4.5. SiteConfig 및 GitOps ZTP를 사용하여 관리형 클러스터 배포


다음 절차에 따라 SiteConfig 사용자 정의 리소스(CR) 및 관련 파일을 만들고 GitOps Zero Touch Provisioning(ZTP) 클러스터 배포를 시작하세요.

중요

SiteConfig v1은 OpenShift Container Platform 버전 4.18부터 더 이상 사용되지 않습니다. 이제 ClusterInstance 사용자 정의 리소스를 사용하여 SiteConfig Operator를 통해 동등하고 향상된 기능을 사용할 수 있습니다. 자세한 내용은 SiteConfig CR에서 ClusterInstance API로 전환하는 절차를 참조하세요.

SiteConfig Operator에 대한 자세한 내용은 SiteConfig를 참조하십시오.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • cluster-admin 권한이 있는 사용자로 허브 클러스터에 로그인했습니다.
  • 필요한 설치 및 정책 CR을 생성하기 위해 허브 클러스터를 구성했습니다.
  • 사용자 정의 사이트 구성 데이터를 관리하는 Git 저장소를 만들었습니다. 저장소는 허브 클러스터에서 접근할 수 있어야 하며 ArgoCD 애플리케이션의 소스 저장소로 구성해야 합니다. 자세한 내용은 "GitOps ZTP 사이트 구성 저장소 준비"를 참조하세요.

    참고

    소스 저장소를 생성할 때 ztp-site-generate 컨테이너에서 추출한 argocd/deployment/argocd-openshift-gitops-patch.json 패치 파일로 ArgoCD 애플리케이션에 패치를 적용해야 합니다. "ArgoCD를 사용하여 허브 클러스터 구성"을 참조하세요.

  • 관리형 클러스터를 프로비저닝하려면 각 베어 메탈 호스트에 대해 다음이 필요합니다.

    네트워크 연결
    네트워크에 DNS가 필요합니다. 관리되는 클러스터 호스트는 허브 클러스터에서 접근할 수 있어야 합니다. 허브 클러스터와 관리되는 클러스터 호스트 사이에 3계층 연결이 있는지 확인하세요.
    베이스보드 관리 컨트롤러(BMC) 세부 정보
    GitOps ZTP는 클러스터 설치 중에 BMC 사용자 이름과 비밀번호 세부 정보를 사용하여 BMC에 연결합니다. GitOps ZTP 플러그인은 사이트 Git 리포지토리의 SiteConfig CR을 기반으로 허브 클러스터의 ManagedCluster CR을 관리합니다. 각 호스트에 대해 개별 BMCSecret CR을 수동으로 생성합니다.

    프로세스

    1. 허브 클러스터에서 필요한 관리형 클러스터 비밀을 만듭니다. 이러한 리소스는 클러스터 이름과 일치하는 이름을 가진 네임스페이스에 있어야 합니다. 예를 들어, out/argocd/example/siteconfig/example-sno.yaml 에서 클러스터 이름과 네임스페이스는 example-sno 입니다.

      1. 다음 명령을 실행하여 클러스터 네임스페이스를 내보냅니다.

        $ export CLUSTERNS=example-sno
        Copy to Clipboard Toggle word wrap
      2. 네임스페이스를 생성합니다.

        $ oc create namespace $CLUSTERNS
        Copy to Clipboard Toggle word wrap
    2. 관리되는 클러스터에 대한 풀 시크릿과 BMC 시크릿 CR을 생성합니다. 풀 시크릿에는 OpenShift Container Platform과 모든 필수 운영자를 설치하는 데 필요한 모든 자격 증명이 포함되어야 합니다. 자세한 내용은 "관리형 베어 메탈 호스트 비밀 만들기"를 참조하세요.

      참고

      비밀은 SiteConfig 사용자 정의 리소스(CR)에서 이름으로 참조됩니다. 네임스페이스는 SiteConfig 네임스페이스와 일치해야 합니다.

    3. Git 저장소의 로컬 복제본에서 클러스터에 대한 SiteConfig CR을 만듭니다.

      1. out/argocd/example/siteconfig/ 폴더에서 CR에 적합한 예를 선택하세요. 폴더에는 단일 노드, 3-노드 및 표준 클러스터에 대한 예제 파일이 포함되어 있습니다.

        • example-sno.yaml
        • example-3node.yaml
        • example-standard.yaml
      2. 예제 파일에서 클러스터 및 호스트 세부 정보를 변경하여 원하는 클러스터 유형에 맞게 만듭니다. 예를 들면 다음과 같습니다.

        단일 노드 OpenShift SiteConfig CR 예제

        # example-node1-bmh-secret & assisted-deployment-pull-secret need to be created under same namespace example-sno
        ---
        apiVersion: ran.openshift.io/v1
        kind: SiteConfig
        metadata:
          name: "example-sno"
          namespace: "example-sno"
        spec:
          baseDomain: "example.com"
          pullSecretRef:
            name: "assisted-deployment-pull-secret"
          clusterImageSetNameRef: "openshift-4.18"
          sshPublicKey: "ssh-rsa AAAA..."
          clusters:
            - clusterName: "example-sno"
              networkType: "OVNKubernetes"
              # installConfigOverrides is a generic way of passing install-config
              # parameters through the siteConfig.  The 'capabilities' field configures
              # the composable openshift feature.  In this 'capabilities' setting, we
              # remove all the optional set of components.
              # Notes:
              # - OperatorLifecycleManager is needed for 4.15 and later
              # - NodeTuning is needed for 4.13 and later, not for 4.12 and earlier
              # - Ingress is needed for 4.16 and later
              installConfigOverrides: |
                {
                  "capabilities": {
                    "baselineCapabilitySet": "None",
                    "additionalEnabledCapabilities": [
                      "NodeTuning",
                      "OperatorLifecycleManager",
                      "Ingress"
                    ]
                  }
                }
              # It is strongly recommended to include crun manifests as part of the additional install-time manifests for 4.13+.
              # The crun manifests can be obtained from source-crs/optional-extra-manifest/ and added to the git repo ie.sno-extra-manifest.
              # extraManifestPath: sno-extra-manifest
              clusterLabels:
                # These example cluster labels correspond to the bindingRules in the PolicyGenTemplate examples
                du-profile: "latest"
                # These example cluster labels correspond to the bindingRules in the PolicyGenTemplate examples in ../policygentemplates:
                # ../acmpolicygenerator/common-ranGen.yaml will apply to all clusters with 'common: true'
                common: true
                # ../policygentemplates/group-du-sno-ranGen.yaml will apply to all clusters with 'group-du-sno: ""'
                group-du-sno: ""
                # ../policygentemplates/example-sno-site.yaml will apply to all clusters with 'sites: "example-sno"'
                # Normally this should match or contain the cluster name so it only applies to a single cluster
                sites: "example-sno"
              clusterNetwork:
                - cidr: 1001:1::/48
                  hostPrefix: 64
              machineNetwork:
                - cidr: 1111:2222:3333:4444::/64
              serviceNetwork:
                - 1001:2::/112
              additionalNTPSources:
                - 1111:2222:3333:4444::2
              # Initiates the cluster for workload partitioning. Setting specific reserved/isolated CPUSets is done via PolicyTemplate
              # please see Workload Partitioning Feature for a complete guide.
              cpuPartitioningMode: AllNodes
              # Optionally; This can be used to override the KlusterletAddonConfig that is created for this cluster:
              #crTemplates:
              #  KlusterletAddonConfig: "KlusterletAddonConfigOverride.yaml"
              nodes:
                - hostName: "example-node1.example.com"
                  role: "master"
                  # Optionally; This can be used to configure desired BIOS setting on a host:
                  #biosConfigRef:
                  #  filePath: "example-hw.profile"
                  bmcAddress: "idrac-virtualmedia+https://[1111:2222:3333:4444::bbbb:1]/redfish/v1/Systems/System.Embedded.1"
                  bmcCredentialsName:
                    name: "example-node1-bmh-secret"
                  bootMACAddress: "AA:BB:CC:DD:EE:11"
                  # Use UEFISecureBoot to enable secure boot.
                  bootMode: "UEFISecureBoot"
                  rootDeviceHints:
                    deviceName: "/dev/disk/by-path/pci-0000:01:00.0-scsi-0:2:0:0"
                  #crTemplates:
                  #  BareMetalHost: "bmhOverride.yaml"
                  # disk partition at `/var/lib/containers` with ignitionConfigOverride. Some values must be updated. See DiskPartitionContainer.md for more details
                  ignitionConfigOverride: |
                    {
                      "ignition": {
                        "version": "3.2.0"
                      },
                      "storage": {
                        "disks": [
                          {
                            "device": "/dev/disk/by-id/wwn-0x6b07b250ebb9d0002a33509f24af1f62",
                            "partitions": [
                              {
                                "label": "var-lib-containers",
                                "sizeMiB": 0,
                                "startMiB": 250000
                              }
                            ],
                            "wipeTable": false
                          }
                        ],
                        "filesystems": [
                          {
                            "device": "/dev/disk/by-partlabel/var-lib-containers",
                            "format": "xfs",
                            "mountOptions": [
                              "defaults",
                              "prjquota"
                            ],
                            "path": "/var/lib/containers",
                            "wipeFilesystem": true
                          }
                        ]
                      },
                      "systemd": {
                        "units": [
                          {
                            "contents": "# Generated by Butane\n[Unit]\nRequires=systemd-fsck@dev-disk-by\\x2dpartlabel-var\\x2dlib\\x2dcontainers.service\nAfter=systemd-fsck@dev-disk-by\\x2dpartlabel-var\\x2dlib\\x2dcontainers.service\n\n[Mount]\nWhere=/var/lib/containers\nWhat=/dev/disk/by-partlabel/var-lib-containers\nType=xfs\nOptions=defaults,prjquota\n\n[Install]\nRequiredBy=local-fs.target",
                            "enabled": true,
                            "name": "var-lib-containers.mount"
                          }
                        ]
                      }
                    }
                  nodeNetwork:
                    interfaces:
                      - name: eno1
                        macAddress: "AA:BB:CC:DD:EE:11"
                    config:
                      interfaces:
                        - name: eno1
                          type: ethernet
                          state: up
                          ipv4:
                            enabled: false
                          ipv6:
                            enabled: true
                            address:
                              # For SNO sites with static IP addresses, the node-specific,
                              # API and Ingress IPs should all be the same and configured on
                              # the interface
                              - ip: 1111:2222:3333:4444::aaaa: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
        Copy to Clipboard Toggle word wrap

        참고

        BMC 주소 지정에 대한 자세한 내용은 "추가 자료" 섹션을 참조하세요. 이 예제에서는 가독성을 높이기 위해 installConfigOverridesignitionConfigOverride 필드가 확장되었습니다.

        참고

        노드의 기본 BareMetalHost CR을 재정의하려면 SiteConfig CR의 노드 수준 crTemplates 필드에서 재정의 CR을 참조할 수 있습니다. 오버라이드 BareMetalHost CR에서 argocd.argoproj.io/sync-wave: "3" 주석을 설정했는지 확인하세요.

      3. out/argocd/extra-manifest 에서 기본 extra-manifest MachineConfig CR 세트를 검사할 수 있습니다. 설치 시 자동으로 클러스터에 적용됩니다.
      4. 선택 사항: 프로비저닝된 클러스터에 추가 설치 시간 매니페스트를 프로비저닝하려면 Git 저장소에 디렉토리(예: sno-extra-manifest/ )를 만들고 이 디렉토리에 사용자 지정 매니페스트 CR을 추가합니다. SiteConfig.yamlextraManifestPath 필드에서 이 디렉토리를 참조하는 경우, 이 참조 디렉토리의 모든 CR은 기본 추가 매니페스트 세트에 추가됩니다.

        crun OCI 컨테이너 런타임 활성화

        최적의 클러스터 성능을 위해서는 단일 노드 OpenShift에서 마스터 및 작업자 노드에 대해 crun, 추가 작업자 노드가 있는 단일 노드 OpenShift, 3-노드 OpenShift 및 표준 클러스터를 활성화합니다.

        클러스터를 재부팅하지 않아도 되도록 ContainerRuntimeConfig CR에서 crun을 추가 Day 0 설치 시 매니페스트로 활성화합니다.

        enable-crun-master.yamlenable-crun-worker.yaml CR 파일은 ztp-site-generate 컨테이너에서 추출할 수 있는 out/source-crs/optional-extra-manifest/ 폴더에 있습니다. 자세한 내용은 "GitOps ZTP 파이프라인에서 추가 설치 매니페스트 사용자 지정"을 참조하세요.

    4. out/argocd/example/siteconfig/kustomization.yaml에 표시된 예와 유사하게 generators 섹션의 kustomization.yaml 파일에 SiteConfig CR을 추가합니다.
    5. SiteConfig CR과 관련 kustomization.yaml 변경 사항을 Git 저장소에 커밋하고 변경 사항을 푸시합니다.

      ArgoCD 파이프라인은 변경 사항을 감지하고 관리형 클러스터 배포를 시작합니다.

검증

  • 노드가 배포된 후 사용자 지정 역할과 레이블이 적용되었는지 확인하세요.

    $ oc describe node example-node.example.com
    Copy to Clipboard Toggle word wrap

출력 예

Name:   example-node.example.com
Roles:  control-plane,example-label,master,worker
Labels: beta.kubernetes.io/arch=amd64
        beta.kubernetes.io/os=linux
        custom-label/parameter1=true
        kubernetes.io/arch=amd64
        kubernetes.io/hostname=cnfdf03.telco5gran.eng.rdu2.redhat.com
        kubernetes.io/os=linux
        node-role.kubernetes.io/control-plane=
        node-role.kubernetes.io/example-label= 
1

        node-role.kubernetes.io/master=
        node-role.kubernetes.io/worker=
        node.openshift.io/os_id=rhcos
Copy to Clipboard Toggle word wrap

1
사용자 지정 라벨이 노드에 적용됩니다.

4.5.1. GitOps ZTP의 가속화된 프로비저닝

중요

GitOps ZTP의 가속화된 프로비저닝은 기술 미리 보기 기능에만 해당됩니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

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

단일 노드 OpenShift에 대한 GitOps ZTP의 가속 프로비저닝을 사용하면 클러스터 설치에 걸리는 시간을 줄일 수 있습니다. 가속화된 ZTP는 더 빠른 단계의 정책에서 파생된 2일차 매니페스트를 적용하여 설치 속도를 높입니다.

중요

GitOps ZTP의 가속 프로비저닝은 Assisted Installer를 사용하여 단일 노드 OpenShift를 설치하는 경우에만 지원됩니다. 그렇지 않으면 이 설치 방법은 실패합니다.

4.5.1.1. 가속 ZTP 활성화

다음 예와 같이 spec.clusters.clusterLabels.accelerated-ztp 레이블을 사용하여 가속화된 ZTP를 활성화할 수 있습니다.

가속 ZTP SiteConfig CR의 예입니다.

apiVersion: ran.openshift.io/v2
kind: SiteConfig
metadata:
  name: "example-sno"
  namespace: "example-sno"
spec:
  baseDomain: "example.com"
  pullSecretRef:
    name: "assisted-deployment-pull-secret"
  clusterImageSetNameRef: "openshift-4.19"
  sshPublicKey: "ssh-rsa AAAA..."
  clusters:
  # ...
    clusterLabels:
        common: true
        group-du-sno: ""
        sites : "example-sno"
        accelerated-ztp: full
Copy to Clipboard Toggle word wrap

accelerated-ztp:full을 사용하면 가속 프로세스를 완전히 자동화할 수 있습니다. GitOps ZTP는 가속화된 GitOps ZTP ConfigMap에 대한 참조로 AgentClusterInstall 리소스를 업데이트하고 TALM의 정책에서 추출한 리소스와 가속화된 ZTP 작업 매니페스트를 포함합니다.

accelerated-ztp: partial 을 사용하는 경우 GitOps ZTP는 가속화된 작업 매니페스트를 포함하지 않지만 다음 유형 의 클러스터 설치 중에 생성된 정책 파생 개체를 포함합니다.

  • PerformanceProfile.performance.openshift.io
  • Tuned.tuned.openshift.io
  • 네임스페이스
  • CatalogSource.operators.coreos.com
  • ContainerRuntimeConfig.machineconfiguration.openshift.io

이 부분적 가속은 Performance Profile , TunedContainerRuntimeConfig 종류의 리소스를 적용할 때 노드에서 수행하는 재부팅 횟수를 줄일 수 있습니다. TALM은 RHACM이 클러스터 가져오기를 완료한 후 표준 GitOps ZTP와 동일한 흐름에 따라 정책에서 파생된 Operator 구독을 설치합니다.

가속화된 ZTP의 이점은 배포 규모에 따라 증가합니다. accelerated-ztp: full을 사용하면 다수의 클러스터에서 더 많은 이점을 얻을 수 있습니다. 클러스터 수가 적으면 설치 시간 단축 효과가 크지 않습니다. 완전히 가속화된 ZTP는 스포크에 네임스페이스와 완료된 작업을 남겨두므로 이를 수동으로 제거해야 합니다.

가속화된 ztp:부분을 사용하는 한 가지 이점은 기본 구현에 문제가 발생하거나 사용자 지정 기능이 필요한 경우 온스포크 작업의 기능을 재정의할 수 있다는 것입니다.

4.5.1.2. 가속화된 ZTP 프로세스

가속화된 ZTP는 추가 ConfigMap을 사용하여 스포크 클러스터의 정책에서 파생된 리소스를 생성합니다. 표준 ConfigMap 에는 GitOps ZTP 워크플로가 클러스터 설치를 사용자 지정하는 데 사용하는 매니페스트가 포함되어 있습니다.

TALM은 accelerated-ztp 레이블이 설정되었음을 감지한 다음 두 번째 ConfigMap을 생성합니다. 가속화된 ZTP의 일부로 SiteConfig 생성기는 <spoke-cluster-name>-aztp 명명 규칙을 사용하여 두 번째 ConfigMap 에 대한 참조를 추가합니다.

TALM이 두 번째 ConfigMap을 생성한 후 관리되는 클러스터에 바인딩된 모든 정책을 찾아 GitOps ZTP 프로필 정보를 추출합니다. TALM은 GitOps ZTP 프로필 정보를 <spoke-cluster-name>-aztp ConfigMap 사용자 정의 리소스(CR)에 추가하고 해당 CR을 허브 클러스터 API에 적용합니다.

GitOps ZTP 및 Red Hat Advanced Cluster Management(RHACM)를 사용하여 설치한 관리형 단일 노드 OpenShift 클러스터에서 IPsec 암호화를 활성화할 수 있습니다. 관리되는 클러스터와 관리되는 클러스터 외부의 IPsec 엔드포인트 간의 트래픽을 암호화할 수 있습니다. OVN-Kubernetes 클러스터 네트워크의 노드 간 모든 네트워크 트래픽은 전송 모드에서 IPsec으로 암호화됩니다.

중요

다음 절차에 따라 추가 작업자 노드가 있는 단일 노드 OpenShift 클러스터에 대한 IPsec 암호화를 구성할 수도 있습니다. 단일 노드 OpenShift 클러스터와 추가 작업자 노드가 있는 단일 노드 OpenShift 클러스터의 경우 리소스 가용성이 낮으므로 IPsec 암호화를 구성하려면 MachineConfig 사용자 정의 리소스(CR)를 사용하는 것이 좋습니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • cluster-admin 권한이 있는 사용자로 허브 클러스터에 로그인했습니다.
  • 관리되는 클러스터에 필요한 설치 및 정책 사용자 정의 리소스(CR)를 생성하기 위해 RHACM과 허브 클러스터를 구성했습니다.
  • 사용자 정의 사이트 구성 데이터를 관리하는 Git 저장소를 만들었습니다. 저장소는 허브 클러스터에서 접근할 수 있어야 하며 Argo CD 애플리케이션의 소스 저장소로 정의되어야 합니다.
  • 부탄 유틸리티 버전 0.20.0 이상을 설치했습니다.
  • IPsec 엔드포인트에 대한 PKCS#12 인증서와 PEM 형식의 CA 인증서가 있습니다.

프로세스

  1. ztp-site-generate 컨테이너 소스의 최신 버전을 추출하여 사용자 정의 사이트 구성 데이터를 관리하는 저장소와 병합합니다.
  2. 클러스터에서 IPsec을 구성하는 데 필요한 값으로 optional-extra-manifest/ipsec/ipsec-endpoint-config.yaml을 구성합니다. 예를 들면 다음과 같습니다.

    interfaces:
    - name: hosta_conn
      type: ipsec
      libreswan:
        left: '%defaultroute'
        leftid: '%fromcert'
        leftmodecfgclient: false
        leftcert: left_server 
    1
    
        leftrsasigkey: '%cert'
        right: <external_host> 
    2
    
        rightid: '%fromcert'
        rightrsasigkey: '%cert'
        rightsubnet: <external_address> 
    3
    
        ikev2: insist 
    4
    
        type: tunnel
    Copy to Clipboard Toggle word wrap
    1
    이 필드의 값은 원격 시스템에서 사용되는 인증서의 이름과 일치해야 합니다.
    2
    <external_host>를 외부 호스트 IP 주소 또는 DNS 호스트 이름으로 바꾸세요.
    3
    <external_address>를 IPsec 터널의 반대쪽에 있는 외부 호스트의 IP 서브넷으로 바꿉니다.
    4
    IKEv2 VPN 암호화 프로토콜만 사용하십시오. 더 이상 사용되지 않는 IKEv1을 사용하지 마세요.
  3. 다음 인증서를 optional-extra-manifest/ipsec 폴더에 추가합니다.

    • left_server.p12 : IPsec 엔드포인트에 대한 인증서 번들
    • ca.pem : 인증서에 서명한 인증 기관

      각 호스트의 네트워크 보안 서비스(NSS) 데이터베이스에는 인증서 파일이 필요합니다. 이러한 파일은 이후 단계에서 부탄 구성의 일부로 가져옵니다.

  4. 사용자 정의 사이트 구성 데이터를 유지 관리하는 Git 저장소의 optional-extra-manifest/ipsec 폴더에서 셸 프롬프트를 엽니다.
  5. optional-extra-manifest/ipsec/build.sh 스크립트를 실행하여 필요한 Butane 및 MachineConfig CR 파일을 생성합니다.

    PKCS#12 인증서가 비밀번호로 보호되는 경우 -W 인수를 설정합니다.

    출력 예

    out
     └── argocd
          └── example
               └── optional-extra-manifest
                    └── ipsec
                         ├── 99-ipsec-master-endpoint-config.bu 
    1
    
                         ├── 99-ipsec-master-endpoint-config.yaml 
    2
    
                         ├── 99-ipsec-worker-endpoint-config.bu 
    3
    
                         ├── 99-ipsec-worker-endpoint-config.yaml 
    4
    
                         ├── build.sh
                         ├── ca.pem 
    5
    
                         ├── left_server.p12 
    6
    
                         ├── enable-ipsec.yaml
                         ├── ipsec-endpoint-config.yml
                         └── README.md
    Copy to Clipboard Toggle word wrap

    1 2 3 4
    ipsec/build.sh 스크립트는 Butane 및 엔드포인트 구성 CR을 생성합니다.
    5 6
    네트워크와 관련된 ca.pemleft_server.p12 인증서 파일을 제공합니다.
  6. 사용자 정의 사이트 구성 데이터를 관리하는 저장소에 custom-manifest/ 폴더를 만듭니다. enable-ipsec.yaml99-ipsec-* YAML 파일을 디렉토리에 추가합니다. 예를 들면 다음과 같습니다.

    siteconfig
      ├── site1-sno-du.yaml
      ├── extra-manifest/
      └── custom-manifest
            ├── enable-ipsec.yaml
            ├── 99-ipsec-worker-endpoint-config.yaml
            └── 99-ipsec-master-endpoint-config.yaml
    Copy to Clipboard Toggle word wrap
  7. SiteConfig CR에서 custom-manifest/ 디렉토리를 extraManifests.searchPaths 필드에 추가합니다. 예를 들면 다음과 같습니다.

    clusters:
    - clusterName: "site1-sno-du"
      networkType: "OVNKubernetes"
      extraManifests:
        searchPaths:
          - extra-manifest/
          - custom-manifest/
    Copy to Clipboard Toggle word wrap
  8. SiteConfig CR 변경 사항과 업데이트된 파일을 Git 저장소에 커밋하고 변경 사항을 푸시하여 관리되는 클러스터를 프로비저닝하고 IPsec 암호화를 구성합니다.

    Argo CD 파이프라인은 변경 사항을 감지하고 관리형 클러스터 배포를 시작합니다.

    클러스터 프로비저닝 중에 GitOps ZTP 파이프라인은 custom-manifest/ 디렉토리에 있는 CR을 extra-manifest/ 디렉토리에 저장된 기본 추가 매니페스트 세트에 추가합니다.

검증

IPsec 암호화를 확인하는 방법에 대한 자세한 내용은 "IPsec 암호화 확인"을 참조하세요.

GitOps ZTP 및 Red Hat Advanced Cluster Management(RHACM)를 사용하여 설치한 관리형 다중 노드 클러스터에서 IPsec 암호화를 활성화할 수 있습니다. 관리되는 클러스터와 관리되는 클러스터 외부의 IPsec 엔드포인트 간의 트래픽을 암호화할 수 있습니다. OVN-Kubernetes 클러스터 네트워크의 노드 간 모든 네트워크 트래픽은 전송 모드에서 IPsec으로 암호화됩니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • cluster-admin 권한이 있는 사용자로 허브 클러스터에 로그인했습니다.
  • 관리되는 클러스터에 필요한 설치 및 정책 사용자 정의 리소스(CR)를 생성하기 위해 RHACM과 허브 클러스터를 구성했습니다.
  • 사용자 정의 사이트 구성 데이터를 관리하는 Git 저장소를 만들었습니다. 저장소는 허브 클러스터에서 접근할 수 있어야 하며 Argo CD 애플리케이션의 소스 저장소로 정의되어야 합니다.
  • 부탄 유틸리티 버전 0.20.0 이상을 설치했습니다.
  • IPsec 엔드포인트에 대한 PKCS#12 인증서와 PEM 형식의 CA 인증서가 있습니다.
  • NMState Operator를 설치했습니다.

프로세스

  1. ztp-site-generate 컨테이너 소스의 최신 버전을 추출하여 사용자 정의 사이트 구성 데이터를 관리하는 저장소와 병합합니다.
  2. 클러스터에서 IPsec을 구성하는 데 필요한 값으로 optional-extra-manifest/ipsec/ipsec-config-policy.yaml 파일을 구성합니다.

    IPsec 구성을 생성하기 위한 ConfigurationPolicy 개체

    apiVersion: policy.open-cluster-management.io/v1
    kind: ConfigurationPolicy
    metadata:
      name: policy-config
    spec:
      namespaceSelector:
        include: ["default"]
        exclude: []
        matchExpressions: []
        matchLabels: {}
      remediationAction: inform
      severity: low
      evaluationInterval:
        compliant:
        noncompliant:
      object-templates-raw: |
        {{- range (lookup "v1" "Node" "" "").items }}
        - complianceType: musthave
          objectDefinition:
            kind: NodeNetworkConfigurationPolicy
            apiVersion: nmstate.io/v1
            metadata:
              name: {{ .metadata.name }}-ipsec-policy
            spec:
              nodeSelector:
                kubernetes.io/hostname: {{ .metadata.name }}
              desiredState:
                interfaces:
                - name: hosta_conn
                  type: ipsec
                  libreswan:
                    left: '%defaultroute'
                    leftid: '%fromcert'
                    leftmodecfgclient: false
                    leftcert: left_server 
    1
    
                    leftrsasigkey: '%cert'
                    right: <external_host> 
    2
    
                    rightid: '%fromcert'
                    rightrsasigkey: '%cert'
                    rightsubnet: <external_address> 
    3
    
                    ikev2: insist 
    4
    
                    type: tunnel
    Copy to Clipboard Toggle word wrap

    1
    이 필드의 값은 원격 시스템에서 사용되는 인증서의 이름과 일치해야 합니다.
    2
    <external_host>를 외부 호스트 IP 주소 또는 DNS 호스트 이름으로 바꾸세요.
    3
    <external_address>를 IPsec 터널의 반대쪽에 있는 외부 호스트의 IP 서브넷으로 바꿉니다.
    4
    IKEv2 VPN 암호화 프로토콜만 사용하십시오. 더 이상 사용되지 않는 IKEv1을 사용하지 마세요.
  3. 다음 인증서를 optional-extra-manifest/ipsec 폴더에 추가합니다.

    • left_server.p12 : IPsec 엔드포인트에 대한 인증서 번들
    • ca.pem : 인증서에 서명한 인증 기관

      각 호스트의 네트워크 보안 서비스(NSS) 데이터베이스에는 인증서 파일이 필요합니다. 이러한 파일은 이후 단계에서 부탄 구성의 일부로 가져옵니다.

  4. 사용자 정의 사이트 구성 데이터를 유지 관리하는 Git 저장소의 optional-extra-manifest/ipsec 폴더에서 셸 프롬프트를 엽니다.
  5. 외부 인증서를 가져오기 위해 필요한 Butane 및 MachineConfig CR을 생성하려면 optional-extra-manifest/ipsec/import-certs.sh 스크립트를 실행하세요.

    PKCS#12 인증서가 비밀번호로 보호되는 경우 -W 인수를 설정합니다.

    출력 예

    out
     └── argocd
          └── example
               └── optional-extra-manifest
                    └── ipsec
                         ├── 99-ipsec-master-import-certs.bu 
    1
    
                         ├── 99-ipsec-master-import-certs.yaml 
    2
    
                         ├── 99-ipsec-worker-import-certs.bu 
    3
    
                         ├── 99-ipsec-worker-import-certs.yaml 
    4
    
                         ├── import-certs.sh
                         ├── ca.pem 
    5
    
                         ├── left_server.p12 
    6
    
                         ├── enable-ipsec.yaml
                         ├── ipsec-config-policy.yaml
                         └── README.md
    Copy to Clipboard Toggle word wrap

    1 2 3 4
    ipsec/import-certs.sh 스크립트는 Butane 및 엔드포인트 구성 CR을 생성합니다.
    5 6
    네트워크와 관련된 ca.pemleft_server.p12 인증서 파일을 추가합니다.
  6. 사용자 정의 사이트 구성 데이터를 관리하는 저장소에 custom-manifest/ 폴더를 만들고 enable-ipsec.yaml99-ipsec-* YAML 파일을 해당 디렉토리에 추가합니다.

    예시 siteconfig 디렉토리

    siteconfig
      ├── site1-mno-du.yaml
      ├── extra-manifest/
      └── custom-manifest
            ├── enable-ipsec.yaml
            ├── 99-ipsec-master-import-certs.yaml
            └── 99-ipsec-worker-import-certs.yaml
    Copy to Clipboard Toggle word wrap

  7. SiteConfig CR에서 다음 예와 같이 custom-manifest/ 디렉터리를 extraManifests.searchPaths 필드에 추가합니다.

    clusters:
    - clusterName: "site1-mno-du"
      networkType: "OVNKubernetes"
      extraManifests:
        searchPaths:
          - extra-manifest/
          - custom-manifest/
    Copy to Clipboard Toggle word wrap
  8. GitOps의 source-crs 디렉토리에 ipsec-config-policy.yaml 구성 정책 파일을 포함하고 PolicyGenerator CR 중 하나에서 해당 파일을 참조합니다.
  9. SiteConfig CR 변경 사항과 업데이트된 파일을 Git 저장소에 커밋하고 변경 사항을 푸시하여 관리되는 클러스터를 프로비저닝하고 IPsec 암호화를 구성합니다.

    Argo CD 파이프라인은 변경 사항을 감지하고 관리형 클러스터 배포를 시작합니다.

    클러스터 프로비저닝 중에 GitOps ZTP 파이프라인은 custom-manifest/ 디렉토리에 있는 CR을 extra-manifest/ 디렉토리에 저장된 기본 추가 매니페스트 세트에 추가합니다.

검증

IPsec 암호화를 확인하는 방법에 대한 자세한 내용은 "IPsec 암호화 확인"을 참조하세요.

4.5.4. IPsec 암호화 확인

관리되는 OpenShift Container Platform 클러스터에 IPsec 암호화가 성공적으로 적용되었는지 확인할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • cluster-admin 권한이 있는 사용자로 허브 클러스터에 로그인했습니다.
  • IPsec 암호화를 구성했습니다.

프로세스

  1. 다음 명령을 실행하여 관리되는 클러스터에 대한 디버그 포드를 시작합니다.

    $ oc debug node/<node_name>
    Copy to Clipboard Toggle word wrap
  2. 다음 명령을 실행하여 클러스터 노드에 IPsec 정책이 적용되었는지 확인하세요.

    sh-5.1# ip xfrm policy
    Copy to Clipboard Toggle word wrap

    출력 예

    src 172.16.123.0/24 dst 10.1.232.10/32
      dir out priority 1757377 ptype main
      tmpl src 10.1.28.190 dst 10.1.232.10
        proto esp reqid 16393 mode tunnel
    src 10.1.232.10/32 dst 172.16.123.0/24
      dir fwd priority 1757377 ptype main
      tmpl src 10.1.232.10 dst 10.1.28.190
        proto esp reqid 16393 mode tunnel
    src 10.1.232.10/32 dst 172.16.123.0/24
      dir in priority 1757377 ptype main
      tmpl src 10.1.232.10 dst 10.1.28.190
        proto esp reqid 16393 mode tunnel
    Copy to Clipboard Toggle word wrap

  3. 다음 명령을 실행하여 IPsec 터널이 작동 중이고 연결되었는지 확인하세요.

    sh-5.1# ip xfrm state
    Copy to Clipboard Toggle word wrap

    출력 예

    src 10.1.232.10 dst 10.1.28.190
      proto esp spi 0xa62a05aa reqid 16393 mode tunnel
      replay-window 0 flag af-unspec esn
      auth-trunc hmac(sha1) 0x8c59f680c8ea1e667b665d8424e2ab749cec12dc 96
      enc cbc(aes) 0x2818a489fe84929c8ab72907e9ce2f0eac6f16f2258bd22240f4087e0326badb
      anti-replay esn context:
       seq-hi 0x0, seq 0x0, oseq-hi 0x0, oseq 0x0
       replay_window 128, bitmap-length 4
       00000000 00000000 00000000 00000000
    src 10.1.28.190 dst 10.1.232.10
      proto esp spi 0x8e96e9f9 reqid 16393 mode tunnel
      replay-window 0 flag af-unspec esn
      auth-trunc hmac(sha1) 0xd960ddc0a6baaccb343396a51295e08cfd8aaddd 96
      enc cbc(aes) 0x0273c02e05b4216d5e652de3fc9b3528fea94648bc2b88fa01139fdf0beb27ab
      anti-replay esn context:
       seq-hi 0x0, seq 0x0, oseq-hi 0x0, oseq 0x0
       replay_window 128, bitmap-length 4
       00000000 00000000 00000000 00000000
    Copy to Clipboard Toggle word wrap

  4. 다음 명령을 실행하여 외부 호스트 서브넷의 알려진 IP에 ping을 보냅니다. 예를 들어, ipsec/ipsec-endpoint-config.yaml 파일에 설정한 rightsubnet 범위의 IP 주소에 ping을 보냅니다.

    sh-5.1# ping 172.16.110.8
    Copy to Clipboard Toggle word wrap

    출력 예

    PING 172.16.110.8 (172.16.110.8) 56(84) bytes of data.
    64 bytes from 172.16.110.8: icmp_seq=1 ttl=64 time=153 ms
    64 bytes from 172.16.110.8: icmp_seq=2 ttl=64 time=155 ms
    Copy to Clipboard Toggle word wrap

4.5.5. 단일 노드 OpenShift SiteConfig CR 설치 참조

Expand
표 4.1. 단일 노드 OpenShift 클러스터에 대한 SiteConfig CR 설치 옵션
SiteConfig CR 필드설명

spec.cpuPartitioningMode

cpuPartitioningMode 값을 AllNodes 로 설정하여 작업 분할을 구성합니다. 구성을 완료하려면 PerformanceProfile CR에서 격리 되고 예약된 CPU를 지정합니다.

metadata.name

nameassisted-deployment-pull-secret 으로 설정하고 SiteConfig CR과 동일한 네임스페이스에 assisted-deployment-pull-secret CR을 생성합니다.

spec.clusterImageSetNameRef

사이트의 모든 클러스터에 대해 허브 클러스터에서 사용 가능한 이미지 세트를 구성합니다. 허브 클러스터에서 지원되는 버전 목록을 보려면 oc get clusterimagesets 를 실행하세요.

installConfigOverrides

클러스터를 설치하기 전에 installConfigOverrides 필드를 설정하여 선택적 구성 요소를 활성화하거나 비활성화합니다.

중요

SiteConfig CR 예제에 지정된 대로 참조 구성을 사용합니다. 시스템에 추가 구성 요소를 다시 추가하려면 예약된 CPU 용량이 추가로 필요할 수 있습니다.

spec.clusters.clusterImageSetNameRef

개별 클러스터를 배포하는 데 사용되는 클러스터 이미지 세트를 지정합니다. 정의된 경우 사이트 수준에서 spec.clusterImageSetNameRef를 재정의합니다.

spec.clusters.clusterLabels

PolicyGenerator 또는 PolicyGentemplate CR에서 정의한 바인딩 규칙에 맞게 클러스터 레이블을 구성합니다. PolicyGenerator CR은 policyDefaults.placement.labelSelector 필드를 사용합니다. PolicyGentemplate CR은 spec.bindingRules 필드를 사용합니다.

예를 들어, acmpolicygenerator/acm-common-ranGen.yaml은 common: true가 설정된 모든 클러스터에 적용되고, acmpolicygenerator/acm-group-du-sno-ranGen.yaml은 group-du-sno: ""가 설정된 모든 클러스터에 적용됩니다.

spec.clusters.crTemplates.KlusterletAddonConfig

선택 사항: 클러스터에 대해 생성된 기본 `KlusterletAddonConfig`를 재정의하려면 KlusterletAddonConfig를 KlusterletAddonConfigOverride.yaml로 설정합니다.

spec.clusters.diskEncryption

이 필드를 구성하여 TPM(신뢰할 수 있는 플랫폼 모듈) 및 PCR(플랫폼 구성 레지스터) 보호를 통해 디스크 암호화를 활성화합니다. 자세한 내용은 "TPM 및 PCR 보호를 통한 디스크 암호화에 관하여"를 참조하세요.

참고

SiteConfig CR의 diskEncryption 필드를 사용하여 디스크 암호화를 구성하는 것은 OpenShift Container Platform 4.19의 기술 미리 보기 기능입니다.

spec.clusters.diskEncryption.type

디스크 암호화 유형을 tpm2 로 설정합니다.

spec.clusters.diskEncryption.tpm2

디스크 암호화를 위한 플랫폼 구성 레지스터(PCR) 보호를 구성합니다.

spec.clusters.diskEncryption.tpm2.pcrList

디스크 암호화에 사용할 플랫폼 구성 레지스터(PCR) 목록을 구성합니다. PCR 레지스터 1과 7을 사용해야 합니다.

spec.clusters.nodes.hostName

단일 노드 배포의 경우 단일 호스트를 정의합니다. 3-노드 배포의 경우 세 개의 호스트를 정의합니다. 표준 배포의 경우, role: master인 호스트 3개와 role: worker인 호스트 2개 이상을 정의합니다.

spec.clusters.nodes.nodeLabels

관리되는 클러스터의 노드에 대한 사용자 정의 역할을 지정합니다. 이러한 추가 역할은 OpenShift Container Platform 구성 요소에서는 사용되지 않고 사용자만 사용합니다. 사용자 정의 역할을 추가하면 해당 역할에 대한 특정 구성을 참조하는 사용자 정의 머신 구성 풀과 연결될 수 있습니다. 설치 중에 사용자 정의 레이블이나 역할을 추가하면 배포 프로세스가 더 효율적으로 진행되고 설치가 완료된 후 추가로 재부팅할 필요가 없습니다.

spec.clusters.nodes.automatedCleaningMode

선택 사항: 디스크를 완전히 지우지 않고 디스크 파티션 테이블만 제거하려면 주석 처리를 해제하고 값을 메타데이터 로 설정합니다. 기본값은 disabled 입니다.

spec.clusters.nodes.bmcAddress

호스트에 액세스하는 데 사용하는 BMC 주소입니다. 모든 클러스터 유형에 적용됩니다. GitOps ZTP는 Redfish 또는 IPMI 프로토콜을 사용하여 iPXE 및 가상 미디어 부팅을 지원합니다. iPXE 부팅을 사용하려면 RHACM 2.8 이상을 사용해야 합니다. BMC 주소 지정에 대한 자세한 내용은 "추가 자료" 섹션을 참조하세요.

spec.clusters.nodes.bmcAddress

호스트에 액세스하는 데 사용하는 BMC 주소입니다. 모든 클러스터 유형에 적용됩니다. GitOps ZTP는 Redfish 또는 IPMI 프로토콜을 사용하여 iPXE 및 가상 미디어 부팅을 지원합니다. iPXE 부팅을 사용하려면 RHACM 2.8 이상을 사용해야 합니다. BMC 주소 지정에 대한 자세한 내용은 "추가 자료" 섹션을 참조하세요.

참고

Far Edge Telco 사용 사례에서는 GitOps ZTP와 함께 사용할 수 있는 가상 미디어만 지원됩니다.

spec.clusters.nodes.bmcCredentialsName

호스트 BMC 자격 증명을 사용하여 별도로 생성한 bmh-secret CR을 구성합니다. bmh-secret CR을 생성할 때 호스트를 프로비저닝하는 SiteConfig CR과 동일한 네임스페이스를 사용하세요.

spec.clusters.nodes.bootMode

호스트의 부팅 모드를 UEFI 로 설정합니다. 기본값은 UEFI 입니다. UEFISecureBoot를 사용하여 호스트에서 보안 부팅을 활성화합니다.

spec.clusters.nodes.rootDeviceHints

배포할 장치를 지정합니다. 재부팅 후에도 안정적인 식별자를 사용하는 것이 좋습니다. 예를 들어, wwn: <disk_wwn> 또는 deviceName: /dev/disk/by-path/<device_path> . <by-path> 값이 선호됩니다. 안정적인 식별자에 대한 자세한 목록은 "루트 장치 힌트에 대하여" 섹션을 참조하세요.

spec.clusters.nodes.ignitionConfigOverride

선택 사항: 이 필드를 사용하여 영구 저장소에 대한 파티션을 할당합니다. 디스크 ID와 크기를 특정 하드웨어에 맞게 조정합니다.

spec.clusters.nodes.nodeNetwork

노드에 대한 네트워크 설정을 구성합니다.

spec.clusters.nodes.nodeNetwork.config.interfaces.ipv6

호스트의 IPv6 주소를 구성합니다. 고정 IP 주소를 사용하는 단일 노드 OpenShift 클러스터의 경우 노드별 API와 Ingress IP는 동일해야 합니다.

맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2025 Red Hat