쿠버네티스(Kubernetes)

전통적 배포 방식

* 물리 서버 한 대 - 여러 application

* 문제점: 특정 application의 resource 과다 점유 발생 -> 타 application 성능 저하

-> 해결 방안 1: 물리 서버 - application: 1:1 매칭

* 문제점: 리소스 활용도 ↓, 물리 서버 운영 비용↑/관리 어려움

 

가상화 배포 방식

* 물리 서버 한 대 - 여러 Virtual Machine 가동

* 장점: 1) 물리 서버 resource 활용도↑, 하드웨어 비용 절감 (이는 더 나은 확장성 제공)

          2) 보안성 제공(application 간 access 불가)

          3) 물리 resource를 폐기 가능한 가상 머신으로 구성된 클러스터 구성 가능

 

컨테이너 배포 방식

* VM과 유사하나 application 간 OS 공유

* 장점: 1) VM 이미지 방식의 배포보다 쉽고 효율적

          2) 지속적 개발, 통합 및 배포 가능

          3) build/release 시점에 container 이미지를 생성하여 application이 infrastructure와 분리

          4) 운영 환경을 타지 않음

          5) cloud 및 OS 배포판 간 이식성이 좋음

          6) application 중심 관리: 논리적인 resource를 사용하는 OS상에서 application을 실행하므로 추상화 수준이 높아짐

          7) 느슨하고, 자유롭고 유연한 마이크로식 서비스

               * 마이크로 서비스(Micro) <-> 모놀리식 서비스(Monolithic)

           8) resource 격리: application 성능 예측 가능

 

쿠버 네티스가 필요한 이유

분산 시스템을 탄력적으로 실행하기 위해 프레임 워크를 제공하기 때문

 

쿠버 네티스 프레임 워크가 제공하는 기능

* service discovery & load balancing

  DNS 이름이나 자체 IP 주소를 이용하여 container 구분

* storage ocastration

 local, public cloud 가리지 않고 자동 탑재 가능

* self rollout/rollback

container의 원하는 상태로 언제든 변경할 수 있다

* self-bin packing

 쿠버네티스 클러스터 노드를 제공하여 각 container가 필요로 하는 cpu & memory를 쿠버 네티스에게 지시

* self-healing

 쿠버네티스는 container에 문제가 생겼을 때 client 노출 없이 restart, kill, replace 등을 실행하여 중단 없는 운영을 지원한다

* secret과 구성 관리

 암호, OAuth token 및 SSH 키 등을 저장하고 관리

 container 이미지 재구성 X, 스택 구성에 노출 없이 시크릿 및 애플리케이션 구성의 배포 및 업데이트 가능

 

 

 

 

출처: kubernetes.io/ko/docs/concepts/overview/what-is-kubernetes/