모든 것이 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
   

   View Slide

2. 모든 것이 kubernetes인 세상
   
   
   kubernetes yaml을 관리하기 위한 일반적인 방법
   
   
   kubernetes yaml을 배포하기 위한 일반적인 방법
   
   
   안전하게 배포하기 위해 필요한 것
   
   
   배포를 예측하기 위한 방법: astrolabe
   

   View Slide

3. 모든 것이 kubernetes인 세상
   

   View Slide

4. 카카오엔터프라이즈, 쿠버네티스 기반 IaaS로 클라우드 보안 인증 획득1)
   1) 카카오엔터프라이즈, 쿠버네티스 기반 IaaS 클라우드 보안 인증 획득 http:/
   /www.dt.co.kr/contents.html?article_no=2022063002109931820002
   

   View Slide

5. lots of applications
   baremetal servers
   VMs
   kubernetes DBs
   fi
   rewalls
   network controllers
   and more lots of things
   😍
   

   View Slide

6. application
   

   a
   application
   

   b
   application
   

   c
   application
   

   d
   application
   

   e
   application
   

   f
   application
   

   g
   application
   

   h
   application
   

   i
   application
   

   j
   ...
   kubernetes cluster
   

   View Slide

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 등)
   

   View Slide

8. kubernetes yaml을 관리하기 위한
   

   일반적인 방법
   

   View Slide

9. kustomize helm
   

   View Slide

10. kustomize
    - kubernetes
    -
    native 하며 선언적인
    방법으로 yaml 관리
    

    - con
    fi
    gmap, secret 등 생성
    

    - 전체 리소스에 동일한 namespace,
    label, annotation 등 설정
    

    - yaml 병합, 패치
    

    - kubectl 만으로도 사용가능
    

    - public github 이용한 배포가 용의
    

    View Slide

11. - template 방식으로 복잡한 형태의 yaml
    도 관리가능
    

    - kubernetes 와 별도로 버전관리 가능
    

    - custom hook과 같이 절차적인 방식의
    

    배포 방식을 지원
    

    - 별도의 helm client 설치 필요
    

    - chart repository를 이용해야 버전관리가
    

    유용
    helm
    

    View Slide

12. bespoke
    

    application
    common
    

    off
    -
    the
    -
    shelf (COTS)
    

    components
    - 외부에 공개되어 있는 코드를 그대로 사용하는
    

    일이 잦음 (업데이트도 외부에서 변경되는걸 반영)
    

    - infrastructure 에 가까울 수록 복잡한
    

    쿠버네티스의 설정들이 동반되야 함
    - 보통 개발된 코드의 업데이트로
    

    이미지 교체가 잦음
    

    - 이 외는 con
    fi
    gmap 이나 secret
    

    등의 변경이 있음
    

    View Slide

13. bespoke
    

    application
    common
    

    off
    -
    the
    -
    shelf (COTS)
    

    components
    kustomize helm
    ❤ ❤
    

    View Slide

14. kubernetes yaml을 배포하기 위한
    

    일반적인 방법
    

    View Slide

15. Script
    Con
    fi
    guration
    
    
    Management
    Infrastructure
    
    
    as Code(IaC)
    GitOps
    bash
    
    
    bourne shell
    chef
    
    
    puppet
    
    
    ansible
    terraform
    fl
    ux
    
    
    argocd
    

    View Slide

16. argocd
    fl
    ux
    Continuous
    
    
    Deployment
    kustomize
    helm
    git
    

    View Slide

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
    
    
    관리 차이점
    

    View Slide

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)
    

    View Slide

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이 필요
    

    View Slide

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은
    
    
    편안
    

    View Slide

21. argocd
    
    
    application
    application
    yaml
    build sync
    `helm template ...`
    

    View Slide

22. argocd
    fl
    

    View Slide

23. 안전하게 배포하기 위해
    

    필요한 것
    

    View Slide

24. 변경 난이도: ᷀
    변경 난이도: ᬊ
    변경 난이도: ᓓ
    

    View Slide

25. 변경 난이도: ᷀
    변경 난이도: ᬊ
    변경 난이도: ᓓ
    => 신규 설치
    => 바뀔 값에 집중
    => 변경된 내용에 따라
    

    value도 변해야
    

    할 수 있음
    

    View Slide

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가
    

    비교적 쉽게 예측 가능
    

    View Slide

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들과 합쳐서 예측이 필요
    

    View Slide

28. 배포되기 전에 정확하게 변경된걸
    

    알 수 있었으면 좋겠는데..
    
    
    🤔
    

    View Slide

29. ?
    
    
    변경되기전에
    
    
    argocd가
    

    변경할 내용을 예측
    할 수 있으면 보다
    

    안전하게 배포가능
    

    View Slide

30. application
    yaml
    master
    new
    
    
    PullRequest #1
    build sync
    yaml
    build diff
    PR을 yaml로 빌드해서 k8s와 비교하면 예측가능
    

    `kubectl diff ...`
    PR test는 이걸로 수행하고 성공시 다음을 진행
    

    View Slide

31. new
    
    
    PullRequest #1
    public network
    private network
    🚫
    

    View Slide

32. application
    yaml
    master
    new
    
    
    PullRequest #1
    build
    yaml
    build
    =
    diff
    =
    master를 build한 값과 PR을 build한 값을
    

    비교하여 정적분석을 수행
    

    View Slide

33. View Slide

34. 그런데,
    

    프로덕션에서
    

    이정도면 충분할까?
    
    
    🤔
    

    View Slide

35. template 변경시
    
    
    기존 클러스터
    
    
    영향도 예측
    
    
    연계된 여러
    
    
    어플리케이션의
    
    
    동시 배포시 예측
    
    
    new
    
    
    PullRequest #1
    application
    application application
    new
    
    
    PullRequest #2
    application
    application
    application
    

    View Slide

36. 배포를 예측하기 위한 방법:
    

    astrolabe
    

    View Slide

37. Astrolabe( 성반 )4)
    성반(ᕨጷ)
    

    라틴어: astrolabe 아스트롤라베
    

    

    고대에서부터 만들어져 발전되어온 정교한 천문 도구
    로서, 태양, 달, 행성, 별의 위치를 예측하는 기능을 하
    였다 - 위키백과
    4) 성반 (천문학) https:/
    /ko.wikipedia.org/wiki/성반_(천문학)
    
    
    

    View Slide

38. 역시 Astrolabe를 썼을 때 제일 좋은 점은
    

    PR을 Merge하기 전에 PR이 실제로
    Cluster에 발생시킬 변경사항을 미리 대조해서 볼
    

    수 있는 점이 아닐까 싶어요.
    
    
    예기치 못한 변경사항을 눈치채지 못하고 그냥
    

    넘겼다가 뒷수습하는 일을 줄여준다고 봅니다.
    
    
    그리고 그 외에는 그런 변경사항 기록이 오랫동안
    

    남는 점도 있다고 봅니다.
    자신의 PR이 배포됐을 때의 어느 범위에
    

    적용이 되고 어떤 변경사항이 있는지 정보를
    강제 로 보게 해주는 ㅎㅎ 모든 개발자들을 평등하
    게 만들어주는(?) 좋은 도구라고 생각합니다 저는
    PR을 올릴 때 Astrolabe을 사용해서 최종 배포
    형상을 검토하는 것을 선호하고요. 덕분에 확실히
    실수가 많이 줄었습니다. 그리고 동료의 PR을 리뷰
    할 때도 자주 Astrolabe을 확인하고 있습니다.
    Astrolabe 개발 후 사용하는 동료 코멘트
    

    View Slide

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
    

    View Slide

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
    

    View Slide

41. template 변경시
    
    
    기존 클러스터
    
    
    영향도 예측
    
    
    연계된 여러
    
    
    어플리케이션의
    
    
    동시 배포시 예측
    
    
    

    View Slide

42. View Slide

43. template 변경시
    
    
    기존 클러스터
    
    
    영향도 예측
    

    View Slide

44. 연계된 여러
    
    
    어플리케이션의
    
    
    동시 배포시 예측
    
    
    value만
    
    
    변경되었기 때문에
    
    
    배포가 발생하지 않음
    value, yaml 둘 다
    
    
    변경되었기 때문에
    
    
    배포가 발생
    

    View Slide

45. github diff 스타일로
    

    yaml 변경을 확인
    diff를 눌렀을때 실제 화면
    github diff 스타일로
    

    value 변경을 확인
    walter, lloyd 고마워요!!
    

    View Slide

46. PR 단위로
    
    
    테스트를 수행하고
    
    
    기본적인 기능을 검증
    PR 단위로
    
    
    변경을 사람이 리뷰하고
    
    
    기존 자원의 영향도를 파악
    PR 단위로
    
    
    변경이 배포될때 서비스의
    
    
    SLA에 미치는 영향을 예측
    PR 단위로
    
    
    변경이 배포될때 문제시
    
    
    배포의 롤백을 예측
    GITOPS
    
    
    +
    
    
    Continuous
    
    
    Deployment
    

    View Slide

47. 감사합니다.
    

    View Slide