照片由 orbtal media 拍摄，来自 Unsplash。
我们如何使用Kubernetes来管理微服务——一个高层次的视图及介绍
为什么选择 Kubernetes?简单回答是这样的，它很好地满足了我们的需求；并且它解决了重要且复杂的难题，而我们不需要自己去构建这些解决方案。Kubernetes提供的显而易见的解决方案围绕着扩展、容器打包以及它让服务能够在一定程度上实现自我恢复。
另一个关键考虑是部署的简便性，包括轻松进行部署和回滚。我们已经建立了一个围绕部署的复杂基础设施，但这方面的更多细节将在后续的文章中介绍。
我们是怎么用Kubernetes的？
我们的生产设施分布在四个不同的可用区域，每个区域都有自己独特的Kubernetes集群。从技术上讲，Kubernetes目前确实拥有可以在单个集群内管理这种拓扑结构的机制，但这对我们来说还是一个新功能，我们还没有去探索。
随着时间的推移，我们发现将这些事情分布在四个集群里存在一些巨大好处。这个列表还在继续增加，其中一些更重要的好处有：
通过一些内部工具按需在不同可用性区域之间调整流量的能力。- 这在单一区域出问题时（无论是云提供商的问题，还是其他依赖关系的问题）非常有用。
- 如果我们想测试一个新的Kubernetes插件或配置更改——我们总是可以在验证更改时将大部分生产流量切换到其他三个集群上，而在基础设施的底层进行验证（如果在测试集群上无法验证的话）
我们选择的服务网格是Istio（https://istio.io/）。我们使用一系列内部控制器来管理入站和出网关，以确保从我们的CDN到四个集群的流量配置和协同工作顺利进行。这里就不详细展开了，这可以单独写成一篇文章呢！
配置和管理Terraform 和一些内部工具是我们管理集群配置的利器。当团队刚开始构思 Kubernetes 配置时，当时市面上还没有很多工具可以帮助简化 Terraform 的操作。我们编写了（并继续维护）一个内部工具，帮助我们在每个集群（包括我们的生产集群和内部测试集群）上对配置进行模板化、渲染和应用。
一个能够处理模板和静态配置的工具已经证明是无价的，它确保我们始终拥有单一事实来源的配置，并且有一个适当的流程来测试和应用集群中的更改。
我们都清楚Kubernetes及容器化领域变化之快——在回复中告诉我们，你们用了哪些其他工具让Kubernetes配置更简单易管！
调整以扩展应对峰值负载，收缩以适应请求为了确保我们的应用程序资源请求根据实际使用情况进行合理配置，我们投入了大量的精力。这在很大程度上帮助我们达到能够充分利用节点资源的状态（更有效的资源分配）。从而让我们的扩展更加平滑，但也需要一些额外调整和工具。
集群过量配置器与 Pod 预抢占这个工具真棒。你可以定义副本的数量和它们所需的资源量。在我们这里，需要扩展最多的服务是backend-A，它也需要不少资源。一旦我们明白了扩展事件的情况，就知道了需要多少副本以及怎么调整它们的大小。
假设我们有频繁的突发，而这项服务需要大约额外的200个pod（在四个集群中）来开始处理请求。如果这些pod无法迅速扩展，我们就会开始看到5xx状态码的迅速增加。
我们将集群过量提供器（cluster-overprovisioner）设置在每个集群中，请求比backend-A pod稍多的CPU和内存资源，并将副本数量设置为50（因为这是每个集群的配置）。通过正确设置和配置优先级抢占 和 集群自动缩放器，我们因此得到了以下好处：
- cluster-overprovisioner 目标是确保任何时候都有相当于 200 个
backend-APod 的额外资源可用，以备扩容事件之需。 - 当需要调度新的
backend-APod 时，cluster-overprovisioner Pod 会被抢占（即驱逐）从而为新的 Pod 让位。 - 当这些被驱逐的 overprovisioner Pod 需要重新调度时，这会促使 cluster-autoscaler 触发节点扩容事件。
这样一来，集群过量供应器本质上吸收了节点扩展事件的延迟，为我们提供了缓冲空间，使生产服务的扩展更加平滑无扰。
一个额外的好处是，我们的节点图表看起来比以前平滑很多。我们不再需要像以前那样频繁地扩展节点了：
总节点数总数在所有4个集群之间经常超出800至900个节点，在进行过度配置和调整大小之前。
节点数量的峰值降至大约400个节点，在所有生产集群中，峰值不超过600个节点——在过度配置和调整应用规模之后。
最后的话Kubernetes 本身就有很高的复杂性，可以根据组织的需求具有无数种可能的配置。在 Medium，我们对自己的 Kubernetes 调整成果感到非常自豪。这并不影响我们对探索新的方法来增强我们的基础设施的热情，同时利用新技术提高可靠性和可扩展性。
随时随地看视频
