Préparation aux déconnexions du réseau - Amazon EKS
Authentification auprès de votre cluster

Aidez à améliorer cette page

Vous souhaitez contribuer à ce guide de l'utilisateur ? Faites défiler cette page vers le bas et sélectionnez Modifier cette page sur GitHub. Vos contributions aideront à améliorer notre guide de l'utilisateur pour tout le monde.

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Préparation aux 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.

Considérations à prendre en compte pour préparer votre cluster local à une déconnexion du réseau :

  • 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 du 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 de dépannage du réseau du rack 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ésolution des problèmes de clusters locaux pour Amazon EKS sur 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 Métriques d'Outpost dans le Guide de l'utilisateur AWS Outposts.

  • Les clusters locaux utilisent IAM comme mécanisme d'authentification par défaut à l'aide d'AWS Identity and Access Management Authenticator 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 DNS dans le AWS OutpostsGuide de l'utilisateur d'.

  • 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 d'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 dimensionnement 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 avez l'habitude de télécharger les images de conteneur de votre application depuis Amazon ECR dans le cloud, envisagez d'exécuter un registre ou un cache 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) à AWS Certificate Manager (ACM), les certificats sont transmis 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 Résolution des problèmes liés au renouvellement géré des certificats dans le Guide de l'utilisateur AWS Certificate Manager.

  • 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 in the parentRégion AWS. Vous pouvez utiliser Prometheus, Grafana ou les solutions partenaires d'Amazon EKS pour surveiller le cluster localement à l'aide du point de terminaison des métriques du serveur d'API Kubernetes ou de Fluent Bit pour les journaux.

  • Si vous utilisez l'AWS Load Balancer Controller sur les Outposts pour le trafic d'applications, les Pods existants gérés par l'AWS Load Balancer Controller continuent de recevoir du trafic pendant les déconnexions du 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 plugin Amazon VPC CNI plugin for Kubernetes est en mode Secondary IP par défaut. Il est configuré avec WARM_ENI_TARGET=1, qui permet au plugin 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 readmefichier du plugin sur GitHub. Pour obtenir la liste du nombre maximum de Pods celles prises en charge par chaque type d'instance, consultez le eni-max-pods.txtfichier sur GitHub.

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

AWS Identity and Access Management (IAM) n'est pas disponible lors des déconnexions du 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.