Kubernetes on GCPDaegeun Kim (gnkr8@outlook.com)

Lezhin Entertainment

1

1편으로 생각해주세요. 40분안에 하기에는 주제가 너무컸습니다.

발표자✑ 레진엔터테인먼트 데이터 엔지니어

✑ Links

✑ https://geekdani.wordpress.com/

✑ dgkim84 @ twitter / fb

2

데이터 엔지니어, 분석가 안드로이드, iOS 앱 개발자 백엔드, 웹 프론트엔드 개발자

충원 중 입니다.

https://github.com/lezhin/apply/blob/master/README.md

Google Cloud Platform GCP에 더 많은 제품이 있지만, 데이터팀에서 사용하고 있는 주요 제품군

3

https://cloud.google.com/icons/

우리 팀은 저 뿐인 팀이고 다 외주 직원들로 구성 얼굴 본 적은 없지만 그 분들이 제품을 만들어줍니다.

로그 수집, 가공, 적재, 모델링, 분석 등을 할 수 있도록 지원해주고 있습니다.

BigData 제품군, Compute 제품군, 로깅, 네트워크, 스토리지 등 제품군을 활용 중 입니다. BigTable 과 같은 제품들도 작지만 사용 중에 있습니다.

왜 레진코믹스 데이터팀은

GCP 를 선택했나

4

https://www.slideshare.net/curioe_/lezhincomics-google-appengine-30453946 왜 레진코믹스는 구글앱엔진을 선택했나

안정적이고 독립된 Data Infrastructure

- 2016년 4월 탈출

5

본업은 백엔드팀 이었고 업무 외에 작업이 진행된 것 이기때문에

손이 덜 가고 안정적으로 운영되도록 하는게 주 목표입니다.

그렇기때문에 오픈소스와 같은 제품을 직접 운영하는 것보다 fully managed 되고 있는 GCP 제품군을 더 살펴보게 됩니다.

Google Cloud Platform 더 많은 제품이 있지만, 데이터팀에서 사용하고 있는 주요 제품군.

6

수집 -> 가공 -> 적재 -> 모델링 -> 분석

수집 -> 가공 -> 적재 -> 모델링 -> 분석 등의 과정을 거치면서

마케팅, 빌링, 기획팀 등에서 SQL 등을 활용할 수 있도록 DWH 구축부터 BI 툴 연계를 통해 SQL을 다루지 못하는 분들도 시각화 할 수 있는 툴을 제공합니다.

이 인프라로 한달에 대략 10억건 이상의 유의미한 로그가 쌓입니다. 배치 분석을 위해 스토리지로, 실시간 분석을 위해 Pub/Sub 등으로 보내집니다.

대부분의 ETL과 추천처리는 Spark 로 이루어지며 실시간 처리는 DataFlow Streaming 쓰고 배치도 씁니다.

GCP 기능 외에 필요한 것

- 워크플로우 & 스케쥴러 - 추천(검색) 데이터 서빙용 어플리케이션 서버

- 서비스 특화된 지표용 백오피스 - 기타 수 많은 어플리케이션 서버

7

워크플로우 & 스케쥴러 : Airflow (Oozie, Azkaban, Luigi 와 같은) 제품으로 ETL 잡이나 이런 반복되는 작업을 DAG 형태로 관리하고 스케쥴링하는 역할

이와 같은 역할을 해주는 서버들이 있는데 관리를 효율적으로 하려고 할 때

고민하는 사항들이 있습니다.

Checklist✑ Deployment

✑ Provisioning

✑ Automation

✑ Stateless, Stateful

✑ Scalability

✑ Monitoring

✑ Discovering Service

8

배포, 프로비저닝, 자동화 등이 그것이고

확장성이라던지 모니터링 그리고 Discovering Service 와 같은 문제들이 있습니다.

이걸 개별로 구축하고 관리하는 비용은 어찌보면 굉장히 큽니다.

이번 발표에서는 자동화, Stateful 어플리케이션에대한 문제, 모니터링, Discovering Service에대한 상세한 내용은 시간관계상 다루지 못합니다.

Deployment - 배포할 때 고려사항

9

Deployment✑ Provisioning

✑ OS, Network, …

✑ Resource (CPU, Memory, Storage, …)

✑ Application Code

✑ Dependencies

✑ Configurations

✑ Update

✑ Rolling Update

✑ Blue-Green Deployment

✑ Rollback

10

하나씩 각개격파 해보아요.

Kubernetes Pod - 앞서 언급한 것을 해결해 주는 기본 모델

11

Pod✑ 배포 최소 단위

✑ 하나 이상의 container (docker / rkt) 포함

✑ 함께 포함시켜야 할 것이 있다면 함께 선언

✑ Resources

✑ Volumes, Port, …

✑ CPU, Memory

✑ Request, Limit

✑ livenessProbe

✑ …

✑ Unique IP address

12

rkt (rock-it) 은 experimental

함께 포함시켜야할 것이 있을 때 함께 선언합니다.

기본적으로 container 기반이기때문에 OS나 dependency 문제는 쉽게 해결이 됩니다.

여기서 가장 중요한 것은 hello world 수준의 guide에선 언급이 안되지만

resource 관리가 중요하며, Pod은 Kubernetes에서 가장 작은 개념으로 알려져있지만 가장 다루기 어렵고 중요한 대상입니다. 삽질해보시면 알게됩니다.

진짜! 그렇기때문에 Kubernetes는 학습해야할 것이 적지 않습니다.

Creating a Pod $ kubectl create -f airflow-web.yaml

1 kind: Pod 2 apiVersion: v1 3 metadata: 4 namespace: dev 5 name: airflow-web 6 labels: 7 app: airflow-web 8 spec: 9 containers: 10 - image: "gcr.io/<PROJECT_ID>/airflow:v1b35" 11 args: ["webserver"] 12 name: airflow-web 13 imagePullPolicy: IfNotPresent 14 ports: 15 - containerPort: 8080 16 protocol: TCP 17 resources: 18 requests: {cpu: "250m", memory: "128Mi"} 19 limits: {cpu: "500m", memory: "512Mi"}

QoS✑ Guaranteed

✑ Limits OR Limits = Requests

✑ Burstable

✑ Limits not set OR Requests != Limits

✑ Guaranteed and Best-Effort = Burstable

✑ Burstable and Best-Effort = Burstable

✑ Best-Effort

✑ Requests, Limits 모두 설정 안된 경우

✑ 이를 바탕으로 oom_score_adjust 결정

✑ 중요한 것이 먼저 kill 될 수 있으니 Resources 설정 중요.

14

Pod은 2개 이상의 container를 가질 수 있기때문에

Guaranteed 가 있더라도 Burstable 로 분류될 수 있습니다.

Expose✑ $ kubectl expose \ ✑ pod/airflow-web \ ✑ —namespace dev \ ✑ —port=8080 \ ✑ —target-port=8080 \ ✑ —type=LoadBalancer

✑ $ kubectl get service —namespace dev ✑ $ open http://EXTERNAL_IP:8080/

15

외부로 노출하기위해선 expose가 필요합니다.

—type 을 별도로 기록하지 않으면 ClusterIP가 생성됩니다.

HTTP LoadBalancer는 Ingress Object Model 통해서 하며 이 발표에서는 자세히 언급되지 않습니다.

Deployment✑ Provisioning

✑ OS, Network, …

✑ Resource (CPU, Memory, Storage, …)

✑ Application Code

✑ Dependencies

✑ Configurations

✑ Update

✑ Rolling Update

✑ Blue-Green Deployment

✑ Rollback

16

17

Kubernetes ConfigMap - 코드변경 없이 Configuration

ConfigMap $ kubectl create -f config.yaml

kind: ConfigMapapiVersion: v1metadata: name: airflow-conf namespace: devdata: airflow.cfg.file: |- [core] airflow_home = /opt/airflow dags_folder = /opt/airflow/dags base_log_folder = /opt/airflow/logs

하나의 단일 코드베이스로

언제라도 설정을 갈아 엎는 방법을 소개합니다.

Mounting ConfigMap as Volume

…spec: volumes: - name: airflow-conf configMap: name: airflow-conf items: - key: airflow.cfg.file path: airflow.cfg containers: - image: "gcr.io/<PROJECT_ID>/airflow:v1b35" … volumeMounts: - name: airflow-conf mountPath: /etc/config…

볼륨 마운트!

헷갈리면 이전 장을 다시 보시면 됩니다.

Deployment✑ Provisioning

✑ OS, Network, …

✑ Resource (CPU, Memory, Storage, …)

✑ Application Code

✑ Dependencies

✑ Configurations

✑ Update

✑ Rolling Update

✑ Blue-Green Deployment

✑ Rollback

20

Kubernetes Deployment

21

Kubernetes Deployment✑ Newer and Higher level concept (since 1.2) ✑ ReplicaSet, ReplicationController ✑ Pods, ReplicaSet 등 리소스를 생성하고 기존의 것을 바꾸는 등 일련의 작업을 명시합니다.

✑ Replica, Autoscaling ✑ Rolling Update, Rolling Back

✑ PodTemplate

22

Deployment 가 알아서 해주기때문에 Pod이나 ReplicaSet 등의 리소스 생성에대해 크게 고민하실 필요는 없습니다.

기본적으로 명시하는 것들은 replica 랑 update strategy 정도이구요.

생성한 deployment 로 autoscale, rolling update, rollout 등을 수행할 수 있습니다.

Deployment에도 생성할 Pod에대한 기본 Template을 명세합니다.

23

apiVersion: extensions/v1beta1kind: Deploymentmetadata: name: af-web namespace: devspec: replicas: 3 strategy: rollingUpdate: maxSurge: 1 maxUnavailable: 1 type: RollingUpdate template:# Pod 생략

Writing a Deployment spec $ kubectl create -f airflow-web-deployment.yaml

Expose✑ $ kubectl expose \ ✑ deploy/airflow-web \ ✑ —namespace dev \ ✑ —port=8080 \ ✑ —target-port=8080 \ ✑ —type=LoadBalancer

✑ $ kubectl get service —namespace dev ✑ $ open http://EXTERNAL_IP:8080/

24

Rolling Update✑ $ kubectl set image \ ✑ —namespace dev \ ✑ deploy/af-web \ ✑ af-web=gcr.io/PROJECT_ID/REPO:VERSION

✑ $ kubectl apply -f airflow-web-deployment.yaml

✑ $ kubectl edit —namespace dev deploy/af-web

25

Deployment✑ Provisioning

✑ OS, Network, …

✑ Resource (CPU, Memory, Storage, …)

✑ Application Code

✑ Dependencies

✑ Configurations

✑ Update

✑ Rolling Update

✑ Blue-Green Deployment

✑ Rollback

26

Rollback /1✑ $ kubectl set image \ ✑ —namespace dev \ ✑ deploy/af-web \ ✑ af-web=gcr.io/PROJECT_ID/REPO:VERSION

✑ $ kubectl apply OR kubectl edit

27

Rollback /2✑ $ kubectl rollout history \ ✑ —namespace dev deploy/af-web

✑ $ kubectl rollout undo \ ✑ —namespace dev —dry-run=true \ ✑ —to-revision=<RevNo> deploy/af-web

28

Deployment✑ Provisioning

✑ OS, Network, …

✑ Resource (CPU, Memory, Storage, …)

✑ Application Code

✑ Dependencies

✑ Configurations

✑ Update

✑ Rolling Update

✑ Blue-Green Deployment

✑ Rollback

29

Blue-Green Deployment 는 가장 나중에 다룹니다.

Scalability - scale in/out, autoscale

30

Scale✑ $ kubectl scale —namespace dev \ ✑ —replicas=3 deploy/af-worker

✑ 현재 replica가 2개일 때만 적용하고 싶을 땐,

✑ $ kubectl scale —namespace dev \ ✑ —replicas=3 —current-replicas=2 deploy/af-worker

31

Horizontal Pod Autoscaling since 1.2

✑ stable 버전에선 cpu만 지원

✑ $ kubectl autoscale \ ✑ deploy/af-worker \ ✑ —cpu-percent=60 —min=1 —max=4

✑ $ kubectl get hpa

✑ autoscaling/v2alpha1 에서 더 다양하게 제어 가능해집니다. ✑ memory, multiple custom metrics

32

Scalability - scale up/down

33

Scalability✑ Scale up/down

✑ Assigning Pods to Nodes

✑ Attach label to the node

✑ Add a nodeSelector field to Pod spec

34

Node Pool✑ $ gcloud container node-pools create NAME \ ✑ —zone ZONE --cluster CLUSTER \ ✑ —machine-type n1-standard-4 \ ✑ —num-nodes 3

35

Preemptible Node Pool✑ $ gcloud beta container node-pools create NAME \ ✑ —zone ZONE --cluster CLUSTER \ ✑ —machine-type n1-standard-4 \ ✑ —num-nodes 3 \ ✑ —preemptible

✑ $ kubectl get nodes \ ✑ —selector='cloud.google.com/gke-preemptible'

✑ $ kubectl get nodes \ ✑ —selector='!cloud.google.com/gke-preemptible'

36

저렴한 가격으로 클러스터를 운영해봅시다.

근데 중요한 POD이 preemptible에 올라가면 어떻게 될까요…

Pod을 특정 노드에 할당되도록 알아봅시다.

Label✑ 모든 resource에 label 추가/삭제 가능

✑ $ kubectl label node NODE_NAME \ ✑ —overwrite key=value

✑ Removing a label ✑ $ kubectl label node NODE_NAME key-

37

NodeSelector 를 언급하기 전에 각 리소스 (node, pod, …)에 Label을 달 수 있습니다.

38

apiVersion: v1kind: Podmetadata: labels: run: af-workerspec: nodeSelector: cloud.google.com/gke-preemptible: 'true' containers: - image: … name: af-worker

좀 전에 언급한 Label 값을 이용할 수 있습니다.

Blue-Green Deployment /1

39

apiVersion: extensions/v1beta1kind: Deploymentmetadata: labels: color: green || blue app: af-web name: af-web-green || af-web-bluespec: replicas: 1 template: metadata: labels: color: green || blue app: af-web

Deployment 를 두개를 배포합니다. 하나는 blue 또 다른 하나는 green 으로 합니다.

전체를 한번에 다른 버전으로 route 시켜보도록 하겠습니다.

Blue-Green Deployment /2

40

spec: ports: - nodePort: 32354 port: 8080 protocol: TCP targetPort: 8080 selector: color: green app: af-web type: LoadBalancer

apiVersion: v1kind: Servicemetadata: labels: run: af-web name: af-web

Expose 하면 기본적으로 Service 하나 만들어집니다.

$ kubectl get services

$ kubectl edit service/<SERVICE_NAME>

한 다음 설정처럼 selector 값을 조정해서 새롭게 배포한 곳으로 가도록 할 수 있습니다.

Deployment✑ Provisioning

✑ OS, Network, …

✑ Resource (CPU, Memory, Storage, …)

✑ Application Code

✑ Dependencies

✑ Configurations

✑ Update

✑ Rolling Update

✑ Blue-Green Deployment

✑ Rollback

41

그 외에도… 시간 부족으로 ….

42

하나의 클러스터 2개 이상의 팀

43

Resource Quota✑ Namespace 별로 resource Quota

44

apiVersion: v1kind: ResourceQuotametadata: name: compute-resourcesspec: hard: pods: "4" requests.cpu: "1" requests.memory: 1Gi limits.cpu: "2" limits.memory: 2Gi

configmaps persistentvolumeclaims replicationcontrollers secrets services services.loadbalancers

이번 발표에서 —namespace 옵션이 들어있는 quota 기능때문에 그렇습니다.

환경별로 quota를 지정할 수도 있고 조직별로 분리시킬 수도 있습니다. 서로의 간섭을 줄일 수 있겠죠.

Google Cloud HTTPS LoadBalancer

45

아직 Internal Load Balancer 가 안되는 건 아쉽습니다.

Issue 로는 등록되어있습니다.

Google Cloud Container Builder

코드변경시 컨테이너 빌드해서 Google Container Registry로 자동 배포

46

StatefulSets 상태를 가지는 어플리케이션

StorageClass volumeClaimTemplates (PersistentVolumeClaim)

47

Q & A

48

감사합니다.

49