Udemy의 Certified Kubernetes Administrator (CKA) with Practice Tests 강의의 21. Recap - Pods 챕터를 공부한 내용으로 강의 내용과 다를 수 있습니다. 정확한 내용은 강의를 들으시는 것을 추천드립니다.
0. 가정
강의를 들어가기 전 pod를 이해하기 위해 몇 가지 가정을 한다.
- 애플리케이션은 도커 이미지로 빌드됐다.
도커 허브와 같은 도커 레포지토리에서 사용 가능해 쿠버네티스에서 이 도커 이미지를 다운 받을 수 있다. - 쿠버네티스 클러스터가 이미 작동 중이다.
싱글 노드나 멀티 노드인 건 상관 없이 모든 서비스는 실행 중이여야 한다.
1. POD
Kubernetes는 cluster에서 worker node 위의 컨테이너 형태로 어플리케이션을 배포하는게 목표다.
컨테이너는 worker node에 직접 배포되지 않고 Pod라는 객체로 캡슐화되어있다.
Pod는 어플리케이션의 단일 인스턴스로 kubernetes에서 만들 수 있는 가장 작은 객체이다.
1-1) 단일 POD
가장 단순한 구조로 pod를 이해 해본다.
Kubernetes 클러스터에 하나의 node가 있다.
Node 안에 어플리케이션 인스턴스 하나가 docker 컨테이너로 캡슐화 되어 pod에서 실행중이다.
어플리케이션 접속자가 많아지면 load를 분산하기 위해 인스턴스를 추가해야한다.
인스턴스는 같은 pod 내의 새 컨테이너 인스턴스가 아닌, 같은 node에 위치한 새로운 pod에 각각 만들어 진다.
접속자 수가 더 늘어 node에 충분한 공간이 없으면 새 node를 만들어 추가 pod를 배포한다.
클러스터의 물리적 용량을 확장하기 위해 새 node가 추가된다.
여기서 가장 중요한 점은 "Pod는 일반적으로 어플리케이션을 실행하는 컨테이너와 1대1의 관계를 가진다".
기존 pod에 컨테이너를 추가하는게 아닌 pod 생성, 삭제를 통해 어플리케이션 확장, 축소가 가능하다.
환경, load balancing 구성 방법은 추후에 배우게 된다.
1-2) Multi-Container PODs
한 pod는 하나의 컨테이너만 가질 수 있게 제한 된 것은 아니다.
한 pod는 같은 종류의 컨테이너가 아니면 여러 컨테이너를 가질 수 있다.
일반적으로 어플리케이션을 확장 하려면 같은 종류의 인스턴스(컨테이너)를 추가해야하기에 pod 추가가 필요하다.
하지만, 웹 어플리케이션은 유저 처리, 업로드 파일 데이터 프로세싱 등 지원 작업을 수행하는 헬퍼 컨테이너가 있을 수 있다.
이때 헬퍼 컨테이너가 어플리케이션 컨테이너와 함께 있어야하며 이런 경우 한 pod 내에 여러 컨테이너가 있을 수 있다.
두 컨테이너가 동일한 pod 내에 있기에 새 어플리케이션 컨테이너가 생성, 삭제 되면 헬퍼도 생기거나 삭제 된다.
두 컨테이너는 동일한 네트워크 공간을 공유해 서로 localhost로 인지해 소통한다.
또한 동일한 저장 공간을 공유한다.
1-3) Pod를 다른 각도에서 이해해보기
Pod를 더 이해하기 위해 kubernetes가 아닌 단순한 docker 컨테이너로 이해 해본다.
어플리케이션을 docker 호스트에 배포하기 위해 프로세스, 스크립를 개발중이라 가정한다.
"docker run python-app" 커맨드로 간단하게 어플리케이션을 배포할 수 있다.
어플리케이션이 정상적으로 실행되면 사용자도 접근 할 수 있다.
"docker run python-app" 명령어를 여러번 실행해 더 많은 어플리케이션 인스턴스를 배포한다.
어플리케이션이 더 개발되어 아키텍쳐의 변화를 겪고 복잡해져 어플리케이션을 도와주는 헬퍼 컨테이너가 생겼다.
헬퍼 컨테이너는 데이터를 가져오거나 처리해준다.
헬퍼 컨테이너는 어플리케이션 컨테이너와 일대일 관계를 유지하며, 직접 통신하고 데이터 접근이 필요하다.
이에 "docker run helper -link app1"과 같은 명령어로 어플리케이션과 헬퍼 컨테이너와의 네트워크 연결을 설정한다.
네트워크, 데이터 공유를 위해 공유 가능한 볼륨을 생성해 공유하고 맵으로 관리한다.
어플리케이션 컨테이너가 죽으면 필요없는 헬퍼 컨테이너도 죽이기 위해 어플리케이션의 상태를 모니터링 하는게 제일 중요하다.
kubernetes가 이 모든 복잡한 작업을 자동으로 수행한다.
Pod가 어떤 컨테이너로 구성 되는지 정의하기만 하면된다.
기본적으로 pod의 컨테이너는 동일한 스토리지, 동일한 네트워크 네임스페이스에 접근 권한을 얻는다.
또한, pod의 컨테이너들은 같이 생성되고 같이 삭제된다.
어플리케이션이 복잡하지 않아도 아키텍쳐의 확장을 위해 pod를 생성하는 것이 좋다.
multi 컨테이너 pod는 굉장히 드문 케이스이기에 이제부터는 단일 pod만 고려하여 설명한다.
2. Pod 다뤄보기
2-1) Pod 배포
앞에서 pod를 생성해 docker 컨테이너를 배포하는 "kubectl run" 커맨드를 배웠다.
"kubectl run nginx" 명령어를 입력하면 pod가 자동으로 생성되고 nginx docker 이미지의 인스턴스를 배포한다.
이때 nginx라는 이미지를 가져오기 위해 "kubectl run nginx --image nginx"와 같이 docker 허브의 저장소에서 nginx를 다운하는 --image 옵션을 넣어줘야 한다.
도커 허브는 다양한 애플리케이션들의 최신 도커 이미지들이 모여 있는 공용 저장소이다.
도커 허브나 프라이빗 저장소에서 이미지를 가져올 수 있도록 쿠버네티스를 구성할 수 있다.
2-2) Pod 확인
Pod가 생성 됐으면 "kubectl get pods" 명령어로 클러스터의 pod 목록을 볼 수 있다.
ContainerCreating 상태에서 Runnng 상태로 바뀌면 실제 실행이 된 것이다.
지금 pod는 node 내부에서만 접근 가능한 상태이다.
이후에 nginx 웹 서버에서 사용자가 접근 가능하게 만드는 방법을 배운다.
'IT 강의 > 도커 쿠버' 카테고리의 다른 글
| [CKA 강의 요약] Demo - Pods with YAML (0) | 2024.03.26 |
|---|---|
| [CKA 강의 요약] Pods with YAML (0) | 2024.03.25 |
| [CKA 강의 요약] Kube Proxy (0) | 2024.03.14 |
| [CKA 강의 요약] Kublet (0) | 2024.03.14 |
| [CKA 강의 요약] Kube Scheduler (0) | 2024.03.07 |