k3sup es una herramienta que permite instalar clústers de Kubernetes basados en K3s en menos de un minuto. Pero acabo de descubrir que además, también permite actualizar el clúster.
Actualizar k3s con k3sup
- post
- Xavi Aznar
Photo by Mabel Amber
k3sup es una herramienta que permite instalar clústers de Kubernetes basados en K3s en menos de un minuto. Pero acabo de descubrir que además, también permite actualizar el clúster.
El script automatiza el proceso completo de creación de un usuario en Kubernetes. Como el proceso es algo diferente en K3s, esta entrada se centra más en este caso especial.
En Kubernetes no existe el concepto de usuario; sólo se confía en quien presente un certificado firmado por la CA del clúster.
Para obtener los certificados de la CA, lo más sencillo es acceder a un nodo server; los certificados (ca.cert
y ca.key
) se encuentran en /etc/kubernetes/pki/
.
Existe otra opción que pasa por generar un objeto
CertificateSigningRequest
para firmar el certificado de usuario.
El proceso implica generar un certificado al usuario, solicitar que lo firme la Certificate Authority del clúster y después autenticarse con él.
Para poder autenticarse en el clúster, necesitamos configurar un cliente, por ejemplo creando un fichero kubeconfig
para kubectl.
Finalmente, el nuevo usuario debe estar autorizado a realizar algunas acciones en el clúster; para ello definiremos un conjunto de permisos en un Role o un ClusterRole y lo asociaremos al usuario mediante un RoleBinding (o un ClusterRoleBinding).
En la entrada anterior, tenemos un fichero Vagrantfile
que permite provisionar máquinas virtuales a partir de la imagen base seleccionada. Las máquinas generadas están configuradas a nivel de hipervisor, con los recursos de CPU y memoria elegidos. También se ha configurado el nombre de la máquina virtual y se ha establecido una IP estática. También se han deshabilitado algunos aspectos específicos de Vagrant, como las carpetas compartidas o la comprobación de actualizaciones de la imagen base.
En esta segunda parte nos centramos en la configuración del sistema operativo aprovechando la capacidad de Vagrant de ejecutar scripts en las máquinas creadas.
Desde mis inicios con Kubernetes, una de las cosas más pesadas del proceso de creación del clúster (para mí) ha sido el tener que desplegar y configurar las máquinas que formarán el clúster.
En esta entrada explico algo de mi relación histórica con Vagrant y el proceso de automatización que estoy siguiendo para desplegar clústers locales (no cloud) en mi laboratorio.
Uno de los problemas abiertos de Kubernetes es la gestión de los secretos; es decir, aquella información sensible que, al menos de momento, se guarda en texto plano y cuya única medida de “seguridad” consiste en codificarla en base64.
Tal y como se indica en el README.md
de Sealed Secrets, puedes gestionar toda la configuración de Kubernetes en Git… excepto los Secrets, precisamente porque los Secrets no son seguros…
Con el auge de metodologías como GitOps, el problema es mayor, ya que los desarrolladores no tienen acceso directo al clúster y todo debe desplegarse automáticamente desde Git.
Una de las soluciones al problema viene del equipo de Bitnami-Labs con SealedSecrets.
En la entrada anterior indicaba la idea general en la que estoy trabajando para implementar una solución funcional de documentación como código.
Reducida a su mínima expresión, la prueba de concepto lo que tiene que mostrar es la velocidad a la que se puede ir actualizando la documentación si se sigue el mismo proceso -y herramientas- de desarrollo a las que está acostumbrado el equipo de proyecto.
No se trata de crear un sistema listo para producción, sino de mostrar algo que funcione ™ más o menos, como funcionaría la solución final.
Una de las claves del éxito de un proyecto es proporcionar una buena documentación. En los proyectos open source cada vez se da más importancia a tener documentación de calidad y completamente actualizada.
En el pasado -aunque tristemente, sigue siendo una práctica muy habitual- la documentación se dejaba como una tarea a realizar una vez el proyecto estuviera prácticamente completado, antes de la entrega al cliente. El problema de esta aproximación es que los proyectos suelen encontrar problemas que hace que las fechas previstas inicialmente no se cumplan, o que se cumplan artificialmente entregando sin haber completado tareas como por ejemplo, la documentación.
Con la introducción de las metodologías ágiles, en cada tarea que se crea en el backlog se incluye la documentación como parte del criterio de aceptación, explícita o implícitamente.
En vez de generar un documento enorme, se suele optar por formatos ligeros como markdown, como paso previo a generar una versión web para el usuario final. Gracias a herramientas como pandoc, también es fácil generar documentación final en prácticamente cualquier otro formato que se requiera, como los habituales Microsoft Word o PDF.
De esta forma, el equipo de desarrollo trabaja en paralelo en la creación de nuevas funcionalidades a la vez que las documenta.
En la entrada anterior, Revisión de la Helm chart oficial de Gitea, analicé la chart oficial de Gitea. Después de revisarla, en esta entrada explico cómo instalar Gitea a partir de la chart oficial usando Helm.