Kubernetes의 목적
Kubernetes의 목적은, 우리의 app들을 container form으로 자동으로 손쉽게 deploy하기 위해 사용한다.
어떻게 구성되어 있을까?
Kubernetes를 바다를 건너는 화물선들(?) 이라고 가정을 해보자.
사실 Kubernetes의 logo는 배의 방향을 결정하는 키의 모습을 하고 있지 않은가??
화물들만 싣어서 바다를 그냥 건너긴 쉽지 않으니,
이 예제에서는 2종류의 배가 컨테이너들을 싣고 움직이는 필요하다고 가정하겠다.
- cargo ship: 실제로 container를 싣고 바다를 건너는 배.
- control ship: cargo ship을 monitoring, managing하는 배.
control ship (master node)
cargo ship에 어떻게 container들을 싣을건지, 어떤 cargo ship이 싣는데 적합한지, conatiner들을 monitoring 하고 tracking하는 역할을 누군가는 해야하는데 그게, control ship이다.
control ship에는 위와 같은 작업을 하기 위해 여러가지 기능이 필요하다.
etcd
어떤 container가 어떤 ship에 있는지, 언제 적재되었는지 등 여러 정보들이 저장되어 있어야 conatiner를 관리한다고 말할 수 있지 않겠는가?
control ship에는 etcd 라고 불리우는 key value format의 database에 저장되어진다.
이 database는 cluster 형태로, ha를 보장하기 때문에 control ship은 저장한 데이터를 안전하게 사용할 수 있다.
kube-scheduler
cargo ship에 container가 하늘에서 뚝 떨어져서 적재 되지 않는다.
control ship에서 cargo ship에 싣을 container를 정해서 싣어 줘야한다. 이때 control ship안의 kube-scheduler라는 부서가 있는데 해당 부서가 그것을 정해준다.
kube-scheduler라는 부서는 container의 size와 이미 적재되어있는 container의 개수 및 크기 또는 container의 타입등을 고려해서, 어느 cargo ship에 싣을지 결정해준다.
kube-scheduler는 container를 싣을 때, 어떤 node에 싣는게 적절한지 판단해준다. 판단의 기준은 Resource requriemetns, worker node의 capacity, policies, taints와 toleration 과 같은 constrains, node affinity rule 과 같은 부분들이다.
controller-manager
전체적인 부분에 대해 관리 감독하는 부서도 필요하다. 예를 들자면, 각 cargo ship에 발생된 damage나 cargo ship끼리의 통시에 있어 traffic 같은 부분들이다.
cargo ship에 올라간 container들 또는 cargo ship 자체가 데미지를 받거나 무슨 문제가 생기거나, 전반적인 각종 문제들에 대해 모니터링하고 있으며 대처하는 부서를 controller-manager 부서가 있다. 그 안에 cargo ship만을 다루는 팀, container만을 다루는 팀 여러 팀이 있다.
contoller-manager에는 여러 controller들이 포함 된다. 예를 들어, node-controller는 node에 대해서 관리한다. cluster에 node를 추가하거나 제거되거나 하는 부분에 대해서 핸들링한다. replication-controller는 desired number of container가 잘 돌아가고 있는지 책임진다.
kube-apiserver
위에 명시한 각기 다른 부서들은 어떻게 통신을 할까? 보통 화물선은 아주 크니까 서로 통신을 할 수 있게 해주는 무언가가 있어야 하지 않을까?
이러한 부분을 해결해주는게 kube-apiserver 부서다. 이 부서는 서로 다른 부서들이 통신이 가능하게 해주는 중앙 관제탑 같은 역할을 한다.
예를 들어, A라는 부서와 B라는 부서가 통신할때 서로 직접 통신하는게 아닌, kube-apiserver를 통해서 통신한다.
kube-apiserver는 api를 expose하여 external user들이 cluster에 대하여 관리할 수 있게 해준다.
control ship과 cargo ship 공통
container runtime
application, dns 서비스, networking 등 모든 서비스들이 container로 실행되기에 container runtime engine이 필요하다. 모든 서비스들이 container로 돌기에 master node와 worker node 모두 container runtime engine이 필요하다. Docker, ContainerD, Rocket 같은 아이들이 여기 포함된다.
cargo ship (worker node)
kubelet
모든 배에는 캡틴이 있다. 우리의 cargo ship 또한 캡틴이 있다. cargo ship의 캡틴을 우리는 kubelet이라고 부른다.
우리의 화물 그룹 joining에 관심 표현부터, container 적재에 대한 명령을 받거나, 적절한 container의 적재, 해당 cargo ship과 적재된 conatiner의 상태 보고 등에 대한 수행을 한다.
kube-apiserver는 주기적으로 kubelet으로 부터 node와 container에대한 상태를 fetch 한다.
kube-proxy
kube-prroxy는 서로 다른 node에 있는 container끼리의 통신을 도와준다.
마치며
언젠가는 시작해야지라고 생각했던 Kubernetes 포스팅을 이제야 하게된다.
이제 대략적인 overview는 서술했으니 떠나자 바다로!
아 시작해버렸다.. 이번 시리즈 범위가 진짜 바다로 출항하는 느낌이네...
그리고 Mumshad, 당신은 천재야!
