[쿠버네티스] 10. 쿠버네티스 설치와 디자인

1. 쿠버네티스 클러스터 설계 가이드 

1) 목적별 구성 

(1) 학습용: minikube 또는 단일 노드 클러스터(kubeadm 사용)

(2) 개발/테스트용: 단일 마스터와 다중 워커 노드 구성

(3) 프로덕션용: 고가용성 다중 마스터 노드 구성 

2) 프로덕션 클러스터 사양 

(1) 클러스터 제한사항 

- 최대 5000개 노드

- 최대 150000개 파드

- 최대 300000개 컨테이너

- 노드당 최대 100개 파드

(2) 서버 스팩별 노드 요구사항

노드 수	GCP 인스턴스	스펙	AWS 인스턴스	스펙
1-5	N1-standard-1	1 vCPU, 3.75GB	M3.medium	1 vCPU, 3.75GB
6-10	N1-standard-2	2 vCPU, 7.5GB	M3.large	2 vCPU, 7.5GB
11-100	N1-standard-4	4 vCPU, 15GB	M3.xlarge	4 vCPU, 15GB
101-250	N1-standard-8	8 vCPU, 30GB	M3.2xlarge	8 vCPU, 30GB

3) 배포 옵션 

(1) 클라우드 플랫폼

- GCP: Google Container Engine(GKE)

- AWS: kOps 도구 사용

- Azure: Azure Kubernetes(AKS)
(2) 온프레미스

- kubeadm을 사용한 수동 배포 

- 물리 서버 또는 가상 머신 

- Linux x86_64 아키텍처 필수 

4) 스토리지 고려사항

(1) 성능 요구사항 

- 고성능 워크로드: SSD 기반 스토리지 

- 다중 동시 접속: 네트워크 기반 스토리지 

- 공유 접근: 영구 스토리지 불륨 

5) 모범 사례

(1) 노드 관리 

- 마스터 노드는 컨트롤 플레인 컴포넌트 전용으로 사용

- 워커노드는 워크로드 호스팅용

- 대규모 클러스터의 경우 etcd클러스터를 마스터 노드와 분리 고려 

(2) 아키텍처

- 최소 4개 노드 권장(워크로드 기반으로 크기 조정)

- 마스터 노드는 기술적으로 워크로드 실행 가능하나 권장하지 않음 

- 컨트롤 플레인 전용으로 마스터 노드 유지가 best practice

 

2. 쿠버네티스 인프라 배포 옵션 

1) 로컬환경배포

- 리눅스 환경: 바이너리 직접 설치 또는 자동화 도구 사용

- 윈도우 환경: Hyper-V, Vmware, VirtualBox등의 가상화 스프트웨어를 통해 리눅스 VM 구동 필요

2) 로컬 환경 솔루션(학습 및 개발용)

- Minikube: 단일 노드 클러스터 배포, VirtualBox 등 가상화 소프트웨어 활용 

- kubeadm: 단일/다중 노드 클러스터 배포 가능, 사전에 VM 구성 필요 

3) 프로덕션 환경 솔루션 

(1) 턴키 솔루션

- OpenShift: Red Hat의 온프레미스 쿠버네티스 플랫폼

- Cloud Foundry Container Runtime: BOSH 도구를 통한 HA 클러스터 배포

- VMware Cloud PKS: VMware 환경 최적화

- Vagrant: 다양한 클라우드 제공자용 배포 스크립트 제공

(2) 관리형 서비스

- Google Container Engine(GKE)

- OpenShift Online

- Azure Kubernetes Service(AKS)

- Amazon Elastic Container Service for Kubernetes(EKS)

4) 솔루션 선택 기준

(1) 턴키 솔루션 특징 

- 사용자가 VM 프로비저닝 및 관리 담당

- 도구와 스크립트로 클러스터 관리 자동화 

- 예시) AWS의 KOPS 도구 사용

(2) 관리형 서비스 특징

- 제공자가 클러스터와 VM 배포 및 관리

- 최소한의 구성으로 빠른 배포 가능 

- 예시: GKE의 몇분 내 클러스터 배포 

 

3. 쿠버네티스 고가용성 구성

1) 고가용성의 필요성

- 마스터 노드 장애 시 새로운 파드 생성이나 스케줄링 불가

- 외부에서 클러스터 관리 불가능 

- 프로덕션 환경에서 단일 장애점(SPOF) 방지 필요 

2) 컨트롤 플레인 컴포넌트 HA 구성

(1) API서버

- Active-Active 모드로 동작 

- 로드밸런서(nginx, HAProxy 등)를 통해 트래픽 분산

- 클라이언트는 로드밸런서 주소로 API 서버 접근 

(2) 스케줄러와 컨트롤러 매니저 

- Active-Standby 모드로 동작 

- Leader Election 방식으로 Active 노드 선출 

- 기본설정: 리더임기/15초, 갱신 주기/10초, 재시도 주기/2초 

3) HA 구성 모범 사례 

- 최소 2개 이상의 마스터 노드 

- API 서버용 LB 구성

- 컨트롤 플레인 컴포넌트 이중화 

- ETCD 클러스터의 적절한 구성(스택형 또는 외부)

- 워커 노드의 이중화 

 

4. ETCD 고가용성 구성 

1) ETCD 특징

- 분산형 신뢰성 있는 키-값 저장소

- 단순하고 안전하며 빠른 처리

- JSON/YAML 형식의 복잡한 데이터 저장 가능

2) 분산합의 

(1) 리더 선출

- RAFT 프로토콜을 통한 리더 선출

- RAFT 프로토콜: 분산시스템, ETCD에서 합의를  이루기 위한 프로토콜. 노드간 투표를 통해 리더를 선출함 

- 랜덤 타이머로 리더 후보 결정 

- 리더는 주기적으로 다른 노드에 신호 전송

- 리더 장애시 자동 재선출 

(2) 쓰기 작업 처리 

- 리더 노드만 쓰기 작업 처리 간으 

- 팔로워 노드는 쓰기 요청을 리더에게 전달

- 쓰기 완료는 과반수(쿼럼) 노드 동의 필요 

3) 노드 구성 권장사항 

(1) 쿼럼 계산

- 쿼럼 권장 수: (전체 노드 수/2) +1 

- 3노드: 2개 노드 필요

- 5노드: 3개 노드 필요

- 7노드: 4개 노드 필요

(2) 최적의 노드 수

- 최소 3개 노드 구성 권장 

- 홀수 개의 노드 선호

- 네트워크 분할 시 쿼럼 확보 용이

- 5개 이상은 불필요한 복잡성 증가 

(3) 장애 허용

- 3노드: 1개 노드 장애 허용

- 5노드:2개 노드 장애 허용

- 7노드:3개 노드 장애 허용 

4) ETCD 구성 토폴로지

(1) 스택형 컨트롤 플레인 

- ETCD가 마스터 노드에 함께 배치

- 구성과 관리가 용이 

- 노드 장애 시 ETCD와 컨트롤 플레인 동시 손실 

(2) 외부 ETCD

- ETCD를 별도 서버에서 운영

- 컨트롤 플레인 장애가 데이터 저장소에 영향 없음 

- 더 많은 서버 자원 필요

- 구성이 복잡