Preparación de los clústeres locales de Amazon EKS en AWS Outposts para las desconexiones de la red - Amazon EKS
Autenticación en su clúster

Ayude a mejorar esta página

¿Quiere contribuir a esta guía del usuario? Desplácese hasta el final de esta página y seleccione Editar esta página en GitHub. Sus contribuciones ayudarán a que nuestra guía del usuario sea mejor para todos.

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.

Consideraciones a la hora de preparar el clúster local para una desconexión de red:

  • 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 la lista de verificación para la solución de problemas de red de los bastidores de AWS Outposts en la Guía del usuario de AWS Outposts. Para obtener más información acerca de cómo solucionar problemas con clústeres locales, consulte Solución de problemas de los clústeres locales de Amazon EKS en 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 en la Guía del usuario de AWS Outposts.

  • Los clústeres locales usan IAM como mecanismo de autenticación predeterminado mediante el Autenticador de AWS Identity and Access Management para Kubernetes. 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.

  • Si no puede acceder a Route 53 durante las desconexiones de red, considere la posibilidad de usar 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 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 habilitar 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, las Pods respaldadas por 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 usar 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 de AWS en la región (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 en la Guía del usuario de AWS Certificate Manager.

  • 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. Al volver a conectarse, los registros se envían a Registros de CloudWatch en la Región de AWS principal. Puede utilizar Prometheus, Grafana o las soluciones de socios de Amazon EKS para supervisar el clúster a nivel local mediante el punto de conexión de métricas del servidor de la API de Kubernetes o usar Fluent Bit para registros.

  • Si está usando el AWS Load Balancer Controller en Outposts para el tráfico de aplicaciones, los Pods existentes encabezados por el AWS Load Balancer Controller 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 Amazon VPC CNI plugin for Kubernetes predeterminado es un modo IP secundario. 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 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 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 puede autenticarse 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 usar 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"

    2. 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

  2. Cree una solicitud de firma de certificado con kubectl.

    kubectl create -f admin-csr.yaml

  3. 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.

  4. Apruebe la solicitud de firma de certificado.

    kubectl certificate approve admin-csr

  5. 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

  6. Recupere y verifique el certificado.

    1. Recupere el certificado.

      kubectl get csr admin-csr -o jsonpath='{.status.certificate}' | base64 --decode > admin.crt

    2. Verifique el certificado.

      cat admin.crt

  7. Cree un enlace de roles de clúster para un usuario admin.

    kubectl create clusterrolebinding admin --clusterrole=cluster-admin \
    --user=admin --group=system:masters

  8. 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

  9. Vea el archivo kubeconfig.

    kubectl get nodes --kubeconfig admin.kubeconfig

  10. 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.

    2. 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.