Este documento presenta una introducción a Amazon EKS. Explica los conceptos clave de Kubernetes y cómo EKS administra el plano de control de Kubernetes de manera segura y confiable. También cubre temas como redes, seguridad, monitoreo y opciones de nodos de trabajo como instancias EC2 administradas, grupos de nodos administrados y AWS Fargate.
Para aquellos de ustedes que no están demasiado familiarizados con Kubernetes, comencemos con una visión rápida de algunos conceptos básicos.
Pods - Grupo coubicado de contenedores que comparten una IP, espacio de nombres, volumen de almacenamiento
Conjuntos de Réplicas - Administra el ciclo de vida de las vainas y asegura que el número especificado se
Servicios - Nombre único, estable para un conjunto de vainas, también actúa como LB
Etiquetas - Se utiliza para organizar y seleccionar grupo de objetos
Comience con los conceptos básicos de cómo funciona Docker.
Tienes un Docker Daemon que extrae imágenes de contenedor de un Registro y las inicia convirtiéndolas en Contenedores en ejecución. Entonces administra su ciclo de vida.
Se puede controlar ese proceso con el cliente docker o con una API.
Con Kubernetes esto es exactamente lo mismo excepto:
que en lugar de que ejecutes docker run te comanda con la CLI el Kubernetes kubelet que se ejecuta en cada máquina lo hace en tu nombre.
A la versión ECS del kublet se le llama Agente ECS pero es mucho la misma idea.
kubelets son, dijeron qué hacer por el avión de control Kubernetes
Kublets como empuja información sobre lo que está sucediendo en cada nodo de nuevo hasta el plano de control ayuda con sus decisiones de programación.
A medida que creces hasta muchos nodos de trabajo un orquestador como Kubernetes haciendo esto por ti se vuelve cada vez más esencial.
Puedes ejecutar Kubernetes tú mismo a través de máquinas virtuales en nuestro EC2 entonces, ¿qué hace EKS por ti por encima de hacerlo tú mismo?
(CLICK)
Desplegamos el Plano de Control de Kubernetes y etcd en una configuración de alta disponibilidad a través de 3 AZs
(CLICK)
Y gestionamos ese plano de control para ti de manera similar a nuestro servicio de base de datos relacional gestionada RDS
(CLICK)
Proporcionamos, y en realidad requerimos que utilice, un plugin de red (CNI) que hemos abierto que integra las redes de Pod de forma nativa con AWS VPC
(CLICK)
Y integramos/federamos el acceso de usuarios a la CLI de Kubernetes (kubectl) y API con AWS IAM a través de nuestro plugin aws-iam-autenticador
Cosas que hay que mencionar:
Amazon EKS corre aguas arriba Kubernetes y está certificado conforme a Kubernetes,
Las aplicaciones administradas por Amazon EKS son totalmente compatibles con aplicaciones gestionadas por cualquier entorno estándar de Kubernetes.
Cosas que hay que mencionar:
En un alto nivel, la arquitectura EKS incluye nodos de trabajo en forma de instancias EC2 y un plano de control de EKS administrado para proporcionar capacidad para ejecutar sus Pods.
Al ir un poco más profundo, el plano de control está conformado por al menos cinco instancias EC2 que ejecutamos dedicadas para usted y este cluster en nuestra cuenta.
Existen al menos dos instancias de servidor API en diferentes Zonas de Disponibilidad y un quórum de tres instancias de Etcd en tres AZs.
Esto significa que cada cliente, y cada clúster, está en su propia infraestructura de HA de un solo inquilino. También es por eso que cobramos por el plano de control ya que incurrimos en este costo de cinco instancias EC2 por cada uno que gires.
The first network consideration to be aware of with EKS is whether the control plane API endpoints, used by kubectl as well by your worker nodes to communicate with the control plane, are public or private.
EKS launched with this as being public-only but has since made this granular so you can have them be only-public, only-private or both public and private. In most situations I’d suggest making them only-private.
We recently launched a capability, so that when only the private endpoint is enabled, Amazon EKS automatically advertises the private IP addresses of the private endpoint from the public endpoint. This means that you can easily connect to your EKS cluster over a peered VPC or over a Direct Connect.
Con EKS te requerimos que utilices nuestra red, o CNI, plugin. Este plugin convierte todo de nuevo en eNIs y IP normales dentro de su red AWS VPC.
Bajo este modelo Pods cada uno obtiene su propia IP VPC 'real' adicional de una Interfaz de Red Elástica o ENI. Esto significa que EKS puede tener una alta densidad de Pods a interfaces e instancias de red pero que no se puede contar plenamente aprovechar Grupos de seguridad vinculados a ENIS para segregación de red - ya que dos Pods no relacionados pueden estar utilizando el mismo ENI y por lo tanto grupo de seguridad.
Lo que pasa es que cuando se programe una vaina
(CLICK)
Nuestro plugin CNI irá y obtendrá una IP adicional, lo asignará a un ENI, y luego
(CLICK)
Mapear ese pod a esa interfaz IP y red.
(CLICK)
El primer elemento que veremos es Administración de Identidad y Acceso.
Cuando hablamos de Administración de Identidad y Acceso se trata de controlar quién puede hacer qué en la plataforma y el clúster de contenedores.
Por lo general, aquí hay dos casos: controlar lo que la gente puede hacer y controlar qué código o tuberías automatizadas pueden hacer.
Hablando de Tuberías Automatizadas —realmente se debe automatizar todo- por razones de seguridad además de las operativas habituales.
Esto incluye:
La cuenta subyacente de AWS y su red VPC
Su Código y Contenedor Construye
Lo cual debe incrustar pruebas de seguridad además de su unidad y pruebas de integración como paso requerido antes, finalmente,
Tus despliegues
El objetivo aquí es que sea lo más rápido y fácil posible para que tu equipo haga lo correcto!
El motivo por el que DevseCops ha despegado es que incrustar la seguridad en sus ductos y procesos, y hacerlo lo más rápido y fácil posible, hace que sea mucho más probable que suceda y la gente no solo vaya por ahí para hacer su trabajo y cumplir sus plazos!
Con EKS, y su AWS IAM Authenticator requerido, inicias sesión en el clúster con una Identidad de AWS IAM, ya sea un Usuario de IAM o un Rol de IAM. Pero Kubernetes decide qué pueden hacer ahí a través de su RBAC.
El modo en que funciona este proceso es:
(CLICK)
1) Cuando se realiza una llamada Kubectl - digamos que he hecho una llamada get pods, mi identidad IAM se pasa junto con la llamada Kubernetes por nuestro plugin IAM Authenticator. Se ve en la cadena de credenciales predeterminada para mi archivo IAM ID - config en la carpeta.aws, rol de IAM asignado a instancia, etc.
(CLICK)
2) En el backend, Kubernetes verifica la identidad de IAM con AWS IAM. Esto es puramente para la autenticación.
(CLICK)
3) La respuesta de autenticación se envía de vuelta a Kubernetes, y K8s comprueba su mapeo interno de RBAC para este principal ahora autenticado. Esto determina si mi llamada de get pods original fue permitida o denegada.
(CLICK)
4) La API de K8s aprueba o niega la solicitud y me devuelve los resultados.
(CLICK)
Cuando se crea un clúster de Amazon EKS, al usuario de entidad de IAM o al rol, como un usuario federado que crea el clúster, se le conceden automáticamente permisos system:masters en la configuración RBAC del clúster. Para permitir que otros roles o usuarios de AWS interactúen con el clúster, debe editar el mapa de configuración aws-auth desde Kubernetes.
No entraré en detalles exhaustivos sobre Kubernetes RBAC ya que está bastante bien descrito en su documentación, y en la capacitación para su certificación Certified Kubernetes Administrator. Pero tocaré algunos de los conceptos básicos.
Kubernetes tiene Roles que se definen dentro y se aplican a un único espacio de nombres, que son la separación lógica dentro de Kubernetes similar a las cuentas que hay dentro de AWS. También cuenta con ClusterRoles que aplican en todo el clusteren todos los espacios de nombres.
Con ambos defines reglas que describen los recursos, y los verbos que área permitida en contra de ellos, por los principales que están ingresados como ese Rol.
Kubernetes tiene algunos Roles incorporados que puedes usar para asignar un mínimo privilegio a personas o ductos para completar su trabajo. Estos son un poco contundentes y a menudo los clientes los usan como inspiración para hacer sus propios más granulares.
A continuación hablaremos de los servicios y configuraciones de la plataforma que se requieren para estar seguros en la nube con sus contenedores.
Tener un rastro de auditoría de lo que sucede —quién hizo qué cuando— es un elemento importante de seguridad y poder investigar con éxito cualquier quebrantamiento de la misma.
Al crear un clúster de EKS ya sea a través de la consola o a través de eksctl, el registro de esto en CloudWatch Logs por omisión está deshabilitado y necesitas solicitarlo activándolo o pasando un parámetro adicional — definitivamente deberías hacerlo.
A continuación hablaremos de las configuraciones de red y firewall para ECS y EKS.
El primer paso para usar Políticas de red, que es la funcionalidad de firewall de red incorporada de Kubernetes, es instalar un Proveedor de Políticas de Red. Una elección común es la de Calico —y ésta es la que explicamos cómo instalar y usar en nuestra documentación de EKS.
So how do Network Polices on Kubernetes work?
Here is an example of 3 microservices that can all talk to each other. If I want to create segmentation boundary between these microservices, I can apply default-deny rule in the NetworkPolicy and apply to this namespace.
Entonces, ¿cómo funcionan las Polices de Red sobre Kubernetes?
Aquí te presentamos un ejemplo de 3 microservicios que todos pueden hablar entre sí. Si quiero crear límite de segmentación entre estos microservicios, puedo aplicar la regla default-deny en la NetworkPolicy y aplicar a este espacio de nombres.
Ahora ninguno de ellos puede comunicarse entre sí o ser alcanzado desde Internet.
Now none of them can communicate with each other or be reached from the Internet.
Si quiero exponer sólo mi microservicio frontend a Internet, puedo hacerlo con este ejemplo NetworkPolicy permitiendo a 0.0.0.0 hablar con él como regla de Ingress.
If I want to expose only my frontend microservice to the Internet, I can do so with this example NetworkPolicy allowing 0.0.0.0 to talk to it as an Ingress rule.
Y ahora tengo mi Frontend abierto a Internet una vez más.
Si quería entonces permitir que el servicio Frontend hable con el servicio de Cats puedo agregar esta regla de ingreso que utiliza un PodSelector coincidente pods con la etiqueta “frontend” en lugar de en una subred IP como antes.
En este espacio hay otra opción que es una comercial de pago. Tigera es la empresa detrás de Calico y tienen una versión Enterprise más avanzada del Proveedor de Políticas de Red con más características.
Los principales son que puede habilitar el cifrado automático y sin fisuras de host a host, puede proporcionar registros de flujo enriquecidos con el contexto kubernetes (el nuestro simplemente enumeraría IPs sin eso) y permite la integración con AWS Security Groups similares a ECS.
Esto es útil para tener reglas para decir que sólo estos Pods pueden conectarse a esta Caché o Base de Datos y otros, que podrían incluso estar en el mismo ENI, no pueden.
-Assign VPC secondary IP addresses to pods like the VPC CNI plugin does today.
-Allow pods to use IPs defined by a CIDR block assigned directly to a node. This is a separate CIDR range distinct from the node's network. This will give you the ability to have very large pod per node density – e.g. 256 or more pods on a [x].large EC2 instance without consuming your VPC IP space.
-Assign ENIs directly to pods. This mode takes advantage of EC2 ENI trunking and enables you to use all ENI features within the pod, such as assigning a security group directly to a pod.
We're currently in the design and development stage of this plugin. We plan to release a beta of the CNI in the coming months. After this new CNI is generally available, we'll make it available in EKS. We do not plan to deprecate the current CNI plugin within EKS until we achieve parity between both generations of CNI plugins.
A continuación hablaremos un poco sobre las responsabilidades del cliente en torno a las Instancias para ejecutar los contenedores. Esto abarca no sólo la gestión de las Instancias dentro de la plataforma sino también todo a nivel del Sistema Operativo y superior.
Estas responsabilidades incluyen:
Qué tipo de instancia debe usar. Esto depende de los requisitos de CPU y Memoria de tus Tareas o Pods y de qué relación de CPU a memoria necesitas.
Qué Sistema Operativo debes elegir. Te recomendamos, e incluso proporcionamos AMIs compatibles y actualizadas regularmente para, Amazon Linux - pero eres libre de usar cualquier Linux que quieras. He trabajado con clientes que han utilizado con éxito RHEL o Ubuntu en su lugar porque eso es lo que han estandarizado y el personal está familiarizado con etc.
Cualquier endurecimiento de ese SO — A menudo escucho que hay un requisito interno para endurecerse a un estándar CIS Nivel 1 etc. Ya que eres responsable de este SO serías responsable de eso.
Y, por último, cualquier parches del SO así como cualquier cosa que se ejecute encima de él -como Docker y el ECS Agent o Kubernetes kubelet.
Elimina la necesidad de que los clientes creen o administren instanciasEC2para sus clústeres de Amazon EKS
Los clientes ya no tienen que preocuparse por la aplicación de parches, el escalado o la seguridad de un clúster de instancias EC2 para ejecutar aplicaciones Kubernetes en la nube.
Let's compare this to EKS on Fargate.
Again, the customer sends a request to the Kubernetes API, asking to run a container.
Kubernetes creates the relevant service and pod within the cluster, and requests an ENI in the customer's VPC, which gets attached to the Fargate container.
But now, customers don't need to provision EC2 instances at all, and so they don't have to manage the capacity of their cluster.
Fuera de la caja EKS no tiene una configuración predeterminada para recopilar, agregar, alertar o visualizar sus métricas. Hay dos patrones comunes que estoy viendo que los clientes agregan a su clúster para obtener esta funcionalidad.
El primero es aprovechar las herramientas que forman parte del ecosistema CNCF, Prometheus y Grafana, para ello. Esto generalmente significa ejecutar los que están encima de su clúster usted mismo. Cubrimos cómo configurarlos como parte de nuestro eksworkshop —que vale la pena revisar ya que te ayuda a agregar las cosas habituales que necesitarás para que tu cluster esté listo para la producción de esta manera.
Alternativamente, recientemente lanzamos CloudWatch Container Insights para que podamos hacer esto todo por usted como un servicio administrado dentro de CloudWatch, que si hace otras cosas en la plataforma AWS es donde estarán todas esas otras métricas.
Por supuesto que hay muchos vendedores comerciales de SaaS que pueden ayudarte con tus métricas. Estas son solo algunas que funcionan bien con AWS y EKS.
Por supuesto que hay muchos vendedores comerciales de SaaS que pueden ayudarte con tus registros. Estas son solo algunas que funcionan bien con AWS y EKS.
Amazon EKS-optimized GPU AMI
Includes NVIDIA packages to support Amazon P2 and P3 instances
Easily run TensorFlow on Amazon EKS
Muchos equipos de desarrollo crean y dan soporte a aplicaciones diseñadas para ejecutarse en servidores Windows y, con Windows Container Support en EKS, pueden implementarlas en Kubernetes junto con aplicaciones Linux. Esta capacidad proporcionará más coherencia en el registro del sistema, la supervisión del rendimiento y las canalizaciones de implementación de código.