참고
컨트롤러
NOTE
쿠버네티스에서 컨트롤러는 클러스터의 상태를 관찰 한 다음, 필요한 경우에 생성/변경을 요청하는 컨트롤 루프이다!
상태 체크(Observer) → 차이점 발견(Diff) → 조치(Act)를 반복 (Controller에서 진행)
컨트롤 루프는 종료되지 않으면서 시스템 상태를 조절하는 루프이다.
•
컨트롤 루프는 컨트롤러를 실행시킨다.
•
모니터링, 상태 차이 발견, 액션 3가지 행위를 한다.
•
3가지 행위를 통해 의도와 상태가 같아지도록 만드는 역할을 한다.
컨트롤러의 종류
NOTE
컨트롤러는 쿠버네티스에서 자체적으로 제공되는 컨트롤러와 커스텀 컨트롤러로 구분된다!
마스터/워커 노드 실행위치에 따라 구분된다.
•
일반적인 컨트롤러는 마스터 노드에서 실행되지만 오퍼레이터에 의한 컨트롤러는 워커 노드에서만 실행된다. 이는 오퍼레이터가 워크로드로써 쿠버네티스 클러스터에 배포되기 때문이다.
•
컨트롤러 매니저는 컨트롤러의 리스트를 가지고 있으며, 각 오퍼레이터 컨트롤러는 컨트롤러 매니저의 컨트롤 루프에 추가된다.
표준 컨트롤러의 종류
NOTE
표준 컨트롤러는 크게 5종류가 있다!
표준 컨트롤러의 종류
Replica Set
NOTE
ReplicaSet ⇒ 여러개의 Pod을 관리하는 단위이다!
# 실행중인 레플리카 확인
kubectl get replicaset
kubectl get po,rs
# 실행중인 레플리카 상세확인
kubectl describe replicaset myapp-replicaset
# 레플리카 생성
kubectl create -f [replicaset 파일이름]
kubectl replace -f [replicaset 파일이름]
# 레플리카 크기 수정
kubectl scale --replicas=6 -f [replicaset 파일이름]
kubectl edit replicaset [replicaset 이름]
# 레플리카 삭제
kubectl delete -f [replicaset 파일이름]
Bash
복사
replica 관련 명령어
apiVersion: apps/v1
kind: ReplicaSet # ReplicaController(구버전)
metadata:
name: myapp-replicaset
labels:
app: myapp
spec:
selector: # ReplicaController => ReplicaSet 넘어오면서 추가된것
matchLabels: # metadata의 labels정보가 일치해야한다.
app: myapp
# 복제 포드 개수
replicas: 3
# 포드 정보
template:
metadata:
name: nginx-2
labels:
app: myapp
spec:
containers:
- name: nginx
image: nginx
YAML
복사
matchLabels ⇒ 어떤 pod를 관리할지 설정
만약 label의 정보가 app: myapp인 Pod를 생성할 경우, Replicaset의 selector와 중복처리 되는데 이경우 어떻게 동작할까?
# app- 를 지정하면 app label을 제거
kubectl label pod/[포드이름] app-
# 다시 Pod 확인
kubectl get pod --show-labels
Shell
복사
app: myapp 라벨 제거한다. (2 → 3 변경)
replica는 3개인데 1개의 pod가 새롭게 추가됨 (라벨제거로 2개가 되었다 판단)
# app=myapp label 추가
kubectl label pod/[포드이름] app=myapp
# 다시 Pod 확인
kubectl get pod --show-labels
Shell
복사
app: myapp 라벨을 다시 추가한다.
다시 3개로 돌아옴 (라벨이 돌아옴으로써 4 → 3 변경)
Deployment
NOTE
Deployment ⇒ ReplicaSet을 이용해 Pod를 업데이트하고 이력을 관리하여 롤백(rollback) 하거나 특정 버전(revision)으로 돌아갈 수 있다!
Deployment는 Replicaset를 더 편리하게 관리해줌! (배포나 롤백 등)
Deployment 생성흐름
# 실행중인 디플로이먼트 확인
kubectl get all
kubectl get po,rs,deploy
# 실행중인 디플로이먼트 상세확인
kubectl describe deployments [deployment 이름]
kubectl describe deploy/[deployment 이름]
# 디플로이먼트 생성
kubectl apply -f [deployment 파일이름]
# 디플로이먼트 삭제
kubectl delete -f [deployment 파일이름]
Bash
복사
Deployment 명령어
Deployment Rollout & history
Rollout은 Deployment를 생성하거나, 변경사항이 생길때 Rollout이 trigger되며 이를통해 컨테이너를 점진적으로 배포하거나 업그레이드하고 내역을 기록한다.
# 디플로이먼트 이미지 수정(--record가 있어야 histroy에서 확인가능)
kubectl set image deployment/[deployment 이름] \
<container-name>=<new-image>:<tag>
kubectl set image deployment/[deployment 이름] \
<container-name>=<new-image>:<tag> --record
# 롤링 업데이트 상태 확인
kubectl rollout status deployment/[deployment 이름]
kubectl describe deployment/[deployment 이름]
# 롤백
kubectl rollout undo deployment/[deployment 이름] # 이전버전
kubectl rollout undo deployment/[deployment 이름] \ # 특정버전
--to-revision=<revision-number>
# 내역확인
k rollout history deployment/[deployment 이름]
YAML
복사
업데이트, 히스토리 관련 명령어
Deployment - 배포 전략 설정
NOTE
Deployment는 다양한 방식의 배포 전략이 존재한다.
롤링 업데이트(Rolling Update)
구 버전을 하나 제거하고 새 버전을 하나 추가하는 과정을 반복한다.
재생성(Recreate)
기존 파드는 모두 삭제되고, 새로운 파드 생성 (다운타임이 존재!)
실제 사용(롤링 업데이트)
apiVersion: apps/v1
kind: Deployment
metadata:
name: echo-deploy-st
spec:
replicas: 4
selector:
matchLabels:
app: echo
tier: app
minReadySeconds: 5
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 3 # 동시에 생성할 수 있는 파드 수
maxUnavailable: 3 # 동시에 삭제할 수 있는 파드 수
template:
metadata:
labels:
app: echo
tier: app
spec:
containers:
- name: echo
image: ghcr.io/subicura/echo:v1
livenessProbe:
httpGet:
path: /
port: 3000
YAML
복사
3개씩 업데이트하게 수정함
데몬셋
NOTE
클러스터 전체(또는 특정) 노드에서 Pod를 실행할 때 사용하는 컨트롤러다!
쉽게 말하면, 각 노드에서 하나씩 존재하게 하는 Pod를 만든다고 생각하면 된다.
apiVersion: apps/v1
kind: DaemonSet
metadata:
labels:
app: elasticsearch
name: elasticsearch
namespace: kube-system
spec:
selector:
matchLabels:
app: elasticsearch
template:
metadata:
labels:
app: elasticsearch
spec:
containers:
- image: registry.k8s.io/fluentd-elasticsearch:1.20
name: fluentd-elasticsearch
YAML
복사
로깅을 위한 Daemonset 생성 (kind 이외에는 Deployment와 비슷함)
•
노드 당 1개씩의 Pod를 보장하는 컨트롤러이며 운영 중에 노드가 추가되면 노드 개수만큼 Pod를 추가한다.
•
보통 로그 수집기를 실행하거나 노드를 모니터링하는 등 클러스터 전체에서 항상 실행해두어야 하는 Pod에 사용된다.
•
대표적인 Pod로 kube-proxy가 존재한다.
StatefulSet
NOTE
StatefulSet은 Pod의 상태(이름, 저장소)를 유지해주는 컨트롤러를 의미힌다!
Pod를 생성할 때 Name뒤에 추가되는 문자는 랜덤으로 생성된 Hash값이다. 컨트롤러에 의해 만들어진 Pod는 이와같이 랜덤 해시 값이 붙은 형태로 Pod이름이 형성된다.
특정 Pod를 지우고 컨트롤러에 의해 다시 생성된 이름을 보면 다른 해시값을 가진다. 즉 Pod의 이름이 보장되지 않는다.
상태를 가진다는 의미!
주로 다음과 같은 상황에서 사용한다.
1.
안정적이고 고유한 네트워크 식별자: 각 파드는 고유한 이름을 가진다.
2.
안정적인 스토리지: StatefulSet은 Pv를 사용하여 각 파드안에 정적 스토리지를 제공한다.
3.
순사적, 예측가능한 롤링 업데이트
4.
순차적, 스케일링
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: nginx-statefulset
spec:
serviceName: "nginx"
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80
name: web
volumeClaimTemplates:
- metadata:
name: nginx-storage
spec:
accessModes: [ "ReadWriteOnce" ]
resources:
requests:
storage: 1Gi
YAML
복사