Revisando el feed del foro de Kubernetes discuss.kubernetes.io, me llamó la atención la pregunta de user2 Why deployment need replicaset, but daemonset and statefulset don’t need.
Respondí en el foro, pero quiero ampliar la respuesta aquí.
Linux
Photo by Mabel Amber
Tema personalizado de Oh My Zsh
- post
- Xavi Aznar
Oh My Zsh es un framework para gestionar la configuración de Zsh.
Zsh es un shell alternativo a BASH, el shell por defecto de la mayoría de distribuciones Linux. Sin embargo, desde Mac OS Catalina, Zsh se convirtió en el shell del terminal de los Mac. Este hecho, junto a la vistosidad de los temas que pueden aplicarse al prompt en Zsh (en especial, gracias a Oh My Zsh), ha convertido Zsh en un shell cada vez más popular.
Update : Joe Block ha sido tan amable de incluir mi tema de Oh My Zsh en la lista que mantiene en GitHub unixorn/awesome-zsh-plugins.
Automatiza la instalación de Longhorn
- post
- Xavi Aznar
Longhorn es una solución de almacenamiento distribuido de bloques para Kubernetes. Recientemente ha sido incluido en la incubadora de la CNCF.
Longhorn proporciona métricas para Prometheus y es el complemento perfecto para proporcionar almacenamiento a las aplicaciones desplegadas sobre Kubernetes.
En esta entrada automatizamos las instrucciones oficiales de despliegue usando Helm para desplegarlo sobre Kubernetes.
Actualizar k3s con k3sup
- post
- Xavi Aznar
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.
Crear usuarios en Kubernetes (y en K3s)
- post
- Xavi Aznar
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.certyca.key) se encuentran en/etc/kubernetes/pki/.Existe otra opción que pasa por generar un objeto
CertificateSigningRequestpara 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
kubeconfigpara 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).
- Provisionar Kubernetes con Vagrant y K3sup - 1a parte
- Provisionar Kubernetes con Vagrant y K3sup - 2a parte
En la entrada anterior, tenemos un fichero
Vagrantfileque 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.
- Provisionar Kubernetes con Vagrant y K3sup - 1a parte
- Provisionar Kubernetes con Vagrant y K3sup - 2a parte
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.
Documentación como código - 2a parte
- post
- Xavi Aznar
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.
Documentación como código - 1a parte
- post
- Xavi Aznar
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.