Kubernetes & Cloud | Primeros pasos

Explica: Freddy Condori Chavez, Expert DevOps Engineer

12 min readDec 29, 2022

Introducción

El objetivo de este artículo es presentar, como pruebas de éxito, diferentes experiencias que se experimentaron en mi vida cotidiana como profesional en sistemas, dando una breve descripción de cómo se realizaron varias tareas.

Con cada punto el artículo describe diferentes casos, implementaciones en data center propios o servidores on-premise y ejecución en la nube, en diferentes proveedores del mercado.

Primeros pasos con Kubernetes

Es habitual trabajar con un mix de tecnologías para resolver diversos problemas, uno de los tips habituales para la resolución de problemas es adquirir conocimiento en tecnologías que tienen relevancia en el mercado actual.

En esta oportunidad te cuento sobre Kubernetes, la tecnología para orquestar microservicios en contenedores, la cual implica conceptos a nivel de infraestructura y Kubernetes, en servidores on-premise y en proveedores en la nube.

1.1 Servidores On-Premise

En un servidor on-premise (o instalación propia) es posible instalar Kubernetes, existen varias opciones que se pueden utilizar para dicha instalación, por ejemplo: OpenShift, K3s o MicroK8s.

K3s y MicroK8s considero que son las mejores alternativas para iniciar este camino, por lo que a continuación te cuento más detalles:

K3s es desarrollado por Rancher y se caracteriza principalmente por ser ligero, facilita binarios para la instalación y puede configurarse con bases de datos SQLite, MySQL o Postgresql. Puede ser instalado en máquinas virtuales con sistemas operativos GNU Linux como Debian, Ubuntu o Fedora.

Las instalación depende mucho del sistema operativo que se elija, muchas veces es necesario lidiar con SELinux en el caso de Fedora, con AppArmor o IPTables para Debian o Ubuntu. Una prueba común con K3s es virtualizar tres máquinas donde podemos simular un nodo master y dos nodos worker.

MicroK8s es un Kubernetes que se puede ejecutar desde una computadora personal con GNU Linux de forma fácil, además es posible ejecutar comandos kubectl pero solo cuenta con un nodo worker (simula un nodo).

Cuenta con un registro de docker para que se pueda crear e implementar fácilmente contenedores en el sistema; es muy útil para realizar pruebas en local. Como punto adicional, probamos agregar nuevos nodos worker utilizando máquinas virtuales con virtualbox, teniendo que editar scripts y modificar hostnames para poder agregarlos.

1.2 Bases de Datos

ETCD es el almacén de datos tipo clave-valor que permite la configuración compartida, la detección de servicios y la coordinación del programador de clusters, es un elemento fundamental para los clusters de Kubernetes; también almacena y replica los estados de los clusters y se caracteriza por su tolerancia a fallas, donde maneja el almacenamiento de clave-valor en directorios organizados jerárquicamente.
DQLITE es otra alternativa como almacén de datos, utiliza SQLite como su administrador de almacenamiento interno y se caracteriza por ser rápida. Se utiliza para micro nubes y dispositivos IoT, con tolerancia a fallas.

K3s puede utilizar SQLite como almacén de datos y MicroK8s puede utilizar DQLITE, por defecto ambas opciones vienen preconfiguradas.

1.3 Prueba de concepto — Raspberry Pi + K3S

Para realizar una prueba, fue necesario conocer los detalles que se mencionaron anteriormente y elegimos probar K3s como sistema base para Kubernetes.

En la prueba simulamos el funcionamiento simple de un cluster en un ambiente de producción, donde se tenía un nodo server y tres nodos worker, se pudo ejecutar comandos kubectl o realizar deploy en base a documentos yaml.

Para crear nuestro cluster el hardware no era muy potente, por este motivo elegimos utilizar K3s.

Lo principal que se utilizó fue hardware para red y almacenamiento, durante las pruebas se quemó un placa Raspberry por la falta de refrigeración, pero no adquirimos ventiladores, optamos por detectar el problema de sobrecalentamiento.

Un network hub de 8 puertos.
Un Raspberry Pi 3, modelo B, 1GB de ram.
Tres Raspberry Pi 4, modelo B, 4GB de ram.
Cuatro memorias SD, 32 GB.
Sistema operativo Raspbian, basado en Debian Bullseye.

Para la instalación utilizamos la documentación oficial de Rancher — K3s, con la característica de que el Nodo Server fue instalado en el Raspberry Pi 3, luego se crearon los nodos worker en los Raspberry Pi 4.

1.4 Observaciones

Refrigeración: Al realizar el montaje, instalación y configuración del cluster de prueba, se notó que presenta sobrecalentamiento en el MicroSD de almacenamiento, chipsets y procesador de las placas Raspberry Pi. El cluster puede ejecutar un número reducido de pods sin sobrecalentar las placas, por lo que es importante buscar que los pods estén distribuidos de forma equitativa en cada nodo worker.
Etcd: Al utilizar memorias MicroSD no fue posible instalar este almacén de datos, es necesario adquirir discos duros SSD y realizar configuraciones extra para adicionar este hardware como almacenamiento para los Raspberry Pi.
Actualizaciones: Intentamos simular un ambiente on-premise donde todo el control del sistema y el hardware es responsabilidad del área de sistemas de una empresa, instalar un Kubernetes propio implica realizar nuevas actualizaciones, agregar nuevas funcionalidades en base a nuevas versiones y generar políticas para ejecutar actualizaciones.
Mantenimiento: Si existe alguna falla en hardware por algún motivo, como refrigeración, existen nuevas necesidades para el hardware, esto es presupuesto adicional de compra, implementación de sensores de calor, proveedores de internet o energía eléctrica redundante, que en un data center se debe cumplir como requisito mínimo y obligatorio.
Seguridad: No se debe dejar de lado la seguridad en los sistemas y que la instalación de software y hardware se ejecuten de forma óptima, pero para asegurar que nuestro Kubernetes sea seguro debemos implementar sistemas de seguridad o hardware específico y así proteger de ataques maliciosos.

2. Soluciones en la Nube

Los proveedores en la nube son opciones que muchas empresas y profesionales recomiendan para facilitar soluciones actuales de costo competentes, los mismos cuentan con documentación apropiada y actualizada.

Muchos conservan la incertidumbre de la soberanía en sus datos, pero actualmente los proveedores en la nube presentan soluciones adaptables en la mayoría de los casos, aunque no siempre al 100%, no dejan de ser una buena opción.

Entre los proveedores más grandes y conocidos en el mercado:

AWS Elastic Kubernetes Service — EKS.
Azure Kubernetes Service — AKS.
Google Cloud Kubernetes.

y entre los proveedores conocidos pero no tan grandes están:

Digitalocean Kubernetes.
Linode Kubernetes Engine — LKE.

Cada proveedor presenta diferentes formas de cobro, on-demand, almacenamiento reservados por tiempo y infraestructura basada en el tipo de recurso que se compre o utilice.

En nuestra experiencia vamos a utilizar AWS EKS para desarrollar este punto.

2.1 Infraestructura en la Nube

A diferencia de una infraestructura on-premise, la nube presenta una nueva forma de diseñar la infraestructura, donde prácticamente se delegan varias tareas al proveedor y el profesional en IT sólo ejecuta órdenes en base a los recursos que necesita utilizar.

En AWS como en otros proveedores es posible desplegar la infraestructura desde cero, al inicio necesitamos una red donde los recursos y/o servicios puedan comunicarse y luego identificamos los productos que vamos a utilizar para ejecutar los servicios necesarios para Kubernetes.

El objetivo principal es desplegar la infraestructura necesaria para ejecutar Kubernetes, esto implica utilizar diferentes recursos del proveedor AWS.

2.2 Recursos AWS para la Infraestructura

AWS Virtual Private Cloud — VPC: Este producto tiene como fin establecer el servicio red, que puede ser definida como red interna y externa de la infraestructura, donde también se definen rutas, NAT, DHCP, gateways entre otros.

Un detalle importante para la infraestructura en VPC es cumplir con los siguientes requisitos:

Tener habilitado los DNS Hostname, enable_dns_hostnames = true, esto es necesario para manejar nombres de dominio con AWS Route 53.
Habilitar el soporte DNS, enable_dns_support = true, necesario para soporte con AWS Route 53.
Y también habilitar el NAT Gateway, enable_nat_gateway = true, necesario para la traducción de direcciones de red y facilitar las instancias de una subred privada pueda conectarse a servicios fuera de la VPC.

Al definir como “true” estos atributos, el VPC podrá asociar nombre de dominio y subdominios.

Nuestra VPC también debe estar con las etiquetas (tags) correspondientes, esto es necesario si en la misma existen varios clusters EKS, un ejemplo sería:

kubernetes.io/cluster/EKS_NAME = shared (Tags para VPC, Private Subnet).
kubernetes.io/role/internal-elb = 1 (Tags para Private Subnet).
kubernetes.io/role/elb = 1 (Tags para Public Subnet).

También se debe crear reglas de porteo, son necesarios dos reglas importantes, una para el cluster y otra para los nodos, estas reglas en AWS se denominan Security Groups (Grupos de Seguridad) y manejan reglas de entrada y salida (inbound — outbound).

Para las reglas del cluster EKS se recomienda crear reglas de entrada para protocolos HTTP (80) y HTTPS (443), para las reglas de entrada de los nodos es necesario tener identificados que puertos serán utilizados, pero como configuración inicial podemos asignar entradas y salidas a todo para direcciones IP que corresponden a la VPC.

AWS Identity and Access Management — IAM: Es el control de recursos de AWS, el mismo controla de forma segura quien o que está autenticado o autorizado para utilizar los recursos, con IAM se debe crear reglas y políticas necesarias para utilizar los recursos de Elastic Compute Cloud — EC2 (análogo a máquinas virtuales) y Elastic Block Store — EBS para almacenamiento persistente.

AWS Elastic Kubernetes Service — EKS: Es el servicio para ejecutar Kubernetes en AWS sin la necesidad de realizar instalaciones de los ejecutables de Kubernetes. Se encarga de facilitar la operación y mantener su propio plano de control o nodos de Kubernetes.

Inicialmente es necesario crear un cluster EKS y asociar instancias EC2 que serán parte de los nodos worker, estos ejecutan el software necesario para gestionar los contenedores que serán parte de un pod, donde AWS también propone usar AWS Fargate, para reducir costos.

Crear la infraestructura específica para Kubernetes no lleva una práctica habitual, existen otros factores que se deben tomar en consideración.

2.3 Complementos, Almacenamiento y otros

Se puede notar que se utilizan recursos AWS explícitos como instancias EC2, EBS o también EKS CNI Addon, estas deben cumplir ciertos requisitos:

AWS EC2 Optimized: A diferencia de una instancia EC2 normal, una optimizada está vinculada a cómputo y beneficia de procesadores de alto rendimiento, estas son adecuadas para procesamiento por lotes y alto rendimiento.

Algo adicional que es necesario, es la creación de plantillas que se denominan Launch Template las cuales permiten agregar funciones adicionales a las instancias EC2 en general, con ellas se puede definir nombres de disco duro, interfaces de red, etiquetas y memoria.

AWS EBS: Es un servicio de almacenamiento en bloque, escalable y de alto rendimiento, diseñado para instancias EC2, esto facilita la persistencia de datos en las instancias cuando existen actualizaciones y cambios de capacidad, desplegándose nuevas instancias y eliminando las viejas, por este motivo existe EBS, una forma de almacenamiento independiente a la instancia.

Este recurso también necesita de controladores o drivers que se deben configurar dentro de AWS EKS, esto se menciona más adelante como configuraciones importantes para Kubernetes.

EKS CNI Addon: Es un complemento que proporciona capacidades de soporte a aplicaciones de Kubernetes, en específico EKS CNI siendo un complemento de red para pod en clusters de EKS, este asigna direcciones IP de la VPC a los nodos de Kubernetes y para EKS CNI es necesario crear permisos IAM donde también se debe establecer un Assume Role, qué es la forma de definir qué recurso puede utilizar a otro.

2.4 Herramientas AWS

AWS facilita diferentes herramientas propias para poder gestionar y configurar sus recursos, la principal es AWS Console una interfaz web donde se puede visualizar y manipular los recursos de AWS de forma gráfica y sencilla.

AWS Command Line Interface — AWS Cli: Es una herramienta de código abierto que permite interactuar con los servicios de AWS, facilita la ejecución de comandos en una terminal Linux o DOS, dependiendo del sistema operativo que se utilice.
ECKCTL: Es otra herramienta de línea de comandos para trabajar con clusters EKS que automatiza varias tareas individuales, es más fácil crear un cluster EKS con EKSCTL que con AWSCLI.

3. Configuración para Kubernetes

Kubernetes también necesita de configuraciones importantes, es necesario agregarlas en base a un funcionamiento básico de la misma.

3.1 Ingress Controller

Un Ingress Controller en Kubernetes es un tipo de Balanceador de Carga, considerado también un proxy básico, que permite redirigir los request a distintos pods en el clúster. Esto se puede definir como un archivo YAML.

También existen los denominados Ingress Controller completos que están desarrollados en Go language y utilizan como base Nginx para crear reglas Forwarding o redirects, el mismo se puede instalar en kubernetes con herramientas adicionales, un Ingress Controller conocido es Ingress Nginx.

3.2 Certificate Manager

Con un VPC configurado con los requisitos necesarios, este punto se tiene cubierto, porque básicamente solo es la compatibilidad del servicio AWS Route 53 y también del Amazon Certificate Manager — ACM.

3.3 AWS EBS CSI Driver

Un problema habitual es que Kubernetes no puede utilizar el recurso EBS, por más que se hayan creado los permisos necesarios en IAM, para resolver este problema se debe instalar drivers adicionales para que Kubernetes pueda utilizar el recurso en los contenedores de cada pod, el driver tiene como nombre AWS EBS Container Storage Interface — CSI, donde permite utilizar EBS como volúmenes para persistencia de datos. Para realizar una prueba rápida AWS facilita este ejercicio de deploy.

Un detalle importante es declarar un archivo YAML para definir un storage class, para poder especificar un storage provisioner, el tipo de almacenamiento que por lo general es GP2.

4. Herramientas para Infraestructura como Código — IaC

Para facilitar el trabajo de despliegue y aplicando las buenas prácticas para infraestructura como código, existen diferentes opciones que AWS facilita, algunas que no son de mucho agrado en el ambiente laboral, AWS Cloudformation y AWS SDK.

4.1 Terraform

Terraform es una herramienta para gestionar IaC, es desarrollado y mantenido por Hashicorp, maneja una sintaxis simple y fácil de interpretar que se denomina HashiCorp Configuration Language — HCL.

El mismo cuenta con un registry para diferentes proveedores en la nube, donde se los puede definir como providers especificando para nuestro ejemplo AWS.

También podemos definir providers para Kubernetes y poder automatizar la configuración con HCL.

El código terraform puede seguir un orden, primero puede ejecutar el despliegue de la infraestructura en AWS y posteriormente el aprovisionamiento de Kubernetes. Pero como aun así es necesario seguir ejecutando varias tareas, Terraform registry cuenta con un provider muy útil que es Helm, de esta forma podemos aprovisionar con software completo a nuestro clúster.

Con terraform podemos gestionar todo nuestro proyecto solo con HCL y es la mejor contra AWS Cloudformation.

4.2 Terragrunt

Terragrunt es una capa de abstracción adicional que se puede agregar al proceso de ejecución de Terraform, donde se organiza mejor el código del mismo proyecto pero con diferente funcionalidad, permitiendo manejar dependencias y generar archivos para que terraform se organice de forma más óptima.

4.3 Pulumi

Pulumi es un framework que soporta varios lenguajes, esta es una opción importante si es que no deseas utilizar AWS SDK; Pulumi facilita librerías que pueden definir la infraestructura de diferentes proveedores en la nube, entre los principales lenguajes de programación podemos nombrar a GO Lang, Python, Javascript entre otros.

4.4 Kubectl

Kubectl es el programa para línea de comandos que interactúa con el API de Kubernetes, gestiona recursos y despliegues clusterizados, genera archivos de configuración y gestiona todo tipo de operaciones de Kubernetes.

4.5 Helm

Es una herramienta para gestionar aplicaciones Kubernetes, Helm ayuda a dirigir Kubernetes usando charts o mapas de configuración.

5. Referencias

Espero que toda esta información y guía te sea de gran ayuda para iniciarte en el mundo de Kubernetes y Cloud y así potenciar tus capacidades técnicas.

Kubernetes & Cloud | Primeros pasos

Explica: Freddy Condori Chavez, Expert DevOps Engineer

Written by Zenta Group