Opciones avanzadas y configuración

Por defecto, los certificados en RKE2 caducan en 12 meses.

Si los certificados están caducados o tienen menos de 90 días restantes antes de que caduquen, los certificados se rotan cuando se reinicia RKE2.

Los certificados también se pueden rotar manualmente. Para hacer esto, es mejor detener el proceso rke2-server, rotar los certificados y luego reiniciar el proceso:

Para renovar los certificados de agente, reinicia rke2-agent en los nodos de agente. Los certificados de agente se renuevan cada vez que el agente se inicia.

También es posible rotar un servicio individual pasando la bandera --service, por ejemplo: rke2 certificate rotate --service api-server. Consulta Gestión de Certificados para más detalles.

Cualquier archivo encontrado en /var/lib/rancher/rke2/server/manifests se desplegará automáticamente en Kubernetes de una manera similar a kubectl apply.

Para información sobre desplegar gráficos de Helm utilizando el directorio de manifiestos, consulta la sección sobre Helm.

RKE2 generará un archivo de configuración para containerd en /var/lib/rancher/rke2/agent/etc/containerd/config.toml, utilizando valores específicos para la configuración actual del clúster y del nodo.

Para personalización avanzada, puedes crear una plantilla de configuración de containerd en el mismo directorio:

Containerd 2.0 es compatible hacia atrás con versiones de configuración anteriores, y RKE2 seguirá generando la configuración de versión 2 heredada desde config.toml.tmpl si config-v3.toml.tmpl no se encuentra.

El archivo de plantilla se renderiza en la configuración de containerd utilizando la text/template biblioteca. Consulta ContainerdConfigTemplateV3 y ContainerdConfigTemplate en templates.go para el contenido de la plantilla por defecto. La plantilla se ejecuta con una estructura ContainerdConfig como su valor punto (argumento de datos).

Si estás ejecutando RKE2 en un entorno que solo tiene conectividad externa a través de un proxy HTTP, puedes configurar tus ajustes de proxy en el servicio systemd de RKE2. Estos ajustes de proxy se utilizarán en RKE2 y se pasarán al containerd y kubelet integrados, así como a los pods estáticos del plano de control, etcd y kube-proxy.

Añade las variables necesarias HTTP_PROXY, HTTPS_PROXY y NO_PROXY al archivo de entorno de tu servicio systemd, normalmente:

RKE2 añadirá automáticamente los rangos de IP internos de Pod y Servicio del clúster y el dominio DNS del clúster a la lista de entradas NO_PROXY. Debes asegurarte de que los rangos de direcciones IP utilizados por los nodos de Kubernetes (es decir, las IPs públicas y privadas de los nodos) estén incluidos en la lista NO_PROXY, o que los nodos puedan ser alcanzados a través del proxy.

Si deseas configurar los ajustes del proxy para containerd sin afectar a RKE2 y al Kubelet, puedes prefijar las variables con CONTAINERD_:

Los agentes de RKE2 se pueden configurar con las opciones node-label y node-taint, que añaden una etiqueta y un taint al kubelet. Las dos opciones solo añaden etiquetas y/o taints en el momento del registro, y solo se pueden añadir una vez y no se pueden eliminar después a través de comandos de rke2.

Si deseas cambiar las etiquetas y taints del nodo después de su registro, deberías usar kubectl. Consulta la documentación oficial de Kubernetes para obtener detalles sobre cómo añadir taints y etiquetas de nodo.

Los nodos agente se registran a través de una conexión websocket iniciada por el proceso rke2 agent, y la conexión es mantenida por un equilibrador de carga del lado del cliente que se ejecuta como parte del proceso del agente.

Los agentes se registran con el servidor utilizando la parte secreta del clúster del token de unión, junto con una contraseña específica del nodo generada aleatoriamente, que se almacena en el agente en /etc/rancher/node/password. El servidor almacenará las contraseñas para nodos individuales como secretos de Kubernetes, y cualquier intento posterior debe utilizar la misma contraseña. Los secretos de contraseña de nodo se almacenan en el espacio de nombres kube-system con nombres que utilizan la plantilla <host>.node-password.rke2. Estos secretos se eliminan cuando se elimina el nodo correspondiente de Kubernetes.

Si se elimina el directorio /etc/rancher/node de un agente, el archivo de contraseña debe ser recreado para el agente antes de su inicio, o la entrada eliminada del servidor o del clúster de Kubernetes (dependiendo de la versión de RKE2).

El guion de instalación proporciona unidades para systemd, pero no habilita ni inicia el servicio por defecto.

Al ejecutar con systemd, los registros se crearán en /var/log/syslog y se verán utilizando journalctl -u rke2-server o journalctl -u rke2-agent.

Un ejemplo de instalación con el guion de instalación:

Los gráficos del servidor incluidos con rke2 desplegados durante la inicialización del clúster pueden ser deshabilitados y reemplazados por alternativas. Un caso de uso común es reemplazar el gráfico rke2-ingress-nginx incluido por una alternativa.

Para deshabilitar cualquiera de los gráficos del sistema incluidos, establece el parámetro disable en el archivo de configuración antes de la inicialización. Un ejemplo de deshabilitar todos los gráficos del sistema disponibles es:

En regiones públicas de AWS, para asegurar que RKE2 esté habilitado para la nube y sea capaz de aprovisionar automáticamente ciertos recursos en la nube, configura RKE2 con:

Al instalar RKE2 en regiones clasificadas (como SC2S o C2S), hay algunos requisitos previos adicionales de los que estar al tanto para asegurar que RKE2 sepa cómo y dónde comunicarse de forma segura con los puntos finales de AWS apropiados:

Las siguientes opciones están disponibles bajo el subcomando server para RKE2. Las opciones permiten especificar solicitudes y límites de CPU para los componentes del plano de control dentro de RKE2.

Los valores son una lista delimitada por comas de [controlplane-component]-(cpu|memory)=[desired-value]. Los valores posibles para controlplane-component son:

Así, un ejemplo de configuración puede verse así:

Los valores de unidad para CPU/memoria son idénticos a las unidades de recursos de Kubernetes (Ver: Límites de Recursos en Kubernetes).

Las siguientes opciones están disponibles bajo el subcomando server para RKE2. Estas opciones especifican el montaje de directorios desde el sistema de archivos del nodo en el componente de pod estático que corresponde al nombre prefijado.

Las siguientes opciones de configuración están disponibles para el subcomando server de RKE2. Estas opciones especifican variables de entorno adicionales en formato estándar, es decir, KEY=VALUE para el componente de pod estático que corresponde al nombre con prefijo.

Se pueden especificar múltiples variables de entorno para el mismo componente pasando los valores de la bandera como un array en el archivo de configuración.