Kubernetes

📦 컨테이너화된 워크로드와 서비스를 관리하기 위한 오픈소스 플랫폼

가상화

초기단계에서는 각 서버 장치에서 운영체제가 필요한 애플리케이션들을 운영하게 되어서 물리적, 시간적 비용이 컸다. 또한 리소스를 더 많이 차지하는 애플리케이션이 있으면 다른 애플리케이션의 성능이 저하되는 등 리소스 할당의 문제가 있었다. 그 다음으로 가상화가 도입되었고 VM간 애플리케이션을 격리하여 독립된 환경에서 운영할 수 있다. 하지만 각 VM에 os를 구동하다보니 무겁고 느리다는 단점이 있었다. 

이제 컨테이너 가상화 기술은 서비스간에 자원 격리를 하는데 os를 별도로 안띄워도 되기때문에 os 기동 시간이 없어 자동화시 빠르고 효율이 높다. 이런 장점으로 도커가 각광받게 되었다. 하지만 하나의 애플리케이션에서 많은 서비스를 운영하게 될 때 컨테이너들을 일일이 배포하고 운영하는 것은 어느 수준을 넘어가게 되면 어려울 수 있다. 따라서 여러 컨테이너들을 관리해주는 솔루션으로 컨테이너 오케스트레이터가 있다. 여러 컨테이너 오케스트레이터가 등장했지만 현재는 가장 큰 생태계와 기술을 가지고 있는 쿠버네티스가 정석(?)처럼 보편화되어 운영이 커질수록 쿠버네티스의 장점이 커지고 있다. 

왜 필요한가?

• 서비스 디스커버리 & 로드 밸런싱
• 스토리지 오케스트레이션
• 자동화된 롤아웃-롤백
• 자동화된 복구
• 시크릿과 구성 관리

컴포넌트

쿠버네티스 기본 개념 관계를 표현했다. 이게 맞는지...

 

Pod

배포 단위. 시스템을 모듈별로 개발할 수 있다.

컨테이너 그룹이다. 여러 컨테이너를 담을 수 있고 보통 하나의 컨테이너를 담는다.

ReplicaSet

Pod에 문제가 생겼을 때 복제된 Pod 수를 설정하면 그만큼 복제되고 자동 복구된다.

label을 체크해서 원하는 수의 Pod가 아닐 시 새로운 Pod를 생성하여 설정한 복제 Pod 개수를 유지한다. 실전에서 단독으로 쓰는 경우는 없고 Deployment가 ReplicaSet을 이용해서 배포한다.

Deployment

ReplicaSet을 이용하여 Pod를 업데이트하고 버전 관리할 수 있다.

Service

파드 집합에서 실행중인 애플리케이션을 네트워크 서비스로 노출하는 추상화 방법

서비스를 통해 쿠버네티스는 고유한 IP 주소와 파드 집합에 대한 단일 DNS 명을 부여하고 그 사이에 로드밸런스를 수행할 수 있다.

 

필요한 이유

파드는 고유한 IP를 갖지만 디플로이먼트에서 한 시점에 실행되는 파드 집합은 다시 실행 될때는 다른 IP를 갖게 될 수 있다. 따라서 고정된 IP를 가진 서비스를 만들고 그 서비스를 통해 Pod에 접근하는 방식을 사용한다.

 

LoadBalancer

노드가 사라졌을 때 자동으로 다른 노드를 통해 접근이 가능하도록 한다. LoadBalancer Service를 Deployment에 붙여서 외부 ip로 접근할 수 있도록 할 수 있다.