View a markdown version of this page

Préparez des clusters Amazon EKS locaux sur AWS Outposts pour les déconnexions réseau - Amazon EKS
Régler le comportement de basculement du pod KubernetesAuthentification auprès de votre cluster local lors d'une déconnexion du réseau

Aidez à améliorer cette page

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.

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

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

Si votre réseau local n'est plus connecté au 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 lors de déconnexions réseau temporaires et imprévues. AWS Outposts reste une offre entièrement connectée qui agit comme une 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 vérification du dépannage du réseau AWS Outposts Rack dans le guide de l'utilisateur d'Outposts AWS . 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 clusters Amazon EKS locaux sur Outposts AWS.

  • 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 d' 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 d' 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 des AWS Outposts. L'exécution d'instances de rechange n'a donc aucun impact 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 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.

  • Les instantanés Amazon EBS ne peuvent pas être créés ou supprimés si AWS Outposts ne peut pas accéder aux API locales pertinentes 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 AWS région. 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 Résolution des problèmes liés au renouvellement géré des certificats dans le Guide de l'utilisateur de 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 aux CloudWatch journaux de la AWS région 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 le AWS Load Balancer Controller sur Outposts pour le trafic des applications, les pods existants dirigés par le AWS Load Balancer Controller continuent de recevoir du trafic lors des déconnexions du réseau. Les nouveaux 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 Cloud. AWS Envisagez de définir le nombre de répliques 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 du plugin 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.

Régler le comportement de basculement du pod Kubernetes

Lors des déconnexions du réseau, le contrôleur du cycle de vie des nœuds Kubernetes marque les nœuds inaccessibles, ce qui a pour effet de les altérer. node.kubernetes.io/unreachable NoExecute Par défaut, les pods sans tolérance correspondante sont expulsés au bout de 300 secondes (5 minutes). Vous pouvez ajuster ce comportement en DaemonSets le configurant tolerationSeconds sur les pods d'application ou en implémentant un contrôleur personnalisé, ce qui permet aux pods de rester sur leurs nœuds lors de déconnexions temporaires sans évictions inutiles. Pour obtenir des conseils détaillés et des exemples, consultez https://docs.aws.amazon.com/eks/latest/best-practices/hybrid-nodes-network-disconnection-best-practices.html # tune_kubernetes_pod_failover_behavior [Tune le comportement de basculement des pods Kubernetes] dans le guide des meilleures pratiques _Amazon EKS.

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 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 des règles de pare-feu aux appareils réseau qui connectent votre avant-poste à la AWS région. 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 AWS Région 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. my-clusterRemplacez-le 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.