Add kubernetes/쿠버네티스를 왜 쓰는가?

- 쿠버네티스의 정의, 장점

kubernetes/쿠버네티스를_왜_쓰는가.md

@@ -0,0 +1,53 @@
+# ⚙️ 쿠버네티스를 왜 쓰는가?
+
+## Kubernetes란?
+
+- 컨테이너화된 애플리케이션의 배포, 확장, 관리 자동화를 위한 **OSS(오픈 소스 시스템)**
+    - Software가 아닌 System임에 유의. 쿠버네티스는 단일 소프트웨어가 아님
+    - 여러 소프트웨어와 방법 모음으로 이루어진 시스템임
+
+## 컨테이너 배포/관리를 수동으로 하는 것의 비효율성
+
+### 컨테이너 간 충돌/종료
+
+- 컨테이너들끼리 충돌하거나, 오류가 발생하며 컨테이너가 종료될 수도 있음
+- 비정상적 종료 여부를 알기 위해 하루 종일 모니터링을 하고 있는 것은 매우 비효율적
+- **자동 회복**을 통해 개선 가능
+
+### 컨테이너 교체 필요 (업데이트)
+
+- 매번 컨테이너를 수동으로 올리고 내릴 것인가?
+- 인스턴스에 접속하고, 기존의 것을 내리고, 새로운 것을 띄우는 일련의 커맨드들을 직접 실행하는 것은 비효율적
+    - 동일 컨테이너가 여러 대의 VM에서 운영되고 있다면? 비효율성은 점점 심해짐
+- **자동 배포**를 통해 개선 가능
+
+### 컨테이너의 Scale Out
+
+- 트래픽이 증가해 더 많은 컨테이너가 필요하거나, 트래픽이 감소해 컨테이너 몇 개를 종료하고자 한다면?
+- 직접 트래픽을 측정하고 수동으로 컨테이너를 띄우는 것은 매우 비효율적
+- 거기다가 각 컨테이너에 트래픽을 적절하게 분산하기 위한 방법도 필요
+- **오토 스케일링**과 **로드 밸런싱**을 통해 개선 가능
+
+## 근데 위의 문제는 모두 ECS를 통해 개선 가능한 것이 아닌가?
+
+- 자동 회복 → ECS의 health check 기능을 통해 도입 가능. 특정 주기로 서버의 상태를 체크하여 문제가 있다면 새 서버를 띄움
+- 자동 배포 → ECS를 통해 몇 번의 클릭만으로도 쉽게 서비스 순단 없이 컨테이너를 교체할 수 있음
+- 오토 스케일링 → AWS EC2 Auto Scaling(ASG)와 연동하여 도입 가능
+- 로드 밸런싱 → AWS Load Balancer(ALB)를 통해 도입 가능
+- **결론: 컨테이너 배포/관리 과정에서의 비효율성은 ECS를 통해 개선할 수 있는 것이 맞음. 하지만…**
+
+## 강한 클라우드 종속성
+
+- ECS의 문제점은, AWS ECS라는 도구에 대한 강한 종속성이 생긴다는 것
+- 클러스터, 서비스, 태스크, 이들에서 사용하는 설정값들, 기타 AWS 도구들(ASG, ALB)과의 연동성 등 모두 **AWS 한정으로 동작**
+- 동일한 설정을 다른 클라우드 프로바이더에서 이용하려고 한다면 결국 처음부터 다시 학습하고 다시 구축해야 함
+- ECS 뿐만이 아니라, 다른 클라우드 프로바이더들(GCP, Azure) 역시 컨테이너 관리 방식이 모두 달라 관리에 필요한 설정들을 쉽게 이식할 수 없을 확률이 큼
+- **결론: 평생 AWS만 쓸 거면 상관 없겠지만 그게 아니면 클라우드 프로바이더를 변경하고자 할 때 상당히 귀찮아질 수 있음**
+
+## 쿠버네티스 - 컨테이너 관리 측면에서 사실상 업계 표준
+
+- 쿠버네티스에는 컨테이너 수, 스케일링, 컨테이너 교체법 등을 관리하기 위한 설정 파일이 존재
+- 이 설정 파일은 쿠버네티스를 지원하는 모든 클라우드 프로바이더에서 동작
+- 각 클라우드별 특화 설정은 설정 파일 내에 import하는 방식으로 적용할 수 있음
+    - 즉, 쉽게 갈아끼울 수 있음
+- **결론: 쿠버네티스의 최대 장점은, 배포를 설명하는 방식을 표준화하여 이 표준을 따른다면 어디서든 효율적으로 컨테이너를 관리할 수 있다는 것. 그게 내 로컬 PC이든, 어떤 클라우드 프로바이더이든.**