홈
제품
OpenShift Container Platform
4.19
수신 및 부하 분산

수신 및 부하 분산

OpenShift Container Platform 4.19

OpenShift Container Platform에서 서비스 노출 및 외부 트래픽 관리

Red Hat OpenShift Documentation Team

초록

이 문서에서는 OpenShift Container Platform에서 경로를 구성하고, 수신 트래픽을 관리하고, 다양한 부하 분산 솔루션을 구현하는 방법을 설명합니다.

경로를 사용하면 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 Toggle word wrap

다음 명령을 실행하여 프로젝트에 포드를 만듭니다.

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

Toggle word wrap

다음 명령을 실행하여 hello-openshift 라는 서비스를 만듭니다.
```
oc expose pod/hello-openshift
```
```
$ oc expose pod/hello-openshift
```
Copy to Clipboard Toggle word wrap
hello-openshift-route.yaml 이라는 경로 정의를 만듭니다.
샤딩을 위해 생성된 경로의 YAML 정의
```
apiVersion: route.openshift.io/v1
kind: Route
metadata:
  labels:
    type: sharded 
  name: hello-openshift-edge
  namespace: hello-openshift
spec:
  subdomain: hello-openshift 
  tls:
    termination: edge
  to:
    kind: Service
    name: hello-openshift
```
```
apiVersion: route.openshift.io/v1
kind: Route
metadata:
  labels:
    type: sharded 
```
1
```
  name: hello-openshift-edge
  namespace: hello-openshift
spec:
  subdomain: hello-openshift 
```
2
```
  tls:
    termination: edge
  to:
    kind: Service
    name: hello-openshift
```
Copy to Clipboard Toggle word wrap
1
레이블 키와 해당 레이블 값은 모두 Ingress Controller에 지정된 것과 일치해야 합니다. 이 예에서 Ingress Controller에는 레이블 키와 값 유형이 있습니다: sharded .
2
경로는 하위 도메인 필드의 값을 사용하여 노출됩니다. 하위 도메인 필드를 지정할 때는 호스트 이름을 설정하지 않아야 합니다. 호스트 와 하위 도메인 필드를 모두 지정하면 경로는 호스트 필드의 값을 사용하고 하위 도메인 필드는 무시합니다.
다음 명령을 실행하여 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 Toggle word wrap

검증

다음 명령을 사용하여 경로 상태를 확인하세요.

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

Toggle word wrap

결과적으로 생성된 Route 리소스는 다음과 유사해야 합니다.

출력 예

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  labels:
    type: sharded
  name: hello-openshift-edge
  namespace: hello-openshift
spec:
  subdomain: hello-openshift
  tls:
    termination: edge
  to:
    kind: Service
    name: hello-openshift
status:
  ingress:
  - host: hello-openshift.<apps-sharded.basedomain.example.net> 
    routerCanonicalHostname: router-sharded.<apps-sharded.basedomain.example.net> 
    routerName: sharded

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  labels:
    type: sharded
  name: hello-openshift-edge
  namespace: hello-openshift
spec:
  subdomain: hello-openshift
  tls:
    termination: edge
  to:
    kind: Service
    name: hello-openshift
status:
  ingress:
  - host: hello-openshift.<apps-sharded.basedomain.example.net>


    routerCanonicalHostname: router-sharded.<apps-sharded.basedomain.example.net>


    routerName: sharded

Copy to Clipboard

Toggle word wrap

1: Ingress 컨트롤러 또는 라우터가 경로를 노출하는 데 사용하는 호스트 이름입니다. 호스트 필드의 값은 Ingress Controller에 의해 자동으로 결정되며 해당 도메인을 사용합니다. 이 예에서 Ingress Controller의 도메인은 <apps-sharded.basedomain.example.net> 입니다.
2: Ingress Controller의 호스트 이름입니다. 호스트 이름이 설정되지 않으면 경로는 대신 하위 도메인을 사용할 수 있습니다. 하위 도메인을 지정하면 경로를 노출하는 Ingress Controller의 도메인이 자동으로 사용됩니다. 경로가 여러 Ingress 컨트롤러에 의해 노출되는 경우 해당 경로는 여러 URL에서 호스팅됩니다.
3: Ingress Controller의 이름입니다. 이 예에서 Ingress Controller의 이름은 sharded 입니다.

1.1.3. 경로 시간 초과 구성
링크 복사

SLA(Service Level Availability) 목적에 필요한 낮은 시간 초과 또는 백엔드가 느린 경우 높은 시간 초과가 필요한 서비스가 있는 경우 기존 경로에 대한 기본 시간 초과를 구성할 수 있습니다.

중요

OpenShift Container Platform 클러스터 앞에 사용자 관리 외부 로드 밸런서를 구성한 경우 사용자 관리 외부 로드 밸런서의 시간 초과 값이 경로의 시간 초과 값보다 높아야 합니다. 이 구성은 클러스터가 사용하는 네트워크에서 네트워크 혼잡 문제가 발생하는 것을 방지합니다.

사전 요구 사항

실행 중인 클러스터에 배포된 Ingress 컨트롤러가 필요합니다.

프로세스

oc annotate 명령을 사용하여 경로에 시간 초과를 추가합니다.
```
oc annotate route <route_name> \
    --overwrite haproxy.router.openshift.io/timeout=<timeout><time_unit>
```
```
$ oc annotate route <route_name> \
    --overwrite haproxy.router.openshift.io/timeout=<timeout><time_unit> 
```
1
Copy to Clipboard Toggle word wrap
1
지원되는 시간 단위는 마이크로초(us), 밀리초(ms), 초(s), 분(m), 시간(h) 또는 일(d)입니다.
다음 예제는 이름이 myroute인 경로에서 2초의 시간 초과를 설정합니다.
```
oc annotate route myroute --overwrite haproxy.router.openshift.io/timeout=2s
```
```
$ oc annotate route myroute --overwrite haproxy.router.openshift.io/timeout=2s
```
Copy to Clipboard Toggle word wrap

1.1.4. HSTS(HTTP Strict Transport Security)
링크 복사

HSTS(HTTP Strict Transport Security) 정책은 라우트 호스트에서 HTTPS 트래픽만 허용됨을 브라우저 클라이언트에 알리는 보안 강화 정책입니다. 또한 HSTS는 HTTP 리디렉션을 사용하지 않고 HTTPS 전송 신호를 통해 웹 트래픽을 최적화합니다. HSTS는 웹사이트와의 상호 작용을 가속화하는 데 유용합니다.

HSTS 정책이 적용되면 HSTS는 사이트의 HTTP 및 HTTPS 응답에 Strict Transport Security 헤더를 추가합니다. 경로에서 insecureEdgeTerminationPolicy 값을 사용하여 HTTP를 HTTPS로 리디렉션할 수 있습니다. HSTS를 적용하면 클라이언트는 요청을 전송하기 전에 HTTP URL의 모든 요청을 HTTPS로 변경하여 리디렉션이 필요하지 않습니다.

클러스터 관리자는 다음을 수행하도록 HSTS를 구성할 수 있습니다.

경로당 HSTS 활성화
라우팅당 HSTS 비활성화
도메인당 HSTS 시행, 도메인 집합 또는 도메인과 함께 네임스페이스 라벨 사용

중요

HSTS는 보안 경로(엣지 종료 또는 재암호화)에서만 작동합니다. HTTP 또는 패스스루(passthrough) 경로에서는 구성이 유효하지 않습니다.

1.1.4.1. 라우팅당 HSTS(HTTP Strict Transport Security) 활성화
링크 복사

HSTS(HTTP Strict Transport Security)는 HAProxy 템플릿에 구현되고 haproxy.router.openshift.io/hsts_header 주석이 있는 에지 및 재암호화 경로에 적용됩니다.

사전 요구 사항

프로젝트에 대한 관리자 권한이 있는 사용자로 클러스터에 로그인했습니다.
OpenShift CLI(oc)를 설치합니다.

프로세스

경로에서 HSTS를 활성화하려면 haproxy.router.openshift.io/hsts_header 값을 에지 종료 또는 재암호화 경로에 추가합니다. 다음 명령을 실행하여 oc annotate 도구를 사용하면 됩니다. 명령을 올바르게 실행하려면 haproxy.router.openshift.io/hsts_header 경로 주석의 세미콜론( ; )도 큰따옴표( "" )로 묶어야 합니다.
최대 연령을 31536000ms (약 8.5시간)로 설정하는 주석 명령의 예
```
oc annotate route <route_name> -n <namespace> --overwrite=true "haproxy.router.openshift.io/hsts_header=max-age=31536000;\
includeSubDomains;preload"
```
```
$ oc annotate route <route_name> -n <namespace> --overwrite=true "haproxy.router.openshift.io/hsts_header=max-age=31536000;\
includeSubDomains;preload"
```
Copy to Clipboard Toggle word wrap
주석으로 구성된 경로 예
```
apiVersion: route.openshift.io/v1
kind: Route
metadata:
  annotations:
    haproxy.router.openshift.io/hsts_header: max-age=31536000;includeSubDomains;preload   
# ...
spec:
  host: def.abc.com
  tls:
    termination: "reencrypt"
    ...
  wildcardPolicy: "Subdomain"
# ...
```
```
apiVersion: route.openshift.io/v1
kind: Route
metadata:
  annotations:
    haproxy.router.openshift.io/hsts_header: max-age=31536000;includeSubDomains;preload 
```
1
```
 
```
2
```
 
```
3
```
# ...
spec:
  host: def.abc.com
  tls:
    termination: "reencrypt"
    ...
  wildcardPolicy: "Subdomain"
# ...
```
Copy to Clipboard Toggle word wrap
1
필수 항목입니다. Max-age는 HSTS 정책이 적용되는 시간(초)을 측정합니다. 0으로 설정하면 정책이 무효화됩니다.
2
선택 사항: 포함되는 경우 includeSubDomains는 호스트의 모든 하위 도메인에 호스트와 동일한 HSTS 정책이 있어야 함을 알려줍니다.
3
선택 사항: max-age가 0보다 크면 haproxy.router.openshift.io/hsts_header에 preload를 추가하여 외부 서비스에서 이 사이트를 HSTS 사전 로드 목록에 포함할 수 있습니다. 예를 들어 Google과 같은 사이트는 preload가 설정된 사이트 목록을 구성할 수 있습니다. 그런 다음 브라우저는 이 목록을 사용하여 사이트와 상호 작용하기 전에 HTTPS를 통해 통신할 수 있는 사이트를 결정할 수 있습니다. preload를 설정하지 않으면 브라우저가 HTTPS를 통해 사이트와 상호 작용하여 헤더를 가져와야 합니다.

1.1.4.2. 라우팅당 HSTS(HTTP Strict Transport Security) 비활성화
링크 복사

경로당 HSTS(HTTP Strict Transport Security)를 비활성화하려면 경로 주석에서 max-age 값을 0으로 설정할 수 있습니다.

사전 요구 사항

프로젝트에 대한 관리자 권한이 있는 사용자로 클러스터에 로그인했습니다.
OpenShift CLI(oc)를 설치합니다.

프로세스

HSTS를 비활성화하려면 다음 명령을 입력하여 경로 주석의 max-age 값을 0으로 설정합니다.

oc annotate route <route_name> -n <namespace> --overwrite=true "haproxy.router.openshift.io/hsts_header"="max-age=0"

$ oc annotate route <route_name> -n <namespace> --overwrite=true "haproxy.router.openshift.io/hsts_header"="max-age=0"

Copy to Clipboard

Toggle word wrap

작은 정보

다음 YAML을 적용하여 구성 맵을 만들 수 있습니다.

경로당 HSTS 비활성화 예

metadata:
  annotations:
    haproxy.router.openshift.io/hsts_header: max-age=0

metadata:
  annotations:
    haproxy.router.openshift.io/hsts_header: max-age=0

Copy to Clipboard

Toggle word wrap

네임스페이스의 모든 경로에 대해 HSTS를 비활성화하려면 다음 명령을 입력하세요.

oc annotate route --all -n <namespace> --overwrite=true "haproxy.router.openshift.io/hsts_header"="max-age=0"

$ oc annotate route --all -n <namespace> --overwrite=true "haproxy.router.openshift.io/hsts_header"="max-age=0"

Copy to Clipboard

Toggle word wrap

검증

모든 경로에 대한 주석을 쿼리하려면 다음 명령을 입력합니다.

oc get route  --all-namespaces -o go-template='{{range .items}}{{if .metadata.annotations}}{{$a := index .metadata.annotations "haproxy.router.openshift.io/hsts_header"}}{{$n := .metadata.name}}{{with $a}}Name: {{$n}} HSTS: {{$a}}{{"\n"}}{{else}}{{""}}{{end}}{{end}}{{end}}'

$ oc get route  --all-namespaces -o go-template='{{range .items}}{{if .metadata.annotations}}{{$a := index .metadata.annotations "haproxy.router.openshift.io/hsts_header"}}{{$n := .metadata.name}}{{with $a}}Name: {{$n}} HSTS: {{$a}}{{"\n"}}{{else}}{{""}}{{end}}{{end}}{{end}}'

Copy to Clipboard

Toggle word wrap

출력 예

Name: routename HSTS: max-age=0

Name: routename HSTS: max-age=0

Copy to Clipboard

Toggle word wrap

1.1.4.3. 도메인별 HSTS(HTTP Strict Transport Security) 적용
링크 복사

도메인당 HSTS(HTTP Strict Transport Security)를 적용하여 보안 경로에 requiredHSTSPolicies 레코드를 Ingress 사양에 추가하여 HSTS 정책 구성을 캡처합니다.

HSTS를 적용하도록 requiredHSTSPolicy를 구성하는 경우 규정 준수 HSTS 정책 주석을 사용하여 새로 생성된 경로를 구성해야 합니다.

참고

준수하지 않는 HSTS 경로를 사용하여 업그레이드된 클러스터를 처리하려면 소스에서 매니페스트를 업데이트하고 업데이트를 적용할 수 있습니다.

참고

oc expose route 또는 oc create route 명령을 사용하여 이러한 명령의 API에서 주석을 수락하지 않기 때문에 HSTS를 적용하는 도메인에 경로를 추가할 수 없습니다.

중요

HSTS가 모든 경로에 대해 글로벌하게 요청된 경우에도, HSTS는 안전하지 않은 경로나 TLS가 아닌 경로에는 적용될 수 없습니다.

사전 요구 사항

프로젝트에 대한 관리자 권한이 있는 사용자로 클러스터에 로그인했습니다.
OpenShift CLI(oc)를 설치합니다.

프로세스

다음 명령을 실행하고 필요에 따라 필드를 업데이트하여 Ingress 구성 YAML을 편집합니다.
```
oc edit ingresses.config.openshift.io/cluster
```
```
$ oc edit ingresses.config.openshift.io/cluster
```
Copy to Clipboard Toggle word wrap
HSTS 정책 예
```
apiVersion: config.openshift.io/v1
kind: Ingress
metadata:
  name: cluster
spec:
  domain: 'hello-openshift-default.apps.username.devcluster.openshift.com'
  requiredHSTSPolicies: 
  - domainPatterns: 
    - '*hello-openshift-default.apps.username.devcluster.openshift.com'
    - '*hello-openshift-default2.apps.username.devcluster.openshift.com'
    namespaceSelector: 
      matchLabels:
        myPolicy: strict
    maxAge: 
      smallestMaxAge: 1
      largestMaxAge: 31536000
    preloadPolicy: RequirePreload 
    includeSubDomainsPolicy: RequireIncludeSubDomains 
  - domainPatterns:
    - 'abc.example.com'
    - '*xyz.example.com'
    namespaceSelector:
      matchLabels: {}
    maxAge: {}
    preloadPolicy: NoOpinion
    includeSubDomainsPolicy: RequireNoIncludeSubDomains
```
```
apiVersion: config.openshift.io/v1
kind: Ingress
metadata:
  name: cluster
spec:
  domain: 'hello-openshift-default.apps.username.devcluster.openshift.com'
  requiredHSTSPolicies: 
```
1
```
  - domainPatterns: 
```
2
```
    - '*hello-openshift-default.apps.username.devcluster.openshift.com'
    - '*hello-openshift-default2.apps.username.devcluster.openshift.com'
    namespaceSelector: 
```
3
```
      matchLabels:
        myPolicy: strict
    maxAge: 
```
4
```
      smallestMaxAge: 1
      largestMaxAge: 31536000
    preloadPolicy: RequirePreload 
```
5
```
    includeSubDomainsPolicy: RequireIncludeSubDomains 
```
6
```
  - domainPatterns:
    - 'abc.example.com'
    - '*xyz.example.com'
    namespaceSelector:
      matchLabels: {}
    maxAge: {}
    preloadPolicy: NoOpinion
    includeSubDomainsPolicy: RequireNoIncludeSubDomains
```
Copy to Clipboard Toggle word wrap
1
필수 항목입니다. requiredHSTSPolicies는 순서대로 검증되고 일치하는 첫 번째 domainPatterns가 적용됩니다.
2
필수 항목입니다. 하나 이상의 domainPatterns 호스트 이름을 지정해야 합니다. 도메인 수를 나열할 수 있습니다. 다른 domainPatterns에 대한 적용 옵션의 여러 섹션을 포함할 수 있습니다.
3
선택 사항: namespaceSelector를 포함하는 경우 경로가 있는 프로젝트의 레이블과 일치하여 경로에 설정된 HSTS 정책을 적용해야 합니다. namespaceSelector만 일치하고 domainPatterns와 일치하지 않는 경로는 검증되지 않습니다.
4
필수 항목입니다. Max-age는 HSTS 정책이 적용되는 시간(초)을 측정합니다. 이 정책 설정을 사용하면 최소 및 최대 max-age를 적용할 수 있습니다.
largestMaxAge 값은 0에서 2147483647 사이여야 합니다. 지정되지 않은 상태로 둘 수 있습니다. 즉, 상한이 적용되지 않습니다.
smallestMaxAge 값은 0에서 2147483647 사이여야 합니다. 문제 해결을 위해 HSTS를 비활성화하려면 0을 입력합니다. HSTS를 비활성화하지 않으려면 1을 입력합니다. 지정되지 않은 상태로 둘 수 있습니다. 즉, 더 낮은 제한이 적용되지 않습니다.
5
선택 사항: haproxy.router.openshift.io/hsts_header에 preload를 포함하면 외부 서비스에서 이 사이트를 HSTS 사전 로드 목록에 포함할 수 있습니다. 그런 다음 브라우저는 이 목록을 사용하여 사이트와 상호 작용하기 전에 HTTPS를 통해 통신할 수 있는 사이트를 결정할 수 있습니다. preload를 설정하지 않으면 브라우저가 헤더를 얻기 위해 사이트와 한 번 이상 상호 작용해야 합니다. 다음 중 하나로 preload를 설정할 수 있습니다.
RequirePreload: RequiredHSTSPolicy에 preload가 필요합니다.
RequireNoPreload: RequiredHSTSPolicy에서 preload를 금지합니다.
NoOpinion:preload는 RequiredHSTSPolicy에 중요하지 않습니다.
6
선택 사항: includeSubDomainsPolicy는 다음 중 하나를 사용하여 설정할 수 있습니다.
RequireIncludeSubDomains:includeSubDomains는 RequiredHSTSPolicy에 필요합니다.
RequireNoIncludeSubDomains:includeSubDomains는 RequiredHSTSPolicy에서 금지합니다.
NoOpinion:includeSubDomains는 RequiredHSTSPolicy와 관련이 없습니다.
oc annotate command를 입력하여 클러스터 또는 특정 네임스페이스에 HSTS를 적용할 수 있습니다.
- 클러스터의 모든 경로에 HSTS를 적용하려면 oc annotate command를 입력합니다. 예를 들면 다음과 같습니다.
  $ oc annotate route --all --all-namespaces --overwrite=true "haproxy.router.openshift.io/hsts_header"="max-age=31536000"
  Copy to Clipboard Toggle word wrap
- 특정 네임스페이스의 모든 경로에 HSTS를 적용하려면 oc annotate command를 입력합니다. 예를 들면 다음과 같습니다.
  $ oc annotate route --all -n my-namespace --overwrite=true "haproxy.router.openshift.io/hsts_header"="max-age=31536000"
  Copy to Clipboard Toggle word wrap

검증

구성한 HSTS 정책을 검토할 수 있습니다. 예를 들면 다음과 같습니다.

필요한 HSTS 정책에 대한 maxAge 세트를 검토하려면 다음 명령을 입력합니다.

oc get clusteroperator/ingress -n openshift-ingress-operator -o jsonpath='{range .spec.requiredHSTSPolicies[*]}{.spec.requiredHSTSPolicies.maxAgePolicy.largestMaxAge}{"\n"}{end}'

$ oc get clusteroperator/ingress -n openshift-ingress-operator -o jsonpath='{range .spec.requiredHSTSPolicies[*]}{.spec.requiredHSTSPolicies.maxAgePolicy.largestMaxAge}{"\n"}{end}'

Copy to Clipboard

Toggle word wrap

모든 경로에서 HSTS 주석을 검토하려면 다음 명령을 입력합니다.

oc get route  --all-namespaces -o go-template='{{range .items}}{{if .metadata.annotations}}{{$a := index .metadata.annotations "haproxy.router.openshift.io/hsts_header"}}{{$n := .metadata.name}}{{with $a}}Name: {{$n}} HSTS: {{$a}}{{"\n"}}{{else}}{{""}}{{end}}{{end}}{{end}}'

$ oc get route  --all-namespaces -o go-template='{{range .items}}{{if .metadata.annotations}}{{$a := index .metadata.annotations "haproxy.router.openshift.io/hsts_header"}}{{$n := .metadata.name}}{{with $a}}Name: {{$n}} HSTS: {{$a}}{{"\n"}}{{else}}{{""}}{{end}}{{end}}{{end}}'

Copy to Clipboard

Toggle word wrap

출력 예

Name: <_routename_> HSTS: max-age=31536000;preload;includeSubDomains

Name: <_routename_> HSTS: max-age=31536000;preload;includeSubDomains

Copy to Clipboard

Toggle word wrap

1.1.5. 처리량 문제 해결 방법
링크 복사

때로는 OpenShift Container Platform을 사용하여 배포된 애플리케이션이 특정 서비스 간에 비정상적으로 높은 지연 시간과 같은 네트워크 처리량 문제를 일으킬 수 있습니다.

Pod 로그에서 문제의 원인이 드러나지 않으면 다음 방법을 사용하여 성능 문제를 분석하세요.

ping 이나 tcpdump 와 같은 패킷 분석기를 사용하여 Pod와 노드 간의 트래픽을 분석합니다.
예를 들어, 문제를 일으킨 동작을 재현하는 동안 각 포드에서 tcpdump 도구를 실행합니다 . Pod에서 나가거나 Pod로 들어오는 트래픽의 대기 시간을 분석하기 위해 전송 및 수신 타임 스탬프를 비교하려면 전송 캡처와 수신 캡처를 둘 다 검토하십시오. 다른 Pod, 스토리지 장치 또는 데이터 플레인의 트래픽으로 노드 인터페이스가 과부하된 경우 OpenShift Container Platform에서 대기 시간이 발생할 수 있습니다.
```
tcpdump -s 0 -i any -w /tmp/dump.pcap host <podip 1> && host <podip 2>
```
```
$ tcpdump -s 0 -i any -w /tmp/dump.pcap host <podip 1> && host <podip 2> 
```
1
Copy to Clipboard Toggle word wrap
1
podip은 Pod의 IP 주소입니다. oc get pod <pod_name> -o wide 명령을 실행하여 Pod의 IP 주소를 가져옵니다.
tcpdump 명령은 두 포드 간의 모든 트래픽을 포함하는 파일을 /tmp/dump.pcap 에 생성합니다. 문제가 재현되기 직전에 분석기를 실행하고, 문제 재현이 완료된 직후에 분석기를 중지하면 파일 크기를 최소화할 수 있습니다. 다음을 사용하여 노드 간에 패킷 분석기를 실행할 수도 있습니다.
```
tcpdump -s 0 -i any -w /tmp/dump.pcap port 4789
```
```
$ tcpdump -s 0 -i any -w /tmp/dump.pcap port 4789
```
Copy to Clipboard Toggle word wrap
iperf 와 같은 대역폭 측정 도구를 사용하여 스트리밍 처리량과 UDP 처리량을 측정합니다. 먼저 포드에서 도구를 실행한 다음 노드에서 도구를 실행하여 병목 현상을 찾습니다.
- iperf 설치 및 사용에 대한 자세한 내용은 Red Hat 솔루션 을 참조하세요.
어떤 경우에는 클러스터가 지연 문제로 인해 라우터 포드가 있는 노드를 비정상으로 표시할 수 있습니다. 작업자 지연 프로필을 사용하여 클러스터가 작업을 수행하기 전에 노드로부터 상태 업데이트를 기다리는 빈도를 조정합니다.
클러스터에 저지연 노드와 고지연 노드가 지정된 경우 Ingress Controller에서 spec.nodePlacement 필드를 구성하여 라우터 포드의 배치를 제어합니다.

1.1.6. 쿠키를 사용하여 경로 상태 유지
링크 복사

OpenShift Container Platform은 모든 트래픽이 동일한 끝점에 도달하도록 하여 스테이트풀(stateful) 애플리케이션 트래픽을 사용할 수 있는 고정 세션을 제공합니다. 그러나 재시작, 스케일링 또는 구성 변경 등으로 인해 끝점 pod가 종료되면 이러한 상태 저장 특성이 사라질 수 있습니다.

OpenShift Container Platform에서는 쿠키를 사용하여 세션 지속성을 구성할 수 있습니다. 인그레스 컨트롤러는 사용자 요청을 처리할 엔드포인트를 선택하고 세션에 대한 쿠키를 생성합니다. 쿠키는 요청에 대한 응답으로 다시 전달되고 사용자는 세션의 다음 요청과 함께 쿠키를 다시 보냅니다. 쿠키는 인그레스 컨트롤러에 세션을 처리하는 엔드포인트가 무엇인지 알려주어 클라이언트 요청이 쿠키를 사용하여 동일한 포드로 라우팅되도록 합니다.

참고

HTTP 트래픽을 볼 수 없기 때문에 패스스루 경로에 쿠키를 설정할 수 없습니다. 대신, 소스 IP 주소를 기반으로 숫자가 계산되어 백엔드가 결정됩니다.

백엔드가 변경되면 트래픽이 잘못된 서버로 전달되어 안정성이 떨어질 수 있습니다. 소스 IP를 숨기는 로드 밸런서를 사용하는 경우 모든 연결에 동일한 숫자가 설정되고 트래픽은 동일한 포드로 전송됩니다.

1.1.6.1. 쿠키를 사용하여 경로에 주석 달기
링크 복사

쿠키 이름을 설정하여 경로에 자동 생성되는 기본 쿠키 이름을 덮어쓸 수 있습니다. 그러면 경로 트래픽을 수신하는 애플리케이션에서 쿠키 이름을 확인할 수 있게 됩니다. 쿠키를 삭제하면 다음 요청에서 엔드포인트를 다시 선택해야 할 수 있습니다. 결과적으로 서버에 과부하가 걸리면 해당 서버는 클라이언트의 요청을 제거하여 재분산하려고 시도합니다.

프로세스

지정된 쿠키 이름으로 경로에 주석을 답니다.
```
oc annotate route <route_name> router.openshift.io/cookie_name="<cookie_name>"
```
```
$ oc annotate route <route_name> router.openshift.io/cookie_name="<cookie_name>"
```
Copy to Clipboard Toggle word wrap
다음과 같습니다.
<route_name>
경로 이름을 지정합니다.
<cookie_name>
쿠키 이름을 지정합니다.
예를 들어 쿠키 이름 my_cookie로 my_route 경로에 주석을 달 수 있습니다.
```
oc annotate route my_route router.openshift.io/cookie_name="my_cookie"
```
```
$ oc annotate route my_route router.openshift.io/cookie_name="my_cookie"
```
Copy to Clipboard Toggle word wrap
경로 호스트 이름을 변수에 캡처합니다.
```
ROUTE_NAME=$(oc get route <route_name> -o jsonpath='{.spec.host}')
```
```
$ ROUTE_NAME=$(oc get route <route_name> -o jsonpath='{.spec.host}')
```
Copy to Clipboard Toggle word wrap
다음과 같습니다.
<route_name>
경로 이름을 지정합니다.
쿠키를 저장한 다음 경로에 액세스합니다.
```
curl $ROUTE_NAME -k -c /tmp/cookie_jar
```
```
$ curl $ROUTE_NAME -k -c /tmp/cookie_jar
```
Copy to Clipboard Toggle word wrap
경로에 연결할 때 이전 명령으로 저장된 쿠키를 사용합니다.
```
curl $ROUTE_NAME -k -b /tmp/cookie_jar
```
```
$ curl $ROUTE_NAME -k -b /tmp/cookie_jar
```
Copy to Clipboard Toggle word wrap

1.1.7. 경로 기반 라우터
링크 복사

경로 기반 라우터는 URL과 비교할 수 있는 경로 구성 요소를 지정하며 이를 위해 라우트의 트래픽이 HTTP 기반이어야 합니다. 따라서 동일한 호스트 이름을 사용하여 여러 경로를 제공할 수 있으며 각각 다른 경로가 있습니다. 라우터는 가장 구체적인 경로를 기반으로 하는 라우터와 일치해야 합니다.

다음 표에서는 경로 및 액세스 가능성을 보여줍니다.

Expand

표 1.1. 경로 가용성
경로	비교 대상	액세스 가능
www.example.com/test	www.example.com/test	제공됨
www.example.com/test	www.example.com	없음
www.example.com/test 및 www.example.com	www.example.com/test	제공됨
www.example.com/test 및 www.example.com	www.example.com	제공됨
www.example.com	www.example.com/text	예 (경로가 아닌 호스트에 의해 결정됨)
www.example.com	www.example.com	제공됨

경로가 있는 보안되지 않은 라우터

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: route-unsecured
spec:
  host: www.example.com
  path: "/test" 
  to:
    kind: Service
    name: service-name

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: route-unsecured
spec:
  host: www.example.com
  path: "/test"


  to:
    kind: Service
    name: service-name

Copy to Clipboard

Toggle word wrap

1: 경로는 경로 기반 라우터에 대해 추가된 유일한 속성입니다.

참고

라우터가 해당 경우 TLS를 종료하지 않고 요청 콘텐츠를 읽을 수 없기 때문에 패스스루 TLS를 사용할 때 경로 기반 라우팅을 사용할 수 없습니다.

1.1.8. HTTP 헤더 구성
링크 복사

OpenShift Container Platform은 HTTP 헤더 작업을 위한 다양한 방법을 제공합니다. 헤더를 설정하거나 삭제할 때 Ingress Controller의 특정 필드나 개별 경로를 사용하여 요청 및 응답 헤더를 수정할 수 있습니다. 경로 주석을 사용하여 특정 헤더를 설정할 수도 있습니다. 헤더를 구성하는 다양한 방법은 함께 작업할 때 어려움을 야기할 수 있습니다.

참고

IngressController 또는 Route CR 내에서만 헤더를 설정하거나 삭제할 수 있으며, 헤더를 추가할 수는 없습니다. HTTP 헤더에 값이 설정된 경우 해당 값은 완전해야 하며 나중에 추가할 필요가 없어야 합니다. X-Forwarded-For 헤더와 같이 헤더를 추가하는 것이 합리적인 상황에서는 spec.httpHeaders.actions 대신 spec.httpHeaders.forwardedHeaderPolicy 필드를 사용합니다.

1.1.8.1. 우선순위
링크 복사

동일한 HTTP 헤더가 Ingress Controller와 경로에서 모두 수정되면 HAProxy는 요청 헤더인지 응답 헤더인지에 따라 특정 방식으로 작업의 우선순위를 지정합니다.

HTTP 응답 헤더의 경우, Ingress Controller에 지정된 작업은 경로에 지정된 작업 이후에 실행됩니다. 즉, Ingress Controller에 지정된 작업이 우선적으로 적용됩니다.
HTTP 요청 헤더의 경우, 경로에 지정된 작업은 Ingress Controller에 지정된 작업 이후에 실행됩니다. 즉, 경로에 지정된 작업이 우선합니다.

예를 들어, 클러스터 관리자는 다음 구성을 사용하여 Ingress Controller에서 X-Frame-Options 응답 헤더를 DENY 값으로 설정합니다.

IngressController 사양 예시

apiVersion: operator.openshift.io/v1
kind: IngressController
# ...
spec:
  httpHeaders:
    actions:
      response:
      - name: X-Frame-Options
        action:
          type: Set
          set:
            value: DENY

apiVersion: operator.openshift.io/v1
kind: IngressController
# ...
spec:
  httpHeaders:
    actions:
      response:
      - name: X-Frame-Options
        action:
          type: Set
          set:
            value: DENY

Copy to Clipboard

Toggle word wrap

경로 소유자는 다음 구성을 사용하여 클러스터 관리자가 Ingress Controller에서 설정한 것과 동일한 응답 헤더를 SAMEORIGIN 값으로 설정합니다.

예시 경로 사양

apiVersion: route.openshift.io/v1
kind: Route
# ...
spec:
  httpHeaders:
    actions:
      response:
      - name: X-Frame-Options
        action:
          type: Set
          set:
            value: SAMEORIGIN

apiVersion: route.openshift.io/v1
kind: Route
# ...
spec:
  httpHeaders:
    actions:
      response:
      - name: X-Frame-Options
        action:
          type: Set
          set:
            value: SAMEORIGIN

Copy to Clipboard

Toggle word wrap

IngressController 사양과 Route 사양이 모두 X-Frame-Options 응답 헤더를 구성하는 경우, 특정 경로에서 프레임을 허용하는 경우에도 Ingress Controller의 글로벌 수준에서 이 헤더에 설정된 값이 우선합니다. 요청 헤더의 경우 Route 사양 값이 IngressController 사양 값을 재정의합니다.

이러한 우선순위 지정은 haproxy.config 파일이 Ingress Controller를 프런트 엔드로 간주하고 개별 경로를 백엔드로 간주하는 다음 논리를 사용하기 때문에 발생합니다. 프런트엔드 구성에 적용된 헤더 값 DENY는 백엔드에 설정된 값 SAMEORIGIN 을 갖는 동일한 헤더를 재정의합니다.

frontend public
  http-response set-header X-Frame-Options 'DENY'

frontend fe_sni
  http-response set-header X-Frame-Options 'DENY'

frontend fe_no_sni
  http-response set-header X-Frame-Options 'DENY'

backend be_secure:openshift-monitoring:alertmanager-main
  http-response set-header X-Frame-Options 'SAMEORIGIN'

frontend public
  http-response set-header X-Frame-Options 'DENY'

frontend fe_sni
  http-response set-header X-Frame-Options 'DENY'

frontend fe_no_sni
  http-response set-header X-Frame-Options 'DENY'

backend be_secure:openshift-monitoring:alertmanager-main
  http-response set-header X-Frame-Options 'SAMEORIGIN'

Copy to Clipboard

Toggle word wrap

또한, Ingress Controller나 경로에 정의된 모든 작업은 경로 주석을 사용하여 설정된 값을 재정의합니다.

1.1.8.2. 특수 케이스 헤더
링크 복사

다음 헤더는 설정 또는 삭제가 전혀 금지되어 있거나, 특정 상황에서만 허용됩니다.

Expand

표 1.2. 특수 케이스 헤더 구성 옵션
헤더 이름	`IngressController` 사양을 사용하여 구성 가능	`Route` 사양을 사용하여 구성 가능	불허 사유	다른 방법을 사용하여 구성 가능
`proxy`	없음	없음	`프록시` HTTP 요청 헤더는 헤더 값을 `HTTP_PROXY` 환경 변수에 주입하여 취약한 CGI 애플리케이션을 악용하는 데 사용될 수 있습니다. `프록시` HTTP 요청 헤더도 비표준이며 구성 중에 오류가 발생하기 쉽습니다.	없음
`host`	없음	제공됨	`IngressController` CR을 사용하여 `호스트` HTTP 요청 헤더를 설정하는 경우 HAProxy는 올바른 경로를 찾을 때 실패할 수 있습니다.	없음
`strict-transport-security`	없음	없음	`strict-transport-security` HTTP 응답 헤더는 이미 경로 주석을 사용하여 처리되므로 별도의 구현이 필요하지 않습니다.	예: `haproxy.router.openshift.io/hsts_header` 경로 주석
`쿠키` 와 `쿠키 설정`	없음	없음	HAProxy가 설정하는 쿠키는 클라이언트 연결을 특정 백엔드 서버에 매핑하기 위한 세션 추적에 사용됩니다. 이러한 헤더를 설정하도록 허용하면 HAProxy의 세션 친화성이 방해를 받을 수 있으며 HAProxy의 쿠키 소유권이 제한될 수 있습니다.	예: `haproxy.router.openshift.io/disable_cookie` 경로 주석 `haproxy.router.openshift.io/cookie_name` 경로 주석

1.1.9. 경로에서 HTTP 요청 및 응답 헤더 설정 또는 삭제
링크 복사

규정 준수 목적이나 기타 이유로 특정 HTTP 요청 및 응답 헤더를 설정하거나 삭제할 수 있습니다. Ingress Controller에서 제공하는 모든 경로 또는 특정 경로에 대해 이러한 헤더를 설정하거나 삭제할 수 있습니다.

예를 들어, 콘텐츠가 여러 언어로 작성된 경우 경로를 제공하는 Ingress Controller에서 기본 글로벌 위치를 지정하더라도 특정 경로에 대한 대체 위치에서 콘텐츠를 제공하도록 웹 애플리케이션을 활성화할 수 있습니다.

다음 절차에서는 Content-Location HTTP 요청 헤더를 설정하는 경로를 생성하여 애플리케이션과 연결된 URL인 https://app.example.com 이 위치 https://app.example.com/lang/en-us 로 연결되도록 합니다. 이 위치로 애플리케이션 트래픽을 유도한다는 것은 해당 경로를 사용하는 모든 사람이 미국 영어로 작성된 웹 콘텐츠에 접근한다는 것을 의미합니다.

사전 요구 사항

OpenShift CLI(oc)가 설치되어 있습니다.
프로젝트 관리자로 OpenShift Container Platform 클러스터에 로그인했습니다.
포트와 해당 포트의 트래픽을 수신하는 HTTP 또는 TLS 엔드포인트를 노출하는 웹 애플리케이션이 있습니다.

프로세스

경로 정의를 만들고 app-example-route.yaml 이라는 파일에 저장합니다.
HTTP 헤더 지시문이 포함된 생성된 경로의 YAML 정의
```
apiVersion: route.openshift.io/v1
kind: Route
# ...
spec:
  host: app.example.com
  tls:
    termination: edge
  to:
    kind: Service
    name: app-example
  httpHeaders:
    actions: 
      response: 
      - name: Content-Location 
        action:
          type: Set 
          set:
            value: /lang/en-us 
```
```
apiVersion: route.openshift.io/v1
kind: Route
# ...
spec:
  host: app.example.com
  tls:
    termination: edge
  to:
    kind: Service
    name: app-example
  httpHeaders:
    actions: 
```
1
```
      response: 
```
2
```
      - name: Content-Location 
```
3
```
        action:
          type: Set 
```
4
```
          set:
            value: /lang/en-us 
```
5
Copy to Clipboard Toggle word wrap
1
HTTP 헤더에 대해 수행하려는 작업 목록입니다.
2
변경하려는 헤더의 유형입니다. 이 경우에는 응답 헤더입니다.
3
변경하려는 헤더의 이름입니다. 설정하거나 삭제할 수 있는 사용 가능한 헤더 목록을 보려면 HTTP 헤더 구성을 참조하세요.
4
헤더에 대해 수행되는 작업의 유형입니다. 이 필드는 Set 또는 Delete 값을 가질 수 있습니다.
5
HTTP 헤더를 설정할 때 값을 제공해야 합니다. 값은 해당 헤더에 사용 가능한 지시문 목록의 문자열(예: DENY ) 이 될 수도 있고, HAProxy의 동적 값 구문을 사용하여 해석되는 동적 값이 될 수도 있습니다. 이 경우 값은 콘텐츠의 상대적 위치로 설정됩니다.
새로 만든 경로 정의를 사용하여 기존 웹 애플리케이션에 대한 경로를 만듭니다.
```
oc -n app-example create -f app-example-route.yaml
```
```
$ oc -n app-example create -f app-example-route.yaml
```
Copy to Clipboard Toggle word wrap

HTTP 요청 헤더의 경우, 경로 정의에 지정된 작업은 Ingress Controller에서 HTTP 요청 헤더에 대해 수행된 모든 작업 이후에 실행됩니다. 즉, 경로에 있는 요청 헤더에 설정된 모든 값은 Ingress Controller에 설정된 값보다 우선합니다. HTTP 헤더의 처리 순서에 대한 자세한 내용은 HTTP 헤더 구성을 참조하세요.

1.1.10. 경로별 주석
링크 복사

Ingress 컨트롤러는 노출하는 모든 경로에 기본 옵션을 설정할 수 있습니다. 개별 경로는 주석에 특정 구성을 제공하는 방식으로 이러한 기본값 중 일부를 덮어쓸 수 있습니다. Red Hat은 operator 관리 경로에 경로 주석 추가를 지원하지 않습니다.

중요

여러 소스 IP 또는 서브넷을 포함하는 허용 목록을 만들려면 공백으로 구분된 목록을 사용하세요. 다른 구분 기호 유형으로 인해 경고 또는 오류 메시지 없이 목록이 무시됩니다.

Expand

표 1.3. 경로 주석
변수	설명	기본값으로 사용되는 환경 변수
`haproxy.router.openshift.io/balance`	로드 밸런싱 알고리즘을 설정합니다. 사용 가능한 옵션은 `random` , `source` , `roundrobin` [ ¹ ] 및 `leastconn` 입니다. TLS 패스스루 경로의 기본값은 `소스` 입니다. 다른 모든 경로의 경우 기본값은 `random` 입니다.	경유 경로의 경우 `ROUTER_TCP_BALANCE_SCHEME`입니다. 그 외에는 `ROUTER_LOAD_BALANCE_ALGORITHM`을 사용하십시오.
`haproxy.router.openshift.io/disable_cookies`	쿠키를 사용하여 관련 연결을 추적하지 않도록 설정합니다. `'true'` 또는 `'TRUE'` 로 설정하면 균형 알고리즘을 사용하여 들어오는 각 HTTP 요청에 대해 어떤 백엔드가 연결을 제공할지 선택합니다.
`router.openshift.io/cookie_name`	이 경로에 사용할 선택적 쿠키를 지정합니다. 이름은 대문자와 소문자, 숫자, ‘_’, ‘-’의 조합으로 구성해야 합니다. 기본값은 경로의 해시된 내부 키 이름입니다.
`haproxy.router.openshift.io/pod-concurrent-connections`	라우터에서 백업 pod로 허용되는 최대 연결 수를 설정합니다. 참고: Pod가 여러 개인 경우 각각 이 수만큼의 연결이 있을 수 있습니다. 라우터가 여러 개 있고 조정이 이루어지지 않는 경우에는 각각 이 횟수만큼 연결할 수 있습니다. 설정하지 않거나 0으로 설정하면 제한이 없습니다.
`haproxy.router.openshift.io/rate-limit-connections`	`'true'` 또는 `'TRUE'` 로 설정하면 경로별 특정 백엔드의 스틱 테이블을 통해 구현되는 속도 제한 기능이 활성화됩니다. 참고: 이 주석을 사용하면 서비스 거부 공격에 대한 기본적인 보호가 제공됩니다.
`haproxy.router.openshift.io/rate-limit-connections.concurrent-tcp`	동일한 소스 IP 주소를 통해 만든 동시 TCP 연결 수를 제한합니다. 숫자 값을 허용합니다. 참고: 이 주석을 사용하면 서비스 거부 공격에 대한 기본적인 보호가 제공됩니다.
`haproxy.router.openshift.io/rate-limit-connections.rate-http`	동일한 소스 IP 주소가 있는 클라이언트에서 HTTP 요청을 수행할 수 있는 속도를 제한합니다. 숫자 값을 허용합니다. 참고: 이 주석을 사용하면 서비스 거부 공격에 대한 기본적인 보호가 제공됩니다.
`haproxy.router.openshift.io/rate-limit-connections.rate-tcp`	동일한 소스 IP 주소가 있는 클라이언트에서 TCP 연결을 수행할 수 있는 속도를 제한합니다. 숫자 값을 허용합니다. 참고: 이 주석을 사용하면 서비스 거부 공격에 대한 기본적인 보호가 제공됩니다.
`haproxy.router.openshift.io/timeout`	경로에 대한 서버 쪽 타임아웃을 설정합니다. (TimeUnits)	`ROUTER_DEFAULT_SERVER_TIMEOUT`
`haproxy.router.openshift.io/timeout-tunnel`	이 시간 초과는 터널 연결, 예를 들어 일반 텍스트, 에지, 재암호화 또는 패스스루 경로를 통한 WebSocket에 적용됩니다. 일반 텍스트, 에지 또는 재암호화 경로 유형을 사용하는 경우 이 주석은 기존 시간 초과 값을 사용하는 시간 초과 터널로 적용됩니다. 패스스루 경로 유형의 경우 주석은 기존에 설정된 시간 초과 값보다 우선합니다.	`ROUTER_DEFAULT_TUNNEL_TIMEOUT`
`ingresses.config/cluster ingress.operator.openshift.io/hard-stop-after`	IngressController 또는 ingress config를 설정할 수 있습니다. 이 주석은 라우터를 재배포하고 HA 프록시를 구성하여 haproxy `hard-stop-after` 글로벌 옵션을 내보냅니다. 이 옵션은 클린 소프트 정지를 수행하는 데 허용되는 최대 시간을 정의합니다.	`ROUTER_HARD_STOP_AFTER`
`router.openshift.io/haproxy.health.check.interval`	백엔드 상태 점검 간격을 설정합니다. (TimeUnits)	`ROUTER_BACKEND_CHECK_INTERVAL`
`haproxy.router.openshift.io/ip_allowlist`	경로에 대한 허용 목록을 설정합니다. 허용 목록은 승인된 소스 주소에 대한 IP 주소와 CIDR 범위를 공백으로 구분하여 나열한 목록입니다. 허용 목록에 없는 IP 주소의 요청은 삭제됩니다. `haproxy.config` 파일에서 직접 볼 수 있는 IP 주소와 CIDR 범위의 최대 수는 61입니다. [ ² ]
`haproxy.router.openshift.io/hsts_header`	엣지 종단 경로 또는 재암호화 경로에 Strict-Transport-Security 헤더를 설정합니다.
`haproxy.router.openshift.io/rewrite-target`	백엔드의 요청 재작성 경로를 설정합니다.
`router.openshift.io/cookie-same-site`	쿠키를 제한하는 값을 설정합니다. 값은 다음과 같습니다. `느슨함` : 브라우저가 크로스 사이트 요청에는 쿠키를 보내지 않지만, 사용자가 외부 사이트에서 원본 사이트로 이동할 때는 쿠키를 보냅니다. `SameSite` 값이 지정되지 않은 경우 이는 기본 브라우저 동작입니다. `엄격함` : 브라우저는 동일 사이트 요청에 대해서만 쿠키를 전송합니다. `없음` : 브라우저가 크로스 사이트 및 동일 사이트 요청 모두에 쿠키를 보냅니다. 이 값은 재암호화 및 엣지 경로에만 적용됩니다. 자세한 내용은 SameSite 쿠키 설명서를 참조하십시오.
`haproxy.router.openshift.io/set-forwarded-headers`	라우터당 `Forwarded` 및 `X-Forwarded-For` HTTP 헤더를 처리하기 위한 정책을 설정합니다. 값은 다음과 같습니다. `append`: 기존 헤더를 유지하면서 헤더를 추가합니다. 이는 기본값입니다. `replace`: 헤더를 설정하고 기존 헤더를 제거합니다. `never`: 헤더를 설정하지 않고 기존 헤더를 유지합니다. `if-none`: 아직 설정되지 않은 경우 헤더를 설정합니다.	`ROUTER_SET_FORWARDED_HEADERS`

기본적으로 라우터는 5초마다 다시 로드하여 포드 전체의 밸런싱 연결을 처음부터 재설정합니다. 결과적으로 라운드 로빈 상태는 다시 로드해도 유지되지 않습니다. 이 알고리즘은 포드의 컴퓨팅 성능과 저장 용량이 거의 동일할 때 가장 잘 작동합니다. 예를 들어 CI/CD 파이프라인을 사용하는 경우 애플리케이션이나 서비스의 엔드포인트가 지속적으로 변경되는 경우 균등하지 않은 균형이 발생할 수 있습니다. 이 경우에는 다른 알고리즘을 사용하세요.
허용 목록에 있는 IP 주소와 CIDR 범위의 수가 61을 초과하면 해당 내용은 별도의 파일에 기록되고 haproxy.config 파일에서 참조됩니다. 이 파일은 /var/lib/haproxy/router/allowlists 폴더에 저장됩니다.
참고
주소가 허용 목록에 기록되었는지 확인하려면 CIDR 범위 전체 목록이 Ingress Controller 구성 파일에 나열되어 있는지 확인하세요. etcd 객체 크기 제한은 경로 주석의 크기를 제한합니다. 이로 인해 허용 목록에 포함할 수 있는 IP 주소와 CIDR 범위의 최대 개수에 대한 임계값이 생성됩니다.

참고

환경 변수는 편집할 수 없습니다.

라우터 시간 제한 변수

TimeUnits는 다음과 같이 표시됩니다. us *(마이크로초), ms (밀리초, 기본값), s (초), m (분), h *(시간), d (일).

정규 표현식은 [1-9][0-9]*(us\|ms\|s\|m\|h\|d)입니다.

Expand

Variable	Default	설명
`ROUTER_BACKEND_CHECK_INTERVAL`	`5000ms`	백엔드에서 후속 활성 검사 사이의 시간입니다.
`ROUTER_CLIENT_FIN_TIMEOUT`	`1s`	경로에 연결된 클라이언트의 TCP FIN 시간 제한 기간을 제어합니다. FIN이 연결을 닫도록 전송한 경우 지정된 시간 내에 응답하지 않으면 HAProxy가 연결을 종료합니다. 낮은 값으로 설정하면 문제가 없으며 라우터에서 더 적은 리소스를 사용합니다.
`ROUTER_DEFAULT_CLIENT_TIMEOUT`	`30s`	클라이언트가 데이터를 승인하거나 보내야 하는 시간입니다.
`ROUTER_DEFAULT_CONNECT_TIMEOUT`	`5s`	최대 연결 시간입니다.
`ROUTER_DEFAULT_SERVER_FIN_TIMEOUT`	`1s`	라우터에서 경로를 지원하는 pod로의 TCP FIN 시간 초과를 제어합니다.
`ROUTER_DEFAULT_SERVER_TIMEOUT`	`30s`	서버에서 데이터를 승인하거나 보내야 하는 시간입니다.
`ROUTER_DEFAULT_TUNNEL_TIMEOUT`	`1시간`	TCP 또는 WebSocket 연결이 열린 상태로 유지되는 동안의 시간입니다. 이 시간 제한 기간은 HAProxy를 다시 로드할 때마다 재설정됩니다.
`ROUTER_SLOWLORIS_HTTP_KEEPALIVE`	`300s`	새 HTTP 요청이 표시될 때까지 대기할 최대 시간을 설정합니다. 이 값을 너무 낮게 설정하면 작은 `keepalive` 값을 예상하지 못하는 브라우저 및 애플리케이션에 문제가 발생할 수 있습니다. 일부 유효한 시간 제한 값은 예상되는 특정 시간 초과가 아니라 특정 변수의 합계일 수 있습니다. 예를 들어 `ROUTER_SLOWLORIS_HTTP_KEEPALIVE`는 `timeout http-keep-alive`를 조정합니다. 기본적으로 `300s`로 설정되지만 HAProxy는 `5s`로 설정된 `tcp-request inspect-delay`도 대기합니다. 이 경우 전체 시간 초과는 `300s` + `5s`입니다.
`ROUTER_SLOWLORIS_TIMEOUT`	`10s`	HTTP 요청 전송에 걸리는 시간입니다.
`RELOAD_INTERVAL`	`5s`	라우터의 최소 빈도가 새 변경 사항을 다시 로드하고 승인하도록 허용합니다.
`ROUTER_METRICS_HAPROXY_TIMEOUT`	`5s`	HAProxy 메트릭 수집에 대한 시간 제한입니다.

경로 설정 사용자 정의 타임아웃

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  annotations:
    haproxy.router.openshift.io/timeout: 5500ms 
...

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  annotations:
    haproxy.router.openshift.io/timeout: 5500ms

...

Copy to Clipboard

Toggle word wrap

1: HAProxy 지원 단위(us, ms, s, m, h, d)를 사용하여 새 타임아웃을 지정합니다. 단위가 제공되지 않는 경우 ms가 기본값입니다.

참고

패스스루(passthrough) 경로에 대한 서버 쪽 타임아웃 값을 너무 낮게 설정하면 해당 경로에서 WebSocket 연결이 자주 시간 초과될 수 있습니다.

하나의 특정 IP 주소만 허용하는 경로

metadata:
  annotations:
    haproxy.router.openshift.io/ip_allowlist: 192.168.1.10

metadata:
  annotations:
    haproxy.router.openshift.io/ip_allowlist: 192.168.1.10

Copy to Clipboard

Toggle word wrap

여러 IP 주소를 허용하는 경로

metadata:
  annotations:
    haproxy.router.openshift.io/ip_allowlist: 192.168.1.10 192.168.1.11 192.168.1.12

metadata:
  annotations:
    haproxy.router.openshift.io/ip_allowlist: 192.168.1.10 192.168.1.11 192.168.1.12

Copy to Clipboard

Toggle word wrap

IP 주소 CIDR 네트워크를 허용하는 경로

metadata:
  annotations:
    haproxy.router.openshift.io/ip_allowlist: 192.168.1.0/24

metadata:
  annotations:
    haproxy.router.openshift.io/ip_allowlist: 192.168.1.0/24

Copy to Clipboard

Toggle word wrap

IP 주소 및 IP 주소 CIDR 네트워크를 둘 다 허용하는 경로

metadata:
  annotations:
    haproxy.router.openshift.io/ip_allowlist: 180.5.61.153 192.168.1.0/24 10.0.0.0/8

metadata:
  annotations:
    haproxy.router.openshift.io/ip_allowlist: 180.5.61.153 192.168.1.0/24 10.0.0.0/8

Copy to Clipboard

Toggle word wrap

재작성 대상을 지정하는 경로

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  annotations:
    haproxy.router.openshift.io/rewrite-target: / 
...

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  annotations:
    haproxy.router.openshift.io/rewrite-target: /

...

Copy to Clipboard

Toggle word wrap

1: /를 백엔드의 요청 재작성 경로로 설정합니다.

경로에 haproxy.router.openshift.io/rewrite-target 주석을 설정하면 Ingress Controller에서 요청을 백엔드 애플리케이션으로 전달하기 전에 이 경로를 사용하여 HTTP 요청의 경로를 재작성해야 합니다. spec.path에 지정된 경로와 일치하는 요청 경로 부분은 주석에 지정된 재작성 대상으로 교체됩니다.

다음 표에 spec.path, 요청 경로, 재작성 대상의 다양한 조합에 따른 경로 재작성 동작의 예가 있습니다.

Expand

표 1.4. 재작성 대상 예시
Route.spec.path	요청 경로	재작성 대상	전달된 요청 경로
/foo	/foo	/	/
/foo	/foo/	/	/
/foo	/foo/bar	/	/bar
/foo	/foo/bar/	/	/bar/
/foo	/foo	/bar	/bar
/foo	/foo/	/bar	/bar/
/foo	/foo/bar	/baz	/baz/bar
/foo	/foo/bar/	/baz	/baz/bar/
/foo/	/foo	/	N/A(요청 경로가 라우팅 경로와 일치하지 않음)
/foo/	/foo/	/	/
/foo/	/foo/bar	/	/bar

haproxy.router.openshift.io/rewrite-target 의 특정 특수 문자는 적절하게 이스케이프되어야 하므로 특별한 처리가 필요합니다. 다음 표를 참조하여 이러한 문자가 어떻게 처리되는지 알아보세요.

Expand

표 1.5. 특수 문자 처리
캐릭터를 위해	문자를 사용하세요	참고
#	\#	#은 재작성 표현식을 종료하므로 사용하지 마십시오.
%	% 또는 %%	%%%와 같은 이상한 시퀀스는 피하세요.
‘	\’	'는 무시되므로 피하세요.

다른 모든 유효한 URL 문자는 이스케이프하지 않고 사용할 수 있습니다.

1.1.11. 경로 허용 정책 구성
링크 복사

관리자 및 애플리케이션 개발자는 도메인 이름이 동일한 여러 네임스페이스에서 애플리케이션을 실행할 수 있습니다. 이는 여러 팀이 동일한 호스트 이름에 노출되는 마이크로 서비스를 개발하는 조직을 위한 것입니다.

주의

네임스페이스 간 클레임은 네임스페이스 간 신뢰가 있는 클러스터에 대해서만 허용해야 합니다. 그렇지 않으면 악의적인 사용자가 호스트 이름을 인수할 수 있습니다. 따라서 기본 승인 정책에서는 네임스페이스 간에 호스트 이름 클레임을 허용하지 않습니다.

사전 요구 사항

클러스터 관리자 권한이 있어야 합니다.

프로세스

다음 명령을 사용하여 ingresscontroller 리소스 변수의 .spec.routeAdmission 필드를 편집합니다.

oc -n openshift-ingress-operator patch ingresscontroller/default --patch '{"spec":{"routeAdmission":{"namespaceOwnership":"InterNamespaceAllowed"}}}' --type=merge

$ oc -n openshift-ingress-operator patch ingresscontroller/default --patch '{"spec":{"routeAdmission":{"namespaceOwnership":"InterNamespaceAllowed"}}}' --type=merge

Copy to Clipboard

Toggle word wrap

샘플 Ingress 컨트롤러 구성

spec:
  routeAdmission:
    namespaceOwnership: InterNamespaceAllowed
...

spec:
  routeAdmission:
    namespaceOwnership: InterNamespaceAllowed
...

Copy to Clipboard

Toggle word wrap

작은 정보

다음 YAML을 적용하여 경로 승인 정책을 구성할 수 있습니다.

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: default
  namespace: openshift-ingress-operator
spec:
  routeAdmission:
    namespaceOwnership: InterNamespaceAllowed

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: default
  namespace: openshift-ingress-operator
spec:
  routeAdmission:
    namespaceOwnership: InterNamespaceAllowed

Copy to Clipboard

Toggle word wrap

1.1.12. Ingress 오브젝트를 통해 경로 생성
링크 복사

일부 에코시스템 구성 요소는 Ingress 리소스와 통합되지만 경로 리소스와는 통합되지 않습니다. 이러한 경우를 처리하기 위해 OpenShift Container Platform에서는 Ingress 오브젝트가 생성될 때 관리형 경로 오브젝트를 자동으로 생성합니다. 이러한 경로 오브젝트는 해당 Ingress 오브젝트가 삭제될 때 삭제됩니다.

프로세스

OpenShift Container Platform 콘솔에서 또는 oc create 명령을 입력하여 Ingress 객체를 정의합니다.
Ingress의 YAML 정의
```
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: frontend
  annotations:
    route.openshift.io/termination: "reencrypt" 
    route.openshift.io/destination-ca-certificate-secret: secret-ca-cert 
spec:
  rules:
  - host: www.example.com 
    http:
      paths:
      - backend:
          service:
            name: frontend
            port:
              number: 443
        path: /
        pathType: Prefix
  tls:
  - hosts:
    - www.example.com
    secretName: example-com-tls-certificate
```
```
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: frontend
  annotations:
    route.openshift.io/termination: "reencrypt" 
```
1
```
    route.openshift.io/destination-ca-certificate-secret: secret-ca-cert 
```
2
```
spec:
  rules:
  - host: www.example.com 
```
3
```
    http:
      paths:
      - backend:
          service:
            name: frontend
            port:
              number: 443
        path: /
        pathType: Prefix
  tls:
  - hosts:
    - www.example.com
    secretName: example-com-tls-certificate
```
Copy to Clipboard Toggle word wrap
1
Ingress에는 Route에 대한 필드가 없으므로 route.openshift.io/termination 주석을 사용하여 spec.tls.termination 필드를 구성할 수 있습니다. 허용되는 값은 edge, passthrough, reencrypt입니다. 다른 모든 값은 자동으로 무시됩니다. 주석 값이 설정되지 않으면 edge가 기본 경로입니다. 기본 에지 경로를 구현하려면 TLS 인증서 세부 정보를 템플릿 파일에 정의해야 합니다.
3
Ingress 객체를 사용할 때는 경로로 작업할 때와 달리 명시적인 호스트 이름을 지정해야 합니다. <host_name>.<cluster_ingress_domain> 구문(예: apps.openshiftdemos.com )을 사용하면 클러스터에 대한 *.<cluster_ingress_domain> 와일드카드 DNS 레코드와 제공 인증서를 활용할 수 있습니다. 그렇지 않은 경우, 선택한 호스트 이름에 대한 DNS 레코드가 있는지 확인해야 합니다.
route.openshift.io/termination 주석에 passthrough 값을 지정하는 경우 path를 ''로 설정하고 spec에서 pathType을 ImplementationSpecific으로 설정합니다.

spec: rules: - host: www.example.com http: paths: - path: '' pathType: ImplementationSpecific backend: service: name: frontend port: number: 443

Copy to Clipboard Toggle word wrap

$ oc apply -f ingress.yaml

Copy to Clipboard Toggle word wrap
2
route.openshift.io/destination-ca-certificate-secret 은 Ingress 객체에서 사용자 정의 대상 인증서(CA)로 경로를 정의하는 데 사용할 수 있습니다. 주석은 생성된 경로에 삽입될 쿠버네티스 비밀인 secret-ca-cert를 참조합니다.
수신 객체에서 대상 CA가 있는 경로 객체를 지정하려면 비밀의 data.tls.crt 지정자에 PEM 인코딩 형식의 인증서가 있는 kubernetes.io/tls 또는 Opaque 유형 비밀을 만들어야 합니다.

노드를 나열합니다.

oc get routes

$ oc get routes

Copy to Clipboard

Toggle word wrap

결과에는 이름이 frontend-로 시작하는 자동 생성 경로가 포함됩니다.

NAME             HOST/PORT         PATH    SERVICES    PORT    TERMINATION          WILDCARD
frontend-gnztq   www.example.com           frontend    443     reencrypt/Redirect   None

NAME             HOST/PORT         PATH    SERVICES    PORT    TERMINATION          WILDCARD
frontend-gnztq   www.example.com           frontend    443     reencrypt/Redirect   None

Copy to Clipboard

Toggle word wrap

이 경로를 살펴보면 다음과 같습니다.

자동 생성 경로의 YAML 정의

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: frontend-gnztq
  ownerReferences:
  - apiVersion: networking.k8s.io/v1
    controller: true
    kind: Ingress
    name: frontend
    uid: 4e6c59cc-704d-4f44-b390-617d879033b6
spec:
  host: www.example.com
  path: /
  port:
    targetPort: https
  tls:
    certificate: |
      -----BEGIN CERTIFICATE-----
      [...]
      -----END CERTIFICATE-----
    insecureEdgeTerminationPolicy: Redirect
    key: |
      -----BEGIN RSA PRIVATE KEY-----
      [...]
      -----END RSA PRIVATE KEY-----
    termination: reencrypt
    destinationCACertificate: |
      -----BEGIN CERTIFICATE-----
      [...]
      -----END CERTIFICATE-----
  to:
    kind: Service
    name: frontend

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: frontend-gnztq
  ownerReferences:
  - apiVersion: networking.k8s.io/v1
    controller: true
    kind: Ingress
    name: frontend
    uid: 4e6c59cc-704d-4f44-b390-617d879033b6
spec:
  host: www.example.com
  path: /
  port:
    targetPort: https
  tls:
    certificate: |
      -----BEGIN CERTIFICATE-----
      [...]
      -----END CERTIFICATE-----
    insecureEdgeTerminationPolicy: Redirect
    key: |
      -----BEGIN RSA PRIVATE KEY-----
      [...]
      -----END RSA PRIVATE KEY-----
    termination: reencrypt
    destinationCACertificate: |
      -----BEGIN CERTIFICATE-----
      [...]
      -----END CERTIFICATE-----
  to:
    kind: Service
    name: frontend

Copy to Clipboard

Toggle word wrap

1.1.13. Ingress 객체를 통해 기본 인증서를 사용하여 경로 생성
링크 복사

TLS 구성을 지정하지 않고 Ingress 객체를 생성하면 OpenShift Container Platform에서 안전하지 않은 경로가 생성됩니다. 기본 Ingress 인증서를 사용하여 보안되고 엣지 종료된 경로를 생성하는 Ingress 객체를 만들려면 다음과 같이 빈 TLS 구성을 지정할 수 있습니다.

사전 요구 사항

공개하고 싶은 서비스가 있습니다.
OpenShift CLI(oc)에 액세스할 수 있습니다.

프로세스

Ingress 객체에 대한 YAML 파일을 만듭니다. 이 예에서 파일 이름은 example-ingress.yaml 입니다.
Ingress 객체의 YAML 정의
```
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: frontend
  ...
spec:
  rules:
    ...
  tls:
  - {} 
```
```
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: frontend
  ...
spec:
  rules:
    ...
  tls:
  - {} 
```
1
Copy to Clipboard Toggle word wrap
1
사용자 정의 인증서를 지정하지 않고도 TLS를 지정하려면 이 정확한 구문을 사용하세요.
다음 명령을 실행하여 Ingress 객체를 만듭니다.
```
oc create -f example-ingress.yaml
```
```
$ oc create -f example-ingress.yaml
```
Copy to Clipboard Toggle word wrap

검증

다음 명령을 실행하여 OpenShift Container Platform이 Ingress 개체에 대한 예상 경로를 생성했는지 확인하세요.

oc get routes -o yaml

$ oc get routes -o yaml

Copy to Clipboard

Toggle word wrap

출력 예

apiVersion: v1
items:
- apiVersion: route.openshift.io/v1
  kind: Route
  metadata:
    name: frontend-j9sdd 
    ...
  spec:
  ...
    tls: 
      insecureEdgeTerminationPolicy: Redirect
      termination: edge 
  ...

apiVersion: v1
items:
- apiVersion: route.openshift.io/v1
  kind: Route
  metadata:
    name: frontend-j9sdd


    ...
  spec:
  ...
    tls:


      insecureEdgeTerminationPolicy: Redirect
      termination: edge

...

Copy to Clipboard

Toggle word wrap

1: 경로 이름에는 Ingress 객체 이름과 그 뒤에 무작위 접미사가 포함됩니다.
2: 기본 인증서를 사용하려면 경로에 spec.certificate를 지정해서는 안 됩니다.
3: 경로에는 에지 종료 정책이 지정되어야 합니다.

1.1.14. Ingress 주석에서 대상 CA 인증서를 사용하여 경로 생성
링크 복사

route.openshift.io/destination-ca-certificate-secret 주석은 Ingress 객체에서 사용자 지정 대상 CA 인증서로 경로를 정의하는 데 사용할 수 있습니다.

사전 요구 사항

PEM으로 인코딩된 파일에 인증서/키 쌍이 있을 수 있으며, 이 인증서는 경로 호스트에 유효합니다.
인증서 체인을 완성하는 PEM 인코딩 파일에 별도의 CA 인증서가 있을 수 있습니다.
PEM 인코딩 파일에 별도의 대상 CA 인증서가 있어야 합니다.
노출하려는 서비스가 있어야 합니다.

프로세스

다음 명령을 입력하여 대상 CA 인증서에 대한 비밀을 만듭니다.

oc create secret generic dest-ca-cert --from-file=tls.crt=<file_path>

$ oc create secret generic dest-ca-cert --from-file=tls.crt=<file_path>

Copy to Clipboard

Toggle word wrap

예를 들면 다음과 같습니다.

oc -n test-ns create secret generic dest-ca-cert --from-file=tls.crt=tls.crt

$ oc -n test-ns create secret generic dest-ca-cert --from-file=tls.crt=tls.crt

Copy to Clipboard

Toggle word wrap

출력 예

secret/dest-ca-cert created

secret/dest-ca-cert created

Copy to Clipboard

Toggle word wrap

Ingress 주석에 route.openshift.io/destination-ca-certificate-secret 을 추가합니다.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: frontend
  annotations:
    route.openshift.io/termination: "reencrypt"
    route.openshift.io/destination-ca-certificate-secret: secret-ca-cert 
...

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: frontend
  annotations:
    route.openshift.io/termination: "reencrypt"
    route.openshift.io/destination-ca-certificate-secret: secret-ca-cert

...

Copy to Clipboard

Toggle word wrap

1: 주석은 쿠버네티스 비밀을 참조합니다.

이 주석에 참조된 비밀은 생성된 경로에 삽입됩니다.

출력 예

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: frontend
  annotations:
    route.openshift.io/termination: reencrypt
    route.openshift.io/destination-ca-certificate-secret: secret-ca-cert
spec:
...
  tls:
    insecureEdgeTerminationPolicy: Redirect
    termination: reencrypt
    destinationCACertificate: |
      -----BEGIN CERTIFICATE-----
      [...]
      -----END CERTIFICATE-----
...

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: frontend
  annotations:
    route.openshift.io/termination: reencrypt
    route.openshift.io/destination-ca-certificate-secret: secret-ca-cert
spec:
...
  tls:
    insecureEdgeTerminationPolicy: Redirect
    termination: reencrypt
    destinationCACertificate: |
      -----BEGIN CERTIFICATE-----
      [...]
      -----END CERTIFICATE-----
...

Copy to Clipboard

Toggle word wrap

1.1.15. 듀얼 스택 네트워킹을 위한 OpenShift Container Platform Ingress 컨트롤러 구성
링크 복사

OpenShift Container Platform 클러스터가 IPv4 및 IPv6 이중 스택 네트워킹에 맞게 구성된 경우 OpenShift Container Platform 경로에서 외부에서 클러스터에 연결할 수 있습니다.

Ingress 컨트롤러는 IPv4 및 IPv6 엔드 포인트가 모두 있는 서비스를 자동으로 제공하지만 단일 스택 또는 듀얼 스택 서비스에 대해 Ingress 컨트롤러를 구성할 수 있습니다.

사전 요구 사항

베어메탈에 OpenShift Container Platform 클러스터를 배포했습니다.
OpenShift CLI(oc)를 설치합니다.

프로세스

Ingress 컨트롤러가 워크로드로 IPv4/IPv6을 통해 트래픽을 제공하도록 하려면 ipFamilies 및 ipFamilyPolicy 필드를 설정하여 서비스 YAML 파일을 생성하거나 기존 서비스 YAML 파일을 수정할 수 있습니다. 예를 들면 다음과 같습니다.

샘플 서비스 YAML 파일

apiVersion: v1
kind: Service
metadata:
  creationTimestamp: yyyy-mm-ddT00:00:00Z
  labels:
    name: <service_name>
    manager: kubectl-create
    operation: Update
    time: yyyy-mm-ddT00:00:00Z
  name: <service_name>
  namespace: <namespace_name>
  resourceVersion: "<resource_version_number>"
  selfLink: "/api/v1/namespaces/<namespace_name>/services/<service_name>"
  uid: <uid_number>
spec:
  clusterIP: 172.30.0.0/16
  clusterIPs: 
  - 172.30.0.0/16
  - <second_IP_address>
  ipFamilies: 
  - IPv4
  - IPv6
  ipFamilyPolicy: RequireDualStack 
  ports:
  - port: 8080
    protocol: TCP
    targetport: 8080
  selector:
    name: <namespace_name>
  sessionAffinity: None
  type: ClusterIP
status:
  loadbalancer: {}

apiVersion: v1
kind: Service
metadata:
  creationTimestamp: yyyy-mm-ddT00:00:00Z
  labels:
    name: <service_name>
    manager: kubectl-create
    operation: Update
    time: yyyy-mm-ddT00:00:00Z
  name: <service_name>
  namespace: <namespace_name>
  resourceVersion: "<resource_version_number>"
  selfLink: "/api/v1/namespaces/<namespace_name>/services/<service_name>"
  uid: <uid_number>
spec:
  clusterIP: 172.30.0.0/16
  clusterIPs:


  - 172.30.0.0/16
  - <second_IP_address>
  ipFamilies:


  - IPv4
  - IPv6
  ipFamilyPolicy: RequireDualStack


  ports:
  - port: 8080
    protocol: TCP
    targetport: 8080
  selector:
    name: <namespace_name>
  sessionAffinity: None
  type: ClusterIP
status:
  loadbalancer: {}

Copy to Clipboard

Toggle word wrap

1: 듀얼 스택 인스턴스에는 두 개의 서로 다른 clusterIPs가 제공됩니다.
2: 단일 스택 인스턴스의 경우 IPv4 또는 IPv6을 입력합니다. 듀얼 스택 인스턴스의 경우 IPv4 및 IPv6 모두를 입력합니다.
3: 단일 스택 인스턴스의 경우 SingleStack을 입력합니다. 듀얼 스택 인스턴스의 경우 RequireDualStack을 입력합니다.

이러한 리소스는 해당 endpoints를 생성합니다. Ingress 컨트롤러는 이제 endpointslices를 감시합니다.

endpoints를 확인하려면 다음 명령을 입력합니다:
```
oc get endpoints
```
```
$ oc get endpoints
```
Copy to Clipboard Toggle word wrap
endpointslices를 확인하려면 다음 명령을 입력합니다.
```
oc get endpointslices
```
```
$ oc get endpointslices
```
Copy to Clipboard Toggle word wrap

1.2. 보안 경로
링크 복사

보안 경로는 여러 유형의 TLS 종료를 사용하여 클라이언트에 인증서를 제공하는 기능을 제공합니다. 다음 섹션에서는 사용자 정의 인증서를 사용하여 재암호화 에지 및 패스스루 경로를 생성하는 방법을 설명합니다.

중요

공용 끝점을 통해 Microsoft Azure에서 경로를 생성하는 경우 리소스 이름에 제한이 적용됩니다. 특정 용어를 사용하는 리소스를 생성할 수 없습니다. Azure에서 제한하는 용어 목록은 Azure 설명서의 예약된 리소스 이름 오류 해결을 참조하십시오.

1.2.1. 사용자 정의 인증서를 사용하여 재암호화 경로 생성
링크 복사

oc create route 명령을 사용하면 재암호화 TLS 종료와 사용자 정의 인증서로 보안 경로를 구성할 수 있습니다.

사전 요구 사항

PEM 인코딩 파일에 인증서/키 쌍이 있고 해당 인증서가 경로 호스트에 유효해야 합니다.
인증서 체인을 완성하는 PEM 인코딩 파일에 별도의 CA 인증서가 있을 수 있습니다.
PEM 인코딩 파일에 별도의 대상 CA 인증서가 있어야 합니다.
노출하려는 서비스가 있어야 합니다.

참고

암호로 보호되는 키 파일은 지원되지 않습니다. 키 파일에서 암호를 제거하려면 다음 명령을 사용하십시오.

openssl rsa -in password_protected_tls.key -out tls.key

$ openssl rsa -in password_protected_tls.key -out tls.key

Copy to Clipboard

Toggle word wrap

프로세스

이 절차에서는 사용자 정의 인증서를 사용하여 Route 리소스를 생성하고 TLS 종료를 재암호화합니다. 다음 예에서는 인증서/키 쌍이 현재 작업 디렉터리의 tls.crt 및 tls.key 파일에 있다고 가정합니다. Ingress 컨트롤러에서 서비스의 인증서를 신뢰하도록 하려면 대상 CA 인증서도 지정해야 합니다. 인증서 체인을 완료하는 데 필요한 경우 CA 인증서를 지정할 수도 있습니다. tls.crt, tls.key, cacert.crt, ca.crt(옵션)에 실제 경로 이름을 사용하십시오. frontend에는 노출하려는 서비스 리소스 이름을 사용합니다. www.example.com을 적절한 호스트 이름으로 바꿉니다.

재암호화 TLS 종료 및 사용자 정의 인증서를 사용하여 보안 Route 리소스를 생성합니다.

oc create route reencrypt --service=frontend --cert=tls.crt --key=tls.key --dest-ca-cert=destca.crt --ca-cert=ca.crt --hostname=www.example.com

$ oc create route reencrypt --service=frontend --cert=tls.crt --key=tls.key --dest-ca-cert=destca.crt --ca-cert=ca.crt --hostname=www.example.com

Copy to Clipboard

Toggle word wrap

생성된 Route 리소스는 다음과 유사합니다.

보안 경로의 YAML 정의

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: frontend
spec:
  host: www.example.com
  to:
    kind: Service
    name: frontend
  tls:
    termination: reencrypt
    key: |-
      -----BEGIN PRIVATE KEY-----
      [...]
      -----END PRIVATE KEY-----
    certificate: |-
      -----BEGIN CERTIFICATE-----
      [...]
      -----END CERTIFICATE-----
    caCertificate: |-
      -----BEGIN CERTIFICATE-----
      [...]
      -----END CERTIFICATE-----
    destinationCACertificate: |-
      -----BEGIN CERTIFICATE-----
      [...]
      -----END CERTIFICATE-----

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: frontend
spec:
  host: www.example.com
  to:
    kind: Service
    name: frontend
  tls:
    termination: reencrypt
    key: |-
      -----BEGIN PRIVATE KEY-----
      [...]
      -----END PRIVATE KEY-----
    certificate: |-
      -----BEGIN CERTIFICATE-----
      [...]
      -----END CERTIFICATE-----
    caCertificate: |-
      -----BEGIN CERTIFICATE-----
      [...]
      -----END CERTIFICATE-----
    destinationCACertificate: |-
      -----BEGIN CERTIFICATE-----
      [...]
      -----END CERTIFICATE-----

Copy to Clipboard

Toggle word wrap

자세한 옵션은 oc create route reencrypt --help를 참조하십시오.

1.2.2. 사용자 정의 인증서를 사용하여 엣지 경로 생성
링크 복사

oc create route 명령을 사용하면 엣지 TLS 종료와 사용자 정의 인증서로 보안 경로를 구성할 수 있습니다. 엣지 경로를 사용하면 Ingress 컨트롤러에서 트래픽을 대상 Pod로 전달하기 전에 TLS 암호화를 종료합니다. 이 경로는 Ingress 컨트롤러가 경로에 사용하는 TLS 인증서 및 키를 지정합니다.

사전 요구 사항

PEM 인코딩 파일에 인증서/키 쌍이 있고 해당 인증서가 경로 호스트에 유효해야 합니다.
인증서 체인을 완성하는 PEM 인코딩 파일에 별도의 CA 인증서가 있을 수 있습니다.
노출하려는 서비스가 있어야 합니다.

참고

암호로 보호되는 키 파일은 지원되지 않습니다. 키 파일에서 암호를 제거하려면 다음 명령을 사용하십시오.

openssl rsa -in password_protected_tls.key -out tls.key

$ openssl rsa -in password_protected_tls.key -out tls.key

Copy to Clipboard

Toggle word wrap

프로세스

이 절차에서는 사용자 정의 인증서 및 엣지 TLS 종료를 사용하여 Route 리소스를 생성합니다. 다음 예에서는 인증서/키 쌍이 현재 작업 디렉터리의 tls.crt 및 tls.key 파일에 있다고 가정합니다. 인증서 체인을 완료하는 데 필요한 경우 CA 인증서를 지정할 수도 있습니다. tls.crt, tls.key, ca.crt(옵션)에 실제 경로 이름을 사용하십시오. frontend에는 노출하려는 서비스 이름을 사용합니다. www.example.com을 적절한 호스트 이름으로 바꿉니다.

엣지 TLS 종료 및 사용자 정의 인증서를 사용하여 보안 Route 리소스를 생성합니다.

oc create route edge --service=frontend --cert=tls.crt --key=tls.key --ca-cert=ca.crt --hostname=www.example.com

$ oc create route edge --service=frontend --cert=tls.crt --key=tls.key --ca-cert=ca.crt --hostname=www.example.com

Copy to Clipboard

Toggle word wrap

생성된 Route 리소스는 다음과 유사합니다.

보안 경로의 YAML 정의

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: frontend
spec:
  host: www.example.com
  to:
    kind: Service
    name: frontend
  tls:
    termination: edge
    key: |-
      -----BEGIN PRIVATE KEY-----
      [...]
      -----END PRIVATE KEY-----
    certificate: |-
      -----BEGIN CERTIFICATE-----
      [...]
      -----END CERTIFICATE-----
    caCertificate: |-
      -----BEGIN CERTIFICATE-----
      [...]
      -----END CERTIFICATE-----

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: frontend
spec:
  host: www.example.com
  to:
    kind: Service
    name: frontend
  tls:
    termination: edge
    key: |-
      -----BEGIN PRIVATE KEY-----
      [...]
      -----END PRIVATE KEY-----
    certificate: |-
      -----BEGIN CERTIFICATE-----
      [...]
      -----END CERTIFICATE-----
    caCertificate: |-
      -----BEGIN CERTIFICATE-----
      [...]
      -----END CERTIFICATE-----

Copy to Clipboard

Toggle word wrap

추가 옵션은 oc create route edge --help를 참조하십시오.

1.2.3. 패스스루 라우팅 생성
링크 복사

oc create route 명령을 사용하면 패스스루 종료와 사용자 정의 인증서로 보안 경로를 구성할 수 있습니다. 패스스루 종료를 사용하면 암호화된 트래픽이 라우터에서 TLS 종료를 제공하지 않고 바로 대상으로 전송됩니다. 따라서 라우터에 키 또는 인증서가 필요하지 않습니다.

사전 요구 사항

노출하려는 서비스가 있어야 합니다.

프로세스

Route 리소스를 생성합니다.

oc create route passthrough route-passthrough-secured --service=frontend --port=8080

$ oc create route passthrough route-passthrough-secured --service=frontend --port=8080

Copy to Clipboard

Toggle word wrap

생성된 Route 리소스는 다음과 유사합니다.

패스스루 종료를 사용하는 보안 경로

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: route-passthrough-secured 
spec:
  host: www.example.com
  port:
    targetPort: 8080
  tls:
    termination: passthrough 
    insecureEdgeTerminationPolicy: None 
  to:
    kind: Service
    name: frontend

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: route-passthrough-secured


spec:
  host: www.example.com
  port:
    targetPort: 8080
  tls:
    termination: passthrough


    insecureEdgeTerminationPolicy: None


  to:
    kind: Service
    name: frontend

Copy to Clipboard

Toggle word wrap

1: 63자로 제한되는 개체의 이름입니다.
2: termination 필드는 passthrough로 설정됩니다. 이 필드는 유일한 필수 tls 필드입니다.
3: insecureEdgeTerminationPolicy는 선택 사항입니다. 비활성화경우 유효한 값은 None, Redirect 또는 빈 값입니다.

대상 Pod는 끝점의 트래픽에 대한 인증서를 제공해야 합니다. 현재 이 방법은 양방향 인증이라고도 하는 클라이언트 인증서도 지원할 수 있는 유일한 방법입니다.

1.2.4. 외부 관리 인증서를 사용하여 경로 생성
링크 복사

경로 API의 .spec.tls.externalCertificate 필드를 사용하여 타사 인증서 관리 솔루션으로 OpenShift Container Platform 경로를 구성할 수 있습니다. 비밀을 통해 외부에서 관리되는 TLS 인증서를 참조할 수 있으므로 수동으로 인증서를 관리할 필요가 없습니다. 외부에서 관리되는 인증서를 사용하면 오류가 줄어들어 인증서 업데이트가 보다 원활하게 진행되고, OpenShift 라우터가 갱신된 인증서를 즉시 제공할 수 있습니다.

참고

이 기능은 에지 경로와 재암호화 경로 모두에 적용됩니다.

사전 요구 사항

RouteExternalCertificate 기능 게이트를 활성화해야 합니다.
routes/custom-host 하위 리소스에 대한 생성 권한이 있는데, 이 권한은 경로를 생성하고 업데이트하는 데 사용됩니다.
kubernetes.io/tls 유형의 PEM 인코딩된 유효한 인증서/키 쌍이 포함된 비밀이 있어야 하며, 여기에는 tls.key 및 tls.crt 키가 모두 포함됩니다.
보호하려는 경로와 동일한 네임스페이스에 참조된 비밀을 배치해야 합니다.

프로세스

다음 명령을 실행하여 라우터 서비스 계정에 읽기 액세스를 허용하기 위해 비밀과 동일한 네임스페이스에 역할을 만듭니다.
```
oc create role secret-reader --verb=get,list,watch --resource=secrets --resource-name=<secret-name> \
--namespace=<current-namespace>
```
```
$ oc create role secret-reader --verb=get,list,watch --resource=secrets --resource-name=<secret-name> \ 
```
1
```
--namespace=<current-namespace> 
```
2
Copy to Clipboard Toggle word wrap
1
비밀번호의 실제 이름을 지정하세요.
2
시크릿과 경로가 모두 있는 네임스페이스를 지정합니다.
비밀과 동일한 네임스페이스에 역할 바인딩을 만들고 다음 명령을 실행하여 라우터 서비스 계정을 새로 만든 역할에 바인딩합니다.
```
oc create rolebinding secret-reader-binding --role=secret-reader --serviceaccount=openshift-ingress:router --namespace=<current-namespace>
```
```
$ oc create rolebinding secret-reader-binding --role=secret-reader --serviceaccount=openshift-ingress:router --namespace=<current-namespace> 
```
1
Copy to Clipboard Toggle word wrap
1
시크릿과 경로가 모두 있는 네임스페이스를 지정합니다.

다음 예를 사용하여 경로를 정의하고 인증서가 포함된 비밀번호를 지정하는 YAML 파일을 만듭니다.

보안 경로의 YAML 정의

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: myedge
  namespace: test
spec:
  host: myedge-test.apps.example.com
  tls:
    externalCertificate:
      name: <secret-name> 
    termination: edge
    [...]
[...]

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: myedge
  namespace: test
spec:
  host: myedge-test.apps.example.com
  tls:
    externalCertificate:
      name: <secret-name>


    termination: edge
    [...]
[...]

Copy to Clipboard

Toggle word wrap

1: 비밀번호의 실제 이름을 지정하세요.

다음 명령을 실행하여 경로 리소스를 만듭니다.
```
oc apply -f <route.yaml>
```
```
$ oc apply -f <route.yaml> 
```
1
Copy to Clipboard Toggle word wrap
1
생성된 YAML 파일 이름을 지정합니다.

비밀이 존재하고 인증서/키 쌍이 있는 경우, 모든 전제 조건이 충족되면 라우터는 생성된 인증서를 제공합니다.

참고

.spec.tls.externalCertificate가 제공되지 않으면 라우터는 기본으로 생성된 인증서를 사용합니다.

.spec.tls.externalCertificate 필드를 사용하는 경우 .spec.tls.certificate 필드나 .spec.tls.key 필드를 제공할 수 없습니다.

2장. 수신 클러스터 트래픽 구성
링크 복사

2.1. 수신 클러스터 트래픽 구성 개요
링크 복사

OpenShift Container Platform에서는 다음 방법을 통해 클러스터에서 실행되는 서비스와 클러스터 외부에서 통신할 수 있습니다.

순서 또는 기본 설정에 따라 권장되는 방법입니다.

HTTP/HTTPS가 있는 경우 Ingress 컨트롤러를 사용합니다.
HTTPS 이외의 TLS 암호화 프로토콜이 있는 경우(예: SNI 헤더가 있는 TLS), Ingress 컨트롤러를 사용합니다.
그 외에는 로드 밸런서, 외부 IP 또는 NodePort를 사용합니다.

Expand

방법	목적
Ingress 컨트롤러 사용	HTTPS 이외의 HTTP/HTTPS 트래픽 및 TLS 암호화 프로토콜(예: SNI 헤더가 있는 TLS)에 액세스할 수 있습니다.
로드 밸런서 서비스를 사용하여 외부 IP 자동 할당	풀에서 할당된 IP 주소를 통해 비표준 포트로의 트래픽을 허용합니다. 대부분의 클라우드 플랫폼은 로드 밸런서 IP 주소로 서비스를 시작하는 방법을 제공합니다.
MetalLB 및 MetalLB Operator 정보	시스템 네트워크의 풀에서 특정 IP 주소 또는 주소로의 트래픽을 허용합니다. 베어 메탈과 같은 베어 메탈 설치 또는 플랫폼의 경우 MetalLB는 로드 밸런서 IP 주소로 서비스를 시작하는 방법을 제공합니다.
서비스에 외부 IP를 수동으로 할당	특정 IP 주소를 통해 비표준 포트로의 트래픽을 허용합니다.
`NodePort` 구성	클러스터의 모든 노드에 서비스를 공개합니다.

2.1.1. 비교: 외부 IP 주소에 대한 내결함성 액세스
링크 복사

외부 IP 주소에 대한 액세스를 제공하는 통신 방법의 경우 IP 주소에 대한 내결함성 액세스를 고려해야 합니다. 다음 기능은 외부 IP 주소에 대한 내결함성 액세스를 제공합니다.

IP 페일오버: IP 페일오버는 노드 집합의 가상 IP 주소 풀을 관리합니다. Keepalived 및 VRRP(Virtual Router Redundancy Protocol)로 구현됩니다. IP 페일오버는 계층 2 메커니즘일 뿐이며 멀티캐스트를 사용합니다. 멀티캐스트에는 일부 네트워크에 대한 단점이 있을 수 있습니다.
MetalLB: MetalLB에는 계층 2 모드가 있지만 멀티캐스트를 사용하지 않습니다. 계층 2 모드에는 하나의 노드를 통해 외부 IP 주소에 대한 모든 트래픽을 전송하는 단점이 있습니다.
수동으로 외부 IP 주소 할당: 외부 IP 주소를 서비스에 할당하는 데 사용되는 IP 주소 블록을 사용하여 클러스터를 구성할 수 있습니다. 이 기능은 기본적으로 비활성화되어 있습니다. 이 기능은 유연하지만 클러스터 또는 네트워크 관리자에게 가장 큰 부담이 됩니다. 클러스터는 외부 IP로 향하는 트래픽을 수신할 준비가 되지만 각 고객은 트래픽을 노드로 라우팅하는 방법을 결정해야 합니다.

2.2. 서비스의 ExternalIP 구성
링크 복사

클러스터 관리자는 클러스터 외부의 IP 주소 블록을 선택하여 클러스터 내 서비스로 트래픽을 전송할 수 있습니다.

이 기능은 일반적으로 베어 메탈 하드웨어에 설치된 클러스터에 가장 유용합니다.

2.2.1. 사전 요구 사항
링크 복사

네트워크 인프라는 외부 IP 주소에 대한 트래픽을 클러스터로 라우팅해야 합니다.

2.2.2. ExternalIP 정보
링크 복사

클라우드가 아닌 환경에서 OpenShift Container Platform은 서비스 객체의 spec.externalIPs[] 매개변수에서 외부 IP 주소를 지정하기 위해 ExternalIP 기능을 사용할 수 있도록 지원합니다. ExternalIP로 구성된 서비스는 type=NodePort 인 서비스와 유사하게 작동합니다. 즉, 트래픽이 부하 분산을 위해 로컬 노드로 전송됩니다.

중요

클라우드 환경의 경우, 로드 밸런서 서비스를 사용하면 클라우드 로드 밸런서를 자동으로 배포하여 서비스의 엔드포인트를 타겟팅할 수 있습니다.

매개변수에 대한 값을 지정하면 OpenShift Container Platform이 서비스에 추가 가상 IP 주소를 할당합니다. IP 주소는 클러스터에 대해 정의한 서비스 네트워크 외부에 존재할 수 있습니다.

주의

ExternalIP는 기본적으로 비활성화되어 있으므로 ExternalIP 기능을 활성화하면 클러스터 내 트래픽이 외부 IP 주소로 전달되어 해당 서비스에 보안 위험이 발생할 수 있습니다. 이 구성은 클러스터 사용자가 외부 리소스를 대상으로 하는 중요한 트래픽을 가로챌 수 있음을 의미합니다.

다음과 같은 방법으로 MetalLB 구현이나 IP 장애 조치 배포를 사용하여 ExternalIP 리소스를 서비스에 연결할 수 있습니다.

외부 IP 자동 할당: OpenShift Container Platform에서는 spec.type=LoadBalancer가 설정된Service 오브젝트를 생성할 때 autoAssignCIDRs CIDR 블록의 IP 주소를 spec.externalIPs[] 배열에 자동으로 할당합니다. 이 구성의 경우, OpenShift Container Platform은 로드 밸런서 서비스 유형의 클라우드 버전을 구현하고 서비스에 IP 주소를 할당합니다. 자동 할당은 기본적으로 비활성화되어 있으며 "ExternalIP 구성" 섹션에 설명된 대로 클러스터 관리자가 구성해야 합니다.
외부 IP 수동 할당: OpenShift Container Platform에서는 Service 오브젝트를 생성할 때 spec.externalIPs[] 배열에 할당된 IP 주소를 사용합니다. 다른 서비스에서 이미 사용 중인 IP 주소는 지정할 수 없습니다.

MetalLB 구현이나 IP 장애 조치 배포를 사용하여 외부 IP 주소 블록을 호스팅한 후에는 외부 IP 주소 블록이 클러스터로 라우팅되도록 네트워킹 인프라를 구성해야 합니다. 이 구성은 노드의 네트워크 인터페이스에 IP 주소가 구성되지 않았음을 의미합니다. 트래픽을 처리하려면 정적 주소 확인 프로토콜(ARP) 항목과 같은 방법을 사용하여 외부 IP에 대한 라우팅과 액세스를 구성해야 합니다.

OpenShift Container Platform은 다음 기능을 추가하여 Kubernetes의 ExternalIP 기능을 확장합니다.

구성 가능한 정책을 통해 사용자가 외부 IP 주소 사용 제한
요청 시 서비스에 자동으로 외부 IP 주소 할당

2.2.3. ExternalIP 구성
링크 복사

Network.config.openshift.io 사용자 지정 리소스(CR)의 다음 매개변수는 OpenShift Container Platform에서 외부 IP 주소 사용을 제어합니다.

spec.externalIP.autoAssignCIDRs는 서비스에 대한 외부 IP 주소를 선택할 때 로드 밸런서에서 사용하는 IP 주소 블록을 정의합니다. OpenShift Container Platform에서는 자동 할당에 대해 하나의 IP 주소 블록만 지원합니다. 이 구성은 제한된 수의 공유 IP 주소에 대한 포트 공간을 관리해야 하는 서비스에 ExternalIP를 수동으로 할당하는 것보다 단계가 덜 필요합니다. 자동 할당을 활성화하면 Cloud Controller Manager Operator가 구성에서 spec.type=LoadBalancer 로 정의된 서비스 개체에 외부 IP 주소를 할당합니다.
spec.externalIP.policy는 IP 주소를 수동으로 지정할 때 허용되는 IP 주소 블록을 정의합니다. OpenShift Container Platform은 spec.externalIP.autoAssignCIDRs 매개변수에서 정의한 IP 주소 블록에 정책 규칙을 적용하지 않습니다.

올바르게 라우팅되면 구성된 외부 IP 주소 블록의 외부 트래픽이 서비스에서 노출하는 TCP 또는 UDP 포트를 통해 서비스 끝점에 도달할 수 있습니다.

중요

클러스터 관리자는 외부 IP로의 라우팅을 구성해야 합니다. 또한 할당한 IP 주소 블록이 클러스터의 하나 이상의 노드에서 종료되는지 확인해야 합니다. 자세한 내용은 Kubernetes 외부 IP를 참조하세요.

OpenShift Container Platform은 자동 및 수동 IP 주소 할당을 모두 지원합니다. 이 지원은 각 주소가 최대 하나의 서비스에만 할당되고, 각 서비스는 다른 서비스에서 노출된 포트에 관계없이 선택한 포트를 노출할 수 있음을 보장합니다.

참고

OpenShift Container Platform에서 autoAssignCIDR로 정의된 IP 주소 블록을 사용하려면 호스트 네트워크에 필요한 IP 주소 할당 및 라우팅을 구성해야 합니다.

다음 YAML에서는 외부 IP 주소가 구성된 서비스를 설명합니다.

spec.externalIPs[]가 설정된 Service 오브젝트의 예

apiVersion: v1
kind: Service
metadata:
  name: http-service
spec:
  clusterIP: 172.30.163.110
  externalIPs:
  - 192.168.132.253
  externalTrafficPolicy: Cluster
  ports:
  - name: highport
    nodePort: 31903
    port: 30102
    protocol: TCP
    targetPort: 30102
  selector:
    app: web
  sessionAffinity: None
  type: LoadBalancer
status:
  loadBalancer:
    ingress:
    - ip: 192.168.132.253
# ...

apiVersion: v1
kind: Service
metadata:
  name: http-service
spec:
  clusterIP: 172.30.163.110
  externalIPs:
  - 192.168.132.253
  externalTrafficPolicy: Cluster
  ports:
  - name: highport
    nodePort: 31903
    port: 30102
    protocol: TCP
    targetPort: 30102
  selector:
    app: web
  sessionAffinity: None
  type: LoadBalancer
status:
  loadBalancer:
    ingress:
    - ip: 192.168.132.253
# ...

Copy to Clipboard

Toggle word wrap

클라우드 제공자 플랫폼에서 개인 클러스터를 실행하는 경우 다음 패치 명령을 실행하여 Ingress Controller의 로드 밸런서에 대한 게시 범위를 내부로 변경할 수 있습니다.

oc -n openshift-ingress-operator patch ingresscontrollers/ingress-controller-with-nlb --type=merge --patch='{"spec":{"endpointPublishingStrategy":{"loadBalancer":{"scope":"Internal"}}}}'

$ oc -n openshift-ingress-operator patch ingresscontrollers/ingress-controller-with-nlb --type=merge --patch='{"spec":{"endpointPublishingStrategy":{"loadBalancer":{"scope":"Internal"}}}}'

Copy to Clipboard

Toggle word wrap

이 명령을 실행하면 Ingress Controller는 OpenShift Container Platform 애플리케이션의 경로에 대한 액세스를 내부 네트워크로만 제한합니다.

2.2.4. 외부 IP 주소 할당 제한 사항
링크 복사

클러스터 관리자는 서비스에 대한 IP 주소를 허용하거나 거부하기 위해 IP 주소 블록을 지정할 수 있습니다. 제한 사항은 cluster-admin 권한이 없는 사용자에게만 적용됩니다. 클러스터 관리자는 서비스 spec.externalIPs[] 필드를 IP 주소로 항상 설정할 수 있습니다.

정책 개체의 spec.ExternalIP.policy 매개변수에 대해 CIDR(Classless Inter-Domain Routing) 주소 블록을 지정하여 IP 주소 정책을 구성합니다.

정책 객체와 CIDR 매개변수의 JSON 형식 예

{
  "policy": {
    "allowedCIDRs": [],
    "rejectedCIDRs": []
  }
}

{
  "policy": {
    "allowedCIDRs": [],
    "rejectedCIDRs": []
  }
}

Copy to Clipboard

Toggle word wrap

정책 제한을 구성할 때는 다음 규칙이 적용됩니다.

정책이 {} 로 설정된 경우 spec.ExternalIPs[] 로 서비스 객체를 생성하면 서비스가 실패합니다. 이 설정은 OpenShift Container Platform의 기본값입니다. policy: null 에도 동일한 동작이 있습니다.
policy가 설정되고 policy.allowedCIDRs[] 또는 policy.rejectedCIDRs[]가 설정된 경우 다음 규칙이 적용됩니다.
- allowedCIDRs[] 와 deniedCIDRs[]가 모두 설정된 경우 deniedCIDRs[] 가 allowedCIDRs[] 보다 우선합니다.
- allowedCIDRs[]가 설정된 경우, 지정된 IP 주소가 허용되는 경우에만 spec.ExternalIPs[] 로 서비스 객체를 만드는 것이 성공합니다.
- deniedCIDRs[]가 설정된 경우, 지정된 IP 주소가 거부되지 않는 경우에만 spec.ExternalIPs[] 로 서비스 객체를 만드는 것이 성공합니다.

2.2.5. 정책 오브젝트의 예
링크 복사

이 섹션의 예에서는 다양한 spec.externalIP.policy 구성을 보여줍니다.

다음 예에서 정책은 OpenShift Container Platform이 지정된 외부 IP 주소로 서비스를 생성하는 것을 방지합니다.
Service 오브젝트 spec.externalIPs[]에 지정된 값을 거부하는 정책의 예
```
apiVersion: config.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  externalIP:
    policy: {}
# ...
```
```
apiVersion: config.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  externalIP:
    policy: {}
# ...
```
Copy to Clipboard Toggle word wrap

다음 예에서는 allowedCIDRs 및 rejectedCIDRs 필드가 모두 설정되어 있습니다.

허용되거나 거부된 CIDR 블록을 모두 포함하는 정책의 예

apiVersion: config.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  externalIP:
    policy:
      allowedCIDRs:
      - 172.16.66.10/23
      rejectedCIDRs:
      - 172.16.66.10/24
# ...

apiVersion: config.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  externalIP:
    policy:
      allowedCIDRs:
      - 172.16.66.10/23
      rejectedCIDRs:
      - 172.16.66.10/24
# ...

Copy to Clipboard

Toggle word wrap

다음 예에서는 정책이 {} 로 설정됩니다. 이 구성을 사용하면 oc get networks.config.openshift.io -o yaml 명령을 사용하여 구성을 볼 때 정책 매개변수가 명령 출력에 표시되지 않습니다. policy: null 에도 동일한 동작이 있습니다.
Service 오브젝트 spec.externalIPs[]에 지정된 값을 허용하는 정책의 예
```
apiVersion: config.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  externalIP:
    policy: {}
# ...
```
```
apiVersion: config.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  externalIP:
    policy: {}
# ...
```
Copy to Clipboard Toggle word wrap

2.2.6. ExternalIP 주소 블록 구성
링크 복사

ExternalIP 주소 블록에 대한 구성은 cluster라는 네트워크 CR(사용자 정의 리소스)에 의해 정의됩니다. 네트워크 CR은 config.openshift.io API 그룹의 일부입니다.

중요

CVO(Cluster Version Operator)는 클러스터를 설치하는 동안 cluster라는 네트워크 CR을 자동으로 생성합니다. 이 유형의 다른 CR 오브젝트는 생성할 수 없습니다.

다음 YAML에서는 ExternalIP 구성을 설명합니다.

cluster라는 Network.config.openshift.io CR

apiVersion: config.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  externalIP:
    autoAssignCIDRs: [] 
    policy: 
      ...

apiVersion: config.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  externalIP:
    autoAssignCIDRs: []


    policy:

...

Copy to Clipboard

Toggle word wrap

1: 서비스에 대한 외부 IP 주소 자동 할당에 사용할 수 있는 CIDR 형식으로 IP 주소 블록을 정의합니다. 단일 IP 주소 범위만 허용됩니다.
2: 서비스에 대한 IP 주소 수동 할당에 대한 제한을 정의합니다. 제한이 정의되지 않은 경우 Service에서 spec.externalIP 필드를 지정할 수 없습니다. 기본적으로는 제한이 정의되어 있지 않습니다.

다음 YAML에서는 policy 스탠자의 필드를 설명합니다.

Network.config.openshift.io policy 스탠자

policy:
  allowedCIDRs: [] 
  rejectedCIDRs: []

policy:
  allowedCIDRs: []


  rejectedCIDRs: []

Copy to Clipboard

Toggle word wrap

1: CIDR 형식의 허용된 IP 주소 범위 목록입니다.
2: CIDR 형식의 거부된 IP 주소 범위 목록입니다.

외부 IP 구성의 예

외부 IP 주소 풀에 사용 가능한 몇 가지 구성이 다음 예에 표시되어 있습니다.

다음 YAML에서는 자동으로 할당된 외부 IP 주소를 사용하는 구성을 설명합니다.

spec.externalIP.autoAssignCIDRs가 설정된 구성의 예

apiVersion: config.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  ...
  externalIP:
    autoAssignCIDRs:
    - 192.168.132.254/29

apiVersion: config.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  ...
  externalIP:
    autoAssignCIDRs:
    - 192.168.132.254/29

Copy to Clipboard

Toggle word wrap

다음 YAML에서는 허용되거나 거부된 CIDR 범위에 대한 정책 규칙을 구성합니다.

spec.externalIP.policy가 설정된 구성의 예

apiVersion: config.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  ...
  externalIP:
    policy:
      allowedCIDRs:
      - 192.168.132.0/29
      - 192.168.132.8/29
      rejectedCIDRs:
      - 192.168.132.7/32

apiVersion: config.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  ...
  externalIP:
    policy:
      allowedCIDRs:
      - 192.168.132.0/29
      - 192.168.132.8/29
      rejectedCIDRs:
      - 192.168.132.7/32

Copy to Clipboard

Toggle word wrap

2.2.7. 클러스터에 대한 외부 IP 주소 블록 구성
링크 복사

클러스터 관리자는 다음 ExternalIP 설정을 구성할 수 있습니다.

Service 오브젝트의 spec.clusterIP 필드를 자동으로 채우도록 OpenShift Container Platform에서 사용하는 ExternalIP 주소 블록입니다.
Service 오브젝트의 spec.clusterIP 배열에 수동으로 할당할 수 있는 IP 주소를 제한하는 정책 오브젝트입니다.

사전 요구 사항

OpenShift CLI(oc)를 설치합니다.
cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.

프로세스

선택 사항: 현재 외부 IP 구성을 표시하려면 다음 명령을 입력합니다.
```
oc describe networks.config cluster
```
```
$ oc describe networks.config cluster
```
Copy to Clipboard Toggle word wrap
구성을 편집하려면 다음 명령을 입력합니다.
```
oc edit networks.config cluster
```
```
$ oc edit networks.config cluster
```
Copy to Clipboard Toggle word wrap

다음 예와 같이 ExternalIP 구성을 수정합니다.

apiVersion: config.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  ...
  externalIP: 
  ...

apiVersion: config.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  ...
  externalIP:

...

Copy to Clipboard

Toggle word wrap

1: externalIP 스탠자에 대한 구성을 지정합니다.

업데이트된 ExternalIP 구성을 확인하려면 다음 명령을 입력합니다.

oc get networks.config cluster -o go-template='{{.spec.externalIP}}{{"\n"}}'

$ oc get networks.config cluster -o go-template='{{.spec.externalIP}}{{"\n"}}'

Copy to Clipboard

Toggle word wrap

2.2.9. 다음 단계
링크 복사

서비스 외부 IP에 대한 수신 클러스터 트래픽 구성

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 Toggle word wrap
최소한 하나의 마스터와 최소한 하나의 노드가 있는 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 Toggle word wrap

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

Toggle word wrap

서비스가 생성되었는지 확인하려면 다음 명령을 실행하세요.

oc get svc -n <project_name>

$ oc get svc -n <project_name>

Copy to Clipboard

Toggle word wrap

출력 예

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

Toggle word wrap

참고

기본적으로 새 서비스에는 외부 IP 주소가 없습니다.

2.3.4. 경로를 생성하여 서비스 노출
링크 복사

oc expose 명령을 사용하여 서비스를 경로로 노출할 수 있습니다.

사전 요구 사항

OpenShift Container Platform에 로그인했습니다.

프로세스

노출하려는 서비스가 있는 프로젝트에 로그인합니다.
```
oc project <project_name>
```
```
$ oc project <project_name>
```
Copy to Clipboard Toggle word wrap
oc expose service 명령을 실행하여 경로를 노출합니다.
```
oc expose service nodejs-ex
```
```
$ oc expose service nodejs-ex
```
Copy to Clipboard Toggle word wrap
출력 예
```
route.route.openshift.io/nodejs-ex exposed
```
```
route.route.openshift.io/nodejs-ex exposed
```
Copy to Clipboard Toggle word wrap
서비스가 노출되었는지 확인하려면 curl 과 같은 도구를 사용하여 클러스터 외부에서 서비스에 액세스할 수 있는지 확인할 수 있습니다.
1. 경로의 호스트 이름을 찾으려면 다음 명령을 입력하세요.
  $ oc get route
  Copy to Clipboard Toggle word wrap
  출력 예
  NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD nodejs-ex nodejs-ex-myproject.example.com nodejs-ex 8080-tcp None
  
  Copy to Clipboard Toggle word wrap
2. 호스트가 GET 요청에 응답하는지 확인하려면 다음 명령을 입력하세요.
  curl 명령 예시
  $ curl --head nodejs-ex-myproject.example.com
  
  Copy to Clipboard Toggle word wrap
  출력 예
  HTTP/1.1 200 OK ...
  
  Copy to Clipboard Toggle word wrap

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 컨트롤러에 분산할 수 있습니다. 이러한 하위 집합은 겹치지 않는 샤딩( 기존 샤딩이라고도 함)이거나 겹치는 샤딩( 중첩 샤딩이라고도 함)일 수 있습니다.

다음 표는 세 가지 샤딩 방법을 간략하게 설명합니다.

Expand

샤딩 방식	설명
네임스페이스 선택기	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 정의 예

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: finops-router
  namespace: openshift-ingress-operator
spec:
  namespaceSelector:
    matchExpressions:
    - key: name
      operator: In
      values:
      - finance
      - ops

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: finops-router
  namespace: openshift-ingress-operator
spec:
  namespaceSelector:
    matchExpressions:
    - key: name
      operator: In
      values:
      - finance
      - ops

Copy to Clipboard

Toggle word wrap

레이블 선택기 spec.namespaceSelector.matchLabels.name 과 키 값이 dev 로 설정된 구성된 Ingress Controller dev-router 의 예:

dev-router 에 대한 YAML 정의 예

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: dev-router
  namespace: openshift-ingress-operator
spec:
  namespaceSelector:
    matchLabels:
      name: dev

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: dev-router
  namespace: openshift-ingress-operator
spec:
  namespaceSelector:
    matchLabels:
      name: dev

Copy to Clipboard

Toggle word wrap

모든 애플리케이션 경로가 별도의 네임스페이스에 있는 경우(예 : 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 정의 예시

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: devops-router
  namespace: openshift-ingress-operator
spec:
  namespaceSelector:
    matchExpressions:
    - key: name
      operator: In
      values:
      - dev
      - ops

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: devops-router
  namespace: openshift-ingress-operator
spec:
  namespaceSelector:
    matchExpressions:
    - key: name
      operator: In
      values:
      - dev
      - ops

Copy to Clipboard

Toggle word wrap

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 Toggle word wrap

finance , ops , dev 레이블이 있는 경로를 제외하는 namespaceSelector를 포함하도록 Ingress Controller를 편집합니다.

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: default
  namespace: openshift-ingress-operator
spec:
  namespaceSelector:
    matchExpressions:
      - key: name
        operator: NotIn
        values:
          - finance
          - ops
          - dev

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: default
  namespace: openshift-ingress-operator
spec:
  namespaceSelector:
    matchExpressions:
      - key: name
        operator: NotIn
        values:
          - finance
          - ops
          - dev

Copy to Clipboard

Toggle word wrap

기본 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 컨트롤러에 균형 있게 분배하고 트래픽을 특정 Ingress 컨트롤러에 격리할 때 유용합니다. 예를 들어, 회사 A는 하나의 Ingress 컨트롤러로, 회사 B는 다른 Ingress 컨트롤러로 이동합니다.

프로세스

router-internal.yaml 파일을 다음과 같이 편집합니다.

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: sharded
  namespace: openshift-ingress-operator
spec:
  domain: <apps-sharded.basedomain.example.net> 
  nodePlacement:
    nodeSelector:
      matchLabels:
        node-role.kubernetes.io/worker: ""
  routeSelector:
    matchLabels:
      type: sharded

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: sharded
  namespace: openshift-ingress-operator
spec:
  domain: <apps-sharded.basedomain.example.net>


  nodePlacement:
    nodeSelector:
      matchLabels:
        node-role.kubernetes.io/worker: ""
  routeSelector:
    matchLabels:
      type: sharded

Copy to Clipboard

Toggle word wrap

1: Ingress Controller에서 사용할 도메인을 지정합니다. 이 도메인은 기본 Ingress Controller 도메인과 달라야 합니다.

Ingress 컨트롤러 router-internal.yaml 파일을 적용합니다.
```
oc apply -f router-internal.yaml
```
```
# oc apply -f router-internal.yaml
```
Copy to Clipboard Toggle word wrap
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

Toggle word wrap

2.3.6.6. 네임스페이스 라벨을 사용하여 Ingress 컨트롤러 분할 구성
링크 복사

네임스페이스 라벨을 사용한 Ingress 컨트롤러 분할이란 Ingress 컨트롤러가 네임스페이스 선택기에서 선택한 모든 네임스페이스의 모든 경로를 제공한다는 뜻입니다.

그림 2.2. 네임스페이스 레이블을 사용한 Ingress 샤딩

주어진 네임스페이스 선택기와 일치하는 레이블을 포함하는 네임스페이스에 속하는 경로를 제공하는 서로 다른 네임스페이스 선택기를 가진 여러 Ingress 컨트롤러를 보여주는 다이어그램

프로세스

router-internal.yaml 파일을 다음과 같이 편집합니다.

cat router-internal.yaml

$ cat router-internal.yaml

Copy to Clipboard

Toggle word wrap

출력 예

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: sharded
  namespace: openshift-ingress-operator
spec:
  domain: <apps-sharded.basedomain.example.net> 
  nodePlacement:
    nodeSelector:
      matchLabels:
        node-role.kubernetes.io/worker: ""
  namespaceSelector:
    matchLabels:
      type: sharded

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: sharded
  namespace: openshift-ingress-operator
spec:
  domain: <apps-sharded.basedomain.example.net>


  nodePlacement:
    nodeSelector:
      matchLabels:
        node-role.kubernetes.io/worker: ""
  namespaceSelector:
    matchLabels:
      type: sharded

Copy to Clipboard

Toggle word wrap

1: Ingress Controller에서 사용할 도메인을 지정합니다. 이 도메인은 기본 Ingress Controller 도메인과 달라야 합니다.

Ingress 컨트롤러 router-internal.yaml 파일을 적용합니다.
```
oc apply -f router-internal.yaml
```
```
$ oc apply -f router-internal.yaml
```
Copy to Clipboard Toggle word wrap
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

Toggle word wrap

2.3.6.7. Ingress Controller 샤딩을 위한 경로 생성
링크 복사

다음 절차에서는 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 Toggle word wrap

다음 명령을 실행하여 프로젝트에 포드를 만듭니다.

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

Toggle word wrap

다음 명령을 실행하여 hello-openshift 라는 서비스를 만듭니다.
```
oc expose pod/hello-openshift
```
```
$ oc expose pod/hello-openshift
```
Copy to Clipboard Toggle word wrap
hello-openshift-route.yaml 이라는 경로 정의를 만듭니다.
샤딩을 위해 생성된 경로의 YAML 정의
```
apiVersion: route.openshift.io/v1
kind: Route
metadata:
  labels:
    type: sharded 
  name: hello-openshift-edge
  namespace: hello-openshift
spec:
  subdomain: hello-openshift 
  tls:
    termination: edge
  to:
    kind: Service
    name: hello-openshift
```
```
apiVersion: route.openshift.io/v1
kind: Route
metadata:
  labels:
    type: sharded 
```
1
```
  name: hello-openshift-edge
  namespace: hello-openshift
spec:
  subdomain: hello-openshift 
```
2
```
  tls:
    termination: edge
  to:
    kind: Service
    name: hello-openshift
```
Copy to Clipboard Toggle word wrap
1
레이블 키와 해당 레이블 값은 모두 Ingress Controller에 지정된 것과 일치해야 합니다. 이 예에서 Ingress Controller에는 레이블 키와 값 유형이 있습니다: sharded .
2
경로는 하위 도메인 필드의 값을 사용하여 노출됩니다. 하위 도메인 필드를 지정할 때는 호스트 이름을 설정하지 않아야 합니다. 호스트 와 하위 도메인 필드를 모두 지정하면 경로는 호스트 필드의 값을 사용하고 하위 도메인 필드는 무시합니다.
다음 명령을 실행하여 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 Toggle word wrap

검증

다음 명령을 사용하여 경로 상태를 확인하세요.

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

Toggle word wrap

결과적으로 생성된 Route 리소스는 다음과 유사해야 합니다.

출력 예

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  labels:
    type: sharded
  name: hello-openshift-edge
  namespace: hello-openshift
spec:
  subdomain: hello-openshift
  tls:
    termination: edge
  to:
    kind: Service
    name: hello-openshift
status:
  ingress:
  - host: hello-openshift.<apps-sharded.basedomain.example.net> 
    routerCanonicalHostname: router-sharded.<apps-sharded.basedomain.example.net> 
    routerName: sharded

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  labels:
    type: sharded
  name: hello-openshift-edge
  namespace: hello-openshift
spec:
  subdomain: hello-openshift
  tls:
    termination: edge
  to:
    kind: Service
    name: hello-openshift
status:
  ingress:
  - host: hello-openshift.<apps-sharded.basedomain.example.net>


    routerCanonicalHostname: router-sharded.<apps-sharded.basedomain.example.net>


    routerName: sharded

Copy to Clipboard

Toggle word wrap

1: Ingress 컨트롤러 또는 라우터가 경로를 노출하는 데 사용하는 호스트 이름입니다. 호스트 필드의 값은 Ingress Controller에 의해 자동으로 결정되며 해당 도메인을 사용합니다. 이 예에서 Ingress Controller의 도메인은 <apps-sharded.basedomain.example.net> 입니다.
2: Ingress Controller의 호스트 이름입니다. 호스트 이름이 설정되지 않으면 경로는 대신 하위 도메인을 사용할 수 있습니다. 하위 도메인을 지정하면 경로를 노출하는 Ingress Controller의 도메인이 자동으로 사용됩니다. 경로가 여러 Ingress 컨트롤러에 의해 노출되는 경우 해당 경로는 여러 URL에서 호스팅됩니다.
3: Ingress Controller의 이름입니다. 이 예에서 Ingress Controller의 이름은 sharded 입니다.

추가 리소스

2.4. Ingress Controller 엔드포인트 게시 전략 구성
링크 복사

endpointPublishingStrategy 는 Ingress Controller 엔드포인트를 다른 네트워크에 게시하고, 로드 밸런서 통합을 활성화하고, 다른 시스템에 대한 액세스를 제공하는 데 사용됩니다.

중요

Red Hat OpenStack Platform(RHOSP)에서 LoadBalancerService 엔드포인트 게시 전략은 클라우드 공급자가 상태 모니터를 생성하도록 구성된 경우에만 지원됩니다. RHOSP 16.2의 경우 Amphora Octavia 공급자를 사용하는 경우에만 이 전략이 가능합니다.

자세한 내용은 RHOSP 설치 설명서의 "RHOSP Cloud Controller Manager 옵션 설정" 섹션을 참조하세요.

2.4.1. Ingress Controller 엔드포인트 게시 전략
링크 복사

NodePortService 끝점 게시 전략

NodePortService 끝점 게시 전략에서는 Kubernetes NodePort 서비스를 사용하여 Ingress 컨트롤러를 게시합니다.

이 구성에서는 Ingress 컨트롤러를 배포하기 위해 컨테이너 네트워킹을 사용합니다. 배포를 게시하기 위해 NodePortService가 생성됩니다. 특정 노드 포트는 OpenShift Container Platform에 의해 동적으로 할당됩니다. 그러나 정적 포트 할당을 지원하기 위해 관리형 NodePortService의 노드 포트 필드에 대한 변경 사항은 유지됩니다.

그림 2.3. NodePortService 다이어그램

OpenShift 컨테이너 플랫폼 Ingress NodePort 엔드포인트 게시 전략

위의 그래픽은 OpenShift Container Platform Ingress NodePort 엔드포인트 게시 전략과 관련된 다음 개념을 보여줍니다.

클러스터 내의 모든 사용 가능한 노드는 자체적으로 외부에서 접근 가능한 IP 주소를 가지고 있습니다. 클러스터에서 실행되는 서비스는 모든 노드의 고유한 NodePort에 바인딩됩니다.
예를 들어, 클라이언트가 다운된 노드에 연결하는 경우(그래픽의 IP 주소 10.0.128.4) 노드 포트는 클라이언트를 서비스를 실행 중인 사용 가능한 노드에 직접 연결합니다. 이 시나리오에서는 부하 분산이 필요하지 않습니다. 그림에서 볼 수 있듯이 10.0.128.4 주소는 다운되었으며 대신 다른 IP 주소를 사용해야 합니다.

참고

Ingress Operator는 서비스의 .spec.ports[].nodePort 필드에 대한 업데이트를 무시합니다.

기본적으로 포트는 자동으로 할당되며 통합을 위해 포트 할당에 액세스할 수 있습니다. 그러나 동적 포트에 대한 응답으로 쉽게 재구성할 수 없는 기존 인프라와 통합하기 위해 정적 포트 할당이 필요한 경우가 있습니다. 정적 노드 포트와 통합하기 위해 관리 서비스 리소스를 직접 업데이트할 수 있습니다.

자세한 내용은 NodePort에 대한 Kubernetes 서비스 설명서를 참조하십시오.

HostNetwork 끝점 게시 전략

HostNetwork 끝점 게시 전략에서는 Ingress 컨트롤러가 배포된 노드 포트에 Ingress 컨트롤러를 게시합니다.

HostNetwork 엔드포인트 게시 전략을 사용하는 Ingress Controller는 노드당 하나의 Pod 복제본만 가질 수 있습니다. n개의 복제본이 필요한 경우에는 해당 복제본을 예약할 수 있는 n개 이상의 노드를 사용해야 합니다. 각 pod 복제본은 예약된 노드 호스트에서 포트 80 및 443을 요청하므로 동일한 노드의 다른 pod가 해당 포트를 사용하는 경우 복제본을 노드에 예약할 수 없습니다.

HostNetwork 개체에는 선택적 바인딩 포트에 대한 다음 기본값을 갖는 hostNetwork 필드가 있습니다. httpPort: 80 , httpsPort: 443 , statsPort: 1936 . 네트워크에 대해 서로 다른 바인딩 포트를 지정하면 HostNetwork 전략에 대해 동일한 노드에 여러 Ingress 컨트롤러를 배포할 수 있습니다.

예

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: internal
  namespace: openshift-ingress-operator
spec:
  domain: example.com
  endpointPublishingStrategy:
    type: HostNetwork
    hostNetwork:
      httpPort: 80
      httpsPort: 443
      statsPort: 1936

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: internal
  namespace: openshift-ingress-operator
spec:
  domain: example.com
  endpointPublishingStrategy:
    type: HostNetwork
    hostNetwork:
      httpPort: 80
      httpsPort: 443
      statsPort: 1936

Copy to Clipboard

Toggle word wrap

2.4.1.1. Ingress 컨트롤러 끝점에서 내부로 게시 범위 구성
링크 복사

클러스터 관리자가 클러스터를 비공개로 지정하지 않고 새 클러스터를 설치하는 경우 기본 Ingress 컨트롤러가 생성되고 범위는 External 로 설정됩니다. 클러스터 관리자는 외부 범위의 Ingress 컨트롤러를 내부 범위 로 변경할 수 있습니다.

사전 요구 사항

oc CLI를 설치했습니다.

프로세스

외부 범위의 Ingress 컨트롤러를 내부 범위 로 변경하려면 다음 명령을 입력하세요.

oc -n openshift-ingress-operator patch ingresscontrollers/default --type=merge --patch='{"spec":{"endpointPublishingStrategy":{"type":"LoadBalancerService","loadBalancer":{"scope":"Internal"}}}}'

$ oc -n openshift-ingress-operator patch ingresscontrollers/default --type=merge --patch='{"spec":{"endpointPublishingStrategy":{"type":"LoadBalancerService","loadBalancer":{"scope":"Internal"}}}}'

Copy to Clipboard

Toggle word wrap

Ingress Controller의 상태를 확인하려면 다음 명령을 입력하세요.
```
oc -n openshift-ingress-operator get ingresscontrollers/default -o yaml
```
```
$ oc -n openshift-ingress-operator get ingresscontrollers/default -o yaml
```
Copy to Clipboard Toggle word wrap
- 진행 상태 조건은 추가 조치를 취해야 하는지 여부를 나타냅니다. 예를 들어, 상태 조건은 다음 명령을 입력하여 서비스를 삭제해야 함을 나타낼 수 있습니다.
  $ oc -n openshift-ingress delete services/router-default
  Copy to Clipboard Toggle word wrap
  서비스를 삭제하면 Ingress Operator에서 해당 서비스를 Internal 로 다시 생성합니다.

2.4.1.2. Ingress Controller 엔드포인트 게시 범위를 외부로 구성
링크 복사

클러스터 관리자가 클러스터를 비공개로 지정하지 않고 새 클러스터를 설치하는 경우 기본 Ingress 컨트롤러가 생성되고 범위는 External 로 설정됩니다.

Ingress Controller의 범위는 설치 중 또는 설치 후에 내부 로 구성할 수 있으며, 클러스터 관리자는 내부 Ingress Controller를 외부 로 변경할 수 있습니다.

중요

일부 플랫폼에서는 서비스를 삭제하고 다시 만들어야 합니다.

범위를 변경하면 Ingress 트래픽이 몇 분 동안 중단될 수 있습니다. 이는 서비스를 삭제하고 다시 만들어야 하는 플랫폼에 적용되는데, 이 절차를 수행하면 OpenShift Container Platform에서 기존 서비스 로드 밸런서의 프로비저닝을 해제하고, 새 로드 밸런서를 프로비저닝하고, DNS를 업데이트해야 할 수 있기 때문입니다.

사전 요구 사항

oc CLI를 설치했습니다.

프로세스

내부 범위의 Ingress 컨트롤러를 외부 범위 로 변경하려면 다음 명령을 입력하세요.

oc -n openshift-ingress-operator patch ingresscontrollers/private --type=merge --patch='{"spec":{"endpointPublishingStrategy":{"type":"LoadBalancerService","loadBalancer":{"scope":"External"}}}}'

$ oc -n openshift-ingress-operator patch ingresscontrollers/private --type=merge --patch='{"spec":{"endpointPublishingStrategy":{"type":"LoadBalancerService","loadBalancer":{"scope":"External"}}}}'

Copy to Clipboard

Toggle word wrap

Ingress Controller의 상태를 확인하려면 다음 명령을 입력하세요.
```
oc -n openshift-ingress-operator get ingresscontrollers/default -o yaml
```
```
$ oc -n openshift-ingress-operator get ingresscontrollers/default -o yaml
```
Copy to Clipboard Toggle word wrap
- 진행 상태 조건은 추가 조치를 취해야 하는지 여부를 나타냅니다. 예를 들어, 상태 조건은 다음 명령을 입력하여 서비스를 삭제해야 함을 나타낼 수 있습니다.
  $ oc -n openshift-ingress delete services/router-default
  Copy to Clipboard Toggle word wrap
  서비스를 삭제하면 Ingress Operator가 해당 서비스를 External 로 다시 생성합니다.

2.4.1.3. Ingress Controller에 단일 NodePort 서비스 추가
링크 복사

각 프로젝트에 대해 NodePort 유형 서비스를 만드는 대신, NodePortService 엔드포인트 게시 전략을 사용하기 위해 사용자 정의 Ingress 컨트롤러를 만들 수 있습니다. 포트 충돌을 방지하려면 이미 HostNetwork Ingress Controller가 있는 노드에 Ingress 샤딩을 통해 일련의 경로를 적용하려는 경우 Ingress Controller에 대해 이 구성을 고려하세요.

각 프로젝트에 대해 NodePort 유형 서비스를 설정하기 전에 다음 고려 사항을 읽어보세요.

Nodeport Ingress Controller 도메인에 대한 와일드카드 DNS 레코드를 만들어야 합니다. Nodeport Ingress Controller 경로는 워커 노드의 주소에서 접근할 수 있습니다. 경로에 필요한 DNS 레코드에 대한 자세한 내용은 "사용자 제공 DNS 요구 사항"을 참조하세요.
서비스에 대한 경로를 공개하고 사용자 지정 Ingress Controller 도메인에 대한 --hostname 인수를 지정해야 합니다.
애플리케이션 포드에 액세스할 수 있도록 경로에 NodePort 유형 서비스 에 할당된 포트를 추가해야 합니다.

사전 요구 사항

OpenShift CLI(oc)를 설치합니다.
클러스터 관리자 권한이 있는 사용자로 로그인했습니다.
와일드카드 DNS 레코드를 생성했습니다.

프로세스

Ingress Controller에 대한 사용자 정의 리소스(CR) 파일을 만듭니다.

IngressController 객체에 대한 정보를 정의하는 CR 파일의 예

apiVersion: v1
items:
- apiVersion: operator.openshift.io/v1
  kind: IngressController
  metadata:
    name: <custom_ic_name> 
    namespace: openshift-ingress-operator
  spec:
    replicas: 1
    domain: <custom_ic_domain_name> 
    nodePlacement:
      nodeSelector:
        matchLabels:
          <key>: <value> 
    namespaceSelector:
     matchLabels:
       <key>: <value> 
    endpointPublishingStrategy:
      type: NodePortService
# ...

apiVersion: v1
items:
- apiVersion: operator.openshift.io/v1
  kind: IngressController
  metadata:
    name: <custom_ic_name>


    namespace: openshift-ingress-operator
  spec:
    replicas: 1
    domain: <custom_ic_domain_name>


    nodePlacement:
      nodeSelector:
        matchLabels:
          <key>: <value>


    namespaceSelector:
     matchLabels:
       <key>: <value>


    endpointPublishingStrategy:
      type: NodePortService
# ...

Copy to Clipboard

Toggle word wrap

1: IngressController CR에 사용자 정의 이름을 지정합니다.
2: Ingress Controller가 서비스하는 DNS 이름입니다. 예를 들어, 기본 ingresscontroller 도메인은 apps.ipi-cluster.example.com 이므로 <custom_ic_domain_name>을 nodeportsvc.ipi-cluster.example.com 으로 지정합니다.
3: 사용자 정의 Ingress 컨트롤러를 포함하는 노드에 대한 레이블을 지정합니다.
4: 네임스페이스 집합에 대한 레이블을 지정합니다. <키>:<값>을 키-값 쌍의 맵으로 대체합니다. 여기서 <키> 는 새 레이블의 고유한 이름이고 <값> 은 해당 값입니다. 예를 들어: ingresscontroller: custom-ic .

oc label node 명령을 사용하여 노드에 레이블을 추가합니다.
```
oc label node <node_name> <key>=<value>
```
```
$ oc label node <node_name> <key>=<value> 
```
1
Copy to Clipboard Toggle word wrap
1
<value> 는 IngressController CR의 nodePlacement 섹션에 지정된 키-값 쌍과 일치해야 합니다.
IngressController 객체를 생성합니다.
```
oc create -f <ingress_controller_cr>.yaml
```
```
$ oc create -f <ingress_controller_cr>.yaml
```
Copy to Clipboard Toggle word wrap

IngressController CR에 대해 생성된 서비스의 포트를 찾으세요.

oc get svc -n openshift-ingress

$ oc get svc -n openshift-ingress

Copy to Clipboard

Toggle word wrap

router-nodeport-custom-ic3 서비스에 대한 포트 80:32432/TCP를 표시하는 예제 출력

NAME                        TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)                                     AGE
router-internal-default      ClusterIP   172.30.195.74    <none>        80/TCP,443/TCP,1936/TCP                     223d
router-nodeport-custom-ic3   NodePort    172.30.109.219   <none>        80:32432/TCP,443:31366/TCP,1936:30499/TCP   155m

NAME                        TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)                                     AGE
router-internal-default      ClusterIP   172.30.195.74    <none>        80/TCP,443/TCP,1936/TCP                     223d
router-nodeport-custom-ic3   NodePort    172.30.109.219   <none>        80:32432/TCP,443:31366/TCP,1936:30499/TCP   155m

Copy to Clipboard

Toggle word wrap

새 프로젝트를 생성하려면 다음 명령을 입력합니다.
```
oc new-project <project_name>
```
```
$ oc new-project <project_name>
```
Copy to Clipboard Toggle word wrap
새 네임스페이스에 레이블을 지정하려면 다음 명령을 입력하세요.
```
oc label namespace <project_name> <key>=<value>
```
```
$ oc label namespace <project_name> <key>=<value> 
```
1
Copy to Clipboard Toggle word wrap
1
<키>=<값> 은 Ingress Controller CR의 namespaceSelector 섹션에 있는 값과 일치해야 합니다.
클러스터에 새 애플리케이션을 만듭니다.
```
oc new-app --image=<image_name>
```
```
$ oc new-app --image=<image_name> 
```
1
Copy to Clipboard Toggle word wrap
1
<image_name> 의 예는 quay.io/openshifttest/hello-openshift:multiarch 입니다.
서비스에 대한 Route 객체를 생성하면 Pod가 서비스를 사용하여 클러스터 외부에 애플리케이션을 노출할 수 있습니다.
```
oc expose svc/<service_name> --hostname=<svc_name>-<project_name>.<custom_ic_domain_name>
```
```
$ oc expose svc/<service_name> --hostname=<svc_name>-<project_name>.<custom_ic_domain_name> 
```
1
Copy to Clipboard Toggle word wrap
참고
--hostname 인수에서 사용자 지정 Ingress 컨트롤러의 도메인 이름을 지정해야 합니다. 이렇게 하지 않으면 Ingress Operator는 기본 Ingress Controller를 사용하여 클러스터의 모든 경로를 처리합니다.

경로가 승인됨 상태인지 확인하고 사용자 지정 Ingress 컨트롤러에 대한 메타데이터가 포함되어 있는지 확인하세요.

oc get route/hello-openshift -o json | jq '.status.ingress'

$ oc get route/hello-openshift -o json | jq '.status.ingress'

Copy to Clipboard

Toggle word wrap

출력 예

...

# ...
{
  "conditions": [
    {
      "lastTransitionTime": "2024-05-17T18:25:41Z",
      "status": "True",
      "type": "Admitted"
    }
  ],
  [
    {
      "host": "hello-openshift.nodeportsvc.ipi-cluster.example.com",
      "routerCanonicalHostname": "router-nodeportsvc.nodeportsvc.ipi-cluster.example.com",
      "routerName": "nodeportsvc", "wildcardPolicy": "None"
    }
  ],
}

Copy to Clipboard

Toggle word wrap

기본 IngressController CR을 업데이트하여 기본 Ingress Controller가 NodePort 유형 서비스를 관리하지 못하도록 합니다. 기본 Ingress Controller는 다른 모든 클러스터 트래픽을 계속 모니터링합니다.

oc patch --type=merge -n openshift-ingress-operator ingresscontroller/default --patch '{"spec":{"namespaceSelector":{"matchExpressions":[{"key":"<key>","operator":"NotIn","values":["<value>]}]}}}'

$ oc patch --type=merge -n openshift-ingress-operator ingresscontroller/default --patch '{"spec":{"namespaceSelector":{"matchExpressions":[{"key":"<key>","operator":"NotIn","values":["<value>]}]}}}'

Copy to Clipboard

Toggle word wrap

검증

다음 명령을 입력하여 DNS 항목이 클러스터 내부와 외부로 라우팅될 수 있는지 확인하세요. 이 명령은 프로시저의 앞부분에서 oc label node 명령을 실행하여 레이블을 수신한 노드의 IP 주소를 출력합니다.
```
dig +short <svc_name>-<project_name>.<custom_ic_domain_name>
```
```
$ dig +short <svc_name>-<project_name>.<custom_ic_domain_name>
```
Copy to Clipboard Toggle word wrap
클러스터가 DNS 확인을 위해 외부 DNS 서버의 IP 주소를 사용하는지 확인하려면 다음 명령을 입력하여 클러스터의 연결을 확인하세요.
```
curl <svc_name>-<project_name>.<custom_ic_domain_name>:<port>
```
```
$ curl <svc_name>-<project_name>.<custom_ic_domain_name>:<port> 
```
1
Copy to Clipboard Toggle word wrap
1 1
여기서 <port> 는 NodePort 유형 서비스 의 노드 포트입니다. oc get svc -n openshift-ingress 명령의 예시 출력을 기준으로 하면 80:32432/TCP HTTP 경로는 32432 가 노드 포트임을 의미합니다.
출력 예
```
Hello OpenShift!
```
```
Hello OpenShift!
```
Copy to Clipboard Toggle word wrap

2.5. 로드 밸런서를 사용하여 수신 클러스터 트래픽 구성
링크 복사

OpenShift Container Platform에서는 클러스터에서 실행되는 서비스와 클러스터 외부에서 통신할 수 있습니다. 이 방법에서는 로드 밸런서를 사용합니다.

2.5.1. 로드 밸런서를 사용하여 클러스터로 트래픽 가져오기
링크 복사

특정 외부 IP 주소가 필요하지 않은 경우 OpenShift Container Platform 클러스터에 대한 외부 액세스를 허용하도록 로드 밸런서 서비스를 구성할 수 있습니다.

로드 밸런서 서비스에서는 고유 IP를 할당합니다. 로드 밸런서에는 VIP(가상 IP)일 수 있는 단일 엣지 라우터 IP가 있지만 이는 초기 로드 밸런싱을 위한 단일 머신에 불과합니다.

참고

풀이 구성된 경우 클러스터 관리자가 아닌 인프라 수준에서 수행됩니다.

참고

이 섹션의 절차에는 클러스터 관리자가 수행해야 하는 사전 요구 사항이 필요합니다.

2.5.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 Toggle word wrap
클러스터에 대한 네트워크 액세스 권한이 있는 마스터와 노드가 클러스터 외부에 각각 1개 이상씩 있는 OpenShift Container Platform 클러스터가 있어야 합니다. 이 절차에서는 외부 시스템이 클러스터와 동일한 서브넷에 있다고 가정합니다. 다른 서브넷에 있는 외부 시스템에 필요한 추가 네트워킹은 이 주제에서 다루지 않습니다.

2.5.3. 프로젝트 및 서비스 생성
링크 복사

공개하려는 프로젝트와 서비스가 존재하지 않는 경우 프로젝트를 생성한 다음 서비스를 생성하세요.

프로젝트와 서비스가 이미 존재하는 경우 서비스를 노출하여 경로를 생성하는 절차로 건너뜁니다.

사전 요구 사항

OpenShift CLI( oc )를 설치하고 클러스터 관리자로 로그인합니다.

프로세스

oc new-project 명령을 실행하여 서비스에 대한 새 프로젝트를 만듭니다.
```
oc new-project <project_name>
```
```
$ oc new-project <project_name>
```
Copy to Clipboard Toggle word wrap

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

Toggle word wrap

서비스가 생성되었는지 확인하려면 다음 명령을 실행하세요.

oc get svc -n <project_name>

$ oc get svc -n <project_name>

Copy to Clipboard

Toggle word wrap

출력 예

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

Toggle word wrap

참고

기본적으로 새 서비스에는 외부 IP 주소가 없습니다.

2.5.4. 경로를 생성하여 서비스 노출
링크 복사

oc expose 명령을 사용하여 서비스를 경로로 노출할 수 있습니다.

사전 요구 사항

OpenShift Container Platform에 로그인했습니다.

프로세스

노출하려는 서비스가 있는 프로젝트에 로그인합니다.
```
oc project <project_name>
```
```
$ oc project <project_name>
```
Copy to Clipboard Toggle word wrap
oc expose service 명령을 실행하여 경로를 노출합니다.
```
oc expose service nodejs-ex
```
```
$ oc expose service nodejs-ex
```
Copy to Clipboard Toggle word wrap
출력 예
```
route.route.openshift.io/nodejs-ex exposed
```
```
route.route.openshift.io/nodejs-ex exposed
```
Copy to Clipboard Toggle word wrap
서비스가 노출되었는지 확인하려면 curl 과 같은 도구를 사용하여 클러스터 외부에서 서비스에 액세스할 수 있는지 확인할 수 있습니다.
1. 경로의 호스트 이름을 찾으려면 다음 명령을 입력하세요.
  $ oc get route
  Copy to Clipboard Toggle word wrap
  출력 예
  NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD nodejs-ex nodejs-ex-myproject.example.com nodejs-ex 8080-tcp None
  
  Copy to Clipboard Toggle word wrap
2. 호스트가 GET 요청에 응답하는지 확인하려면 다음 명령을 입력하세요.
  curl 명령 예시
  $ curl --head nodejs-ex-myproject.example.com
  
  Copy to Clipboard Toggle word wrap
  출력 예
  HTTP/1.1 200 OK ...
  
  Copy to Clipboard Toggle word wrap

2.5.5. 로드 밸런서 서비스 생성
링크 복사

다음 절차에 따라 로드 밸런서 서비스를 생성합니다.

사전 요구 사항

노출하려는 프로젝트와 서비스가 존재하는지 확인합니다.
귀하의 클라우드 제공자는 로드 밸런서를 지원합니다.

프로세스

로드 밸런서 서비스를 생성하려면 다음을 수행합니다.

OpenShift Container Platform 4에 로그인합니다.
노출하려는 서비스가 있는 프로젝트를 로드합니다.
```
oc project project1
```
```
$ oc project project1
```
Copy to Clipboard Toggle word wrap
필요에 따라 컨트롤 플레인 노드에서 텍스트 파일을 열고 다음 텍스트를 붙여넣고 파일을 편집합니다.
로드 밸런서 구성 파일 샘플
```
apiVersion: v1
kind: Service
metadata:
  name: egress-2 
spec:
  ports:
  - name: db
    port: 3306 
  loadBalancerIP:
  loadBalancerSourceRanges: 
  - 10.0.0.0/8
  - 192.168.0.0/16
  type: LoadBalancer 
  selector:
    name: mysql 
```
```
apiVersion: v1
kind: Service
metadata:
  name: egress-2 
```
1
```
spec:
  ports:
  - name: db
    port: 3306 
```
2
```
  loadBalancerIP:
  loadBalancerSourceRanges: 
```
3
```
  - 10.0.0.0/8
  - 192.168.0.0/16
  type: LoadBalancer 
```
4
```
  selector:
    name: mysql 
```
5
Copy to Clipboard Toggle word wrap
1
로드 밸런서 서비스를 설명하는 이름을 입력합니다.
2
노출하려는 서비스가 수신 대기 중인 포트와 동일한 포트를 입력합니다.
3
로드 밸런서를 통한 트래픽을 제한하려면 특정 IP 주소 목록을 입력합니다. cloud-provider가 이 기능을 지원하지 않는 경우 이 필드는 무시됩니다.
4
유형으로 Loadbalancer를 입력합니다.
5
서비스 이름을 입력합니다.
참고
로드 밸런서를 통과하는 트래픽을 특정 IP 주소로 제한하려면 Ingress Controller 필드 spec.endpointPublishingStrategy.loadBalancer.allowedSourceRanges 를 사용하는 것이 좋습니다. loadBalancerSourceRanges 필드를 설정하지 마세요.
파일을 저장하고 종료합니다.
다음 명령을 실행하여 서비스를 생성합니다.
```
oc create -f <file-name>
```
```
$ oc create -f <file-name>
```
Copy to Clipboard Toggle word wrap
예를 들면 다음과 같습니다.
```
oc create -f mysql-lb.yaml
```
```
$ oc create -f mysql-lb.yaml
```
Copy to Clipboard Toggle word wrap

새 서비스를 보려면 다음 명령을 실행합니다.

oc get svc

$ oc get svc

Copy to Clipboard

Toggle word wrap

출력 예

NAME       TYPE           CLUSTER-IP      EXTERNAL-IP                             PORT(S)          AGE
egress-2   LoadBalancer   172.30.22.226   ad42f5d8b303045-487804948.example.com   3306:30357/TCP   15m

NAME       TYPE           CLUSTER-IP      EXTERNAL-IP                             PORT(S)          AGE
egress-2   LoadBalancer   172.30.22.226   ad42f5d8b303045-487804948.example.com   3306:30357/TCP   15m

Copy to Clipboard

Toggle word wrap

활성화된 클라우드 공급자가 있는 경우 서비스에 외부 IP 주소가 자동으로 할당됩니다.

마스터에서 cURL과 같은 도구를 사용하여 공개 IP 주소로 서비스에 도달할 수 있는지 확인합니다.
```
curl <public-ip>:<port>
```
```
$ curl <public-ip>:<port>
```
Copy to Clipboard Toggle word wrap
예를 들면 다음과 같습니다.
```
curl 172.29.121.74:3306
```
```
$ curl 172.29.121.74:3306
```
Copy to Clipboard Toggle word wrap
이 섹션의 예제에서는 클라이언트 애플리케이션이 필요한 MySQL 서비스를 사용합니다. 패킷이 잘못됨이라는 메시지가 포함된 문자열이 표시되면 서비스에 연결된 것입니다.
MySQL 클라이언트가 있는 경우 표준 CLI 명령으로 로그인하십시오.
```
mysql -h 172.30.131.89 -u admin -p
```
```
$ mysql -h 172.30.131.89 -u admin -p
```
Copy to Clipboard Toggle word wrap
출력 예
```
Enter password:
Welcome to the MariaDB monitor.  Commands end with ; or \g.

MySQL [(none)]>
```
```
Enter password:
Welcome to the MariaDB monitor.  Commands end with ; or \g.

MySQL [(none)]>
```
Copy to Clipboard Toggle word wrap

2.6. AWS에서 인그레스 클러스터 트래픽 구성
링크 복사

OpenShift Container Platform에서는 클러스터에서 실행되는 서비스와 클러스터 외부에서 통신할 수 있습니다. 이 방법은 AWS의 로드 밸런서, 특히 네트워크 로드 밸런서(NLB) 또는 클래식 로드 밸런서(CLB)를 사용합니다. 두 유형의 로드 밸런서 모두 클라이언트의 IP 주소를 노드로 전달할 수 있지만, CLB에는 프록시 프로토콜 지원이 필요하며, OpenShift Container Platform은 이를 자동으로 활성화합니다.

NLB를 사용하도록 Ingress Controller를 구성하는 방법에는 두 가지가 있습니다.

현재 CLB를 사용 중인 Ingress Controller를 강제로 교체합니다. 이렇게 하면 IngressController 객체가 삭제되고 새로운 DNS 레코드가 전파되고 NLB가 프로비저닝되는 동안 중단이 발생합니다.
CLB를 사용하는 기존 Ingress 컨트롤러를 편집하여 NLB를 사용합니다. 이렇게 하면 IngressController 객체를 삭제하고 다시 만들지 않고도 로드 밸런서를 변경할 수 있습니다.

두 방법 모두 NLB에서 CLB로 전환하는 데 사용할 수 있습니다.

이러한 로드 밸런서는 새 AWS 클러스터나 기존 AWS 클러스터에서 구성할 수 있습니다.

2.6.1. AWS에서 Classic Load Balancer 시간 초과 구성
링크 복사

OpenShift Container Platform은 특정 경로 또는 Ingress Controller에 대한 사용자 정의 시간 초과 기간을 설정하는 방법을 제공합니다. 또한 AWS Classic Load Balancer(CLB)에는 기본적으로 60초의 시간 초과 기간이 있습니다.

CLB의 시간 초과 기간이 경로 시간 초과 또는 Ingress Controller 시간 초과보다 짧으면 로드 밸런서가 연결을 조기에 종료할 수 있습니다. 경로의 시간 초과 기간과 CLB를 모두 늘리면 이 문제를 방지할 수 있습니다.

2.6.1.1. 경로 시간 초과 구성
링크 복사

중요

사전 요구 사항

실행 중인 클러스터에 배포된 Ingress 컨트롤러가 필요합니다.

프로세스

oc annotate 명령을 사용하여 경로에 시간 초과를 추가합니다.
```
oc annotate route <route_name> \
    --overwrite haproxy.router.openshift.io/timeout=<timeout><time_unit>
```
```
$ oc annotate route <route_name> \
    --overwrite haproxy.router.openshift.io/timeout=<timeout><time_unit> 
```
1
Copy to Clipboard Toggle word wrap
1
지원되는 시간 단위는 마이크로초(us), 밀리초(ms), 초(s), 분(m), 시간(h) 또는 일(d)입니다.
다음 예제는 이름이 myroute인 경로에서 2초의 시간 초과를 설정합니다.
```
oc annotate route myroute --overwrite haproxy.router.openshift.io/timeout=2s
```
```
$ oc annotate route myroute --overwrite haproxy.router.openshift.io/timeout=2s
```
Copy to Clipboard Toggle word wrap

2.6.1.2. Classic Load Balancer 시간 초과 구성
링크 복사

클래식 로드 밸런서(CLB)의 기본 시간 초과를 구성하여 유휴 연결을 연장할 수 있습니다.

사전 요구 사항

실행 중인 클러스터에 Ingress Controller가 배포되어 있어야 합니다.

프로세스

다음 명령을 실행하여 기본 ingresscontroller에 대한 AWS 연결 유휴 시간 제한을 5분으로 설정합니다.

oc -n openshift-ingress-operator patch ingresscontroller/default \
    --type=merge --patch='{"spec":{"endpointPublishingStrategy": \
    {"type":"LoadBalancerService", "loadBalancer": \
    {"scope":"External", "providerParameters":{"type":"AWS", "aws": \
    {"type":"Classic", "classicLoadBalancer": \
    {"connectionIdleTimeout":"5m"}}}}}}}'

$ oc -n openshift-ingress-operator patch ingresscontroller/default \
    --type=merge --patch='{"spec":{"endpointPublishingStrategy": \
    {"type":"LoadBalancerService", "loadBalancer": \
    {"scope":"External", "providerParameters":{"type":"AWS", "aws": \
    {"type":"Classic", "classicLoadBalancer": \
    {"connectionIdleTimeout":"5m"}}}}}}}'

Copy to Clipboard

Toggle word wrap

선택 사항: 다음 명령을 실행하여 시간 초과의 기본값을 복원합니다.

oc -n openshift-ingress-operator patch ingresscontroller/default \
    --type=merge --patch='{"spec":{"endpointPublishingStrategy": \
    {"loadBalancer":{"providerParameters":{"aws":{"classicLoadBalancer": \
    {"connectionIdleTimeout":null}}}}}}}'

$ oc -n openshift-ingress-operator patch ingresscontroller/default \
    --type=merge --patch='{"spec":{"endpointPublishingStrategy": \
    {"loadBalancer":{"providerParameters":{"aws":{"classicLoadBalancer": \
    {"connectionIdleTimeout":null}}}}}}}'

Copy to Clipboard

Toggle word wrap

참고

현재 범위가 이미 설정되어 있지 않으면 연결 시간 초과 값을 변경할 때 범위 필드를 지정해야 합니다. 범위 필드를 설정하면 기본 시간 초과 값을 복원하는 경우 다시 설정할 필요가 없습니다.

2.6.2. 네트워크 로드 밸런서를 사용하여 AWS에서 수신 클러스터 트래픽 구성
링크 복사

OpenShift Container Platform은 클러스터 내에서 실행되는 서비스와 클러스터 외부에서 통신하는 방법을 제공합니다. 이러한 방법 중 하나는 네트워크 부하 분산 장치(NLB)를 사용합니다. 신규 또는 기존 AWS 클러스터에서 NLB를 구성할 수 있습니다.

2.6.2.1. 클래식 로드 밸런서를 사용하는 Ingress 컨트롤러를 네트워크 로드 밸런서로 전환
링크 복사

AWS에서 Classic Load Balancer(CLB)를 사용하는 Ingress Controller를 Network Load Balancer(NLB)를 사용하는 Ingress Controller로 전환할 수 있습니다.

이러한 로드 밸런서 간에 전환해도 IngressController 개체는 삭제되지 않습니다.

주의

이 절차로 인해 다음과 같은 문제가 발생할 수 있습니다.

새로운 DNS 레코드 전파, 새로운 로드 밸런서 프로비저닝 및 기타 요소로 인해 몇 분 동안 지속될 수 있는 중단입니다. 이 절차를 적용하면 Ingress Controller 로드 밸런서의 IP 주소와 정식 이름이 변경될 수 있습니다.
서비스 주석 변경으로 인해 로드 밸런서 리소스가 누출되었습니다.

프로세스

NLB를 사용하여 전환하려는 기존 Ingress Controller를 수정합니다. 이 예에서는 기본 Ingress 컨트롤러에 외부 범위가 있고 다른 사용자 정의가 없다고 가정합니다.
ingresscontroller.yaml 파일 예시
```
apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  creationTimestamp: null
  name: default
  namespace: openshift-ingress-operator
spec:
  endpointPublishingStrategy:
    loadBalancer:
      scope: External
      providerParameters:
        type: AWS
        aws:
          type: NLB
    type: LoadBalancerService
```
```
apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  creationTimestamp: null
  name: default
  namespace: openshift-ingress-operator
spec:
  endpointPublishingStrategy:
    loadBalancer:
      scope: External
      providerParameters:
        type: AWS
        aws:
          type: NLB
    type: LoadBalancerService
```
Copy to Clipboard Toggle word wrap
참고
spec.endpointPublishingStrategy.loadBalancer.providerParameters.aws.type 필드에 값을 지정하지 않으면 Ingress Controller는 설치 중에 설정된 클러스터 Ingress 구성의 spec.loadBalancer.platform.aws.type 값을 사용합니다.
작은 정보
Ingress Controller에 도메인 변경 등 업데이트하려는 다른 사용자 정의가 있는 경우 대신 Ingress Controller 정의 파일을 강제로 바꾸는 것을 고려하세요.
다음 명령을 실행하여 Ingress Controller YAML 파일에 변경 사항을 적용합니다.
```
oc apply -f ingresscontroller.yaml
```
```
$ oc apply -f ingresscontroller.yaml
```
Copy to Clipboard Toggle word wrap
Ingress Controller가 업데이트되는 동안 몇 분간 중단이 예상됩니다.

2.6.2.2. 네트워크 로드 밸런서를 사용하는 Ingress 컨트롤러를 클래식 로드 밸런서로 전환
링크 복사

AWS에서 네트워크 로드 밸런서(NLB)를 사용하는 Ingress 컨트롤러를 클래식 로드 밸런서(CLB)를 사용하는 Ingress 컨트롤러로 전환할 수 있습니다.

이러한 로드 밸런서 간에 전환해도 IngressController 개체는 삭제되지 않습니다.

주의

이 절차를 수행하면 새로운 DNS 레코드 전파, 새로운 로드 밸런서 프로비저닝 및 기타 요소로 인해 몇 분 동안 지속되는 중단이 발생할 수 있습니다. 이 절차를 적용하면 Ingress Controller 로드 밸런서의 IP 주소와 정식 이름이 변경될 수 있습니다.

프로세스

CLB를 사용하여 전환하려는 기존 Ingress 컨트롤러를 수정합니다. 이 예에서는 기본 Ingress 컨트롤러에 외부 범위가 있고 다른 사용자 정의가 없다고 가정합니다.

ingresscontroller.yaml 파일 예시

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  creationTimestamp: null
  name: default
  namespace: openshift-ingress-operator
spec:
  endpointPublishingStrategy:
    loadBalancer:
      scope: External
      providerParameters:
        type: AWS
        aws:
          type: Classic
    type: LoadBalancerService

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  creationTimestamp: null
  name: default
  namespace: openshift-ingress-operator
spec:
  endpointPublishingStrategy:
    loadBalancer:
      scope: External
      providerParameters:
        type: AWS
        aws:
          type: Classic
    type: LoadBalancerService

Copy to Clipboard

Toggle word wrap

참고

spec.endpointPublishingStrategy.loadBalancer.providerParameters.aws.type 필드에 값을 지정하지 않으면 Ingress Controller는 설치 중에 설정된 클러스터 Ingress 구성의 spec.loadBalancer.platform.aws.type 값을 사용합니다.

작은 정보

Ingress Controller에 도메인 변경 등 업데이트하려는 다른 사용자 정의가 있는 경우 대신 Ingress Controller 정의 파일을 강제로 바꾸는 것을 고려하세요.

다음 명령을 실행하여 Ingress Controller YAML 파일에 변경 사항을 적용합니다.
```
oc apply -f ingresscontroller.yaml
```
```
$ oc apply -f ingresscontroller.yaml
```
Copy to Clipboard Toggle word wrap
Ingress Controller가 업데이트되는 동안 몇 분간 중단이 예상됩니다.

2.6.2.3. Ingress Controller Classic Load Balancer를 Network Load Balancer로 교체
링크 복사

AWS에서 Classic Load Balancer(CLB)를 사용하는 Ingress Controller를 Network Load Balancer(NLB)를 사용하는 Ingress Controller로 교체할 수 있습니다.

주의

이 절차로 인해 다음과 같은 문제가 발생할 수 있습니다.

새로운 DNS 레코드 전파, 새로운 로드 밸런서 프로비저닝 및 기타 요소로 인해 몇 분 동안 지속될 수 있는 중단입니다. 이 절차를 적용하면 Ingress Controller 로드 밸런서의 IP 주소와 정식 이름이 변경될 수 있습니다.
서비스 주석 변경으로 인해 로드 밸런서 리소스가 누출되었습니다.

프로세스

새로운 기본 Ingress 컨트롤러로 파일을 만듭니다. 다음 예에서는 기본 Ingress 컨트롤러에 외부 범위가 있고 다른 사용자 정의가 없다고 가정합니다.

ingresscontroller.yml 파일 예시

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  creationTimestamp: null
  name: default
  namespace: openshift-ingress-operator
spec:
  endpointPublishingStrategy:
    loadBalancer:
      scope: External
      providerParameters:
        type: AWS
        aws:
          type: NLB
    type: LoadBalancerService

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  creationTimestamp: null
  name: default
  namespace: openshift-ingress-operator
spec:
  endpointPublishingStrategy:
    loadBalancer:
      scope: External
      providerParameters:
        type: AWS
        aws:
          type: NLB
    type: LoadBalancerService

Copy to Clipboard

Toggle word wrap

기본 Ingress 컨트롤러에 다른 사용자 정의가 있는 경우 해당 파일을 적절히 수정해야 합니다.

작은 정보

Ingress 컨트롤러에 다른 사용자 정의가 없고 로드 밸런서 유형만 업데이트하는 경우 "클래식 로드 밸런서를 사용하는 Ingress 컨트롤러에서 네트워크 로드 밸런서로 전환"에 자세히 설명된 절차를 따르는 것이 좋습니다.

Ingress Controller YAML 파일을 강제로 교체합니다.
```
oc replace --force --wait -f ingresscontroller.yml
```
```
$ oc replace --force --wait -f ingresscontroller.yml
```
Copy to Clipboard Toggle word wrap
Ingress Controller가 교체될 때까지 기다리세요. 몇 분 동안의 정전이 예상됩니다.

2.6.2.4. 기존 AWS 클러스터에서 Ingress 컨트롤러 네트워크 로드 밸런서 생성
링크 복사

기존 클러스터에서 AWS NLB(Network Load Balancer)가 지원하는 Ingress 컨트롤러를 생성할 수 있습니다.

사전 요구 사항

AWS 클러스터가 설치되어 있어야 합니다.
인프라 리소스의 PlatformStatus는 AWS여야 합니다.
- PlatformStatus가 AWS인지 확인하려면 다음을 실행하십시오.
  $ oc get infrastructure/cluster -o jsonpath='{.status.platformStatus.type}' AWS
  Copy to Clipboard Toggle word wrap

프로세스

기존 클러스터에서 AWS NLB가 지원하는 Ingress 컨트롤러를 생성합니다.

Ingress 컨트롤러 매니페스트를 생성합니다.

cat ingresscontroller-aws-nlb.yaml

 $ cat ingresscontroller-aws-nlb.yaml

Copy to Clipboard

Toggle word wrap

출력 예

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: $my_ingress_controller
  namespace: openshift-ingress-operator
spec:
  domain: $my_unique_ingress_domain
  endpointPublishingStrategy:
    type: LoadBalancerService
    loadBalancer:
      scope: External
      providerParameters:
        type: AWS
        aws:
          type: NLB

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: $my_ingress_controller


  namespace: openshift-ingress-operator
spec:
  domain: $my_unique_ingress_domain


  endpointPublishingStrategy:
    type: LoadBalancerService
    loadBalancer:
      scope: External


      providerParameters:
        type: AWS
        aws:
          type: NLB

Copy to Clipboard

Toggle word wrap

1: $my_ingress_controller를 Ingress 컨트롤러에 대해 고유한 이름으로 교체합니다.
2: $my_unique_ingress_domain을 클러스터의 모든 Ingress 컨트롤러 간에 고유한 도메인 이름으로 교체합니다. 이 변수는 DNS 이름 <clustername>.<domain> 의 하위 도메인이어야 합니다.
3: 내부 NLB를 사용하려면 External을 Internal로 교체할 수 있습니다.

클러스터에서 리소스를 생성합니다.
```
oc create -f ingresscontroller-aws-nlb.yaml
```
```
$ oc create -f ingresscontroller-aws-nlb.yaml
```
Copy to Clipboard Toggle word wrap

중요

새로운 AWS 클러스터에서 Ingress Controller NLB를 구성하려면 먼저 설치 구성 파일 생성 절차를 완료해야 합니다.

2.6.2.5. 새 AWS 클러스터에서 Ingress 컨트롤러 네트워크 로드 밸런서 생성
링크 복사

새 클러스터에서 AWS NLB(Network Load Balancer)가 지원하는 Ingress 컨트롤러를 생성할 수 있습니다.

사전 요구 사항

install-config.yaml 파일을 생성하고 수정합니다.

프로세스

새 클러스터에서 AWS NLB가 지원하는 Ingress 컨트롤러를 생성합니다.

설치 프로그램이 포함된 디렉터리로 변경하고 매니페스트를 생성합니다.
```
./openshift-install create manifests --dir <installation_directory>
```
```
$ ./openshift-install create manifests --dir <installation_directory> 
```
1
Copy to Clipboard Toggle word wrap
1
<installation_directory>는 클러스터의 install-config.yaml 파일이 포함된 디렉터리의 이름을 지정합니다.
<installation_directory>/manifests/ 디렉터리에 cluster-ingress-default-ingresscontroller.yaml이라는 이름으로 파일을 만듭니다.
```
touch <installation_directory>/manifests/cluster-ingress-default-ingresscontroller.yaml
```
```
$ touch <installation_directory>/manifests/cluster-ingress-default-ingresscontroller.yaml 
```
1
Copy to Clipboard Toggle word wrap
1
<installation_directory>는 클러스터의 manifests / 디렉터리가 포함된 디렉터리 이름을 지정합니다.
파일이 생성되면 다음과 같이 여러 네트워크 구성 파일이 manifests/ 디렉토리에 나타납니다.
```
ls <installation_directory>/manifests/cluster-ingress-default-ingresscontroller.yaml
```
```
$ ls <installation_directory>/manifests/cluster-ingress-default-ingresscontroller.yaml
```
Copy to Clipboard Toggle word wrap
출력 예
```
cluster-ingress-default-ingresscontroller.yaml
```
```
cluster-ingress-default-ingresscontroller.yaml
```
Copy to Clipboard Toggle word wrap

편집기에서 cluster-ingress-default-ingresscontroller.yaml 파일을 열고 원하는 운영자 구성을 설명하는 CR(사용자 정의 리소스)을 입력합니다.

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  creationTimestamp: null
  name: default
  namespace: openshift-ingress-operator
spec:
  endpointPublishingStrategy:
    loadBalancer:
      scope: External
      providerParameters:
        type: AWS
        aws:
          type: NLB
    type: LoadBalancerService

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  creationTimestamp: null
  name: default
  namespace: openshift-ingress-operator
spec:
  endpointPublishingStrategy:
    loadBalancer:
      scope: External
      providerParameters:
        type: AWS
        aws:
          type: NLB
    type: LoadBalancerService

Copy to Clipboard

Toggle word wrap

cluster-ingress-default-ingresscontroller.yaml 파일을 저장하고 텍스트 편집기를 종료합니다.
선택 사항: manifests / cluster-ingress-default-ingresscontroller.yaml 파일을 백업합니다. 설치 프로그램은 클러스터를 생성할 때 manifests/ 디렉터리를 삭제합니다.

2.6.2.6. LoadBalancerService Ingress Controller를 생성하는 동안 서브넷 선택
링크 복사

기존 클러스터의 Ingress Controller에 대한 로드 밸런서 서브넷을 수동으로 지정할 수 있습니다. 기본적으로 로드 밸런서 서브넷은 AWS에서 자동으로 검색되지만 Ingress Controller에서 이를 지정하면 이를 재정의하여 수동 제어가 가능합니다.

사전 요구 사항

AWS 클러스터가 설치되어 있어야 합니다.
IngressController 를 매핑하려는 서브넷의 이름이나 ID를 알아야 합니다.

프로세스

사용자 정의 리소스(CR) 파일을 만듭니다.

다음 내용을 포함하는 YAML 파일(예: sample-ingress.yaml )을 만듭니다.

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  namespace: openshift-ingress-operator
  name: <name>
spec:
  domain: <domain>
  endpointPublishingStrategy:
    type: LoadBalancerService
    loadBalancer:
      scope: External
  dnsManagementPolicy: Managed

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  namespace: openshift-ingress-operator
  name: <name>
spec:
  domain: <domain>
  endpointPublishingStrategy:
    type: LoadBalancerService
    loadBalancer:
      scope: External
  dnsManagementPolicy: Managed

Copy to Clipboard

Toggle word wrap

사용자 정의 리소스(CR) 파일을 만듭니다.

YAML 파일에 서브넷을 추가합니다.

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name:  <name> 
  namespace: openshift-ingress-operator
spec:
  domain: <domain> 
  endpointPublishingStrategy:
    type: LoadBalancerService
    loadBalancer:
      scope: External
      providerParameters:
        type: AWS
        aws:
          type: Classic
          classicLoadBalancer: 
            subnets:
              ids: 
              - <subnet> 
              - <subnet>
              - <subnet>
dnsManagementPolicy: Managed

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name:  <name>


  namespace: openshift-ingress-operator
spec:
  domain: <domain>


  endpointPublishingStrategy:
    type: LoadBalancerService
    loadBalancer:
      scope: External
      providerParameters:
        type: AWS
        aws:
          type: Classic
          classicLoadBalancer:


            subnets:
              ids:


              - <subnet>


              - <subnet>
              - <subnet>
dnsManagementPolicy: Managed

Copy to Clipboard

Toggle word wrap

1: <name>을 IngressController 의 이름으로 바꾸세요.
2: <도메인>을 IngressController 에서 서비스하는 DNS 이름으로 바꾸세요.
3: NLB를 사용하는 경우 networkLoadBalancer 필드를 사용할 수도 있습니다.
4: ID로 서브넷을 지정하는 대신 이름 필드를 사용하여 이름으로 서브넷을 지정할 수도 있습니다.
5: 서브넷 ID(또는 이름을 사용하는 경우 이름 )를 지정합니다.
중요
가용성 영역당 최대 1개의 서브넷을 지정할 수 있습니다. 외부 Ingress 컨트롤러에는 공용 서브넷만 제공하고, 내부 Ingress 컨트롤러에는 개인 서브넷만 제공합니다.

CR 파일을 적용합니다.
1. 파일을 저장하고 OpenShift CLI( oc )를 사용하여 적용합니다.
  $ oc apply -f sample-ingress.yaml
  Copy to Clipboard Toggle word wrap
2. IngressController 조건을 확인하여 로드 밸런서가 성공적으로 프로비저닝되었는지 확인하세요.
  $ oc get ingresscontroller -n openshift-ingress-operator <name> -o jsonpath="{.status.conditions}" | yq -PC
  Copy to Clipboard Toggle word wrap

2.6.2.7. 기존 Ingress 컨트롤러의 서브넷 업데이트
링크 복사

OpenShift Container Platform에서 수동으로 지정한 로드 밸런서 서브넷으로 IngressController를 업데이트하면 중단을 방지하고, 서비스의 안정성을 유지하고, 네트워크 구성이 특정 요구 사항에 맞게 조정되도록 할 수 있습니다. 다음 절차에서는 새로운 서브넷을 선택 및 적용하고, 구성 변경 사항을 확인하고, 로드 밸런서 프로비저닝이 성공적으로 완료되었는지 확인하는 방법을 보여줍니다.

주의

프로세스

수동으로 지정한 로드 밸런서 서브넷으로 IngressController를 업데이트하려면 다음 단계를 따르세요.

기존 IngressController를 수정하여 새로운 서브넷으로 업데이트합니다.

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name:  <name> 
  namespace: openshift-ingress-operator
spec:
  domain: <domain> 
  endpointPublishingStrategy:
    type: LoadBalancerService
    loadBalancer:
      scope: External
      providerParameters:
        type: AWS
        aws:
          type: Classic 
          classicLoadBalancer: 
            subnets:
              ids: 
              - <updated_subnet> 
              - <updated_subnet>
              - <updated_subnet>

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name:  <name>


  namespace: openshift-ingress-operator
spec:
  domain: <domain>


  endpointPublishingStrategy:
    type: LoadBalancerService
    loadBalancer:
      scope: External
      providerParameters:
        type: AWS
        aws:
          type: Classic


          classicLoadBalancer:


            subnets:
              ids:


              - <updated_subnet>


              - <updated_subnet>
              - <updated_subnet>

Copy to Clipboard

Toggle word wrap

1: <name>을 IngressController 의 이름으로 바꾸세요.
2: <도메인>을 IngressController 에서 서비스하는 DNS 이름으로 바꾸세요.
3: 업데이트된 서브넷 ID(또는 이름을 사용하는 경우 이름 )를 지정합니다.
4: NLB를 사용하는 경우 networkLoadBalancer 필드를 사용할 수도 있습니다.
5: ID로 서브넷을 지정하는 대신 이름 필드를 사용하여 이름으로 서브넷을 지정할 수도 있습니다.
6: 서브넷 ID(또는 이름을 사용하는 경우 이름 )를 업데이트합니다.

중요

가용성 영역당 최대 1개의 서브넷을 지정할 수 있습니다. 외부 Ingress 컨트롤러에는 공용 서브넷만 제공하고, 내부 Ingress 컨트롤러에는 개인 서브넷만 제공합니다.

다음 명령을 실행하여 서브넷 업데이트를 적용하는 방법에 대한 지침을 보려면 IngressController 의 진행 조건을 살펴보세요.

oc get ingresscontroller -n openshift-ingress-operator subnets -o jsonpath="{.status.conditions[?(@.type==\"Progressing\")]}" | yq -PC

$ oc get ingresscontroller -n openshift-ingress-operator subnets -o jsonpath="{.status.conditions[?(@.type==\"Progressing\")]}" | yq -PC

Copy to Clipboard

Toggle word wrap

출력 예

lastTransitionTime: "2024-11-25T20:19:31Z"
message: 'One or more status conditions indicate progressing: LoadBalancerProgressing=True (OperandsProgressing: One or more managed resources are progressing: The IngressController subnets were changed from [...] to [...].  To effectuate this change, you must delete the service: `oc -n openshift-ingress delete svc/router-<name>`; the service load-balancer will then be deprovisioned and a new one created. This will most likely cause the new load-balancer to have a different host name and IP address and cause disruption. To return to the previous state, you can revert the change to the IngressController: [...]'
reason: IngressControllerProgressing
status: "True"
type: Progressing

lastTransitionTime: "2024-11-25T20:19:31Z"
message: 'One or more status conditions indicate progressing: LoadBalancerProgressing=True (OperandsProgressing: One or more managed resources are progressing: The IngressController subnets were changed from [...] to [...].  To effectuate this change, you must delete the service: `oc -n openshift-ingress delete svc/router-<name>`; the service load-balancer will then be deprovisioned and a new one created. This will most likely cause the new load-balancer to have a different host name and IP address and cause disruption. To return to the previous state, you can revert the change to the IngressController: [...]'
reason: IngressControllerProgressing
status: "True"
type: Progressing

Copy to Clipboard

Toggle word wrap

업데이트를 적용하려면 다음 명령을 실행하여 Ingress 컨트롤러와 연결된 서비스를 삭제하세요.

oc -n openshift-ingress delete svc/router-<name>

$ oc -n openshift-ingress delete svc/router-<name>

Copy to Clipboard

Toggle word wrap

검증

로드 밸런서가 성공적으로 프로비저닝되었는지 확인하려면 다음 명령을 실행하여 IngressController 조건을 확인하세요.

oc get ingresscontroller -n openshift-ingress-operator <name> -o jsonpath="{.status.conditions}" | yq -PC

$ oc get ingresscontroller -n openshift-ingress-operator <name> -o jsonpath="{.status.conditions}" | yq -PC

Copy to Clipboard

Toggle word wrap

2.6.2.8. 네트워크 로드 밸런서(NLB)에 대한 AWS Elastic IP(EIP) 주소 구성
링크 복사

Ingress Controller에서 네트워크 로드 밸런서(NLB)에 대해 고정 IP(탄력적 IP라고도 함)를 지정할 수 있습니다. 이 기능은 클러스터 네트워크에 적합한 방화벽 규칙을 구성하려는 상황에서 유용합니다.

사전 요구 사항

AWS 클러스터가 설치되어 있어야 합니다.
IngressController 를 매핑하려는 서브넷의 이름이나 ID를 알아야 합니다.

절차

다음 내용을 포함하는 YAML 파일을 만듭니다.

sample-ingress.yaml

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  namespace: openshift-ingress-operator
  name: <name> 
spec:
  domain: <domain> 
  endpointPublishingStrategy:
    loadBalancer:
      scope: External 
      type: LoadBalancerService
      providerParameters:
        type: AWS
        aws:
          type: NLB
          networkLoadBalancer:
            subnets: 
              ids:
              - <subnet_ID>
              names:
              - <subnet_A>
              - <subnet_B>
            eipAllocations: 
            - <eipalloc_A>
            - <eipalloc_B>
            - <eipalloc_C>

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  namespace: openshift-ingress-operator
  name: <name>


spec:
  domain: <domain>


  endpointPublishingStrategy:
    loadBalancer:
      scope: External


      type: LoadBalancerService
      providerParameters:
        type: AWS
        aws:
          type: NLB
          networkLoadBalancer:
            subnets:


              ids:
              - <subnet_ID>
              names:
              - <subnet_A>
              - <subnet_B>
            eipAllocations:


            - <eipalloc_A>
            - <eipalloc_B>
            - <eipalloc_C>

Copy to Clipboard

Toggle word wrap

1: <name> 플레이스홀더를 Ingress Controller의 이름으로 바꾸세요.
2: <도메인> 자리 표시자를 Ingress Controller에서 서비스하는 DNS 이름으로 바꾸세요.
3: EIP를 할당하려면 범위를 값으로 외부로 설정하고 인터넷에 연결해야 합니다.
4: 서브넷의 ID와 이름을 지정합니다. ID와 이름의 총 개수는 할당된 EIP와 같아야 합니다.
5: EIP 주소를 지정합니다.

중요

가용성 영역당 최대 1개의 서브넷을 지정할 수 있습니다. 외부 Ingress 컨트롤러에 대해서만 공개 서브넷을 제공합니다. 서브넷당 하나의 EIP 주소를 연결할 수 있습니다.

다음 명령을 입력하여 CR 파일을 저장하고 적용합니다.
```
 oc apply -f sample-ingress.yaml
```
```
$  oc apply -f sample-ingress.yaml
```
Copy to Clipboard Toggle word wrap

검증

다음 명령을 실행하여 IngressController 조건을 확인하여 로드 밸런서가 성공적으로 프로비저닝되었는지 확인하세요.

oc get ingresscontroller -n openshift-ingress-operator <name> -o jsonpath="{.status.conditions}" | yq -PC

$ oc get ingresscontroller -n openshift-ingress-operator <name> -o jsonpath="{.status.conditions}" | yq -PC

Copy to Clipboard

Toggle word wrap

2.7. 서비스 외부 IP에 대한 수신 클러스터 트래픽 구성
링크 복사

MetalLB 구현이나 IP 장애 조치 배포를 사용하여 ExternalIP 리소스를 서비스에 연결하면 해당 서비스를 OpenShift Container Platform 클러스터 외부의 트래픽에서 사용할 수 있습니다. 이런 방식으로 외부 IP 주소를 호스팅하는 것은 베어 메탈 하드웨어에 설치된 클러스터에만 적용됩니다.

서비스로의 트래픽을 라우팅하기 위해 외부 네트워크 인프라를 올바르게 구성해야 합니다.

2.7.1. 사전 요구 사항
링크 복사

클러스터는 ExternalIP가 활성화된 상태로 구성됩니다. 자세한 내용은 서비스에 대한 ExternalIP 구성을 읽어보세요.
참고
출구 IP에 동일한 ExternalIP를 사용하지 마세요.

2.7.2. 서비스에 ExternalIP 연결
링크 복사

서비스에 ExternalIP 리소스를 연결할 수 있습니다. 클러스터가 리소스를 서비스에 자동으로 연결하도록 구성한 경우 서비스에 외부 IP를 수동으로 연결할 필요가 없을 수 있습니다.

이 절차의 예제에서는 IP 장애 조치 구성을 사용하여 클러스터의 서비스에 ExternalIP 리소스를 수동으로 연결하는 시나리오를 사용합니다.

프로세스

CLI에 다음 명령을 입력하여 ExternalIP 리소스에 대해 호환되는 IP 주소 범위를 확인하세요.
```
oc get networks.config cluster -o jsonpath='{.spec.externalIP}{"\n"}'
```
```
$ oc get networks.config cluster -o jsonpath='{.spec.externalIP}{"\n"}'
```
Copy to Clipboard Toggle word wrap
참고
autoAssignCIDRs가 설정되어 있고 ExternalIP 리소스에서 spec.externalIPs 에 대한 값을 지정하지 않은 경우 OpenShift Container Platform은 자동으로 새 서비스 개체에 ExternalIP를 할당합니다.
다음 옵션 중 하나를 선택하여 서비스에 ExternalIP 리소스를 연결합니다.
1. 새로운 서비스를 생성하는 경우 spec.externalIPs 필드에 값을 지정하고 allowedCIDRs 매개변수에 하나 이상의 유효한 IP 주소 배열을 지정합니다.
  ExternalIP 리소스를 지원하는 서비스 YAML 구성 파일의 예
  apiVersion: v1 kind: Service metadata: name: svc-with-externalip spec: externalIPs: policy: allowedCIDRs: - 192.168.123.0/28
  
  Copy to Clipboard Toggle word wrap
2. ExternalIP를 기존 서비스에 연결하는 경우 다음 명령을 입력합니다. <name>을 서비스 이름으로 교체합니다. <ip_address>를 유효한 ExternalIP 주소로 교체합니다. 쉼표로 구분된 여러 IP 주소를 제공할 수 있습니다.
  $ oc patch svc <name> -p \ '{ "spec": { "externalIPs": [ "<ip_address>" ] } }'
  Copy to Clipboard Toggle word wrap
  예를 들면 다음과 같습니다.
  $ oc patch svc mysql-55-rhel7 -p '{"spec":{"externalIPs":["192.174.120.10"]}}'
  Copy to Clipboard Toggle word wrap
  출력 예
  "mysql-55-rhel7" patched
  
  Copy to Clipboard Toggle word wrap
ExternalIP 주소가 서비스에 연결되었는지 확인하려면 다음 명령을 입력합니다. 새 서비스에 ExternalIP를 지정한 경우 먼저 서비스를 생성해야 합니다.
```
oc get svc
```
```
$ oc get svc
```
Copy to Clipboard Toggle word wrap
출력 예
```
NAME               CLUSTER-IP      EXTERNAL-IP     PORT(S)    AGE
mysql-55-rhel7     172.30.131.89   192.174.120.10  3306/TCP   13m
```
```
NAME               CLUSTER-IP      EXTERNAL-IP     PORT(S)    AGE
mysql-55-rhel7     172.30.131.89   192.174.120.10  3306/TCP   13m
```
Copy to Clipboard Toggle word wrap

2.8. NodePort를 사용하여 수신 클러스터 트래픽 구성
링크 복사

OpenShift Container Platform에서는 클러스터에서 실행되는 서비스와 클러스터 외부에서 통신할 수 있습니다. 이 방법에서는 NodePort를 사용합니다.

2.8.1. NodePort를 사용하여 클러스터로 트래픽 가져오기
링크 복사

클러스터의 모든 노드에서 특정 포트에 서비스를 노출하려면 NodePort 유형의 서비스 리소스를 사용하십시오. 포트는 Service 리소스의 .spec.ports[*].nodePort 필드에 지정됩니다.

중요

노드 포트를 사용하려면 추가 포트 리소스가 필요합니다.

NodePort는 서비스를 노드 IP 주소의 정적 포트에 노출합니다. NodePort는 기본적으로 30000~32767 범위에 있으며, 서비스에서 의도한 포트와 NodePort가 일치하지 않을 수 있습니다. 예를 들어, 포트 8080은 노드에서 포트 31020으로 노출될 수 있습니다.

관리자는 외부 IP 주소가 노드로 라우팅되는지 확인해야 합니다.

NodePort 및 외부 IP는 독립적이며 둘 다 동시에 사용할 수 있습니다.

참고

이 섹션의 절차에는 클러스터 관리자가 수행해야 하는 사전 요구 사항이 필요합니다.

2.8.2. 사전 요구 사항
링크 복사

다음 절차를 시작하기 전에 관리자는 다음을 수행해야 합니다.

요청이 클러스터에 도달할 수 있도록 외부 포트를 클러스터 네트워킹 환경으로 설정합니다.
클러스터 관리자 역할의 사용자가 한 명 이상 있는지 확인합니다. 이 역할을 사용자에게 추가하려면 다음 명령을 실행합니다.
```
oc adm policy add-cluster-role-to-user cluster-admin <user_name>
```
```
$ oc adm policy add-cluster-role-to-user cluster-admin <user_name>
```
Copy to Clipboard Toggle word wrap
클러스터에 대한 네트워크 액세스 권한이 있는 마스터와 노드가 클러스터 외부에 각각 1개 이상씩 있는 OpenShift Container Platform 클러스터가 있어야 합니다. 이 절차에서는 외부 시스템이 클러스터와 동일한 서브넷에 있다고 가정합니다. 다른 서브넷에 있는 외부 시스템에 필요한 추가 네트워킹은 이 주제에서 다루지 않습니다.

2.8.3. 프로젝트 및 서비스 생성
링크 복사

공개하려는 프로젝트와 서비스가 존재하지 않는 경우 프로젝트를 생성한 다음 서비스를 생성하세요.

프로젝트와 서비스가 이미 존재하는 경우 서비스를 노출하여 경로를 생성하는 절차로 건너뜁니다.

사전 요구 사항

OpenShift CLI( oc )를 설치하고 클러스터 관리자로 로그인합니다.

프로세스

oc new-project 명령을 실행하여 서비스에 대한 새 프로젝트를 만듭니다.
```
oc new-project <project_name>
```
```
$ oc new-project <project_name>
```
Copy to Clipboard Toggle word wrap

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

Toggle word wrap

서비스가 생성되었는지 확인하려면 다음 명령을 실행하세요.

oc get svc -n <project_name>

$ oc get svc -n <project_name>

Copy to Clipboard

Toggle word wrap

출력 예

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

Toggle word wrap

참고

기본적으로 새 서비스에는 외부 IP 주소가 없습니다.

2.8.4. 경로를 생성하여 서비스 노출
링크 복사

oc expose 명령을 사용하여 서비스를 경로로 노출할 수 있습니다.

사전 요구 사항

OpenShift Container Platform에 로그인했습니다.

프로세스

노출하려는 서비스가 있는 프로젝트에 로그인합니다.
```
oc project <project_name>
```
```
$ oc project <project_name>
```
Copy to Clipboard Toggle word wrap
애플리케이션에 대한 노드 포트를 노출하려면 다음 명령을 입력하여 서비스의 사용자 정의 리소스 정의(CRD)를 수정합니다.
```
oc edit svc <service_name>
```
```
$ oc edit svc <service_name>
```
Copy to Clipboard Toggle word wrap
출력 예
```
spec:
  ports:
  - name: 8443-tcp
    nodePort: 30327 
    port: 8443
    protocol: TCP
    targetPort: 8443
  sessionAffinity: None
  type: NodePort 
```
```
spec:
  ports:
  - name: 8443-tcp
    nodePort: 30327 
```
1
```
    port: 8443
    protocol: TCP
    targetPort: 8443
  sessionAffinity: None
  type: NodePort 
```
2
Copy to Clipboard Toggle word wrap
1
선택 사항: 애플리케이션의 노드 포트 범위를 지정합니다. 기본적으로 OpenShift Container Platform은 30000-32767 범위에서 사용 가능한 포트를 선택합니다.
2
서비스 유형을 정의합니다.

선택 사항: 노드 포트가 노출된 상태로 서비스를 사용할 수 있는지 확인하려면 다음 명령을 입력합니다.

oc get svc -n myproject

$ oc get svc -n myproject

Copy to Clipboard

Toggle word wrap

출력 예

NAME                TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
nodejs-ex           ClusterIP   172.30.217.127   <none>        3306/TCP         9m44s
nodejs-ex-ingress   NodePort    172.30.107.72    <none>        3306:31345/TCP   39s

NAME                TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
nodejs-ex           ClusterIP   172.30.217.127   <none>        3306/TCP         9m44s
nodejs-ex-ingress   NodePort    172.30.107.72    <none>        3306:31345/TCP   39s

Copy to Clipboard

Toggle word wrap

선택 사항: oc new-app 명령에서 자동 생성한 서비스를 제거하려면 다음 명령을 입력합니다.
```
oc delete svc nodejs-ex
```
```
$ oc delete svc nodejs-ex
```
Copy to Clipboard Toggle word wrap

검증

서비스 노드 포트가 30000-32767 범위의 포트로 업데이트되었는지 확인하려면 다음 명령을 입력하세요.
```
oc get svc
```
```
$ oc get svc
```
Copy to Clipboard Toggle word wrap
다음 예제 출력에서 업데이트된 포트는 30327 입니다.
출력 예
```
NAME    TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
httpd   NodePort   172.xx.xx.xx    <none>        8443:30327/TCP   109s
```
```
NAME    TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
httpd   NodePort   172.xx.xx.xx    <none>        8443:30327/TCP   109s
```
Copy to Clipboard Toggle word wrap

2.9. 로드 밸런서 허용 소스 범위를 사용하여 인그레스 클러스터 트래픽 구성
링크 복사

IngressController 에 대한 IP 주소 범위 목록을 지정할 수 있습니다. 이는 endpointPublishingStrategy가 LoadBalancerService 인 경우 로드 밸런서 서비스에 대한 액세스를 제한합니다.

2.9.1. 로드 밸런서 허용 소스 범위 구성
링크 복사

spec.endpointPublishingStrategy.loadBalancer.allowedSourceRanges 필드를 활성화하고 구성할 수 있습니다. 로드 밸런서 허용 소스 범위를 구성하면 Ingress Controller의 로드 밸런서 액세스를 지정된 IP 주소 범위 목록으로 제한할 수 있습니다. Ingress Operator는 로드 밸런서 서비스를 조정하고 AllowedSourceRanges를 기반으로 spec.loadBalancerSourceRanges 필드를 설정합니다.

참고

이전 버전의 OpenShift Container Platform에서 spec.loadBalancerSourceRanges 필드나 로드 밸런서 서비스 주석 service.beta.kubernetes.io/load-balancer-source-ranges를 이미 설정한 경우, Ingress Controller는 업그레이드 후 Progressing=True를 보고하기 시작합니다. 이 문제를 해결하려면 spec.loadBalancerSourceRanges 필드를 덮어쓰고 service.beta.kubernetes.io/load-balancer-source-ranges 주석을 지우는 AllowedSourceRanges를 설정합니다. Ingress Controller가 다시 Progressing=False를 보고하기 시작했습니다.

사전 요구 사항

실행 중인 클러스터에 배포된 Ingress 컨트롤러가 필요합니다.

프로세스

다음 명령을 실행하여 Ingress Controller에 허용되는 소스 범위 API를 설정합니다.

oc -n openshift-ingress-operator patch ingresscontroller/default \
    --type=merge --patch='{"spec":{"endpointPublishingStrategy": \
    {"type":"LoadBalancerService", "loadbalancer": \
    {"scope":"External", "allowedSourceRanges":["0.0.0.0/0"]}}}}'

$ oc -n openshift-ingress-operator patch ingresscontroller/default \
    --type=merge --patch='{"spec":{"endpointPublishingStrategy": \
    {"type":"LoadBalancerService", "loadbalancer": \
    {"scope":"External", "allowedSourceRanges":["0.0.0.0/0"]}}}}'

Copy to Clipboard

Toggle word wrap

1: 예시 값 0.0.0.0/0은 허용되는 소스 범위를 지정합니다.

2.9.2. 로드 밸런서 허용 소스 범위로 마이그레이션
링크 복사

이미 주석 service.beta.kubernetes.io/load-balancer-source-ranges를 설정한 경우 로드 밸런서에서 허용하는 소스 범위로 마이그레이션할 수 있습니다. AllowedSourceRanges를 설정하면 Ingress Controller는 AllowedSourceRanges 값에 따라 spec.loadBalancerSourceRanges 필드를 설정하고 service.beta.kubernetes.io/load-balancer-source-ranges 주석을 설정 해제합니다.

참고

이전 버전의 OpenShift Container Platform에서 spec.loadBalancerSourceRanges 필드나 로드 밸런서 서비스 주석 service.beta.kubernetes.io/load-balancer-source-ranges를 이미 설정한 경우, 업그레이드 후 Ingress Controller가 Progressing=True를 보고하기 시작합니다. 이 문제를 해결하려면 spec.loadBalancerSourceRanges 필드를 덮어쓰고 service.beta.kubernetes.io/load-balancer-source-ranges 주석을 지우는 AllowedSourceRanges를 설정합니다. Ingress Controller가 다시 Progressing=False를 보고하기 시작했습니다.

사전 요구 사항

service.beta.kubernetes.io/load-balancer-source-ranges 주석을 설정했습니다.

프로세스

service.beta.kubernetes.io/load-balancer-source-ranges 가 설정되었는지 확인하세요.

oc get svc router-default -n openshift-ingress -o yaml

$ oc get svc router-default -n openshift-ingress -o yaml

Copy to Clipboard

Toggle word wrap

출력 예

apiVersion: v1
kind: Service
metadata:
  annotations:
    service.beta.kubernetes.io/load-balancer-source-ranges: 192.168.0.1/32

apiVersion: v1
kind: Service
metadata:
  annotations:
    service.beta.kubernetes.io/load-balancer-source-ranges: 192.168.0.1/32

Copy to Clipboard

Toggle word wrap

spec.loadBalancerSourceRanges 필드가 설정되지 않았는지 확인하세요.

oc get svc router-default -n openshift-ingress -o yaml

$ oc get svc router-default -n openshift-ingress -o yaml

Copy to Clipboard

Toggle word wrap

출력 예

...
spec:
  loadBalancerSourceRanges:
  - 0.0.0.0/0
...

...
spec:
  loadBalancerSourceRanges:
  - 0.0.0.0/0
...

Copy to Clipboard

Toggle word wrap

클러스터를 OpenShift Container Platform 4.19로 업데이트하세요.

다음 명령을 실행하여 ingresscontroller 에 허용되는 소스 범위 API를 설정합니다.

oc -n openshift-ingress-operator patch ingresscontroller/default \
    --type=merge --patch='{"spec":{"endpointPublishingStrategy": \
    {"loadBalancer":{"allowedSourceRanges":["0.0.0.0/0"]}}}}'

$ oc -n openshift-ingress-operator patch ingresscontroller/default \
    --type=merge --patch='{"spec":{"endpointPublishingStrategy": \
    {"loadBalancer":{"allowedSourceRanges":["0.0.0.0/0"]}}}}'

Copy to Clipboard

Toggle word wrap

1: 예시 값 0.0.0.0/0은 허용되는 소스 범위를 지정합니다.

2.10. 기존 인그레스 객체 패치
링크 복사

다음 기존 Ingress 객체의 필드는 객체를 다시 만들거나 해당 객체에 대한 서비스를 중단하지 않고도 업데이트하거나 수정할 수 있습니다.

명세서
호스트
경로
백엔드 서비스
SSL/TLS 설정
주석

2.10.1. IngressWithoutClassName 경고를 해결하기 위해 Ingress 객체 패치
링크 복사

ingressClassName 필드는 IngressClass 객체의 이름을 지정합니다. 각 Ingress 객체에 대해 ingressClassName 필드를 정의해야 합니다.

Ingress 객체에 대해 ingressClassName 필드를 정의하지 않은 경우 라우팅 문제가 발생할 수 있습니다. 24시간 후에는 ingressWithoutClassName 알림을 받게 되며, 이 알림을 통해 ingressClassName 필드를 설정하라는 알림을 받게 됩니다.

절차

적절한 라우팅과 기능을 보장하기 위해 완성된 ingressClassName 필드로 Ingress 객체에 패치를 적용합니다.

모든 IngressClass 객체를 나열하세요:
```
oc get ingressclass
```
```
$ oc get ingressclass
```
Copy to Clipboard Toggle word wrap
모든 네임스페이스의 모든 Ingress 객체를 나열합니다.
```
oc get ingress -A
```
```
$ oc get ingress -A
```
Copy to Clipboard Toggle word wrap
Ingress 객체에 패치를 적용합니다.
```
oc patch ingress/<ingress_name> --type=merge --patch '{"spec":{"ingressClassName":"openshift-default"}}'
```
```
$ oc patch ingress/<ingress_name> --type=merge --patch '{"spec":{"ingressClassName":"openshift-default"}}'
```
Copy to Clipboard Toggle word wrap
<ingress_name>을 Ingress 객체의 이름으로 바꾸세요. 이 명령은 원하는 Ingress 클래스 이름을 포함하도록 Ingress 객체에 패치를 적용합니다.

2.11. 특정 서브넷에 로드 밸런서 할당
링크 복사

로드 밸런서를 할당하면 애플리케이션 트래픽을 효율적으로 관리할 수 있습니다. 네트워크 관리자는 로드 밸런서를 할당하여 배포를 사용자 정의할 수 있으며, 이를 통해 최적의 트래픽 분산, 애플리케이션의 고가용성, 중단 없는 서비스 및 네트워크 분할을 보장할 수 있습니다.

2.11.1. AWS의 특정 서브넷에 API 및 Ingress 로드 밸런서 할당
링크 복사

install-config.yaml 파일의 platform.aws.vpc.subnets 섹션에서 가상 사설 클라우드(VPC)의 서브넷을 명시적으로 정의하고 특정 역할을 직접 할당하여 Ingress Controller를 포함한 AWS의 OpenShift 로드 밸런서의 네트워크 배치를 제어할 수 있습니다. 이 방법은 Ingress Controller 및 기타 클러스터 구성 요소와 같은 리소스에 사용되는 서브넷을 세부적으로 제어할 수 있도록 해줍니다.

2.11.1.1. 설치 시 OpenShift API 및 Ingress 로드 밸런서에 대한 AWS 서브넷 지정
링크 복사

특정 서브넷에 API 및 수신 로드 밸런서를 할당하려면 다음 단계를 수행합니다.

사전 요구 사항

시작하기 전에 다음 사항을 확인하세요.

기존 AWS 가상 사설 클라우드(VPC).
다음 고려 사항을 고려하여 OpenShift 클러스터에서 사용하도록 미리 구성된 AWS 서브넷:
- 서브넷 ID 목록이 있습니다(예: subnet-0123456789abcdef0 ). 이러한 ID는 install-config.yaml 파일에서 사용됩니다.
- 부하 분산 장치 및 제어 평면과 같은 기타 중요 구성 요소의 고가용성을 위해 최소 두 개의 가용성 영역(AZ)에 걸쳐 있는 서브넷을 사용합니다.
- 이러한 서브넷 내에는 할당된 모든 역할에 사용할 수 있는 충분한 IP 주소가 있습니다.
- 네트워크 ACL 및 보안 그룹을 포함한 이러한 서브넷에 대한 AWS 구성은 해당 서브넷에 할당된 모든 역할에 필요한 트래픽을 허용해야 합니다. 인그레스 컨트롤러를 호스팅하는 서브넷의 경우 일반적으로 필요한 소스의 TCP 포트 80과 443이 포함됩니다.
대상 OpenShift 버전에 대한 OpenShift 설치 프로그램 바이너리가 있습니다.
install-config.yaml 파일이 있습니다.

프로세스

install-config.yaml 파일을 준비합니다.
아직 생성하지 않았다면 OpenShift 설치 프로그램을 사용하여 설치 구성 파일을 생성하세요.
```
openshift-install create install-config --dir=<your_installation_directory>
```
```
$ openshift-install create install-config --dir=<your_installation_directory>
```
Copy to Clipboard Toggle word wrap
이 명령은 지정된 디렉토리에 install-config.yaml 파일을 생성합니다.
서브넷을 정의하고 역할을 할당합니다.
텍스트 편집기를 사용하여 <설치 디렉토리> 에 있는 install-config.yaml 파일을 엽니다. platform.aws.vpc.subnets 필드에서 VPC 서브넷과 지정된 역할을 정의합니다.
클러스터에서 사용할 각 AWS 서브넷에 대해 ID 와 역할 목록을 지정하는 항목을 만듭니다. 각 역할은 유형 키가 있는 객체입니다. 기본 Ingress Controller에 대한 서브넷을 지정하려면 IngressControllerLB 유형 의 역할을 할당합니다.
```
apiVersion: v1
baseDomain: example.com 
metadata:
  name: my-cluster # Example cluster name
platform:
  aws:
    region: us-east-1 
    vpc: 
      subnets: 
      - id: subnet-0fcf8e0392f0910d5 # Public Subnet in AZ us-east-1a 
        roles:
        - type: IngressControllerLB 
        - type: BootstrapNode
      - id: subnet-0xxxxxxxxxxxxxxza # Public Subnet in another AZ for HA
        roles:
        - type: IngressControllerLB
      - id: subnet-0fcf8e0392f0910d4 # Private Subnet in AZ us-east-1a
        roles:
        - type: ClusterNode 
      - id: subnet-0yyyyyyyyyyyyyyzb # Private Subnet in another AZ for HA
        roles:
        - type: ClusterNode
      # Add other subnet IDs and their roles as needed for your cluster architecture
pullSecret: '...' 
sshKey: '...' 
```
```
apiVersion: v1
baseDomain: example.com 
```
1
```
metadata:
  name: my-cluster # Example cluster name
platform:
  aws:
    region: us-east-1 
```
2
```
    vpc: 
```
3
```
      subnets: 
```
4
```
      - id: subnet-0fcf8e0392f0910d5 # Public Subnet in AZ us-east-1a 
```
5
```
        roles:
        - type: IngressControllerLB 
```
6
```
        - type: BootstrapNode
      - id: subnet-0xxxxxxxxxxxxxxza # Public Subnet in another AZ for HA
        roles:
        - type: IngressControllerLB
      - id: subnet-0fcf8e0392f0910d4 # Private Subnet in AZ us-east-1a
        roles:
        - type: ClusterNode 
```
7
```
      - id: subnet-0yyyyyyyyyyyyyyzb # Private Subnet in another AZ for HA
        roles:
        - type: ClusterNode
      # Add other subnet IDs and their roles as needed for your cluster architecture
pullSecret: '...' 
```
8
```
sshKey: '...' 
```
9
Copy to Clipboard Toggle word wrap
1
기본 도메인.
2
귀하의 AWS 지역.
3
platform.aws 아래의 vpc 객체에는 서브넷 목록이 포함되어 있습니다.
4
OpenShift가 사용할 모든 서브넷 개체 목록입니다. 각 객체는 서브넷 ID와 역할을 정의합니다.
5
AWS 서브넷 ID로 바꾸세요.
6
유형: IngressControllerLB 역할은 이 서브넷을 기본 Ingress Controller의 LoadBalancer에 대해 특별히 지정합니다. 개인/내부 클러스터에서 IngressControllerLB 역할이 있는 서브넷은 개인이어야 합니다.
7
유형: ClusterNode 역할은 이 서브넷을 제어 평면 및 컴퓨팅 노드에 지정합니다. 일반적으로 이는 개인 서브넷입니다.
8
풀 시크릿.
9
SSH 키.
서브넷 목록의 제어 평면 부하 분산 장치 항목은 다음과 같은 패턴을 따릅니다.
```
# ... (within platform.aws.vpc.subnets list)
      - id: subnet-0fcf8e0392f0910d6 # Public Subnet for External API LB
        roles:
        - type: ControlPlaneExternalLB
      - id: subnet-0fcf8e0392f0910d7 # Private Subnet for Internal API LB
        roles:
        - type: ControlPlaneInternalLB
# ...
```
```
# ... (within platform.aws.vpc.subnets list)
      - id: subnet-0fcf8e0392f0910d6 # Public Subnet for External API LB
        roles:
        - type: ControlPlaneExternalLB
      - id: subnet-0fcf8e0392f0910d7 # Private Subnet for Internal API LB
        roles:
        - type: ControlPlaneInternalLB
# ...
```
Copy to Clipboard Toggle word wrap
기본 공개 Ingress Controller의 경우 install-config.yaml 파일에서 IngressControllerLB 역할이 할당된 모든 서브넷은 공개 서브넷이어야 합니다. 예를 들어, AWS에는 아웃바운드 트래픽을 인터넷 게이트웨이(IGW)로 전달하는 경로 테이블 항목이 있어야 합니다.
AZ 전체에서 필요한 모든 서브넷(공개 및 비공개)을 나열하고 클러스터 아키텍처에 따라 적절한 역할을 할당하세요.
서브넷 ID는 기존 VPC의 서브넷을 정의하며, 선택적으로 해당 서브넷의 역할을 지정할 수 있습니다. 어떤 서브넷에도 역할이 지정되지 않으면 서브넷 역할이 자동으로 결정됩니다. 이 경우 VPC에는 kubernetes.io/cluster/<cluster-id> 태그가 없는 다른 비클러스터 서브넷이 포함되어서는 안 됩니다.
서브넷에 역할이 지정된 경우 각 서브넷에는 최소한 하나의 역할이 할당되어야 하며 ClusterNode , BootstrapNode , IngressControllerLB , ControlPlaneExternalLB 및 ControlPlaneInternalLB 역할은 최소한 하나의 서브넷에 할당되어야 합니다. 하지만 클러스터 범위가 내부인 경우 ControlPlaneExternalLB는 필요하지 않습니다.
클러스터 설치를 진행하세요:
install-config.yaml 파일에 변경 사항을 저장한 후 클러스터를 만듭니다.
```
openshift-install create cluster --dir=<your_installation_directory>
```
```
$ openshift-install create cluster --dir=<your_installation_directory>
```
Copy to Clipboard Toggle word wrap
설치 프로그램은 이제 install-config.yaml 파일의 platform.aws.vpc.subnets 섹션에서 서브넷 정의와 명시적 역할 할당을 사용하여 클러스터 리소스를 프로비저닝합니다. 여기에는 IngressControllerLB 역할로 지정한 서브넷에 Ingress Controller의 LoadBalancer를 배치하는 것도 포함됩니다.

참고

IngressControllerLB , ClusterNode , ControlPlaneExternalLB , ControlPlaneInternalLB , BootstrapNode 와 같은 유형을 지정하는 platform.aws.vpc.subnets 내의 역할 할당 메커니즘은 OpenShift 설치 프로그램이 다양한 클러스터 서비스와 구성 요소에 적합한 서브넷을 식별하는 포괄적인 방법입니다.

2.12. 수동 DNS 관리를 위한 Ingress 컨트롤러 구성
링크 복사

클러스터 관리자가 Ingress Controller를 생성하면 운영자가 DNS 레코드를 자동으로 관리합니다. 필요한 DNS 영역이 클러스터 DNS 영역과 다르거나 DNS 영역이 클라우드 공급자 외부에서 호스팅되는 경우 몇 가지 제한이 있습니다.

클러스터 관리자는 Ingress Controller를 구성하여 자동 DNS 관리를 중지하고 수동 DNS 관리를 시작할 수 있습니다. dnsManagementPolicy를 설정하여 자동 또는 수동으로 관리할지 여부를 지정합니다.

Ingress Controller를 관리형 DNS 관리 정책에서 비관리형 DNS 관리 정책으로 변경하는 경우, 운영자는 클라우드에 프로비저닝된 이전 와일드카드 DNS 레코드를 정리하지 않습니다. Ingress Controller를 비관리형 에서 관리형 DNS 관리 정책으로 변경하면 운영자는 클라우드 공급자에 DNS 레코드가 없으면 생성을 시도하고, 이미 있으면 DNS 레코드를 업데이트합니다.

중요

dnsManagementPolicy를 unmanaged 로 설정하면 클라우드 공급자에서 와일드카드 DNS 레코드의 수명 주기를 수동으로 관리해야 합니다.

2.12.1. 관리되는 DNS 관리 정책
링크 복사

Ingress Controllers의 관리형 DNS 관리 정책은 클라우드 공급자의 와일드카드 DNS 레코드 수명 주기가 운영자에 의해 자동으로 관리되도록 보장합니다.

2.12.2. 관리되지 않는 DNS 관리 정책
링크 복사

Ingress Controllers의 관리되지 않는 DNS 관리 정책은 클라우드 공급자의 와일드카드 DNS 레코드 수명 주기가 자동으로 관리되지 않고 대신 클러스터 관리자의 책임이 되도록 보장합니다.

참고

AWS 클라우드 플랫폼에서 Ingress Controller의 도메인이 dnsConfig.Spec.BaseDomain 과 일치하지 않으면 DNS 관리 정책이 자동으로 Unmanaged 로 설정됩니다.

2.12.3. 관리되지 않는 DNS 관리 정책을 사용하여 사용자 지정 Ingress 컨트롤러 만들기
링크 복사

클러스터 관리자는 관리되지 않는 DNS 관리 정책을 사용하여 새로운 사용자 지정 Ingress 컨트롤러를 만들 수 있습니다.

사전 요구 사항

OpenShift CLI(oc)를 설치합니다.
cluster-admin 권한이 있는 사용자로 로그인합니다.

프로세스

다음 내용을 포함하는 sample-ingress.yaml 이라는 사용자 정의 리소스(CR) 파일을 만듭니다.
```
apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  namespace: openshift-ingress-operator
  name: <name> 
spec:
  domain: <domain> 
  endpointPublishingStrategy:
    type: LoadBalancerService
    loadBalancer:
      scope: External 
      dnsManagementPolicy: Unmanaged 
```
```
apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  namespace: openshift-ingress-operator
  name: <name> 
```
1
```
spec:
  domain: <domain> 
```
2
```
  endpointPublishingStrategy:
    type: LoadBalancerService
    loadBalancer:
      scope: External 
```
3
```
      dnsManagementPolicy: Unmanaged 
```
4
Copy to Clipboard Toggle word wrap
1
<name> 에 IngressController 객체의 이름을 지정합니다.
2
필수 조건으로 생성된 DNS 레코드를 기반으로 도메인을 지정합니다.
3
로드 밸런서를 외부에 노출하려면 범위를 외부 로 지정합니다.
4
dnsManagementPolicy는 Ingress Controller가 로드 밸런서와 연결된 와일드카드 DNS 레코드의 수명 주기를 관리하는지 여부를 나타냅니다. 유효한 값은 관리됨 및 관리되지 않음 입니다. 기본값은 관리됨 입니다.
파일을 저장하여 변경 사항을 적용합니다.
```
oc apply -f <name>.yaml 
```
```
oc apply -f <name>.yaml 
```
1
Copy to Clipboard Toggle word wrap

2.12.4. 기존 Ingress 컨트롤러 수정
링크 복사

클러스터 관리자는 기존 Ingress 컨트롤러를 수정하여 DNS 레코드 수명 주기를 수동으로 관리할 수 있습니다.

사전 요구 사항

OpenShift CLI(oc)를 설치합니다.
cluster-admin 권한이 있는 사용자로 로그인합니다.

프로세스

선택한 IngressController를 수정하여 dnsManagementPolicy를 설정합니다.

SCOPE=$(oc -n openshift-ingress-operator get ingresscontroller <name> -o=jsonpath="{.status.endpointPublishingStrategy.loadBalancer.scope}")

oc -n openshift-ingress-operator patch ingresscontrollers/<name> --type=merge --patch='{"spec":{"endpointPublishingStrategy":{"type":"LoadBalancerService","loadBalancer":{"dnsManagementPolicy":"Unmanaged", "scope":"${SCOPE}"}}}}'

SCOPE=$(oc -n openshift-ingress-operator get ingresscontroller <name> -o=jsonpath="{.status.endpointPublishingStrategy.loadBalancer.scope}")

oc -n openshift-ingress-operator patch ingresscontrollers/<name> --type=merge --patch='{"spec":{"endpointPublishingStrategy":{"type":"LoadBalancerService","loadBalancer":{"dnsManagementPolicy":"Unmanaged", "scope":"${SCOPE}"}}}}'

Copy to Clipboard

Toggle word wrap

선택 사항: 클라우드 공급자에서 연관된 DNS 레코드를 삭제할 수 있습니다.

2.13. OpenShift 컨테이너 플랫폼 네트워킹을 통한 게이트웨이 API
링크 복사

OpenShift Container Platform은 Ingress Operator와 함께 Gateway API를 사용하여 네트워크 트래픽을 구성하는 추가적인 방법을 제공합니다.

중요

Gateway API는 사용자 정의 네트워크(UDN)를 지원하지 않습니다.

2.13.1. Gateway API 개요
링크 복사

Gateway API는 오픈 소스이고 커뮤니티에서 관리하는 Kubernetes 네트워킹 메커니즘입니다. 이는 클러스터의 전송 계층 L4와 애플리케이션 계층 L7 내에서의 라우팅에 초점을 맞춥니다. 다양한 공급업체가 Gateway API의 다양한 구현을 제공합니다.

이 프로젝트는 폭넓은 커뮤니티 지원을 바탕으로 이식 가능한 API를 사용하여 표준화된 생태계를 제공하기 위한 노력입니다. Gateway API 기능을 Ingress Operator에 통합함으로써 기존 커뮤니티와 업스트림 개발 노력에 부합하는 네트워킹 솔루션을 구축할 수 있습니다.

Gateway API는 Ingress Operator의 기능을 확장하여 더욱 세부적인 클러스터 트래픽과 라우팅 구성을 처리합니다. 이러한 기능을 사용하면 Gateway API 사용자 정의 리소스 정의(CRD) 인스턴스를 만들 수 있습니다. OpenShift Container Platform 클러스터의 경우 Ingress Operator는 다음 리소스를 생성합니다.

게이트웨이: 이 리소스는 트래픽이 클러스터 내의 서비스로 어떻게 변환될 수 있는지 설명합니다. 예를 들어, 특정 로드 밸런서 구성.
GatewayClass: 이 리소스는 공통 구성과 동작을 공유하는 Gateway 객체 세트를 정의합니다. 예를 들어, 공개 또는 비공개 애플리케이션에 사용되는 Gateway 리소스 세트를 구별하기 위해 두 개의 별도 GatewayClass 객체를 생성할 수 있습니다.
HTTP 경로: 이 리소스는 게이트웨이에서 서비스로 가는 HTTP 요청의 라우팅 동작을 지정하며, 특히 HTTP 또는 종료된 HTTPS 연결을 다중화하는 데 유용합니다.
GRPCRoute: 이 리소스는 gRPC 요청의 라우팅 동작을 지정합니다.
ReferenceGrant: 이 리소스는 네임스페이스 간 참조를 활성화합니다. 예를 들어, 다른 네임스페이스에 있는 백엔드로 트래픽을 전달하는 경로를 활성화합니다.

OpenShift Container Platform에서 Gateway API 구현은 gateway.networking.k8s.io/v1을 기반으로 하며, 이 버전의 모든 필드가 지원됩니다.

2.13.1.1. Gateway API의 이점
링크 복사

Gateway API는 다음과 같은 이점을 제공합니다.

이식성: OpenShift Container Platform은 Ingress 성능을 개선하기 위해 HAProxy를 사용하는 반면, Gateway API는 특정 동작을 제공하기 위해 공급업체별 주석에 의존하지 않습니다. HAProxy와 비슷한 성능을 얻으려면 Gateway 객체를 수평적으로 확장하거나 연관된 노드를 수직적으로 확장해야 합니다.
관심사 분리: Gateway API는 리소스에 대한 역할 기반 접근 방식을 사용하며 대규모 조직이 책임과 팀을 구성하는 방식에 더 잘 맞습니다. 플랫폼 엔지니어는 GatewayClass 리소스에 집중할 수 있고, 클러스터 관리자는 Gateway 리소스 구성에 집중할 수 있으며, 애플리케이션 개발자는 HTTPRoute 리소스를 사용하여 서비스를 라우팅하는 데 집중할 수 있습니다.
확장성: 추가 기능은 표준화된 CRD로 개발됩니다.

2.13.1.2. 게이트웨이 API의 한계
링크 복사

Gateway API에는 다음과 같은 제한 사항이 있습니다.

버전 비호환성: Gateway API 생태계는 빠르게 변화하며, 일부 구현은 다른 구현과 호환되지 않습니다. 이는 해당 기능 세트가 Gateway API의 서로 다른 버전을 기반으로 하기 때문입니다.
리소스 오버헤드: Gateway API는 더 유연하지만 여러 리소스 유형을 사용하여 결과를 얻습니다. 규모가 작은 애플리케이션의 경우 기존 Ingress의 단순성이 더 적합할 수 있습니다.

2.13.2. OpenShift 컨테이너 플랫폼을 위한 게이트웨이 API 구현
링크 복사

Ingress Operator는 다른 공급업체 구현이 OpenShift Container Platform 클러스터에 정의된 CRD를 활용할 수 있도록 Gateway API CRD의 수명 주기를 관리합니다.

어떤 상황에서는 Gateway API가 공급업체 구현에서 지원하지 않는 하나 이상의 필드를 제공하지만, 해당 구현은 스키마상 나머지 필드와 호환됩니다. 이러한 "데드 필드"로 인해 Ingress 워크로드가 중단되고, 애플리케이션과 서비스가 부적절하게 프로비저닝되고, 보안 관련 문제가 발생할 수 있습니다. OpenShift Container Platform은 특정 버전의 Gateway API CRD를 사용하므로 Gateway API의 타사 구현을 사용하려면 모든 필드가 예상대로 작동하도록 OpenShift Container Platform 구현을 준수해야 합니다.

OpenShift Container Platform 4.19 클러스터 내에서 생성된 모든 CRD는 Ingress Operator에 의해 호환 가능한 버전이 지정되고 유지 관리됩니다. CRD가 이미 존재하지만 이전에 Ingress Operator에서 관리하지 않은 경우, Ingress Operator는 이러한 구성이 OpenShift Container Platform에서 지원하는 Gateway API 버전과 호환되는지 확인하고 CRD 계승에 대한 승인을 요구하는 관리 게이트를 만듭니다.

중요

Gateway API CRD가 포함된 이전 OpenShift Container Platform 버전에서 클러스터를 업데이트하는 경우 해당 리소스를 OpenShift Container Platform에서 지원하는 버전과 정확히 일치하도록 변경합니다. 그렇지 않으면 해당 CRD가 OpenShift Container Platform에서 관리되지 않고 Red Hat에서 지원하지 않는 기능을 포함할 수 있으므로 클러스터를 업데이트할 수 없습니다.

2.13.3. Ingress Operator를 위한 Gateway API 시작하기
링크 복사

첫 번째 단계에서 보여준 것처럼 GatewayClass를 생성하면 클러스터에서 사용할 Gateway API가 구성됩니다.

프로세스

GatewayClass 객체를 생성합니다.
1. 다음 정보를 포함하는 YAML 파일 openshift-default.yaml 을 만듭니다.
  예제 GatewayClass CR
  apiVersion: gateway.networking.k8s.io/v1 kind: GatewayClass metadata: name: openshift-default spec: controllerName: openshift.io/gateway-controller/v1
  1
  
  Copy to Clipboard Toggle word wrap
  1 1
  컨트롤러 이름.
  중요
  Ingress Operator가 관리할 수 있도록 컨트롤러 이름은 표시된 대로 정확히 지정되어야 합니다. 이 필드를 다른 값으로 설정하면 Ingress Operator는 GatewayClass 개체와 관련된 모든 Gateway , GRPCRoute , HTTPRoute 개체를 무시합니다. 컨트롤러 이름은 OpenShift Container Platform의 Gateway API 구현과 연결되어 있으며, 허용되는 컨트롤러 이름은 openshift.io/gateway-controller/v1 뿐입니다.
2. 다음 명령을 실행하여 GatewayClass 리소스를 만듭니다.
  $ oc create -f openshift-default.yaml
  Copy to Clipboard Toggle word wrap
  출력 예
  gatewayclass.gateway.networking.k8s.io/openshift-default created
  
  Copy to Clipboard Toggle word wrap
  GatewayClass 리소스를 생성하는 동안 Ingress Operator는 Red Hat OpenShift Service Mesh의 경량 버전, Istio 사용자 정의 리소스 및 openshift-ingress 네임스페이스에 새 배포를 설치합니다.
3. 선택 사항: 새로운 배포인 istiod-openshift-gateway가 준비되고 사용 가능한지 확인하세요.
  $ oc get deployment -n openshift-ingress
  Copy to Clipboard Toggle word wrap
  출력 예
  NAME READY UP-TO-DATE AVAILABLE AGE istiod-openshift-gateway 1/1 1 1 55s router-default 2/2 2 2 6h4m
  
  Copy to Clipboard Toggle word wrap

다음 명령을 실행하여 비밀을 생성합니다.

oc -n openshift-ingress create secret tls gwapi-wildcard --cert=wildcard.crt --key=wildcard.key

$ oc -n openshift-ingress create secret tls gwapi-wildcard --cert=wildcard.crt --key=wildcard.key

Copy to Clipboard

Toggle word wrap

다음 명령을 실행하여 Ingress Operator의 도메인을 가져옵니다.

DOMAIN=$(oc get ingresses.config/cluster -o jsonpath={.spec.domain})

$ DOMAIN=$(oc get ingresses.config/cluster -o jsonpath={.spec.domain})

Copy to Clipboard

Toggle word wrap

Gateway 객체를 생성합니다.

다음 정보를 포함하는 YAML 파일 example-gateway.yaml 을 만듭니다.

게이트웨이 CR 예시

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: example-gateway
  namespace: openshift-ingress 
spec:
  gatewayClassName: openshift-default 
  listeners:
  - name: https 
    hostname: "*.gwapi.${DOMAIN}" 
    port: 443
    protocol: HTTPS
    tls:
      mode: Terminate
      certificateRefs:
      - name: gwapi-wildcard 
    allowedRoutes:
      namespaces:
        from: All

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: example-gateway
  namespace: openshift-ingress


spec:
  gatewayClassName: openshift-default


  listeners:
  - name: https


    hostname: "*.gwapi.${DOMAIN}"


    port: 443
    protocol: HTTPS
    tls:
      mode: Terminate
      certificateRefs:
      - name: gwapi-wildcard


    allowedRoutes:
      namespaces:
        from: All

Copy to Clipboard

Toggle word wrap

1: Gateway 객체는 openshift-ingress 네임스페이스에 생성되어야 합니다.
2: Gateway 객체는 이전에 생성된 GatewayClass 객체의 이름을 참조해야 합니다.
3: HTTPS 리스너는 클러스터 도메인의 하위 도메인과 일치하는 HTTPS 요청을 수신합니다. 이 리스너를 사용하면 Gateway API HTTPRoute 리소스를 사용하여 애플리케이션에 대한 수신을 구성할 수 있습니다.
4: 호스트 이름은 Ingress Operator 도메인의 하위 도메인이어야 합니다. 도메인을 사용하는 경우 리스너는 해당 도메인의 모든 트래픽을 처리하려고 시도합니다.
5: 이전에 생성된 비밀의 이름입니다.

다음 명령을 실행하여 리소스를 적용합니다.
```
oc apply -f example-gateway.yaml
```
```
$ oc apply -f example-gateway.yaml
```
Copy to Clipboard Toggle word wrap

선택 사항: Gateway 객체를 생성하면 Red Hat OpenShift Service Mesh가 동일한 이름으로 배포 및 서비스를 자동으로 프로비저닝합니다. 다음 명령을 실행하여 이를 확인하세요.

배포를 확인하려면 다음 명령을 실행하세요.

oc get deployment -n openshift-ingress example-gateway-openshift-default

$ oc get deployment -n openshift-ingress example-gateway-openshift-default

Copy to Clipboard

Toggle word wrap

출력 예

NAME                                 READY   UP-TO-DATE   AVAILABLE   AGE
example-gateway-openshift-default    1/1     1            1           25s

NAME                                 READY   UP-TO-DATE   AVAILABLE   AGE
example-gateway-openshift-default    1/1     1            1           25s

Copy to Clipboard

Toggle word wrap

서비스를 확인하려면 다음 명령을 실행하세요.

oc get service -n openshift-ingress example-gateway-openshift-default

$ oc get service -n openshift-ingress example-gateway-openshift-default

Copy to Clipboard

Toggle word wrap

출력 예

NAME                                TYPE           CLUSTER-IP   EXTERNAL-IP         PORT(S)      AGE
example-gateway-openshift-default   LoadBalancer   10.1.2.3     <external_ipname>   <port_info>  47s

NAME                                TYPE           CLUSTER-IP   EXTERNAL-IP         PORT(S)      AGE
example-gateway-openshift-default   LoadBalancer   10.1.2.3     <external_ipname>   <port_info>  47s

Copy to Clipboard

Toggle word wrap

선택 사항: Ingress Operator는 리스너의 호스트 이름을 사용하여 DNSRecord CR을 자동으로 생성하고, gateway.networking.k8s.io/gateway-name=example-gateway 레이블을 추가합니다. 다음 명령을 실행하여 DNS 레코드 상태를 확인하세요.

oc -n openshift-ingress get dnsrecord -l gateway.networking.k8s.io/gateway-name=example-gateway -o yaml

$ oc -n openshift-ingress get dnsrecord -l gateway.networking.k8s.io/gateway-name=example-gateway -o yaml

Copy to Clipboard

Toggle word wrap

출력 예

kind: DNSRecord
  ...
status:
  ...
  zones:
  - conditions:
    - message: The DNS provider succeeded in ensuring the record
      reason: ProviderSuccess
      status: "True"
      type: Published
    dnsZone:
      tags:
        ...
  - conditions:
    - message: The DNS provider succeeded in ensuring the record
      reason: ProviderSuccess
      status: "True"
      type: Published
    dnsZone:
      id: ...

kind: DNSRecord
  ...
status:
  ...
  zones:
  - conditions:
    - message: The DNS provider succeeded in ensuring the record
      reason: ProviderSuccess
      status: "True"
      type: Published
    dnsZone:
      tags:
        ...
  - conditions:
    - message: The DNS provider succeeded in ensuring the record
      reason: ProviderSuccess
      status: "True"
      type: Published
    dnsZone:
      id: ...

Copy to Clipboard

Toggle word wrap

이미 생성된 네임스페이스와 example-app/example-app 이라는 애플리케이션으로 요청을 전달하는 HTTPRoute 리소스를 만듭니다.
1. 다음 정보를 포함하는 YAML 파일 example-route.yaml 을 만듭니다.
  예제 HTTPRoute CR
  apiVersion: gateway.networking.k8s.io/v1 kind: HTTPRoute metadata: name: example-route namespace: example-app-ns
  1
  spec: parentRefs:
  2
  - name: example-gateway namespace: openshift-ingress hostnames: ["example.gwapi.${DOMAIN}"]
  3
  rules: - backendRefs:
  4
  - name: example-app
  5
  port: 8443
  
  Copy to Clipboard Toggle word wrap
  1
  애플리케이션을 배포하는 네임스페이스입니다.
  2
  이 필드는 이전에 구성한 Gateway 객체를 가리켜야 합니다.
  3
  호스트 이름은 Gateway 개체에 지정된 호스트 이름과 일치해야 합니다. 이 경우, 리스너는 와일드카드 호스트 이름을 사용합니다.
  4
  이 필드는 서비스를 가리키는 백엔드 참조를 지정합니다.
  5
  애플리케이션에 대한 서비스 의 이름입니다.
2. 다음 명령을 실행하여 리소스를 적용합니다.
  $ oc apply -f example-route.yaml
  Copy to Clipboard Toggle word wrap
  출력 예
  httproute.gateway.networking.k8s.io/example-route created
  
  Copy to Clipboard Toggle word wrap

검증

다음 명령을 실행하여 Gateway 개체가 배포되었고 조건이 Programmed 인지 확인하세요.

oc wait -n openshift-ingress --for=condition=Programmed gateways.gateway.networking.k8s.io example-gateway

$ oc wait -n openshift-ingress --for=condition=Programmed gateways.gateway.networking.k8s.io example-gateway

Copy to Clipboard

Toggle word wrap

출력 예

gateway.gateway.networking.k8s.io/example-gateway condition met

gateway.gateway.networking.k8s.io/example-gateway condition met

Copy to Clipboard

Toggle word wrap

구성된 HTTPRoute 객체 호스트 이름으로 요청을 보냅니다.

curl -I --cacert <local cert file> https://example.gwapi.${DOMAIN}:443

$ curl -I --cacert <local cert file> https://example.gwapi.${DOMAIN}:443

Copy to Clipboard

Toggle word wrap

2.13.4. 게이트웨이 API 배포 토폴로지
링크 복사

게이트웨이 API는 공유 게이트웨이 또는 전용 게이트웨이라는 두 가지 토폴로지를 수용하도록 설계되었습니다. 각 토폴로지마다 장점이 다르고 보안에 미치는 영향도 다릅니다.

전용 게이트웨이: 경로와 모든 로드 밸런서 또는 프록시는 동일한 네임스페이스에서 제공됩니다. Gateway 객체는 특정 애플리케이션 네임스페이스에 대한 경로를 제한합니다. 이는 OpenShift Container Platform에서 Gateway API 리소스를 배포할 때의 기본 토폴로지입니다.
공유 게이트웨이: 경로는 여러 네임스페이스 또는 여러 호스트 이름으로 제공됩니다. Gateway 객체 필터는 spec.listeners.allowedRoutes.namespaces 필드를 사용하여 애플리케이션 네임스페이스의 경로를 허용합니다.

2.13.4.1. 전용 게이트웨이 예
링크 복사

다음 예에서는 전용 Gateway 리소스인 fin-gateway를 보여줍니다.

전용 게이트웨이 리소스 예시

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: fin-gateway
  namespace: openshift-ingress
spec:
  listeners: 
  - name: http
    protocol: HTTP
    port: 8080
    hostname: "example.com"

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: fin-gateway
  namespace: openshift-ingress
spec:
  listeners:


  - name: http
    protocol: HTTP
    port: 8080
    hostname: "example.com"

Copy to Clipboard

Toggle word wrap

1: spec.listeners[].allowedRoutes를 설정하지 않고 Gateway 리소스를 생성하면 namespaces.from 필드의 값이 Same 으로 암묵적으로 설정됩니다.

다음 예제에서는 전용 Gateway 개체에 연결되는 연관된 HTTPRoute 리소스인 sales-db 를 보여줍니다.

HTTPRoute 리소스 예시

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: sales-db
  namespace: openshift-ingress
spec:
  parentRefs:
  - name: fin-gateway
  hostnames:
  - sales-db.example.com
  rules:
    - backendRefs:
        - name: sales-db
        ¦ port: 8080

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: sales-db
  namespace: openshift-ingress
spec:
  parentRefs:
  - name: fin-gateway
  hostnames:
  - sales-db.example.com
  rules:
    - backendRefs:
        - name: sales-db
        ¦ port: 8080

Copy to Clipboard

Toggle word wrap

HTTPRoute 리소스는 게이트웨이에 연결하기 위해 parentRefs 필드의 값으로 Gateway 개체의 이름을 가져야 합니다. 암묵적으로 해당 경로는 Gateway 개체와 같은 네임스페이스에 있다고 가정합니다.

2.13.4.2. 공유 게이트웨이 예
링크 복사

다음 예제에서는 shared-gateway-access: "true"를 포함하는 모든 네임스페이스와 일치하도록 spec.listeners.allowedRoutes.namespaces 레이블 선택기가 설정된 devops-gateway 라는 Gateway 리소스를 보여줍니다.

공유 게이트웨이 리소스 예시

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: devops-gateway
  namespace: openshift-ingress
listeners:
  - name: https
    protocol: HTTPS
    hostname: "example.com"
    allowedRoutes:
      namespaces:
        from: Selector
        selector:
        ¦ matchLabels:
        ¦   shared-gateway-access: "true"

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: devops-gateway
  namespace: openshift-ingress
listeners:
  - name: https
    protocol: HTTPS
    hostname: "example.com"
    allowedRoutes:
      namespaces:
        from: Selector
        selector:
        ¦ matchLabels:
        ¦   shared-gateway-access: "true"

Copy to Clipboard

Toggle word wrap

다음 예에서는 devops-gateway 리소스에 허용되는 네임스페이스를 보여줍니다.

예제 네임스페이스 리소스

apiVersion: v1
kind: Namespace
metadata:
  name: dev
  labels:
    shared-gateway-access: "true"
---
apiVersion: v1
kind: Namespace
metadata:
  name: ops
  labels:
    shared-gateway-access: "true"

apiVersion: v1
kind: Namespace
metadata:
  name: dev
  labels:
    shared-gateway-access: "true"
---
apiVersion: v1
kind: Namespace
metadata:
  name: ops
  labels:
    shared-gateway-access: "true"

Copy to Clipboard

Toggle word wrap

이 예에서 두 개의 HTTPRoute 리소스인 dev-portal 과 ops-home 은 서로 다른 네임스페이스에 있지만 공유 게이트웨이에 연결되어 있습니다.

apiVersion: v1
kind: HTTPRoute
metadata:
  name: dev-portal
  namespace: dev
spec:
  parentRefs:
  - name: devops-gateway
    namespace: openshift-ingress
  rules:
  - backendRefs:
    - name: dev-portal
      port: 8080
---
apiVersion: v1
kind: HTTPRoute
metadata:
  name: ops-home
  namespace: ops
spec:
  parentRefs:
  - name: devops-gateway
    namespace: openshift-ingress
  rules:
  - backendRefs:
    - name: ops-home
      port: 8080

apiVersion: v1
kind: HTTPRoute
metadata:
  name: dev-portal
  namespace: dev
spec:
  parentRefs:
  - name: devops-gateway
    namespace: openshift-ingress
  rules:
  - backendRefs:
    - name: dev-portal
      port: 8080
---
apiVersion: v1
kind: HTTPRoute
metadata:
  name: ops-home
  namespace: ops
spec:
  parentRefs:
  - name: devops-gateway
    namespace: openshift-ingress
  rules:
  - backendRefs:
    - name: ops-home
      port: 8080

Copy to Clipboard

Toggle word wrap

공유 게이트웨이 토폴로지를 사용하는 경우 경로는 연결하려는 게이트웨이 개체의 네임스페이스를 지정해야 합니다. 여러 Gateway 객체를 배포하여 네임스페이스 전체에 공유할 수 있습니다. 공유 게이트웨이가 여러 개 있는 경우 이 토폴로지는 개념적으로 Ingress Controller 샤딩과 유사해집니다.

추가 리소스

Ingress 컨트롤러 분할 .

3장. RHOSP의 로드 밸런싱
링크 복사

3.1. 로드 밸런서 서비스의 한계
링크 복사

Red Hat OpenStack Platform(RHOSP)의 OpenShift Container Platform 클러스터는 Octavia를 사용하여 로드 밸런서 서비스를 처리합니다. 이러한 선택의 결과로 이러한 클러스터에는 여러 가지 기능적 제한이 있습니다.

RHOSP Octavia는 Amphora와 OVN이라는 두 가지 지원 공급자를 보유하고 있습니다. 이러한 공급업체는 사용 가능한 기능과 구현 세부 사항 면에서 서로 다릅니다. 이러한 구분은 클러스터에서 생성되는 로드 밸런서 서비스에 영향을 미칩니다.

3.1.1. 지역 외부 교통 정책
링크 복사

부하 분산 서비스에서 외부 트래픽 정책(ETP) 매개변수인 .spec.externalTrafficPolicy 를 설정하여 서비스 엔드포인트 포드에 도달할 때 들어오는 트래픽의 소스 IP 주소를 보존할 수 있습니다. 하지만 클러스터가 Amphora Octavia 공급자를 사용하는 경우 트래픽의 소스 IP는 Amphora VM의 IP 주소로 대체됩니다. 클러스터가 OVN Octavia 공급자를 사용하는 경우 이 동작은 발생하지 않습니다.

ETP 옵션을 로컬 로 설정하려면 로드 밸런서에 대한 상태 모니터를 생성해야 합니다. 상태 모니터가 없으면 트래픽이 기능적 엔드포인트가 없는 노드로 라우팅될 수 있으며, 이로 인해 연결이 끊어질 수 있습니다. Cloud Provider OpenStack이 상태 모니터를 생성하도록 강제하려면 클라우드 공급자 구성에서 create-monitor 옵션 값을 true 로 설정해야 합니다.

RHOSP 16.2에서는 OVN Octavia 공급자가 상태 모니터를 지원하지 않습니다. 따라서 ETP를 로컬로 설정하는 것은 지원되지 않습니다.

RHOSP 16.2에서 Amphora Octavia 공급자는 UDP 풀에서 HTTP 모니터를 지원하지 않습니다. 결과적으로 UDP 로드 밸런서 서비스에는 대신 UDP-CONNECT 모니터가 생성됩니다. 구현 세부 사항으로 인해 이 구성은 OVN-Kubernetes CNI 플러그인을 사용해서만 제대로 작동합니다.

3.2. Octavia를 사용하여 애플리케이션 트래픽의 클러스터 확장
링크 복사

Red Hat OpenStack Platform(RHOSP)에서 실행되는 OpenShift Container Platform 클러스터는 Octavia 부하 분산 서비스를 사용하여 트래픽을 여러 가상 머신(VM) 또는 유동 IP 주소에 분산할 수 있습니다. 이 기능을 사용하면 단일 머신 또는 주소가 생성하는 병목 현상이 완화됩니다.

애플리케이션 네트워크 확장에 사용하려면 Octavia 로드 밸런서를 직접 만들어야 합니다.

3.2.1. Octavia를 사용하여 클러스터 스케일링
링크 복사

여러 API 로드 밸런서를 사용하려면 Octavia 로드 밸런서를 만든 다음 클러스터를 구성하여 이를 사용합니다.

사전 요구 사항

Octavia는 Red Hat OpenStack Platform(RHOSP) 배포에서 사용할 수 있습니다.

프로세스

명령줄에서 Amphora 드라이버를 사용하는 Octavia 로드 밸런서를 생성합니다.
```
openstack loadbalancer create --name API_OCP_CLUSTER --vip-subnet-id <id_of_worker_vms_subnet>
```
```
$ openstack loadbalancer create --name API_OCP_CLUSTER --vip-subnet-id <id_of_worker_vms_subnet>
```
Copy to Clipboard Toggle word wrap
API_OCP_CLUSTER 대신 선택한 이름을 사용할 수 있습니다.

로드 밸런서가 활성화된 후 리스너를 생성합니다.

openstack loadbalancer listener create --name API_OCP_CLUSTER_6443 --protocol HTTPS--protocol-port 6443 API_OCP_CLUSTER

$ openstack loadbalancer listener create --name API_OCP_CLUSTER_6443 --protocol HTTPS--protocol-port 6443 API_OCP_CLUSTER

Copy to Clipboard

Toggle word wrap

참고

로드 밸런서의 상태를 보려면 openstack loadbalancer list를 입력합니다.

라운드 로빈 알고리즘을 사용하고 세션 지속성이 활성화된 풀을 생성합니다.

openstack loadbalancer pool create --name API_OCP_CLUSTER_pool_6443 --lb-algorithm ROUND_ROBIN --session-persistence type=<source_IP_address> --listener API_OCP_CLUSTER_6443 --protocol HTTPS

$ openstack loadbalancer pool create --name API_OCP_CLUSTER_pool_6443 --lb-algorithm ROUND_ROBIN --session-persistence type=<source_IP_address> --listener API_OCP_CLUSTER_6443 --protocol HTTPS

Copy to Clipboard

Toggle word wrap

컨트롤 플레인 머신을 사용할 수 있도록 하려면 상태 모니터를 생성합니다.

openstack loadbalancer healthmonitor create --delay 5 --max-retries 4 --timeout 10 --type TCP API_OCP_CLUSTER_pool_6443

$ openstack loadbalancer healthmonitor create --delay 5 --max-retries 4 --timeout 10 --type TCP API_OCP_CLUSTER_pool_6443

Copy to Clipboard

Toggle word wrap

컨트롤 플레인 머신을 로드 밸런서 풀의 멤버로 추가합니다.

for SERVER in $(MASTER-0-IP MASTER-1-IP MASTER-2-IP)
do
  openstack loadbalancer member create --address $SERVER  --protocol-port 6443 API_OCP_CLUSTER_pool_6443
done

$ for SERVER in $(MASTER-0-IP MASTER-1-IP MASTER-2-IP)
do
  openstack loadbalancer member create --address $SERVER  --protocol-port 6443 API_OCP_CLUSTER_pool_6443
done

Copy to Clipboard

Toggle word wrap

선택 사항: 클러스터 API 유동 IP 주소를 재사용하려면 설정을 해제합니다.
```
openstack floating ip unset $API_FIP
```
```
$ openstack floating ip unset $API_FIP
```
Copy to Clipboard Toggle word wrap

생성된 로드 밸런서 VIP에 설정되지 않은 API_FIP 또는 새 주소를 추가합니다.

openstack floating ip set  --port $(openstack loadbalancer show -c <vip_port_id> -f value API_OCP_CLUSTER) $API_FIP

$ openstack floating ip set  --port $(openstack loadbalancer show -c <vip_port_id> -f value API_OCP_CLUSTER) $API_FIP

Copy to Clipboard

Toggle word wrap

이제 클러스터에서 로드 밸런싱에 Octavia를 사용합니다.

3.3. 사용자 관리 로드 밸런서를 위한 서비스
링크 복사

Red Hat OpenStack Platform(RHOSP)에서 OpenShift Container Platform 클러스터를 구성하여 기본 로드 밸런서 대신 사용자 관리 로드 밸런서를 사용할 수 있습니다.

중요

사용자 관리 로드 밸런서를 구성하는 방법은 공급업체의 로드 밸런서에 따라 달라집니다.

이 섹션의 정보와 예시는 지침 목적으로만 제공됩니다. 공급업체의 로드 밸런서에 대한 자세한 내용은 공급업체 설명서를 참조하세요.

Red Hat은 사용자 관리형 로드 밸런서에 대해 다음 서비스를 지원합니다.

Ingress 컨트롤러
OpenShift API
OpenShift MachineConfig API

사용자 관리형 부하 분산 장치에 대해 이러한 서비스 중 하나 또는 전부를 구성할지 여부를 선택할 수 있습니다. Ingress Controller 서비스만 구성하는 것은 일반적인 구성 옵션입니다. 각 서비스를 더 잘 이해하려면 다음 다이어그램을 살펴보세요.

그림 3.1. OpenShift Container Platform 환경에서 작동하는 Ingress Controller를 보여주는 네트워크 워크플로 예시

OpenShift Container Platform 환경에서 작동하는 Ingress Controller의 네트워크 워크플로우 예를 보여주는 이미지입니다.

그림 3.2. OpenShift 컨테이너 플랫폼 환경에서 작동하는 OpenShift API를 보여주는 네트워크 워크플로 예시

OpenShift Container Platform 환경에서 작동하는 OpenShift API의 네트워크 워크플로우 예를 보여주는 이미지입니다.

그림 3.3. OpenShift Container Platform 환경에서 작동하는 OpenShift MachineConfig API를 보여주는 네트워크 워크플로 예시

OpenShift Container Platform 환경에서 작동하는 OpenShift MachineConfig API의 네트워크 워크플로우 예를 보여주는 이미지입니다.

사용자 관리 부하 분산 장치에는 다음과 같은 구성 옵션이 지원됩니다.

노드 선택기를 사용하여 Ingress Controller를 특정 노드 세트에 매핑합니다. 이 세트의 각 노드에 고정 IP 주소를 할당하거나 각 노드가 DHCP(동적 호스트 구성 프로토콜)에서 동일한 IP 주소를 받도록 구성해야 합니다. 인프라 노드는 일반적으로 이러한 유형의 구성을 받습니다.
서브넷의 모든 IP 주소를 대상으로 합니다. 이 구성을 사용하면 로드 밸런서 대상을 재구성하지 않고도 해당 네트워크 내에서 노드를 생성하고 삭제할 수 있으므로 유지 관리 오버헤드를 줄일 수 있습니다. /27 또는 /28 과 같은 소규모 네트워크에 있는 머신 세트를 사용하여 인그레스 포드를 배포하면 로드 밸런서 대상을 간소화할 수 있습니다.
작은 정보
머신 구성 풀의 리소스를 확인하면 네트워크에 있는 모든 IP 주소를 나열할 수 있습니다.

OpenShift Container Platform 클러스터에 대한 사용자 관리 로드 밸런서를 구성하기 전에 다음 정보를 고려하세요.

프런트엔드 IP 주소의 경우 프런트엔드 IP 주소, Ingress Controller의 로드 밸런서 및 API 로드 밸런서에 동일한 IP 주소를 사용할 수 있습니다. 이 기능에 대해서는 벤더의 설명서를 확인하십시오.
백엔드 IP 주소의 경우, 사용자 관리 부하 분산 장치의 수명 동안 OpenShift Container Platform 제어 평면 노드의 IP 주소가 변경되지 않도록 해야 합니다. 다음 작업 중 하나를 완료하면 이를 달성할 수 있습니다.
- 각 제어 평면 노드에 고정 IP 주소를 할당합니다.
- 노드가 DHCP 임대를 요청할 때마다 DHCP로부터 동일한 IP 주소를 받도록 각 노드를 구성합니다. 공급업체에 따라 DHCP 임대는 IP 예약이나 정적 DHCP 할당 형태일 수 있습니다.
Ingress Controller 백엔드 서비스에 대한 사용자 관리 로드 밸런서에서 Ingress Controller를 실행하는 각 노드를 수동으로 정의합니다. 예를 들어, Ingress Controller가 정의되지 않은 노드로 이동하면 연결이 중단될 수 있습니다.

3.3.1. 사용자 관리 로드 밸런서 구성
링크 복사

Red Hat OpenStack Platform(RHOSP)에서 OpenShift Container Platform 클러스터를 구성하여 기본 로드 밸런서 대신 사용자 관리 로드 밸런서를 사용할 수 있습니다.

중요

사용자 관리형 로드 밸런서를 구성하기 전에 "사용자 관리형 로드 밸런서 서비스" 섹션을 읽어보세요.

사용자 관리형 로드 밸런서에 대해 구성하려는 서비스에 적용되는 다음 필수 구성 요소를 읽어보세요.

참고

클러스터에서 실행되는 MetalLB는 사용자 관리형 로드 밸런서 역할을 합니다.

OpenShift API 필수 구성 요소

프런트엔드 IP 주소를 정의했습니다.
TCP 포트 6443과 22623은 로드 밸런서의 프런트엔드 IP 주소에 노출됩니다. 다음 항목을 확인합니다.
- 포트 6443은 OpenShift API 서비스에 대한 액세스를 제공합니다.
- 포트 22623은 노드에 점화 시작 구성을 제공할 수 있습니다.
프런트엔드 IP 주소와 포트 6443은 OpenShift Container Platform 클러스터 외부에 위치한 시스템의 모든 사용자가 접근할 수 있습니다.
프런트엔드 IP 주소와 포트 22623은 OpenShift Container Platform 노드에서만 접근 가능합니다.
로드 밸런서 백엔드는 포트 6443 및 22623에서 OpenShift Container Platform 제어 평면 노드와 통신할 수 있습니다.

Ingress 컨트롤러 사전 요구 사항

프런트엔드 IP 주소를 정의했습니다.
TCP 포트 443과 80은 로드 밸런서의 프런트엔드 IP 주소에 노출됩니다.
프런트엔드 IP 주소, 포트 80 및 포트 443은 OpenShift Container Platform 클러스터 외부에 위치한 시스템의 모든 사용자가 접근할 수 있습니다.
프런트엔드 IP 주소, 포트 80 및 포트 443은 OpenShift Container Platform 클러스터에서 작동하는 모든 노드에서 접근 가능합니다.
로드 밸런서 백엔드는 포트 80, 443, 1936에서 Ingress Controller를 실행하는 OpenShift Container Platform 노드와 통신할 수 있습니다.

상태 점검 URL 사양을 위한 전제 조건

대부분의 로드 밸런서는 서비스를 사용할 수 있는지 없는지 확인하는 상태 점검 URL을 설정하여 구성할 수 있습니다. OpenShift Container Platform은 OpenShift API, Machine Configuration API 및 Ingress Controller 백엔드 서비스에 대한 상태 점검을 제공합니다.

다음 예에서는 이전에 나열된 백엔드 서비스에 대한 상태 점검 사양을 보여줍니다.

Kubernetes API 상태 점검 사양의 예

Path: HTTPS:6443/readyz
Healthy threshold: 2
Unhealthy threshold: 2
Timeout: 10
Interval: 10

Path: HTTPS:6443/readyz
Healthy threshold: 2
Unhealthy threshold: 2
Timeout: 10
Interval: 10

Copy to Clipboard

Toggle word wrap

Machine Config API 상태 점검 사양의 예

Path: HTTPS:22623/healthz
Healthy threshold: 2
Unhealthy threshold: 2
Timeout: 10
Interval: 10

Path: HTTPS:22623/healthz
Healthy threshold: 2
Unhealthy threshold: 2
Timeout: 10
Interval: 10

Copy to Clipboard

Toggle word wrap

Ingress Controller 상태 점검 사양의 예

Path: HTTP:1936/healthz/ready
Healthy threshold: 2
Unhealthy threshold: 2
Timeout: 5
Interval: 10

Path: HTTP:1936/healthz/ready
Healthy threshold: 2
Unhealthy threshold: 2
Timeout: 5
Interval: 10

Copy to Clipboard

Toggle word wrap

프로세스

로드 밸런서에서 포트 6443, 22623, 443 및 80에서 클러스터에 액세스할 수 있도록 HAProxy Ingress Controller를 구성합니다. 사용자의 요구 사항에 따라 HAProxy 구성에서 단일 서브넷의 IP 주소나 여러 서브넷의 IP 주소를 지정할 수 있습니다.

하나의 나열된 서브넷이 있는 HAProxy 구성 예

...
...

# ...
listen my-cluster-api-6443
    bind 192.168.1.100:6443
    mode tcp
    balance roundrobin
  option httpchk
  http-check connect
  http-check send meth GET uri /readyz
  http-check expect status 200
    server my-cluster-master-2 192.168.1.101:6443 check inter 10s rise 2 fall 2
    server my-cluster-master-0 192.168.1.102:6443 check inter 10s rise 2 fall 2
    server my-cluster-master-1 192.168.1.103:6443 check inter 10s rise 2 fall 2

listen my-cluster-machine-config-api-22623
    bind 192.168.1.100:22623
    mode tcp
    balance roundrobin
  option httpchk
  http-check connect
  http-check send meth GET uri /healthz
  http-check expect status 200
    server my-cluster-master-2 192.168.1.101:22623 check inter 10s rise 2 fall 2
    server my-cluster-master-0 192.168.1.102:22623 check inter 10s rise 2 fall 2
    server my-cluster-master-1 192.168.1.103:22623 check inter 10s rise 2 fall 2

listen my-cluster-apps-443
    bind 192.168.1.100:443
    mode tcp
    balance roundrobin
  option httpchk
  http-check connect
  http-check send meth GET uri /healthz/ready
  http-check expect status 200
    server my-cluster-worker-0 192.168.1.111:443 check port 1936 inter 10s rise 2 fall 2
    server my-cluster-worker-1 192.168.1.112:443 check port 1936 inter 10s rise 2 fall 2
    server my-cluster-worker-2 192.168.1.113:443 check port 1936 inter 10s rise 2 fall 2

listen my-cluster-apps-80
   bind 192.168.1.100:80
   mode tcp
   balance roundrobin
  option httpchk
  http-check connect
  http-check send meth GET uri /healthz/ready
  http-check expect status 200
    server my-cluster-worker-0 192.168.1.111:80 check port 1936 inter 10s rise 2 fall 2
    server my-cluster-worker-1 192.168.1.112:80 check port 1936 inter 10s rise 2 fall 2
    server my-cluster-worker-2 192.168.1.113:80 check port 1936 inter 10s rise 2 fall 2
# ...

Copy to Clipboard

Toggle word wrap

여러 개의 나열된 서브넷이 있는 HAProxy 구성 예

...
...

# ...
listen api-server-6443
    bind *:6443
    mode tcp
      server master-00 192.168.83.89:6443 check inter 1s
      server master-01 192.168.84.90:6443 check inter 1s
      server master-02 192.168.85.99:6443 check inter 1s
      server bootstrap 192.168.80.89:6443 check inter 1s

listen machine-config-server-22623
    bind *:22623
    mode tcp
      server master-00 192.168.83.89:22623 check inter 1s
      server master-01 192.168.84.90:22623 check inter 1s
      server master-02 192.168.85.99:22623 check inter 1s
      server bootstrap 192.168.80.89:22623 check inter 1s

listen ingress-router-80
    bind *:80
    mode tcp
    balance source
      server worker-00 192.168.83.100:80 check inter 1s
      server worker-01 192.168.83.101:80 check inter 1s

listen ingress-router-443
    bind *:443
    mode tcp
    balance source
      server worker-00 192.168.83.100:443 check inter 1s
      server worker-01 192.168.83.101:443 check inter 1s

listen ironic-api-6385
    bind *:6385
    mode tcp
    balance source
      server master-00 192.168.83.89:6385 check inter 1s
      server master-01 192.168.84.90:6385 check inter 1s
      server master-02 192.168.85.99:6385 check inter 1s
      server bootstrap 192.168.80.89:6385 check inter 1s

listen inspector-api-5050
    bind *:5050
    mode tcp
    balance source
      server master-00 192.168.83.89:5050 check inter 1s
      server master-01 192.168.84.90:5050 check inter 1s
      server master-02 192.168.85.99:5050 check inter 1s
      server bootstrap 192.168.80.89:5050 check inter 1s
# ...

Copy to Clipboard

Toggle word wrap

curl CLI 명령을 사용하여 사용자 관리 로드 밸런서와 해당 리소스가 작동하는지 확인하세요.

다음 명령을 실행하고 응답을 관찰하여 클러스터 머신 구성 API가 Kubernetes API 서버 리소스에 액세스할 수 있는지 확인하세요.

curl https://<loadbalancer_ip_address>:6443/version --insecure

$ curl https://<loadbalancer_ip_address>:6443/version --insecure

Copy to Clipboard

Toggle word wrap

구성이 올바르면 응답으로 JSON 오브젝트가 표시됩니다.

{
  "major": "1",
  "minor": "11+",
  "gitVersion": "v1.11.0+ad103ed",
  "gitCommit": "ad103ed",
  "gitTreeState": "clean",
  "buildDate": "2019-01-09T06:44:10Z",
  "goVersion": "go1.10.3",
  "compiler": "gc",
  "platform": "linux/amd64"
}

{
  "major": "1",
  "minor": "11+",
  "gitVersion": "v1.11.0+ad103ed",
  "gitCommit": "ad103ed",
  "gitTreeState": "clean",
  "buildDate": "2019-01-09T06:44:10Z",
  "goVersion": "go1.10.3",
  "compiler": "gc",
  "platform": "linux/amd64"
}

Copy to Clipboard

Toggle word wrap

다음 명령을 실행하고 출력을 관찰하여 클러스터 머신 구성 API가 머신 구성 서버 리소스에 액세스할 수 있는지 확인하세요.
```
curl -v https://<loadbalancer_ip_address>:22623/healthz --insecure
```
```
$ curl -v https://<loadbalancer_ip_address>:22623/healthz --insecure
```
Copy to Clipboard Toggle word wrap
구성이 올바르면 명령 출력에 다음과 같은 응답이 표시됩니다.
```
HTTP/1.1 200 OK
Content-Length: 0
```
```
HTTP/1.1 200 OK
Content-Length: 0
```
Copy to Clipboard Toggle word wrap

다음 명령을 실행하고 출력을 관찰하여 포트 80에서 Ingress Controller 리소스에 컨트롤러가 액세스할 수 있는지 확인하세요.

curl -I -L -H "Host: console-openshift-console.apps.<cluster_name>.<base_domain>" http://<load_balancer_front_end_IP_address>

$ curl -I -L -H "Host: console-openshift-console.apps.<cluster_name>.<base_domain>" http://<load_balancer_front_end_IP_address>

Copy to Clipboard

Toggle word wrap

구성이 올바르면 명령 출력에 다음과 같은 응답이 표시됩니다.

HTTP/1.1 302 Found
content-length: 0
location: https://console-openshift-console.apps.ocp4.private.opequon.net/
cache-control: no-cache

HTTP/1.1 302 Found
content-length: 0
location: https://console-openshift-console.apps.ocp4.private.opequon.net/
cache-control: no-cache

Copy to Clipboard

Toggle word wrap

다음 명령을 실행하고 출력을 관찰하여 포트 443에서 Ingress Controller 리소스에 컨트롤러가 액세스할 수 있는지 확인하세요.

curl -I -L --insecure --resolve console-openshift-console.apps.<cluster_name>.<base_domain>:443:<Load Balancer Front End IP Address> https://console-openshift-console.apps.<cluster_name>.<base_domain>

$ curl -I -L --insecure --resolve console-openshift-console.apps.<cluster_name>.<base_domain>:443:<Load Balancer Front End IP Address> https://console-openshift-console.apps.<cluster_name>.<base_domain>

Copy to Clipboard

Toggle word wrap

구성이 올바르면 명령 출력에 다음과 같은 응답이 표시됩니다.

HTTP/1.1 200 OK
referrer-policy: strict-origin-when-cross-origin
set-cookie: csrf-token=UlYWOyQ62LWjw2h003xtYSKlh1a0Py2hhctw0WmV2YEdhJjFyQwWcGBsja261dGLgaYO0nxzVErhiXt6QepA7g==; Path=/; Secure; SameSite=Lax
x-content-type-options: nosniff
x-dns-prefetch-control: off
x-frame-options: DENY
x-xss-protection: 1; mode=block
date: Wed, 04 Oct 2023 16:29:38 GMT
content-type: text/html; charset=utf-8
set-cookie: 1e2670d92730b515ce3a1bb65da45062=1bf5e9573c9a2760c964ed1659cc1673; path=/; HttpOnly; Secure; SameSite=None
cache-control: private

HTTP/1.1 200 OK
referrer-policy: strict-origin-when-cross-origin
set-cookie: csrf-token=UlYWOyQ62LWjw2h003xtYSKlh1a0Py2hhctw0WmV2YEdhJjFyQwWcGBsja261dGLgaYO0nxzVErhiXt6QepA7g==; Path=/; Secure; SameSite=Lax
x-content-type-options: nosniff
x-dns-prefetch-control: off
x-frame-options: DENY
x-xss-protection: 1; mode=block
date: Wed, 04 Oct 2023 16:29:38 GMT
content-type: text/html; charset=utf-8
set-cookie: 1e2670d92730b515ce3a1bb65da45062=1bf5e9573c9a2760c964ed1659cc1673; path=/; HttpOnly; Secure; SameSite=None
cache-control: private

Copy to Clipboard

Toggle word wrap

사용자 관리 부하 분산 장치의 프런트엔드 IP 주소를 대상으로 클러스터의 DNS 레코드를 구성합니다. 로드 밸런서를 통해 클러스터 API 및 애플리케이션에 대한 레코드를 DNS 서버로 업데이트해야 합니다.
수정된 DNS 레코드의 예
```
<load_balancer_ip_address>  A  api.<cluster_name>.<base_domain>
A record pointing to Load Balancer Front End
```
```
<load_balancer_ip_address>  A  api.<cluster_name>.<base_domain>
A record pointing to Load Balancer Front End
```
Copy to Clipboard Toggle word wrap
```
<load_balancer_ip_address>   A apps.<cluster_name>.<base_domain>
A record pointing to Load Balancer Front End
```
```
<load_balancer_ip_address>   A apps.<cluster_name>.<base_domain>
A record pointing to Load Balancer Front End
```
Copy to Clipboard Toggle word wrap
중요
DNS 전파가 각 DNS 레코드를 사용할 수 있게 되는 데는 시간이 걸릴 수 있습니다. 각 레코드를 검증하기 전에 각 DNS 레코드가 전파되는지 확인하세요.
OpenShift Container Platform 클러스터에서 사용자 관리형 로드 밸런서를 사용하려면 클러스터의 install-config.yaml 파일에 다음 구성을 지정해야 합니다.
```
# ...
platform:
  openstack:
    loadBalancer:
      type: UserManaged 
    apiVIPs:
    - <api_ip> 
    ingressVIPs:
    - <ingress_ip> 
# ...
```
```
# ...
platform:
  openstack:
    loadBalancer:
      type: UserManaged 
```
1
```
    apiVIPs:
    - <api_ip> 
```
2
```
    ingressVIPs:
    - <ingress_ip> 
```
3
```
# ...
```
Copy to Clipboard Toggle word wrap
1
클러스터에 대한 사용자 관리 부하 분산 장치를 지정하려면 유형 매개변수에 UserManaged를 설정합니다. 매개변수의 기본값은 기본 내부 부하 분산 장치를 나타내는 OpenShiftManagedDefault 입니다. openshift-kni-infra 네임스페이스에 정의된 서비스의 경우, 사용자 관리 로드 밸런서는 클러스터의 포드에 coredns 서비스를 배포할 수 있지만 keepalived 및 haproxy 서비스는 무시합니다.
2
사용자 관리 로드 밸런서를 지정할 때 필수 매개변수입니다. Kubernetes API가 사용자 관리 로드 밸런서와 통신할 수 있도록 사용자 관리 로드 밸런서의 공용 IP 주소를 지정하세요.
3
사용자 관리 로드 밸런서를 지정할 때 필수 매개변수입니다. 사용자 관리 부하 분산 장치의 공용 IP 주소를 지정하면 사용자 관리 부하 분산 장치가 클러스터의 수신 트래픽을 관리할 수 있습니다.

검증

curl CLI 명령을 사용하여 사용자 관리 부하 분산 장치와 DNS 레코드 구성이 작동하는지 확인하세요.

다음 명령을 실행하고 출력을 관찰하여 클러스터 API에 액세스할 수 있는지 확인하세요.

curl https://api.<cluster_name>.<base_domain>:6443/version --insecure

$ curl https://api.<cluster_name>.<base_domain>:6443/version --insecure

Copy to Clipboard

Toggle word wrap

구성이 올바르면 응답으로 JSON 오브젝트가 표시됩니다.

{
  "major": "1",
  "minor": "11+",
  "gitVersion": "v1.11.0+ad103ed",
  "gitCommit": "ad103ed",
  "gitTreeState": "clean",
  "buildDate": "2019-01-09T06:44:10Z",
  "goVersion": "go1.10.3",
  "compiler": "gc",
  "platform": "linux/amd64"
  }

{
  "major": "1",
  "minor": "11+",
  "gitVersion": "v1.11.0+ad103ed",
  "gitCommit": "ad103ed",
  "gitTreeState": "clean",
  "buildDate": "2019-01-09T06:44:10Z",
  "goVersion": "go1.10.3",
  "compiler": "gc",
  "platform": "linux/amd64"
  }

Copy to Clipboard

Toggle word wrap

다음 명령을 실행하고 출력을 관찰하여 클러스터 머신 구성에 액세스할 수 있는지 확인하세요.
```
curl -v https://api.<cluster_name>.<base_domain>:22623/healthz --insecure
```
```
$ curl -v https://api.<cluster_name>.<base_domain>:22623/healthz --insecure
```
Copy to Clipboard Toggle word wrap
구성이 올바르면 명령 출력에 다음과 같은 응답이 표시됩니다.
```
HTTP/1.1 200 OK
Content-Length: 0
```
```
HTTP/1.1 200 OK
Content-Length: 0
```
Copy to Clipboard Toggle word wrap

다음 명령을 실행하고 출력을 관찰하여 포트에서 각 클러스터 애플리케이션에 액세스할 수 있는지 확인하세요.

curl http://console-openshift-console.apps.<cluster_name>.<base_domain> -I -L --insecure

$ curl http://console-openshift-console.apps.<cluster_name>.<base_domain> -I -L --insecure

Copy to Clipboard

Toggle word wrap

구성이 올바르면 명령 출력에 다음과 같은 응답이 표시됩니다.

HTTP/1.1 302 Found
content-length: 0
location: https://console-openshift-console.apps.<cluster-name>.<base domain>/
cache-control: no-cacheHTTP/1.1 200 OK
referrer-policy: strict-origin-when-cross-origin
set-cookie: csrf-token=39HoZgztDnzjJkq/JuLJMeoKNXlfiVv2YgZc09c3TBOBU4NI6kDXaJH1LdicNhN1UsQWzon4Dor9GWGfopaTEQ==; Path=/; Secure
x-content-type-options: nosniff
x-dns-prefetch-control: off
x-frame-options: DENY
x-xss-protection: 1; mode=block
date: Tue, 17 Nov 2020 08:42:10 GMT
content-type: text/html; charset=utf-8
set-cookie: 1e2670d92730b515ce3a1bb65da45062=9b714eb87e93cf34853e87a92d6894be; path=/; HttpOnly; Secure; SameSite=None
cache-control: private

HTTP/1.1 302 Found
content-length: 0
location: https://console-openshift-console.apps.<cluster-name>.<base domain>/
cache-control: no-cacheHTTP/1.1 200 OK
referrer-policy: strict-origin-when-cross-origin
set-cookie: csrf-token=39HoZgztDnzjJkq/JuLJMeoKNXlfiVv2YgZc09c3TBOBU4NI6kDXaJH1LdicNhN1UsQWzon4Dor9GWGfopaTEQ==; Path=/; Secure
x-content-type-options: nosniff
x-dns-prefetch-control: off
x-frame-options: DENY
x-xss-protection: 1; mode=block
date: Tue, 17 Nov 2020 08:42:10 GMT
content-type: text/html; charset=utf-8
set-cookie: 1e2670d92730b515ce3a1bb65da45062=9b714eb87e93cf34853e87a92d6894be; path=/; HttpOnly; Secure; SameSite=None
cache-control: private

Copy to Clipboard

Toggle word wrap

다음 명령을 실행하고 출력을 관찰하여 포트 443에서 각 클러스터 애플리케이션에 액세스할 수 있는지 확인하세요.

curl https://console-openshift-console.apps.<cluster_name>.<base_domain> -I -L --insecure

$ curl https://console-openshift-console.apps.<cluster_name>.<base_domain> -I -L --insecure

Copy to Clipboard

Toggle word wrap

구성이 올바르면 명령 출력에 다음과 같은 응답이 표시됩니다.

HTTP/1.1 200 OK
referrer-policy: strict-origin-when-cross-origin
set-cookie: csrf-token=UlYWOyQ62LWjw2h003xtYSKlh1a0Py2hhctw0WmV2YEdhJjFyQwWcGBsja261dGLgaYO0nxzVErhiXt6QepA7g==; Path=/; Secure; SameSite=Lax
x-content-type-options: nosniff
x-dns-prefetch-control: off
x-frame-options: DENY
x-xss-protection: 1; mode=block
date: Wed, 04 Oct 2023 16:29:38 GMT
content-type: text/html; charset=utf-8
set-cookie: 1e2670d92730b515ce3a1bb65da45062=1bf5e9573c9a2760c964ed1659cc1673; path=/; HttpOnly; Secure; SameSite=None
cache-control: private

HTTP/1.1 200 OK
referrer-policy: strict-origin-when-cross-origin
set-cookie: csrf-token=UlYWOyQ62LWjw2h003xtYSKlh1a0Py2hhctw0WmV2YEdhJjFyQwWcGBsja261dGLgaYO0nxzVErhiXt6QepA7g==; Path=/; Secure; SameSite=Lax
x-content-type-options: nosniff
x-dns-prefetch-control: off
x-frame-options: DENY
x-xss-protection: 1; mode=block
date: Wed, 04 Oct 2023 16:29:38 GMT
content-type: text/html; charset=utf-8
set-cookie: 1e2670d92730b515ce3a1bb65da45062=1bf5e9573c9a2760c964ed1659cc1673; path=/; HttpOnly; Secure; SameSite=None
cache-control: private

Copy to Clipboard

Toggle word wrap

3.4. Ingress Controller에서 플로팅 IP 주소 지정
링크 복사

기본적으로 Red Hat OpenStack Platform(RHOSP)의 OpenShift Container Platform 클러스터에 배포 시 부동 IP 주소가 무작위로 할당됩니다. 이 유동 IP 주소는 Ingress 포트와 연결되어 있습니다.

DNS 레코드와 클러스터 배포를 업데이트하기 전에 미리 부동 IP 주소를 만들어 두는 것이 좋습니다. 이런 상황에서는 Ingress Controller에 플로팅 IP 주소를 정의할 수 있습니다. Octavia를 사용하든 사용자 관리 클러스터를 사용하든 이 작업을 수행할 수 있습니다.

절차

플로팅 IP를 사용하여 Ingress Controller 사용자 정의 리소스(CR) 파일을 만듭니다.

Ingress 구성 예시 sample-ingress.yaml

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  namespace: openshift-ingress-operator
  name: <name> 
spec:
  domain: <domain> 
  endpointPublishingStrategy:
    type: LoadBalancerService
    loadBalancer:
      scope: External 
      providerParameters:
        type: OpenStack
        openstack:
          floatingIP: <ingress_port_IP>

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  namespace: openshift-ingress-operator
  name: <name>


spec:
  domain: <domain>


  endpointPublishingStrategy:
    type: LoadBalancerService
    loadBalancer:
      scope: External


      providerParameters:
        type: OpenStack
        openstack:
          floatingIP: <ingress_port_IP>

Copy to Clipboard

Toggle word wrap

1: Ingress Controller의 이름입니다. 기본 Ingress Controller를 사용하는 경우 이 필드의 값은 default 입니다.
2: Ingress Controller에서 서비스하는 DNS 이름입니다.
3: 유동 IP 주소를 사용하려면 범위를 외부 로 설정해야 합니다.
4: Ingress Controller가 수신하는 포트와 연결된 유동 IP 주소입니다.

다음 명령을 실행하여 CR 파일을 적용합니다.
```
oc apply -f sample-ingress.yaml
```
```
$ oc apply -f sample-ingress.yaml
```
Copy to Clipboard Toggle word wrap
Ingress Controller 엔드포인트로 DNS 레코드를 업데이트하세요.
```
*.apps.<name>.<domain>. IN A <ingress_port_IP>
```
```
*.apps.<name>.<domain>. IN A <ingress_port_IP>
```
Copy to Clipboard Toggle word wrap
OpenShift Container Platform 클러스터 생성을 계속합니다.

검증

다음 명령을 사용하여 IngressController 조건을 확인하여 로드 밸런서가 성공적으로 프로비저닝되었는지 확인하세요.

oc get ingresscontroller -n openshift-ingress-operator <name> -o jsonpath="{.status.conditions}" | yq -PC

$ oc get ingresscontroller -n openshift-ingress-operator <name> -o jsonpath="{.status.conditions}" | yq -PC

Copy to Clipboard

Toggle word wrap

4장. MetalLB로 로드 밸런싱
링크 복사

4.1. MetalLB 주소 풀 구성
링크 복사

클러스터 관리자는 주소 풀을 추가, 수정, 삭제할 수 있습니다. MetalLB Operator는 주소 풀 사용자 정의 리소스를 사용하여 MetalLB에서 서비스에 할당할 수 있는 IP 주소를 설정합니다. 예제에서 사용된 네임스페이스는 metallb-system 이라고 가정합니다.

MetalLB Operator를 설치하는 방법에 대한 자세한 내용은 MetalLB 및 MetalLB Operator 정보를 참조하세요.

4.1.1. IPAddressPool 사용자 정의 리소스에 관하여
링크 복사

다음 표에서는 IPAddressPool 사용자 지정 리소스의 필드에 대해 설명합니다.

Expand

표 4.1. MetalLB IPAddressPool 풀 사용자 정의 리소스
필드	유형	설명
`metadata.name`	`string`	주소 풀의 이름을 지정합니다. 서비스를 추가할 때 `metallb.io/address-pool` 주석에서 이 풀 이름을 지정하여 특정 풀에서 IP 주소를 선택할 수 있습니다. 문서 전체에서 `doc-example`, `silver`, `gold`라는 이름이 사용됩니다.
`metadata.namespace`	`string`	주소 풀의 네임스페이스를 지정합니다. MetalLB Operator에서 사용하는 동일한 네임스페이스를 지정합니다.
`metadata.label`	`string`	선택 사항: `IPAddressPool` 에 할당된 키 값 쌍을 지정합니다. 이는 `BGPAdvertisement` 및 `L2Advertisement` CRD의 `ipAddressPoolSelectors` 에서 참조되어 `IPAddressPool을` 광고와 연결할 수 있습니다.
`spec.addresses`	`string`	MetalLB 운영자가 서비스에 할당할 IP 주소 목록을 지정합니다. 하나의 풀에서 여러 범위를 지정할 수 있으며, 모든 범위는 동일한 설정을 공유합니다. CIDR 표기법에서 각 범위를 지정하거나 하이픈으로 구분된 시작 및 끝 IP 주소로 지정합니다.
`spec.autoAssign`	`boolean`	선택 사항: MetalLB에서 이 풀에서 IP 주소를 자동으로 할당하는지 여부를 지정합니다. `metallb.io/address-pool` 주석을 사용하여 이 풀에서 IP 주소를 명시적으로 요청하려면 `false를` 지정합니다. 기본값은 `true`입니다. 참고 IP 주소 풀 구성의 경우, `자동 할당이` 활성화된 경우 충돌을 방지하기 위해 주소 필드에 다른 네트워크 장치에서 사용 가능하고 사용되지 않는 IP, 특히 게이트웨이 주소만 지정해야 합니다.
`spec.avoidBuggyIPs`	`boolean`	선택 사항: 이 기능을 활성화하면 `.0` 및 `.255` 로 끝나는 IP 주소가 풀에서 할당되지 않습니다. 기본값은 `false`입니다. 일부 오래된 소비자 네트워크 장비는 실수로 `.0` 및 `.255` 로 끝나는 IP 주소를 차단합니다.

spec.serviceAllocation 사양을 구성하여 IPAddressPool 에서 서비스 및 네임스페이스에 IP 주소를 할당할 수 있습니다.

Expand

표 4.2. MetalLB IPAddressPool 사용자 정의 리소스 사양.serviceAllocation 하위 필드
필드	유형	설명
`priority`	`int`	선택 사항: 두 개 이상의 IP 주소 풀이 서비스나 네임스페이스와 일치하는 경우 IP 주소 풀 간의 우선 순위를 정의합니다. 숫자가 낮을수록 우선순위가 높습니다.
`네임스페이스`	`배열(문자열)`	선택 사항: IP 주소 풀의 IP 주소에 할당할 수 있는 네임스페이스 목록을 지정합니다.
`namespaceSelectors`	`배열(LabelSelector)`	선택 사항: 목록 형식의 레이블 선택기를 사용하여 IP 주소 풀의 IP 주소에 할당할 수 있는 네임스페이스 레이블을 지정합니다.
`serviceSelectors`	`배열(LabelSelector)`	선택 사항: 목록 형식의 레이블 선택기를 사용하여 주소 풀의 IP 주소에 할당할 수 있는 서비스 레이블을 지정합니다.

4.1.2. 주소 풀 구성
링크 복사

클러스터 관리자는 MetalLB가 로드 밸런서 서비스에 할당할 수 있는 IP 주소를 제어하기 위해 클러스터에 주소 풀을 추가할 수 있습니다.

사전 요구 사항

OpenShift CLI(oc)를 설치합니다.
cluster-admin 권한이 있는 사용자로 로그인합니다.

프로세스

다음 예시와 같은 내용을 담은 ipaddresspool.yaml 과 같은 파일을 만듭니다.

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  namespace: metallb-system
  name: doc-example
  labels: 
    zone: east
spec:
  addresses:
  - 203.0.113.1-203.0.113.10
  - 203.0.113.65-203.0.113.75
# ...

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  namespace: metallb-system
  name: doc-example
  labels:


    zone: east
spec:
  addresses:
  - 203.0.113.1-203.0.113.10
  - 203.0.113.65-203.0.113.75
# ...

Copy to Clipboard

Toggle word wrap

1: IPAddressPool 에 할당된 이 레이블은 BGPAdvertisement CRD의 ipAddressPoolSelectors 에서 참조되어 IPAddressPool을 광고와 연결할 수 있습니다.

IP 주소 풀에 대한 구성을 적용합니다.
```
oc apply -f ipaddresspool.yaml
```
```
$ oc apply -f ipaddresspool.yaml
```
Copy to Clipboard Toggle word wrap

검증

다음 명령을 입력하여 주소 풀을 확인하세요.

oc describe -n metallb-system IPAddressPool doc-example

$ oc describe -n metallb-system IPAddressPool doc-example

Copy to Clipboard

Toggle word wrap

출력 예

Name:         doc-example
Namespace:    metallb-system
Labels:       zone=east
Annotations:  <none>
API Version:  metallb.io/v1beta1
Kind:         IPAddressPool
Metadata:
  ...
Spec:
  Addresses:
    203.0.113.1-203.0.113.10
    203.0.113.65-203.0.113.75
  Auto Assign:  true
Events:         <none>

Name:         doc-example
Namespace:    metallb-system
Labels:       zone=east
Annotations:  <none>
API Version:  metallb.io/v1beta1
Kind:         IPAddressPool
Metadata:
  ...
Spec:
  Addresses:
    203.0.113.1-203.0.113.10
    203.0.113.65-203.0.113.75
  Auto Assign:  true
Events:         <none>

Copy to Clipboard

Toggle word wrap

doc-example 과 같은 주소 풀 이름과 IP 주소 범위가 출력에 존재하는지 확인하세요.

4.1.3. VLAN에 대한 MetalLB 주소 풀 구성
링크 복사

클러스터 관리자는 MetalLB가 로드 밸런서 서비스에 할당할 수 있는 생성된 VLAN의 IP 주소를 제어하기 위해 클러스터에 주소 풀을 추가할 수 있습니다.

사전 요구 사항

OpenShift CLI(oc)를 설치합니다.
별도의 VLAN을 구성합니다.
cluster-admin 권한이 있는 사용자로 로그인합니다.

프로세스

다음 예와 유사한 ipaddresspool-vlan.yaml 과 같은 파일을 만듭니다.
```
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  namespace: metallb-system
  name: doc-example-vlan
  labels:
    zone: east 
spec:
  addresses:
  - 192.168.100.1-192.168.100.254 
```
```
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  namespace: metallb-system
  name: doc-example-vlan
  labels:
    zone: east 
```
1
```
spec:
  addresses:
  - 192.168.100.1-192.168.100.254 
```
2
Copy to Clipboard Toggle word wrap
1
IPAddressPool 에 할당된 이 레이블은 BGPAdvertisement CRD의 ipAddressPoolSelectors 에서 참조되어 IPAddressPool을 광고와 연결할 수 있습니다.
2
이 IP 범위는 네트워크의 VLAN에 할당된 서브넷과 일치해야 합니다. 2계층(L2) 모드를 지원하려면 IP 주소 범위가 클러스터 노드와 동일한 서브넷 내에 있어야 합니다.
IP 주소 풀에 대한 구성을 적용합니다.
```
oc apply -f ipaddresspool-vlan.yaml
```
```
$ oc apply -f ipaddresspool-vlan.yaml
```
Copy to Clipboard Toggle word wrap

이 구성이 VLAN에 적용되도록 하려면 spec gatewayConfig.ipForwarding을 Global 로 설정해야 합니다.

다음 명령을 실행하여 네트워크 구성 사용자 정의 리소스(CR)를 편집합니다.
```
oc edit network.operator.openshift/cluster
```
```
$ oc edit network.operator.openshift/cluster
```
Copy to Clipboard Toggle word wrap

spec.defaultNetwork.ovnKubernetesConfig 섹션을 업데이트하여 gatewayConfig.ipForwarding을 Global 로 설정합니다. 다음과 같이 보여야 합니다.

예

...
spec:
  clusterNetwork:
    - cidr: 10.128.0.0/14
      hostPrefix: 23
  defaultNetwork:
    type: OVNKubernetes
    ovnKubernetesConfig:
      gatewayConfig:
        ipForwarding: Global
...

...
spec:
  clusterNetwork:
    - cidr: 10.128.0.0/14
      hostPrefix: 23
  defaultNetwork:
    type: OVNKubernetes
    ovnKubernetesConfig:
      gatewayConfig:
        ipForwarding: Global
...

Copy to Clipboard

Toggle word wrap

4.1.4. 주소 풀 구성의 예
링크 복사

다음 예에서는 특정 시나리오에 대한 주소 풀 구성을 보여줍니다.

4.1.4.1. 예: IPv4 및 CIDR 범위
링크 복사

클래스 없는 도메인 간 라우팅(CIDR) 표기법으로 IP 주소 범위를 지정할 수 있습니다. 하이픈을 사용하는 표기법과 CIDR 표기법을 결합하여 하한 및 상한을 분리할 수 있습니다.

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: doc-example-cidr
  namespace: metallb-system
spec:
  addresses:
  - 192.168.100.0/24
  - 192.168.200.0/24
  - 192.168.255.1-192.168.255.5
# ...

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: doc-example-cidr
  namespace: metallb-system
spec:
  addresses:
  - 192.168.100.0/24
  - 192.168.200.0/24
  - 192.168.255.1-192.168.255.5
# ...

Copy to Clipboard

Toggle word wrap

4.1.4.2. 예: IP 주소 할당
링크 복사

MetalLB가 풀에서 IP 주소를 자동으로 할당하지 못하도록 autoAssign 필드를 false 로 설정할 수 있습니다. 그런 다음 IP 주소 풀에서 하나 또는 여러 개의 IP 주소를 할당할 수 있습니다. IP 주소를 할당하려면 spec.addresses 매개변수의 대상 IP 주소에 /32 CIDR 표기법을 추가합니다. 이 설정을 사용하면 특정 IP 주소만 할당이 가능하고, 예약되지 않은 IP 주소는 애플리케이션에서 사용할 수 있습니다.

여러 IP 주소를 할당하는 IPAddressPool CR 예제

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: doc-example-reserved
  namespace: metallb-system
spec:
  addresses:
  - 192.168.100.1/32
  - 192.168.200.1/32
  autoAssign: false
# ...

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: doc-example-reserved
  namespace: metallb-system
spec:
  addresses:
  - 192.168.100.1/32
  - 192.168.200.1/32
  autoAssign: false
# ...

Copy to Clipboard

Toggle word wrap

참고

서비스를 추가할 때 풀에서 특정 IP 주소를 요청하거나 주석에 풀 이름을 지정하여 풀에서 IP 주소를 요청할 수 있습니다.

4.1.4.3. 예: IPv4 및 IPv6 주소
링크 복사

IPv4 및 IPv6를 사용하는 주소 풀을 추가할 수 있습니다. 그러나 여러 IPv4 예제와 마찬가지로 address 목록에 여러 범위를 지정할 수 있습니다.

서비스에 단일 IPv4 주소, 단일 IPv6 주소 또는 둘 다가 할당되는지는 서비스를 추가하는 방법에 따라 결정됩니다. spec.ipFamilies 및 spec.ipFamilyPolicy 필드는 IP 주소가 서비스에 할당되는 방식을 제어합니다.

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: doc-example-combined
  namespace: metallb-system
spec:
  addresses:
  - 10.0.100.0/28 
  - 2002:2:2::1-2002:2:2::100
# ...

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: doc-example-combined
  namespace: metallb-system
spec:
  addresses:
  - 10.0.100.0/28


  - 2002:2:2::1-2002:2:2::100
# ...

Copy to Clipboard

Toggle word wrap

1: 여기서 10.0.100.0/28 은 로컬 네트워크 IP 주소이고 뒤에 /28 네트워크 접두사가 붙습니다.

4.1.4.4. 예: 서비스 또는 네임스페이스에 IP 주소 풀 할당
링크 복사

IPAddressPool 에서 지정한 서비스와 네임스페이스에 IP 주소를 할당할 수 있습니다.

서비스나 네임스페이스를 두 개 이상의 IP 주소 풀에 할당하는 경우 MetalLB는 우선순위가 높은 IP 주소 풀에서 사용 가능한 IP 주소를 사용합니다. 높은 우선순위를 가진 할당된 IP 주소 풀에서 사용 가능한 IP 주소가 없는 경우 MetalLB는 낮은 우선순위를 가진 IP 주소 풀이나 우선순위가 없는 IP 주소 풀에서 사용 가능한 IP 주소를 사용합니다.

참고

namespaceSelectors 및 serviceSelectors 사양에는 matchLabels 레이블 선택기, matchExpressions 레이블 선택기 또는 둘 다를 사용할 수 있습니다. 이 예제에서는 각 사양에 대한 하나의 레이블 선택기를 보여줍니다.

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: doc-example-service-allocation
  namespace: metallb-system
spec:
  addresses:
    - 192.168.20.0/24
  serviceAllocation:
    priority: 50 
    namespaces: 
      - namespace-a
      - namespace-b
    namespaceSelectors: 
      - matchLabels:
          zone: east
    serviceSelectors: 
      - matchExpressions:
        - key: security
          operator: In
          values:
          - S1
# ...

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: doc-example-service-allocation
  namespace: metallb-system
spec:
  addresses:
    - 192.168.20.0/24
  serviceAllocation:
    priority: 50


    namespaces:


      - namespace-a
      - namespace-b
    namespaceSelectors:


      - matchLabels:
          zone: east
    serviceSelectors:


      - matchExpressions:
        - key: security
          operator: In
          values:
          - S1
# ...

Copy to Clipboard

Toggle word wrap

1: 주소 풀에 우선순위를 지정합니다. 숫자가 낮을수록 우선순위가 높습니다.
2: IP 주소 풀에 하나 이상의 네임스페이스를 목록 형식으로 할당합니다.
3: 목록 형식의 레이블 선택기를 사용하여 IP 주소 풀에 하나 이상의 네임스페이스 레이블을 할당합니다.
4: 목록 형식의 레이블 선택기를 사용하여 IP 주소 풀에 하나 이상의 서비스 레이블을 할당합니다.

4.2. IP 주소 풀에 대한 광고에 관하여
링크 복사

IP 주소가 2계층 프로토콜, BGP 프로토콜 또는 둘 다를 통해 광고되도록 MetalLB를 구성할 수 있습니다. MetalLB는 2계층을 통해 장애에 강한 외부 IP 주소를 제공합니다. MetalLB는 BGP를 사용하여 외부 IP 주소에 대한 내결함성과 부하 분산을 제공합니다.

MetalLB는 동일한 IP 주소 집합에 대해 L2 및 BGP를 사용한 광고를 지원합니다.

MetalLB는 네트워크의 노드 하위 집합에 효과적으로 특정 BGP 피어에 주소 풀을 할당할 수 있는 유연성을 제공합니다. 이를 통해 노드의 분리나 네트워크의 세분화를 용이하게 하는 등 보다 복잡한 구성이 가능해집니다.

4.2.1. BGPAdvertisement 사용자 정의 리소스에 관하여
링크 복사

BGPAdvertisements 개체의 필드는 다음 표에 정의되어 있습니다.

Expand

표 4.3. BGP광고 구성
필드	유형	설명
`metadata.name`	`string`	BGP 광고의 이름을 지정합니다.
`metadata.namespace`	`string`	BGP 광고에 대한 네임스페이스를 지정합니다. MetalLB Operator에서 사용하는 동일한 네임스페이스를 지정합니다.
`spec.aggregationLength`	`integer`	선택 사항: 32비트 CIDR 마스크에 포함할 비트 수를 지정합니다. 스피커가 BGP 피어에 광고하는 경로를 집계하기 위해 여러 서비스 IP 주소에 대한 경로에 마스크가 적용되고 스피커는 집계된 경로를 광고합니다. 예를 들어, 집계 길이가 `24` 인 경우 스피커는 여러 개의 `10.0.1.x/32` 서비스 IP 주소를 집계하고 단일 `10.0.1.0/24` 경로를 광고할 수 있습니다.
`spec.aggregationLengthV6`	`integer`	선택 사항: 128비트 CIDR 마스크에 포함할 비트 수를 지정합니다. 예를 들어, 집계 길이가 `124` 인 경우 스피커는 여러 개의 `fc00:f853:0ccd:e799::x/128` 서비스 IP 주소를 집계하고 단일 `fc00:f853:0ccd:e799::0/124` 경로를 광고할 수 있습니다.
`spec.communities`	`string`	선택 사항: 하나 이상의 BGP 커뮤니티를 지정합니다. 각 커뮤니티는 콜론 문자로 구분된 두 개의 16비트 값으로 지정됩니다. 잘 알려진 커뮤니티는 16비트 값으로 지정해야 합니다. `NO_EXPORT`: `65535:65281` `NO_ADVERTISE`: `65535:65282` `NO_EXPORT_SUBCONFED`: `65535:65283` 참고 문자열과 함께 생성되는 커뮤니티 객체를 사용할 수도 있습니다.
`spec.localPref`	`integer`	선택 사항: 이 광고에 대한 로컬 기본 설정을 지정합니다. 이 BGP 속성은 자율 시스템 내의 BGP 세션에 적용됩니다.
`spec.ipAddressPools`	`string`	선택 사항: 이름으로 선택된 이 광고와 함께 광고할 `IPAddressPool` 목록입니다.
`spec.ipAddressPoolSelectors`	`string`	선택 사항: 이 광고를 통해 광고되는 `IPAddressPools` 에 대한 선택기입니다. 이는 `IPAddressPool` 에 할당된 레이블을 기준으로 `IPAddressPool을` 광고에 연결하기 위한 것입니다. 이름 자체가 아닙니다. 이 목록이나 목록에서 `IPAddressPool을` 선택하지 않으면 광고가 모든 `IPAddressPool` 에 적용됩니다.
`spec.nodeSelectors`	`string`	선택 사항: `NodeSelectors를` 사용하면 로드 밸런서 IP에 대한 다음 홉으로 발표할 노드를 제한할 수 있습니다. 비어 있을 경우 모든 노드가 다음 홉으로 발표됩니다.
`spec.peers`	`string`	선택 사항: 목록을 사용하여 MetalLB 서비스 IP 주소에 대한 광고를 수신하는 각 `BGPPeer` 리소스에 대한 `metadata.name` 값을 지정합니다. MetalLB 서비스 IP 주소는 IP 주소 풀에서 할당됩니다. 기본적으로 MetalLB 서비스 IP 주소는 구성된 모든 `BGPPeer` 리소스에 광고됩니다. 이 필드를 사용하여 광고를 특정 `BGPpeer` 리소스로 제한합니다.

4.2.2. BGP 광고와 기본 사용 사례를 사용하여 MetalLB 구성
링크 복사

MetalLB를 다음과 같이 구성하여 피어 BGP 라우터가 MetalLB가 서비스에 할당한 각 로드 밸런서 IP 주소에 대해 하나의 203.0.113.200/32 경로와 하나의 fc00:f853:ccd:e799::1/128 경로를 수신하도록 합니다. localPref 및 communities 필드가 지정되지 않았으므로 경로는 localPref가 0으로 설정되고 BGP communities가 설정되지 않은 상태로 광고됩니다.

4.2.2.1. 예: BGP를 사용한 기본 주소 풀 구성 광고
링크 복사

IPAddressPool 이 BGP 프로토콜을 통해 광고되도록 MetalLB를 다음과 같이 구성합니다.

사전 요구 사항

OpenShift CLI(oc)를 설치합니다.
cluster-admin 권한이 있는 사용자로 로그인합니다.

프로세스

IP 주소 풀을 생성합니다.

다음 예시와 같은 내용을 담은 ipaddresspool.yaml 과 같은 파일을 만듭니다.

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  namespace: metallb-system
  name: doc-example-bgp-basic
spec:
  addresses:
    - 203.0.113.200/30
    - fc00:f853:ccd:e799::/124

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  namespace: metallb-system
  name: doc-example-bgp-basic
spec:
  addresses:
    - 203.0.113.200/30
    - fc00:f853:ccd:e799::/124

Copy to Clipboard

Toggle word wrap

IP 주소 풀에 대한 구성을 적용합니다.
```
oc apply -f ipaddresspool.yaml
```
```
$ oc apply -f ipaddresspool.yaml
```
Copy to Clipboard Toggle word wrap

BGP 광고를 생성합니다.

다음 예시와 같은 내용을 담은 bgpadvertisement.yaml 과 같은 파일을 만듭니다.

apiVersion: metallb.io/v1beta1
kind: BGPAdvertisement
metadata:
  name: bgpadvertisement-basic
  namespace: metallb-system
spec:
  ipAddressPools:
  - doc-example-bgp-basic

apiVersion: metallb.io/v1beta1
kind: BGPAdvertisement
metadata:
  name: bgpadvertisement-basic
  namespace: metallb-system
spec:
  ipAddressPools:
  - doc-example-bgp-basic

Copy to Clipboard

Toggle word wrap

설정을 적용합니다.
```
oc apply -f bgpadvertisement.yaml
```
```
$ oc apply -f bgpadvertisement.yaml
```
Copy to Clipboard Toggle word wrap

4.2.3. BGP 광고 및 고급 사용 사례를 사용하여 MetalLB 구성
링크 복사

MetalLB가 203.0.113.200 과 203.0.113.203 사이, 그리고 fc00:f853:ccd:e799::0 과 fc00:f853:ccd:e799::f 사이의 IP 주소를 부하 분산 서비스에 할당하도록 MetalLB를 다음과 같이 구성합니다.

두 가지 BGP 광고를 설명하기 위해 MetalLB가 서비스에 IP 주소 203.0.113.200을 할당하는 경우를 생각해 보겠습니다. 예를 들어 해당 IP 주소를 사용하여 스피커는 BGP 피어에 두 가지 경로를 광고합니다.

203.0.113.200/32 , localPref가 100 으로 설정되고 community가 NO_ADVERTISE 커뮤니티의 숫자 값으로 설정됩니다. 이 사양은 피어 라우터가 이 경로를 사용할 수 있지만 BGP 피어에 이 경로에 대한 정보를 전파해서는 안 된다는 것을 나타냅니다.
203.0.113.200/30은 MetalLB가 할당한 로드 밸런서 IP 주소를 단일 경로로 집계합니다. MetalLB는 커뮤니티 속성이 8000:800 으로 설정된 BGP 피어에 대한 집계 경로를 광고합니다. BGP 피어는 203.0.113.200/30 경로를 다른 BGP 피어에게 전파합니다. 트래픽이 스피커가 있는 노드로 라우팅되는 경우 203.0.113.200/32 경로는 트래픽을 클러스터와 서비스에 연결된 포드로 전달하는 데 사용됩니다.

더 많은 서비스를 추가하고 MetalLB가 풀에서 더 많은 로드 밸런서 IP 주소를 할당하면 피어 라우터는 각 서비스에 대해 하나의 로컬 경로인 203.0.113.20x/32 와 203.0.113.200/30 집계 경로를 수신합니다. 추가하는 각 서비스는 /30 경로를 생성하지만 MetalLB는 피어 라우터와 통신하기 전에 하나의 BGP 광고에 대한 경로 중복을 제거합니다.

4.2.3.1. 예: BGP를 사용한 고급 주소 풀 구성 광고
링크 복사

IPAddressPool 이 BGP 프로토콜을 통해 광고되도록 MetalLB를 다음과 같이 구성합니다.

사전 요구 사항

OpenShift CLI(oc)를 설치합니다.
cluster-admin 권한이 있는 사용자로 로그인합니다.

프로세스

IP 주소 풀을 생성합니다.

다음 예시와 같은 내용을 담은 ipaddresspool.yaml 과 같은 파일을 만듭니다.

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  namespace: metallb-system
  name: doc-example-bgp-adv
  labels:
    zone: east
spec:
  addresses:
    - 203.0.113.200/30
    - fc00:f853:ccd:e799::/124
  autoAssign: false

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  namespace: metallb-system
  name: doc-example-bgp-adv
  labels:
    zone: east
spec:
  addresses:
    - 203.0.113.200/30
    - fc00:f853:ccd:e799::/124
  autoAssign: false

Copy to Clipboard

Toggle word wrap

IP 주소 풀에 대한 구성을 적용합니다.
```
oc apply -f ipaddresspool.yaml
```
```
$ oc apply -f ipaddresspool.yaml
```
Copy to Clipboard Toggle word wrap

BGP 광고를 생성합니다.

다음 예시와 같은 내용을 담은 bgpadvertisement1.yaml 과 같은 파일을 만듭니다.

apiVersion: metallb.io/v1beta1
kind: BGPAdvertisement
metadata:
  name: bgpadvertisement-adv-1
  namespace: metallb-system
spec:
  ipAddressPools:
    - doc-example-bgp-adv
  communities:
    - 65535:65282
  aggregationLength: 32
  localPref: 100

apiVersion: metallb.io/v1beta1
kind: BGPAdvertisement
metadata:
  name: bgpadvertisement-adv-1
  namespace: metallb-system
spec:
  ipAddressPools:
    - doc-example-bgp-adv
  communities:
    - 65535:65282
  aggregationLength: 32
  localPref: 100

Copy to Clipboard

Toggle word wrap

설정을 적용합니다.
```
oc apply -f bgpadvertisement1.yaml
```
```
$ oc apply -f bgpadvertisement1.yaml
```
Copy to Clipboard Toggle word wrap

다음 예시와 같은 내용을 포함하는 bgpadvertisement2.yaml 과 같은 파일을 만듭니다.

apiVersion: metallb.io/v1beta1
kind: BGPAdvertisement
metadata:
  name: bgpadvertisement-adv-2
  namespace: metallb-system
spec:
  ipAddressPools:
    - doc-example-bgp-adv
  communities:
    - 8000:800
  aggregationLength: 30
  aggregationLengthV6: 124

apiVersion: metallb.io/v1beta1
kind: BGPAdvertisement
metadata:
  name: bgpadvertisement-adv-2
  namespace: metallb-system
spec:
  ipAddressPools:
    - doc-example-bgp-adv
  communities:
    - 8000:800
  aggregationLength: 30
  aggregationLengthV6: 124

Copy to Clipboard

Toggle word wrap

설정을 적용합니다.
```
oc apply -f bgpadvertisement2.yaml
```
```
$ oc apply -f bgpadvertisement2.yaml
```
Copy to Clipboard Toggle word wrap

4.2.4. 노드 하위 집합에서 IP 주소 풀 광고
링크 복사

IP 주소 풀에서 특정 노드 집합의 IP 주소를 광고하려면 BGPAdvertisement 사용자 지정 리소스에서 .spec.nodeSelector 사양을 사용합니다. 이 사양은 IP 주소 풀을 클러스터의 노드 집합과 연관시킵니다. 이 기능은 클러스터 내 여러 서브넷에 노드가 있고 특정 서브넷(예: 공개 서브넷)의 주소 풀에서 IP 주소를 광고하려는 경우에 유용합니다.

사전 요구 사항

OpenShift CLI(oc)를 설치합니다.
cluster-admin 권한이 있는 사용자로 로그인합니다.

프로세스

사용자 지정 리소스를 사용하여 IP 주소 풀을 만듭니다.

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  namespace: metallb-system
  name: pool1
spec:
  addresses:
    - 4.4.4.100-4.4.4.200
    - 2001:100:4::200-2001:100:4::400

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  namespace: metallb-system
  name: pool1
spec:
  addresses:
    - 4.4.4.100-4.4.4.200
    - 2001:100:4::200-2001:100:4::400

Copy to Clipboard

Toggle word wrap

BGPAdvertisement 사용자 정의 리소스에서 .spec.nodeSelector 값을 정의하여 pool1 의 IP 주소가 광고되는 클러스터의 노드를 제어합니다.

apiVersion: metallb.io/v1beta1
kind: BGPAdvertisement
metadata:
  name: example
spec:
  ipAddressPools:
  - pool1
  nodeSelector:
  - matchLabels:
      kubernetes.io/hostname: NodeA
  - matchLabels:
      kubernetes.io/hostname: NodeB

apiVersion: metallb.io/v1beta1
kind: BGPAdvertisement
metadata:
  name: example
spec:
  ipAddressPools:
  - pool1
  nodeSelector:
  - matchLabels:
      kubernetes.io/hostname: NodeA
  - matchLabels:
      kubernetes.io/hostname: NodeB

Copy to Clipboard

Toggle word wrap

이 예에서 pool1 의 IP 주소는 NodeA 와 NodeB 에서만 광고됩니다.

4.2.5. L2Advertisement 사용자 정의 리소스에 관하여
링크 복사

l2Advertisements 개체의 필드는 다음 표에 정의되어 있습니다.

Expand

표 4.4. L2 광고 구성
필드	유형	설명
`metadata.name`	`string`	L2 광고의 이름을 지정합니다.
`metadata.namespace`	`string`	L2 광고에 대한 네임스페이스를 지정합니다. MetalLB Operator에서 사용하는 동일한 네임스페이스를 지정합니다.
`spec.ipAddressPools`	`string`	선택 사항: 이름으로 선택된 이 광고와 함께 광고할 `IPAddressPool` 목록입니다.
`spec.ipAddressPoolSelectors`	`string`	선택 사항: 이 광고를 통해 광고되는 `IPAddressPools` 에 대한 선택기입니다. 이는 `IPAddressPool` 에 할당된 레이블을 기준으로 `IPAddressPool을` 광고에 연결하기 위한 것입니다. 이름 자체가 아닙니다. 이 목록이나 목록에서 `IPAddressPool을` 선택하지 않으면 광고가 모든 `IPAddressPool` 에 적용됩니다.
`spec.nodeSelectors`	`string`	선택 사항: `NodeSelectors는` 로드 밸런서 IP에 대한 다음 홉으로 발표할 노드를 제한합니다. 비어 있을 경우 모든 노드가 다음 홉으로 발표됩니다. 중요 다음 홉으로 발표할 노드를 제한하는 것은 기술 미리 보기 기능에만 해당됩니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다. Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.
`spec.interfaces`	`string`	선택 사항: 로드 밸런서 IP를 알리는 데 사용되는 `인터페이스` 목록입니다.

4.2.6. L2 광고로 MetalLB 구성
링크 복사

IPAddressPool 이 L2 프로토콜을 통해 광고되도록 MetalLB를 다음과 같이 구성합니다.

사전 요구 사항

OpenShift CLI(oc)를 설치합니다.
cluster-admin 권한이 있는 사용자로 로그인합니다.

프로세스

IP 주소 풀을 생성합니다.

다음 예시와 같은 내용을 담은 ipaddresspool.yaml 과 같은 파일을 만듭니다.

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  namespace: metallb-system
  name: doc-example-l2
spec:
  addresses:
    - 4.4.4.0/24
  autoAssign: false

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  namespace: metallb-system
  name: doc-example-l2
spec:
  addresses:
    - 4.4.4.0/24
  autoAssign: false

Copy to Clipboard

Toggle word wrap

IP 주소 풀에 대한 구성을 적용합니다.
```
oc apply -f ipaddresspool.yaml
```
```
$ oc apply -f ipaddresspool.yaml
```
Copy to Clipboard Toggle word wrap

L2 광고를 만드세요.

다음 예시와 같은 내용을 담은 l2advertisement.yaml 과 같은 파일을 만듭니다.

apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: l2advertisement
  namespace: metallb-system
spec:
  ipAddressPools:
   - doc-example-l2

apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: l2advertisement
  namespace: metallb-system
spec:
  ipAddressPools:
   - doc-example-l2

Copy to Clipboard

Toggle word wrap

설정을 적용합니다.
```
oc apply -f l2advertisement.yaml
```
```
$ oc apply -f l2advertisement.yaml
```
Copy to Clipboard Toggle word wrap

4.2.7. L2 광고 및 레이블을 사용하여 MetalLB 구성
링크 복사

BGPAdvertisement 및 L2Advertisement 사용자 지정 리소스 정의의 ipAddressPoolSelectors 필드는 이름 자체가 아닌 IPAddressPool 에 할당된 레이블을 기준으로 IPAddressPool 을 광고에 연결하는 데 사용됩니다.

이 예제에서는 ipAddressPoolSelectors 필드를 구성하여 IPAddressPool 이 L2 프로토콜을 통해 광고되도록 MetalLB를 구성하는 방법을 보여줍니다.

사전 요구 사항

OpenShift CLI(oc)를 설치합니다.
cluster-admin 권한이 있는 사용자로 로그인합니다.

프로세스

IP 주소 풀을 생성합니다.

다음 예시와 같은 내용을 담은 ipaddresspool.yaml 과 같은 파일을 만듭니다.

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  namespace: metallb-system
  name: doc-example-l2-label
  labels:
    zone: east
spec:
  addresses:
    - 172.31.249.87/32

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  namespace: metallb-system
  name: doc-example-l2-label
  labels:
    zone: east
spec:
  addresses:
    - 172.31.249.87/32

Copy to Clipboard

Toggle word wrap

IP 주소 풀에 대한 구성을 적용합니다.
```
oc apply -f ipaddresspool.yaml
```
```
$ oc apply -f ipaddresspool.yaml
```
Copy to Clipboard Toggle word wrap

ipAddressPoolSelectors를 사용하여 IP를 광고하는 L2 광고를 만듭니다.

다음 예시와 같은 내용을 담은 l2advertisement.yaml 과 같은 파일을 만듭니다.

apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: l2advertisement-label
  namespace: metallb-system
spec:
  ipAddressPoolSelectors:
    - matchExpressions:
        - key: zone
          operator: In
          values:
            - east

apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: l2advertisement-label
  namespace: metallb-system
spec:
  ipAddressPoolSelectors:
    - matchExpressions:
        - key: zone
          operator: In
          values:
            - east

Copy to Clipboard

Toggle word wrap

설정을 적용합니다.
```
oc apply -f l2advertisement.yaml
```
```
$ oc apply -f l2advertisement.yaml
```
Copy to Clipboard Toggle word wrap

4.2.8. 선택된 인터페이스에 대한 L2 광고로 MetalLB 구성
링크 복사

기본적으로 서비스에 할당된 IP 주소 풀의 IP 주소는 모든 네트워크 인터페이스에서 광고됩니다. L2Advertisement 사용자 정의 리소스 정의의 인터페이스 필드는 IP 주소 풀을 광고하는 네트워크 인터페이스를 제한하는 데 사용됩니다.

이 예제에서는 모든 노드의 인터페이스 필드에 나열된 네트워크 인터페이스에서만 IP 주소 풀이 광고되도록 MetalLB를 구성하는 방법을 보여줍니다.

사전 요구 사항

OpenShift CLI(oc)가 설치되어 있습니다.
클러스터 관리자 권한이 있는 사용자로 로그인했습니다.

프로세스

IP 주소 풀을 생성합니다.

ipaddresspool.yaml 과 같은 파일을 만들고 다음 예와 같이 구성 세부 정보를 입력합니다.

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  namespace: metallb-system
  name: doc-example-l2
spec:
  addresses:
    - 4.4.4.0/24
  autoAssign: false

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  namespace: metallb-system
  name: doc-example-l2
spec:
  addresses:
    - 4.4.4.0/24
  autoAssign: false

Copy to Clipboard

Toggle word wrap

다음 예와 같이 IP 주소 풀에 대한 구성을 적용합니다.
```
oc apply -f ipaddresspool.yaml
```
```
$ oc apply -f ipaddresspool.yaml
```
Copy to Clipboard Toggle word wrap

인터페이스 선택기를 사용하여 IP를 광고하는 L2 광고를 만듭니다.

l2advertisement.yaml 과 같은 YAML 파일을 만들고 다음 예와 같이 구성 세부 정보를 입력합니다.

apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: l2advertisement
  namespace: metallb-system
spec:
  ipAddressPools:
   - doc-example-l2
   interfaces:
   - interfaceA
   - interfaceB

apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: l2advertisement
  namespace: metallb-system
spec:
  ipAddressPools:
   - doc-example-l2
   interfaces:
   - interfaceA
   - interfaceB

Copy to Clipboard

Toggle word wrap

다음 예와 같이 광고에 대한 구성을 적용합니다.
```
oc apply -f l2advertisement.yaml
```
```
$ oc apply -f l2advertisement.yaml
```
Copy to Clipboard Toggle word wrap

중요

인터페이스 선택기는 MetalLB가 L2를 사용하여 주어진 IP를 알리는 노드를 선택하는 방식에 영향을 미치지 않습니다. 선택한 노드에 선택한 인터페이스가 없으면 해당 노드는 서비스를 알리지 않습니다.

4.2.9. 보조 네트워크로 MetalLB 구성
링크 복사

OpenShift Container Platform 4.14부터 기본 네트워크 동작은 네트워크 인터페이스 간에 IP 패킷 전달을 허용하지 않는 것입니다. 따라서 MetalLB가 보조 인터페이스에 구성되는 경우 필요한 인터페이스에 대해서만 IP 전달을 활성화하기 위해 머신 구성을 추가해야 합니다.

참고

4.13에서 업그레이드된 OpenShift Container Platform 클러스터는 업그레이드 중에 글로벌 IP 전달을 활성화하는 글로벌 매개변수가 설정되므로 영향을 받지 않습니다.

보조 인터페이스에 대한 IP 전달을 활성화하려면 두 가지 옵션이 있습니다.

특정 인터페이스에 대한 IP 전달을 활성화합니다.
모든 인터페이스에 대해 IP 전달을 활성화합니다.
참고
특정 인터페이스에 대해 IP 전달을 활성화하면 보다 세부적인 제어가 가능하지만, 모든 인터페이스에 대해 IP 전달을 활성화하면 글로벌 설정이 적용됩니다.

4.2.9.1. 특정 인터페이스에 대한 IP 전달 활성화
링크 복사

프로세스

다음 명령을 실행하여 매개변수 routingViaHost를 true 로 설정하여 클러스터 네트워크 운영자를 패치합니다.

oc patch network.operator cluster -p '{"spec":{"defaultNetwork":{"ovnKubernetesConfig":{"gatewayConfig": {"routingViaHost": true} }}}}' --type=merge

$ oc patch network.operator cluster -p '{"spec":{"defaultNetwork":{"ovnKubernetesConfig":{"gatewayConfig": {"routingViaHost": true} }}}}' --type=merge

Copy to Clipboard

Toggle word wrap

MachineConfig CR을 생성하고 적용하여 bridge-net 과 같은 특정 보조 인터페이스에 대한 전달을 활성화합니다.

로컬 머신에서 다음 명령을 실행하여 네트워크 커널 매개변수를 구성하는 데 사용되는 문자열을 Base64로 인코딩합니다.

echo -e "net.ipv4.conf.bridge-net.forwarding = 1\nnet.ipv6.conf.bridge-net.forwarding = 1\nnet.ipv4.conf.bridge-net.rp_filter = 0\nnet.ipv6.conf.bridge-net.rp_filter = 0" | base64 -w0

$ echo -e "net.ipv4.conf.bridge-net.forwarding = 1\nnet.ipv6.conf.bridge-net.forwarding = 1\nnet.ipv4.conf.bridge-net.rp_filter = 0\nnet.ipv6.conf.bridge-net.rp_filter = 0" | base64 -w0

Copy to Clipboard

Toggle word wrap

출력 예

bmV0LmlwdjQuY29uZi5icmlkZ2UtbmV0LmZvcndhcmRpbmcgPSAxCm5ldC5pcHY2LmNvbmYuYnJpZGdlLW5ldC5mb3J3YXJkaW5nID0gMQpuZXQuaXB2NC5jb25mLmJyaWRnZS1uZXQucnBfZmlsdGVyID0gMApuZXQuaXB2Ni5jb25mLmJyaWRnZS1uZXQucnBfZmlsdGVyID0gMAo=

bmV0LmlwdjQuY29uZi5icmlkZ2UtbmV0LmZvcndhcmRpbmcgPSAxCm5ldC5pcHY2LmNvbmYuYnJpZGdlLW5ldC5mb3J3YXJkaW5nID0gMQpuZXQuaXB2NC5jb25mLmJyaWRnZS1uZXQucnBfZmlsdGVyID0gMApuZXQuaXB2Ni5jb25mLmJyaWRnZS1uZXQucnBfZmlsdGVyID0gMAo=

Copy to Clipboard

Toggle word wrap

bridge-net 이라는 지정된 보조 인터페이스에 대한 IP 전달을 활성화하기 위해 MachineConfig CR을 만듭니다.

다음 YAML을 enable-ip-forward.yaml 파일에 저장합니다.

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: <node_role> 
  name: 81-enable-global-forwarding
spec:
  config:
    ignition:
      version: 3.2.0
    storage:
      files:
      - contents:
          source: data:text/plain;charset=utf-8;base64,bmV0LmlwdjQuY29uZi5icmlkZ2UtbmV0LmZvcndhcmRpbmcgPSAxCm5ldC5pcHY2LmNvbmYuYnJpZGdlLW5ldC5mb3J3YXJkaW5nID0gMQpuZXQuaXB2NC5jb25mLmJyaWRnZS1uZXQucnBfZmlsdGVyID0gMApuZXQuaXB2Ni5jb25mLmJyaWRnZS1uZXQucnBfZmlsdGVyID0gMAo= 
          verification: {}
        filesystem: root
        mode: 420
        path: /etc/sysctl.d/enable-global-forwarding.conf
  osImageURL: ""

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: <node_role>


  name: 81-enable-global-forwarding
spec:
  config:
    ignition:
      version: 3.2.0
    storage:
      files:
      - contents:
          source: data:text/plain;charset=utf-8;base64,bmV0LmlwdjQuY29uZi5icmlkZ2UtbmV0LmZvcndhcmRpbmcgPSAxCm5ldC5pcHY2LmNvbmYuYnJpZGdlLW5ldC5mb3J3YXJkaW5nID0gMQpuZXQuaXB2NC5jb25mLmJyaWRnZS1uZXQucnBfZmlsdGVyID0gMApuZXQuaXB2Ni5jb25mLmJyaWRnZS1uZXQucnBfZmlsdGVyID0gMAo=


          verification: {}
        filesystem: root
        mode: 420
        path: /etc/sysctl.d/enable-global-forwarding.conf
  osImageURL: ""

Copy to Clipboard

Toggle word wrap

1: IP 전달을 활성화하려는 노드 역할(예: 작업자)
2: 생성된 base64 문자열로 채우기

다음 명령을 실행하여 구성을 적용합니다.
```
oc apply -f enable-ip-forward.yaml
```
```
$ oc apply -f enable-ip-forward.yaml
```
Copy to Clipboard Toggle word wrap

검증

머신 구성을 적용한 후 다음 절차에 따라 변경 사항을 확인하세요.
1. 다음 명령을 실행하여 대상 노드에서 디버그 세션을 시작합니다.
  $ oc debug node/<node-name>
  Copy to Clipboard Toggle word wrap
  이 단계에서는 <node-name>-debug 라는 디버그 포드를 인스턴스화합니다.
2. 다음 명령을 실행하여 디버그 셸에서 /host를 루트 디렉터리로 설정합니다.
  $ chroot /host
  Copy to Clipboard Toggle word wrap
  디버그 Pod는 Pod 내의 /host에 호스트의 루트 파일 시스템을 마운트합니다. 루트 디렉토리를 /host 로 변경하면 호스트의 실행 파일 경로에 포함된 바이너리를 실행할 수 있습니다.
3. 다음 명령을 실행하여 IP 전달이 활성화되었는지 확인하세요.
  $ cat /etc/sysctl.d/enable-global-forwarding.conf
  Copy to Clipboard Toggle word wrap
  예상 출력
  net.ipv4.conf.bridge-net.forwarding = 1 net.ipv6.conf.bridge-net.forwarding = 1 net.ipv4.conf.bridge-net.rp_filter = 0 net.ipv6.conf.bridge-net.rp_filter = 0
  
  Copy to Clipboard Toggle word wrap
  출력은 브리지-넷 인터페이스에서 IPv4 및 IPv6 패킷 전달이 활성화되었음을 나타냅니다.

4.2.9.2. 전 세계적으로 IP 전달 활성화
링크 복사

다음 명령을 실행하여 IP 전달을 전역적으로 활성화합니다.

oc patch network.operator cluster -p '{"spec":{"defaultNetwork":{"ovnKubernetesConfig":{"gatewayConfig":{"ipForwarding": "Global"}}}}}' --type=merge

$ oc patch network.operator cluster -p '{"spec":{"defaultNetwork":{"ovnKubernetesConfig":{"gatewayConfig":{"ipForwarding": "Global"}}}}}' --type=merge

Copy to Clipboard

Toggle word wrap

4.3. MetalLB BGP 피어 구성
링크 복사

클러스터 관리자는 BGP(Border Gateway Protocol) 피어를 추가, 수정, 삭제할 수 있습니다. MetalLB 운영자는 BGP 피어 사용자 정의 리소스를 사용하여 MetalLB 스피커 포드가 BGP 세션을 시작하기 위해 접속하는 피어를 식별합니다. 피어는 MetalLB가 서비스에 할당한 로드 밸런서 IP 주소에 대한 경로 광고를 수신합니다.

4.3.1. BGP 피어 사용자 정의 리소스에 관하여
링크 복사

다음 표에서는 BGP 피어 사용자 지정 리소스의 필드에 대해 설명합니다.

Expand

표 4.5. MetalLB BGP 피어 사용자 정의 리소스
필드	유형	설명
`metadata.name`	`string`	BGP 피어 사용자 정의 리소스의 이름을 지정합니다.
`metadata.namespace`	`string`	BGP 피어 사용자 지정 리소스에 대한 네임스페이스를 지정합니다.
`spec.myASN`	`integer`	BGP 세션의 로컬 종료에 대한 ASN(자율 시스템 번호)을 지정합니다. 추가하는 모든 BGP 피어 사용자 정의 리소스에 동일한 값을 지정합니다. 범위는 `0` ~ `4294967295` 입니다.
`spec.peerASN`	`integer`	BGP 세션의 원격 끝에 대한 ASN을 지정합니다. 범위는 `0` ~ `4294967295` 입니다. 이 필드를 사용하는 경우 `spec.dynamicASN` 필드에 값을 지정할 수 없습니다.
`spec.dynamicASN`	`string`	명시적으로 설정하지 않고 세션의 원격 끝에 사용할 ASN을 감지합니다. 동일한 ASN을 가진 피어의 경우 `내부를` 지정하고, 다른 ASN을 가진 피어의 경우 `외부를` 지정합니다. 이 필드를 사용하면 `spec.peerASN` 필드에 값을 지정할 수 없습니다.
`spec.peerAddress`	`string`	BGP 세션을 설정하기 위해 연결할 피어의 IP 주소를 지정합니다. 이 필드를 사용하면 `spec.interface` 필드에 값을 지정할 수 없습니다.
`spec.interface`	`string`	세션을 설정할 때 사용할 인터페이스 이름을 지정합니다. 이 필드를 사용하여 번호가 지정되지 않은 BGP 피어링을 구성합니다. 두 BGP 피어 간에 지점 간, 계층 2 연결을 설정해야 합니다. IPv4, IPv6 또는 듀얼 스택에서 번호가 지정되지 않은 BGP 피어링을 사용할 수 있지만 IPv6 RA(라우터 광고)를 활성화해야 합니다. 각 인터페이스는 하나의 BGP 연결로 제한됩니다. 이 필드를 사용하면 `spec.peerAddress` 필드에 값을 지정할 수 없습니다. `spec.bgp.routers.neighbors.interface` 필드는 기술 미리보기 기능에만 해당됩니다. Red Hat Technology Preview 기능의 지원 범위에 대한 자세한 내용은 Technology Preview 기능 지원 범위를 참조하세요.
`spec.sourceAddress`	`string`	선택 사항: BGP 세션을 설정할 때 사용할 IP 주소를 지정합니다. 값은 IPv4 주소여야 합니다.
`spec.peerPort`	`integer`	선택 사항: BGP 세션을 설정하기 위해 연결할 피어의 네트워크 포트를 지정합니다. 범위는 `0` ~ `16384` 입니다.
`spec.holdTime`	`string`	선택 사항: BGP 피어에 제안할 보류 시간의 기간을 지정합니다. 최소값은 3초( `3s` )입니다. 일반적인 단위는 초와 분으로, `3초` , `1분` , `5분 30초` 등이 있습니다. 경로 오류를 더 빠르게 감지하려면 BFD도 구성하세요.
`spec.keepaliveTime`	`string`	선택 사항: BGP 피어에 keep-alive 메시지를 보내는 최대 간격을 지정합니다. 이 필드를 지정하는 경우 `holdTime` 필드에 대한 값도 지정해야 합니다. 지정된 값은 `holdTime` 필드의 값보다 작아야 합니다.
`spec.routerID`	`string`	선택 사항: BGP 피어에 광고할 라우터 ID를 지정합니다. 이 필드를 지정하는 경우 추가하는 모든 BGP 피어 사용자 지정 리소스에 동일한 값을 지정해야 합니다.
`spec.password`	`string`	선택 사항: TCP MD5 인증 BGP 세션을 강제하는 라우터에 대해 피어로 보낼 MD5 비밀번호를 지정합니다.
`spec.passwordSecret`	`string`	선택 사항: BGP 피어에 대한 인증 비밀번호의 이름을 지정합니다. 비밀은 `metallb` 네임스페이스에 있어야 하며 basic-auth 유형이어야 합니다.
`spec.bfdProfile`	`string`	선택 사항: BFD 프로필의 이름을 지정합니다.
`spec.nodeSelectors`	`object[]`	선택 사항: 일치 표현식과 일치 레이블을 사용하여 선택기를 지정하여 어떤 노드가 BGP 피어에 연결할 수 있는지 제어합니다.
`spec.ebgpMultiHop`	`boolean`	선택 사항: BGP 피어가 여러 네트워크 홉 떨어져 있음을 지정합니다. BGP 피어가 동일한 네트워크에 직접 연결되어 있지 않으면 이 필드가 `true` 로 설정되지 않는 한 스피커는 BGP 세션을 설정할 수 없습니다. 이 필드는 외부 BGP 에 적용됩니다. 외부 BGP는 BGP 피어가 다른 자율 시스템에 속하는 경우를 설명하는 데 사용되는 용어입니다.
`connectTime`	`duration`	BGP가 이웃과의 연결을 시도하는 사이에 기다리는 시간을 지정합니다.

참고

passwordSecret 필드는 password 필드와 상호 배타적이며, 사용할 비밀번호가 포함된 비밀에 대한 참조를 포함합니다. 두 필드를 모두 설정하면 구문 분석에 실패합니다.

4.3.2. BGP 피어 구성
링크 복사

클러스터 관리자는 BGP 피어 사용자 정의 리소스를 추가하여 네트워크 라우터와 라우팅 정보를 교환하고 서비스의 IP 주소를 광고할 수 있습니다.

사전 요구 사항

OpenShift CLI(oc)를 설치합니다.
cluster-admin 권한이 있는 사용자로 로그인합니다.
BGP 광고로 MetalLB를 구성합니다.

프로세스

다음 예시와 같은 내용을 담은 bgppeer.yaml 과 같은 파일을 만듭니다.

apiVersion: metallb.io/v1beta2
kind: BGPPeer
metadata:
  namespace: metallb-system
  name: doc-example-peer
spec:
  peerAddress: 10.0.0.1
  peerASN: 64501
  myASN: 64500
  routerID: 10.10.10.10

apiVersion: metallb.io/v1beta2
kind: BGPPeer
metadata:
  namespace: metallb-system
  name: doc-example-peer
spec:
  peerAddress: 10.0.0.1
  peerASN: 64501
  myASN: 64500
  routerID: 10.10.10.10

Copy to Clipboard

Toggle word wrap

BGP 피어에 대한 구성을 적용합니다.
```
oc apply -f bgppeer.yaml
```
```
$ oc apply -f bgppeer.yaml
```
Copy to Clipboard Toggle word wrap

4.3.3. 지정된 주소 풀에 대해 특정 BGP 피어 세트를 구성합니다.
링크 복사

이 절차에서는 다음 작업을 수행하는 방법을 보여줍니다.

주소 풀 세트( pool1 및 pool2 )를 구성합니다.
BGP 피어 세트( peer1 및 peer2 )를 구성합니다.
BGP 광고를 구성하여 pool1을 peer1 에, pool2를 peer2 에 할당합니다.

사전 요구 사항

OpenShift CLI(oc)를 설치합니다.
cluster-admin 권한이 있는 사용자로 로그인합니다.

프로세스

주소 풀 pool1을 생성합니다.

다음 예시와 같은 내용을 담은 ipaddresspool1.yaml 과 같은 파일을 만듭니다.

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  namespace: metallb-system
  name: pool1
spec:
  addresses:
    - 4.4.4.100-4.4.4.200
    - 2001:100:4::200-2001:100:4::400

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  namespace: metallb-system
  name: pool1
spec:
  addresses:
    - 4.4.4.100-4.4.4.200
    - 2001:100:4::200-2001:100:4::400

Copy to Clipboard

Toggle word wrap

IP 주소 풀 pool1 에 대한 구성을 적용합니다.
```
oc apply -f ipaddresspool1.yaml
```
```
$ oc apply -f ipaddresspool1.yaml
```
Copy to Clipboard Toggle word wrap

주소 풀 pool2를 생성합니다.

다음 예시와 같은 내용을 담은 ipaddresspool2.yaml 과 같은 파일을 만듭니다.

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  namespace: metallb-system
  name: pool2
spec:
  addresses:
    - 5.5.5.100-5.5.5.200
    - 2001:100:5::200-2001:100:5::400

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  namespace: metallb-system
  name: pool2
spec:
  addresses:
    - 5.5.5.100-5.5.5.200
    - 2001:100:5::200-2001:100:5::400

Copy to Clipboard

Toggle word wrap

IP 주소 풀 pool2 에 대한 구성을 적용합니다.
```
oc apply -f ipaddresspool2.yaml
```
```
$ oc apply -f ipaddresspool2.yaml
```
Copy to Clipboard Toggle word wrap

BGP peer1을 생성합니다.

다음 예시와 같은 내용을 포함하는 bgppeer1.yaml 과 같은 파일을 만듭니다.

apiVersion: metallb.io/v1beta2
kind: BGPPeer
metadata:
  namespace: metallb-system
  name: peer1
spec:
  peerAddress: 10.0.0.1
  peerASN: 64501
  myASN: 64500
  routerID: 10.10.10.10

apiVersion: metallb.io/v1beta2
kind: BGPPeer
metadata:
  namespace: metallb-system
  name: peer1
spec:
  peerAddress: 10.0.0.1
  peerASN: 64501
  myASN: 64500
  routerID: 10.10.10.10

Copy to Clipboard

Toggle word wrap

BGP 피어에 대한 구성을 적용합니다.
```
oc apply -f bgppeer1.yaml
```
```
$ oc apply -f bgppeer1.yaml
```
Copy to Clipboard Toggle word wrap

BGP peer2를 생성합니다.

다음 예시와 같은 내용을 포함하는 bgppeer2.yaml 과 같은 파일을 만듭니다.

apiVersion: metallb.io/v1beta2
kind: BGPPeer
metadata:
  namespace: metallb-system
  name: peer2
spec:
  peerAddress: 10.0.0.2
  peerASN: 64501
  myASN: 64500
  routerID: 10.10.10.10

apiVersion: metallb.io/v1beta2
kind: BGPPeer
metadata:
  namespace: metallb-system
  name: peer2
spec:
  peerAddress: 10.0.0.2
  peerASN: 64501
  myASN: 64500
  routerID: 10.10.10.10

Copy to Clipboard

Toggle word wrap

BGP peer2에 대한 구성을 적용합니다.
```
oc apply -f bgppeer2.yaml
```
```
$ oc apply -f bgppeer2.yaml
```
Copy to Clipboard Toggle word wrap

BGP 광고 생성 1.

다음 예시와 같은 내용을 담은 bgpadvertisement1.yaml 과 같은 파일을 만듭니다.

apiVersion: metallb.io/v1beta1
kind: BGPAdvertisement
metadata:
  name: bgpadvertisement-1
  namespace: metallb-system
spec:
  ipAddressPools:
    - pool1
  peers:
    - peer1
  communities:
    - 65535:65282
  aggregationLength: 32
  aggregationLengthV6: 128
  localPref: 100

apiVersion: metallb.io/v1beta1
kind: BGPAdvertisement
metadata:
  name: bgpadvertisement-1
  namespace: metallb-system
spec:
  ipAddressPools:
    - pool1
  peers:
    - peer1
  communities:
    - 65535:65282
  aggregationLength: 32
  aggregationLengthV6: 128
  localPref: 100

Copy to Clipboard

Toggle word wrap

설정을 적용합니다.
```
oc apply -f bgpadvertisement1.yaml
```
```
$ oc apply -f bgpadvertisement1.yaml
```
Copy to Clipboard Toggle word wrap

BGP 광고 2를 생성합니다.

다음 예시와 같은 내용을 포함하는 bgpadvertisement2.yaml 과 같은 파일을 만듭니다.

apiVersion: metallb.io/v1beta1
kind: BGPAdvertisement
metadata:
  name: bgpadvertisement-2
  namespace: metallb-system
spec:
  ipAddressPools:
    - pool2
  peers:
    - peer2
  communities:
    - 65535:65282
  aggregationLength: 32
  aggregationLengthV6: 128
  localPref: 100

apiVersion: metallb.io/v1beta1
kind: BGPAdvertisement
metadata:
  name: bgpadvertisement-2
  namespace: metallb-system
spec:
  ipAddressPools:
    - pool2
  peers:
    - peer2
  communities:
    - 65535:65282
  aggregationLength: 32
  aggregationLengthV6: 128
  localPref: 100

Copy to Clipboard

Toggle word wrap

설정을 적용합니다.
```
oc apply -f bgpadvertisement2.yaml
```
```
$ oc apply -f bgpadvertisement2.yaml
```
Copy to Clipboard Toggle word wrap

4.3.4. 네트워크 VRF를 통한 서비스 노출
링크 복사

네트워크 인터페이스의 VRF를 BGP 피어와 연결하여 가상 라우팅 및 전달(VRF) 인스턴스를 통해 서비스를 노출할 수 있습니다.

중요

BGP 피어의 VRF를 통해 서비스를 노출하는 것은 기술 미리 보기 기능에 불과합니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

네트워크 인터페이스에서 VRF를 사용하여 BGP 피어를 통해 서비스를 노출하면 서비스에 대한 트래픽을 분리하고, 독립적인 라우팅 결정을 구성하고, 네트워크 인터페이스에서 다중 테넌시 지원을 활성화할 수 있습니다.

참고

네트워크 VRF에 속하는 인터페이스를 통해 BGP 세션을 설정함으로써 MetalLB는 해당 인터페이스를 통해 서비스를 광고하고 외부 트래픽이 이 인터페이스를 통해 서비스에 도달하도록 할 수 있습니다. 하지만 네트워크 VRF 라우팅 테이블은 OVN-Kubernetes에서 사용하는 기본 VRF 라우팅 테이블과 다릅니다. 따라서 트래픽이 OVN-Kubernetes 네트워크 인프라에 도달할 수 없습니다.

서비스로 전송되는 트래픽이 OVN-Kubernetes 네트워크 인프라에 도달할 수 있도록 하려면 네트워크 트래픽의 다음 홉을 정의하는 라우팅 규칙을 구성해야 합니다. 자세한 내용은 추가 리소스 섹션의 "MetalLB를 사용한 대칭 라우팅 관리"에서 NodeNetworkConfigurationPolicy 리소스를 참조하세요.

BGP 피어를 통해 네트워크 VRF를 통해 서비스를 노출하는 상위 단계는 다음과 같습니다.

BGP 피어를 정의하고 네트워크 VRF 인스턴스를 추가합니다.
MetalLB에 대한 IP 주소 풀을 지정합니다.
VRF 인스턴스와 연관된 BGP 피어와 지정된 IP 주소 풀을 사용하여 경로를 광고하도록 MetalLB에 대한 BGP 경로 광고를 구성합니다.
구성을 테스트하기 위해 서비스를 배포합니다.

사전 요구 사항

OpenShift CLI(oc)를 설치합니다.
cluster-admin 권한이 있는 사용자로 로그인했습니다.
가상 라우팅 및 포워딩(VRF) 인스턴스를 네트워크 인터페이스와 연결하기 위해 NodeNetworkConfigurationPolicy를 정의했습니다. 이 필수 조건을 완료하는 방법에 대한 자세한 내용은 추가 리소스 섹션을 참조하세요.
클러스터에 MetalLB를 설치했습니다.

프로세스

BGPPeer 사용자 정의 리소스(CR)를 만듭니다.
1. 다음 예시와 같은 내용을 포함하는 frrviavrf.yaml 과 같은 파일을 만듭니다.
  apiVersion: metallb.io/v1beta2 kind: BGPPeer metadata: name: frrviavrf namespace: metallb-system spec: myASN: 100 peerASN: 200 peerAddress: 192.168.130.1 vrf: ens4vrf
  1
  Copy to Clipboard Toggle word wrap
  1
  BGP 피어와 연결할 네트워크 VRF 인스턴스를 지정합니다. MetalLB는 VRF의 라우팅 정보를 기반으로 서비스를 광고하고 라우팅 결정을 내릴 수 있습니다.
  참고
  NodeNetworkConfigurationPolicy CR에서 이 네트워크 VRF 인스턴스를 구성해야 합니다. 자세한 내용은 추가 자료를 참조하세요.
2. 다음 명령을 실행하여 BGP 피어에 대한 구성을 적용합니다.
  $ oc apply -f frrviavrf.yaml
  Copy to Clipboard Toggle word wrap

IPAddressPool CR을 생성합니다.

다음 예시와 같은 내용을 담은 first-pool.yaml 과 같은 파일을 만듭니다.

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: first-pool
  namespace: metallb-system
spec:
  addresses:
  - 192.169.10.0/32

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: first-pool
  namespace: metallb-system
spec:
  addresses:
  - 192.169.10.0/32

Copy to Clipboard

Toggle word wrap

다음 명령을 실행하여 IP 주소 풀에 대한 구성을 적용합니다.
```
oc apply -f first-pool.yaml
```
```
$ oc apply -f first-pool.yaml
```
Copy to Clipboard Toggle word wrap

BGP광고 CR을 만드세요:

다음 예시와 같은 내용을 담은 first-adv.yaml 과 같은 파일을 만듭니다.

apiVersion: metallb.io/v1beta1
kind: BGPAdvertisement
metadata:
  name: first-adv
  namespace: metallb-system
spec:
  ipAddressPools:
    - first-pool
  peers:
    - frrviavrf

apiVersion: metallb.io/v1beta1
kind: BGPAdvertisement
metadata:
  name: first-adv
  namespace: metallb-system
spec:
  ipAddressPools:
    - first-pool
  peers:
    - frrviavrf

Copy to Clipboard

Toggle word wrap

1: 이 예에서 MetalLB는 첫 번째 풀 IP 주소 풀에서 frrviavrf BGP 피어로 IP 주소 범위를 광고합니다.

다음 명령을 실행하여 BGP 광고에 대한 구성을 적용합니다.
```
oc apply -f first-adv.yaml
```
```
$ oc apply -f first-adv.yaml
```
Copy to Clipboard Toggle word wrap

네임스페이스 , 배포 및 서비스 CR을 만듭니다.

다음 예시와 같은 내용을 포함하는 deploy-service.yaml 과 같은 파일을 만듭니다.

apiVersion: v1
kind: Namespace
metadata:
  name: test
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: server
  namespace: test
spec:
  selector:
    matchLabels:
      app: server
  template:
    metadata:
      labels:
        app: server
    spec:
      containers:
      - name: server
        image: registry.redhat.io/ubi9/ubi
        ports:
        - name: http
          containerPort: 30100
        command: ["/bin/sh", "-c"]
        args: ["sleep INF"]
---
apiVersion: v1
kind: Service
metadata:
  name: server1
  namespace: test
spec:
  ports:
  - name: http
    port: 30100
    protocol: TCP
    targetPort: 30100
  selector:
    app: server
  type: LoadBalancer

apiVersion: v1
kind: Namespace
metadata:
  name: test
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: server
  namespace: test
spec:
  selector:
    matchLabels:
      app: server
  template:
    metadata:
      labels:
        app: server
    spec:
      containers:
      - name: server
        image: registry.redhat.io/ubi9/ubi
        ports:
        - name: http
          containerPort: 30100
        command: ["/bin/sh", "-c"]
        args: ["sleep INF"]
---
apiVersion: v1
kind: Service
metadata:
  name: server1
  namespace: test
spec:
  ports:
  - name: http
    port: 30100
    protocol: TCP
    targetPort: 30100
  selector:
    app: server
  type: LoadBalancer

Copy to Clipboard

Toggle word wrap

다음 명령을 실행하여 네임스페이스, 배포 및 서비스에 대한 구성을 적용합니다.
```
oc apply -f deploy-service.yaml
```
```
$ oc apply -f deploy-service.yaml
```
Copy to Clipboard Toggle word wrap

검증

다음 명령을 실행하여 MetalLB 스피커 포드를 식별하세요.

oc get -n metallb-system pods -l component=speaker

$ oc get -n metallb-system pods -l component=speaker

Copy to Clipboard

Toggle word wrap

출력 예

NAME            READY   STATUS    RESTARTS   AGE
speaker-c6c5f   6/6     Running   0          69m

NAME            READY   STATUS    RESTARTS   AGE
speaker-c6c5f   6/6     Running   0          69m

Copy to Clipboard

Toggle word wrap

다음 명령을 실행하여 스피커 포드에서 BGP 세션 상태가 설정 되었는지 확인하고, 구성과 일치하도록 변수를 바꿉니다.

oc exec -n metallb-system <speaker_pod> -c frr -- vtysh -c "show bgp vrf <vrf_name> neigh"

$ oc exec -n metallb-system <speaker_pod> -c frr -- vtysh -c "show bgp vrf <vrf_name> neigh"

Copy to Clipboard

Toggle word wrap

출력 예

BGP neighbor is 192.168.30.1, remote AS 200, local AS 100, external link
  BGP version 4, remote router ID 192.168.30.1, local router ID 192.168.30.71
  BGP state = Established, up for 04:20:09

...

BGP neighbor is 192.168.30.1, remote AS 200, local AS 100, external link
  BGP version 4, remote router ID 192.168.30.1, local router ID 192.168.30.71
  BGP state = Established, up for 04:20:09

...

Copy to Clipboard

Toggle word wrap

다음 명령을 실행하여 서비스가 올바르게 광고되었는지 확인하세요.

oc exec -n metallb-system <speaker_pod> -c frr -- vtysh -c "show bgp vrf <vrf_name> ipv4"

$ oc exec -n metallb-system <speaker_pod> -c frr -- vtysh -c "show bgp vrf <vrf_name> ipv4"

Copy to Clipboard

Toggle word wrap

4.3.5. BGP 피어 구성 예
링크 복사

4.3.5.1. 예: BGP 피어에 연결하는 노드 제한
링크 복사

노드 선택기 필드를 지정하여 어떤 노드가 BGP 피어에 연결할 수 있는지 제어할 수 있습니다.

apiVersion: metallb.io/v1beta2
kind: BGPPeer
metadata:
  name: doc-example-nodesel
  namespace: metallb-system
spec:
  peerAddress: 10.0.20.1
  peerASN: 64501
  myASN: 64500
  nodeSelectors:
  - matchExpressions:
    - key: kubernetes.io/hostname
      operator: In
      values: [compute-1.example.com, compute-2.example.com]

apiVersion: metallb.io/v1beta2
kind: BGPPeer
metadata:
  name: doc-example-nodesel
  namespace: metallb-system
spec:
  peerAddress: 10.0.20.1
  peerASN: 64501
  myASN: 64500
  nodeSelectors:
  - matchExpressions:
    - key: kubernetes.io/hostname
      operator: In
      values: [compute-1.example.com, compute-2.example.com]

Copy to Clipboard

Toggle word wrap

4.3.5.2. 예: BGP 피어에 대한 BFD 프로필 지정
링크 복사

BGP 피어와 연결할 BFD 프로필을 지정할 수 있습니다. BFD는 BGP만 사용할 때보다 피어 간 통신 장애를 더 빠르게 감지하여 BGP를 보완합니다.

apiVersion: metallb.io/v1beta2
kind: BGPPeer
metadata:
  name: doc-example-peer-bfd
  namespace: metallb-system
spec:
  peerAddress: 10.0.20.1
  peerASN: 64501
  myASN: 64500
  holdTime: "10s"
  bfdProfile: doc-example-bfd-profile-full

apiVersion: metallb.io/v1beta2
kind: BGPPeer
metadata:
  name: doc-example-peer-bfd
  namespace: metallb-system
spec:
  peerAddress: 10.0.20.1
  peerASN: 64501
  myASN: 64500
  holdTime: "10s"
  bfdProfile: doc-example-bfd-profile-full

Copy to Clipboard

Toggle word wrap

참고

양방향 전달 감지(BFD) 프로필을 삭제하고 BGP(Border Gateway Protocol) 피어 리소스에 추가된 bfdProfile을 제거해도 BFD가 비활성화되지 않습니다. 대신 BGP 피어는 기본 BFD 프로필 사용을 시작합니다. BGP 피어 리소스에서 BFD를 비활성화하려면 BGP 피어 구성을 삭제하고 BFD 프로필없이 다시 생성합니다. 자세한 내용은 BZ#2050824를 참조하세요.

4.3.5.3. 예: 듀얼 스택 네트워킹을 위한 BGP 피어 지정
링크 복사

듀얼 스택 네트워킹을 지원하려면 IPv4에 대한 BGP 피어 사용자 정의 리소스 하나와 IPv6에 대한 BGP 피어 사용자 정의 리소스 하나를 추가합니다.

apiVersion: metallb.io/v1beta2
kind: BGPPeer
metadata:
  name: doc-example-dual-stack-ipv4
  namespace: metallb-system
spec:
  peerAddress: 10.0.20.1
  peerASN: 64500
  myASN: 64500
---
apiVersion: metallb.io/v1beta2
kind: BGPPeer
metadata:
  name: doc-example-dual-stack-ipv6
  namespace: metallb-system
spec:
  peerAddress: 2620:52:0:88::104
  peerASN: 64500
  myASN: 64500

apiVersion: metallb.io/v1beta2
kind: BGPPeer
metadata:
  name: doc-example-dual-stack-ipv4
  namespace: metallb-system
spec:
  peerAddress: 10.0.20.1
  peerASN: 64500
  myASN: 64500
---
apiVersion: metallb.io/v1beta2
kind: BGPPeer
metadata:
  name: doc-example-dual-stack-ipv6
  namespace: metallb-system
spec:
  peerAddress: 2620:52:0:88::104
  peerASN: 64500
  myASN: 64500

Copy to Clipboard

Toggle word wrap

4.3.5.4. 예: 번호가 지정되지 않은 BGP 피어링에 대한 BGP 피어 지정
링크 복사

중요

spec.interface 필드는 기술 미리보기 기능에 불과합니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

번호가 지정되지 않은 BGP 피어링을 구성하려면 다음 예제 구성을 사용하여 spec.interface 필드에 인터페이스를 지정합니다.

apiVersion: metallb.io/v1beta2
kind: BGPPeer
metadata:
  name: peer-unnumber
  namespace: metallb-system
spec:
  myASN: 64512
  ASN: 645000
  interface: net0

apiVersion: metallb.io/v1beta2
kind: BGPPeer
metadata:
  name: peer-unnumber
  namespace: metallb-system
spec:
  myASN: 64512
  ASN: 645000
  interface: net0

Copy to Clipboard

Toggle word wrap

참고

인터페이스 필드를 사용하려면 두 BGP 피어 간에 지점 간, 계층 2 연결을 설정해야 합니다. IPv4, IPv6 또는 듀얼 스택에서 번호가 지정되지 않은 BGP 피어링을 사용할 수 있지만 IPv6 RA(라우터 광고)를 활성화해야 합니다. 각 인터페이스는 하나의 BGP 연결로 제한됩니다.

이 필드를 사용하면 spec.bgp.routers.neighbors.address 필드에 값을 지정할 수 없습니다.

4.3.6. 다음 단계
링크 복사

MetalLB를 사용하도록 서비스 구성

4.4. 커뮤니티 별칭 구성
링크 복사

클러스터 관리자는 커뮤니티 별칭을 구성하여 다양한 광고에 사용할 수 있습니다.

4.4.1. 커뮤니티 사용자 정의 리소스에 관하여
링크 복사

커뮤니티 사용자 정의 리소스는 커뮤니티에 대한 별칭의 모음입니다. 사용자는 BGPAdvertisement를 사용하여 ipAddressPools를 광고할 때 사용할 명명된 별칭을 정의할 수 있습니다. 다음 표에서는 커뮤니티 사용자 정의 리소스의 필드에 대해 설명합니다.

참고

커뮤니티 CRD는 BGPAdvertisement에만 적용됩니다.

Expand

표 4.6. MetalLB 커뮤니티 사용자 정의 리소스
필드	유형	설명
`metadata.name`	`string`	`커뮤니티` 의 이름을 지정합니다.
`metadata.namespace`	`string`	`커뮤니티` 의 네임스페이스를 지정합니다. MetalLB Operator에서 사용하는 동일한 네임스페이스를 지정합니다.
`spec.communities`	`string`	BGPAdvertisements에서 사용할 수 있는 BGP 커뮤니티 별칭 목록을 지정합니다. 커뮤니티 별칭은 이름(별칭)과 값(숫자:숫자)의 쌍으로 구성됩니다. `spec.communities` 필드에서 별칭 이름을 참조하여 BGPAdvertisement를 커뮤니티 별칭에 연결합니다.

Expand

표 4.7. CommunityAlias
필드	유형	설명
`name`	`string`	`커뮤니티` 의 별칭 이름입니다.
`value`	`string`	지정된 이름에 해당하는 BGP `커뮤니티` 값입니다.

4.4.2. BGP 광고 및 커뮤니티 별칭을 사용하여 MetalLB 구성
링크 복사

IPAddressPool 이 BGP 프로토콜로 광고되고 커뮤니티 별칭이 NO_ADVERTISE 커뮤니티의 숫자 값으로 설정되도록 MetalLB를 다음과 같이 구성합니다.

다음 예에서 피어 BGP 라우터 doc-example-peer-community는 MetalLB가 서비스에 할당한 각 로드 밸런서 IP 주소에 대해 하나의 203.0.113.200/32 경로와 하나의 fc00:f853:ccd:e799::1/128 경로를 수신합니다. 커뮤니티 별칭은 NO_ADVERTISE 커뮤니티로 구성됩니다.

사전 요구 사항

OpenShift CLI(oc)를 설치합니다.
cluster-admin 권한이 있는 사용자로 로그인합니다.

프로세스

IP 주소 풀을 생성합니다.

다음 예시와 같은 내용을 담은 ipaddresspool.yaml 과 같은 파일을 만듭니다.

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  namespace: metallb-system
  name: doc-example-bgp-community
spec:
  addresses:
    - 203.0.113.200/30
    - fc00:f853:ccd:e799::/124

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  namespace: metallb-system
  name: doc-example-bgp-community
spec:
  addresses:
    - 203.0.113.200/30
    - fc00:f853:ccd:e799::/124

Copy to Clipboard

Toggle word wrap

IP 주소 풀에 대한 구성을 적용합니다.
```
oc apply -f ipaddresspool.yaml
```
```
$ oc apply -f ipaddresspool.yaml
```
Copy to Clipboard Toggle word wrap

community1 이라는 이름의 커뮤니티 별칭을 만듭니다.

apiVersion: metallb.io/v1beta1
kind: Community
metadata:
  name: community1
  namespace: metallb-system
spec:
  communities:
    - name: NO_ADVERTISE
      value: '65535:65282'

apiVersion: metallb.io/v1beta1
kind: Community
metadata:
  name: community1
  namespace: metallb-system
spec:
  communities:
    - name: NO_ADVERTISE
      value: '65535:65282'

Copy to Clipboard

Toggle word wrap

doc-example-bgp-peer 라는 이름의 BGP 피어를 만듭니다.

다음 예시와 같은 내용을 담은 bgppeer.yaml 과 같은 파일을 만듭니다.

apiVersion: metallb.io/v1beta2
kind: BGPPeer
metadata:
  namespace: metallb-system
  name: doc-example-bgp-peer
spec:
  peerAddress: 10.0.0.1
  peerASN: 64501
  myASN: 64500
  routerID: 10.10.10.10

apiVersion: metallb.io/v1beta2
kind: BGPPeer
metadata:
  namespace: metallb-system
  name: doc-example-bgp-peer
spec:
  peerAddress: 10.0.0.1
  peerASN: 64501
  myASN: 64500
  routerID: 10.10.10.10

Copy to Clipboard

Toggle word wrap

BGP 피어에 대한 구성을 적용합니다.
```
oc apply -f bgppeer.yaml
```
```
$ oc apply -f bgppeer.yaml
```
Copy to Clipboard Toggle word wrap

커뮤니티 별칭으로 BGP 광고를 만듭니다.

다음 예시와 같은 내용을 담은 bgpadvertisement.yaml 과 같은 파일을 만듭니다.

apiVersion: metallb.io/v1beta1
kind: BGPAdvertisement
metadata:
  name: bgp-community-sample
  namespace: metallb-system
spec:
  aggregationLength: 32
  aggregationLengthV6: 128
  communities:
    - NO_ADVERTISE 
  ipAddressPools:
    - doc-example-bgp-community
  peers:
    - doc-example-peer

apiVersion: metallb.io/v1beta1
kind: BGPAdvertisement
metadata:
  name: bgp-community-sample
  namespace: metallb-system
spec:
  aggregationLength: 32
  aggregationLengthV6: 128
  communities:
    - NO_ADVERTISE


  ipAddressPools:
    - doc-example-bgp-community
  peers:
    - doc-example-peer

Copy to Clipboard

Toggle word wrap

1: 여기에는 커뮤니티 사용자 정의 리소스(CR) 이름이 아닌 CommunityAlias.name 을 지정하세요.

설정을 적용합니다.
```
oc apply -f bgpadvertisement.yaml
```
```
$ oc apply -f bgpadvertisement.yaml
```
Copy to Clipboard Toggle word wrap

4.5. MetalLB BFD 프로필 구성
링크 복사

클러스터 관리자는 양방향 전달 감지(BFD) 프로필을 추가, 수정, 삭제할 수 있습니다. MetalLB Operator는 BFD 프로필 사용자 정의 리소스를 사용하여 어떤 BGP 세션이 BFD를 사용하여 BGP만으로 제공하는 것보다 더 빠른 경로 오류 감지를 제공하는지 식별합니다.

4.5.1. BFD 프로필 사용자 정의 리소스에 관하여
링크 복사

다음 표에서는 BFD 프로필 사용자 정의 리소스에 대한 필드에 대해 설명합니다.

Expand

표 4.8. BFD 프로필 사용자 정의 리소스
필드	유형	설명
`metadata.name`	`string`	BFD 프로필 사용자 정의 리소스의 이름을 지정합니다.
`metadata.namespace`	`string`	BFD 프로필 사용자 정의 리소스에 대한 네임스페이스를 지정합니다.
`spec.detectMultiplier`	`integer`	패킷 손실을 판별하기 위한 감지 배수를 지정합니다. 원격 전송 간격에 이 값을 곱하여 연결 손실 감지 타이머를 결정합니다. 예를 들어, 로컬 시스템의 감지 배수가 `3` 으로 설정되어 있고 원격 시스템의 전송 간격이 `300` 으로 설정되어 있는 경우 로컬 시스템은 패킷을 수신하지 못한 채 `900ms` 가 지난 후에야 장애를 감지합니다. 범위는 `2` ~ `255` 입니다. 기본값은 `3`입니다.
`spec.echoMode`	`boolean`	에코 전송 모드를 지정합니다. 분산 BFD를 사용하지 않는 경우 에코 전송 모드는 피어가 FRR인 경우에만 작동합니다. 기본값은 `false` 이고 에코 전송 모드는 비활성화됩니다. 에코 전송 모드가 활성화된 경우 대역폭 사용량을 줄이기 위해 제어 패킷의 전송 간격을 늘리는 것을 고려하세요. 예를 들어, 전송 간격을 `2000ms` 로 늘리는 것을 고려해 보세요.
`spec.echoInterval`	`integer`	이 시스템이 에코 패킷을 보내고 받는 데 사용하는 최소 전송 간격(지터 제외)을 지정합니다. 범위는 `10` ~ `60000` 입니다. 기본값은 `50ms` 입니다.
`spec.minimumTtl`	`integer`	수신 제어 패킷에 대한 최소 예상 TTL을 지정합니다. 이 필드는 멀티홉 세션에만 적용됩니다. 최소 TTL을 설정하는 목적은 패킷 검증 요구 사항을 더욱 엄격하게 만들고 다른 세션에서 제어 패킷을 수신하지 않도록 하는 것입니다. 기본값은 `254` 이며, 이는 시스템이 이 시스템과 피어 사이에 단 하나의 홉만 예상함을 나타냅니다.
`spec.passiveMode`	`boolean`	세션이 활성인지 수동인지 여부를 지정합니다. 수동 세션은 연결을 시작하려고 시도하지 않습니다. 대신, 수동 세션은 응답을 시작하기 전에 피어로부터 제어 패킷을 기다립니다. 스타 네트워크의 중앙 노드 역할을 하는 라우터가 있고 시스템에서 보낼 필요가 없는 제어 패킷을 보내는 것을 방지하려는 경우 세션을 수동으로 표시하는 것이 유용합니다. 기본값은 `false` 이며 세션을 활성 상태로 표시합니다.
`spec.receiveInterval`	`integer`	이 시스템이 제어 패킷을 수신할 수 있는 최소 간격을 지정합니다. 범위는 `10` ~ `60000` 입니다. 기본값은 `300ms` 입니다.
`spec.transmitInterval`	`integer`	이 시스템이 제어 패킷을 보내는 데 사용하는 최소 전송 간격(지터 제외)을 지정합니다. 범위는 `10` ~ `60000` 입니다. 기본값은 `300ms` 입니다.

4.5.2. BFD 프로필 구성
링크 복사

클러스터 관리자는 BFD 프로필을 추가하고 BGP 피어가 해당 프로필을 사용하도록 구성할 수 있습니다. BFD는 BGP만 사용할 때보다 경로 장애 감지 속도가 더 빠릅니다.

사전 요구 사항

OpenShift CLI(oc)를 설치합니다.
cluster-admin 권한이 있는 사용자로 로그인합니다.

프로세스

다음 예시와 같은 내용을 담은 bfdprofile.yaml 과 같은 파일을 만듭니다.

apiVersion: metallb.io/v1beta1
kind: BFDProfile
metadata:
  name: doc-example-bfd-profile-full
  namespace: metallb-system
spec:
  receiveInterval: 300
  transmitInterval: 300
  detectMultiplier: 3
  echoMode: false
  passiveMode: true
  minimumTtl: 254

apiVersion: metallb.io/v1beta1
kind: BFDProfile
metadata:
  name: doc-example-bfd-profile-full
  namespace: metallb-system
spec:
  receiveInterval: 300
  transmitInterval: 300
  detectMultiplier: 3
  echoMode: false
  passiveMode: true
  minimumTtl: 254

Copy to Clipboard

Toggle word wrap

BFD 프로필에 대한 구성을 적용합니다.
```
oc apply -f bfdprofile.yaml
```
```
$ oc apply -f bfdprofile.yaml
```
Copy to Clipboard Toggle word wrap

4.5.3. 다음 단계
링크 복사

BFD 프로필을 사용하도록 BGP 피어를 구성합니다 .

4.6. MetalLB를 사용하도록 서비스 구성
링크 복사

클러스터 관리자는 LoadBalancer 유형의 서비스를 추가할 때 MetalLB에서 IP 주소를 할당하는 방법을 제어할 수 있습니다.

4.6.1. 특정 IP 주소 요청
링크 복사

다른 로드 밸런서 구현과 마찬가지로 MetalLB에는 서비스 사양에서 spec.loadBalancerIP 필드가 허용됩니다.

요청된 IP 주소가 주소 풀의 범위 내에 있는 경우 MetalLB는 요청된 IP 주소를 할당합니다. 요청된 IP 주소가 범위 내에 없는 경우 MetalLB에서 경고를 보고합니다.

특정 IP 주소에 대한 서비스 YAML의 예

apiVersion: v1
kind: Service
metadata:
  name: <service_name>
  annotations:
    metallb.io/address-pool: <address_pool_name>
spec:
  selector:
    <label_key>: <label_value>
  ports:
    - port: 8080
      targetPort: 8080
      protocol: TCP
  type: LoadBalancer
  loadBalancerIP: <ip_address>

apiVersion: v1
kind: Service
metadata:
  name: <service_name>
  annotations:
    metallb.io/address-pool: <address_pool_name>
spec:
  selector:
    <label_key>: <label_value>
  ports:
    - port: 8080
      targetPort: 8080
      protocol: TCP
  type: LoadBalancer
  loadBalancerIP: <ip_address>

Copy to Clipboard

Toggle word wrap

MetalLB에서 요청된 IP 주소를 할당할 수 없는 경우 서비스의 EXTERNAL-IP는 <pending>을 보고하고 oc describe service <service_name>을 실행하면 다음 예와 같은 이벤트가 포함됩니다.

MetalLB에서 요청된 IP 주소를 할당할 수 없는 이벤트의 예

  ...
Events:
  Type     Reason            Age    From                Message
  ----     ------            ----   ----                -------
  Warning  AllocationFailed  3m16s  metallb-controller  Failed to allocate IP for "default/invalid-request": "4.3.2.1" is not allowed in config

  ...
Events:
  Type     Reason            Age    From                Message
  ----     ------            ----   ----                -------
  Warning  AllocationFailed  3m16s  metallb-controller  Failed to allocate IP for "default/invalid-request": "4.3.2.1" is not allowed in config

Copy to Clipboard

Toggle word wrap

4.6.2. 특정 풀에서 IP 주소 요청
링크 복사

특정 범위의 IP 주소를 할당하지만 구체적인 IP 주소가 필요하지 않다면 metallb.io/address-pool 주석을 사용하여 지정된 주소 풀에서 IP 주소를 요청할 수 있습니다.

특정 풀의 IP 주소에 대한 서비스 YAML의 예

apiVersion: v1
kind: Service
metadata:
  name: <service_name>
  annotations:
    metallb.io/address-pool: <address_pool_name>
spec:
  selector:
    <label_key>: <label_value>
  ports:
    - port: 8080
      targetPort: 8080
      protocol: TCP
  type: LoadBalancer

apiVersion: v1
kind: Service
metadata:
  name: <service_name>
  annotations:
    metallb.io/address-pool: <address_pool_name>
spec:
  selector:
    <label_key>: <label_value>
  ports:
    - port: 8080
      targetPort: 8080
      protocol: TCP
  type: LoadBalancer

Copy to Clipboard

Toggle word wrap

<address_pool_name>에 대해 지정한 주소 풀이 없는 경우 MetalLB는 자동 할당을 허용하는 모든 풀에서 IP 주소를 할당하려고 시도합니다.

4.6.3. IP 주소 수락
링크 복사

기본적으로 주소 풀은 자동 할당을 허용하도록 구성됩니다. MetalLB는 이러한 주소 풀에서 IP 주소를 할당합니다.

자동 할당을 위해 구성된 풀의 IP 주소를 수락하려면 특별한 주석이나 구성이 필요하지 않습니다.

IP 주소를 수락하는 서비스 YAML의 예

apiVersion: v1
kind: Service
metadata:
  name: <service_name>
spec:
  selector:
    <label_key>: <label_value>
  ports:
    - port: 8080
      targetPort: 8080
      protocol: TCP
  type: LoadBalancer

apiVersion: v1
kind: Service
metadata:
  name: <service_name>
spec:
  selector:
    <label_key>: <label_value>
  ports:
    - port: 8080
      targetPort: 8080
      protocol: TCP
  type: LoadBalancer

Copy to Clipboard

Toggle word wrap

4.6.4. 특정 IP 주소 공유
링크 복사

기본적으로 서비스는 IP 주소를 공유하지 않습니다. 하지만 단일 IP 주소에 서비스를 함께 배치해야 하는 경우 서비스에 metallb.io/allow-shared-ip 주석을 추가하여 선택적 IP 공유를 활성화할 수 있습니다.

apiVersion: v1
kind: Service
metadata:
  name: service-http
  annotations:
    metallb.io/address-pool: doc-example
    metallb.io/allow-shared-ip: "web-server-svc"  
spec:
  ports:
    - name: http
      port: 80  
      protocol: TCP
      targetPort: 8080
  selector:
    <label_key>: <label_value>  
  type: LoadBalancer
  loadBalancerIP: 172.31.249.7  
---
apiVersion: v1
kind: Service
metadata:
  name: service-https
  annotations:
    metallb.io/address-pool: doc-example
    metallb.io/allow-shared-ip: "web-server-svc"
spec:
  ports:
    - name: https
      port: 443
      protocol: TCP
      targetPort: 8080
  selector:
    <label_key>: <label_value>
  type: LoadBalancer
  loadBalancerIP: 172.31.249.7

apiVersion: v1
kind: Service
metadata:
  name: service-http
  annotations:
    metallb.io/address-pool: doc-example
    metallb.io/allow-shared-ip: "web-server-svc"


spec:
  ports:
    - name: http
      port: 80


      protocol: TCP
      targetPort: 8080
  selector:
    <label_key>: <label_value>


  type: LoadBalancer
  loadBalancerIP: 172.31.249.7


---
apiVersion: v1
kind: Service
metadata:
  name: service-https
  annotations:
    metallb.io/address-pool: doc-example
    metallb.io/allow-shared-ip: "web-server-svc"
spec:
  ports:
    - name: https
      port: 443
      protocol: TCP
      targetPort: 8080
  selector:
    <label_key>: <label_value>
  type: LoadBalancer
  loadBalancerIP: 172.31.249.7

Copy to Clipboard

Toggle word wrap

1: metallb.io/allow-shared-ip 주석에 동일한 값을 지정합니다. 이 값을 공유 키라고 합니다.
2: 서비스에 대해 서로 다른 포트 번호를 지정합니다.
3: 서비스가 동일한 Pod 세트로 트래픽을 보내도록 externalTrafficPolicy: local을 지정해야 하는 경우 동일한 Pod 선택기를 지정합니다. cluster 외부 트래픽 정책을 사용하는 경우 Pod 선택기를 동일할 필요가 없습니다.
4: 선택 사항: 이전 항목 3개를 지정하는 경우 MetalLB에서 서비스를 동일한 IP 주소에 배치할 수 있습니다. 서비스가 IP 주소를 공유하도록 하려면 공유할 IP 주소를 지정합니다.

기본적으로 Kubernetes는 다중 프로토콜 로드 밸런서 서비스를 허용하지 않습니다. 이 제한으로 인해 일반적으로 TCP 및 UDP에서 수신 대기해야 하는 DNS와 같은 서비스를 실행할 수 없습니다. MetalLB를 사용하여 이 Kubernetes 제한 사항을 해결하려면 다음 두 서비스를 생성합니다.

한 서비스에 대해 TCP를 지정하고 두 번째 서비스에 대해 UDP를 지정합니다.
두 서비스 모두에서 동일한 pod 선택기를 지정합니다.
동일한 공유 키와 spec.loadBalancerIP 값을 지정하여 TCP 및 UDP 서비스를 동일한 IP 주소에 공동 배치합니다.

4.6.5. MetalLB를 사용하여 서비스 구성
링크 복사

주소 풀에서 외부 IP 주소를 사용하도록 로드 밸런싱 서비스를 구성할 수 있습니다.

사전 요구 사항

OpenShift CLI(oc)를 설치합니다.
MetalLB Operator를 설치하고 MetalLB를 시작합니다.
하나 이상의 주소 풀을 구성합니다.
클라이언트의 트래픽을 클러스터의 호스트 네트워크로 라우팅하도록 네트워크를 구성합니다.

프로세스

<service_name>.yaml 파일을 생성합니다. 파일에서 spec.type 필드가 LoadBalancer로 설정되어 있는지 확인합니다.
MetalLB에서 서비스에 할당하는 외부 IP 주소를 요청하는 방법에 대한 자세한 내용은 예제를 참조하십시오.
서비스를 생성합니다.
```
oc apply -f <service_name>.yaml
```
```
$ oc apply -f <service_name>.yaml
```
Copy to Clipboard Toggle word wrap
출력 예
```
service/<service_name> created
```
```
service/<service_name> created
```
Copy to Clipboard Toggle word wrap

검증

서비스를 설명합니다.

oc describe service <service_name>

$ oc describe service <service_name>

Copy to Clipboard

Toggle word wrap

출력 예

Name:                     <service_name>
Namespace:                default
Labels:                   <none>
Annotations:              metallb.io/address-pool: doc-example  
Selector:                 app=service_name
Type:                     LoadBalancer  
IP Family Policy:         SingleStack
IP Families:              IPv4
IP:                       10.105.237.254
IPs:                      10.105.237.254
LoadBalancer Ingress:     192.168.100.5  
Port:                     <unset>  80/TCP
TargetPort:               8080/TCP
NodePort:                 <unset>  30550/TCP
Endpoints:                10.244.0.50:8080
Session Affinity:         None
External Traffic Policy:  Cluster
Events:  
  Type    Reason        Age                From             Message
  ----    ------        ----               ----             -------
  Normal  nodeAssigned  32m (x2 over 32m)  metallb-speaker  announcing from node "<node_name>"

Name:                     <service_name>
Namespace:                default
Labels:                   <none>
Annotations:              metallb.io/address-pool: doc-example


Selector:                 app=service_name
Type:                     LoadBalancer


IP Family Policy:         SingleStack
IP Families:              IPv4
IP:                       10.105.237.254
IPs:                      10.105.237.254
LoadBalancer Ingress:     192.168.100.5


Port:                     <unset>  80/TCP
TargetPort:               8080/TCP
NodePort:                 <unset>  30550/TCP
Endpoints:                10.244.0.50:8080
Session Affinity:         None
External Traffic Policy:  Cluster
Events:


  Type    Reason        Age                From             Message
  ----    ------        ----               ----             -------
  Normal  nodeAssigned  32m (x2 over 32m)  metallb-speaker  announcing from node "<node_name>"

Copy to Clipboard

Toggle word wrap

1: 특정 풀에서 IP 주소를 요청하면 주석이 표시됩니다.
2: 서비스 유형에 LoadBalancer가 표시되어야 합니다.
3: 서비스가 올바르게 할당된 경우 부하 분산기 ingress 필드는 외부 IP 주소를 나타냅니다.
4: events 필드는 외부 IP 주소를 알리기 위해 할당된 노드 이름을 나타냅니다. 오류가 발생하면 이벤트 필드에 오류 이유가 표시됩니다.

4.7. MetalLB를 사용한 대칭 라우팅 관리
링크 복사

클러스터 관리자는 MetalLB, NMState, OVN-Kubernetes의 기능을 구현하여 여러 호스트 인터페이스가 있는 MetalLB 로드 밸런서 서비스 뒤에 있는 포드의 트래픽을 효과적으로 관리할 수 있습니다. 이 컨텍스트에서 이러한 기능을 결합하면 대칭 라우팅, 트래픽 분리를 제공하고 CIDR 주소가 겹치는 서로 다른 네트워크의 클라이언트를 지원할 수 있습니다.

이 기능을 구현하려면 MetalLB를 사용하여 가상 라우팅 및 전달(VRF) 인스턴스를 구현하고 송신 서비스를 구성하는 방법을 알아보세요.

중요

MetalLB와 송신 서비스를 사용하여 VRF 인스턴스를 사용하여 대칭 트래픽을 구성하는 것은 기술 미리 보기 기능에 불과합니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

4.7.1. MetalLB를 사용한 대칭 라우팅 관리의 과제
링크 복사

여러 호스트 인터페이스와 함께 MetalLB를 사용하면 MetalLB는 호스트에서 사용 가능한 모든 인터페이스를 통해 서비스를 노출하고 알립니다. 이는 네트워크 격리, 비대칭적 반환 트래픽 및 중복되는 CIDR 주소와 관련된 문제를 야기할 수 있습니다.

반환 트래픽이 올바른 클라이언트에 도달하도록 보장하는 한 가지 옵션은 정적 경로를 사용하는 것입니다. 하지만 이 솔루션을 사용하면 MetalLB는 서비스를 분리한 다음 각 서비스를 다른 인터페이스를 통해 알릴 수 없습니다. 또한 정적 라우팅에는 수동 구성이 필요하고 원격 사이트를 추가하는 경우 유지 관리가 필요합니다.

MetalLB 서비스를 구현할 때 대칭 라우팅의 또 다른 과제는 외부 시스템이 애플리케이션의 소스 및 대상 IP 주소가 동일할 것으로 예상하는 시나리오입니다. OpenShift Container Platform의 기본 동작은 Pod에서 발생하는 트래픽에 대한 소스 IP 주소로 호스트 네트워크 인터페이스의 IP 주소를 할당하는 것입니다. 이는 호스트 인터페이스가 여러 개인 경우 문제가 됩니다.

MetalLB, NMState, OVN-Kubernetes의 기능을 결합한 구성을 구현하면 이러한 과제를 극복할 수 있습니다.

4.7.2. MetalLB를 사용하여 VRF를 사용한 대칭 라우팅 관리 개요
링크 복사

NMState를 사용하여 호스트에서 VRF 인스턴스를 구성하고, VRF 인스턴스를 MetalLB BGPPeer 리소스와 연결하고, OVN-Kubernetes를 사용하여 송신 트래픽에 대한 송신 서비스를 구성하면 대칭 라우팅 구현의 과제를 극복할 수 있습니다.

그림 4.1. MetalLB를 사용하여 VRF를 사용하여 대칭 라우팅을 관리하는 네트워크 개요

구성 프로세스는 세 단계로 구성됩니다.

1. VRF 및 라우팅 규칙 정의

VRF 인스턴스를 네트워크 인터페이스와 연결하기 위해 NodeNetworkConfigurationPolicy 사용자 정의 리소스(CR)를 구성합니다.
VRF 라우팅 테이블을 사용하여 유입 및 유출 트래픽을 지시합니다.

2. VRF를 MetalLB BGPPeer 에 연결

네트워크 인터페이스에서 VRF 인스턴스를 사용하도록 MetalLB BGPPeer 리소스를 구성합니다.
BGPPeer 리소스를 VRF 인스턴스와 연결하면 지정된 네트워크 인터페이스가 BGP 세션의 기본 인터페이스가 되고 MetalLB는 이 인터페이스를 통해 서비스를 광고합니다.

3. 이그레스 서비스 구성

VRF 인스턴스와 연결된 네트워크를 송신 트래픽에 사용하도록 송신 서비스를 구성합니다.
선택 사항: MetalLB 부하 분산 서비스의 IP 주소를 송신 트래픽의 소스 IP로 사용하도록 송신 서비스를 구성합니다.

4.7.3. MetalLB를 사용하여 VRF를 사용하여 대칭 라우팅 구성
링크 복사

동일한 수신 및 송신 네트워크 경로가 필요한 MetalLB 서비스 뒤의 애플리케이션에 대해 대칭 네트워크 라우팅을 구성할 수 있습니다.

이 예제에서는 VRF 라우팅 테이블을 MetalLB와 송신 서비스에 연결하여 LoadBalancer 서비스 뒤에 있는 포드의 수신 및 송신 트래픽에 대한 대칭 라우팅을 활성화합니다.

중요

EgressService CR에서 sourceIPBy: "LoadBalancerIP" 설정을 사용하는 경우 BGPAdvertisement 사용자 정의 리소스(CR)에서 로드 밸런서 노드를 지정해야 합니다.
OVN-Kubernetes를 사용하고 gatewayConfig.routingViaHost 사양을 true 로 설정한 클러스터에서만 sourceIPBy: "Network" 설정을 사용할 수 있습니다. 또한, sourceIPBy: "Network" 설정을 사용하는 경우 네트워크 VRF 인스턴스로 구성된 노드에서 애플리케이션 작업 부하를 예약해야 합니다.

사전 요구 사항

OpenShift CLI(oc)를 설치합니다.
cluster-admin 권한이 있는 사용자로 로그인합니다.
Kubernetes NMState Operator를 설치합니다.
MetalLB Operator를 설치합니다.

프로세스

VRF 인스턴스를 정의하려면 NodeNetworkConfigurationPolicy CR을 만듭니다.

다음 예시와 같은 내용을 포함하는 node-network-vrf.yaml 과 같은 파일을 만듭니다.

apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
  name: vrfpolicy 
spec:
  nodeSelector:
    vrf: "true" 
  maxUnavailable: 3
  desiredState:
    interfaces:
    - name: ens4vrf 
      type: vrf 
      state: up
      vrf:
        port:
        - ens4 
        route-table-id: 2 
    - name: ens4 
      type: ethernet
      state: up
      ipv4:
        address:
        - ip: 192.168.130.130
          prefix-length: 24
        dhcp: false
        enabled: true
    routes: 
      config:
      - destination: 0.0.0.0/0
        metric: 150
        next-hop-address: 192.168.130.1
        next-hop-interface: ens4
        table-id: 2
    route-rules: 
      config:
      - ip-to: 172.30.0.0/16
        priority: 998
        route-table: 254 
      - ip-to: 10.132.0.0/14
        priority: 998
        route-table: 254
      - ip-to: 169.254.0.0/17
        priority: 998
        route-table: 254

apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
  name: vrfpolicy


spec:
  nodeSelector:
    vrf: "true"


  maxUnavailable: 3
  desiredState:
    interfaces:
    - name: ens4vrf


      type: vrf


      state: up
      vrf:
        port:
        - ens4


        route-table-id: 2


    - name: ens4


      type: ethernet
      state: up
      ipv4:
        address:
        - ip: 192.168.130.130
          prefix-length: 24
        dhcp: false
        enabled: true
    routes:


      config:
      - destination: 0.0.0.0/0
        metric: 150
        next-hop-address: 192.168.130.1
        next-hop-interface: ens4
        table-id: 2
    route-rules:


      config:
      - ip-to: 172.30.0.0/16
        priority: 998
        route-table: 254


      - ip-to: 10.132.0.0/14
        priority: 998
        route-table: 254
      - ip-to: 169.254.0.0/17
        priority: 998
        route-table: 254

Copy to Clipboard

Toggle word wrap

1: 정책의 이름입니다.
2: 이 예제에서는 vrf:true 레이블이 있는 모든 노드에 정책을 적용합니다.
3: 인터페이스의 이름.
4: 인터페이스 유형입니다. 이 예제에서는 VRF 인스턴스를 생성합니다.
5: VRF가 연결되는 노드 인터페이스입니다.
6: VRF에 대한 경로 테이블 ID의 이름입니다.
7: VRF와 연관된 인터페이스의 IPv4 주소입니다.
8: 네트워크 경로에 대한 구성을 정의합니다. 다음 홉 주소 필드는 경로의 다음 홉의 IP 주소를 정의합니다. 다음 홉 인터페이스 필드는 경로에 대한 나가는 인터페이스를 정의합니다. 이 예에서 VRF 라우팅 테이블은 2 이며, 이는 EgressService CR에서 정의한 ID를 참조합니다.
9: 추가 경로 규칙을 정의합니다. ip-to 필드는 클러스터 네트워크 CIDR, 서비스 네트워크 CIDR 및 내부 마스커레이드 서브넷 CIDR과 일치해야 합니다. 다음 명령을 실행하면 이러한 CIDR 주소 사양에 대한 값을 볼 수 있습니다: oc describe network.operator/cluster .
10: Linux 커널이 경로를 계산할 때 사용하는 주요 라우팅 테이블의 ID는 254 입니다.

다음 명령을 실행하여 정책을 적용합니다.
```
oc apply -f node-network-vrf.yaml
```
```
$ oc apply -f node-network-vrf.yaml
```
Copy to Clipboard Toggle word wrap

BGPPeer 사용자 정의 리소스(CR)를 만듭니다.
1. 다음 예시와 같은 내용을 포함하는 frr-via-vrf.yaml 과 같은 파일을 만듭니다.
  apiVersion: metallb.io/v1beta2 kind: BGPPeer metadata: name: frrviavrf namespace: metallb-system spec: myASN: 100 peerASN: 200 peerAddress: 192.168.130.1 vrf: ens4vrf
  1
  Copy to Clipboard Toggle word wrap
  1
  BGP 피어와 연결할 VRF 인스턴스를 지정합니다. MetalLB는 VRF의 라우팅 정보를 기반으로 서비스를 광고하고 라우팅 결정을 내릴 수 있습니다.
2. 다음 명령을 실행하여 BGP 피어에 대한 구성을 적용합니다.
  $ oc apply -f frr-via-vrf.yaml
  Copy to Clipboard Toggle word wrap

IPAddressPool CR을 생성합니다.

다음 예시와 같은 내용을 담은 first-pool.yaml 과 같은 파일을 만듭니다.

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: first-pool
  namespace: metallb-system
spec:
  addresses:
  - 192.169.10.0/32

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: first-pool
  namespace: metallb-system
spec:
  addresses:
  - 192.169.10.0/32

Copy to Clipboard

Toggle word wrap

다음 명령을 실행하여 IP 주소 풀에 대한 구성을 적용합니다.
```
oc apply -f first-pool.yaml
```
```
$ oc apply -f first-pool.yaml
```
Copy to Clipboard Toggle word wrap

BGP광고 CR을 만드세요:
1. 다음 예시와 같은 내용을 담은 first-adv.yaml 과 같은 파일을 만듭니다.
  apiVersion: metallb.io/v1beta1 kind: BGPAdvertisement metadata: name: first-adv namespace: metallb-system spec: ipAddressPools: - first-pool peers: - frrviavrf
  1
  nodeSelectors: - matchLabels: egress-service.k8s.ovn.org/test-server1: ""
  2
  Copy to Clipboard Toggle word wrap
  1
  이 예에서 MetalLB는 첫 번째 풀 IP 주소 풀에서 frrviavrf BGP 피어로 IP 주소 범위를 광고합니다.
  2
  이 예에서 EgressService CR은 부하 분산 장치 서비스 IP 주소를 사용하도록 송신 트래픽의 소스 IP 주소를 구성합니다. 따라서 포드에서 발생한 트래픽에 대해 동일한 반환 경로를 사용하도록 반환 트래픽에 대한 로드 밸런서 노드를 지정해야 합니다.
2. 다음 명령을 실행하여 BGP 광고에 대한 구성을 적용합니다.
  $ oc apply -f first-adv.yaml
  Copy to Clipboard Toggle word wrap
EgressService CR을 만듭니다.
1. 다음 예시와 같은 내용을 포함하는 egress-service.yaml 과 같은 파일을 만듭니다.
  apiVersion: k8s.ovn.org/v1 kind: EgressService metadata: name: server1
  1
  namespace: test
  2
  spec: sourceIPBy: "LoadBalancerIP"
  3
  nodeSelector: matchLabels: vrf: "true"
  4
  network: "2"
  5
  Copy to Clipboard Toggle word wrap
  1
  출구 서비스의 이름을 지정합니다. EgressService 리소스의 이름은 수정하려는 로드 밸런서 서비스의 이름과 일치해야 합니다.
  2
  송신 서비스에 대한 네임스페이스를 지정합니다. EgressService 의 네임스페이스는 수정하려는 로드 밸런서 서비스의 네임스페이스와 일치해야 합니다. 송신 서비스는 네임스페이스 범위입니다.
  3
  이 예제에서는 LoadBalancer 서비스 수신 IP 주소를 송신 트래픽의 소스 IP 주소로 할당합니다.
  4
  sourceIPBy 사양에 대해 LoadBalancer를 지정하는 경우 단일 노드가 LoadBalancer 서비스 트래픽을 처리합니다. 이 예에서 vrf: "true" 라벨이 있는 노드만 서비스 트래픽을 처리할 수 있습니다. 노드를 지정하지 않으면 OVN-Kubernetes는 서비스 트래픽을 처리할 워커 노드를 선택합니다. 노드가 선택되면 OVN-Kubernetes는 다음 형식으로 노드에 레이블을 지정합니다: egress-service.k8s.ovn.org/<svc_namespace>-<svc_name>: "" .
  5
  송신 트래픽에 대한 라우팅 테이블 ID를 지정합니다. 값이 NodeNetworkConfigurationPolicy 리소스에 정의된 route-table-id ID와 일치하는지 확인합니다(예: route-table-id: 2 ).
2. 다음 명령을 실행하여 송신 서비스에 대한 구성을 적용합니다.
  $ oc apply -f egress-service.yaml
  Copy to Clipboard Toggle word wrap

검증

다음 명령을 실행하여 MetalLB 서비스 뒤에서 실행되는 포드의 애플리케이션 엔드포인트에 액세스할 수 있는지 확인하세요.
```
curl <external_ip_address>:<port_number>
```
```
$ curl <external_ip_address>:<port_number> 
```
1
Copy to Clipboard Toggle word wrap
1
애플리케이션 엔드포인트에 맞게 외부 IP 주소와 포트 번호를 업데이트합니다.
선택 사항: LoadBalancer 서비스 수신 IP 주소를 송신 트래픽의 소스 IP 주소로 지정한 경우 tcpdump 와 같은 도구를 사용하여 외부 클라이언트에서 수신된 패킷을 분석하여 이 구성을 확인합니다.

4.8. MetalLB와 FRR-K8s 통합 구성
링크 복사

FRRouting(FRR)은 Linux 및 UNIX 플랫폼을 위한 무료 오픈 소스 인터넷 라우팅 프로토콜 모음입니다. FRR-K8s 는 Kubernetes 호환 방식으로 FRR API의 하위 집합을 공개하는 Kubernetes 기반 DaemonSet입니다. 클러스터 관리자는 FRRConfiguration 사용자 정의 리소스(CR)를 사용하여 MetalLB에서 제공하지 않는 일부 FRR 서비스(예: 수신 경로)에 액세스할 수 있습니다. MetalLB는 적용된 MetalLB 구성에 해당하는 FRR-K8s 구성을 생성합니다.

주의

VRF(가상 경로 전달)를 구성할 때 사용자는 VRF를 1000보다 작은 테이블 ID로 변경해야 합니다. 1000보다 큰 값은 OpenShift Container Platform에 예약되어 있기 때문입니다.

4.8.1. FRR 구성
링크 복사

MetalLB 에서 FRR 서비스를 사용하려면 여러 개의 FRRConfiguration CR을 생성할 수 있습니다. MetalLB는 FRRConfiguration 객체를 생성하고, FRR-K8s는 이를 모든 사용자가 생성한 다른 모든 구성과 병합합니다.

예를 들어, FRR-K8을 구성하여 주어진 이웃이 광고한 모든 접두사를 수신할 수 있습니다. 다음 예제에서는 호스트가 172.18.0.5 인 BGPPeer 에서 광고된 모든 접두사를 수신하도록 FRR-K8s를 구성합니다.

예제 FRRConfiguration CR

apiVersion: frrk8s.metallb.io/v1beta1
kind: FRRConfiguration
metadata:
 name: test
 namespace: metallb-system
spec:
 bgp:
   routers:
   - asn: 64512
     neighbors:
     - address: 172.18.0.5
       asn: 64512
       toReceive:
        allowed:
            mode: all

apiVersion: frrk8s.metallb.io/v1beta1
kind: FRRConfiguration
metadata:
 name: test
 namespace: metallb-system
spec:
 bgp:
   routers:
   - asn: 64512
     neighbors:
     - address: 172.18.0.5
       asn: 64512
       toReceive:
        allowed:
            mode: all

Copy to Clipboard

Toggle word wrap

적용된 구성에 관계 없이 항상 특정 접두사 집합을 차단하도록 FRR-K8을 구성할 수도 있습니다. 이는 클러스터 오작동을 일으킬 수 있는 Pod 또는 ClusterIP CIDR에 대한 경로를 피하는 데 유용할 수 있습니다. 다음 예제에서는 192.168.1.0/24 접두사 세트를 차단합니다.

MetalLB CR 예시

apiVersion: metallb.io/v1beta1
kind: MetalLB
metadata:
  name: metallb
  namespace: metallb-system
spec:
  bgpBackend: frr-k8s
  frrk8sConfig:
    alwaysBlock:
    - 192.168.1.0/24

apiVersion: metallb.io/v1beta1
kind: MetalLB
metadata:
  name: metallb
  namespace: metallb-system
spec:
  bgpBackend: frr-k8s
  frrk8sConfig:
    alwaysBlock:
    - 192.168.1.0/24

Copy to Clipboard

Toggle word wrap

FRR-K8을 설정하여 클러스터 네트워크 CIDR 및 서비스 네트워크 CIDR을 차단할 수 있습니다. 다음 명령을 실행하면 이러한 CIDR 주소 사양에 대한 값을 볼 수 있습니다.

oc describe network.config/cluster

$ oc describe network.config/cluster

Copy to Clipboard

Toggle word wrap

4.8.2. FRRConfiguration CRD 구성
링크 복사

다음 섹션에서는 FRRConfiguration 사용자 정의 리소스(CR)를 사용하는 참조 예를 제공합니다.

4.8.2.1. 라우터 필드
링크 복사

라우터 필드를 사용하여 각 VRF(가상 라우팅 및 포워딩) 리소스에 대해 하나씩 여러 라우터를 구성할 수 있습니다. 각 라우터에 대해 ASN(자율 시스템 번호)을 정의해야 합니다.

다음 예와 같이 연결할 BGP(Border Gateway Protocol) 이웃 목록을 정의할 수도 있습니다.

예제 FRRConfiguration CR

apiVersion: frrk8s.metallb.io/v1beta1
kind: FRRConfiguration
metadata:
  name: test
  namespace: frr-k8s-system
spec:
  bgp:
    routers:
    - asn: 64512
      neighbors:
      - address: 172.30.0.3
        asn: 4200000000
        ebgpMultiHop: true
        port: 180
      - address: 172.18.0.6
        asn: 4200000000
        port: 179

apiVersion: frrk8s.metallb.io/v1beta1
kind: FRRConfiguration
metadata:
  name: test
  namespace: frr-k8s-system
spec:
  bgp:
    routers:
    - asn: 64512
      neighbors:
      - address: 172.30.0.3
        asn: 4200000000
        ebgpMultiHop: true
        port: 180
      - address: 172.18.0.6
        asn: 4200000000
        port: 179

Copy to Clipboard

Toggle word wrap

4.8.2.2. toAdvertise 필드
링크 복사

기본적으로 FRR-K8s는 라우터 구성의 일부로 구성된 접두사를 광고하지 않습니다. 이를 광고하려면 toAdvertise 필드를 사용합니다.

다음 예와 같이 접두사의 하위 집합을 광고할 수 있습니다.

예제 FRRConfiguration CR

apiVersion: frrk8s.metallb.io/v1beta1
kind: FRRConfiguration
metadata:
  name: test
  namespace: frr-k8s-system
spec:
  bgp:
    routers:
    - asn: 64512
      neighbors:
      - address: 172.30.0.3
        asn: 4200000000
        ebgpMultiHop: true
        port: 180
        toAdvertise:
          allowed:
            prefixes: 
            - 192.168.2.0/24
      prefixes:
        - 192.168.2.0/24
        - 192.169.2.0/24

apiVersion: frrk8s.metallb.io/v1beta1
kind: FRRConfiguration
metadata:
  name: test
  namespace: frr-k8s-system
spec:
  bgp:
    routers:
    - asn: 64512
      neighbors:
      - address: 172.30.0.3
        asn: 4200000000
        ebgpMultiHop: true
        port: 180
        toAdvertise:
          allowed:
            prefixes:


            - 192.168.2.0/24
      prefixes:
        - 192.168.2.0/24
        - 192.169.2.0/24

Copy to Clipboard

Toggle word wrap

1: 접두사의 하위 집합을 광고합니다.

다음 예에서는 모든 접두사를 광고하는 방법을 보여줍니다.

예제 FRRConfiguration CR

apiVersion: frrk8s.metallb.io/v1beta1
kind: FRRConfiguration
metadata:
  name: test
  namespace: frr-k8s-system
spec:
  bgp:
    routers:
    - asn: 64512
      neighbors:
      - address: 172.30.0.3
        asn: 4200000000
        ebgpMultiHop: true
        port: 180
        toAdvertise:
          allowed:
            mode: all 
      prefixes:
        - 192.168.2.0/24
        - 192.169.2.0/24

apiVersion: frrk8s.metallb.io/v1beta1
kind: FRRConfiguration
metadata:
  name: test
  namespace: frr-k8s-system
spec:
  bgp:
    routers:
    - asn: 64512
      neighbors:
      - address: 172.30.0.3
        asn: 4200000000
        ebgpMultiHop: true
        port: 180
        toAdvertise:
          allowed:
            mode: all


      prefixes:
        - 192.168.2.0/24
        - 192.169.2.0/24

Copy to Clipboard

Toggle word wrap

1: 모든 접두사를 광고합니다.

4.8.2.3. toReceive 필드
링크 복사

기본적으로 FRR-K8s는 이웃이 광고한 접두사를 처리하지 않습니다. toReceive 필드를 사용하여 이러한 주소를 처리할 수 있습니다.

이 예와 같이 접두사의 하위 집합을 구성할 수 있습니다.

예제 FRRConfiguration CR

apiVersion: frrk8s.metallb.io/v1beta1
kind: FRRConfiguration
metadata:
  name: test
  namespace: frr-k8s-system
spec:
  bgp:
    routers:
    - asn: 64512
      neighbors:
      - address: 172.18.0.5
          asn: 64512
          port: 179
          toReceive:
            allowed:
              prefixes:
              - prefix: 192.168.1.0/24
              - prefix: 192.169.2.0/24
                ge: 25 
                le: 28

apiVersion: frrk8s.metallb.io/v1beta1
kind: FRRConfiguration
metadata:
  name: test
  namespace: frr-k8s-system
spec:
  bgp:
    routers:
    - asn: 64512
      neighbors:
      - address: 172.18.0.5
          asn: 64512
          port: 179
          toReceive:
            allowed:
              prefixes:
              - prefix: 192.168.1.0/24
              - prefix: 192.169.2.0/24
                ge: 25


                le: 28

Copy to Clipboard

Toggle word wrap

1 2: 접두사 길이가 le 접두사 길이보다 작거나 같고 ge 접두사 길이보다 크거나 같은 경우 접두사가 적용됩니다.

다음 예에서는 FRR이 발표된 모든 접두사를 처리하도록 구성합니다.

예제 FRRConfiguration CR

apiVersion: frrk8s.metallb.io/v1beta1
kind: FRRConfiguration
metadata:
  name: test
  namespace: frr-k8s-system
spec:
  bgp:
    routers:
    - asn: 64512
      neighbors:
      - address: 172.18.0.5
          asn: 64512
          port: 179
          toReceive:
            allowed:
              mode: all

apiVersion: frrk8s.metallb.io/v1beta1
kind: FRRConfiguration
metadata:
  name: test
  namespace: frr-k8s-system
spec:
  bgp:
    routers:
    - asn: 64512
      neighbors:
      - address: 172.18.0.5
          asn: 64512
          port: 179
          toReceive:
            allowed:
              mode: all

Copy to Clipboard

Toggle word wrap

4.8.2.4. bgp 필드
링크 복사

bgp 필드를 사용하여 다양한 BFD 프로필을 정의하고 이를 이웃과 연결할 수 있습니다. 다음 예에서 BFD는 BGP 세션을 백업하고 FRR은 링크 오류를 감지할 수 있습니다.

예제 FRRConfiguration CR

apiVersion: frrk8s.metallb.io/v1beta1
kind: FRRConfiguration
metadata:
  name: test
  namespace: frr-k8s-system
spec:
  bgp:
    routers:
    - asn: 64512
      neighbors:
      - address: 172.30.0.3
        asn: 64512
        port: 180
        bfdProfile: defaultprofile
    bfdProfiles:
      - name: defaultprofile

apiVersion: frrk8s.metallb.io/v1beta1
kind: FRRConfiguration
metadata:
  name: test
  namespace: frr-k8s-system
spec:
  bgp:
    routers:
    - asn: 64512
      neighbors:
      - address: 172.30.0.3
        asn: 64512
        port: 180
        bfdProfile: defaultprofile
    bfdProfiles:
      - name: defaultprofile

Copy to Clipboard

Toggle word wrap

4.8.2.5. nodeSelector 필드
링크 복사

기본적으로 FRR-K8s는 데몬이 실행 중인 모든 노드에 구성을 적용합니다. nodeSelector 필드를 사용하여 구성을 적용할 노드를 지정할 수 있습니다. 예를 들면 다음과 같습니다.

예제 FRRConfiguration CR

apiVersion: frrk8s.metallb.io/v1beta1
kind: FRRConfiguration
metadata:
  name: test
  namespace: frr-k8s-system
spec:
  bgp:
    routers:
    - asn: 64512
  nodeSelector:
    labelSelector:
    foo: "bar"

apiVersion: frrk8s.metallb.io/v1beta1
kind: FRRConfiguration
metadata:
  name: test
  namespace: frr-k8s-system
spec:
  bgp:
    routers:
    - asn: 64512
  nodeSelector:
    labelSelector:
    foo: "bar"

Copy to Clipboard

Toggle word wrap

4.8.2.6. 인터페이스 필드
링크 복사

중요

spec.bgp.routers.neighbors.interface 필드는 기술 미리보기 기능에만 해당됩니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

다음 예제 구성을 사용하여 인터페이스 필드를 사용하여 번호가 지정되지 않은 BGP 피어링을 구성할 수 있습니다.

예제 FRRConfiguration CR

apiVersion: frrk8s.metallb.io/v1beta1
kind: FRRConfiguration
metadata:
  name: test
  namespace: frr-k8s-system
spec:
  bgp:
    bfdProfiles:
    - echoMode: false
      name: simple
      passiveMode: false
    routers:
    - asn: 64512
      neighbors:
      - asn: 64512
        bfdProfile: simple
        disableMP: false
        interface: net10 
        port: 179
        toAdvertise:
          allowed:
            mode: filtered
            prefixes:
            - 5.5.5.5/32
        toReceive:
          allowed:
            mode: filtered
      prefixes:
      - 5.5.5.5/32

apiVersion: frrk8s.metallb.io/v1beta1
kind: FRRConfiguration
metadata:
  name: test
  namespace: frr-k8s-system
spec:
  bgp:
    bfdProfiles:
    - echoMode: false
      name: simple
      passiveMode: false
    routers:
    - asn: 64512
      neighbors:
      - asn: 64512
        bfdProfile: simple
        disableMP: false
        interface: net10


        port: 179
        toAdvertise:
          allowed:
            mode: filtered
            prefixes:
            - 5.5.5.5/32
        toReceive:
          allowed:
            mode: filtered
      prefixes:
      - 5.5.5.5/32

Copy to Clipboard

Toggle word wrap

1: 번호가 지정되지 않은 BGP 피어링을 활성화합니다.

참고

이 필드를 사용하면 spec.bgp.routers.neighbors.address 필드에 값을 지정할 수 없습니다.

다음 표에서는 FRRConfiguration 사용자 정의 리소스에 대한 필드에 대해 설명합니다.

Expand

표 4.9. MetalLB FRRConfiguration 사용자 정의 리소스
필드	유형	설명
`spec.bgp.routers`	`array`	FRR이 구성할 라우터를 지정합니다(VRF당 하나).
`spec.bgp.routers.asn`	`integer`	세션의 로컬 종료에 사용할 자율 시스템 번호(ASN)입니다.
`spec.bgp.routers.id`	`string`	`bgp` 라우터의 ID를 지정합니다.
`spec.bgp.routers.vrf`	`string`	이 라우터에서 세션을 설정하는 데 사용되는 호스트 vrf를 지정합니다.
`spec.bgp.routers.neighbors`	`array`	BGP 세션을 설정할 이웃을 지정합니다.
`spec.bgp.routers.neighbors.asn`	`integer`	세션의 원격 끝에 사용할 ASN을 지정합니다. 이 필드를 사용하면 `spec.bgp.routers.neighbors.dynamicASN` 필드에 값을 지정할 수 없습니다.
`spec.bgp.routers.neighbors.dynamicASN`	`string`	명시적으로 설정하지 않고 세션의 원격 끝에 사용할 ASN을 감지합니다. 동일한 ASN을 가진 이웃에 대해서는 `내부를` 지정하고, 다른 ASN을 가진 이웃에 대해서는 `외부를` 지정합니다. 이 필드를 사용하면 `spec.bgp.routers.neighbors.asn` 필드에 값을 지정할 수 없습니다.
`spec.bgp.routers.neighbors.address`	`string`	세션을 설정할 IP 주소를 지정합니다. 이 필드를 사용하면 `spec.bgp.routers.neighbors.interface` 필드에 값을 지정할 수 없습니다.
`spec.bgp.routers.neighbors.interface`	`string`	세션을 설정할 때 사용할 인터페이스 이름을 지정합니다. 이 필드를 사용하여 번호가 지정되지 않은 BGP 피어링을 구성합니다. 두 BGP 피어 사이에는 지점 간, 계층 2 연결이 있어야 합니다. IPv4, IPv6 또는 듀얼 스택에서 번호가 지정되지 않은 BGP 피어링을 사용할 수 있지만 IPv6 RA(라우터 광고)를 활성화해야 합니다. 각 인터페이스는 하나의 BGP 연결로 제한됩니다. `spec.bgp.routers.neighbors.interface` 필드는 기술 미리보기 기능에만 해당됩니다. Red Hat Technology Preview 기능의 지원 범위에 대한 자세한 내용은 Technology Preview 기능 지원 범위를 참조하세요.
`spec.bgp.routers.neighbors.port`	`integer`	세션을 설정할 때 다이얼할 포트를 지정합니다. 기본값은 179입니다.
`spec.bgp.routers.neighbors.password`	`string`	BGP 세션을 설정하는 데 사용할 비밀번호를 지정합니다. `Password` 와 `PasswordSecret은` 상호 배타적입니다.
`spec.bgp.routers.neighbors.passwordSecret`	`string`	이웃에 대한 인증 비밀번호의 이름을 지정합니다. 비밀번호는 "kubernetes.io/basic-auth" 유형이어야 하며 FRR-K8s 데몬과 동일한 네임스페이스에 있어야 합니다. "password" 키는 비밀번호를 비밀에 저장합니다. `Password` 와 `PasswordSecret은` 상호 배타적입니다.
`spec.bgp.routers.neighbors.holdTime`	`duration`	RFC4271에 따라 요청된 BGP 보류 시간을 지정합니다. 기본값은 180입니다.
`spec.bgp.routers.neighbors.keepaliveTime`	`duration`	RFC4271에 따라 요청된 BGP keepalive 시간을 지정합니다. 기본값은 `60초` 입니다.
`spec.bgp.routers.neighbors.connectTime`	`duration`	BGP가 이웃과의 연결을 시도하는 사이에 기다리는 시간을 지정합니다.
`spec.bgp.routers.neighbors.ebgpMultiHop`	`boolean`	BGPPeer가 멀티홉 떨어져 있는지 여부를 나타냅니다.
`spec.bgp.routers.neighbors.bfdProfile`	`string`	BGP 세션과 연관된 BFD 세션에 사용할 BFD 프로필의 이름을 지정합니다. 설정하지 않으면 BFD 세션이 설정되지 않습니다.
`spec.bgp.routers.neighbors.toAdvertise.allowed`	`array`	이웃에게 광고할 접두사 목록과 연관된 속성을 나타냅니다.
`spec.bgp.routers.neighbors.toAdvertise.allowed.prefixes`	`문자열 배열`	이웃에게 광고할 접두사 목록을 지정합니다. 이 목록은 라우터에서 정의한 접두사와 일치해야 합니다.
`spec.bgp.routers.neighbors.toAdvertise.allowed.mode`	`string`	접두사를 처리할 때 사용할 모드를 지정합니다. 접두사 목록에 있는 접두사만 허용하도록 `필터링` 을 설정할 수 있습니다. 라우터에 구성된 모든 접두사를 허용하려면 `'모두'` 로 설정할 수 있습니다.
`spec.bgp.routers.neighbors.toAdvertise.withLocalPref`	`array`	광고된 로컬 환경 설정과 관련된 접두사를 지정합니다. 광고가 허용되는 접두사에서 로컬 기본 설정과 연관된 접두사를 지정해야 합니다.
`spec.bgp.routers.neighbors.toAdvertise.withLocalPref.prefixes`	`문자열 배열`	로컬 기본 설정과 관련된 접두사를 지정합니다.
`spec.bgp.routers.neighbors.toAdvertise.withLocalPref.localPref`	`integer`	접두사와 관련된 로컬 기본 설정을 지정합니다.
`spec.bgp.routers.neighbors.toAdvertise.withCommunity`	`array`	광고된 BGP 커뮤니티와 연관된 접두사를 지정합니다. 광고하려는 접두사 목록에 로컬 기본 설정과 연관된 접두사를 포함해야 합니다.
`spec.bgp.routers.neighbors.toAdvertise.withCommunity.prefixes`	`문자열 배열`	커뮤니티와 관련된 접두사를 지정합니다.
`spec.bgp.routers.neighbors.toAdvertise.withCommunity.community`	`string`	접두사와 연관된 커뮤니티를 지정합니다.
`spec.bgp.routers.neighbors.toReceive`	`array`	이웃으로부터 수신할 접두사를 지정합니다.
`spec.bgp.routers.neighbors.toReceive.allowed`	`array`	이웃에게서 받고 싶은 정보를 지정합니다.
`spec.bgp.routers.neighbors.toReceive.allowed.prefixes`	`array`	이웃에서 허용되는 접두사를 지정합니다.
`spec.bgp.routers.neighbors.toReceive.allowed.mode`	`string`	접두사를 처리할 때 사용할 모드를 지정합니다. `필터링` 으로 설정하면 `접두사` 목록에 있는 접두사만 허용됩니다. `all` 로 설정하면 라우터에 구성된 모든 접두사가 허용됩니다.
`spec.bgp.routers.neighbors.disableMP`	`boolean`	MP BGP를 비활성화하여 IPv4 및 IPv6 경로 교환을 별도의 BGP 세션으로 분리하지 못하도록 합니다.
`spec.bgp.routers.prefixes`	`문자열 배열`	이 라우터 인스턴스에서 광고할 모든 접두사를 지정합니다.
`spec.bgp.bfdProfiles`	`array`	이웃을 구성할 때 사용할 BFD 프로필 목록을 지정합니다.
`spec.bgp.bfdProfiles.name`	`string`	구성의 다른 부분에서 참조할 BFD 프로필의 이름입니다.
`spec.bgp.bfdProfiles.receiveInterval`	`integer`	이 시스템이 제어 패킷을 수신할 수 있는 최소 간격을 밀리초 단위로 지정합니다. 기본값은 `300ms` 입니다.
`spec.bgp.bfdProfiles.transmitInterval`	`integer`	지터를 제외한, 이 시스템이 BFD 제어 패킷을 보내는 데 사용하려는 최소 전송 간격을 밀리초 단위로 지정합니다. 기본값은 `300ms` 입니다.
`spec.bgp.bfdProfiles.detectMultiplier`	`integer`	패킷 손실을 판별하기 위해 감지 배수를 구성합니다. 연결 손실 감지 타이머를 결정하려면 원격 전송 간격에 이 값을 곱합니다.
`spec.bgp.bfdProfiles.echoInterval`	`integer`	이 시스템이 처리할 수 있는 최소 에코 수신 전송 간격을 밀리초 단위로 구성합니다. 기본값은 `50ms` 입니다.
`spec.bgp.bfdProfiles.echoMode`	`boolean`	에코 전송 모드를 활성화하거나 비활성화합니다. 이 모드는 기본적으로 비활성화되어 있으며 멀티홉 설정에서는 지원되지 않습니다.
`spec.bgp.bfdProfiles.passiveMode`	`boolean`	세션을 수동적으로 표시하세요. 수동 세션은 연결을 시작하려고 시도하지 않고 피어로부터 제어 패킷을 기다린 후 응답을 시작합니다.
`spec.bgp.bfdProfiles.MinimumTtl`	`integer`	멀티홉 세션에만 해당됩니다. 수신 BFD 제어 패킷에 대한 최소 예상 TTL을 구성합니다.
`spec.nodeSelector`	`string`	이 구성을 적용하려는 노드를 제한합니다. 지정된 경우, 지정된 선택기와 일치하는 레이블을 가진 노드만 구성을 적용하려고 시도합니다. 지정하지 않으면 모든 노드가 이 구성을 적용하려고 시도합니다.
`status`	`string`	FRRConfiguration의 관찰된 상태를 정의합니다.

4.8.3. FRR-K8s가 여러 구성을 병합하는 방법
링크 복사

여러 사용자가 동일한 노드를 선택하는 구성을 추가하는 경우 FRR-K8s는 구성을 병합합니다. 각 구성은 다른 구성을 확장할 수만 있습니다. 즉, 라우터에 새로운 이웃을 추가하거나 이웃에게 추가 접두사를 광고하는 것은 가능하지만, 다른 구성에 의해 추가된 구성 요소를 제거하는 것은 불가능합니다.

4.8.3.1. 구성 충돌
링크 복사

다음과 같은 특정 구성으로 인해 충돌이 발생하여 오류가 발생할 수 있습니다.

동일한 라우터(동일한 VRF 내)에 대해 다른 ASN
동일한 이웃(동일한 IP/포트)에 대해 다른 ASN
이름은 같지만 값이 다른 여러 BFD 프로필

데몬이 노드에 대해 유효하지 않은 구성을 찾으면 해당 구성을 유효하지 않은 것으로 보고하고 이전의 유효한 FRR 구성으로 되돌립니다.

4.8.3.2. 병합
링크 복사

병합할 때 다음 작업을 수행할 수 있습니다.

이웃에게 광고하려는 IP 세트를 확장합니다.
IP 집합을 사용하여 추가 이웃을 추가합니다.
커뮤니티를 연결할 IP 세트를 확장합니다.
이웃에 대한 수신 경로를 허용합니다.

각 구성은 자체적으로 포함되어야 합니다. 예를 들어, 이는 다른 구성에서 온 접두사를 활용하여 라우터 섹션에 정의되지 않은 접두사를 허용하는 것이 불가능하다는 것을 의미합니다.

적용할 구성이 호환되는 경우 병합은 다음과 같이 작동합니다.

FRR-K8s는 모든 라우터를 결합했습니다.
FRR-K8s는 각 라우터의 모든 접두사와 이웃을 병합합니다.
FRR-K8s는 각 이웃에 대한 모든 필터를 병합합니다.

참고

제한이 덜한 필터는 엄격한 필터보다 우선합니다. 예를 들어, 일부 접두사를 허용하는 필터는 아무것도 허용하지 않는 필터보다 우선하고, 모든 접두사를 허용하는 필터는 일부만 허용하는 필터보다 우선합니다.

4.9. MetalLB 로깅, 문제 해결 및 지원
링크 복사

MetalLB 구성 문제를 해결해야 하는 경우 일반적으로 사용되는 명령에 대한 다음 섹션을 참조하세요.

4.9.1. MetalLB 로깅 수준 설정
링크 복사

MetalLB는 기본 설정인 info 를 사용하여 컨테이너에서 FRRouting(FRR)을 사용하여 많은 로깅을 생성합니다. 이 예제에서 설명한 대로 logLevel을 설정하여 생성된 로그의 자세한 정도를 제어할 수 있습니다.

다음과 같이 logLevel을 debug 로 설정하여 MetalLB에 대한 더 깊은 통찰력을 얻으세요.

사전 요구 사항

cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
OpenShift CLI(oc)가 설치되어 있습니다.

프로세스

다음 예시와 같은 내용을 담은 setdebugloglevel.yaml 과 같은 파일을 만듭니다.

apiVersion: metallb.io/v1beta1
kind: MetalLB
metadata:
  name: metallb
  namespace: metallb-system
spec:
  logLevel: debug
  nodeSelector:
    node-role.kubernetes.io/worker: ""

apiVersion: metallb.io/v1beta1
kind: MetalLB
metadata:
  name: metallb
  namespace: metallb-system
spec:
  logLevel: debug
  nodeSelector:
    node-role.kubernetes.io/worker: ""

Copy to Clipboard

Toggle word wrap

설정을 적용합니다.
```
oc replace -f setdebugloglevel.yaml
```
```
$ oc replace -f setdebugloglevel.yaml
```
Copy to Clipboard Toggle word wrap
참고
oc replace를 사용하는 이유는 metallb CR이 이미 생성되었고 여기서 로그 수준을 변경하고 있기 때문입니다.

스피커 포드의 이름을 표시합니다.

oc get -n metallb-system pods -l component=speaker

$ oc get -n metallb-system pods -l component=speaker

Copy to Clipboard

Toggle word wrap

출력 예

NAME                    READY   STATUS    RESTARTS   AGE
speaker-2m9pm           4/4     Running   0          9m19s
speaker-7m4qw           3/4     Running   0          19s
speaker-szlmx           4/4     Running   0          9m19s

NAME                    READY   STATUS    RESTARTS   AGE
speaker-2m9pm           4/4     Running   0          9m19s
speaker-7m4qw           3/4     Running   0          19s
speaker-szlmx           4/4     Running   0          9m19s

Copy to Clipboard

Toggle word wrap

참고

업데이트된 로깅 수준이 적용되도록 스피커와 컨트롤러 포드가 다시 생성됩니다. MetalLB의 모든 구성 요소에 대한 로깅 수준이 수정되었습니다.

스피커 로그 보기:

oc logs -n metallb-system speaker-7m4qw -c speaker

$ oc logs -n metallb-system speaker-7m4qw -c speaker

Copy to Clipboard

Toggle word wrap

출력 예

{"branch":"main","caller":"main.go:92","commit":"3d052535","goversion":"gc / go1.17.1 / amd64","level":"info","msg":"MetalLB speaker starting (commit 3d052535, branch main)","ts":"2022-05-17T09:55:05Z","version":""}
{"caller":"announcer.go:110","event":"createARPResponder","interface":"ens4","level":"info","msg":"created ARP responder for interface","ts":"2022-05-17T09:55:05Z"}
{"caller":"announcer.go:119","event":"createNDPResponder","interface":"ens4","level":"info","msg":"created NDP responder for interface","ts":"2022-05-17T09:55:05Z"}
{"caller":"announcer.go:110","event":"createARPResponder","interface":"tun0","level":"info","msg":"created ARP responder for interface","ts":"2022-05-17T09:55:05Z"}
{"caller":"announcer.go:119","event":"createNDPResponder","interface":"tun0","level":"info","msg":"created NDP responder for interface","ts":"2022-05-17T09:55:05Z"}
I0517 09:55:06.515686      95 request.go:665] Waited for 1.026500832s due to client-side throttling, not priority and fairness, request: GET:https://172.30.0.1:443/apis/operators.coreos.com/v1alpha1?timeout=32s
{"Starting Manager":"(MISSING)","caller":"k8s.go:389","level":"info","ts":"2022-05-17T09:55:08Z"}
{"caller":"speakerlist.go:310","level":"info","msg":"node event - forcing sync","node addr":"10.0.128.4","node event":"NodeJoin","node name":"ci-ln-qb8t3mb-72292-7s7rh-worker-a-vvznj","ts":"2022-05-17T09:55:08Z"}
{"caller":"service_controller.go:113","controller":"ServiceReconciler","enqueueing":"openshift-kube-controller-manager-operator/metrics","epslice":"{\"metadata\":{\"name\":\"metrics-xtsxr\",\"generateName\":\"metrics-\",\"namespace\":\"openshift-kube-controller-manager-operator\",\"uid\":\"ac6766d7-8504-492c-9d1e-4ae8897990ad\",\"resourceVersion\":\"9041\",\"generation\":4,\"creationTimestamp\":\"2022-05-17T07:16:53Z\",\"labels\":{\"app\":\"kube-controller-manager-operator\",\"endpointslice.kubernetes.io/managed-by\":\"endpointslice-controller.k8s.io\",\"kubernetes.io/service-name\":\"metrics\"},\"annotations\":{\"endpoints.kubernetes.io/last-change-trigger-time\":\"2022-05-17T07:21:34Z\"},\"ownerReferences\":[{\"apiVersion\":\"v1\",\"kind\":\"Service\",\"name\":\"metrics\",\"uid\":\"0518eed3-6152-42be-b566-0bd00a60faf8\",\"controller\":true,\"blockOwnerDeletion\":true}],\"managedFields\":[{\"manager\":\"kube-controller-manager\",\"operation\":\"Update\",\"apiVersion\":\"discovery.k8s.io/v1\",\"time\":\"2022-05-17T07:20:02Z\",\"fieldsType\":\"FieldsV1\",\"fieldsV1\":{\"f:addressType\":{},\"f:endpoints\":{},\"f:metadata\":{\"f:annotations\":{\".\":{},\"f:endpoints.kubernetes.io/last-change-trigger-time\":{}},\"f:generateName\":{},\"f:labels\":{\".\":{},\"f:app\":{},\"f:endpointslice.kubernetes.io/managed-by\":{},\"f:kubernetes.io/service-name\":{}},\"f:ownerReferences\":{\".\":{},\"k:{\\\"uid\\\":\\\"0518eed3-6152-42be-b566-0bd00a60faf8\\\"}\":{}}},\"f:ports\":{}}}]},\"addressType\":\"IPv4\",\"endpoints\":[{\"addresses\":[\"10.129.0.7\"],\"conditions\":{\"ready\":true,\"serving\":true,\"terminating\":false},\"targetRef\":{\"kind\":\"Pod\",\"namespace\":\"openshift-kube-controller-manager-operator\",\"name\":\"kube-controller-manager-operator-6b98b89ddd-8d4nf\",\"uid\":\"dd5139b8-e41c-4946-a31b-1a629314e844\",\"resourceVersion\":\"9038\"},\"nodeName\":\"ci-ln-qb8t3mb-72292-7s7rh-master-0\",\"zone\":\"us-central1-a\"}],\"ports\":[{\"name\":\"https\",\"protocol\":\"TCP\",\"port\":8443}]}","level":"debug","ts":"2022-05-17T09:55:08Z"}

{"branch":"main","caller":"main.go:92","commit":"3d052535","goversion":"gc / go1.17.1 / amd64","level":"info","msg":"MetalLB speaker starting (commit 3d052535, branch main)","ts":"2022-05-17T09:55:05Z","version":""}
{"caller":"announcer.go:110","event":"createARPResponder","interface":"ens4","level":"info","msg":"created ARP responder for interface","ts":"2022-05-17T09:55:05Z"}
{"caller":"announcer.go:119","event":"createNDPResponder","interface":"ens4","level":"info","msg":"created NDP responder for interface","ts":"2022-05-17T09:55:05Z"}
{"caller":"announcer.go:110","event":"createARPResponder","interface":"tun0","level":"info","msg":"created ARP responder for interface","ts":"2022-05-17T09:55:05Z"}
{"caller":"announcer.go:119","event":"createNDPResponder","interface":"tun0","level":"info","msg":"created NDP responder for interface","ts":"2022-05-17T09:55:05Z"}
I0517 09:55:06.515686      95 request.go:665] Waited for 1.026500832s due to client-side throttling, not priority and fairness, request: GET:https://172.30.0.1:443/apis/operators.coreos.com/v1alpha1?timeout=32s
{"Starting Manager":"(MISSING)","caller":"k8s.go:389","level":"info","ts":"2022-05-17T09:55:08Z"}
{"caller":"speakerlist.go:310","level":"info","msg":"node event - forcing sync","node addr":"10.0.128.4","node event":"NodeJoin","node name":"ci-ln-qb8t3mb-72292-7s7rh-worker-a-vvznj","ts":"2022-05-17T09:55:08Z"}
{"caller":"service_controller.go:113","controller":"ServiceReconciler","enqueueing":"openshift-kube-controller-manager-operator/metrics","epslice":"{\"metadata\":{\"name\":\"metrics-xtsxr\",\"generateName\":\"metrics-\",\"namespace\":\"openshift-kube-controller-manager-operator\",\"uid\":\"ac6766d7-8504-492c-9d1e-4ae8897990ad\",\"resourceVersion\":\"9041\",\"generation\":4,\"creationTimestamp\":\"2022-05-17T07:16:53Z\",\"labels\":{\"app\":\"kube-controller-manager-operator\",\"endpointslice.kubernetes.io/managed-by\":\"endpointslice-controller.k8s.io\",\"kubernetes.io/service-name\":\"metrics\"},\"annotations\":{\"endpoints.kubernetes.io/last-change-trigger-time\":\"2022-05-17T07:21:34Z\"},\"ownerReferences\":[{\"apiVersion\":\"v1\",\"kind\":\"Service\",\"name\":\"metrics\",\"uid\":\"0518eed3-6152-42be-b566-0bd00a60faf8\",\"controller\":true,\"blockOwnerDeletion\":true}],\"managedFields\":[{\"manager\":\"kube-controller-manager\",\"operation\":\"Update\",\"apiVersion\":\"discovery.k8s.io/v1\",\"time\":\"2022-05-17T07:20:02Z\",\"fieldsType\":\"FieldsV1\",\"fieldsV1\":{\"f:addressType\":{},\"f:endpoints\":{},\"f:metadata\":{\"f:annotations\":{\".\":{},\"f:endpoints.kubernetes.io/last-change-trigger-time\":{}},\"f:generateName\":{},\"f:labels\":{\".\":{},\"f:app\":{},\"f:endpointslice.kubernetes.io/managed-by\":{},\"f:kubernetes.io/service-name\":{}},\"f:ownerReferences\":{\".\":{},\"k:{\\\"uid\\\":\\\"0518eed3-6152-42be-b566-0bd00a60faf8\\\"}\":{}}},\"f:ports\":{}}}]},\"addressType\":\"IPv4\",\"endpoints\":[{\"addresses\":[\"10.129.0.7\"],\"conditions\":{\"ready\":true,\"serving\":true,\"terminating\":false},\"targetRef\":{\"kind\":\"Pod\",\"namespace\":\"openshift-kube-controller-manager-operator\",\"name\":\"kube-controller-manager-operator-6b98b89ddd-8d4nf\",\"uid\":\"dd5139b8-e41c-4946-a31b-1a629314e844\",\"resourceVersion\":\"9038\"},\"nodeName\":\"ci-ln-qb8t3mb-72292-7s7rh-master-0\",\"zone\":\"us-central1-a\"}],\"ports\":[{\"name\":\"https\",\"protocol\":\"TCP\",\"port\":8443}]}","level":"debug","ts":"2022-05-17T09:55:08Z"}

Copy to Clipboard

Toggle word wrap

FRR 로그를 확인하세요:

oc logs -n metallb-system speaker-7m4qw -c frr

$ oc logs -n metallb-system speaker-7m4qw -c frr

Copy to Clipboard

Toggle word wrap

출력 예

Started watchfrr
2022/05/17 09:55:05 ZEBRA: client 16 says hello and bids fair to announce only bgp routes vrf=0
2022/05/17 09:55:05 ZEBRA: client 31 says hello and bids fair to announce only vnc routes vrf=0
2022/05/17 09:55:05 ZEBRA: client 38 says hello and bids fair to announce only static routes vrf=0
2022/05/17 09:55:05 ZEBRA: client 43 says hello and bids fair to announce only bfd routes vrf=0
2022/05/17 09:57:25.089 BGP: Creating Default VRF, AS 64500
2022/05/17 09:57:25.090 BGP: dup addr detect enable max_moves 5 time 180 freeze disable freeze_time 0
2022/05/17 09:57:25.090 BGP: bgp_get: Registering BGP instance (null) to zebra
2022/05/17 09:57:25.090 BGP: Registering VRF 0
2022/05/17 09:57:25.091 BGP: Rx Router Id update VRF 0 Id 10.131.0.1/32
2022/05/17 09:57:25.091 BGP: RID change : vrf VRF default(0), RTR ID 10.131.0.1
2022/05/17 09:57:25.091 BGP: Rx Intf add VRF 0 IF br0
2022/05/17 09:57:25.091 BGP: Rx Intf add VRF 0 IF ens4
2022/05/17 09:57:25.091 BGP: Rx Intf address add VRF 0 IF ens4 addr 10.0.128.4/32
2022/05/17 09:57:25.091 BGP: Rx Intf address add VRF 0 IF ens4 addr fe80::c9d:84da:4d86:5618/64
2022/05/17 09:57:25.091 BGP: Rx Intf add VRF 0 IF lo
2022/05/17 09:57:25.091 BGP: Rx Intf add VRF 0 IF ovs-system
2022/05/17 09:57:25.091 BGP: Rx Intf add VRF 0 IF tun0
2022/05/17 09:57:25.091 BGP: Rx Intf address add VRF 0 IF tun0 addr 10.131.0.1/23
2022/05/17 09:57:25.091 BGP: Rx Intf address add VRF 0 IF tun0 addr fe80::40f1:d1ff:feb6:5322/64
2022/05/17 09:57:25.091 BGP: Rx Intf add VRF 0 IF veth2da49fed
2022/05/17 09:57:25.091 BGP: Rx Intf address add VRF 0 IF veth2da49fed addr fe80::24bd:d1ff:fec1:d88/64
2022/05/17 09:57:25.091 BGP: Rx Intf add VRF 0 IF veth2fa08c8c
2022/05/17 09:57:25.091 BGP: Rx Intf address add VRF 0 IF veth2fa08c8c addr fe80::6870:ff:fe96:efc8/64
2022/05/17 09:57:25.091 BGP: Rx Intf add VRF 0 IF veth41e356b7
2022/05/17 09:57:25.091 BGP: Rx Intf address add VRF 0 IF veth41e356b7 addr fe80::48ff:37ff:fede:eb4b/64
2022/05/17 09:57:25.092 BGP: Rx Intf add VRF 0 IF veth1295c6e2
2022/05/17 09:57:25.092 BGP: Rx Intf address add VRF 0 IF veth1295c6e2 addr fe80::b827:a2ff:feed:637/64
2022/05/17 09:57:25.092 BGP: Rx Intf add VRF 0 IF veth9733c6dc
2022/05/17 09:57:25.092 BGP: Rx Intf address add VRF 0 IF veth9733c6dc addr fe80::3cf4:15ff:fe11:e541/64
2022/05/17 09:57:25.092 BGP: Rx Intf add VRF 0 IF veth336680ea
2022/05/17 09:57:25.092 BGP: Rx Intf address add VRF 0 IF veth336680ea addr fe80::94b1:8bff:fe7e:488c/64
2022/05/17 09:57:25.092 BGP: Rx Intf add VRF 0 IF vetha0a907b7
2022/05/17 09:57:25.092 BGP: Rx Intf address add VRF 0 IF vetha0a907b7 addr fe80::3855:a6ff:fe73:46c3/64
2022/05/17 09:57:25.092 BGP: Rx Intf add VRF 0 IF vethf35a4398
2022/05/17 09:57:25.092 BGP: Rx Intf address add VRF 0 IF vethf35a4398 addr fe80::40ef:2fff:fe57:4c4d/64
2022/05/17 09:57:25.092 BGP: Rx Intf add VRF 0 IF vethf831b7f4
2022/05/17 09:57:25.092 BGP: Rx Intf address add VRF 0 IF vethf831b7f4 addr fe80::f0d9:89ff:fe7c:1d32/64
2022/05/17 09:57:25.092 BGP: Rx Intf add VRF 0 IF vxlan_sys_4789
2022/05/17 09:57:25.092 BGP: Rx Intf address add VRF 0 IF vxlan_sys_4789 addr fe80::80c1:82ff:fe4b:f078/64
2022/05/17 09:57:26.094 BGP: 10.0.0.1 [FSM] Timer (start timer expire).
2022/05/17 09:57:26.094 BGP: 10.0.0.1 [FSM] BGP_Start (Idle->Connect), fd -1
2022/05/17 09:57:26.094 BGP: Allocated bnc 10.0.0.1/32(0)(VRF default) peer 0x7f807f7631a0
2022/05/17 09:57:26.094 BGP: sendmsg_zebra_rnh: sending cmd ZEBRA_NEXTHOP_REGISTER for 10.0.0.1/32 (vrf VRF default)
2022/05/17 09:57:26.094 BGP: 10.0.0.1 [FSM] Waiting for NHT
2022/05/17 09:57:26.094 BGP: bgp_fsm_change_status : vrf default(0), Status: Connect established_peers 0
2022/05/17 09:57:26.094 BGP: 10.0.0.1 went from Idle to Connect
2022/05/17 09:57:26.094 BGP: 10.0.0.1 [FSM] TCP_connection_open_failed (Connect->Active), fd -1
2022/05/17 09:57:26.094 BGP: bgp_fsm_change_status : vrf default(0), Status: Active established_peers 0
2022/05/17 09:57:26.094 BGP: 10.0.0.1 went from Connect to Active
2022/05/17 09:57:26.094 ZEBRA: rnh_register msg from client bgp: hdr->length=8, type=nexthop vrf=0
2022/05/17 09:57:26.094 ZEBRA: 0: Add RNH 10.0.0.1/32 type Nexthop
2022/05/17 09:57:26.094 ZEBRA: 0:10.0.0.1/32: Evaluate RNH, type Nexthop (force)
2022/05/17 09:57:26.094 ZEBRA: 0:10.0.0.1/32: NH has become unresolved
2022/05/17 09:57:26.094 ZEBRA: 0: Client bgp registers for RNH 10.0.0.1/32 type Nexthop
2022/05/17 09:57:26.094 BGP: VRF default(0): Rcvd NH update 10.0.0.1/32(0) - metric 0/0 #nhops 0/0 flags 0x6
2022/05/17 09:57:26.094 BGP: NH update for 10.0.0.1/32(0)(VRF default) - flags 0x6 chgflags 0x0 - evaluate paths
2022/05/17 09:57:26.094 BGP: evaluate_paths: Updating peer (10.0.0.1(VRF default)) status with NHT
2022/05/17 09:57:30.081 ZEBRA: Event driven route-map update triggered
2022/05/17 09:57:30.081 ZEBRA: Event handler for route-map: 10.0.0.1-out
2022/05/17 09:57:30.081 ZEBRA: Event handler for route-map: 10.0.0.1-in
2022/05/17 09:57:31.104 ZEBRA: netlink_parse_info: netlink-listen (NS 0) type RTM_NEWNEIGH(28), len=76, seq=0, pid=0
2022/05/17 09:57:31.104 ZEBRA: 	Neighbor Entry received is not on a VLAN or a BRIDGE, ignoring
2022/05/17 09:57:31.105 ZEBRA: netlink_parse_info: netlink-listen (NS 0) type RTM_NEWNEIGH(28), len=76, seq=0, pid=0
2022/05/17 09:57:31.105 ZEBRA: 	Neighbor Entry received is not on a VLAN or a BRIDGE, ignoring

Started watchfrr
2022/05/17 09:55:05 ZEBRA: client 16 says hello and bids fair to announce only bgp routes vrf=0
2022/05/17 09:55:05 ZEBRA: client 31 says hello and bids fair to announce only vnc routes vrf=0
2022/05/17 09:55:05 ZEBRA: client 38 says hello and bids fair to announce only static routes vrf=0
2022/05/17 09:55:05 ZEBRA: client 43 says hello and bids fair to announce only bfd routes vrf=0
2022/05/17 09:57:25.089 BGP: Creating Default VRF, AS 64500
2022/05/17 09:57:25.090 BGP: dup addr detect enable max_moves 5 time 180 freeze disable freeze_time 0
2022/05/17 09:57:25.090 BGP: bgp_get: Registering BGP instance (null) to zebra
2022/05/17 09:57:25.090 BGP: Registering VRF 0
2022/05/17 09:57:25.091 BGP: Rx Router Id update VRF 0 Id 10.131.0.1/32
2022/05/17 09:57:25.091 BGP: RID change : vrf VRF default(0), RTR ID 10.131.0.1
2022/05/17 09:57:25.091 BGP: Rx Intf add VRF 0 IF br0
2022/05/17 09:57:25.091 BGP: Rx Intf add VRF 0 IF ens4
2022/05/17 09:57:25.091 BGP: Rx Intf address add VRF 0 IF ens4 addr 10.0.128.4/32
2022/05/17 09:57:25.091 BGP: Rx Intf address add VRF 0 IF ens4 addr fe80::c9d:84da:4d86:5618/64
2022/05/17 09:57:25.091 BGP: Rx Intf add VRF 0 IF lo
2022/05/17 09:57:25.091 BGP: Rx Intf add VRF 0 IF ovs-system
2022/05/17 09:57:25.091 BGP: Rx Intf add VRF 0 IF tun0
2022/05/17 09:57:25.091 BGP: Rx Intf address add VRF 0 IF tun0 addr 10.131.0.1/23
2022/05/17 09:57:25.091 BGP: Rx Intf address add VRF 0 IF tun0 addr fe80::40f1:d1ff:feb6:5322/64
2022/05/17 09:57:25.091 BGP: Rx Intf add VRF 0 IF veth2da49fed
2022/05/17 09:57:25.091 BGP: Rx Intf address add VRF 0 IF veth2da49fed addr fe80::24bd:d1ff:fec1:d88/64
2022/05/17 09:57:25.091 BGP: Rx Intf add VRF 0 IF veth2fa08c8c
2022/05/17 09:57:25.091 BGP: Rx Intf address add VRF 0 IF veth2fa08c8c addr fe80::6870:ff:fe96:efc8/64
2022/05/17 09:57:25.091 BGP: Rx Intf add VRF 0 IF veth41e356b7
2022/05/17 09:57:25.091 BGP: Rx Intf address add VRF 0 IF veth41e356b7 addr fe80::48ff:37ff:fede:eb4b/64
2022/05/17 09:57:25.092 BGP: Rx Intf add VRF 0 IF veth1295c6e2
2022/05/17 09:57:25.092 BGP: Rx Intf address add VRF 0 IF veth1295c6e2 addr fe80::b827:a2ff:feed:637/64
2022/05/17 09:57:25.092 BGP: Rx Intf add VRF 0 IF veth9733c6dc
2022/05/17 09:57:25.092 BGP: Rx Intf address add VRF 0 IF veth9733c6dc addr fe80::3cf4:15ff:fe11:e541/64
2022/05/17 09:57:25.092 BGP: Rx Intf add VRF 0 IF veth336680ea
2022/05/17 09:57:25.092 BGP: Rx Intf address add VRF 0 IF veth336680ea addr fe80::94b1:8bff:fe7e:488c/64
2022/05/17 09:57:25.092 BGP: Rx Intf add VRF 0 IF vetha0a907b7
2022/05/17 09:57:25.092 BGP: Rx Intf address add VRF 0 IF vetha0a907b7 addr fe80::3855:a6ff:fe73:46c3/64
2022/05/17 09:57:25.092 BGP: Rx Intf add VRF 0 IF vethf35a4398
2022/05/17 09:57:25.092 BGP: Rx Intf address add VRF 0 IF vethf35a4398 addr fe80::40ef:2fff:fe57:4c4d/64
2022/05/17 09:57:25.092 BGP: Rx Intf add VRF 0 IF vethf831b7f4
2022/05/17 09:57:25.092 BGP: Rx Intf address add VRF 0 IF vethf831b7f4 addr fe80::f0d9:89ff:fe7c:1d32/64
2022/05/17 09:57:25.092 BGP: Rx Intf add VRF 0 IF vxlan_sys_4789
2022/05/17 09:57:25.092 BGP: Rx Intf address add VRF 0 IF vxlan_sys_4789 addr fe80::80c1:82ff:fe4b:f078/64
2022/05/17 09:57:26.094 BGP: 10.0.0.1 [FSM] Timer (start timer expire).
2022/05/17 09:57:26.094 BGP: 10.0.0.1 [FSM] BGP_Start (Idle->Connect), fd -1
2022/05/17 09:57:26.094 BGP: Allocated bnc 10.0.0.1/32(0)(VRF default) peer 0x7f807f7631a0
2022/05/17 09:57:26.094 BGP: sendmsg_zebra_rnh: sending cmd ZEBRA_NEXTHOP_REGISTER for 10.0.0.1/32 (vrf VRF default)
2022/05/17 09:57:26.094 BGP: 10.0.0.1 [FSM] Waiting for NHT
2022/05/17 09:57:26.094 BGP: bgp_fsm_change_status : vrf default(0), Status: Connect established_peers 0
2022/05/17 09:57:26.094 BGP: 10.0.0.1 went from Idle to Connect
2022/05/17 09:57:26.094 BGP: 10.0.0.1 [FSM] TCP_connection_open_failed (Connect->Active), fd -1
2022/05/17 09:57:26.094 BGP: bgp_fsm_change_status : vrf default(0), Status: Active established_peers 0
2022/05/17 09:57:26.094 BGP: 10.0.0.1 went from Connect to Active
2022/05/17 09:57:26.094 ZEBRA: rnh_register msg from client bgp: hdr->length=8, type=nexthop vrf=0
2022/05/17 09:57:26.094 ZEBRA: 0: Add RNH 10.0.0.1/32 type Nexthop
2022/05/17 09:57:26.094 ZEBRA: 0:10.0.0.1/32: Evaluate RNH, type Nexthop (force)
2022/05/17 09:57:26.094 ZEBRA: 0:10.0.0.1/32: NH has become unresolved
2022/05/17 09:57:26.094 ZEBRA: 0: Client bgp registers for RNH 10.0.0.1/32 type Nexthop
2022/05/17 09:57:26.094 BGP: VRF default(0): Rcvd NH update 10.0.0.1/32(0) - metric 0/0 #nhops 0/0 flags 0x6
2022/05/17 09:57:26.094 BGP: NH update for 10.0.0.1/32(0)(VRF default) - flags 0x6 chgflags 0x0 - evaluate paths
2022/05/17 09:57:26.094 BGP: evaluate_paths: Updating peer (10.0.0.1(VRF default)) status with NHT
2022/05/17 09:57:30.081 ZEBRA: Event driven route-map update triggered
2022/05/17 09:57:30.081 ZEBRA: Event handler for route-map: 10.0.0.1-out
2022/05/17 09:57:30.081 ZEBRA: Event handler for route-map: 10.0.0.1-in
2022/05/17 09:57:31.104 ZEBRA: netlink_parse_info: netlink-listen (NS 0) type RTM_NEWNEIGH(28), len=76, seq=0, pid=0
2022/05/17 09:57:31.104 ZEBRA: 	Neighbor Entry received is not on a VLAN or a BRIDGE, ignoring
2022/05/17 09:57:31.105 ZEBRA: netlink_parse_info: netlink-listen (NS 0) type RTM_NEWNEIGH(28), len=76, seq=0, pid=0
2022/05/17 09:57:31.105 ZEBRA: 	Neighbor Entry received is not on a VLAN or a BRIDGE, ignoring

Copy to Clipboard

Toggle word wrap

4.9.1.1. FRRouting(FRR) 로그 수준
링크 복사

다음 표에서는 FRR 로깅 수준을 설명합니다.

Expand

표 4.10. 로그 수준
로그 수준	설명
`all`	모든 로깅 수준에 대한 모든 로깅 정보를 제공합니다.
`debug`	사람들에게 진단적으로 도움이 되는 정보입니다. `디버그` 로 설정하면 자세한 문제 해결 정보를 제공합니다.
`info`	항상 기록되어야 하지만 일반적인 상황에서는 사용자 개입이 필요하지 않은 정보를 제공합니다. 이는 기본 로깅 수준입니다.
`warn`	`MetalLB의` 불일치한 동작을 잠재적으로 일으킬 수 있는 모든 사항. 일반적으로 `MetalLB는` 이러한 유형의 오류를 자동으로 복구합니다.
`error`	`MetalLB` 의 기능에 치명적인 오류입니다. 이러한 오류는 일반적으로 관리자의 개입이 필요합니다.
`none`	모든 로깅을 끕니다.

4.9.2. BGP 문제 해결
링크 복사

클러스터 관리자로서 BGP 구성 문제를 해결해야 하는 경우 FRR 컨테이너에서 명령을 실행해야 합니다.

사전 요구 사항

cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
OpenShift CLI(oc)가 설치되어 있습니다.

프로세스

다음 명령을 실행하여 frr-k8s 포드의 이름을 표시합니다.

oc -n metallb-system get pods -l component=frr-k8s

$ oc -n metallb-system get pods -l component=frr-k8s

Copy to Clipboard

Toggle word wrap

출력 예

NAME            READY   STATUS    RESTARTS   AGE
frr-k8s-thsmw   6/6     Running   0          109m

NAME            READY   STATUS    RESTARTS   AGE
frr-k8s-thsmw   6/6     Running   0          109m

Copy to Clipboard

Toggle word wrap

다음 명령을 실행하여 FRR의 실행 구성을 표시합니다.

oc exec -n metallb-system frr-k8s-thsmw -c frr -- vtysh -c "show running-config"

$ oc exec -n metallb-system frr-k8s-thsmw -c frr -- vtysh -c "show running-config"

Copy to Clipboard

Toggle word wrap

출력 예

Building configuration...

Current configuration:
!
frr version 8.5.3
frr defaults traditional
hostname some-hostname
log file /etc/frr/frr.log informational
log timestamp precision 3
no ip forwarding
no ipv6 forwarding
service integrated-vtysh-config
!
router bgp 64500  
 bgp router-id 10.0.1.2
 no bgp ebgp-requires-policy
 no bgp default ipv4-unicast
 no bgp network import-check
 neighbor 10.0.2.3 remote-as 64500  
 neighbor 10.0.2.3 bfd profile doc-example-bfd-profile-full  
 neighbor 10.0.2.3 timers 5 15
 neighbor 10.0.2.4 remote-as 64500
 neighbor 10.0.2.4 bfd profile doc-example-bfd-profile-full
 neighbor 10.0.2.4 timers 5 15
 !
 address-family ipv4 unicast
  network 203.0.113.200/30   
  neighbor 10.0.2.3 activate
  neighbor 10.0.2.3 route-map 10.0.2.3-in in
  neighbor 10.0.2.4 activate
  neighbor 10.0.2.4 route-map 10.0.2.4-in in
 exit-address-family
 !
 address-family ipv6 unicast
  network fc00:f853:ccd:e799::/124
  neighbor 10.0.2.3 activate
  neighbor 10.0.2.3 route-map 10.0.2.3-in in
  neighbor 10.0.2.4 activate
  neighbor 10.0.2.4 route-map 10.0.2.4-in in
 exit-address-family
!
route-map 10.0.2.3-in deny 20
!
route-map 10.0.2.4-in deny 20
!
ip nht resolve-via-default
!
ipv6 nht resolve-via-default
!
line vty
!
bfd
 profile doc-example-bfd-profile-full
  transmit-interval 35
  receive-interval 35
  passive-mode
  echo-mode
  echo-interval 35
  minimum-ttl 10
 !
!
end

Building configuration...

Current configuration:
!
frr version 8.5.3
frr defaults traditional
hostname some-hostname
log file /etc/frr/frr.log informational
log timestamp precision 3
no ip forwarding
no ipv6 forwarding
service integrated-vtysh-config
!
router bgp 64500


 bgp router-id 10.0.1.2
 no bgp ebgp-requires-policy
 no bgp default ipv4-unicast
 no bgp network import-check
 neighbor 10.0.2.3 remote-as 64500


 neighbor 10.0.2.3 bfd profile doc-example-bfd-profile-full


 neighbor 10.0.2.3 timers 5 15
 neighbor 10.0.2.4 remote-as 64500
 neighbor 10.0.2.4 bfd profile doc-example-bfd-profile-full
 neighbor 10.0.2.4 timers 5 15
 !
 address-family ipv4 unicast
  network 203.0.113.200/30


  neighbor 10.0.2.3 activate
  neighbor 10.0.2.3 route-map 10.0.2.3-in in
  neighbor 10.0.2.4 activate
  neighbor 10.0.2.4 route-map 10.0.2.4-in in
 exit-address-family
 !
 address-family ipv6 unicast
  network fc00:f853:ccd:e799::/124
  neighbor 10.0.2.3 activate
  neighbor 10.0.2.3 route-map 10.0.2.3-in in
  neighbor 10.0.2.4 activate
  neighbor 10.0.2.4 route-map 10.0.2.4-in in
 exit-address-family
!
route-map 10.0.2.3-in deny 20
!
route-map 10.0.2.4-in deny 20
!
ip nht resolve-via-default
!
ipv6 nht resolve-via-default
!
line vty
!
bfd
 profile doc-example-bfd-profile-full
  transmit-interval 35
  receive-interval 35
  passive-mode
  echo-mode
  echo-interval 35
  minimum-ttl 10
 !
!
end

Copy to Clipboard

Toggle word wrap

1: 라우터 bgp 섹션은 MetalLB의 ASN을 나타냅니다.
2: 추가한 각 BGP 피어 사용자 정의 리소스에 대해 neighbor <ip-address> remote-as <peer-ASN> 라인이 있는지 확인하세요.
3: BFD를 구성한 경우 BFD 프로필이 올바른 BGP 피어와 연결되어 있고 BFD 프로필이 명령 출력에 나타나는지 확인합니다.
4: 네트워크 <ip-address-range> 줄이 추가한 주소 풀 사용자 지정 리소스에 지정한 IP 주소 범위와 일치하는지 확인하세요.

다음 명령을 실행하여 BGP 요약을 표시합니다.

oc exec -n metallb-system frr-k8s-thsmw -c frr -- vtysh -c "show bgp summary"

$ oc exec -n metallb-system frr-k8s-thsmw -c frr -- vtysh -c "show bgp summary"

Copy to Clipboard

Toggle word wrap

출력 예

IPv4 Unicast Summary:
BGP router identifier 10.0.1.2, local AS number 64500 vrf-id 0
BGP table version 1
RIB entries 1, using 192 bytes of memory
Peers 2, using 29 KiB of memory

Neighbor        V         AS   MsgRcvd   MsgSent   TblVer  InQ OutQ  Up/Down State/PfxRcd   PfxSnt
10.0.2.3        4      64500       387       389        0    0    0 00:32:02            0        1  
10.0.2.4        4      64500         0         0        0    0    0    never       Active        0  

Total number of neighbors 2

IPv6 Unicast Summary:
BGP router identifier 10.0.1.2, local AS number 64500 vrf-id 0
BGP table version 1
RIB entries 1, using 192 bytes of memory
Peers 2, using 29 KiB of memory

Neighbor        V         AS   MsgRcvd   MsgSent   TblVer  InQ OutQ  Up/Down State/PfxRcd   PfxSnt
10.0.2.3        4      64500       387       389        0    0    0 00:32:02 NoNeg
10.0.2.4        4      64500         0         0        0    0    0    never       Active        0

Total number of neighbors 2

IPv4 Unicast Summary:
BGP router identifier 10.0.1.2, local AS number 64500 vrf-id 0
BGP table version 1
RIB entries 1, using 192 bytes of memory
Peers 2, using 29 KiB of memory

Neighbor        V         AS   MsgRcvd   MsgSent   TblVer  InQ OutQ  Up/Down State/PfxRcd   PfxSnt
10.0.2.3        4      64500       387       389        0    0    0 00:32:02            0        1


10.0.2.4        4      64500         0         0        0    0    0    never       Active        0



Total number of neighbors 2

IPv6 Unicast Summary:
BGP router identifier 10.0.1.2, local AS number 64500 vrf-id 0
BGP table version 1
RIB entries 1, using 192 bytes of memory
Peers 2, using 29 KiB of memory

Neighbor        V         AS   MsgRcvd   MsgSent   TblVer  InQ OutQ  Up/Down State/PfxRcd   PfxSnt
10.0.2.3        4      64500       387       389        0    0    0 00:32:02 NoNeg
10.0.2.4        4      64500         0         0        0    0    0    never       Active        0

Total number of neighbors 2

Copy to Clipboard

Toggle word wrap

1: 추가한 각 BGP 피어 사용자 정의 리소스에 대한 줄이 출력에 포함되어 있는지 확인하세요.
2: 수신된 메시지와 전송된 메시지가 0개 라는 출력은 BGP 세션이 없는 BGP 피어를 나타냅니다. 네트워크 연결과 BGP 피어의 BGP 구성을 확인하세요.

다음 명령을 실행하여 주소 풀을 수신한 BGP 피어를 표시합니다.

oc exec -n metallb-system frr-k8s-thsmw -c frr -- vtysh -c "show bgp ipv4 unicast 203.0.113.200/30"

$ oc exec -n metallb-system frr-k8s-thsmw -c frr -- vtysh -c "show bgp ipv4 unicast 203.0.113.200/30"

Copy to Clipboard

Toggle word wrap

IPv6 주소 풀을 수신한 BGP 피어를 표시하려면 ipv4를 ipv6 로 바꾸세요. 203.0.113.200/30을 주소 풀의 IPv4 또는 IPv6 IP 주소 범위로 바꿉니다.

출력 예

BGP routing table entry for 203.0.113.200/30
Paths: (1 available, best #1, table default)
  Advertised to non peer-group peers:
  10.0.2.3  
  Local
    0.0.0.0 from 0.0.0.0 (10.0.1.2)
      Origin IGP, metric 0, weight 32768, valid, sourced, local, best (First path received)
      Last update: Mon Jan 10 19:49:07 2022

BGP routing table entry for 203.0.113.200/30
Paths: (1 available, best #1, table default)
  Advertised to non peer-group peers:
  10.0.2.3


  Local
    0.0.0.0 from 0.0.0.0 (10.0.1.2)
      Origin IGP, metric 0, weight 32768, valid, sourced, local, best (First path received)
      Last update: Mon Jan 10 19:49:07 2022

Copy to Clipboard

Toggle word wrap

1: 출력에 BGP 피어의 IP 주소가 포함되어 있는지 확인하세요.

4.9.3. BFD 문제 해결
링크 복사

Red Hat이 지원하는 양방향 전달 감지(BFD) 구현은 스피커 포드의 컨테이너에서 FRRouting(FRR)을 사용합니다. BFD 구현은 BGP 세션이 설정된 BGP 피어로 구성된 BFD 피어에도 의존합니다. 클러스터 관리자로서 BFD 구성 문제를 해결해야 하는 경우 FRR 컨테이너에서 명령을 실행해야 합니다.

사전 요구 사항

cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
OpenShift CLI(oc)가 설치되어 있습니다.

프로세스

스피커 포드의 이름을 표시합니다.

oc get -n metallb-system pods -l component=speaker

$ oc get -n metallb-system pods -l component=speaker

Copy to Clipboard

Toggle word wrap

출력 예

NAME            READY   STATUS    RESTARTS   AGE
speaker-66bth   4/4     Running   0          26m
speaker-gvfnf   4/4     Running   0          26m
...

NAME            READY   STATUS    RESTARTS   AGE
speaker-66bth   4/4     Running   0          26m
speaker-gvfnf   4/4     Running   0          26m
...

Copy to Clipboard

Toggle word wrap

BFD 피어 표시:

oc exec -n metallb-system speaker-66bth -c frr -- vtysh -c "show bfd peers brief"

$ oc exec -n metallb-system speaker-66bth -c frr -- vtysh -c "show bfd peers brief"

Copy to Clipboard

Toggle word wrap

출력 예

Session count: 2
SessionId  LocalAddress              PeerAddress              Status
=========  ============              ===========              ======
3909139637 10.0.1.2                  10.0.2.3                 up  <.>

Session count: 2
SessionId  LocalAddress              PeerAddress              Status
=========  ============              ===========              ======
3909139637 10.0.1.2                  10.0.2.3                 up  <.>

Copy to Clipboard

Toggle word wrap

<.> PeerAddress 열에 각 BFD 피어가 포함되어 있는지 확인합니다. 출력에 예상한 BFD 피어 IP 주소가 나열되지 않으면 피어와의 BGP 연결 문제를 해결하세요. 상태 필드에 다운이 표시되면 노드와 피어 사이의 링크와 장비의 연결을 확인하세요. oc get pods -n metallb-system speaker-66bth -o jsonpath='{.spec.nodeName}' 와 같은 명령을 사용하면 스피커 포드의 노드 이름을 확인할 수 있습니다.

4.9.4. BGP 및 BFD에 대한 MetalLB 메트릭
링크 복사

OpenShift Container Platform은 BGP 피어 및 BFD 프로필과 관련된 MetalLB에 대한 다음과 같은 Prometheus 메트릭을 캡처합니다.

Expand

표 4.11. MetalLB BFD 메트릭
이름	설명
`frrk8s_bfd_control_packet_input`	각 BFD 피어로부터 수신된 BFD 제어 패킷의 수를 계산합니다.
`frrk8s_bfd_control_packet_output`	각 BFD 피어에 전송된 BFD 제어 패킷의 수를 계산합니다.
`frrk8s_bfd_echo_packet_input`	각 BFD 피어로부터 수신된 BFD 에코 패킷의 수를 계산합니다.
`frrk8s_bfd_echo_packet_output`	각 BFD에 전송된 BFD 에코 패킷의 수를 계산합니다.
`frrk8s_bfd_session_down_events`	피어와의 BFD 세션이 `다운` 상태로 전환된 횟수를 계산합니다.
`frrk8s_bfd_session_up`	BFD 피어와의 연결 상태를 나타냅니다. `1은` 세션이 `작동 중임` 을 나타내고, `0은` 세션이 `종료` 되었음을 나타냅니다.
`frrk8s_bfd_session_up_events`	피어와의 BFD 세션이 `업` 상태로 전환된 횟수를 계산합니다.
`frrk8s_bfd_zebra_notifications`	각 BFD 피어에 대한 BFD Zebra 알림 수를 계산합니다.

Expand

표 4.12. MetalLB BGP 메트릭
이름	설명
`frrk8s_bgp_announced_prefixes_total`	BGP 피어에 광고되는 로드 밸런서 IP 주소 접두사의 수를 계산합니다. 접두사 및 집계 경로라는 용어는 동일한 의미를 갖습니다.
`frrk8s_bgp_session_up`	BGP 피어와의 연결 상태를 나타냅니다. `1은` 세션이 `작동 중임` 을 나타내고, `0은` 세션이 `종료` 되었음을 나타냅니다.
`frrk8s_bgp_updates_total`	각 BGP 피어에 전송된 BGP 업데이트 메시지 수를 계산합니다.
`frrk8s_bgp_opens_sent`	각 BGP 피어에 전송된 BGP 오픈 메시지 수를 계산합니다.
`frrk8s_bgp_opens_received`	각 BGP 피어로부터 수신된 BGP 오픈 메시지 수를 계산합니다.
`frrk8s_bgp_notifications_sent`	각 BGP 피어에 전송된 BGP 알림 메시지의 수를 계산합니다.
`frrk8s_bgp_updates_total_received`	각 BGP 피어로부터 수신된 BGP 업데이트 메시지 수를 계산합니다.
`frrk8s_bgp_keepalives_sent`	각 BGP 피어에 전송된 BGP keepalive 메시지의 수를 계산합니다.
`frrk8s_bgp_keepalives_received`	각 BGP 피어로부터 수신된 BGP keepalive 메시지의 수를 계산합니다.
`frrk8s_bgp_route_refresh_sent`	각 BGP 피어에 전송된 BGP 경로 새로 고침 메시지 수를 계산합니다.
`frrk8s_bgp_total_sent`	각 BGP 피어에 전송된 총 BGP 메시지 수를 계산합니다.
`frrk8s_bgp_total_received`	각 BGP 피어로부터 수신된 총 BGP 메시지 수를 계산합니다.

추가 리소스

모니터링 대시보드를 사용하는 방법에 대한 자세한 내용은 모니터링 대시보드를 사용하여 모든 프로젝트의 메트릭 쿼리를 참조하세요.

4.9.5. MetalLB 데이터 수집에 관하여
링크 복사

oc adm must-gather CLI 명령을 사용하면 클러스터, MetalLB 구성 및 MetalLB Operator에 대한 정보를 수집할 수 있습니다. 다음 기능과 객체는 MetalLB 및 MetalLB Operator와 연관되어 있습니다.

MetalLB Operator가 배포되는 네임스페이스 및 자식 개체
모든 MetalLB 운영자 사용자 정의 리소스 정의(CRD)

oc adm must-gather CLI 명령은 Red Hat이 BGP 및 BFD를 구현하는 데 사용하는 FRRouting(FRR)에서 다음 정보를 수집합니다.

/etc/frr/frr.conf
/etc/frr/frr.log
/etc/frr/daemons 구성 파일
/etc/frr/vtysh.conf

이전 목록의 로그 및 구성 파일은 각 스피커 포드의 frr 컨테이너에서 수집됩니다.

로그 및 구성 파일 외에도 oc adm must-gather CLI 명령은 다음 vtysh 명령의 출력을 수집합니다.

show running-config
show bgp ipv4
bgp ipv6 표시
bgp 이웃 표시
BFD 피어 표시

oc adm must-gather CLI 명령을 실행할 때 추가 구성은 필요하지 않습니다.

추가 리소스

클러스터에 대한 데이터 수집

Legal Notice
링크 복사

OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).

Modified versions must remove all Red Hat trademarks.

Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.

Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.

Linux® is the registered trademark of Linus Torvalds in the United States and other countries.

Java® is a registered trademark of Oracle and/or its affiliates.

XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.

MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.

Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.

The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.

All other trademarks are the property of their respective owners.

맨 위로 이동

수신 및 부하 분산

OpenShift Container Platform에서 서비스 노출 및 외부 트래픽 관리

1장. 경로 구성링크 복사링크가 클립보드에 복사되었습니다!

1.1. 경로 구성링크 복사링크가 클립보드에 복사되었습니다!

1.1.1. HTTP 기반 경로 생성링크 복사링크가 클립보드에 복사되었습니다!

1.1.2. Ingress Controller 샤딩을 위한 경로 생성링크 복사링크가 클립보드에 복사되었습니다!

1.1.3. 경로 시간 초과 구성링크 복사링크가 클립보드에 복사되었습니다!

1.1.4. HSTS(HTTP Strict Transport Security)링크 복사링크가 클립보드에 복사되었습니다!

1.1.4.1. 라우팅당 HSTS(HTTP Strict Transport Security) 활성화링크 복사링크가 클립보드에 복사되었습니다!

1.1.4.2. 라우팅당 HSTS(HTTP Strict Transport Security) 비활성화링크 복사링크가 클립보드에 복사되었습니다!

1.1.4.3. 도메인별 HSTS(HTTP Strict Transport Security) 적용링크 복사링크가 클립보드에 복사되었습니다!

1.1.5. 처리량 문제 해결 방법링크 복사링크가 클립보드에 복사되었습니다!

1.1.6. 쿠키를 사용하여 경로 상태 유지링크 복사링크가 클립보드에 복사되었습니다!

1.1.6.1. 쿠키를 사용하여 경로에 주석 달기링크 복사링크가 클립보드에 복사되었습니다!

1.1.7. 경로 기반 라우터링크 복사링크가 클립보드에 복사되었습니다!

1.1.8. HTTP 헤더 구성링크 복사링크가 클립보드에 복사되었습니다!

1.1.8.1. 우선순위링크 복사링크가 클립보드에 복사되었습니다!

1.1.8.2. 특수 케이스 헤더링크 복사링크가 클립보드에 복사되었습니다!

1.1.9. 경로에서 HTTP 요청 및 응답 헤더 설정 또는 삭제링크 복사링크가 클립보드에 복사되었습니다!

1.1.10. 경로별 주석링크 복사링크가 클립보드에 복사되었습니다!

1.1.11. 경로 허용 정책 구성링크 복사링크가 클립보드에 복사되었습니다!

1.1.12. Ingress 오브젝트를 통해 경로 생성링크 복사링크가 클립보드에 복사되었습니다!

1.1.13. Ingress 객체를 통해 기본 인증서를 사용하여 경로 생성링크 복사링크가 클립보드에 복사되었습니다!

1.1.14. Ingress 주석에서 대상 CA 인증서를 사용하여 경로 생성링크 복사링크가 클립보드에 복사되었습니다!

1.1.15. 듀얼 스택 네트워킹을 위한 OpenShift Container Platform Ingress 컨트롤러 구성링크 복사링크가 클립보드에 복사되었습니다!

1.2. 보안 경로링크 복사링크가 클립보드에 복사되었습니다!

1.2.1. 사용자 정의 인증서를 사용하여 재암호화 경로 생성링크 복사링크가 클립보드에 복사되었습니다!

1.2.2. 사용자 정의 인증서를 사용하여 엣지 경로 생성링크 복사링크가 클립보드에 복사되었습니다!

1.2.3. 패스스루 라우팅 생성링크 복사링크가 클립보드에 복사되었습니다!

1.2.4. 외부 관리 인증서를 사용하여 경로 생성링크 복사링크가 클립보드에 복사되었습니다!

2장. 수신 클러스터 트래픽 구성링크 복사링크가 클립보드에 복사되었습니다!

2.1. 수신 클러스터 트래픽 구성 개요링크 복사링크가 클립보드에 복사되었습니다!

2.1.1. 비교: 외부 IP 주소에 대한 내결함성 액세스링크 복사링크가 클립보드에 복사되었습니다!

2.2. 서비스의 ExternalIP 구성링크 복사링크가 클립보드에 복사되었습니다!

2.2.1. 사전 요구 사항링크 복사링크가 클립보드에 복사되었습니다!

2.2.2. ExternalIP 정보링크 복사링크가 클립보드에 복사되었습니다!

2.2.3. ExternalIP 구성링크 복사링크가 클립보드에 복사되었습니다!

2.2.4. 외부 IP 주소 할당 제한 사항링크 복사링크가 클립보드에 복사되었습니다!

2.2.5. 정책 오브젝트의 예링크 복사링크가 클립보드에 복사되었습니다!

2.2.6. ExternalIP 주소 블록 구성링크 복사링크가 클립보드에 복사되었습니다!

외부 IP 구성의 예

2.2.7. 클러스터에 대한 외부 IP 주소 블록 구성링크 복사링크가 클립보드에 복사되었습니다!

2.2.9. 다음 단계링크 복사링크가 클립보드에 복사되었습니다!

2.3. Ingress 컨트롤러를 사용한 수신 클러스터 트래픽 구성링크 복사링크가 클립보드에 복사되었습니다!

2.3.1. Ingress 컨트롤러 및 경로 사용링크 복사링크가 클립보드에 복사되었습니다!

2.3.2. 사전 요구 사항링크 복사링크가 클립보드에 복사되었습니다!

2.3.3. 프로젝트 및 서비스 생성링크 복사링크가 클립보드에 복사되었습니다!

2.3.4. 경로를 생성하여 서비스 노출링크 복사링크가 클립보드에 복사되었습니다!

2.3.5. OpenShift 컨테이너 플랫폼의 Ingress 샤딩링크 복사링크가 클립보드에 복사되었습니다!

2.3.6. Ingress 컨트롤러 분할링크 복사링크가 클립보드에 복사되었습니다!

2.3.6.1. 기존 샤딩 예시링크 복사링크가 클립보드에 복사되었습니다!

2.3.6.2. 중첩된 샤딩 예제링크 복사링크가 클립보드에 복사되었습니다!

2.3.6.3. 기본 Ingress 컨트롤러 분할링크 복사링크가 클립보드에 복사되었습니다!

2.3.6.4. Ingress 샤딩 및 DNS링크 복사링크가 클립보드에 복사되었습니다!

2.3.6.5. 경로 라벨을 사용하여 Ingress 컨트롤러 분할 구성링크 복사링크가 클립보드에 복사되었습니다!

2.3.6.6. 네임스페이스 라벨을 사용하여 Ingress 컨트롤러 분할 구성링크 복사링크가 클립보드에 복사되었습니다!

2.3.6.7. Ingress Controller 샤딩을 위한 경로 생성링크 복사링크가 클립보드에 복사되었습니다!

추가 리소스

2.4. Ingress Controller 엔드포인트 게시 전략 구성링크 복사링크가 클립보드에 복사되었습니다!

2.4.1. Ingress Controller 엔드포인트 게시 전략링크 복사링크가 클립보드에 복사되었습니다!

2.4.1.1. Ingress 컨트롤러 끝점에서 내부로 게시 범위 구성링크 복사링크가 클립보드에 복사되었습니다!

2.4.1.2. Ingress Controller 엔드포인트 게시 범위를 외부로 구성링크 복사링크가 클립보드에 복사되었습니다!

2.4.1.3. Ingress Controller에 단일 NodePort 서비스 추가링크 복사링크가 클립보드에 복사되었습니다!

2.5. 로드 밸런서를 사용하여 수신 클러스터 트래픽 구성링크 복사링크가 클립보드에 복사되었습니다!

2.5.1. 로드 밸런서를 사용하여 클러스터로 트래픽 가져오기링크 복사링크가 클립보드에 복사되었습니다!

2.5.2. 사전 요구 사항링크 복사링크가 클립보드에 복사되었습니다!

2.5.3. 프로젝트 및 서비스 생성링크 복사링크가 클립보드에 복사되었습니다!

2.5.4. 경로를 생성하여 서비스 노출링크 복사링크가 클립보드에 복사되었습니다!

2.5.5. 로드 밸런서 서비스 생성링크 복사링크가 클립보드에 복사되었습니다!

2.6. AWS에서 인그레스 클러스터 트래픽 구성링크 복사링크가 클립보드에 복사되었습니다!

2.6.1. AWS에서 Classic Load Balancer 시간 초과 구성링크 복사링크가 클립보드에 복사되었습니다!

2.6.1.1. 경로 시간 초과 구성링크 복사링크가 클립보드에 복사되었습니다!

2.6.1.2. Classic Load Balancer 시간 초과 구성링크 복사링크가 클립보드에 복사되었습니다!

2.6.2. 네트워크 로드 밸런서를 사용하여 AWS에서 수신 클러스터 트래픽 구성링크 복사링크가 클립보드에 복사되었습니다!

2.6.2.1. 클래식 로드 밸런서를 사용하는 Ingress 컨트롤러를 네트워크 로드 밸런서로 전환링크 복사링크가 클립보드에 복사되었습니다!

2.6.2.2. 네트워크 로드 밸런서를 사용하는 Ingress 컨트롤러를 클래식 로드 밸런서로 전환링크 복사링크가 클립보드에 복사되었습니다!

2.6.2.3. Ingress Controller Classic Load Balancer를 Network Load Balancer로 교체링크 복사링크가 클립보드에 복사되었습니다!

2.6.2.4. 기존 AWS 클러스터에서 Ingress 컨트롤러 네트워크 로드 밸런서 생성링크 복사링크가 클립보드에 복사되었습니다!

2.6.2.5. 새 AWS 클러스터에서 Ingress 컨트롤러 네트워크 로드 밸런서 생성링크 복사링크가 클립보드에 복사되었습니다!

2.6.2.6. LoadBalancerService Ingress Controller를 생성하는 동안 서브넷 선택링크 복사링크가 클립보드에 복사되었습니다!

1장. 경로 구성
링크 복사

1.1. 경로 구성
링크 복사

1.1.1. HTTP 기반 경로 생성
링크 복사

1.1.2. Ingress Controller 샤딩을 위한 경로 생성
링크 복사

1.1.3. 경로 시간 초과 구성
링크 복사

1.1.4. HSTS(HTTP Strict Transport Security)
링크 복사

1.1.4.1. 라우팅당 HSTS(HTTP Strict Transport Security) 활성화
링크 복사

1.1.4.2. 라우팅당 HSTS(HTTP Strict Transport Security) 비활성화
링크 복사

1.1.4.3. 도메인별 HSTS(HTTP Strict Transport Security) 적용
링크 복사

1.1.5. 처리량 문제 해결 방법
링크 복사

1.1.6. 쿠키를 사용하여 경로 상태 유지
링크 복사

1.1.6.1. 쿠키를 사용하여 경로에 주석 달기
링크 복사

1.1.7. 경로 기반 라우터
링크 복사

1.1.8. HTTP 헤더 구성
링크 복사

1.1.8.1. 우선순위
링크 복사

1.1.8.2. 특수 케이스 헤더
링크 복사

1.1.9. 경로에서 HTTP 요청 및 응답 헤더 설정 또는 삭제
링크 복사

1.1.10. 경로별 주석
링크 복사

1.1.11. 경로 허용 정책 구성
링크 복사

1.1.12. Ingress 오브젝트를 통해 경로 생성
링크 복사

1.1.13. Ingress 객체를 통해 기본 인증서를 사용하여 경로 생성
링크 복사

1.1.14. Ingress 주석에서 대상 CA 인증서를 사용하여 경로 생성
링크 복사

1.1.15. 듀얼 스택 네트워킹을 위한 OpenShift Container Platform Ingress 컨트롤러 구성
링크 복사

1.2. 보안 경로
링크 복사

1.2.1. 사용자 정의 인증서를 사용하여 재암호화 경로 생성
링크 복사

1.2.2. 사용자 정의 인증서를 사용하여 엣지 경로 생성
링크 복사

1.2.3. 패스스루 라우팅 생성
링크 복사

1.2.4. 외부 관리 인증서를 사용하여 경로 생성
링크 복사

2장. 수신 클러스터 트래픽 구성
링크 복사

2.1. 수신 클러스터 트래픽 구성 개요
링크 복사

2.1.1. 비교: 외부 IP 주소에 대한 내결함성 액세스
링크 복사

2.2. 서비스의 ExternalIP 구성
링크 복사

2.2.1. 사전 요구 사항
링크 복사

2.2.2. ExternalIP 정보
링크 복사

2.2.3. ExternalIP 구성
링크 복사

2.2.4. 외부 IP 주소 할당 제한 사항
링크 복사

2.2.5. 정책 오브젝트의 예
링크 복사

2.2.6. ExternalIP 주소 블록 구성
링크 복사

2.2.7. 클러스터에 대한 외부 IP 주소 블록 구성
링크 복사

2.2.9. 다음 단계
링크 복사

2.3. Ingress 컨트롤러를 사용한 수신 클러스터 트래픽 구성
링크 복사

2.3.1. Ingress 컨트롤러 및 경로 사용
링크 복사

2.3.2. 사전 요구 사항
링크 복사

2.3.3. 프로젝트 및 서비스 생성
링크 복사

2.3.4. 경로를 생성하여 서비스 노출
링크 복사

2.3.5. OpenShift 컨테이너 플랫폼의 Ingress 샤딩
링크 복사

2.3.6. Ingress 컨트롤러 분할
링크 복사

2.3.6.1. 기존 샤딩 예시
링크 복사

2.3.6.2. 중첩된 샤딩 예제
링크 복사

2.3.6.3. 기본 Ingress 컨트롤러 분할
링크 복사

2.3.6.4. Ingress 샤딩 및 DNS
링크 복사

2.3.6.5. 경로 라벨을 사용하여 Ingress 컨트롤러 분할 구성
링크 복사

2.3.6.6. 네임스페이스 라벨을 사용하여 Ingress 컨트롤러 분할 구성
링크 복사

2.3.6.7. Ingress Controller 샤딩을 위한 경로 생성
링크 복사

2.4. Ingress Controller 엔드포인트 게시 전략 구성
링크 복사

2.4.1. Ingress Controller 엔드포인트 게시 전략
링크 복사

2.4.1.1. Ingress 컨트롤러 끝점에서 내부로 게시 범위 구성
링크 복사

2.4.1.2. Ingress Controller 엔드포인트 게시 범위를 외부로 구성
링크 복사

2.4.1.3. Ingress Controller에 단일 NodePort 서비스 추가
링크 복사

2.5. 로드 밸런서를 사용하여 수신 클러스터 트래픽 구성
링크 복사

2.5.1. 로드 밸런서를 사용하여 클러스터로 트래픽 가져오기
링크 복사

2.5.2. 사전 요구 사항
링크 복사

2.5.3. 프로젝트 및 서비스 생성
링크 복사

2.5.4. 경로를 생성하여 서비스 노출
링크 복사

2.5.5. 로드 밸런서 서비스 생성
링크 복사

2.6. AWS에서 인그레스 클러스터 트래픽 구성
링크 복사

2.6.1. AWS에서 Classic Load Balancer 시간 초과 구성
링크 복사

2.6.1.1. 경로 시간 초과 구성
링크 복사

2.6.1.2. Classic Load Balancer 시간 초과 구성
링크 복사

2.6.2. 네트워크 로드 밸런서를 사용하여 AWS에서 수신 클러스터 트래픽 구성
링크 복사

2.6.2.1. 클래식 로드 밸런서를 사용하는 Ingress 컨트롤러를 네트워크 로드 밸런서로 전환
링크 복사

2.6.2.2. 네트워크 로드 밸런서를 사용하는 Ingress 컨트롤러를 클래식 로드 밸런서로 전환
링크 복사

2.6.2.3. Ingress Controller Classic Load Balancer를 Network Load Balancer로 교체
링크 복사

2.6.2.4. 기존 AWS 클러스터에서 Ingress 컨트롤러 네트워크 로드 밸런서 생성
링크 복사

2.6.2.5. 새 AWS 클러스터에서 Ingress 컨트롤러 네트워크 로드 밸런서 생성
링크 복사

2.6.2.6. LoadBalancerService Ingress Controller를 생성하는 동안 서브넷 선택
링크 복사

2.6.2.7. 기존 Ingress 컨트롤러의 서브넷 업데이트
링크 복사

2.6.2.8. 네트워크 로드 밸런서(NLB)에 대한 AWS Elastic IP(EIP) 주소 구성
링크 복사

2.7. 서비스 외부 IP에 대한 수신 클러스터 트래픽 구성
링크 복사

2.7.1. 사전 요구 사항
링크 복사