TL;DR

Kubernetes 에는 Pod를 관리함에 있어서 다양한 기능들을 제공해주는 Resource가 있는데 그 중 Controller 에 대해서 알아보았다.

Controller 는 크게 4가지 기능을 제공해준다.

• Auto Healing: Pod 에대한 helthcheck를 통해서 문제가 생겼다면 새로 Pod를 띄워주는 기능
• Auto Scaling: Pod 의 resource가 limit 상태가 됐을 때 controller 가 이를 보고 pod 를 scaling 해주는 기능.
• Software Update: Pod 에 대한 version upgrade or downgrade 등을 제공해준다.
• Job: 일시적인 작업을 진행할 때가 있다면 그 때마다 자원을 사용할 수 있도록 해주는 기능

ReplicaSet

Controller 와 Pod는 label과 selector로 연결되게 된다.

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: frontend
  labels:
    app: guestbook
    tier: frontend
spec:
  # modify replicas according to your case
  replicas: 3
  selector:
    matchLabels:
      tier: frontend
    matchExpressions:
    - {key: tier, operator: Exists}
  template:
    metadata:
      labels:
        tier: frontend
    spec:
      containers:
      - name: php-redis
        image: gcr.io/google_samples/gb-frontend:v3

Template

Controller는 Pod가 죽었을 때 재생성을 해주게 되는데 이 때 Pod의 정보는 template 에 있는 정보를 기반으로해서 만들어지게 된다.

Controller 의 selector를 통해 Pod label 을 refering 하게 된다. 또한 template 에 refering할 pod의 label을 넣어줘야 새로 생성되는 파드에 대해서도 관리가 이루어진다.

Replicas

spec.replicas 는 몇 개의 Pod를 운용할 것이냐는 정보를 담고 있다. 해당 값의 설정에 따라서 Pod의 갯수가 정해지게된다.

Selector

matchLabels

정확하게 key 와 value값이 일치하는 label을 가지는 pod에 대해서 관리가 이루어지게 된다.

matchExpressions

operator를 통해서 다양한 조건식을 사용할 수 있다.

• Exists: key가 존재하는 것만 컨트롤한다.
• DoesNotExist: key가 존재하지 않는것만 컨트롤한다.
• In: value list를 설정할 수 있고 이에 포함되는 Label key: value 를 갖는 pod 만 컨트롤한다.
• NotIn: In 과 반대로 포함되지 않는 Pod만 컨트롤한다.

Deployment

운영되고 있는 Service에 대한 재배포기능을 제공해주는 resource라고 볼 수 있다.
배포 방식으로는 4가지가 존재한다.

• ReCreate: 이전 버전의 Pod를 down 시킨다. 그리고 새로운 버전의 Pod를 만듬 ( downtime이 발생 )
• RollingUpdate: 여러개의 Pod가 있다는 가정하에 새버전의 Pod를 하나씩 ( 혹은 설정값에 따라서 ) 만들고 이전 버전의 Pod는 down 시키고 하는 과정으로 traffic을 옮긴다. downtime이 없지만 추가적인 resource가 사용된다는 단점이 있다.
• BlueGreen: Deployment 뿐만 아니라 다른 Controller에서도 사용이 가능한 방식이다. Controller를 하나 더 만들어서 다음 버전의 pod를 만들고 pod에 연결된 service의 label을 v2 로 바꾸는 방식으로 traffic을 순간적으로 변경하게 된다. 이에 따라서 downtime은 거의 0에 가깝고 혹시 v2에 장애가 있다면 Service의 label만 바꾸는 방식으로 롤백이 용이하다.
• Canary: 기본 개념은 두 개의 버전을 같이 운영하면서 새로운 버전에 대한 안정성을 확인하고 나서 점차적으로 Pod를 바꾸는 방식이다. 하나의 Service에서 이전 버전 파드와 최신 버전 파드의 공통 라벨링을 이용해서 traffic을 분산하다가 새로운 버전으로 변경하는 방식이 있을 수 있고 두 개의 service를 달고 앞단에 ingressController를 통해서 다른 endpoint로 운영하다 안정성이 확인되면 이전 endpoint로 덮어씌우는 방식도 가능하다.

추가적으로 Deployment에서 replicaset 이 2개가 만들어지게 되면 2개의 replicaset에서 만들어진 pod들의 label이 같아서 문제가 생길 수 있기 때문에 자체적으로 구분이 가능한 labeling을 해주게 된다.

Reference

https://kubernetes.io/