쿠버네티스(Kubernetes) 블로그 시리즈 두 번째 포스팅에 오신 것을 환영합니다.
이번 시리즈에서는 Zadara의 AWS API 호환 클라우드 환경에서 Kubernetes를 어떻게 배포하고 운영할 수 있는지 소개합니다. Kubernetes를 처음 접하는 분부터 이미 운영 경험이 있는 사용자까지, Zadara 클라우드에서 컨테이너 기반 애플리케이션을 보다 효율적으로 운영할 수 있도록 다양한 인사이트와 모범 사례를 다룰 예정입니다. 이번 포스팅에서는 Zadara 클라우드 기반의 EKS-D(EKS Anywhere Distribution) 솔루션을 소개합니다. 솔루션 구성과 참조 아키텍처를 살펴보고, 자동화된 배포 블루프린트를 활용해 Kubernetes 클러스터를 얼마나 간단하게 구축할 수 있는지 실제 배포 흐름을 통해 설명하겠습니다.
zCompute 23.08 이상(VSC 모드 기준)부터 Zadara는 고도로 커스터마이징 가능한 셀프 매니지드(Self-Managed) EKS-D 클러스터 자동 배포 기능을 제공합니다.
EKS-D 솔루션은 크게 다음 세 가지 핵심 요소로 구성됩니다.
첫 번째 요소는 EKS-D VM 이미지입니다. 이 이미지에는 Kubernetes 실행에 필요한 필수 구성 요소, EKS-D 아티팩트 및 다양한 커스터마이징 기능이 포함되어 있습니다.
Zadara는 AWS EKS와 동일한 방식으로 각 EKS-D 메이저 버전에 맞는 이미지를 미리 구성(pre-baked)된 AMI 형태로 제공하며, 각 클라우드의 Marketplace에서 사용할 수 있도록 지원합니다.
또한 이미지 생성 과정 자체도 오픈소스 기반 Packer 프로젝트 형태로 함께 제공됩니다. 이를 통해 고객은 이미지 생성 프로세스를 직접 검토할 수 있으며, 필요에 따라 자체 커스텀 AMI를 생성하는 것도 가능합니다.
두 번째 요소는 자동화된 배포 스크립트입니다.
이 구성은 다음 두 개의 Terraform 프로젝트로 이루어져 있습니다.
추가로 원클릭 실행을 위한 Wrapper Script도 함께 제공됩니다.
자동 배포가 완료되면 Zadara 클라우드 상에 Kubernetes 클러스터가 자동으로 생성되며, Kubernetes 관리자용 로컬 kubeconfig 파일도 함께 제공됩니다.
세 번째 요소는 Kubernetes Add-ons입니다.
이는 이미지에 기본 내장되어 있으며 자동 배포 과정에서 함께 구성되는 Kubernetes 네이티브 애플리케이션입니다.
각 애드온에 대해서는 이후 블로그에서 더 자세히 다룰 예정입니다. 다만 현재는 대부분의 기능이 기본 활성화되어 있어, 별도 설정 없이 바로 사용할 수 있는(out-of-the-box) 형태로 제공된다는 점만 기억하시면 됩니다.
아래 구성은 Terraform 프로젝트를 통해 자동 생성되는 EKS-D 배포 환경의 전체 아키텍처를 보여줍니다.
Kubernetes 환경을 위한 전용 VPC가 생성됩니다.
192.168.0.0/16Internet Gateway가 연결된 Public Subnet이 생성됩니다.
이 서브넷은 다음 역할을 수행합니다.
내부 Private Subnet VM 접근을 위한 Bastion(Jump Server) 인스턴스를 호스팅합니다.
기본적으로 Security Group은 외부 SSH 접근을 허용하지만, 필요 시 정책 변경이 가능합니다.
Kubernetes API Server용 Load Balancer(NLB)가 이 서브넷에 배치됩니다.
6443NAT Gateway와 인터넷 연결용 라우팅 테이블이 포함된 Private Subnet이 생성됩니다.
이 서브넷에는 다음 노드들이 배치됩니다.
각 노드는 전용 Auto Scaling Group(ASG)으로 관리되며, 개별 Launch Configuration과 확장 정책을 가질 수 있습니다.
Master/Worker VM용 IAM 정책과 역할도 자동 생성됩니다.
각 인스턴스는 Instance Profile을 통해 필요한 권한을 할당받으며, 기본적으로 다음 API 사용 권한이 포함됩니다.
필요에 따라 권한 정책을 수정할 수도 있습니다.
자동 배포 워크플로우를 실행하기 전에, 사전 준비 단계로 zadara-examples GitHub 저장소에 안내된 클라우드 요구사항들을 먼저 확인해야 합니다.
대부분의 경우 기본 배포값인 gp2를 사용하지만, 필요 시 클라우드 관리자에게 문의하거나 문서에 설명된 Symp 명령어를 실행하여 다른 값이 올바른지 검증할 수 있습니다.
배포를 위해서는 Bastion Host용 Ubuntu 22.04 AMI와 Kubernetes Master/Worker 노드용 원하는 버전의 EKS-D AMI ID가 필요합니다. 해당 이미지가 아직 Images 목록에 없다면, 클라우드 Marketplace에서 확인할 수 있습니다.
해당 Key Pair는 필요 시 Bastion, Master, Worker VM에 SSH로 접속하기 위해 사용됩니다. 모든 VM에 동일한 Key Pair를 사용할 수도 있고, 역할별로 서로 다른 Key Pair를 사용할 수도 있습니다.
사용하는 계정에는 대상 프로젝트에 대해 최소 MemberFullAccess 및 IAMFullAccess 권한이 필요합니다. 또는 AdministratorAccess와 같은 상위 권한을 사용할 수도 있습니다.
이는 이후 배포 과정에서 필요한 IAM 리소스를 생성하기 위해 반드시 필요합니다.
배포 워크플로우를 실행하려면 대상 클라우드에 접근 가능한 Bash 기반 실행 환경이 필요합니다.
해당 환경에는 Git과 Terraform(또는 OpenTofu)이 사전에 설치되어 있어야 합니다.
또한 Marketplace에서 제공되는 Zadara Toolbox 이미지를 사용할 수도 있습니다.
이 이미지에는 Git과 Terraform이 기본 포함되어 있어 배포 환경 구성에 바로 활용할 수 있습니다.
준비가 완료되면 아래와 같이 zadara-examples 저장소를 Clone한 뒤, \k8s\eksd 디렉터리로 이동하여 자동 배포를 시작합니다.
git clone https://github.com/zadarastorage/zadara-examples.git
cd zadara-examples/k8s/eksd/대부분의 경우 자동화된 EKS-D 배포를 실행하는 가장 간단한 방법은 All-in-One Wrapper Script를 사용하는 것입니다.
이 스크립트는 몇 가지 기본 파라미터만 입력하면 인프라 구성용 Terraform 프로젝트와 EKS-D 배포용 Terraform 프로젝트를 모두 자동으로 실행합니다. 약 10분 정도 후 Kubernetes 클러스터가 자동으로 구성되며, 즉시 사용할 수 있는 로컬 관리자용 kubeconfig 파일도 함께 생성됩니다. 이 스크립트는 다음 챕터에서 설명할 비기본(Default 외) 설정값과 함께 사용할 수도 있지만, 이번 예제에서는 단순화를 위해 기본 설정 기준으로 진행하겠습니다.
자동 배포를 실행하기 위해서는 다음 단계를 순서대로 수행합니다.
이제 환경 설정 내용을 살펴보겠습니다.
해당 설정에서는 아래 변수들을 구성합니다.
api_endpointenvironmentbastion_keynamebastion_keyfilebastion_amibastion_userubuntu가 기본값)eksd_amimasters_keynamemasters_keyfileworkers_keynameworkers_keyfile이번 예제에서는 편의를 위해 동일한 Key Pair를 사용했지만, 필요에 따라 Bastion, Master, Worker VM 각각에 서로 다른 Key Pair를 사용할 수도 있습니다.
또한 Terraform 특성상 Private Key 파일 경로는 상대 경로(Relative Path)가 아닌 절대 경로(Absolute Path)로 지정해야 합니다.
계속 진행하기 전에 Ubuntu 이미지와 EKS-D 이미지 모두 Compute 클라우드의 Images 목록에서 업로드가 완료된 상태(Ready 상태)인지 반드시 확인해야 합니다.
설정이 모두 완료되었다면, 이제 사용자의 AWS Credentials를 인자로 전달하여 apply-all.sh 스크립트를 실행할 수 있습니다.
또는 보안 강화를 위해, 예제처럼 환경 변수(Environment Variables) 형태로 Credentials를 전달하는 방식도 사용할 수 있습니다.
스크립트 실행 전에 표시되는 타임스탬프를 참고하면, 기본 배포 설정 기준으로 전체 작업에는 약 10분 정도가 소요됩니다.
또한 배포 과정에서는 별도의 사용자 입력 없이 다음 작업들이 자동으로 수행됩니다.
기본 구성 기준으로 kubeconfig 파일을 가져오는 마지막 단계에서는 Kubernetes Control Plane이 초기 부트스트래핑되는 과정이 필요하기 때문에 몇 분 정도 추가 시간이 소요될 수 있습니다.
일반적으로 약 20회 정도 재시도를 수행한 뒤 kubeconfig 파일이 생성됩니다.
최종적으로 생성된 kubeconfig 파일은 콘솔에 출력되며, 작업 디렉터리에도 함께 저장됩니다.
스크립트 실행 전에 표시되는 타임스탬프를 참고하면, 기본 배포 설정 기준으로 전체 작업에는 약 10분 정도가 소요됩니다.
또한 배포 과정에서는 별도의 사용자 입력 없이 다음 작업들이 자동으로 수행됩니다.
기본 구성 기준으로 kubeconfig 파일을 가져오는 마지막 단계에서는 Kubernetes Control Plane이 초기 부트스트래핑되는 과정이 필요하기 때문에 몇 분 정도 추가 시간이 소요될 수 있습니다.
일반적으로 약 20회 정도 재시도를 수행한 뒤 kubeconfig 파일이 생성됩니다.
최종적으로 생성된 kubeconfig 파일은 콘솔에 출력되며, 작업 디렉터리에도 함께 저장됩니다.
CNI를 제외한 모든 Add-on은 Helm 기반으로 배포되므로, 필요에 따라 목록 조회, 업그레이드 및 설정 변경과 같은 작업을 수행할 수 있습니다.
이처럼 Zadara 클라우드에서는 약 10분 이내에 완전히 동작하는 Kubernetes 클러스터를 자동으로 구축할 수 있습니다. 생성된 클러스터는 실제 Kubernetes 워크로드 운영에 바로 활용할 수 있으며, 함께 설치된 다양한 Add-on을 통해 클라우드 서비스와의 연동도 손쉽게 구성할 수 있습니다.
다음 블로그에서는 Zadara 기반 Kubernetes 환경의 주요 활용 사례(Use Case)에 대해 더욱 자세히 살펴볼 예정이니 많은 기대 부탁드립니다.
최근 기업들은 AI, 데이터 플랫폼, MLOps, 클라우드 네이티브 환경 전환과 함께 Kubernetes 기반 인프라에 대한 요구가 빠르게 증가하고 있습니다. 하지만 실제 운영 환경에서는 단순히 Kubernetes를 설치하는 것을 넘어, 네트워크·스토리지·보안·백업·오토스케일링까지 통합적으로 고려해야 하는 복잡성이 존재합니다. Zadara의 EKS-D 자동화 아키텍처는 이러한 운영 복잡도를 크게 줄이면서도 AWS API 호환성과 프라이빗 클라우드의 통제성을 동시에 제공한다는 점에서 의미가 있습니다. 특히 퍼블릭 클라우드 경험은 유지하면서도 데이터 주권, 비용 예측성, 엔터프라이즈급 운영 안정성을 함께 고려해야 하는 고객들에게 매우 현실적인 Kubernetes 운영 대안이 될 수 있습니다.
