- 발표자: 카카오 홍석용

1. @ 2 6 0
. 2 16 0) 6 68 6
(
,

2. o d
:GICJ
0 . 8L DB .DGL 7H 82 kh
0po 0 c 8IB K .DGL St m ae
uui
7H K C 2IG B - I K D St 2 AGLJ /IB I
uui vzn / 7 kh
.G L BKN KB BKN
( ) 7H K C / N nb l 1GIBOG : 8DL B
CL I K J cn kh AKKHJ C J CI
CL I K J D K sg AKKH JD C C J BG - -
0GG D KL N PS rW y IGLH D I
) (#

3. Ni O c bp D
A 3 ? A
1
A 3 ? A m
3 ? A P S
C A
7 7 : .2A C ) : 2A
: .2A C 2AA ? e
kneK P oMle d D a
: .2A C ) : 2A O g
!!

4. - - / I , :
() )
신규 클러스터 생성
클러스터 상태 토폴로지
클러스터 관리 화면
Worker node 추가(증설) Cluster 사용자 추가/제거

5. Builder
/
() )
1) Push / PR
2) Merge / Release
Authentication
Authorization
Access Control
Auto-Security Scan
Auto-Build
Auto-Deploy
4) Image build
D2hub
3) Web hook
5) Image push
6) Deploy
부서별 / 서비스 별 독립 클러스터 제공
카카오 개발자
DKOS
git clone
image pull
애조로 Krane KEMI
DNSaaS IaaS Monitoring
IMS
인프라 구성 정보 관리
,!!

6. () )
• 사용중인 클러스터 : 700 여개
• 전체 노드 수 : 8000 여대 (물리서버 1100 여대)
• 전체 컨테이너 개수 : 18,000 여개
• 단일 최대 클러스터 : 1600대
• 최대 TPS(http, https) : x0000

7. () )
카카오톡 게임탭 헤어샵 주문하기 카카오파머카카오T
다음 메일 다음 뉴스 카카오 번역(GPU)

8. () )
알람 생성 정책 설정

9. () )

10. . ,
• App을 띄우면 LB 가 붙는 직관적 개념
• mesos / marathon 기반
• 익숙한 사용성과 아키텍처
• 기존 클러스터 마이그레이션 용이
• 상용 버전 존재
•Pod, Service 등 낯선 추상 개념
• 사내 시스템 연동을 다 새로 해야함
• 활성화된 커뮤니티
• 거의 모든 퍼블릭 클라우드에서 지원
• DeFacto (사실상의 표준)
Mesos + marathon의 주도권이 mesosphere 로
넘어가면서 신규 버전 서비스를 위해서는
DC/OS로 신규 구성 필요

11. :
Mesos + marathon Kubernetes
Deploy
O
rolling-update, blue-green, rollback
+ canary(vamp 추가 설치)
O
rolling-update, blue-green, canary,
rollback
Batch job O O
High Availability O O
Service Discovery & Load
Balancing
O O
Self-Healing O O
Health Checks O O
Web UI O O
CLI X, DC/OS(O) O
Auto Scaling O O
Persistent volume O O
Performance and
Scalability
10,000 node 5,000 node
Networking
Host / bridge
+ plugins
Host / bridge
+ plugins
event tracking Last one History
life cycle hook X O
... ...

12. ! !
1. Cloud native 한 서비스 운영/디버깅 :
• local proxy 기능을 이용한 debugging (console, log, network)
• Label / Selector, Taint / Tolerations
• Event Tracking
• configMap, Secret
• life cycle hook (preStop, postStart...)
2. 오픈소스 생태계
• k8s native support : kubeflow(TensorFlow), jenkinsX, rook(ceph), spark, spinnaker..
• k8s official support : hadoop, kafaka, redis, istio...
• Community power : gitHub, stack overflow, blog, slack..

13. Replica Set(From Deployment)
) () ) ) ,
• 서비스 참여 중이었던 Pod 를 격리하고, 내 Local에 연결해서 테스트하고 디버깅 할 수 있음.
• Label / Selector, Taint / Tolerations 활용 : Pod 격리 가능, 장애 복구 시 우선 순위 높은 서비스부터 살리기에 유용.
Cluster Network
Localhost
Notebook
Service(Type=LoadBalancer)
pod podpodpod
Label
Service=In
Label
Service=In
Label
Service=In
Label
Service=Out
USER
Log, Console, Network
Proxy
1) 로컬에서 Pod 로그 확인
Kubectl logs –f ${POD_NAME}
3) 로컬에서 Pod bash 콘솔 접근
Kubectl exec –it ${POD_NAME} /bin/bash
2) 로컬에서 Pod HTTP 8080 포트 접근
Kubectl port-forward ${POD_NAME} 8080:8080
-> http://localhost:8080
Pod IP가 뭔지, 어디 호스트 서버에 떠 있는지 알 필요 없음.
Selector
Service=In
Selector
Service=In

14. • Event Tracking
-> kubernetes system log 를 찾지 않아도 Event History 를 통해 Resource 별 이슈의 원인을 알 수 있음.
-> 장애로 인해 Master 연결이 끊어진 노드의 현황에 대해서도 확인할 수 있음.

15. • Event Tracking
-> Marathon 의 경우 image pull 이나 resource 가 없어서 스케줄링에 실패 했을 때 waiting 상태로 기다리고 있음.
<- Case : Mesos Marathon apps with
persistent volume apps stuck at
suspended
사용자는 무엇이 문제인지 알 수가 없음.
Marathon 이나 Mesos log를 봐야 함
<- 슬레이브가 네트워크 단절로
마스터와의 연결이 끊어지면
리스트에서 삭제해버림.
슬레이브가 수 천 수 백대 되는 상황에서
어떤 슬레이브가 아직 못 붙었는지
확인하기가 어려움.

16. 깨끗한 코드 작성, 자동화 된 테스트, 리팩토링, 코드 품질
실제 세계에 가까운 비즈니스 관점에서 소프트웨어 설계
대규모 컨테이너 마이크로 서비스를 자동화하기 위한 패턴
분산 응용 프로그램을 설계. 확장성, 탄력성 고려
Clean Code + DDD + MSA 다 배웠더니 Cloud Native 도 알아야 되는 세상이 왔음...
Ref : https://www.slideshare.net/bibryam/designing-cloud-native-applications-with-kubernetes

17. 마이크로 서비스 아키텍처 클라우드 네이티브 아키텍처
<- 오케스트레이터의 매니지먼트 사이클과
어플리케이션이 유기적으로 연동되게
해주는 설계가 필요.
*클라우드 네이티브 어플리케이션을 개발할 때 고려할 점 :
https://www.cncf.io/blog/2017/05/15/developing-cloud-native-applications/

18. *Pod 설계 패턴 예 : Pod 컨테이너 끼리 로컬 볼륨과 네트워크를 공유하는 구조를 활용
사이드카 패턴 엠베서더/프록시 패턴
https://vitalflux.com/container-design-patterns-kubernetes-pods-design/
어댑터 패턴

19. ) (
1. Single concern principle (SCP) : container 1개에는 단일 목적의 process 만 띄워주세요.
2. High observability principle (HOP) : Readiness / HealthCheck API 제공, log는 stdout, stderr 로.
3. Life-cycle conformance principle (LCP) : SIGTERM / SIGKILL 처리 필요, PreStop / PostStart 활용.
4. Image immutability principle (IIP) : Dev/ Test / Prod 환경에 모두 같은 Image 사용.
5. Process disposability principle (PDP) : State는 외부화하거나 분산시켜야 하며 App의 시작/종료는 신속하게.
6. Self-containment principle (S-CP) : 모든 dependency 는 build time에 image에 넣고, 환경에 따라 다른
정보는 Run time에 configMap, Storage에 넣어주세요.
7. Runtime confinement principle (RCP) : container app이 필요한 CPU / MEM / Disk 에 대해 고려되어야 함.
https://kubernetes.io/blog/2018/03/principles-of-container-app-design/

20. High observability principle (HOP)
Readiness / HealthCheck API 제공, log는 stdout, stderr 로 뿌려주세요.
1) 컨테이너가 살았는지? 죽었는지? 서비스 트래픽을 보내 줘도 되는지? 안되는지?
-> 오케스트레이터가 컨테이너 앱의 상태를 알 수 있는 API가 필요.
2) 컨테이너 안에서 파일로 로그를 쌓으면?
-> 오케스트레이터 입장에선 아무런 로그도 남기지 않는 앱 (관리 X, 디버깅 기능 X)
-> 컨테이너 종료 시 로그 유실
-> 해당 컨테이너는 다른 노드에 가서 뜸 : 추적 어려움
-> 로그 크기가 커졌을 때 Disk Full : Host 전체 컨테이너 장애
3) log 를 stdout / stderr 로 보낸 경우
-> 외부 로그 수집시스템과의 연계(플랫폼에서 제공) : ELK Stack 등
-> 오케스트레이터에서 자동으로 logrotate 실행
-> json parsing 등 드라이버 제공도 해줌
-> 오케스트레이터의 debugging 기능 이용 가능

21. Life-cycle conformance principle (LCP)
1) SIGTERM / SIGKILL 처리 필요
- 컨테이너는 종료 될 때 SIGTERM 을 받고 SIGKILL 을 통해 종료.
- 이때 SIGTERM에 대한 처리가 Application 에 구현되어 있지 않으면 처리하던 Task 를 유실하고 그냥 종료.
- 무중단 배포를 위한 필수 구현 사항.

22. Life-cycle conformance principle (LCP)
2) K8s의 경우 PreStop / PostStart 활용.
<- graceful shutdown command

23. Container Orchestrator 만으로는 부족
Application의 Cloud Native로의 변화 필요
개발자들의 적극적인 참여
조직 문화, 일하는 방식의 변화 필요