Kubernetes
안녕하세요! 오늘은 Kubernetes에 대해서 배워 보는 시간을 가져 보도록 하겠습니다. 일단 Kubernetes에 대해 알아 보기 전에, Container Orchestration에 대해서 먼저 알아 보도록 하겠습니다.
Container Orchestration이란, 컨테이너의 배포, 관리, 확장, 네트워킹 등을 자동화 하는 것을 의미 합니다. 우리는 어플리케이션들을 컨테이너화 하면서, 원하는 시간에 빠르게, 안정적으로 어플리케이션을 배포 할 수 있게 되었습니다.
우리는 이러한 이점으로, 다양한 이슈를 해결 할 수 있었습니다. 장애가 생긴 어플리케이션을 빠르게 재시동 한다던지, 트레픽에 따라 컨테이너를 복사하여 빠르게 늘리고 줄이던지 말이죠.
하지만, 아직 뭔가 아쉽습니다. 이러한 것들을 우리가 자동으로 했으면 더 좋을텐데 말이죠. 컨테이너에 이상이 생기면, 자동으로 컨테이너를 재시작 해주고, 트레픽에 따라 자동으로 컨테이너를 늘렸다, 줄였다, 해 주는 방식으로 말이죠.
우리는 이러한 Container Orchestration을 지원 해 주는, Kubernetes의 개념에 대해 이번 시간에 배워 보려고 합니다.
Kubernetes
Docker Swarm?
사실, Container Orchestration은 Docker에 내장 되어 있는, Docker Swarm으로도 가능 합니다. 저도 실제로 많은 프로젝트에서 Docker Swarm을 사용 합니다. 하지만, Docker Swarm과 Kubernetes의 장단점을 비교 하면 다음과 같습니다.
대신 귀여운 돌고래를 드리겠습니다.
Docker Swarm
- 장점: 가볍다, 설치 및 설정이 간편하다, 소~중형 시스템에서는 좋다
- 단점: 대형 클러스터를 다루는 데에는, 대시보드, 중앙 관리를 위한 API 서버등을 지원 하지 않는다.
Kubernetes
- 장점: 매우 안정적이다, 중~대형 클러스터를 다루는 데에 좋다, 대시보드, 중앙 관리를 위한 API 서버 등을 지원 한다.
- 단점: 무겁다, 소형 서비스에는 적합 하지 않다.
Kubernetes의 아키텍처
Kubernetes의 아키텍처의 구성 요소는 다음과 같습니다.
대신 귀여운 돌고래를 드리겠습니다.
일단 구성요소 하나하나 설명을 드리겠습니다.
- API Server: 말 그대로 클러스터의 상태를 바꾸거나 조회 하는데에 사용하며, REST API 형태로 다른 요소들과 통신 합니다. 내부 통신, 외부 접속등 어떠한 요청이 올 때마다. 권한을 체크하여, 권한이 없을 경우에는 요청을 차단 합니다.
- etcd: 클러스터의 모든 상태와 메타 데이터를 저장 합니다. 분산 시스템으로 구성하여 안전성을 높이고, 가볍고 빠르면서 정확한 데이터가 오고 갈 수 있도록 합니다. Key-Value 형태로 데이터를 저장합니다. 중요한 데이터니 만큼 백업이 요구 됩니다. 또한 etcd에는 Current State와 Desired State에 대한 정보를 가지고 있는데, API Server 측에서 Current State와 Desired State를 비교 하여, 둘이 일치 할 수 있도록 상태를 조절 합니다.
- Scheduler: 새로 생성된 Pod을 감지하며, 해당 Pod에 대한 요청이 들어 왔을 때, 어떤 노드에 Pod를 실행을 할지 결정 합니다. 또한, 노드의 상태와 Pod의 요구 사항들을 체크 하는 역할 또한 진행 합니다.
Node, Pod의 관계 (출처: https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/explore/explore-intro/)
- Controller: 끊임 없이 상태를 체크하고 원하는 상태를 유지 합니다. 논리적으로 복제, 노드, 엔드포인트 등 다양한 컨트롤러가 존재 합니다.
- Kubelet: 각 노드에서 실행되며, Pod을 실행 및 중지하고 상태를 체크합니다. 또한, Container의 Runtime Interface를 제공 합니다. 즉, 컨테이너와 연결 될 수 있도록 도와준다는 것이지요.
- Proxy: 네트워크 프록시와 부하를 분산시키는 역할을 합니다. 성능의 이슈가 있어, 커널 레벨에서 iptable을 제공 해 주어, 설정만 관리 해 줍니다.
Examples
- 사용자가 하나의 Pod를 API Server에 요청 합니다.
- API Server는 Pod을 요청 한 정보를 etcd에 작성 합니다.
- Controller는 새 Pod 생성 요청이 들어 온 것을 확인합니다.
- Controller가 실제 Pod을 할당하는 요청을 API Server에 전달 합니다.
- API Server는 Pod 할당 요청 정보를 etcd에 작성 합니다.
- Scheduler는 새 Pod 할당 요청이 들어 왔는지 확인 합니다.
- Scheduler는 적당한 노드를 골라, 이에 Pod을 할당 하도록 API Server에 요청 합니다.
- API Server는 특정 노드에 Pod이 할당 되었다는 정보를 etcd에 작성 합니다.
- Kubelet은 현재 미실행 Pod을 확인하고, Pod을 생성 (실행) 합니다.
- Kubelet은 Pod이 생성 되었다는 정보를 API Server에 전달 합니다.
- API Server는 Pod이 생성 되었다는 정보를 etcd에 기록 합니다.
Kubernetes의 Object
다음은 Kubernetes의 Object에 대해서 설명 하겠습니다.
Pod
Kubernetes는 Container가 아닌, Container를 감싸는 Pod을 배포 합니다. 각 Pod는 전체 클러스터에서 고유한 IP를 할당 받습니다. 또한, Pod 내부에는 여러 개의 컨테이너가 있을 수 있습니다. 각 Pod은 용도에 따라, 네트워크 혹은 볼륨을 Pod 내부에 있는 Container마다 공유 할 수 있습니다.
Pod (출처: https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/explore/explore-intro/)
ReplicaSet
ReplicaSet은, 여러 개의 Pod을 한꺼번에 관리 하는 데에 사용합니다. ReplicaSet 내부에서 Pod이 새로 생성 될때는, ReplicaSet 내부의 PodTemplate을 이용 합니다.
ReplicaSet
Deployment
배포 버전을 관리하는 오브젝트 입니다. 내부적으로 ReplicaSet을 이용하며, 이를 통해 무중단 배포가 가능 하게끔 합니다. 내부 Pod이 변경 될 때, 순간적으로 하나의 ReplicaSet을 분리하여 두 개의 ReplicaSet을 만듭니다. 하나는 변경 점이 없는, 하나는 업데이트가 된 것으로 분리 합니다.
Deployment
Service
네트워크 또한, 별도의 오브젝트를 이용하여 관리 하는데, 바로 Service를 이용하여 관리 합니다.
ClusterIP
Service 안에는, ClusterIP라는 요소가 있습니다. 이는 여러 개의 Pod에 대한 로드 벨런싱 기능도 수행 하며, Pod을 동적으로 추가, 업데이트 및 삭제를 하더라도, Service의 IP는 고유한 IP로 고정 이기 때문에, 외부에서 조정을 할 필요가 없습니다.
ClusterIP
또한, 클러스터 내부에서는 Service의 ClusterIP를 통해 접근 합니다.
내부 접근
외부에서의 접근을 위해서 NodePort를 활용 합니다. 동일한 기능을 하는 노드가 여러 개라도, 하나의 노드로 취급 합니다.
NodePort
멀리서 그림을 그려보면, 다음과 같을 수 있겠네요.
NodePort