Introducción a Kubernetes [Parte 1]: Arquitectura

Este blog está dirigido principalmente a profesionales de tecnología que conocen poco de Kubernetes. Por eso, consideré apropiado comenzar una serie de titulada Introducción a Kubernetes. En esta parte comenzaré hablando de la arquitectura y componentes de Kubernetes.

Kubernetes es un sistema “open source” para automatización de configuración y manejo de contenedores. La lista de componentes es como sigue:

  • “Pods”: Este es el elemento más pequeño de Kubernetes. El término en inglés “pod” significa vaina, como las vainas de guisantes. Muy apropiado, ya que, así como una vaina puede contener varios guisantes, cada “pod” puede contener varios contenedores. Los contenedores dentro del “pod” comparten todos los recursos, incluyendo número de dirección IP. Cada “pod” solo puede tener un número de dirección IP.
  • Nodos “master” y “worker”: Estos servidores tienen instalado alguna tecnología de contenedores y kubelet, esto es Kubernetes. Hay dos clases de nodos, el “master” y el “worker”.
    • Nodos “master” : Este nodo es un servidor Linux con Kubernetes instalado que administra el “cluster” de Kubernetes. Para administrar el cluster de Kubernetes utiliza base de datos etcd, kube-apiserver, kube-scheduler, kube-controller-manager y cloud controller-manager. En producción, la única función del nodo “master” es la administración y manejo de nodos “workers” y no opera los “pods” con contenedores para las aplicaciones del usuario.
      • kube-apiserver: Este es el corazón de Kubernetes. Todos los comandos de manejo de Kubernetes son enviados a este componente. Este es el único componente que se comunica con la base de datos etcd.
      • etcd: Este es el componente que guarda la configuración de todos los componentes de Kubernetes.
      • kube-scheduler: Este componentes se encarga de distribuir los “pods” entre los nodos de Kubernetes.
      • kube-controller-manager: Este componente se asegura de que el estado del cluster esté en conformidad con las configuraciones del “cluster” de Kubernetes. Cuando detecta un diferencia, escala los pods de alguna aplicación de acuerdo a su configuración.
      • cloud-controller-manager: Maneja configuraciones específicas a tecnologías en la nube (por ejemplo: Azure, AWS, etc.).
    • Nodos “worker”: Estos nodos son los que operan los “pods” con las aplicaciones del usuario. kubelet interactúa con software de contenedores como Docker y es el componente que se comunica con kube-apiserver sobre la condición de los pods en el nodo. kube-proxy maneja la conectividad con la red.
    • Servicios: Expone una aplicación que se ejecuta en un grupo de “pods” como un servicio de red. Distribuye el tráfico a los “pods” de acuerdo a su configuración. Por ejemplo: uno de los servicios que se configuran en zalando/postgres-operator se asegura de que se comunique con el pod “master”, o el único pod que acepta inserción y actualización de datos.
    • “Namespace”: Cada uno de los elementos que se crean en Kubernetes deben habitar en una agrupación abstracta llamada “namespace”. Los privilegios a los usuarios y las cuentas de servicios pueden ser restringidos por “namespace”.
    • Red: Dentro de Kubernetes existe una red virtual. Los diferentes elementos de Kubernetes tienen restringido la comunicación de acuerdo con las políticas de red asignadas en conjunto con los roles que tengan vinculados en determinados “namespace”.
    • Almacenamiento: Volúmenes persistentes y sus reclamaciones permiten que los datos importantes que residan en la aplicación sobrevivan al volátil “pod” cuando este es removido.

Esta es una descripción básica de lo que es Kubernetes. En siguientes artículos seguiré compartiendo mas sobre como opera Kubernetes. Para más información, puede ir a la página oficial de documentación de Kubernetes.

Cómo instalar un cluster de PostgreSQL en K8s

Instalar PostgreSQL en K8s es sumamente fácil, manejar PostgreSQL, es otra historia. Para instalar y manejar PostgreSQL en K8s se debe utilizar un operador que automatice las operaciones de replicación y administración. Hay varios operadores com Crunchy Data y KubeDB, el que yo utilizo es el operador de Zalando. (https://github.com/zalando/postgres-operator) Debe instalarlo desde su terminal en Linux o “Powershell” en Windows. Debe tener instalado git, helm y Kubernetes para poder seguir el siguiente tutorial de como instalar PostgreSQL. Si tiene instalado Minikube es suficiente. Con los pre-requisitos instalados, utilizar “zalando/postgres-operator” es sencillo con los siguientes pasos:

  1. Descargue el código de GitHub con el siguiente comando: git clone https://github.com/zalando/postgres-operator.git
  2. Posiciónese dentro de la carpeta que descargó: cd postgres-operator
  3. Instale el operador: helm install charts/postgres-operator/
  4. Instale el “cluster”de PostgreSQL: kubectl create -f manifests/minimal-postgres-manifest.yaml
  5. Verifique que todo esté bien: kubectl get pods -l application=spilo -L spilo-role

Así de sencillo, ya tiene un cluster de postgreSQL en K8s.

Instalar minikube en Windows 10

Minikube es una version portátil de Kubernetes que se puede instalar en cualquier PC. La instalación es simple. Siga los siguientes pasos:

  1. Instalar VirtualBox.
  2. Instalar Chocolatey. Ejecute el siguiente commando de powershell como administrador: Set-ExecutionPolicy Bypass -Scope Process -Force; iex ((New-Object System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))
  3. Instalar Minikube. Ejecute el siguiente commando de powershell como administrador: choco install minikube
  4. Instalar Helm. Ejecute el siguiente commando de powershell como administrador: choco install kubernetes-helm
  5. Iniciar Minikube. Ejecute el siguiente commando de powershell como administrador: minikube start
  6. Verificar minikube. Ejecute el siguiente commando de powershell como administrador: kubectl get nodes
  7. Iniciar helm. Ejecute el siguiente commando de powershell como administrador: helm init

Con estos pasos tendrá instalado minikube y podrá comenzar a experimentar con kubernetes.

5 cosas a considerar antes de implementar bases de datos en Kubernetes

Docker y Kubernetes (abreviado se le dice K8s) están siendo ampliamente adaptadas en la industria tecnológica. En sus comienzos, K8s y Docker no tenían las funcionalidades necesarias para manejar bases de datos. Los contenedores en Docker son efímeros, aunque Kubernetes ofrece excelente manejo de contenedores, no tiene los mecanismos necesarios para manejar por sí solo lo que necesita para automatizar conmutación por error (failover), configurar cambios en la replicación y procesos únicos en bases de datos.

La comunidad está haciendo un excelente trabajo mejorando y añadiendo funcionalidades a K8s. Crearon volúmenes persistentes para montarlos en los “pods” y así contener datos de manera consistente. Esto es que no se borre cuando se elimine y reemplace un “pod”. Para satisfacer las necesidades particulares de cada aplicación, ahora se puede crear CRD (“Custom Resource Definition” o Definición de Recursos Personalizados). Con CRD, y la habilidad de instalar operadores personalizados en K8s, las comunidades “open source” (código abierto”) han creado diferentes operadores que manejan la automatización de tareas pertinentes a las diferentes tecnologías de bases de datos. ¿Es esto suficiente para implementar bases de datos de producción en K8s?

La opinión de este servidor es que sí, pero no en todos los casos. Yo todavía me retraigo de implementar en K8s bases de datos que se utilicen para operaciones intensas de análisis. Un ejemplo sería una base de datos que cada mes recoja 100 GB de datos para procesarlo, analizarlo y al final producir reportes. Esto sin duda requiere un servidor muy poderoso con muchos recursos. Pero hay otras bases de datos que se utilizan para reportes diarios, guardar contraseñas, y recopilar metadata sobre una aplicación. Estas bases de datos, yo me atrevo a decir que se pueden implementar en K8s, aunque tenga miles de usuarios.

Solo porque se puede implementar bases de datos en K8s, no necesariamente signifique que deba hacerlo. Aquí les tengo mi lista de 5 cosas a considerar antes de implementar bases de datos en K8s:

  1. El personal que diseña la arquitectura de la aplicación debe conocer el uso de las bases de datos que se van a administrar. Si se utilizan para cálculos complejos y procesan grandes cantidades de datos, probablemente K8s no es la solución más adecuada para usted. Asegúrese de que los “pods” de K8s tengan los recursos necesarios para operar con alto rendimiento.
  2. El personal que administra las bases de datos en K8s, debe tener entrenamiento en operar K8s. Es cierto que uno no va a ser experto en todo, pero debe conocer lo suficiente como para pedirle a los ingenieros que operan K8s lo que se necesita para operar las bases de datos. K8s es complejo y dentro del nodo de K8s existen redes, “namespaces”, roles, agentes, volúmenes persistentes, etc. Pudieran adjudicar problemas a limitaciones en K8s que en realidad sea configuración incorrecta. Debe tener expertos en K8s para trabajar los problemas que puedan surgir al operar bases de datos.
  3. Sea experto en la tecnología de bases de datos que va a implementar. K8s no es responsable de las configuraciones internas de PostgreSQL, ScyllaDB o cualquier otra base de datos. Eso es responsabilidad del administrador de bases de datos.
  4. Asegúrese de que el hardware de los nodos de K8s sea adecuado. Las bases de datos son aplicaciones robustas que requieren discos, CPUs y memoria de alto rendimiento. Si dispone de discos baratos, la aplicación tendrá problemas con el rendimiento y no será culpa de K8s.
  5. Utilice un buen operador personalizado para manejar bases de datos. K8s no maneja replicación entre “pods”, seleccionar el “pod” que servirá de primario, automatizar conmutación por error (failover) cuando un “pod” falla, etc. Hay varios operadores y no todos funcionan igual. Analice bien las opciones que tenga y elija el que más le convenga. Aquí hay una lista de operadores con buena reputación en la industria:
    1. Stolon (PostgreSQL)
    2. Zalando\postgresq-operator y patroni.
    3. KubeDB
    4. Scylla-operator todavía no está en producción, pero es prometedor.

En resumen, automatizar el manejo de bases de datos no es asunto de lanzarlo en K8s y asumir que todo va a ser automático. Igual que todo en la vida, requiere destreza, planificación y estrategia. Esa inversión vale la pena ya que puede lograr alta disponibilidad y estará más cerca de realizar ese elusivo “cero interrupción de servicio”.