클러스터만 설치하면 끝일까? AWS에 RKE2와 DevOps 스택을 한 번에 올리는 Ansible 자동화
쿠버네티스 구축에서 가장 오래 걸리는 것은 설치 명령이 아닙니다. 세 번째 노드부터 시작되는 반복 작업, 팀마다 달라지는 설정, 며칠 뒤 아무도 정확히 기억하지 못하는 수동 절차가 진짜 비용입니다.
그런데 클러스터가 올라간 뒤에도 할 일은 끝나지 않습니다. 스토리지, 모니터링, 로그, 트레이싱, 백업, GitOps, 인증, 보안, 데이터베이스까지 이어집니다. 결국 “클러스터 설치”보다 “운영 가능한 플랫폼 만들기”가 훨씬 어렵습니다.
AWS 환경의 서버를 RKE2 클러스터로 구성하고, 운영에 필요한 DevOps 오픈소스 패키지까지 Ansible로 자동 배포하는 프로젝트입니다.
한 줄로 요약하면
rke2-install은 단순한 Kubernetes 설치 스크립트가 아닙니다. 컨트롤 노드 준비 → RKE2 마스터 초기화 → 추가 마스터와 워커 조인 → 노드 라벨·테인트 적용 → 운영 도구 배포를 하나의 흐름으로 묶은 인프라 자동화 코드입니다.
AWS 서버 준비 ↓ Ansible Control Node 구성 ↓ RKE2 Control Plane / Worker 클러스터 생성 ↓ Label · Taint 적용 ↓ Storage · Observability · CI/CD · Security · DB 배포 ↓ 운영 가능한 DevOps 플랫폼 완성
왜 RKE2인가?
RKE2는 Rancher 생태계에서 제공하는 경량이면서도 운영 환경을 지향하는 Kubernetes 배포판입니다. 구축 복잡도를 낮추면서 Rancher UI와 자연스럽게 연결할 수 있고, 표준 Kubernetes 도구와 Helm 생태계를 그대로 활용할 수 있다는 점이 매력적입니다.
하지만 좋은 배포판을 선택했다고 자동으로 좋은 운영 환경이 만들어지는 것은 아닙니다. 노드별 역할, 조인 순서, kubeconfig, 라벨과 테인트, 애드온 버전, 설치 순서까지 일관되게 관리해야 합니다. 이 프로젝트는 그 반복을 Ansible Role과 변수로 코드화했습니다.
클러스터만이 아니라 ‘운영 스택’까지
playbook.yaml에는 클러스터 구축 이후 필요한 도구들이 카탈로그 형태로 연결되어 있습니다. 각 구성요소는 배포 여부와 버전을 변수로 선택할 수 있어, 필요한 기능만 조합하는 방식입니다.
| 영역 | 포함된 구성요소 | 역할 |
|---|---|---|
| 클러스터 관리 | Rancher UI | 클러스터 가시화와 운영 관리 |
| 스토리지·백업 | Longhorn, MinIO, Velero | 영구 볼륨, 오브젝트 스토리지, 백업·복구 |
| 관측성 | Prometheus, OpenSearch, Jaeger | 메트릭, 로그 검색, 분산 추적 |
| CI/CD | Argo CD, GitLab, Jenkins | GitOps와 빌드·배포 자동화 |
| 네트워크·보안 | Istio, NeuVector, Keycloak | 서비스 메시, 런타임 보안, 인증·인가 |
| 데이터 계층 | MySQL, MariaDB, PostgreSQL, Kafka, Redis | DB, 메시징, 캐시 |
| 샘플 워크로드 | Java, Spring Cloud Gateway, Node.js, Python | 설치 직후 배포 흐름 검증 |
예를 들어 Prometheus는 DEPLOY_PROMETHEUS, Argo CD는 DEPLOY_ARGOCD, Istio는 DEPLOY_ISTIO 같은 플래그로 켜고 끕니다. 버전도 별도 변수로 고정합니다. “오늘 실행한 설치”와 “한 달 뒤 다시 실행한 설치”가 최대한 같은 결과를 내도록 만든 구조입니다.
설치 흐름은 어떻게 자동화했나
1. Control Node를 먼저 준비한다
Ansible을 실행할 컨트롤 노드를 구성하고, 대상 서버에 필요한 기본 패키지와 설정을 준비합니다. AWS에서는 SSM을 활용하는 운영 방식과도 잘 맞도록 사용자 계정 기반의 자동화 흐름을 구성했습니다.
2. 첫 번째 마스터를 초기화한다
RKE2 클러스터의 시작점이 되는 첫 컨트롤 플레인을 올립니다. 이후 노드가 합류하는 기준점이므로 가장 먼저 안정적으로 만들어야 하는 단계입니다.
3. 마스터와 워커를 순서대로 조인한다
추가 마스터는 고가용성 컨트롤 플레인으로, 워커는 실제 애플리케이션 실행 노드로 연결합니다. 노드 추가 전용 플레이북도 분리되어 있어 클러스터 확장 시 전체를 다시 설치할 필요가 없습니다.
4. 라벨과 테인트로 역할을 명확히 한다
마스터와 워커에 라벨을 적용하고, 컨트롤 플레인에는 필요한 테인트를 설정합니다. 특정 워크로드를 특정 노드군에 배치할 수 있어 운영 정책이 사람의 기억이 아니라 코드로 남습니다.
5. 선택한 카탈로그를 배포한다
Longhorn부터 Argo CD, Prometheus, Istio까지 배포 여부를 변수로 제어합니다. Istio를 사용할 경우 VirtualService 템플릿도 렌더링해 적용하도록 이어집니다.
한 번에 전부 설치할 필요도 없다
INSTALL.sh는 단순 실행 파일이 아니라 플레이북을 선택적으로 호출하는 터미널 메뉴입니다.
- 전체 설치: 클러스터부터 선택된 카탈로그까지 순서대로 실행
- 단일 작업 설치: 특정 Ansible 태그에 해당하는 작업만 실행
- 특정 작업 이후부터 설치: 실패하거나 멈춘 지점 이후를 이어서 실행
- 전체 삭제: 별도 uninstall 플레이북으로 정리
이 방식은 실전에서 특히 유용합니다. 수십 단계 중 하나가 외부 네트워크 문제로 실패해도 처음부터 다시 돌리지 않고, 필요한 구간만 재실행할 수 있기 때문입니다.
빠르게 시작하기
현재 기준 대상 OS는 Rocky Linux 8.8이며, 8.9는 아직 검증 전입니다. 실행 전 Ansible과 yq, SSH 또는 AWS SSM 기반의 노드 접근 환경을 준비합니다.
# 실행 권한 부여 chmod +x INSTALL.sh UNINSTALL.sh # 대화형 설치 메뉴 실행 ./INSTALL.sh # 노드 확장 ansible-playbook playbook-addnode.yaml # 전체 제거 ./UNINSTALL.sh
실행 전에는 group_vars/all/variables.yaml에서 노드 정보, 설치할 패키지, 각 Helm Chart 버전, 배포 플래그를 환경에 맞게 변경합니다. 실제 운영에서는 비밀번호·토큰·클라우드 자격증명을 평문 변수에 넣지 말고 Ansible Vault나 AWS Secrets Manager 같은 비밀 관리 도구와 연결하는 것이 좋습니다.
이 프로젝트가 해결하려는 진짜 문제
자동화의 가치는 명령어 몇 줄을 줄이는 데 있지 않습니다. 누가 설치해도 같은 결과가 나오고, 실패 지점을 다시 실행할 수 있으며, 어떤 버전과 옵션으로 구성했는지 코드에서 설명할 수 있게 만드는 것이 핵심입니다.
- 노드가 늘어나도 반복 설치 절차를 재사용할 수 있습니다.
- Helm Chart 버전을 고정해 예기치 않은 변경을 줄일 수 있습니다.
- 관측성·백업·보안·배포 도구를 하나의 카탈로그로 관리할 수 있습니다.
- Ansible 태그로 부분 실행과 장애 복구가 쉬워집니다.
- 인프라 구축 경험이 개인 노하우가 아니라 팀의 코드 자산으로 남습니다.
“서버는 준비됐습니다”라는 말이 나온 뒤, 며칠씩 수작업하지 않고 운영 가능한 Kubernetes 플랫폼을 재현 가능하게 만드는 것.
마치며
RKE2를 AWS에 설치하는 것 자체는 어렵지 않을 수 있습니다. 어려운 것은 그 위에 팀이 실제로 쓸 수 있는 DevOps 환경을 일관되게 올리고, 다시 만들 수 있도록 남기는 일입니다.
클러스터 한 번을 설치하는 스크립트가 아니라, 운영 환경 전체를 반복해서 만들어내는 코드. 그것이 rke2-install이 지향하는 자동화입니다.
앞으로는 각 카탈로그의 설치 과정, AWS SSM 기반 운영, Longhorn 스토리지 구성, Argo CD GitOps 파이프라인을 단계별로 더 깊게 정리해보겠습니다.
댓글
댓글 쓰기