Explicación de los recursos de Kubernetes – CloudSavvy IT

Tecnología abril 5, 2021

Gráfico que muestra el logotipo de Kubernetes

Kubernetes no es conocido por ser accesible. Para dominar Kubernetes, debe comprender cómo encajan sus abstracciones. Kubernetes viene con docenas de tipos de recursos que puede usar dentro de sus aplicaciones. Veamos los roles de los recursos utilizados con más frecuencia.

Vainas

Si hay un término de Kubernetes que aprender, es “Pod”. Vainas son la unidad de cálculo fundamental que utiliza Kubernetes. Albergan sus contenedores en ejecución. Por esta razón, es común comparar un pod con una instancia de un contenedor Docker.

Esta semejanza no es exacta, ya que un solo pod de Kubernetes puede tener varios contenedores ejecutándose dentro de él. Los pods se ven mejor como un “grupo” de contenedores que tienen un contexto de ejecución compartido. El entorno de la vaina está aislado; los entornos de contenedores individuales dentro están aún más sub-aislados.

Los contenedores de un pod siempre se programan en el mismo nodo de Kubernetes. Se ejecutarán en la misma máquina física y pueden compartir almacenamiento y recursos de red.

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
    - name: my-container
      image: my-image:latest

El manifiesto anterior crearía manualmente un solo Pod. El Pod ejecutaría un contenedor usando el my-image:latest imagen.

Normalmente, no administra pods directamente en Kubernetes. Los pods se crean como consecuencia de agregar otros recursos, como una implementación (ver más abajo). Debes tratar tus Pods como unidades efímeras. Kubernetes tiene control sobre el Pod y podría reprogramarlo a otro nodo si los recursos del clúster se ven limitados.

Conjuntos de réplicas

Conjuntos de réplicas (generalmente escrito como ReplicaSets, sin espacio) son otra capa de abstracción en la parte superior de Pods. Los ReplicaSets garantizan que habrá una cantidad específica de Pods idénticos ejecutándose en cualquier momento.

Cuando usa ReplicaSets, puede aplicar una cantidad mínima de Pods para su aplicación. Especifica la cantidad de pods que deben ejecutarse al mismo tiempo. Luego, Kubernetes programa suficientes pods para cumplir con la disponibilidad mínima que defina. Recuerde que cada pod puede constar de varios contenedores en ejecución, según cómo esté configurada su aplicación.

Cuando un ReplicaSet crea un Pod, Kubernetes actualiza el metadata.ownerReferences campo para incluir la identidad del ReplicaSet. Luego, ReplicaSet puede establecer los pods que controla, de modo que sepa si se ha cumplido el objetivo de disponibilidad mínima.

ReplicaSets tienen un replicas campo que define la cantidad de pods que se ejecutarán. Cambie este valor y aplique el manifiesto ReplicaSet actualizado a su clúster para que Kubernetes reprograme sus pods para que coincidan con el nuevo recuento de réplicas.

Este detalle destaca un punto importante sobre ReplicaSets: Kubernetes solo garantiza la cantidad de Pods en ejecución finalmente coincidir con el recuento de réplicas que ha especificado. Si cambia el recuento de réplicas, habrá un período de tiempo en el que se ejecutarán más o menos pods de lo que indica su manifiesto. ReplicaSet creará o eliminará Pods hasta que el número deseado esté operativo.

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: my-replicaset
  labels:
    my-label: my-value
spec:
  replicas: 3
  selector:
    matchLabels:
      my-label: my-value
  template:
    metadata:
      labels:
        my-label: my-value
    spec:
      containers:
        - name: app-container
          image: my-image:latest

El manifiesto anterior ejecutaría tres réplicas del my-image:latest imagen de contenedor utilizando un ReplicaSet. Puede cambiar el número de réplicas actualizando el valor en el manifiesto y volviéndolo a aplicar (kubectl apply -f my-manifest.yml).

Despliegues

Si bien los ReplicaSets facilitan el trabajo con Pods, rara vez se usan directamente. Despliegues son una abstracción sobre ReplicaSets. Por lo general, crea una implementación cuando agrega una nueva carga de trabajo a un clúster.

Los recursos de implementación permiten actualizaciones declarativas de pods y ReplicaSets. Le permiten realizar actualizaciones continuas de ReplicaSets, donde los pods se reprograman sin ningún tiempo de inactividad del servicio. Los Pods y ReplicaSets se reemplazan individualmente, lo que permite que las versiones antiguas y nuevas coexistan brevemente.

La necesidad de implementaciones surgió del enfoque histórico de Kubernetes para las réplicas. ReplicaSets evolucionó a partir de Controladores de replicación. Los controladores de replicación ofrecían una funcionalidad similar a los ReplicaSets pero con compatibilidad de escala incorporada.

Sin embargo, los controladores de replicación no ofrecen escalado declarativo. Tuviste que usar manualmente kubectl rolling-update para escalar las réplicas sin tiempo de inactividad. Esto estaba en desacuerdo con el enfoque declarativo basado en manifiestos de otros recursos de Kubernetes.

En comparación con ReplicaSets, la principal ventaja de las implementaciones es su soporte para actualizaciones continuas. Cambiar la cantidad de réplicas en un ReplicaSet no garantiza que ninguna cantidad de pods permanecerá en un estado determinado durante el lanzamiento. Con una implementación, puede estar seguro de que su aplicación continuará manejando el tráfico, incluso si la implementación aún no se ha completado.

Hoy, Kubernetes aconseja el uso de implementaciones para representar sus cargas de trabajo. Sus implementaciones se ejecutarán y escalarán ReplicaSets automáticamente; ReplicaSets, a su vez, administrará sus Pods. Puede realizar una actualización continua de una implementación actualizando el replicas campo en su manifiesto. Kubernetes se asegurará de que su aplicación permanezca disponible durante el cambio, lo que permitirá que los pods nuevos y antiguos coexistan temporalmente.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
  labels:
    my-label: my-value
spec:
  replicas: 3
  selector:
    matchLabels:
      my-label: my-value
  template:
    metadata:
      labels:
        my-label: my-value
    spec:
      containers:
        - name: app-container
          image: my-image:latest

El manifiesto anterior crearía una implementación que constaría de tres réplicas, cada una ejecutando el my-image:latest imagen del contenedor. Cambiando el replicas El valor desencadenaría una actualización continua de los ReplicaSets y Pods subyacentes.

Otros tipos de recursos

Los tres tipos de recursos que hemos analizado son los objetos más comunes que encontrará al trabajar con Kubernetes. Se utilizan para configurar las cargas de trabajo de su aplicación y administrar sus contenedores.

Deberá utilizar otros tipos de tipos de recursos a medida que trabaje más con Kubernetes. ConfigMaps y Misterios le permite inyectar la configuración en sus pods, lo que les permite acceder a valores externos. Volúmenes y Volúmenes persistentes proporcione a los pods un sistema de archivos de escritura compartido que se pueda usar para almacenar datos, en lugar del almacenamiento efímero predeterminado que se pierde cuando sale del pod.

Un conjunto adicional de recursos ayuda a administrar las opciones de red de su carga de trabajo. Servicios le permite exponer un conjunto de Pods como un único servicio de red con una dirección IP. Ingresses le permite exponer servicios externamente. Enrutan el tráfico a su clúster a un servicio de destino en función de atributos como el nombre de host, el puerto y la ruta URL.

Finalmente, hay meta-recursos que describen su clúster. Los espacios de nombres se utilizan para aislar cargas de trabajo individuales, evitando colisiones de nombres. Por lo general, debe crear un nuevo espacio de nombres para cada una de sus cargas de trabajo independientes. Los nodos son un tipo de recurso que representa las máquinas físicas que ejecutan sus pods. Cada nodo suele alojar varios pods. Kubernetes averigua cómo programar cargas de trabajo en función de la disponibilidad de cada nodo y las restricciones que aplica.

Puede ver la lista completa de recursos para su clúster ejecutando kubectl api-resources. Además de los recursos integrados, las cargas de trabajo pueden agregar sus propias definiciones de recursos personalizados (CRD) que le permiten crear nuevos tipos de objetos. Kubernetes proporciona automáticamente puntos finales de API para definiciones de recursos personalizadas.

Conclusión

Aprender Kubernetes significa familiarizarse con nuevas abstracciones y terminologías. Si bien esto crea un área de superficie de API amplia, cada objeto de Kubernetes tiene un propósito relativamente limitado.

A menudo, podrá ceñirse a las abstracciones de alto nivel, como las implementaciones. No debería necesitar microgestionar tipos de recursos fundamentales, como Pods, a menos que tenga requisitos complejos que no se puedan resolver solo con Implementaciones y ReplicaSets.