Aplicar el Manifiesto YAML
En este paso, explorará el comando kubectl apply con más detalle y aprenderá diferentes formas de aplicar manifiestos de Kubernetes. Basándonos en los archivos YAML del paso anterior, demostraremos varias técnicas para aplicar manifiestos.
Primero, asegúrese de estar en el directorio correcto:
cd ~/project/k8s-manifests
Creemos un nuevo subdirectorio para organizar aún más nuestros manifiestos. Cree un directorio llamado manifests y navegue dentro de él:
mkdir -p manifests
cd manifests
Ahora, creemos un manifiesto para una aplicación web simple que incluya tanto un Deployment como un Service en un solo archivo. Cree un nuevo archivo llamado web-app.yaml usando nano:
nano web-app.yaml
Agregue el siguiente contenido a web-app.yaml:
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-app
spec:
replicas: 2
selector:
matchLabels:
app: web
template:
metadata:
labels:
app: web
spec:
containers:
- name: web
image: nginx:alpine
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: web-service
spec:
selector:
app: web
type: ClusterIP
ports:
- port: 80
targetPort: 80
Este manifiesto define dos recursos de Kubernetes en un solo archivo, separados por ---. Esta es una forma común de agrupar recursos relacionados. Analicemos lo que es nuevo:
- Múltiples Recursos en un Solo Archivo: El archivo
web-app.yaml ahora contiene dos definiciones de recursos de Kubernetes separadas: un Deployment y un Service. El separador --- se utiliza para distinguirlos.
kind: Service: Esto define un recurso de tipo Service.
spec.selector.app: web: Este Service se dirigirá a los pods que tengan la etiqueta app: web. Esto coincide con las etiquetas que establecimos para los pods creados por el Deployment web-app.spec.type: ClusterIP: Especifica el tipo de servicio como ClusterIP. Esto significa que el servicio se expondrá en una dirección IP interna dentro del clúster y se utiliza típicamente para la comunicación entre servicios dentro del clúster.spec.ports: Define cómo el servicio mapea los puertos a los pods de destino.
port: 80: El puerto en el propio Service al que accederá.targetPort: 80: El puerto en los pods de destino al que el servicio reenviará el tráfico.
Ahora, apliquemos este manifiesto utilizando diferentes métodos.
Método 1: Aplicar el archivo completo
Esta es la forma más común de aplicar un manifiesto. Use kubectl apply -f seguido del nombre del archivo:
kubectl apply -f web-app.yaml
Este comando creará tanto el Deployment como el Service definidos en web-app.yaml. Debería ver una salida como:
deployment.apps/web-app created
service/web-service created
Método 2: Aplicar desde un directorio
Puede aplicar todos los manifiestos de un directorio a la vez. Si tiene varios archivos de manifiesto en el directorio manifests, puede aplicarlos todos especificando el directorio en lugar de un archivo específico:
kubectl apply -f .
El . representa el directorio actual. kubectl buscará archivos YAML en este directorio y aplicará todos ellos. Esto es útil cuando ha organizado sus manifiestos en varios archivos dentro de un directorio.
Método 3: Aplicar desde una URL (Opcional)
kubectl apply también puede aplicar manifiestos directamente desde una URL. Esto es útil para desplegar rápidamente aplicaciones o configuraciones de ejemplo alojadas en línea. Por ejemplo, puede desplegar el despliegue maestro de Redis del repositorio de ejemplos de Kubernetes:
kubectl apply -f https://raw.githubusercontent.com/kubernetes/examples/master/guestbook/redis-master-deployment.yaml
Esto descargará el manifiesto de la URL y lo aplicará a su clúster. Nota: Tenga cuidado al aplicar manifiestos de URLs no confiables, ya que pueden modificar su clúster.
Exploremos algunas opciones adicionales para kubectl apply.
Dry Run (Simulación)
Puede usar la bandera --dry-run=client para simular la aplicación de un manifiesto sin realizar cambios reales en el clúster. Esto es útil para verificar si su manifiesto es válido y para ver qué recursos se crearían o modificarían:
kubectl apply -f web-app.yaml --dry-run=client
Este comando mostrará lo que se crearía o cambiaría, pero en realidad no aplicará los cambios a su clúster.
Salida Detallada (Verbose Output)
Para obtener una salida más detallada de kubectl apply, puede usar la bandera -v seguida de un nivel de verbosidad (por ejemplo, -v=7). Los niveles de verbosidad más altos proporcionan información más detallada, lo que puede ser útil para la depuración:
kubectl apply -f web-app.yaml -v=7
Esto imprimirá mucha más información sobre las solicitudes de API que se están realizando y el procesamiento del manifiesto.
Verifique los recursos creados al aplicar web-app.yaml. Use kubectl get deployments y kubectl get services para listar los Deployments y Services en su clúster:
## Listar despliegues
kubectl get deployments
## Listar servicios
kubectl get services
## Describir el despliegue para ver más detalles
kubectl describe deployment web-app
Ejemplo de salida para kubectl get deployments:
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deployment 3/3 3 3 3m33s
redis-master 0/1 1 0 23s
web-app 2/2 2 2 42s
Ejemplo de salida para kubectl get services:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 8m28s
web-service ClusterIP 10.106.220.33 <none> 80/TCP 46s
Observe que ahora tiene un Deployment web-app con 2/2 réplicas READY y un web-service de tipo ClusterIP.
Discutamos brevemente la diferencia entre la gestión declarativa e imperativa en Kubernetes, especialmente en el contexto de kubectl apply y kubectl create.
kubectl apply: Utiliza un enfoque declarativo. Usted define el estado deseado en sus archivos de manifiesto, y kubectl apply intenta lograr ese estado. Si ejecuta kubectl apply varias veces con el mismo manifiesto, Kubernetes solo realizará cambios si hay diferencias entre el estado deseado en el manifiesto y el estado actual en el clúster. kubectl apply es generalmente recomendado para administrar recursos de Kubernetes porque es más robusto y fácil de administrar cambios a lo largo del tiempo. Rastrea la configuración de sus recursos y permite actualizaciones incrementales.kubectl create: Utiliza un enfoque imperativo. Usted instruye directamente a Kubernetes para que cree un recurso. Si intenta ejecutar kubectl create para un recurso que ya existe, generalmente resultará en un error. kubectl create es menos flexible para administrar actualizaciones y cambios en comparación con kubectl apply.
En la mayoría de los casos, especialmente para administrar despliegues de aplicaciones, kubectl apply es el método preferido y recomendado debido a su naturaleza declarativa y mejor manejo de actualizaciones y gestión de configuración.
