Skip to content

Anatomía de una Distribución de Kubernetes de Próxima Generación

📝 Traducción de (https://docs.rke2.io/architecture)

Resumen de la Arquitectura

Con RKE2, aplicamos las lecciones aprendidas al desarrollar y mantener nuestra distribución ligera de Kubernetes, K3s, para construir una distribución lista para empresas con la misma facilidad de uso de K3s. Esto significa que RKE2 es, en su forma más simple, un único binario que se instala y configura en todos los nodos que participarán en el clúster de Kubernetes. Una vez iniciado, RKE2 puede arrancar y supervisar agentes adecuados para cada nodo mientras obtiene el contenido necesario desde la red.

Rancher and RKE

RKE2 combina varias tecnologías de código abierto para hacerlo funcionar:

Todos estos componentes, excepto el Controlador de Ingress NGINX, están compilados y vinculados de forma estática con Go+BoringCrypto.

Ciclo de Vida del Proceso

Inicio del Contenido

RKE2 obtiene los binarios y manifiestos necesarios para ejecutar nodos servidor y agente desde la imagen de tiempo de ejecución de RKE2. Esto significa que RKE2 busca por defecto en /var/lib/rancher/rke2/agent/images/*.tar la imagen rancher/rke2-runtime (con una etiqueta que correlacione con la salida de rke2 --version) y, si no se encuentra, intenta descargarla desde la red (es decir, Docker Hub). Luego, RKE2 extrae /bin/ de la imagen y lo aplana en /var/lib/rancher/rke2/data/${RKE2_DATA_KEY}/bin, donde ${RKE2_DATA_KEY} representa una cadena única que identifica la imagen.

Para que RKE2 funcione correctamente, la imagen de tiempo de ejecución debe proporcionar, como mínimo:

  • containerd (la CRI)
  • containerd-shim (shim envuelve tareas runc y no se detiene cuando containerd lo hace)
  • containerd-shim-runc-v1
  • containerd-shim-runc-v2
  • kubelet (el agente del nodo Kubernetes)
  • runc (el tiempo de ejecución OCI)

Las siguientes herramientas operativas también son proporcionadas por la imagen de tiempo de ejecución:

  • ctr (mantenimiento e inspección de bajo nivel de containerd)
  • crictl (mantenimiento e inspección de bajo nivel de CRI)
  • kubectl (mantenimiento e inspección del clúster de Kubernetes)
  • socat (necesario por containerd para el reenvío de puertos)

Después de extraer los binarios, RKE2 extrae gráficos (charts) de la imagen en el directorio /var/lib/rancher/rke2/server/manifests.

Inicializar el Servidor

En el motor integrado de K3s, los servidores son procesos de agente especializados, lo que significa que el siguiente inicio se diferirá hasta que el tiempo de ejecución del contenedor del nodo haya comenzado.

Preparar Componentes
kube-apiserver

Descargar la imagen de kube-apiserver, si no está presente, y ejecutar una goroutine para esperar a etcd y luego escribir la definición del pod estático en /var/lib/rancher/rke2/agent/pod-manifests/.

kube-controller-manager

Descargar la imagen de kube-controller-manager, si no está presente, y ejecutar una goroutine para esperar a kube-apiserver y luego escribir la definición del pod estático en /var/lib/rancher/rke2/agent/pod-manifests/.

kube-scheduler

Descargar la imagen de kube-scheduler, si no está presente, y ejecutar una goroutine para esperar a kube-apiserver y luego escribir la definición del pod estático en /var/lib/rancher/rke2/agent/pod-manifests/.

Iniciar el Clúster

Ejecutar un servidor HTTP en una goroutine para escuchar a otros servidores/agentes del clúster y luego inicializar o unirse al clúster.

etcd

Descargar la imagen de etcd, si no está presente, y ejecutar una goroutine para esperar a kubelet y luego escribir la definición del pod estático en /var/lib/rancher/rke2/agent/pod-manifests/.

helm-controller

Ejecutar la goroutine para iniciar el helm-controller integrado después de esperar que kube-apiserver esté listo.

Inicializar Agente

El punto de entrada del proceso del agente. Para procesos de servidor, el motor integrado de K3s invoca esto directamente.

Tiempo de Ejecución del Contenedor
containerd

Iniciar el proceso containerd y escuchar la terminación. Si containerd finaliza, el proceso rke2 también finalizará.

Agente del Nodo
kubelet

Iniciar y supervisar el proceso kubelet. Si kubelet finaliza, rke2 intentará reiniciarlo. Una vez que kubelet esté en ejecución, iniciará cualquier pod estático disponible. Para servidores, esto significa que etcd y kube-apiserver comenzarán, sucesivamente, permitiendo que los componentes restantes iniciados a través de pod estático se conecten a kube-apiserver y comiencen su procesamiento.

Gráficos del Servidor

En nodos servidor, el helm-controller puede ahora aplicar al clúster cualquier gráfico encontrado en /var/lib/rancher/rke2/server/manifests.

  • rke2-canal.yaml o rke2-cilium.yaml (daemonset, bootstrap)
  • rke2-coredns.yaml (deployment, bootstrap)
  • rke2-ingress-nginx.yaml (deployment)
  • rke2-kube-proxy.yaml (daemonset, bootstrap)
  • rke2-metrics-server.yaml (deployment)

Proceso Daemon

El proceso RKE2 ahora correrá indefinidamente hasta que reciba un SIGTERM o SIGKILL o si el proceso containerd finaliza.