Controller

mingg·2024년 1월 30일
Controllerk8s쿠버네티스
0

쿠버네티스

목록 보기
4/9

Controller는 Pod의 개수를 보장한다.

ReplicationController

요구하는 파드의 개수를 보장하며 파드 집합의 실행을 항상 안정적으로 유지하는 것을 목표

→ 요구하는 파드의 개수가 부족하면 template을 이용해 파드를 추가,

→ 요구하는 파드의 수보다 많으면 최근 생성된 파드를 삭제

apiVersion: v1
kind: ReplicationController
metadata:
  name: myapp-rc
spec:
  replicas: 3
  selector:
    app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: nginx-container
        image: nginx:1.14

기본구성

  • selector → selector의 key:value 값을 보고 이러한 값을 가진 파드를
  • replicas → replicas 값만큼 실행해
  • template → 컨테이너 템플릿 부족하면 만들때 이 템플릿을 보고 여기에는 꼭 label에는 selector의 라벨을 꼭 포함하고 있어야한다.

ReplicationController는 이 세개만 보는거지 

#
kubectl create rc -exam --image=nginx --replicas=3 --selector=app=webui

api는 app=webui 라벨을 가진 파드를 3개 실행하게 된다. controller는 3개가 보장되게 계속 탐지

이렇게 delete pod시키면 알아서 replicaset에 맞춰 파드가 자동 생성되는 것을 볼 수 있다.

kubectl run redis --image=redis --labels=app=my-app --dry-run -o yaml > redis.yaml

같은 라벨을 가진 파드를 실행시킨다면?

실행이 안되고 바로 중지된다. controller에서는 라벨 확인을 하고 terminate시킴

kubectl edit rc my-app
# 위 명령어를 해서 replicas 값을 수정하거나 
# 아래 명령어처럼 수정해도 된다
kubectl scale rc my-app --replicas=2

Replicaset

replicationController와 같은 역할을 하는 컨트롤러

replicationController보다 풍부한 Selector

selector:
	matchLabels:
		key : value
	matchExpressions:
		{key: , operator: , values: }

matchExpressions 연산자

  • In : key와 values를 지정하여 key,value가 일치하는 pod만 연결
  • NotIn : key는 일치하고 value는 일치하지 않는 pod에 연결
  • Exists : key에 맞는 label의 pod를 연결
  • DoesNotExist : key와 다른 label의 pod를 연결

Replicaset도 파드의 개수를 보장하는데 replicationController와의 차이점은?

#selector안에 있는 조건은 AND!
ReplicationController
spec:
	replicas: 3
	selector:
		app: my-app
		version: "2.1"
templete:
~~

ReplicaSet
spec:
	replicas: 3
	selector:
		matchLabels:
			app: my-app
		matchExpressions:
		- {key: version, operator: In, value: ["2.1"]}
templete:
~~~

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: rs-nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: webui
  template:
    metadata:
      name: nginx-pod
      labels:
        app: webui
    spec:
      containers:
      - name: nginx-container
        image: nginx:1.14

kubectl delete rs rs-nginx --cascade=false

—cascade=false가 없으면 해당 rs의 파드도 함께 사라지는데 이 옵션 붙여주면 파드는 삭제 안됨.

Deployment

replicaset을 제어해주는 부모 역할 → 디플로이먼트가 레플리카셋을 컨트롤하고 레플리카셋은 파드를 컨트롤하는 거

apiVersion: apps/v1
kind: Deployment
metadata:
  name: deploy-nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: webui
  template:
    metadata:
      name: nginx-pod
      labels:
        app: webui
    spec:
      containers:
      - name: nginx-container
        image: nginx:1.14

Rolling update를 위해 만들어 졌다,

Replicaset을 컨트롤해서 pod의 수를 조절한다.

Rolling Update: 파드를 점진적으로 새로운 것으로 업데이트하여 디플로이먼트 업데이트가 서비스 중단없이 이루어지도록 해줌. 

kubectl set image deployment [deploy name] [container name]=[new version image]

RollBack 

kubectl rollout history deployment [deploy name]
kubectl rollout undo deploy [deploy name]
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-deploy
spec:
  selector:
    matchLabels:
      app: webui
  replicas: 3
  template:
    metadata:
      labels:
        app: webui
    spec:
      containers:
      - image: nginx:1.14
        name: web
        ports:
        - containerPort: 80
kubectl create -f deploy-test.yaml --record
kubectl get deployment,rs,pod,svc

# rolling update
kubectl set image deploy app-deploy web=nginx:1.15 --record
# controlling rolling update
kubectl rollout pause deploy app-deploy
kubectl rollout resume deploy app-deploy
kubectl rollout status deploy app-deploy


# rollback
kubectl rollout history deployment app-deploy # 이전 업데이트 기록을 볼 수 있어 그래서 record 옵션을 꼭 쓰는것!
kubectl rollout undo deployment app-deploy # 그 이전 버전으로 rollback
kubectl rollout undo deployment app-deploy --to-revision=[돌아가고 싶은 revison 번호로]

Untitled

apiVersion: apps/v1
kind: Deployment
metadata:
  name: deploy-nginx
  annotations:
    kubernetes.io/change-cause: version 1.15
spec:
  progressDeadlineSeconds: 600
  revisionHistoryLimit: 10
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  replicas: 3
  selector:
    matchLabels:
      app: webui
  template:
    metadata:
      labels:
        app: webui
    spec:
      containers:
      - name: web
        image: nginx:1.15
        ports:
        - containerPort: 80

maxSurge를 통해서 업데이트를 얼마나 빨리 할지 커스텀할 수 있다.

maxsurge가 25%인것은 replicas*0.25 의 값에서 반올림한 값

예를들어 replicas가 3이고 maxsurge가 50%인것은

3 * 0.5 = 1.75 → 2 ⇒ 3+2개의 파드

업데이트 할때 5개까지 러닝중인것을 유지하는거지!

maxUnavailable : terminating하는 파드의 개수를 조절하는 것.

annotation → yaml파일로 업데이트 시키는 방법

kubectl create -f [yaml파일]
vi -> annotations 버전 변경
kubectl apply -f [yaml파일]

DaemonSet

노드당 하나의 파드를 보장해준다,

로그 수입기, 모니터링 에이전트와 같은 프로그램 실행시 적용한다.

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: daemonset-nginx
spec:
  selector:
    matchLabels:
      app: webui
  template:
    metadata:
      name: nginx-pod
      labels:
        app: webui
    spec:
      containers:
      - name: nginx-container
        image: nginx:1.14

하나만 보장하니깐 replicas는 필요가 없다~

kubeadm token list
kubeadm token create --tth[시간]

토큰은 일정 시간이 지나면 삭제 되서 생성해줘야함

그럼 새로운 워커 노드에 토큰만 바꿔서 join하면됨.

마스터 노드에서 daemon set을 설정하면 마스터노드에 연결된 모든 워커노드에 deamonset 파드가 하나씩 생기는데 위 코드처럼 추가하면 추가한 노드에도 하나의 파드를 보장해준다.

daemonset도 edit하면 rolling update가 된다. rollback도 마찬가지

StatefulSet

파드의 상태를 유지해주는 컨트롤러

파드의 이름과 볼륨(저장소)을 유지해준다. 

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: sf-nginx
spec:
  replicas: 3
  serviceName: sf-service
#  podManagementPolicy: OrderedReady 순차적으로 만듦 
  podManagementPolicy: Parallel
  selector:
    matchLabels:
      app: webui
  template:
    metadata:
      name: nginx-pod
      labels:
        app: webui
    spec:
      containers:
      - name: nginx-container
        image: nginx:1.14

kubectl scale statefulset sf-nginx --replicas=

scale up하면 다음 번호가 생성 down하면 그 마지막 번호가 삭제됨

JobController

쿠버네티스는 파드를 running중인 상태로 유지

batch 처리하는 파드는 작업이 완료되면 종료됨

batch 처리에 적합한 컨트롤러로 파드의 성공적인 완료를 보장

→ 비정상 종료 시 다시 실행하고 정상종료되면 완료시킨다. 

apiVersion: batch/v1
kind: Job
metadata:
  name: centos-job
spec:
#  completions: 5
#  parallelism: 2
  activeDeadlineSeconds: 5
  template:
    spec:
      containers:
      - name: centos-container
        image: centos:7
        command: ["bash"]
        args:
        - "-c"
        - "echo 'Hello World'; sleep 25; echo 'Bye'"
      restartPolicy: Never
#      restartPolicy: OnFailure
#  backoffLimit: 3
  • completions : 실행해야할 job의 수가 몇개인지 지정. replicas랑 비슷
  • parallelism : 병렬성, 동시 running되는 파드 수
  • activeDeadlineSeconds : 지정 시간 내에 job을 완료. 지정 시간 지나면 강제로 종료
  • restartPolicy: Never vs restartPolicy: OnFailure
    • onFailure : 실패하면 컨테이너를 재실행
    • backoffLimit: 기본은 6번 이 값보다 컨테이너 restart 실패하면 파드 삭제
    • Never : pod 재실행
# centos 이미지를 실행하고 실행된 파드 내에서 sleep 5 커멘드 실
kubectl run testpod --image=centos:7 --command sleep 5

CronJob

사용자가 원하는 시간에 job을 실행하게 해주는 예약기능

job 컨트롤러로 실행할 application pod를 주기적으로 반복해서 실행

Linux의 cronjob의 스케줄링 기능을 job controller에 추가한 API

data backup, send email, cleacing task 같이 반복적으로 실행하는 job을 운영할 때 사용

cronjob schedule

ex) 0 3 1 * * → 매월 1일 새벽 3시에 job을 실행하라!

          • → 1분에 1번씩 job을 실행하라!

/5 * * * → 5분에 1번씩 job을 실행하라!

  • minute (0~59)
  • hours (0~23)
  • Day of the month (1~31)
  • Month (1~12)
  • Day of the week (0~6) 6 = saturday 주중 : 1-5 주말 0,6
apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: cronjob-exam
spec:
  schedule: "* * * * *"
  startingDeadlineSeconds: 500
#  concurrencyPolicy: Allow
  concurrencyPolicy: Forbid
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busybox
            args:
            - /bin/sh
            - -c
            - echo Hello; sleep 10; echo Bye
          restartPolicy: Never
  • startingDeadlineSeconds : 해당 시간마다 해당 job을 실행시키지 못하면 취소
  • concurrencyPolicy
    • concurrencyPolicy: Allow 이게 기본값. 한번에 여러 job이 동작되어도 괜찮다~
    • concurrencyPolicy: Forbid 작업을 한번에 한개씩
profile
mingg
혼자 이것저것 해보는걸 즐깁니다..!
이전 포스트

Namespace , pod

다음 포스트

Service

0개의 댓글