Tareas

• 1: Instalar herramientas
• 1.1: Instalar y Configurar kubectl en Linux
• 1.2: Herramientas incluidas
• 1.2.1: Instalar y configurar kubectl en Linux
• 1.2.2: Instalar y configurar kubectl en macOS
• 1.2.3: Instalar y configurar kubectl en Windows
• 1.2.4: ¿Que sigue?
• 1.2.5: Autocompletar bash en Linux
• 1.2.6: Autocompletar bash en macOS
• 1.2.7: Autocompletar zsh
• 1.2.8: Descripción general de kubectl-convert
• 1.2.9: verificar la instalación de kubectl
• 2: Administrar un clúster
• 2.1: Administrar un clúster con kubeadm
• 2.2: Administrar recursos de memoria, CPU y API
• 2.3: Instalar un proveedor de políticas de red
• 3: Configurar pods y contenedores
• 3.1: Configura un Pod para Usar un Volume como Almacenamiento
• 4: Administrar Objetos en Kubernetes
• 4.1: Administración declarativa de Objetos en Kubernetes usando archivos de Configuración
• 4.2: Manejo Declarativo de Objectos de Kubernetes usando Kustomize
• 5: Inyectar datos en las aplicaciones
• 6: Gestionar y ejecutar aplicaciones
• 6.1: Corre una aplicación stateless usando un Deployment
• 6.2: Escalar un StatefulSet
• 6.3: Borrar un StatefulSet
• 6.4: Eliminación Forzosa de Pods de StatefulSet
• 6.5: Especificando un presupuesto de disrupción para tu aplicación
• 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
• 10.2: Depurar Contenedores de Inicialización
• 10.3: Escribiendo Logs con Elasticsearch y Kibana
• 10.4: Pipeline de métricas de recursos
• 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

1 - Instalar herramientas

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.29 se puede comunicar con las siguientes versiones de plano de control v1.28, v1.29 y v1.30. 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
• Instalación mediante el administrador de paquetes nativo
• Instalación usando otro administrador de paquetes

Instalación del binario para Linux de kubectl con Curl

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

   • x86-64
   • ARM64

   
      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"
      

   Nota:

   Para descargar una versión específica reemplaza la siguiente parte del comando con la versión que desea instalar $(curl -L -s https://dl.k8s.io/release/stable.txt)

   Por ejemplo, para descargar la versión 1.29.2 en linux x86-64:

   curl -LO https://dl.k8s.io/release/v1.29.2/bin/linux/amd64/kubectl
   

   Y para Linux ARM64:

   curl -LO https://dl.k8s.io/release/v1.29.2/bin/linux/arm64/kubectl
   

2. Validación del binario (paso opcional)

   Descargar el archivo checksum:

   • x86-64
   • ARM64

   
      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
   

   Nota: Descarga la misma versión del binario y el checksum.

3. Instalar kubectl

   sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl
   

   Nota:

   Si no tienes acceso root en el sistema donde se busca instalar, puedes colocar el binario kubectl en el directorio ~/.local/bin:

   chmod +x kubectl
   mkdir -p ~/.local/bin
   mv ./kubectl ~/.local/bin/kubectl
   # Y después agrega el directorio ~/.local/bin a tu $PATH
   

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

• Debian-based distributions
• Red Hat-based distributions
• SUSE-based distributions

Instalación usando otro administrador de paquetes

• Snap
• Homebrew

snap install kubectl --classic
kubectl version --client

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.

• Bash
• Fish
• Zsh

source /usr/share/bash-completion/bash_completion

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

kubectl completion fish | source

source <(kubectl completion zsh)

echo 'alias k=kubectl' >>~/.zshrc
echo 'compdef __start_kubectl k' >>~/.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:

   • x86-64
   • ARM64

   
      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:

   • x86-64
   • ARM64

   
      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
   

   Nota: Descargue la misma versión del binario y del checksum.

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

• Instalar Minikube
• Consulte las guías de introducción para obtener más información sobre la creación de clústeres.
• Aprenda a iniciar y exponer su aplicación.
• Si necesita acceso a un clúster que no creó, consulte la guia de Compartir el acceso al clúster.
• Lea los documentos de referencia de kubectl

1.2 - Herramientas incluidas

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.29 puede comunicarse con v1.28, v1.29, y v1.30 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:

• Instalar el binario kubectl con curl en Linux
• Instalar usando la administración nativa de paquetes
• Instalar usando otra administración de paquetes

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"
   

   Nota:

   Para descargar una versión específica, reemplace la parte de $(curl -L -s https://dl.k8s.io/release/stable.txt) del comando con la versión específica.

   Por ejemplo, para descargar la versión 1.29.2 en Linux, escriba:

   curl -LO https://dl.k8s.io/release/v1.29.2/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
   

   Nota: Descargue la misma versión del binario y el archivo de comprobación.

3. Instalar kubectl

   sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl
   

   Nota:

   Si no tiene acceso de root en el sistema de destino, aún puede instalar kubectl en el ~/.local/bin directorio:

   chmod +x kubectl
   mkdir -p ~/.local/bin/kubectl
   mv ./kubectl ~/.local/bin/kubectl
   # y luego agregue ~/.local/bin/kubectl en el $PATH
   

4. Para asegurarse de que la versión que instaló este actualizada ejecute:

   kubectl version --client
   

Instalar usando la administración nativa de paquetes

• Debian-based distributions
• Red Hat-based distributions

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

• Snap
• Homebrew

snap install kubectl --classic
kubectl version --client

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.

• Bash
• Zsh

source /usr/share/bash-completion/bash_completion

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

source <(kubectl completion zsh)

echo 'alias k=kubectl' >>~/.zshrc
echo 'compdef __start_kubectl k' >>~/.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
   

   Nota: Descargue la misma versión del binario y el archivo de comprobación.

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

• Instalar Minikube
• Consulte las guías de introducción para obtener más información sobre la creación de clústeres.
• Aprenda a iniciar y exponer su aplicación.
• Si necesita acceso a un clúster que no creó, consulte la guia de Compartir el acceso al clúster.
• Lea los documentos de referencia de kubectl

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.29 puede comunicarse con v1.28, v1.29, y v1.30 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
• Instalar con Homebrew en macOS
• Instalar con Macports en macOS

Instalar el binario de kubectl con curl en macOS

1. Descargue la última versión:

   • Intel
   • Apple Silicon

   
      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"
      

   Nota:

   Para descargar una versión específica, reemplace el $(curl -L -s https://dl.k8s.io/release/stable.txt) parte del comando con la versión específica.

   Por ejemplo, para descargar la versión 1.29.2 en Intel macOS, escriba:

   curl -LO "https://dl.k8s.io/release/v1.29.2/bin/darwin/amd64/kubectl"
   

   Y para macOS en Apple Silicon, escriba:

   curl -LO "https://dl.k8s.io/release/v1.29.2/bin/darwin/arm64/kubectl"
   

2. Validar el binario (opcional)

   Descargue el archivo de comprobación de kubectl:

   • Intel
   • Apple Silicon

   
      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
   

   Nota: Descargue la misma versión del binario y el archivo de comprobación.

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
   

   Nota: Asegúrese de que /usr/local/bin se encuentre definida en su variable de entorno PATH.

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.

• Bash
• Zsh

echo $BASH_VERSION

brew install bash

echo $BASH_VERSION $SHELL

brew install bash-completion@2

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

source <(kubectl completion zsh)

echo 'alias k=kubectl' >>~/.zshrc
echo 'compdef __start_kubectl k' >>~/.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:

   • Intel
   • Apple Silicon

   
      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:

   • Intel
   • Apple Silicon

   
      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
   

   Nota: Descargue la misma versión del binario y el archivo de comprobación.

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
   

   Nota: Asegúrese de que /usr/local/bin se encuentre definida en su variable de entorno PATH.

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

• Instalar Minikube
• Consulte las guías de introducción para obtener más información sobre la creación de clústeres.
• Aprenda a iniciar y exponer su aplicación.
• Si necesita acceso a un clúster que no creó, consulte la guia de Compartir el acceso al clúster.
• Lea los documentos de referencia de kubectl

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.29 puede comunicarse con versiones v1.28, v1.29, y v1.30 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
• Instalar en Windows usando Chocolatey o Scoop

Instalar el binario de kubectl con curl en Windows

1. Descarga la última versión 1.29.2.

   O si tiene curl instalado, use este comando:

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

   Nota: Para conocer la última versión estable (por ejemplo, para secuencias de comandos), eche un vistazo a https://dl.k8s.io/release/stable.txt.

2. Validar el binario (opcional)

   Descargue el archivo de comprobación de kubectl:

   curl -LO https://dl.k8s.io/v1.29.2/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
   • scoop

   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.29.2/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.29.2/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

• Instalar Minikube
• Consulte las guías de introducción para obtener más información sobre la creación de clústeres.
• Aprenda a iniciar y exponer su aplicación.
• Si necesita acceso a un clúster que no creó, consulte la guia de Compartir el acceso al clúster.
• Lea los documentos de referencia de kubectl

1.2.4 - ¿Que sigue?

• Instalar Minikube
• Consulte las guías de introducción para obtener más información sobre la creación de clústeres.
• Aprenda a iniciar y exponer su aplicación.
• Si necesita acceso a un clúster que no creó, consulte la guia de Compartir el acceso al clúster.
• Lea los documentos de referencia de kubectl

1.2.5 - Autocompletar 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

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.

  Nota: La instalación de Homebrew de bash-completion v2 genera todos los archivos en el directorio BASH_COMPLETION_COMPAT_DIR, es por eso que los dos últimos métodos funcionan.

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

1.2.7 - Autocompletar 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 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

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:

• Killercoda
• Play with Kubernetes

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:

pods/storage/redis.yaml

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

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:

• Killercoda
• Play with Kubernetes

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:

• Administración de Objetos de Kubernetes usando comandos imperativos
• Administración imperativa de los Objetos de Kubernetes usando archivos de Configuración

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:

application/simple_deployment.yaml

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:

application/simple_deployment.yaml

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:

application/update_deployment.yaml

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:

application/update_deployment.yaml

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.

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:

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:

application/simple_deployment.yaml

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.

   Nota: Este paso es opcional, ya que kubectl apply no actualiza el campo status aunque este presente en el 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

• Administración de Objetos de Kubernetes usando comandos imperativos
• Administración imperativa de los Objetos de Kubernetes usando archivos de configuración
• Referencia del comando Kubectl
• Referencia de la API de Kubernetes

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:

• Killercoda
• Play with Kubernetes

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