Ch03 파드: 쿠버네티스에서 컨테이너 실행

 
3.1 파드 소개

파드
 
한 개 혹은 두 개 이상의 컨테이너를 포함하는 컨테이너 그룹
배포가 이루어지는 단위
 
하나의 컨테이너 내 다중 프로세스 vs 다중 컨테이너 비교
 
컨테이너 내 다중 프로세스를 실행한다면 프로세스의 실행과 로깅이 모두 개발자 책임이 되어버리는 문제가 있기 때문에 하나의 프로세스 당 하나의 컨테이너로 분리해서 관리하는 것이 좋음

파드 내 컨테이너들이 동일하게 공유하는 부분
 
네트워크 네임스페이스, UTS 네임스페이스 (동일한 호스트 이름, ip 주소, 포트 공간)
IPC 네임스페이스
 
파드 내 컨테이너들에게 분리되어있는 부분
 
PID 네임스페이스 (ps aux를 통해 컨테이너 안에서 실행되는 프로세스만 보기)
파일 시스템 (볼륨 개념을 통해 공유 가능)
 
 
하나의 파드에 여러 개의 컨테이너를 모두 넣기 vs 파드 당 하나의 컨테이너로 여러개의 파드 구성하기

1) 파드 당 하나의 컨테이너로 여러개의 파드를 구성
 

• 남는 워커 노드의 자원을 충분이 활용 가능
• 컨테이너의 개별 확장이 가능 (수평적인 스케일링은 파드 별로 이루어지므로)
• e.g 백엔드와 프론트엔드 컨테이너의 파드 분리

 
2) 하나의 파드에 여러 개의 컨테이너를 모두 구성
 

• 애플리케이션이 하나의 주요 프로세스와 하나 이상의 보조 프로세스로 구성되어있을 때 용이
• e.g 특정 디렉토리에서 파일을 제공하는 웹 서버와 외부 소스에서 콘텐츠를 받아오는 사이드카 컨테이너

 
3) 파드에서 여러 컨테이너를 사용할지 말지 판단할 때 생각해볼 것
 

• 컨테이너를 다른 호스트에서 실행 할 수 있는지 생각해보기
• 여러 컨테이너가 하나의 구성 요소인지, 개별적인지 생각해보기
• 컨테이너의 스케일링 단위 생각해보기

 
 
3.2 YAML 또는 JSON 디스크립터로 파드 생성

YAML 파일 작성
 
파드(이름), 컨테이너(이미지, 이름, 포트) 등 정보 작성
 

apiVersion: v1
kind: Pod
metadata:
    name: kubia-manual
spec:
    containers:
        - image: luksa/kubia
          name: kubia
          ports:
          - containerPort: 8080
            protocol: TCP

 
 
파드 생성
 

kubectl create -f kubia-manual.yaml

 
 
파드 전체 정의 확인
 

kubectl get pod kubia-manual -o yaml
Kubectl get pod kubia-manual -o json

 
 
파드 로그 가져오기
 

// 표준 입출력 로그 스트림을 다음 명렁어로 출력 가능
docker logs kubia-manual (파드 이름)

// 파드가 다중 컨테이너를 가질 때 특정 컨테이너 로그 가져오기 가능
docker logs kubia-manual -c kubia (컨테이너 이름)

 

포트 포워딩

로컬 호스트 포트와 파드의 특정 포트를 연결하여 컨테이너에 접속 가능

kubectl port-forward kubia-manual 8888:8080

 
이게 프로세스를 수행시키는 거라서 해당 프로세스를 끄면 포트포워딩이 종료되는 것 같다

 
3.3 레이블을 이용한 파드 구성
 
파드에 레이블을 붙여 파드 분류 가능
 
yaml 파일에 labels 정의
 

apiVersion: v1
kind: Pod
metadata:
    name: kubia-manual-v2
    labels:
        creation_method: manual
        env: prod

spec:
    containers:
        - image: luksa/kubia
          name: kubia
          ports:
          - containerPort: 8080
            protocol: TCP

 

label 확인
 

kubectl get pods —show-labels
Kubectl get pods -L creayion_method, env (특정 라벨만 확인)

label 변경 및 overwrite
 

Kubectl label pod kubia-manual-v2 env=debug (이미 지정된 레이블 값을 바꿀 시 —overwrite 추가)

 
 
3.4 레이블 셀렉터를 이용한 파드 부분 집합 나열
 

kubectl get pods -l {레이블 조건}
kubectl get pods -l env // env 레이블이 있는 파드 선택
kubectl get pods -l ‘!env’ // env 레이블이 없는 파드 선택
kubectl get pods -l ‘env=debug’ //env 레이블의 값이 debug 인 파드만 선택
Kubectl get pods -l ‘env in (debug, prod)’
kubectl get pods -l ‘env not in (debug, prod)’

 
 
3.5 레이블 셀렉터를 이용해 파드 스케줄링 제한

파드 뿐만 아니라 노드에도 라벨 붙이기 가능
 

Kubectl label nodes {노드 이름} gpu=true // gpu=true 라벨 붙이기

이후 파드 생성 매니페스트에 특정 조건을 만족시키는 노드에 배정되도록 명시하면 쿠버네티스가 해당 라벨이 붙어있는 노드를 찾아 스케줄링(특정 노드를 직접 적으로 기술할 수도 있으나 그것 보다는 노드 조건을 명시하고 쿠버네티스가 조건을 만족하는 노드를 찾는 흐름이 좋다)


3.6 파드에 어노테이션 달기
 
설명, 주석 같은 개념으로 라벨과 달리 셀렉터 기능 불가

kubectl annotate pod kubia-manual mycompany.com/someannatation=“foo bar”
kubectl describe pod kubia-manual // 애노테이션 확인 가능

 
 
3.7 네임스페이스를 사용한 리소스 그룹화

네임스페이스를 분리하면 해당 네임스페이스 안에서 독립적으로 리소스 사용 가능
(다른 네임스페이스라면 중복된 이름을 가진 파드를 만드는 것이 가능하다)

// 네임스페이스 생성
kubectl create namespace custom-namespace

// 파드를 custom-namespace 네임스페이스 내에서 생성
kubectl create -f kubia-manual.yaml -n custom-namespace 

// 해당 네임스페이스 안에 있는 파드만 보기
Kubectl get pods —namespace custom-namespace

 
 
3.8 파드의 중지와 제거
 

// 이름으로 특정 파드만 삭제
kubectl delete pods kubia-gpu 

// 특정 라벨을 가지는 파드들 삭제
kubectl delete pods -l creation_method=manual

// 네임스페이스 삭제 + 네임스페이스가 삭제되면서 내부 파드들도 다 삭제
kubectl delete namespace custom-namespace 

// 네임스페이스는 놔두고 네임스페이스 안에 있는 파드들만 모두 삭제
kubectl delete pods -all 

// 파드 뿐만 아니라 레플리케이션 컨트롤러, 서비스 등도 모두 삭제
kubectl delete all -all

 
 
특정 노드를 제거하더라도 레플리케이션컨트롤러에 복제 목표 개수가 지정되어있는 경우 계속 노드가 재생성 될 수 있다 (레플리케이션컨트롤러를 먼저 삭제해야)