모든 것이 kubernetes인 세상에서 안전하게 배포하기

#Kubernetes #Helm #ArgoCD #Yaml #Predictable #Deterministic #Declarative

카카오엔터프라이즈의 클라우드는 모든것이 kubernetes로 이루어져있습니다. 그렇기에 kubernetes의 관리가 매우 중요합니다. kubernetes는 yaml 기반으로 어플리케이션을 관리하여 yaml을 관리할 시 그 결과를 예측하기 좋으나 yaml은 텍스트 기반의 마크업 언어이기 때문에 그대로 사람이 사용할 시 관리측면에서 생산성이 떨어지게 됩니다. 그래서 yaml관리의 생산성을 높이면서도 안정적으로 예측가능한 배포를 만들어내기 위한 시스템을 소개합니다.

발표자 : al.ien
카카오엔터프라이즈에서 클라우드를 개발하는 알입니다. 불가능한 기술에 도전하는 것을 좋아하고 개인을 넘어 전체가 성장 할 수 있는 방법을 찾는 것을 좋아합니다.

Transcript

1. 모든 것이 kubernetes인 세상에서 
 안전하게 배포하기 이어형 Al.ien 카카오엔터프라이즈 Copyright 2022. Kakao Corp. All rights reserved. Redistribution or public display is not permitted without written permission from Kakao. if(kakao)2022
2. 모든 것이 kubernetes인 세상 kubernetes yaml을 관리하기 위한 일반적인 방법 kubernetes yaml을 배포하기 위한 일반적인 방법 안전하게 배포하기 위해 필요한 것 배포를 예측하기 위한 방법: astrolabe
3. 모든 것이 kubernetes인 세상
4. 카카오엔터프라이즈, 쿠버네티스 기반 IaaS로 클라우드 보안 인증 획득1) 1) 카카오엔터프라이즈, 쿠버네티스 기반 IaaS 클라우드 보안 인증 획득 http:/ /www.dt.co.kr/contents.html?article_no=2022063002109931820002
5. lots of applications baremetal servers VMs kubernetes DBs fi rewalls network controllers and more lots of things 😍
6. application 
 a application 
 b application 
 c application 
 d application 
 e application 
 f application 
 g application 
 h application 
 i application 
 j ... kubernetes cluster
7. b e f g bespoke 
 application2) common 
 off - the - shelf (COTS) 
 components3) 2) 3) Declarative application management in Kubernetes https:/ /github.com/kubernetes/design - proposals - archive/blob/main/architecture/declarative - application - management.md a c d h j i - 맞춤형 application - 회사에서 자체 개발되는 application - 보통 stateless 한 application - 기성품 component 
 - 외부(white box or black box) 에서 
 가지고 와서 사용되는 component 
 - 보통 stateful한 infrastructure system 
 (DB, virtual switch, reverse proxy 등)
8. kubernetes yaml을 관리하기 위한 
 일반적인 방법
9. kustomize helm
10. kustomize - kubernetes - native 하며 선언적인 방법으로 yaml 관리 
 - con fi gmap, secret 등 생성 
 - 전체 리소스에 동일한 namespace, label, annotation 등 설정 
 - yaml 병합, 패치 
 - kubectl 만으로도 사용가능 
 - public github 이용한 배포가 용의
11. - template 방식으로 복잡한 형태의 yaml 도 관리가능 
 - kubernetes 와 별도로 버전관리 가능 
 - custom hook과 같이 절차적인 방식의 
 배포 방식을 지원 
 - 별도의 helm client 설치 필요 
 - chart repository를 이용해야 버전관리가 
 유용 helm
12. bespoke 
 application common 
 off - the - shelf (COTS) 
 components - 외부에 공개되어 있는 코드를 그대로 사용하는 
 일이 잦음 (업데이트도 외부에서 변경되는걸 반영) 
 - infrastructure 에 가까울 수록 복잡한 
 쿠버네티스의 설정들이 동반되야 함 - 보통 개발된 코드의 업데이트로 
 이미지 교체가 잦음 
 - 이 외는 con fi gmap 이나 secret 
 등의 변경이 있음
13. bespoke 
 application common 
 off - the - shelf (COTS) 
 components kustomize helm ❤ ❤
14. kubernetes yaml을 배포하기 위한 
 일반적인 방법
15. Script Con fi guration Management Infrastructure as Code(IaC) GitOps bash bourne shell chef puppet ansible terraform fl ux argocd
16. argocd fl ux Continuous Deployment kustomize helm git
17. fl ux argocd - helm golang library를 사용해서 helm release를 helm 방식으로 설치함 
 - chart, release 등을 CRD로 helm data 에 맞춰서 데이터가 호환며 헬름의 의존성을 유지 
 - helm 호환성 유지가 중요하면 좋음 - `helm template` 커맨드를 이용해 kubectl 로 사용할 yaml로 변환해서 설치함 
 - application 이라는 CRD로 독자적인 data를 사용함 
 - helm 호환성 없이 kubernetes - native 방법이 좋으면 좋음 helm 관리 차이점
18. apiVersion: argoproj.io/v1alpha1 kind: Application metadata: namespace: argocd spec: destination: namespace: application-a server: https://kubernetes.local source: helm: values: | parameter-a: new-value repoURL: https://github.com/my/helm path: helm/application-a targetRevision: 7694a2da51c01312fd63e0f8d21276de584446d4 argocd application custom resource data(CRD)
19. apiVersion: argoproj.io/v1alpha1 kind: Application metadata: namespace: argocd spec: destination: namespace: application-a server: https://kubernetes.local source: helm: values: | parameter-a: new-value repoURL: https://github.com/my/helm path: helm/application-a targetRevision: 7694a2da51c01312fd63e0f8d21276de584446d4 argocd application custom resource data(CRD) kustomize는 5가지 외에는 추가적인 yaml이 필요
20. apiVersion: argoproj.io/v1alpha1 kind: Application metadata: namespace: argocd spec: destination: namespace: application-a server: https://kubernetes.local source: helm: values: | parameter-a: new-value repoURL: https://github.com/my/helm path: helm/application-a targetRevision: 7694a2da51c01312fd63e0f8d21276de584446d4 argocd application custom resource data(CRD) Target Value Template 
 (git에 의해 고정) 😍 helm은 편안
21. argocd application application yaml build sync `helm template ...`
22. argocd fl
23. 안전하게 배포하기 위해 
 필요한 것
24. 변경 난이도: ᷀ 변경 난이도: ᬊ 변경 난이도: ᓓ
25. 변경 난이도: ᷀ 변경 난이도: ᬊ 변경 난이도: ᓓ => 신규 설치 => 바뀔 값에 집중 => 변경된 내용에 따라 
 value도 변해야 
 할 수 있음
26. apiVersion: v1 kind: Service metadata: labels: app: memcached-exporter release: {{ .Values.commonLabels }} name: memcached-exporter namespace: monitoring spec: ports: - name: metrics port: 9150 targetPort: 9150 selector: app: memcached-exporter release: {{ .Values.commonLabels }} template commonLabels: site-a commonLabels: site-b site - a values site - b values value 변경시 
 완성될 yaml가 
 비교적 쉽게 예측 가능
27. apiVersion: v1 kind: Service metadata: labels: app: memcached-exporter release: {{ .Values.commonLabels }} name: memcached-exporter namespace: monitoring spec: ports: - name: metrics port: 9150 targetPort: 9150 selector: app: memcached-exporter release: {{ .Values.commonLabels }} apiVersion: v1 kind: Service metadata: labels: app: memcached-exporter release: this-is-super-long-length-label-upper-than-63characters-{{ .Values.commonLabels }} name: memcached-exporter namespace: monitoring spec: ports: - name: metrics port: 9150 targetPort: 9150 selector: app: memcached-exporter release: this-is-super-long-length-label-upper-than-63characters-{{ .Values.commonLabels }} old template new template commonLabels: site-c11 commonLabels: site-a commonLabels: site-b site - a values site - a values site - c11 values 💥 template 변경시 
 이미 사용중인 value들과 합쳐서 예측이 필요
28. 배포되기 전에 정확하게 변경된걸 
 알 수 있었으면 좋겠는데.. 🤔
29. ? 변경되기전에 argocd가 
 변경할 내용을 예측 할 수 있으면 보다 
 안전하게 배포가능
30. application yaml master new PullRequest #1 build sync yaml build diff PR을 yaml로 빌드해서 k8s와 비교하면 예측가능 
 `kubectl diff ...` PR test는 이걸로 수행하고 성공시 다음을 진행
31. new PullRequest #1 public network private network 🚫
32. application yaml master new PullRequest #1 build yaml build = diff = master를 build한 값과 PR을 build한 값을 
 비교하여 정적분석을 수행
34. 그런데, 
 프로덕션에서 
 이정도면 충분할까? 🤔
35. template 변경시 기존 클러스터 영향도 예측 연계된 여러 어플리케이션의 동시 배포시 예측 new PullRequest #1 application application application new PullRequest #2 application application application
36. 배포를 예측하기 위한 방법: 
 astrolabe
37. Astrolabe( 성반 )4) 성반(ᕨጷ) 
 라틴어: astrolabe 아스트롤라베 
 
 고대에서부터 만들어져 발전되어온 정교한 천문 도구 로서, 태양, 달, 행성, 별의 위치를 예측하는 기능을 하 였다 - 위키백과 4) 성반 (천문학) https:/ /ko.wikipedia.org/wiki/성반_(천문학)
38. 역시 Astrolabe를 썼을 때 제일 좋은 점은 
 PR을 Merge하기 전에 PR이 실제로 Cluster에 발생시킬 변경사항을 미리 대조해서 볼 
 수 있는 점이 아닐까 싶어요. 예기치 못한 변경사항을 눈치채지 못하고 그냥 
 넘겼다가 뒷수습하는 일을 줄여준다고 봅니다. 그리고 그 외에는 그런 변경사항 기록이 오랫동안 
 남는 점도 있다고 봅니다. 자신의 PR이 배포됐을 때의 어느 범위에 
 적용이 되고 어떤 변경사항이 있는지 정보를 강제 로 보게 해주는 ㅎㅎ 모든 개발자들을 평등하 게 만들어주는(?) 좋은 도구라고 생각합니다 저는 PR을 올릴 때 Astrolabe을 사용해서 최종 배포 형상을 검토하는 것을 선호하고요. 덕분에 확실히 실수가 많이 줄었습니다. 그리고 동료의 PR을 리뷰 할 때도 자주 Astrolabe을 확인하고 있습니다. Astrolabe 개발 후 사용하는 동료 코멘트
39. cluster-1 cluster-2 cluster-3 cluster-4 application - a - value application - a - yaml application - b - value application - b - yaml application - c - value application - c - yaml DIFF DIFF DIFF DIFF DIFF DIFF
40. cluster-1 cluster-2 cluster-3 cluster-4 cluster-5 cluster-6 cluster-7 cluster-8 cluster-9 ... ... ... a value a yaml b value b yaml c value c yaml d value d yaml e value e yaml f value f yaml g value g yaml h value h yaml i value i yaml ... ... DIFF DIFF DIFF DIFF DIFF DIFF DIFF DIFF DIFF DIFF DIFF DIFF DIFF DIFF DIFF DIFF DIFF DIFF DIFF DIFF DIFF
41. template 변경시 기존 클러스터 영향도 예측 연계된 여러 어플리케이션의 동시 배포시 예측
43. template 변경시 기존 클러스터 영향도 예측
44. 연계된 여러 어플리케이션의 동시 배포시 예측 value만 변경되었기 때문에 배포가 발생하지 않음 value, yaml 둘 다 변경되었기 때문에 배포가 발생
45. github diff 스타일로 
 yaml 변경을 확인 diff를 눌렀을때 실제 화면 github diff 스타일로 
 value 변경을 확인 walter, lloyd 고마워요!!
46. PR 단위로 테스트를 수행하고 기본적인 기능을 검증 PR 단위로 변경을 사람이 리뷰하고 기존 자원의 영향도를 파악 PR 단위로 변경이 배포될때 서비스의 SLA에 미치는 영향을 예측 PR 단위로 변경이 배포될때 문제시 배포의 롤백을 예측 GITOPS + Continuous Deployment
47. 감사합니다.