Configuration du noeud final de service cloud privé

Activez le noeud final de service cloud privé pour votre cluster.

Le noeud final de service cloud privé rend votre maître Kubernetes accessible en privé. Vos noeuds worker et vos utilisateurs de cluster autorisés peuvent communiquer avec le maître Kubernetes sur le réseau privé. Pour déterminer si vous pouvez activer le noeud final de service cloud privé, voir Communication entre les noeuds worker et le maître et entre les utilisateurs et le maître. Notez que vous ne pouvez pas désactiver le nœud final de service de cloud privé après l'avoir activé.

Avez-vous créé un cluster avec un noeud final de service cloud privé uniquement lorsque vous avez activé votre compte pour VRF et les noeuds finaux de service? Essayez de configurer le noeud final de service cloud public de manière à pouvoir utiliser votre cluster jusqu'à ce que vos cas de support soient traités pour mettre à jour votre compte.

1. Activez VRF dans votre compte d'infrastructure IBM Cloud. Pour vérifier si la fonction VRF est déjà activée, utilisez la commande ibmcloud account show.

2. Activez votre compte IBM Cloud pour utiliser des noeuds finaux de service.

3. Activez le noeud final de service de cloud privé.

   ibmcloud ks cluster master private-service-endpoint enable --cluster CLUSTER_NAME_OR_ID
   

4. Actualisez le serveur d'API du maître Kubernetes pour l'utilisation du noeud final de service de cloud privé. Vous pouvez le faire à l'invite de l'interface de ligne de commande ou exécuter la commande suivante. Il peut s'écouler plusieurs minutes avant que le maître ne soit actualisé.

   ibmcloud ks cluster master refresh --cluster CLUSTER_NAME_OR_ID
   

5. Créez une mappe de configuration (configmap) pour contrôler le nombre maximal de noeuds worker pouvant être indisponibles à moment donné dans votre cluster. Lorsque vous mettez à jour vos noeuds worker, la mappe de configuration permet d'éviter l'interruption de vos applications car les applications sont replanifiées dans l'ordre sur les noeuds worker disponibles.

6. Mettez à jour tous les noeuds worker de votre cluster pour récupérer la configuration du noeud final de service de cloud privé.

   En émettant la commande de mise à jour, les noeuds worker sont rechargés pour récupérer la configuration du noeud final de service. Si aucun noeud worker n'est disponible, vous devez recharger manuellement les noeuds worker. Dans ce cas, veillez à effectuer les opérations cordon et drain, et à gérer l'ordre pour contrôler le nombre maximal de noeuds worker indisponibles à moment donné.

   ibmcloud ks worker update --cluster CLUSTER_NAME_OR_ID --worker WORKER1,WORKER2
   

7. Si le cluster se trouve dans un environnement protégé par un pare-feu :

   • Autorisez vos utilisateurs de cluster autorisés à exécuter des commandes kubectl pour accéder au maître via le noeud final de service de cloud privé.
   • Autorisez le trafic réseau sortant sur les adresses IP privées pour les ressources d'infrastructure et les services IBM Cloud que vous envisagez d'utiliser.

8. Facultatif : pour utiliser le noeud final de service cloud privé uniquement :

   1. Désactivez le noeud final de service cloud public.
   2. Configurez l'accès au maître sur le noeud final de service cloud privé.

Configuration du noeud final de service cloud public

Activez ou désactivez le noeud final de service cloud public pour votre cluster.

Le noeud final de service cloud public rend votre maître Kubernetes accessible au public. Vos noeuds worker et vos utilisateurs de cluster autorisés peuvent communiquer de manière sécurisée avec le maître Kubernetes sur le réseau public. Pour plus d'informations, voir Communication entre les noeuds worker et le maître et entre les utilisateurs et le maître.

Passage du noeud final de service cloud public au noeud final de service cloud privé

Activez les noeuds worker pour communiquer avec le maître via le réseau privé au lieu du réseau public en activant le noeud final de service de cloud privé.

Tous les clusters connectés à un VLAN public et un VLAN privé utilisent le noeud final de service cloud public par défaut. Vos noeuds worker et vos utilisateurs de cluster autorisés peuvent communiquer de manière sécurisée avec le maître Kubernetes sur le réseau public. Pour activer les noeuds worker pour communiquer avec le maître Kubernetes via le réseau privé à la place du réseau public, vous pouvez activer le noeud final de service de cloud privé. Ensuite, vous pouvez éventuellement désactiver le noeud final de service cloud public.

• Si vous activez le noeud final de service cloud privé en conservant le noeud final de service cloud public activé, les noeuds worker communiquent toujours avec le maître via le réseau privé, mais vos utilisateurs peuvent communiquer avec le maître via le réseau public ou privé.
• Si vous activez le noeud final de service cloud privé en désactivant le noeud final de service cloud public, les noeuds worker et les utilisateurs doivent communiquer avec le maître via le réseau privé.

Vous ne pouvez pas désactiver le point de terminaison du service de cloud privé une fois que vous l'avez activé.

1. Activez VRF dans votre compte d'infrastructure IBM Cloud. Pour vérifier si la fonction VRF est déjà activée, utilisez la commande ibmcloud account show.

2. Activez votre compte IBM Cloud pour utiliser des noeuds finaux de service.

3. Activez le noeud final de service de cloud privé.

   ibmcloud ks cluster master private-service-endpoint enable --cluster CLUSTER_NAME_OR_ID
   

4. Actualisez le serveur d'API du maître Kubernetes pour l'utilisation du noeud final de service cloud privé à l'invite de l'interface de ligne de commande ou en exécutant la commande suivante. Il peut s'écouler plusieurs minutes avant que le maître ne soit actualisé.

   ibmcloud ks cluster master refresh --cluster CLUSTER_NAME_OR_ID
   

5. Créez une mappe de configuration (configmap) pour contrôler le nombre maximal de noeuds worker pouvant être indisponibles à moment donné dans votre cluster. Lorsque vous mettez à jour vos noeuds worker, la mappe de configuration permet d'éviter l'interruption de vos applications car les applications sont replanifiées dans l'ordre sur les noeuds worker disponibles.

6. Mettez à jour tous les noeuds worker de votre cluster pour récupérer la configuration du noeud final de service de cloud privé.

   En émettant la commande de mise à jour, les noeuds worker sont rechargés pour récupérer la configuration du noeud final de service. Si aucun noeud worker n'est disponible, vous devez recharger manuellement les noeuds worker. Dans ce cas, veillez à effectuer les opérations cordon et drain, et à gérer l'ordre pour contrôler le nombre maximal de noeuds worker indisponibles à moment donné.

   ibmcloud ks worker update --cluster CLUSTER_NAME_OR_ID --worker WORKER1,WORKER2
   

7. Facultatif : pour utiliser le noeud final de service cloud privé uniquement :

   1. Désactivez le noeud final de service cloud public.

       ibmcloud ks cluster master public-service-endpoint disable --cluster CLUSTER_NAME_OR_ID
       ```
   2. [Configurez l'accès au maître sur le noeud final de service cloud privé](/docs/containers?topic=containers-access-private-classic).
   
   
   
   

Modification des connexions de VLAN de vos noeuds worker

Lorsque vous créez un cluster, vous déterminez si la connexion de vos noeuds worker doit s'effectuer avec un VLAN public et un VLAN privé ou uniquement avec un VLAN privé. Vos noeuds worker font partie de pools de noeuds worker qui stockent les métadonnées de réseau incluant les VLAN à utiliser pour mettre à disposition les futurs noeuds worker dans le pool. Vous envisagerez peut-être de modifier la configuration de la connectivité de VLAN de votre cluster ultérieurement dans les cas suivants.

• Les VLAN du pool de noeuds worker dans une zone ont atteint leur capacité maximale et vous devez prévoir l'utilisation d'un nouveau VLAN pour les noeuds worker de votre cluster.
• Vous disposez d'un cluster avec des noeuds worker figurant à la fois sur des VLAN public et privé, mais vous voulez passer à un cluster privé uniquement.
• Vous disposez d'un cluster privé uniquement, mais vous souhaitez avoir quelques noeuds worker, par exemple un pool de noeuds worker de noeuds de périphérie sur le VLAN public pour exposer vos applications sur Internet.

Vous essayez à la place de modifier le noeud final de service pour la communication entre le maître et les noeuds worker ? Consultez la rubrique sur la configuration de noeuds finaux de service publics et privés.

Le retrait de tous les noeuds worker d'un VLAN supprime l'adresse IP de l'équilibreur de charge d'application Ingress dans la zone du VLAN.

Connectez-vous à votre compte. Le cas échéant, ciblez le groupe de ressources approprié. Définissez le contexte de votre cluster.

Pour modifier les VLAN utilisés par un pool de noeuds worker pour mettre à disposition des noeuds worker :

1. Affichez la liste des pools de noeuds worker de votre cluster.

   ibmcloud ks worker-pool ls --cluster CLUSTER_NAME_OR_ID
   

2. Déterminez les zones d'un des pools de noeuds worker. Dans la sortie, recherchez la zone Zones.

   ibmcloud ks worker-pool get --cluster CLUSTER_NAME_OR_ID --worker-pool POOL_NAME
   

3. Pour chaque zone identifiée à l'étape précédente, obtenez un VLAN public et un VLAN privé compatibles.

   1. Vérifiez les VLAN publics et privés répertoriés sous Type dans la sortie.

       ibmcloud ks vlan ls --zone ZONE
       ```
   2. Vérifiez que le VLAN public et le VLAN privé dans la zone sont compatibles. Pour qu'ils soient compatibles, le routeur (**Router**) doit avoir le même ID de pod. Dans cet exemple, les ID de pod de **Router** correspondent : `01a` et `01a`. Si un ID de groupe était `01a` et que l'autre était `02a`, vous ne pouvez pas définir ces ID VLAN publics et privés pour votre pool de travailleurs.
   ```sh {: screen}
       ID        Name   Number   Type      Router         Supports Virtual Workers
       229xxxx          1234     private   bcr01a.dal12   true
       229xxxx          5678     public    fcr01a.dal12   true
       ```
   3. Si vous devez commander un nouveau VLAN public et un nouveau VLAN privé, vous pouvez le faire dans la [console IBM Cloud](/docs/vlans?topic=vlans-ordering-premium-vlans#ordering-premium-vlans) ou utiliser la commande ci-après. N'oubliez pas que les VLAN doivent être compatibles, avec des ID de pod de **Router** correspondants, comme indiqué à l'étape précédente. Si vous créez une paire de nouveaux VLAN public-privé, ces VLAN doivent être compatibles.
   ```sh {: pre}
       ibmcloud sl vlan create -t [public|private] -d <zone> -r <compatible_router>
       ```
   4. Notez les ID des VLAN compatibles.
   
   

4. Configurez un pool de noeuds worker avec les mêmes métadonnées de réseau VLAN pour chaque zone. Vous pouvez créer un nouveau pool de noeuds worker ou modifier un pool existant.

   • Créer un pool de travailleurs: consultez la section Ajouter des nœuds de travail en créant un nouveau pool de travailleurs.

   • Modifier un pool de noeuds worker existant : définissez les métadonnées de réseau du pool de noeuds worker pour utiliser le VLAN pour chaque zone. Les noeuds worker déjà créés dans le pool continuent à utiliser les VLAN précédents, mais les nouveaux noeuds worker du pool utilisent les métadonnées du nouveau VLAN que vous avez défini.

   • Exemple pour ajouter un VLAN public et un VLAN privé, comme si vous passiez d'un VLAN privé uniquement à une paire de VLAN public-privé :

       ibmcloud ks zone network-set --zone ZONE --cluster CLUSTER_NAME_OR_ID --worker-pool POOL_NAME --private-vlan PRIVATE_VLAN_ID --public-vlan PUBLIC_VLAN_ID
       ```
   - Exemple pour ajouter uniquement un VLAN privé, comme si vous passiez d'une paire de VLAN public-privé à un VLAN privé uniquement lorsque vous avez un [compte avec la fonction VRF activée qui utilise des noeuds finaux de service](/docs/account?topic=account-vrf-service-endpoint) :
   
   ```sh {: pre}
       ibmcloud ks zone network-set --zone ZONE --cluster CLUSTER_NAME_OR_ID --worker-pool POOL_NAME --private-vlan PRIVATE_VLAN_ID --private-only
       ```
   

5. Ajoutez des noeuds worker dans le pool de noeuds worker en redimensionnant le pool.

   ibmcloud ks worker-pool resize --cluster CLUSTER_NAME_OR_ID --worker-pool POOL_NAME --size-per-zone NUMBER_OF_WORKERS_PER_ZONE
   

   Si vous souhaitez retirer des noeuds worker qui utilisent les anciennes métadonnées de réseau, modifiez le nombre de noeuds worker par zone pour doubler leur nombre dans chaque zone. Un peu plus loin dans cette procédure, vous pourrez effectuer des opérations cordon, drain et remove sur les noeuds worker précédents.

6. Vérifiez que les nouveaux noeuds worker sont créés avec les adresses IP publiques et IP privées appropriées dans la sortie. Par exemple, si vous passez d'un pool de noeuds worker avec une paire de VLAN public-privé à un pool de noeuds worker avec VLAN privé uniquement, les nouveaux noeuds worker n'auront qu'une adresse IP privée. Inversement, si vous passez d'un pool de noeuds worker avec un VLAN privé uniquement à un pool de noeuds worker avec une paire de VLAN public-privé, les nouveaux noeuds worker auront une adresse IP publique et une adresse IP privée.

   ibmcloud ks worker ls --cluster CLUSTER_NAME_OR_ID --worker-pool POOL_NAME
   

7. Facultatif : retirez les noeuds worker avec les métadonnées de réseau précédentes du pool de noeuds worker.

   1. Dans la sortie de l'étape précédente, notez l'ID des noeuds worker que vous souhaitez retirer du pool de noeuds worker.
   2. Supprimez le noeud worker.

       ibmcloud ks worker rm --cluster CLUSTER_NAME_OR_ID --worker WORKER_NAME_OR_ID
       ```
   3. Vérifiez que le noeud worker est supprimé.
   ```sh {: pre}
       ibmcloud ks worker ls --cluster CLUSTER_NAME_OR_ID --worker-pool POOL_NAME
       ```
   4. Rééquilibrez le pool de nœuds worker.
   ```sh {: pre}
       ibmcloud ks worker-pool rebalance --cluster CLUSTER_NAME_OR_ID --worker-pool POOL_NAME
       ```
   
   
   

8. Facultatif : répétez les étapes 2 à 7 pour chaque pool de travailleurs de votre cluster. Lorsque vous avez terminé, tous les noeuds worker de votre cluster sont configurés avec les nouveaux VLAN.

9. Les équilibreurs de charge d'application par défaut contenus dans votre cluster sont toujours liés à l'ancien VLAN car leurs adresses IP proviennent d'un sous-réseau de ce VLAN. Comme les ALB ne peuvent pas être déplacés sur des VLAN, vous pouvez à la place rréer des ALB dans des VLAN et désactiver les ALB dans les anciens VLAN.

10. Facultatif : si vous n'avez plus besoin des sous-réseaux sur les anciens VLAN, vous pouvez les retirer.