[Google] Kubernetes(쿠버네티스)란?

[Google] Kubernetes(쿠버네티스)란?

작성자: Anderson Kim 12월 26, 2018

[Google] Kubernetes(쿠버네티스)

컨테이너

사전적 의미로는 어떤 물체를 격리하는 공간
클라우드에서는 애플리케이션과 애플리케이션을 구동하는 환경을 격리한 공간을 뜻함
컨테이너 기술은 약 10여년전에 리눅스에 내장된 기술로 현재 차세대 트랜드 기술로 주목받고 있음

가상머신과 컨테이너의 차이점

가상머신 서버에서는 Hypervisor로 하드웨어를 가상화하고, 그 위에 Guest OS가 설치된 가상 머신들을 구동시킴

Hypervisor : 호스트 컴퓨터 1대에서 다수의 운영체제를 동시에 실행할 수 있도록 해주는 가상 플랫폼 기술

컨테이너 서버는 운영체제 레벨에서 CPU, RAM, Disk, Network 등의 자원을 격리하여 컨테이너에 할당하기 때문에 게스트 OS가 따로 필요 없음

	가상머신(VM)	컨테이너 기술
효율성	기업환경에서는 안정적인 운영을 위해, 1개의 가상머신에 1개의 서비스를 구동하는 것을 권장 이의 경우 성능적 오버헤드가 발생	OS 커널을 공유하기 때문에 자원을 필요한 만큼 효율적으로 사용 가능
신속성	VM을 배포해야 할때 크기가 최소 GB단위의 크기	컨테이너를 배포할 때 Guest OS가 없어 MB단위의 크기로 빠르게 배포가능
비용	가상화 서버의 경우 가상머신 개수만큼 Guest OS의 라이센스 비용이 발생	Host OS 1대의 라이센스 비용만 발생
안정성	정확히 할당된 자원 내에서 가상머신이 운영되기 때문에, 컨테이너에 비해 안정적	OS 커널을 공유하기 때문에, 하나의 컨테이너가 무리하게 자원을 사용하게 될 수 있습니다. 자원 할당량을 사전에 지정시켜줄 수 있지만, 만약 이런 상황이 발생하면 컨테이너에 장애가 발생합니다. 이런 컨테이너의 문제는 뒤에 등장할 쿠버네티스로 해결할 수 있습니다.

쿠버네티스?

컨테이너를 사용하면 서버의 자원을 효율적으로 사용할 수 있음

if) 컨테이너가 너무 많아져서 관리와 운영이 어려워지면?
if) 웹 서비스에서 애플리케이션을 연중 무휴로 사용하고 싶다면?
if) 개발자들이 새로운 버전의 애플리케이션을 하루에 몇번씩 배포하길 원한다면?
-> 쿠버네티스로 해결

컨테이너화는 downtime없이 쉽고 빠르게 업데이트되고 배포되는것을 가능하도록 도와준다.
쿠버네티스는 이러한 컨테이너화된 어플리케이션을 언제 어디서든 원하는곳에서 실행 가능하도록 도와준다.
쿠버네티스는 구글에서 컨테이너 배포 관리에 관한 경험으로 만들어진 Production-ready, Open Source Platform이다

쿠버네티스 기본 작동 모듈

1. 쿠버네티스 클러스터 만들기

쿠버네티스는 단일 장치로 작동하도록 연결된 고 가용성 클러스터 컴퓨터를 조정함
쿠버네티스 추상화를 사용하면 컨테이너화 된 응용 프로그램을 개별 시스템에 특수하게 묶지 않고 클러스터에 배포 할 수 있음
효율적으로 클러스터에서 응용 프로그램 컨테이너의 배포 및 예약을 자동화 함
쿠버네티스 클러스터는 2가지로 구성되어 있음

Master : cluster들을 관리

애플리케이션 스케일링, 스케쥴링, 유지 관리, 새로운 업데이트 등

Nodes : 애플리케이션을 작동시키는 workers

VM 또는 실질적 컴퓨터

Master와 Node는 쿠버네티스 API를 이용해서 커뮤니케이션 함

2. 앱 디플로이 하기

쿠버네티스 클러스터가 실행되면, 컨테이너화된 에플리케이션을 클러스터 위에 배포

Deployment는 Kubernetes에게 응용 프로그램의 인스턴스를 만들고 업데이트하는 방법을 알려줌
쿠버네티스는 파드나 애플리카셋을 직접적으로 배포하는것이 아니라 deployment가 알아서 해주는 개념

위와 같이 하기 위해서 Deployment configuration을 만들어야 함

어플리케이션 인스턴스가 생성되면, Kubernetes Deployment Controller는 인스턴스를 꾸준히 관리

만약 인스턴스를 호스팅하는 노드가 제거되면, DC는 이것을 대체함
즉, 유지 관리를 위한 Self-healing mechanism

이것을 통해서 특정 컨테이너가 오류를 발생시켜도 바로, 복제본을 만들어서 사용할 수 있음

kubectl 명령어를 사용하면 배포 및 관리 가능

kubectl 명령어는 쿠버네티스 클러스터에 대한 명령을 실행하기 위한 것
kubectl은 쿠버네티스 API를 사용함
kubectl get -> 자원(resource) 의 리스트
kubectl describe -> 자원(resource)에 대한 자세한 정보
kubectl logs -> 포드안에 있는 컨테이너에 대한 로그를 찍어줌
kubectl exec -> 포드안에 있는 컨테이너 실행

배포 할때 응용 프로그램의 컨테이너 이미지와 실행할 복제본 수를 지정

3. 앱 탐색(explore)하기

배포를 할 때 Kubernetes는 응용 프로그램 인스턴스를 호스팅 할 Pod를 만든다.
포드는 하나 이상의 응용 프로그램 컨테이너 그룹 (예 : Docker 또는 rkt) 및 해당 컨테이너에 대한 일부 공유 리소스를 나타내는 Kubernetes 추상화

포드의 특징

Volume이라고 불리는 공유된 저장소
고유한 클러스터 IP주소로 네트워킹
컨테이너 이미지의 버전이나 특정 포트와 같은 각 컨테이너 실행하는 방법 정보

포드는 응용 프로그램 별 logical host를 모델링하여 긴밀하게 결합된 여러 응용 프로그램 컨테이너를 포함 할 수 있음

ex) 포드에는 Node.js 웹 서버가 게시 할 데이터를 공급하는 다른 컨테이너뿐만 아니라 Node.js 애플리케이션이 있는 컨테이너도 포함 될 수 있음

포드는 쿠버네티스 플랫폼의 원자 단위

kubernetes에서 Deployment를 하면 해당 디플로이는 컨테이너가 있는 포드를 만듬
(직접 컨테이너를 만드는 것이 아님)
각 포드는 노드가 있는곳에 연결되고 restart정책에 따라 연결이 종료되거나 삭제됨

노드란?

포드는 항상 노드위에서 실행 됨
노드는 쿠버네티스의 작업 머신이며 클러스터에 따라 가상 or 실제 시스템일 수 있음
각 노드는 마스터가 관리함
노드는 여러 포드를 가질 수 있음
쿠버네티스 마스터는 클러스터의 노드에서 포드 스케줄링을 자동으로 처리
마스터의 자동 스케줄링은 각 노드에서 사용 가능한 리소스를 고려함
registry에서 컨테이너 이미지를 가져오고, 컨테이너의 압축을 풀고, 응용 프로그램을 실행시키는 컨테이너 런타임

컨테이너들이 강하게 결합되어 있거나 자원을 공유해야 한다면 단일 포드에 같이 배정되어야 함

kubelet

마스터와 노드 사이의 통신을 담당하는 프로세스
시스템에서 실행중인 포드 및 컨테이너를 관리

4. 공개적으로 앱 노출 시키기

쿠버네티스 포드에는 수명 주기가 있음

노드가 종료되면 노드에서 실행중인 포드도 종료가 됨

즉, 쿠버네티스 클러스터의 각 포드에는 고유한 IP 주소(동일한 노드의 포드)가 있으므로 포드간의 변경 사항을 자동으로 조정하여 응용 프로그램이 계속 작동 할 수 있어야 함
각 포드는 고유한 IP주소가 있지만 이러한 IP주소는 서비스가 없으면 클로스터 외부에 노출되지 않음

서비스 = load balancer
쿠버네티스의 서비스 : 포드의 논리적 집합과 접근 할 수 있는 정책을 정의하는 추상화

서비스는 종속 포드 간의 느슨한 결합을 가능하게 함
서비스는 모든 쿠버네티스 객체처럼 마찬가지로 YAML(추천) or JSON으로 정의

서비스를 통해 응용 프로그램이 트래픽을 수신 할 수 있음

서비스는 ServiceSpec에서 유형을 지정하여 다양한 방식으로 노출 가능

서비스는 일련의 포드에서 트래픽을 라우팅 함

ex) label이 app-node인 것에만 load balancing을 실시

서비스는 포드가 응용 프로그램에 영향을 주지 않고 Kubernetes에서 죽고 복제 할 수 있게 해주는 추상화
서비스는 종속 포드 (ex 응용 프로그램의 프런트 엔드 및 백엔드 구성요소 ) 간의 검색 및 라우팅을 처리

서비스는 쿠버네티스에서 논리적 작동이 가능하도록 label과 selectors를 매치시킨다.
label : 오브젝트에 붙여진 key/value 쌍으로 여러가지 방법으로 사용 가능

개발, 테스트 및 생성을 위한 오브젝트 지정
버전 태그 삽입
태그를 사용하여 객체 분류
생성시 또는 나중에도 객체에 레이블을 추가 가능(언제든지 수정 가능)

5. 앱 스케일 업 하기

트래픽이 증가하면 사용자의 요구를 따라 잡기 위해 애플리케이션을 확장해야 함

확장은 디플로이에서 복제본 수를 변경하여 수행

배포를 확장하면 사용 가능한 리소스가 있는 노드로 새 포드가 만들어짐
크기 조정을 수행하면 포드 수가 원하는 새 상태로 증가

0으로 스케일링하면, 지정된 배치의 모든 포드를 종료함

응용 프로그램의 여러 인스턴스를 실행하려면 모든 응용 프로그램에 트래픽을 분산 시키는 것이 필요
서비스에는 노출된 배포의 모든 포드에 네트워크 트래픽을 분산 시키는 통합 load balancer가 존재

6. 앱 업데이트 하기

개발자는 하루에 여러 번 새로운 버전을 배포 할 수 있음
Rolling updates를 사용하면 포드 인스턴스를 새 인스턴스로 점차적으로 업데이트를 수행 할 수 있음

가동 중지 시간 없이 배포의 업데이트를 수행

업데이트를하고 이전버전으로 되돌릴 수도 있음
업데이트 중에 사용할 수 없는 그리고 사용 가능하게 되는 포드의 수는 1개가 default

응용 프로그램 확장과 마찬가지로 배포가 public하게 되는 경우 서비스는 업데이트중에 사용 가능한 포드로만 트래픽을 load balancing함
롤링 업데이트

한 환경에서 다른 환경으로 응용 프로그램 수준 올리기

(컨테이너 이미지 업데이트를 통하여)

이전 버전으로 Rollback
중단 시간없이 애플리케이션을 지속적으로 통합 및 지속적으로 제공함

정리

Pod를 생성하는건 ReplicaSet
ReplicaSet을 묶어서 관리하는 건 Deployment

하나의 Deployment에 여러개의 Replication Controller를 넣어서 Pod들을 관리 가능

Service는 Label을통해서 Pod를 Load Balancer느낌

Ingress

서비스는 파드간의 Load Blanacer
시스템 관점에서는 하나의 서비스로 만들고 싶을수 있음

ex) Gmail은 하나의 API를 쓰는데 거기서 유저 서비스도 있고, 메일 박스도 있고...이런것들을 하나의 URL로 묶어줘야 함

서비스에 대한 Load Balancer를 Ingress라고 함

이것은 URL의 PATH에 따라서 routing을 함

Ingress는 2가지로 구성됨

Ingress Resource : 인바운드 트래픽이 서비스에 도달하는 규칙 모음
Ingress Controller : 일반적으로 HTTP 또는 Layer7 로드 밸런서를 통해서 Ingress Resource가 정한 규칙에 따라 작동함

SatatefulSet이란

포드 집합의 배포 및 확장을 관리하고 이러한 포드의 순서 및 고유성을 보장

Deployment와 마찬가지로 동일한 컨테이너 사양을 기반으로하는 포드를 관리
Deployment와 다르게, 각각의 Pod에 대한 sticky ID를 유지함

이러한 포드는 동일한 사양으로 만들어지지만, 상호교환을 할 수 없다.

Headless Service란?

Cluster IP등의 주소를 가지지 않는다.
단, DNS이름을 가지게 된다.

DNS이름을 보게 되면, 서비스(load balancer)의 IP를 리턴하지 않고, 이 서비스에 연결된 Pod들의 IP를 리턴하게 된다

service : 특정 포드에 접근하기 위한 정책 또는 규칙
Headless service : 로드벨런싱을 규정하지 않는 서비스

즉, 개별 DNS를 제공하여 우리의 포드에 접근 할 수 있음

출처

댓글