使用 Direct Link 将位置与 IBM Cloud 连接
- 支持的位置类型
- 支持Red Hat CoreOS(RHCOS) 的位置和连接器
- 受支持的主机操作系统
- Red Hat CoreOS(RHCOS) 和 RHEL
将安全 IBM Cloud® Direct Link 连接用于 Satellite 在 IBM Cloud Satellite® 位置和 IBM Cloud®中运行的服务之间的链接通信。
在本教程中,您将设置 Satellite 链接以使用 Direct Link 连接。 您所在位置的链路隧道客户机通过 Direct Link 连接将流量发送到您在 IBM Cloud 帐户中创建的中继设备。 此中继代理到 IBM Cloud 专用网络中链接隧道服务器的 IP 地址的流量。
常见问题及解答
- 中继计算资源的成本是否包含在 Satellite 服务成本中?
- 用于中继设备和 Satellite 的 IBM Cloud 资源将单独计费。
- 通过 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 链接。 这使客户能够:
- 通过 Direct Link从 Satellite 位置访问 IBM Cloud 上的服务; 示例包括 IBM Cloud® Object Storage中的备份,将度量值发送到 IBM Cloud Monitoring,在 IBM Cloud Activity Tracker中跟踪事件或将日志发送到 IBM Cloud Log Analysis。
- 从 IBM Cloud访问在 Satellite 位置中运行的服务。
- 在 IBM Cloud外部访问公共云服务。
可以使用为通过 Direct Link 而不是因特网路由流量而创建的 Satellite 端点地址来访问这些端点。
这可防止客户的敏感数据通过公共互联网,例如混合云环境中的集成服务之间的日志记录,备份或数据。 这还有助于优化入口/出口费用。
概述
缺省情况下,两个 Satellite 链接组件,隧道服务器和连接器,IBM Cloud 与 Satellite 位置中的资源之间的代理网络流量通过安全 TLS 连接。 本文档涵盖通过 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 帐户中创建 Relay,这将逆向代理传入到隧道服务器的私有云服务端点的流量。 缺省情况下,中继 Ingress 具有内部 10.X.X.X/8
IP 地址范围内的 IP 地址,可通过 Direct Link 连接进行访问。
下图演示了流量。
- 源自您的位置的网络流量 (例如,从 IBM Cloud Satellite 集群到 IBM Cloud 服务的请求) 通过链接服务通过 Direct Link 路由到具有直接链路可路由地址的 Relay Private Ingress。
- 中继设备启动新会话以将请求转发到隧道服务器的私有云服务端点,该端点将终止到
166.9.X.X/16
范围内的 IP 地址 (链路专用地址)。
目标
您可以创建 Red Hat CoreOS 已启用的位置,而无需访问公共因特网。 所有流量都由 Direct Link 处理并保持在内部。
高级步骤包括:
- 使用终止 Direct Link的 IBM Cloud 帐户创建启用了 Red Hat CoreOS 的 Satellite 位置。
- 创建一个中继,它是一个支持 http/https 和安全 websocket 的逆向代理。
- 供应 Red Hat CoreOS 主机。 使用作为步骤 1 中创建的位置的连接脚本下载的点火脚本来定制主机。
先决条件
- 您必须已启用 Red Hat CoreOS Satellite 位置。 如果您还没有 Red Hat CoreOS,请遵循 创建已启用的 Red Hat CoreOS Satellite 位置 中的指示信息进行创建。
- 在目标 Satellite 位置与 IBM Cloud 特定 VPC 或经典集群之间提供了 Direct Link。
- 确保 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
- 管理员 IBM Cloud IBM Cloud Container Registry
- 写程序 或 管理者 IBM Cloud IBM Cloud Kubernetes Service
- 管理员 IBM Cloud IBM Cloud Container Registry
- 管理员 IBM Cloud IBM Cloud Satellite
- Manager IBM Cloud IBM Cloud Satellite
- 管理员 IBM Cloud Object Storage
- 写程序 或 管理者 IBM Cloud IBM Cloud Object Storage
- 管理员 IBM Cloud IBM Cloud Certificate Manager 的 IAM 平台访问角色
- 写程序 或 管理器 IBM Cloud IBM Cloud Certificate Manager
- 查看者 IBM Cloud 您计划用于 Satellite 的资源组的 IAM 平台访问角色
- Manager IBM Cloud IBM Cloud Schematics
- 专门供应 Kubernetes 集群,并在其中部署 NGINX 逆向代理以转发到 Direct Link 端点。
创建启用了 Red Hat CoreOS 的 Satellite 位置
如果已启用 Red Hat CoreOS Satellite 位置,那么可以跳过此步骤。
登录到具有 Direct Link 的 IBM Cloud 帐户,并创建启用了 Red Hat CoreOS 的 Satellite 位置。 有关更多信息,请参阅 创建 Satellite 位置。
创建中继设备
中继是一个支持安全 Websocket 连接的 http/https 逆向代理。 它可以在 VSI,Red Hat OpenShift 或 IBM Cloud Kubernetes Service 上作为经典或 VPC 运行。 以下步骤演示了在仅专用 VPC Red Hat OpenShift 集群 (在 VPC 专用节点上) 上部署 NGINX 逆向代理的示例。
一个基本要求是具有可分配给集群专用入口 (Relay Ingress) 的有效名称以及 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 相冲突,则包括入口负载平衡器 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
在此场景中,如果对 Ingress 子域运行
nslookup
命令,那么它将解析为 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
-
创建入口。
oc apply -f myingressresource.yaml -n <dl-reverse-proxy>
-
通过运行以下命令获取隧道服务器 Direct Link 内部 Ingress 主机名。
ibmcloud sat endpoint ls --location LOCATION_ID
-
从输出中,记下 Location 端点。 将
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 逆向 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 的 ConfigMap (
dl-reverse-proxy
)。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 pods
NAME 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
-
检查入口。
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
-
连接到反向代理 URL。
curl -k https://mysatellite-dl.myname-cluster10-22bfd3cd491bdeb5a0f661fb1e2b0c44-0000.us-south.containers.appdomain.cloud
{"status":"UP"}
重定向流量以使用Direct Link路径
既然中继已准备就绪,可以将传入流量代理到隧道服务器内部入口,那么就可以设置定位主机或连接器,通过中继重定向其流量。 这样就能确保所有流量都保持在专用网络的Direct Link路径上,不会有流量使用公共互联网。
按照以下适用说明,为 Connector 代理或位置主机重定向流量。
使用连接器代理Docker或 Windows)
按照 为SatelliteConnector 代理配置隧道服务器导入主机 中的说明操作,但将 "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 位置的名称或标识。
--operating-system SYSTEM
- 要附加到位置的主机的操作系统(RHEL 或 RHCOS)。
--host-link-agent-endpoint ENDPOINT
- 链路代理程序用于连接到链路隧道服务器的端点。 在这种情况下,将使用步骤 2 中创建的中继输入主机(
mysatellite-dl.myname-cluster10-22bfd3cd491bdeb5a0f661fb1e2b0c44-0000.us-south.containers.appdomain.cloud
)。
-
按照 "将内部部署主机附加到您的位置 中适用于主机操作系统的说明安装主机代理。