【.com快译】根据2018年云计算状态报告：现在81%的企业使用多种云服务模式。云服务、现代基础设施平台和公有/私有云的持续混合可以更快地为客户提供价值，同时快速灵活地调整自己的规模和容量。事实上，根据IDC最新数据，2018年第一季度，全球服务器出货量同比增长20.7%至270万台，整体营收增长38.6%，已是连续第三个季度出货量同比增长20.6%。达到两位数的增长。另一个令人兴奋的趋势：容器的出现提供了打包和管理应用程序组件的最佳方式。Kubernetes也被广泛认为是部署和运行容器化应用程序的最佳解决方案。此外，Kubernetes的关键价值在于它可以帮助标准化多个云提供商提供的服务功能。当然，这些优势也带来了一定的复杂性。虽然容器解决了与DevOps相关的问题，但它们也引入了一个需要管理的新抽象层。由于Kubernetes本身是分布式应用，需要管理，只能解决部分运维问题，不能解决全部。在本文中，我们将讨论在多种云服务模式下成功部署和运行Kubernetes集群的关键操作难点和最佳实践。总的来说，我们的观点是，IT运营团队应该为多个其他内部团队构建一个企业范围的整体Kubernetes战略。1.使用最好的基础设施与传统的内部基础设施提供商一样，所有云服务提供商都能够提供存储和网络等服务。在考虑多种云服务模型的策略时，我们关注：是否使用每个提供商提供的现有功能？或者使用抽象层。虽然这两种方法都有效，但您应该注意尽可能减少抽象层并使用供应商自己的解决方案。例如：不要在AWS中运行覆盖网络（overlaynetwork，译者注：它是一种针对应用层的网络协议，没有或减少对网络层和物理层的考虑），但最好使用AWS提供的KubernetesCNI（容器网络接口（ContainerNetworkInterface）插件，为Kubernetes提供原生网络功能。这种方式也可以使用其他服务，如安全组和IAM（译者注：身份和访问管理，Identityand访问管理）。2.管理自己的Kubernetes版本Kubernetes是一个快速发展的项目，每三个月发布一个更新版本。因此，您需要决定是让供应商为您测试和管理Kubernetes版本，还是让您自己的团队直接使用这些版本。凡事都有利有弊，需要考虑。如果您使用供应商来管理Kubernetes，他们会带来额外的测试和验证帮助。当然，云原生计算基金会（CNCF）的Kubernetes社区本身就有成熟的开发、测试和发布流程。Kubernetes项目由一个特殊兴趣小组（SpecialInterestGroups，SIGs）管理，ReleaseSIG（https://github.com/kubernetes/sig-release#mission）负责确保每个新版本的发布，通过各种工艺。质量稳定。CNCF还为各个供应商提供了Kubernetes软件一致性（https://www.cncf.io/certification/software-conformance/）程序，以证明他们的软件能够与Kubernetes的各种API实现100%兼容。对于企业来说，生产环境最好使用稳定版。但是，有些团队可能需要一个pre-GA（译者注：pre-GeneralAvailability，正式发布之前）特性集群。因此，最好的方法是让团队可以灵活地选择各种经过验证的上游版本，或者让他们根据需要尝试新版本，但风险自负。3.通过策略规范集群部署在安装Kubernetes集群时，我们需要做出以下重要决定：版本：要使用的Kubernetes组件的版本。Network：通过CNI（ContainerNetworkingInterface，容器网络接口，https://github.com/containernetworking/cni）插件配置要使用的网络技术。存储：要使用的存储技术通过CSI（ContainerStorageInterface，容器存储接口，https://github.com/container-storage-interface/spec）插件进行配置。Ingress：IngressController可用作负载均衡器，并反向代理对不同应用程序服务的各种外部请求。监控：可用于监控集群中的Kubernetes组件和工作负载的附加组件。日志记录：一种集中式日志记录解决方案，可用于从集群的Kubernetes组件和应用程序工作负载收集、聚合日志并将其转发到集中式日志记录系统。其他附加组件：需要作为集群的一部分运行的其他服务，例如DNS和安全组件。虽然我们可以为每个集群安装实施上述决策，但如果可以将它们作为集群安装的模板或策略输入，我们以后重用它们会更有效。例如，我们可以使用Terraform脚本（https://www.terraform.io/docs/providers/kubernetes/index.html）或Nirmata集群策略（http://nirmata-documentation.readthedocs.io/en/latest/Clusters.html）。一旦集群安装自动化，它就可以作为高级工作流的一部分被调用。例如：根据服务目录执行自助服务供应请求。4.提供端到端的安全性对于容器和Kubernetes的安全性，我们需要考虑以下几个方面：镜像扫描：在容器镜像运行之前，我们必须扫描各种漏洞。因此，在允许图像进入企业私有存储表之前，可以将此步骤作为持续交付管道的一部分实施。图片来源：除了对图片进行漏洞扫描外，我们应该只允许那些“可信”的图片进入运行的集群环境。主机和集群扫描：除了对镜像实施安全控制，我们还应该对集群节点进行扫描。Kubernetes的常规安全强化是使用CIS（互联网安全中心）(https://www.cisecurity.org/benchmark/kubernetes/)的各种安全基线的最佳实践。分段和隔离：虽然多租户环境不是必需的，但可以通过在多个异构工作负载之间共享集群来实现真正的效率和成本节约。Kubernetes提供隔离结构（例如命名空间和网络策略）和管理资源的开销（例如资源配额）。身份管理：在典型的企业部署中，用户身份由集中目录提供。因此，无论我们将集群部署在哪里，都应该控制联合用户身份，以方便一致的管理、控制和应用。访问控制：Kubernetes虽然没有用户的概念，但是可以提供对指定角色和权限的丰富控制。集群可以使用各种默认角色，以及指定权限集的自定义角色。重要提示：同一企业内的所有集群都应该使用跨集群的通用角色定义和管理方法。虽然上述每个安全实践都可以单独使用，但我们应该跨多个云提供商彻底审查和规划我们的安全策略。我们可以通过使用AquaSec、Twistlock等安全解决方案结合Nirmata、OpenShift等平台来做到这一点。5.集中式应用管理与安全相同，管理Kubernetes集群上的各种应用也需要集中一致的解决方案.Kubernetes提供了一整套可用于定义和操作不同应用程序的结构。由于它确实内置了一些应用的概念，因此可以灵活地支持不同的应用类型，允许不同的应用平台以不同的方式在Kubernetes上构建。当然，Kubernetes应用管理平台也提供了一些通用的属性和功能。下面列出了Kubernetes工作负载的集中应用管理需要考虑的方面：应用建模和定义用户需要定义其应用的组件，以基于现有组件编写新的应用。用户可以通过Kubernetes的声明性来定义系统的目标状态。Kubernetes工作负载API提供了多种结构来定义所需的资源状态。示例：我们可以使用部署来为无状态工作负载组件建模。这些定义通常写成一组YAML或JSON清单。当然，开发者也可以使用Git等版本控制系统（VersionControlSystem，VCS）来组织管理这些列表。开发人员只需要定义和管理应用程序清单的某些部分，而其他部分可以由运营团队指定以运行策略和特定的运行环境。因此，我们可以将应用程序清单理解为在部署和更新之前动态生成的管道。Helm是一个辅助Kubernetes进行包管理的工具。它使应用程序的分组、版本控制、部署和更新变得容易。Kubernetes应用平台必须从开发和运维的不同关注点出发，提供简单的方法来建模、组织和构建应用清单和HelmCharts。该平台还必须提供对不同定义的验证，以便尽早发现常见错误，同时提供一种简单的方法来重用这些应用的定义。运行环境管理应用的应用程序在建模和验证后，需要部署到集群中。由于我们的最终目标是跨不同的工作负载重用这些集群以提高效率和节省成本。因此，最好将应用程序的运行环境与集群解耦，并对环境应用通用的策略和控制。由于Kubernetes允许使用命名空间和网络策略来创建虚拟集群，因此Kubernetes应用程序平台应该能够轻松利用这些构造来创建具有逻辑分离和隔离以及资源控制的环境。变更管理在大多数情况下，操作环境是持久的，因此我们需要以可控的方式对其进行更改。这些更改通常源自构建系统或交付管道中的上游环境。Kubernetes应用平台需要为CI/CD（持续集成和持续交付）工具提供各种集成，并监控外部存储库的变化。一旦检测到更改，就应该根据不同环境中的更改管理策略对其进行验证和处理。当然，用户也可以查看更改、接受更改或完全依赖自动更新过程。应用监控不同的应用运行在多个环境中，运行在不同的集群中。从监控的角度来看，我们需要尝试对传递的消息进行降噪，以便我们可以专注于应用程序的实例。因此，我们需要将应用程序的指标、状态和事件与运行时环境的构建相关联。同时，Kubernetes应用平台还必须将监控与自动化的细粒度标签结合起来，让用户在任何环境下都能深入查看应用实例。应用程序日志记录类似于监视。日志数据还需要将应用程序定义与运行时环境信息相关联，并且可以被任何应用程序组件访问。Kubernetes应用平台必须能够在不同的运行组件上流动和聚合日志。如果你使用集中式日志系统，你必须将应用程序标记为必要的，以分离来自不同应用程序和环境的日志，并且还可以实现跨团队和用户访问管理。警报和通知对于服务级别管理，我们必须能够根据任何指标值、状态变化或不同条件自定义警报。同样，我们可以根据相关性区分需要立即采取行动的警报和可以延迟的警报。例如：如果部署同一个应用程序在多个环境（例如开发测试、暂存和生产）中运行，我们必须能够定义仅在生产工作负载上触发的警报规则。Kubernetes应用平台必须能够感知环境和应用，从而提供细粒度警报规则的定义和管理。由于云服务，远程访问环境是动态的，而容器将这种动态提升到一个新的水平。因此，一旦检测到并报告了问题，我们必须能够快速访问受影响的系统组件。Kubernetes应用平台必须提供一种方法，可以在运行的容器中启动shell，访问容器运行环境的详细信息，而无需通过VPN和SSH访问各种云服务实例。事件管理通常在Kubernetes的应用中，可能会有容器的退出和重启。这个退出可能是正常工作流程的一部分（比如升级），也可能是内存不足等错误导致的。Kubernetes应用平台必须能够识别故障并捕获故障的所有详细信息，以供离线分析和排查。总结容器和Kubernetes使企业能够利用一组通用的行业最佳实践来跨多个云服务操作和管理应用程序。所有主流的云服务提供商和应用平台都承诺支持Kubernetes。其中，有“开发人员提供代码工件，平台负责其余部分”模式的平台即服务（PaaS）解决方案；还有基于“部分”模式的“开发者提供容器镜像，平台搞定”容器即服务（Container-as-a-Service，CaaS）方案；还有一种功能即服务（Functions-as-a-service），是基于“开发者只需要提供功能性功能，平台负责其余部分”的模式。-服务，FaaS）方案。可以说，Kubernetes已经成为了新的云原生操作系统。因此，企业在针对多种云服务模型制定Kubernetes策略时，必须慎重考虑：如何使用基础设施服务，如何管理Kubernetes组件版本，如何设计和管理Kubernetes集群，如何定义公共安全层，如何定义公共安全层。管理应用程序。原标题：Multi-CloudKubernetesBestPractices，作者：JimBugwadia
