Kubernetes가 왜 많이 쓰이나요? (학습과 프로젝트 도입)

Why Kubernetes?

 

Kubernetes(K8s)를 사용하는 이유는 운영 효율성, 확장성, 자동화 등의 이점을 제공하기 때문입니다.

 

1. 자동화된 컨테이너 오케스트레이션

• 수동으로 컨테이너를 배포하고 관리하는 대신, K8s가 자동으로 컨테이너를 배포, 확장, 복구함.
• 예를 들어, Pod가 종료되면 자동으로 새로운 Pod를 생성하여 서비스 가용성을 유지.

2. 높은 확장성 (Scalability)

• 트래픽이 증가하면 자동 확장(Auto-scaling)을 통해 추가 리소스를 할당하고, 트래픽이 줄면 리소스를 줄여 비용 절감 가능.
• Horizontal Pod Autoscaler(HPA), Vertical Pod Autoscaler(VPA) 등을 활용 가능.

3. 서비스 발견 및 로드 밸런싱

• Kubernetes는 내부 DNS 기반 서비스 검색 기능을 제공하여, 컨테이너 간의 통신을 쉽게 함.
• 로드 밸런싱을 통해 트래픽을 여러 Pod에 자동으로 분배하여 성능 최적화.

4. 무중단 배포 및 롤백 지원

• Rolling Update를 통해 무중단 배포 가능.
• 문제가 발생하면 Rollback 기능으로 이전 버전으로 즉시 되돌릴 수 있음.

5. 멀티 클라우드 및 하이브리드 클라우드 지원

• AWS, GCP, Azure 등 다양한 클라우드 환경에서 일관된 배포 및 운영 가능.
• 온프레미스와 클라우드를 혼합한 하이브리드 클러스터 구성도 가능.

6. 리소스 효율적인 운영

• 컨테이너 리소스를 세밀하게 관리 (Requests와 Limits 설정)하여 서버 과부하를 방지.
• 여러 애플리케이션을 단일 클러스터에서 실행 가능하여 서버 비용 절감.

7. 강력한 생태계 및 오픈소스 지원

• Helm, Prometheus, Grafana, Istio 등 다양한 오픈소스 도구와의 통합이 쉬움.
• 대규모 커뮤니티와 클라우드 벤더들의 지속적인 지원이 있음.

 

CNCF(클라우드 네이티브 재단)

https://www.cncf.io/projects/

Graduated and Incubating Projects

위 링크는 클라우드 네이티브 재단 사이트인데, 엄청나게 많은 K8S 관련 생태계가 구축되어 있는 것을 알 수 있습니다.

 

궁금증

 

Docker compose로 3tier app을 운영하다보니 restart 정책으로 컨테이너가 꺼져도 다시 켜지는 기능이 있는데 왜 K8s의 오토힐링 기능이 장점으로 꼽힐까 궁금했습니다.

 

 

Docker의 restart 정책은 단순히 컨테이너가 종료되면 재시작하는 기능입니다.

반면, k8s의 오토힐링은 pod 단위로 동작하며, 컨테이너뿐만 아니라 노드 장애 감지, 상태 체크, 복구까지 포함합니다.

 

즉, Docker의 restart는 애플리케이션이 응답하지 않는 경우 감지할 방법이 없다는 것입니다.

 

이건 전 프로젝트의 아키텍쳐 구조도인데, 컨테이너가 많을 뿐아니라, compose도 다중 compose로 이루어져있었습니다. (include 구문을 통해)

 

모니터링 스택을 넣긴했지만 감지하고 경고알림은 보낼 수 있지만 복구마저 자동화할 수 있는 점이 매력적으로 다가왔습니다.

 

 

컨테이너 내부에 존재하는 파일들은 수명이 짧습니다. 컨테이너에 이런저런 문제가 생기거나 컨테이너가 삭제되거나 재실행되면 해당 컨테이너 내부에 존재하는 파일을 모두 삭제되기 때문입니다. 하지만 쿠버네티스 스토리지를 활용하면 파드의 상태와 상관없이 파일을 보관할 수 있습니다.

 

 

고객들은 f5를 세 번은 누르지만 그 이상은 누르지 않고 떠난다.

 

 

ec2 + eks는 포폴용 프로젝트로 계속 띄우기에는 비용이 필요이상으로 나올 것 입니다. 트래픽이 적을것이고, 쿠버네티스를 연습할 때 서버리스 아키텍처로 사용한 만큼만 내는 것이 좋다고 판단했습니다. (현재 최소 인스턴스 t3.medium)

 

추가적으로 gke는 3개월 무료를 제공해서 테스트할 때 이거로 하면 좋아보입니다.

 

근데 이것도 오버스펙인거 같기도 해서 비용도 고려했을 때, 오픈소스 상태인 minikube 도 적용 고려를 해보았습니다. 

 

학습내용

k8s는 선언적으로 구성됩니다.

 

최소 배포단위는 POD이고, 애플리케이션으로서 배포가 되려면 최소 SERVICE(로드밸런서)와 DEPLOYMENT(배포할 컨테이너 d)가 쌍으로 구성되어야 합니다. 

 

서비스가 커질 경우, 이 service와 deployment 쌍이 많아지기 때문에 운영 복잡성이 커졌고, helm 으로 압축파일로 더 쉽게 관리할 수 있다.

 

마스터 노드에는 이상적인 상황을 설정 후 비이상적일 경우 이 상태를 회복시키는 kube-controller-manager 가 있습니다.

 

클러스터 내부의 권한은 RBAC, 클러스터에서 클라우드에의 읽기 쓰기 권한은 IAM ROLE로 관리할 수 있다. (서비스에도 권한을 부여)

 

Fargate로 사용량만큼만 부여할 수도 있다. 원하는 노드(ec2 인스턴스)를 설정할 수 있다.

 

EKS 등 관리형 K8S의 경우 마스터 노드의 구성을 사용자에게 보여주지 않고 CLUSER IP만 알려준다.