使用 IBM Cloud 使用 Direct Link 連接位置

使用 IBM Cloud 使用 Direct Link 連接位置

使用 IBM Cloud 使用 Direct Link 連接位置

請使用安全的 IBM Cloud 連線,以建立 Satellite Link 通訊,串聯您在 Satellite 位置上執行的服務與 IBM Cloud 之間的連線。 瞭解如何為混合雲環境設定直接連結。

以下步驟已停用。 有關最新操作步驟,請參閱 《透過私有網路使用 Satellite Connector 連線至 IBM Cloud 》以及《 Direct Link 2.0 》。

支援的位置類型
支援Red Hat CoreOS (RHCOS) 的位置和連接器
支援的主機作業系統
Red HatCoreOS (RHCOS) 和 RHEL

請使用安全的 IBM Cloud® Direct Link 連線,以建立 Satellite 連結,串聯您在 IBM Cloud Satellite® 位置中運行的服務與 IBM Cloud® 之間的通訊。

在本指導教學中,您將設定 Satellite 鏈結以使用 Direct Link 連線。 「位置」的「鏈結通道」用戶端會透過 Direct Link 連線,將資料流量傳送至您在 IBM Cloud 帳戶中建立的「中繼站」。 此「中繼站」會將資料流量 Proxy 至 IBM Cloud 專用網路中的「鏈結」通道伺服器 IP 位址。

常見問題 (FAQ)

中繼運算資源的成本是否包含在 Satellite 服務成本中?
用於中繼的 IBM Cloud 資源和 Satellite 會個別計費。
是否有其他費用可透過 Direct Link存取 IBM Cloud 服務?
否,透過 Direct Link存取服務沒有額外費用。
為何我需要 Direct Link?
預設情況下,從您的位置發往 IBM Cloud 服務的出站流量會透過公共網際網路傳輸。 當您使用「Direct Link」時,來自您所在位置的外發流量將透過「Direct Link」傳輸,而非使用公共網際網路。
我的組織會依設計停用網際網路存取。 我可以使用 Direct Link來建立及維護連接至「位置」的「位置」及主機嗎?
如果您有 Direct Link,則可以將它用於 Satellite 服務。 使用 Direct Link,您可以建立「位置」並連接主機,而無需存取公用網際網路。
我可以使用 RHEL 主機來設定 Direct Link嗎?
次數 您必須同時具有已啟用 RHCOS 的位置,並且必須在您的位置中使用 RHCOS 主機才能使用 Direct Link。
我可以透過 Direct Link 而非網際網路將所有資料流量重新導向至 IBM Cloud 嗎?
目前,並非所有服務都支援 Direct Link。 所有流量是否都能使用 Direct Link,取決於您使用的服務。 請查閱各服務的文件,以確認其連線需求。
我可以透過 Direct Link 存取哪些 IBM Cloud 服務,以避免透過網際網路存取它們?
遵循這些指示後,Satellite 和 Satellite 上的 OpenShift 將可跨 Direct Link 工作。 若要在 Satellite 位置部署其他服務,請查閱各服務的文件以確認其連線需求,因為某些服務需要公開網際網路存取權限。
如果我有兩個使用 Direct Link的「位置」,我可以將它們用於 Direct Link 從一個「位置」失效接手至另一個「位置」嗎?
此功能目前尚未提供。
如何調整「位置」的 Direct Link 容量大小?
使用 Direct Link沒有其他調整大小需求。 因此,您可以像一般「位置」一樣,根據您將使用的服務來調整「位置」的大小。
我可以按一下部署啟用 Direct Link 以避免手動錯誤所需的一切嗎?
目前無法使用 Direct Link 的一鍵式部署。

目標使用案例

目前在 IBM 與內部部署或其他公用雲端之間使用 Direct Link 的客戶可以繼續將它用於 Satellite 鏈結。 這可讓客戶:

  • 從 Satellite 位置透過 Direct Link存取 IBM Cloud 上的服務; 例如 IBM Cloud® Object Storage中的備份、將度量傳送至 IBM Cloud Monitoring、在 IBM Cloud Activity Tracker中追蹤事件,或將日誌傳送至 IBM Cloud Log Analysis。
  • 從 IBM Cloud存取在 Satellite 位置中執行的服務。
  • 存取 IBM Cloud外部的公用雲端服務。

可以使用建立的 Satellite 端點位址來存取這些端點,以透過 Direct Link 而非網際網路來遞送資料流量。

這可防止客戶透過公用網際網路傳送機密資料,例如混合式雲端環境中整合服務之間的記載、備份或資料。 這也有助於優化入口/出口費用。

概觀

預設情況下,兩個「Satellite Link」元件(隧道伺服器與連接器)會透過安全的 TLS 連線,在 IBM Cloud 與您位於 Satellite 的位置中的資源之間代理網路流量。 本文件說明透過 Direct Link 使用 TLS 連線的使用情境。

此設定會使用通道伺服器的專用雲端服務端點,透過 IBM Cloud 專用網路 (166.9.0.0/8,請參閱 服務網路) 來遞送資料流量。 不過,與通道伺服器專用雲端服務端點的通訊必須通過 166.9.X.X/16 IBM Cloud 專用網路上的 IP 位址範圍,無法從 IBM Cloud Direct Link遞送。

若要啟用 166.9.X.X/16 範圍的存取權,請在 IBM Cloud 帳戶中建立「中繼站」,這會將 Proxy 送入的資料流量反向到通道伺服器的專用雲端服務端點。 依預設,「中繼入口」在內部 10.X.X.X/8 IP 位址範圍內具有 IP 位址,可透過 Direct Link 連線來存取。

下圖示範資料流量的流程。

Satellite使用Direct Link連接和反向代理的連結設定
使用DirectLink連接的Satellite Link設定

  1. 源自「位置」的網路資料流量 (例如從 IBM Cloud Satellite 叢集到 IBM Cloud 服務的要求) 會透過「透過 Direct Link 的鏈結服務」遞送至具有「直接鏈結可遞送位址」的「中繼專用入口」。
  2. 「中繼站」會起始新的階段作業,將要求轉遞至通道伺服器的專用雲端服務端點,這會終止至 166.9.X.X/16 範圍內的 IP 位址 (鏈結專用位址)。

目標

您無需連線至公共網際網路,即可建立啟用 Red Hat CoreOS 功能的據點。 所有流量均由 Direct Link 處理,並保持在內部。

高階步驟包括:

  1. 使用終止 Direct Link的 IBM Cloud 帳戶建立 Red Hat CoreOS 已啟用 Satellite 位置。
  2. 建立中繼,這是支援 http/https 及安全 websocket 的反向 Proxy。
  3. 佈建 Red Hat CoreOS 主機。 使用已下載為步驟 1 中所建立「位置」之連接 Script 的 ignition Script 來自訂主機。

必要條件

  • 您必須已啟用 Red Hat CoreOS Satellite 位置。 如果您還沒有,請遵循 建立 Red Hat CoreOS 已啟用 Satellite 位置 中的指示來建立它。
  • Direct Link 可在目標 Satellite 位置與 IBM Cloud 特定 VPC 或標準叢集之間使用。
  • 確保 IBM Cloud Direct Link 連線可以存取 10.X.X.X/8 IP 位址範圍。 請檢閱網路設計,以避免 Direct Link兩端之間的 IP 衝突。
  • 安裝 IBM Cloud CLI 和外掛程式,並 安裝 Kubernetes CLI(kubectl)。
  • 確保 IBM Cloud 帳戶已啟用「虛擬路由器功能 (VRF)」以使用服務端點。
  • 請確保您已設定以下存取政策。 如需相關資訊,請參閱 檢查使用者許可權。
    • 管理者 IBM Cloud IBM Cloud Kubernetes Service 的 IAM 平台存取角色
    • 管理者 IBM Cloud IBM Cloud Container Registry 的 IAM 平台存取角色
    • 撰寫者 或 管理員 IBM Cloud IBM Cloud Kubernetes Service 的 IAM 服務存取角色
    • 管理者 IBM Cloud IBM Cloud Container Registry 的 IAM 平台存取角色
    • 管理者 IBM Cloud IBM Cloud Satellite 的 IAM 平台存取角色
    • 管理員 IBM Cloud IBM Cloud Satellite 的 IAM 服務存取角色
    • 管理者 IBM Cloud Object Storage 的 IAM 平台存取角色
    • 撰寫者 或 管理員 IBM Cloud IBM Cloud Object Storage 的 IAM 平台存取角色
    • 管理者 IBM Cloud IBM Cloud Certificate Manager 的 IAM 平台存取角色
    • 撰寫者 或 管理員 IBM Cloud IBM Cloud Certificate Manager
    • 檢視者 IBM Cloud 您計劃與 Satellite 搭配使用之資源群組的 IAM 平台存取角色
    • 管理員 IBM Cloud IBM Cloud Schematics 的 IAM 服務存取角色
  • 具體而言,請配置一個 Kubernetes 叢集,並在其內部署 NGINX 反向代理伺服器,以將流量轉發至 Direct Link 端點。

建立 Red Hat CoreOS 已啟用 Satellite 位置

若您已啟用 Red Hat CoreOS 並設定 Satellite 位置,則可跳過此步驟。

請登入您擁有 Direct Link 的 IBM Cloud 帳戶,並建立一個啟用 Red Hat CoreOS 的 Satellite 位置。 如需更多資訊,請參閱「建立 Satellite 位置」。

建立中繼

中繼是支援安全 Websocket 連線的 http/https 反向 Proxy。 它可以在 VSI、Red Hat OpenShift 或 IBM Cloud Kubernetes Service 上以 Classic 或 VPC 模式運行。 以下步驟示範如何在僅限私有網路的 VPC Red Hat OpenShift 叢集(位於 VPC 私有節點上)部署 NGINX 反向代理。

一個基本需求是具有可指派給叢集專用入口 (中繼入口) 的有效名稱,以及 IBM Cloud上的有效憑證。 在 IBM Cloud上,專用節點上的 VPC Red Hat OpenShift 叢集隨附預設專用主機名稱和憑證。 您可以使用它們,或使用自訂主機名稱及憑證。 此範例使用預設專用主機名稱及憑證。

此實務範例的 VPC 叢集考量:

  • 區域: 任何具有多區域功能的 VPC 區域
  • 工作者節點規格: 任何 VPC 基礎架構規格
  • 版本: 4.x.x
  • 工作者節點儲存區: 至少 2 個工作者節點
  • 子網路:如果預設範圍與 Satellite 上 Red Hat OpenShift 叢集的 --pod-subnet 和 --service-subnet 值或 Satellite 或 Red Hat OpenShift 主機部署在內部的網路 CIDR 衝突,請納入 Ingress Load Balancer IP 子網路。
  • 雲端服務端點: 如果您同時想要公用和專用端點,請不要指定 --disable-public-service-endpoint 選項。
  • 將預設工作者節點儲存區分散到各區域,以增加標準或 VPC 叢集的可用性。
  • 確保每個區域中至少存在 2 個工作者節點,以便您在後續步驟中配置的專用 ALB 具有高可用性,並且可以適當地接收版本更新。

在下列範例中,依預設會建立僅限專用 VPC 叢集及專用 Ingress 控制器。 不過,您也可以使用已啟用公有雲服務端點的 Red Hat OpenShift 叢集;但在這種情況下,您的叢集預設僅會搭配一個公有 Ingress 控制器建立。 如果您要使用具有公用服務端點的叢集來設定中繼,則必須先啟用專用 Ingress 控制器,並遵循 設定 Ingress 中的步驟,向子網域及憑證登錄它。

  1. 在 VPC 上建立僅限專用 Red Hat OpenShift 叢集。 如需相關資訊,請參閱 建立 VPC 叢集。

    在 VPC 中的 Red Hat OpenShift 叢集中,有許多方法可以將應用程式對外公開。 在此範例中,該應用程式將僅透過私有端點進行私有公開,這是 Direct Link 客戶最常見的使用情境。僅透過私有端點進行私有公開的 Red Hat OpenShift 叢集,會預設附帶私有名稱和憑證。 在此範例中,它們將用於公開 NGINX 的反向代理 Pod。 您可以使用預設主機名稱或使用自訂主機名稱及憑證。 如需詳細資料,請參閱 僅在具有專用雲端服務端點的 VPC 叢集裡以專用方式公開應用程式。

  2. 建立 Secret Manager 實例並將其註冊到在上一個步驟中建立的Red Hat OpenShift叢集。 如需相關資訊,請參閱 建立 Secrets Manager 服務實例。

  3. 從 Direct Link取得 Ingress 詳細資料。

    ibmcloud oc cluster get --cluster CLUSTER_NAME_OR_ID | grep Ingress
    

    輸出範例:

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

    在此情境下,若您在 nslookup 命令來存取 Ingress 子網域,系統會將其解析為 IBM 服務的私有 IP 位址(10.0.0.0/8 )。關於如何新增路由,以便讓客戶的本地端環境能連通 Ingress IP 位址(10.0.0.0/8 ),本文未涵蓋相關說明。 您負責協調本地端與 IBM Cloud 上的 Ingress 中繼站之間的路由。

  4. 獲取秘密 CRN。

    ibmcloud oc ingress secret get -c CLUSTER --name SECRET_NAME --namespace openshift-ingress
    
  5. 為「NGINX」反向代理建立一個命名空間。

    kubectl create ns dl-reverse-proxy
    
  6. 請將預設的 TLS 密鑰從 openshift-ingress 複製到即將部署 NGINX 的專案中。

    ibmcloud oc ingress secret create --cluster CLUSTER_NAME_OR_ID --cert-crn CRN --name SECRET_NAME --namespace dl-reverse-proxy
    
  7. 將下列 Ingress 資源檔案內容複製到本端目錄。 將 VALUE_FROM_INGRESS_SUBDOMAIN 和 VALUE_FROM_INGRESS_SECRET 取代為您自己的值。

    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. 建立 Ingress。

    oc apply -f myingressresource.yaml -n <dl-reverse-proxy>
    
  9. 執行下列指令,以取得通道伺服器 Direct Link 內部 Ingress 主機名稱。

    ibmcloud sat endpoint ls --location LOCATION_ID
    
  10. 從輸出中,記下「位置」端點。 將 c-01、c-02 或 c-03 取代為 d-01-ws、d-02-ws 或 d-03-ws,並移除埠。 例如,c-01.private.us-south.link.satellite.cloud.ibm.com:40934 會變成 d-01-ws.private.us-south.link.satellite.cloud.ibm.com。 此值可以用作 ConfigMap 檔案中 proxy_pass https 的值。

  11. 將 NGINX ConfigMap 檔案的內容複製到您的本機目錄中。 此設定會將 ws-reverse proxy 或 https reverse proxy 套用至隧道伺服器的 Direct Link 端點。 將 VALUE_FROM_INGRESS_SUBDOMAIN 和 VALUE_FOR_PROXY_PASS 取代為您自己的值。

    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. 複製 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. 建立「NGINX」(dl-reverse-proxy )的「ConfigMap」。

    oc apply -f confnginx.yaml -n dl-reverse-proxy
    
  14. 設定正確的「scc」設定檔,並建立「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. 請透過列出 Pod 來再次確認 NGINX 是否正在運行。

    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. 請檢查日誌。

    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. 檢查 Ingress。

    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. 連接到反向代理 URL。

    curl -k https://mysatellite-dl.myname-cluster10-22bfd3cd491bdeb5a0f661fb1e2b0c44-0000.us-south.containers.appdomain.cloud
    
    {"status":"UP"}
    

重定向流量以使用Direct Link路徑

現在中繼已準備好將傳入流量代理到隧道伺服器內部入口,您可以設定位置主機或連接器以透過中繼重新導向其流量。 這可確保所有流量都保留在您的專用網路中的Direct Link路徑上,並且沒有流量使用公共互聯網。

請依照下面的適用說明重定向連接器代理程式或位置主機的流量。

使用連接器代理程式( Docker或 Windows)

依照 為Satellite Connector 代理程式設定隧道伺服器入口主機 中的說明進行操作,但將 SATELLITE_CONNECTOR_DIRECT_LINK_INGRESS 參數設定為步驟 2 中建立的中繼入口主機 ( mysatellite-dl.myname-cluster10-22bfd3cd491bdeb5a0f661fb1e2b0c44-0000.us-south.containers.appdomain.cloud ),而不是內部入口主機本身。 例如:

  • 在容器平台上的 env.txt 檔案中。

    SATELLITE_CONNECTOR_DIRECT_LINK_INGRESS=mysatellite-dl.myname-cluster10-22bfd3cd491bdeb5a0f661fb1e2b0c44-0000.us-south.
    
  • 在 Windows 上,在 config.json 檔案中。

    "SATELLITE_CONNECTOR_DIRECT_LINK_INGRESS": "mysatellite-dl.myname-cluster10-22bfd3cd491bdeb5a0f661fb1e2b0c44-0000.us-south.containers.appdomain.cloud"
    

使用位置主機( CoreOS或 RHEL)

  1. 執行以下 CLI 命令來下載您所在位置的主機附件腳本。

    ibmcloud sat host attach --location LOCATION --operating-system SYSTEM --host-link-agent-endpoint ENDPOINT
    
    --location LOCATION
    Satellite 位置的名稱或 ID。
    --operating-system SYSTEM
    您欲將其附加至該位置的主機所使用的作業系統(RHEL 或 RHCOS)。
    --host-link-agent-endpoint ENDPOINT
    鏈結代理程式用來連接鏈結通道伺服器的端點。 在本例中,是在步驟 2 中建立的中繼 Ingress 主機 ( mysatellite-dl.myname-cluster10-22bfd3cd491bdeb5a0f661fb1e2b0c44-0000.us-south.containers.appdomain.cloud )。
  2. 依照將 本機附加到您的位置 中適用於您的主機作業系統的說明來附加主機代理程式。