Tipos de Objetos en Kubernetes

En esta nueva entrada de Refactorizando, vamos a ver los principales tipos de objetos en Kubernetes y y como podemos llegar a definirlos. Si quieres ver las anteriores entradas sobre Kubernetes pulsa aquí.

¿Cómo funcionan los objetos de Kubernetes?

Los objetos de kubernetes son entidades dentro de la plataforma, que Kubernetes utiliza para poder presentar el estado del clúster. Estas entidades describen:

• Qué aplicaciones contenerizadas estamos ejecutando y qué nodo.
• Los recursos que se están consumiendo
• Las políticas de las aplicaciones, cómo restart/upgrade, tolerancia a fallos etc.

Podríamos decir que cada objeto es un «registro de intención», es decir, con cada objeto que se crea le estas diciendo a Kubernetes como debería ser la carga de trabjo del clúster, es decir, el estado deseado.

Con cada objeto, que se define, existen dos campos anidados, el spec y el status. El campo spec, describe como es el estado deseado, y el campo status va que es gestionado por el sistema de Kubernetes, es el estado actual del objeto el cual será guardado. En cualquier momento el Control Plane verifica si el estado actual coincide con el estado deseado, en el caso en el que esto no sea así se tomarán medidas.

Por ejemplo si tenemos un objeto Deployment, el cual no servirá para desplegar una aplicación en nuestro clúster, le podemos decir en el apartado Spec, que queremos tres réplicas. Si en cualquier momento hubiese un fallo en alguna de las instancias, el sistema de Kubernetes lo solucionaría instanciando una nueva.

Definiendo tipos de objetos en Kubernetes

Existen diferentes objetos de kubernetes como por ejemplo, Pods, ReplicaSets, Deployments, Namespaces, etc. Para poder definir cualquiera de estos objetos se puede realizar en JSON o en YAML, pero mejor el último que es el más utilizado. Una vez que se ha definido el fichero, será enviado al API server a través del Kubectl.

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

El anterior objeto es un objeto de tipo Deployment, a continuación vamos a ir definiendo los diferentes campos que nos encontramos:

• apiVersion: Qué versión de la API de Kubernetes vamos a usar para crear el objeto. (Campo obligatorio)
• kind: El tipo de objeto que estamos definiendo. (Campo obligatorio)
• metadata: Datos para identificar al objeto. (Campo obligatorio)
• spec: Contiene campos anidados que dependen del tipo de objeto que se defina, no será igual cuando se defina un Pod que cuando se defina un deployment.

Tipos de Objeto

Pods

Un Pod es el objeto más simple y pequeño en Kubernetes. Representa una sola instancia de la aplicación. Un Pod es una colección de uno o más contenedores, y encapsula un contenedor de una aplicación.

• Comparten la misma red de namespace. (Se podría pensar que un namespace es como un cluster virtual)
• Tienen acceso a montar el mismo almacenamiento externo
• Se planifican juntos.

Los Pods son efímeros y son usados con controladores que gestionen, la replicación, la tolerancia a fallos etc…, A continuación mostramos un ejemplo de YAML tipo Pod.

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  labels:
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.15.11
    ports:
    - containerPort: 80

A continuación vamos a definir los campos de un objeto de tipo Pod:

• apiVersion: Qué versión de la API de Kubernetes vamos a usar para crear el objeto. (Campo obligatorio)
• kind: El tipo de objeto que estamos definiendo. (Campo obligatorio)
• metadata: Datos para identificar al objeto. En este caso asigna un nombre y un label (Campo obligatorio)
• spec: Marca el principio del bloque en el que se define el estado deseado del Pod, también llamado PodSpec. (Campo obligatorio).

ReplicationControllers

No es un objeto recomendado de implementar, hoy en día la forma recomendada es con un Deployment que configura un ReplicaSet.

ReplicaSet

Utilizando un ReplicaSet, podemos escalar el número de Pods que ejecutan una imágen. El escalado se puede realizar manualmente o través de un autoescalador.

Un ReplicaSet asegura que el número establecido de réplicas se están ejecutando en cualquier momento, es decir, mantener el estado deseado.

No es necesario administrar ReplicaSets y Pods por separado, la mejor aproximación es usar Deployments y configurar la replicación.

Deployments

El objetivo de un deployment es proporcionar una manera declarativa de actualizar Pods y ReplicaSets.

Con un Deployment se describe un estado deseado y el Deployment Controller cambia el estado actual al estado deseado. Se pueden definir Deployments para crear nuevos ReplicaSets, o para eliminar Deployments existente y adoptar todos sus recursos con nuevos Deployments.

Casos de Uso para crear Deployments

• Crear un Deployment para implementar un ReplicaSet
• Definir nuevos estados de los Pods.
• Escalar un Deployment
• Limpiar viejos ReplicaSets
• Usar el estado del Deployment para saber que un despliegue no se ha realizado correctamente.
• Crear un deployment para hacer Rollback.

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

A continuación vamos a definir los campos de un objeto de tipo Deployment:

• apiVersion: Qué versión de la API de Kubernetes vamos a usar para crear el objeto. (Campo obligatorio)
• kind: El tipo de objeto que estamos definiendo, en este caso Deployment. (Campo obligatorio)
• metadata: Datos para identificar al objeto. En este caso asigna un nombre y un label (Campo obligatorio)
• spec: Marca el principio del bloque en el que se define el estado deseado del Deployment. (Campo obligatorio).
• spec.selector: Este campo indica como el Deployment encuentra el Pod para gestionar, para eso el label tiene que estar definida previamente en el Pod template.
• spec.template:
  • app:nginx : Los Pods son etiquetados con app:nginx usando el campo .metadata.labels.
  • spec: Indica que contenedor se va a ejecutar, ejecuta un contenedor y el nombre va a ser nginx.

Conclusión

En esta entrada hemos definido los principales tipos de objetos en Kubernetes, en la siguiente entrada veremos un ejemplo de Deployment, para hacer Rolling Update y Rollback.