Tareas

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.

Siguientes pasos

Si quisieras escribir una página de Tareas, echa un vistazo a Crear una Petición de Subida de Documentación.

1 - Instalar herramientas

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.

Ver la guía de instalación y configuración de kubectl

También se puede leer la documentación de referencia de kubectl.

kind

kind le permite usar Kubernetes en su máquina local. Esta herramienta require que Docker instalado y configurado.

En la página de inicio rápido encontrarás toda la información necesaria para empezar con kind.

Ver la guía de inicio rápido

minikube

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.

Ver la guía de minikube

Una vez minikube ha terminado de instalarse, está lista para desplegar un aplicación de ejemplo (/docs/tutorials/hello-minikube/).

kubeadm

Se puede usar la utilidad kubeadm para crear y gestionar clústeres de Kubernetes.

En instalando kubeadm se muestra como instalar kubeadm. Una vez instalado, se puede utilizar para crear un clúster.

Ver la guía de instalación

1.1 - Instalar y Configurar kubectl en Linux

Antes de empezar

Se debe utilizar la versión de kubectl con una minor versión de diferencia con tu cluster. Por ejemplo, un cliente con versión v1.30 se puede comunicar con las siguientes versiones de plano de control v1.29, v1.30 y v1.31. Utilizar la última versión compatible de kubectl evita posibles errores.

Instalar kubectl en Linux

Existen los siguientes métodos para instalar kubectl en Linux:

Instalación del binario para Linux de kubectl con Curl

  1. Descargar la última versión con el siguiente comando:

    
       curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
       

    
       curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/arm64/kubectl"
       
  2. Validación del binario (paso opcional)

    Descargar el archivo checksum:

    
       curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl.sha256"
       

    
       curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/arm64/kubectl.sha256"
       

    Validar el binario de kubectl contra el archivo checksum:

    echo "$(cat kubectl.sha256)  kubectl" | sha256sum --check
    

    Si es válido, va a obtener la siguiente respuesta:

    kubectl: OK
    

    En caso de falla, sha256 terminará con un estado diferente a cero con una salida similar a:

    kubectl: FAILED
    sha256sum: WARNING: 1 computed checksum did NOT match
    
  3. Instalar kubectl

    sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl
    
  4. Test para asegurar que la versión instalada está actualizada:

    kubectl version --client
    

    O puedes utilizar lo siguiente para una vista detallada de la versión:

    kubectl version --client --output=yaml
    

Instalación mediante el administrador de paquetes nativo

  1. Actualiza el índice del paquete apt, luego instala los paquetes necesarios para Kubernetes:

    sudo apt-get update
    # apt-transport-https may be a dummy package; if so, you can skip that package
    sudo apt-get install -y apt-transport-https ca-certificates curl gnupg
    
  2. Descarga la llave pública firmada para los repositorios de Kubernetes. La misma llave firmada es usada para todos los repositorios por lo que se puede obviar la versión en la URL:

    curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.30/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg
    
  3. Agregar el repositorio apropiado de Kubernetes. Si quieres una versión de Kubernetes diferente a v1.30, reemplace v1.30 con la versión deseada en el siguiente comando:

    # Esto sobrescribe cualquier configuración existente en el archivo /etc/apt/sources.list.d/kubernetes.list
    echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.30/deb/ /' | sudo tee /etc/apt/sources.list.d/kubernetes.list
    
  1. Actualiza el índice de apt, luego instala kubectl:

    sudo apt-get update
    sudo apt-get install -y kubectl
    

  1. Agregar Kubernetes al repositorio yum. Si deseas usar una versión de Kubernetes diferente a v1.30, reemplaza v1.30 con la versión deseada en el siguiente comando:

    # Lo siguiente reemplaza cualquier configuración existente en /etc/yum.repos.d/kubernetes.repo
    cat <<EOF | sudo tee /etc/yum.repos.d/kubernetes.repo
    [kubernetes]
    name=Kubernetes
    baseurl=https://pkgs.k8s.io/core:/stable:/v1.30/rpm/
    enabled=1
    gpgcheck=1
    gpgkey=https://pkgs.k8s.io/core:/stable:/v1.30/rpm/repodata/repomd.xml.key
    EOF
    
  1. Instalar kubectl utilizando yum:

    sudo yum install -y kubectl
    

  1. Agregar Kubernetes al repositorio zypper. Si deseas usar una versión de Kubernetes diferente a v1.30, reemplaza v1.30 con la versión deseada en el siguiente comando:

    # Lo siguiente reemplaza cualquier configuración existente en /etc/zypp/repos.d/kubernetes.repo
    cat <<EOF | sudo tee /etc/zypp/repos.d/kubernetes.repo
    [kubernetes]
    name=Kubernetes
    baseurl=https://pkgs.k8s.io/core:/stable:/v1.30/rpm/
    enabled=1
    gpgcheck=1
    gpgkey=https://pkgs.k8s.io/core:/stable:/v1.30/rpm/repodata/repomd.xml.key
    EOF
    
  1. Instalar kubectl usando zypper:

    sudo zypper install -y kubectl
    

Instalación usando otro administrador de paquetes

Si utilizas Ubuntu o alguna distribución que soporte el administrador de páquetes snap, kubectl está disponible como una aplicación de snap.

snap install kubectl --classic
kubectl version --client

Si utilizas Homebrew en Linux, kubectl está disponible para su instalación.

brew install kubectl
kubectl version --client

Verificar la configuración de kubectl

Para que kubectl encuentre y acceda a un clúster de Kubernetes, necesita un archivo kubeconfig, que se crea automáticamente cuando creas un clúster usando kube-up.sh o implementar con éxito un clúster de Minikube. De forma predeterminada, la configuración de kubectl se encuentra en ~/.kube/config.

Verifique que kubectl esté configurado correctamente obteniendo el estado del clúster:

kubectl cluster-info

Si ve una respuesta de URL, kubectl está configurado correctamente para acceder a su clúster.

Si ve un mensaje similar al siguiente, kubectl no está configurado correctamente o no puede conectarse a 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 tiene la intención de ejecutar un clúster de Kubernetes en su computadora portátil (localmente), primero necesitará instalar una herramienta como Minikube y luego volver a ejecutar los comandos indicados anteriormente.

Si kubectl cluster-info devuelve la respuesta de la URL pero no puede acceder a su clúster, para verificar si está configurado correctamente, use:

kubectl cluster-info dump

Configuraciones opcionales y plugins de kubectl

Habilitar el autocompletado en la shell

Kubectl tiene soporte para autocompletar en Bash, Zsh, Fish y Powershell, lo que puede agilizar el tipeo.

A continuación están los procedimientos para configurarlo en Bash, Fish y Zsh.

Introducción

El script de completado de kubectl para Bash se puede generar con el comando kubectl completion bash. Obtener el script de completado en su shell habilita el autocompletado de kubectl.

Sin embargo, el script de completado depende de bash-completion, lo que significa que primero debe instalar este software (puedes probar si tienes bash-completion ya instalado ejecutando type _init_completion).

Instalar bash-complete

El completado de bash es proporcionado por muchos administradores de paquetes (ver aquí). Puedes instalarlo con apt-get install bash-completion o yum install bash-completion, etc.

Los comandos anteriores crean /usr/share/bash-completion/bash_completion, que es el script principal de bash-complete. Dependiendo de su administrador de paquetes, debe obtener manualmente este archivo de perfil en su ~/.bashrc.

Para averiguarlo, recargue su shell y ejecute type _init_completion. Si el comando tiene éxito, ya está configurado; de lo contrario, agregue lo siguiente a su archivo ~/.bashrc:

source /usr/share/bash-completion/bash_completion

Vuelva a cargar su shell y verifique que la finalización de bash esté correctamente instalada escribiendo type _init_completion.

Habilitar el autocompletado de kubectl

Ahora debe asegurarse de que el script de completado de kubectl se obtenga en todas sus sesiones de shell. Hay dos formas de hacer esto:

  • Obtenga el script de completado en su perfil ~/.bashrc:

    echo 'source <(kubectl completion bash)' >>~/.bashrc
    
  • Agregue el script de completado al directorio de /etc/bash_completion.d:

    kubectl completion bash >/etc/bash_completion.d/kubectl
    

Si tiene un alias para kubectl, puede extender el completado del shell para trabajar con ese alias:

echo 'alias k=kubectl' >>~/.bashrc
echo 'complete -o default -F __start_kubectl k' >>~/.bashrc

Ambos enfoques son equivalentes. Después de recargar su shell, el autocompletado de kubectl debería estar funcionando.

El script de autocompletado de Fish para kubectl puede ser generado con el comando kubectl completion fish. Ejecutando este comando en tu shell habilitará el autocompletado de kubectl para Fish.

Para qué funcione en sus futuras sesiones shell, debes agregar la siguiente línea al archivo ~/.config/fish/config.fish:

kubectl completion fish | source

Después de recargar tu shell, el autocompletado para kubectl estará funcionando automáticamente.

El script de completado de kubectl para Zsh se puede generar con el comando kubectl completion zsh. Obtener el script de completado en su shell habilita el autocompletado de kubectl.

Para hacerlo en todas sus sesiones de shell, agregue lo siguiente a su perfil ~/.zshrc:

source <(kubectl completion zsh)

Si tiene un alias para kubectl, puede extender el completado del shell para trabajar con ese alias:

echo 'alias k=kubectl' >>~/.zshrc
echo 'compdef __start_kubectl k' >>~/.zshrc

Después de recargar su shell, el autocompletado de kubectl debería estar funcionando.

Si recibe un error como complete:13: command not found: compdef, luego agregue lo siguiente al comienzo de su perfil ~/.zshrc:

autoload -Uz compinit
compinit

Instalar el plugin kubectl convert

Un plugin para la herramienta de línea de comandos de Kubernetes kubectl, que le permite convertir manifiestos entre diferentes versiones de la API. Esto puede ser particularmente útil para migrar manifiestos a una versión no obsoleta de la API con la versión más reciente de Kubernetes. Para obtener más información, visite migrar a APIs no obsoletas

  1. Descarga la última versión con el siguiente comando:

    
       curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl-convert"
       

    
       curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/arm64/kubectl-convert"
       
  2. Valida el binario (opcional)

    Descarga el checksum de kubectl-convert:

    
       curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl-convert.sha256"
       

    
       curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/arm64/kubectl-convert.sha256"
       

    Ahora se puede validar el binario utilizando el checksum:

    echo "$(cat kubectl-convert.sha256) kubectl-convert" | sha256sum --check
    

    Si es válido, la salida será:

    kubectl-convert: OK
    

    En caso de falla, sha256 terminará con un estado diferente a cero con una salida similar a esta:

    kubectl-convert: FAILED
    sha256sum: WARNING: 1 computed checksum did NOT match
    
  3. Instalar kubectl-convert

    sudo install -o root -g root -m 0755 kubectl-convert /usr/local/bin/kubectl-convert
    
  4. Verificar si el plugin fue instalado correctamente

    kubectl convert --help
    

    Si no visualizas ningún error quiere decir que el plugin fue instalado correctamente.

  5. Después de instalar el plugin elimina los archivos de instalación:

    rm kubectl-convert kubectl-convert.sha256
    

Siguientes pasos

1.2 - Herramientas incluidas

Fragmentos que se incluirán en las páginas principales de kubectl-installs-*.

1.2.1 - Instalar y configurar kubectl en Linux

Antes de empezar

Debes usar una versión de kubectl que esté dentro de una diferencia de versión menor de tu clúster. Por ejemplo, un cliente v1.30 puede comunicarse con v1.29, v1.30, y v1.31 del plano de control. El uso de la última versión de kubectl ayuda a evitar problemas inesperados.

Instalar kubectl en Linux

Existen los siguientes métodos para instalar kubectl en Linux:

Instale el binario kubectl con curl en Linux

  1. Descargue la última versión con el comando:

    curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
    
  2. Validar el binario (opcional)

    Descargue el archivo de comprobación de kubectl:

    curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl.sha256"
    

    Valide el binario kubectl con el archivo de comprobación:

    echo "$(cat kubectl.sha256)  kubectl" | sha256sum --check
    

    Si es válido, la salida es:

    kubectl: OK
    

    Si la comprobación falla, sha256 arroja un valor distinto de cero e imprime una salida similar a:

    kubectl: FAILED
    sha256sum: WARNING: 1 computed checksum did NOT match
    
  3. Instalar kubectl

    sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl
    
  4. Para asegurarse de que la versión que instaló este actualizada ejecute:

    kubectl version --client
    

Instalar usando la administración nativa de paquetes

  1. Actualice el índice de paquetes de apt e instale los paquetes necesarios para usar Kubernetes con el repositorio apt:

    sudo apt-get update
    sudo apt-get install -y apt-transport-https ca-certificates curl
    
  2. Descargue la clave de firma pública de Google Cloud:

    sudo curl -fsSLo /usr/share/keyrings/kubernetes-archive-keyring.gpg https://packages.cloud.google.com/apt/doc/apt-key.gpg
    
  3. Agregue el repositorio de Kubernetes a apt:

    echo "deb [signed-by=/usr/share/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list
    
  4. Actualice el índice de paquetes de apt con el nuevo repositorio e instale kubectl:

    sudo apt-get update
    sudo apt-get install -y kubectl
    


cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-\$basearch
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF
yum install -y kubectl

Instalar usando otra administración de paquetes

Si está en Ubuntu u otra distribución de Linux que admita el administrador de paquetes snap, kubectl estará disponible como solicitud de snap.

snap install kubectl --classic
kubectl version --client

Si está en Linux y usa Homebrew como administrador de paquetes, kubectl está disponible para instalación.

brew install kubectl
kubectl version --client

Verificar la configuración de kubectl

Para que kubectl encuentre y acceda a un clúster de Kubernetes, necesita un archivo kubeconfig, que se crea automáticamente cuando creas un clúster usando kube-up.sh o implementar con éxito un clúster de Minikube. De forma predeterminada, la configuración de kubectl se encuentra en ~/.kube/config.

Verifique que kubectl esté configurado correctamente obteniendo el estado del clúster:

kubectl cluster-info

Si ve una respuesta de URL, kubectl está configurado correctamente para acceder a su clúster.

Si ve un mensaje similar al siguiente, kubectl no está configurado correctamente o no puede conectarse a 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 tiene la intención de ejecutar un clúster de Kubernetes en su computadora portátil (localmente), primero necesitará instalar una herramienta como Minikube y luego volver a ejecutar los comandos indicados anteriormente.

Si kubectl cluster-info devuelve la respuesta de la URL pero no puede acceder a su clúster, para verificar si está configurado correctamente, use:

kubectl cluster-info dump

Plugins y configuraciones opcionales de kubectl

Habilitar el autocompletado de shell

kubectl proporciona soporte de autocompletado para Bash y Zsh, lo que puede ahorrarle mucho tiempo al interactuar con la herramienta.

A continuación, se muestran los procedimientos para configurar el autocompletado para Bash y Zsh.

Introducción

El script de completado de kubectl para Bash se puede generar con el comando kubectl completion bash. Obtener el script de completado en su shell habilita el autocompletado de kubectl.

Sin embargo, el script de completado depende de bash-completion, lo que significa que primero debe instalar este software (puedes probar si tienes bash-completion ya instalado ejecutando type _init_completion).

Instalar bash-complete

El completado de bash es proporcionado por muchos administradores de paquetes (ver aquí). Puedes instalarlo con apt-get install bash-completion o yum install bash-completion, etc.

Los comandos anteriores crean /usr/share/bash-completion/bash_completion, que es el script principal de bash-complete. Dependiendo de su administrador de paquetes, debe obtener manualmente este archivo de perfil en su ~/.bashrc.

Para averiguarlo, recargue su shell y ejecute type _init_completion. Si el comando tiene éxito, ya está configurado; de lo contrario, agregue lo siguiente a su archivo ~/.bashrc:

source /usr/share/bash-completion/bash_completion

Vuelva a cargar su shell y verifique que la finalización de bash esté correctamente instalada escribiendo type _init_completion.

Habilitar el autocompletado de kubectl

Ahora debe asegurarse de que el script de completado de kubectl se obtenga en todas sus sesiones de shell. Hay dos formas de hacer esto:

  • Obtenga el script de completado en su perfil ~/.bashrc:

    echo 'source <(kubectl completion bash)' >>~/.bashrc
    
  • Agregue el script de completado al directorio de /etc/bash_completion.d:

    kubectl completion bash >/etc/bash_completion.d/kubectl
    

Si tiene un alias para kubectl, puede extender el completado del shell para trabajar con ese alias:

echo 'alias k=kubectl' >>~/.bashrc
echo 'complete -o default -F __start_kubectl k' >>~/.bashrc

Ambos enfoques son equivalentes. Después de recargar su shell, el autocompletado de kubectl debería estar funcionando.

El script de completado de kubectl para Zsh se puede generar con el comando kubectl completion zsh. Obtener el script de completado en su shell habilita el autocompletado de kubectl.

Para hacerlo en todas sus sesiones de shell, agregue lo siguiente a su perfil ~/.zshrc:

source <(kubectl completion zsh)

Si tiene un alias para kubectl, puede extender el completado del shell para trabajar con ese alias:

echo 'alias k=kubectl' >>~/.zshrc
echo 'compdef __start_kubectl k' >>~/.zshrc

Después de recargar su shell, el autocompletado de kubectl debería estar funcionando.

Si recibe un error como complete:13: command not found: compdef, luego agregue lo siguiente al comienzo de su perfil ~/.zshrc:

autoload -Uz compinit
compinit

Instalar en pc kubectl convert plugin

Un plugin para la herramienta de línea de comandos de Kubernetes kubectl, que le permite convertir manifiestos entre diferentes versiones de la API. Esto puede ser particularmente útil para migrar manifiestos a una versión no obsoleta de la API con la versión más reciente de Kubernetes. Para obtener más información, visite migrar a APIs no obsoletas

  1. Descargue la última versión con el comando:

    curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl-convert"
    
  2. Valide el binario (opcional)

    Descargue el archivo de comprobación kubectl-convert:

    curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl-convert.sha256"
    

    Valide el binario kubectl-convert con el archivo de comprobación:

    echo "$(cat kubectl-convert.sha256) kubectl-convert" | sha256sum --check
    

    Si es válido, la salida es:

    kubectl-convert: OK
    

    Si la comprobación falla, sha256 arroja un valor distinto de cero e imprime una salida similar a:

    kubectl-convert: FAILED
    sha256sum: WARNING: 1 computed checksum did NOT match
    
  3. Instale kubectl-convert en pc

    sudo install -o root -g root -m 0755 kubectl-convert /usr/local/bin/kubectl-convert
    
  4. Verifique que el plugin se haya instalado correctamente

    kubectl convert --help
    

    Si no ve un error, significa que el plugin se instaló correctamente.

Siguientes pasos

1.2.2 - Instalar y configurar kubectl en macOS

Antes de empezar

Debes usar una versión de kubectl que esté dentro de una diferencia de versión menor de tu clúster. Por ejemplo, un cliente v1.30 puede comunicarse con v1.29, v1.30, y v1.31 del plano de control. El uso de la última versión de kubectl ayuda a evitar problemas imprevistos.

Instalar kubectl en macOS

Existen los siguientes métodos para instalar kubectl en macOS:

Instalar el binario de kubectl con curl en macOS

  1. Descargue la última versión:

    
       curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl"
       

    
       curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/arm64/kubectl"
       
  2. Validar el binario (opcional)

    Descargue el archivo de comprobación de kubectl:

    
       curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl.sha256"
       

    
       curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/arm64/kubectl.sha256"
       

    Valide el binario kubectl con el archivo de comprobación:

    echo "$(<kubectl.sha256)  kubectl" | shasum -a 256 --check
    

    Si es válido, la salida es:

    kubectl: OK
    

    Si la verificación falla, shasum arroja un valor distinto de cero e imprime una salida similar a:

    kubectl: FAILED
    shasum: WARNING: 1 computed checksum did NOT match
    
  3. Hacer ejecutable el binario de kubectl.

    chmod +x ./kubectl
    
  4. Mueva el binario kubectl a una ubicación de archivo en su sistema PATH.

    sudo mv ./kubectl /usr/local/bin/kubectl
    sudo chown root: /usr/local/bin/kubectl
    
  5. Para asegurarse de que la versión que instaló se encuentra actualizada, ejecute:

    kubectl version --client
    

Instalar con Homebrew en macOS

Si está en macOS y usa Homebrew como administrador de paquetes, puede instalar kubectl con Homebrew.

  1. Ejecute el comando de instalación:

    brew install kubectl 
    

    or

    brew install kubernetes-cli
    
  2. Para asegurarse de que la versión que instaló se encuentra actualizada, ejecute:

    kubectl version --client
    

Instalar con Macports en macOS

Si está en macOS y usa Macports como administrador de paquetes, puede instalar kubectl con Macports.

  1. Ejecute el comando de instalación:

    sudo port selfupdate
    sudo port install kubectl
    
  2. Para asegurarse de que la versión que instaló se encuentra actualizada, ejecute:

    kubectl version --client
    

Verificar la configuración de kubectl

Para que kubectl encuentre y acceda a un clúster de Kubernetes, necesita un archivo kubeconfig, que se crea automáticamente cuando creas un clúster usando kube-up.sh o implementar con éxito un clúster de Minikube. De forma predeterminada, la configuración de kubectl se encuentra en ~/.kube/config.

Verifique que kubectl esté configurado correctamente obteniendo el estado del clúster:

kubectl cluster-info

Si ve una respuesta de URL, kubectl está configurado correctamente para acceder a su clúster.

Si ve un mensaje similar al siguiente, kubectl no está configurado correctamente o no puede conectarse a 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 tiene la intención de ejecutar un clúster de Kubernetes en su computadora portátil (localmente), primero necesitará instalar una herramienta como Minikube y luego volver a ejecutar los comandos indicados anteriormente.

Si kubectl cluster-info devuelve la respuesta de la URL pero no puede acceder a su clúster, para verificar si está configurado correctamente, use:

kubectl cluster-info dump

Plugins y configuraciones opcionales de kubectl

Habilitar el autocompletado de shell

kubectl proporciona soporte de autocompletado para Bash y Zsh, lo que puede ahorrarle mucho tiempo al escribir.

A continuación, se muestran los procedimientos para configurar el autocompletado para Bash y Zsh.

Introducción

El script de completado de kubectl para Bash se puede generar con kubectl completion bash. Obtener este script en su shell permite el completado de kubectl.

Sin embargo, el script de finalización de kubectl depende de bash-completion que, por lo tanto, debe instalar previamente.

Actualizar Bash

Las siguientes instrucciones asumen que usa Bash 4.1+. Puede verificar la versión de su Bash ejecutando:

echo $BASH_VERSION

Si es demasiado antiguo, puede instalarlo o actualizarlo usando Homebrew:

brew install bash

Vuelva a cargar su shell y verifique que se esté utilizando la versión deseada:

echo $BASH_VERSION $SHELL

Homebrew generalmente lo instala en /usr/local/bin/bash.

Instalar bash-complete

Puede probar si ya tiene instalado bash-complete v2 con type _init_completion. Si no es así, puede instalarlo con Homebrew:

brew install bash-completion@2

Como se indica en el resultado de este comando, agregue lo siguiente a su archivo ~/.bash_profile:

brew_etc="$(brew --prefix)/etc" && [[ -r "${brew_etc}/profile.d/bash_completion.sh" ]] && . "${brew_etc}/profile.d/bash_completion.sh"

Vuelva a cargar su shell y verifique que bash-complete v2 esté instalado correctamente con type _init_completion.

Habilitar el autocompletado de kubectl

Ahora debe asegurarse de que el script de completado de kubectl se obtenga en todas sus sesiones de shell. Hay varias formas de lograrlo:

  • Obtenga el script de finalización en su perfil ~/.bash_profile:

    echo 'source <(kubectl completion bash)' >>~/.bash_profile
    
  • Agregue el script de completado al directorio /usr/local/etc/bash_completion.d:

    kubectl completion bash >/usr/local/etc/bash_completion.d/kubectl
    
  • Si tiene un alias para kubectl, puede extender el completado del shell para trabajar con ese alias:

    echo 'alias k=kubectl' >>~/.bash_profile
    echo 'complete -o default -F __start_kubectl k' >>~/.bash_profile
    
  • Si instaló kubectl con Homebrew (como se explica aquí), entonces el script de completado de kubectl ya debería estar en /usr/local/etc/bash_completion.d/kubectl. En ese caso, no necesita hacer nada.

En cualquier caso, después de recargar su shell, el completado de kubectl debería estar funcionando.

El script de completado de kubectl para Zsh se puede generar con el comando kubectl completion zsh. Obtener el script de completado en su shell habilita el autocompletado de kubectl.

Para hacerlo en todas sus sesiones de shell, agregue lo siguiente a su perfil ~/.zshrc:

source <(kubectl completion zsh)

Si tiene un alias para kubectl, puede extender el completado del shell para trabajar con ese alias:

echo 'alias k=kubectl' >>~/.zshrc
echo 'compdef __start_kubectl k' >>~/.zshrc

Después de recargar su shell, el autocompletado de kubectl debería estar funcionando.

Si recibe un error como complete:13: command not found: compdef, luego agregue lo siguiente al comienzo de su perfil ~/.zshrc:

autoload -Uz compinit
compinit

Instalar el plugin kubectl-convert

Un plugin para la herramienta de línea de comandos de Kubernetes kubectl, que le permite convertir manifiestos entre diferentes versiones de la API. Esto puede ser particularmente útil para migrar manifiestos a una versión no obsoleta de la API con la versión más reciente de Kubernetes. Para obtener más información, visite migrar a APIs no obsoletas

  1. Descargue la última versión con el comando:

    
       curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl-convert"
       

    
       curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/arm64/kubectl-convert"
       
  2. Validar el binario (opcional)

    Descargue el archivo de comprobación de kubectl:

    
       curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl-convert.sha256"
       

    
       curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/arm64/kubectl-convert.sha256"
       

    Valide el binario kubectl-convert con el archivo de comprobación:

    echo "$(<kubectl-convert.sha256)  kubectl-convert" | shasum -a 256 --check
    

    Si es válido, la salida es:

    kubectl-convert: OK
    

    Si la verificación falla, shasum arroja un valor distinto de cero e imprime una salida similar a:

    kubectl-convert: FAILED
    shasum: WARNING: 1 computed checksum did NOT match
    
  3. Hacer ejecutable el binario de kubectl-convert

    chmod +x ./kubectl-convert
    
  4. Mueva el binario kubectl-convert a una ubicación de archivo en su sistema PATH.

    sudo mv ./kubectl-convert /usr/local/bin/kubectl-convert
    sudo chown root: /usr/local/bin/kubectl-convert
    
  5. Verifique que el complemento se haya instalado correctamente

    kubectl convert --help
    

    Si no ve algun error, significa que el complemento se instaló correctamente.

Siguientes pasos

1.2.3 - Instalar y configurar kubectl en Windows

Antes de empezar

Debes usar una versión de kubectl que este dentro de una diferencia de versión menor de tu clúster. Por ejemplo, un cliente v1.30 puede comunicarse con versiones v1.29, v1.30, y v1.31 del plano de control.

El uso de la última versión de kubectl ayuda a evitar problemas imprevistos.

Instalar kubectl en Windows

Existen los siguientes métodos para instalar kubectl en Windows:

Instalar el binario de kubectl con curl en Windows

  1. Descarga la última versión 1.30.0.

    O si tiene curl instalado, use este comando:

    curl -LO https://dl.k8s.io/release/v1.30.0/bin/windows/amd64/kubectl.exe
    
  2. Validar el binario (opcional)

    Descargue el archivo de comprobación de kubectl:

    curl -LO https://dl.k8s.io/v1.30.0/bin/windows/amd64/kubectl.exe.sha256
    

    Valide el binario kubectl con el archivo de comprobación:

    • Usando la consola del sistema para comparar manualmente la salida de CertUtil con el archivo de comprobación descargado:

      CertUtil -hashfile kubectl.exe SHA256
      type kubectl.exe.sha256
      
    • Usando PowerShell puede automatizar la verificación usando el operador -eq para obtener un resultado de True o False:

       $(Get-FileHash -Algorithm SHA256 .\kubectl.exe).Hash -eq $(Get-Content .\kubectl.exe.sha256))
      
  3. Agregue el binario a su PATH.

  4. Para asegurar que la versión dekubectl es la misma que descargada, ejecute:

    kubectl version --client
    

Instalar en Windows usando Chocolatey o Scoop

  1. Para instalar kubectl en Windows, puede usar Chocolatey como administrador de paquetes o el instalador Scoop desde línea de comandos.

    choco install kubernetes-cli
    

    scoop install kubectl
    
  2. Para asegurarse de que la versión que instaló esté actualizada, ejecute:

    kubectl version --client
    
  3. Navegue a su directorio de inicio:

    # Si estas usando cmd.exe, correr: cd %USERPROFILE%
    cd ~
    
  4. Cree el directorio .kube:

    mkdir .kube
    
  5. Cambie al directorio .kube que acaba de crear:

    cd .kube
    
  6. Configure kubectl para usar un clúster de Kubernetes remoto:

    New-Item config -type file
    

Verificar la configuración de kubectl

Para que kubectl encuentre y acceda a un clúster de Kubernetes, necesita un archivo kubeconfig, que se crea automáticamente cuando creas un clúster usando kube-up.sh o implementar con éxito un clúster de Minikube. De forma predeterminada, la configuración de kubectl se encuentra en ~/.kube/config.

Verifique que kubectl esté configurado correctamente obteniendo el estado del clúster:

kubectl cluster-info

Si ve una respuesta de URL, kubectl está configurado correctamente para acceder a su clúster.

Si ve un mensaje similar al siguiente, kubectl no está configurado correctamente o no puede conectarse a 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 tiene la intención de ejecutar un clúster de Kubernetes en su computadora portátil (localmente), primero necesitará instalar una herramienta como Minikube y luego volver a ejecutar los comandos indicados anteriormente.

Si kubectl cluster-info devuelve la respuesta de la URL pero no puede acceder a su clúster, para verificar si está configurado correctamente, use:

kubectl cluster-info dump

Plugins y configuraciones opcionales de kubectl

Habilitar el autocompletado de shell

kubectl proporciona soporte de autocompletado para Bash y Zsh, lo que puede ahorrarle mucho tiempo al escribir.

A continuación se muestran los procedimientos para configurar el autocompletado para Zsh, si lo está ejecutando en Windows.

El script de completado de kubectl para Zsh se puede generar con el comando kubectl completion zsh. Obtener el script de completado en su shell habilita el autocompletado de kubectl.

Para hacerlo en todas sus sesiones de shell, agregue lo siguiente a su perfil ~/.zshrc:

source <(kubectl completion zsh)

Si tiene un alias para kubectl, puede extender el completado del shell para trabajar con ese alias:

echo 'alias k=kubectl' >>~/.zshrc
echo 'compdef __start_kubectl k' >>~/.zshrc

Después de recargar su shell, el autocompletado de kubectl debería estar funcionando.

Si recibe un error como complete:13: command not found: compdef, luego agregue lo siguiente al comienzo de su perfil ~/.zshrc:

autoload -Uz compinit
compinit

Instalar el plugin kubectl-convert

Un plugin para la herramienta de línea de comandos de Kubernetes kubectl, que le permite convertir manifiestos entre diferentes versiones de la API. Esto puede ser particularmente útil para migrar manifiestos a una versión no obsoleta de la API con la versión más reciente de Kubernetes. Para obtener más información, visite migrar a APIs no obsoletas

  1. Descargue la última versión con el comando:

    curl -LO https://dl.k8s.io/release/v1.30.0/bin/windows/amd64/kubectl-convert.exe
    
  2. Validar el binario (opcional)

    Descargue el archivo de comprobación kubectl-convert:

    curl -LO https://dl.k8s.io/v1.30.0/bin/windows/amd64/kubectl-convert.exe.sha256
    

    Valide el binario kubectl-convert con el archivo de comprobación:

    • Usando la consola del sistema puede comparar manualmente la salida de CertUtil con el archivo de comprobación descargado:

      CertUtil -hashfile kubectl-convert.exe SHA256
      type kubectl-convert.exe.sha256
      
    • Usando PowerShell puede automatizar la verificación usando el operador -eq para obtener un resultado de True o False:

      $($(CertUtil -hashfile .\kubectl-convert.exe SHA256)[1] -replace " ", "") -eq $(type .\kubectl-convert.exe.sha256)
      
  3. Agregue el binario a su PATH.

  4. Verifique que el plugin se haya instalado correctamente

    kubectl convert --help
    

    Si no ve un error, significa que el plugin se instaló correctamente.

Siguientes pasos

1.2.4 - ¿Que sigue?

¿Qué sigue después de instalar kubectl.

1.2.5 - Autocompletar bash en Linux

Alguna configuración opcional para la finalización automática de bash en Linux.

Introducción

El script de completado de kubectl para Bash se puede generar con el comando kubectl completion bash. Obtener el script de completado en su shell habilita el autocompletado de kubectl.

Sin embargo, el script de completado depende de bash-completion, lo que significa que primero debe instalar este software (puedes probar si tienes bash-completion ya instalado ejecutando type _init_completion).

Instalar bash-complete

El completado de bash es proporcionado por muchos administradores de paquetes (ver aquí). Puedes instalarlo con apt-get install bash-completion o yum install bash-completion, etc.

Los comandos anteriores crean /usr/share/bash-completion/bash_completion, que es el script principal de bash-complete. Dependiendo de su administrador de paquetes, debe obtener manualmente este archivo de perfil en su ~/.bashrc.

Para averiguarlo, recargue su shell y ejecute type _init_completion. Si el comando tiene éxito, ya está configurado; de lo contrario, agregue lo siguiente a su archivo ~/.bashrc:

source /usr/share/bash-completion/bash_completion

Vuelva a cargar su shell y verifique que la finalización de bash esté correctamente instalada escribiendo type _init_completion.

Habilitar el autocompletado de kubectl

Ahora debe asegurarse de que el script de completado de kubectl se obtenga en todas sus sesiones de shell. Hay dos formas de hacer esto:

  • Obtenga el script de completado en su perfil ~/.bashrc:

    echo 'source <(kubectl completion bash)' >>~/.bashrc
    
  • Agregue el script de completado al directorio de /etc/bash_completion.d:

    kubectl completion bash >/etc/bash_completion.d/kubectl
    

Si tiene un alias para kubectl, puede extender el completado del shell para trabajar con ese alias:

echo 'alias k=kubectl' >>~/.bashrc
echo 'complete -o default -F __start_kubectl k' >>~/.bashrc

Ambos enfoques son equivalentes. Después de recargar su shell, el autocompletado de kubectl debería estar funcionando.

1.2.6 - Autocompletar bash en macOS

Alguna configuración opcional para la finalización automática de bash en macOS.

Introducción

El script de completado de kubectl para Bash se puede generar con kubectl completion bash. Obtener este script en su shell permite el completado de kubectl.

Sin embargo, el script de finalización de kubectl depende de bash-completion que, por lo tanto, debe instalar previamente.

Actualizar Bash

Las siguientes instrucciones asumen que usa Bash 4.1+. Puede verificar la versión de su Bash ejecutando:

echo $BASH_VERSION

Si es demasiado antiguo, puede instalarlo o actualizarlo usando Homebrew:

brew install bash

Vuelva a cargar su shell y verifique que se esté utilizando la versión deseada:

echo $BASH_VERSION $SHELL

Homebrew generalmente lo instala en /usr/local/bin/bash.

Instalar bash-complete

Puede probar si ya tiene instalado bash-complete v2 con type _init_completion. Si no es así, puede instalarlo con Homebrew:

brew install bash-completion@2

Como se indica en el resultado de este comando, agregue lo siguiente a su archivo ~/.bash_profile:

brew_etc="$(brew --prefix)/etc" && [[ -r "${brew_etc}/profile.d/bash_completion.sh" ]] && . "${brew_etc}/profile.d/bash_completion.sh"

Vuelva a cargar su shell y verifique que bash-complete v2 esté instalado correctamente con type _init_completion.

Habilitar el autocompletado de kubectl

Ahora debe asegurarse de que el script de completado de kubectl se obtenga en todas sus sesiones de shell. Hay varias formas de lograrlo:

  • Obtenga el script de finalización en su perfil ~/.bash_profile:

    echo 'source <(kubectl completion bash)' >>~/.bash_profile
    
  • Agregue el script de completado al directorio /usr/local/etc/bash_completion.d:

    kubectl completion bash >/usr/local/etc/bash_completion.d/kubectl
    
  • Si tiene un alias para kubectl, puede extender el completado del shell para trabajar con ese alias:

    echo 'alias k=kubectl' >>~/.bash_profile
    echo 'complete -o default -F __start_kubectl k' >>~/.bash_profile
    
  • Si instaló kubectl con Homebrew (como se explica aquí), entonces el script de completado de kubectl ya debería estar en /usr/local/etc/bash_completion.d/kubectl. En ese caso, no necesita hacer nada.

En cualquier caso, después de recargar su shell, el completado de kubectl debería estar funcionando.

1.2.7 - Autocompletar zsh

Alguna configuración opcional para la finalización automática de zsh.

El script de completado de kubectl para Zsh se puede generar con el comando kubectl completion zsh. Obtener el script de completado en su shell habilita el autocompletado de kubectl.

Para hacerlo en todas sus sesiones de shell, agregue lo siguiente a su perfil ~/.zshrc:

source <(kubectl completion zsh)

Si tiene un alias para kubectl, puede extender el completado del shell para trabajar con ese alias:

echo 'alias k=kubectl' >>~/.zshrc
echo 'compdef __start_kubectl k' >>~/.zshrc

Después de recargar su shell, el autocompletado de kubectl debería estar funcionando.

Si recibe un error como complete:13: command not found: compdef, luego agregue lo siguiente al comienzo de su perfil ~/.zshrc:

autoload -Uz compinit
compinit

1.2.8 - Descripción general de kubectl-convert

Un plugin de kubectl que le permite convertir manifiestos de una versión

Un plugin para la herramienta de línea de comandos de Kubernetes kubectl, que le permite convertir manifiestos entre diferentes versiones de la API. Esto puede ser particularmente útil para migrar manifiestos a una versión no obsoleta de la API con la versión más reciente de Kubernetes. Para obtener más información, visite migrar a APIs no obsoletas

1.2.9 - verificar la instalación de kubectl

Cómo verificar kubectl.

Para que kubectl encuentre y acceda a un clúster de Kubernetes, necesita un archivo kubeconfig, que se crea automáticamente cuando creas un clúster usando kube-up.sh o implementar con éxito un clúster de Minikube. De forma predeterminada, la configuración de kubectl se encuentra en ~/.kube/config.

Verifique que kubectl esté configurado correctamente obteniendo el estado del clúster:

kubectl cluster-info

Si ve una respuesta de URL, kubectl está configurado correctamente para acceder a su clúster.

Si ve un mensaje similar al siguiente, kubectl no está configurado correctamente o no puede conectarse a 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 tiene la intención de ejecutar un clúster de Kubernetes en su computadora portátil (localmente), primero necesitará instalar una herramienta como Minikube y luego volver a ejecutar los comandos indicados anteriormente.

Si kubectl cluster-info devuelve la respuesta de la URL pero no puede acceder a su clúster, para verificar si está configurado correctamente, use:

kubectl cluster-info dump

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:

apiVersion: v1
kind: Pod
metadata:
  name: redis
spec:
  containers:
  - name: redis
    image: redis
    volumeMounts:
    - name: redis-storage
      mountPath: /data/redis
  volumes:
  - name: redis-storage
    emptyDir: {}
  1. Crea el Pod:

    kubectl apply -f https://k8s.io/examples/pods/storage/redis.yaml
    
  2. 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
    
  3. En otro terminal, abre una sesión interactiva dentro del Contenedor que se está ejecutando:

    kubectl exec -it redis -- /bin/bash
    
  4. 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
    
  5. 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  33308  3828 ?        Ssl  00:46   0:00 redis-server *:6379
    root        12  0.0  0.0  20228  3020 ?        Ss   00:47   0:00 /bin/bash
    root        15  0.0  0.0  17500  2072 ?        R+   00:48   0:00 ps aux
    
  6. En el terminal, mata el proceso de Redis:

    root@redis:/data/redis# kill <pid>
    

    donde <pid> es el ID de proceso (PID) de Redis.

  7. 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).

  1. Abre un terminal en el Contenedor reiniciado:

    kubectl exec -it redis -- /bin/bash
    
  2. 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
    
  3. Elimina el Pod que has creado para este ejercicio:

    kubectl delete pod redis
    

Siguientes pasos

  • Revisa Volume.

  • Revisa Pod.

  • 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á.

Antes de empezar

Instale kubectl.

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.

Modos de administración

La herramienta kubectl soporta tres modos distintos para la administración de objetos:

  • Comandos imperativos
  • Configuración de objetos imperativa
  • Configuración de objetos declarativa

Acceda Administración de objetos de Kubernetes para una discusión de las ventajas y desventajas de cada modo distinto de administración.

Visión general

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.

El siguiente es un ejemplo de archivo de configuración para un objeto:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  minReadySeconds: 5
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

Ejecute kubectl diff para visualizar el objeto que será creado:

kubectl diff -f https://k8s.io/examples/application/simple_deployment.yaml

Cree el objeto usando kubectl apply:

kubectl apply -f https://k8s.io/examples/application/simple_deployment.yaml

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: Deployment
metadata:
  annotations:
    # ...
    # Esta es la representación JSON de simple_deployment.yaml
    # Fue escrita por kubectl apply cuando el objeto fue creado
    kubectl.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: 5
  selector:
    matchLabels:
      # ...
      app: nginx
  template:
    metadata:
      # ...
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx:1.14.2
        # ...
        name: nginx
        ports:
        - 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:

  1. Definir los campos que aparecerán en la configuración activa.
  2. Eliminar aquellos campos eliminados en el archivo de configuración, de la configuración activa.
kubectl diff -f <directorio>/
kubectl apply -f <directorio>/

Este es un ejemplo de archivo de configuración:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  minReadySeconds: 5
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

Cree el objeto usando kubectl apply:

kubectl apply -f https://k8s.io/examples/application/simple_deployment.yaml

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: Deployment
metadata:
  annotations:
    # ...
    # Esta es la representación JSON de simple_deployment.yaml
    # Fue escrita por kubectl apply cuando el objeto fue creado
    kubectl.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: 5
  selector:
    matchLabels:
      # ...
      app: nginx
  template:
    metadata:
      # ...
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx:1.14.2
        # ...
        name: nginx
        ports:
        - 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:

kubectl scale deployment/nginx-deployment --replicas=2

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/v1
kind: Deployment
metadata:
  annotations:
    # ...
    # note que la anotación no contiene replicas
    # debido a que el objeto no fue actualizado usando apply
    kubectl.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: 5
  selector:
    matchLabels:
      # ...
      app: nginx
  template:
    metadata:
      # ...
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx:1.14.2
        # ...
        name: nginx
        ports:
        - 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/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.16.1 # actualice el valor de image
        ports:
        - containerPort: 80

Aplique los cambios realizados al archivo de configuración:

kubectl diff -f https://k8s.io/examples/application/update_deployment.yaml
kubectl apply -f https://k8s.io/examples/application/update_deployment.yaml

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/v1
kind: Deployment
metadata:
  annotations:
    # ...
    # La anotación contiene la imagen acutalizada a nginx 1.11.9,
    # pero no contiene la actualización de las replicas a 2
    kubectl.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: nginx
  template:
    metadata:
      # ...
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx:1.16.1 # Definido `kubectl apply`
        # ...
        name: nginx
        ports:
        - containerPort: 80
        # ...
      # ...
    # ...
  # ...

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.

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.

kubectl apply -f <directorio/> --prune -l <etiquetas>

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

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:

  1. Calculo de campos por eliminar. Estos son los campos presentes en last-applied-configuration pero ausentes en el archivo de configuración.
  2. 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/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.16.1 # actualice el valor de image
        ports:
        - containerPort: 80

También, suponga que esta es la configuración activa para ese mismo objeto de tipo Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    # ...
    # tome nota de que la anotación no contiene un valor para replicas
    # dado que no fue actualizado usando el comando apply
    kubectl.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: 5
  selector:
    matchLabels:
      # ...
      app: nginx
  template:
    metadata:
      # ...
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx:1.14.2
        # ...
        name: nginx
        ports:
        - containerPort: 80
      # ...

Estos son los cálculos de unión que serían realizados por kubectl apply:

  1. 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.
  2. 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.
  3. Definir el valor de la anotación last-applied-configuration para que sea consistente con el archivo de configuración.
  4. 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/v1
kind: Deployment
metadata:
  annotations:
    # ...
    # La anotación contiene la imágen actualizada a nginx 1.11.9,
    # pero no contiene la actualización a 2 replicas
    kubectl.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: nginx
  replicas: 2 # Definido por `kubectl scale`.  Ignorado por `kubectl apply`.
  # minReadySeconds eliminado por `kubectl apply`
  # ...
  template:
    metadata:
      # ...
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx:1.16.1 # Definido por `kubectl apply`
        # ...
        name: nginx
        ports:
        - 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.

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:

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-configuration
    args: ["a", "b"]

# valores en archivo de configuración
    args: ["a", "c"]

# configuración activa
    args: ["a", "b", "d"]

# resultado posterior a la unión
    args: ["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-configuration
    containers:
    - name: nginx
      image: nginx:1.16
    - name: nginx-helper-a # llave: nginx-helper-a; será eliminado en resultado
      image: helper:1.3
    - name: nginx-helper-b # llave: nginx-helper-b; será conservado
      image: helper:1.3

# valor en archivo de configuración
    containers:
    - name: nginx
      image: nginx:1.16
    - name: nginx-helper-b
      image: helper:1.3
    - name: nginx-helper-c # llavel: nginx-helper-c; será agregado en el resultado
      image: helper:1.3

# configuración activa
    containers:
    - name: nginx
      image: nginx:1.16
    - name: nginx-helper-a
      image: helper:1.3
    - name: nginx-helper-b
      image: helper:1.3
      args: ["run"] # Campo será conservado
    - name: nginx-helper-d # llave: nginx-helper-d; será conservado
      image: helper:1.3

# resultado posterior a la unión
    containers:
    - name: nginx
      image: nginx:1.16
      # Elemento nginx-helper-a fue eliminado
    - name: nginx-helper-b
      image: helper:1.3
      args: ["run"] # Campo fue conservado
    - name: nginx-helper-c # Elemento fue agregado
      image: helper:1.3
    - name: nginx-helper-d # Elemento fue ignorado
      image: 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.

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:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  minReadySeconds: 5
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

Cree un nuevo objeto kubectl apply:

kubectl apply -f https://k8s.io/examples/application/simple_deployment.yaml

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/v1
kind: Deployment
# ...
spec:
  selector:
    matchLabels:
      app: nginx
  minReadySeconds: 5
  replicas: 1 # valor por defecto definido por apiserver
  strategy:
    rollingUpdate: # valor por defecto definido por apiserver - derivado de strategy.type
      maxSurge: 1
      maxUnavailable: 1
    type: RollingUpdate # valor por defecto definido por apiserver
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx:1.14.2
        imagePullPolicy: IfNotPresent # valor por defecto definido por apiserver
        name: nginx
        ports:
        - containerPort: 80
          protocol: TCP # valor por defecto definido por apiserver
        resources: {} # valor por defecto definido por apiserver
        terminationMessagePath: /dev/termination-log # valor por defecto definido por apiserver
      dnsPolicy: ClústerFirst # valor por defecto definido por apiserver
      restartPolicy: Always # valor por defecto definido por apiserver
      securityContext: {} # valor por defecto definido por apiserver
      terminationGracePeriodSeconds: 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-configuration
spec:
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

# archivo de configuración
spec:
  strategy:
    type: Recreate # valor actualizado
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

# configuración activa
spec:
  strategy:
    type: RollingUpdate # valor por defecto
    rollingUpdate: # valor por defecto derivado del campo type
      maxSurge : 1
      maxUnavailable: 1
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

# resultado posterior a la unión - ERROR!
spec:
  strategy:
    type: Recreate # valor actualizado: incompatible con RollingUpdate
    rollingUpdate: # valor por defecto: incompatible con "type: Recreate"
      maxSurge : 1
      maxUnavailable: 1
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

Explicación:

  1. El usuario crea un Deployment sin definir strategy.type.
  2. El servidor define strategy.type a su valor por defecto de RollingUpdate y agrega los valores por defecto a strategy.rollingUpdate.
  3. 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.
  4. 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.

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:

  1. Exporte el objeto activo a un archivo local de configuración:

    kubectl get <tipo>/<nombre> -o yaml > <tipo>_<nombre>.yaml
    
  2. Elimine de manera manual el campo status del archivo de configuración.

  3. Defina la anotación kubectl.kubernetes.io/last-applied-configuration en el objeto:

    kubectl replace --save-config -f <tipo>_<nombre>.yaml
    
  4. Modifique el proceso para usar kubectl apply para gestionar el objeto de manera exclusiva.

Migrando de gestión imperativa de la configuración de objetos a gestión declarativa

  1. Defina la anotación kubectl.kubernetes.io/last-applied-configuration en el objeto:

    kubectl replace --save-config -f <tipo>_<nombre>.yaml
    
  2. 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

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.

Ejemplo:

selector:
  matchLabels:
      controller-selector: "apps/v1/deployment/nginx"
template:
  metadata:
    labels:
      controller-selector: "apps/v1/deployment/nginx"

Siguientes pasos

4.2 - Manejo Declarativo de Objectos de Kubernetes usando Kustomize

Kustomize es una herramienta independiente para personalizar objetos de Kubernetes a través de un archivo de kustomization.

Desde la versión 1.14, Kubectl también admite la gestión de objetos de Kubernetes utilizando un archivo de kustomización. Para ver Recursos encontrados en un directorio que contiene un archivo de kustomización, ejecuta el siguiente comando:

kubectl kustomize <directorio_de_kustomización>

Para aplicar esos Recursos, ejecuta kubectl apply con la bandera --kustomize o -k :

kubectl apply -k <directorio_de_kustomización>

Antes de empezar

Instala kubectl.

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.

Descripción General de Kustomize

Kustomize es una herramienta para personalizar configuraciones de Kubernetes. Ofrece características para manejar archivos de configuración de aplicaciones, tales como:

  • Generar recursos a partir de otras fuentes.
  • Establecer campos transversales para los recursos.
  • Componer y personalizar colecciones de recursos.

Generando Recursos

ConfigMaps y Secrets almacenan configuración o datos sensibles utilizados por otros objetos de Kubernetes, como los Pods. La fuente de verdad de los ConfigMaps o Secrets suele ser externa a un clúster, como un archivo .properties o un archivo de clave SSH. Kustomize tiene secretGenerator y configMapGenerator, que generan Secret y ConfigMap a partir de archivos o literales.

configMapGenerator

Para generar un ConfigMap desde un archivo, añade una entrada en la lista files en configMapGenerator. Aquí tienes un ejemplo de cómo generar un ConfigMap con un elemento de datos de un archivo .properties:

# Crear un archivo application.properties
cat <<EOF >application.properties
FOO=Bar
EOF

cat <<EOF >./kustomization.yaml
configMapGenerator:
- name: example-configmap-1
  files:
  - application.properties
EOF

El ConfigMap generado se puede examinar con el siguiente comando:

kubectl kustomize ./

El ConfigMap generado es:

apiVersion: v1
data:
  application.properties: |
    FOO=Bar    
kind: ConfigMap
metadata:
  name: example-configmap-1-8mbdf7882g

Para generar un ConfigMap desde un archivo env, añade una entrada en la lista de envs en configMapGenerator. Aquí tienes un ejemplo de cómo generar un ConfigMap con un elemento de datos de un archivo .env:

# Crear un archivo .env
cat <<EOF >.env
FOO=Bar
EOF

cat <<EOF >./kustomization.yaml
configMapGenerator:
- name: example-configmap-1
  envs:
  - .env
EOF

El ConfigMap generado se puede examinar con el siguiente comando:

kubectl kustomize ./

El ConfigMap generado es:

apiVersion: v1
data:
  FOO: Bar
kind: ConfigMap
metadata:
  name: example-configmap-1-42cfbf598f

Los ConfigMaps también pueden generarse a partir de pares clave-valor literales. Para generar un ConfigMap a partir de una literal clave-valor, añade una entrada a la lista literals en configMapGenerator. Aquí hay un ejemplo de cómo generar un ConfigMap con un elemento de datos de un par clave-valor:

cat <<EOF >./kustomization.yaml
configMapGenerator:
- name: example-configmap-2
  literals:
  - FOO=Bar
EOF

El ConfigMap generado se puede verificar con el siguiente comando:

kubectl kustomize ./

El ConfigMap generado es:

apiVersion: v1
data:
  FOO: Bar
kind: ConfigMap
metadata:
  name: example-configmap-2-g2hdhfc6tk

Para usar un ConfigMap generado en un Deployment, refiérelo por el nombre del configMapGenerator. Kustomize reemplazará automáticamente este nombre con el nombre generado.

Este es un ejemplo de un Deployment que utiliza un ConfigMap generado:

# Crear un archivo application.properties
cat <<EOF >application.properties
FOO=Bar
EOF

cat <<EOF >deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  labels:
    app: my-app
spec:
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: app
        image: my-app
        volumeMounts:
        - name: config
          mountPath: /config
      volumes:
      - name: config
        configMap:
          name: example-configmap-1
EOF

cat <<EOF >./kustomization.yaml
resources:
- deployment.yaml
configMapGenerator:
- name: example-configmap-1
  files:
  - application.properties
EOF

Genera el ConfigMap y Deployment:

kubectl kustomize ./

El Deployment generado hara referencia al ConfigMap generado por nombre:

apiVersion: v1
data:
  application.properties: |
    FOO=Bar    
kind: ConfigMap
metadata:
  name: example-configmap-1-g4hk9g2ff8
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: my-app
  name: my-app
spec:
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - image: my-app
        name: app
        volumeMounts:
        - mountPath: /config
          name: config
      volumes:
      - configMap:
          name: example-configmap-1-g4hk9g2ff8
        name: config

secretGenerator

Puedes generar Secrets a partir de archivos o pares clave-valor literales. Para generar un Secret a partir de un archivo, añade una entrada a la lista files en secretGenerator. Aquí tienes un ejemplo de cómo generar un Secret con un elemento de datos de un archivo.

# Crea un archivo password.txt
cat <<EOF >./password.txt
username=admin
password=secret
EOF

cat <<EOF >./kustomization.yaml
secretGenerator:
- name: example-secret-1
  files:
  - password.txt
EOF

El Secret generado se vería de la siguiente manera:

apiVersion: v1
data:
  password.txt: dXNlcm5hbWU9YWRtaW4KcGFzc3dvcmQ9c2VjcmV0Cg==
kind: Secret
metadata:
  name: example-secret-1-t2kt65hgtb
type: Opaque

Para generar un Secret a partir de una literal clave-valor, añade una entrada a la lista literals en secretGenerator. Aquí tienes un ejemplo de cómo generar un Secret con un elemento de datos de un par clave-valor.

cat <<EOF >./kustomization.yaml
secretGenerator:
- name: example-secret-2
  literals:
  - username=admin
  - password=secret
EOF

El Secret generado se verá de la siguiente manera:

apiVersion: v1
data:
  password: c2VjcmV0
  username: YWRtaW4=
kind: Secret
metadata:
  name: example-secret-2-t52t6g96d8
type: Opaque

Al igual que los ConfigMaps, los Secrets generados pueden utilizarse en Deployments refiriéndose al nombre del secretGenerator.

# Crea un archivo password.txt 
cat <<EOF >./password.txt
username=admin
password=secret
EOF

cat <<EOF >deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  labels:
    app: my-app
spec:
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: app
        image: my-app
        volumeMounts:
        - name: password
          mountPath: /secrets
      volumes:
      - name: password
        secret:
          secretName: example-secret-1
EOF

cat <<EOF >./kustomization.yaml
resources:
- deployment.yaml
secretGenerator:
- name: example-secret-1
  files:
  - password.txt
EOF

generatorOptions

Los ConfigMaps y Secrets generados tienen un sufijo de hash de contenido añadido. Esto asegura que se genere un nuevo ConfigMap o Secret cuando se cambian los contenidos. Para desactivar el comportamiento de añadir un sufijo, se puede utilizar generatorOptions. Además, es posible especificar opciones transversales para los ConfigMaps y Secrets generados.

cat <<EOF >./kustomization.yaml
configMapGenerator:
- name: example-configmap-3
  literals:
  - FOO=Bar
generatorOptions:
  disableNameSuffixHash: true
  labels:
    type: generated
  annotations:
    note: generated
EOF

Ejecuta kubectl kustomize ./ para visualizar el ConfigMap generado:

apiVersion: v1
data:
  FOO: Bar
kind: ConfigMap
metadata:
  annotations:
    note: generated
  labels:
    type: generated
  name: example-configmap-3

Establecer campos transversales

Es bastante común establecer campos transversales para todos los recursos de Kubernetes en un proyecto. Algunos casos de uso para establecer campos transversales:

  • Establecer el mismo espacio de nombres para todos los Recursos
  • Agregar el mismo prefijo o sufijo de nombre
  • Agregar el mismo conjunto de etiquetas
  • Agregar el mismo conjunto de anotaciones

Aquí hay un ejemplo:

# Crea un deployment.yaml
cat <<EOF >./deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
EOF

cat <<EOF >./kustomization.yaml
namespace: my-namespace
namePrefix: dev-
nameSuffix: "-001"
commonLabels:
  app: bingo
commonAnnotations:
  oncallPager: 800-555-1212
resources:
- deployment.yaml
EOF

Ejecuta kubectl kustomize ./ para ver que esos campos están todos establecidos en el Recurso Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    oncallPager: 800-555-1212
  labels:
    app: bingo
  name: dev-nginx-deployment-001
  namespace: my-namespace
spec:
  selector:
    matchLabels:
      app: bingo
  template:
    metadata:
      annotations:
        oncallPager: 800-555-1212
      labels:
        app: bingo
    spec:
      containers:
      - image: nginx
        name: nginx

Componiendo y Personalizando Recursos

Es común componer un conjunto de recursos en un proyecto y gestionarlos dentro del mismo archivo o directorio.

Kustomize ofrece la composición de recursos desde diferentes archivos y la aplicación de parches u otras personalizaciones a ellos.

Composición

Kustomize admite la composición de diferentes recursos. El campo resources, en el archivo kustomization.yaml, define la lista de recursos para incluir en una configuración. Establece la ruta al archivo de configuración de un recurso en la lista resources.

Aquí hay un ejemplo de una aplicación NGINX compuesta por un Deployment y un Service:

# Crea un archivo deployment.yaml 
cat <<EOF > deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx
spec:
  selector:
    matchLabels:
      run: my-nginx
  replicas: 2
  template:
    metadata:
      labels:
        run: my-nginx
    spec:
      containers:
      - name: my-nginx
        image: nginx
        ports:
        - containerPort: 80
EOF

# Crea un archivo service.yaml 
cat <<EOF > service.yaml
apiVersion: v1
kind: Service
metadata:
  name: my-nginx
  labels:
    run: my-nginx
spec:
  ports:
  - port: 80
    protocol: TCP
  selector:
    run: my-nginx
EOF

# Crea un  kustomization.yaml que los integra
cat <<EOF >./kustomization.yaml
resources:
- deployment.yaml
- service.yaml
EOF

Los Recursos de kubectl kustomize ./ contienen tanto los objetos de Deployment como los de Service.

Personalizando

Los parches pueden usarse para aplicar diferentes personalizaciones a los recursos. Kustomize admite diferentes mecanismos de parcheo a través de patchesStrategicMerge y patchesJson6902. patchesStrategicMerge es una lista de rutas de archivo. Cada archivo debe resolverse en un parche de fusión estratégica. Los nombres dentro de los parches deben coincidir con los nombres de recursos que ya están cargados. Se recomiendan pequeños parches que hagan una sola cosa. Por ejemplo, crear un parche para aumentar el número de réplicas del Deployment y otro parche para establecer el límite de memoria.

# Crea un archivo deployment.yaml
cat <<EOF > deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx
spec:
  selector:
    matchLabels:
      run: my-nginx
  replicas: 2
  template:
    metadata:
      labels:
        run: my-nginx
    spec:
      containers:
      - name: my-nginx
        image: nginx
        ports:
        - containerPort: 80
EOF

# Crea un parche increase_replicas.yaml
cat <<EOF > increase_replicas.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx
spec:
  replicas: 3
EOF

# Crea otro parche set_memory.yaml
cat <<EOF > set_memory.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx
spec:
  template:
    spec:
      containers:
      - name: my-nginx
        resources:
          limits:
            memory: 512Mi
EOF

cat <<EOF >./kustomization.yaml
resources:
- deployment.yaml
patchesStrategicMerge:
- increase_replicas.yaml
- set_memory.yaml
EOF

Ejecuta kubectl kustomize ./ para visualizar el Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      run: my-nginx
  template:
    metadata:
      labels:
        run: my-nginx
    spec:
      containers:
      - image: nginx
        name: my-nginx
        ports:
        - containerPort: 80
        resources:
          limits:
            memory: 512Mi

No todos los recursos o campos admiten parches de fusión estratégica. Para admitir la modificación de campos arbitrarios en recursos arbitrarios, Kustomize ofrece la implementacion a través de JSON patch patchesJson6902. Para encontrar el Recurso correcto para un parche Json, el grupo, versión, tipo y nombre de ese recurso necesitan ser especificados en kustomization.yaml. Por ejemplo, aumentar el número de réplicas de un objeto de Deployment también se puede hacer a través de patchesJson6902.

# Crea un archivo deployment.yaml 
cat <<EOF > deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx
spec:
  selector:
    matchLabels:
      run: my-nginx
  replicas: 2
  template:
    metadata:
      labels:
        run: my-nginx
    spec:
      containers:
      - name: my-nginx
        image: nginx
        ports:
        - containerPort: 80
EOF

# Crea un parche en json
cat <<EOF > patch.yaml
- op: replace
  path: /spec/replicas
  value: 3
EOF

# Crea un  kustomization.yaml
cat <<EOF >./kustomization.yaml
resources:
- deployment.yaml

patchesJson6902:
- target:
    group: apps
    version: v1
    kind: Deployment
    name: my-nginx
  path: patch.yaml
EOF

Ejecuta kubectl kustomize ./ para ver que el campo replicas está actualizado:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      run: my-nginx
  template:
    metadata:
      labels:
        run: my-nginx
    spec:
      containers:
      - image: nginx
        name: my-nginx
        ports:
        - containerPort: 80

Además de los parches, Kustomize también ofrece personalizar imágenes de contenedores o inyectar valores de campos de otros objetos en contenedores sin crear parches. Por ejemplo, puedes cambiar la imagen utilizada dentro de los contenedores especificando la nueva imagen en el campo images en kustomization.yaml.

cat <<EOF > deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx
spec:
  selector:
    matchLabels:
      run: my-nginx
  replicas: 2
  template:
    metadata:
      labels:
        run: my-nginx
    spec:
      containers:
      - name: my-nginx
        image: nginx
        ports:
        - containerPort: 80
EOF

cat <<EOF >./kustomization.yaml
resources:
- deployment.yaml
images:
- name: nginx
  newName: my.image.registry/nginx
  newTag: 1.4.0
EOF

Ejecuta kubectl kustomize ./ para ver que el campo image ha sido actualizado:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      run: my-nginx
  template:
    metadata:
      labels:
        run: my-nginx
    spec:
      containers:
      - image: my.image.registry/nginx:1.4.0
        name: my-nginx
        ports:
        - containerPort: 80

A veces, la aplicación que se ejecuta en un Pod puede necesitar usar valores de configuración de otros objetos. Por ejemplo, un Pod de un objeto de Deployment necesita leer el nombre del Service correspondiente desde Env o como un argumento de comando.

Dado que el nombre del Service puede cambiar a medida que se agrega namePrefix o nameSuffix en el archivo kustomization.yaml. No se recomienda codificar de manera fija el nombre del Service en el argumento del comando. Para este uso, Kustomize puede inyectar el nombre del Service en los contenedores a través de vars.

# Crea un archivo deployment.yaml (citando el delimitador de documento aquí)
cat <<'EOF' > deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx
spec:
  selector:
    matchLabels:
      run: my-nginx
  replicas: 2
  template:
    metadata:
      labels:
        run: my-nginx
    spec:
      containers:
      - name: my-nginx
        image: nginx
        command: ["start", "--host", "$(MY_SERVICE_NAME)"]
EOF

# Crea un archivo service.yaml 
cat <<EOF > service.yaml
apiVersion: v1
kind: Service
metadata:
  name: my-nginx
  labels:
    run: my-nginx
spec:
  ports:
  - port: 80
    protocol: TCP
  selector:
    run: my-nginx
EOF

cat <<EOF >./kustomization.yaml
namePrefix: dev-
nameSuffix: "-001"

resources:
- deployment.yaml
- service.yaml

vars:
- name: MY_SERVICE_NAME
  objref:
    kind: Service
    name: my-nginx
    apiVersion: v1
EOF

Ejecuta kubectl kustomize ./ para ver que el nombre del Service inyectado en la sección de contaierns es dev-my-nginx-001:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: dev-my-nginx-001
spec:
  replicas: 2
  selector:
    matchLabels:
      run: my-nginx
  template:
    metadata:
      labels:
        run: my-nginx
    spec:
      containers:
      - command:
        - start
        - --host
        - dev-my-nginx-001
        image: nginx
        name: my-nginx

Bases y Overlays

Kustomize tiene los conceptos de bases y overlays. Una base es un directorio con un kustomization.yaml, que contiene un conjunto de recursos y personalización asociada. Una base puede ser un directorio local o un directorio de un repositorio remoto, siempre que haya un kustomization.yaml presente dentro. Un overlay es un directorio con un kustomization.yaml que se refiere a otros directorios de kustomization como sus bases. Una base no tiene conocimiento de un overlay y puede ser utilizada en múltiples overlays. Un overlay puede tener múltiples bases y compone todos los recursos de las bases y también puede tener personalizaciones encima de ellos.

Aquí hay un ejemplo de una base:


# Crea un directorio que tendrá la **base**

mkdir base

# Crea el archivo base/deployment.yaml
cat <<EOF > base/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx
spec:
  selector:
    matchLabels:
      run: my-nginx
  replicas: 2
  template:
    metadata:
      labels:
        run: my-nginx
    spec:
      containers:
      - name: my-nginx
        image: nginx
EOF

# Crea el archivo base/service.yaml 
cat <<EOF > base/service.yaml
apiVersion: v1
kind: Service
metadata:
  name: my-nginx
  labels:
    run: my-nginx
spec:
  ports:
  - port: 80
    protocol: TCP
  selector:
    run: my-nginx
EOF
# Crea un archivo base/kustomization.yaml
cat <<EOF > base/kustomization.yaml
resources:
- deployment.yaml
- service.yaml
EOF

Esta base puede ser utilizada en múltiples overlays. Puedes agregar diferentes namePrefix u otros campos transversales en diferentes overlays. Aquí hay dos overlays utilizando la misma base.

mkdir dev
cat <<EOF > dev/kustomization.yaml
resources:
- ../base
namePrefix: dev-
EOF

mkdir prod
cat <<EOF > prod/kustomization.yaml
resources:
- ../base
namePrefix: prod-
EOF

Cómo aplicar/ver/eliminar objetos usando Kustomize

Usa --kustomize o -k en comandos de kubectl para reconocer recursos gestionados por kustomization.yaml. Nota que -k debe apuntar a un directorio de kustomization, tal como:

kubectl apply -k <kustomization directory>/

Dando como resultado el siguientekustomization.yaml,

# Crea un archivo deployment.yaml 
cat <<EOF > deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx
spec:
  selector:
    matchLabels:
      run: my-nginx
  replicas: 2
  template:
    metadata:
      labels:
        run: my-nginx
    spec:
      containers:
      - name: my-nginx
        image: nginx
        ports:
        - containerPort: 80
EOF

# Crea un archivo kustomization.yaml
cat <<EOF >./kustomization.yaml
namePrefix: dev-
commonLabels:
  app: my-nginx
resources:
- deployment.yaml
EOF

Ejecuta el siguiente comando para aplicar el objeto de Deployment dev-my-nginx:

> kubectl apply -k ./
deployment.apps/dev-my-nginx created

Ejecuta uno de los siguientes comandos para ver el objeto de Deployment dev-my-nginx:

kubectl get -k ./
kubectl describe -k ./

Ejecuta el siguiente comando para comparar el objecto Deployment dev-my-nginx contra el estado en el que estaría el clúster si se aplicara el manifiesto:

kubectl diff -k ./

Ejecuta el siguiente comando para eliminar el objeto de Deployment dev-my-nginx:

> kubectl delete -k ./
deployment.apps "dev-my-nginx" deleted

Kustomize Feature List

Campo Tipo Explicación
namespace string Agregar namespace a todos los recursos
namePrefix string El valor de este campo se antepone a los nombres de todos los recursos
nameSuffix string El valor de este campo se añade al final de los nombres de todos los recursos
commonLabels map[string]string Etiquetas para agregar a los recursos y selectores.
commonAnnotations map[string]string Anotaciones para agregar a todos los recursos
resources []string Cada entrada en esta lista debe resolverse en un archivo de configuración de recurso existente
configMapGenerator []ConfigMapArgs Cada entrada en esta lista genera un ConfigMap
secretGenerator []SecretArgs Cada entrada en esta lista genera un Secret
generatorOptions GeneratorOptions Modifica comportamientos de todos los generadores de ConfigMap y Secret
bases []string Cada entrada en esta lista debe resolverse en un directorio que contenga un archivo kustomization.yaml
patchesStrategicMerge []string Cada entrada en esta lista debe resolver un parche de fusión estratégica de un objeto de Kubernetes
patchesJson6902 []Patch Cada entrada en esta lista debe resolverse en un objeto de Kubernetes y un parche Json
vars []Var Cada entrada es para capturar texto del campo de un recurso
images []Image Cada entrada es para modificar el nombre, las etiquetas y/o el digesto de una imagen sin crear parches
configurations []string Cada entrada en esta lista debe resolverse en un archivo que contenga Configuraciones de transformador de Kustomize
crds []string Cada entrada en esta lista debería resolver a un archivo de definición OpenAPI para los tipos de Kubernetes.

Siguientes pasos

4.3 - Administración Imperativa de Objetos de Kubernetes Mediante Archivos de Configuración

Los objetos de Kubernetes se pueden crear, actualizar y eliminar utilizando la herramienta de línea de comandos kubectl junto con un archivo de configuración de objetos escrito en YAML o JSON. Este documento explica cómo definir y gestionar objetos utilizando archivos de configuración.

Antes de empezar

Instalar kubectl.

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.

Opciones

La herramienta kubectl admite tres tipos de administración de objetos:

  • Comandos imperativos
  • Configuración de objeto imperativo.
  • Configuración de objeto declarativo

Consulta Administración de objetos de Kubernetes para una discusión de las ventajas y desventajas de cada tipo de administración de objetos.

¿Cómo crear objetos?

Puede usar kubectl create -f para crear un objeto a partir de un archivo de configuración. Consulta la referencia de la API de Kubernetes para mas detalles.

  • kubectl create -f <filename|url>

¿Cómo actualizar objetos?

Puedes usar kubectl replace -f para actualizar un objeto en activo de acuerdo con un archivo de configuración.

  • kubectl replace -f <filename|url>

¿Cómo eliminar objetos?

Puedes usar kubectl delete -f para eliminar un objeto que se describe en un archivo de configuración.

  • kubectl delete -f <filename|url>

¿Cómo ver un objeto?

Puedes usar kubectl get -f para ver información sobre un objeto que está descrito en un archivo de configuración.

  • kubectl get -f <filename|url> -o yaml

La bandera -o yaml especifica que se imprime la configuración completa del objeto. Utiliza kubectl get -h para ver una lista de opciones.

Limitaciones

Los comandos create, replace y delete funcionan bien cuando la configuración de cada objeto está completamente definida y registrada en su archivo de configuración. Sin embargo, cuando se actualiza un objeto activo y las actualizaciones no se combinan en su archivo de configuración las actualizaciones se perderán la próxima vez que se ejecute un replace. Esto puede suceder si un controlador, como un HorizontalPodAutoscaler, realiza actualizaciones directamente a un objeto en activo. Los comandos create, replace y delete funcionan bien cuando la configuración de cada objeto está completamente definida y registrada en su archivo de configuración. Sin embargo, cuando se actualiza un objeto activo y las actualizaciones no se combinan en su archivo de configuración las actualizaciones se perderán la próxima vez que se ejecute un replace. Esto puede suceder si un controlador, como un HorizontalPodAutoscaler, realice actualizaciones directamente a un objeto en activo.

Ejemplo:

  1. Creas un objeto a partir de un archivo de configuración.
  2. Otra fuente actualiza el objeto cambiando algún campo.
  3. Reemplaza el objeto del archivo de configuración. Cambios hechos por la otra fuente en el paso 2 se pierden.

Si necesitas admitir varios escritores en el mismo objeto, puede usar kubectl apply para administrar el objeto.

Crear y editar un objeto desde una URL sin guardar la configuración

Supongamos que tienes la URL de un archivo de configuración de objeto. Puedes usar

  1. Exporta el objeto en vivo a un archivo de configuración de objeto local. que apuntan a un archivo de configuración que podría ser modificado por el lector.
kubectl create -f <url> --edit

Migración de comandos imperativos a configuración de objetos imperativos

La migración de comandos imperativos a la configuración de objetos imperativos implica varios pasos manuales.

  1. Exporta el objeto en vivo a un archivo de configuración de objeto local.

    kubectl get <kind>/<name> -o yaml > <kind>_<name>.yaml
    
  2. Elimina manualmente el campo de estado del archivo de configuración del objeto.

  3. Para la gestión posterior de objetos, utiliza replace exclusivamente.

    kubectl replace -f <kind>_<name>.yaml
    

Definiendo selectores de controlador y etiquetas PodTemplate

El enfoque recomendado es definir una etiqueta PodTemplate única e inmutable utilizada únicamente por el selector del controlador sin ningún otro significado semántico.

Etiqueta de ejemplo:

selector:
  matchLabels:
      controller-selector: "apps/v1/deployment/nginx"
template:
  metadata:
* [Referencia de la API de Kubernetes](/docs/reference/generated/kubernetes-api/v1.30/)
      controller-selector: "apps/v1/deployment/nginx"

Siguientes pasos

4.4 - Actualiza Objetos del API en su sitio (in Place) usando kubectl patch

Usa kubectl patch para actualizar objetos del API de kubernetes sin reemplazarlos. Usa strategic merge patch o JSON merge patch.

Esta tarea muestra cómo utilizar kubectl patch para actualizar un objeto del API sin reemplazarlo. Los ejercicios de esta tarea demuestran el uso de "strategic merge patch" y "JSON merge patch"

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.

Usa strategic merge patch para actualizar un Deployment

Aquí está el archivo de configuración para un Deployment con dos réplicas. Cada réplica es un Pod que tiene un contenedor:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: patch-demo
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: patch-demo-ctr
        image: nginx
      tolerations:
      - effect: NoSchedule
        key: dedicated
        value: test-team

Crea el Deployment:

kubectl apply -f https://k8s.io/examples/application/deployment-patch.yaml

Revisa los Pods asociados con tu Deployment:

kubectl get pods

El resultado muestra que el Deployment tiene dos Pods. El 1/1 indica que cada Pod tiene un contenedor:

NAME                        READY     STATUS    RESTARTS   AGE
patch-demo-28633765-670qr   1/1       Running   0          23s
patch-demo-28633765-j5qs3   1/1       Running   0          23s

Toma nota de los nombres de los Pods que se están ejecutando. Verás que estos Pods son terminados y reemplazados posteriormente.

En este punto cada Pod tiene un contenedor que ejecuta una imagen de nginx. Ahora supón que quieres que cada Pod tenga dos contenedores: uno que ejecute nginx y otro que ejecute redis.

Crea un archivo llamado patch-file.yaml con el siguiente contenido:

spec:
  template:
    spec:
      containers:
      - name: patch-demo-ctr-2
        image: redis

Modifica tu Deployment usando Patch:

kubectl patch deployment patch-demo --patch-file patch-file.yaml

Revisa el Deployment modificado:

kubectl get deployment patch-demo --output yaml

El resultado muestra que el PodSpec del Deployment tiene dos contenedores:

containers:
- image: redis
  imagePullPolicy: Always
  name: patch-demo-ctr-2
  ...
- image: nginx
  imagePullPolicy: Always
  name: patch-demo-ctr
  ...

Revisa los Pods asociados con tu Deployment modificado:

kubectl get pods

El resultado muestra que los Pods tienen un nombre distinto a los que se estaban ejecutando anteriormente. El Deployment terminó los Pods viejos y creo dos nuevos que cumplen con la especificación actualizada del Deployment. El 2/2 indica que cada Pod tiene dos contenedores:

NAME                          READY     STATUS    RESTARTS   AGE
patch-demo-1081991389-2wrn5   2/2       Running   0          1m
patch-demo-1081991389-jmg7b   2/2       Running   0          1m

Un vistazo más de cerca a uno de los Pods del patch-demo:

kubectl get pod <your-pod-name> --output yaml

El resultado muestra que el Pod tienen dos contenedores: uno ejecutando nginx y otro redis:

containers:
- image: redis
  ...
- image: nginx
  ...

Notas acerca de strategic merge patch

El patch que hiciste en el ejercicio anterior se llama strategic merge patch. Toma en cuenta que el path no reemplazó la lista containers. Sino que agregó un contenedor nuevo a la lista. En otras palabras, la lista en el patch fue agregada a la lista ya existente. Esto no es lo que pasa siempre que se utiliza strategic merge patch en una lista. En algunos casos la lista existente podría ser reemplazada en lugar de unir ambas.

Con strategic merge patch, la lista existente puede ser reemplazada o unida con la nueva dependiendo de la estrategia de patch. La estrategia de patch se especifica en el valor de la clave patchStrategyen un campo tag del código fuente de Kubernetes. Por ejemplo el campo Containers de la struct PodSpec tiene un valor de merge en su clave patchStrategy:

type PodSpec struct {
  ...
  Containers []Container `json:"containers" patchStrategy:"merge" patchMergeKey:"name" ...`
  ...
}

También puedes consultar la estrategia de patch en OpenApi spec:

"io.k8s.api.core.v1.PodSpec": {
    ...,
    "containers": {
        "description": "List of containers belonging to the pod.  ...."
    },
    "x-kubernetes-patch-merge-key": "name",
    "x-kubernetes-patch-strategy": "merge"
}

Y puedes consultar la estrategia de patch en la Documentación del API Kubernetes.

Crea un archivo llamado patch-file-tolerations.yaml que tenga el siguiente contenido:

spec:
  template:
    spec:
      tolerations:
      - effect: NoSchedule
        key: disktype
        value: ssd

Modifica tu Deployment utilizando Patch:

kubectl patch deployment patch-demo --patch-file patch-file-tolerations.yaml

Revisa el Deployment modificado:

kubectl get deployment patch-demo --output yaml

El resultado muestra que el PodsSpec del Deployment tiene solo un Toleration:

tolerations:
- effect: NoSchedule
  key: disktype
  value: ssd

Toma en cuenta que la lista de tolerations en el PodSpec fue reemplazada, no unida. Esto es porque el campo de Tolerations del PodSpec no tiene una clave patchStrategy en su campo de tag. por lo tanto strategic merge patch utiliza la estrategia de patch por defecto, la cual es replace.

type PodSpec struct {
  ...
  Tolerations []Toleration `json:"tolerations,omitempty" protobuf:"bytes,22,opt,name=tolerations"`
  ...
}

Usa JSON merge patch para actualizar un Deployment

Un strategic merge patch es distinto a un JSON merge patch.

Con JSON merge patch, si quieres actualizar una lista tienes que especificar la lista nueva en su totalidad y reemplazar la lista existente con la lista nueva.

El comando kubectl patch tiene un parámetro type que acepta los siguientes valores:

Valor del parámetrotipo de unión
jsonJSON Patch, RFC 6902
mergeJSON Merge Patch, RFC 7386
strategicStrategic merge patch

Para una comparación entre JSON patch y JSON merge patch, revisa JSON Patch y JSON Merge Patch.

El valor predeterminado para el parámetro type es strategic. Entonces en el ejercicio anterior hiciste un strategic merge patch.

A continuación haz un JSON merge path en el mismo Deployment. Crea un archivo llamado patch-file-2.yaml que tenga el siguiente contenido:

spec:
  template:
    spec:
      containers:
      - name: patch-demo-ctr-3
        image: gcr.io/google-samples/node-hello:1.0

En el comando patch configura el valor de type como merge

kubectl patch deployment patch-demo --type merge --patch-file patch-file-2.yaml

Revisa el Deployment modificado:

kubectl get deployment patch-demo --output yaml

La lista containers que especificaste en el patch solo tiene un contenedor. el resultado muestra que tu lista con un contenedor reemplazó a la lista containers preexistente.

spec:
  containers:
  - image: gcr.io/google-samples/node-hello:1.0
    ...
    name: patch-demo-ctr-3

Revisa los Pods en ejecución:

kubectl get pods

En el resultado se puede ver que los Pods existentes fueron terminados y se crearon Pods nuevos. El 1/1 indica que cada Pod nuevo esta ejecutando un solo contenedor.

NAME                          READY     STATUS    RESTARTS   AGE
patch-demo-1307768864-69308   1/1       Running   0          1m
patch-demo-1307768864-c86dc   1/1       Running   0          1m

Usa strategic merge patch para actualizar un Deployment utilizando la estrategia retainKeys

Aquí esta el archivo de configuración para un Deployment que usa la estrategia RollingUpdate:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: retainkeys-demo
spec:
  selector:
    matchLabels:
      app: nginx
  strategy:
    rollingUpdate:
      maxSurge: 30%
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: retainkeys-demo-ctr
        image: nginx

Crea el Deployment:

kubectl apply -f https://k8s.io/examples/application/deployment-retainkeys.yaml

En este punto, el Deployment es creado y está usando la estrategia RollingUpdate.

Crea un archivo llamado patch-file-no-retainkeys.yaml con el siguiente contenido:

spec:
  strategy:
    type: Recreate

Modifica tu Deployment:

kubectl patch deployment retainkeys-demo --type strategic --patch-file patch-file-no-retainkeys.yaml

En el resultado se puede ver que no es posible definir el type como Recreate cuando hay un value definido para spec.strategy.rollingUpdate:

The Deployment "retainkeys-demo" is invalid: spec.strategy.rollingUpdate: Forbidden: may not be specified when strategy `type` is 'Recreate'

La forma para quitar el valor para spec.strategy.rollingUpdate al momento de cambiar el valor type es usar la estrategia retainKeys para el strategic merge.

Crea otro archivo llamado patch-file-retainkeys.yaml con el siguiente contenido:

spec:
  strategy:
    $retainKeys:
    - type
    type: Recreate

Con este Patch definimos que solo queremos conservar la clave type del objeto strategy. Por lo tanto la clave rollingUpdate será eliminada durante la operación de modificación.

Modifica tu Deployment de nuevo con este nuevo Patch:

kubectl patch deployment retainkeys-demo --type strategic --patch-file patch-file-retainkeys.yaml

Revisa el contenido del Deployment:

kubectl get deployment retainkeys-demo --output yaml

El resultado muestra que el objeto strategy en el Deployment ya no contiene la clave rollingUpdate:

spec:
  strategy:
    type: Recreate
  template:

Notas acerca de strategic merge patch utilizando la estrategia retainKeys

La modificación realizada en el ejercicio anterior tiene el nombre de strategic merge patch con estrategia retainKeys. Este método introduce una nueva directiva $retainKeys que tiene las siguientes estrategias:

  • Contiene una lista de strings.
  • Todos los campos que necesiten ser preservados deben estar presentes en la lista $retainKeys.
  • Todos los campos que estén presentes serán combinados con el objeto existente.
  • Todos los campos faltantes serán removidos o vaciados al momento de la modificación.
  • Todos los campos en la lista $retainKeys deberán ser un superconjunto o idéntico a los campos presentes en el Patch.

La estrategia retainKeys no funciona para todos los objetos. Solo funciona cuando el valor de la key patchStrategyen el campo tag de el código fuente de Kubernetes contenga retainKeys. Por ejemplo, el campo Strategy del struct DeploymentSpec tiene un valor de retainKeys en su tag patchStrategy

type DeploymentSpec struct {
  ...
  // +patchStrategy=retainKeys
  Strategy DeploymentStrategy `json:"strategy,omitempty" patchStrategy:"retainKeys" ...`
  ...
}

También puedes revisar la estrategia retainKeys en la especificación de OpenApi:

"io.k8s.api.apps.v1.DeploymentSpec": {
    ...,
    "strategy": {
        "$ref": "#/definitions/io.k8s.api.apps.v1.DeploymentStrategy",
        "description": "The deployment strategy to use to replace existing pods with new ones.",
        "x-kubernetes-patch-strategy": "retainKeys"
    },
    ....
}

Además puedes revisar la estrategia retainKeys en la documentación del API de k8s.

Formas alternativas del comando kubectl patch

El comando kubectl patch toma como entrada un archivo en formato YAML o JSON desde el sistema de archivos o la línea de comandos.

Crea un archivo llamado patch-file.json que contenga lo siguiente:

{
   "spec": {
      "template": {
         "spec": {
            "containers": [
               {
                  "name": "patch-demo-ctr-2",
                  "image": "redis"
               }
            ]
         }
      }
   }
}

Los siguientes comandos son equivalentes:

kubectl patch deployment patch-demo --patch-file patch-file.yaml
kubectl patch deployment patch-demo --patch 'spec:\n template:\n  spec:\n   containers:\n   - name: patch-demo-ctr-2\n     image: redis'

kubectl patch deployment patch-demo --patch-file patch-file.json
kubectl patch deployment patch-demo --patch '{"spec": {"template": {"spec": {"containers": [{"name": "patch-demo-ctr-2","image": "redis"}]}}}}'

Actualiza la cantidad de réplicas de un objeto utilizando kubectl patch con --subresource

FEATURE STATE: Kubernetes v1.24 [alpha]

La bandera --subresource=[subresource-name] es utilizada con comandos de kubectl como get, patch y replace para obtener y actualizar los subrecursos status y scale de los recursos (aplicable para las versiones de kubectl de v1.24 en adelante). Esta bandera se utiliza con todos los recursos del API (incluidos en k8s o CRs) que tengan los subrecursos status o scale. Deployment es un ejemplo de un objeto con estos subrecursos.

A continuación se muestra un ejemplo de un Deployment con dos réplicas:

apiVersion: apps/v1 # Usa apps/v1beta2 para versiones anteriores a 1.9.0
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 2 # indica al controlador que ejecute 2 pods
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

Crea el Deployment:

kubectl apply -f https://k8s.io/examples/application/deployment.yaml

Revisa los Pods asociados al Deployment

kubectl get pods -l app=nginx

En el resultado se puede observar que el Deployment tiene dos Pods:

NAME                                READY   STATUS    RESTARTS   AGE
nginx-deployment-7fb96c846b-22567   1/1     Running   0          47s
nginx-deployment-7fb96c846b-mlgns   1/1     Running   0          47s

Ahora modifica el Deployment utilizando Patch con la bandera --subresource=[subresource-name]:

kubectl patch deployment nginx-deployment --subresource='scale' --type='merge' -p '{"spec":{"replicas":3}}'

El resultado es :

scale.autoscaling/nginx-deployment patched

Revisa los Pods asociados al Deployment modificado:

kubectl get pods -l app=nginx

En el resultado se puede apreciar que se ha creado un Pod nuevo. Ahora tienes 3 Pods en ejecución.

NAME                                READY   STATUS    RESTARTS   AGE
nginx-deployment-7fb96c846b-22567   1/1     Running   0          107s
nginx-deployment-7fb96c846b-lxfr2   1/1     Running   0          14s
nginx-deployment-7fb96c846b-mlgns   1/1     Running   0          107s

Revisa el Deployment modificado

kubectl get deployment nginx-deployment -o yaml
...
spec:
  replicas: 3
  ...
status:
  ...
  availableReplicas: 3
  readyReplicas: 3
  replicas: 3

Resumen

En este ejercicio utilizaste kubectl patch para cambiar la configuración en ejecución de un objeto de tipo Deployment. No hubo cambios al archivo de configuración que se utilizó originalmente para crear el Deployment. Otros comandos utilizados para actualizar objetos del API incluyen: kubectl annotate, kubectl edit, kubectl replace, kubectl scale, y kubectl apply.

Siguientes pasos

5 - Inyectar datos en las aplicaciones

6 - Gestionar y ejecutar aplicaciones

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.0
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 2 # indica al controlador que ejecute 2 pods
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80
  1. Crea un deployment basado en el fichero YAML:

     kubectl apply -f https://k8s.io/examples/application/deployment.yaml
    
  2. Obtén información acerca del deployment:

     kubectl describe deployment nginx-deployment
    

    El resultado es similar a esto:

     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.
    
  3. 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
    
  4. 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.0
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 2
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.8 # Actualiza la versión de nginx de 1.7.9 a 1.8
        ports:
        - containerPort: 80
  1. Aplica el nuevo fichero YAML:

      kubectl apply -f https://k8s.io/examples/application/deployment-update.yaml
    
  2. 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.0
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 4 # Actualiza el número de réplicas de 2 a 4
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.8
        ports:
        - containerPort: 80
  1. Aplica el nuevo fichero YAML:

     kubectl apply -f https://k8s.io/examples/application/deployment-scale.yaml
    
  2. Verifica que el deployment tiene cuatro pods:

     kubectl get pods -l app=nginx
    

    El resultado es similar a esto:

     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.

Siguientes pasos

6.2 - Escalar un StatefulSet

Esta página muestra cómo escalar un StatefulSet. Escalar un StatefulSet es incrementar o decrementar el número de réplicas.

Antes de empezar

  • Los StatefulSets están solamente disponibles en Kubernetes 1.5 o posterior. Para verificar su versión de Kubernetes puede ejecutar kubectl version.

  • No todas las aplicaciones que manejan estados escalan correctamente. Si no está seguro sobre si puede escalar sus StatefulSets, visite los conceptos de StatefulSet o el tutorial sobre StatefulSet para más información.

  • Solamente se debe realizar un escalamiento cuando esté lo suficientemente seguro del buen funcionamiento de su clúster y de las aplicaciones que manejan estados.

Escalando StatefulSets

Uso de kubectl para escalar StatefulSets

Como primer paso, identifica el StatefulSet que deseas escalar.

kubectl get statefulsets <nombre-del-stateful-set>

Cambia el número de réplicas de tu StatefulSet:

kubectl scale statefulsets <nombre-del-stateful-set> --replicas=<número-de-réplicas>

Hacer actualizaciones "in-place" en los StatefulSets

De manera alternativa, se pueden hacer actualizaciones in-place en tus StatefulSets.

Si el StatefulSet fue inicialmente creado con kubectl apply, puedes actualizar .spec.replicas en el manifiesto previamente definido y ahí hacer kubectl apply:

kubectl apply -f <archivo-stateful-set-actualizado>

De otra manera, edita esa línea con kubectl edit:

kubectl edit statefulsets <nombre-del-stateful-set>

También puedes usar kubectl patch:

kubectl patch statefulsets <nombre-del-stateful-set> -p '{"spec":{"replicas":<número-de-réplicas>}}'

Solución de Problemas

El escalamiento hacia abajo no funciona correctamente

No se puede escalar hacia abajo un StatefulSet cuando alguno de los Pods que administra está dañado. Desescalar solo tiene lugar después de tener los Pods disponibles.

Si spec.replicas > 1, Kubernetes no puede determinar la razón de un Pod dañado. Esto puede ser el resultado de una falla permanente o una falla transitoria. Una falla transitoria puede ser causada por un reinicio necesario para una actualización o mantenimiento.

Si el Pod está dañado con una falla permanente, escalar sin corregir la falla puede llevarnos a un estado donde el StatefulSet cae en una cantidad de miembros inferior a la cantidad de replicas que son necesarias para funcionar correctamente. Esto puede causar que el StatefulSet no este disponible.

Si el Pod está dañado por una falla transitoria y el Pod puede volver a estar disponible nuevamente, el error transitorio puede interferir con la operación de escalar. Algunas bases de datos distribuidas tienen errores cuando los nodos se unen y abandonan en el mismo momento. Es mejor analizar acerca de escalar la operación a nivel de la aplicación y realizar el escalamiento solamente cuando está seguro que el clúster de la aplicación está funcionando y en buen estado.

Siguientes pasos

6.3 - Borrar un StatefulSet

Esta página muestra cómo se debe eliminar un StatefulSet.

Antes de empezar

  • Se asume que se tiene una aplicación del tipo StatefulSet corriendo en tu clúster.

Borrando un StatefulSet

Se puede eliminar un StatefulSet de la misma manera que se eliminan el resto de los recursos en Kubernetes: Usa el comando kubectl delete y especifica el StatefulSet, usando su nombre o el archivo con el que fue creado.

kubectl delete -f <archivo.yaml>
kubectl delete statefulsets <nombre-del-stateful-set>

Puede suceder que necesites eliminar los servicios headless asociados después de eliminar el StatefulSet.

kubectl delete service <nombre-del-servicio>

Cuando se elimina un StatefulSet utilizando kubectl, el StatefulSet escala a 0. Todos los Pods que eran parte de esta carga de trabajo son eliminados. Si tú quieres eliminar solo el StatefulSet y no los Pods utiliza --cascade=orphan. Por ejemplo:

kubectl delete -f <archivo.yaml> --cascade=orphan

Agregando --cascade=orphan al comando kubectl delete, los Pods administrados por el StatefulSet dejan de pertenecer al StatefulSet cuando es eliminado. Si los pods tienen una etiqueta app.kubernetes.io/name=MyApp se los puede eliminar de la siguiente manera:

kubectl delete pods -l app.kubernetes.io/name=MyApp

Volúmenes Persistentes

Eliminar los Pods de un StatefulSet no va a eliminar los volúmenes asociados. Esto es para asegurar que se tiene una oportunidad de copiar los datos fuera del volumen antes de eliminarlo. Borrar el PVC después de que los pods estén terminados puede disparar la eliminación del Volumen Persistente que hay detrás dependiendo de la clase de almacenamiento y la política de reclamo. Nunca debes asumir la capacidad de acceder a un volumen después de la eliminación del claim.

Eliminación completa de un StatefulSet

Para eliminar todo en un StatefulSet, incluyendo los pods asociados, se puede correr una serie de comandos similares a los siguientes:

grace=$(kubectl get pods <stateful-set-pod> --template '{{.spec.terminationGracePeriodSeconds}}')
kubectl delete statefulset -l app.kubernetes.io/name=MyApp
sleep $grace
kubectl delete pvc -l app.kubernetes.io/name=MyApp

En este ejemplo, los Pods tienen la etiqueta app.kubernetes.io/name=MyApp, sustituye la misma por tu propia etiqueta.

Forzar la eliminación de los Pods de un StatefulSet

Si encuentras algunos pods bloqueados en tu StatefulSet en el estado 'Terminating' o 'Unknown' por un largo período de tiempo, puede ser que necesites intervenir manualmente para forzar la eliminación de los pods del apiserver. Ésta es una tarea potencialmente riesgosa. Visita Forzar eliminación de Pods en StatefulSet para más detalles.

Siguientes pasos

Aprende más sobre Forzar eliminación de Pods en StatefulSet.

6.4 - Eliminación Forzosa de Pods de StatefulSet

Esta página muestra cómo eliminar Pods que son parte de un StatefulSet, y explica las consideraciones a tener en cuenta al hacerlo.

Antes de empezar

  • Esta es una tarea bastante avanzada y tiene el potencial de violar algunas de las propiedades inherentes de StatefulSet.
  • Antes de proceder, familiarízate con las consideraciones enumeradas a continuación.

Consideraciones de StatefulSet

En la operación normal de un StatefulSet, nunca hay necesidad de eliminar forzosamente un Pod de StatefulSet. El controlador de StatefulSet es responsable de crear, escalar y eliminar miembros del StatefulSet. Intenta asegurar que el número especificado de Pods, desde el ordinal 0 hasta N-1, estén vivos y listos. StatefulSet asegura que, en cualquier momento, exista como máximo un Pod con una identidad dada, corriendo en un clúster. Esto se refiere a la semántica de como máximo uno proporcionada por un StatefulSet.

La eliminación manual forzada debe realizarse con precaución, ya que tiene el potencial de violar la semántica de como máximo uno, inherente a StatefulSet. Los StatefulSets pueden usarse para ejecutar aplicaciones distribuidas y agrupadas que necesitan una identidad de red estable y almacenamiento estable. Estas aplicaciones a menudo tienen configuraciones que dependen de un conjunto de un número fijo de miembros con identidades fijas. Tener múltiples miembros con la misma identidad puede ser desastroso y puede llevar a pérdida de datos (por ejemplo, escenario de cerebro dividido en sistemas basados en quórum).

Eliminar Pods

Puedes realizar una eliminación de Pod paulatina con el siguiente comando:

kubectl delete pods <pod>

Para que lo anterior conduzca a una terminación paulatina, el Pod no debe especificar un pod.Spec.TerminationGracePeriodSeconds de 0. La práctica de establecer un pod.Spec.TerminationGracePeriodSeconds de 0 segundos es insegura y se desaconseja rotundamente para los Pods de StatefulSet. La eliminación paulatina es segura y garantizará que el Pod se apague de manera paulatina, antes de que kubelet elimine el nombre en el apiserver.

Un Pod no se elimina automáticamente cuando un nodo no es accesible. Los Pods que se ejecutan en un Nodo inaccesible entran en el estado 'Terminating' o 'Unknown' después de un tiempo de espera. Los Pods también pueden entrar en estos estados cuando el usuario intenta la eliminación paulatina de un Pod en un nodo inaccesible. Las únicas formas en que un Pod en tal estado puede ser eliminado del apiserver son las siguientes:

  • El objeto Node es eliminado (ya sea por ti, o por el Controlador de Nodo).).
  • Kubelet, en el nodo no responsivo, comienza a responder, mata el Pod y elimina la entrada del apiserver.
  • Eliminación forzada del Pod por el usuario.

La mejor práctica recomendada es usar el primer o segundo enfoque. Si un nodo está confirmado como muerto (por ejemplo, desconectado permanentemente de la red, apagado, etc.), entonces elimina el objeto Node. Si el nodo es afectado de una partición de red, entonces trata de resolver esto o espera a que se resuelva. Cuando la partición se solucione, kubelet completará la eliminación del Pod y liberará su nombre en el apiserver.

Normalmente, el sistema completa la eliminación una vez que el Pod ya no se está ejecutando en un nodo, o el nodo es eliminado por un administrador. Puedes anular esto forzando la eliminación del Pod.

Eliminación Forzosa

Las eliminaciones forzosas no esperan confirmación de kubelet de que el Pod ha sido terminado. Independientemente de si una eliminación forzosa tiene éxito en matar un Pod, inmediatamente liberará el nombre del apiserver. Esto permitiría que el controlador de StatefulSet cree un Pod de reemplazo con esa misma identidad; esto puede llevar a la duplicación de un Pod que aún está en ejecución, y si dicho Pod todavía puede comunicarse con los otros miembros del StatefulSet, violará la semántica de como máximo uno que StatefulSet está diseñado para garantizar.

Cuando eliminas forzosamente un Pod de StatefulSet, estás afirmando que el Pod en cuestión nunca volverá a hacer contacto con otros Pods en el StatefulSet y su nombre puede ser liberado de forma segura para que se cree un reemplazo.

Si quieres eliminar un Pod de forma forzosa usando la versión de kubectl >= 1.5, haz lo siguiente:

kubectl delete pods <pod> --grace-period=0 --force

Si estás usando cualquier versión de kubectl <= 1.4, deberías omitir la opción --force y usar:

kubectl delete pods <pod> --grace-period=0

Si incluso después de estos comandos el pod está atascado en el estado Unknown, usa el siguiente comando para eliminar el Pod del clúster:

kubectl patch pod <pod> -p '{"metadata":{"finalizers":null}}'

Siempre realiza la eliminación forzosa de Pods de StatefulSet con cuidado y con pleno conocimiento de los riesgos involucrados.

Siguientes pasos

Aprende más sobre depurar un StatefulSet.

6.5 - 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

Protegiendo una aplicación con un PodDisruptionBudget

  1. Identifica la aplicación que quieres proteger con un PodDisruptionBudget (PDB).
  2. Revisa como afectan las disrupciones a tú aplicación.
  3. Crea un PDB usando un archivo YAML.
  4. 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.

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.

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.

Ejemplo de PDB usando minAvailable:

apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
  name: zk-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: zookeeper

Ejemplo de PDB usando maxUnavailable (Kubernetes 1.7 o superior):

apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
  name: zk-pdb
spec:
  maxUnavailable: 1
  selector:
    matchLabels:
      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:

kubectl get poddisruptionbudgets zk-pdb -o yaml
apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
  creationTimestamp: 2017-08-28T02:38:26Z
  generation: 1
  name: zk-pdb
...
status:
  currentHealthy: 3
  desiredHealthy: 3
  disruptedPods: null
  disruptionsAllowed: 1
  expectedPods: 3
  observedGeneration: 1

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    2               0                     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.

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 rules debe 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: RequestResponse
    resources:
    - 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: Metadata
    resources:
    - group: ""
      resources: ["pods/log", "pods/status"]

  # No registrar peticiones al configmap denominado "controller-leader"
  - level: None
    resources:
    - group: ""
      resources: ["configmaps"]
      resourceNames: ["controller-leader"]

  # No registrar peticiones de observación hechas por "system:kube-proxy" sobre puntos de acceso o servicios
  - level: None
    users: ["system:kube-proxy"]
    verbs: ["watch"]
    resources:
    - group: "" # Grupo API base
      resources: ["endpoints", "services"]

  # No registrar peticiones autenticadas a ciertas rutas URL que no son recursos.
  - level: None
    userGroups: ["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: Request
    resources:
    - group: "" # Grupo API base
      resources: ["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: Metadata
    resources:
    - group: "" # Grupo API base
      resources: ["secrets", "configmaps"]

  # Registrar todos los recursos en core y extensions al nivel Request.
  - level: Request
    resources:
    - 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/v1
kind: Policy
rules:
- 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.

Backend de Logs

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:

apiVersion: auditregistration.k8s.io/v1alpha1
kind: AuditSink
metadata:
  name: mysink
spec:
  policy:
    level: Metadata
    stages:
    - ResponseComplete
  webhook:
    throttle:
      qps: 10
      burst: 15
    clientConfig:
      url: "https://audit.app"

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:

  1. Instala fluentd, fluent-plugin-forest y fluent-plugin-rewrite-tag-filter en el nodo donde corre kube-apiserver

  2. 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
    
  3. Arranca fluentd:

    fluentd -c /etc/fluentd/config  -vv
    
  4. Arranca el componente kube-apiserver con las siguientes opciones:

    --audit-policy-file=/etc/kubernetes/audit-policy.yaml --audit-log-path=/var/log/kube-audit --audit-log-format=json
    
  5. 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.

  1. Instala logstash

  2. Crea un archivo de configuración para logstash:

    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
    
  3. Arranca logstash:

    bin/logstash -f /etc/logstash/config --path.settings /etc/logstash/
    
  4. Crea un archivo kubeconfig para el webhook del backend de auditoría de kube-apiserver:

     cat <<EOF > /etc/kubernetes/audit-webhook-kubeconfig
     apiVersion: v1
     clusters:
     - cluster:
         server: http://<ip_of_logstash>:8888
       name: logstash
     contexts:
     - context:
         cluster: logstash
         user: ""
       name: default-context
     current-context: default-context
     kind: Config
     preferences: {}
     users: []
     EOF
    
  5. Arranca kube-apiserver con las siguientes opciones:

    --audit-policy-file=/etc/kubernetes/audit-policy.yaml --audit-webhook-config-file=/etc/kubernetes/audit-webhook-kubeconfig
    
  6. 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:

Para comprobar la versión, introduzca kubectl version.

Comprobar el estado de los Init Containers

Muestra el estado de tu pod:

kubectl get pod <pod-name>

Por ejemplo, un estado de Init:1/2 indica que uno de los Init Containers se ha ejecutado satisfactoriamente:

NAME         READY     STATUS     RESTARTS   AGE
<pod-name>   0/1       Init:1/2   0          7s

Echa un vistazo a Comprender el estado de un Pod para más ejemplos de valores de estado y sus significados.

Obtener detalles acerca de los Init Containers

Para ver información detallada acerca de la ejecución de un Init Container:

kubectl describe pod <pod-name>

Por ejemplo, un Pod con dos Init Containers podría mostrar lo siguiente:

Init Containers:
  <init-container-1>:
    Container ID:    ...
    ...
    State:           Terminated
      Reason:        Completed
      Exit Code:     0
      Started:       ...
      Finished:      ...
    Ready:           True
    Restart Count:   0
    ...
  <init-container-2>:
    Container ID:    ...
    ...
    State:           Waiting
      Reason:        CrashLoopBackOff
    Last State:      Terminated
      Reason:        Error
      Exit Code:     1
      Started:       ...
      Finished:      ...
    Ready:           False
    Restart Count:   3
    ...

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

En la plataforma Google Compute Engine (GCE), por defecto da soporte a la escritura de logs haciendo uso de Stackdriver Logging, el cual se describe en detalle en Logging con Stackdriver Logging.

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.

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.

kubectl get pods --namespace=kube-system
NAME                                           READY     STATUS    RESTARTS   AGE
elasticsearch-logging-v1-78nog                 1/1       Running   0          2h
elasticsearch-logging-v1-nj2nb                 1/1       Running   0          2h
fluentd-elasticsearch-kubernetes-node-5oq0     1/1       Running   0          2h
fluentd-elasticsearch-kubernetes-node-6896     1/1       Running   0          2h
fluentd-elasticsearch-kubernetes-node-l1ds     1/1       Running   0          2h
fluentd-elasticsearch-kubernetes-node-lz9j     1/1       Running   0          2h
kibana-logging-v1-bhpo8                        1/1       Running   0          2h
kube-dns-v3-7r1l9                              3/3       Running   0          2h
monitoring-heapster-v4-yl332                   1/1       Running   1          2h
monitoring-influx-grafana-v1-o79xf             2/2       Running   0          2h

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:

Estado de Elasticsearch

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:

Kibana logs

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.

10.4 - 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í.

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.

11 - Extender la API de Kubernetes

11.1 - Usar recursos personalizados

12 - Gestionar certificados TLS

13 - Federación

13.1 - Administrar la federación de clústeres

14 - Catálogo de servicios