Kubernetes

23.8.31(목) 쿠버네티스 5일차

사실 나도 모름 2023. 9. 1. 13:17

https://kubernetes.io/ko/docs/concepts/workloads/

 

워크로드

쿠버네티스에서 배포할 수 있는 가장 작은 컴퓨트 오브젝트인 파드와, 이를 실행하는 데 도움이 되는 하이-레벨(higher-level) 추상화

kubernetes.io

쿠버네티스에서 구동되는 애플리케이션이며 파드를 생성 및 관리

 

쿠버네티스에서는 워크로드를 일련의 파드 집합 내에서 실행

쿠버네티스에서 Pod 는 클러스터에서 실행 중인 컨테이너 집합을 의미함

 

 

ReplicationController

cat<<EOF>rc-nginx.yaml
apiVersion: v1
kind: ReplicationController
metadata:
  name: rc-nginx
spec:
  replicas: 3
  selector:
    app: webui
  template:
    metadata:
      name: nginx-pod
      labels:
        app: webui
    spec:
      containers:
      - name: nginx
        image: nginx:1.14
        ports:
        - containerPort: 80
          protocol: TCP
        - containerPort: 443
          protocol: TCP
EOF

 

 

 

https://kubernetes.io/ko/docs/concepts/overview/working-with-objects/labels/

 

레이블과 셀렉터

레이블 은 파드와 같은 오브젝트에 첨부된 키와 값의 쌍이다. 레이블은 오브젝트의 특성을 식별하는 데 사용되어 사용자에게 중요하지만, 코어 시스템에 직접적인 의미는 없다. 레이블로 오브

kubernetes.io

matchExpressions:
{key: version, operator: In, value: ["2.1","2.2"] # 2.1 or 2.2인것
{key: version, operator: NotIn, value: ["2.1","2.2"] # 2.1 or 2.2가아님
{key: version, operator: Exist} # 버젼이 존재하기만 하면
{key: version, operator: DoesNotExist}

 

 

 

Deployment와 ReplicaSet

둘의 차이는 거의 없다. 요약하면, DeploymentReplicaSet 위에 추상화된 레이어로서 애플리케이션 배포 및 롤링 업데이트를 관리하기 위한 용도로 사용된다. DeploymentReplicaSet을 생성하고 관리하면서 업데이트 전략을 통해 파드 업데이트를 처리한다. ReplicaSet은 파드 복제본을 일정한 수로 관리하는 데 사용되며, 주로 Deployment이나 다른 컨트롤러 리소스를 통해 관리된다.

cat<<EOF>rs-nginx-g1.yaml
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
        image: nginx:1.14
        ports:
        - containerPort: 80
        - containerPort: 443
          protocol: TCP
EOF
cat<<EOF>dep-nginx-g1.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: dep-nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: webui
  template:
    metadata:
      name: nginx-pod
      labels:
        app: webui
    spec:
      containers:
      - name: nginx
        image: nginx:1.14
        ports:
        - containerPort: 80
        - containerPort: 443
          protocol: TCP
EOF
# yaml 파일 실행시키는 명령
k apply -f [파일명]

# dep-nginx에서 nginx의 버전을 1.14.2로 수정하는 명령
k set image deploy/dep-nginx nginx=nginx:1.14.2 --record

# ??
k rollout history deploy/dep-nginx

# 리소스 정보 수정
k set resources deploy/dep-nginx --limits=cpu=1000m,memory=128Mi
k describe deploy dep-nginx # 세부정보확인

 

 

 

배포전략

Rolling : 기존의 두개의 컨테이너가 운영되고 있을 때 버전을 수정하려고 하면 하나씩 삭제하고 새버전을 만들며 모든 컨테이너의 버전을 수정하는 전략

  • 만약 한대가 버전 업그레이드 할 때 한대가 모든 처리를 감내할 수 있다고 판단되면 사용하는 전략

Blue/Green : 기존의 컨테이너(Blue)를 그대로 두고 새 버전의 두개의 컨테이너(Green)를 추가로 더 생성한 후 연결을 한번에 바꾸고 기존 컨테이너를 제거하는 전략

  • ???

Canary : 새로운 버전을 먼저 배포하고 기존의 컨테이너에 모든 처리와 부하를 줬다가 천천히 처리와 부하를 새로 배포한 컨테이너쪽으로 증가시키며 새 버전에 처리와 부하가 100%가 될 때까지 지속하고 그래도 안정적이고 안전하다고 판단되면 기존의 컨테이너를 제거하여 운영하는 전략

cat<<EOF>dep-nginx-g1.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: dep-nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  progressDeadlineSeconds: 600
  revisionHistoryLimit: 10
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14
        ports:
        - containerPort: 80
EOF
# pods의 상세정보를 실시간으로 변할 때마다 표시하는데 백그라운드에서 실행시키기
k get pods -o wide --watch &

# nginx의 버전을 1.15로 업데이트하고 롤아웃 상태를 표시해주는 명령 
k set image deploy/dep-nginx nginx=nginx:1.15 --record ; k rollout status deploy/dep-nginx

# 롤아웃 내역을 표시
k rollout history deploy/dep-nginx

# nginx의 버전을 1.16로 업데이트하고 롤아웃 상태를 표시해주는 명령 
k set image deploy/dep-nginx nginx=nginx:1.16 --record ; k rollout status deploy/dep-nginx

# nginx의 버전을 1.17로 업데이트하고 롤아웃 상태를 표시해주는 명령 
k set image deploy/dep-nginx nginx=nginx:1.17 --record ; k rollout status deploy/dep-nginx

k rollout history deploy/dep-nginx

# 롤아웃 내역을 기반으로 4번째 실행했던 명령을 다시 실행하는 명령 : 이는 버전을 1.17에서 무슨 이유로 마음에 안들어서 1.16으로 다시 되돌리는 명령
k rollout undo deploy/dep-nginx --to-revision=4
k rollout history deploy/dep-nginx

 

 

 

DaemonSet

전체 노드 중에 각각의 노드마다 하나의 pod를 배치시키는 것 replica가 필요없으며 node의 개수가 곧 pod의 수

cat<<EOF>dae-nginx-g1.yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: dae-nginx
spec:
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14
        ports:
        - containerPort: 80
EOF

node3을 suspend하고 위 yaml코드를 실행시키면 두개의 pod만 생성된다.

node3을 다시 start 시키면 pod하나가 더 실행된다.

 

 

 

StatefulSet

pod이름이 고정되고 pod의 볼륨에 모두 연결된다.

nfs 필수 nfs로 pv, pvc 생성해야함

/html 과 /data 디렉토리를 만들어준다.

 

mkidr -m 777 {html,data}

cat<<EOF>st-nginx-g1.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-pv
spec:
  capacity:
    storage: 10Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteMany
  storageClassName: manual
  persistentVolumeReclaimPolicy: Recycle
  nfs:
   server: 192.168.108.20
   path: /html
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nfs-pvc
spec:
  accessModes:
    - ReadWriteMany
  volumeMode: Filesystem
  resources:
    requests:
      storage: 2Gi
  storageClassName: manual
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: st-nginx
spec:
  replicas: 3
  serviceName: st-nginx
  podManagementPolicy: OrderedReady # OrderedReady 순차 / Paraller 병렬
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14
        ports:
        - containerPort: 80
        volumeMounts:
        - mountPath: /usr/share/nginx/html
          name: pvc-volume
      volumes:
      - name: pvc-volume
        persistentVolumeClaim:
          claimName: nfs-pvc
EOF
# replicas의 값을 5로 변경 
k scale statefulset st-nginx --replicas=5

 

 

 

 

미니 프로젝트

Blue/Green 전략을 이용하여 배포하는 yaml 코드를 생성하여 pod를 만들어 운영

 

blue-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: blue-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: blue-app
  template:
    metadata:
      labels:
        app: blue-app
    spec:
      containers:
      - name: nginx
        image: nginx:1.14
        ports:
        - containerPort: 80

kubectl apply -f blue-deployment.yaml

 

service.yaml

apiVersion: v1
kind: Service
metadata:
  name: app-service
spec:
  selector:
    app: blue-app  # Initially points to the blue deployment
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80

kubectl apply -f service.yaml

 

green-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: green-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: green-app
  template:
    metadata:
      labels:
        app: green-app
    spec:
      containers:
      - name: nginx
        image: nginx:1.15  # New version
        ports:
        - containerPort: 80

kubectl apply -f green-deployment.yaml

 

kubectl patch svc app-service -p '{"spec":{"selector":{"app":"green-app"}}}'

 : service 타입의 파드의 app-service의 내용 중 spec의 selector의 app에서 값을 green-app으로 바꿔라

 

먼저 Blue 환경을 배포한 후, Green 환경으로 업데이트하고 서비스를 전환

'Kubernetes' 카테고리의 다른 글

23.9.1(금) 쿠버네티스 6일차  (0) 2023.09.01
23.8.25(금) 쿠버네티스 1일차  (0) 2023.09.01
23.8.28(월) 쿠버네티스 2일차  (0) 2023.09.01
23.8.29(화) 쿠버네티스 3일차  (0) 2023.09.01
23.8.30(수) 쿠버네티스 4일차  (0) 2023.09.01