✅ Stages 4 & 5 — Validation & Validating Admission

Schema Validation

After mutation, the API server validates the final object against the OpenAPI schema registered for that resource version. For CRDs this is the schema block in the CRD spec; for built-in types it's compiled Go validation.

# CEL validation in a CRD (Kubernetes 1.25+)
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
spec:
  versions:
    - name: v1
      schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                replicas:
                  type: integer
                  minimum: 1
                  maximum: 100
                maxUnavailable:
                  type: integer
              x-kubernetes-validations:
                # CEL rule: maxUnavailable must be <= replicas
                - rule: "self.maxUnavailable <= self.replicas"
                  message: "maxUnavailable cannot exceed replicas"

Validating Admission Webhooks

All matching ValidatingWebhookConfigurations are called in parallel. Every one must return allowed: true; a single rejection (or timeout) aborts the request with the webhook's rejection message.

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: policy-enforce
webhooks:
  - name: pods.policy.example.com
    admissionReviewVersions: ["v1"]
    clientConfig:
      service:
        name: policy-webhook
        namespace: policy-system
        path: /validate-pods
    rules:
      - operations: ["CREATE", "UPDATE"]
        apiGroups: [""]
        apiVersions: ["v1"]
        resources: ["pods"]
    failurePolicy: Fail     # reject if webhook is unreachable
    timeoutSeconds: 5
    sideEffects: None

Stage 6 — Persist to etcd

The validated, mutated object is serialized and written atomically to etcd using a Compare-And-Swap (CAS) on the resource version to prevent lost updates. The etcd revision becomes the new resourceVersion field.

# The etcd key path structure:
# /registry/{group}/{resource}/{namespace}/{name}
# Examples:
# /registry/apps/deployments/default/nginx
# /registry/core/pods/kube-system/coredns-abc123
# /registry/rbac.authorization.k8s.io/clusterroles/cluster-admin

# Inspect etcd directly (from a control-plane node):
ETCDCTL_API=3 etcdctl \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/peer.crt \
  --key=/etc/kubernetes/pki/etcd/peer.key \
  get /registry/apps/deployments/default/nginx --print-value-only \
  | auger decode    # auger decodes protobuf → YAML

Stage 7 — Watch Cache & Event Propagation

The API server maintains an in-memory watch cache that mirrors recent etcd history. Controllers connect with Watch requests and receive a stream of ADDED / MODIFIED / DELETED events without hitting etcd for every event.