**Ayude a mejorar esta página** Para contribuir a esta guía del usuario, elija el enlace **Edit this page on GitHub** que se encuentra en el panel derecho de cada página. # Preparación de los clústeres locales de Amazon EKS en AWS Outposts configurados con el almacén de instancias de EC2 para las desconexiones de la red Si el enlace de servicio de AWS Outposts que conecta la red local a la nube de AWS perdió la conectividad, puede continuar usando el clúster local de Amazon EKS en un Outpost. En este tema, se explica cómo preparar el clúster local para las desconexiones de red y las consideraciones relacionadas. + Los clústeres locales permiten la estabilidad y las operaciones continuas durante las desconexiones de red temporales e imprevistas. AWS Outposts sigue siendo una oferta completamente conectada que funciona como una extensión de la nube de AWS en su centro de datos. En caso de que la red se desconecte entre el Outpost y la nube de AWS, le recomendamos que intente restablecer la conexión. Para obtener instrucciones, consulte [Lista de verificación para la solución de problemas de red de los bastidores de AWS](https://docs.aws.amazon.com/outposts/latest/userguide/network-troubleshoot.html) en la * Guía del usuario de AWS Outposts*. + Los Outposts emiten una métrica `ConnectedStatus` que puede usar para supervisar el estado de conectividad de su Outpost. Para obtener más información, consulte [Métricas de Outposts](https://docs.aws.amazon.com/outposts/latest/userguide/outposts-cloudwatch-metrics.html#outposts-metrics) en la *Guía del usuario de AWS Outposts*. ## Autenticación durante las desconexiones de red Los clústeres locales admiten varios mecanismos de autenticación. Su disponibilidad durante las desconexiones de red varía: | Mecanismo de autenticación | ¿Está disponible durante la desconexión? | | --- | --- | | AWS IAM (entradas de acceso, ConfigMap de `aws-auth`) | No. IAM requiere conectividad con la región de AWS. | | OIDC (proveedor proporcionado por el cliente) | Depende de la ubicación del proveedor. Si se puede acceder al proveedor de OIDC desde la red local de Outpost, la autenticación continúa funcionando. | | Certificados de cliente x.509 | Sí. Los certificados se validan localmente en el servidor de la API de Kubernetes. | | IRSA (roles de IAM para cuentas de servicio) | No. Consulte [IRSA y Pod Identity durante las desconexiones](#eks-outposts-instance-store-network-disconnects-irsa). | | Pod Identity de EKS | No. Consulte [IRSA y Pod Identity durante las desconexiones](#eks-outposts-instance-store-network-disconnects-irsa). | ### Certificados de cliente x.509 Para mantener el acceso a `kubectl` durante las desconexiones de red, cree un certificado X.509 de cliente antes de que se produzca la desconexión. Para crear un certificado de administrador: 1. Genere una clave privada y una solicitud de firma de certificado (CSR): ``` openssl req -new -newkey rsa:4096 -nodes \ -keyout admin.key -out admin.csr -subj "/CN=admin" ``` 1. Cree un recurso `CertificateSigningRequest` de Kubernetes y apruébelo: ``` cat admin.csr | base64 | tr -d '\n' > admin.csr.b64 ``` ``` apiVersion: certificates.k8s.io/v1 kind: CertificateSigningRequest metadata: name: admin-csr spec: request: signerName: kubernetes.io/kube-apiserver-client usages: - client auth ``` ``` kubectl apply -f admin-csr.yaml kubectl certificate approve admin-csr ``` 1. Recupere el certificado firmado: ``` kubectl get csr admin-csr -o jsonpath='{.status.certificate}' | base64 --decode > admin.crt ``` 1. Cree `ClusterRoleBinding` para conceder acceso de administrador: ``` kubectl create clusterrolebinding admin --clusterrole=cluster-admin \ --user=admin --group=system:masters ``` 1. Cree `kubeconfig` que utilice el certificado: ``` kubectl config --kubeconfig admin.kubeconfig set-cluster my-cluster \ --certificate-authority=ca.crt --server $APISERVER_ENDPOINT --embed-certs kubectl config --kubeconfig admin.kubeconfig set-credentials admin \ --client-certificate=admin.crt --client-key=admin.key --embed-certs kubectl config --kubeconfig admin.kubeconfig set-context admin@my-cluster \ --cluster my-cluster --user admin kubectl config --kubeconfig admin.kubeconfig use-context admin@my-cluster ``` ### Resolución del DNS del punto de conexión del clúster durante las desconexiones El punto de conexión del servidor de la API de Kubernetes para un clúster local se aloja en Amazon Route 53 y se resuelve en las direcciones IP privadas de las interfaces de red elásticas (ENI) entre cuentas que Amazon EKS crea en las subredes. Estas ENI tienen direcciones IP privadas estáticas que no cambian durante el funcionamiento normal del clúster. Durante una desconexión de red, el Outpost no puede llegar a Route 53, por lo que el nombre de host del punto de conexión del clúster no se resuelve a menos que se haya preparado una ruta de resolución local. Hay tres categorías de clientes que necesitan acceder al servidor de la API: + **Administradores de clústeres** que ejecutan `kubectl`. + **Nodos de trabajo** (`kubelet`) que envían los latidos de los nodos y extraen especificaciones. + **`kube-proxy`** en cada nodo, lo que configura las IP de servicio del clúster. #### Opción 1: solución de DNS local (recomendada) AWS recomienda implementar una solución de DNS local que almacene en caché los registros de los puntos de conexión del clúster y los entregue mientras el Outpost esté desconectado. Puede ejecutar su propio servidor de DNS en su entorno en las instalaciones que almacene en caché los registros de los puntos de conexión del clúster. Si utiliza una solución de DNS local, le recomendamos que dirija las AMI de `kubeconfig` y del nodo de trabajo al nombre de host del punto de conexión del clúster (no a las direcciones IP de la ENI) para que la resolución sea coherente con la solución de DNS local. #### Opción 2: acceso estático basado en IP Si no desea ejecutar una solución de DNS local, puede usar el acceso estático basado en IP. + **Administradores:** configure `kubeconfig` para que apunte directamente a una dirección IP privada de la ENI multicuenta. Para encontrar las ENI, busque las interfaces de red con la descripción `Amazon EKS {{cluster-name}} ` en la cuenta de AWS. La dirección IP de cada ENI es estable durante toda la vida útil del clúster en condiciones normales de funcionamiento. + **Nodos de trabajo (AMI optimizadas para Amazon EKS):** al lanzar nodos de trabajo desde una AMI optimizada para Amazon EKS, el script de arranque agrega el punto de conexión del clúster a `/etc/hosts` con las direcciones IP de la ENI. No se necesita ninguna configuración adicional. + **Nodos de trabajo (AMI personalizadas):** agregue el nombre de host del punto de conexión del clúster y las direcciones IP de la ENI a `/etc/hosts` en el arranque personalizado. De lo contrario, `kubelet` y `kube-proxy` no podrán acceder al servidor de la API durante una desconexión. **importante** Si se elimina una ENI multicuenta o cambia su dirección IP (por ejemplo, si la elimina o modifica de forma que impida que Amazon EKS la vuelva a adjuntar), todos los nodos y administradores que utilicen un acceso estático basado en IP deben actualizarse manualmente. Con una solución de DNS local, no se requiere ninguna intervención manual. ### Resolución de DNS del pod durante las desconexiones Para evitar que se produzcan errores de DNS durante una operación desconectada, configure la plantilla de lanzamiento del nodo de trabajo para anular la configuración `kubelet’s `resolvConf`. En los datos de usuario, cree un archivo `resolv.conf` personalizado (por ejemplo, `/etc/kubernetes/resolv.conf`) que contenga solo `nameserver 10.0.0.2` (sin el dominio de búsqueda de VPC) y, a continuación, establezca `spec.kubelet.config.resolvConf: /etc/kubernetes/resolv.conf` en `NodeConfig`. Esto elimina el dominio de búsqueda ` {{region-code}}.compute.internal` de la configuración de DNS del pod, lo que impide que las consultas se reenvíen al solucionador de DNS de la VPC inalcanzable mientras está desconectada. En el ejemplo siguiente se muestran los datos de usuario del nodo de trabajo: ``` MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="BOUNDARY" --BOUNDARY Content-Type: text/x-shellscript; charset="us-ascii" #!/bin/bash mkdir -p /etc/kubernetes echo "nameserver [.replaceable]``10.0.0.2``" > /etc/kubernetes/resolv.conf --BOUNDARY Content-Type: application/node.eks.aws --- apiVersion: node.eks.aws/v1alpha1 kind: NodeConfig spec: cluster: name: my-cluster ... kubelet: config: resolvConf: /etc/kubernetes/resolv.conf --BOUNDARY-- ``` ### IRSA y Pod Identity durante las desconexiones **importante** IRSA y Pod Identity de EKS dependen de AWS STS, que se ejecuta en la región de AWS. Durante una desconexión de red, las cargas de trabajo que utilizan IRSA o Pod Identity no pueden obtener nuevas credenciales. Las credenciales existentes vencen después de un periodo de tiempo. No recomendamos depender funcional ni operativamente de los servicios de AWS basados en la región para las cargas de trabajo que deben permanecer disponibles durante las desconexiones de red. ## Comportamiento de `etcd` durante las desconexiones Durante las desconexiones de red, no se pueden hacer copias de seguridad de las instantáneas de `etcd`. Si más de una instancia `etcd` deja de estar disponible durante una desconexión, `etcd` pierde el cuórum y las operaciones de la API de Kubernetes no estarán disponibles hasta que el Outpost se vuelva a conectar y se restablezca el quórum `etcd`. Las cargas de trabajo que ya están en ejecución continúan funcionando. ## Registro del plano de control durante las desconexiones Durante las desconexiones de red, los registros del plano de control de Amazon EKS se almacenan en caché de forma local en instancias del plano de control. Cuando se restablece la conectividad, los registros se envían a Registros de Amazon CloudWatch en la región de AWS principal. No es necesario instalar ni mantener ningún agente de registro en el plano de control. ## Observabilidad local Puede supervisar el clúster localmente durante las desconexiones mediante [Prometheus](https://prometheus.io/), [Grafana](https://grafana.com/) u otras soluciones de terceros para raspar el punto de conexión de métricas del servidor de la API de Kubernetes. ## Repositorio de imágenes local Para escalar las implementaciones con réplicas adicionales o para recuperarse de los errores de los pods durante las desconexiones, debe tener un repositorio de imágenes en un contenedor local (como un registro de Docker) o las imágenes deben almacenarse en caché en el nodo antes de la desconexión. Amazon ECR no está disponible durante las desconexiones de red. ## Ajuste del comportamiento de conmutación por error del pod de Kubernetes Durante una desconexión de la red, el plano de control de Kubernetes no puede comunicarse con la región de AWS. Si no se puede acceder a un nodo, el comportamiento predeterminado de Kubernetes es expulsar los pods después de un periodo de tiempo de espera. Puede ajustar este comportamiento con las tolerancias y `tolerationSeconds` en las especificaciones del pod para controlar la rapidez con la que se reprograman los pods durante las particiones. Para obtener instrucciones detalladas y ejemplos, consulte https://docs.aws.amazon.com/eks/latest/best-practices/hybrid-nodes-network-disconnection-best-practices.html\#*tune\_kubernetes\_pod\_failover\_behavior[Ajuste del comportamiento de conmutación por error de los pods de Kubernetes] en la \_Guía de prácticas recomendadas de Amazon EKS*. ## Simulación de una desconexión de red Antes de iniciar la producción con el clúster local, simule una desconexión para verificar que pueda acceder al clúster cuando esté en estado desconectado. 1. Aplique las reglas de firewall en los dispositivos de red que conectan su Outpost a la región de AWS. Esto desconecta el enlace de servicio del Outpost. 1. Pruebe la conexión al clúster local con el certificado x.509 que creó: ``` kubectl --kubeconfig admin.kubeconfig get nodes ``` **nota** Si ya tiene servicios en producción en su Outpost, no simule ninguna desconexión. La desconexión del enlace de servicio afecta a todos los servicios que se ejecutan en el Outpost.