Udemy의 Kubernetes for the Absolute Beginners - Hands-on 과정을 요약한다.
오늘은 두 번째 주제로 Kubernetes Overview이다. (첫 번째는 강의소개라서 생략)
* Kubernetes(K8s): Container + Orchestration
(구글에서 만든, 요즘 시대에 가장 유명한 컨테이너 오케스트레이션 기술)
1. Container, 컨테이너는 무엇이고 왜 필요할까?
(컨테이너는 최근 기술이 아니라, 10년 전에도 있었던 기술이다.)
과거에는 서버 위 여러 app들을 올리면, 각 app들에서 호환되는 OS나 Library 버전들이 모두 달라 많은 이슈가 있었다.
그래서 이 호환성 문제의 해결책으로 컨테이너(Container) 라는 개념이 나왔다.
컨테이너는 Docker 위에 올라가는데, 각 Container는 독립된 라이브러리와 dependency를 가질 수 있다.
그래서 Container가 뭐냐면, 완벽히 독립적으로 구분된 환경(completely isolated environments) 이다.
컨테이너는 각자 독립된 network interface와 VM같은 마운트를 가지는데, 동일한 os 커널을 사용한다.
* 동일한 os 커널을 사용하는 게 단점은 아니냐고?
Docker는 가상화를 하기 위한 수단이 아니라, 동일한 hw에 다른 os와 커널을 실행시키는 것이다.
- Docker의 주된 목적: 앱들을 컨테이너화 시키고, 이동, 실행 시키는 데에 있음
컨테이너 개념을 VM과 비교를 해보자면,
VM은 Docker대신 Hypervisor가 있었고, VM마다 OS를 별도로 갖고 있었다.
그러다보니 각 VM당 용량이 GB 이상으로 컸고, 이는(overhead) 많은 부하까지 야기 시켰다.
반면, 컨테이너는 앱마다 OS가 별도로 존재하지 않아 빠른 부팅속도와 작은 용량을 가지고 있다.
(전체 os를 재기동할 필요 없으니 빠를 수 밖에 없다)
컨테이너는 상대적으로 덜 고립(isolation) 되어 있고, 더 많은 리소스를 공유해서 사용할 수 있지만,
vm은 완전히 분리되어 있다고 볼 수 있다.
(이 외 image 부분 및 장단점은 기본적이라 요약에서 제외)
2. 그럼, Orchestration은 무엇일까?
- app들을 컨테이너에 넣었다고 가정하자. 그런데 이걸 어떻게 실행할까?
- 만약 특정 app이(ex. messaging app, DB, backend service..) 다른 컨테이너에 의존해야 한다면 어떻게 할까?
- 그리고 컨테이너 증감이 필요하다면 어떻게 해야할까?
=> 이런 기능들이 가능하기 위해 리소스 및 platform이 필요하다. 이 플랫폼은 컨테이너간 connectivity와 scale up/down을 orchestrate 해야하는데, 이렇게 컨테이너를 관리하고 자동으로 deploy하는 전반적인 프로세스가 Container Orchestration다.
all public cloud service(ex. GCP, Azure, AWS 등)를 지원한다.
Container orchestration는 다양한 장점이 있다.
- app들은 highly avalable한 상태가 된다.
왜? app들이 각각 다른 노드에서 running 되기 때문에 (multiple instance를 갖고 있기 때문),
hw dependancy가 없어진다.
- load balance도 가능 (cluster 구성이기 때문에),
- 노드들의 부하에 따라 자동으로 노드의 scale in/out이 가능하다.
그럼 위에서 말한 cluster, node들은 무엇일까? Architecture에서 알아보도록 하자.
3. Kubernetes Architecture
1) Node(=minion): K8s가 설치된 physical or virtual한 machine 자체이다.
node는 worker machine이고, k8s에 의해 컨테이너가 설치된다. 과거엔 Minion라고 불리기도 했다.
여기서, 우리 app이 설치된 Node가 죽으면 어떻게 될까? 만약 Node가 1개라면 죽을 것이다.
2) Cluster: Node들간의 구성
그림과 같이 Node가 다수 개라면?
app하나가 죽는다해도 다른 Node를 통해 여전히 accessible할 수 있다. 이는 부하분산 또한 가능하게 해준다.
그런데, 이런 Node들은 어디서 관리할까?
3) Master: 클러스트들을 관리 및 정보저장, 모니터링, 부하분산, fail-over 동작을 한다.
4) 이외 여러 구성요소 (Components)
- API server acts as the front-end for kubernetes. The users, management devices, Command line interfaces all talk to the API server to interact with the kubernetes cluster. => k8s의 FE로, cluster와 통신하기 위한 입구.
- ETCD is a distributed reliable key-value store used by kubernetes to store all data used to manage the cluster. Think of it this way, when you have multiple nodes and multiple masters in your cluster, etcd stores all that information on all the nodes in the cluster in a distributed manner. ETCD is responsible for implementing locks within the cluster to ensure there are no conflicts between the Masters. => 전체 데이터 저장소
- scheduler is responsible for distributing work or containers across multiple nodes. It looks for newly created containers and assigns them to Nodes. => 부하 분산
- controllers are the brain behind orchestration. They are responsible for noticing and responding when nodes, containers or endpoints goes down. The controllers makes decisions to bring up new containers in such cases.
=> 뇌. 컨테이너나 엔드단이 down 됐을 때 알림을 주고 새 컨테이너를 띄울지 결정하는 곳
- container runtime is the underlying software that is used to run containers. In our case it happens to be Docker. And finally kubelet is the agent that runs on each node in the cluster. The agent is responsible for making sure that the containers are running on the nodes as expected
=> 컨테이너를 띄우기 위한 sw이고, kubelet이 각 노드를 띄우기 위한 agent임
각 컴포넌트간 동작과정은 조금 복잡하므로 요약에서 제외하고, 필요할 때 보도록 하자.
5) kubectl(=kubel control): k8s에서 사용되는 command line 유틸리티
app을 deploy하거나 조회할 때 사용하는 명령어 유틸리티.
Overview 섹션은 여기까지이고 생략한 부분도 일부 있다.
그렇게 섹션이 끝날 때마다, 퀴즈가 주어지는데, 이번 섹션(섹션 2: Kubenetes Overview)에서는 8개 중 7 문제를 맞췄다.
틀린 문제를 지금와서 보니..답이 바로 보인다. 역시 공부는 정리를 해야 내 것이 되나보다.
출처)
자료의 기반은 모두 Udemy의 'Kubernetes for the Absolute Beginners - Hands-on' Course 입니다!
