K8S Pod와 Deployment 간단 이해

“쿠버네티스에서 배포할 수 있는 가장 작은 컴퓨터 오브젝트인 Pod와 이를 실행하는데 도움이 되는 고수준 추상화” = 쿠버네티스 워크로드

쿠버네티스의 워크로드는 클러스터에서 실행되는 애플리케이션과 서비스를 나타낸다. 이는 컨테이너화된 애플리케이션을 배포, 관리 및 확장하기 위해 정의된 객체들로 구성된다. 워크로드의 주요 유형은 아래와 같다.

• Pod : 하나 이상의 컨테이너를 포함하는 쿠버네티스의 가장 작은 배포 단위
• Deployment : 무중단 배포와 롤백을 관리하며, 애플리케이션을 선언적으로 배포
• StatefulSet : 상태를 가진 애플리케이션을 관리하며, 안정적인 네트워크 ID를 제공
• DaemonSet : 각 노드에서 실행되는 워크로드를 관리
• Job & CronJob : 일회성 또는 주기성을 띄는 작업을 수행

워크로드를 적절히 활용하여 클러스터 리소스를 효율적으로 활용하며 서비스에 확장성과 안정성을 제공할 수 있게 된다.

오늘 이 시간엔 Pod에 대해 하나씩 자세히 알아보자.

Pod

파드(Pod)는 쿠버네티스에서 생성하고 관리할 수 있는 배포 가능한 가장 작은 컴퓨팅 단위이다. 일반적으로 “도커”가 가장 잘 알려진 Pod 컨테이너 런타임 환경이고, 이 외에도 다양한 컨테이너 런타임을 지원한다. 과거에는 도커에 의존적이었던 kube 환경 덕에 도커 관련 용어로 설명하면 쉽게 이해되는 경우가 많다.

Pod는 도커 컨테이너처럼 내부에서 아래 요소들을 호스트 환경으로부터 격리한다.

• 하나 이상의 애플리케이션 컨테이너
• IP Address
• volume과 같은 공유 스토리지

단, 도커와 Pod의 차이점은 Pod는 단일 컨테이너가 아닌 여러 컨테이너가 공유하는 논리적 단위로 동작한다. 따라서 Net 네임스페이스(동일한 IP address와 port number)와 일부 볼륨 등 공유 스토리지는 공유된다.

파드의 생성과 관리는 일반적으로 YAML 형식의 리소스 정의 파일을 사용한다. 아래는 nginx:1.14.2 이미지를 실행하는 컨테이너로 구성되는 Pod 예시이다.

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx
    ports:
    - containerPort: 80
	    protocol: TCP

위 yaml 파일을 저장하고 아래 명령어를 실행하면 Pod가 생성된다.

$ kubectl create -f {title}.yaml

하지만 일반적으로 Pod는 직접 생성하지는 않으며, 대신 워크로드 리소스를 사용하여 생성한다. Pod는 일시적이고, 언제나 삭제될 수 있음을 감안하고 만들어진다.

컨테이너를 수동으로 만들고 관리하는 활동은 도커만 사용하면 충분하다. K8S의 진정한 가치는 단지 격리된 컨테이너 환경에서 애플리케이션을 실행하고 운영하는 것을 넘어서 “오케스트레이션” 에서 나온다.

네트워크나 Pod 장애 시 복구하거나, 복제하는 등의 일을 자동으로 처리해야 하므로 직접적으로 사용자가 Pod를 관리하는 것이 아닌 워크로드에 의한 효율화된 운영이 주가 되는 것이다(물론 권장되지 않을 뿐, K8S는 사용자가 Pod를 직접 관리하는 것을 막지 않는다).

Pod의 헬스체크

K8S에서는 애플리케이션 컨테이너의 상태를 모니터링하고, 적절히 관리하기 위해 사용되는 세 가지 헬스 체크(Health Check) 메커니즘이 존재한다. 하나하나 살펴보자.

Probe

우선 세가지 헬스 체크 메커니즘이 활용하는 방식을 이해해야 한다.

• HTTP request : 특정 HTTP 엔드포인트로 상태를 확인
• TCP 요청 : 특정 포트로 연결 가능 여부 확인
• Exec 명령어 : 컨테이너 내부에서 명령어 실행 후 종료 코드 확인
• grpc: gRPC를 사용하여 Health check

1. Liveness Probe

애플리케이션이 여전히 정상적으로 실행되고 있는지 확인하는 헬스 체크이다.

만약, 애플리케이션이 응답하지 않거나, 내부적으로 정지된 상태가 된 경우 이를 감지하여 자동으로 재시작한다. 사용자가 정의한 Liveness Probe 활동에 실패하면 컨테이너를 강제로 종료하고 Kubernetes가 새로운 컨테이너를 생성하여 실행한다.

Liveness Probe 예시를 살펴보자.

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-exec
spec:
  containers:
  - name: liveness
    image: registry.k8s.io/busybox
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -f /tmp/healthy; sleep 600
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5
      periodSeconds: 5

위 예시는 Exec 명령어를 통해 명령어 실행 후 종료 코드를 확인하는 방식으로 애플리케이션이 정상적으로 작동하는지를 확인한다. Pod가 생성된 후 5초 후(initialDelaySeconds)부터 첫 번째 Probe가 동작하며 5초 간격(periodSeconds)으로 동작을 반복하게 된다.

시스템 명령이 성공하여 0을 반환했다면 kubelet은 컨테이너가 살아있다고 간주하고 명령이 0이 아닌 값을 반환하면 kubelet에 의해 컨테이너는 종료되고 다시 시작한다.

주의할 점

Liveness Probe의 의도와 목적은 컨테이너가 데드락 또는 복구 불가능한 장애 상태에 빠졌을 때 이를 감지하여 컨테이너를 자동으로 재시작하도록 설계되었다. 따라서, Liveness Probe는 컨테이너가 다시 시작되어야 할 합당한 이유를 감지하도록 구성해야한다.

만약, 라이브니스 프로브의 대기 시간(initialDelaySeconds)이나 요청 간격(periodSeconds)이 너무 짧게 설정되어 있다면 정상 상태의 컨테이너가 불필요하게 재시작하여 리소스를 소모할 수 있다. 또한 과도한 부하 상황에서 Liveness Probe에 의해 재시작되는 연쇄 실패가 발생, 전체 시스템 장애로도 확산될 수 있다.

따라서 Liveness Probe는 애플리케이션의 복구 불가능한 상태를 정확히 감지하도록 신중히 구성해야 한다.

2. Readiness Probe

Readiness Probe는 애플리케이션이 트래픽을 처리할 준비가 되었는지 확인하기 위해 사용되며, 이를 통해 서비스의 안정성을 유지할 수 있다. 만약 애플리케이션이 서비스 트래픽을 받아들일 준비가 되어 있지 않다는 것이 Readiness Probe를 통해 K8S에 감지되면 해당 Pod는 서비스의 엔드포인트에서 제거되어 트래픽을 받지 않는다.

아래 예시 설정을 살펴보자.

apiVersion: v1
kind: Pod
metadata:
  name: goproxy
  labels:
	  app: goproxy
spec:
  containers:
  - name: goproxy
    image: registry.k8s.io/goproxy:0.1
    ports:
    - containerPort: 8080
    readinessProbe:
      httpGet:
        path: /readyz
        port: 8080
        httpHeaders:
        - name: Custom-Header
          value: CustomValue
      initialDelaySeconds: 5
      periodSeconds: 10
      timeoutSeconds: 2
      successThreshold: 1
      failureThreshold: 3

위 예시는 HTTP GET Request를 통해 애플리케이션의 특정 엔드포인트에서 상태 확인을 수행한다. Pod가 생성된 후 5초 후(initialDelaySeconds)부터 첫 번째 Probe가 동작하며 10초 간격(periodSeconds)으로 동작을 반복하게 된다. 연속 성공 횟수(successThreshold)가 1회여야 준비 완료 상태로 간주되고 연속 실패 횟수(failureThreshold)가 3회면 준비가 되지 않은 상태로 간주되어 해당 Pod를 서비스 엔드포인트에서 제외한다.

만약 HTTP request에서 200 이상 400 미만(200 ~ 399)의 응답을 받았다면 애플리케이션이 준비 완료 상태임으로 간주하고 그 외의 상태 코드일 때 준비되지 않았으므로 간주한다.

주의할 점

이렇게 Readiness Probe는 애플리케이션의 준비 상태를 효과적으로 확인하고, 트래픽 경로에서 불완전한 Pod를 제외함으로써 시스템 안정성을 강화할 수 있다. 이를 정확히 설계하면 무중단 배포와 장애 격리가 용이해진다.

공식 docs에서는 “**Liveness Probe와 Readiness Probe의 차이점을 명확히 이해하라”**고 강조하고 있다. Liveness Probe는 애플리케이션 자체의 상태를 감지해 컨테이너를 재시작할지 결정한다. "애플리케이션이 살아 있는가?"라는 질문을 Exec, TCP, HTTP 등의 방법으로 던지고 응답을 받아 컨테이너를 관리한다. 반면, Readiness Probe는 애플리케이션이 트래픽을 처리할 준비가 되었는지 확인한다. "애플리케이션이 요청을 받을 준비가 되었는가?"라는 질의를 통해 Pod를 관리하며 이때 Pod는 재시작을 필요로 하지 않는다.

3. Startup Probe

Startup Probe는 애플리케이션의 초기화가 느리거나 복잡한 경우 초기화 상태를 확인하는 데 사용되며, 애플리케이션이 정상적으로 시작되었는지 확인하기 위해 설정된다. 초기화의 기준은 Readiness와 마찬가지로 응답을 받느냐 받지 않느냐이다.

만약, 초기화가 느린 애플리케이션의 경우 Liveness Probe에 의해 초기화도 되지 않았는데 오류로 간주되어 컨테이너를 재시작하는 상황이 생길 수도 있다. 이때, Startup Probe는 초기화가 완료될 때까지 시간을 벌어주어 이러한 상황을 해결한다.

Startup Probe가 성공하면 Liveness와 Readiness Probe가 동작하며, Pod는 트래픽을 받을 준비가 완료된다.

 

아래 예시를 살펴보자.

apiVersion: v1
kind: Pod
metadata:
  name: tcp-startup-probe-pod
spec:
  containers:
  - name: tcp-startup-probe-container
    image: your-image
    startupProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 10
      periodSeconds: 5
      timeoutSeconds: 1
      failureThreshold: 30

위 TCP 검사의 구성은 HTTP request 방식과 상당히 유사하다. 해당 Pod의 8080번 포트(tcpSocket. port)로 연결을 확인하게 된다. 이 때 TCP 연길 시도의 타임아웃 시간(timeoutSeconds)은 1초이다.

 

초기화 상태 확인 전용 Probe를 통해 초기화 중인 컨테이너가 Liveness Probe에 의해 불필요하게 재시작되는 것을 막아준다. 이를 위해 K8S는 Startup Probe를 통해 Liveness 나 Readiness Probe가 초기화가 완료된 후에만 동작하도록 보장한다.

Pod Label

Labels는 객체에 메타데이터를 추가하기 위한 키-값 쌍을 의미한다. K8S 리소스(Pod, Service, Deployment)에 부여되어 리소스를 선택하거나 그룹화하는 데 사용된다. 레이블을 사용하면 리소스를 더 쉽게 찾고 관리할 수 있으며, 다양한 리소스를 효율적으로 조작할 수 있게 된다.

레이블을 기반으로 선택자를 사용하여 여러 리소스를 선택하거나 필터링할 수 있다. 선택자는 레이블의 키와 값을 기준으로 리소스를 필터링하는 조건을 정의하고 동일한 종류의 리소스나 관련된 리소스들을 그룹화하며 이를 바탕으로 여러 작업을 실행할 수 있다.

예시

Label 키	설명	레이블 값
Application-ID/Application-name	응용 프로그램 이름 또는 ID	my-app/k-l1verse
Version-nr	버전 번호	ver-0.9
Owner	개체가 속한 팀 또는 개인	Team-devBack/Aiden
Stage/Phase	개발 단계 또는 위치	Dev, staging, QA, Canary, Production
Release-nr	릴리즈 번호	release-nr-2.0.1
Tier	앱이 속한 계층	frontend/backend
Custom-facing	고객에게 직접 서비스하는 앱 여부	Yes/No
App-role	앱의 역할	Cache/Web/Database/Auth
Project-ID	연관된 프로젝트 ID	my-project-12
Customer-ID	자원을 할당한 고객 ID	customer-id-13

 

활용

Pod를 생성할 때, Label정보를 yaml로 정의한 예시이다.

apiVersion: v1
kind: Pod
metadata:
  name: label-demo
  labels:
    environment: production
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    ports:
    - containerPort: 80

위처럼 리소스를 생성한 시점에 Label을 정의할 수도 있고, 리소스를 생성한 후에도 동적으로 변경할 수 있다. 아래 커맨드를 살펴보자.

 

$ kubectl label pods label-demo tier=frontend

위 yaml정보로 생성한 pod에 tier:frontend라는 label을 적용할 수 있다.

$ kubectl label pods label-demo environment=test

위 명령어는 기존에 environment라는 레이블이 이미 존재하면 에러를 반환할 것이다. 존재하는 레이블을 덮어쓰고 싶다면 --overwrite 옵션을 활용하자.

$  kubectl label pods label-demo environment=production --overwrite

 

레이블로 특정 Pod의 그룹 또는 특정 Pod를 조회하고 싶다면 아래와 같은 방법을 사용한다.

# pod에 레이블 표시
$ kubectl get pod --show-labels

# 특정 레이블이 있는 Pod 조회
$ kubectl get pod -L tier

다른 리소스들과 연계

Label의 의미는 단순한 리소스의 식별자 정도로 생각하면 안된다. Deployment, Service, Stateful Set과 같이 K8S의 각종 리소스와 Pod사이의 연결고리가 바로 label이다. 예를 들어, Deployment에서 생성된 Pod들은 특정 레이블을 통해 해당 Deployment와 연결된다. 아래 yaml 정보를 보자.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: frontend-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      tier: frontend  # 이 레이블을 가진 Pod들을 선택
  template:
    metadata:
      labels:
        tier: frontend  # Pod에 이 레이블을 설정
    spec:
      containers:
        - name: frontend-container
          image: myfrontend:latest
          ports:
            - containerPort: 80

아직 자세히 다루진 않았지만 Deployment라는 K8S의 리소스를 정의한 yaml 파일이다.

 

selector.matchLabels은 Deployment가 관리할 Pod들을 선택하는 레이블이다. 이 레이블을 가진 Pod들이 디플로이먼트에 의해 관리된다. 또한, template.metadata.labels는 디플로이먼트가 생성할 Pod들에 설정할 레이블이다. 이 레이블은 위의 selector.matchLabels와 일치해야 하며 이를 통해 디플로이먼트가 생성한 Pod들이 이 레이블을 가지게 된다.

Replication Controller(Replica Set)

현재 새로운 버전의 K8S에서는 Replica Set으로 대체된 Replication Controller는 K8S에서 Pod의 수를 관리하는 리소스이다. 주로 지정된 수의 하나의 Pod 인스턴스를 유지하려는 목적을 가지고 있고 자동화된 복제 및 확장을 통해 안정적인 애플리케이션 배포와 운영을 지원한다.

주요 기능으로는 다음과 같다.

1. Pod 복제
   • 지정된 수의 Pod 복제본을 항상 유지한다.
2. 자동화된 Pod 생성 및 삭제
   • 만약 Pod가 중지되거나 삭제되면 자동으로 새로운 Pod를 생성하여 늘 같은 replica 수를 유지한다.

다음으로 3개의 Pod를 유지하도록 설정한 Replication controller를 봐보자.

apiVersion: v1
kind: ReplicationController
metadata:
  name: nginx
spec:
  replicas: 3
  selector:
    app: nginx
  template:
    metadata:
      name: nginx
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80

위 설정은 원하는 pod는 3개를 유지(replicas)하고 app:nginx 라는 레이블을 가진 pod들을 관리하도록 selector를 설정해두었다. 그 후 template에 Replication Controller가 생성할 Pod를 정의한다. 이 template에 정의된 컨테이너와 설정이 모든 replica에 적용된다.

Replication Controller는 이처럼 단일 애플리케이션을 여러 Pod 인스턴스로 배포할 때 사용된다. 리소스가 충분하다면 replicase 값을 늘려서 트래픽에 대응할 수도 있고 Pod가 죽거나 비정상적인 상태를 감지하여 새로운 Pod를 자동으로 생성할 수도 있다.

ReplicaSet과 Deployment

다만, 현재 K8S 최신버전에서는 Replication Controller보다 ReplicaSet이 권장된다. Deployment 리소스는 ReplicaSet을 사용하여 Pod 복제를 비롯한 다른 고급 기능을 함께 지원하고 있으므로, Replication controller의 자리를 천천히 대신하고 있다.

물론 Replication Controller는 여전히 Kubernetes에서 지원되고 있으며, 일부 이전 시스템이나 특정 상황에서는 유용할 수 있다.

Deployment와 RollingUpdate

Deployment는 K8S에서 애플리케이션의 배포, 업데이트, 스케일링, 롤백을 관리하는 고급 리소스이다. Deployment를 활용하여 지정된 수의 Pod를 실행하도록 정의하고, 해당 Pod들이 항상 예상되는 상태를 유지하도록 보장할 수 있다.

Deployment는 K8S의 핵심적인 기능인만큼 주요 기능 정리가 많다.

1. 배포 관리
   • Deployment는 애플리케이션의 최신 버전을 배포하고, 이를 자동으로 관리한다.
2. 자동화된 롤백
   • 배포 과정에서 문제가 생기면, Deployment는 자동으로 이전 안정적인 상태로 롤백이 가능하다.
3. 애플리케이션 업데이트
   • 새로운 버전의 컨테이너 이미지를 배포하거나, 설정을 변경하면 deployment가 알아서 이를 처리한다.
4. 스케일링
   • ReplicaSet을 사용하여 Pod의 수를 동적으로 조정할 수 있다.
5. 배포 전략
   • Deployment는 Rolling Update, Recreate, Blue/Green 배포 전략을 지원하여, 업데이트 시 애플리케이션의 가용성을 보장한다.

 

아래 Deployment의 설정을 선언한 yaml 파일을 보자.

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

위 설정에서 replicas를 통해 총 3개의 Pod를 항상 실행하고, Label이 app:nginx 인 Pod들을 대상으로 관리함(selector.matchLables)을 명시했다. 생성될 Pod의 정의는 template에 포함되어 있다.

애플리케이션의 배포는 위 yaml 파일을 create 하면 된다.

$ kubectl create -f {file-name}.yml --record=true

배포 버전을 시각적으로 보기 위해서는 record 옵션을 true로 준다.

Deployment는 애플리케이션 업데이트를 점진적으로 수행하여 애플리케이션의 가용성을 보장한다. 새로운 버전의 애플리케이션을 배포할 때, 기존의 Pod를 하나씩 교체하면서 서비스의 중단을 최소화하게 된다.

 

$ kubectl set image deployment/nginx-deployment nginx=nginx:1.19.0

위 명령어는 nginx-deployment Deployment에 포함된 모든 nginx 컨테이너 이미지를 nginx:1.19.0으로 업데이트한다. 이 과정은 아무런 설정을 하지 않으면 default로 롤링 업데이트 방식으로 진행된다.

update 직후에 리소스를 조회해보자. AGE를 통해서 pod들이 새롭게 만들어지고 이전 버전의 Pod가 사라지는 것을 볼 수 있다.

스케일링을 위하여 replicas의 수를 변경할 수도 있다.

$ kubectl scale deployment nginx-deployment --replicas=5

새롭게 두 개의 Pod가 생성되었다.

배포 과정에서 문제가 발생했다면 즉각적인 이전 버전으로의 롤백이 가능하다.

$ kubectl rollout undo deployment/nginx-deployment

현재 배포가 완료되었는지, 그리고 Deployment가 제대로 실행되고 있는지 확인할 수도 있다.

$ kubectl rollout status deployment/nginx-deployment

Deployment 리소스의 상세 정보와 설정을 확인할 수 있습니다.

$ kubectl get deployment nginx-deployment

Deployment에서 실행되는 설정을 동적으로 수정할 수 있다.

$ kubectl patch deployment nginx-deployment -p '{"spec":{"replicas":4}}'

Rolling Update

Deployment의 기본적인 배포 전략으로 자리 잡은 Rolling Update는 서비스 중단 없이 점진적으로 애플리케이션을 업데이트하는 방식이다. 이전 버전의 Pod를 새로운 버전의 Pod로 점진적(카나리)으로 배포하는 방식으로 동작한다.

Rolling Update는 한 번에 모든 Pod를 교체하지 않고, 작은 배치 단위로 Pod를 교체하게 된다. 만약 새로운 버전의 Pod가 문제를 일으킨다면 Rolling Update 옵션에서는 자동으로 이전 버전으로 롤백하여 시스템을 정상화한다.

기본적으로 기존의 Pod를 점진적으로 종료하고, 새로 업데이트된 Pod를 추가하여 교체하는 방식에서 교체 비율을 조정하는 고급 기능을 추가할 수 있다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:latest
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1  # 새 Pod를 한 개 초과할 수 있음
      maxUnavailable: 1  # 업데이트 중 한 번에 하나의 Pod만 종료

maxSurge 옵션을 통해 새로운 Pod를 추가할 수 있는 최대 개수를 지정한다. 위 yaml 설정에 따르면, 새로운 버전의 Pod를 추가할 때 기존 Pod 수보다 1개 더 많은 Pod를 생성할 수 있다.

maxUnavailable은 업데이트 중에 한 번에 종료할 수 있는 Pod의 최대 개수를 의미한다. 위에선 1로 설정했으므로 한 번에 하나의 Pod만 종료된다.

Rolling Update 외에도

K8S는 Rolling Update 외에도 다양한 배포 전략을 사용할 수 있다.

• Recreate
• 이전 버전의 Pod를 모두 종료하고 새로운 버전의 Pod를 한 번에 시작하는 방식이다. 이는 불가피하게 서비스의 중단이 발생하지만 직관적으로 이해하기 쉬운 간단한 배포 방식이다.
• Blue/Green
• 두 개의 환경(Blue와 Green)을 준비해 두고, 새로운 버전의 애플리케이션을 Green 환경에 배포한 후, 트래픽을 한꺼번에 Green으로 전환하는 방식이다. 롤백이 간편한 방식이지만 불가피하게 리소스를 두 배로 사용하는 단점이 있다.

네임스페이스

K8S에서 클러스터 내 리소스를 논리적으로 분리하여 관리할 수 있도록 하는 가상환경인 “네임스페이스”는 다양한 팀, 프로젝트, 환경 등을 효율적으로 구분하고 자원을 격리하는 데 사용된다.

K8S 클러스터에는 기본적으로 4개의 네임스페이스가 설정된다.

1. default
   • 별도의 네임스페이스를 지정하지 않을 경우 사용하는 기본 네임스페이스.
   • 일반적인 테스트 또는 소규모 작업에 사용
2. kube-system
   • K8S 클러스터의 내부 시스템 컴포넌트(Pod, 컨트롤러 등)가 실행되는 네임스페이스
   • kube-apiserver, kube-controller-managerm, kube-scheduler 등이 포함된다.
3. kube-public
   • 클러스터 내에서 모든 사용자가 읽을 수 있는 리소스를 포함한다. 주로 클러스터 정보나 공개 데이터를 저장한다.
   • 대부분의 클러스에서는 거의 사용되지 않는다.
4. kube-node-lease
   • 각 노드의 상태 정보를 유지하는 NodeLease 객체를 저장한다.
   • 노드의 상태를 효율적으로 관리하기 위해 사용된다.

현재 클러스터 내의 네임스페이스를 확인하고 싶다면 아래 커맨드를 입력한다.

$ kubectl get namespaces

yaml 파일을 이용해서 네임스페이스를 설정하고 싶다면 yaml 파일을 입력하고 커맨드를 입력한다.

apiVersion: v1
kind: Namespace
metadata:
  name: dev-team

$ kubectl apply -f namespace.yaml

특정 네임스페이스에 리소스 생성할 때 네임스페이스를 지정하는 방법은 아래 yaml 설정을 참고하자.

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  namespace: dev-team
spec:
  containers:
    - name: nginx
      image: nginx:latest

위처럼 metadata에 namespace를 명시해주자. 이 Pod는 dev-team이라는 네임스페이스에 생성되어 관리될 것이다.

특정 네임스페이스의 리소스를 확인하기 위해선 아래 커맨드를 입력한다.

$ kubectl get pods -n <namespace-name>

클러스터의 현재 네임스페이스를 설정하는 방식은 아래 커맨드를 입력하면 된다.

$ kubectl config set-context --current --namespace=<namespace-name>
# kubectl config set-context --current --namespace=dev-team

리소스 쿼터

네임스페이스에서 사용할 리소스를 제한하기 위해 리소스 쿼터를 설정할 수 있다. 이를 통해 네임스페이스별로 CPU, 메모리, 스토리지 등을 제한할 수 있다. 아래 네임스페이스 설정을 담은 yaml파일을 확인해보자.

apiVersion: v1
kind: ResourceQuota
metadata:
  name: dev-team-quota
  namespace: dev-team
spec:
  hard:
    pods: "10"
    requests.cpu: "4"
    requests.memory: "8Gi"
    limits.cpu: "8"
    limits.memory: "16Gi"

위 설정에 다르면, dev-team 네임스페이스는 최대 10개의 Pod, 최대 4개의 CPU 요청, 최대 8Gi의 메모리 요청, 최대 8개의 CPU 사용, 최대 16Gi의 메모리 사용이 가능하다.

네임스페이스는 Kubernetes 클러스터를 논리적으로 분리하고, 다양한 팀과 환경에서 효율적으로 작업을 관리할 수 있도록 도와준다. 이를 활용하면 리소스를 안전하게 격리하고, 사용 제한 및 권한 제어를 쉽게 구현할 수 있다.