- 파드(Pods)
- 디플로이먼트(Deployment)
- 레플리카셋(ReplicaSet)
- 잡(Job)
- 크론잡(CronJob)
- 데몬셋(DaemonSet)
- 스테이트풀셋(StatefulSet)
0. yaml파일 생성 후, kubectl 에서 명령어로 실행
kubectl apply -f ____.yaml
+ 예시 yaml 은 쿠버네티스 공식문서 - 워크로드 리소스 부분 참고
1. 파드(Pods)
pod .yaml
apiVersion: v1
kind: Pod
metadata:
name: nginx #kubectl get pod 하면 나오는 이름
labels: #pod의 레이블, 레이블은 필수값 아님
runs: nginx
spec: # 배포할 컨테이너에 대한 값, Pod에서 호출할 컨테이너 이미지 지정
containers:
- name: nginx
image: nginx
2. 디플로이먼트(Deployment)
deployment.yaml
apiVersion: apps/v1 #Pod는 v1인데, Deploy는 apps/v1 인것 확인
kind: Deployment
metadata:
name: nginx-deployment #kubectl get deploy로 조회되는 이름
labels:
app: nginx #deploy의 레이블
spec:
replicas: 3 #pod를 몇 개 생성 할 지
selector: #selector는 template와 연결됨
matchLabels:
app: nginx
template: #일반적으로 Pod 구조와 같다. pod를 똑같이 여러개 만들기 > 템플릿
metadata:
labels:
app: nginx #selector.matchLables.app = template.metadata.labels.app
spec:
containers:
- name: nginx
image: nginx
3. 레플리카셋(ReplicaSet)
replicaset.yaml
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: frontend
labels:
app: guestbook
tier: frontend
spec:
# 케이스에 따라 레플리카를 수정한다.
replicas: 3
selector:
matchLabels:
tier: frontend
template:
metadata:
labels:
tier: frontend
spec:
containers:
- name: php-redis
image: gcr.io/google_samples/gb-frontend:v3
yaml 파일을 살펴보니 kind가 ReplicaSet으로 명시된 것 이외에는 Deployment와 거의 동일한 정보를 가지고 있다.
deployment는 replicaset보다 상위 개념이다.
1) ReplicaSet 선언, Deployment 선언 한 뒤
- kubectl get deployment.apps > Deployment만 조회됨
- kubectl get replicasets.apps > ReplicaSet, Deployment 모두 조회됨
2) Deployment delete한 뒤에 ReplicaSet 도 삭제해야한다.
ReplicaSet의 존재 이유 : 컨테이너 버전을 업데이트 할 때, Deploy는 그대로 있는 상태에서 ReplicaSet 이 replica를 조절하면서 pod를 업데이트 하기 때문
4. 잡(Job)
job.yaml
apiVersion: batch/v1
kind: Job
metadata:
name: pi
spec:
template:
spec:
containers:
- name: pi
image: perl:5.34.0
command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
restartPolicy: Never #반복실행 진행하지 않는다. 기본값은 "문제가 있으면 언제나 다시 시작한다" 임
backoffLimit: 4
job에는 필수적으로 넣는 요소 restartPolicy: Never
기본값은 always인데 job의 특성상 한 번 실행하고 발생한 로그를 보존해야 job이기 때문
(다시 실행하면 로그는 날아갈 것)
실패하는 경우 다시 구동하고자 할 때는 "OnFailure"
job spec 설정
1)병렬 실행
1-1) completions : 3
job실행 > job 실행 > job 실행
1-2) parallelism : 3
동시에 3개의 pod 실행
2) 자동 종료
2-1) activeDeadLineSeconds: 30
job이 실행되고 30초 뒤에 종료
2-2) ttlSecondsAfterFinished: 30
job 이 모든 job이 일을 한 뒤에 30초 뒤에 종료
apiVersion: batch/v1
kind: Job
metadata:
name: pi
spec:
ttlSecondsAfterFinished: 30 # 언급한 4개의 옵션은 이 위치에서 설정
template:
spec:
containers:
- name: pi
image: perl:5.34.0
command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
restartPolicy: Never
backoffLimit: 4
5. 크론잡(CronJob)
apiVersion: batch/v1
kind: CronJob
metadata:
name: pi
spec:
schedule: "* * * * *"
successfulJobsHistoryLimit: 10 #10회까지 job 보존하고 싶을 때 이렇게 설정
jobTemplate:
spec:
template:
spec:
containers:
- name: pi
image: perl:5.34.0
command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
restartPolicy: Never
크론 규칙을 통해 스케쥴을 설정해서, 시간마다 반복적으로 job을 실행할 수 있도록 설정
successfulJobsHistoryLimit의 default값은 3회, 3회 초과시 기존 실행된 잡을 삭제해서 3회를 유지함
6. 데몬셋(DaemonSet)
daemonset.yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: fluentd-elasticsearch
namespace: kube-system
labels:
k8s-app: fluentd-logging
spec: #Demonset에서는 Deployment와 다르게 replicas를 선언하지 않음.
selector:
matchLabels:
name: fluentd-elasticsearch
template:
metadata:
labels:
name: fluentd-elasticsearch
spec:
tolerations:
# 이 톨러레이션(toleration)은 데몬셋이 컨트롤 플레인 노드에서 실행될 수 있도록 만든다.
# 컨트롤 플레인 노드가 이 파드를 실행해서는 안 되는 경우, 이 톨러레이션을 제거한다.
- key: node-role.kubernetes.io/control-plane
operator: Exists
effect: NoSchedule
- key: node-role.kubernetes.io/master
operator: Exists
effect: NoSchedule
containers:
- name: fluentd-elasticsearch
image: quay.io/fluentd_elasticsearch/fluentd:v2.5.2
resources:
limits:
memory: 200Mi
requests:
cpu: 100m
memory: 200Mi
volumeMounts:
- name: varlog
mountPath: /var/log
terminationGracePeriodSeconds: 30
volumes:
- name: varlog
hostPath:
path: /var/log
Demonset에서는 Deployment와 다르게 replicas를 선언하지 않는다.
worker node당 1개씩으로 이미 설정되어있기 때문
node마다 하나씩 배포되는 형태
7. 스테이트풀셋(StatefulSet)
statefulset.yaml
apiVersion: v1
kind: Service
metadata:
name: nginx
labels:
app: nginx
spec:
ports:
- port: 80
name: web
clusterIP: None
selector:
app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: web
spec:
selector:
matchLabels:
app: nginx # .spec.template.metadata.labels 와 일치해야 한다
serviceName: "nginx" #statefulSet의 필수 값
replicas: 3 # 기본값은 1
minReadySeconds: 10 # 기본값은 0
template:
metadata:
labels:
app: nginx # .spec.selector.matchLabels 와 일치해야 한다
spec:
terminationGracePeriodSeconds: 10
containers:
- name: nginx
image: registry.k8s.io/nginx-slim:0.8
ports:
- containerPort: 80
name: web
volumeMounts:
- name: www
mountPath: /usr/share/nginx/html
volumeClaimTemplates:
- metadata:
name: www
spec:
accessModes: [ "ReadWriteOnce" ]
storageClassName: "my-storage-class"
resources:
requests:
storage: 1Gi
serviceName을 꼭 입력해야함
상태를 가지고 독립적인 생태계를 꾸리는 스테이트풀셋(쿠버네티스 내에서 유일)
상태값을 유지하면서, 어떤 순서로 배포가 이루어진다고 미리 정해져있어서, 정확히 그 순서로 배포가 일어남.
순서를 가지고 배포하거나 고정된 이름이 필요한 애플리케이션에 적합하다.
레플리카 수를 늘리면 순차적으로 배포되었다가, 레플리카 수를 줄이면 역순으로 하나 씩 삭제된다.
'kubernetes' 카테고리의 다른 글
자주 쓰는 kubectl 명령어 (0) | 2023.08.17 |
---|---|
[k8s] kustomize로 애플리케이션 동적 배포 (0) | 2023.08.11 |
[k8s] pod를 원하는 node에 배정하는 설정 값 (0) | 2023.08.04 |