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, oc e calicoctl dal 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.

  1. Aggiungi cloud.ibm.com alla tua lista dei siti autorizzati, consentendo l'accesso alla porta 443.

  2. Verifica la tua connessione accedendo a IBM Cloud tramite questo endpoint API.

    ibmcloud login -a https://cloud.ibm.com/
    
  3. Aggiungi containers.cloud.ibm.com alla tua lista dei siti autorizzati, consentendo l'accesso alla porta 443.

  4. Verifica la tua connessione. Se l'accesso è configurato correttamente, nell'output vengono visualizzate le zone.

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

    Output 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."}]
    
  5. 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.

  6. 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:

  1. 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]
    
  2. 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, esegui ibmcloud oc cluster ls. Nota: devi disporre almeno del ruolo Visualizzatore per il gruppo di risorse.

    ibmcloud target -g <resource_group_name>
    
  3. Richiama il nome del tuo cluster.

    ibmcloud oc cluster ls
    
  4. 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
    ...
    
  5. 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.

  6. 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&reg; 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"
        }
        ```
    
  7. 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.

  1. Recupera l'indirizzo IP dal server master URL che hai utilizzato per abilitare i comandi oc.

  2. Ottieni la porta per etcd.

    oc get cm -n kube-system cluster-info -o yaml | grep etcd_host
    
  3. 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.

Domini Bootstrap per regione
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.
Gli indirizzi IP da aprire per il traffico in uscita
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.net
  • TCP 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/24
  • 163.114.230.0/24
  • 163.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

  1. Consenti gli intervalli di IP privati dell'infrastruttura IBM Cloud in modo da poter creare nodi di lavoro nel tuo cluster.

    1. Consenti gli intervalli di IP privati dell'infrastruttura IBM Cloud appropriati. Vedi Rete di backend (privata).
    2. 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/14 e 161.26.0.0/16, gli intervalli IP per le zone dal10 e wdc04. Vedi Rete del servizio (nella rete di backend/privata).
  2. 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.
Gli indirizzi IP da aprire per il traffico in uscita
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 logs e oc 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.
Gli indirizzi IP da aprire per il traffico del registro
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.

  1. Accedi al tuo cluster Red Hat OpenShift.

  2. 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.

      1. Elenca i nodi di lavoro nel tuo cluster.

        ibmcloud oc worker ls --cluster <cluster_name_or_ID>
        
      2. 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.178 e 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.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  
        
      3. 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    
        
      4. Richiama l'indirizzo di sottorete. Nell'output, trova il numero di IP. Quindi, eleva 2 alla potenza di n uguale al numero di IP. Ad esempio, se il numero di IP è 16, 2 viene elevato alla potenza di 4 (n) uguale a 16. Ora ottieni il CIDR della sottorete sottraendo il valore di n da 32 bit. Ad esempio, se n è uguale a 4, il CIDR è 28 (dall'equazione 32 - 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/28
        • 169.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>
        ```
    
  3. 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.

  4. 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.

  1. Identifica quali credenziali dell'utente vengono utilizzate per le autorizzazioni dell'infrastruttura del gruppo di risorse e della regione del cluster.

    1. 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)
        ```
    
  2. Accedi a Console IBM Cloud.

  3. 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.

    1. Nell'account in cui si trova il cluster, dalla barra dei menu, fare clic su Gestione > Restrizioni basate sul contesto.

    2. Fare clic su Zone di rete > Crea.

    3. Per Nome, inserire un nome descrittivo per la zona di rete, ad esempio us-south-kubernetes-service-network-zone.

    4. Non inserire alcun valore nelle sezioni Indirizzi IP consentiti e VPC consentiti.

    5. Nella sezione Riferimento di un servizio, selezionare Kubernetes Service e fare clic su +.

    6. 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.

    7. Fare clic su Avanti e rivedere le selezioni.

    8. Fai clic su Crea.

    9. Ripetere l'operazione per altre zone.

  4. Aggiungere i nomi delle zone di rete all'elenco di permessi IAM.

    1. Dalla barra dei menu, fai clic su Gestisci > Accesso (IAM) e seleziona Impostazioni.

    2. In Limitare l'accesso all'indirizzo IP, selezionare Abilita e fornire il nome della zona di rete dal passaggio precedente.

    3. 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

  1. Dall'elenco delle risorse della console dell' IBM Cloud, fare clic sul cluster.
  2. Fai clic su Worker nodes.
  3. Nota ogni VLAN pubblica utilizzata dai nodi di lavoro nel cluster. Più nodi di lavoro potrebbero utilizzare la stessa VLAN pubblica.
  4. Dal menu della console IBM Cloud Icona Menu, fare clic su Infrastruttura > Infrastruttura classica > Gestione IP > VLAN.
  5. Fare clic su ogni VLAN pubblica per verificare se è utilizzata dai nodi di lavoro nel proprio cluster.
  6. 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

  1. Elenca le VLAN pubbliche utilizzate dai tuoi nodi di lavoro. L'output è formattato come publicVLAN=<vlan_id>.

    oc describe nodes | grep publicVLAN | sort | uniq
    
  2. 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
    
  3. 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.

  4. 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