**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](https://docs.aws.amazon.com/outposts/latest/userguide/network-troubleshoot.html) 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](https://docs.aws.amazon.com/outposts/latest/userguide/outposts-cloudwatch-metrics.html#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. Voir[IRSA et Pod Identity lors des déconnexions](#eks-outposts-instance-store-network-disconnects-irsa). | | Identité du pod EKS | Non. Voir[IRSA et Pod Identity lors des déconnexions](#eks-outposts-instance-store-network-disconnects-irsa). | ### 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" ``` 1. 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: signerName: kubernetes.io/kube-apiserver-client usages: - client auth ``` ``` kubectl apply -f admin-csr.yaml kubectl certificate approve admin-csr ``` 1. Récupérez le certificat signé : ``` kubectl get csr admin-csr -o jsonpath='{.status.certificate}' | base64 --decode > admin.crt ``` 1. Créez un `ClusterRoleBinding` pour accorder un accès administrateur : ``` kubectl create clusterrolebinding admin --clusterrole=cluster-admin \ --user=admin --group=system:masters ``` 1. 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écution`kubectl`. + **Les nœuds** de travail (`kubelet`) envoient les pulsations cardiaques des nœuds et extraient les spécifications. + **`kube-proxy`**sur 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](https://prometheus.io/)[,](https://grafana.com/) 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. 1. 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.