Controller는 아래의 기능을 제공함으로써 운영하고 관리하는데에 도움을 줌.

1. auto healing - 죽으면 다시 띄워줌

2. auto scaling - 1개의 파드가 소화하기에 힘들때 파드를 하나 더 띄워줘서 부하를 분산

3. software update - 여러 파드의 업그레이드를 쉽게, 롤백도 제공

4. job - 일시적인 일을 해야할 때

Replication Controller(deprecated), ReplicaSet

위의 컨트롤러와 파드는 라벨로 (with selector) 연결될 수 있다.

컨트롤러를 만들때 파드의 template를 넣게 되는데, 파드가 죽으면 이걸 보고 살려냄.

컨트롤러의 template에 업그레이드 하고 원래 있던 파드를 죽이면 업그레이드된 버전으로 파드가 새로 뜸(auto healing)

replicas 에 명시된 수 만큼 파드 개수를 유지함.

Selector는 ReplicaSet에만 있는 것임.

matchLabels로 정확히 일치하는 라벨을 찾아서 연결

matchExpression 표현식을 통해서 조금더 세분화해서 selector 설정을 할 수 있음.

matchExpressions:

- {key: ver, operator: Exists}

Exists / DoesNotExist / In / NotIn

Exists - 그 키에 해당하는 파드들을 선택

DoesNotExist - Exists 반대

In - key와 values를 지정할 수 있음. 즉, 조금 더 세분화해서 선택할 수 있음.

NotIn - In과 반대

Recreate(기본), RollingUpdate(strategy에 명시함) - Deployment를 활용.

Blue/Green - ReplicaSet을 활용해서 새로운 파드들을 띄우고 Service의 selector를 수정하여 업데이트된 버전으로 변경함.

Canary - Ingress를 활용해서 2개의 서비스를 동시에 운영.

Deployment - 업데이트를 해서 재배포해야될때 도움을 준다.

ReCreate - 원래 있던 것을 모두 삭제한 다음 새로 생성. 일시적인 정지가 생김.

RollingUpdate - V2 하나 만들고 V1 하나 죽이고 V2 하나 더 만들고 V1 남은 것중 하나 죽이고.... 반복. 배포에 있어 자원소모량이 잠시 증가하지만 무중단 배포가 가능.

Blue/Green - 업데이트한 파드를 띄우기 위한 Controller를 하나 생성(레알 자원 소모 2배) 한 후에 Service에 있는 selector를 변경하여 V1과의 연결을 끊고 V2와 연결되게끔 함. 연결이 끊겼다 뿐이지 v1은 그대로 다 살아있기 때문에 손쉽게 롤백이 가능하다는 것이 장점이다.

Canary - 카나리아를 가스노출이 될만한 곳에 데려다두고 죽는지 안죽는지 실험했던 것에서 유래된 이름. 즉, 실험용을 사용하는 것을 의미한다. V1과 V2 모두 띄워서 둘다 잘 돌아가는지 보고 테스트하는 용도임. 서비스를 모두 Ingress Controller를 맨 앞단에 설치해서 테스트하게끔 할 수 있다. 테스트할 때 얼마나 테스트하는지 어떤걸 테스트하는지에 따라 자원소모량이 많이 필요할 수도 있다.

Downtime - 서버가 잠시 중단됨을 의미함.

revisionHistoryLimit - 이전 ReplicaSet을 몇개나 살려두고 지켜볼거냐를 정의함. default 값은 10임.

strategy: type: RollingUpdate 라고 명시하면 롤링업데이트를 하는데 minReadySeconds를 명시 안해주면 순식간에 롤링업데이트가 되서 이게 롤링인지 아니면 그냥 순삭되버리는건지 모름. 추후 다른 기능을 위해서도 쓰이기도 함.

Deployment는 자기가 만든 pod들을 구별하기 위해 추가적인 라벨을 자동으로 부여한다. 그래서 다른 디플로이먼트가 만든 파드들과 구별이 되는 것임.

kubectl rollout history deployment deployment-1

- 이렇게 입력하면 버전 히스토리를 볼 수 잇음.(history limit 때문에 지워진거는 안보임)

kubectl rollout undo deployment-1 --to-version=2

- 이렇게 하면 롤백이 됨.

Blue/Green은 ReplicaSet을 이용했음.

그리고 나서 서비스에 있는 selector를 수정하여 업데이트 적용시킴.

DaemonSet - 노드의 자원 할당량과 관계 없이 모든 노드에 하나씩 파드를 생성함. 1) 성능 수집 2) 로그 수집 3) 스토리지(네트워크 파일 시스템)

단순하게 만든 pod는 죽으면 다시 안뜸.

ReplicaSet으로 만든 파드는 노드가 죽어서 안뜨면 다른 노드에 연결시켜서 뜨게 함. 다시 뜬 파드가 일을 안하게 되면 Restart를 시킴(컨테이너 죽어도 ps -a 하면 아직 남아있는거를 재실행 시키듯이). 

Job에 의해 만들어진 파드들도 노드가 죽으면 다른 노드에 파드가 뜨고 일이 끝나면 삭제되지는 않고 stop 되어 있는 상태로 남아 있음(ps -a에서 멈춰있는 상태처럼, 나중에 들어가서 로그 같은 것들을 볼 수 있음)

보통 Job만 따로 만들어서 쓰지 않고 CronJob(정기적인 작업을해야할 경우)을 통해서 Job이 생성되도록 하고 그걸 활용함.

DaemonSet은 각 노드마다 1개를 초과해서 파드를 생성할 수는 없지만 nodeSelector를 명시해주면 원하는 노드에만 생성되게는 할 수 있다. 그리고 hostPort를 설정해서 Daemon으로 돌아가는 파드에 접근할 수도 있다.

Job에 파드들이 생성될 수 있도록 template를 명시할 수 있고, selector는 알아서 만들어지게 함.(근데 원래 컨트롤러 쓰면 알아서 인식할 수 있게끔 하는 셀렉터가 생기지 않나...? 궁금하네)

completions 옵션을 명시하면 그 갯수만큼 파드를 생성하고 순차적으로 하나씩 실행되고 모두 끝나야 job이 끝나게끔 할 수도 있고,  parallelism 옵션을 명시하면 completions에 명시된 것들이 동시에 같이 몇개씩 실행될지를 정할 수 있다.

activeDeadlineSeconds를 명시하면 해당 Job 컨트롤러의(파드 단위가 아님) 작업 데드라인을 설정할 수 있고, 모든 파드들이 끝나지 않아도 심지어 실행 대기 중인 파드들도 실행이 안되고 데드라인이 끝나면 걍 끝남.

restartPolicy는 Never와 OnFailure가 있음. 나중에 설명해준대.

CronJob은 jobTemplate를 명시하여 Job을 생성하도록 함.

schedule을 명시하여 cronjob의 * * * * * 포멧을 따름.

concurrencyPolicy - Allow(default) / Forbid / Replace

Allow - 각개 전투, 딱 자기 타임 되면 알아서 튀어나와서 일함.

Forbid - 나 아직 안끝났어 기달려. 다음 스케쥴까지 안끝나면 하던 일 계속하고 끝나면 그 후에 스케쥴이 실행됨.

Replace - 일이 아직 안끝났지만 다음 근무자에게 인수인계함. 새로 파드를 만들고 거기에서 예전에 하던거 함.

Suspend - 실행 중인 job을 일시중지 시킬 수 있음.

ManualTrigger - 수동 실행