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. # Prácticas recomendadas para implementaciones híbridas Esta guía proporciona orientación sobre cómo ejecutar despliegues en entornos locales o periféricos con EKS Hybrid Nodes o EKS Anywhere. Actualmente, hemos publicado guías sobre los siguientes temas: + [Mejores prácticas para los nodos híbridos de EKS y las desconexiones de red](hybrid-nodes-network-disconnections.md) # Nodos híbridos EKS y desconexiones de red La arquitectura de nodos híbridos de EKS puede resultar nueva para los clientes que están acostumbrados a ejecutar clústeres de Kubernetes locales por completo en sus propios centros de datos o ubicaciones periféricas. Con los nodos híbridos de EKS, el plano de control de Kubernetes se ejecuta en una región de AWS y solo los nodos se ejecutan de forma local, lo que da como resultado una arquitectura de clúster de Kubernetes «extendida» o «extendida». Esto lleva a una pregunta común: «¿Qué ocurre si mis nodos se desconectan del plano de control de Kubernetes?» En esta guía, respondemos a esa pregunta mediante una revisión de los siguientes temas. Se recomienda validar la estabilidad y la fiabilidad de las aplicaciones mediante la desconexión de la red, ya que cada aplicación puede comportarse de forma diferente en función de sus dependencias, configuración y entorno. Consulte el aws-samples/ eks-hybrid-examples GitHub repo para ver la configuración, los procedimientos y los resultados de las pruebas que puede consultar para probar las desconexiones de red con los nodos híbridos de EKS y sus propias aplicaciones. El GitHub repositorio también contiene detalles adicionales de las pruebas utilizadas para validar el comportamiento explicado en esta guía. + [Mejores prácticas para garantizar la estabilidad mediante las desconexiones de la red](hybrid-nodes-network-disconnection-best-practices.md) + [Comportamiento de conmutación por error del pod de Kubernetes mediante desconexiones de red](hybrid-nodes-kubernetes-pod-failover.md) + [Tráfico de red de aplicaciones a través de desconexiones de red](hybrid-nodes-app-network-traffic.md) + [Aloje las credenciales mediante desconexiones de red](hybrid-nodes-host-creds.md) # Mejores prácticas para garantizar la estabilidad mediante las desconexiones de la red ## Redes de alta disponibilidad El mejor enfoque para evitar las desconexiones de red entre los nodos híbridos y el plano de control de Kubernetes es utilizar conexiones redundantes y resilientes desde el entorno local hacia y desde AWS. Consulte el [kit de herramientas de resiliencia de AWS Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/resiliency_toolkit.html) y la [documentación de AWS Site-to-Site VPN](https://docs.aws.amazon.com/vpn/latest/s2svpn/vpn-redundant-connection.html) para obtener más información sobre cómo diseñar redes híbridas de alta disponibilidad con esas soluciones. ## Aplicaciones de alta disponibilidad Al diseñar la arquitectura de las aplicaciones, tenga en cuenta los dominios de los fallos y los efectos de los distintos tipos de interrupciones. Kubernetes proporciona mecanismos integrados para implementar y mantener réplicas de aplicaciones en dominios de nodos, zonas y regiones. El uso de estos mecanismos depende de la arquitectura de la aplicación, los entornos y los requisitos de disponibilidad. Por ejemplo, las aplicaciones sin estado a menudo se pueden implementar con múltiples réplicas y se pueden mover entre hosts y capacidades de infraestructura arbitrarias, y puede usar selectores de nodos y restricciones de distribución de topología para ejecutar instancias de la aplicación en diferentes dominios. [Para obtener más información sobre las técnicas a nivel de aplicación para crear aplicaciones resilientes en Kubernetes, consulte la Guía de mejores prácticas de EKS.](https://aws.github.io/aws-eks-best-practices/reliability/docs/application/) Kubernetes evalúa la información zonal de los nodos que están desconectados del plano de control de Kubernetes al determinar si se deben mover los pods a otros nodos. Si no se puede acceder a todos los nodos de una zona, Kubernetes cancela los desalojos de los nodos de esa zona. Como práctica recomendada, si tiene una implementación con nodos que se ejecutan en varios centros de datos o ubicaciones físicas, asigne una zona a cada nodo en función de su centro de datos o ubicación física. Cuando ejecuta EKS con nodos en la nube, AWS aplica automáticamente esta etiqueta de zona cloud-controller-manager. Sin embargo, a no cloud-controller-manager se usa con nodos híbridos, por lo que puede pasar esta información a través de su configuración de kubelet. A continuación, se muestra un ejemplo de cómo configurar una zona en la configuración de nodos para nodos híbridos. La configuración se transfiere al conectar los nodos híbridos al clúster con la CLI (`nodeadm`) de los nodos híbridos. Para obtener más información sobre la `topology.kubernetes.io/zone` etiqueta, consulta la documentación de [Kubernetes](https://kubernetes.io/docs/reference/labels-annotations-taints/#topologykubernetesiozone). Para obtener más información sobre la CLI de los nodos híbridos, consulte la referencia [nodeadm de los nodos híbridos](https://docs.aws.amazon.com/eks/latest/userguide/hybrid-nodes-nodeadm.html). ``` apiVersion: node.eks.aws/v1alpha1 kind: NodeConfig spec: cluster: name: my-cluster region: my-region kubelet: flags: - --node-labels=topology.kubernetes.io/zone=dc1 hybrid: ... ``` ## Monitorización de la red Si utiliza AWS Direct Connect o AWS Site-to-Site VPN para su conectividad híbrida, puede aprovechar CloudWatch las alarmas, los registros y las métricas para observar el estado de la conexión híbrida y diagnosticar problemas. Para obtener más información, consulte [Supervisión de los recursos de AWS Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/monitoring-overview.html) y [Supervisión de una conexión Site-to-Site VPN de AWS](https://docs.aws.amazon.com/vpn/latest/s2svpn/monitoring-overview-vpn.html). Se recomienda crear alarmas para `NodeNotReady` los eventos notificados por la node-lifecycle-controller ejecución en el plano de control del EKS, lo que indica que un nodo híbrido podría estar sufriendo una desconexión de la red. Para crear esta alarma, habilite el registro del plano de control EKS para el Controller Manager y cree un filtro métrico CloudWatch para el mensaje «Grabando un mensaje de evento de cambio de estado para el nodo» con el status= «». NodeNotReady Tras crear un filtro métrico, puede crear una alarma para este filtro en función de los umbrales que desee. Para obtener más información, consulte [Alarmar los registros en la CloudWatch documentación](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Alarm-On-Logs.html). Puede usar las métricas integradas Transit Gateway (TGW) y Virtual Private Gateway (VGW) para observar el tráfico de red que entra y sale de su TGW o VGW. Puede crear alarmas para estas métricas a fin de detectar situaciones en las que el tráfico de la red cae por debajo de los niveles normales, lo que indica un posible problema de red entre los nodos híbridos y el plano de control del EKS. Las métricas de TGW y VGW se describen en la siguiente tabla. | Puerta de enlace | Métrica | Description (Descripción) | | --- | --- | --- | | Transit Gateway | BytesIn | Los bytes recibidos por TGW desde el archivo adjunto (del plano de control EKS a los nodos híbridos) | | Transit Gateway | BytesOut | Los bytes enviados desde TGW al adjunto (nodos híbridos al plano de control EKS) | | Puerta de enlace privada virtual | TunnelDataIn | Los bytes enviados desde el lado de AWS de la conexión a través del túnel VPN hasta la puerta de enlace del cliente (del plano de control EKS a los nodos híbridos) | | Puerta de enlace privada virtual | TunnelDataOut | Los bytes recibidos en el lado de AWS de la conexión a través del túnel VPN desde la puerta de enlace del cliente (nodos híbridos al plano de control de EKS) | También puede usar [CloudWatch Network Monitor](https://aws.amazon.com/blogs/networking-and-content-delivery/monitor-hybrid-connectivity-with-amazon-cloudwatch-network-monitor/) para obtener una visión más profunda de sus conexiones híbridas a fin de reducir el tiempo medio de recuperación y determinar si los problemas de red se originan en AWS o en su entorno. CloudWatch El monitor de red se puede utilizar para visualizar la pérdida de paquetes y la latencia en las conexiones de la red híbrida, establecer alertas y umbrales y, a continuación, tomar medidas para mejorar el rendimiento de la red. Para obtener más información, consulte [Uso de Amazon CloudWatch Network Monitor](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/what-is-network-monitor.html). EKS ofrece varias opciones para monitorear el estado de sus clústeres y aplicaciones. Para conocer el estado del clúster, puede utilizar el panel de observabilidad de la consola de EKS para detectar, solucionar y solucionar problemas rápidamente. También puede usar Amazon Managed Service para Prometheus, AWS Distro for Open Telemetry (ADOT) y para la supervisión de clústeres CloudWatch , aplicaciones e infraestructuras. Para obtener más información sobre las opciones de observabilidad de EKS, consulte [Supervisar el rendimiento del clúster y ver los registros](https://docs.aws.amazon.com/eks/latest/userguide/eks-observe.html). ## Solución de problemas locales Para prepararse para las desconexiones de la red entre los nodos híbridos y el plano de control de EKS, puede configurar backends secundarios de monitoreo y registro para mantener la observabilidad de las aplicaciones cuando no se pueda acceder a los servicios regionales de AWS. Por ejemplo, puede configurar el recopilador AWS Distro for Open Telemetry (ADOT) para enviar métricas y registros a varios backends. También puedes usar herramientas locales, como la `crictl` CLI, para interactuar localmente con los pods y contenedores como reemplazo de otros clientes compatibles con la API de Kubernetes que normalmente consultan el punto final del servidor de la API de Kubernetes. `kubectl` [Para obtener más información, consulte la documentación de cri-tools`crictl`. `crictl`](https://github.com/kubernetes-sigs/cri-tools/blob/master/docs/crictl.md) GitHub A continuación se enumeran algunos `crictl` comandos útiles. Enumere los pods que se ejecutan en el host: ``` crictl pods ``` Enumere los contenedores que se ejecutan en el host: ``` crictl ps ``` Enumere las imágenes que se ejecutan en el host: ``` crictl images ``` Obtenga los registros de un contenedor que se ejecuta en el host: ``` crictl logs CONTAINER_NAME ``` Obtenga estadísticas de los pods que se ejecutan en el host: ``` crictl statsp ``` ## Tráfico de red de aplicaciones Al utilizar nodos híbridos, es importante tener en cuenta y comprender los flujos de red del tráfico de las aplicaciones y las tecnologías que se utilizan para exponer las aplicaciones de forma externa al clúster. Las diferentes tecnologías para el equilibrio de carga y la entrada de aplicaciones se comportan de forma diferente durante las desconexiones de la red. Por ejemplo, si utiliza la función del plano de control BGP de Cilium para equilibrar la carga de las aplicaciones, es posible que la sesión de BGP de sus pods y servicios se interrumpa durante las desconexiones de la red. Esto se debe a que la funcionalidad del altavoz BGP está integrada en el agente Cilium, y este se reiniciará continuamente cuando se desconecte del plano de control de Kubernetes. El motivo del reinicio se debe a que la comprobación del estado de Cilium ha fallado, ya que su estado va acompañado del acceso al plano de control de Kubernetes (véase [CFP](https://github.com/cilium/cilium/issues/31702): \$131702, con una mejora opcional en la versión 1.17 de Cilium). Del mismo modo, si utiliza balanceadores de carga de aplicaciones (ALB) o balanceadores de carga de red (NLB) para el tráfico de aplicaciones originado en la región de AWS, es posible que ese tráfico se interrumpa temporalmente si su entorno local pierde la conectividad con la región de AWS. Se recomienda comprobar que las tecnologías que utiliza para el equilibrio de carga y la entrada permanezcan estables durante las desconexiones de la red antes de implementarlas en producción. El ejemplo del [aws-samples/ eks-hybrid-examples](https://github.com/aws-samples/eks-hybrid-examples) GitHub repo utiliza MetallB para equilibrar la carga en el [modo L2](https://metallb.universe.tf/concepts/layer2/), que permanece estable durante las desconexiones de red entre los nodos híbridos y el plano de control de EKS. ## Revise las dependencias de los servicios remotos de AWS Cuando utilice nodos híbridos, tenga en cuenta las dependencias que asume con los servicios regionales de AWS que son externos a su entorno local o periférico. Algunos ejemplos incluyen el acceso a Amazon S3 o Amazon RDS para los datos de la aplicación, el uso de Amazon Managed Service for Prometheus CloudWatch o para obtener métricas y registros, el uso de balanceadores de carga de redes y aplicaciones para el tráfico originado en la región y la extracción de contenedores de Amazon Elastic Container Registry. No se podrá acceder a estos servicios durante las desconexiones de red entre su entorno local y AWS. Si su entorno local es propenso a desconectarse de la red con AWS, revise el uso que hace de los servicios de AWS y asegúrese de que la pérdida de la conexión a esos servicios no comprometa la estabilidad estática de sus aplicaciones. ## Ajuste el comportamiento de conmutación por error del pod de Kubernetes Existen opciones para ajustar el comportamiento de la conmutación por error del pod durante las desconexiones de la red para las aplicaciones que no son portátiles entre los hosts o para los entornos con recursos limitados que no tienen capacidad sobrante para la conmutación por error de los pods. Por lo general, es importante tener en cuenta los requisitos de recursos de las aplicaciones y disponer de la capacidad suficiente para que una o más instancias de la aplicación se conmuten por error a un host diferente en caso de que se produzca un error en un nodo. + Opción 1: Uso DaemonSets: esta opción se aplica a las aplicaciones que pueden y deben ejecutarse en todos los nodos del clúster. DaemonSets se configuran automáticamente para tolerar la contaminación inalcanzable, que mantiene a los DaemonSet pods conectados a sus nodos debido a las desconexiones de la red. + Opción 2: Ajustarlos `tolerationSeconds` para evitar que se vean contaminados: puedes ajustar el tiempo que los pods permanecen conectados a los nodos durante las desconexiones de la red. Para ello, configure los pods de aplicaciones para que toleren la contaminación inalcanzable con el `NoExecute` efecto que especifique (en las especificaciones de la aplicación). `tolerationSeconds` Con esta opción, cuando se producen desconexiones de red, los pods de aplicaciones permanecen enlazados a los nodos hasta que caduquen. `tolerationSeconds` Tenga esto en cuenta, ya que si se aumenta la contaminación `tolerationSeconds` por lo inalcanzable, los pods que `NoExecute` se ejecutan en hosts inalcanzables pueden tardar más en trasladarse a otros hosts accesibles y en buen estado. + Opción 3: Controlador personalizado: puedes crear y ejecutar un controlador personalizado (u otro software) que supervise Kubernetes en busca de la contaminación inalcanzable que provoca este efecto. `NoExecute` Cuando se detecta esta contaminación, el controlador personalizado puede comprobar las métricas específicas de la aplicación para evaluar su estado. Si la aplicación está en buen estado, el controlador personalizado puede eliminar la contaminación inalcanzable e impedir que se desalojen los pods de los nodos durante las desconexiones de la red. A continuación, se muestra un ejemplo de cómo configurar una implementación con `tolerationSeconds` una contaminación inalcanzable. En el ejemplo, `tolerationSeconds` está configurado en `1800` (30 minutos), lo que significa que los pods que se ejecuten en nodos inalcanzables solo se desalojarán si la desconexión de la red dura más de 30 minutos. ``` apiVersion: apps/v1 kind: Deployment metadata: ... spec: ... tolerations: - key: "node.kubernetes.io/unreachable" operator: "Exists" effect: "NoExecute" tolerationSeconds: 1800 ``` # Conmutación por error de los pods de Kubernetes mediante desconexiones de red Comenzamos con una revisión de los conceptos, componentes y configuraciones clave que influyen en el comportamiento de Kubernetes durante las desconexiones de red entre los nodos y el plano de control de Kubernetes. En principio, EKS se ajusta a Kubernetes, por lo que todos los conceptos, componentes y configuraciones de Kubernetes que se describen aquí se aplican a las implementaciones de EKS y EKS Hybrid Nodes. [https://github.com/kubernetes/kubernetes/pull/131294](https://github.com/kubernetes/kubernetes/pull/131294) ## Conceptos Contaminaciones y tolerancias: en Kubernetes se utilizan las restricciones y tolerancias para controlar la programación de los pods en los nodos. Los límites se establecen node-lifecycle-controller para indicar que los nodos no son aptos para la programación o que se deben desalojar los módulos de esos nodos. Cuando no se puede acceder a los nodos debido a una desconexión de la red, se aplica el comando node.kubernetes. node-lifecycle-controller io/unreachable taint with a NoSchedule effect, and with a NoExecute effect if certain conditions are met. The node.kubernetes.io/unreachabletaint NodeCondition corresponde a que Ready being Unknown. Los usuarios pueden especificar las tolerancias de contaminación a nivel de aplicación en el. PodSpec + NoSchedule: No hay nuevos pods programados en el nodo contaminado a menos que tengan una tolerancia coincidente. Los pods que ya se están ejecutando en el nodo no se desalojan. + NoExecute: Las cápsulas que no toleran la contaminación se desalojan inmediatamente. Las cápsulas que toleran la contaminación (sin especificar los segundos de tolerancia) permanecen atadas para siempre. Los pods que toleran la contaminación con un TolerationSeconds específico permanecen enlazados durante el tiempo especificado. Una vez transcurrido ese tiempo, el controlador del ciclo de vida del nodo expulsa los pods del nodo. Arrendamientos de nodos: Kubernetes usa la API de arrendamiento para comunicar los latidos de los nodos de Kubelet al servidor de la API de Kubernetes. Para cada nodo, hay un objeto de arrendamiento con un nombre coincidente. Internamente, cada latido del kubelet actualiza el campo spec.RenewTime del objeto Lease. El plano de control de Kubernetes usa la marca de tiempo de este campo para determinar la disponibilidad de los nodos. Si los nodos están desconectados del plano de control de Kubernetes, no pueden actualizar Spec.RenewTime para su arrendamiento, y el plano de control interpreta que está listo para ser desconocido. NodeCondition ## Componentes ![\[Los componentes de Kubernetes están involucrados en el comportamiento de conmutación por error del pod\]](http://docs.aws.amazon.com/es_es/eks/latest/best-practices/images/hybrid/k8s-components-pod-failover.png) | Componente | Subcomponente | Description (Descripción) | | --- | --- | --- | | Plano de control de Kubernetes | kube-api-server | El servidor de API es un componente central del plano de control de Kubernetes que expone la API de Kubernetes. | | Plano de control de Kubernetes | node-lifecycle-controller | Uno de los controladores que ejecuta. kube-controller-manager Es responsable de detectar y responder a los problemas de los nodos. | | Plano de control de Kubernetes | programador de kube | Un componente del plano de control que observa los pods recién creados sin un nodo asignado y selecciona un nodo en el que ejecutarlos. | | nodos de Kubernetes | kubelet | Un agente que se ejecuta en cada nodo del clúster. El kubelet vigila PodSpecs y se asegura de que los contenedores descritos en ellas PodSpecs estén funcionando y en buen estado. | ## Opciones de configuración | Componente | Opción | Description (Descripción) | K8 es el predeterminado | Predeterminado por EKS | Configurable en EKS | | --- | --- | --- | --- | --- | --- | | kube-api-server | default-unreachable-toleration-seconds | Indica `tolerationSeconds` si la tolerancia `unreachable:NoExecute` que se añade de forma predeterminada a todos los módulos que aún no tienen dicha tolerancia. | 300 | 300 | No | | node-lifecycle-controller | node-monitor-grace-period | El tiempo que un nodo puede estar inactivo antes de que se marque como no está en buen estado. Debe ser N veces mayor que el de kubelet`nodeStatusUpdateFrequency`, donde N es el número de reintentos permitidos para que el kubelet publique el estado de nodo. | 40 | 40 | No | | node-lifecycle-controller | large-cluster-size-threshold | El número de nodos en los que considera que el clúster es grande node-lifecycle-controller para la lógica de desalojo. `--secondary-node-eviction-rate`se sustituye por 0 para los clústeres de este tamaño o más pequeños. | 50 | 100 000 | No | | node-lifecycle-controller | unhealthy-zone-threshold | El porcentaje de nodos de una zona que no deben estar preparados para que esa zona se considere en mal estado. | 55% | 55% | No | | kubelet | node-status-update-frequency | Con qué frecuencia el kubelet publica el estado del nodo en el plano de control. Debe ser compatible con `nodeMonitorGracePeriod` in. node-lifecycle-controller | 10 | 10 | Sí | | kubelet | etiquetas de nodo | Etiquetas para añadir al registrar el nodo en el clúster. La etiqueta se `topology.kubernetes.io/zone` puede especificar con nodos híbridos para agrupar los nodos en zonas. | Ninguno | Ninguno | Sí | ## Conmutación por error del pod de Kubernetes mediante desconexiones de red El comportamiento que se describe aquí supone que los pods se ejecutan como despliegues de Kubernetes con la configuración predeterminada y que EKS se utiliza como proveedor de Kubernetes. El comportamiento real puede variar según el entorno, el tipo de desconexión de la red, las aplicaciones, las dependencias y la configuración del clúster. El contenido de esta guía se validó mediante una aplicación, una configuración de clúster y un subconjunto de complementos específicos. Se recomienda encarecidamente probar el comportamiento en su propio entorno y con sus propias aplicaciones antes de pasar a la fase de producción. Cuando hay desconexiones de red entre los nodos y el plano de control de Kubernetes, el kubelet de cada nodo desconectado no puede comunicarse con el plano de control de Kubernetes. En consecuencia, el kubelet no puede desalojar los pods de esos nodos hasta que se restablezca la conexión. Esto significa que los pods que se ejecutaban en esos nodos antes de la desconexión de la red seguirán funcionando durante la desconexión, siempre que no haya otros fallos que provoquen su cierre. En resumen, se puede lograr una estabilidad estática durante las desconexiones de la red entre los nodos y el plano de control de Kubernetes, pero no se pueden realizar operaciones de mutación en los nodos o las cargas de trabajo hasta que se restablezca la conexión. Existen cinco escenarios principales que producen diferentes comportamientos de conmutación por error entre los módulos en función de la naturaleza de la desconexión de la red. En todos los escenarios, el clúster vuelve a estar en buen estado sin la intervención del operador una vez que los nodos se vuelven a conectar al plano de control de Kubernetes. Los siguientes escenarios describen los resultados esperados en función de nuestras observaciones, pero es posible que estos resultados no se apliquen a todas las configuraciones posibles de aplicaciones y clústeres. ### Escenario 1: Interrupción total del clúster **Resultado esperado**: los pods de los nodos inalcanzables no se expulsan y siguen ejecutándose en esos nodos. Una interrupción total del clúster significa que todos los nodos del clúster se desconectan del plano de control de Kubernetes. En este escenario, el node-lifecycle-controller plano de control detecta que no se puede acceder a todos los nodos del clúster y cancela cualquier desalojo de un módulo. Los administradores del clúster verán todos los nodos con su estado `Not Ready` durante la desconexión. El estado de los pods no cambia y no se programan nuevos pods en ningún nodo durante la desconexión y la posterior reconexión. ### Escenario 2: Interrupción total de la zona **Resultado esperado**: los pods de los nodos inalcanzables no se expulsan y siguen ejecutándose en esos nodos. Una interrupción total de la zona significa que todos los nodos de la zona están desconectados del plano de control de Kubernetes. En este escenario, el node-lifecycle-controller plano de control detecta que no se puede acceder a todos los nodos de la zona y cancela cualquier desalojo de un módulo. Los administradores del clúster verán todos los nodos con su estado `Not Ready` durante la desconexión. El estado de los pods no cambia y no se programan nuevos pods en ningún nodo durante la desconexión y la posterior reconexión. ### Escenario 3: Interrupción de la zona mayoritaria **Resultado esperado**: los pods de los nodos inalcanzables no se expulsan y siguen ejecutándose en esos nodos. Una interrupción mayoritaria de una zona significa que la mayoría de los nodos de una zona determinada están desconectados del plano de control de Kubernetes. Las zonas de Kubernetes se definen mediante nodos con la misma etiqueta. `topology.kubernetes.io/zone` Si no hay ninguna zona definida en el clúster, una interrupción mayoritaria significa que la mayoría de los nodos de todo el clúster están desconectados. De forma predeterminada, la mayoría se define por s`unhealthy-zone-threshold`, que se establece en un 55% tanto en Kubernetes como en EKS. node-lifecycle-controller Como `large-cluster-size-threshold` está establecido en 100 000 en EKS, si no se puede acceder al 55% o más de los nodos de una zona, se cancelan los desalojos de los pods (dado que la mayoría de los clústeres son mucho más pequeños que 100 000 nodos). Los administradores de clústeres verán la mayoría de los nodos de la zona en estado `Not Ready` durante la desconexión, pero el estado de los pods no cambiará y no se reprogramarán en otros nodos. Tenga en cuenta que el comportamiento anterior solo se aplica a los clústeres de más de tres nodos. En los clústeres de tres nodos o menos, se programa el desalojo de los módulos de los nodos inalcanzables y se programa el desalojo de los nuevos módulos de los nodos en buen estado. Durante las pruebas, en ocasiones observamos que los pods eran expulsados exactamente de un nodo inalcanzable durante las desconexiones de la red, incluso cuando no se podía acceder a la mayoría de los nodos de la zona. Seguimos investigando una posible condición de carrera en Kubernetes como causa de este comportamiento node-lifecycle-controller. ### Escenario 4: Interrupción en una zona minoritaria **Resultado esperado**: se expulsan los pods de los nodos inalcanzables y se programan nuevos pods en los nodos disponibles y aptos. Una interrupción minoritaria significa que un porcentaje menor de nodos de una zona están desconectados del plano de control de Kubernetes. Si no hay ninguna zona definida en el clúster, una interrupción minoritaria significa que la minoría de nodos de todo el clúster está desconectada. Como se ha indicado, la minoría se define mediante el `unhealthy-zone-threshold` ajuste de node-lifecycle-controller, que es del 55% de forma predeterminada. En este escenario, si la desconexión de la red dura más de `default-unreachable-toleration-seconds` (5 minutos) y `node-monitor-grace-period` (40 segundos) y no se puede acceder a menos del 55% de los nodos de una zona, se programan nuevos pods en los nodos en buen estado, mientras que los pods de los nodos inalcanzables se marcan para su desalojo. Los administradores de clústeres verán los nuevos pods creados en los nodos en buen estado y los pods de los nodos desconectados aparecerán como. `Terminating` Recuerde que, aunque los pods de los nodos desconectados tengan un `Terminating` estado, no se desalojarán por completo hasta que el nodo se vuelva a conectar al plano de control de Kubernetes. ## Escenario 5: Reinicio del nodo durante una interrupción de la red **Resultado esperado**: los pods de los nodos inalcanzables no se inician hasta que los nodos se vuelven a conectar al plano de control de Kubernetes. La conmutación por error de los pods sigue la lógica descrita en los escenarios 1 a 3, en función del número de nodos inalcanzables. El reinicio de un nodo durante una interrupción de la red significa que se ha producido otro fallo (como un ciclo de alimentación, un out-of-memory evento u otro problema) en un nodo al mismo tiempo que se desconecta la red. Los pods que se estaban ejecutando en ese nodo cuando se inició la desconexión de la red no se reinician automáticamente durante la desconexión si el kubelet también se ha reiniciado. El kubelet consulta al servidor de la API de Kubernetes durante el inicio para saber qué pods debe ejecutar. Si el kubelet no puede acceder al servidor de la API debido a una desconexión de la red, no podrá recuperar la información necesaria para iniciar los pods. En este escenario, las herramientas de solución de problemas locales, como la `crictl` CLI, no se pueden utilizar para iniciar los pods manualmente como medida de «romper cristales». Por lo general, Kubernetes elimina los pods que fallan y crea otros nuevos en lugar de reiniciar los pods existentes (consulta \$110213 [en](https://github.com/containerd/containerd/pull/10213) el repositorio containerd para obtener más información). GitHub Los pods estáticos son el único objeto de carga de trabajo de Kubernetes que controla el kubelet y que se pueden reiniciar en estos escenarios. Sin embargo, por lo general no se recomienda utilizar pods estáticos para las implementaciones de aplicaciones. En su lugar, despliegue varias réplicas en distintos hosts para garantizar la disponibilidad de las aplicaciones en caso de que se produzcan varios fallos simultáneos, como un fallo en un nodo o una desconexión de la red entre los nodos y el plano de control de Kubernetes. # Tráfico de red de aplicaciones a través de desconexiones de red Los temas de esta página están relacionados con las redes de clústeres de Kubernetes y el tráfico de aplicaciones durante las desconexiones de red entre los nodos y el plano de control de Kubernetes. ## Cilium Cilium tiene varios modos de administración de direcciones IP (IPAM), encapsulación, equilibrio de carga y enrutamiento de clústeres. Los modos validados en esta guía utilizaban el IPAM con alcance de clúster, la superposición de VXLAN, el equilibrio de carga de BGP y el kube-proxy. También se utilizó Cilium sin balanceo de carga BGP, sustituyéndolo por el balanceo de carga MetalLB L2. La base de la instalación Cilium está formada por el operador Cilium y los agentes Cilium. [El operador de Cilium se ejecuta como una implementación y registra las definiciones de recursos personalizadas de Cilium (CRDs), administra el IPAM y sincroniza los objetos del clúster con el servidor API de Kubernetes, entre otras funciones.](https://docs.cilium.io/en/stable/internals/cilium_operator/) Los agentes de Cilium se ejecutan en cada nodo como un programa eBPF DaemonSet y los administran para controlar las reglas de red para las cargas de trabajo que se ejecutan en el clúster. Por lo general, el enrutamiento dentro del clúster configurado por Cilium permanece disponible y activo durante las desconexiones de la red, lo que se puede confirmar observando los flujos de tráfico del clúster y las reglas de la tabla de direcciones IP (iptables) de la red de módulos. ``` ip route show table all | grep cilium ``` ``` 10.86.2.0/26 via 10.86.3.16 dev cilium_host proto kernel src 10.86.3.16 mtu 1450 10.86.2.64/26 via 10.86.3.16 dev cilium_host proto kernel src 10.86.3.16 mtu 1450 10.86.2.128/26 via 10.86.3.16 dev cilium_host proto kernel src 10.86.3.16 mtu 1450 10.86.2.192/26 via 10.86.3.16 dev cilium_host proto kernel src 10.86.3.16 mtu 1450 10.86.3.0/26 via 10.86.3.16 dev cilium_host proto kernel src 10.86.3.16 10.86.3.16 dev cilium_host proto kernel scope link ... ``` Sin embargo, durante las desconexiones de la red, el operador de Cilium y los agentes de Cilium se reinician debido a la combinación de sus comprobaciones de estado con el estado de la conexión con el servidor API de Kubernetes. Se espera que aparezca lo siguiente en los registros del operador de Cilium y de los agentes de Cilium durante las desconexiones de la red. Durante las desconexiones de la red, puede utilizar herramientas como la `crictl` CLI para observar los reinicios de estos componentes, incluidos sus registros. ``` msg="Started gops server" address="127.0.0.1:9890" subsys=gops msg="Establishing connection to apiserver" host="https://:443" subsys=k8s-client msg="Establishing connection to apiserver" host="https://:443" subsys=k8s-client msg="Unable to contact k8s api-server" error="Get \"https://:443/api/v1/namespaces/kube-system\": dial tcp :443: i/o timeout" ipAddr="https://:443" subsys=k8s-client msg="Start hook failed" function="client.(*compositeClientset).onStart (agent.infra.k8s-client)" error="Get \"https://:443/api/v1/namespaces/kube-system\": dial tcp :443: i/o timeout" msg="Start failed" error="Get \"https://:443/api/v1/namespaces/kube-system\": dial tcp :443: i/o timeout" duration=1m5.003834026s msg=Stopping msg="Stopped gops server" address="127.0.0.1:9890" subsys=gops msg="failed to start: Get \"https://:443/api/v1/namespaces/kube-system\": dial tcp :443: i/o timeout" subsys=daemon ``` Si utiliza la función del plano de control BGP de Cilium para equilibrar la carga de las aplicaciones, es posible que la sesión de BGP de sus pods y servicios se interrumpa durante las desconexiones de la red, ya que la funcionalidad de los altavoces BGP está integrada en el agente de Cilium, y el agente de Cilium se reiniciará continuamente cuando se desconecte del plano de control de Kubernetes. Para obtener más información, consulte la Guía de funcionamiento del plano de control BGP de Cilium en la documentación de Cilium. Además, si se produce un fallo simultáneo durante una desconexión de la red, como un ciclo de alimentación o un reinicio de la máquina, las rutas de Cilium no se conservarán mediante estas acciones, aunque se volverán a crear cuando el nodo se vuelva a conectar al plano de control de Kubernetes y Cilium se vuelva a iniciar. ## Calico *Próximamente* ## Metal LB [MetalLB tiene dos modos de equilibrio de carga: modo [L2](https://metallb.universe.tf/concepts/layer2/) y modo BGP.](https://metallb.universe.tf/concepts/bgp/) Consulte la documentación de MetalLB para obtener detalles sobre cómo funcionan estos modos de equilibrio de carga y sus limitaciones. En la validación de esta guía se utilizó MetallB en el modo L2, en el que una máquina del clúster asume la propiedad del servicio de Kubernetes y utiliza ARP para hacer que las direcciones IP del balanceador de carga estén IPv4 accesibles en la red local. Cuando se ejecuta MetallB, hay un controlador que se encarga de la asignación de IP y altavoces en cada nodo que se encargan de anunciar los servicios con direcciones IP asignadas. El controlador MetalLB funciona como un Deployment y los altavoces MetalLB funcionan como un. DaemonSet Durante las desconexiones de la red, el controlador MetalLB y los altavoces no vigilan el servidor API de Kubernetes en busca de recursos del clúster, pero siguen funcionando. Y lo que es más importante, los servicios que utilizan MetallB para la conectividad externa permanecen disponibles y accesibles durante las desconexiones de la red. ## kube-proxy En los clústeres de EKS, kube-proxy se ejecuta DaemonSet en cada nodo y es responsable de gestionar las reglas de red para permitir la comunicación entre los servicios y los pods mediante la traducción de las direcciones IP de los servicios a las direcciones IP de los pods subyacentes. Las reglas de las tablas de IP (iptables) configuradas por kube-proxy se mantienen durante las desconexiones de la red, el enrutamiento dentro del clúster sigue funcionando y los pods de kube-proxy siguen funcionando. Puedes observar las reglas de kube-proxy con los siguientes comandos de iptables. El primer comando muestra que los paquetes que atraviesan la `PREROUTING` cadena se dirigen a la cadena. `KUBE-SERVICES` ``` iptables -t nat -L PREROUTING ``` ``` Chain PREROUTING (policy ACCEPT) target prot opt source destination KUBE-SERVICES all -- anywhere anywhere /* kubernetes service portals */ ``` Al inspeccionar la `KUBE-SERVICES` cadena, podemos ver las reglas de los distintos servicios del clúster. ``` Chain KUBE-SERVICES (2 references) target prot opt source destination KUBE-SVL-NZTS37XDTDNXGCKJ tcp -- anywhere 172.16.189.136 /* kube-system/hubble-peer:peer-service cluster IP / KUBE-SVC-2BINP2AXJOTI3HJ5 tcp -- anywhere 172.16.62.72 / default/metallb-webhook-service cluster IP / KUBE-SVC-LRNEBRA3Z5YGJ4QC tcp -- anywhere 172.16.145.111 / default/redis-leader cluster IP / KUBE-SVC-I7SKRZYQ7PWYV5X7 tcp -- anywhere 172.16.142.147 / kube-system/eks-extension-metrics-api:metrics-api cluster IP / KUBE-SVC-JD5MR3NA4I4DYORP tcp -- anywhere 172.16.0.10 / kube-system/kube-dns:metrics cluster IP / KUBE-SVC-TCOU7JCQXEZGVUNU udp -- anywhere 172.16.0.10 / kube-system/kube-dns:dns cluster IP / KUBE-SVC-ERIFXISQEP7F7OF4 tcp -- anywhere 172.16.0.10 / kube-system/kube-dns:dns-tcp cluster IP / KUBE-SVC-ENODL3HWJ5BZY56Q tcp -- anywhere 172.16.7.26 / default/frontend cluster IP / KUBE-EXT-ENODL3HWJ5BZY56Q tcp -- anywhere / default/frontend loadbalancer IP / KUBE-SVC-NPX46M4PTMTKRN6Y tcp -- anywhere 172.16.0.1 / default/kubernetes:https cluster IP / KUBE-SVC-YU5RV2YQWHLZ5XPR tcp -- anywhere 172.16.228.76 / default/redis-follower cluster IP / KUBE-NODEPORTS all -- anywhere anywhere / kubernetes service nodeports; NOTE: this must be the last rule in this chain */ ``` Al inspeccionar la cadena del servicio de interfaz de la aplicación, podemos ver las direcciones IP de los módulos que respaldan el servicio. ``` iptables -t nat -L KUBE-SVC-ENODL3HWJ5BZY56Q ``` ``` Chain KUBE-SVC-ENODL3HWJ5BZY56Q (2 references) target prot opt source destination KUBE-SEP-EKXE7ASH7Y74BGBO all -- anywhere anywhere /* default/frontend -> 10.86.2.103:80 / statistic mode random probability 0.33333333349 KUBE-SEP-GCY3OUXWSVMSEAR6 all -- anywhere anywhere / default/frontend -> 10.86.2.179:80 / statistic mode random probability 0.50000000000 KUBE-SEP-6GJJR3EF5AUP2WBU all -- anywhere anywhere / default/frontend -> 10.86.3.47:80 */ ``` Se esperan los siguientes mensajes de registro de kube-proxy durante las desconexiones de la red, ya que intenta vigilar el servidor API de Kubernetes en busca de actualizaciones en los recursos de los nodos y terminales. ``` "Unhandled Error" err="k8s.io/client-go/informers/factory.go:160: Failed to watch *v1.Node: failed to list *v1.Node: Get \"https:///api/v1/nodes?fieldSelector=metadata.name%3D&resourceVersion=2241908\": dial tcp :443: i/o timeout" logger="UnhandledError" "Unhandled Error" err="k8s.io/client-go/informers/factory.go:160: Failed to watch *v1.EndpointSlice: failed to list *v1.EndpointSlice: Get \"https:///apis/discovery.k8s.io/v1/endpointslices?labelSelector=%21service.kubernetes.io%2Fheadless%2C%21service.kubernetes.io%2Fservice-proxy-name&resourceVersion=2242090\": dial tcp :443: i/o timeout" logger="UnhandledError" ``` ## CoreDNS De forma predeterminada, los pods de los clústeres de EKS utilizan la dirección IP del clúster de CoreDNS como servidor de nombres para las consultas de DNS dentro del clúster. En los clústeres de EKS, CoredNS se ejecuta como una implementación en los nodos. Con los nodos híbridos, los pods pueden seguir comunicándose con el CoreDNS durante las desconexiones de la red cuando hay réplicas de CoreDNS ejecutándose localmente en los nodos híbridos. Si tiene un clúster de EKS con nodos en la nube y nodos híbridos en su entorno local, se recomienda tener al menos una réplica de CoredNS en cada entorno. CoredNS sigue atendiendo consultas de DNS para los registros que se crearon antes de la desconexión de la red y continúa ejecutándose durante la reconexión de la red para garantizar una estabilidad estática. Se esperan los siguientes mensajes de registro de CoredNS durante las desconexiones de la red, ya que intenta enumerar los objetos del servidor API de Kubernetes. ``` Failed to watch *v1.Namespace: failed to list *v1.Namespace: Get "https://:443/api/v1/namespaces?resourceVersion=2263964": dial tcp :443: i/o timeout Failed to watch *v1.Service: failed to list *v1.Service: Get "https://:443/api/v1/services?resourceVersion=2263966": dial tcp :443: i/o timeout Failed to watch *v1.EndpointSlice: failed to list *v1.EndpointSlice: Get "https://:443/apis/discovery.k8s.io/v1/endpointslices?resourceVersion=2263896": dial tcp : i/o timeout ``` # Aloje las credenciales mediante desconexiones de red EKS Hybrid Nodes se integra con las activaciones híbridas de AWS Systems Manager (SSM) y con AWS IAM Roles Anywhere para obtener credenciales de IAM temporales que se utilizan para autenticar el nodo con el plano de control de EKS. Tanto SSM como IAM Roles Anywhere actualizan automáticamente las credenciales temporales que administran en los hosts locales. Se recomienda utilizar un único proveedor de credenciales en todos los nodos híbridos del clúster: SSM Hybrid Activations o IAM Roles Anywhere, pero no ambos. ## Activaciones híbridas de SSM Las credenciales temporales proporcionadas por SSM son válidas durante una hora. No puede modificar la duración de la validez de las credenciales si utiliza SSM como proveedor de credenciales. SSM rota automáticamente las credenciales temporales antes de que caduquen y la rotación no afecta al estado de los nodos o las aplicaciones. Sin embargo, cuando hay desconexiones de red entre el agente de SSM y el punto de conexión regional de SSM, SSM no puede actualizar las credenciales y estas podrían caducar. SSM utiliza un retardo exponencial para los reintentos de actualización de credenciales si no puede conectarse a los puntos finales regionales de SSM. En la versión del agente SSM `3.3.808.0` y versiones posteriores (publicadas en agosto de 2024), el retraso exponencial está limitado a 30 minutos. Según la duración de la desconexión de la red, SSM puede tardar hasta 30 minutos en actualizar las credenciales y los nodos híbridos no se volverán a conectar al plano de control de EKS hasta que se actualicen las credenciales. En este escenario, puede reiniciar el agente SSM para forzar la actualización de las credenciales. Como efecto secundario del comportamiento actual de actualización de credenciales de SSM, es posible que los nodos se vuelvan a conectar en distintos momentos, según el momento en que el agente de SSM de cada nodo consiga actualizar sus credenciales. Por este motivo, es posible que se produzca una conmutación por error entre los nodos que aún no se han vuelto a conectar y los nodos que ya se han vuelto a conectar. Obtenga la versión del agente SSM. También puedes consultar la sección Fleet Manager de la consola SSM: ``` # AL2023, RHEL yum info amazon-ssm-agent # Ubuntu snap list amazon-ssm-agent ``` Reinicie el agente SSM: ``` # AL2023, RHEL systemctl restart amazon-ssm-agent # Ubuntu systemctl restart snap.amazon-ssm-agent.amazon-ssm-agent ``` Vea los registros del agente SSM: ``` tail -f /var/log/amazon/ssm/amazon-ssm-agent.log ``` Mensajes de registro esperados durante las desconexiones de la red: ``` INFO [CredentialRefresher] Credentials ready INFO [CredentialRefresher] Next credential rotation will be in 29.995040663666668 minutes ERROR [CredentialRefresher] Retrieve credentials produced error: RequestError: send request failed INFO [CredentialRefresher] Sleeping for 35s before retrying retrieve credentials ERROR [CredentialRefresher] Retrieve credentials produced error: RequestError: send request failed INFO [CredentialRefresher] Sleeping for 56s before retrying retrieve credentials ERROR [CredentialRefresher] Retrieve credentials produced error: RequestError: send request failed INFO [CredentialRefresher] Sleeping for 1m24s before retrying retrieve credentials ``` ## IAM Roles Anywhere De forma predeterminada, las credenciales temporales proporcionadas por IAM Roles Anywhere son válidas durante una hora. Puede configurar la duración de la validez de las credenciales con IAM Roles Anywhere a través del [https://docs.aws.amazon.com/rolesanywhere/latest/userguide/authentication-create-session.html#credentials-object](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/authentication-create-session.html#credentials-object)campo de su perfil de IAM Roles Anywhere. La validez máxima de las credenciales es de 12 horas. La [https://docs.aws.amazon.com/managedservices/latest/ctref/management-advanced-identity-and-access-management-iam-update-maxsessionduration.html](https://docs.aws.amazon.com/managedservices/latest/ctref/management-advanced-identity-and-access-management-iam-update-maxsessionduration.html)configuración de su función de IAM de Hybrid Nodes debe ser mayor que la `durationSeconds` configuración de su perfil de IAM Roles Anywhere. Al utilizar IAM Roles Anywhere como proveedor de credenciales para los nodos híbridos, la reconexión al plano de control del EKS tras la desconexión de la red suele producirse segundos después de la restauración de la red, ya que el kubelet llama para obtener las credenciales a pedido. `aws_signing_helper credential-process` Aunque no está directamente relacionado con los nodos híbridos o las desconexiones de la red, puede configurar notificaciones y alertas para el vencimiento de los certificados cuando utilice IAM Roles Anywhere. Para obtener más información, consulte [Personalizar la configuración de notificaciones en IAM](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/customize-notification-settings.html) Roles Anywhere.