1016 Kubernetes : 설정 관리와 AWS EKS 배포
✅ 1. 설정과 비밀의 분리: ConfigMap & Secret
-
문제점: 애플리케이션 설정(DB 주소, API 엔드포인트 등)이나 민감한 정보(비밀번호, API 키)를 Docker 이미지에 직접 포함시키는 것은 매우 나쁜 관행입니다. 설정이 변경될 때마다 이미지를 다시 빌드해야 하고, 보안에 매우 취약하기 때문입니다.
-
해결책: 쿠버네티스는 설정(Configuration)과 비밀(Secret)을 애플리케이션 코드와 분리하여 관리할 수 있는 오브젝트를 제공합니다.
| 오브젝트 | ConfigMap | Secret |
|---|---|---|
| 목적 | 일반 설정 정보 저장 | 민감한 정보 저장 |
| 데이터 | Key-Value 쌍의 평문(Plain Text) 데이터 | Key-Value 쌍의 Base64로 인코딩된 데이터 |
| 보안 | 암호화되지 않음 | 기본적으로 인코딩만 되지만, 클러스터 내에서 암호화된 저장 등 추가 보안 메커니즘 제공 |
| 사용 사례 | • DB 호스트 주소, 포트 • 외부 API 엔드포인트 • 기능 활성화 플래그 | • DB 사용자 비밀번호 • TLS 인증서, Private Key • 외부 서비스 API 키 |
➕ Pod에서 ConfigMap/Secret 사용하는 방법
-
Pod를 생성할 때,
ConfigMap이나Secret의 데이터를 두 가지 주요 방식으로 컨테이너에 주입할 수 있습니다.- 환경 변수 (Environment Variables):
ConfigMap이나Secret의 Key-Value를 컨테이너의 환경 변수로 주입합니다. 애플리케이션은 이 환경 변수를 읽어 설정을 로드합니다. (가장 일반적인 방식) - 볼륨 마운트 (Volume Mount):
ConfigMap이나Secret을 가상의 볼륨으로 만들어, 컨테이너 내부의 특정 경로에 파일 형태로 마운트합니다. 애플리케이션은 이 파일을 읽어 설정을 로드합니다.
- 환경 변수 (Environment Variables):
-
핵심 장점: 코드나 이미지의 변경 없이 설정만 독립적으로 업데이트하고, Pod를 재시작하는 것만으로 새로운 설정을 적용할 수 있습니다.
✅ 2. 클라우드 네이티브 배포: AWS EKS (Elastic Kubernetes Service)
-
EKS는 AWS에서 제공하는 완전 관리형 쿠버네티스 서비스입니다.
-
문제점: 쿠버네티스는 매우 강력하지만, 직접 설치하고 운영하는 것은 매우 복잡합니다. 특히, 컨트롤 플레인(Control Plane)의 고가용성, 보안, 업그레이드 등을 관리하는 것은 전문적인 지식이 필요합니다.
-
EKS의 역할: AWS가 쿠버네티스의 컨트롤 플레인(Control Plane)을 대신 관리해주고, 사용자는 애플리케이션을 실행할 워커 노드(Worker Nodes)만 관리하면 되도록 하여, 쿠버네티스 운영의 복잡성을 크게 줄여줍니다.
- 컨트롤 플레인: 클러스터의 전체 상태를 관리하고 결정을 내리는 "두뇌" 역할. (API 서버, etcd, 스케줄러 등)
- 워커 노드: 실제 컨테이너(Pod)가 실행되는 EC2 인스턴스.
✅ 3. EKS 클러스터 구축 및 애플리케이션 배포 과정
➕ 1. 사전 준비 (IAM, VPC, CLI)
- IAM 역할(Role) 생성: EKS 클러스터와 워커 노드가 AWS의 다른 리소스(EC2, ELB 등)를 관리할 수 있도록 적절한 권한을 가진 IAM 역할을 미리 생성해야 합니다.
- VPC 준비: EKS 클러스터가 동작할 격리된 네트워크 공간(VPC)과 서브넷을 준비합니다. 고가용성을 위해 최소 2개 이상의 가용 영역(AZ)에 걸친 서브넷을 사용하는 것이 표준입니다.
- CLI 도구 설치: 로컬 컴퓨터에서 EKS 클러스터를 제어하기 위해
aws-cli,kubectl,eksctl과 같은 명령줄 도구를 설치하고 설정합니다.eksctl: EKS 클러스터 생성을 명령어 한 줄로 자동화해주는 매우 편리한 공식 도구입니다.
➕ 2. EKS 클러스터 구축하기
eksctl을 사용하여 클러스터 이름, 리전, 워커 노드의 사양 및 개수 등을 정의한 YAML 파일을 작성하고, 명령어를 실행하여 클러스터를 생성합니다.eksctl create cluster -f cluster.yaml- 이 과정에서
eksctl은 CloudFormation을 통해 VPC, 서브넷, IAM 역할, 컨트롤 플레인, 워커 노드(EC2 Auto Scaling Group) 등 수많은 AWS 리소스를 자동으로 생성하고 구성해줍니다.
➕ 3. EKS 클러스터에 애플리케이션 배포하기
- 로컬의
kubectl이 EKS 클러스터를 바라보도록 설정(aws eks update-kubeconfig)한 후, 이전에 작성했던 쿠버네티스 YAML 파일(Deployment,Service등)을 그대로 사용하여 애플리케이션을 배포합니다.kubectl apply -f my-app-deployment.yaml kubectl apply -f my-app-service.yaml
➕ 4. LoadBalancer Service로 앱 공개하기
- 애플리케이션을 외부 인터넷에 노출시키기 위해, Service의 타입을
LoadBalancer로 지정합니다. - EKS 클러스터는 이 Service 정의를 감지하고, AWS 클라우드 컨트롤러를 통해 자동으로 AWS의 로드 밸런서(Classic 또는 Network Load Balancer)를 생성하고, 이를 Service에 연결합니다.
- 생성된 로드 밸런서의 DNS 주소를 통해 외부에서 애플리케이션에 접근할 수 있게 됩니다.
➕ 5. 흔적 없이 사라지기 (비용 관리)
- EKS 클러스터는 컨트롤 플레인과 워커 노드(EC2)에 대해 시간당 비용이 발생하므로, 학습이나 테스트가 끝나면 반드시 리소스를 삭제해야 합니다.
eksctl을 사용하여 클러스터를 삭제하면, 클러스터 생성 시 만들어졌던 모든 관련 AWS 리소스(EC2, Auto Scaling Group, IAM 역할 등)를 한 번에 깔끔하게 삭제할 수 있습니다.eksctl delete cluster --name my-cluster --region ap-northeast-2
📌 요약
- ConfigMap과 Secret을 사용하면, 애플리케이션의 설정과 민감 정보를 코드와 이미지로부터 분리하여 유연하고 안전하게 관리할 수 있습니다.
- AWS EKS는 복잡한 쿠버네티스 컨트롤 플레인을 AWS가 대신 관리해주는 완전 관리형 서비스입니다.
eksctl도구를 사용하면 EKS 클러스터 생성에 필요한 복잡한 AWS 리소스들을 자동으로 프로비저닝할 수 있습니다.- EKS 클러스터에
Service타입을LoadBalancer로 지정하여 배포하면, AWS의 실제 로드 밸런서가 자동으로 생성되어 애플리케이션을 외부에 안정적으로 노출시킬 수 있습니다. - 비용 관리를 위해, 사용이 끝난 EKS 클러스터는 반드시
eksctl delete명령어로 삭제해야 합니다.
