Recap -Pods

최종 목표는 쿠버네티스 클러스터의 워커노드에 컨테이너 형태의 app을 배포하는거다.

 

근데, 쿠버네티스는 컨테이너를 워커노드에 직접 배포하진않는다. 

컨테이너는
"Pod"라고 불리는 "쿠버네티스 object" 형태로 포장된다.

pod는 하나의 어플리케이션의 인스턴스다.

pod가 쿠버네티스에서 생성할수있는 가장 작은 object다. 

 

사용자가 늘면 로드를 분산할 앱을 추가해야할것이다.

spin up을 어케할까? ->

pod에 컨테이너를 추가할까? X

동일한 pod를 추가한다.

만약 노드가 감당할수있는 사용자수를 넘기면? 

클러스터에 새 노드에 추가 pod를 배포할 수있다.

클러스터의 물리적 용량을 확장하기위해서!

 

Pod에는 여러 컨테이너가 담길수 있다.

사용자 처리를 할때 helper container 를 쓸 수도 있는데, 

Pod안에 새로운 container 가 생기면 , helper container 도 생기고,

container 가 죽으면 helper container 도 죽는다. 

두 컨테이너는 localhost 로 서로 직접적으로 통신가능하다. 

또한, 동일한 storage 를 쉽게 바라본다. 

 

만약 pod 가 없다면, 

docker 로 app을 매번 실행시키고, 이에 상응하는  helper container 도 각 app에 맞춰 매번 실행시켜줘야 한다.

지우는것도 각각 별도로 해줘야 한다.

pod 가 있으니, 

app 정보와 helper container 정보만 pod 생성시 기입하면, pod 단위로 생성, 삭제가 가능하여 간편하다.

 

단, 만약 복잡하지 않은 단순한 하나의 컨테이너를 띄울때도 쿠버네티스는 pod를 필요로 하지만, 

향후 아키텍쳐 변화와 확장에 대비하면 장기적으로 봤을땐 더 좋다.

 

Kubectl 

아래 명령어 수행시에 실제로 pod를 생성하고, 컨테이너를 배포할떄 어떻게 작동할까?

 

kubectl run nginx

1. pod를 자동적으로 생성한다.

2. nginx docker image 에대한 인스턴스를 배포한다.

-> 이 이미지는 어디서오나? : parameter로 image 명을 명시해줘야한다.

그러면, docker hub registory 에서 받아온다. 

또는 설정한 private repository 에서 받아온다.

kubectl run nginx --image nginx

사용가능한 pods 는 어떻게 보나?

kubectl get pods