Kubernetes是一个编排器。这是你部署、网络、负载均衡、扩展和维护容器化应用程序的方式。这些工作负载中的每一个都有自己的架构，无论是有状态的还是无状态的，都是容器化的单体，或者是与服务网格、批处理作业或无服务器功能一起使用的微服务。

但你还需要考虑Kubernetes基础设施本身的架构：如何构建Kubernete运行的平台。

Kubernetes足够灵活，可以在几乎任何类型的硬件上部署任何类型的应用程序，无论是在云中还是其他地方：为了既通用又强大，它具有极高的可配置性和可扩展性。这提供了许多架构选择。

这些选择包括你是否自己做出所有单独的配置选择，是否遵循VMware Tanzu或Azure Arc等工具中的默认选项（这些工具提供了更集成的部署和管理基础设施的方法），或者使用托管云Kubernetes服务（该服务提供有关部署资源的选择，为常见应用程序工作负载设计的参考架构和蓝图）。

规划Kubernetes资源

Kubernetes基础设施是Kubernete用于运行容器化应用程序（及其自己的服务）的一组物理或虚拟资源，以及在指定和配置它们时所做的选择。

需要根据pod和服务的工作负载和资源需求，决定控制平面服务器、集群服务、附加组件、集群、数据存储和网络组件所需的虚拟机（或裸金属硬件），集群上需要多少节点，以及它们应该具有哪些内存和vCPU。

自动缩放允许动态地向上或向下调整容量，但需要有可用的基础容量。需要考虑托管Kubernetes集群的最佳平台：在自己的数据中心、边缘、托管提供商或公共、私有或混合云中的基础设施。

其中一些将取决于工作负载的需求：如果它们主要是无状态的（或者如果很容易将状态存储在外部），可以通过使用部署打折扣但也可能突然中断的现货实例来降低云成本。需要了解计划运行的应用程序的大小、复杂性和可扩展性，以及所需的控制和定制量，并考虑将使用的资源的性能、可用性和成本。

最初，Kubernetes的构建是基于这样的假设，即它运行的所有硬件基本上都是相似的，并且可以有效地互换，因为它是为了利用云基础设施即服务（IaaS）中常见的商品服务器而开发的。

但即使在云环境中，不同的工作负载仍然需要非常不同的资源，Kubernetes已经进化为支持更多的异构基础设施：不仅是Windows节点和Linux节点，还有GPU、CPU、Arm处理器和x86。甚至可以选择使用某些类别的Linux设备作为节点。

如果正在为Kubernetes虚拟机使用云IaaS，或者使用托管云Kubernete服务（如AKS或EKS），可以为VM选择合适的实例。如果正在边缘构建自己的Kubernetes基础设施，可能会选择Arm硬件或消费级Intel NUC来运行要求较低的Kubernet分发，例如在餐厅或零售店中的k3s，在那里没有数据中心级硬件的设施。

根据选择的Kubernetes发行版，可能还需要考虑所需的主机操作系统以及要使用的容器运行时。运行自己的容器注册表还是只从公共注册表中提取镜像？在哪里储存秘密？使用HashiCorp Vault或来自云提供商的托管密钥存储意味着部署管道中不会有可能泄漏的凭据。

多集群K8s基础架构

还需要考虑可能的故障：是否需要运行关键控制平面组件的多个副本的高可用性集群，或者运行多集群架构？

对于较小的Kubernetes基础设施，可以使用命名空间分隔不同的工作负载：逻辑分区，允许在一个集群上隔离和管理不同的应用程序、环境和项目。但也可以使用单个Kubernetes控制平面来管理多个节点集群，将工作负载放在不同的集群上，以获得更好的安全性和性能。

如果对延迟有监管要求或严格限制，需要强制执行不同的策略和权限，或者希望避免需要零停机的应用程序出现单点故障，这可以在不同的位置（包括不同的云提供商）编排应用程序，但仍有一个地方可以访问该基础设施。这简化了从集群到集群的应用程序迁移，无论是用于扩展还是灾难恢复，尽管这也带来了很大的复杂性。

Kubernetes基础设施联网

还需要规划服务发现选项和网络拓扑，包括防火墙和VPN连接，以及网络插件、DNS设置、负载均衡器和集群的入口控制器。

考虑访问管理：需要部署基于角色的访问控制（RBAC）来为用户和资源实施细粒度的权限和策略，并确保确保管理员访问的安全。还需要为需要访问现有数据存储的工作负载管理机器标识。

原生Kubernetes用户身份验证使用证书：如果需要对用户访问进行集中控制和管理，你可能希望使用现有的身份提供程序进行身份验证。

Kubernetes管理架构

由于Kubernetes的构建使其易于扩展应用程序，而你可以手动更改单个设置，如活跃度和就绪性探测，因此它确实是为声明性配置管理而设计的。可以在YAML中编写配置文件（或使用一个发出配置文件的工具），告诉Kubernetes应用程序应该如何运行，而Kubernete负责实现这一点。

与其调整设置，不如将重点放在使用“基础设施即代码”实现可重复性的自动化上：将配置设置为版本控制、可审核的代码，并根据需要经常应用它（如果出现问题，则重新启动它），每次都得到相同的系统。

可重复、不可变的基础设施，将集群视为牛（而不是单独命名、拥抱和关心的宠物），这就是Kubernetes的设计宗旨。为此做好准备是关于如何减少持续管理和实际运维生产中容器的工作量。

可以使用具有Flux或Argo CD的GitOps工作流将其扩展到策略管理和治理以及应用程序交付，该工作流部署应用程序更新，并从引导到配置更新，始终保持集群处于所需状态。需要收集指标并跟踪性能：大多数工作负载都会发出Prometheus指标，但还需要考虑监控仪表板以及希望启用的日志记录。

需要监控容器基础设施的威胁和安全风险，并确保VM主机得到了适当的加固。同样，在规划Kubernetes基础设施时，考虑将使用的工具和流程，可以更容易地确保不会遗漏任何内容。

了解Kubernetes架构

将所有这些放在一起并不简单，你可以从其他Kubernetes用户如何构建其基础设施中学到很多东西。

前Kubernetes发布负责人兼指导委员会成员Lachlan Evenson说：“需要数年Kubernete开发经验才能取得成效。你需要一本帮助导航和避开冰山的书。”Evenson与Kubernetes联合创始人Brendan Burns合著了《Kubernetes Best Practices》，试图提供一个配套指南来提供一些帮助。

但你仍然应该花时间弄清楚什么样的基础设施最适合你的特定工作负载，并获得运行它的专业知识。