Blog de Amazon Web Services (AWS)

Kubernetes Auto-gestionado con Amazon EKS-Distro

Por Jhon H. Guzmán, Partner Solutions Architect para Public Sector en AWS

 

Kubernetes, también conocido como K8s, es un sistema de código abierto que permite simplificar la administración y despliegue de aplicaciones en contenedores a través de múltiples hosts. Kubernetes está respaldado por Cloud Native Computing Foundation (CNCF) y le permite configurar y ejecutar aplicaciones en contenedores a escala para ambientes de producción e integrar controladores para configurar redes y almacenamiento para sus aplicaciones.

Sin embargo, administrar Kubernetes y escalarlo es difícil, donde ejecutar clústeres a escala de producción requiere recursos capacitados que dedican una parte significativa de su tiempo a administrar actualizaciones, monitorear y escalar el plano de control, implementar y administrar el ciclo de vida del software operativo, y más. Además, los equipos de operaciones deben asegurarse de que sus cargas de trabajo se implementen de manera segura sin exponerse a vulnerabilidades de seguridad comunes aumentando aún más la sobrecarga operativa de ejecutar Kubernetes por su cuenta. Todo este esfuerzo no genera valor al negocio y es allí donde los clientes de AWS quieren centrarse en sus aplicaciones e ideas que les permitan ofrecer nuevos productos a sus usuarios finales.

Si bien la mayoría de nuestros clientes eligen un servicio administrado por AWS, también hay clientes que tienen necesidades específicas para auto-gestionar Kubernetes en AWS, así que el compromiso de AWS es brindar la mejor experiencia independientemente de lo que elija para ejecutar Kubernetes. En este blog me centraré en las principales características de Amazon EKS Distro (EKS-D) y su proceso de instalación a partir del repositorio que se encuentra publicado a través de Github. La documentación completa de las versiones de EKS-D la puede encontrar en este enlace distro.eks.amazonaws.com.

La seguridad ha sido y será el trabajo cero, donde es importante resaltar que AWS participa activamente en la comunidad de Kubernetes para dar forma al roadmap de seguridad de Kubernetes y además ha adicionado componentes de código abierto para simplificar la implementación y la administración de Kubernetes en AWS dentro de los cuales se encuentran:

kubernetes/cloud-provider-aws Interfaz entre un clúster de Kubernetes y las API de servicios de AWS.
kubernetes/autoscaler Ajusta el tamaño de un clúster de Kubernetes
kubernetes-sigs/aws-ebs-csi-driver Orquestador de Contenedores para administrar el ciclo de vida de los volúmenes de Amazon EBS
kubernetes-sigs/aws-efs-csi-driver Container Orchestrators para administrar el ciclo de vida de los sistemas de archivos de Amazon EFS.
kubernetes-sigs/aws-fsx-csi-driver  Container Orchestrators para administrar el ciclo de vida de los sistemas de archivos de Amazon EFSx.
kubernetes-sigs/aws-iam-authenticator  Una herramienta para usar las credenciales de AWS IAM para autenticarse en un clúster de Kubernetes.
kubernetes-sigs/aws-load-balancer-controller Gestionar Elastic Load Balancers para un clúster de Kubernetes
kubernetes-sigs/aws-encryption-provider Implementación del proveedor de cifrado para kube-apiserver, respaldado por AWS KMS
awslabs/karpenter Solución de gestión del ciclo de vida de los nodos.
aws/eks-distro Distribución de Kubernetes basada y utilizada por Amazon Elastic Kubernetes Service (EKS)

Tabla 1. Componentes de código abierto liberados por AWS

Existen múltiples opciones de implementación para Amazon EKS, desde Amazon EKS en AWS, a AWS Outposts, AWS Local Zones e implementaciones en computo auto-gestionado por el cliente con Amazon EKS Anywhere y Amazon EKS Distro que le permiten a nuestros clientes seleccionar en donde ejecutar Kubernetes.

Figura 1. Opciones de implementación para Amazon EKS

 

¿Que es Amazon EKS Distro (EKS-D)?

Iniciemos por entender que Amazon EKS Distro (EKS-D) es la distribucion de código abierto que potencia a Amazon EKS y a Amazon EKS Anywhere. Por otra parte, es importante saber que AWS realiza un esfuerzo significativo para certificar cada versión de Amazon EKS. Por ejemplo: Tenemos que asegurarnos de que la versión de Etcd, la API de servidor, Controller Manager, Scheduler, y todos los componentes principales de k8s funcionen bien juntos. También se realizan pruebas para asegurar de que cumpla con los criterios de excelencia operativa, en áreas de seguridad, estabilidad y escalabilidad. Amazon EKS Distro es un reflejo de todas esas buenas prácticas y aprendizajes y se encuentra a su disposición para que lo consuma desde una única fuente confiable.

En EKS-D, se encuentran las mismas versiones de Kubernetes y las dependencias implementadas por Amazon EKS. Esto incluye las últimas actualizaciones del upstream de kubernetes, soporte extendido de parches de seguridad y correcciones de backport a versiones compatibles con Amazon EKS. Es importante recalcar que EKS-D sigue el mismo ciclo de lanzamiento de la versión de Kubernetes que usa Amazon EKS.

 

¿Cuál es la diferencia entre Amazon EKS y Amazon EKS-D?

La principal diferencia está en cómo se gestionan. Amazon EKS es una plataforma Kubernetes completamente administrada, mientras que EKS-D está disponible para ser instalado y administrado por usted mismo. Puede ejecutar EKS-D en ambientes On-premise, en la nube o en sus propios sistemas, proporcionando una ruta para tener esencialmente la misma experiencia de Kubernetes de Amazon EKS ejecutándose donde sea que necesite ejecutarla.

Figura 2. Diferencia entre Amazon EKS y Amazon EKS-D

 

Desde el punto de vista de la administración, una vez que EKS-D se está ejecutando, usted es responsable de gestionarlo y actualizarlo. Sin embargo, para los usuarios finales, ejecutar aplicaciones es lo mismo que con Amazon EKS, ya que los dos admiten las mismas versiones de API y el mismo conjunto de componentes.

Desde el punto de vista de componentes, las versiones de EKS-D están en sintonía con las versiones de los componentes utilizados o recomendados para su uso con Amazon EKS a partir de la versión de Kubernetes v1.18.9 e incluyen los siguientes componentes: CNI plugins, CoreDNS, Etcd, CSI Sidecars, aws-iam-authenticator, Kubernetes Metrics Server y el upstream de Kubernetes. Las imágenes de contenedor para estos componentes se basan en Amazon Linux 2 y están disponibles en el registro público de Amazon ECR en arquitecturas amd64 y arm64.

 

¿Cómo inicio la instalación de Amazon EKS-D?

Para iniciar con EKS-D puede construir (Build) EKS-D a partir del código fuente o instalarlo usando kOps u otros métodos de instalación. A continuación, voy a detallar los pasos necesarios para el proceso de instalación de EKS-D usando kOps y los pasos adicionales de despliegue de una aplicación de ejemplo nativa para Kubernetes.

kOps, es una abreviatura de Kubernetes Operations, es un conjunto de herramientas para instalar, operar y eliminar clústeres de Kubernetes desde la línea de comandos. También tiene la posibilidad de realizar una actualización progresiva de una versión anterior de Kubernetes a una nueva versión y administra los complementos del clúster.

Para este blog se usará el servicio de Amazon Cloud9 a través del cual se realizará la configuración de herramientas y repositorios necesarios para la creación del clúster de EKS-D.

 

Arquitectura

La arquitectura para el cluster de Amazon EKS Distro (EKS-D) implementada en este blog tendrá como herramienta central el uso de kOps que se instalará en el ambiente de Amazon Cloud9. A través de los comandos de kOps, se realiza la creación del cluster y el aprovisionamiento de recursos en los servicios de AWS entre los que se encuentran: Amazon S3 para almacenar el Estado del cluster, Amazon EC2 para los recursos de computo del cluster y Amazon Route 53 para la gestión de registros de DNS. Adicionalmente se crearán Roles de IAM para la gestión Identidad y Acceso. Como recursos externos se usará el repositorio publico de EKS Distro en Github y la Galería publica de Amazon ECR.

Figura 3. Arquitectura general para Amazon EKS-D

 

A continuación, detallaré los pasos para la creación y configuración de cada unos de los componentes, la creación del clúster y finalmente el despliegue de una aplicación de ejemplo.

 

Configuración del entorno

Crear Roles de IAM

  1. Siga este enlace para crear el Rol de IAM con acceso de administrador.
  2. Confirme que el servicio AWS y EC2 estén seleccionados, luego haga clic en Siguiente: Permisos para ver los permisos.
  3. Confirme que la política de AdministratorAccess esté seleccionada, luego haga clic en Siguiente: Etiquetas para asignar etiquetas.
  4. Tome los valores predeterminados y haga clic en Siguiente: Revisar para revisar.
  5. Ingrese eksdistro-admin como Nombre y haga clic en Crear rol.
  6. Realice el mismo procedimiento para la creación de los roles de IAM kops-control-plane-role y kops-node-role.

 

Creación del Workspace

Podemos crear el ambiente de AWS Cloud9 de múltiples formas, siguiendo el Workshop de Amazon EKS que lo llevara directamente a pasos en la consola de administración de AWS o creando un Stack simple de AWS Cloudformation como se muestra a continuación:

AWSTemplateFormatVersion: '2010-09-09'
Resources:
                
   KopsCloud9Ide:
    Type: "AWS::Cloud9::EnvironmentEC2"
    Properties:
      Description: "Cloud9 IDE for EKS-D"
      AutomaticStopTimeMinutes: 150
      InstanceType: t2.micro
      Name: eksD-kops-mgmt-cloud9-instance      
 
Outputs:
  Cloud9EnvUrl:
    Description: Cloud9 IDE for EKS-D
    Value: !Sub "https://${AWS::Region}.console.aws.amazon.com/cloud9/ide/${KopsCloud9Ide}"

Cuando este preparado el entorno Cloud9, abra el servicio AWS Cloud9 en la consola en la región donde fue creado, seleccione el entorno y abrir IDE.

Figura 4. Entorno de AWS Cloud9

 

Instalación de herramientas básicas

Actualice el cliente de AWS CLI según las instrucciones de la documentación de AWS. Luego Instale jq, envsubst (desde las utilidades GNU gettext) y bash-complete.

sudo pip install --upgrade awscli && hash -r
sudo yum -y install jq gettext bash-completion moreutils

Instale yq para el procesamiento de yaml

echo 'yq() {
  docker run --rm -i -v "${PWD}":/workdir mikefarah/yq "$@"
}' | tee -a ~/.bashrc && source ~/.bashrc

Verifique que los binarios estén en la ruta y sean ejecutables

for command in jq envsubst aws
  do
    which $command &>/dev/null && echo "$command in path" || echo "$command NOT FOUND"
  done

Asocie el Rol de IAM al ambiente de Cloud9

Haga clic en el botón del círculo gris (en la esquina superior derecha) y seleccione Administrar instancia EC2.

Figura 5. Opción de Manage EC2 Instance

 

Seleccione la instancia, y luego Actions / Security / Modify IAM Role

Figura 6. Modificación de Role de IAM

 

Elija eksdistro-admin en el menú desplegable de Roles de IAM y seleccione Save

Figura 7. Selección de Role de IAM

 

Configuración del entorno de trabajo

Regresando al ambiente de Cloud9 haga clic en el ícono de ajustes (en la esquina superior derecha), seleccione AWS Settings y desactive las credenciales temporales administradas por AWS.

Figura 8. Opciones de configuración de AWS Cloud9

 

Para garantizar que las credenciales temporales estén en su lugar, elimine cualquier archivo de credenciales existente:

rm -vf ${HOME}/.aws/credentials

Configure el AWS CLI con la región actual como predeterminada.

export ACCOUNT_ID=$(aws sts get-caller-identity --output text --query Account)
export AWS_REGION=$(curl -s 169.254.169.254/latest/dynamic/instance-identity/document | jq -r '.region')

Compruebe si la variable AWS_REGION está configurado en la región deseada

export ACCOUNT_ID=$(aws sts get-caller-identity --output text --query Account)
export AWS_REGION=$(curl -s 169.254.169.254/latest/dynamic/instance-identity/document | jq -r '.region')

Almacene los valores de las variables de entorno en el archivo de ~/.bash_profile

echo "export ACCOUNT_ID=${ACCOUNT_ID}" | tee -a ~/.bash_profile
echo "export AWS_REGION=${AWS_REGION}" | tee -a ~/.bash_profile
aws configure set default.region ${AWS_REGION}</p><p>aws configure get default.region

Use el comando de la AWS CLI GetCallerIdentity para validar que el IDE de Cloud9 esté usando el Rol de IAM correcto.

aws sts get-caller-identity --query Arn | grep eksdistro-admin -q && echo "IAM role valid" || echo "IAM role NOT valid"

 

Instalar herramientas para Kubernetes

Los clústeres de Kubernetes requieren los binarios kubectl y kubelet y el binario de aws-cli , aws-iam-authenticator para permitir la autenticación de IAM a su clúster. Ejecute el siguiente comando para realizar la instalación de la herramienta de línea de comandos de Kubernetes, kubectl, para ejecutar comandos en el clúster de Kubernetes.

sudo curl --silent --location -o /usr/local/bin/kubectl \
https://amazon-eks.s3.us-west-2.amazonaws.com/1.20.4/2021-04-12/bin/linux/amd64/kubectl
 sudo chmod +x /usr/local/bin/kubectl

Como se menciono previamente se usará la herramienta de línea de comandos kOps para las operaciones de creación, actualización y eliminación del clúster de Amazon EKS-Distro. El proceso de instalación para Linux es el siguiente:

 
curl -Lo kops https://github.com/kubernetes/kops/releases/download/$(curl -s https://api.github.com/repos/kubernetes/kops/releases/latest | grep tag_name | cut -d '"' -f 4)/kops-linux-amd64
 
chmod +x kops
 
sudo mv kops /usr/local/bin/kops

Verifique que los binarios estén en la ruta /usr/local/bin/, sean ejecutables y se encuentren en la versión deseada:

for command in kubectl kops
do
which $command &>/dev/null && echo "$command in path" || echo "$command NOT FOUND"
done
 
kubectl version --short --client
kops version

 

Creación del Clúster de Amazon EKS-Distro

Una vez se encuentra preparado el ambiente de AWS Cloud9 con las herramientas necesarias puede iniciar con la configuración de las variables de entorno para usar los roles de IAM creados previamente para el clúster.

Se emplearán roles de IAM independientes para cada componente de clúster de Kubernetes. El Rol de IAM kops-control-plane-role se asociará a las instancias de Amazon EC2 que operaran como parte del Control Plane del clúster a través de la variable de entorno CONTROL_PLANE_INSTANCE_PROFILE.  El Rol de IAM kops-node-role se asociará a las instancias de Amazon EC2 que operaran como parte del Data Plane del clúster de Kubernetes a través de la variable de entorno NODE_INSTANCE_PROFILE.

export CONTROL_PLANE_INSTANCE_PROFILE=arn:aws:iam::${ACCOUNT_ID}:instance-profile/kops-control-plane-role
export NODE_INSTANCE_PROFILE=arn:aws:iam::${ACCOUNT_ID}:instance-profile/kops-node-role
 
echo "export CONTROL_PLANE_INSTANCE_PROFILE=${CONTROL_PLANE_INSTANCE_PROFILE}" | tee -a ~/.bash_profile
echo "export NODE_INSTANCE_PROFILE=${NODE_INSTANCE_PROFILE}" | tee -a ~/.bash_profile

Configuración del DNS

Para construir un clúster de Kubernetes con kOps, necesitamos preparar los registros DNS. Existen varios métodos de configuración de los registros de DNS del clúster, para nuestro caso, lo haremos a través del servicio Amazon Route53 creando una zona publica para el subdominio que utilizara el clúster subdomain.example.com.

ID=$(uuidgen) && aws route53 create-hosted-zone --name subdomain.example.com --caller-reference $ID | jq .DelegationSet.NameServers

Este es un componente crítico al configurar el clúster. Si una vez creado el clúster tiene problemas de comunicación con la API de Kubernetes, es probable que haya algún problema con el DNS asociado al clúster.

 

Almacenamiento del Estado del Clúster

Para almacenar el estado y la representación de su clúster, es necesario crear un Bucket de Amazon S3 dedicado al uso de kOps. Este Bucket se convertirá en la fuente para la configuración del clúster. Es recomendable habilitar las características de cifrado y de versionado del bucket de S3 en caso de reversión o recuperación de un estado anterior.

kOps verifica algunas variables de entorno definidas como parte de la configuración de clúster. Debe configurar y exportar KOPS_STATE_STORE  con un bucket de S3 para usarlo como el Estado de kOps y KOPS_CLUSTER_NAME  al subdominio válido controlado por Route53.

export KOPS_STATE_STORE=s3://amazon-kops-cluster-state-${ACCOUNT_ID}-${AWS_REGION}
echo "export KOPS_STATE_STORE=s3://amazon-kops-cluster-state-${ACCOUNT_ID}-${AWS_REGION}" >> $HOME/.bash_profile
 
export KOPS_CLUSTER_NAME=subdomain.example.com
echo "export KOPS_CLUSTER_NAME= subdomain.example.com" >> $HOME/.bash_profile

Clone el repositorio eks-distro para acceder a los scripts de kOps y ubíquese en el directorio de kops:

git clone https://github.com/aws/eks-distro.git
cd eks-distro/development/kops

Antes de iniciar con la ejecución de los scripts para la creación del clúster, puede verificar el contenido de las variables de entorno y los valores que fueron almacenadas en el archivo ~/.bash_profile. El contenido debe ser similar al siguiente:

cat ~/.bash_profile
…
export AWS_REGION=us-east-1
export ACCOUNT_ID=12345678901
export CONTROL_PLANE_INSTANCE_PROFILE=arn:aws:iam:12345678901:instance-profile/kops-control-plane-role
export NODE_INSTANCE_PROFILE=arn:aws:iam::12345678901:instance-profile/kops-node-role
export KOPS_STATE_STORE=s3://amazon-kops-cluster-state-subdomain-us-east-1
export KOPS_CLUSTER_NAME=subdomain.example.com

Ahora puede crear la configuración del Clúster. Si el bucket de Amazon S3 para almacenar el estado de kOps no existe, se creará durante la ejecución de los scripts.

./create_values_yaml.sh
sudo cp /usr/local/bin/kops bin/kops
./create_configuration.sh

El script create_values_yaml.sh crea un subdirectorio con el nombre del clúster subdomain.example.com  y genera el archivo values.yaml  con las variables que contienen (la versión de Kubernetes, clusterName, IAM Roles) y de manera adicional encontrará las referencias a las imágenes de contenedor asociadas a la versión de EKS-D (Kube-apiserver, Kube-controller-manager, Kube-scheduler, Kube-proxy, Metrics-server, aws-iam-authenticator, Pause, y Coredns) que se encuentran como parte de la Galería publica de Amazon ECR.

El script create_configuration.sh emplea la plantilla eks-d.tpl  como base para generar el archivo subdomain.example.com.yaml con la configuración completa del clúster necesaria para el despliegue y crea entre otros: El bucket de Amazon S3 definido en la variable KOPS_STATE_STORE para almacenar allí el estado de la configuración del clúster, las llaves RSA para la eventual conexión vía SSH a las instancias EC2 y el archivo aws-iam-authenticator.yaml para usar las credenciales temporales de AWS IAM y autenticarse al clúster de Kubernetes.

Una vez la configuración del clúster se haya creado correctamente, puede crear el clúster de EKS-D. A través del script create_cluster.sh el cual ejecuta el comando kops update cluster ––admin. Este comando inicia el proceso de aprovisionamiento de recursos en AWS tomando como referencia los archivos y variables de entorno creados previamente.

./create_cluster.sh

El proceso de aprovisionamiento y creación del clúster puede tarde un poco. Utilice el script cluster_wait.sh para verificar a que el clúster esté listo. Una vez el clúster esté listo, este script agregará el autenticador IAM de AWS aws-iam-authenticator.

A través de la consola de AWS puede verificar el aprovisionamiento de los siguientes recursos de AWS

TYPE                    NAME
autoscaling-config      control-plane-us-east-1a.masters.subdomain.example.
autoscaling-config      nodes.subdomain.example.
autoscaling-group       control-plane-us-east-1a.masters.subdomain.example.
autoscaling-group       nodes.subdomain.example.com
 
keypair                 kubernetes.subdomain.example.com-6f:3b:…
instance                control-plane-us-east-1a.masters.subdomain.example.
instance                nodes.subdomain.example.com
instance                nodes.subdomain.example.com
instance                nodes.subdomain.example.com
 
route53-record          api.subdomain.example.com.
route53-record          api.internal.subdomain.example.com.
route53-record          kops-controller.internal.subdomain.example.com.
 
security-group          sg-0f50ff1cff879e539
security-group          masters.subdomain.example.com
security-group          nodes.subdomain.example.com
 
vpc                     subdomain.example.com
dhcp-options            subdomain.example.com
internet-gateway        subdomain.example.com
route-table             subdomain.example.com
 
subnet                  us-east-1a.subdomain.example.com
subnet                  us-east-1b.subdomain.example.com
subnet                  us-east-1c.subdomain.example.com
 
volume                  a.etcd-events.subdomain.example.com
volume                  a.etcd-main.subdomain.example.com
volume                  control-plane-us-east-1a.masters.subdomain.example.com
volume                  nodes.subdomain.example.com
volume                  nodes.subdomain.example.com
volume                  nodes.subdomain.example.com

El siguiente es un ejemplo de las instancias de Amazon EC2 aprovisionadas a través de la secuencia de comandos de creación del clúster.

Figura 9. Aprovisionamiento de instancias EC2 en la consola de AWS

 

Una vez se completa la secuencia de comandos, el clúster está listo para usar, por lo que puede también validar el estado del clúster de EKS-D con el comando de kOps.

kops validate cluster –-name subdomain.example.com

La salida esperada es el resumen de INSTANCE GROUPS que indica que se ha creado el clúster con 1 instancia de Amazon EC2 para el Control Plane y 3 instancias de Amazon EC2 como Nodos del clúster.

INSTANCE GROUPS
NAME                            ROLE    MACHINETYPE     MIN     MAX     SUBNETS
control-plane-us-east-1a        Master  t3.medium       1       1       us-east-1a
nodes                           Node    t3.medium       3       3       us-east-1a,us-east-1b,us-east-1c
 
NODE STATUS
NAME                            ROLE    READY
ip-172-20-119-51.ec2.internal   node    True
ip-172-20-46-233.ec2.internal   node    True
ip-172-20-55-94.ec2.internal    master  True
ip-172-20-92-121.ec2.internal   node    True

Una parte importante del proceso de creación del clúster es que a diferencia de la instalación típica de Kubernetes, se ha empleado las imágenes de Amazon EKS Distro, que se encuentran en la galería publica de imágenes de Amazon ECR. Al ejecutar el siguiente comando puede verificar que los pods en el clúster estén usando las imágenes de EKS-D incluidas en los pasos previos.

kubectl get po --all-namespaces -o json | jq -r '.items[].spec.containers[].image' | sort -u

La salida esperada es similar a la siguiente en donde se puede apreciar el uso de las imágenes de EKS-D public.ecr.aws/eks-distro/:

k8s.gcr.io/cpa/cluster-proportional-autoscaler:1.8.3
k8s.gcr.io/etcdadm/etcd-manager:3.0.20210430
k8s.gcr.io/kops/dns-controller:1.21.0
k8s.gcr.io/kops/kops-controller:1.21.0
k8s.gcr.io/kops/kube-apiserver-healthcheck:1.21.0
public.ecr.aws/eks-distro/coredns/coredns:v1.8.3-eks-1-21-1
public.ecr.aws/eks-distro/kubernetes/kube-apiserver:v1.21.2-eks-1-21-1
public.ecr.aws/eks-distro/kubernetes/kube-controller-manager:v1.21.2-eks-1-21-1
public.ecr.aws/eks-distro/kubernetes/kube-proxy:v1.21.2-eks-1-21-1
public.ecr.aws/eks-distro/kubernetes/kube-scheduler:v1.21.2-eks-1-21-1
public.ecr.aws/eks-distro/kubernetes-sigs/aws-iam-authenticator:v0.5.2-eks-1-21-1
public.ecr.aws/eks-distro/kubernetes-sigs/metrics-server:v0.5.0-eks-1-21-1

Adicionalmente puede verificar que en los registros de Amazon Route 53 para subdomain.example.com se hayan creado tres (3) registros de tipo A. Un registro publico y dos registros internos, que serán empleados por el clúster para la comunicación a nivel de APIs.

api.subdomain.example.com   A      Simple
api.internal.subdomain.example.com  A      Simple
kops-controller.internal.subdomain.example.com A  Simple

 

Configuración para ambientes de producción

El clúster de Kubernetes que se ha creado con la distribución de Amazon EKS Distro, es el punto de partida de múltiples configuraciones. Al momento de crear el clúster se deben tener en cuenta otros aspectos que no están cubiertos a detalle en este blog, pero que deben ser tenidos en cuenta para su operación en ambientes de producción.

Unos de los aspectos mas relevantes es la Alta Disponibilidad, parte del proceso de creación del Clúster usa la plantilla eks-d.tpl la cual puede ser modificada y adaptada a necesidades de configuración especificas. En esta plantilla se parte de una configuración en la cual, a pesar de aprovisionar Grupos de Auto escalado dedicados (Para el control Plane y el Data Plane) el Control Plane no es redundante, así que puede migrar de un clúster de un solo Master a un clúster Multi-Master modificando la plantilla o creando grupos de instancias adicionales con los comandos de kOps.

Otro punto de mejora a considerar son las capacidades de Networking del clúster, la plantilla eks-d.tpl  usa por defecto el plugin de red básico kubenet el cual podemos modificar para se use en su lugar el plugin de red de Amazon VPC CNI el cual a su vez incluye el plugin CNI. Con Amazon VPC CNI a cada pod se asigna una dirección IP asociada a la ENI del nodo, además de poder crear políticas de red especificas para cada aplicación. Así que puede fácilmente modificar el proveedor de red en la sección de networking de la plantilla eks-d.tpl de kubenet a amazonvpc.

Otro aspecto importante es la Topología, por defecto el despliegue del clúster posee una Topología Publica en la cual los Master/Nodos se encuentran en subredes publicas y expuestos a internet. En la plantilla eks-d.tpl puede identificar la topología en la sección Topology para Master /Nodos y puede fácilmente modificar los valores de Public a Private y de esta manera lograr que los recursos de Master/Nodos sean aprovisionados en subredes privadas de la VPC.

Finalmente, a través del proceso de creación del clúster se ha hecho énfasis en el uso de plantillas como una forma de mantener la configuración del clúster y sus recursos de forma centralizada y así tener mayor control en los procesos de creación/actualización de múltiples ambientes.

 

Despliegue de aplicación

En este punto el clúster se encuentra operativo, así que puede desplegar una aplicación de ejemplo. Para el despliegue de la aplicación se usará la herramienta de línea de comandos kubectl instalada previamente y se desplegará la aplicación PHP Guestbook la cual implementa una aplicación web simple. Este ejemplo consta de dos componentes principales, una instancia Redis para almacenar entradas a un libro de visitas (Guestbook) y varias instancias Web de frontend. El despliegue detallado y los archivos de Manifiesto de cada uno de los componentes los puede encontrar en este enlace.

Para iniciar el despliegue, se aplican los archivos que corresponden a los componentes de backend, compuesto por dos manifest de tipo Deployment y dos de tipo Service.

kubectl apply -f https://k8s.io/examples/application/guestbook/redis-leader-deployment.yaml
kubectl apply -f https://k8s.io/examples/application/guestbook/redis-follower-deployment.yaml
 
kubectl apply -f https://k8s.io/examples/application/guestbook/redis-leader-service.yaml
kubectl apply -f https://k8s.io/examples/application/guestbook/redis-follower-service.yaml

Puede verificar los componentes desplegados, donde la salida es similar a la siguiente:

kubectl get pods
 
redis-follower-dddfbdcc9-llf77   1/1     Running   0          2m13s
redis-follower-dddfbdcc9-mgc62   1/1     Running   0          2m13s
redis-leader-fb76b4755-qx59w     1/1     Running   0          2m14s
 
kubectl get service
 
NAME             TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
kubernetes       ClusterIP   100.64.0.1       <none>        443/TCP    9h
redis-follower   ClusterIP   100.67.179.129   <none>        6379/TCP   4m52s
redis-leader     ClusterIP   100.67.52.2      <none>        6379/TCP   4m53s

Ahora aplique los archivos que corresponden a los componentes de frontend, compuesto por un manifest de tipo Deployment y uno de tipo Service.

kubectl apply -f https://k8s.io/examples/application/guestbook/frontend-deployment.yaml
kubectl apply -f https://k8s.io/examples/application/guestbook/frontend-service.yaml

Puede verificar los componentes desplegados como frontend, donde la salida es similar a la siguiente:

kubectl get pods -l app=guestbook -l tier=frontend
 
NAME                        READY   STATUS    RESTARTS   AGE
frontend-85595f5bf9-czg76   1/1     Running   0          91s
frontend-85595f5bf9-sqzpq   1/1     Running   0          91s
frontend-85595f5bf9-vkddr   1/1     Running   0          91s

Si desplego el manifiesto frontend-service.yaml con el tipo de servicio type:LoadBalancer (Expone el Servicio de forma externa) debe encontrar un nombre del DNS publico del servicio al momento de listarlo con kubectl y además un Balanceador de Carga Clasico aprovisionado que podrá verificar a través de AWS CLI o en la consola web de AWS.

El Balanceador de Carga Clasico, es el componente por defecto aprovisionado cuando se usa el tipo de servicio type:LoadBalancer y no se cuenta con controladores específicos como AWS Load Balancer Controller para aprovisionar Balanceadores de Carga de Aplicación (ALB) o Balanceadores de Carga de Red (NLB).

kubectl get services
 
NAME             TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
frontend         LoadBalancer 100.64.78.99     a88e7551-XX.us-east-1.elb.amazonaws.com   80:31417/TCP   12m
kubernetes       ClusterIP    100.64.0.1       <none>        443/TCP    9h
redis-follower   ClusterIP    100.67.179.129   <none>        6379/TCP   4m52s
redis-leader     ClusterIP    100.67.52.2      <none>        6379/TCP   4m53s

Finalmente, puede navegar al DNS publico del servicio  frontend donde podrá verificar el uso de la aplicación.

Figura 10. Frontend aplicación PHP Guestbook

La importancia que tiene esta aplicación de ejemplo radica en que es una aplicación nativa para Kubernetes y lo que se ha hecho es desplegarla en un clúster que opera con la distribución de Amazon EKS Distro, demostrando su uso y operación.

 

Limpiando el entorno

Para la aplicación de ejemplo al eliminar los despliegues y los servicios, también se eliminan los pods que estén en ejecución. Utilice etiquetas para eliminar varios recursos con un solo comando.

Ejecute los siguientes comandos para eliminar todos los pods, despliegues y servicios de la aplicación.

kubectl delete deployment -l app=redis
kubectl delete service -l app=redis
kubectl delete deployment frontend
kubectl delete service frontend

Para eliminar el clúster, se usará el script delete_cluster.sh con lo cual no solo se eliminará el clúster sino también se eliminarán los recursos aprovisionados entre los que se encuentran los servicios de Amazon EC2, Amazon Route 53 y Amazon S3.

./delete_cluster.sh

Conclusiones

Amazon EKS Distro (EKS-D) reduce la fricción entre el uso de una distribución de Kubernetes para entornos On-premise y entornos basados en nube mediante el uso de las mismas versiones y configuraciones validadas de Kubernetes y sus dependencias, tal como se implementan globalmente para Amazon EKS. Dado que es código abierto, es más probable que pueda ser evaluado por nuestros clientes antes de considerar otras distribuciones de Kubernetes junto con proveedores de software independientes como VMware, Red Hat, Rancher, etc. que aprovechan los servicios de computo de Amazon EC2 para ejecutar su oferta administrada Kubernetes.

 

Sobre el autor

Jhon Guzmán es Arquitecto de Soluciones de Partners en Amazon Web Services para el Sector Público. Jhon ha ayudado a múltiples socios de negocio de AWS en Latinoamérica para la adopción de nuevas tecnologías e implementación de soluciones cloud en sus clientes.

 

 

 

Revisores Técnicos

Branko Straub es Arquitecto de Soluciones en Amazon Web Services para Sector Público en Chile. Branko ha ayudado a múltiples instituciones de Sector Público y Privado en la adopción tecnológica de nube en los últimos 5 años, ha ejecutado de manera exitosa proyectos con impacto social en la ciudadanía alrededor de América Latina.

 

 

 

Germán Ruiz es Arquitecto de Soluciones de Partners en Amazon Web Services para el Sector Público en Centro América y el Caribe, apoyándolos en su camino a la innovación y adopción tecnológica.