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

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

2. Helm charts の⾃動追従
1. 最新の Helm chart を⽤いてマニフェストを⽣成
「helm template」コマンドを利⽤したマニフェストの⽣成
2. kustomization.yaml のファイルリストの更新
⽣成される ./templates と ./crds 以下のファイルを対象
• Helm Repo
• Helm App
設定ファイル
• values.yaml
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

View Slide

3. Raw マニフェストの更新追従（パターン 1）
2. Submodule の更新
• GitHub Repo と対象のディレクトリ
設定ファイル
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

View Slide

3. Raw マニフェストの更新追従（パターン 2）
2. 特定の URL からファイルの取得
downloads/ ディレクトリ配下に保存
./downloads 以下のファイルを対象
• ダウンロード先URL
設定ファイル
namespace: argocd
patches:
- ./patches.yaml
resources:
- ./downloads/install.yaml
kustomization.yaml

View Slide

ؔ࿈͢Δ Argo CD ͷ Tips

View Slide

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

View Slide

1. Kustomize などのバージョン依存問題
Application で指定されたバージョンの Kustomize バイナリはそれぞれ配置する *1
kind: Application
metadata:
name: guestbook
spec:
source:
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.

View Slide

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/

View Slide

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

View Slide

AKE – Kubernetes as a Service ͷ֓ཁ

View Slide

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:
spec:
topology:
version: v1.21.2
controlPlane:
replicas: 3
workers:
machineDeployments:
replicas: 5
kind: Cluster
metadata:
spec:
topology:
version: v1.19.7
controlPlane:
replicas: 3
workers:
machineDeployments:
replicas: 5
管理クラスタ
ユーザークラスタ

View Slide

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

View Slide

GitOps at AKE

View Slide

管理クラスタに対するエコシステムの管理
管理クラスタには、多岐にわたるエコシステムを導⼊
マニフェスト追加後には、別途 “Application” も追加
管理クラスタ
kind: Application
metadata:
name: external-dns
namespace: argocd
spec:
project: default
source:
repoURL: [email protected]: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:
path: manifests/cert-manager/overlays/release
destination:
server: https://kubernetes.default.svc
manifests
├── cert-manager
│ ├── base
│ └── overlays
├── external-dns
│ ├── base
...
ディレクトリ構成の例

View Slide

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

View Slide

Argo CD での複数クラスタ管理と登録
⼀般的には「argocd cluster add」コマンドで追加
※ この構成が GitOps か否かはここでは取り扱いません
kind: Secret
metadata:
name: my-test-cluster
namespace: argocd
labels:
argocd.argoproj.io/secret-type: cluster
stringData:
server: https://10.xxx.xxx.xxx:6443
config: （Argo CD 特有のkubeconfig相当のファイル）
clusterResources: true
type: Opaque
kind: Secret
metadata:
namespace: argocd
labels:
stringData:
type: Opaque
kind: Secret
metadata:
namespace: argocd
labels:
stringData:
server: https://10.0.0.1:6443
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

View Slide

⾃作 Controller による Argo CD へのクラスタの登録
ClusterAPI が発⾏するクラスタの認証情報を元に
Argo CD Clsuter Secret を⽣成
ake-addon-manager (controllers)
reconcile
watch
ClusterAPI resources
管理クラスタ
kind: Secret
metadata:
namespace: argocd
labels:
stringData:
type: Opaque
kind: Secret
metadata:
namespace: argocd
labels:
stringData:
type: Opaque
kind: Secret
metadata:
namespace: argocd
labels:
stringData:
server: https://10.0.0.1:6443
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

View Slide

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:
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:
path: manifests/prometheus
destination:
server: https://10.0.0.1:6443

View Slide

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:
namespace: argocd
spec:
project: amsy
source:
path: manifests/node-autorepair
destination:
kind: Application
metadata:
name: test-cluster-01-cluster-autoscaler
namespace: argocd
spec:
project: amsy
source:
path: manifests/cluster-autoscaler
destination:

View Slide

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:
path: manifests/applications
manifests
├── applications
│ ├── applications.yaml
│ ├── cert-manager.yaml
│ ├── external-dns.yaml
│ └── kustomization.yaml
│ ├── base
│ ├── base
...
いくつかの Application リソース⾃体を Application で管理する（GitOps する）

View Slide

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:
path: manifests/applications
manifests
├── applications
│ ├── applications.yaml
│ ├── cert-manager.yaml
│ ├── external-dns.yaml
│ └── kustomization.yaml
│ ├── base
│ ├── base
...
いくつかの Application リソース⾃体を Application で管理する（GitOps する）
【課題】
エコシステム追加時にほぼ同じ設定値の Application の追加を忘れる
そもそも複数クラスタに対する柔軟な Application の作成は複雑

View Slide

ApplicationSet ʹΑΔॊೈͳ Application ؅ཧ

View Slide

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
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'
kind: Application
metadata:
name: 'test-cluster-2-guestbook'
spec:
source: {...}
destination:
server: 'https://10.0.0.2'

View Slide

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
metadata:
name: guestbook
spec:
generators:
- list:
elements:
url: https://10.0.0.1
url: https://10.0.0.2
template:
metadata:
name: '{{cluster}}-guestbook'
spec:
source: {...}
destination:
server: '{{url}}'

View Slide

Git generator
コンポーネントが追加されるたびに Application の追加が不要に
manifests
│ ├── base
│ ├── base
...
kind: Application
metadata:
name: 'external-dns'
spec:
project: ake
source:
repoURL: [email protected]:xxxxx/xxxxx.git
path: 'manifests/external-dns/overlays/release'
destination: {...}
kind: Application
metadata:
name: 'cert-manager'
spec:
project: ake
source:
path: 'manifests/cert-manager/overlays/release'
destination: {...}
generate
metadata:
name: bootstrap-components
spec:
generators:
- git:
revision: develop
directories:
- path: manifests/*
template:
metadata:
name: ‘{{ path.basename }}'
spec:
project: ake
source:
path: '{{ path }}/overlays/release'
destination: {...}

View Slide

Cluster generator
各サーバーに同⼀のアプリケーションを追加する
e.g. KaaS の各クラスタに Cilium を登録する
kind: Application
metadata:
name: 'cilium-test-cluster-1'
spec:
project: default
source:
repoURL: [email protected]:xxxxx/addons.git
targetRevision: main
path: 'manifests/cilium/overlays/release'
destination:
server: 'https://10.0.0.1:6443'
kind: Application
metadata:
spec:
project: default
source:
destination:
server: 'https://10.0.0.1:6443'
generate
metadata:
name: cilium
spec:
generators:
- clusters: {...}
template:
metadata:
name: 'cilium-{{ name }}'
spec:
project: default
source:
path: manifests/cilium/overlays/release
destination:
server: '{{ server }}'

View Slide

Kubernetes as a Service での課題
✅ 複数クラスタを容易に管理できる
各クラスタの Kubernetes バージョンごとに適切なマニフェストがデプロイできる
v1.19.7
v1.20.5
CSI (A)
v1.21.3
管理クラスタ

View Slide

ブランチ戦略
Kubernetesのマイナーバージョン毎にブランチを⽤意
=> マイナーバージョンごとに利⽤できる機能に差があり、エコシステムのアップグレードに影響があるため
それぞれのブランチにタグを発⾏し、そのタグを Argo CD で参照する
=> ブランチに対して変更を⾏った際にも、ユーザークラスタへの影響がないように
kind: Application
metadata:
name: cert-manager
spec:
source:
path: manifests/cert-manager

View Slide

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

View Slide

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

View Slide

各クラスタの K8s バージョンに
合わせたアドオンのデプロイ
Argo CD Clsuter Secret で
指定された label / annotation の値を展開可能
kind: Application
metadata:
spec:
project: 'my-project'
source:
targetRevision: 'v1.20-ake.211006'
destination: {...}
kind: Application
metadata:
spec:
project: 'amsy0930'
source:
destination: {...}
metadata:
name: cilium
spec:
generators:
- clusters: {...}
template:
metadata:
name: 'cilium-{{ name }}'
spec:
project: '{{ metadata.labels.ake/project }}'
source:
targetRevision: '{{ metadata.labels.ake/version }}'
path: manifests/cilium/overlays/release
destination: {...}
kind: Secret
metadata:
namespace: argocd
labels:
addons.ake/cilium: "true"
ake/project: amsy0930
ake/version: v1.20-ake.211007
stringData:
type: Opaque
※ 実際にはラベル名などは ake.cycloud.io/version などを利⽤しています
kind: Secret
metadata:
namespace: argocd
labels:
ake/project: amsy0930
stringData:
server: https://10.0.0.1:6443
type: Opaque

View Slide

✅ 各クラスタの Kubernetes バージョンごとに適切なマニフェストがデプロイできる
v1.19.7
v1.20.5
CSI (A)
v1.21.3
管理クラスタ

View Slide

各クラスタのごとに利⽤するアドオンの切り替え
Argo CD Clsuter Secret の label / annotation をもとに
Generator で Selector を利⽤する
AKE ではクラウドプロバイダーやその他様々な条件で切り替え（e.g. CCM, CSI）
kind: Application
metadata:
spec:
project: 'amsy0930'
source:
destination: {...}
metadata:
name: cilium
spec:
generators:
- clusters:
selector:
matchExpressions:
- key: addons.ake/cilium
operator: In
values:
- "true"
template: {...}
kind: Secret
metadata:
labels:
stringData: {...}
kind: Secret
metadata:
labels:
addons.ake/cilium: "false"
stringData: {...}

View Slide

（参考）変数展開エラーの緩和
変数展開に利⽤する値は、Selector の条件に含める
ApplicationSet の Templating 部分の実装では、
値が存在しない場合は失敗や空⽩になるのではなく
そのまま Application が作られる＝エラー
kind: Application
metadata:
spec:
source:
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 }}'
kind: Secret
metadata:
labels:
stringData: {...}

View Slide

✅ 各クラスタの Kubernetes バージョンごとに適切なマニフェストがデプロイできる
✅ 各クラスタで利⽤する機能（アドオン、アプリケーション）の Enable/Disable が切り替えられる
v1.19.7
v1.20.5
CSI (A)
v1.21.3
管理クラスタ

View Slide

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

View Slide

【再掲】 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:
namespace: argocd
spec:
project: amsy
source:
path: manifests/my-app
destination:
server: https://10.0.0.2:6443
kind: Application
metadata:
name: test-cluster-01-prometheus
namespace: argocd
spec:
project: amsy
source:
path: manifests/prometheus
destination:
server: https://10.0.0.1:6443

View Slide

【再掲】 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:
namespace: argocd
spec:
project: amsy
source:
path: manifests/node-autorepair
destination:
kind: Application
metadata:
name: test-cluster-01-cluster-autoscaler
namespace: argocd
spec:
project: amsy
source:
path: manifests/cluster-autoscaler
destination:

View Slide

アプリケーションの挙動の変更
ApplicationSet で渡ってくる変数をアプリケーションに渡して挙動を変える⽅法
• e.g. Cluster Autoscaler が対象にするクラスタ名
• e.g. Datadog で利⽤する API Key
Kustomize
外部からパラメータを渡すことができない
（kustomize plugins を⾃作して頑張るという⼿もありそうだが…）
Helm
values を渡して挙動を変えることが可能
クラスタごとにアプリケーションに変更が必要なものは、
Helm の変数展開を利⽤して設定を切り替え
metadata:
name: cluster-autoscaler
spec:
template:
spec:
source:
helm:
parameters:
- name: ake.cluster-name
value: {{ name }}
- name: ake.options.xxx
value: '{{ metadata.annotations.… }}'

View Slide

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

View Slide

·ͱΊ

View Slide

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

View Slide

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

View Slide

Thank you for your attention
Twitter: @amsy810

View Slide

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

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

Masaya Aoyama (@amsy810)

More Decks by Masaya Aoyama (@amsy810)

Other Decks in Technology

Featured

Transcript