Esta sección de la documentación de Kubernetes contiene páginas que
muestran cómo acometer tareas individuales. Cada página de tarea muestra cómo
realizar una única cosa, típicamente proporcionando una pequeña secuencia de comandos.
Interfaz Web de Usuario (Tablero de Control)
Despliega y accede al interfaz web de usuario del Tablero de Control para ayudarte en la gestión y monitorización de las aplicaciones en contenedores de tu clúster de Kubenertes.
Usar la línea de comandos con kubectl
Instala y configura la herramienta de línea de comandos kubectl para gestionar de forma directa tus clústers de Kubernetes.
Configurar Pods y Contenedores
Realiza tareas comunes de configuración para tus Pods y Contenedores.
Ejecutar Aplicaciones
Realiza tareas comunes de gestión de aplicaciones, como actualizaciones de lanzamiento, inyectar información en los pods, y auto-escalado horizontal de pods.
Ejecutar Jobs
Ejecuta Jobs usando procesado paralelo.
Acceder a las Aplicaciones de un Clúster
Configura el balanceo de carga, re-envío de puertos, o configura el cortafuegos o las configuraciones de DNS para acceder a las aplicaciones en un clúster.
Monitorización, Trazas, y Depuración
Configura la monitorización y las trazas para identificar problemas en un clúster o depurar una aplicación en un contenedor.
Acceder a la API de Kubernetes
Aprende varios métodos para acceder directamente a la API de Kubernetes.
Usar TLS
Configura tu aplicación para que confíe y use el Certificado de Autoridad (CA) raíz de tu clúster.
Administrar un Clúster
Aprende tareas comunes de administración de un clúster.
Administrar la Federación
Configura componentes en una federación de clústers.
Gestionar Aplicaciones con Estado
Realiza tareas comunes de gestión de aplicaciones con estado, incluyendo escalado, borrado y depuración de StatefulSets.
Daemons del Clúster
Realiza tareas comunes de gestión de un DaemonSet, como llevar a cabo una actualización de lanzamiento.
Gestionar GPUs
Configura y planifica GPUs de NVIDIA para hacerlas disponibles como recursos a los nodos de un clúster.
Gestionar HugePages
Configura y planifica HugePages como un recurso planificado en un clúster.
Configurar las herramientas de Kubernetes en su computadora.
kubectl
Usa la herramienta de línea de comandos de Kubernetes, kubectl, para desplegar y gestionar aplicaciones en Kubernetes. Usando kubectl, puedes inspeccionar recursos del clúster; crear, eliminar, y actualizar componentes; explorar tu nuevo clúster y arrancar aplicaciones.
Ver Instalar y Configurar kubectl para más información sobre cómo descargar y instalar kubectl y configurarlo para acceder su clúster.
De forma similar a kind, minikube es una herramienta que le permite usar Kubernetes en su máquina local. minikube le permite ejecutar un único nodo en su computadora personal (PC de Windows, macOS y Linux) para que se pueda probar Kubernetes, o para su trabajo de desarrollo.
Se puede seguir la guía oficial de minikube si su enfoque esta instalando la herramienta.
Usa la herramienta de línea de comandos de Kubernetes, kubectl, para desplegar y gestionar aplicaciones en Kubernetes. Usando kubectl, puedes inspeccionar recursos del clúster; crear, eliminar, y actualizar componentes; explorar tu nuevo clúster; y arrancar aplicaciones de ejemplo. Para ver la lista completa de operaciones de kubectl, se puede ver el resumen de kubectl.
Antes de empezar
Debes usar una versión de kubectl que esté a menos de una versión menor de diferencia con tu clúster. Por ejemplo, un cliente v1.2 debería funcionar con un máster v1.1, v1.2, y v1.3. Usar la última versión de kubectl ayuda a evitar problemas inesperados.
Para descargar una versión específica, remplaza el comando $(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt) con la versión específica.
Por ejemplo, para descarga la versión v1.21.14 en Linux, teclea:
Si usas Ubuntu o alguna de las otras distribuciones de Linux que soportan el gestor de paquetes snap, kubectl está disponible como una aplicación snap.
snap install kubectl --classic
kubectl version --client
Para descargar una versión específica, remplaza el comando $(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt) con la versión específica.
Por ejemplo, para descargar la versión v1.21.14 en macOS, teclea:
Si tienes Docker Desktop instalado, es posible que tengas que modificar tu PATH al PATH añadido por Docker Desktop o eliminar la versión de kubectl proporcionada por Docker Desktop.
Instalar con Powershell desde PSGallery
Si estás en Windows y utilizas el gestor de paquetes Powershell Gallery, puedes instalar y actualizar kubectl con Powershell.
Ejecuta los comandos de instalación (asegurándote de especificar una DownloadLocation):
Para asegurar que la versión utilizada sea la más actual puedes probar:
kubectl version --client
Comprobar la configuración kubectl
Para que kubectl pueda encontrar y acceder a un clúster de Kubernetes, necesita un fichero kubeconfig, que se crea de forma automática cuando creas un clúster usando kube-up.sh o despliegas de forma satisfactoria un clúster de Minikube. Revisa las guías para comenzar para más información acerca de crear clústers. Si necesitas acceso a un clúster que no has creado, ver el documento de Compartir Acceso a un Clúster.
Por defecto, la configuración de kubectl se encuentra en ~/.kube/config.
Comprueba que kubectl está correctamente configurado obteniendo el estado del clúster:
kubectl cluster-info
Si ves una respuesta en forma de URL, kubectl está correctamente configurado para acceder a tu clúster.
Si ves un mensaje similar al siguiente, kubectl no está correctamente configurado o no es capaz de conectar con un clúster de Kubernetes.
The connection to the server <server-name:port> was refused - did you specify the right host or port?
Por ejemplo, si intentas ejecutar un clúster de Kubernetes en tu portátil (localmente), necesitarás una herramienta como minikube que esté instalada primero y entonces volver a ejecutar los comandos indicados arriba.
Si kubectl cluster-info devuelve la respuesta en forma de url, pero no puedes acceder a tu clúster, para comprobar si está configurado adecuadamente, usa:
kubectl cluster-info dump
kubectl configuraciones opcionales
Habilitar el auto-completado en el intérprete de comandos
kubectl provee de soporte para auto-completado para Bash y Zsh, ¡que te puede ahorrar mucho uso del teclado!
Abajo están los procedimientos para configurar el auto-completado para Bash (incluyendo la diferencia entre Linux y macOS) y Zsh.
La secuencia de comandos de completado de kubectl para Bash puede ser generado con el comando kubectl completion bash. Corriendo la secuencia de comandos de completado en tu intérprete de comandos habilita el auto-completado de kubectl.
Sin embargo, la secuencia de comandos de completado depende de bash-completion*, lo que significa que tienes que instalar primero este programa (puedes probar si ya tienes bash-completion instalado ejecutando type _init_completion).
Instalar bash-completion
bash-completion es ofrecido por muchos gestores de paquetes (ver aquí). Puedes instalarlo con apt-get install bash-completion o yum install bash-completion, etc.
Los comandos de arriba crean /usr/share/bash-completion/bash_completion, que es la secuencia de comandos principal de bash-completion. Dependiendo de tu gestor de paquetes, tienes que correr manualmente este archivo en tu ~/.bashrc.
Para averiguarlo, recarga tu intérprete de comandos y ejecuta type _init_completion. Si el comando tiene éxito, ya has terminado; si no, añade lo siguiente a tu ~/.bashrc:
source /usr/share/bash-completion/bash_completion
recarga tu intérprete de comandos y verifica que bash-completion está correctamente instalado tecleando type _init_completion.
Habilitar el auto-completado de kubectl
Debes asegurarte que la secuencia de comandos de completado de kubectl corre en todas tus sesiones de tu intérprete de comandos. Hay dos formas en que puedes hacer esto:
Corre la secuencia de comandos de completado en tu ~/.bashrc:
Si tienes un alias para kubectl, puedes extender los comandos de shell para funcionar con ese alias:
echo'alias k=kubectl' >>~/.bashrc
echo'complete -F __start_kubectl k' >>~/.bashrc
Nota: bash-completion corre todas las secuencias de comandos de completado en /etc/bash_completion.d.
Ambas estrategias son equivalentes. Tras recargar tu intérprete de comandos, el auto-completado de kubectl debería estar funcionando.
Introducción
La secuencia de comandos de completado de kubectl para Bash puede generarse con el comando kubectl completion bash. Corriendo la secuencia de comandos de completado en tu intérprete de comandos habilita el auto-completado de kubectl.
Sin embargo, la secuencia de comandos de completado depende de bash-completion*, lo que significa que tienes que instalar primero este programa (puedes probar si ya tienes bash-completion instalado ejecutando type _init_completion).
Advertencia: macOS incluye Bash 3.2 por defecto. La secuencia de comandos de completado de kubectl requiere Bash 4.1+ y no funciona con Bash 3.2. Una posible alternativa es instalar una nueva versión de Bash en macOS (ver instrucciones aquí). Las instrucciones de abajo sólo funcionan si estás usando Bash 4.1+.
Actualizar bash
Las instrucciones asumen que usa Bash 4.1+. Puedes comprobar tu versión de bash con:
echo$BASH_VERSION
Si no es 4.1+, puede actualizar bash con Homebrew:
brew install bash
Recarga tu intérprete de comandos y verifica que estás usando la versión deseada:
echo$BASH_VERSION$SHELL
Usualmente, Homebrew lo instala en /usr/local/bin/bash.
Instalar bash-completion
Puedes instalar bash-completion con Homebrew:
brew install bash-completion@2
Nota: El @2 simboliza bash-completion 2, que es requerido por la secuencia de comandos de completado de kubectl (no funciona con bash-completion 1). Luego, bash-completion 2 requiere Bash 4.1+, eso es por lo que necesitabas actualizar Bash.
Como se indicaba en la salida de brew install (sección "Caveats"), añade las siguientes líneas a tu ~/.bashrc o ~/.bash_profile:
Recarga tu intérprete de comandos y verifica que bash-completion está correctamente instalado tecleando type _init_completion.
Habilitar el auto-completado de kubectl
Debes asegurarte que la secuencia de comandos de completado de kubectl corre en todas tus sesiones de tu intérprete de comenados. Hay múltiples formas en que puedes hacer esto:
Corre la secuencia de comandos de completado en tu ~/.bashrc:
Si has instalado kubectl con Homebrew (como se explica aquí), entonces la secuencia de comandos de completado se instaló automáticamente en /usr/local/etc/bash_completion.d/kubectl. En este caso, no tienes que hacer nada.
Nota: bash-completion (si se instaló con Homebrew) corre todas las secuencias de comandos de completado en el directorio que se ha puesto en la variable de entorno BASH_COMPLETION_COMPAT_DIR.
Todas las estrategias son equivalentes. Tras recargar tu intérprete de comandos, el auto-completado de kubectl debería funcionar.
La secuencia de comandos de completado de kubectl para Zsh puede ser generada con el comando kubectl completion zsh. Corriendo la secuencia de comandos de completado en tu intérprete de comandos habilita el auto-completado de kubectl.
Para hacerlo en todas tus sesiones de tu intérprete de comandos, añade lo siguiente a tu ~/.zshrc:
source <(kubectl completion zsh)
Si tienes alias para kubectl, puedes extender el completado de intérprete de comandos para funcionar con ese alias.
echo'alias k=kubectl' >>~/.zshrc
echo'complete -F __start_kubectl k' >>~/.zshrc
Tras recargar tu intérprete de comandos, el auto-completado de kubectl debería funcionar.
Si obtienes un error como complete:13: command not found: compdef, entonces añade lo siguiente al principio de tu ~/.zshrc:
Leer ´la documentación de kubectl reference](/docs/reference/kubectl/kubectl/)
2 - Administrar un clúster
2.1 - Administrar un clúster con kubeadm
2.2 - Administrar recursos de memoria, CPU y API
2.3 - Instalar un proveedor de políticas de red
3 - Configurar pods y contenedores
3.1 - Configura un Pod para Usar un Volume como Almacenamiento
En esta página se muestra cómo configurar un Pod para usar un Volume (volumen) como almacenamiento.
El sistema de ficheros de un Contenedor existe mientras el Contenedor exista. Por tanto, cuando un Contenedor es destruido o reiniciado, los cambios realizados en el sistema de ficheros se pierden. Para un almacenamiento más consistente que sea independiente del ciclo de vida del Contenedor, puedes usar un Volume. Esta característica es especialmente importante para aplicaciones que deben mantener un estado, como motores de almacenamiento clave-valor (por ejemplo Redis) y bases de datos.
Antes de empezar
Debes tener un cluster Kubernetes a tu dispocición, y la herramienta de línea de comandos kubectl debe estar configurada. Si no tienes un cluster, puedes crear uno utilizando Minikube,
o puedes utilizar una de las siguientes herramientas en línea:
Para comprobar la versión, introduzca kubectl version.
Configura un Volume para un Pod
En este ejercicio crearás un Pod que ejecuta un único Contenedor. Este Pod tiene un Volume de tipo emptyDir (directorio vacío) que existe durante todo el ciclo de vida del Pod, incluso cuando el Contenedor es destruido y reiniciado. Aquí está el fichero de configuración del Pod:
Verifica que el Contenedor del Pod se está ejecutando y después observa los cambios en el Pod
kubectl get pod redis --watch
La salida debería ser similar a:
NAME READY STATUS RESTARTS AGE
redis 1/1 Running 0 13s
En otro terminal, abre una sesión interactiva dentro del Contenedor que se está ejecutando:
kubectl exec -it redis -- /bin/bash
En el terminal, ve a /data/redis y crea un fichero:
root@redis:/data# cd /data/redis/
root@redis:/data/redis# echo Hello > test-file
En el terminal, lista los procesos en ejecución:
root@redis:/data/redis# apt-get update
root@redis:/data/redis# apt-get install procps
root@redis:/data/redis# ps aux
La salida debería ser similar a:
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
redis 1 0.1 0.1 333083828 ? Ssl 00:46 0:00 redis-server *:6379
root 12 0.0 0.0 202283020 ? Ss 00:47 0:00 /bin/bash
root 15 0.0 0.0 175002072 ? R+ 00:48 0:00 ps aux
En el terminal, mata el proceso de Redis:
root@redis:/data/redis# kill <pid>
donde <pid> es el ID de proceso (PID) de Redis.
En el terminal original, observa los cambios en el Pod de Redis. Eventualmente verás algo como lo siguiente:
NAME READY STATUS RESTARTS AGE
redis 1/1 Running 0 13s
redis 0/1 Completed 0 6m
redis 1/1 Running 1 6m
En este punto, el Contenedor ha sido destruido y reiniciado. Esto es debido a que el Pod de Redis tiene una
restartPolicy (política de reinicio)
de Always (siempre).
Abre un terminal en el Contenedor reiniciado:
kubectl exec -it redis -- /bin/bash
En el terminal, ve a /data/redis y verifica que test-file todavía existe:
root@redis:/data/redis# cd /data/redis/
root@redis:/data/redis# ls
test-file
Elimina el Pod que has creado para este ejercicio:
Además del almacenamiento local proporcionado por emptyDir, Kubernetes soporta diferentes tipos de soluciones de almacenamiento por red, incluyendo los discos gestionados de los diferentes proveedores cloud, como por ejemplo los Persistent Disks en Google Cloud Platform o el Elastic Block Storage de Amazon Web Services. Este tipo de soluciones para volúmenes son las preferidas para el almacenamiento de datos críticos. Kubernetes se encarga de todos los detalles, tal como montar y desmontar los dispositivos en los nodos del clúster. Revisa Volumes para obtener más información.
4 - Administrar Objetos en Kubernetes
Interactuando con el API de Kubernetes aplicando paradigmas declarativo e imperativo.
4.1 - Administración declarativa de Objetos en Kubernetes usando archivos de Configuración
Objetos en Kubernetes pueden ser creados, actualizados y eliminados utilizando
archivos de configuración almacenados en un directorio. Usando el comando
kubectl apply podrá crearlos o actualizarlos de manera recursiva según sea necesario.
Este método retiene cualquier escritura realizada contra objetos activos en el
sistema sin unirlos de regreso a los archivos de configuración. kubectl diff le
permite visualizar de manera previa los cambios que apply realizará.
Debes tener un cluster Kubernetes a tu dispocición, y la herramienta de línea de comandos kubectl debe estar configurada. Si no tienes un cluster, puedes crear uno utilizando Minikube,
o puedes utilizar una de las siguientes herramientas en línea:
La configuración de objetos declarativa requiere una comprensión firme de la
definición y configuración de objetos de Kubernetes. Si aún no lo ha hecho, lea
y complete los siguientes documentos:
A continuación la definición de términos usados en este documento:
archivo de configuración de objeto / archivo de configuración: Un archivo en el
que se define la configuración de un objeto de Kubernetes. Este tema muestra como
utilizar archivos de configuración con kubectl apply. Los archivos de configuración
por lo general se almacenan en un sistema de control de versiones, como Git.
configuración activa de objeto / configuración activa: Los valores de configuración
activos de un objeto, según estén siendo observados por el Clúster. Esta configuración
se almacena en el sistema de almacenamiento de Kubernetes, usualmente etcd.
escritor de configuración declarativo / escritor declarativo: Una persona o
componente de software que actualiza a un objeto activo. Los escritores activos a
los que se refiere este tema aplican cambios a los archivos de configuración de objetos
y ejecutan kubectl apply para aplicarlos.
Como crear objetos
Utilice kubectl apply para crear todos los objetos definidos en los archivos
de configuración existentes en un directorio específico, con excepción de aquellos que
ya existen:
kubectl apply -f <directorio>/
Esto definirá la anotación kubectl.kubernetes.io/last-applied-configuration: '{...}'
en cada objeto. Esta anotación contiene el contenido del archivo de configuración
utilizado para la creación del objeto.
Nota: Agregue la opción -R para procesar un directorio de manera recursiva.
El siguiente es un ejemplo de archivo de configuración para un objeto:
diff utiliza server-side dry-run,
que debe estar habilitado en el kube-apiserver.
Dado que diff ejecuta una solicitud de apply en el servidor en modo de simulacro (dry-run),
requiere obtener permisos de PATCH, CREATE, y UPDATE.
Vea Autorización Dry-Run
para más detalles.
Despliegue la configuración activa usando kubectl get:
kubectl get -f https://k8s.io/examples/application/simple_deployment.yaml -o yaml
La salida le mostrará que la anotación kubectl.kubernetes.io/last-applied-configuration
fue escrita a la configuración activa, y es consistente con los contenidos del archivo
de configuración:
kind:Deploymentmetadata:annotations:# ...# Esta es la representación JSON de simple_deployment.yaml# Fue escrita por kubectl apply cuando el objeto fue creadokubectl.kubernetes.io/last-applied-configuration:| {"apiVersion":"apps/v1","kind":"Deployment",
"metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"},
"spec":{"minReadySeconds":5,"selector":{"matchLabels":{"app":nginx}},"template":{"metadata":{"labels":{"app":"nginx"}},
"spec":{"containers":[{"image":"nginx:1.14.2","name":"nginx",
"ports":[{"containerPort":80}]}]}}}}# ...spec:# ...minReadySeconds:5selector:matchLabels:# ...app:nginxtemplate:metadata:# ...labels:app:nginxspec:containers:- image:nginx:1.14.2# ...name:nginxports:- containerPort:80# ...# ...# ...# ...
Como actualizar objetos
También puede usar kubectl apply para actualizar los objetos definidos en un directorio,
aún cuando esos objetos ya existan en la configuración activa. Con este enfoque logrará
lo siguiente:
Definir los campos que aparecerán en la configuración activa.
Eliminar aquellos campos eliminados en el archivo de configuración, de la configuración activa.
Nota: Con el propósito de ilustrar, el comando anterior se refiere a un único archivo
de configuración en vez de un directorio.
Despliegue la configuración activa usando kubectl get:
kubectl get -f https://k8s.io/examples/application/simple_deployment.yaml -o yaml
La salida le mostrará que la anotación kubectl.kubernetes.io/last-applied-configuration
fue escrita a la configuración activa, y es consistente con los contenidos del archivo
de configuración:
kind:Deploymentmetadata:annotations:# ...# Esta es la representación JSON de simple_deployment.yaml# Fue escrita por kubectl apply cuando el objeto fue creadokubectl.kubernetes.io/last-applied-configuration:| {"apiVersion":"apps/v1","kind":"Deployment",
"metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"},
"spec":{"minReadySeconds":5,"selector":{"matchLabels":{"app":nginx}},"template":{"metadata":{"labels":{"app":"nginx"}},
"spec":{"containers":[{"image":"nginx:1.14.2","name":"nginx",
"ports":[{"containerPort":80}]}]}}}}# ...spec:# ...minReadySeconds:5selector:matchLabels:# ...app:nginxtemplate:metadata:# ...labels:app:nginxspec:containers:- image:nginx:1.14.2# ...name:nginxports:- containerPort:80# ...# ...# ...# ...
De manera directa, actualice el campo replicas en la configuración activa usando kubectl scale.
En este caso no se usa kubectl apply:
Despliegue la configuración activa usando kubectl get:
kubectl get deployment nginx-deployment -o yaml
La salida le muestra que el campo replicas ha sido definido en 2, y que la
anotación last-applied-configuration no contiene el campo replicas:
apiVersion:apps/v1kind:Deploymentmetadata:annotations:# ...# note que la anotación no contiene replicas# debido a que el objeto no fue actualizado usando applykubectl.kubernetes.io/last-applied-configuration:| {"apiVersion":"apps/v1","kind":"Deployment",
"metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"},
"spec":{"minReadySeconds":5,"selector":{"matchLabels":{"app":nginx}},"template":{"metadata":{"labels":{"app":"nginx"}},
"spec":{"containers":[{"image":"nginx:1.14.2","name":"nginx",
"ports":[{"containerPort":80}]}]}}}}# ...spec:replicas:2# definido por scale# ...minReadySeconds:5selector:matchLabels:# ...app:nginxtemplate:metadata:# ...labels:app:nginxspec:containers:- image:nginx:1.14.2# ...name:nginxports:- containerPort:80# ...
Actualice el archivo de configuración simple_deployment.yaml para cambiar el campo image
de nginx:1.14.2 a nginx:1.16.1, y elimine el campo minReadySeconds:
apiVersion:apps/v1kind:Deploymentmetadata:name:nginx-deploymentspec:selector:matchLabels:app:nginxtemplate:metadata:labels:app:nginxspec:containers:- name:nginximage:nginx:1.16.1# actualice el valor de imageports:- containerPort:80
Aplique los cambios realizados al archivo de configuración:
Despliegue la configuración activa usando kubectl get:
kubectl get -f https://k8s.io/examples/application/update_deployment.yaml -o yaml
La salida le mostrará los siguientes cambios hechos a la configuración activa:
El campo replicas retiene el valor de 2 definido por kubectl scale.
Esto es posible ya que el campo fue omitido en el archivo de configuración.
El campo image ha sido actualizado de nginx:1.16.1 a nginx:1.14.2.
La anotación last-applied-configuration ha sido actualizada con la nueva imagen.
El campo minReadySeconds ha sido despejado.
La anotación last-applied-configuration ya no contiene el campo minReadySeconds
apiVersion:apps/v1kind:Deploymentmetadata:annotations:# ...# La anotación contiene la imagen acutalizada a nginx 1.11.9,# pero no contiene la actualización de las replicas a 2kubectl.kubernetes.io/last-applied-configuration:| {"apiVersion":"apps/v1","kind":"Deployment",
"metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"},
"spec":{"selector":{"matchLabels":{"app":nginx}},"template":{"metadata":{"labels":{"app":"nginx"}},
"spec":{"containers":[{"image":"nginx:1.16.1","name":"nginx",
"ports":[{"containerPort":80}]}]}}}}# ...spec:replicas:2# Definido por `kubectl scale`. Ignorado por `kubectl apply`.# minReadySeconds fue despejado por `kubectl apply`# ...selector:matchLabels:# ...app:nginxtemplate:metadata:# ...labels:app:nginxspec:containers:- image:nginx:1.16.1# Definido `kubectl apply`# ...name:nginxports:- containerPort:80# ...# ...# ...# ...
Advertencia: No se puede combinar kubectl apply con comandos de configuración imperativa de objetos
como create y replace. Esto se debe a que create
y replace no retienen la anotación kubectl.kubernetes.io/last-applied-configuration
que kubectl apply utiliza para calcular los cambios por realizar.
Como eliminar objetos
Hay dos opciones diferentes para eliminar objetos gestionados por kubectl apply.
Manera recomendada: kubectl delete -f <archivo>
La manera recomendada de eliminar objetos de manera manual es utilizando el comando
imperativo, ya que es más explícito en relación a lo que será eliminado, y es
menos probable que resulte en algo siendo eliminado sin la intención del usuario.
kubectl delete -f <archivo>
Manera alternativa: kubectl apply -f <directorio/> --prune -l etiqueta=deseada
Únicamente utilice esta opción si está seguro de saber lo que está haciendo.
Advertencia:kubectl apply --prune se encuentra aún en alpha, y cambios incompatibles con versiones previas
podrían ser introducidos en lanzamientos futuros.
Advertencia: Sea cuidadoso(a) al usar este comando, para evitar eliminar objetos
no intencionalmente.
Como una alternativa a kubectl delete, puede usar kubectl apply para identificar objetos a ser
eliminados, luego de que sus archivos de configuración han sido eliminados del directorio. El commando apply con --prune
consulta a la API del servidor por todos los objetos que coincidan con un grupo de etiquetas, e intenta relacionar
la configuración obtenida de los objetos activos contra los objetos según sus archivos de configuración.
Si un objeto coincide con la consulta, y no tiene un archivo de configuración en el directorio, pero si
tiene una anotación last-applied-configuration, entonces será eliminado.
Advertencia:apply con --prune debería de ser ejecutado únicamente en contra del directorio
raíz que contiene los archivos de configuración. Ejecutarlo en contra de sub-directorios
podría causar que objetos sean eliminados no intencionalmente, si son retornados en la
consulta por selección de etiqueta usando -l <etiquetas> y no existen en el subdirectorio.
Como visualizar un objeto
Puede usar kubectl get con -o yaml para ver la configuración de objetos activos:
kubectl get -f <archivo|url> -o yaml
Como son las diferencias calculadas y unidas por apply
Precaución: Un patch (parche) es una operación de actualización con alcance a campos específicos
de un objeto, y no al objeto completo. Esto permite actualizar únicamente grupos de campos
específicos en un objeto sin tener que leer el objeto primero.
Cuando kubectl apply actualiza la configuración activa para un objeto, lo hace enviando
una solicitud de patch al servidor de API. El patch define actualizaciones para campos
específicos en la configuración del objeto activo. El comando kubectl apply calcula esta solicitud
de patch usando el archivo de configuración, la configuración activa, y la anotación last-applied-configuration
almacenada en la configuración activa.
Calculando la unión de un patch
El comando kubectl apply escribe los contenidos de la configuración a la anotación
kubectl.kubernetes.io/last-applied-configuration. Esto es usado para identificar aquellos campos
que han sido eliminados de la configuración y deben ser limpiados. Los siguientes pasos
son usados para calcular que campos deben ser eliminados o definidos:
Calculo de campos por eliminar. Estos son los campos presentes en last-applied-configuration pero ausentes en el archivo de configuración.
Calculo de campos por agregar o definir. Estos son los campos presentes en el archivo de configuración, con valores inconsistentes con la configuración activa.
A continuación un ejemplo. Suponga que este es el archivo de configuración para un objeto de tipo Deployment:
apiVersion:apps/v1kind:Deploymentmetadata:name:nginx-deploymentspec:selector:matchLabels:app:nginxtemplate:metadata:labels:app:nginxspec:containers:- name:nginximage:nginx:1.16.1# actualice el valor de imageports:- containerPort:80
También, suponga que esta es la configuración activa para ese mismo objeto de tipo Deployment:
apiVersion:apps/v1kind:Deploymentmetadata:annotations:# ...# tome nota de que la anotación no contiene un valor para replicas# dado que no fue actualizado usando el comando applykubectl.kubernetes.io/last-applied-configuration:| {"apiVersion":"apps/v1","kind":"Deployment",
"metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"},
"spec":{"minReadySeconds":5,"selector":{"matchLabels":{"app":nginx}},"template":{"metadata":{"labels":{"app":"nginx"}},
"spec":{"containers":[{"image":"nginx:1.14.2","name":"nginx",
"ports":[{"containerPort":80}]}]}}}}# ...spec:replicas:2# definidas por scale# ...minReadySeconds:5selector:matchLabels:# ...app:nginxtemplate:metadata:# ...labels:app:nginxspec:containers:- image:nginx:1.14.2# ...name:nginxports:- containerPort:80# ...
Estos son los cálculos de unión que serían realizados por kubectl apply:
Calcular los campos por eliminar, leyendo los valores de last-applied-configuration
y comparándolos con los valores en el archivo de configuración.
Limpiar los campos definidos en null de manera explícita en el archivo de configuración
sin tomar en cuenta si se encuentran presentes en la anotación last-applied-configuration.
En este ejemplo, minReadySeconds aparece en la anotación
last-applied-configuration pero no aparece en el archivo de configuración.
Acción: Limpiar minReadySeconds de la configuración activa.
Calcular los campos por ser definidos, al leer los valores del fichero de configuración
y compararlos con los valores en la configuración activa. En este ejemplo, el valor image
en el archivo de configuración, no coincide con el valor en la configuración activa.
Acción: Definir el campo image en la configuración activa.
Definir el valor de la anotación last-applied-configuration para que sea consistente
con el archivo de configuración.
Unir los resultados de 1, 2 y 3, en una única solicitud de patch para enviar al servidor de API.
Esta es la configuración activa como resultado de esta unión:
apiVersion:apps/v1kind:Deploymentmetadata:annotations:# ...# La anotación contiene la imágen actualizada a nginx 1.11.9,# pero no contiene la actualización a 2 replicaskubectl.kubernetes.io/last-applied-configuration:| {"apiVersion":"apps/v1","kind":"Deployment",
"metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"},
"spec":{"selector":{"matchLabels":{"app":nginx}},"template":{"metadata":{"labels":{"app":"nginx"}},
"spec":{"containers":[{"image":"nginx:1.16.1","name":"nginx",
"ports":[{"containerPort":80}]}]}}}}# ...spec:selector:matchLabels:# ...app:nginxreplicas:2# Definido por `kubectl scale`. Ignorado por `kubectl apply`.# minReadySeconds eliminado por `kubectl apply`# ...template:metadata:# ...labels:app:nginxspec:containers:- image:nginx:1.16.1# Definido por `kubectl apply`# ...name:nginxports:- containerPort:80# ...# ...# ...# ...
Como se unen los diferentes tipos de campos
La manera en la que los campos en un archivo de configuración son unidos con la
configuración activa depende del tipo de campo. Existen varios tipos de campos:
primitivo: Campos de cadena de texto (string), enteros (integer), o lógicos (boolean).
Por ejemplo, image y replicas son campos de tipo primitivo. Acción: Reemplazarlos.
mapa, también llamados objeto: Campo de tipo mapa o un tipo
complejo que contiene sub-campos. Por ejemplo, labels,
annotations,spec y metadata son todos mapas. Acción: Unir los elementos o sub-campos.
lista: Campos que contienen una lista de elementos que pueden ser de tipo primitivo o mapa.
Como ejemplos, containers, ports, y args son listas. Acción: Varía.
Cuando kubectl apply actualiza un campo de tipo mapa o lista, típicamente no reemplaza
el campo completo, sino actualiza los sub-elementos individuales.
Por ejemplo, cuando se hace una unión del campo spec en un Deployment, el spec
completo no es reemplazado, por el contrario, únicamente los sub-campos de spec como
replica son comparados y unidos.
Uniendo cambios en campos primitivos
Campos primitivos son limpiados o reemplazados.
Nota:- determina que "no aplica" debido a que el valor no es utilizado.
Campo en el archivo de configuración
Campo en la configuración activa
Campo en last-applied-configuration
Acción
Si
Si
-
Define el valor en el archivo de configuración como activo.
Si
No
-
Define el valor a la configuración local.
No
-
Si
Elimina de la configuración activa.
No
-
No
No hacer nada. Mantiene el valor activo.
Uniendo cambios en campos de un mapa
Los campos que conjuntamente representan un mapa, son unidos al comparar cada uno de los subcampos o elementos del mapa:
Nota:- determina que "no aplica" debido a que el valor no es utilizado.
Propiedad en archivo de configuración
Propiedad en configuración activa
Campo en last-applied-configuration
Acción
Si
Si
-
Comparar valores de sub-propiedades.
Si
No
-
Usar configuración local.
No
-
Si
Eliminar de la configuración activa.
No
-
No
No hacer nada. Mantener el valor activo.
Uniendo cambios en campos de tipo lista
El unir cambios en una lista utiliza una de tres posibles estrategias:
Reemplazar la lista si todos sus elementos son primitivos.
Unir elementos individuales en líneas de elementos complejos.
Unir una lista de elementos primitivos.
Se define la estrategia elegida con base en cada campo.
Reemplazar una lista si todos sus elementos son primitivos
Trata la lista como si fuese un campo primitivo. Reemplaza o elimina la lista completa.
Esto preserva el orden de los elementos.
Ejemplo: Usando kubectl apply para actualizar el campo args de un Contenedor en un Pod.
Esto define el valor de args en la configuración activa, al valor en el archivo de configuración.
Cualquier elemento de args que haya sido previamente agregado a la configuración activa se perderá.
El orden de los elementos definidos en args en el archivo de configuración, serán conservados
en la configuración activa.
# valor en last-applied-configurationargs:["a","b"]# valores en archivo de configuraciónargs:["a","c"]# configuración activaargs:["a","b","d"]# resultado posterior a la uniónargs:["a","c"]
Explicación: La unión utilizó los valores del archivo de configuración para definir los nuevos valores de la lista.
Unir elementos individuales en una lista de elementos complejos
Trata la lista como un mapa, y trata cada campo específico de cada elemento como una llave.
Agrega, elimina o actualiza elementos individuales. Esta operación no conserva el orden.
Esta estrategia de unión utiliza una etiqueta especial en cada campo llamada patchMergeKey. La etiqueta
patchMergeKey es definida para cada campo en el código fuente de Kubernetes:
types.go
Al unir una lista de mapas, el campo especificado en patchMergeKey para el elemento dado
se utiliza como un mapa de llaves para ese elemento.
Ejemplo: Utilice kubectl apply para actualizar el campo containers de un PodSpec.
Esto une la lista como si fuese un mapa donde cada elemento utiliza name por llave.
# valor en last-applied-configurationcontainers:- name:nginximage:nginx:1.16- name: nginx-helper-a # llave:nginx-helper-a; será eliminado en resultadoimage:helper:1.3- name: nginx-helper-b # llave:nginx-helper-b; será conservadoimage:helper:1.3# valor en archivo de configuracióncontainers:- name:nginximage:nginx:1.16- name:nginx-helper-bimage:helper:1.3- name: nginx-helper-c # llavel:nginx-helper-c; será agregado en el resultadoimage:helper:1.3# configuración activacontainers:- name:nginximage:nginx:1.16- name:nginx-helper-aimage:helper:1.3- name:nginx-helper-bimage:helper:1.3args:["run"]# Campo será conservado- name: nginx-helper-d # llave:nginx-helper-d; será conservadoimage:helper:1.3# resultado posterior a la unióncontainers:- name:nginximage:nginx:1.16# Elemento nginx-helper-a fue eliminado- name:nginx-helper-bimage:helper:1.3args:["run"]# Campo fue conservado- name:nginx-helper-c# Elemento fue agregadoimage:helper:1.3- name:nginx-helper-d# Elemento fue ignoradoimage:helper:1.3
Explicación:
El contenedor llamado "nginx-helper-a" fué eliminado al no aparecer ningún
contenedor llamado "nginx-helper-a" en el archivo de configuración.
El contenedor llamado "nginx-helper-b" mantiene los cambios existentes en args
en la configuración activa. kubectl apply pudo identificar que
el contenedor "nginx-helper-b" en la configuración activa es el mismo
"nginx-helper-b" que aparece en el archivo de configuración, aún teniendo diferentes
valores en los campos (no existe args en el archivo de configuración). Esto sucede
debido a que el valor del campo patchMergeKey (name) es idéntico en ambos.
El contenedor llamado "nginx-helper-c" fue agregado ya que no existe ningún contenedor
con ese nombre en la configuración activa, pero si existe uno con ese nombre
en el archivo de configuración.
El contendor llamado "nginx-helper-d" fue conservado debido a que no aparece
ningún elemento con ese nombre en last-applied-configuration.
Unir una lista de elementos primitivos
A partir de Kubernetes 1.5, el unir listas de elementos primitivos no es soportado.
Nota: La etiqueta patchStrategy en types.go es la que
determina cual de las estrategias aplica para cualquier campo en particular.
Para campos de tipo lista, el campo será reemplazado cuando no exista una especificación de patchStrategy.
Valores de campo por defecto
El Servidor de API define algunos campos a sus valores por defecto si no son especificados
al momento de crear un objeto.
Aquí puede ver un archivo de configuración para un Deployment. Este archivo no especifica
el campo strategy:
Despliegue la configuración activa usando kubectl get:
kubectl get -f https://k8s.io/examples/application/simple_deployment.yaml -o yaml
La salida muestra que el servidor de API definió varios campos con los valores por defecto
en la configuración activa. Estos campos no fueron especificados en el archivo de
configuración.
apiVersion:apps/v1kind:Deployment# ...spec:selector:matchLabels:app:nginxminReadySeconds:5replicas:1# valor por defecto definido por apiserverstrategy:rollingUpdate:# valor por defecto definido por apiserver - derivado de strategy.typemaxSurge:1maxUnavailable:1type:RollingUpdate# valor por defecto definido por apiservertemplate:metadata:creationTimestamp:nulllabels:app:nginxspec:containers:- image:nginx:1.14.2imagePullPolicy:IfNotPresent# valor por defecto definido por apiservername:nginxports:- containerPort:80protocol:TCP# valor por defecto definido por apiserverresources:{}# valor por defecto definido por apiserverterminationMessagePath:/dev/termination-log# valor por defecto definido por apiserverdnsPolicy:ClústerFirst# valor por defecto definido por apiserverrestartPolicy:Always# valor por defecto definido por apiserversecurityContext:{}# valor por defecto definido por apiserverterminationGracePeriodSeconds:30# valor por defecto definido por apiserver# ...
En una solicitud de patch, los campos definidos a valores por defecto no son redefinidos a excepción
de cuando hayan sido limpiados de manera explícita como parte de la solicitud de patch. Esto puede
causar comportamientos no esperados para campos cuyo valor por defecto es basado en los valores
de otros campos. Cuando el otro campo ha cambiado, el valor por defecto de ellos no será actualizado
de no ser que sean limpiados de manera explícita.
Por esta razón, se recomienda que algunos campos que reciben un valor por defecto del
servidor sean definidos de manera explícita en los archivos de configuración, aun cuando
el valor definido sea idéntico al valor por defecto. Esto facilita la identificación
de valores conflictivos que podrían no ser revertidos a valores por defecto por parte
del servidor.
Ejemplo:
# last-applied-configurationspec:template:metadata:labels:app:nginxspec:containers:- name:nginximage:nginx:1.14.2ports:- containerPort:80# archivo de configuraciónspec:strategy:type:Recreate# valor actualizadotemplate:metadata:labels:app:nginxspec:containers:- name:nginximage:nginx:1.14.2ports:- containerPort:80# configuración activaspec:strategy:type:RollingUpdate# valor por defectorollingUpdate:# valor por defecto derivado del campo typemaxSurge :1maxUnavailable:1template:metadata:labels:app:nginxspec:containers:- name:nginximage:nginx:1.14.2ports:- containerPort:80# resultado posterior a la unión - ERROR!spec:strategy:type: Recreate # valor actualizado:incompatible con RollingUpdaterollingUpdate: # valor por defecto:incompatible con "type: Recreate"maxSurge :1maxUnavailable:1template:metadata:labels:app:nginxspec:containers:- name:nginximage:nginx:1.14.2ports:- containerPort:80
Explicación:
El usuario crea un Deployment sin definir strategy.type.
El servidor define strategy.type a su valor por defecto de RollingUpdate y
agrega los valores por defecto a strategy.rollingUpdate.
El usuario cambia strategy.type a Recreate. Los valores de strategy.rollingUpdate
se mantienen en su configuración por defecto, sin embargo el servidor espera que se limpien.
Si los valores de strategy.rollingUpdate hubiesen sido definidos inicialmente en el archivo
de configuración, hubiese sido más claro que requerían ser eliminados.
Apply fallará debido a que strategy.rollingUpdate no fue eliminado. El campo strategy.rollingupdate
no puede estar definido, si el valor de strategy.type es Recreate.
Recomendación: Estos campos deberían de ser definidos de manera explícita en el archivo de configuración:
Etiquetas de Selectors y PodTemplate en cargas de trabajo como Deployment, StatefulSet, Job, DaemonSet,
ReplicaSet, y ReplicationController
Estrategia de rollout para un Deployment
Como limpiar campos definidos a valores por defecto por el servidor, o definidos por otros escritores
Campos que no aparecen en el archivo de configuración pueden ser limpiados si se define su valor
a null y luego se aplica el archivo de configuración.
Para los campos definidos a valores por defecto por el servidor, esto provoca que se reestablezca
a sus valores por defecto.
Como cambiar al propietario de un campo entre un archivo de configuración y un escritor imperativo
Estos son los únicos métodos que debe usar para cambiar un campo individual de un objeto:
Usando kubectl apply.
Escribiendo de manera directa a la configuración activa sin modificar el archivo de configuración:
por ejemplo, usando kubectl scale.
Cambiando al propietario de un campo de un escritor imperativo a un archivo de configuración
Añada el campo al archivo de configuración, y no realice nuevas actualizaciones a la configuración
activa que no sucedan por medio de kubectl apply.
Cambiando al propietario de un archivo de configuración a un escritor imperativo
A partir de Kubernetes 1.5, el cambiar un campo que ha sido definido por medio de un
archivo de configuración para que sea modificado por un escritor imperativo requiere
pasos manuales:
Eliminar el campo del archivo de configuración.
Eliminar el campo de la anotación kubectl.kubernetes.io/last-applied-configuration en el objeto activo.
Cambiando los métodos de gestión
Los objetos en Kubernetes deberían de ser gestionados utilizando únicamente un método
a la vez. El alternar de un método a otro es posible, pero es un proceso manual.
Nota: Esta bien el usar eliminación imperativa junto a gestión declarativa.
Migrando de gestión imperativa con comandos a configuración declarativa de objetos
El migrar de gestión imperativa utilizando comandos a la gestión declarativa de objetos
requiere varios pasos manuales:
Exporte el objeto activo a un archivo local de configuración:
kubectl get <tipo>/<nombre> -o yaml > <tipo>_<nombre>.yaml
Elimine de manera manual el campo status del archivo de configuración.
Nota: Este paso es opcional, ya que kubectl apply no actualiza el campo status
aunque este presente en el archivo de configuración.
Defina la anotación kubectl.kubernetes.io/last-applied-configuration en el objeto:
Modifique el proceso para usar kubectl apply para gestionar el objeto de manera exclusiva.
Definiendo los selectores para el controlador y las etiquetas de PodTemplate
Advertencia: Se desaconseja encarecidamente actualizar los selectores en controladores.
La forma recomendada es definir una etiqueta única e inmutable para PodTemplate usada
únicamente por el selector del controlador sin tener ningún otro significado semántico.
6.1 - Corre una aplicación stateless usando un Deployment
Ésta página enseña como correr una aplicación stateless usando un deployment de Kubernetes.
Objetivos
Crear un deployment de nginx.
Usar kubectl para obtener información acerca del deployment.
Actualizar el deployment.
Antes de empezar
Debes tener un cluster Kubernetes a tu dispocición, y la herramienta de línea de comandos kubectl debe estar configurada. Si no tienes un cluster, puedes crear uno utilizando Minikube,
o puedes utilizar una de las siguientes herramientas en línea:
Su versión de Kubernetes debe ser como mínimo v1.9.
Para comprobar la versión, introduzca kubectl version.
Creando y explorando un nginx deployment
Puedes correr una aplicación creando un deployment de Kubernetes, y puedes describir el deployment en un fichero YAML. Por ejemplo, el siguiente fichero YAML describe un deployment que corre la imágen Docker nginx:1.7.9:
apiVersion:apps/v1# Usa apps/v1beta2 para versiones anteriores a 1.9.0kind:Deploymentmetadata:name:nginx-deploymentspec:selector:matchLabels:app:nginxreplicas:2# indica al controlador que ejecute 2 podstemplate:metadata:labels:app:nginxspec:containers:- name:nginximage:nginx:1.7.9ports:- containerPort:80
Name: nginx-deployment
Namespace: default
CreationTimestamp: Tue, 30 Aug 2016 18:11:37 -0700
Labels: app=nginx
Annotations: deployment.kubernetes.io/revision=1
Selector: app=nginx
Replicas: 2 desired | 2 updated | 2 total | 2 available | 0 unavailable
StrategyType: RollingUpdate
MinReadySeconds: 0
RollingUpdateStrategy: 1 max unavailable, 1 max surge
Pod Template:
Labels: app=nginx
Containers:
nginx:
Image: nginx:1.7.9
Port: 80/TCP
Environment: <none>
Mounts: <none>
Volumes: <none>
Conditions:
Type Status Reason
---- ------ ------
Available True MinimumReplicasAvailable
Progressing True NewReplicaSetAvailable
OldReplicaSets: <none>
NewReplicaSet: nginx-deployment-1771418926 (2/2 replicas created)
No events.
Lista los pods creados por el deployment:
kubectl get pods -l app=nginx
El resultado es similar a esto:
NAME READY STATUS RESTARTS AGE
nginx-deployment-1771418926-7o5ns 1/1 Running 0 16h
nginx-deployment-1771418926-r18az 1/1 Running 0 16h
Muestra información acerca del pod:
kubectl describe pod <pod-name>
donde <pod-name> es el nombre de uno de los pods.
Actualizando el deployment
Puedes actualizar el deployment aplicando un nuevo fichero YAML. El siguiente fichero YAML
especifica que el deployment debería ser actualizado para usar nginx 1.8.
apiVersion:apps/v1# Usa apps/v1beta2 para versiones anteriores a 1.9.0kind:Deploymentmetadata:name:nginx-deploymentspec:selector:matchLabels:app:nginxreplicas:2template:metadata:labels:app:nginxspec:containers:- name:nginximage:nginx:1.8# Actualiza la versión de nginx de 1.7.9 a 1.8ports:- containerPort:80
Comprueba como el deployment crea nuevos pods con la nueva imagen mientras va eliminando los pods con la especificación antigua:
kubectl get pods -l app=nginx
Escalando la aplicación aumentado el número de replicas
Puedes aumentar el número de pods en tu deployment aplicando un nuevo fichero YAML.
El siguiente fichero YAML especifica un total de 4 replicas, lo que significa que el deployment debería tener cuatro pods:
apiVersion:apps/v1# Usa apps/v1beta2 para versiones anteriores a 1.9.0kind:Deploymentmetadata:name:nginx-deploymentspec:selector:matchLabels:app:nginxreplicas:4# Actualiza el número de réplicas de 2 a 4template:metadata:labels:app:nginxspec:containers:- name:nginximage:nginx:1.8ports:- containerPort:80
NAME READY STATUS RESTARTS AGE
nginx-deployment-148880595-4zdqq 1/1 Running 0 25s
nginx-deployment-148880595-6zgi1 1/1 Running 0 25s
nginx-deployment-148880595-fxcez 1/1 Running 0 2m
nginx-deployment-148880595-rwovn 1/1 Running 0 2m
Eliminando un deployment
Elimina el deployment por el nombre:
kubectl delete deployment nginx-deployment
ReplicationControllers
La manera preferida de crear una aplicación con múltiples instancias es usando un Deployment, el cual usa un ReplicaSet. Antes de que Deployment y ReplicaSet fueran introducidos en Kubernetes, aplicaciones con múltiples instancias eran configuradas usando un
ReplicationController.
6.2 - Especificando un presupuesto de disrupción para tu aplicación
Ésta pagina enseña como limitar el numero de disrupciones concurrentes que afectan a tu aplicación definiendo presupuestos de disrupción de pods, Pod Disruption Budgets (PDB) en inglés. Estos presupuestos definen el mínimo número de pods que deben estar ejecutándose en todo momento para asegurar la disponibilidad de la aplicación durante operaciones de mantenimiento efectuadas sobre los nodos por los administradores del cluster.
Antes de empezar
Tener permisos de administrador sobre la aplicación que esta corriendo en Kubernetes y requiere alta disponibilidad
Deberías confirmar con el propietario del cluster o proveedor de servicio que respetan Presupuestos de Disrupción para Pods.
Protegiendo una aplicación con un PodDisruptionBudget
Identifica la aplicación que quieres proteger con un PodDisruptionBudget (PDB).
Revisa como afectan las disrupciones a tú aplicación.
Crea un PDB usando un archivo YAML.
Crea el objecto PDB desde el archivo YAML.
Identifica la applicación que quieres proteger
El caso más común es proteger aplicaciones que usan uno de los controladores incorporados
en Kubernetes:
Deployment
Replicationcontrolador
ReplicaSet
StatefulSet
En este caso, toma nota del .spec.selector que utiliza el controlador; el mismo se utilizará en el spec.selector del PDB.
También puedes utilizar PDBs para proteger pods que no estan gestionados por uno de los controladores listados arriba, o agrupaciones arbitrarias de pods, con algunas restricciones descritas en Controladores Arbitrarios y Selectors.
Revisa como afectan las disrupciones a tú aplicación
Decide cuántas instancias de tu aplicación pueden estar fuera de servicio al mismo
tiempo debido a disrupciones voluntarias de corto plazo.
Frontend stateless:
Objetivo: evitar reducir capacidad para servir por mas de 10%.
Solución: usar un PDB que especifica minAvailable 90%.
Aplicación Stateful con una sola instancia:
Objetivo: no terminar esta aplicación sin primero confirmar conmigo.
Posible Solución 1: No usar un PDB y tolerar inactividad ocasional.
Posible Solución 2: Crea un PDB con maxUnavailable=0. Entiende que el operador del cluster debe consultar contigo antes de terminar tu aplicación. Cuando el operador te contacte, prepara tu aplicación para downtime y elimina el PDB para indicar que estas preparado para la disrupción. Crea el PDB de nuevo al terminar la disrupción.
Aplicación Stateful con múltiples instancias como Consul, ZooKeeper, etcd, Redis o MySQL:
Objetivo: no reducir el numero de instancias por debajo del quorum, de lo contrario, las escrituras fallarían.
Posible Solución 1: fijar maxUnavailable a 1 (funciona con diferentes escalas de aplicación).
Posible Solución 2: fijar minAvailable al tamaño del quorum (e.g. 3 cuando hay un total de 5 instancias). (Permite mas disrupciones a la vez.).
Trabajos por lote reiniciables:
Objetivo: El trabajo debe completarse en caso de una interrupción voluntaria.
Posible solución: No cree un PDB. El controlador de Jobs creará un pod de reemplazo.
Especificando un PodDisruptionBudget
Un PodDisruptionBudget tiene tres atributos:
Un label selector .spec.selector para especificar el grupo de
pods donde aplicar el presupuesto. Este campo es requerido.
.spec.minAvailable que es una descripción del número de pods del grupo que deben estar disponibles después del desalojo, incluso en ausencia del pod desalojado. minAvailable puede ser un número absoluto o un porcentaje.
.spec.maxUnavailable (disponible en Kubernetes 1.7 y superior) que es una descripción
del numero de pods del grupo que pueden estar indisponibles despues del desalojo. Puede ser un número absoluto o un porcentaje.
Nota: Para las versiones 1.8 y anteriores: al crear un PodDisruptionBudget
utilizando la herramienta de línea de comandos kubectl, el campo minAvailable es 1 por defecto si no se especifica minAvailable ni maxUnavailable.
Puedes especificar únicamente un valor para maxUnavailable y minAvailable por PodDisruptionBudget.
maxUnavailable solo se puede usar para controlar el desalojo de pods
que tienen un controlador asociado manejándolos. En los ejemplos a continuación, "réplicas deseadas"
hace referencia al valor 'scale' del controlador que gestiona el grupo de pods seleccionados por el
PodDisruptionBudget.
Ejemplo 1: Con un minAvailable de 5, se permiten los desalojos siempre que dejen
5 o más pods disponibles entre las seleccionadas por el selector del PodDisruptionBudget.
Ejemplo 2: Con un minAvailable del 30%, se permiten los desalojos mientras que al menos 30% de la cantidad de réplicas se mantengan disponibles.
Ejemplo 3: Con un maxUnavailable de 5, se permiten desalojos siempre que haya como máximo 5
réplicas indisponibles entre el número total de réplicas deseadas.
Ejemplo 4: Con un maxUnavailable de 30%, se permiten los desalojos siempre y cuando no más del 30%
de las réplicas esten indisponibles.
En el uso típico, se usaría un solo presupuesto para una colección de pods administrados por
un controlador, por ejemplo, los pods en un solo ReplicaSet o StatefulSet.
Nota: Un presupuesto de disrupción no garantiza que el número/porcentaje de pods especificado
siempre estarán disponibles. Por ejemplo, un nodo que alberga un
pod del grupo puede fallar cuando el grupo está en el tamaño mínimo
especificados en el presupuesto, lo que hace que el número de pods disponibles este por debajo del tamaño especificado. El presupuesto solo puede proteger contra
desalojos voluntarios, pero no todas las causas de indisponibilidad.
Un maxUnavailable de 0% (o 0) o un minAvailable de 100% (o igual al
número de réplicas) puede prevenir que los nodos sean purgados completamente.
Esto está permitido según la semántica de PodDisruptionBudget.
Puedes encontrar ejemplos de presupuestos de disrupción de pods definidas a continuación. Los ejemplos aplican al grupo de pods que tienen la etiqueta app: zookeeper.
Por ejemplo, si el objeto anterior zk-pdb selecciona los pods de un StatefulSet de tamaño 3, ambas
especificaciones tienen el mismo significado exacto. Se recomienda el uso de maxUnavailable ya que
responde automáticamente a los cambios en el número de réplicas del controlador correspondiente.
Crea el objeto PDB
Puedes crear el objeto PDB con el comando kubectl apply -f mypdb.yaml.
No puedes actualizar objetos PDB. Deben ser eliminados y recreados.
Comprueba el estado del PDB
Utiliza kubectl para comprobar que se ha creado tu PDB.
Suponiendo que en realidad no tengas pods que coincidan con app: zookeeper en su namespace,
entonces verás algo como esto:
kubectl get poddisruptionbudgets
NAME MIN-AVAILABLE ALLOWED-DISRUPTIONS AGE
zk-pdb 2 0 7s
Si hay pods que coinciden (por ejemplo, 3), entonces debes ver algo similar a esto:
kubectl get poddisruptionbudgets
NAME MIN-AVAILABLE ALLOWED-DISRUPTIONS AGE
zk-pdb 2 1 7s
El valor distinto a cero de ALLOWED-DISRUPTIONS significa que el controlador de disrupción ha visto los pods, contó los pods coincidentes, y actualizó el estado del PDB.
Puedes obtener más información sobre el estado de un PDB con este comando:
Por último, los PodDisruptionBudgets también se pueden consultar con kubectl utilizando el nombre corto pdb:
kubectl get pdb
NAME MIN-AVAILABLE ALLOWED-DISRUPTIONS AGE
zk-pdb 20 7s
Controladores y selectors arbitrarios
Puedes omitir esta sección si solo utilizas PDBs con los controladores integrados de aplicaciones (Deployment, Replicationcontrolador, ReplicaSet y StatefulSet), con el selector de PDB coincidiendo con el selector del controlador.
Puedes utilizar un PDB con pods controlados por otro tipo de controlador, por un
"Operator", o pods individuales, pero con las siguientes restricciones:
solo puedes usar .spec.minAvailable, no .spec.maxUnavailable.
solo puedes usar un número entero en .spec.minAvailable, no un porcentaje.
Puedes usar un selector que selecciona un subconjunto o superconjunto de los pods que pertenecen a un controlador incorporado. Sin embargo, cuando hay varios PDB en un namespace, debes tener cuidado de no
crear PDBs cuyos selectores se superponen.
7 - Gestionar y ejecutar daemons
8 - Gestionar y ejecutar trabajos
9 - Acceder al clúster y las aplicaciones
10 - Monitorización, Logs y Debugging
10.1 - Auditoría
La auditoría de Kubernetes proporciona un conjunto de registros cronológicos referentes a la seguridad
que documentan la secuencia de actividades que tanto los usuarios individuales, como
los administradores y otros componentes del sistema ha realizado en el sistema.
Así, permite al administrador del clúster responder a las siguientes cuestiones:
¿qué ha pasado?
¿cuándo ha pasado?
¿quién lo ha iniciado?
¿sobre qué ha pasado?
¿dónde se ha observado?
¿desde dónde se ha iniciado?
¿hacia dónde iba?
El componente Kube-apiserver lleva a cabo la auditoría. Cada petición en cada fase
de su ejecución genera un evento, que se pre-procesa según un cierto reglamento y
se escribe en un backend. Este reglamento determina lo que se audita
y los backends persisten los registros. Las implementaciones actuales de backend
incluyen los archivos de logs y los webhooks.
Cada petición puede grabarse junto con una "etapa" asociada. Las etapas conocidas son:
RequestReceived - La etapa para aquellos eventos generados tan pronto como
el responsable de la auditoría recibe la petición, pero antes de que sea delegada al
siguiente responsable en la cadena.
ResponseStarted - Una vez que las cabeceras de la respuesta se han enviado,
pero antes de que el cuerpo de la respuesta se envíe. Esta etapa sólo se genera
en peticiones de larga duración (ej. watch).
ResponseComplete - El cuerpo de la respuesta se ha completado y no se enviarán más bytes.
Panic - Eventos que se generan cuando ocurre una situación de pánico.
Nota: La característica de registro de auditoría incrementa el consumo de memoria del servidor API
porque requiere de contexto adicional para lo que se audita en cada petición.
De forma adicional, el consumo de memoria depende de la configuración misma del registro.
Reglamento de Auditoría
El reglamento de auditoría define las reglas acerca de los eventos que deberían registrarse y
los datos que deberían incluir. La estructura del objeto de reglas de auditoría se define
en el audit.k8s.io grupo de API. Cuando se procesa un evento, se compara
con la lista de reglas en orden. La primera regla coincidente establece el "nivel de auditoría"
del evento. Los niveles de auditoría conocidos son:
None - no se registra eventos que disparan esta regla.
Metadata - se registra los metadatos de la petición (usuario que la realiza, marca de fecha y hora, recurso,
verbo, etc.), pero no la petición ni el cuerpo de la respuesta.
Request - se registra los metadatos del evento y el cuerpo de la petición, pero no el cuerpo de la respuesta.
Esto no aplica para las peticiones que no son de recurso.
RequestResponse - se registra los metadatos del evento, y los cuerpos de la petición y la respuesta.
Esto no aplica para las peticiones que no son de recurso.
Es posible indicar un archivo al definir el reglamento en el kube-apiserver
usando el parámetro --audit-policy-file. Si dicho parámetros se omite, no se registra ningún evento.
Nótese que el campo rulesdebe proporcionarse en el archivo del reglamento de auditoría.
Un reglamento sin (0) reglas se considera ilegal.
Abajo se presenta un ejemplo de un archivo de reglamento de auditoría:
apiVersion:audit.k8s.io/v1# Esto es obligatorio.kind:Policy# No generar eventos de auditoría para las peticiones en la etapa RequestReceived.omitStages:- "RequestReceived"rules:# Registrar los cambios del pod al nivel RequestResponse- level:RequestResponseresources:- group:""# Los recursos "pods" no hacen coincidir las peticiones a cualquier sub-recurso de pods,# lo que es consistente con la regla RBAC.resources:["pods"]# Registrar "pods/log", "pods/status" al nivel Metadata- level:Metadataresources:- group:""resources:["pods/log","pods/status"]# No registrar peticiones al configmap denominado "controller-leader"- level:Noneresources:- group:""resources:["configmaps"]resourceNames:["controller-leader"]# No registrar peticiones de observación hechas por "system:kube-proxy" sobre puntos de acceso o servicios- level:Noneusers:["system:kube-proxy"]verbs:["watch"]resources:- group:""# Grupo API baseresources:["endpoints","services"]# No registrar peticiones autenticadas a ciertas rutas URL que no son recursos.- level:NoneuserGroups:["system:authenticated"]nonResourceURLs:- "/api*"# Coincidencia por comodín.- "/version"# Registrar el cuerpo de la petición de los cambios de configmap en kube-system.- level:Requestresources:- group:""# Grupo API baseresources:["configmaps"]# Esta regla sólo aplica a los recursos en el Namespace "kube-system".# La cadena vacía "" se puede usar para seleccionar los recursos sin Namespace.namespaces:["kube-system"]# Registrar los cambios de configmap y secret en todos los otros Namespaces al nivel Metadata.- level:Metadataresources:- group:""# Grupo API baseresources:["secrets","configmaps"]# Registrar todos los recursos en core y extensions al nivel Request.- level:Requestresources:- group:""# Grupo API base- group:"extensions"# La versión del grupo NO debería incluirse.# Regla para "cazar" todos las demás peticiones al nivel Metadata.- level:Metadata# Las peticiones de larga duración, como los watches, que caen bajo esta regla no# generan un evento de auditoría en RequestReceived.omitStages:- "RequestReceived"
Puedes usar un archivo mínimo de reglamento de auditoría para registrar todas las peticiones al nivel Metadata de la siguiente forma:
# Log all requests at the Metadata level.apiVersion:audit.k8s.io/v1kind:Policyrules:- level:Metadata
El perfil de auditoría utilizado por GCE debería servir como referencia para
que los administradores construyeran sus propios perfiles de auditoría.
Backends de auditoría
Los backends de auditoría persisten los eventos de auditoría en un almacenamiento externo.
El Kube-apiserver por defecto proporciona tres backends:
Backend de logs, que escribe los eventos en disco
Backend de webhook, que envía los eventos a una API externa
Backend dinámico, que configura backends de webhook a través de objetos de la API AuditSink.
En todos los casos, la estructura de los eventos de auditoría se define por la API del grupo
audit.k8s.io. La versión actual de la API es
v1.
Nota:
En el caso de parches, el cuerpo de la petición es una matriz JSON con operaciones de parcheado, en vez
de un objeto JSON que incluya el objeto de la API de Kubernetes apropiado. Por ejemplo,
el siguiente cuerpo de mensaje es una petición de parcheado válida para
/apis/batch/v1/namespaces/some-namespace/jobs/some-job-name.
El backend de logs escribe los eventos de auditoría a un archivo en formato JSON.
Puedes configurar el backend de logs de auditoría usando el siguiente
parámetro de kube-apiserver flags:
--audit-log-path especifica la ruta al archivo de log que el backend utiliza para
escribir los eventos de auditoría. Si no se especifica, se deshabilita el backend de logs. - significa salida estándar
--audit-log-maxage define el máximo número de días a retener los archivos de log
--audit-log-maxbackup define el máximo número de archivos de log a retener
--audit-log-maxsize define el tamaño máximo en megabytes del archivo de logs antes de ser rotado
Backend de Webhook
El backend de Webhook envía eventos de auditoría a una API remota, que se supone es la misma API
que expone el kube-apiserver. Puedes configurar el backend de webhook de auditoría usando
los siguientes parámetros de kube-apiserver:
--audit-webhook-config-file especifica la ruta a un archivo con configuración del webhook.
La configuración del webhook es, de hecho, un archivo kubeconfig.
--audit-webhook-initial-backoff especifica la cantidad de tiempo a esperar tras una petición fallida
antes de volver a intentarla. Los reintentos posteriores se ejecutan con retraso exponencial.
El archivo de configuración del webhook usa el formato kubeconfig para especificar la dirección remota
del servicio y las credenciales para conectarse al mismo.
En la versión 1.13, los backends de webhook pueden configurarse dinámicamente.
Procesamiento por lotes
Tanto el backend de logs como el de webhook permiten procesamiento por lotes. Si usamos el webhook como ejemplo,
aquí se muestra la lista de parámetros disponibles. Para aplicar el mismo parámetro al backend de logs,
simplemente sustituye webhook por log en el nombre del parámetro. Por defecto,
el procesimiento por lotes está habilitado en webhook y deshabilitado en log. De forma similar,
por defecto la regulación (throttling) está habilitada en webhook y deshabilitada en log.
--audit-webhook-mode define la estrategia de memoria intermedia (búfer), que puede ser una de las siguientes:
batch - almacenar eventos y procesarlos de forma asíncrona en lotes. Esta es la estrategia por defecto.
blocking - bloquear todas las respuestas del servidor API al procesar cada evento de forma individual.
blocking-strict - igual que blocking, pero si ocurre un error durante el registro de la audtoría en la etapa RequestReceived, la petición completa al apiserver fallará.
Los siguientes parámetros se usan únicamente en el modo batch:
--audit-webhook-batch-buffer-size define el número de eventos a almacenar de forma intermedia antes de procesar por lotes.
Si el ritmo de eventos entrantes desborda la memoria intermedia, dichos eventos se descartan.
--audit-webhook-batch-max-size define el número máximo de eventos en un único proceso por lotes.
--audit-webhook-batch-max-wait define la cantidad máxima de tiempo a esperar de forma incondicional antes de procesar los eventos de la cola.
--audit-webhook-batch-throttle-qps define el promedio máximo de procesos por lote generados por segundo.
--audit-webhook-batch-throttle-burst define el número máximo de procesos por lote generados al mismo tiempo si el QPS permitido no fue usado en su totalidad anteriormente.
Ajuste de parámetros
Los parámetros deberían ajustarse a la carga del apiserver.
Por ejemplo, si kube-apiserver recibe 100 peticiones por segundo, y para cada petición se audita
las etapas ResponseStarted y ResponseComplete, deberías esperar unos ~200
eventos de auditoría generados por segundo. Asumiendo que hay hasta 100 eventos en un lote,
deberías establecer el nivel de regulación (throttling) por lo menos a 2 QPS. Además, asumiendo
que el backend puede tardar hasta 5 segundos en escribir eventos, deberías configurar el tamaño de la memoria intermedia para almacenar hasta 5 segundos de eventos, esto es,
10 lotes, o sea, 1000 eventos.
En la mayoría de los casos, sin embargo, los valores por defecto de los parámetros
deberían ser suficientes y no deberías preocuparte de ajustarlos manualmente.
Puedes echar un vistazo a la siguientes métricas de Prometheus que expone kube-apiserver
y también los logs para monitorizar el estado del subsistema de auditoría:
apiserver_audit_event_total métrica que contiene el número total de eventos de auditoría exportados.
apiserver_audit_error_total métrica que contiene el número total de eventos descartados debido a un error durante su exportación.
Truncado
Tanto el backend de logs como el de webhook permiten truncado. Como ejemplo, aquí se indica la
lista de parámetros disponible para el backend de logs:
audit-log-truncate-enabled indica si el truncado de eventos y por lotes está habilitado.
audit-log-truncate-max-batch-size indica el tamaño máximo en bytes del lote enviado al backend correspondiente.
audit-log-truncate-max-event-size indica el tamaño máximo en bytes del evento de auditoría enviado al backend correspondiente.
Por defecto, el truncado está deshabilitado tanto en webhook como en log; un administrador del clúster debe configurar bien el parámetro audit-log-truncate-enabled o audit-webhook-truncate-enabled para habilitar esta característica.
Backend dinámico
FEATURE STATE:Kubernetes v1.13 [alpha]
En la versión 1.13 de Kubernetes, puedes configurar de forma dinámica los backends de auditoría usando objetos de la API AuditSink.
Para habilitar la auditoría dinámica, debes configurar los siguientes parámetros de apiserver:
--audit-dynamic-configuration: el interruptor principal. Cuando esta característica sea GA, el único parámetro necesario.
--feature-gates=DynamicAuditing=true: en evaluación en alpha y beta.
--runtime-config=auditregistration.k8s.io/v1alpha1=true: habilitar la API.
Cuando se habilita, un objeto AuditSink se provisiona de la siguiente forma:
Para una definición completa de la API, ver AuditSink. Múltiples objetos existirán como soluciones independientes.
Aquellos backends estáticos que se configuran con parámetros en tiempo de ejecución no se ven impactados por esta característica.
Sin embargo, estos backends dinámicos comparten las opciones de truncado del webhook estático, de forma que si dichas opciones se configura con parámetros en tiempo de ejecución, entonces se aplican a todos los backends dinámicos.
Reglamento
El reglamento de AuditSink es diferente del de la auditoría en tiempo de ejecución. Esto es debido a que el objeto de la API sirve para casos de uso diferentes. El reglamento continuará
evolucionando para dar cabida a más casos de uso.
El campo level establece el nivel de auditoría indicado a todas las peticiones. El campo stages es actualmente una lista de las etapas que se permite registrar.
Seguridad
Los administradores deberían tener en cuenta que permitir el acceso en modo escritura de esta característica otorga el modo de acceso de lectura
a toda la información del clúster. Así, el acceso debería gestionarse como un privilegio de nivel cluster-admin.
Rendimiento
Actualmente, esta característica tiene implicaciones en el apiserver en forma de incrementos en el uso de la CPU y la memoria.
Aunque debería ser nominal cuando se trata de un número pequeño de destinos, se realizarán pruebas adicionales de rendimiento para entender su impacto real antes de que esta API pase a beta.
Configuración multi-clúster
Si estás extendiendo la API de Kubernetes mediante la capa de agregación, puedes también
configurar el registro de auditoría para el apiserver agregado. Para ello, pasa las opciones
de configuración en el mismo formato que se describe arriba al apiserver agregado
y configura el mecanismo de ingestión de logs para que recolecte los logs de auditoría.
Cada uno de los apiservers puede tener configuraciones de auditoría diferentes con
diferentes reglamentos de auditoría.
Ejemplos de recolectores de Logs
Uso de fluentd para recolectar y distribuir eventos de auditoría a partir de un archivo de logs
Fluentd es un recolector de datos de libre distribución que proporciona una capa unificada de registros.
En este ejemplo, usaremos fluentd para separar los eventos de auditoría por nombres de espacio:
Instala fluentd, fluent-plugin-forest y fluent-plugin-rewrite-tag-filter en el nodo donde corre kube-apiserver
Nota: Fluent-plugin-forest y fluent-plugin-rewrite-tag-filter son plugins de fluentd. Puedes obtener detalles de la instalación de estos plugins en el documento [fluentd plugin-management][fluentd_plugin_management_doc].
Crea un archivo de configuración para fluentd:
cat <<'EOF' > /etc/fluentd/config
# fluentd conf runs in the same host with kube-apiserver
<source>
@type tail
# audit log path of kube-apiserver
path /var/log/kube-audit
pos_file /var/log/audit.pos
format json
time_key time
time_format %Y-%m-%dT%H:%M:%S.%N%z
tag audit
</source>
<filter audit>
#https://github.com/fluent/fluent-plugin-rewrite-tag-filter/issues/13
@type record_transformer
enable_ruby
<record>
namespace ${record["objectRef"].nil? ? "none":(record["objectRef"]["namespace"].nil? ? "none":record["objectRef"]["namespace"])}
</record>
</filter>
<match audit>
# route audit according to namespace element in context
@type rewrite_tag_filter
<rule>
key namespace
pattern /^(.+)/
tag ${tag}.$1
</rule>
</match>
<filter audit.**>
@type record_transformer
remove_keys namespace
</filter>
<match audit.**>
@type forest
subtype file
remove_prefix audit
<template>
time_slice_format %Y%m%d%H
compress gz
path /var/log/audit-${tag}.*.log
format json
include_time_key true
</template>
</match>
EOF
Arranca fluentd:
fluentd -c /etc/fluentd/config -vv
Arranca el componente kube-apiserver con las siguientes opciones:
Comprueba las auditorías de los distintos espacios de nombres en /var/log/audit-*.log
Uso de logstash para recolectar y distribuir eventos de auditoría desde un backend de webhook
Logstash es una herramienta de libre distribución de procesamiento de datos en servidor.
En este ejemplo, vamos a usar logstash para recolectar eventos de auditoría a partir de un backend de webhook,
y grabar los eventos de usuarios diferentes en archivos distintos.
cat <<EOF > /etc/logstash/config
input{
http{
#TODO, figure out a way to use kubeconfig file to authenticate to logstash
#https://www.elastic.co/guide/en/logstash/current/plugins-inputs-http.html#plugins-inputs-http-ssl
port=>8888
}
}
filter{
split{
# Webhook audit backend sends several events together with EventList
# split each event here.
field=>[items]
# We only need event subelement, remove others.
remove_field=>[headers, metadata, apiVersion, "@timestamp", kind, "@version", host]
}
mutate{
rename => {items=>event}
}
}
output{
file{
# Audit events from different users will be saved into different files.
path=>"/var/log/kube-audit-%{[event][user][username]}/audit"
}
}
EOF
Comprueba las auditorías en los directorios /var/log/kube-audit-*/audit de los nodos de logstash
Nótese que además del plugin para salida en archivos, logstash ofrece una variedad de salidas adicionales
que permiten a los usuarios enviar la información donde necesiten. Por ejemplo, se puede enviar los eventos de auditoría
al plugin de elasticsearch que soporta búsquedas avanzadas y analíticas.
10.2 - Depurar Contenedores de Inicialización
Esta página muestra cómo investigar problemas relacionados con la ejecución
de los contenedores de inicialización (init containers). Las líneas de comando del ejemplo de abajo
se refieren al Pod como <pod-name> y a los Init Containers como <init-container-1> e
<init-container-2> respectivamente.
Antes de empezar
Debes tener un cluster Kubernetes a tu dispocición, y la herramienta de línea de comandos kubectl debe estar configurada. Si no tienes un cluster, puedes crear uno utilizando Minikube,
o puedes utilizar una de las siguientes herramientas en línea:
También puedes acceder al estado del Init Container de forma programática mediante
la lectura del campo status.initContainerStatuses dentro del Pod Spec:
kubectl get pod nginx --template '{{.status.initContainerStatuses}}'
Este comando devolverá la misma información que arriba en formato JSON.
Acceder a los logs de los Init Containers
Indica el nombre del Init Container así como el nombre del Pod para
acceder a sus logs.
kubectl logs <pod-name> -c <init-container-2>
Los Init Containers que ejecutan secuencias de línea de comandos muestran los comandos
conforme se van ejecutando. Por ejemplo, puedes hacer lo siguiente en Bash
indicando set -x al principio de la secuencia.
Comprender el estado de un Pod
Un estado de un Pod que comienza con Init: especifica el estado de la ejecución de
un Init Container. La tabla a continuación muestra algunos valores de estado de ejemplo
que puedes encontrar al depurar Init Containers.
Estado
Significado
Init:N/M
El Pod tiene M Init Containers, y por el momento se han completado N.
Init:Error
Ha fallado la ejecución de un Init Container.
Init:CrashLoopBackOff
Un Init Container ha fallado de forma repetida.
Pending
El Pod todavía no ha comenzado a ejecutar sus Init Containers.
PodInitializing o Running
El Pod ya ha terminado de ejecutar sus Init Containers.
10.3 - Escribiendo Logs con Elasticsearch y Kibana
Este artículo describe cómo configurar un clúster para la ingesta de logs en
Elasticsearch y su posterior visualización
con Kibana, a modo de alternativa a
Stackdriver Logging cuando se utiliza la plataforma GCE.
Nota: No se puede desplegar de forma automática Elasticsearch o Kibana en un clúster alojado en Google Kubernetes Engine. Hay que desplegarlos de forma manual.
Para utilizar Elasticsearch y Kibana para escritura de logs del clúster, deberías configurar
la siguiente variable de entorno que se muestra a continuación como parte de la creación
del clúster con kube-up.sh:
KUBE_LOGGING_DESTINATION=elasticsearch
También deberías asegurar que KUBE_ENABLE_NODE_LOGGING=true (que es el valor por defecto en la plataforma GCE).
Así, cuando crees un clúster, un mensaje te indicará que la recolección de logs de los daemons de Fluentd
que corren en cada nodo enviará dichos logs a Elasticsearch:
cluster/kube-up.sh
...
Project: kubernetes-satnam
Zone: us-central1-b
... calling kube-up
Project: kubernetes-satnam
Zone: us-central1-b
+++ Staging server tars to Google Storage: gs://kubernetes-staging-e6d0e81793/devel
+++ kubernetes-server-linux-amd64.tar.gz uploaded (sha1 = 6987c098277871b6d69623141276924ab687f89d)
+++ kubernetes-salt.tar.gz uploaded (sha1 = bdfc83ed6b60fa9e3bff9004b542cfc643464cd0)
Looking for already existing resources
Starting master and configuring firewalls
Created [https://www.googleapis.com/compute/v1/projects/kubernetes-satnam/zones/us-central1-b/disks/kubernetes-master-pd].
NAME ZONE SIZE_GB TYPE STATUS
kubernetes-master-pd us-central1-b 20 pd-ssd READY
Created [https://www.googleapis.com/compute/v1/projects/kubernetes-satnam/regions/us-central1/addresses/kubernetes-master-ip].
+++ Logging using Fluentd to elasticsearch
Tanto los pods por nodo de Fluentd, como los pods de Elasticsearch, y los pods de Kibana
deberían ejecutarse en el namespace de kube-system inmediatamente después
de que el clúster esté disponible.
Los pods de fluentd-elasticsearch recogen los logs de cada nodo y los envían a los
pods de elasticsearch-logging, que son parte de un servicio llamado elasticsearch-logging.
Estos pods de Elasticsearch almacenan los logs y los exponen via una API REST.
El pod de kibana-logging proporciona una UI via web donde leer los logs almacenados en
Elasticsearch, y es parte de un servicio denominado kibana-logging.
Los servicios de Elasticsearch y Kibana ambos están en el namespace kube-system
y no se exponen de forma directa mediante una IP accesible públicamente. Para poder acceder a dichos logs,
sigue las instrucciones acerca de cómo Acceder a servicios corriendo en un clúster.
Si tratas de acceder al servicio de elasticsearch-logging desde tu navegador,
verás una página de estado que se parece a la siguiente:
A partir de ese momento, puedes introducir consultas de Elasticsearch directamente en el navegador, si lo necesitas.
Echa un vistazo a la documentación de Elasticsearch
para más detalles acerca de cómo hacerlo.
De forma alternativa, puedes ver los logs de tu clúster en Kibana (de nuevo usando las
instrucciones para acceder a un servicio corriendo en un clúster).
La primera vez que visitas la URL de Kibana se te presentará una página que te pedirá
que configures una vista de los logs. Selecciona la opción de valores de serie temporal
y luego @timestamp. En la página siguiente selecciona la pestaña de Discover
y entonces deberías ver todos los logs. Puedes establecer el intervalo de actualización
en 5 segundos para refrescar los logs de forma regular.
Aquí se muestra una vista típica de logs desde el visor de Kibana:
Siguientes pasos
¡Kibana te permite todo tipo de potentes opciones para explorar tus logs! Puedes encontrar
algunas ideas para profundizar en el tema en la documentación de Kibana.
Nota: Por defecto, Stackdriver recolecta toda la salida estándar de tus contenedores, así
como el flujo de la salida de error. Para recolectar cualquier log tu aplicación escribe en un archivo (por ejemplo),
ver la estrategia de sidecar
en el resumen de escritura de logs en Kubernetes.
Despliegue
Para ingerir logs, debes desplegar el agente de Stackdriver Logging en cada uno de los nodos de tu clúster.
Dicho agente configura una instancia de fluentd, donde la configuración se guarda en un ConfigMap
y las instancias se gestionan a través de un DaemonSet de Kubernetes. El despliegue actual del
ConfigMap y el DaemonSet dentro de tu clúster depende de tu configuración individual del clúster.
Desplegar en un nuevo clúster
Google Kubernetes Engine
Stackdriver es la solución por defecto de escritura de logs para aquellos clústeres desplegados en Google Kubernetes Engine.
Stackdriver Logging se despliega por defecto en cada clúster a no ser que se le indique de forma explícita no hacerlo.
Otras plataformas
Para desplegar Stackdriver Logging en un nuevo clúster que estés creando con
kube-up.sh, haz lo siguiente:
Configura la variable de entorno KUBE_LOGGING_DESTINATION con el valor gcp.
Si no estás trabajando en GCE, incluye beta.kubernetes.io/fluentd-ds-ready=true
en la variable KUBE_NODE_LABELS.
Una vez que tu clúster ha arrancado, cada nodo debería ejecutar un agente de Stackdriver Logging.
Los DaemonSet y ConfigMap se configuran como extras. Si no estás usando kube-up.sh,
considera la posibilidad de arrancar un clúster sin una solución pre-determinada de escritura de logs
y entonces desplegar los agentes de Stackdriver Logging una vez el clúster esté ejecutándose.
Advertencia: El proceso de Stackdriver Logging reporta problemas conocidos en plataformas distintas
a Google Kubernetes Engine. Úsalo bajo tu propio riesgo.
Desplegar a un clúster existente
Aplica una etiqueta en cada nodo, si no estaba presente ya.
El despliegue del agente de Stackdriver Logging utiliza etiquetas de nodo para
determinar en qué nodos debería desplegarse. Estas etiquetas fueron introducidas
para distinguir entre nodos de Kubernetes de la versión 1.6 o superior.
Si el clúster se creó con Stackdriver Logging configurado y el nodo tiene la
versión 1.5.X o inferior, ejecutará fluentd como un pod estático. Puesto que un nodo
no puede tener más de una instancia de fluentd, aplica únicamente las etiquetas
a los nodos que no tienen un pod de fluentd ya desplegado. Puedes confirmar si tu nodo
ha sido etiquetado correctamente ejecutando kubectl describe de la siguiente manera:
Asegúrate que la salida contiene la etiqueta beta.kubernetes.io/fluentd-ds-ready=true.
Si no está presente, puedes añadirla usando el comando kubectl label como se indica:
Nota: Si un nodo falla y tiene que volver a crearse, deberás volver a definir
la etiqueta al nuevo nodo. Para facilitar esta tarea, puedes utilizar el
parámetro de línea de comandos del Kubelet para aplicar dichas etiquetas
cada vez que se arranque un nodo.
Despliega un ConfigMap con la configuración del agente de escritura de logs ejecutando el siguiente comando:
Este comando crea el ConfigMap en el espacio de nombres default. Puedes descargar el archivo
manualmente y cambiarlo antes de crear el objeto ConfigMap.
Despliega el agente DaemonSet de escritura de logs ejecutando el siguiente comando:
Puedes descargar y editar este archivo antes de usarlo igualmente.
Verificar el despliegue de tu agente de escritura de logs
Tras el despliegue del DaemonSet de StackDriver, puedes comprobar el estado de
cada uno de los despliegues de los agentes ejecutando el siguiente comando:
kubectl get ds --all-namespaces
Si tienes 3 nodos en el clúster, la salida debería ser similar a esta:
NAMESPACE NAME DESIRED CURRENT READY NODE-SELECTOR AGE
...
default fluentd-gcp-v2.0 3 3 3 beta.kubernetes.io/fluentd-ds-ready=true 5m
...
Para comprender cómo funciona Stackdriver, considera la siguiente especificación
de un generador de logs sintéticos counter-pod.yaml:
apiVersion:v1kind:Podmetadata:name:counterspec:containers:- name:countimage:busyboxargs:[/bin/sh, -c,'i=0; while true; do echo "$i: $(date)"; i=$((i+1)); sleep 1; done']
Esta especificación de pod tiene un contenedor que ejecuta una secuencia de comandos bash
que escribe el valor de un contador y la fecha y hora cada segundo, de forma indefinida.
Vamos a crear este pod en el espacio de nombres por defecto.
NAME READY STATUS RESTARTS AGE
counter 1/1 Running 0 5m
Durante un período de tiempo corto puedes observar que el estado del pod es 'Pending', debido a que el kubelet
tiene primero que descargar la imagen del contenedor. Cuando el estado del pod cambia a Running
puedes usar el comando kubectl logs para ver la salida de este pod contador.
kubectl logs counter
0: Mon Jan 1 00:00:00 UTC 2001
1: Mon Jan 1 00:00:01 UTC 2001
2: Mon Jan 1 00:00:02 UTC 2001
...
Como se describe en el resumen de escritura de logs, este comando visualiza las entradas de logs
del archivo de logs del contenedor. Si se termina el contenedor y Kubernetes lo reinicia,
todavía puedes acceder a los logs de la ejecución previa del contenedor. Sin embargo,
si el pod se desaloja del nodo, los archivos de log se pierden. Vamos a demostrar este
comportamiento mediante el borrado del contenedor que ejecuta nuestro contador:
Tras un tiempo, puedes acceder a los logs del pod contador otra vez:
kubectl logs counter
0: Mon Jan 1 00:01:00 UTC 2001
1: Mon Jan 1 00:01:01 UTC 2001
2: Mon Jan 1 00:01:02 UTC 2001
...
Como era de esperar, únicamente se visualizan las líneas de log recientes. Sin embargo,
para una aplicación real seguramente prefieras acceder a los logs de todos los contenedores,
especialmente cuando te haga falta depurar problemas. Aquí es donde haber habilitado
Stackdriver Logging puede ayudarte.
Ver logs
El agente de Stackdriver Logging asocia metadatos a cada entrada de log, para que puedas usarlos posteriormente
en consultas para seleccionar sólo los mensajes que te interesan: por ejemplo,
los mensajes de un pod en particular.
Los metadatos más importantes son el tipo de recurso y el nombre del log.
El tipo de recurso de un log de contenedor tiene el valor container, que se muestra como
GKE Containers en la UI (incluso si el clúster de Kubernetes no está en Google Kubernetes Engine).
El nombre de log es el nombre del contenedor, de forma que si tienes un pod con
dos contenedores, denominados container_1 y container_2 en la especificación, sus logs
tendrán los nombres container_1 y container_2 respectivamente.
Los componentes del sistema tienen el valor compute como tipo de recursos, que se muestra como
GCE VM Instance en la UI. Los nombres de log para los componentes del sistema son fijos.
Para un nodo de Google Kubernetes Engine, cada entrada de log de cada componente de sistema tiene uno de los siguientes nombres:
Uno de los posibles modos de ver los logs es usando el comando de línea de interfaz
gcloud logging
del SDK de Google Cloud.
Este comando usa la sintaxis de filtrado de StackDriver Logging
para consultar logs específicos. Por ejemplo, puedes ejecutar el siguiente comando:
...
"2: Mon Jan 1 00:01:02 UTC 2001\n"
"1: Mon Jan 1 00:01:01 UTC 2001\n"
"0: Mon Jan 1 00:01:00 UTC 2001\n"
...
"2: Mon Jan 1 00:00:02 UTC 2001\n"
"1: Mon Jan 1 00:00:01 UTC 2001\n"
"0: Mon Jan 1 00:00:00 UTC 2001\n"
Como puedes observar, muestra los mensajes del contenedor contador tanto de la
primera como de la segunda ejecución, a pesar de que el kubelet ya había eliminado los logs del primer contenedor.
Exportar logs
Puedes exportar los logs al Google Cloud Storage
o a BigQuery para llevar a cabo un análisis más profundo.
Stackdriver Logging ofrece el concepto de destinos, donde puedes especificar el destino de
las entradas de logs. Más información disponible en la página de exportación de logs de StackDriver.
Configurar los agentes de Stackdriver Logging
En ocasiones la instalación por defecto de Stackdriver Logging puede que no se ajuste a tus necesidades, por ejemplo:
Puede que quieras añadir más recursos porque el rendimiento por defecto no encaja con tus necesidades.
Puede que quieras añadir un parseo adicional para extraer más metadatos de tus mensajes de log,
como la severidad o referencias al código fuente.
Puede que quieras enviar los logs no sólo a Stackdriver o sólo enviarlos a Stackdriver parcialmente.
En cualquiera de estos casos, necesitas poder cambiar los parámetros del DaemonSet y el ConfigMap.
Prerequisitos
Si estás usando GKE y Stackdriver Logging está habilitado en tu clúster, no puedes
cambiar su configuración, porque ya está gestionada por GKE.
Sin embargo, puedes deshabilitar la integración por defecto y desplegar la tuya propia.
Nota: Tendrás que mantener y dar soporte tú mismo a la nueva configuración desplegada:
actualizar la imagen y la configuración, ajustar los recuros y todo eso.
Para deshabilitar la integración por defecto, usa el siguiente comando:
Puedes encontrar notas acerca de cómo instalar los agentes de Stackdriver Logging
en un clúster ya ejecutándose en la sección de despliegue.
Cambiar los parámetros del DaemonSet
Cuando tienes un DaemonSet de Stackdriver Logging en tu clúster, puedes simplemente
modificar el campo template en su especificación, y el controlador del daemonset actualizará los pods por ti. Por ejemplo,
asumamos que acabas de instalar el Stackdriver Logging como se describe arriba. Ahora quieres cambiar
el límite de memoria que se le asigna a fluentd para poder procesar más logs de forma segura.
Obtén la especificación del DaemonSet que corre en tu clúster:
kubectl get ds fluentd-gcp-v2.0 --namespace kube-system -o yaml > fluentd-gcp-ds.yaml
A continuación, edita los requisitos del recurso en el spec y actualiza el objeto DaemonSet
en el apiserver usando el siguiente comando:
kubectl replace -f fluentd-gcp-ds.yaml
Tras un tiempo, los pods de agente de Stackdriver Logging se reiniciarán con la nueva configuración.
Cambiar los parámetros de fluentd
La configuración de Fluentd se almacena en un objeto ConfigMap. Realmente se trata de un conjunto
de archivos de configuración que se combinan conjuntamente. Puedes aprender acerca de
la configuración de fluentd en el sitio oficial.
Imagina que quieres añadir una nueva lógica de parseo a la configuración actual, de forma que fluentd pueda entender
el formato de logs por defecto de Python. Un filtro apropiado de fluentd para conseguirlo sería:
<filter reform.**>
type parser
format /^(?<severity>\w):(?<logger_name>\w):(?<log>.*)/
reserve_data true
suppress_parse_error_log true
key_name log
</filter>
Ahora tienes que añadirlo a la configuración actual y que los agentes de Stackdriver Logging la usen.
Para ello, obtén la versión actual del ConfigMap de Stackdriver Logging de tu clúster
ejecutando el siguiente comando:
kubectl get cm fluentd-gcp-config --namespace kube-system -o yaml > fluentd-gcp-configmap.yaml
Luego, como valor de la clave containers.input.conf, inserta un nuevo filtro justo después
de la sección source.
Nota: El orden es importante.
Actualizar el ConfigMap en el apiserver es más complicado que actualizar el DaemonSet.
Es mejor considerar que un ConfigMap es inmutable. Así, para poder actualizar la configuración, deberías
crear un nuevo ConfigMap con otro nombre y cambiar el DaemonSet para que apunte al nuevo
siguiendo la guía de arriba.
Añadir plugins de fluentd
Fluentd está desarrollado en Ruby y permite extender sus capacidades mediante el uso de
plugins. Si quieres usar un plugin que no está incluido en
la imagen por defecto del contenedor de Stackdriver Logging, debes construir tu propia imagen.
Imagina que quieres añadir un destino Kafka para aquellos mensajes de un contenedor en particular
para poder procesarlos posteriormente. Puedes reusar los fuentes de imagen de contenedor
con algunos pequeños cambios:
Cambia el archivo Makefile para que apunte a tu repositorio de contenedores, ej. PREFIX=gcr.io/<your-project-id>.
Añade tu dependencia al archivo Gemfile, por ejemplo gem 'fluent-plugin-kafka'.
Luego, ejecuta make build push desde ese directorio. Cuando el DaemonSet haya tomado los cambios de la nueva imagen,
podrás usar el plugin que has indicado en la configuración de fluentd.
10.5 - Pipeline de métricas de recursos
Desde Kubernetes 1.8, las métricas de uso de recursos, tales como el uso de CPU y memoria del contenedor,
están disponibles en Kubernetes a través de la API de métricas. Estas métricas son accedidas directamente
por el usuario, por ejemplo usando el comando kubectl top, o usadas por un controlador en el cluster,
por ejemplo el Horizontal Pod Autoscaler, para la toma de decisiones.
La API de Métricas
A través de la API de métricas, Metrics API en inglés, puedes obtener la cantidad de recursos usados
actualmente por cada nodo o pod. Esta API no almacena los valores de las métricas,
así que no es posible, por ejemplo, obtener la cantidad de recursos que fueron usados por
un nodo hace 10 minutos.
La API de métricas está completamente integrada en la API de Kubernetes:
se expone a través del mismo endpoint que las otras APIs de Kubernetes bajo el path /apis/metrics.k8s.io/
ofrece las mismas garantías de seguridad, escalabilidad y confiabilidad
La API está definida en el repositorio k8s.io/metrics. Puedes encontrar
más información sobre la API ahí.
Nota: La API requiere que el servidor de métricas esté desplegado en el clúster. En otro caso no estará
disponible.
Servidor de Métricas
El Servidor de Métricas es un agregador
de datos de uso de recursos de todo el clúster.
A partir de Kubernetes 1.8, el servidor de métricas se despliega por defecto como un objeto de
tipo Deployment en clústeres
creados con el script kube-up.sh. Si usas otro mecanismo de configuración de Kubernetes, puedes desplegarlo
usando los yamls de despliegue
proporcionados. Está soportado a partir de Kubernetes 1.7 (más detalles al final).
El servidor reune métricas de la Summary API, que es expuesta por el Kubelet en cada nodo.
El servidor de métricas se añadió a la API de Kubernetes utilizando el
Kubernetes aggregator introducido en Kubernetes 1.7.
Puedes aprender más acerca del servidor de métricas en el documento de diseño.
