En este artículo, exploraremos qué es Kubernetes, sus beneficios y componentes clave, y en qué casos es recomendable adoptarlo.

¿Qué es la orquestación de contenedores?

Antes de adentrarnos en Kubernetes primero dedebes saber qué es la orquestación de contenedores. Las tecnologías de contenedores han cambiado de forma radical el panorama de sistemas y la forma de empaquetar y desplegar el software. Algunos de los beneficios que aportan los contenedores son la portabilidad, la agilidad, la velocidad, la inmutabilidad y el aislamiento de fallos.

Un orquestador de contenedores (en inglés container orchestration) es un software encargado de gestionar y coordinar contenedores de forma automatizada. Existen varias herramientas de orquestación de contenedores como Docker Swarm, Google Container Engine, Amazon ECS, y otras. Sin embargo, en este post nos centraremos en Kubernetes, donde explicaremos el concepto, componentes más destacables de la herramienta y beneficios que Kubernetes puede ofrecer, entre otros puntos.

¿Qué es Kubernetes?

Kubernetes es una plataforma de orquestación de contenedores de código abierto que permite automatizar el despliegue, la gestión y el escalado de aplicaciones en contenedores. Su arquitectura distribuida facilita la administración de clústeres en distintos entornos, ya sea en nube pública, privada o híbrida.

Originalmente desarrollado por Google, Kubernetes se basa en la experiencia de la compañía con Borg, su sistema interno de gestión de contenedores. Desde su lanzamiento como proyecto de código abierto en 2014, ha evolucionado hasta convertirse en la plataforma estándar para la infraestructura cloud-native.

Beneficios de Kubernetes

Implementar Kubernetes en un entorno de producción ofrece numerosas ventajas:

Escalabilidad y eficiencia

Permite escalar aplicaciones de forma horizontal y vertical en función de la demanda, optimizando el uso de los recursos.

Automatización del despliegue y la gestión

Facilita la implementación continua (CI/CD) y la actualización sin tiempos de inactividad, permitiendo la entrega ágil de nuevas versiones de software.

Recuperación ante fallos

Los Pods y nodos defectuosos se reprograman automáticamente, asegurando alta disponibilidad y continuidad del negocio.

Portabilidad y compatibilidad

Es compatible con múltiples proveedores cloud y entornos on-premise, permitiendo la portabilidad sin bloqueos de proveedor (vendor lock-in).

Aislamiento y seguridad

Gracias a su sistema de namespaces, permite aislar cargas de trabajo, mejorar la seguridad y optimizar el uso de recursos.

Componentes clave de Kubernetes

Para comprender cómo funciona Kubernetes, es importante conocer sus principales componentes:

Pods

Los Pods son la unidad mínima de ejecución en Kubernetes. Cada Pod puede contener uno o más contenedores que comparten almacenamiento y red.

Nodos

Los Nodos son las máquinas físicas o virtuales donde se ejecutan los Pods. Un clúster de Kubernetes está compuesto por múltiples nodos.

Control Plane (Plano de Control)

El Control Plane administra el clúster y gestiona la comunicación entre los componentes de Kubernetes. Incluye el kube-apiserver, kube-controller-manager y kube-scheduler.

Clúster

Un clúster de Kubernetes es un conjunto de nodos gestionados como una sola unidad. Asegura la alta disponibilidad y distribución de la carga de trabajo.

¿Cuándo usar Kubernetes?

No todas las aplicaciones requieren Kubernetes. Su adopción es ideal en los siguientes escenarios:

• Arquitecturas de microservicios: Si tu aplicación está basada en microservicios, Kubernetes facilita la gestión de contenedores de manera independiente y escalable.
• Aplicaciones que requieren alta disponibilidad: Kubernetes distribuye cargas de trabajo para garantizar redundancia y recuperación automática en caso de fallos.
• Entornos híbridos o multi-cloud: Permite ejecutar aplicaciones en múltiples nubes o entornos on-premise sin modificar su configuración.
• Cargas de trabajo con picos de demanda: Kubernetes permite escalar horizontalmente de manera dinámica según la demanda.
• Empresas que buscan automatización en DevOps: Kubernetes se integra con herramientas como CI/CD, monitorización y logging, automatizando los flujos de trabajo.

En este webinar puedes saber más sobre qué es Kubernetes y por qué aplicarlo en tu negocio:

Consideraciones antes de adoptar Kubernetes

A pesar de sus múltiples ventajas, Kubernetes no siempre es la mejor opción. Antes de implementarlo, ten en cuenta que requiere conocimientos avanzados para su correcta administración. No es recomendable para proyectos pequeños con recursos limitados, ya que su gestión consume infraestructura y requiere equipo técnico especializado.

Kubernetes se ha convertido en el estándar para la gestión de contenedores, permitiendo el despliegue escalable, automatizado y seguro de aplicaciones en entornos cloud y on-premise. Sin embargo, su implementación requiere una evaluación estratégica para determinar si es la solución adecuada para cada negocio.

Si estás considerando migrar tus aplicaciones a Kubernetes y necesitas asesoramiento, en Geko Cloud podemos ayudarte a optimizar tu infraestructura con Kubernetes.

La entrada ¿Qué es Kubernetes y cuándo usarlo? se publicó primero en Geko Cloud.

Esta versión no solo optimiza el rendimiento general del sistema, sino que también incorpora nuevas capacidades que facilitan la administración de clusters y la asignación de recursos. 

A continuación, detallamos aspectos clave de esta actualización y su impacto en la administración de Kubernetes:

Principales novedades de Kubernetes v1.32

• Mejoras en la Asignación Dinámica de Recursos (DRA)

1. • Se ha optimizado la gestión de hardware especializado como GPUs, FPGAs y adaptadores de red, lo que permite una asignación más eficiente de los recursos en entornos de alto rendimiento.
   • El soporte para parámetros estructurados, ahora en fase beta, mejora la planificación y distribución de los recursos sin necesidad de validaciones externas.
   • Esta actualización beneficia especialmente a áreas como la inteligencia artificial y el cálculo de alto rendimiento.

• Actualizaciones en la gestión de nodos y contenedores sidecar

1. • Se ha implementado el systemd watchdog para reiniciar automáticamente el kubelet en caso de fallos, garantizando una mayor estabilidad y reduciendo el tiempo de inactividad.
   • Las mejoras en los mensajes de error de ImagePullBackOff permiten identificar más fácilmente problemas relacionados con la descarga de imágenes de contenedores.
   • La funcionalidad de los contenedores sidecar se acerca a la fase Stable para la versión v1.33, facilitando su integración en arquitecturas complejas y mejorando la eficiencia operativa.

• Mejoras en fase stable (listas para producción)

1. • Selectores de campo para recursos personalizados: mejora en la filtración de datos en la API, lo que permite a los desarrolladores realizar consultas más precisas y eficientes.
   • Soporte para volúmenes en memoria con tamaño ajustable: posibilita el ajuste dinámico del almacenamiento basado en las necesidades del Pod, optimizando la utilización de recursos.
   • Mejoras en la seguridad de los tokens de cuenta de servicio: ahora se incluye el nombre del nodo en los tokens, reduciendo los riesgos de escalamiento de privilegios.
   • Eliminación automática de PVCs obsoletos: facilita la administración del almacenamiento, evitando residuos innecesarios en el sistema.

• Mejoras en fase beta (pueden cambiar en futuras versiones)

1. • Gestor de trabajos mejorado (Job API managed-by): permite a los controladores externos gestionar la sincronización de trabajos de forma más eficiente.
   • Autorización anónima configurada: los administradores pueden definir qué endpoints permiten acceso anónimo, reforzando la seguridad.
   • Mejoras en la reprogramación de Pods (kube-scheduler): optimiza la priorización de tareas y reduce el tiempo de espera en la asignación de recursos.

• Nuevas funciones en alpha (fase temprana de desarrollo)

• • Preempción asíncrona en el planificador: mejora el rendimiento al manejar operaciones de preempción en paralelo, reduciendo latencias en la asignación de Pods.
  • Especificaciones de recursos a nivel de Pod: introduce la posibilidad de definir recursos compartidos entre los contenedores de un Pod, optimizando el consumo de CPU y memoria.
  • Soporte para apagados controlados en nodos Windows: permite la gestión eficiente, asegurando que los Pods sean reasignados adecuadamente.

Impacto en la administración de Kubernetes

La versión v1.32 de Kubernetes aporta beneficios en varias áreas:

• Reducción de costes operativos: la optimización en la asignación de recursos mejora la eficiencia y reduce el desperdicio de cómputo.
• Mayor estabilidad: con nuevas capacidades de autorecuperación, se minimizan las interrupciones en el servicio.
• Mejoras en seguridad y cumplimiento: las nuevas funcionalidades de autorización y gestión de tokens refuerzan la protección de los entornos Kubernetes.
• Automatización mejorada: Kubernetes sigue avanzando hacia una mayor autosuficiencia, lo que permite a los equipos centrarse en tareas de mayor valor.

Para más detalles sobre Kubernetes v1.32, visita el blog oficial o contáctanos para aprovechar al máximo estas mejoras.

La entrada Kubernetes v1.32, Penelope: novedades y mejoras se publicó primero en Geko Cloud.

¿Qué es un contenedor?

Empecemos con una breve definición de qué es exactamente un contenedor. Los contenedores son una forma de virtualización del sistema operativo. Un solo contenedor puede utilizarse para ejecutar cualquier cosa, desde un pequeño microservicio o proceso de software hasta una aplicación más grande.

Un contenedor es como una caja compacta que contiene todas las dependencias de una aplicación en un solo lugar. Esto no sólo permite que una aplicación se ejecute rápidamente en un sistema, sino que también la hace portátil, fácil de transferir de un entorno a otro.

A diferencia de las máquinas virtuales, los contenedores sólo virtualizan el sistema operativo y las dependencias necesarias, lo cual los hace más ligeros y portátiles, con una carga de sistema significativamente menor. Se pueden transferir fácilmente de un entorno a otro y funcionan de manera uniforme en todo momento gracias a contener todo lo necesario para que la aplicación funcione.

¿Qué es Docker?

Docker es una plataforma de contenerización de código abierto lanzada por la empresa Docker Inc. en 2013, es decir, Docker es una tecnología que se utiliza para crear y ejecutar contenedores de software. En esencia Docker es un sistema que permite construir, transferir, desplegar y ejecutar los contenedores con las aplicaciones dentro de una manera muy sencilla y confiable, garantizando un despliegue escalable de forma eficiente sin importar el sistema operativo anfitrión.

Docker agiliza la creación de contenedores con herramientas como los dockerfiles, y agiliza la definición como código de aplicaciones en contenedores a través de docker-compose. Estas herramientas se utilizan para crear un ciclo de vida de desarrollo, desde definir qué va a haber dentro de un contenedor, hasta establecer su entorno y acceso a recursos. También ayuda a los desarrolladores a trasladar las cargas de trabajo desde su entorno local, a las pruebas hasta la producción, eliminando las incoherencias y dependencias entre entornos. Como el contenedor que se despliega será el mismo en el que se desarrollaba, el entorno tendrá el mismo resultado predecible.

¿Qué es Kubernetes?

Kubernetes (también conocido como k8s) es un orquestador de plataformas de contenedores, como Docker. Para ser más exactos, Kubernetes es un conjunto de herramientas de código abierto para construir una plataforma escalable y tolerante a fallos diseñada para automatizar y gestionar de forma centralizada las aplicaciones en contenedores. Conoce más en detalle sobre esta herramiento en nuestro post ¿Qué es Kubernetes?

Entonces ¿en qué se parecen o diferencian Docker y Kubernetes?

Como podemos deducir de lo anterior, Docker y Kubernetes son tecnologías relacionadas, pero no tienen nada que ver. En realidad, las dos herramientas se complementan entre sí y ayudan a construir arquitecturas nativas en el cloud o de microservicios. Dicho de otra manera, Kubernetes construye sobre Docker, utilizándolo como motor para ejecutar contenedores, pero éste se ocupa de cómo se ejecutan estos contenedores exactamente: configuración, réplicas, acceso a recursos del sistema, o comunicación de red. Se encarga de generar estas configuraciones y de comunicarlas a Docker para que las aplique.

¿Cuál es la diferencia entre Docker y Kubernetes? Kubernetes está pensado para ejecutarse en un clúster, mientras que Docker se ejecuta en un único nodo por defecto, sin gestión de replicación o mantenimiento de salud de los contenedores, sólo se ocupa de ejecutar un contenedor tal y como se ha declarado. Por lo tanto, la diferencia fundamental entre Docker y Kubernetes es que Docker es una plataforma de contenerización, lo que significa que se encarga de la creación de contenedores, mientras que Kubernetes es una plataforma de orquestación de contenedores.

Por lo tanto, la comparación entre Kubernetes y Docker no es tan sencilla como crear una lista de pros y contras o de características por características. Sin embargo, existe una tecnología de orquestación similar a Kubernetes desarrollada por Docker Inc. llamada Docker Swarm, que nos proporciona elementos parecidos a Kubernetes como la gestión de replicación o el balanceo de carga entre contenedores.

Conclusión

En resumen, Docker proporciona un estándar abierto para empaquetar y distribuir aplicaciones en contenedores y es suficiente para abordar casos de uso sencillos y Kubernetes aprovecha un amplio ecosistema de herramientas junto con la integración continua/despliegue continuo (CI/CD) y otras prácticas de DevOps para orquestar grandes conjuntos de contenedores, desde los entornos de desarrollo hasta los de producción.

En Geko Cloud estamos a tu disposición si estás buscando un partner para implementar Kubernetes, migrar al cloud, cambiar a un modelo de microservicios o gestionar tu plataforma en el cloud. Contacta con nosotros para conocer nuestros servicios.

La entrada Kubernetes vs Docker, conoce en qué se diferencian se publicó primero en Geko Cloud.

Hoy vamos a hablar sobre esta última opción; una solución para desplegar un registry dentro del propio Kubernetes: Harbor.

¿Pero qué es Harbor?

Harbor es open-source y es parte de la Cloud Native Computing Foundation. Implementa funcionalidades básicas como por ejemplo autenticación basada en roles (con soporte para LDAP) y también ofrece otras características más avanzadas como la habilidad para subir y gestionar charts de helm, realizar escaneo de vulnerabilidades sobre las imágenes subidas, y mucho más.

Suficiente charla, ¡quiero un hands-on!

Vamos a ver cómo poner en marcha Harbor en nuestro clúster. Asumiremos que cuentas con los siguientes requisitos:

• Tienes un clúster de k8s con un ingress-controller. Minikube es aceptable.
• Tienes helm instalado (lee sobre cómo instalar helm)
• Tienes el cliente de docker instalado localmente
• Te sobran 10 minutos

IMPORTANTE: Deberías tener cert-manager instalado en el clúster ya que Harbor requiere tener un certificado HTTPS válido para permitir el login desde la terminal.

Instalando Harbor

Vamos a usar el chart de helm oficial para esta parte. Para hacerlo, primero necesitarás añadir el repo de harbor:

helm repo add harbor https://helm.goharbor.io

Para personalizar tu despliegue puedes crear un nuevo fichero values.yaml, reemplaza el contenido con los valores más adecuados para ti:

expose:
  type: ingress
  tls: 
    commonName: "TU_CN"
  ingress:
    hosts:
      core: "harbor.TU_DOMINIO"
persistence:
  enabled: true
externalURL: "https://harbor.TU_DOMINIO"
harborAdminPassword: admin

Ahroa crearemos un nuevo namespace y desplegaremos el chart. Los valores a usar dependerán de tus necesidades:

kubectl create harbor-system
helm install --wait harbor --namespace harbor-system harbor/harbor -f values.yaml

En cuanto termine la instalación (puede tomar hasta 5 minutes) ya puedes ir al dominio usando tu navegador web y hacer login con el usuario admin y el password que definiste en el values.yaml. Tras el login deberías ver algo muy parecido a ésto:

Subiendo tu primera imagen

Primero, debes hacer login desde el terminal usando el comando docker login y proporcionando tus credenciales:

docker login https://harbor.YOUR_DOMAIN

*Ten en cuenta de que para poder acceder a harbor a través de este dominio deberás crear una entrada de DNS en tu gestor de DNS y es imprescindible contar con un certificado HTTPS válido

Haz click sobre «NEW PROJECT» y rellena los inputs:

Tras hacer click en OK ya deberías poder ver tu nuevo proyecto en la página principal.

Ahora, vamos a probar a subir una nueva imagen a este proyecto. Haremos pull de la imagen oficial de nginx, pondremos un tag con la dirección de tu harbor/proyecto y haremos el push:

docker pull nginx
docker tag nginx harbor.YOUR_DOMAIN/myproject/nginx:latest
docker push harbor.YOUR_DOMAIN/myproject/nginx:latest

Si todo ha ido bien, deberías poder ver la imagen de nginx dentro del proyecto que creaste en harbor:

Y ahora, ¿qué?

Has desplegado un nuevo Harbor registry privado y ya has subido tu primera imagen.

En la próxima entrada de esta serie veremos cómo crear las credenciales necesarias para que tus pods sean capaces de hacer pull de las imágenes que subas en tu Harbor privado y veremos cómo indicar a Kubernetes cuando y cómo puede usar esas credenciales.

Espero que hayas disfrutado de este post y te animo a que revises nuestro blog para leer otrosposts que puedan ser de tu interés. No dudes en contactarnos si deseas que te ayudemos en tus proyectos.

¡Nos vemos en la próxima entrada!

La entrada Harbor: Instalar un registry privado en Kubernetes se publicó primero en Geko Cloud.

Jenkins Kubernetes Pod Template

El otro día nos encontramos con un problema no muy común con uno de nuestros clientes…

Resulta que algunas de las pipelines de Jenkins dejaron de funcionar ya que los nodos destinados a la ejecución de ciertas tareas, usaban nodos Kubernetes como ejecutores y se quedaban esperando que los pods encargados arrancaran:

[Pipeline] node
Still waiting to schedule task
All nodes of label ‘docker-build-xxxxxx’ are offline

Aquí os dejo un enlace con el plugin y su configuración por si os interesa usar esta gran funcionalidad

El problema

Decidimos entrar a inspeccionar los nodos de Kubernetes para revisar la ejecución de los pods del namespace destinado a estas tareas y la API de Kubernetes nos responde lo siguiente en todos los comandos que lanzamos desde nuestro kubectl:

Unable to authenticate the request due to an error: [x509: certificate has expired or is not yet valid, x509: certificate has expired or is not yet valid]

Bingo! resulta que el certificado de nuestro Kubernetes que se usa para el cliente kubectl y el etcd ha expirado. Esto representa un pequeño problema ya que para renovar un certificado en Kubernetes, utilizamos las conexiones a la API para hacerlo, pero estas llamadas requieren de tener un certificado válido.

Entonces qué hacemos??

Geko al rescate

Existe una solución que pasa por destruir los certificados a mano y con el comando kubeadm inicializarlos engañando al control plane para que crea que no existen certificados previos.

Nuestro consejo es mover todos los certificados a una carpeta temporal para luego forzar la inicialización de nuevos certificados y finalmente inicializar la config de todo el cluster de kubernetes

$ cd /etc/kubernetes/pki/ 
$ mkdir -p /tmp/oldcerts/etcd
$ mv {apiserver.crt,apiserver-etcd-client.key,apiserver-kubelet-client.crt,front-proxy-ca.crt,front-proxy-client.crt,front-proxy-client.key,front-proxy-ca.key,apiserver-kubelet-client.key,apiserver.key,apiserver-etcd-client.crt} /tmp/oldcerts 
$ mv etcd/* /tmp/oldcerts/etcd
$ kubeadm init phase certs all --apiserver-advertise-address  
$ cd /etc/kubernetes/ 
$ mv {admin.conf,controller-manager.conf,kubelet.conf,scheduler.conf} /tmp/oldcerts 
$ kubeadm init phase kubeconfig all 
$ reboot

Tras el reinicio, nuestro cluster habrá arrancado utilizando los nuevos certificados y ya podremos copiar las credenciales en nuestro directorio home o en nuestro sistema personal para poder hacer las llamadas a la API.

$ cp -i /etc/kubernetes/admin.conf $HOME/.kube/config

Una vez copiado el config , ya podemos utilizar el cliente kubectl para conectar a nuestro K8S.

En nuestro caso eliminamos todos los pods huérfanos generados con jenkins en el namespace llamado «cicd»:

for docker in `kubectl get pods -n cicd | awk {'print $1'}`;do kubectl delete pod $docker -ncicd;done

Esperamos que os sirva para rescatar vuestro Kubernetes con certificados expirados! y recordar dejarnos vuestros comentarios…

Si os podemos ayudar con la configuración, incidencias o mejoras de vuestra plataforma Kubernetes, no dudéis en contactarnos.

La entrada Renueva tus certificados expirados en Kubernetes se publicó primero en Geko Cloud.

Introducción

Muchas veces para realizar nuestras tareas diarias nos vemos en la situación de tener que crear herramientas propias para resolver problemas o situaciones a medida. En esta entrada voy a mostrar lo fácil que es y cómo podemos crear un plugin para kubectl.

Un plugin es simplemente un programa ejecutable que permite extender la funcionalidad de kubectl, permitiendonos implementar nuestros propios subcomandos. Es importante mencionar que podemos hacerlo en el lenguaje que más nos guste: Bash, Python, Go, etc…

¿Qué necesitamos?

Existen ciertas condiciones que debemos cumplir para que nuestro plugin funcione:

1. El nombre del archivo debe comenzar con «kubectl-» y no debe contener extensión.
2. El archivo debe ser ejecutable.
3. Debe encontrarse ubicado en nuestro PATH

Y esta es toda la instalación que requerirá. Simple, ¿no?

Podemos ver qué plugins tenemos disponibles utilizando:

kubectl plugin list

Este comando buscará dentro de PATH todos los archivos ejecutables que cumplan con el nombre requerido.

¡Manos a la obra!

Creamos un entorno  de pruebas

Hagamos un simple plugin, más entretenido que el trivial «Hola Mundo!», que envíe los logs de todos pods corriendo a una salida única para poder visualizar dicha salida de manera conjunta. Para hacerlo más entretenido agregaremos el nombre del pod colorido por cada línea de log en el output. Y además podremos seleccionar con las teclas numéricas de 1 a N (donde N es el enésimo pod: 1 < N < 10 por simpleza), filtrar on-the-fly y ver solamente la salida de ese pod. ¡Y todo esto lo haremos en Bash!

Para esta demo vamos a usar una imagen de docker nginx-log-generator que genera fake-logs del Nginx. Primero crearemos un deployment de kubernetes que contendra los pods. Creamos un nuevo archivo llamado fake-logs.yaml con el siguiente contenido:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-fake-logger
spec:
  template:
    metadata:
      name: logger-1
      labels:
        app: logger
    spec:
      containers:
        - name: logger
          image: kscarlett/nginx-log-generator
  replicas: 3
  selector:
    matchLabels:
      app: logger

Y aplicamos el deployment:

kubectl create -f fake-logs.yaml

Podemos comprobar que nuestros nuestro deploy esta funcionando:

$ kubectl get pods
NAME                              READY   STATUS    RESTARTS   AGE
my-fake-logger-66dcffbccd-6kx8b   1/1     Running   4          6d2h
my-fake-logger-66dcffbccd-7q4tm   1/1     Running   1          3d1h
my-fake-logger-66dcffbccd-cff4s   1/1     Running   1          3d1h

$ kubectl get deploy
NAME             READY   UP-TO-DATE   AVAILABLE   AGE
my-fake-logger   3/3     3            3           6d2h

Creamos el plugin:

Primero: Crearemos el archivo de nuestro plugin llamado kubectl-demo con el siguiente script.

#!/bin/bash
trap ctrl_c INT
function ctrl_c() {
  echo "**************************************** Bye Bye ****************************************"
  for pid in ${PIDS[@]}
  do
      kill -TERM $pid 
  done
  rm $NAMED_PIPE
  rm $sync
  exit 0
}

function colorize() {

  pod=$1
  counter=$2
  # colors from 31 to 39
  pre_colour="\033[3${counter}m"
  post_colour="\033[0m"
  if [ "$colorize_output" = true ]
  then
    colour_pod="${pre_colour}[${pod}]${post_colour}"
  else
    colour_pod="[${pod}]"
  fi
}

function show_logs() {
  local sync="$1"
  grep -E -f $sync $NAMED_PIPE &
}

function banner() {
  echo ""
  echo "==================================================="
  echo "+ Showing logs for:"
  echo "+ $1"
  echo "==================================================="
  echo ""
}

function start_log() {
  show_logs $sync 
  shl_pid=$!
  disown $shl_pid
  PIDS+=$shl_pid" "  
}

function usage() {
  echo "~~~~~~~~~~~"
  echo " U S A G E"
  echo "~~~~~~~~~~~"
  echo "Usage: kubectl demo [option]"
  echo "  options:"
  echo "    --no-colorize: no colorize [default: colorize]"
  echo "    -h: Show this help"
  echo ""
  echo "When running you can use the numbers 1 to N to filter N-pod and only show it's output."
  echo "0 resets and shows all outputs again"
  echo ""
}

NAMED_PIPE="/tmp/my_named_pipe"
PODS=$(kubectl get pods --no-headers=true -o=custom-columns=NAME:.metadata.name)
TOTAL_PODS=$(echo $PODS | sed -s 's/ /n/g' | wc -l)
colorize_output=true

if [[ $@ ]]; then
  case "$@" in
    "--no-colorize")
      colorize_output=false
      ;;
    "-h")
      usage
      exit 1
      ;;
    *) echo "Invalid option"
      exit 1
      ;;
  esac
fi


# create named pipe
if [ ! -p $NAMED_PIPE ]
then
    mkfifo $NAMED_PIPE
    chmod a+rw $NAMED_PIPE
fi

PIDS=()
declare -A pods_index
counter=1
for pod in $(echo $PODS)
do
  colour_pod=""
  colorize $pod $counter
  kubectl logs -f $pod | awk -v pod_name=$colour_pod '{print pod_name" "$0}' > $NAMED_PIPE &
  PIDS+=$!" " # save all PIDs
  pods_index[$counter]=$pod
  counter=$((counter+1))
done

# Trick: Shared memory segment for inter process comunication. 
sync=/dev/shm/syntest-$$  # allocate a shared memory segment name for this pid
echo '' > $sync           # init the shm

start_log
input="*"
re='^[0-9]+$' # we match only numbers

while true
do
  read -t 0.25 -N 1 input
  if  [[ $input =~ $re ]]  && [ "$input" -ge "0" ] && [ "$input" -le "$TOTAL_PODS" ]
  then
    if [ "$input" -eq "0" ]
    then
      banner "All Pods"
      echo $ > $sync    # grep everything
    else
      banner ${pods_index[$input]}
      echo ${pods_index[$input]} > $sync  # grep only pod name
    fi
    kill -SIGTERM $shl_pid
    PIDS=$(echo $PID | sed -e "s/$shl_pid//g" | tr -s " ")  # remove unused pid
    start_log
  fi
done

Segundo: Le daremos permisos de ejecución.

chmod +x kubectl-demo

Tercero: Y último paso, necesitamos que este accesible en nuestro PATH.

ln -s $PWD/kubectl-demo /usr/local/bin/kubectl-demo

A partir de ahora, y sin nada más que hacer, podemos hacer uso de nuestro recién creado plugin.

Podemos comprobar que kubectl está listo para usarlo listando los plugins que encuentra:

$ kubectl plugin list
The following compatible plugins are available:

/home/user/kubectl-demo

 ¡Pongámoslo a prueba!

Mostramos las opciones posibles:

$ kubectl demo -h
~~~~~~~~~~~
 U S A G E
~~~~~~~~~~~
Usage: kubectl demo [option]
  options:
    --no-colorize: no colorize [default: colorize]
    -h: Show this help

When running you can use the numbers 1 to N to filter N-pod and only show it's output.
0 resets and shows all outputs again

A modo de ejemplo de cómo podemos pasar parámetros a nuestros sub-comandos, hemos agregado la opción para permitir no pintar el output.

Outputs

Default:

[my-fake-logger-66dcffbccd-7q4tm] 214.216.236.37--[02/Jan/2021:10:17:17+0000] "GET/moderator/Reduced.cssHTTP/1.1"....
[my-fake-logger-66dcffbccd-6kx8b] 132.56.98.34--[02/Jan/2021:10:19:22+0000] "GET/standardization.svgHTTP/1.1"2001908 
[my-fake-logger-66dcffbccd-cff4s] 159.240.103.70--[02/Jan/2021:10:24:45+0000] "GET/Virtual.htmHTTP/1.1"2002288"-"....

Podemos elegir que pod mostrar con los números del 1 a 3 en este caso:

# 1
===================================================
+ Showing logs for:
+ my-fake-logger-66dcffbccd-6kx8b
===================================================
[my-fake-logger-66dcffbccd-6kx8b]  16.211.208.91 - - [02/Jan/2021:10:34:33 +0000]  "GET /bottom-line%20Advanced/Upgradable/intermediate.svg HTTP/1.1" ....

Y podemos resetear esta vista con el número 0 y volver a tener todos los logs:

===================================================
+ Showing logs for:
+ All Pods
===================================================
[my-fake-logger-66dcffbccd-7q4tm] 214.216.236.37--[02/Jan/2021:10:17:17+0000] "GET/moderator/Reduced.cssHTTP/1.1"30143"-"....
[my-fake-logger-66dcffbccd-6kx8b]  16.211.208.91 - - ....

Como vemos el script es simple y te invito a que pruebes todas sus opciones, modifiques a tu gusto y extiendas su funcionalidad.

Conclusión:

Hemos visto que es sumamente sencillo crear un plugin para kubectl, basta con programar lo que nuestra imaginación quiera y cumplir con el nombre y ubicación del ejecutable.

Por esta facilidad, no existe excusa para no hacer un plugin prácticamente por cada necesidad específica que necesitemos de kubectl.
También es necesario comentar que existe una gran cantidad de plugins provistos por la comunidad.
¡Vale la pena echar un vistazo!

Espero que este artículo te haya servido de ayuda para aprender algo nuevo y seguir ampliando tus conocimientos.

Te invito a que si necesitas información sobre el mundo DevOps o Kubernetes, nos contactes y sigas revisando nuestro blog para encontrar otras publicaciones útiles. ¡Hasta la próxima!

La entrada Kubectl Plugins en solo 3 pasos se publicó primero en Geko Cloud.

Hoy en día, y cada vez más, es común que las empresas migren algunas partes de su infraestructura (o incluso la compañía entera) al cloud. Hay dos principales enfoques: Permanecer lo mas cerca posible de la antigua arquitectura usando VMs, o apostar por flexibilidad/escalabilidad/disponibilidad y buscar una nueva perspectiva mediante el uso de un orquestador de contenedores como Kubernetes. Centrándose en esta última opción (Kubernetes), lo que anteriormente se ejecutaba directamente sobre un Sistema Operativo (y que por tanto tenía acceso a la mayoría de aplicaciones que provee dicho Sistema) ahora se ejecuta dentro de contenedores. Además, estos contenedores comúnmente no se ejecutan en un destino (máquina/nodo) específico, sino en un clúster. Todo funciona bien y todo es fantástico, hasta que uno se da cuenta de que el entorno ya no es tan amigable y conocido como cabría esperar. Herramientas de Sistema Operativo, como las tareas programadas o Crones, no encajan en las buenas prácticas de los contenedores, ya que son trasversales al Sistema (lo que es lo opuesto a la filosofía que se predica para los contenedores, consistente en aislar cada aplicación). Incrustar esas herramientas (o sus comportamientos) en la aplicación, al mismo tiempo que se aísla la misma, puede llegar a convertirse en una ardua tarea plagada de parches temporales y prácticas no tan buenas.

Como ecosistema completo grande, Kubernetes provee por su cuenta algunas de las funcionalidades anteriormente mencionadas, de modo que los requerimientos del día a día puedan ser atendidos y gestionados. Sin embargo, aparecen nuevas operativas y posibilidades cuando se habla de clústeres y contenedores. A lo largo de las siguientes líneas se describirá cómo Kubernetes ha solucionado la funcionalidad Cron, así como la mayoría de sus nuevas características y detalles ocultos.

1. Cómo funcionan los CronJobs en Kubernetes realmente

Cuando se crea un recurso CronJob, lo que hace realmente Kubernetes es registrar una programación en el tiempo. Cada 10 segundos el Controlador de CronJobs comprueba si hay programaciones que coincidan y de las que deba ocuparse. Cuando llega el momento señalado se crea un recurso Job, que deberá hacerse cargo de la tarea para esa ejecución específica. Finalmente cada Job crea un recurso Pod, que será el ejecutor final.

Como probablemente se haya podido apreciar ya, esta aproximación difiere significativamente del enfoque que tiene un Sistema Operativo. Lo que se observa aquí es un desacoplamiento entre el sistema de programación en el tiempo (Cron) y la gestión de las ejecuciones (Jobs). Esto permite al clúster (y por tanto al usuario) gestionar tareas efímeras sin perder el control sobre ellas.

Cabe además mencionar que los Jobs pueden crear uno o más Pods (permitiendo concurrencia/paralelismo) a la vez que se aseguran que las tareas se completan satisfactoriamente. Sin embargo, este último comportamiento podría crear complejidades adicionales ya que los contenedores ya incorporan su propia funcionalidad de gestión de fallos y reinicios. Este tema será abordado en la siguiente sección.

2. Cómo configurar los detalles avanzados

Debe tenerse en cuenta que para configurar un CronJob, cada recurso subyacente debe configurarse también. Esto significa que la configuración de un CronJob agrega sus propios parámetros además de las propiedades del Job y de las especificaciones del Pod/contenedor. Teniendo en cuenta que la mayoría de las operativas comunes se pueden entender y conseguir leyendo la documentación, el propósito de esta sección es mostrar cómo obtener ciertas funcionalidades avanzadas mediante la configuración.

Gestionar los errores

Cuando un contenedor detiene su ejecución (ya sea por un fallo o después de una ejecución satisfactoria) existen una serie de acciones que se pueden tomar justo después, las cuales son definidas (como de costumbre) por las directivas del propio recurso. Las acciones típicas son reiniciar el contenedor (siempre o sólo cuando ha sucedido algún error) o bien no hacer nada. Pero, además, los Jobs añaden una capa de complejidad adicional que se encarga de que la tarea se termine adecuadamente. Esto quiere decir que la política de reinicios se garantiza desde dos capas diferentes, que a su vez deben gestionarse desde dos partes diferentes.

Desde el lado de los contenedores, la directiva se llama restartPolicy. En el lado de los Jobs, la política se gestiona mediante la directiva backoffLimit, la cual  especifica el número de fallos permitidos antes dejar de reiniciar la tarea. Teniendo ambas en cuenta, obtener la configuración para un CronJob que pueda fallar sin reinicios se aproxima a lo siguiente.

apiVersion: batch/v1beta1
kind: CronJob
...
spec:
  ...
  jobTemplate:
    spec:
      backoffLimit: 0
      template:
        spec:
          containers:
            ...
          restartPolicy: Never

Ejecuciones Solapadas vs. Secuenciales

Cuando se habla de un CronJob en específico, podrían coexistir varias ejecuciones. Dependiendo del tipo de operativa que caracterice a la tarea, la concurrencia podría ser una forma de proceder para acelerar el procesamiento. Existen tres vías disponibles para gestionar cómo se ejecutan los Jobs, las cuales son controladas mediante la directiva concurrencyPolicy.

1. Allow: Permite ejecuciones solapadas.
2. Replace: Las nuevas ejecuciones fuerzan, antes de comenzar, que se terminen las ejecuciones previas.
3. Forbid: Las nuevas ejecuciones se descartan si una ejecución previa todavía está en ejecución.

Mientras que la primera permite la concurrencia, las dos últimas apuestan por ejecuciones secuenciales. Una vez más, para seguir el estilo de los crones de la vieja escuela, la opción que más se aproxima es Allow. Por otra parte, las ejecuciones concurrentes pueden desembocar en efectos no deseados si no se tratan adecuadamente, y es algo que se debe tener en cuenta y tratarse con cautela.

Tiempo mínimo de ejecución

Como ya se ha visto anteriormente, las nuevas ejecuciones de tareas pueden llegar a interferir con las anteriores, dependiendo de cómo se establezcan las directivas de concurrencia. Existe una propiedad en la especificación de los contenedores (terminationGracePeriodSeconds) que se puede emplear para sobrellevar las consecuencias de interrumpir ejecuciones. Mediante su uso se puede definir un tiempo mínimo de ejecución, de modo que aunque una nueva tarea fuerce la terminación de una previa, se garantiza una terminación grácil.

3. Operar con los CronJobs como un Maestro

Una vez la configuración pone de manifiesto lo que se pretende que haga el CronJob, los comandos básicos pueden ser utilizados para recuperar su estado (información acerca de la programación, el estado de ejecución, logs, …). Al igual que en la sección anterior, las siguientes operativas cubren cómo obtener algunas funcionalidades menos comunes.

Habilitar/Deshabilitar los CronJobs

La especificación de los CronJobs contiene una propiedad llamada suspend que permite deshabilitarlos. Ya sea de manera temporal o permanente, los CronJobs se pueden definir sin que ello implique que vayan a ser ejecutados (a pesar de lo que indiquen sus programaciones en el tiempo).

# Deshabilitar un CronJob
NOMBRE_CRONJOB=mi-cronjob-1
kubectl patch cronjobs $NOMBRE_CRONJOB -p '{"spec" : {"suspend" : true }}'

# Deshabilitar TODOS los CronJobs
kubectl get cronjobs | grep False | cut -d' ' -f 1 | xargs kubectl patch cronjobs -p '{"spec" : {"suspend" : true }}'

Echa un vistazo a la siguiente sección para descubrir más detalles sobre los efectos colaterales que esto podría causar.

Ejecutar CronJobs manualmente

Es ampliamente reconocido que las pruebas (comunmente llamados tests, del Inglés) son útiles para detectar efectos no deseados. Los CronJobs se pueden ejecutar manualmente incluso cuando están desactivados, por lo que mantenerlos en ese estado y poder ejecutarlos bajo circunstancias que sirvan para probarlos puede ayudar a validar que todo está correctamente configurado.

NOMBRE_CRONJOB=mi-cronjob-1
kubectl create job --from=cronjobs/$NOMBRE_CRONJOB $NOMBRE_CRONJOB-ejec-manual-01

4. Sacando a la luz los casos poco frecuentes

Después de todo, no existiría la variedad si todo funcionase igual. Cada situación tiene sus propias particularidades y características especiales, por lo que cuando se trata de los CronJobs la cosa no es diferente. A lo largo de las siguientes líneas se presentarán y tratarán algunos casos poco frecuentes, de modo que las soluciones aportadas puedan ser reutilizadas (o, al menos, tenidas en consideración).

Tiempo máximo de ejecución

En secciones anteriores se trató el tema del tiempo de ejecución, de modo que se garantizase un tiempo mínimo antes de forzar la terminación. Pero, ¡eh! ¿Qué sucede con las ejecuciones que se alarguen en el tiempo más allá de lo previsto? La motivación (desde un punto de vista agnóstico) de los contenedores (y también la de Kubernetes) es la de ejecutar las tareas hasta el infinito y más allá. Los contenedores pueden fluir o pueden crashear (fallar), pero no se deben terminar como una práctica habitual. Siguiendo este principio, no existe ninguna forma de gestionar la expiración del tiempo previsto desde la especificación de los CronJobs/Jobs/Contenedores. ¿Entonces, es imposible implantar un tiempo máximo de ejecución? — ¡No, no lo es! En este punto es donde el abanico de herramientas de Linux aparece al rescate. Existe un comando llamado timeout que puede ser usado para ejecutar otro comando durante una cantidad específica de tiempo.

Aunque la utilidad anterior puede limitar el tiempo, el código de salida de la ejecución cuando lo hace, no es un código exitoso; por lo que el contenedor entrará en un estado de fallo (que puede escalar en un reinicio si así está especificado). Por otra parte, el estado del comando que se quiere ejecutar se puede preservar, pero entonces no se puede saber si fue terminado o no. Entonces, ¿cómo tratar ambas situaciones? En el siguiente extracto de código se puede hallar una propuesta que consigue terminar siempre de manera satisfactorio, a la vez que se devuelve retroalimentación acerca de lo ocurrido en realidad.

containers:
  - name: "mi-container-limitado-a-10s"
    ...
    command: ["bash", "-c"]
    args:
      - /usr/bin/timeout 10 bash -c 'bash -c "com arg1" && echo OK || echo KO-COM' || echo KO-TMP

CronJobs que no se ejecutan después de haber sido desactivados y activados de nuevo

Se produce un efecto colateral cuando se desactiva un CronJob, que consiste en que después de haberse perdido 100 programaciones en el tiempo, el CronJob no se volverá a ejecutar. Esta información ya se señala en la documentación, pero se menciona de pasada y se trata como algo poco relevante. La solución en este caso es volver a crear el recurso.

CronJobs que se ejecutan fuera de su programación después de haber sido reactivados

Se puede encontrar otro efecto no esperado cuando se trata con CronJobs, que consiste en que al reactivar uno de ellos (y a pesar del hecho de que el momento en el que se haga no coincida con el que tiene programado) se ejecuta inmediatamente. Esto sucede porque la ejecución no es simplemente un evento aislado, sino una ventana de tiempo con una fecha límite. Esto implica que cada ejecución que se pierde (por la política de concurrencia, o por estar el CronJob deshabilitado) incrementa un contador (hasta cierta cantidad, lo que probablemente está relacionado con el caso poco frecuente anterior). Entonces, llegado el momento, cuando el CronJob se vuelve a activar y se permite de nuevo su ejecución, el controlador tiene en cuenta que existen programaciones pendientes. Si la ventana de tiempo no se ha cerrado aún, el CronJob comienza a ejecutarse.

Este comportamiento puede gestionarse estableciendo la directiva startingDeadlineSeconds en un valor pequeño, de modo que la ventana de ejecución no coincida con el momento de la reactivación.

CronJobs que no se ejecutan

Cabe tener en cuenta que la anterior directiva startingDeadlineSeconds se puede establecer en cualquier valor, pero no todos ellos van a causar el efecto deseado. Como ya se ha mencionado anteriormente el controlador de CronJobs se ejecuta cada 10 segundos, por lo que todo valor por debajo de diez segundos hará que los CronJobs nunca se ejecuten. Se ha enviado una incidencia al proyecto de website de Kubernetes, avisándoles de este caso. Seguramente en siguientes versiones se podrá encontrar que ya se ha documentado, aunque no sea así por el momento.

Así que no se debe olvidar establecer startingDeadlineSeconds en un valor mayor que 10.

Conclusión

Como habrás podido comprobar, la diferencia entre los crones de Sistema Operativo y los de Kubernetes es mayor de la esperable desde un primer momento. Existen diferentes escenarios en un clúster y numerosas situaciones gestionar, y por eso se tratan. En algunos casos estaremos buscando un comportamiento similar al que podemos obtener en un Sistema Operativo, y en otros casos no, pero probablemente todos ellos pueden ser abordados. Por otra parte, que algo se incline mucho al multi-propósito también puede derivar (como los CronJobs) en una experiencia de configuración con una mayor dificultad.

Afortunadamente siempre puedes contar con el equipo de Geko (un equipo de ingenieros altamente cualificados), quienes profundizarán en el tema hasta conseguir hacerlo sencillo para ti. ¡No olvides volver por el blog de Geko para comprobar qué hay nuevo por aquí! El equipo de Geko siempre estará más que contento de verte por aquí, y por supuesto ¡Ponte en contacto con nosotros para más información!

Lectura adicional

https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/
https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/
https://kubernetes.io/docs/concepts/workloads/controllers/job/
https://www.magalix.com/blog/kubernetes-patterns-the-cron-job-pattern
https://medium.com/@bambash/kubernetes-docker-and-cron-8e92e3b5640f
https://medium.com/cloud-native-the-gathering/how-to-write-and-use-kubernetes-cronjobs-3fbb891f88b8
https://medium.com/@hengfeng/what-does-kubernetes-cronjobs-startingdeadlineseconds-exactly-mean-cc2117f9795f

La entrada Kubernetes CronJobs – Una vista en profundidad se publicó primero en Geko Cloud.

Todos conocemos la oferta de Kubernetes gestionados del «big three»: EKS, GKE y AKS.

Pero a día de hoy, aparte de los anteriores y de algunos más que quieren jugar en la misma liga (Oracle o IBM, por ejemplo), existen otros proveedores menos conocidos que, no pudiendo competir en catálogo de servicios, intentan hacerse un hueco ofreciendo sencillez y precios más bajos. Una de las bondades que ha traído la «explosión» de Kubernetes es que con él y poco más (un load balancer, algo de almacenamiento y una base de datos gestionada) se puede llegar muy lejos antes de necesitar lo que ofrecen los grandes.

Así que, cuando hablamos de Kubernetes «sencillo y barato», la fórmula consiste en ofrecer el servicio de «Kubernetes gestionado» (los nodos master son alojados y gestionados por el proveedor) sin cobrar por ello. Y esto es justamente lo que proporcionan proveedores como Scaleway, Linode, OVH o DigitalOcean.

Probando un clúster gestionado

En Geko Cloud estamos desarrollando un producto basado en Kubernetes del que muy pronto tendréis más noticias, así que decidimos usarlo para probar uno de los servicios de la lista (en este caso, Digital Ocean Kubernetes Service).

Crear un cluster es muy sencillo: basta con seleccionar la versión, la región, el tipo de nodo para el pool y darle un nombre:

En nuestro caso, al tratarse de una prueba, elegimos crear droplets básicos y confiar en el cluster autoscaler en caso que la aplicación fuera a necesitar más recursos.

Cuando el clúster estuvo listo (el proceso puede tardar unos 10-15 minutos), solo tuvimos que descargar el fichero kubeconfig y lanzar el proceso de instalación de la aplicación. Y ahí empezaron los problemas.

Problemas observados

Al poco rato, el API server empezó a comportarse de forma un tanto errática, respondiendo muy lentamente o devolviendo diversos errores. Síntomas:

• Tiempos de respuesta altísimos, en ocasiones incluso superiores al minuto

  bash-5.0# time kubectl get pods -A 
  NAMESPACE                      NAME                                                 READY   STATUS              RESTARTS   AGE
  istio-system                   istio-init-crd-10-1.4.8-86xf9                        1/1     Running             1          7m1s
  …
  real    1m14.507s
  user    0m0.174s
  sys     0m0.028s
  

• Errores de conexión

  bash-5.0# kubectl get pods -A
  Unable to connect to the server: unexpected EOF

• Timeouts en la negociación TLS

  bash-5.0# kubectl get pods -A
  Unable to connect to the server: net/http: TLS handshake timeout

El problema tenía que estar relacionado con la instalación ya que antes de eso todo funcionaba perfectamente.

DigitalOcean, al igual que el resto de proveedores, no ofrece ningún tipo de información acerca de los recursos dedicados a los nodos master (número de nodos, tamaño de los mismos…) ni acceso a los logs o a la monitorización del control plane, así que no había forma de saber qué estaba pasando.

Una búsqueda rápida nos hizo darnos cuenta que no éramos los únicos con este tipo de problemas, aunque también vimos que muchos otros eran usuarios felices del servicio.

Solución

Esto nos hizo sospechar que no todos los nodos master eran creados por igual, y que el único parámetro del proceso de creación que podía crear la diferencia era el node pool configurado.

Para verificar nuestra teoría, primero probamos a crear un clúster con un node pool con más nodos (de 3 pasamos a 6), con idéntico resultado.

Así que probamos a crear un node pool con nodos no-básicos (CPU-Optimized en este caso). Y ahí sí dimos en el clavo: el proceso de instalación terminó sin problemas y el API server estuvo respondiendo adecuadamente todo el tiempo.

Conclusión

Está claro que nadie regala nada y que no puedes esperar tener un nodo master dedicado con 16 cores y 64 Gb de RAM pagando 20€ al mes por un droplet básico. De todos modos no estaría de más que fueran un poco más transparentes e informaran de las capacidades y limitaciones del servicio que están ofreciendo (aunque sea gratuito). De esta forma, más de uno se ahorraría dolores de cabeza y frustraciones.

Así que si tienes planteado usar este servicio para alojar una aplicación que vaya a hacer un uso más o menos intensivo del API server, será mejor que te decantes por droplets no-básicos si no quieres tener problemas de rendimiento.

Y recuerda que si necesitas cualquier cosa estaremos encantados de escucharte. ¡También puedes revisar nuestro blog para encontrar otras publicaciones útiles como ésta!

La entrada Kubernetes gestionados «alternativos» se publicó primero en Geko Cloud.

En este how-to vamos a cubrir desde la instalación de cert-manager a cómo configurarlo para realizar la validación por HTTP. También aprenderemos a crear un nuevo certificado para nuestro host simplemente añadiendo una annotation a nuestro ingress.

¡Suena bien! ¿Qué necesito?

Deberías cumplir con estos requisitos:

• Tener un clúster k8s funcional con nginx como ingress-controller
• Tener helm instalado (lee aquí cómo instalar helm)
• Tener un dominio en tu posesión que apunte hacia el clúster
• Ganas de aprender algo nuevo

¡Empecemos!

Primero necesitamos añadir el repositorio de helm para cert-manager:

helm repo add jetstack https://charts.jetstack.io

Ahora procederemos a crear el nuevo namespace y hacer el deploy de cert-manager:

kubectl create ns cert-manager
helm upgrade --install cert-manager 
  --namespace cert-manager 
  --version v1.0.3 
  jetstack/cert-manager 
  --set installCRDs=true

Dale unos segundos de margen para que termine y deberías ver un mensaje de finalización con éxito.

Creando un ClusterIssuer

Podemos usar tanto un Issuer como un ClusterIssuer (namespace vs cluster-scoped). Es exactamente lo mismo, solo cambia el scope. El Issuer/ClusterIssuer representa la CA de la que queremos obtener el nuevo certificado, en este caso usaremos LetsEncrypt.

Fíjate a continuación que el objeto ClusterIssuer realmente es muy simple. Tanto el nombre como el nombre del secret pueden ser lo que tú quieras:

apiVersion: cert-manager.io/v1alpha3
kind: ClusterIssuer
metadata:
  name: my-cluster-issuer
spec:
  acme:
    email: {{ tu email }}
    privateKeySecretRef:
      name: my-cluster-issuer
    server: https://acme-v02.api.letsencrypt.org/directory
    solvers:
      - http01:
         ingress:
           class: nginx

Expidiendo un nuevo certificado

Vamos a hacer un deploy muy simple con un nginx, lo expondremos como servicio y después crearemos un ingress. Así pues, vamos allá:

kubectl create deployment nginx --image nginx:alpine --namespace test
kubectl expose deployment nginx --port 80 --target-port 80 --namespace test

Ahora crearemos un nuevo objeto ingress para hacer accesible el servicio a través del ingress controller. Recuerda reemplazar a continuación las ocurrencias del host con tu propio dominio:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
  labels:
    app: nginx
  name: nginx
  namespace: test
spec:
  rules:
  - host: nginx.{{ tu dominio }}
    http:
      paths:
      - backend:
          serviceName: nginx
          servicePort: 80
        path: /
  tls:
  - hosts:
    - nginx.{{ tu dominio }}
    secretName: nginx-certificate

Aplicamos el nuevo manifest:

kubectl apply -f ingress.yaml

Si ahora intentas acceder al host que has definido en el ingress verás un mensaje de error conforme tu certificado no es válido («Your connection is not private»). Para solucionarlo, vamos a expedir un nuevo certificado. Edita el ingress que has creado y añade la siguiente anotación, reemplazando el valor por el nombre que hayas puesto en tu ClusterIssuer:

cert-manager.io/cluster-issuer: my-cluster-issuer

Aplica el ingress de nuevo (o guarda los cambios si estás haciendo un edit) y revisa el estado del objeto «cert». Deberías ver algo así:

kubectl get cert -n test

NAME                READY   SECRET              AGE
nginx-certificate   False   nginx-certificate   21s

Ahora espera 1 o 2 minutos y cuando lo revises de nuevo…

kubectl get cert -n test

NAME                READY   SECRET              AGE
nginx-certificate   True    nginx-certificate   93s

… ¡hemos conseguido el certificado! Haz un test refrescando la página o abriendo una nueva pestaña y deberías ver el mensaje de bienvenida de Nginx. Si inspeccionas el certificado, verás que efectivamente éste ha sido expedido por LetsEncrypt:

Resumiendo

Lo que hemos visto aquí es:

• Como instalar cert-manager
• Como configurar un nuevo ClusterIssuer
• Como expedir de forma sencilla un certificado

En líneas generales ha sido un proceso simple, ¿verdad? Es más, cuando sabes cómo funciona es muy fácil replicar este setup en cualquier clúster en cuestión de unos pocos minutos.

Cert-manager se encargará de la renovación de tus certificados. También puedes crear otros Issuers o ClusterIssuers que soporten otros CA o usar otros métodos de validación (DNS), pero eso es un tema algo más avanzado que dejaremos para más adelante.

Espero que hayas disfrutado con este how-to y que haya resultado útil. Recuerda que si necesitas cualquier cosa estaremos encantados de escucharte. ¡También puedes revisar nuestro blog para encontrar otras publicaciones útiles como ésta!

La entrada Cómo instalar cert-manager con validación HTTP en Kubernetes se publicó primero en Geko Cloud.

Brotli es un método de compresión desarrollado por Google y lanzado en 2015. En función del escenario, brotli es capaz de conseguir una mejora en la tasa de compresión de entre un 20 y un 30% sobre gzip, que es el método de compresión por defecto.

Configuración del ingress-nginx

Para crear el ingress-nginx en función de nuestro proveedor, podemos seguir la documentación del siguiente enlace:

https://kubernetes.github.io/ingress-nginx/deploy/

La configuración del ingress-nginx puede hacerse a través de los Annotations, con un ConfigMap o con una plantilla personalizada.
En el siguiente enlace podemos comprobar qué parámetros pueden modificarse con cada una de las formas:

https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/

En este caso, para modificar el método de compresión, tendremos que emplear el ConfigMap.
El método de compresión por defecto es gzip, con un nivel de compresión de 1. Para habilitar y configurar la compresión brotli, disponemos de tres parámetros: enable-brotli, brotli-level y brotli-types.

• enable-brotli: true o false. Permite habilitar la compresión brotli.
• brotli-level: nivel de compresión. Puede tomar valores entre 1 y 11, por defecto es 4. A mayor nivel de compresión, más agresivos serán los algoritmos para comprimir los ficheros, consiguiendo menores tamaños, pero a cambio será más costoso computacionalmente.
• brotli-types: tipos MIME que serán comprimidos al vuelo por brotli.

Aplicando los cambios

Ejecutando el siguiente comando, listaremos los ConfigMap del ingress-nginx:

kubectl get cm -l app.kubernetes.io/name=ingress-nginx -A

El parámetro ‘-A’ nos lista los recursos de todos los namespaces, dado que en función del proveedor que estemos usando, el namespace puede variar. La salida del comando sería algo así:

NAMESPACE     NAME                          DATA   AGE
my-namespace  ingress-nginx-configuration   0      14d
my-namespace  ingress-nginx-tcp-services    0      14d
my-namespace  ingress-nginx-udp-services    0      14d

El ConfigMap que debemos modificar es ingress-nginx-configuration.
Para ver el contenido actual del ConfigMap, ejecutaremos el siguiente comando:

kubectl get cm ingress-nginx-configuration -n my-namespace -o yaml

En este caso deberemos especificar el namespace donde está desplegado el ingress-nginx.

Podemos editar este ConfigMap de forma directa, pero en este caso crearemos un fichero yaml para luego aplicarlo.

configmap.yaml:

apiVersion: v1
kind: ConfigMap
metadata:
  name: ingress-nginx-configuration
data:
  enable-brotli: "true"
  brotli-level: "6"
  brotli-types: "text/xml image/svg+xml application/x-font-ttf image/vnd.microsoft.icon application/x-font-opentype application/json font/eot application/vnd.ms-fontobject application/javascript font/otf application/xml application/xhtml+xml text/javascript application/x-javascript text/plain application/x-font-truetype application/xml+rss image/x-icon font/opentype text/css image/x-win-bitmap"

Nota importante: todos los parámetros del ConfigMap deben ser cadenas de texto y, por lo tanto, deben estar entrecomillados.

Una vez tengamos el fichero configmap.yaml creado, con los valores deseados de los parámetros, lo aplicaremos ejecutaremos el siguiente comando:

kubectl apply -f configmap.yaml -n my-namespace

Tenemos que asegurarnos de aplicar el ConfigMap en el mismo namespace donde tengamos desplegado el ingress-nginx.

Comprobación

Finalmente comprobaremos que hemos aplicado correctamente los cambios, mostrando de nuevo el contenido del ConfigMap de configuración del ingress-nginx:

kubectl get cm ingress-nginx-configuration -n kube-system -o yaml
apiVersion: v1
data:
  brotli-level: "6"
  brotli-types: text/xml image/svg+xml application/x-font-ttf image/vnd.microsoft.icon
    application/x-font-opentype application/json font/eot application/vnd.ms-fontobject
    application/javascript font/otf application/xml application/xhtml+xml text/javascript  application/x-javascript
    text/plain application/x-font-truetype application/xml+rss image/x-icon font/opentype
    text/css image/x-win-bitmap
  enable-brotli: "true"
kind: ConfigMap
metadata:
  annotations:
    ...

Con la compresión brotli activada, al realizar una petición a alguna web expuesta a través del ingress-nginx, en la cabeceras de respuesta recibiremos algo como lo siguiente:

¡Y listo!

Esperamos que te haya sido útil este post, no olvides que el equipo DevOps de Geko está a tu disposición. Contáctanos si tienes cualquier duda.

La entrada Cómo habilitar la compresión Brotli en un ingress-nginx se publicó primero en Geko Cloud.