Préparer des clusters Amazon EKS locaux sur AWS Outposts pour les déconnexions du réseau - Amazon EKS
Authentification auprès de votre cluster local lors d'une déconnexion du réseau

Aidez à améliorer cette page

Pour contribuer à ce guide de l’utilisateur, cliquez sur le lien Modifier cette page sur GitHub qui se trouve dans le volet droit de chaque page.

Préparer des clusters Amazon EKS locaux sur AWS Outposts pour les déconnexions du réseau

Si votre réseau local a perdu la connectivité avec AWS Cloud, vous pouvez continuer à utiliser votre cluster Amazon EKS local sur un Outpost. Cette rubrique explique comment préparer votre cluster local pour les déconnexions du réseau et les considérations connexes.

  • Les clusters locaux garantissent la stabilité et la continuité des opérations en cas de déconnexions réseau temporaires et imprévues. AWS Outposts reste une offre entièrement connectée qui agit comme extension de AWS Cloud dans votre centre de données. En cas de déconnexion du réseau entre votre Outpost et AWS Cloud, nous vous recommandons de tenter de rétablir votre connexion. Pour obtenir des instructions, consultez la liste de contrôle pour le dépannage du réseau de racks AWS Outposts dans le Guide de l’utilisateur AWS Outposts. Pour plus d'informations sur la résolution des problèmes liés aux clusters locaux, consultez Résoudre les problèmes des clusters Amazon EKS locaux sur des AWS Outposts.

  • Les Outposts génèrent une métrique ConnectedStatus qui permet de surveiller l'état de connectivité de votre Outpost. Pour plus d’informations, consultez la section Outposts Metrics dans le Guide de l’utilisateur AWS Outposts.

  • Les clusters locaux utilisent IAM comme mécanisme d’authentification par défaut à l’aide de l’authentificateur de la gestion des identités et des accès AWS pour Kubernetes. IAM n’est pas disponible lors des déconnexions du réseau. Les clusters locaux prennent en charge un mécanisme d'authentification à l'aide des certificats x.509 que vous pouvez utiliser pour vous connecter à votre cluster lors des déconnexions du réseau. Pour plus d'informations sur l'obtention et l'utilisation d'un certificat x.509 pour votre cluster, consultez Authentification auprès de votre cluster local lors d'une déconnexion du réseau.

  • Si vous ne pouvez pas accéder à Route 53 lors des déconnexions du réseau, pensez à utiliser des serveurs DNS locaux dans votre environnement sur site. Les instances du plan de contrôle Kubernetes utilisent des adresses IP statiques. Vous pouvez configurer les hôtes que vous utilisez pour vous connecter à votre cluster avec le nom d'hôte et les adresses IP du point de terminaison comme alternative à l'utilisation de serveurs DNS locaux. Pour plus d’informations, consultez la section DNS dans le Guide de l’utilisateur AWS Outposts.

  • Si vous prévoyez une augmentation du trafic d'applications lorsque le réseau se déconnecte, vous pouvez allouer de la capacité de calcul de réserve dans votre cluster lorsque vous êtes connecté au cloud. Les instances Amazon EC2 sont incluses dans le prix de AWS Outposts. Ainsi, l’exécution d’instances de rechange n’a pas d’impact sur votre coût d’utilisation d’AWS.

  • Lors des déconnexions du réseau pour permettre les opérations de création, de mise à jour et de mise à l'échelle des charges de travail, les images de conteneur de votre application doivent être accessibles sur le réseau local et votre cluster doit disposer d'une capacité suffisante. Les clusters locaux n’hébergent pas de registre de conteneurs pour vous. Si les pods ont déjà été exécutés sur ces nœuds, les images de conteneur sont mises en cache sur les nœuds. Si vous téléchargez généralement les images de conteneurs de votre application depuis Amazon ECR dans le cloud, envisagez d'exécuter un cache ou un registre local. Un cache ou un registre local est utile si vous avez besoin d'opérations de création, de mise à jour et de mise à l'échelle pour les ressources de la charge de travail pendant les déconnexions du réseau.

  • Les clusters locaux utilisent Amazon EBS comme classe de stockage par défaut pour les volumes persistants et le pilote CSI Amazon EBS pour gérer le cycle de vie des volumes persistants Amazon EBS. Pendant les déconnexions du réseau, les pods qui sont sauvegardés par Amazon EBS ne peuvent pas être créés, mis à jour ou mis à l’échelle. En effet, ces opérations nécessitent des appels à l'API Amazon EBS dans le cloud. Si vous déployez des charges de travail avec état sur des clusters locaux et que vous avez besoin d’opérations de création, de mise à jour ou de mise à l’échelle lors des déconnexions du réseau, envisagez d’utiliser un autre mécanisme de stockage.

  • Il est impossible de créer ou de supprimer des instantanés Amazon EBS si AWS Outposts n’a pas accès aux API pertinentes de la région AWS (telles que les API pour Amazon EBS ou Amazon S3).

  • Lors de l’intégration d’ALB (Ingress) avec AWS Certificate Manager (ACM), les certificats sont transférés et stockés dans la mémoire de l’instance AWS Outposts ALB Compute. La terminaison TLS actuelle continuera de fonctionner en cas de déconnexion de la région AWS. Dans ce contexte, les opérations de mutation (telles que les nouvelles définitions d'entrée, les nouvelles opérations d'API de certificats basés sur ACM, le dimensionnement du calcul ALB ou la rotation des certificats) échoueront. Pour plus d’informations, consultez la section Dépannage du renouvellement des certificats gérés dans le Guide de l’utilisateur du gestionnaire de certificats AWS.

  • Les journaux du plan de contrôle Amazon EKS sont mis en cache localement sur les instances du plan de contrôle Kubernetes lors des déconnexions du réseau. Lors de la reconnexion, les journaux sont envoyés à CloudWatch Logs dans la région AWS parent. Vous pouvez utiliser Prometheus, Grafana ou les solutions partenaires Amazon EKS pour surveiller le cluster localement à l’aide du point de terminaison des métriques du serveur API Kubernetes ou à l’aide de Fluent Bit pour les journaux.

  • Si vous utilisez l’AWS Load Balancer Controller sur Outposts pour le trafic des applications, les pods existants gérés par l’AWS Load Balancer Controller continuent de recevoir du trafic pendant les déconnexions réseau. Les nouveaux pods créés lors de déconnexions du réseau ne reçoivent pas de trafic tant que l’Outpost n’est pas reconnecté au AWS Cloud. Envisagez de définir le nombre de réplicas pour vos applications lorsque vous êtes connecté au AWS Cloud afin de répondre à vos besoins de mise à l’échelle lors des déconnexions du réseau.

  • Le plug-in CNI Amazon VPC pour Kubernetes utilise par défaut le mode IP secondaire. Il est configuré avec WARM_ENI_TARGET=1, qui permet au plug-in de conserver « une interface réseau entièrement Elastic » contenant les adresses IP disponibles. Pensez à modifier les valeurs WARM_ENI_TARGET, WARM_IP_TARGET et MINIMUM_IP_TARGET en fonction de vos besoins de mise à l'échelle lors d'un état déconnecté. Pour plus d’informations, consultez le fichier readme pour le plug-in sur GitHub. Pour obtenir la liste du nombre maximal de pods pris en charge par chaque type d’instance, consultez le fichier eni-max-pods.txt sur GitHub.

Authentification auprès de votre cluster local lors d'une déconnexion du réseau

La gestion des identités et des accès AWS (IAM) n’est pas disponible en cas de déconnexions réseau. Vous ne pouvez pas vous authentifier auprès de votre cluster local à l’aide des informations d’identification IAM lorsque vous êtes déconnecté. Cependant, vous pouvez vous connecter à votre cluster sur votre réseau local à l'aide de certificats x509 en cas de déconnexion. Vous devez télécharger et stocker un certificat X509 client à utiliser lors des déconnexions. Dans cette rubrique, vous allez voir comment créer et utiliser le certificat pour vous authentifier auprès de votre cluster lorsqu’il est dans un état déconnecté.

  1. Créer une demande de signature de certificat.

    1. Générez une demande de signature de certificat.

      openssl req -new -newkey rsa:4096 -nodes -days 365 \
    -keyout admin.key -out admin.csr -subj "/CN=admin"

    2. Créez une demande de signature de certificat dans 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. Créez une demande de signature de certificat à l'aide de kubectl.

    kubectl create -f admin-csr.yaml

  3. Vérifiez le statut de la demande de signature de certificat.

    kubectl get csr admin-csr

    L'exemple qui suit illustre un résultat.

    NAME       AGE   REQUESTOR                       CONDITION
admin-csr  11m   kubernetes-admin                Pending

    Kubernetes a créé la demande de signature de certificat.

  4. Approuvez la demande de signature de certificat.

    kubectl certificate approve admin-csr

  5. Vérifiez à nouveau l'état de la demande de signature de certificat pour approbation.

    kubectl get csr admin-csr

    L'exemple qui suit illustre un résultat.

    NAME       AGE   REQUESTOR                     CONDITION
admin-csr  11m   kubernetes-admin              Approved

  6. Récupérez et vérifiez le certificat.

    1. Récupérez le certificat.

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

    2. Vérifiez le certificat.

      cat admin.crt

  7. Créez une liaison de rôle de cluster pour un utilisateur admin.

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

  8. Générez un kubeconfig spécifique à l'utilisateur pour un état déconnecté.

    Vous pouvez générer un fichier kubeconfig à l'aide des certificats admin téléchargés. Remplacez my-cluster et apiserver-endpoint dans les commandes suivantes.

    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. Affichez votre fichier kubeconfig.

    kubectl get nodes --kubeconfig admin.kubeconfig

  10. Si des services sont déjà en production sur votre Outpost, ignorez cette étape. Si Amazon EKS est le seul service qui s’exécute sur votre Outpost et que ce dernier n’est pas en production, vous pouvez simuler une déconnexion du réseau. Avant de passer en production avec votre cluster local, simulez une déconnexion pour vous assurer que vous pouvez accéder à votre cluster lorsqu’il est déconnecté.

    1. Appliquez les règles de pare-feu sur les appareils réseaux qui connectent votre Outpost à la région AWS. Cela déconnecte le lien de service de l'Outpost. Vous ne pouvez pas créer de nouvelles instances. Les instances en cours d’exécution perdent leur connectivité à la région AWS et à Internet.

    2. Vous pouvez tester la connection à votre cluster local à l'aide du certificat x509 en cas de déconnexion. Assurez-vous de remplacer votre kubeconfig par le admin.kubeconfig que vous avez créé à une étape précédente. Remplacez my-cluster par le nom de votre cluster local.

      kubectl config use-context admin@my-cluster --kubeconfig admin.kubeconfig

    Si vous remarquez des problèmes avec vos clusters locaux alors qu’ils sont déconnectés, nous vous recommandons d’ouvrir un ticket de support.