View a markdown version of this page

Préparez des clusters Amazon EKS locaux sur AWS Outposts configurés avec le magasin 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 du pod KubernetesSimuler 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 configurés avec le magasin d'instances EC2 pour les déconnexions réseau

Si le lien de service AWS Outposts reliant votre réseau local au AWS Cloud a perdu sa 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 du réseau et explique 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 le 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 AWS Outposts rack dans le guide de l'utilisateur d'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.

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 du réseau varie :

Mécanisme d’authentification Disponible pendant la déconnexion ?

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

Non. L'IAM a besoin d'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 client x.509

Oui. Les certificats sont validés localement par le serveur d'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 client x.509

Pour maintenir kubectl l'accès pendant les déconnexions du réseau, créez un certificat client x.509 avant que la déconnexion ne se produise.

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 un 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 d'API Kubernetes pour un cluster local est hébergé sur 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 du réseau, l'Outpost ne peut pas atteindre la 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 clusters en cours d'exécutionkubectl.

  • Les nœuds de travail (kubelet) envoient les pulsations cardiaques des nœuds et extraient les spécifications.

  • kube-proxysur chaque nœud, qui définit les adresses IP des services 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 IP kubeconfig pour qu'elle pointe directement vers une adresse IP privée ENI entre comptes. 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 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 aux adresses IP ENI. Aucune configuration supplémentaire n'est nécessaire.

  • 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 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 le modifiez de manière à empêcher Amazon EKS de le rattacher à 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 défaillances du DNS lors d'une opération déconnectée, configurez le modèle de lancement de votre nœud de travail pour qu'il remplace 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 spec.kubelet.config.resolvConf: /etc/kubernetes/resolv.conf définissez 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 [.replaceable]``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 l'EKS Pod Identity dépendent de AWS STS, qui fonctionne dans la AWS région. Lors d'une déconnexion du 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 déconseillons de prendre 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 du réseau.

comportement etcd lors des déconnexions

Lors des déconnexions réseau, les etcd instantanés ne peuvent pas être sauvegardés. Si plusieurs etcd instances deviennent indisponibles lors d'une déconnexion, etcd perdent le quorum et les opérations de l'API Kubernetes ne sont pas disponibles tant que votre Outpost ne se reconnecte pas et etcd que le quorum n'est pas rétabli. Les charges de travail déjà en cours 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 lors des déconnexions en utilisant Prometheus, Grafana ou d'autres solutions tierces pour supprimer le point de terminaison des métriques du serveur d'API Kubernetes.

Référentiel d'images local

Pour étendre les déploiements avec des répliques supplémentaires ou pour effectuer une restauration en cas de panne de pod 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 du réseau.

Régler le comportement de basculement du pod 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'expiration. Vous pouvez ajuster ce comportement à l'aide de tolérances et en tolerationSeconds fonction des spécifications de vos pods pour contrôler la rapidité avec laquelle les pods sont reprogrammés pendant les 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 le comportement de basculement des pods Kubernetes] dans le guide des meilleures pratiques _Amazon EKS.

Simuler une déconnexion du 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 sur les appareils réseau qui connectent votre avant-poste à 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 du lien de service affecte tous les services exécutés sur l'Outpost.