**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 para las desconexiones de la red Puede seguir usando su clúster local de Amazon EKS en un Outpost si su red local ha perdido la conectividad con la nube de AWS. 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 su 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*. Para obtener más información acerca de cómo solucionar problemas de los clústeres locales, consulte [Solución de problemas de los clústeres locales de Amazon EKS en AWS Outposts](eks-outposts-troubleshooting.md). + 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*. + Los clústeres locales utilizan IAM como mecanismo de autenticación predeterminado mediante el [Autenticador de AWS Identity and Access Management para Kubernetes](https://github.com/kubernetes-sigs/aws-iam-authenticator). IAM no está disponible durante las desconexiones de red. Entonces, los clústeres locales admiten un mecanismo de autenticación alternativo mediante certificados `x.509` que puede usar para conectarse a su clúster durante las desconexiones de red. Para obtener información acerca de cómo obtener y usar un certificado `x.509` para su clúster, consulte [Autenticación en el clúster local durante una desconexión de red](#outposts-network-disconnects-authentication). + Si no puede acceder a Route 53 durante las desconexiones de red, considere la posibilidad de utilizar servidores de DNS locales en su entorno en las instalaciones. Las instancias del plano de control de Kubernetes usan direcciones IP estáticas. Puede configurar los hosts que usa para conectarse a su clúster con el nombre de host y las direcciones IP del punto de conexión como alternativa al uso de servidores de DNS locales. Para obtener más información, consulte [DNS](https://docs.aws.amazon.com/outposts/latest/userguide/how-outposts-works.html#dns) en la *Guía del usuario de AWS Outposts*. + Si prevé aumentos en el tráfico de aplicaciones durante las desconexiones de red, puede aprovisionar capacidad de computación sobrante en su clúster cuando se conecte a la nube. Las instancias de Amazon EC2 están incluidas en el precio de AWS Outposts. Por lo tanto, la ejecución de instancias de repuesto no afecta al costo de uso de AWS. + Durante las desconexiones de red, para permitir las operaciones de creación, actualización y escalado de las cargas de trabajo, las imágenes del contenedor de la aplicación deben ser accesibles a través de la red local y el clúster debe tener capacidad suficiente. Los clústeres locales no alojan un registro de contenedores en su nombre. Las imágenes del contenedor se almacenan en caché en los nodos si los pods se ejecutaron anteriormente en esos nodos. Si normalmente extrae las imágenes del contenedor de su aplicación de Amazon ECR en la nube, considere la posibilidad de ejecutar una caché o un registro local. Una caché o un registro local es útil si necesita crear, actualizar y escalar operaciones para los recursos de las cargas de trabajo durante desconexiones de red. + Los clústeres locales usan Amazon EBS como clase de almacenamiento predeterminada para los volúmenes persistentes y el controlador de CSI de Amazon EBS para administrar el ciclo de vida de los volúmenes persistentes de Amazon EBS. Durante las desconexiones de red, los pods basados en Amazon EBS no se pueden crear, actualizar ni escalar. Esto se debe a que estas operaciones requieren llamadas a la API de Amazon EBS en la nube. Si está implementando cargas de trabajo con estado en clústeres locales y necesita crear, actualizar o escalar operaciones durante las desconexiones de red, considere la posibilidad de utilizar un mecanismo de almacenamiento alternativo. + Las instantáneas de Amazon EBS no se pueden crear ni eliminar si AWS Outposts no puede acceder a las API pertinentes en la región de AWS (como las API de Amazon EBS o Amazon S3). + Al integrar ALB (Ingress) con AWS Certificate Manager (ACM), los certificados se cargan y almacenan en la memoria de la instancia ALB Compute de AWS Outposts. La terminación actual de TLS seguirá funcionando en caso de que se desconecte de la región de AWS. Las operaciones de mutación en este contexto fallarán (como las nuevas definiciones de entrada, las nuevas operaciones de API de certificados basadas en ACM, la escala de computación de ALB o la rotación de certificados). Para obtener más información, consulte [Solución de problemas de renovación administrada de certificados](https://docs.aws.amazon.com/acm/latest/userguide/troubleshooting-renewal.html) en la *Guía del usuario de AWS*. + Los registros del plano de control de Amazon EKS se almacenan en caché de forma local en instancias del plano de control de Kubernetes durante las desconexiones de red. Si se conecta nuevamente, los registros se enviarán a Registros de CloudWatch en la región de AWS principal. Puede utilizar [Prometheus](https://prometheus.io/), [Grafana](https://grafana.com/) o las soluciones de socios de Amazon EKS para supervisar el clúster de forma local mediante el punto de conexión de métricas del servidor de la API de Kubernetes o utilizar Fluent Bit para registros. + Si está usando el controlador del equilibrador de carga de AWS en Outposts para el tráfico de aplicaciones, los pods existentes encabezados por el controlador del equilibrador de carga de AWS seguirán recibiendo tráfico durante las desconexiones de red. Los nuevos pods creados durante las desconexiones de red no reciben tráfico hasta que el Outpost se vuelve a conectar a la nube de AWS. Considere la posibilidad de configurar el recuento de réplicas de sus aplicaciones mientras esté conectado a la nube de AWS para satisfacer sus necesidades de escalado durante las desconexiones de red. + El complemento CNI de Amazon VPC para Kubernetes establece el valor predeterminado en el [modo de IP secundario](https://aws.github.io/aws-eks-best-practices/networking/vpc-cni/#overview). Está configurado con `WARM_ENI_TARGET`=`1`, que permite al complemento mantener “una interfaz de red elástica completa” de las direcciones IP disponibles. Considere cambiar los valores `WARM_ENI_TARGET`, `WARM_IP_TARGET` y `MINIMUM_IP_TARGET` de acuerdo con sus necesidades de escalado durante un estado desconectado. Para obtener más información, consulte el archivo [readme](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/README.md) para el complemento en GitHub. Para obtener una lista del número máximo de pods admitidos por cada tipo de instancia, consulte el archivo [eni-max-pods.txt](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/misc/eni-max-pods.txt) en GitHub. ## Autenticación en el clúster local durante una desconexión de red AWS Identity and Access Management (IAM) no está disponible durante las desconexiones de red. No es posible autenticar en su clúster local con las credenciales de IAM mientras esté desconectado. Sin embargo, puede conectarse a su clúster a través de su red local mediante certificados `x509` cuando esté desconectado. Debe descargar y almacenar un certificado cliente `X509` para usar durante las desconexiones. En este tema, aprenderá a crear y utilizar el certificado para autenticarse en su clúster cuando está en estado desconectado. 1. Crear una solicitud de firma de certificado. 1. Genere una solicitud de firma de certificado. ``` openssl req -new -newkey rsa:4096 -nodes -days 365 \ -keyout admin.key -out admin.csr -subj "/CN=admin" ``` 1. Cree una solicitud de firma de certificado en Kubernetes. ``` BASE64_CSR=$(cat admin.csr | base64 -w 0) cat << EOF > admin-csr.yaml apiVersion: certificates.k8s.io/v1 kind: CertificateSigningRequest metadata: name: admin-csr spec: signerName: kubernetes.io/kube-apiserver-client request: ${BASE64_CSR} usages: - client auth EOF ``` 1. Cree una solicitud de firma de certificado con `kubectl`. ``` kubectl create -f admin-csr.yaml ``` 1. Compruebe el estado de la solicitud de firma de certificado. ``` kubectl get csr admin-csr ``` Un ejemplo de salida sería el siguiente. ``` NAME AGE REQUESTOR CONDITION admin-csr 11m kubernetes-admin Pending ``` Kubernetes ha creado la solicitud de firma de certificado. 1. Apruebe la solicitud de firma de certificado. ``` kubectl certificate approve admin-csr ``` 1. Vuelva a comprobar el estado de la solicitud de firma de certificado para aprobarla. ``` kubectl get csr admin-csr ``` Un ejemplo de salida sería el siguiente. ``` NAME AGE REQUESTOR CONDITION admin-csr 11m kubernetes-admin Approved ``` 1. Recupere y verifique el certificado. 1. Recupere el certificado. ``` kubectl get csr admin-csr -o jsonpath='{.status.certificate}' | base64 --decode > admin.crt ``` 1. Verifique el certificado. ``` cat admin.crt ``` 1. Cree un enlace de roles de clúster para un usuario `admin`. ``` kubectl create clusterrolebinding admin --clusterrole=cluster-admin \ --user=admin --group=system:masters ``` 1. Genere un kubeconfig con ámbito de usuario para un estado desconectado. Puede generar un archivo `kubeconfig` con los certificados de `admin` descargados. Reemplace *my-cluster* y *apiserver-endpoint* en los siguientes comandos. ``` aws eks describe-cluster --name my-cluster \ --query "cluster.certificateAuthority" \ --output text | base64 --decode > ca.crt ``` ``` 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 ``` 1. Visualización del archivo `kubeconfig`. ``` kubectl get nodes --kubeconfig admin.kubeconfig ``` 1. Si ya tiene servicios en producción en su Outpost, omita este paso. Si Amazon EKS es el único servicio que se ejecuta en su Outpost y el Outpost no está en producción actualmente, puede simular una desconexión de red. Antes de iniciar la producción con el clúster local, simule una desconexión para asegurarse de que puede 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. No puede crear ninguna instancia nueva. Las instancias que se están ejecutando actualmente pierden la conectividad con la región de AWS e Internet. 1. Puede probar la conexión a su clúster local mientras está desconectado mediante el certificado `x509`. Asegúrese de cambiar su `kubeconfig` a la `admin.kubeconfig` que creó en un paso anterior. Reemplace *my-cluster* por el nombre de su clúster local. ``` kubectl config use-context admin@my-cluster --kubeconfig admin.kubeconfig ``` Si observa algún problema con sus clústeres locales mientras están desconectados, le recomendamos que abra un tique de soporte.