在这篇博客中,我们将介绍在设置 Kubernetes 集群时必须考虑的高级 kubernetes 集群最佳实践。
Kubernetes 网络的设计方式必须能够适应未来的集群和应用程序需求。
Kubernetes 网络组织常犯的一个错误是使用不属于组织网络的 CIDR 范围。将来,当他们希望集群位于混合网络中时,最终会进行迁移。
在最终确定网络设计之前,最好与组织的网络团队进行讨论。这样,即使您不是混合网络的一部分,也可以划分和保留 IP 范围。
每个云提供商都为 Node 和 Pod 网络提供了多种选择。
例如,Google Kubernetes Engine 提供多集群服务、具有来自同一 VPC 的可路由 Pod IP 的 VPC 原生集群,以及对等 VPC。
AWS EKS 提供了基于 VPC 本机和辅助范围的 Pod 联网选项。
但是,如果您不想公开 Pod IP,则可能需要在集群中使用类似 IP 伪装代理之类的东西,以便传出流量始终将节点 IP 作为源标识。
此外,入口和出口流量设计也是必不可少的。可能需要从群集应用连接 API 网关、本地系统、代理服务器和第三方 API。
您的设计应包括所有访问要求,以便在实现过程中不会遇到任何访问限制。
以下是通用的 Kubernetes 安全最佳实践。
设计和记录 kubernetes 集群的访问方式非常重要。
以下是关键注意事项。
设计访问级别,以便可以将职责移交给使用群集的其他团队。这将为每个人节省时间,您可以更专注于工程标准,而不是重复完成任务。
高可用性是 Kubernetes 集群中的另一个关键因素。
在这里,您需要考虑跨不同可用区的工作节点可用性。
此外,请考虑 Pod 拓扑分布约束,以将 Pod 分布在不同的可用区中。
当我们谈论扩展时,它不仅仅是实例或 Pod 的自动扩展。
这是关于如何在不中断任何服务的情况下优雅地缩减和纵向扩展应用程序。
根据需要在 Kubernetes 上托管的应用类型,您可以设计部署,以便在缩减和修补活动期间正常逐出 Pod。
此外,请考虑在生产之前进行混沌工程实验,以检查集群和应用的稳定性。
Ingress 是 Kubernetes 集群的重要组成部分。
此外,还有不同类型的入口控制器。
可以尝试适合组织的合规性策略和缩放要求的最佳选项。
无论是托管服务还是自定义 kubernetes 实现,备份集群都是必不可少的。
当我们说备份时,它主要是备份 etcd。
你应该有一个非常好的设计来自动备份 kubernetes 集群及其相关组件。
此外,还需要还原群集的设计。
还有一些选项可以采用JSON格式的现有对象进行转储。您可以使用转储来还原相同或不同集群中的对象。
修补是一个重复的过程。
当涉及到 kubernetes,有节点和容器修补。
请确保在 CI/CD 管道中实现 DevSecOps 原则。
以下是一些最佳实践,
通常,您可以通过两种方式执行集群升级
您需要一个非常好的自动化管道设计来执行集群升级。
在升级过程中,可能会发生网络、DNS 和其他组件更改。这完全取决于设计和组织政策。
集群容量是一个非常重要的讨论主题。
您需要确定需要运行的集群数量。
一些组织更喜欢运行多个集群,以减小爆炸半径并易于维护。而另一些人则更喜欢具有大量工作节点的大型集群或具有巨大实例容量的较少节点。
您可以根据自己的需求和管理集群的团队规模来决定集群容量。
接下来是存储部分。
规划将卷附加到容器的方式。遵循 Kubernetes 上的所有标准存储安全实践。
在云方面,有开箱即用的支持来配置存储,
如果计划运行有状态集,则设计存储以获得高吞吐量和最大可用性非常重要。
此外,有状态集备份和还原也很重要。
大多数组织将拥有一个集中的日志记录和监控系统,他们更喜欢将 Kubernetes 与这些系统集成。
下面是一些日志记录和监视最佳做法。
这些是一些 kubernetes 设计最佳实践,在设置 kubernetes 集群时经常被遗漏。
在实现 Kubernetes 时缺少这些方面可能会导致整个集群出现问题,并可能对业务造成损害。
这不仅仅是使用自动化创建 Kubernetes 集群,您还需要考虑 Kubernetes 集群生命周期管理并相应地规划自动化工作。
理想情况下,解决方案/技术架构师在设计集群架构时应将所有提到的项目(可能有很多,但值得考虑)保留为清单,以确保它们在 IaaC 开发期间实现。