Controller

Controller의 주 역할은 Pod 을 생성, 관리하는 것이다.

Controller의 역할

• Auto Healing: Pod 또는 Node의 문제로 인해 Pod가 다운될 시 Pod를 정상적으로 동작하도록 재생성해준다.
• Auto Scaling: Pod의 자원 상태가 limit의 상태로 돌입하였을 때 이를 감지하여 Pod를 하나 더 생성해 부하를 분산시켜 성능에 대한 장애 없이 안정적인 서비스를 운영할 수 있게 해준다.

• Software Update: 여러 Pod에 대한 버전 업그레이드를 컨트롤러를 통해 쉽게 업그레이드가 가능하다.

  • 업그레이드 도중에 기능문제가 생길 시 롤백 기능이 있음

• Job: 필요한(일시적인) 순간에만 작업을 해야할 때만 해당 작업 이행 후 제거할 수 있다.

  • 필요한 순간에만 자원이 생성되고 삭제되기 때문에 효율적인 자원 활용이 가능함

Replication Controller - Deprecated(사용되지 않음)

현재 Replication Controller 대체용으로 ReplicaSet이 사용되고 있다.
지정된 숫자로 Pod을 기동 시키고 관리한다.

기능

• template: Pod를 재생성 또는 추가로 기동시킬 때 즉, template에 정의된 내용을 토대로 Pod를 생성

  • Pod를 미리 생성해놓고 연결할 수도 있고 미리 생성하지 않고도 연결해줄 수 있다.
• replicas: 정해진 개수만큼 Pod의 스케일 인/아웃을 관리해준다.

ReplicaSet

지정된 숫자로 Pod을 기동 시키고 관리한다.

기능

• template, replicas 두개의 기능을 기본적으로 가지고 있다.
• selector: label 기준으로 어떤 Pod들을 관리할지 정의한다.

Selector의 속성

• matchLabels : 기존의 label 기능과 같이 Key: value의 값이 Pod - label과 동일한 Pod들만 연결 시켜주는 기능

  주의사항: label에 정의된 내용을 기준으로 작성해야 한다.

• matchExpressions: 조건을 걸어 label을 좀 더 정교하게 필터링하는 기능

  • Exists: value 값에 상관없이 key 값이 Pod에 존재하는 것만 연결시켜주는 기능
  • DoesNotExist: value 값에 상관없이 key 값이 Pod에 존재하지 않는 것만 연결시켜주는 기능
  • In: 해당 key를 포함하는 Pod들 중에서 value의 값들이 존재하는 것만 연결시켜주는 기능
  • NotIn: 해당 key를 포함하는 Pod들 중에서 value의 값들이 존재하지 않는 것만 연결시켜주는 기능

Tips

• ReplicaSet에서 만들어진 여러 개의 Pod들은 각각의 Pod를 구별해 주기 위해 Pod이름 앞에 자동으로 레플리카셋의 이름을 포함하여 만들어 진다.

• 레플리카 오브젝트를 지우게 되면 자동으로 안에 있던 Pod들도 삭제가 된다. 하지만 레플리카 오브젝트를 지울 때 Pod를 살릴 수 있는 옵션이 있는데 바로 --cascade==false 라는 옵션이다.

  • $ kubectl delete 레플리카_오브젝트명 레플리카_네임 --cascade==false

Deployment

서비스를 업데이트해서 배포 및 재배포 시 도움을 주는 컨트롤러
ReplicationController 와 ReplicaSet 을 좀더 추상화한 개념

쿠버네티스의 일반적인 배포 및 업그레이드 방식

ReCreate

• 이전 Pod들을 삭제 후 새 버전의 Pod를 재배포

  • 서비스에 대한 다운타임이 발생 (일시적인 서비스 중지가 가능할때만 사용가능)

(옵션) revisionHistoryLimit: 이전 버전의 히스토리 보관 개수를 지정한다.

Rolling Update(default)

• 새 버전을 먼저 만들어준다. 즉, V1, V2 버전이 동시에 서비스가 되고 있기 때문에 사용자의 버전이 다를 수 있다.

  • 또한 자원 사용량이 증가된다.(V1, V2 버전이 동시에 운용)
  • 이후 이전 버전의 Pod를 차례로 삭제해준다.
• 추가적인 자원을 요구하지만, 다운타임이 없다.

(옵션) minReadySeconds : V1 -> V2 로 버전을 업데이트할 때 대기 시간을 부여한다.

Blue/Green

블루그린은 새버전, 구버전의 2세트의 서버를 마련하고 한꺼번에 교체하는 배포 방법이다.
로드 밸런서 혹은 서비스 디스커버리 수준에서 참조 대상을 교체하는 방식으로 이뤄지는 배포형태이다.

• 두개의 ReplicaSet.yml 를 작성이 선행되어야 한다.

• Service 컨트롤러를 이용해 label 단위로 V1, V2 버전을 선택. 즉, 신버전, 구버전의 순간적인 교체 가능

  • 문제 시 label만 이전 버전(V1)으로 바꿔주는 롤백이 가능(스탠바이 상태 가능), 다운 타임이 없음
  • 단점은 배포할 서버군을 2게통으로 유지해야 하므로 롤링 업데이트보다 필요 리소스 양이 늘어난다

Canary

신규 버전을 배포할 때 한꺼번에 앱의 전체를 교체하는게 아니라 기존 버전을 유지한 채로 일부 버전만 신규 버전으로 올려서 신규 버전에 버그나 이상은 없는지를 사용자 반응은 어떤지 확인하는데 유용하게 사용하는 방법이다.

• Pod에 대한 label을 2개 달아놓고, 레플리카셋 등으로 테스트용 Canary-Pod의 개수를 할당해 트래픽을 분산 및 신규 버전을 테스트하는 식이다.

  • 다운 타임이 존재하지 않다. 하지만 파드나 서비스 배포 개수에 따라 자원이 그만큼 더 필요하다.

Ingress Controller

• 이 옵션을 이용하면 Path를 이용해 특정 target을 대상으로 테스트가 가능하다.

DaemonSet

이전까진 ReplicaSet과 같은 컨트롤러와 쿠버네티스 스케줄러에 의해 각 Node의 자원량을 점수로 환산해 적절한 곳에 Pod를 배치 시켰지만, Daemonset은 각 Node에 Pod를 하나씩 생성해 준다.

• 각 노드에 두개 이상의 Pod를 만들 순 없지만 nodeSelector-label 를 통해 특정 노드에 Pod를 안만들 순 있다.

대표적인 사용사례

• 성능 수집

  • 각 노드들의 성능을 체크할 수 있는 모니터링 서비스가 필요하다.(Prometheus 툴 등)

• 로그 수집

  • 특정 노드에 장애가 발생했을 경우 문제를 파악하기 위해 필요하다. (fluentd 툴 등)

• 각 노드에 대한 정보를 저장 - Storage

  • 각각의 노드에서 네트워크 파일 시스템을 구축할 수 있다. (GlusterFS 툴 등)

(옵션) hostPort: Service의 externalTrafficPolicy: Local 처럼 해당 노드의 Pod에 접근이 가능하게 해준다.(같은 기능이라고 생각하면 된다.)

Job, CronJob

Job

• 한번 실행되고 끝나는 Pod 을 관리한다.
• Job 컨트롤러가 종료되면 Pod 도 같이 종료한다.
• 컨테이너에서 Job 을 수행하기 위한 별도의 command 를 준다.
• Job command 의 성공 여부를 받아 재실행 또는 종료여부를 결정한다.

CronJob

• Job 컨트롤러를 주기적으로 수행해야 할 때 사용한다. (Pod 등)
• 별도의 schedule 을 정의해아 한다.
• 예시: 주기적인(데이터 백업, 업데이트 확인, 예약 메일, SNS 등 메시징 관리)

(옵션) completions: 정의된 개수만큼 Pod 정해진 작업을 수행한다.

(옵션) parallelism: 정의된 개수만큼 Pod를 생성한다.

(옵션) activeDeadlineSeconds: 정의된 시간(초)동안 동작하다 Pod의 수행여부와 관계없이 종료

• 예를 들어 10초면 끝나야 할 작업이 30초가 되어도 끝나지 않을 시 등 점검해보기 위해 많이 사용

schedule : 리눅스에서 사용하는 Cron 포맷형태 (정의된 시간대로 Job를 만든다.)

concurrencyPolicy: Job의 동작 방식을 설정 (Allow가 default)

Reference

https://arisu1000.tistory.com/27842

https://kkimsangheon.github.io/2019/06/15/kube17/

https://dailyheumsi.tistory.com/208

위로 올라가기💨