[Google Cloud Platform 기초] Kubernetes와 GKE 소개

1. Kubernetes

Kubernetes는 컨테이너를 위한 open-source orchestrator입니다. API를 제공하여 권한을 주고, 몇 가지 utility를 통해 운영을 제어합니다. 이 중 하나가 kubectl command입니다. Kubernetes는 컨테이너를 cluster라는 node의 세트에 배치합니다. 클러스터는 전체 시스템을 컨트롤하는 master component이며, 컨테이너를 운영하는 node입니다. Kubernetes에서는 node는 computing instance를 대신합니다. GCP Cloud에서 node는 Compute Engine에서 실행되는 가상 머신입니다.

 

Kubernetes를 사용하기 위해선, application set와 어떻게 서로 상호교환하는지 설명할 수 있습니다. 그리고 어떻게 가능하게 하는지 알아낼 수 있습니다.

 

2. Kubernetes cluster

Goolge Cloud는 Kubernetes를 클라우드에서 서비스로 관리하는 Kubernetes Engine을 제공합니다. Cloud SDK가 제공하는 GCP console이나 g-cloud command를 이용해 Kubernetes Engine에서 cluster를 생성할 수 있습니다.

 

3. GKE cluster

GKE cluster는 커스터마이징할 수 있고, 다른 타입의 머신과 수많은 노드 그리고 네트워크 세팅을 지원합니다. 아래는 GKE로 Kubernetes cluster를 구축하는 명령어입니다. 이름이 k1인 cluster가 생성됩니다. 클러스터의 상태를 GCP console에서 확인할 수 있습니다. 

> gcloud container clusters create k1

 

4. Pod

Kubernetes가 컨데이너나 컨테이너 관련 set를 배치할 때, 내부도 추상화가 되어 pod라고 불립니다. Pod는 Kubernetes에서 배치가 가능한 가장 작은 단위입니다. Cluster에서 pod가 프로세스를 실행한다고 생각하면, application에서 하나의 요소나 전체가 될 수 있습니다.

 

Pod 당 컨테이너가 하나가 있는 것이 일반적입니다. 하지만 다수의 컨테이너가 높은 의존성을 갖고 있다면, 하나의 pod에 넣을 수 있습니다. 그러면 자동적으로 네트워크를 공유하고, 공동의 disk storage volume을 가질 수 있습니다. Kubernetes에 있는 각각의 pod는 컨테이너를 위한 unique IP 주소와 port를 갖습니다. 하나의 pod 안에 있는 컨테이너들이 localhost network interface를 사용해 소통할 수 있어 어느 노드가 배치되는지 모르기 때문입니다.

 

Kubernetes에 있는 pod의 컨테이너를 실행하는 하나의 방법은, kubectl run command를 사용하는 것입니다. kubectl run command를 사용하면, pod를 실행하는 컨터이너로 배치를 시작합니다. 예를 들어, pod에서 실행 중인 컨테이너가 nginx open source web server의 이미지라면, kubectl command는 container registry로부터 해당 버전의 nginx 이미지를 가져옵니다.

 

5. Deployment

Deployment는 동일한 pod의 replicas 그룹을 나타냅니다. Deployment는 심지어 몇몇 node가 실행에 실패해도, pod가 실행되도록 유지합니다. 또한, application의 요소나 application 전체를 포함할 수 있습니다. 실행되는 pod를 보기 위해선, 아래의 명령어를 실행하면 됩니다.

> kubectl get pods

 

기본적으로, pod가 deployment에 위치하거나 cluster 내부에 접근만 가능합니다. Deployment 안에 pod를 공개적으로 사용하도록 만들기 위해선, kubectl expose command로 load balancer를 연결할 수 있습니다. 그러면 Kubernetes는 pod에 고정된 IP 주소 서비스를 생성합니다. 구체적으로, cluster 외부에서 접근할 수 있도록 Kubernetes에 public IP 주소를 갖는 external load balancer를 서비스에 붙이도록 요청합니다. 고객이 고정 IP 주소를 입력하면 서비스 뒤에서 pod로 라우팅될 것입니다. GKE에서 이러한 load balancer는 network load balancer로 생성됩니다. Compute Engine이 가상 머신을 이용 가능하게 하는 서비스 중에 하나로, GKE가 컨테이너로 이를 쉽게 만들어 줍니다. 

 

Deployment를 확장하기 위해서, kubectl scale command를 입력하면 됩니다. 또한, 유용한 파라미터로 auto scaling을 사용할 수 있습니다. 아래의 명령어를 입력하면, cpu 사용량이 용량의 80%일 때 최소 10개, 최대 15개의 pod를 확장할 수 있습니다.

> kubectl autoscale nginx --min=10 --max=15 --cpu=80

 

Application 버전을 업데이트 할 때, 재구축하고 재배치하면서 user들이 정지 상태를 경험하지 않게 하기 위해 deployment에는 update strategy가 있습니다. 업데이트 시에는 Kubernetes가 새 버전의 pod를 하나씩 생성시키고 오래된 버전의 pod가 파괴되기 전에 이용 가능한 상태가 되도록 기다립니다.

 

6. Service

여기서 서비스는, pod set를 그룹으로 만들고 stable endpoint를 제공하는 것을 말합니다. 그렇다면, 왜 pod의 IP 주소를 직접적으로 사용하지 않고 서비스가 필요한 것일까요? 바로 front end와 back end로 구성되어 있기 때문입니다. Front end는 서비스를 요구하지 않고 pod의 내부 IP 주소를 이용해 backend에 접근할 수 있습니다. 하지만 관리 문제가 있습니다.

 

Deployment는 pod를 생성하거나 파괴하면서 pod는 IP 주소를 얻습니다. 하지만, 이런 주소는 장기간동안 안정적이지 않습니다. 서비스는 stable endpoint를 제공합니다. 아래 명령어는 서비스의 pulbic IP 주소를 보여줍니다.

> kubectl get services

 

7. Configuration file

Configuration file은 관리 툴과 같습니다. Issuing 명령어를 사용하는 대신에, configuration file을 제공하여 Kubernetes에게 보여지기 원하는 상태가 무엇인지 말하고 어떻게 해결할 것인지 알아냅니다. 변경을 하려면, 파일을 수정하고 변경된 버전을 Kuberenetes에게 건네면 됩니다. 아래 명령어는 이미 작업한 것을 기반으로 file의 starting point를 얻을 수 있는 한가지 방법입니다.

> kubectl get pods -l "app=nginx" -o yaml

 

이런 파일은 길고 우리고 이해야지 못하는 문구가 포함되어 있습니다. 하지만 익숙해진다면, 작업하기에 용이합니다. 그리고 인프라의 변경을 추적하는 version control system에 저장할 수 있습니다. 이는 특정 pod 모두가 label을 공유하기 때문입니다.