10. Controller - DaemonSet, Job, CronJob

 노드들이 있고, 각각의 노드에 자원이 다르게 남아있는 상태에서 이전에 배운 ReplicaSet의 경우 Pod를 스케줄러에 의존해서 노드에 배치를 할 때 만약 노드1에 자원이 많이 남아 있는 상태면 위처럼 배치를 많이 할거고, 자원이 별로 없다면 Pod를 배치 안할 수 있습니다.

 

 

 DaemonSet

: 노드의 자원 상태와 상관없이 모든 노드에 Pod가 하나씩 생긴다는 특징이 있습니다.

 

 이렇게 사용되는 서비스로 대표적인

1. 성능 수집인데 각 노드들의 성능상태는 모두 감시 대상이죠. 그래서 모니터링 화면이 있을거고, 각각의 노드에 프로메테우스 같은 수집 에이전트가 깔여 있어야 모든 노드들의 정보들을 모니터링 시스템에 전달해 줄 수가 있습니다.

2. 로그 수집인데, 특정 노드에 문제가 파악했다면 로그를 확인해야 하는데 Fluentd 같은 서비스는 각각의 노드에 설치돼서 로그 정보들을 수집해줍니다.

3. 노드들을 스토리지에 활용할 수 있는데 GlusterFs와 같은게 각각의 노드에 설치돼서 해당 자원을 가지고 네트워크 파일 시스템을 구축할 수 있습니다.

 

 K8s 자체도 네트워킹 관리를 하기 위해서 각각의 노드에 DaemonSet으로 Proxy 역할을 하는 Pod를 만드는데 추후 운영 편에서 말씀드리겠습니다.

 

 

 Job과 CronJob을 보면 여기에 그냥 (1) Pod를 직접 만드는 경우가 있고, (2) ReplicaSet을 통해서 만들어진 Pod가 있고, (3) Job을 통해 만들어진 Pod가 있습니다. 누구에 의해 만들어졌냐에 따라 달라지는 부분들이 있는데, 이렇게 Pod들이 노드1에서 돌아가고 있는 상태에서 노드1이 다운이 되었어요. 그럼 직접 만들어진 Pod도 장애가 발생하고, 해당 서비스는 더이상 유지가 안됩니다. 근데 이렇게 컨트롤러에 의해서 만들어진 Pod들은 문제가 발생하면 다른 노드에 재생성되기 때문에 서비스는 유지가 됩니다. Replicas에서 만들어진 Pod는 일을 하지 않으면 다시 Pod를 Restart 시켜주어 서비스가 유지되어야 하는 목적으로 사용해야 합니다.

 

 Job

: Job으로 만들어진 Pod는 프로세서가 일하지 않으면 Pod가 종료됩니다. 이때 종료의 의미는 Pod 삭제가 아니라 자원을 사용하지 않는 상태로 멈춰 있다는 건데, 해당 Pod 안에 들어가서 로그를 확인할 수 있습니다.

 

 CronJob

: CronJob은 이런 Job들을 주기적인 시간에 따라서 생성을 하는 역할을 하는데 대체로  이 Job을 하나 단위로 사용하지 않고 CronJob을 만들어서 특정 시간에 반복적으로 실행할 목적으로 사용이 됩니다.

 

1) 매일 새벽마다 정기적으로 데이터 백업

2) 주기적인 업데이트 확인

3) 예약 메일과 sms 같이 메세지 발송하는 작업 등

 

 * Recreate, Restart의 차이 : Recreate Pod를 다시 만들어주기 때문에 Pod의 이름과 IP들이 변경됩니다. 하지만 Restart Pod내 컨테이너만 재기동 시켜줍니다.

 

 

 

 

DaemonSet

: Selector와 Template이 있어 모든 노드에 Pod를 만들고, Selector와 Label로 DaemonSet과 연결이 됩니다. 만약 노드들의 os종류가 달라서 위처럼 Label들이 붙어 있다고 가정하고, 데몬셋에 있는 Pod는 ubuntu에서 실행이 불가하기 때문에 노드3에는 설치하지 않고 싶을 때 이렇게 Pod에 node selector라고 지정을 해주면 이 라벨이 없는 노드에는 Pod가 생성되지 않습니다. 이렇게 DaemonSet은 한 노드에 하나를 초과해서 Pod를 만들 수 없지만, 노드에 Pod를 안만들 수는 있습니다.

 

 그리고 특정 노드로 접근했을 때 이 노드에 들어있는 Pod의 접근이 되도록 많이 사용하는데, 예전 Service 짚고 넘어갈 때 위처럼 노드 타입의 서비스를 만들고 externalTrafficPolicy 옵션을 추가하면 특정 노드에 노드 포트로 접근하면 트래픽은 Service로 가고, Service가 해당 노드에 Pod와 연결되도록 하는 걸 해봤습니다. 이렇게도 사용할 수 있는데, HostPort라고 해서이를 설정하면 노드에 있는 포트가 Pod로 연결이 돼서 똑같은 결과를 얻을 수 있습니다. 

 

 

Job

: Selector, Template이 있고 Template는 특정 작업만 하고, 종료가 되는 일을 Pod들을 담게 됩니다. Selector는 직접 만들지 않아도 Job이 알아서 만들어줍니다. 그래서 Template을 가지고 일반적으로 하나의 Pod를 생성하고 그 Pod가 일을 다하면 Job도 종료가 되지만 completions라고 위처럼 6을 주면 6개의 Pod를 하나씩 순차적으로 실행시켜서 모두 작업이 끝나야 Job도 종료가 됩니다. 또한 parallelism이라고 2를 주면 2개씩 Pod가 생성이 되고, ActiveDeadlineSeconds 30을 주면 해당 Job은 30초 후에 기능이 정지해버립니다.

 

 그리고 실행되고 있는 모든 Pod들은 삭제가 됩니다. 아직 실행하지 못한 Pod들도 앞으로 실행이 안됩니다. ActiveDeadlineSeconds는 어떨때 쓰냐면 만약 제가 10초 걸릴 일에 Job을 만들었는데 30초가 되도록 작업이 끝나지 않으면 뭔가 문제가 있는거고, 그럴 경우 Pod를 삭제해서 자원을 Release하고 더이상 작업을 진행하지 않도록 설정을 할 때 사용이 됩니다.

 

 

CronJob

: Job Template이 있어서 이 내용을 통해서 Job을 만들어 주고 스케줄이 있어서 이 시간을 주기로 Job을 만드는데 이 포맷은 흔히 사용하는 크론 포멧입니다. 위는 1분에 1개 Job을 만든다는 의미, 이렇게 1분 간격으로 Job이 생성되고 Job은 또 자신의 역할인 Pod를 만들게 됩니다. concurrencyPolicy라는 기능이 있는데 Allow, Forbid, Replace 3가지 옵션이 있습니다. 일반적으로 policy를 설정하지 않으면 Allow가 Default 입니다.  이러한 옵션들로 인해 CronJob은 Job을 더 정교하게 다룰 수 있고, 이 밖에 실행중인 Job을 일시 정지시키는 작업이나 Manual, Trigger 하는 부분이 있는데 이것은 실습 때 해보도록 하겠습니다.

 

1) Allow

: 예시로 1분 간격으로 스케줄을 한다고 설정했을 때 1분이 되면 Job이 만들어지고 Pod가 생성됩니다. 2분이 됐을 때 미리 만들어진 Pod가 Running or 종료 됐건 간에 상관없이 자신의 스케줄 타임이 되면 또 새로운 Job을 만들고 Pod가 생깁니다. 3분째도 같습니다.

 

2) Forbid

: 1분이 됐을 때 Job이 생성되지만, 2분이 됐을 때까지 이 Pod가 종료되지 않고 실행한다면, 이때 이 2분째 생겨야 하는 Job은 Skip이 됩니다. 그리고 Pod가 종료되는 즉시 다음 스케줄 타임에 있는 Job이 만들어집니다.

 

3) Replace

: 위처럼 1분에 Job이 만들어졌고, 2분 스케줄이 됐는데, 1분에서 생성된 Pod가 Running 중이라면 새로운 Pod를 만들어서 1분의 Job에 연결해 교체합니다. 2분이 됐을 때 새로운 Job은 생기지 않고, 새로운 파드가 생기면서 이전 스케줄 때 만들었던 Job이 연결이 됩니다. 만약에 2분째 Pod가 자신의 스케줄 타임에 종료가 됐다면, 3분 스케줄이 됐을 때 새로운 Job이 만들어지고 Pod가 생성됩니다.