Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés. # Plano de control EKS **sugerencia** [Explore](https://aws-experience.com/emea/smb/events/series/get-hands-on-with-amazon-eks?trk=4a9b4147-2490-4c63-bc9f-f8a84b122c8c&sc_channel=el) las mejores prácticas a través de los talleres de Amazon EKS. Amazon Elastic Kubernetes Service (EKS) es un servicio de Kubernetes administrado que le facilita la ejecución de Kubernetes en AWS sin necesidad de instalar, operar y mantener su propio plano de control de Kubernetes o nodos de trabajo. Funciona con Kubernetes en sentido ascendente y está certificado como compatible con Kubernetes. Esta conformidad garantiza que EKS sea compatible con las API de Kubernetes, al igual que la versión comunitaria de código abierto que se puede instalar en EC2 o de forma local. Las aplicaciones existentes que se ejecutan en Kubernetes upstream son compatibles con Amazon EKS. EKS administra automáticamente la disponibilidad y la escalabilidad de los nodos del plano de control de Kubernetes y reemplaza automáticamente los nodos del plano de control en mal estado. ## Arquitectura EKS La arquitectura EKS está diseñada para eliminar cualquier punto único de fallo que pueda comprometer la disponibilidad y la durabilidad del plano de control de Kubernetes. El plano de control de Kubernetes gestionado por EKS se ejecuta dentro de una VPC gestionada por EKS. El plano de control de EKS comprende la API de Kubernetes, los nodos del servidor, el clúster, etc. Nodos del servidor de API de Kubernetes que ejecutan componentes como el servidor de API o el programador y se ejecutan `kube-controller-manager` en un grupo de autoscalamiento. EKS ejecuta un mínimo de dos nodos de servidor de API en distintas zonas de disponibilidad (AZ) dentro de una región de AWS. Del mismo modo, para mayor durabilidad, los nodos del servidor etcd también se ejecutan en un grupo de autoescalado que abarca tres AZ. EKS ejecuta una puerta de enlace NAT en cada zona de disponibilidad, y los servidores API y etcd se ejecutan en una subred privada. Esta arquitectura garantiza que un evento en una única zona de disponibilidad no afecte a la disponibilidad del clúster EKS. Cuando crea un clúster nuevo, Amazon EKS crea un punto de enlace de alta disponibilidad para el servidor API de Kubernetes administrado que utiliza para comunicarse con el clúster (mediante herramientas como). `kubectl` El punto final administrado usa NLB para equilibrar la carga de los servidores API de Kubernetes. EKS también proporciona dos [ENI](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html) en diferentes zonas de disponibilidad para facilitar la comunicación con los nodos de trabajo. Plano de datos EKS: conectividad de red ![Conectividad](http://docs.aws.amazon.com/es_es/eks/latest/best-practices/images/reliability/eks-data-plane-connectivity.jpeg) Puedes [configurar si se puede acceder al servidor de API de tu clúster de Kubernetes](https://docs.aws.amazon.com/eks/latest/userguide/cluster-endpoint.html) desde la Internet pública (mediante el punto de conexión público) o a través de tu VPC (mediante los ENI) o ambos. EKS-managed Tanto si los usuarios como los nodos trabajadores se conectan al servidor de API mediante el punto final público o el EKS-managed ENI, existen rutas de conexión redundantes. ## Recomendaciones Revise las siguientes recomendaciones. ## Supervise las métricas del plano de control La supervisión de las métricas de la API de Kubernetes puede proporcionarte información sobre el rendimiento del plano de control e identificar problemas. Un plano de control defectuoso puede comprometer la disponibilidad de las cargas de trabajo que se ejecutan dentro del clúster. Por ejemplo, los controladores mal escritos pueden sobrecargar los servidores de la API y afectar a la disponibilidad de la aplicación. Kubernetes expone las métricas del plano de control en el punto final. `/metrics` Puede ver las métricas expuestas mediante: `kubectl` ``` kubectl get --raw /metrics ``` Estas métricas se representan en formato de texto de [Prometheus](https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md). Puedes usar Prometheus para recopilar y almacenar estas métricas. En mayo de 2020, CloudWatch se agregó soporte para monitorear las métricas CloudWatch de Prometheus en Container Insights. Por lo tanto, también puede usar Amazon CloudWatch para monitorear el plano de control del EKS. Puede utilizar el [tutorial para añadir un nuevo Prometheus Scrape Target: Prometheus KPI](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContainerInsights-Prometheus-Setup-configure.html#ContainerInsights-Prometheus-Setup-new-exporters) Server Metrics para recopilar métricas CloudWatch y crear un panel de control para supervisar el plano de control de su clúster. [Puedes encontrar las métricas del servidor API de Kubernetes aquí.](https://github.com/kubernetes/apiserver/blob/master/pkg/endpoints/metrics/metrics.go) Por ejemplo, `apiserver_request_duration_seconds` puede indicar cuánto tardan en ejecutarse las solicitudes de API. Considere la posibilidad de monitorizar estas métricas del plano de control: ### Servidor de API | Métrica | Description (Descripción) | | --- | --- | | `apiserver_request_total` | Contador de solicitudes de apiserver desglosadas por verbo, valor de ensayo, grupo, versión, recurso, ámbito, componente y código de respuesta HTTP. | | `apiserver_request_duration_seconds*` | Histograma de latencia de respuesta en segundos para cada verbo, valor de simulacro, grupo, versión, recurso, subrecurso, ámbito y componente. | | `apiserver_admission_controller_admission_duration_seconds*` | Histograma de latencia del controlador de admisión en segundos, identificado por su nombre y desglosado para cada operación y recurso y tipo de API (validar o admitir). | | `apiserver_admission_webhook_rejection_count` | Recuento de rechazos de webhooks de admisión. Se identifica por nombre, operación, código de rechazo, tipo (validando o admitiendo), tipo de error (calling\_webhook\_error, apiserver\_internal\_error, no\_error) | | `rest_client_request_duration_seconds*` | Solicita el histograma de latencia en segundos. Desglosado por verbo y URL. | | `rest_client_requests_total` | Número de solicitudes HTTP, fragmentadas por código de estado, método y host. | + Las métricas del histograma incluyen los sufijos \_bucket, \_sum y \_count. ### etc.d. | Métrica | Description (Descripción) | | --- | --- | | `etcd_request_duration_seconds*` | Etcd solicita el histograma de latencia en segundos para cada operación y tipo de objeto. | | `apiserver_storage_db_total_size_in_bytes`o `apiserver_storage_size_bytes` (a partir de EKS v1.28) | Tamaño de la base de datos Etcd. | + Las métricas del histograma incluyen los sufijos \_bucket, \_sum y \_count. Considere la posibilidad de utilizar el [panel general de supervisión de Kubernetes para visualizar y supervisar](https://grafana.com/grafana/dashboards/14623) las solicitudes del servidor de la API de Kubernetes y las métricas de latencia y latencia, etc. **importante** Cuando se supera el límite de tamaño de la base de datos, etcd emite una alarma de falta de espacio y deja de recibir más solicitudes de escritura. En otras palabras, el clúster pasa a ser de solo lectura y el servidor de API del clúster rechazará todas las solicitudes para mutar objetos, como la creación de nuevos pods, el escalado de las implementaciones, etc. ## Autenticación de Actualmente, EKS admite dos tipos de autenticación: los [tokens de bearer/service cuenta](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#service-account-tokens) y la autenticación de IAM, que utiliza la autenticación con [token de webhook](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#webhook-token-authentication). Cuando los usuarios llaman a la API de Kubernetes, un webhook pasa a IAM un token de autenticación incluido en la solicitud. El token, una URL firmada de base 64, lo genera la interfaz de línea de comandos de [AWS (AWS CLI](https://aws.amazon.com/cli/)). El usuario o rol de IAM que crea el clúster de EKS obtiene automáticamente acceso total al clúster. Puede administrar el acceso al clúster de EKS editando el mapa de configuración de [aws-auth](https://docs.aws.amazon.com/eks/latest/userguide/add-user-role.html). Si configura mal el `aws-auth` mapa de configuración y pierde el acceso al clúster, puede seguir utilizando el usuario o el rol del creador del clúster para acceder a su clúster de EKS. En el improbable caso de que no pueda usar el servicio de IAM en la región de AWS, también puede usar el token portador de la cuenta de servicio de Kubernetes para administrar el clúster. Cree una `super-admin` cuenta que pueda realizar todas las acciones del clúster: ``` kubectl -n kube-system create serviceaccount super-admin ``` Cree un enlace de roles que asigne al superadministrador el rol de administrador del clúster: ``` kubectl create clusterrolebinding super-admin-rb --clusterrole=cluster-admin --serviceaccount=kube-system:super-admin ``` Obtén el secreto de la cuenta de servicio: ``` SECRET_NAME=`kubectl -n kube-system get serviceaccount/super-admin -o jsonpath='{.secrets[0].name}'` ``` Obtenga el token asociado al secreto: ``` TOKEN=`kubectl -n kube-system get secret $SECRET_NAME -o jsonpath='{.data.token}'| base64 --decode` ``` Agrega la cuenta de servicio y el token a`kubeconfig`: ``` kubectl config set-credentials super-admin --token=$TOKEN ``` Defina el contexto actual para usar la cuenta `kubeconfig` de superadministrador: ``` kubectl config set-context --current --user=super-admin ``` La versión final `kubeconfig` debería tener este aspecto: ``` apiVersion: v1 clusters: - cluster: certificate-authority-data: server: https://.gr7.us-west-2.eks.amazonaws.com name: arn:aws:eks:us-west-2::cluster/ contexts: - context: cluster: arn:aws:eks:us-west-2::cluster/ user: super-admin name: arn:aws:eks:us-west-2::cluster/ current-context: arn:aws:eks:us-west-2::cluster/ kind: Config preferences: {} users: #- name: arn:aws:eks:us-west-2::cluster/ # user: # exec: # apiVersion: client.authentication.k8s.io/v1beta1 # args: # - --region # - us-west-2 # - eks # - get-token # - --cluster-name # - <> # command: aws # env: null - name: super-admin user: token: <> ``` ## Webhooks de admisión Kubernetes tiene dos tipos de webhooks de admisión: los webhooks de admisión [validan y los webhooks de admisión mutantes](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers). Estos permiten al usuario ampliar la API de kubernetes y validar o mutar los objetos antes de que la API los acepte. Una mala configuración de estos webhooks puede desestabilizar el plano de control de EKS al bloquear las operaciones críticas del clúster. Para evitar afectar a las operaciones críticas del clúster, evite configurar webhooks «generales» como los siguientes: ``` - name: "pod-policy.example.com" rules: - apiGroups: ["*"] apiVersions: ["*"] operations: ["*"] resources: ["*"] scope: "*" ``` O bien, asegúrate de que el webhook tenga una política de apertura por error con un tiempo de espera inferior a 30 segundos para asegurarte de que, si tu webhook no está disponible, no afectará a las cargas de trabajo críticas del clúster. ### Bloquee los pods con unsafe `sysctls` `Sysctl`es una utilidad de Linux que permite a los usuarios modificar los parámetros del núcleo durante el tiempo de ejecución. Estos parámetros del núcleo controlan varios aspectos del comportamiento del sistema operativo, como la red, el sistema de archivos, la memoria virtual y la administración de procesos. Kubernetes permite asignar `sysctl` perfiles a los pods. Kubernetes se clasifica como seguro e inseguro. `systcls` Los espacios de nombres del contenedor o del pod `sysctls` son seguros, y configurarlos no afecta a los demás pods del nodo ni al nodo en sí. Por el contrario, los sysctls no seguros están deshabilitados de forma predeterminada, ya que pueden interrumpir otros pods o hacer que el nodo sea inestable. Como `sysctls` los inseguros están deshabilitados de forma predeterminada, el kubelet no creará un pod con un perfil inseguro. `sysctl` Si creas un pod de este tipo, el programador los asignará repetidamente a los nodos, mientras que el nodo no podrá lanzarlo. En última instancia, este bucle infinito sobrecarga el plano de control del clúster, lo que hace que el clúster sea inestable. Considera usar [OPA Gatekeeper](https://github.com/open-policy-agent/gatekeeper-library/blob/377cb915dba2db10702c25ef1ee374b4aa8d347a/src/pod-security-policy/forbidden-sysctls/constraint.tmpl) o [Kyverno para rechazar los Pods que no](https://kyverno.io/policies/pod-security/baseline/restrict-sysctls/restrict-sysctls/) sean seguros. `sysctls` ## Gestión de las actualizaciones de clústeres Desde abril de 2021, el ciclo de lanzamiento de Kubernetes ha cambiado de cuatro versiones al año (una vez por trimestre) a tres versiones al año. Una nueva versión secundaria (como la 1. **21** o 1. **22**) se publica aproximadamente [cada quince semanas](https://kubernetes.io/blog/2021/07/20/new-kubernetes-release-cadence/#what-s-changing-and-when). A partir de la versión 1.19 de Kubernetes, cada versión secundaria recibe soporte durante aproximadamente doce meses después de su lanzamiento por primera vez. Con la llegada de la versión 1.28 de Kubernetes, el sesgo de compatibilidad entre el plano de control y los nodos de trabajo ha pasado de las versiones n-2 a las n-3 secundarias. [Para obtener más información, consulte Prácticas recomendadas para las actualizaciones de clústeres.](cluster-upgrades.md) ## Conectividad de terminales de clúster Al trabajar con Amazon EKS (Elastic Kubernetes Service), es posible que se produzcan errores o tiempos de espera de conexión durante eventos como el escalado del plano de control de Kubernetes o la aplicación de parches. Estos eventos pueden provocar el reemplazo de las instancias de kube-apiserver, lo que podría provocar que se devuelvan direcciones IP diferentes al resolver el FQDN. En este documento, se describen las mejores prácticas para que los consumidores de las API de Kubernetes mantengan una conectividad fiable. **nota** La implementación de estas mejores prácticas puede requerir actualizaciones en las configuraciones o los scripts de los clientes para gestionar las nuevas estrategias de reresolución y reintento del DNS de forma eficaz. El principal problema se debe al almacenamiento en caché del DNS en el lado del cliente y a la posibilidad de que las direcciones IP del terminal EKS queden obsoletas (*NLB público en el caso de los terminales públicos* o privados). X-ENI Cuando se sustituyen las instancias de kube-apiserver, el nombre de dominio completo (FQDN) puede convertirse en nuevas direcciones IP. Sin embargo, debido a la configuración del tiempo de vida (TTL) del DNS, que se establece en 60 segundos en la zona Route 53 gestionada por AWS, los clientes pueden seguir utilizando direcciones IP anticuadas durante un breve período de tiempo. Para mitigar estos problemas, los usuarios de las API de Kubernetes (como kubectl, CI/CD pipelines y aplicaciones personalizadas) deberían implementar las siguientes prácticas recomendadas: + Implemente la reresolución de DNS + Implemente los reintentos con Backoff y Jitter. Por ejemplo, consulte [este artículo](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/) titulado Los fallos ocurren + Implemente los tiempos de espera de los clientes. Establezca los tiempos de espera adecuados para evitar que las solicitudes de larga duración bloqueen su aplicación. Tenga en cuenta que es posible que algunas bibliotecas cliente de Kubernetes, especialmente las generadas por los generadores de OpenAPI, no permitan configurar fácilmente los tiempos de espera personalizados. + Ejemplo 1 con kubectl: ``` kubectl get pods --request-timeout 10s # default: no timeout ``` + Ejemplo 2 con Python: el [cliente de Kubernetes proporciona](https://github.com/kubernetes-client/python/blob/release-30.0/kubernetes/client/api_client.py#L120) un parámetro \_request\_timeout Al implementar estas mejores prácticas, puedes mejorar significativamente la confiabilidad y la resiliencia de tus aplicaciones al interactuar con la API de Kubernetes. Recuerda probar estas implementaciones exhaustivamente, especialmente en condiciones de fallo simuladas, para asegurarte de que se comportan como se espera durante los eventos reales de escalado o aplicación de parches. ## Ejecutar clústeres de gran tamaño EKS monitorea activamente la carga en las instancias del plano de control y las escala automáticamente para garantizar un alto rendimiento. Sin embargo, debe tener en cuenta los posibles problemas y límites de rendimiento en Kubernetes y las cuotas en los servicios de AWS cuando ejecute clústeres grandes. + Según las [pruebas realizadas](https://www.projectcalico.org/comparing-kube-proxy-modes-iptables-or-ipvs/) por el equipo, los clústeres con más de 1000 servicios pueden experimentar una latencia de red si se utilizan `kube-proxy` en `iptables` modo in. ProjectCalico La solución es cambiar al [`ipvs`modo `kube-proxy` de ejecución](ipvs.md). + También es posible que se limiten las [solicitudes de la API de EC2](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/throttling.html) si el CNI necesita solicitar direcciones IP para los pods o si necesita crear nuevas instancias de EC2 con frecuencia. Puede reducir las llamadas a la API EC2 configurando la CNI para que almacene en caché las direcciones IP. Puede usar tipos de instancias EC2 más grandes para reducir los eventos de escalado de EC2. ## Recursos adicionales: + [De-mystifyingredes de clústeres para nodos de trabajo de Amazon EKS](https://aws.amazon.com/blogs/containers/de-mystifying-cluster-networking-for-amazon-eks-worker-nodes/) + [Control de acceso al punto final del clúster Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/cluster-endpoint.html) + [AWS re:Invent 2019: Amazon EKS bajo el capó () CON421-R1](https://www.youtube.com/watch?v=7vxDWDD2YnM)