쿠버네티스 구조

쿠버네티스가 수행하는 작업과 수행하지 않는 작업을 이해하는 것이 중요하다.

- 쿠버네티스가 수행하지 않는 작업

개발자가 작업해야 하는 것은 클러스트와 노드 생성이다.

쿠버네티스는 최종 아키텍처를 정의하는 올인원 도구이지만 클러스터, 마스터노드, 워커 노드 등의 기본적인  리소스를 스스로 생성하지 않으며 그것은 쿠버네티스가 하는 일이 아니다.

 

- 쿠버네티스가 수행하는 작업

쿠버네티스는 포드의 모니터링, 포드 컨테이너의 모니터링, 실패한 포드 교체 및 포드의 스케일링 등, 이러한 포드를 관리하는데 도움을 주는 것이지 클라우드 인프라 생성이나 인프라 서비스 프로바이더 역할을 수행하지 않는다. 때문에 쿠버네티스는 인프라에 대해 아무것도 알지 못한다.

그러므로 쿠버네티스는 구체적인 리모트 머신의 구체적인 가상 인스턴스, 또는 작업하려는 컴퓨터에 대해 전혀 알지 못한다. 따라서 우리는  마스터 노드와 워커 노드에 API서버, kubelet 등의 쿠버네티스 구성에 필요한 서비스를 설치해야 한다.

하지만 쿠버네티스에 필요한 도구(EC2, 로드밸러서, kubelets, API서버, 스케줄러 등)를 직접 설치하는 것은 번거롭기 때문에 Kubermatic 이나 AWS EKS와 같은 전용 서비스들을 사용한다. 이것들은 자체 쿠버네티스 구성을 불러오는 것을 허용하는 서비스이다.

 

마스터 노드 : API 서버와 스케줄러 등 

워커 노드 : Docker, Kubelet

kubectl : kube control 도구, 새 deployment 생성, deployment 삭제 또는 실행 중인 deployment 변경과 같은 명령을 클러스터에 보내는데 사용되는 도구이다. 개발자 및 관리자가 마스터 노드에 명령을 보낼 수 있으며, 마스터 노드는 워커 노드와 관련하여 필요한 모든 작업을 수행한다.

 

- 쿠버네티스 객체 이해하기

Pods, Deployments, Services, Volume 객체

특정 명령으로 이런 객체를 만들 수 있다.

 

- Pods 객체

쿠버네티스와 상호작용하는 가장 작은 유닛. Pod는 하나 이상의 컨테이너를 보유하고 쿠버네티스는 이러한 Pod와 컨테이너를 관리한다. 또한 컨테이너뿐만 아니라 볼륨 같은 공유 리소스를 보유한다. 여기서 중요한 것은 Pod도 클러스트의 일부이므로, 다른 Pod나 외부 세계와 통신할 수 있다는 것이다. 디폴트로 Pod에는  내부 IP주소가 있으며 하나의 Pod내에 여러 컨테이너끼리는 localhost를 통해 통신할 수 있다. 이는 AWS ECS의 태스크와 비슷하다.

 

*Pod에 대해 염두에 두어야 할 2가지 중요한 사항

1. Pod는 임시적이다. Pod가 삭제되면 모든 리소스 손실된다.

 

- Deployment 객체

일반적으로 수동으로 Pod 객체를 생성하여 특정 워커 노드로 이동시킨 뒤 직접 관리하는 것 대신 Deployment 객체를 생성하여, Pod와 컨테이너를 관리할 수 있다. Deployment 객체는 하나 이상의 Pod를 제어할 수 있다. 이로써 수동으로 리모트 머신에 접근하여 pod를 배치할 필요없이 쿠버네티스가 pod를 생성하고 제어할 수 있게 된다. 또한 Deployment를 일시 중지하거나, 삭제, 롤백할 수도 있으며 스케일링 기능을 사용할 수 있다.

 

클러스터 가동 후 master node에 Deployment 객체를 생성하라는 명령어 전송 -> Kubelet 사용

 

*새로운 Deployment 객체 생성 명령어 : kubectl create deployment {객체 이름} --image={생성된 Pod에사 사용할 image 이름}

Deployments 생성 후 확인

-deployment 업데이트

이미지 재빌드 후 -> docker hub push ->  kubkectl set image deployment/{deployment name} {현재 container name}={new image name}

*참고) 이미지 재빌드 시 새로운 태그를 지정해야 쿠버네티스가 새로운 이미지를 다운로드한다.

 

roll out check 명령어 : kubectl rollout status deployment/{deployment name}

 

업데이트를 실패하더라도 새로운 pod가 구동되어 실행되기 전까지 오래된 pod를 종료하지 않는다. 또한 쿠버네티스는 업데이트를 계속 시도한다. 이럴 경우 쿠버네티스가 계속 업데이트를 시도하는 것을 막기위해 실패한 업데이트를 롤백하는 작업이 필요하다. 

롤백 명령어 : kubectl rollout undo deployment/{deployment name}

 

방금 전의 업데이트를 롤백하는 것이 아닌 더 이전의 버전으로 롤백하기 위해서 먼저 히스토리 내역을 볼 수도 있다.

history 조회 명령어 : kubectl rollout history deployment/{deployment name}

 

히스토리 내역엔 업데이트 별로 revision이 할당되어 있으며 이를 가지고 롤백 명령에 추가로 작성하여 돌아가고 싶은 deployment로 롤백할 수 있다.

롤백 명령어 revision 태그 추가 : kubectl rollout undo deployment/{deployment name} --to-revision={롤백할 revision 번호}

 

 

- Service 객체

쿠버네티스의 서비스란 파드의 집합을 의미한다. Pod에서 실행되고 있는 컨테이너에 접근하기 위해서는 service가 필요하며,  Pod들을 하나의 Service로 묶어 해당 Pod들을 한번에 관리한다.

 

Pod에는 디폴드로 이미 내부 IP주소가 있다. 하지만 이 IP 주소에는 두가지 문제가 있다. 

첫 번째는 클러스터 외부에서 pod에 액세스할 수 없다.

두 번째는 Pod가 교체될 때마다 IP 주소가 변경된다.

이를 위해 Servcie는 Pod를 그룹화하고 공유 주소, 공유 IP 주소를 제공한다. 즉 Service를 사용하여 여러 Pod를 해당 service로 이동하고  변경되지 않는 IP 주소에 연결한다. 또한 클러스터 외부에도 이 주소를 노출하도록 service에 지시할 수 있다.

 

service 생성 명령어 : kubectl expose deployment {deployment name} --type={tpye option} --port={port num}

 

tpye 옵션

1. ClusterIP - 클러스터 내부에서만 연결할 수 있음을 뜻한다.

2. NodePort - deployment가 실행 중인 워커 노드의 IP 주소를 통해 노출 됨을 뜻한다.

3. LoadBalancer - 실제로 service에 대한 고유한 주소를 생성하고 들어오는 트래픽을 이 service의 일부인 모든 pod에 고를게 분산하는 기능을 수행한다.

 

*minikube에 생성한 클러스터의 경우 로컬 가상 머신에 생성한 것이기 때문에 External-IP는 pending 상태로 유지된다. minikube는 이를 위해 IP에 특수 포트를 매핑하여 로컬머신에서 가상 머신에 접근할 수 있도록 해준다. 

 

service 접근 명령어 : minikube service {service name}

- scale 기능

kubectl scale deployment /{deployment name} --replicas=3

pods가 3개로 늘었났으며 로드밸런서로 인해 트래픽이 3개의 pod으로 분산되어 redirect된다. 이는 자동으로 스케이링되지 않지만 쿠버네티스에서 얻을 수 있는 유용한 기능이다.