Controller의 역할
pod의 개수를 보장
api에게 요청을 날리면 etcd에서 worker node의 정보를 얻어와서 scheduler에게 어디에 다가 배치를 해야하나를 api에 응답해준다.
controller에게 nginx container 3개를 보장해줘라고 요청을 한다.
만약 중간에 하나가 고장나면 controller가 api보고 하나를 더 추가해라 하고 api는 다시 위의 과정을 거쳐서 하나를 추가로 실행한다.
Controller의 종류들
Replication Controller
요구하는 Pod의 개수를 보장하며 파드 집합의 실행을 항상 안정적으로 유지하는 것을 목표
selector 가 구분자 역할을 하게 된다. template 은 recepie
kind 에서 replicationController라는 것을 명시해주고 띄우고 싶은 Pod정보를 template에 적어둔다.
위의 예시에서는 왼쪽의 Pod를 3개 , app:webui 구분자로 띄우려 한다.
label 은 selector 에서 있는것들 중 하나로 해야한다.
get replicationcontrollers에서 현재 해당 컨트롤러로 관리되고 있는 pod를 볼 수 있다.
rc 중 현재 지금 실행중인 rc-nginx의 자세한 정보를 확인한 결과이다.
위의 상태에서 label이 app: webui 인 redis 를 실행시키면 Controller가 바로 terminate시킨다. 해당 label 은 replcation 은 3개로 정했기 때문이다.
kubectl edit rc rc-nginx 명령어를 통해 동작중인 controller의 세부정보를 볼 수 있다.
여기서 replicas 를 4개로 바꾸고 저장하는 순간 그즉시 1개 더 추가 하여 4개를 만들게된다.
kubectl scale rc rc-nginx --replicas=2 명령어를 통해 2개로 줄일 수 있다. 가장 최근에 실행된 녀석들 순으로 terminate시킨다.
rolling update(deploy)(연속적 배포)
kubectl edit rc rc-nginx 으로 들어가서 template의 ngnix version 을 바꾸면 즉시 반영이 되지 않는다. 왜냐하면 현재 지정된 label 을 확인해보니 replica 2개가 정상적으로 돌아가고 있기 때문이다.
이떄 kubectl delete pod rc-nginx-6kcmj 명령어를 통해 동작중인 2개의 pod중 하나를 지우면 이때는 template을 보고 version 업그레이드 된 ngnix pod를 띄우게 된다.
이런 방식으로 지속적인 배포를 할 수 있다.