잡다한기술블로그

CronJob

• CronJob안에 Job 컨트롤 기능 포함
  • 사용자가 원하는 시간에 Job 실행 예약 지원
  • Job 컨트롤러로 실행할 애플리케이션 파드를 주기적으로 반복해서 실행
• Linux의 cronjob의 스케줄링 기능을 Job Controller에 추가한 API
• 반복해서 실행하는 Job을 운영해야 할 때 사용
  • Data Backup
  • Send email
  • Cleaning tasks
    • log file 정리
    • garbagage 제거
• CronJob을 통해 작업을 예약하려면 CronJob 포맷에 맞게 작업 예약시간을 걸어줘야 함
  • CronJob Schedule: " 0 3 1 * * "
    • Minutes (from 0 to 59)
    • Hours (from 0 to 23)
    • Day of the month (from 1 to 31)
    • Month (from 1 to 12)
    • Day of the week (from 0 to 6)

CronJob Schedule

CronJob Definition

CronJob Example

• 변수
  • concurrencyPolicy
    • Allow
      • Pod 동시 실행 가능
    • Forbid
      • Pod 동시 실행 금지
      • 실행 Pod 완료되면 다음 Pod 실행 (한 번에 하나씩 실행)
  • successfulJobsHistoryLimit
    • 완료된 Pod의 히스토리를 몇개 남길지 지정
  • startingDeadlineSeconds
    
    • 지정 시간 내에 Job을 실행하지 못하면 취소 시킴
• create -f를 통해 CronJob 실행
  
  • kubectl create -f cronjob-exam.yaml
• get을 통해  CronJob , Pod 확인
  
  • kubectl get cronjob
  • kubectl get pods
• delete를 통해 CronJob 삭제 
  • kubectl delete cronjob cronjob-exam

Reference

따배쿠22강

Job Controller

• Kubernetes는 pod를 running 중인 상태로 유지
  • 동작 후 5초뒤 종료하는 pod를 생성하면 동작과 종료를 계속 반복함 
• Batch 처리하는 Pod는 작업이 완료되면 종료됨
  • 백업을 하는 경우, 백업이 완료되면 종료되어야 함
• Batch 처리에 적합한 컨트롤러로 Pod의 성공적인 완료를 보장
  • 비정상 종료 시 다시 실행
  • 정상 종료 시 완료
    • 완료 시 pod가 삭제되는 것은 아님

Job Controller Definition

• Image가 배치 작업이어야 함
  • set up
  • garbage data clear
  • log 주기적 forwarding
• restartPolicy
  • Never
    • Pod restart
  • OnFailure
    • 컨테이너 restart

Job example

• 변수
  • completions
    • 실행해야 할 job을 몇 번 실행할지 지정
    • replicas와 비슷한 필드
  • parallelism
    • 동시 running되는 pod(job) 수
    • 병렬성
  • activeDeadlineSeconds
    • 지정 시간 내에 Job을 완료
• create -f를 통해 Job 실행
  
  • kubectl create -f job-exam.yaml
• get을 통해  Job , Pod 확인
  
  • kubectl get job
  • kubectl get pods
• delete를 통해 Container 종료
  
  • kubectl delete jobs.batch centos-job
• delete를 통해 Job 삭제 
  • kubectl delete job.apps centos-job

Reference

따배쿠 21강

StatefulSet

• Pod의 상태를 유지해주는 컨트롤러
  • Pod 이름
    • Pod는 생성될 때 random하게 hash값을 받아 생성 됨
    • Controller에 의해 Pod가 삭제되고 생성될 때 Pod 이름 보장 x
    • StatefulSet은 Pod의 이름을 보존
  • Pod의 볼륨(스토리지)

StatefulSet Definition

• Service 이름과 Pod이름을 연결시켜서 코어DNS 도메인 이름으로 사용

StatefulSet volume example

• create -f를 통해 StatefulSet 실행
  
  • kubectl create -f statefulset-exam.yaml
• get을 통해  StatefulSet, Pod 확인
  
  • kubectl get statefulset
  • kubectl get pods
• scale을 통해 scale down or up
  • kubectl scale statefulset sf-nginx --replicas=2
  • kubectl scale statefulset sf-nginx --replicas=4
• delete를 통해 DaemonSet 삭제
  
  • kubectl delete statefulsets.apps sf-nginx

StatefulSet RollingUpdate/RollBack

• Rolling Update
  • StatefulSet 편집 모드에 들어가 image 버전 변경
    • kubectl edit statefulsets.apps sf-nginx
    • image 버전 변경
• Roll Back
  • rollout undo 명령어 사용
    • kubectl rollout undo statefulsets.apps sf-nginx
    • rolling update 하기 전 버전으로 roll back 됨

Reference

따배쿠20강

DaemonSet

• 전체 노드에서 Pod가 한 개씩 실행되도록 보장
  • 워커 노드 추가 되면 Pod 한 개 추가
  • 워커 노드 삭제 되면 Pod 한 개 삭제
  • Pod에 문제가 생기면 Pod 삭제 후 새로 생성
• 로그 수입기, 모니터링 에이전트와 같은 프로그램 실행 시 적용

DaemonSet Definition

DaemonSet example

• create -f를 통해 DaemonSet 실행
  
  • kubectl create -f daemonset-exam.yaml
• get을 통해  DaemonSet, Pod 확인
  
  • kubectl get daemonset
  • kubectl get pods
• delete를 통해 DaemonSet 삭제
  
  • kubectl delete daemonsets.apps daemonset-nginx

DaemonSet RollingUpdate/RollBack

• Rolling Update
  • DaemonSet 편집 모드에 들어가 image 버전 변경
    • kubectl edit daemonsets.apps daemonset-nginx
    • image 버전 변경
• Roll Back
  • rollout undo 명령어 사용
    • kubectl rollout undo daemonset daemonset-nginx
    • rolling update 하기 전 버전으로 roll back 됨

Reference

따배쿠 19강

Deployment

• ReplicaSet을 제어해주는 부모 역할
  • ReplicaSet을 컨트롤해서 Pod수를 조절
• Deployment의 목적
  • Rolling Update & Rolling Back

Rolling Update란?

• 서비스의 중단 없이 버전을 업데이트 하는 것
  • pod 인스턴스를 점진적으로 새로운것으로 업데이트

Deployment definition

• Rolling Update 기능을 제외하면 ReplicaSet과 Deployment 똑같음

Deployment example

• create -f를 통해 Deployment 실행
  
  • kubectl create -f deploy-nginx.yaml
• get을 통해  Deployment, ReplicaSet, Pod 확인
  
  • kubectl get deployments
  • kubectl get rs
  • kubectl get pods
•  Deployment 생성 -> Deployment가 ReplicaSet 생성 -> ReplicaSet이 Pod 생성
  • pod 지우면 Replicaset이 보장 수에 맞게 pod 생성
  • Replicaset 지우면 pod&Replicaset 삭제 -> Deployment가 Replicaset 생성, Replicaset이 pod 생성
  • Deployment 지우면 세개 모두 삭제

Deployment Rolling Update & Rolling Back

• Rolling Update
  • rolling update 커맨드 
    • kubectl set image deployment <deploy_name> <container_name>=<new_version_image> --record
    • --record는 업데이트 과정을 history로 기록하는 옵션

• Controlling Rollling Update
  • rolling update 상태 확인
    • kubectl rollout status deployment <deploy_name>
  • rolling update 일시정지/재시작 
    • kubectl rollout pause/resume deployment <deploy_name>
• RollBack
  • rolling update 히스토리 확인
    • kubectl rollout history deployment <deploy_name>
  • 바로 전단계 버전으로 rollback
    
    • kubectl rollout undo deploy <deploy_name>
  • 특정 시점 전단계 버전으로 rollback
    • kubectl rollout undo deploy <deploy_name> --to-revision=3
    • --to-revision은 revision 값으로 롤백하는 옵션
    • 3번 시점 버전으로 rollback 할경우 history에 3번 시점 사라지고 3번시점은 버전은 현재시점+1 시점의 버전이 됨
      • history에 1, 2, 3, 4, 5가 있을 때, 3으로 롤백할 경우 3번 사라지고 6번이 3번 버전이 되어 history에 1,2,4,5,6이 남게 됨

Rolling Update Deployment Example

• revisionHistoryLimit
  • history 제한 수
• progressDeadlineSeconds
  • 해당 시간동안 업데이트 못하면 업데이트 취소
• maxSurge
  • 롤링 업데이트시 최대 pod개수
    • replicas(=3)의 25%(0.75)를 반올림한 값(1)을 replicas(3)에 더한 값(4)
    • 값이 클수록 업데이트 속도 빠름
    • 얼마나 빠르게 업데이트 할 것인지 커스터마이징 가능
• maxUnavailable
  • 터미네이팅 조절
• annotations
  • 쿠버네티스의 동작방식 컨트롤 서포트
  • yaml파일을 이용하여 업데이트 시키는 방법
  • yaml파일을 편집하여 version 변경하고 apply를 통해 업데이트

Reference

따배쿠 18강

ReplicaSet

• ReplicationController와 같은 역할을 하는 컨트롤러
  • 성격 = pod의 개수 보장
• ReplicationController보다 풍부한 selector

• matchLabels 연산자 까지는 ReplicationController와 동일
  • key:value
• matchExpressions 연산자
  • In: key와 values를 지정하여 key, value가 일치하는 Pod만 연결
  • NotIn: key는 일치하고 value는 일치하지 않는 Pod에 연결
  • Exists: key에 맞는 label의 Pod를 연결
  • DoesNotExist: key와 다른 label의 Pod를 연결

ReplicationController/ReplicaSet Definition

ReplicaSet Selector Definition

ReplicationController vs ReplicaSet

• ReplicaSet은 풍부한 label selector을 보장해줌
  • In 이용하여 한개 또는 여러개의 version
    • - {key: version, operator: In, value:["2.1","2.2"]}
  • NotIn 이용하여 특정 version 제외 모든 version
    • - {key: version, operator: NotIn, value:["2.1","2.2"]}
  • Exists 이용하여 모든 version
    
    • - {key: version, operator: Exists}
  • NotExist 이용하여 모든 version 제외
    • - {key: version, operator: NotExists}

ReplicaSet Example

• create -f를 통해 ReplicationSet 실행
  
  • kubectl create -f rs-nginx.yaml
• get, describe rs를 통해 ReplicationSet 확인
  
  • kubectl get rs
  • kubectl describe rs rs-nginx
• edit, scale rs를 이용하여 보장 pod수 수평 확장&감소(scale-out & scale-down)
  
  • kubectl edit rs rs-nginx
  • kubectl scale rs rs-nginx --replicas=2
• kubectl delete를 이용하면 ReplicaSet과 Pod 같이 삭제 됨
  • ReplicaSet만 삭제하고 Pod는 유지하고 싶으면 --cascade=false 옵션 추가
    • --cascade=false 옵션: 연쇄 삭제 기능을 비활성화.(default=true)
    • kubectl delete rs rs-nginx --cascade=false
• edit을 통해 template의 image정보를 바꾸고 저장하면 컨테이너의 이미지가 당장 바뀌지 않고 기존의 pod가 삭제되고 새로운 pod가 template을 통해 생성될 때 반영 됨
  • 기존의 버전이 삭제되고 새로운 버전으로 변경되는 것을 rolling update 배포라고 함

Reference

따배쿠17강

Controller란

• Pod의 개수를 보장
  • 스케줄러는 파드를 노드에 알맞게 배치, 컨트롤러는 파드의 개수를 보장
  • 컨트롤러가 보장중인 파드 중 한개가 다운되어 수가 적어질 경우 컨트롤러가 파드를 하나 생성하여 보장 개수를 맞춰줌
  • 보장하는 Pod의 구분은 레이블을 이용

Controller 종류

Replication Controller

• 가장 기본적인 컨트롤러
• 요구하는 Pod의 개수를 보장하며 파드 집합의 실행을 항상 안정적으로 유지하는 것을 목표로 함
  • 요구하는 Pod의 개수가 부족하면 template를 이용해 Pod를 추가
  • 요구하는 Pod의 수 보다 많으면 최근에 생성된 Pod를 삭제
• 기본 구성
  • selector
  • replicas
  • template

• selector의 key: value에 해당하는 레이블을 갖는 컨테이너를 replicas 배포 갯수만큼 운영
  • 현재 운영 중인 key:value 해당 컨테이너가 배포 갯수보다 많으면 pod를 죽이고 적으면 pod 생성

Replication Controller 동작원리

• app:webui라는 label을 가지는 pod 실행 및 보장

Replication Controller Definition

• Pod 정의는 labels을 key:value의 형태로 넣을 수 있음
  • labels은 Pod를 구분하는 정보, 태그
• Replication Controller 정의는 selector이용하여 해당 label을 가진 pod를 replicas 수 만큼 보장하며 pod와 똑같은 형식을 template에 넣어 pod가 부족할때 template을 이용해 pod 생성

Replication Controller Example

• create -f를 통해 ReplicationController 실행
  
  • kubectl create -f rc-nginx.yaml
• get, describe rc를 통해 ReplicationController 확인
  
  • kubectl get rc
  • kubectl describe rc rc-nginx
• edit, scale rc을 이용하여 보장 pod수 수평 확장&감소(scale-out & scale-down)
  
  • kubectl edit rc rc-nginx
  • kubectl scale rc rc-nginx --replicas=2
• 컨트롤러의 보장 pod 수가 충족된 상황에서 같은 label의 pod가 생성되면 바로 삭제 됨
  • 보장 pod수가 넘을시 가장 최근에 생성된 pod 삭제 되므로
• edit을 통해 template의 image정보를 바꾸고 저장하면 컨테이너의 이미지가 당장 바뀌지 않고 기존의 pod가 삭제되고 새로운 pod가 template을 통해 생성될 때 반영 됨
  • 기존의 버전이 삭제되고 새로운 버전으로 변경되는 것을 rolling update 배포라고 함

Reference

따배쿠16강

환경변수

• Pod내의 컨테이너가 실행될 때 필요로 하는 변수
• 컨테이너 제작 시 미리 정의
  • NGINX Dockerfile의 예
    • ENV(환경변수) [환경변수 이름] [환경변수 값]
    • ENV NGINX_VERSION 1.19.2
    • ENV NJS_VERSION 0.4.3
• Pod 실행 시 미리 정의된 컨테이너 환경변수를 변경할 수 있음
  • 미리 정의된 환경변수를 입력한 기존의 환경변수 값으로 변경
  • 미리 정의된 환경변수를 입력한 새로운 환경변수 값으로 변경

환경변수 사용 예

• 환경변수 변경 여러개 작성 가능

Pod 구성 패턴의 종류

• Pod를 구성하고 실행하는 패턴
• multi-container Pod

• Sidecar Pod, Sidecar Container
  • 단독으로 혼자서 움직일 수 없는 pod의 형태
    • 웹 서버 컨테이너의 로그를 가져가 분석 or 작업 하는 컨테이너가 존재하는 형태
    • 로그를 만들어줘야지만 실행할 수 있는 형태의 pod
• Adapter Pod, Adapter Container
  • 밖에 있는 데이터를 가져와 컨테이너 안쪽(웹 서버)으로 서비스하는 형태
    • 모니터링 정보를 Adapter 컨테이너가 받아 웹 UI 컨테이너 포트를 통해 외부에 송출하는 형태
•  Ambassador Pod, Ambassador Container
  • 웹 서버가 만든 것을 받아 외부로 전달하는 형태
    • 고객이 접속한 데이터를 캐쉬로 분산시켜 보내는 형태

Reference

따배쿠15강

Pod에 리소스(cpu, memory) 할당하기

• pod에 리소스 제한을 하지 않으면 하나의 pod가 노드의 리소스를 전부 다 사용할 수도 있음
  • 같은 노드의 다른 pod는 사용할 리소스가 없을 수 있음
  • 특정 pod가 해킹당해 리소스를 다 잡아먹으면 다른 pod가 제대로 동작을 못하는 상황이 발생할 수 있음

Pod 리소스 요청 및 제한

• Resource Requests
  • 파드를 실행하기 위한 최소 리소스 양을 요청
• Resource Limits
  • 파드가 사용할 수 있는 최대 리소스 양을 제한
  • Memory limit을 초과해서 사용되는 파드는 종료(OOM Kill)되며 다시 스케줄링 됨

Resource 단위

• memory
  • Gib, Mib, Kib 등으로 표현
  • 1Gib = 1024Mib, 1Mib = 1Kib
• CPU
  • core, mc 등으로 표현
  • 1 core = 1000mc

Container Resource 설정 예

• • requests만 입력하면 pod에 requests만 포함
  • limits만 입력하면 pod에 limits와 동일하게 requests도 포함
  • 노드의 용량을 넘어서는 resouce를 request/limit하면 scheduling이 되지 않음

Reference

따배쿠14강

static Pod

• 특정 노드의 kubelet daemon에 의해 동작되는 Pod
  • API에게 요청 보내지 않음
• kubelet daemon이 관리하는 static pod directory(dir/)에 yaml파일을 저장하면 알아서 컨테이너 실행하고 yaml 파일 지우면 알아서 컨테이너 삭제
  
  • 보통 /etc/kubernetes/manifests/ 디렉토리가 static pod 디렉토리
  • 노드의 /var/lib/kubelet/config.yaml 파일안에서 static pod 디렉토리 확인 가능
  • /var/lib/kubelet/config.yaml 파일안의 static pod 디렉토리 수정시 kubelet deamon은 restart 필수
• 스케줄러가 pod를 생성할 노드를 정해주는 것이 아닌 사용자가 직접 지정 가능

Master node의 static pod

• 마스터 노드에도 kubelet deamon 존재
• 마스터 노드의 static pod 종류
  • kube-apiserver.yaml
  • etcd.yaml
  • kube-scheduler.yaml
  • kube-controller-manager.yaml
• 마스터 노드의 static pod에 다른 앱 파드 생성 yaml파일 저장시 마스터 노드가 아닌 다른 노드에서 pod생성됨

Reference

따배쿠13강

init container

• 앱 컨테이너 실행 전에 미리 동작시킬 컨테이너
• 본 컨테이너가 실행되기 전에 사전 작업이 필요한 경우 사용
  • 로그인 컨테이너가 실행되기 전 db에 접속하여 내용을 받아오는 사전 작업이 필요한 경우
  • 앱을 실행하기 전에 네트워크 점검이 필요한 경우 등
• init container가 모두 실행된 후에 앱 컨테이너를 실행

init container example

• init-myservice, init-mydb라는 init container와 myapp-container라는 메인 컨테이너를 만드는 yaml파일
• 메인 컨테이너는 init container가 모두 실행되어야 실행
• init-myservice, init-mydb는 제대로 동작되지 않으면 계속 'wating for myservice'라는 명령어 반복하며 실행되면 종료
• yaml파일로 pod 생성하면 init container가 실행되지 않아 메인컨테이너 실행 x

• 위와 같이 init container를 실행시키는 yaml파일을 만들어 실행
• init container가 실행되고 메인 컨테이너 실행

infra container(pause)

• Pod의 환경을 만들어주는 컨테이너
  • IP, Host name 등의 인프라를 관리하고 생성해주는 컨테이너
  • 인프라를 관리하는 컨테이너이므로 kubectl get pods에서 명시되지 않음
• Pod를 만들면 같이 생성, 삭제하면 같이 삭제

• pause 컨테이너 확인 방법
  • pod 실행 중인 노드 접속
    • ssh node
  • 동작중인 컨테이너 정보 확인
    • docker ps

Reference

따배쿠12강

Liveness Probe

• Pod가 계속 실행할 수 있음을 보장
• Pod의 Spec에 정의

• 주기적으로 80포트에 접속
  • 응답이 나오면 건강한 컨테이너로 판단
  • 응답이 나오지 않으면 건강하지 않는 컨테이너로 판단

Liveness Probe 매커니즘

• httpGet probe
  • 웹 서비스를 하는 컨테이너에 해당
  • 지정한 IP주소, port, path에 HTTP GET 요청을 주기적으로 보내 해당 컨테이너가 응답하는지 확인
  • 반환코드가 200이 아닌 값이 나오면 오류
  • 연속으로 세번 오류가 발생하면 컨테이너 죽임
  • 도커 hub에서 건강한 새 컨테이너를 받아 컨테이너 다시 시작

• tcpSocket probe
  • sshd 서비스를 하는 컨테이너에 해당
  • 지정된 포트에 TCP연결을 시도
  • 연속으로 세번 연결되지 않으면 컨테이너 죽임
  • hub에서 새 컨테이너 받아 다시 시작

• exec probe
  • 컨테이너에서 실행하고 싶은 명령어 (ex.컨테이너에 데이터가 있는지)
  • exec 명령을 전달하고 명령의 종료코드가 0이 아니면 컨테이너 다시 시작

Liveness Probe 매개변수

• periodSeconds: health check 반복 실행 시간(초)
• initialDelaySeconds: Pod 실행 후 delay할 시간(초)
  • pod 실행 후 처음 검사를 실행할때까지의 시간
• timeoutSeconds: health check후 응답을 기다리는 시간(초)
  • 설정 초가 지나도 응답이 없으면 실패로 가정
• successThreshold: health check의 결과를 성공으로 결정하는 기준
  • 2로 설정, 연속으로 2번 성공하면 건강한걸로 판단
• failureThreshold: health check의 결과를 실패로 결정하는 기준
  • 3으로 설정, 연속으로 3번 오류가 나오면 실패로 판단
• 매개변수 확인 & 수정
  • describe에서 Liveness Probe 매개변수 확인 가능
  • kubectl get pod nginx-pod-liveness -o yaml을 이용하여 매개변수 확인 & 복사하여 yaml 파일에서 매개변수 수정

Example

• 문제: 아래의 liveness-exam.yaml 파일에 self-healing 기능을 추가
  • 동작되는 Pod내의 컨테이너에 /tmp/healthy 파일이 있는지 5초마다 확인
  • Pod 실행 후 10초 후부터 검사
  • 성공횟수는 1번, 실패횟수는 연속 2번으로 구성

• 문제풀이

Reference

따배쿠11강