챕터3. 파드:쿠버네티스에서 컨테이너 실행

챕터 3. 파드:쿠버네티스에서 컨테이너 실행

3장에서 다루는 내용

• 파드의 생성,실행,정지
• 파드와 다른 리소스를 레이블로 조직화하기
• 특정 레이블을 가진 모든 파드에서 작업 수행
• 네임스페이스를 사용해 파드를 겹치지 않는 그룹으로 나누기
• 특정한 형식을 가진 워커 노드에 파드 배치

3.1 파드소개

파드 → 함께 배치된 컨테이너 그룹이며 쿠버네티스의 기본 빌딩 블록

컨테이너를 가진 파드를 배포 운영한다.

파드가 여러 컨테이너를 가지고 있을 경우, 모든 컨테이너는 항상 하나의 워커노드에서 실행되며 여러 워커 노드에 걸쳐 실행되지 않는다.

 

3.1.1 파드가 필요한 이유

여러 프로세스를 싱행하는 단일 컨테이너보다 다중 컨테이너가 나은 이유

• 컨테이너는 단일 프로세스를 실행하는 것을 목적으로 설계됨
• 모든 프로세스는 동일한 표준 출력으로 로그를 기록하기 때문에 어떤 프로세스가 남긴 로그인지 파악하기 어렵다.

3.1.2 파드 이해하기

파드가 필요한 이유 →

여러 프로세스를 단일 컨테이너로 묶지 않기 때문에, 컨테이너들을 함께 묶고 하나의 단위로 관리할 수 있는 상위구조가 필요 → 이게 파드

 

컨테이너 모음을 사용해 밀접하게 연관된 프로세스를 묶어 단일 컨테이너에서 실행하는 거 처럼 보이지만 또 컨테이너를 사용해 격리된 상태를 유지

 

같은 파드에서 컨테이너 간 부분 격리

쿠버네티스는 파드 안에 있는 모든 컨테이너가 자체 네임스페이스가 아닌 동일한 리눅스 네임스페이스를 공유하도로고 도커를 설정한다.

파드 안의 모든 컨테이너는 같은 호스트 이름과 네트워크 인터페이스를 공유한다.

그러나 기본적으로 파일시스템은 다른 컨테이너와 완전히 분리된다.

 

컨테이너가 동일한 IP와 포트 공간을 공유하는 방법

• 파드 안의 컨테이너가 동일한 네트워크 네임스페이스에서 실행되기 때문에 동일한 IP주소와 포트 공간을 공유한다.
• 동일한 파드 안 컨테이너에서 실행 중인 프로세스가 같은 포트 번호를 사용하지 않도록 주의 → 동일한 파드일 때만 해당

파드 간 플랫 네트워크 소개

• 파드 사이에서 통신은 항상 단순하다. 두 파드가 동일 혹은 서로 다른 워커 노드에 있는지 중요하지 않으며, 두 경우 모두 파드 안에 있는 컨테이너는 NAT 없는 플랫 네트워크를 통해 서로 통신하는 것이 가능하다.

파드는 논리적인 호스트로서 컨테이너가 아닌 환경에서

동일한 파드에서 실행한 프로세스는 각 프로세스가 컨테이너 안에 캡슐화돼 있다는 점을 제외하면,

같은 물리적 혹은 VM에서 동작하는 것과 동일하다.

 

3.1.3 파드에서 컨테이너의 적절한 구성

파드는 상대적으로 가볍기 때문에 오버헤드 없이 필요한 만큼 파드를 가질 수 있다.

 

다계층 애플리케이션을 여러 파드로 분할

컴퓨팅 리소스를 활용하지 않고 버릴수도 있다.

 

개별 확장이 가능하도록 여러 파드로 분할

두 컨테이너를 하나의 파드에 넣지 말아야 하는 또 다른 이유 → 스케일링

파드는 스케일리의 기본 단위이다.

 

파드에서 여러 컨테이너를 사용하는 경우

주요 프로세스와 하나 이상의 보완 프로세스로 구성된 경우.

사이드카 컨테이너의 다른 예제로는 로그 로테이터와 수집기, 데이터 프로세서, 통신 어댑터 등

 

파드에서 여러 컨테이너를 사용하는 경우 결정

• 컨테이너를 함께 실행해야 하는거, 혹은 서로 다른 호스트에서 실행할 수 있는가?
• 여러 컨테이너가 모여 하나의 구성요소를 나타내는가? 혹는 개별적인 구성 요소인가?
• 컨테이너가 함께 혹은 개별적으로 스케일링 돼야 하는가?

 

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

파드를 포함한 다른 쿠버네티스 리소스는 일반적으로 쿠버네티스 REST API 엔드포인트에

JSON 혹은 YAML 매니페스트를 전송해 생성한다.

 

YAML 파일에 모든 쿠버네티스 오브젝트를 정의하면 버전 관리 시스템에 넣는 것이 가능해져 모든 이점을 누릴 수 있다.

 

3.2.1 기존 파드의 YAML 디스크립터 살펴보기

kubectl get 명령과 함께 -o yaml 옵션을 통해 파드의 전체 YAML 정의를 볼 수 있다.

 

파다를 정의하는 주요 부분 소개

거의 모든 쿠버네티스 리소스가 갖고 있는 세 가지 중요한 부분

• Metadata: 이름, 네임스페이스, 레이블 및 파드에 관한 기타 정보 포함
• Spec: 파드 컨테이너, 볼륨, 기타 데이터 등 파드 자체에 관한 실제 명세
• Status: 파드 상태, 각 컨테이너 설명과 상태, 파드 내부 IP, 기타 기본정보 등 현재 실행 중인 파드에 관한 현재 정보

status 부분에는 특정 시간의 리소스 상태를 보여주는 읽기 전용의 런타임 데이터가 포함돼 있다.

→ 새 파드를 만들 때 status 부분은 작성할 필요가 없다.

 

3.2.2 파드를 정의하는 간단한 YAML 정의 작성하기

컨테이너 포트 지정

포트 지정을 생략해도 다른 클라이언트에서 포트를 통해 파드에 연결할 수 있는 여부에 영향을 미치지 않는다.

그러나 포트를 명시적으로 정의한다면 → 클러스터를 사용하는 모든 사람이 파드에서 노출한 포트를 빠르게 볼 수 있다.

또한 명시적으로 정의하면 이름을 지정해 편리하게 사용할 수 있다.

 

3.2.3 kubectl create 명령으로 파드 만들기

$ kubectl create -f kubia-manual.yaml
pod "kubia-manual" created

실행 중인 파드의 전체 정의 가져오기
$ kubectl get po kubia-manual -o yaml
// yaml 형식
$ kubectl get po kubia-manual -o json
// json 형식

$ kubectl get pods
// 파드들 상태 조회

 

3.2.4 애플리케이션 로그 보기

컨테이너화된 애플리케이션은 로그를 파일에 쓰기보다는 표준 출력과 표준 에러에 로그를 남기는 게 일반적 → 이로 사용자는 간단하고 동일한 방식으로 볼 수 있다.

$ docker logs <container id>
// 도커 로그 명령으로 로그를 확인

$ kubectl logs kubia-manual
// kubectl logs를 이용해 파드 로그 가져오기

$ kubectl logs kubia-manual -c kubia
// -c 옵션을 통해 파드 속에 특정 컨테이너 로그 확인(파드 속에 컨테이너가 여러개라면)

 

3.2.5 파드에 요청 보내기

로컬 네트워크 포트를 파드의 포트로 포워딩

$ kubectl port-forward kubia-manual 8888:8080
// 포트 포워딩은 kubectal port-forward 명령으로 할 수 있다.
// 머신의 로컬 포트 8888을 kubia-manual 파드의 8080포트로 포워딩

 

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

파드가 많아지면 어떤 파드가 어떤 것인지 쉽게 알 수 있도록 임의의 기준에 따라 작은 그룹으로 조직하는 방법이 필요하다.

레이블을 통해 파드와 기타 다른 쿠버네티스 오브젝트의 조직화가 이뤄진다.

 

3.3.1 레이블 소개

레이블 - 파드와 모든 다른 쿠버네티스 리소스를 조직화할 수 있는 쿠버네티스 기능.

레이블은 리소스에 첨부하는 키-값 쌍

레이블 키가 해당 리소스를 생성할 때 레이블을 붙이지만, 나중에 레이블을 추가 수정할 수 있다.

 

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

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

$ kubectl get po -L creation_method,env
// -L 스위치로 지정해 해당 레이블을 자체 열에 표시할 수 있다.

3.3.3 기존 파드 레이블 수정

$ kubectl label po kubia-manual-v2 env=debug --overwrite
// 기존 레이블을 변경할 때는 --overwrite 옵션이 필요하다
// kubia-manual-v2 파드의 env=prod 레이블을 env=debug로 변경

 

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

레이블이 레이블 셀렉터와 함께 사용된다!

→ 레이블 셀렉터는 특정 레이블로 태그된 파드의 부분 집합을 선택해 원하는 작업을 수행한다.

특정 값과 레이블을 갖는지 여부에 따라 리소스를 필터링하는 기준이 된다.

 

레이블 셀렉터는 리소스 중 다음 기준에 따라 리소스를 선택한다

• 특정한 키를 포함하거나 포함하지 않는 레이블
• 특정한 키와 값을 가진 레이블
• 특정한 키를 갖고 있지만, 다른 갑을 가진 레이블

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

$ kubectl get po -l creation_method=manual
// 수동으로 생성한 모든 파드를 보기

$ kubectl get po -l env
// env레이블을 가지고 있지만 값은 무엇이든 상관없는 파드 조회

$ kubectl get po -l '!env'
// env 레이블을 가지고 있지 않는 파드

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

레이블 셀렉터는 파드 목록을 나열하는 것 뿐만 아니라, 파드 부분 집합에 작업을 수행할 때도 유용하다.

셀렉터는 쉼표로 구분된 여러 기준을 포함하는 것도 가능하다.

 

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

어떤 파드가 어느 노드에 스케줄링 됐느냐는 중요하지 않다.

그렇기 때문에 쿠버에게 파드를 어디에 스케줄링 할지 알려줄 필요는 없다.

하지만 예로 GPU 가속을 제공하는 노드에만 GPU 계산이 필요한 파드를 스케줄하는 것 처럼.

쿠버네티스의 전체적인 아이디어 → 위에 실행되는 애플리케이션으로부터 실제 인프라스트럭처를 숨기는 것

→ 파드가 어느 노드에 스케줄링돼야 하는지 구체적으로 지정하고 싶지 않을 것

 

그러나 정확한 노드를 지정하는 대신 필요한 노드 요구 사항을 기술하고 쿠버네티스가 요구사항을 만족하는 노드를 선택하도록한다.

→ 이는 노드 레이블과 레이블 셀렉터를 통해 할 수 있다.

 

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

레이블 → 노드를 포함한 모든 쿠버네티스 오브젝트에 레이블을 부착할 수 있다.

$ kubectl label node gke-kubia-85f6-node-0rrx gpu=true
// gke-kubia-85f6-node-0rrx 노드에 gpu=true라는 레이블을 붙임

$ kubectl get nodes -l gpu=true
// gpu=true 레이블을 가진 노드를 나열

 

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

이제 GPU를 필요로 하는 새로운 파드를 배포해야 한다고 가정하면

파드의 YAML파일에 노드 셀렉터를 추가해 작성한다.

spec 섹션 안에

nodeSelector 필드를 추가하고 gpu: “true”를 통해 조건을 부여한다.

 

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

파드는 특정한 노드로 스케줄링하는 것도 가능하다

→ 그러나 그 특정 노드가 오프라인 상태인 경우 스케줄링 되지 않을 수 있다.

→ 개별 노드로 생각해서는 안된다.

→ 레이블 셀렉터를 통해 지정한 특정 기준을 만족하는 노드의 논리적인 그룹을 생각해야한다.

 

3.6 파드에 어노테이션 달기

파드 및 다른 오브젝트는 레이블 이외 어노테이션을 가질 수 있다.

어노테이션은 키-값 쌍으로 레이블과 비슷하지만 식별정보를 가지지 않는다.

레이블 셀렉터를 통해 오브젝트를 선택할 수 있지만 어노테이션 셀렉터와 같은 것은 없다.

어노테이션을 더 많은 정보를 담을 수 있다.

 

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

kubectl describe 명령을 이요하거나 YAML 전체 내용을 통해 어노테이션을 볼 수 있다.

레이블에는 짧은 데이터를, 그에 비해 어노테이션에는 상대적으로 큰 데이터를 넣을 수 있다.

 

3.6.2 어노테이션 추가 및 수정

$ kubectl annotate pod kubia-manual mycompany.com/someannotation="foo bar"
// kubectl annotate 명령을 통해 어노테이션을 추가
// 어노테이션 충돌 방지를 위해 어노테이션 키로 형식을 사용하는 것이 좋다

 

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

레이블을 사용하면 오브젝트 그룹이 서로 겹칠 수 있다.

→ 이런 문제점을 해결하기 위해 쿠버네티스는 오브젝트 네임스페이스로 그룹화한다

→ 프로세스를 격리하는데 사용하는 리눅스 네임스페이스와 다른것!

 

3.7.1 네임스페이스의 필요성

여러 네임스페이스를 사용하면 많은 구성 요소를 가진 복잡한 시스템을 좀 더 작은 개별 그룹으로 분리할 수 있다.

ex) 리소스를 프로덕션, 개발, QA 환경 혹은 원하는 다른 방법으로 나누어 사용할 수 있다.

 

• 서로 다른 두 네임스페이스는 동일한 이름의 리소스를 가질 수 있다.
• 대부분의 리소스 유형은 네임스페이스 안에 속하지만 일부는 그렇지 않다.

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

$ kubectl get ns
// 모든 네임스페이스 확인

$ kubectl get po --namespace kube-system
// kube-system 네임스페이스에 속해 있는 파드를 확인
// --namespace 대신 -n 옵션 사용 가능

네임스페이스를 사용해 서로 관계없는 리소스를 겹치지 않는 그룹으로 분리할 수 있다.

네임스페이스는 리소스를 격리하는 것 외에도 특정 사용자가 지정된 리소스에 접근할 수 있도록 허용,

개별 사용자가 사용할 수 잇는 컴퓨팅 리소스를 제한하는 데에도 사용된다.

 

3.7.3 네임스페이스 생성

$ kubectl create namespace custom-namespace
// kubectl create namespace 명령으로 네임스페이스 생성

 

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

생성한 네임스페이스 안에 리소스를 만들기 위해서는 metadata 섹션에 namespace: custom-namespace 항목을 넣거나

kubectl create 명령을 사용할 때 지정한다.

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

동일한 이름을 가진 두 파드가 서로 다른 네임스페이스에 있다.

이런 경우 —namespace 플래그를 kubectl에 전달해야 한다.

지정하지 않으면 현재 kubectl 컨텍스트에 구성돼 잇는 기본 네임스페이스에서 작업을 수행한다.

 

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

• 네임스페이스를 사용하면 오브젝트를 별도 그룹으로 분리해 특정 리소스를 대상으로 작업할 수 있게 해준다.
• 하지만 실행중인 오브젝트에 대한 격리는 제공하지 않는다.

3.8 파드 중지와 제거

 

3.8.1 이름으로 파드 삭제

$ kubectl delete po kubia-gpu
// 파드를 이름으로 삭제

파드를 삭제하면 쿠버네티스는 SIGTERM 신호를 프로세스에게 보내 지정된 시간동안 기다린다.

시간 내에 종료되지 않으면 SIGKILL 신호를 통해 종료한다.

 

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

$ kubectl delete po -l creation_method=manual
// 레이블 셀렉터를 통해 파드 삭제

 

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

$ kubectl delete ns custom-namespace
// 네임스페이스를 삭제 -> 파드는 네임스페이스와 함께 자동으로 삭제된다.

 

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

$ kubectl get pods
$ kubectl delete po --all
// --all 옵션을 이용해 쿠버네티스가 현재 네임스페이스에 있는 모든 파드를 삭제

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

첫번째 all 명령은 모든 유형의 리소스를 삭제하도록 지정하고

—all 옵션으로 리소스 이름이 아닌 모든 리소스 인스턴스를 삭제할 것을 지정한다.

 

3.9 요약

• 특정 컨테이너를 파드로 묶어야 하는지.
• 파드는 여러 프로세스를 실행할 수 있으며 컨테이너가 아닌 세계의 물리적 호스트와 비슷하다.
• YAML 또는 JSON 파일을 통해 파드를 작성하고 정의와 상태를 확인 할 수 있다.
• 레이블과 레이블 셀렉터를 사용해 파드를 조직하고 한번에 여러 파드에서 작업을 쉽게 할 수 있다.
• 노드 레이블과 셀렉터를 사용해 특정 기능을 가진 노드에 파드를 스케줄링 할 수 있다.
• 어노테이션을 사용해 더 큰 데이터 정보를 파드에 부착할 수 있다.
• 네임스페이스는 다른 팀들이 동일한 클러스터를 별도 클러스터를 사용하는 것 처럼 이용할 수 있게 해준다.