[CloudONE(1). Kubernetes 101]

Jiyoon·2021년 4월 5일

Career

목록 보기

2/3

DevOps 파트로 인턴을 시작하게 되어 DevOps에 대한 공부와 함께, 컨테이너 기술 / Docker와 Kubernetes에 대한 내용을 담은 Kubernetes 101 세미나 준비로 첫 업무를 시작하게 되었다.

DevOps와 Container 기술, Kubernetes
Kubernetes Objects (Pod, Service, Persistant Volume, Deployment ,Configmap)

순서로 Kubernetes 101 을 준비했다.

1. DevOps와 Container 기술 그리고 Kubernetes

DevOps

MZC CloudONE 팀에 들어오기 전까지, DevOps라는 말을 듣기만 하고, 정확히 어떤 일을 하는지 알수가 없었다. DevOps는 기존의 waterfall 방식으로 일하던 IT팀들이, 최근 고객의 다양화된 needs를 받아들이게 되면서 Agile 하게 일하기 시작했고, 특히 운영과 배포를 빠르게 하기 위해 등장한 철학 및 개념이다.

과거에는 개발 팀에서 애플리케이션을 만든 후에 운영 팀에 넘겨주면 애플리케이션을 배포하고, 관리하고, 계속 실행했지만 지금은 애플리케이션을 개발하는 사람이 배포에도 참여하고, 관리, 실행하는 것이 DevOps다.

개발자, 품질 보증, 운영 팀이 전체 프로세스를 모두 함께 작업하는 작업방식을 지칭하기도 한다.

DevOps를 실현 가능하게 해주는 Orchestration management system이 Kubernetes이다. Application을 배포하고 실행하는 단일 플랫폼으로써 실제 하드웨어를 추상화하고 노출하므로 개발자가 직접 시스템 관리자의 도움 없이도 애플리케이션을 구성하고 배포할 수 있다.

그리고, 시스템 관리자는 실제로 하드웨어에서 실행되고 있는 Application에 대해 모르더라도 기본 인프라를 유지하고 가동하는데 집중할 수 있다.

Container 기술 소개

Kubernetes는 리눅스 컨테이너 기술을 사용해 실행 중인 애플리케이션을 분리하도록 만들어주는 , 그래서 컨테이너 어플리케이션을 쉽게 배포하고 관리할 수 있게 해주는 소프트웨어 시스템이다.

VM에서의 문제점

Application이 각각 커다란 구성요소, 작은 수로 구성되면, 각각 구성요소에 Virtual Machine을 부여한다. One app - One VM 으로 매치하면, 수가 늘어날 수록 하드웨어 Resource를 낭비하게 될 수 있다. 그렇다고 하드웨어 비용을 줄이기 위해 여러 Application이 VM을 공유하게 되면, 각자 고유의 가상머신 제공이 어려워지게 된다.

Virtual Machine과의 비교

1) 하이퍼바이저 없음
2) 커널이 하나임

Container 를 통해 동일한 하드웨어에서 더 많은 소프트웨어 구성 요소를 실행할 수 있게 된다.

ex) 가상머신 3개 ⇒ 완전히 분리된 3개의 운영체제 실행 (Hypervisor: 물리적 하드웨어 리소스를 내부의 운영체제에서 사용할 수 있는 리소스로 나눠줌 +호스트 os)

반면 컨테이너는 모두 동일한 OS에서 실행되는, 동일한 커널에서 시스템을 호출한다.

컨테이너 격리를 가능하게 해주는 매커니즘

1) Linux namespace

각 프로세스가 파일, 프로세스, ni, host name 등 독립 뷰를 제공함.

2) cgroups

프로세스가 소비할 수 있는 리소스의 양(cpu, memory.. ) 등을 제한함

Docker

Container 기술을 사용해 애플리케이션을 구축, 패키징, 배포, 실행하게 해주는 software platform

Docker에 필요한 3가지 개념은 다음과 같다.

Image : 필요한 프로그램, 파일 시스템, 소스 설치한 뒤 만든 하나의 파일
Registry : 도커 이미지를 저장하고, 사람들 간에/컴퓨터 간에 이미지를 공유할 수 있게 만든 시스템
Container : 도커 기반 컨테이너 이미지에서 생성된 일반적인 형태의 리눅스 컨테이너

Docker Container Platform (vm에서 가상 머신 이미지 만드는 것과 유사)

컨테이너를 여러 컴퓨터에 쉽게 이식 가능하게 하는 최초의 컨테이너 시스템

도커가 운영 중인 다른 머신에 어플리케이션이 프로비저닝할 수 있도록 동일한 수준의 격리를 하게 하지만, 컨테이너 이미지를 사용한다.

간단한 실습

docker run 명령어로 echo "Hello world" 를 busybox 도커이미지 위에서 실행하는 docker 실행시켜보았다.

Kubernetes

Container System 상에서 Application을 쉽게 배포하고 관리할 수 있게 해주는 orchestration management 시스템.

배포의 과정은 다음과 같다.

개발자 → Application manifest를 마스터에 제출 → 워커 노드 클러스터에 배포

Kubernetes에서 Application 실행하기

1) 하나 이상의 컨테이너 이미지들을 패키지로 만들어

2) 이미지 레지스트리에 푸시한 후,

3) 쿠버네티스 API서버에 어플리케이션의 description을 게시한다.

Description이 컨테이너의 실행을 가져오는 방법

스케줄러가 API 서버가 애플리케이션 description을 처리할 때, 각 그룹에서 필요한 연산 resource, 각 노드에 할당되지 않은 리소스를 기반으로 사용 가능한 worker node 및 컨테이너 지정 그룹을 예약한다.

Kubernetes의 장점

애플리케이션 배포 단순화

모든 워커 노드를 단일 배포 플랫폼으로 제공하므로 애플리케이션 개발자가 직접 애플리케이션을 배포할 수 있다, 클러스터를 구성하는 서버에 대해 알 필요가 없다.
하드웨어 활용도 높이기

사용 가능한 리소스에 따라 실행하기 가장 적합할 노드를 선택하기 때문에 클러스터의 주변을 자유롭게 이동할 수 있다.

상태 확인 및 자가 치유

어플리케이션 구성 요소와 실행되는 노드를 모니터링하고, 노드 장애 발생 시 다른 노드로 일정을 자동으로 재조정 가능~
Auto scaling

배포된 애플리케이션 개별 부하를 지속적으로 모니터링할 필요가 없다.

Docker와의 차이점?

Docker는 image를 컨테이너로 띄우고 실행하는 기술적인 개념 + 도구고, Kubernetes는 Docker 를 관리하는 Tool이다.

Kubernetes State

Desired State vs Current State

사용자가 쿠버네티스에 바라는 상태 와 객체의 현재 상태를 의미한다. 쿠버네티스는 끊임없이 객체의 current state를 감시해 desired state를 달성하고자 한다.

Kubernetes 초기 세팅하기

kubectl CLI 클라이언트 설치하기

Kubectl은 kubernetes command line 도구로, Kubernetes 클러스터에 대해 명령을 실행한다. Kubectl로 리소스, 로그, application 배포.. 모두 가능하다.

회사에서 받은 랩탑이 mac OS 여서, curl 명령어로 kubectl을 설치했다.

K9S 설치하기

kubectl 라는 kubernetes command line 조차도 너무 자주치다보면 귀찮기 때문에, 또 커서키로 이동하면서 K8S의 리소스를 보고, 삭제하고, manage하기 위해 사용하는 CLI tool이다.

역시 brew를 이용해 install 했다.

https://k9scli.io/topics/install/

2. Kubernetes Resources

(Pod, Service, Persistant Volume, Deployment, Configmap)

Pod

Pod Overview

K8S 환경 상에서 서비스를 배포할 때, 배포의 가장 기본이 되는 단위가 되는 object가 pod이며,

각 Pod는 동일한 worker node, 자체 ip, 호스트 이름, 프로세스 등을 보유한 별도의 논리적 시스템이다,

하나의 Pod에 속하는 컨테이너들은 모두 1개의 노드 안에 같이 실행된다.

Pod 하나에 속하는 컨테이너들이 여러 대의 노드에 흩어져서 실행되는 일은 없음. Pode의 목적이 동일한 목적을 가진 컨테이너들끼리 자원을 공유하기 위해서이기 때문.

하나의 컨테이너가 모든 역할을 하도록 구성하지 않는 이유?

한 컨테이너는 1개의 프로세스를 띄우도록 설계되어 있음
시스템 시그널, 종료 코드 처리 등 각 프로세스 별로 처리해줘야 하기 때문에 컨테이너 하나가 여러 역할을 하다보면 관리 효율이 떨어진다.

Pod의 구성

Pod 정의의 주요 부분은 아래 명령어를 사용해서 확인할 수 있다.

$ kubectl describe pods

Pod의 status 가 Running 인 것을 확인할 수 있다!

Label, Namespace를 이용한 포드 구성

마이크로서비스 아키텍처의 경우, 배포된 마이크로서비스가 20개를 쉽게 초과하기도 해서 시스템에 수백개의 포드가 생길 수 있다.

우리 클러스터에도 조직화 Mechanism이 필요하기 때문에 임의의 기준에 따라 작은 그룹으로 구성할 수 있고, 이 때 Label과 Namespace를 사용한다.

라벨은 리소스에 첨부하는 임의의 키/쌍 값이며, label selector를 이용해 리소스를 선택할 때 사용됨.

app : 포드가 속한 애플리케이션, 구성요소 or 마이크로서비스를 표시
rel : 포드에서 실행 중인 애플리케이션이 안정적 버전, 베타 혹은 카나리 버전인지 여부 표시

$ kubectl create -f YAML이름.yaml #생성
$ kubectl get po --show labels #조회
$ kubectl get po -l creation_method=manual #라벨 셀렉터를 이용한 포드 조회(수동으로 생성한 포드)

Service

Service Overview

동적으로 떠다니는 떠다니는 Pod들을 고정적으로 접근하기 위해 사용한다.
Pod가 클러스터 내 어디에 있던지 상관 없이 고정적으로 Pod에 접근할 수 있다.
서비스를 사용하게 되면 Pod가 클러스터 내의 어디에 있는지에 상관없이 고정된 주소를 이용해서 접근이 가능해지고, 외부에서 Pod에 접근하는 것도 서비스를 통해 가능해진다. (식별 주소 느낌)

사용 예시) Frontend 용 Pod / Backend 용 Pod 나뉘어져 있는 경우, Frontend pod에서 고정적으로 요청을 보낼 backend ip가 필요한 경우

Service의 특징에 따른 Service의 종류

Service의 특징과 Use case에 따라서 Service를 5가지 정도로 분류해보았다.

외부 클라이언트에서 서비스를 연결하는 경우

외부 클라이언트에서 Service를 연결해 자원에 접근하는 경우 NodePort, LoadBalancer, Ingress를 위에 언급된 목적에 맞게 이용해 Cluster 내의 자원에 static한 ip를 할당한다.
내부 서비스 내 연결하는 경우

클러스터 내부의 Node, Pod에서 서비스에 연결된 Pod로 연결하고 싶을 때는 ClusterIP를 사용한다.

Default이다.
외부 서비스에 연결하는 경우

클러스터 외부의 Service에 연결하고 싶은 경우 ExternalName을 사용한다. 이 때, Service이름을 externalname 값과 매치시킨다.. 는데 실제로 사용해보지는 않아 잘 모르겠다.

Persistant Volume

Persistant Volume(PV) Overview

Container는 기본적으로 stateless이다(container가 죽었을 때 현재까지의 데이터가 사라짐). 상태가 없기 때문에 Container에 문제가 있거나 Node에 장애가 발생해서 Container를 새로 띄우거나 다른 곳으로 옮기는 자유로운 특성을 이용하는 것이 K8S의 큰 장점이라고 할 수 있다.

그치만, "mysql이나 jenkins처럼 컨테이너가 내려가거나 재시작했을 때 데이터가 사라지면 안되는 경우" 처럼 Stateful한 Usage를 위해 필요한 것이 Persistant Volume 이다.

PV의 특징

volume은 pod의 컴포넌트이므로, pod의 스펙에 정의된다.
Pod의 모든 Container에서 볼륨을 사용할 수 있지만, 볼륨에 access해야 하는 각 컨테이너에 볼륨을 mount 해줘야 한다.

PV and PVC

PV와 PVC는 Kubernetes에서 볼륨을 사용하는 구조이다.

PV(persistant volume) : 볼륨 자체를 의미, 클러스터 내에서 리소스로 다뤄짐.

PV의 Lifecycle

Persistant Volume의 Lifecycle에는 4가지 유형이 있다. Provisioning, Binding, Using, Reclaiming

Deployment

Deployment Overview

Deployment는 Kubernetes에서 일반적인 Application을 배포할 때 사용하는 가장 기본적인 컨트롤러이며, Deployment가 ReplicaSet을 관리하면서 Application의 배포를 보다 세밀하게 관리할 수 있도록 한다.

Deployment의 큰 특징 중 하나는, Declarative Application Update (선언적 애플리케이션 업데이트) 를 가능하게 한다는 점이다.

Declarative Application Update?

Application Container를 수동으로 업데이트하는 프로세스는 시간이 아주 많이 걸린다.

(Start new version pod → Stop old version pod → Rollback if it fails)

이런 작업을 수작업으로 진행하면 인적 오류가 발생하고, scripting 오류가 날 수 있으므로, 쿠버네티스 배포에서 이러한 프로세스를 자동화하고 반복할 수 있도록 하는 것이다.

Update 전략

Rollback

만약 new version을 활성화한 후에 오류를 전달 받기 시작하는 경우 신속하게 지난 버전으로 되돌려야 한다. 이때, 아래의 명령어를 사용해 deployment를 Rollback한다.

#마지막 롤아웃을 취소하도록 해서 이전 버전으로 롤백하는 경우
$ kubectl rollout undo deployent 이름

#특정 리비전으로 롤백하고 싶은 경우
$ kubectl rollout undo deployment 이름 --to-revision=버전넘버

ConfigMap

ConfigMap Overview

ConfigMap은 Kubernetes에서 Container에서 필요한 환경설정 옵션을 Container와 분리해서 제공 해주기 위한 기능이다. 환경변수 기능이라고 할 수 있다.

" 개발할 때 사용하는 컨테이너와 실제 서비스 용으로 사용되는 컨테이너를 동일하게 해서 개발/서비스 간에 환경 차이에서 오는 문제를 해결한다" _ 쿠버네티스의 기본 철학(?)

개발용과 서비스용에서는 서로 다른 설정이 필요한 경우가 다반사이다. 예를 들어서, 개발용에서는 debug로 log를 출력하는데 서비스용에서는 info로 log를 출력하는 것과 같은 경우이다.

이와 같이, 다른 설정을 가지고 실행을 해야할 때 Configmap을 사용한다.

ConfigMap 생성하기

ConfigMap 선언 → ConfigMap을 Kuber API에 게시하기 의 순서로 적용할 수 있다.

ConfigMap을 선언할 때는 3가지 옵션이 있다.

ConfigMap을 쿠버네티스 API에 게시하기

`kubectl apply -f configmap_name.yaml` 의 cmd로 Kubernetes API에 게시할 수 있다.

3. 마지막으로 인턴 첫 과제로 K8S 를 톺아보며 느낀점

K8S는 각자의 할 일이 명확하게 구분 되기를 바라는 것 같다. 그래서 DevOps에 유용하다는 말이 무엇인지 어렴풋이 알 것 같았다.

(어플리케이션 개발자는 어플리케이션만 서비스하도록, 운영은 운영만 집중하도록 관리)
그런 목적에 알맞게 K8S 세계의 구성도 할 일이 참 명확하게 구성되어 있어서 놀라웠다.

(PV Claim / PV mount 분리, Service Account /Service Account Binding의 분리.. 등)