入学 Webhooks

Admission Webhooks 是接收入场请求的 HTTP 回调，处理这些请求并返回入场响应。

Kubernetes 提供以下类型的准入 webhook：

  • 变更Admission Webhook：这些Webhook可以在对象创建或更新时对其进行变更，在对象被存储之前。它可以用于在资源请求中设置字段的默认值，例如，在用户未指定的Deployment字段中。还可以用于注入边车容器。

  • 验证入场 Webhook：这些可以在对象被创建或更新时进行验证，确保其在存储之前有效。它允许比纯基于模式的验证更复杂的验证，例如跨字段验证和容器镜像白名单。

默认情况下，apiserver 并不会对 webhook 进行身份验证。然而，如果您想要对客户端进行身份验证，您可以配置 apiserver 使用基本身份验证、令牌或证书来对 webhook 进行身份验证。您可以在这里找到详细步骤。

在入场Webhook中处理资源状态

理解原因：

变异 admission Webhooks

变更的 Admission Webhooks 主要旨在拦截和修改与对象的创建、修改或删除相关的请求。尽管它们具备修改对象规格的能力，但直接更改对象的状态并不被视为标准做法，通常会导致意外结果。

// MutatingWebhookConfiguration 允许对对象进行修改。
// 然而，直接修改状态可能会导致意外行为。type MutatingWebhookConfiguration struct {
    ...
}

设置初始状态

对于那些深入研究自定义资源的自定义控制器的人来说，了解设置初始状态的概念是至关重要的。这个初始化通常在控制器内部进行。当控制器通过监视机制识别到其管理资源的新实例时，它有权为该资源分配一个初始状态。

// 自定义控制器的调整函数可能看起来像这样：
func (r *ReconcileMyResource) Reconcile(request reconcile.Request) (reconcile.Result, error) {
    // ...
    // 在发现新实例时，设置初始状态
    instance.Status = SomeInitialStatus
    // ...
}

状态子资源

深入研究 Kubernetes 自定义资源时，可以明确区分 spec（描述期望状态）和 status（展示观察到的状态）。为自定义资源定义（CRD）启用 /status 子资源，将 status 和 spec 分开，各自分配给相应的 API 端点。这样的分离确保了用户引入的变更，例如修改 spec，以及系统驱动的更新，如状态变化，能够保持明确的区分。在修改 spec 操作期间利用变更的 webhook 来调整状态，可能无法如预期那样顺利进行，这要归功于这种隔离。

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: myresources.mygroup.mydomain
spec:
  ...
  subresources:
    status: {} # 启用 /status 子资源

结论

虽然某些边缘场景可能允许变更的 webhook 无缝地修改状态，但走这条道路并不是普遍认可或推荐的策略。将状态更新的责任交给控制器逻辑仍然是最被提倡的方法。