生产 Kubernetes

第 8 章 接入控制 入场控制

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

我们在本书中多次提到，Kubernetes 灵活的模块化设计是其一大优势。 合理的默认设置可以被替换、增强或构建，从而为平台用户提供替代或功能更全面的体验。准入控制是特别受益于这种灵活设计目标的一个领域。准入控制主要是验证和更改向 Kubernetes API 服务器发出的请求，然后再将其持久化到 etcd 中。 这种细粒度地拦截对象并进行控制的能力开辟了许多有趣的用例。 例如：..：

• 确保无法在当前正在删除（处于终止状态）的名称空间中创建新对象

• 强制规定新 Pod 不能以根用户身份运行

• 确保命名空间中所有 Pod 使用的内存总和不超过用户定义的上限

• 确保导入规则不会被意外覆盖

• 为每个 Pod 添加侧载容器（如 Istio）

首先，我们将从高层次来了解接纳链，即所有向 API 服务器发出的请求都要经过的过程。然后，我们将介绍树内控制器。这些是内置的接纳控制器，可以通过 API 服务器的标志启用或禁用，并启用前面的一些用例。其他用例需要更多自定义实现，并通过灵活的 Webhook 模型进行集成。我们将用大量时间深入研究 webhook 模型，因为它提供了最强大、最灵活的选项，可将准入控制集成到集群中。最后，我们将介绍 Gatekeeper，这是一个有见地的开源项目，它实现了 webhook 模型并提供了更多用户友好的功能。

备注

在本章的后面，我们将深入探讨一些用 Go 编程语言编写的代码。 由于 Go 开发速度快、并发基元强、设计简洁，Kubernetes 和许多其他云原生工具都是用 Go 实现的。要理解本章的大部分内容，并不需要了解 Go 语言（但如果你对 Kubernetes 工具感兴趣，我们建议你研究一下 Go 语言），在权衡定制与现成工具的选择时，我们将讨论需要开发技能的权衡。

Kubernetes 准入链

在仔细研究单个控制器的功能和机制之前，我们先来了解一下进出 Kubernetes API 服务器的请求流，如图 8-1 所示。

图 8-1. 接纳链。

当请求到达 API 服务器时，首先要对其进行身份验证和授权，以确保客户端是有效的，并且能够根据任何配置的 RBAC 规则执行所请求的操作（例如，在特定命名空间中创建 Pod）。

在下一阶段，请求会通过图 8-1 中最左侧蓝框所代表的突变接纳控制器。这些控制器可以是内置控制器，也可以是对外部（树外）突变网络钩子的调用（我们将在本章后面讨论）。这些控制器可以在资源进入未来阶段之前修改资源属性。以服务账户控制器（默认情况下已内置并启用）为例，我们来看看这为什么有用。 提交 Pod 时，服务账户控制器会检查 Pod 的规格，确保它已设置serviceAccount (SA) 字段。如果没有，它就会添加该字段，并将其设置为名称空间的default SA。它还会 添加ImagePullSecrets 和卷，允许 Pod访问其服务帐户令牌。

然后，请求会经过模式验证，以确保根据定义的模式提交的对象是有效的。在这里，它会确保设置必填字段等内容。这种排序方式非常重要，因为它意味着我们可以在对象验证之前，在突变接纳控制器中设置字段。 ...