쿠버네티스의 기본 구성

1. 먼저 아래와 같이 kubectl get pod --all-namespaces를 하면 모든 pod들이 나열된다.

일단 위에 대한 설명을은 천천히 뒤에서 하기로 하자.

 

먼저 쿠버네티스의 기본적인 아키텍처를 보면 아래와 같다.

https://kubernetes.io/ko/docs/concepts/overview/components/

중요한 것들을 살펴보면 크게 

- master node, worker node 

- pod

- service

- ingress

- kube-apiserver

- kube-scheduler

- kube-controller-manager

- kubelet

- kube-proxy

- etcd

- coredns

- CNI ( flannel, calico 등 )

- metrics-server 

이 외에도 아주 많다. 다보지는 않고 몇개만 살펴보자

 

1. master node , worker node

마스터 노드는 말 그대로 쿠버네티스가 동작하기 위해서 중요한 역할들을 하는 노드이다. 위 그림에서 컨트롤 플레인을 명칭한다. etcd, 스케쥴러, 컨트롤러메니저 등이 기동되고 있으며, 쿠버네티스의 api서버로서 클라이언트의 명령을 받아들이고 실행한다. 또한 파드 스케쥴링 등 여러가지 역할을 하고 있다.

 

2. pod

파드는 컨테이너를 실행하기 위한 최소 단위이다. 파드는 한개 혹은 여러개의 컨테이너를 담을 수 있다.

여러가지 단계가 존재하는데 아래와 같이 공식 홈페이지에 정리되어 있다.

https://kubernetes.io/ko/docs/concepts/workloads/pods/pod-lifecycle/

이러한 pod를 배포하는 전략이 여러가지가 있는데 기본적으로는 롤링업데이트로 되어있다. 아래의 블로그를 보면 많은 도움이 된다. 배포 전략은 서비스의 상황에 맞게 전략적으로 가지고 가야한다.

https://blog.container-solutions.com/kubernetes-deployment-strategies

Kubernetes deployment strategies

pod의 생성을 보자. pod의 생성은 아래 이미지와 같다.

https://blog.heptio.com/core-kubernetes-jazz-improv-over-orchestration-a7903ea92ca

etcd의 역할이 굉장히 중요한데 모든 정보들이 etcd에 write되고 필요할때 read된다고 생각할 수 있다. 중요한 만큼 master node에서 분리한 후 외부 VM에 구축하여 클러스터링하여 운영하기도 한다.

 

이번에는 삭제과정을 간략하게 보자.

https://www.infracloud.io/blogs/kubernetes-pod-lifecycle/

과정을 보면 사용자가 delete 명령어를 날려도 바로 삭제하지 않고 디폴트 30초 기다리는 것을 볼 수 있다. graceful 하게 종료되는 것을 의도한 값이다. 이 값은 30초 이상으로도 셋팅이 가능하며 성능테스트를 통해 적절한 값을 설계해야 한다.

 

아래 그림을 보면 전체적인 느낌을 이해할 수 있다.

 

 

3. 서비스 (service)

서비스는 앞단에서 들어온 요청들을 pod단으로 전달하기 위해 프록시를 구성할 수 있도록 하는 컴포넌트이다.

즉 로드밸런서의 역할을 가지며, 클라이언트 요청을 받기 위한 대표IP주소를 가진다.

아래 그림을 보면 실제로 이 서비스를 통해 어떻게 사용자 트래픽을 받을지에 대한 방법들에 대해 볼 수 있다.

https://medium.com/nerd-for-tech/kubernetes-services-f623c53213ed

 

4. 인그레스 (ingress)

인그레스는 클러스터 외부에서 클러스터 내부 서비스로 접근할 수 있도록 HTTP,HTTPS경로를 노출한다. 

들어온 트래픽 라우팅은 인그레스 yaml에 정의된 규칙에 의해 라우팅된다. 

하지만 이는 규칙만 설정할뿐 실제 고객데이터를 받는 역할을 하지는 않는다. ingress controller가 필요하다.

종류로는 nginx나 kong 등이 있고 aws와 같은 클라우드 회사에서는 ALB ingress같은 상품을 지원하기도 한다.

 

필자는 AWS를 사용하여 운영을 했었는데 ALB ingress는 상당히 사용하기 쉽게 제공되어 운영하기 편리하다.

아래의 아키텍처를 참고해보자

https://aws.amazon.com/ko/blogs/opensource/kubernetes-ingress-aws-alb-ingress-controller/

그림을 보면 Rule에서 /* , /products, /accounts 등 L7 레이어단의 path를 기반으로 분산하도록 설정이 되어 있다. 

이렇게 특정 url path로 들어온 트래픽은 설정된 Target Group으로 넘어가게 되는데, 실제 aws를 이용해보면 타겟그룹별 port를 지정할 수 있고 이것은 node port를 의미하며 해당 node port로 배포되어 있는 pod로 트래픽이 들어가게 된다. 

 

 

5. kube-scheduler

스케쥴러는 이름에서 이해할수 있는 것처럼, pod 생성 요청이 오면 어떤 노드에 생성할지를 스케쥴링하는 역할을 하며 마스터노드에 기동되어 있다.

 

해당 pod를 어떤 노드에 배포할지 정하는 기준은 2가지 단계를 거치게 된다.

1.  필터링

2.  스코어링

필터링은 말그대로 배포할 수 있는 노드들을 골라내는 작업이다 .이렇게 배포 가능한 노드들이 선정이 되면, 내부적으로 설정된 스코어링 방식을 기준으로 가장 우선순위가 높은 노드에 pod를 배포하게 된다.