Kubernetes 提供了很多好处：拥有大量参与者的庞大生态系统、自我修复能力等。不过天下没有免费的午餐。它也有缺点，其中最主要的是它的复杂性和运营成本。
然而，我使用 Kubernetes 的次数越多，我就越认为它最重要的资产是可扩展性。如果您需要平台默认不提供的东西，可以选择自己开发并集成。在这篇文章中，我想列出这样的扩展点。
库伯内斯 101
很多关于 Kubernetes 的讲解都集中在架构上。我相信他们进入了太多的细节而错过了大局。在这里，我只想强调基本概念。
在最基本的层面上，Kubernetes 只是一个能够运行容器镜像的平台。它将其配置存储在分布式存储引擎中，etcd. 此配置中最重要的部分专用于对象的所需状态。例如，您仅在使用kubectl命令行安排 pod 时更新此状态。
其他组件，称为控制器，观察配置更改并读取所需状态。然后，他们尝试协调理想状态与实际状态。这不是革命性的：Puppet 基于相同的控制循环方法，AFAIK，Chef。通常，控制器管理单一类型的对象，例如，DeploymentController管理部署。
制作通用工具背后的想法是遵循帕累托定律：用 20% 的努力解决 80% 的问题。不幸的是，工具越通用，用户群越广，定制剩余 20% 的工作就越多。
Kubernetes 设计者将此问题视为广泛采用的最关键障碍。因此，Kubernetes 提供了许多扩展点。
可扩展模型
在上面的部分中，我提到了安排 pod。Pod 是 Kubernetes 中开箱即用的众多对象之一。其他对象包括部署、作业、服务等。
一些解决方案很容易适合这个模型。例如，可以轻松创建三个 Hazelcast pod 的部署。它开箱即用：pod 将通过网络进行多播，相互发现并形成一个集群。
其他解决方案不是那么同质。在KIP-500之前，Kafka 会依赖 Zookeeper。At 集群由至少三个 Zookeeper 节点和任意数量的 Kafka 节点组成。Kubernetes 使得在同一个 pod 上部署多个镜像成为可能。然而，如果所有必需的组件都在同一个 pod 上并且 pod 发生故障，那将毫无意义。我们应该将一个常规组件映射到一个 pod。
在这种情况下，我们需要一个描述架构的全功能 Kubernetes 清单。由于不同的要求，我们需要使其可配置。Kubernetes 的生态系统提供了多种替代方案来解决这个问题：Kustomize和Helm count 是最受欢迎的解决方案之一。但两者都不能在所需的抽象级别上工作，即 Kafka 集群。
因此，Kubernetes 允许设计一个新的Kafka对象。这种自定义对象称为CRD。
必填标题
符合以下.
REST API 的组名 -/apis//
REST API 的复数名称 -/apis///
用于 CLI 和显示的单数名称
在清单中使用
可以是Cluster或Namespaced。Cluster资源在集群范围内声明，每个集群可以有一个资源；Namespaced资源可以是多个，需要在一个命名空间下；默认，default
可以启用/禁用版本
最新版本必须标记为存储版本
上面的命令用新Foo类型更新了数据模型并创建了一个Foo对象。但在幕后，我们只etcd通过 Kubernetes API 存储数据。在我们启动一个监视新对象并对其进行操作的控制器之前，什么都不会发生。请注意，管理 CRD 的控制器的名称是operator。
可扩展验证
可以运行第三方工作负载的平台的一个普遍问题是只允许经过审查的工作负载。一些工作负载可能会消耗太多资源；其他人可能是恶意的。
下面是两个具体的场景：
作为集群操作员，您希望管理集群的有限物理资源（CPU/内存）并在所有 pod 之间共享它们。为此，您希望强制每个 pod 描述其资源需求。开发人员通过设置request和limits属性来实现这一点。你想禁止没有它们的 pod。
作为具有安全意识的操作员，您希望防止特权升级。它不应该改变 pod 的最终行为。您想将 添加allowPrivilegeEscalation=false到每个 pod。
虽然可以通过“构建”管道管理这两种情况，但 Kubernetes 提供了一种开箱即用的解决方案。
正如我在上面解释的那样，Kubernetes 存储配置是etcd在控制器观察变化并根据它们采取行动的时候。为了防止不必要的行为，最安全的方法是验证更改配置的有效负载；这是准入控制器的角色。