FAQ

릴레이 계산 리소스의 비용이 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를 설정할 수 있습니까?

아니오. Direct Link를 사용하려면 RHCOS 사용 위치가 둘 다 있어야 하고 사용자 위치에서 RHCOS 호스트를 사용해야 합니다.

인터넷 대신 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 ’ 링크 구성 요소(터널 서버와 커넥터)가 보안 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 계정에서 릴레이를 작성하십시오. 그러면 터널 서버의 사설 클라우드 서비스 엔드포인트로 프록시 수신 트래픽을 전환합니다. 기본적으로 릴레이 Ingress에는 내부 10.X.X.X/8 IP 주소 범위에 있는 IP 주소가 있으며, 이는 Direct Link 연결을 통해 액세스할 수 있습니다.

다음 다이어그램은 트래픽의 플로우를 보여줍니다.

1. IBM Cloud Satellite 클러스터에서 IBM Cloud 서비스로의 요청과 같이 사용자 위치에서 시작되는 네트워크 트래픽은 Direct Link 를 통해 Direct Link 라우팅 가능 주소가 있는 Relay Private Ingress로 링크 서비스를 통해 라우팅됩니다.
2. 중계기는 새 세션을 시작하여 터널 서버의 프라이빗 클라우드 서비스 엔드포인트로 요청을 전달하며, 이는 166.9.X.X/16 범위 (링크 프라이빗 주소) 의 IP 주소로 종료됩니다.

목표

공용 인터넷에 접속하지 않고도 Red Hat CoreOS 기능을 지원하는 위치를 생성할 수 있습니다. 모든 트래픽은 Direct Link 에서 처리되며, 내부에서만 유지됩니다.

상위 레벨 단계에는 다음이 포함됩니다.

1. Direct Link를 종료하는 IBM Cloud 계정으로 Red Hat CoreOS 사용 Satellite 위치를 작성하십시오.
2. 릴레이를 작성하십시오. 이는 http/https및 보안 웹 소켓을 지원하는 역방향 프록시입니다.
3. Red Hat CoreOS 호스트에 대한 조항. 1단계에서작성된 위치에 대한 첨부 스크립트로 다운로드되는 ignition 스크립트를 사용하여 호스트를 사용자 정의하십시오.

전제조건

• 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 (Virtual Router Function) 인지 확인하십시오.
• 다음과 같은 액세스 정책이 설정되어 있는지 확인하십시오. 자세한 정보는 사용자 권한 확인을 참조하십시오.
  • IBM Cloud 의 관리자 IAM 플랫폼 액세스 역할은 다음을 위한 것입니다. IBM Cloud Kubernetes Service
  • IBM Cloud 의 관리자 IAM 플랫폼 액세스 역할 (다음에 대한) IBM Cloud Container Registry
  • 작성자 또는 관리자 IBM Cloud IBM Cloud Kubernetes Service
  • IBM Cloud 의 관리자 IAM 플랫폼 액세스 역할 (다음에 대한) IBM Cloud Container Registry
  • IBM Cloud 의 관리자 IAM 플랫폼 액세스 역할은 다음을 위한 것입니다. IBM Cloud Satellite
  • 관리자 IBM Cloud IBM Cloud Satellite 에 대한 IAM 서비스 액세스 역할
  • IBM Cloud 의 관리자 IAM 플랫폼 액세스 역할은 다음을 위한 것입니다. Object Storage
  • 작성자 또는 관리자 IBM Cloud IBM Cloud Object Storage 에 대한 IAM 플랫폼 액세스 역할
  • IBM Cloud 의 관리자 IAM 플랫폼 액세스 역할은 다음을 위한 것입니다. IBM Cloud Certificate Manager
  • 작성자 또는 관리자 IBM Cloud IBM Cloud Certificate Manager 의 IAM 플랫폼 액세스 역할
  • 뷰어 IBM Cloud Satellite 와 함께 사용할 리소스 그룹에 대한 IAM 플랫폼 액세스 역할
  • 관리자 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 에서 Classic 또는 VPC 모드로 실행할 수 있습니다. 다음 단계에서는 비공개 전용 VPC Red Hat OpenShift 클러스터(VPC 비공개 노드)에 NGINX 리버스 프록시를 배포하는 예시를 보여줍니다.

한 가지 필수 요구사항은 클러스터 사설 유입 (릴레이 유입) 에 지정할 수 있는 올바른 이름과 IBM Cloud의 올바른 인증서를 보유하는 것입니다. IBM Cloud에서 개인용 노드의 VPC Red Hat OpenShift 클러스터는 기본 개인용 호스트 이름 및 인증서와 함께 제공됩니다. 이를 사용하거나 사용자 정의 호스트 이름 및 인증서를 가져올 수 있습니다. 이 예제에서는 기본 개인용 호스트 이름 및 인증서를 사용합니다.

이 시나리오에 대한 VPC 클러스터 고려사항:

• 구역: 모든 다중 구역 가능 VPC 구역
• 작업자 노드 특성: 모든 VPC 인프라 특성
• 버전: 4.x.x
• 작업자 풀: 최소 2개의 작업자 노드
• 서브넷: 기본 범위가 Red Hat OpenShift 클러스터의 --pod-subnet 및 --service-subnet 값과 Satellite 또는 Satellite 또는 Red Hat OpenShift 호스트가 온프레미스에 배포된 네트워크 CIDR과 충돌하는 경우, 인그레스 로드 밸런서 IP 서브넷을 포함하세요.
• 클라우드 서비스 엔드포인트: 공용 및 개인용 엔드포인트를 모두 원하는 경우 --disable-public-service-endpoint 옵션을 지정하지 마십시오.
• 기본 작업자 풀을 구역 간에 분산시켜 클래식 또는 VPC 클러스터의 가용성을 늘리십시오.
• 후속 단계에서 구성하는 사설 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 리버스 프록시 포드를 노출하는 데 이들이 사용될 것입니다. 기본값을 사용하거나 사용자 정의 호스트 이름 및 인증서를 가져올 수 있습니다. 자세한 정보는 사설 클라우드 서비스 엔드포인트만 사용하여 VPC 클러스터에서 앱을 비공개로 노출 을 참조하십시오.

2. 시크릿 매니저 인스턴스를 생성하고 이전 단계에서 생성한 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. openshift-ingress 에서 기본 TLS 시크릿을 복사하여, 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 ) 파일의 내용을 로컬 디렉터리에 복사하세요. 이 구성은 터널 서버의 Direct Link 엔드포인트에 ws-리버스 프록시 또는 https 리버스 프록시를 적용합니다. 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. 포드 목록을 확인하여 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 경로에 머무르게 되고 공용 인터넷을 사용하는 트래픽은 없습니다.

아래의 해당 지침에 따라 커넥터 에이전트 또는 로케이션 호스트의 트래픽을 리디렉션하세요.