Luego de algunos intentos y de resolver varios problemas que se nos presentaron en el camino, logramos definir un proceso claro y repetible para el firmado de las imágenes Docker, a la vez que lo implementamos exitosamente en el cliente.

Debido a la dificultad que presentó realizar esta tarea y a la falta de consistencia en la documentación encontrada decidí escribir este artículo, en el cual trato de integrar todo el conocimiento y herramientas necesarias para realizar el correcto firmado de imágenes Docker siguiendo el protocolo Docker Content Trust (DCT).

Requerimientos Iniciales

• El ordenador desde el cual se llevará a cabo el presente tutorial, debe tener instaladas y configuradas las siguientes herramientas:
  • Docker Engine (servidor): Guía de instalación
  • Notary CLI (cliente): Guía de instalación
  • Azure CLI (cliente): Guía de instalación

La Arquitectura de Docker Content Trust (DCT)

Los componentes necesarios para realizar el proceso de firmado de imágenes Docker bajo el esquema DCT son los siguientes:

Las Keys para el firmado

Para el firmado de imágenes Docker necesitaremos principalmente 3 tipos de Keys (claves). Las describimos a continuación:

• Root Key: Es la clave raíz para todo un registro de contenedores (container registry) y es la clave base sobre la cual se crean las Repository keys. En caso de perder la Root Key, es imposible recuperarla.
• Repository Key: Es una clave correspondiente a un repositorio de imágenes en particular y servirá para firmar sólo los tags pertenecientes a dicho repositorio. Es creada a partir de la Root Key por lo que de perderse ésta ya no podrán crearse nuevas Repository Keys.
• Delegation Key: Es la key correspondiente a un usuario con permisos para firmar las imágenes de un repositorio particular. Estos permisos se asignan mediante un proceso llamado delegación.

El Notary Server

Cuando se generan las firmas de las imágenes Docker, éstas no se guardan con la imagen Docker en sí sino que se almacenan en un servidor Llamado Notary Server. Hay que tener en cuentan que no todos los registros de contenedores de imágenes soportan DCT y por ende cuentan con un Notary Server habilitado.

En nuestro caso usaremos Azure Container Registry (ACR) para almacenar nuestras imágenes el cual nos permite habilitar el protocolo DCT en sus registros de contenedores. En este caso, el Notary Server es accesible por la misma URL del registro de contenedor (usando https) como en la imagen de ejemplo.

Cuando activamos el Notary Server, éste se habilita para el registro de contenedores, es decir para todos los repositorios almacenados en dicho registro. Adicionalmente, un repositorio de imágenes puede tener tags firmados y no firmados conviviendo sin problemas.

Desplegando un registro de contenedores en Azure (ACR)

Antes de todo debemos tener desplegado un registro de contenedores Docker, en nuestro caso haremos uso de Azure Container Registry (ACR) puesto que incluye el soporte de Docker Content Trust para el firmado de imágenes.

Creando el registro

Al momento de crear el registro de contenedores, le damos un nombre y seleccionamos como SKU a Premium puesto que este Tier es el que nos permitirá habilitar el servicio de Docker Content Trust:

En la siguiente página habilitamos el acceso público al registro, dejamos las demás opciones por defecto y creamos el registro:

Una vez creado el registro debemos habilitar DCT, para ello en la lista de opciones del registro (panel izquierdo) vamos a Policies ➜ Content trust, lo habilitamos seleccionando Status ➜ Enabled y guardamos (Save):

Asignando permisos para el firmado de imágenes

Adicionalmente debemos asignar permisos (rol) a nuestro usuario para que éste tenga la capacidad de firmar las imágenes almacenadas en nuestro registro.

En el panel izquierdo vamos a Access control (IAM) y en la parte inferior del panel principal, en la sección Grant access to this resource seleccionamos la opción Add role assignment:

En la lista de roles que se mostrarán buscamos el rol AcrImageSigner, lo seleccionamos y hacemos click en Next:

En la página siguiente seleccionamos +Select members y se nos mostrará a la derecha un panel en el cual buscaremos a nuestro usuario ingresando el email. Seleccionamos a nuestro usuario y ya aparecerá en la sección Members del panel principal. Seleccionamos Review + assign guardando los cambios:

Verificamos los permisos asignados regresando a la página inicial de Access control (IAM), seleccionamos la opción View my access y se nos mostrará un panel derecho con la lista de roles asignados a nuestro usuario. Revisamos que el rol AcrImageSigner se encuentre en la lista:

Con esto ya contamos con un registro de contenedores con DCT habilitado y con los permisos adecuados para realizar el firmado de imágenes.

Para el caso de los registros de contenedores que no soporten DCT, la solución viene por desplegar un Notary Server de manera independiente. El procedimiento se sale del alcance del presente artículo, pero usted puede guiarse del proyecto oficial de Notary en GitHub.

El Proceso de Firmado

Antes de todo debemos iniciar sesión en Azure y el registro de contenedores sobre el cual trabajaremos:

az login
az acr login --name johnrc.azurecr.io

Verificamos que estamos correctamente conectados ejecutando:

# az acr list -o table
NAME   RESOURCE  LOCATION SKU     LOGIN             CREATION             ADMIN
       GROUP                      SERVER            DATE                 ENABLED
------ --------- -------- ------- ----------------- -------------------- -------
johnrc rg_johnrc eastus   Premium johnrc.azurecr.io 2023-05-01T01:27:43Z False

Generando las Delegation Keys

Lo primero que tenemos que realizar es generar una Delegation Key para la firma de las imágenes. Para ello, ejecutamos:

docker trust key generate john

Se nos pedirá un password para encriptar la nueva Delegation Key generada. El comando creará un par de archivos, una clave pública y una clave privada. El archivo de clave privada se almacena siempre en la carpeta ~/.docker/trust/private, y el archivo de clave pública en la carpeta desde la cual ejecutamos el comando:

~/files # docker trust key generate john
Generating key for john...
Enter passphrase for new john key with ID 6d6ade9:
Repeat passphrase for new john key with ID 6d6ade9:
Successfully generated and loaded private key. Corresponding public key available: /root/files/john.pub

Podemos verificar la creación de la delegation key con el cliente de Notary, ejecutamos:

notary key list

# notary key list

ROLE    GUN    KEY ID           LOCATION
----    ---    -------------    --------
john           6d6ade9e896df    /root/.docker/trust/private

En caso de que ya contemos con un par de archivos de clave pública y privada que queramos reutilizar (creadas anteriormente con OpenSSL por ejemplo), podemos cargar la clave privada con el siguiente comando:

docker trust key load private.key --name john

~/files # docker trust key load private.key --name john
Loading key from "private.key"...
Enter passphrase for new john key with ID 778705c:
Repeat passphrase for new john key with ID 778705c:
Successfully imported key from private.key

Creando las reglas de Delegación

Una regla de delegación permite indicar quien puede firmar imágenes en un repositorio específico. Para ello necesitamos el nombre del usuario, el archivo de clave pública generado en el paso anterior y el repositorio sobre el cual se asignarán los permisos.

El archivo de clave pública puede estar en distintos formatos (.pub/.crt/.pem), esto depende de si generamos la delegation key con docker trust, o de si la creamos manualmente con una utilidad como OpenSSL.

docker trust signer add --key john.pub john johnrc.azurecr.io/java11-utils

En este ejemplo el nombre del usuario es john, el archivo de clave pública es john.pub y el repositorio johnrc.azurecr.io/java11-utils.

 # docker trust signer add --key john.pub john johnrc.azurecr.io/java11-utils
Adding signer "john" to johnrc.azurecr.io/java11-utils...
Initializing signed repository for johnrc.azurecr.io/java11-utils...
You are about to create a new root signing key passphrase. This passphrase
will be used to protect the most sensitive key in your signing system. Please
choose a long, complex passphrase and be careful to keep the password and the
key file itself secure and backed up. It is highly recommended that you use a
password manager to generate the passphrase and keep it safe. There will be no
way to recover this key. You can find the key in your config directory.
Enter passphrase for new root key with ID 86b2ff1:
Repeat passphrase for new root key with ID 86b2ff1:
Enter passphrase for new repository key with ID a2dbb4a:
Repeat passphrase for new repository key with ID a2dbb4a:
Successfully initialized "johnrc.azurecr.io/java11-utils"
Successfully added signer: john to johnrc.azurecr.io/java11-utils

Dado que es la primera vez que creamos una delegación en el repositorio johnrc.azurecr.io/java11-utils, DCT procede a inicializarlo y para ello se crean la Root Key y Repository Key correspondientes. Se nos pedirán passwords para encriptar la Root Key y Repository Key. Se recomienda usar passwords complejos y diferentes así como guardarlos en un lugar seguro para su uso posterior.

Verificamos las claves creadas. Podemos ver las claves raíz (root), de usuario (john) y de repositorio (targets):

# notary key list
ROLE     GUN                        KEY ID               LOCATION
----     ---                        ------               --------
root                                18d9dffb748b55280ee  /root/.docker/trust/private
john                                42e9f806d309c9c4828  /root/.docker/trust/private
targets  ...zurecr.io/java11-utils  5a9647e8d848082f4d1  /root/.docker/trust/private

La próxima vez que creemos una delegación sobre un repositorio diferente, por ejemplo johnrc.azurecr.io/python9-utils, sólo se creará una nueva Repository Key para dicho repositorio y se reutilizará la Root Key ya creada anteriormente. Vale recordar que la Root Key se crea sólo una vez y las diferentes Repository Keys se generan basadas en ella.

Firmando y subiendo una imagen Docker

Para realizar nuestra prueba de firmado, crearemos una imagen Docker de ejemplo en el repositorio johnrc.azurecr.io/java11-utils colocándole el tag signed:

# docker build -t johnrc.azurecr.io/java11-utils:signed .
[+] Building 25.1s (6/6) FINISHED
 => [internal] load build definition from Dockerfile_alpine_java11               0.0s
 => => transferring dockerfile: 269B                                             0.0s
 => [internal] load .dockerignore                                                0.0s
 => => transferring context: 2B                                                  0.0s
 => [internal] load metadata for docker.io/library/alpine:3.17.2                 1.2s
 => CACHED [1/2] FROM docker.io/library/alpine:3.17.2@sha256:ff6bdca1701f3a      0.0s
 => [2/2] RUN apk add git util-linux && apk add openjdk11                       22.8s
 => exporting to image 1.1s
 => => exporting layers 1.1s
 => => writing image sha256:1baba7d5e04a91b85fb4e4347aeb03ba456e4b36ef6bae       0.0s
 => => naming to johnrc.azurecr.io/java11-utils:signed
#
# docker images
REPOSITORY                       TAG       IMAGE ID       CREATED      SIZE
johnrc.azurecr.io/java11-utils   signed    1baba7d5e04a   3 hours ago   297MB

Ya estamos listos para firmar y subir nuestra nueva imagen Docker al registro de contenedor de Azure. En el momento de subir la imagen, la información de firmado se guardará en el Notary Server. Ejecutamos:

docker push --disable-content-trust=false johnrc.azurecr.io/java11-utils:signed

En este ejemplo habilitamos el firmado de la imagen con la opción –disable-content-trust=false e indicamos el repositorio y tag de la imagen a firmar como johnrc.azurecr.io/java11-utils:signed

# docker push --disable-content-trust=false johnrc.azurecr.io/java11-utils:signed
The push refers to repository [johnrc.azurecr.io/java11-utils]
6cb6697bc6eb: Layer already exists
7cd52847ad77: Layer already exists
signed: digest: sha256:6ed4ea21547483944b71568e53d6f7664a6ea4b3c94d8a0a8640d1d030879b0c size: 741
Signing and pushing trust metadata
Enter passphrase for john key with ID 778705c:
Successfully signed johnrc.azurecr.io/java11-utils:signed

En este ejemplo tenemos localmente 2 imágenes: la que acabamos de crear y subir firmada (tag signed) y otra ya existente (tag v1) que se subió sin la opción –disable-content-trust=false (sin firmar):

# docker images
REPOSITORY                       TAG       IMAGE ID       CREATED       SIZE
johnrc.azurecr.io/java11-utils   signed    1baba7d5e04a   3 hours ago   297MB
johnrc.azurecr.io/java11-utils   v1        8d25badcd502   3 hours ago   14.4MB

Verificando las firmas e identificando tags firmados

El hecho de que le hayamos colocado el tag signed a una imagen no quiere decir que la imagen ya esté firmada. Para verificar si una imagen está realmente firmada o no vamos a utilizar el siguiente comando:

docker trust inspect --pretty johnrc.azurecr.io/java11-utils:signed

# docker trust inspect --pretty johnrc.azurecr.io/java11-utils:signed

Signatures for johnrc.azurecr.io/java11-utils:signed

SIGNED TAG   DIGEST                                                         SIGNERS
signed       6ed4ea21547483944b71568e53d6f7664a6ea4b3c94d8a0a8640d1d03087   john

List of signers and their keys for johnrc.azurecr.io/java11-utils:signed

SIGNER    KEYS
john      778705c2e4f4

Administrative keys for johnrc.azurecr.io/java11-utils:signed

  Repository Key:  a62a0297649e16318b32853af85dd8bcbc7fb276da62fed6f5d875fbda8f
  Root Key:  4f719a5c838d9d22eccec72ed59c49935783fb2bb92ba289d5334bad14d5

Podemos ver que se indica quién firmó la imagen (john), el id de la clave de delegación utilizada (778705c2e4f4), y el Repository/Root Keys utilizados.

En caso analizemos el tag v1 con el mismo comando, veremos que el resultado es diferente:

# docker trust inspect --pretty johnrc.azurecr.io/java11-utils:v1

No signatures for johnrc.azurecr.io/java11-utils:v1

List of signers and their keys for johnrc.azurecr.io/java11-utils:v1

SIGNER    KEYS
john      42e9f806d309

Administrative keys for johnrc.azurecr.io/java11-utils:v1

  Repository Key:       5a9647e8d84808d7003b4416f29f18810da9dbbd55c62a90cbf93c02f4d1
  Root Key:     368988454a765d285cd9489aec92d0a676dc797f07d94f92096bc08d0b086

El resultado indica claramente que la imagen analizada no cuenta con firma alguna.

Otra manera de verificar los tags firmados y no firmados en un repositorio Docker pero que funciona sólo para Azure Container Registry es ejecutando el siguiente comando de Azure CLI:

az acr repository show-tags -n johnrc.azurecr.io --repository java11-utils --detail -o table

Podemos ver en la columna Name los tags almacenados en el registro y en la columna Signed si dicho tag está firmado o no:

# az acr repository show-tags -n johnrc.azurecr.io --repository java11-utils --detail -o table
CreatedTime    Digest                          LastUpdateTime       Name    Signed
-------------  ------------------------------  -------------------  ------  --------
2023-04-21T17  sha256:826dc034c5846fa3599bdec  2023-04-21T17:06:37  latest  False
2023-04-21T19  sha256:6ed4ea21547483944b71568  2023-04-21T19:25:53  signed  True

Luego de revisar la diversa documentación existente y de realizar varias pruebas de concepto, encontré que a parte del despliegue del clúster en sí, eran necesarios otros componentes que permitieran el correcto funcionamiento de una aplicación en K8s (Jenkins en este caso).

En el presente proyecto, he tratado de describir este proceso de la manera más detallada posible. Aunque puede parecer tedioso en un inicio, una vez comprendidos los conceptos replicar el procedimiento no debe tomarnos más de unos cuantos minutos.

Si bien este procedimiento ha sido desarrollado pensado en el despliegue de Jenkins, puede adaptarse fácilmente a cualquier tipo de aplicación conteinerizada, o simplemente para el despliegue correcto de un clúster Kubernetes sobre AWS.

Requerimientos Iniciales

• Una cuenta activa de Amazon AWS.
• El ordenador desde el cual se llevará a cabo el presente tutorial, debe tener instaladas y configuradas las siguientes herramientas:
  • Aws Cli: Guía de instalación.
  • eksctl: Guía de instalación.
  • kubectl: Guía de instalación.
  • helm: Guía de instalación.
• Usando git, clonar localmente el siguiente repositorio de código en GitHub Jenkins-K8s.

Arquitectura Jenkins sobre Kubernetes

A continuación se muestra la arquitectura de componentes de la aplicación Jenkins sobre un clúster de Kubernetes EKS (AWS).

En el diagrama se puede apreciar lo siguiente:

• Los recursos utilizados por Jenkins (pods, services, pvc, serviceAccount, ingress, etc. ) irán desplegados en su propio namespace, aislándolos de otros servicios / aplicaciones ya existentes en el clúster.
• El deployment de Jenkins puede implementarse en uno o más pods brindando alta disponibilidad y escalamiento horizontal.
• Los agentes Jenkins se levantan a demanda como pods y existen sólo durante el tiempo de ejecución del pipeline, luego de que éste finaliza el pod se destruye automáticamente y se liberan los recursos.
• Si en un futuro el clúster se queda sin recursos de CPU / memoria, simplemente deben agregarse más nodos Kubernetes tipo Worker al clúster.
• Los nodos tipo Worker en EKS por defecto usan el sistema operativo Amazon Linux 2.
• El servicio de Jenkins será expuesto públicamente a través de un ingress, el cual a su vez está enlazado con un Application Load Balancer (ALB). Es a través de este ALB que podremos acceder a nuestra aplicación desde Internet.

Despliegue de un Clúster Kubernetes en AWS EKS

Desplegando el clúster con eksctl

En mi experiencia, la manera más fácil para desplegar un clúster Kubernetes (EKS) en AWS es usando la herramienta eksctl.

Eksctl nos creará de manera automática las plantillas de CloudFormation que desplegarán los recursos solicitados en AWS.

Teniendo eksctl correctamente instalado y configurado, ejecutar el siguiente comando en una terminal:

eksctl create cluster --name "my-cluster" --region "us-east-1" --zones "us-east-1a,us-east-1b" --version 1.24 --node-type "t2.small" --nodes 2 --nodes-min 1 --nodes-max 2 --with-oidc --alb-ingress-access --spot

Vamos a explicar las principales opciones de la línea de comandos anterior:

• –name: El nombre que llevará el clúster, en este caso my-cluster.
• –region: La región AWS sobre la que se desplegará el clúster, nosotros usaremos us-east-1.
• –zones: Las zonas de disponibilidad (subnets) dentro de la región sobre las que funcionará el clúster. Para nuestro caso y por simplicidad sólo seleccionamos 2, pero pueden ser más.
• –version: La versión de Kubernetes a utilizar.
• –node-type: El tipo de instancia que se utilizará para desplegar los nodos. En nuestro ejemplo usaremos t2.small.
• –nodes, –nodes-min, –nodes-max: Número de nodos inicial, mínimo y máximo que tendrá el clúster
• –spot (Opcional): Desplegará las instancias EC2 como tipo spot ahorrando costos. No usar esta opción en despliegues para producción.

Al ejecutar esta línea de comando, veremos una salida como la siguiente:

14:38:34  eksctl version 0.122.0
14:38:34  using region us-east-1
14:38:34  subnets for us-east-1a - public:192.168.0.0/19 private:192.168.64.0/19
14:38:34  subnets for us-east-1b - public:192.168.32.0/19 private:192.168.96.0/19
14:38:34  nodegroup "ng-0e78de48" will use "" [AmazonLinux2/1.24]
14:38:34  using Kubernetes version 1.24
14:38:34  creating EKS cluster "my-cluster" in "us-east-1" region with managed nodes
14:38:34  will create 2 separate CloudFormation stacks for cluster itself and the initial managed nodegroup
14:38:34  if you encounter any issues, check CloudFormation console or try 'eksctl utils describe-stacks --region=us-east-1 --cluster=my-cluster'
14:38:34  Kubernetes API endpoint access will use default of {publicAccess=true, privateAccess=false} for cluster "my-cluster" in "us-east-1"
.
.
14:57:04  waiting for CloudFormation stack "eksctl-my-cluster-nodegroup-ng-0e78de48"
14:57:04  waiting for the control plane to become ready
14:57:05 [✔]  saved kubeconfig as "C:\\Users\\John\\.kube\\config"
14:57:05  no tasks
14:57:05 [✔]  all EKS cluster resources for "my-cluster" have been created
14:57:06  nodegroup "ng-0e78de48" has 2 node(s)
14:57:06  node "ip-192-168-32-202.ec2.internal" is ready
14:57:06  node "ip-192-168-5-170.ec2.internal" is ready
14:57:06  waiting for at least 1 node(s) to become ready in "ng-0e78de48"
14:57:10  kubectl command should work with "C:\\Users\\John\\.kube\\config", try 'kubectl get nodes'
14:57:10 [✔]  EKS cluster "my-cluster" in "us-east-1" region is ready

Al terminar el despliegue, vamos a la consola de AWS y verificamos que nuestro clúster EKS se haya desplegado correctamente:

Configurando la conexión al clúster Kubernetes

Para acceder a nuestro nuevo clúster, ya sea por línea de comandos eksctl o de manera gráfica usando Lens, debemos actualizar nuestro archivo local de configuración de Kubernetes (~/.kube/config) con la información correspondiente de conexión. Para ello ejecutamos el siguiente comando:

aws eks update-kubeconfig --region "us-east-1" --name "my-cluster"

Updated context arn:aws:eks:us-east-1:680655248338:cluster/my-cluster in C:\Users\John\.kube\config

En el parámetro –region colocamos la región en la cual desplegamos nuestro clúster, y en –name el nombre del mismo.

A continuación verificamos que podamos conectarnos correctamente al clúster usando kubectl:

kubectl cluster-info

Kubernetes control plane is running at https://******.gr7.us-east-1.eks.amazonaws.com
CoreDNS is running at https://******.gr7.us-east-1.eks.amazonaws.com/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

kubectl get nodes

NAME                             STATUS   ROLES    AGE    VERSION
ip-192-168-32-202.ec2.internal   Ready    <none>   113m   v1.24.7-eks-fb459a0
ip-192-168-5-170.ec2.internal    Ready    <none>   113m   v1.24.7-eks-fb459a0

Para el caso de Lens, una nueva conexión aparecerá en la lista de clústeres disponibles:

Instalación del controlador Amazon EBS CSI

Para poder aprovisionar volúmenes de almacenamiento (unidades de disco) en nuestro clúster, es necesario que instalemos un controlador de almacenamiento.

Para AWS EKS instalaremos el controlador Amazon EBS CSI (Elastic Block Store Container Storage Interface). Este driver nos permitirá crear y eliminar dinámicamente volúmenes EBS (Elastic Block Store) para ser utilizados por las aplicaciones en nuestro clúster.

Creación del rol de IAM

Primero debemos crear el rol de IAM con el cual se ejecutará el controlador EBS CSI en el clúster. Para ello, en el siguiente comando reemplazamos my-cluster por el nombre de nuestro clúster y lo ejecutamos:

eksctl create iamserviceaccount \
  --name ebs-csi-controller-sa \
  --namespace kube-system \
  --cluster my-cluster \
  --attach-policy-arn arn:aws:iam::aws:policy/service-role/AmazonEBSCSIDriverPolicy \
  --approve \
  --role-only \
  --role-name AmazonEKS_EBS_CSI_DriverRole

Verificamos que el comando termine de ejecutarse correctamente:

17:35:34  1 existing iamserviceaccount(s) (kube-system/aws-node) will be excluded
17:35:34  1 iamserviceaccount (kube-system/ebs-csi-controller-sa) was included (based on the include/exclude rules)
17:35:34  serviceaccounts that exist in Kubernetes will be excluded, use --override-existing-serviceaccounts to override
17:35:34  1 task: { create IAM role for serviceaccount "kube-system/ebs-csi-controller-sa" }
17:35:34  building iamserviceaccount stack "eksctl-my-cluster-addon-iamserviceaccount-kube-system-ebs-csi-controller-sa"
17:35:34  deploying stack "eksctl-my-cluster-addon-iamserviceaccount-kube-system-ebs-csi-controller-sa"
17:35:34  waiting for CloudFormation stack "eksctl-my-cluster-addon-iamserviceaccount-kube-system-ebs-csi-controller-sa"

Instalación del controlador usando eksctl o AWS CLI

Ahora realizaremos la instalación del controlador en sí. En el siguiente comando, reemplazamos my-cluster por el nombre de nuestro clúster y el valor de 111122223333 por nuestro identificador de cuenta de AWS:

eksctl create addon --name aws-ebs-csi-driver --cluster my-cluster --service-account-role-arn arn:aws:iam::111122223333:role/AmazonEKS_EBS_CSI_DriverRole

También podemos realizar la misma tarea usando AWS CLI:

aws eks create-addon --cluster-name my-cluster --addon-name aws-ebs-csi-driver --service-account-role-arn arn:aws:iam::111122223333:role/AmazonEKS_EBS_CSI_DriverRole

Verificamos que el driver haya terminado de instalarse correctamente:

2023-01-08 11:53:31 [ℹ]  Kubernetes version "1.24" in use by cluster "my-cluster"
2023-01-08 11:53:32 [ℹ]  using provided ServiceAccountRoleARN "arn:aws:iam::680655248338:role/AmazonEKS_EBS_CSI_DriverRole"
2023-01-08 11:53:32 [ℹ]  creating addon

Instalación de Prometheus para el monitoreo del clúster

Para el monitoreo básico del estado de nuestro clúster, instalaremos la aplicación Prometheus. Esto lo realizaremos usando el comando helm.

Primero agregamos el repositorio de charts de Prometheus y actualizamos nuestra caché local:

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts

helm repo update

Instalamos el chart de Prometheus:

helm install prometheus prometheus-community/prometheus

Una vez Prometheus esté instalado, podremos ver en los widgets de monitoreo de Lens información de uso de recursos como CPU, memoria, etc.:

Instalación del controlador AWS Load Balancer

Para poder publicar nuestros servicios en Kubernetes y así estén disponibles en Internet, es necesario contar con un controlador que mapee estos servicios con un balanceador de carga correspondiente al proveedor de cloud que estemos utilizando.

Para el caso de AWS es necesario instalar el AWS Load Balancer Controller. Este controlador nos permitirá mapear un ingress o servicio de Kubernetes a un Application Load Balancer (ALB) o Network Load Balancer (NLB), según sea el caso.

Creación de la política y rol de IAM

Primero creamos la política que utilizará el rol. Ejecutamos:

curl -o iam_policy.json https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.4.4/docs/install/iam_policy.json

aws iam create-policy --policy-name AWSLoadBalancerControllerIAMPolicy --policy-document file://iam_policy.json

Creamos el rol IAM y Service Account con el cual se ejecutará el controlador a instalar. Reemplazamos my-cluster con el nombre de nuestro clúster y el valor de 111122223333 lo reemplazamos por nuestro identificador de cuenta de AWS. Ejecutamos:

eksctl create iamserviceaccount \
  --cluster=my-cluster \
  --namespace=kube-system \
  --name=aws-load-balancer-controller \
  --role-name "AmazonEKSLoadBalancerControllerRole" \
  --attach-policy-arn=arn:aws:iam::111122223333:policy/AWSLoadBalancerControllerIAMPolicy \
  --approve

Instalación del controlador con Helm

Instalaremos el controlador usando helm. Primero agregamos el Helm chart correspondiente y actualizamos:

helm repo add eks https://aws.github.io/eks-charts

helm repo update

En el siguiente comando, reemplazamos my-cluster con el nombre de nuestro clúster, los valores 602401143452 y us-east-1 debes reemplazarlos con los valores correspondientes a tu caso según el siguiente cuadro. Ejecutamos el comando y verificamos que termine correctamente.

helm install aws-load-balancer-controller eks/aws-load-balancer-controller \
  -n kube-system \
  --set clusterName=my-cluster \
  --set serviceAccount.create=false \
  --set serviceAccount.name=aws-load-balancer-controller \
  --set image.repository=602401143452.dkr.ecr.us-east-1.amazonaws.com/amazon/aws-load-balancer-controller

Despliegue de Jenkins en Kubernetes

Ya tenemos nuestro clúster Kubernetes ejecutándose y con todos los plugins necesarios, así que ya podemos proceder a instalar Jenkins.

Si aún no lo haz hecho, clona el repositorio de código en GitHub correspondiente al presente artículo:

git clone https://github.com/jruizcampos/jenkins-k8s.git

Creando los recursos de Jenkins en Kubernetes

Ubicados en la carpeta del repositorio clonado, ejecutamos los siguientes comandos. Creamos el namespace, Service Account y volumen necesarios:

kubectl apply -f namespace.yaml

kubectl apply -f serviceAccount.yaml

kubectl apply -f volume.yaml

Creamos el deployment de Jenkins y su servicio de acceso correspondiente:

kubectl apply -f deployment.yaml

kubectl apply -f service.yaml

Configurando el Ingress y Load Balancer en AWS

Para configurar el ingress en Kubernetes, necesitamos la lista de subnets públicas configuradas en nuestro clúster EKS. Para ello, desde la consola de AWS vamos al servicio de VPC, seleccionamos Subnets y filtramos las redes por «public«. Copiamos los Subnet ID encontrados:

Editamos el archivo ingress.yaml y buscamos la sección alb.ingress.kubernetes.io/subnets, a continuación actualizamos los valores con la lista de Subnet ID‘s obtenida en el paso anterior:

  alb.ingress.kubernetes.io/subnets: subnet-0ce7fbd629a3db193,subnet-0c4b6807f56cbd85d

Procedemos a crear el ingress:

kubectl apply -f ingress.yaml

ingress.networking.k8s.io/jenkins-ingress created

Luego de unos minutos, verificamos que el load balancer correspondiente se haya creado en AWS. Vamos a la consola EC2 de AWS y seleccionamos Load Balancers. El load balancer creado debe ser del tipo application (ALB):

Comprobando el acceso a Jenkins

En el Load Balancer creado en el paso anterior verificamos su DNS name, lo copiamos y pegamos en la barra de direcciones de nuestro navegador web y accedemos:

Se nos pedirá la clave de administrador inicial generada durante el momento de la instalación. Para obtener esta clave, debemos inspeccionar los logs del pod de despliegue de Jenkins.

Primero listamos los pods ejecutándose actualmente en el namespace devops-tools:

kubectl get pods -n devops-tools

NAME                       READY   STATUS    RESTARTS   AGE
jenkins-5ddc766476-ll82g   1/1     Running   0          88m

Una vez identificado el pod, obtenemos las últimas 20 líneas de su log de ejecución:

kubectl logs jenkins-5ddc766476-ll82g --tail 20 -n devops-tools

En el fragmento de log mostrado, se puede apreciar claramente la clave generada:

*************************************************************
*************************************************************

Jenkins initial setup is required. An admin user has been created and a password generated.
Please use the following password to proceed to installation:

a14f39190fa44226af623ce9560b0d7b

This may also be found at: /var/jenkins_home/secrets/initialAdminPassword

*************************************************************
*************************************************************

Ingresamos esta clave en la página de inicio de Jenkins, instalamos la lista de plugins recomendados y creamos un usuario administrador:

Configuramos la URL de acceso a nuestra instancia e ingresamos a la consola de Jenkins:

Es por ello que una vez logré realizarlo con éxito, decidí recopilar todas la tareas y configuraciones necesarias en un proyecto Ansible, de manera que pudiera reutilizar el procedimiento cuando lo necesitase, además de quedar documentado para el futuro.

En el presente artículo trato de explicar el procedimiento de instalación de un clúster Kubernetes en Linux usando Ansible, el despliegue de aplicaciones simples, así como también el uso de comandos para verficar el correcto funcionamiento de nodos, deployments, servicios, ingress, etc. en Kubernetes.

Requerimientos Iniciales

Para la ejecución del proyecto Ansible necesitaremos como mínimo 3 hosts Linux (Ansible, Master y Worker), los cuales tendrán las siguientes funciones y características:

• Para todos los servidores podemos usar CentOS 7/8 o Rocky Linux 8.
• El servidor Ansible funcionará como controlador y debe tener Ansible y el cliente de GIT instalados:

[adminUsername@localhost ~]$ sudo yum install epel-release
[adminUsername@localhost ~]$ sudo yum install ansible
[adminUsername@localhost ~]$ sudo yum install git
[adminUsername@localhost ~]$
[adminUsername@localhost ~]$ git --version
git version 2.27.0
[adminUsername@localhost ~]$ ansible --version
ansible 2.9.25

• Para los servidores Master, Worker y NFS, el sistema operativo debe estar recién instalado, actualizado y sin paquetes ni software adicional.

• Para el presente proyecto se recomienda desplegar un sólo servidor Master y NFS. Podemos desplegar tantos servidores Worker como deseemos y los recursos nos lo permitan.

Infraestructura de Despliegue

Todas los servidores se encontrarán conectados al mismo segmento de red (en este caso 10.0.1.0/24) según la imagen:

Ya con los servidores preparados, procederemos a explicar el procedimiento de despliegue:

En el host Ansible descargaremos el proyecto Ansible con git, personalizaremos algunos archivos, configuraremos el acceso a los hosts Kubernetes (master, workers y nfs) y lanzaremos el despliegue sobre dichos servidores.

Estructura del Proyecto Ansible

El proyecto Ansible que utilizaremos se encuentra disponible en el siguiente repositorio GitHub: https://github.com/jruizcampos/kubernetes-deploy

Procedemos a clonar el repositorio:

[adminUsername@localhost ~]$ git clone https://github.com/jruizcampos/kubernetes-deploy.git
Cloning into 'kubernetes-deploy'...
remote: Enumerating objects: 730, done.
remote: Counting objects: 100% (730/730), done.
remote: Compressing objects: 100% (432/432), done.
remote: Total 730 (delta 341), reused 513 (delta 140), pack-reused 0
Receiving objects: 100% (730/730), 158.54 KiB | 418.00 KiB/s, done.
Resolving deltas: 100% (341/341), done.

Ingresamos al proyecto, carpeta ansible y revisamos su contenido:

[adminUsername@localhost ~]$ cd kubernetes-deploy/ansible/
[adminUsername@localhost ansible]$ ls -lh
total 40K
-rw-rw-r--. 1 john john 171 Nov  8 05:51 01-configuraciones-comunes.yml
-rw-rw-r--. 1 john john 150 Nov  8 05:51 02-configurando-nfs.yml
-rw-rw-r--. 1 john john 204 Nov  8 05:51 03-configuraciones-master-worker.yml
-rw-rw-r--. 1 john john 163 Nov  8 05:51 04-configurando-master.yml
-rw-rw-r--. 1 john john 166 Nov  8 05:51 05-configurando-workers.yml
-rw-rw-r--. 1 john john 155 Nov  8 05:51 06-tests-cluster.yml
-rwxrwxr-x. 1 john john 228 Nov  8 05:51 deploy.sh
-rw-rw-r--. 1 john john 173 Nov  8 05:51 despliegue-aplicacion.yml
-rw-rw-r--. 1 john john 755 Nov  8 05:51 despliegue-kubernetes.yml
drwxrwxr-x. 2 john john 141 Nov  8 05:51 group_vars
-rw-rw-r--. 1 john john 157 Nov  8 05:51 hosts
drwxrwxr-x. 9 john john 106 Nov  8 05:51 roles

De la lista, los 2 playbooks principales son despliegue-kubernetes.yml y despliegue-aplicacion.yml. Estos 2 playbooks llaman o usan todos los demás archivos del proyecto según el siguiente esquema:

El playbook despliegue-kubernetes.yml se encarga del despliegue del clúster Kubernetes en sí, y el playbook despliegue-aplicacion.yml instala de manera opcional un par de aplicaciones de ejemplo sobre el clúster ya instalado.

El script bash deploy.sh es sólo una manera cómoda de llamar a ambos playbooks de manera secuencial.

Personalizando el Proyecto

Antes de realizar el despliegue, debemos editar un par de archivos con valores acordes a nuestra infraestructura en particular.

Archivo ansible/hosts:

[all:vars]
# Usuario linux para conectarse a los hosts
ansible_user=adminUsername

# Definimos el host master y su ip
[master]
master1 ansible_host=10.0.1.21

# Definimos los hosts worker y sus ips
[workers]
worker1 ansible_host=10.0.1.51
# worker2 ansible_host=10.0.1.52
# .
# .
# .
# worker[n] ansible_host=10.0.1.n

# Definimos el host NFS y su ip
[nfs]
nfs1 ansible_host=10.0.1.21

Este archivo debemos modificarlo de acuerdo a lo siguiente:

ansible_user=adminUsername

En esta sección colocaremos en ansible_user el Usuario Linux que Ansible utilizará para conectarse a los hosts [master], [workers] y [nfs] (en este caso adminUsername). Debemos colocar el que nosotros hayamos configurado en dichos sistemas.

[master]
master1 ansible_host=10.0.1.21

En esta sección colocaremos en ansible_host la dirección ip del host master1 (en este caso 10.0.1.21).

[workers]
worker1 ansible_host=10.0.1.51
worker2 ansible_host=10.0.1.52
...

En esta sección colocaremos en ansible_host la dirección ip de los hosts worker1, worker2, etc. En este caso 10.0.1.51, 10.0.1.52, etc.

[nfs]
nfs1 ansible_host=10.0.1.21

En esta sección colocaremos en ansible_host la dirección ip del host nfs. En este caso 10.0.1.21 (estamos reutilizando el master para la función nfs).

Archivo ansible/group_vars/master.yaml

# Red de Docker configurada en el master. La obtenemos a través de los facts
docker_network: "{{ ansible_docker0.ipv4.network }}/16"

# Aquí definimos la red por defecto para los pods. Podemos cambiarla si así lo deseamos.
pod_network: "10.255.0.0/16"

# Aquí definimos que tipo de SDN queremos desplegar Calico o Flannel
sdn: flannel
# sdn: calico

En este archivo modificaremos parámetros relacionados a la instalación de Kubernetes de acuerdo a lo siguiente:

pod_network: "10.255.0.0/16"

En esta sección colocaremos en pod_network el segmento de red de los pods en formato CIDR. Este valor por lo general no se cambia y se usa el que está por defecto: 10.255.0.0/16

sdn: calico

En esta sección colocaremos en sdn el tipo de SDN a utilizar en la instalación de Kubernetes: calico o flannel (en minúsculas).

La elección de Calico o Flannel depende de la infraestructura subyacente sobre la cual estamos instalando Kubernetes:

1. Si estamos realizando una instalación on-premise (bare-metal) se recomienda usar Calico puesto que es más completo y personalizable (aunque Flannel también funcionará).
2. Si estamos realizando una instalación sobre máquinas virtuales desplegadas en un proveedor de cloud como Azure, debemos usar Flannel puesto que los proveedores de cloud por defecto bloquean a nivel de red ciertos puertos y protocolos necesarios para el correcto funcionamiento de Calico.

Configurando los permisos de Ansible

Configurando el acceso directo por SSH a los hosts

Antes de proceder con el despliegue, debemos configurar el acceso por SSH desde el host Ansible hacia los hosts master y workers sin necesidad de ingresar usuario y contraseña.

Para ello, en nuestro host Ansible debemos contar con las llaves (keys) SSH privada y pública de nuestro usuario Linux. En caso no se encuentren creadas, podemos hacerlo con el comando ssh-keygen:

[adminUsername@localhost ~]$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/adminUsername/.ssh/id_rsa):
Created directory '/home/adminUsername/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/adminUsername/.ssh/id_rsa.
Your public key has been saved in /home/adminUsername/.ssh/id_rsa.pub.

Ahora procederemos a copiar nuestra llave pública a los hosts master y worker:

[localhost ~]$ ssh-copy-id -i ~/.ssh/id_rsa.pub adminUsername@10.0.1.21
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/adminUsername/.ssh/id_rsa.pub"
The authenticity of host '10.0.1.21 (10.0.1.21)' can't be established.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
adminUsername@10.0.1.21's password:

Number of key(s) added: 1

[localhost ~]$ ssh-copy-id -i ~/.ssh/id_rsa.pub adminUsername@10.0.1.51
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/adminUsername/.ssh/id_rsa.pub"
The authenticity of host '10.0.1.51 (10.0.1.51)' can't be established.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
adminUsername@10.0.1.51's password:

Number of key(s) added: 1

De esta manera, ya podemos iniciar sesión en dichos servidores sin necesidad de usar usuario y clave. Podemos verificarlo con los comandos a continuación:

[adminUsername@localhost ~]$ ssh adminUsername@10.0.1.21
[adminUsername@localhost ~]$
[adminUsername@localhost ~]$ ssh adminUsername@10.0.1.51
[adminUsername@localhost ~]$

Configurando visudo en los hosts Kubernetes

Adicionalmente, debemos habilitar en los hosts master, workers y nfs que el usuario Linux pueda escalar privilegios mediante sudo pero sin solicitar la contraseña.

Para ello, en cada servidor ejecutamos el comando visudo como root:

[adminUsername@localhost ~]$ sudo visudo

Agregamos la siguiente línea al final del archivo y guardamos:

## Same thing without a password
adminUsername    ALL=(ALL)       NOPASSWD: ALL

Ahora si probamos escalar privilegios como superusuario (root), veremos que ya no se nos pide la contraseña:

[adminUsername@localhost ~]$ sudo su
[root@localhost adminUsername]#

Despliegue del Clúster Kubernetes

Ya estamos listos para realizar el despliegue de nuestro clúster Kubernetes.

Instalando Kubernetes

Ingresamos a la carpeta kubernetes-deploy/ansible y ejecutamos lo siguiente:

[localhost ansible]$ ansible-playbook -i hosts despliegue-kubernetes.yml

Mientras se ejecuta el playbook, se mostrarán una a una las tareas que se van realizando sobre los hosts. A continuación un resumen:

PLAY [Realizando configuraciones comunes a todos los nodos] ***********************

TASK [Gathering Facts] ************************************************************
ok: [master1]
ok: [nfs1]
ok: [worker1]

TASK [common : Configuramos el hostname] ******************************************
skipping: [nfs1]
changed: [worker1]
changed: [master1]

TASK [common : Actualizando los paquetes del Sistema] *****************************
changed: [worker1]
changed: [master1]
changed: [nfs1]

TASK [master_workers : Instalamos Docker] *****************************************
changed: [worker1]
changed: [master1]

TASK [master_workers : Instalamos Kubernetes] *************************************
changed: [master1]
changed: [worker1]

TASK [master : debug] *************************************************************
ok: [master1] => {
    "msg": "Se ejecutara: kubeadm init --apiserver-advertise-address 10.0.1.21 --pod-network-cidr 10.255.0.0/16"
}

TASK [master : Mostrando la salida de la ejecución del kubeadm init] **************
ok: [master1] => {
    "msg": [
        "[init] Using Kubernetes version: v1.22.3",
        "[preflight] Running pre-flight checks",
        "[preflight] Pulling images required for setting up a Kubernetes cluster",
        "Your Kubernetes control-plane has initialized successfully!",
        "You should now deploy a pod network to the cluster.",
        "Run \"kubectl apply -f [podnetwork].yaml\" with one of the options listed at:",
        "  https://kubernetes.io/docs/concepts/cluster-administration/addons/",
        "",
        "Then you can join any number of worker nodes by running the following on each as root:",
        "",
        "kubeadm join 10.0.1.21:6443 --token xxxxxx.xxxxxxxxxxxxxxxx \\",
        "\t--discovery-token-ca-cert-hash sha256:fffffffffffffffffffffffffffffffffffffffffffffffffffffffffff "
    ]
}

TASK [master : Extrayendo el hash CRT CA del Master] ******************************
changed: [master1]

TASK [master : Extrayendo el token del Master en formato JSON] ********************
changed: [master1]

TASK [master : Instalamos el operador de Tigera] **********************************
changed: [master1]

TASK [master : Instalamos la SDN Calico] ******************************************
changed: [master1]

TASK [master : Mostramos el resultado de la instalación de la SDN Calico] *********
ok: [master1] => {
    "msg": [
        "installation.operator.tigera.io/default created"
    ]
}

TASK [master : Desplegando el Nginx Ingress Controller] ***************************
changed: [master1]

TASK [master : Mostramos el resultado de la instalación Nginx Ingress Controller] * 
ok: [master1] => {
    "msg": [
        "namespace/ingress-nginx created",
        "serviceaccount/ingress-nginx created",
        "configmap/ingress-nginx-controller created",
        "clusterrole.rbac.authorization.k8s.io/ingress-nginx created",
        "clusterrolebinding.rbac.authorization.k8s.io/ingress-nginx created",
        "role.rbac.authorization.k8s.io/ingress-nginx created",
        "rolebinding.rbac.authorization.k8s.io/ingress-nginx created",
        "service/ingress-nginx-controller-admission created",
        "service/ingress-nginx-controller created",
        "deployment.apps/ingress-nginx-controller created",
        "ingressclass.networking.k8s.io/nginx created",
        "serviceaccount/ingress-nginx-admission created",
        "role.rbac.authorization.k8s.io/ingress-nginx-admission created",
        "job.batch/ingress-nginx-admission-create created",
        "job.batch/ingress-nginx-admission-patch created"
    ]
}

PLAY [Realizando configuraciones en los Workers] **********************************

TASK [workers : debug] ************************************************************
ok: [worker1] => {
    "msg": "La IP del master es: 10.0.1.21"
}

TASK [workers : Habilitamos los puertos para unirse al clúster 10250] *************
changed: [worker1]

TASK [workers : Habilitamos los puertos para unirse al clúster 30000 32767] *******
changed: [worker1]

TASK [workers : Unimos el Worker al clúster Kubernetes] ***************************
changed: [worker1]

TASK [workers : Resultado de la unión del Worker al clúster] **********************
ok: [worker1] => {
    "msg": [
        "[preflight] Running pre-flight checks",
        "[preflight] Reading configuration from the cluster...",
        "[kubelet-start] Writing kubelet configuration to file \"/var/lib/kubelet/config.yaml\"",
        "[kubelet-start] Writing kubelet environment file with flags to file \"/var/lib/kubelet/kubeadm-flags.env\"",
        "[kubelet-start] Starting the kubelet",
        "[kubelet-start] Waiting for the kubelet to perform the TLS Bootstrap...",
        "This node has joined the cluster:",
        "* Certificate signing request was sent to apiserver and a response was received.",
        "* The Kubelet was informed of the new secure connection details.",
        "Run 'kubectl get nodes' on the control-plane to see this node join the cluster."
    ]
}

TASK [tests : Mostrando información del Cluster recién desplegado] ****************
ok: [master1] => {
    "msg": "\"--> SE CULMINÓ EL DESPLIEGUE DEL CLÚSTER DE KUBERNETES\"\n\"['\\x1b[0;32mKubernetes control plane\\x1b[0m is running at \\x1b[0;33mhttps://10.0.1.21:6443\\x1b[0m', '\\x1b[0;32mCoreDNS\\x1b[0m is running at \\x1b[0;33mhttps://10.0.1.21:6443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy\\x1b[0m', '', \"To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.\"]\"\n"
}

TASK [tests : Ejecutando kubectl get svc] *****************************************
changed: [master1]

TASK [tests : Mostramos el resultado de kubectl get svc] **************************
ok: [master1] => {
"msg": [
"NAMESPACE    NAME    TYPE    CLUSTER-IP    EXTERNAL-IP    PORT(S)    AGE",
"default    kubernetes    ClusterIP 10.96.0.1    <none>    443/TCP    45s",
"ingress-nginx  ingress-nginx-controller  NodePort  10.97.92.38  <none>  80:30614/TCP,443:31329/TCP  32s",
"ingress-nginx  ingress-nginx-controller-admission  ClusterIP  10.101.84.254  <none>  443/TCP  32s",
"kube-system  kube-dns  ClusterIP  10.96.0.10  <none>  53/UDP,53/TCP,9153/TCP  42s"
    ]
}

Al finalizar la ejecución del playbook, podemos verificar si todas las tareas terminaron correctamente o si algunas fallaron:

PLAY RECAP ************************************************************************
master1: ok=71 changed=50 unreachable=0  failed=0  skipped=2  rescued=0  ignored=0
nfs1   : ok=2  changed=2  unreachable=0  failed=0  skipped=1  rescued=0  ignored=0
worker1: ok=39 changed=28 unreachable=0  failed=0  skipped=0  rescued=0  ignored=0

Instalando las Aplicaciones de ejemplo

Con el clúster Kubernetes ya instalado, podemos proceder a instalar las aplicaciones de ejemplo. Para ello ejecutamos:

[localhost ansible]$ ansible-playbook -i hosts despliegue-aplicacion.yml

Al igual que con el playbook anterior, se mostrarán una a una las tareas que se van realizando sobre el host Kubernetes master:

PLAY [Realizando el Despliegue de la aplicación sobre Kubernetes] *****************

TASK [Gathering Facts] ************************************************************
ok: [master1]

TASK [app : Copiando los archivos de las Aplicaciones] ****************************
changed: [master1] => (item=mongodb-secret.yaml)
changed: [master1] => (item=mongodb-cm.yaml)
changed: [master1] => (item=mongodb.yaml)
changed: [master1] => (item=mongo-express.yaml)
changed: [master1] => (item=ajedrez-app.yaml)
changed: [master1] => (item=myingress.yaml)

TASK [app : Desplegando las Aplicaciones] *****************************************
changed: [master1] => (item=mongodb-secret.yaml)
changed: [master1] => (item=mongodb-cm.yaml)
changed: [master1] => (item=mongodb.yaml)
changed: [master1] => (item=mongo-express.yaml)
changed: [master1] => (item=ajedrez-app.yaml)
changed: [master1] => (item=myingress.yaml)

TASK [app : Mostramos el resultado del despliegue de las Aplicaciones] ************
ok: [master1] => (item={'cmd': 'kubectl apply -f /root/mongodb-secret.yaml', 'stdout': 'secret/mongodb-secret created', 'stderr': '', 'rc': 0, 'start': '2021-11-10 16:21:33.595560', 'end': '2021-11-10 16:21:33.895110', 'delta': '0:00:00.299550', 'changed': True, 'invocation': {'module_args': {'_raw_params': 'kubectl apply -f /root/mongodb-secret.yaml', '_uses_shell': True, 'warn': True, 'stdin_add_newline': True, 'strip_empty_ends': True, 'argv': None, 'chdir': None, 'executable': None, 'creates': None, 'removes': None, 'stdin': None}}, 'stdout_lines': ['secret/mongodb-secret created'], 'stderr_lines': [], 'failed': False, 'item': 'mongodb-secret.yaml', 'ansible_loop_var': 'item'}) => {
    "msg": [
        "secret/mongodb-secret created"
    ]
}

ok: [master1] => (item={'cmd': 'kubectl apply -f /root/mongodb-cm.yaml', 'stdout': 'configmap/mongodb-configmap created', 'stderr': '', 'rc': 0, 'start': '2021-11-10 16:21:34.264286', 'end': '2021-11-10 16:21:34.618406', 'delta': '0:00:00.354120', 'changed': True, 'invocation': {'module_args': {'_raw_params': 'kubectl apply -f /root/mongodb-cm.yaml', '_uses_shell': True, 'warn': True, 'stdin_add_newline': True, 'strip_empty_ends': True, 'argv': None, 'chdir': None, 'executable': None, 'creates': None, 'removes': None, 'stdin': None}}, 'stdout_lines': ['configmap/mongodb-configmap created'], 'stderr_lines': [], 'failed': False, 'item': 'mongodb-cm.yaml', 'ansible_loop_var': 'item'}) => {
    "msg": [
        "configmap/mongodb-configmap created"
    ]
}

ok: [master1] => (item={'cmd': 'kubectl apply -f /root/mongodb.yaml', 'stdout': 'deployment.apps/mongodb-deployment created\nservice/mongodb-service created', 'stderr': '', 'rc': 0, 'start': '2021-11-10 16:21:34.943632', 'end': '2021-11-10 16:21:35.427144', 'delta': '0:00:00.483512', 'changed': True, 'invocation': {'module_args': {'_raw_params': 'kubectl apply -f /root/mongodb.yaml', '_uses_shell': True, 'warn': True, 'stdin_add_newline': True, 'strip_empty_ends': True, 'argv': None, 'chdir': None, 'executable': None, 'creates': None, 'removes': None, 'stdin': None}}, 'stdout_lines': ['deployment.apps/mongodb-deployment created', 'service/mongodb-service created'], 'stderr_lines': [], 'failed': False, 'item': 'mongodb.yaml', 'ansible_loop_var': 'item'}) => {
    "msg": [
        "deployment.apps/mongodb-deployment created",
        "service/mongodb-service created"
    ]
}

ok: [master1] => (item={'cmd': 'kubectl apply -f /root/mongo-express.yaml', 'stdout': 'deployment.apps/mongo-express created\nservice/mongo-ex-service created', 'stderr': '', 'rc': 0, 'start': '2021-11-10 16:21:37.110115', 'end': '2021-11-10 16:21:40.956915', 'delta': '0:00:03.846800', 'changed': True, 'invocation': {'module_args': {'_raw_params': 'kubectl apply -f /root/mongo-express.yaml', '_uses_shell': True, 'warn': True, 'stdin_add_newline': True, 'strip_empty_ends': True, 'argv': None, 'chdir': None, 'executable': None, 'creates': None, 'removes': None, 'stdin': None}}, 'stdout_lines': ['deployment.apps/mongo-express created', 'service/mongo-ex-service created'], 'stderr_lines': [], 'failed': False, 'item': 'mongo-express.yaml', 'ansible_loop_var': 'item'}) => {
    "msg": [
        "deployment.apps/mongo-express created",
        "service/mongo-ex-service created"
    ]
}

ok: [master1] => (item={'cmd': 'kubectl apply -f /root/ajedrez-app.yaml', 'stdout': 'deployment.apps/ajedrez-app created\nservice/ajedrez-app-service created', 'stderr': '', 'rc': 0, 'start': '2021-11-10 16:21:42.890756', 'end': '2021-11-10 16:21:44.295909', 'delta': '0:00:01.405153', 'changed': True, 'invocation': {'module_args': {'_raw_params': 'kubectl apply -f /root/ajedrez-app.yaml', '_uses_shell': True, 'warn': True, 'stdin_add_newline': True, 'strip_empty_ends': True, 'argv': None, 'chdir': None, 'executable': None, 'creates': None, 'removes': None, 'stdin': None}}, 'stdout_lines': ['deployment.apps/ajedrez-app created', 'service/ajedrez-app-service created'], 'stderr_lines': [], 'failed': False, 'item': 'ajedrez-app.yaml', 'ansible_loop_var': 'item'}) => {
    "msg": [
        "deployment.apps/ajedrez-app created",
        "service/ajedrez-app-service created"
    ]
}

ok: [master1] => (item={'cmd': 'kubectl apply -f /root/myingress.yaml', 'stdout': 'ingress.networking.k8s.io/myingress created', 'stderr': '', 'rc': 0, 'start': '2021-11-10 16:21:46.202769', 'end': '2021-11-10 16:21:49.322063', 'delta': '0:00:03.119294', 'changed': True, 'invocation': {'module_args': {'_raw_params': 'kubectl apply -f /root/myingress.yaml', '_uses_shell': True, 'warn': True, 'stdin_add_newline': True, 'strip_empty_ends': True, 'argv': None, 'chdir': None, 'executable': None, 'creates': None, 'removes': None, 'stdin': None}}, 'stdout_lines': ['ingress.networking.k8s.io/myingress created'], 'stderr_lines': [], 'failed': False, 'item': 'myingress.yaml', 'ansible_loop_var': 'item'}) => {
    "msg": [
        "ingress.networking.k8s.io/myingress created"
    ]
}

Terminada la ejecución del playbook, podemos verificar si todas las tareas terminaron satisfactoriamente o si alguna falló:

PLAY RECAP ***********************************************************************
master1: ok=6  changed=3  unreachable=0  failed=0  skipped=0  rescued=0  ignored=0

Pruebas de estado y acceso a las Aplicaciones

En esta sección verificaremos el estado del clúster Kubernetes que acabamos de instalar y el acceso a las aplicaciones de prueba.

Verificando el estado del Clúster Kubernetes

Nos conectamos al nodo master y como usuario root ejecutamos el comando kubectl cluster-info. La salida nos muestra información del clúster Kubernetes recién instalado como la URL del Control Plane y del CoreDNS:

[root@master1 ~]# kubectl cluster-info
Kubernetes control plane is running at https://10.0.1.21:6443
CoreDNS is running at https://10.0.1.21:6443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

Ahora ejecutaremos kubectl get nodes -o wide. Este comando nos mostrará la lista de nodos que forman parte del clúster, su estado y dirección IP:

[root@master1 ~]# kubectl get nodes -o wide
NAME                     STATUS  ROLES                 AGE  VERSION  INTERNAL-IP
master1.jruizcampos.com  Ready   control-plane,master  57m  v1.22.3  10.0.1.21
worker1.jruizcampos.com  Ready   <none>                57m  v1.22.3  10.0.1.51

Ejecutamos kubectl get deployments -o wide y kubectl get pods -o wide. Con estos comandos verificamos si las aplicaciones de prueba que desplegamos se llegaron a inicializar de manera correcta:

[root@master1 ~]# kubectl get deployments -o wide
NAME                READY  UP-TO-DATE  AVAILABLE  AGE  CONTAINERS     IMAGES
ajedrez-app         1/1    1           1          34m  ajedrez-app    chess
mongo-express       1/1    1           1          34m  mongo-express  mongo-express
mongodb-deployment  1/1    1           1          34m  mongodb        mongo

[root@master1 ~]# kubectl get pods -o wide
NAME                                READY  STATUS   RESTARTS  AGE  IP
ajedrez-app-8459955f76-699sm        1/1    Running  0         26m  10.255.78.76
mongo-express-78fcf796b8-dgbhl      1/1    Running  0         26m  10.255.78.75
mongodb-deployment-8f6675bc5-fc9gn  1/1    Running  0         26m  10.255.78.74

En los resultados mostrados se verifica que todos los despliegues de aplicación se realizaron correctamente y están listos (READY 1/1).

Acceso a las aplicaciones directamente en los Nodos

Las aplicaciones de prueba desplegadas son 2: Un juego de ajedrez web basado en PHP y una base de datos mongodb con su gestor web mongo-express.

El acceso a estas aplicaciones es a través de servicios configurados en Kubernetes como tipo NodePort. Para ver el estado de los servicios ejcutamos kubectl get svc:

[root@master1 ~]# kubectl get svc
NAME                TYPE        CLUSTER-IP      EXTERNAL-IP  PORT(S)         AGE
ajedrez-app-service NodePort    10.96.76.52     <none>       8082:31236/TCP  57m
kubernetes          ClusterIP   10.96.0.1       <none>       443/TCP         62m
mongo-ex-service    NodePort    10.106.141.185  <none>       8081:32622/TCP  57m
mongodb-service     ClusterIP   10.103.213.238  <none>       27017/TCP       57m

Al ser de tipo NodePort, para acceder a un servicio en particular debemos ingresar a la dirección ip de cualquier nodo del clúster y en el puerto devuelto por el comando anterior (resaltado en naranja).

Por ejemplo para acceder a la aplicación de ajedrez en el nodo master: http://10.0.1.21:31236

Accediendo al ajedrez en el nodo worker: http://10.0.1.51:31236

Ahora accederemos a la segunda aplicación, el gestor web mongo-express a través del nodo master http://10.0.1.21:32622 :

Acceso a las aplicaciones usando un Ingress Controller

La otra forma de publicar una aplicación Kubernetes es usando un Ingress Controller. En este caso, al momento de realizar el despliegue de Kubernetes se instaló el ingress controller de Nginx. Podemos verificarlo ejecutando kubectl get svc -n ingress-nginx :

[root@master1 ~]# kubectl get svc -n ingress-nginx
NAME                      TYPE     CLUSTER-IP    EXTERNAL-IP  PORT(S)
ingress-nginx-controller  NodePort 10.107.49.177 <none>  80:30575/TCP,443:32507/TCP
ingress-nginx-controller-admission  ClusterIP 10.104.4.66 <none>  443/TCP

En el resultado mostrado podemos ver que el ingress controller escucha en el puerto 30575 para http y 32507 para https. Estos valores nos servirán más adelante.

Como ya contamos con un servicio de ingress controller instalado en el clúster, nos queda desplegar la configuración de ingress específica para la publicación de nuestros servicios.

Cuando realizamos el despliegue de las aplicaciones con el archivo despliegue-aplicacion.yml, se desplegó también la configuración de ingress especificada en myingress.yaml. Podemos verificarlo ejecutando kubectl get ingress:

[root@master1 ~]# kubectl get ingress
NAME        CLASS    HOSTS             ADDRESS     PORTS   AGE
myingress   <none>   jruizcampos.com   10.0.1.51   80      3h35m

Podemos revisar más a detalle esta configuración con el comando kubectl describe ingress myingress:

[root@master1 ~]# kubectl describe ingress myingress
Name:             myingress
Namespace:        default
Address:          10.0.1.51
Default backend:  default-http-backend:80 (<error: endpoints "default-http-backend" not found>)
Rules:
  Host             Path  Backends
  ----             ----  --------
  jruizcampos.com
                   /mongodb   mongo-ex-service:8081 (10.255.1.6:8081)
                   /ajedrez   ajedrez-app-service:8082 (10.255.1.7:80)
Annotations:       kubernetes.io/ingress.class: nginx
                   nginx.ingress.kubernetes.io/add-base-url: true
                   nginx.ingress.kubernetes.io/rewrite-target: /
Events:
  Type    Reason  Age                  From                      Message
  ----    ------  ----                 ----                      -------
  Normal  Sync    42s (x3 over 3h35m)  nginx-ingress-controller  Scheduled for sync

La configuración nos indica que podemos acceder a la aplicación ajedrez usando el dominio jruizcampos.com y la ruta /ajedrez.

Adicionalmente debemos agregar a la URL de acceso el número de puerto en el que escucha el Ingress Controller, que como vimos al inicio de la sección es 30575 (http) por lo que nuestra URL quedaría así: http://jruizcampos.com:30575/ajedrez

Para que el acceso por dominio funcione, debemos tener previamente configurado en nuestro DNS que el dominio (en este caso jruizcampos.com) apunte a la dirección ip del nodo master (en este caso 10.0.1.21).

En mi caso y al ser una instalación de prueba, he realizado la configuración DNS agregando la siguiente línea al final del archivo hosts de mi equipo:

10.0.1.21 jruizcampos.com

Bueno, este artículo ha quedado más extenso de lo previsto. Espero les haya sido de utilidad. Nos vemos pronto!