如果您是k8s的新手，此时您被安排为您的企业研究供应商支持平台，你很有可能不知所措。你会遇到一个看似永无止境的供应商列表，当然，所有的供应商或多或少都一样。

为了帮助你浏览并向供应商询问正确的问题，我们创建了此 no- BS Kubernetes 清单。清单中包括了面向未来的Kubernetes策略的所有“必备品”。

企业级Kubernetes必备

• 基础架构管理

默认情况下，Kubernetes无法配置基础架构，因此如果节点崩溃，Kubernetes将无法配置新的基础架构。Kubernetes所能做的就是在可用节点内重组Pod。但是，如果没有足够的可用基础架构资源，Kubernetes将无法保证自我修复。这里有一个小秘密；至今为止，市场上的大多数解决方案尚未管理基础架构，或者仅仅在选定的环境中进行配置。

• 自我修复的Kubernetes

几乎每个平台都有望实现自愈。但是，您需要在三个不同的层面进行自我修复：（1）基础架构：取决于上述基础架构的管理能力；（2）Kubernetes组件：这是您必须验证以确认这一点；（3）应用程序级别：默认情况下，由Kubernetes通过自我修复的容器（自愈容器）提供。对于真正可靠的应用程序，您需要在所有层上进行自我修复。

• 多集群支持和集中管理

虽然早期采用Kubernetes的方法可能包括一个或几个静态集群，但随着业务规模的增长和成熟的DevOps实践，就需要将Kubernetes集群视为牛，而不是宠物。大多数组织必须同时运行多个集群，根据需要创建和销毁它们，并为其开发团队启用自助服务。如果对每个群集分别进行管理，则此方案很快就变得难以管理。

• 多环境支持

随着云和软件变得越来越复杂，托管应用程序的位置将越来越影响系统性能。根据451 Research的调查，所有的企业中，超过一半选择混合云和多云作为他们理想的IT架构，大约63％的企业正在使用两个或多个云。这就是为什么您需要一种可在各种环境下工作的解决方案的原因。

• 多站点支持可靠性和容灾

大型企业不会在一个数据中心、区域或云中运行其关键任务应用程序。它们分布在不同的站点，以确保可靠性和容灾。在这种情况下，您的平台必须支持多站点部署，并且能够在多个站点之间协调自动故障转移和恢复过程。

• 集中记录和监控

集中日志记录和监控对于Ops和DevOps团队快速识别并修复基础架构、Kubernetes和应用程序问题至关重要。与很多零碎的视图相比，它提供了单个集成图片。趋势和相关性更容易发现，有助于尽早采取预防或纠正措施。此外，为了安全性和审计，infosec需要一些所有遥测的集中图片。

• 安全

Kubernetes本身具有强大的安全功能特点，但正在寻找可以将这些功能连接到企业系统的提供商。这不仅应包括集群和容器的安全功能（例如TLS，密钥和证书的轮换和管理，AAA和身份管理等），而且具有企业IDM（SAML，OIDC，LDAP）和Kubernetes的RBAC集成能力。

• 第2天操作的完全自动化

该解决方案应处理在集群上的所有管理任务。恢复、还原，更新、升级等等。如果不是自动化的，则需要您自己去做，这很快会让您的资源和预算紧张。

• “开放”开源

开源的主要好处是它开放且灵活，允许用户根据市场需求进行调整。但是，我们看到了一些新的“自以为是的开源​​”产品，这些产品会锁定您。虽然有些将您绑定到特定的基础结构或技术堆栈，但有些则在修改原始的开源技术。尽管后者可能是开源的，但它们特定于该供应商，并且不受社区支持。确保您的平台没有被绑定到特定的技术堆栈或基础架构，从而损害了敏捷性。

• 可配置性

尽管利用供应商支持的Kubernetes平台的整体想法是所有东西都已预先配置，但是一旦冒险进入更高级的用例，您需要能够覆盖参数。由于Kubernetes是一个复杂的多组件系统，因此配置灵活性可能会有所不同，例如，数据科学集群配置会与无状态应用程序或微服务的配置不同。根本就没有那种四海皆准的方法。确保您有权访问主节点和工作节点组件配置，包括交换机，资源请求和限制，操作系统级别的配置等。

• 命令行和API

当您的Kubernetes和与容器相关的用例成熟时，一些团队成员将更喜欢通过命令行（CLI）进行工作。CLI和API支持复杂的自动化和集成方案，包括将Kubernetes集群操作集成到CI / CD管道、扩展、平衡、故障转移和恢复方案等。

• 智能监控和警报

Kubernetes和容器化的应用程序会生成大量原始数据，您必须转换这些原始数据才能了解集群的状况。早期发现和干预对于预防灾难至关重要。如果您无法理解Kubernetes告诉您的内容，那么您就有问题了。通过合并自动智能监视和警报（不会给您充斥不重要的细节），您会从状态、错误、事件和警告等关键信息中受益，从而使您的团队拥有采取行动所需的洞察力。

• 支持多个Kubernetes版本

企业中任何有意义的Kubernetes部署都将包含多个集群和环境，无论是dev、prod、staging、QA环境，还是组织内不同部门和组或不同应用程序使用的环境和集群。希望所有的都维持相同的配置和补丁/ Kubernetes版本级别是不可行的，因此企业Kubernetes解决方案必须能够同时支持多个Kubernetes版本和配置。

• 支持Kubernetes升级和更新

Kubernetes平台由整个堆栈组成。仅Kubernetes每年就有四个主要版本。其他项目也有自己的版本。如何处理更新和升级？故障期怎么办？请注意，尽管有些供应商声称支持升级，但如果您进行更深入的研究，您会发现他们需要（有时甚至是很长时间）停机才能进行集群的重新初始化。

• 24/7支持

最后，随着您的团队开始学习Kubernetes技能，重要的是要有一家提供24/7支持和培训的供应商，以确保您的Kubernetes旅程顺利。

乐于助人

• 对初学者的用户友好型UI

友好的用户界面对刚接触Kubernetes的企业特别有利。它们通过提供方便的下拉菜单简化了大部分部署，确保几乎不可能创建故障集群。这将使您的团队组织在开始构建内部专业知识时迅速上手Kubernetes。

• 与Kubernetes“Essentials”的集成

有很多组件不是Kubernetes的一部分，但是对于Kubernetes用户实现任何有意义的目标来说都是必不可少的。其中包括组件和框架，例如容器覆盖网络提供商、入口控制器、Kubernetes自动缩放器、云原生存储系统、用于不同类型卷的持久卷供应器、GPU集成等。

显然，在迁移到基于Kubernetes的面向未来的架构时，企业需要进行多方面的考虑。不幸的是，并不是所有的企业在研究其选择方案时都完全理解他们的要求。如果您考虑一下大多数情况下很新的Kubernetes和云原生技术，这并不让人感到很意外。

无论您选择Kublr的企业级平台还是其他替代产品，我们希望该清单将帮助您浏览生态系统并找到适合您需求的平台。

作者：Oleg Chunikhin

原文地址：https://thenewstack.io/a-no-bs-checklist-for-kubernetes/