Kubernetes的“无BS”清单

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

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

企业级Kubernetes必备

  • 基础架构管理

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

  • 自我修复的Kubernetes

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

  • 多集群支持和集中管理

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

  • 多环境支持

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

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

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

  • 集中记录和监控

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

  • 安全

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

  • 2天操作的完全自动化

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

  • 开放开源

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

  • 可配置性

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

  • 命令行和API

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

  • 智能监控和警报

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

  • 支持多个Kubernetes版本

企业中任何有意义的Kubernetes部署都将包含多个集群和环境,无论是devprodstagingQA环境,还是组织内不同部门和组或不同应用程序使用的环境和集群。希望所有的都维持相同的配置和补丁/ 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/

 

K8S中文社区微信公众号

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址