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
etcalicoctl
à 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.
-
Autoriser l'accès à
cloud.ibm.com
sur le port 443 dans votre liste d'autorisations. -
Vérifiez votre connexion en vous connectant à IBM Cloud via ce noeud final d'API.
ibmcloud login -a https://cloud.ibm.com/
-
Autoriser l'accès à
containers.cloud.ibm.com
sur le port 443 dans votre liste d'autorisations. -
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."}]
-
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.
-
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 :
-
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]
-
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 commandeibmcloud oc cluster ls
. Remarque : vous devez disposer au moins du rôle Afficheur pour le groupe de ressources.ibmcloud target -g <resource_group_name>
-
Obtenez le nom de votre cluster.
ibmcloud oc cluster ls
-
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 ...
-
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.
-
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" }
-
-
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
.
-
Extrayez l'adresse IP de l'URL du maître que vous avez utilisée pour autoriser les commandes
oc
. -
Obtenez le port pour etcd.
oc get cm -n kube-system cluster-info -o yaml | grep etcd_host
-
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.
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
-
Autorisez les plages d'adresses IP privées de l'infrastructure IBM Cloud pour pouvoir créer des noeuds worker dans votre cluster.
- Autorisez les plages d'adresses IP privées de l'infrastructure IBM Cloud appropriées. Voir Réseau (privé) de back end.
- 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
et161.26.0.0/16
, les plages d'adresses IP pour les zonesdal10
etwdc04
. Voir Réseau de service (sur réseau back end/privé).
-
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.
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
etoc 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.
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.
-
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.
-
Répertoriez les noeuds worker présents dans votre cluster.
ibmcloud oc worker ls --cluster <cluster_name_or_ID>
-
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
et169.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
-
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
-
Récupérez l'adresse du sous-réseau. Dans la sortie, recherchez le nombre d'adresses IP. Puis, augmentez la puissance
2
à un nombren
égal au nombre d'adresses IP. Par exemple, si le nombre d'adresses IP est16
,2
est augmenté à la puissance4
(n
) pour obtenir16
. Obtenez ensuite le CIDR du sous-réseau en soustrayant la valeurn
de32
bits. Par exemple, lorsque le nombren
est égal à4
, le CIDR correspond à28
(d'après l'équation32 - 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>
-
-
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.
-
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.
-
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.
-
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>
-
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)
-
-
Connectez-vous à la console IBM Cloud.
-
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.
-
Dans le compte où se trouve le cluster, dans la barre de menu, cliquez sur Gestion > Restrictions basées sur le contexte.
-
Cliquez sur Zones de réseau > Créer.
-
Dans la zone Nom, entrez un nom descriptif pour la zone réseau, par exemple
us-south-kubernetes-service-network-zone
. -
Ne saisissez aucune valeur dans les sections Adresses IP autorisées et VPC autorisés.
-
Dans la section Référencer un service, sélectionnez Kubernetes Service et cliquez sur +.
-
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.
-
Cliquez sur Suivant et passez en revue les sélections.
-
Cliquez sur Créer.
-
Répéter l'opération pour les zones supplémentaires.
-
-
Ajoutez les noms des zones réseau à votre liste d'autorisations IAM.
-
Dans la barre de menu, cliquez sur Gérer > Accès (IAM ), puis sélectionnez Paramètres.
-
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.
-
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
- Dans la liste des ressources de la console d' IBM Cloud, cliquez sur votre cluster.
- Cliquez sur Nœuds de travail.
- Notez chaque VLAN public utilisé par les noeuds worker dans votre cluster. Plusieurs noeuds worker peuvent utiliser le même VLAN public.
- Dans le menu de la console IBM Cloud
, cliquez sur Infrastructure > Infrastructure classique > Gestion IP > VLANs.
- Cliquez sur chaque VLAN public pour vérifier s'il est utilisé par les nœuds de travail de votre cluster.
- 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
-
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
-
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
-
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.
-
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