파드
k8s에서 관리하는 가장 작은 배포 단위로, 컨테이너를 관리하는 기본 단위이다.
도커는 컨테이너를 만들지만, k8s는 컨테이너 대신 파드를 만든다. 파드는 한 개 또는 여러 개의 컨테이너를 포함한다.
노드와 파드 (출처: ooeunz.tistory.com/119)
각 파드는 어플리케이션을 실행하는 자체 IP, 호스트 이름, 프로세스 등이 있는 별도의 논리적 시스템이다. 파드는 고유한 IP와 컨테이너가 하나 이상 있으며, 파드 하나 안에 있는 컨테이너들이 IP 하나를 공유한다. 각 컨테이너에서는 어플리케이션 프로세스가 실행된다. 파드는 여러 개의 워커 노드에 분산돼 있다.
즉, 파드는 자체 IP 주소와 호스트 이름을 가진 별도의 독립적인 시스템처럼 작동한다.
파드의 필요성
컨테이너는 프로세스 자체가 하위 프로세스를 생성하지 않는 한 컨테이너당 하나의 프로세스만 실행하도록 설계됐다.
컨테이너 하나 안에 프로세스를 2개 실행하도록 설정하는 것은 간단하지 않다. 관련 없는 여러 프로세스를 하나의 컨테이너에서 실행하는 경우를 예를 들어, 충돌이 발생한 경우 개별 프로세스를 자동으로 다시 시작하는 매커니즘을 포함시켜야 하고 모든 프로세스는 동일한 표준 출력으로 로그를 남기기 때문에 어떤 프로세스가 어떤 내용을 기록했는지 파악하기 어려울 수 있다. 이렇게 번거롭고 컨테이너의 관리 효율도 낮아진다.
그렇기 때문에 컨테이너를 단일 단위로 관리할 수 있는 상위 레벨 구조가 파드다. 파드는 밀접하게 연관된 프로세스를 함께 실행하고 마치 하나의 컨테이너에서 실행되는 것처럼 동일한 환경을 제공하면서 다소 격리된 상태로 유지한다.
파드 정의
apiVersion: v1 # 오브젝트 api 버전
kind: Pod # 리소스 종류
metadata: # 메타데이터. name, label, annotation으로 구성
name: nginx # 파드 이름
spec: # 상세 명세 (리소스 종류마다 다르다)
containers:
- name: nginx
image: nginx:1.14.2 # 생성할 컨테이너의 이미지
ports:
- containerPort: 80 # 응답 대기할 어플리케이션 포트apiVersion, kind, metadata, spec는 리소스를 정의할 때 반드시 필요한 요소이다.
파드의 생명 주기
파드는 생성부터 삭제까지의 과정에 생명주기(lifecycle)가 있다.
⌛ Pending : k8s 시스템에 파드를 생성하는 중임을 뜻한다. 이 상태는 컨테이너 이미지를 다운로드한 후 전체 컨테이너를 실행하는 도중이기 때문에 파드 안의 전체 컨테이너가 실행될 때까지 시간이 걸린다.
⌛ Running : 파드 안 모든 컨테이너가 실행 중인 상태를 뜻한다. 1개 이상의 컨테이너가 실행중이거나 시작 또는 재시작 상태일 수 있다.
⌛ Succeeded : 파드 안 모든 컨테이너가 정상 실행 종료된 상태로 재시작되지 않는 상태를 뜻한다.
⌛ Failed : 파드 안 모든 컨테이너 중 정상적으로 실행 종료되지 않은 컨테이너가 있는 상태를 뜻한다. 컨테이너 종료 코드가 0이 아니면 비정상 종료이거나 시스템이 직접 컨테이너를 종료한 것이다.
⌛ Unknown : 파드의 상태를 확인할 수 없는 상태를 뜻한다. 보통 파드가 있는 노드와 통신할 수 없을 때이다.
라벨과 라벨 셀렉터
파드는 수십, 수백 개가 생성될 수 있다. 그것들을 조직화하는 매커니즘이 없다면 굉장히 복잡해질 것이다.
라벨은 리소스에 첨부하는 임의의 키/값 쌍이며 라벨 셀렉터를 사용해 리소스를 선택할 수 있다. 라벨과 라벨 셀렉터를 통해 여러 파드의 작업을 한 번에 쉽게 수행할 수 있다.
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위 파드는 environment:production과 app:nginx 2개의 레이블이 있다.
라벨 셀렉터를 사용하는 커맨드는 다음과 같다.
# 특정 label 선택
$ kubectl get pods -l creation_method=manual
# label의 value와 상관없이 env label을 포함하는 pod 선택
$ kubectl get pods -l env
# env label을 포함하지 않는 pod 선택
$ kubectl get pods -l '!env'
# 다중 선택
$ kubectl get pods -l env=prod,creation_method=manual 노드 라벨 및 셀렉터
노드에도 라벨을 붙일 수 있다. 노드 라벨 및 셀렉터를 사용해 특정 기능이 있는 노드에만 파드를 스케줄할 수 있다.
apiVersion: v1
kind: Pod
metadata:
name: kubia-gpu
spec:
nodeSelector:
gpu: "false" # gpu=false 라벨을 포함하는 노드에만 파드를 배포하도록 지시
containers:
- image: luksa/kubia
name: kubia어노테이션 (주석)
라벨 외에도 파드나 그 밖의 객체에 주석을 넣을 수 있다. 주석은 라벨과 같이 키/값 쌍이지만, 식별 정보를 보유하지는 않는다.
주석은 훨씬 더 많은 정보(총 256kb)를 담을 수 있으며 k8s 클라이언트나 라이브러리가 자원을 관리하는 데 활용한다. 예를 들어 릴리즈 정보, 로깅, 모니터링에 필요한 정보들 등의 사용자에게 필요한 정보들을 메모하는 용도로도 사용될 수 있다.
각 파드나 API 객체 설명이 추가되기 때문에 클러스터를 사용하는 모든 사람이 각 객체의 정보를 빠르게 찾을 수 있다.
어노테이션을 사용하면 사용자나 도구 및 라이브러리를 통해 더 큰 크기의 데이터를 파드에 첨부할 수 있다.
apiVersion: v1
kind: Pod
metadata:
annotatoions: # 주석
manager: "myadmin"
release-versions: 'v1.0'
...# 주석 추가
$ kubectl annotate pod kubia-manual mycompany.com/comeannotation="foo bae"
# 주석 확인
$ kubectl describe pod kubia-manual고유한 접두사를 사용하지 않으면 의도치않게 주석을 덮어쓸 수 있다.
라벨을 통해 k8s 클러스터 안에서 사용자가 오브젝트를 생성할 때 해당 오브젝트를 구분하고,어노테이션을 통해 k8s 시스템에서 필요한 정보들을 표시하는 데 사용한다.
네임스페이스
네임스페이스는 k8s 클러스터 하나를 여러 개의 논리적인 단위로 나눠서 사용하는 것이다. 네임스페이스를 통해 k8s 클러스터 하나를 여러 개 팀이나 사용자가 함께 공유할 수 있다. 네임스페이스가 리소스 이름의 범위를 제공하기 때문에 다른 사용자의 리소스를 부주의하게 수정하거나 삭제하지 않도록 특별히 주의할 필요가 없으며 이름의 충돌에 신경 쓸 필요가 없다.
리소스를 격리하는 것 이외에도 네임스페이스는 특정 사용자에게만 특정 리소스를 접근을 허용하고 심지어 개별 사용자가 사용할 수 있는 컴퓨팅 리소스의 양을 제한하는 데도 사용된다.
🧩 네임스페이스 생성
$ kubectl create namespace 네임스페이스이름🧩 네임스페이스 조회
$ kubectl get namespaces
NAME STATUS AGE
default ACTIVE 32m
kube-node-lease ACTIVE 32m
kube-public ACTIVE 32m
kube-system ACTIVE 32mdefault: 기본 네임스페이스이다. k8s에서 명령을 실행할 때 별도의 네임스페이스를 지정하지 않는다면 항상 default 네임스페이스에 명령을 적용한다.kube-node-lease: k8s 시스템에서 관리하는 네임스페이스이다. 이 네임스페이스에는 k8s 관리용 파드나 설정이 있다.kube-public: 클러스터 안 모든 사용자가 읽을 수 있는 네임스페이스이다. 보통 클러스터 사용량 같은 정보를 관리한다.kube-system: 각 노드의 임대(lease) 오브젝트들을 관리한다. k8s 1.13 이후 알파 기능으로 추가되었다.
🧩 네임스페이스 삭제
$ kubectl delete ns 네임스페이스 이름네임스페이스 삭제 시 해당 네임스페이스를 가진 파드 역시 삭제된다.
네임스페이스를 사용하면 서로 다른 팀이 k8s 클러스터를 사용하는 것처럼 동일한 클러스터를 사용할 수 있다.
References
