引言
我们如何使用 Kubernetes 来管理微服务——概览与介绍
为什么选择Kubernetes？
简单来说，Kubernetes 完美地满足了我们的需求；它解决了许多复杂且重要的问题，而我们无需自己从头开始构建解决方案。Kubernetes 提供的显著优势包括：扩展性、资源优化（类似于容器的“装箱”）以及其让服务具备一定的“自愈”能力。
另一个关键考虑因素是部署——尤其是简化发布和回滚的过程。我们围绕部署构建了复杂的基础设施，但关于这方面的细节，我们将在后续的文章中进一步讨论。
我们如何使用 Kubernetes 呢？
图片
我们的生产基础设施分布在四个可用区，位于四个独立的 Kubernetes 集群中。从技术角度来看，Kubernetes 现在已经有了在单一集群内管理这种拓扑的机制[1]，但这是一个较新的功能，我们还没有深入探索过。
随着时间的推移，我们意识到将基础设施分布在四个集群中带来了巨大的好处。这个好处清单不断增加，但其中一些更为重要的好处包括：
必要时通过一些自研工具在可用区之间切换流量
• 当某个可用区出现问题时（无论是由于云服务提供商的问题，还是其他依赖关系出现故障），这种能力证明是非常有用的。
在生产环境中逐步发布基础设施变更
• 假设我们想要测试一个新的 Kubernetes 插件或配置更改——我们可以将大部分生产流量转移到其他三个集群上，同时在底层基础设施上验证这些更改（如果我们无法在预发布集群上验证的话）。
我们选择的服务网格是 Istio[2]。我们使用多种自研控制器来管理我们的入口和出口网关，确保从我们的 CDN 到四个集群之间的流量配置和协调顺畅。这里就不再展开讨论了（这个话题本身就足够写一篇完整的文章了！）。
配置与管理
Terraform 和一些自研工具是我们管理集群配置的首选工具。在团队最初构思 Kubernetes 配置时，市面上并没有很多工具能帮助简化 Terraform 的使用。于是，我们开发了一个内部应用（并且一直在维护），帮助我们为每个集群模板化、渲染并应用配置，无论是我们的生产集群，还是任何内部的预发布集群。
拥有一个单一的工具，能够让我们使用模板和静态配置，证明在确保我们始终拥有“配置真相源”和拥有合理的测试与应用变更流程方面是无价的。
我们都知道 Kubernetes 和容器化领域变化发展非常迅速——欢迎在评论中分享你们使用的其他工具，帮助你们更轻松地管理 Kubernetes 配置！
扩展与收缩的调优 — 应对流量激增与请求收缩
我们投入了大量精力，确保我们的应用资源请求是根据真实的资源利用情况进行合理调整的。这在很大程度上帮助了 Medium[3] 达到现在的状态，使我们能够更高效地使用节点（实现了更有效的资源优化）。此外，这也使得我们的扩展过程更加平稳，但这也需要额外的调优和工具来帮助我们实现这一目标。
Cluster Over-Provisioner & Pod Preemption
这个工具[4]非常棒。对于它的过度简化解释是：你定义副本的数量以及它们所需的资源量。在我们的案例中，我们知道需要根据流量进行最大扩展的服务（我们称之为 backend-A）也需要大量的资源。一旦我们理解了扩展事件的特征，我们就知道了应该为多少副本做规划以及如何调整它们的资源配置。
假设我们有频繁的流量激增，并且这个服务需要大约 200 个额外的 Pod （跨所有四个集群）来开始处理请求。如果这些Pod没有及时扩展，我们就会看到 5xx 错误的急剧增加。
我们在每个集群中设置了 cluster-overprovisioner，要求它请求比 backend-A Pod 略多的 CPU 和内存资源，并将副本数设置为 50（因为这是每个集群独立配置的）。通过 Priority & preemption[5] 和正确配置的cluster-autoscaler[6]，我们获得了以下好处：
• Cluster Over-Provisioner 的目标是在任何给定时刻，确保为扩展事件提供 200 个额外 backend-A Pods 所需的资源。
• 当新的 backend-A Pods 需要调度时，Cluster Over-Provisioner 的 Pods 会被抢占（即驱逐[7]），以为它们腾出资源。
• 随着 Over-Provisioner 的 Pods 被驱逐，它们仍然需要重新调度。因此，它们会通过 ckuster-autoscaler 触发节点扩展事件。
因此，Cluster Over-Provisioner 本质上吸收了节点扩展事件中的延迟，并为我们提供了足够的空间，确保生产服务的扩展事件能够顺利进行且不受中断。
另一个好处是，我们的节点计数图表看起来比以前更加平滑了。我们不再需要像以前那样频繁地扩展节点。
图片
在进行 Over-Provisioner 和资源优化之前，所有 4 个集群的总节点数经常突破 800 到 900 个节点。
图片
在进行 Over-Provisioner 和应用程序资源优化后，所有生产集群的节点数峰值降至接近 400 个节点，且峰值几乎不再突破 600 个节点。
结语
Kubernetes 具有极高的复杂性，并且根据组织的需求，它可以有无限多种可能的配置。在 Medium，我们非常自豪能够将 Kubernetes 调整到符合我们自身需求的状态。尽管如此，这并没有减少我们探索新方法以增强基础设施的热情，同时我们也在不断利用新技术，帮助提升系统的可靠性和可扩展性。
原文：https://medium.com/medium-eng/kubernetes-infrastructure-at-medium-d9e2444932ef
引用链接
[1] 拓扑的机制:https://kubernetes.io/docs/concepts/services-networking/
[2]Istio:https://istio.io/
[3]Medium:https://medium.com/
[4]工具:https://github.com/deliveryhero/helm-charts/tree/master/stable/cluster-overprovisioner
[5]Priority & preemption:??https://kubernetes.io/docs/concepts/scheduling-eviction/pod-priority-preemption/
[6]cluster-autoscaler:https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler
[7]即驱逐:https://kubernetes.io/docs/concepts/scheduling-eviction/pod-priority-preemption/#preemption
