Resource 중간정리

지금까지 배운 내용을 간단하게 요약해보고, 앞으로 배울 내용을 정리해보는 중간 점검시간을 가져보자.

지금까지 배운 것

일반 Pod 리소스를 통한 Container를 K8S Cluster에 deploy하기였다. Pod 리소스를 생성할 때 우리는 여태까지 **deployment**라는 리소스를 생성시키는 방법을 사용하였다.

그리고 여기에 추가적으로 컨테이너에 스토리지를 마운트시키는 작업을 진행했다. Volume을 만들기 위해 PV 리소스를 생성시켜 준비하고,(인프라엔지니어가 하는 일) 이를 추상화해서 사용하기 위해 PVC 리소스를 생성했고, pod가 이용할 수 있게 deployment resource에 반영했다.

또한 일반정보 또는 중요정보를 컨테이너를 통해 실행되는 프로그램에서 이용할 수 있게 하고자 ETCD를 이용하여 스토리지가 준비되고, 이를 추상화해 사용하고자 ConfigMap, Secret 리소스를 생성했고, 이를 Pod가 이용할 수 있게 deployment 리소스에 환경변수 혹은 볼륨마운트 방식으로 반영했다!

앞으로 학습할 것

일반 Pod 리소스와 다른 특성의 Container deployment 방식을 알아보자.

Daemon set : 모든 worker node에 하나씩 배포되는 방식

특징

1. 클러스터의 모든 worker node에 하나씩 pod를 배포한다.
2. 로그 수집, 모니터링 에이전트, 네트워크 구성 등 노드별 작업을 수행할 때 사용된다.

기존과 다른 건..?

1. 일반 Deployment는 특정 개수의 Pod만 배포되지만, DaemonSet은 모든 노드에 Pod가 자동으로 배포된다.
2. Pod의 수가 노드의 수에 따라 동적으로 결정되므로 확장성에서 큰 차이를 가지게 된다.

Daemon set 이전에는 ,,

각각의 worker node에 pod가 하나씩만 돌아갔으면 좋겠는 상황일 때, 일반 deployment 혹은 replicaset을 사용하면 스케쥴러가 가장 적합한 노드를 찾아서 pod를 배포하는 방식이었다. 즉, 모든 노드에 하나씩 배포되는 것을 보장할 수 없었고, 관리자가 하나하나 수작업으로 하는 수밖에 없었다!

DaemonSet 컨트롤러의 작동 원리

daemonset은 컨트롤러에 의해 관리된다. 아래와 같은 방식으로 작동하게 된다.

1. 노드 상태 확인: Daemonset 컨트롤러는 클러스터의 모든 worker node 상태를 주기적으로 모니터링한다.
2. Pod 배포 요청: 각 노드에 pod가 없으면 스케쥴러에게 요청을 보내 “이 노드에 pod를 배치해줘” 라고 지시하고, 모든 노드에 정확하게 하나의 pod가 배치된다.
3. NodeAffinity와 연계: DaemonSet은 NodeAffinity를 사용해 특정 조건을 만족하는 노드에만 pod를 배치할 수도 있다.
4. Pod 생성 및 연결 정보 설정: Daemonset 컨트롤러는 각 pod를 생성하고, 어떤 노드에 배치되었는지 기록한다. pod가 생성될 때 해당 노드 정보를 nodeName 필드에 명시한다.

DaemonSet의 자동 복구 (시험문제)

1. Pod 손실: 특정 노드에서 pod가 삭제되거나 문제가 생기면, daemonset 컨트롤러가 주기적인 모니터링으로 이를 감지하고 다시 pod를 생성한다.
2. 노드 추가: 새로운 노드가 클러스터에 추가되면, Daemonset컨트롤러가 이를 감지하고 해당 노드에 pod를 자동으로 생성한다.

DaemonSet YAML

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: log-collector
spec:
  selector:
    matchLabels:
      app: log-collector
  template:
    metadata:
      labels:
        app: log-collector
    spec:
      containers:
      - name: fluentd
        image: fluentd

<aside> ❔

DaemonSet이 무엇이며, 새로운 노드가 추가되었을 때 어떤 과정을 통해 Pod가 배치되는지를 설명하시오.

DaemonSet은 클러스터의 모든 노드에 하나씩 Pod를 배포하기 위한 Kubernetes 리소스이다. Daemonset 컨트롤러는 주기적으로 클러스터 상태를 모니터링하며, Pod가 없는 노드에 대해 스케쥴러에게 배포 요청을 보낸다. 새로운 노드가 추가되면 컨트롤러가 이를 감지하고 해당 노드에 pod를 자동으로 생성한다. 노드에서 pod가 삭제되거나 문제가 발생하면 daemonset 컨트롤러가 이를 복구한다.

</aside>

Job: 배포되어 일을 마치면 사라지는 방식

특징

1. 작업이 완료되면 관련 pod도 삭제된다.
2. 작업 실패 시, 재시도 횟수(backoffLimit)을 설정할 수 있다.

스펙설명

1. parallelism

동시에 실행되는 pod의 수이다.

1. completions

Job이 완료되기 위해 실행되어야 할 pod의 총 수를 뜻한다.

1. backoffLimit

pod 실패 시 재시도 횟수를 의미한다.

1. TTLSecondsAfterFinished

Job이 완료된 후 리소스를 유지할 시간을 의미한다. 설정하지 않으면 리소스가 유지된다.

Job YAML

apiVersion: batch/v1
kind: Job
metadata:
  name: example-job
spec:
  parallelism: 2
  completions: 4
  backoffLimit: 3
  template:
    spec:
      containers:
      - name: example-container
        image: busybox
        command: ["sh", "-c", "echo 'Processing Job!' && sleep 10"]
      restartPolicy: Never
      
      

실행 흐름

1. Job 컨트롤러가 정의된 대로 Pod를 생성한다.
2. Pod는 작업을 수행하고 완료되면 종료한다.
3. 모든 pod가 성공적으로 완료되면 Job이 종료된다.

CronJob: 정해진 시간에 배포되고 일을 마치면 삭제하는 방식

목적

CronJob은 특정 스케줄에 따라 Job을 반복 실행한다.

CronJob과 Job의 차이

스펙 설명

1. schedule

CRON 표현식을 사용하여 실행 스케줄을 정의한다.

1. jobTemplate

생성할 Job의 템플릿을 정의한다.

1. startingDeadlineSeconds

Job이 스케줄된 시간 이후 몇 초까지 유효한지를 정의한다.

1. suspend

Cronjob을 일시 중지하려면 true로 설정한다.

CronJob YAML

apiVersion: batch/v1
kind: CronJob
metadata:
  name: backup-job
spec:
  schedule: "0 0 * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: backup
            image: busybox
            command: ["sh", "-c", "echo 'Running backup!' && sleep 5"]
          restartPolicy: OnFailure
          
  

실행 흐름

1. CronJob 컨트롤러가 스케줄에 따라 job을 생성한다.
2. Job은 정의된 대로 작업을 수행한다.
3. 작업이 완료되면 pod는 삭제되고 Job은 완료 상태로 기록된다.

Stateful Set: 여러 개의 Pod를 생성시 각각의 pod가 구별되게 하는 방식

목적

StatefulSet은 상태를 가진 Pod를 배포하고 관리한다.

특징

1. 고유한 Pod 이름을 가져 Pod에 순서가 부여된다.
2. 재시작 시 상태를 유지한다. Pod가 재생성되더라도 고유한 이름으로 기존 상태를 유지한다.
3. 스토리지 연결이 유지된다. pod가 PV와 연결된 상태를 보장한다.
4. 데이터베이스, 분산 시스템, 쿠키 기반 세션 관리에 이용된다.

StatefulSet YAML

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  serviceName: "web-service"
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: nginx
        image: nginx

스토리지말고도 다른 파라미터 그런것들도 있으니까 알아보면 좋음

---

또한, 워크로드를 운영시에 필요한 여러 기능을 배울 것이다.

Container image를 업데이트하고 싶을 때

단순 업데이트는….

pod를 죽이고 업데이트를 하면 중간에 서버를 운영할 수가 없잖아?

1. 서비스 중단
2. 새 이미지 문제
3. 롤백의 어려움

과 같은 문제점이 발생하게 된다. 그래서 쿠버네티스는 이러한 문제를 해결하기 위해서 중단 없는 배포를 지원한다.

대표적으로 3가지 방식이 있다.

1️⃣ Rolling Update

기존 pod를 하나씩 종료하고, 새로운 pod를 하나씩 생성하는 방식이다. 새 pod가 준비 상태가 될 때까지 기존 pod가 종료되지 않는다.

장점

중단 없는 서비스를 제공하며, 트래픽을 새로운 pod와 기존 pod에 적절히 분배한다.

구현 방법

strategy 필드에 RollingUpdate를 설정한다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1
  template:
    spec:
      containers:
      - name: my-app-container
        image: my-app:v2

• maxUnavailable: 업데이트 중 동시에 사용할 수 없는 pod의 최대 수
• maxSurge: 업데이트 중 생성되는 추가 pod의 최대 수

2️⃣ Blue-Green Deployment

새 버전을 별도의 Blue 환경에 배포한 후, 안정성을 확인한 뒤 트래픽을 새 버전으로 전환한다. 기존 Pod는 여전히 Green 환경에서 대기 상태로 유지한다.

장점👍

1. 새 버전이 안정적이지 않을 때 빠르게 롤백이 가능하다.
2. 테스트와 검증을 거친 후 전환하므로 안정성을 보장한다.

단점👎🏻

1. 두 버전이 동시에 실행되므로 리소스를 많이 사용한다.

구현 방법

1. 새 버전을 배포하여 새로운 서비스 라우팅을 설정한다.
2. 새 버전이 검증되면, 트래픽을 새 서비스로 라우팅한다.

3️⃣ Canary Deployment

새 버전을 소수의 사용자에게 테스트한다. 새 버전이 안정적임이 확인되면 점직적으로 트래픽 비율을 증가한다.

장점👍

1. 새 버전의 안정성을 빠르게 확인할 수 있다.
2. 문제 발생 시 영향 범위가 제한되어있다.

단점👎🏻

1. 설정이 복잡하다.

구현 방법

Istio 또는 Argo Rollouts 같은 도구와 함께 사용하여 트래픽을 분배한다.

Pod 의 Scaling 방법

HPA (Horizontal Pod Autoscaler) : Scale Out

HPA는 쿠버네티스에서 pod의 수를 동적으로 조정하는 기능이다. 주로 CPU 사용률, 메모리 사용량을 기반으로 Pod의 개수를 늘리거나 줄인다.

장점

1. 수평적 확장을 통해 로드밸런싱이 가능해진다.
2. 쉽게 구현 가능하다.

HPA 동작 원리

1. Kubernetes의 metrics-server가 각 pod의 리소스 사용량을 모니터링한다.
2. CPU 또는 메모리 사용량이 설정값을 초과하면 pod 개수를 증가시킨다.
3. 사용량이 줄어들면 pod 개수를 감소시킨다.

구현 예시

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: example-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: example-deployment
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50
        

• minReplicas: 최소 pod 개수
• maxReplicas: 최대 pod 개수
• averageUtiliztion: 평균 CPU 사용률이 50%를 넘으면 Pod를 늘림

VPA (Vertial Pod Autoscaler) : Scale Up

VPA는 pod의 CPU, 메모리 리소스를 동적으로 조정한다.

문제점

pod가 종료후 재생성되기 때문에 서비스 중단이 발생할 수 있다.

VPA 동작 원리

1. pod의 리소스 사용량을 모니터링한다.
2. 부족한 리소스를 동적으로 할당한다.
3. 기존 pod를 종료한 뒤 새로운 리소스를 할당받아 재생성한다.

VPA 구현 예시

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: example-vpa
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: example-deployment
  updatePolicy:
    updateMode: Auto
    
 

• updateMode: Auto(VPA가 자동으로 리소스 조정), Off(리소스는 조정되지 않음)

<aside> 🗣

백미리 CPU란? 쿠버네티스에서 CPU는 밀리 코어(millicore) 단위로 표현한다. 단위는

1 CPU = 1000m = 1 Core

</aside>

Hybrid Autoscaling

HPA 는 pod의 개수만 조정 가능하고, pod의 리소스 크기는 변경할 수 없다.

VPA는 리소스 크기만 조정 가능하고, pod의 개수는 변경할 수 없다.

⇒ 둘을 섞어버리자!

따라서 Hybrid Autoscaler는 HPA와 VPA의 장점을 결합한 방식이다. Kubernetes의 클러스터 상태를 분석하여 pod의 개수와 크기를 동시에 조정한다.

뭐 예를 들자면, CPU 사용량이 80%를 넘으면 HPA를 통해 Pod를 추가한다. 또는 pod의 메모리가 부족하면 VPA를 통해 메모리의 크기를 증가시킨다!

• 이해해봐..pod개수가 필요에 따라서 알아서 늘었으면 좋겠다. 코로나시절에 약국마스크찾기 이런거 서버가 자꾸 터졌잖아? 부하가 오지 않도록 적절히 스케일링해야 함.vpa는 파드에 cpu랑 메모리를 더 늘려줌. (이거 cgroup이 해줌) (Scale up이라고 함)근데 신버전에서는 vpa가 자동으로 되는데 이게 자동으로 안되면 이걸하고자한다면 파드의 스펙을 바꾸려면 파드를 새로 정의해야 함. 그니까 돌고 있던애가 죽었다가 살아나야 함. 어떻게하면 안죽이고 할 수 잇을까? 이걸 죽지 않고 하는 방법은..머 논문을 쓰셧대
• 하이브리드는 어느때 늘리고 어느때 줄일건가에 대한 판단을 함. 판단을 내리는 케이스를 분석해서 하이브리드오토스케일러를 정의한다.. 여기에 더 업데이트되면 머신러닝을 접목시켜서 언제 늘릴지 예측하고 그런대
• 백미리 cpu: cpu core가 여러개가있는데 한개 코어를 쪼갤수가 있음 밀리 단위로 . 코어를 백미리만큼 잘라주세요. 코어를 1/10만큼 달라 이런뜻임
• 똑같은걸 수평적으로 늘리는걸: hpa (scale out이라고 함)
• Scaling

전달 불가능한 정보를 전달하는 방법

Downward API

쿠버네티스에서 실행 중인 pod의 메타데이터와 상태 정보를 애플리케이션에서 전달하는 기능을 제공한다. 이를 통해 애플리케이션은 pod의 환경이나 상태에 따라 동적으로 동작할 수 있다.

필요성!

클라우드 환경에서 애플리케이션은 자신이 실행되고 있는 환경에 대한 정보를 미리 알기 어렵다.

뭐 예를 들어 pod의 ip주소, pod이름, 클러스터에서의 CPU/메모리 요청량과 한도, 실행주인 ns 이런 정보들은 pod가 실행된 이후에만 알 수 있다!

Downward API는 이러한 정보를 pod내 컨테이너에 전달함으로써, 애플리케이션이 동적으로 동작할 수 있도록 돕는다.

사용 방식

두가지 방식으로 정보를 전달한다.

1. 환경 변수: 애플리케이션에서 직접 환경변수로 정보를 참조하는 방식
2. 볼륨 마운트: 파일로 정보를 전달하여 읽을 수 있게 제공하는 방식

ConfigMap/Secret과의 차이점

Downward API는 pod 실행 중 동적으로 생성된 kubernetes 메타데이터를 전달하고, ConfigMap/Secret은 개발자가 사전에 정의한 설정값이나 민감한 데이터를 전달한다는 점에서 차이가 있다!

• 읽어봐라클라우드에 돌아가야지만 알게되는 정보들이 있음. 파드의 ip주소 이런거.. 파드가 돌기전에는 ip주소를 알수없자나/?환경변수 혹 볼륨마운트방식으로 apiserver읽어가서 미리 사용할 수 있게 한다.