Kubernetes on GCP

Kubernetes on GCP
Daegeun 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
✑ Dependencies
✑ Configurations
✑ Update
✑ Rolling Update
✑ Rollback
16

17
Kubernetes ConfigMap
- 코드변경 없이 Configuration

ConfigMap
$ kubectl create -f config.yaml
kind: ConfigMap
apiVersion: v1
metadata:
name: airflow-conf
namespace: dev
data:
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
✑ Dependencies
✑ Configurations
✑ Update
✑ Rolling Update
✑ Rollback
20

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/v1beta1
kind: Deployment
metadata:
name: af-web
namespace: dev
spec:
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
✑ —port=8080
✑ —target-port=8080
✑ —type=LoadBalancer
✑ $ kubectl get service —namespace dev
✑ $ open http://EXTERNAL_IP:8080/
24

Rolling Update
✑ $ kubectl set image
✑ 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
✑ Dependencies
✑ Configurations
✑ Update
✑ Rolling Update
✑ Rollback
26

Rollback /1
✑ $ kubectl set image
✑ 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
✑ Dependencies
✑ Configurations
✑ Update
✑ Rolling Update
✑ 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: v1
kind: Pod
metadata:
labels:
run: af-worker
spec:
nodeSelector:
cloud.google.com/gke-preemptible: 'true'
containers:
- image: …
name: af-worker
좀 전에 언급한 Label 값을 이용할 수 있습니다.

Blue-Green Deployment /1
39
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
labels:
color: green || blue
app: af-web
name: af-web-green || af-web-blue
spec:
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: v1
kind: Service
metadata:
labels:
run: af-web
name: af-web
Expose 하면 기본적으로 Service 하나 만들어집니다.
$ kubectl get services
$ kubectl edit service/<SERVICE_NAME>
한 다음 설정처럼 selector 값을 조정해서 새롭게 배포한 곳으로 가도록
할 수 있습니다.

Deployment
✑ Provisioning
✑ Dependencies
✑ Configurations
✑ Update
✑ Rolling Update
✑ Rollback
41

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

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

Resource Quota
✑ Namespace 별로 resource Quota
44
apiVersion: v1
kind: ResourceQuota
metadata:
name: compute-resources
spec:
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

Kubernetes on GCP

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à Kubernetes on GCP

Similaire à Kubernetes on GCP (20)

Kubernetes on GCP