[Kubernetes] Kubernetes System: 컨테이너 관리의 자동화

1. 컨테이너 시스템이 가져온 변화

 

 

1-1. 컨테이너 시스템이 가져온 변화

 

컨테이너가 가져온 변화

 

Virtual Machine의 등장은 기존에 필요했던 하드웨어 비용을 크게 감소하는 효과를 가져왔고, 컨테이너의 등장은 언제 어디서든지 환경에 구애받지 않고 Application을 배포, 실행할 수 있는 확장성과 이식성을 크게 발전시켰습니다.

특히 VM과 달리 별도의 Guest OS가 필요하지 않아 빨라진 속도도 컨테이너 시스템의 큰 이점입니다.

 

+) 그리고 이러한 컨테이너 시스템에서는 Linux 기반의 컨테이너 이미지 사용을 위해 U2L** 이 필요합니다.

**U2L = Unix 시스템(Windows 등)을 Linux 시스템으로의 전환

 

 

1-2. public + private 하이브리드 시스템 구축의 필요성

 

Public Cloud : 사용자가 타고 들어오는 public 단 → 이론상 autoscailing으로 무한정 증가 가능!

(그러나 autoscailing이 늘어나면 비용 부담이 증가하므로 대부분의 경우 limit을 설정합니다.)

— AWS의 EKS, MS의 AKS, Google의 GKS 등

 

Private Cloud : 회사 실적, 장비 처리, 매출 현황(DB, Tomcat) 등의 작업은 사용자가 볼 수 없도록 private 단에서 처리

— Openshift, accordion, cocktail, Nutanix Karbon 

 

 

---

2. Kubernetes 의 등장

기존 컨테이너의 과제를 해결하기 위해 등장한 것이 바로 Kubernetes 입니다.

Kubernetes는 시스템 속 수많은 컨테이너 플랫폼 관리의 어려움**을 자동화를 통해 해결합니다.

 

**배포, node 장애 발생 시 재배치, 부하 처리, scale in/out 등의 어려움 존재

 

📌 어느 node가 가장 자원을 적게 쓰고 있는지 감지 → 추가 시 할당 작업을 자동화해주는 "컨테이너의 단점 보완 솔루션"
📌 Kubernetes = 컨테이너 배포, 장애 대처, 자동화 및 모든 관리를 해 주는 솔루션

— 여러 컨테이너 호스트를 중앙에서 관리
— Pod 예약 사활 감시, 시작/정지
— Pod 설정
— 부하에 따른 자동 확장/축소

 

Kubernetes는 1년에 2번의 공식적 업데이트를 지원합니다.

오픈 소스인 Kubernetes만을 사용해도 되지만, 장애 처리나 유지 보수 등의 관리가 되지 않으므로 대부분의 회사에서는 글로벌 벤더의 라이센스가 있는 제품을 사용하고 있습니다.

 

Openshift	Kubernetes
CoreOS에만 설치 가능, 호환성 도구 존재	대부분의 리눅스 배포판에 설치 가능
자동 설치 및 upgrade	명령어로 upgrade
제품 지원(Grafana, jenkins, prometheus 등)	별도 설치 필요
배포 편의성 - DeploymentConfig
CI/CD 편의성 - build, 배포 자동화
대시보드 지원	주로 CLI 명령, 대시보드로는 제한적 기능
보안 강화	인증 및 권한 부여 설정 기본 생성 X
Route 제공	Ingress 제공

 

---

3. Kubernetes 사용하기

 

3.1 pod의 개념과 kubernetes 실습 환경

 

우선 kubernetes에서 컨테이너가 상호 통신할 수 있는 최소 단위를 "Pod" 라고 합니다.

(컨테이너 자체에는 IP를 할당할 수 없으므로, Pod를 씌워 통신)

 

" Pod = 컨테이너를 표현하는 k8s API의 최소 단위 "

 

이 때 다른 노드의 pod 간 통신을 하려면 CNI(Cloud Network Inerface)가 필요합니다.

CNI는 컨테이너 간 통신을 지원하는 Pod Network로 Weavenet, Calico, Flannel 등 다양한 종류가 있습니다.

 

 

지금부터는 생성한 컨테이너를 'Pod'라고 부르겠습니다. (pod는 node 하나 당 기본적으로 110개 생성이 가능합니다!)

 

kubectl describe node k8s-worker1 로 확인한 pods

 

 

 

간단한 Kubernetes 실습을 통해 기존 컨테이너 시스템과의 차이를 살펴보겠습니다.

 

우선 가상머신을 통해 ubuntu 서버를 세 개 만들었고, master에는 kubernetes를 설치해 다음과 같이 cluster를 구성했습니다.

(CNI : Weavenet 사용)

 

구성된 cluster

 

master와 연결된 console에서 실습을 진행하며, 생성된 Pod를 관찰하기 위해 [XShell 접속 - 세션 복제]로 창을 분할했습니다.

 

마우스 우클릭 - 세션 복제 후 수평 분할 선택

상 - watch kubectl로 생성 및 실행되는 Pod 관찰 / 하 - 실제 kubectl 명령으로 Pod 작업

 

console1 — watch kubectl get pods -o wide

console2 — kubectl create deployment nginx-web --image=nginx --replicas=5

 

기본적으로 kubectl의 명령어는 앞서 컨테이너 실습을 진행한 docker 명령어와 매우 유사합니다.

docker와 마찬가지로 create, start, run 으로 이미지를 가지고 컨테이너를 생성/실행할 수 있는데, 가장 큰 차이는 deploy를 이용해 한 번에 여러 개의 컨테이너를 생성하고 관리할 수 있다는 것입니다.

 

 

 

3-2. Deployment (배포)

 

kubernetes는 deployments를 통해 한 번에 여러 pod를 생성, 삭제, 배포 등의 제어가 가능합니다.

 

단순 run과 deployment의 차이

 

webserver7은 run으로 단일 pod를 만들어 실행한 것이고, nginx-web은 deployment를 이용해 생성한 것입니다.

 

 

deployments - replicaset - pod 의 관계는 조부모 - 부모 - 나 의 관계로 비유할 수 있습니다.deployment로 생성된 pod와 replicaset은 deployment 라는 부모가 살아있으므로 완전 삭제가 불가능합니다. (계속 재생성)

 

컨테이너 삭제 시 --replicas로 생성된 이미지는 delete pod로 아무리 삭제해도 조건을 충족할 때까지 재생성됩니다.

다시 말해 kubectl delete pods nginx-web-7fc79595fb-zpp84 로 하나의 pod를 지우더라도, 처음 설정한 replicas 개수 (--replicas=5) 를 충족하도록 자동으로 새로운 하나를 다시 생성하는 것입니다.

 

따라서 replicaset들을 완전히 지우고 싶다면, kubectl delete deployments.apps nginx-web 으로 조부모 격인 nginx-web을 완전 삭제해야 합니다.

 

 

 

3-3. masternode 제어

이렇게 run이나 deploy로 생성한 pod들은 별도의 작업이 필요 없으며 자동으로 worker1과 worker2에 할당됩니다. 

masternode는 각 node의 리소스를 고려하여 한 쪽으로 부하가 집중되지 않도록(pod가 몰리지 않도록) 합니다. 

 

이 때 worknode는 오로지 컨테이너를 담아 실행하는 역할만 할 뿐, 모든 제어는 masternode에서 수행하게 됩니다.

 

 

3-4. scale out

kubernetes는 replicas 옵션으로 자동 확장 및 축소 기능을 지원합니다.

 

자동으로 scale out한 pod 8개를 worker1과 worker2에 나누어 할당

 

kubectl scale deployment nginx-web --replicas=8 nginx-web deployment를 8개로 scale-out 했습니다.

이 때 자동으로 각 pod들은 worker node에 고르게 분배됩니다.

 

이처럼 kubenetes에서는 master가 worker node들의 리소스 사용 및 상태를 계속해서 모니터링하며 작업의 자동화를 지원합니다.

 

 

3-5. yaml 파일 관리

 

ansible의 playbook과 마찬가지로 대부분의 kubernetes 작업은 yaml 파일로 관리합니다.

 

app-deploy.yaml

 

kubectl get pods webserver -o yaml
# webserver pod에 대한 yaml 파일 보기
kubectl get pods webserver -o yaml > webserver.yaml
# vi 편집기로 수정할 수 있도록 yaml 파일 뜨기
kubectl apply -f webserver.yaml
# 생성 및 수정한 yaml 파일 적용 (Pod 생성)

 

console 명령어로 pod를 관리할 경우, history 등이 남지 않기 때문에 yaml 파일을 떠서 pod 설정과 작업을 관리하는 것이 좋습니다. (언제, 어디서 누가 어떤 작업을 했는지 history 기록!)