Red Hat Blog를 보다가 관심 가는 글이 보여서 AI번역+약간 교정해 보았습니다.
출처: https://developers.redhat.com/articles/2025/07/29/implement-zero-touch-provisioning-openshift-gitops
자동화 와 표준화는 모든 기업에 필수적입니다. 제로터치 프로비저닝(ZTP)은 베어 메탈 환경에 Red Hat OpenShift를 구축하는 핵심 솔루션 중 하나입니다 . 이 글에서는 ZTP가 OpenShift 클러스터의 구축 및 프로비저닝에 어떤 혁신을 가져오는지 분석하며, 특히 Red Hat OpenShift Virtualization 과의 통합에 중점을 둡니다 .
ZTP의 가치
0일차: 사전 설치 자동화
클러스터 설치 전 Day 0 단계에서 ZTP를 사용하면 ClusterCurator와 Red Hat Ansible Automation Platform을 통해 인프라 준비를 자동화할 수 있습니다 .
이 접근 방식을 사용하면 다음이 가능합니다.
- 자동 네트워킹 구성.
- 베어메탈 인프라 준비.
- 필수 조건 검증.
- 설치 전 상태 점검을 수행합니다.
1일차: 자동 배포
ZTP는 OpenShift 배포 프로세스를 오류가 발생하기 쉬운 수동 작업에서 완전 자동화된 프로세스로 전환합니다. 주요 장점은 다음과 같습니다.
- 표준화: 모든 클러스터는 동일한 구성으로 배포됩니다.
- 반복성: 이 과정은 일관된 결과를 내며 무한히 반복될 수 있습니다.
- 속도: 새로운 클러스터의 출시 시간이 크게 단축되었습니다.
- 신뢰성: 설치 과정에서 인적 오류가 제거됩니다.
2일차: 관리 및 확장성
ZTP의 진정한 힘은 2일차 단계에서 드러납니다.
- 확장성: 클러스터에 새로운 노드를 자동으로 확장합니다.
- 정책 관리: 안전 및 규정 준수 정책의 중앙 집중식 구현.
- 일관성: 여러 클러스터에서 일관성을 유지합니다.
- 자동화: 업데이트 및 패치 관리를 자동화합니다.
분산된 OpenShift 엣지 클러스터를 관리하기 위한 GitOps 아키텍처.
그림 1은 여러 네트워크 원거리 사이트에 걸쳐 OpenShift 클러스터를 관리하기 위해 중앙 허브 클러스터를 사용하는 GitOps 기반 배포 모델을 보여줍니다. 여기에는 단일 노드 OpenShift, 3노드 클러스터 또는 여러 제어 및 컴퓨팅 노드가 있는 표준 클러스터와 같은 다양한 구성이 포함될 수 있습니다.
정책 관리
정책 생성기는 Red Hat Advanced Cluster Management for Kubernetes 의 기본 도구 로, 선언적 방식으로 정책을 정의하고 관리할 수 있도록 해줍니다. YAML 정의를 실제 쿠버네티스 정책으로 변환하는 정책 생성기 역할을 하여 여러 클러스터에 걸친 복잡한 구성 관리를 간소화합니다.
PolicyGenerator 작동 방식
PolicyGenerator는 세 가지 주요 구성 요소를 통해 작동합니다.
- PolicySets: 관련 정책을 조립하고 배치 규칙을 통해 적용해야 할 위치를 정의합니다.
- Placements: 정책을 적용할 클러스터를 결정합니다.
- Policy definitions: 개별 정책과 해당 구성을 정의합니다.
다음은 이를 사용하는 방법에 대한 기본적인 예입니다.
apiVersion: policy.open-cluster-management.io/v1 kind: PolicyGenerator metadata: name: policies policySets: ... # array of policySets to define policies: ... # array of policies to define
권장되는 조직 정책
다음 폴더 구조는 정책 구성에 권장되는 방식이지만, 조직의 특정 요구에 따라 조정할 수 있습니다. 이 구조는 정책 및 관리 클러스터의 증가에 따라 원활하게 확장되고 릴리스된 코드의 유지 관리성을 향상시키도록 설계되었습니다.
policies ├── Global # Global configurations for all clusters │ ├── base-config # Essential base configurations │ │ ├── policy-chrony.yaml # Time synchronization │ │ ├── policy-custom-ca.yaml # Custom CA certificates │ │ ├── policy-kubelet.yaml # Kubelet configuration │ │ └── policy-ssh-key.yaml # SSH key management │ ├── day2-config # Post-installation configurations │ │ ├── policy-alertmanager-customrule.yaml # Alerting rules │ │ ├── policy-file-integrity-operator.yaml # File integrity monitoring │ │ ├── policy-ingress-certificate.yaml # Ingress certificates │ │ └── policy-storagecluster.yaml # Storage configuration │ ├── hub-config # Hub-specific configurations │ │ ├── policy-clusterlogging.yaml # Centralized logging │ │ ├── policy-enable-ceph-toolbox.yaml # Ceph tools │ │ └── policy-storagecluster.yaml # Storage configuration │ ├── kustomization.yaml # Kustomize file │ ├── policy-generator.yaml # Policy generator │ ├── registry # Registry configurations │ │ └── policy-registry.yaml # Internal registry policy │ ├── secrets-config # Secret management │ │ ├── policy-external-secrets.yaml # Integration with external vaults │ │ └── policy-secretstore.yaml # Secret store configuration │ ├── security-auth # Security and authentication │ │ ├── policy-authentication.yaml # Authentication methods │ │ ├── policy-disable-self-provisioner.yaml # Self-service limitations │ │ ├── policy-htpasswd.yaml # Htpasswd authentication │ │ └── policy-remove-kubeadmin.yaml # Remove default admin │ ├── storage # Storage configurations │ │ ├── enable-multipath.yaml # Enable multipath │ │ └── policy-storagecluster.yaml # Storage configuration │ ├── testing # Test policies │ │ ├── check-cluster-operator.yaml # Cluster operator check │ │ └── virtualizations # Virtualization configurations │ │ ├── policy-install-mtv.yaml # Migration Toolkit for Virtualization │ │ ├── policy-install-nmstate.yaml # Network state management │ │ └── policy-install-virtualization.yaml # OpenShift Virtualization │ ├── CHANGELOG.md # Reference document for changes made │ └── README.md # General documentation
이 구조는 다음과 같은 여러 가지 장점을 제공합니다.
- 논리적 구성:
- 글로벌 정책과 특정 정책을 명확히 구분합니다.
- 정책의 유형과 목적에 따라 쉽게 식별할 수 있습니다.
- 여러 지역에 걸친 조직 지원.
- 간소화된 유지관리:
- 카테고리별 타겟 업데이트.
- 더욱 효율적인 변경 검토.
- 갈등의 위험이 감소합니다.
- 거버넌스 및 규정 준수:
- 지역별 정책 추적.
- 간소화된 구성 감사.
- 보안 정책의 중앙 관리.
다음은 policy-generator.yaml 예는 이 구조를 사용하는 예입니다 .
apiVersion: policy.open-cluster-management.io/v1
kind: PolicyGenerator
metadata:
name: policies
placementBindingDefaults:
# Set an explicit placement binding name to use rather than rely on the default.
name: "placementbinding"
policyDefaults:
categories:
- "CM Configuration Management"
controls:
- "CM-2 Baseline Configuration"
standards:
- "NIST SP 800-53"
namespaceSelector:
include: ["*"]
exclude: []
namespace: open-cluster-management-policies
remediationAction: inform
complianceType: "musthave"
severity: low
pruneObjectBehavior: "None"
metadataComplianceType: "musthave"
policySets:
- name: global
description: "Global configuration for all managed clusters"
placement:
name: "global-placement"
labelSelector:
matchExpressions:
- key: vendor
operator: In
values:
- OpenShift
policies:
- configure-alert-manager
- enable-registry
- ingress-certificate
- install-cert-manager
- install-external-secrets
- install-lvm
- oauth-configuration
- remove-kubeadmin
- service-account-aap
- ocp-tools
- kubelet-config
- check-cluster-operator
- check-job-failed
- file-integrity
- name: hub
description: "Dedicated configurations for the hub cluster"
placement:
name: "hub-placement"
labelSelector:
matchExpressions:
- key: cluster-name
operator: In
values:
- hub
policies:
- automation-template
- install-gitops
- name: sno
description: "Dedicated configurations for managed clusters of type sno"
placement:
name: "sno-placement"
labelSelector:
matchExpressions:
- key: cluster-name
operator: NotIn
values:
- sno
policies:
- install-smb-operator
policies:
- name: configure-alert-manager
description: "Configures AlertManager for notification management"
manifests:
- path: ../policies/alert-manager.yml
remediationAction: enforce
categories:
- "CM Configuration Management"
controls:
- "CM-2 Baseline Configuration"
standards:
- "NIST SP 800-53"
severity: low
- name: install-external-secrets
description: "Installs and configures External Secrets Operator for secret management"
manifests:
- path: ../policies/external-secrets.yml
remediationAction: enforce
categories:
- "CM Configuration Management"
controls:
- "CM-2 Baseline Configuration"
standards:
- "NIST SP 800-53"
severity: low
...이 조직을 통해 다음이 가능합니다.
- 책임을 명확하게 분리하세요.
- 새로운 정책 추가를 용이하게 합니다.
- 멀티 테넌트 관리를 지원합니다.
- 검토 및 승인 프로세스를 간소화합니다.
- 변경 사항 추적성을 개선합니다.
각 폴더에는 README.md 문서도 포함될 수 있습니다.
- 해당 폴더의 정책 목적.
- 다른 정책과의 종속성.
- 구현을 위한 구체적인 요구 사항.
- 테스트 및 검증 절차.
각 조직은 자사의 특정 요구에 따라 이 구조를 평가하고 조정해야 합니다. 고려해야 할 주요 요소는 다음과 같습니다.
- 관리되는 클러스터의 수.
- 정책의 복잡성.
- 준수 요구 사항
- 조직 팀 구조.
OpenShift 가상화 및 ZTP
멀티 클러스터 관리
ZTP와 OpenShift Virtualization의 통합은 다음과 같은 상당한 이점을 제공합니다.
- 프로비저닝: OpenShift 클러스터의 설치 및 준비가 용이합니다.
- 반복성: 잘 정리된 템플릿 구조에서 시작하여 항상 새로운 설치를 쉽게 복제할 수 있습니다.
- 동질성: ZTP 및 Red Hat Advanced Cluster Management 정책은 OpenShift 클러스터에 적용되는 구성의 동질성과 일반화를 용이하게 합니다.
구현을 위한 모범 사례
ZTP와 GitOps를 구현하기 전에 보안, 확장성 및 관리 편의성을 보장하기 위해 몇 가지 필수 모범 사례를 따르는 것이 중요합니다. 주요 권장 사항은 다음과 같습니다.
- 진실의 단일 소스로서의 GitOps: 모든 구성은 Git을 통해 버전 관리되고 관리되어야 합니다.
- 환경 분리: 실수를 피하고 변경 사항을 단순화하기 위해 별도의 환경(개발, 테스트, 프로덕션)을 유지합니다.
- 안전한 비밀 관리: 외부 비밀과 같은 연산자를 사용하여 민감한 데이터를 저장소에 저장하지 않도록 합니다.
- 자동 검증: CI/CD 파이프라인에 자동 테스트와 규정 준수 검사를 통합합니다.
- 필수 문서: 유지 관리를 지원하기 위해 구성에 간략한 문서를 추가합니다.
Argo CD 응용 프로그램 예:
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: policy
namespace: openshift-gitops
spec:
destination:
namespace: open-cluster-management-policies
server: 'https://kubernetes.default.svc'
project: default
source:
path: policies
repoURL: 'git@github.com:albertofilice/rhacm-policies.git'
targetRevision: HEAD
syncPolicy:
automated:
selfHeal: true
syncOptions:
- CreateNamespace=true
- Validate=true
- RespectIgnoreDifferences=trueAnsible 자동화 플랫폼을 사용한 자동화
대규모 환경에서 일관성과 효율성을 위해서는 클러스터 수명 주기 운영을 자동화하는 것이 필수적입니다. Ansible Automation Platform은 설치 전후 작업, 업그레이드, 검증 등 복잡한 워크플로우를 오케스트레이션하여 모든 단계의 반복 및 감사를 보장합니다. 다음은 ZTP 프로세스에 자동화를 통합하는 방법에 대한 몇 가지 주요 개념과 예시입니다.
프리훅과 포스트훅
ClusterCurator를 사용하면 설치 전, 설치 후 또는 업그레이드 후크를 정의할 수 있습니다.
spec:
install:
towerAuthSecret: aap-integrations
prehook:
- name: Pre-Installation Check
extra_vars:
check_network: true
check_storage: true
posthook:
- name: Post-Installation Validation
extra_vars:
validate_operators: true
validate_network: true
upgrade:
towerAuthSecret: aap-integrations
prehook:
- name: Pre-Upgrade Check
extra_vars:
check_network: true
check_storage: true
posthook:
- name: Post-Upgrade Validation
extra_vars:
validate_operators: true
validate_network: true
type: Job
---
kind: Secret
apiVersion: v1
metadata:
name: aap-integrations
namespace: aap
data:
host: <base64-encoded-host>
token: <base64-encoded-token>
type: OpaqueGit 중심 접근 방식의 주요 이점
주요 이점은 다음과 같습니다.
- 버전 관리 및 제어
- 전체 추적이 변경되었습니다.
- 롤백 가능성.
- 코드에 내장된 문서.
- 자동화 및 CI/CD
- 자동화된 배포 파이프라인.
- 구성 테스트.
- 배포 전 검증.
- 협업 및 표준화
- 모범 사례 공유
- 구조화된 검토 프로세스
- 지식 공유 촉진
1일차 구조 및 Argo CD와의 통합
1일차 단계는 클러스터 설치의 중요한 순간입니다. 파일 구조는 설치의 모든 측면을 관리하도록 구성되어 있습니다.
├── day1-agentclusterinstall.yaml # Cluster installation configuration ├── day1-bmh.yaml # Bare Metal Host definition ├── day1-clusterdeployment.yaml # Cluster deployment ├── day1-infraenv.yaml # Infrastructure environment ├── day1-klusterletaddonconfig.yaml # Managed cluster addon configuration ├── day1-managed-cluster-secret.yaml # Secret for the managed cluster ├── day1-managedcluster.yaml # Managed cluster definition ├── day1-namespace.yaml # Dedicated namespace ├── day1-nmstateconfig.yaml # Network configuration ├── day1-oidc-configmap.yaml # OIDC configuration ├── day1-pull-secret.yaml # Pull secret for images ├── day1-reports.md # Documentation and reports ├── day2-workers/ # Configurations for adding worker / Infra nodes └── kustomization.yaml # Kustomize file for resource management
관리의 편의를 위해 이 예에서는 Red Hat Advanced Cluster Management가 아닌 설치된 IPI 클러스터에서 직접 작업자 노드를 관리하도록 설정했습니다.
따라서 1일차 단계에서는 3노드 클러스터가 구성되고 이후 클러스터 확장을 위해 전용 ApplicationSet으로 확장됩니다.
Argo CD를 사용한 자동화
Argo CD와의 통합을 통해 ApplicationSet을 활용한 배포 프로세스 자동화가 가능합니다. 두 개의 주요 ApplicationSet이 이 프로세스를 관리합니다..
- 환경 ZTP: 클러스터의 초기 배포를 관리합니다.
- 클러스터 스케일: 워커 노드의 스케일링을 관리합니다.
1일차 ApplicationSet:
kind: ApplicationSet
metadata:
name: environments-ztp
namespace: openshift-gitops
spec:
generators:
- git:
directories:
- path: '*'
repoURL: 'https://github.com/test/ztp-environments.git'
revision: develop
# ... existing code ...이것 ApplicationSet:
- Git 저장소의 디렉토리를 자동으로 스캔합니다.
- 발견된 각 환경에 대한 애플리케이션을 생성합니다.
- 충돌을 피하기 위해 특정 필드를 무시하여 차이점을 관리합니다.
- 자동화된 동기화 정책을 구현합니다.
확장을 위한 ApplicationSet:
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
name: cluster-scale
namespace: openshift-gitops
spec:
generators:
- clusters:
selector:
matchLabels:
apps.open-cluster-management.io/acm-cluster: 'true'
# ... existing code ...이 ApplicationSet:
- 레이블을 통해 관리되는 클러스터를 선택합니다.
- day2-workers 파일에서 스케일링 구성을 적용합니다.
- 워커 노드의 동적 확장을 지원합니다.
구조적 이점
이 구조의 장점은 다음과 같습니다.
- 완벽한 자동화:
- 자동화된 클러스터 배포.
- 자동 스케일링 관리.
- 구성의 자체 복구.
- 유연성:
- 다양한 환경 지원.
- 새로운 클러스터를 쉽게 추가할 수 있습니다.
- 환경별로 사용자 정의 가능한 구성.
- 유지 보수성:
- 명확하고 체계적인 구조.
- 책임의 분리.
- 통합 문서화.
- 보안 :
- 비밀스러운 중앙 관리.
- OIDC를 통한 접근 제어.
- 감사 추적을 변경합니다.
외부 비밀 운영자를 통한 시크릿 관리
ZTP 프로젝트에서는 클러스터 운영에 필요한 모든 비밀 정보를 안전하고 중앙에서 관리하기 위해 External Secrets Operator (ESO)를 구현했습니다. 이러한 접근 방식을 통해 Git 저장소를 민감한 데이터로부터 안전하게 보호하고 인프라 보안을 크게 향상시킬 수 있습니다.
볼트를 통해 시크릿을 통합할 수 있는 여러 인증 제품이 있습니다. 편의를 위해 커뮤니티 지원 운영자를 사용했지만, 프로덕션 환경에서는 버그를 적시에 해결하기 위해 인증 및 지원되는 제품을 사용하는 것이 항상 더 좋습니다.
시크릿의 종류
ESO는 클러스터 운영을 위해 다양한 유형의 중요 시크릿을 관리합니다.
- 액세스 자격 증명:
- 인증을 위한 HTPasswd 자격 증명.
- 레지스트리에 대한 액세스 토큰.
- 베어 메탈 호스트(BMH)에 대한 자격 증명.
- 인증서:
- 침투 인증서.
- 사용자 정의 CA 인증서.
- 클러스터 간 통신을 위한 인증서.
- 시스템 스크릿:
- OpenShift 시크릿 풀.
- Red Hat Advanced Cluster Management와의 통신을 위한 시크릿.
- 외부 서비스와의 통합을 위한 토큰입니다.
구현
시크릿 관리에는 두 가지 주요 구성 요소가 사용됩니다.
SecretStore: 비밀 백엔드(예: HashiCorp Vault)에 대한 연결을 정의합니다.ExternalSecret: 백엔드에서 Kubernetes로 비밀을 매핑하는 방법을 정의합니다.
구성 예:
apiVersion: external-secrets.io/v1beta1
kind: SecretStore
metadata:
name: vault-backend
namespace: open-cluster-management-policies
spec:
provider:
vault:
server: "https://vault.example.com"
path: "secret"
version: "v2"
auth:
kubernetes:
mountPath: "kubernetes"
role: "eso-role"
serviceAccountRef:
name: "eso-service-account"
---
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
name: htpasswd-secret
namespace: open-cluster-management-policies
spec:
refreshInterval: "1h"
secretStoreRef:
name: vault-backend
kind: SecretStore
target:
name: htpasswd-secret
data:
- secretKey: htpasswd
remoteRef:
key: clusters/htpasswd이 접근 방식의 이점
GitOps는 향상된 보안, 유지 관리성, 확장성을 포함하여 클러스터 프로비저닝에 상당한 이점을 제공합니다. 인프라에 버전 제어를 적용하여 일관성과 감사 가능성을 보장하는 강력한 솔루션입니다.
- 보안:
- Git 저장소에 민감한 데이터가 없습니다.
- 자동 시크릿 순환.
- 중앙 감사 추적.
- 세분화된 액세스 제어.
- 유지 보수성:
- 중앙집중식 시크릿 관리.
- 자동 업데이트.
- 하드코딩된 시크릿의 위험 감소
- 단순화된 회전 과정.
- 확장성:
- 여러 Vault 인스턴스 지원.
- 대량의 시크릿을 효율적으로 관리합니다.
- 새로운 시크릿을 쉽게 확장할 수 있습니다.
- 멀티 클러스터 환경 지원.
모범 사례를 구현
우리의 접근 방식은 이러한 목표를 달성하기 위해 몇 가지 핵심 원칙을 통합합니다.
- 환경 분리:
- Vault에서는 각 환경에 대한 별도의 경로를 제공합니다.
- 시크릿을 위한 전용 네임스페이스.
- 시크릿 출처를 추적하기 위한 라벨입니다.
- 수명주기 관리:
- 자동 비밀 순환.
- 시크릿 버전 관리.
- 구성의 자동 백업.
- 모니터링 및 감사:
- 시크릿 운영의 기록.
- 무단 접근에 대한 경고.
- 사용량에 대한 정기 보고서.
ZTP 워크플로우와의 통합
ESO는 ZTP 워크플로와 완벽하게 통합됩니다.
- 0일차:
- 볼트 준비에 필요한 시크릿.
- 액세스 정책 구성.
SecretStore설정.
- 1일차:
- 시크릿 설치 중 자동 프로비저닝.
- 초기 자격 증명 설정.
- 인증서 설정.
- 2일차:
- 자동 시크릿 순환.
- 사용자 자격 증명 관리.
- 인증서 업데이트.
보안 고려 사항
안전하고 확장 가능한 OpenShift 환경을 설계하고 구현할 때는 몇 가지 핵심 측면을 고려하는 것이 중요합니다. 다음은 견고하고 규정을 준수하는 인프라를 보장하기 위해 염두에 두어야 할 가장 중요한 고려 사항입니다.
- 시크릿 접근:
- PoLP(최소 권한 원칙) 구현.
- 서비스 계정을 기반으로 한 인증.
- 모든 액세스에 대한 감사 로깅이 수행됩니다.
- 암호화:
- 암호화된 시크릿이 저장되어 있습니다.
- Vault와 통신하기 위한 TLS.
- 비밀 키 순환.
- 규정 준수:
- 보안 정책 준수.
- 변경 사항 추적.
- 절차의 문서화.
마지막 생각
Git 중심 접근 방식을 활용한 ZTP 구현은 OpenShift 인프라 관리의 패러다임 전환을 의미합니다. OpenShift Virtualization과의 결합을 통해 견고하고 확장 가능하며 관리가 용이한 생태계를 구축하여 출시 기간과 운영 비용을 크게 단축할 수 있습니다.
자세한 내용은 다음 자료를 참조하세요.
