FAQ

Il costo delle risorse di calcolo del relay è incluso nei costi del servizio Satellite ?

Le risorse IBM Cloud utilizzate per il relay e Satellite vengono fatturate separatamente.

Ci sono ulteriori addebiti per accedere ai servizi IBM Cloud su Direct Link?

No, non ci sono costi aggiuntivi per accedere ai servizi tramite Direct Link.

Perché ho bisogno di Direct Link?

Per impostazione predefinita, il traffico in uscita dalla tua sede verso i servizi di IBM Cloud transita attraverso la rete Internet pubblica. Quando si utilizza Direct Link, il traffico in uscita dalla propria sede passa attraverso l' Direct Link, anziché utilizzare la rete Internet pubblica.

La mia organizzazione disabilita l'accesso a Internet per progettazione. Posso creare e gestire le ubicazioni e gli host collegati all'ubicazione con Direct Link?

Se hai Direct Link, puoi utilizzarlo per i servizi Satellite. Con Direct Link, puoi creare ubicazioni e collegare host senza accedere a Internet pubblico.

Posso utilizzare gli host RHEL per configurare il mio Direct Link?

Num. Devi avere entrambe le ubicazioni abilitate a RHCOS e devi utilizzare gli host RHCOS nella tua ubicazione per utilizzare Direct Link.

Posso reindirizzare tutto il traffico a IBM Cloud su Direct Link anziché su Internet?

Attualmente, non tutti i servizi supportano Direct Link. La possibilità per tutto il traffico di utilizzare Direct Link dipende dai servizi che utilizzi. Consultare la documentazione relativa a ciascun servizio per verificarne i requisiti di connettività.

A quali servizi IBM Cloud posso accedere tramite Direct Link per evitare di accedervi tramite Internet?

Dopo aver seguito queste istruzioni, Satellite e OpenShift su Satellite funzioneranno attraverso Direct Link. Se vengono implementati servizi aggiuntivi in una sede “ Satellite ”, consultare la documentazione relativa a ciascun servizio per verificarne i requisiti di connettività, poiché alcuni servizi richiedono l’accesso a Internet pubblico.

Se ho due collocazioni che utilizzano Direct Link, posso utilizzarle per Direct Link per eseguire il failover da un'ubicazione all'altra?

Questa funzionalità non è ancora disponibile.

Come posso dimensionare la capacità Direct Link per la mia sede?

Non ci sono ulteriori requisiti di dimensionamento per utilizzare Direct Link. Quindi, puoi ridimensionare la tua posizione come una posizione normale, ovvero in base ai servizi che utilizzerai.

Posso avere una distribuzione con un solo clic di tutto ciò che è necessario per abilitare Direct Link per evitare errori manuali?

Attualmente, non è disponibile una distribuzione con un solo clic per Direct Link.

Caso di utilizzo di destinazione

I clienti che attualmente utilizzano Direct Link tra IBM e in loco o altri cloud pubblici, possono continuare a utilizzarlo per il link Satellite. Ciò consente ai clienti di:

• Accedi ai servizi su IBM Cloud da un'ubicazione Satellite su Direct Link; gli esempi sono backup in IBM Cloud® Object Storage, invio di metriche a IBM Cloud Monitoring, traccia di eventi in IBM Cloud Activity Trackero invio di log a IBM Cloud Log Analysis.
• Accedi ai servizi in esecuzione in un'ubicazione Satellite da IBM Cloud.
• Accedi ai servizi cloud pubblici all'esterno di IBM Cloud.

A questi è possibile accedere utilizzando gli indirizzi endpoint Satellite creati per instradare il traffico su Direct Link invece di Internet.

Ciò impedisce ai dati sensibili dei clienti di passare attraverso l'internet pubblico come la registrazione, i backup o i dati tra i servizi integrati nel panorama del cloud ibrido. Questo aiuta anche a ottimizzare i costi di ingresso / uscita.

Panoramica

Per impostazione predefinita, due componenti di " Satellite Link", ovvero il server tunnel e il connettore, fungono da proxy per il traffico di rete tra IBM Cloud e le risorse presenti nella sede Satellite tramite una connessione sicura TLS. Il presente documento illustra il caso d'uso relativo all'utilizzo di una connessione TLS tramite Direct Link.

Questa configurazione utilizza il servizio cloud privato del server tunnel per instradare il traffico sulla rete privata IBM Cloud (166.9.0.0/8, vedi Rete del servizio. Tuttavia, la comunicazione con l'endpoint del servizio cloud privato del server tunnel deve passare attraverso 166.9.X.X/16 Intervallo di indirizzi IP nella rete privata IBM Cloud, che non è instradabile da IBM Cloud Direct Link.

Per abilitare l'accesso all'intervallo di 166.9.X.X/16, crea un relay nel tuo account IBM Cloud, che invertirà il traffico in entrata del proxy all'endpoint di servizio cloud privato del server tunnel. Per impostazione predefinita, Relay Ingress ha un indirizzo IP nell'intervallo di indirizzi IP 10.X.X.X/8 interno, accessibile tramite una connessione Direct Link.

Il seguente diagramma illustra il flusso di traffico.

1. Il traffico di rete che ha origine presso la tua sede, come una richiesta da un cluster IBM Cloud Satellite a un servizio IBM Cloud, viene instradato tramite il servizio Link su Direct Link all'Ingress privato relay, che ha un indirizzo instradabile di link diretto.
2. Il relay avvia una nuova sessione per inoltrare la richiesta all'endpoint del servizio cloud privato del server tunnel, che termina con un indirizzo IP nell'intervallo 166.9.X.X/16 (indirizzo privato del link).

Obiettivi

È possibile creare sedi abilitate per Red Hat CoreOS senza accedere a Internet pubblico. Tutto il traffico viene gestito da Direct Link e rimane interno.

I passi di alto livello comprendono:

1. Crea un'ubicazione Red Hat CoreOS abilitata Satellite con il tuo account IBM Cloud che termina il tuo Direct Link.
2. Creare un relay, che è un proxy inverso che supporta http / https e websocket sicuro.
3. Esegui il provisioning di host Red Hat CoreOS. Personalizza gli host utilizzando lo script di accensione scaricato come script di collegamento per la posizione creata nel passo 1.

Prerequisiti

• Devi avere un'ubicazione Red Hat CoreOS abilitata Satellite. Se non ne hai già uno, segui le istruzioni in Creating a Red Hat CoreOS enabled Satellite Location per crearlo.
• Direct Link è disponibile tra l'ubicazione Satellite di destinazione e il VPC specifico o i cluster classici IBM Cloud.
• Assicurati che la tua connessione IBM Cloud Direct Link possa accedere all'intervallo di indirizzi IP 10.X.X.X/8. Esamina la progettazione della rete per evitare conflitti IP tra due estremità di Direct Link.
• Installa la CLI e i plug-in IBM Cloud e installa la CLI Kubernetes(kubectl).
• Assicurati che il tuo account IBM Cloud sia abilitato VRF (Virtual Router Function) per utilizzare gli endpoint del servizio.
• Assicurati di disporre delle seguenti politiche di accesso. Per ulteriori informazioni, vedi Verifica delle autorizzazioni utente.
  • Amministratore IBM Cloud Ruolo di accesso della piattaforma IAM per IBM Cloud Kubernetes Service
  • Amministratore IBM Cloud ruolo di accesso della piattaforma IAM per IBM Cloud Container Registry
  • Writer o Manager IBM Cloud Ruolo di accesso al servizio IAM per IBM Cloud Kubernetes Service
  • Amministratore IBM Cloud ruolo di accesso della piattaforma IAM per IBM Cloud Container Registry
  • Amministratore IBM Cloud ruolo di accesso della piattaforma IAM per IBM Cloud Satellite
  • Gestore IBM Cloud Ruolo di accesso al servizio IAM per IBM Cloud Satellite
  • Amministratore IBM Cloud Ruolo di accesso della piattaforma IAM per Object Storage
  • Writer o Manager IBM Cloud ruolo di accesso della piattaforma IAM per IBM Cloud Object Storage
  • Amministratore IBM Cloud Ruolo di accesso della piattaforma IAM per IBM Cloud Certificate Manager
  • Writer o Manager IBM Cloud ruolo di accesso della piattaforma IAM per IBM Cloud Certificate Manager
  • Visualizzatore IBM Cloud Ruolo di accesso della piattaforma IAM per il gruppo di risorse che intendi utilizzare con Satellite
  • Gestore IBM Cloud Ruolo di accesso al servizio IAM per IBM Cloud Schematics
• In particolare, configurare un cluster Kubernetes e implementarvi un proxy inverso NGINX per inoltrare le richieste agli endpoint Direct Link.

Creazione di un percorso Red Hat CoreOS abilitato Satellite

Puoi saltare questo passaggio se disponi già di un'istanza di Red Hat CoreOS abilitata Satellite.

Accedi al tuo account IBM Cloud associato a Direct Link e crea una posizione Satellite abilitata per Red Hat CoreOS. Per ulteriori informazioni, consultare la sezione " Creazione di una posizione ' Satellite ' ".

Creazione di un relay

Il relay è un proxy inverso http / https che supporta connessioni Websocket sicure. Può essere eseguito su VSI, Red Hat OpenShift o IBM Cloud Kubernetes Service in modalità Classic o VPC. I passaggi seguenti illustrano un esempio di implementazione di un proxy invers NGINX e su un cluster Red Hat OpenShift all’interno di una VPC esclusivamente privata (su nodi privati della VPC).

Un requisito essenziale è avere un nome valido che può essere assegnato all'ingresso privato del cluster (Ingress relay) e un certificato valido su IBM Cloud. Su IBM Cloud, i cluster VPC Red Hat OpenShift sui nodi privati vengono forniti con nome host e certificato privato predefiniti. Puoi utilizzarli o portare il tuo nome host e certificato personalizzati. Questo esempio utilizza il nome host privato predefinito e i certificati.

Considerazioni sui cluster VPC per questo scenario:

• Zona: qualsiasi zona VPC con capacità multizona
• Caratteristica del nodo di lavoro: qualsiasi caratteristica dell'infrastruttura VPC
• Versione: 4.x.x
• Pool di nodi di lavoro: almeno 2 nodi di lavoro
• Sottoreti: Includere le sottoreti IP dell'Ingress Load Balancer se gli intervalli predefiniti sono in conflitto con i valori di --pod-subnet e --service-subnet del cluster Red Hat OpenShift su Satellite o con il CIDR della rete in cui sono distribuiti gli host Satellite o Red Hat OpenShift in sede.
• Endpoint del servizio cloud: non specificare l'opzione --disable-public-service-endpoint se si desiderano endpoint sia pubblici che privati.
• Distribuisci il pool di nodi di lavoro predefinito tra le zone per incrementare la disponibilità del tuo cluster classico o VPC.
• Assicurati che esistano almeno 2 nodi di lavoro in ciascuna zona, in modo che gli ALB privati che configuri nei passi successivi siano altamente disponibili e possano ricevere correttamente gli aggiornamenti della versione.

Nel seguente esempio, un cluster VPC solo privato e un controller Ingress privato vengono creati per impostazione predefinita. Tuttavia, è possibile utilizzare anche un cluster Red Hat OpenShift con un endpoint di servizio cloud pubblico abilitato, ma in questo caso il cluster viene creato, per impostazione predefinita, solo con un controller Ingress pubblico. Se vuoi configurare il tuo relay utilizzando un cluster con un endpoint del servizio pubblico, devi prima abilitare il controller Ingress privato e registrarlo con un dominio secondario e un certificato seguendo la procedura in Configurazione di Ingress.

1. Crea un cluster Red Hat OpenShift solo privato su VPC. Per ulteriori informazioni, vedi Creazione di cluster VPC.

   Esistono molti modi per rendere accessibili le app in un cluster di Red Hat OpenShift all’interno di una VPC. In questo esempio, l'app sarà esposta in modalità privata esclusivamente tramite endpoint privati: si tratta del caso d'uso più comune per i clienti di " Direct Link ". I cluster " Red Hat OpenShift " esposti in modalità privata esclusivamente tramite endpoint privati vengono forniti con un nome privato e un certificato predefiniti. In questo esempio verranno utilizzati per rendere accessibili i pod del proxy inverso NGINX. È possibile utilizzare quelli predefiniti o portare il nome host e il certificato personalizzati. Per ulteriori dettagli, vedi Esposizione privata delle applicazioni nei cluster VPC solo con un endpoint del servizio cloud privato.

2. Creare un'istanza di Secret Manager e registrarla sul cluster Red Hat OpenShift creato nel passaggio precedente. Per ulteriori informazioni, vedi Creazione di un'istanza del servizio Secrets Manager.

3. Ottieni i dettagli Ingress da Direct Link.

   ibmcloud oc cluster get --cluster CLUSTER_NAME_OR_ID | grep Ingress
   

   Output di esempio:

   Ingress Subdomain:      mycluster-i000.us-south.containers.appdomain.cloud
   Ingress Secret:         mycluster-i000
   

   In questo scenario, se si esegue il nslookup comando relativo al sottodominio dell'Ingress, questo viene risolto nell'indirizzo IP privato del servizio IBM (10.0.0.0/8). L'aggiunta di rotte per rendere l'indirizzo IP dell'Ingress (10.0.0.0/8) raggiungibile dall'ambiente on-premise del cliente non è trattata in questo documento. È tua responsabilità garantire il routing tra l'ambiente on-premise e il relay Ingress su IBM Cloud.

4. Ottenere il CRN segreto.

   ibmcloud oc ingress secret get -c CLUSTER --name SECRET_NAME --namespace openshift-ingress
   

5. Crea uno spazio dei nomi per il proxy inverso NGINX.

   kubectl create ns dl-reverse-proxy
   

6. Copia il segreto predefinito " TLS " da openshift-ingress nel progetto in cui verrà distribuito NGINX.

   ibmcloud oc ingress secret create --cluster CLUSTER_NAME_OR_ID --cert-crn CRN --name SECRET_NAME --namespace dl-reverse-proxy
   

7. Copia il seguente contenuto del file di risorse Ingress nella tua directory locale. Sostituire VALUE_FROM_INGRESS_SUBDOMAIN e VALUE_FROM_INGRESS_SECRET con i propri valori.

   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     name: dl-ingress-resource
     annotations:
       kubernetes.io/ingress.class: "public-iks-k8s-nginx"
       nginx.ingress.kubernetes.io/proxy-read-timeout: "3600"
       nginx.ingress.kubernetes.io/proxy-send-timeout: "3600"
   spec:
     tls:
     - hosts:
       - satellite-dl.VALUE_FROM_INGRESS_SUBDOMAIN
       secretName: VALUE_FROM_INGRESS_SECRET
     rules:
     - host: satellite-dl.VALUE_FROM_INGRESS_SUBDOMAIN
       http:
         paths:
         - path: /
           pathType: Prefix
           backend:
             service:
               name: nginxsvc
               port:
                 number: 80
   

8. Crea l'Ingress.

   oc apply -f myingressresource.yaml -n <dl-reverse-proxy>
   

9. Ottieni il nome host Ingress interno del server tunnel Direct Link immettendo il seguente comando.

   ibmcloud sat endpoint ls --location LOCATION_ID
   

10. Dall'output, prendi nota dell'endpoint di ubicazione. Sostituire c-01, c-02 o c-03 con d-01-ws, d-02-ws o d-03-ws e rimuovere la porta. Ad esempio, c-01.private.us-south.link.satellite.cloud.ibm.com:40934 diventa d-01-ws.private.us-south.link.satellite.cloud.ibm.com. Questo valore può essere utilizzato come valore per proxy_pass https nel file ConfigMap.

11. Copia il contenuto del file NGINX ConfigMap nella tua directory locale. Questa configurazione applica un proxy inverso WS o un proxy inverso HTTPS all'endpoint Direct Link del server tunnel. Sostituire VALUE_FROM_INGRESS_SUBDOMAIN e VALUE_FOR_PROXY_PASS con i propri valori.

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: confnginx
    data:
      nginx.conf: |
        user  nginx;
        worker_processes  1;
        error_log  /var/log/nginx/error.log warn;
        events {
            worker_connections  4096;
        }
        http {
          include       /etc/nginx/mime.types;
          default_type  application/octet-stream;
          log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                              '$status $body_bytes_sent "$http_referer" '
                              '"$http_user_agent" "$http_x_forwarded_for"';
          access_log  /var/log/nginx/access.log  main;
          sendfile        on;
          keepalive_timeout  65;
          server_names_hash_bucket_size  128;
          server {
            listen 80;
            server_name VALUE_FROM_INGRESS_SUBDOMAIN;
            proxy_connect_timeout 180;
            proxy_send_timeout 180;
            proxy_read_timeout 180;
            location /ws {
              proxy_pass https://VALUE_FOR_PROXY_PASS;
              proxy_ssl_server_name on;
              proxy_http_version 1.1;
              proxy_set_header Upgrade $http_upgrade;
              proxy_set_header Connection "upgrade";
            }
            location / {
              proxy_pass https://VALUE_FOR_PROXY_PASS;
            }
          }
        }
    

12. Copiare il file di distribuzione di NGINX.

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: nginx
      labels:
        app: nginx
    spec:
      selector:
        matchLabels:
          app: nginx
      replicas: 2
      template:
        metadata:
          labels:
            app: nginx
      spec:
        containers:
          - name: nginx
            image: nginx:alpine
            ports:
            - containerPort: 80
            volumeMounts:
              - name: nginx-config
                mountPath: /etc/nginx/nginx.conf
                subPath: nginx.conf
        volumes:
          - name: nginx-config
            configMap:
              name: confnginx
    ---
    apiVersion: v1
    kind: Service
    metadata:
      name: nginxsvc
      labels:
        app: nginx
    spec:
      type: NodePort
      ports:
      - port: 80
        protocol: TCP
        name: http
      - port: 443
        protocol: TCP
        name: https
      - port: 8080
        protocol: TCP
        name: tcp
      selector:
        app: nginx
    

13. Crea l' ConfigMap e dell' NGINX (dl-reverse-proxy).

    oc apply -f confnginx.yaml -n dl-reverse-proxy
    

14. Imposta il profilo corretto di scc e crea il file NGINX (dl-reverse-proxy).

    oc adm policy add-scc-to-user anyuid system:serviceaccount:dl-reverse-proxy:default
    oc apply -f nginx-app.yaml -n dl-reverse-proxy
    

15. Verifica che l' NGINX e sia in esecuzione visualizzando l'elenco dei pod.

    oc get pods
    

    NAME                     READY   STATUS    RESTARTS   AGE
    nginx-757fbc9f85-gv2p6   1/1     Running   0          53s
    nginx-757fbc9f85-xvmrj   1/1     Running   0          53s
    

16. Controllare i log.

    oc logs -f nginx-757fbc9f85-gv2p6
    

    /docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
    /docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/
    /docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh
    10-listen-on-ipv6-by-default.sh: info: Getting the checksum of /etc/nginx/conf.d/default.conf
    10-listen-on-ipv6-by-default.sh: info: Enabled listen on IPv6 in /etc/nginx/conf.d/default.conf
    /docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh
    /docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh
    /docker-entrypoint.sh: Configuration complete; ready for start up
    

17. Verificare l'ingresso.

    oc get ingress
    

    NAME                  CLASS    HOSTS                                                                                                       ADDRESS                                                                                                     PORTS     AGE
    dl-ingress-resource   <none>   mysatellite-dl.myname-cluster10-22bfd3cd491bdeb5a0f661fb1e2b0c44-0000.us-south.containers.appdomain.cloud   router-default.myname-cluster10-22bfd3cd491bdeb5a0f661fb1e2b0c44-0000.us-south.containers.appdomain.cloud   80, 443   19m
    

18. Collegarsi all' URL del reverse proxy.

    curl -k https://mysatellite-dl.myname-cluster10-22bfd3cd491bdeb5a0f661fb1e2b0c44-0000.us-south.containers.appdomain.cloud
    

    {"status":"UP"}
    

Reindirizza il traffico all'utilizzo del Direct Link Percorso

Ora che il relay è pronto a proxyare il traffico in entrata verso l'Ingress interno del tunnel server, si può impostare l'host di localizzazione o il Connector per reindirizzare il suo traffico attraverso il relay. In questo modo si garantisce che tutto il traffico rimanga sul percorso Direct Link della rete privata e che nessun traffico utilizzi la rete Internet pubblica.

Reindirizzare il traffico dell'agente Connector o dell'host di localizzazione seguendo le istruzioni pertinenti riportate di seguito.