
- 서버 관리의 어려움
- Container Orchestration
- Kubernetes
- 학습 방향

관리해야하는 서버의 수가 기하급수적으로 늘어나면, '어느 서버가 문제가 있는지?', '어느 서비스가 문제를 갖고 있는지?' 또 '이런 문제들을 얼마나 빨리 알고 해결할 수 있을지?'와 같은 물음에 답하기 곤란한 상황이 일어난다.
이러한 문제를 어떻게 해결하는 지가 중요한데, 요즘은 Infrastructure As Code 라고 해서 자동화된 스크립트를 이용해서 다수의 서버들에 명령을 대신 실행해주는 툴들을 이용한다. 다수의 서버에 설치 작업을 하고, 명령을 내리는 것은 가능하지만, 소프트웨어 충돌 문제에는 크게 도움이 안되는 단점이 있는데, 이를 해결하기위한 수단으로 Docker를 사용한다.

Docker를 사용하면 모든 소프트웨어를 Docker Image로 만들기 때문에 버전 관리, 배포 작업에 용이하고 문제 발생 시 롤백도 쉽다. 또한 VM에 비해 리소스 낭비도 적고 실행 시간도 빠른 장점이 있다. 오픈소스라 클라우드나 특정 업체에 Lock-in 이슈도 없기 때문에 Docker는 이제 서비스 배포의 기본이 됐다. 이제 DevOps 엔지니어들은 모든 서비스를 Docker Image로 만들어서 운영한다.

이렇다보니 다수의 Docker Image들을 더 많은 수의 Docker Container로 실행해야하기 때문에 관리가 힘들다는 점이 부각되었다. 그래서 다음의 문제를 해결하기 위해서 Docker Container를 효율적으로 관리할 수 있는 도구의 필요성이 생겼다.

이런 배경하에 탄생한 것이 Kubernetes와 같은 Container Orchestration 툴이다.
Container Orchestration의 기능을 요약하자면 다음과 같다.

서비스 이미지를 Container로 배포하는 기능을 말한다. 만약 이상이 감지되면 이전 안정 버전으로 롤백한다. 컨테이너의 수가 많을수록 이상 감지와, 롤맥은 큰 이슈가 되기 때문에 DevOps 팀 관점에서 보면 가장 중요한 기능이라고 할 수 있다.

트래픽에 따라서 특정 서비스의 Containe 수를 쉽게 늘리고 줄이는 기능을 말한다. 이 때 서버의 utilization도 고려해서 놀고 있는 서버가 없게, 비슷하게 리소스를 할당한다. 이렇게 컨테이너를 추가하면 컴포넌트 간에 통신이 필요할 때, 서버1의 B에 액세스해야 하는지, 서버2의 B에 액세스해야 하는지를 처리하는 기능이 필요하다. 그 기능은 다음에 소개할 네트워크 기능에서 처리한다.

서비스가 다수의 컨테이너로 나눠지면서 이들을 대표하는 Load Balancer를 만들어주어야 한다. 서비스들 간에 서로를 쉽게 찾을 수 있어야 한다. (서비스 디스커버리)

다양한 인사이트를 제공하여 운영을 돕닌 기능을 말한다. 다음과 같은 예를 들 수 있다.

이러한 Container Orchestration 툴들은 여러개가 존재한다. 그 중 가장 유명한 툴은 K8s 또는 Kubernetes라고 부르는 툴이다. 워낙 지배적인 점유율을 갖고있기 때문에 현재 Container Orchestration 기술은 K8s를 중심으로 정리가 되고 있고 모든 클라우드 업체들은 K8s 관련 서비스들을 내놓고 있다. (EKS, AKS, GKE)

Kubernetes는 컨테이너 기반 서비스 배포/스케일/관리 자동화를 해주는 오픈소스 프레임워크이다. 어느 컨테이너이던 가능하지만 주로 Docker Container들이 대상이 되고, 클라우드나 On-premis 환경 모두에서 잘 동작한다.
Kubernetes는 다음과 같은 특징이 있다.

Kubernetes는 기본적으로 다수의 서버(노드)로 이루어져 있다. 이 서버들은 물리서버나 가상서버로 구성할 수 있다. 이런 1개 이상의 노드들의 집합을 클러스터라고 한다.
Master는 클러스터를 관리하는 역할을 수행하는 장치로, Master가 없으면 클러스터가 동작하지 않기 때문에 보통 백업을 같이 만들어서 High Availability를 구현한다. High Availability란 어떤 서비스를 두개 이상의 서버로 구성하여 한 서버가 다운되도 계속해서 서비스가 운영되게 하는 것을 말한다. 사용자는 이 Master를 이용해서 Kubernetes의 다양한 기능들을 사용할 수 있다.
Master 안에는 다음과 같은 여러 프로세스들이 동작하고 있다.

Pod란 네트워크 주소를 갖는 self-contained server로, K8s 사용자가 사용하는 가장 작은 빌딩 블록이라 생각하면 된다. Kubernetes를 사용할 때 컨테이너를 바로 다루지는 않고, 이 Pod를 이용해서 컨테이너를 조작할 수 있다.
보통은 1개의 Pod는 1개의 Container로 구성되지만, 하나보다 많은 경우에는 보통 helper container가 같이 사용된다. 같은 Pod 내에서는 디스크와 네트워크가 공유되고, Fail-over를 위해 replicas를 지정하는 것이 일반적이다. 이 말고도 다양한 방법으로 복제본을 유지하는 것이 중요하다.
yml파일에서 Pod를 지정하는 예제는 다음과 같다.

Pod를 CLI(kubectl) 환경에서 생성하는 명령어는 다음과 같다.
kubectl create -f pod-definition.yml : yml파일의 내용을 바탕으로 Pod 생성kubectl get pods : 돌고 있는 모든 Pod 출력kubectl describe pod nginx : nginx라는 pod의 정보 출력kubectl run nginx --image nginx : 특정 이미지를 바탕으로 컨테이너를 실행하고 pod로 둘러 쌓음 (pod 이름: nginx)