¿Cuál es la forma correcta de modificar kubelet y la configuración del plano de control con kubeadm?

Question

Instalé un clúster de Kubernetes (v1.20.0) con 3 maestros y 3 nodos usando kubeadm inity kubeadm join, todo en Ubuntu 20.04. Ahora necesito actualizar la configuración y

• Agregue --cloud-provider=externalel indicador de inicio de kubelet en todos los nodos que voy a usarcontrolador-vsphere-csi
• Cambiar --service-cidrdebido a los requisitos de la red.

Sin embargo, no estoy del todo seguro de cuál es la forma correcta de realizar estos cambios.

kubelet

Al mirar /etc/systemd/system/kubelet.service.d/10-kubeadm.confhay una referencia, /etc/default/kubeletpero se considera un último recurso y se recomienda actualizar .NodeRegistration.KubeletExtraArgsen su lugar:

...
# This is a file that the user can use for overrides of the kubelet args as a last resort. Preferably, the user should use
# the .NodeRegistration.KubeletExtraArgs object in the configuration files instead. KUBELET_EXTRA_ARGS should be sourced from this file.
EnvironmentFile=-/etc/default/kubelet
...

¿Dónde está esto .NodeRegistration.KubeletExtraArgsy cómo lo cambio para todos los nodos del clúster?

plano de control

Por lo que tengo entendido, el apiserver y el controlador-administrador se ejecutan como pods estáticos en cada maestro y leen su configuración desde /etc/kubernetes/manifests/kube-<type>.yaml. Mi primer pensamiento fue realizar los cambios necesarios en estos archivos; sin embargo, de acuerdo con los documentos de Kubernetes enactualizar un clúster kubeadm, kubeadm:

* Fetches the kubeadm ClusterConfiguration from the cluster.
* Optionally backups the kube-apiserver certificate.
* Upgrades the static Pod manifests for the control plane components.

Debido a que cambié los manifiestos manualmente, no se actualizan en ClusterConfiguration ( kubectl -n kube-system get cm kubeadm-config -o yaml), ¿mis cambios sobrevivirían a una actualización de esta manera? Supongo que también podría editar la configuración del clúster manualmente, kubeadm edit cm ...pero esto parece propenso a errores y es fácil olvidar cambiarlo cada vez.

Según los documentos, hay una manera depersonalizar la configuración del plano de controlpero eso parece ser sólo cuando se instala el clúster por primera vez. Por ejemplo, kubeadm config print init-defaultscomo sugiere el nombre, solo dame los valores predeterminados, no lo que se está ejecutando actualmente en el clúster. El intento de extraer la configuración del clúster kubectl -n kube-system get cm kubeadm-config -o yamly ejecutarlo kubeadm init --config <config>falla en todos los sentidos porque el clúster ya está inicializado.

Kubeadm puede ejecutarseplano de control de fase inicialupload-configque actualiza los manifiestos del pod estático pero deja intacta la configuración del clúster, por lo que también necesitaría ejecutar la fase.

Con base en lo anterior, el flujo de trabajo parece ser

• Extraiga la configuración del clúster kubeadm -n kube-system get cm kubeadm-configy guárdela en un archivo yaml
• Modifique el archivo yaml con los cambios que necesite
• Aplicar cambios conkubeadm init phase control-plane all --config <yaml>
• Cargar configuración modificadakubeadm init phase upload-config all --config <yaml>
• Distribuya el archivo yaml modificado a todos los maestros.
• Para cada maestría, aplicar conkubeadm init phase control-plane all --config <yaml>

Lo que me preocupa aquí es la aparente desconexión entre los manifiestos del pod estático y ClusterConfiguration. Los cambios no se realizan con mucha frecuencia, por lo que es bastante fácil olvidar que cambiar en un lugar también requiere cambios en el otro, manualmente.

¿No hay forma de actualizar la configuración de kubelet y del plano de control que garantice la coherencia entre los componentes de Kubernetes y kubeadm? Todavía soy bastante nuevo en Kubernetes y haymuchode documentación al respecto, así que lo siento si me he perdido algo obvio aquí.

Answer 1

Intentaré responder a ambas preguntas.

---

1. Agregue --cloud-provider=indicador de inicio de kubelet externo en todos los nodos

¿Dónde está este .NodeRegistration.KubeletExtraArgs y cómo lo cambio para todos los nodos del clúster?

KubeletExtraArgs¿Hay argumentos y parámetros admitidos por kubelet? estan documentadosaquí. Debe utilizar el kubeletcomando con las banderas adecuadas para poder modificarlo. Además, tenga en cuenta que la bandera que está a punto de usar se eliminará en k8s v1.23:

--cloud-provider stringEl proveedor de servicios en la nube. Establezca una cadena vacía para ejecutar sin proveedor de nube. Si está configurado, el proveedor de la nube determina el nombre del nodo (consulte la documentación del proveedor de la nube para determinar si se utiliza el nombre de host y cómo). (OBSECUTIVO: se eliminará en 1.23, a favor de eliminar el código del proveedor de la nube de Kubelet).

EDITAR:

Para abordar mejor su pregunta sobre:.NodeRegistration.KubeletExtraArgs

Estos también son elementos de laarchivo de configuración de inicio de kubeadm:

Es posible configurar kubeadm initcon un archivo de configuración en lugar de indicadores de línea de comando, y es posible que algunas funciones más avanzadas solo estén disponibles como opciones del archivo de configuración. Este archivo se pasa usando la --configbandera y debe contener una ClusterConfiguration estructura y, opcionalmente, es posible que en algunos casos no se permitan más estructuras separadas por ---\nla mezcla con otras banderas.--config

También puede encontrar más detalles sobre elOpciones de registro de nodoasí como más información sobre los campos y uso de la configuración.

Además, tenga en cuenta que:

KubeletExtraArgspasa a través de argumentos adicionales al kubelet. Los argumentos aquí se pasan a la línea de comando de kubelet a través del archivo de entorno.

kubeadm escribe en tiempo de ejecución para kubelet en el origen. Esto anula la configuración genérica de nivel base en kubelet-config-1.X. ConfigMap

Las banderas tienen mayor prioridad al analizar. Estos valores son locales y específicos del nodo en el que se ejecuta kubeadm.

EDITAR2:

kubeadm initSe supone que debe usarse solo una vez al crear un clúster, siempre que lo use con banderas o un archivo de configuración. No puede cambiar las configuraciones ejecutándolas nuevamente con valores diferentes.AquíEncontrará información sobre kubeadm y su uso. Una vez que se configura el clúster, se debe eliminar kubeadm y realizar cambios directamente en los manifiestos del pod estático.

---

2. Cambie --service-cidr debido a los requisitos de la red.

Esto es más complicado. Podrías intentar hacer esto de manera similar comoaquíoaquípero ese enfoque es propenso a errores y más bien no se recomienda.

La forma más factible y segura sería simplemente recrear el clúster con kubeadm resety kubeadm init --service-cidr. La opción de cambiar automáticamente los CIDR ni siquiera se esperaba desde la perspectiva de Kubernetes. Entonces en resumen, elreinicio de kubeadmes el camino a seguir aquí.

Answer 2

Con respecto a

Entiendo que KubletExtraArgs hace referencia a los argumentos de la línea de comando de kubelet, lo que no entiendo es dónde está este atributo y cómo puedo modificarlo.

múltiples fuentes comoÉsteapuntar a agregar a

/etc/systemd/system/kubelet.service.d/10-kubeadm.conf

líneas como por ejemplo

Environment="KUBELET_EXTRA_ARGS=--pod-manifest-path=/etc/kubelet.d/"

para configurar el entorno para un directorio personalizado para pods estáticos aquí, por ejemplo, en lugar de usar cli con

kubelet --pod-manifest-path=/etc/kubelet.d

como sugiere en los documentos.

Si busca en Google, $KUBELET_EXTRA_ARGSencontrará muchos ejemplos relacionados con el 10-kubeadm.confarchivo antes mencionado.