Estructura Interna y División de Módulos

OpenKruise Rollouts opera como un controlador nativo de Kubernetes, especializado en la orquestación de estrategias de entrega progresiva. El esquema de directorios sigue una convención estándar para desarrolladores de operadores en Go, separando explícitamente la validación de esquemas de la lógica de ejecución:

openkruise-rollouts/
├── cmd/manager/        # Motor de inicialización y registro de hooks
├── pkg/apis/           # Tipado estático y validación de CRDs
├── pkg/controller/     # Reconcilers y manejo de estados de replicación
├── charts/kruise-rollouts/ # Despliegue automatizado vía Helm
└── deploy/             # Manifiestos de namespace y RBAC

Esta arquitectura permite escalar las reglas de negocio sin afectar el ciclo de vida del controlador. El módulo pkg/apis gestiona la conversión entre vertiones, mientras pkg/controller mantiene los bucles de observación contra etcd.

Arranque del Operador y Gestión de Ciclo de Vida

El punto de entrada reside en cmd/manager. Durante la fase de bootstrapping, se configura el cliente HTTP hacia el API server, se activa el cache local para reducir latencia en lecturas repetitivas y se registran los handlers de webhook. Posteriormente, se inician los goroutines dedicados al reconciliation loop de cada recurso personalizado.

Para ejecutar el operador en clústers existentes, se recomienda inyectar las credenciales mediante ServiceAccount y configurar la elecciones de líder para garantizar alta disponibilidad:

# Despliegue directo en modo DaemonSet o Deployment
kubectl apply -f charts/kruise-rollouts/templates/deployment.yaml
# Verificación del pod activo
kubectl get pods -n kruise-system -l app.kubernetes.io/name=kruise-rollouts

Este método delega la gestión de health checks, tolerancias y reinicios automáticos a la capa de scheduling nativa de Kubernetes.

Extensión de la API y Definición de Estrategias

La integración con el clúster requiere la instalación de Custom Resource Definitions que expanden el espacio de nombres de Kubernetes. El manifiesto base debe apuntar al grupo de API oficial del proyecto y habilitar las versiones compatibles:

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: rollouts.apps.kruise.io
spec:
  group: apps.kruise.io
  versions:
    - name: v1alpha1
      served: true
      storage: true
  scope: Namespaced

Con el CRD registrado, las especificaciones de despliegue definen el comportamiento de transición. Los objetos Rollout admiten topologías Blue-Green y Canary, permitiendo ponderación gradual de tráfico y pausas condicionales antes de la promoción completa:

apiVersion: apps.kruise.io/v1alpha1
kind: Rollout
metadata:
  name: canal-canary-frontend
spec:
  type: Canary
  replicas: 3
  revisionHistoryLimit: 5
  templateRef:
    apiVersion: apps/v1
    kind: Deployment
    name: frontend-v2
  canaryUpdateStrategy:
    maxUnavailable: "10%"
    steps:
      - setWeight: 20
      - pause: {duration: 300}
      - setWeight: 50
      - pause: {}