Ce guide fournit de la documentation pour Wickr Enterprise. Si vous utilisez AWS Wickr, consultez le guide d'[administration d'AWS Wickr ou le guide](https://docs.aws.amazon.com/wickr/latest/adminguide/what-is-wickr.html) de l'utilisateur d'[AWS Wickr.](https://docs.aws.amazon.com/wickr/latest/userguide/what-is-wickr.html)
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.
# Connexion au cluster Kubernetes
L'API Amazon EKS n'est accessible que via un hôte bastion créé dans le cadre du déploiement. Par conséquent, toutes les `kubectl` commandes doivent être exécutées sur l'hôte bastion lui-même ou être transmises par proxy via l'hôte bastion.
## Connexion par proxy via le bastion
La première fois que vous vous connectez au cluster, vous devez mettre à jour votre fichier kubeconfig local à l'aide de la `aws eks update-kubeconfig` commande, puis le définir `proxy-url` dans votre configuration. Ensuite, chaque fois que vous souhaitez vous connecter au cluster, vous démarrez une session SSM avec l'hôte bastion pour transférer le port vers le proxy pour accéder à l'API.
**Configuration unique**
Il existe une valeur de sortie sur la `WickrEks` CloudFormation pile dont le nom commence par`WickrEnterpriseConfigCommand`. La valeur contient la commande complète nécessaire pour générer la configuration kubectl pour votre cluster. Cette sortie peut être visualisée à l'aide de la commande suivante :
```
aws cloudformation describe-stacks --stack-name WickrEks \
--query 'Stacks[0]{{.Outputs}}[?starts_with(OutputKey, `WickrEnterpriseConfigCommand`)]{{.OutputValue}}' \
--output text
```
Cela devrait générer une commande commençant par`aws eks update-kubeconfig`. Exécutez cette commande.
Ensuite, la configuration de Kubernetes doit être modifiée en fonction des requêtes proxy via l'hôte Bastion. Cela peut être fait à l'aide des commandes suivantes :
```
CLUSTER_ARN=$(aws cloudformation describe-stacks --stack-name WickrEks --query 'Stacks[0].Outputs[?OutputKey==`WickrEnterpriseEksClusterArn`].OutputValue' --output text)
kubectl config set {{"clusters.${CLUSTER_ARN}.proxy-url"}} http://localhost:8888
```
Si cela a fonctionné correctement, vous verrez une sortie comme `'Property "clusters.arn:aws:eks:us-west-2:012345678912:cluster/WickrEnterprise5B8BF472-1234a41c4ec48b7b615c6789d93dcce.proxy-url" set.'`
**Port en avant vers le bastion**
Pour vous connecter au cluster Amazon EKS, vous devez démarrer une session SSM afin de transférer les demandes vers le proxy exécuté sur votre hôte Bastion. La commande pour ce faire est fournie en sortie `BastionSSMProxyEKSCommand` sur la `WickrEks` pile. Exécutez la commande suivante pour afficher la valeur de sortie :
```
aws cloudformation describe-stacks --stack-name WickrEks \
--query 'Stacks[0]{{.Outputs}}[?OutputKey==`BastionSSMProxyEKSCommand`]{{.OutputValue}}' \
--output text
```
La commande qu'il émet commencera par`aws ssm start-session`. Exécutez cette commande pour démarrer un proxy local exécuté sur le port 8888 via lequel vous pouvez vous connecter au cluster Amazon EKS. Si le transfert de port fonctionne correctement, la sortie doit indiquer « En attente de connexions... ». Maintenez ce processus en cours pendant toute la durée nécessaire pour accéder au cluster Amazon EKS.
Si tout est correctement configuré, vous pourrez exécuter `kubectl get nodes` dans un autre terminal pour répertorier les nœuds de travail du cluster Amazon EKS :
```
kubectl get nodes
NAME STATUS ROLES AGE VERSION
ip-10-0-111-216.ec2.internal Ready none 3d v1.26.4-eks-0a21954
ip-10-0-180-1.ec2.internal Ready none 2d23h v1.26.4-eks-0a21954
ip-10-0-200-102.ec2.internal Ready none 3d v1.26.4-eks-0a21954
```