[Kubernetes] Pod 파해치기 1 - label, nodeSelector, env, volume, resource

쿠버네티스의 가장 기본  Pod리소스에 대해 자세히 알아보려 합니다.
Pod를 이해하는 것이 쿠버네티스의 핵심을 이해하는 길이라 합니다. 허허 
열심히 해봅시다.

 

Pod는 쿠버네티스의 최소 실행 단위입니다.

그 어떤 프로세스 하나를 실행 시키려 해도 Pod를 통해 수행되지요.

 

가상환경 플랫폼 실행 단위

• 가상머신: Instance
• 도커: Container
• 쿠버네티스: Pod

Pod의 특징

Pod는 다음과 같은 특징을 갖습니다.

 

1개 이상의 컨테이너 실행

보통 1개 Pod 내에 한개 컨테이너를 실행하지만, 두 세개까지도 실행합니다.

(이론상 3개 이상도 가능하지만 실질적으로 3개 이상 넘어가근 경우는 거의 없다고 합니다.)

 

동일 노드에 할당

Pod 내에 실행되는 컨테이너들은 반드시 동일 노드에 할당됩낟.

이들은 동일한 생명주기를 갖고 Pod 삭제 시 Pod 내 모든 컨테이너가 같이 삭제됩니다.

 

고유의 Pod IP

Pod 리소스는 노드IP와 별개로 클러스터 내에서 접근 가능한 고유IP를 할당받습니다.

도커 컨테이너인 경우 다른 노드에 위치한 컨테이너간의 통신을 위해 포트 포워딩을 이용해 노드IP와 포워딩 포트를 이용해 접근합니다. 쿠버네티스에선 다른 노드에 위치한 Pod라도 NAT 통신 없이 Pod 고유의 IP를 이용하여 접근할 수 있습니다.

 

IP 공유

Pod내에 있는 컨테이너들은 서로 IP를 공유합니다.

Pod내의 컨테이너 끼리는 localhost로 접근 가능호고 포트로 구분합니다.

 

Volumn 공유

Pod안의 컨테이너들은 동일한 볼륨과 연결이 가능해 파일 시스템을 기반으로 서로 파일을 주고 받을 수 있습니다.

 

쿠버네티스의 모든 리소스는 YAML 형태의 선언형 명령 정의서로 표현될 수 있습니다.

하나 만들어봅시다.

아래 명령어를 사용하면 Pod를 실제 생성하지 않고 템플릿 파일을 생성 할 수 있습니다.

# mynginx.yaml 이라는 YAML 정의서 생성
kubectl run mynginx --image nginx --dry-run=client -o yaml > mynginx.yaml

 

vi를 통해 생성된 yaml파일을 열면 다음과 같습니다.

위에 있는 property말고 더 존재하지만 Pod를 구성하기 위한 최소 property부터 설명해보겠습니다.

 

• apiVersion - 모든 리소스는 이 property를 가집니다. 리소스 이름 충돌을 피하기 위한 목적으로 리소스의 scope을 정의한 것입니다.
• kind - 리소스 타입을 정의합니다. 
• metadata - 리소스의 메타 정보를 나타냅니다.
  • labels - 리소스의 라벨 정보를 표기합니다.
  • name - 리소스의 이름을 표기합니다.
• spec - 리소스의 스펙을 정의합니다. 이는 리소스마다 조금씩 다르게 정의됩니다.
  • containers - 1개 이상의 컨테이너를 정의합니다.
    1. name: 컨에이너 이름 표기
    2. image: 컨테이너 이미지 주소 지정

위  YAML로 Pod를 생성해봅시다.

 

Pod를 생성하면 다음과 같은 순서로 Pod가 생성됩니다.

1. 사용자가 kubectl로 Pod정의를 마스터에 전달합니다.
2. 마스터는 YAML 정의의 유효성 체크 후 특정 노드에 사용자의 요청에 따라 컨테이너를 실행하도록 명령합니다.
3. 명령을 받은 노드는 요청 사항에 맞게 실제 컨테이너를 노드에 실행합니다.

파드의 새로운 기능을 소개할 때마다 그에 따라 Pod spec에 새로운 property가 추가됩니다.

 

라벨링 시스템

라벨링 시스템은 쿠버네티스에서 정말 중요한 메커니즘 중 하나입니다.

특정 시스템을 참조하거나 Pod에 트래픽을 전달할 때 등에 사용되지요.

라벨링 자체로는 큰 기능이 없긴 합니다.

단순 key, value 형태의 문자열입니다.

라벨을 추가하는 방법은 Pod의 metadata property에 key, value 문자열을 추가하면 됩니다.

단순하지만 이는 다양한 방법에 활용이 가능합니다.

 

Pod에 라벨 부여하기

Pod에 라벨을 부여하는 방법은 크게 2가지 있습니다.

 

label 명령을 이용

아래처럼 label 명령어를 이용하거나

kubectl label pod mynginx hello=world
# pod/mynginx labeled

 

 

선언형 명령을 이용

직접 YAML 정의서에 추가할 수 있지요

(metadata안 labels를 통해 부여합니다.)

 

또한 kubectl run <NAME> 명령으로 라벨을 추가 할 수 있습니다.

kubectl run hello --image nginx
# pod/hello created

위 명령을 실행하면 run=hello 라벨을 자동으로 Pod에 추가할 수 있습니다.

 

라벨 정보 확인하기

Pod에 부여된 라벨을 확인하려면 -L 옵션을 사용하면 됩니다.

키 run에 대한 값을 다음과 같이 볼 수 있죠.

# 키 run에 대한 값 표시
kubectl get pod mynginx -L run

 

특정 라벨이 아닌 전체 라벨을 확인하고 싶다면 --show-labels 옵션을 사용합니다.

# 모든 라벨 정보 표시
kubectl get pod mynginx --show-labels

 

라벨 활용 조건 필터링

특정 라벨을 가진 Pod만 필터해서 보기 보려면 -l 옵션을 사용합니다.

특정 key를 기준으로 필터가 가능하고 key, value  전체를 이용하여 피터링 할 수 있습니다.

# 새로운 yournginx Pod 생성
kubectl run yournginx --image nginx

# key가 run인 Pod들 출력
kubectl get pod -l run

# key가 run이고 value가 mynginx인 Pod 출력
kubectl get pod -l run=mynginx


# key가 run이고 value가 yournginx Pod 출력
kubectl get pod -l run=yournginx

 

nodeSelector를 이용한 노드 선택

라벨링 시스템을 이용해 Pod가 특정 토드에 할당되도록 스케줄링 할 수 있습니다.

기본적으론 쿠버네티스 마스터가 어떤 노드 위에서 Pof를 실행할지 스케줄링합니다.

쿠버네티스는 클러스터링 시스템이어서 사용자가 매번 노드를 선택할 필용 없이 알아서 Pod 스케줄링을 관리합니다.

 

하지만 간혹 특정 노드를 명시적으로 선택해 실행하고 싶을때가 있지요.

예로 A라는 노드는 디스크가 SSD로 설정되어 있고 B라는 노드는 디스크가 HDD로 설정됐다면,

특정 Pod에 한해 SSD 디스크를 사용해야 할 수 있습니다. 

바로 이때 nodeSelector라는 Property를 이용해 노드를 선택할 수 있습니다.

 

노드엔 기본적으로 설정된 라벨들이 많습니다.

여기에 disktype라는 라벨을 추가해 봅시다.

마스터 노드에 diskytype=ssd 라벨을 부여,

워커 노드에 diskytype=hdd 라벨을 부여합니다.

Pod와 마찬가지로 노드에 label 명령을 사용할 수 있습니다.

 

각 노드에 라벨이 잘 적용 됐으면 실행하고자 하는 Pod의 YAML 정의서에 nodeSelector property를 추가합니다.

 

특정 노드를 지정한 Pod를 실행하면 지정한 노드에 잘 올라가는 것을 볼 수 있습니다.

이처럼 Spec property에 nodeSelector를 이용하여 원하는 노드를 선택할 수 있습니다.

 

실행 명령 및 파라미터 지정

Pod 생성 시, 실행 명령과 파라미터를 전달할 수 있습니다.

이번엔 nginx말고 사용자가 원하는 명령으로 실행해봅시다.

지금까지 사용한 nginx 이미지에 실행 명령(command)과 파라미터(args)를 수정했을 때 Pod가 어떻게 동작하는지 봅시다.

• commend - 컨테이너의 시작 실행 명령을 지정합니다.
• args - 실행 명령에 넘겨줄 파라미터를 지정합니다.
• restartPolicy - Pod의 재시작 정책을 설정합니다.
  • Always: Pod 종료 시 항상 재시작을 시도 (default)
  • Never: 재시작을 시도하지 않음
  • OnFailure: 실패 시에만 재시작을 시도 ? -> echo명령은 실행 후 종료라 실패시에만 재시작함, 안그러면 반복 실행 됨

apply -f로 실행하면 hello메시지를 출력하고 완료된 상태인걸 볼 수 있습니다.

 

기본 이미지의 실행 명령 외에 사용자가 원하는 실행 명령을 지정하고 싶을 때 사용할 수 있는 기능입니다.

 

환경변수 설정

이번엔 Pod에 환경 변수를 전달하는 법을 알아봅시다.

간단히 env property를 활용하여 간단히 환경변수를 설정할 수 있습니다.

env로 환경변수를 설정하는 property를 선언하고,

name은 환경변수의 key를,

value는 환경변수의 value를 지정합니다.

 

Pod 생성 후 exec명령어로 실행 중인 env Pod에 printenv 명령을 전달하면,

다음과 같이 잘 나오게 됩니다.

 

볼륨을 연결해봅시다.

Pod 내부 스토리지의 생명주기는 Pod와 동일하게 사라지면 저장된 데이터도 삭제됩니다.

Pod내에서 생성된 데이터를 Pod 생명주기와 상관없이 지속적으로 저장하고 싶다면 볼륨을 따로 연결해야 합니다.

쿠버네티스엔 여러 볼륨 타입이 있지만 가장 기본인 host Volume을 사용해 실습해봅시다.

host Volume은 도커 -v 옵션과 유사하게 host 서버의 볼륨 공간에 Pod가 데이터를 저장하는 것을 말합니다.

 

아래 YAML로 Pod를 생성해봅시다.

• volumeMounts - 컨테이너 내부에 사용될 볼륨을 선언합니다.
  • mountPath: 컨테이너 내부에 볼륨이 연결될 위치를 지정합니다.
  • name: volumeMounts와 volums을 연결하는 식별자로 사용됩니다.
• volumes - Pod에서 사용할 volume을 지정합니다.
  • name: volumeMounts와 volums을 연결하는 식별자로 사용됩니다.
  • hostPath: 호스트 서버의 연결 위치를 지정합니다.

이렇게 지정하면 Pod 내 /container-volume 내부와 /home 디렉토리가 동일한걸 볼 수 있습니다.

 

어 근데 왜 다르죠?

Pod가 worker노드에서 실행되고 있어서 worker노드의 /home이랑 동기화 된겁니다.

worker 노드에서 다시 ls /home을 하면 Pod의 볼륨과 같은걸 볼 수 있습니다.

 

 

또한, Pod내에서 임시로 생성하는 emptyDir property도 존재합니다.

# volume-empty.yaml
apiVersion: v1
kind: Pod
metadata:
  name: volume-empty
  labels:
    name: volume-empty
spec:
  containers:
  - name: nginx
    image: nginx
    volumeMounts: # 컨테이너 내부의 연결 위치 지정
    - name: shared-storage
      mountPath: /container-volume
  - name: redis
    image: redis
    volumeMounts:
    - name: shared-storage
      mountPath: /container-volume
  volumes: 
  - name: shared-storage
    emptyDir: {}

 

이러면 두 컨테이너끼리 파일 데이터를 주고받을 수 있지요.

emptyDir은 Pod의 생명주기를 따라가는 임시 volume입니다.

이는 컨테이너 내부에 데이터를 저장하는 것과 별반 다르지 않지만,

여러 컨테이너가 서로 디렉터리 공간을 공유할 수 있다는 점이 있습니다.

 

리소스 관리

이 리소스는 쿠버네티스 리소스가 아닌 컴퓨팅 자원 관리에 관한 내용입니다.

쿠버네티스는 컨테이너 실행에 필요한 리소스를 제약할 수 있습니다.

resource라는 property를 활용하여 리소스를 관리합니다.

resources는 최소 리소스 사용량을 보장해주는 requests, 최대 리소스 사용량을 제한하는 limits preperty가 있습니다.

 

requests - 최소 리소스 사용량 정의

# requests.yaml
apiVersion: v1
kind: Pod
metadata:
  name: requests
spec:
  containers: 
  - name: nginx
    image: nginx
    resources:
      requests:
        cpu: "250m"
        memory: "500Mi"

 

cpu에서 1000m은 1core를 뜻합니다. 위 250m은 0.25core를 의미하지요

memory의 Mi는 1MiB(2^20 bytes)를 의미합니다.

 

limits - 최대 리소스 사용량 정의

# limits.yaml
apiVersion: v1
kind: Pod
metadata:
  name: limits
spec:
  restartPolicy: OnFailure
  containers: 
  - name: mynginx
    image: python:3.7
    command: [ "python" ]
    args: [ "-c", "arr = []\nwhile True: arr.append(range(1000))" ]
    resources:
      limits:
        cpu: "500m"
        memory: "1Gi"

 

이러면 이 컨테이너는 최대 0.5cpu와 1Gi 메모리 사용량을 넘을 수 없습니다.

최대 리소스 사용량을 넘으면

CPU는 throttling이 발생하고,

메모리는 Out of Memory 에러가 발생합니다.

 

최대 메모리 리소스 사용량을 넘으면 강제로 프로세스가 중단됩니다.

쿠버네티스의 이러한 기능을 통해 특정 프로세스의 리소스 소진이 전체 서버에 영향을 주지 않고 해당 프로세스에만 영향을 미쳐 전체적을 안정된 운영이 가능합니다.