Kubernetesエコシステムのバージョン追従と柔軟な管理への挑戦 / cndt2021-amsy810

Kubernetesにデプロイしたエコシステムのバージョンアップは継続的に最小限の労力で頻繁に行えていますか？

複数のエコシステムのデプロイや、複数のクラスタに対するデプロイを柔軟に行えていますか？

CyberAgentでは、マネージドKubernetesサービスを提供するAKEを提供しています。
ユーザに対して様々なカスタマイズを行った状態で、かつ最新機能が利用できる状態でクラスタを提供する必要があります。

このセッションでは私達のエコシステム管理の経験から、次の2つをトピックとして提供します。

1.
Kubernetesのエコシステム自体を継続的にアップデートすることは重要です。
その仕組みを整備し、Platformも継続的に進化させ続ける、すなわちPlatform側のCloudNative化を推進した事例を紹介します。

2.
AKEではエコシステムは全てGitOps + Argo CD ApplicationSet Controllerで管理する方式に変更しました。
これにより、複数のアプリケーションを個別にカスタマイズしてデプロイしたり、複数のクラスタに対してデプロイすることを可能にしています。
ApplicationSetについてDeepDiveしながら、柔軟なエコシステムの管理について紹介します。

---

Masaya Aoyama （青山 真也）
CyberAgent - サイバーエージェント
Software Engineer

2016年CyberAgent入社。プライベートクラウド上のKubernetes as a Serviceのプロダクトオーナー、Kubernetes/CloudNative 領域の Developer Expertsとしても従事。国内カンファレンスでのKeynoteや海外カンファレンス等での登壇経験。著書に『Kubernetes完全ガイド』『みんなのDocker/Kubernetes』。現在はOSSへのContribute 活動をはじめ、CloudNative Days Tokyo のCo-chair、CNCF公認のCloud Native Meetup TokyoやKubernetes Meetup TokyoのOrganizerなどコミュニティ活動にも従事。

Transcript

1. Masaya Aoyama CyberAgent KubernetesΤίγεςϜͷόʔδϣϯ௥ैͱ ॊೈͳ؅ཧ΁ͷ௅ઓ CloudNative Days Tokyo 2021 amsy810 @amsy810
2. - Co-chair ੨ࢁ ਅ໵ + CREATIONLINE - 技術アドバイザ + SAKURA Internet Research Center – 客員研究員 + 3-shake 技術顧問 + PLAID - Organizer - KaaS Product Owner - Publications Twitter: @amsy810
3. Kubernetes のアップグレードとエコシステム Kubernetes 運⽤の始まり… Kubernetes はアップグレードが⼤変と聞くので⽅針を決める e.g. マネージドサービスなので in-place で 3 ヶ⽉に 1 回、マイナーバージョンを上げる＋セキュリティパッチやバグ修正は影響がある場合に上げる Kubernetes に⾜りない部分は、豊富なエコシステムで便利に機能拡張︕ × エコシステムの進化に追従せずに塩漬けに => 上げたタイミングでビックバンリリース状態（K8s APIの廃⽌、CRD 変更、アプリ仕様変更、etc） => 果たしてこれは “CloudNative”︖ × エコシステムのマニフェストは⼿動で取得してきて、書き換えながら利⽤ => Upstream の追従コストが急増（オプションの変更、RBACの変更、etc） アプリケーション側だけ CloudNative ⽬指してませんか︖ それを⽀える プラットフォーム側も CloudNative であるべき
4. GitOps Config Repo manifest manifest Agent Git pull Apply via InCluster API 宣⾔的な定義がバージョン管理されたリポジトリに保存された状態 = マニフェスト管理の話題 そして⾃動的にPullされ、継続的にその定義状態に調整される = GitOps Agent の話題 GitOps Principles v1.0.0 by CNCF TAG App Delivery GitOps WG, https://github.com/open-gitops/documents/blob/release-v1.0.0/PRINCIPLES.md What Is GitOps, https://www.weave.works/blog/what-is-gitops-really Kubernetes anti-patterns: Let's do GitOps, not CIOps!, https://www.weave.works/blog/kubernetes-anti-patterns-let-s-do-gitops-not-ciops
5. ΤίγεςϜ͕ఏڙ͢ΔϚχϑΣετͱ ࣗಈߋ৽ͷ࣮ݱ
6. Kubernetes マニフェストの⾃動更新の⽬指す形 Config リポジトリに対して、各エコシステムに対する ⾃動的なアップグレードのPRと変更差分の表⽰ Config Repo manifest manifest
7. Kubernetes マニフェストの⾃動更新の⽬指す形 Config リポジトリに対して、各エコシステムに対する ⾃動的なアップグレードのPRと変更差分の表⽰ Config Repo manifest manifest
8. Argo CD における対象のマニフェスト*1 • Rawマニフェスト • Kustomize • Helm charts • Ksonnet（開発停⽌*2） • Jsonnet*3 • Custom Plugin*4 *1 User Guide > Tools, https://argo-cd.readthedocs.io/en/stable/user-guide/application_sources/ *2 Welcoming Heptio Open Source Projects to VMware, https://tanzu.vmware.com/content/blog/welcoming-heptio-open-source-projects-to-vmware *3 prometheus-operator/kube-prometheus, https://github.com/prometheus-operator/kube-prometheus *4 argoproj/argo-cd – Plugins, https://github.com/argoproj/argo-cd/blob/master/docs/user-guide/config-management-plugins.md#plugins 多くのエコシステムはこの⽅法で公開
9. 1. Kustomize マニフェストの⾃動追従 1. GitHub の最新リリースを取得 2. kustomization.yaml の Reference の更新 namespace: ingress-nginx bases: - github.com/kubernetes/ingress-nginx/deploy/.../baremetal?ref=controller-v1.0.2 patches: - ./patches.yaml kustomization.yaml ⾃動追従の設定 • GitHub Repo 設定ファイル • ベースとなる kustomization.yaml • kustomize で patch を当てるファイル
10. （参考）最新リリースの取得 モノレポ構成で tag に複数パターンの命名規則がある場合、 Prefix の命名規則を判断して最新リリースを取得 namespace: ingress-nginx bases: - github.com/kubernetes/ingress-nginx/deploy/.../baremetal?ref=controller-v1.0.2 patches: - ./patches.yaml kustomization.yaml
11. 2. Helm charts の⾃動追従 1. 最新の Helm chart を⽤いてマニフェストを⽣成 「helm template」 コマンドを利⽤したマニフェストの⽣成 2. kustomization.yaml のファイルリストの更新 ⽣成される ./templates と ./crds 以下のファイルを対象 ⾃動追従の設定 • Helm Repo • Helm App 設定ファイル • values.yaml • ベースとなる kustomization.yaml • kustomize で patch を当てるファイル namespace: external-secrets patches: - ./patches.yaml resources: - ./namespace.yaml - ./kubernetes-external-secrets/templates/deployment.yaml - ./kubernetes-external-secrets/templates/service.yaml - ./kubernetes-external-secrets/templates/serviceaccount.yaml - ./kubernetes-external-secrets/templates/rbac.yaml - ./kubernetes-external-secrets/crds/kubernetes-client.io_externalsecrets_crd.yaml kustomization.yaml
12. 3. Raw マニフェストの更新追従（パターン 1） 1. GitHub の最新リリースを取得 2. Submodule の更新 3. kustomization.yaml のファイルリストの更新 ⾃動追従の設定 • GitHub Repo と対象のディレクトリ 設定ファイル • ベースとなる kustomization.yaml • kustomize で patch を当てるファイル namespace: external-dns resources: - ./deployment.yaml - ./external-dns/docs/contributing/crd-source/crd-manifest.yaml - ./external-dns/docs/contributing/crd-source/xxxxx.yaml kustomization.yaml
13. 3. Raw マニフェストの更新追従（パターン 2） 1. GitHub の最新リリースを取得 2. 特定の URL からファイルの取得 downloads/ ディレクトリ配下に保存 3. kustomization.yaml のファイルリストの更新 ./downloads 以下のファイルを対象 ⾃動追従の設定 • ダウンロード先URL 設定ファイル • ベースとなる kustomization.yaml • kustomize で patch を当てるファイル namespace: argocd patches: - ./patches.yaml resources: - ./downloads/install.yaml kustomization.yaml
14. ؔ࿈͢Δ Argo CD ͷ Tips
15. 1. Kustomize などのバージョン依存問題 Argo CD では内部的に保持しているバイナリを⽤いて、マニフェストを⽣成 => Argo CD のバージョンを上げると、Kustomize や Helm などのバージョンも上がる *1 => エコシステムのマニフェストが Argo CD のツールでは新しくて or 古くて対応できない e.g. Kustomize は内部で KYAML というライブラリを利⽤ × Kustomize 4.x 系から KYAML が必須となり、 その影響で⽇本語コメントを受け付けない問題が発⽣ => アプリケーション毎に 特定の Kustomize のバージョンを利⽤したい *2 kind: Application metadata: name: guestbook spec: source: repoURL: https://github.com/xxx.git targetRevision: HEAD path: guestbook-kustomize kustomize: version: v3.5.4 *1 tool-versions.sh https://github.com/argoproj/argo-cd/blob/release-2.1/hack/tool-versions.sh *2 Custom Kustomize Version, https://argo-cd.readthedocs.io/en/stable/user-guide/kustomize/#custom-kustomize-versions # v2.1 の hack/tool-versions.sh helm2_version=2.17.0 helm3_version=3.6.0 jq_version=1.6 ksonnet_version=0.13.1 kubectl_version=1.17.8 kubectx_version=0.6.3 kustomize4_version=4.2.0 protoc_version=3.7.1 swagger_version=0.19.0
16. 1. Kustomize などのバージョン依存問題 Application で指定されたバージョンの Kustomize バイナリはそれぞれ配置する *1 kind: Application metadata: name: guestbook spec: source: repoURL: https://github.com/xxx.git targetRevision: HEAD path: guestbook-kustomize kustomize: version: v3.5.4 kind: ConfigMap metadata: name: argocd-cm namespace: argocd data: kustomize.path.v3.5.1: /custom-tools/kustomize_3_5_1 kustomize.path.v3.5.4: /custom-tools/kustomize_3_5_4 1. initContianer or ⾃前でビルドしたコンテナイメージでバイナリを⽤意 *2 *1 Custom Kustomize Version, https://argo-cd.readthedocs.io/en/stable/user-guide/kustomize/#custom-kustomize-versions *2 Custom Tooling, https://argo-cd.readthedocs.io/en/stable/operator-manual/custom_tools/ 2. 3.
17. 2. 任意のマニフェスト管理⽅法への対応 CUE でしかマニフェストが公開されていなかった場合は︖ Built-in ではサポートされていない CUE なども Custom Plugin *1 を定義することでサポート可能 （バイナリはコンテナイメージで利⽤できるようにする必要あり） zoetro さんが CUE 向けの設定例を公開 *2 Custom Config Management Plugin は v2 実装が提案中 *3 CustomResource を⽤いた実装 kind: ConfigMap metadata: name: argocd-cm namespace: argocd data: configManagementPlugins: | - name: pluginName init: command: ["echo"] args: ["initialize"] generate: command: ["cue"] args: ["dump”, "./"] lockRepo: true *1 Plugins, https://argo-cd.readthedocs.io/en/stable/user-guide/config-management-plugins/ *2 zoetrope/argocd-cue, https://github.com/zoetrope/argocd-cue *3 Config Management Plugin Enhancement, https://argo-cd.readthedocs.io/en/stable/proposals/config-management-plugin-v2/
18. ʮෳ਺ͷΤίγεςϜʯͱ ʮෳ਺ͷΫϥελʯͷॊೈͳ؅ཧ
19. AKE – Kubernetes as a Service ͷ֓ཁ
20. ClusterAPI-based Kubernetes as a Service 2017 年頃に OpenStack Heat ベースで実装、現在は ClusterAPI ベースの実装に変更中 v1.19.7 v1.20.5 v1.21.3 kind: Cluster metadata: name: test-cluster-01 spec: topology: version: v1.21.2 controlPlane: replicas: 3 workers: machineDeployments: - class: type1-workers name: cpu-nodepool-01 replicas: 5 kind: Cluster metadata: name: test-cluster-01 spec: topology: version: v1.21.2 controlPlane: replicas: 3 workers: machineDeployments: - class: type1-workers name: cpu-nodepool-01 replicas: 5 kind: Cluster metadata: name: test-cluster-01 spec: topology: version: v1.19.7 controlPlane: replicas: 3 workers: machineDeployments: - class: type1-workers name: cpu-nodepool-01 replicas: 5 管理クラスタ ユーザークラスタ
21. Kubernetes as a Service での要件 複数クラスタを容易に管理できる 各クラスタの Kubernetes バージョンごとに適切なマニフェストがデプロイできる 各クラスタで利⽤する機能（アドオン、アプリケーション）の Enable/Disable が切り替えられる v1.19.7 Prometheus, Cert-manager v1.20.5 CSI (A) v1.21.3 CSI (B), Cluster Autoscaler 管理クラスタ ユーザークラスタ
22. GitOps at AKE
23. 管理クラスタに対するエコシステムの管理 管理クラスタには、多岐にわたるエコシステムを導⼊ マニフェスト追加後には、別途 “Application” も追加 管理クラスタ kind: Application metadata: name: external-dns namespace: argocd spec: project: default source: repoURL: git@github.com:xxx/xxx.git path: manifests/external-dns /overlays/release targetRevision: develop destination: server: https://Kubernetes.default.svc kind: Application metadata: name: cert-manager namespace: argocd spec: project: default source: repoURL: git@github.com:xxx/xxx.git path: manifests/cert-manager/overlays/release targetRevision: develop destination: server: https://kubernetes.default.svc manifests ├── cert-manager │ ├── base │ └── overlays ├── external-dns │ ├── base │ └── overlays ... ディレクトリ構成の例
24. ユーザークラスタ郡に対するエコシステムの管理 管理クラスタ上にデプロイ 管理クラスタ ユーザークラスタ 「ユーザー側では直接利⽤しないもの」 「KaaS としての⾃動管理系の機能」 などで利⽤ e.g. Cluster Autoscaler 管理クラスタからユーザクラスタの状態を監視し、スケールが必要になったらスケールアウト e.g. Node Auto Repair 管理クラスタから、ユーザークラスタのノードの状態を ユーザー向けクラスタ上にデプロイ 管理クラスタ ユーザークラスタ 「ユーザが直接利⽤する必要があるもの」 「ユーザクラスタ上の情報が必要なもの」 などで利⽤ e.g. Cert Manager CRD を含む⼀式をデプロイし、ユーザーの Ingress などで証明書が利⽤できるように e.g. Prometheus / Exporter 類 ユーザのクラスタ上でメトリクスを収集する（管理クラスタへ集約）
25. Argo CD での複数クラスタ管理と登録 ⼀般的には 「argocd cluster add」 コマンドで追加 ※ この構成が GitOps か否かはここでは取り扱いません kind: Secret metadata: name: my-test-cluster namespace: argocd labels: argocd.argoproj.io/secret-type: cluster stringData: name: my-test-cluster server: https://10.xxx.xxx.xxx:6443 config: （Argo CD 特有のkubeconfig相当のファイル） clusterResources: true type: Opaque kind: Secret metadata: name: my-test-cluster namespace: argocd labels: argocd.argoproj.io/secret-type: cluster stringData: name: my-test-cluster server: https://10.xxx.xxx.xxx:6443 config: （Argo CD 特有のkubeconfig相当のファイル） clusterResources: true type: Opaque kind: Secret metadata: name: test-cluster-01 namespace: argocd labels: argocd.argoproj.io/secret-type: cluster stringData: name: test-cluster-01 server: https://10.0.0.1:6443 config: （Argo CD 特有のkubeconfig相当のファイル） clusterResources: true type: Opaque 管理クラスタ ユーザークラスタ test-cluster-01 https://10.0.0.1:6443 test-cluster-02 https://10.0.0.2:6443 test-cluster-03 https://10.0.0.3:6443
26. ⾃作 Controller による Argo CD へのクラスタの登録 ClusterAPI が発⾏するクラスタの認証情報を元に Argo CD Clsuter Secret を⽣成 ake-addon-manager (controllers) reconcile watch ClusterAPI resources 管理クラスタ ユーザークラスタ kind: Secret metadata: name: my-test-cluster namespace: argocd labels: argocd.argoproj.io/secret-type: cluster stringData: name: my-test-cluster server: https://10.xxx.xxx.xxx:6443 config: （Argo CD 特有のkubeconfig相当のファイル） clusterResources: true type: Opaque kind: Secret metadata: name: my-test-cluster namespace: argocd labels: argocd.argoproj.io/secret-type: cluster stringData: name: my-test-cluster server: https://10.xxx.xxx.xxx:6443 config: （Argo CD 特有のkubeconfig相当のファイル） clusterResources: true type: Opaque kind: Secret metadata: name: test-cluster-01 namespace: argocd labels: argocd.argoproj.io/secret-type: cluster stringData: name: test-cluster-01 server: https://10.0.0.1:6443 config: （Argo CD 特有のkubeconfig相当のファイル） clusterResources: true type: Opaque ※ この構成が GitOps か否かはここでは取り扱いません test-cluster-01 https://10.0.0.1:6443 test-cluster-02 https://10.0.0.2:6443 test-cluster-03 https://10.0.0.3:6443
27. Argo CD での特定のクラスタに対するデプロイ 登録されたクラスタを利⽤する際は、 Application リソースの spec.destination で指定 test-cluster-01 https://10.0.0.1:6443 test-cluster-02 https://10.0.0.2:6443 test-cluster-03 https://10.0.0.3:6443 管理クラスタ ユーザークラスタ kind: Application metadata: name: my-test-cluster2-my-app namespace: argocd spec: project: amsy source: repoURL: git@github.com:xxx/xxx.git path: manifests/my-app targetRevision: v1.20-ake.211006 destination: server: https://10.0.0.2:6443 kind: Application metadata: name: test-cluster-01-prometheus namespace: argocd spec: project: amsy source: repoURL: git@github.com:xxx/xxx.git path: manifests/prometheus targetRevision: v1.20-ake.211006 destination: server: https://10.0.0.1:6443 ※ この構成が GitOps か否かはここでは取り扱いません
28. Argo CD での特定のクラスタ向けのデプロイ 管理クラスタに対して、 個々のクラスタ⽤にアプリケーションをデプロイ test-cluster-01 https://10.0.0.1:6443 test-cluster-02 https://10.0.0.2:6443 test-cluster-03 https://10.0.0.3:6443 管理クラスタ ユーザークラスタ kind: Application metadata: name: my-test-cluster2-my-app namespace: argocd spec: project: amsy source: repoURL: git@github.com:xxx/xxx.git path: manifests/node-autorepair targetRevision: v1.20-ake.211006 destination: server: https://kubernetes.default.svc kind: Application metadata: name: test-cluster-01-cluster-autoscaler namespace: argocd spec: project: amsy source: repoURL: git@github.com:xxx/xxx.git path: manifests/cluster-autoscaler targetRevision: v1.20-ake.211006 destination: server: https://kubernetes.default.svc ※ この構成が GitOps か否かはここでは取り扱いません
29. App of Apps pattern *1 *1 Cluster Bootstrapping, https://argo-cd.readthedocs.io/en/stable/operator-manual/cluster-bootstrapping/#app-of-apps-pattern kind: Application metadata: name: cert-manager namespace: argocd spec: {...} kind: Application metadata: name: external-dns namespace: argocd spec: {...} kind: Application metadata: name: applications namespace: argocd spec: source: repoURL: git@github.com:xxx/xxx.git path: manifests/applications manifests ├── applications │ ├── applications.yaml │ ├── cert-manager.yaml │ ├── external-dns.yaml │ └── kustomization.yaml ├── cert-manager │ ├── base │ └── overlays ├── external-dns │ ├── base │ └── overlays ... ディレクトリ構成の例 いくつかの Application リソース⾃体を Application で管理する（GitOps する）
30. App of Apps pattern *1 *1 Cluster Bootstrapping, https://argo-cd.readthedocs.io/en/stable/operator-manual/cluster-bootstrapping/#app-of-apps-pattern kind: Application metadata: name: cert-manager namespace: argocd spec: {...} kind: Application metadata: name: external-dns namespace: argocd spec: {...} kind: Application metadata: name: applications namespace: argocd spec: source: repoURL: git@github.com:xxx/xxx.git path: manifests/applications manifests ├── applications │ ├── applications.yaml │ ├── cert-manager.yaml │ ├── external-dns.yaml │ └── kustomization.yaml ├── cert-manager │ ├── base │ └── overlays ├── external-dns │ ├── base │ └── overlays ... ディレクトリ構成の例 いくつかの Application リソース⾃体を Application で管理する（GitOps する） 【課題】 エコシステム追加時にほぼ同じ設定値の Application の追加を忘れる そもそも複数クラスタに対する柔軟な Application の作成は複雑
31. ApplicationSet ʹΑΔॊೈͳ Application ؅ཧ
32. Argo CD ApplicationSet における Generator ApplicationSet は条件を元に Application リソースを⽣成する、Argo CD の拡張機能 generate kind: ApplicationSet metadata: name: guestbook spec: generators: - list: elements: - cluster: test-cluster-1 url: https://10.0.0.1 - cluster: test-cluster-2 url: https://10.0.0.2 template: metadata: name: '{{cluster}}-guestbook' spec: source: {...} destination: server: '{{url}}' namespace: guestbook kind: Application metadata: name: 'test-cluster-1-guestbook' spec: source: {...} destination: server: 'https://10.0.0.1' namespace: guestbook kind: Application metadata: name: 'test-cluster-2-guestbook' spec: source: {...} destination: server: 'https://10.0.0.2' namespace: guestbook
33. Argo CD ApplicationSet における Generator ⽣成する条件のことを「Generator」と呼び、いくつかの Generator が⽤意されている • List generator 静的に定義された url と cluster の値を元に⽣成 • Cluster generator Argo CD Cluster secret を元に⽣成 • Git generator Git リポジトリのディレクトリ構造をもとに⽣成 • SCM Provider generator GitHub などのリポジトリ・ブランチ情報をもとに⽣成 • Matrix generator 複数の Generator を元に⽣成 • Cluster Decision Resource generator CustomResource を元に⽣成（e.g. Open Cluster Management CR） *1 ApplicationSet - Generator, https://argocd-applicationset.readthedocs.io/en/stable/Generators/ apiVersion: argoproj.io/v1alpha1 kind: ApplicationSet metadata: name: guestbook spec: generators: - list: elements: - cluster: test-cluster-1 url: https://10.0.0.1 - cluster: test-cluster-2 url: https://10.0.0.2 template: metadata: name: '{{cluster}}-guestbook' spec: source: {...} destination: server: '{{url}}' namespace: guestbook
34. Git generator コンポーネントが追加されるたびに Application の追加が不要に manifests ├── cert-manager │ ├── base │ └── overlays ├── external-dns │ ├── base │ └── overlays ... kind: Application metadata: name: 'external-dns' spec: project: ake source: repoURL: git@github.com:xxxxx/xxxxx.git targetRevision: develop path: 'manifests/external-dns/overlays/release' destination: {...} kind: Application metadata: name: 'cert-manager' spec: project: ake source: repoURL: git@github.com:xxxxx/xxxxx.git targetRevision: develop path: 'manifests/cert-manager/overlays/release' destination: {...} generate kind: ApplicationSet metadata: name: bootstrap-components spec: generators: - git: repoURL: git@github.com:xxxxx/xxxxx.git revision: develop directories: - path: manifests/* template: metadata: name: ‘{{ path.basename }}' spec: project: ake source: repoURL: git@github.com:xxxxx/xxxxx.git targetRevision: develop path: '{{ path }}/overlays/release' destination: {...} ディレクトリ構成の例
35. Cluster generator 各サーバーに同⼀のアプリケーションを追加する e.g. KaaS の各クラスタに Cilium を登録する kind: Application metadata: name: 'cilium-test-cluster-1' spec: project: default source: repoURL: git@github.com:xxxxx/addons.git targetRevision: main path: 'manifests/cilium/overlays/release' destination: server: 'https://10.0.0.1:6443' kind: Application metadata: name: 'cilium-test-cluster-2' spec: project: default source: repoURL: git@github.com:xxxxx/addons.git targetRevision: main path: 'manifests/cilium/overlays/release' destination: server: 'https://10.0.0.1:6443' generate kind: ApplicationSet metadata: name: cilium spec: generators: - clusters: {...} template: metadata: name: 'cilium-{{ name }}' spec: project: default source: repoURL: git@github.com:xxxxx/addons.git targetRevision: main path: manifests/cilium/overlays/release destination: server: '{{ server }}'
36. Kubernetes as a Service での課題 ✅ 複数クラスタを容易に管理できる 各クラスタの Kubernetes バージョンごとに適切なマニフェストがデプロイできる 各クラスタで利⽤する機能（アドオン、アプリケーション）の Enable/Disable が切り替えられる v1.19.7 Prometheus, Cert-manager v1.20.5 CSI (A) v1.21.3 CSI (B), Cluster Autoscaler 管理クラスタ ユーザークラスタ
37. ブランチ戦略 Kubernetesのマイナーバージョン毎にブランチを⽤意 => マイナーバージョンごとに利⽤できる機能に差があり、エコシステムのアップグレードに影響があるため それぞれのブランチにタグを発⾏し、そのタグを Argo CD で参照する => ブランチに対して変更を⾏った際にも、ユーザークラスタへの影響がないように kind: Application metadata: name: cert-manager spec: source: repoURL: https://github.com/xxx.git targetRevision: v1.19-ake.2 path: manifests/cert-manager
38. ブランチ戦略 • 新たな Kubernetes マイナーバージョンが出るたびに main ブランチから切り出す • 変更は main ブランチに⾏い、各ブランチには⾃動的に cherry-pick（実際には PR） • リリースを⾏うタイミングで各ブランチで tag を発⾏
39. 複数ブランチに対するアップデートの追従 • ⾃動アップグレードは main ブランチに対して⾏う • main ブランチへの PR は、各ブランチに対しても⾃動的に作成 （⼿動で作成する PR も、各ブランチに対して⾃動的に作成） v1.21 ブランチ向け v1.20 ブランチ向け 本来の PR
40. 各クラスタの K8s バージョンに 合わせたアドオンのデプロイ Argo CD Clsuter Secret で 指定された label / annotation の値を展開可能 kind: Application metadata: name: 'cilium-test-cluster-1' spec: project: 'my-project' source: repoURL: git@github.com:xxxxx/addons.git targetRevision: 'v1.20-ake.211006' path: 'manifests/cilium/overlays/release' destination: {...} kind: Application metadata: name: 'cilium-test-cluster-01' spec: project: 'amsy0930' source: repoURL: git@github.com:xxxxx/addons.git targetRevision: 'v1.20-ake.211006' path: 'manifests/cilium/overlays/release' destination: {...} kind: ApplicationSet metadata: name: cilium spec: generators: - clusters: {...} template: metadata: name: 'cilium-{{ name }}' spec: project: '{{ metadata.labels.ake/project }}' source: repoURL: git@github.com:xxxxx/addons.git targetRevision: '{{ metadata.labels.ake/version }}' path: manifests/cilium/overlays/release destination: {...} kind: Secret metadata: name: my-test-cluster namespace: argocd labels: argocd.argoproj.io/secret-type: cluster addons.ake/cilium: "true" ake/project: amsy0930 ake/version: v1.20-ake.211007 stringData: name: my-test-cluster server: https://10.xxx.xxx.xxx:6443 config: （Argo CD 特有のkubeconfig相当のファイル） clusterResources: true type: Opaque ※ 実際にはラベル名などは ake.cycloud.io/version などを利⽤しています kind: Secret metadata: name: test-cluster-01 namespace: argocd labels: argocd.argoproj.io/secret-type: cluster addons.ake/cilium: "true" ake/version: v1.20-ake.211007 ake/project: amsy0930 stringData: name: test-cluster-01 server: https://10.0.0.1:6443 config: （Argo CD 特有のkubeconfig相当のファイル） clusterResources: true type: Opaque
41. Kubernetes as a Service での課題 ✅ 複数クラスタを容易に管理できる ✅ 各クラスタの Kubernetes バージョンごとに適切なマニフェストがデプロイできる 各クラスタで利⽤する機能（アドオン、アプリケーション）の Enable/Disable が切り替えられる v1.19.7 Prometheus, Cert-manager v1.20.5 CSI (A) v1.21.3 CSI (B), Cluster Autoscaler 管理クラスタ ユーザークラスタ
42. 各クラスタのごとに利⽤するアドオンの切り替え Argo CD Clsuter Secret の label / annotation をもとに Generator で Selector を利⽤する AKE ではクラウドプロバイダーやその他様々な条件で切り替え（e.g. CCM, CSI） kind: Application metadata: name: 'cilium-test-cluster-01' spec: project: 'amsy0930' source: repoURL: git@github.com:xxxxx/addons.git targetRevision: 'v1.20-ake.211006' path: 'manifests/cilium/overlays/release' destination: {...} kind: ApplicationSet metadata: name: cilium spec: generators: - clusters: selector: matchExpressions: - key: addons.ake/cilium operator: In values: - "true" template: {...} ※ 実際にはラベル名などは ake.cycloud.io/version などを利⽤しています kind: Secret metadata: name: test-cluster-01 labels: argocd.argoproj.io/secret-type: cluster addons.ake/cilium: "true" ake/version: v1.20-ake.211007 stringData: {...} kind: Secret metadata: name: test-cluster-02 labels: argocd.argoproj.io/secret-type: cluster addons.ake/cilium: "false" ake/version: v1.20-ake.211007 stringData: {...}
43. （参考）変数展開エラーの緩和 変数展開に利⽤する値は、Selector の条件に含める ApplicationSet の Templating 部分の実装では、 値が存在しない場合は 失敗 や 空⽩ になるのではなく そのまま Application が作られる ＝ エラー kind: Application metadata: name: 'cilium-test-cluster-01' spec: source: targetRevision: 'v1.20-ake.211006' kind: ApplicationSet metadata: name: cilium spec: generators: - clusters: selector: matchExpressions: - key: addons.ake/cilium operator: In values: - "true" - key: ake/version operator: Exists template: spec: source: targetRevision: '{{ metadata.labels.ake/version }}' ※ 実際にはラベル名などは ake.cycloud.io/version などを利⽤しています kind: Secret metadata: name: test-cluster-01 labels: argocd.argoproj.io/secret-type: cluster addons.ake/cilium: "true" ake/version: v1.20-ake.211007 stringData: {...}
44. Kubernetes as a Service での課題 ✅ 複数クラスタを容易に管理できる ✅ 各クラスタの Kubernetes バージョンごとに適切なマニフェストがデプロイできる ✅ 各クラスタで利⽤する機能（アドオン、アプリケーション）の Enable/Disable が切り替えられる v1.19.7 Prometheus, Cert-manager v1.20.5 CSI (A) v1.21.3 CSI (B), Cluster Autoscaler 管理クラスタ ユーザークラスタ
45. Ϋϥελ͝ͱͷ ΞϓϦέʔγϣϯڍಈͷ੾Γସ͑
46. 【再掲】 Argo CD での特定のクラスタに対するデプロイ 各クラスタ毎に設定を変えたい場合はどうするのか…︖ e.g. ログの転送先、etc test-cluster-01 https://10.0.0.1:6443 test-cluster-02 https://10.0.0.2:6443 test-cluster-03 https://10.0.0.3:6443 管理クラスタ ユーザークラスタ kind: Application metadata: name: my-test-cluster2-my-app namespace: argocd spec: project: amsy source: repoURL: git@github.com:xxx/xxx.git path: manifests/my-app targetRevision: v1.20-ake.211006 destination: server: https://10.0.0.2:6443 kind: Application metadata: name: test-cluster-01-prometheus namespace: argocd spec: project: amsy source: repoURL: git@github.com:xxx/xxx.git path: manifests/prometheus targetRevision: v1.20-ake.211006 destination: server: https://10.0.0.1:6443 ※ この構成が GitOps か否かはここでは取り扱いません
47. 【再掲】 Argo CD での特定のクラスタ向けのデプロイ 管理クラスタに対して、 個々のクラスタ⽤にアプリケーションをデプロイ 各クラスタ向けだという設定はどこに⼊れるのか…︖ e.g. ClusterAutoscaler の対象クラスタ test-cluster-01 https://10.0.0.1:6443 test-cluster-02 https://10.0.0.2:6443 test-cluster-03 https://10.0.0.3:6443 管理クラスタ ユーザークラスタ kind: Application metadata: name: my-test-cluster2-my-app namespace: argocd spec: project: amsy source: repoURL: git@github.com:xxx/xxx.git path: manifests/node-autorepair targetRevision: v1.20-ake.211006 destination: server: https://kubernetes.default.svc kind: Application metadata: name: test-cluster-01-cluster-autoscaler namespace: argocd spec: project: amsy source: repoURL: git@github.com:xxx/xxx.git path: manifests/cluster-autoscaler targetRevision: v1.20-ake.211006 destination: server: https://kubernetes.default.svc ※ この構成が GitOps か否かはここでは取り扱いません
48. アプリケーションの挙動の変更 ApplicationSet で渡ってくる変数をアプリケーションに渡して挙動を変える⽅法 • e.g. Cluster Autoscaler が対象にするクラスタ名 • e.g. Datadog で利⽤する API Key Kustomize 外部からパラメータを渡すことができない （kustomize plugins を⾃作して頑張るという⼿もありそうだが…） Helm values を渡して挙動を変えることが可能 クラスタごとにアプリケーションに変更が必要なものは、 Helm の変数展開を利⽤して設定を切り替え kind: ApplicationSet metadata: name: cluster-autoscaler spec: template: spec: source: helm: parameters: - name: ake.cluster-name value: {{ name }} - name: ake.options.xxx value: '{{ metadata.annotations.… }}'
49. （参考）Argo CD Build Environment Argo CD にもいくつかの値を展開する機能 *1 が存在 Custom Tool、Jsonnet、Helmでは利⽤可能 だが、Kustomize では利⽤不可 *1 Build Environment, https://argo-cd.readthedocs.io/en/stable/user-guide/build-environment/ kind: Application metadata: name: my-app spec: source: helm: parameters: - name: kube-version value: $KUBE_VERSION # v1.22.1 - name: kube-api-versions value: $KUBE_API_VERSIONS # v1,apps/v1,... • ARGOCD_APP_NAME • ARGOCD_APP_NAMESPACE • ARGOCD_APP_REVISION • ARGOCD_APP_SOURCE_PATH • ARGOCD_APP_SOURCE_REPO_URL • ARGOCD_APP_SOURCE_TARGET_REVISION • KUBE_VERSION • KUBE_API_VERSIONS
50. ·ͱΊ
51. Conclusion & Future works • エコシステムを導⼊するときは、Upstream へ追従できる仕組みを最初につくる • 複数クラスタを GitOps で管理する場合は、ブランチ戦略 + ApplicationSet が効果的 => Platform 側もしっかり “CloudNative” な状態を⽬指すべき 現在のエコシステムアップグレーダーは「shellscripts 製の内部 DSL」相当の仕組み ⼀定期間実運⽤してみて、汎⽤的なモデル化が固まったタイミングで Go + YAML で OSS へ ソースコードの変更差分だけではなく、GitHub Release や Release note などから変更点を表⽰ ApplicationSet と変数展開を使っても、GitOps における 「宣⾔された状態」 と⾔えるのか、 その謎を確かめるためアマゾンの奥地へ向かう
52. We are hiring ! • Kubernetes クラスタの⾼度な運⽤⾃動化 with CustomController • ユーザクラスタに対するセキュリティ・SRE ⽀援機能 • 機械学習 × 運⽤⽀援 • , and many more… ご相談は下記までお気軽にどうぞ Twitter: @amsy810 E-mail: aoyama_masaya_xa@cyberagent.co.jp
53. Thank you for your attention Twitter: @amsy810