Kubernetes 기본 개념

Kubernetes

컨테이너화 된 애플리케이션을 자동으로 배포 , 스케일링 및 관리해주는 오픈소스 시스템이며 구글에서 설계되었고 애플리케이션을 구성하는 컨테이너들의 쉬운 관리를 위해 논리적인 단위로 그룹화한다. Kubernetes 어원은 그리스어로 조타수, 키잡이라는 뜻이며 Kubernetes에서 ubernete가 8글자이므로 k8s라고 표현하기도 한다.

출시 배경

• 마이크로 서비스 아키텍처 발전 마이크로 서비스 아키텍처가 단순 개념에서부터 점점 발전하기 시작하였고 디자인 패턴과 이를 구현하기 위한 다양한 인프라 플랫폼들이 소개되기 시작했다. 또한 서비스가 점점 작아지면서 1~2 Core로도 운영할 수 있는 작은 서비스들이 등장하게 되었고 이런 작은 서비스는 VM 환경으로 운영하기에는 낭비가 심하다
• 설루션의 발전
• 데브옵스 모델의 성숙화 데브옵스 모델도 나온지는 오래되었지만, 운영을 데브옵스라는 이름으로 바꾼 것일 뿐 실제적인 변화가 없는 팀들이 많았고, 또는 데브옵스라는 이름 아래에서 개발팀이 개발과/운영 역할을 병행해서 하는 사례가 오히려 많았다. 이런 데브옵스의 개념도 근래에 들어서 정리가 되어가고 있는데, 개발팀이 개발과 시스템에 대한 배포/운영을 담당한다면, 데브옵스팀은 개발팀이 이를 쉽게 할 수 있는 아랫단의 플랫폼과 자동화를 하는데 목표를 두는 역할로 역할이 명확해지고 있다.

사용하는 이유

• 벤더나 플랫폼에 종속되지 않기 때문에, 대부분의 퍼블릭 클라우드 (구글, 아마존, 애저)등에 사용이 가능하고 오픈 스택과 같은 프라이빗 클라우드 구축 환경이나 또는 베어 메탈 (가상화 환경을 사용하지 않는 일반 서버 하드웨어)에도 배포가 가능
• Docker 이외에도 rkt나 Hyper container 다양한 컨테이너 엔진들을 지원
• 하드웨어 자원을 컨테이너화 하여 isolation(격리) 하는 기능이 가능
• 스토리지 자원의 활용 용이성
• 노드 확장 등을 유연하게 지원
• 자원을 최대한 최적으로 사용하기 위해 적절한 위치에 배포가 가능

기본 오브젝트

• Cluster 클러스터를 실행하면 컨테이너화 된 애플리케이션을 배치할 수 있으며, master, node를 아우르는 개념이라고 생각하면 된다. cluster에는 최소한 3개의 node를 가지고 있어야 하고 node가 3개 이하로 운영되어도 kubernetes 시스템 자체의 문제는 발생하지 않지만 컨테이너의 롤링 업데이트 시 애플리케이션의 down time이 발생하기 때문에 최소 3개의 node를 권장한다.
• Master 클러스터 관리를 담당한다. 클러스터 노드에 컨테이너 구동을 위한 스케줄링 작업을 진행 (스케줄링이라 함은 적절한 node(물리 머신 or VM)에 배포를 의미) master가 설치되어 있는 서버에서 kubernetes관련 프로세스를 확인해 보면 다음과 같이 5개의 프로세스가 동작하는 것을 확인할 수 있다. 마스터 서버의 자동 스케줄링은 각 노드에서 사용 가능한 리소스를 고려한다.
• Node node는 VM 또는 물리적 장비들이다. 각 노드에는 kubelet이 존재하며 kubernetes master와 통신(using kubernetes API)하며 노드를 관리한다, kubelet을 agent라고도 부른다 컨테이너의 애플리케이션을 kubernetes에 배포할 때 마스터 서버에게 애플리케이션 컨테이너를 시작한다고 알린다. 각 Node는 Master의 관리를 받는다.
• Pod Deployment를 생성하면 쿠버 네티스는 당신의 애플리케이션을 호스트 장비의 pod으로 생성한다. pod에는 한개 또는 여러 개의 애플리케이션 컨테이너가 존재한다. 그리고 각 컨테이너들이 리소스를 공유할 수 있다. pod은 항상 Node위에서 동작한다. Node는 쿠버네티스 안에서 동작하는 머신이다. Node는 여러 개의 pod을 가질 수 있다. 쿠버네티스 마스터는 클러스터의 노드에서 pod을 자동으로 스케줄링 처리한다.
• Volume Pod가 기동 할 때 디폴트로, 컨테이너마다 로컬 디스크를 생성해서 기동되는데, 이 로컬 디스크의 경우에는 영구적이지 못하다. 즉 컨테이너가 리스타트 되거나 새로 배포될 때 마다 로컬 디스크는 Pod 설정에 따라서 새롭게 정의되서 배포되기 때문에, 디스크에 기록된 내용이 유실된다. 데이타베이스와 같이 영구적으로 파일을 저장해야 하는 경우에는 컨테이너 리스타트에 상관 없이 파일을 영속적으로 저장해야 하는데, 이러한 형태의 스토리지를 볼륨이라고 한다. 볼륨은 컨테이너의 외장 디스크로 생각하면 된다. Pod가 기동할때 컨테이너에 마운트 해서 사용한다.
• Service Pod와 볼륨을 이용하여, 컨테이너들을 정의한 후에, Pod를 서비스로 제공할 때, 일반적인 분산 환경에서는 하나의 Pod로 서비스하는 경우는 드물고, 여러 개의 Pod를 서비스하면서, 이를 로드밸런서를 이용해서 하나의 IP와 포트로 묶어서 서비스를 제공한다.
• Name space 네임스페이스는 한 Kubernetes 클러스터 내의 논리적인 분리 단위라고 보면 된다. Pod, Service 등은 네임 스페이스 별로 생성이나 관리가 될 수 있고, 사용자의 권한 역시 이 네임 스페이스 별로 나눠서 부여할 수 있다. 간단하게 얘기하면 패키 지명 정도이다.
• Ingress 쿠버 네티스 외부에서 내부로 들어오는 트래픽을 처리하기 위한 규칙 세트이며 로드밸런싱 , SSL/TLS 인증서 처리 , 외부에서 접근 가능한 URL 등을 제공한다. Ingress 자체는 이런 규칙들을 정의해둔 자원이고 이런 규칙들을 실제로 동작하게 해주는 것이 Ingress Controller이다. 특히 가장 많이 사용되는 건 쿠버 네티스에서 제공하는 Ingress-nginx (https://github.com/kubernetes/ingress-nginx)이다.

컨트롤러

앞에서 소개한 4개의 기본 오브젝트로, 애플리케이션을 설정하고 배포하는 것이 가능한데 이를 조금 더 편리하게 관리하기 위해서 Kubernetes는 컨트롤러라는 개념을 사용한다. 컨트롤러는 Replication Controller (aka RC), Replication Set, DaemonSet, Job, StatefulSet, Deployment가 있다.

• Replication Controller Replication Controller는 Pod를 관리해주는 역할을 하는데, 지정된 숫자로 Pod를 기동 시키고, 관리하는 역할을 한다. Replication Controller (이하 RC)는 크게 3가지 파트로 구성되는데, Replica의 수, Pod Selector, Pod Template 3가지로 구성된다.
• Deployment Deployment (이하 디플로이먼트) Replication controller와 Replica Set의 좀 더 상위 추상화 개념이다. 실제 운영에서는 ReplicaSet이나 Replication Controller를 바로 사용하는 것보다, 좀 더 추상화된 Deployment를 사용하게 된다.