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.
# Mejores prácticas para lograr la estabilidad a través de 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 sobre la Site-to-Site VPN de [ AWS ](https://docs.aws.amazon.com/vpn/latest/s2svpn/vpn-redundant-connection.html) para obtener más información sobre la arquitectura de redes híbridas de alta disponibilidad con esas soluciones.
## Aplicaciones de alta disponibilidad
Al diseñar aplicaciones, tenga en cuenta sus dominios de error y los efectos de los diferentes 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 pueden moverse a través de una capacidad de infraestructura y host arbitraria, y se pueden 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/](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 para 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 tienes una implementación con nodos que se ejecutan en varios centros de datos o ubicaciones físicas, asigna 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, el administrador del controlador de la nube de AWS aplica automáticamente esta etiqueta de zona. Sin embargo, no se usa un administrador de controladores en la nube con los 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 tu configuración de nodos para nodos híbridos. La configuración se aprueba cuando conectas los nodos híbridos a tu clúster con la CLI de los nodos híbridos (`nodeadm`). 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, consulta la referencia nodeadm de [ Hybrid Nodes. ](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 usa 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 su 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 los `NodeNotReady` eventos notificados por el controlador del ciclo de vida del nodo que se ejecuta en el plano de control de EKS, lo que indica que un nodo híbrido podría estar desconectándose de la red. Para crear esta alarma, habilite el registro del plano de control de EKS en el Controller Manager y cree un filtro métrico para el mensaje «Registrando el mensaje de evento de cambio de estado CloudWatch para el nodo» con el estado = «». 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 para registros en la CloudWatch documentación](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Alarm-On-Logs.html).
Puedes 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 tu TGW o VGW. Puedes 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 tabla siguiente.
| Puerta de enlace | Métrica | Description (Descripción) |
| --- | --- | --- |
| Transit Gateway | BytesIn | Los bytes recibidos por TGW desde el 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 de 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 (de los 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 información más detallada sobre sus conexiones híbridas, reducir el tiempo medio de recuperación y determinar si los problemas de red se originan en AWS o en su entorno. CloudWatch Network Monitor se puede utilizar para visualizar la pérdida de paquetes y la latencia en las conexiones de red híbridas, 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 supervisar el estado de sus clústeres y aplicaciones. Para conocer el estado de los clústeres, puede usar el panel de observabilidad de la consola de EKS para detectar, solucionar y corregir los 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, aplicaciones e CloudWatch infraestructuras. Para obtener más información sobre las opciones de observabilidad de EKS, consulte [ Supervisar el rendimiento de su 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 red entre los nodos híbridos y el plano de control de EKS, puede configurar backends secundarios de monitoreo y registro para mantener la capacidad de observación 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 puede usar herramientas locales, como la `crictl` CLI, para interactuar localmente con los pods y los contenedores en lugar de con otros API-compatible clientes de Kubernetes que normalmente consultan el punto `kubectl` final del servidor de la API de Kubernetes. Para obtener más información al respecto`crictl`, consulta la documentación de cri-tools. [`crictl`](https://github.com/kubernetes-sigs/cri-tools/blob/master/docs/crictl.md) GitHub A continuación se enumeran algunos `crictl` comandos útiles.
Enumera los pods que se están ejecutando en el host:
```
crictl pods
```
Enumera 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 están ejecutando en el host:
```
crictl statsp
```
## Tráfico de red de aplicaciones
Al usar 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 de equilibrio de carga y entrada de las aplicaciones se comportan de forma diferente durante las desconexiones de la red. Por ejemplo, si utilizas 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 tus pods y servicios no funcione durante las desconexiones de la red. Esto ocurre porque la funcionalidad del altavoz BGP está integrada con el agente de Cilium, que se reinicia continuamente cuando se desconecta del plano de control de Kubernetes. El motivo del reinicio se debe a que Cilium no ha podido comprobar su estado, ya que su estado va unido al acceso al plano de control de Kubernetes (consulte [ CFP: \#31702, con una mejora opcional en la versión 1.17 de Cilium). ](https://github.com/cilium/cilium/issues/31702) Del mismo modo, si utiliza balanceadores de carga de aplicaciones (ALB) o balanceadores de carga de red (NLB) para el tráfico de Region-originated aplicaciones de AWS, ese tráfico podría interrumpirse temporalmente si su entorno local pierde la conectividad con la región de AWS. Antes de implementarlas en producción, se recomienda comprobar que las tecnologías que utiliza para equilibrar la carga y la entrada permanecen estables durante las desconexiones de la red. El ejemplo del [ GitHub repositorio ](https://github.com/aws-samples/eks-hybrid-examples) aws- samples/eks -hybrid-examples usa 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 EKS.
## Revise las dependencias de los servicios remotos de AWS
Cuando utilice nodos híbridos, tenga en cuenta las dependencias que adquiere de los servicios regionales de AWS que son externos a su entorno local o periférico. Algunos ejemplos son acceder a Amazon S3 o Amazon RDS para obtener datos de aplicaciones, utilizar Amazon Managed Service para Prometheus o CloudWatch para obtener métricas y registros, utilizar los balanceadores de carga de aplicaciones y redes para el Region-originated tráfico y extraer 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 perder la conexión a esos servicios no comprometa la estabilidad estática de sus aplicaciones.
## Ajuste del comportamiento de conmutación por error del pod de Kubernetes
Existen opciones para ajustar el comportamiento de conmutación por error de los pods durante las desconexiones de la red para aplicaciones que no se pueden transportar entre hosts o para entornos con recursos limitados que no tienen capacidad disponible 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 capacidad suficiente para que una o más instancias de la aplicación puedan conmutar por error a un host diferente si se produce 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 los DaemonSet pods conectados a sus nodos cuando se desconectan de la red.
+ Opción 2: Ajustarse `tolerationSeconds` para detectar la contaminación inalcanzable: puedes ajustar el tiempo que tus pods permanecen conectados a los nodos durante las desconexiones de la red. Para ello, configura los pods de las aplicaciones para que toleren la contaminación inalcanzable durante el tiempo que especifiques (en las `NoExecute` especificaciones de la aplicación). `tolerationSeconds` Con esta opción, cuando hay desconexiones de red, los pods de la aplicación permanecen enlazados a los nodos hasta que caduquen. `tolerationSeconds` Tenga en cuenta esta posibilidad, ya que `tolerationSeconds` si aumenta la contaminación inalcanzable, los pods que se ejecutan en hosts inaccesibles pueden tardar más en trasladarse a otros hosts accesibles y en buen estado. `NoExecute`
+ Opción 3: mando personalizado: puedes crear y ejecutar un mando personalizado (u otro software) que supervise Kubernetes en busca de la mancha inalcanzable que produce ese 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 información inalcanzable e impedir que se expulsen 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 `tolerationSeconds` para los usuarios inalcanzables. En el ejemplo, `tolerationSeconds` se establece en `1800` (30 minutos), lo que significa que los pods que se ejecuten en nodos inaccesibles 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
```