Satellite 클러스터에 앱 노출
공용 네트워크의 트래픽 요청, 호스트의 사설 네트워크에 연결된 리소스의 트래픽 요청 또는 Satellite의 리소스의 트래픽 요청에 IBM Cloud 클러스터에서 실행되는 앱을 안전하게 노출합니다.
Satellite 클러스터에 앱을 노출하는 몇 가지 옵션이 있습니다.
- MetalLB: 온프레미스 Satellite 클러스터에 적합한
LoadBalancer구현입니다. - Red Hat OpenShift 라우트: 호스트 이름과 함께 공용 또는 사설 네트워크의 요청에 대해 앱을 신속하게 노출합니다. Red Hat OpenShift Ingress 제어기는 라우트에 대한 DNS 등록 및 선택적 인증서를 제공합니다.
- 서드파티 로드 밸런서 및 Red Hat OpenShift 라우트: 호스트 이름으로 앱을 노출하고 Ingress 제어기의 DNS 레코드에 등록된 호스트 IP 주소에 대한 상태 검사를 추가합니다.
- NodePorts: 30000 - 32767 범위의 NodePort를 사용하여 UDP 또는 TCP 앱과 같은 HTTP가 아닌 앱을 노출합니다.
- Red Hat OpenShift 라우트 및 Satellite 링크 엔드포인트: 개인용 라우트를 사용하여 앱을 노출하고 라우트에 대한
location유형의 링크 엔드포인트를 작성합니다. IBM Cloud 사설 네트워크에 연결된 리소스만 앱에 액세스할 수 있습니다.
MetalLB 설정
MetalLB 베어 메탈 Kubernetes 클러스터용 로드 밸런서 구현체로, 표준 라우팅 프로토콜을 사용합니다. 자세한 내용은 문 서의 MetalLB 및 Red Hat OpenShift 연산자에 MetalLB 관한 내용을 참조하십시오.
MetalLB, 설치하고 구성하려면 Red Hat OpenShift 설명서의 MetalLB 운영자 설치에 나와 있는 지침을 따르세요. 시작하기 전에 LoadBalancer 서비스의 외부 IP를 위한 전용 서브넷(IPAddressPool)이 있는지 확인하세요. IPAddressPool 에 포함된 IP 주소가 예약되어 있지 않거나 다른 용도로 사용되는지 확인하십시오. 그렇지 않으면 로드 밸런싱 기능이 실패할 수 있습니다.
Red Hat OpenShift 라우트를 사용한 앱 노출
라우트를 사용하여 Red Hat OpenShift Ingress 제어기의 외부 IP 주소에 클러스터의 서비스를 신속하게 노출합니다.
Red Hat OpenShift 라우트는 서비스를 <service_name>-<project>.<cluster_name>-<random_hash>-0000.upi.containers.appdomain.cloud 형식의 호스트 이름으로 노출합니다. Ingress
제어기는 기본적으로 클러스터에 배치되며, 이를 통해 외부 클라이언트가 라우트를 사용할 수 있습니다. Ingress 제어기는 서비스 선택기를 사용하여 서비스 및 서비스를 백업하는 엔드포인트를 찾습니다. 하나의 라우트를 통한 트래픽이 여러 서비스로 향하도록 서비스 선택기를 구성할 수 있습니다. 또한 Ingress 제어기가 호스트 이름에 대해 지정한 TLS 인증서를 사용하여 비보안 또는 보안 라우트를 작성할 수 있습니다. Ingress
제어기는 HTTP 및 HTTPS 프로토콜만 지원합니다.
라우트를 시작하기 전에 다음 고려사항을 검토하십시오.
- 호스트 네트워크 연결
- 클러스터의 호스트에 공용 네트워크 연결이 있는 경우, 기본적으로 공용 Ingress 제어기로만 클러스터가 작성됩니다. 이 Ingress 제어기를 사용하여 앱의 공용 라우트를 작성할 수 있습니다. 클러스터의 호스트에 사설 네트워크 연결만 있는 경우, 기본적으로 개인용 Ingress 제어기로만 클러스터가 작성됩니다. 이 Ingress 제어기를 사용하여 호스트의 사설 네트워크 내에서만 액세스할 수 있는 앱의 개인용 라우트를 작성할 수 있습니다. 클러스터에서 사설 네트워크 연결만 있는 공용 라우트를 설정하려면 다음 단계를 완료하기 전에 먼저 개인용 Ingress 제어기 앞에 공용 네트워크 연결이 있는 자체 서드파티 로드 밸런서를 설정하십시오.
- 상태 검사
- 기본적으로 클러스터의 Ingress 제어기에 대한 DNS 등록 관리가 제공됩니다. 예를 들어, 클러스터에 지정된 호스트를 사용자 위치에서 제거하고 다른 호스트로 대체하면 IBM에서 Ingress 제어기의 DNS 레코드에 있는 호스트 IP 주소를 업데이트합니다. 라우트에 대한 DNS 등록이 제공되지만 클러스터의 Ingress 제어기 앞에 로드 밸런서 서비스가 배치되지 않습니다. Ingress 제어기의 DNS 레코드에 등록된 호스트의 IP 주소 상태를 검사하려면 다음 단계를 완료하기 전에 Ingress 제어기 앞에 자체 서드파티 로드 밸런서를 설정할 수 있습니다.
앱에 대한 라우트를 작성하려면 다음을 수행하십시오.
-
앱 배치에 대한 Kubernetes
ClusterIP서비스를 작성하십시오. 이 서비스는 Ingress 제어기가 트래픽을 전송할 수 있는 앱의 내부 IP 주소를 제공합니다.oc expose deploy <app_deployment_name> --name my-app-svc -
앱에 대한 도메인을 설정하십시오.
- IBM 제공 도메인: 사용자 정의 도메인을 사용할 필요가 없는 경우 라우트 호스트 이름이
<service_name>-<project>.<cluster_name>-<random_hash>-0000.upi.containers.appdomain.cloud형식으로 생성됩니다. 다음 단계를 계속하십시오. - 사용자 정의 도메인: 사용자 정의 도메인을 작성하려면 DNS 제공자에 대한 작업을 수행하십시오. 이전에 Ingress 제어기 앞에 서드파티 로드 밸런서를 설정한 경우에는 대신 DNS 제공자와 함께 작업하여 로드 밸런서에 대한 사용자 정의 도메인을 작성하십시오.
- IBM 제공 도메인: 사용자 정의 도메인을 사용할 필요가 없는 경우 라우트 호스트 이름이
-
EXTERNAL-IP 열에서 Ingress 제어기 서비스에 대한 IP 주소를 가져오십시오.
oc get svc router-external-default -n openshift-ingress -
DNS 제공자를 사용하여 사용자 정의 도메인을 작성하십시오. 클러스터의 여러 서비스에 동일한 하위 도메인을 사용하려는 경우 와일드카드 하위 도메인을 등록할 수 있습니다(예:
*.example.com). -
IP 주소를 A 레코드로 추가하여 사용자 정의 도메인을 Ingress 제어기의 IP 주소에 맵핑하십시오.
-
앱에 필요한 TLS 종료 유형을 기반으로 라우트를 설정하십시오. 사용자 지정 도메인이 없는 경우,
--hostname옵션을 포함하지 마십시오. 그러면 경로 호스트명이 자동으로 생성됩니다. 와일드카드 하위 도메인을 등록한 경우 작성하는 각 라우트에 고유한 하위 도메인을 지정하십시오. 예를 들어, 이 라우트에--hostname svc1.example.com을 지정하고 다른 라우트에--hostname svc2.example.com을 지정할 수 있습니다.- 단순:
oc expose service <app_service_name> [--hostname <subdomain>] ``` * 통과(Passthrough): ```sh {: pre} 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`를 실행하여 라우트를 테스트할 수 있습니다. {: tip} * 참고: 사용자 지정 도메인을 사용하는 경우, `--hostname`, `--cert`, `--key` 옵션을 포함하고, 필요에 따라 `--ca-cert` 옵션도 포함하십시오. TLS 인증서 요구 사항에 대한 자세한 내용은 [Red Hat OpenShift 의 에지 경로 문서를](https://docs.redhat.com/en/documentation/openshift_container_platform/4.21/html/ingress_and_load_balancing/routes#nw-ingress-creating-an-edge-route-with-a-custom-certificate_secured-routes){: external} 참조하십시오. ```sh {: pre} oc create route edge --service <app_service_name> [--hostname <subdomain> --cert <tls.crt> --key <tls.key> --ca-cert <ca.crt>] ``` * 재암호화: 사용자 지정 도메인을 사용하는 경우, `--hostname`, `--cert` 및 `--key` 옵션을 포함하고, 선택적으로 `--ca-cert` 옵션도 포함하십시오. TLS 인증서 요건에 대한 자세한 내용은 [Red Hat OpenShift 의 재암호화 경로 문서를](https://docs.redhat.com/en/documentation/openshift_container_platform/4.21/html/ingress_and_load_balancing/routes#nw-ingress-creating-a-reencrypt-route-with-a-custom-certificate_secured-routes){: external} 참조하십시오. ```sh {: pre} 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>] ``` -
앱 서비스에 대한 라우트가 작성되었는지 확인하십시오.
oc get routes -
선택 사항: 선택적 구성으로 기본 라우팅 규칙을 사용자 지정합니다. 예를 들어, 경로별 HAProxy 어노테이션을 사용할 수 있습니다.
Red Hat OpenShift Ingress 제어기 앞에 서드파티 로드 밸런서 설정
Ingress 컨트롤러의 DNS 레코드에 등록된 호스트의 IP 주소에 대한 상태 점검을 수행하려면, 클러스터의 워커 노드로 할당된 호스트의 IP 주소 앞에 자체적인 타사 로드 밸런서를 구성할 수 있습니다.
예를 들어, 클러스터에 지정된 호스트를 사용자 위치에서 제거하고 다른 호스트로 대체하면 IBM에서 Ingress 제어기의 DNS 레코드에 있는 호스트 IP 주소를 업데이트합니다. 그러나 클라우드 제공자의 인프라 관리 등을 통해 호스트의 전원을 끄면 호스트의 IP 주소가 Ingress 제어기의 DNS 레코드에서 제거되지 않으며 DNS 레코드가 해당 호스트의 IP 주소로 해석되는 경우 이로 인해 호출이 실패할 수 있습니다. Ingress 제어기 앞에 로드 밸런서를 설정하면, 예를 들어 프로덕션 레벨 워크로드에 대한 고가용성을 보장하기 위해 호스트 IP 주소의 상태가 정기적으로 검사되는지 확인할 수 있습니다.
Ingress 제어기 앞에 로드 밸런서를 작성한 후 Ingress 제어기를 사용하여 앱에 대한 라우트를 작성할 수 있습니다. 요청이 앱에 대한 라우트로 전송되면 먼저 로드 밸런서에서 요청을 수신한 후 Ingress 제어기로 전달한 다음 요청을 앱으로 전달합니다.
-
클러스터의 기본 Ingress 제어기에 대한 세부사항을 나열하십시오. 출력의 EXTERNAL-IP 열에서 클러스터의 Ingress 제어기에 등록된 작업자 노드 IP 주소를 가져오십시오. 출력의 PORT(S) 열에서 공용 또는 개인용 로드 밸런서를 작성할지에 따라 Ingress 제어기 서비스가 현재 공용 또는 사설 네트워크 트래픽에 대해 노출하는 노드 포트를 가져오십시오.
oc get svc router-external-default -n openshift-ingress다음 출력 예에서 노드 포트
30783이 공용 트래픽(80)에 대해 노출됩니다.NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE router-external-default LoadBalancer 172.21.84.172 169.xx.xxx.xxx, 169.xx.xxx.xxx 80:30783/TCP,443:30413/TCP 24h -
이러한 IP 주소 및 노드 포트를 사용하는 경우 호스트의 사설 네트워크에 연결된 계층 4 로드 밸런서를 작성하십시오. 예를 들어, 호스트의 클라우드 제공자에서 로드 밸런서를 배치하거나 온프레미스 네트워크에 F5 로드 밸런서를 배치할 수 있습니다. 공용 라우트를 작성하려면 로드 밸런서에 공용 네트워크 연결이 있어야 하며 이전 단계에서 발견한 공용 트래픽의 포트에 TCP 및 UDP 트래픽을 전달할 수 있어야 합니다. 개인용 라우트를 작성하려면 로드 밸런서가 이전 단계에서 발견한 개인용 트래픽의 포트에 TCP 및 UDP 트래픽을 전달할 수 있어야 합니다.
-
클러스터의 호스트 이름을 가져오십시오.
<cluster_name>-<random_hash>-0000.upi.containers.appdomain.cloud형식의 이 하위 도메인이 클러스터의 Ingress 제어기에 등록됩니다.ibmcloud oc nlb-dns ls --cluster <cluster_name_or_ID> -
클러스터의 하위 도메인에 로드 밸런서의 공인 IP 주소를 추가하십시오. 추가할 모든 공인 IP 주소에 대해 이 명령을 반복하십시오.
ibmcloud oc nlb-dns add --ip <public_IP> --cluster <cluster_name_or_ID> --nlb-host <hostname> -
클러스터의 하위 도메인에서 작업자 노드 IP 주소를 제거하십시오. 이전에 검색한 모든 IP 주소에 대해 이 명령을 반복하십시오.
ibmcloud oc nlb-dns rm classic --ip <private_IP> --cluster <cluster_name_or_ID> --nlb-host <hostname> -
로드 밸런서의 공인 IP 주소가 이제 클러스터 하위 도메인에 등록되어 있는지 확인하십시오.
ibmcloud oc nlb-dns ls --cluster <cluster_name_or_ID> -
Red Hat OpenShift 라우트로 앱 노출의 단계를 계속하여 앱에 대한 라우트를 작성하십시오.
기본 등록 방식을 사용하지 않고 외부 로드 밸런서나 VIP를 하위 도메인에 등록하도록 구성하는 경우, 해당 로드 밸런서는 클러스터 호스트에 대한 인바운드 액세스 권한이 필요하며, 클러스터 호스트는 로드 밸런서에 대한 아웃바운드 액세스 권한이 필요합니다.
NodePort로 앱 노출
TCP 또는 UDP 앱을 노출해야 하는 경우와 같이 Red Hat OpenShift Ingress 제어기를 사용하여 앱을 노출할 수 없는 경우 앱에 대한 NodePort를 작성할 수 있습니다.
-
앱의 NodePort를 작성하십시오. 30000 - 32767 범위의 NodePort 및 내부 클러스터 IP 주소가 앱에 지정됩니다.
oc expose deployment <deployment_name> --type=NodePort --name=<nodeport_svc_name> -
앱에 지정된 NodePort를 가져오십시오.
oc describe svc <nodeport_svc_name> -
<cluster_name>-<random_hash>-0000.upi.containers.appdomain.cloud형식으로 된 클러스터의 호스트 이름을 가져오십시오.ibmcloud oc nlb-dns ls --cluster <cluster_name_or_ID> -
<cluster_name>-<random_hash>-0000.upi.containers.appdomain.cloud:<nodeport>형식으로 된 클러스터의 하위 도메인 및 NodePort를 사용하여 앱에 액세스하십시오. 호스트에 사설 네트워크 연결만 있는 경우, 예를 들어, VPN 액세스를 통해 호스트의 사설 네트워크에 연결되어 있어야 합니다. -
선택사항: NodePort에 직접 액세스하지 않으려는 경우 또는 443과 같은 특정 포트에서 앱을 노출해야 하는 경우 호스트의 사설 네트워크에 연결되고 트래픽을 NodePort로 전달하는 자체 서드파티 계층 4 로드 밸런서를 설정할 수 있습니다. 예를 들어, 호스트의 클라우드 제공자에서 로드 밸런서를 배치하거나 온프레미스 네트워크에 F5 로드 밸런서를 배치할 수 있습니다. 로드 밸런서는
30000 - 32767포트에 대한 TCP 및 UDP 트래픽을 전달할 수 있어야 합니다.
IBM Cloud에서 트래픽의 링크 엔드포인트 및 라우트로 앱 노출
사설 네트워크를 통해 IBM Cloud의 리소스에서 Satellite 클러스터의 앱에 액세스하려는 경우 개인용 Ingress 제어기를 사용하여 앱에 대한 개인용 라우트를 작성할 수 있습니다. 그런 다음, 라우트에 대해 location 유형의 링크 엔드포인트를 작성할 수 있으며 이 엔드포인트에는 IBM Cloud 사설 네트워크 내에서만 액세스할 수 있습니다.
-
Red Hat OpenShift 라우트를 사용하여 앱 노출의 단계에 따라 앱에 대한 개인용 라우트를 작성하십시오. 이 라우트에는 호스트의 사설 네트워크 내에서만 액세스할 수 있습니다.
-
location엔드포인트를 작성하여 위치의 리소스에 연결의 단계에 따라 앱의 개인용 라우트에 대한 Satellite 링크 엔드포인트를 작성하십시오. -
선택사항: IBM Cloud의 특정 리소스에서만 엔드포인트에 액세스할 수 있도록 하려면 엔드포인트의 소스 목록에 리소스를 추가하십시오.