Photo by Mabel Amber
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).
La solución para el Error en Vagrant tras actualizar a Pop_Os! 22.04 es la instalación de una versión concreta del software, en este caso, la 2.2.19.
TL,DR; Solución en Vagrant up error on Ubuntu 22.04: pkeys are immutable on OpenSSL 3.0
Ayer actualicé a la nueva versión de PoP_OS!, basada en Ubuntu 22.04 LTS. Todo funcionó de maravilla, como debe ser. El único problema -por llamarlo de algún modo- identificado tras la actualización ha sido la pérdida de la configuración de Cool Retro Term; no big deal…
Hoy he instalado Cockpit y después de configurar una IP estática para el servidor que uso de laboratorio, la sección Software Updates ha dejado de funcionar, mostrando el mensaje de error Cannot refresh cache whilst offline.
La solución la he encontrado en Cockpit – “cannot refresh cache whilst offline”.
El título tiene una sonoridad un poco a click bait, así que explicaré rápidamente a qué me refiero.
Hace poco que hemos empezado a colaborar en un proyecto nuevo. Mientras nos vamos poniendo al día estoy ayudando a uno de mis compañeros -un crack en networking- con temas relacionados con contenedores, con los que está menos familiarizado.
Revisando los ficheros de configuración de Google Cloud Build, encontramos, en el mismo fichero, referencias a la imagen de un contenedor como hashicorp/terraform:latest, otras en las que el nombre es de la forma gcr.io/cloud-builders/gcloud y otras en las que es, simplemente, alpine.
Y claro, mi compañero no entiende nada…
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).
Las variables de entorno se definen para cada usuario; por tanto, para mi usuario xavi, puedo configurar la variable https_proxy mediante:
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í.
