6. Core Concepts - pod

2024. 6. 24. 02:23·Kubernetes
이 글은 아래 자료를 참고하여 작성되었습니다.

Udemy [Kubernetes For the Absolute Beginners]

 

1. pod이란?

쿠버네티스를 사용하면 애플리케이션을 컨테이너 형태로 클러스터의 여러 워커 노드에 배포할 수 있다. 하지만 쿠버네티스는 컨테이너를 직접 워커 노드에 배포하지 않고, pod라는 쿠버네티스 객체에 캡슐화하여 배포한다. pod은 쿠버네티스에서 생성할 수 있는 가장 작은 단위로, 단일 애플리케이션 인스턴스를 의미한다. 가장 간단한 예로, 단일 노드 쿠버네티스 클러스터에서 하나의 애플리케이션 인스턴스가 하나의 도커 컨테이너로 실행되고, 이는 하나의 pod에 캡슐화된다.

 

2. pod의 생성과 확장

  • 사용자 수가 증가하면 애플리케이션의 인스턴스를 추가하여 부하를 분산해야 한다. 이때 동일한 pod 내에 새로운 컨테이너 인스턴스를 생성하는 것이 아니라, 새로운 pod를 생성한다.
  • pod와 컨테이너는 보통 1:1 관계를 가지며, 확장을 위해서는 새로운 pod을 생성하고, 축소를 위해서는 pod을 삭제한다.

 

3. 다중 컨테이너 pod

  • pod는 일반적으로 단일 컨테이너를 포함하지만, 경우에 따라 여러 컨테이너를 포함할 수도 있다. 이 경우 보통 동일한 유형의 컨테이너가 아니라, 애플리케이션 컨테이너를 지원하는 헬퍼 컨테이너가 포함된다.
  • 이러한 헬퍼 컨테이너는 데이터 처리, 파일 업로드 처리 등 보조 작업을 수행하며, 같은 pod 내에서 애플리케이션 컨테이너와 함께 생성되고 제거된다.
  • 이러한 컨테이너들은 동일한 네트워크 네임스페이스를 공유하여 'localhost'로 서로 통신할 수 있고, 동일한 스토리지 공간을 쉽게 공유할 수 있다.

 

4. 도커 container vs 쿠버네티스 pod

4-1. 도커 container 사용

단순히 도커 컨테이너를 사용하여 애플리케이션을 배포하는 과정을 생각해 보면, 처음에는 docker run [application] 명령어를 사용하여 애플리케이션을 배포하고 사용자가 이에 접근할 수 있다. 그러나 사용자가 늘어나면 더 많은 애플리케이션 인스턴스를 배포해야 하고, 이를 위해 여러 번 docker run 명령어를 실행해야 한다.

애플리케이션이 발전하고 복잡해지면, 보조 작업을 수행하는 새로운 헬퍼 컨테이너가 필요할 수 있다. 이 헬퍼 컨테이너는 애플리케이션 컨테이너와 일대일 관계를 유지하며, 직접 통신하고 데이터를 공유해야 한다. 이를 위해 각 컨테이너 간의 네트워크 연결을 설정하고 공유 가능한 볼륨을 만들어야 하며, 애플리케이션 컨테이너가 종료되면 헬퍼 컨테이너도 수동으로 종료시켜야 한다. 새로운 컨테이너가 배포될 때마다 새로운 헬퍼 컨테이너도 배포해야 한다.

4-2. 쿠버네티스 pod을 사용

쿠버네티스의 pod을 사용하면 이러한 작업이 자동으로 처리된다. 우리는 pod가 어떤 컨테이너로 구성되는지만 정의하면 된다. pod 내의 컨테이너는 기본적으로 동일한 스토리지, 네트워크 네임스페이스, 운명을 공유하여 함께 생성되고 함께 삭제된다.

애플리케이션이 단일 컨테이너로 충분히 작동하더라도 쿠버네티스는 pod을 생성하도록 강제한다. 이는 애플리케이션의 미래 아키텍처 변경 및 확장에 대비할 수 있게 한다.

 

 

5. Pod 정의 및 생성

# pod.yaml

apiVersion: v1
kind: Pod
metadata:
    name: nginx
    labels:
        app: nginx
        tier: frontend
spec:
    containers:
    -   name: nginx
        image: nginx
  • metadata: Pod에 대한 메타데이터를 제공
    • name: pod의 고유 이름
    • labels: Key-Value 쌍으로 구성된 라벨. 라벨은 리소스를 식별하고, 선택하며, 조직화하는 데 사용된다. 사용자는 자신의 요구에 맞춰 어떤 값이든 라벨로 사용할 수 있지만, 일관된 네이밍 컨벤션을 사용하는 것이 좋다.
  • spec: Pod의 경우 spec에 containers(컨테이너 목록)가 포함되어야 한다. 이 예제에서는 하나의 컨테이너만 포함하고 있다.
    • name: 컨테이너의 이름을 nginx로 설정
    • image: 사용할 Docker 이미지를 nginx로 설정
# 새로운 리소스를 생성
# 이미 존재하는 리소스를 생성하려고 하면 오류가 발생
kubectl create -f pod.yaml

# 리소스를 생성하거나 업데이트
# 리소스가 존재하지 않으면 생성하고, 존재하면 변경된 부분만 업데이트
kubectl apply -f pod.yaml

# pod 상태 확인
# NAME  READY  STATUS  RESTARTS  AGE
# READY: [running containers in pod] / [total containers in pod]
kubectl get pods

# -o wide 옵션으로 더 많은 정보 조회 가능
# NAME  READY  STATUS  RESTARTS  AGE  IP  NODE  [NOMINATED NODE]  [READINESS GATES]
kubectl get pods -o wide

# pod 상세 정보 확인
kubectl describe pod nginx

# pod 설정 편집
# 현재 실행중인 configuration 파일이 vim editor로 열린다. 
# 이 파일은 실제 리소스를 생성할 때 작성한 파일이 아니라 쿠버네티스가 메모리에서 임시로 생성한 파일로, 기존 객체의 구성을 편집할 수 있게 해준다.
# 이 파일에서 변경한 사항은 파일을 저장하자마자 클러스터의 실행 중인 구성에 직접 적용되므로, 매우 주의해야 한다.
kubectl edit pod nginx

# pod 삭제
kubectl delete pod nginx


# 특정 이미지로 빠르게 pod을 생성하고 싶을 때는 kubectl run을 사용할수도 있다.
# kubectl run [pod 이름] --image=[이미지 이름]
kubectl run nginx --image=nginx
# dry run 
# 실제로 리소스를 생성하거나 변경하지 않고, 명령어가 실행될 경우 어떤 결과가 나올지를 미리 확인할 수 있도록 해주는 기능

kubectl apply -f pod.yaml --dry-run=client  # 클라이언트 측에서 pod.yaml 파일을 검토하고, 리소스가 유효한지 확인하지만 실제로 Pod을 생성하지는 않습니다.
kubectl apply -f pod.yaml --dry-run=server  # 서버 측에서 pod.yaml 파일을 검토하고, 리소스가 유효한지 확인하지만 실제로 Pod을 생성하지는 않습니다.


# 실제 예시
➜  k8s-beginner kubectl get pods
NAME    READY   STATUS    RESTARTS   AGE
nginx   1/1     Running   0          17m

➜  k8s-beginner kubectl create -f pod.yaml --dry-run=client
pod/nginx created (dry run)

➜  k8s-beginner kubectl create -f pod.yaml --dry-run=server
Error from server (AlreadyExists): error when creating "pod.yaml": pods "nginx" already exists

➜  k8s-beginner kubectl apply -f pod.yaml --dry-run=server
pod/nginx unchanged (server dry run)

➜  k8s-beginner kubectl create -f nginx.yaml --dry-run=client
pod/nginx-2 created (dry run)

➜  k8s-beginner kubectl create -f nginx.yaml --dry-run=server
pod/nginx-2 created (server dry run)

## 테스트 이후 확인해보면, 실제로 pod이 생성되지 않았음을 알 수 있다.
➜  k8s-beginner kubectl get pods
NAME    READY   STATUS    RESTARTS   AGE
nginx   1/1     Running   0          18m


# -o yaml 옵션은 kubectl 명령어를 사용하여 쿠버네티스 리소스의 출력을 YAML 형식으로 출력하도록 지정한다.
# 이 옵션은 리소스의 상세한 구성을 확인하거나, 해당 리소스를 YAML 파일로 저장할 때 유용하다
➜  k8s-beginner kubectl create -f nginx.yaml --dry-run=server -o yaml
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: "2024-06-24T14:16:26Z"
  labels:
    env: production
  name: nginx-2
  namespace: default
  uid: 85d3ff66-5bff-4fbe-a067-dc04fcc412d2
spec:
  containers:
  - image: nginx
    imagePullPolicy: Always
    name: nginx
    ...

'Kubernetes' 카테고리의 다른 글

8. Core Concepts - Deployment  (0) 2024.07.04
7. Core Concepts - ReplicaSet  (0) 2024.06.25
5. Introduction - Minikube  (1) 2024.06.24
4. Introduction - Kubernetes with YAML  (1) 2024.06.24
3. Introduction - YAML  (0) 2024.06.18
'Kubernetes' 카테고리의 다른 글
  • 8. Core Concepts - Deployment
  • 7. Core Concepts - ReplicaSet
  • 5. Introduction - Minikube
  • 4. Introduction - Kubernetes with YAML
SerenaDev
SerenaDev
나의 기술블로그 입니다.
  • SerenaDev
    나의 기술블로그
    SerenaDev
    • 분류 전체보기 (33)
      • FastAPI (1)
      • Iceberg (6)
      • Kubernetes (24)
      • ETC (1)
      • 독서 (1)
  • hELLO· Designed By정상우.v4.10.0
SerenaDev
6. Core Concepts - pod
상단으로

티스토리툴바