pod이 가진 여러 속성이 있습니다. 각 속성에 대해서 알아보도록 하겠습니다.

중요 속성

liveness Probe, readness Probe
request, limit

조금 덜 중요 속성

Qos
Toleration & taints
Volumes
anootations

Liveness Probe와 Readiness Probe

Liveness Probe

목적: 컨테이너가 살아있는지(정상적으로 동작 중인지)를 확인합니다.
동작: Kubelet이 주기적으로 프로브를 실행하여 컨테이너의 상태를 평가합니다.
실패 시: Kubelet은 컨테이너를 재시작합니다.

예제:

  
livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 3
  periodSeconds: 5

Readiness Probe

목적: 컨테이너가 트래픽을 받을 준비가 되었는지 확인합니다.
동작: Kubelet이 주기적으로 프로브를 실행하여 컨테이너의 상태를 평가합니다.
실패 시: Kubelet은 컨테이너를 서비스의 엔드포인트에서 제거하여 트래픽을 받지 않게 합니다.

예제:

  
readinessProbe:
  httpGet:
    path: /readiness
    port: 8080
  initialDelaySeconds: 3
  periodSeconds: 5

Probe를 호출하는 주체는 Kubelet

Liveness Probe 실패: 컨테이너를 재시작합니다.
Readiness Probe 실패: 컨테이너를 서비스 엔드포인트에서 제거하여 트래픽을 받지 않게 합니다.

Request와 Limit

Request: Pod가 실행되기 위해 필요한 최소 리소스를 정의합니다. Kubernetes 스케줄러는 Request 값을 기반으로 Pod를 배치합니다. Request는 CPU와 메모리에 대해 설정할 수 있습니다.
Limit: Pod가 사용할 수 있는 최대 리소스를 정의합니다. Limit 값은 Pod가 클러스터 내에서 과도한 리소스를 사용하는 것을 방지합니다.

Request와 Limit의 단위

CPU

Millicore 단위: 100m, 500m 등. 예를 들어, 100m은 0.1 CPU 코어를 의미합니다.
Core 단위: 1, 2 등. 예를 들어, 1은 1 CPU 코어를 의미합니다.

Memory

메가바이트(MiB) 단위: 256Mi, 512Mi 등. 예를 들어, 256Mi는 256 메가바이트를 의미합니다.
기가바이트(GiB) 단위: 1Gi, 2Gi 등. 예를 들어, 1Gi는 1 기가바이트를 의미합니다.
정수 단위: 256M, 1G 등. 메모리의 경우도 정수로 지정할 수 있습니다.

설정 예시

  
apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
  - name: example-container
    image: nginx
    resources:
      requests:
        memory: "256Mi"
        cpu: "1"         # 1 CPU core
      limits:
        memory: "512Mi"
        cpu: "2"         # 2 CPU cores

request와 limit는 어떻게 활용되는가

스케줄링 시: Pod가 특정 노드에 배치될 때, 노드는 해당 Pod의 Request 값을 기준으로 충분한 리소스를 가지고 있는지 판단합니다.
실행 시: Pod가 Limit 값 이상의 리소스를 사용하려고 하면, Kubernetes는 이를 제한합니다. 다만, CPU와 메모리 설정은 다르다. 예를 들어, Pod가 CPU Limit을 초과하면 CPU 사용량이 스로틀링되고, 메모리 Limit을 초과하면 Pod가 종료됩니다.

Qos(Quality of Service Class)

QoS 클래스 요약 및 스케줄링 예시

QoS 클래스는 파드의 request과 limit에 따라 파드의 우선순위를 결정하고, 클러스터 자원이 부족할 때 자원 할당의 우선순위를 결정합니다. QoS 클래스는 Guaranteed, Burstable, BestEffort의 세 가지로 나뉩니다.

QoS 클래스 종류 및 스케줄링 예시

1. Guaranteed 파드

Requests와 limit가 동일하게 설정됨
스케줄링 우선순위: 가장 높음

예시:

  
apiVersion: v1
kind: Pod
metadata:
  name: guaranteed-pod
spec:
  containers:
  - name: mycontainer
    image: myimage
    resources:
      requests:
        memory: "50Mi"
        cpu: "250m"
      limits:
        memory: "50Mi"
        cpu: "250m"

예시) 스케줄링:
- 노드의 남은 메모리: 100Mi
- 파드의 요청 메모리: 50Mi
- 결론: 노드A에 100Mi의 메모리가 남아있는 경우, 이 파드는 스케줄러가 request을 충족할 수 있음을 확인하고 스케줄링할 수 있습니다. Guaranteed 파드는 자원이 부족한 상황에서도 보호됩니다.

2. Burstable 파드

requests과 limit이 하나만 설정되거나 값이 다른 경우
스케줄링 우선순위: 중간

예시:

  
apiVersion: v1
kind: Pod
metadata:
  name: burstable-pod
spec:
  containers:
  - name: mycontainer
    image: myimage
    resources:
      requests:
        memory: "30Mi"
        cpu: "250m"
      limits:
        memory: "150Mi"
        cpu: "500m"

예시) 스케줄링:
- 노드의 남은 메모리: 100Mi
- 파드의 요청 메모리: 30Mi
- 결론: 노드A에 100Mi의 메모리가 남아있는 경우, 이 파드는 30Mi의 요청을 충족할 수 있으므로 스케줄링될 수 있습니다. 그러나 실행 중에 150Mi까지 사용할 수 있어 자원 부족 상황이 발생할 수 있습니다.

3. BestEffort 파드

requests와 limit이 설정되지 않은 경우
스케줄링 우선순위: 가장 낮음

예시:

  
apiVersion: v1
kind: Pod
metadata:
  name: besteffort-pod
spec:
  containers:
  - name: mycontainer
    image: myimage

예시) 스케줄링:
- 노드의 남은 메모리: 100Mi
- 파드의 요청 메모리: 없음 (0Mi로 간주)
- 결론: 노드A에 100Mi의 메모리가 남아있는 경우, BestEffort 파드는 자원 요청이 없으므로 스케줄링될 수 있습니다. 그러나 자원 부족 시 가장 먼저 종료될 수 있습니다.

우선순위에 대한 이유

Guaranteed 파드: 자원 예약과 제한이 명확하여, 자원 스케줄링의 예측 가능성과 효율성을 높입니다. 자원 부족 시 가장 보호됩니다.
Burstable 파드: 최소 자원 요청을 기반으로 스케줄링되지만, 자원 제한이 달라 실제 사용량이 변동될 수 있습니다. 자원 부족 시 중간 우선순위를 가집니다.
BestEffort 파드: 자원 요청과 제한이 없어 자원 사용 예측이 어렵지만, 스케줄링은 용이합니다. 자원 부족 시 가장 먼저 종료됩니다.

Tolerations

Tolerations와 Taints의 의미

Taints: “오염” 또는 “더럽힘”을 의미합니다. Kubernetes에서 Taint는 노드에 적용되어 특정 파드가 해당 노드에서 실행되지 않도록 하는 메커니즘입니다. 즉, 노드에 ‘오염’을 표시하여 특정 파드를 멀리하게 만듭니다.
Tolerations: “관용” 또는 “용인”을 의미합니다. Kubernetes에서 Toleration은 파드가 특정 Taint를 ‘관용’하여 무시하고 해당 노드에서 실행될 수 있도록 하는 메커니즘입니다. 즉, 파드가 노드의 ‘오염’을 용인하고 해당 노드에서 실행될 수 있도록 합니다.

Tolerations

Tolerations와 taints는 함께 사용되어 특정 파드가 특정 노드에 스케줄링되는 것을 제어합니다. 이는 노드의 자원을 효율적으로 사용할 수 있게 하며, 특정 조건에서 파드를 격리하거나 우선순위를 설정하는 데 유용합니다.

taint 예시

kubectl taint nodes node1 key1=value1:NoSchedule

Key: taint의 키
Value: taint의 값
Effect: taint가 가지는 효과로, NoSchedule, PreferNoSchedule, NoExecute 중 하나가 될 수 있습니다.

Tolerations 예시

  
apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  tolerations:
  - key: "key1"
    operator: "Equal"
    value: "value1"
    effect: "NoSchedule"
  containers:
  - name: mycontainer
    image: myimage

Toleration 필드

key: taint의 키와 일치해야 하는 키입니다.
operator: 키와 값을 비교하는 연산자입니다. Equal(기본값) 또는 Exists가 될 수 있습니다.
value: taint의 값과 일치해야 하는 값입니다.
effect: taint의 효과입니다. NoSchedule, PreferNoSchedule, NoExecute 중 하나입니다. 효과가 일치해야 taint를 무효화합니다.
tolerationSeconds: (선택적) NoExecute 효과에만 적용되며, 파드가 노드에서 얼마나 오래 허용될지를 지정합니다.

Toleration 효과

NoSchedule:
- 노드에 taint가 있을 경우, Toleration이 없는 파드는 해당 노드에 스케줄링되지 않습니다.
- Toleration이 있으면 파드가 해당 노드에 스케줄링될 수 있습니다.
PreferNoSchedule:
- 노드에 taint가 있을 경우, Toleration이 없는 파드는 가능한 한 해당 노드에 스케줄링되지 않도록 시도합니다.
- Toleration이 있으면 파드가 해당 노드에 스케줄링될 수 있습니다.
NoExecute:
- 노드에 taint가 있을 경우, Toleration이 없는 파드는 해당 노드에서 즉시 제거됩니다.
- Toleration이 있으면 파드는 해당 노드에서 계속 실행될 수 있습니다. tolerationSeconds 필드가 지정된 경우, 지정된 시간 동안만 파드가 해당 노드에 남아 있을 수 있습니다.

사용 예시

taint 추가

kubectl taint nodes node1 key1=value1:NoSchedule

위 명령어는 node1에 key1=value1이라는 taint를 추가하고, NoSchedule 효과를 적용합니다. 이는 Toleration이 없는 파드가 node1에 스케줄링되지 않도록 합니다.

Toleration 추가

파드가 해당 노드에 스케줄링될 수 있도록 Toleration을 추가합니다.

  
apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  tolerations:
  - key: "key1"
    operator: "Equal"
    value: "value1"
    effect: "NoSchedule"
  containers:
  - name: mycontainer
    image: myimage

위 설정은 key1=value1 taint를 가진 노드에 NoSchedule 효과가 있어도 mypod가 스케줄링될 수 있도록 합니다.

volumes

Kubernetes에서 볼륨은 파드 내 여러 컨테이너가 데이터를 공유할 수 있게 하거나, 파드가 종료되더라도 데이터를 지속적으로 저장할 수 있게 합니다. 볼륨은 컨테이너의 라이프사이클을 초과하여 데이터를 유지할 수 있으므로, 컨테이너 재시작, 재배포 등의 상황에서도 데이터를 보존하는 데 유용합니다.

볼륨의 주요 개념

Ephemeral Volumes (휘발성 볼륨):
- 파드의 라이프사이클 동안에만 존재하며, 파드가 삭제되면 볼륨도 삭제됩니다.
- 예시: emptyDir, configMap, secret
Persistent Volumes (영구 볼륨):
- 파드의 라이프사이클을 초과하여 존재하며, 파드가 삭제되어도 데이터가 유지됩니다.
- 예시: persistentVolumeClaim, hostPath

서비스 어카운트

Kubernetes에서 서비스 계정(Service Account)은 파드가 API 서버와 상호작용할 때 사용하는 인증 수단입니다. 서비스 계정은 파드에 필요한 권한을 부여하고, 안전하게 API 서버와 통신할 수 있도록 합니다.

팟과 API 서버 간의 통신이 필요한 케이스는 ConfigMap이나 Secret과 같은 구성 정보를 API 서버에서 직접 조회하는 경우가 있다고 한다.

애노테이션

Annotations과 Labels의 차이점

용도:
- Annotations: Kubernetes 객체에 부가적인 메타데이터를 저장하는 데 사용됩니다. 객체의 동작에 직접적인 영향을 미치지 않습니다.
- Labels: Kubernetes 객체를 식별하고 그룹화하는 데 사용됩니다. 객체의 동작에 직접적으로 영향을 미치며, 주로 선택기(selector)로 사용됩니다.

Annotations이 필요한 이유

메타데이터 저장:
- 객체에 대한 부가적인 정보를 저장할 수 있습니다 (예: 생성 시간, 소유자, 빌드/배포 정보).
외부 도구와의 통합:
- 모니터링 도구, 로그 관리 시스템 등 외부 도구와의 통합에 유용합니다.

pod이 가진 속성들

중요 속성

조금 덜 중요 속성

Liveness Probe와 Readiness Probe

Liveness Probe

Readiness Probe

Probe를 호출하는 주체는 Kubelet

Request와 Limit

Request와 Limit의 단위

CPU

Memory

설정 예시

request와 limit는 어떻게 활용되는가

Qos(Quality of Service Class)

QoS 클래스 요약 및 스케줄링 예시

QoS 클래스 종류 및 스케줄링 예시

1. Guaranteed 파드

2. Burstable 파드

3. BestEffort 파드

우선순위에 대한 이유

Tolerations

Tolerations와 Taints의 의미

Tolerations

taint 예시

Tolerations 예시

Toleration 필드

Toleration 효과

사용 예시

taint 추가

Toleration 추가

volumes

볼륨의 주요 개념

서비스 어카운트

애노테이션

Annotations과 Labels의 차이점

Annotations이 필요한 이유

Further Reading

멱등 API는 왜 필요할까

API문서의 가독성과 파편화

Spring WebClient 사용 시 uri tag가 none으로 나올 때