Aggiunta delle porte e degli indirizzi IP necessari all'elenco delle eccezioni
Cluster classici
Le informazioni contenute in questa lista di autorizzazioni si riferiscono specificatamente ai cluster classici. Per i cluster VPC, consultare la sezione " Apertura delle porte e degli indirizzi IP richiesti nell'elenco degli indirizzi consentiti per i cluster VPC ".
Esamina queste situazioni in cui potrebbe essere necessario aprire porte e indirizzi IP specifici nelle tue liste di autorizzazione per i tuoi cluster Red Hat® OpenShift® on IBM Cloud®.
- Elenchi di autorizzazione aziendali: se le politiche di rete aziendali impediscono l'accesso dal proprio sistema locale a endpoint pubblici tramite proxy o elenchi di autorizzazione, è necessario autorizzare l'accesso
per eseguire i comandi
ibmcloud,ibmcloud oc,ibmcloud cr,ocecalicoctldal proprio sistema locale. - Elenchi di autorizzazione dei dispositivi gateway: se nel proprio account dell’infrastruttura IBM Cloud sono stati configurati elenchi di autorizzazione sulla rete pubblica o privata, come ad esempio un VRA, è necessario aprire intervalli IP, porte e protocolli per consentire ai nodi di lavoro di comunicare con il master, con le risorse dell’infrastruttura e con altri servizi IBM Cloud. Puoi anche aprire le porte per consentire il traffico in entrata ai servizi che espongono le applicazioni nel tuo cluster.
- Calico Criteri di rete: se si utilizzano i criteri di rete di Calico come lista di autorizzazioni per limitare tutto il traffico in uscita dai nodi di lavoro, è necessario consentire a tali nodi di accedere alle risorse necessarie al funzionamento del cluster.
- Altri servizi o elenchi di indirizzi consentiti di rete: per consentire al cluster di accedere a servizi in esecuzione all’interno o all’esterno di IBM Cloud o in reti locali e protetti da un elenco di indirizzi consentiti, è necessario aggiungere gli indirizzi IP dei nodi di lavoro a tale elenco.
Apertura delle porte in un elenco di permessi aziendale
Se le politiche di rete aziendali impediscono l'accesso dal proprio sistema locale agli endpoint pubblici tramite proxy o elenchi di autorizzazioni, è necessario consentire l'accesso per eseguire i comandi ibmcloud, ibmcloud oc e ibmcloud cr, i comandi oc e i comandi calicoctl dal proprio sistema locale.
Esecuzione dei comandi ibmcloud, ibmcloud oc e ibmcloud cr da una lista di autorizzazioni
Se le politiche di rete aziendali impediscono l'accesso dal proprio sistema locale agli endpoint pubblici tramite proxy o liste di autorizzazione, per eseguire i comandi ibmcloud, ibmcloud oc e ibmcloud cr è necessario consentire l'accesso TCP per IBM Cloud, Red Hat OpenShift on IBM Cloud e IBM Cloud Container Registry.
-
Aggiungi
cloud.ibm.comalla tua lista dei siti autorizzati, consentendo l'accesso alla porta 443. -
Verifica la tua connessione accedendo a IBM Cloud tramite questo endpoint API.
ibmcloud login -a https://cloud.ibm.com/ -
Aggiungi
containers.cloud.ibm.comalla tua lista dei siti autorizzati, consentendo l'accesso alla porta 443. -
Verifica la tua connessione. Se l'accesso è configurato correttamente, nell'output vengono visualizzate le zone.
curl https://containers.cloud.ibm.com/v1/zonesOutput di esempio
[{"id":"mon01","metro":""},{"id":"tor01","metro":""},{"id":"wdc04","metro":"Washington D.C."},{"id":"wdc06","metro":"Washington D.C."},{"id":"wdc07","metro":"Washington D.C."}] -
Consenti l'accesso alle regioniIBM Cloud Container Registry che intendi utilizzare sulla porta 443 nel tuo allowlist. Il registro globale archivia le immagini pubbliche fornite da IBM e i registri regionali archiviano le tue proprie immagini pubbliche e private.
-
Verifica la tua connessione elencando i tuoi spazi dei nomi del registro del contenitore.
Esecuzione di comandi oc da dietro un allowlist
Se le politiche di rete aziendali impediscono l'accesso dal proprio sistema locale agli endpoint pubblici tramite proxy o liste di autorizzazione, per eseguire i comandi oc è necessario consentire l'accesso TCP per il cluster.
Quando viene creato un cluster, la porta presente negli URL degli endpoint di servizio viene assegnata in modo casuale all'interno dell'intervallo compreso tra 30000 e 32767. È possibile scegliere se aprire l'intervallo di porte 30000-32767 per qualsiasi cluster che possa essere creato oppure consentire l'accesso a un cluster specifico già esistente.
Prima di cominciare, consenti l'accesso per eseguire i comandi ibmcloud oc.
Per concedere l'accesso per un cluster specifico:
-
Accedi alla CLI IBM Cloud. Immetti le tue credenziali IBM Cloud quando richiesto. Se hai un account federato, includi l'opzione
--sso.ibmcloud login [--sso] -
Se il cluster si trova in un gruppo di risorse diverso da quello di
default, specifica tale gruppo di risorse. Per visualizzare il gruppo di risorse a cui appartiene ciascun cluster, eseguiibmcloud oc cluster ls. Nota: devi disporre almeno del ruolo Visualizzatore per il gruppo di risorse.ibmcloud target -g <resource_group_name> -
Richiama il nome del tuo cluster.
ibmcloud oc cluster ls -
Richiama gli URL degli endpoint del servizio per il tuo cluster.
- Se viene popolato solo il campo Public Service Endpoint URL, ottieni questo URL. I tuoi utenti del cluster autorizzati possono accedere al master tramite questo endpoint sulla rete pubblica.
- Se viene popolato solo il campo Private Service Endpoint URL, ottieni questo URL. I tuoi utenti del cluster autorizzati possono accedere al master tramite questo endpoint sulla rete privata.
- Se vengono popolati entrambi i campi Public Service Endpoint URL e Private Service Endpoint URL, ottieni i due URL. I tuoi utenti del cluster autorizzati possono accedere al master tramite l'endpoint pubblico sulla rete pubblica o l'endpoint privato sulla rete privata.
ibmcloud oc cluster get --cluster <cluster_name_or_ID>Output di esempio
... 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 ... -
Consenti l'accesso agli URL e alle porte degli endpoint del servizio che hai ottenuto nel passo precedente. Se la tua lista di autorizzazioni è basata sugli indirizzi IP, puoi verificare quali indirizzi IP sono abilitati quando consenti l'accesso agli URL degli endpoint del servizio consultando questa tabella.
-
Verifica la tua connessione.
- Se l'endpoint del servizio cloud pubblico è abilitato:
curl --insecure <public_service_endpoint_URL>/version ``` Comando di esempio: ```sh {: pre} curl --insecure https://c3.<region>.containers.cloud.ibm.com:31142/version ``` Output di esempio ```sh {: screen} { "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" } ``` - Se l'endpoint del servizio cloud privato è abilitato, è necessario trovarsi all'interno della rete privata IBM Cloud oppure connettersi alla rete privata tramite una connessione VPN per verificare la connessione al master. **Nota**: devi [esporre l'endpoint master tramite un programma di bilanciamento del carico privato](/docs/openshift?topic=openshift-access_cluster#access_private_se) in modo che gli utenti possano accedere al master tramite una VPN o una connessione IBM Cloud® Direct Link. ```sh {: pre} curl --insecure <private_service_endpoint_URL>/version ``` Comando di esempio: ```sh {: pre} curl --insecure https://c3-private.<region>.containers.cloud.ibm.com:31142/version ``` Output di esempio ```sh {: screen} { "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" } ``` -
Facoltativo: ripeti questa procedura per ogni cluster che devi esporre.
Esecuzione di comandi calicoctl da dietro un allowlist
Se le politiche di rete aziendali impediscono l'accesso dal proprio sistema locale agli endpoint pubblici tramite proxy o liste di autorizzazione, per eseguire i comandi calicoctl è necessario consentire l'accesso TCP per i comandi
Calico.
Prima di iniziare, autorizza l'accesso ai siti ibmcloud comandi e oc comandi.
-
Recupera l'indirizzo IP dal server master URL che hai utilizzato per abilitare i comandi
oc. -
Ottieni la porta per etcd.
oc get cm -n kube-system cluster-info -o yaml | grep etcd_host -
Consenti l'accesso alle politiche Calico tramite l'indirizzo IP dell'URL master e la porta etcd.
Apertura delle porte nelle liste di autorizzazione dei dispositivi gateway
Se nell'account dell'infrastruttura IBM Cloud sono state configurate liste di autorizzazione sulla rete pubblica o su quella privata, ad esempio un sistema di gestione delle reti ( Virtual Router Appliance, Vyatta), è necessario aprire intervalli IP, porte e protocolli per consentire ai nodi di lavoro di comunicare con il master, con le risorse dell'infrastruttura e con altri servizi IBM Cloud.
Apertura delle porte richieste in una lista di autorizzazioni pubblica
Se nel proprio account dell'infrastruttura IBM Cloud è presente una lista di autorizzazioni sulla rete pubblica, ad esempio un Virtual Router Appliance (Vyatta), è necessario aggiungere alla lista di autorizzazioni gli intervalli IP, le porte e i protocolli necessari per consentire ai nodi di lavoro di comunicare con il master, con le risorse dell'infrastruttura e con altri servizi IBM Cloud.
Azione richiesta entro il 31 luglio 2026: gli endpoint origin.<region>.containers.cloud.ibm.com saranno dismessi. Se disponi di cluster classici con l'endpoint del servizio pubblico abilitato e limiti l'accesso
in uscita tramite liste di autorizzazione o firewall, oppure se disponi di script personalizzati che richiamano direttamente questi endpoint di origine, devi aggiornare le tue configurazioni entro il 31 luglio 2026 per evitare interruzioni
del servizio. Per ulteriori informazioni, consultare la sezione " Migrazione dagli endpoint di origine agli endpoint supportati ".
Migrazione dagli endpoint di origine agli endpoint supportati
Cluster classici
È necessario intervenire se una delle seguenti condizioni si applica al proprio caso:
- Si dispone di uno o più cluster classici con l'endpoint di servizio pubblico abilitato e si limita l'accesso in uscita tramite liste di autorizzazione o firewall.
- Si dispone di script o strumenti personalizzati che richiamano direttamente gli endpoint di
origin.<region>.containers.cloud.ibm.com.
Se nessuna delle due condizioni è soddisfatta, non è necessario intervenire.
Per mantenere la connettività dei nodi di lavoro a Red Hat OpenShift on IBM Cloud, completare i seguenti passaggi entro il 31 luglio 2026.
-
Se si utilizzano regole di firewall basate su indirizzi IP: assicurarsi che gli indirizzi IP indicati nella sezione “Consenti ai nodi di lavoro di comunicare con il master del cluster ” siano presenti nelle regole del firewall.
-
Se utilizzi regole firewall basate sui domini: aggiungi i seguenti domini di avvio alla tua lista dei domini consentiti.
| Regione | Dominio Bootstrap |
|---|---|
UE Centrale (fra02, fra04, fra05) |
bootstrap.eu-de.containers.cloud.ibm.com |
Regno Unito Sud (lon02, lon04, lon05, lon06) |
bootstrap.eu-gb.containers.cloud.ibm.com |
Madrid (mad02, mad04, mad05) |
bootstrap.eu-es.containers.cloud.ibm.com |
Osaka (osa21, osa22, osa23) |
bootstrap.jp-osa.containers.cloud.ibm.com |
San Paolo (sao01, sao04, sao05) |
bootstrap.br-sao.containers.cloud.ibm.com |
Asia Pacifico Sud (syd01, syd04, syd05) |
bootstrap.au-syd.containers.cloud.ibm.com |
AP North (tok02, tok04, tok05) |
bootstrap.jp-tok.containers.cloud.ibm.com |
Toronto (tor01, tor04, tor05) |
bootstrap.ca-tor.containers.cloud.ibm.com |
Sud degli Stati Uniti (dal10, dal12, dal13) |
bootstrap.us-south.containers.cloud.ibm.com |
Costa orientale degli Stati Uniti (wdc04, wdc06, wdc07) |
bootstrap.us-east.containers.cloud.ibm.com |
- Se disponi di script personalizzati che richiamano direttamente gli endpoint di origine: passa agli endpoint API supportati. Per ulteriori informazioni, consulta la sezione " Informazioni sull'API".
Prima di iniziare, prendere nota dell'indirizzo IP pubblico di ciascun nodo di lavoro del cluster.
ibmcloud oc worker ls --cluster <cluster_name_or_ID>
Consenti ai nodi di lavoro di comunicare con il master cluster
Per consentire ai nodi di lavoro di comunicare con il master del cluster tramite l'endpoint del servizio cloud pubblico, autorizzare il traffico di rete in uscita dalla sorgente <each_worker_node_publicIP> verso la destinazione TCP / UDP nell'intervallo di porte 30000-32767 e sulla porta 443, nonché per i seguenti indirizzi IP e gruppi di rete. Inoltre, se si prevede di utilizzare Ingress o le rotte per esporre le applicazioni nel cluster, consentire il traffico di rete in entrata attraverso queste porte anche agli indirizzi IP dei nodi worker, in modo che il piano di controllo Red Hat OpenShift possa verificare la salute dei router.
Questa tabella è in movimento. Per gli ultimi elenchi di IP e gli aggiornamenti continui, vedi la cartella di isolamento della rete pubblica nel IBM/kube-samples repository
. Puoi guardare le richieste di pull nel repository per aggiornamenti.
TCP/UDP port range 30000-32767, port 443 FROM <each_worker_node_publicIP> TO <public_IPs>- Sostituisci <public_IPs> con gli indirizzi IP pubblici della regione in cui si trova il tuo cluster.
| Regione | Indirizzo IP pubblico |
|---|---|
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 |
Asia Pacifico 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 |
UE Centrale (ams03, 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.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, 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 |
San Paolo (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 |
Regno Unito Sud (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 |
Stati Uniti Est (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 |
Stati Uniti Sud (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 |
Consenti ai nodi di lavoro di comunicare con IBM Cloud Container Registry
Consenti il traffico di rete in uscita dai nodi di lavoro verso IBM Cloud Container Registry. Per ulteriori informazioni, vedi Accesso a IBM Cloud Container Registry tramite un firewall.
Consenti traffico di rete in uscita dal nodo di lavoro a IAM
Consenti il traffico di rete in uscita dal tuo nodo di lavoro a IBM Cloud IAM (Identity and Access Management). Per consentire l'accesso al nome di dominio IAM, l'elenco delle eccezioni deve essere impostato su Livello 7. IAM non ha specifici indirizzi IP che puoi consentire. Se la tua lista di autorizzazioni non supporta il Layer 7, puoi autorizzare tutto il traffico di rete HTTPS sulla porta 443.
TCP port 443 FROM <each_worker_node_publicIP> TO https://iam.bluemix.netTCP port 443 FROM <each_worker_node_publicIP> TO https://iam.cloud.ibm.com
Opzionale: consentire il traffico di rete in uscita dai nodi di lavoro verso i servizi Monitoring e IBM Cloud Logs
-
IBM Cloud Monitoring:
TCP port 443, port 6443 FROM <each_worker_node_public_IP> TO <monitoring_public_IP>- Sostituire < IP_pubblico_monitoraggio> con Indirizzi IP Monitoring.
-
IBM Cloud Logs:
TCP port 443, port 80 FROM <each_worker_node_public_IP> TO <logging_public_IP>- Sostituisci <logging_public_IP> con gli indirizzi IP IBM Cloud Logs.
Opzionale: Consentire il traffico di rete in entrata per il monitoraggio del sottodominio di ingresso
Se si desidera utilizzare il monitoraggio dello stato di salute del dominio Ingress per monitorare lo stato degli endpoint del servizio, è necessario consentire l'accesso in entrata dai servizi di monitoraggio.
Per impostazione predefinita, le richieste di monitoraggio dello stato di salute vengono inviate attraverso HTTPS alla porta 443, pertanto è necessario consentire l'elenco del traffico proveniente dai seguenti intervalli IP e indirizzato alla porta 443. Se il monitor sanitario è configurato per utilizzare HTTP, il traffico dell'elenco di permessi deve essere indirizzato alla porta 80. Inoltre, se si utilizza una porta personalizzata TCP, assicurarsi di consentire il traffico in entrata su tale porta.
Per ulteriori informazioni, consultare la documentazione di IBM NS1 Connect sul monitoraggio.
IBM NS1 Connect Monitoraggio degli intervalli IP
163.114.225.0/24163.114.230.0/24163.114.231.0/24
Passi successivi
Se utilizzi i servizi del programma di bilanciamento del carico, assicurati che tutto il traffico che utilizza il protocollo VRRP sia consentito tra i nodi di lavoro sulle interfacce pubbliche e private. Red Hat OpenShift on IBM Cloud utilizza il protocollo VRRP per gestire gli indirizzi IP per i programmi di bilanciamento del carico pubblici e privati.
Se si utilizzano Ingress o rotte per esporre le applicazioni nel cluster, consentire il traffico di rete in entrata dagli indirizzi IP di origine di IBM NS1 sulla porta 80 agli indirizzi IP dei servizi del router, in modo che il piano di controllo di Red Hat OpenShift possa verificare la salute dei router.
Apertura delle porte necessarie in una lista di autorizzazioni privata
Se nell'account dell'infrastruttura IBM Cloud è presente una lista di autorizzazioni sulla rete privata, ad esempio un " Virtual Router Appliance " (Vyatta), è necessario aggiungere alla lista di autorizzazioni gli intervalli IP, le porte e i protocolli necessari per consentire ai nodi di lavoro di comunicare con il master, tra loro, con le risorse dell'infrastruttura e con altri servizi IBM Cloud.
Prima di iniziare
-
Consenti gli intervalli di IP privati dell'infrastruttura IBM Cloud in modo da poter creare nodi di lavoro nel tuo cluster.
- Consenti gli intervalli di IP privati dell'infrastruttura IBM Cloud appropriati. Vedi Rete di backend (privata).
- Assegnare all’infrastruttura di “ IBM Cloud ” intervalli di indirizzi IP privati per tutte le zone in uso. Nota: è necessario aggiungere gli intervalli
IP
166.8.0.0/14e161.26.0.0/16, gli intervalli IP per le zonedal10ewdc04. Vedi Rete del servizio (nella rete di backend/privata).
-
Prendi nota dell'indirizzo IP privato per ciascun nodo di lavoro nel cluster.
ibmcloud oc worker ls --cluster <cluster_name_or_ID>
Consenti ai nodi di lavoro di comunicare con il master cluster
Per consentire ai nodi di lavoro di comunicare con il master del cluster tramite l'endpoint del servizio cloud privato, autorizzare il traffico di rete in uscita dalla sorgente <each_worker_node_privateIP> verso la destinazione TCP / UDP nell'intervallo di porte 30000-32767 e sulla porta 443, nonché per i seguenti indirizzi IP e gruppi di rete.
Questa tabella è in movimento. Per gli ultimi elenchi di IP e gli aggiornamenti continui, vedi la cartella di isolamento della rete privata nel IBM/kube-samples repository
. Puoi guardare le richieste di pull nel repository per aggiornamenti.
TCP/UDP port range 30000-32767, port 443 FROM <each_worker_node_privateIP> TO <private_IPs>- Sostituisci <private_IPs> con gli indirizzi IP privati della regione in cui si trova il tuo cluster.
| Regione | Indirizzo IP privato |
|---|---|
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 |
Asia Pacifico 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 |
UE Centrale (ams03, 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 |
Regno Unito Sud (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 |
Stati Uniti Est (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 |
Stati Uniti Sud (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 |
Porte aperte
Apri le seguenti porte nella tua allowlist perché i tuoi nodi di lavoro funzionino correttamente. Le seguenti porte devono essere aperte per tutti gli IP di destinazione.
- Consenti connessioni TCP e UDP in uscita dai nodi di lavoro alle porte 80 e 443 per consentire gli aggiornamenti e i ricaricamenti dei nodi di lavoro.
- Consenti connessioni TCP e UDP in uscita alla porta 2049 per consentire il montaggio dell'archiviazione file come volumi.
- Consenti connessioni TCP e UDP in uscita alla porta 3260 per le comunicazioni all'archiviazione blocchi.
- Consenti le connessioni in entrata TCP e UDP alla porta 10250 per la dashboard Red Hat OpenShift e per comandi quali
oc logseoc exec. - Consenti le connessioni in entrata e in uscita verso TCP e UDP sulle porte 53 e 5353 per l'accesso al DNS.
Abilita comunicazione tra i nodi di lavoro
Abilitare la comunicazione da lavoratore a lavoratore consentendo tutto il traffico TCP, UDP, VRRP e IPEncap tra i nodi lavoratori sulle interfacce private e consentire anche VRRP sull'interfaccia pubblica. Red Hat OpenShift on IBM Cloud utilizza il protocollo VRRP per gestire gli indirizzi IP per i bilanciatori di carico e il protocollo IPEncap per consentire il traffico da pod a pod attraverso le sottoreti.
Consenti ai nodi di lavoro di comunicare con IBM Cloud Container Registry
Per consentire ai nodi di lavoro di comunicare con IBM Cloud Container Registry, autorizza il traffico di rete in uscita dai nodi di lavoro verso le regioni di IBM Cloud Container Registry.
TCP port 443 FROM <each_worker_node_privateIP> TO <registry_ip>- Sostituire
<registry_ip>con l'indirizzo IP del registro a cui si desidera consentire il traffico. Il registro globale archivia le immagini pubbliche fornite da IBM e i registri regionali archiviano le tue proprie immagini pubbliche e private.
| Regione Red Hat OpenShift on IBM Cloud | Indirizzo del registro | Indirizzi IP privati del Registro di sistema fino al 5 luglio 2022 | Indirizzi IP privati del registro dopo il 5 luglio 2022 |
|---|---|---|---|
| Registro globale tra le regioni 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 |
| Asia Pacifico 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 |
| Asia Pacifico 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 |
| Europa 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/D | 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 |
| San 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 |
| Regno Unito Sud | 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 |
| Stati Uniti Est, Stati Uniti Sud | 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 |
Opzionale: Impostare le regole allowlist per i servizi IBM Cloud Logs e IBM Cloud Monitoring
Per inviare i dati di log e le metriche, configura le regole di whitelist per i servizi IBM Cloud Logs e IBM Cloud Monitoring.
Apertura di porte in un elenco di consentiti pubblico o privato per il traffico in entrata
È possibile consentire l'accesso in entrata a un bilanciatore di carico di NodePort,, ai servizi Ingress e alle rotte di Red Hat OpenShift.
- Servizio NodePort
- Apri la porta che hai configurato al momento della distribuzione del servizio sugli indirizzi IP pubblici o privati di tutti i nodi di lavoro, in modo da consentire il traffico verso di essi. Per trovare la porta, esegui
oc get svc. La porta è compresa nell'intervallo 20000-32000. - Servizio del programma di bilanciamento del carico
- Apri la porta che hai configurato quando hai distribuito il servizio all'indirizzo IP pubblico o privato del servizio del programma di bilanciamento del carico.
- Ingress
- Aprire la porta 80 per HTTP e la porta 443 per HTTPS sull'indirizzo IP pubblico o privato del bilanciatore di carico dell'applicazione Ingress.
- Instradamento
- Apri la porta 80 per HTTP e la porta 443 per HTTPS verso l'indirizzo IP pubblico del router.
Concessione al cluster dell'accesso alle risorse tramite le politiche di rete Calico
Anziché configurare un dispositivo di allowlist per il gateway, è possibile scegliere di utilizzare le politiche di rete di Calico, che fungono da allowlist del cluster sulla rete pubblica o privata. Per ulteriori informazioni, consulta i seguenti argomenti.
Consentire il traffico proveniente dal proprio cluster nelle liste di autorizzazione di altri servizi o nelle liste di autorizzazione on-premises
Se desideri accedere a servizi in esecuzione all'interno o all'esterno di IBM Cloud o in locale e protetti da una lista di autorizzazioni, puoi aggiungere gli indirizzi IP dei tuoi nodi di lavoro a tale lista per consentire il traffico di rete in uscita verso il tuo cluster. Ad esempio, potresti voler leggere i dati da un database IBM Cloud protetto da una lista di autorizzazioni, oppure specificare le sottoreti dei tuoi nodi di lavoro in una lista di autorizzazioni locale per consentire il traffico di rete proveniente dal tuo cluster.
-
Ottieni le sottoreti o gli indirizzi IP del nodo di lavoro.
-
Sottoreti dei nodi di lavoro: se prevedi di modificare frequentemente il numero di nodi di lavoro nel tuo cluster, ad esempio se abiliti la funzione di autoscaling del cluster, potresti preferire non aggiornare l'elenco dei nodi autorizzati per ogni nuovo nodo di lavoro. Puoi invece aggiungere le sottoreti VLAN utilizzate dal cluster. Tieni presente che la sottorete VLAN potrebbe essere condivisa da nodi di lavoro in altri cluster. Si noti che le sottoreti pubbliche primarie che Red Hat OpenShift on IBM Cloud assegna al proprio cluster dispongono di 14 indirizzi IP disponibili e possono essere condivise con altri cluster sulla stessa VLAN. Se hai più di 14 nodi di lavoro, viene ordinata un'altra sottorete, per cui le sottoreti che devi consentire possono cambiare. Per ridurre la frequenza delle modifiche, crea pool di lavoro con profili di nodi di lavoro con risorse CPU e memoria più elevate in modo da non dover aggiungere nodi tanto spesso.
-
Elenca i nodi di lavoro nel tuo cluster.
ibmcloud oc worker ls --cluster <cluster_name_or_ID> -
Dall'output del passo precedente, prendi nota di tutti gli ID di rete univoci (primi tre ottetti) dell'IP pubblico per i nodi di lavoro nel tuo cluster. Nel seguente output, gli ID di rete univoci sono
169.xx.178e169.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.35 kube-dal10-crb2f60e9735254ac8b20b9c1e38b649a5-w34 169.xx.178.102 10.xxx.xx.xxx b3c.4x16.encrypted normal Ready dal10 1.35 kube-dal12-crb2f60e9735254ac8b20b9c1e38b649a5-w32 169.xx.210.101 10.xxx.xx.xxx b3c.4x16.encrypted normal Ready dal12 1.35 kube-dal12-crb2f60e9735254ac8b20b9c1e38b649a5-w33 169.xx.210.102 10.xxx.xx.xxx b3c.4x16.encrypted normal Ready dal12 1.35 -
Elenca le sottoreti VLAN per ogni ID di rete univoco.
ibmcloud sl subnet list | grep -e <networkID1> -e <networkID2>Output di esempio
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 -
Richiama l'indirizzo di sottorete. Nell'output, trova il numero di IP. Quindi, eleva
2alla potenza dinuguale al numero di IP. Ad esempio, se il numero di IP è16,2viene elevato alla potenza di4(n) uguale a16. Ora ottieni il CIDR della sottorete sottraendo il valore dinda32bit. Ad esempio, senè uguale a4, il CIDR è28(dall'equazione32 - 4 = 28). Combina la maschera dell'identificativo con il valore CIDR per ottenere l'indirizzo completo della sottorete. Nell'output precedente, gli indirizzi di sottorete sono:169.xx.210.xxx/28169.xx.178.xxx/28
-
-
Indirizzi IP dei singoli nodi di lavoro: se disponi di un numero limitato di nodi di lavoro che eseguono una sola applicazione e non richiedono scalabilità, oppure se desideri aggiungere un solo nodo di lavoro, elenca tutti i nodi di lavoro presenti nel tuo cluster e prendi nota degli indirizzi IP pubblici. Se i nodi di lavoro sono collegati esclusivamente a una rete privata e si desidera connettersi ai servizi IBM Cloud utilizzando l'endpoint del servizio cloud privato, prendere nota invece degli indirizzi IP privati. Vengono aggiunti solo questi nodi di lavoro. Se si eliminano o si aggiungono nodi di lavoro al cluster, è necessario aggiornare di conseguenza l'elenco dei nodi autorizzati.
ibmcloud oc worker ls --cluster <cluster_name_or_ID> ``` -
-
Aggiungi gli indirizzi IP o il CIDR della sottorete all'elenco dei permessi del tuo servizio per il traffico in uscita oppure all'elenco dei permessi locale per il traffico in entrata.
-
Ripeti questi passi per ciascun cluster per il quale vuoi consentire il traffico in entrata o in uscita.
Aggiornamento degli elenchi di permessi IAM per Kubernetes Service zone di rete
Per impostazione predefinita, tutti gli indirizzi IP possono essere utilizzati per accedere alla IBM Cloud console ed eseguire azioni di gestione del cluster, quali la creazione, l'aggiornamento, l'eliminazione o la visualizzazione delle credenziali. Nella console IBM Cloud IAM (Identity and Access Management), puoi creare una allowlist specificando quali indirizzi IP hanno accesso, limitando tutti gli altri indirizzi IP.
Se si sceglie di impostare un elenco di permessi IAM, è necessario includere una zona di rete che comprenda il sito Kubernetes Service. Altrimenti i cluster esistenti non funzioneranno correttamente. Questo perché il piano di controllo di Kubernetes Service deve essere in grado di contattare IAM per distribuire e gestire i servizi IBM necessari per il cluster. Seguire attentamente queste istruzioni prima di impostare l'elenco dei permessi di IBM.
Nell'allowlist è necessario configurare anche le zone di rete nel piano di controllo Red Hat OpenShift on IBM Cloud per la regione in cui si trova il cluster, in modo che Red Hat OpenShift on IBM Cloud possa creare o accedere a componenti come gli ALB Ingress o la console web Red Hat OpenShift, che richiede tutti gli indirizzi IP del piano di controllo.
Prima di iniziare, i passaggi seguenti richiedono di modificare l'elenco delle autorizzazioni IAM per l'utente le cui credenziali vengono utilizzate per le autorizzazioni relative all'infrastruttura della regione e del gruppo di risorse del cluster. Se sei il proprietario delle credenziali, puoi modificare le tue impostazioni della allowlist IAM. Se non sei il titolare delle credenziali, ma ti è stato assegnato il ruolo di accesso alla piattaforma IAM di IBM Cloud "Editor" o "Amministratore" per il servizio di gestione degli utenti, puoi aggiornare le reti per conto del titolare delle credenziali.
-
Identifica quali credenziali dell'utente vengono utilizzate per le autorizzazioni dell'infrastruttura del gruppo di risorse e della regione del cluster.
- Controlla la chiave API per una regione e un gruppo di risorse del cluster.
ibmcloud oc api-key info --cluster <cluster_name_or_ID> ``` Output di esempio ```sh {: screen} Getting information about the API key owner for cluster <cluster_name>... OK Name Email <user_name> <name@email.com> ``` 2. Controlla se l'account dell'infrastruttura per la regione e il gruppo di risorse è impostato manualmente per utilizzare un account dell'infrastruttura IBM Cloud differente. ```sh {: pre} ibmcloud oc credential get --region <us-south> ``` **Output di esempio se le credenziali sono impostate per l'utilizzo di un account differente**. In questo caso, le credenziali dell'infrastruttura dell'utente vengono utilizzate per la regione e il gruppo di risorse che hai indicato come destinazione, anche se nella chiave API che hai richiamato nel passo precedente sono memorizzate le credenziali di un utente differente. ```sh {: screen} OK Infrastructure credentials for user name <1234567_name@email.com> set for resource group <resource_group_name>. ``` **Output di esempio se le credenziali non sono impostate per l'utilizzo di un account differente**. In questo caso, il proprietario della chiave API che hai richiamato nel passo precedente ha le credenziali dell'infrastruttura che sono utilizzate per la regione e il gruppo di risorse. ```sh {: screen} FAILED No credentials set for resource group <resource_group_name>.: The user credentials could not be found. (E0051) ``` -
Accedi a Console IBM Cloud.
-
Creare zone di rete che includano gli IP Kubernetes Service per tutte le regioni o solo per le regioni in cui sono presenti i cluster.
-
Nell'account in cui si trova il cluster, dalla barra dei menu, fare clic su Gestione > Restrizioni basate sul contesto.
-
Fare clic su Zone di rete > Crea.
-
Per Nome, inserire un nome descrittivo per la zona di rete, ad esempio
us-south-kubernetes-service-network-zone. -
Non inserire alcun valore nelle sezioni Indirizzi IP consentiti e VPC consentiti.
-
Nella sezione Riferimento di un servizio, selezionare Kubernetes Service e fare clic su +.
-
Per Locazioni, è possibile lasciare il campo vuoto in modo che vengano utilizzate tutte le località, il che si applica ai cluster di altre regioni, oppure specificare una singola regione.
-
Fare clic su Avanti e rivedere le selezioni.
-
Fai clic su Crea.
-
Ripetere l'operazione per altre zone.
-
-
Aggiungere i nomi delle zone di rete all'elenco di permessi IAM.
-
Dalla barra dei menu, fai clic su Gestisci > Accesso (IAM) e seleziona Impostazioni.
-
In Limitare l'accesso all'indirizzo IP, selezionare Abilita e fornire il nome della zona di rete dal passaggio precedente.
-
Fai clic su Apply.
-
Ottenimento dei tuoi indirizzi IP della sottorete Kubernetes Service
Attieniti alla procedura per ottenere gli indirizzi IP della sottorete corretti da aggiungere al tuo elenco di consentiti IAM.
Ottenimento degli indirizzi IP della sottorete nella console
- Dall'elenco delle risorse della console dell' IBM Cloud, fare clic sul cluster.
- Fai clic su Worker nodes.
- Nota ogni VLAN pubblica utilizzata dai nodi di lavoro nel cluster. Più nodi di lavoro potrebbero utilizzare la stessa VLAN pubblica.
- Dal menu della console IBM Cloud
, fare clic su Infrastruttura > Infrastruttura classica > Gestione IP > VLAN.
- Fare clic su ogni VLAN pubblica per verificare se è utilizzata dai nodi di lavoro nel proprio cluster.
- Per ogni VLAN pubblica utilizzata dai nodi di lavoro nel tuo cluster, trova la sezione Sottoreti e prendi nota di ogni indirizzo IP incluso nella tabella. Questi sono gli indirizzi IP che devi includere nella tua allowlist.
Ottenimento degli indirizzi IP della sottorete nella CLI
-
Elenca le VLAN pubbliche utilizzate dai tuoi nodi di lavoro. L'output è formattato come
publicVLAN=<vlan_id>.oc describe nodes | grep publicVLAN | sort | uniq -
Per ogni VLAN pubblica, trova le sottoreti pubbliche associate. Nell'output, prendi nota degli indirizzi IP della sottorete nella colonna identifier.
ibmcloud sl subnet list | grep <vlan-id>Output di esempio delle sottoreti associate alla VLAN pubblica con 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 -
Elencare i nodi di lavoro e ottenere i relativi IP pubblici. Nell'output, gli IP pubblici vengono elencati nella colonna IP esterno. Nota quali di questi indirizzi IP sono contenuti nelle sottoreti che hai elencato in precedenza e prendi nota di questi ID sottorete.
-
Per ogni ID sottorete, eseguire il comando per ottenere i dettagli della sottorete. In ogni output, annotare l'indirizzo IP nella colonna identificativo. Questo è l'indirizzo IP che devi aggiungere all'elenco dei consentiti IAM.
ibmcloud sl subnet detail <subnet_id>Output di esempio
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