Masaya Aoyama CyberAgent KubernetesΤίγεςϜͷόʔδϣϯ௥ैͱ ॊೈͳ؅ཧ΁ͷ௅ઓ CloudNative Days Tokyo 2021 amsy810 @amsy810

- Co-chair ੨ࢁ ਅ໵ + CREATIONLINE - 技術アドバイザ + SAKURA Internet Research Center – 客員研究員 + 3-shake 技術顧問 + PLAID - Organizer - KaaS Product Owner - Publications Twitter: @amsy810

Kubernetes のアップグレードとエコシステム Kubernetes 運⽤の始まり… Kubernetes はアップグレードが⼤変と聞くので⽅針を決める e.g. マネージドサービスなので in-place で 3 ヶ⽉に 1 回、マイナーバージョンを上げる＋セキュリティパッチやバグ修正は影響がある場合に上げる Kubernetes に⾜りない部分は、豊富なエコシステムで便利に機能拡張︕ × エコシステムの進化に追従せずに塩漬けに => 上げたタイミングでビックバンリリース状態（K8s APIの廃⽌、CRD 変更、アプリ仕様変更、etc） => 果たしてこれは “CloudNative”︖ × エコシステムのマニフェストは⼿動で取得してきて、書き換えながら利⽤ => Upstream の追従コストが急増（オプションの変更、RBACの変更、etc） アプリケーション側だけ CloudNative ⽬指してませんか︖ それを⽀える プラットフォーム側も CloudNative であるべき

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

ΤίγεςϜ͕ఏڙ͢ΔϚχϑΣετͱ ࣗಈߋ৽ͷ࣮ݱ

Kubernetes マニフェストの⾃動更新の⽬指す形 Config リポジトリに対して、各エコシステムに対する ⾃動的なアップグレードのPRと変更差分の表⽰ Config Repo manifest manifest

Kubernetes マニフェストの⾃動更新の⽬指す形 Config リポジトリに対して、各エコシステムに対する ⾃動的なアップグレードのPRと変更差分の表⽰ Config Repo manifest manifest

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 多くのエコシステムはこの⽅法で公開

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 を当てるファイル

（参考）最新リリースの取得 モノレポ構成で tag に複数パターンの命名規則がある場合、 Prefix の命名規則を判断して最新リリースを取得 namespace: ingress-nginx bases: - github.com/kubernetes/ingress-nginx/deploy/.../baremetal?ref=controller-v1.0.2 patches: - ./patches.yaml kustomization.yaml

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

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

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

ؔ࿈͢Δ Argo CD ͷ Tips

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

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.

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/

ʮෳ਺ͷΤίγεςϜʯͱ ʮෳ਺ͷΫϥελʯͷॊೈͳ؅ཧ

AKE – Kubernetes as a Service ͷ֓ཁ

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 管理クラスタ ユーザークラスタ

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 管理クラスタ ユーザークラスタ

GitOps at AKE

管理クラスタに対するエコシステムの管理 管理クラスタには、多岐にわたるエコシステムを導⼊ マニフェスト追加後には、別途 “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 ... ディレクトリ構成の例

ユーザークラスタ郡に対するエコシステムの管理 管理クラスタ上にデプロイ 管理クラスタ ユーザークラスタ 「ユーザー側では直接利⽤しないもの」 「KaaS としての⾃動管理系の機能」 などで利⽤ e.g. Cluster Autoscaler 管理クラスタからユーザクラスタの状態を監視し、スケールが必要になったらスケールアウト e.g. Node Auto Repair 管理クラスタから、ユーザークラスタのノードの状態を ユーザー向けクラスタ上にデプロイ 管理クラスタ ユーザークラスタ 「ユーザが直接利⽤する必要があるもの」 「ユーザクラスタ上の情報が必要なもの」 などで利⽤ e.g. Cert Manager CRD を含む⼀式をデプロイし、ユーザーの Ingress などで証明書が利⽤できるように e.g. Prometheus / Exporter 類 ユーザのクラスタ上でメトリクスを収集する（管理クラスタへ集約）

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

⾃作 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

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 か否かはここでは取り扱いません

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 か否かはここでは取り扱いません

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 する）

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 の作成は複雑

ApplicationSet ʹΑΔॊೈͳ Application ؅ཧ

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

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

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: {...} ディレクトリ構成の例

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 }}'

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 管理クラスタ ユーザークラスタ

ブランチ戦略 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

ブランチ戦略 • 新たな Kubernetes マイナーバージョンが出るたびに main ブランチから切り出す • 変更は main ブランチに⾏い、各ブランチには⾃動的に cherry-pick（実際には PR） • リリースを⾏うタイミングで各ブランチで tag を発⾏

複数ブランチに対するアップデートの追従 • ⾃動アップグレードは main ブランチに対して⾏う • main ブランチへの PR は、各ブランチに対しても⾃動的に作成 （⼿動で作成する PR も、各ブランチに対して⾃動的に作成） v1.21 ブランチ向け v1.20 ブランチ向け 本来の PR

各クラスタの 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

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 管理クラスタ ユーザークラスタ

各クラスタのごとに利⽤するアドオンの切り替え 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: {...}

（参考）変数展開エラーの緩和 変数展開に利⽤する値は、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: {...}

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 管理クラスタ ユーザークラスタ

Ϋϥελ͝ͱͷ ΞϓϦέʔγϣϯڍಈͷ੾Γସ͑

【再掲】 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 か否かはここでは取り扱いません

【再掲】 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 か否かはここでは取り扱いません

アプリケーションの挙動の変更 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.… }}'

（参考）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

·ͱΊ

Conclusion & Future works • エコシステムを導⼊するときは、Upstream へ追従できる仕組みを最初につくる • 複数クラスタを GitOps で管理する場合は、ブランチ戦略 + ApplicationSet が効果的 => Platform 側もしっかり “CloudNative” な状態を⽬指すべき 現在のエコシステムアップグレーダーは「shellscripts 製の内部 DSL」相当の仕組み ⼀定期間実運⽤してみて、汎⽤的なモデル化が固まったタイミングで Go + YAML で OSS へ ソースコードの変更差分だけではなく、GitHub Release や Release note などから変更点を表⽰ ApplicationSet と変数展開を使っても、GitOps における 「宣⾔された状態」 と⾔えるのか、 その謎を確かめるためアマゾンの奥地へ向かう

We are hiring ! • Kubernetes クラスタの⾼度な運⽤⾃動化 with CustomController • ユーザクラスタに対するセキュリティ・SRE ⽀援機能 • 機械学習 × 運⽤⽀援 • , and many more… ご相談は下記までお気軽にどうぞ Twitter: @amsy810 E-mail: aoyama_masaya_xa@cyberagent.co.jp

Thank you for your attention Twitter: @amsy810