네트워킹

TLS 보안 프로필 유형(Old,Intermediate 또는 Custom)을 지정합니다. 기본값은 Intermediate입니다.

선택한 유형의 적절한 필드를 지정합니다.

old: {}
intermediate: {}
custom:

custom 유형의 경우 TLS 암호화 목록 및 최소 허용된 TLS 버전을 지정합니다.

파일을 저장하여 변경 사항을 적용합니다.

검증

IngressController CR에 프로파일이 설정되어 있는지 확인합니다.

oc describe IngressController default -n openshift-ingress-operator

$ oc describe IngressController default -n openshift-ingress-operator

Copy to Clipboard

Toggle word wrap

출력 예

Name:         default
Namespace:    openshift-ingress-operator
Labels:       <none>
Annotations:  <none>
API Version:  operator.openshift.io/v1
Kind:         IngressController
 ...
Spec:
 ...
  Tls Security Profile:
    Custom:
      Ciphers:
        ECDHE-ECDSA-CHACHA20-POLY1305
        ECDHE-RSA-CHACHA20-POLY1305
        ECDHE-RSA-AES128-GCM-SHA256
        ECDHE-ECDSA-AES128-GCM-SHA256
      Min TLS Version:  VersionTLS11
    Type:               Custom
 ...

Name:         default
Namespace:    openshift-ingress-operator
Labels:       <none>
Annotations:  <none>
API Version:  operator.openshift.io/v1
Kind:         IngressController
 ...
Spec:
 ...
  Tls Security Profile:
    Custom:
      Ciphers:
        ECDHE-ECDSA-CHACHA20-POLY1305
        ECDHE-RSA-CHACHA20-POLY1305
        ECDHE-RSA-AES128-GCM-SHA256
        ECDHE-ECDSA-AES128-GCM-SHA256
      Min TLS Version:  VersionTLS11
    Type:               Custom
 ...

Copy to Clipboard

Toggle word wrap

6.3.1.3. 상호 TLS 인증 구성
링크 복사

spec.clientTLS 값을 설정하여 mTLS(mTLS) 인증을 사용하도록 Ingress 컨트롤러를 구성할 수 있습니다. clientTLS 값은 클라이언트 인증서를 확인하도록 Ingress 컨트롤러를 구성합니다. 이 구성에는 구성 맵에 대한 참조인 clientCA 값 설정이 포함됩니다. 구성 맵에는 클라이언트의 인증서를 확인하는 데 사용되는 PEM 인코딩 CA 인증서 번들이 포함되어 있습니다. 필요한 경우 인증서 제목 필터 목록을 구성할 수 있습니다.

clientCA 값이 X509v3 인증서 취소 목록(CRL) 배포 지점을 지정하는 경우 Ingress Operator는 CRL을 다운로드하고 이를 승인하도록 Ingress 컨트롤러를 구성합니다. 유효한 인증서를 제공하지 않는 요청은 거부됩니다.

사전 요구 사항

cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.

절차

openshift-config 네임스페이스에 있는 구성 맵을 생성합니다.
```
oc create configmap router-ca-certs-default --from-file=ca-bundle.pem=client-ca.crt -n openshift-config
```
```
$ oc create configmap router-ca-certs-default --from-file=ca-bundle.pem=client-ca.crt -n openshift-config
```
Copy to Clipboard Toggle word wrap
참고
구성 맵 데이터 키는 ca-bundle.pem이어야 하며 데이터 값은 PEM 형식의 CA 인증서여야 합니다.
openshift-ingress-operator 프로젝트에서 IngressController 리소스를 편집합니다.
```
oc edit IngressController default -n openshift-ingress-operator
```
```
$ oc edit IngressController default -n openshift-ingress-operator
```
Copy to Clipboard Toggle word wrap

spec.clientTLS 필드 및 하위 필드를 추가하여 상호 TLS를 구성합니다.

패턴 필터링을 지정하는 clientTLS 프로필에 대한 IngressController CR 샘플

  apiVersion: operator.openshift.io/v1
  kind: IngressController
  metadata:
    name: default
    namespace: openshift-ingress-operator
  spec:
    clientTLS:
      clientCertificatePolicy: Required
      clientCA:
        name: router-ca-certs-default
      allowedSubjectPatterns:
      - "^/CN=example.com/ST=NC/C=US/O=Security/OU=OpenShift$"

  apiVersion: operator.openshift.io/v1
  kind: IngressController
  metadata:
    name: default
    namespace: openshift-ingress-operator
  spec:
    clientTLS:
      clientCertificatePolicy: Required
      clientCA:
        name: router-ca-certs-default
      allowedSubjectPatterns:
      - "^/CN=example.com/ST=NC/C=US/O=Security/OU=OpenShift$"

Copy to Clipboard

Toggle word wrap

6.4. 기본 Ingress 컨트롤러 보기
링크 복사

Ingress Operator는 OpenShift Container Platform의 핵심 기능이며 즉시 사용이 가능합니다.

모든 새로운 OpenShift Container Platform 설치에는 이름이 ingresscontroller로 기본으로 지정됩니다. 추가 Ingress 컨트롤러를 추가할 수 있습니다. 기본 ingresscontroller가 삭제되면 Ingress Operator가 1분 이내에 자동으로 다시 생성합니다.

프로세스

기본 Ingress 컨트롤러를 확인합니다.

oc describe --namespace=openshift-ingress-operator ingresscontroller/default

$ oc describe --namespace=openshift-ingress-operator ingresscontroller/default

Copy to Clipboard

Toggle word wrap

6.5. Ingress Operator 상태 보기
링크 복사

Ingress Operator의 상태를 확인 및 조사할 수 있습니다.

프로세스

Ingress Operator 상태를 확인합니다.
```
oc describe clusteroperators/ingress
```
```
$ oc describe clusteroperators/ingress
```
Copy to Clipboard Toggle word wrap

6.6. Ingress 컨트롤러 로그 보기
링크 복사

Ingress 컨트롤러의 로그를 확인할 수 있습니다.

프로세스

Ingress 컨트롤러 로그를 확인합니다.

oc logs --namespace=openshift-ingress-operator deployments/ingress-operator -c <container_name>

$ oc logs --namespace=openshift-ingress-operator deployments/ingress-operator -c <container_name>

Copy to Clipboard

Toggle word wrap

6.7. Ingress 컨트롤러 상태 보기
링크 복사

특정 Ingress 컨트롤러의 상태를 확인할 수 있습니다.

프로세스

Ingress 컨트롤러의 상태를 확인합니다.

oc describe --namespace=openshift-ingress-operator ingresscontroller/<name>

$ oc describe --namespace=openshift-ingress-operator ingresscontroller/<name>

Copy to Clipboard

Toggle word wrap

6.8. Ingress 컨트롤러 구성
링크 복사

6.8.1. 사용자 정의 기본 인증서 설정
링크 복사

관리자는 Secret 리소스를 생성하고 IngressController CR(사용자 정의 리소스)을 편집하여 사용자 정의 인증서를 사용하도록 Ingress 컨트롤러를 구성할 수 있습니다.

사전 요구 사항

PEM 인코딩 파일에 인증서/키 쌍이 있어야 합니다. 이때 인증서는 신뢰할 수 있는 인증 기관 또는 사용자 정의 PKI에서 구성한 신뢰할 수 있는 개인 인증 기관의 서명을 받은 인증서입니다.
인증서가 다음 요구 사항을 충족합니다.
- 인증서가 Ingress 도메인에 유효해야 합니다.
- 인증서는 subjectAltName 확장자를 사용하여 *.apps.ocp4.example.com과 같은 와일드카드 도메인을 지정합니다.
IngressController CR이 있어야 합니다. 기본 설정을 사용할 수 있어야 합니다.
```
oc --namespace openshift-ingress-operator get ingresscontrollers
```
```
$ oc --namespace openshift-ingress-operator get ingresscontrollers
```
Copy to Clipboard Toggle word wrap
출력 예
```
NAME      AGE
default   10m
```
```
NAME      AGE
default   10m
```
Copy to Clipboard Toggle word wrap

참고

임시 인증서가 있는 경우 사용자 정의 기본 인증서가 포함 된 보안의 tls.crt 파일에 인증서가 포함되어 있어야 합니다. 인증서를 지정하는 경우에는 순서가 중요합니다. 서버 인증서 다음에 임시 인증서를 나열해야 합니다.

프로세스

아래에서는 사용자 정의 인증서 및 키 쌍이 현재 작업 디렉터리의 tls.crt 및 tls.key 파일에 있다고 가정합니다. 그리고 tls.crt 및 tls.key의 실제 경로 이름으로 변경합니다. Secret 리소스를 생성하고 IngressController CR에서 참조하는 경우 custom-certs-default를 다른 이름으로 변경할 수도 있습니다.

참고

이 작업을 수행하면 롤링 배포 전략에 따라 Ingress 컨트롤러가 재배포됩니다.

tls.crt 및 tls.key 파일을 사용하여 openshift-ingress 네임스페이스에 사용자 정의 인증서를 포함하는 Secret 리소스를 만듭니다.
```
oc --namespace openshift-ingress create secret tls custom-certs-default --cert=tls.crt --key=tls.key
```
```
$ oc --namespace openshift-ingress create secret tls custom-certs-default --cert=tls.crt --key=tls.key
```
Copy to Clipboard Toggle word wrap

새 인증서 보안 키를 참조하도록 IngressController CR을 업데이트합니다.

oc patch --type=merge --namespace openshift-ingress-operator ingresscontrollers/default \
  --patch '{"spec":{"defaultCertificate":{"name":"custom-certs-default"}}}'

$ oc patch --type=merge --namespace openshift-ingress-operator ingresscontrollers/default \
  --patch '{"spec":{"defaultCertificate":{"name":"custom-certs-default"}}}'

Copy to Clipboard

Toggle word wrap

업데이트가 적용되었는지 확인합니다.

echo Q |\
  openssl s_client -connect console-openshift-console.apps.<domain>:443 -showcerts 2>/dev/null |\
  openssl x509 -noout -subject -issuer -enddate

$ echo Q |\
  openssl s_client -connect console-openshift-console.apps.<domain>:443 -showcerts 2>/dev/null |\
  openssl x509 -noout -subject -issuer -enddate

Copy to Clipboard

Toggle word wrap

다음과 같습니다.

<domain>: 클러스터의 기본 도메인 이름을 지정합니다.

출력 예

subject=C = US, ST = NC, L = Raleigh, O = RH, OU = OCP4, CN = *.apps.example.com
issuer=C = US, ST = NC, L = Raleigh, O = RH, OU = OCP4, CN = example.com
notAfter=May 10 08:32:45 2022 GM

subject=C = US, ST = NC, L = Raleigh, O = RH, OU = OCP4, CN = *.apps.example.com
issuer=C = US, ST = NC, L = Raleigh, O = RH, OU = OCP4, CN = example.com
notAfter=May 10 08:32:45 2022 GM

Copy to Clipboard

Toggle word wrap

작은 정보

다음 YAML을 적용하여 사용자 지정 기본 인증서를 설정할 수 있습니다.

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: default
  namespace: openshift-ingress-operator
spec:
  defaultCertificate:
    name: custom-certs-default

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: default
  namespace: openshift-ingress-operator
spec:
  defaultCertificate:
    name: custom-certs-default

Copy to Clipboard

Toggle word wrap

인증서 보안 이름은 CR을 업데이트하는 데 사용된 값과 일치해야 합니다.

IngressController CR이 수정되면 Ingress Operator는 사용자 정의 인증서를 사용하도록 Ingress 컨트롤러의 배포를 업데이트합니다.

6.8.2. 사용자 정의 기본 인증서 제거
링크 복사

관리자는 사용할 Ingress 컨트롤러를 구성한 사용자 정의 인증서를 제거할 수 있습니다.

사전 요구 사항

cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
OpenShift CLI(oc)가 설치되어 있습니다.
이전에 Ingress 컨트롤러에 대한 사용자 정의 기본 인증서를 구성했습니다.

프로세스

사용자 정의 인증서를 제거하고 OpenShift Container Platform과 함께 제공되는 인증서를 복원하려면 다음 명령을 입력합니다.
```
oc patch -n openshift-ingress-operator ingresscontrollers/default \
  --type json -p $'- op: remove\n  path: /spec/defaultCertificate'
```
```
$ oc patch -n openshift-ingress-operator ingresscontrollers/default \
  --type json -p $'- op: remove\n  path: /spec/defaultCertificate'
```
Copy to Clipboard Toggle word wrap
클러스터가 새 인증서 구성을 조정하는 동안 지연이 발생할 수 있습니다.

검증

원래 클러스터 인증서가 복원되었는지 확인하려면 다음 명령을 입력합니다.

echo Q | \
  openssl s_client -connect console-openshift-console.apps.<domain>:443 -showcerts 2>/dev/null | \
  openssl x509 -noout -subject -issuer -enddate

$ echo Q | \
  openssl s_client -connect console-openshift-console.apps.<domain>:443 -showcerts 2>/dev/null | \
  openssl x509 -noout -subject -issuer -enddate

Copy to Clipboard

Toggle word wrap

다음과 같습니다.

<domain>: 클러스터의 기본 도메인 이름을 지정합니다.

출력 예

subject=CN = *.apps.<domain>
issuer=CN = ingress-operator@1620633373
notAfter=May 10 10:44:36 2023 GMT

subject=CN = *.apps.<domain>
issuer=CN = ingress-operator@1620633373
notAfter=May 10 10:44:36 2023 GMT

Copy to Clipboard

Toggle word wrap

6.8.3. Ingress 컨트롤러 확장
링크 복사

처리량 증가 요구 등 라우팅 성능 또는 가용성 요구 사항을 충족하도록 Ingress 컨트롤러를 수동으로 확장할 수 있습니다. IngressController 리소스를 확장하려면 oc 명령을 사용합니다. 다음 절차는 기본 IngressController를 확장하는 예제입니다.

참고

원하는 수의 복제본을 만드는 데에는 시간이 걸리기 때문에 확장은 즉시 적용되지 않습니다.

프로세스

기본 IngressController의 현재 사용 가능한 복제본 개수를 살펴봅니다.

oc get -n openshift-ingress-operator ingresscontrollers/default -o jsonpath='{$.status.availableReplicas}'

$ oc get -n openshift-ingress-operator ingresscontrollers/default -o jsonpath='{$.status.availableReplicas}'

Copy to Clipboard

Toggle word wrap

출력 예

Copy to Clipboard

Toggle word wrap

oc patch 명령을 사용하여 기본 IngressController의 복제본 수를 원하는 대로 조정합니다. 다음 예제는 기본 IngressController를 3개의 복제본으로 조정합니다.

oc patch -n openshift-ingress-operator ingresscontroller/default --patch '{"spec":{"replicas": 3}}' --type=merge

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

Copy to Clipboard

Toggle word wrap

출력 예

ingresscontroller.operator.openshift.io/default patched

ingresscontroller.operator.openshift.io/default patched

Copy to Clipboard

Toggle word wrap

기본 IngressController가 지정한 복제본 수에 맞게 조정되었는지 확인합니다.

oc get -n openshift-ingress-operator ingresscontrollers/default -o jsonpath='{$.status.availableReplicas}'

$ oc get -n openshift-ingress-operator ingresscontrollers/default -o jsonpath='{$.status.availableReplicas}'

Copy to Clipboard

Toggle word wrap

출력 예

Copy to Clipboard

Toggle word wrap

작은 정보

또는 다음 YAML을 적용하여 Ingress 컨트롤러를 세 개의 복제본으로 확장할 수 있습니다.

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: default
  namespace: openshift-ingress-operator
spec:
  replicas: 3

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: default
  namespace: openshift-ingress-operator
spec:
  replicas: 3

1

Copy to Clipboard

Toggle word wrap

1: 다른 양의 복제본이 필요한 경우 replicas 값을 변경합니다.

6.8.4. 수신 액세스 로깅 구성
링크 복사

Ingress 컨트롤러가 로그에 액세스하도록 구성할 수 있습니다. 수신 트래픽이 많지 않은 클러스터의 경우 사이드카에 로그를 기록할 수 있습니다. 트래픽이 많은 클러스터가 있는 경우 로깅 스택의 용량을 초과하지 않거나 OpenShift Container Platform 외부의 로깅 인프라와 통합하기 위해 사용자 정의 syslog 끝점으로 로그를 전달할 수 있습니다. 액세스 로그의 형식을 지정할 수도 있습니다.

컨테이너 로깅은 기존 Syslog 로깅 인프라가 없는 경우 트래픽이 적은 클러스터에서 액세스 로그를 활성화하거나 Ingress 컨트롤러의 문제를 진단하는 동안 단기적으로 사용하는 데 유용합니다.

액세스 로그가 OpenShift 로깅 스택 용량을 초과할 수 있는 트래픽이 많은 클러스터 또는 로깅 솔루션이 기존 Syslog 로깅 인프라와 통합되어야 하는 환경에는 Syslog가 필요합니다. Syslog 사용 사례는 중첩될 수 있습니다.

사전 요구 사항

cluster-admin 권한이 있는 사용자로 로그인합니다.

프로세스

사이드카에 Ingress 액세스 로깅을 구성합니다.

수신 액세스 로깅을 구성하려면 spec.logging.access.destination을 사용하여 대상을 지정해야 합니다. 사이드카 컨테이너에 로깅을 지정하려면 Container spec.logging.access.destination.type을 지정해야 합니다. 다음 예제는 Container 대상에 로그를 기록하는 Ingress 컨트롤러 정의입니다.

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: default
  namespace: openshift-ingress-operator
spec:
  replicas: 2
  logging:
    access:
      destination:
        type: Container

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: default
  namespace: openshift-ingress-operator
spec:
  replicas: 2
  logging:
    access:
      destination:
        type: Container

Copy to Clipboard

Toggle word wrap

사이드카에 로그를 기록하도록 Ingress 컨트롤러를 구성하면 Operator는 Ingress 컨트롤러 Pod에 logs 라는 컨테이너를 만듭니다.

oc -n openshift-ingress logs deployment.apps/router-default -c logs

$ oc -n openshift-ingress logs deployment.apps/router-default -c logs

Copy to Clipboard

Toggle word wrap

출력 예

2020-05-11T19:11:50.135710+00:00 router-default-57dfc6cd95-bpmk6 router-default-57dfc6cd95-bpmk6 haproxy[108]: 174.19.21.82:39654 [11/May/2020:19:11:50.133] public be_http:hello-openshift:hello-openshift/pod:hello-openshift:hello-openshift:10.128.2.12:8080 0/0/1/0/1 200 142 - - --NI 1/1/0/0/0 0/0 "GET / HTTP/1.1"

2020-05-11T19:11:50.135710+00:00 router-default-57dfc6cd95-bpmk6 router-default-57dfc6cd95-bpmk6 haproxy[108]: 174.19.21.82:39654 [11/May/2020:19:11:50.133] public be_http:hello-openshift:hello-openshift/pod:hello-openshift:hello-openshift:10.128.2.12:8080 0/0/1/0/1 200 142 - - --NI 1/1/0/0/0 0/0 "GET / HTTP/1.1"

Copy to Clipboard

Toggle word wrap

Syslog 끝점에 대한 Ingress 액세스 로깅을 구성합니다.

수신 액세스 로깅을 구성하려면 spec.logging.access.destination을 사용하여 대상을 지정해야 합니다. Syslog 끝점 대상에 로깅을 지정하려면 spec.logging.access.destination.type에 대한 Syslog를 지정해야 합니다. 대상 유형이 Syslog인 경우, spec.logging.access.destination.syslog.endpoint를 사용하여 대상 끝점을 지정해야 하며 spec.logging.access.destination.syslog.facility를 사용하여 장치를 지정할 수 있습니다. 다음 예제는 Syslog 대상에 로그를 기록하는 Ingress 컨트롤러 정의입니다.
```
apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: default
  namespace: openshift-ingress-operator
spec:
  replicas: 2
  logging:
    access:
      destination:
        type: Syslog
        syslog:
          address: 1.2.3.4
          port: 10514
```
```
apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: default
  namespace: openshift-ingress-operator
spec:
  replicas: 2
  logging:
    access:
      destination:
        type: Syslog
        syslog:
          address: 1.2.3.4
          port: 10514
```
Copy to Clipboard Toggle word wrap
참고
syslog 대상 포트는 UDP여야 합니다.

특정 로그 형식으로 Ingress 액세스 로깅을 구성합니다.

spec.logging.access.httpLogFormat을 지정하여 로그 형식을 사용자 정의할 수 있습니다. 다음 예제는 IP 주소 1.2.3.4 및 포트 10514를 사용하여 syslog 끝점에 로그하는 Ingress 컨트롤러 정의입니다.

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: default
  namespace: openshift-ingress-operator
spec:
  replicas: 2
  logging:
    access:
      destination:
        type: Syslog
        syslog:
          address: 1.2.3.4
          port: 10514
      httpLogFormat: '%ci:%cp [%t] %ft %b/%s %B %bq %HM %HU %HV'

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: default
  namespace: openshift-ingress-operator
spec:
  replicas: 2
  logging:
    access:
      destination:
        type: Syslog
        syslog:
          address: 1.2.3.4
          port: 10514
      httpLogFormat: '%ci:%cp [%t] %ft %b/%s %B %bq %HM %HU %HV'

Copy to Clipboard

Toggle word wrap

Ingress 액세스 로깅을 비활성화합니다.

Ingress 액세스 로깅을 비활성화하려면 spec.logging 또는 spec.logging.access를 비워 둡니다.

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: default
  namespace: openshift-ingress-operator
spec:
  replicas: 2
  logging:
    access: null

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: default
  namespace: openshift-ingress-operator
spec:
  replicas: 2
  logging:
    access: null

Copy to Clipboard

Toggle word wrap

6.8.5. Ingress 컨트롤러 스레드 수 설정
링크 복사

클러스터 관리자는 클러스터에서 처리할 수 있는 들어오는 연결의 양을 늘리기 위해 스레드 수를 설정할 수 있습니다. 기존 Ingress 컨트롤러에 패치하여 스레드의 양을 늘릴 수 있습니다.

사전 요구 사항

다음은 Ingress 컨트롤러를 이미 생성했다고 가정합니다.

프로세스

스레드 수를 늘리도록 Ingress 컨트롤러를 업데이트합니다.
```
oc -n openshift-ingress-operator patch ingresscontroller/default --type=merge -p '{"spec":{"tuningOptions": {"threadCount": 8}}}'
```
```
$ oc -n openshift-ingress-operator patch ingresscontroller/default --type=merge -p '{"spec":{"tuningOptions": {"threadCount": 8}}}'
```
Copy to Clipboard Toggle word wrap
참고
많은 리소스를 실행할 수 있는 노드가 있는 경우 원하는 노드의 용량과 일치하는 라벨을 사용하여 spec.nodePlacement.nodeSelector를 구성하고 spec.tuningOptions.threadCount를 적절하게 높은 값으로 구성할 수 있습니다.

6.8.6. 내부 로드 밸런서를 사용하도록 Ingress 컨트롤러 구성
링크 복사

클라우드 플랫폼에서 Ingress 컨트롤러를 생성할 때 Ingress 컨트롤러는 기본적으로 퍼블릭 클라우드 로드 밸런서에 의해 게시됩니다. 관리자는 내부 클라우드 로드 밸런서를 사용하는 Ingress 컨트롤러를 생성할 수 있습니다.

주의

클라우드 공급자가 Microsoft Azure인 경우 노드를 가리키는 퍼블릭 로드 밸런서가 하나 이상 있어야 합니다. 그렇지 않으면 모든 노드의 인터넷 연결이 끊어집니다.

중요

IngressController 의 범위를 변경하려면 CR(사용자 정의 리소스)이 생성된 후 .spec.endpointPublishingStrategy.loadBalancer.scope 매개변수를 변경할 수 있습니다.

그림 6.1. LoadBalancer 다이어그램

이전 그래픽에서는 OpenShift Container Platform Ingress LoadBalancerService 끝점 게시 전략에 대한 다음 개념을 보여줍니다.

OpenShift Ingress 컨트롤러 로드 밸런서를 사용하여 클라우드 공급자 로드 밸런서 또는 내부적으로 로드 밸런싱을 외부적으로 로드할 수 있습니다.
그래픽에 표시된 것처럼 로드 밸런서의 단일 IP 주소 및 더 친숙한 포트(예: 8080 및 4200)를 사용할 수 있습니다.
외부 로드 밸런서의 트래픽은 Pod에서 지시하며 down 노드의 인스턴스에 표시된 대로 로드 밸런서에서 관리합니다. 구현 세부 사항은 Kubernetes 서비스 설명서를 참조하십시오.

사전 요구 사항

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

프로세스

다음 예제와 같이 <name>-ingress-controller.yam 파일에 IngressController CR(사용자 정의 리소스)을 생성합니다.

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

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

1


spec:
  domain: <domain>

2


  endpointPublishingStrategy:
    type: LoadBalancerService
    loadBalancer:
      scope: Internal

3

Copy to Clipboard

Toggle word wrap

1: <name>을 IngressController 오브젝트의 이름으로 변경합니다.
2: 컨트롤러가 게시한 애플리케이션의 domain을 지정합니다.
3: 내부 로드 밸런서를 사용하려면 Internal 값을 지정합니다.

다음 명령을 실행하여 이전 단계에서 정의된 Ingress 컨트롤러를 생성합니다.
```
oc create -f <name>-ingress-controller.yaml
```
```
$ oc create -f <name>-ingress-controller.yaml 
```
1
Copy to Clipboard Toggle word wrap
1
<name>을 IngressController 오브젝트의 이름으로 변경합니다.
선택 사항: Ingress 컨트롤러가 생성되었는지 확인하려면 다음 명령을 실행합니다.
```
oc --all-namespaces=true get ingresscontrollers
```
```
$ oc --all-namespaces=true get ingresscontrollers
```
Copy to Clipboard Toggle word wrap

6.8.7. GCP에서 Ingress 컨트롤러에 대한 글로벌 액세스 구성
링크 복사

내부 로드 밸런서가 있는 GCP에서 생성된 Ingress 컨트롤러는 서비스의 내부 IP 주소를 생성합니다. 클러스터 관리자는 로드 밸런서와 동일한 VPC 네트워크 및 컴퓨팅 리전 내의 모든 리전의 클라이언트가 클러스터에서 실행되는 워크로드에 도달할 수 있도록 하는 글로벌 액세스 옵션을 지정할 수 있습니다.

자세한 내용은 글로벌 액세스에 대한 GCP 설명서를 참조하십시오.

사전 요구 사항

GCP 인프라에 OpenShift Container Platform 클러스터를 배포했습니다.
내부 로드 밸런서를 사용하도록 Ingress 컨트롤러 구성
OpenShift CLI(oc)를 설치합니다.

프로세스

글로벌 액세스를 허용하도록 Ingress 컨트롤러 리소스를 구성합니다.

참고

Ingress 컨트롤러를 생성하고 글로벌 액세스 옵션을 지정할 수도 있습니다.

Ingress 컨트롤러 리소스를 구성합니다.

oc -n openshift-ingress-operator edit ingresscontroller/default

$ oc -n openshift-ingress-operator edit ingresscontroller/default

Copy to Clipboard

Toggle word wrap

YAML 파일을 편집합니다.

Global에 대한 clientAccess 구성 샘플

  spec:
    endpointPublishingStrategy:
      loadBalancer:
        providerParameters:
          gcp:
            clientAccess: Global 
          type: GCP
        scope: Internal
      type: LoadBalancerService

  spec:
    endpointPublishingStrategy:
      loadBalancer:
        providerParameters:
          gcp:
            clientAccess: Global

1


          type: GCP
        scope: Internal
      type: LoadBalancerService

Copy to Clipboard

Toggle word wrap

1: gcp.clientAccess를 Global로 설정합니다.

파일을 저장하여 변경 사항을 적용합니다.

다음 명령을 실행하여 서비스가 글로벌 액세스를 허용하는지 확인합니다.
```
oc -n openshift-ingress edit svc/router-default -o yaml
```
```
$ oc -n openshift-ingress edit svc/router-default -o yaml
```
Copy to Clipboard Toggle word wrap
출력에서 주석 networking.gke.io/internal-load-balancer-allow-global-access가 있는 GCP에 글로벌 액세스가 활성화되어 있음을 보여줍니다.

6.8.8. Ingress 컨트롤러 상태 점검 간격 설정
링크 복사

클러스터 관리자는 상태 점검 간격을 설정하여 두 번 연속된 상태 점검 간에 라우터가 대기하는 시간을 정의할 수 있습니다. 이 값은 모든 경로에 대한 기본값으로 전역적으로 적용됩니다. 기본값은 5초입니다.

사전 요구 사항

다음은 Ingress 컨트롤러를 이미 생성했다고 가정합니다.

프로세스

백엔드 상태 점검 간 간격을 변경하도록 Ingress 컨트롤러를 업데이트합니다.
```
oc -n openshift-ingress-operator patch ingresscontroller/default --type=merge -p '{"spec":{"tuningOptions": {"healthCheckInterval": "8s"}}}'
```
```
$ oc -n openshift-ingress-operator patch ingresscontroller/default --type=merge -p '{"spec":{"tuningOptions": {"healthCheckInterval": "8s"}}}'
```
Copy to Clipboard Toggle word wrap
참고
단일 경로에 대해 healthCheckInterval 을 재정의하려면 경로 주석 router.openshift.io/haproxy.health.check.interval을 사용하십시오.

6.8.9. 클러스터의 기본 Ingress 컨트롤러를 내부로 구성
링크 복사

클러스터를 삭제하고 다시 생성하여 클러스터의 default Ingress 컨트롤러를 내부용으로 구성할 수 있습니다.

주의

클라우드 공급자가 Microsoft Azure인 경우 노드를 가리키는 퍼블릭 로드 밸런서가 하나 이상 있어야 합니다. 그렇지 않으면 모든 노드의 인터넷 연결이 끊어집니다.

중요

IngressController 의 범위를 변경하려면 CR(사용자 정의 리소스)이 생성된 후 .spec.endpointPublishingStrategy.loadBalancer.scope 매개변수를 변경할 수 있습니다.

사전 요구 사항

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

프로세스

클러스터의 기본 Ingress 컨트롤러를 삭제하고 다시 생성하여 내부용으로 구성합니다.

oc replace --force --wait --filename - <<EOF
apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  namespace: openshift-ingress-operator
  name: default
spec:
  endpointPublishingStrategy:
    type: LoadBalancerService
    loadBalancer:
      scope: Internal
EOF

$ oc replace --force --wait --filename - <<EOF
apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  namespace: openshift-ingress-operator
  name: default
spec:
  endpointPublishingStrategy:
    type: LoadBalancerService
    loadBalancer:
      scope: Internal
EOF

Copy to Clipboard

Toggle word wrap

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

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

주의

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

사전 요구 사항

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

프로세스

다음 명령을 사용하여 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

6.8.11. 와일드카드 경로 사용
링크 복사

HAProxy Ingress 컨트롤러는 와일드카드 경로를 지원합니다. Ingress Operator는 wildcardPolicy를 사용하여 Ingress 컨트롤러의 ROUTER_ALLOW_WILDCARD_ROUTES 환경 변수를 구성합니다.

Ingress 컨트롤러의 기본 동작은 와일드카드 정책이 None인 경로를 허용하고, 이는 기존 IngressController 리소스의 이전 버전과 호환됩니다.

프로세스

와일드카드 정책을 구성합니다.
1. 다음 명령을 사용하여 IngressController 리소스를 편집합니다.
  $ oc edit IngressController
  Copy to Clipboard Toggle word wrap
2. spec에서 wildcardPolicy 필드를 WildcardsDisallowed 또는 WildcardsAllowed로 설정합니다.
  spec: routeAdmission: wildcardPolicy: WildcardsDisallowed # or WildcardsAllowed
  Copy to Clipboard Toggle word wrap

6.8.12. X-Forwarded 헤더 사용
링크 복사

HAProxy Ingress 컨트롤러를 구성하여 Forwarded 및 X-Forwarded-For를 포함한 HTTP 헤더 처리 방법에 대한 정책을 지정합니다. Ingress Operator는 HTTPHeaders 필드를 사용하여 Ingress 컨트롤러의 ROUTER_SET_FORWARDED_HEADERS 환경 변수를 구성합니다.

프로세스

Ingress 컨트롤러에 대한 HTTPHeaders 필드를 구성합니다.

다음 명령을 사용하여 IngressController 리소스를 편집합니다.
```
oc edit IngressController
```
```
$ oc edit IngressController
```
Copy to Clipboard Toggle word wrap

spec에서 HTTPHeaders 정책 필드를 Append, Replace, IfNone 또는 Never로 설정합니다.

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: default
  namespace: openshift-ingress-operator
spec:
  httpHeaders:
    forwardedHeaderPolicy: Append

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: default
  namespace: openshift-ingress-operator
spec:
  httpHeaders:
    forwardedHeaderPolicy: Append

Copy to Clipboard

Toggle word wrap

사용 사례 예

클러스터 관리자는 다음을 수행할 수 있습니다.

Ingress 컨트롤러로 전달하기 전에 X-Forwarded-For 헤더를 각 요청에 삽입하는 외부 프록시를 구성합니다.
헤더를 수정하지 않은 상태로 전달하도록 Ingress 컨트롤러를 구성하려면 never 정책을 지정합니다. 그러면 Ingress 컨트롤러에서 헤더를 설정하지 않으며 애플리케이션은 외부 프록시에서 제공하는 헤더만 수신합니다.
외부 프록시에서 외부 클러스터 요청에 설정한 X-Forwarded-For 헤더를 수정하지 않은 상태로 전달하도록 Ingress 컨트롤러를 구성합니다.
외부 프록시를 통과하지 않는 내부 클러스터 요청에 X-Forwarded-For 헤더를 설정하도록 Ingress 컨트롤러를 구성하려면 if-none 정책을 지정합니다. HTTP 요청에 이미 외부 프록시를 통해 설정된 헤더가 있는 경우 Ingress 컨트롤러에서 해당 헤더를 보존합니다. 요청이 프록시를 통해 제공되지 않아 헤더가 없는 경우에는 Ingress 컨트롤러에서 헤더를 추가합니다.

애플리케이션 개발자는 다음을 수행할 수 있습니다.

X-Forwarded-For 헤더를 삽입하는 애플리케이션별 외부 프록시를 구성합니다.
다른 경로에 대한 정책에 영향을 주지 않으면서 애플리케이션 경로에 대한 헤더를 수정하지 않은 상태로 전달하도록 Ingress 컨트롤러를 구성하려면 애플리케이션 경로에 주석 haproxy.router.openshift.io/set-forwarded-headers: if-none 또는 haproxy.router.openshift.io/set-forwarded-headers: never를 추가하십시오.
참고
Ingress 컨트롤러에 전역적으로 설정된 값과 관계없이 경로별로 haproxy.router.openshift.io/set-forwarded-headers 주석을 설정할 수 있습니다.

6.8.13. HTTP/2 수신 연결 사용
링크 복사

이제 HAProxy에서 투명한 엔드 투 엔드 HTTP/2 연결을 활성화할 수 있습니다. 애플리케이션 소유자는 이를 통해 단일 연결, 헤더 압축, 바이너리 스트림 등 HTTP/2 프로토콜 기능을 활용할 수 있습니다.

개별 Ingress 컨트롤러 또는 전체 클러스터에 대해 HAProxy에서 HTTP/2 연결을 활성화할 수 있습니다.

클라이언트에서 HAProxy로의 연결에 HTTP/2 사용을 활성화하려면 경로에서 사용자 정의 인증서를 지정해야 합니다. 기본 인증서를 사용하는 경로에서는 HTTP/2를 사용할 수 없습니다. 이것은 동일한 인증서를 사용하는 다른 경로의 연결을 클라이언트가 재사용하는 등 동시 연결로 인한 문제를 방지하기 위한 제한입니다.

HAProxy에서 애플리케이션 pod로의 연결은 re-encrypt 라우팅에만 HTTP/2를 사용할 수 있으며 Edge termination 또는 비보안 라우팅에는 사용할 수 없습니다. 이 제한은 백엔드와 HTTP/2 사용을 협상할 때 HAProxy가 TLS의 확장인 ALPN(Application-Level Protocol Negotiation)을 사용하기 때문에 필요합니다. 이는 엔드 투 엔드 HTTP/2가 패스스루(passthrough) 및 re-encrypt 라우팅에는 적합하지만 비보안 또는 Edge termination 라우팅에는 적합하지 않음을 의미합니다.

주의

Ingress 컨트롤러에서 재암호화 경로와 HTTP/2가 활성화된 WebSockets를 사용하려면 HTTP/2를 통해 WebSocket 지원이 필요합니다. WebSockets over HTTP/2는 현재 OpenShift Container Platform에서 지원되지 않는 HAProxy 2.4의 기능입니다.

중요

패스스루(passthrough)가 아닌 경로의 경우 Ingress 컨트롤러는 클라이언트와의 연결과 관계없이 애플리케이션에 대한 연결을 협상합니다. 다시 말해 클라이언트가 Ingress 컨트롤러에 연결하여 HTTP/1.1을 협상하고, Ingress 컨트롤러가 애플리케이션에 연결하여 HTTP/2를 협상하고, 클라이언트 HTTP/1.1 연결에서 받은 요청을 HTTP/2 연결을 사용하여 애플리케이션에 전달할 수 있습니다. Ingress 컨트롤러는 WebSocket을 HTTP/2로 전달할 수 없고 HTTP/2 연결을 WebSocket으로 업그레이드할 수 없기 때문에 나중에 클라이언트가 HTTP/1.1 연결을 WebSocket 프로토콜로 업그레이드하려고 하면 문제가 발생하게 됩니다. 결과적으로, WebSocket 연결을 허용하는 애플리케이션이 있는 경우 HTTP/2 프로토콜 협상을 허용하지 않아야 합니다. 그러지 않으면 클라이언트가 WebSocket 프로토콜로 업그레이드할 수 없게 됩니다.

프로세스

단일 Ingress 컨트롤러에서 HTTP/2를 활성화합니다.

Ingress 컨트롤러에서 HTTP/2를 사용하려면 다음과 같이 oc annotate 명령을 입력합니다.

oc -n openshift-ingress-operator annotate ingresscontrollers/<ingresscontroller_name> ingress.operator.openshift.io/default-enable-http2=true

$ oc -n openshift-ingress-operator annotate ingresscontrollers/<ingresscontroller_name> ingress.operator.openshift.io/default-enable-http2=true

Copy to Clipboard

Toggle word wrap

<ingresscontroller_name>을 주석 처리할 Ingress 컨트롤러의 이름으로 변경합니다.

전체 클러스터에서 HTTP/2를 활성화합니다.

전체 클러스터에 HTTP/2를 사용하려면 oc annotate 명령을 입력합니다.

oc annotate ingresses.config/cluster ingress.operator.openshift.io/default-enable-http2=true

$ oc annotate ingresses.config/cluster ingress.operator.openshift.io/default-enable-http2=true

Copy to Clipboard

Toggle word wrap

작은 정보

다음 YAML을 적용하여 주석을 추가할 수도 있습니다.

apiVersion: config.openshift.io/v1
kind: Ingress
metadata:
  name: cluster
  annotations:
    ingress.operator.openshift.io/default-enable-http2: "true"

apiVersion: config.openshift.io/v1
kind: Ingress
metadata:
  name: cluster
  annotations:
    ingress.operator.openshift.io/default-enable-http2: "true"

Copy to Clipboard

Toggle word wrap

6.8.14. Ingress 컨트롤러에 대한 PROXY 프로토콜 구성
링크 복사

클러스터 관리자는 Ingress 컨트롤러에서 HostNetwork 또는 NodePortService 엔드포인트 게시 전략 유형을 사용하는 경우 PROXY 프로토콜을 구성할 수 있습니다. PROXY 프로토콜을 사용하면 로드 밸런서에서 Ingress 컨트롤러가 수신하는 연결에 대한 원래 클라이언트 주소를 유지할 수 있습니다. 원래 클라이언트 주소는 HTTP 헤더를 로깅, 필터링 및 삽입하는 데 유용합니다. 기본 구성에서 Ingress 컨트롤러가 수신하는 연결에는 로드 밸런서와 연결된 소스 주소만 포함됩니다.

이 기능은 클라우드 배포에서 지원되지 않습니다. 이 제한 사항은 OpenShift Container Platform이 클라우드 플랫폼에서 실행되고 IngressController에서 서비스 로드 밸런서를 사용해야 함을 지정하기 때문에 Ingress Operator는 로드 밸런서 서비스를 구성하고 소스 주소를 유지하기 위한 플랫폼 요구 사항에 따라 PROXY 프로토콜을 활성화하기 때문입니다.

중요

PROXY 프로토콜을 사용하거나 TCP를 사용하려면 OpenShift Container Platform과 외부 로드 밸런서를 모두 구성해야 합니다.

주의

PROXY 프로토콜은 Keepalived Ingress VIP를 사용하는 비클라우드 플랫폼에 설치 관리자 프로비저닝 클러스터가 있는 기본 Ingress 컨트롤러에 지원되지 않습니다.

사전 요구 사항

Ingress 컨트롤러가 생성되어 있습니다.

프로세스

Ingress 컨트롤러 리소스를 편집합니다.

oc -n openshift-ingress-operator edit ingresscontroller/default

$ oc -n openshift-ingress-operator edit ingresscontroller/default

Copy to Clipboard

Toggle word wrap

PROXY 구성을 설정합니다.
- Ingress 컨트롤러에서 hostNetwork 엔드포인트 게시 전략 유형을 사용하는 경우 spec.endpointPublishingStrategy.hostNetwork.protocol 하위 필드를 PROXY로 설정합니다.
  PROXY에 대한 hostNetwork 구성 샘플
  spec: endpointPublishingStrategy: hostNetwork: protocol: PROXY type: HostNetwork
  
  Copy to Clipboard Toggle word wrap
- Ingress 컨트롤러에서 NodePortService 엔드포인트 게시 전략 유형을 사용하는 경우 spec.endpointPublishingStrategy.nodePort.protocol 하위 필드를 PROXY로 설정합니다.
  PROXY에 대한 nodePort 구성 샘플
  spec: endpointPublishingStrategy: nodePort: protocol: PROXY type: NodePortService
  
  Copy to Clipboard Toggle word wrap

6.8.15. appsDomain 옵션을 사용하여 대체 클러스터 도메인 지정
링크 복사

클러스터 관리자는 appsDomain 필드를 구성하여 사용자가 생성한 경로의 기본 클러스터 도메인에 대한 대안을 지정할 수 있습니다. appsDomain 필드는 domain 필드에 지정된 기본값 대신 사용할 OpenShift Container Platform의 선택적 도메인 입니다. 대체 도메인을 지정하면 새 경로의 기본 호스트를 결정하기 위해 기본 클러스터 도메인을 덮어씁니다.

예를 들어, 회사의 DNS 도메인을 클러스터에서 실행되는 애플리케이션의 경로 및 인그레스의 기본 도메인으로 사용할 수 있습니다.

사전 요구 사항

OpenShift Container Platform 클러스터를 배포했습니다.
oc 명령줄 인터페이스를 설치했습니다.

프로세스

사용자 생성 경로에 대한 대체 기본 도메인을 지정하여 appsDomain 필드를 구성합니다.
1. Ingress 클러스터 리소스를 편집합니다.
  $ oc edit ingresses.config/cluster -o yaml
  Copy to Clipboard Toggle word wrap
2. YAML 파일을 편집합니다.
  test.example.com에 대한 샘플 appsDomain 구성
  apiVersion: config.openshift.io/v1 kind: Ingress metadata: name: cluster spec: domain: apps.example.com
  1
  appsDomain: <test.example.com>
  2
  
  Copy to Clipboard Toggle word wrap
  1
  기본 도메인을 지정합니다. 설치 후에는 기본 도메인을 수정할 수 없습니다.
  2
  선택사항: 애플리케이션 경로에 사용할 OpenShift Container Platform 인프라의 도메인입니다. 앱 의 기본 접두사 대신 test 와 같은 대체 접두사를 사용할 수 있습니다.

경로를 노출하고 경로 도메인 변경을 확인하여 기존 경로에 appsDomain 필드에 지정된 도메인 이름이 포함되어 있는지 확인합니다.

참고

경로를 노출하기 전에 openshift-apiserver가 롤링 업데이트를 완료할 때까지 기다립니다.

경로를 노출합니다.

oc expose service hello-openshift
route.route.openshift.io/hello-openshift exposed

$ oc expose service hello-openshift
route.route.openshift.io/hello-openshift exposed

Copy to Clipboard

Toggle word wrap

출력 예:

oc get routes
NAME              HOST/PORT                                   PATH   SERVICES          PORT       TERMINATION   WILDCARD
hello-openshift   hello_openshift-<my_project>.test.example.com
hello-openshift   8080-tcp                 None

$ oc get routes
NAME              HOST/PORT                                   PATH   SERVICES          PORT       TERMINATION   WILDCARD
hello-openshift   hello_openshift-<my_project>.test.example.com
hello-openshift   8080-tcp                 None

Copy to Clipboard

Toggle word wrap

6.8.16. HTTP 헤더 대소문자 변환
링크 복사

HAProxy 2.2는 기본적으로 HTTP 헤더 이름을 소문자로 (예: Host: xyz.com을 host: xyz.com으로) 변경합니다. 기존 애플리케이션이 HTTP 헤더 이름의 대문자에 민감한 경우 Ingress Controller spec.httpHeaders.headerNameCaseAdjustments API 필드를 사용하여 기존 애플리케이션을 수정할 때 까지 지원합니다.

중요

OpenShift Container Platform에는 HAProxy 2.2가 포함되어 있으므로 업그레이드하기 전에 spec.httpHeaders.headerNameCaseAdjustments 를 사용하여 필요한 구성을 추가하십시오.

사전 요구 사항

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

프로세스

클러스터 관리자는 oc patch 명령을 입력하거나 Ingress 컨트롤러 YAML 파일에서 HeaderNameCaseAdjustments 필드를 설정하여 HTTP 헤더 케이스를 변환할 수 있습니다.

oc patch 명령을 입력하여 대문자로 작성할 HTTP 헤더를 지정합니다.

oc patch 명령을 입력하여 HTTP host 헤더를 Host로 변경합니다.

oc -n openshift-ingress-operator patch ingresscontrollers/default --type=merge --patch='{"spec":{"httpHeaders":{"headerNameCaseAdjustments":["Host"]}}}'

$ oc -n openshift-ingress-operator patch ingresscontrollers/default --type=merge --patch='{"spec":{"httpHeaders":{"headerNameCaseAdjustments":["Host"]}}}'

Copy to Clipboard

Toggle word wrap

애플리케이션 경로에 주석을 추가합니다.
```
oc annotate routes/my-application haproxy.router.openshift.io/h1-adjust-case=true
```
```
$ oc annotate routes/my-application haproxy.router.openshift.io/h1-adjust-case=true
```
Copy to Clipboard Toggle word wrap
그런 다음 Ingress 컨트롤러는 지정된 대로 host 요청 헤더를 조정합니다.

Ingress 컨트롤러 YAML 파일을 구성하여 HeaderNameCaseAdjustments 필드를 사용하여 조정합니다.

다음 예제 Ingress 컨트롤러 YAML은 적절하게 주석이 달린 경로의 HTTP/1 요청에 대해 host 헤더를 Host로 조정합니다.

Ingress 컨트롤러 YAML 예시

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: default
  namespace: openshift-ingress-operator
spec:
  httpHeaders:
    headerNameCaseAdjustments:
    - Host

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: default
  namespace: openshift-ingress-operator
spec:
  httpHeaders:
    headerNameCaseAdjustments:
    - Host

Copy to Clipboard

Toggle word wrap

다음 예제 경로에서는 haproxy.router.openshift.io/h1-adjust-case 주석을 사용하여 HTTP 응답 헤더 이름 대소문자 조정을 활성화합니다.

경로 YAML의 예

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  annotations:
    haproxy.router.openshift.io/h1-adjust-case: true 
  name: my-application
  namespace: my-application
spec:
  to:
    kind: Service
    name: my-application

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  annotations:
    haproxy.router.openshift.io/h1-adjust-case: true

1


  name: my-application
  namespace: my-application
spec:
  to:
    kind: Service
    name: my-application

Copy to Clipboard

Toggle word wrap

1: haproxy.router.openshift.io/h1-adjust-case를 true로 설정합니다.

6.8.17. 라우터 압축 사용
링크 복사

특정 MIME 유형에 대해 전역적으로 라우터 압축을 지정하도록 HAProxy Ingress 컨트롤러를 구성합니다. mimeTypes 변수를 사용하여 압축이 적용되는 MIME 유형의 형식을 정의할 수 있습니다. 유형은 애플리케이션, 이미지, 메시지, 다중 파트, 텍스트, 비디오 또는 "X-"로 선행되는 사용자 정의 유형입니다. MIME 유형 및 하위 유형에 대한 전체 표기법을 보려면 RFC1341 을 참조하십시오.

참고

압축을 위해 할당된 메모리는 최대 연결에 영향을 미칠 수 있습니다. 또한 대규모 버퍼 압축으로 인해 regex 또는 긴 regex 목록과 같은 대기 시간이 발생할 수 있습니다.

모든 MIME 유형이 압축의 이점을 제공하는 것은 아니지만, HAProxy는 여전히 리소스를 사용하여 에 지시된 경우 압축하려고 합니다. 일반적으로 html, css 및 js와 같은 텍스트 형식은 압축의 이점을 활용하지만 이미지, 오디오 및 비디오와 같은 형식이 압축되는 시간과 리소스를 교환하는 것은 거의 없습니다.

절차

Ingress 컨트롤러의 httpCompression 필드를 구성합니다.

다음 명령을 사용하여 IngressController 리소스를 편집합니다.

oc edit -n openshift-ingress-operator ingresscontrollers/default

$ oc edit -n openshift-ingress-operator ingresscontrollers/default

Copy to Clipboard

Toggle word wrap

사양에서 httpCompression 정책 필드를 mimeTypes 로 설정하고 압축이 적용되어야 하는 MIME 유형 목록을 지정합니다.

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: default
  namespace: openshift-ingress-operator
spec:
  httpCompression:
    mimeTypes:
    - "text/html"
    - "text/css; charset=utf-8"
    - "application/json"
   ...

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: default
  namespace: openshift-ingress-operator
spec:
  httpCompression:
    mimeTypes:
    - "text/html"
    - "text/css; charset=utf-8"
    - "application/json"
   ...

Copy to Clipboard

Toggle word wrap

6.8.18. HAProxy 오류 코드 응답 페이지 사용자 정의
링크 복사

클러스터 관리자는 503, 404 또는 두 오류 페이지에 대한 사용자 지정 오류 코드 응답 페이지를 지정할 수 있습니다. HAProxy 라우터는 애플리케이션 pod가 실행 중이 아닌 경우 503 오류 페이지 또는 요청된 URL이 없는 경우 404 오류 페이지를 제공합니다. 예를 들어 503 오류 코드 응답 페이지를 사용자 지정하면 애플리케이션 pod가 실행되지 않을 때 페이지가 제공되며 HAProxy 라우터에서 잘못된 경로 또는 존재하지 않는 경로에 대해 기본 404 오류 코드 HTTP 응답 페이지가 제공됩니다.

사용자 정의 오류 코드 응답 페이지가 구성 맵에 지정되고 Ingress 컨트롤러에 패치됩니다. 구성 맵 키의 사용 가능한 파일 이름은 error-page-503.http 및 error-page-404.http 입니다.

사용자 지정 HTTP 오류 코드 응답 페이지는 HAProxy HTTP 오류 페이지 구성 지침을 따라야 합니다. 다음은 기본 OpenShift Container Platform HAProxy 라우터 http 503 오류 코드 응답 페이지의 예입니다. 기본 콘텐츠를 고유한 사용자 지정 페이지를 생성하기 위한 템플릿으로 사용할 수 있습니다.

기본적으로 HAProxy 라우터는 애플리케이션이 실행 중이 아니거나 경로가 올바르지 않거나 존재하지 않는 경우 503 오류 페이지만 제공합니다. 이 기본 동작은 OpenShift Container Platform 4.8 및 이전 버전의 동작과 동일합니다. HTTP 오류 코드 응답 사용자 정의에 대한 구성 맵이 제공되지 않고 사용자 정의 HTTP 오류 코드 응답 페이지를 사용하는 경우 라우터는 기본 404 또는 503 오류 코드 응답 페이지를 제공합니다.

참고

OpenShift Container Platform 기본 503 오류 코드 페이지를 사용자 지정을 위한 템플릿으로 사용하는 경우 파일의 헤더에 CRLF 줄 종료를 사용할 수 있는 편집기가 필요합니다.

절차

openshift-config 네임스페이스에 my-custom-error-code-pages 라는 구성 맵을 생성합니다.
```
oc -n openshift-config create configmap my-custom-error-code-pages \
--from-file=error-page-503.http \
--from-file=error-page-404.http
```
```
$ oc -n openshift-config create configmap my-custom-error-code-pages \
--from-file=error-page-503.http \
--from-file=error-page-404.http
```
Copy to Clipboard Toggle word wrap
중요
사용자 정의 오류 코드 응답 페이지에 올바른 형식을 지정하지 않으면 라우터 Pod 중단이 발생합니다. 이 중단을 해결하려면 구성 맵을 삭제하거나 수정하고 영향을 받는 라우터 Pod를 삭제하여 올바른 정보로 다시 생성해야 합니다.
이름별로 my-custom-error-code-pages 구성 맵을 참조하도록 Ingress 컨트롤러를 패치합니다.
```
oc patch -n openshift-ingress-operator ingresscontroller/default --patch '{"spec":{"httpErrorCodePages":{"name":"my-custom-error-code-pages"}}}' --type=merge
```
```
$ oc patch -n openshift-ingress-operator ingresscontroller/default --patch '{"spec":{"httpErrorCodePages":{"name":"my-custom-error-code-pages"}}}' --type=merge
```
Copy to Clipboard Toggle word wrap
Ingress Operator는 my-custom-error-code-pages 구성 맵을 openshift-config 네임스페이스에서 openshift-ingress 네임스페이스로 복사합니다. Operator는 openshift-ingress 네임스페이스에서 <your_ingresscontroller_name>-errorpages 패턴에 따라 구성 맵의 이름을 지정합니다.
복사본을 표시합니다.
```
oc get cm default-errorpages -n openshift-ingress
```
```
$ oc get cm default-errorpages -n openshift-ingress
```
Copy to Clipboard Toggle word wrap
출력 예
```
NAME                       DATA   AGE
default-errorpages         2      25s  
```
```
NAME                       DATA   AGE
default-errorpages         2      25s  
```
1
Copy to Clipboard Toggle word wrap
1
default Ingress 컨트롤러 CR(사용자 정의 리소스)이 패치되었기 때문에 구성 맵 이름은 default-errorpages입니다.
사용자 정의 오류 응답 페이지가 포함된 구성 맵이 라우터 볼륨에 마운트되는지 확인합니다. 여기서 구성 맵 키는 사용자 정의 HTTP 오류 코드 응답이 있는 파일 이름입니다.
- 503 사용자 지정 HTTP 사용자 정의 오류 코드 응답의 경우:
  $ oc -n openshift-ingress rsh <router_pod> cat /var/lib/haproxy/conf/error_code_pages/error-page-503.http
  Copy to Clipboard Toggle word wrap
- 404 사용자 지정 HTTP 사용자 정의 오류 코드 응답의 경우:
  $ oc -n openshift-ingress rsh <router_pod> cat /var/lib/haproxy/conf/error_code_pages/error-page-404.http
  Copy to Clipboard Toggle word wrap

검증

사용자 정의 오류 코드 HTTP 응답을 확인합니다.

테스트 프로젝트 및 애플리케이션을 생성합니다.
```
oc new-project test-ingress
```
```
 $ oc new-project test-ingress
```
Copy to Clipboard Toggle word wrap
```
oc new-app django-psql-example
```
```
$ oc new-app django-psql-example
```
Copy to Clipboard Toggle word wrap
503 사용자 정의 http 오류 코드 응답의 경우:
1. 애플리케이션의 모든 pod를 중지합니다.
2. 다음 curl 명령을 실행하거나 브라우저에서 경로 호스트 이름을 방문합니다.
  $ curl -vk <route_hostname>
  Copy to Clipboard Toggle word wrap
404 사용자 정의 http 오류 코드 응답의 경우:
1. 존재하지 않는 경로 또는 잘못된 경로를 방문합니다.
2. 다음 curl 명령을 실행하거나 브라우저에서 경로 호스트 이름을 방문합니다.
  $ curl -vk <route_hostname>
  Copy to Clipboard Toggle word wrap

errorfile 속성이 haproxy.config 파일에 제대로 있는지 확인합니다.

oc -n openshift-ingress rsh <router> cat /var/lib/haproxy/conf/haproxy.config | grep errorfile

$ oc -n openshift-ingress rsh <router> cat /var/lib/haproxy/conf/haproxy.config | grep errorfile

Copy to Clipboard

Toggle word wrap

6.8.19. Ingress 컨트롤러 최대 연결 설정
링크 복사

클러스터 관리자는 OpenShift 라우터 배포에 대한 최대 동시 연결 수를 설정할 수 있습니다. 기존 Ingress 컨트롤러를 패치하여 최대 연결 수를 늘릴 수 있습니다.

사전 요구 사항

다음은 Ingress 컨트롤러를 이미 생성했다고 가정합니다.

절차

HAProxy에 대한 최대 연결 수를 변경하려면 Ingress 컨트롤러를 업데이트합니다.
```
oc -n openshift-ingress-operator patch ingresscontroller/default --type=merge -p '{"spec":{"tuningOptions": {"maxConnections": 7500}}}'
```
```
$ oc -n openshift-ingress-operator patch ingresscontroller/default --type=merge -p '{"spec":{"tuningOptions": {"maxConnections": 7500}}}'
```
Copy to Clipboard Toggle word wrap
주의
spec.tuningOptions.maxConnections 값을 현재 운영 체제 제한보다 크게 설정하면 HAProxy 프로세스가 시작되지 않습니다. 이 매개변수에 대한 자세한 내용은 "Ingress Controller 구성 매개변수" 섹션의 표를 참조하십시오.

7장. OpenShift Container Platform의 Ingress 분할
링크 복사

OpenShift Container Platform에서 Ingress 컨트롤러는 모든 경로를 제공하거나 경로 서브 세트를 제공할 수 있습니다. 기본적으로 Ingress 컨트롤러는 클러스터의 모든 네임스페이스에서 생성된 모든 경로를 제공합니다. 선택한 특성을 기반으로 경로의 하위 집합인 shard 를 생성하여 라우팅을 최적화하도록 클러스터에 Ingress 컨트롤러를 추가할 수 있습니다. 경로를 shard의 멤버로 표시하려면 경로 또는 네임스페이스 메타데이터 필드에 라벨을 사용합니다. Ingress 컨트롤러는 선택 표현식 이라고도 하는 선택기 를 사용하여 제공할 전체 경로 풀에서 경로 서브 세트를 선택합니다.

Ingress 분할은 트래픽을 특정 Ingress 컨트롤러로 라우팅하거나 다음 섹션에 설명된 다양한 이유로 트래픽을 분리하려는 경우 여러 Ingress 컨트롤러에서 들어오는 트래픽을 로드 밸런싱하려는 경우에 유용합니다.

기본적으로 각 경로는 클러스터의 기본 도메인을 사용합니다. 그러나 라우터 도메인을 대신 사용하도록 경로를 구성할 수 있습니다. 자세한 내용은 Ingress 컨트롤러 Sharding의 경로 생성 을 참조하십시오.

7.1. Ingress 컨트롤러 분할
링크 복사

라우터 샤딩이라고도 하는 Ingress 샤딩을 사용하여 경로, 네임스페이스 또는 둘 다에 라벨을 추가하여 여러 라우터에 경로 집합을 배포할 수 있습니다. Ingress 컨트롤러는 해당 선택기 세트를 사용하여 지정된 라벨이 있는 경로만 허용합니다. 각 Ingress shard는 지정된 선택 표현식을 사용하여 필터링되는 경로로 구성됩니다.

트래픽이 클러스터로 유입되는 기본 메커니즘으로 Ingress 컨트롤러의 요구 사항이 중요할 수 있습니다. 클러스터 관리자는 다음을 위해 경로를 분할할 수 있습니다.

여러 경로를 통해 Ingress 컨트롤러 또는 라우터를 로드 밸런싱하여 변경에 대한 응답 속도 향상
특정 경로가 나머지 경로와 다른 수준의 신뢰성을 가지도록 할당
특정 Ingress 컨트롤러에 다른 정책을 정의할 수 있도록 허용
특정 경로만 추가 기능을 사용하도록 허용
예를 들어, 내부 및 외부 사용자가 다른 경로를 볼 수 있도록 다른 주소에 다른 경로를 노출
녹색 배포 중에 애플리케이션의 한 버전에서 다른 버전으로 트래픽을 전송합니다.

Ingress 컨트롤러가 분할되면 지정된 경로가 그룹의 0개 이상의 Ingress 컨트롤러에 허용됩니다. 경로 상태는 Ingress 컨트롤러가 승인했는지 여부를 나타냅니다. Ingress 컨트롤러는 해당 shard에 고유한 경우에만 경로를 허용합니다.

Ingress 컨트롤러는 세 가지 분할 방법을 사용할 수 있습니다.

네임스페이스 선택기와 일치하는 라벨이 있는 네임스페이스의 모든 경로가 Ingress shard에 있도록 Ingress 컨트롤러에 네임스페이스 선택기만 추가합니다.
경로 선택기와 일치하는 레이블이 있는 모든 경로가 Ingress shard에 있도록 Ingress 컨트롤러에 경로 선택기만 추가합니다.
네임스페이스 선택기와 경로 선택기를 모두 Ingress 컨트롤러에 추가하여 네임스페이스 선택기와 일치하는 라벨과 일치하는 라벨이 있는 레이블이 있는 경로가 Ingress shard에 있도록 합니다.

샤딩을 사용하면 여러 Ingress 컨트롤러에 경로 서브 세트를 배포할 수 있습니다. 이러한 서브셋은 오버라이프(over-overla)이거나, 기존 샤딩(Sampling)이라고도 하며, 중복되는 분할이라고 할 수 있습니다.

7.1.1. 기존 분할 예
링크 복사

Ingress 컨트롤러 finops-router 는 label selector spec.namespaceSelector.matchLabels.name 을 Thanos 및 ops 로 설정하여 구성됩니다.

finops-router에 대한 YAML 정의의 예

apiVersion: v1
items:
- apiVersion: operator.openshift.io/v1
  kind: IngressController
  metadata:
    name: finops-router
    namespace: openshift-ingress-operator
  spec:
    namespaceSelector:
      matchLabels:
        name:
          - finance
          - ops

apiVersion: v1
items:
- apiVersion: operator.openshift.io/v1
  kind: IngressController
  metadata:
    name: finops-router
    namespace: openshift-ingress-operator
  spec:
    namespaceSelector:
      matchLabels:
        name:
          - finance
          - ops

Copy to Clipboard

Toggle word wrap

두 번째 Ingress 컨트롤러 dev-router 는 라벨 선택기 spec.namespaceSelector.matchLabels.name 을 dev 로 설정하여 구성됩니다.

dev-routerYAML 정의의 예

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

apiVersion: v1
items:
- 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 경로는 처리해서는 안 됩니다.

위의 시나리오에서는 분할이 중복된 하위 집합이 없는 특별한 파티션 케이스가 됩니다. 경로는 라우터 shard 간에 나뉩니다.

주의

namespaceSelector 또는 routeSelector 필드에 제외를 위한 경로가 포함되지 않는 한 기본 Ingress 컨트롤러는 모든 경로를 계속 제공합니다. 기본 Ingress 컨트롤러에서 경로를 제외하는 방법에 대한 자세한 내용은 이 Red Hat Knowledgebase 솔루션 및 "기본 Ingress 컨트롤러 삭제" 섹션을 참조하십시오.

7.1.2. 중복된 분할 예
링크 복사

위의 예에서 finops-router 및 dev-router 외에도, dev 및 ops 로 설정된 라벨 선택기 spec.namespaceSelector.matchLabels.name 으로 구성됩니다.

ECDHE -router에 대한 YAML정의의 예

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

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

Copy to Clipboard

Toggle word wrap

name:dev 및 name:ops 레이블이 지정된 네임스페이스의 경로는 이제 서로 다른 두 개의 Ingress 컨트롤러에서 서비스를 제공합니다. 이 구성을 사용하면 경로가 중복되는 하위 집합이 있습니다.

경로의 중복된 하위 집합을 사용하면 더 복잡한 라우팅 규칙을 생성할 수 있습니다. 예를 들어 전용 finops-router 로 더 높은 우선 순위 트래픽을 전환하면서 더 낮은 우선 순위 트래픽을ECDHE -router 로 전송할 수 있습니다.

7.1.3. 기본 Ingress 컨트롤러 분할
링크 복사

새 Ingress shard를 생성한 후 기본 Ingress 컨트롤러에도 적용되는 새 Ingress shard에 적용되는 경로가 있을 수 있습니다. 이는 기본 Ingress 컨트롤러에 선택기가 없고 기본적으로 모든 경로를 허용하기 때문입니다.

네임스페이스 선택기 또는 경로 선택기를 사용하여 특정 라벨을 사용하여 Ingress 컨트롤러를 서비스 경로에서 제한할 수 있습니다. 다음 절차에서는 기본 Ingress 컨트롤러가 네임스페이스 선택기를 사용하여 새로 분할된 Thanos ,ops, dev 경로를 서비스하지 못하도록 제한합니다. 이렇게 하면 Ingress shard에 더 많은 격리가 추가되었습니다.

중요

모든 OpenShift Container Platform 관리 경로를 동일한 Ingress 컨트롤러에 보관해야 합니다. 따라서 이러한 필수 경로를 제외하는 기본 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

jaeger ,ops, dev 라벨이 있는 경로를 제외하는 namespaceSelector 를 포함 하도록 Ingress 컨트롤러를 편집합니다.

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

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

Copy to Clipboard

Toggle word wrap

기본 Ingress 컨트롤러는 더 이상 name:finance,name:ops, name:dev 로 레이블이 지정된 네임스페이스를 제공하지 않습니다.

7.1.4. Ingress 분할 및 DNS
링크 복사

클러스터 관리자는 프로젝트의 각 라우터에 대해 별도의 DNS 항목을 수행해야 합니다. 라우터는 알 수 없는 경로를 다른 라우터로 전달하지 않습니다.

다음 예제를 고려하십시오.

라우터 A는 호스트 192.168.0.5에 존재하며 *.foo.com 이 있는 경로가 있습니다.
라우터 B는 호스트 192.168.1.9에 있으며 *.example.com 이 있는 경로가 있습니다.

별도의 DNS 항목은 라우터 A 및 *.example.com 을 라우터 B를 호스팅하는 노드에 *.foo.com 으로 확인해야 합니다.

*.foo.com A IN 192.168.0.5
*.example.com A IN 192.168.1.9

7.1.5. 경로 라벨을 사용하여 Ingress 컨트롤러 분할 구성
링크 복사

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

그림 7.1. 경로 라벨을 사용한 Ingress 분할

Ingress 컨트롤러 분할은 들어오는 트래픽 부하를 일련의 Ingress 컨트롤러에 균형 있게 분배하고 트래픽을 특정 Ingress 컨트롤러에 격리할 때 유용합니다. 예를 들어, 회사 A는 하나의 Ingress 컨트롤러로, 회사 B는 다른 Ingress 컨트롤러로 이동합니다.

프로세스

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

cat router-internal.yaml
apiVersion: v1
items:
- 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
  status: {}
kind: List
metadata:
  resourceVersion: ""
  selfLink: ""

# cat router-internal.yaml
apiVersion: v1
items:
- 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
  status: {}
kind: List
metadata:
  resourceVersion: ""
  selfLink: ""

Copy to Clipboard

Toggle word wrap

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 라벨이 있는 네임스페이스에서 경로를 선택합니다.

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

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

그림 7.2. 네임스페이스 라벨을 사용한 Ingress 분할

Ingress 컨트롤러 분할은 들어오는 트래픽 부하를 일련의 Ingress 컨트롤러에 균형 있게 분배하고 트래픽을 특정 Ingress 컨트롤러에 격리할 때 유용합니다. 예를 들어, 회사 A는 하나의 Ingress 컨트롤러로, 회사 B는 다른 Ingress 컨트롤러로 이동합니다.

프로세스

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

cat router-internal.yaml

# cat router-internal.yaml

Copy to Clipboard

Toggle word wrap

출력 예

apiVersion: v1
items:
- 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
  status: {}
kind: List
metadata:
  resourceVersion: ""
  selfLink: ""

apiVersion: v1
items:
- 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
  status: {}
kind: List
metadata:
  resourceVersion: ""
  selfLink: ""

Copy to Clipboard

Toggle word wrap

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 라벨이 있는 네임스페이스에서 경로를 선택합니다.

7.2. Ingress 컨트롤러 분할을 위한 경로 생성
링크 복사

경로를 사용하면 URL에서 애플리케이션을 호스팅할 수 있습니다. 이 경우 호스트 이름이 설정되지 않고 경로는 대신 하위 도메인을 사용합니다. 하위 도메인을 지정하면 경로를 노출하는 Ingress 컨트롤러의 도메인을 자동으로 사용합니다. 여러 Ingress 컨트롤러에서 경로가 노출되는 경우 경로는 여러 URL에서 호스팅됩니다.

다음 절차에서는 hello-openshift 애플리케이션을 예제로 사용하여 Ingress 컨트롤러 분할에 대한 경로를 생성하는 방법을 설명합니다.

Ingress 컨트롤러 분할은 들어오는 트래픽 부하를 일련의 Ingress 컨트롤러에 균형 있게 분배하고 트래픽을 특정 Ingress 컨트롤러에 격리할 때 유용합니다. 예를 들어, 회사 A는 하나의 Ingress 컨트롤러로, 회사 B는 다른 Ingress 컨트롤러로 이동합니다.

사전 요구 사항

OpenShift CLI(oc)를 설치합니다.
프로젝트 관리자로 로그인되어 있습니다.
포트에서 트래픽을 수신 대기하는 포트 및 HTTP 또는 TLS 엔드포인트를 노출하는 웹 애플리케이션이 있습니다.
분할을 위해 Ingress 컨트롤러가 구성되어 있습니다.

프로세스

다음 명령을 실행하여 hello-openshift 라는 프로젝트를 생성합니다.
```
oc new-project hello-openshift
```
```
$ oc new-project hello-openshift
```
Copy to Clipboard Toggle word wrap

다음 명령을 실행하여 프로젝트에 Pod를 생성합니다.

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 컨트롤러에 지정된 라벨과 일치해야 합니다. 이 예제에서 Ingress 컨트롤러에는 레이블 키와 값 type: sharded 가 있습니다.
2
경로는 subdomain 필드의 값을 사용하여 노출됩니다. 하위 도메인 필드를 지정할 때 호스트 이름을 설정되지 않은 상태로 두어야 합니다. host 및 subdomain 필드를 모두 지정하면 경로는 호스트 필드의 값을 사용하고 subdomain 필드를 무시합니다.
다음 명령을 실행하여 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>

1


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

2


    routerName: sharded

3

Copy to Clipboard

Toggle word wrap

1: Ingress 컨트롤러 또는 라우터에서 경로를 노출하는 데 사용하는 호스트 이름입니다. host 필드의 값은 Ingress 컨트롤러에 의해 자동으로 결정되며 도메인을 사용합니다. 이 예제에서 Ingress 컨트롤러의 도메인은 < apps-sharded.basedomain.example.net>입니다.
2: Ingress 컨트롤러의 호스트 이름입니다.
3: Ingress 컨트롤러의 이름입니다. 이 예제에서 Ingress 컨트롤러에는 이름 sharded 가 있습니다.

추가 리소스

기본 Ingress 컨트롤러(라우터) 성능

8장. Ingress 컨트롤러 끝점 게시 전략 구성
링크 복사

8.1. Ingress 컨트롤러 끝점 게시 전략
링크 복사

NodePortService 끝점 게시 전략

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

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

그림 8.1. Diagram of NodePortService

이전 그래픽에서는 OpenShift Container Platform Ingress NodePort 끝점 게시 전략에 대한 다음 개념을 보여줍니다.

클러스터에서 사용 가능한 모든 노드에는 외부에서 액세스할 수 있는 자체 IP 주소가 있습니다. 클러스터에서 실행 중인 서비스는 모든 노드의 고유한 NodePort에 바인딩됩니다.
클라이언트가 그래픽에 10.0.128.4 IP 주소를 연결하여 다운된 노드에 클라이언트가 연결되면 노드 포트는 서비스를 실행 중인 사용 가능한 노드에 클라이언트를 직접 연결합니다. 이 시나리오에서는 로드 밸런싱이 필요하지 않습니다. 이미지가 표시된 대로 10.0.128.4 주소가 다운되어 다른 IP 주소를 대신 사용해야 합니다.

참고

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

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

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

HostNetwork 끝점 게시 전략

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

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

8.1.1. Ingress 컨트롤러 끝점 게시 범위를 Internal에 구성
링크 복사

클러스터 관리자가 클러스터가 프라이빗으로 지정되도록 지정하지 않고 새 클러스터를 설치하면 기본 Ingress 컨트롤러가 External 로 설정된 범위를 사용하여 생성됩니다. 클러스터 관리자는 외부 범위 Ingress 컨트롤러를 Internal 로 변경할 수 있습니다.

사전 요구 사항

oc CLI를 설치했습니다.

절차

외부 범위가 지정된 Ingress 컨트롤러를 Internal 로 변경하려면 다음 명령을 입력합니다.

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 컨트롤러의 상태를 확인하려면 다음 명령을 입력합니다.
```
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
- Progressing 상태 조건은 추가 작업을 수행해야 하는지 여부를 나타냅니다. 예를 들어 상태 조건은 다음 명령을 입력하여 서비스를 삭제해야 함을 나타낼 수 있습니다.
  $ oc -n openshift-ingress delete services/router-default
  Copy to Clipboard Toggle word wrap
  서비스를 삭제하면 Ingress Operator에서 내부로 다시 생성합니다.

8.1.2. Ingress 컨트롤러 끝점 게시 범위를 외부로 구성
링크 복사

클러스터 관리자가 클러스터가 프라이빗으로 지정되도록 지정하지 않고 새 클러스터를 설치하면 기본 Ingress 컨트롤러가 External 로 설정된 범위를 사용하여 생성됩니다.

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

중요

일부 플랫폼에서는 서비스를 삭제하고 다시 생성해야 합니다.

범위를 변경하면 몇 분 동안 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 컨트롤러의 상태를 확인하려면 다음 명령을 입력합니다.
```
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
- Progressing 상태 조건은 추가 작업을 수행해야 하는지 여부를 나타냅니다. 예를 들어 상태 조건은 다음 명령을 입력하여 서비스를 삭제해야 함을 나타낼 수 있습니다.
  $ oc -n openshift-ingress delete services/router-default
  Copy to Clipboard Toggle word wrap
  서비스를 삭제하면 Ingress Operator가 외부로 다시 생성합니다.

9장. 끝점에 대한 연결 확인
링크 복사

CNO(Cluster Network Operator)는 클러스터 내 리소스 간에 연결 상태 검사를 수행하는 연결 확인 컨트롤러인 컨트롤러를 실행합니다. 상태 점검 결과를 검토하여 연결 문제를 진단하거나 현재 조사하고 있는 문제의 원인으로 네트워크 연결을 제거할 수 있습니다.

9.1. 연결 상태 점검 수행
링크 복사

클러스터 리소스에 도달할 수 있는지 확인하기 위해 다음 클러스터 API 서비스 각각에 TCP 연결이 수행됩니다.

Kubernetes API 서버 서비스
Kubernetes API 서버 끝점
OpenShift API 서버 서비스
OpenShift API 서버 끝점
로드 밸런서

클러스터의 모든 노드에서 서비스 및 서비스 끝점에 도달할 수 있는지 확인하기 위해 다음 대상 각각에 TCP 연결이 수행됩니다.

상태 점검 대상 서비스
상태 점검 대상 끝점

9.2. 연결 상태 점검 구현
링크 복사

연결 검증 컨트롤러는 클러스터의 연결 확인 검사를 오케스트레이션합니다. 연결 테스트의 결과는 openshift-network-diagnostics의 PodNetworkConnectivity 오브젝트에 저장됩니다. 연결 테스트는 병렬로 1분마다 수행됩니다.

CNO(Cluster Network Operator)는 클러스터에 여러 리소스를 배포하여 연결 상태 점검을 전달하고 수신합니다.

상태 점검 소스: 이 프로그램은 Deployment 오브젝트에서 관리하는 단일 포드 복제본 세트에 배포됩니다. 프로그램은 PodNetworkConnectivity 오브젝트를 사용하고 각 오브젝트에 지정된 spec.targetEndpoint에 연결됩니다.
상태 점검 대상: 클러스터의 모든 노드에서 데몬 세트의 일부로 배포된 포드입니다. 포드는 인바운드 상태 점검을 수신 대기합니다. 모든 노드에 이 포드가 있으면 각 노드로의 연결을 테스트할 수 있습니다.

9.3. PodNetworkConnectivityCheck 오브젝트 필드
링크 복사

PodNetworkConnectivityCheck 오브젝트 필드는 다음 표에 설명되어 있습니다.

Expand

표 9.1. PodNetworkConnectivityCheck 오브젝트 필드
필드	유형	설명
`metadata.name`	`string`	다음과 같은 형식의 오브젝트 이름: `<source>-to-<target>`. `<target>`에서 설명한 대상에는 다음 문자열 중 하나가 포함되어 있습니다. `load-balancer-api-external` `load-balancer-api-internal` `kubernetes-apiserver-endpoint` `kubernetes-apiserver-service-cluster` `network-check-target` `openshift-apiserver-endpoint` `openshift-apiserver-service-cluster`
`metadata.namespace`	`string`	오브젝트와 연결된 네임스페이스입니다. 이 값은 항상 `openshift-network-diagnostics`입니다.
`spec.sourcePod`	`string`	연결 확인이 시작된 포드의 이름입니다(예: `network-check-source-596b4c6566-rgh92`).
`spec.targetEndpoint`	`string`	연결 검사의 대상입니다(예: `api.devcluster.example.com:6443`).
`spec.tlsClientCert`	`object`	사용할 TLS 인증서 설정입니다.
`spec.tlsClientCert.name`	`string`	해당하는 경우 사용되는 TLS 인증서의 이름입니다. 기본값은 빈 문자열입니다.
`status`	`object`	연결 테스트의 조건 및 최근 연결 성공 및 실패의 로그를 나타내는 오브젝트입니다.
`status.conditions`	`array`	연결 확인의 최신 상태 및 모든 이전 상태입니다.
`status.failures`	`array`	실패한 시도에서의 연결 테스트 로그입니다.
`status.outages`	`array`	중단 기간을 포함하는 테스트 로그를 연결합니다.
`status.successes`	`array`	성공적인 시도에서의 연결 테스트 로그입니다.

다음 표에서는 status.conditions 배열에서 오브젝트 필드를 설명합니다.

Expand

표 9.2. status.conditions
필드	유형	설명
`lastTransitionTime`	`string`	연결 조건이 하나의 상태에서 다른 상태로 전환된 시간입니다.
`message`	`string`	사람이 읽기 쉬운 형식으로 마지막 전환에 대한 세부 정보입니다.
`reason`	`string`	머신에서 읽을 수 있는 형식으로 전환의 마지막 상태입니다.
`status`	`string`	조건의 상태:
`type`	`string`	조건의 유형입니다.

다음 표에서는 status.conditions 배열에서 오브젝트 필드를 설명합니다.

Expand

표 9.3. status.outages
필드	유형	설명
`end`	`string`	연결 오류가 해결될 때부터의 타임 스탬프입니다.
`endLogs`	`array`	서비스 중단의 성공적인 종료와 관련된 로그 항목을 포함한 연결 로그 항목입니다.
`message`	`string`	사람이 읽을 수 있는 형식의 중단 세부 정보에 대한 요약입니다.
`start`	`string`	연결 오류가 먼저 감지될 때부터의 타임 스탬프입니다.
`startLogs`	`array`	원래 오류를 포함한 연결 로그 항목입니다.

연결 로그 필드

연결 로그 항목의 필드는 다음 표에 설명되어 있습니다. 오브젝트는 다음 필드에서 사용됩니다.

status.failures[]
status.successes[]
status.outages[].startLogs[]
status.outages[].endLogs[]

Expand

표 9.4. 연결 로그 오브젝트
필드	유형	설명
`latency`	`string`	작업 기간을 기록합니다.
`message`	`string`	사람이 읽을 수 있는 형식으로 상태를 제공합니다.
`reason`	`string`	머신에서 읽을 수 있는 형식으로 상태의 이유를 제공합니다. 값은 `TCPConnect`, `TCPConnectError`, `DNSResolve`, `DNSError` 중 하나입니다.
`success`	`boolean`	로그 항목이 성공 또는 실패인지를 나타냅니다.
`time`	`string`	연결 확인 시작 시간입니다.

9.4. 끝점에 대한 네트워크 연결 확인
링크 복사

클러스터 관리자는 API 서버, 로드 밸런서, 서비스 또는 포드와 같은 끝점의 연결을 확인할 수 있습니다.

사전 요구 사항

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

프로세스

현재 PodNetworkConnectivityCheck 오브젝트를 나열하려면 다음 명령을 입력합니다.

oc get podnetworkconnectivitycheck -n openshift-network-diagnostics

$ oc get podnetworkconnectivitycheck -n openshift-network-diagnostics

Copy to Clipboard

Toggle word wrap

출력 예

NAME                                                                                                                                AGE
network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0   75m
network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-1   73m
network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-2   75m
network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-kubernetes-apiserver-service-cluster                               75m
network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-kubernetes-default-service-cluster                                 75m
network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-load-balancer-api-external                                         75m
network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-load-balancer-api-internal                                         75m
network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-target-ci-ln-x5sv9rb-f76d1-4rzrp-master-0            75m
network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-target-ci-ln-x5sv9rb-f76d1-4rzrp-master-1            75m
network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-target-ci-ln-x5sv9rb-f76d1-4rzrp-master-2            75m
network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-target-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh      74m
network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-target-ci-ln-x5sv9rb-f76d1-4rzrp-worker-c-n8mbf      74m
network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-target-ci-ln-x5sv9rb-f76d1-4rzrp-worker-d-4hnrz      74m
network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-target-service-cluster                               75m
network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-openshift-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0    75m
network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-openshift-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-1    75m
network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-openshift-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-2    74m
network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-openshift-apiserver-service-cluster                                75m

NAME                                                                                                                                AGE
network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0   75m
network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-1   73m
network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-2   75m
network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-kubernetes-apiserver-service-cluster                               75m
network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-kubernetes-default-service-cluster                                 75m
network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-load-balancer-api-external                                         75m
network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-load-balancer-api-internal                                         75m
network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-target-ci-ln-x5sv9rb-f76d1-4rzrp-master-0            75m
network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-target-ci-ln-x5sv9rb-f76d1-4rzrp-master-1            75m
network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-target-ci-ln-x5sv9rb-f76d1-4rzrp-master-2            75m
network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-target-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh      74m
network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-target-ci-ln-x5sv9rb-f76d1-4rzrp-worker-c-n8mbf      74m
network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-target-ci-ln-x5sv9rb-f76d1-4rzrp-worker-d-4hnrz      74m
network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-target-service-cluster                               75m
network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-openshift-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0    75m
network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-openshift-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-1    75m
network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-openshift-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-2    74m
network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-openshift-apiserver-service-cluster                                75m

Copy to Clipboard

Toggle word wrap

연결 테스트 로그를 확인합니다.

이전 명령의 출력에서 연결 로그를 검토할 끝점을 식별합니다.

오브젝트를 확인하려면 다음 명령을 입력합니다:

oc get podnetworkconnectivitycheck <name> \
  -n openshift-network-diagnostics -o yaml

$ oc get podnetworkconnectivitycheck <name> \
  -n openshift-network-diagnostics -o yaml

Copy to Clipboard

Toggle word wrap

여기서 <name>은 PodNetworkConnectivityCheck 오브젝트의 이름을 지정합니다.

출력 예

apiVersion: controlplane.operator.openshift.io/v1alpha1
kind: PodNetworkConnectivityCheck
metadata:
  name: network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0
  namespace: openshift-network-diagnostics
  ...
spec:
  sourcePod: network-check-source-7c88f6d9f-hmg2f
  targetEndpoint: 10.0.0.4:6443
  tlsClientCert:
    name: ""
status:
  conditions:
  - lastTransitionTime: "2021-01-13T20:11:34Z"
    message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
      connection to 10.0.0.4:6443 succeeded'
    reason: TCPConnectSuccess
    status: "True"
    type: Reachable
  failures:
  - latency: 2.241775ms
    message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: failed
      to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443: connect:
      connection refused'
    reason: TCPConnectError
    success: false
    time: "2021-01-13T20:10:34Z"
  - latency: 2.582129ms
    message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: failed
      to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443: connect:
      connection refused'
    reason: TCPConnectError
    success: false
    time: "2021-01-13T20:09:34Z"
  - latency: 3.483578ms
    message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: failed
      to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443: connect:
      connection refused'
    reason: TCPConnectError
    success: false
    time: "2021-01-13T20:08:34Z"
  outages:
  - end: "2021-01-13T20:11:34Z"
    endLogs:
    - latency: 2.032018ms
      message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0:
        tcp connection to 10.0.0.4:6443 succeeded'
      reason: TCPConnect
      success: true
      time: "2021-01-13T20:11:34Z"
    - latency: 2.241775ms
      message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0:
        failed to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443:
        connect: connection refused'
      reason: TCPConnectError
      success: false
      time: "2021-01-13T20:10:34Z"
    - latency: 2.582129ms
      message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0:
        failed to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443:
        connect: connection refused'
      reason: TCPConnectError
      success: false
      time: "2021-01-13T20:09:34Z"
    - latency: 3.483578ms
      message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0:
        failed to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443:
        connect: connection refused'
      reason: TCPConnectError
      success: false
      time: "2021-01-13T20:08:34Z"
    message: Connectivity restored after 2m59.999789186s
    start: "2021-01-13T20:08:34Z"
    startLogs:
    - latency: 3.483578ms
      message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0:
        failed to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443:
        connect: connection refused'
      reason: TCPConnectError
      success: false
      time: "2021-01-13T20:08:34Z"
  successes:
  - latency: 2.845865ms
    message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
      connection to 10.0.0.4:6443 succeeded'
    reason: TCPConnect
    success: true
    time: "2021-01-13T21:14:34Z"
  - latency: 2.926345ms
    message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
      connection to 10.0.0.4:6443 succeeded'
    reason: TCPConnect
    success: true
    time: "2021-01-13T21:13:34Z"
  - latency: 2.895796ms
    message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
      connection to 10.0.0.4:6443 succeeded'
    reason: TCPConnect
    success: true
    time: "2021-01-13T21:12:34Z"
  - latency: 2.696844ms
    message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
      connection to 10.0.0.4:6443 succeeded'
    reason: TCPConnect
    success: true
    time: "2021-01-13T21:11:34Z"
  - latency: 1.502064ms
    message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
      connection to 10.0.0.4:6443 succeeded'
    reason: TCPConnect
    success: true
    time: "2021-01-13T21:10:34Z"
  - latency: 1.388857ms
    message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
      connection to 10.0.0.4:6443 succeeded'
    reason: TCPConnect
    success: true
    time: "2021-01-13T21:09:34Z"
  - latency: 1.906383ms
    message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
      connection to 10.0.0.4:6443 succeeded'
    reason: TCPConnect
    success: true
    time: "2021-01-13T21:08:34Z"
  - latency: 2.089073ms
    message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
      connection to 10.0.0.4:6443 succeeded'
    reason: TCPConnect
    success: true
    time: "2021-01-13T21:07:34Z"
  - latency: 2.156994ms
    message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
      connection to 10.0.0.4:6443 succeeded'
    reason: TCPConnect
    success: true
    time: "2021-01-13T21:06:34Z"
  - latency: 1.777043ms
    message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
      connection to 10.0.0.4:6443 succeeded'
    reason: TCPConnect
    success: true
    time: "2021-01-13T21:05:34Z"

apiVersion: controlplane.operator.openshift.io/v1alpha1
kind: PodNetworkConnectivityCheck
metadata:
  name: network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0
  namespace: openshift-network-diagnostics
  ...
spec:
  sourcePod: network-check-source-7c88f6d9f-hmg2f
  targetEndpoint: 10.0.0.4:6443
  tlsClientCert:
    name: ""
status:
  conditions:
  - lastTransitionTime: "2021-01-13T20:11:34Z"
    message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
      connection to 10.0.0.4:6443 succeeded'
    reason: TCPConnectSuccess
    status: "True"
    type: Reachable
  failures:
  - latency: 2.241775ms
    message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: failed
      to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443: connect:
      connection refused'
    reason: TCPConnectError
    success: false
    time: "2021-01-13T20:10:34Z"
  - latency: 2.582129ms
    message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: failed
      to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443: connect:
      connection refused'
    reason: TCPConnectError
    success: false
    time: "2021-01-13T20:09:34Z"
  - latency: 3.483578ms
    message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: failed
      to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443: connect:
      connection refused'
    reason: TCPConnectError
    success: false
    time: "2021-01-13T20:08:34Z"
  outages:
  - end: "2021-01-13T20:11:34Z"
    endLogs:
    - latency: 2.032018ms
      message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0:
        tcp connection to 10.0.0.4:6443 succeeded'
      reason: TCPConnect
      success: true
      time: "2021-01-13T20:11:34Z"
    - latency: 2.241775ms
      message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0:
        failed to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443:
        connect: connection refused'
      reason: TCPConnectError
      success: false
      time: "2021-01-13T20:10:34Z"
    - latency: 2.582129ms
      message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0:
        failed to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443:
        connect: connection refused'
      reason: TCPConnectError
      success: false
      time: "2021-01-13T20:09:34Z"
    - latency: 3.483578ms
      message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0:
        failed to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443:
        connect: connection refused'
      reason: TCPConnectError
      success: false
      time: "2021-01-13T20:08:34Z"
    message: Connectivity restored after 2m59.999789186s
    start: "2021-01-13T20:08:34Z"
    startLogs:
    - latency: 3.483578ms
      message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0:
        failed to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443:
        connect: connection refused'
      reason: TCPConnectError
      success: false
      time: "2021-01-13T20:08:34Z"
  successes:
  - latency: 2.845865ms
    message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
      connection to 10.0.0.4:6443 succeeded'
    reason: TCPConnect
    success: true
    time: "2021-01-13T21:14:34Z"
  - latency: 2.926345ms
    message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
      connection to 10.0.0.4:6443 succeeded'
    reason: TCPConnect
    success: true
    time: "2021-01-13T21:13:34Z"
  - latency: 2.895796ms
    message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
      connection to 10.0.0.4:6443 succeeded'
    reason: TCPConnect
    success: true
    time: "2021-01-13T21:12:34Z"
  - latency: 2.696844ms
    message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
      connection to 10.0.0.4:6443 succeeded'
    reason: TCPConnect
    success: true
    time: "2021-01-13T21:11:34Z"
  - latency: 1.502064ms
    message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
      connection to 10.0.0.4:6443 succeeded'
    reason: TCPConnect
    success: true
    time: "2021-01-13T21:10:34Z"
  - latency: 1.388857ms
    message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
      connection to 10.0.0.4:6443 succeeded'
    reason: TCPConnect
    success: true
    time: "2021-01-13T21:09:34Z"
  - latency: 1.906383ms
    message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
      connection to 10.0.0.4:6443 succeeded'
    reason: TCPConnect
    success: true
    time: "2021-01-13T21:08:34Z"
  - latency: 2.089073ms
    message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
      connection to 10.0.0.4:6443 succeeded'
    reason: TCPConnect
    success: true
    time: "2021-01-13T21:07:34Z"
  - latency: 2.156994ms
    message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
      connection to 10.0.0.4:6443 succeeded'
    reason: TCPConnect
    success: true
    time: "2021-01-13T21:06:34Z"
  - latency: 1.777043ms
    message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
      connection to 10.0.0.4:6443 succeeded'
    reason: TCPConnect
    success: true
    time: "2021-01-13T21:05:34Z"

Copy to Clipboard

Toggle word wrap

10장. 클러스터 네트워크의 MTU 변경
링크 복사

클러스터 관리자는 클러스터 설치 후 클러스터 네트워크의 MTU를 변경할 수 있습니다. MTU 변경을 종료하려면 클러스터 노드를 재부팅해야 하므로 이러한 변경이 중단됩니다. OVN-Kubernetes 또는 OpenShift SDN 클러스터 네트워크 공급자를 사용하여 클러스터의 MTU만 변경할 수 있습니다.

10.1. 클러스터 MTU 정보
링크 복사

클러스터 네트워크의 최대 전송 단위(MTU)를 설치하는 동안 클러스터에 있는 노드의 기본 네트워크 인터페이스 MTU를 기반으로 자동으로 탐지됩니다. 일반적으로 감지된 MTU를 재정의할 필요는 없습니다.

다음과 같은 몇 가지 이유로 클러스터 네트워크의 MTU를 변경할 수 있습니다.

클러스터 설치 중에 감지된 MTU가 인프라에 적합하지 않음
이제 클러스터 인프라에는 최적의 성능을 위해 다른 MTU가 필요한 노드 추가와 같이 다른 MTU가 필요합니다.

OVN-Kubernetes 및 OpenShift SDN 클러스터 네트워크 공급자에 대해서만 클러스터 MTU를 변경할 수 있습니다.

10.1.1. 서비스 중단 고려 사항
링크 복사

클러스터에서 MTU 변경을 시작하면 다음과 같은 결과가 서비스 가용성에 영향을 미칠 수 있습니다.

새 MTU로 마이그레이션을 완료하려면 두 개 이상의 롤링 재부팅이 필요합니다. 이 기간 동안 일부 노드를 재시작하기 때문에 사용할 수 없습니다.
절대 TCP 시간 초과 간격보다 짧은 시간 제한 간격을 사용하여 클러스터에 배포된 특정 애플리케이션은 MTU를 변경하는 동안 중단될 수 있습니다.

10.1.2. MTU 값 선택
링크 복사

MTU 마이그레이션을 계획할 때 다음과 같은 두 가지 MTU 값이 서로 다릅니다.

Hardware MTU:이 MTU 값은 네트워크 인프라의 세부 사항에 따라 설정됩니다.
클러스터 네트워크 MTU: 이 MTU 값은 클러스터 네트워크 오버레이 오버헤드를 고려하기 위해 하드웨어 MTU보다 항상 적습니다. 특정 오버헤드는 클러스터 네트워크 공급자에 의해 결정됩니다.
- OVN-Kubernetes:100 바이트
- OpenShift SDN:50 바이트

클러스터에 다른 노드에 대한 다른 MTU 값이 필요한 경우 클러스터의 모든 노드에서 사용하는 가장 낮은 MTU 값에서 클러스터 네트워크 공급자의 오버헤드 값을 제거해야 합니다. 예를 들어, 클러스터의 일부 노드에 9001의 MTU가 있고 일부에는 1500의 MTU가 있는 경우 이 값을 1400으로 설정해야 합니다.

10.1.3. 마이그레이션 프로세스의 작동 방식
링크 복사

다음 표는 프로세스의 사용자 시작 단계와 마이그레이션이 수행하는 작업 간에 분할하여 마이그레이션 프로세스를 요약합니다.

Expand

표 10.1. 클러스터 MTU의 실시간 마이그레이션
사용자 시작 단계	OpenShift Container Platform 활동
Cluster Network Operator 구성에서 다음 값을 설정합니다. `spec.migration.mtu.machine.to` `spec.migration.mtu.network.from` `spec.migration.mtu.network.to`	CNO(Cluster Network Operator): 각 필드가 유효한 값으로 설정되었는지 확인합니다. `mtu.machine.to` 는 하드웨어의 MTU를 변경하지 않는 경우 새 하드웨어 MTU 또는 현재 하드웨어 MTU로 설정해야 합니다. 이 값은 일시적인 것이며 마이그레이션 프로세스의 일부로 사용됩니다. 기존 하드웨어 MTU 값과 다른 하드웨어 MTU 값과 다른 하드웨어 MTU를 별도로 지정하는 경우 머신 구성, DHCP 설정 또는 Linux 커널 명령줄과 같은 다른 방법으로 MTU를 수동으로 구성해야 합니다. `mtu.network.from` 필드는 클러스터 네트워크의 현재 MTU인 `network.status.clusterNetworkMTU` 필드와 같아야 합니다. `mtu.network.to` 필드는 대상 클러스터 네트워크 MTU로 설정해야 하며 클러스터 네트워크 공급자의 오버레이 오버헤드를 허용하려면 하드웨어 MTU보다 작아야 합니다. OVN-Kubernetes의 경우 오버헤드는 `100` 바이트이고 OpenShift SDN의 경우 오버헤드는 `50` 바이트입니다. 제공된 값이 유효한 경우 CNO는 `mtu.network.to` 필드 값으로 설정된 클러스터 네트워크의 MTU를 사용하여 새 임시 구성을 기록합니다. MCO(Machine Config Operator): 클러스터의 각 노드의 롤링 재부팅을 수행합니다.
클러스터에 있는 노드의 기본 네트워크 인터페이스의 MTU를 재구성합니다. 다음을 포함하여 다양한 방법을 사용하여 이를 수행할 수 있습니다. MTU 변경 사항을 사용하여 새 NetworkManager 연결 프로필 배포 DHCP 서버 설정을 통해 MTU 변경 부팅 매개 변수를 통해 MTU 변경	해당 없음
클러스터 네트워크 공급자의 CNO 구성에서 `mtu` 값을 설정하고 `spec.migration` 을 `null` 로 설정합니다.	MCO(Machine Config Operator): 새 MTU 구성으로 클러스터의 각 노드가 롤링 재부팅을 수행합니다.

10.2. 클러스터 MTU 변경
링크 복사

클러스터 관리자는 클러스터의 최대 전송 단위(MTU)를 변경할 수 있습니다. 마이그레이션이 중단되고 MTU 업데이트가 롤아웃되므로 클러스터의 노드를 일시적으로 사용할 수 없게 될 수 있습니다.

다음 절차에서는 머신 구성, DHCP 또는 ISO를 사용하여 클러스터 MTU를 변경하는 방법을 설명합니다. DHCP 또는 ISO 접근법을 사용하는 경우 절차를 완료하기 위해 클러스터를 설치한 후 보관한 구성 아티팩트를 참조해야 합니다.

사전 요구 사항

OpenShift CLI(oc)를 설치합니다.
cluster-admin 권한이 있는 사용자로 클러스터에 로그인합니다.
클러스터의 대상 MTU를 확인했습니다. 올바른 MTU는 클러스터가 사용하는 클러스터 네트워크 공급자에 따라 다릅니다.
- OVN-Kubernetes: 클러스터 MTU는 클러스터의 가장 낮은 하드웨어 MTU 값보다 100 미만으로 설정되어야 합니다.
- OpenShift SDN: 클러스터 MTU는 클러스터에서 가장 낮은 하드웨어 MTU 값보다 50 미만으로 설정되어야 합니다.

절차

클러스터 네트워크의 MTU를 늘리거나 줄이려면 다음 절차를 완료합니다.

클러스터 네트워크의 현재 MTU를 가져오려면 다음 명령을 입력합니다.

oc describe network.config cluster

$ oc describe network.config cluster

Copy to Clipboard

Toggle word wrap

출력 예

...
Status:
  Cluster Network:
    Cidr:               10.217.0.0/22
    Host Prefix:        23
  Cluster Network MTU:  1400
  Network Type:         OpenShiftSDN
  Service Network:
    10.217.4.0/23
...

...
Status:
  Cluster Network:
    Cidr:               10.217.0.0/22
    Host Prefix:        23
  Cluster Network MTU:  1400
  Network Type:         OpenShiftSDN
  Service Network:
    10.217.4.0/23
...

Copy to Clipboard

Toggle word wrap

하드웨어 MTU 설정을 준비합니다.
- DHCP를 사용하여 하드웨어 MTU를 지정하는 경우 다음 dnsmasq 구성과 같은 DHCP 구성을 업데이트합니다.
  dhcp-option-force=26,<mtu>
  Copy to Clipboard Toggle word wrap
  다음과 같습니다.
  <mtu>
  알릴 DHCP 서버의 하드웨어 MTU를 지정합니다.
- PXE로 커널 명령줄을 사용하여 하드웨어 MTU를 지정하는 경우 그에 따라 해당 구성을 업데이트합니다.
- NetworkManager 연결 구성에 하드웨어 MTU를 지정하는 경우 다음 단계를 완료합니다. 이 방법은 DHCP, 커널 명령줄 또는 기타 방법으로 네트워크 구성을 명시적으로 지정하지 않은 경우 OpenShift Container Platform의 기본값입니다. 다음 절차에서는 클러스터 노드에서 모두 동일한 기본 네트워크 구성을 사용하여 수정되지 않은 상태로 작동해야 합니다.
  1. 기본 네트워크 인터페이스를 찾습니다.
    OpenShift SDN 클러스터 네트워크 공급자를 사용하는 경우 다음 명령을 입력합니다.
    
    $ oc debug node/<node_name> -- chroot /host ip route list match 0.0.0.0/0 | awk '{print $5 }'
    
    Copy to Clipboard Toggle word wrap
    
    다음과 같습니다.
    <node_name>
    클러스터의 노드 이름을 지정합니다.
    OVN-Kubernetes 클러스터 네트워크 공급자를 사용하는 경우 다음 명령을 입력합니다.
    
    $ oc debug node/<node_name> -- chroot /host nmcli -g connection.interface-name c show ovs-if-phys0
    
    Copy to Clipboard Toggle word wrap
    
    다음과 같습니다.
    <node_name>
    클러스터의 노드 이름을 지정합니다.
  2. 이전 명령에서 반환된 인터페이스 이름에 대해 NetworkManager가 생성한 연결 프로필을 찾으려면 다음 명령을 입력합니다.
    
    $ oc debug node/<node_name> -- chroot /host nmcli c | grep <interface>
    
    Copy to Clipboard Toggle word wrap
    
    다음과 같습니다.
    <interface>
    기본 네트워크 인터페이스의 이름을 지정합니다.
    OpenShift SDN의 출력 예
    
    Wired connection 1 46da4a6a-xxxx-xxxx-xxxx-ac0ca900f213 ethernet ens3
    
    Copy to Clipboard Toggle word wrap
    
    원래 연결 구성이 없는 OVN-Kubernetes의 출력 예
    
    ovs-if-phys0 353774d3-0d3d-4ada-b14e-cd4d8824e2a8 ethernet ens4 ovs-port-phys0 332ef950-b2e5-4991-a0dc-3158977c35ca ovs-port ens4
    
    Copy to Clipboard Toggle word wrap
    
    OVN-Kubernetes 클러스터 네트워크 공급자의 경우 2개 또는 3개의 연결 관리자 프로필이 반환됩니다.
    이전 명령에서 두 개의 프로필만 반환하는 경우 기본 NetworkManager 연결 구성을 템플릿으로 사용해야 합니다.
    이전 명령에서 세 개의 프로필을 반환하는 경우 다음 수정 사항에 대한 템플릿으로 ovs-if-phys0 또는 ovs-port-phys0 이라는 프로필을 사용합니다.
  3. 기본 네트워크 인터페이스에 대한 NetworkManager 연결 구성의 파일 이름을 가져오려면 다음 명령을 입력합니다.
    
    $ oc debug node/<node_name> -- chroot /host nmcli -g UUID,FILENAME c show | grep <uuid> | cut -d: -f2
    
    Copy to Clipboard Toggle word wrap
    
    다음과 같습니다.
    <node_name>
    클러스터의 노드 이름을 지정합니다.
    <uuid>
    NetworkManager 연결 프로필의 UUID를 지정합니다.
    출력 예
    
    /run/NetworkManager/system-connections/Wired connection 1.nmconnection
    
    Copy to Clipboard Toggle word wrap
  4. 노드에서 NetworkManager 연결 구성을 복사하려면 다음 명령을 입력합니다.
    
    $ oc debug node/<node_name> -- chroot /host cat "<profile_path>" > config.nmconnection
    
    Copy to Clipboard Toggle word wrap
    
    다음과 같습니다.
    <node_name>
    클러스터의 노드 이름을 지정합니다.
    <profile_path>
    이전 단계에서 NetworkManager 연결의 파일 시스템 경로를 지정합니다.
    NetworkManager 연결 구성 예
    
    [connection] id=Wired connection 1 uuid=3e96a02b-xxxx-xxxx-ad5d-61db28678130 type=ethernet autoconnect-priority=-999 interface-name=enp1s0 permissions= timestamp=1644109633 [ethernet] mac-address-blacklist= [ipv4] dns-search= method=auto [ipv6] addr-gen-mode=stable-privacy dns-search= method=auto [proxy] [.nmmeta] nm-generated=true
    
    Copy to Clipboard Toggle word wrap
  5. 이전 단계에서 config.nmconnection 파일에 저장된 NetworkManager 구성 파일을 편집합니다.
    다음 값을 설정합니다.
    802-3-Ethernet.mtu: 시스템의 기본 네트워크 인터페이스에 대한 MTU를 지정합니다.
    connection.interface-name: 선택 사항: 이 구성이 적용되는 네트워크 인터페이스 이름을 지정합니다.
    connection.autoconnect-priority: 선택 사항: 0 이상의 정수 우선 순위 값을 지정하여 이 프로필이 동일한 인터페이스에 대해 다른 프로필에서 사용되는지 확인하는 것이 좋습니다. OVN-Kubernetes 클러스터 네트워크 공급자를 사용하는 경우 이 값은 100 보다 작아야 합니다.
    connection.uuid 필드를 제거합니다.
    다음 값을 변경합니다.
    connection.id: 선택 사항: 다른 NetworkManager 연결 프로필 이름을 지정합니다.
    NetworkManager 연결 구성 예
    
    [connection] id=Primary network interface type=ethernet autoconnect-priority=10 interface-name=enp1s0 [802-3-ethernet] mtu=8051
    
    Copy to Clipboard Toggle word wrap
  6. 컨트롤 플레인 노드 및 클러스터의 작업자 노드에 대해 하나씩 두 개의 MachineConfig 오브젝트를 생성합니다.
    control-plane-interface.bu 파일에 다음 Butane 구성을 생성합니다.
    
    variant: openshift version: 4.11.0 metadata: name: 01-control-plane-interface labels: machineconfiguration.openshift.io/role: master storage: files: - path: /etc/NetworkManager/system-connections/<connection_name>
    1
    contents: local: config.nmconnection
    2
    mode: 0600
    
    Copy to Clipboard Toggle word wrap
    
    1
    기본 네트워크 인터페이스에 대한 NetworkManager 연결 이름을 지정합니다.
    2
    이전 단계에서 업데이트된 NetworkManager 구성 파일의 로컬 파일 이름을 지정합니다.
    worker-interface.bu 파일에 다음 Butane 구성을 생성합니다.
    
    variant: openshift version: 4.11.0 metadata: name: 01-worker-interface labels: machineconfiguration.openshift.io/role: worker storage: files: - path: /etc/NetworkManager/system-connections/<connection_name>
    1
    contents: local: config.nmconnection
    2
    mode: 0644
    
    Copy to Clipboard Toggle word wrap
    
    1
    기본 네트워크 인터페이스에 대한 NetworkManager 연결 이름을 지정합니다.
    2
    이전 단계에서 업데이트된 NetworkManager 구성 파일의 로컬 파일 이름을 지정합니다.
    다음 명령을 실행하여 Butane 구성에서 MachineConfig 오브젝트를 생성합니다.
    
    $ for manifest in control-plane-interface worker-interface; do butane --files-dir . $manifest.bu > $manifest.yaml done
    
    Copy to Clipboard Toggle word wrap
MTU 마이그레이션을 시작하려면 다음 명령을 입력하여 마이그레이션 구성을 지정합니다. Machine Config Operator는 MTU 변경을 준비하기 위해 클러스터에서 노드 롤링 재부팅을 수행합니다.
```
oc patch Network.operator.openshift.io cluster --type=merge --patch \
  '{"spec": { "migration": { "mtu": { "network": { "from": <overlay_from>, "to": <overlay_to> } , "machine": { "to" : <machine_to> } } } } }'
```
```
$ oc patch Network.operator.openshift.io cluster --type=merge --patch \
  '{"spec": { "migration": { "mtu": { "network": { "from": <overlay_from>, "to": <overlay_to> } , "machine": { "to" : <machine_to> } } } } }'
```
Copy to Clipboard Toggle word wrap
다음과 같습니다.
<overlay_from>
현재 클러스터 네트워크 MTU 값을 지정합니다.
<overlay_to>
클러스터 네트워크의 대상 MTU를 지정합니다. 이 값은 < machine_to > 값을 기준으로 설정되며 OVN-Kubernetes의 값은 100 미만이어야 하며 OpenShift SDN은 50 미만이어야 합니다.
<machine_to>
기본 호스트 네트워크의 기본 네트워크 인터페이스의 MTU를 지정합니다.
클러스터 MTU를 늘리는 예
```
oc patch Network.operator.openshift.io cluster --type=merge --patch \
  '{"spec": { "migration": { "mtu": { "network": { "from": 1400, "to": 9000 } , "machine": { "to" : 9100} } } } }'
```
```
$ oc patch Network.operator.openshift.io cluster --type=merge --patch \
  '{"spec": { "migration": { "mtu": { "network": { "from": 1400, "to": 9000 } , "machine": { "to" : 9100} } } } }'
```
Copy to Clipboard Toggle word wrap
MCO는 각 머신 구성 풀의 머신을 업데이트할 때 각 노드를 하나씩 재부팅합니다. 모든 노드가 업데이트될 때까지 기다려야 합니다. 다음 명령을 입력하여 머신 구성 풀 상태를 확인합니다.
```
oc get mcp
```
```
$ oc get mcp
```
Copy to Clipboard Toggle word wrap
업데이트된 노드의 상태가 UPDATED=true, UPDATING=false,DEGRADED=false입니다.
참고
기본적으로 MCO는 풀당 한 번에 하나의 시스템을 업데이트하므로 클러스터 크기에 따라 마이그레이션에 걸리는 총 시간이 증가합니다.

호스트의 새 머신 구성 상태를 확인합니다.

머신 구성 상태 및 적용된 머신 구성 이름을 나열하려면 다음 명령을 입력합니다.

oc describe node | egrep "hostname|machineconfig"

$ oc describe node | egrep "hostname|machineconfig"

Copy to Clipboard

Toggle word wrap

출력 예

kubernetes.io/hostname=master-0
machineconfiguration.openshift.io/currentConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b
machineconfiguration.openshift.io/desiredConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b
machineconfiguration.openshift.io/reason:
machineconfiguration.openshift.io/state: Done

kubernetes.io/hostname=master-0
machineconfiguration.openshift.io/currentConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b
machineconfiguration.openshift.io/desiredConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b
machineconfiguration.openshift.io/reason:
machineconfiguration.openshift.io/state: Done

Copy to Clipboard

Toggle word wrap

다음 구문이 올바른지 확인합니다.

machineconfiguration.openshift.io/state 필드의 값은 Done입니다.
machineconfiguration.openshift.io/currentConfig 필드의 값은 machineconfiguration.openshift.io/desiredConfig 필드의 값과 동일합니다.

머신 구성이 올바른지 확인하려면 다음 명령을 입력합니다.
```
oc get machineconfig <config_name> -o yaml | grep ExecStart
```
```
$ oc get machineconfig <config_name> -o yaml | grep ExecStart
```
Copy to Clipboard Toggle word wrap
여기서 <config_name>은 machineconfiguration.openshift.io/currentConfig 필드에서 머신 구성의 이름입니다.
머신 구성은 다음 업데이트를 systemd 구성에 포함해야 합니다.
```
ExecStart=/usr/local/bin/mtu-migration.sh
```
```
ExecStart=/usr/local/bin/mtu-migration.sh
```
Copy to Clipboard Toggle word wrap

기본 네트워크 인터페이스 MTU 값을 업데이트합니다.
- NetworkManager 연결 구성으로 새 MTU를 지정하는 경우 다음 명령을 입력합니다. MachineConfig Operator는 클러스터의 노드 롤링 재부팅을 자동으로 수행합니다.
  $ for manifest in control-plane-interface worker-interface; do oc create -f $manifest.yaml done
  Copy to Clipboard Toggle word wrap
- DHCP 서버 옵션 또는 커널 명령줄 및 PXE로 새 MTU를 지정하는 경우 인프라에 필요한 변경을 수행합니다.
MCO는 각 머신 구성 풀의 머신을 업데이트할 때 각 노드를 하나씩 재부팅합니다. 모든 노드가 업데이트될 때까지 기다려야 합니다. 다음 명령을 입력하여 머신 구성 풀 상태를 확인합니다.
```
oc get mcp
```
```
$ oc get mcp
```
Copy to Clipboard Toggle word wrap
업데이트된 노드의 상태가 UPDATED=true, UPDATING=false,DEGRADED=false입니다.
참고
기본적으로 MCO는 풀당 한 번에 하나의 시스템을 업데이트하므로 클러스터 크기에 따라 마이그레이션에 걸리는 총 시간이 증가합니다.
호스트의 새 머신 구성 상태를 확인합니다.
1. 머신 구성 상태 및 적용된 머신 구성 이름을 나열하려면 다음 명령을 입력합니다.
  $ oc describe node | egrep "hostname|machineconfig"
  Copy to Clipboard Toggle word wrap
  출력 예
  kubernetes.io/hostname=master-0 machineconfiguration.openshift.io/currentConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b machineconfiguration.openshift.io/desiredConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b machineconfiguration.openshift.io/reason: machineconfiguration.openshift.io/state: Done
  
  Copy to Clipboard Toggle word wrap
  다음 구문이 올바른지 확인합니다.
  - machineconfiguration.openshift.io/state 필드의 값은 Done입니다.
  - machineconfiguration.openshift.io/currentConfig 필드의 값은 machineconfiguration.openshift.io/desiredConfig 필드의 값과 동일합니다.
2. 머신 구성이 올바른지 확인하려면 다음 명령을 입력합니다.
  $ oc get machineconfig <config_name> -o yaml | grep path:
  Copy to Clipboard Toggle word wrap
  여기서 <config_name>은 machineconfiguration.openshift.io/currentConfig 필드에서 머신 구성의 이름입니다.
  머신 구성이 성공적으로 배포된 경우 이전 출력에 /etc/NetworkManager/system-connections/<connection_name > 파일 경로가 포함됩니다.
  머신 구성에는 ExecStart=/usr/local/bin/mtu-migration.sh 행이 포함되어 있지 않아야 합니다.

MTU 마이그레이션을 완료하려면 다음 명령 중 하나를 입력합니다.

OVN-Kubernetes 클러스터 네트워크 공급자를 사용하는 경우 다음을 수행합니다.

oc patch Network.operator.openshift.io cluster --type=merge --patch \
  '{"spec": { "migration": null, "defaultNetwork":{ "ovnKubernetesConfig": { "mtu": <mtu> }}}}'

$ oc patch Network.operator.openshift.io cluster --type=merge --patch \
  '{"spec": { "migration": null, "defaultNetwork":{ "ovnKubernetesConfig": { "mtu": <mtu> }}}}'

Copy to Clipboard

Toggle word wrap

다음과 같습니다.

<mtu>: < overlay_to>로 지정한 새 클러스터 네트워크 MTU를 지정합니다.

OpenShift SDN 클러스터 네트워크 공급자를 사용하는 경우:

oc patch Network.operator.openshift.io cluster --type=merge --patch \
  '{"spec": { "migration": null, "defaultNetwork":{ "openshiftSDNConfig": { "mtu": <mtu> }}}}'

$ oc patch Network.operator.openshift.io cluster --type=merge --patch \
  '{"spec": { "migration": null, "defaultNetwork":{ "openshiftSDNConfig": { "mtu": <mtu> }}}}'

Copy to Clipboard

Toggle word wrap

다음과 같습니다.

<mtu>: < overlay_to>로 지정한 새 클러스터 네트워크 MTU를 지정합니다.

검증

클러스터의 노드가 이전 프로세스에서 지정한 MTU를 사용하는지 확인할 수 있습니다.

클러스터 네트워크의 현재 MTU를 가져오려면 다음 명령을 입력합니다.
```
oc describe network.config cluster
```
```
$ oc describe network.config cluster
```
Copy to Clipboard Toggle word wrap
노드의 기본 네트워크 인터페이스에 대한 현재 MTU를 가져옵니다.
1. 클러스터의 노드를 나열하려면 다음 명령을 입력합니다.
  $ oc get nodes
  Copy to Clipboard Toggle word wrap
2. 노드의 기본 네트워크 인터페이스의 현재 MTU 설정을 가져오려면 다음 명령을 입력합니다.
  $ oc debug node/<node> -- chroot /host ip address show <interface>
  Copy to Clipboard Toggle word wrap
  다음과 같습니다.
  <node>
  이전 단계의 출력에서 노드를 지정합니다.
  <interface>
  노드의 기본 네트워크 인터페이스 이름을 지정합니다.
  출력 예
  ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8051
  
  Copy to Clipboard Toggle word wrap

11장. 노드 포트 서비스 범위 구성
링크 복사

클러스터 관리자는 사용 가능한 노드 포트 범위를 확장할 수 있습니다. 클러스터에서 많은 수의 노드 포트를 사용하는 경우 사용 가능한 포트 수를 늘려야 할 수 있습니다.

기본 포트 범위는 30000~32767입니다. 기본 범위 이상으로 확장한 경우에도 포트 범위는 축소할 수 없습니다.

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

클러스터 인프라는 확장된 범위 내에서 지정한 포트에 대한 액세스를 허용해야 합니다. 예를 들어, 노드 포트 범위를 30000~32900으로 확장하는 경우 방화벽 또는 패킷 필터링 구성에서 32768~32900의 포함 포트 범위를 허용해야 합니다.

11.2. 노드 포트 범위 확장
링크 복사

클러스터의 노드 포트 범위를 확장할 수 있습니다.

사전 요구 사항

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

프로세스

노드 포트 범위를 확장하려면 다음 명령을 입력합니다. <port>를 새 범위에서 가장 큰 포트 번호로 변경합니다.

oc patch network.config.openshift.io cluster --type=merge -p \
  '{
    "spec":
      { "serviceNodePortRange": "30000-<port>" }
  }'

$ oc patch network.config.openshift.io cluster --type=merge -p \
  '{
    "spec":
      { "serviceNodePortRange": "30000-<port>" }
  }'

Copy to Clipboard

Toggle word wrap

작은 정보

또는 다음 YAML을 적용하여 노드 포트 범위를 업데이트할 수 있습니다.

apiVersion: config.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  serviceNodePortRange: "30000-<port>"

apiVersion: config.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  serviceNodePortRange: "30000-<port>"

Copy to Clipboard

Toggle word wrap

출력 예

network.config.openshift.io/cluster patched

network.config.openshift.io/cluster patched

Copy to Clipboard

Toggle word wrap

구성이 활성 상태인지 확인하려면 다음 명령을 입력합니다. 업데이트가 적용되려면 몇 분 정도 걸릴 수 있습니다.

oc get configmaps -n openshift-kube-apiserver config \
  -o jsonpath="{.data['config\.yaml']}" | \
  grep -Eo '"service-node-port-range":["[[:digit:]]+-[[:digit:]]+"]'

$ oc get configmaps -n openshift-kube-apiserver config \
  -o jsonpath="{.data['config\.yaml']}" | \
  grep -Eo '"service-node-port-range":["[[:digit:]]+-[[:digit:]]+"]'

Copy to Clipboard

Toggle word wrap

출력 예

"service-node-port-range":["30000-33000"]

"service-node-port-range":["30000-33000"]

Copy to Clipboard

Toggle word wrap

12장. IP 페일오버 구성
링크 복사

다음에서는 OpenShift Container Platform 클러스터의 Pod 및 서비스에 대한 IP 페일오버 구성에 대해 설명합니다.

IP 페일오버는 노드 집합에서 VIP(가상 IP) 주소 풀을 관리합니다. 세트의 모든 VIP는 세트에서 선택한 노드에서 서비스를 제공합니다. 단일 노드를 사용할 수 있는 경우 VIP가 제공됩니다. 노드에 VIP를 명시적으로 배포할 방법은 없으므로 VIP가 없는 노드와 많은 VIP가 많은 다른 노드가 있을 수 있습니다 노드가 하나만 있는 경우 모든 VIP가 노드에 있습니다.

참고

VIP는 클러스터 외부에서 라우팅할 수 있어야 합니다.

IP 페일오버는 각 VIP의 포트를 모니터링하여 노드에서 포트에 연결할 수 있는지 확인합니다. 포트에 연결할 수 없는 경우 VIP가 노드에 할당되지 않습니다. 포트를 0으로 설정하면 이 검사가 비활성화됩니다. 검사 스크립트는 필요한 테스트를 수행합니다.

IP 페일오버는 Keepalived를 사용하여 호스트 집합에서 외부 액세스가 가능한 VIP 주소 집합을 호스팅합니다. 각 VIP는 한 번에 하나의 호스트에서만 서비스를 제공합니다. keepalived는 VRRP(Virtual Router Redundancy Protocol: 가상 라우터 중복 프로토콜)를 사용하여 호스트 집합에서 VIP를 대상으로 서비스를 결정합니다. 호스트를 사용할 수 없게 되거나 Keepalived 서비스가 응답하지 않는 경우 VIP가 세트의 다른 호스트로 전환됩니다. 즉, 호스트를 사용할 수 있는 한 VIP는 항상 서비스됩니다.

Keepalived를 실행하는 노드가 확인 스크립트를 통과하면 해당 노드의 VIP가 우선 순위와 현재 master의 우선 순위 및 선점 전략에 따라 마스터 상태를 입력할 수 있습니다.

클러스터 관리자는 OPENSHIFT_HA_NOTIFY_SCRIPT 변수를 통해 스크립트를 제공할 수 있으며 이 스크립트는 노드의 VIP 상태가 변경될 때마다 호출됩니다. keepalived는 VIP를 서비스하는 경우 master 상태를 사용하고, 다른 노드가 VIP를 서비스할 때 backup 상태를 사용하거나 검사 스크립트가 실패할 때 fault 상태를 사용합니다. 알림 스크립트는 상태가 변경될 때마다 새 상태로 호출됩니다.

OpenShift Container Platform에서 IP 장애 조치 배포 구성을 생성할 수 있습니다. IP 장애 조치 배포 구성은 VIP 주소 집합과 서비스할 노드 집합을 지정합니다. 클러스터에는 고유한 VIP 주소 집합을 관리할 때마다 여러 IP 페일오버 배포 구성이 있을 수 있습니다. IP 장애 조치 구성의 각 노드는 IP 장애 조치 Pod를 실행하며 이 Pod는 Keepalived를 실행합니다.

VIP를 사용하여 호스트 네트워킹이 있는 pod에 액세스하는 경우 애플리케이션 pod는 IP 페일오버 pod를 실행하는 모든 노드에서 실행됩니다. 이를 통해 모든 IP 페일오버 노드가 마스터가 되고 필요한 경우 VIP에 서비스를 제공할 수 있습니다. IP 페일오버가 있는 모든 노드에서 애플리케이션 pod가 실행되지 않는 경우 일부 IP 페일오버 노드가 VIP를 서비스하지 않거나 일부 애플리케이션 pod는 트래픽을 수신하지 않습니다. 이러한 불일치를 방지하려면 IP 페일오버 및 애플리케이션 pod 모두에 동일한 선택기 및 복제 수를 사용합니다.

VIP를 사용하여 서비스에 액세스하는 동안 애플리케이션 pod가 실행 중인 위치와 상관없이 모든 노드에서 서비스에 연결할 수 있으므로 모든 노드가 IP 페일오버 노드 세트에 있을 수 있습니다. 언제든지 IP 페일오버 노드가 마스터가 될 수 있습니다. 서비스는 외부 IP와 서비스 포트를 사용하거나 NodePort를 사용할 수 있습니다.

서비스 정의에서 외부 IP를 사용하는 경우 VIP가 외부 IP로 설정되고 IP 페일오버 모니터링 포트가 서비스 포트로 설정됩니다. 노드 포트를 사용하면 포트는 클러스터의 모든 노드에서 열려 있으며, 서비스는 현재 VIP를 서비스하는 모든 노드에서 트래픽을 로드 밸런싱합니다. 이 경우 서비스 정의에서 IP 페일오버 모니터링 포트가 NodePort로 설정됩니다.

중요

NodePort 설정은 권한 있는 작업입니다.

중요

VIP 서비스의 가용성이 높더라도 성능은 여전히 영향을 받을 수 있습니다. keepalived는 각 VIP가 구성의 일부 노드에서 서비스되도록 하고, 다른 노드에 아무것도 없는 경우에도 여러 VIP가 동일한 노드에 배치될 수 있도록 합니다. IP 페일오버가 동일한 노드에 여러 VIP를 배치하면 일련의 VIP에 걸쳐 외부적으로 로드 밸런싱을 수행하는 전략이 좌절될 수 있습니다.

ingressIP를 사용하는 경우 ingressIP 범위와 동일한 VIP 범위를 갖도록 IP 페일오버를 설정할 수 있습니다. 모니터링 포트를 비활성화할 수도 있습니다. 이 경우 모든 VIP가 클러스터의 동일한 노드에 표시됩니다. 모든 사용자는 ingressIP를 사용하여 서비스를 설정하고 고가용성으로 설정할 수 있습니다.

중요

클러스터에는 최대 254개의 VIP가 있습니다.

12.1. IP 페일오버 환경 변수
링크 복사

다음 표에는 IP 페일오버를 구성하는 데 사용되는 변수가 표시되어 있습니다.

Expand

표 12.1. IP 페일오버 환경 변수
변수 이름	기본값	설명
`OPENSHIFT_HA_MONITOR_PORT`	`80`	IP 페일오버 pod는 각 가상 IP(VIP)에서 이 포트에 대한 TCP 연결을 엽니다. 연결이 설정되면 서비스가 실행 중인 것으로 간주됩니다. 이 포트가 `0`으로 설정되면 테스트가 항상 통과합니다.
`OPENSHIFT_HA_NETWORK_INTERFACE`		IP 페일오버가 VRRP(Virtual Router Redundancy Protocol) 트래픽을 보내는 데 사용하는 인터페이스 이름입니다. 기본값은 `eth0`입니다.
`OPENSHIFT_HA_REPLICA_COUNT`	`2`	생성할 복제본 수입니다. 이는 IP 페일오버 배포 구성의 `spec.replicas` 값과 일치해야 합니다.
`OPENSHIFT_HA_VIRTUAL_IPS`		복제할 IP 주소 범위 목록입니다. 이 정보를 제공해야 합니다. 예: `1.2.3.4-6,1.2.3.9`.
`OPENSHIFT_HA_VRRP_ID_OFFSET`	`0`	가상 라우터 ID를 설정하는 데 사용되는 오프셋 값입니다. 다른 오프셋 값을 사용하면 동일한 클러스터 내에 여러 IP 페일오버 구성이 존재할 수 있습니다. 기본 오프셋은 `0`이며 허용되는 범위는 `0`에서 `255` 사이입니다.
`OPENSHIFT_HA_VIP_GROUPS`		VRRP에 대해 생성할 그룹 수입니다. 설정하지 않으면 `OPENSHIFT_HA_VIP_GROUPS` 변수로 지정된 각 가상 IP 범위에 대해 그룹이 생성됩니다.
`OPENSHIFT_HA_IPTABLES_CHAIN`	INPUT	VRRP 트래픽을 허용하는 iptables 규칙을 자동으로 추가하는 `iptables` 체인의 이름입니다. 값을 설정하지 않으면 `iptables` 규칙이 추가되지 않습니다. 체인이 없으면 생성되지 않습니다.
`OPENSHIFT_HA_CHECK_SCRIPT`		애플리케이션이 작동하는지 확인하기 위해 정기적으로 실행되는 스크립트의 Pod 파일 시스템에 있는 전체 경로 이름입니다.
`OPENSHIFT_HA_CHECK_INTERVAL`	`2`	확인 스크립트가 실행되는 기간(초)입니다.
`OPENSHIFT_HA_NOTIFY_SCRIPT`		상태가 변경될 때마다 실행되는 스크립트의 Pod 파일 시스템의 전체 경로 이름입니다.
`OPENSHIFT_HA_PREEMPTION`	`preempt_nodelay 300`	더 높은 우선 순위의 호스트를 처리하는 전략입니다. `nopreempt` 전략에서는 더 낮은 우선 순위 호스트에서 더 높은 우선 순위 호스트로 마스터를 이동하지 않습니다.

12.2. IP 페일오버 구성
링크 복사

클러스터 관리자는 레이블 선택기에 정의된 대로 전체 클러스터 또는 노드의 하위 집합에서 IP 페일오버를 구성할 수 있습니다. 클러스터에서 여러 IP 페일오버 배포 구성을 설정할 수도 있습니다. 이 배포 구성은 서로 독립적입니다.

IP 페일오버 배포 구성을 사용하면 제약 조건 또는 사용된 라벨과 일치하는 각 노드에서 페일오버 pod가 실행됩니다.

이 Pod는 Keepalived를 실행하여 엔드포인트를 모니터링하고 VRRP(Virtual Router Redundancy Protocol)를 사용하여 첫 번째 노드가 서비스 또는 엔드포인트에 연결할 수 없는 경우 한 노드에서 다른 노드로의 가상 IP(VIP)를 페일오버할 수 있습니다.

프로덕션 용도의 경우 두 개 이상의 노드를 선택하는 selector를 설정하고 선택한 노드 수와 동일한 replicas를 설정합니다.

사전 요구 사항

cluster-admin 권한이 있는 사용자로 클러스터에 로그인합니다.
풀 시크릿을 생성했습니다.

프로세스

IP 페일오버 서비스 계정을 생성합니다.
```
oc create sa ipfailover
```
```
$ oc create sa ipfailover
```
Copy to Clipboard Toggle word wrap

hostNetwork의 SCC(보안 컨텍스트 제약 조건)를 업데이트합니다.

oc adm policy add-scc-to-user privileged -z ipfailover
oc adm policy add-scc-to-user hostnetwork -z ipfailover

$ oc adm policy add-scc-to-user privileged -z ipfailover
$ oc adm policy add-scc-to-user hostnetwork -z ipfailover

Copy to Clipboard

Toggle word wrap

IP 페일오버를 구성하기 위해 배포 YAML 파일을 만듭니다.

IP 페일오버 구성을 위한 배포 YAML의 예

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ipfailover-keepalived 
  labels:
    ipfailover: hello-openshift
spec:
  strategy:
    type: Recreate
  replicas: 2
  selector:
    matchLabels:
      ipfailover: hello-openshift
  template:
    metadata:
      labels:
        ipfailover: hello-openshift
    spec:
      serviceAccountName: ipfailover
      privileged: true
      hostNetwork: true
      nodeSelector:
        node-role.kubernetes.io/worker: ""
      containers:
      - name: openshift-ipfailover
        image: quay.io/openshift/origin-keepalived-ipfailover
        ports:
        - containerPort: 63000
          hostPort: 63000
        imagePullPolicy: IfNotPresent
        securityContext:
          privileged: true
        volumeMounts:
        - name: lib-modules
          mountPath: /lib/modules
          readOnly: true
        - name: host-slash
          mountPath: /host
          readOnly: true
          mountPropagation: HostToContainer
        - name: etc-sysconfig
          mountPath: /etc/sysconfig
          readOnly: true
        - name: config-volume
          mountPath: /etc/keepalive
        env:
        - name: OPENSHIFT_HA_CONFIG_NAME
          value: "ipfailover"
        - name: OPENSHIFT_HA_VIRTUAL_IPS 
          value: "1.1.1.1-2"
        - name: OPENSHIFT_HA_VIP_GROUPS 
          value: "10"
        - name: OPENSHIFT_HA_NETWORK_INTERFACE 
          value: "ens3" #The host interface to assign the VIPs
        - name: OPENSHIFT_HA_MONITOR_PORT 
          value: "30060"
        - name: OPENSHIFT_HA_VRRP_ID_OFFSET 
          value: "0"
        - name: OPENSHIFT_HA_REPLICA_COUNT 
          value: "2" #Must match the number of replicas in the deployment
        - name: OPENSHIFT_HA_USE_UNICAST
          value: "false"
        #- name: OPENSHIFT_HA_UNICAST_PEERS
          #value: "10.0.148.40,10.0.160.234,10.0.199.110"
        - name: OPENSHIFT_HA_IPTABLES_CHAIN 
          value: "INPUT"
        #- name: OPENSHIFT_HA_NOTIFY_SCRIPT 
        #  value: /etc/keepalive/mynotifyscript.sh
        - name: OPENSHIFT_HA_CHECK_SCRIPT 
          value: "/etc/keepalive/mycheckscript.sh"
        - name: OPENSHIFT_HA_PREEMPTION 
          value: "preempt_delay 300"
        - name: OPENSHIFT_HA_CHECK_INTERVAL 
          value: "2"
        livenessProbe:
          initialDelaySeconds: 10
          exec:
            command:
            - pgrep
            - keepalived
      volumes:
      - name: lib-modules
        hostPath:
          path: /lib/modules
      - name: host-slash
        hostPath:
          path: /
      - name: etc-sysconfig
        hostPath:
          path: /etc/sysconfig
      # config-volume contains the check script
      # created with `oc create configmap keepalived-checkscript --from-file=mycheckscript.sh`
      - configMap:
          defaultMode: 0755
          name: keepalived-checkscript
        name: config-volume
      imagePullSecrets:
        - name: openshift-pull-secret

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ipfailover-keepalived

1


  labels:
    ipfailover: hello-openshift
spec:
  strategy:
    type: Recreate
  replicas: 2
  selector:
    matchLabels:
      ipfailover: hello-openshift
  template:
    metadata:
      labels:
        ipfailover: hello-openshift
    spec:
      serviceAccountName: ipfailover
      privileged: true
      hostNetwork: true
      nodeSelector:
        node-role.kubernetes.io/worker: ""
      containers:
      - name: openshift-ipfailover
        image: quay.io/openshift/origin-keepalived-ipfailover
        ports:
        - containerPort: 63000
          hostPort: 63000
        imagePullPolicy: IfNotPresent
        securityContext:
          privileged: true
        volumeMounts:
        - name: lib-modules
          mountPath: /lib/modules
          readOnly: true
        - name: host-slash
          mountPath: /host
          readOnly: true
          mountPropagation: HostToContainer
        - name: etc-sysconfig
          mountPath: /etc/sysconfig
          readOnly: true
        - name: config-volume
          mountPath: /etc/keepalive
        env:
        - name: OPENSHIFT_HA_CONFIG_NAME
          value: "ipfailover"
        - name: OPENSHIFT_HA_VIRTUAL_IPS

2


          value: "1.1.1.1-2"
        - name: OPENSHIFT_HA_VIP_GROUPS

3


          value: "10"
        - name: OPENSHIFT_HA_NETWORK_INTERFACE

4


          value: "ens3" #The host interface to assign the VIPs
        - name: OPENSHIFT_HA_MONITOR_PORT

5


          value: "30060"
        - name: OPENSHIFT_HA_VRRP_ID_OFFSET

6


          value: "0"
        - name: OPENSHIFT_HA_REPLICA_COUNT

7


          value: "2" #Must match the number of replicas in the deployment
        - name: OPENSHIFT_HA_USE_UNICAST
          value: "false"
        #- name: OPENSHIFT_HA_UNICAST_PEERS
          #value: "10.0.148.40,10.0.160.234,10.0.199.110"
        - name: OPENSHIFT_HA_IPTABLES_CHAIN

8


          value: "INPUT"
        #- name: OPENSHIFT_HA_NOTIFY_SCRIPT

9


        #  value: /etc/keepalive/mynotifyscript.sh
        - name: OPENSHIFT_HA_CHECK_SCRIPT

10


          value: "/etc/keepalive/mycheckscript.sh"
        - name: OPENSHIFT_HA_PREEMPTION

11


          value: "preempt_delay 300"
        - name: OPENSHIFT_HA_CHECK_INTERVAL

12


          value: "2"
        livenessProbe:
          initialDelaySeconds: 10
          exec:
            command:
            - pgrep
            - keepalived
      volumes:
      - name: lib-modules
        hostPath:
          path: /lib/modules
      - name: host-slash
        hostPath:
          path: /
      - name: etc-sysconfig
        hostPath:
          path: /etc/sysconfig
      # config-volume contains the check script
      # created with `oc create configmap keepalived-checkscript --from-file=mycheckscript.sh`
      - configMap:
          defaultMode: 0755
          name: keepalived-checkscript
        name: config-volume
      imagePullSecrets:
        - name: openshift-pull-secret

13

Copy to Clipboard

Toggle word wrap

1: IP 페일오버 배포의 이름입니다.
2: 복제할 IP 주소 범위 목록입니다. 이 정보를 제공해야 합니다. 예: 1.2.3.4-6,1.2.3.9.
3: VRRP에 대해 생성할 그룹 수입니다. 설정하지 않으면 OPENSHIFT_HA_VIP_GROUPS 변수로 지정된 각 가상 IP 범위에 대해 그룹이 생성됩니다.
4: IP 페일오버가 VRRP 트래픽을 보내는 데 사용하는 인터페이스 이름입니다. 기본적으로 eth0이 사용됩니다.
5: IP 페일오버 pod는 각 VIP에서 이 포트에 대한 TCP 연결을 열려고 합니다. 연결이 설정되면 서비스가 실행 중인 것으로 간주됩니다. 이 포트가 0으로 설정되면 테스트가 항상 통과합니다. 기본값은 80입니다.
6: 가상 라우터 ID를 설정하는 데 사용되는 오프셋 값입니다. 다른 오프셋 값을 사용하면 동일한 클러스터 내에 여러 IP 페일오버 구성이 존재할 수 있습니다. 기본 오프셋은 0이며 허용되는 범위는 0에서 255 사이입니다.
7: 생성할 복제본 수입니다. 이는 IP 페일오버 배포 구성의 spec.replicas 값과 일치해야 합니다. 기본값은 2입니다.
8: VRRP 트래픽을 허용하는 iptables 규칙을 자동으로 추가하는 iptables 체인의 이름입니다. 값을 설정하지 않으면 iptables 규칙이 추가되지 않습니다. 체인이 존재하지 않으면 이 체인이 생성되지 않으며 Keepalived는 유니캐스트 모드로 작동합니다. 기본값은 INPUT입니다.
9: 상태가 변경될 때마다 실행되는 스크립트의 Pod 파일 시스템의 전체 경로 이름입니다.
10: 애플리케이션이 작동하는지 확인하기 위해 정기적으로 실행되는 스크립트의 Pod 파일 시스템에 있는 전체 경로 이름입니다.
11: 더 높은 우선 순위의 호스트를 처리하는 전략입니다. 기본값은 preempt_delay 300으로, 우선순위가 낮은 마스터가 VIP를 보유하는 경우 Keepalived 인스턴스가 5분 후에 VIP를 넘겨받습니다.
12: 확인 스크립트가 실행되는 기간(초)입니다. 기본값은 2입니다.
13: 배포를 만들기 전에 풀 시크릿을 생성합니다. 그렇지 않으면 배포를 생성할 때 오류가 발생합니다.

12.3. 가상 IP 주소 정보
링크 복사

keepalived는 가상 IP 주소 집합(VIP)을 관리합니다. 관리자는 다음 주소를 모두 확인해야 합니다.

클러스터 외부에서 구성된 호스트에서 액세스할 수 있습니다.
클러스터 내의 다른 용도로는 사용되지 않습니다.

각 노드의 keepalive는 필요한 서비스가 실행 중인지 여부를 결정합니다. 이 경우 VIP가 지원되고 Keepalived가 협상에 참여하여 VIP를 제공하는 노드를 결정합니다. 노드가 참여하려면 VIP의 감시 포트에서 서비스를 수신 대기하거나 검사를 비활성화해야 합니다.

참고

세트의 각 VIP는 다른 노드에서 제공할 수 있습니다.

12.4. 검사 구성 및 스크립트 알림
링크 복사

keepalived는 사용자가 제공한 선택적 검사 스크립트를 주기적으로 실행하여 애플리케이션의 상태를 모니터링합니다. 예를 들어 스크립트는 요청을 발행하고 응답을 확인하여 웹 서버를 테스트할 수 있습니다.

검사 스크립트를 제공하지 않으면 TCP 연결을 테스트하는 간단한 기본 스크립트가 실행됩니다. 이 기본 테스트는 모니터 포트가 0이면 비활성화됩니다.

각 IP 페일오버 pod는 pod가 실행 중인 노드에서 하나 이상의 가상 IP(VIP)를 관리하는 Keepalived 데몬을 관리합니다. Keepalived 데몬은 해당 노드의 각 VIP 상태를 유지합니다. 특정 노드의 특정 VIP는 master, backup, fault 상태일 수 있습니다.

master 상태에 있는 노드에서 해당 VIP에 대한 검사 스크립트가 실패하면 해당 노드의 VIP가 fault 상태가 되어 재협상을 트리거합니다. 재협상하는 동안 fault 상태에 있지 않은 노드의 모든 VIP가 VIP를 인수하는 노드를 결정하는 데 참여합니다. 결과적으로 VIP는 일부 노드에서 master 상태로 전환되고 VIP는 다른 노드에서 backup 상태로 유지됩니다.

backup 상태의 VIP 노드가 실패하면 해당 노드의 VIP가 fault 상태가 됩니다. 검사 스크립트가 fault 상태의 노드에서 VIP를 다시 전달하면 해당 노드의 VIP 상태가 fault 상태를 종료하고 master 상태로 전환하도록 협상합니다. 그런 다음 해당 노드의 VIP는 master 또는 backup 상태에 들어갈 수 있습니다.

클러스터 관리자는 상태가 변경될 때마다 호출되는 선택적 알림 스크립트를 제공할 수 있습니다. keepalived는 다음 세 개의 매개변수를 스크립트에 전달합니다.

$1 - group 또는 instance
$2 - group 또는 instance 이름
$3 - 새 상태: master, backup 또는 fault

검사 및 알림 스크립트가 IP 페일오버 Pod에서 실행되고 호스트 파일 시스템이 아닌 Pod 파일 시스템을 사용합니다. 그러나 IP 페일오버 Pod를 사용하면 /hosts 마운트 경로에서 호스트 파일 시스템을 사용할 수 있습니다. 검사 또는 알림 스크립트를 구성할 때 스크립트의 전체 경로를 제공해야 합니다. 스크립트를 제공하는 데 권장되는 접근 방식은 구성 맵을 사용하는 것입니다.

Keepalived가 시작될 때마다 로드되는 검사 및 알림 스크립트의 전체 경로 이름이 Keepalived 구성 파일인 _/etc/keepalived/keepalived.conf에 추가됩니다. 스크립트는 다음과 같이 구성 맵을 사용하여 Pod에 추가할 수 있습니다.

사전 요구 사항

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

프로세스

원하는 스크립트를 생성하고 해당 스크립트를 유지할 구성 맵을 생성합니다. 스크립트에는 입력 인수가 없으며 OK의 경우 0을fail의 경우 1을 반환해야 합니다.
검사 스크립트, mycheckscript.sh:
```
#!/bin/bash
    # Whatever tests are needed
    # E.g., send request and verify response
exit 0
```
```
#!/bin/bash
    # Whatever tests are needed
    # E.g., send request and verify response
exit 0
```
Copy to Clipboard Toggle word wrap

config map을 생성합니다.

oc create configmap mycustomcheck --from-file=mycheckscript.sh

$ oc create configmap mycustomcheck --from-file=mycheckscript.sh

Copy to Clipboard

Toggle word wrap

pod에 스크립트를 추가합니다. 마운트된 구성 맵 파일의 defaultMode는 oc 명령을 사용하거나 배포 구성을 편집하여 실행할 수 있어야 합니다. 0755, 493 10진수 값이 일반적입니다.

oc set env deploy/ipfailover-keepalived \
    OPENSHIFT_HA_CHECK_SCRIPT=/etc/keepalive/mycheckscript.sh

$ oc set env deploy/ipfailover-keepalived \
    OPENSHIFT_HA_CHECK_SCRIPT=/etc/keepalive/mycheckscript.sh

Copy to Clipboard

Toggle word wrap

oc set volume deploy/ipfailover-keepalived --add --overwrite \
    --name=config-volume \
    --mount-path=/etc/keepalive \
    --source='{"configMap": { "name": "mycustomcheck", "defaultMode": 493}}'

$ oc set volume deploy/ipfailover-keepalived --add --overwrite \
    --name=config-volume \
    --mount-path=/etc/keepalive \
    --source='{"configMap": { "name": "mycustomcheck", "defaultMode": 493}}'

Copy to Clipboard

Toggle word wrap

참고

oc set env 명령은 공백 문자를 구분합니다. = 기호 양쪽에 공백이 없어야 합니다.

작은 정보

또는 ipfailover-keepalived 배포 구성을 편집할 수 있습니다.

oc edit deploy ipfailover-keepalived

$ oc edit deploy ipfailover-keepalived

Copy to Clipboard

Toggle word wrap

    spec:
      containers:
      - env:
        - name: OPENSHIFT_HA_CHECK_SCRIPT  
          value: /etc/keepalive/mycheckscript.sh
...
        volumeMounts: 
        - mountPath: /etc/keepalive
          name: config-volume
      dnsPolicy: ClusterFirst
...
      volumes: 
      - configMap:
          defaultMode: 0755 
          name: customrouter
        name: config-volume
...

    spec:
      containers:
      - env:
        - name: OPENSHIFT_HA_CHECK_SCRIPT

1


          value: /etc/keepalive/mycheckscript.sh
...
        volumeMounts:

2


        - mountPath: /etc/keepalive
          name: config-volume
      dnsPolicy: ClusterFirst
...
      volumes:

3


      - configMap:
          defaultMode: 0755

4


          name: customrouter
        name: config-volume
...

Copy to Clipboard

Toggle word wrap

1: spec.container.env 필드에서 마운트된 스크립트 파일을 가리키도록 OPENSHIFT_HA_CHECK_SCRIPT 환경 변수를 추가합니다.
2: spec.container.volumeMounts 필드를 추가하여 마운트 지점을 생성합니다.
3: 새 spec.volumes 필드를 추가하여 구성 맵을 언급합니다.
4: 파일에 대한 실행 권한을 설정합니다. 다시 읽으면 10진수 493으로 표시됩니다.

변경 사항을 저장하고 편집기를 종료합니다. 이렇게 하면 ipfailover-keepalived가 다시 시작됩니다.

12.5. VRRP 선점 구성
링크 복사

노드의 가상 IP(VIP)가 검사 스크립트를 전달하여 fault 상태를 벗어나면 노드의 VIP가 현재 master 상태에 있는 노드의 VIP보다 우선 순위가 낮은 경우 backup 상태가 됩니다. 그러나 fault 상태를 벗어나는 노드의 VIP가 우선 순위가 더 높은 경우 선점 전략이 클러스터에서 해당 역할을 결정합니다.

nopreempt 전략에서는 호스트의 우선 순위가 낮은 VIP에서 호스트의 우선 순위가 높은 VIP로 master를 이동하지 않습니다. preempt_delay 300을 사용하면 기본값인 Keepalived가 지정된 300초 동안 기다린 후 fault를 호스트의 우선 순위 VIP로 이동합니다.

사전 요구 사항

OpenShift CLI(oc)를 설치합니다.

프로세스

선점 기능을 지정하려면 oc edit deploy ipfailover-keepalived를 입력하여 라우터 배포 구성을 편집합니다.
```
oc edit deploy ipfailover-keepalived
```
```
$ oc edit deploy ipfailover-keepalived
```
Copy to Clipboard Toggle word wrap
```
...
    spec:
      containers:
      - env:
        - name: OPENSHIFT_HA_PREEMPTION  
          value: preempt_delay 300
...
```
```
...
    spec:
      containers:
      - env:
        - name: OPENSHIFT_HA_PREEMPTION  
```
1
```
          value: preempt_delay 300
...
```
Copy to Clipboard Toggle word wrap
1
OPENSHIFT_HA_PREEMPTION 값을 설정합니다.
preempt_delay 300: Keepalived는 지정된 300초 동안 기다린 후 호스트의 우선 순위가 높은 VIP로 master를 이동합니다. 이는 기본값입니다.
nopreempt: 더 낮은 우선 순위 호스트에서 더 높은 우선 순위 호스트로 master를 이동하지 않습니다.

12.6. VRRP ID 오프셋 정보
링크 복사

IP 페일오버 배포 구성에서 관리하는 각 IP 페일오버 pod는 노드 또는 복제본당 1개의 Pod를 실행하고 Keepalived 데몬을 실행합니다. 더 많은 IP 페일오버 배포 구성이 설정되면 더 많은 Pod가 생성되고 더 많은 데몬이 일반 VRRP(Virtual Router Redundancy Protocol) 협상에 연결됩니다. 이 협상은 모든 Keepalived 데몬에서 수행되며 어떤 노드가 어떤 VIP(가상 IP)를 서비스할 지 결정합니다.

내부적으로 Keepalived는 각 VIP에 고유한 vrrp-id를 할당합니다. 협상은 이 vrrp-id 세트를 사용하며, 결정이 내려지면 vrrp-id에 해당하는 VIP가 노드에 제공됩니다.

따라서 IP 페일오버 배포 구성에 정의된 모든 VIP에 대해 IP 페일오버 Pod에서 해당 vrrp-id를 할당해야 합니다. 이 작업은 OPENSHIFT_HA_VRRP_ID_OFFSET에서 시작하고 vrrp-ids를 VIP 목록에 순차적으로 할당하여 수행됩니다. vrrp-ids는 1..255 범위의 값이 있을 수 있습니다.

IP 페일오버 배포 구성이 여러 개인 경우 배포 구성의 VIP 수를 늘리고 vrrp-id 범위가 겹치지 않도록 OPENSHIFT_HA_VRRP_ID_OFFSET을 지정해야 합니다.

12.7. 254개 이상의 주소에 대한 IP 페일오버 구성
링크 복사

IP 페일오버 관리는 254개의 가상 IP(VIP) 주소 그룹으로 제한됩니다. 기본적으로 OpenShift Container Platform은 각 그룹에 하나의 IP 주소를 할당합니다. OPENSHIFT_HA_VIP_GROUPS 변수를 사용하여 이를 변경하여 여러 IP 주소가 각 그룹에 속하도록 하고 IP 페일오버를 구성할 때 각 VRRP(Virtual Router Redundancy Protocol) 인스턴스에 사용 가능한 VIP 그룹 수를 정의할 수 있습니다.

VIP 그룹화는 VRRP 페일오버 이벤트의 경우 VRRP당 VIP의 할당 범위가 넓어지며 클러스터의 모든 호스트가 로컬에서 서비스에 액세스할 수 있는 경우에 유용합니다. 예를 들어 서비스가 ExternalIP를 사용하여 노출되는 경우입니다.

참고

페일오버에 대한 규칙으로 라우터와 같은 서비스를 하나의 특정 호스트로 제한하지 마십시오. 대신 IP 페일오버의 경우 새 호스트에서 서비스를 다시 생성할 필요가 없도록 각 호스트에 서비스를 복제해야 합니다.

참고

OpenShift Container Platform 상태 확인을 사용하는 경우 IP 페일오버 및 그룹의 특성으로 인해 그룹의 모든 인스턴스가 확인되지 않습니다. 따라서 서비스가 활성화되어 있는지 확인하려면 Kubernetes 상태 점검을 사용해야 합니다.

사전 요구 사항

cluster-admin 권한이 있는 사용자로 클러스터에 로그인합니다.

프로세스

각 그룹에 할당된 IP 주소 수를 변경하려면 OPENSHIFT_HA_VIP_GROUPS 변수의 값을 변경합니다. 예를 들면 다음과 같습니다.
IP 페일오버 구성을 위한 Deployment YAML의 예
```
...
    spec:
        env:
        - name: OPENSHIFT_HA_VIP_GROUPS 
          value: "3"
...
```
```
...
    spec:
        env:
        - name: OPENSHIFT_HA_VIP_GROUPS 
```
1
```
          value: "3"
...
```
Copy to Clipboard Toggle word wrap
1
7개의 VIP가 있는 환경에서 OPENSHIFT_HA_VIP_GROUPS가 3으로 설정된 경우 3개의 그룹을 생성하여 3개의 VIP를 첫 번째 그룹에 할당하고 2개의 VIP를 나머지 2개의 그룹에 할당합니다.

참고

OPENSHIFT_HA_VIP_GROUPS로 설정된 그룹 수가 페일오버로 설정된 IP 주소 수보다 적으면 그룹에는 두 개 이상의 IP 주소가 포함되어 있으며 모든 주소가 하나의 단위로 이동합니다.

12.8. ingressIP의 고가용성
링크 복사

클라우드 이외의 클러스터에서 서비스에 대한 IP 페일오버 및 ingressIP를 결합할 수 있습니다. 그 결과 ingressIP를 사용하여 서비스를 생성하는 사용자를 위한 고가용성 서비스가 생성됩니다.

사용 방법은 ingressIPNetworkCIDR 범위를 지정한 다음 ipfailover 구성을 생성할 때 동일한 범위를 사용하는 것입니다.

IP 페일오버는 전체 클러스터에 대해 최대 255개의 VIP를 지원할 수 있으므로 ingressIPNetworkCIDR은 /24 이하이어야 합니다.

12.9. IP 페일오버 제거
링크 복사

IP 페일오버가 처음 구성되면 클러스터의 작업자 노드는 Keepalived에 대해 224.0.0.18의 멀티 캐스트 패킷을 명시적으로 허용하는 iptables 규칙을 사용하여 수정됩니다. 노드를 변경하여 IP 페일오버를 제거하려면 iptables 규칙을 제거하고 Keepalived에서 사용하는 가상 IP 주소를 제거하는 작업을 실행해야 합니다.

절차

선택 사항: 구성 맵으로 저장된 점검 및 알림 스크립트를 식별하고 삭제합니다.

IP 페일오버에 대한 Pod가 구성 맵을 볼륨으로 사용하는지 여부를 확인합니다.

oc get pod -l ipfailover \
  -o jsonpath="\
{range .items[?(@.spec.volumes[*].configMap)]}
{'Namespace: '}{.metadata.namespace}
{'Pod:       '}{.metadata.name}
{'Volumes that use config maps:'}
{range .spec.volumes[?(@.configMap)]}  {'volume:    '}{.name}
  {'configMap: '}{.configMap.name}{'\n'}{end}
{end}"

$ oc get pod -l ipfailover \
  -o jsonpath="\
{range .items[?(@.spec.volumes[*].configMap)]}
{'Namespace: '}{.metadata.namespace}
{'Pod:       '}{.metadata.name}
{'Volumes that use config maps:'}
{range .spec.volumes[?(@.configMap)]}  {'volume:    '}{.name}
  {'configMap: '}{.configMap.name}{'\n'}{end}
{end}"

Copy to Clipboard

Toggle word wrap

출력 예

Namespace: default
Pod:       keepalived-worker-59df45db9c-2x9mn
Volumes that use config maps:
  volume:    config-volume
  configMap: mycustomcheck

Namespace: default
Pod:       keepalived-worker-59df45db9c-2x9mn
Volumes that use config maps:
  volume:    config-volume
  configMap: mycustomcheck

Copy to Clipboard

Toggle word wrap

이전 단계에서 볼륨으로 사용되는 구성 맵의 이름을 제공한 경우 구성 맵을 삭제합니다.
```
oc delete configmap <configmap_name>
```
```
$ oc delete configmap <configmap_name>
```
Copy to Clipboard Toggle word wrap

IP 페일오버를 위한 기존 배포를 식별합니다.

oc get deployment -l ipfailover

$ oc get deployment -l ipfailover

Copy to Clipboard

Toggle word wrap

출력 예

NAMESPACE   NAME         READY   UP-TO-DATE   AVAILABLE   AGE
default     ipfailover   2/2     2            2           105d

NAMESPACE   NAME         READY   UP-TO-DATE   AVAILABLE   AGE
default     ipfailover   2/2     2            2           105d

Copy to Clipboard

Toggle word wrap

배포를 삭제합니다.

oc delete deployment <ipfailover_deployment_name>

$ oc delete deployment <ipfailover_deployment_name>

Copy to Clipboard

Toggle word wrap

ipfailover 서비스 계정을 제거합니다.
```
oc delete sa ipfailover
```
```
$ oc delete sa ipfailover
```
Copy to Clipboard Toggle word wrap

IP 페일오버를 처음 구성할 때 추가된 IP 테이블 규칙을 제거하는 작업을 실행합니다.

다음 예와 유사한 콘텐츠를 사용하여 remove-ipfailover-job.yaml과 같은 파일을 생성합니다.

apiVersion: batch/v1
kind: Job
metadata:
  generateName: remove-ipfailover-
  labels:
    app: remove-ipfailover
spec:
  template:
    metadata:
      name: remove-ipfailover
    spec:
      containers:
      - name: remove-ipfailover
        image: quay.io/openshift/origin-keepalived-ipfailover:4.11
        command: ["/var/lib/ipfailover/keepalived/remove-failover.sh"]
      nodeSelector:
        kubernetes.io/hostname: <host_name>  <.>
      restartPolicy: Never

apiVersion: batch/v1
kind: Job
metadata:
  generateName: remove-ipfailover-
  labels:
    app: remove-ipfailover
spec:
  template:
    metadata:
      name: remove-ipfailover
    spec:
      containers:
      - name: remove-ipfailover
        image: quay.io/openshift/origin-keepalived-ipfailover:4.11
        command: ["/var/lib/ipfailover/keepalived/remove-failover.sh"]
      nodeSelector:
        kubernetes.io/hostname: <host_name>  <.>
      restartPolicy: Never

Copy to Clipboard

Toggle word wrap

<.> IP 페일오버용으로 구성된 클러스터의 각 노드에 대해 작업을 실행하고 매번 호스트 이름을 바꿉니다.

작업을 실행합니다.

oc create -f remove-ipfailover-job.yaml

$ oc create -f remove-ipfailover-job.yaml

Copy to Clipboard

Toggle word wrap

출력 예

job.batch/remove-ipfailover-2h8dm created

job.batch/remove-ipfailover-2h8dm created

Copy to Clipboard

Toggle word wrap

검증

작업이 IP 페일오버의 초기 구성을 제거했는지 확인합니다.

oc logs job/remove-ipfailover-2h8dm

$ oc logs job/remove-ipfailover-2h8dm

Copy to Clipboard

Toggle word wrap

출력 예

remove-failover.sh: OpenShift IP Failover service terminating.
  - Removing ip_vs module ...
  - Cleaning up ...
  - Releasing VIPs  (interface eth0) ...

remove-failover.sh: OpenShift IP Failover service terminating.
  - Removing ip_vs module ...
  - Cleaning up ...
  - Releasing VIPs  (interface eth0) ...

Copy to Clipboard

Toggle word wrap

13장. 인터페이스 수준 네트워크 sysctl 구성
링크 복사

Linux에서 sysctl을 사용하면 관리자가 런타임에 커널 매개변수를 수정할 수 있습니다. 튜닝 CNI(Container Network Interface) 메타 플러그인을 사용하여 인터페이스 수준 네트워크 sysctl을 수정할 수 있습니다. 튜닝 CNI 메타 플러그인은 설명된 대로 기본 CNI 플러그인이 있는 체인에서 작동합니다.

기본 CNI 플러그인은 인터페이스를 할당하고 런타임 시 튜닝 CNI 메타 플러그인에 이를 전달합니다. 튜닝 CNI 메타 플러그인을 사용하여 네트워크 네임스페이스에서 일부 sysctl 및 여러 인터페이스 속성(프로미스 모드, all-multicast 모드, MTU 및 MAC 주소)을 변경할 수 있습니다. 튜닝 CNI 메타 플러그인 구성에서 인터페이스 이름은 IFNAME 토큰으로 표시되고 런타임 시 인터페이스 이름으로 교체됩니다.

참고

OpenShift Container Platform에서 튜닝 CNI 메타 플러그인은 인터페이스 수준 네트워크 sysctl 변경만 지원합니다.

13.1. 튜닝 CNI 구성
링크 복사

다음 절차에서는 인터페이스 수준 네트워크 net.ipv4.conf.IFNAME.accept_redirects sysctl을 변경하기 위해 튜닝 CNI를 구성합니다. 이 예제에서는 ICMP 리디렉션 패킷을 수락하고 전송할 수 있습니다.

프로세스

다음 콘텐츠를 사용하여 tuning-example.yaml 과 같은 네트워크 연결 정의를 생성합니다.

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  name: <name> 
  namespace: default 
spec:
  config: '{
    "cniVersion": "0.4.0", 
    "name": "<name>", 
    "plugins": [{
       "type": "<main_CNI_plugin>" 
      },
      {
       "type": "tuning", 
       "sysctl": {
            "net.ipv4.conf.IFNAME.accept_redirects": "1" 
        }
      }
     ]
}

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  name: <name>

1


  namespace: default

2


spec:
  config: '{
    "cniVersion": "0.4.0",

3


    "name": "<name>",

4


    "plugins": [{
       "type": "<main_CNI_plugin>"

5


      },
      {
       "type": "tuning",

6


       "sysctl": {
            "net.ipv4.conf.IFNAME.accept_redirects": "1"

7

Copy to Clipboard

Toggle word wrap

1: 생성할 추가 네트워크 연결의 이름을 지정합니다. 이름은 지정된 네임스페이스 내에서 고유해야 합니다.
2: 개체가 연결된 네임스페이스를 지정합니다.
3: CNI 사양 버전을 지정합니다.
4: 구성의 이름을 지정합니다. 구성 이름을 네트워크 연결 정의의 name 값과 일치시키는 것이 좋습니다.
5: 구성할 기본 CNI 플러그인의 이름을 지정합니다.
6: CNI 메타 플러그인의 이름을 지정합니다.
7: 설정할 sysctl을 지정합니다.

yaml 파일의 예는 다음과 같습니다.

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  name: tuningnad
  namespace: default
spec:
  config: '{
    "cniVersion": "0.4.0",
    "name": "tuningnad",
    "plugins": [{
      "type": "bridge"
      },
      {
      "type": "tuning",
      "sysctl": {
         "net.ipv4.conf.IFNAME.accept_redirects": "1"
        }
    }
  ]
}'

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  name: tuningnad
  namespace: default
spec:
  config: '{
    "cniVersion": "0.4.0",
    "name": "tuningnad",
    "plugins": [{
      "type": "bridge"
      },
      {
      "type": "tuning",
      "sysctl": {
         "net.ipv4.conf.IFNAME.accept_redirects": "1"
        }
    }
  ]
}'

Copy to Clipboard

Toggle word wrap

다음 명령을 실행하여 yaml을 적용합니다.

oc apply -f tuning-example.yaml

$ oc apply -f tuning-example.yaml

Copy to Clipboard

Toggle word wrap

출력 예

networkattachmentdefinition.k8.cni.cncf.io/tuningnad created

networkattachmentdefinition.k8.cni.cncf.io/tuningnad created

Copy to Clipboard

Toggle word wrap

다음과 유사한 네트워크 연결 정의를 사용하여 examplepod.yaml 과 같은 Pod를 생성합니다.
```
apiVersion: v1
kind: Pod
metadata:
  name: tunepod
  namespace: default
  annotations:
    k8s.v1.cni.cncf.io/networks: tuningnad 
spec:
  containers:
  - name: podexample
    image: centos
    command: ["/bin/bash", "-c", "sleep INF"]
    securityContext:
      runAsUser: 2000 
      runAsGroup: 3000 
      allowPrivilegeEscalation: false 
      capabilities: 
        drop: ["ALL"]
  securityContext:
    runAsNonRoot: true 
    seccompProfile: 
      type: RuntimeDefault
```
```
apiVersion: v1
kind: Pod
metadata:
  name: tunepod
  namespace: default
  annotations:
    k8s.v1.cni.cncf.io/networks: tuningnad 
```
1
```
spec:
  containers:
  - name: podexample
    image: centos
    command: ["/bin/bash", "-c", "sleep INF"]
    securityContext:
      runAsUser: 2000 
```
2
```
      runAsGroup: 3000 
```
3
```
      allowPrivilegeEscalation: false 
```
4
```
      capabilities: 
```
5
```
        drop: ["ALL"]
  securityContext:
    runAsNonRoot: true 
```
6
```
    seccompProfile: 
```
7
```
      type: RuntimeDefault
```
Copy to Clipboard Toggle word wrap
1
구성된 NetworkAttachmentDefinition 의 이름을 지정합니다.
2
Run AsUser는 컨테이너가 실행되는 사용자 ID를 제어합니다.
3
runAsGroup 은 컨테이너가 실행되는 기본 그룹 ID를 제어합니다.
4
allowPrivilegeEscalation 은 Pod에서 권한 에스컬레이션을 허용하도록 요청할 수 있는지 여부를 결정합니다. 지정되지 않은 경우 기본값은 true입니다. 이 부울은 컨테이너 프로세스에 no_new_privs 플래그가 설정되는지 여부를 직접 제어합니다.
5
기능을 사용하면 전체 루트 액세스 권한을 부여하지 않고 권한 있는 작업을 수행할 수 있습니다. 이 정책은 모든 기능이 Pod에서 삭제되도록 합니다.
6
runAsNonRoot: true 를 사용하려면 컨테이너가 0이 아닌 다른 UID와 함께 컨테이너를 실행해야 합니다.
7
RuntimeDefault 는 Pod 또는 컨테이너 워크로드에 대한 기본 seccomp 프로필을 활성화합니다.
다음 명령을 실행하여 yaml을 적용합니다.
```
oc apply -f examplepod.yaml
```
```
$ oc apply -f examplepod.yaml
```
Copy to Clipboard Toggle word wrap

다음 명령을 실행하여 Pod가 생성되었는지 확인합니다.

oc get pod

$ oc get pod

Copy to Clipboard

Toggle word wrap

출력 예

NAME      READY   STATUS    RESTARTS   AGE
tunepod   1/1     Running   0          47s

NAME      READY   STATUS    RESTARTS   AGE
tunepod   1/1     Running   0          47s

Copy to Clipboard

Toggle word wrap

다음 명령을 실행하여 Pod에 로그인합니다.
```
oc rsh tunepod
```
```
$ oc rsh tunepod
```
Copy to Clipboard Toggle word wrap
구성된 sysctl 플래그 값을 확인합니다. 예를 들어 다음 명령을 실행하여 net.ipv4.conf.net1.accept_redirects 값을 찾습니다.
```
sysctl net.ipv4.conf.net1.accept_redirects
```
```
sh-4.4# sysctl net.ipv4.conf.net1.accept_redirects
```
Copy to Clipboard Toggle word wrap
예상 출력
```
net.ipv4.conf.net1.accept_redirects = 1
```
```
net.ipv4.conf.net1.accept_redirects = 1
```
Copy to Clipboard Toggle word wrap

14장. 베어 메탈 클러스터에서 SCTP(Stream Control Transmission Protocol) 사용
링크 복사

클러스터 관리자는 클러스터에서 SCTP(Stream Control Transmission Protocol)를 사용할 수 있습니다.

14.1. OpenShift Container Platform에서의 SCTP(스트림 제어 전송 프로토콜)
링크 복사

클러스터 관리자는 클러스터의 호스트에서 SCTP를 활성화 할 수 있습니다. RHCOS(Red Hat Enterprise Linux CoreOS)에서 SCTP 모듈은 기본적으로 비활성화되어 있습니다.

SCTP는 IP 네트워크에서 실행되는 안정적인 메시지 기반 프로토콜입니다.

활성화하면 Pod, 서비스, 네트워크 정책에서 SCTP를 프로토콜로 사용할 수 있습니다. type 매개변수를 ClusterIP 또는 NodePort 값으로 설정하여 Service를 정의해야 합니다.

14.1.1. SCTP 프로토콜을 사용하는 구성의 예
링크 복사

protocol 매개변수를 포드 또는 서비스 오브젝트의 SCTP 값으로 설정하여 SCTP를 사용하도록 포드 또는 서비스를 구성할 수 있습니다.

다음 예에서는 pod가 SCTP를 사용하도록 구성되어 있습니다.

apiVersion: v1
kind: Pod
metadata:
  namespace: project1
  name: example-pod
spec:
  containers:
    - name: example-pod
...
      ports:
        - containerPort: 30100
          name: sctpserver
          protocol: SCTP

apiVersion: v1
kind: Pod
metadata:
  namespace: project1
  name: example-pod
spec:
  containers:
    - name: example-pod
...
      ports:
        - containerPort: 30100
          name: sctpserver
          protocol: SCTP

Copy to Clipboard

Toggle word wrap

다음 예에서는 서비스가 SCTP를 사용하도록 구성되어 있습니다.

apiVersion: v1
kind: Service
metadata:
  namespace: project1
  name: sctpserver
spec:
...
  ports:
    - name: sctpserver
      protocol: SCTP
      port: 30100
      targetPort: 30100
  type: ClusterIP

apiVersion: v1
kind: Service
metadata:
  namespace: project1
  name: sctpserver
spec:
...
  ports:
    - name: sctpserver
      protocol: SCTP
      port: 30100
      targetPort: 30100
  type: ClusterIP

Copy to Clipboard

Toggle word wrap

다음 예에서 NetworkPolicy 오브젝트는 특정 레이블이 있는 모든 Pod의 포트 80에서 SCTP 네트워크 트래픽에 적용되도록 구성되어 있습니다.

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-sctp-on-http
spec:
  podSelector:
    matchLabels:
      role: web
  ingress:
  - ports:
    - protocol: SCTP
      port: 80

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-sctp-on-http
spec:
  podSelector:
    matchLabels:
      role: web
  ingress:
  - ports:
    - protocol: SCTP
      port: 80

Copy to Clipboard

Toggle word wrap

14.2. SCTP(스트림 제어 전송 프로토콜) 활성화
링크 복사

클러스터 관리자는 클러스터의 작업자 노드에 블랙리스트 SCTP 커널 모듈을 로드하고 활성화할 수 있습니다.

사전 요구 사항

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

프로세스

다음 YAML 정의가 포함된 load-sctp-module.yaml 파일을 생성합니다.

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  name: load-sctp-module
  labels:
    machineconfiguration.openshift.io/role: worker
spec:
  config:
    ignition:
      version: 3.2.0
    storage:
      files:
        - path: /etc/modprobe.d/sctp-blacklist.conf
          mode: 0644
          overwrite: true
          contents:
            source: data:,
        - path: /etc/modules-load.d/sctp-load.conf
          mode: 0644
          overwrite: true
          contents:
            source: data:,sctp

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  name: load-sctp-module
  labels:
    machineconfiguration.openshift.io/role: worker
spec:
  config:
    ignition:
      version: 3.2.0
    storage:
      files:
        - path: /etc/modprobe.d/sctp-blacklist.conf
          mode: 0644
          overwrite: true
          contents:
            source: data:,
        - path: /etc/modules-load.d/sctp-load.conf
          mode: 0644
          overwrite: true
          contents:
            source: data:,sctp

Copy to Clipboard

Toggle word wrap

MachineConfig 오브젝트를 생성하려면 다음 명령을 입력합니다.
```
oc create -f load-sctp-module.yaml
```
```
$ oc create -f load-sctp-module.yaml
```
Copy to Clipboard Toggle word wrap
선택 사항: MachineConfig Operator가 구성 변경 사항을 적용하는 동안 노드의 상태를 보려면 다음 명령을 입력합니다. 노드 상태가 Ready로 전환되면 구성 업데이트가 적용됩니다.
```
oc get nodes
```
```
$ oc get nodes
```
Copy to Clipboard Toggle word wrap

14.3. SCTP(Stream Control Transmission Protocol)의 활성화 여부 확인
링크 복사

SCTP 트래픽을 수신하는 애플리케이션으로 pod를 만들고 서비스와 연결한 다음, 노출된 서비스에 연결하여 SCTP가 클러스터에서 작동하는지 확인할 수 있습니다.

사전 요구 사항

클러스터에서 인터넷에 액세스하여 nc 패키지를 설치합니다.
OpenShift CLI(oc)를 설치합니다.
cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.

프로세스

SCTP 리스너를 시작하는 포드를 생성합니다.

다음 YAML로 pod를 정의하는 sctp-server.yaml 파일을 생성합니다.

apiVersion: v1
kind: Pod
metadata:
  name: sctpserver
  labels:
    app: sctpserver
spec:
  containers:
    - name: sctpserver
      image: registry.access.redhat.com/ubi8/ubi
      command: ["/bin/sh", "-c"]
      args:
        ["dnf install -y nc && sleep inf"]
      ports:
        - containerPort: 30102
          name: sctpserver
          protocol: SCTP

apiVersion: v1
kind: Pod
metadata:
  name: sctpserver
  labels:
    app: sctpserver
spec:
  containers:
    - name: sctpserver
      image: registry.access.redhat.com/ubi8/ubi
      command: ["/bin/sh", "-c"]
      args:
        ["dnf install -y nc && sleep inf"]
      ports:
        - containerPort: 30102
          name: sctpserver
          protocol: SCTP

Copy to Clipboard

Toggle word wrap

다음 명령을 입력하여 pod를 생성합니다.
```
oc create -f sctp-server.yaml
```
```
$ oc create -f sctp-server.yaml
```
Copy to Clipboard Toggle word wrap

SCTP 리스너 pod에 대한 서비스를 생성합니다.

다음 YAML을 사용하여 서비스를 정의하는 sctp-service.yaml 파일을 생성합니다.

apiVersion: v1
kind: Service
metadata:
  name: sctpservice
  labels:
    app: sctpserver
spec:
  type: NodePort
  selector:
    app: sctpserver
  ports:
    - name: sctpserver
      protocol: SCTP
      port: 30102
      targetPort: 30102

apiVersion: v1
kind: Service
metadata:
  name: sctpservice
  labels:
    app: sctpserver
spec:
  type: NodePort
  selector:
    app: sctpserver
  ports:
    - name: sctpserver
      protocol: SCTP
      port: 30102
      targetPort: 30102

Copy to Clipboard

Toggle word wrap

서비스를 생성하려면 다음 명령을 입력합니다.
```
oc create -f sctp-service.yaml
```
```
$ oc create -f sctp-service.yaml
```
Copy to Clipboard Toggle word wrap

SCTP 클라이언트에 대한 pod를 생성합니다.

다음 YAML을 사용하여 sctp-client.yaml 파일을 만듭니다.

apiVersion: v1
kind: Pod
metadata:
  name: sctpclient
  labels:
    app: sctpclient
spec:
  containers:
    - name: sctpclient
      image: registry.access.redhat.com/ubi8/ubi
      command: ["/bin/sh", "-c"]
      args:
        ["dnf install -y nc && sleep inf"]

apiVersion: v1
kind: Pod
metadata:
  name: sctpclient
  labels:
    app: sctpclient
spec:
  containers:
    - name: sctpclient
      image: registry.access.redhat.com/ubi8/ubi
      command: ["/bin/sh", "-c"]
      args:
        ["dnf install -y nc && sleep inf"]

Copy to Clipboard

Toggle word wrap

Pod 오브젝트를 생성하려면 다음 명령을 입력합니다.
```
oc apply -f sctp-client.yaml
```
```
$ oc apply -f sctp-client.yaml
```
Copy to Clipboard Toggle word wrap

서버에서 SCTP 리스너를 실행합니다.
1. 서버 Pod에 연결하려면 다음 명령을 입력합니다.
  $ oc rsh sctpserver
  Copy to Clipboard Toggle word wrap
2. SCTP 리스너를 시작하려면 다음 명령을 입력합니다.
  $ nc -l 30102 --sctp
  Copy to Clipboard Toggle word wrap
서버의 SCTP 리스너에 연결합니다.
1. 터미널 프로그램에서 새 터미널 창 또는 탭을 엽니다.
2. sctpservice 서비스의 IP 주소를 얻습니다. 다음 명령을 실행합니다.
  $ oc get services sctpservice -o go-template='{{.spec.clusterIP}}{{"\n"}}'
  Copy to Clipboard Toggle word wrap
3. 클라이언트 Pod에 연결하려면 다음 명령을 입력합니다.
  $ oc rsh sctpclient
  Copy to Clipboard Toggle word wrap
4. SCTP 클라이언트를 시작하려면 다음 명령을 입력합니다. <cluster_IP>를 sctpservice 서비스의 클러스터 IP 주소로 변경합니다.
  # nc <cluster_IP> 30102 --sctp
  Copy to Clipboard Toggle word wrap

15장. PTP 하드웨어 사용
링크 복사

OpenShift Container Platform 클러스터 노드에서 linuxptp 서비스를 구성하고 PTP 지원 하드웨어를 사용할 수 있습니다.

15.1. PTP 하드웨어 정보
링크 복사

PTP Operator를 배포하여 OpenShift Container Platform 콘솔 또는 OpenShift CLI (oc)를 사용하여 PTP를 설치할 수 있습니다. PTP Operator는 linuxptp 서비스를 생성 및 관리하고 다음 기능을 제공합니다.

클러스터에서 PTP 가능 장치 검색.
linuxptp 서비스의 구성 관리.
PTP Operator cloud-event-proxy 사이드카를 사용하여 애플리케이션의 성능 및 안정성에 부정적인 영향을 주는 PTP 클록 이벤트 알림

참고

PTP Operator는 베어 메탈 인프라에서만 프로비저닝된 클러스터에서 PTP 가능 장치와 함께 작동합니다.

15.2. PTP 정보
링크 복사

PTP(Precision Time Protocol)는 네트워크에서 클럭을 동기화하는 데 사용됩니다. 하드웨어 지원과 함께 사용할 경우 PTP는 마이크로초 미만의 정확성을 수행할 수 있으며 NTP(Network Time Protocol)보다 더 정확합니다.

linuxptp 패키지에는 클럭 동기화를 위한 ptp4l 및 phc2sys 프로그램이 포함되어 있습니다. ptp4l은 PTP 경계 클록과 일반 클록을 구현합니다. ptp4l는 하드웨어 타임스탬프를 사용하여 PTP 하드웨어 클록을 소스 클록에 동기화하고 소프트웨어 타임스탬프를 사용하여 시스템 클록을 소스 클록에 동기화합니다. phc2sys는 하드웨어 타임스탬프에 NIC(네트워크 인터페이스 컨트롤러)의 PTP 하드웨어 클록에 동기화하는 데 사용됩니다.

15.2.1. PTP 도메인의 요소
링크 복사

PTP는 네트워크에 연결된 여러 노드를 각 노드의 클럭과 동기화하는 데 사용됩니다. PTP에 의해 동기화된 클럭은 소스 대상 계층 구조로 구성됩니다. 계층 구조는 모든 클럭에서 실행되는 최상의 마스터 시계(BMC) 알고리즘에 의해 자동으로 생성 및 업데이트됩니다. 대상 클럭은 소스 클럭에 동기화되며 대상 클럭은 다른 다운스트림 시계의 소스가 될 수 있습니다. 다음 유형의 클럭을 구성에 포함할 수 있습니다.

GRandmaster 클록: 마스터 클록은 네트워크의 다른 클록에 표준 시간 정보를 제공하며 정확하고 안정적인 동기화를 보장합니다. 타임스탬프를 작성하고 다른 클럭의 시간 요청에 응답합니다. Grandmaster 시계를 GPS(Global Positioning System) 시간 소스에 동기화할 수 있습니다.
일반 클록: 일반 클록에는 네트워크의 위치에 따라 소스 또는 대상 클록의 역할을 수행할 수 있는 단일 포트가 연결되어 있습니다. 일반 클록은 타임스탬프를 읽고 쓸 수 있습니다.
경계 클록: 경계 클록에는 두 개 이상의 통신 경로에 포트가 있으며, 동시에 소스와 다른 대상 클록의 대상일 수 있습니다. 경계 클록은 대상 클록으로 작동합니다. 대상 클럭이 타이밍 메시지를 수신하고 지연을 조정한 다음 네트워크를 전달하기 위한 새 소스 시간 신호를 생성합니다. 경계 클록은 소스 클록과 정확하게 동기화되는 새로운 타이밍 패킷을 생성하며 소스 클럭에 직접 보고하는 연결된 장치의 수를 줄일 수 있습니다.

15.2.2. NTP를 통한 PTP의 이점
링크 복사

PTP가 NTP를 능가하는 주요 이점 중 하나는 다양한 NIC(네트워크 인터페이스 컨트롤러) 및 네트워크 스위치에 있는 하드웨어 지원입니다. 특수 하드웨어를 사용하면 PTP가 메시지 전송 지연을 고려하여 시간 동기화의 정확성을 향상시킬 수 있습니다. 최대한의 정확성을 달성하려면 PTP 클록 사이의 모든 네트워킹 구성 요소를 PTP 하드웨어를 사용하도록 설정하는 것이 좋습니다.

NIC는 전송 및 수신 즉시 PTP 패킷을 타임스탬프할 수 있으므로 하드웨어 기반 PTP는 최적의 정확성을 제공합니다. 이를 운영 체제에서 PTP 패킷을 추가로 처리해야 하는 소프트웨어 기반 PTP와 비교합니다.

중요

PTP를 활성화하기 전에 필수 노드에 대해 NTP가 비활성화되어 있는지 확인합니다. MachineConfig 사용자 정의 리소스를 사용하여 chrony 타임 서비스 (chronyd)를 비활성화할 수 있습니다. 자세한 내용은 chrony 타임 서비스 비활성화를 참조하십시오.

15.2.3. 듀얼 NIC 하드웨어에서 PTP 사용
링크 복사

OpenShift Container Platform은 클러스터에서 정밀한 PTP 타이밍을 위해 단일 및 듀얼 NIC 하드웨어를 지원합니다.

대역 중 사양을 제공하는 5G 통신망의 경우 각 가상 분산 장치(vDU)는 6개의 무선 단위(RU)에 연결되어 있어야 합니다. 이러한 연결을 수행하기 위해 각 vDU 호스트에 경계 시계로 구성된 2개의 NIC가 필요합니다.

듀얼 NIC 하드웨어를 사용하면 각 NIC가 다운스트림 클럭을 공급하는 별도의 ptp4l 인스턴스와 함께 각 NIC를 동일한 업스트림 리더 시계에 연결할 수 있습니다.

15.3. CLI를 사용하여 PTP Operator 설치
링크 복사

클러스터 관리자는 CLI를 사용하여 Operator를 설치할 수 있습니다.

사전 요구 사항

PTP를 지원하는 하드웨어가 있는 노드로 베어 메탈 하드웨어에 설치된 클러스터
OpenShift CLI(oc)를 설치합니다.
cluster-admin 권한이 있는 사용자로 로그인합니다.

절차

PTP Operator의 네임스페이스를 생성합니다.

다음 YAML을 ptp-namespace.yaml 파일에 저장합니다.

apiVersion: v1
kind: Namespace
metadata:
  name: openshift-ptp
  annotations:
    workload.openshift.io/allowed: management
  labels:
    name: openshift-ptp
    openshift.io/cluster-monitoring: "true"

apiVersion: v1
kind: Namespace
metadata:
  name: openshift-ptp
  annotations:
    workload.openshift.io/allowed: management
  labels:
    name: openshift-ptp
    openshift.io/cluster-monitoring: "true"

Copy to Clipboard

Toggle word wrap

네임스페이스 CR을 생성합니다.
```
oc create -f ptp-namespace.yaml
```
```
$ oc create -f ptp-namespace.yaml
```
Copy to Clipboard Toggle word wrap

PTP Operator를 위한 Operator 그룹을 생성합니다.

다음 YAML을 ptp-operatorgroup.yaml 파일에 저장합니다.

apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: ptp-operators
  namespace: openshift-ptp
spec:
  targetNamespaces:
  - openshift-ptp

apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: ptp-operators
  namespace: openshift-ptp
spec:
  targetNamespaces:
  - openshift-ptp

Copy to Clipboard

Toggle word wrap

OperatorGroup CR을 생성합니다.
```
oc create -f ptp-operatorgroup.yaml
```
```
$ oc create -f ptp-operatorgroup.yaml
```
Copy to Clipboard Toggle word wrap

PTP Operator에 등록합니다.

다음 YAML을 ptp-sub.yaml 파일에 저장합니다.

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: ptp-operator-subscription
  namespace: openshift-ptp
spec:
  channel: "stable"
  name: ptp-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: ptp-operator-subscription
  namespace: openshift-ptp
spec:
  channel: "stable"
  name: ptp-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace

Copy to Clipboard

Toggle word wrap

서브스크립션 CR을 생성합니다.
```
oc create -f ptp-sub.yaml
```
```
$ oc create -f ptp-sub.yaml
```
Copy to Clipboard Toggle word wrap

Operator가 설치되었는지 확인하려면 다음 명령을 입력합니다.

oc get csv -n openshift-ptp -o custom-columns=Name:.metadata.name,Phase:.status.phase

$ oc get csv -n openshift-ptp -o custom-columns=Name:.metadata.name,Phase:.status.phase

Copy to Clipboard

Toggle word wrap

출력 예

Name                         Phase
4.12.0-202301261535          Succeeded

Name                         Phase
4.12.0-202301261535          Succeeded

Copy to Clipboard

Toggle word wrap

15.4. 웹 콘솔을 사용하여 PTP Operator 설치
링크 복사

클러스터 관리자는 웹 콘솔을 사용하여 PTP Operator를 설치할 수 있습니다.

참고

이전 섹션에서 언급한 것처럼 네임스페이스 및 Operator group을 생성해야 합니다.

프로세스

OpenShift Container Platform 웹 콘솔을 사용하여 PTP Operator를 설치합니다.
1. OpenShift Container Platform 웹 콘솔에서 Operator → OperatorHub를 클릭합니다.
2. 사용 가능한 Operator 목록에서 PTP Operator를 선택한 다음 설치를 클릭합니다.
3. Operator 설치 페이지의 클러스터의 특정 네임스페이스에서 openshift-ptp를 선택합니다. 그런 다음, 설치를 클릭합니다.
선택 사항: PTP Operator가 설치되었는지 확인합니다.
1. Operator → 설치된 Operator 페이지로 전환합니다.
2. PTP Operator가 openshift-ptp 프로젝트에 InstallSucceeded 상태로 나열되어 있는지 확인합니다.
  참고
  설치 중에 Operator는 실패 상태를 표시할 수 있습니다. 나중에 InstallSucceeded 메시지와 함께 설치에 성공하면 이 실패 메시지를 무시할 수 있습니다.
  Operator가 설치된 것으로 나타나지 않으면 다음과 같이 추가 문제 해결을 수행합니다.
  - Operator → 설치된 Operator 페이지로 이동하고 Operator 서브스크립션 및 설치 계획 탭의 상태에 장애나 오류가 있는지 검사합니다.
  - Workloads → Pod 페이지로 이동하여 openshift-ptp 프로젝트에서 Pod 로그를 확인합니다.

15.5. PTP 장치 구성
링크 복사

PTP Operator는 NodePtpDevice.ptp.openshift.io CRD(custom resource definition)를 OpenShift Container Platform에 추가합니다.

PTP Operator는 각 노드에서 PTP 가능 네트워크 장치를 클러스터에서 검색합니다. 호환 가능한 PTP 가능 네트워크 장치를 제공하는 각 노드에 대해 NodePtpDevice CR(사용자 정의 리소스) 오브젝트를 생성하고 업데이트합니다.

15.5.1. 클러스터에서 PTP 가능 네트워크 장치 검색
링크 복사

클러스터에서 PTP 가능 네트워크 장치의 전체 목록을 반환하려면 다음 명령을 실행합니다.

oc get NodePtpDevice -n openshift-ptp -o yaml

$ oc get NodePtpDevice -n openshift-ptp -o yaml

Copy to Clipboard

Toggle word wrap

출력 예

apiVersion: v1
items:
- apiVersion: ptp.openshift.io/v1
  kind: NodePtpDevice
  metadata:
    creationTimestamp: "2022-01-27T15:16:28Z"
    generation: 1
    name: dev-worker-0 
    namespace: openshift-ptp
    resourceVersion: "6538103"
    uid: d42fc9ad-bcbf-4590-b6d8-b676c642781a
  spec: {}
  status:
    devices: 
    - name: eno1
    - name: eno2
    - name: eno3
    - name: eno4
    - name: enp5s0f0
    - name: enp5s0f1
...

apiVersion: v1
items:
- apiVersion: ptp.openshift.io/v1
  kind: NodePtpDevice
  metadata:
    creationTimestamp: "2022-01-27T15:16:28Z"
    generation: 1
    name: dev-worker-0

1


    namespace: openshift-ptp
    resourceVersion: "6538103"
    uid: d42fc9ad-bcbf-4590-b6d8-b676c642781a
  spec: {}
  status:
    devices:

2


    - name: eno1
    - name: eno2
    - name: eno3
    - name: eno4
    - name: enp5s0f0
    - name: enp5s0f1
...

Copy to Clipboard

Toggle word wrap

1: name 매개변수의 값은 상위 노드의 이름과 동일합니다.
2: devices 컬렉션에는 PTP Operator가 노드를 검색할 PTP 지원 장치 목록이 포함됩니다.

15.5.2. linuxptp 서비스를 일반 클럭으로 구성
링크 복사

PtpConfig CR(사용자 정의 리소스) 오브젝트를 생성하여 linuxptp 서비스(ptp4l,phc2sys)를 일반 시계로 구성할 수 있습니다.

참고

다음 예제 PtpConfig CR을 기반으로 linuxptp 서비스를 특정 하드웨어 및 환경에 대한 일반 클럭으로 구성합니다. 이 예제 CR에서는 ptp4lOpts,ptp4lConf 및 ptpClockThreshold 에 대한 적절한 값을 설정하여 PTP 빠른 이벤트를 구성합니다. ptpClockThreshold 는 이벤트가 활성화된 경우에만 사용됩니다.

사전 요구 사항

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

절차

다음 PtpConfig CR을 생성한 다음 YAML을 ordinary-clock-ptp-config.yaml 파일에 저장합니다.

apiVersion: ptp.openshift.io/v1
kind: PtpConfig
metadata:
  name: ordinary-clock-ptp-config                       
  namespace: openshift-ptp
spec:
  profile:                                              
  - name: "<profile_name>"                              
    interface: ""<interface_name>"                      
    ptp4lOpts: "-2 -s --summary_interval -4"            
    phc2sysOpts: "-a -r -n 24"                          
    ptp4lConf: |                                        
     [global]
      #
      # Default Data Set
      #
      twoStepFlag                        1
      slaveOnly                          0
      priority1                          128
      priority2                          128
      domainNumber                       24
      #utc_offset                        37
      clockClass                         248
      clockAccuracy                      0xFE
      offsetScaledLogVariance            0xFFFF
      free_running                       0
      freq_est_interval                  1
      dscp_event                         0
      dscp_general                       0
      dataset_comparison                 G.8275.x
      G.8275.defaultDS.localPriority     128
      #
      # Port Data Set
      #
      logAnnounceInterval               -3
      logSyncInterval                   -4
      logMinDelayReqInterval            -4
      logMinPdelayReqInterval           -4
      announceReceiptTimeout             3
      syncReceiptTimeout                 0
      delayAsymmetry                     0
      fault_reset_interval               4
      neighborPropDelayThresh            20000000
      masterOnly                         0
      G.8275.portDS.localPriority        128
      #
      # Run time options
      #
      assume_two_step                    0
      logging_level                      6
      path_trace_enabled                 0
      follow_up_info                     0
      hybrid_e2e                         0
      inhibit_multicast_service          0
      net_sync_monitor                   0
      tc_spanning_tree                   0
      tx_timestamp_timeout               10             
      unicast_listen                     0
      unicast_master_table               0
      unicast_req_duration               3600
      use_syslog                         1
      verbose                            0
      summary_interval                   0
      kernel_leap                        1
      check_fup_sync                     0
      #
      # Servo Options
      #
      pi_proportional_const              0.0
      pi_integral_const                  0.0
      pi_proportional_scale              0.0
      pi_proportional_exponent          -0.3
      pi_proportional_norm_max           0.7
      pi_integral_scale                  0.0
      pi_integral_exponent               0.4
      pi_integral_norm_max               0.3
      step_threshold                     2.0
      first_step_threshold               0.00002
      max_frequency                      900000000
      clock_servo                        pi
      sanity_freq_limit                  200000000
      ntpshm_segment                     0
      #
      # Transport options
      #
      transportSpecific                  0x0
      ptp_dst_mac                        01:1B:19:00:00:00
      p2p_dst_mac                        01:80:C2:00:00:0E
      udp_ttl                            1
      udp6_scope                         0x0E
      uds_address                        /var/run/ptp4l
      #
      # Default interface options
      #
      clock_type                         OC
      network_transport                  L2
      delay_mechanism                    E2E
      time_stamping                      hardware
      tsproc_mode                        filter
      delay_filter                       moving_median
      delay_filter_length                10
      egressLatency                      0
      ingressLatency                     0
      boundary_clock_jbod                0              
      #
      # Clock description
      #
      productDescription                 ;;
      revisionData                       ;;
      manufacturerIdentity               00:00:00
      userDescription                    ;
      timeSource                         0xA0
    ptpSchedulingPolicy:                 SCHED_OTHER    
    ptpSchedulingPriority:               10             
  ptpClockThreshold:                                    
    holdOverTimeout:                     5
    maxOffsetThreshold:                  100
    minOffsetThreshold:                 -100
  recommend:                                            
  - profile: "profile1"                                 
    priority: 0                                         
    match:                                              
    - nodeLabel: "node-role.kubernetes.io/worker"       
      nodeName: "compute-0.example.com"

apiVersion: ptp.openshift.io/v1
kind: PtpConfig
metadata:
  name: ordinary-clock-ptp-config

1


  namespace: openshift-ptp
spec:
  profile:

2


  - name: "<profile_name>"

3


    interface: ""<interface_name>"

4


    ptp4lOpts: "-2 -s --summary_interval -4"

5


    phc2sysOpts: "-a -r -n 24"

6


    ptp4lConf: |

7


     [global]
      #
      # Default Data Set
      #
      twoStepFlag                        1
      slaveOnly                          0
      priority1                          128
      priority2                          128
      domainNumber                       24
      #utc_offset                        37
      clockClass                         248
      clockAccuracy                      0xFE
      offsetScaledLogVariance            0xFFFF
      free_running                       0
      freq_est_interval                  1
      dscp_event                         0
      dscp_general                       0
      dataset_comparison                 G.8275.x
      G.8275.defaultDS.localPriority     128
      #
      # Port Data Set
      #
      logAnnounceInterval               -3
      logSyncInterval                   -4
      logMinDelayReqInterval            -4
      logMinPdelayReqInterval           -4
      announceReceiptTimeout             3
      syncReceiptTimeout                 0
      delayAsymmetry                     0
      fault_reset_interval               4
      neighborPropDelayThresh            20000000
      masterOnly                         0
      G.8275.portDS.localPriority        128
      #
      # Run time options
      #
      assume_two_step                    0
      logging_level                      6
      path_trace_enabled                 0
      follow_up_info                     0
      hybrid_e2e                         0
      inhibit_multicast_service          0
      net_sync_monitor                   0
      tc_spanning_tree                   0
      tx_timestamp_timeout               10

8


      unicast_listen                     0
      unicast_master_table               0
      unicast_req_duration               3600
      use_syslog                         1
      verbose                            0
      summary_interval                   0
      kernel_leap                        1
      check_fup_sync                     0
      #
      # Servo Options
      #
      pi_proportional_const              0.0
      pi_integral_const                  0.0
      pi_proportional_scale              0.0
      pi_proportional_exponent          -0.3
      pi_proportional_norm_max           0.7
      pi_integral_scale                  0.0
      pi_integral_exponent               0.4
      pi_integral_norm_max               0.3
      step_threshold                     2.0
      first_step_threshold               0.00002
      max_frequency                      900000000
      clock_servo                        pi
      sanity_freq_limit                  200000000
      ntpshm_segment                     0
      #
      # Transport options
      #
      transportSpecific                  0x0
      ptp_dst_mac                        01:1B:19:00:00:00
      p2p_dst_mac                        01:80:C2:00:00:0E
      udp_ttl                            1
      udp6_scope                         0x0E
      uds_address                        /var/run/ptp4l
      #
      # Default interface options
      #
      clock_type                         OC
      network_transport                  L2
      delay_mechanism                    E2E
      time_stamping                      hardware
      tsproc_mode                        filter
      delay_filter                       moving_median
      delay_filter_length                10
      egressLatency                      0
      ingressLatency                     0
      boundary_clock_jbod                0

9


      #
      # Clock description
      #
      productDescription                 ;;
      revisionData                       ;;
      manufacturerIdentity               00:00:00
      userDescription                    ;
      timeSource                         0xA0
    ptpSchedulingPolicy:                 SCHED_OTHER

10


    ptpSchedulingPriority:               10

11


  ptpClockThreshold:

12


    holdOverTimeout:                     5
    maxOffsetThreshold:                  100
    minOffsetThreshold:                 -100
  recommend:

13


  - profile: "profile1"

14


    priority: 0

15


    match:

16


    - nodeLabel: "node-role.kubernetes.io/worker"

17


      nodeName: "compute-0.example.com"

18

Copy to Clipboard

Toggle word wrap

1: PtpConfig CR의 이름입니다.
2: 하나 이상의 profile 오브젝트의 배열을 지정합니다.
3: 프로필 오브젝트의 고유 이름을 지정합니다.
4: ptp4l 서비스에서 사용할 네트워크 인터페이스를 지정합니다(예: ens787f1 ).
5: ptp4l 서비스에 대한 시스템 구성 옵션을 지정합니다. 예를 들어 -2 는 IEEE 802.3 네트워크 전송을 선택합니다. 옵션은 네트워크 인터페이스 이름과 서비스 구성 파일이 자동으로 추가되므로 네트워크 인터페이스 이름 -i <interface> 및 서비스 구성 파일 -f /etc/ptp4l.conf를 포함하지 않아야 합니다. 이 인터페이스에서 PTP 빠른 이벤트를 사용하려면 --summary_interval -4 를 추가합니다.
6: phc2sys 서비스에 대한 시스템 구성 옵션을 지정합니다. 이 필드가 비어 있으면 PTP Operator에서 phc2sys 서비스를 시작하지 않습니다. Intel Coumbiaville 800 시리즈 NIC의 경우 phc2sysOpts 옵션을 -a -r -m -n 24 -N 8 -R 16 으로 설정합니다. -m 은 stdout 에 메시지를 출력합니다. linuxptp-daemon DaemonSet 은 로그를 구문 분석하고 Prometheus 지표를 생성합니다.
7: 기본 /etc/ptp4l.conf 파일을 대체할 구성이 포함된 문자열을 지정합니다. 기본 구성을 사용하려면 필드를 비워 둡니다.
8: Intel Coumbiaville 800 시리즈 NIC의 경우 tx_timestamp_timeout 을 50 으로 설정합니다.
9: Intel Columbiaville 800 시리즈 NIC의 경우 boundary_clock_jbod 를 0 으로 설정합니다.
10: ptp4l 및 phc2sys 프로세스에 대한 스케줄링 정책입니다. 기본값은-4.8 _OTHER 입니다. Havana 스케줄링을 지원하는 시스템에서 Retain_ VRF를 사용합니다.
11: ptpSchedulingPolicy 가ECDHE _FIFO로 설정된 경우 ptp4l 및 phc2sys 프로세스의 FIFO 우선 순위를 설정하는 데 사용되는 1-65의 정수 값입니다. ptpSchedulingPriority 필드는 ptpSchedulingPolicy 가ECDHE _OTHER 로 설정된 경우 사용되지 않습니다.
12: 선택 사항: ptpClockThreshold 가 없으면 기본값이 ptpClockThreshold 필드에 사용됩니다. 스탠자는 기본 ptpClockThreshold 값을 표시합니다. ptpClockThreshold 값은 PTP 이벤트가 트리거되기 전에 PTP 마스터 클럭이 연결 해제된 후의 기간을 구성합니다. holdOverTimeout 은 PTP 마스터 클럭의 연결이 끊어지면 PTP 클럭 이벤트 상태가 FREERUN 로 변경되기 전 시간(초)입니다. maxOffsetThreshold 및 minOffsetThreshold 설정은 CLOCK_REALTIME (phc2sys) 또는 마스터 오프셋(ptp4l)의 값과 비교되는 나노초에 오프셋 값을 구성합니다. ptp4l 또는 phc2sys 오프셋 값이 이 범위를 벗어나는 경우 PTP 클럭 상태가 FREERUN 로 설정됩니다. 오프셋 값이 이 범위 내에 있으면 PTP 클럭 상태가 LOCKED 로 설정됩니다.
13: 프로필 을 노드에 적용하는 방법에 대한 규칙을 정의하는 하나 이상의 recommend 오브젝트 배열을 지정합니다.
14: profile 섹션에 정의된 profile 오브젝트 이름을 지정합니다.
15: 일반 시계의 경우 priority 를 0 으로 설정합니다.
16: nodeLabel 또는 nodeName으로 일치 규칙을 지정합니다.
17: oc get nodes --show-labels 명령을 사용하여 노드 오브젝트에서 node.Labels 의 키로 nodeLabel 을 지정합니다.
18: oc get nodes 명령을 사용하여 노드 오브젝트에서 node.Name 으로 nodeName 을 지정합니다.

다음 명령을 실행하여 PtpConfig CR을 생성합니다.
```
oc create -f ordinary-clock-ptp-config.yaml
```
```
$ oc create -f ordinary-clock-ptp-config.yaml
```
Copy to Clipboard Toggle word wrap

검증

PtpConfig 프로필이 노드에 적용되었는지 확인합니다.

다음 명령을 실행하여 openshift-ptp 네임스페이스에서 Pod 목록을 가져옵니다.

oc get pods -n openshift-ptp -o wide

$ oc get pods -n openshift-ptp -o wide

Copy to Clipboard

Toggle word wrap

출력 예

NAME                            READY   STATUS    RESTARTS   AGE   IP               NODE
linuxptp-daemon-4xkbb           1/1     Running   0          43m   10.1.196.24      compute-0.example.com
linuxptp-daemon-tdspf           1/1     Running   0          43m   10.1.196.25      compute-1.example.com
ptp-operator-657bbb64c8-2f8sj   1/1     Running   0          43m   10.129.0.61      control-plane-1.example.com

NAME                            READY   STATUS    RESTARTS   AGE   IP               NODE
linuxptp-daemon-4xkbb           1/1     Running   0          43m   10.1.196.24      compute-0.example.com
linuxptp-daemon-tdspf           1/1     Running   0          43m   10.1.196.25      compute-1.example.com
ptp-operator-657bbb64c8-2f8sj   1/1     Running   0          43m   10.129.0.61      control-plane-1.example.com

Copy to Clipboard

Toggle word wrap

프로필이 올바른지 확인합니다. PtpConfig 프로필에 지정한 노드에 해당하는 linuxptp 데몬의 로그를 검사합니다. 다음 명령을 실행합니다.

oc logs linuxptp-daemon-4xkbb -n openshift-ptp -c linuxptp-daemon-container

$ oc logs linuxptp-daemon-4xkbb -n openshift-ptp -c linuxptp-daemon-container

Copy to Clipboard

Toggle word wrap

출력 예

I1115 09:41:17.117596 4143292 daemon.go:107] in applyNodePTPProfile
I1115 09:41:17.117604 4143292 daemon.go:109] updating NodePTPProfile to:
I1115 09:41:17.117607 4143292 daemon.go:110] ------------------------------------
I1115 09:41:17.117612 4143292 daemon.go:102] Profile Name: profile1
I1115 09:41:17.117616 4143292 daemon.go:102] Interface: ens787f1
I1115 09:41:17.117620 4143292 daemon.go:102] Ptp4lOpts: -2 -s --summary_interval -4
I1115 09:41:17.117623 4143292 daemon.go:102] Phc2sysOpts: -a -r -n 24
I1115 09:41:17.117626 4143292 daemon.go:116] ------------------------------------

I1115 09:41:17.117596 4143292 daemon.go:107] in applyNodePTPProfile
I1115 09:41:17.117604 4143292 daemon.go:109] updating NodePTPProfile to:
I1115 09:41:17.117607 4143292 daemon.go:110] ------------------------------------
I1115 09:41:17.117612 4143292 daemon.go:102] Profile Name: profile1
I1115 09:41:17.117616 4143292 daemon.go:102] Interface: ens787f1
I1115 09:41:17.117620 4143292 daemon.go:102] Ptp4lOpts: -2 -s --summary_interval -4
I1115 09:41:17.117623 4143292 daemon.go:102] Phc2sysOpts: -a -r -n 24
I1115 09:41:17.117626 4143292 daemon.go:116] ------------------------------------

Copy to Clipboard

Toggle word wrap

15.5.3. linuxptp 서비스를 경계 시계로 구성
링크 복사

PtpConfig CR(사용자 정의 리소스) 오브젝트를 생성하여 linuxptp 서비스(ptp4l,phc2sys)를 경계 시계로 구성할 수 있습니다.

참고

다음 예제 PtpConfig CR을 기반으로 linuxptp 서비스를 특정 하드웨어 및 환경에 대한 경계 클럭으로 구성합니다. 이 예제 CR은 또한 ptp4lOpts,ptp4lConf, ptpClockThreshold 에 적절한 값을 설정하여 PTP 빠른 이벤트를 구성합니다. ptpClockThreshold 는 이벤트가 활성화된 경우에만 사용됩니다.

사전 요구 사항

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

절차

다음 PtpConfig CR을 만든 다음 YAML을 boundary-clock-ptp-config.yaml 파일에 저장합니다.

apiVersion: ptp.openshift.io/v1
kind: PtpConfig
metadata:
  name: boundary-clock-ptp-config                     
  namespace: openshift-ptp
spec:
  profile:                                            
  - name: "<profile_name>"                            
    ptp4lOpts: "-2 --summary_interval -4"             
    ptp4lConf: |                                      
      [ens1f0]                                        
      masterOnly 0
      [ens1f3]                                        
      masterOnly 1
      [global]
      #
      # Default Data Set
      #
      twoStepFlag                       1
      #slaveOnly                        1
      priority1                         128
      priority2                         128
      domainNumber                      24
      #utc_offset                       37
      clockClass                        248
      clockAccuracy                     0xFE
      offsetScaledLogVariance           0xFFFF
      free_running                      0
      freq_est_interval                 1
      dscp_event                        0
      dscp_general                      0
      dataset_comparison                G.8275.x
      G.8275.defaultDS.localPriority    128
      #
      # Port Data Set
      #
      logAnnounceInterval              -3
      logSyncInterval                  -4
      logMinDelayReqInterval           -4
      logMinPdelayReqInterval          -4
      announceReceiptTimeout            3
      syncReceiptTimeout                0
      delayAsymmetry                    0
      fault_reset_interval              4
      neighborPropDelayThresh           20000000
      masterOnly                        0
      G.8275.portDS.localPriority       128
      #
      # Runtime options
      #
      assume_two_step                   0
      logging_level                     6
      path_trace_enabled                0
      follow_up_info                    0
      hybrid_e2e                        0
      inhibit_multicast_service         0
      net_sync_monitor                  0
      tc_spanning_tree                  0
      tx_timestamp_timeout              10            
      unicast_listen                    0
      unicast_master_table              0
      unicast_req_duration              3600
      use_syslog                        1
      verbose                           0
      summary_interval                 -4
      kernel_leap                       1
      check_fup_sync                    0
      #
      # Servo Options
      #
      pi_proportional_const             0.0
      pi_integral_const                 0.0
      pi_proportional_scale             0.0
      pi_proportional_exponent         -0.3
      pi_proportional_norm_max          0.7
      pi_integral_scale                 0.0
      pi_integral_exponent              0.4
      pi_integral_norm_max              0.3
      step_threshold                    2.0
      first_step_threshold              0.00002
      max_frequency                     900000000
      clock_servo                       pi
      sanity_freq_limit                 200000000
      ntpshm_segment                    0
      #
      # Transport options
      #
      transportSpecific                 0x0
      ptp_dst_mac                       01:1B:19:00:00:00
      p2p_dst_mac                       01:80:C2:00:00:0E
      udp_ttl                           1
      udp6_scope                        0x0E
      uds_address                       /var/run/ptp4l
      #
      # Default interface options
      #
      clock_type                        BC
      network_transport                 L2
      delay_mechanism                   E2E
      time_stamping                     hardware
      tsproc_mode                       filter
      delay_filter                      moving_median
      delay_filter_length               10
      egressLatency                     0
      ingressLatency                    0
      boundary_clock_jbod               0             
      #
      # Clock description
      #
      productDescription                ;;
      revisionData                      ;;
      manufacturerIdentity              00:00:00
      userDescription                   ;
      timeSource                        0xA0
    phc2sysOpts:                        "-a -r -n 24" 
    ptpSchedulingPolicy:                SCHED_OTHER   
    ptpSchedulingPriority:              10            
  ptpClockThreshold:                                  
    holdOverTimeout:                    5
    maxOffsetThreshold:                 100
    minOffsetThreshold:                -100
  recommend:                                          
  - profile: "<profile_name>"                         
    priority: 10                                      
    match:                                            
    - nodeLabel: "<node_label>"                       
      nodeName: "<node_name>"

apiVersion: ptp.openshift.io/v1
kind: PtpConfig
metadata:
  name: boundary-clock-ptp-config

1


  namespace: openshift-ptp
spec:
  profile:

2


  - name: "<profile_name>"

3


    ptp4lOpts: "-2 --summary_interval -4"

4


    ptp4lConf: |

5


      [ens1f0]

6


      masterOnly 0
      [ens1f3]

7


      masterOnly 1
      [global]
      #
      # Default Data Set
      #
      twoStepFlag                       1
      #slaveOnly                        1
      priority1                         128
      priority2                         128
      domainNumber                      24
      #utc_offset                       37
      clockClass                        248
      clockAccuracy                     0xFE
      offsetScaledLogVariance           0xFFFF
      free_running                      0
      freq_est_interval                 1
      dscp_event                        0
      dscp_general                      0
      dataset_comparison                G.8275.x
      G.8275.defaultDS.localPriority    128
      #
      # Port Data Set
      #
      logAnnounceInterval              -3
      logSyncInterval                  -4
      logMinDelayReqInterval           -4
      logMinPdelayReqInterval          -4
      announceReceiptTimeout            3
      syncReceiptTimeout                0
      delayAsymmetry                    0
      fault_reset_interval              4
      neighborPropDelayThresh           20000000
      masterOnly                        0
      G.8275.portDS.localPriority       128
      #
      # Runtime options
      #
      assume_two_step                   0
      logging_level                     6
      path_trace_enabled                0
      follow_up_info                    0
      hybrid_e2e                        0
      inhibit_multicast_service         0
      net_sync_monitor                  0
      tc_spanning_tree                  0
      tx_timestamp_timeout              10

8


      unicast_listen                    0
      unicast_master_table              0
      unicast_req_duration              3600
      use_syslog                        1
      verbose                           0
      summary_interval                 -4
      kernel_leap                       1
      check_fup_sync                    0
      #
      # Servo Options
      #
      pi_proportional_const             0.0
      pi_integral_const                 0.0
      pi_proportional_scale             0.0
      pi_proportional_exponent         -0.3
      pi_proportional_norm_max          0.7
      pi_integral_scale                 0.0
      pi_integral_exponent              0.4
      pi_integral_norm_max              0.3
      step_threshold                    2.0
      first_step_threshold              0.00002
      max_frequency                     900000000
      clock_servo                       pi
      sanity_freq_limit                 200000000
      ntpshm_segment                    0
      #
      # Transport options
      #
      transportSpecific                 0x0
      ptp_dst_mac                       01:1B:19:00:00:00
      p2p_dst_mac                       01:80:C2:00:00:0E
      udp_ttl                           1
      udp6_scope                        0x0E
      uds_address                       /var/run/ptp4l
      #
      # Default interface options
      #
      clock_type                        BC
      network_transport                 L2
      delay_mechanism                   E2E
      time_stamping                     hardware
      tsproc_mode                       filter
      delay_filter                      moving_median
      delay_filter_length               10
      egressLatency                     0
      ingressLatency                    0
      boundary_clock_jbod               0

9


      #
      # Clock description
      #
      productDescription                ;;
      revisionData                      ;;
      manufacturerIdentity              00:00:00
      userDescription                   ;
      timeSource                        0xA0
    phc2sysOpts:                        "-a -r -n 24"

10


    ptpSchedulingPolicy:                SCHED_OTHER

11


    ptpSchedulingPriority:              10

12


  ptpClockThreshold:

13


    holdOverTimeout:                    5
    maxOffsetThreshold:                 100
    minOffsetThreshold:                -100
  recommend:

14


  - profile: "<profile_name>"

15


    priority: 10

16


    match:

17


    - nodeLabel: "<node_label>"

18


      nodeName: "<node_name>"

19

Copy to Clipboard

Toggle word wrap

1: PtpConfig CR의 이름입니다.
2: 하나 이상의 profile 오브젝트의 배열을 지정합니다.
3: 프로파일 오브젝트를 고유하게 식별하는 프로파일 오브젝트의 이름을 지정합니다.
4: ptp4l 서비스에 대한 시스템 구성 옵션을 지정합니다. 옵션은 네트워크 인터페이스 이름과 서비스 구성 파일이 자동으로 추가되므로 네트워크 인터페이스 이름 -i <interface> 및 서비스 구성 파일 -f /etc/ptp4l.conf를 포함하지 않아야 합니다.
5: ptp4l을 경계 클록으로 시작하는 데 필요한 구성을 지정합니다. 예를 들어 ens1f0 은 그랜드 마스터 클록에서 동기화되고 ens1f3은 연결된 장치를 동기화합니다.
6: 동기화 클럭을 수신하는 인터페이스입니다.
7: 동기화 시계를 전송하는 인터페이스입니다.
8: Intel Coumbiaville 800 시리즈 NIC의 경우 tx_timestamp_timeout 을 50 으로 설정합니다.
9: Intel Columbiaville 800 시리즈 NIC의 경우 boundary_clock_jbod 가 0 으로 설정되어 있는지 확인합니다. Intel Fortville X710 시리즈 NIC의 경우 boundary_clock_jbod 가 1 로 설정되어 있는지 확인합니다.
10: phc2sys 서비스에 대한 시스템 구성 옵션을 지정합니다. 이 필드가 비어 있으면 PTP Operator에서 phc2sys 서비스를 시작하지 않습니다.
11: ptp4l 및 phc2sys 프로세스에 대한 스케줄링 정책입니다. 기본값은-4.8 _OTHER 입니다. Havana 스케줄링을 지원하는 시스템에서 Retain_ VRF를 사용합니다.
12: ptpSchedulingPolicy 가ECDHE _FIFO로 설정된 경우 ptp4l 및 phc2sys 프로세스의 FIFO 우선 순위를 설정하는 데 사용되는 1-65의 정수 값입니다. ptpSchedulingPriority 필드는 ptpSchedulingPolicy 가ECDHE _OTHER 로 설정된 경우 사용되지 않습니다.
13: 선택 사항: ptpClockThreshold 스탠자가 없으면 ptpClockThreshold 필드에 기본값이 사용됩니다. 스탠자는 기본 ptpClockThreshold 값을 표시합니다. ptpClockThreshold 값은 PTP 이벤트가 트리거되기 전에 PTP 마스터 클럭이 연결 해제된 후의 기간을 구성합니다. holdOverTimeout 은 PTP 마스터 클럭의 연결이 끊어지면 PTP 클럭 이벤트 상태가 FREERUN 로 변경되기 전 시간(초)입니다. maxOffsetThreshold 및 minOffsetThreshold 설정은 CLOCK_REALTIME (phc2sys) 또는 마스터 오프셋(ptp4l)의 값과 비교되는 나노초에 오프셋 값을 구성합니다. ptp4l 또는 phc2sys 오프셋 값이 이 범위를 벗어나는 경우 PTP 클럭 상태가 FREERUN 로 설정됩니다. 오프셋 값이 이 범위 내에 있으면 PTP 클럭 상태가 LOCKED 로 설정됩니다.
14: 프로필 을 노드에 적용하는 방법에 대한 규칙을 정의하는 하나 이상의 recommend 오브젝트 배열을 지정합니다.
15: profile 섹션에 정의된 profile 오브젝트 이름을 지정합니다.
16: 0에서 99 사이의 정수 값으로 priority를 지정합니다. 숫자가 클수록 우선순위가 낮으므로 우선순위 99는 우선순위 10보다 낮습니다. match 필드에 정의된 규칙에 따라 여러 프로필과 노드를 일치시킬 수 있는 경우 우선 순위가 높은 프로필이 해당 노드에 적용됩니다.
17: nodeLabel 또는 nodeName으로 일치 규칙을 지정합니다.
18: oc get nodes --show-labels 명령을 사용하여 노드 오브젝트에서 node.Labels 의 키로 nodeLabel 을 지정합니다. 예: node-role.kubernetes.io/worker.
19: oc get nodes 명령을 사용하여 노드 오브젝트에서 node.Name 으로 nodeName 을 지정합니다. 예: node-role.kubernetes.io/worker. 예: compute-0.example.com.

다음 명령을 실행하여 CR을 생성합니다.
```
oc create -f boundary-clock-ptp-config.yaml
```
```
$ oc create -f boundary-clock-ptp-config.yaml
```
Copy to Clipboard Toggle word wrap

검증

PtpConfig 프로필이 노드에 적용되었는지 확인합니다.

다음 명령을 실행하여 openshift-ptp 네임스페이스에서 Pod 목록을 가져옵니다.

oc get pods -n openshift-ptp -o wide

$ oc get pods -n openshift-ptp -o wide

Copy to Clipboard

Toggle word wrap

출력 예

NAME                            READY   STATUS    RESTARTS   AGE   IP               NODE
linuxptp-daemon-4xkbb           1/1     Running   0          43m   10.1.196.24      compute-0.example.com
linuxptp-daemon-tdspf           1/1     Running   0          43m   10.1.196.25      compute-1.example.com
ptp-operator-657bbb64c8-2f8sj   1/1     Running   0          43m   10.129.0.61      control-plane-1.example.com

NAME                            READY   STATUS    RESTARTS   AGE   IP               NODE
linuxptp-daemon-4xkbb           1/1     Running   0          43m   10.1.196.24      compute-0.example.com
linuxptp-daemon-tdspf           1/1     Running   0          43m   10.1.196.25      compute-1.example.com
ptp-operator-657bbb64c8-2f8sj   1/1     Running   0          43m   10.129.0.61      control-plane-1.example.com

Copy to Clipboard

Toggle word wrap

프로필이 올바른지 확인합니다. PtpConfig 프로필에 지정한 노드에 해당하는 linuxptp 데몬의 로그를 검사합니다. 다음 명령을 실행합니다.

oc logs linuxptp-daemon-4xkbb -n openshift-ptp -c linuxptp-daemon-container

$ oc logs linuxptp-daemon-4xkbb -n openshift-ptp -c linuxptp-daemon-container

Copy to Clipboard

Toggle word wrap

출력 예

I1115 09:41:17.117596 4143292 daemon.go:107] in applyNodePTPProfile
I1115 09:41:17.117604 4143292 daemon.go:109] updating NodePTPProfile to:
I1115 09:41:17.117607 4143292 daemon.go:110] ------------------------------------
I1115 09:41:17.117612 4143292 daemon.go:102] Profile Name: profile1
I1115 09:41:17.117616 4143292 daemon.go:102] Interface:
I1115 09:41:17.117620 4143292 daemon.go:102] Ptp4lOpts: -2 --summary_interval -4
I1115 09:41:17.117623 4143292 daemon.go:102] Phc2sysOpts: -a -r -n 24
I1115 09:41:17.117626 4143292 daemon.go:116] ------------------------------------

I1115 09:41:17.117596 4143292 daemon.go:107] in applyNodePTPProfile
I1115 09:41:17.117604 4143292 daemon.go:109] updating NodePTPProfile to:
I1115 09:41:17.117607 4143292 daemon.go:110] ------------------------------------
I1115 09:41:17.117612 4143292 daemon.go:102] Profile Name: profile1
I1115 09:41:17.117616 4143292 daemon.go:102] Interface:
I1115 09:41:17.117620 4143292 daemon.go:102] Ptp4lOpts: -2 --summary_interval -4
I1115 09:41:17.117623 4143292 daemon.go:102] Phc2sysOpts: -a -r -n 24
I1115 09:41:17.117626 4143292 daemon.go:116] ------------------------------------

Copy to Clipboard

Toggle word wrap

15.5.4. 듀얼 NIC 하드웨어의 경계 시계로 linuxptp 서비스 구성
링크 복사

중요

경계 시계로 구성된 이중 NIC가 있는 PTP(Precision Time Protocol) 하드웨어는 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

각 NIC에 대한 PtpConfig CR(사용자 정의 리소스) 오브젝트를 생성하여 이중 NIC 하드웨어의 경계 시계로 linuxptp 서비스(ptp4l,phc2sys)를 구성할 수 있습니다.

듀얼 NIC 하드웨어를 사용하면 각 NIC가 다운스트림 클럭을 공급하는 별도의 ptp4l 인스턴스와 함께 각 NIC를 동일한 업스트림 리더 시계에 연결할 수 있습니다.

사전 요구 사항

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

절차

각 NIC에 대해 하나씩 두 개의 개별 PtpConfig CR을 생성하고 각 CR의 기반으로 "Linuxptp 서비스 구성"의 참조 CR을 사용합니다. 예를 들어 다음과 같습니다.

phc2sysOpts 의 값을 지정하여 boundary-clock-ptp-config-nic1.yaml 을 생성합니다.

apiVersion: ptp.openshift.io/v1
kind: PtpConfig
metadata:
  name: boundary-clock-ptp-config-nic1
  namespace: openshift-ptp
spec:
  profile:
  - name: "profile1"
    ptp4lOpts: "-2 --summary_interval -4"
    ptp4lConf: | 
      [ens5f1]
      masterOnly 1
      [ens5f0]
      masterOnly 0
    ...
    phc2sysOpts: "-a -r -m -n 24 -N 8 -R 16"

apiVersion: ptp.openshift.io/v1
kind: PtpConfig
metadata:
  name: boundary-clock-ptp-config-nic1
  namespace: openshift-ptp
spec:
  profile:
  - name: "profile1"
    ptp4lOpts: "-2 --summary_interval -4"
    ptp4lConf: |

1


      [ens5f1]
      masterOnly 1
      [ens5f0]
      masterOnly 0
    ...
    phc2sysOpts: "-a -r -m -n 24 -N 8 -R 16"

2

Copy to Clipboard

Toggle word wrap

1: ptp4l 을 경계 시계로 시작하는 데 필요한 인터페이스를 지정합니다. 예를 들어 ens5f0 은 할머신 시계와 ens5f1 이 연결된 장치를 동기화합니다.
2: 필수 phc2sysOpts 값. -m 은 stdout 에 메시지를 출력합니다. linuxptp-daemon DaemonSet 은 로그를 구문 분석하고 Prometheus 지표를 생성합니다.

boundary-clock-ptp-config-nic2.yaml 을 생성하고 phc2syss 필드를 완전히 제거하여 두 번째 NIC에 대해 phc2sys 서비스를 비활성화합니다.

apiVersion: ptp.openshift.io/v1
kind: PtpConfig
metadata:
  name: boundary-clock-ptp-config-nic2
  namespace: openshift-ptp
spec:
  profile:
  - name: "profile2"
    ptp4lOpts: "-2 --summary_interval -4"
    ptp4lConf: | 
      [ens7f1]
      masterOnly 1
      [ens7f0]
      masterOnly 0
...

apiVersion: ptp.openshift.io/v1
kind: PtpConfig
metadata:
  name: boundary-clock-ptp-config-nic2
  namespace: openshift-ptp
spec:
  profile:
  - name: "profile2"
    ptp4lOpts: "-2 --summary_interval -4"
    ptp4lConf: |

1


      [ens7f1]
      masterOnly 1
      [ens7f0]
      masterOnly 0
...

Copy to Clipboard

Toggle word wrap

1: 두 번째 NIC에서 ptp4l 을 경계 시계로 시작하는 데 필요한 인터페이스를 지정합니다.

참고

두 번째 NIC에서 phc2sysOpts 필드를 두 번째 PtpConfig CR에서 완전히 제거하여 phc2sys 서비스를 비활성화해야 합니다.

다음 명령을 실행하여 듀얼 NIC PtpConfig CR을 생성합니다.
1. 첫 번째 NIC에 대해 PTP를 구성하는 CR을 생성합니다.
  $ oc create -f boundary-clock-ptp-config-nic1.yaml
  Copy to Clipboard Toggle word wrap
2. 두 번째 NIC에 대해 PTP를 구성하는 CR을 생성합니다.
  $ oc create -f boundary-clock-ptp-config-nic2.yaml
  Copy to Clipboard Toggle word wrap

검증

PTP Operator가 두 NIC에 PtpConfig CR을 적용했는지 확인합니다. 이중 NIC 하드웨어가 설치된 노드에 해당하는 linuxptp 데몬의 로그를 검사합니다. 예를 들어 다음 명령을 실행합니다.

oc logs linuxptp-daemon-cvgr6 -n openshift-ptp -c linuxptp-daemon-container

$ oc logs linuxptp-daemon-cvgr6 -n openshift-ptp -c linuxptp-daemon-container

Copy to Clipboard

Toggle word wrap

출력 예

ptp4l[80828.335]: [ptp4l.1.config] master offset          5 s2 freq   -5727 path delay       519
ptp4l[80828.343]: [ptp4l.0.config] master offset         -5 s2 freq  -10607 path delay       533
phc2sys[80828.390]: [ptp4l.0.config] CLOCK_REALTIME phc offset         1 s2 freq  -87239 delay    539

ptp4l[80828.335]: [ptp4l.1.config] master offset          5 s2 freq   -5727 path delay       519
ptp4l[80828.343]: [ptp4l.0.config] master offset         -5 s2 freq  -10607 path delay       533
phc2sys[80828.390]: [ptp4l.0.config] CLOCK_REALTIME phc offset         1 s2 freq  -87239 delay    539

Copy to Clipboard

Toggle word wrap

15.5.5. Intel coumbiaville E800 시리즈 NIC as PTP 일반 클럭 참조
링크 복사

다음 표에서는 Intel coumbiaville E800 시리즈 NIC를 일반 시계로 사용하기 위해 참조 PTP 설정을 변경해야 하는 변경 사항을 설명합니다. 클러스터에 적용하는 PtpConfig CR(사용자 정의 리소스)을 변경합니다.

Expand

표 15.1. Intel coumbiaville NIC에 권장되는 PTP 설정
PTP 구성	권장 설정
`phc2sysOpts`	`-a -r -m -n 24 -N 8 -R 16`
`tx_timestamp_timeout`	`50`
`boundary_clock_jbod`	`0`

참고

phc 2sysOpts의 경우-m 은 stdout 에 메시지를 출력합니다. linuxptp-daemon DaemonSet 은 로그를 구문 분석하고 Prometheus 지표를 생성합니다.

15.5.6. PTP 하드웨어에 대한 VRF 우선 순위 스케줄링 구성
링크 복사

대기 시간이 짧은 성능을 요구하는 통신 또는 기타 배포 구성에서 PTP 데몬 스레드는 나머지 인프라 구성 요소와 함께 제한된 CPU 풋프린트에서 실행됩니다. 기본적으로 PTP 스레드는 SCHED_OTHER 정책으로 실행됩니다. 높은 로드에서 이러한 스레드는 오류가 없는 작업에 필요한 스케줄링 대기 시간을 얻지 못할 수 있습니다.

잠재적인 스케줄링 대기 시간 오류가 발생하지 않도록 PTP Operator linuxptp 서비스를 구성하여 스레드를 schedule _ VRF 정책으로 실행할 수 있습니다. ppc _ VRF가 PtpConfig CR에 대해 설정된 경우 ptp4l 및 phc2sys 는 PtpConfig CR의 ptpSchedulingPriority 필드에 의해 설정된 우선 순위로 chrt 의 상위 컨테이너에서 실행됩니다.

참고

ptpSchedulingPolicy 설정은 선택 사항이며 대기 시간 오류가 발생하는 경우에만 필요합니다.

절차

PtpConfig CR 프로필을 편집합니다.
```
oc edit PtpConfig -n openshift-ptp
```
```
$ oc edit PtpConfig -n openshift-ptp
```
Copy to Clipboard Toggle word wrap

ptpSchedulingPolicy 및 ptpSchedulingPriority 필드를 변경합니다.

apiVersion: ptp.openshift.io/v1
kind: PtpConfig
metadata:
  name: <ptp_config_name>
  namespace: openshift-ptp
...
spec:
  profile:
  - name: "profile1"
...
    ptpSchedulingPolicy: SCHED_FIFO 
    ptpSchedulingPriority: 10

apiVersion: ptp.openshift.io/v1
kind: PtpConfig
metadata:
  name: <ptp_config_name>
  namespace: openshift-ptp
...
spec:
  profile:
  - name: "profile1"
...
    ptpSchedulingPolicy: SCHED_FIFO

1


    ptpSchedulingPriority: 10

2

Copy to Clipboard

Toggle word wrap

1: ptp4l 및 phc2sys 프로세스에 대한 스케줄링 정책입니다. Havana 스케줄링을 지원하는 시스템에서 Retain_ VRF를 사용합니다.
2: 필수 항목입니다. ptp4l 및 phc2sys 프로세스의 FIFO 우선 순위를 구성하는 데 사용되는 정수 값 1-65를 설정합니다.

저장 후 종료하여 PtpConfig CR에 변경 사항을 적용합니다.

검증

linuxptp-daemon Pod의 이름과 PtpConfig CR이 적용된 해당 노드를 가져옵니다.

oc get pods -n openshift-ptp -o wide

$ oc get pods -n openshift-ptp -o wide

Copy to Clipboard

Toggle word wrap

출력 예

NAME                            READY   STATUS    RESTARTS   AGE     IP            NODE
linuxptp-daemon-gmv2n           3/3     Running   0          1d17h   10.1.196.24   compute-0.example.com
linuxptp-daemon-lgm55           3/3     Running   0          1d17h   10.1.196.25   compute-1.example.com
ptp-operator-3r4dcvf7f4-zndk7   1/1     Running   0          1d7h    10.129.0.61   control-plane-1.example.com

NAME                            READY   STATUS    RESTARTS   AGE     IP            NODE
linuxptp-daemon-gmv2n           3/3     Running   0          1d17h   10.1.196.24   compute-0.example.com
linuxptp-daemon-lgm55           3/3     Running   0          1d17h   10.1.196.25   compute-1.example.com
ptp-operator-3r4dcvf7f4-zndk7   1/1     Running   0          1d7h    10.129.0.61   control-plane-1.example.com

Copy to Clipboard

Toggle word wrap

업데이트된 chrt first priority로 ptp4l 프로세스가 실행 중인지 확인합니다.

oc -n openshift-ptp logs linuxptp-daemon-lgm55 -c linuxptp-daemon-container|grep chrt

$ oc -n openshift-ptp logs linuxptp-daemon-lgm55 -c linuxptp-daemon-container|grep chrt

Copy to Clipboard

Toggle word wrap

출력 예

I1216 19:24:57.091872 1600715 daemon.go:285] /bin/chrt -f 65 /usr/sbin/ptp4l -f /var/run/ptp4l.0.config -2  --summary_interval -4 -m

I1216 19:24:57.091872 1600715 daemon.go:285] /bin/chrt -f 65 /usr/sbin/ptp4l -f /var/run/ptp4l.0.config -2  --summary_interval -4 -m

Copy to Clipboard

Toggle word wrap

15.6. 일반적인 PTP Operator 문제 해결
링크 복사

다음 단계를 수행하여 PTP Operator의 일반적인 문제를 해결합니다.

사전 요구 사항

OpenShift Container Platform CLI (oc)를 설치합니다.
cluster-admin 권한이 있는 사용자로 로그인합니다.
PTP를 지원하는 호스트가 있는 베어 메탈 클러스터에 PTP Operator를 설치합니다.

절차

구성된 노드를 위해 Operator 및 Operand가 클러스터에 성공적으로 배포되었는지 확인합니다.

oc get pods -n openshift-ptp -o wide

$ oc get pods -n openshift-ptp -o wide

Copy to Clipboard

Toggle word wrap

출력 예

NAME                            READY   STATUS    RESTARTS   AGE     IP            NODE
linuxptp-daemon-lmvgn           3/3     Running   0          4d17h   10.1.196.24   compute-0.example.com
linuxptp-daemon-qhfg7           3/3     Running   0          4d17h   10.1.196.25   compute-1.example.com
ptp-operator-6b8dcbf7f4-zndk7   1/1     Running   0          5d7h    10.129.0.61   control-plane-1.example.com

NAME                            READY   STATUS    RESTARTS   AGE     IP            NODE
linuxptp-daemon-lmvgn           3/3     Running   0          4d17h   10.1.196.24   compute-0.example.com
linuxptp-daemon-qhfg7           3/3     Running   0          4d17h   10.1.196.25   compute-1.example.com
ptp-operator-6b8dcbf7f4-zndk7   1/1     Running   0          5d7h    10.129.0.61   control-plane-1.example.com

Copy to Clipboard

Toggle word wrap

참고

PTP 빠른 이벤트 버스가 활성화되면 준비된 linuxptp-daemon Pod 수는 3/3가 됩니다. PTP 빠른 이벤트 버스가 활성화되지 않으면 2/2가 표시됩니다.

지원되는 하드웨어가 클러스터에 있는지 확인합니다.

oc -n openshift-ptp get nodeptpdevices.ptp.openshift.io

$ oc -n openshift-ptp get nodeptpdevices.ptp.openshift.io

Copy to Clipboard

Toggle word wrap

출력 예

NAME                                  AGE
control-plane-0.example.com           10d
control-plane-1.example.com           10d
compute-0.example.com                 10d
compute-1.example.com                 10d
compute-2.example.com                 10d

NAME                                  AGE
control-plane-0.example.com           10d
control-plane-1.example.com           10d
compute-0.example.com                 10d
compute-1.example.com                 10d
compute-2.example.com                 10d

Copy to Clipboard

Toggle word wrap

노드에 사용 가능한 PTP 네트워크 인터페이스를 확인합니다.

oc -n openshift-ptp get nodeptpdevices.ptp.openshift.io <node_name> -o yaml

$ oc -n openshift-ptp get nodeptpdevices.ptp.openshift.io <node_name> -o yaml

Copy to Clipboard

Toggle word wrap

다음과 같습니다.

<node_name>

쿼리할 노드를 지정합니다 (예: compute-0.example.com).

출력 예

apiVersion: ptp.openshift.io/v1
kind: NodePtpDevice
metadata:
  creationTimestamp: "2021-09-14T16:52:33Z"
  generation: 1
  name: compute-0.example.com
  namespace: openshift-ptp
  resourceVersion: "177400"
  uid: 30413db0-4d8d-46da-9bef-737bacd548fd
spec: {}
status:
  devices:
  - name: eno1
  - name: eno2
  - name: eno3
  - name: eno4
  - name: enp5s0f0
  - name: enp5s0f1

apiVersion: ptp.openshift.io/v1
kind: NodePtpDevice
metadata:
  creationTimestamp: "2021-09-14T16:52:33Z"
  generation: 1
  name: compute-0.example.com
  namespace: openshift-ptp
  resourceVersion: "177400"
  uid: 30413db0-4d8d-46da-9bef-737bacd548fd
spec: {}
status:
  devices:
  - name: eno1
  - name: eno2
  - name: eno3
  - name: eno4
  - name: enp5s0f0
  - name: enp5s0f1

Copy to Clipboard

Toggle word wrap

해당 노드의 linuxptp-daemon Pod에 액세스하여 PTP 인터페이스가 기본 클록에 성공적으로 동기화되었는지 확인합니다.

다음 명령을 실행하여 linuxptp-daemon Pod의 이름과 문제를 해결하려는 해당 노드를 가져옵니다.

oc get pods -n openshift-ptp -o wide

$ oc get pods -n openshift-ptp -o wide

Copy to Clipboard

Toggle word wrap

출력 예

NAME                            READY   STATUS    RESTARTS   AGE     IP            NODE
linuxptp-daemon-lmvgn           3/3     Running   0          4d17h   10.1.196.24   compute-0.example.com
linuxptp-daemon-qhfg7           3/3     Running   0          4d17h   10.1.196.25   compute-1.example.com
ptp-operator-6b8dcbf7f4-zndk7   1/1     Running   0          5d7h    10.129.0.61   control-plane-1.example.com

NAME                            READY   STATUS    RESTARTS   AGE     IP            NODE
linuxptp-daemon-lmvgn           3/3     Running   0          4d17h   10.1.196.24   compute-0.example.com
linuxptp-daemon-qhfg7           3/3     Running   0          4d17h   10.1.196.25   compute-1.example.com
ptp-operator-6b8dcbf7f4-zndk7   1/1     Running   0          5d7h    10.129.0.61   control-plane-1.example.com

Copy to Clipboard

Toggle word wrap

필수 linuxptp-daemon 컨테이너로의 원격 쉘:
```
oc rsh -n openshift-ptp -c linuxptp-daemon-container <linux_daemon_container>
```
```
$ oc rsh -n openshift-ptp -c linuxptp-daemon-container <linux_daemon_container>
```
Copy to Clipboard Toggle word wrap
다음과 같습니다.
<linux_daemon_container>
진단할 컨테이너입니다 (예: linuxptp-daemon-lmvgn).

linuxptp-daemon 컨테이너에 대한 원격 쉘 연결에서 PTP 관리 클라이언트(pmc) 툴을 사용하여 네트워크 인터페이스를 진단합니다. 다음 pmc 명령을 실행하여 PTP 장치의 동기화 상태를 확인합니다(예: ptp4l ).

pmc -u -f /var/run/ptp4l.0.config -b 0 'GET PORT_DATA_SET'

# pmc -u -f /var/run/ptp4l.0.config -b 0 'GET PORT_DATA_SET'

Copy to Clipboard

Toggle word wrap

노드가 기본 클록에 성공적으로 동기화되었을 때의 출력 예

sending: GET PORT_DATA_SET
    40a6b7.fffe.166ef0-1 seq 0 RESPONSE MANAGEMENT PORT_DATA_SET
        portIdentity            40a6b7.fffe.166ef0-1
        portState               SLAVE
        logMinDelayReqInterval  -4
        peerMeanPathDelay       0
        logAnnounceInterval     -3
        announceReceiptTimeout  3
        logSyncInterval         -4
        delayMechanism          1
        logMinPdelayReqInterval -4
        versionNumber           2

sending: GET PORT_DATA_SET
    40a6b7.fffe.166ef0-1 seq 0 RESPONSE MANAGEMENT PORT_DATA_SET
        portIdentity            40a6b7.fffe.166ef0-1
        portState               SLAVE
        logMinDelayReqInterval  -4
        peerMeanPathDelay       0
        logAnnounceInterval     -3
        announceReceiptTimeout  3
        logSyncInterval         -4
        delayMechanism          1
        logMinPdelayReqInterval -4
        versionNumber           2

Copy to Clipboard

Toggle word wrap

15.7. PTP 하드웨어 빠른 이벤트 알림 프레임워크
링크 복사

15.7.1. PTP 및 클럭 동기화 오류 이벤트 정보
링크 복사

가상 RAN과 같은 클라우드 네이티브 애플리케이션에서는 전체 네트워크의 작동에 중요한 하드웨어 타이밍 이벤트에 대한 알림에 액세스해야 합니다. 빠른 이벤트 알림은 임박한 실시간 PTP(Precision Time Protocol) 클럭 동기화 이벤트에 대한 조기 경고 신호입니다. PTP 클럭 동기화 오류는 낮은 대기 시간 애플리케이션의 성능과 안정성에 부정적인 영향을 줄 수 있습니다(예: 분산 장치(DU)에서 실행되는 vRAN 애플리케이션).

PTP 동기화 손실은 RAN 네트워크에 심각한 오류입니다. 노드에서 동기화가 손실된 경우 라디오가 종료될 수 있으며 네트워크 Over the Air (OTA) 트래픽이 무선 네트워크의 다른 노드로 이동될 수 있습니다. 클러스터 노드에서 PTP 클럭 동기화 상태를 DU에서 실행 중인 vRAN 애플리케이션에 통신할 수 있도록 함으로써 이벤트 알림이 워크로드 오류와 비교하여 완화됩니다.

동일한 DU 노드에서 실행되는 RAN 애플리케이션에서 이벤트 알림을 사용할 수 있습니다. 게시/서브스크립션 REST API는 이벤트 알림을 메시징 버스에 전달합니다. 게시/서브스크립션 메시징 또는 pub/sub 메시징은 주제에 게시된 모든 메시지가 해당 주제에 대한 모든 가입자에 의해 즉시 수신되는 서비스 통신 아키텍처에 대한 비동기식 서비스입니다.

빠른 이벤트 알림은 OpenShift Container Platform의 PTP Operator에서 모든 PTP 가능 네트워크 인터페이스에 대해 생성됩니다. 이 이벤트는 AMQP(Advanced Message Queuing Protocol) 메시지 버스를 통해 cloud-event-proxy 사이드카 컨테이너를 사용하여 사용할 수 있습니다. AMQP 메시지 버스는 AMQ Interconnect Operator에서 제공합니다.

참고

PTP 빠른 이벤트 알림은 PTP 일반 클럭 또는 PTP 경계 클럭을 사용하도록 구성된 네트워크 인터페이스에 사용할 수 있습니다.

15.7.2. PTP 빠른 이벤트 알림 프레임워크 정보
링크 복사

DCN(Distributed Unit) 애플리케이션을 PTP(Precision Time Protocol) 빠른 이벤트 알림을 PTP Operator 및 cloud-event-proxy 사이드카 컨테이너를 사용하여 생성한 빠른 이벤트 알림에 등록할 수 있습니다. ptpOperatorConfig CR(사용자 정의 리소스)에서 enableEventPublisher 필드를 true 로 설정하고 AMQPP(Advanced Messageauthorization Protocol) transportHost 주소를 지정하여 cloud-event-proxy 사이드카 컨테이너를 활성화합니다. PTP 빠른 이벤트는 AMQ Interconnect Operator가 제공하는 AMQP 이벤트 알림 버스를 사용합니다. AMQ Interconnect는 AMQP 지원 엔드포인트 간에 유연한 메시지 라우팅을 제공하는 메시징 라우터인 Red Hat AMQ의 구성 요소입니다. PTP 빠른 이벤트 프레임워크의 개요는 다음과 같습니다.

그림 15.1. PTP 빠른 이벤트 개요

cloud-event-proxy 사이드카 컨테이너는 기본 애플리케이션의 리소스를 사용하지 않고 대기 시간 없이 기본 vRAN 애플리케이션과 동일한 리소스에 액세스할 수 있습니다.

빠른 이벤트 알림 프레임워크는 통신에 REST API를 사용하며 O-RAN REST API 사양을 기반으로 합니다. 프레임워크는 게시자 및 구독자 애플리케이션 간의 통신을 처리하는 게시자, 구독자 및 AMQ 메시징 버스로 구성됩니다. cloud-event-proxy 사이드카는 DU 노드의 기본 DU 애플리케이션 컨테이너에 느슨하게 연결된 Pod에서 실행되는 유틸리티 컨테이너입니다. DU 애플리케이션을 게시된 PTP 이벤트에 등록할 수 있는 이벤트 게시 프레임워크를 제공합니다.

DU 애플리케이션은 사이드카 패턴에서 cloud-event-proxy 컨테이너를 실행하여 PTP 이벤트를 구독합니다. 다음 워크플로는 DU 애플리케이션에서 PTP 빠른 이벤트를 사용하는 방법을 설명합니다.

DU 애플리케이션에서 서브스크립션 요청: DU는 API 요청을 cloud-event-proxy 사이드카로 전송하여 PTP 이벤트 서브스크립션을 생성합니다. cloud-event-proxy 사이드카는 서브스크립션 리소스를 생성합니다.
cloud-event-proxy 사이드카는 서브스크립션을 생성: 이벤트 리소스는 cloud-event-proxy 사이드카에 의해 유지됩니다. cloud-event-proxy 사이드카 컨테이너는 ID 및 URL 위치가 있는 승인을 전송하여 저장된 서브스크립션 리소스에 액세스합니다. 사이드카는 서브스크립션에 지정된 리소스에 대한 AMQ 메시징 리스너 프로토콜을 생성합니다.
DU 애플리케이션에서 PTP 이벤트 알림 수신: cloud-event-proxy 사이드카 컨테이너가 리소스 한정자에 지정된 주소를 수신합니다. DU 이벤트 소비자는 메시지를 처리하고 서브스크립션에 지정된 반환 URL로 전달합니다.
cloud-event-proxy 사이드카는 PTP 이벤트를 검증하고 DU 애플리케이션에 게시: cloud-event-proxy 사이드카는 이벤트를 수신하고 클라우드 이벤트 오브젝트를 래핑하여 데이터를 검색하고 반환 URL을 가져와 이벤트를 DU 소비자 애플리케이션에 다시 게시합니다.
DU 애플리케이션은 PTP 이벤트 사용: DU 애플리케이션 이벤트 소비자가 PTP 이벤트를 수신하고 처리합니다.

15.7.3. AMQ 메시징 버스 설치
링크 복사

노드에서 게시자와 구독자 간에 PTP 빠른 이벤트 알림을 전달하려면 노드에서 로컬로 실행되도록 AMQ 메시징 버스를 설치하고 구성해야 합니다. 클러스터에서 사용할 AMQ Interconnect Operator를 설치하여 이 작업을 수행합니다.

사전 요구 사항

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

절차

AMQ Interconnect Operator를 자체 amq-interconnect 네임스페이스에 설치합니다. Add the Red Hat Integration - AMQ Interconnect Operator 를 참조하십시오.

검증

AMQ Interconnect Operator를 사용할 수 있고 필요한 Pod가 실행 중인지 확인합니다.

oc get pods -n amq-interconnect

$ oc get pods -n amq-interconnect

Copy to Clipboard

Toggle word wrap

출력 예

NAME                                    READY   STATUS    RESTARTS   AGE
amq-interconnect-645db76c76-k8ghs       1/1     Running   0          23h
interconnect-operator-5cb5fc7cc-4v7qm   1/1     Running   0          23h

NAME                                    READY   STATUS    RESTARTS   AGE
amq-interconnect-645db76c76-k8ghs       1/1     Running   0          23h
interconnect-operator-5cb5fc7cc-4v7qm   1/1     Running   0          23h

Copy to Clipboard

Toggle word wrap

필수 linuxptp-daemon PTP 이벤트 생산자 Pod가 openshift-ptp 네임스페이스에서 실행되고 있는지 확인합니다.

oc get pods -n openshift-ptp

$ oc get pods -n openshift-ptp

Copy to Clipboard

Toggle word wrap

출력 예

NAME                     READY   STATUS    RESTARTS       AGE
linuxptp-daemon-2t78p    3/3     Running   0              12h
linuxptp-daemon-k8n88    3/3     Running   0              12h

NAME                     READY   STATUS    RESTARTS       AGE
linuxptp-daemon-2t78p    3/3     Running   0              12h
linuxptp-daemon-k8n88    3/3     Running   0              12h

Copy to Clipboard

Toggle word wrap

15.7.4. PTP 빠른 이벤트 알림 게시자 구성
링크 복사

클러스터에서 네트워크 인터페이스에 PTP 빠른 이벤트 알림을 사용하려면 PTP Operator PtpOperatorConfig CR(사용자 정의 리소스)에서 빠른 이벤트 게시자를 활성화하고 생성한 PtpConfig CR에서 ptpClockThreshold 값을 구성해야 합니다.

사전 요구 사항

OpenShift Container Platform CLI (oc)를 설치합니다.
cluster-admin 권한이 있는 사용자로 로그인합니다.
PTP Operator 및 AMQ Interconnect Operator를 설치합니다.

절차

PTP 빠른 이벤트를 활성화하도록 기본 PTP Operator 구성을 수정합니다.

다음 YAML을 ptp-operatorconfig.yaml 파일에 저장합니다.

apiVersion: ptp.openshift.io/v1
kind: PtpOperatorConfig
metadata:
  name: default
  namespace: openshift-ptp
spec:
  daemonNodeSelector:
    node-role.kubernetes.io/worker: ""
  ptpEventConfig:
    enableEventPublisher: true 
    transportHost: amqp://<instance_name>.<namespace>.svc.cluster.local

apiVersion: ptp.openshift.io/v1
kind: PtpOperatorConfig
metadata:
  name: default
  namespace: openshift-ptp
spec:
  daemonNodeSelector:
    node-role.kubernetes.io/worker: ""
  ptpEventConfig:
    enableEventPublisher: true

1


    transportHost: amqp://<instance_name>.<namespace>.svc.cluster.local

2

Copy to Clipboard

Toggle word wrap

1: enableEventPublisher를 true로 설정하여 PTP 빠른 이벤트 알림을 활성화합니다.
2: < instance_name > 및 < namespace >가 AMQ Interconnect 라우터 인스턴스 이름과 네임스페이스(예: amqp://amq-interconnect.amq-interconnect.svc.cluster.local)에 해당하는 AMQ 라우터로 transportHost 를 설정합니다.

PtpOperatorConfig CR을 업데이트합니다.
```
oc apply -f ptp-operatorconfig.yaml
```
```
$ oc apply -f ptp-operatorconfig.yaml
```
Copy to Clipboard Toggle word wrap

PTP 지원 인터페이스에 대한 PtpConfig CR(사용자 정의 리소스)을 생성하고 ptpClockThreshold 및 ptp4lOpts 에 필요한 값을 설정합니다. 다음 YAML은 PtpConfig CR에 설정해야 하는 필수 값을 보여줍니다.
```
spec:
  profile:
  - name: "profile1"
    interface: "enp5s0f0"
    ptp4lOpts: "-2 -s --summary_interval -4" 
    phc2sysOpts: "-a -r -m -n 24 -N 8 -R 16" 
    ptp4lConf: "" 
  ptpClockThreshold: 
    holdOverTimeout: 5
    maxOffsetThreshold: 100
    minOffsetThreshold: -100
```
```
spec:
  profile:
  - name: "profile1"
    interface: "enp5s0f0"
    ptp4lOpts: "-2 -s --summary_interval -4" 
```
1
```
    phc2sysOpts: "-a -r -m -n 24 -N 8 -R 16" 
```
2
```
    ptp4lConf: "" 
```
3
```
  ptpClockThreshold: 
```
4
```
    holdOverTimeout: 5
    maxOffsetThreshold: 100
    minOffsetThreshold: -100
```
Copy to Clipboard Toggle word wrap
1
PTP 빠른 이벤트를 사용하려면 --summary_interval -4 를 추가합니다.
2
필수 phc2sysOpts 값. -m 은 stdout 에 메시지를 출력합니다. linuxptp-daemon DaemonSet 은 로그를 구문 분석하고 Prometheus 지표를 생성합니다.
3
기본 /etc/ptp4l.conf 파일을 대체할 구성이 포함된 문자열을 지정합니다. 기본 구성을 사용하려면 필드를 비워 둡니다.
4
선택 사항: ptpClockThreshold 가 없으면 기본값이 ptpClockThreshold 필드에 사용됩니다. 스탠자는 기본 ptpClockThreshold 값을 표시합니다. ptpClockThreshold 값은 PTP 이벤트가 트리거되기 전에 PTP 마스터 클럭이 연결 해제된 후의 기간을 구성합니다. holdOverTimeout 은 PTP 마스터 클럭의 연결이 끊어지면 PTP 클럭 이벤트 상태가 FREERUN 로 변경되기 전 시간(초)입니다. maxOffsetThreshold 및 minOffsetThreshold 설정은 CLOCK_REALTIME (phc2sys) 또는 마스터 오프셋(ptp4l)의 값과 비교되는 나노초에 오프셋 값을 구성합니다. ptp4l 또는 phc2sys 오프셋 값이 이 범위를 벗어나는 경우 PTP 클럭 상태가 FREERUN 로 설정됩니다. 오프셋 값이 이 범위 내에 있으면 PTP 클럭 상태가 LOCKED 로 설정됩니다.

15.7.5. DU 애플리케이션을 PTP 이벤트 REST API 참조에 구독
링크 복사

PTP 이벤트 알림을 REST API를 사용하여 DU(Distributed Unit) 애플리케이션을 상위 노드에 생성된 PTP 이벤트에 서브스크립션합니다.

리소스 주소 /cluster/node/<node_name>/ptp 을 사용하여 애플리케이션을 PTP 이벤트에 서브스크립션합니다. 여기서 < node_name >은 DU 애플리케이션을 실행하는 클러스터 노드입니다.

별도의 DU 애플리케이션 Pod에 cloud-event-consumer DU 애플리케이션 컨테이너 및 cloud-event-proxy 사이드카 컨테이너를 배포합니다. cloud-event-consumer DU 애플리케이션은 애플리케이션 Pod의 cloud-event-proxy 컨테이너에 가입합니다.

다음 API 끝점을 사용하여 DU 애플리케이션 Pod의 http://localhost:8089/api/ocloudNotifications/v1/ 에서 cloud-event- consumer DU 애플리케이션을 게시한 PTP 이벤트에 등록합니다.

/api/ocloudNotifications/v1/subscriptions
- POST: 새 서브스크립션을 생성합니다.
- GET: 서브스크립션 목록 검색합니다.
/api/ocloudNotifications/v1/subscriptions/<subscription_id>
- GET: 지정된 서브스크립션 ID에 대한 세부 정보를 반환합니다.
api/ocloudNotifications/v1/subscriptions/status/<subscription_id>
- PUT: 지정된 서브스크립션 ID에 대한 새 상태 ping 요청 생성
/api/ocloudNotifications/v1/health
- GET: ocloudNotifications API의 상태를 반환합니다.
api/ocloudNotifications/v1/publishers
- GET: 클러스터 노드에 대한 os-clock-sync-state,ptp-clock-class-change, lock-state 메시지 배열을 반환합니다.
/api/ocloudnotifications/v1/<resource_address>/CurrentState
- GET: os-clock-sync-state,ptp-clock-class-change, lock-state 이벤트 등 하나의 현재 상태를 반환합니다.

참고

9089 는 애플리케이션 Pod에 배포된 cloud-event-consumer 컨테이너의 기본 포트입니다. 필요에 따라 DU 애플리케이션에 대해 다른 포트를 구성할 수 있습니다.

15.7.5.1. api/ocloudNotifications/v1/subscriptions
링크 복사

HTTP 방법

GET api/ocloudNotifications/v1/subscriptions

설명

서브스크립션 목록을 반환합니다. 서브스크립션이 존재하는 경우 200 OK 상태 코드가 서브스크립션 목록과 함께 반환됩니다.

API 응답 예

[
 {
  "id": "75b1ad8f-c807-4c23-acf5-56f4b7ee3826",
  "endpointUri": "http://localhost:9089/event",
  "uriLocation": "http://localhost:8089/api/ocloudNotifications/v1/subscriptions/75b1ad8f-c807-4c23-acf5-56f4b7ee3826",
  "resource": "/cluster/node/compute-1.example.com/ptp"
 }
]

[
 {
  "id": "75b1ad8f-c807-4c23-acf5-56f4b7ee3826",
  "endpointUri": "http://localhost:9089/event",
  "uriLocation": "http://localhost:8089/api/ocloudNotifications/v1/subscriptions/75b1ad8f-c807-4c23-acf5-56f4b7ee3826",
  "resource": "/cluster/node/compute-1.example.com/ptp"
 }
]

Copy to Clipboard

Toggle word wrap

HTTP 방법

POST api/ocloudNotifications/v1/subscriptions

설명

새 서브스크립션을 생성합니다. 서브스크립션이 성공적으로 생성되었거나 이미 존재하는 경우 201 Created 상태 코드가 반환됩니다.

Expand

표 15.2. 쿼리 매개변수
매개변수	유형
subscription	data

페이로드 예

{
  "uriLocation": "http://localhost:8089/api/ocloudNotifications/v1/subscriptions",
  "resource": "/cluster/node/compute-1.example.com/ptp"
}

{
  "uriLocation": "http://localhost:8089/api/ocloudNotifications/v1/subscriptions",
  "resource": "/cluster/node/compute-1.example.com/ptp"
}

Copy to Clipboard

Toggle word wrap

15.7.5.2. api/ocloudNotifications/v1/subscriptions/
링크 복사

HTTP 방법

GET api/ocloudNotifications/v1/subscriptions/<subscription_id>

설명

ID <subscription _id>가 있는 서브스크립션의 세부 정보를 반환합니다.

Expand

표 15.3. 쿼리 매개변수
매개변수	유형
`<subscription_id>`	string

API 응답 예

{
  "id":"48210fb3-45be-4ce0-aa9b-41a0e58730ab",
  "endpointUri": "http://localhost:9089/event",
  "uriLocation":"http://localhost:8089/api/ocloudNotifications/v1/subscriptions/48210fb3-45be-4ce0-aa9b-41a0e58730ab",
  "resource":"/cluster/node/compute-1.example.com/ptp"
}

{
  "id":"48210fb3-45be-4ce0-aa9b-41a0e58730ab",
  "endpointUri": "http://localhost:9089/event",
  "uriLocation":"http://localhost:8089/api/ocloudNotifications/v1/subscriptions/48210fb3-45be-4ce0-aa9b-41a0e58730ab",
  "resource":"/cluster/node/compute-1.example.com/ptp"
}

Copy to Clipboard

Toggle word wrap

15.7.5.3. api/ocloudNotifications/v1/subscriptions/status/
링크 복사

HTTP 방법

PUT api/ocloudNotifications/v1/subscriptions/status/<subscription_id>

설명

ID <subscription _id>를 사용하여 서브스크립션에 대한 새 상태 ping 요청을 생성합니다. 서브스크립션이 있는 경우 상태 요청이 성공하고 202 Accepted 상태 코드가 반환됩니다.

Expand

표 15.4. 쿼리 매개변수
매개변수	유형
`<subscription_id>`	string

API 응답 예

{"status":"ping sent"}

{"status":"ping sent"}

Copy to Clipboard

Toggle word wrap

15.7.5.4. api/ocloudNotifications/v1/health/
링크 복사

HTTP 방법

GET api/ocloudNotifications/v1/health/

설명

ocloudNotifications REST API의 상태를 반환합니다.

API 응답 예

OK

OK

Copy to Clipboard

Toggle word wrap

15.7.5.5. api/ocloudNotifications/v1/publishers
링크 복사

HTTP 방법

GET api/ocloudNotifications/v1/publishers

설명

클러스터 노드의 os-clock-sync-state,ptp-clock-class-change 및 lock-state 세부 정보를 반환합니다. 시스템은 관련 장비 상태 변경이 있을 때 알림을 생성합니다.

OS-clock-sync-state 알림은 호스트 운영 체제 클럭 동기화 상태를 설명합니다. LOCKED 또는 free RUN 상태에 있을 수 있습니다.
PTP-clock-class-change 알림은 PTP 클럭 클래스의 현재 상태를 설명합니다.
lock-state 알림은 PTP 장비 잠금 상태의 현재 상태를 설명합니다. LOCKED,HOLDOVER 또는 free RUN 상태에 있을 수 있습니다.

API 응답 예

[
  {
    "id": "0fa415ae-a3cf-4299-876a-589438bacf75",
    "endpointUri": "http://localhost:9085/api/ocloudNotifications/v1/dummy",
    "uriLocation": "http://localhost:9085/api/ocloudNotifications/v1/publishers/0fa415ae-a3cf-4299-876a-589438bacf75",
    "resource": "/cluster/node/compute-1.example.com/sync/sync-status/os-clock-sync-state"
  },
  {
    "id": "28cd82df-8436-4f50-bbd9-7a9742828a71",
    "endpointUri": "http://localhost:9085/api/ocloudNotifications/v1/dummy",
    "uriLocation": "http://localhost:9085/api/ocloudNotifications/v1/publishers/28cd82df-8436-4f50-bbd9-7a9742828a71",
    "resource": "/cluster/node/compute-1.example.com/sync/ptp-status/ptp-clock-class-change"
  },
  {
    "id": "44aa480d-7347-48b0-a5b0-e0af01fa9677",
    "endpointUri": "http://localhost:9085/api/ocloudNotifications/v1/dummy",
    "uriLocation": "http://localhost:9085/api/ocloudNotifications/v1/publishers/44aa480d-7347-48b0-a5b0-e0af01fa9677",
    "resource": "/cluster/node/compute-1.example.com/sync/ptp-status/lock-state"
  }
]

[
  {
    "id": "0fa415ae-a3cf-4299-876a-589438bacf75",
    "endpointUri": "http://localhost:9085/api/ocloudNotifications/v1/dummy",
    "uriLocation": "http://localhost:9085/api/ocloudNotifications/v1/publishers/0fa415ae-a3cf-4299-876a-589438bacf75",
    "resource": "/cluster/node/compute-1.example.com/sync/sync-status/os-clock-sync-state"
  },
  {
    "id": "28cd82df-8436-4f50-bbd9-7a9742828a71",
    "endpointUri": "http://localhost:9085/api/ocloudNotifications/v1/dummy",
    "uriLocation": "http://localhost:9085/api/ocloudNotifications/v1/publishers/28cd82df-8436-4f50-bbd9-7a9742828a71",
    "resource": "/cluster/node/compute-1.example.com/sync/ptp-status/ptp-clock-class-change"
  },
  {
    "id": "44aa480d-7347-48b0-a5b0-e0af01fa9677",
    "endpointUri": "http://localhost:9085/api/ocloudNotifications/v1/dummy",
    "uriLocation": "http://localhost:9085/api/ocloudNotifications/v1/publishers/44aa480d-7347-48b0-a5b0-e0af01fa9677",
    "resource": "/cluster/node/compute-1.example.com/sync/ptp-status/lock-state"
  }
]

Copy to Clipboard

Toggle word wrap

cloud-event-proxy 컨테이너의 로그에서 os-clock-sync-state,ptp-clock-class-change 및 lock-state 이벤트를 찾을 수 있습니다. 예를 들어 다음과 같습니다.

oc logs -f linuxptp-daemon-cvgr6 -n openshift-ptp -c cloud-event-proxy

$ oc logs -f linuxptp-daemon-cvgr6 -n openshift-ptp -c cloud-event-proxy

Copy to Clipboard

Toggle word wrap

os-clock-sync-state 이벤트의 예

{
   "id":"c8a784d1-5f4a-4c16-9a81-a3b4313affe5",
   "type":"event.sync.sync-status.os-clock-sync-state-change",
   "source":"/cluster/compute-1.example.com/ptp/CLOCK_REALTIME",
   "dataContentType":"application/json",
   "time":"2022-05-06T15:31:23.906277159Z",
   "data":{
      "version":"v1",
      "values":[
         {
            "resource":"/sync/sync-status/os-clock-sync-state",
            "dataType":"notification",
            "valueType":"enumeration",
            "value":"LOCKED"
         },
         {
            "resource":"/sync/sync-status/os-clock-sync-state",
            "dataType":"metric",
            "valueType":"decimal64.3",
            "value":"-53"
         }
      ]
   }
}

{
   "id":"c8a784d1-5f4a-4c16-9a81-a3b4313affe5",
   "type":"event.sync.sync-status.os-clock-sync-state-change",
   "source":"/cluster/compute-1.example.com/ptp/CLOCK_REALTIME",
   "dataContentType":"application/json",
   "time":"2022-05-06T15:31:23.906277159Z",
   "data":{
      "version":"v1",
      "values":[
         {
            "resource":"/sync/sync-status/os-clock-sync-state",
            "dataType":"notification",
            "valueType":"enumeration",
            "value":"LOCKED"
         },
         {
            "resource":"/sync/sync-status/os-clock-sync-state",
            "dataType":"metric",
            "valueType":"decimal64.3",
            "value":"-53"
         }
      ]
   }
}

Copy to Clipboard

Toggle word wrap

ptp-clock-class-change 이벤트의 예

{
   "id":"69eddb52-1650-4e56-b325-86d44688d02b",
   "type":"event.sync.ptp-status.ptp-clock-class-change",
   "source":"/cluster/compute-1.example.com/ptp/ens2fx/master",
   "dataContentType":"application/json",
   "time":"2022-05-06T15:31:23.147100033Z",
   "data":{
      "version":"v1",
      "values":[
         {
            "resource":"/sync/ptp-status/ptp-clock-class-change",
            "dataType":"metric",
            "valueType":"decimal64.3",
            "value":"135"
         }
      ]
   }
}

{
   "id":"69eddb52-1650-4e56-b325-86d44688d02b",
   "type":"event.sync.ptp-status.ptp-clock-class-change",
   "source":"/cluster/compute-1.example.com/ptp/ens2fx/master",
   "dataContentType":"application/json",
   "time":"2022-05-06T15:31:23.147100033Z",
   "data":{
      "version":"v1",
      "values":[
         {
            "resource":"/sync/ptp-status/ptp-clock-class-change",
            "dataType":"metric",
            "valueType":"decimal64.3",
            "value":"135"
         }
      ]
   }
}

Copy to Clipboard

Toggle word wrap

lock-state 이벤트의 예

{
   "id":"305ec18b-1472-47b3-aadd-8f37933249a9",
   "type":"event.sync.ptp-status.ptp-state-change",
   "source":"/cluster/compute-1.example.com/ptp/ens2fx/master",
   "dataContentType":"application/json",
   "time":"2022-05-06T15:31:23.467684081Z",
   "data":{
      "version":"v1",
      "values":[
         {
            "resource":"/sync/ptp-status/lock-state",
            "dataType":"notification",
            "valueType":"enumeration",
            "value":"LOCKED"
         },
         {
            "resource":"/sync/ptp-status/lock-state",
            "dataType":"metric",
            "valueType":"decimal64.3",
            "value":"62"
         }
      ]
   }
}

{
   "id":"305ec18b-1472-47b3-aadd-8f37933249a9",
   "type":"event.sync.ptp-status.ptp-state-change",
   "source":"/cluster/compute-1.example.com/ptp/ens2fx/master",
   "dataContentType":"application/json",
   "time":"2022-05-06T15:31:23.467684081Z",
   "data":{
      "version":"v1",
      "values":[
         {
            "resource":"/sync/ptp-status/lock-state",
            "dataType":"notification",
            "valueType":"enumeration",
            "value":"LOCKED"
         },
         {
            "resource":"/sync/ptp-status/lock-state",
            "dataType":"metric",
            "valueType":"decimal64.3",
            "value":"62"
         }
      ]
   }
}

Copy to Clipboard

Toggle word wrap

15.7.5.6. /api/ocloudnotifications/v1//CurrentState
링크 복사

HTTP 방법

GET api/ocloudNotifications/v1/cluster/node/<node_name>/sync/ptp-status/lock-state/CurrentState

GET api/ocloudNotifications/v1/cluster/node/<node_name>/sync/sync-status/os-clock-sync-state/CurrentState

GET api/ocloudNotifications/v1/cluster/node/<node_name>/sync/ptp-status/ptp-clock-class-change/CurrentState

설명

클러스터 노드의 os-clock-sync-state,ptp-clock-class-change, lock-state 이벤트의 현재 상태를 반환하도록 CurrentState API 엔드포인트를 구성합니다.

OS-clock-sync-state 알림은 호스트 운영 체제 클럭 동기화 상태를 설명합니다. LOCKED 또는 free RUN 상태에 있을 수 있습니다.
PTP-clock-class-change 알림은 PTP 클럭 클래스의 현재 상태를 설명합니다.
lock-state 알림은 PTP 장비 잠금 상태의 현재 상태를 설명합니다. LOCKED,HOLDOVER 또는 free RUN 상태에 있을 수 있습니다.

Expand

표 15.5. 쿼리 매개변수
매개변수	유형
`<resource_address>`	string

lock-state API 응답 예

{
  "id": "c1ac3aa5-1195-4786-84f8-da0ea4462921",
  "type": "event.sync.ptp-status.ptp-state-change",
  "source": "/cluster/node/compute-1.example.com/sync/ptp-status/lock-state",
  "dataContentType": "application/json",
  "time": "2023-01-10T02:41:57.094981478Z",
  "data": {
    "version": "v1",
    "values": [
      {
        "resource": "/cluster/node/compute-1.example.com/ens5fx/master",
        "dataType": "notification",
        "valueType": "enumeration",
        "value": "LOCKED"
      },
      {
        "resource": "/cluster/node/compute-1.example.com/ens5fx/master",
        "dataType": "metric",
        "valueType": "decimal64.3",
        "value": "29"
      }
    ]
  }
}

{
  "id": "c1ac3aa5-1195-4786-84f8-da0ea4462921",
  "type": "event.sync.ptp-status.ptp-state-change",
  "source": "/cluster/node/compute-1.example.com/sync/ptp-status/lock-state",
  "dataContentType": "application/json",
  "time": "2023-01-10T02:41:57.094981478Z",
  "data": {
    "version": "v1",
    "values": [
      {
        "resource": "/cluster/node/compute-1.example.com/ens5fx/master",
        "dataType": "notification",
        "valueType": "enumeration",
        "value": "LOCKED"
      },
      {
        "resource": "/cluster/node/compute-1.example.com/ens5fx/master",
        "dataType": "metric",
        "valueType": "decimal64.3",
        "value": "29"
      }
    ]
  }
}

Copy to Clipboard

Toggle word wrap

os-clock-sync-state API 응답 예

{
  "specversion": "0.3",
  "id": "4f51fe99-feaa-4e66-9112-66c5c9b9afcb",
  "source": "/cluster/node/compute-1.example.com/sync/sync-status/os-clock-sync-state",
  "type": "event.sync.sync-status.os-clock-sync-state-change",
  "subject": "/cluster/node/compute-1.example.com/sync/sync-status/os-clock-sync-state",
  "datacontenttype": "application/json",
  "time": "2022-11-29T17:44:22.202Z",
  "data": {
    "version": "v1",
    "values": [
      {
        "resource": "/cluster/node/compute-1.example.com/CLOCK_REALTIME",
        "dataType": "notification",
        "valueType": "enumeration",
        "value": "LOCKED"
      },
      {
        "resource": "/cluster/node/compute-1.example.com/CLOCK_REALTIME",
        "dataType": "metric",
        "valueType": "decimal64.3",
        "value": "27"
      }
    ]
  }
}

{
  "specversion": "0.3",
  "id": "4f51fe99-feaa-4e66-9112-66c5c9b9afcb",
  "source": "/cluster/node/compute-1.example.com/sync/sync-status/os-clock-sync-state",
  "type": "event.sync.sync-status.os-clock-sync-state-change",
  "subject": "/cluster/node/compute-1.example.com/sync/sync-status/os-clock-sync-state",
  "datacontenttype": "application/json",
  "time": "2022-11-29T17:44:22.202Z",
  "data": {
    "version": "v1",
    "values": [
      {
        "resource": "/cluster/node/compute-1.example.com/CLOCK_REALTIME",
        "dataType": "notification",
        "valueType": "enumeration",
        "value": "LOCKED"
      },
      {
        "resource": "/cluster/node/compute-1.example.com/CLOCK_REALTIME",
        "dataType": "metric",
        "valueType": "decimal64.3",
        "value": "27"
      }
    ]
  }
}

Copy to Clipboard

Toggle word wrap

ptp-clock-class-change API 응답 예

{
  "id": "064c9e67-5ad4-4afb-98ff-189c6aa9c205",
  "type": "event.sync.ptp-status.ptp-clock-class-change",
  "source": "/cluster/node/compute-1.example.com/sync/ptp-status/ptp-clock-class-change",
  "dataContentType": "application/json",
  "time": "2023-01-10T02:41:56.785673989Z",
  "data": {
    "version": "v1",
    "values": [
      {
        "resource": "/cluster/node/compute-1.example.com/ens5fx/master",
        "dataType": "metric",
        "valueType": "decimal64.3",
        "value": "165"
      }
    ]
  }
}

{
  "id": "064c9e67-5ad4-4afb-98ff-189c6aa9c205",
  "type": "event.sync.ptp-status.ptp-clock-class-change",
  "source": "/cluster/node/compute-1.example.com/sync/ptp-status/ptp-clock-class-change",
  "dataContentType": "application/json",
  "time": "2023-01-10T02:41:56.785673989Z",
  "data": {
    "version": "v1",
    "values": [
      {
        "resource": "/cluster/node/compute-1.example.com/ens5fx/master",
        "dataType": "metric",
        "valueType": "decimal64.3",
        "value": "165"
      }
    ]
  }
}

Copy to Clipboard

Toggle word wrap

15.7.6. CLI를 사용하여 PTP 빠른 이벤트 메트릭 모니터링
링크 복사

oc CLI를 사용하여 cloud-event-proxy 컨테이너에서 직접 빠른 이벤트 버스 메트릭을 모니터링할 수 있습니다.

참고

OpenShift Container Platform 웹 콘솔에서 PTP 빠른 이벤트 알림 메트릭도 사용할 수 있습니다.

사전 요구 사항

OpenShift Container Platform CLI (oc)를 설치합니다.
cluster-admin 권한이 있는 사용자로 로그인합니다.
PTP Operator를 설치하고 구성합니다.

절차

활성 linuxptp-daemon Pod 목록을 가져옵니다.

oc get pods -n openshift-ptp

$ oc get pods -n openshift-ptp

Copy to Clipboard

Toggle word wrap

출력 예

NAME                    READY   STATUS    RESTARTS   AGE
linuxptp-daemon-2t78p   3/3     Running   0          8h
linuxptp-daemon-k8n88   3/3     Running   0          8h

NAME                    READY   STATUS    RESTARTS   AGE
linuxptp-daemon-2t78p   3/3     Running   0          8h
linuxptp-daemon-k8n88   3/3     Running   0          8h

Copy to Clipboard

Toggle word wrap

다음 명령을 실행하여 필요한 cloud-event-proxy 컨테이너의 메트릭에 액세스합니다.

oc exec -it <linuxptp-daemon> -n openshift-ptp -c cloud-event-proxy -- curl 127.0.0.1:9091/metrics

$ oc exec -it <linuxptp-daemon> -n openshift-ptp -c cloud-event-proxy -- curl 127.0.0.1:9091/metrics

Copy to Clipboard

Toggle word wrap

다음과 같습니다.

<linuxptp-daemon>

쿼리할 Pod를 지정합니다(예: linuxptp-daemon-2t78p ).

출력 예

# HELP cne_amqp_events_published Metric to get number of events published by the transport
# TYPE cne_amqp_events_published gauge
cne_amqp_events_published{address="/cluster/node/compute-1.example.com/ptp/status",status="success"} 1041
# HELP cne_amqp_events_received Metric to get number of events received  by the transport
# TYPE cne_amqp_events_received gauge
cne_amqp_events_received{address="/cluster/node/compute-1.example.com/ptp",status="success"} 1019
# HELP cne_amqp_receiver Metric to get number of receiver created
# TYPE cne_amqp_receiver gauge
cne_amqp_receiver{address="/cluster/node/mock",status="active"} 1
cne_amqp_receiver{address="/cluster/node/compute-1.example.com/ptp",status="active"} 1
cne_amqp_receiver{address="/cluster/node/compute-1.example.com/redfish/event",status="active"}
...

# HELP cne_amqp_events_published Metric to get number of events published by the transport
# TYPE cne_amqp_events_published gauge
cne_amqp_events_published{address="/cluster/node/compute-1.example.com/ptp/status",status="success"} 1041
# HELP cne_amqp_events_received Metric to get number of events received  by the transport
# TYPE cne_amqp_events_received gauge
cne_amqp_events_received{address="/cluster/node/compute-1.example.com/ptp",status="success"} 1019
# HELP cne_amqp_receiver Metric to get number of receiver created
# TYPE cne_amqp_receiver gauge
cne_amqp_receiver{address="/cluster/node/mock",status="active"} 1
cne_amqp_receiver{address="/cluster/node/compute-1.example.com/ptp",status="active"} 1
cne_amqp_receiver{address="/cluster/node/compute-1.example.com/redfish/event",status="active"}
...

Copy to Clipboard

Toggle word wrap

15.7.7. 웹 콘솔에서 PTP 빠른 이벤트 메트릭 모니터링
링크 복사

사전 구성 및 자체 업데이트 Prometheus 모니터링 스택을 사용하여 OpenShift Container Platform 웹 콘솔에서 PTP 빠른 이벤트 메트릭을 모니터링할 수 있습니다.

사전 요구 사항

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

절차

다음 명령을 입력하여 cloud-event-proxy 사이드카 컨테이너에서 사용 가능한 PTP 메트릭 목록을 반환합니다.
```
oc exec -it <linuxptp_daemon_pod> -n openshift-ptp -c cloud-event-proxy -- curl 127.0.0.1:9091/metrics
```
```
$ oc exec -it <linuxptp_daemon_pod> -n openshift-ptp -c cloud-event-proxy -- curl 127.0.0.1:9091/metrics
```
Copy to Clipboard Toggle word wrap
다음과 같습니다.
<linuxptp_daemon_pod>
쿼리할 Pod를 지정합니다(예: linuxptp-daemon-2t78p ).
반환된 메트릭 목록에서 쿼리할 PTP 메트릭의 이름을 복사합니다(예: cne_amqp_events_received ).
OpenShift Container Platform 웹 콘솔에서 모니터링 → 메트릭을 클릭합니다.
PTP 메트릭을 표현식 필드에 붙여넣고 쿼리 실행을 클릭합니다.

16장. 외부 DNS Operator
링크 복사

16.1. OpenShift Container Platform의 외부 DNS Operator
링크 복사

외부 DNS Operator는 ExternalDNS 를 배포 및 관리하여 외부 DNS 공급자에서 OpenShift Container Platform으로의 서비스 및 경로에 대한 이름 확인을 제공합니다.

16.1.1. 외부 DNS Operator
링크 복사

외부 DNS Operator는 olm.openshift.io API 그룹에서 외부 DNS API를 구현합니다. 외부 DNS Operator는 배포 리소스를 사용하여 ExternalDNS 를 배포합니다. ExternalDNS 배포는 클러스터의 서비스 및 경로와 같은 리소스를 감시하고 외부 DNS 공급자를 업데이트합니다.

절차

OperatorHub에서 필요에 따라 ExternalDNS Operator를 배포할 수 있으므로 Subscription 오브젝트가 생성됩니다.

설치 계획의 이름을 확인합니다.

oc -n external-dns-operator get sub external-dns-operator -o yaml | yq '.status.installplan.name'

$ oc -n external-dns-operator get sub external-dns-operator -o yaml | yq '.status.installplan.name'

Copy to Clipboard

Toggle word wrap

출력 예

install-zcvlr

install-zcvlr

Copy to Clipboard

Toggle word wrap

설치 계획의 상태를 확인하면 설치 계획의 상태가 완료 여야 합니다.
```
oc -n external-dns-operator get ip <install_plan_name> -o yaml | yq .status.phase'
```
```
$ oc -n external-dns-operator get ip <install_plan_name> -o yaml | yq .status.phase'
```
Copy to Clipboard Toggle word wrap
출력 예
```
Complete
```
```
Complete
```
Copy to Clipboard Toggle word wrap

oc get 명령을 사용하여 배포 상태를 확인합니다.

oc get -n external-dns-operator deployment/external-dns-operator

$ oc get -n external-dns-operator deployment/external-dns-operator

Copy to Clipboard

Toggle word wrap

출력 예

NAME                    READY     UP-TO-DATE   AVAILABLE   AGE
external-dns-operator   1/1       1            1           23h

NAME                    READY     UP-TO-DATE   AVAILABLE   AGE
external-dns-operator   1/1       1            1           23h

Copy to Clipboard

Toggle word wrap

16.1.2. 외부 DNS Operator 로그
링크 복사

oc logs 명령을 사용하여 외부 DNS Operator 로그를 볼 수 있습니다.

절차

외부 DNS Operator의 로그를 확인합니다.

oc logs -n external-dns-operator deployment/external-dns-operator -c external-dns-operator

$ oc logs -n external-dns-operator deployment/external-dns-operator -c external-dns-operator

Copy to Clipboard

Toggle word wrap

16.1.2.1. 외부 DNS Operator 도메인 이름 제한
링크 복사

외부 DNS Operator는 새 형식을 따르고 TXT 레코드의 접두사를 추가하는 TXT 레지스트리를 사용합니다. 이렇게 하면 TXT 레코드의 도메인 이름의 최대 길이가 줄어듭니다. 해당 TXT 레코드 없이는 DNS 레코드를 존재할 수 없으므로 DNS 레코드의 도메인 이름은 TXT 레코드와 동일한 제한을 따라야 합니다. 예를 들어 DNS 레코드는 < domain-name-from-source >이며 TXT 레코드는 external-dns-< records-type>-<domain-name-from-source >입니다.

외부 DNS Operator에서 생성한 DNS 레코드의 도메인 이름에는 다음과 같은 제한 사항이 있습니다.

Expand

레코드 유형	문자 수
CNAME	44
AzureDNS의 와일드카드 CNAME 레코드	42
A	48
AzureDNS의 와일드카드 A 레코드	46

외부 DNS에서 생성한 도메인 이름이 도메인 이름 제한을 초과하면 외부 DNS 인스턴스에서 다음 오류가 발생합니다.

oc -n external-dns-operator logs external-dns-aws-7ddbd9c7f8-2jqjh

$ oc -n external-dns-operator logs external-dns-aws-7ddbd9c7f8-2jqjh

1

Copy to Clipboard

Toggle word wrap

1: external-dns-aws-7ddbd9c7f8-2jqjh 매개변수는 외부 DNS Pod의 이름을 지정합니다.

출력 예

time="2022-09-02T08:53:57Z" level=info msg="Desired change: CREATE external-dns-cname-hello-openshift-aaaaaaaaaa-bbbbbbbbbb-ccccccc.test.example.io TXT [Id: /hostedzone/Z06988883Q0H0RL6UMXXX]"
time="2022-09-02T08:53:57Z" level=info msg="Desired change: CREATE external-dns-hello-openshift-aaaaaaaaaa-bbbbbbbbbb-ccccccc.test.example.io TXT [Id: /hostedzone/Z06988883Q0H0RL6UMXXX]"
time="2022-09-02T08:53:57Z" level=info msg="Desired change: CREATE hello-openshift-aaaaaaaaaa-bbbbbbbbbb-ccccccc.test.example.io A [Id: /hostedzone/Z06988883Q0H0RL6UMXXX]"
time="2022-09-02T08:53:57Z" level=error msg="Failure in zone test.example.io. [Id: /hostedzone/Z06988883Q0H0RL6UMXXX]"
time="2022-09-02T08:53:57Z" level=error msg="InvalidChangeBatch: [FATAL problem: DomainLabelTooLong (Domain label is too long) encountered with 'external-dns-a-hello-openshift-aaaaaaaaaa-bbbbbbbbbb-ccccccc']\n\tstatus code: 400, request id: e54dfd5a-06c6-47b0-bcb9-a4f7c3a4e0c6"

time="2022-09-02T08:53:57Z" level=info msg="Desired change: CREATE external-dns-cname-hello-openshift-aaaaaaaaaa-bbbbbbbbbb-ccccccc.test.example.io TXT [Id: /hostedzone/Z06988883Q0H0RL6UMXXX]"
time="2022-09-02T08:53:57Z" level=info msg="Desired change: CREATE external-dns-hello-openshift-aaaaaaaaaa-bbbbbbbbbb-ccccccc.test.example.io TXT [Id: /hostedzone/Z06988883Q0H0RL6UMXXX]"
time="2022-09-02T08:53:57Z" level=info msg="Desired change: CREATE hello-openshift-aaaaaaaaaa-bbbbbbbbbb-ccccccc.test.example.io A [Id: /hostedzone/Z06988883Q0H0RL6UMXXX]"
time="2022-09-02T08:53:57Z" level=error msg="Failure in zone test.example.io. [Id: /hostedzone/Z06988883Q0H0RL6UMXXX]"
time="2022-09-02T08:53:57Z" level=error msg="InvalidChangeBatch: [FATAL problem: DomainLabelTooLong (Domain label is too long) encountered with 'external-dns-a-hello-openshift-aaaaaaaaaa-bbbbbbbbbb-ccccccc']\n\tstatus code: 400, request id: e54dfd5a-06c6-47b0-bcb9-a4f7c3a4e0c6"

Copy to Clipboard

Toggle word wrap

16.2. 클라우드 공급자에 외부 DNS Operator 설치
링크 복사

AWS, Azure 및 GCP와 같은 클라우드 공급자에 외부 DNS Operator를 설치할 수 있습니다.

16.2.1. 외부 DNS Operator 설치
링크 복사

OpenShift Container Platform OperatorHub를 사용하여 외부 DNS Operator를 설치할 수 있습니다.

절차

OpenShift Container Platform 웹 콘솔에서 Operators → OperatorHub 를 클릭합니다.
외부 DNS Operator 를 클릭합니다. 키워드로 텍스트 상자 또는 필터 목록을 사용하여 Operator 목록에서 외부 DNS Operator를 검색할 수 있습니다.
external-dns-operator 네임스페이스를 선택합니다.
External DNS Operator 페이지에서 설치를 클릭합니다.
Operator 설치 페이지에서 다음 옵션을 선택했는지 확인합니다.
1. 채널을 stable-v1.0 으로 업데이트합니다.
2. 클러스터의 특정 이름으로 설치 모드입니다.
3. external-dns-operator 로 설치된 네임스페이스입니다. external-dns-operator 네임스페이스가 없는 경우 Operator 설치 중에 생성됩니다.
4. 승인 전략을 자동 또는 수동으로 선택합니다. 승인 전략은 기본적으로 자동으로 설정됩니다.
5. 설치를 클릭합니다.

자동 업데이트를 선택하면 OLM(Operator Lifecycle Manager)에서 개입 없이 실행 중인 Operator 인스턴스를 자동으로 업그레이드합니다.

수동 업데이트를 선택하면 OLM에서 업데이트 요청을 생성합니다. 클러스터 관리자는 Operator를 새 버전으로 업데이트하려면 OLM 업데이트 요청을 수동으로 승인해야 합니다.

검증

외부 DNS Operator가 설치된 Operator 대시보드에서 상태가 Succeeded 로 표시되는지 확인합니다.

16.3. 외부 DNS Operator 구성 매개변수
링크 복사

외부 DNS Operator에는 다음 구성 매개변수가 포함됩니다.

16.3.1. 외부 DNS Operator 구성 매개변수
링크 복사

외부 DNS Operator에는 다음 구성 매개변수가 포함됩니다.

Expand

매개변수	설명
`spec`	클라우드 공급자의 유형을 활성화합니다. `spec: provider: type: AWS` 1 `aws: credentials: name: aws-access-key` 2 Copy to Clipboard Toggle word wrap 1 AWS, GCP, Azure와 같은 사용 가능한 옵션을 정의합니다. 2 클라우드 공급자에 대한 인증 정보가 포함된 `시크릿` 이름을 정의합니다.
`영역`	해당 도메인에서 DNS 영역을 지정할 수 있습니다. 영역을 지정하지 않으면 `ExternalDNS` 는 클라우드 공급자 계정에 있는 모든 영역을 검색합니다. `zones: - "myzoneid"` 1 Copy to Clipboard Toggle word wrap 1 DNS 영역의 ID를 지정합니다.
`domain`	해당 도메인에서 AWS 영역을 지정할 수 있습니다. 도메인을 지정하지 않으면 `ExternalDNS` 에서 클라우드 공급자 계정에 있는 모든 영역을 검색합니다. `domains: - filterType: Include` 1 `matchType: Exact` 2 `name: "myzonedomain1.com"` 3 `- filterType: Include matchType: Pattern` 4 `pattern: ".*\\.otherzonedomain\\.com"` 5 Copy to Clipboard Toggle word wrap 1 지정된 도메인을 포함하도록 `ExternalDNS` 에 지시합니다. 2 `ExtrnalDNS` 에서 도메인 일치가 정규 표현식과 일치하지 않는 것과 정확히 일치해야 함을 지시합니다. 3 `ExternalDNS` 필터를 사용하는 정확한 도메인 이름을 정의합니다. 4 `ExternalDNS` 에서 `regex-domain-filter` 플래그를 설정합니다. Regex 필터를 사용하여 가능한 도메인을 제한할 수 있습니다. 5 대상 영역의 도메인을 필터링하기 위해 `ExternalDNS` 에서 사용할 regex 패턴을 정의합니다.
`소스`	DNS 레코드, `서비스` 또는 `경로` 의 소스를 지정할 수 있습니다. `source:` 1 `type: Service` 2 `service: serviceType:` 3 `- LoadBalancer - ClusterIP labelFilter:` 4 `matchLabels: external-dns.mydomain.org/publish: "yes" hostnameAnnotation: "Allow"` 5 `fqdnTemplate: - "{{.Name}}.myzonedomain.com"` 6 Copy to Clipboard Toggle word wrap 1 DNS 레코드 소스에 대한 설정을 정의합니다. 2 `ExternalDNS` 는 dns 레코드를 생성하는 소스로 `서비스` 유형을 사용합니다. 3 `ExternalDNS` 에서 `service-type-filter` 플래그를 설정합니다. `serviceType` 에는 다음 필드가 포함되어 있습니다. `default`: `LoadBalancer` `예상`:`ClusterIP` `NodePort` `LoadBalancer` `ExternalName` 4 컨트롤러에서 레이블 필터와 일치하는 리소스만 고려하도록 합니다. 5 `hostnameAnnotation` 의 기본값은 `Ignore` that external `DNS` 가 `fqdnTemplates` 필드에 지정된 템플릿을 사용하여 DNS 레코드를 생성하도록 지시하는 Ignore입니다. 값이 `Allow` the DNS records get generated based on the value specified in the `external-dns.alpha.kubernetes.io/hostname` 주석에 지정된 값을 기반으로 DNS 레코드가 생성될 수 있습니다. 6 외부 DNS Operator는 문자열을 사용하여 호스트 이름을 정의하지 않는 소스에서 DNS 이름을 생성하거나 페이크 소스와 함께 사용할 때 호스트 이름 접미사를 추가합니다. `source: type: OpenShiftRoute` 1 `openshiftRouteOptions: routerName: default` 2 `labelFilter: matchLabels: external-dns.mydomain.org/publish: "yes"` Copy to Clipboard Toggle word wrap 1 externalDNS는 dns 레코드를 생성하는 데 유형 `경로` 를 소스로 사용합니다. 2 소스가 `OpenShiftRoute` 인 경우 Ingress 컨트롤러 이름을 전달할 수 있습니다. `ExternalDNS` 는 Ingress 컨트롤러의 정식 이름을 CNAME 레코드의 대상으로 사용합니다.

16.4. AWS에서 DNS 레코드 생성
링크 복사

외부 DNS Operator를 사용하여 AWS 및 AWS GovCloud에서 DNS 레코드를 생성할 수 있습니다.

16.4.1. Red Hat External DNS Operator를 사용하여 AWS의 퍼블릭 호스팅 영역에 DNS 레코드 생성
링크 복사

Red Hat External DNS Operator를 사용하여 AWS의 퍼블릭 호스팅 영역에서 DNS 레코드를 생성할 수 있습니다. 동일한 지침을 사용하여 AWS GovCloud의 호스팅 영역에 DNS 레코드를 생성할 수 있습니다.

절차

사용자를 확인합니다. 사용자는 kube-system 네임스페이스에 액세스할 수 있어야 합니다. 인증 정보가 없는 경우 kube-system 네임스페이스에서 인증 정보를 가져와 클라우드 공급자 클라이언트를 사용할 수 있습니다.
```
oc whoami
```
```
$ oc whoami
```
Copy to Clipboard Toggle word wrap
출력 예
```
system:admin
```
```
system:admin
```
Copy to Clipboard Toggle word wrap

kube-system 네임스페이스에 있는 aws-creds 시크릿에서 값을 가져옵니다.

export AWS_ACCESS_KEY_ID=$(oc get secrets aws-creds -n kube-system  --template={{.data.aws_access_key_id}} | base64 -d)
export AWS_SECRET_ACCESS_KEY=$(oc get secrets aws-creds -n kube-system  --template={{.data.aws_secret_access_key}} | base64 -d)

$ export AWS_ACCESS_KEY_ID=$(oc get secrets aws-creds -n kube-system  --template={{.data.aws_access_key_id}} | base64 -d)
$ export AWS_SECRET_ACCESS_KEY=$(oc get secrets aws-creds -n kube-system  --template={{.data.aws_secret_access_key}} | base64 -d)

Copy to Clipboard

Toggle word wrap

경로를 가져와 도메인을 확인합니다.

oc get routes --all-namespaces | grep console

$ oc get routes --all-namespaces | grep console

Copy to Clipboard

Toggle word wrap

출력 예

openshift-console          console             console-openshift-console.apps.testextdnsoperator.apacshift.support                       console             https   reencrypt/Redirect     None
openshift-console          downloads           downloads-openshift-console.apps.testextdnsoperator.apacshift.support                     downloads           http    edge/Redirect          None

openshift-console          console             console-openshift-console.apps.testextdnsoperator.apacshift.support                       console             https   reencrypt/Redirect     None
openshift-console          downloads           downloads-openshift-console.apps.testextdnsoperator.apacshift.support                     downloads           http    edge/Redirect          None

Copy to Clipboard

Toggle word wrap

dns 영역 목록을 가져와서 이전에 찾은 경로의 도메인에 해당하는 항목을 찾습니다.

aws route53 list-hosted-zones | grep testextdnsoperator.apacshift.support

$ aws route53 list-hosted-zones | grep testextdnsoperator.apacshift.support

Copy to Clipboard

Toggle word wrap

출력 예

HOSTEDZONES	terraform	/hostedzone/Z02355203TNN1XXXX1J6O	testextdnsoperator.apacshift.support.	5

HOSTEDZONES	terraform	/hostedzone/Z02355203TNN1XXXX1J6O	testextdnsoperator.apacshift.support.	5

Copy to Clipboard

Toggle word wrap

경로 소스를 위한 ExternalDNS 리소스를 생성합니다.
```
$ cat <<EOF | oc create -f -
apiVersion: externaldns.olm.openshift.io/v1beta1
kind: ExternalDNS
metadata:
  name: sample-aws 
spec:
  domains:
  - filterType: Include   
    matchType: Exact   
    name: testextdnsoperator.apacshift.support 
  provider:
    type: AWS 
  source:  
    type: OpenShiftRoute 
    openshiftRouteOptions:
      routerName: default 
EOF
```
```
$ cat <<EOF | oc create -f -
apiVersion: externaldns.olm.openshift.io/v1beta1
kind: ExternalDNS
metadata:
  name: sample-aws 
```
1
```
spec:
  domains:
  - filterType: Include   
```
2
```
    matchType: Exact   
```
3
```
    name: testextdnsoperator.apacshift.support 
```
4
```
  provider:
    type: AWS 
```
5
```
  source:  
```
6
```
    type: OpenShiftRoute 
```
7
```
    openshiftRouteOptions:
      routerName: default 
```
8
```
EOF
```
Copy to Clipboard Toggle word wrap
1
외부 DNS 리소스의 이름을 정의합니다.
2
기본적으로 모든 호스팅 영역이 잠재적인 대상으로 선택됩니다. 필요한 호스팅 영역을 포함할 수 있습니다.
3
대상 영역의 도메인 일치는 정확해야 합니다(정식 표현식과 대조되는 경우).
4
업데이트할 영역의 정확한 도메인을 지정합니다. 경로의 호스트 이름은 지정된 도메인의 하위 도메인이어야 합니다.
5
AWS Route53 DNS 공급자를 정의합니다.
6
DNS 레코드 소스에 대한 옵션을 정의합니다.
7
OpenShift 경로 리소스를 이전에 지정한 DNS 공급자에서 생성되는 DNS 레코드의 소스로 정의합니다.
8
소스가 OpenShiftRoute 인 경우 OpenShift Ingress 컨트롤러 이름을 전달할 수 있습니다. 외부 DNS Operator는 CNAME 레코드를 생성하는 동안 해당 라우터의 정식 호스트 이름을 대상으로 선택합니다.

다음 명령을 사용하여 OCP 경로에 대해 생성된 레코드를 확인합니다.

aws route53 list-resource-record-sets --hosted-zone-id Z02355203TNN1XXXX1J6O --query "ResourceRecordSets[?Type == 'CNAME']" | grep console

$ aws route53 list-resource-record-sets --hosted-zone-id Z02355203TNN1XXXX1J6O --query "ResourceRecordSets[?Type == 'CNAME']" | grep console

Copy to Clipboard

Toggle word wrap

16.5. Azure에서 DNS 레코드 생성
링크 복사

외부 DNS Operator를 사용하여 Azure에서 DNS 레코드를 생성할 수 있습니다.

16.5.1. Red Hat External DNS Operator를 사용하여 Azure의 퍼블릭 DNS 영역에 DNS 레코드 생성
링크 복사

Red Hat External DNS Operator를 사용하여 Azure의 퍼블릭 DNS 영역에서 DNS 레코드를 생성할 수 있습니다.

절차

사용자를 확인합니다. 사용자는 kube-system 네임스페이스에 액세스할 수 있어야 합니다. 인증 정보가 없는 경우 kube-system 네임스페이스에서 인증 정보를 가져와 클라우드 공급자 클라이언트를 사용할 수 있습니다.
```
oc whoami
```
```
$ oc whoami
```
Copy to Clipboard Toggle word wrap
출력 예
```
system:admin
```
```
system:admin
```
Copy to Clipboard Toggle word wrap

kube-system 네임스페이스에 있는 azure-credentials 시크릿에서 값을 가져옵니다.

CLIENT_ID=$(oc get secrets azure-credentials  -n kube-system  --template={{.data.azure_client_id}} | base64 -d)
CLIENT_SECRET=$(oc get secrets azure-credentials  -n kube-system  --template={{.data.azure_client_secret}} | base64 -d)
RESOURCE_GROUP=$(oc get secrets azure-credentials  -n kube-system  --template={{.data.azure_resourcegroup}} | base64 -d)
SUBSCRIPTION_ID=$(oc get secrets azure-credentials  -n kube-system  --template={{.data.azure_subscription_id}} | base64 -d)
TENANT_ID=$(oc get secrets azure-credentials  -n kube-system  --template={{.data.azure_tenant_id}} | base64 -d)

$ CLIENT_ID=$(oc get secrets azure-credentials  -n kube-system  --template={{.data.azure_client_id}} | base64 -d)
$ CLIENT_SECRET=$(oc get secrets azure-credentials  -n kube-system  --template={{.data.azure_client_secret}} | base64 -d)
$ RESOURCE_GROUP=$(oc get secrets azure-credentials  -n kube-system  --template={{.data.azure_resourcegroup}} | base64 -d)
$ SUBSCRIPTION_ID=$(oc get secrets azure-credentials  -n kube-system  --template={{.data.azure_subscription_id}} | base64 -d)
$ TENANT_ID=$(oc get secrets azure-credentials  -n kube-system  --template={{.data.azure_tenant_id}} | base64 -d)

Copy to Clipboard

Toggle word wrap

base64 디코딩된 값을 사용하여 Azure에 로그인합니다.

az login --service-principal -u "${CLIENT_ID}" -p "${CLIENT_SECRET}" --tenant "${TENANT_ID}"

$ az login --service-principal -u "${CLIENT_ID}" -p "${CLIENT_SECRET}" --tenant "${TENANT_ID}"

Copy to Clipboard

Toggle word wrap

경로를 가져와 도메인을 확인합니다.

oc get routes --all-namespaces | grep console

$ oc get routes --all-namespaces | grep console

Copy to Clipboard

Toggle word wrap

출력 예

openshift-console          console             console-openshift-console.apps.test.azure.example.com                       console             https   reencrypt/Redirect     None
openshift-console          downloads           downloads-openshift-console.apps.test.azure.example.com                     downloads           http    edge/Redirect          None

openshift-console          console             console-openshift-console.apps.test.azure.example.com                       console             https   reencrypt/Redirect     None
openshift-console          downloads           downloads-openshift-console.apps.test.azure.example.com                     downloads           http    edge/Redirect          None

Copy to Clipboard

Toggle word wrap

dns 영역 목록을 가져와서 이전에 찾은 경로의 도메인에 해당하는 항목을 찾습니다.
```
az network dns zone list --resource-group "${RESOURCE_GROUP}"
```
```
$ az network dns zone list --resource-group "${RESOURCE_GROUP}"
```
Copy to Clipboard Toggle word wrap

경로 소스를 위한 ExternalDNS 리소스를 생성합니다.

apiVersion: externaldns.olm.openshift.io/v1beta1
kind: ExternalDNS
metadata:
  name: sample-azure 
spec:
  zones:
  - "/subscriptions/1234567890/resourceGroups/test-azure-xxxxx-rg/providers/Microsoft.Network/dnszones/test.azure.example.com" 
  provider:
    type: Azure 
  source:
    openshiftRouteOptions: 
      routerName: default 
    type: OpenShiftRoute 
EOF

apiVersion: externaldns.olm.openshift.io/v1beta1
kind: ExternalDNS
metadata:
  name: sample-azure

1


spec:
  zones:
  - "/subscriptions/1234567890/resourceGroups/test-azure-xxxxx-rg/providers/Microsoft.Network/dnszones/test.azure.example.com"

2


  provider:
    type: Azure

3


  source:
    openshiftRouteOptions:

4


      routerName: default

5


    type: OpenShiftRoute

6

EOF

Copy to Clipboard

Toggle word wrap

1: 외부 DNS CR의 이름을 지정합니다.
2: 영역 ID를 정의합니다.
3: Azure DNS 공급자를 정의합니다.
4: DNS 레코드 소스에 대한 옵션을 정의할 수 있습니다.
5: 소스가 OpenShiftRoute 인 경우 OpenShift Ingress 컨트롤러 이름을 전달할 수 있습니다. 외부 DNS는 CNAME 레코드를 생성하는 동안 해당 라우터의 정식 호스트 이름을 대상으로 선택합니다.
6: OpenShift 경로 리소스를 이전에 지정한 DNS 공급자에서 생성되는 DNS 레코드의 소스로 정의합니다.

다음 명령을 사용하여 OCP 경로에 대해 생성된 레코드를 확인합니다.
```
az network dns record-set list -g "${RESOURCE_GROUP}"  -z test.azure.example.com | grep console
```
```
$ az network dns record-set list -g "${RESOURCE_GROUP}"  -z test.azure.example.com | grep console
```
Copy to Clipboard Toggle word wrap
참고
프라이빗 Azure dns의 프라이빗 호스팅 영역에 레코드를 생성하려면 ExternalDNS 컨테이너 args에서 azure-private-dns 에 공급자 유형을 채우는 프라이빗 영역을 지정해야 합니다.

16.6. GCP에서 DNS 레코드 생성
링크 복사

외부 DNS Operator를 사용하여 GCP에서 DNS 레코드를 생성할 수 있습니다.

16.6.1. Red Hat External DNS Operator를 사용하여 GCP의 퍼블릭 관리형 영역에 DNS 레코드 생성
링크 복사

Red Hat External DNS Operator를 사용하여 GCP의 퍼블릭 관리형 영역에서 DNS 레코드를 생성할 수 있습니다.

절차

사용자를 확인합니다. 사용자는 kube-system 네임스페이스에 액세스할 수 있어야 합니다. 인증 정보가 없는 경우 kube-system 네임스페이스에서 인증 정보를 가져와 클라우드 공급자 클라이언트를 사용할 수 있습니다.
```
oc whoami
```
```
$ oc whoami
```
Copy to Clipboard Toggle word wrap
출력 예
```
system:admin
```
```
system:admin
```
Copy to Clipboard Toggle word wrap

다음 명령을 실행하여 encoded-gcloud.json 파일의 gcp-credentials 시크릿의 service_account.json 값을 복사합니다.

oc get secret gcp-credentials -n kube-system --template='{{$v := index .data "service_account.json"}}{{$v}}' | base64 -d - > decoded-gcloud.json

$ oc get secret gcp-credentials -n kube-system --template='{{$v := index .data "service_account.json"}}{{$v}}' | base64 -d - > decoded-gcloud.json

Copy to Clipboard

Toggle word wrap

Google 인증 정보를 내보냅니다.
```
export GOOGLE_CREDENTIALS=decoded-gcloud.json
```
```
$ export GOOGLE_CREDENTIALS=decoded-gcloud.json
```
Copy to Clipboard Toggle word wrap

다음 명령을 사용하여 계정을 활성화합니다.

gcloud auth activate-service-account  <client_email as per decoded-gcloud.json> --key-file=decoded-gcloud.json

$ gcloud auth activate-service-account  <client_email as per decoded-gcloud.json> --key-file=decoded-gcloud.json

Copy to Clipboard

Toggle word wrap

프로젝트를 설정합니다.

gcloud config set project <project_id as per decoded-gcloud.json>

$ gcloud config set project <project_id as per decoded-gcloud.json>

Copy to Clipboard

Toggle word wrap

경로를 가져와 도메인을 확인합니다.

oc get routes --all-namespaces | grep console

$ oc get routes --all-namespaces | grep console

Copy to Clipboard

Toggle word wrap

출력 예

openshift-console          console             console-openshift-console.apps.test.gcp.example.com                       console             https   reencrypt/Redirect     None
openshift-console          downloads           downloads-openshift-console.apps.test.gcp.example.com                     downloads           http    edge/Redirect          None

openshift-console          console             console-openshift-console.apps.test.gcp.example.com                       console             https   reencrypt/Redirect     None
openshift-console          downloads           downloads-openshift-console.apps.test.gcp.example.com                     downloads           http    edge/Redirect          None

Copy to Clipboard

Toggle word wrap

관리형 영역 목록을 가져와서 이전에 찾은 경로의 도메인에 해당하는 영역을 찾습니다.

gcloud dns managed-zones list | grep test.gcp.example.com
qe-cvs4g-private-zone test.gcp.example.com

$ gcloud dns managed-zones list | grep test.gcp.example.com
qe-cvs4g-private-zone test.gcp.example.com

Copy to Clipboard

Toggle word wrap

경로 소스를 위한 ExternalDNS 리소스를 생성합니다.
```
apiVersion: externaldns.olm.openshift.io/v1beta1
kind: ExternalDNS
metadata:
  name: sample-gcp 
spec:
  domains:
    - filterType: Include 
      matchType: Exact 
      name: test.gcp.example.com 
  provider:
    type: GCP 
  source:
    openshiftRouteOptions: 
      routerName: default 
    type: OpenShiftRoute 
EOF
```
```
apiVersion: externaldns.olm.openshift.io/v1beta1
kind: ExternalDNS
metadata:
  name: sample-gcp 
```
1
```
spec:
  domains:
    - filterType: Include 
```
2
```
      matchType: Exact 
```
3
```
      name: test.gcp.example.com 
```
4
```
  provider:
    type: GCP 
```
5
```
  source:
    openshiftRouteOptions: 
```
6
```
      routerName: default 
```
7
```
    type: OpenShiftRoute 
```
8
```
EOF
```
Copy to Clipboard Toggle word wrap
1
외부 DNS CR의 이름을 지정합니다.
2
기본적으로 모든 호스팅 영역이 잠재적인 대상으로 선택됩니다. 필요한 호스팅 영역을 포함할 수 있습니다.
3
대상 영역의 도메인 일치는 정확해야 합니다(정식 표현식과 대조되는 경우).
4
업데이트할 영역의 정확한 도메인을 지정합니다. 경로의 호스트 이름은 지정된 도메인의 하위 도메인이어야 합니다.
5
Google Cloud DNS 공급자를 정의합니다.
6
DNS 레코드 소스에 대한 옵션을 정의할 수 있습니다.
7
소스가 OpenShiftRoute 인 경우 OpenShift Ingress 컨트롤러 이름을 전달할 수 있습니다. 외부 DNS는 CNAME 레코드를 생성하는 동안 해당 라우터의 정식 호스트 이름을 대상으로 선택합니다.
8
OpenShift 경로 리소스를 이전에 지정한 DNS 공급자에서 생성되는 DNS 레코드의 소스로 정의합니다.

다음 명령을 사용하여 OCP 경로에 대해 생성된 레코드를 확인합니다.

gcloud dns record-sets list --zone=qe-cvs4g-private-zone | grep console

$ gcloud dns record-sets list --zone=qe-cvs4g-private-zone | grep console

Copy to Clipboard

Toggle word wrap

16.7. Infoblox에서 DNS 레코드 생성
링크 복사

Red Hat External DNS Operator를 사용하여 Infoblox에서 DNS 레코드를 생성할 수 있습니다.

16.7.1. Infoblox의 퍼블릭 DNS 영역에서 DNS 레코드 생성
링크 복사

Red Hat External DNS Operator를 사용하여 Infoblox의 퍼블릭 DNS 영역에 DNS 레코드를 생성할 수 있습니다.

사전 요구 사항

OpenShift CLI(oc)에 액세스할 수 있습니다.
Infoblox UI에 액세스할 수 있습니다.

프로세스

다음 명령을 실행하여 Infoblox 인증 정보로 보안 오브젝트를 생성합니다.

oc -n external-dns-operator create secret generic infoblox-credentials --from-literal=EXTERNAL_DNS_INFOBLOX_WAPI_USERNAME=<infoblox_username> --from-literal=EXTERNAL_DNS_INFOBLOX_WAPI_PASSWORD=<infoblox_password>

$ oc -n external-dns-operator create secret generic infoblox-credentials --from-literal=EXTERNAL_DNS_INFOBLOX_WAPI_USERNAME=<infoblox_username> --from-literal=EXTERNAL_DNS_INFOBLOX_WAPI_PASSWORD=<infoblox_password>

Copy to Clipboard

Toggle word wrap

다음 명령을 실행하여 routes 오브젝트를 가져와 클러스터 도메인을 확인합니다.

oc get routes --all-namespaces | grep console

$ oc get routes --all-namespaces | grep console

Copy to Clipboard

Toggle word wrap

출력 예

openshift-console          console             console-openshift-console.apps.test.example.com                       console             https   reencrypt/Redirect     None
openshift-console          downloads           downloads-openshift-console.apps.test.example.com                     downloads           http    edge/Redirect          None

openshift-console          console             console-openshift-console.apps.test.example.com                       console             https   reencrypt/Redirect     None
openshift-console          downloads           downloads-openshift-console.apps.test.example.com                     downloads           http    edge/Redirect          None

Copy to Clipboard

Toggle word wrap

다음과 같이 ExternalDNS 리소스 YAML 파일을 생성합니다(예: sample-infoblox.yaml).

apiVersion: externaldns.olm.openshift.io/v1beta1
kind: ExternalDNS
metadata:
  name: sample-infoblox
spec:
  provider:
    type: Infoblox
    infoblox:
      credentials:
        name: infoblox-credentials
      gridHost: ${INFOBLOX_GRID_PUBLIC_IP}
      wapiPort: 443
      wapiVersion: "2.3.1"
  domains:
  - filterType: Include
    matchType: Exact
    name: test.example.com
  source:
    type: OpenShiftRoute
    openshiftRouteOptions:
      routerName: default

apiVersion: externaldns.olm.openshift.io/v1beta1
kind: ExternalDNS
metadata:
  name: sample-infoblox
spec:
  provider:
    type: Infoblox
    infoblox:
      credentials:
        name: infoblox-credentials
      gridHost: ${INFOBLOX_GRID_PUBLIC_IP}
      wapiPort: 443
      wapiVersion: "2.3.1"
  domains:
  - filterType: Include
    matchType: Exact
    name: test.example.com
  source:
    type: OpenShiftRoute
    openshiftRouteOptions:
      routerName: default

Copy to Clipboard

Toggle word wrap

다음 명령을 실행하여 Infoblox에서 ExternalDNS 리소스를 생성합니다.
```
oc create -f sample-infoblox.yaml
```
```
$ oc create -f sample-infoblox.yaml
```
Copy to Clipboard Toggle word wrap
Infoblox UI에서 콘솔 경로에 대해 생성된 DNS 레코드를 확인합니다.
1. 데이터 관리 → DNS → 영역을 클릭합니다.
2. 영역 이름을 선택합니다.

16.8. 외부 DNS Operator에서 클러스터 전체 프록시 구성
링크 복사

외부 DNS Operator에서 클러스터 전체 프록시를 구성할 수 있습니다. 외부 DNS Operator에서 클러스터 전체 프록시를 구성한 후 OLM(Operator Lifecycle Manager)은 HTTP_PROXY,HTTPS_PROXY 및 NO_PROXY 와 같은 환경 변수를 사용하여 Operator의 모든 배포를 자동으로 업데이트합니다.

16.8.1. 클러스터 전체 프록시의 인증 기관을 신뢰하도록 외부 DNS Operator 구성
링크 복사

클러스터 전체 프록시의 인증 기관을 신뢰하도록 외부 DNS Operator를 구성할 수 있습니다.

프로세스

다음 명령을 실행하여 외부-dns-operator 네임스페이스에 CA 번들을 포함하도록 구성 맵을 생성합니다.
```
oc -n external-dns-operator create configmap trusted-ca
```
```
$ oc -n external-dns-operator create configmap trusted-ca
```
Copy to Clipboard Toggle word wrap
신뢰할 수 있는 CA 번들을 구성 맵에 삽입하려면 다음 명령을 실행하여 config.openshift.io/inject-trusted-cabundle=true 라벨을 구성 맵에 추가합니다.
```
oc -n external-dns-operator label cm trusted-ca config.openshift.io/inject-trusted-cabundle=true
```
```
$ oc -n external-dns-operator label cm trusted-ca config.openshift.io/inject-trusted-cabundle=true
```
Copy to Clipboard Toggle word wrap

다음 명령을 실행하여 외부 DNS Operator의 서브스크립션을 업데이트합니다.

oc -n external-dns-operator patch subscription external-dns-operator --type='json' -p='[{"op": "add", "path": "/spec/config", "value":{"env":[{"name":"TRUSTED_CA_CONFIGMAP_NAME","value":"trusted-ca"}]}}]'

$ oc -n external-dns-operator patch subscription external-dns-operator --type='json' -p='[{"op": "add", "path": "/spec/config", "value":{"env":[{"name":"TRUSTED_CA_CONFIGMAP_NAME","value":"trusted-ca"}]}}]'

Copy to Clipboard

Toggle word wrap

검증

외부 DNS Operator 배포가 완료되면 다음 명령을 실행하여 신뢰할 수 있는 CA 환경 변수가 external-dns-operator 배포에 추가되었는지 확인합니다.
```
oc -n external-dns-operator exec deploy/external-dns-operator -c external-dns-operator -- printenv TRUSTED_CA_CONFIGMAP_NAME
```
```
$ oc -n external-dns-operator exec deploy/external-dns-operator -c external-dns-operator -- printenv TRUSTED_CA_CONFIGMAP_NAME
```
Copy to Clipboard Toggle word wrap
출력 예
```
trusted-ca
```
```
trusted-ca
```
Copy to Clipboard Toggle word wrap

17장. 네트워크 정책
링크 복사

17.1. 네트워크 정책 정의
링크 복사

클러스터 관리자는 클러스터의 pod로 트래픽을 제한하는 네트워크 정책을 정의할 수 있습니다.

17.1.1. 네트워크 정책 정의
링크 복사

Kubernetes 네트워크 정책을 지원하는 CNI(Kubernetes Container Network Interface) 플러그인을 사용하는 클러스터에서 네트워크 격리는 NetworkPolicy 개체에 의해서만 제어됩니다. OpenShift Container Platform 4.11에서 OpenShift SDN은 기본 네트워크 격리 모드에서 네트워크 정책의 사용을 지원합니다.

주의

네트워크 정책은 호스트 네트워크 네임스페이스에 적용되지 않습니다. 호스트 네트워킹이 활성화된 Pod는 네트워크 정책 규칙의 영향을 받지 않습니다.

기본적으로 네트워크 정책 모드에서는 다른 Pod 및 네트워크 끝점에서 프로젝트의 모든 Pod에 액세스할 수 있습니다. 프로젝트에서 하나 이상의 Pod를 분리하기 위해 해당 프로젝트에서 NetworkPolicy 오브젝트를 생성하여 수신되는 연결을 표시할 수 있습니다. 프로젝트 관리자는 자신의 프로젝트 내에서 NetworkPolicy 오브젝트를 만들고 삭제할 수 있습니다.

하나 이상의 NetworkPolicy 오브젝트에서 선택기와 Pod가 일치하면 Pod는 해당 NetworkPolicy 오브젝트 중 하나 이상에서 허용되는 연결만 허용합니다. NetworkPolicy 오브젝트가 선택하지 않은 Pod에 완전히 액세스할 수 있습니다.

다음 예제 NetworkPolicy 오브젝트는 다양한 시나리오 지원을 보여줍니다.

모든 트래픽 거부:

기본적으로 프로젝트를 거부하려면 모든 Pod와 일치하지만 트래픽을 허용하지 않는 NetworkPolicy 오브젝트를 추가합니다.

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: deny-by-default
spec:
  podSelector: {}
  ingress: []

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: deny-by-default
spec:
  podSelector: {}
  ingress: []

Copy to Clipboard

Toggle word wrap

OpenShift Container Platform Ingress 컨트롤러의 연결만 허용합니다.

프로젝트에서 OpenShift Container Platform Ingress 컨트롤러의 연결만 허용하도록 하려면 다음 NetworkPolicy 개체를 추가합니다.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-openshift-ingress
spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          network.openshift.io/policy-group: ingress
  podSelector: {}
  policyTypes:
  - Ingress

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-openshift-ingress
spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          network.openshift.io/policy-group: ingress
  podSelector: {}
  policyTypes:
  - Ingress

Copy to Clipboard

Toggle word wrap

프로젝트 내 Pod 연결만 허용:

Pod가 동일한 프로젝트 내 다른 Pod의 연결은 수락하지만 다른 프로젝트에 속하는 Pod의 기타 모든 연결을 거부하도록 하려면 다음 NetworkPolicy 오브젝트를 추가합니다.

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-same-namespace
spec:
  podSelector: {}
  ingress:
  - from:
    - podSelector: {}

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-same-namespace
spec:
  podSelector: {}
  ingress:
  - from:
    - podSelector: {}

Copy to Clipboard

Toggle word wrap

Pod 레이블을 기반으로 하는 HTTP 및 HTTPS 트래픽만 허용:

특정 레이블(다음 예에서 role=frontend)을 사용하여 Pod에 대한 HTTP 및 HTTPS 액세스만 활성화하려면 다음과 유사한 NetworkPolicy 오브젝트를 추가합니다.

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-http-and-https
spec:
  podSelector:
    matchLabels:
      role: frontend
  ingress:
  - ports:
    - protocol: TCP
      port: 80
    - protocol: TCP
      port: 443

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-http-and-https
spec:
  podSelector:
    matchLabels:
      role: frontend
  ingress:
  - ports:
    - protocol: TCP
      port: 80
    - protocol: TCP
      port: 443

Copy to Clipboard

Toggle word wrap

네임스페이스와 Pod 선택기를 모두 사용하여 연결 수락:

네임스페이스와 Pod 선택기를 결합하여 네트워크 트래픽을 일치시키려면 다음과 유사한 NetworkPolicy 오브젝트를 사용하면 됩니다.

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-pod-and-namespace-both
spec:
  podSelector:
    matchLabels:
      name: test-pods
  ingress:
    - from:
      - namespaceSelector:
          matchLabels:
            project: project_name
        podSelector:
          matchLabels:
            name: test-pods

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-pod-and-namespace-both
spec:
  podSelector:
    matchLabels:
      name: test-pods
  ingress:
    - from:
      - namespaceSelector:
          matchLabels:
            project: project_name
        podSelector:
          matchLabels:
            name: test-pods

Copy to Clipboard

Toggle word wrap

NetworkPolicy 오브젝트는 추가 기능이므로 여러 NetworkPolicy 오브젝트를 결합하여 복잡한 네트워크 요구 사항을 충족할 수 있습니다.

예를 들어, 이전 샘플에서 정의된 NetworkPolicy 오브젝트의 경우 동일한 프로젝트 내에서 allow-same-namespace 정책과 allow-http-and-https 정책을 모두 정의할 수 있습니다. 따라서 레이블이 role=frontend로 지정된 Pod는 각 정책에서 허용하는 모든 연결을 허용할 수 있습니다. 즉 동일한 네임스페이스에 있는 Pod의 모든 포트 연결과 모든 네임스페이스에 있는 Pod에서 포트 80 및 443에 대한 연결이 허용됩니다.

17.1.2. 네트워크 정책 최적화
링크 복사

네트워크 정책을 사용하여 네임스페이스 내의 라벨에 따라 서로 다른 포드를 분리합니다.

참고

네트워크 정책 규칙을 효율적으로 사용하기 위한 지침은 OpenShift SDN 클러스터 네트워크 공급자에게만 적용됩니다.

NetworkPolicy 오브젝트를 단일 네임스페이스에서 개별 포드의 많은 수에 적용하는 것은 비효율적입니다. 포드 라벨은 IP 주소 수준에 존재하지 않으므로 네트워크 정책은 podSelector로 선택한 모든 포드 간에 가능한 모든 링크에 대한 별도의 OVS(Open vSwitch) 흐름 규칙을 생성합니다.

예를 들어 NetworkPolicy 오브젝트 내의 spec podSelector 및 ingress podSelector가 각각 200개의 포드와 일치하는 경우 40,000(200*200)개의 OVS 흐름 규칙이 생성됩니다. 이 경우 노드가 느려질 수 있습니다.

네트워크 정책을 설계할 때 다음 지침을 참조하십시오.

분리해야 하는 포드 그룹을 포함하도록 네임스페이스를 사용하여 OVS 흐름 규칙의 수를 줄입니다.
namespaceSelector 또는 빈 podSelector를 사용하여 전체 네임스페이스를 선택하는 NetworkPolicy 오브젝트는 네임스페이스의 VXLAN 가상 네트워크 ID(VNID)와 일치하는 단일 OVS 흐름 규칙만 생성합니다.
원래 네임스페이스에서 분리할 필요가 없는 포드를 유지하고, 분리해야 하는 포드를 하나 이상의 네임스페이스로 이동합니다.
분리된 포드에서 허용하려는 특정 트래픽을 허용하도록 추가 대상의 네임스페이스 간 네트워크 정책을 생성합니다.

17.1.3. 다음 단계
링크 복사

네트워크 정책 생성
선택사항: 기본 네트워크 정책 정의

17.2. 네트워크 정책 이벤트 로깅
링크 복사

클러스터 관리자는 클러스터에 대한 네트워크 정책 감사 로깅을 구성하고 하나 이상의 네임스페이스에 대해 로깅을 활성화할 수 있습니다.

참고

네트워크 정책의 감사 로깅은 OVN-Kubernetes 클러스터 네트워크 공급자 에서만 사용할 수 있습니다.

17.2.1. 네트워크 정책 감사 로깅
링크 복사

OVN-Kubernetes 클러스터 네트워크 공급자는 OVN(Open Virtual Network) ACL을 사용하여 네트워크 정책을 관리합니다. 감사 로깅은 ACL 이벤트를 허용 및 거부합니다.

syslog 서버 또는 UNIX 도메인 소켓과 같은 네트워크 정책 감사 로그의 대상을 구성할 수 있습니다. 추가 구성에 관계없이 감사 로그는 항상 클러스터의 각 OVN-Kubernetes Pod의 /var/log/ovn/acl-audit-log.log에 저장됩니다.

다음 예와 같이 k8s.ovn.org/acl-logging 키로 네임스페이스에 주석을 달아 네임스페이스별로 네트워크 정책 감사 로깅을 사용할 수 있습니다.

네임스페이스 주석의 예

kind: Namespace
apiVersion: v1
metadata:
  name: example1
  annotations:
    k8s.ovn.org/acl-logging: |-
      {
        "deny": "info",
        "allow": "info"
      }

kind: Namespace
apiVersion: v1
metadata:
  name: example1
  annotations:
    k8s.ovn.org/acl-logging: |-
      {
        "deny": "info",
        "allow": "info"
      }

Copy to Clipboard

Toggle word wrap

로깅 형식은 RFC5424에 정의된 대로 syslog와 호환됩니다. syslog 기능은 구성 가능하며 기본값은 local0입니다. 예제 로그 항목은 다음과 유사합니다.

ACL 거부 로그 항목의 예

2021-06-13T19:33:11.590Z|00005|acl_log(ovn_pinctrl0)|INFO|name="verify-audit-logging_deny-all", verdict=drop, severity=alert: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:39,dl_dst=0a:58:0a:80:02:37,nw_src=10.128.2.57,nw_dst=10.128.2.55,nw_tos=0,nw_ecn=0,nw_ttl=64,icmp_type=8,icmp_code=0

2021-06-13T19:33:11.590Z|00005|acl_log(ovn_pinctrl0)|INFO|name="verify-audit-logging_deny-all", verdict=drop, severity=alert: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:39,dl_dst=0a:58:0a:80:02:37,nw_src=10.128.2.57,nw_dst=10.128.2.55,nw_tos=0,nw_ecn=0,nw_ttl=64,icmp_type=8,icmp_code=0

Copy to Clipboard

Toggle word wrap

다음 표에서는 네임스페이스 주석 값에 대해 설명합니다.

Expand

표 17.1. 네트워크 정책 감사 로깅 네임스페이스 주석
주석	값
`k8s.ovn.org/acl-logging`	네임스페이스에 대해 네트워크 정책 감사 로깅을 활성화하려면 `allow`,`deny` 또는 둘 중 하나를 지정해야 합니다. `deny` 선택 사항: `alert`, `warning`, `notice`, `info`, `debug`를 지정합니다. `allow` 선택 사항: `alert`, `warning`, `notice`, `info`, `debug`를 지정합니다.

17.2.2. 네트워크 정책 감사 구성
링크 복사

감사 로깅 구성은 OVN-Kubernetes 클러스터 네트워크 공급자 구성의 일부로 지정됩니다. 다음 YAML은 네트워크 정책 감사 로깅 기능의 기본값을 보여줍니다.

감사 로깅 구성

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  defaultNetwork:
    ovnKubernetesConfig:
      policyAuditConfig:
        destination: "null"
        maxFileSize: 50
        rateLimit: 20
        syslogFacility: local0

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  defaultNetwork:
    ovnKubernetesConfig:
      policyAuditConfig:
        destination: "null"
        maxFileSize: 50
        rateLimit: 20
        syslogFacility: local0

Copy to Clipboard

Toggle word wrap

다음 표에서는 네트워크 정책 감사 로깅을 위한 구성 필드를 설명합니다.

Expand

표 17.2. policyAuditConfig 오브젝트
필드	유형	설명
`rateLimit`	integer	노드당 1초마다 생성할 최대 메시지 수입니다. 기본값은 초당 `20` 개의 메시지입니다.
`maxFileSize`	integer	감사 로그의 최대 크기(바이트)입니다. 기본값은 `50000000` 또는 50MB입니다.
`대상`	string	다음 추가 감사 로그 대상 중 하나입니다. `libc` 호스트에서 journald 프로세스의 libc `syslog()` 함수입니다. `udp:<host>:<port>` syslog 서버입니다. `<host>:<port>`를 syslog 서버의 호스트 및 포트로 바꿉니다. `unix:<file>` `<file>`로 지정된 Unix Domain Socket 파일입니다. `null` 감사 로그를 추가 대상으로 보내지 마십시오.
`syslogFacility`	string	RFC5424에 정의된 `kern`과 같은 syslog 기능입니다. 기본값은 `local0`입니다.

17.2.3. 클러스터에 대한 네트워크 정책 감사 구성
링크 복사

클러스터 관리자는 클러스터의 네트워크 정책 감사 로깅을 사용자 지정할 수 있습니다.

사전 요구 사항

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

프로세스

네트워크 정책 감사 로깅 구성을 사용자 정의하려면 다음 명령을 입력합니다.

oc edit network.operator.openshift.io/cluster

$ oc edit network.operator.openshift.io/cluster

Copy to Clipboard

Toggle word wrap

작은 정보

또는 다음 YAML을 사용자 지정하고 적용하여 감사 로깅을 구성할 수 있습니다.

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  defaultNetwork:
    ovnKubernetesConfig:
      policyAuditConfig:
        destination: "null"
        maxFileSize: 50
        rateLimit: 20
        syslogFacility: local0

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  defaultNetwork:
    ovnKubernetesConfig:
      policyAuditConfig:
        destination: "null"
        maxFileSize: 50
        rateLimit: 20
        syslogFacility: local0

Copy to Clipboard

Toggle word wrap

검증

네트워크 정책을 사용하여 네임스페이스를 생성하려면 다음 단계를 완료합니다.

검증을 위해 네임스페이스를 생성합니다.

cat <<EOF| oc create -f -
kind: Namespace
apiVersion: v1
metadata:
  name: verify-audit-logging
  annotations:
    k8s.ovn.org/acl-logging: '{ "deny": "alert", "allow": "alert" }'
EOF

$ cat <<EOF| oc create -f -
kind: Namespace
apiVersion: v1
metadata:
  name: verify-audit-logging
  annotations:
    k8s.ovn.org/acl-logging: '{ "deny": "alert", "allow": "alert" }'
EOF

Copy to Clipboard

Toggle word wrap

출력 예

namespace/verify-audit-logging created

namespace/verify-audit-logging created

Copy to Clipboard

Toggle word wrap

감사 로깅을 활성화합니다.

oc annotate namespace verify-audit-logging k8s.ovn.org/acl-logging='{ "deny": "alert", "allow": "alert" }'

$ oc annotate namespace verify-audit-logging k8s.ovn.org/acl-logging='{ "deny": "alert", "allow": "alert" }'

Copy to Clipboard

Toggle word wrap

namespace/verify-audit-logging annotated

namespace/verify-audit-logging annotated

Copy to Clipboard

Toggle word wrap

네임스페이스의 네트워크 정책을 생성합니다.

cat <<EOF| oc create -n verify-audit-logging -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
spec:
  podSelector:
    matchLabels:
  policyTypes:
  - Ingress
  - Egress
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-same-namespace
spec:
  podSelector: {}
  policyTypes:
   - Ingress
   - Egress
  ingress:
    - from:
        - podSelector: {}
  egress:
    - to:
       - namespaceSelector:
          matchLabels:
            namespace: verify-audit-logging
EOF

$ cat <<EOF| oc create -n verify-audit-logging -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
spec:
  podSelector:
    matchLabels:
  policyTypes:
  - Ingress
  - Egress
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-same-namespace
spec:
  podSelector: {}
  policyTypes:
   - Ingress
   - Egress
  ingress:
    - from:
        - podSelector: {}
  egress:
    - to:
       - namespaceSelector:
          matchLabels:
            namespace: verify-audit-logging
EOF

Copy to Clipboard

Toggle word wrap

출력 예

networkpolicy.networking.k8s.io/deny-all created
networkpolicy.networking.k8s.io/allow-from-same-namespace created

networkpolicy.networking.k8s.io/deny-all created
networkpolicy.networking.k8s.io/allow-from-same-namespace created

Copy to Clipboard

Toggle word wrap

default 네임스페이스에서 소스 트래픽에 사용할 Pod를 생성합니다.

cat <<EOF| oc create -n default -f -
apiVersion: v1
kind: Pod
metadata:
  name: client
spec:
  containers:
    - name: client
      image: registry.access.redhat.com/rhel7/rhel-tools
      command: ["/bin/sh", "-c"]
      args:
        ["sleep inf"]
EOF

$ cat <<EOF| oc create -n default -f -
apiVersion: v1
kind: Pod
metadata:
  name: client
spec:
  containers:
    - name: client
      image: registry.access.redhat.com/rhel7/rhel-tools
      command: ["/bin/sh", "-c"]
      args:
        ["sleep inf"]
EOF

Copy to Clipboard

Toggle word wrap

verify-audit-logging 네임스페이스에 두 개의 Pod를 생성합니다.

for name in client server; do
cat <<EOF| oc create -n verify-audit-logging -f -
apiVersion: v1
kind: Pod
metadata:
  name: ${name}
spec:
  containers:
    - name: ${name}
      image: registry.access.redhat.com/rhel7/rhel-tools
      command: ["/bin/sh", "-c"]
      args:
        ["sleep inf"]
EOF
done

$ for name in client server; do
cat <<EOF| oc create -n verify-audit-logging -f -
apiVersion: v1
kind: Pod
metadata:
  name: ${name}
spec:
  containers:
    - name: ${name}
      image: registry.access.redhat.com/rhel7/rhel-tools
      command: ["/bin/sh", "-c"]
      args:
        ["sleep inf"]
EOF
done

Copy to Clipboard

Toggle word wrap

출력 예

pod/client created
pod/server created

pod/client created
pod/server created

Copy to Clipboard

Toggle word wrap

트래픽을 생성하고 네트워크 정책 감사 로그 항목을 생성하려면 다음 단계를 완료합니다.

verify-audit-logging 네임스페이스에서 server라는 Pod의 IP 주소를 가져옵니다.

POD_IP=$(oc get pods server -n verify-audit-logging -o jsonpath='{.status.podIP}')

$ POD_IP=$(oc get pods server -n verify-audit-logging -o jsonpath='{.status.podIP}')

Copy to Clipboard

Toggle word wrap

default 네임스페이스에 있는 client라는 Pod에서 이전 명령의 IP 주소를 ping하고 모든 패킷이 삭제되었는지 확인합니다.

oc exec -it client -n default -- /bin/ping -c 2 $POD_IP

$ oc exec -it client -n default -- /bin/ping -c 2 $POD_IP

Copy to Clipboard

Toggle word wrap

출력 예

PING 10.128.2.55 (10.128.2.55) 56(84) bytes of data.

--- 10.128.2.55 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 2041ms

PING 10.128.2.55 (10.128.2.55) 56(84) bytes of data.

--- 10.128.2.55 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 2041ms

Copy to Clipboard

Toggle word wrap

verify-audit-logging 네임스페이스의 client라는 Pod에서 POD_IP 쉘 환경 변수에 저장된 IP 주소를 ping하고 모든 패킷이 허용되는지 확인합니다.

oc exec -it client -n verify-audit-logging -- /bin/ping -c 2 $POD_IP

$ oc exec -it client -n verify-audit-logging -- /bin/ping -c 2 $POD_IP

Copy to Clipboard

Toggle word wrap

출력 예

PING 10.128.0.86 (10.128.0.86) 56(84) bytes of data.
64 bytes from 10.128.0.86: icmp_seq=1 ttl=64 time=2.21 ms
64 bytes from 10.128.0.86: icmp_seq=2 ttl=64 time=0.440 ms

--- 10.128.0.86 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.440/1.329/2.219/0.890 ms

PING 10.128.0.86 (10.128.0.86) 56(84) bytes of data.
64 bytes from 10.128.0.86: icmp_seq=1 ttl=64 time=2.21 ms
64 bytes from 10.128.0.86: icmp_seq=2 ttl=64 time=0.440 ms

--- 10.128.0.86 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.440/1.329/2.219/0.890 ms

Copy to Clipboard

Toggle word wrap

네트워크 정책 감사 로그의 최신 항목을 표시합니다.

for pod in $(oc get pods -n openshift-ovn-kubernetes -l app=ovnkube-node --no-headers=true | awk '{ print $1 }') ; do
    oc exec -it $pod -n openshift-ovn-kubernetes -- tail -4 /var/log/ovn/acl-audit-log.log
  done

$ for pod in $(oc get pods -n openshift-ovn-kubernetes -l app=ovnkube-node --no-headers=true | awk '{ print $1 }') ; do
    oc exec -it $pod -n openshift-ovn-kubernetes -- tail -4 /var/log/ovn/acl-audit-log.log
  done

Copy to Clipboard

Toggle word wrap

출력 예

Defaulting container name to ovn-controller.
Use 'oc describe pod/ovnkube-node-hdb8v -n openshift-ovn-kubernetes' to see all of the containers in this pod.
2021-06-13T19:33:11.590Z|00005|acl_log(ovn_pinctrl0)|INFO|name="verify-audit-logging_deny-all", verdict=drop, severity=alert: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:39,dl_dst=0a:58:0a:80:02:37,nw_src=10.128.2.57,nw_dst=10.128.2.55,nw_tos=0,nw_ecn=0,nw_ttl=64,icmp_type=8,icmp_code=0
2021-06-13T19:33:12.614Z|00006|acl_log(ovn_pinctrl0)|INFO|name="verify-audit-logging_deny-all", verdict=drop, severity=alert: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:39,dl_dst=0a:58:0a:80:02:37,nw_src=10.128.2.57,nw_dst=10.128.2.55,nw_tos=0,nw_ecn=0,nw_ttl=64,icmp_type=8,icmp_code=0
2021-06-13T19:44:10.037Z|00007|acl_log(ovn_pinctrl0)|INFO|name="verify-audit-logging_allow-from-same-namespace_0", verdict=allow, severity=alert: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:3b,dl_dst=0a:58:0a:80:02:3a,nw_src=10.128.2.59,nw_dst=10.128.2.58,nw_tos=0,nw_ecn=0,nw_ttl=64,icmp_type=8,icmp_code=0
2021-06-13T19:44:11.037Z|00008|acl_log(ovn_pinctrl0)|INFO|name="verify-audit-logging_allow-from-same-namespace_0", verdict=allow, severity=alert: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:3b,dl_dst=0a:58:0a:80:02:3a,nw_src=10.128.2.59,nw_dst=10.128.2.58,nw_tos=0,nw_ecn=0,nw_ttl=64,icmp_type=8,icmp_code=0

Defaulting container name to ovn-controller.
Use 'oc describe pod/ovnkube-node-hdb8v -n openshift-ovn-kubernetes' to see all of the containers in this pod.
2021-06-13T19:33:11.590Z|00005|acl_log(ovn_pinctrl0)|INFO|name="verify-audit-logging_deny-all", verdict=drop, severity=alert: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:39,dl_dst=0a:58:0a:80:02:37,nw_src=10.128.2.57,nw_dst=10.128.2.55,nw_tos=0,nw_ecn=0,nw_ttl=64,icmp_type=8,icmp_code=0
2021-06-13T19:33:12.614Z|00006|acl_log(ovn_pinctrl0)|INFO|name="verify-audit-logging_deny-all", verdict=drop, severity=alert: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:39,dl_dst=0a:58:0a:80:02:37,nw_src=10.128.2.57,nw_dst=10.128.2.55,nw_tos=0,nw_ecn=0,nw_ttl=64,icmp_type=8,icmp_code=0
2021-06-13T19:44:10.037Z|00007|acl_log(ovn_pinctrl0)|INFO|name="verify-audit-logging_allow-from-same-namespace_0", verdict=allow, severity=alert: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:3b,dl_dst=0a:58:0a:80:02:3a,nw_src=10.128.2.59,nw_dst=10.128.2.58,nw_tos=0,nw_ecn=0,nw_ttl=64,icmp_type=8,icmp_code=0
2021-06-13T19:44:11.037Z|00008|acl_log(ovn_pinctrl0)|INFO|name="verify-audit-logging_allow-from-same-namespace_0", verdict=allow, severity=alert: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:3b,dl_dst=0a:58:0a:80:02:3a,nw_src=10.128.2.59,nw_dst=10.128.2.58,nw_tos=0,nw_ecn=0,nw_ttl=64,icmp_type=8,icmp_code=0

Copy to Clipboard

Toggle word wrap

17.2.4. 네임스페이스에 대한 네트워크 정책 감사 로깅 활성화
링크 복사

클러스터 관리자는 네임스페이스에 대한 기존 네트워크 정책 감사 로깅을 활성화할 수 있습니다.

사전 요구 사항

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

프로세스

네임스페이스의 네트워크 정책 감사 로깅을 활성화하려면 다음 명령을 입력합니다.

oc annotate namespace <namespace> \
  k8s.ovn.org/acl-logging='{ "deny": "alert", "allow": "notice" }'

$ oc annotate namespace <namespace> \
  k8s.ovn.org/acl-logging='{ "deny": "alert", "allow": "notice" }'

Copy to Clipboard

Toggle word wrap

다음과 같습니다.

<namespace>: 네임스페이스의 이름을 지정합니다.

작은 정보

다음 YAML을 적용하여 감사 로깅을 활성화할 수 있습니다.

kind: Namespace
apiVersion: v1
metadata:
  name: <namespace>
  annotations:
    k8s.ovn.org/acl-logging: |-
      {
        "deny": "alert",
        "allow": "notice"
      }

kind: Namespace
apiVersion: v1
metadata:
  name: <namespace>
  annotations:
    k8s.ovn.org/acl-logging: |-
      {
        "deny": "alert",
        "allow": "notice"
      }

Copy to Clipboard

Toggle word wrap

출력 예

namespace/verify-audit-logging annotated

namespace/verify-audit-logging annotated

Copy to Clipboard

Toggle word wrap

검증

네트워크 정책 감사 로그의 최신 항목을 표시합니다.

for pod in $(oc get pods -n openshift-ovn-kubernetes -l app=ovnkube-node --no-headers=true | awk '{ print $1 }') ; do
    oc exec -it $pod -n openshift-ovn-kubernetes -- tail -4 /var/log/ovn/acl-audit-log.log
  done

$ for pod in $(oc get pods -n openshift-ovn-kubernetes -l app=ovnkube-node --no-headers=true | awk '{ print $1 }') ; do
    oc exec -it $pod -n openshift-ovn-kubernetes -- tail -4 /var/log/ovn/acl-audit-log.log
  done

Copy to Clipboard

Toggle word wrap

출력 예

2021-06-13T19:33:11.590Z|00005|acl_log(ovn_pinctrl0)|INFO|name="verify-audit-logging_deny-all", verdict=drop, severity=alert: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:39,dl_dst=0a:58:0a:80:02:37,nw_src=10.128.2.57,nw_dst=10.128.2.55,nw_tos=0,nw_ecn=0,nw_ttl=64,icmp_type=8,icmp_code=0

2021-06-13T19:33:11.590Z|00005|acl_log(ovn_pinctrl0)|INFO|name="verify-audit-logging_deny-all", verdict=drop, severity=alert: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:39,dl_dst=0a:58:0a:80:02:37,nw_src=10.128.2.57,nw_dst=10.128.2.55,nw_tos=0,nw_ecn=0,nw_ttl=64,icmp_type=8,icmp_code=0

Copy to Clipboard

Toggle word wrap

17.2.5. 네임스페이스의 네트워크 정책 감사 로깅 비활성화
링크 복사

클러스터 관리자는 네임스페이스에 대한 네트워크 정책 감사 로깅을 비활성화할 수 있습니다.

사전 요구 사항

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

절차

네임스페이스에 대한 네트워크 정책 감사 로깅을 비활성화하려면 다음 명령을 입력합니다.
```
oc annotate --overwrite namespace <namespace> k8s.ovn.org/acl-logging-
```
```
$ oc annotate --overwrite namespace <namespace> k8s.ovn.org/acl-logging-
```
Copy to Clipboard Toggle word wrap
다음과 같습니다.
<namespace>
네임스페이스의 이름을 지정합니다.
작은 정보
다음 YAML을 적용하여 감사 로깅을 비활성화할 수 있습니다.
kind: Namespace apiVersion: v1 metadata: name: <namespace> annotations: k8s.ovn.org/acl-logging: null
Copy to Clipboard Toggle word wrap
출력 예
```
namespace/verify-audit-logging annotated
```
```
namespace/verify-audit-logging annotated
```
Copy to Clipboard Toggle word wrap

17.3. 네트워크 정책 생성
링크 복사

admin 역할이 있는 사용자는 네임스페이스에 대한 네트워크 정책을 생성할 수 있습니다.

17.3.1. NetworkPolicy 오브젝트 예
링크 복사

다음은 예제 NetworkPolicy 오브젝트에 대한 주석입니다.

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-27107 
spec:
  podSelector: 
    matchLabels:
      app: mongodb
  ingress:
  - from:
    - podSelector: 
        matchLabels:
          app: app
    ports: 
    - protocol: TCP
      port: 27017

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-27107

1


spec:
  podSelector:

2


    matchLabels:
      app: mongodb
  ingress:
  - from:
    - podSelector:

3


        matchLabels:
          app: app
    ports:

4


    - protocol: TCP
      port: 27017

Copy to Clipboard

Toggle word wrap

1: NetworkPolicy 오브젝트의 이름입니다.
2: 정책이 적용되는 Pod를 설명하는 선택기입니다. 정책 오브젝트는 NetworkPolicy 오브젝트를 정의하는 프로젝트에서만 Pod를 선택할 수 있습니다.
3: 정책 오브젝트가 수신 트래픽을 허용하는 Pod와 일치하는 선택기입니다. 선택기는 NetworkPolicy와 동일한 네임스페이스의 Pod와 일치합니다.
4: 트래픽을 허용할 하나 이상의 대상 포트 목록입니다.

17.3.2. CLI를 사용하여 네트워크 정책 생성
링크 복사

클러스터의 네임스페이스에서 허용된 수신 또는 송신 네트워크 트래픽을 설명하는 세분화된 규칙을 정의하기 위해 네트워크 정책을 생성할 수 있습니다.

참고

cluster-admin 역할로 사용자로 로그인하는 경우 클러스터의 모든 네임스페이스에서 네트워크 정책을 생성할 수 있습니다.

사전 요구 사항

클러스터는 NetworkPolicy 오브젝트를 지원하는 클러스터 네트워크 공급자(예: mode: NetworkPolicy 로 설정된 OpenShift SDN 네트워크 공급자)를 사용합니다. 이 모드는 OpenShift SDN의 기본값입니다.
OpenShift CLI(oc)를 설치합니다.
admin 권한이 있는 사용자로 클러스터에 로그인합니다.
네트워크 정책이 적용되는 네임스페이스에서 작업하고 있습니다.

절차

다음과 같이 정책 규칙을 생성합니다.

<policy_name>.yaml 파일을 생성합니다.
```
touch <policy_name>.yaml
```
```
$ touch <policy_name>.yaml
```
Copy to Clipboard Toggle word wrap
다음과 같습니다.
<policy_name>
네트워크 정책 파일 이름을 지정합니다.

방금 만든 파일에서 다음 예와 같이 네트워크 정책을 정의합니다.

모든 네임스페이스의 모든 Pod에서 수신 거부

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: deny-by-default
spec:
  podSelector:
  ingress: []

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: deny-by-default
spec:
  podSelector:
  ingress: []

Copy to Clipboard

Toggle word wrap

동일한 네임 스페이스에 있는 모든 Pod의 수신 허용

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-same-namespace
spec:
  podSelector:
  ingress:
  - from:
    - podSelector: {}

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-same-namespace
spec:
  podSelector:
  ingress:
  - from:
    - podSelector: {}

Copy to Clipboard

Toggle word wrap

다음 명령을 실행하여 네트워크 정책 오브젝트를 생성합니다.
```
oc apply -f <policy_name>.yaml -n <namespace>
```
```
$ oc apply -f <policy_name>.yaml -n <namespace>
```
Copy to Clipboard Toggle word wrap
다음과 같습니다.
<policy_name>
네트워크 정책 파일 이름을 지정합니다.
<namespace>
선택 사항: 오브젝트가 현재 네임스페이스와 다른 네임스페이스에 정의된 경우 이를 사용하여 네임스페이스를 지정합니다.
출력 예
```
networkpolicy.networking.k8s.io/default-deny created
```
```
networkpolicy.networking.k8s.io/default-deny created
```
Copy to Clipboard Toggle word wrap

참고

cluster-admin 권한을 사용하여 웹 콘솔에 로그인하면 클러스터의 모든 네임스페이스에서 YAML 또는 웹 콘솔의 양식에서 직접 네트워크 정책을 생성할 수 있습니다.

17.4. 네트워크 정책 보기
링크 복사

admin 역할이 있는 사용자는 네임스페이스에 대한 네트워크 정책을 볼 수 있습니다.

17.4.1. NetworkPolicy 오브젝트 예
링크 복사

다음은 예제 NetworkPolicy 오브젝트에 대한 주석입니다.

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-27107 
spec:
  podSelector: 
    matchLabels:
      app: mongodb
  ingress:
  - from:
    - podSelector: 
        matchLabels:
          app: app
    ports: 
    - protocol: TCP
      port: 27017

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-27107

1


spec:
  podSelector:

2


    matchLabels:
      app: mongodb
  ingress:
  - from:
    - podSelector:

3


        matchLabels:
          app: app
    ports:

4


    - protocol: TCP
      port: 27017

Copy to Clipboard

Toggle word wrap

1: NetworkPolicy 오브젝트의 이름입니다.
2: 정책이 적용되는 Pod를 설명하는 선택기입니다. 정책 오브젝트는 NetworkPolicy 오브젝트를 정의하는 프로젝트에서만 Pod를 선택할 수 있습니다.
3: 정책 오브젝트가 수신 트래픽을 허용하는 Pod와 일치하는 선택기입니다. 선택기는 NetworkPolicy와 동일한 네임스페이스의 Pod와 일치합니다.
4: 트래픽을 허용할 하나 이상의 대상 포트 목록입니다.

17.4.2. CLI를 사용하여 네트워크 정책 보기
링크 복사

네임스페이스에서 네트워크 정책을 검사할 수 있습니다.

참고

cluster-admin 역할을 가진 사용자로 로그인하면 클러스터의 모든 네트워크 정책을 볼 수 있습니다.

사전 요구 사항

OpenShift CLI(oc)를 설치합니다.
admin 권한이 있는 사용자로 클러스터에 로그인합니다.
네트워크 정책이 존재하는 네임스페이스에서 작업하고 있습니다.

프로세스

네임스페이스의 네트워크 정책을 나열합니다.

네임스페이스에 정의된 네트워크 정책 개체를 보려면 다음 명령을 입력합니다.
```
oc get networkpolicy
```
```
$ oc get networkpolicy
```
Copy to Clipboard Toggle word wrap

선택 사항: 특정 네트워크 정책을 검사하려면 다음 명령을 입력합니다.

oc describe networkpolicy <policy_name> -n <namespace>

$ oc describe networkpolicy <policy_name> -n <namespace>

Copy to Clipboard

Toggle word wrap

다음과 같습니다.

<policy_name>: 검사할 네트워크 정책의 이름을 지정합니다.
<namespace>: 선택 사항: 오브젝트가 현재 네임스페이스와 다른 네임스페이스에 정의된 경우 이를 사용하여 네임스페이스를 지정합니다.

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

oc describe networkpolicy allow-same-namespace

$ oc describe networkpolicy allow-same-namespace

Copy to Clipboard

Toggle word wrap

oc describe 명령의 출력

Name:         allow-same-namespace
Namespace:    ns1
Created on:   2021-05-24 22:28:56 -0400 EDT
Labels:       <none>
Annotations:  <none>
Spec:
  PodSelector:     <none> (Allowing the specific traffic to all pods in this namespace)
  Allowing ingress traffic:
    To Port: <any> (traffic allowed to all ports)
    From:
      PodSelector: <none>
  Not affecting egress traffic
  Policy Types: Ingress

Name:         allow-same-namespace
Namespace:    ns1
Created on:   2021-05-24 22:28:56 -0400 EDT
Labels:       <none>
Annotations:  <none>
Spec:
  PodSelector:     <none> (Allowing the specific traffic to all pods in this namespace)
  Allowing ingress traffic:
    To Port: <any> (traffic allowed to all ports)
    From:
      PodSelector: <none>
  Not affecting egress traffic
  Policy Types: Ingress

Copy to Clipboard

Toggle word wrap

참고

cluster-admin 권한을 사용하여 웹 콘솔에 로그인하면 클러스터의 모든 네임스페이스에서 YAML 또는 웹 콘솔의 양식에서 직접 네트워크 정책을 볼 수 있습니다.

17.5. 네트워크 정책 편집
링크 복사

관리자 역할이 있는 사용자는 네임스페이스에 대한 기존 네트워크 정책을 편집할 수 있습니다.

17.5.1. 네트워크 정책 편집
링크 복사

네임스페이스에서 네트워크 정책을 편집할 수 있습니다.

참고

cluster-admin 역할을 가진 사용자로 로그인하면 클러스터의 모든 네임스페이스에서 네트워크 정책을 편집할 수 있습니다.

사전 요구 사항

클러스터는 NetworkPolicy 오브젝트를 지원하는 클러스터 네트워크 공급자(예: mode: NetworkPolicy 로 설정된 OpenShift SDN 네트워크 공급자)를 사용합니다. 이 모드는 OpenShift SDN의 기본값입니다.
OpenShift CLI(oc)를 설치합니다.
admin 권한이 있는 사용자로 클러스터에 로그인합니다.
네트워크 정책이 존재하는 네임스페이스에서 작업하고 있습니다.

프로세스

선택 사항: 네임스페이스의 네트워크 정책 개체를 나열하려면 다음 명령을 입력합니다.
```
oc get networkpolicy
```
```
$ oc get networkpolicy
```
Copy to Clipboard Toggle word wrap
다음과 같습니다.
<namespace>
선택 사항: 오브젝트가 현재 네임스페이스와 다른 네임스페이스에 정의된 경우 이를 사용하여 네임스페이스를 지정합니다.
네트워크 정책 오브젝트를 편집합니다.
- 네트워크 정책 정의를 파일에 저장한 경우 파일을 편집하고 필요한 사항을 변경한 후 다음 명령을 입력합니다.
  $ oc apply -n <namespace> -f <policy_file>.yaml
  Copy to Clipboard Toggle word wrap
  다음과 같습니다.
  <namespace>
  선택 사항: 오브젝트가 현재 네임스페이스와 다른 네임스페이스에 정의된 경우 이를 사용하여 네임스페이스를 지정합니다.
  <policy_file>
  네트워크 정책이 포함된 파일의 이름을 지정합니다.
- 네트워크 정책 개체를 직접 업데이트해야 하는 경우 다음 명령을 입력합니다.
  $ oc edit networkpolicy <policy_name> -n <namespace>
  Copy to Clipboard Toggle word wrap
  다음과 같습니다.
  <policy_name>
  네트워크 정책의 이름을 지정합니다.
  <namespace>
  선택 사항: 오브젝트가 현재 네임스페이스와 다른 네임스페이스에 정의된 경우 이를 사용하여 네임스페이스를 지정합니다.
네트워크 정책 개체가 업데이트되었는지 확인합니다.
```
oc describe networkpolicy <policy_name> -n <namespace>
```
```
$ oc describe networkpolicy <policy_name> -n <namespace>
```
Copy to Clipboard Toggle word wrap
다음과 같습니다.
<policy_name>
네트워크 정책의 이름을 지정합니다.
<namespace>
선택 사항: 오브젝트가 현재 네임스페이스와 다른 네임스페이스에 정의된 경우 이를 사용하여 네임스페이스를 지정합니다.

참고

cluster-admin 권한을 사용하여 웹 콘솔에 로그인하면 클러스터의 모든 네임스페이스에서 YAML에서 직접 또는 작업 메뉴를 통해 웹 콘솔의 정책에서 네트워크 정책을 편집할 수 있습니다.

17.5.2. NetworkPolicy 오브젝트 예
링크 복사

다음은 예제 NetworkPolicy 오브젝트에 대한 주석입니다.

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-27107 
spec:
  podSelector: 
    matchLabels:
      app: mongodb
  ingress:
  - from:
    - podSelector: 
        matchLabels:
          app: app
    ports: 
    - protocol: TCP
      port: 27017

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-27107

1


spec:
  podSelector:

2


    matchLabels:
      app: mongodb
  ingress:
  - from:
    - podSelector:

3


        matchLabels:
          app: app
    ports:

4


    - protocol: TCP
      port: 27017

Copy to Clipboard

Toggle word wrap

1: NetworkPolicy 오브젝트의 이름입니다.
2: 정책이 적용되는 Pod를 설명하는 선택기입니다. 정책 오브젝트는 NetworkPolicy 오브젝트를 정의하는 프로젝트에서만 Pod를 선택할 수 있습니다.
3: 정책 오브젝트가 수신 트래픽을 허용하는 Pod와 일치하는 선택기입니다. 선택기는 NetworkPolicy와 동일한 네임스페이스의 Pod와 일치합니다.
4: 트래픽을 허용할 하나 이상의 대상 포트 목록입니다.

17.6. 네트워크 정책 삭제
링크 복사

admin 역할이 있는 사용자는 네임스페이스에서 네트워크 정책을 삭제할 수 있습니다.

17.6.1. CLI를 사용하여 네트워크 정책 삭제
링크 복사

네임스페이스에서 네트워크 정책을 삭제할 수 있습니다.

참고

cluster-admin 역할을 가진 사용자로 로그인하면 클러스터의 모든 네트워크 정책을 삭제할 수 있습니다.

사전 요구 사항

클러스터는 NetworkPolicy 오브젝트를 지원하는 클러스터 네트워크 공급자(예: mode: NetworkPolicy 로 설정된 OpenShift SDN 네트워크 공급자)를 사용합니다. 이 모드는 OpenShift SDN의 기본값입니다.
OpenShift CLI(oc)를 설치합니다.
admin 권한이 있는 사용자로 클러스터에 로그인합니다.
네트워크 정책이 존재하는 네임스페이스에서 작업하고 있습니다.

프로세스

네트워크 정책 개체를 삭제하려면 다음 명령을 입력합니다.
```
oc delete networkpolicy <policy_name> -n <namespace>
```
```
$ oc delete networkpolicy <policy_name> -n <namespace>
```
Copy to Clipboard Toggle word wrap
다음과 같습니다.
<policy_name>
네트워크 정책의 이름을 지정합니다.
<namespace>
선택 사항: 오브젝트가 현재 네임스페이스와 다른 네임스페이스에 정의된 경우 이를 사용하여 네임스페이스를 지정합니다.
출력 예
```
networkpolicy.networking.k8s.io/default-deny deleted
```
```
networkpolicy.networking.k8s.io/default-deny deleted
```
Copy to Clipboard Toggle word wrap

참고

cluster-admin 권한을 사용하여 웹 콘솔에 로그인하면 클러스터의 모든 네임스페이스에서 YAML에서 직접 또는 작업 메뉴를 통해 웹 콘솔의 정책에서 네트워크 정책을 삭제할 수 있습니다.

17.7. 프로젝트의 기본 네트워크 정책 정의
링크 복사

클러스터 관리자는 새 프로젝트를 만들 때 네트워크 정책을 자동으로 포함하도록 새 프로젝트 템플릿을 수정할 수 있습니다. 새 프로젝트에 대한 사용자 정의 템플릿이 아직 없는 경우에는 우선 생성해야 합니다.

17.7.1. 새 프로젝트의 템플릿 수정
링크 복사

클러스터 관리자는 사용자 정의 요구 사항을 사용하여 새 프로젝트를 생성하도록 기본 프로젝트 템플릿을 수정할 수 있습니다.

사용자 정의 프로젝트 템플릿을 만들려면:

프로세스

cluster-admin 권한이 있는 사용자로 로그인합니다.

기본 프로젝트 템플릿을 생성합니다.

oc adm create-bootstrap-project-template -o yaml > template.yaml

$ oc adm create-bootstrap-project-template -o yaml > template.yaml

Copy to Clipboard

Toggle word wrap

텍스트 편집기를 사용하여 오브젝트를 추가하거나 기존 오브젝트를 수정하여 생성된 template.yaml 파일을 수정합니다.
프로젝트 템플릿은 openshift-config 네임스페이스에서 생성해야 합니다. 수정된 템플릿을 불러옵니다.
```
oc create -f template.yaml -n openshift-config
```
```
$ oc create -f template.yaml -n openshift-config
```
Copy to Clipboard Toggle word wrap
웹 콘솔 또는 CLI를 사용하여 프로젝트 구성 리소스를 편집합니다.
- 웹 콘솔에 액세스:
  1. 관리 → 클러스터 설정으로 이동합니다.
  2. 구성을 클릭하여 모든 구성 리소스를 확인합니다.
  3. 프로젝트 항목을 찾아 YAML 편집을 클릭합니다.
- CLI 사용:
  1. 다음과 같이 project.config.openshift.io/cluster 리소스를 편집합니다.
    
    $ oc edit project.config.openshift.io/cluster
    
    Copy to Clipboard Toggle word wrap
projectRequestTemplate 및 name 매개변수를 포함하도록 spec 섹션을 업데이트하고 업로드된 프로젝트 템플릿의 이름을 설정합니다. 기본 이름은 project-request입니다.
사용자 정의 프로젝트 템플릿이 포함된 프로젝트 구성 리소스
```
apiVersion: config.openshift.io/v1
kind: Project
metadata:
  ...
spec:
  projectRequestTemplate:
    name: <template_name>
```
```
apiVersion: config.openshift.io/v1
kind: Project
metadata:
  ...
spec:
  projectRequestTemplate:
    name: <template_name>
```
Copy to Clipboard Toggle word wrap
변경 사항을 저장한 후 새 프로젝트를 생성하여 변경 사항이 성공적으로 적용되었는지 확인합니다.

17.7.2. 새 프로젝트 템플릿에 네트워크 정책 추가
링크 복사

클러스터 관리자는 네트워크 정책을 새 프로젝트의 기본 템플릿에 추가할 수 있습니다. OpenShift Container Platform은 프로젝트의 템플릿에 지정된 모든 NetworkPolicy 개체를 자동으로 생성합니다.

사전 요구 사항

클러스터는 NetworkPolicy 오브젝트를 지원하는 기본 CNI 네트워크 공급자(예: mode: NetworkPolicy로 설정된 OpenShift SDN 네트워크 공급자)를 사용합니다. 이 모드는 OpenShift SDN의 기본값입니다.
OpenShift CLI(oc)를 설치합니다.
cluster-admin 권한이 있는 사용자로 클러스터에 로그인해야 합니다.
새 프로젝트에 대한 사용자 정의 기본 프로젝트 템플릿을 생성해야 합니다.

프로세스

다음 명령을 실행하여 새 프로젝트의 기본 템플릿을 편집합니다.
```
oc edit template <project_template> -n openshift-config
```
```
$ oc edit template <project_template> -n openshift-config
```
Copy to Clipboard Toggle word wrap
<project_template>을 클러스터에 대해 구성한 기본 템플릿의 이름으로 변경합니다. 기본 템플릿 이름은 project-request입니다.

템플릿에서 각 NetworkPolicy 오브젝트를 objects 매개변수의 요소로 추가합니다. objects 매개변수는 하나 이상의 오브젝트 컬렉션을 허용합니다.

다음 예제에서 objects 매개변수 컬렉션에는 여러 NetworkPolicy 오브젝트가 포함됩니다.

objects:
- apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    name: allow-from-same-namespace
  spec:
    podSelector: {}
    ingress:
    - from:
      - podSelector: {}
- apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    name: allow-from-openshift-ingress
  spec:
    ingress:
    - from:
      - namespaceSelector:
          matchLabels:
            network.openshift.io/policy-group: ingress
    podSelector: {}
    policyTypes:
    - Ingress
- apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    name: allow-from-kube-apiserver-operator
  spec:
    ingress:
    - from:
      - namespaceSelector:
          matchLabels:
            kubernetes.io/metadata.name: openshift-kube-apiserver-operator
        podSelector:
          matchLabels:
            app: kube-apiserver-operator
    policyTypes:
    - Ingress
...

objects:
- apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    name: allow-from-same-namespace
  spec:
    podSelector: {}
    ingress:
    - from:
      - podSelector: {}
- apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    name: allow-from-openshift-ingress
  spec:
    ingress:
    - from:
      - namespaceSelector:
          matchLabels:
            network.openshift.io/policy-group: ingress
    podSelector: {}
    policyTypes:
    - Ingress
- apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    name: allow-from-kube-apiserver-operator
  spec:
    ingress:
    - from:
      - namespaceSelector:
          matchLabels:
            kubernetes.io/metadata.name: openshift-kube-apiserver-operator
        podSelector:
          matchLabels:
            app: kube-apiserver-operator
    policyTypes:
    - Ingress
...

Copy to Clipboard

Toggle word wrap

선택 사항: 다음 명령을 실행하여 새 프로젝트를 생성하고 네트워크 정책 오브젝트가 생성되었는지 확인합니다.
1. 새 프로젝트를 생성합니다.
  $ oc new-project <project>
  1
  Copy to Clipboard Toggle word wrap
  1
  <project> 를 생성중인 프로젝트의 이름으로 변경합니다.
2. 새 프로젝트 템플릿의 네트워크 정책 오브젝트가 새 프로젝트에 있는지 확인합니다.
  $ oc get networkpolicy NAME POD-SELECTOR AGE allow-from-openshift-ingress <none> 7s allow-from-same-namespace <none> 7s
  Copy to Clipboard Toggle word wrap

17.8. 네트워크 정책으로 다중 테넌트 격리 구성
링크 복사

클러스터 관리자는 다중 테넌트 네트워크 격리를 제공하도록 네트워크 정책을 구성할 수 있습니다.

참고

OpenShift SDN 클러스터 네트워크 공급자를 사용하는 경우 이 섹션에 설명된 대로 네트워크 정책을 구성하는 경우 다중 테넌트 모드와 유사하지만 네투어크 정책 모드가 설정된 네트워크 격리를 제공합니다.

17.8.1. 네트워크 정책을 사용하여 다중 테넌트 격리 구성
링크 복사

다른 프로젝트 네임스페이스의 Pod 및 서비스에서 격리하도록 프로젝트를 구성할 수 있습니다.

사전 요구 사항

클러스터는 NetworkPolicy 오브젝트를 지원하는 클러스터 네트워크 공급자(예: mode: NetworkPolicy 로 설정된 OpenShift SDN 네트워크 공급자)를 사용합니다. 이 모드는 OpenShift SDN의 기본값입니다.
OpenShift CLI(oc)를 설치합니다.
admin 권한이 있는 사용자로 클러스터에 로그인합니다.

프로세스

다음 NetworkPolicy 오브젝트를 생성합니다.

이름이 allow-from-openshift-ingress인 정책입니다.

cat << EOF| oc create -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-openshift-ingress
spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          policy-group.network.openshift.io/ingress: ""
  podSelector: {}
  policyTypes:
  - Ingress
EOF

$ cat << EOF| oc create -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-openshift-ingress
spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          policy-group.network.openshift.io/ingress: ""
  podSelector: {}
  policyTypes:
  - Ingress
EOF

Copy to Clipboard

Toggle word wrap

참고

policy-group.network.openshift.io/ingress: "" 는 OpenShift SDN의 기본 네임스페이스 선택기 레이블입니다. network.openshift.io/policy-group: ingress 네임스페이스 선택기 레이블을 사용할 수 있지만 이는 레거시 레이블입니다.

이름이 allow-from-openshift-monitoring인 정책:

cat << EOF| oc create -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-openshift-monitoring
spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          network.openshift.io/policy-group: monitoring
  podSelector: {}
  policyTypes:
  - Ingress
EOF

$ cat << EOF| oc create -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-openshift-monitoring
spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          network.openshift.io/policy-group: monitoring
  podSelector: {}
  policyTypes:
  - Ingress
EOF

Copy to Clipboard

Toggle word wrap

이름이 allow-same-namespace인 정책:

cat << EOF| oc create -f -
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-same-namespace
spec:
  podSelector:
  ingress:
  - from:
    - podSelector: {}
EOF

$ cat << EOF| oc create -f -
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-same-namespace
spec:
  podSelector:
  ingress:
  - from:
    - podSelector: {}
EOF

Copy to Clipboard

Toggle word wrap

이름이 allow-from-kube-apiserver-operator 인 정책:

cat << EOF| oc create -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-kube-apiserver-operator
spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: openshift-kube-apiserver-operator
      podSelector:
        matchLabels:
          app: kube-apiserver-operator
  policyTypes:
  - Ingress
EOF

$ cat << EOF| oc create -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-kube-apiserver-operator
spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: openshift-kube-apiserver-operator
      podSelector:
        matchLabels:
          app: kube-apiserver-operator
  policyTypes:
  - Ingress
EOF

Copy to Clipboard

Toggle word wrap

자세한 내용은 웹 후크 의 상태를 검증하는 새로운 kube-apiserver-operator 웹 후크 컨트롤러 를 참조하십시오.

선택 사항: 현재 프로젝트에 네트워크 정책이 있는지 확인하려면 다음 명령을 입력합니다.

oc describe networkpolicy

$ oc describe networkpolicy

Copy to Clipboard

Toggle word wrap

출력 예

Name:         allow-from-openshift-ingress
Namespace:    example1
Created on:   2020-06-09 00:28:17 -0400 EDT
Labels:       <none>
Annotations:  <none>
Spec:
  PodSelector:     <none> (Allowing the specific traffic to all pods in this namespace)
  Allowing ingress traffic:
    To Port: <any> (traffic allowed to all ports)
    From:
      NamespaceSelector: network.openshift.io/policy-group: ingress
  Not affecting egress traffic
  Policy Types: Ingress


Name:         allow-from-openshift-monitoring
Namespace:    example1
Created on:   2020-06-09 00:29:57 -0400 EDT
Labels:       <none>
Annotations:  <none>
Spec:
  PodSelector:     <none> (Allowing the specific traffic to all pods in this namespace)
  Allowing ingress traffic:
    To Port: <any> (traffic allowed to all ports)
    From:
      NamespaceSelector: network.openshift.io/policy-group: monitoring
  Not affecting egress traffic
  Policy Types: Ingress

Name:         allow-from-openshift-ingress
Namespace:    example1
Created on:   2020-06-09 00:28:17 -0400 EDT
Labels:       <none>
Annotations:  <none>
Spec:
  PodSelector:     <none> (Allowing the specific traffic to all pods in this namespace)
  Allowing ingress traffic:
    To Port: <any> (traffic allowed to all ports)
    From:
      NamespaceSelector: network.openshift.io/policy-group: ingress
  Not affecting egress traffic
  Policy Types: Ingress


Name:         allow-from-openshift-monitoring
Namespace:    example1
Created on:   2020-06-09 00:29:57 -0400 EDT
Labels:       <none>
Annotations:  <none>
Spec:
  PodSelector:     <none> (Allowing the specific traffic to all pods in this namespace)
  Allowing ingress traffic:
    To Port: <any> (traffic allowed to all ports)
    From:
      NamespaceSelector: network.openshift.io/policy-group: monitoring
  Not affecting egress traffic
  Policy Types: Ingress

Copy to Clipboard

Toggle word wrap

17.8.2. 다음 단계
링크 복사

기본 네트워크 정책 정의

18장. AWS Load Balancer Operator
링크 복사

18.1. OpenShift Container Platform의 AWS Load Balancer Operator
링크 복사

ALB(AWS Load Balancer) Operator는 aws-load-balancer-controller 의 인스턴스를 배포 및 관리합니다. OpenShift Container Platform 웹 콘솔 또는 CLI를 사용하여 OperatorHub에서 ALB Operator를 설치할 수 있습니다.

18.1.1. AWS Load Balancer Operator
링크 복사

kubernetes.io/role/elb 태그가 누락된 경우 AWS Load Balancer Operator에서 퍼블릭 서브넷에 태그를 지정할 수 있습니다. 또한 AWS Load Balancer Operator는 기본 AWS 클라우드에서 다음을 탐지합니다.

Operator를 호스팅하는 클러스터가 배포되는 VPC(가상 프라이빗 클라우드)의 ID입니다.
검색된 VPC의 퍼블릭 및 프라이빗 서브넷입니다.

사전 요구 사항

AWS 인증 정보 시크릿이 있어야 합니다. 인증 정보는 서브넷 태그 지정 및 VPC 검색을 제공하는 데 사용됩니다.

프로세스

Subscription 오브젝트를 생성하여 OperatorHub의 요구에 AWS Load Balancer Operator를 배포할 수 있습니다.

oc -n aws-load-balancer-operator get sub aws-load-balancer-operator --template='{{.status.installplan.name}}{{"\n"}}'

$ oc -n aws-load-balancer-operator get sub aws-load-balancer-operator --template='{{.status.installplan.name}}{{"\n"}}'

Copy to Clipboard

Toggle word wrap

출력 예

install-zlfbt

install-zlfbt

Copy to Clipboard

Toggle word wrap

설치 계획의 상태를 확인합니다. 설치 계획의 상태는 Complete 여야 합니다.

oc -n aws-load-balancer-operator get ip <install_plan_name> --template='{{.status.phase}}{{"\n"}}'

$ oc -n aws-load-balancer-operator get ip <install_plan_name> --template='{{.status.phase}}{{"\n"}}'

Copy to Clipboard

Toggle word wrap

출력 예

Complete

Complete

Copy to Clipboard

Toggle word wrap

oc get 명령을 사용하여 배포 상태를 확인합니다.

oc get -n aws-load-balancer-operator deployment/aws-load-balancer-operator-controller-manager

$ oc get -n aws-load-balancer-operator deployment/aws-load-balancer-operator-controller-manager

Copy to Clipboard

Toggle word wrap

출력 예

NAME                                           READY     UP-TO-DATE   AVAILABLE   AGE
aws-load-balancer-operator-controller-manager  1/1       1            1           23h

NAME                                           READY     UP-TO-DATE   AVAILABLE   AGE
aws-load-balancer-operator-controller-manager  1/1       1            1           23h

Copy to Clipboard

Toggle word wrap

18.1.2. AWS Load Balancer Operator 로그
링크 복사

oc logs 명령을 사용하여 AWS Load Balancer Operator 로그를 확인합니다.

프로세스

AWS Load Balancer Operator의 로그를 확인합니다.

oc logs -n aws-load-balancer-operator deployment/aws-load-balancer-operator-controller-manager -c manager

$ oc logs -n aws-load-balancer-operator deployment/aws-load-balancer-operator-controller-manager -c manager

Copy to Clipboard

Toggle word wrap

18.2. AWS Load Balancer Operator 이해
링크 복사

ALB(AWS Load Balancer) Operator는 aws-load-balancer-controller 리소스의 인스턴스를 배포 및 관리합니다. OpenShift Container Platform 웹 콘솔 또는 CLI를 사용하여 OperatorHub에서 AWS Load Balancer Operator를 설치할 수 있습니다.

중요

AWS Load Balancer Operator 배포는 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

18.2.1. AWS Load Balancer Operator 설치
링크 복사

OpenShift Container Platform 웹 콘솔을 사용하여 OperatorHub에서 AWS Load Balancer Operator를 설치할 수 있습니다.

사전 요구 사항

cluster-admin 권한이 있는 사용자로 OpenShift Container Platform 웹 콘솔에 로그인했습니다.

프로세스

OpenShift Container Platform 웹 콘솔에서 Operators → OperatorHub 로 이동합니다.
AWS Load Balancer Operator 를 선택합니다. 키워드로 필터링 텍스트 상자를 사용하거나 필터 목록을 사용하여 Operator 목록에서 AWS Load Balancer Operator를 검색할 수 있습니다.
aws-load-balancer-operator 네임스페이스를 선택합니다.
지침에 따라 Operator에서 설치를 준비합니다.
AWS Load Balancer Operator 페이지에서 설치를 클릭합니다.
Operator 설치 페이지에서 다음 옵션을 선택합니다.
1. 채널을 stable-v0.1 으로 업데이트합니다.
2. 클러스터의 특정 네임스페이스 로 설치 모드.
3. 설치된 네임스페이스를 aws-load-balancer-operator. aws-load-balancer-operator 네임스페이스가 없는 경우 Operator 설치 중에 생성됩니다.
4. 승인 업데이트를 자동 또는 수동으로 선택합니다. 기본적으로 업데이트 승인 은 자동으로 설정됩니다. 자동 업데이트를 선택하면 OLM(Operator Lifecycle Manager)에서 개입 없이 Operator의 실행 중인 인스턴스를 자동으로 업그레이드합니다. 수동 업데이트를 선택하면 OLM에서 업데이트 요청을 생성합니다. 클러스터 관리자는 Operator를 새 버전으로 업데이트하려면 해당 업데이트 요청을 수동으로 승인해야 합니다.
5. 설치를 클릭합니다.

검증

설치된 Operator 대시보드에서 AWS Load Balancer Operator에 상태가 Succeeded 로 표시되는지 확인합니다.

18.3. AWS 로드 밸런서 컨트롤러 인스턴스 생성
링크 복사

Operator를 설치한 후 AWS 로드 밸런서 컨트롤러의 인스턴스를 생성할 수 있습니다.

18.3.1. AWS Load Balancer Operator를 사용하여 AWS Load Balancer 컨트롤러 인스턴스 생성
링크 복사

클러스터에 aws-load-balancer-controller 의 단일 인스턴스만 설치할 수 있습니다. CLI를 사용하여 AWS Load Balancer 컨트롤러를 생성할 수 있습니다. AWS Load Balancer(ALB) Operator는 이름이 cluster 인 리소스만 조정합니다.

사전 요구 사항

echoserver 네임스페이스를 생성했습니다.
OpenShift CLI(oc)에 액세스할 수 있습니다.

프로세스

다음과 같이 aws-load-balancer-controller 리소스 YAML 파일을 생성합니다(예: sample-aws-lb.yaml ).
```
apiVersion: networking.olm.openshift.io/v1alpha1
kind: AWSLoadBalancerController 
metadata:
  name: cluster 
spec:
  subnetTagging: Auto 
  additionalResourceTags: 
    example.org/cost-center: 5113232
    example.org/security-scope: staging
  ingressClass: cloud 
  config:
    replicas: 2 
  enabledAddons: 
    - AWSWAFv2 
```
```
apiVersion: networking.olm.openshift.io/v1alpha1
kind: AWSLoadBalancerController 
```
1
```
metadata:
  name: cluster 
```
2
```
spec:
  subnetTagging: Auto 
```
3
```
  additionalResourceTags: 
```
4
```
    example.org/cost-center: 5113232
    example.org/security-scope: staging
  ingressClass: cloud 
```
5
```
  config:
    replicas: 2 
```
6
```
  enabledAddons: 
```
7
```
    - AWSWAFv2 
```
8
Copy to Clipboard Toggle word wrap
1
aws-load-balancer-controller 리소스를 정의합니다.
2
AWS Load Balancer Controller 인스턴스 이름을 정의합니다. 이 인스턴스 이름은 모든 관련 리소스에 접미사로 추가됩니다.
3
유효한 옵션은 Auto 및 Manual 입니다. 값을 Auto 로 설정하면 Operator에서 클러스터에 속하는 서브넷을 확인하고 적절하게 태그를 지정하려고 합니다. 내부 서브넷 태그가 내부 서브넷에 없는 경우 Operator에서 역할을 올바르게 결정할 수 없습니다. 사용자 제공 인프라에 클러스터를 설치하는 경우 적절한 역할 태그로 서브넷에 수동으로 태그를 지정하고 서브넷 태그 지정 정책을 Manual 로 설정할 수 있습니다.
4
AWS 리소스를 프로비저닝할 때 컨트롤러가 사용하는 태그를 정의합니다.
5
이 필드의 기본값은 alb 입니다. Operator는 이름이 없는 경우 IngressClass 리소스를 동일한 이름으로 프로비저닝합니다.
6
컨트롤러의 복제본 수를 지정합니다.
7
주석을 통해 지정된 AWS 로드 밸런서의 애드온을 지정합니다.
8
alb.ingress.kubernetes.io/wafv2-acl-arn 주석을 활성화합니다.
다음 명령을 실행하여 aws-load-balancer-controller 리소스를 생성합니다.
```
oc create -f sample-aws-lb.yaml
```
```
$ oc create -f sample-aws-lb.yaml
```
Copy to Clipboard Toggle word wrap

AWS 로드 밸런서 컨트롤러가 실행된 후 배포 리소스를 생성합니다.

apiVersion: apps/v1
kind: Deployment 
metadata:
  name: <echoserver> 
  namespace: echoserver
spec:
  selector:
    matchLabels:
      app: echoserver
  replicas: 3 
  template:
    metadata:
      labels:
        app: echoserver
    spec:
      containers:
        - image: openshift/origin-node
          args:
            - TCP4-LISTEN:8080,reuseaddr,fork
            - EXEC:'/bin/bash -c \"printf \\\"HTTP/1.0 200 OK\r\n\r\n\\\"; sed -e \\\"/^\r/q\\\"\"'
          imagePullPolicy: Always
          name: echoserver
          ports:
            - containerPort: 8080

apiVersion: apps/v1
kind: Deployment

1


metadata:
  name: <echoserver>

2


  namespace: echoserver
spec:
  selector:
    matchLabels:
      app: echoserver
  replicas: 3

3


  template:
    metadata:
      labels:
        app: echoserver
    spec:
      containers:
        - image: openshift/origin-node
          args:
            - TCP4-LISTEN:8080,reuseaddr,fork
            - EXEC:'/bin/bash -c \"printf \\\"HTTP/1.0 200 OK\r\n\r\n\\\"; sed -e \\\"/^\r/q\\\"\"'
          imagePullPolicy: Always
          name: echoserver
          ports:
            - containerPort: 8080

Copy to Clipboard

Toggle word wrap

1: 배포 리소스를 정의합니다.
2: 배포 이름을 지정합니다.
3: 배포 복제본 수를 지정합니다.

서비스 리소스를 생성합니다.

apiVersion: v1
kind: Service 
metadata:
  name: <echoserver> 
  namespace: echoserver
spec:
  ports:
    - port: 80
      targetPort: 8080
      protocol: TCP
  type: NodePort
  selector:
    app: echoserver

apiVersion: v1
kind: Service

1


metadata:
  name: <echoserver>

2


  namespace: echoserver
spec:
  ports:
    - port: 80
      targetPort: 8080
      protocol: TCP
  type: NodePort
  selector:
    app: echoserver

Copy to Clipboard

Toggle word wrap

1: 서비스 리소스를 정의합니다.
2: 서비스 이름을 지정합니다.

ALB 지원 Ingress 리소스를 배포합니다.

apiVersion: networking.k8s.io/v1
kind: Ingress 
metadata:
  name: <echoserver> 
  namespace: echoserver
  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: instance
spec:
  ingressClassName: alb
  rules:
    - http:
        paths:
          - path: /
            pathType: Exact
            backend:
              service:
                name: <echoserver> 
                port:
                  number: 80

apiVersion: networking.k8s.io/v1
kind: Ingress

1


metadata:
  name: <echoserver>

2


  namespace: echoserver
  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: instance
spec:
  ingressClassName: alb
  rules:
    - http:
        paths:
          - path: /
            pathType: Exact
            backend:
              service:
                name: <echoserver>

3


                port:
                  number: 80

Copy to Clipboard

Toggle word wrap

1: Ingress 리소스를 정의합니다.
2: Ingress 리소스의 이름을 지정합니다.
3: 서비스 리소스의 이름을 지정합니다.

검증

다음 명령을 실행하여 프로비저닝된 AWS Load Balancer(ALB) 호스트를 표시하는 Ingress 리소스의 상태를 확인합니다.

HOST=$(kubectl get ingress -n echoserver echoserver -o json | jq -r '.status.loadBalancer.ingress[0].hostname')

$ HOST=$(kubectl get ingress -n echoserver echoserver -o json | jq -r '.status.loadBalancer.ingress[0].hostname')

Copy to Clipboard

Toggle word wrap

다음 명령을 실행하여 프로비저닝된 AWS Load Balancer(ALB) 호스트의 상태를 확인합니다.
```
curl $HOST
```
```
$ curl $HOST
```
Copy to Clipboard Toggle word wrap

18.4. 여러 Ingress 생성
링크 복사

단일 AWS Load Balancer(ALB)를 통해 단일 도메인에 속하는 다른 서비스로 트래픽을 라우팅할 수 있습니다. 각 Ingress 리소스는 도메인의 다양한 끝점을 제공합니다.

18.4.1. 단일 AWS 로드 밸런서를 통해 여러 인그레스 생성
링크 복사

CLI를 사용하여 단일 AWS Load Balancer(ALB)를 통해 트래픽을 여러 Ingress로 라우팅할 수 있습니다.

사전 요구 사항

OpenShift CLI(oc)에 액세스할 수 있습니다.

프로세스

다음과 같이 IngressClassParams 리소스 YAML 파일을 생성합니다(예: sample-single-lb-params.yaml ).
```
apiVersion: elbv2.k8s.aws/v1beta1 
kind: IngressClassParams
metadata:
  name: <single-lb-params> 
spec:
  group:
    name: single-lb 
```
```
apiVersion: elbv2.k8s.aws/v1beta1 
```
1
```
kind: IngressClassParams
metadata:
  name: <single-lb-params> 
```
2
```
spec:
  group:
    name: single-lb 
```
3
Copy to Clipboard Toggle word wrap
1
IngressClassParams 리소스의 API 그룹 및 버전을 정의합니다.
2
IngressClassParams 리소스의 이름을 지정합니다.
3
IngressGroup 의 이름을 지정합니다. 이 클래스의 모든 Ingress는 이 IngressGroup 에 속합니다.
다음 명령을 실행하여 IngressClassParams 리소스를 생성합니다.
```
oc create -f sample-single-lb-params.yaml
```
```
$ oc create -f sample-single-lb-params.yaml
```
Copy to Clipboard Toggle word wrap
다음과 같이 IngressClass 리소스 YAML 파일을 생성합니다(예: sample-single-lb.yaml ).
```
apiVersion: networking.k8s.io/v1 
kind: IngressClass
metadata:
  name: <single-lb> 
spec:
  controller: ingress.k8s.aws/alb 
  parameters:
    apiGroup: elbv2.k8s.aws 
    kind: IngressClassParams 
    name: single-lb 
```
```
apiVersion: networking.k8s.io/v1 
```
1
```
kind: IngressClass
metadata:
  name: <single-lb> 
```
2
```
spec:
  controller: ingress.k8s.aws/alb 
```
3
```
  parameters:
    apiGroup: elbv2.k8s.aws 
```
4
```
    kind: IngressClassParams 
```
5
```
    name: single-lb 
```
6
Copy to Clipboard Toggle word wrap
1
API 그룹 및 IngressClass 리소스의 버전을 정의합니다.
2
IngressClass 의 이름을 지정합니다.
3
모든 IngressClasses 에 공통인 컨트롤러 이름을 정의합니다. aws-load-balancer-controller 가 컨트롤러를 조정합니다.
4
IngressClassParams 리소스의 API 그룹을 정의합니다.
5
IngressClassParams 리소스의 리소스 유형을 정의합니다.
6
IngressClassParams 리소스의 이름을 정의합니다.
다음 명령을 실행하여 IngressClass 리소스를 생성합니다.
```
oc create -f sample-single-lb.yaml
```
```
$ oc create -f sample-single-lb.yaml
```
Copy to Clipboard Toggle word wrap

다음과 같이 Ingress 리소스 YAML 파일을 생성합니다(예: sample-multiple-ingress.yaml ).

apiVersion: networking.k8s.io/v1 
kind: Ingress
metadata:
  name: <example-1> 
  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing 
    alb.ingress.kubernetes.io/group.order: "1" 
spec:
  ingressClass: alb 
  rules:
  - host: example.com 
    http:
        paths:
        - path: /blog 
          backend:
            service:
              name: <example-1> 
              port:
                number: 80 
kind: Ingress
metadata:
  name: <example-2>
  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/group.order: "2"
spec:
  ingressClass: alb
  rules:
  - host: example.com
    http:
        paths:
        - path: /store
          backend:
            service:
              name: <example-2>
              port:
                number: 80
kind: Ingress
  metadata:
  name: <example-3>
  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/group.order: "3"
spec:
  ingressClass: alb
  rules:
  - host: example.com
    http:
        paths:
        - path: /
          backend:
            service:
              name: <example-3>
              port:
                number: 80

apiVersion: networking.k8s.io/v1

1


kind: Ingress
metadata:
  name: <example-1>

2


  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing

3


    alb.ingress.kubernetes.io/group.order: "1"

4


spec:
  ingressClass: alb

5


  rules:
  - host: example.com

6


    http:
        paths:
        - path: /blog

7


          backend:
            service:
              name: <example-1>

8


              port:
                number: 80

9


kind: Ingress
metadata:
  name: <example-2>
  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/group.order: "2"
spec:
  ingressClass: alb
  rules:
  - host: example.com
    http:
        paths:
        - path: /store
          backend:
            service:
              name: <example-2>
              port:
                number: 80
kind: Ingress
  metadata:
  name: <example-3>
  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/group.order: "3"
spec:
  ingressClass: alb
  rules:
  - host: example.com
    http:
        paths:
        - path: /
          backend:
            service:
              name: <example-3>
              port:
                number: 80

Copy to Clipboard

Toggle word wrap

1 2: Ingress의 이름을 지정합니다.
3: 공용 서브넷에서 프로비저닝할 로드 밸런서를 나타내며 인터넷을 통해 액세스할 수 있도록 합니다.
4: 로드 밸런서에서 요청이 수신될 때 Ingress의 규칙과 일치하는 순서를 지정합니다.
5: 이 인그레스에 속하는 Ingress 클래스를 지정합니다.
6: 요청 라우팅에 사용되는 도메인의 이름을 정의합니다.
7: 서비스에 라우팅해야 하는 경로를 정의합니다.
8: Ingress에 구성된 끝점을 제공하는 서비스의 이름을 정의합니다.
9: 엔드포인트를 제공하는 서비스의 포트를 정의합니다.

다음 명령을 실행하여 Ingress 리소스를 생성합니다.
```
oc create -f sample-multiple-ingress.yaml
```
```
$ oc create -f sample-multiple-ingress.yaml
```
Copy to Clipboard Toggle word wrap

18.5. TLS 종료 추가
링크 복사

AWS 로드 밸런서에 TLS 종료를 추가할 수 있습니다.

18.5.1. AWS 로드 밸런서에 TLS 종료 추가
링크 복사

도메인의 트래픽을 서비스 Pod로 라우팅하고 AWS Load Balancer에서 TLS 종료를 추가할 수 있습니다.

사전 요구 사항

OpenShift CLI(oc)에 액세스할 수 있습니다.

절차

Operator를 설치하고 aws-load-balancer-controller 리소스의 인스턴스를 생성합니다.
```
apiVersion: networking.k8s.io/v1
kind: AWSLoadBalancerController
group: networking.olm.openshift.io/v1alpha1 
metadata:
  name: cluster 
spec:
  subnetTagging: auto
  ingressClass: tls-termination 
```
```
apiVersion: networking.k8s.io/v1
kind: AWSLoadBalancerController
group: networking.olm.openshift.io/v1alpha1 
```
1
```
metadata:
  name: cluster 
```
2
```
spec:
  subnetTagging: auto
  ingressClass: tls-termination 
```
3
Copy to Clipboard Toggle word wrap
1
aws-load-balancer-controller 리소스의 API 그룹을 정의합니다.
2
aws-load-balancer-controller 인스턴스를 정의합니다.
3
AWS 로드 밸런서 컨트롤러에서 조정한 ingressClass 리소스의 이름을 정의합니다. 이 ingressClass 리소스가 없으면 생성됩니다. ingressClass 값을 더 추가할 수 있습니다. spec.controller 가 ingress.k8s.aws/alb 로 설정된 경우 컨트롤러가 ingressClass 값을 조정합니다.

인그레스 리소스를 생성합니다.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: <example> 
  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing 
    alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:us-west-2:xxxxx 
spec:
  ingressClassName: tls-termination 
  rules:
  - host: <example.com> 
    http:
        paths:
          - path: /
            pathType: Exact
            backend:
              service:
                name: <example-service> 
                port:
                  number: 80

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: <example>

1


  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing

2


    alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:us-west-2:xxxxx

3


spec:
  ingressClassName: tls-termination

4


  rules:
  - host: <example.com>

5


    http:
        paths:
          - path: /
            pathType: Exact
            backend:
              service:
                name: <example-service>

6


                port:
                  number: 80

Copy to Clipboard

Toggle word wrap

1: Ingress의 이름을 지정합니다.
2: 컨트롤러는 인터넷을 통해 로드 밸런서에 연결할 수 있도록 이 Ingress 리소스의 로드 밸런서를 공용 서브넷에 프로비저닝합니다.
3: 로드 밸런서에 연결하는 인증서의 Amazon 리소스 이름입니다.
4: Ingress 클래스 이름을 정의합니다.
5: 트래픽 라우팅에 대한 도메인을 정의합니다.
6: 트래픽 라우팅에 대한 서비스를 정의합니다.

19장. 다중 네트워크
링크 복사

19.1. 다중 네트워크 이해하기
링크 복사

Kubernetes에서 컨테이너 네트워킹은 CNI(컨테이너 네트워크 인터페이스)를 구현하는 네트워킹 플러그인에 위임됩니다.

OpenShift Container Platform은 Multus CNI 플러그인을 사용하여 CNI 플러그인 체인을 허용합니다. 클러스터 설치 중에 기본 pod 네트워크를 구성합니다. 기본 네트워크는 클러스터의 모든 일반 네트워크 트래픽을 처리합니다. 사용 가능한 CNI 플러그인을 기반으로 추가 네트워크를 정의하고 이러한 네트워크 중 하나 이상을 Pod에 연결할 수 있습니다. 필요에 따라 클러스터에 2개 이상의 추가 네트워크를 정의 할 수 있습니다. 따라서 스위칭 또는 라우팅과 같은 네트워크 기능을 제공하는 pod를 구성할 때 유연성이 제공됩니다.

19.1.1. 추가 네트워크 사용 시나리오
링크 복사

데이터 플레인 및 컨트롤 플레인 분리를 포함하여 네트워크 격리가 필요한 상황에서 추가 네트워크를 사용할 수 있습니다. 네트워크 트래픽 격리는 다음과 같은 성능 및 보안상의 이유로 유용합니다.

성능: 각 플레인의 트래픽 수량을 관리하기 위해 두 개의 다른 플레인으로 트래픽을 보낼 수 있습니다.
보안: 보안 고려 사항을 위해 특별히 관리되는 네트워크 플레인으로 중요한 트래픽을 보낼 수 있으며 테넌트 또는 고객 간에 공유되지 않아야 하는 개인 데이터를 분리할 수 있습니다.

클러스터의 모든 pod는 여전히 클러스터 전체의 기본 네트워크를 사용하여 클러스터 전체의 연결을 유지합니다. 모든 pod에는 클러스터 전체 pod 네트워크에 연결된 eth0 인터페이스가 있습니다. oc exec -it <pod_name> -- ip a 명령을 사용하여 pod의 인터페이스를 확인할 수 있습니다. Multus CNI를 사용하는 네트워크 인터페이스를 추가하는 경우 이름은 net1, net2, … , netN입니다.

Pod에 추가 네트워크 인터페이스를 연결하려면 인터페이스 연결 방법을 정의하는 구성을 생성해야 합니다. NetworkAttachmentDefinition CR(사용자 정의 리소스)을 사용하여 각 인터페이스를 지정합니다. 각 CR 내부의 CNI 구성은 해당 인터페이스의 생성 방법을 정의합니다.

19.1.2. OpenShift Container Platform의 그룹은 중첩되지 않습니다.
링크 복사

OpenShift Container Platform은 클러스터에서 추가 네트워크를 생성하기 위해 다음 CNI 플러그인을 제공합니다.

bridge: 동일한 호스트의 Pod가 서로 그리고 호스트와 통신할 수 있도록브리지 기반 추가 네트워크를 구성합니다.
host-device: pod가호스트 시스템의 물리적 이더넷 네트워크 장치에 액세스할 수 있도록 호스트 장치 추가 네트워크를 구성합니다.
ipvlan: macvlan기반 추가 네트워크와 유사하게 호스트의 pod가 해당 호스트의 다른 호스트 및 pod와 통신할 수 있도록 ipvlan 기반 추가 네트워크를 구성합니다. macvlan 기반 추가 네트워크와 달리 각 pod는 상위 물리적 네트워크 인터페이스와 동일한 MAC 주소를 공유합니다.
macvlan: 물리적네트워크 인터페이스를 사용하여 호스트의 pod가 해당 호스트의 다른 호스트 및 pod와 통신할 수 있도록 macvlan 기반 추가 네트워크를 구성합니다. macvlan 기반 추가 네트워크에 연결된 각 pod에는 고유 한 MAC 주소가 제공됩니다.
SR-IOV: 호스트 시스템의SR-IOV 가능 하드웨어에서 pod를 VF(가상 기능) 인터페이스에 연결할 수 있도록 SR-IOV 기반 추가 네트워크를 구성합니다.

19.2. 추가 네트워크 구성
링크 복사

클러스터 관리자는 클러스터에 대한 추가 네트워크를 구성할 수 있습니다. 다음과 같은 네트워크 유형이 지원됩니다.

19.2.1. 추가 네트워크 관리 방법
링크 복사

두 가지 방법으로 추가 네트워크의 라이프사이클을 관리할 수 있습니다. 각 접근 방식은 상호 배타적이며 한 번에 추가 네트워크를 관리하는 데 하나의 방법만 사용할 수 있습니다. 두 방법 모두 추가 네트워크는 사용자가 구성하는 CNI(Container Network Interface) 플러그인에 의해 관리됩니다.

추가 네트워크의 경우 추가 네트워크의 일부로 구성하는 IPAM(IP 주소 관리) CNI 플러그인을 통해 IP 주소가 프로비저닝됩니다. IPAM 플러그인은 DHCP 및 고정 할당을 포함한 다양한 IP 주소 할당 방식을 지원합니다.

CNO(Cluster Network Operator) 설정을 수정합니다. CNO는 NetworkAttachmentDefinition 오브젝트를 자동으로 생성하고 관리합니다. CNO에서 오브젝트 라이프사이클을 관리하는 것 외에도 DHCP가 할당된 IP 주소를 사용하는 추가 네트워크에 DHCP를 사용할 수 있는지 확인합니다.
YAML 매니페스트 적용: NetworkAttachmentDefinition 오브젝트를 생성하여 직접 추가 네트워크를 관리할 수 있습니다. 이 방법을 사용하면 CNI 플러그인을 연결할 수 있습니다.

19.2.2. 추가 네트워크 연결을 위한 구성
링크 복사

추가 네트워크는 k8s.cni.cncf.io API 그룹의 NetworkAttachmentDefinition API를 통해 구성됩니다.

중요

이 정보가 프로젝트 관리 사용자가 액세스할 수 있으므로 중요한 정보 또는 시크릿을 NetworkAttachmentDefinition 오브젝트에 저장하지 마십시오.

API의 구성은 다음 표에 설명되어 있습니다.

Expand

표 19.1. NetworkAttachmentDefinition API 필드
필드	유형	설명
`metadata.name`	`string`	추가 네트워크의 이름입니다.
`metadata.namespace`	`string`	오브젝트와 연결된 네임스페이스입니다.
`spec.config`	`string`	JSON 형식의 CNI 플러그인 구성입니다.

19.2.2.1. Cluster Network Operator를 통한 추가 네트워크 구성
링크 복사

추가 네트워크 연결 구성은 CNO(Cluster Network Operator) 구성의 일부로 지정됩니다.

다음 YAML은 CNO를 사용하여 추가 네트워크를 관리하는 구성 매개변수를 설명합니다.

CNO(Cluster Network Operator) 구성

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  # ...
  additionalNetworks: 
  - name: <name> 
    namespace: <namespace> 
    rawCNIConfig: |- 
      {
        ...
      }
    type: Raw

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  # ...
  additionalNetworks:

1


  - name: <name>

2


    namespace: <namespace>

3


    rawCNIConfig: |-

4


      {
        ...
      }
    type: Raw

Copy to Clipboard

Toggle word wrap

1: 하나 이상의 추가 네트워크 구성으로 구성된 배열입니다.
2: 생성 중인 추가 네트워크 연결의 이름입니다. 이름은 지정된 namespace 내에서 고유해야 합니다.
3: 네트워크 연결을 생성할 네임스페이스입니다. 값을 지정하지 않으면 default 네임스페이스가 사용됩니다.
4: JSON 형식의 CNI 플러그인 구성입니다.

19.2.2.2. YAML 매니페스트에서 추가 네트워크 구성
링크 복사

추가 네트워크의 구성은 다음 예와 같이 YAML 구성 파일에서 지정됩니다.

apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
  name: <name> 
spec:
  config: |- 
    {
      ...
    }

apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
  name: <name>

1


spec:
  config: |-

2


    {
      ...
    }

Copy to Clipboard

Toggle word wrap

1: 생성 중인 추가 네트워크 연결의 이름입니다.
2: JSON 형식의 CNI 플러그인 구성입니다.

19.2.3. 추가 네트워크 유형의 구성
링크 복사

추가 네트워크의 특정 구성 필드는 다음 섹션에 설명되어 있습니다.

19.2.3.1. 브리지 추가 네트워크에 대한 구성
링크 복사

다음 오브젝트는 브릿지 CNI 플러그인의 구성 매개변수를 설명합니다.

Expand

표 19.2. 브릿지 CNI 플러그인 JSON 구성 오브젝트
필드	유형	설명
`cniVersion`	`string`	CNI 사양 버전입니다. `0.3.1` 값이 필요합니다.
`name`	`string`	CNO 구성에 대해 이전에 입력한 `name` 매개변수의 값입니다.
`type`	`string`
`bridge`	`string`	사용할 가상 브릿지의 이름을 지정합니다. 브릿지 인터페이스가 호스트에 없으면 생성됩니다. 기본값은 `cni0`입니다.
`ipam`	`object`	IPAM CNI 플러그인에 대한 구성 오브젝트입니다. 플러그인은 연결 정의에 대한 IP 주소 할당을 관리합니다.
`ipMasq`	`boolean`	가상 네트워크에서 전송되는 트래픽에 IP 마스커레이딩을 사용하려면 `true`로 설정합니다. 모든 트래픽의 소스 IP 주소가 브리지의 IP 주소로 다시 작성됩니다. 브리지에 IP 주소가 없으면 이 설정이 적용되지 않습니다. 기본값은 `false`입니다.
`isGateway`	`boolean`	브리지에 IP 주소를 할당하려면 `true`로 설정합니다. 기본값은 `false`입니다.
`isDefaultGateway`	`boolean`	브릿지를 가상 네트워크의 기본 게이트웨이로 구성하려면 `true`로 설정합니다. 기본값은 `false`입니다. `isDefaultGateway`가 `true`로 설정되면 `isGateway`도 자동으로 `true`로 설정됩니다.
`forceAddress`	`boolean`	이전에 할당된 IP 주소를 가상 브리지에 할당할 수 있도록 하려면 `true`로 설정합니다. `false`로 설정하면 중첩되는 하위 집합의 IPv4 주소 또는 IPv6 주소가 가상 브릿지에 지정되는 경우 오류가 발생합니다. 기본값은 `false`입니다.
`hairpinMode`	`boolean`	가상 브릿지가 수신한 가상 포트를 통해 이더넷 프레임을 다시 보낼 수 있도록 하려면 `true` 로 설정합니다. 이 모드를 반사 릴레이라고도 합니다. 기본값은 `false`입니다.
`promiscMode`	`boolean`	브릿지에서 무차별 모드를 사용하려면 `true`로 설정합니다. 기본값은 `false`입니다.
`vlan`	`string`	VLAN(가상 LAN) 태그를 정수 값으로 지정합니다. 기본적으로 VLAN 태그는 할당되지 않습니다.
`mtu`	`string`	최대 전송 단위(MTU)를 지정된 값으로 설정합니다. 기본값은 커널에 의해 자동으로 설정됩니다.

19.2.3.1.1. 브릿지 구성 예
링크 복사

다음 예제는 이름이 bridge-net인 추가 네트워크를 구성합니다.

{
  "cniVersion": "0.3.1",
  "name": "work-network",
  "type": "bridge",
  "isGateway": true,
  "vlan": 2,
  "ipam": {
    "type": "dhcp"
    }
}

{
  "cniVersion": "0.3.1",
  "name": "work-network",
  "type": "bridge",
  "isGateway": true,
  "vlan": 2,
  "ipam": {
    "type": "dhcp"
    }
}

Copy to Clipboard

Toggle word wrap

19.2.3.2. 호스트 장치 추가 네트워크에 대한 구성
링크 복사

참고

device, hwaddr, kernelpath 또는 pciBusID 매개변수 중 하나만 설정하여 네트워크 장치를 지정합니다.

다음 오브젝트는 호스트 장치 CNI 플러그인의 구성 매개변수를 설명합니다.

Expand

표 19.3. 호스트 장치 CNI 플러그인 JSON 구성 오브젝트
필드	유형	설명
`cniVersion`	`string`	CNI 사양 버전입니다. `0.3.1` 값이 필요합니다.
`name`	`string`	CNO 구성에 대해 이전에 입력한 `name` 매개변수의 값입니다.
`type`	`string`	구성할 CNI 플러그인의 이름: `호스트 장치`.
`device`	`string`	선택사항: 장치 이름(예: `eth0` )입니다.
`hwaddr`	`string`	선택사항: 장치 하드웨어 MAC 주소입니다.
`kernelpath`	`string`	선택 사항: `/sys/devices/pci0000:00/0000:00:1f.6` 과 같은 Linux 커널 장치 경로입니다.
`pciBusID`	`string`	선택 사항: 네트워크 장치의 PCI 주소입니다(예: `0000:00:1f.6` ).

19.2.3.2.1. 호스트 장치 구성 예
링크 복사

다음 예제는 이름이 hostdev-net인 추가 네트워크를 구성합니다.

{
  "cniVersion": "0.3.1",
  "name": "work-network",
  "type": "host-device",
  "device": "eth1"
}

{
  "cniVersion": "0.3.1",
  "name": "work-network",
  "type": "host-device",
  "device": "eth1"
}

Copy to Clipboard

Toggle word wrap

19.2.3.3. IPVLAN 추가 네트워크를 위한 구성
링크 복사

다음 오브젝트는 IPVLAN CNI 플러그인의 구성 매개변수를 설명합니다.

Expand

표 19.4. IPVLAN CNI 플러그인 JSON 구성 오브젝트
필드	유형	설명
`cniVersion`	`string`	CNI 사양 버전입니다. `0.3.1` 값이 필요합니다.
`name`	`string`	CNO 구성에 대해 이전에 입력한 `name` 매개변수의 값입니다.
`type`	`string`	구성할 CNI 플러그인의 이름: `ipvlan`.
`mode`	`string`	가상 네트워크의 운영 모드입니다. 값은 `l2`, `l3` 또는 `l3s`여야 합니다. 기본값은 `l2`입니다.
`master`	`string`	네트워크 연결과 연결할 이더넷 인터페이스입니다. `마스터`를 지정하지 않으면 기본 네트워크 경로에 대한 인터페이스가 사용됩니다.
`mtu`	`integer`	최대 전송 단위(MTU)를 지정된 값으로 설정합니다. 기본값은 커널에 의해 자동으로 설정됩니다.
`ipam`	`object`	IPAM CNI 플러그인에 대한 구성 오브젝트입니다. 플러그인은 연결 정의에 대한 IP 주소 할당을 관리합니다. `dhcp` 를 지정하지 마십시오. IPVLAN 인터페이스가 호스트 인터페이스와 MAC 주소를 공유하므로 DHCP를 사용하여 IPVLAN 구성은 지원되지 않습니다.

19.2.3.3.1. ipvlan 구성 예
링크 복사

다음 예제는 이름이 ipvlan-net인 추가 네트워크를 구성합니다.

{
  "cniVersion": "0.3.1",
  "name": "work-network",
  "type": "ipvlan",
  "master": "eth1",
  "mode": "l3",
  "ipam": {
    "type": "static",
    "addresses": [
       {
         "address": "192.168.10.10/24"
       }
    ]
  }
}

{
  "cniVersion": "0.3.1",
  "name": "work-network",
  "type": "ipvlan",
  "master": "eth1",
  "mode": "l3",
  "ipam": {
    "type": "static",
    "addresses": [
       {
         "address": "192.168.10.10/24"
       }
    ]
  }
}

Copy to Clipboard

Toggle word wrap

19.2.3.4. MACVLAN 추가 네트워크 구성
링크 복사

다음 오브젝트는 macvlan CNI 플러그인의 구성 매개변수를 설명합니다.

Expand

표 19.5. MACVLAN CNI 플러그인 JSON 구성 오브젝트
필드	유형	설명
`cniVersion`	`string`	CNI 사양 버전입니다. `0.3.1` 값이 필요합니다.
`name`	`string`	CNO 구성에 대해 이전에 입력한 `name` 매개변수의 값입니다.
`type`	`string`	구성할 CNI 플러그인의 이름입니다. `macvlan`.
`mode`	`string`	가상 네트워크에서 트래픽 가시성을 구성합니다. `bridge`, `passthru`, `private` 또는 `vepa` 중 하나여야 합니다. 값을 입력하지 않으면 기본값은 `bridge`입니다.
`master`	`string`	새로 생성된 macvlan 인터페이스와 연결할 호스트 네트워크 인터페이스입니다. 값을 지정하지 않으면 기본 경로 인터페이스가 사용됩니다.
`mtu`	`string`	지정된 값에 대한 최대 전송 단위(MTU)입니다. 기본값은 커널에 의해 자동으로 설정됩니다.
`ipam`	`object`	IPAM CNI 플러그인에 대한 구성 오브젝트입니다. 플러그인은 연결 정의에 대한 IP 주소 할당을 관리합니다.

참고

플러그인 구성에 대한 마스터 키를 지정하는 경우, 가능한 충돌을 방지하려면 기본 네트워크 플러그인과 연결된 것과 다른 물리적 네트워크 인터페이스를 사용합니다.

19.2.3.4.1. macvlan 구성 예
링크 복사

다음 예제는 이름이 macvlan-net인 추가 네트워크를 구성합니다.

{
  "cniVersion": "0.3.1",
  "name": "macvlan-net",
  "type": "macvlan",
  "master": "eth1",
  "mode": "bridge",
  "ipam": {
    "type": "dhcp"
    }
}

{
  "cniVersion": "0.3.1",
  "name": "macvlan-net",
  "type": "macvlan",
  "master": "eth1",
  "mode": "bridge",
  "ipam": {
    "type": "dhcp"
    }
}

Copy to Clipboard

Toggle word wrap

19.2.4. 추가 네트워크에 대한 IP 주소 할당 구성
링크 복사

IP 주소 관리(IPAM) CNI(Container Network Interface) 플러그인은 다른 CNI 플러그인에 대한 IP 주소를 제공합니다.

다음 IP 주소 할당 유형을 사용할 수 있습니다.

정적 할당
DHCP 서버를 통한 동적 할당. 지정한 DHCP 서버는 추가 네트워크에서 연결할 수 있어야 합니다.
Whereabouts IPAM CNI 플러그인을 통한 동적 할당

19.2.4.1. 고정 IP 주소 할당 구성
링크 복사

다음 표에서는 고정 IP 주소 할당 구성에 대해 설명합니다.

Expand

표 19.6. IPAM 고정 구성 오브젝트
필드	유형	설명
`type`	`string`	IPAM 주소 유형입니다. `static` 값이 필요합니다.
`주소`	`array`	가상 인터페이스에 할당할 IP 주소를 지정하는 개체의 배열입니다. IPv4 및 IPv6 IP 주소가 모두 지원됩니다.
`routes`	`array`	Pod 내부에서 구성할 경로를 지정하는 오브젝트의 배열입니다.
`dns`	`array`	선택 사항: DNS 구성을 지정하는 오브젝트의 배열입니다.

addresses 배열에는 다음 필드가 있는 오브젝트가 필요합니다.

Expand

표 19.7. ipam.addresses[] array
필드	유형	설명
`주소`	`string`	지정하는 IP 주소 및 네트워크 접두사입니다. 예를 들어 `10.10.21.10/24`를 지정하면 추가 네트워크에 IP 주소 `10.10.21.10`이 할당되고 넷마스크는 `255.255.255.0`입니다.
`gateway`	`string`	송신 네트워크 트래픽을 라우팅할 기본 게이트웨이입니다.

Expand

표 19.8. ipam.routes[] array
필드	유형	설명
`dst`	`string`	CIDR 형식의 IP 주소 범위(예: 기본 경로의 경우 `192.168.17.0/24` 또는 `0.0.0.0/0` )입니다.
`gw`	`string`	네트워크 트래픽이 라우팅되는 게이트웨이입니다.

Expand

표 19.9. ipam.dns object
필드	유형	설명
`nameservers`	`array`	DNS 쿼리를 보낼 하나 이상의 IP 주소로 구성된 배열입니다.
`domain`	`array`	호스트 이름에 추가할 기본 도메인입니다. 예를 들어 도메인이 `example.com`으로 설정되면 `example-host`에 대한 DNS 조회 쿼리가 `example-host.example.com`으로 다시 작성됩니다.
`search`	`array`	DNS 조회 쿼리 중에 규정되지 않은 호스트 이름(예: `example-host`)에 추가할 도메인 이름 배열입니다.

고정 IP 주소 할당 구성 예

{
  "ipam": {
    "type": "static",
      "addresses": [
        {
          "address": "191.168.1.7/24"
        }
      ]
  }
}

{
  "ipam": {
    "type": "static",
      "addresses": [
        {
          "address": "191.168.1.7/24"
        }
      ]
  }
}

Copy to Clipboard

Toggle word wrap

19.2.4.2. DHCP(Dynamic IP 주소) 할당 구성
링크 복사

다음 JSON은 DHCP를 사용한 동적 IP 주소 할당 구성을 설명합니다.

DHCP 리스 갱신

pod는 생성될 때 원래 DHCP 리스를 얻습니다. 리스는 클러스터에서 실행되는 최소 DHCP 서버 배포를 통해 주기적으로 갱신되어야 합니다.

DHCP 서버 배포를 트리거하려면 다음 예와 같이 Cluster Network Operator 구성을 편집하여 shim 네트워크 연결을 만들어야 합니다.

shim 네트워크 연결 정의 예

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  additionalNetworks:
  - name: dhcp-shim
    namespace: default
    type: Raw
    rawCNIConfig: |-
      {
        "name": "dhcp-shim",
        "cniVersion": "0.3.1",
        "type": "bridge",
        "ipam": {
          "type": "dhcp"
        }
      }
  # ...

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  additionalNetworks:
  - name: dhcp-shim
    namespace: default
    type: Raw
    rawCNIConfig: |-
      {
        "name": "dhcp-shim",
        "cniVersion": "0.3.1",
        "type": "bridge",
        "ipam": {
          "type": "dhcp"
        }
      }
  # ...

Copy to Clipboard

Toggle word wrap

Expand

표 19.10. IPAM DHCP 구성 오브젝트
필드	유형	설명
`type`	`string`	IPAM 주소 유형입니다. 값 `dhcp` 가 필요합니다.

DHCP(Dynamic IP 주소) 할당 구성 예

{
  "ipam": {
    "type": "dhcp"
  }
}

{
  "ipam": {
    "type": "dhcp"
  }
}

Copy to Clipboard

Toggle word wrap

19.2.4.3. Whereabouts를 사용한 동적 IP 주소 할당 구성
링크 복사

Whereabouts CNI 플러그인을 사용하면 DHCP 서버를 사용하지 않고도 IP 주소를 추가 네트워크에 동적으로 할당할 수 있습니다.

다음 표에서는 Whereabouts를 사용한 동적 IP 주소 할당 구성을 설명합니다.

Expand

표 19.11. IPAM 위치 구성 오브젝트
필드	유형	설명
`type`	`string`	IPAM 주소 유형입니다. 값 `whereabouts` 가 필요합니다.
`범위`	`string`	CIDR 표기법의 IP 주소 및 범위입니다. IP 주소는 이 주소 범위 내에서 할당됩니다.
`exclude`	`array`	선택 사항: CIDR 표기법으로 0개 이상의 IP 주소 및 범위 목록입니다. 제외된 주소 범위 내의 IP 주소는 할당되지 않습니다.

Whereabouts를 사용하는 동적 IP 주소 할당 구성 예

{
  "ipam": {
    "type": "whereabouts",
    "range": "192.0.2.192/27",
    "exclude": [
       "192.0.2.192/30",
       "192.0.2.196/32"
    ]
  }
}

{
  "ipam": {
    "type": "whereabouts",
    "range": "192.0.2.192/27",
    "exclude": [
       "192.0.2.192/30",
       "192.0.2.196/32"
    ]
  }
}

Copy to Clipboard

Toggle word wrap

19.2.5. Cluster Network Operator를 사용하여 추가 네트워크 연결 생성
링크 복사

CNO(Cluster Network Operator)는 추가 네트워크 정의를 관리합니다. 생성할 추가 네트워크를 지정하면 CNO가 NetworkAttachmentDefinition 오브젝트를 자동으로 생성합니다.

중요

Cluster Network Operator가 관리하는 NetworkAttachmentDefinition 오브젝트를 편집하지 마십시오. 편집하면 추가 네트워크의 네트워크 트래픽이 중단될 수 있습니다.

사전 요구 사항

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

절차

선택 사항: 추가 네트워크의 네임스페이스를 생성합니다.
```
oc create namespace <namespace_name>
```
```
$ oc create namespace <namespace_name>
```
Copy to Clipboard Toggle word wrap
CNO 구성을 편집하려면 다음 명령을 입력합니다.
```
oc edit networks.operator.openshift.io cluster
```
```
$ oc edit networks.operator.openshift.io cluster
```
Copy to Clipboard Toggle word wrap

다음 예제 CR과 같이 생성 중인 추가 네트워크의 구성을 추가하여 생성 중인 CR을 수정합니다.

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  # ...
  additionalNetworks:
  - name: tertiary-net
    namespace: namespace2
    type: Raw
    rawCNIConfig: |-
      {
        "cniVersion": "0.3.1",
        "name": "tertiary-net",
        "type": "ipvlan",
        "master": "eth1",
        "mode": "l2",
        "ipam": {
          "type": "static",
          "addresses": [
            {
              "address": "192.168.1.23/24"
            }
          ]
        }
      }

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  # ...
  additionalNetworks:
  - name: tertiary-net
    namespace: namespace2
    type: Raw
    rawCNIConfig: |-
      {
        "cniVersion": "0.3.1",
        "name": "tertiary-net",
        "type": "ipvlan",
        "master": "eth1",
        "mode": "l2",
        "ipam": {
          "type": "static",
          "addresses": [
            {
              "address": "192.168.1.23/24"
            }
          ]
        }
      }

Copy to Clipboard

Toggle word wrap

변경 사항을 저장하고 텍스트 편집기를 종료하여 변경 사항을 커밋합니다.

검증

CNO가 다음 명령을 실행하여 NetworkAttachmentDefinition 오브젝트를 생성했는지 확인합니다. CNO가 오브젝트를 생성하기 전에 지연이 발생할 수 있습니다.
```
oc get network-attachment-definitions -n <namespace>
```
```
$ oc get network-attachment-definitions -n <namespace>
```
Copy to Clipboard Toggle word wrap
다음과 같습니다.
<namespace>
CNO 구성에 추가한 네트워크 연결의 네임스페이스를 지정합니다.
출력 예
```
NAME                 AGE
test-network-1       14m
```
```
NAME                 AGE
test-network-1       14m
```
Copy to Clipboard Toggle word wrap

19.2.6. YAML 매니페스트를 적용하여 추가 네트워크 연결 생성
링크 복사

사전 요구 사항

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

절차

다음 예와 같이 추가 네트워크 구성을 사용하여 YAML 파일을 생성합니다.

apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
  name: next-net
spec:
  config: |-
    {
      "cniVersion": "0.3.1",
      "name": "work-network",
      "type": "host-device",
      "device": "eth1",
      "ipam": {
        "type": "dhcp"
      }
    }

apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
  name: next-net
spec:
  config: |-
    {
      "cniVersion": "0.3.1",
      "name": "work-network",
      "type": "host-device",
      "device": "eth1",
      "ipam": {
        "type": "dhcp"
      }
    }

Copy to Clipboard

Toggle word wrap

추가 네트워크를 생성하려면 다음 명령을 입력합니다.
```
oc apply -f <file>.yaml
```
```
$ oc apply -f <file>.yaml
```
Copy to Clipboard Toggle word wrap
다음과 같습니다.
<file>
YAML 매니페스트가 포함된 파일의 이름을 지정합니다.

19.3. 가상 라우팅 및 전달 정보
링크 복사

19.3.1. 가상 라우팅 및 전달 정보
링크 복사

IP 규칙과 결합된 가상 라우팅 및 전달(VRF) 장치는 가상 라우팅 및 전달 도메인을 생성하는 기능을 제공합니다. VRF는 CNF에 필요한 권한 수를 줄이고 보조 네트워크의 네트워크 토폴로지의 가시성을 증대시킵니다. VRF는 예를 들어 각 테넌트마다 고유한 라우팅 테이블이 있고 다른 기본 게이트웨이가 필요한 멀티 테넌시 기능을 제공하는 데 사용됩니다.

프로세스는 소켓을 VRF 장치에 바인딩할 수 있습니다. 바인딩된 소켓을 통한 패킷은 VRF 장치와 연결된 라우팅 테이블을 사용합니다. VRF의 중요한 기능은 OSI 모델 레이어 3 트래픽 및 LLDP와 같은 L2 도구에만 영향을 미치지 않는다는 것입니다. 이를 통해 정책 기반 라우팅과 같은 우선순위가 높은 IP 규칙이 특정 트래픽을 지시하는 VRF 장치 규칙보다 우선합니다.

19.3.1.1. 통신 운영자의 포드에 대한 보조 네트워크 이점
링크 복사

통신사용 사례에서 각 CNF는 동일한 주소 공간을 공유하는 여러 다른 네트워크에 잠재적으로 연결할 수 있습니다. 이러한 보조 네트워크는 클러스터의 기본 네트워크 CIDR과 잠재적으로 충돌할 수 있습니다. CNI VRF 플러그인을 사용하여 네트워크 기능은 동일한 IP 주소를 사용하여 다른 고객의 인프라에 연결할 수 있으므로 서로 다른 고객을 분리할 수 있습니다. IP 주소는 OpenShift Container Platform IP 공간과 겹치게 됩니다. CNI VRF 플러그인은 CNF에 필요한 권한 수를 줄이고 보조 네트워크의 네트워크 토폴로지의 가시성을 높입니다.

19.4. 다중 네트워크 정책 구성
링크 복사

클러스터 관리자는 추가 네트워크에 대한 네트워크 정책을 구성할 수 있습니다.

참고

macvlan 추가 네트워크에 대해서만 다중 네트워크 정책을 지정할 수 있습니다. ipvlan과 같은 기타 유형의 추가 네트워크는 지원되지 않습니다.

19.4.1. 다중 네트워크 정책과 네트워크 정책의 차이점
링크 복사

MultiNetworkPolicy API는 NetworkPolicy API를 구현하지만 다음과 같은 몇 가지 중요한 차이점이 있습니다.

MultiNetworkPolicy API를 사용해야 합니다.

apiVersion: k8s.cni.cncf.io/v1beta1
kind: MultiNetworkPolicy

apiVersion: k8s.cni.cncf.io/v1beta1
kind: MultiNetworkPolicy

Copy to Clipboard

Toggle word wrap

CLI를 사용하여 다중 네트워크 정책과 상호 작용할 때 multi-networkpolicy 리소스 이름을 사용해야 합니다. 예를 들어 oc get multi-networkpolicy <name> 명령을 사용하여 다중 네트워크 정책 오브젝트를 볼 수 있습니다. 여기서 <name>은 다중 네트워크 정책의 이름입니다.

macvlan 추가 네트워크를 정의하는 네트워크 연결 정의의 이름으로 주석을 지정해야 합니다.

apiVersion: k8s.cni.cncf.io/v1beta1
kind: MultiNetworkPolicy
metadata:
  annotations:
    k8s.v1.cni.cncf.io/policy-for: <network_name>

apiVersion: k8s.cni.cncf.io/v1beta1
kind: MultiNetworkPolicy
metadata:
  annotations:
    k8s.v1.cni.cncf.io/policy-for: <network_name>

Copy to Clipboard

Toggle word wrap

다음과 같습니다.

<network_name>: 네트워크 연결 정의의 이름을 지정합니다.

19.4.2. 클러스터의 다중 네트워크 정책 활성화
링크 복사

클러스터 관리자는 클러스터에서 다중 네트워크 정책 지원을 활성화할 수 있습니다.

사전 요구 사항

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

프로세스

다음 YAML을 사용하여 multinetwork-enable-patch.yaml 파일을 생성합니다.

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  useMultiNetworkPolicy: true

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  useMultiNetworkPolicy: true

Copy to Clipboard

Toggle word wrap

다중 네트워크 정책을 활성화하도록 클러스터를 구성합니다.

oc patch network.operator.openshift.io cluster --type=merge --patch-file=multinetwork-enable-patch.yaml

$ oc patch network.operator.openshift.io cluster --type=merge --patch-file=multinetwork-enable-patch.yaml

Copy to Clipboard

Toggle word wrap

출력 예

network.operator.openshift.io/cluster patched

network.operator.openshift.io/cluster patched

Copy to Clipboard

Toggle word wrap

19.4.3. 다중 네트워크 정책 작업
링크 복사

클러스터 관리자는 다중 네트워크 정책을 생성, 편집, 보기 및 삭제할 수 있습니다.

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

클러스터에 대한 다중 네트워크 정책 지원을 활성화했습니다.

19.4.3.2. CLI를 사용하여 다중 네트워크 정책 생성
링크 복사

클러스터의 네임스페이스에서 허용된 수신 또는 송신 네트워크 트래픽을 설명하는 세분화된 규칙을 정의하기 위해 다중 네트워크 정책을 생성할 수 있습니다.

사전 요구 사항

클러스터는 NetworkPolicy 오브젝트를 지원하는 클러스터 네트워크 공급자(예: mode: NetworkPolicy 로 설정된 OpenShift SDN 네트워크 공급자)를 사용합니다. 이 모드는 OpenShift SDN의 기본값입니다.
OpenShift CLI(oc)를 설치합니다.
cluster-admin 권한이 있는 사용자로 클러스터에 로그인합니다.
다중 네트워크 정책이 적용되는 네임스페이스에서 작업하고 있습니다.

프로세스

다음과 같이 정책 규칙을 생성합니다.

<policy_name>.yaml 파일을 생성합니다.
```
touch <policy_name>.yaml
```
```
$ touch <policy_name>.yaml
```
Copy to Clipboard Toggle word wrap
다음과 같습니다.
<policy_name>
다중 네트워크 정책 파일 이름을 지정합니다.

방금 만든 파일에서 다음 예와 같이 다중 네트워크 정책을 정의합니다.

모든 네임스페이스의 모든 Pod에서 수신 거부

apiVersion: k8s.cni.cncf.io/v1beta1
kind: MultiNetworkPolicy
metadata:
  name: deny-by-default
  annotations:
    k8s.v1.cni.cncf.io/policy-for: <network_name>
spec:
  podSelector:
  ingress: []

apiVersion: k8s.cni.cncf.io/v1beta1
kind: MultiNetworkPolicy
metadata:
  name: deny-by-default
  annotations:
    k8s.v1.cni.cncf.io/policy-for: <network_name>
spec:
  podSelector:
  ingress: []

Copy to Clipboard

Toggle word wrap

다음과 같습니다.

<network_name>: 네트워크 연결 정의의 이름을 지정합니다.

동일한 네임 스페이스에 있는 모든 Pod의 수신 허용

apiVersion: k8s.cni.cncf.io/v1beta1
kind: MultiNetworkPolicy
metadata:
  name: allow-same-namespace
  annotations:
    k8s.v1.cni.cncf.io/policy-for: <network_name>
spec:
  podSelector:
  ingress:
  - from:
    - podSelector: {}

apiVersion: k8s.cni.cncf.io/v1beta1
kind: MultiNetworkPolicy
metadata:
  name: allow-same-namespace
  annotations:
    k8s.v1.cni.cncf.io/policy-for: <network_name>
spec:
  podSelector:
  ingress:
  - from:
    - podSelector: {}

Copy to Clipboard

Toggle word wrap

다음과 같습니다.

<network_name>: 네트워크 연결 정의의 이름을 지정합니다.

다음 명령을 실행하여 다중 네트워크 정책 오브젝트를 생성합니다.
```
oc apply -f <policy_name>.yaml -n <namespace>
```
```
$ oc apply -f <policy_name>.yaml -n <namespace>
```
Copy to Clipboard Toggle word wrap
다음과 같습니다.
<policy_name>
다중 네트워크 정책 파일 이름을 지정합니다.
<namespace>
선택 사항: 오브젝트가 현재 네임스페이스와 다른 네임스페이스에 정의된 경우 이를 사용하여 네임스페이스를 지정합니다.
출력 예
```
multinetworkpolicy.k8s.cni.cncf.io/default-deny created
```
```
multinetworkpolicy.k8s.cni.cncf.io/default-deny created
```
Copy to Clipboard Toggle word wrap

참고

cluster-admin 권한을 사용하여 웹 콘솔에 로그인하면 클러스터의 모든 네임스페이스에서 YAML 또는 웹 콘솔의 양식에서 직접 네트워크 정책을 생성할 수 있습니다.

19.4.3.3. 다중 네트워크 정책 편집
링크 복사

네임스페이스에서 다중 네트워크 정책을 편집할 수 있습니다.

사전 요구 사항

클러스터는 NetworkPolicy 오브젝트를 지원하는 클러스터 네트워크 공급자(예: mode: NetworkPolicy 로 설정된 OpenShift SDN 네트워크 공급자)를 사용합니다. 이 모드는 OpenShift SDN의 기본값입니다.
OpenShift CLI(oc)를 설치합니다.
cluster-admin 권한이 있는 사용자로 클러스터에 로그인합니다.
다중 네트워크 정책이 적용되는 네임스페이스에서 작업하고 있습니다.

프로세스

선택 사항: 네임스페이스의 다중 네트워크 정책 오브젝트를 나열하려면 다음 명령을 입력합니다.
```
oc get multi-networkpolicy
```
```
$ oc get multi-networkpolicy
```
Copy to Clipboard Toggle word wrap
다음과 같습니다.
<namespace>
선택 사항: 오브젝트가 현재 네임스페이스와 다른 네임스페이스에 정의된 경우 이를 사용하여 네임스페이스를 지정합니다.
다중 네트워크 정책 오브젝트를 편집합니다.
- 다중 네트워크 정책 정의를 파일에 저장한 경우 파일을 편집하고 필요한 사항을 변경한 후 다음 명령을 입력합니다.
  $ oc apply -n <namespace> -f <policy_file>.yaml
  Copy to Clipboard Toggle word wrap
  다음과 같습니다.
  <namespace>
  선택 사항: 오브젝트가 현재 네임스페이스와 다른 네임스페이스에 정의된 경우 이를 사용하여 네임스페이스를 지정합니다.
  <policy_file>
  네트워크 정책이 포함된 파일의 이름을 지정합니다.
- 다중 네트워크 정책 오브젝트를 직접 업데이트해야 하는 경우 다음 명령을 입력합니다.
  $ oc edit multi-networkpolicy <policy_name> -n <namespace>
  Copy to Clipboard Toggle word wrap
  다음과 같습니다.
  <policy_name>
  네트워크 정책의 이름을 지정합니다.
  <namespace>
  선택 사항: 오브젝트가 현재 네임스페이스와 다른 네임스페이스에 정의된 경우 이를 사용하여 네임스페이스를 지정합니다.
다중 네트워크 정책 오브젝트가 업데이트되었는지 확인합니다.
```
oc describe multi-networkpolicy <policy_name> -n <namespace>
```
```
$ oc describe multi-networkpolicy <policy_name> -n <namespace>
```
Copy to Clipboard Toggle word wrap
다음과 같습니다.
<policy_name>
다중 네트워크 정책의 이름을 지정합니다.
<namespace>
선택 사항: 오브젝트가 현재 네임스페이스와 다른 네임스페이스에 정의된 경우 이를 사용하여 네임스페이스를 지정합니다.

참고

cluster-admin 권한을 사용하여 웹 콘솔에 로그인하면 클러스터의 모든 네임스페이스에서 YAML에서 직접 또는 작업 메뉴를 통해 웹 콘솔의 정책에서 네트워크 정책을 편집할 수 있습니다.

19.4.3.4. CLI를 사용하여 다중 네트워크 정책 보기
링크 복사

네임스페이스에서 다중 네트워크 정책을 검사할 수 있습니다.

사전 요구 사항

OpenShift CLI(oc)를 설치합니다.
cluster-admin 권한이 있는 사용자로 클러스터에 로그인합니다.
다중 네트워크 정책이 적용되는 네임스페이스에서 작업하고 있습니다.

프로세스

네임스페이스의 다중 네트워크 정책을 나열합니다.
- 네임스페이스에 정의된 다중 네트워크 정책 오브젝트를 보려면 다음 명령을 입력합니다.
  $ oc get multi-networkpolicy
  Copy to Clipboard Toggle word wrap
- 선택 사항: 특정 다중 네트워크 정책을 검사하려면 다음 명령을 입력합니다.
  $ oc describe multi-networkpolicy <policy_name> -n <namespace>
  Copy to Clipboard Toggle word wrap
  다음과 같습니다.
  <policy_name>
  검사할 다중 네트워크 정책의 이름을 지정합니다.
  <namespace>
  선택 사항: 오브젝트가 현재 네임스페이스와 다른 네임스페이스에 정의된 경우 이를 사용하여 네임스페이스를 지정합니다.

참고

cluster-admin 권한을 사용하여 웹 콘솔에 로그인하면 클러스터의 모든 네임스페이스에서 YAML 또는 웹 콘솔의 양식에서 직접 네트워크 정책을 볼 수 있습니다.

19.4.3.5. CLI를 사용하여 다중 네트워크 정책 삭제
링크 복사

네임스페이스에서 다중 네트워크 정책을 삭제할 수 있습니다.

사전 요구 사항

클러스터는 NetworkPolicy 오브젝트를 지원하는 클러스터 네트워크 공급자(예: mode: NetworkPolicy 로 설정된 OpenShift SDN 네트워크 공급자)를 사용합니다. 이 모드는 OpenShift SDN의 기본값입니다.
OpenShift CLI(oc)를 설치합니다.
cluster-admin 권한이 있는 사용자로 클러스터에 로그인합니다.
다중 네트워크 정책이 적용되는 네임스페이스에서 작업하고 있습니다.

프로세스

다중 네트워크 정책 오브젝트를 삭제하려면 다음 명령을 입력합니다.
```
oc delete multi-networkpolicy <policy_name> -n <namespace>
```
```
$ oc delete multi-networkpolicy <policy_name> -n <namespace>
```
Copy to Clipboard Toggle word wrap
다음과 같습니다.
<policy_name>
다중 네트워크 정책의 이름을 지정합니다.
<namespace>
선택 사항: 오브젝트가 현재 네임스페이스와 다른 네임스페이스에 정의된 경우 이를 사용하여 네임스페이스를 지정합니다.
출력 예
```
multinetworkpolicy.k8s.cni.cncf.io/default-deny deleted
```
```
multinetworkpolicy.k8s.cni.cncf.io/default-deny deleted
```
Copy to Clipboard Toggle word wrap

참고

cluster-admin 권한을 사용하여 웹 콘솔에 로그인하면 클러스터의 모든 네임스페이스에서 YAML에서 직접 또는 작업 메뉴를 통해 웹 콘솔의 정책에서 네트워크 정책을 삭제할 수 있습니다.

19.5. 추가 네트워크에 pod 연결
링크 복사

클러스터 사용자는 pod를 추가 네트워크에 연결할 수 있습니다.

19.5.1. 추가 네트워크에 Pod 추가
링크 복사

추가 네트워크에 Pod를 추가할 수 있습니다. Pod는 기본 네트워크를 통해 정상적인 클러스터 관련 네트워크 트래픽을 계속 전송합니다.

Pod가 생성되면 추가 네트워크가 연결됩니다. 그러나 Pod가 이미 있는 경우에는 추가 네트워크를 연결할 수 없습니다.

Pod는 추가 네트워크와 동일한 네임스페이스에 있어야 합니다.

사전 요구 사항

OpenShift CLI(oc)를 설치합니다.
클러스터에 로그인합니다.

프로세스

Pod 오브젝트에 주석을 추가합니다. 다음 주석 형식 중 하나만 사용할 수 있습니다.
1. 사용자 정의 없이 추가 네트워크를 연결하려면 다음 형식으로 주석을 추가합니다. <network>를 Pod와 연결할 추가 네트워크의 이름으로 변경합니다.
  metadata: annotations: k8s.v1.cni.cncf.io/networks: <network>[,<network>,...]
  1
  Copy to Clipboard Toggle word wrap
  1
  둘 이상의 추가 네트워크를 지정하려면 각 네트워크를 쉼표로 구분합니다. 쉼표 사이에 공백을 포함하지 마십시오. 동일한 추가 네트워크를 여러 번 지정하면 Pod에 해당 네트워크에 대한 인터페이스가 여러 개 연결됩니다.
2. 사용자 정의된 추가 네트워크를 연결하려면 다음 형식으로 주석을 추가합니다.
  metadata: annotations: k8s.v1.cni.cncf.io/networks: |- [ { "name": "<network>",
  1
  "namespace": "<namespace>",
  2
  "default-route": ["<default-route>"]
  3
  } ]
  Copy to Clipboard Toggle word wrap
  1
  NetworkAttachmentDefinition 오브젝트에서 정의한 추가 네트워크의 이름을 지정합니다.
  2
  NetworkAttachmentDefinition 오브젝트가 정의된 네임스페이스를 지정합니다.
  3
  선택 사항: 기본 경로에 대한 재정의를 지정합니다(예: 192.168.17.1).
Pod를 생성하려면 다음 명령을 입력합니다. <name>을 Pod 이름으로 교체합니다.
```
oc create -f <name>.yaml
```
```
$ oc create -f <name>.yaml
```
Copy to Clipboard Toggle word wrap

선택사항: Pod CR에 주석이 있는지 확인하려면 다음 명령을 입력하고 <name>을 Pod 이름으로 교체합니다.

oc get pod <name> -o yaml

$ oc get pod <name> -o yaml

Copy to Clipboard

Toggle word wrap

다음 예에서 example-pod Pod는 net1 추가 네트워크에 연결되어 있습니다.

oc get pod example-pod -o yaml
apiVersion: v1
kind: Pod
metadata:
  annotations:
    k8s.v1.cni.cncf.io/networks: macvlan-bridge
    k8s.v1.cni.cncf.io/networks-status: |-
      [{
          "name": "openshift-sdn",
          "interface": "eth0",
          "ips": [
              "10.128.2.14"
          ],
          "default": true,
          "dns": {}
      },{
          "name": "macvlan-bridge",
          "interface": "net1",
          "ips": [
              "20.2.2.100"
          ],
          "mac": "22:2f:60:a5:f8:00",
          "dns": {}
      }]
  name: example-pod
  namespace: default
spec:
  ...
status:
  ...

$ oc get pod example-pod -o yaml
apiVersion: v1
kind: Pod
metadata:
  annotations:
    k8s.v1.cni.cncf.io/networks: macvlan-bridge
    k8s.v1.cni.cncf.io/networks-status: |-

1


      [{
          "name": "openshift-sdn",
          "interface": "eth0",
          "ips": [
              "10.128.2.14"
          ],
          "default": true,
          "dns": {}
      },{
          "name": "macvlan-bridge",
          "interface": "net1",
          "ips": [
              "20.2.2.100"
          ],
          "mac": "22:2f:60:a5:f8:00",
          "dns": {}
      }]
  name: example-pod
  namespace: default
spec:
  ...
status:
  ...

Copy to Clipboard

Toggle word wrap

1: k8s.v1.cni.cncf.io/networks-status 매개변수는 JSON 오브젝트 배열입니다. 각 오브젝트는 Pod에 연결된 추가 네트워크의 상태를 설명합니다. 주석 값은 일반 텍스트 값으로 저장됩니다.

19.5.1.1. Pod별 주소 지정 및 라우팅 옵션 지정
링크 복사

추가 네트워크에 Pod를 연결할 때 특정 Pod에서 해당 네트워크에 대한 추가 속성을 지정할 수 있습니다. 이를 통해 라우팅의 일부 측면을 변경하고 고정 IP 주소 및 MAC 주소를 지정할 수 있습니다. 이를 위해 JSON 형식의 주석을 사용할 수 있습니다.

사전 요구 사항

Pod는 추가 네트워크와 동일한 네임스페이스에 있어야 합니다.
OpenShift CLI(oc)를 설치합니다.
클러스터에 로그인해야 합니다.

프로세스

주소 지정 및/또는 라우팅 옵션을 지정하는 동안 추가 네트워크에 Pod를 추가하려면 다음 단계를 완료하십시오.

Pod 리소스 정의를 편집합니다. 기존 Pod 리소스를 편집하는 경우 다음 명령을 실행하여 기본 편집기에서 정의를 편집합니다. <name>을 편집할 Pod 리소스의 이름으로 교체합니다.
```
oc edit pod <name>
```
```
$ oc edit pod <name>
```
Copy to Clipboard Toggle word wrap
Pod 리소스 정의에서 k8s.v1.cni.cncf.io/networks 매개변수를 Pod metadata 매핑에 추가합니다. k8s.v1.cni.cncf.io/networks는 추가 특성을 지정하는 것 외에도 NetworkAttachmentDefinition Custom Resource(CR) 이름을 참조하는 오브젝트 목록의 JSON 문자열을 허용합니다.
```
metadata:
  annotations:
    k8s.v1.cni.cncf.io/networks: '[<network>[,<network>,...]]' 
```
```
metadata:
  annotations:
    k8s.v1.cni.cncf.io/networks: '[<network>[,<network>,...]]' 
```
1
Copy to Clipboard Toggle word wrap
1
다음 예제와 같이 <network>를 JSON 오브젝트로 변경합니다. 작은 따옴표를 사용해야 합니다.

다음 예에서 주석은 default-route 매개변수를 사용하여 기본 경로로 지정될 네트워크 연결을 지정합니다.

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
  annotations:
    k8s.v1.cni.cncf.io/networks: '
    {
      "name": "net1"
    },
    {
      "name": "net2", 
      "default-route": ["192.0.2.1"] 
    }'
spec:
  containers:
  - name: example-pod
    command: ["/bin/bash", "-c", "sleep 2000000000000"]
    image: centos/tools

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
  annotations:
    k8s.v1.cni.cncf.io/networks: '
    {
      "name": "net1"
    },
    {
      "name": "net2",

1


      "default-route": ["192.0.2.1"]

2


    }'
spec:
  containers:
  - name: example-pod
    command: ["/bin/bash", "-c", "sleep 2000000000000"]
    image: centos/tools

Copy to Clipboard

Toggle word wrap

1: name 키는 Pod와 연결할 추가 네트워크의 이름입니다.
2: default-route 키는 라우팅 테이블에 다른 라우팅 항목이 없는 경우 트래픽이 라우팅될 게이트웨이 값을 지정합니다. default-route 키가 두 개 이상 지정되면 Pod가 활성화되지 않습니다.

기본 경로는 다른 경로에 지정되지 않은 모든 트래픽이 게이트웨이로 라우팅되도록 합니다.

중요

OpenShift Container Platform의 기본 네트워크 인터페이스 이외의 인터페이스로 기본 경로를 설정하면 Pod 사이에서 트래픽이 라우팅될 것으로 예상되는 트래픽이 다른 인터페이스를 통해 라우팅될 수 있습니다.

Pod의 라우팅 속성을 확인하려면 oc 명령을 사용하여 Pod에서 ip 명령을 실행하십시오.

oc exec -it <pod_name> -- ip route

$ oc exec -it <pod_name> -- ip route

Copy to Clipboard

Toggle word wrap

참고

JSON 형식의 오브젝트 목록에 default-route 키가 있으면 Pod의 k8s.v1.cni.cncf.io/networks-status를 참조하여 어떤 추가 네트워크에 기본 경로가 할당되었는지를 확인할 수도 있습니다.

Pod의 고정 IP 주소 또는 MAC 주소를 설정하려면 JSON 형식의 주석을 사용하면 됩니다. 이를 위해서는 이러한 기능을 특별하게 허용하는 네트워크를 생성해야 합니다. 이는 다음과 같이 CNO의 rawCNIConfig에서 지정할 수 있습니다.

다음 명령을 실행하여 CNO CR을 편집합니다.
```
oc edit networks.operator.openshift.io cluster
```
```
$ oc edit networks.operator.openshift.io cluster
```
Copy to Clipboard Toggle word wrap

다음 YAML은 CNO의 구성 매개변수를 설명합니다.

CNO(Cluster Network Operator) YAML 구성

name: <name> 
namespace: <namespace> 
rawCNIConfig: '{ 
  ...
}'
type: Raw

name: <name>

1


namespace: <namespace>

2


rawCNIConfig: '{

3


  ...
}'
type: Raw

Copy to Clipboard

Toggle word wrap

1: 생성 중인 추가 네트워크 연결의 이름을 지정합니다. 이름은 지정된 namespace 내에서 고유해야 합니다.
2: 네트워크를 연결한 네임스페이스를 지정합니다. 값을 지정하지 않으면 default 네임스페이스가 사용됩니다.
3: 다음 템플릿을 기반으로 CNI 플러그인 구성을 JSON 형식으로 지정합니다.

다음 오브젝트는 macvlan CNI 플러그인을 사용하여 고정 MAC 주소 및 IP 주소를 사용하기 위한 구성 매개변수를 설명합니다.

고정 IP 및 MAC 주소를 사용하는 macvlan CNI 플러그인 JSON 구성 오브젝트

{
  "cniVersion": "0.3.1",
  "name": "<name>", 
  "plugins": [{ 
      "type": "macvlan",
      "capabilities": { "ips": true }, 
      "master": "eth0", 
      "mode": "bridge",
      "ipam": {
        "type": "static"
      }
    }, {
      "capabilities": { "mac": true }, 
      "type": "tuning"
    }]
}

{
  "cniVersion": "0.3.1",
  "name": "<name>",

1


  "plugins": [{

2


      "type": "macvlan",
      "capabilities": { "ips": true },

3


      "master": "eth0",

4


      "mode": "bridge",
      "ipam": {
        "type": "static"
      }
    }, {
      "capabilities": { "mac": true },

5


      "type": "tuning"
    }]
}

Copy to Clipboard

Toggle word wrap

1: 생성할 추가 네트워크 연결의 이름을 지정합니다. 이름은 지정된 namespace 내에서 고유해야 합니다.
2: CNI 플러그인 구성의 배열을 지정합니다. 첫 번째 오브젝트는 macvlan 플러그인 구성을 지정하고 두 번째 오브젝트는 튜닝 플러그인 구성을 지정합니다.
3: CNI 플러그인 런타임 구성 기능의 고정 IP 주소 기능을 사용하도록 요청하도록 지정합니다.
4: macvlan 플러그인이 사용하는 인터페이스를 지정합니다.
5: CNI 플러그인의 정적 MAC 주소 기능을 사용하도록 요청하도록 지정합니다.

그런 다음 위의 네트워크 연결을 키와 함께 JSON 형식 주석에서 참조하여 지정된 Pod에 할당할 고정 IP 및 MAC 주소를 지정할 수 있습니다.

다음을 사용하여 Pod를 편집합니다.

oc edit pod <name>

$ oc edit pod <name>

Copy to Clipboard

Toggle word wrap

고정 IP 및 MAC 주소를 사용하는 macvlan CNI 플러그인 JSON 구성 오브젝트

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
  annotations:
    k8s.v1.cni.cncf.io/networks: '[
      {
        "name": "<name>", 
        "ips": [ "192.0.2.205/24" ], 
        "mac": "CA:FE:C0:FF:EE:00" 
      }
    ]'

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
  annotations:
    k8s.v1.cni.cncf.io/networks: '[
      {
        "name": "<name>",

1


        "ips": [ "192.0.2.205/24" ],

2


        "mac": "CA:FE:C0:FF:EE:00"

3


      }
    ]'

Copy to Clipboard

Toggle word wrap

1: 위의 rawCNIConfig를 구성하는 경우에는 제공되는 <name>을 사용해야 합니다.
2: 서브넷 마스크를 포함하여 IP 주소를 제공합니다.
3: MAC 주소를 입력합니다.

참고

고정 IP 주소와 MAC 주소를 동시에 사용할 필요는 없으며 개별적으로 또는 함께 사용할 수 있습니다.

추가 네트워크가 있는 Pod의 IP 주소 및 MAC 속성을 확인하려면 oc 명령을 사용하여 Pod에서 ip 명령을 실행합니다.

oc exec -it <pod_name> -- ip a

$ oc exec -it <pod_name> -- ip a

Copy to Clipboard

Toggle word wrap

19.6. 추가 네트워크에서 Pod 제거
링크 복사

클러스터 사용자는 추가 네트워크에서 Pod를 제거할 수 있습니다.

19.6.1. 추가 네트워크에서 Pod 제거
링크 복사

Pod를 삭제해야만 추가 네트워크에서 Pod를 제거할 수 있습니다.

사전 요구 사항

Pod에 추가 네트워크가 연결되어 있어야 합니다.
OpenShift CLI(oc)를 설치합니다.
클러스터에 로그인합니다.

프로세스

Pod를 삭제하려면 다음 명령을 입력합니다.
```
oc delete pod <name> -n <namespace>
```
```
$ oc delete pod <name> -n <namespace>
```
Copy to Clipboard Toggle word wrap
- <name>은 Pod의 이름입니다.
- <namespace>는 Pod가 포함된 네임스페이스입니다.

19.7. 추가 네트워크 편집
링크 복사

클러스터 관리자는 기존 추가 네트워크의 구성을 수정할 수 있습니다.

19.7.1. 추가 네트워크 연결 정의 수정
링크 복사

클러스터 관리자는 기존 추가 네트워크를 변경할 수 있습니다. 추가 네트워크에 연결된 기존 Pod는 업데이트되지 않습니다.

사전 요구 사항

클러스터에 추가 네트워크가 구성되어야 합니다.
OpenShift CLI(oc)를 설치합니다.
cluster-admin 권한이 있는 사용자로 로그인합니다.

프로세스

클러스터의 추가 네트워크를 편집하려면 다음 단계를 완료하십시오.

기본 텍스트 편집기에서 CNO(Cluster Network Operator) CR을 편집하려면 다음 명령을 실행합니다.
```
oc edit networks.operator.openshift.io cluster
```
```
$ oc edit networks.operator.openshift.io cluster
```
Copy to Clipboard Toggle word wrap
additionalNetworks 컬렉션에서 변경 내용으로 추가 네트워크를 업데이트합니다.
변경 사항을 저장하고 텍스트 편집기를 종료하여 변경 사항을 커밋합니다.

선택 사항: CNO에서 다음 명령을 실행하여 NetworkAttachmentDefinition 오브젝트를 업데이트했는지 확인합니다. <network-name>을 표시할 추가 네트워크의 이름으로 변경합니다. CNO가 변경 사항을 반영하기 위해서 NetworkAttachmentDefinition 오브젝트를 업데이트하기 전에 지연이 발생할 수 있습니다.

oc get network-attachment-definitions <network-name> -o yaml

$ oc get network-attachment-definitions <network-name> -o yaml

Copy to Clipboard

Toggle word wrap

예를 들어, 다음 콘솔 출력은 net1이라는 NetworkAttachmentDefinition 오브젝트를 표시합니다.

oc get network-attachment-definitions net1 -o go-template='{{printf "%s\n" .spec.config}}'
{ "cniVersion": "0.3.1", "type": "macvlan",
"master": "ens5",
"mode": "bridge",
"ipam":       {"type":"static","routes":[{"dst":"0.0.0.0/0","gw":"10.128.2.1"}],"addresses":[{"address":"10.128.2.100/23","gateway":"10.128.2.1"}],"dns":{"nameservers":["172.30.0.10"],"domain":"us-west-2.compute.internal","search":["us-west-2.compute.internal"]}} }

$ oc get network-attachment-definitions net1 -o go-template='{{printf "%s\n" .spec.config}}'
{ "cniVersion": "0.3.1", "type": "macvlan",
"master": "ens5",
"mode": "bridge",
"ipam":       {"type":"static","routes":[{"dst":"0.0.0.0/0","gw":"10.128.2.1"}],"addresses":[{"address":"10.128.2.100/23","gateway":"10.128.2.1"}],"dns":{"nameservers":["172.30.0.10"],"domain":"us-west-2.compute.internal","search":["us-west-2.compute.internal"]}} }

Copy to Clipboard

Toggle word wrap

19.8. 추가 네트워크 제거
링크 복사

클러스터 관리자는 추가 네트워크의 연결을 제거할 수 있습니다.

19.8.1. 추가 네트워크 연결 정의 제거
링크 복사

클러스터 관리자는 OpenShift Container Platform 클러스터에서 추가 네트워크를 제거할 수 있습니다. 추가 네트워크는 연결된 Pod에서 제거되지 않습니다.

사전 요구 사항

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

절차

클러스터에서 추가 네트워크를 제거하려면 다음 단계를 완료하십시오.

다음 명령을 실행하여 기본 텍스트 편집기에서 CNO(Cluster Network Operator)를 편집합니다.
```
oc edit networks.operator.openshift.io cluster
```
```
$ oc edit networks.operator.openshift.io cluster
```
Copy to Clipboard Toggle word wrap
제거할 네트워크 연결 정의에 대한 additionalNetworks 컬렉션에서 구성을 제거하여 CR을 수정합니다.
```
apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  additionalNetworks: [] 
```
```
apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  additionalNetworks: [] 
```
1
Copy to Clipboard Toggle word wrap
1
additionalNetworks 컬렉션에서 유일한 추가 네트워크 첨부 파일 정의에 대한 구성 매핑을 제거하는 경우 빈 컬렉션을 지정해야 합니다.
변경 사항을 저장하고 텍스트 편집기를 종료하여 변경 사항을 커밋합니다.
선택 사항: 추가 네트워크 CR이 삭제되었는지 확인하려면 다음 명령을 실행합니다.
```
oc get network-attachment-definition --all-namespaces
```
```
$ oc get network-attachment-definition --all-namespaces
```
Copy to Clipboard Toggle word wrap

19.9. VRF에 보조 네트워크 할당
링크 복사

19.9.1. VRF에 보조 네트워크 할당
링크 복사

클러스터 관리자는 CNI VRF 플러그인을 사용하여 VRF 도메인에 대한 추가 네트워크를 구성할 수 있습니다. 이 플러그인으로 생성된 가상 네트워크는 지정한 물리적 인터페이스와 연결됩니다.

참고

VRF를 사용하는 애플리케이션은 특정 장치에 바인딩해야 합니다. 일반적인 사용은 소켓에 SO_BINDTODEVICE 옵션을 사용하는 것입니다. SO_BINDTODEVICE는 소켓을 전달된 인터페이스 이름(예: eth1)에 지정된 장치에 바인딩합니다. SO_BINDTODEVICE를 사용하려면 애플리케이션에 CAP_NET_RAW 기능이 있어야 합니다.

OpenShift Container Platform Pod에서는 ip vrf exec 명령을 통해 VRF를 사용할 수 없습니다. VRF를 사용하려면 애플리케이션을 VRF 인터페이스에 직접 바인딩합니다.

19.9.1.1. CNI VRF 플러그인으로 추가 네트워크 연결 생성
링크 복사

CNO(Cluster Network Operator)는 추가 네트워크 정의를 관리합니다. 생성할 추가 네트워크를 지정하면 CNO가 NetworkAttachmentDefinition CR(사용자 정의 리소스)을 자동으로 생성합니다.

참고

CNO가 관리하는 NetworkAttachmentDefinition CR을 편집하지 마십시오. 편집하면 추가 네트워크의 네트워크 트래픽이 중단될 수 있습니다.

CNI VRF 플러그인으로 추가 네트워크 연결을 생성하려면 다음 절차를 수행하십시오.

사전 요구 사항

OpenShift Container Platform CLI, oc를 설치합니다.
cluster-admin 권한이 있는 사용자로 OpenShift 클러스터에 로그인합니다.

절차

추가 Network 연결에 사용할 네트워크 CR(사용자 정의 리소스)을 생성하고 다음 예제 CR과 같이 추가 네트워크의 rawCNIConfig 구성을 삽입합니다. YAML을 additional-network-attachment.yaml 파일로 저장합니다.

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
  spec:
  additionalNetworks:
  - name: test-network-1
    namespace: additional-network-1
    type: Raw
    rawCNIConfig: '{
      "cniVersion": "0.3.1",
      "name": "macvlan-vrf",
      "plugins": [  
      {
        "type": "macvlan",  
        "master": "eth1",
        "ipam": {
            "type": "static",
            "addresses": [
            {
                "address": "191.168.1.23/24"
            }
            ]
        }
      },
      {
        "type": "vrf",
        "vrfname": "example-vrf-name",  
        "table": 1001   
      }]
    }'

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
  spec:
  additionalNetworks:
  - name: test-network-1
    namespace: additional-network-1
    type: Raw
    rawCNIConfig: '{
      "cniVersion": "0.3.1",
      "name": "macvlan-vrf",
      "plugins": [

1


      {
        "type": "macvlan",

2


        "master": "eth1",
        "ipam": {
            "type": "static",
            "addresses": [
            {
                "address": "191.168.1.23/24"
            }
            ]
        }
      },
      {
        "type": "vrf",
        "vrfname": "example-vrf-name",

3


        "table": 1001

4


      }]
    }'

Copy to Clipboard

Toggle word wrap

1: plugins는 목록이어야 합니다. 목록의 첫 번째 항목은 VRF 네트워크를 기반으로 하는 보조 네트워크여야 합니다. 목록의 두 번째 항목은 VRF 플러그인 구성입니다.
2: type은 vrf로 설정해야 합니다.
3: vrfname은 인터페이스가 할당된 VRF의 이름입니다. 포드에 없는 경우 생성됩니다.
4: 선택 사항: table은 라우팅 테이블 ID입니다. 기본적으로 tableid 매개변수가 사용됩니다. 지정하지 않으면 CNI에서 무료 라우팅 테이블 ID를 VRF에 할당합니다.

참고

VRF는 리소스의 유형이 netdevice인 경우에만 올바르게 작동합니다.

Network 리소스를 생성합니다.

oc create -f additional-network-attachment.yaml

$ oc create -f additional-network-attachment.yaml

Copy to Clipboard

Toggle word wrap

CNO가 다음 명령을 실행하여 NetworkAttachmentDefinition CR을 생성했는지 확인합니다. <namespace>를 네트워크 연결을 구성할 때 지정한 네임스페이스(예: additional-network-1)로 바꿉니다.
```
oc get network-attachment-definitions -n <namespace>
```
```
$ oc get network-attachment-definitions -n <namespace>
```
Copy to Clipboard Toggle word wrap
출력 예
```
NAME                       AGE
additional-network-1       14m
```
```
NAME                       AGE
additional-network-1       14m
```
Copy to Clipboard Toggle word wrap
참고
CNO가 CR을 생성하기 전에 지연이 발생할 수 있습니다.

추가 VRF 네트워크 연결에 성공했는지 확인

VRF CNI가 올바르게 구성되어 추가 네트워크 연결이 연결되었는지 확인하려면 다음을 수행하십시오.

VRF CNI를 사용하는 네트워크를 생성합니다.
포드에 네트워크를 할당합니다.
포드 네트워크 연결이 VRF 추가 네트워크에 연결되어 있는지 확인합니다. Pod로 원격 쉘을 설치하고 다음 명령을 실행합니다.
```
ip vrf show
```
```
$ ip vrf show
```
Copy to Clipboard Toggle word wrap
출력 예
```
Name              Table
-----------------------
red                 10
```
```
Name              Table
-----------------------
red                 10
```
Copy to Clipboard Toggle word wrap
VRF 인터페이스가 보조 인터페이스의 마스터인지 확인합니다.
```
ip link
```
```
$ ip link
```
Copy to Clipboard Toggle word wrap
출력 예
```
5: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master red state UP mode
```
```
5: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master red state UP mode
```
Copy to Clipboard Toggle word wrap

20장. 하드웨어 네트워크
링크 복사

20.1. SR-IOV(Single Root I/O Virtualization) 하드웨어 네트워크 정보
링크 복사

SR-IOV(Single Root I/O Virtualization) 사양은 단일 장치를 여러 Pod와 공유할 수 있는 PCI 장치 할당 유형의 표준입니다.

SR-IOV를 사용하면 호스트 노드에서 물리적 기능(PF)으로 인식되는 호환 네트워크 장치를 여러 VF(가상 기능)로 분할할 수 있습니다. VF는 다른 네트워크 장치와 같이 사용됩니다. 장치의 SR-IOV 네트워크 장치 드라이버는 컨테이너에서 VF가 노출되는 방식을 결정합니다.

netdevice 드라이버: 컨테이너의 netns에 있는 일반 커널 네트워크 장치
vfio-pci 드라이버: 컨테이너에 마운트된 문자 장치

높은 대역폭 또는 짧은 대기 시간이 필요한 애플리케이션에 베어 메탈 또는 RHOSP(Red Hat OpenStack Platform) 인프라에 설치된 OpenShift Container Platform 클러스터에 추가 네트워크와 함께 SR-IOV 네트워크 장치를 사용할 수 있습니다.

다음 명령을 사용하여 노드에서 SR-IOV를 활성화할 수 있습니다.

oc label node <node_name> feature.node.kubernetes.io/network-sriov.capable="true"

$ oc label node <node_name> feature.node.kubernetes.io/network-sriov.capable="true"

Copy to Clipboard

Toggle word wrap

20.1.1. SR-IOV 네트워크 장치를 관리하는 구성 요소
링크 복사

SR-IOV 네트워크 Operator는 SR-IOV 스택의 구성 요소를 생성하고 관리합니다. 다음과 같은 기능을 수행합니다.

SR-IOV 네트워크 장치 검색 및 관리 오케스트레이션
SR-IOV 컨테이너 네트워크 인터페이스(CNI)에 대한 NetworkAttachmentDefinition 사용자 정의 리소스 생성
SR-IOV 네트워크 장치 플러그인의 구성을 생성하고 업데이트
노드별 SriovNetworkNodeState 사용자 정의 리소스 생성
각 SriovNetworkNodeState 사용자 정의 리소스에서 spec.interfaces 필드 업데이트

Operator는 다음 구성 요소를 프로비저닝합니다.

SR-IOV 네트워크 구성 데몬: SR-IOV 네트워크 Operator가 시작될 때 작업자 노드에 배포되는 데몬 세트입니다. 데몬은 클러스터에서 SR-IOV 네트워크 장치를 검색하고 초기화합니다.
SR-IOV 네트워크 Operator webhook: Operator 사용자 정의 리소스의 유효성을 검증하고 설정되지 않은 필드에 적절한 기본값을 설정하는 동적 승인 컨트롤러 webhook.
SR-IOV 네트워크 리소스 인젝터: SR-IOV VF와 같은 사용자 정의 네트워크 리소스에 대한 요청 및 제한으로 Kubernetes pod 사양을 패치하는 기능을 제공하는 동적 승인 컨트롤러 webhook. SR-IOV 네트워크 리소스 인젝터는 Pod의 첫 번째 컨테이너에만 리소스 필드를 자동으로 추가합니다.
SR-IOV 네트워크 장치 플러그인: SR-IOV 네트워크 VF(가상 기능) 리소스를 검색, 승격 및 할당하는 장치 플러그인입니다. Kubernetes에서는 장치 플러그인을 사용하여 일반적으로 물리적 장치에서 제한된 리소스를 사용할 수 있습니다. 장치 플러그인은 Kubernetes 스케줄러에 리소스 가용성을 인식하여 스케줄러가 충분한 리소스가 있는 노드에서 Pod를 예약할 수 있도록 합니다.
SR-IOV CNI 플러그인: SR-IOV 네트워크 장치 플러그인에서 할당된 VF 인터페이스를 pod에 직접 연결하는 CNI 플러그인입니다.
SR-IOV InfiniBand CNI 플러그인: SR-IOV 네트워크 장치 플러그인에서 할당된 IB(InfiniBand) VF 인터페이스를 pod에 직접 연결하는 CNI 플러그인입니다.

참고

SR-IOV 네트워크 리소스 인젝터 및 SR-IOV 네트워크 Operator webhook는 기본적으로 활성화되어 있으며 기본 SriovOperatorConfig CR을 편집하여 비활성화할 수 있습니다. SR-IOV Network Operator Admission Controller 웹 후크를 비활성화할 때 주의하십시오. 문제 해결과 같은 특정 상황에서 웹 후크를 비활성화하거나 지원되지 않는 장치를 사용하려는 경우 사용할 수 있습니다.

20.1.1.1. 지원되는 플랫폼
링크 복사

SR-IOV Network Operator는 다음 플랫폼에서 지원됩니다.

베어 메탈
Red Hat OpenStack Platform (RHOSP)

20.1.1.2. 지원되는 장치
링크 복사

OpenShift Container Platform에서는 다음 네트워크 인터페이스 컨트롤러를 지원합니다.

Expand

표 20.1. 지원되는 네트워크 인터페이스 컨트롤러
제조업체	모델	벤더 ID	장치 ID
Broadcom	BCM57414	14e4	16d7
Broadcom	BCM57508	14e4	1750
Intel	X710	8086	1572
Intel	XL710	8086	1583
Intel	XXV710	8086	158b
Intel	E810-CQDA2	8086	1592
Intel	E810-2CQDA2	8086	1592
Intel	E810-XXVDA2	8086	159b
Intel	E810-XXVDA4	8086	1593
Mellanox	MT27700 제품군 [ConnectX-4]	15b3	1013
Mellanox	MT27710 제품군 [ConnectX-4 Lx]	15b3	1015
Mellanox	MT27800 제품군 [ConnectX-5]	15b3	1017
Mellanox	MT28880 제품군 [ConnectX-5 Ex]	15b3	1019
Mellanox	MT28908 제품군 [ConnectX-6]	15b3	101b
Mellanox	MT2892 제품군 [ConnectX-6 Dx]	15b3	101d
Mellanox	MT2894 제품군 [ConnectX-6 Lx]	15b3	101f
Pensando ^[1]	DSC-25 듀얼 포트 25G 분산 서비스 카드 ionic 드라이버	0x1dd8	0x1002
Pensando ^[1]	ionic 드라이버용 DSC-100 듀얼 포트 100G 분산 서비스 카드	0x1dd8	0x1003

OpenShift SR-IOV는 지원되지만 SR-IOV를 사용할 때 SR-IOV를 사용할 때 SR-IOV CNI 구성 파일을 사용하여 정적인 VF(가상 기능) 미디어 액세스 제어(MAC) 주소를 설정해야 합니다.

참고

지원되는 카드 및 호환 가능한 OpenShift Container Platform 버전의 최신 목록은 Openshift Single Root I/O Virtualization(SR-IOV) 및 PTP 하드웨어 네트워크 지원 매트릭스 를 참조하십시오.

20.1.1.3. SR-IOV 네트워크 장치의 자동 검색
링크 복사

SR-IOV Network Operator는 작업자 노드에서 SR-IOV 가능 네트워크 장치를 클러스터에서 검색합니다. Operator는 호환되는 SR-IOV 네트워크 장치를 제공하는 각 작업자 노드에 대해 SriovNetworkNodeState CR(사용자 정의 리소스)을 생성하고 업데이트합니다.

CR에는 작업자 노드와 동일한 이름이 할당됩니다. status.interfaces 목록은 노드의 네트워크 장치에 대한 정보를 제공합니다.

중요

SriovNetworkNodeState 오브젝트를 수정하지 마십시오. Operator는 이러한 리소스를 자동으로 생성하고 관리합니다.

20.1.1.3.1. SriovNetworkNodeState 오브젝트의 예
링크 복사

다음 YAML은 SR-IOV Network Operator가 생성한 SriovNetworkNodeState 오브젝트의 예입니다.

SriovNetworkNodeState 오브젝트

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodeState
metadata:
  name: node-25 
  namespace: openshift-sriov-network-operator
  ownerReferences:
  - apiVersion: sriovnetwork.openshift.io/v1
    blockOwnerDeletion: true
    controller: true
    kind: SriovNetworkNodePolicy
    name: default
spec:
  dpConfigVersion: "39824"
status:
  interfaces: 
  - deviceID: "1017"
    driver: mlx5_core
    mtu: 1500
    name: ens785f0
    pciAddress: "0000:18:00.0"
    totalvfs: 8
    vendor: 15b3
  - deviceID: "1017"
    driver: mlx5_core
    mtu: 1500
    name: ens785f1
    pciAddress: "0000:18:00.1"
    totalvfs: 8
    vendor: 15b3
  - deviceID: 158b
    driver: i40e
    mtu: 1500
    name: ens817f0
    pciAddress: 0000:81:00.0
    totalvfs: 64
    vendor: "8086"
  - deviceID: 158b
    driver: i40e
    mtu: 1500
    name: ens817f1
    pciAddress: 0000:81:00.1
    totalvfs: 64
    vendor: "8086"
  - deviceID: 158b
    driver: i40e
    mtu: 1500
    name: ens803f0
    pciAddress: 0000:86:00.0
    totalvfs: 64
    vendor: "8086"
  syncStatus: Succeeded

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodeState
metadata:
  name: node-25

1


  namespace: openshift-sriov-network-operator
  ownerReferences:
  - apiVersion: sriovnetwork.openshift.io/v1
    blockOwnerDeletion: true
    controller: true
    kind: SriovNetworkNodePolicy
    name: default
spec:
  dpConfigVersion: "39824"
status:
  interfaces:

2


  - deviceID: "1017"
    driver: mlx5_core
    mtu: 1500
    name: ens785f0
    pciAddress: "0000:18:00.0"
    totalvfs: 8
    vendor: 15b3
  - deviceID: "1017"
    driver: mlx5_core
    mtu: 1500
    name: ens785f1
    pciAddress: "0000:18:00.1"
    totalvfs: 8
    vendor: 15b3
  - deviceID: 158b
    driver: i40e
    mtu: 1500
    name: ens817f0
    pciAddress: 0000:81:00.0
    totalvfs: 64
    vendor: "8086"
  - deviceID: 158b
    driver: i40e
    mtu: 1500
    name: ens817f1
    pciAddress: 0000:81:00.1
    totalvfs: 64
    vendor: "8086"
  - deviceID: 158b
    driver: i40e
    mtu: 1500
    name: ens803f0
    pciAddress: 0000:86:00.0
    totalvfs: 64
    vendor: "8086"
  syncStatus: Succeeded

Copy to Clipboard

Toggle word wrap

1: name 필드의 값은 작업자 노드의 이름과 동일합니다.
2: 인터페이스 스탠자에는 작업자 노드에서 Operator가 감지한 모든 SR-IOV 장치 목록이 포함되어 있습니다.

20.1.1.4. Pod에서 가상 함수 사용 예
링크 복사

SR-IOV VF가 연결된 pod에서 RDMA(Remote Direct Memory Access) 또는 DPDK(Data Plane Development Kit) 애플리케이션을 실행할 수 있습니다.

이 예는 RDMA 모드에서 VF(가상 기능)를 사용하는 pod를 보여줍니다.

RDMA 모드를 사용하는 Pod 사양

apiVersion: v1
kind: Pod
metadata:
  name: rdma-app
  annotations:
    k8s.v1.cni.cncf.io/networks: sriov-rdma-mlnx
spec:
  containers:
  - name: testpmd
    image: <RDMA_image>
    imagePullPolicy: IfNotPresent
    securityContext:
      runAsUser: 0
      capabilities:
        add: ["IPC_LOCK","SYS_RESOURCE","NET_RAW"]
    command: ["sleep", "infinity"]

apiVersion: v1
kind: Pod
metadata:
  name: rdma-app
  annotations:
    k8s.v1.cni.cncf.io/networks: sriov-rdma-mlnx
spec:
  containers:
  - name: testpmd
    image: <RDMA_image>
    imagePullPolicy: IfNotPresent
    securityContext:
      runAsUser: 0
      capabilities:
        add: ["IPC_LOCK","SYS_RESOURCE","NET_RAW"]
    command: ["sleep", "infinity"]

Copy to Clipboard

Toggle word wrap

다음 예는 DPDK 모드에서 VF가 있는 pod를 보여줍니다.

DPDK 모드를 사용하는 Pod 사양

apiVersion: v1
kind: Pod
metadata:
  name: dpdk-app
  annotations:
    k8s.v1.cni.cncf.io/networks: sriov-dpdk-net
spec:
  containers:
  - name: testpmd
    image: <DPDK_image>
    securityContext:
      runAsUser: 0
      capabilities:
        add: ["IPC_LOCK","SYS_RESOURCE","NET_RAW"]
    volumeMounts:
    - mountPath: /dev/hugepages
      name: hugepage
    resources:
      limits:
        memory: "1Gi"
        cpu: "2"
        hugepages-1Gi: "4Gi"
      requests:
        memory: "1Gi"
        cpu: "2"
        hugepages-1Gi: "4Gi"
    command: ["sleep", "infinity"]
  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages

apiVersion: v1
kind: Pod
metadata:
  name: dpdk-app
  annotations:
    k8s.v1.cni.cncf.io/networks: sriov-dpdk-net
spec:
  containers:
  - name: testpmd
    image: <DPDK_image>
    securityContext:
      runAsUser: 0
      capabilities:
        add: ["IPC_LOCK","SYS_RESOURCE","NET_RAW"]
    volumeMounts:
    - mountPath: /dev/hugepages
      name: hugepage
    resources:
      limits:
        memory: "1Gi"
        cpu: "2"
        hugepages-1Gi: "4Gi"
      requests:
        memory: "1Gi"
        cpu: "2"
        hugepages-1Gi: "4Gi"
    command: ["sleep", "infinity"]
  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages

Copy to Clipboard

Toggle word wrap

20.1.1.5. 컨테이너 애플리케이션에서 사용하는 DPDK 라이브러리
링크 복사

선택적 라이브러리인 app-netutil은 해당 포드에서 실행 중인 컨테이너 내에서 포드에 관한 네트워크 정보를 수집하기 위해 여러 API 메서드를 제공합니다.

이 라이브러리는 DPDK(Data Plane Development Kit) 모드의 SR-IOV VF(가상 기능)를 컨테이너에 통합하는 데 도움이 될 수 있습니다. 라이브러리는 Golang API와 C API를 모두 제공합니다.

현재 세 가지 API 메서드가 구현되어 있습니다.

GetCPUInfo(): 이 함수는 컨테이너에서 사용할 수 있는 CPU를 결정하고 목록을 반환합니다.
GetHugepages(): 이 함수는 각 컨테이너에 대해 Pod 사양에서 요청된 대량의 페이지 메모리의 양을 결정하고 값을 반환합니다.
GetInterfaces(): 이 함수는 컨테이너의 인터페이스 집합을 결정하고 목록을 반환합니다. 반환 값에는 각 인터페이스에 대한 인터페이스 유형 및 유형별 데이터가 포함됩니다.

라이브러리 리포지토리에는 컨테이너 이미지 dpdk-app-centos를 빌드하는 샘플 Dockerfile이 포함되어 있습니다. 컨테이너 이미지는 pod 사양의 환경 변수에 따라 다음 DPDK 샘플 애플리케이션 중 하나를 실행할 수 있습니다. l2fwd,l3wd 또는 testpmd. 컨테이너 이미지는 app-netutil 라이브러리를 컨테이너 이미지 자체에 통합하는 예를 제공합니다. 라이브러리는 init 컨테이너에 통합할 수도 있습니다. init 컨테이너는 필요한 데이터를 수집하고 기존 DPDK 워크로드에 데이터를 전달할 수 있습니다.

20.1.1.6. Downward API 에 대한 대규보 페이지 리소스 주입
링크 복사

Pod 사양에 대규모 페이지에 대한 리소스 요청 또는 제한이 포함된 경우 Network Resources Injector는 컨테이너에 대규모 페이지 정보를 제공하기 위해 Pod 사양에 Downward API 필드를 자동으로 추가합니다.

Network Resources Injector는 podnetinfo라는 볼륨을 추가하고 Pod의 각 컨테이너에 대해 /etc/podnetinfo에 마운트됩니다. 볼륨은 Downward API를 사용하며 대규모 페이지 요청 및 제한에 대한 파일을 포함합니다. 파일 이름 지정 규칙은 다음과 같습니다.

/etc/podnetinfo/hugepages_1G_request_<container-name>
/etc/podnetinfo/hugepages_1G_limit_<container-name>
/etc/podnetinfo/hugepages_2M_request_<container-name>
/etc/podnetinfo/hugepages_2M_limit_<container-name>

이전 목록에 지정된 경로는 app-netutil 라이브러리와 호환됩니다. 기본적으로 라이브러리는 /etc/podnetinfo 디렉터리에서 리소스 정보를 검색하도록 구성됩니다. Downward API 경로 항목을 수동으로 지정하도록 선택하는 경우 app-netutil 라이브러리는 이전 목록의 경로 외에도 다음 경로를 검색합니다.

/etc/podnetinfo/hugepages_request
/etc/podnetinfo/hugepages_limit
/etc/podnetinfo/hugepages_1G_request
/etc/podnetinfo/hugepages_1G_limit
/etc/podnetinfo/hugepages_2M_request
/etc/podnetinfo/hugepages_2M_limit

Network Resources Injector에서 생성할 수 있는 경로와 마찬가지로, 이전 목록의 경로는 선택적으로 _<container-name> 접미사로 종료할 수 있습니다.

20.1.2. 다음 단계
링크 복사

SR-IOV Network Operator 설치
선택사항: SR-IOV Network Operator 구성
SR-IOV 네트워크 장치 구성
OpenShift Virtualization을 사용하는 경우: 가상 머신을 SR-IOV 네트워크에 연결
SR-IOV 네트워크 연결 구성
SR-IOV 추가 네트워크에 pod 추가

20.2. SR-IOV Network Operator 설치
링크 복사

SR-IOV(Single Root I/O Virtualization) Network Operator를 클러스터에 설치하여 SR-IOV 네트워크 장치 및 네트워크 연결을 관리할 수 있습니다.

20.2.1. SR-IOV Network Operator 설치
링크 복사

클러스터 관리자는 OpenShift Container Platform CLI 또는 웹 콘솔을 사용하여 SR-IOV Network Operator를 설치할 수 있습니다.

20.2.1.1. CLI: SR-IOV Network Operator 설치
링크 복사

클러스터 관리자는 CLI를 사용하여 Operator를 설치할 수 있습니다.

사전 요구 사항

SR-IOV를 지원하는 하드웨어가 있는 노드로 베어 메탈 하드웨어에 설치된 클러스터.
OpenShift CLI(oc)를 설치합니다.
cluster-admin 권한이 있는 계정.

프로세스

openshift-sriov-network-operator 네임스페이스를 생성하려면 다음 명령을 입력합니다.

cat << EOF| oc create -f -
apiVersion: v1
kind: Namespace
metadata:
  name: openshift-sriov-network-operator
  annotations:
    workload.openshift.io/allowed: management
EOF

$ cat << EOF| oc create -f -
apiVersion: v1
kind: Namespace
metadata:
  name: openshift-sriov-network-operator
  annotations:
    workload.openshift.io/allowed: management
EOF

Copy to Clipboard

Toggle word wrap

OperatorGroup CR을 생성하려면 다음 명령을 입력합니다.

cat << EOF| oc create -f -
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: sriov-network-operators
  namespace: openshift-sriov-network-operator
spec:
  targetNamespaces:
  - openshift-sriov-network-operator
EOF

$ cat << EOF| oc create -f -
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: sriov-network-operators
  namespace: openshift-sriov-network-operator
spec:
  targetNamespaces:
  - openshift-sriov-network-operator
EOF

Copy to Clipboard

Toggle word wrap

SR-IOV Network Operator를 서브스크립션합니다.

다음 명령을 실행하여 OpenShift Container Platform 주 버전 및 부 버전을 가져옵니다. 다음 단계의 channel 값에 필요합니다.

OC_VERSION=$(oc version -o yaml | grep openshiftVersion | \
    grep -o '[0-9]*[.][0-9]*' | head -1)

$ OC_VERSION=$(oc version -o yaml | grep openshiftVersion | \
    grep -o '[0-9]*[.][0-9]*' | head -1)

Copy to Clipboard

Toggle word wrap

SR-IOV Network Operator에 대한 서브스크립션 CR을 만들려면 다음 명령을 입력합니다.

cat << EOF| oc create -f -
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: sriov-network-operator-subscription
  namespace: openshift-sriov-network-operator
spec:
  channel: "${OC_VERSION}"
  name: sriov-network-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace
EOF

$ cat << EOF| oc create -f -
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: sriov-network-operator-subscription
  namespace: openshift-sriov-network-operator
spec:
  channel: "${OC_VERSION}"
  name: sriov-network-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace
EOF

Copy to Clipboard

Toggle word wrap

Operator가 설치되었는지 확인하려면 다음 명령을 입력합니다.

oc get csv -n openshift-sriov-network-operator \
  -o custom-columns=Name:.metadata.name,Phase:.status.phase

$ oc get csv -n openshift-sriov-network-operator \
  -o custom-columns=Name:.metadata.name,Phase:.status.phase

Copy to Clipboard

Toggle word wrap

출력 예

Name                                         Phase
sriov-network-operator.4.12.0-202310121402   Succeeded

Name                                         Phase
sriov-network-operator.4.12.0-202310121402   Succeeded

Copy to Clipboard

Toggle word wrap

20.2.1.2. 웹 콘솔 : SR-IOV Network Operator 설치
링크 복사

클러스터 관리자는 웹 콘솔을 사용하여 Operator를 설치할 수 있습니다.

사전 요구 사항

SR-IOV를 지원하는 하드웨어가 있는 노드로 베어 메탈 하드웨어에 설치된 클러스터.
OpenShift CLI(oc)를 설치합니다.
cluster-admin 권한이 있는 계정.

프로세스

SR-IOV Network Operator 설치:
1. OpenShift Container Platform 웹 콘솔에서 Operator → OperatorHub를 클릭합니다.
2. 사용 가능한 Operator 목록에서 SR-IOV Network Operator를 선택한 다음 설치를 클릭합니다.
3. Operator 설치 페이지의 설치된 네임스페이스에서 Operator 권장 네임스페이스 를 선택합니다.
4. 설치를 클릭합니다.
SR-IOV Network Operator가 설치되었는지 확인하십시오.
1. Operator → 설치된 Operator 페이지로 이동합니다.
2. SR-IOV Network Operator가 openshift-sriov-network-operator 프로젝트에 InstallSucceeded 상태로 나열되어 있는지 확인하십시오.
  참고
  설치 중에 Operator는 실패 상태를 표시할 수 있습니다. 나중에 InstallSucceeded 메시지와 함께 설치에 성공하면 이 실패 메시지를 무시할 수 있습니다.
  Operator가 설치된 것으로 나타나지 않으면 다음과 같이 추가 문제 해결을 수행합니다.
  - Operator 서브스크립션 및 설치 계획 탭의 상태 아래에서 장애 또는 오류가 있는지 점검합니다.
  - Workloads → Pod 페이지로 이동하여 openshift-sriov-network-operator 프로젝트에서 Pod 로그를 확인하십시오.
  - YAML 파일의 네임스페이스를 확인합니다. 주석이 누락된 경우 다음 명령을 사용하여 주석 workload.openshift.io/allowed=management 를 Operator 네임스페이스에 추가할 수 있습니다.
    
    $ oc annotate ns/openshift-sriov-network-operator workload.openshift.io/allowed=management
    
    Copy to Clipboard Toggle word wrap
    
    참고
    단일 노드 OpenShift 클러스터의 경우 주석 workload.openshift.io/allowed=management 가 네임스페이스에 필요합니다.

20.2.2. 다음 단계
링크 복사

선택사항: SR-IOV Network Operator 구성

20.3. SR-IOV Network Operator 구성
링크 복사

SR-IOV(Single Root I/O Virtualization) Network Operator는 클러스터의 SR-IOV 네트워크 장치 및 네트워크 첨부 파일을 관리합니다.

20.3.1. SR-IOV Network Operator 구성
링크 복사

중요

SR-IOV Network Operator 구성 수정은 일반적으로 필요하지 않습니다. 대부분의 사용 사례에는 기본 구성이 권장됩니다. Operator의 기본 동작이 사용 사례와 호환되지 않는 경우에만 관련 구성을 수정하는 단계를 완료하십시오.

SR-IOV Network Operator는 SriovOperatorConfig.sriovnetwork.openshift.io CustomResourceDefinition 리소스를 추가합니다. Operator는 openshift-sriov-network-operator 네임스페이스에 default 라는 SriovOperatorConfig CR(사용자 정의 리소스)을 자동으로 생성합니다.

참고

default CR에는 클러스터에 대한 SR-IOV Network Operator 구성이 포함됩니다. Operator 구성을 변경하려면 이 CR을 수정해야 합니다.

20.3.1.1. SR-IOV Network Operator 구성 사용자 정의 리소스
링크 복사

다음 표에는 sriovoperatorconfig 사용자 정의 리소스의 필드가 설명되어 있습니다.

Expand

표 20.2. SR-IOV Network Operator 구성 사용자 정의 리소스
필드	유형	설명
`metadata.name`	`string`	SR-IOV Network Operator 인스턴스의 이름을 지정합니다. 기본값은 `default`입니다. 다른 값을 설정하지 마십시오.
`metadata.namespace`	`string`	SR-IOV Network Operator 인스턴스의 네임스페이스를 지정합니다. 기본값은 `openshift-sriov-network-operator` 입니다. 다른 값을 설정하지 마십시오.
`spec.configDaemonNodeSelector`	`string`	선택한 노드에서 SR-IOV Network Config Daemon을 제어하는 노드 선택을 지정합니다. 기본적으로 이 필드는 설정되지 않으며 Operator는 작업자 노드에 SR-IOV Network Config 데몬 세트를 배포합니다.
`spec.disableDrain`	`boolean`	노드에 NIC를 구성하기 위해 새 정책을 적용할 때 노드 드레이닝 프로세스를 비활성화하거나 노드 드레이닝 프로세스를 활성화할지 여부를 지정합니다. 이 필드를 `true` 로 설정하면 소프트웨어 개발 및 OpenShift Container Platform을 단일 노드에 설치할 수 있습니다. 기본적으로 이 필드는 설정되지 않습니다. 단일 노드 클러스터의 경우 Operator를 설치한 후 이 필드를 `true` 로 설정합니다. 이 필드는 `true` 로 설정되어야 합니다.
`spec.enableInjector`	`boolean`	Network Resources Injector 데몬 세트를 활성화하거나 비활성화할지 여부를 지정합니다. 기본적으로 이 필드는 `true` 로 설정됩니다.
`spec.enableOperatorWebhook`	`boolean`	Operator Admission Controller 웹 후크 데몬 세트를 활성화하거나 비활성화할지 여부를 지정합니다. 기본적으로 이 필드는 `true` 로 설정됩니다.
`spec.logLevel`	`integer`	Operator의 로그 세부 정보 표시 수준을 지정합니다. 기본 로그만 표시하려면 `0` 으로 설정합니다. 사용 가능한 모든 로그를 표시하려면 `2` 로 설정합니다. 기본적으로 이 필드는 `2` 로 설정됩니다.

20.3.1.2. Network Resources Injector 정보
링크 복사

Network Resources Injector는 Kubernetes Dynamic Admission Controller 애플리케이션입니다. 다음과 같은 기능을 제공합니다.

SR-IOV 네트워크 연결 정의 주석에 따라 SR-IOV 리소스 이름을 추가하기 위해 Pod 사양의 리소스 요청 및 제한 변경
Pod 사양을 Downward API 볼륨으로 변경하여 Pod 주석, 라벨 및 대규모 페이지 요청 및 제한을 노출합니다. pod에서 실행되는 컨테이너는 /etc/podnetinfo 경로에 있는 파일로 노출된 정보에 액세스할 수 있습니다.

기본적으로 Network Resources Injector는 SR-IOV Network Operator에 의해 활성화되며 모든 컨트롤 플레인 노드에서 데몬 세트로 실행됩니다. 다음은 3개의 컨트롤 플레인 노드가 있는 클러스터에서 실행 중인 Network Resources Injector Pod의 예입니다.

oc get pods -n openshift-sriov-network-operator

$ oc get pods -n openshift-sriov-network-operator

Copy to Clipboard

Toggle word wrap

출력 예

NAME                                      READY   STATUS    RESTARTS   AGE
network-resources-injector-5cz5p          1/1     Running   0          10m
network-resources-injector-dwqpx          1/1     Running   0          10m
network-resources-injector-lktz5          1/1     Running   0          10m

NAME                                      READY   STATUS    RESTARTS   AGE
network-resources-injector-5cz5p          1/1     Running   0          10m
network-resources-injector-dwqpx          1/1     Running   0          10m
network-resources-injector-lktz5          1/1     Running   0          10m

Copy to Clipboard

Toggle word wrap

20.3.1.3. SR-IOV 네트워크 Operator Admission Controller webhook 정보
링크 복사

SR-IOV 네트워크 Operator Admission Controller webhook은 Kubernetes Dynamic Admission Controller 애플리케이션입니다. 다음과 같은 기능을 제공합니다.

SriovNetworkNodePolicy CR이 생성 또는 업데이트될 때 유효성 검사
CR을 만들거나 업데이트할 때 priority 및 deviceType 필드의 기본값을 설정하여 SriovNetworkNodePolicy CR 변경

기본적으로 SR-IOV 네트워크 Operator Admission Controller 웹 후크는 Operator에서 활성화하며 모든 컨트롤 플레인 노드에서 데몬 세트로 실행됩니다.

참고

SR-IOV Network Operator Admission Controller 웹 후크를 비활성화할 때 주의하십시오. 문제 해결과 같은 특정 상황에서 웹 후크를 비활성화하거나 지원되지 않는 장치를 사용하려는 경우 사용할 수 있습니다.

다음은 3개의 컨트롤 플레인 노드가 있는 클러스터에서 실행되는 Operator Admission Controller 웹 후크 Pod의 예입니다.

oc get pods -n openshift-sriov-network-operator

$ oc get pods -n openshift-sriov-network-operator

Copy to Clipboard

Toggle word wrap

출력 예

NAME                                      READY   STATUS    RESTARTS   AGE
operator-webhook-9jkw6                    1/1     Running   0          16m
operator-webhook-kbr5p                    1/1     Running   0          16m
operator-webhook-rpfrl                    1/1     Running   0          16m

NAME                                      READY   STATUS    RESTARTS   AGE
operator-webhook-9jkw6                    1/1     Running   0          16m
operator-webhook-kbr5p                    1/1     Running   0          16m
operator-webhook-rpfrl                    1/1     Running   0          16m

Copy to Clipboard

Toggle word wrap

20.3.1.4. 사용자 정의 노드 선택기 정보
링크 복사

SR-IOV Network Config 데몬은 클러스터 노드에서 SR-IOV 네트워크 장치를 검색하고 구성합니다. 기본적으로 클러스터의 모든 worker 노드에 배포됩니다. 노드 레이블을 사용하여 SR-IOV Network Config 데몬이 실행되는 노드를 지정할 수 있습니다.

20.3.1.5. Network Resources Injector 비활성화 또는 활성화
링크 복사

기본적으로 활성화되어 있는 Network Resources Injector를 비활성화하거나 활성화하려면 다음 절차를 완료하십시오.

사전 요구 사항

OpenShift CLI(oc)를 설치합니다.
cluster-admin 권한이 있는 사용자로 로그인합니다.
SR-IOV Network Operator가 설치되어 있어야 합니다.

프로세스

enableInjector 필드를 설정합니다. 기능을 비활성화하려면 <value>를 false로 바꾸고 기능을 활성화하려면 true로 바꿉니다.

oc patch sriovoperatorconfig default \
  --type=merge -n openshift-sriov-network-operator \
  --patch '{ "spec": { "enableInjector": <value> } }'

$ oc patch sriovoperatorconfig default \
  --type=merge -n openshift-sriov-network-operator \
  --patch '{ "spec": { "enableInjector": <value> } }'

Copy to Clipboard

Toggle word wrap

작은 정보

또는 다음 YAML을 적용하여 Operator를 업데이트할 수 있습니다.

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovOperatorConfig
metadata:
  name: default
  namespace: openshift-sriov-network-operator
spec:
  enableInjector: <value>

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovOperatorConfig
metadata:
  name: default
  namespace: openshift-sriov-network-operator
spec:
  enableInjector: <value>

Copy to Clipboard

Toggle word wrap

20.3.1.6. SR-IOV 네트워크 Operator Admission Controller webhook 비활성화 또는 활성화
링크 복사

Admission Controller webhook를 비활성화하거나 활성화하려면(기본적으로 활성화되어 있음) 다음 절차를 완료하십시오.

사전 요구 사항

OpenShift CLI(oc)를 설치합니다.
cluster-admin 권한이 있는 사용자로 로그인합니다.
SR-IOV Network Operator가 설치되어 있어야 합니다.

프로세스

enableOperatorWebhook 필드를 설정합니다. 기능을 비활성화하려면 <value>를 false로 바꾸고 활성화하려면 true로 바꿉니다.

oc patch sriovoperatorconfig default --type=merge \
  -n openshift-sriov-network-operator \
  --patch '{ "spec": { "enableOperatorWebhook": <value> } }'

$ oc patch sriovoperatorconfig default --type=merge \
  -n openshift-sriov-network-operator \
  --patch '{ "spec": { "enableOperatorWebhook": <value> } }'

Copy to Clipboard

Toggle word wrap

작은 정보

또는 다음 YAML을 적용하여 Operator를 업데이트할 수 있습니다.

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovOperatorConfig
metadata:
  name: default
  namespace: openshift-sriov-network-operator
spec:
  enableOperatorWebhook: <value>

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovOperatorConfig
metadata:
  name: default
  namespace: openshift-sriov-network-operator
spec:
  enableOperatorWebhook: <value>

Copy to Clipboard

Toggle word wrap

20.3.1.7. SR-IOV Network Config 데몬에 대한 사용자 정의 NodeSelector 구성
링크 복사

SR-IOV Network Config 데몬은 클러스터 노드에서 SR-IOV 네트워크 장치를 검색하고 구성합니다. 기본적으로 클러스터의 모든 worker 노드에 배포됩니다. 노드 레이블을 사용하여 SR-IOV Network Config 데몬이 실행되는 노드를 지정할 수 있습니다.

SR-IOV Network Config 데몬이 배포된 노드를 지정하려면 다음 절차를 완료하십시오.

중요

configDaemonNodeSelector 필드를 업데이트하면 선택한 각 노드에서 SR-IOV Network Config 데몬이 다시 생성됩니다. 데몬이 다시 생성되는 동안 클러스터 사용자는 새로운 SR-IOV 네트워크 노드 정책을 적용하거나 새로운 SR-IOV Pod를 만들 수 없습니다.

절차

Operator의 노드 선택기를 업데이트하려면 다음 명령을 입력합니다.

oc patch sriovoperatorconfig default --type=json \
  -n openshift-sriov-network-operator \
  --patch '[{
      "op": "replace",
      "path": "/spec/configDaemonNodeSelector",
      "value": {<node_label>}
    }]'

$ oc patch sriovoperatorconfig default --type=json \
  -n openshift-sriov-network-operator \
  --patch '[{
      "op": "replace",
      "path": "/spec/configDaemonNodeSelector",
      "value": {<node_label>}
    }]'

Copy to Clipboard

Toggle word wrap

"node-role.kubernetes.io/worker": ""에서와 같이 적용하려면 <node_label>을 레이블로 바꿉니다.

작은 정보

또는 다음 YAML을 적용하여 Operator를 업데이트할 수 있습니다.

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovOperatorConfig
metadata:
  name: default
  namespace: openshift-sriov-network-operator
spec:
  configDaemonNodeSelector:
    <node_label>

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovOperatorConfig
metadata:
  name: default
  namespace: openshift-sriov-network-operator
spec:
  configDaemonNodeSelector:
    <node_label>

Copy to Clipboard

Toggle word wrap

20.3.1.8. 단일 노드 설치를 위한 SR-IOV Network Operator 구성
링크 복사

기본적으로 SR-IOV Network Operator는 모든 정책이 변경되기 전에 노드에서 워크로드를 드레인합니다. Operator는 재구성하기 전에 가상 기능을 사용하는 워크로드가 없는지 확인하기 위해 이 작업을 수행합니다.

단일 노드에 설치하는 경우 워크로드를 수신할 다른 노드가 없습니다. 결과적으로 단일 노드에서 워크로드를 드레이닝하지 않도록 Operator를 구성해야 합니다.

중요

드레이닝 워크로드를 비활성화하려면 다음 절차를 수행한 후 SR-IOV 네트워크 인터페이스를 사용하는 모든 워크로드를 제거한 후 SR-IOV 네트워크 노드 정책을 변경해야 합니다.

사전 요구 사항

OpenShift CLI(oc)를 설치합니다.
cluster-admin 권한이 있는 사용자로 로그인합니다.
SR-IOV Network Operator가 설치되어 있어야 합니다.

절차

disableDrain 필드를 true 로 설정하려면 다음 명령을 입력합니다.

oc patch sriovoperatorconfig default --type=merge \
  -n openshift-sriov-network-operator \
  --patch '{ "spec": { "disableDrain": true } }'

$ oc patch sriovoperatorconfig default --type=merge \
  -n openshift-sriov-network-operator \
  --patch '{ "spec": { "disableDrain": true } }'

Copy to Clipboard

Toggle word wrap

작은 정보

또는 다음 YAML을 적용하여 Operator를 업데이트할 수 있습니다.

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovOperatorConfig
metadata:
  name: default
  namespace: openshift-sriov-network-operator
spec:
  disableDrain: true

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovOperatorConfig
metadata:
  name: default
  namespace: openshift-sriov-network-operator
spec:
  disableDrain: true

Copy to Clipboard

Toggle word wrap

20.3.2. 다음 단계
링크 복사

SR-IOV 네트워크 장치 구성

20.4. SR-IOV 네트워크 장치 구성
링크 복사

클러스터에서 SR-IOV(Single Root I/O Virtualization) 장치를 구성할 수 있습니다.

20.4.1. SR-IOV 네트워크 노드 구성 오브젝트
링크 복사

SR-IOV 네트워크 노드 정책을 생성하여 노드의 SR-IOV 네트워크 장치 구성을 지정합니다. 정책의 API 오브젝트는 sriovnetwork.openshift.io API 그룹의 일부입니다.

다음 YAML은 SR-IOV 네트워크 노드 정책을 설명합니다.

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: <name> 
  namespace: openshift-sriov-network-operator 
spec:
  resourceName: <sriov_resource_name> 
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true" 
  priority: <priority> 
  mtu: <mtu> 
  needVhostNet: false 
  numVfs: <num> 
  nicSelector: 
    vendor: "<vendor_code>" 
    deviceID: "<device_id>" 
    pfNames: ["<pf_name>", ...] 
    rootDevices: ["<pci_bus_id>", ...] 
    netFilter: "<filter_string>" 
  deviceType: <device_type> 
  isRdma: false 
    linkType: <link_type> 
  eSwitchMode: "switchdev"

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: <name>

1


  namespace: openshift-sriov-network-operator

2


spec:
  resourceName: <sriov_resource_name>

3


  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"

4


  priority: <priority>

5


  mtu: <mtu>

6


  needVhostNet: false

7


  numVfs: <num>

8


  nicSelector:

9


    vendor: "<vendor_code>"

10


    deviceID: "<device_id>"

11


    pfNames: ["<pf_name>", ...]

12


    rootDevices: ["<pci_bus_id>", ...]

13


    netFilter: "<filter_string>"

14


  deviceType: <device_type>

15


  isRdma: false

16


    linkType: <link_type>

17


  eSwitchMode: "switchdev"

18

Copy to Clipboard

Toggle word wrap

사용자 정의 리소스 오브젝트의 이름입니다.

SR-IOV Network Operator가 설치된 네임스페이스입니다.

SR-IOV 네트워크 장치 플러그인의 리소스 이름입니다. 리소스 이름에 대한 SR-IOV 네트워크 노드 정책을 여러 개 생성할 수 있습니다.

이름을 지정할 때 resourceName 에서 허용된 구문 표현식 ^[a-zA-Z0-9_]+$ 를 사용해야 합니다.

4

노드 선택기는 구성할 노드를 지정합니다. 선택한 노드의 SR-IOV 네트워크 장치만 구성됩니다. SR-IOV CNI(Container Network Interface) 플러그인 및 장치 플러그인은 선택한 노드에만 배포됩니다.

5

선택 사항: 우선순위는 0에서 99 사이의 정수 값입니다. 작은 값은 우선순위가 높습니다. 예를 들어 우선순위 10은 우선순위 99보다 높습니다. 기본값은 99입니다.

6

선택사항: 가상 기능의 최대 전송 단위(MTU)입니다. 최대 MTU 값은 네트워크 인터페이스 컨트롤러(NIC) 모델마다 다를 수 있습니다.

7

선택 사항: pod에 /dev/vhost-net 장치를 마운트하려면 needVhostNet을 true로 설정합니다. DPDK(Data Plane Development Kit)와 함께 마운트된 /dev/vhost-net 장치를 사용하여 트래픽을 커널 네트워크 스택으로 전달합니다.

8

SR-IOV 물리적 네트워크 장치에 생성할 VF(가상 기능) 수입니다. Intel NIC(Network Interface Controller)의 경우 VF 수는 장치에서 지원하는 총 VF보다 클 수 없습니다. Mellanox NIC의 경우 VF 수는 128보다 클 수 없습니다.

9

NIC 선택기는 Operator가 구성할 장치를 식별합니다. 모든 매개변수에 값을 지정할 필요는 없습니다. 실수로 장치를 선택하지 않도록 네트워크 장치를 정확하게 파악하는 것이 좋습니다.

rootDevices를 지정하면 vendor, deviceID 또는 pfNames의 값도 지정해야 합니다. pfNames와 rootDevices를 동시에 지정하는 경우 동일한 장치를 참조하는지 확인하십시오. netFilter의 값을 지정하는 경우 네트워크 ID가 고유하므로 다른 매개변수를 지정할 필요가 없습니다.

10

선택 사항: SR-IOV 네트워크 장치의 벤더 16진수 코드입니다. 허용되는 값은 8086 및 15b3입니다.

11

선택사항: SR-IOV 네트워크 장치의 장치 16진수 코드입니다. 예를 들어 101b는 Mellanox ConnectX-6 장치의 장치 ID입니다.

12

선택사항: 장치에 대해 하나 이상의 물리적 기능(PF) 이름으로 구성된 배열입니다.

13

선택 사항: 장치의 PF에 대해 하나 이상의 PCI 버스 주소로 구성된 배열입니다. 주소를 0000:02: 00.1 형식으로 입력합니다.

14

선택 사항: 플랫폼별 네트워크 필터입니다. 지원되는 유일한 플랫폼은 RHOSP(Red Hat OpenStack Platform)입니다. 허용 가능한 값은 다음 형식을 사용합니다. openstack/NetworkID:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx. xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx를 /var/config/openstack/latest/network_data.json 메타데이터 파일의 값으로 바꿉니다.

15

선택사항: 가상 기능의 드라이버 유형입니다. 허용되는 값은 netdevice 및 vfio-pci입니다. 기본값은 netdevice입니다.

베어 메탈 노드의 DPDK 모드에서 Mellanox NIC가 작동하려면 netdevice 드라이버 유형을 사용하고 isRdma를 true로 설정합니다.

16

선택 사항: 원격 직접 메모리 액세스(RDMA) 모드를 활성화할지 여부를 구성합니다. 기본값은 false입니다.

isRdma 매개변수가 true로 설정된 경우 RDMA 사용 VF를 일반 네트워크 장치로 계속 사용할 수 있습니다. 어느 모드에서나 장치를 사용할 수 있습니다.

isRdma를 true로 설정하고 추가로 needVhostNet을 true로 설정하여 Fast Datapath DPDK 애플리케이션에서 사용할 Mellanox NIC를 구성합니다.

17

선택사항: VF의 링크 유형입니다. 기본값은 이더넷의 경우 eth 입니다. InfiniBand의 경우 이 값을 'ib'로 변경합니다.

linkType을 ib로 설정하면 isRdma가 SR-IOV Network Operator 웹 후크에 의해 자동으로 true로 설정됩니다. linkType을 ib로 설정하면 deviceType을 vfio-pci로 설정해서는 안 됩니다.

장치 플러그인에서 보고한 장치 수가 잘못될 수 있으므로 linkType을 SriovNetworkNodePolicy의 'eth'로 설정하지 마십시오.

18

선택 사항: 하드웨어 오프로드를 활성화하려면 'eSwitchMode' 필드를 "switchdev" 로 설정해야 합니다.

20.4.1.1. SR-IOV 네트워크 노드 구성 예
링크 복사

다음 예제에서는 InfiniBand 장치의 구성을 설명합니다.

InfiniBand 장치의 구성 예

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: policy-ib-net-1
  namespace: openshift-sriov-network-operator
spec:
  resourceName: ibnic1
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  numVfs: 4
  nicSelector:
    vendor: "15b3"
    deviceID: "101b"
    rootDevices:
      - "0000:19:00.0"
  linkType: ib
  isRdma: true

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: policy-ib-net-1
  namespace: openshift-sriov-network-operator
spec:
  resourceName: ibnic1
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  numVfs: 4
  nicSelector:
    vendor: "15b3"
    deviceID: "101b"
    rootDevices:
      - "0000:19:00.0"
  linkType: ib
  isRdma: true

Copy to Clipboard

Toggle word wrap

다음 예제에서는 RHOSP 가상 머신의 SR-IOV 네트워크 장치에 대한 구성을 설명합니다.

가상 머신의 SR-IOV 장치 구성 예

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: policy-sriov-net-openstack-1
  namespace: openshift-sriov-network-operator
spec:
  resourceName: sriovnic1
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  numVfs: 1 
  nicSelector:
    vendor: "15b3"
    deviceID: "101b"
    netFilter: "openstack/NetworkID:ea24bd04-8674-4f69-b0ee-fa0b3bd20509"

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: policy-sriov-net-openstack-1
  namespace: openshift-sriov-network-operator
spec:
  resourceName: sriovnic1
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  numVfs: 1

1


  nicSelector:
    vendor: "15b3"
    deviceID: "101b"
    netFilter: "openstack/NetworkID:ea24bd04-8674-4f69-b0ee-fa0b3bd20509"

2

Copy to Clipboard

Toggle word wrap

1: 가상 머신에 대한 노드 네트워크 정책을 구성할 때 numVfs 필드는 항상 1로 설정됩니다.
2: 가상 머신이 RHOSP에 배포될 때 netFilter 필드는 네트워크 ID를 참조해야 합니다. netFilter의 유효한 값은 SriovNetworkNodeState 오브젝트에서 사용할 수 있습니다.

20.4.1.2. SR-IOV 장치의 VF(가상 기능) 파티셔닝
링크 복사

경우에 따라 동일한 물리적 기능(PF)의 VF(가상 기능)를 여러 리소스 풀로 분할할 수 있습니다. 예를 들어, 일부 VF를 기본 드라이버로 로드하고 나머지 VF를vfio-pci 드라이버로 로드할 수 있습니다. 이러한 배포에서 SriovNetworkNodePolicy CR(사용자 정의 리소스)의 pfNames 선택기를 사용하여 <pfname>#<first_vf>-<last_vf> 형식을 사용하여 풀의 VF 범위를 지정할 수 있습니다.

예를 들어 다음 YAML은 VF 2에서 7까지의 netpf0 인터페이스에 대한 선택기를 보여줍니다.

pfNames: ["netpf0#2-7"]

pfNames: ["netpf0#2-7"]

Copy to Clipboard

Toggle word wrap

netpf0은 PF 인터페이스 이름입니다.
2는 범위에 포함된 첫 번째 VF 인덱스(0 기반)입니다.
7은 범위에 포함된 마지막 VF 인덱스(0 기반)입니다.

다음 요구 사항이 충족되면 다른 정책 CR을 사용하여 동일한 PF에서 VF를 선택할 수 있습니다.

동일한 PF를 선택하는 정책의 경우 numVfs 값이 동일해야 합니다.
VF 색인은 0에서 <numVfs>-1까지의 범위 내에 있어야 합니다. 예를 들어, numVfs가 8로 설정된 정책이 있는 경우 <first_vf> 값은 0보다 작아야 하며 <last_vf>는 7보다 크지 않아야 합니다.
다른 정책의 VF 범위는 겹치지 않아야 합니다.
<first_vf>는 <last_vf>보다 클 수 없습니다.

다음 예는 SR-IOV 장치의 NIC 파티셔닝을 보여줍니다.

정책 policy-net-1은 기본 VF 드라이버와 함께 PF netpf0의 VF 0을 포함하는 리소스 풀 net-1을 정의합니다. 정책 policy-net-1-dpdk는 vfio VF 드라이버와 함께 PF netpf0의 VF 8 ~ 15를 포함하는 리소스 풀 net-1-dpdk를 정의합니다.

정책 policy-net-1:

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: policy-net-1
  namespace: openshift-sriov-network-operator
spec:
  resourceName: net1
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  numVfs: 16
  nicSelector:
    pfNames: ["netpf0#0-0"]
  deviceType: netdevice

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: policy-net-1
  namespace: openshift-sriov-network-operator
spec:
  resourceName: net1
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  numVfs: 16
  nicSelector:
    pfNames: ["netpf0#0-0"]
  deviceType: netdevice

Copy to Clipboard

Toggle word wrap

정책 policy-net-1-dpdk:

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: policy-net-1-dpdk
  namespace: openshift-sriov-network-operator
spec:
  resourceName: net1dpdk
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  numVfs: 16
  nicSelector:
    pfNames: ["netpf0#8-15"]
  deviceType: vfio-pci

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: policy-net-1-dpdk
  namespace: openshift-sriov-network-operator
spec:
  resourceName: net1dpdk
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  numVfs: 16
  nicSelector:
    pfNames: ["netpf0#8-15"]
  deviceType: vfio-pci

Copy to Clipboard

Toggle word wrap

인터페이스가 성공적으로 분할되었는지 확인

다음 명령을 실행하여 SR-IOV 장치의 VF(가상 기능)로 분할된 인터페이스를 확인합니다.

ip link show <interface>

$ ip link show <interface>

1

Copy to Clipboard

Toggle word wrap

1: & lt;interface >를 SR-IOV 장치의 VF로 파티셔닝할 때 지정한 인터페이스로 교체합니다(예: ens3f1 ).

출력 예

5: ens3f1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether 3c:fd:fe:d1:bc:01 brd ff:ff:ff:ff:ff:ff

vf 0     link/ether 5a:e7:88:25:ea:a0 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
vf 1     link/ether 3e:1d:36:d7:3d:49 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
vf 2     link/ether ce:09:56:97:df:f9 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
vf 3     link/ether 5e:91:cf:88:d1:38 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
vf 4     link/ether e6:06:a1:96:2f:de brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off

5: ens3f1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether 3c:fd:fe:d1:bc:01 brd ff:ff:ff:ff:ff:ff

vf 0     link/ether 5a:e7:88:25:ea:a0 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
vf 1     link/ether 3e:1d:36:d7:3d:49 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
vf 2     link/ether ce:09:56:97:df:f9 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
vf 3     link/ether 5e:91:cf:88:d1:38 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
vf 4     link/ether e6:06:a1:96:2f:de brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off

Copy to Clipboard

Toggle word wrap

20.4.2. SR-IOV 네트워크 장치 구성
링크 복사

SR-IOV Network Operator는 SriovNetworkNodePolicy.sriovnetwork.openshift.io CustomResourceDefinition을 OpenShift Container Platform에 추가합니다. SriovNetworkNodePolicy CR(사용자 정의 리소스)을 만들어 SR-IOV 네트워크 장치를 구성할 수 있습니다.

참고

SriovNetworkNodePolicy 오브젝트에 지정된 구성을 적용하면 SR-IOV Operator가 노드를 비우고 경우에 따라 노드를 재부팅할 수 있습니다.

구성 변경 사항을 적용하는 데 몇 분이 걸릴 수 있습니다.

사전 요구 사항

OpenShift CLI(oc)를 설치합니다.
cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
SR-IOV Network Operator가 설치되어 있습니다.
비운 노드에서 제거된 워크로드를 처리하기 위해 클러스터에 사용 가능한 노드가 충분합니다.
SR-IOV 네트워크 장치 구성에 대한 컨트롤 플레인 노드를 선택하지 않았습니다.

절차

SriovNetworkNodePolicy 오브젝트를 생성한 후 YAML을 <name>-sriov-node-network.yaml 파일에 저장합니다. <name>을 이 구성의 이름으로 바꿉니다.
선택 사항: SR-IOV 가능 클러스터 노드에 SriovNetworkNodePolicy.Spec.NodeSelector 레이블이 지정되지 않은 경우 레이블을 지정합니다. 노드 레이블링에 대한 자세한 내용은 "노드에서 라벨을 업데이트하는 방법"을 참조하십시오.
SriovNetworkNodePolicy 오브젝트를 생성합니다.
```
oc create -f <name>-sriov-node-network.yaml
```
```
$ oc create -f <name>-sriov-node-network.yaml
```
Copy to Clipboard Toggle word wrap
<name>은 이 구성의 이름을 지정합니다.
구성 업데이트를 적용하면 sriov-network-operator 네임스페이스의 모든 Pod가 Running 상태로 전환됩니다.
SR-IOV 네트워크 장치가 구성되어 있는지 확인하려면 다음 명령을 입력합니다. <node_name>을 방금 구성한 SR-IOV 네트워크 장치가 있는 노드 이름으로 바꿉니다.
```
oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name> -o jsonpath='{.status.syncStatus}'
```
```
$ oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name> -o jsonpath='{.status.syncStatus}'
```
Copy to Clipboard Toggle word wrap

20.4.3. SR-IOV 구성 문제 해결
링크 복사

SR-IOV 네트워크 장치를 구성하는 절차를 수행한 후 다음 섹션에서는 일부 오류 조건을 다룹니다.

노드 상태를 표시하려면 다음 명령을 실행합니다.

oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name>

$ oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name>

Copy to Clipboard

Toggle word wrap

여기서 <node_name>은 SR-IOV 네트워크 장치가 있는 노드의 이름을 지정합니다.

오류 출력 : 메모리를 할당할 수 없음

"lastSyncError": "write /sys/bus/pci/devices/0000:3b:00.1/sriov_numvfs: cannot allocate memory"

"lastSyncError": "write /sys/bus/pci/devices/0000:3b:00.1/sriov_numvfs: cannot allocate memory"

Copy to Clipboard

Toggle word wrap

노드가 메모리를 할당할 수 없음을 나타내는 경우 다음 항목을 확인합니다.

글로벌 SR-IOV 설정이 노드의 BIOS에서 활성화되어 있는지 확인합니다.
BIOS에서 노드에 대해 VT-d가 활성화되어 있는지 확인합니다.

20.4.4. SR-IOV 네트워크를 VRF에 할당
링크 복사

클러스터 관리자는 CNI VRF 플러그인을 사용하여 SR-IOV 네트워크 인터페이스를 VRF 도메인에 할당할 수 있습니다.

이렇게 하려면 SriovNetwork 리소스의 선택적 metaPlugins 매개변수에 VRF 구성을 추가합니다.

참고

VRF를 사용하는 애플리케이션은 특정 장치에 바인딩해야 합니다. 일반적인 사용은 소켓에 SO_BINDTODEVICE 옵션을 사용하는 것입니다. SO_BINDTODEVICE는 소켓을 전달된 인터페이스 이름(예: eth1)에 지정된 장치에 바인딩합니다. SO_BINDTODEVICE를 사용하려면 애플리케이션에 CAP_NET_RAW 기능이 있어야 합니다.

OpenShift Container Platform Pod에서는 ip vrf exec 명령을 통해 VRF를 사용할 수 없습니다. VRF를 사용하려면 애플리케이션을 VRF 인터페이스에 직접 바인딩합니다.

20.4.4.1. CNI VRF 플러그인으로 추가 SR-IOV 네트워크 연결 생성
링크 복사

SR-IOV Network Operator는 추가 네트워크 정의를 관리합니다. 생성할 추가 SR-IOV 네트워크를 지정하면 SR-IOV Network Operator가 NetworkAttachmentDefinition CR(사용자 정의 리소스)을 자동으로 생성합니다.

참고

SR-IOV Network Operator가 관리하는 NetworkAttachmentDefinition 사용자 정의 리소스를 편집하지 마십시오. 편집하면 추가 네트워크의 네트워크 트래픽이 중단될 수 있습니다.

CNI VRF 플러그인으로 추가 SR-IOV 네트워크 연결을 생성하려면 다음 절차를 수행합니다.

사전 요구 사항

OpenShift Container Platform CLI, oc를 설치합니다.
cluster-admin 역할의 사용자로 OpenShift Container Platform 클러스터에 로그인합니다.

절차

추가 SR-IOV 네트워크 연결에 대한 SriovNetwork CR(사용자 정의 리소스)을 생성하고 다음 예제 CR과 같이 metaPlugins 구성을 삽입합니다. YAML을 sriov-network-attachment.yaml 파일로 저장합니다.

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: example-network
  namespace: additional-sriov-network-1
spec:
  ipam: |
    {
      "type": "host-local",
      "subnet": "10.56.217.0/24",
      "rangeStart": "10.56.217.171",
      "rangeEnd": "10.56.217.181",
      "routes": [{
        "dst": "0.0.0.0/0"
      }],
      "gateway": "10.56.217.1"
    }
  vlan: 0
  resourceName: intelnics
  metaPlugins : |
    {
      "type": "vrf", 
      "vrfname": "example-vrf-name" 
    }

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: example-network
  namespace: additional-sriov-network-1
spec:
  ipam: |
    {
      "type": "host-local",
      "subnet": "10.56.217.0/24",
      "rangeStart": "10.56.217.171",
      "rangeEnd": "10.56.217.181",
      "routes": [{
        "dst": "0.0.0.0/0"
      }],
      "gateway": "10.56.217.1"
    }
  vlan: 0
  resourceName: intelnics
  metaPlugins : |
    {
      "type": "vrf",

1


      "vrfname": "example-vrf-name"

2

Copy to Clipboard

Toggle word wrap

1: type은 vrf로 설정해야 합니다.
2: vrfname은 인터페이스가 할당된 VRF의 이름입니다. 포드에 없는 경우 생성됩니다.

SriovNetwork 리소스를 생성합니다.
```
oc create -f sriov-network-attachment.yaml
```
```
$ oc create -f sriov-network-attachment.yaml
```
Copy to Clipboard Toggle word wrap

NetworkAttachmentDefinition CR이 성공적으로 생성되었는지 확인

SR-IOV Network Operator가 다음 명령을 실행하여 NetworkAttachmentDefinition CR을 생성했는지 확인합니다.
```
oc get network-attachment-definitions -n <namespace>
```
```
$ oc get network-attachment-definitions -n <namespace> 
```
1
Copy to Clipboard Toggle word wrap
1
<namespace>를 네트워크 연결을 구성할 때 지정한 네임스페이스(예: additional-sriov-network-1)로 바꿉니다.
출력 예
```
NAME                            AGE
additional-sriov-network-1      14m
```
```
NAME                            AGE
additional-sriov-network-1      14m
```
Copy to Clipboard Toggle word wrap
참고
SR-IOV Network Operator가 CR을 생성하기 전에 지연이 발생할 수 있습니다.

추가 SR-IOV 네트워크 연결에 성공했는지 확인

VRF CNI가 올바르게 구성되어 추가 SR-IOV 네트워크 연결이 연결되었는지 확인하려면 다음을 수행하십시오.

VRF CNI를 사용하는 SR-IOV 네트워크를 생성합니다.
포드에 네트워크를 할당합니다.
포드 네트워크 연결이 SR-IOV 추가 네트워크에 연결되어 있는지 확인합니다. Pod로 원격 쉘을 설치하고 다음 명령을 실행합니다.
```
ip vrf show
```
```
$ ip vrf show
```
Copy to Clipboard Toggle word wrap
출력 예
```
Name              Table
-----------------------
red                 10
```
```
Name              Table
-----------------------
red                 10
```
Copy to Clipboard Toggle word wrap

VRF 인터페이스가 보조 인터페이스의 마스터인지 확인합니다.

ip link

$ ip link

Copy to Clipboard

Toggle word wrap

출력 예

...
5: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master red state UP mode
...

...
5: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master red state UP mode
...

Copy to Clipboard

Toggle word wrap

20.4.5. 다음 단계
링크 복사

SR-IOV 네트워크 연결 구성

20.5. SR-IOV 이더넷 네트워크 연결 구성
링크 복사

클러스터에서 SR-IOV(Single Root I/O Virtualization) 장치에 대한 이더넷 네트워크 연결을 구성할 수 있습니다.

20.5.1. 이더넷 장치 구성 오브젝트
링크 복사

SriovNetwork 오브젝트를 정의하여 이더넷 네트워크 장치를 구성할 수 있습니다.

다음 YAML은 SriovNetwork 오브젝트를 설명합니다.

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: <name> 
  namespace: openshift-sriov-network-operator 
spec:
  resourceName: <sriov_resource_name> 
  networkNamespace: <target_namespace> 
  vlan: <vlan> 
  spoofChk: "<spoof_check>" 
  ipam: |- 
    {}
  linkState: <link_state> 
  maxTxRate: <max_tx_rate> 
  minTxRate: <min_tx_rate> 
  vlanQoS: <vlan_qos> 
  trust: "<trust_vf>" 
  capabilities: <capabilities>

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: <name>

1


  namespace: openshift-sriov-network-operator

2


spec:
  resourceName: <sriov_resource_name>

3


  networkNamespace: <target_namespace>

4


  vlan: <vlan>

5


  spoofChk: "<spoof_check>"

6


  ipam: |-

7


    {}
  linkState: <link_state>

8


  maxTxRate: <max_tx_rate>

9


  minTxRate: <min_tx_rate>

10


  vlanQoS: <vlan_qos>

11


  trust: "<trust_vf>"

12


  capabilities: <capabilities>

13

Copy to Clipboard

Toggle word wrap

1: 오브젝트의 이름입니다. SR-IOV Network Operator는 동일한 이름으로 NetworkAttachmentDefinition 오브젝트를 생성합니다.
2: SR-IOV Network Operator가 설치된 네임스페이스입니다.
3: 이 추가 네트워크에 대한 SR-IOV 하드웨어를 정의하는 SriovNetworkNodePolicy 오브젝트의 spec.resourceName 매개변수 값입니다.
4: SriovNetwork 오브젝트의 대상 네임스페이스입니다. 대상 네임스페이스의 포드만 추가 네트워크에 연결할 수 있습니다.
5: 선택사항: 추가 네트워크의 VLAN(Virtual LAN) ID입니다. 정수 값은 0에서 4095 사이여야 합니다. 기본값은 0입니다.
6: 선택사항: VF의 스푸핑 검사 모드입니다. 허용되는 값은 문자열 "on" 및 "off"입니다.
중요
SR-IOV Network Operator가 지정한 값을 따옴표로 묶거나 오브젝트를 거부해야 합니다.
7: YAML 블록 스칼라 IPAM CNI 플러그인에 대한 구성 오브젝트입니다. 플러그인은 연결 정의에 대한 IP 주소 할당을 관리합니다.
8: 선택사항: VF(가상 기능)의 링크 상태입니다. 허용되는 값은 enable, disable 및 auto입니다.
9: 선택사항: VF의 경우 최대 전송 속도(Mbps)입니다.
10: 선택사항: VF의 경우 최소 전송 속도(Mbps)입니다. 이 값은 최대 전송 속도보다 작거나 같아야 합니다.
참고
인텔 NIC는 minTxRate 매개변수를 지원하지 않습니다. 자세한 내용은 BZ#1772847에서 참조하십시오.
11: 선택사항: VF의 IEEE 802.1p 우선순위 수준입니다. 기본값은 0입니다.
12: 선택사항: VF의 신뢰 모드입니다. 허용되는 값은 문자열 "on" 및 "off"입니다.
중요
지정한 값을 따옴표로 묶어야 합니다. 그렇지 않으면 SR-IOV Network Operator에서 오브젝트를 거부합니다.
13: 선택사항: 이 추가 네트워크에 구성할 수 있는 기능입니다. "{"ips": true}" 를 지정하여 IP 주소 지원을 활성화하거나 "{"mac":true}"를 지정하여 MAC 주소 지원을 활성화할 수 있습니다.

20.5.1.1. 추가 네트워크에 대한 IP 주소 할당 구성
링크 복사

IP 주소 관리(IPAM) CNI(Container Network Interface) 플러그인은 다른 CNI 플러그인에 대한 IP 주소를 제공합니다.

다음 IP 주소 할당 유형을 사용할 수 있습니다.

정적 할당
DHCP 서버를 통한 동적 할당. 지정한 DHCP 서버는 추가 네트워크에서 연결할 수 있어야 합니다.
Whereabouts IPAM CNI 플러그인을 통한 동적 할당

20.5.1.1.1. 고정 IP 주소 할당 구성
링크 복사

다음 표에서는 고정 IP 주소 할당 구성에 대해 설명합니다.

Expand

표 20.3. IPAM 고정 구성 오브젝트
필드	유형	설명
`type`	`string`	IPAM 주소 유형입니다. `static` 값이 필요합니다.
`주소`	`array`	가상 인터페이스에 할당할 IP 주소를 지정하는 개체의 배열입니다. IPv4 및 IPv6 IP 주소가 모두 지원됩니다.
`routes`	`array`	Pod 내부에서 구성할 경로를 지정하는 오브젝트의 배열입니다.
`dns`	`array`	선택 사항: DNS 구성을 지정하는 오브젝트의 배열입니다.

addresses 배열에는 다음 필드가 있는 오브젝트가 필요합니다.

Expand

표 20.4. ipam.addresses[] array
필드	유형	설명
`주소`	`string`	지정하는 IP 주소 및 네트워크 접두사입니다. 예를 들어 `10.10.21.10/24`를 지정하면 추가 네트워크에 IP 주소 `10.10.21.10`이 할당되고 넷마스크는 `255.255.255.0`입니다.
`gateway`	`string`	송신 네트워크 트래픽을 라우팅할 기본 게이트웨이입니다.

Expand

표 20.5. ipam.routes[] array
필드	유형	설명
`dst`	`string`	CIDR 형식의 IP 주소 범위(예: 기본 경로의 경우 `192.168.17.0/24` 또는 `0.0.0.0/0` )입니다.
`gw`	`string`	네트워크 트래픽이 라우팅되는 게이트웨이입니다.

Expand

표 20.6. ipam.dns object
필드	유형	설명
`nameservers`	`array`	DNS 쿼리를 보낼 하나 이상의 IP 주소로 구성된 배열입니다.
`domain`	`array`	호스트 이름에 추가할 기본 도메인입니다. 예를 들어 도메인이 `example.com`으로 설정되면 `example-host`에 대한 DNS 조회 쿼리가 `example-host.example.com`으로 다시 작성됩니다.
`search`	`array`	DNS 조회 쿼리 중에 규정되지 않은 호스트 이름(예: `example-host`)에 추가할 도메인 이름 배열입니다.

고정 IP 주소 할당 구성 예

{
  "ipam": {
    "type": "static",
      "addresses": [
        {
          "address": "191.168.1.7/24"
        }
      ]
  }
}

{
  "ipam": {
    "type": "static",
      "addresses": [
        {
          "address": "191.168.1.7/24"
        }
      ]
  }
}

Copy to Clipboard

Toggle word wrap

20.5.1.1.2. DHCP(Dynamic IP 주소) 할당 구성
링크 복사

다음 JSON은 DHCP를 사용한 동적 IP 주소 할당 구성을 설명합니다.

DHCP 리스 갱신

pod는 생성될 때 원래 DHCP 리스를 얻습니다. 리스는 클러스터에서 실행되는 최소 DHCP 서버 배포를 통해 주기적으로 갱신되어야 합니다.

SR-IOV Network Operator는 DHCP 서버 배포를 생성하지 않습니다. Cluster Network Operator자는 최소 DHCP 서버 배포를 생성합니다.

DHCP 서버 배포를 트리거하려면 다음 예와 같이 Cluster Network Operator 구성을 편집하여 shim 네트워크 연결을 만들어야 합니다.

shim 네트워크 연결 정의 예

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  additionalNetworks:
  - name: dhcp-shim
    namespace: default
    type: Raw
    rawCNIConfig: |-
      {
        "name": "dhcp-shim",
        "cniVersion": "0.3.1",
        "type": "bridge",
        "ipam": {
          "type": "dhcp"
        }
      }
  # ...

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  additionalNetworks:
  - name: dhcp-shim
    namespace: default
    type: Raw
    rawCNIConfig: |-
      {
        "name": "dhcp-shim",
        "cniVersion": "0.3.1",
        "type": "bridge",
        "ipam": {
          "type": "dhcp"
        }
      }
  # ...

Copy to Clipboard

Toggle word wrap

Expand

표 20.7. IPAM DHCP 구성 오브젝트
필드	유형	설명
`type`	`string`	IPAM 주소 유형입니다. 값 `dhcp` 가 필요합니다.

DHCP(Dynamic IP 주소) 할당 구성 예

{
  "ipam": {
    "type": "dhcp"
  }
}

{
  "ipam": {
    "type": "dhcp"
  }
}

Copy to Clipboard

Toggle word wrap

20.5.1.1.3. Whereabouts를 사용한 동적 IP 주소 할당 구성
링크 복사

Whereabouts CNI 플러그인을 사용하면 DHCP 서버를 사용하지 않고도 IP 주소를 추가 네트워크에 동적으로 할당할 수 있습니다.

다음 표에서는 Whereabouts를 사용한 동적 IP 주소 할당 구성을 설명합니다.

Expand

표 20.8. IPAM 위치 구성 오브젝트
필드	유형	설명
`type`	`string`	IPAM 주소 유형입니다. 값 `whereabouts` 가 필요합니다.
`범위`	`string`	CIDR 표기법의 IP 주소 및 범위입니다. IP 주소는 이 주소 범위 내에서 할당됩니다.
`exclude`	`array`	선택 사항: CIDR 표기법으로 0개 이상의 IP 주소 및 범위 목록입니다. 제외된 주소 범위 내의 IP 주소는 할당되지 않습니다.

Whereabouts를 사용하는 동적 IP 주소 할당 구성 예

{
  "ipam": {
    "type": "whereabouts",
    "range": "192.0.2.192/27",
    "exclude": [
       "192.0.2.192/30",
       "192.0.2.196/32"
    ]
  }
}

{
  "ipam": {
    "type": "whereabouts",
    "range": "192.0.2.192/27",
    "exclude": [
       "192.0.2.192/30",
       "192.0.2.196/32"
    ]
  }
}

Copy to Clipboard

Toggle word wrap

20.5.2. SR-IOV 추가 네트워크 구성
링크 복사

SriovNetwork 오브젝트를 생성하여 SR-IOV 하드웨어를 사용하는 추가 네트워크를 구성할 수 있습니다. SriovNetwork 오브젝트를 생성하면 SR-IOV Network Operator가 NetworkAttachmentDefinition 오브젝트를 자동으로 생성합니다.

참고

SriovNetwork 오브젝트가 running 상태의 Pod에 연결된 경우 해당 오브젝트를 수정하거나 삭제하지 마십시오.

사전 요구 사항

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

프로세스

SriovNetwork 오브젝트를 생성한 다음 <name>.yaml 파일에 YAML을 저장합니다. 여기서 <name>은 이 추가 네트워크의 이름입니다. 오브젝트 사양은 다음 예와 유사할 수 있습니다.

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: attach1
  namespace: openshift-sriov-network-operator
spec:
  resourceName: net1
  networkNamespace: project2
  ipam: |-
    {
      "type": "host-local",
      "subnet": "10.56.217.0/24",
      "rangeStart": "10.56.217.171",
      "rangeEnd": "10.56.217.181",
      "gateway": "10.56.217.1"
    }

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: attach1
  namespace: openshift-sriov-network-operator
spec:
  resourceName: net1
  networkNamespace: project2
  ipam: |-
    {
      "type": "host-local",
      "subnet": "10.56.217.0/24",
      "rangeStart": "10.56.217.171",
      "rangeEnd": "10.56.217.181",
      "gateway": "10.56.217.1"
    }

Copy to Clipboard

Toggle word wrap

오브젝트를 생성하려면 다음 명령을 입력합니다:
```
oc create -f <name>.yaml
```
```
$ oc create -f <name>.yaml
```
Copy to Clipboard Toggle word wrap
여기서 <name>은 추가 네트워크의 이름을 지정합니다.
선택사항: 이전 단계에서 생성한 SriovNetwork 오브젝트에 연결된 NetworkAttachmentDefinition 오브젝트가 존재하는지 확인하려면 다음 명령을 입력합니다. <namespace>를 SriovNetwork 오브젝트에 지정한 networkNamespace로 바꿉니다.
```
oc get net-attach-def -n <namespace>
```
```
$ oc get net-attach-def -n <namespace>
```
Copy to Clipboard Toggle word wrap

20.5.3. 다음 단계
링크 복사

SR-IOV 추가 네트워크에 pod 추가

20.6. SR-IOV InfiniBand 네트워크 연결 구성
링크 복사

클러스터에서 SR-IOV(Single Root I/O Virtualization) 장치에 대한 IB(InfiniBand) 네트워크 연결을 구성할 수 있습니다.

20.6.1. InfiniBand 장치 구성 오브젝트
링크 복사

SriovIBNetwork 오브젝트를 정의하여 IB(InfiniBand) 네트워크 장치를 구성할 수 있습니다.

다음 YAML은 SriovIBNetwork 오브젝트를 설명합니다.

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovIBNetwork
metadata:
  name: <name> 
  namespace: openshift-sriov-network-operator 
spec:
  resourceName: <sriov_resource_name> 
  networkNamespace: <target_namespace> 
  ipam: |- 
    {}
  linkState: <link_state> 
  capabilities: <capabilities>

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovIBNetwork
metadata:
  name: <name>

1


  namespace: openshift-sriov-network-operator

2


spec:
  resourceName: <sriov_resource_name>

3


  networkNamespace: <target_namespace>

4


  ipam: |-

5


    {}
  linkState: <link_state>

6


  capabilities: <capabilities>

7

Copy to Clipboard

Toggle word wrap

1: 오브젝트의 이름입니다. SR-IOV Network Operator는 동일한 이름으로 NetworkAttachmentDefinition 오브젝트를 생성합니다.
2: SR-IOV Operator가 설치된 네임스페이스입니다.
3: 이 추가 네트워크에 대한 SR-IOV 하드웨어를 정의하는 SriovNetworkNodePolicy 오브젝트의 spec.resourceName 매개변수 값입니다.
4: SriovIBNetwork 오브젝트의 대상 네임스페이스입니다. 대상 네임스페이스의 포드만 네트워크 장치에 연결할 수 있습니다.
5: 선택사항: YAML 블록 스칼라인 IPAM CNI 플러그인에 대한 구성 오브젝트입니다. 플러그인은 연결 정의에 대한 IP 주소 할당을 관리합니다.
6: 선택사항: VF(가상 기능)의 링크 상태입니다. 허용되는 값은 enable, disable, auto입니다.
7: 선택사항: 이 네트워크에 구성할 수 있는 기능입니다. IP 주소 지원을 사용하려면 "{ "ips": true }"를 지정하고 IB GUID(Global Unique Identifier) 지원을 사용하려면 "{ "infinibandGUID": true }"를 지정하면 됩니다.

20.6.1.1. 추가 네트워크에 대한 IP 주소 할당 구성
링크 복사

IP 주소 관리(IPAM) CNI(Container Network Interface) 플러그인은 다른 CNI 플러그인에 대한 IP 주소를 제공합니다.

다음 IP 주소 할당 유형을 사용할 수 있습니다.

정적 할당
DHCP 서버를 통한 동적 할당. 지정한 DHCP 서버는 추가 네트워크에서 연결할 수 있어야 합니다.
Whereabouts IPAM CNI 플러그인을 통한 동적 할당

20.6.1.1.1. 고정 IP 주소 할당 구성
링크 복사

다음 표에서는 고정 IP 주소 할당 구성에 대해 설명합니다.

Expand

표 20.9. IPAM 고정 구성 오브젝트
필드	유형	설명
`type`	`string`	IPAM 주소 유형입니다. `static` 값이 필요합니다.
`주소`	`array`	가상 인터페이스에 할당할 IP 주소를 지정하는 개체의 배열입니다. IPv4 및 IPv6 IP 주소가 모두 지원됩니다.
`routes`	`array`	Pod 내부에서 구성할 경로를 지정하는 오브젝트의 배열입니다.
`dns`	`array`	선택 사항: DNS 구성을 지정하는 오브젝트의 배열입니다.

addresses 배열에는 다음 필드가 있는 오브젝트가 필요합니다.

Expand

표 20.10. ipam.addresses[] array
필드	유형	설명
`주소`	`string`	지정하는 IP 주소 및 네트워크 접두사입니다. 예를 들어 `10.10.21.10/24`를 지정하면 추가 네트워크에 IP 주소 `10.10.21.10`이 할당되고 넷마스크는 `255.255.255.0`입니다.
`gateway`	`string`	송신 네트워크 트래픽을 라우팅할 기본 게이트웨이입니다.

Expand

표 20.11. ipam.routes[] array
필드	유형	설명
`dst`	`string`	CIDR 형식의 IP 주소 범위(예: 기본 경로의 경우 `192.168.17.0/24` 또는 `0.0.0.0/0` )입니다.
`gw`	`string`	네트워크 트래픽이 라우팅되는 게이트웨이입니다.

Expand

표 20.12. ipam.dns object
필드	유형	설명
`nameservers`	`array`	DNS 쿼리를 보낼 하나 이상의 IP 주소로 구성된 배열입니다.
`domain`	`array`	호스트 이름에 추가할 기본 도메인입니다. 예를 들어 도메인이 `example.com`으로 설정되면 `example-host`에 대한 DNS 조회 쿼리가 `example-host.example.com`으로 다시 작성됩니다.
`search`	`array`	DNS 조회 쿼리 중에 규정되지 않은 호스트 이름(예: `example-host`)에 추가할 도메인 이름 배열입니다.

고정 IP 주소 할당 구성 예

{
  "ipam": {
    "type": "static",
      "addresses": [
        {
          "address": "191.168.1.7/24"
        }
      ]
  }
}

{
  "ipam": {
    "type": "static",
      "addresses": [
        {
          "address": "191.168.1.7/24"
        }
      ]
  }
}

Copy to Clipboard

Toggle word wrap

20.6.1.1.2. DHCP(Dynamic IP 주소) 할당 구성
링크 복사

다음 JSON은 DHCP를 사용한 동적 IP 주소 할당 구성을 설명합니다.

DHCP 리스 갱신

pod는 생성될 때 원래 DHCP 리스를 얻습니다. 리스는 클러스터에서 실행되는 최소 DHCP 서버 배포를 통해 주기적으로 갱신되어야 합니다.

DHCP 서버 배포를 트리거하려면 다음 예와 같이 Cluster Network Operator 구성을 편집하여 shim 네트워크 연결을 만들어야 합니다.

shim 네트워크 연결 정의 예

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  additionalNetworks:
  - name: dhcp-shim
    namespace: default
    type: Raw
    rawCNIConfig: |-
      {
        "name": "dhcp-shim",
        "cniVersion": "0.3.1",
        "type": "bridge",
        "ipam": {
          "type": "dhcp"
        }
      }
  # ...

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  additionalNetworks:
  - name: dhcp-shim
    namespace: default
    type: Raw
    rawCNIConfig: |-
      {
        "name": "dhcp-shim",
        "cniVersion": "0.3.1",
        "type": "bridge",
        "ipam": {
          "type": "dhcp"
        }
      }
  # ...

Copy to Clipboard

Toggle word wrap

Expand

표 20.13. IPAM DHCP 구성 오브젝트
필드	유형	설명
`type`	`string`	IPAM 주소 유형입니다. 값 `dhcp` 가 필요합니다.

DHCP(Dynamic IP 주소) 할당 구성 예

{
  "ipam": {
    "type": "dhcp"
  }
}

{
  "ipam": {
    "type": "dhcp"
  }
}

Copy to Clipboard

Toggle word wrap

20.6.1.1.3. Whereabouts를 사용한 동적 IP 주소 할당 구성
링크 복사

Whereabouts CNI 플러그인을 사용하면 DHCP 서버를 사용하지 않고도 IP 주소를 추가 네트워크에 동적으로 할당할 수 있습니다.

다음 표에서는 Whereabouts를 사용한 동적 IP 주소 할당 구성을 설명합니다.

Expand

표 20.14. IPAM 위치 구성 오브젝트
필드	유형	설명
`type`	`string`	IPAM 주소 유형입니다. 값 `whereabouts` 가 필요합니다.
`범위`	`string`	CIDR 표기법의 IP 주소 및 범위입니다. IP 주소는 이 주소 범위 내에서 할당됩니다.
`exclude`	`array`	선택 사항: CIDR 표기법으로 0개 이상의 IP 주소 및 범위 목록입니다. 제외된 주소 범위 내의 IP 주소는 할당되지 않습니다.

Whereabouts를 사용하는 동적 IP 주소 할당 구성 예

{
  "ipam": {
    "type": "whereabouts",
    "range": "192.0.2.192/27",
    "exclude": [
       "192.0.2.192/30",
       "192.0.2.196/32"
    ]
  }
}

{
  "ipam": {
    "type": "whereabouts",
    "range": "192.0.2.192/27",
    "exclude": [
       "192.0.2.192/30",
       "192.0.2.196/32"
    ]
  }
}

Copy to Clipboard

Toggle word wrap

20.6.2. SR-IOV 추가 네트워크 구성
링크 복사

SriovIBNetwork 오브젝트를 생성하여 SR-IOV 하드웨어를 사용하는 추가 네트워크를 구성할 수 있습니다. SriovIBNetwork 오브젝트를 생성하면 SR-IOV Network Operator가 NetworkAttachmentDefinition 오브젝트를 자동으로 생성합니다.

참고

SriovIBNetwork 오브젝트가 running 상태의 Pod에 연결된 경우 해당 오브젝트를 수정하거나 삭제하지 마십시오.

사전 요구 사항

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

프로세스

SriovIBNetwork 오브젝트를 생성한 다음 <name>.yaml 파일에 YAML을 저장합니다. 여기서 <name>은 이 추가 네트워크의 이름입니다. 오브젝트 사양은 다음 예와 유사할 수 있습니다.

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovIBNetwork
metadata:
  name: attach1
  namespace: openshift-sriov-network-operator
spec:
  resourceName: net1
  networkNamespace: project2
  ipam: |-
    {
      "type": "host-local",
      "subnet": "10.56.217.0/24",
      "rangeStart": "10.56.217.171",
      "rangeEnd": "10.56.217.181",
      "gateway": "10.56.217.1"
    }

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovIBNetwork
metadata:
  name: attach1
  namespace: openshift-sriov-network-operator
spec:
  resourceName: net1
  networkNamespace: project2
  ipam: |-
    {
      "type": "host-local",
      "subnet": "10.56.217.0/24",
      "rangeStart": "10.56.217.171",
      "rangeEnd": "10.56.217.181",
      "gateway": "10.56.217.1"
    }

Copy to Clipboard

Toggle word wrap

오브젝트를 생성하려면 다음 명령을 입력합니다:
```
oc create -f <name>.yaml
```
```
$ oc create -f <name>.yaml
```
Copy to Clipboard Toggle word wrap
여기서 <name>은 추가 네트워크의 이름을 지정합니다.
선택 사항: 이전 단계에서 생성한 SriovIBNetwork 오브젝트에 연결된 NetworkAttachmentDefinition 오브젝트가 존재하는지 확인하려면 다음 명령을 입력합니다. <namespace>를 SriovIBNetwork 오브젝트에 지정한 networkNamespace로 바꿉니다.
```
oc get net-attach-def -n <namespace>
```
```
$ oc get net-attach-def -n <namespace>
```
Copy to Clipboard Toggle word wrap

20.6.3. 다음 단계
링크 복사

SR-IOV 추가 네트워크에 pod 추가

20.7. SR-IOV 추가 네트워크에 pod 추가
링크 복사

기존 SR-IOV(Single Root I/O Virtualization) 네트워크에 pod를 추가할 수 있습니다.

20.7.1. 네트워크 연결을 위한 런타임 구성
링크 복사

추가 네트워크에 pod를 연결할 때 런타임 구성을 지정하여 pod에 대한 특정 사용자 정의를 수행할 수 있습니다. 예를 들어 특정 MAC 하드웨어 주소를 요청할 수 있습니다.

Pod 사양에서 주석을 설정하여 런타임 구성을 지정합니다. 주석 키는 k8s.v1.cni.cncf.io/networks이며 런타임 구성을 설명하는 JSON 오브젝트를 허용합니다.

20.7.1.1. 이더넷 기반 SR-IOV 연결을 위한 런타임 구성
링크 복사

다음 JSON은 이더넷 기반 SR-IOV 네트워크 연결에 대한 런타임 구성 옵션을 설명합니다.

[
  {
    "name": "<name>", 
    "mac": "<mac_address>", 
    "ips": ["<cidr_range>"] 
  }
]

[
  {
    "name": "<name>",

1


    "mac": "<mac_address>",

2


    "ips": ["<cidr_range>"]

3

}
]

Copy to Clipboard

Toggle word wrap

1: SR-IOV 네트워크 연결 정의 CR의 이름입니다.
2: 선택사항: SR-IOV 네트워크 연결 정의 CR에 정의된 리소스 유형에서 할당된 SR-IOV 장치의 MAC 주소입니다. 이 기능을 사용하려면 SriovNetwork 오브젝트에 { "mac": true }도 지정해야 합니다.
3: 선택사항: SR-IOV 네트워크 연결 정의 CR에 정의된 리소스 유형에서 할당된 SR-IOV 장치의 IP 주소입니다. IPv4 및 IPv6 주소가 모두 지원됩니다. 이 기능을 사용하려면 SriovNetwork 오브젝트에 { "ips": true }도 지정해야 합니다.

런타임 구성 예

apiVersion: v1
kind: Pod
metadata:
  name: sample-pod
  annotations:
    k8s.v1.cni.cncf.io/networks: |-
      [
        {
          "name": "net1",
          "mac": "20:04:0f:f1:88:01",
          "ips": ["192.168.10.1/24", "2001::1/64"]
        }
      ]
spec:
  containers:
  - name: sample-container
    image: <image>
    imagePullPolicy: IfNotPresent
    command: ["sleep", "infinity"]

apiVersion: v1
kind: Pod
metadata:
  name: sample-pod
  annotations:
    k8s.v1.cni.cncf.io/networks: |-
      [
        {
          "name": "net1",
          "mac": "20:04:0f:f1:88:01",
          "ips": ["192.168.10.1/24", "2001::1/64"]
        }
      ]
spec:
  containers:
  - name: sample-container
    image: <image>
    imagePullPolicy: IfNotPresent
    command: ["sleep", "infinity"]

Copy to Clipboard

Toggle word wrap

20.7.1.2. InfiniBand 기반 SR-IOV 연결을 위한 런타임 구성
링크 복사

다음 JSON은 InfiniBand 기반 SR-IOV 네트워크 연결에 대한 런타임 구성 옵션을 설명합니다.

[
  {
    "name": "<network_attachment>", 
    "infiniband-guid": "<guid>", 
    "ips": ["<cidr_range>"] 
  }
]

[
  {
    "name": "<network_attachment>",

1


    "infiniband-guid": "<guid>",

2


    "ips": ["<cidr_range>"]

3

}
]

Copy to Clipboard

Toggle word wrap

1: SR-IOV 네트워크 연결 정의 CR의 이름입니다.
2: SR-IOV 장치의 InfiniBand GUID입니다. 이 기능을 사용하려면 SriovIBNetwork 오브젝트에 { "infinibandGUID": true }도 지정해야 합니다.
3: SR-IOV 네트워크 연결 정의 CR에 정의된 리소스 유형에서 할당된 SR-IOV 장치의 IP 주소입니다. IPv4 및 IPv6 주소가 모두 지원됩니다. 이 기능을 사용하려면 SriovIBNetwork 오브젝트에 { "ips": true }도 지정해야 합니다.

런타임 구성 예

apiVersion: v1
kind: Pod
metadata:
  name: sample-pod
  annotations:
    k8s.v1.cni.cncf.io/networks: |-
      [
        {
          "name": "ib1",
          "infiniband-guid": "c2:11:22:33:44:55:66:77",
          "ips": ["192.168.10.1/24", "2001::1/64"]
        }
      ]
spec:
  containers:
  - name: sample-container
    image: <image>
    imagePullPolicy: IfNotPresent
    command: ["sleep", "infinity"]

apiVersion: v1
kind: Pod
metadata:
  name: sample-pod
  annotations:
    k8s.v1.cni.cncf.io/networks: |-
      [
        {
          "name": "ib1",
          "infiniband-guid": "c2:11:22:33:44:55:66:77",
          "ips": ["192.168.10.1/24", "2001::1/64"]
        }
      ]
spec:
  containers:
  - name: sample-container
    image: <image>
    imagePullPolicy: IfNotPresent
    command: ["sleep", "infinity"]

Copy to Clipboard

Toggle word wrap

20.7.2. 추가 네트워크에 Pod 추가
링크 복사

추가 네트워크에 Pod를 추가할 수 있습니다. Pod는 기본 네트워크를 통해 정상적인 클러스터 관련 네트워크 트래픽을 계속 전송합니다.

Pod가 생성되면 추가 네트워크가 연결됩니다. 그러나 Pod가 이미 있는 경우에는 추가 네트워크를 연결할 수 없습니다.

Pod는 추가 네트워크와 동일한 네임스페이스에 있어야 합니다.

참고

SR-IOV Network Resource Injector는 리소스 필드를 Pod의 첫 번째 컨테이너에 자동으로 추가합니다.

DPDK(Data Plane Development Kit) 모드에서 Intel NIC(네트워크 인터페이스 컨트롤러)를 사용하는 경우 Pod의 첫 번째 컨테이너만 NIC에 액세스하도록 구성되어 있습니다. SriovNetworkNodePolicy 오브젝트에서 deviceType 이 vfio-pci 로 설정된 경우 SR-IOV 추가 네트워크가 DPDK 모드에 대해 구성됩니다.

NIC에 액세스해야 하는 컨테이너가 Pod 오브젝트에 정의된 첫 번째 컨테이너인지 아니면 Network Resource Injector를 비활성화하여 이 문제를 해결할 수 있습니다. 자세한 내용은 BZ#1990953 에서 참조하십시오.

사전 요구 사항

OpenShift CLI(oc)를 설치합니다.
클러스터에 로그인합니다.
SR-IOV Operator를 설치합니다.
Pod를 연결할 SriovNetwork 오브젝트 또는 SriovIBNetwork 오브젝트를 생성합니다.

절차

Pod 오브젝트에 주석을 추가합니다. 다음 주석 형식 중 하나만 사용할 수 있습니다.
1. 사용자 정의 없이 추가 네트워크를 연결하려면 다음 형식으로 주석을 추가합니다. <network>를 Pod와 연결할 추가 네트워크의 이름으로 변경합니다.
  metadata: annotations: k8s.v1.cni.cncf.io/networks: <network>[,<network>,...]
  1
  Copy to Clipboard Toggle word wrap
  1
  둘 이상의 추가 네트워크를 지정하려면 각 네트워크를 쉼표로 구분합니다. 쉼표 사이에 공백을 포함하지 마십시오. 동일한 추가 네트워크를 여러 번 지정하면 Pod에 해당 네트워크에 대한 인터페이스가 여러 개 연결됩니다.
2. 사용자 정의된 추가 네트워크를 연결하려면 다음 형식으로 주석을 추가합니다.
  metadata: annotations: k8s.v1.cni.cncf.io/networks: |- [ { "name": "<network>",
  1
  "namespace": "<namespace>",
  2
  "default-route": ["<default-route>"]
  3
  } ]
  Copy to Clipboard Toggle word wrap
  1
  NetworkAttachmentDefinition 오브젝트에서 정의한 추가 네트워크의 이름을 지정합니다.
  2
  NetworkAttachmentDefinition 오브젝트가 정의된 네임스페이스를 지정합니다.
  3
  선택 사항: 기본 경로에 대한 재정의를 지정합니다(예: 192.168.17.1).
Pod를 생성하려면 다음 명령을 입력합니다. <name>을 Pod 이름으로 교체합니다.
```
oc create -f <name>.yaml
```
```
$ oc create -f <name>.yaml
```
Copy to Clipboard Toggle word wrap

선택사항: Pod CR에 주석이 있는지 확인하려면 다음 명령을 입력하고 <name>을 Pod 이름으로 교체합니다.

oc get pod <name> -o yaml

$ oc get pod <name> -o yaml

Copy to Clipboard

Toggle word wrap

다음 예에서 example-pod Pod는 net1 추가 네트워크에 연결되어 있습니다.

oc get pod example-pod -o yaml
apiVersion: v1
kind: Pod
metadata:
  annotations:
    k8s.v1.cni.cncf.io/networks: macvlan-bridge
    k8s.v1.cni.cncf.io/networks-status: |-
      [{
          "name": "openshift-sdn",
          "interface": "eth0",
          "ips": [
              "10.128.2.14"
          ],
          "default": true,
          "dns": {}
      },{
          "name": "macvlan-bridge",
          "interface": "net1",
          "ips": [
              "20.2.2.100"
          ],
          "mac": "22:2f:60:a5:f8:00",
          "dns": {}
      }]
  name: example-pod
  namespace: default
spec:
  ...
status:
  ...

$ oc get pod example-pod -o yaml
apiVersion: v1
kind: Pod
metadata:
  annotations:
    k8s.v1.cni.cncf.io/networks: macvlan-bridge
    k8s.v1.cni.cncf.io/networks-status: |-

1


      [{
          "name": "openshift-sdn",
          "interface": "eth0",
          "ips": [
              "10.128.2.14"
          ],
          "default": true,
          "dns": {}
      },{
          "name": "macvlan-bridge",
          "interface": "net1",
          "ips": [
              "20.2.2.100"
          ],
          "mac": "22:2f:60:a5:f8:00",
          "dns": {}
      }]
  name: example-pod
  namespace: default
spec:
  ...
status:
  ...

Copy to Clipboard

Toggle word wrap

1: k8s.v1.cni.cncf.io/networks-status 매개변수는 JSON 오브젝트 배열입니다. 각 오브젝트는 Pod에 연결된 추가 네트워크의 상태를 설명합니다. 주석 값은 일반 텍스트 값으로 저장됩니다.

20.7.3. NUMA(Non-Uniform Memory Access) 정렬 SR-IOV Pod 생성
링크 복사

SR-IOV 및 제한된 또는 single-numa-node 토폴로지 관리자 정책으로 동일한 NUMA 노드에서 할당된 CPU 리소스를 제한하여 NUMA 정렬 SR-IOV Pod를 생성할 수 있습니다.

사전 요구 사항

OpenShift CLI(oc)가 설치되어 있습니다.
CPU 관리자 정책을 static으로 구성했습니다. CPU 관리자에 대한 자세한 내용은 "추가 리소스" 섹션을 참조하십시오.
토폴로지 관리자 정책을 single-numa-node로 구성했습니다.
참고
single-numa-node가 요청을 충족할 수 없는 경우 Topology Manager 정책을 restricted로 구성할 수 있습니다.

절차

다음과 같은 SR-IOV Pod 사양을 생성한 다음 YAML을 <name>-sriov-pod.yaml 파일에 저장합니다. <name>을 이 Pod의 이름으로 바꿉니다.

다음 예는 SR-IOV Pod 사양을 보여줍니다.

apiVersion: v1
kind: Pod
metadata:
  name: sample-pod
  annotations:
    k8s.v1.cni.cncf.io/networks: <name> 
spec:
  containers:
  - name: sample-container
    image: <image> 
    command: ["sleep", "infinity"]
    resources:
      limits:
        memory: "1Gi" 
        cpu: "2" 
      requests:
        memory: "1Gi"
        cpu: "2"

apiVersion: v1
kind: Pod
metadata:
  name: sample-pod
  annotations:
    k8s.v1.cni.cncf.io/networks: <name>

1


spec:
  containers:
  - name: sample-container
    image: <image>

2


    command: ["sleep", "infinity"]
    resources:
      limits:
        memory: "1Gi"

3


        cpu: "2"

4


      requests:
        memory: "1Gi"
        cpu: "2"

Copy to Clipboard

Toggle word wrap

1: <name>을 SR-IOV 네트워크 첨부 파일 정의 CR의 이름으로 바꿉니다.
2: <image>를 sample-pod 이미지의 이름으로 바꿉니다.
3: 보장된 QoS로 SR-IOV Pod를 생성하려면 메모리 제한을 메모리 요청과 동일하게 설정합니다.
4: 보장된 QoS로 SR-IOV Pod를 생성하려면 cpu 제한을 CPU 요청과 동일하게 설정합니다.

다음 명령을 실행하여 샘플 SR-IOV Pod를 만듭니다.
```
oc create -f <filename>
```
```
$ oc create -f <filename> 
```
1
Copy to Clipboard Toggle word wrap
1
<filename>을 이전 단계에서 생성한 파일 이름으로 바꿉니다.
sample-pod가 보장된 QoS로 구성되어 있는지 확인하십시오.
```
oc describe pod sample-pod
```
```
$ oc describe pod sample-pod
```
Copy to Clipboard Toggle word wrap

sample-pod에 전용 CPU가 할당되어 있는지 확인하십시오.

oc exec sample-pod -- cat /sys/fs/cgroup/cpuset/cpuset.cpus

$ oc exec sample-pod -- cat /sys/fs/cgroup/cpuset/cpuset.cpus

Copy to Clipboard

Toggle word wrap

sample-pod에 할당된 SR-IOV 장치 및 CPU가 동일한 NUMA 노드에 있는지 확인하십시오.
```
oc exec sample-pod -- cat /sys/fs/cgroup/cpuset/cpuset.cpus
```
```
$ oc exec sample-pod -- cat /sys/fs/cgroup/cpuset/cpuset.cpus
```
Copy to Clipboard Toggle word wrap

20.7.4. OpenStack에서 SR-IOV를 사용하는 클러스터의 테스트 pod 템플릿
링크 복사

다음 testpmd pod는 대규모 페이지, 예약된 CPU 및 SR-IOV 포트로 컨테이너 생성을 보여줍니다.

예제 testpmd Pod

apiVersion: v1
kind: Pod
metadata:
  name: testpmd-sriov
  namespace: mynamespace
  annotations:
    cpu-load-balancing.crio.io: "disable"
    cpu-quota.crio.io: "disable"
# ...
spec:
  containers:
  - name: testpmd
    command: ["sleep", "99999"]
    image: registry.redhat.io/openshift4/dpdk-base-rhel8:v4.9
    securityContext:
      capabilities:
        add: ["IPC_LOCK","SYS_ADMIN"]
      privileged: true
      runAsUser: 0
    resources:
      requests:
        memory: 1000Mi
        hugepages-1Gi: 1Gi
        cpu: '2'
        openshift.io/sriov1: 1
      limits:
        hugepages-1Gi: 1Gi
        cpu: '2'
        memory: 1000Mi
        openshift.io/sriov1: 1
    volumeMounts:
      - mountPath: /dev/hugepages
        name: hugepage
        readOnly: False
  runtimeClassName: performance-cnf-performanceprofile 
  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages

apiVersion: v1
kind: Pod
metadata:
  name: testpmd-sriov
  namespace: mynamespace
  annotations:
    cpu-load-balancing.crio.io: "disable"
    cpu-quota.crio.io: "disable"
# ...
spec:
  containers:
  - name: testpmd
    command: ["sleep", "99999"]
    image: registry.redhat.io/openshift4/dpdk-base-rhel8:v4.9
    securityContext:
      capabilities:
        add: ["IPC_LOCK","SYS_ADMIN"]
      privileged: true
      runAsUser: 0
    resources:
      requests:
        memory: 1000Mi
        hugepages-1Gi: 1Gi
        cpu: '2'
        openshift.io/sriov1: 1
      limits:
        hugepages-1Gi: 1Gi
        cpu: '2'
        memory: 1000Mi
        openshift.io/sriov1: 1
    volumeMounts:
      - mountPath: /dev/hugepages
        name: hugepage
        readOnly: False
  runtimeClassName: performance-cnf-performanceprofile

1


  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages

Copy to Clipboard

Toggle word wrap

1: 이 예에서는 성능 프로필의 이름이 cnf-performance 프로필 이라고 가정합니다.

20.8. SR-IOV 네트워크의 인터페이스 수준 네트워크 sysctl 설정 구성
링크 복사

클러스터 관리자는 SR-IOV 네트워크 장치에 연결된 Pod의 CNI(Container Network Interface) 메타 플러그인을 사용하여 인터페이스 수준 네트워크 sysctl을 수정할 수 있습니다.

20.8.1. SR-IOV 활성화된 NIC로 노드 레이블 지정
링크 복사

SR-IOV 가능 노드에서만 SR-IOV를 활성화하려면 다음과 같은 몇 가지 방법이 있습니다.

NFD(Node Feature Discovery) Operator를 설치합니다. NFD는 SR-IOV 활성화된 NIC의 존재를 감지하고 node.alpha.kubernetes-incubator.io/nfd-network-sriov.capable = true 로 노드에 레이블을 지정합니다.
각 노드의 SriovNetworkNodeState CR을 검사합니다. 인터페이스 스탠자에 는 작업자 노드에서 SR-IOV Network Operator가 검색한 모든 SR-IOV 장치 목록이 포함되어 있습니다. 다음 명령을 사용하여 feature.node.kubernetes.io/network-sriov.capable: "true" 로 각 노드에 레이블을 지정합니다.
```
$ oc label node <node_name> feature.node.kubernetes.io/network-sriov.capable="true"
```
```
$ oc label node <node_name> feature.node.kubernetes.io/network-sriov.capable="true"
```
Copy to Clipboard Toggle word wrap
참고
원하는 이름으로 노드에 라벨을 지정할 수 있습니다.

20.8.2. 하나의 sysctl 플래그 설정
링크 복사

SR-IOV 네트워크 장치에 연결된 Pod의 인터페이스 수준 네트워크 sysctl 설정을 설정할 수 있습니다.

이 예에서는 생성된 가상 인터페이스에서 net.ipv4.conf.IFNAME.accept_redirects 가 1 로 설정됩니다.

sysctl-tuning-test 는 이 예제에서 사용되는 네임스페이스입니다.

다음 명령을 사용하여 sysctl-tuning-test 네임스페이스를 생성합니다.
```
oc create namespace sysctl-tuning-test
```
```
$ oc create namespace sysctl-tuning-test
```
Copy to Clipboard Toggle word wrap

20.8.2.1. SR-IOV 네트워크 장치를 사용하여 노드에서 하나의 sysctl 플래그 설정
링크 복사

SR-IOV Network Operator는 SriovNetworkNodePolicy.sriovnetwork.openshift.io CRD(사용자 정의 리소스 정의)를 OpenShift Container Platform에 추가합니다. SriovNetworkNodePolicy CR(사용자 정의 리소스)을 생성하여 SR-IOV 네트워크 장치를 구성할 수 있습니다.

참고

SriovNetworkNodePolicy 오브젝트에 지정된 구성을 적용하면 SR-IOV Operator가 노드를 비우고 재부팅할 수 있습니다.

구성 변경 사항을 적용하는 데 몇 분이 걸릴 수 있습니다.

SriovNetworkNodePolicy CR(사용자 정의 리소스)을 생성하려면 다음 절차를 따르십시오.

프로세스

SriovNetworkNodePolicy CR(사용자 정의 리소스)을 생성합니다. 예를 들어 다음 YAML을 policyoneflag-sriov-node-network.yaml 파일로 저장합니다.
```
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: policyoneflag 
  namespace: openshift-sriov-network-operator 
spec:
  resourceName: policyoneflag 
  nodeSelector: 
    feature.node.kubernetes.io/network-sriov.capable="true"
  priority: 10 
  numVfs: 5 
  nicSelector: 
    pfNames: ["ens5"] 
  deviceType: "netdevice" 
  isRdma: false 
```
```
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: policyoneflag 
```
1
```
  namespace: openshift-sriov-network-operator 
```
2
```
spec:
  resourceName: policyoneflag 
```
3
```
  nodeSelector: 
```
4
```
    feature.node.kubernetes.io/network-sriov.capable="true"
  priority: 10 
```
5
```
  numVfs: 5 
```
6
```
  nicSelector: 
```
7
```
    pfNames: ["ens5"] 
```
8
```
  deviceType: "netdevice" 
```
9
```
  isRdma: false 
```
10
Copy to Clipboard Toggle word wrap
1
사용자 정의 리소스 오브젝트의 이름입니다.
2
SR-IOV Network Operator가 설치된 네임스페이스입니다.
3
SR-IOV 네트워크 장치 플러그인의 리소스 이름입니다. 리소스 이름에 대한 SR-IOV 네트워크 노드 정책을 여러 개 생성할 수 있습니다.
4
노드 선택기는 구성할 노드를 지정합니다. 선택한 노드의 SR-IOV 네트워크 장치만 구성됩니다. SR-IOV CNI(Container Network Interface) 플러그인 및 장치 플러그인은 선택한 노드에만 배포됩니다.
5
선택 사항: 우선순위는 0에서 99 사이의 정수 값입니다. 작은 값은 우선순위가 높습니다. 예를 들어 우선순위 10은 우선순위 99보다 높습니다. 기본값은 99입니다.
6
SR-IOV 물리적 네트워크 장치에 생성할 VF(가상 기능) 수입니다. Intel NIC(Network Interface Controller)의 경우 VF 수는 장치에서 지원하는 총 VF보다 클 수 없습니다. Mellanox NIC의 경우 VF 수는 128보다 클 수 없습니다.
7
NIC 선택기는 Operator가 구성할 장치를 식별합니다. 모든 매개변수에 값을 지정할 필요는 없습니다. 실수로 장치를 선택하지 않도록 네트워크 장치를 정확하게 파악하는 것이 좋습니다. rootDevices를 지정하면 vendor, deviceID 또는 pfNames의 값도 지정해야 합니다. pfNames와 rootDevices를 동시에 지정하는 경우 동일한 장치를 참조하는지 확인하십시오. netFilter의 값을 지정하는 경우 네트워크 ID가 고유하므로 다른 매개변수를 지정할 필요가 없습니다.
8
선택사항: 장치에 대해 하나 이상의 물리적 기능(PF) 이름으로 구성된 배열입니다.
9
선택사항: 가상 기능의 드라이버 유형입니다. 허용되는 유일한 값은 netdevice 입니다. 베어 메탈 노드에서 Mellanox NIC가 DPDK 모드에서 작동하려면 isRdma 를 true 로 설정합니다.
10
선택 사항: 원격 직접 메모리 액세스(RDMA) 모드를 활성화할지 여부를 구성합니다. 기본값은 false입니다. isRdma 매개변수가 true로 설정된 경우 RDMA 사용 VF를 일반 네트워크 장치로 계속 사용할 수 있습니다. 어느 모드에서나 장치를 사용할 수 있습니다. isRdma를 true로 설정하고 추가로 needVhostNet을 true로 설정하여 Fast Datapath DPDK 애플리케이션에서 사용할 Mellanox NIC를 구성합니다.
참고
vfio-pci 드라이버 유형은 지원되지 않습니다.
SriovNetworkNodePolicy 오브젝트를 생성합니다.
```
oc create -f policyoneflag-sriov-node-network.yaml
```
```
$ oc create -f policyoneflag-sriov-node-network.yaml
```
Copy to Clipboard Toggle word wrap
구성 업데이트를 적용하면 sriov-network-operator 네임스페이스의 모든 Pod가 실행 중 상태로 변경됩니다.
SR-IOV 네트워크 장치가 구성되어 있는지 확인하려면 다음 명령을 입력합니다. <node_name>을 방금 구성한 SR-IOV 네트워크 장치가 있는 노드 이름으로 바꿉니다.
```
oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name> -o jsonpath='{.status.syncStatus}'
```
```
$ oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name> -o jsonpath='{.status.syncStatus}'
```
Copy to Clipboard Toggle word wrap
출력 예
```
Succeeded
```
```
Succeeded
```
Copy to Clipboard Toggle word wrap

20.8.2.2. SR-IOV 네트워크에서 sysctl 구성
링크 복사

SriovNetwork 리소스의 선택적 metaPlugins 매개변수에 튜닝 구성을 추가하여 SR-IOV에서 생성한 가상 인터페이스에서 인터페이스별 sysctl 설정을 설정할 수 있습니다.

SR-IOV Network Operator는 추가 네트워크 정의를 관리합니다. 생성할 추가 SR-IOV 네트워크를 지정하면 SR-IOV Network Operator가 NetworkAttachmentDefinition CR(사용자 정의 리소스)을 자동으로 생성합니다.

참고

SR-IOV Network Operator가 관리하는 NetworkAttachmentDefinition 사용자 정의 리소스를 편집하지 마십시오. 편집하면 추가 네트워크의 네트워크 트래픽이 중단될 수 있습니다.

인터페이스 수준 네트워크 net.ipv4.conf.IFNAME.accept_redirects sysctl 설정을 변경하려면 CNI(Container Network Interface) 튜닝 플러그인을 사용하여 추가 SR-IOV 네트워크를 생성합니다.

사전 요구 사항

OpenShift Container Platform CLI, oc를 설치합니다.
cluster-admin 역할의 사용자로 OpenShift Container Platform 클러스터에 로그인합니다.

프로세스

추가 SR-IOV 네트워크 연결에 대한 SriovNetwork CR(사용자 정의 리소스)을 생성하고 다음 예제 CR과 같이 metaPlugins 구성을 삽입합니다. YAML을 sriov-network-interface-sysctl.yaml 파일로 저장합니다.
```
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: onevalidflag 
  namespace: openshift-sriov-network-operator 
spec:
  resourceName: policyoneflag 
  networkNamespace: sysctl-tuning-test 
  ipam: '{ "type": "static" }' 
  capabilities: '{ "mac": true, "ips": true }' 
  metaPlugins : | 
    {
      "type": "tuning",
      "capabilities":{
        "mac":true
      },
      "sysctl":{
         "net.ipv4.conf.IFNAME.accept_redirects": "1"
      }
    }
```
```
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: onevalidflag 
```
1
```
  namespace: openshift-sriov-network-operator 
```
2
```
spec:
  resourceName: policyoneflag 
```
3
```
  networkNamespace: sysctl-tuning-test 
```
4
```
  ipam: '{ "type": "static" }' 
```
5
```
  capabilities: '{ "mac": true, "ips": true }' 
```
6
```
  metaPlugins : | 
```
7
```
    {
      "type": "tuning",
      "capabilities":{
        "mac":true
      },
      "sysctl":{
         "net.ipv4.conf.IFNAME.accept_redirects": "1"
      }
    }
```
Copy to Clipboard Toggle word wrap
1
오브젝트의 이름입니다. SR-IOV Network Operator는 동일한 이름으로 NetworkAttachmentDefinition 오브젝트를 생성합니다.
2
SR-IOV Network Operator가 설치된 네임스페이스입니다.
3
이 추가 네트워크에 대한 SR-IOV 하드웨어를 정의하는 SriovNetworkNodePolicy 오브젝트의 spec.resourceName 매개변수 값입니다.
4
SriovNetwork 오브젝트의 대상 네임스페이스입니다. 대상 네임스페이스의 포드만 추가 네트워크에 연결할 수 있습니다.
5
YAML 블록 스칼라 IPAM CNI 플러그인에 대한 구성 오브젝트입니다. 플러그인은 연결 정의에 대한 IP 주소 할당을 관리합니다.
6
선택 사항: 추가 네트워크의 기능을 설정합니다. "{"ips": true}" 를 지정하여 IP 주소 지원을 활성화하거나 "{"mac":true}"를 지정하여 MAC 주소 지원을 활성화할 수 있습니다.
7
선택 사항: metaPlugins 매개 변수는 장치에 추가 기능을 추가하는 데 사용됩니다. 이 사용 사례에서는 유형 필드를 튜닝 으로 설정합니다. sysctl 필드에 설정할 인터페이스 수준 네트워크 sysctl 을 지정합니다.

SriovNetwork 리소스를 생성합니다.

oc create -f sriov-network-interface-sysctl.yaml

$ oc create -f sriov-network-interface-sysctl.yaml

Copy to Clipboard

Toggle word wrap

NetworkAttachmentDefinition CR이 성공적으로 생성되었는지 확인

SR-IOV Network Operator가 다음 명령을 실행 하여 NetworkAttach mentDefinition CR을 생성했는지 확인합니다.
```
oc get network-attachment-definitions -n <namespace>
```
```
$ oc get network-attachment-definitions -n <namespace> 
```
1
Copy to Clipboard Toggle word wrap
1
& lt;namespace >를 SriovNetwork 오브젝트에 지정한 networkNamespace 의 값으로 바꿉니다. 예를 들면 sysctl-tuning-test 입니다.
출력 예
```
NAME                                  AGE
onevalidflag                          14m
```
```
NAME                                  AGE
onevalidflag                          14m
```
Copy to Clipboard Toggle word wrap
참고
SR-IOV Network Operator가 CR을 생성하기 전에 지연이 발생할 수 있습니다.

추가 SR-IOV 네트워크 연결에 성공했는지 확인

튜닝 CNI가 올바르게 구성되어 추가 SR-IOV 네트워크 연결이 연결되었는지 확인하려면 다음을 수행하십시오.

Pod CR을 생성합니다. 다음 YAML을 examplepod.yaml 파일로 저장합니다.

apiVersion: v1
kind: Pod
metadata:
  name: tunepod
  namespace: sysctl-tuning-test
  annotations:
    k8s.v1.cni.cncf.io/networks: |-
      [
        {
          "name": "onevalidflag",  
          "mac": "0a:56:0a:83:04:0c", 
          "ips": ["10.100.100.200/24"] 
       }
      ]
spec:
  containers:
  - name: podexample
    image: centos
    command: ["/bin/bash", "-c", "sleep INF"]
    securityContext:
      runAsUser: 2000
      runAsGroup: 3000
      allowPrivilegeEscalation: false
      capabilities:
        drop: ["ALL"]
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault

apiVersion: v1
kind: Pod
metadata:
  name: tunepod
  namespace: sysctl-tuning-test
  annotations:
    k8s.v1.cni.cncf.io/networks: |-
      [
        {
          "name": "onevalidflag",

1


          "mac": "0a:56:0a:83:04:0c",

2


          "ips": ["10.100.100.200/24"]

3


       }
      ]
spec:
  containers:
  - name: podexample
    image: centos
    command: ["/bin/bash", "-c", "sleep INF"]
    securityContext:
      runAsUser: 2000
      runAsGroup: 3000
      allowPrivilegeEscalation: false
      capabilities:
        drop: ["ALL"]
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault

Copy to Clipboard

Toggle word wrap

1: SR-IOV 네트워크 연결 정의 CR의 이름입니다.
2: 선택사항: SR-IOV 네트워크 연결 정의 CR에 정의된 리소스 유형에서 할당된 SR-IOV 장치의 MAC 주소입니다. 이 기능을 사용하려면 SriovNetwork 오브젝트에 { "mac": true } 도 지정해야 합니다.
3: 선택사항: SR-IOV 네트워크 연결 정의 CR에 정의된 리소스 유형에서 할당된 SR-IOV 장치의 IP 주소입니다. IPv4 및 IPv6 주소가 모두 지원됩니다. 이 기능을 사용하려면 SriovNetwork 오브젝트에 { "ips": true }도 지정해야 합니다.

Pod CR을 생성합니다.
```
oc apply -f examplepod.yaml
```
```
$ oc apply -f examplepod.yaml
```
Copy to Clipboard Toggle word wrap

다음 명령을 실행하여 Pod가 생성되었는지 확인합니다.

oc get pod -n sysctl-tuning-test

$ oc get pod -n sysctl-tuning-test

Copy to Clipboard

Toggle word wrap

출력 예

NAME      READY   STATUS    RESTARTS   AGE
tunepod   1/1     Running   0          47s

NAME      READY   STATUS    RESTARTS   AGE
tunepod   1/1     Running   0          47s

Copy to Clipboard

Toggle word wrap

다음 명령을 실행하여 Pod에 로그인합니다.
```
oc rsh -n sysctl-tuning-test tunepod
```
```
$ oc rsh -n sysctl-tuning-test tunepod
```
Copy to Clipboard Toggle word wrap
구성된 sysctl 플래그 값을 확인합니다. 다음 명령을 실행하여 net.ipv4.conf.IFNAME.accept_redirects 값을 찾습니다.
```
sysctl net.ipv4.conf.net1.accept_redirects
```
```
$ sysctl net.ipv4.conf.net1.accept_redirects
```
Copy to Clipboard Toggle word wrap
출력 예
```
net.ipv4.conf.net1.accept_redirects = 1
```
```
net.ipv4.conf.net1.accept_redirects = 1
```
Copy to Clipboard Toggle word wrap

20.8.3. 결합된 SR-IOV 인터페이스 플래그와 연결된 Pod의 sysctl 설정 구성
링크 복사

결합된 SR-IOV 네트워크 장치에 연결된 Pod의 인터페이스 수준 네트워크 sysctl 설정을 설정할 수 있습니다.

이 예에서 구성할 수 있는 특정 네트워크 인터페이스 수준의 sysctl 설정은 본딩된 인터페이스에 설정됩니다.

sysctl-tuning-test 는 이 예제에서 사용되는 네임스페이스입니다.

다음 명령을 사용하여 sysctl-tuning-test 네임스페이스를 생성합니다.
```
oc create namespace sysctl-tuning-test
```
```
$ oc create namespace sysctl-tuning-test
```
Copy to Clipboard Toggle word wrap

20.8.3.1. 결합된 SR-IOV 네트워크 장치를 사용하여 노드에서 모든 sysctl 플래그 설정
링크 복사

SR-IOV Network Operator는 SriovNetworkNodePolicy.sriovnetwork.openshift.io CRD(사용자 정의 리소스 정의)를 OpenShift Container Platform에 추가합니다. SriovNetworkNodePolicy CR(사용자 정의 리소스)을 생성하여 SR-IOV 네트워크 장치를 구성할 수 있습니다.

참고

SriovNetworkNodePolicy 오브젝트에 지정된 구성을 적용하면 SR-IOV Operator가 노드를 비우고 경우에 따라 노드를 재부팅할 수 있습니다.

구성 변경 사항을 적용하는 데 몇 분이 걸릴 수 있습니다.

SriovNetworkNodePolicy CR(사용자 정의 리소스)을 생성하려면 다음 절차를 따르십시오.

프로세스

SriovNetworkNodePolicy CR(사용자 정의 리소스)을 생성합니다. 다음 YAML을 policyallflags-sriov-node-network.yaml 파일로 저장합니다. policyallflags 를 구성 이름으로 바꿉니다.
```
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: policyallflags 
  namespace: openshift-sriov-network-operator 
spec:
  resourceName: policyallflags 
  nodeSelector: 
    node.alpha.kubernetes-incubator.io/nfd-network-sriov.capable = `true`
  priority: 10 
  numVfs: 5 
  nicSelector: 
    pfNames: ["ens1f0"]  
  deviceType: "netdevice" 
  isRdma: false 
```
```
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: policyallflags 
```
1
```
  namespace: openshift-sriov-network-operator 
```
2
```
spec:
  resourceName: policyallflags 
```
3
```
  nodeSelector: 
```
4
```
    node.alpha.kubernetes-incubator.io/nfd-network-sriov.capable = `true`
  priority: 10 
```
5
```
  numVfs: 5 
```
6
```
  nicSelector: 
```
7
```
    pfNames: ["ens1f0"]  
```
8
```
  deviceType: "netdevice" 
```
9
```
  isRdma: false 
```
10
Copy to Clipboard Toggle word wrap
1
사용자 정의 리소스 오브젝트의 이름입니다.
2
SR-IOV Network Operator가 설치된 네임스페이스입니다.
3
SR-IOV 네트워크 장치 플러그인의 리소스 이름입니다. 리소스 이름에 대한 SR-IOV 네트워크 노드 정책을 여러 개 생성할 수 있습니다.
4
노드 선택기는 구성할 노드를 지정합니다. 선택한 노드의 SR-IOV 네트워크 장치만 구성됩니다. SR-IOV CNI(Container Network Interface) 플러그인 및 장치 플러그인은 선택한 노드에만 배포됩니다.
5
선택 사항: 우선순위는 0에서 99 사이의 정수 값입니다. 작은 값은 우선순위가 높습니다. 예를 들어 우선순위 10은 우선순위 99보다 높습니다. 기본값은 99입니다.
6
SR-IOV 물리적 네트워크 장치에 생성할 VF(가상 기능) 수입니다. Intel NIC(Network Interface Controller)의 경우 VF 수는 장치에서 지원하는 총 VF보다 클 수 없습니다. Mellanox NIC의 경우 VF 수는 128보다 클 수 없습니다.
7
NIC 선택기는 Operator가 구성할 장치를 식별합니다. 모든 매개변수에 값을 지정할 필요는 없습니다. 실수로 장치를 선택하지 않도록 네트워크 장치를 정확하게 파악하는 것이 좋습니다. rootDevices를 지정하면 vendor, deviceID 또는 pfNames의 값도 지정해야 합니다. pfNames와 rootDevices를 동시에 지정하는 경우 동일한 장치를 참조하는지 확인하십시오. netFilter의 값을 지정하는 경우 네트워크 ID가 고유하므로 다른 매개변수를 지정할 필요가 없습니다.
8
선택사항: 장치에 대해 하나 이상의 물리적 기능(PF) 이름으로 구성된 배열입니다.
9
선택사항: 가상 기능의 드라이버 유형입니다. 허용되는 유일한 값은 netdevice 입니다. 베어 메탈 노드에서 Mellanox NIC가 DPDK 모드에서 작동하려면 isRdma 를 true 로 설정합니다.
10
선택 사항: 원격 직접 메모리 액세스(RDMA) 모드를 활성화할지 여부를 구성합니다. 기본값은 false입니다. isRdma 매개변수가 true로 설정된 경우 RDMA 사용 VF를 일반 네트워크 장치로 계속 사용할 수 있습니다. 어느 모드에서나 장치를 사용할 수 있습니다. isRdma를 true로 설정하고 추가로 needVhostNet을 true로 설정하여 Fast Datapath DPDK 애플리케이션에서 사용할 Mellanox NIC를 구성합니다.
참고
vfio-pci 드라이버 유형은 지원되지 않습니다.
SriovNetworkNodePolicy 오브젝트를 생성합니다.
```
oc create -f policyallflags-sriov-node-network.yaml
```
```
$ oc create -f policyallflags-sriov-node-network.yaml
```
Copy to Clipboard Toggle word wrap
구성 업데이트를 적용하면 sriov-network-operator 네임스페이스의 모든 Pod가 실행 중 상태로 변경됩니다.
SR-IOV 네트워크 장치가 구성되어 있는지 확인하려면 다음 명령을 입력합니다. <node_name>을 방금 구성한 SR-IOV 네트워크 장치가 있는 노드 이름으로 바꿉니다.
```
oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name> -o jsonpath='{.status.syncStatus}'
```
```
$ oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name> -o jsonpath='{.status.syncStatus}'
```
Copy to Clipboard Toggle word wrap
출력 예
```
Succeeded
```
```
Succeeded
```
Copy to Clipboard Toggle word wrap

20.8.3.2. 결합된 SR-IOV 네트워크에서 sysctl 구성
링크 복사

두 SR-IOV 인터페이스에서 생성된 결합된 인터페이스에서 인터페이스별 sysctl 설정을 설정할 수 있습니다. 본딩 네트워크 연결 정의의 선택적 Plugins 매개변수에 튜닝 구성을 추가하여 이 작업을 수행합니다.

참고

SR-IOV Network Operator가 관리하는 NetworkAttachmentDefinition 사용자 정의 리소스를 편집하지 마십시오. 편집하면 추가 네트워크의 네트워크 트래픽이 중단될 수 있습니다.

특정 인터페이스 수준 네트워크 sysctl 설정을 변경하려면 다음 절차를 사용하여 CNI(Container Network Interface) 튜닝 플러그인을 사용하여 SriovNetwork CR(사용자 정의 리소스)을 생성합니다.

사전 요구 사항

OpenShift Container Platform CLI, oc를 설치합니다.
cluster-admin 역할의 사용자로 OpenShift Container Platform 클러스터에 로그인합니다.

프로세스

다음 예제 CR과 같이 결합된 인터페이스에 대한 SriovNetwork CR(사용자 정의 리소스)을 생성합니다. YAML을 sriov-network-attachment.yaml 파일로 저장합니다.
```
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: allvalidflags 
  namespace: openshift-sriov-network-operator 
spec:
  resourceName: policyallflags 
  networkNamespace: sysctl-tuning-test 
  capabilities: '{ "mac": true, "ips": true }' 
```
```
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: allvalidflags 
```
1
```
  namespace: openshift-sriov-network-operator 
```
2
```
spec:
  resourceName: policyallflags 
```
3
```
  networkNamespace: sysctl-tuning-test 
```
4
```
  capabilities: '{ "mac": true, "ips": true }' 
```
5
Copy to Clipboard Toggle word wrap
1
오브젝트의 이름입니다. SR-IOV Network Operator는 동일한 이름으로 NetworkAttachmentDefinition 오브젝트를 생성합니다.
2
SR-IOV Network Operator가 설치된 네임스페이스입니다.
3
이 추가 네트워크에 대한 SR-IOV 하드웨어를 정의하는 SriovNetworkNodePolicy 오브젝트의 spec.resourceName 매개변수 값입니다.
4
SriovNetwork 오브젝트의 대상 네임스페이스입니다. 대상 네임스페이스의 포드만 추가 네트워크에 연결할 수 있습니다.
5
선택사항: 이 추가 네트워크에 구성할 수 있는 기능입니다. "{"ips": true}" 를 지정하여 IP 주소 지원을 활성화하거나 "{"mac":true}"를 지정하여 MAC 주소 지원을 활성화할 수 있습니다.
SriovNetwork 리소스를 생성합니다.
```
oc create -f sriov-network-attachment.yaml
```
```
$ oc create -f sriov-network-attachment.yaml
```
Copy to Clipboard Toggle word wrap

다음 예제 CR에서와 같이 본딩 네트워크 연결 정의를 생성합니다. YAML을 sriov-bond-network-interface.yaml 파일로 저장합니다.

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  name: bond-sysctl-network
  namespace: sysctl-tuning-test
spec:
  config: '{
  "cniVersion":"0.4.0",
  "name":"bound-net",
  "plugins":[
    {
      "type":"bond", 
      "mode": "active-backup", 
      "failOverMac": 1, 
      "linksInContainer": true, 
      "miimon": "100",
      "links": [ 
        {"name": "net1"},
        {"name": "net2"}
      ],
      "ipam":{ 
        "type":"static"
      }
    },
    {
      "type":"tuning", 
      "capabilities":{
        "mac":true
      },
      "sysctl":{
        "net.ipv4.conf.IFNAME.accept_redirects": "0",
        "net.ipv4.conf.IFNAME.accept_source_route": "0",
        "net.ipv4.conf.IFNAME.disable_policy": "1",
        "net.ipv4.conf.IFNAME.secure_redirects": "0",
        "net.ipv4.conf.IFNAME.send_redirects": "0",
        "net.ipv6.conf.IFNAME.accept_redirects": "0",
        "net.ipv6.conf.IFNAME.accept_source_route": "1",
        "net.ipv6.neigh.IFNAME.base_reachable_time_ms": "20000",
        "net.ipv6.neigh.IFNAME.retrans_time_ms": "2000"
      }
    }
  ]
}'

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  name: bond-sysctl-network
  namespace: sysctl-tuning-test
spec:
  config: '{
  "cniVersion":"0.4.0",
  "name":"bound-net",
  "plugins":[
    {
      "type":"bond",

1


      "mode": "active-backup",

2


      "failOverMac": 1,

3


      "linksInContainer": true,

4


      "miimon": "100",
      "links": [

5


        {"name": "net1"},
        {"name": "net2"}
      ],
      "ipam":{

6


        "type":"static"
      }
    },
    {
      "type":"tuning",

7


      "capabilities":{
        "mac":true
      },
      "sysctl":{
        "net.ipv4.conf.IFNAME.accept_redirects": "0",
        "net.ipv4.conf.IFNAME.accept_source_route": "0",
        "net.ipv4.conf.IFNAME.disable_policy": "1",
        "net.ipv4.conf.IFNAME.secure_redirects": "0",
        "net.ipv4.conf.IFNAME.send_redirects": "0",
        "net.ipv6.conf.IFNAME.accept_redirects": "0",
        "net.ipv6.conf.IFNAME.accept_source_route": "1",
        "net.ipv6.neigh.IFNAME.base_reachable_time_ms": "20000",
        "net.ipv6.neigh.IFNAME.retrans_time_ms": "2000"
      }
    }
  ]
}'

Copy to Clipboard

Toggle word wrap

type은 bond 입니다.

mode 속성은 본딩 모드를 지정합니다. 지원되는 본딩 모드는 다음과 같습니다.

balance-rr - 0
active-backup - 1
balance-xor - 2
balance-rr 또는 balance-xor 모드의 경우 SR-IOV 가상 기능에 대해 신뢰 모드를 on 으로 설정해야 합니다.

장애 조치( failover ) 속성은 active-backup 모드에 필요합니다.

4

linksInContainer=true 플래그는 Bond CNI에 컨테이너 내부에 필요한 인터페이스가 있음을 알립니다. 기본적으로 Bond CNI는 SRIOV 및 Multus와의 통합에 작동하지 않는 호스트에서 이러한 인터페이스를 찾습니다.

5

links 섹션에서는 본딩을 만드는 데 사용할 인터페이스를 정의합니다. 기본적으로 Multus는 연결된 인터페이스의 이름을 "net"과 함께 1부터 시작하여 연속 숫자로 지정합니다.

6

YAML 블록 스칼라 IPAM CNI 플러그인에 대한 구성 오브젝트입니다. 플러그인은 연결 정의에 대한 IP 주소 할당을 관리합니다. 이 Pod 예제 IP 주소는 수동으로 구성되므로 이 경우ipam 이 static으로 설정됩니다.

7

장치에 추가 기능을 추가합니다. 예를 들어 type 필드를 튜닝 으로 설정합니다. sysctl 필드에 설정할 인터페이스 수준 네트워크 sysctl 을 지정합니다. 이 예에서는 설정할 수 있는 모든 인터페이스 수준 네트워크 sysctl 설정을 설정합니다.

본딩 네트워크 연결 리소스를 생성합니다.
```
oc create -f sriov-bond-network-interface.yaml
```
```
$ oc create -f sriov-bond-network-interface.yaml
```
Copy to Clipboard Toggle word wrap

NetworkAttachmentDefinition CR이 성공적으로 생성되었는지 확인

SR-IOV Network Operator가 다음 명령을 실행 하여 NetworkAttach mentDefinition CR을 생성했는지 확인합니다.
```
oc get network-attachment-definitions -n <namespace>
```
```
$ oc get network-attachment-definitions -n <namespace> 
```
1
Copy to Clipboard Toggle word wrap
1
< namespace >를 네트워크 연결을 구성할 때 지정한 networkNamespace로 변경합니다(예: sysctl-tuning-test ).
출력 예
```
NAME                          AGE
bond-sysctl-network           22m
allvalidflags                 47m
```
```
NAME                          AGE
bond-sysctl-network           22m
allvalidflags                 47m
```
Copy to Clipboard Toggle word wrap
참고
SR-IOV Network Operator가 CR을 생성하기 전에 지연이 발생할 수 있습니다.

추가 SR-IOV 네트워크 리소스가 성공했는지 확인

튜닝 CNI가 올바르게 구성되어 추가 SR-IOV 네트워크 연결이 연결되었는지 확인하려면 다음을 수행하십시오.

Pod CR을 생성합니다. 예를 들어 다음 YAML을 examplepod.yaml 파일로 저장합니다.

apiVersion: v1
kind: Pod
metadata:
  name: tunepod
  namespace: sysctl-tuning-test
  annotations:
    k8s.v1.cni.cncf.io/networks: |-
      [
        {"name": "allvalidflags"}, 
        {"name": "allvalidflags"},
        {
          "name": "bond-sysctl-network",
          "interface": "bond0",
          "mac": "0a:56:0a:83:04:0c", 
          "ips": ["10.100.100.200/24"] 
       }
      ]
spec:
  containers:
  - name: podexample
    image: centos
    command: ["/bin/bash", "-c", "sleep INF"]
    securityContext:
      runAsUser: 2000
      runAsGroup: 3000
      allowPrivilegeEscalation: false
      capabilities:
        drop: ["ALL"]
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault

apiVersion: v1
kind: Pod
metadata:
  name: tunepod
  namespace: sysctl-tuning-test
  annotations:
    k8s.v1.cni.cncf.io/networks: |-
      [
        {"name": "allvalidflags"},

1


        {"name": "allvalidflags"},
        {
          "name": "bond-sysctl-network",
          "interface": "bond0",
          "mac": "0a:56:0a:83:04:0c",

2


          "ips": ["10.100.100.200/24"]

3


       }
      ]
spec:
  containers:
  - name: podexample
    image: centos
    command: ["/bin/bash", "-c", "sleep INF"]
    securityContext:
      runAsUser: 2000
      runAsGroup: 3000
      allowPrivilegeEscalation: false
      capabilities:
        drop: ["ALL"]
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault

Copy to Clipboard

Toggle word wrap

1: SR-IOV 네트워크 연결 정의 CR의 이름입니다.
2: 선택사항: SR-IOV 네트워크 연결 정의 CR에 정의된 리소스 유형에서 할당된 SR-IOV 장치의 MAC 주소입니다. 이 기능을 사용하려면 SriovNetwork 오브젝트에 { "mac": true } 도 지정해야 합니다.
3: 선택사항: SR-IOV 네트워크 연결 정의 CR에 정의된 리소스 유형에서 할당된 SR-IOV 장치의 IP 주소입니다. IPv4 및 IPv6 주소가 모두 지원됩니다. 이 기능을 사용하려면 SriovNetwork 오브젝트에 { "ips": true }도 지정해야 합니다.

YAML을 적용합니다.
```
oc apply -f examplepod.yaml
```
```
$ oc apply -f examplepod.yaml
```
Copy to Clipboard Toggle word wrap

다음 명령을 실행하여 Pod가 생성되었는지 확인합니다.

oc get pod -n sysctl-tuning-test

$ oc get pod -n sysctl-tuning-test

Copy to Clipboard

Toggle word wrap

출력 예

NAME      READY   STATUS    RESTARTS   AGE
tunepod   1/1     Running   0          47s

NAME      READY   STATUS    RESTARTS   AGE
tunepod   1/1     Running   0          47s

Copy to Clipboard

Toggle word wrap

다음 명령을 실행하여 Pod에 로그인합니다.
```
oc rsh -n sysctl-tuning-test tunepod
```
```
$ oc rsh -n sysctl-tuning-test tunepod
```
Copy to Clipboard Toggle word wrap
구성된 sysctl 플래그 값을 확인합니다. 다음 명령을 실행하여 net.ipv6.neigh.IFNAME.base_reachable_time_ms 값을 찾습니다.
```
sysctl net.ipv6.neigh.bond0.base_reachable_time_ms
```
```
$ sysctl net.ipv6.neigh.bond0.base_reachable_time_ms
```
Copy to Clipboard Toggle word wrap
출력 예
```
net.ipv6.neigh.bond0.base_reachable_time_ms = 20000
```
```
net.ipv6.neigh.bond0.base_reachable_time_ms = 20000
```
Copy to Clipboard Toggle word wrap

20.9. 고성능 멀티 캐스트 사용
링크 복사

SR-IOV(Single Root I/O Virtualization) 하드웨어 네트워크에서 멀티 캐스트를 사용할 수 있습니다.

20.9.1. 고성능 멀티 캐스트
링크 복사

OpenShift SDN 기본 CNI(Container Network Interfac) 네트워크 공급자는 기본 네트워크에서 Pod 간 멀티 캐스트를 지원합니다. 이는 고 대역폭 애플리케이션이 아닌 저 대역폭 조정 또는 서비스 검색에 가장 적합합니다. IPTV(Internet Protocol Television) 및 멀티 포인트 화상 회의와 같은 스트리밍 미디어와 같은 애플리케이션의 경우 SR-IOV(Single Root I/O Virtualization) 하드웨어를 사용하여 거의 네이티브와 같은 성능을 제공할 수 있습니다.

멀티 캐스트에 추가 SR-IOV 인터페이스를 사용하는 경우:

멀티 캐스트 패키지는 추가 SR-IOV 인터페이스를 통해 pod에서 보내거나 받아야 합니다.
SR-IOV 인터페이스를 연결하는 물리적 네트워크는 멀티 캐스트 라우팅 및 토폴로지를 결정하며 OpenShift Container Platform에서 제어하지 않습니다.

20.9.2. 멀티 캐스트를 위한 SR-IOV 인터페이스 구성
링크 복사

다음 프로시저는 멀티 캐스트용 SR-IOV 인터페이스 예제를 만듭니다.

사전 요구 사항

OpenShift CLI(oc)를 설치합니다.
cluster-admin 역할을 가진 사용자로 클러스터에 로그인해야 합니다.

프로세스

SriovNetworkNodePolicy 오브젝트를 생성합니다.

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: policy-example
  namespace: openshift-sriov-network-operator
spec:
  resourceName: example
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  numVfs: 4
  nicSelector:
    vendor: "8086"
    pfNames: ['ens803f0']
    rootDevices: ['0000:86:00.0']

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: policy-example
  namespace: openshift-sriov-network-operator
spec:
  resourceName: example
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  numVfs: 4
  nicSelector:
    vendor: "8086"
    pfNames: ['ens803f0']
    rootDevices: ['0000:86:00.0']

Copy to Clipboard

Toggle word wrap

SriovNetwork 오브젝트를 생성합니다.

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: net-example
  namespace: openshift-sriov-network-operator
spec:
  networkNamespace: default
  ipam: | 
    {
      "type": "host-local", 
      "subnet": "10.56.217.0/24",
      "rangeStart": "10.56.217.171",
      "rangeEnd": "10.56.217.181",
      "routes": [
        {"dst": "224.0.0.0/5"},
        {"dst": "232.0.0.0/5"}
      ],
      "gateway": "10.56.217.1"
    }
  resourceName: example

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: net-example
  namespace: openshift-sriov-network-operator
spec:
  networkNamespace: default
  ipam: |

1


    {
      "type": "host-local",

2


      "subnet": "10.56.217.0/24",
      "rangeStart": "10.56.217.171",
      "rangeEnd": "10.56.217.181",
      "routes": [
        {"dst": "224.0.0.0/5"},
        {"dst": "232.0.0.0/5"}
      ],
      "gateway": "10.56.217.1"
    }
  resourceName: example

Copy to Clipboard

Toggle word wrap

1 2: DHCP를 IPAM으로 구성하도록 선택한 경우 DHCP 서버를 통해 224.0.0.0/5 및 232.0.0.0/5 기본 경로를 프로비저닝해야 합니다. 이는 기본 네트워크 공급자가 설정한 정적 멀티 캐스트 경로를 재정의하는 것입니다.

멀티 캐스트 애플리케이션으로 pod를 생성합니다.

apiVersion: v1
kind: Pod
metadata:
  name: testpmd
  namespace: default
  annotations:
    k8s.v1.cni.cncf.io/networks: nic1
spec:
  containers:
  - name: example
    image: rhel7:latest
    securityContext:
      capabilities:
        add: ["NET_ADMIN"] 
    command: [ "sleep", "infinity"]

apiVersion: v1
kind: Pod
metadata:
  name: testpmd
  namespace: default
  annotations:
    k8s.v1.cni.cncf.io/networks: nic1
spec:
  containers:
  - name: example
    image: rhel7:latest
    securityContext:
      capabilities:
        add: ["NET_ADMIN"]

1


    command: [ "sleep", "infinity"]

Copy to Clipboard

Toggle word wrap

1: NET_ADMIN 기능은 애플리케이션이 멀티 캐스트 IP 주소를 SR-IOV 인터페이스에 할당해야 하는 경우에만 필요합니다. 그 밖의 경우에는 생략할 수 있습니다.

20.10. DPDK 및 RDMA 사용
링크 복사

컨테이너화된 DPDK(Data Plane Development Kit) 애플리케이션은 OpenShift Container Platform에서 지원됩니다. DPDK(Data Plane Development Kit) 및 RDMA(Remote Direct Memory Access)와 함께 SR-IOV(Single Root I/O Virtualization) 네트워크 하드웨어를 사용할 수 있습니다.

지원되는 장치에 대한 자세한 내용은 지원되는 장치를 참조하십시오.

20.10.1. Intel NIC와 함께 DPDK 모드에서 가상 기능 사용
링크 복사

사전 요구 사항

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

프로세스

다음 SriovNetworkNodePolicy 오브젝트를 생성한 다음 YAML을 intel-dpdk-node-policy.yaml 파일에 저장합니다.

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: intel-dpdk-node-policy
  namespace: openshift-sriov-network-operator
spec:
  resourceName: intelnics
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  priority: <priority>
  numVfs: <num>
  nicSelector:
    vendor: "8086"
    deviceID: "158b"
    pfNames: ["<pf_name>", ...]
    rootDevices: ["<pci_bus_id>", "..."]
  deviceType: vfio-pci

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: intel-dpdk-node-policy
  namespace: openshift-sriov-network-operator
spec:
  resourceName: intelnics
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  priority: <priority>
  numVfs: <num>
  nicSelector:
    vendor: "8086"
    deviceID: "158b"
    pfNames: ["<pf_name>", ...]
    rootDevices: ["<pci_bus_id>", "..."]
  deviceType: vfio-pci

1

Copy to Clipboard

Toggle word wrap

1: 가상 기능의 드라이버 유형을 vfio-pci로 지정합니다.

참고

SriovNetworkNodePolicy의 각 옵션에 대한 자세한 설명은 Configuring SR-IOV network devices 섹션을 참조하십시오.

SriovNetworkNodePolicy 오브젝트에 지정된 구성을 적용하면 SR-IOV Operator가 노드를 비우고 경우에 따라 노드를 재부팅할 수 있습니다. 구성 변경 사항을 적용하는 데 몇 분이 걸릴 수 있습니다. 제거된 워크로드를 사전에 처리하는 데 클러스터에 사용 가능한 노드가 충분한지 확인하십시오.

구성 업데이트가 적용되면 openshift-sriov-network-operator 네임스페이스의 모든 Pod 상태가 Running으로 변경됩니다.

다음 명령을 실행하여 SriovNetworkNodePolicy 오브젝트를 생성합니다.
```
oc create -f intel-dpdk-node-policy.yaml
```
```
$ oc create -f intel-dpdk-node-policy.yaml
```
Copy to Clipboard Toggle word wrap
다음 SriovNetwork 오브젝트를 생성한 다음 YAML을 intel-dpdk-network.yaml 파일에 저장합니다.
```
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: intel-dpdk-network
  namespace: openshift-sriov-network-operator
spec:
  networkNamespace: <target_namespace>
  ipam: |-
# ... 
  vlan: <vlan>
  resourceName: intelnics
```
```
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: intel-dpdk-network
  namespace: openshift-sriov-network-operator
spec:
  networkNamespace: <target_namespace>
  ipam: |-
# ... 
```
1
```
  vlan: <vlan>
  resourceName: intelnics
```
Copy to Clipboard Toggle word wrap
1
ipam CNI 플러그인의 구성 오브젝트를 YAML 블록 스칼라로 지정합니다. 플러그인은 연결 정의에 대한 IP 주소 할당을 관리합니다.
참고
SriovNetwork의 각 옵션에 대한 자세한 설명은 " SR-IOV 추가 네트워크 구성" 섹션을 참조하십시오.
선택적 라이브러리인 app-netutil은 컨테이너의 상위 pod에 대한 네트워크 정보를 수집하기 위한 여러 API 메서드를 제공합니다.
다음 명령을 실행하여 SriovNetwork 오브젝트를 생성합니다.
```
oc create -f intel-dpdk-network.yaml
```
```
$ oc create -f intel-dpdk-network.yaml
```
Copy to Clipboard Toggle word wrap
다음 Pod 사양을 생성한 다음 YAML을 intel-dpdk-pod.yaml 파일에 저장합니다.
```
apiVersion: v1
kind: Pod
metadata:
  name: dpdk-app
  namespace: <target_namespace> 
  annotations:
    k8s.v1.cni.cncf.io/networks: intel-dpdk-network
spec:
  containers:
  - name: testpmd
    image: <DPDK_image> 
    securityContext:
      runAsUser: 0
      capabilities:
        add: ["IPC_LOCK","SYS_RESOURCE","NET_RAW"] 
    volumeMounts:
    - mountPath: /dev/hugepages 
      name: hugepage
    resources:
      limits:
        openshift.io/intelnics: "1" 
        memory: "1Gi"
        cpu: "4" 
        hugepages-1Gi: "4Gi" 
      requests:
        openshift.io/intelnics: "1"
        memory: "1Gi"
        cpu: "4"
        hugepages-1Gi: "4Gi"
    command: ["sleep", "infinity"]
  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages
```
```
apiVersion: v1
kind: Pod
metadata:
  name: dpdk-app
  namespace: <target_namespace> 
```
1
```
  annotations:
    k8s.v1.cni.cncf.io/networks: intel-dpdk-network
spec:
  containers:
  - name: testpmd
    image: <DPDK_image> 
```
2
```
    securityContext:
      runAsUser: 0
      capabilities:
        add: ["IPC_LOCK","SYS_RESOURCE","NET_RAW"] 
```
3
```
    volumeMounts:
    - mountPath: /dev/hugepages 
```
4
```
      name: hugepage
    resources:
      limits:
        openshift.io/intelnics: "1" 
```
5
```
        memory: "1Gi"
        cpu: "4" 
```
6
```
        hugepages-1Gi: "4Gi" 
```
7
```
      requests:
        openshift.io/intelnics: "1"
        memory: "1Gi"
        cpu: "4"
        hugepages-1Gi: "4Gi"
    command: ["sleep", "infinity"]
  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages
```
Copy to Clipboard Toggle word wrap
1
SriovNetwork 오브젝트 intel-dpdk-network가 생성되는 동일한 target_namespace를 지정합니다. 다른 네임스페이스에서 포드를 생성하려면 Pod 사양과 SriovNetowrk 오브젝트 모두에서 target_namespace를 변경합니다.
2
애플리케이션 및 애플리케이션이 사용하는 DPDK 라이브러리를 포함하는 DPDK 이미지를 지정합니다.
3
hugepage 할당, 시스템 리소스 할당 및 네트워크 인터페이스 액세스를 위해 컨테이너 내부의 애플리케이션에 필요한 추가 기능을 지정합니다.
4
/dev/hugepages 아래 DPDK pod에 hugepage 볼륨을 마운트합니다. hugepage 볼륨은 매체가 Hugepages인 emptyDir 볼륨 유형으로 지원됩니다.
5
선택사항: DPDK Pod에 할당된 DPDK 장치 수를 지정합니다. 명시적으로 지정되지 않은 경우 이 리소스 요청 및 제한은 SR-IOV 네트워크 리소스 인젝터에 의해 자동으로 추가됩니다. SR-IOV 네트워크 리소스 인젝터는 SR-IOV Operator에서 관리하는 승인 컨트롤러 구성 요소입니다. 기본적으로 활성화되어 있으며 기본 SriovOperatorConfig CR에서 enableInjector 옵션을 false로 설정하여 비활성화할 수 있습니다.
6
CPU 수를 지정합니다. DPDK pod는 일반적으로 kubelet에서 배타적 CPU를 할당해야 합니다. 이를 위해 CPU 관리자 정책을 static으로 설정하고 QoS가 Guaranteed Pod를 생성합니다.
7
hugepage 크기 hugepages-1Gi 또는 hugepages-2Mi를 지정하고 DPDK Pod에 할당할 hugepage 수량을 지정합니다. 2Mi 및 1Gi hugepage를 별도로 구성합니다. 1Gi hugepage를 구성하려면 커널 인수를 노드에 추가해야 합니다. 예를 들어, 커널 인수 default_hugepagesz = 1GB, hugepagesz = 1G 및 hugepages = 16을 추가하면 시스템 부팅 시 16 * 1Gi hugepage가 할당됩니다.
다음 명령을 실행하여 DPDK Pod를 생성합니다.
```
oc create -f intel-dpdk-pod.yaml
```
```
$ oc create -f intel-dpdk-pod.yaml
```
Copy to Clipboard Toggle word wrap

20.10.2. Mellanox NIC와 함께 DPDK 모드에서 가상 기능 사용
링크 복사

Mellanox NIC와 함께 DPDK 모드의 가상 기능을 사용하여 네트워크 노드 정책을 생성하고 DPDK(Data Plane Development Kit) Pod를 생성할 수 있습니다.

사전 요구 사항

OpenShift CLI(oc)가 설치되어 있습니다.
SR-IOV(Single Root I/O Virtualization) Network Operator를 설치했습니다.
cluster-admin 권한이 있는 사용자로 로그인했습니다.

프로세스

다음 SriovNetworkNodePolicy YAML 구성을 mlx-dpdk-node-policy.yaml 파일에 저장합니다.
```
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: mlx-dpdk-node-policy
  namespace: openshift-sriov-network-operator
spec:
  resourceName: mlxnics
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  priority: <priority>
  numVfs: <num>
  nicSelector:
    vendor: "15b3"
    deviceID: "1015" 
    pfNames: ["<pf_name>", ...]
    rootDevices: ["<pci_bus_id>", "..."]
  deviceType: netdevice 
  isRdma: true 
```
```
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: mlx-dpdk-node-policy
  namespace: openshift-sriov-network-operator
spec:
  resourceName: mlxnics
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  priority: <priority>
  numVfs: <num>
  nicSelector:
    vendor: "15b3"
    deviceID: "1015" 
```
1
```
    pfNames: ["<pf_name>", ...]
    rootDevices: ["<pci_bus_id>", "..."]
  deviceType: netdevice 
```
2
```
  isRdma: true 
```
3
Copy to Clipboard Toggle word wrap
1
SR-IOV 네트워크 장치의 장치 16진수 코드를 지정합니다.
2
netdevice에 가상 기능의 드라이버 유형을 지정합니다. Mellanox SR-IOV VF(가상 기능)는 vfio-pci 장치 유형을 사용하지 않고도 DPDK 모드에서 작동할 수 있습니다. VF 장치는 컨테이너 내부에 커널 네트워크 인터페이스로 나타납니다.
3
RDMA(Remote Direct Memory Access) 모드를 활성화합니다. Mellanox 카드가 DPDK 모드에서 작동하려면 이 카드가 필요합니다.
참고
SriovNetworkNodePolicy 오브젝트의 각 옵션에 대한 자세한 설명은 SR-IOV 네트워크 장치 구성을 참조하십시오.
SriovNetworkNodePolicy 오브젝트에 지정된 구성을 적용하면 SR-IOV Operator가 노드를 비우고 경우에 따라 노드를 재부팅할 수 있습니다. 구성 변경 사항을 적용하는 데 몇 분이 걸릴 수 있습니다. 제거된 워크로드를 사전에 처리하는 데 클러스터에 사용 가능한 노드가 충분한지 확인하십시오.
구성 업데이트가 적용되면 openshift-sriov-network-operator 네임스페이스의 모든 Pod 상태가 Running으로 변경됩니다.
다음 명령을 실행하여 SriovNetworkNodePolicy 오브젝트를 생성합니다.
```
oc create -f mlx-dpdk-node-policy.yaml
```
```
$ oc create -f mlx-dpdk-node-policy.yaml
```
Copy to Clipboard Toggle word wrap
다음 SriovNetwork YAML 구성을 mlx-dpdk-network.yaml 파일에 저장합니다.
```
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: mlx-dpdk-network
  namespace: openshift-sriov-network-operator
spec:
  networkNamespace: <target_namespace>
  ipam: |- 
...
  vlan: <vlan>
  resourceName: mlxnics
```
```
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: mlx-dpdk-network
  namespace: openshift-sriov-network-operator
spec:
  networkNamespace: <target_namespace>
  ipam: |- 
```
1
```
...
  vlan: <vlan>
  resourceName: mlxnics
```
Copy to Clipboard Toggle word wrap
1
IP 주소 관리(IPAM) CNI(Container Network Interface) 플러그인의 구성 오브젝트를 YAML 블록 스칼라로 지정합니다. 플러그인은 연결 정의에 대한 IP 주소 할당을 관리합니다.
참고
SriovNetwork 오브젝트 의 각 옵션에 대한 자세한 설명은 SR-IOV 네트워크 장치 구성을 참조하십시오.
app-netutil 옵션 라이브러리는 컨테이너의 상위 포드에 대한 네트워크 정보를 수집하기 위한 여러 API 메서드를 제공합니다.
다음 명령을 실행하여 SriovNetwork 오브젝트를 생성합니다.
```
oc create -f mlx-dpdk-network.yaml
```
```
$ oc create -f mlx-dpdk-network.yaml
```
Copy to Clipboard Toggle word wrap
다음 Pod YAML 구성을 mlx-dpdk-pod.yaml 파일에 저장합니다.
```
apiVersion: v1
kind: Pod
metadata:
  name: dpdk-app
  namespace: <target_namespace> 
  annotations:
    k8s.v1.cni.cncf.io/networks: mlx-dpdk-network
spec:
  containers:
  - name: testpmd
    image: <DPDK_image> 
    securityContext:
      runAsUser: 0
      capabilities:
        add: ["IPC_LOCK","SYS_RESOURCE","NET_RAW"] 
    volumeMounts:
    - mountPath: /dev/hugepages 
      name: hugepage
    resources:
      limits:
        openshift.io/mlxnics: "1" 
        memory: "1Gi"
        cpu: "4" 
        hugepages-1Gi: "4Gi" 
      requests:
        openshift.io/mlxnics: "1"
        memory: "1Gi"
        cpu: "4"
        hugepages-1Gi: "4Gi"
    command: ["sleep", "infinity"]
  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages
```
```
apiVersion: v1
kind: Pod
metadata:
  name: dpdk-app
  namespace: <target_namespace> 
```
1
```
  annotations:
    k8s.v1.cni.cncf.io/networks: mlx-dpdk-network
spec:
  containers:
  - name: testpmd
    image: <DPDK_image> 
```
2
```
    securityContext:
      runAsUser: 0
      capabilities:
        add: ["IPC_LOCK","SYS_RESOURCE","NET_RAW"] 
```
3
```
    volumeMounts:
    - mountPath: /dev/hugepages 
```
4
```
      name: hugepage
    resources:
      limits:
        openshift.io/mlxnics: "1" 
```
5
```
        memory: "1Gi"
        cpu: "4" 
```
6
```
        hugepages-1Gi: "4Gi" 
```
7
```
      requests:
        openshift.io/mlxnics: "1"
        memory: "1Gi"
        cpu: "4"
        hugepages-1Gi: "4Gi"
    command: ["sleep", "infinity"]
  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages
```
Copy to Clipboard Toggle word wrap
1
SriovNetwork 오브젝트 mlx-dpdk-network가 생성되는 동일한 target_namespace를 지정합니다. 다른 네임스페이스에서 Pod를 생성하려면 Pod 사양 및 SriovNetwork 오브젝트 모두에서 target_namespace 를 변경합니다.
2
애플리케이션 및 애플리케이션에서 사용하는 DPDK 라이브러리를 포함하는 DPDK 이미지를 지정합니다.
3
hugepage 할당, 시스템 리소스 할당 및 네트워크 인터페이스 액세스를 위해 컨테이너 내부의 애플리케이션에 필요한 추가 기능을 지정합니다.
4
hugepage 볼륨을 /dev/hugepages 아래의 DPDK Pod에 마운트합니다. hugepage 볼륨은 매체가 Hugepages 인 emptyDir 볼륨 유형으로 지원됩니다.
5
선택 사항: DPDK Pod에 할당된 DPDK 장치 수를 지정합니다. 명시적으로 지정하지 않으면 SR-IOV 네트워크 리소스 인젝터에 의해 이 리소스 요청 및 제한이 자동으로 추가됩니다. SR-IOV 네트워크 리소스 인젝터는 SR-IOV Operator에서 관리하는 승인 컨트롤러 구성 요소입니다. 기본적으로 활성화되어 있으며 기본 SriovOperatorConfig CR에서 enableInjector 옵션을 false로 설정하여 비활성화할 수 있습니다.
6
CPU 수를 지정합니다. DPDK Pod는 일반적으로 kubelet에서 전용 CPU를 할당해야 합니다. 이렇게 하려면 CPU 관리자 정책을 static 으로 설정하고 QoS(Quality of Service)가 보장된 Pod를 생성합니다.
7
hugepage 크기 hugepages-1Gi 또는 hugepages-2Mi를 지정하고 DPDK Pod에 할당할 hugepage 수량을 지정합니다. 2Mi 및 1Gi hugepage를 별도로 구성합니다. 1Gi hugepages를 구성하려면 커널 인수를 노드에 추가해야 합니다.
다음 명령을 실행하여 DPDK Pod를 생성합니다.
```
oc create -f mlx-dpdk-pod.yaml
```
```
$ oc create -f mlx-dpdk-pod.yaml
```
Copy to Clipboard Toggle word wrap

20.10.3. 특정 DPDK 라인 비율 달성 개요
링크 복사

특정 DPDK(Data Plane Development Kit) 라인 속도를 달성하려면 Node Tuning Operator를 배포하고 SR-IOV(Single Root I/O Virtualization)를 구성합니다. 다음 리소스의 DPDK 설정도 조정해야 합니다.

분리된 CPU
hugepages
토폴로지 스케줄러

참고

이전 버전의 OpenShift Container Platform에서는 OpenShift Container Platform 애플리케이션에 대해 짧은 대기 시간 성능을 실현하기 위해 자동 튜닝을 구현하는 데 Performance Addon Operator를 사용했습니다. OpenShift Container Platform 4.11 이상에서는 이 기능이 Node Tuning Operator의 일부입니다.

DPDK 테스트 환경

다음 다이어그램은 트래픽 테스트 환경의 구성 요소를 보여줍니다.

트래픽 생성기: 대량의 패킷 트래픽을 생성할 수 있는 애플리케이션입니다.
SR-IOV 지원 NIC: SR-IOV와 호환되는 네트워크 인터페이스 카드입니다. 이 카드는 물리적 인터페이스에서 여러 가상 기능을 실행합니다.
PF(물리적 기능 ): SR-IOV 인터페이스를 지원하는 네트워크 어댑터의 PCI Express(PCI Express) 기능입니다.
VF(가상 기능): SR-IOV를 지원하는 네트워크 어댑터의 경량 DASD 기능입니다. VF는 네트워크 어댑터의 controlPlane PF와 연결되어 있습니다. VF는 네트워크 어댑터의 가상화된 인스턴스를 나타냅니다.
Switch: 네트워크 스위치입니다. 또한 노드는 back-to-back으로 연결할 수 있습니다.
testpmd: DPDK에 포함된 예제 애플리케이션입니다. testpmd 애플리케이션을 사용하여 packet-forwarding 모드에서 DPDK를 테스트할 수 있습니다. testpmd 애플리케이션은 DPDK 소프트웨어 개발 키트(SDK)를 사용하여 완전한 애플리케이션을 빌드하는 방법의 예입니다.
worker 0 및 worker 1: OpenShift Container Platform 노드

20.10.4. SR-IOV 및 Node Tuning Operator를 사용하여 DPDK 라인 속도 달성
링크 복사

Node Tuning Operator를 사용하여 분리된 CPU, hugepages 및 토폴로지 스케줄러를 구성할 수 있습니다. 그런 다음 Node Tuning Operator를 SR-IOV(Single Root I/O Virtualization)와 함께 사용하여 특정 DPDK(Data Plane Development Kit) 라인 속도를 달성할 수 있습니다.

사전 요구 사항

OpenShift CLI(oc)가 설치되어 있습니다.
SR-IOV Network Operator가 설치되어 있습니다.
cluster-admin 권한이 있는 사용자로 로그인했습니다.
독립 실행형 Node Tuning Operator를 배포했습니다.
참고
이전 버전의 OpenShift Container Platform에서는 OpenShift 애플리케이션에 대해 짧은 대기 시간 성능을 실현하기 위해 자동 튜닝을 구현하는 데 Performance Addon Operator를 사용했습니다. OpenShift Container Platform 4.11 이상에서는 이 기능이 Node Tuning Operator의 일부입니다.

프로세스

다음 예제를 기반으로 PerformanceProfile 오브젝트를 생성합니다.
```
apiVersion: performance.openshift.io/v2
kind: PerformanceProfile
metadata:
  name: performance
spec:
  globallyDisableIrqLoadBalancing: true
  cpu:
    isolated: 21-51,73-103 
    reserved: 0-20,52-72 
  hugepages:
    defaultHugepagesSize: 1G 
    pages:
      - count: 32
        size: 1G
  net:
    userLevelNetworking: true
  numa:
    topologyPolicy: "single-numa-node"
  nodeSelector:
    node-role.kubernetes.io/worker-cnf: ""
```
```
apiVersion: performance.openshift.io/v2
kind: PerformanceProfile
metadata:
  name: performance
spec:
  globallyDisableIrqLoadBalancing: true
  cpu:
    isolated: 21-51,73-103 
```
1
```
    reserved: 0-20,52-72 
```
2
```
  hugepages:
    defaultHugepagesSize: 1G 
```
3
```
    pages:
      - count: 32
        size: 1G
  net:
    userLevelNetworking: true
  numa:
    topologyPolicy: "single-numa-node"
  nodeSelector:
    node-role.kubernetes.io/worker-cnf: ""
```
Copy to Clipboard Toggle word wrap
1
시스템에서 하이퍼 스레딩이 활성화되면 관련 심볼릭 링크를 분리 및 예약된 CPU 그룹에 할당합니다. 시스템에 NUMA(Non-uniform 메모리 액세스 노드)가 여러 개 포함된 경우 두 NUMA에서 두 그룹으로 CPU를 할당합니다. 이 작업에 Performance Profile Creator를 사용할 수도 있습니다. 자세한 내용은 성능 프로필 생성을 참조하십시오.
2
대기열이 예약된 CPU 수로 설정될 장치 목록을 지정할 수도 있습니다. 자세한 내용은 Node Tuning Operator를 사용하여 NIC 대기열 단축을 참조하십시오.
3
필요한 hugepages의 수와 크기를 할당합니다. hugepages에 대한 NUMA 구성을 지정할 수 있습니다. 기본적으로 시스템은 시스템의 모든 NUMA 노드에 짝수를 할당합니다. 필요한 경우 노드에 실시간 커널 사용을 요청할 수 있습니다. 자세한 내용은 실시간 기능이 있는 작업자 프로비저닝 을 참조하십시오.
yaml 파일을 mlx-dpdk-perfprofile-policy.yaml 로 저장합니다.
다음 명령을 사용하여 성능 프로필을 적용합니다.
```
oc create -f mlx-dpdk-perfprofile-policy.yaml
```
```
$ oc create -f mlx-dpdk-perfprofile-policy.yaml
```
Copy to Clipboard Toggle word wrap

20.10.4.1. 가상 기능을 위한 SR-IOV Network Operator의 예
링크 복사

SR-IOV(Single Root I/O Virtualization) Network Operator를 사용하여 노드의 SR-IOV 지원 물리적 기능 NIC에서 VF(가상 기능)를 할당하고 구성할 수 있습니다.

Operator 배포에 대한 자세한 내용은 SR-IOV Network Operator 설치를 참조하십시오. SR-IOV 네트워크 장치 구성에 대한 자세한 내용은 SR-IOV 네트워크 장치 구성을 참조하십시오.

Intel VF와 Mellanox VF에서 DPDK(Data Plane Development Kit) 워크로드 실행 사이에 몇 가지 차이점이 있습니다. 이 섹션에서는 두 VF 유형의 오브젝트 구성 예제를 제공합니다. 다음은 Intel NIC에서 DPDK 애플리케이션을 실행하는 데 사용되는 sriovNetworkNodePolicy 오브젝트의 예입니다.

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: dpdk-nic-1
  namespace: openshift-sriov-network-operator
spec:
  deviceType: vfio-pci 
  needVhostNet: true 
  nicSelector:
    pfNames: ["ens3f0"]
  nodeSelector:
    node-role.kubernetes.io/worker-cnf: ""
  numVfs: 10
  priority: 99
  resourceName: dpdk_nic_1
---
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: dpdk-nic-1
  namespace: openshift-sriov-network-operator
spec:
  deviceType: vfio-pci
  needVhostNet: true
  nicSelector:
    pfNames: ["ens3f1"]
  nodeSelector:
  node-role.kubernetes.io/worker-cnf: ""
  numVfs: 10
  priority: 99
  resourceName: dpdk_nic_2

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: dpdk-nic-1
  namespace: openshift-sriov-network-operator
spec:
  deviceType: vfio-pci

1


  needVhostNet: true

2


  nicSelector:
    pfNames: ["ens3f0"]
  nodeSelector:
    node-role.kubernetes.io/worker-cnf: ""
  numVfs: 10
  priority: 99
  resourceName: dpdk_nic_1
---
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: dpdk-nic-1
  namespace: openshift-sriov-network-operator
spec:
  deviceType: vfio-pci
  needVhostNet: true
  nicSelector:
    pfNames: ["ens3f1"]
  nodeSelector:
  node-role.kubernetes.io/worker-cnf: ""
  numVfs: 10
  priority: 99
  resourceName: dpdk_nic_2

Copy to Clipboard

Toggle word wrap

1: Intel NIC의 경우 deviceType 은 vfio-pci 여야 합니다.
2: DPDK 워크로드와의 커널 통신이 필요한 경우 needVhostNet: true 를 추가합니다. 그러면 애플리케이션이 탭 장치를 생성하고 탭 장치를 DPDK 워크로드에 연결할 수 있도록 /dev/net/tun 및 /dev/vhost-net 장치가 컨테이너에 마운트됩니다.

다음은 Mellanox NIC의 sriovNetworkNodePolicy 오브젝트의 예입니다.

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: dpdk-nic-1
  namespace: openshift-sriov-network-operator
spec:
  deviceType: netdevice 
  isRdma: true 
  nicSelector:
    rootDevices:
      - "0000:5e:00.1"
  nodeSelector:
    node-role.kubernetes.io/worker-cnf: ""
  numVfs: 5
  priority: 99
  resourceName: dpdk_nic_1
---
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: dpdk-nic-2
  namespace: openshift-sriov-network-operator
spec:
  deviceType: netdevice
  isRdma: true
  nicSelector:
    rootDevices:
      - "0000:5e:00.0"
  nodeSelector:
    node-role.kubernetes.io/worker-cnf: ""
  numVfs: 5
  priority: 99
  resourceName: dpdk_nic_2

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: dpdk-nic-1
  namespace: openshift-sriov-network-operator
spec:
  deviceType: netdevice

1


  isRdma: true

2


  nicSelector:
    rootDevices:
      - "0000:5e:00.1"
  nodeSelector:
    node-role.kubernetes.io/worker-cnf: ""
  numVfs: 5
  priority: 99
  resourceName: dpdk_nic_1
---
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: dpdk-nic-2
  namespace: openshift-sriov-network-operator
spec:
  deviceType: netdevice
  isRdma: true
  nicSelector:
    rootDevices:
      - "0000:5e:00.0"
  nodeSelector:
    node-role.kubernetes.io/worker-cnf: ""
  numVfs: 5
  priority: 99
  resourceName: dpdk_nic_2

Copy to Clipboard

Toggle word wrap

1: Mellanox 장치의 경우 deviceType 은 netdevice 여야 합니다.
2: Mellanox 장치의 경우 isRdma 가 true 여야 합니다. Mellanox 카드는 Flow Bifurcation을 사용하여 DPDK 애플리케이션에 연결됩니다. 이 메커니즘은 Linux 사용자 공간과 커널 공간 간에 트래픽을 분할하고 라인 속도 처리 기능을 향상시킬 수 있습니다.

20.10.4.2. SR-IOV 네트워크 Operator의 예
링크 복사

다음은 sriovNetwork 오브젝트 정의의 예입니다. 이 경우 Intel 및 Mellanox 구성은 동일합니다.

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: dpdk-network-1
  namespace: openshift-sriov-network-operator
spec:
  ipam: '{"type": "host-local","ranges": [[{"subnet": "10.0.1.0/24"}]],"dataDir":
   "/run/my-orchestrator/container-ipam-state-1"}' 
  networkNamespace: dpdk-test 
  spoofChk: "off"
  trust: "on"
  resourceName: dpdk_nic_1 
---
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: dpdk-network-2
  namespace: openshift-sriov-network-operator
spec:
  ipam: '{"type": "host-local","ranges": [[{"subnet": "10.0.2.0/24"}]],"dataDir":
   "/run/my-orchestrator/container-ipam-state-1"}'
  networkNamespace: dpdk-test
  spoofChk: "off"
  trust: "on"
  resourceName: dpdk_nic_2

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: dpdk-network-1
  namespace: openshift-sriov-network-operator
spec:
  ipam: '{"type": "host-local","ranges": [[{"subnet": "10.0.1.0/24"}]],"dataDir":
   "/run/my-orchestrator/container-ipam-state-1"}'

1


  networkNamespace: dpdk-test

2


  spoofChk: "off"
  trust: "on"
  resourceName: dpdk_nic_1

3


---
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: dpdk-network-2
  namespace: openshift-sriov-network-operator
spec:
  ipam: '{"type": "host-local","ranges": [[{"subnet": "10.0.2.0/24"}]],"dataDir":
   "/run/my-orchestrator/container-ipam-state-1"}'
  networkNamespace: dpdk-test
  spoofChk: "off"
  trust: "on"
  resourceName: dpdk_nic_2

Copy to Clipboard

Toggle word wrap

1: Whereabouts와 같은 다른 IP 주소 관리 (IPAM) 구현을 사용할 수 있습니다. 자세한 내용은 Whereabouts를 사용한 동적 IP 주소 할당 구성을 참조하십시오.
2: 네트워크 연결 정의가 생성될 networkNamespace 를 요청해야 합니다. openshift-sriov-network-operator 네임스페이스에서 sriovNetwork CR을 생성해야 합니다.
3: resourceName 값은 sriovNetworkNodePolicy 에서 생성된 resourceName 의 값과 일치해야 합니다.

20.10.4.3. DPDK 기본 워크로드의 예
링크 복사

다음은 DPDK(Data Plane Development Kit) 컨테이너의 예입니다.

apiVersion: v1
kind: Namespace
metadata:
  name: dpdk-test
---
apiVersion: v1
kind: Pod
metadata:
  annotations:
    k8s.v1.cni.cncf.io/networks: '[ 
     {
      "name": "dpdk-network-1",
      "namespace": "dpdk-test"
     },
     {
      "name": "dpdk-network-2",
      "namespace": "dpdk-test"
     }
   ]'
    irq-load-balancing.crio.io: "disable" 
    cpu-load-balancing.crio.io: "disable"
    cpu-quota.crio.io: "disable"
  labels:
    app: dpdk
  name: testpmd
  namespace: dpdk-test
spec:
  runtimeClassName: performance-performance 
  containers:
    - command:
        - /bin/bash
        - -c
        - sleep INF
      image: registry.redhat.io/openshift4/dpdk-base-rhel8
      imagePullPolicy: Always
      name: dpdk
      resources: 
        limits:
          cpu: "16"
          hugepages-1Gi: 8Gi
          memory: 2Gi
        requests:
          cpu: "16"
          hugepages-1Gi: 8Gi
          memory: 2Gi
      securityContext:
        capabilities:
          add:
            - IPC_LOCK
            - SYS_RESOURCE
            - NET_RAW
            - NET_ADMIN
        runAsUser: 0
      volumeMounts:
        - mountPath: /mnt/huge
          name: hugepages
  terminationGracePeriodSeconds: 5
  volumes:
    - emptyDir:
        medium: HugePages
      name: hugepages

apiVersion: v1
kind: Namespace
metadata:
  name: dpdk-test
---
apiVersion: v1
kind: Pod
metadata:
  annotations:
    k8s.v1.cni.cncf.io/networks: '[

1


     {
      "name": "dpdk-network-1",
      "namespace": "dpdk-test"
     },
     {
      "name": "dpdk-network-2",
      "namespace": "dpdk-test"
     }
   ]'
    irq-load-balancing.crio.io: "disable"

2


    cpu-load-balancing.crio.io: "disable"
    cpu-quota.crio.io: "disable"
  labels:
    app: dpdk
  name: testpmd
  namespace: dpdk-test
spec:
  runtimeClassName: performance-performance

3


  containers:
    - command:
        - /bin/bash
        - -c
        - sleep INF
      image: registry.redhat.io/openshift4/dpdk-base-rhel8
      imagePullPolicy: Always
      name: dpdk
      resources:

4


        limits:
          cpu: "16"
          hugepages-1Gi: 8Gi
          memory: 2Gi
        requests:
          cpu: "16"
          hugepages-1Gi: 8Gi
          memory: 2Gi
      securityContext:
        capabilities:
          add:
            - IPC_LOCK
            - SYS_RESOURCE
            - NET_RAW
            - NET_ADMIN
        runAsUser: 0
      volumeMounts:
        - mountPath: /mnt/huge
          name: hugepages
  terminationGracePeriodSeconds: 5
  volumes:
    - emptyDir:
        medium: HugePages
      name: hugepages

Copy to Clipboard

Toggle word wrap

1: 필요한 SR-IOV 네트워크를 요청합니다. 장치의 리소스가 자동으로 삽입됩니다.
2: CPU 및 IRQ 로드 밸런싱 기반을 비활성화합니다. 자세한 내용은 개별 Pod의 인터럽트 처리 비활성화 를 참조하십시오.
3: runtimeClass 를 performance-performance 로 설정합니다. runtimeClass 를 HostNetwork 또는 privileged 로 설정하지 마십시오.
4: QoS (Quality of Service)를 사용하여 Pod를 시작하기 위해 요청 및 제한에 대해 동일한 수의 리소스를 요청합니다.

참고

SLEEP 로 Pod를 시작한 다음 Pod로 실행하여 testpmd 또는 DPDK 워크로드를 시작합니다. 그러면 exec 프로세스가 CPU에 고정되지 않으므로 추가 인터럽트가 추가될 수 있습니다.

20.10.4.4. testpmd 스크립트의 예
링크 복사

다음은 testpmd 를 실행하는 스크립트의 예입니다.

#!/bin/bash
set -ex
export CPU=$(cat /sys/fs/cgroup/cpuset/cpuset.cpus)
echo ${CPU}

dpdk-testpmd -l ${CPU} -a ${PCIDEVICE_OPENSHIFT_IO_DPDK_NIC_1} -a ${PCIDEVICE_OPENSHIFT_IO_DPDK_NIC_2} -n 4 -- -i --nb-cores=15 --rxd=4096 --txd=4096 --rxq=7 --txq=7 --forward-mode=mac --eth-peer=0,50:00:00:00:00:01 --eth-peer=1,50:00:00:00:00:02

#!/bin/bash
set -ex
export CPU=$(cat /sys/fs/cgroup/cpuset/cpuset.cpus)
echo ${CPU}

dpdk-testpmd -l ${CPU} -a ${PCIDEVICE_OPENSHIFT_IO_DPDK_NIC_1} -a ${PCIDEVICE_OPENSHIFT_IO_DPDK_NIC_2} -n 4 -- -i --nb-cores=15 --rxd=4096 --txd=4096 --rxq=7 --txq=7 --forward-mode=mac --eth-peer=0,50:00:00:00:00:01 --eth-peer=1,50:00:00:00:00:02

Copy to Clipboard

Toggle word wrap

이 예에서는 두 개의 다른 sriovNetwork CR을 사용합니다. 환경 변수에는 Pod에 할당된 VF(가상 기능) PCI 주소가 포함됩니다. Pod 정의에서 동일한 네트워크를 사용하는 경우 pciAddress 를 분할해야 합니다. 트래픽 생성기의 올바른 MAC 주소를 구성하는 것이 중요합니다. 이 예에서는 사용자 정의 MAC 주소를 사용합니다.

20.10.5. Mellanox NIC와 함께 RDMA 모드에서 가상 기능 사용
링크 복사

중요

RoCE(RDMA over Converged Ethernet)는 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

OpenShift Container Platform에서 RDMA를 사용할 때 RoCE(RDMA over Converged Ethernet)가 지원되는 유일한 모드입니다.

사전 요구 사항

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

프로세스

다음 SriovNetworkNodePolicy 오브젝트를 생성한 다음 YAML을 mlx-rdma-node-policy.yaml 파일에 저장합니다.

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: mlx-rdma-node-policy
  namespace: openshift-sriov-network-operator
spec:
  resourceName: mlxnics
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  priority: <priority>
  numVfs: <num>
  nicSelector:
    vendor: "15b3"
    deviceID: "1015" 
    pfNames: ["<pf_name>", ...]
    rootDevices: ["<pci_bus_id>", "..."]
  deviceType: netdevice 
  isRdma: true

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: mlx-rdma-node-policy
  namespace: openshift-sriov-network-operator
spec:
  resourceName: mlxnics
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  priority: <priority>
  numVfs: <num>
  nicSelector:
    vendor: "15b3"
    deviceID: "1015"

1


    pfNames: ["<pf_name>", ...]
    rootDevices: ["<pci_bus_id>", "..."]
  deviceType: netdevice

2


  isRdma: true

3

Copy to Clipboard

Toggle word wrap

1: SR-IOV 네트워크 장치의 장치 16진수 코드를 지정합니다.
2: netdevice에 가상 기능의 드라이버 유형을 지정합니다.
3: RDMA 모드를 활성화합니다.

참고

SriovNetworkNodePolicy의 각 옵션에 대한 자세한 설명은 Configuring SR-IOV network devices 섹션을 참조하십시오.

SriovNetworkNodePolicy 오브젝트에 지정된 구성을 적용하면 SR-IOV Operator가 노드를 비우고 경우에 따라 노드를 재부팅할 수 있습니다. 구성 변경 사항을 적용하는 데 몇 분이 걸릴 수 있습니다. 제거된 워크로드를 사전에 처리하는 데 클러스터에 사용 가능한 노드가 충분한지 확인하십시오.

구성 업데이트가 적용되면 openshift-sriov-network-operator 네임스페이스의 모든 Pod 상태가 Running으로 변경됩니다.

다음 명령을 실행하여 SriovNetworkNodePolicy 오브젝트를 생성합니다.
```
oc create -f mlx-rdma-node-policy.yaml
```
```
$ oc create -f mlx-rdma-node-policy.yaml
```
Copy to Clipboard Toggle word wrap
다음 SriovNetwork 오브젝트를 생성한 다음 YAML을 mlx-rdma-network.yaml 파일에 저장합니다.
```
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: mlx-rdma-network
  namespace: openshift-sriov-network-operator
spec:
  networkNamespace: <target_namespace>
  ipam: |- 
# ...
  vlan: <vlan>
  resourceName: mlxnics
```
```
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: mlx-rdma-network
  namespace: openshift-sriov-network-operator
spec:
  networkNamespace: <target_namespace>
  ipam: |- 
```
1
```
# ...
  vlan: <vlan>
  resourceName: mlxnics
```
Copy to Clipboard Toggle word wrap
1
ipam CNI 플러그인의 구성 오브젝트를 YAML 블록 스칼라로 지정합니다. 플러그인은 연결 정의에 대한 IP 주소 할당을 관리합니다.
참고
SriovNetwork의 각 옵션에 대한 자세한 설명은 " SR-IOV 추가 네트워크 구성" 섹션을 참조하십시오.
선택적 라이브러리인 app-netutil은 컨테이너의 상위 pod에 대한 네트워크 정보를 수집하기 위한 여러 API 메서드를 제공합니다.
다음 명령을 실행하여 SriovNetworkNodePolicy 오브젝트를 생성합니다.
```
oc create -f mlx-rdma-network.yaml
```
```
$ oc create -f mlx-rdma-network.yaml
```
Copy to Clipboard Toggle word wrap

다음 Pod 사양을 생성한 다음 YAML을 mlx-rdma-pod.yaml 파일에 저장합니다.

apiVersion: v1
kind: Pod
metadata:
  name: rdma-app
  namespace: <target_namespace> 
  annotations:
    k8s.v1.cni.cncf.io/networks: mlx-rdma-network
spec:
  containers:
  - name: testpmd
    image: <RDMA_image> 
    securityContext:
      runAsUser: 0
      capabilities:
        add: ["IPC_LOCK","SYS_RESOURCE","NET_RAW"] 
    volumeMounts:
    - mountPath: /dev/hugepages 
      name: hugepage
    resources:
      limits:
        memory: "1Gi"
        cpu: "4" 
        hugepages-1Gi: "4Gi" 
      requests:
        memory: "1Gi"
        cpu: "4"
        hugepages-1Gi: "4Gi"
    command: ["sleep", "infinity"]
  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages

apiVersion: v1
kind: Pod
metadata:
  name: rdma-app
  namespace: <target_namespace>

1


  annotations:
    k8s.v1.cni.cncf.io/networks: mlx-rdma-network
spec:
  containers:
  - name: testpmd
    image: <RDMA_image>

2


    securityContext:
      runAsUser: 0
      capabilities:
        add: ["IPC_LOCK","SYS_RESOURCE","NET_RAW"]

3


    volumeMounts:
    - mountPath: /dev/hugepages

4


      name: hugepage
    resources:
      limits:
        memory: "1Gi"
        cpu: "4"

5


        hugepages-1Gi: "4Gi"

6


      requests:
        memory: "1Gi"
        cpu: "4"
        hugepages-1Gi: "4Gi"
    command: ["sleep", "infinity"]
  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages

Copy to Clipboard

Toggle word wrap

1: SriovNetwork 오브젝트 mlx-rdma-network가 생성되는 동일한 target_namespace를 지정합니다. 다른 네임스페이스에서 포드를 생성하려면 Pod 사양과 SriovNetowrk 오브젝트 모두에서 target_namespace를 변경합니다.
2: 애플리케이션 및 애플리케이션에서 사용하는 RDMA 라이브러리를 포함하는 RDMA 이미지를 지정합니다.
3: hugepage 할당, 시스템 리소스 할당 및 네트워크 인터페이스 액세스를 위해 컨테이너 내부의 애플리케이션에 필요한 추가 기능을 지정합니다.
4: hugepage 볼륨을 /dev/hugepages 아래의 RDMA Pod에 마운트합니다. hugepage 볼륨은 매체가 Hugepages인 emptyDir 볼륨 유형으로 지원됩니다.
5: CPU 수를 지정합니다. RDMA Pod는 일반적으로 kubelet에서 전용 CPU를 할당해야 합니다. 이를 위해 CPU 관리자 정책을 static으로 설정하고 QoS가 Guaranteed Pod를 생성합니다.
6: hugepage 크기 hugepages-1Gi 또는 hugepages-2Mi를 지정하고 RDMA Pod에 할당할 hugepage 수량을 지정합니다. 2Mi 및 1Gi hugepage를 별도로 구성합니다. 1Gi hugepage를 구성하려면 커널 인수를 노드에 추가해야 합니다.

다음 명령을 실행하여 RDMA Pod를 생성합니다.
```
oc create -f mlx-rdma-pod.yaml
```
```
$ oc create -f mlx-rdma-pod.yaml
```
Copy to Clipboard Toggle word wrap

20.10.6. OpenStack에서 OVS-DPDK를 사용하는 클러스터에 대한 테스트 Pod 템플릿
링크 복사

다음 testpmd pod는 대규모 페이지, 예약된 CPU 및 SR-IOV 포트로 컨테이너 생성을 보여줍니다.

예제 testpmd Pod

apiVersion: v1
kind: Pod
metadata:
  name: testpmd-dpdk
  namespace: mynamespace
  annotations:
    cpu-load-balancing.crio.io: "disable"
    cpu-quota.crio.io: "disable"
# ...
spec:
  containers:
  - name: testpmd
    command: ["sleep", "99999"]
    image: registry.redhat.io/openshift4/dpdk-base-rhel8:v4.9
    securityContext:
      capabilities:
        add: ["IPC_LOCK","SYS_ADMIN"]
      privileged: true
      runAsUser: 0
    resources:
      requests:
        memory: 1000Mi
        hugepages-1Gi: 1Gi
        cpu: '2'
        openshift.io/dpdk1: 1 
      limits:
        hugepages-1Gi: 1Gi
        cpu: '2'
        memory: 1000Mi
        openshift.io/dpdk1: 1
    volumeMounts:
      - mountPath: /dev/hugepages
        name: hugepage
        readOnly: False
  runtimeClassName: performance-cnf-performanceprofile 
  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages

apiVersion: v1
kind: Pod
metadata:
  name: testpmd-dpdk
  namespace: mynamespace
  annotations:
    cpu-load-balancing.crio.io: "disable"
    cpu-quota.crio.io: "disable"
# ...
spec:
  containers:
  - name: testpmd
    command: ["sleep", "99999"]
    image: registry.redhat.io/openshift4/dpdk-base-rhel8:v4.9
    securityContext:
      capabilities:
        add: ["IPC_LOCK","SYS_ADMIN"]
      privileged: true
      runAsUser: 0
    resources:
      requests:
        memory: 1000Mi
        hugepages-1Gi: 1Gi
        cpu: '2'
        openshift.io/dpdk1: 1

1


      limits:
        hugepages-1Gi: 1Gi
        cpu: '2'
        memory: 1000Mi
        openshift.io/dpdk1: 1
    volumeMounts:
      - mountPath: /dev/hugepages
        name: hugepage
        readOnly: False
  runtimeClassName: performance-cnf-performanceprofile

2


  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages

Copy to Clipboard

Toggle word wrap

1: 이 예제의 이름 dpdk1 은 사용자가 생성한 SriovNetworkNodePolicy 리소스입니다. 이 이름을 생성한 리소스의 해당 이름으로 대체할 수 있습니다.
2: 성능 프로필의 이름이 cnf-performance 프로필 인 경우 해당 문자열을 올바른 성능 프로필 이름으로 바꿉니다.

20.10.7. OpenStack에서 OVS 하드웨어 오프로드를 사용하는 클러스터의 테스트 pod 템플릿
링크 복사

다음 testpmd pod는 RHOSP(Red Hat OpenStack Platform)에서 OVS(Open vSwitch) 하드웨어 오프로드를 보여줍니다.

예제 testpmd Pod

apiVersion: v1
kind: Pod
metadata:
  name: testpmd-sriov
  namespace: mynamespace
  annotations:
    k8s.v1.cni.cncf.io/networks: hwoffload1
spec:
  runtimeClassName: performance-cnf-performanceprofile 
  containers:
  - name: testpmd
    command: ["sleep", "99999"]
    image: registry.redhat.io/openshift4/dpdk-base-rhel8:v4.9
    securityContext:
      capabilities:
        add: ["IPC_LOCK","SYS_ADMIN"]
      privileged: true
      runAsUser: 0
    resources:
      requests:
        memory: 1000Mi
        hugepages-1Gi: 1Gi
        cpu: '2'
      limits:
        hugepages-1Gi: 1Gi
        cpu: '2'
        memory: 1000Mi
    volumeMounts:
      - mountPath: /dev/hugepages
        name: hugepage
        readOnly: False
  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages

apiVersion: v1
kind: Pod
metadata:
  name: testpmd-sriov
  namespace: mynamespace
  annotations:
    k8s.v1.cni.cncf.io/networks: hwoffload1
spec:
  runtimeClassName: performance-cnf-performanceprofile

1


  containers:
  - name: testpmd
    command: ["sleep", "99999"]
    image: registry.redhat.io/openshift4/dpdk-base-rhel8:v4.9
    securityContext:
      capabilities:
        add: ["IPC_LOCK","SYS_ADMIN"]
      privileged: true
      runAsUser: 0
    resources:
      requests:
        memory: 1000Mi
        hugepages-1Gi: 1Gi
        cpu: '2'
      limits:
        hugepages-1Gi: 1Gi
        cpu: '2'
        memory: 1000Mi
    volumeMounts:
      - mountPath: /dev/hugepages
        name: hugepage
        readOnly: False
  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages

Copy to Clipboard

Toggle word wrap

1: 성능 프로필의 이름이 cnf-performance 프로필 인 경우 해당 문자열을 올바른 성능 프로필 이름으로 바꿉니다.

20.11. Pod 수준 본딩 사용
링크 복사

Pod 수준의 본딩은 고가용성과 처리량이 필요한 Pod 내부의 워크로드를 활성화하는 데 중요합니다. Pod 수준 본딩을 사용하면 커널 모드 인터페이스에서 여러 개의 단일 루트 I/O 가상화(SR-IOV) 가상 기능 인터페이스에서 본딩 인터페이스를 생성할 수 있습니다. SR-IOV 가상 기능은 Pod에 전달되고 커널 드라이버에 연결됩니다.

Pod 수준 본딩이 필요한 한 가지 시나리오는 다양한 물리적 기능에 여러 SR-IOV 가상 함수에서 본딩 인터페이스를 생성하는 것입니다. 호스트의 서로 다른 물리 함수 두 개에서 본딩 인터페이스를 생성하여 Pod 수준에서 고가용성 및 처리량을 달성할 수 있습니다.

SR-IOV 네트워크, 네트워크 정책, 네트워크 연결 정의 및 Pod 생성과 같은 작업에 대한 지침은 SR-IOV 네트워크 장치 구성을 참조하십시오.

20.11.1. SR-IOV 인터페이스 두 개에서 본딩 인터페이스 구성
링크 복사

본딩을 사용하면 여러 네트워크 인터페이스를 단일 논리 "보딩" 인터페이스로 통합할 수 있습니다. 본딩 컨테이너 네트워크 인터페이스(Bond-CNI)는 본딩 기능을 컨테이너에 제공합니다.

bond-CNI는 SR-IOV(Single Root I/O Virtualization) 가상 기능을 사용하여 생성할 수 있으며 컨테이너 네트워크 네임스페이스에 배치할 수 있습니다.

OpenShift Container Platform은 SR-IOV 가상 기능을 사용하는 Bond-CNI만 지원합니다. SR-IOV Network Operator는 가상 기능을 관리하는 데 필요한 SR-IOV CNI 플러그인을 제공합니다. 기타 CNI 또는 인터페이스 유형은 지원되지 않습니다.

사전 요구 사항

컨테이너에서 가상 기능을 가져오도록 SR-IOV Network Operator를 설치하고 구성해야 합니다.
SR-IOV 인터페이스를 구성하려면 각 인터페이스에 대해 SR-IOV 네트워크 및 정책을 생성해야 합니다.
SR-IOV Network Operator는 정의된 SR-IOV 네트워크 및 정책을 기반으로 각 SR-IOV 인터페이스에 대한 네트워크 연결 정의를 생성합니다.
linkState 는 SR-IOV 가상 기능의 기본값 auto 로 설정됩니다.

20.11.1.1. 본딩 네트워크 연결 정의 생성
링크 복사

이제 SR-IOV 가상 기능을 사용할 수 있으므로 본딩 네트워크 연결 정의를 생성할 수 있습니다.

apiVersion: "k8s.cni.cncf.io/v1"
    kind: NetworkAttachmentDefinition
    metadata:
      name: bond-net1
      namespace: demo
    spec:
      config: '{
      "type": "bond", 
      "cniVersion": "0.3.1",
      "name": "bond-net1",
      "mode": "active-backup", 
      "failOverMac": 1, 
      "linksInContainer": true, 
      "miimon": "100",
      "mtu": 1500,
      "links": [ 
            {"name": "net1"},
            {"name": "net2"}
        ],
      "ipam": {
            "type": "host-local",
            "subnet": "10.56.217.0/24",
            "routes": [{
            "dst": "0.0.0.0/0"
            }],
            "gateway": "10.56.217.1"
        }
      }'

apiVersion: "k8s.cni.cncf.io/v1"
    kind: NetworkAttachmentDefinition
    metadata:
      name: bond-net1
      namespace: demo
    spec:
      config: '{
      "type": "bond",

1


      "cniVersion": "0.3.1",
      "name": "bond-net1",
      "mode": "active-backup",

2


      "failOverMac": 1,

3


      "linksInContainer": true,

4


      "miimon": "100",
      "mtu": 1500,
      "links": [

5


            {"name": "net1"},
            {"name": "net2"}
        ],
      "ipam": {
            "type": "host-local",
            "subnet": "10.56.217.0/24",
            "routes": [{
            "dst": "0.0.0.0/0"
            }],
            "gateway": "10.56.217.1"
        }
      }'

Copy to Clipboard

Toggle word wrap

cni-type은 항상 bond 로 설정됩니다.

mode 속성은 본딩 모드를 지정합니다.

참고

지원되는 본딩 모드는 다음과 같습니다.

balance-rr - 0
active-backup - 1
balance-xor - 2

balance-rr 또는 balance-xor 모드의 경우 SR-IOV 가상 기능에 대해 신뢰 모드를 on 으로 설정해야 합니다.