Index

Docker

Container Orchestration

Provisioning

쿠버네티스란

Kubernetes(k8s)는 컨테이너화된 애플리케이션을 자동으로 배포, 스케일링 및 관리해주는 오픈소스 시스템입니다.
Kubernetes란 명칭은 키잡이(helmsman)이나 파일럿을 뜻하는 그리스어로 구글에서 개발한 2014년 오픈소스화 된 프로젝트입니다.

k8s는 다른 Container Orchestration들 보다는 늦게 등장했지만 현재 사실상의 Container Orchestration의 표준이 되었습니다.
그 이유는 CNCF(Cloud Native Computing Foundation:클라우드 네이티브 컴퓨팅재단)을 결성했기 때문이라고 말합니다.

대규모 컨테이너를 관리했던 구글 (Google은 내부 플랫폼인 Borg를 통해 일주일에 20억 개 이상의 컨테이너 배포를 생성하고 있습니다.)의 노하우와 CNCF에 AWS, Oracle, MS, RedHat, IBM 등 수많은 기업의의 참여로 k8s를 Container Orchestration의 표준이 될 수 있었습니다.

개념 이해

쿠버네티스에서 사용하는 개념은 크게 객체(Object)와 그걸 관리하는 컨트롤러(Controller)가 있습니다. 객체는 사용자가 쿠버네티스에 바라는 상태(desired state)를 의미하고 컨트롤러는 객체가 원래 설정된 상태를 잘 유지할수있게 관리하는 역할을 합니다.

k8s의 공식문서는 한글도 지원이 됩니다. 자세한 내용은 공식문서를 참고해주세요
공식문서를 읽다보면 개념을 잡기는 쉽지 않습니다. (낯선 용어와 환경….) 저희는 가벼운 수준으로 살펴보기로 하겠습니다.

1. 클러스터 아키텍처

1.1 Master / Node

클러스터는 크게 Master 와 Node로 구성이 됩니다.
클러스터 전체를 관리하는 Master가 존재하고, Container가 배포되는 Node가 존재합니다.

Master : 클러스터 관리를 담당합니다. 마스터는 애플리케이션을 스케줄링하거나, 애플리케이션의 항상성을 유지하거나, 애플리케이션을 스케일링하고, 새로운 변경사항을 순서대로 반영하는 일과 같은 클러스터 내 모든 활동을 조율합니다.
Node : 쿠버네티스 클러스터 내 워커 머신으로써 동작하는 VM 또는 물리적인 컴퓨터입니다. 각 노드들은 Pod를 동작시키기 위해 필요한 서비스를 포함하여 마스터 컴포넌트에 의해 관리됩니다.

2. Object

쿠버네티스는 상태를 관리하기 위한 대상을 오브젝트로 정의합니다. 기본으로 수십 가지 오브젝트를 제공하고 새로운 오브젝트를 추가하기가 매우 쉽기 때문에 확장성이 좋습니다. 여러 오브젝트 중 주요 오브젝트는 다음과 같습니다.

2.1 Pod

Pod 는 쿠버네티스에서 생성되고 관리될 수 있는 배포 가능한 최소 컴퓨팅 단위입니다.

한개 이상의 컨테이너를 가질 수 있습니다. 하지만 대부분 1~2개의 컨테이너를 갖게 됩니다. 이유는 배포의 최소 단위이기 때문에 Pod내부에 다수의 컨테이너들이 묶여있으면 scale-out이 쉽지 않거나 비효율적으로 이뤄지는 문제가 있습니다.
Pod 내부의 Container들은 Ip/Port와 볼륨등을 공유하고 서로 localhost로 통신이 가능합니다.
Pod에서 사용하는 Ip / Port는 서비스에서 사용되지 않습니다 (External 접근이 되지 않음) Pod는 Service를 통해 접근이 가능하기 때문인데 Service를 Pod에 연결했을때 외부 접근이 가능합니다.
Pod는 언젠가는 반드시 죽는(mortal) 오브젝트입니다. 수명이 있다는 의미로 Pod는 생성되고, 소멸된 후 부활하지 않습니다.

Pod는 총 5개의 상태값을 가집니다.

값	의미
Pending	Pod가 쿠버네티스 시스템에 의해서 승인되었지만, Pod를 위한 하나 또는 하나 이상의 컨테이너 이미지 생성이 아직 완료되지 않았다. 여기에는 스케줄되기 이전까지의 시간 뿐만 아니라 오래 걸릴 수 있는 네트워크를 통한 이미지 다운로드 시간도 포함된다.
Running	Pod가 한 노드에 결합되었고, 모든 컨테이너들의 생성이 완료되었다. 적어도 하나의 컨테이너가 동작 중이거나, 시작 또는 재시작 중에 있다.
Succeeded	Pod에 있는 모든 컨테이너들이 성공으로 종료되었고, 재시작되지 않을 것이다.
Failed	Pod에 있는 모든 컨테이너들이 종료되었고, 적어도 하나 이상의 컨테이너가 실패로 종료되었다. 즉, 해당 컨테이너는 non-zero 상태로 빠져나왔거나(exited) 시스템에 의해서 종료(terminated)되었다
Unknown	어떤 이유에 의해서 Pod의 상태를 얻을 수 없다. 일반적으로 Pod 호스트와의 통신 오류에 의해서 발생한다.

2.2 Sevice

pod에서 실행 중인 프로세스를 위한 신원(identity)을 제공합니다. 쿠버네티스에서 서비스는 pod의 논리적 집합과 그것들에 접근할 수 있는 정책을 정의하는 추상적 개념입니다.

Pod를 외부 네트워크와 연결해주고 여러 개의 Pod을 바라보는 내부 로드 밸런서를 생성할 때 사용합니다. 내부 DNS에 서비스 이름을 도메인으로 등록하기 때문에 서비스 디스커버리 역할도 합니다.

서비스를 정의할때, 어떤 Pod를 서비스로 묶을 것인지를 정의하는데, 이를 라벨 셀렉터라고 합니다. 각 Pod를 생성할때 메타데이타 정보 부분에 라벨을 정의할 수 있는데 서비스는 라벨 셀렉터에서 특정 라벨을 가지고 있는 Pod만 선택하여 서비스에 묶게 됩니다.

Pod의 경우에는 동적으로 생성이 되고, 장애가 생기면 자동으로 리스타트 되면서 그 IP가 바뀌기 때문에, 로드밸런서에서 Pod의 목록을 지정할 때는 IP주소를 이용하는 것은 어렵습니다. 또한 오토 스케일링으로 인하여 Pod 가 동적으로 추가 또는 삭제되기 때문에, 이렇게 추가/삭제된 Pod 목록을 로드밸런서가 유연하게 선택해 줘야 합니다.
그래서 사용하는 것이 라벨(label) 과 라벨 셀렉터(label selector) 라는 개념입니다.

2.3 Volume

저장소와 관련된 오브젝트입니다. 호스트 디렉토리를 그대로 사용할 수도 있고 EBS 같은 스토리지를 동적으로 생성하여 사용할 수도 있습니다.
사실상 인기 있는 대부분의 저장 방식을 지원합니다.
Pod가 기동할때 디폴트로 컨테이너마다 로컬 디스크를 생성해서 기동되는데, 이 로컬 디스크의 경우에는 영구적이지 못합니다.
컨테이너가 리스타트 되거나 새로 배포될때 마다 로컬 디스크는 Pod 설정에 따라서 새롭게 정의되서 배포되기 때문에, 디스크에 기록된 내용이 유실됩니다.
데이타 베이스와 같이 영구적으로 파일을 저장해야 하는 경우에는 컨테이너 리스타트에 상관 없이 파일을 영속적으로 저장해야 하기때문에 Volume을 별도로 셋팅해야 합니다. 이부분은 Docker Volume와 비슷한 개념입니다.

2.4 NameSpace

네임스페이스는 한 쿠버네티스 클러스터내의 논리적인 분리단위입니다. Pod, Service 등은 네임스페이스 별로 생성이나 관리가 될 수 있고, 사용자의 권한 역시 이 네임스페이스 별로 나눠서 부여할 수 있습니다.
네임스페이스는 복수의 팀이나, 프로젝트에 걸쳐서 많은 사용자가 있는 환경에서 사용하도록 만들어졌습니다. 사용자가 거의 없거나, 수 십명 정도가 되는 경우에는, 네임스페이스를 고려할 필요가 없습니다.

참고

https://kubernetes.io/ko/docs/concepts/overview/
https://subicura.com/2019/05/19/kubernetes-basic-1.html
https://bcho.tistory.com/1256?category=731548
https://arisu1000.tistory.com/

Container Orchestration - 2. kubernetes(1)