Ediciones ENI Editorial | líder en informática
Alojar una aplicación en clúster
Objetivos del capítulo y requisitos previos
Este capítulo abordará una necesidad específica para el funcionamiento de Kubernetes: alojar un grupo de pods que funcionan en clúster. Este tipo de alojamiento se encuentra a menudo cuando se implementa una base de datos o un conjunto de máquinas que funcionan en clúster, para proporcionar una alta disponibilidad.
Se discutirá la gestión de la persistencia de datos, ya que difiere ligeramente del mecanismo tratado anteriormente.
La sincronización de datos entre pods se tratará en el próximo capítulo.
Desplegar una base de datos MariaDB
1. Origen de la necesidad
Lanzar una base de datos en Kubernetes no es en sí una dificultad: en el mercado existen imágenes para la mayoría de las bases de datos de código abierto.
La principal dificultad vendrá derivada de dos aspectos:
-
La persistencia de los datos.
-
La implementación de la resiliencia.
Posteriormente, el ejercicio consistirá en desplegar una base de datos de tipo MariaDB y configurar la replicación.
2. Despliegue
a. Elegir la imagen Docker
En el sitio de Docker Hub (https://hub.docker.com), la base de datos está disponible en la imagen oficial de mariadb (https://hub.docker.com/_/mariadb).
Se realizará una primera instalación para familiarizarse con esta última.
b. Versión inicial del archivo de despliegue
Como se vio anteriormente, kubectl permite crear un borrador de archivo de despliegue.
Para hacer esto, debe pasar las siguientes opciones:
-
El verbo create, seguido del tipo (deployment).
-
Un nombre para el despliegue (mariadb).
-
La opción image, seguida del nombre de la imagen que se ha de utilizar (mariadb).
-
La opción --dry-run para no crear directamente el despliegue.
-
La opción --output yaml para obtener el resultado en formato YAMLL
Redirija el resultado del comando al archivo mariadb-deployment.yaml.
A continuación, se muestra el comando correspondiente:
$ kubectl create deployment mariadb \
--image=mariadb --dry-run \
--output yaml > mariadb-deployment.yaml c. Gestión de la reentrada
Para gestionar la reentrada, se eliminarán los campos innecesarios (vacíos, nulos o con valor por defecto).
A continuación, se muestra la lista de los campos que hay que eliminar:
-
metadata --> creationTimestamp
-
spec --> replicas
-
spec --> strategy
-
spec --> template --> metadata --> creationTimestamp
-
spec --> template --> spec --> containers --> resources
-
status
He aquí el contenido del archivo mariadb-deployment.yaml después de estas modificaciones:
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: mariadb
name: mariadb
spec:
selector:
matchLabels:
app:...Implantar un StatefulSet
1. Aumentar el número de pods asociados al despliegue
En informática, aumentar el número de ejecuciones de una misma aplicación, permite dar respuesta a dos tipos de problemas:
-
Aumento de la resiliencia de un sistema.
-
Aumento de la capacidad de procesamiento de un sistema.
Kubernetes ofrece un mecanismo que permite escalar automáticamente los despliegues.
Para cambiar la cantidad de pods asociados con un despliegue, puede utilizar el comando kubectl, seguido de estas opciones:
-
El verbo scale.
-
El tipo de objeto que hay que modificar (deployment).
-
El nombre del objeto que hay que modificar (mariadb).
-
El número de réplicas que se desea (--replicas=2).
Para pasar de 1 a 2 pods, la operación se podría hacer con el siguiente comando:
$ kubectl scale deployment mariadb --replicas=2 Consulte el estado de los pods de mariadb:
$ kubectl get pods -l app=mariadb --watch A continuación, se muestran las primeras líneas devueltas por este comando:
NAME READY STATUS RESTARTS AGE
mariadb-6c758c6984-4pnjw 0/1 ContainerCreating 0 1s
mariadb-6c758c6984-czsbw 1/1 Running 0 3m Después de unos segundos, debería aparecer la siguiente línea:
mariadb-6c758c6984-4pnjw 0/1 Running 0 4s Aproximadamente después de 1 minuto, deberían aparecer las siguientes líneas (una nueva cada minuto):
mariadb-6c758c6984-4pnjw 0/1 Running 1 65s
mariadb-6c758c6984-4pnjw 0/1 Running 2 2m4s...Base y cuenta de pruebas
1. Variables de entorno del contenedor
Con el fin de probar la replicación, para el resto del ejercicio se creará una base de datos y una cuenta de prueba.
La imagen Docker de MariaDB soporta este tipo de operaciones. Para realizarlas, hay que basarse en el contenido de las siguientes variables:
-
MYSQL_DATABASE: nombre de la base de datos.
-
MYSQL_USER: nombre de usuario de la base de datos.
-
MYSQL_PASSWORD: contraseña de usuario.
Estas variables se declaran a nivel de campo env del contenedor mariadb.
A continuación, se muestra el extracto de configuración para agregar:
env:
- name: MYSQL_ROOT_PASSWORD
value: password-root
- name: MYSQL_DATABASE
value: test
- name: MYSQL_USER
value: test
- name: MYSQL_PASSWORD
value: test 2. ConfigMap y Secret
a. ¿Por qué llamarlo?
El número de variables todavía es pequeño. Sin embargo, empieza a ser interesante almacenar estos elementos en lugares más apropiados: ConfigMaps y Secrets.
b. Estructura de un objeto ConfigMap
Los objetos ConfigMap (o cm) son bastante sencillos. A continuación, se muestra la estructura mínima:
-
El campo apiVersion y kind.
-
El campo metadata, que está formado por el campo name (que contiene el nombre del objeto ConfigMap).
-
El campo data con las variables de entorno que se deben declarar.
Para el ejercicio, el objeto ConfigMap se llamará mariadb. Almacenará la siguiente información:
-
El nombre de la base de datos (campo MYSQL_DATABASE).
-
El nombre del usuario (campo MYSQL_USER).
Retomando estas diversas indicaciones, la declaración debe ser la siguiente:
apiVersion: v1
kind: ConfigMap
metadata:
name: mariadb
data:
MYSQL_DATABASE:...