Photo by Mabel Amber
En la entrada anterior k3d: desplegar un clúster de Kubernetes como código incluí un registry en el despliegue del clúster con k3d.
En esta entrada veremos cómo usarlo para desplegar aplicaciones en el clúster.
Ya he hablado de k3d otras veces en el blog; del mismo modo que kind permite desplegar Kubernetes en Docker: cada nodo del clúster se ejecuta en un contenedor.
k3d hace lo mismo pero en vez de Kubernetes vanilla, usa la distribución ligera de Kubernetes, k3s.
Este fin de semana he actualizado la documentación del repositorio onthedock/k8s-devops en lo relativo a k3d y he aprovechado para explorar un par de cosas nuevas: deplegar el clúster de forma declarativa (como código) y el uso del registry interno en k3s.
En este artículo me centro en la primera parte: el despliegue del clúster como código.
Después de un tiempo focalizado casi exclusivamente en aprender Go, hoy he vuelto a mis raíces: Kubernetes.
En el repositorio onthedock/vagrant tengo los scripts que me permiten desplegar varias máquinas virtuales usando Vagrant, instalar K3s y configurar un clúster de Kubernetes con (en este momento) un nodo master y dos workers. Como parte de la automatización, también despliego Longhorn como storageClass .
Hoy he testeado con éxito el despliegue de ArgoCD y Gitea en el clúster, dando un pasito adelante para desplegar una plataforma completa de desarrollo sobre Kubernetes.
Tras solucionar los problemas con Vagrant al actualizar a PoP_OS! 22.04 (basada en Ubuntu 22.04), encuentro otro problema relacionado también con SSH :(
k3sup, el instalador de clústers de Kubernetes usando k3s, no puede conectar con las máquinas virtuales basadas en la imagen ubuntu/jammy64 (la nueva versión de Ubuntu 22.04).
Estaba leyendo las nuevas entradas en el foro de Kubernetes y me he encontrado con Getting Pod ID and container ID of a container when it restarts.
La pregunta es cómo obtener el identificador de un pod (y de un contenedor dentro del pod) cuando éste se reinicia. Lo curioso -al menos para mí- es que esa información es necesaria porque hay otro pod que monitoriza el primero que necesita esta información (supondo que para identificar el pod monitorizado).
A raíz de la entrada anterior GitOps con ArgoCD - Instalación y acceso a la consola he visto que la versión desplegada en el clúster de laboratorio era la 2.2.1, mientras que la versión actual es la 2.2.5.
Antes de actualizar, al tratarse de una versión patch release, no es necesario tener en cuenta ninguna consideración especial, según se indica en la documentación oficial Upgrading > Overview.
Sin embargo, aplicando el fichero correspondiente a la última versión estable, se sobreescriben los ConfigMaps de configuración, por lo que las modificaciones realizadas se pierden; en mi caso, la configuración del modo inseguro necesario para el acceso a través de un ingress.
Como solución temporal, se puede aplicar de nuevo el fichero con el ConfigMap y ejecutar kubectl -n argocd rollout restart deploy argocd-server.
GitOps es una forma de gestionar los clústers de Kubernetes y el proceso de application delivery, según consta en la definición que hacen los inventores del término, el equipo de Weave.works en What is GitOps?.
El concepto gitOps proporciona un modelo operativo en el que el estado deseado del clúster (y de las aplicaciones desplegadas en él) se encuentra definido de forma declarativa en un repositorio Git.
Un agente se encarga de reconciliar el estado deseado (en Git) con el estado real (en Kubernetes), considerando -en general- como fuente de la verdad el contenido del repositorio.
Aunque Weave.works desarrolló inicialmente Flux (ahora forma parte de la CNCF), en este post hablaré de ArgoCD. Hay otras herramientas con las que implementar GitOps, pero sin duda Flux y ArgoCD son las referencias indiscutibles.
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í.
Hace unas entradas, en
Crear usuarios en Kubernetes (y en K3s), escribía sobre cómo generar nuevos usuarios con acceso al clúster de Kubernetes usando un fichero kubeconfig.
El método descrito implicaba extraer fuera del clúster el certificado privado de la entidad certificadora (CA) de Kubernetes, lo que no me parecía la mejor solución.
Desde Kubernetes 1.19 existe un nuevo recurso en la API, el CertificateSigningRequest, que permite firmar certificados para proporcionar acceso (por ejemplo) al clúster.
En esta entrada se describe cómo aprovechar esta nueva funcionalidad para dar acceso a un usuario usando un certificado firmado por la CA del clúster.
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.
