프로세스

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는 서버를 기반으로 추가 서버 구성 블록을 사용하여 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.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 resolver 를 정의합니다. 둘 중 하나 또는 둘 다를 지정할 수 있습니다.

   9

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

   10

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

2. 선택 사항: 고도로 규제된 환경에서 작업할 때 추가 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.local 은 zones 필드에 유효하지 않은 하위 도메인입니다. 클러스터 도메인에 해당하는 cluster.local은 영역에 유효하지 않은 하위 도메인입니다.

   3

   전달된 DNS 쿼리에 대해 TLS를 구성할 때 전송 필드를 값 TLS 를 갖도록 설정합니다. 기본적으로 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 가 정의되지 않았거나 유효하지 않은 경우 구성 맵에는 기본 서버만 포함됩니다.

검증

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

   $ 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. 다음 명령을 실행하여 default 라는 DNS Operator 오브젝트를 편집합니다.

   $ oc edit dns.operator.openshift.io/default

2. TTL(Time-to-live) 캐싱 값을 수정합니다.

   DNS 캐싱 구성

   apiVersion: operator.openshift.io/v1
   kind: DNS
   metadata:
     name: default
   spec:
     cache:
       positiveTTL: 1h 1
       negativeTTL: 0.5h10m 2

   1

   문자열 값 1h 는 CoreDNS에서 해당 초 수로 변환됩니다. 이 필드를 생략하면 값이 0s 로 간주되고 클러스터는 내부 기본값 900s 를 대체 값으로 사용합니다.

   2

   문자열 값은 0.5h10m 과 같은 단위의 조합일 수 있으며 CoreDNS에서 해당 초 수로 변환됩니다. 이 필드를 생략하면 값이 0s 로 간주되고 클러스터는 내부 기본값인 30s 를 대체 값으로 사용합니다.

   주의

   TTL 필드를 낮은 값으로 설정하면 클러스터의 부하 증가, 모든 업스트림 리졸버 또는 둘 다 발생할 수 있습니다.

절차

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

   label 키와 해당 레이블 값은 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. ingressnodefirewallconfig 라는 openshift-ingress-node-firewall 네임스페이스에 IngressNodeFirewallConfig 를 생성합니다.

2. 다음 명령을 실행하여 Ingress Node Firewall Operator 규칙을 배포합니다.

   $ oc apply -f rule.yaml

절차

1. 다음 명령을 실행하여 모든 현재 규칙을 확인합니다.

   $ oc get ingressnodefirewall

2. 반환된 < resource> 이름 중 하나를 선택하고 다음 명령을 실행하여 규칙 또는 구성을 확인합니다.

   $ oc get <resource> <name> -o yaml

절차

1. 다음을 포함하는 sample-ingress.yaml 이라는 CR(사용자 정의 리소스) 파일을 생성합니다.

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

   1

   IngressController 오브젝트의 이름으로 <name>을 지정합니다.

   2

   사전 요구 사항으로 생성된 DNS 레코드를 기반으로 도메인을 지정합니다.

   3

   로드 밸런서를 외부로 노출하려면 범위를 External 로 지정합니다.

   4

   dnsManagementPolicy 는 Ingress 컨트롤러가 로드 밸런서와 연결된 와일드카드 DNS 레코드의 라이프사이클을 관리하고 있는지 여부를 나타냅니다. 유효한 값은 Managed 및 Unmanaged 입니다. 기본값은 Managed 입니다.

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

   oc apply -f <name>.yaml 1

절차

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

   SCOPE=$(oc -n openshift-ingress-operator get ingresscontroller <name> -o=jsonpath="{.status.endpointPublishingStrategy.loadBalancer.scope}")
   
   oc -n openshift-ingress-operator patch ingresscontrollers/<name> --type=merge --patch='{"spec":{"endpointPublishingStrategy":{"type":"LoadBalancerService","loadBalancer":{"dnsManagementPolicy":"Unmanaged", "scope":"${SCOPE}"}}}}'

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

프로세스

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를 지정합니다.

   • 하드웨어 MTU를 PXE를 사용하여 커널 명령줄로 지정하면 그에 따라 해당 구성을 업데이트합니다.

   • 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. < interface>-mtu.conf 파일에 다음 NetworkManager 구성을 만듭니다.

        NetworkManager 연결 구성 예

        [connection-<interface>-mtu]
        match-device=interface-name:<interface>
        ethernet.mtu=<mtu>

        다음과 같습니다.

        <mtu>

        새 하드웨어 MTU 값을 지정합니다.

        <interface>

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

     3. 두 개의 MachineConfig 오브젝트를 만듭니다. 하나는 컨트롤 플레인 노드용이고 다른 하나는 클러스터의 작업자 노드에 사용됩니다.

        1. control-plane-interface.bu 파일에 다음 Butane 구성을 생성합니다.

           variant: openshift
           version: 4.13.0
           metadata:
             name: 01-control-plane-interface
             labels:
               machineconfiguration.openshift.io/role: master
           storage:
             files:
               - path: /etc/NetworkManager/conf.d/99-<interface>-mtu.conf 1
                 contents:
                   local: <interface>-mtu.conf 2
                 mode: 0600

           1 1

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

           2

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

        2. worker-interface.bu 파일에 다음 Butane 구성을 생성합니다.

           variant: openshift
           version: 4.13.0
           metadata:
             name: 01-worker-interface
             labels:
               machineconfiguration.openshift.io/role: worker
           storage:
             files:
               - path: /etc/NetworkManager/conf.d/99-<interface>-mtu.conf 1
                 contents:
                   local: <interface>-mtu.conf 2
                 mode: 0600

           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. 클러스터의 클러스터 네트워크 범위 및 호스트 접두사를 가져오려면 다음 명령을 입력합니다.

   $ oc get network.operator.openshift.io \
     -o jsonpath="{.items[0].spec.clusterNetwork}"

   출력 예

   [{"cidr":"10.217.0.0/22","hostPrefix":23}]

2. 클러스터 네트워크 IP 주소 범위를 확장하려면 다음 명령을 입력합니다. 이전 명령의 출력에서 반환된 CIDR IP 주소 범위 및 호스트 접두사를 사용합니다.

   $ oc patch Network.config.openshift.io cluster --type='merge' --patch \
     '{
       "spec":{
         "clusterNetwork": [ {"cidr":"<network>/<cidr>","hostPrefix":<prefix>} ],
         "networkType": "OVNKubernetes"
       }
     }'

   다음과 같습니다.

   <network>

   이전 단계에서 얻은 cidr 필드의 네트워크 부분을 지정합니다. 이 값은 변경할 수 없습니다.

   <cidr>

   네트워크 접두사 길이를 지정합니다. 예를 들면 14 입니다. 이 값을 이전 단계의 출력 값보다 작은 숫자로 변경하여 클러스터 네트워크 범위를 확장합니다.

   <prefix>

   클러스터의 현재 호스트 접두사를 지정합니다. 이 값은 이전 단계에서 얻은 hostPrefix 필드에 대해 동일해야 합니다.

   명령 예

   $ oc patch Network.config.openshift.io cluster --type='merge' --patch \
     '{
       "spec":{
         "clusterNetwork": [ {"cidr":"10.217.0.0/14","hostPrefix": 23} ],
         "networkType": "OVNKubernetes"
       }
     }'

   출력 예

   network.config.openshift.io/cluster patched

3. 구성이 활성 상태인지 확인하려면 다음 명령을 입력합니다. 이 변경 사항을 적용하는 데 최대 30분이 걸릴 수 있습니다.

   $ oc get network.operator.openshift.io \
     -o jsonpath="{.items[0].spec.clusterNetwork}"

   출력 예

   [{"cidr":"10.217.0.0/14","hostPrefix":23}]

프로세스

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

   RunAsUser 는 컨테이너가 실행되는 사용자 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. 다음 명령을 실행하여 포드에 로그인합니다.

   $ 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/ubi9/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/ubi9/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. Namespace CR을 생성합니다.

      $ oc create -f ptp-namespace.yaml

2. PTP Operator에 대한 Operator group을 생성합니다.

   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. Subscription 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.13.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 로그를 확인합니다.