Cluster de kubernetes con AWS EKS Explicado.

16 junio, 2020

Con el aumento de uso de servicios en la nube, existen diferentes alternativas para desplegar un cluster de kubernetes en los distintos proveedores del mercado. En el siguiente artículo vamos a crear un cluster de kubernetes en AWS utilizando eksctl pero intentaremos explicar las configuraciones avanzadas que se podrían utilizar.

Antes de continuar debe considerar que la creación del cluster eks considera un costo de 0.1 usd x hora mas las instancias EC2 hora que utilice. Por tanto si realiza esta prueba y no quieres sorpresas, tendrás que ejecutar el comando para eliminar el cluster.

Para evitar problemas en la ejecución, haremos el paso a paso con una instancia EC2 nueva, por tanto para evitar errores te recomiendo la siguiente AMI.

Asumiendo que usted ya tiene una cuenta en AWS con permisos suficientes para crear un cluster EKS, ejecute los siguientes comando para instalar las herramientas necesarias:

1. Instalación de herramientas necesarias para crear EKS:

sudo yum install python3 -y
pip3 install awscli --upgrade --user

Luego ejecute aws configure e ingrese su key id y secret necesario.

aws configure

Descargar eksctl que utilizaremos para crear el cluster de kubernetes en EKS

curl --silent --location "https://github.com/weaveworks/eksctl/releases/download/latest_release/eksctl_$(uname -s)_amd64.tar.gz" | tar xz -C /tmp

Mover binario

sudo mv -v /tmp/eksctl /usr/local/bin

Instalar autocompletar de eksctl

eksctl completion bash >> ~/.bash_completion . /etc/profile.d/bash_completion.sh . ~/.bash_completion

Instalar kubectl

Este es la herramienta que nos permite conectarnos con kubernetes que crearemos con eksctl

sudo curl --silent --location -o /usr/local/bin/kubectl https://amazon-eks.s3.us-west-2.amazonaws.com/1.16.8/2020-04-16/bin/linux/amd64/kubectl

Permisos de ejecución a binario de kubectl

sudo chmod +x /usr/local/bin/kubectl

2: Crear el cluster

Si bien eksctl tiene opciones de crear cluster en una solo línea de comando, de manera muy simple como por ejemplo “eksctl create cluster”, pero dado que tiene muchas cosas por defecto, en este ejemplo veremos la utilización de un archivo de despliegue del tipo yaml incorporando varias opciones que nos provee EKS.

En el siguiente repositorio queda el archivo para crear el cluster

Para crear el cluster eks, edite el archivo eks-test.yaml y ejecute lo siguiente. Tenga paciencia que su creación tarda más de 10 minutos.

eksctl create cluster -f eks-test.yaml

Luego, para configurar kubectl ejecute lo siguiente

aws eks --region us-east-1 update-kubeconfig --name eks-test

Ahora puede ejecutar comandos kubectl

3. Explicación.

A continuación vamos a explicar las distintas secciones del archivo:

VPC:

En la sección VPC, subnet es posible indicar cuál será las zonas de disponibilidad de las subnet pública donde estará disponible los nodos del cluster, si bien el ejemplo considera red pública, también puede ser privada cambiando o agregando un nuevo tag “private”

En caso de querer ejecutar recuerde cambiar los id de las subnet por los suyos.

Node Groups

En tag nodeGroups describe el grupo de nodos que utiliza el cluster, donde puede tener uno o más grupos de nodos con configuraciones distintas. Por ejemplo podrías tener instancias del tipo spot y otras del tipo ondemand.

Si bien también existe la posibilidad de crear el grupo de nodos autoadministrado con el tag “managedNodeGroups” en este ejemplo preferí utilizar no administrado por que tiene más opciones de configuración. Cabe destacar que puedes tener nodos administrados y no administrados a la vez.

Node groups / tags

Kubernetes y EKS utilizan mucho los tags en sus configuraciones. Si bien en este ejemplo no vamos a configurar el escalo de nodos, los últimos dos tags serían necesarios.

Node groups / instanceType

Aquí puede indicar el tipo de instancias que utilizará cada nodo, si este valor no es seteado el valor por defecto es m5.large. En caso de utilizar instancias spot éste tag debería cambiarlo por tag instancesDistribution.

Node groups / Tamaño del grupo

En caso de configurar autoescalado de nodos, es necesario indicar los límites del grupo de nodos, tanto mínimo como máximo. El valor de desiredCapacity es opcional y significa la cantidad de instancias que iniciará el grupo.

Node Groups / kubeletExtraConfig

Desde mi punto de vista encuentro esta configuración una de las más importantes ya que aquí aseguramos un capacidad reservada de cada nodo para realizar tareas administrativas como permitir o quitar pods o mantener el nodo en un estado saludable. Si bien según la documentación eksctl considera valores por defecto, en su documentación no logre encontrar sus valores.

En kubeReserved indicamos la CPU, memoria y espacio reservado para los demonios de kubernetes como kubelet. kubeReservedCgroup indica el grupo de reserva, en systemReserved indicas las cpu, memoria y espacio en disco reservado para el sistema operativo. En evictionHard se indica desde cuando comenzar a desalojar pod según límite de memoria o disco. En featureGates el RotateKubeletServerCertificate es obligatorio si queremos cambiar estas configuraciones.

Node Groups / SSH

En la opción de ssh, puede indicar si se permite o no acceso ssh y cuál sería su par de clave para acceder.

Volumen Size y Red Privada

Aquí puede cambiar el tamaño de volumen por defecto que tendrá cada instancia del nodo. Además podrá indicar si éste grupo de nodos pertenecerá a una red privada o no. Si en la sección de VPC indicó alguna red privada y si aquí habilita la opción red privada, entonces los nodos se crearán en dichas subnet.

Node Groups / Label

Esta opción permite crear un label para cada nodo, esto es útiles si queremos indicar que ciertos nodos sea solo para algunos PODs.

Node Groups / asgMetricsCollection

Con asgMetricsCollection permite crear métricas en CloudWath sobre para el escalado automático.

Node Groups / iam

Considero que este tag es tambíen unos de los más importante, ya que faculta a los nodos a contar con permisos para interactuar con otras cosas de AWS. Por ejemplo si necesitamos que desde los nodos se haga push a ECR será necesario habilitar imageBuilder o bien si se necesita enviar log a cloudWatch es necesario habilitarlo.

CloudWatch