4.5. SiteConfig 및 GitOps ZTP를 사용하여 관리형 클러스터 배포
다음 절차에 따라 SiteConfig
CR(사용자 정의 리소스) 및 관련 파일을 생성하고 ZTP( GitOps Zero Touch Provisioning) 클러스터 배포를 시작합니다.
사전 요구 사항
-
OpenShift CLI(
oc
)가 설치되어 있습니다. -
cluster-admin
권한이 있는 사용자로 hub 클러스터에 로그인했습니다. - 필요한 설치 및 정책 CR을 생성하도록 허브 클러스터를 구성했습니다.
사용자 지정 사이트 구성 데이터를 관리하는 Git 리포지토리를 생성하셨습니다. 리포지토리는 hub 클러스터에서 액세스할 수 있어야 하며 ArgoCD 애플리케이션의 소스 리포지토리로 구성해야 합니다. 자세한 내용은 " GitOps ZTP 사이트 구성 리포지토리 준비"를 참조하십시오.
참고소스 리포지토리를 생성할 때
ztp-site-generate
컨테이너에서 추출한argocd/deployment/argocd-openshift-gitops-patch.json
patch-file을 사용하여 ArgoCD 애플리케이션을 패치하는지 확인합니다. " ArgoCD를 사용하여 허브 클러스터 구성"을 참조하십시오.관리 클러스터 프로비저닝을 준비하려면 각 베어 메탈 호스트에 대해 다음이 필요합니다.
- 네트워크 연결
- 네트워크에는 DNS가 필요합니다. 허브 클러스터에서 관리 클러스터 호스트에 연결할 수 있어야 합니다. hub 클러스터와 관리 클러스터 호스트 간에 계층 3 연결이 있는지 확인합니다.
- BMC(Baseboard Management Controller) 세부 정보
-
GitOps ZTP는 BMC 사용자 이름과 암호 세부 정보를 사용하여 클러스터 설치 중에 BMC에 연결합니다. GitOps ZTP 플러그인은 사이트 Git 리포지토리의 site
Config
CR을 기반으로 Hub 클러스터에서ManagedCluster
CR을 관리합니다. 각 호스트에 대해 수동으로 개별BMCSecret
CR을 생성합니다.
프로세스
hub 클러스터에 필요한 관리 클러스터 시크릿을 생성합니다. 이러한 리소스는 클러스터 이름과 일치하는 이름이 있는 네임스페이스에 있어야 합니다. 예를 들어
out/argocd/example/siteconfig/example-sno.yaml
에서 클러스터 이름과 네임스페이스는example-sno
입니다.다음 명령을 실행하여 클러스터 네임스페이스를 내보냅니다.
$ export CLUSTERNS=example-sno
네임스페이스를 생성합니다.
$ oc create namespace $CLUSTERNS
관리 클러스터에 대한 풀 시크릿 및 BMC
Secret
CR을 생성합니다. 풀 시크릿에는 OpenShift Container Platform 및 필요한 모든 Operator를 설치하는 데 필요한 모든 인증 정보가 포함되어야 합니다. 자세한 내용은 "관리된 베어 메탈 호스트 시크릿 생성"을 참조하십시오.참고보안은 site
Config
CR(사용자 정의 리소스)에서 이름으로 참조됩니다. 네임스페이스는 siteConfig 네임스페이스와
일치해야 합니다.Git 리포지토리의 로컬 복제본에 클러스터의 site
Config
CR을 생성합니다.out/argocd/example/siteconfig/
폴더에서 CR에 적합한 예제를 선택합니다. 폴더에는 단일 노드, 3-노드 및 표준 클러스터에 대한 예제 파일이 포함되어 있습니다.-
example-sno.yaml
-
예:-3node.yaml
-
example-standard.yaml
-
예제 파일의 클러스터 및 호스트 세부 정보를 원하는 클러스터 유형과 일치하도록 변경합니다. 예를 들면 다음과 같습니다.
단일 노드 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.16" 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: # ../policygentemplates/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" # 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
참고BMC 주소 지정에 대한 자세한 내용은 "추가 리소스" 섹션을 참조하십시오.
installConfigOverrides
및ignitionConfigOverride
필드는 쉽게 읽을 수 있도록 확장됩니다.-
외부/argocd/extra-manifest에서
기본 extra-manifestMachineConfig
CR 세트를 검사할 수 있습니다. 설치 시 클러스터에 자동으로 적용됩니다. 선택 사항: 프로비저닝된 클러스터에서 추가 설치 시간 매니페스트를 프로비저닝하려면 Git 리포지토리에 디렉터리를 생성하고 (예:
sno-extra-manifest/
) 사용자 정의 매니페스트 CR을 이 디렉터리에 추가합니다.SiteConfig.yaml
이extraManifestPath
필드의 이 디렉터리를 참조하는 경우 이 참조 디렉터리의 모든 CR이 기본 추가 매니페스트 세트에 추가됩니다.crun OCI 컨테이너 런타임 활성화최적의 클러스터 성능을 위해서는 단일 노드 OpenShift에서 마스터 및 작업자 노드에 대해 crun, 추가 작업자 노드가 있는 단일 노드 OpenShift, 3-노드 OpenShift 및 표준 클러스터를 활성화합니다.
클러스터를 재부팅하지 않도록
ContainerRuntimeConfig
CR에서 0일 추가 설치 시간 매니페스트로 crun을 활성화합니다.enable-crun-master.yaml
및enable-crun-worker.yaml
CR 파일은ztp-site-generate
컨테이너에서 추출할 수 있는out/source-crs/optional-extra-manifest/
폴더에 있습니다. 자세한 내용은 " GitOps ZTP 파이프라인의 추가 설치 매니페스트 사용자 지정"을 참조하십시오.
-
out/argocd/example/siteconfig/
과 유사하게kustomization.yaml
generators
섹션의 kustomization.yaml 파일에SiteConfig
CR을 추가합니다. Git 리포지토리에서
SiteConfig
CR 및 관련kustomization.yaml
변경 사항을 커밋하고 변경 사항을 내보냅니다.ArgoCD 파이프라인은 변경 사항을 감지하고 관리 클러스터 배포를 시작합니다.
검증
노드가 배포된 후 사용자 정의 역할 및 라벨이 적용되는지 확인합니다.
$ oc describe node example-node.example.com
출력 예
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
- 1
- 사용자 정의 레이블이 노드에 적용됩니다.
4.5.1. GitOps ZTP 프로비저닝 가속화
GitOps ZTP의 가속화된 프로비저닝은 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.
단일 노드 OpenShift에 GitOps ZTP의 빠른 프로비저닝을 사용하여 클러스터 설치에 걸리는 시간을 줄일 수 있습니다. 가속화 ZTP는 이전 단계에서 정책에서 파생된 Day 2 매니페스트를 적용하여 설치를 가속화합니다.
GitOps ZTP의 가속화된 프로비저닝은 지원 설치 프로그램이 있는 단일 노드 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.10" sshPublicKey: "ssh-rsa AAAA..." clusters: # ... clusterLabels: common: true group-du-sno: "" sites : "example-sno" accelerated-ztp: full
accelerated-ztp: full
을 사용하여 가속 프로세스를 완전히 자동화할 수 있습니다. GitOps ZTP는 가속화된 GitOps ZTP ConfigMap
에 대한 참조로 AgentClusterInstall
리소스를 업데이트하고 TALM에서 정책에서 추출한 리소스를 포함하고 ZTP 작업 매니페스트를 가속화합니다.
accelerated-ztp: 부분
, GitOps ZTP는 가속화된 작업 매니페스트를 포함하지 않지만 다음 유형의
클러스터 설치 중에 생성된 policy-derived 오브젝트를 포함합니다.
-
PerformanceProfile.performance.openshift.io
-
Tuned.tuned.openshift.io
-
네임스페이스
-
CatalogSource.operators.coreos.com
-
ContainerRuntimeConfig.machineconfiguration.openshift.io
이러한 부분적인 가속을 통해 성능 프로필
,Tuned
및 ContainerRuntimeConfig
유형의 리소스를 적용할 때 노드에서 수행한 재부팅 횟수를 줄일 수 있습니다. TALM은 표준 GitOps ZTP와 동일한 흐름에 따라 RHACM이 클러스터 가져오기를 완료한 후 정책에서 파생되는 Operator 서브스크립션을 설치합니다.
배포 규모에 따라 가속화된 ZTP의 이점이 증가합니다. accelerated-ztp 사용: 많은 클러스터에서 전체
이점을 제공합니다. 더 적은 수의 클러스터를 사용하면 설치 시간을 줄이는 것이 덜 중요합니다. 전체 가속 ZTP는 네임스페이스 뒤에 있으며 수동으로 제거해야 하는 문구에 완료된 작업을 남겨 둡니다.
accelerated-ztp를 사용하는 한 가지 이점: 부분적
이점은 주식 구현에 문제가 있거나 사용자 지정 기능이 필요한 경우 온스포크 작업의 기능을 재정의할 수 있다는 것입니다.
4.5.1.2. 가속화된 ZTP 프로세스
가속화된 ZTP는 추가 ConfigMap
을 사용하여 spoke 클러스터의 정책에서 파생된 리소스를 생성합니다. 표준 ConfigMap
에는 GitOps ZTP 워크플로우에서 클러스터 설치를 사용자 정의하는 데 사용하는 매니페스트가 포함되어 있습니다.
TALM은 accelerated-ztp
레이블이 설정되어 있음을 감지한 다음 두 번째 ConfigMap
을 생성합니다. 가속화된 ZTP의 일부로, SiteConfig
생성기는 이름 지정 규칙 < spoke-cluster-name>-aztp
를 사용하여 두 번째 ConfigMap
에 대한 참조를 추가합니다.
TALM이 두 번째 ConfigMap
을 생성한 후 관리 클러스터에 바인딩된 모든 정책을 찾아 GitOps ZTP 프로필 정보를 추출합니다. TALM은 < spoke-cluster-name>-aztp
ConfigMap
CR(사용자 정의 리소스)에 GitOps ZTP 프로필 정보를 추가하고 CR을 hub 클러스터 API에 적용합니다.
4.5.2. GitOps ZTP 및 siteConfig 리소스를 사용하여 단일 노드 OpenShift 클러스터에 대한 IPsec 암호화 구성
GitOps ZTP 및 RHACM(Red Hat Advanced Cluster Management)을 사용하여 설치하는 관리형 단일 노드 OpenShift 클러스터에서 IPsec 암호화를 활성화할 수 있습니다. 관리 클러스터와 관리 클러스터 외부의 IPsec 끝점 간 트래픽을 암호화할 수 있습니다. OVN-Kubernetes 클러스터 네트워크의 노드 간 모든 네트워크 트래픽은 전송 모드에서 IPsec으로 암호화됩니다.
다음 절차에 따라 추가 작업자 노드를 사용하여 단일 노드 OpenShift 클러스터에 대해 IPsec 암호화를 구성할 수도 있습니다. MachineConfig
CR(사용자 정의 리소스)을 사용하여 리소스 가용성이 낮기 때문에 단일 노드 OpenShift 클러스터 및 단일 노드 OpenShift 클러스터에 대한 IPsec 암호화를 구성하는 것이 좋습니다.
사전 요구 사항
-
OpenShift CLI(
oc
)가 설치되어 있습니다. -
cluster-admin
권한이 있는 사용자로 hub 클러스터에 로그인했습니다. - 관리 클러스터에 필요한 설치 및 정책 CR(사용자 정의 리소스)을 생성하도록 RHACM 및 허브 클러스터를 구성했습니다.
- 사용자 지정 사이트 구성 데이터를 관리하는 Git 리포지토리를 생성했습니다. 리포지토리는 hub 클러스터에서 액세스할 수 있어야 하며 Argo CD 애플리케이션의 소스 리포지토리로 정의해야 합니다.
-
butane
유틸리티 버전 0.20.0 이상을 설치했습니다. - IPsec 끝점에 대한 PKCS#12 인증서와 PEM 형식의 CA 인증서가 있습니다.
프로세스
-
최신 버전의
ztp-site-generate
컨테이너 소스를 추출하여 사용자 지정 사이트 구성 데이터를 관리하는 리포지토리와 병합합니다. 클러스터에서 IPsec을 구성하는 필수 값으로
optional-extra-manifest/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
optional-extra-manifest/ipsec
폴더에 다음 인증서를 추가합니다.-
left_server.p12
: IPsec 엔드포인트의 인증서 번들 ca.pem
: 인증서에 서명한 인증 기관인증서 파일은 각 호스트의 NSS(Network Security Services) 데이터베이스에 필요합니다. 이러한 파일은 이후 단계에서 Butane 구성의 일부로 가져옵니다.
-
-
사용자 지정 사이트 구성 데이터를 유지 관리하는 Git 리포지토리의
optional-extra-manifest/ipsec
폴더에서 쉘 프롬프트를 엽니다. 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
사용자 지정 사이트 구성 데이터를 관리하는 리포지토리에
custom-manifest/
폴더를 생성합니다.enable-ipsec.yaml
및99-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
SiteConfig
CR에서custom-manifest/
디렉터리를extraManifests.searchPaths
필드에 추가합니다. 예를 들면 다음과 같습니다.clusters: - clusterName: "site1-sno-du" networkType: "OVNKubernetes" extraManifests: searchPaths: - extra-manifest/ - custom-manifest/
Git 리포지토리에서
SiteConfig
CR 변경 및 업데이트된 파일을 커밋하고 변경 사항을 푸시하여 관리 클러스터를 프로비저닝하고 IPsec 암호화를 구성합니다.Argo CD 파이프라인은 변경 사항을 감지하고 관리 클러스터 배포를 시작합니다.
클러스터 프로비저닝 중에 GitOps ZTP 파이프라인은
custom-manifest/
디렉터리의 CR을extra-manifest/
디렉터리에 저장된 추가 매니페스트 세트에 추가합니다.
검증
IPsec 암호화를 확인하는 방법에 대한 자세한 내용은 " IPsec 암호화 확인"을 참조하십시오.
4.5.3. GitOps ZTP 및 siteConfig 리소스를 사용하여 다중 노드 클러스터의 IPsec 암호화 구성
GitOps ZTP 및 RHACM(Red Hat Advanced Cluster Management)을 사용하여 설치하는 관리형 다중 노드 클러스터에서 IPsec 암호화를 활성화할 수 있습니다. 관리 클러스터와 관리 클러스터 외부의 IPsec 끝점 간 트래픽을 암호화할 수 있습니다. OVN-Kubernetes 클러스터 네트워크의 노드 간 모든 네트워크 트래픽은 전송 모드에서 IPsec으로 암호화됩니다.
사전 요구 사항
-
OpenShift CLI(
oc
)가 설치되어 있습니다. -
cluster-admin
권한이 있는 사용자로 hub 클러스터에 로그인했습니다. - 관리 클러스터에 필요한 설치 및 정책 CR(사용자 정의 리소스)을 생성하도록 RHACM 및 허브 클러스터를 구성했습니다.
- 사용자 지정 사이트 구성 데이터를 관리하는 Git 리포지토리를 생성했습니다. 리포지토리는 hub 클러스터에서 액세스할 수 있어야 하며 Argo CD 애플리케이션의 소스 리포지토리로 정의해야 합니다.
-
butane
유틸리티 버전 0.20.0 이상을 설치했습니다. - IPsec 끝점에 대한 PKCS#12 인증서와 PEM 형식의 CA 인증서가 있습니다.
- NMState Operator가 설치되어 있습니다.
프로세스
-
최신 버전의
ztp-site-generate
컨테이너 소스를 추출하여 사용자 지정 사이트 구성 데이터를 관리하는 리포지토리와 병합합니다. 클러스터에서 IPsec을 구성하는 필수 값으로
optional-extra-manifest/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
optional-extra-manifest/ipsec
폴더에 다음 인증서를 추가합니다.-
left_server.p12
: IPsec 엔드포인트의 인증서 번들 ca.pem
: 인증서에 서명한 인증 기관인증서 파일은 각 호스트의 NSS(Network Security Services) 데이터베이스에 필요합니다. 이러한 파일은 이후 단계에서 Butane 구성의 일부로 가져옵니다.
-
-
사용자 지정 사이트 구성 데이터를 유지 관리하는 Git 리포지토리의
optional-extra-manifest/ipsec
폴더에서 쉘 프롬프트를 엽니다. optional-extra-manifest/ipsec/import-certs.sh
스크립트를 실행하여 외부 인증서를 가져오는 데 필요한 Butane 및MachineConfig
CR을 생성합니다.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
리포지토리에
custom-manifest/
폴더를 생성하여 사용자 지정 사이트 구성 데이터를 관리하고enable-ipsec.yaml
및99-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
SiteConfig
CR에서 다음 예와 같이extraManifests.searchPaths
필드에custom-manifest/
디렉터리를 추가합니다.clusters: - clusterName: "site1-mno-du" networkType: "OVNKubernetes" extraManifests: searchPaths: - extra-manifest/ - custom-manifest/
-
GitOps의
source-crs
디렉터리에ipsec-config-policy.yaml
구성 정책 파일을 포함하고PolicyGenerator
CR 중 하나에서 파일을 참조합니다. Git 리포지토리에서
SiteConfig
CR 변경 및 업데이트된 파일을 커밋하고 변경 사항을 푸시하여 관리 클러스터를 프로비저닝하고 IPsec 암호화를 구성합니다.Argo CD 파이프라인은 변경 사항을 감지하고 관리 클러스터 배포를 시작합니다.
클러스터 프로비저닝 중에 GitOps ZTP 파이프라인은
custom-manifest/
디렉터리의 CR을extra-manifest/
디렉터리에 저장된 추가 매니페스트 세트에 추가합니다.
검증
IPsec 암호화를 확인하는 방법에 대한 자세한 내용은 " IPsec 암호화 확인"을 참조하십시오.
4.5.4. IPsec 암호화 확인
IPsec 암호화가 관리형 OpenShift Container Platform 클러스터에 성공적으로 적용되었는지 확인할 수 있습니다.
사전 요구 사항
-
OpenShift CLI(
oc
)가 설치되어 있습니다. -
cluster-admin
권한이 있는 사용자로 hub 클러스터에 로그인했습니다. - IPsec 암호화를 구성했습니다.
프로세스
다음 명령을 실행하여 관리 클러스터의 디버그 Pod를 시작합니다.
$ oc debug node/<node_name>
다음 명령을 실행하여 IPsec 정책이 클러스터 노드에 적용되었는지 확인합니다.
sh-5.1# ip xfrm policy
출력 예
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
다음 명령을 실행하여 IPsec 터널이 가동되어 연결되어 있는지 확인합니다.
sh-5.1# ip xfrm state
출력 예
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
다음 명령을 실행하여 외부 호스트 서브넷에서 알려진 IP를 ping합니다. 예를 들어
ipsec/ipsec-endpoint-config.yaml
파일에서 설정한rightsubnet
범위에서 IP 주소를 ping합니다.sh-5.1# ping 172.16.110.8
출력 예
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
4.5.5. 단일 노드 OpenShift SiteConfig CR 설치 참조
siteConfig CR 필드 | 설명 |
---|---|
|
참고
|
|
|
|
사이트의 모든 클러스터에 대해 hub 클러스터에서 사용 가능한 이미지 세트를 구성합니다. hub 클러스터에서 지원되는 버전 목록을 보려면 |
|
클러스터 설치 전에 선택적 구성 요소를 활성화하거나 비활성화하려면 중요
예제 |
|
개별 클러스터를 배포하는 데 사용되는 클러스터 이미지 세트를 지정합니다. 정의된 경우 사이트 수준에서 |
|
사용자가 정의한
예를 들어 |
|
선택 사항: |
| 신뢰할 수 있는 플랫폼 모듈(TPM) 및 플랫폼 구성 등록(PCR) 보호로 디스크 암호화를 활성화하도록 이 필드를 구성합니다. 자세한 내용은 " TPM 및 PCR 보호로 디스크 암호화 정보"를 참조하십시오. 참고
|
|
디스크 암호화 유형을 |
| 디스크 암호화에 대한 플랫폼 구성 등록(PCR) 보호를 구성합니다. |
| 디스크 암호화에 사용할 플랫폼 구성 레지스터(PCR) 목록을 구성합니다. PCR 레지스터 1과 7을 사용해야 합니다. |
|
단일 노드 배포의 경우 단일 호스트를 정의합니다. 3-노드 배포의 경우 세 개의 호스트를 정의합니다. 표준 배포의 경우 역할이 있는 세 개의 호스트( |
| 관리 클러스터에서 노드의 사용자 지정 역할을 지정합니다. 추가 역할은 사용자만 OpenShift Container Platform 구성 요소에서 사용하지 않습니다. 사용자 지정 역할을 추가하면 해당 역할의 특정 구성을 참조하는 사용자 지정 머신 구성 풀과 연결할 수 있습니다. 설치 중에 사용자 정의 레이블 또는 역할을 추가하면 배포 프로세스가 더 효과적이며 설치가 완료된 후 추가 재부팅이 필요하지 않습니다. |
|
선택 사항: 디스크를 완전히 삭제하지 않고 값의 주석을 |
| 호스트에 액세스하는 데 사용하는 BMC 주소입니다. 모든 클러스터 유형에 적용됩니다. GitOps ZTP는 Redfish 또는 IPMI 프로토콜을 사용하여 iPXE 및 가상 미디어 부팅을 지원합니다. iPXE 부팅을 사용하려면 RHACM 2.8 이상을 사용해야 합니다. BMC 주소 지정에 대한 자세한 내용은 "추가 리소스" 섹션을 참조하십시오. |
| 호스트에 액세스하는 데 사용하는 BMC 주소입니다. 모든 클러스터 유형에 적용됩니다. GitOps ZTP는 Redfish 또는 IPMI 프로토콜을 사용하여 iPXE 및 가상 미디어 부팅을 지원합니다. iPXE 부팅을 사용하려면 RHACM 2.8 이상을 사용해야 합니다. BMC 주소 지정에 대한 자세한 내용은 "추가 리소스" 섹션을 참조하십시오. 참고 지금까지 엣지 Telco 사용 사례에서는 GitOps ZTP에서 사용할 수 있도록 가상 미디어만 지원됩니다. |
|
호스트 BMC 인증 정보를 사용하여 별도로 생성하는 |
|
호스트의 부팅 모드를 |
|
배포 장치를 지정합니다. 재부팅 시 안정적인 식별자를 사용하는 것이 좋습니다. 예를 들어 |
| 선택 사항: 이 필드를 사용하여 영구 스토리지의 파티션을 할당합니다. 디스크 ID와 크기를 특정 하드웨어에 조정합니다. |
| 노드의 네트워크 설정을 구성합니다. |
| 호스트의 IPv6 주소를 구성합니다. 고정 IP 주소가 있는 단일 노드 OpenShift 클러스터의 경우 노드별 API 및 Ingress IP가 동일해야 합니다. |