Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 

Archivo YAML para Kubernetes

 

Junto con muchas otras muchas formas de configurar Kubernetes, YAML es el formato estándar utilizado en un archivo de configuración Kubernetes. La YAML se utiliza ampliamente, por lo que lo más probable es que ya esté familiarizado con ella. Si no es así’, no es un gran negocio, ya que YAML es un lenguaje bastante fácil de aprender. Cada línea de la configuración YAML de un conjunto Pod se detalla y debe comprender el formato YAML como un derivado del proceso de aprendizaje Pod.

El archivo de configuración Pod en formato YAML es:

YAML utiliza tres tipos de datos básicos:

  1. Scalar (cadenas o números): elemento de datos Atom, cadenas como Pod-1, número de puerto 80.

  2. Asignaciones (algoritmos hash/diccionarios): los pares clave-valor se pueden anidar. apiVersion: V1 es una asignación. la clave apiVersion tiene un valor de v1.

  3. Secuencias (matrices o listas): colección de valores ordenados, sin clave. Los elementos de la lista se indican con un signo. El valor de los contenedores de claves es una lista que incluye dos contenedores.

En este ejemplo, también está viendo YAML estructura de datos anidada:

  • Asignación de un mapa: Spec es la clave de un mapa, en la que se define’una especificación Pod s. En este ejemplo, sólo se define el comportamiento de los contenedores que se iniciarán en la caja Pod. El valor es otro mapa con la clave que se encuentra en los contenedores.

  • Asignación de una lista. Los valores de los contenedores de claves son una lista de dos elementos: contenedor de servidor y cliente, cada uno de los cuales de nuevo, son una asignación que describe el contenedor individual con unos cuantos atributos como el nombre, la imagen y los puertos que se van a exponer.

Otras características que debería conocer acerca de YAML:

  • Distingue mayúsculas de minúsculas

  • Los elementos del mismo nivel comparten la misma sangría izquierda, la cantidad de sangría no importa

  • Los caracteres de tabulación no se pueden usar como sangría

  • Las líneas en blanco no importan

  • Utilice # para comentar una línea

  • Utilice una sola comilla ' para omitir el significado especial de cualquier carácter

Antes de profundizar en más detalles sobre el archivo YAML’, deje que s finalice la creación de Pod:

Hay. Hemos creado nuestro primer objeto – Kubernetes un pod denominado Pod-1. Pero, ¿dónde están los contenedores? La salida ofrece las siguientes pistas: se ha iniciado una caja Pod-1 (nombre), que contiene dos contenedores (preparados/2), en el nodo Kubernetes Worker cent333 con una dirección IP asignada de 10.47.255.237. Los dos contenedores de la caja Pod están en funcionamiento (READY 2/) y su estado de ejecución no es 27S sin reiniciar. A’continuación se muestra un breve comentario línea por línea acerca de lo que está haciendo la configuración de YAML:

  • Línea 1: Esta es una línea de comentario que utiliza # antes del texto, puede colocar cualquier comentario en el archivo YAML (A lo largo de este libro, usamos esta primera línea para asignar un nombre al archivo YAML. El nombre de archivo se utilizará posteriormente en el comando al crear el objeto a partir del archivo YAML.)

  • Líneas 2, 3, 4, 8: Las cuatro asignaciones YAML son los componentes principales de la definición Pod:

    • ApiVersion: Hay distintas versiones, por ejemplo, V2. Aquí, específicamente, es la versión 1.

    • Redondeo Recuerde que hay distintos tipos de objetos Kubernetes, y aquí queremos que Kubernetes crear un objeto Pod. Más adelante, verá el tipo ReplicationController, o servicio, en los ejemplos de otros objetos.

    • Datos Para identificar los objetos creados. Aparte del nombre del objeto que se va a crear, otros metadatos importantes son las etiquetas. Y leerá más acerca de esto en el capítulo 3.

    • Spec Esto proporciona la especificación sobre el comportamiento del conjunto Pod.

  • Líneas 9-15: La especificación Pod se muestra aquí acerca de los dos contenedores. El sistema descarga las imágenes, inicia cada contenedor con un nombre y expone los puertos especificados, respectivamente.

Estos’son’los s que se ejecutan dentro de la caja Pod:

No es sorprendente que la Pod-1 se componga de dos contenedores declarados en el archivo YAML, el servidor y el cliente respectivamente, con una dirección IP asignada por Kubernetes clúster y compartida entre todos los contenedores, tal y como se muestra en la Figure 1:

Figure 1: Nodo, conjunto Pod y contenedores
Nodo, conjunto Pod y contenedores

Pausar contenedor

Si inicia sesión en el nodo cent333, verá’los contenedores de acoplamiento que se ejecutan dentro de la caja Pod:

El tercer contenedor con nombre de imagen k8s.gcr.io/pause es un contenedor especial creado para cada conjunto Pod por el sistema Kubernetes. El contenedor pausar se crea para administrar los recursos de red de la caja Pod, que comparten todos los contenedores de dicho conjunto Pod.

La Figure 2 muestra un conjunto Pod que incluye unos cuantos contenedores de usuario y un contenedor pausar.

Figure 2: Pod, contenedores de usuario y el contenedor especial PAUSE
Pod, contenedores de usuario y el contenedor especial PAUSE

Comunicación intra-Pod

En el patrón Kubernetes, deje’que inicie sesión en un contenedor del maestro:

Note

Si ha jugado alguna vez con Docker, se dará cuenta inmediatamente de que esto es bastante agradable. Recuerde que los contenedores se iniciaron en uno de los nodos, por lo que si utiliza Docker primero deberá iniciar sesión en el nodo remoto correcto y, a continuación, utilizar un comando similar de dockr Exec para iniciar sesión en cada contenedor. Kubernetes oculta estos detalles. Le permite hacer todo desde un nodo – al maestro.

Y ahora comprueba los procesos que se ejecutan en el contenedor:

Contenedor de servidor

El contenedor cliente

Este comando de salida de PS muestra que cada contenedor está ejecutando su propio proceso. Sin embargo, los resultados del comando SS e IP indican que ambos contenedores comparten el mismo entorno de red exacto, por lo que ambos ven el puerto expuesto entre sí. Por lo tanto, la comunicación entre los contenedores de una caja Pod puede producirse simplemente utilizando localhost. ’Para comprobarlo, inicie una conexión TCP con el comando rizo.

Supongamos que desde el contenedor cliente desea obtener una página web desde el contenedor servidor. Puede simplemente iniciar rizo con la dirección IP de localhost:

Puede ver que la conexión está establecida y que la página web se ha descargado correctamente.

A continuación’, permita que s supervise el estado de conexión TCP: la conexión se estableció correctamente:

Y se puede ver la misma conexión exacta desde el contenedor servidor:

Herramienta Kubectl

Hasta ahora’Ve el objeto creado por el comando kubectl. Este comando, al igual que el comando Docker World, es la interfaz en el mundo Kubernetes para comunicarse con el clúster o, más concretamente, Kubernetes Master, a través de Kubernetes API. Es’una herramienta versátil que ofrece opciones para completar todo tipo de tareas que necesitaría tratar con Kubernetes.

Como ejemplo rápido, suponiendo que haya habilitado la característica de finalización automática para kubectl, puede enumerar todas las opciones compatibles con su entorno actual iniciando sesión en el patrón y escribiendo kubectl, seguido de dos pulsaciones de tecla de tabulación:

Note

Para configurar la finalización automática para el comando kubectl, siga las instrucciones de la opción ayuda-finalización:

finalización de kubectl-h

Si está’seguro, disodos verá y aprende algunas de estas opciones en el resto de este manual.