Multi-Cloud Kubernetes 最佳实践

【编者的话】本文以 IT 运维团队为多个内部团队构建企业级 Kubernetes 解决方案的视角展开，介绍了在制定 multi-cloud 策略时需要考虑的因素及解决办法，包括基础设施、版本管理、部署策略及安全性等方面，提供了一套相对完整的最佳实践方案。

2018 年云服务现状调查 显示，81％ 的企业会使用混合云，公有云计算服务和现代基础架构平台更具灵活性。随着企业为客户提供价值速度的加快，公有云和私有云的采用率继续以健康的速度增长也就不足为奇了。 事实上，根据 IDC 的最新数据 ，2018 年第一季度全球服务器出货量同比增长 20.7％ 至 270 万台，收入增长 38.6％，连续第三个季度实现两位数增长！

另一个令人兴奋的大趋势是，容器成为了打包和管理应用程序组件的最佳方式。Kubernetes 是部署和操作容器化应用的最佳方式，这一点已被广泛认同。另外重要的一点是，Kubernetes 可以助力跨云供应商提供标准化功能。

但这些进步也引进了新的复杂性。容器解决了一些 DevOps 面临的挑战，但也引入了新的需要管理的抽象层。Kubernetes 解决了运维面临的部分挑战，并非全部。而且，Kubernetes 是一个分布式应用，本身也需要管理。

在不同云供应商之间部署和运营 Kubernetes 集群时会面临一些关键挑战，本文将就此讨论解决这些挑战的最佳实践和指南。我们将以 IT 运维团队为多个内部团队构建企业级 Kubernetes 解决方案的视角展开。

1.利用好基础设施

与本地基础架构供应商一样，所有云供应商都提供存储和网络服务。在考虑 multi-cloud 策略时要关注的一个问题是，是依赖每个供应商的能力还是自己去抽象一层。虽然这两种方法都可行，但尝试最小化抽象层并利用供应商的原生方法始终是明智的做法。例如，不要在 AWS 中运行 Overlay Network，而最好使用 AWS 的 Kubernetes CNI（容器网络接口）插件，该插件为 Kubernetes 提供本机网络功能。此方法还允许使用其他服务，如安全组和 IAM。

2.管理自己的（上游）Kubernetes 版本

Kubernetes 是一个快速发展的项目，每三个月发布一次新版本。一个关键的决定是，是否希望供应商为你测试新版的 Kubernetes，或者是否允许团队直接使用上游版本。

当然，这需要衡量利弊。使用供应商管理的 Kubernetes，供应商可以提供额外测试和验证。但是，Cloud Native Computing Foundation（CNCF）的 Kubernetes 社区本身拥有成熟的开发、测试和发布流程。Kubernetes 项目由一些特殊兴趣小组（SIG）组织， Release SIG 负责确保每个新版本的质量和稳定性。CNCF 还为供应商提供 Kubernetes 软件一致性计划 ，以确保他们的软件与 Kubernetes API 100％ 兼容。

企业在生产环境中最好使用稳定版本。但是，某些团队可能需要具有 pre-GA 功能的集群。最好的办法是，团队可灵活选择多个校验过的上游版本，或者按需尝试更新的版本，但风险自负。

3.通过策略标准化集群部署

安装 Kubernetes 集群时需要考虑的几个点。 如下：

• 版本 ：要使用的 Kubernetes 组件的版本。
• 网络 ：通过 CNI （ 容器网络接口 ）插件配置要使用的网络技术。
• 存储 ：通过 CSI （ 容器存储接口 ）插件配置要使用的存储技术。
• Ingress ： Ingress Controller 用于负载均衡和反向代理外部请求到应用程序服务。
• 监控 ：用于监控集群中 Kubernetes 组件和工作负载的附加组件。
• 日志记录 ：一种集中式日志记录解决方案，用于从 Kubernetes 组件以及集群中的应用程序工作负载收集、聚合和转发日志到集中式日志记录系统。
• 其他附加组件 ：需要作为集群的一部分运行的其他服务，如 DNS 和安全组件。

虽然可以针对每个集群应用这些设置，但将集群安装采样为模板或策略会更加高效，可以轻松复用。这方面的一些示例可以是 Terraform 脚本 或 Nirmata 集群策略 。集群安装自动化后，也可以作为更高级别工作流的一部分调用，例如从服务目录中完成自助服务配置请求。

4.提供端到端安全性

容器 和 Kubernetes 的安全性需要考虑下面几个点：

• 镜像扫描 ：需要在运行之前扫描容器镜像以查找漏洞。在允许镜像进入企业的私有注册表之前，可以将此步骤作为 Continuous Delivery 管道的一部分来实现。
• 镜像来源 ：镜像扫描检查漏洞时，明确镜像出处，确保只允许“可信”镜像进入正在运行的集群或环境。
• 主机和集群扫描 ：除了确保镜像安全外，集群节点及主机也需要扫描。此外，定期运行 互联网安全中心（CIS）基准 以确保 Kubernetes 安全是最佳做法。
• 分段和隔离 ：即使多租户可能不是一项硬性要求，最好还是计划在多个异构工作负载之间共享集群，以提高效率并节省更多成本。Kubernetes 提供用于隔离（例如，命名空间和网络策略）以及用于管理资源消耗（资源配额）的构造。
• 身份管理 ：在典型的企业部署中，用户身份由中心目录提供。无论在何处部署集群，都必须联合用户身份权限，以便以一致的方式轻松控制和应用集群。
• 访问控制 ：虽然 Kubernetes 没有用户的概念，但它提供了丰富的控件来指定角色和权限。集群可以利用默认角色或使用指定权限集定制角色。企业中的所有集群都具有这些角色的通用定义以及跨集群管理它们的方法，这一点很重要。

虽然这些安全实践中的每一个都可以单独应用，但从整体上看，打造一套适用于多个云供应商的安全策略是有意义的。可以使用 AquaSec ， Twistlock 等安全解决方案以及 Nirmata ， OpenShift 等平台实现。

5.集中应用程序管理

与安全性一样，管理 Kubernetes 集群上的应用程序需要集中且一致的方法。Kubernetes 提供了一组可用于定义和操作应用程序的全面构造，大有应用内置的概念。这实际上是一件好事，因为它可以灵活地支持不同的应用程序类型，并允许在 Kubernetes 上用不同方式构建更多定制化的应用程序平台。

但是，任何 Kubernetes 应用程序管理平台都必须提供几个常见的属性和功能。下面主要讨论针对Kubernetes 工作负载，中心化应用程序管理的问题。

应用程序建模和定义

用户需要定义应用程序组件，并从现有组件组成应用程序。Kubernetes 的核心设计理念是其声明性，用户可以在其中定义所需的系统状态。Kubernetes 工作负载 API 提供了几种构造来定义所需的资源状态。例如，部署可用于构造无状态工作负载组件。这些定义通常写为一组 YAML 或 JSON 清单。但是，开发人员需要组织和管理这些清单，通常是在像 Git 这样的版本控制系统（VCS）中。

虽然开发人员希望定义和管理应用程序的某些部分，但当这部分指定了操作策略，并且可能针对特定的运行时环境时，最好由运营团队管理。因此，正确理解程序行为的方式是将其视为在部署和更新之前动态组合的管道。

Helm （Kubernetes 包管理工具）解决了其中一些挑战，它可以轻松地将应用程序分组，版本化，部署及更新为 Helm Charts。

Kubernetes 应用程序平台必须提供简单的方法来建模，组织及构建应用程序清单和 Helm Charts ，并恰当分离开发和运维资源之间的关注点。还必须提供定义校验，以尽早捕获常见错误，以及重用应用程序定义的简便方法。

环境 - 应用程序运行时管理

一旦对应用程序进行建模和验证后，就需要将它们部署到集群。但是，最终目标是在不同工作负载之间重用群集，以提高效率并增加成本节约。因此，最好将应用程序运行时环境与集群分离，并将常用策略和控制应用于这些环境。

Kubernetes 允许使用命名空间和网络策略创建虚拟集群。Kubernetes 应用程序平台应该可以轻松利用这些构造，创建具有逻辑分段，隔离和资源控制的环境。

更改管理

在很多情况下，运行时环境寿命会很长，并且需要通过控制器进行更改。这些更改可能源自构建系统或来自传递管道中的上游环境。

Kubernetes 应用程序平台需要提供 CI/CD 工具的集成，并监控外部 repository 的变化。检测到更改后，应对其进行验证，然后根据每个环境的更改管理策略进行处理。用户应该查看并接受更改或完全自动化更新过程。

应用监控

应用程序可能在多个环境和不同群集中运行。关于监控，重要的是有能力将信号与噪声分离并专注于应用实例。因此，度量、状态和事件需要与应用程序和运行时构造相关联。Kubernetes 应用程序平台必须提供带有自动粒度标记的集成监视，以便用户可以轻松地下钻并专注于任何环境中的应用程序实例。

应用日志

与监控类似，日志数据需要与应用程序定义和运行时信息相关联，并且应该可以访问任何应用程序组件。Kubernetes 应用程序平台必须能够流式传输并聚合来自不同运行组件的日志。如果使用集中式日志记录系统，则必须应用必要的标记，以便能够分离来自不同应用程序和环境的日志，并支持跨团队和用户的访问。

报警和通知

服务管理层面必须能够根据任意指标，状态更改或条件定制警报。再强调一点，需要正确区分紧急报警和其他常规报警。例如，如果相同的应用程序部署在 dev-test，staging 和 production 等多个环境中运行，则能够自定义仅在生产环境才可触发的警报规则是非常重要的。 Kubernetes 应用程序平台必须具备提供定义和管理环境及应用程序感知的粒度警报规则的能力。

远程访问

云环境往往是动态的，容器将动态性提升到了一个新的水平。 一旦检测到并报告了问题，就必须快速访问系统中受影响的组件。Kubernetes 应用程序平台必须提供一种方法，将 shell 启动到正在运行的容器中，并访问容器运行时的详细信息，而无需通过 VPN 和 SSH 访问云实例。

事件管理

在 Kubernetes 应用程序中，容器可能会停止运行并快速重新启动。停止运行可能是正常工作流程的一部分，如升级，或者可能是由于内存不足等情况导致的错误。Kubernetes 应用程序平台必须能够识别故障并捕获故障的所有详细信息，以便进行脱机故障排除和分析。

总结

容器和 Kubernetes 允许企业利用一组通用的行业最佳实践来跨云供应商进行应用程序操作和管理。所有主流云供应商和应用平台都承诺支持 Kubernetes。这包括平台即服务（PaaS）解决方案，其中开发人员提供代码工件，平台执行其他工作；容器即服务（CaaS）解决方案，开发人员提供容器映像，平台完成其余工作；功能即服务（FaaS）解决方案，开发人员只需提供功能，平台完成其余工作。 Kubernetes 已成为新的云原生操作系统。

在开发 multi-cloud Kubernetes 策略时，企业必须考虑他们希望如何使用基础架构服务，管理Kubernetes 组件版本，设计和管理 Kubernetes 集群，定义公共安全层和应用程序管理。

原文链接： Best Practices for Multi-Cloud Kubernetes （翻译： 李加庆 ）