View a markdown version of this page

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 - Amazon EKS
Autenticación durante las desconexiones de redComportamiento de etcd durante las desconexionesRegistro del plano de control durante las desconexionesObservabilidad localRepositorio de imágenes localAjuste del comportamiento de conmutación por error del pod de KubernetesSimulación de una desconexión de red

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

Pod Identity de EKS

No. Consulte IRSA y Pod Identity durante las desconexiones.

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"

  2. 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: <base64-encoded-csr>
  signerName: kubernetes.io/kube-apiserver-client
  usages:
    - client auth
    kubectl apply -f admin-csr.yaml
kubectl certificate approve admin-csr

  3. Recupere el certificado firmado:

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

  4. Cree ClusterRoleBinding para conceder acceso de administrador:

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

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

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