네트워킹

프로세스

1. openshift-install 명령으로 생성된 가상 프라이빗 클라우드(VPC)에 SSH로 액세스할 수 있는 보안 그룹을 만듭니다.
2. 설치 관리자가 생성한 퍼블릭 서브넷 중 하나에 Amazon EC2 인스턴스를 생성합니다.

3. 생성한 Amazon EC2 인스턴스와 퍼블릭 IP 주소를 연결합니다.

   OpenShift Container Platform 설치와는 달리, 생성한 Amazon EC2 인스턴스를 SSH 키 쌍과 연결해야 합니다. 이 인스턴스에서 사용되는 운영 체제는 중요하지 않습니다. 그저 인터넷을 OpenShift Container Platform 클러스터의 VPC에 연결하는 SSH 베스천의 역할을 수행하기 때문입니다. 사용하는 AMI(Amazon 머신 이미지)는 중요합니다. 예를 들어, RHCOS(Red Hat Enterprise Linux CoreOS)를 사용하면 설치 프로그램과 마찬가지로 Ignition을 통해 키를 제공할 수 있습니다.

4. Amazon EC2 인스턴스를 프로비저닝한 후 SSH로 연결할 수 있는 경우 OpenShift Container Platform 설치와 연결된 SSH 키를 추가해야 합니다. 이 키는 베스천 인스턴스의 키와 다를 수 있지만 반드시 달라야 하는 것은 아닙니다.

   참고

   SSH 직접 액세스는 재해 복구 시에만 권장됩니다. Kubernetes API가 응답할 때는 권한 있는 Pod를 대신 실행합니다.

5. oc get nodes를 실행하고 출력을 확인한 후 마스터 노드 중 하나를 선택합니다. 호스트 이름은 ip-10-0-1-163.ec2.internal과 유사합니다.

6. Amazon EC2에 수동으로 배포한 베스천 SSH 호스트에서 해당 컨트롤 플레인 호스트에 SSH로 연결합니다. 설치 중 지정한 것과 동일한 SSH 키를 사용해야 합니다.

   $ ssh -i <ssh-key-path> core@<master-hostname>

1. 다음 명령을 실행하여 배포 상태를 확인합니다.

   $ oc get -n openshift-network-operator deployment/network-operator

   출력 예

   NAME               READY   UP-TO-DATE   AVAILABLE   AGE
   network-operator   1/1     1            1           56m

2. 다음 명령을 실행하여 Cluster Network Operator의 상태를 확인합니다.

   $ oc get clusteroperator/network

   출력 예

   NAME      VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE
   network   4.5.4     True        False         False      50m

   AVAILABLE, PROGRESSING 및 DEGRADED 필드에서 Operator 상태에 대한 정보를 볼 수 있습니다. Cluster Network Operator가 사용 가능한 상태 조건을 보고하는 경우 AVAILABLE 필드는 True로 설정됩니다.

1. oc get 명령을 사용하여 배포 상태를 확인합니다.

   $ oc get -n openshift-dns-operator deployment/dns-operator

   출력 예

   NAME           READY     UP-TO-DATE   AVAILABLE   AGE
   dns-operator   1/1       1            1           23h

2. oc get 명령을 사용하여 DNS Operator의 상태를 확인합니다.

   $ oc get clusteroperator/dns

   출력 예

   NAME      VERSION     AVAILABLE   PROGRESSING   DEGRADED   SINCE
   dns       4.1.0-0.11  True        False         False      92m

   AVAILABLE, PROGRESSING 및 DEGRADED는 Operator의 상태에 대한 정보를 제공합니다. AVAILABLE은 CoreDNS 데몬 세트에서 1개 이상의 포드가 Available 상태 조건을 보고할 때 True입니다.

프로세스

1. oc describe 명령을 사용하여 기본 dns를 확인합니다.

   $ oc describe dns.operator/default

   출력 예

   Name:         default
   Namespace:
   Labels:       <none>
   Annotations:  <none>
   API Version:  operator.openshift.io/v1
   Kind:         DNS
   ...
   Status:
     Cluster Domain:  cluster.local 1
     Cluster IP:      172.30.0.10 2
   ...

   1

   Cluster Domain 필드는 정규화된 pod 및 service 도메인 이름을 구성하는 데 사용되는 기본 DNS 도메인입니다.

   2

   Cluster IP는 이름을 확인하기 위한 주소 Pod 쿼리입니다. IP는 service CIDR 범위에서 10번째 주소로 정의됩니다.

2. 클러스터의 service CIDR을 찾으려면 oc get 명령을 사용합니다.

   $ oc get networks.config/cluster -o jsonpath='{$.status.serviceNetwork}'

절차

1. 이름이 default인 DNS Operator 오브젝트를 수정합니다.

   $ oc edit dns.operator/default

   이를 통해 Operator는 Server 를 기반으로 추가 서버 구성 블록으로 dns-default 라는 구성 맵을 생성하고 업데이트할 수 있습니다. 서버에 쿼리와 일치하는 영역이 없는 경우 이름 확인은 업스트림 DNS 서버로 대체됩니다.

   DNS 전달 구성

   apiVersion: operator.openshift.io/v1
   kind: DNS
   metadata:
     name: default
   spec:
     servers:
     - name: example-server 1
       zones: 2
       - example.com
       forwardPlugin:
         policy: Random 3
         upstreams: 4
         - 1.1.1.1
         - 2.2.2.2:5353
     upstreamResolvers: 5
       policy: Random 6
       upstreams: 7
       - type: SystemResolvConf 8
       - type: Network
         address: 1.2.3.4 9
         port: 53 10

   1

   rfc6335 서비스 이름 구문을 준수해야 합니다.

   2

   rfc1123 서비스 이름 구문의 하위 도메인 정의를 준수해야 합니다. cluster domain, cluster.local.local은 zones 필드에 유효하지 않은 하위 도메인입니다.

   3

   업스트림 리졸버를 선택할 정책을 정의합니다. 기본값은 Random 입니다. 또한 RoundRobin 및 Sequential 값을 사용할 수도 있습니다.

   4

   forwardPlugin당 최대 15개의 업스트림이 허용됩니다.

   5

   선택 사항: 이를 사용하여 기본 정책을 재정의하고 DNS 확인을 기본 도메인의 지정된 DNS 확인자(업스트림 확인자)로 전달할 수 있습니다. 업스트림 리졸버를 제공하지 않으면 DNS 이름 쿼리는 /etc/resolv.conf 의 서버로 이동합니다.

   6

   조회를 위해 업스트림 서버가 선택된 순서를 결정합니다. 다음 값 중 하나를 지정할 수 있습니다: Random,RoundRobin, 또는 Sequential. 기본값은 Sequential 입니다.

   7

   선택 사항: 이를 사용하여 업스트림 확인자를 제공할 수 있습니다.

   8

   두 가지 유형의 업스트림 ( SystemResolvConf 및 Network )을 지정할 수 있습니다. SystemResolvConf 는 /etc/resolv.conf 및 Network 를 사용하도록 업스트림을 구성하여 Networkresolver 를 정의합니다. 하나 또는 둘 다를 지정할 수 있습니다.

   9

   지정된 유형이 네트워크 이면 IP 주소를 제공해야 합니다. address 필드는 유효한 IPv4 또는 IPv6 주소여야 합니다.

   10

   지정된 유형이 네트워크 이면 선택적으로 포트를 제공할 수 있습니다. 포트 필드는 1 에서 65535 사이의 값을 가져야합니다. 업스트림 포트를 지정하지 않으면 기본적으로 포트 853이 시도됩니다.

   고도로 규제된 환경에서 작업하는 경우 추가 DNS 트래픽 및 데이터 개인 정보를 확보할 수 있도록 요청을 업스트림 리졸버에 전달할 때 DNS 트래픽을 보호할 수 있는 기능이 필요할 수 있습니다. 클러스터 관리자는 전달된 DNS 쿼리에 대해 TLS(Transport Layer Security)를 구성할 수 있습니다.

   TLS를 사용하여 DNS 전달 구성

   apiVersion: operator.openshift.io/v1
   kind: DNS
   metadata:
     name: default
   spec:
     servers:
     - name: example-server 1
       zones: 2
       - example.com
       forwardPlugin:
         transportConfig:
           transport: TLS 3
           tls:
             caBundle:
               name: mycacert
             serverName: dnstls.example.com  4
         policy: Random 5
         upstreams: 6
         - 1.1.1.1
         - 2.2.2.2:5353
     upstreamResolvers: 7
       transportConfig:
         transport: TLS
         tls:
           caBundle:
             name: mycacert
           serverName: dnstls.example.com
       upstreams:
       - type: Network 8
         address: 1.2.3.4 9
         port: 53 10

   1

   rfc6335 서비스 이름 구문을 준수해야 합니다.

   2

   rfc1123 서비스 이름 구문의 하위 도메인 정의를 준수해야 합니다. cluster domain, cluster.local.local은 zones 필드에 유효하지 않은 하위 도메인입니다. 클러스터 도메인에 해당하는 cluster.local은 영역에 유효하지 않은 하위 도메인입니다.

   3

   전달된 DNS 쿼리를 위해 TLS를 구성할 때 값 TLS 를 갖도록 transport 필드를 설정합니다. 기본적으로 CoreDNS는 10초 동안 연결을 전달했습니다. 요청이 발행되지 않은 경우 CoreDNS는 10초 동안 열려 있는 TCP 연결을 유지합니다. 대규모 클러스터를 사용하면 노드당 연결을 시작할 수 있으므로 DNS 서버에서 많은 새 연결이 열려 있을 수 있음을 확인합니다. 성능 문제를 방지하기 위해 적절하게 DNS 계층을 설정합니다.

   4

   전달된 DNS 쿼리에 대해 TLS를 구성할 때 이는 업스트림 TLS 서버 인증서를 검증하기 위해 SNI(서버 이름 표시)의 일부로 사용되는 필수 서버 이름입니다.

   5

   업스트림 리졸버를 선택할 정책을 정의합니다. 기본값은 Random 입니다. 또한 RoundRobin 및 Sequential 값을 사용할 수도 있습니다.

   6

   필수 항목입니다. 이를 사용하여 업스트림 확인자를 제공할 수 있습니다. forwardPlugin 항목당 최대 15 개의 업스트림 항목을 사용할 수 있습니다.

   7

   선택 사항: 이를 사용하여 기본 정책을 재정의하고 DNS 확인을 기본 도메인의 지정된 DNS 확인자(업스트림 확인자)로 전달할 수 있습니다. 업스트림 리졸버를 제공하지 않으면 DNS 이름 쿼리는 /etc/resolv.conf 의 서버로 이동합니다.

   8

   네트워크 유형은 이 업스트림 확인자가 /etc/resolv.conf 에 나열된 업스트림 확인자와 별도로 전달된 요청을 처리해야 함을 나타냅니다. TLS를 사용하는 경우 네트워크 유형만 허용되며 IP 주소를 제공해야 합니다.

   9

   address 필드는 유효한 IPv4 또는 IPv6 주소여야 합니다.

   10

   선택적으로 포트를 제공할 수 있습니다. 포트 는 1 에서 65535 사이의 값을 가져야합니다. 업스트림 포트를 지정하지 않으면 기본적으로 포트 853이 시도됩니다.

   참고

   servers 가 정의되지 않았거나 유효하지 않은 경우 구성 맵에는 기본 서버만 포함됩니다.

2. 구성 맵을 표시합니다.

   $ oc get configmap/dns-default -n openshift-dns -o yaml

   이전 샘플 DNS를 기반으로 하는 샘플 DNS ConfigMap

   apiVersion: v1
   data:
     Corefile: |
       example.com:5353 {
           forward . 1.1.1.1 2.2.2.2:5353
       }
       bar.com:5353 example.com:5353 {
           forward . 3.3.3.3 4.4.4.4:5454 1
       }
       .:5353 {
           errors
           health
           kubernetes cluster.local in-addr.arpa ip6.arpa {
               pods insecure
               upstream
               fallthrough in-addr.arpa ip6.arpa
           }
           prometheus :9153
           forward . /etc/resolv.conf 1.2.3.4:53 {
               policy Random
           }
           cache 30
           reload
       }
   kind: ConfigMap
   metadata:
     labels:
       dns.operator.openshift.io/owning-dns: default
     name: dns-default
     namespace: openshift-dns

   1

   forwardPlugin을 변경하면 CoreDNS 데몬 세트의 롤링 업데이트가 트리거됩니다.

프로세스

1. 다음 명령을 실행하여 hello-openshift 라는 프로젝트를 생성합니다.

   $ oc new-project hello-openshift

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

   $ oc create -f https://raw.githubusercontent.com/openshift/origin/master/examples/hello-openshift/hello-pod.json

3. 다음 명령을 실행하여 hello-openshift 라는 서비스를 생성합니다.

   $ oc expose pod/hello-openshift

4. hello-openshift-route.yaml 이라는 경로 정의를 생성합니다.

   분할을 위해 생성된 경로의 YAML 정의:

   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

   1

   레이블 키와 해당 레이블 값은 Ingress 컨트롤러에 지정된 라벨과 일치해야 합니다. 이 예제에서 Ingress 컨트롤러에는 레이블 키와 값 type: sharded 가 있습니다.

   2

   경로는 subdomain 필드의 값을 사용하여 노출됩니다. 하위 도메인 필드를 지정할 때 호스트 이름을 설정되지 않은 상태로 두어야 합니다. host 및 subdomain 필드를 모두 지정하면 경로는 호스트 필드의 값을 사용하고 subdomain 필드를 무시합니다.

5. 다음 명령을 실행하여 hello-openshift-route.yaml 을 사용하여 hello-openshift 애플리케이션에 대한 경로를 생성합니다.

   $ oc -n hello-openshift create -f hello-openshift-route.yaml

프로세스

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

   $ oc get podnetworkconnectivitycheck -n openshift-network-diagnostics

   출력 예

   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

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

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

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

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

      여기서 <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"

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

   $ oc describe network.config cluster

   출력 예

   ...
   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
   ...

2. 하드웨어 MTU 설정을 준비합니다.

   • DHCP를 사용하여 하드웨어 MTU를 지정하는 경우 다음 dnsmasq 구성과 같은 DHCP 구성을 업데이트합니다.

     dhcp-option-force=26,<mtu>

     다음과 같습니다.

     <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 }'

          다음과 같습니다.

          <node_name>

          클러스터의 노드 이름을 지정합니다.

        • OVN-Kubernetes 클러스터 네트워크 공급자를 사용하는 경우 다음 명령을 입력합니다.

          $ oc debug node/<node_name> -- chroot /host nmcli -g connection.interface-name c show ovs-if-phys0

          다음과 같습니다.

          <node_name>

          클러스터의 노드 이름을 지정합니다.

     2. 이전 명령에서 반환된 인터페이스 이름에 대해 NetworkManager가 생성한 연결 프로필을 찾으려면 다음 명령을 입력합니다.

        $ oc debug node/<node_name> -- chroot /host nmcli c | grep <interface>

        다음과 같습니다.

        <interface>

        기본 네트워크 인터페이스의 이름을 지정합니다.

        OpenShift SDN의 출력 예

        Wired connection 1  46da4a6a-xxxx-xxxx-xxxx-ac0ca900f213  ethernet  ens3

        원래 연결 구성이 없는 OVN-Kubernetes의 출력 예

        ovs-if-phys0        353774d3-0d3d-4ada-b14e-cd4d8824e2a8  ethernet       ens4
        ovs-port-phys0      332ef950-b2e5-4991-a0dc-3158977c35ca  ovs-port       ens4

        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

        다음과 같습니다.

        <node_name>

        클러스터의 노드 이름을 지정합니다.

        <uuid>

        NetworkManager 연결 프로필의 UUID를 지정합니다.

        출력 예

        /run/NetworkManager/system-connections/Wired connection 1.nmconnection

     4. 노드에서 NetworkManager 연결 구성을 복사하려면 다음 명령을 입력합니다.

        $ oc debug node/<node_name> -- chroot /host cat "<profile_path>" > config.nmconnection

        다음과 같습니다.

        <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

     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

     6. 컨트롤 플레인 노드 및 클러스터의 작업자 노드에 대해 하나씩 두 개의 MachineConfig 오브젝트를 생성합니다.

        1. 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

           1

           기본 네트워크 인터페이스에 대한 NetworkManager 연결 이름을 지정합니다.

           2

           이전 단계에서 업데이트된 NetworkManager 구성 파일의 로컬 파일 이름을 지정합니다.

        2. 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

           1

           기본 네트워크 인터페이스에 대한 NetworkManager 연결 이름을 지정합니다.

           2

           이전 단계에서 업데이트된 NetworkManager 구성 파일의 로컬 파일 이름을 지정합니다.

        3. 다음 명령을 실행하여 Butane 구성에서 MachineConfig 오브젝트를 생성합니다.

           $ for manifest in control-plane-interface worker-interface; do
               butane --files-dir . $manifest.bu > $manifest.yaml
             done

3. 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> } } } } }'

   다음과 같습니다.

   <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} } } } }'

4. MCO는 각 머신 구성 풀의 머신을 업데이트할 때 각 노드를 하나씩 재부팅합니다. 모든 노드가 업데이트될 때까지 기다려야 합니다. 다음 명령을 입력하여 머신 구성 풀 상태를 확인합니다.

   $ oc get mcp

   업데이트된 노드의 상태가 UPDATED=true, UPDATING=false,DEGRADED=false입니다.

   참고

   기본적으로 MCO는 풀당 한 번에 하나의 시스템을 업데이트하므로 클러스터 크기에 따라 마이그레이션에 걸리는 총 시간이 증가합니다.

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

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

      $ oc describe node | egrep "hostname|machineconfig"

      출력 예

      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

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

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

   2. 머신 구성이 올바른지 확인하려면 다음 명령을 입력합니다.

      $ oc get machineconfig <config_name> -o yaml | grep ExecStart

      여기서 <config_name>은 machineconfiguration.openshift.io/currentConfig 필드에서 머신 구성의 이름입니다.

      머신 구성은 다음 업데이트를 systemd 구성에 포함해야 합니다.

      ExecStart=/usr/local/bin/mtu-migration.sh

6. 기본 네트워크 인터페이스 MTU 값을 업데이트합니다.

   • NetworkManager 연결 구성으로 새 MTU를 지정하는 경우 다음 명령을 입력합니다. MachineConfig Operator는 클러스터의 노드 롤링 재부팅을 자동으로 수행합니다.

     $ for manifest in control-plane-interface worker-interface; do
         oc create -f $manifest.yaml
       done

   • DHCP 서버 옵션 또는 커널 명령줄 및 PXE로 새 MTU를 지정하는 경우 인프라에 필요한 변경을 수행합니다.

7. MCO는 각 머신 구성 풀의 머신을 업데이트할 때 각 노드를 하나씩 재부팅합니다. 모든 노드가 업데이트될 때까지 기다려야 합니다. 다음 명령을 입력하여 머신 구성 풀 상태를 확인합니다.

   $ oc get mcp

   업데이트된 노드의 상태가 UPDATED=true, UPDATING=false,DEGRADED=false입니다.

   참고

   기본적으로 MCO는 풀당 한 번에 하나의 시스템을 업데이트하므로 클러스터 크기에 따라 마이그레이션에 걸리는 총 시간이 증가합니다.

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

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

      $ oc describe node | egrep "hostname|machineconfig"

      출력 예

      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

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

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

   2. 머신 구성이 올바른지 확인하려면 다음 명령을 입력합니다.

      $ oc get machineconfig <config_name> -o yaml | grep path:

      여기서 <config_name>은 machineconfiguration.openshift.io/currentConfig 필드에서 머신 구성의 이름입니다.

      머신 구성이 성공적으로 배포된 경우 이전 출력에 /etc/NetworkManager/system-connections/<connection_name > 파일 경로가 포함됩니다.

      머신 구성에는 ExecStart=/usr/local/bin/mtu-migration.sh 행이 포함되어 있지 않아야 합니다.

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

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

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

     다음과 같습니다.

     <mtu>

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

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

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

     다음과 같습니다.

     <mtu>

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

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

   $ oc describe network.config cluster

2. 노드의 기본 네트워크 인터페이스에 대한 현재 MTU를 가져옵니다.

   1. 클러스터의 노드를 나열하려면 다음 명령을 입력합니다.

      $ oc get nodes

   2. 노드의 기본 네트워크 인터페이스의 현재 MTU 설정을 가져오려면 다음 명령을 입력합니다.

      $ oc debug node/<node> -- chroot /host ip address show <interface>

      다음과 같습니다.

      <node>

      이전 단계의 출력에서 노드를 지정합니다.

      <interface>

      노드의 기본 네트워크 인터페이스 이름을 지정합니다.

      출력 예

      ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8051

프로세스

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

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

   작은 정보

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

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

   출력 예

   network.config.openshift.io/cluster patched

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

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

   출력 예

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

프로세스

1. IP 페일오버 서비스 계정을 생성합니다.

   $ oc create sa ipfailover

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

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

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

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

   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

   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

   배포를 만들기 전에 풀 시크릿을 생성합니다. 그렇지 않으면 배포를 생성할 때 오류가 발생합니다.

프로세스

1. 원하는 스크립트를 생성하고 해당 스크립트를 유지할 구성 맵을 생성합니다. 스크립트에는 입력 인수가 없으며 OK의 경우 0을fail의 경우 1을 반환해야 합니다.

   검사 스크립트, mycheckscript.sh:

   #!/bin/bash
       # Whatever tests are needed
       # E.g., send request and verify response
   exit 0

2. config map을 생성합니다.

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

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

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

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

   참고

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

   작은 정보

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

   $ oc edit deploy ipfailover-keepalived

       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
   ...

   1

   spec.container.env 필드에서 마운트된 스크립트 파일을 가리키도록 OPENSHIFT_HA_CHECK_SCRIPT 환경 변수를 추가합니다.

   2

   spec.container.volumeMounts 필드를 추가하여 마운트 지점을 생성합니다.

   3

   새 spec.volumes 필드를 추가하여 구성 맵을 언급합니다.

   4

   파일에 대한 실행 권한을 설정합니다. 다시 읽으면 10진수 493으로 표시됩니다.

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

절차

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

   1. 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}"

      출력 예

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

   2. 이전 단계에서 볼륨으로 사용되는 구성 맵의 이름을 제공한 경우 구성 맵을 삭제합니다.

      $ oc delete configmap <configmap_name>

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

   $ oc get deployment -l ipfailover

   출력 예

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

3. 배포를 삭제합니다.

   $ oc delete deployment <ipfailover_deployment_name>

4. ipfailover 서비스 계정을 제거합니다.

   $ oc delete sa ipfailover

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

   1. 다음 예와 유사한 콘텐츠를 사용하여 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

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

   2. 작업을 실행합니다.

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

      출력 예

      job.batch/remove-ipfailover-2h8dm created

프로세스

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

   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
           }
         }
        ]
   }

   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"
           }
       }
     ]
   }'

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

   $ oc apply -f tuning-example.yaml

   출력 예

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

3. 다음과 유사한 네트워크 연결 정의를 사용하여 examplepod.yaml 과 같은 Pod를 생성합니다.

   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

   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 프로필을 활성화합니다.

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

   $ oc apply -f examplepod.yaml

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

   $ oc get pod

   출력 예

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

6. 다음 명령을 실행하여 Pod에 로그인합니다.

   $ oc rsh tunepod

7. 구성된 sysctl 플래그 값을 확인합니다. 예를 들어 다음 명령을 실행하여 net.ipv4.conf.net1.accept_redirects 값을 찾습니다.

   sh-4.4# sysctl net.ipv4.conf.net1.accept_redirects

   예상 출력

   net.ipv4.conf.net1.accept_redirects = 1

프로세스

1. 다음 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

2. MachineConfig 오브젝트를 생성하려면 다음 명령을 입력합니다.

   $ oc create -f load-sctp-module.yaml

3. 선택 사항: MachineConfig Operator가 구성 변경 사항을 적용하는 동안 노드의 상태를 보려면 다음 명령을 입력합니다. 노드 상태가 Ready로 전환되면 구성 업데이트가 적용됩니다.

   $ oc get nodes

프로세스

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

   1. 다음 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

   2. 다음 명령을 입력하여 pod를 생성합니다.

      $ oc create -f sctp-server.yaml

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

   1. 다음 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

   2. 서비스를 생성하려면 다음 명령을 입력합니다.

      $ oc create -f sctp-service.yaml

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

   1. 다음 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"]

   2. Pod 오브젝트를 생성하려면 다음 명령을 입력합니다.

      $ oc apply -f sctp-client.yaml

4. 서버에서 SCTP 리스너를 실행합니다.

   1. 서버 Pod에 연결하려면 다음 명령을 입력합니다.

      $ oc rsh sctpserver

   2. SCTP 리스너를 시작하려면 다음 명령을 입력합니다.

      $ nc -l 30102 --sctp

5. 서버의 SCTP 리스너에 연결합니다.

   1. 터미널 프로그램에서 새 터미널 창 또는 탭을 엽니다.

   2. sctpservice 서비스의 IP 주소를 얻습니다. 다음 명령을 실행합니다.

      $ oc get services sctpservice -o go-template='{{.spec.clusterIP}}{{"\n"}}'

   3. 클라이언트 Pod에 연결하려면 다음 명령을 입력합니다.

      $ oc rsh sctpclient

   4. SCTP 클라이언트를 시작하려면 다음 명령을 입력합니다. <cluster_IP>를 sctpservice 서비스의 클러스터 IP 주소로 변경합니다.

      # nc <cluster_IP> 30102 --sctp

절차

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

   1. 다음 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"

   2. 네임스페이스 CR을 생성합니다.

      $ oc create -f ptp-namespace.yaml

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

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

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

   2. OperatorGroup CR을 생성합니다.

      $ oc create -f ptp-operatorgroup.yaml

3. PTP Operator에 등록합니다.

   1. 다음 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

   2. 서브스크립션 CR을 생성합니다.

      $ oc create -f ptp-sub.yaml

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

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

   출력 예

   Name                         Phase
   4.12.0-202301261535          Succeeded

프로세스

1. OpenShift Container Platform 웹 콘솔을 사용하여 PTP Operator를 설치합니다.

   1. OpenShift Container Platform 웹 콘솔에서 Operator → OperatorHub를 클릭합니다.
   2. 사용 가능한 Operator 목록에서 PTP Operator를 선택한 다음 설치를 클릭합니다.
   3. Operator 설치 페이지의 클러스터의 특정 네임스페이스에서 openshift-ptp를 선택합니다. 그런 다음, 설치를 클릭합니다.

2. 선택 사항: PTP Operator가 설치되었는지 확인합니다.

   1. Operator → 설치된 Operator 페이지로 전환합니다.

   2. PTP Operator가 openshift-ptp 프로젝트에 InstallSucceeded 상태로 나열되어 있는지 확인합니다.

      참고

      설치 중에 Operator는 실패 상태를 표시할 수 있습니다. 나중에 InstallSucceeded 메시지와 함께 설치에 성공하면 이 실패 메시지를 무시할 수 있습니다.

      Operator가 설치된 것으로 나타나지 않으면 다음과 같이 추가 문제 해결을 수행합니다.

      • Operator → 설치된 Operator 페이지로 이동하고 Operator 서브스크립션 및 설치 계획 탭의 상태에 장애나 오류가 있는지 검사합니다.
      • Workloads → Pod 페이지로 이동하여 openshift-ptp 프로젝트에서 Pod 로그를 확인합니다.

절차

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

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

   출력 예

   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

   참고

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

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

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

   출력 예

   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

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

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

   다음과 같습니다.

   <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

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

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

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

      출력 예

      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

   2. 필수 linuxptp-daemon 컨테이너로의 원격 쉘:

      $ oc rsh -n openshift-ptp -c linuxptp-daemon-container <linux_daemon_container>

      다음과 같습니다.

      <linux_daemon_container>

      진단할 컨테이너입니다 (예: linuxptp-daemon-lmvgn).

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

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

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

      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