Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

kakao
PRO
December 09, 2022

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

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

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

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

kakao
PRO

December 09, 2022
Tweet

More Decks by kakao

Other Decks in Programming

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