[쿠버네티스 인 액션] 3. 파드: 쿠버네티스에서 컨테이너 실행 (2)

3.3 레이블을 이용한 파드 구성

• 어떤 파드가 어떤 것인지 쉽게 알 수 있도록 임의의 기준에 따라 작은 그룹으로 조직하는 방법이 필요하다.
• 각 파드에 대한 개별적인 작업 보다는 그룹에 속한 모든 파드를 한번에 작업하기를 원할 것이다.
• 레이블을 통해 파드와 기타 다른 쿠버네티스 오브젝트의 조직화가 이뤄진다.

---

3.3.1 레이블 소개

• 레이블은 리소스에 첨부하는 키-값 쌍으로, 이 쌍은 레이블 셀렉터를 사용해 리소스를 선택할 때 활용된다.

• 두 레이블을 추가해 그림처럼 파드를 2차원으로 구성했다.
  • app : 파드가 속한 애플리케이션, 구성 요소 혹은 마이크로 서비스를 지정한다.
  • rel : 파드에서 실행중인 애플리케이션이 stable, 베타 혹은 카나리 릴리스인지 보여준다.

---

3.3.2 파드를 생성할 때 레이블 지정

• 먼저 다음과 같이 yaml 파일을 생성한다.

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

• 레이블 creation_method=manual과 env=prod를 metadata.labels에 포함했다.
• 이제 파드를 생성한다.

$kubectl create -f kubia-manual-with-labels.yaml

• kubectl get pods 명령은 레이블을 표시하지않는게 기본값이라 --show-labels 스위치를 사용해 레이블을 볼 수 있다.

$kubectl get po --show-labels

• 특정 레이블에만 관심이 있는 경우 -L 스위치로 지정해 표시할 수 있다.

$kubectl get po -L creation_method,env

---

3.3.3 기존 파드 레이블 수정

• 기존에 생성했던 kubia-manual 파드에 레이블을 추가해보자.

$kubectl label po kubia-manual creation_method=manual

• --overwrite 옵션을 사용해서 kubia-manual-v2 파드의 env=prod 레이블은 env=debug로 변경하자.

$kubectl label po kubia-manual-v2 env=debug --overwrite

---

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

• 레이블 셀렉터는 특정 레이블로 태그된 파드의 부분 집합을 선택해 원하는 작업을 수행한다.
• 레이블 셀렉터는 다음 기준에 따라 리소스를 선택한다.
  • 특정한 키를 포함하거나 포함하지 않는 레이블
  • 특정한 키와 값을 가진 레이블
  • 특정한 키를 갖고 있지만, 다른 값을 가진 레이블

---

3.4.1 레이블 셀렉터를 사용해 파드 나열

• creation_method=manual 레이블을 붙인 모든 파드를 보려면 다음 명령을 실행한다.

$kubectl get po -l creation_method=manual

• env 레이블을 가지고 있지 않은 파드는 다음 명령으로 볼 수 있다.

$kubectl get po -l '!env'

• 마찬가지로 다음 레이블 셀렉터를 이용해 일치하는 파드를 찾을 수 있다.
  • creation_method!=manual : creation_method 레이블을 가진 파드 중에 값이 manual이 아닌 것
  • env in (prod, devel) : env 레이블 값이 prod 또는 devel로 설정된 파드
  • env notin (prod, devel) : env 레이블 값이 prod,devel이 아닌 파드

---

3.4.2 레이블 셀렉터에서 여러 조건 사용

• 셀렉터는 쉼표로 구분된 여러 기준을 포함하는 것도 가능하다.
• 레이블 셀렉터는 파드 목록을 나열하는 것뿐만 아니라, 파드 부분 집합에 작업을 수행할 때도 유용하다.

---

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

• 지금까지 생성한 모든 파드는 워커 노드 전체에 걸쳐 무작위로 스케줄링 됐고 이것이 쿠버네티스의 적절한 동작 방식이다.
• 하지만 스케줄링할 위치를 결정할 때 약간이라도 영향을 미치고 싶은 상황이 있다. GPU 가속을 제공하는 노드가 필요하거나 SSD가 있는 노드에 스케줄링하는 경우 등을 들수 있다.
• 어떤 파드가 어떤 노드에 스케줄링돼야 하는지 구체적으로 지정한다면 애플리케이션이 인프라스트럭처에 결합되어버릴 것이다.
• 따라서 정확한 노드를 지정하는 대신 필요한 노드 요구사항을 기술하고 쿠버네티스가 요구사항을 만족하는 노드를 선택하도록 한다.

---

3.5.1 워커 노드 분류에 레이블 사용

• 레이블은 노드를 포함한 모든 쿠버네티스 오브젝트에 부착할 수 있다.
• 클러스터에 범용 GPU 컴퓨팅에 사용할 수 있는 GPU를 가지고 있는 노드가 있다면, 이 기능을 가지고 있음을 보여주는 레이블을 노드에 추가할 수 있다.

$kubectl label node gke-kubia-pool-1-01349329-5bk0 gpu=true

• 이제 파드를 나열할 때 처럼 노드를 나열할 때 레이블 셀렉터를 사용할 수 있다.

$kubectl get nodes -l gpu=true

---

3.5.2 특정 노드에 파드 스케줄링

• 스케줄러가 GPU를 제공하는 노드를 선택하도록 요청하려면, 파드의 YAML 파일에 노드 셀렉터를 추가해야 한다.

apiVersion: v1
kind: Pod
metadata:
  name: kubia-gpu
spec:
  nodeSelector:
    gpu: "true"
  containers:
  - image: luksa/kubia
    name: kubia

$kubectl create -f kubia-gpu.yaml

• spec 섹션 안에 nodeSelector 필드를 추가했다. 파드를 생성할 때, 스케줄러는 gpu =true 레이블을 가진 노드 중에 선택한다.

---

3.5.3 하나의 특정 노드로 스케줄링

• 각 노드에는 키가 kubernetes.io/hostname이고 값이 호스트 이름으로 설정된 고유한 레이블이 있기 때문에, 파드를 특정 노드로 스케줄링하는 것도 가능하다.
• 그러나 실제 호스트 이름으로 지정할 경우 해당 노드가 오프라인 상태라면 파드가 스케줄링되지 않을 수 있다.
• 개별 노드가 아닌 레이블 셀렉터를 통해 지정한 특정 기준을 만족하는 노드의 논리적인 그룹으로 생각해야 한다.

---

3.6 파드에 어노테이션 달기

• 어노테이션은 키-값 쌍으로 레이블과 거의 비슷하지만 식별 정보를 갖지 않는다.
• 어노테이션은 레이블셀렉터 같은 것은 없지만 훨씬 더 많은 정보를 보유할 수 있다.
• 새로운 기능의 알파 혹은 베터전의 API 오브젝트에 새로운 필드를 바로 도입하지 않고 어노테이션을 사용한다. 그러다 필요한 API 변경이 명확해지면 어노테이션을 중단하고 필드로 도입한다.
• 파드나 다른 API 오브젝트에 설명을 추가하거나 오브젝트를 만든 사람 이름을 어노테이션으로 지정해두는 식으로 유용하게 사용할 수 있다.

---

3.6.1 오브젝트의 어노테이션 조회

• 다음 명령어로 어노테이션을 볼 수 있다.

$kubectl describe pod kubia-4rzxp

• 현재는 어노테이션이 없어서 none으로 출력된다.

---

3.6.2 어노테이션 추가 및 수정

• 키 충돌을 방지하기 위해 어노테이션 키를 다음과 같이 사용하는 것이 좋다. 고유한 접두사가 없다면 기존에 있던 어노테이션을 덮어버릴 수가 있다.

$kubectl annotate pod kubia-manual mycompany.com/someanotation="foo bar"

---

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

• 각 오브젝트는 여러 레이블을 가질 수 있기 때문에, 오브젝트 그룹은 서로 겹쳐질 수 있다.
• 하나의 그룹에서만 작업하기위해 오브젝트를 겹치지 않는 그룹으로 분할하고자 한다면 네임스페이스로 그룹화해야한다.
• 여기서 네임스페이스는 프로세스를 격리할 때 사용했던 리눅스 네임스페이스가 아니다. 쿠버네티스 네임스페이스는 오브젝트 이름의 범위를 제공한다.

---

3.7.1 네임스페이스의 필요성

• 네임스페이스를 사용하면 많은 구성 요소를 가진 복잡한 시스템을 좀 더 작은 개별 그룹으로 분리할 수 있다.
• 또한 멀티테넌트(multi-tenant) 환경처럼 리소스를 분리하는 데 사용된다. 리소스는 네임스페이스 안에서만 고유하면 된다.
• 대부분의 리소스 유형은 네임스페이스 안에 속하지만, 전역으로 사용되는 노드 리소스와 같은 경우도 존재한다.

---

3.7.2 다른 네임스페이스와 파드 살펴보기

• 클러스터에 있는 모든 네임 스페이스를 나열해보자.

$kubectl get ns

• 지금까지는 네임스페이스를 명시적으로 지정한 적이 없기 때문에 default 네임스페이스에서만 작업을 진행했다.
• kube-system 네임스페이스에 속해있는 파드를 나열해보자.

$kubectl get po --namespace kube-system

• 쿠버네티스 시스템에 관련된 리소스들이 default 네임 스페이스 안에 있고 사용자가 직접 생성한 리소스와 섞여있다면, 리소스를 구분하기 어렵고 실수로 삭제할 수도 있다.
• 네임스페이스를 사용해 서로 관계없는 리소스를 겹치지 않는 그룹으로 분리할 수 있다. 여러 사용자 또는 그룹이 동일한 쿠버네티스 그룹을 사용한다면, 각자 고유한 네임스페이스를 사용해 리소스를 관리해서 충돌을 방지할 수 있다.

---

3.7.3 네임스페이스 생성

YAML 파일에서 네임스페이스 생성

apiVersion: v1
kind: Namespace
metadata:
  name: custom-namespace

$kubectl create -f custom-namespace.yaml

kubectl create namespace 명령으로 네임스페이스 생성

• 명령어를 사용해 yaml 파일 없이 네임스페이스를 생성할 수 있다.

$kubectl create namespace custom-namespace2

---

3.7.4 다른 네임스페이스의 오브젝트 관리

• 네임스페이스 안에 리소스를 만들기 위해서는 metata 섹션에 namespace:custom-namespace 항목을 넣거나
  kubectl create 명령을 사용할 때 네임스페이스를 지정한다.

$kubectl create -f kubia-manual.yaml -n custom-namespace

• 이제 동일한 이름을 가진 두 파드가 있다. 하나는 default 네임스페이스에 있고 하나는 custom-namespace에 있다.
• 다른 네임스페이스 안에 있는 오브젝트를 나열하거나 어노테이션 달기, 수정 또는 삭제할 때는 --namespace(또는 n) 플래그를 전달해야 한다.
• 네임스페이스를 지정하지 않으면 kubectl은 현재 kubectl 컨텍스트에 구성되어 있는 기본 네임스페이스에서 작업을 수행한다.
• 현재 컨텍스트의 네임스페이스와 컨텍스트 자체는 kubectl config 명령으로 변경할 수 있다.

---

3.7.5 네임스페이스가 제공하는 격리 이해

• 네임스페이스를 사용하면 오브젝트를 별도 그룹으로 분리해 네임스페이스 안에 속한 리소스를 대상으로 작업할 수 있게 해주지만, 실행중인 오브젝트에 대한 격리는 제공하지 않는다
• 예를들어 서로 다른 네임스페이스를 파드에 배포할 때 네트워크 격리는 네트워킹 솔루션에 따라 다르다. 네트워크 솔루션이 네임스페이스 간 격리를 제공하지 않는 경우 통신에 아무런 제약 사항이 없다.

---

3.8 파드 중지와 제거

3.8.1 이름으로 파드 삭제

$kubectl delete po kubia-gpu

• 파드를 삭제하면 쿠버네티스는 파드 안에 있는 모든 컨테이너를 종료하도록 지시한다.
• 쿠버네티스는 SIGTERM 신호를 프로세스에 보내고 지정된 시간(기본값 30초)동안 기다린다. 시간 내에 종료되지 않으면 SIGKILL 신호를 통해 종료한다.

---

3.8.2 레이블 셀렉터를 이용한 파드 삭제

• 레이블 셀렉터를 사용해 레이블을 가지고 있는 모든 파드를 삭제할 수 있다.

$ kubectl delete po -l creation_method=manual

---

3.8.3 네임스페이스를 삭제한 파드 제거

• 네임스페이스 전체를 삭제할 수 있다. 파드는 네임스페이스와 함께 자동으로 삭제된다.

$kubectl delete ns custom-namespace

• 하지만 파드를 다시 조회해보면 새로운 파드가 생성되어 있다.

• 2장에서 만들었던 레플리케이션컨트롤러에 의해 파드가 삭제되면 즉시 새로운 파드가 생성된다.
• 파드를 삭제하기 위해서는 레플리케이션컨트롤러도 삭제해야 한다.

---

3.8.4 네임스페이스를 유지하면서 네임스페이스 안에 있는 모든 파드 삭제

• 특정 파드를 삭제하는 대신 --all 옵션을 이용해 현재 네임스페이스에 있는 모든 파드를 삭제해보자.

$kubectl delete po --all

---

3.8.5 네임스페이스에서 (거의) 모든 리소스 삭제

• 하나의 명령으로 현재 네임스페이스에 있는 모든 리소스(레플리케이션 컨트롤러, 파드, 생성한 모든 서비스)를 삭제할 수 있다.

$kubectl delete all --all