El 23 de septiembre a las 20:00 MSK, Sergey Bondarev ofrecerá un seminario web gratuito titulado "", donde explicará cómo se prepara Kubespray para que sea rápido, eficiente y resistente a fallos.
Sergey Bondarev comentará la diferencia entre la versión original y nuestro fork:
Diferencia entre la versión original y nuestro fork.
Quienes ya se han encontrado con Kubespray probablemente se preguntan por qué comparo kubeadm con Kubespray, ya que Kubespray se utiliza para crear clústeres y, de hecho, invoca kubeadm, y a primera vista parece un script para instalar paquetes y realizar arrancadas automatizadas.
Pero no siempre fue así, originalmente Kubespray instalaba todos los componentes por sí mismo:
- reunía el clúster etcd;
- instalaba kubelets, generaba certificados, configuraciones y tokens de acceso para los pods estáticos del plano de control y otros componentes auxiliares;
- creaba cuentas de servicio para los nodos de trabajo y las conectaba al clúster.
Pero el año pasado eliminaron esta funcionalidad, dejando solo kubeadm, que en ese momento no era muy bueno. Me sentí decepcionado y creé mi propio fork, en el cual mantuve el modo clásico de instalación, y ahora mantengo este fork actualizado, eligiendo commits del Kubespray original. A la vez, mejorando el modo clásico para adaptarlo a los nuevos cambios.
Al final, la diferencia entre los clústeres creados por mi fork y el original es kube-proxy y la duración de los certificados.
En mi fork, todo permaneció como antes: kube-proxy se ejecuta como un pod estático, los certificados se emiten por 100 años.
En Kubeadm, kube-proxy se ejecuta como un daemonset, y los certificados se emiten por 1 año y deben ser renovados periódicamente. Kubeadm finalmente aprendió a hacerlo con un solo comando.
La diferencia es pequeña, y en la actualidad utilizamos ambas opciones.
Características (desventajas) en la explotación industrial:
El escenario es universal, por lo tanto, no es muy rápido. El propio se puede acelerar significativamente, eliminando verificaciones y ejecutándose desde una imagen lista.
El escenario es complicado, hay lugares ilógicos, un pesado legado. La instalación de controladores adicionales y software a través de Kubespray es buena para la formación y las pruebas. En un entorno de producción, depender de Kubespray no es una idea muy sensata, además, la actualización del software se realiza mediante el método "lo eliminé - hice uno nuevo", lo que significa una pausa en el servicio.
Solo se pueden agregar nodos de trabajo, hay algunos matices con los maestros relacionados con los certificados, y el escenario no aborda todos los problemas posibles que pueden surgir.
Por ejemplo, tuve un problema con kubeadm, cuando fallaba al agregar el segundo y el tercer maestro, y después de eso, Kubespray realizaba un kubeadm reset en el nodo e intentaba agregar el maestro nuevamente.
El problema fue que para el momento en que ocurrió la falla, la segunda instancia de etcd ya había conseguido registrarse, y como también se eliminaba después del reset, obtuvimos una pesadilla: un clúster de etcd de dos nodos, uno de los cuales fue eliminado y el otro ya no acepta clientes. Al final, el clúster murió antes de nacer.
Código abierto tal como es.
Todo esto y mucho más en el seminario web gratuito "" el 23 de septiembre a las 20:00 MSK.
¡Únete!
Fuente: habr.com
