Préparez les EKS clusters Amazon locaux AWS Outposts pour les 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 tous.

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éparez les EKS clusters Amazon locaux AWS Outposts pour les déconnexions du réseau

Si votre réseau local a perdu la connectivité avec le AWS Cloud, vous pouvez continuer à utiliser votre EKS cluster Amazon 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 lors de déconnexions réseau temporaires et imprévues. AWS Outposts demeure une offre entièrement connectée qui agit comme une extension de AWS Cloud 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ésoudre les problèmes liés aux EKS clusters Amazon locaux 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 sont utilisés IAM comme mécanisme d'authentification par défaut à l'aide de l'AWS Identity and Access Management authentificateur pour Kubernetes. IAMn'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 de déconnexions réseau, pensez à utiliser des DNS serveurs locaux dans votre environnement local. Le Kubernetes les instances du plan de contrôle 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 au lieu d'utiliser des DNS serveurs locaux. Pour plus d'informations, consultez DNSle guide de AWS Outposts l'utilisateur.

  • 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 EC2 instances Amazon sont incluses dans le prix de AWS Outposts. L'exécution d'instances de rechange n'a donc aucune incidence sur vos coûts AWS d'utilisation.

  • 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 l'icône Pods ont déjà été exécutés sur ces nœuds, les images des conteneurs sont mises en cache sur les nœuds. Si vous extrayez généralement les images de conteneur 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 EBS CSI pilote Amazon pour gérer le cycle de vie des volumes EBS persistants Amazon. Lors des déconnexions du réseau, Pods qui sont soutenus par Amazon ne EBS peuvent pas être créés, mis à jour ou redimensionnés. En effet, ces opérations nécessitent des appels vers Amazon EBS API 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.

  • Les EBS instantanés Amazon ne peuvent pas être créés ou supprimés s' AWS Outposts ils ne peuvent pas accéder à la AWS région concernée APIs (comme pour APIs Amazon EBS ou Amazon S3).

  • Lors de l'intégration ALB (Ingress) avec AWS Certificate Manager (ACM), les certificats sont transmis et stockés dans la mémoire de l'instance AWS Outposts ALB Compute. TLSLa résiliation actuelle continuera de fonctionner en cas de déconnexion du Région AWS. Dans ce contexte, les opérations de mutation échoueront (telles que les nouvelles définitions d'entrée, les API opérations de nouveaux certificats ACM basés, l'échelle de ALB calcul ou la rotation des certificats). 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 EKS de contrôle Amazon sont mis en cache localement sur Kubernetes instances du plan de contrôle lors des déconnexions du réseau. Lors de la reconnexion, les journaux sont envoyés à CloudWatch Logs in the parent Région AWS. Vous pouvez utiliser Prometheus, Grafana, ou les solutions des EKS partenaires Amazon pour surveiller le cluster localement à l'aide du Kubernetes APIpoint de terminaison des métriques du serveur ou utilisation Fluent Bit pour les journaux.

  • Si vous utilisez AWS Load Balancer Controller sur Outposts pour le trafic des applications, existant Pods dirigé par le AWS Load Balancer Controller continuer à recevoir du trafic pendant les déconnexions du réseau. New Pods créés lors des 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épliques pour vos applications lorsqu'elles sont connectées au afin AWS Cloud de répondre à vos besoins de dimensionnement lors des déconnexions du réseau.

  • Le Amazon VPC CNI plugin for Kubernetes passe par défaut au mode IP secondaire. 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 une liste du nombre maximum de Pods qui est pris 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 IAM informations d'identification 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 du 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 and 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 exécuté sur votre Outpost et que celui-ci n'est pas actuellement 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é à Internet 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 avec 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.