Arquitectura EKS Recomendaciones Supervise las métricas del plano de control Autenticación de Webhooks de admisión Cómo gestionar las actualizaciones de un clúster Conectividad de terminales de clúster Ejecución de clústeres grandes Recursos adicionales:

Plano de control EKS

sugerencia

Explore 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 facilita la ejecución de Kubernetes en AWS sin necesidad de instalar, operar y mantener su propio plano de control o nodos de trabajo de Kubernetes. Funciona en la fase inicial de Kubernetes y cuenta con la certificación de conformidad 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 la versión anterior de Kubernetes 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 falla que pueda comprometer la disponibilidad y la durabilidad del plano de control de Kubernetes.

El plano de control de Kubernetes administrado por EKS se ejecuta dentro de una VPC administrada por EKS. El plano de control de EKS comprende los nodos del servidor de la API de Kubernetes, el clúster, etc. Nodos del servidor de API de Kubernetes que ejecutan componentes como el servidor de API, el planificador y se ejecutan en un grupo de escalado automático. kube-controller-manager 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 escalado automático que abarca tres zonas de disponibilidad. 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 sola zona de disponibilidad no afecte a la disponibilidad del clúster de EKS.

Cuando crea un nuevo clúster, Amazon EKS crea un punto final de alta disponibilidad para el servidor de API de Kubernetes administrado que utiliza para comunicarse con su clúster (mediante herramientas como). kubectl El punto de enlace administrado usa NLB para equilibrar la carga de los servidores de API de Kubernetes. EKS también aprovisiona dos ENI en diferentes zonas de disponibilidad para facilitar la comunicación con los nodos de trabajo.

Conectividad de red del plano de datos EKS

Puede configurar si se puede acceder al servidor de API de su clúster de Kubernetes desde la Internet pública (mediante el punto de conexión público) o a través de su VPC (mediante el EKS-managed eNIS) o ambos.

Ya sea que los usuarios y los nodos de trabajo se conecten al servidor de API mediante el punto final público o el EKS-managed ENI, existen rutas de conexión redundantes.

Recomendaciones

Revisa 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 en mal estado 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 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.

Puedes usar Prometheus para recopilar y almacenar estas métricas. En mayo de 2020, CloudWatch se agregó soporte para monitorear las métricas de Prometheus en Container Insights. CloudWatch Por lo tanto, también puede usar Amazon CloudWatch para monitorear el plano de control del EKS. Puedes usar Tutorial for Add a New Prometheus Scrape Target: Prometheus KPI Server Metrics para recopilar métricas y crear un CloudWatch panel para supervisar el plano de control de tu clúster.

Puedes encontrar las métricas del servidor de la 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.

Considera la posibilidad de supervisar 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 prueba, 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 identifican por nombre, operación, rejection_code, tipo (validando o admitiendo), error_type (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 un 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 la versión 1.28 de EKS)	Tamaño de la base de datos Etcd.

Las métricas del histograma incluyen los sufijos _bucket, _sum y _count.

Considera la posibilidad de utilizar el panel de información general sobre la supervisión de Kubernetes para visualizar y supervisar las solicitudes del servidor 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 y la autenticación de IAM, que utiliza la autenticación mediante tokens de webhook. Cuando los usuarios llaman a la API de Kubernetes, un webhook transfiere a IAM un token de autenticación incluido en la solicitud. El token, una URL firmada en 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 gestionar el acceso al clúster de EKS editando el mapa de configuración de aws-auth.

Si configura mal el aws-auth mapa de configuración y pierde el acceso al clúster, puede seguir usando el usuario o la función del creador del clúster para acceder al clúster de EKS.

En el improbable caso de que no puedas usar el servicio de IAM en la región de AWS, también puedes 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 en el clúster:


kubectl -n kube-system create serviceaccount super-admin

Crea un enlace de roles que asigne el rol de superadministrador al de administrador del clúster:


kubectl create clusterrolebinding super-admin-rb --clusterrole=cluster-admin --serviceaccount=kube-system:super-admin

Obtenga 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`

Agregue la cuenta de servicio y el token akubeconfig:


kubectl config set-credentials super-admin --token=$TOKEN

Configura el contexto actual para usar la cuenta kubeconfig de superadministrador:


kubectl config set-context --current --user=super-admin

La final kubeconfig debería tener este aspecto:


apiVersion: v1
clusters:
- cluster:
    certificate-authority-data:<REDACTED>
    server: https://<CLUSTER>.gr7.us-west-2.eks.amazonaws.com
  name: arn:aws:eks:us-west-2:<account number>:cluster/<cluster name>
contexts:
- context:
    cluster: arn:aws:eks:us-west-2:<account number>:cluster/<cluster name>
    user: super-admin
  name: arn:aws:eks:us-west-2:<account number>:cluster/<cluster name>
current-context: arn:aws:eks:us-west-2:<account number>:cluster/<cluster name>
kind: Config
preferences: {}
users:
#- name: arn:aws:eks:us-west-2:<account number>:cluster/<cluster name>
#  user:
#    exec:
#      apiVersion: client.authentication.k8s.io/v1beta1
#      args:
#      - --region
#      - us-west-2
#      - eks
#      - get-token
#      - --cluster-name
#      - <<cluster name>>
#      command: aws
#      env: null
- name: super-admin
  user:
    token: <<super-admin sa's secret>>

Webhooks de admisión

Kubernetes tiene dos tipos de webhooks de admisión: los de validación y los de admisión mutantes. Permiten al usuario ampliar la API de Kubernetes y validar o mutar objetos antes de que la API los acepte. Las configuraciones incorrectas de estos webhooks pueden 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, evita establecer webhooks «generales», como los siguientes:


- name: "pod-policy.example.com"
  rules:
  - apiGroups:   ["*"]
    apiVersions: ["*"]
    operations:  ["*"]
    resources:   ["*"]
    scope: "*"

O asegúrate de que el webhook tenga una política de apertura fallida 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 para el clúster.

Bloquea los pods con sysctls no seguros

Sysctles 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 kernel 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 clasifica como seguro e inseguro. systcls sysctlsLos seguros son espacios de nombres en el contenedor o el pod, 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 afectar a otros pods o hacer que el nodo sea inestable.

Como sysctls los no seguros 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 asignará dichos pods repetidamente a los nodos, mientras el nodo no pueda lanzarlo. En última instancia, este bucle infinito agota el plano de control del clúster, lo que hace que el clúster sea inestable.

Considera usar OPA Gatekeeper o Kyverno para rechazar los pods que no sean seguros. sysctls

Cómo gestionar las actualizaciones de un clúster

Desde abril de 2021, el ciclo de lanzamiento de Kubernetes ha pasado de cuatro lanzamientos al año (una vez por trimestre) a tres lanzamientos al año. Una nueva versión secundaria (como 1). 21 o 1. 22) se publica aproximadamente cada quince semanas. A partir de la versión 1.19 de Kubernetes, cada versión secundaria cuenta con soporte durante aproximadamente doce meses a partir de su primera publicación. 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 pasó de tener versiones secundarias n-2 a n-3. Para obtener más información, consulta las prácticas recomendadas para las actualizaciones de clústeres. Mejores prácticas para las actualizaciones de clústeres

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 o la aplicación de parches en el plano de control de Kubernetes. Estos eventos pueden provocar la sustitución de las instancias de kube-apiserver, lo que puede provocar que se devuelvan direcciones IP diferentes al resolver el FQDN. Este documento describe las mejores prácticas para que los consumidores de la API de Kubernetes mantengan una conectividad confiable.

nota

La implementación de estas mejores prácticas puede requerir actualizar las configuraciones o los scripts de los clientes para gestionar las nuevas estrategias de reintento y resolución del DNS de manera 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 de los terminales de EKS queden obsoletas (NLB públicas para las terminales públicas o privadas). 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 administrada por AWS, los clientes pueden seguir utilizando direcciones IP desactualizadas durante un breve período de tiempo.

Para mitigar estos problemas, los consumidores de las API de Kubernetes (como kubectl, CI/CD pipelines y aplicaciones personalizadas) deben implementar las siguientes prácticas recomendadas:

Implemente la reresolución de DNS
Implemente los reintentos con backoff y Jitter. Por ejemplo, consulta este artículo titulado Los errores ocurren
Implemente los tiempos de espera de los clientes. Establezca tiempos de espera adecuados para evitar que las solicitudes de larga duración bloqueen su aplicación. Ten en cuenta que es posible que algunas bibliotecas cliente de Kubernetes, en particular las generadas por los generadores de OpenAPI, no permitan configurar fácilmente 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 un parámetro _request_timeout

Al implementar estas prácticas recomendadas, puedes mejorar significativamente la confiabilidad y la resiliencia de tus aplicaciones al interactuar con la API de Kubernetes. Recuerda probar estas implementaciones minuciosamente, especialmente en condiciones de fallo simuladas, para asegurarte de que se comportan según lo esperado durante los eventos reales de escalado o aplicación de parches.

Ejecución de clústeres grandes

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 de rendimiento y los límites de Kubernetes y las cuotas de los servicios de AWS cuando ejecute clústeres grandes.

Según las pruebas realizadas por el equipo, los clústeres con más de 1000 servicios pueden experimentar latencia de red si se utilizan kube-proxy en iptables modo activo. ProjectCalico La solución es cambiar al ipvs modo kube-proxy de ejecución.
También es posible que se limiten las solicitudes de la API de EC2 si el CNI necesita solicitar direcciones IP para los pods o si necesitas crear nuevas instancias de EC2 con frecuencia. Puedes reducir las llamadas a la API EC2 configurando el CNI para almacenar en caché las direcciones IP. Puede usar tipos de instancias EC2 más grandes para reducir los eventos de escalado de EC2.

Recursos adicionales:

Aviso JavaScript está desactivado o no está disponible en su navegador.

Para utilizar la documentación de AWS, debe estar habilitado JavaScript. Para obtener más información, consulte las páginas de ayuda de su navegador.

Convenciones del documento

Aplicaciones

Plano de datos