Red Hat OpenShift 4에서의 라우트를 사용한 앱 노출

단일 구역 클래식 클러스터에서의 트래픽 플로우

다음 다이어그램은 라우터가 인터넷에서 단일 구역, 클래식 클러스터의 앱으로 네트워크 트래픽을 전달하는 방법을 보여줍니다.

{: caption="

1. 앱에 대한 요청은 앱에 대해 설정한 라우트 호스트 이름을 사용합니다.

2. DNS 서비스가 하위 도메인을 라우터 서비스의 포터블 공인 IP 주소로 해석합니다.

3. 라우터는 요청을 수신한 후 사설 네트워크를 통해 앱 팟(Pod)의 사설 IP 주소로 전달합니다. 요청 패키지의 소스 IP 주소는 라우터 팟(Pod)이 실행되는 작업자 노드의 공인 IP 주소로 변경됩니다. 여러 앱 인스턴스가 클러스터에 배치되면 라우터에서 앱 팟(Pod) 간의 요청을 전송합니다.

4. 앱이 응답 패킷을 리턴하는 경우 클라이언트 요청을 전달한 라우터가 있는 작업자 노드의 IP 주소를 사용합니다. 그런 다음 로드 밸런서 서비스를 통해 응답 패킷을 클라이언트에 전송합니다.

다중 구역 클래식 클러스터에서의 트래픽 플로우

다음 다이어그램은 라우터가 인터넷에서 다중 구역, 클래식 클러스터의 앱으로 네트워크 트래픽을 전달하는 방법을 보여줍니다.

{: caption="

1. 앱에 대한 요청은 앱에 대해 설정한 라우트 호스트 이름을 사용합니다.

2. DNS 서비스가 라우트 하위 도메인을 다중 구역 로드 밸런서(MZLB)에서 정상으로 보고한 라우터 서비스의 포터블 공용 IP 주소로 해석합니다. MZLB는 클러스터의 각 구역에서 라우터를 노출하는 서비스의 이동식 공용 IP 주소를 지속적으로 확인합니다. 요청은 라운드 로빈 주기로 다양한 구역에서 라우터 서비스에 의해 처리됩니다.

3. 라우터가 라우터 서비스의 해석된 IP 주소를 기반으로 요청을 수신합니다.

4. 라우터가 사설 네트워크를 통해 앱 팟(Pod)의 사설 IP 주소로 요청을 전달합니다. 요청 패키지의 소스 IP 주소는 라우터 팟(Pod)이 실행되는 작업자 노드의 공인 IP 주소로 변경됩니다. 각 라우터는 자체 구역의 앱 인스턴스와 기타 구역의 앱 인스턴스로 요청을 라우팅합니다. 또한, 여러 앱 인스턴스가 하나의 구역에 배치되는 경우 라우터는 앱 팟(Pod) 간의 요청을 대체합니다.

5. 앱이 응답 패킷을 리턴하는 경우 클라이언트 요청을 전달한 라우터가 있는 작업자 노드의 IP 주소를 사용합니다. 그런 다음 로드 밸런서 서비스를 통해 응답 패킷을 클라이언트에 전송합니다.

퍼블릭 클라우드 서비스 엔드포인트가 있는 다중 구역 VPC 클러스터의 트래픽 플로우

퍼블릭 클라우드 서비스 엔드포인트가 사용으로 설정된 다중 구역 VPC 클러스터를 작성하면 공용 Ingress 제어기가 기본적으로 작성됩니다. Ingress 제어기는 앱에 대해 공개적으로 액세스 가능한 라우트를 지정하며 공용 호스트 네트워크 인터페이스에서 앱에 대한 요청을 청취합니다.

다음 다이어그램은 Ingress 제어기가 인터넷에서 다중 구역, VPC 클러스터의 앱으로 네트워크 트래픽을 전달하는 방법을 보여줍니다.

1. 앱에 대한 요청은 앱에 대해 설정한 라우트 호스트 이름을 사용합니다.

2. DNS 서비스가 라우트 하위 도메인을 Ingress 제어기에 대한 서비스에 지정된 VPC 로드 밸런서 호스트 이름으로 해석합니다. VPC 클러스터에서 Ingress 제어기 서비스의 외부 IP 주소는 유동 IP 주소이며 VPC 지정 호스트 이름으로 숨겨집니다.

3. VPC 로드 밸런서가 VPC 호스트 이름을 정상으로 보고된 Ingress 제어기 서비스의 사용 가능한 외부 IP 주소로 해석합니다. VPC 로드 밸런서는 클러스터의 각 구역에서 Ingress 제어기를 노출하는 서비스의 외부 IP 주소를 지속적으로 확인합니다.

4. VPC 로드 밸런서가 해석된 IP 주소를 기반으로 Ingress 제어기 서비스에 요청을 전송합니다.

5. Ingress 제어기가 사설 네트워크를 통해 앱 팟(Pod)의 사설 IP 주소로 해당 요청을 전달합니다. 요청 패킷의 소스 IP 주소는 Ingress 제어기 팟(Pod)이 실행되는 작업자 노드의 IP 주소로 변경됩니다. 각 Ingress 제어기는 자체 구역의 앱 인스턴스와 다른 구역의 앱 인스턴스로 요청을 라우팅합니다. 또한 다중 앱 인스턴스가 하나의 구역에 배치되는 경우 Ingress 제어기는 앱 팟(Pod) 간에 요청을 대체합니다.

6. 앱이 응답 패킷을 리턴할 때 클라이언트 요청을 전달한 Ingress 제어기가 있는 작업자 노드의 IP 주소를 사용합니다. 그런 다음 Ingress 제어기가 VPC 로드 밸런서를 통해 응답 패킷을 클라이언트에 전송합니다.

프라이빗 클라우드 서비스 엔드포인트만 있는 다중 구역 VPC 클러스터의 트래픽 플로우

프라이빗 클라우드 서비스 엔드포인트만으로 다중 구역 VPC 클러스터를 작성하는 경우 기본적으로 개인용 Ingress 제어기가 작성됩니다. Ingress 제어기는 앱에 대해 비공개로 액세스 가능한 라우트를 지정하며 개인용 호스트 네트워크 인터페이스를 청취합니다. 사설 VPC 네트워크에 연결된 클라이언트만 개인용 라우트에 의해 노출된 앱에 액세스할 수 있습니다.

다음 다이어그램은 Ingress 제어기가 사설 네트워크에서 다중 구역, VPC 클러스터의 앱으로 네트워크 트래픽을 전달하는 방법을 보여줍니다.

{: caption="컨트롤러를 사용하여 프라이빗, 멀티존, VPC 클러스터에 앱 노출인그레스 " caption-side="bottom"} 사용하여 프라이빗, 멀티존, VPC 클러스터에 앱 노출

1. 사설 VPC 네트워크에 연결된 클라이언트는 앱의 개인용 라우트를 사용하여 요청을 앱에 전송합니다. 예를 들어, 가상 프라이빗 클라우드 VPN인 IBM Cloud Transit Gateway 또는 IBM Cloud Direct Link를 사용하여 온프레미스 네트워크, 다른 VPC 또는 IBM Cloud 클래식 인프라부터 클러스터에서 실행되는 앱까지의 요청을 허용할 수 있습니다.

2. DNS 서비스가 라우트 하위 도메인을 Ingress 제어기에 대한 서비스에 지정된 VPC 로드 밸런서 호스트 이름으로 해석합니다. VPC 클러스터에서 Ingress 제어기 서비스의 IP 주소는 유동 IP 주소이며 VPC 지정 호스트 이름으로 숨겨집니다. 라우트 하위 도메인에 대한 DNS가 공용 DNS 시스템에 등록되어 있지만 VPC에서 DNS 분석 서버에 연결할 수 있습니다.

3. 사설 VPC 로드 밸런서가 VPC 호스트 이름을 정상으로 보고된 Ingress 제어기 서비스의 사용 가능한 사설 IP 주소로 해석합니다. VPC 로드 밸런서는 클러스터의 각 구역에서 Ingress 제어기를 노출하는 서비스의 IP 주소를 지속적으로 확인합니다.

4. VPC 로드 밸런서가 해석된 IP 주소를 기반으로 Ingress 제어기 서비스에 요청을 전송합니다.

5. Ingress 제어기가 사설 네트워크를 통해 앱 팟(Pod)의 사설 IP 주소로 해당 요청을 전달합니다. 요청 패킷의 소스 IP 주소는 Ingress 제어기 팟(Pod)이 실행되는 작업자 노드의 IP 주소로 변경됩니다. 각 Ingress 제어기는 자체 구역의 앱 인스턴스와 다른 구역의 앱 인스턴스로 요청을 라우팅합니다. 또한 다중 앱 인스턴스가 하나의 구역에 배치되는 경우 Ingress 제어기는 앱 팟(Pod) 간에 요청을 대체합니다.

6. 앱이 응답 패킷을 리턴할 때 클라이언트 요청을 전달한 Ingress 제어기가 있는 작업자 노드의 IP 주소를 사용합니다. 그런 다음 Ingress 제어기가 VPC 로드 밸런서 및 IBM Cloud VPC VPN, Transit Gateway 또는 Direct Link를 통해 응답 패킷을 클라이언트에 전송합니다.

퍼블릭 클라우드 서비스 엔드포인트가 있는 클래식 클러스터 또는 VPC 클러스터에 공용 라우트 설정

클러스터가 클래식 인프라에서 생성되었거나, VPC 인프라에서 생성되었고 클러스터 생성 시 퍼블릭 클라우드 서비스 엔드포인트를 활성화한 경우, 클러스터는 기본적으로 퍼블릭 인그레스 컨트롤러와 함께 생성됩니다. 이 Ingress 제어기를 사용하여 앱의 공용 라우트를 작성할 수 있습니다.

1. 앱 배치에 대한 Kubernetes ClusterIP 서비스를 작성하십시오. 이 서비스는 Ingress 제어기가 트래픽을 전송할 수 있는 앱의 내부 IP 주소를 제공합니다.

   oc expose deploy <app_deployment_name> --name my-app-svc
   

2. 앱에 대한 도메인을 선택하십시오. 경로 URL은 130자 이내여야 합니다. IBM 제공 도메인: 사용자 지정 도메인이 필요하지 않은 경우, 경로 호스트명이 자동 생성됩니다. 형식은 <service_name>-<project>.<cluster_name>-<random_hash>-0000.<region>.containers.appdomain.cloud 다음과 같습니다. 사용자 정의 도메인: 사용자 정의 도메인을 지정하려면 DNS 제공자 또는 IBM Cloud® Internet Services를 통해 이를 수행하십시오.

   1. EXTERNAL-IP 열에서 각 구역의 공용 Ingress 제어기 서비스에 대한 공인 IP 주소를 가져오십시오. 작업자 노드가 있는 첫 번째 구역의 Ingress 제어기 서비스는 항상 router-default로 이름이 지정되고, 이후에 클러스터에 추가하는 구역의 Ingress 제어기 서비스는 router-dal12와 같은 이름을 갖습니다.

      oc get svc -n openshift-ingress
      

   2. DNS 제공자를 사용하여 사용자 정의 도메인을 작성하십시오. 클러스터의 여러 서비스에 동일한 하위 도메인을 사용하려는 경우 와일드카드 하위 도메인을 등록할 수 있습니다(예: *.example.com).

   3. IP 주소를 A 레코드로 추가하여 사용자 정의 도메인을 Ingress 제어기의 공인 IP 주소에 맵핑하십시오.

3. 앱에 필요한 TLS 종료 유형을 기반으로 라우트를 설정하십시오. 사용자 지정 도메인이 없다면 옵션을 --hostname 포함하지 마십시오. 라우트 호스트 이름이 <service_name>-<project>.<cluster_name>-<random_hash>-0000.<region>.containers.appdomain.cloud 형식으로 생성됩니다. 와일드카드 하위 도메인을 등록한 경우 작성하는 각 라우트에 고유한 하위 도메인을 지정하십시오. 예를 들어, 이 라우트에 --hostname svc1.example.com을 지정하고 다른 라우트에 --hostname svc2.example.com을 지정할 수 있습니다.

   • 단순:

     oc expose service <app_service_name> [--hostname <subdomain>]
     

   • 통과(Passthrough):

     oc create route passthrough --service <app_service_name> [--hostname <subdomain>]
     

     HTTP/2 연결을 처리해야 합니까? 라우트를 작성한 후 oc edit route <app_service_name>을 실행하고 라우트의 targetPort 값을 https로 변경하십시오. curl -I --http2 https://<route> --insecure를 실행하여 라우트를 테스트할 수 있습니다.
   • Edge: 사용자 지정 도메인을 사용하는 경우, --cert, 옵션을 --key 포함하고 --hostname, 선택적으로 옵션을 --ca-cert 포함하십시오. TLS 인증서 요구 사항에 대한 자세한 내용은 Red Hat OpenShift edge route 문서 에서 확인하십시오.

     oc create route edge --service <app_service_name> [--hostname <subdomain> --cert <tls.crt> --key <tls.key> --ca-cert <ca.crt>]
     

   • 재암호화: 사용자 지정 도메인을 사용하는 경우, --cert, 옵션을 포함하고 --hostname, 선택적으로 --key 옵션을 --ca-cert 포함하십시오. TLS 인증서 요구 사항에 대한 자세한 내용은 Red Hat OpenShift 재암호화 경로 문서를 참조하십시오.

     oc create route reencrypt --service <app_service_name> --dest-ca-cert <destca.crt> [--hostname <subdomain> --cert <tls.crt> --key <tls.key> --ca-cert <ca.crt>]
     

4. 앱 서비스에 대한 라우트가 작성되었는지 확인하십시오.

   oc get routes
   

5. 선택 사항: 선택적 구성으로 기본 라우팅 규칙을 사용자 지정합니다. 예를 들어, 경로별 HAProxy 어노테이션을 사용할 수 있습니다.

프라이빗 클라우드 서비스 엔드포인트만 있는 VPC 클러스터에 공용 라우트 설정

클러스터가 VPC 인프라에서 작성되었으며 클러스터 작성 중에 프라이빗 클라우드 서비스 엔드포인트만 사용으로 설정한 경우 클러스터는 기본적으로 개인용 라우터로만 작성됩니다. 앱을 공개적으로 노출하려면 먼저 공용 IngressController 리소스를 작성하고 하위 도메인을 사용하여 이를 구성해야 합니다. 이 Ingress 오퍼레이터는 IngressController를 기반으로 새 공용 Ingress 제어기를 자동으로 작성하고 구성하며, 이를 사용하여 앱에 대한 공용 라우트를 작성할 수 있습니다.

다음 단계에서 IngressController 리소스를 작성하더라도 이 IngressController는 자신에게 필요한 Ingress 제어기를 작성하고 구성하는 데만 필요하다는 점을 참고하십시오. Ingress 제어기가 작성된 후에는 Ingress 제어기를 직접 사용하여 라우트를 작성합니다.

1. Ingress 제어기에 사용할 도메인을 준비하십시오.

   • 사용자 정의 도메인: 사용자 정의 도메인을 등록하려면 DNS(Domain Name Service) 제공자 또는 IBM Cloud DNS를 통해 이를 수행하십시오. 클러스터의 여러 서비스에 동일한 하위 도메인을 사용하려는 경우 와일드카드 하위 도메인을 등록할 수 있습니다(예: *.example.com). 사용자 정의 도메인을 사용하는 경우 IngressController 스펙에 도메인 인증서도 지정해야 합니다. 자세한 정보는 사용자 정의 기본 인증서 설정 을 참조하십시오.
   • IBM 제공 도메인:
     1. 클러스터에 있는 기존 하위 도메인을 나열하십시오. 출력의 하위 도메인 열에서 000<n> 값이 가장 높은 하위 도메인을 복사하십시오.

        ibmcloud oc nlb-dns ls --cluster <cluster_name_or_id>
        

        이 예제 출력에서는 mycluster-a1b2cdef345678g9hi012j3kl4567890-0002.us-south.containers.appdomain.cloud 하위 도메인의 000<n> 값이 가장 높은 값인 0002입니다.

        Subdomain                                                                               Load Balancer Hostname                        Health Monitor   SSL Cert Status           SSL Cert Secret Name
        mycluster-a1b2cdef345678g9hi012j3kl4567890-0000.us-south.containers.appdomain.cloud     ["1234abcd-us-south.lb.appdomain.cloud"]      None             created                   mycluster-a1b2cdef345678g9hi012j3kl4567890-0000
        mycluster-a1b2cdef345678g9hi012j3kl4567890-0001.us-south.containers.appdomain.cloud     ["5678efgh-us-south.lb.appdomain.cloud"]      None             created                   mycluster-a1b2cdef345678g9hi012j3kl4567890-0001
        mycluster-a1b2cdef345678g9hi012j3kl4567890-0002.us-south.containers.appdomain.cloud     ["9012ijkl-us-south.lb.appdomain.cloud"]      None             created                   mycluster-a1b2cdef345678g9hi012j3kl4567890-0002
        

     2. 복사한 하위 도메인에서 하위 도메인의 000<n> 값을 000<n+1>로 변경하십시오. 예를 들어, 하위 mycluster-a1b2cdef345678g9hi012j3kl4567890-0002.us-south.containers.appdomain.cloud 도메인이 로 변경됩니다 mycluster-a1b2cdef345678g9hi012j3kl4567890-0003.us-south.containers.appdomain.cloud. 이 하위 도메인은 후속 단계에서 등록합니다.

2. 1단계의 도메인을 사용하는 공용 Ingress 제어기를 구성하는 YAML 파일을 작성하십시오.

   apiVersion: operator.openshift.io/v1
   kind: IngressController
   metadata:
     name: public
     namespace: openshift-ingress-operator
   spec:
     # defaultCertificate: If you are using a custom domain, specify the domain certificate
       # name: custom-certs-default
     replicas: 2
     domain: <domain>
     endpointPublishingStrategy:
       loadBalancer:
         scope: External
       type: LoadBalancerService
   

3. 클러스터의 openshift-ingress-operator 네임스페이스에 IngressController 리소스를 작성하십시오. IngressController를 작성하면 IngressController 설정에 따라 공용 Ingress 제어기가 자동으로 작성되어 openshift-ingress 네임스페이스에 배치됩니다. 또한 Ingress 제어기를 노출시키기 위해 Ingress 제어기 서비스가 작성됩니다.

   oc create -f public.yaml -n openshift-ingress-operator
   

4. ** 서비스의 **EXTERNAL-IProuter-public 필드에서 VPC 호스트 이름을 가져오십시오. VPC 클러스터에서, 라우터 서비스의 외부 IP 주소는 유동 IP 주소이며 VPC 지정 호스트 이름으로 숨겨집니다.

   oc get svc router-public -n openshift-ingress
   

   출력 예

   NAME                         TYPE           CLUSTER-IP       EXTERNAL-IP                             PORT(S)                      AGE
   router-public                LoadBalancer   172.21.57.132    1234abcd-us-south.lb.appdomain.cloud    80/TCP,443/TCP,1940/TCP      3m
   

5. 서비스의 VPC 호스트 이름을 1단계에서 선택한 도메인에 등록하십시오. 이 단계를 수행하면 VPC 호스트 이름으로 숨겨진 Ingress 제어기 서비스의 IP 주소가 Ingress 제어기에 대해 선택한 도메인에 등록됩니다.

   • 사용자 정의 도메인: DNS 제공자를 통해 서비스의 VPC 호스트 이름을 사용자 정의 도메인에 맵핑되는 CNAME으로 추가하십시오.

   • IBM 제공 도메인: 서비스의 VPC 호스트 이름에 대한 DNS 항목을 작성하십시오. 다음 명령을 실행하면 2단계에서 지정한 하위 도메인이 자동으로 작성되어 Ingress 제어기 서비스에 등록됩니다.

     ibmcloud oc nlb-dns create vpc-gen2 --cluster <cluster_name_or_ID> --lb-host <router_VPC_hostname>
     

6. 선택사항: 특정 라우트가 특정 Ingress 제어기에서 처리되도록 Ingress 제어기 샤딩을 사용하려는 경우(예: 개인용 라우트는 개인용 라우터에만 허용됨) 라우트 레이블 또는 네임스페이스 레이블을 사용하여 샤딩 방법을 지정할 수 있습니다. 작성 시간 동안 선택기를 추가하려면 spec 아래의 ingresscontroller yaml에 이를 포함시키십시오. 예를 들어, Ingress 제어기가 레이블이 type=sharded인 Ingress/라우트만 처리할 수 있도록 하려면 routeSelector를 추가할 수 있습니다. 자세한 정보는 Ingress 제어기 샤딩을 참조하십시오.

     routeSelector:
       matchLabels:
         type: sharded
   

   1. 기존 Ingress 제어기에 선택기를 추가하려면 Ingress 제어기 목록을 가져오십시오.

      oc get ingresscontroller -n openshift-ingress-operator
      

   2. 샤딩을 사용할 Ingress 제어기에 선택기를 추가하십시오.

      oc patch  -n openshift-ingress-operator IngressController/<name>   --type='merge'   -p '{"spec":{"routeSelector":{"matchLabels":{"type":"sharded"}}}}'
      

   3. 기본 IngressController에는 선택기가 추가되지 않으므로 모든 라우트가 클러스터의 기본 Ingress 제어기에 계속 허용됩니다. 관련 라우트 또는 네임스페이스 레이블 선택기를 사용하여 이 동작을 변경할 수 있습니다. 예를 들어, 레이블이 type=sharded인 Ingress/라우트를 건너뛰도록 기본 라우터를 조정하려면 다음 패치 명령을 실행하십시오.

      oc patch -n openshift-ingress-operator IngressController/default --type='merge'   -p '{"spec":{"routeSelector":{"matchExpressions":[{"key":"type","operator":"NotIn","values":["sharded"]}]}}}'
      

      클러스터의 여러 라우트 및 Ingress는 기본 공용 Ingress 제어기에 따라 다릅니다. 기본 Ingress 컨트롤러를 편집하기 전에 변경 사항이 올바른지 확인하십시오. 자세한 정보는 Ingress 제어기 샤딩을 참조하십시오.

7. 앱 배치에 대한 Kubernetes ClusterIP 서비스를 작성하십시오. 이 서비스는 Ingress 제어기가 트래픽을 전송할 수 있는 앱의 내부 IP 주소를 제공합니다.

   oc expose deploy <app_deployment_name> --name <app_service_name> -n <app_project>
   

8. 앱에 필요한 TLS 종료 유형을 기반으로 라우트를 설정하십시오. 옵션을 --hostname 포함하지 않으면 경로 호스트명이 형식으로 자동 <app_service_name>-<app_project>.<router-subdomain> 생성됩니다.

   • 단순:

     oc expose service <app_service_name> [--hostname <subdomain>]
     

   • 통과(Passthrough):

     oc create route passthrough --service <app_service_name> [--hostname <subdomain>]
     

     HTTP/2 연결을 처리해야 합니까? 라우트를 작성한 후 oc edit route <app_service_name>을 실행하고 라우트의 targetPort 값을 https로 변경하십시오. curl -I --http2 https://<route> --insecure를 실행하여 라우트를 테스트할 수 있습니다.
   • Edge: 사용자 지정 도메인을 사용하는 경우, --cert, 옵션을 --key 포함하고 --hostname, 선택적으로 옵션을 --ca-cert 포함하십시오. TLS 인증서 요구 사항에 대한 자세한 내용은 Red Hat OpenShift edge route 문서 에서 확인하십시오.

     oc create route edge --service <app_service_name> [--hostname <subdomain> --cert <tls.crt> --key <tls.key> --ca-cert <ca.crt>]
     

   • 재암호화: 사용자 지정 도메인을 사용하는 경우, --cert, 옵션을 포함하고 --hostname, 선택적으로 --key 옵션을 --ca-cert 포함하십시오. TLS 인증서 요구 사항에 대한 자세한 내용은 Red Hat OpenShift 재암호화 경로 문서를 참조하십시오.

     oc create route reencrypt --service <app_service_name> --dest-ca-cert <destca.crt> [--hostname <subdomain> --cert <tls.crt> --key <tls.key> --ca-cert <ca.crt>]
     

9. 앱에 대한 라우트가 작성되었는지 확인하십시오.

   oc get routes
   

10. 선택사항: 선택적 구성을 사용하여 공용 Ingress 제어기의 라우팅 규칙을 사용자 정의하십시오. 예를 들어, 경로별 HAProxy 어노테이션을 사용할 수 있습니다.

11. 동일한 하위 도메인을 사용하여 더 많은 앱에 대한 라우트를 작성하려면 동일한 공용 Ingress 제어기에서 라우트가 생성되도록 7 - 10단계를 반복할 수 있습니다. 다른 하위 도메인을 사용하여 더 많은 앱에 대한 라우트를 작성하려면 이 섹션의 모든 단계를 반복하여 다른 도메인으로 새 공용 Ingress 제어기를 작성하십시오.

퍼블릭 클라우드 서비스 엔드포인트가 있는 클래식 클러스터 또는 VPC 클러스터에 개인용 라우트 설정

클러스터가 클래식 인프라에서 생성되었거나, VPC 인프라에서 생성되었고 클러스터 생성 시 퍼블릭 클라우드 서비스 엔드포인트를 활성화한 경우, 기본적으로 퍼블릭 인그레스 컨트롤러만 포함된 클러스터가 생성됩니다. 앱을 비공개로 노출하려면 먼저 개인용 IngressController 리소스를 작성하고 하위 도메인을 사용하여 이 제어기를 구성해야 합니다. Ingress 오퍼레이터는 새 개인용 Ingress 제어기를 자동으로 작성하고 구성하며, 이를 사용하여 앱의 개인용 라우트를 작성할 수 있습니다.

다음 단계에서 IngressController 리소스를 작성하더라도 이 IngressController 리소스는 자신에게 필요한 Ingress 제어기를 작성하고 구성하는 데만 필요하다는 점을 참고하십시오. Ingress 제어기가 작성된 후에는 이 라우터를 직접 사용하여 라우트를 작성합니다.

1. Ingress 제어기에 사용할 도메인을 준비하십시오.

   • 사용자 정의 도메인, 클래식 또는 VPC 클러스터: 사용자 정의 도메인을 등록하려면 DNS(Domain Name Service) 제공자 또는 IBM Cloud DNS를 통해 이를 수행하십시오. 클러스터의 여러 서비스에 동일한 하위 도메인을 사용하려는 경우 와일드카드 하위 도메인을 등록할 수 있습니다(예: *.example.com).
   • IBM 제공 도메인, VPC 클러스터 한정:
     1. 클러스터에 있는 기존 하위 도메인을 나열하십시오. 출력의 하위 도메인 열에서 000<n> 값이 가장 높은 하위 도메인을 복사하십시오.

        ibmcloud oc nlb-dns ls --cluster <cluster_name_or_id>
        

        이 예제 출력에서는 mycluster-a1b2cdef345678g9hi012j3kl4567890-0002.us-south.containers.appdomain.cloud 하위 도메인의 000<n> 값이 가장 높은 값인 0002입니다.

        Subdomain                                                                               Load Balancer Hostname                        Health Monitor   SSL Cert Status           SSL Cert Secret Name
        mycluster-a1b2cdef345678g9hi012j3kl4567890-0000.us-south.containers.appdomain.cloud     ["1234abcd-us-south.lb.appdomain.cloud"]      None             created                   mycluster-a1b2cdef345678g9hi012j3kl4567890-0000
        mycluster-a1b2cdef345678g9hi012j3kl4567890-0001.us-south.containers.appdomain.cloud     ["5678efgh-us-south.lb.appdomain.cloud"]      None             created                   mycluster-a1b2cdef345678g9hi012j3kl4567890-0001
        mycluster-a1b2cdef345678g9hi012j3kl4567890-0002.us-south.containers.appdomain.cloud     ["9012ijkl-us-south.lb.appdomain.cloud"]      None             created                   mycluster-a1b2cdef345678g9hi012j3kl4567890-0002
        

     2. 복사한 하위 도메인에서 하위 도메인의 000<n> 값을 000<n+1>로 변경하십시오. 예를 들어, 하위 mycluster-a1b2cdef345678g9hi012j3kl4567890-0002.us-south.containers.appdomain.cloud 도메인이 로 변경됩니다 mycluster-a1b2cdef345678g9hi012j3kl4567890-0003.us-south.containers.appdomain.cloud. 이 하위 도메인은 후속 단계에서 등록합니다.

2. 1단계의 도메인을 사용하는 개인용 Ingress 제어기를 구성하는 구성 파일을 작성하십시오.

   apiVersion: operator.openshift.io/v1
   kind: IngressController
   metadata:
     name: private
     namespace: openshift-ingress-operator
   spec:
     replicas: 2
     domain: <domain>
     endpointPublishingStrategy:
       loadBalancer:
         scope: Internal
       type: LoadBalancerService
   

3. 클러스터의 openshift-ingress-operator 네임스페이스에 IngressController 리소스를 작성하십시오. IngressController 리소스를 작성하면 IngressController 설정에 따라 개인용 Ingress 제어기가 자동으로 작성되어 openshift-ingress 네임스페이스에 배치됩니다. 또한 IP 주소(클래식 클러스터) 또는 VPC 호스트 이름(VPC 클러스터)을 사용하여 Ingress 제어기를 노출시키기 위해 Ingress 제어기 서비스가 작성됩니다.

   oc create -f private.yaml -n openshift-ingress-operator
   

4. ** 서비스의 **EXTERNAL-IProuter-private 필드에서 IP 주소 또는 VPC 호스트 이름을 가져오십시오.

   oc get svc router-private -n openshift-ingress
   

   클래식 클러스터의 출력 예:

   NAME                         TYPE           CLUSTER-IP       EXTERNAL-IP    PORT(S)                      AGE
   router-private               LoadBalancer   172.21.57.132    10.XX.XX.XX    80/TCP,443/TCP,1940/TCP      3m
   

   VPC 클러스터의 출력 예:

   NAME                         TYPE           CLUSTER-IP       EXTERNAL-IP                             PORT(S)                      AGE
   router-private               LoadBalancer   172.21.57.132    1234abcd-us-south.lb.appdomain.cloud    80/TCP,443/TCP,1940/TCP      3m
   

5. 서비스의 외부 IP 주소 또는 VPC 호스트 이름을 1단계에서 선택한 도메인에 등록하십시오.

   • 사용자 정의 도메인, 클래식 또는 VPC 클러스터: DNS 제공자를 통해 서비스의 외부 IP 주소를 사용자 정의 도메인에 맵핑되는 A 레코드(클래식 클러스터)로 추가하거나, VPC 호스트 이름을 사용자 정의 도메인에 맵핑되는 CNAME(VPC 클러스터)으로 추가하십시오.
   • IBM 제공 도메인, VPC 클러스터 한정: 서비스의 VPC 호스트 이름에 대한 DNS 항목을 작성하십시오. 다음 명령을 실행하면 2단계에서 지정한 하위 도메인이 자동으로 작성되어 Ingress 제어기 서비스에 등록됩니다.

     ibmcloud oc nlb-dns create vpc-gen2 --cluster <cluster_name_or_ID> --lb-host <router_VPC_hostname>
     

6. 선택사항: 특정 라우트가 특정 Ingress 제어기에서 처리되도록 Ingress 제어기 샤딩을 사용하려는 경우(예: 개인용 라우트는 개인용 라우터에만 허용됨) 라우트 레이블 또는 네임스페이스 레이블을 사용하여 샤딩 방법을 지정할 수 있습니다. 작성 시간 동안 선택기를 추가하려면 spec 아래의 ingresscontroller yaml에 이를 포함시키십시오. 예를 들어, Ingress 제어기가 레이블이 type=sharded인 Ingress/라우트만 처리할 수 있도록 하려면 routeSelector를 추가할 수 있습니다. 자세한 정보는 Ingress 제어기 샤딩을 참조하십시오.

     routeSelector:
       matchLabels:
         type: sharded
   

   1. 기존 Ingress 제어기에 선택기를 추가하려면 Ingress 제어기 목록을 가져오십시오.

      oc get ingresscontroller -n openshift-ingress-operator
      

   2. 샤딩을 사용할 Ingress 제어기에 선택기를 추가하십시오.

      oc patch  -n openshift-ingress-operator IngressController/<name>   --type='merge'   -p '{"spec":{"routeSelector":{"matchLabels":{"type":"sharded"}}}}'
      

   3. 기본 IngressController에는 선택기가 추가되지 않으므로 모든 라우트가 클러스터의 기본 Ingress 제어기에 계속 허용됩니다. 관련 라우트 또는 네임스페이스 레이블 선택기를 사용하여 이 동작을 변경할 수 있습니다. 예를 들어, 레이블이 type=sharded인 Ingress/라우트를 건너뛰도록 기본 라우터를 조정하려면 다음 패치 명령을 실행하십시오.

      oc patch -n openshift-ingress-operator IngressController/default --type='merge'   -p '{"spec":{"routeSelector":{"matchExpressions":[{"key":"type","operator":"NotIn","values":["sharded"]}]}}}'
      

7. 앱 배치에 대한 Kubernetes ClusterIP 서비스를 작성하십시오. 이 서비스는 Ingress 제어기가 트래픽을 전송할 수 있는 앱의 내부 IP 주소를 제공합니다.

   oc expose deploy <app_deployment_name> --name <app_service_name> -n <app_project>
   

8. 앱에 필요한 TLS 종료 유형을 기반으로 라우트를 설정하십시오. 5단계에서 설정한 호스트 이름을 지정하십시오.

   • 단순:

     oc expose service <app_service_name> --hostname <subdomain>
     

   • 통과(Passthrough):

     oc create route passthrough --service <app_service_name> --hostname <subdomain>
     

     HTTP/2 연결을 처리해야 합니까? 라우트를 작성한 후 oc edit route <app_service_name>을 실행하고 라우트의 targetPort 값을 https로 변경하십시오. curl -I --http2 https://<route> --insecure를 실행하여 라우트를 테스트할 수 있습니다.
   • Edge: 사용자 지정 도메인을 사용하는 경우 및 --key --cert 옵션을 포함하고, 선택적으로 옵션을 --ca-cert 포함하십시오. TLS 인증서 요구 사항에 대한 자세한 내용은 Red Hat OpenShift edge route 문서 에서 확인하십시오.

     oc create route edge --service <app_service_name> --hostname <subdomain> [--cert <tls.crt> --key <tls.key> --ca-cert <ca.crt>]
     

   • 재암호화: 사용자 지정 도메인을 사용하는 경우 및 --key --cert 옵션을 포함하고, 선택적으로 옵션을 --ca-cert 포함하십시오. TLS 인증서 요구 사항에 대한 자세한 내용은 Red Hat OpenShift 재암호화 경로 문서를 참조하십시오.

     oc create route reencrypt --service <app_service_name> --dest-ca-cert <destca.crt> --hostname <subdomain> [--cert <tls.crt> --key <tls.key> --ca-cert <ca.crt>]
     

9. 앱에 대한 라우트가 작성되었는지 확인하십시오.

   oc get routes
   

10. 선택사항: 선택적 구성을 사용하여 개인용 Ingress 제어기의 라우팅 규칙을 사용자 정의하십시오. 예를 들어, 경로별 HAProxy 어노테이션을 사용할 수 있습니다.

11. 동일한 하위 도메인을 사용하여 더 많은 앱에 대한 라우트를 작성하려면 동일한 개인용 Ingress 제어기에서 라우트가 생성되도록 7 - 10단계를 반복할 수 있습니다. 다른 하위 도메인을 사용하여 더 많은 앱에 대한 라우트를 작성하려면 이 섹션의 모든 단계를 반복하여 다른 도메인으로 새 개인용 Ingress 제어기를 작성하십시오.

프라이빗 클라우드 서비스 엔드포인트만 있는 VPC 클러스터에 개인용 라우트 설정

클러스터가 VPC 인프라에서 작성되고 클러스터 작성 중에 프라이빗 클라우드 서비스 엔드포인트만 사용으로 설정한 경우 클러스터는 기본적으로 개인용 Ingress 제어기로 작성됩니다. 이 Ingress 제어기를 사용하여 앱의 개인용 라우트를 작성할 수 있습니다.

1. 앱 배치에 대한 Kubernetes ClusterIP 서비스를 작성하십시오. 이 서비스는 Ingress 제어기가 트래픽을 전송할 수 있는 앱의 내부 IP 주소를 제공합니다.

   oc expose deploy <app_deployment_name> --name my-app-svc
   

2. 앱에 대한 도메인을 선택하십시오.

   • IBM 제공 도메인: 사용자 정의 도메인이 필요하지 않은 라우트 하위 도메인이 <service_name>-<project>.<cluster_name>-<random_hash>-0000.<region>.containers.appdomain.cloud 형식으로 생성됩니다.
   • 사용자 정의 도메인: 사용자 정의 도메인을 지정하려면 DNS 제공자 또는 IBM Cloud® Internet Services를 통해 이를 수행하십시오.

     1. EXTERNAL-IP 열에서 각 구역의 개인용 Ingress 제어기 서비스에 대한 외부 IP 주소를 가져오십시오. 작업자 노드가 있는 첫 번째 구역의 Ingress 제어기 서비스는 항상 router-default로 이름이 지정되고, 이후에 클러스터에 추가하는 구역의 Ingress 제어기 서비스는 router-dal12와 같은 이름을 갖습니다.

        oc get svc -n openshift-ingress
        

     2. DNS 제공자를 사용하여 사용자 정의 도메인을 작성하십시오. 클러스터의 여러 서비스에 동일한 하위 도메인을 사용하려는 경우 와일드카드 하위 도메인을 등록할 수 있습니다(예: *.example.com).

     3. IP 주소를 A 레코드로 추가하여 사용자 정의 도메인을 Ingress 제어기 서비스의 사설 IP 주소에 맵핑하십시오.

3. 앱에 필요한 TLS 종료 유형에 따라 라우트를 설정하십시오. 사용자 지정 도메인이 없다면 옵션을 --hostname 포함하지 마십시오. 라우트 하위 도메인이 <service_name>-<project>.<cluster_name>-<random_hash>-0000.<region>.containers.appdomain.cloud 형식으로 생성됩니다. 와일드카드 하위 도메인을 등록한 경우 작성하는 각 라우트에 고유한 하위 도메인을 지정하십시오. 예를 들어, 이 라우트에 --hostname svc1.example.com을 지정하고 다른 라우트에 --hostname svc2.example.com을 지정할 수 있습니다.

   • 단순:

     oc expose service <app_service_name> [--hostname <subdomain>]
     

   • 통과(Passthrough):

     oc create route passthrough --service <app_service_name> [--hostname <subdomain>]
     

     HTTP/2 연결을 처리해야 합니까? 라우트를 작성한 후 oc edit route <app_service_name>을 실행하고 라우트의 targetPort 값을 https로 변경하십시오. curl -I --http2 https://<route> --insecure를 실행하여 라우트를 테스트할 수 있습니다.

   • Edge: 사용자 지정 도메인을 사용하는 경우, --cert, 옵션을 --key 포함하고 --hostname, 선택적으로 옵션을 --ca-cert 포함하십시오. TLS 인증서 요구 사항에 대한 자세한 내용은 Red Hat OpenShift edge route 문서 에서 확인하십시오.

     oc create route edge --service <app_service_name> [--hostname <subdomain> --cert <tls.crt> --key <tls.key> --ca-cert <ca.crt>]
     

   • 재암호화: 사용자 지정 도메인을 사용하는 경우, --cert, 옵션을 포함하고 --hostname, 선택적으로 --key 옵션을 --ca-cert 포함하십시오. TLS 인증서 요구 사항에 대한 자세한 내용은 Red Hat OpenShift 재암호화 경로 문서를 참조하십시오.

     oc create route reencrypt --service <app_service_name> --dest-ca-cert <destca.crt> [--hostname <subdomain> --cert <tls.crt> --key <tls.key> --ca-cert <ca.crt>]
     

4. 앱 서비스에 대한 라우트가 작성되었는지 확인하십시오.

   oc get routes
   

5. 선택 사항: 선택적 구성으로 기본 라우팅 규칙을 사용자 지정합니다. 예를 들어, 경로별 HAProxy 어노테이션을 사용할 수 있습니다.