View a markdown version of this page

Préparez des clusters Amazon EKS locaux sur AWS Outposts configurés avec le stockage d'instances EC2 pour les déconnexions réseau - Amazon EKS
Authentification lors des déconnexions du réseaucomportement etcd lors des déconnexionsEnregistrement du plan de contrôle lors des déconnexionsObservabilité localeRéférentiel d'images localRégler le comportement de basculement des pods KubernetesSimuler une déconnexion 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 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 configurés avec le stockage d'instances EC2 pour les déconnexions réseau

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

  • Les clusters locaux assurent 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 le AWS Cloud, nous vous recommandons d'essayer de rétablir votre connexion. Pour obtenir des instructions, consultez la liste de contrôle de dépannage du réseau rack AWS Outposts dans le Guide de l'utilisateur d' 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 Outposts Metrics dans le Guide de l'utilisateur d' AWS Outposts.

Authentification lors des déconnexions du réseau

Les clusters locaux prennent en charge plusieurs mécanismes d'authentification. Leur disponibilité lors des déconnexions réseau varie :

Mécanisme d’authentification Disponible lors de la déconnexion ?

AWS IAM (entrées d'accès, aws-auth ConfigMap)

Non. L'IAM nécessite une connectivité à la AWS région.

OIDC (fournisseur fourni par le client)

Cela dépend de l'emplacement du fournisseur. Si le fournisseur OIDC est joignable depuis le réseau local de l'Outpost, l'authentification continue de fonctionner.

certificats clients x.509

Oui. Les certificats sont validés localement par le serveur API Kubernetes.

IRSA (rôles IAM pour les comptes de service)

Non. VoirIRSA et Pod Identity lors des déconnexions.

Identité du pod EKS

Non. VoirIRSA et Pod Identity lors des déconnexions.

certificats clients x.509

Pour conserver kubectl l'accès pendant les déconnexions réseau, créez un certificat client x.509 avant la déconnexion.

Pour créer un certificat d'administrateur :

  1. Générez une clé privée et une demande de signature de certificat (CSR) :

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

  2. Créez une CertificateSigningRequest ressource Kubernetes et approuvez-la :

    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. Récupérez le certificat signé :

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

  4. Créez un ClusterRoleBinding pour accorder l'accès administrateur :

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

  5. Créez un kubeconfig qui utilise le certificat :

    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

Résolution DNS des points de terminaison du cluster lors des déconnexions

Le point de terminaison du serveur API Kubernetes pour un cluster local est hébergé dans Amazon Route 53 et correspond aux adresses IP privées des interfaces réseau élastiques (ENI) inter-comptes créées par Amazon EKS dans vos sous-réseaux. Ces ENI ont des adresses IP privées statiques qui ne changent pas pendant le fonctionnement normal du cluster.

Lors d'une déconnexion réseau, l'Outpost ne peut pas atteindre Route 53. Le nom d'hôte du point de terminaison du cluster n'est donc pas résolu à moins que vous n'ayez préparé un chemin de résolution local. Trois catégories de clients doivent accéder au serveur API :

  • Administrateurs de cluster en cours d'exécutionkubectl.

  • Worker nodes (kubelet) envoie des battements de cœur aux nœuds et extrait des spécifications.

  • kube-proxysur chaque nœud, ce qui configure les adresses IP de service du cluster.

Option 1 : solution DNS locale (recommandée)

AWS recommande de déployer une solution DNS locale qui met en cache les enregistrements des points de terminaison du cluster et les diffuse lorsque l'Outpost est déconnecté. Vous pouvez exécuter votre propre serveur DNS dans votre environnement local qui met en cache les enregistrements des points de terminaison du cluster.

Si vous utilisez une solution DNS locale, nous vous recommandons de pointer vos AMI kubeconfig et celles de votre nœud de travail vers le nom d'hôte du point de terminaison du cluster (et non vers les adresses IP ENI) afin que la résolution soit cohérente avec la solution DNS locale.

Option 2 : IP-based accès statique

Si vous ne souhaitez pas exécuter de solution DNS locale, vous pouvez utiliser un IP-based accès statique.

  • Administrateurs : configurez votre adresse kubeconfig pour qu'elle pointe directement vers une adresse IP privée ENI multicompte. Trouvez les ENI en recherchant les interfaces réseau dont la description figure Amazon EKS cluster-name dans votre AWS compte. L'adresse IP de chaque ENI est stable pendant toute la durée de vie du cluster en fonctionnement normal.

  • Nœuds de travail (AMI optimisées pour Amazon EKS) : lorsque vous lancez des nœuds de travail à partir d'une AMI optimisée pour Amazon EKS, le script bootstrap ajoute le point de terminaison du cluster /etc/hosts avec les adresses IP ENI. Aucune configuration supplémentaire n'est requise.

  • Nœuds de travail (AMI personnalisées) : ajoutez le nom d'hôte du point de terminaison du cluster et les adresses IP ENI /etc/hosts dans votre bootstrap personnalisé. Sinon, kubelet et kube-proxy vous ne pourrez pas accéder au serveur API lors d'une déconnexion.

Important

Si un ENI multicompte est supprimé ou si son adresse IP change (par exemple, si vous le supprimez ou si vous le modifiez de manière à empêcher Amazon EKS de le connecter à nouveau), chaque nœud et chaque administrateur utilisant un IP-based accès statique doivent être mis à jour manuellement. Avec une solution DNS locale, aucune intervention manuelle n'est requise.

Résolution DNS du pod lors des déconnexions

Pour éviter les pannes DNS lors d'une opération déconnectée, configurez le modèle de lancement de votre nœud de travail pour remplacer le kubelet’s `resolvConf paramètre. Dans vos données utilisateur, créez un resolv.conf fichier personnalisé (par exemple/etc/kubernetes/resolv.conf) contenant uniquement nameserver 10.0.0.2 (sans le domaine de recherche VPC), puis définissez spec.kubelet.config.resolvConf: /etc/kubernetes/resolv.conf votre. NodeConfig Cela supprime le domaine de region-code.compute.internal recherche de la configuration DNS du pod, empêchant ainsi le transfert des requêtes vers le résolveur DNS VPC inaccessible en cas de déconnexion.

L'exemple suivant montre les données utilisateur du nœud de travail :

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 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 et Pod Identity lors des déconnexions

Important

L'IRSA et EKS Pod Identity dépendent de AWS STS, qui fonctionne dans la AWS région. Lors d'une déconnexion réseau, les charges de travail qui utilisent IRSA ou Pod Identity ne peuvent pas obtenir de nouvelles informations d'identification. Les informations d'identification existantes expirent au bout d'un certain temps.

Nous ne recommandons pas de prendre en compte des dépendances fonctionnelles ou opérationnelles vis-à-vis Region-based AWS des services pour les charges de travail qui doivent rester disponibles pendant les déconnexions réseau.

comportement etcd lors des déconnexions

En cas de déconnexion du réseau, les etcd instantanés ne peuvent pas être sauvegardés. Si plusieurs etcd instances deviennent indisponibles lors d'une déconnexion, si le quorum est etcd perdu et que les opérations de l'API Kubernetes ne sont pas disponibles tant que votre Outpost ne se reconnecte pas et que le quorum n'est pas rétabli. etcd Les charges de travail déjà en cours d'exécution continuent de fonctionner.

Enregistrement du plan de contrôle lors des déconnexions

Lors des déconnexions réseau, les journaux du plan de contrôle sont mis en cache localement sur les instances du plan de contrôle. Lorsque la connectivité est rétablie, les journaux sont envoyés à Amazon CloudWatch Logs dans la AWS région parent. Il n'est pas nécessaire d'installer ou de gérer un agent de journalisation sur le plan de contrôle.

Observabilité locale

Vous pouvez surveiller votre cluster localement pendant les déconnexions en utilisant Prometheus, Grafana ou d'autres solutions tierces pour scraper le point de terminaison des métriques du serveur d'API Kubernetes.

Référentiel d'images local

Pour étendre les déploiements à l'aide de répliques supplémentaires ou pour remédier à des défaillances de pods lors de déconnexions, vous devez disposer d'un référentiel d'images de conteneur local (tel qu'un registre Docker), ou les images doivent être mises en cache sur le nœud avant la déconnexion. Amazon ECR n'est pas disponible lors des déconnexions réseau.

Régler le comportement de basculement des pods Kubernetes

Lors d'une déconnexion du réseau, le plan de contrôle Kubernetes ne peut pas communiquer avec la région. AWS Si un nœud devient inaccessible, le comportement par défaut de Kubernetes est d'expulser les pods après un délai d'attente. Vous pouvez ajuster ce comportement à l'aide des tolérances et des spécifications tolerationSeconds de votre pod pour contrôler la rapidité avec laquelle les pods sont replanifiés lors des partitions. 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 Kubernetes pod failover behavior] dans le _Amazon EKS Best Practices Guide.

Simuler une déconnexion réseau

Avant de passer en production avec votre cluster local, simulez une déconnexion pour vérifier que vous pouvez accéder à votre cluster lorsqu'il est déconnecté.

  1. Appliquez des règles de pare-feu aux périphériques réseau qui connectent votre Outpost à la AWS Région. Cela déconnecte le lien de service de l'Outpost.

  2. Testez la connexion à votre cluster local à l'aide du certificat x.509 que vous avez créé :

    kubectl --kubeconfig admin.kubeconfig get nodes
Note

Si des services sont déjà en production sur votre Outpost, ne simulez pas une déconnexion. La déconnexion de la liaison de service affecte tous les services exécutés sur l'Outpost.