2.3. Ingress 컨트롤러를 사용한 수신 클러스터 트래픽 구성
OpenShift Container Platform에서는 클러스터에서 실행되는 서비스와 클러스터 외부에서 통신할 수 있습니다. 이 방법에서는 Ingress 컨트롤러를 사용합니다.
2.3.1. Ingress 컨트롤러 및 경로 사용 링크 복사링크가 클립보드에 복사되었습니다!
Ingress Operator에서는 Ingress 컨트롤러 및 와일드카드 DNS를 관리합니다.
OpenShift Container Platform 클러스터에 대한 외부 액세스를 허용하는 가장 일반적인 방법은 Ingress 컨트롤러를 사용하는 것입니다.
Ingress 컨트롤러는 외부 요청을 수락하고 구성된 경로를 기반으로 이러한 요청을 프록시하도록 구성되어 있습니다. 이는 HTTP, SNI를 사용하는 HTTPS, SNI를 사용하는 TLS로 제한되며, SNI를 사용하는 TLS를 통해 작동하는 웹 애플리케이션 및 서비스에 충분합니다.
관리자와 협력하여 구성된 경로를 기반으로 외부 요청을 수락하고 프록시하도록 Ingress 컨트롤러를 구성하십시오.
관리자는 와일드카드 DNS 항목을 생성한 다음 Ingress 컨트롤러를 설정할 수 있습니다. 그러면 관리자에게 문의하지 않고도 엣지 Ingress 컨트롤러로 작업할 수 있습니다.
기본적으로 클러스터의 모든 Ingress Controller는 클러스터의 모든 프로젝트에서 생성된 모든 경로를 허용할 수 있습니다.
Ingress 컨트롤러의 경우
- 기본적으로 두 개의 복제본이 있으므로 두 개의 작업자 노드에서 실행되어야 합니다.
- 더 많은 노드에 더 많은 복제본을 갖도록 확장할 수 있습니다.
이 섹션의 절차에는 클러스터 관리자가 수행해야 하는 사전 요구 사항이 필요합니다.
2.3.2. 사전 요구 사항 링크 복사링크가 클립보드에 복사되었습니다!
다음 절차를 시작하기 전에 관리자는 다음을 수행해야 합니다.
- 요청이 클러스터에 도달할 수 있도록 외부 포트를 클러스터 네트워킹 환경으로 설정합니다.
클러스터 관리자 역할의 사용자가 한 명 이상 있는지 확인합니다. 이 역할을 사용자에게 추가하려면 다음 명령을 실행합니다.
oc adm policy add-cluster-role-to-user cluster-admin username
$ oc adm policy add-cluster-role-to-user cluster-admin username
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 최소한 하나의 마스터와 최소한 하나의 노드가 있는 OpenShift Container Platform 클러스터와 클러스터에 대한 네트워크 액세스 권한이 있는 클러스터 외부 시스템이 있습니다. 이 절차에서는 외부 시스템이 클러스터와 동일한 서브넷에 있다고 가정합니다. 다른 서브넷에 있는 외부 시스템에 필요한 추가 네트워킹은 이 주제에서 다루지 않습니다.
2.3.3. 프로젝트 및 서비스 생성 링크 복사링크가 클립보드에 복사되었습니다!
공개하려는 프로젝트와 서비스가 존재하지 않는 경우 프로젝트를 생성한 다음 서비스를 생성하세요.
프로젝트와 서비스가 이미 존재하는 경우 서비스를 노출하여 경로를 생성하는 절차로 건너뜁니다.
사전 요구 사항
-
OpenShift CLI(
oc
)를 설치하고 클러스터 관리자로 로그인합니다.
프로세스
oc new-project
명령을 실행하여 서비스에 대한 새 프로젝트를 만듭니다.oc new-project <project_name>
$ oc new-project <project_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc new-app
명령을 사용하여 서비스를 생성합니다.oc new-app nodejs:12~https://github.com/sclorg/nodejs-ex.git
$ oc new-app nodejs:12~https://github.com/sclorg/nodejs-ex.git
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 서비스가 생성되었는지 확인하려면 다음 명령을 실행하세요.
oc get svc -n <project_name>
$ oc get svc -n <project_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE nodejs-ex ClusterIP 172.30.197.157 <none> 8080/TCP 70s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE nodejs-ex ClusterIP 172.30.197.157 <none> 8080/TCP 70s
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고기본적으로 새 서비스에는 외부 IP 주소가 없습니다.
2.3.4. 경로를 생성하여 서비스 노출 링크 복사링크가 클립보드에 복사되었습니다!
oc expose
명령을 사용하여 서비스를 경로로 노출할 수 있습니다.
사전 요구 사항
- OpenShift Container Platform에 로그인했습니다.
프로세스
노출하려는 서비스가 있는 프로젝트에 로그인합니다.
oc project <project_name>
$ oc project <project_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc expose service
명령을 실행하여 경로를 노출합니다.oc expose service nodejs-ex
$ oc expose service nodejs-ex
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
route.route.openshift.io/nodejs-ex exposed
route.route.openshift.io/nodejs-ex exposed
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 서비스가 노출되었는지 확인하려면
curl
과 같은 도구를 사용하여 클러스터 외부에서 서비스에 액세스할 수 있는지 확인할 수 있습니다.경로의 호스트 이름을 찾으려면 다음 명령을 입력하세요.
oc get route
$ oc get route
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD nodejs-ex nodejs-ex-myproject.example.com nodejs-ex 8080-tcp None
NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD nodejs-ex nodejs-ex-myproject.example.com nodejs-ex 8080-tcp None
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 호스트가 GET 요청에 응답하는지 확인하려면 다음 명령을 입력하세요.
curl
명령 예시curl --head nodejs-ex-myproject.example.com
$ curl --head nodejs-ex-myproject.example.com
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
HTTP/1.1 200 OK ...
HTTP/1.1 200 OK ...
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.3.5. OpenShift 컨테이너 플랫폼의 Ingress 샤딩 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Container Platform에서 Ingress Controller는 모든 경로를 제공할 수도 있고 경로의 하위 집합을 제공할 수도 있습니다. 기본적으로 Ingress Controller는 클러스터의 모든 네임스페이스에서 생성된 모든 경로를 제공합니다. 클러스터에 추가 Ingress 컨트롤러를 추가하여 선택한 특성에 따라 경로의 하위 집합인 샤드를 생성하여 라우팅을 최적화할 수 있습니다. 샤드의 멤버로 경로를 표시하려면 경로 또는 네임스페이스 메타데이터
필드에 레이블을 사용합니다. Ingress Controller는 선택 표현식 이라고도 하는 선택기를 사용하여 전체 경로 풀에서 제공할 경로의 하위 집합을 선택합니다.
Ingress 샤딩은 여러 Ingress 컨트롤러에 걸쳐 들어오는 트래픽의 부하를 분산하려는 경우, 트래픽을 특정 Ingress 컨트롤러로 라우팅하려는 경우 또는 다음 섹션에서 설명하는 다양한 다른 이유로 유용합니다.
기본적으로 각 경로는 클러스터의 기본 도메인을 사용합니다. 하지만 라우터의 도메인을 사용하도록 경로를 구성할 수 있습니다.
2.3.6. Ingress 컨트롤러 분할 링크 복사링크가 클립보드에 복사되었습니다!
Ingress 샤딩(라우터 샤딩이라고도 함)을 사용하면 경로, 네임스페이스 또는 둘 다에 레이블을 추가하여 여러 라우터에 걸쳐 경로 세트를 분산할 수 있습니다. Ingress Controller는 해당 선택기 세트를 사용하여 지정된 레이블이 있는 경로만 허용합니다. 각 Ingress 샤드는 주어진 선택 표현식을 사용하여 필터링된 경로로 구성됩니다.
트래픽이 클러스터에 진입하는 주요 메커니즘으로 인해 Ingress Controller에 대한 요구 사항이 상당할 수 있습니다. 클러스터 관리자는 다음을 위해 경로를 분할할 수 있습니다.
- 여러 경로를 갖춘 Ingress 컨트롤러 또는 라우터를 균형 있게 조정하여 변경 사항에 대한 대응 속도를 높입니다.
- 특정 경로에 다른 경로보다 다른 신뢰성 보장을 할당합니다.
- 특정 Ingress 컨트롤러에 다른 정책을 정의할 수 있도록 허용
- 특정 경로만 추가 기능을 사용하도록 허용
- 예를 들어, 내부 및 외부 사용자가 다른 경로를 볼 수 있도록 다른 주소에 다른 경로를 노출
- 블루-그린 배포 중에 애플리케이션의 한 버전에서 다른 버전으로 트래픽을 전송합니다.
Ingress 컨트롤러가 분할되면 주어진 경로는 그룹 내의 0개 이상의 Ingress 컨트롤러에 허용됩니다. 경로 상태는 Ingress Controller가 경로를 승인했는지 여부를 나타냅니다. Ingress Controller는 경로가 샤드에 고유한 경우에만 경로를 허용합니다.
샤딩을 사용하면 경로 하위 집합을 여러 Ingress 컨트롤러에 분산할 수 있습니다. 이러한 하위 집합은 겹치지 않는 샤딩( 기존 샤딩이라고도 함)이거나 겹치는 샤딩( 중첩 샤딩이라고도 함)일 수 있습니다.
다음 표는 세 가지 샤딩 방법을 간략하게 설명합니다.
샤딩 방식 | 설명 |
---|---|
네임스페이스 선택기 | Ingress 컨트롤러에 네임스페이스 선택기를 추가하면 네임스페이스 선택기에 일치하는 레이블이 있는 네임스페이스의 모든 경로가 Ingress 샤드에 포함됩니다. 네임스페이스에서 생성된 모든 경로를 Ingress Controller가 처리하는 경우 이 방법을 고려하세요. |
경로 선택기 | Ingress 컨트롤러에 경로 선택기를 추가하면 경로 선택기와 일치하는 레이블이 있는 모든 경로가 Ingress 샤드에 포함됩니다. 네임스페이스의 특정 경로나 경로의 하위 집합만 처리하려는 경우 Ingress Controller를 고려하세요. |
네임스페이스 및 경로 선택기 | 네임스페이스 선택기와 경로 선택기 메서드 모두에 대한 Ingress Controller 범위를 제공합니다. 네임스페이스 선택기와 경로 선택기 방법 모두의 유연성이 필요한 경우 이 방법을 고려하세요. |
2.3.6.1. 기존 샤딩 예시 링크 복사링크가 클립보드에 복사되었습니다!
키 값이 finance
및 ops
로 설정된 레이블 선택기 spec.namespaceSelector.matchExpressions
를 갖는 구성된 Ingress Controller finops-router
의 예:
finops-router
에 대한 YAML 정의 예
레이블 선택기 spec.namespaceSelector.matchLabels.name
과 키 값이 dev
로 설정된 구성된 Ingress Controller dev-router
의 예:
dev-router
에 대한 YAML 정의 예
모든 애플리케이션 경로가 별도의 네임스페이스에 있는 경우(예 : name:finance
, name:ops
, name:dev
로 레이블 지정) 구성은 경로를 두 Ingress 컨트롤러 간에 효과적으로 분산합니다. 콘솔, 인증 및 기타 목적을 위한 OpenShift Container Platform 경로는 처리해서는 안 됩니다.
이전 시나리오에서 샤딩은 겹치는 하위 집합이 없는 특수한 분할 사례가 됩니다. 경로는 라우터 샤드 사이에 나뉩니다.
기본
Ingress Controller는 namespaceSelector
또는 routeSelector
필드에 제외할 경로가 포함되어 있지 않는 한 모든 경로를 계속 처리합니다. 기본 Ingress 컨트롤러에서 경로를 제외하는 방법에 대한 자세한 내용은 Red Hat Knowledgebase 솔루션 과 "기본 Ingress 컨트롤러 분할" 섹션을 참조하세요.
2.3.6.2. 중첩된 샤딩 예제 링크 복사링크가 클립보드에 복사되었습니다!
레이블 선택기 spec.namespaceSelector.matchExpressions
와 키 값이 dev
및 ops
로 설정된 구성된 Ingress Controller devops-router
의 예:
devops-router
에 대한 YAML 정의 예시
name:dev
및 name:ops로
라벨이 지정된 네임스페이스의 경로는 이제 두 개의 서로 다른 Ingress 컨트롤러에서 서비스됩니다. 이 구성을 사용하면 경로의 하위 집합이 겹치게 됩니다.
중복되는 경로 하위 집합을 사용하면 더 복잡한 라우팅 규칙을 만들 수 있습니다. 예를 들어, 우선순위가 높은 트래픽을 전용 finops-router
로 전환하고, 우선순위가 낮은 트래픽을 devops-router
로 보낼 수 있습니다.
2.3.6.3. 기본 Ingress 컨트롤러 분할 링크 복사링크가 클립보드에 복사되었습니다!
새로운 Ingress 샤드를 생성한 후에는 기본 Ingress 컨트롤러에서도 허용되는 경로가 새로운 Ingress 샤드에 허용될 수 있습니다. 이는 기본 Ingress Controller에 선택기가 없고 기본적으로 모든 경로를 허용하기 때문입니다.
네임스페이스 선택기나 경로 선택기를 사용하여 Ingress Controller가 특정 레이블이 있는 경로를 서비스하지 못하도록 제한할 수 있습니다. 다음 절차에서는 네임스페이스 선택기를 사용하여 새로 분할된 finance
, ops
, dev
경로에 대한 기본 Ingress Controller의 서비스를 제한합니다. 이렇게 하면 Ingress 샤드에 추가적인 격리가 추가됩니다.
OpenShift Container Platform의 모든 관리 경로를 동일한 Ingress Controller에 유지해야 합니다. 따라서 이러한 필수 경로를 제외하는 추가 선택기를 기본 Ingress 컨트롤러에 추가하지 마세요.
사전 요구 사항
-
OpenShift CLI(
oc
)를 설치합니다. - 프로젝트 관리자로 로그인했습니다.
프로세스
다음 명령을 실행하여 기본 Ingress 컨트롤러를 수정합니다.
oc edit ingresscontroller -n openshift-ingress-operator default
$ oc edit ingresscontroller -n openshift-ingress-operator default
Copy to Clipboard Copied! Toggle word wrap Toggle overflow finance
,ops
,dev
레이블이 있는 경로를 제외하는namespaceSelector를
포함하도록 Ingress Controller를 편집합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
기본 Ingress Controller는 더 이상 name:finance
, name:ops
, name:dev로
라벨이 지정된 네임스페이스를 제공하지 않습니다.
2.3.6.4. Ingress 샤딩 및 DNS 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 관리자는 프로젝트의 각 라우터에 대해 별도의 DNS 항목을 만드는 일을 담당합니다. 라우터는 알 수 없는 경로를 다른 라우터로 전달하지 않습니다.
다음 예를 살펴보세요.
-
라우터 A는 호스트 192.168.0.5에 있으며
*.foo.com을
포함하는 경로를 가지고 있습니다. -
라우터 B는 호스트 192.168.1.9에 있으며
*.example.com을
포함하는 경로를 가지고 있습니다.
별도의 DNS 항목은 *.foo.com을
라우터 A를 호스팅하는 노드로 확인하고 *.example.com을
라우터 B를 호스팅하는 노드로 확인해야 합니다.
-
*.foo.com A IN 192.168.0.5
-
*.example.com A IN 192.168.1.9
2.3.6.5. 경로 라벨을 사용하여 Ingress 컨트롤러 분할 구성 링크 복사링크가 클립보드에 복사되었습니다!
경로 라벨을 사용한 Ingress 컨트롤러 분할이란 Ingress 컨트롤러가 경로 선택기에서 선택한 모든 네임스페이스의 모든 경로를 제공한다는 뜻입니다.
그림 2.1. 경로 레이블을 사용한 Ingress 샤딩
Ingress 컨트롤러 분할은 들어오는 트래픽 부하를 일련의 Ingress 컨트롤러에 균형 있게 분배하고 트래픽을 특정 Ingress 컨트롤러에 격리할 때 유용합니다. 예를 들어, 회사 A는 하나의 Ingress 컨트롤러로, 회사 B는 다른 Ingress 컨트롤러로 이동합니다.
프로세스
router-internal.yaml
파일을 다음과 같이 편집합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Ingress Controller에서 사용할 도메인을 지정합니다. 이 도메인은 기본 Ingress Controller 도메인과 달라야 합니다.
Ingress 컨트롤러
router-internal.yaml
파일을 적용합니다.oc apply -f router-internal.yaml
# oc apply -f router-internal.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Ingress 컨트롤러는
type: sharded
라벨이 있는 네임스페이스에서 경로를 선택합니다.router-internal.yaml
에 구성된 도메인을 사용하여 새로운 경로를 만듭니다.oc expose svc <service-name> --hostname <route-name>.apps-sharded.basedomain.example.net
$ oc expose svc <service-name> --hostname <route-name>.apps-sharded.basedomain.example.net
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.3.6.6. 네임스페이스 라벨을 사용하여 Ingress 컨트롤러 분할 구성 링크 복사링크가 클립보드에 복사되었습니다!
네임스페이스 라벨을 사용한 Ingress 컨트롤러 분할이란 Ingress 컨트롤러가 네임스페이스 선택기에서 선택한 모든 네임스페이스의 모든 경로를 제공한다는 뜻입니다.
그림 2.2. 네임스페이스 레이블을 사용한 Ingress 샤딩
Ingress 컨트롤러 분할은 들어오는 트래픽 부하를 일련의 Ingress 컨트롤러에 균형 있게 분배하고 트래픽을 특정 Ingress 컨트롤러에 격리할 때 유용합니다. 예를 들어, 회사 A는 하나의 Ingress 컨트롤러로, 회사 B는 다른 Ingress 컨트롤러로 이동합니다.
프로세스
router-internal.yaml
파일을 다음과 같이 편집합니다.cat router-internal.yaml
$ cat router-internal.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Ingress Controller에서 사용할 도메인을 지정합니다. 이 도메인은 기본 Ingress Controller 도메인과 달라야 합니다.
Ingress 컨트롤러
router-internal.yaml
파일을 적용합니다.oc apply -f router-internal.yaml
$ oc apply -f router-internal.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Ingress 컨트롤러는 네임스페이스 선택기에서 선택한
type: sharded
라벨이 있는 네임스페이스에서 경로를 선택합니다.router-internal.yaml
에 구성된 도메인을 사용하여 새로운 경로를 만듭니다.oc expose svc <service-name> --hostname <route-name>.apps-sharded.basedomain.example.net
$ oc expose svc <service-name> --hostname <route-name>.apps-sharded.basedomain.example.net
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.3.6.7. Ingress Controller 샤딩을 위한 경로 생성 링크 복사링크가 클립보드에 복사되었습니다!
경로를 사용하면 URL에서 애플리케이션을 호스팅할 수 있습니다. Ingress 컨트롤러 분할은 여러 Ingress 컨트롤러 간에 들어오는 트래픽 부하를 균형 있게 조절하는 데 도움이 됩니다. 또한 특정 Ingress Controller로 트래픽을 격리할 수도 있습니다. 예를 들어, 회사 A는 하나의 Ingress 컨트롤러로, 회사 B는 다른 Ingress 컨트롤러로 이동합니다.
다음 절차에서는 hello-openshift
애플리케이션을 예로 들어 Ingress Controller 샤딩에 대한 경로를 만드는 방법을 설명합니다.
사전 요구 사항
-
OpenShift CLI(
oc
)를 설치합니다. - 프로젝트 관리자로 로그인했습니다.
- 포트와 해당 포트의 트래픽을 수신하는 HTTP 또는 TLS 엔드포인트를 노출하는 웹 애플리케이션이 있습니다.
- 샤딩을 위해 Ingress Controller를 구성했습니다.
프로세스
다음 명령을 실행하여
hello-openshift
라는 프로젝트를 만듭니다.oc new-project hello-openshift
$ oc new-project hello-openshift
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 프로젝트에 포드를 만듭니다.
oc create -f https://raw.githubusercontent.com/openshift/origin/master/examples/hello-openshift/hello-pod.json
$ oc create -f https://raw.githubusercontent.com/openshift/origin/master/examples/hello-openshift/hello-pod.json
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
hello-openshift
라는 서비스를 만듭니다.oc expose pod/hello-openshift
$ oc expose pod/hello-openshift
Copy to Clipboard Copied! Toggle word wrap Toggle overflow hello-openshift-route.yaml
이라는 경로 정의를 만듭니다.샤딩을 위해 생성된 경로의 YAML 정의
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
hello-openshift-route.yaml을
사용하여hello-openshift
애플리케이션에 대한 경로를 만듭니다.oc -n hello-openshift create -f hello-openshift-route.yaml
$ oc -n hello-openshift create -f hello-openshift-route.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
다음 명령을 사용하여 경로 상태를 확인하세요.
oc -n hello-openshift get routes/hello-openshift-edge -o yaml
$ oc -n hello-openshift get routes/hello-openshift-edge -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 결과적으로 생성된
Route
리소스는 다음과 유사해야 합니다.출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Ingress 컨트롤러 또는 라우터가 경로를 노출하는 데 사용하는 호스트 이름입니다.
호스트
필드의 값은 Ingress Controller에 의해 자동으로 결정되며 해당 도메인을 사용합니다. 이 예에서 Ingress Controller의 도메인은<apps-sharded.basedomain.example.net>
입니다. - 2
- Ingress Controller의 호스트 이름입니다. 호스트 이름이 설정되지 않으면 경로는 대신 하위 도메인을 사용할 수 있습니다. 하위 도메인을 지정하면 경로를 노출하는 Ingress Controller의 도메인이 자동으로 사용됩니다. 경로가 여러 Ingress 컨트롤러에 의해 노출되는 경우 해당 경로는 여러 URL에서 호스팅됩니다.
- 3
- Ingress Controller의 이름입니다. 이 예에서 Ingress Controller의 이름은
sharded
입니다.