|
|
Me complace anunciar la disponibilidad de clústeres locales para Amazon Elastic Kubernetes Service (Amazon EKS) en AWS Outposts. Significa que, a partir de hoy, puede implementar su clúster de Amazon EKS por completo en Outposts: tanto el plano de control de Kubernetes como los nodos.
Amazon EKS es un servicio de Kubernetes administrado que le facilita la ejecución de Kubernetes en AWS y en las instalaciones. AWS Outposts es una familia de soluciones completamente administradas que brindan infraestructura y servicios de AWS a prácticamente cualquier ubicación local o de borde para una experiencia híbrida verdaderamente uniforme.
Para comprender completamente los beneficios de los clústeres locales para Amazon EKS en Outposts, primero necesito compartir algunos antecedentes.
Algunos clientes usan Outposts para implementar pods y nodos de clúster de Kubernetes cerca del resto de su infraestructura local. Esto permite que sus aplicaciones se beneficien del acceso de baja latencia a los servicios y datos locales mientras administran el clúster y el ciclo de vida de los nodos utilizando la misma API, CLI o consola de AWS de AWS que utilizan para sus clústeres basados en la nube.
Hasta hoy, cuando implementaba aplicaciones de Kubernetes en Outposts, generalmente comenzaba creando un clúster de Amazon EKS en la nube de AWS. Luego implementó los nodos del clúster en sus máquinas Outposts. En este escenario de clúster híbrido, el plano de control de Kubernetes se ejecuta en la región principal de sus Outposts y los nodos se ejecutan en sus Outposts locales. El servicio de Amazon EKS se comunica a través de la red con los nodos que se ejecutan en la máquina de Outposts.
Pero recuerda: todo falla todo el tiempo. Los clientes nos dijeron que el principal desafío que tienen en este escenario es administrar las desconexiones del sitio. Esto es algo que no podemos controlar, especialmente cuando implementa Outposts en áreas irregulares: áreas con conexiones de red deficientes o intermitentes. Cuando la instalación local se desconecta temporalmente de Internet, el plano de control de Amazon EKS que se ejecuta en la nube no puede comunicarse con los nodos y los pods. Aunque los nodos y los pods funcionan a la perfección y siguen sirviendo la aplicación en la red local local, Kubernetes puede considerar que no están en buen estado y programar su sustitución cuando se restablezca la conexión (consulte desalojo de pod en la documentación de Kubernetes). Esto puede provocar tiempos de inactividad de la aplicación cuando se restaura la conectividad.
hablé con cris, nuestro gerente de productos y experto en Kubernetes, mientras preparaba esta publicación de blog. Me dijo hay al menos siete opciones distintas para configurar cómo un plano de control se vuelve a conectar a sus nodos. A menos que domine todas estas opciones, el estado del sistema en la reconexión es impredecible.
Para simplificar esto, le ofrecemos la posibilidad de alojar todo su clúster de Amazon EKS en Outposts. En esta configuración, tanto el plano de control de Kubernetes como los nodos de trabajo se ejecutan localmente en las instalaciones de su máquina Outposts. De esa manera, su clúster continúa funcionando incluso en caso de una caída temporal en su conexión de enlace de servicio. Puede realizar operaciones de clúster, como crear, actualizar y escalar aplicaciones durante las desconexiones de la red a la nube.
Veámoslo en acción
Veamos cómo podemos usar esta nueva capacidad. Para esta demostración, implementaré el plano de control de Kubernetes en instancias de Amazon Elastic Compute Cloud (Amazon EC2) que se ejecutan localmente en un rack de Outposts.
Uso un rack Outposts ya configurado. Si desea obtener información sobre cómo comenzar con Outposts, puede leer los pasos en la página Comenzar con AWS Outposts.
Esta demostración tiene dos partes. Primero, creo el clúster. En segundo lugar, me conecto al clúster y creo nodos.
Creación de clúster
Antes de implementar el clúster local de Amazon EKS en Outposts, me aseguré de haber creado un rol de clúster de IAM y adjunto el AmazonEKSLocalOutpostClusterPolicy política administrada. Este rol de clúster de IAM se utilizará en la creación del clúster.
Luego, cambio al panel de control de Amazon EKS y selecciono Agregar clústerdespués Crear.
En la página siguiente, elegí la ubicación del plano de control de Kubernetes: la nube de AWS o AWS Outposts. Yo selecciono Puestos avanzados de AWS y especificar el Identificación de puestos avanzados.
El plano de control de Kubernetes en Outposts se implementa en tres instancias EC2 para una alta disponibilidad. Por eso veo tres Réplicas. Luego, elijo el tipo de instancia según la cantidad de nodos trabajadores necesarios para las cargas de trabajo. Por ejemplo, para manejar de 0 a 20 nodos trabajadores, se recomienda usar m5d.large Instancias EC2.
En la misma página, especifico valores de configuración para el clúster de Kubernetes, como su Nombre, Versión de Kubernetesy el Rol de servicio de clúster que creé antes.
En la página siguiente, configuro las opciones de red. Dado que Outposts es una extensión de una región de AWS, necesito usar el VPC y Subredes utilizado por Outposts para permitir la comunicación entre el plano de control de Kubernetes y los nodos de trabajo. Para Grupos de seguridad, Amazon EKS crea un grupo de seguridad para clústeres locales que permite la comunicación entre mi clúster y mi VPC. También puedo definir grupos de seguridad adicionales según los requisitos de mi aplicación.
A medida que ejecutamos el plano de control de Kubernetes dentro de Outposts, el Acceso al extremo del clúster Solo se puede acceder de forma privada. Esto significa que solo puedo acceder al clúster de Kubernetes a través de máquinas que están implementadas en la misma VPC o en la red local a través de la puerta de enlace local de Outposts con enrutamiento directo de VPC.
En la página siguiente, defino registro. El registro está deshabilitado de forma predeterminada y puedo habilitarlo según sea necesario. Para obtener más detalles sobre el registro, puede leer la documentación de registro del plano de control de Amazon EKS.
La última pantalla me permite revisar todas las opciones de configuración. Cuando estoy satisfecho con la configuración, selecciono Crear para crear el clúster.
La creación del clúster tarda unos minutos. Para verificar el estado de creación del clúster, puedo usar la consola o la terminal con el siguiente comando:
$ aws eks describe-cluster \
--region <REGION_CODE> \
--name <CLUSTER_NAME> \
--query "cluster.status"los Estado La sección me dice cuándo se crea y activa el clúster.
Además de utilizar la Consola de administración de AWS, también puedo crear un clúster local mediante la CLI de AWS. Aquí está el fragmento de comando para crear un clúster local con la AWS CLI:
$ aws eks create-cluster \
--region <REGION_CODE> \
--name <CLUSTER_NAME> \
--resources-vpc-config subnetIds=<SUBNET_ID>\
--role-arn <ARN_CLUSTER_ROLE> \
--outpost-config controlPlaneInstanceType=<INSTANCE_TYPE> \
--outpostArns=<ARN_OUTPOST>Conexión al clúster
El acceso de punto final para un clúster local es privado; por lo tanto, puedo acceder desde una puerta de enlace local con Direct VPC Routing o desde máquinas que están en la misma VPC. Para averiguar cómo usar puertas de enlace locales con Outposts, puede seguir la información en la página Trabajar con puertas de enlace locales. Para esta demostración, uso una instancia EC2 como host bastión y administro el clúster de Kubernetes usando kubectl dominio.
lo primero que hago es editar Grupos de seguridad para abrir el acceso al tráfico desde el host bastión. Voy a la página de detalles del clúster de Kubernetes y selecciono el Redes pestaña. Luego selecciono el enlace en Grupo de seguridad del clúster.
Luego, agrego reglas de entrada y brindo acceso al host bastión especificando su dirección IP.
Una vez que he permitido el acceso, creo kubeconfig en el host bastión ejecutando el comando:
$ aws eks update-kubeconfig --region <REGION_CODE> --name <CLUSTER_NAME>Finalmente, uso kubectl para interactuar con el servidor API de Kubernetes, como de costumbre.
$ kubectl get nodes -o wide
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
ip-10-X-Y-Z.us-west-2.compute.internal NotReady control-plane,master 10h v1.21.13 10.X.Y.Z <none> Bottlerocket OS 1.8.0 (aws-k8s-1.21) 5.10.118 containerd://1.6.6+bottlerocket
ip-10-X-Y-Z.us-west-2.compute.internal NotReady control-plane,master 10h v1.21.13 10.X.Y.Z <none> Bottlerocket OS 1.8.0 (aws-k8s-1.21) 5.10.118 containerd://1.6.6+bottlerocket
ip-10-X-Y-Z.us-west-2.compute.internal NotReady control-plane,master 9h v1.21.13 10.X.Y.Z <none> Bottlerocket OS 1.8.0 (aws-k8s-1.21) 5.10.118 containerd://1.6.6+bottlerocketLos clústeres locales de Kubernetes que se ejecutan en AWS Outposts se ejecutan en tres instancias EC2. Vemos en el resultado anterior que el estado de tres nodos trabajadores es NotReady. Esto se debe a que el plano de control los usa exclusivamente y no podemos usarlos para programar pods.
A partir de esta etapa, puede implementar grupos de nodos autoadministrados mediante el clúster local de Amazon EKS.
Precios y disponibilidad
Los clústeres locales de Amazon EKS se cobran al mismo precio que los clústeres de EKS tradicionales. Comienza en $0.10/hora. Las instancias EC2 necesarias para implementar el plano de control y los nodos de Kubernetes en Outposts están incluidas en el precio de Outposts. Como de costumbre, la página de precios tiene los detalles.
Los clústeres locales de Amazon EKS están disponibles en todas las regiones de AWS donde Outposts está disponible.
¡Construya y cree su primer clúster local de EKS hoy mismo!
–seb y Donnie.
