rke2spray와 Kubespray 비교

핵심 요약

• Ansible 관점의 직접 비교 대상은 Kubespray와 rke2spray의 Inventory·Playbook·Role·변수·검증 계약임
• kubeadm과 RKE2의 bootstrap·runtime·PKI 차이는 두 Ansible 저장소 자체가 아니라 각 저장소가 선택한 Kubernetes 실행 엔진의 차이임
• Kubespray는 kubeadm 기반 Kubernetes를 구성하는 upstream 원본이고, rke2spray는 그 공개 API를 RKE2 lifecycle로 변환하는 별도 Ansible 구현체임
• 동일한 cluster.yml·Inventory group·Role 경로는 운영 의도와 이름의 호환성을 뜻하며 task 본문·변수 의미·결과 상태의 동일성을 보장하지 않음
• rke2spray는 범용 코어와 sample Inventory만 제공하고 실제 jamie-kr Inventory는 jamie-kr-gitops가 소비자 코드로 소유함
• 선택은 Ansible 재사용만이 아니라 kubeadm 구성요소 선택권과 RKE2 표준화 중 어느 운영 모델을 소유할지로 결정해야 함

비교는 세 계층을 분리함

• Ansible 계층이 사용자의 Inventory와 명령을 해석하고 실행 엔진 계층으로 전달함
• 설치 엔진의 차이가 Ansible Role·변수·tag의 구현 차이를 만드는 인과관계임
• **이 문서의 rke2spray 판정 기준은 검증일의 main과 docs/kubespray-api-compatibility.yml**임

Download source

실제 Inventory는 jamie-kr-gitops가 소유함

• rke2spray와 jamie-kr-gitops는 제공자와 소비자 관계로 분리함
  • rke2spray는 범용 Playbook·Role·plugin·defaults·inventory/sample을 제공함
  • jamie-kr-gitops는 실제 host·group 변수·host 변수·암호화된 Vault 값과 실행 wrapper를 소유함
• 의존 방향은 jamie-kr-gitops가 고정된 rke2spray release를 선택하는 단방향으로 유지함
  • rke2spray 코어에서 jamie-kr 이름·주소·도메인·토폴로지를 참조하지 않음
  • jamie-kr-gitops에서 Collection 또는 고정된 checkout을 통해 rke2spray를 호출함

jamie-kr-gitops/
├── inventory/
│   └── jamie-kr/
│       ├── hosts.yml
│       ├── group_vars/
│       └── host_vars/
├── ansible/
│   └── rke2spray.rev
└── apps/
    └── ...
            │
            └── consumes pinned rke2spray checkout

rke2spray/
├── cluster.yml
├── roles/
├── plugins/
└── inventory/
    └── sample/

• jamie-kr-gitops는 Ansible IaC와 Argo CD GitOps의 환경 선언을 함께 관리함
  • inventory/와 ansible/rke2spray.rev는 Kubernetes API 생성 전 수렴 입력임
  • bootstrap/과 apps/는 Kubernetes API 생성 후 Argo CD 수렴 입력임
• Inventory 이동 후 실행 기준 경로는 jamie-kr-gitops 저장소임

make inventory-vault-check
make inventory-preflight
make cluster-converge
make gitops-bootstrap

• 저장소 이름의 GitOps는 관리 기법이고 Ansible IaC 소유를 배제하는 경계가 아님
  • Inventory는 Kubernetes API가 생성되기 전의 선언적 cluster desired state임
  • apps/는 Kubernetes API가 생성된 후 Argo CD가 수렴하는 platform desired state임
  • 두 상태는 같은 환경 release로 검토할 수 있지만 각 실행 엔진은 rke2spray와 Argo CD로 구분됨

Ansible 관점에서 공개 API의 해석이 다름

• **Ansible 관점의 핵심 차이는 “같은 이름이 어떤 task graph로 해석되는가”**임
  • Kubespray의 kubernetes/kubeadm은 kubeadm task를 실행함
  • rke2spray의 kubernetes/kubeadm은 RKE2 bootstrap·node·control-plane Role을 연결하는 adapter임
• rke2spray의 변수 존재는 기능 지원을 자동으로 의미하지 않음
  • container_manager: docker, container_manager: crio, kubeadm patch와 external CNI 직접 설치 입력은 현재 계약에서 거부됨
  • 변환 가능한 registry mirror·auth·TLS는 RKE2 registries.yaml로 mapping됨
• 공통 Inventory와 Playbook 이름은 runbook 전환 비용을 줄일 수 있으나 drop-in compatibility를 만들지 않음

kubeadm 관점에서 Kubespray의 실행 모델을 봄

• 이 계층은 Kubespray와 rke2spray의 Ansible API 차이가 아니라 Kubespray가 자동화하는 kubeadm 기반 클러스터 모델임

• kubeadm 모델의 장점은 Kubernetes 구성요소를 세부 선택하고 별도로 교체할 수 있는 유연성임
• 한계는 구성 조합이 많아질수록 팀이 component 간 호환성·upgrade 순서·장애 경계를 함께 소유해야 한다는 점임

RKE2 관점에서 rke2spray의 실행 모델을 봄

• 이 계층은 Ansible 인터페이스 차이가 아니라 rke2spray가 자동화하는 RKE2 배포판 모델임

• RKE2 모델의 장점은 runtime·PKI·control-plane lifecycle을 release와 service 단위로 표준화하는 점임
• 한계는 alternate runtime, kubeadm phase, external·custom CNI처럼 RKE2 표준 계약 밖의 요구가 즉시 제약으로 바뀐다는 점임
• RKE2에서 기술적으로 가능한 기능과 현재 rke2spray adapter가 지원하는 기능은 구분해야 함

엔진 차이가 Ansible 계약으로 변환됨

• Adapter는 의도를 변환하지만 실행체를 복제하지 않음
• Conditional은 datastore·topology 같은 전제가 충족될 때만 공개 API가 유효함을 뜻함
• Unsupported는 RKE2 자체의 영구적 불가능이 아니라 현재 rke2spray 공개 실행 계약에 안전한 adapter가 없음을 뜻할 수 있음

공통 Playbook은 의도만 유지함

• rke2spray는 공통 Playbook 외에 health·snapshot·certificate rotation·AddOn plan·converge·prune을 extra_playbooks/로 제공함
• 제거·복구·소유권 이전 같은 고위험 경로에 confirmation과 preflight gate를 추가함

선택은 Ansible 재사용과 실행 모델을 함께 평가함

• 기존 Kubespray 클러스터를 rke2spray로 바꾸는 작업은 Ansible 저장소 교체가 아닌 Kubernetes 엔진 migration으로 계획해야 함
  • 공통 Inventory group이 기존 cluster state·PKI·datastore·CNI를 자동 변환하지 않음
  • 기존 변수와 custom Role을 compatibility contract의 supported·adapter·conditional·unsupported 분류와 대조해야 함

결론과 실행 제안

• Ansible 관점에서 Kubespray는 원본 구현, rke2spray는 공개 이름을 유지하는 RKE2 adapter로 구분함
• 실행 엔진 관점에서 kubeadm은 구성요소 조합, RKE2는 배포판·service·release 통합으로 구분함
• 운영 소유권 관점에서 실제 Inventory는 jamie-kr-gitops, 범용 설치 엔진은 rke2spray로 구분함
• PoC는 공통 cluster.yml 실행만이 아니라 변수 mapping, tag 도달성, upgrade, node 제거와 snapshot 복구를 함께 검증해야 함

기준 자료

• rke2spray Kubespray 비교
• rke2spray Kubespray API 호환성 계약
• Kubespray 저장소와 지원 구성요소
• Kubespray Ansible Inventory
• Kubespray upgrade
• RKE2 architecture
• RKE2 server configuration
• RKE2 network options
• RKE2 backup and restore