Al hacer limpieza de uno de los clústers de desarrollo, he borrado dos namespaces y los dos se han quedado en estado Terminating
Eliminar namespace encallado en Terminating
- post
- Xavi Aznar
Photo by Mabel Amber
Al hacer limpieza de uno de los clústers de desarrollo, he borrado dos namespaces y los dos se han quedado en estado Terminating
Idealmente, el análisis de los ficheros de definición de objetos (YAML) en Kubernetes debería realizarse antes de crear los objetos en el clúster. Para ello, uno de los stages del proceso de CI/CD debería incorporar KubeLinter (por ejemplo).
De forma paralela, también deberíamos tener un proceso periódico que revise los ficheros de definición de los objetos que tenemos almacenados en el repositorio para identificar, por ejemplo, el uso de versiones de la API desaconsejadas (deprecated) en proceso de eliminación de la API.
En este artículo vemos cómo configurar un Cronjob que ejecute KubeLinter para obtener los ficheros de un repositorio remoto y analizarlos.
En la entrada anterior KubeLinter: identifica malas configuraciones en los objetos de Kubernetes, KubeLinter identificaba dos errores que se solucionan usando las opciones: runAsUser
y readOnlyRootFilesystem
.
En esta entrada comparo los efectos de aplicar una u otra, así como qué pasa cuando se aplican las dos al mismo tiempo.
KubeLinter es un linter para los objetos de Kubernetes; es decir, KubeLinter comprueba configuraciones sospechosas en los ficheros de definición de los objetos de Kubernetes.
En la documentación oficial tienes una lista de las validaciones que realiza y cuáles vienen habilitadas por defecto: KubeLinter checks.
KubeLinter es una herramienta opensource desarrollada por StackRox, una empresa orientada a la seguridad que recientemente ha sido adquirida por Red Hat, precisamente, para mejorar la seguridad de OpenShift.
Las buenas prácticas (por ejemplo Version Control Best Practices) relacionadas con el control de versiones usando Git indican que hay que guardar (commit) los cambios de forma frecuente, conteniendo únicamente pequeños cambios.
Sin embargo, el desarrollo no se produce de una forma lineal, de principio a fin; a veces, lo que parece una buena idea que funciona al principio, más adelante es necesario cambiarla o modificarla…
Si guardamos todos los commits, la historia del repositorio quedará llena de estos cambios de dirección durante el desarrollo. Por este motivo, una de las opciones que tenemos es la de reescribir la historia del repositorio antes de, por ejemplo, hacer merge de la rama de feaure sobre la rama principal.
En este artículo vemos cómo conseguirlo usando git rebase
.
La mayoría de los recursos de Kubernetes como los pods, los services, los replication controllers, etc están limitados al namespace en el que se despliegan. Así, dos recursos pueden tener el mismo nombre, etc si se encuentran en namespaces diferentes, ya que el namespace define el alcance de visibilidad para el recursos. El namespace es el límite del scope del recurso en Kubernetes.
Sin embargo, no todos los recursos en Kubernetes se encuentran “limitados” por el namespace; por ejemplo, el propio recurso namespace
no está en un namespace, ni los persistentVolumes
tampoco…
¿Cómo podemos obtener una lista de los recursos con alcance restringido al namespace en el que se encuentran?
Ya he hablado varias veces de Gitea en este sitio, así que no me repetiré (mucho) ; Gitea es una solución ligera de alojamiento de repositorios Git (a lo GitHub).
En esta entrada se indica el proceso que he seguido para la creación de los diferentes objetos necesarios para desplegar Gitea (usando SQLite como base de datos) en Kubernetes.
Puedes seguir los pasos de la documentación oficial para desplegar Gitea sobre Kubernetes usando Helm.
K3OS (y K3s) despliega Traefik como Ingress. Pero el problema es que el certificado autofirmado configurado por defecto caducó en 2017.
Probablemente se trata de una feature y no de un bug, para “animar” a cambiar el certificado desplegado por defecto por uno válido; en este artículo explico cómo hacerlo.
Hace unos días leía More Problems with GitOps — and How to Fix Them sobre los problemas asociados a GitOps, así que aprovecho para inaugurar esta nueva sección de reflexiones sobre artículos que considero interesantes.
Ya hace casi dos meses de la última entrada en el blog; en esta entrada explico en qué he estado trabajando y qué me ha mantenido apartado de la publicación en el blog.