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.
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 contribueront à 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.
Cette rubrique fournit une vue d'ensemble des éléments à prendre en compte lors de l'exécution d'un cluster local sur un Outpost. Elle donne également des instructions pour déployer un cluster local sur un Outpost.
Important
-
Ces considérations ne sont pas reprises dans la EKS documentation Amazon associée. Si d'autres rubriques de EKS la documentation Amazon sont en conflit avec les considérations présentées ici, suivez les considérations décrites ici.
-
Ces considérations sont sujettes à modification et peuvent changer fréquemment. Nous vous recommandons donc de consulter régulièrement cette rubrique.
-
De nombreuses considérations sont différentes de celles relatives à la création d'un cluster sur le AWS cloud.
-
Les clusters locaux prennent uniquement en charge les racks Outpost. Un seul cluster local peut s'exécuter sur plusieurs racks Outpost physiques qui constituent un seul Outpost logique. Un seul cluster local ne peut pas fonctionner sur plusieurs Outposts logiques. Chaque avant-poste logique possède un seul ARN avant-poste.
-
Les clusters locaux exécutent et gèrent Kubernetes contrôlez le plan dans votre compte sur l'Outpost. Vous ne pouvez pas exécuter de charges de travail sur Kubernetes instances du plan de contrôle ou modifiez le Kubernetes composants du plan de commande. Ces nœuds sont gérés par le EKS service Amazon. Modifications apportées au Kubernetes le plan de contrôle ne persiste pas en raison EKS des actions de gestion automatiques d'Amazon, telles que l'application de correctifs.
-
Les clusters locaux prennent en charge les modules complémentaires autogérés et les groupes de nœuds Amazon Linux autogérés. Le VPCCNIplugin Amazon pour Kubernetes, kube-proxy et les DNS modules complémentaires Core sont automatiquement installés sur les clusters locaux.
-
Les clusters locaux nécessitent l'utilisation d'Amazon EBS on Outposts. Amazon doit être EBS disponible dans votre Outpost pour Kubernetes stockage du plan de commande.
-
Les clusters locaux utilisent Amazon EBS on Outposts. Amazon doit être EBS disponible dans votre Outpost pour Kubernetes stockage du plan de commande. Les Outposts ne prennent en charge que les EBS
gp2
volumes Amazon. -
EBSSoutenu par Amazon Kubernetes
PersistentVolumes
sont pris en charge à l'aide du EBS CSI pilote Amazon. -
Les instances du plan de contrôle des clusters locaux sont configurées selon une topologie empilée à haute disponibilité
. Deux des trois instances du plan de contrôle doivent être saines à tout moment pour maintenir le quorum. Si le quorum est perdu, contactez le AWS support, car certaines actions côté service seront nécessaires pour activer les nouvelles instances gérées.
Prérequis
-
Un Outpost existant. Pour plus d'informations, consultez What is AWS Outposts.
-
L'outil de ligne de
kubectl
commande est installé sur votre ordinateur ou AWS CloudShell. La version peut être identique ou supérieure à une version mineure antérieure ou ultérieure à Kubernetes version de votre cluster. Par exemple, si la version de votre cluster est1.29
, vous pouvez utiliser la versionkubectl
1.28
,1.29
ou1.30
. Pour installer ou mettre à niveaukubectl
, veuillez consulter Configurer kubectl et eksctl. -
Version
2.12.3
ou version ultérieure1.27.160
ou version ultérieure de l'interface de ligne de AWS commande (AWS CLI) installée et configurée sur votre appareil ou AWS CloudShell. Pour vérifier votre version actuelle, utilisezaws --version | cut -d / -f2 | cut -d ' ' -f1
. Des gestionnaires de packages tels queyum
apt-get
, ou Homebrew for macOS ont souvent plusieurs versions de retard par rapport à la dernière version du AWS CLI. Pour installer la dernière version, consultez la section Installation et configuration rapide avec aws configure dans le Guide de l'utilisateur de l'interface de ligne de AWS commande. La AWS CLI version installée AWS CloudShell peut également avoir plusieurs versions de retard par rapport à la dernière version. Pour le mettre à jour, consultez la section Installation AWS CLI dans votre répertoire personnel dans le guide de AWS CloudShell l'utilisateur. -
Un IAM principal (utilisateur ou rôle) autorisé à accéder à un EKS cluster Amazon
create
et àdescribe
un tel cluster. Pour plus d’informations, consultez Créez un local Kubernetes cluster sur un avant-poste et Affichage de la liste ou description de tous les clusters.
Lorsqu'un EKS cluster Amazon local est créé, le IAMprincipal qui crée le cluster est ajouté définitivement. Le principal est spécifiquement ajouté au Kubernetes RBACtable d'autorisation en tant qu'administrateur. Cette entité possède des autorisations system:masters
. L'identité de cette entité n'est pas visible dans la configuration de votre cluster. Il est donc important de noter l'entité qui a créé le cluster et de veiller à ne jamais le supprimer. Au départ, seul le principal qui a créé le serveur peut appeler le Kubernetes APIserveur utilisantkubectl
. Si vous utilisez la console pour créer le cluster, assurez-vous que les mêmes IAM informations d'identification figurent dans la chaîne AWS SDK d'informations d'identification lorsque vous exécutez des kubectl
commandes sur votre cluster. Une fois votre cluster créé, vous pouvez accorder à d'autres IAM principaux l'accès à votre cluster.