17.13. GitOps ZTP를 사용하여 단일 노드 OpenShift 클러스터 확장

GitOps ZTP를 사용하여 단일 노드 OpenShift 클러스터를 확장할 수 있습니다. 단일 노드 OpenShift 클러스터에 작업자 노드를 추가하면 원래 단일 노드 OpenShift 클러스터는 컨트롤 플레인 노드 역할을 유지합니다. 작업자 노드를 추가해도 기존 단일 노드 OpenShift 클러스터에 대한 다운타임이 필요하지 않습니다.

참고

단일 노드 OpenShift 클러스터에 추가할 수 있는 작업자 노드 수에 대한 제한은 없지만 추가 작업자 노드의 컨트롤 플레인 노드에서 예약된 CPU 할당을 다시 평가해야 합니다.

작업자 노드에 워크로드 파티셔닝이 필요한 경우 노드를 설치하기 전에 hub 클러스터에 관리형 클러스터 정책을 배포하고 수정해야 합니다. 이렇게 하면 GitOps ZTP 워크플로우에서 MachineConfig작업자 노드에 적용하기 전에 워크로드 파티셔닝 MachineConfig 오브젝트가 작업자 머신 구성 풀과 연결되고 작업자 머신 구성 풀과 연결됩니다.

먼저 정책을 수정한 다음 작업자 노드를 설치하는 것이 좋습니다. 작업자 노드를 설치한 후 워크로드 파티션 매니페스트를 생성하는 경우 노드를 수동으로 드레이닝하고 데몬 세트에서 관리하는 모든 Pod를 삭제해야 합니다. 관리 데몬 세트에서 새 Pod를 생성하면 새 Pod에 워크로드 파티셔닝 프로세스가 수행됩니다.

중요

GitOps ZTP를 사용하여 단일 노드 OpenShift 클러스터에 작업자 노드를 추가하는 것은 기술 프리뷰 기능입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

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

추가 리소스

17.13.1. 작업자 노드에 프로필 적용

DU 프로필을 사용하여 추가 작업자 노드를 구성할 수 있습니다.

ZTP GitOps 공통, 그룹 및 사이트별 PolicyGenTemplate 리소스를 사용하여 작업자 노드 클러스터에 RAN 분산 장치(DU) 프로필을 적용할 수 있습니다. ArgoCD 정책 애플리케이션에 연결된 GitOps ZTP 파이프라인에는 ztp-site-generate 컨테이너를 추출할 때 out/argocd/example/policygentemplates 폴더에 있는 다음 CR이 포함되어 있습니다.

  • common-ranGen.yaml
  • group-du-sno-ranGen.yaml
  • example-sno-site.yaml
  • ns.yaml
  • kustomization.yaml

작업자 노드에서 DU 프로필을 구성하는 것은 업그레이드로 간주됩니다. 업그레이드 흐름을 시작하려면 기존 정책을 업데이트하거나 추가 정책을 생성해야 합니다. 그런 다음 클러스터 그룹의 정책을 조정하려면 ClusterGroupUpgrade CR을 생성해야 합니다.

17.13.2. (선택 사항) PTP 및 SR-IOV 데몬 선택기 호환성 강화

DU 프로필이 GitOps ZTP 플러그인 버전 4.11 또는 이전 버전을 사용하여 배포된 경우 PTP 및 SR-IOV Operator가 마스터 로 레이블이 지정된 노드에만 데몬을 배치하도록 구성할 수 있습니다. 이 구성으로 PTP 및 SR-IOV 데몬이 작업자 노드에서 작동하지 않습니다. PTP 및 SR-IOV 데몬 노드 선택기가 시스템에 잘못 구성된 경우 작업자 DU 프로필 구성을 진행하기 전에 데몬을 변경해야 합니다.

절차

  1. 설명된 클러스터 중 하나에서 PTP Operator의 데몬 노드 선택기 설정을 확인합니다.

    $ oc get ptpoperatorconfig/default -n openshift-ptp -ojsonpath='{.spec}' | jq

    PTP Operator 출력 예

    {"daemonNodeSelector":{"node-role.kubernetes.io/master":""}} 1

    1
    노드 선택기가 master 로 설정된 경우, 스포크는 변경이 필요한 ZTP 플러그인 버전으로 배포되었습니다.
  2. 설명된 클러스터 중 하나에서 SR-IOV Operator의 데몬 노드 선택기 설정을 확인합니다.

    $  oc get sriovoperatorconfig/default -n \
    openshift-sriov-network-operator -ojsonpath='{.spec}' | jq

    SR-IOV Operator의 출력 예

    {"configDaemonNodeSelector":{"node-role.kubernetes.io/worker":""},"disableDrain":false,"enableInjector":true,"enableOperatorWebhook":true} 1

    1
    노드 선택기가 master 로 설정된 경우, 스포크는 변경이 필요한 ZTP 플러그인 버전으로 배포되었습니다.
  3. 그룹 정책에서 다음 complianceTypespec 항목을 추가합니다.

    spec:
        - fileName: PtpOperatorConfig.yaml
          policyName: "config-policy"
          complianceType: mustonlyhave
          spec:
            daemonNodeSelector:
              node-role.kubernetes.io/worker: ""
        - fileName: SriovOperatorConfig.yaml
          policyName: "config-policy"
          complianceType: mustonlyhave
          spec:
            configDaemonNodeSelector:
              node-role.kubernetes.io/worker: ""
    중요

    daemonNodeSelector 필드를 변경하면 임시 PTP 동기화 손실 및 SR-IOV 연결이 끊어집니다.

  4. Git의 변경 사항을 커밋한 다음 GitOps ZTP ArgoCD 애플리케이션에서 모니터링하는 Git 리포지토리로 내보냅니다.

17.13.3. PTP 및 SR-IOV 노드 선택기 호환성

PTP 구성 리소스 및 SR-IOV 네트워크 노드 정책은 node-role.kubernetes.io/master: "" 를 노드 선택기로 사용합니다. 추가 작업자 노드에 컨트롤 플레인 노드와 동일한 NIC 구성이 있는 경우 컨트롤 플레인 노드를 구성하는 데 사용되는 정책을 작업자 노드에 재사용할 수 있습니다. 그러나 "node-role.kubernetes.io/worker" 레이블과 같이 노드 유형을 둘 다 선택하도록 노드 선택기를 변경해야 합니다.

17.13.4. PolicyGenTemplate CR을 사용하여 작업자 노드에 작업자 노드 정책 적용

작업자 노드에 대한 정책을 생성할 수 있습니다.

절차

  1. 다음 정책 템플릿을 생성합니다.

    apiVersion: ran.openshift.io/v1
    kind: PolicyGenTemplate
    metadata:
      name: "example-sno-workers"
      namespace: "example-sno"
    spec:
      bindingRules:
        sites: "example-sno" 1
      mcp: "worker" 2
      sourceFiles:
        - fileName: MachineConfigGeneric.yaml 3
          policyName: "config-policy"
          metadata:
            labels:
              machineconfiguration.openshift.io/role: worker
            name: enable-workload-partitioning
          spec:
            config:
              storage:
                files:
                - contents:
                    source: data:text/plain;charset=utf-8;base64,W2NyaW8ucnVudGltZS53b3JrbG9hZHMubWFuYWdlbWVudF0KYWN0aXZhdGlvbl9hbm5vdGF0aW9uID0gInRhcmdldC53b3JrbG9hZC5vcGVuc2hpZnQuaW8vbWFuYWdlbWVudCIKYW5ub3RhdGlvbl9wcmVmaXggPSAicmVzb3VyY2VzLndvcmtsb2FkLm9wZW5zaGlmdC5pbyIKcmVzb3VyY2VzID0geyAiY3B1c2hhcmVzIiA9IDAsICJjcHVzZXQiID0gIjAtMyIgfQo=
                  mode: 420
                  overwrite: true
                  path: /etc/crio/crio.conf.d/01-workload-partitioning
                  user:
                    name: root
                - contents:
                    source: data:text/plain;charset=utf-8;base64,ewogICJtYW5hZ2VtZW50IjogewogICAgImNwdXNldCI6ICIwLTMiCiAgfQp9Cg==
                  mode: 420
                  overwrite: true
                  path: /etc/kubernetes/openshift-workload-pinning
                  user:
                    name: root
        - fileName: PerformanceProfile.yaml
          policyName: "config-policy"
          metadata:
            name: openshift-worker-node-performance-profile
          spec:
            cpu: 4
              isolated: "4-47"
              reserved: "0-3"
            hugepages:
              defaultHugepagesSize: 1G
              pages:
                - size: 1G
                  count: 32
            realTimeKernel:
              enabled: true
        - fileName: TunedPerformancePatch.yaml
          policyName: "config-policy"
          metadata:
            name: performance-patch-worker
          spec:
            profile:
              - name: performance-patch-worker
                data: |
                  [main]
                  summary=Configuration changes profile inherited from performance created tuned
                  include=openshift-node-performance-openshift-worker-node-performance-profile
                  [bootloader]
                  cmdline_crash=nohz_full=4-47 5
                  [sysctl]
                  kernel.timer_migration=1
                  [scheduler]
                  group.ice-ptp=0:f:10:*:ice-ptp.*
                  [service]
                  service.stalld=start,enable
                  service.chronyd=stop,disable
            recommend:
            - profile: performance-patch-worker
    1
    정책은 이 라벨이 있는 모든 클러스터에 적용됩니다.
    2
    MCP 필드는 worker 로 설정해야 합니다.
    3
    이 일반 MachineConfig CR은 작업자 노드에서 워크로드 파티셔닝을 구성하는 데 사용됩니다.
    4
    각 특정 하드웨어 플랫폼에 대해 cpu.isolatedcpu.reserved 필드를 구성해야 합니다.
    5
    cmdline_crash CPU 세트는 PerformanceProfile 섹션의 cpu.isolated 세트와 일치해야 합니다.

    일반 MachineConfig CR은 작업자 노드에서 워크로드 파티셔닝을 구성하는 데 사용됩니다. criokubelet 구성 파일의 콘텐츠를 생성할 수 있습니다.

  2. ArgoCD 정책 애플리케이션에서 모니터링하는 Git 리포지토리에 생성된 정책 템플릿을 추가합니다.
  3. kustomization.yaml 파일에 정책을 추가합니다.
  4. Git의 변경 사항을 커밋한 다음 GitOps ZTP ArgoCD 애플리케이션에서 모니터링하는 Git 리포지토리로 내보냅니다.
  5. 새로운 정책을 스포크 클러스터에 수정하려면 TALM 사용자 정의 리소스를 생성합니다.

    $ cat <<EOF | oc apply -f -
    apiVersion: ran.openshift.io/v1alpha1
    kind: ClusterGroupUpgrade
    metadata:
      name: example-sno-worker-policies
      namespace: default
    spec:
      backup: false
      clusters:
      - example-sno
      enable: true
      managedPolicies:
      - group-du-sno-config-policy
      - example-sno-workers-config-policy
      - example-sno-config-policy
      preCaching: false
      remediationStrategy:
        maxConcurrency: 1
    EOF

17.13.5. GitOps ZTP를 사용하여 단일 노드 OpenShift 클러스터에 작업자 노드 추가

기존 단일 노드 OpenShift 클러스터에 하나 이상의 작업자 노드를 추가하여 클러스터에서 사용 가능한 CPU 리소스를 늘릴 수 있습니다.

사전 요구 사항

  • OpenShift Container Platform 4.11 이상 베어 메탈 허브 클러스터에서 RHACM 2.6 이상을 설치하고 구성
  • 허브 클러스터에 Topology Aware Lifecycle Manager 설치
  • hub 클러스터에 Red Hat OpenShift GitOps 설치
  • GitOps ZTP ztp-site-generate 컨테이너 이미지 버전 4.12 이상을 사용합니다.
  • GitOps ZTP를 사용하여 관리형 단일 노드 OpenShift 클러스터 배포
  • RHACM 문서에 설명된 대로 중앙 인프라 관리 구성
  • 내부 API 엔드포인트 api-int.<cluster_name>.<base_domain>을 확인하도록 클러스터에 DNS 서비스를 구성

절차

  1. example-sno.yaml site Config 매니페스트를 사용하여 클러스터를 배포한 경우 새 작업자 노드를 spec.clusters['example-sno'].nodes 목록에 추가합니다.

    nodes:
    - hostName: "example-node2.example.com"
      role: "worker"
      bmcAddress: "idrac-virtualmedia+https://[1111:2222:3333:4444::bbbb:1]/redfish/v1/Systems/System.Embedded.1"
      bmcCredentialsName:
        name: "example-node2-bmh-secret"
      bootMACAddress: "AA:BB:CC:DD:EE:11"
      bootMode: "UEFI"
      nodeNetwork:
        interfaces:
          - name: eno1
            macAddress: "AA:BB:CC:DD:EE:11"
        config:
          interfaces:
            - name: eno1
              type: ethernet
              state: up
              macAddress: "AA:BB:CC:DD:EE:11"
              ipv4:
                enabled: false
              ipv6:
                enabled: true
                address:
                - ip: 1111:2222:3333:4444::1
                  prefix-length: 64
          dns-resolver:
            config:
              search:
              - example.com
              server:
              - 1111:2222:3333:4444::2
          routes:
            config:
            - destination: ::/0
              next-hop-interface: eno1
              next-hop-address: 1111:2222:3333:4444::1
              table-id: 254
  2. site Config 파일의 spec.nodes 섹션에 있는 bmcCredentialsName 필드에서 참조하는 대로 새 호스트의 BMC 인증 시크릿을 생성합니다.

    apiVersion: v1
    data:
      password: "password"
      username: "username"
    kind: Secret
    metadata:
      name: "example-node2-bmh-secret"
      namespace: example-sno
    type: Opaque
  3. Git의 변경 사항을 커밋한 다음 GitOps ZTP ArgoCD 애플리케이션에서 모니터링하는 Git 리포지토리로 내보냅니다.

    ArgoCD 클러스터 애플리케이션이 동기화되면 ZTP 플러그인에서 생성된 hub 클러스터에 두 개의 새 매니페스트가 표시됩니다.

    • BareMetalHost
    • NMStateConfig

      중요

      worker 노드에 대해 cpuset 필드를 구성해서는 안 됩니다. 노드 설치가 완료된 후 작업자 노드의 워크로드 파티션은 관리 정책을 통해 추가됩니다.

검증

여러 가지 방법으로 설치 프로세스를 모니터링할 수 있습니다.

  • 다음 명령을 실행하여 사전 프로비저닝된 이미지가 생성되었는지 확인합니다.

    $ oc get ppimg -n example-sno

    출력 예

    NAMESPACE       NAME            READY   REASON
    example-sno     example-sno     True    ImageCreated
    example-sno     example-node2   True    ImageCreated

  • 베어 메탈 호스트의 상태를 확인합니다.

    $ oc get bmh -n example-sno

    출력 예

    NAME            STATE          CONSUMER   ONLINE   ERROR   AGE
    example-sno     provisioned               true             69m
    example-node2   provisioning              true             4m50s 1

    1
    provisioning 상태는 설치 미디어에서 부팅 중인 노드가 진행 중임을 나타냅니다.
  • 설치 프로세스를 지속적으로 모니터링합니다.

    1. 다음 명령을 실행하여 에이전트 설치 프로세스를 확인합니다.

      $ oc get agent -n example-sno --watch

      출력 예

      NAME                                   CLUSTER   APPROVED   ROLE     STAGE
      671bc05d-5358-8940-ec12-d9ad22804faa   example-sno   true       master   Done
      [...]
      14fd821b-a35d-9cba-7978-00ddf535ff37   example-sno   true       worker   Starting installation
      14fd821b-a35d-9cba-7978-00ddf535ff37   example-sno   true       worker   Installing
      14fd821b-a35d-9cba-7978-00ddf535ff37   example-sno   true       worker   Writing image to disk
      [...]
      14fd821b-a35d-9cba-7978-00ddf535ff37   example-sno   true       worker   Waiting for control plane
      [...]
      14fd821b-a35d-9cba-7978-00ddf535ff37   example-sno   true       worker   Rebooting
      14fd821b-a35d-9cba-7978-00ddf535ff37   example-sno   true       worker   Done

    2. 작업자 노드 설치가 완료되면 작업자 노드 인증서가 자동으로 승인됩니다. 이 시점에서 작업자는 ManagedClusterInfo 상태에 나타납니다. 다음 명령을 실행하여 상태를 확인합니다.

      $ oc get managedclusterinfo/example-sno -n example-sno -o \
      jsonpath='{range .status.nodeList[*]}{.name}{"\t"}{.conditions}{"\t"}{.labels}{"\n"}{end}'

      출력 예

      example-sno	[{"status":"True","type":"Ready"}]	{"node-role.kubernetes.io/master":"","node-role.kubernetes.io/worker":""}
      example-node2	[{"status":"True","type":"Ready"}]	{"node-role.kubernetes.io/worker":""}