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

3장에서 다루는 내용

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

---

3.1 파드 소개

• 파드는 함께 배치된 컨테이너 그룹이며 쿠버네티스의 기본 빌딩 블록이다.
• 컨테이너를 개별적으로 배포하기보다는 컨테이너를 포함하는 파드를 배포하고 운영한다.
• 파드가 여러 컨테이너를 가지고 있을 경우, 컨테이너는 항상 하나의 워커 노드에서 실행되며 여러 워커 노드에 걸쳐 실행되지 않는다.

---

3.1.1 파드가 필요한 이유

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

• 컨테이너는 단일 프로세스를 실행하는 것을 목적으로 설계했다.
• 단일 컨테이너에서 관련 없는 다른 프로세스에 대한 실행 및 관리는 모두 사용자 책임이다. (프로세스 실패 후 재시작 등)
• 따라서 각 프로세스를 자체 개별 컨테이너로 실행해야 한다.

---

3.1.2 파드 이해하기

• 여러 프로세스를 단일 컨테이너로 묶지 않기 때문에, 컨테이너를 묶고 하나의 단위로 관리 할 수 있는 상위 구조인 파드가 필요하다.
• 컨테이너 모음을 사용해 연관된 프로세스를 함께 실행하고 단일 컨테이너 안에서 함께 실행되는 것처럼 동일한 환경을 제공하면서도 서로 격리된 상태로 유지할 수 있다.

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

• 파드 안에 있는 모든 컨테이너는 동일한 네트워크 네임스페이스와 UTS 네임스페이스를 공유하기 때문에, 같은 호스트 이름과 네트워크 인터페이스를 공유한다.
• 또한 모든 컨테이너는 동일한 IPC 네임스페이스에서 실행되어 IPC를 통해 서로 통신할 수 있다.
• 그러나 대부분의 컨테이너 파일 시스템은 컨테이너 이미지에서 나오기 때문에, 파일시스템은 다른 컨테이너와 분리된다.

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

• 컨테이너가 동일한 IP 주소와 포트 공간을 공유하므로, 실행 중인 프로세스 간에 같은 포트번호를 사용하지 않도록 주의해야 한다.
• 이는 동일한 파드일 때만 해당하며, 다른 파드에 있는 컨테이너는 포트 충돌이 일어나지 앉는다.
• 파드 안에 있는 모든 컨테이너는 동일한 루프백 네트워크 인터페이스를 갖기 떄문에, 로컬 호스트를 통해 통신할 수 있다.

파드 간 플랫 네트워크 소개

• 모든 파드는 하나의 플랫(flat)한 공유 네트워크 주소 공간에 상주하므로 모든 파드는 다른 파드의 IP 주소를 사용해 접근할 수 있다.
• 둘 사이에는 어떠한 NAT(Network Address Translation)도 존재하지 않는다.
• 두 파드가 서로 다른 워커 노드에 있는지는 중요하지 않으며, 실제 노드 간 네트워크 토폴로지에 관계없이 LAN 상에 있는 컴퓨터 간 통신과 비슷하다.

---

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

• 파드를 각각 별도의 머신으로 생각할 수 있지만, 파드는 특정한 애플리케이션만을 호스팅한다.
• 모든 것을 파드 하나에 넣는 대신 애플리케이션을 여러 파드로 구성하고, 각 파드에는 밀접하게 관련 있는 구성 요소나 프로세스만 포함해야 한다.

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

• 프론트엔드 서버와 데이터베이스 컨테이너 두 개로 구성된 단일 파드를 실행하는 것은 적절하지 않다.
• 프론트엔드와 벡엔드가 같은 파드에 있다면, 둘은 항상 같은 노드에서 실행된다.
• 그러면 활용할 수 있는 워커 노드가 여러 개있더라도 하나의 워커 노드만 사용하므로 컴퓨팅 리소스의 활용도가 떨어진다.

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

• 쿠버네티스는 개별 컨테이너를 수평 확장할 수 없으며, 대신 전체 파드를 수평 확장한다.
• 프론트엔드와 벡엔드 컨테이너로 구성된 파드를 늘리면, 프론트엔드와 벡엔드가 같이 늘어난다.
• 하지만 일반적으로 프론트엔드와 벡엔드는 다른 스케일링 요구 사항을 갖고 개별적으로 확장하는 경향이 있다.

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

• 여러 컨테이너를 단일 파드에 넣는 주된 이유는 위와 같이 하나의 주요 프로세스와 하나 이상의 보완 프로세스로 구성된 경우다.

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

• 컨테이너를 파드로 묶어 그룹을 만들 때는 다음 사항을 고려해야 한다.
  • 컨테이너를 함께 실행해야 하는가, 혹은 서로 다른 호스트에서 실행할 수 있는가?
  • 여러 컨테이너가 모여 하나의 구성 요소를 나타내는가, 혹은 개별적인 구성요소인가?
  • 컨테이너가 함께, 혹은 개별적으로 스케일링돼야 하는가?
• 특정 이유 때문에 컨테이너를 단일 파드로 구성하는 것을 요구하지 않는다면, 분리된 파드에서 컨테이너를 실행하는 것이 좋다.

---

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

• 파드를 포함한 쿠버네티스 리소느는 일반적으로 쿠버네티스 REST API 엔드포인트에 JSON 혹은 YAML 매니페스트를 전송해 생성한다.

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

다음 명령어를 사용해 생성한 파드의 전체 YAML 정의를 볼 수 있다.

$kubectl get po kubia-fkgrt -o yaml

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

• 먼저 YAML에서 사용하는 쿠버네티스 API 버전과 YAML이 설명하는 리소스 유형이 있다.
• 이어서 거의 모든 쿠버네티스 리소스가 가지고 있는 중요한 부분이 있다.
  • Metadata: 이름, 네임스페이스, 레이블 및 파드에 관한 기타 정보를 포함
  • Spec: 파드 컨테이너, 볼륨, 기타 데이터 등 파드 자체에 관한 실제 명세
  • Status: 파드 상태, 각 컨테이너 설명과 상태, 파드 내부 IP, 기타 기본 정보 등 현재 실행 중인 파드에 관한 현재 정보

---

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

컨테이너 포트 지정

• 포트를 지정하지 않아도 다른 클라이언트에서 파드 연결에는 문제가 없다.
• 하지만 포트를 명시적으로 정의하면 클러스터를 사용하는 모든 사람이 파드에서 노출한 포트를 빠르게 볼 수 있다.

---

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

• YAML 또는 JSON 파일을 이용해 를 리소스만들려면, 다음 명령어를 사용한다.

$kubectl create -f kubia-manual.yaml

파드 목록에서 새로 생성된 파드 보기

• 파드를 조회해보면 kubia-manual 파드가 실행중인 것을 볼 수 있다.

---

3.2.4 애플리케이션 로그 보기

• 다음 명령어를 통해 컨테이너 로그를 가져올 수 있다.

$docker logs <container id>

kubectl logs를 이용해 파드 로그 가져오기

• 파드 로그(정확히는 컨테이너 로그)를 보기 위해서는 로컬머신에서 다음 명령을 실행한다.

$kubectl logs kubia-manual

컨테이너 이름을 지정해 다중 컨테이너 파드에서 로그 가져오기

• 여러 컨테이너를 포함한 파드인 경우에는, 컨테이너 이름을 명시적으로 포함해야 한다.

$kubectl logs kubia-manual -c kubia

• 현재 존재하는 파드의 로그만 가져올 수 있으며, 파드가 삭제되면 로그도 함께 삭제된다.
• 파드가 삭제된 후에도 로그을 보기 위해서는 모든 로그를 중앙 저장소에 저장하는 중앙집중식 로깅을 설정해야 한다.

---

3.2.5 파드에 요청 보내기

• 서비스를 통해 외부에서 파드로 접근할 수도 있지만 테스트와 디버깅 목적으로 파드에 연결할 수 있는 방법이 있다.

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

• 서비스를 거치지 않고 특정 파드와 대화하고 싶을 때 쿠버네티스는 해당 파드로 향하는 포트 포워딩을 구성해준다.
• 다음 명령은 머신의 로컬 포트 8888을 kubia-manual 파드의 8080 포트로 향하게 한다.

$kubectl port-forward kubia-manual 8888:8080

포트 포워딩을 통해 파드 연결

• 이제 다른 터미널에서 curl을 이용해 localhost:8888에서 실행되고 있는 kubectl port-forward 프록시를 통해 http 요청을 해당 파드에 보낼 수 있다.