Ingress 오퍼레이터

Ingress Red Hat OpenShift 오퍼레이터 는 클러스터 내 애플리케이션으로 들어오는 모든 트래픽에 적용되는 라우팅 규칙을 구현합니다.

Ingress 제어기는 Ingress 오퍼레이터가 관리합니다. 클러스터 작성 중에 기본 Ingress 제어기는 <cluster_name>-<globally_unique_account_HASH>-0000.<region>.containers.appdomain.cloud 형식으로 클러스터의 기본 Ingress 하위 도메인에 등록됩니다. 라우트 리소스를 작성하여 앱을 이 하위 도메인에 등록하는 경우 Ingress 제어기는 이 하위 도메인을 통해 앱에 대한 요청이 앱 팟(Pod)에 올바르게 프록시되는지 확인합니다. 클러스터에서 기본 Ingress 제어기를 확인하려면 oc describe ingresscontroller/default -n openshift-ingress-operator를 실행하십시오.

앱을 다른 도메인에 등록할 경우, 대신해서 사용자 정의 도메인에 대한 라우팅 규칙을 구현하는 사용자 정의 Ingress 제어기를 작성할 수 있습니다.

Ingress 제어기

하나의 HAProxy기반 Red Hat OpenShift Ingress 제어기가 각 IngressController에 대해 작성되고 작업자 노드가 있는 각 구역에 하나의 Ingress 제어기 서비스가 작성됩니다.

Ingress 오퍼레이터는 IngressController에 지정된 것과 동일한 도메인으로 Ingress 제어기를 구성합니다. Ingress 제어기는 해당 도메인을 통해 수신 HTTP, HTTPS 또는 TCP 서비스 요청을 청취합니다. Ingress 제어기의 로드 밸런서 서비스 컴포넌트는 라우트 리소스에 정의되고 Ingress 제어기로 구현되는 규칙에 따라서만 해당 앱에 대한 요청을 팟(Pod)에 전달합니다.

다중 구역 클러스터가 있는 경우에는 하나의 고가용성 라우터가 클러스터에 배치되고 다중 구역 VPC 로드 밸런서를 사용하여 구성됩니다. Ingress 제어기의 두 복제본이 올바르게 배치되고 업데이트될 수 있도록 구역당 두 개의 작업자 노드가 필요합니다.

Ingress 제어기를 수동으로 작성하는 경우 Ingress 제어기는 클러스터의 앱 또는 Ingress 하위 도메인에 자동으로 등록되지 않습니다.

라우트 리소스

라우트를 사용하여 앱을 노출시키려면 앱에 대한 Kubernetes 서비스를 작성하고 라우트 리소스를 정의하여 Ingress 제어기에 이 서비스를 등록해야 합니다. Ingress 리소스는 앱에 대한 수신 요청을 라우팅하는 방법의 규칙을 정의하는 Red Hat OpenShift 리소스입니다.

Route 리소스는 앱 서비스에 대한 경로도 지정합니다. 앱 서비스에 대한 경로가 클러스터의 Ingress 하위 도메인에 추가되어 고유 앱 URL을 구성합니다(예: mycluster-a1b2cdef345678g9hi012j3kl4567890-0000.us-south.containers.appdomain.cloud/myapp1).

노출하려는 앱이 있는 프로젝트마다 하나의 라우트 리소스가 필요합니다.

• 클러스터의 앱이 모두 동일한 프로젝트에 있는 경우 노출할 앱에 대한 라우팅 규칙을 정의하려면 하나의 라우트 리소스를 작성해야 합니다. 동일한 프로젝트 내에서 앱에 다른 도메인을 사용할 경우 도메인당 하나의 리소스를 작성할 수 있습니다.
• 클러스터의 앱이 여러 프로젝트에 있는 경우 앱의 라우팅 규칙을 정의하려면 프로젝트마다 하나의 라우트 리소스를 작성해야 합니다.

자세한 정보는 단일 또는 다중 프로젝트에 대한 네트워킹 계획을 참조하십시오.

앱에 대한 라우팅 규칙을 사용자 정의하려는 경우에는 앱에 대한 트래픽을 관리하는 라우트별 HAProxy 어노테이션을 사용할 수 있습니다. 이러한 지원되는 어노테이션의 형식은 haproxy.router.openshift.io/<annotation> 또는 router.openshift.io/<annotation>입니다. IBM Cloud Kubernetes Service 어노테이션(ingress.bluemix.net/<annotation>) 및 NGINX 어노테이션(nginx.ingress.kubernetes.io/<annotation>)은 Red Hat OpenShift 버전 4의 Ingress 제어기 또는 라우트 리소스에 대해 지원되지 않습니다.

단일 구역 클러스터

다음 다이어그램은 Ingress가 인터넷에서 클래식 단일 구역 클러스터의 앱으로 통신을 지정하는 방법을 보여줍니다.

![](/images/roks_router_ingress_single.svg "사용하여 단일 영역 클러스터에 앱 노출Ingress*를 사용하여 단일 영역 클러스터에 앱 " caption-side="bottom"} 사용하여 단일 영역 클러스터에 앱 "){: caption="

1. 사용자는 앱의 URL에 액세스하여 요청을 앱에 전송합니다. 이 URL은 Ingress 리소스 경로가 추가된, 노출된 앱에 대한 클러스터의 Ingress 하위 도메인입니다(예: mycluster-<hash>-0000.us-south.containers.appdomain.cloud/myapp).

2. DNS 시스템 서비스는 URL의 하위 도메인을 클러스터에서 Ingress 제어기를 노출하는 로드 밸런서의 포터블 공인 IP 주소로 해석합니다.

3. 클라이언트가 해석된 IP 주소를 기반으로 하여 Ingress 제어기 서비스에 요청을 전송합니다.

4. Ingress 제어기가 Ingress 제어기로 구현되는 라우팅 규칙에서 myapp 경로에 대한 라우팅 규칙을 확인합니다. 일치하는 규칙이 발견된 경우에는 Ingress 제어기에서 정의한 규칙 및 라우트 리소스에 따라 앱이 배치된 팟(Pod)으로 요청이 프록시됩니다. 패킷의 소스 IP 주소는 Ingress 제어기 팟(Pod)이 실행되는 작업자 노드의 IP 주소로 변경됩니다. 여러 앱 인스턴스가 클러스터에 배치된 경우 Ingress 제어기가 앱 팟(Pod) 간에 요청을 로드 밸런싱합니다.

5. 앱이 응답 패킷을 리턴하는 경우 요청을 전달한 Ingress 제어기가 있는 작업자 노드의 IP 주소를 사용합니다. 그러면 Ingress 제어기가 응답 패킷을 클라이언트에 전송합니다.

다중 구역 클러스터

다음 다이어그램은 Ingress가 인터넷에서 클래식 다중 구역 클러스터의 앱으로 통신을 지정하는 방법을 보여줍니다.

![](/images/roks_router_ingress_multizone.svg "사용하여 멀티존 클러스터에 앱 노출Ingress*를 사용하여 멀티존 클러스터에 앱 " caption-side="bottom"} 사용하여 멀티존 클러스터에 앱 "){: caption="

1. 사용자는 앱의 URL에 액세스하여 요청을 앱에 전송합니다. 이 URL은 Ingress 리소스 경로가 추가된, 노출된 앱에 대한 클러스터의 Ingress 하위 도메인입니다(예: mycluster-<hash>-0000.us-south.containers.appdomain.cloud/myapp).

2. DNS 시스템 서비스는 라우트 하위 도메인을 MZLB에서 정상으로 보고된 Ingress 제어기 서비스의 부동 공인 IP 주소로 해석합니다. MZLB는 클러스터의 각 구역에서 Ingress 제어기를 노출하는 서비스의 포터블 공인 IP 주소를 지속적으로 확인합니다. 다양한 구역에서 Ingress 제어기 서비스가 라운드 로빈 주기로 요청을 처리합니다.

3. 클라이언트가 Ingress 제어기를 노출하는 서비스의 IP 주소로 요청을 전송합니다.

4. Ingress 제어기가 Ingress 제어기로 구현되는 myapp 경로에 대한 라우팅 규칙을 확인합니다. 일치하는 규칙이 발견된 경우에는 IngressController에서 정의한 규칙 및 라우트 리소스에 따라 앱이 배치된 팟(Pod)으로 요청이 프록시됩니다. 패킷의 소스 IP 주소는 Ingress 제어기 팟(Pod)이 실행되는 작업자 노드의 IP 주소로 변경됩니다. 여러 앱 인스턴스가 클러스터에 배치된 경우 Ingress 제어기 서비스가 모든 구역의 앱 팟(Pod) 간에 요청을 전송합니다.

5. 앱이 응답 패킷을 리턴할 때 요청을 전달한 Ingress 제어기 서비스가 있는 작업자 노드의 IP 주소를 사용합니다. 그러면 Ingress 제어기가 응답 패킷을 클라이언트에 전송합니다.

퍼블릭 클라우드 서비스 엔드포인트가 있는 VPC 클러스터

퍼블릭 클라우드 서비스 엔드포인트가 사용으로 설정된 다중 구역 VPC 클러스터를 작성하면 공용 Ingress 제어기가 기본적으로 작성됩니다. 다음 다이어그램은 Ingress가 인터넷에서 VPC 다중 구역 클러스터의 앱으로 통신을 지정하는 방법을 보여줍니다.

![](images/roks_router_ingress_vpc.svg "사용하여 멀티존 VPC 클러스터에서 앱을 공개적으로 노출하기Ingress*를 사용하여 멀티존 VPC 클러스터에서 앱을 공개적으로 " caption-side="bottom"} 사용하여 멀티존 VPC 클러스터에서 앱을 "){: caption="노출하기

1. 사용자는 앱의 URL에 액세스하여 요청을 앱에 전송합니다. 이 URL은 노출된 앱의 Ingress 리소스 경로가 추가된 클러스터의 Ingress 하위 도메인입니다(예: mycluster-<hash>-0000.us-south.containers.appdomain.cloud/myapp).

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

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

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

5. Ingress 제어기가 Ingress 제어기로 구현되는 myapp 경로에 대한 라우팅 규칙을 확인합니다. 일치하는 규칙이 발견된 경우에는 IngressController에서 정의한 규칙 및 라우트 리소스에 따라 앱이 배치된 팟(Pod)으로 요청이 프록시됩니다. 패킷의 소스 IP 주소는 Ingress 제어기 팟(Pod)이 실행되는 작업자 노드의 IP 주소로 변경됩니다. 여러 앱 인스턴스가 클러스터에 배치된 경우 Ingress 제어기가 모든 구역의 앱 팟(Pod) 간에 요청을 로드 밸런싱합니다.

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

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

프라이빗 클라우드 서비스 엔드포인트만으로 다중 구역 VPC 클러스터를 작성하는 경우 기본적으로 개인용 Ingress 제어기가 작성됩니다. 사설 VPC 네트워크에 연결된 클라이언트만 개인용 Ingress 제어기에 의해 노출된 앱에 액세스할 수 있습니다. 다음 다이어그램은 Ingress가 사설 네트워크에서 VPC 다중 구역 클러스터의 앱으로 통신을 지정하는 방법을 보여줍니다.

1. 사설 VPC 네트워크에 연결된 클라이언트는 앱의 URL을 사용하여 요청을 앱에 전송합니다. 이 URL은 노출된 앱의 Ingress 리소스 경로가 추가된 클러스터의 Ingress 하위 도메인입니다(예: mycluster-<hash>-0000.us-south.containers.appdomain.cloud/myapp). 예를 들어, 가상 프라이빗 클라우드 VPN인 IBM Cloud Transit Gateway 또는 IBM Cloud Direct Link를 사용하여 온프레미스 네트워크, 다른 VPC 또는 IBM Cloud 클래식 인프라부터 클러스터에서 실행되는 앱까지의 요청을 허용할 수 있습니다.

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

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

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

5. Ingress 제어기가 Ingress 제어기로 구현되는 myapp 경로에 대한 라우팅 규칙을 확인합니다. 일치하는 규칙이 발견된 경우에는 IngressController에서 정의한 규칙 및 라우트 리소스에 따라 앱이 배치된 팟(Pod)으로 요청이 프록시됩니다. 패킷의 소스 IP 주소는 Ingress 제어기 팟(Pod)이 실행되는 작업자 노드의 IP 주소로 변경됩니다. 여러 앱 인스턴스가 클러스터에 배치된 경우 Ingress 제어기가 모든 구역의 앱 팟(Pod) 간에 요청을 로드 밸런싱합니다.

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