使用 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 連線來存取。
下圖示範資料流量的流程。
- 源自「位置」的網路資料流量 (例如從 IBM Cloud Satellite 叢集到 IBM Cloud 服務的要求) 會透過「透過 Direct Link 的鏈結服務」遞送至具有「直接鏈結可遞送位址」的「中繼專用入口」。
- 「中繼站」會起始新的階段作業,將要求轉遞至通道伺服器的專用雲端服務端點,這會終止至
166.9.X.X/16範圍內的 IP 位址 (鏈結專用位址)。
目標
您無需連線至公共網際網路,即可建立啟用 Red Hat CoreOS 功能的據點。 所有流量均由 Direct Link 處理,並保持在內部。
高階步驟包括:
- 使用終止 Direct Link的 IBM Cloud 帳戶建立 Red Hat CoreOS 已啟用 Satellite 位置。
- 建立中繼,這是支援 http/https 及安全 websocket 的反向 Proxy。
- 佈建 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/8IP 位址範圍。 請檢閱網路設計,以避免 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 中的步驟,向子網域及憑證登錄它。
-
在 VPC 上建立僅限專用 Red Hat OpenShift 叢集。 如需相關資訊,請參閱 建立 VPC 叢集。
在 VPC 中的 Red Hat OpenShift 叢集中,有許多方法可以將應用程式對外公開。 在此範例中,該應用程式將僅透過私有端點進行私有公開,這是 Direct Link 客戶最常見的使用情境。僅透過私有端點進行私有公開的 Red Hat OpenShift 叢集,會預設附帶私有名稱和憑證。 在此範例中,它們將用於公開 NGINX 的反向代理 Pod。 您可以使用預設主機名稱或使用自訂主機名稱及憑證。 如需詳細資料,請參閱 僅在具有專用雲端服務端點的 VPC 叢集裡以專用方式公開應用程式。
-
建立 Secret Manager 實例並將其註冊到在上一個步驟中建立的Red Hat OpenShift叢集。 如需相關資訊,請參閱 建立 Secrets Manager 服務實例。
-
從 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 中繼站之間的路由。 -
獲取秘密 CRN。
ibmcloud oc ingress secret get -c CLUSTER --name SECRET_NAME --namespace openshift-ingress -
為「NGINX」反向代理建立一個命名空間。
kubectl create ns dl-reverse-proxy -
請將預設的 TLS 密鑰從
openshift-ingress複製到即將部署 NGINX 的專案中。ibmcloud oc ingress secret create --cluster CLUSTER_NAME_OR_ID --cert-crn CRN --name SECRET_NAME --namespace dl-reverse-proxy -
將下列 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 -
建立 Ingress。
oc apply -f myingressresource.yaml -n <dl-reverse-proxy> -
執行下列指令,以取得通道伺服器 Direct Link 內部 Ingress 主機名稱。
ibmcloud sat endpoint ls --location LOCATION_ID -
從輸出中,記下「位置」端點。 將
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的值。 -
將 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; } } } -
複製 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 -
建立「NGINX」(
dl-reverse-proxy)的「ConfigMap」。oc apply -f confnginx.yaml -n dl-reverse-proxy -
設定正確的「
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 -
請透過列出 Pod 來再次確認 NGINX 是否正在運行。
oc get podsNAME READY STATUS RESTARTS AGE nginx-757fbc9f85-gv2p6 1/1 Running 0 53s nginx-757fbc9f85-xvmrj 1/1 Running 0 53s -
請檢查日誌。
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 -
檢查 Ingress。
oc get ingressNAME 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 -
連接到反向代理 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)
-
執行以下 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)。
-
依照將 本機附加到您的位置 中適用於您的主機作業系統的說明來附加主機代理程式。