IBM Cloud Docs
Ouverture des ports et adresses IP requis dans votre liste d'autorisations

Ouverture des ports et adresses IP requis dans votre liste d'autorisations

Clusters classiques

Ces informations sont spécifiques aux clusters classiques. Pour les clusters VPC, voir Ouverture des ports et adresses IP requis dans votre liste d'autorisations pour les clusters VPC.

Examinez les situations dans lesquelles vous pourriez avoir besoin d'ouvrir des ports et des adresses IP spécifiques dans vos listes d'autorisations pour vos clusters Red Hat® OpenShift® on IBM Cloud®.

  • Listes d'autorisation de l'entreprise: Si les règles du réseau de l'entreprise empêchent l'accès de votre système local aux points de terminaison publics via des proxies ou des listes d'autorisation, vous devez autoriser l'accès pour exécuter les commandes ibmcloud, ibmcloud oc, ibmcloud cr, oc et calicoctl à partir de votre système local.
  • Listes d'autorisation de l'appliance de passerelle: Si vous avez configuré des listes d'autorisation sur le réseau public ou privé dans votre compte d'infrastructure IBM Cloud, tel qu'un VRA, vous devez ouvrir des plages IP, des ports et des protocoles pour permettre aux nœuds de travail de communiquer avec le maître, avec les ressources de l'infrastructure et avec d'autres services IBM Cloud. Vous pouvez également ouvrir des ports pour autoriser le trafic entrant vers des services qui exposent des applications dans votre cluster.
  • Calico les stratégies de réseau: Si vous utilisez les stratégies réseau Calico comme liste d'autorisation pour restreindre toutes les sorties des nœuds de travail, vous devez permettre à vos nœuds de travail d'accéder aux ressources nécessaires au fonctionnement de la grappe.
  • Autres services ou listes d'autorisation réseau: Pour permettre à votre cluster d'accéder à des services qui s'exécutent à l'intérieur ou à l'extérieur de IBM Cloud ou dans des réseaux sur site et qui sont protégés par une liste d'autorisations, vous devez ajouter les adresses IP de vos nœuds de travail à cette liste d'autorisations.

Ouverture de ports dans une liste de contrôle d'entreprise

Si les règles du réseau de l'entreprise empêchent l'accès de votre système local aux terminaux publics via des proxys ou des listes d'autorisation, vous devez autoriser l'accès pour exécuter les commandes ibmcloud, ibmcloud oc, et ibmcloud cr, oc et calicoctl à partir de votre système local.

Exécution des commandes ibmcloud, ibmcloud oc, et ibmcloud cr à partir d'une liste d'autorisations

Si les politiques du réseau d'entreprise empêchent l'accès de votre système local aux points de terminaison publics via des proxies ou des listes d'autorisation, pour exécuter les commandes ibmcloud, ibmcloud oc et ibmcloud cr, vous devez autoriser l'accès TCP pour IBM Cloud, Red Hat OpenShift on IBM Cloud et IBM Cloud Container Registry.

  1. Autoriser l'accès à cloud.ibm.com sur le port 443 dans votre liste d'autorisations.

  2. Vérifiez votre connexion en vous connectant à IBM Cloud via ce noeud final d'API.

    ibmcloud login -a https://cloud.ibm.com/
    
  3. Autoriser l'accès à containers.cloud.ibm.com sur le port 443 dans votre liste d'autorisations.

  4. Vérifiez votre connexion. Si l'accès est configuré correctement, les zones sont affichées dans la sortie.

    curl https://containers.cloud.ibm.com/v1/zones
    

    Exemple de sortie

    [{"id":"mon01","metro":""},{"id":"tor01","metro":""},{"id":"wdc04","metro":"Washington D.C."},{"id":"wdc06","metro":"Washington D.C."},{"id":"wdc07","metro":"Washington D.C."}]
    
  5. Autorisez l'accès aux régions IBM Cloud Container Registry que vous prévoyez d'utiliser sur le port 443 dans votre liste d'autorisations. Le registre global héberge des images publiques fournies par IBM et les registres régionaux stockent vos propres images privées ou publiques.

  6. Vérifiez votre connexion en dressant la liste des espaces de noms de votre registre de conteneurs.

Exécution de commandes oc à partir d'une liste autorisée

Si les règles du réseau de l'entreprise empêchent l'accès de votre système local aux points d'extrémité publics via des proxies ou des listes d'autorisation, pour exécuter les commandes oc, vous devez autoriser l'accès TCP pour le cluster.

Lorsqu'un cluster est créé, le port des URL de nœud final de service est affecté de manière aléatoire à partir de 30000 - 32767. Vous pouvez choisir d'ouvrir la plage de ports 30000 - 32767 pour tout cluster qui pourrait être créé ou vous pouvez choisir d'autoriser l'accès à un cluster existant spécifique.

Avant de commencer, autorisez l'accès pour exécuter des commandes ibmcloud oc.

Pour autoriser l'accès à un cluster spécifique :

  1. Connectez-vous à l'interface de ligne de commande IBM Cloud. A l'invite, entrez vos données d'identification IBM Cloud. Si vous disposez d'un compte fédéré, incluez l'option --sso.

    ibmcloud login [--sso]
    
  2. Si le cluster se trouve dans un autre groupe de ressources que default, ciblez ce groupe de ressources. Pour voir à quel groupe de ressources appartient chaque cluster, exécutez la commande ibmcloud oc cluster ls. Remarque : vous devez disposer au moins du rôle Afficheur pour le groupe de ressources.

    ibmcloud target -g <resource_group_name>
    
  3. Obtenez le nom de votre cluster.

    ibmcloud oc cluster ls
    
  4. Extrayez les URL de noeud final de service pour votre cluster.

    • Si seule l'URL du noeud final de service public est indiquée, extrayez cette URL. Vos utilisateurs de cluster autorisés peuvent accéder au maître via ce noeud final sur le réseau public.
    • Si seule l'URL du noeud final de service privé est indiquée, extrayez cette URL. Vos utilisateurs de cluster autorisés peuvent accéder au maître via ce noeud final sur le réseau privé.
    • Si l'URL du noeud final de service public et l'URL du noeud final de service privé sont indiquées, extrayez ces deux URL. Vos utilisateurs de cluster autorisés peuvent accéder au maître via le noeud final public sur le réseau public ou via le noeud final privé sur le réseau privé.
    ibmcloud oc cluster get --cluster <cluster_name_or_ID>
    

    Exemple de sortie

    ...
    Public Service Endpoint URL:    https://c3.<region>.containers.cloud.ibm.com:30426
    Private Service Endpoint URL:   https://c3-private.<region>.containers.cloud.ibm.com:31140
    ...
    
  5. Autorisez l'accès aux URL de noeud final de service et aux ports que vous avez obtenus à l'étape précédente. Si votre liste d'autorisation est basée sur les adresses IP, vous pouvez voir quelles adresses IP sont ouvertes lorsque vous autorisez l'accès aux URL des points de terminaison du service en consultant ce tableau.

  6. Vérifiez votre connexion.

    • Si le noeud final de service cloud public est activé :

      curl --insecure <public_service_endpoint_URL>/version
      

      Exemple de commande :

      curl --insecure https://c3.<region>.containers.cloud.ibm.com:31142/version
      

      Exemple de sortie

      {
      "major": "1",
      "minor": "7+",
      "gitVersion": "v1.7.4-2+eb9172c211dc41",
      "gitCommit": "eb9172c211dc4108341c0fd5340ee5200f0ec534",
      "gitTreeState": "clean",
      "buildDate": "2017-11-16T08:13:08Z",
      "goVersion": "go1.8.3",
      "compiler": "gc",
      "platform": "linux/amd64"
      }
      
    • Si le noeud final de service cloud privé est activé, vous devez être dans votre réseau privé IBM Cloud ou vous connecter au réseau privé via une connexion VPN pour vérifier votre connexion au maître. Remarque : vous devez exposer le noeud final maître via un équilibreur de charge privé de sorte que les utilisateurs puissent accéder au maître via un VPN ou une connexion IBM Cloud® Direct Link.

      curl --insecure <private_service_endpoint_URL>/version
      

      Exemple de commande :

      curl --insecure https://c3-private.<region>.containers.cloud.ibm.com:31142/version
      

      Exemple de sortie

      {
      "major": "1",
      "minor": "7+",
      "gitVersion": "v1.7.4-2+eb9172c211dc41",
      "gitCommit": "eb9172c211dc4108341c0fd5340ee5200f0ec534",
      "gitTreeState": "clean",
      "buildDate": "2017-11-16T08:13:08Z",
      "goVersion": "go1.8.3",
      "compiler": "gc",
      "platform": "linux/amd64"
      }
      
  7. Facultatif : répétez ces étapes pour chaque cluster que vous avec besoin d'exposer.

Exécution de commandes calicoctl à partir d'une liste autorisée

Si les règles du réseau de l'entreprise empêchent l'accès de votre système local aux points d'extrémité publics via des proxies ou des listes d'autorisation, pour exécuter les commandes calicoctl, vous devez autoriser l'accès TCP pour les commandes Calico.

Avant de commencer, autorisez l'accès pour exécuter des commandes ibmcloud et des commandes oc.

  1. Extrayez l'adresse IP de l'URL du maître que vous avez utilisée pour autoriser les commandes oc.

  2. Obtenez le port pour etcd.

    oc get cm -n kube-system cluster-info -o yaml | grep etcd_host
    
  3. Autorisez l'accès aux règles Calico via l'adresse IP de l'URL du maître et le port etcd.

Ouverture de ports dans les listes d'autorisations des appliances de passerelle

Si vous avez configuré des listes d'autorisations sur le réseau public ou privé dans votre compte d'infrastructure IBM Cloud, tel que Virtual Router Appliance (Vyatta), vous devez ouvrir des plages IP, des ports et des protocoles pour permettre aux nœuds de travailleur de communiquer avec le maître, avec les ressources de l'infrastructure et avec d'autres services IBM Cloud.

Ouverture des ports requis dans une liste d'autorisation publique

Si vous disposez d'une liste d'autorisations sur le réseau public dans votre compte d'infrastructure IBM Cloud, tel que Virtual Router Appliance (Vyatta), vous devez ouvrir des plages IP, des ports et des protocoles dans votre liste d'autorisations pour permettre aux nœuds de travail de communiquer avec le maître, avec les ressources de l'infrastructure et avec d'autres services IBM Cloud.

Avant de commencer, notez l'adresse IP publique de chaque noeud worker du cluster.

ibmcloud oc worker ls --cluster <cluster_name_or_ID>

Autoriser les noeuds worker à communiquer avec le maître de cluster

Pour permettre aux nœuds worker de communiquer avec le maître cluster sur le nœud final de service de cloud public, autorisez le trafic réseau sortant de la source <each_worker_node_publicIP> vers la plage de ports TCP/UDP de destination 30000 - 32767 et le port 443, ainsi que les adresses IP et les groupes de réseau suivants. De plus, si vous prévoyez d'utiliser Ingress ou des routes pour exposer des applications dans votre cluster, autorisez également le trafic réseau entrant via ces ports sur les adresses IP de vos noeuds worker pour que le plan de contrôle Red Hat OpenShift puisse vérifier l'intégrité de vos routeurs.

Ce tableau est en mouvement. Pour les listes d'adresses IP les plus récentes et les mises à jour continues, consultez le dossier d'isolement du réseau public dans le IBM/kube-samples référentiel . Vous pouvez Watch pull requests in the repo pour les mises à jour.

  • TCP/UDP port range 30000-32767, port 443 FROM <each_worker_node_publicIP> TO <public_IPs>
  • Remplacez <public_IPs> par les adresses IP publiques de la région où se trouve votre cluster.
Adresses IP à ouvrir pour le trafic sortant
Région Adresse IP publique
AP Nord (che01, sng01, tok02, tok04, tok05) 119.81.194.90, 119.81.222.210, 128.168.106.194, 128.168.71.117, 128.168.75.194, 128.168.85.154, 135.90.69.66, 135.90.69.82, 161.202.126.210, 161.202.154.10, 161.202.186.226, 161.202.56.10, 161.202.57.34, 165.192.69.69, 165.192.80.146, 165.192.83.202, 165.192.95.90, 169.38.68.178, 169.38.70.10, 169.38.79.170, 169.56.1.162, 169.56.132.234, 169.56.48.114, 169.56.69.242, 169.56.96.42, 104.94.220.124, 104.94.221.124, 104.94.222.132, 104.94.223.132, 104.96.176.124, 104.96.177.124, 104.96.178.126, 104.96.179.126, 104.96.180.123, 104.96.181.123
Asie-Pacifique Sud (syd01, syd04, syd05) 130.198.64.19, 130.198.66.26, 130.198.79.170, 130.198.83.34, 130.198.102.82, 135.90.66.2, 135.90.68.114, 135.90.69.66, 135.90.69.82, 135.90.89.234, 168.1.6.106, 168.1.8.195, 168.1.12.98, 168.1.39.34, 168.1.58.66, 104.94.220.125, 104.94.221.125, 104.94.222.133, 104.94.223.133, 104.96.176.125, 104.96.177.125, 104.96.178.127, 104.96.179.127, 104.96.180.124, 104.96.181.124
Europe Centrale (ams03, mil01, par01, fra02, fra04, fra05) 149.81.103.98, 149.81.104.122, 149.81.113.154, 149.81.123.18, 149.81.142.90, 149.81.180.114, 149.81.180.122, 149.81.68.2, 149.81.78.114, 158.177.102.162, 158.177.107.50, 158.177.112.146, 158.177.138.138, 158.177.151.2, 158.177.156.178, 158.177.198.138, 158.177.79.34, 159.122.141.69, 159.122.150.2, 159.8.79.250, 159.8.86.149, 159.8.95.34, 161.156.115.138, 161.156.120.74, 161.156.12.82, 161.156.183.218, 161.156.187.226, 161.156.65.42, 161.156.65.82, 161.156.74.10, 161.156.79.26, 169.50.146.82, 169.50.169.110, 169.50.184.18, 169.50.56.174, 169.51.197.18, 104.94.220.127, 104.94.221.127, 104.94.222.135, 104.94.223.135, 104.96.176.127, 104.96.177.127, 104.96.178.129, 104.96.179.129, 104.96.180.126, 104.96.181.126
Madrid (mad02, mad04, mad05) 13.120.65.98, 13.120.127.250, 13.121.64.178, 13.121.64.186, 13.122.65.10, 13.122.65.34, 2.18.48.89, 2.18.49.89, 2.18.50.89, 2.18.51.89, 2.18.52.89, 2.18.53.89, 2.18.54.89, 2.18.55.89, 23.40.100.89, 23.7.244.89
Osaka (osa21, osa22,osa23) 163.68.69.114, 163.68.69.122, 163.69.65.114, 163.69.65.122, 163.73.64.250, 163.73.65.194, 104.94.220.131, 104.94.221.131, 104.94.222.139, 104.94.223.139, 104.96.176.131, 104.96.177.131, 104.96.178.133, 104.96.179.133, 104.96.180.130, 104.96.181.130
São Paulo (sao01, sao04, sao05) 163.107.65.194, 163.107.65.202, 163.109.65.154, 163.109.65.242, 169.57.159.130, 169.57.254.50, 104.94.220.129, 104.94.221.129, 104.94.222.137, 104.94.223.137, 104.96.176.129, 104.96.177.129, 104.96.178.131, 104.96.179.131, 104.96.180.128, 104.96.181.128
Toronto (tor01, tor04, tor05) 158.85.77.114, 163.74.65.250, 163.75.64.162, 104.94.220.132, 104.94.221.132, 104.94.222.140, 104.94.223.140, 104.96.176.132, 104.96.177.132, 104.96.178.134, 104.96.179.134, 104.96.180.131, 104.96.181.131
Sud du Royaume-Uni (lon02, lon04, lon05, lon06) 141.125.102.106, 141.125.66.26, 141.125.67.34, 141.125.77.58, 141.125.91.138, 158.175.111.42, 158.175.125.194, 158.175.139.130, 158.175.150.122, 158.175.65.170, 158.175.77.178, 158.175.82.50, 158.176.123.130, 158.176.135.242, 158.176.142.26, 158.176.149.154, 158.176.71.242, 158.176.94.26, 158.176.95.146, 159.122.224.242, 159.122.242.78, 104.94.220.126, 104.94.221.126, 104.94.222.134, 104.94.223.134, 104.96.176.126, 104.96.177.126, 104.96.178.128, 104.96.179.128, 104.96.180.125, 104.96.181.125
Est des États-Unis (mon01, wdc04, wdc06, wdc07) 158.85.97.34, 169.47.162.130, 169.47.174.106, 169.53.167.50, 169.53.171.210, 169.54.126.219, 169.54.80.106, 169.54.94.26, 169.60.100.242, 169.60.101.42, 169.60.111.58, 169.60.73.142, 169.60.92.50, 169.60.92.66, 169.61.109.34, 169.61.110.66, 169.61.74.210, 169.61.83.62, 169.62.10.162, 169.62.9.250, 169.63.106.50, 169.63.111.82, 169.63.149.122, 169.63.158.82, 169.63.160.130, 169.63.66.226, 169.63.75.82, 169.63.88.178, 169.63.88.186, 169.63.94.210, 52.117.72.42, 52.117.88.42, 104.94.220.128, 104.94.221.128, 104.94.222.136, 104.94.223.136, 104.96.176.128, 104.96.177.128, 104.96.178.130, 104.96.179.130, 104.96.180.127, 104.96.181.127
Sud des États-Unis (sjc03, sjc04, dal10, dal12, dal13) 50.22.129.34, 52.116.231.210, 52.116.254.234, 52.116.54.122, 52.117.197.210, 52.117.212.34, 52.117.215.162, 52.117.232.194, 52.117.240.106, 52.117.28.138, 67.228.97.210, 169.45.126.154, 169.45.67.210, 169.45.88.98, 169.46.110.218, 169.46.111.122, 169.46.16.202, 169.46.24.210, 169.46.27.234, 169.46.63.250, 169.46.68.234, 169.46.7.238, 169.46.89.50, 169.47.109.34, 169.47.115.18, 169.47.201.194, 169.47.209.66, 169.47.229.90, 169.47.232.210, 169.47.239.34, 169.47.242.242, 169.47.70.10, 169.47.71.138, 169.48.110.250, 169.48.143.218, 169.48.161.242, 169.48.226.2, 169.48.230.146, 169.48.244.66, 169.57.100.18, 169.57.13.10, 169.57.147.58, 169.57.151.10, 169.57.154.98, 169.59.219.90, 169.59.223.194, 169.59.230.98, 169.60.128.2, 169.60.170.234, 169.61.175.106, 169.61.177.2, 169.61.187.58, 169.61.228.138, 169.61.28.66, 169.61.29.194, 169.61.60.130, 169.62.166.98, 169.62.189.26, 169.62.206.234, 169.62.230.114, 169.62.82.197, 169.62.87.170, 169.62.97.218, 169.63.39.66, 169.63.47.250, 104.94.220.130, 104.94.221.130, 104.94.222.138, 104.94.223.138, 104.96.176.130, 104.96.177.130, 104.96.178.132, 104.96.179.132, 104.96.180.129, 104.96.181.129

Autoriser les noeuds worker à communiquer avec IBM Cloud Container Registry

Autorisez le trafic réseau sortant de vos nœuds de travail à l'adresse IBM Cloud Container Registry. Pour plus d'informations, voir Accès à IBM Cloud Container Registry via un pare-feu.

Autoriser le trafic réseau sortant du noeud worker vers IAM

Autorisez le trafic réseau sortant à partir de votre noeud worker vers IBM Cloud Identity and Access Management (IAM). Votre liste d'autorisations doit être de niveau 7 pour autoriser le nom de domaine IAM. IAM ne possède pas d'adresses IP spécifiques pouvant être autorisées. Si votre liste d'autorisations ne prend pas en charge la couche 7, vous pouvez autoriser tout le trafic réseau HTTPS sur le port 443.

  • TCP port 443 FROM <each_worker_node_publicIP> TO https://iam.bluemix.net
  • TCP port 443 FROM <each_worker_node_publicIP> TO https://iam.cloud.ibm.com

Facultatif : autorisez le trafic réseau sortant depuis les noeuds d'agent vers les services Monitoring et IBM Cloud Logs

  • IBM Cloud Monitoring:

    • TCP port 443, port 6443 FROM <each_worker_node_public_IP> TO <monitoring_public_IP>
    • Remplacez <monitoring_public_IP> par les adresses IP Monitoring.
  • IBM Cloud Logs:

    • TCP port 443, port 80 FROM <each_worker_node_public_IP> TO <logging_public_IP>
    • Remplacez <logging_public_IP> par les adresses IP IBM Cloud Logs.

Facultatif : Autoriser le trafic réseau entrant pour la surveillance du sous-domaine d'entrée

Si vous souhaitez utiliser la surveillance de l'état du domaine Ingress pour surveiller l'état de vos points de terminaison de service, vous devez autoriser l'accès entrant des services de surveillance.

Red Hat OpenShift on IBM Cloud passe d'Akamai à IBM NS1 pour son fournisseur interne de DNS. Pendant cette période de transition, autorisez la liste de toutes les plages d'adresses IP d'Akamai et de IBM NS1 pour assurer une surveillance ininterrompue de la santé.

Par défaut, les demandes de surveillance de l'état de santé sont envoyées par l'intermédiaire de HTTPS au port 443. Vous devez donc autoriser le trafic des plages d'adresses IP ci-dessous ciblé sur le port 443. Si votre moniteur de santé est configuré pour utiliser HTTP à la place, le trafic de la liste d'autorisation doit être ciblé sur le port 80. En outre, si vous utilisez un port TCP personnalisé, veillez à autoriser le trafic entrant sur ce port.

Pour plus d'informations, consultez la documentation IBM NS1 Connect sur la surveillance et la documentation Akamai GTM.

Plages de surveillance du GTM d'Akamai
  • 193.108.155.118/32
  • 8.18.43.199/32
  • 8.18.43.240/32
  • 66.198.8.167/32
  • 66.198.8.168/32
  • 67.220.143.216/31
  • 173.205.7.116/31
  • 209.249.98.36/31
  • 207.126.104.118/31
  • 63.217.211.110/31
  • 63.217.211.116/31
  • 204.2.159.68/31
  • 209.107.208.188/31
  • 124.40.41.200/29
  • 125.252.224.36/31
  • 125.56.219.52/31
  • 192.204.11.4/31
  • 204.1.136.238/31
  • 204.2.160.182/31
  • 204.201.160.246/31
  • 205.185.205.132/31
  • 220.90.198.178/31
  • 60.254.173.30/31
  • 61.111.58.82/31
  • 63.235.21.192/31
  • 64.145.89.236/31
  • 65.124.174.194/31
  • 69.31.121.20/31
  • 69.31.138.100/31
  • 77.67.85.52/31
  • 203.69.138.120/30
  • 66.198.26.68/30
  • 201.33.187.68/30
  • 2.16.0.0/13
  • 23.0.0.0/12
  • 23.192.0.0/11
  • 23.32.0.0/11
  • 23.64.0.0/14
  • 23.72.0.0/13
  • 69.192.0.0/16
  • 72.246.0.0/15
  • 88.221.0.0/16
  • 92.122.0.0/15
  • 95.100.0.0/15
  • 96.16.0.0/15
  • 96.6.0.0/15
  • 104.64.0.0/10
  • 118.214.0.0/16
  • 173.222.0.0/15
  • 184.24.0.0/13
  • 184.50.0.0/15
  • 184.84.0.0/14
IBM NS1 Connect Surveillance des plages IP
  • 163.114.225.0/24
  • 163.114.230.0/24
  • 163.114.231.0/24

Etapes suivantes

Si vous utilisez des services d'équilibrage de charge, vérifiez que tout le trafic utilisant le protocole VRRP est autorisé entre les nœuds worker sur les interfaces publiques et privées. Red Hat OpenShift on IBM Cloud utilise le protocole VRRP pour gérer les adresses IP des équilibreurs de charge publics et privés.

Si vous utilisez Ingress ou des routes pour exposer des applications dans votre cluster, autorisez le trafic réseau entrant des adresses IP source d'Akamai sur le port 80 vers les adresses IP de vos services de routeur afin que le plan de contrôle Red Hat OpenShift puisse vérifier l'état de santé de vos routeurs.

Ouverture des ports requis dans une liste d'autorisations privée

Si vous disposez d'une liste d'autorisations sur le réseau privé dans votre compte d'infrastructure IBM Cloud, tel que Virtual Router Appliance (Vyatta), vous devez ouvrir des plages IP, des ports et des protocoles dans votre liste d'autorisations pour permettre aux nœuds de travail de communiquer avec le maître, entre eux, avec les ressources de l'infrastructure et avec d'autres services IBM Cloud.

Avant de commencer

  1. Autorisez les plages d'adresses IP privées de l'infrastructure IBM Cloud pour pouvoir créer des noeuds worker dans votre cluster.

    1. Autorisez les plages d'adresses IP privées de l'infrastructure IBM Cloud appropriées. Voir Réseau (privé) de back end.
    2. Autorisez les plages d'adresses IP privées de l'infrastructure IBM Cloud pour tous les zones que vous utilisez. Note: Vous devez ajouter les plages d'adresses IP 166.8.0.0/14 et 161.26.0.0/16, les plages d'adresses IP pour les zones dal10 et wdc04. Voir Réseau de service (sur réseau back end/privé).
  2. Notez l'adresse IP privée de chaque noeud worker du cluster.

    ibmcloud oc worker ls --cluster <cluster_name_or_ID>
    

Autoriser les noeuds worker à communiquer avec le maître de cluster

Pour permettre aux nœuds worker de communiquer avec le maître de cluster sur le nœud final de service de cloud privé, laissez le trafic réseau sortant de la source <each_worker_node_privateIP> vers la plage de ports TCP/UDP de destination 30000-32767 et le port 443, ainsi que les adresses IP et les groupes réseau suivants.

Ce tableau est en mouvement. Pour les listes d'adresses IP les plus récentes et les mises à jour ultérieures, consultez le dossier d'isolement du réseau privé dans le IBM/kube-samples référentiel . Vous pouvez Watch pull requests in the repo pour les mises à jour.

  • TCP/UDP port range 30000-32767, port 443 FROM <each_worker_node_privateIP> TO <private_IPs>
  • Remplacez <private_IPs> par les adresses IP privées de la région où se trouve votre cluster.
Adresses IP à ouvrir pour le trafic sortant
Région Adresse IP privée
AP Nord (che01, sng01, tok02, tok04, tok05) 166.9.40.102, 166.9.40.21, 166.9.40.36, 166.9.40.39, 166.9.40.6, 166.9.40.7, 166.9.40.8, 166.9.40.88, 166.9.42.23, 166.9.42.28, 166.9.42.55, 166.9.42.6, 166.9.42.7, 166.9.42.97, 166.9.44.15, 166.9.44.3, 166.9.44.4, 166.9.44.47, 166.9.44.5, 166.9.44.88, 166.9.46.4, 166.9.60.2, 166.9.60.4, 166.9.249.106, 166.9.249.136, 166.9.249.170
Asie-Pacifique Sud (syd01, syd04, syd05) 166.9.52.14, 166.9.52.15, 166.9.52.23, 166.9.52.30, 166.9.52.31, 166.9.54.11, 166.9.54.12, 166.9.54.13, 166.9.54.21, 166.9.54.32, 166.9.54.33, 166.9.56.10, 166.9.56.11, 166.9.56.16, 166.9.56.24, 166.9.56.36, 166.9.244.107, 166.9.244.137, 166.9.244.171
Europe Centrale (ams03, mil01, par01, fra02, fra04, fra05) 166.9.28.107, 166.9.28.17, 166.9.28.19, 166.9.28.20, 166.9.28.203, 166.9.28.22, 166.9.28.23, 166.9.28.235, 166.9.28.24, 166.9.28.240, 166.9.28.43, 166.9.28.64, 166.9.28.84, 166.9.28.87, 166.9.28.91, 166.9.28.94, 166.9.28.95, 166.9.30.100, 166.9.30.11, 166.9.30.116, 166.9.30.12, 166.9.30.13, 166.9.30.22, 166.9.30.41, 166.9.30.54, 166.9.30.56, 166.9.30.9, 166.9.30.92, 166.9.32.101, 166.9.32.185, 166.9.32.20, 166.9.32.26, 166.9.32.27, 166.9.32.44, 166.9.32.54, 166.9.32.56, 166.9.32.84, 166.9.32.88, 166.9.32.9, 166.9.248.77, 166.9.248.106, 166.9.248.137
Madrid (mad02, mad04, mad05) 166.9.94.6, 166.9.95.6, 166.9.96.6, 166.9.94.7, 166.9.95.7, 166.9.96.7
Osaka (osa21, osa22,osa23) 166.9.70.6, 166.9.70.8, 166.9.71.8, 166.9.71.10, 166.9.72.9, 166.9.72.10, 166.9.247.41, 166.9.247.75, 166.9.247.107
Sud du Royaume-Uni (lon02,lon04, lon05, lon06) 166.9.34.17, 166.9.34.41, 166.9.34.45, 166.9.34.5, 166.9.34.50, 166.9.34.6, 166.9.34.77, 166.9.36.10, 166.9.36.11, 166.9.36.12, 166.9.36.13, 166.9.36.23, 166.9.36.30, 166.9.36.53, 166.9.36.65, 166.9.36.95, 166.9.38.18, 166.9.38.28, 166.9.38.46, 166.9.38.54, 166.9.38.6, 166.9.38.7, 166.9.38.75, 166.9.244.12, 166.9.244.48, 166.9.244.75
Est des Etats-Unis (mon01, tor01, wdc04, wdc06, wdc07) 166.9.20.11, 166.9.20.117, 166.9.20.12, 166.9.20.13, 166.9.20.187, 166.9.20.38, 166.9.20.42, 166.9.20.63, 166.9.20.80, 166.9.22.10, 166.9.22.109, 166.9.22.211, 166.9.22.215, 166.9.22.26, 166.9.22.43, 166.9.22.51, 166.9.22.52, 166.9.22.8, 166.9.22.9, 166.9.24.19, 166.9.24.196, 166.9.24.198, 166.9.24.22, 166.9.24.35, 166.9.24.4, 166.9.24.45, 166.9.24.47, 166.9.24.5, 166.9.24.90, 166.9.68.130, 166.9.68.134, 166.9.68.34, 166.9.68.47, 166.9.231.217, 166.9.232.15, 166.9.251.118
Sud des États-Unis (sao01, sjc03, sjc04, dal10, dal12, dal13) 166.9.12.140, 166.9.12.141, 166.9.12.142, 166.9.12.143, 166.9.12.144, 166.9.12.151, 166.9.12.193, 166.9.12.196, 166.9.12.26, 166.9.12.99, 166.9.13.31, 166.9.13.93, 166.9.13.94, 166.9.14.122, 166.9.14.125, 166.9.14.202, 166.9.14.204, 166.9.14.205, 166.9.14.95, 166.9.15.130, 166.9.15.69, 166.9.15.70, 166.9.15.71, 166.9.15.72, 166.9.15.73, 166.9.15.74, 166.9.15.75, 166.9.15.76, 166.9.16.113, 166.9.16.137, 166.9.16.149, 166.9.16.183, 166.9.16.184, 166.9.16.185, 166.9.16.38, 166.9.16.39, 166.9.16.5, 166.9.17.2, 166.9.17.35, 166.9.17.37, 166.9.17.39, 166.9.48.124, 166.9.48.171, 166.9.48.175, 166.9.48.240, 166.9.48.35, 166.9.48.50, 166.9.48.76, 166.9.51.104, 166.9.51.106, 166.9.51.16, 166.9.51.54, 166.9.51.74, 166.9.58.104, 166.9.58.11, 166.9.58.16, 166.9.58.170, 166.9.58.210, 166.9.58.64, 166.9.58.65, 166.9.59.125, 166.9.59.147, 166.9.61.15, 166.9.61.54, 166.9.85.114, 166.9.88.186, 166.9.88.196, 166.9.88.21, 166.9.228.8, 166.9.229.10, 166.9.230.9

Ouverture de ports

Ouvrez les ports suivants dans votre liste autorisée pour que vos noeuds worker fonctionnent correctement. Les ports suivants doivent être ouverts pour toutes les adresses IP de destination.

  • Autorisez les connexions TCP et UDP sortantes à partir des noeuds worker sur les ports 80 et 443 pour permettre les mises à jour et les rechargements des noeuds worker.
  • Autorisez les connexions TCP et UDP sortantes sur le port 2049 pour permettre le montage du stockage de fichiers sous forme de volumes.
  • Autorisez les connexions TCP et UDP sortantes sur le port 3260 pour la communication avec du stockage par blocs.
  • Autorisez les connexions TCP et UDP entrantes sur le port 10250 pour le tableau de bord Red Hat OpenShift et les commandes telles que oc logs et oc exec.
  • Autorisez les connexions TCP et UDP entrantes et sortantes sur les ports 53 et 5353 pour l'accès DNS.

Activer la communication entre les nœuds worker

Autorisez la communication entre travailleurs en autorisant tout le trafic TCP, UDP, VRRP et IPEncap entre les nœuds de travail sur les interfaces privées et autorisez également le protocole VRRP sur l'interface publique. Red Hat OpenShift on IBM Cloud utilise le protocole VRRP pour gérer les adresses IP des équilibreurs de charge et le protocole IPEncap pour permettre le trafic entre les pods à travers les sous-réseaux.

Autoriser les noeuds worker à communiquer avec IBM Cloud Container Registry

Pour permettre aux nœuds worker de communiquer avec IBM Cloud Container Registry, autorisez le trafic réseau sortant des nœuds worker vers les régions IBM Cloud Container Registry.

  • TCP port 443 FROM <each_worker_node_privateIP> TO <registry_ip>
  • Remplacez<registry_ip> par l'adresse IP de registre à laquelle vous souhaitez autoriser le trafic. Le registre global héberge des images publiques fournies par IBM et les registres régionaux stockent vos propres images privées ou publiques.

Le 23 juin 2022, seules les régions br-sao et ca-tor ont été modifiées. Les autres régions ont changé le 5 juillet 2022. Pour plus d'informations, voir Container Registry adresses IP privées modifiées le 5 juillet 2022.

Adresses IP à ouvrir pour le trafic du registre
Région Red Hat OpenShift on IBM Cloud Adresse du registre Registre des adresses IP privées jusqu'au 5 juillet 2022 Registre des adresses IP privées après le 5 juillet 2022
Registre global entre les régions Red Hat OpenShift on IBM Cloud private.icr.io cp.icr.io 166.9.20.31, 166.9.22.22, 166.9.24.16 166.9.251.49, 166.9.251.82, 166.9.251.113
Asie - Pacifique nord private.jp.icr.io 166.9.40.20, 166.9.42.21, 166.9.44.12 166.9.249.104, 166.9.249.157, 166.9.249.168
Asie - Pacifique sud private.au.icr.io 166.9.52.20, 166.9.54.19, 166.9.56.13 166.9.244.106, 166.9.244.136, 166.9.244.170
Europe centrale private.de.icr.io 166.9.28.35, 166.9.30.2, 166.9.32.2 166.9.248.76, 166.9.248.105, 166.9.248.136
Madrid private.es.icr.io N/A 166.9.248.76, 166.9.248.105, 166.9.248.136
Osaka private.jp2.icr.io 166.9.70.4, 166.9.71.5, 166.9.72.6 166.9.247.39, 166.9.247.73, 166.9.247.105
Sao Paolo private.br.icr.io 166.9.82.13, 166.9.83.13, 166.9.84.13 166.9.246.72, 166.9.246.104, 166.9.246.130
Toronto private.ca.icr.io 166.9.76.12, 166.9.77.11, 166.9.78.11 166.9.247.143, 166.9.247.170, 166.9.247.207
Sud du Royaume-Uni private.uk.icr.io 166.9.36.19, 166.9.38.14, 166.9.34.12 166.9.244.9, 166.9.244.45, 166.9.244.73
Est des États-Unis, Sud des États-Unis private.us.icr.io 166.9.12.227, 166.9.15.116, 166.9.16.244 166.9.250.214, 166.9.250.246, 166.9.251.21

Optionnel : Configurer les règles de la liste d'autorisation pour les services IBM Cloud Logs et IBM Cloud Monitoring

Pour envoyer des données de journalisation et des données métriques, configurez des règles d'autorisation pour vos services IBM Cloud Logs et IBM Cloud Monitoring.

Ouverture de ports dans une liste autorisée publique ou privée pour le trafic entrant

Vous pouvez autoriser l'accès entrant aux services NodePort, d'équilibreur de charge et Ingress, et aux routes Red Hat OpenShift.

Service NodePort
Ouvrez le port que vous avez configuré lorsque vous avez déployé le service sur les adresses IP publiques ou privées de tous les nœuds worker afin de permettre le trafic. Pour identifier le port, exécutez la commande oc get svc. Le port est compris dans une plage de 20000 à 32000.
Service d'équilibreur de charge
Ouvrez le port que vous avez configuré lorsque vous avez déployé le service sur l'adresse IP publique ou l'adresse IP privée du service d'équilibreur de charge.
Ingress
Ouvrez le port 80 pour HTTP et le port 443 pour HTTPS vers l'adresse IP publique ou privée de l'équilibreur de charge d'application Ingress.
Route
Ouvrez le port 80 pour HTTP ou le port 443 pour HTTPS vers l'adresse IP publique du routeur.

Autorisation accordée au cluster d'accéder aux ressources via des règles réseau Calico

Au lieu de mettre en place un dispositif de liste d'autorisation de passerelle, vous pouvez choisir d'utiliser les stratégies de réseau Calico pour agir en tant que liste d'autorisation de cluster sur le réseau public ou privé. Pour plus d'informations, reportez-vous aux rubriques suivantes.

Autoriser le trafic de votre cluster dans les listes d'autorisation d'autres services ou dans les listes d'autorisation sur site

Si vous souhaitez accéder à des services exécutés à l'intérieur ou à l'extérieur de IBM Cloud ou sur site et protégés par une liste d'autorisations, vous pouvez ajouter les adresses IP de vos nœuds de travail à cette liste afin d'autoriser le trafic réseau sortant vers votre cluster. Par exemple, vous pouvez vouloir lire les données d'une base de données IBM Cloud protégée par une liste d'autorisation ou spécifier les sous-réseaux de vos nœuds de travail dans une liste d'autorisation sur site afin d'autoriser le trafic réseau depuis votre cluster.

  1. Accédez à votre cluster Red Hat OpenShift.

  2. Obtenez les sous-réseaux ou les adresses IP des noeuds worker.

    • Sous-réseaux de nœuds de travail: Si vous prévoyez de modifier fréquemment le nombre de nœuds de travail dans votre cluster, par exemple si vous activez l'autoscaler du cluster, vous ne voudrez peut-être pas mettre à jour votre liste d'autorisations pour chaque nouveau nœud de travail. Vous pouvez à la place ajouter les sous-réseaux de VLAN utilisés par le cluster. N'oubliez pas qu'un sous-réseau de VLAN peut être partagé par des noeuds worker dans d'autres clusters. Notez que les sous-réseaux publics principaux mis à disposition par Red Hat OpenShift on IBM Cloud pour votre cluster comprennent 14 adresses IP disponibles et peuvent être partagés par d'autres clusters sur le même VLAN. Lorsque vous avez plus de 14 noeuds worker, un autre sous-réseau est commandé. Par conséquent, les sous-réseaux que vous devez autoriser peuvent changer. Pour réduire la fréquence des modifications, créez des pools de noeuds worker avec des modèles comprenant des ressources supérieures en termes d'UC et de mémoire, pour que vous n'ayez pas à ajouter des noeuds worker aussi souvent.

      1. Répertoriez les noeuds worker présents dans votre cluster.

        ibmcloud oc worker ls --cluster <cluster_name_or_ID>
        
      2. Dans la sortie de l'étape précédente, notez tous les ID de réseau uniques (les trois premiers octets) de l'adresse IP publique pour les noeuds worker contenus dans votre cluster. Dans la sortie suivante, les ID de réseau uniques sont 169.xx.178 et 169.xx.210 :

        ID                                                  Public IP        Private IP     Machine Type        State    Status   Zone    Version   
        kube-dal10-crb2f60e9735254ac8b20b9c1e38b649a5-w31   169.xx.178.101   10.xxx.xx.xxx   b3c.4x16.encrypted   normal   Ready    dal10   1.32   
        kube-dal10-crb2f60e9735254ac8b20b9c1e38b649a5-w34   169.xx.178.102   10.xxx.xx.xxx   b3c.4x16.encrypted   normal   Ready    dal10   1.32  
        kube-dal12-crb2f60e9735254ac8b20b9c1e38b649a5-w32   169.xx.210.101   10.xxx.xx.xxx   b3c.4x16.encrypted   normal   Ready    dal12   1.32   
        kube-dal12-crb2f60e9735254ac8b20b9c1e38b649a5-w33   169.xx.210.102   10.xxx.xx.xxx   b3c.4x16.encrypted   normal   Ready    dal12   1.32  
        
      3. Répertoriez les sous-réseaux de VLAN correspondant à chaque ID de réseau unique.

        ibmcloud sl subnet list | grep -e <networkID1> -e <networkID2>
        

        Exemple de sortie

        ID        identifier       type                 network_space   datacenter   vlan_id   IPs   hardware   virtual_servers
        1234567   169.xx.210.xxx   ADDITIONAL_PRIMARY   PUBLIC          dal12        1122334   16    0          5   
        7654321   169.xx.178.xxx   ADDITIONAL_PRIMARY   PUBLIC          dal10        4332211   16    0          6    
        
      4. Récupérez l'adresse du sous-réseau. Dans la sortie, recherchez le nombre d'adresses IP. Puis, augmentez la puissance 2 à un nombre n égal au nombre d'adresses IP. Par exemple, si le nombre d'adresses IP est 16, 2 est augmenté à la puissance 4 (n) pour obtenir 16. Obtenez ensuite le CIDR du sous-réseau en soustrayant la valeur n de 32 bits. Par exemple, lorsque le nombre n est égal à 4, le CIDR correspond à 28 (d'après l'équation 32 - 4 = 28). Combinez le masque identifier avec la valeur de CIDR pour obtenir l'adresse complète du sous-réseau. Dans la sortie précédente, les adresses de sous-réseau sont :

        • 169.xx.210.xxx/28
        • 169.xx.178.xxx/28
    • Adresses IP de noeud worker individuel : Si vous disposez d'un petit nombre de nœuds worker qui exécutent une seule application et n'ont pas besoin de mise à l'échelle, ou si vous souhaitez ajouter un seul nœud worker, listez tous les nœuds worker de votre cluster et notez les adresses IP publiques. Si vos noeuds worker sont connectés uniquement à un réseau privé et que vous voulez vous connecter aux services IBM Cloud en utilisant le noeud final de service cloud privé, notez les adresses IP privées à la place. Seuls ces noeuds worker sont ajoutés. Si vous supprimez les nœuds de travail ou ajoutez des nœuds de travail à la grappe, vous devez mettre à jour votre liste d'autorisations en conséquence.

      ibmcloud oc worker ls --cluster <cluster_name_or_ID>
      
  3. Ajoutez le sous-réseau CIDR ou les adresses IP à la liste d'autorisations de votre service pour le trafic sortant ou à la liste d'autorisations de votre site pour le trafic entrant.

  4. Répétez ces étapes pour chaque cluster vers ou depuis lequel vous souhaitez autoriser le trafic.

Mise à jour des listes d'autorisations IAM pour les zones réseau Kubernetes Service

Par défaut, toutes les adresses IP peuvent être utilisées pour se connecter à la console IBM Cloud et effectuer des actions pour gérer votre cluster, telles que la création, la mise à jour, la suppression ou l'affichage des données d'identification. Dans la console IBM Cloud Identity and Access Management (IAM), vous pouvez créer une liste autorisée en spécifiant les adresses IP qui permettent un accès, ainsi, toutes les autres adresses IP sont restreintes.

Dans votre liste d'autorisations, vous devez également configurer des zones réseau dans le plan de contrôle Red Hat OpenShift on IBM Cloud pour la région où se trouve votre cluster afin que Red Hat OpenShift on IBM Cloud puisse créer ou accéder à des composants tels que les ALB Ingress ou la Red Hat OpenShift console web, qui nécessite toutes les adresses IP du plan de contrôle.

Avant de commencer, la procédure suivante vous demande de modifier la liste des droits d'accès IAM pour l'utilisateur dont les données d'identification sont utilisées pour les droits d'accès à l'infrastructure de la région et du groupe de ressources du cluster. Si vous êtes le propriétaire des données d'identification, vous pouvez modifier vos propres paramètres de liste autorisée IAM. Si vous n'êtes pas le propriétaire des informations d'identification, mais que le rôle d'accès à la plate-forme IAM IBM Cloud vous a été attribué en tant qu' éditeur ou administrateur pour le service de gestion des utilisateurs, vous pouvez mettre à jour les réseaux pour le propriétaire des informations d'identification.

  1. Identifiez les données d'identification d'utilisateur qui sont utilisées pour les droits d'infrastructure de la région et du groupe de ressources du cluster.

    1. Vérifiez la clé d'API pour une région et un groupe de ressources du cluster.

      ibmcloud oc api-key info --cluster <cluster_name_or_ID>
      

      Exemple de sortie

      Getting information about the API key owner for cluster <cluster_name>...
      OK
      Name                Email   
      <user_name>         <name@email.com>
      
    2. Vérifiez si le compte d'infrastructure pour la région et le groupe de ressources est défini manuellement pour utiliser un autre compte d'infrastructure IBM Cloud.

      ibmcloud oc credential get --region <us-south>
      

      Exemple de sortie si des données d'identification sont définies pour utiliser un autre compte. Dans ce cas, les données d'identification d'infrastructure de l'utilisateur sont utilisées pour la région et le groupe de ressources que vous avez ciblés, même si les données d'identification d'un autre utilisateur sont stockées dans la clé d'API que vous avez extraite à l'étape précédente.

      OK
      Infrastructure credentials for user name <1234567_name@email.com> set for resource group <resource_group_name>.
      

      Exemple de sortie si des données d'identification ne sont pas définies pour utiliser un autre compte. Dans ce cas, le propriétaire de la clé d'API que vous avez extraite à l'étape précédente possède les données d'identification d'infrastructure qui sont utilisées pour la région et le groupe de ressources.

      FAILED
      No credentials set for resource group <resource_group_name>.: The user credentials could not be found. (E0051)
      
  2. Connectez-vous à la console IBM Cloud.

  3. Créez des zones de réseau qui incluent les Kubernetes Service IP pour toutes les régions ou uniquement pour les régions dans lesquelles vous avez des clusters.

    1. Dans le compte où se trouve le cluster, dans la barre de menu, cliquez sur Gestion > Restrictions basées sur le contexte.

    2. Cliquez sur Zones de réseau > Créer.

    3. Dans la zone Nom, entrez un nom descriptif pour la zone réseau, par exemple us-south-kubernetes-service-network-zone.

    4. Ne saisissez aucune valeur dans les sections Adresses IP autorisées et VPC autorisés.

    5. Dans la section Référencer un service, sélectionnez Kubernetes Service et cliquez sur +.

    6. Pour Localisations, vous pouvez soit laisser le champ vide afin que toutes les localisations soient utilisées, ce qui s'applique aux clusters des autres régions, soit spécifier une seule région.

    7. Cliquez sur Suivant et passez en revue les sélections.

    8. Cliquez sur Créer.

    9. Répéter l'opération pour les zones supplémentaires.

  4. Ajoutez les noms des zones réseau à votre liste d'autorisations IAM.

    1. Dans la barre de menu, cliquez sur Gérer > Accès (IAM ), puis sélectionnez Paramètres.

    2. Sous Restreindre l'accès à l'adresse IP, sélectionnez Activer et indiquez le nom de la zone réseau indiqué à l'étape précédente.

    3. Cliquez sur Appliquer.

Obtention de vos adresses IP de sous-réseau Kubernetes Service

Suivez les étapes pour obtenir les adresses IP de sous-réseau correctes à ajouter à votre liste autorisée IAM.

Obtention de vos adresses IP de sous-réseau dans la console

  1. Dans la liste des ressources de la console d' IBM Cloud, cliquez sur votre cluster.
  2. Cliquez sur Nœuds de travail.
  3. Notez chaque VLAN public utilisé par les noeuds worker dans votre cluster. Plusieurs noeuds worker peuvent utiliser le même VLAN public.
  4. Dans le menu de la console IBM Cloud Icône de menu, cliquez sur Infrastructure > Infrastructure classique > Gestion IP > VLANs.
  5. Cliquez sur chaque VLAN public pour vérifier s'il est utilisé par les nœuds de travail de votre cluster.
  6. Pour chaque VLAN public utilisé par les noeuds worker dans votre cluster, recherchez la section Sous-réseaux et notez chaque adresse IP incluse dans le tableau. Il s'agit des adresses IP que vous devez inclure dans votre liste autorisée.

Obtention de vos adresses IP de sous-réseau dans l'interface de ligne de commande

  1. Répertoriez les VLAN publics utilisés par vos noeuds worker. La sortie est au format publicVLAN=<vlan_id>.

    oc describe nodes | grep publicVLAN | sort | uniq
    
  2. Pour chaque VLAN public, recherchez les sous-réseaux publics associés. Dans la sortie, notez les adresses IP de sous-réseau dans la colonne identifier.

    ibmcloud sl subnet list | grep <vlan-id>
    

    Exemple de sortie de sous-réseaux associés à un VLAN public avec l'ID 2761690.

    ID        identifier        type                 network_space   datacenter   vlan_id   IPs   hardware   virtual_servers  
    1962263   169.62.46.56      SECONDARY_ON_VLAN    PUBLIC          wdc07        2761690   8     0          0   
    2008207   169.62.39.248     SECONDARY_ON_VLAN    PUBLIC          wdc07        2761690   8     0          0   
    2342562   169.62.2.128      ADDITIONAL_PRIMARY   PUBLIC          wdc07        2761690   16    0          5
    
  3. Répertoriez vos noeuds worker et obtenez leurs adresses IP publiques. Dans la sortie, les adresses IP publiques sont répertoriées dans la colonne External-IP. Notez quelles adresses IP sont contenues dans les sous-réseaux que vous avez répertoriés précédemment et notez ces ID de sous-réseau.

  4. Pour chaque ID de sous-réseau, exécutez la commande pour obtenir les détails du sous-réseau. Dans chaque sortie, notez l'adresse IP dans la colonne identifier. Il s'agit de l'adresse IP que vous devez ajouter à la liste autorisée IAM.

    ibmcloud sl subnet detail <subnet_id>
    

    Exemple de sortie

    Name             Value   
    ID               2342562   
    identifier       169.62.2.128/28   
    subnet type      ADDITIONAL_PRIMARY   
    network space    PUBLIC   
    gateway          169.62.2.129   
    broadcast        169.62.2.143   
    datacenter       wdc07   
    usable ips       13   
    IP address       ID          IP address      
                    186531376   169.62.2.128      
                    186531378   169.62.2.129      
                    186531380   169.62.2.130      
                    186531382   169.62.2.131      
                    186531384   169.62.2.132      
                    186531386   169.62.2.133      
                    186531388   169.62.2.134      
                    186531390   169.62.2.135      
                    186531392   169.62.2.136      
                    186531394   169.62.2.137      
                    186531396   169.62.2.138      
                    186531398   169.62.2.139      
                    186531400   169.62.2.140      
                    186531402   169.62.2.141      
                    186531404   169.62.2.142      
                    186531406   169.62.2.143      
    
    virtual guests   hostname                                                 domain    public_ip      private_ip      
                    kube-c8ofi5pw077drsbovf90-roks47class-default-00000187   iks.ibm   169.62.2.130   10.191.55.109      
                    kube-c8ofi5pw077drsbovf90-roks47class-default-000002a2   iks.ibm   169.62.2.133   10.191.55.108      
                    kube-c8ofi5pw077drsbovf90-roks47class-default-00000372   iks.ibm   169.62.2.135   10.191.55.121      
                    kube-c8ofh6kw0jj8l6jovf8g-iks22classi-default-00000219   iks.ibm   169.62.2.132   10.191.55.105      
                    kube-c8ofh6kw0jj8l6jovf8g-iks22classi-default-0000012f   iks.ibm   169.62.2.134   10.191.55.107