[CKA] Kubernetes Pod

Kubernetes Pod

 

Pod을 이해하기 전에 다음 항목이 이미 설정되었다고 가정해 보자.이 시점에서, 우리는 애플리케이션이 이미 개발되어 Docker 이미지에 내장되어 있으며 쿠버네티스가 다운할 수 있도록 Dockerhub 와 같은 도커 저장소에서 사용할 수 있다고 가정하자. 또한 Kubernetes 클러스터가 이미 설정되었고 작동 중이라고 가정한다. 단일 노드 설정 또는 다중 노드 설정이어도 상관없다.

모든 서비스가 실행 중이어야 한다. 우리의 궁극적인 목표는 클러스터에서 Worker Node로 구성된 기계 세트에 우리의 애플리케이션을 컨테이너 형태로 배포하는 것이다. 그러나 Kubernetes는 컨테이너를 Worker Node에 직접 배포하지 않는다.

컨테이너는 Pod라고 알려진 쿠버네티스 객체에 캡슐화된다. Pod는 응용 프로그램의 단일 인스턴스이다. Pod는 Kubernetes에서 만들 수 있는 가장 작은 객체이다.

단일 노드인 Kubernetes 클러스터가 있고 단일 애플리케이션이 Pod로 캡슐화된 단일 Docker 컨테이너에서 실행되는 가장 간단한 경우가 있을때, 응용 프로그램에 접근하는 사용자 수가 증가하고 응용 프로그램을 확장해야 하는 경우 로드를 공유하기 위해 웹 응용 프로그램의 인스턴스를 추가해야 한다.

추가 인스턴스를 어디서 찾을 수 있을까? 동일한 Pod 내에서 새 컨테이너 인스턴스를 불러올까?
아니다, 동일한 애플리케이션의 새 인스턴스와 함께 새 Pod를 만든다. 이제 동일한 쿠버네티스 시스템 또는 노드에서 웹 애플리케이션의 두 인스턴스가 두 개의 개별 포드에서 실행되고 있다. 사용자 기반이 더 증가하여 현재 노드에 충분한 용량이 없을 경우 어떻게 해야 할까? 그러면 언제든지 새 노드에 추가 포드를 배포할 수 있다. 클러스터에서 클러스터의 물리적 용량을 확장하기 위해 새 노드를 클러스터에 추가한다.

 

Pod가 일반적으로 응용 프로그램을 실행하는 컨테이너와 1:1 관계를 가지고 있다. 확장하려면 새 Pod를 만들고 축소하려면 기존 Pod를 삭제한다. 애플리케이션을 확장하기 위해 기존 포드에 컨테이너를 추가하지 않는다.

그럼 우리는 하나의 Pod에 하나의 컨테이너를 가지고 있는 것으로 제한될까?
아니다. 일반적으로 동일한 종류의 여러 컨테이너가 아니라는 점을 제외하고 단일 포드는 여러 컨테이너를 가질 수 있다.
애플리케이션을 확장하려면 추가 Pod를 만들어야 하지만 때로는 사용자 처리, 데이터 입력, 사용자가 업로드한 파일 처리 등과 같은 웹 응용 프로그램에 대한 일종의 지원 작업을 수행하는 도우미 컨테이너가 있을 수 있으며 이러한 도우미 컨테이너가 응용 프로그램 컨테이너와 함께 사용되기를 원하는 시나리오가 있을 수 있다. 이 경우 이 두 컨테이너를 모두 동일한 Pod의 일부로 만들 수 있으므로 새 응용 프로그램 컨테이너가 생성되면 도우미도 생성되고 도우미도 동일한 포드의 일부이기 때문에 죽게 된다.
두 컨테이너는 동일한 네트워크 공간을 공유하기 때문에 서로를 로컬 호스트라고 지칭하여 직접 통신할 수도 있다. 또한 동일한 스토리지 공간을 쉽게 공유할 수 있다.


Docker 호스트에 애플리케이션을 배포하기 위한 프로세스나 스크립트를 개발했다고 가정해 보자.

그런 다음 먼저 간단한 Docker 실행인 Python App Command를 사용하여 애플리케이션을 배포하면 애플리케이션이 정상적으로 실행되고 사용자가 접근할 수 있다. 부하가 증가하면 Docker run 명령을 여러 번 실행하여 애플리케이션의 인스턴스를 더 많이 배포한다. 

응용 프로그램은 추가로 개발되고 아키텍처 변경을 거치며 성장하고 복잡해진다. 이제 다른 곳에서 데이터를 처리하거나 가져와 웹 애플리케이션을 지원하는 새로운 도우미 컨테이너가 생겼다.
이러한 도우미 컨테이너는 애플리케이션 컨테이너와 1:1 관계를 유지하므로 애플리케이션 컨테이너와 직접 통신하고 해당 컨테이너의 데이터에 액세스해야 한다. 이를 위해 어떤 앱의 지도를 유지하고 컨테이너가 서로 연결되도록 도와야 한다. 우리는 링크와 사용자 지정 네트워크를 사용하여 이러한 컨테이너 간의 네트워크 연결을 설정해야 한다. 공유 가능한 볼륨을 생성하여 컨테이너 간에 공유해야 하고 그것에 대한 지도도 유지해야 할 것이다. 그리고 가장 중요한 것은 애플리케이션 컨테이너의 상태를 모니터링해야 하고, 상태가 나빠지면 도우미 컨테이너를 새 컨테이너가 배포될 때 더 이상 필요하지 않으므로 수동으로 종료해야 하며 새로운 도우미 컨테이너도 배치해야 한다.

Kubernetes Pod 를 사용하면 이 모든 작업을 자동으로 수행할 수 있다.
자동으로 Pod가 어떤 컨테이너로 구성되어 있는지 정의하기만 하면 기본적으로 Pod의 컨테이너는 동일한 스토리지, 동일한 네트워크 네임스페이스 및 동일한 생명주기에 액세스할 수 있다. 그들은 함께 생성되고 함께 제거될 것이다.

비록 우리의 애플리케이션이 그렇게 복잡하지 않았고 우리는 하나의 컨테이너로 살 수 있었다 하더라도 애플리케이션이 현재 미래의 아키텍처 변화와 확장에 적합하기 때문에 장기적으로 볼 때 이것은 좋다. 그러나 다중 Pod 컨테이너는 드문 사용 사례이며,Pod당 단일 컨테이너를 고수할 것이다.

 

이제 Pod을 배포하는 방법을 살펴보자

$ kubectl run nginx–-image nginx

 

이 명령은 실제로 Pod를 생성하여 Docker 컨테이너를 배포한다. 먼저 자동으로 Pod를 생성하고 nginx 도커 이미지의 인스턴스를 배포한다. 애플리케이션 이미지는 어디에서 얻을 수 있을까? 이를 위해서는 image 매개변수를 사용하여 이미지 이름을 지정해야 한다. 이 경우 nginx 이미지가 Docker Hub 저장소에서 다운로드된다.
Docker Hub는 다양한 애플리케이션의 최신 docker 이미지가 저장되는 공용 저장소이다. 공용 Docker Hub 또는 조직 내 개인 리포지토리에서 이미지를 가져오도록 Kubernetes를 구성할 수 있다.

 

사용 가능한 Pod 목록을 어떻게 볼 수 있을까?

$ kubectl get pods

 

kubectl get pod 명령을 사용하면 클러스터의 포드 목록을 볼 수 있다.

 

 

 

 

 

 

출처:

https://www.udemy.com/course/certified-kubernetes-administrator-with-practice-tests/learn/lecture/14298578#content