Kubernetes 3. Pod

지난 포스트에 이어서 이번에는 Pod의 내용을 다루도록 하겠습니다.

# Pod란?

애플리케이션의 논리 호스트라 볼 수 있습니다. VM과 유사하게 동작하지만 각 프로세스가 컨테이너에 캡슐화된다는 점에서 차이가 있겠습니다.

포드는 여러개의 컨테이너를 포함할 수 있지만, 그 컨테이너들은 모두 동일한 워커 노드에서 실행된다는 점을 알아두시면 좋을 것 같습니다.

출처: https://act-coe.github.io/kubernetes-in-action-03/

## 포드의 필요성

모놀리식 서비스와 마이크로 서비스의 비교를 다시 떠올려보면 좋습니다. 하나의 시스템에 모든 프로세스를 넣어서 동작시키면 유지, 관리, 보수가 어려워집니다. 그러므로 각각의 프로세스를 자체 컨테이너에서 실행하는 게 옳겠죠. 그러려고 컨테이너가 만들어지기도 했고요.

여러 개의 프로세스를 위해 다수의 컨테이너를 생성해야 하다 보니, 이 컨테이너들을 관리할 수 있는 상위 레벨 구조가 필요하게 됩니다. 포드 컨테이너는 하위 컨테이너들을 관리하며 마치 하나의 시스템에서 동작하는듯한 효과를 누릴 수 있게 해 줍니다.

## 격리

이전 포스트에서 컨테이너들은 각각 고유의 리눅스 네임스페이스를 이용하여 완전 격리된다고 하였지만 포드 컨테이너의 경우는 조금 다르게 진행됩니다. 쿠버네티스는 도커를 구성하여 각 포드 컨테이너가 자체 세트를 가지게 하는 대신 모든 포드 컨테이너가 동일한 리눅스 네임스페이스 세트를 공유하도록 함으로써 포드들을 격리시킵니다.

특정 포드 내의 컨테이너들은 동일한 네트워크, UTS 네임스페이스(리눅스 네임스페이스)에서 실행되기 때문에 모두 같은 호스트 이름, 네트워크 인터페이스를 공유하게 됩니다. 그렇기 때문에 포드 내 모든 컨테이너들은 동일한 IPC 네임스페이스에서 동작하게 되고 이를 통해 서로 통신할 수 있습니다.

최신 버전의 쿠버네티스 & 도커 버전에서는 동일한 PID 네임스페이스 공유가 가능하지만 이 기능은 비활성화가 기본 값으로 설정되어 있다고 하네요. 참고로 포드 내 컨테이너들은 서로 다른 PID 네임스페이스를 사용해야만 각 컨테이너에서 자신의 프로세스를 확인할 수 있습니다.

파일 시스템의 경우는 상황이 조금 다릅니다. 파일 시스템은 이전 포스트에서 설명했듯이 컨테이너 이미지에서 나오기 때문에 기본적으로 분리되어 있습니다. 하지만 볼륨이라는 쿠버네티스 개념을 사용하면 파일 디렉토리 공유가 가능하다고 합니다. 이 내용은 다음에 다시 설명하도록 하겠습니다.

## 네트워크

동일한 포드 내 컨테이너들은 동일한 네트워크에서 실행되므로 동일한 포트 번호에 바인딩되지 않도록 주의가 필요합니다. 포드 내부의 모든 컨테이너들은 localhost:{port}를 통하여 같은 포드 내 다른 컨테이너와 통신이 가능합니다.

기본적으로 쿠버네티스 클러스터의 모든 포드는 하나의 플랫과 공유 공간, 네트워크 주소 공간에 위치하게 됩니다. 즉, 모든 포드는 다른 포드에 접근할 수 있습니다. 또한 포드 사이의 NAT 게이트웨이가 없기 때문에 포드끼리 서로 네트워크 패킷을 주고 받게 되면, 상대의 실제 주소가 패킷의 소스 IP로 보여지게 됩니다.

출처: https://act-coe.github.io/kubernetes-in-action-03/

즉 포드 간의 통신은 네트워크 토폴로지에 관계없이 LAN과 같은 NAT-less 네트워크를 통해 이루어지게 됩니다.

## 컨테이너와 포드 구성

포드가 VM과 비슷한 역할을 한다고 하였습니다. 하지만 포드는 VM에 비하면 매우 가볍습니다. 그렇기 때문에 여러 컨테이너를 하나의 포드에 배포하기보다는 포드에 밀접하게 연관되어 있는 컨테이너만을 포드에 구성하는 것이 앞으로 관리에 있어서 유리하다고 생각됩니다.

쿠버네티스가 마이크로 서비스와 밀접하게 관련 있다는 점을 다시 상기하시면 컨테이너-포드 구성에 크게 도움을 얻으실 수 있을 거라 생각됩니다.

개인적으로 반드시 동일한 포드에서 다른 컨테이너를 구성해야 할 이유가 없다면, 별도의 포드로 구성하는게 옳다고 생각됩니다.

출처: https://act-coe.github.io/kubernetes-in-action-03/

# Manifest 생성

이전 포스트에서 REST API를 통하여 간단한 쿠버네티스 설정과 함께 배포 테스트를 진행했었습니다. 하지만 그 방법으로 모든 쿠버네티스 설정을 진행하기는 힘들죠. 그래서 보통 '*.yaml' 혹은 '*.json'으로 구성된 매니페스트를 쿠버네티스 REST API를 통해 게시하여 배포를 진행합니다.

## Pod의 yaml 포맷

이전에 배포를 진행한 Pod를 통하여 yaml 파일의 포맷을 확인해보도록 하겠습니다.

아래 명령어를 통하여 확인을 진행합니다.

kubectl get po {pod name} -o yaml

yaml의 자세한 내용은 너무 길기 때문에 생략하도록 하겠습니다. 그저 간단하게 중요한 몇 가지 부분만 설명하도록 하겠습니다.

• 메타 데이터 (metadata) : 포드와 관련된 이름, 네임스페이스, 라벨 등 
• 스펙 (spec) : 컨테이너, 볼륨 등 포드 내용의 실제 설명
• 상태 (status) : 포드의 상태, 컨테이너 설명과 상태, 포드 내부의 IP 및 실행중인 포드의 정보