컨트롤러란?

각 노드들을 관리해주는 역할을 지닌 객체

컨트롤러는 아래와 같은 기능을 지니고 있다.

• auto Healing: pod 또는 node에 이상이 생길 경우 다른 node에 pod을 생성
• auto Scaling: 한 pod의 처리량이 과중될 경우 실시간 모니터링 중인 controller에 의해 pod가 복제된다.
• SW Update & Rollback: 여러 pod의 버전을 업그레이드 기능/이상 시 roll-back 지원
• Job: batch job용도로 pod를 임시 생성해서 사용

1. Replicaset

이전의 replication Controller는 지원이 중단되었고 현재 replicaset으로 지원되고 있다.

컨트롤러는 크게 3가지로 구성할 수 있다.

우선 Template을 지정하는데 template은 해당 컨트롤러가 생성 시 template으로 pod를 생성한다. 만일 pod를 삭제한다면 template으로 자동으로 생성된다고 볼 수 있다.

다음 replicas는 설정된 수만큼 pod가 생성이 된다. 해당 기능으로 scale-in & scale-out이 가능하다

마지막으로 selector의 설정 방식들이다. 우선 selector는 컨트롤러와 연결된 pod들을 설정하는 기능이다.

replicaset에서는 2가지 기능으로 Selector가 운영이되는데

• matchLabels: 기존의 selector처럼 키와 벨류를 지정하면 해당하는 pod들을 연결한다.
• matchExpressions: pod들을 고를 때에 selector에 조건을 넣어서 고른다.

위의 사진이 matchExpressions의 조건 4가지이다.

• exists/DoesNotExists: 해당 key가 존재하는지 여부
• In/NotIn: 해당 key에 해당하는 values가 존재하는지 여부

  여기서 중요한 점은 template과 selector의 조건이 맞아야된다는 점이다!

=> 결과적으로는 matchExpressions은 어떠한 pod과 연결이 될지 모르기 때문에 잘 사용하지 않는 방법이라고 한다.

1-2 실습

replicaset 생성 코드 

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: replica1
spec:
  replicas: 3
  selector:
    matchLabels:
      type: web
  # Pod 정의
  template:
    metadata:
      name: pod1
      labels:
        type: web
    spec:
      containers:
        - name: container
          image: sample/image
          ports:
            - containerPort: 8000
              hostPort: 8100
              protocol: TCP
          resources:
            limits:
              memory: "128Mi"
              cpu: "500m"
      # Graceful shutdown 비활성화
      terminationGracePeriodSeconds: 0

terminationGracePeriodSeconds를 30으로 설정하면 pod를 삭제 후 30초동안 pod가 유지된다.

2. Deployment

배포의 방식은 총 4가지가 있다.

• ReCreate: pod을 삭제 후 재생성하는 방식
• RollingUpdate: 삭제전 pod를 생성하고 그 후 삭제하는 방식
• Blue/Green: replicaset을 복사 후 재생성
• canary: 필요한 Pod만 생성 후 제거

1) ReCreate

위에서 말했던 것 처럼 reCreate방식은 pod을 삭제 후 재생성하는 방식이다. 이 방식은 pod가 삭제 후 재생성될 때까지의 시간 즉 downTime이 발생하기 때문에 주의해야한다.

RecreaterevisionHistoryLimit 이라는 설정은 Replicatset의 pod들이 삭제되고 0인 replicaset을 몇개까지 유지할것인가에 대한 설정이다 default는 10으로 설정이 되어 있다.

2) RollingUpdate

rollingUpdate 방식은 새로운 Pod을 하나 만들고 기존의 pod를 하나씩 삭제하는 방식이다. 이 방식을 기존의 pod이 없어질 때까지 반복한다.

그렇다면 기존의 v1의 pod으로 연결되면 어떡하냐라는 질문을 할 수 있다. 하지만 pod을 생성할 때 pod-template-hash라는 라벨이 자동적으로 만들어지는데 해당 라벨을 통해 새로 생성된 pod들만 연결이 되기 때문에 그럴일은 없다!

해당 방식은 다운타임이 없다는 장점이 있지만, roll-back을 지원하지 않아 롤백시 위의 방법을 반복해야한다는 번거로움이 있다.

3) Blue/Green

이 방식은 deployment자체적인 기능이 아니라 Replicaset 등의 controller와 selector들을 활용하는 방식이다.

• Controller를 이용해서 pod을 생성
• seletor와 라벨을 이용해서 버전 관리
• service에서는 해당 controller 하위의 Pod들을 연결

위의 장점은 마찬가지로 생성 후 삭제를 진행하기 때문에 downTime이 없다, 또한 기존의 컨트롤러를 유지할 수 있기때문에 rollback이 자유롭다는 특이 있다.

다만 단점은 새로운 컨트롤러를 생성하는 것이므로 자원이 2배가 든다는 점을 고려해야한다.

4) Canary

위 방법은 2가지의 방식이 있다.

[방식1] 새로운 controller를 생성 시에 소수의 pod들을 미리 생성해서 테스팅하는 법

• 컨트롤러를 생성할 때 replicas를 우선 1로 생성하고 테스팅한다.

위 방식은 기존 pod들과 같이 서비스되면서 먼저 테스팅하는 방식이다. 만일 문제가 생긴다면 새로운 컨트롤러 replicas를 0으로 설정하면 된다.

[방식2] 서비스 자체를 따로 두면서 운영하는 방식

• 새로운 서비스 생성 후 pod들을 한 두개로 유지
• ingress Controller를 이용하여 새 서비스와 연결

해당 방식을 이용해 운영자는 테스팅 기간에 특정 유저타켓을 두어 테스팅이 가능하다.

장점은 베타 테스팅, 롤백 등의 기능이 지원이 되고 다운타임이 없다는 점이다. 단점은 blue/green보다는 덜하지만 추가적인 자원을 소모한다는 점이다.

3. DaemonSet

• 노드의 자원상태에 상관없이 pod이 하나씩 생성이 된다(안할 수도 있음)
• 각 노드에 호환되지 않는 pod을 넣어야하는 경우에는 nodeSelector를 통해 라벨을 정해서 지정된 node에만 pod을 넣을 수 있다.
• 또 hostPort를 통해 특정 pod로 연결되도록할 수 있다.

그렇다면 위의 방식은 언제 사용될까? 보통 각 노드에 pod들이 1이상있어야할 때 즉

• node 성능 모니터링
• logging
• 노드의 NFS storage로도 활용 가능
• custom proxy

와 같은 방향으로 사용이 된다.

1) Job

임시 pod를 생성해서 해당 pod를 실행하고 종료(삭제X)를 하는 기능이다. selector는 자동으로 생성이 만들어지는데 아래와 같은 속성들이 있다.

• completions: 순차적으로 실행할 pod의 개수
• parallelism: 동시에 생성될 pod의 개수
• activeDeadlineSeconds: job의 유효기간
  • 이후 실행되는 pod들이 삭제되고, 실행되지 않은 pod들은 실행이 안됨

2) CronJob

지정된 시간 마다 job을 실행하는 기능이다. schedule 설정으로 시간 값을 설정할 수 있다.

• ConcurrencyPolicy에 pod의 관리 방식을 지정할 수 있다.
  • allow: 지정된 시간마다(실행여부와 상관없이) job, pod 모두 생성
  • forbid: 기존 job의 pod가 종료되지 않으면 skip
  • Replace: 기존 job의 pod가 종료되지 않으면 해당 pod를 교체해서 다시 실행