CyberAgentにおけるKubernetes as a Serviceの歩みと利用者を支える機能 / cainfra01-amsy810-kubernetes

CyberAgentにおけるKubernetes as a Serviceの歩みと利用者を支える機能

青山 真也 / 株式会社サイバーエージェント
Kaas Product Owner / Software Engineer

CyberAgentのKaaSは、OpenStack Heatを用いたオーケストレーションから、Cluster APIベースのシステムへと移設しました。 これにより、クラスタ管理などにおいてもKubernetes Controllerをベースとしたアーキテクチャが容易となりました。 本セッションでは、現在の弊社のKaaSのアーキテクチャや、その上で動作するKubernetes利用者向けの各種Platformの機能について紹介します。

Transcript

1. Masaya Aoyama CyberAgent CyberAgentʹ͓͚ΔKubernetes as a ServiceͷาΈͱ ར༻ऀΛࢧ͑Δػೳ CA.infra #1 amsy810 @amsy810
2. - Co-chair ੨ࢁ ਅ໵ + CREATIONLINE - 技術アドバイザ + SAKURA Internet Research Center – 客員研究員 + 3-shake 技術顧問 + PLAID - Organizer - KaaS Product Owner - Publications Twitter: @amsy810
3. Agenda • CyberAgent ͷϓϥΠϕʔτΫϥ΢υͱAKE • AKE ʹ͓͚ΔΫϥελͷΦʔέετϨʔγϣϯ • Workload ΫϥελͱΫϥ΢υϓϩόΠμͷ࿈ܞ • AKE ʹ͓͚ΔΞυΦϯ؅ཧͱࣗಈԽ • AKE ͕໨ࢦ͢ੈք؍ͱͦΕΛࢧ͑Δػೳ
4. CyberAgent ͷϓϥΠϕʔτΫϥ΢υͱAKE
5. CyberAgent のプライベートクラウド CyberAgent には もともと事業領域ごとに、2 つのプライベートクラウド環境が存在 2021年ごろに合併し、 CIU（CyberAgent group Infrastructure Unit）へ AI・広告事業側 プライベートクラウド （OpenStack ベース） メディア・ゲーム事業側 プライベートクラウド （OpenStack ベース）
6. KaaS / ML Platform 開発チーム
7. AKE の歴史
8. AKE ʹ͓͚ΔΫϥελͷΦʔέετϨʔγϣϯ
9. AKE におけるクラスタの管理 クラスタ アップグレード AKE Cluster API Provider （cluster-api-provider-openstack based） & AKE Cluster Manager クラスタ オートスケール AKE Cluster Autoscaler (cloudprovider/clusterapi based) ノード オートヒーリング AKE Node Autorepair
10. AKE におけるクラスタの管理 クラスタ アップグレード AKE Cluster API Provider （cluster-api-provider-openstack based） & AKE Cluster Manager クラスタ オートスケール AKE Cluster Autoscaler (cloudprovider/clusterapi based) ノード オートヒーリング AKE Node Autorepair
11. クラスタの管理: AKE Cluster API Provider
12. クラスタのライフサイクル管理: AKE Cluster Manager • 更新処理の同時実⾏制御、 • ノード構成のアップデート（インスタンスタイプ・ ストレージ・AZ・ノード数・etc） • Kubernetes バージョンのアップグレード • AKE バージョンのアップグレード（アドオンのアップグレード） • 更新失敗時のロールバック • 利⽤可能なバージョンの制御 • クラスタステータスのメトリクス公開 • 課⾦情報の⽣成 • (故障予兆ノードの退避) sum(ake_controlplane_status{}) by (status, cluster_name)
13. AKE におけるクラスタの管理 クラスタ アップグレード AKE Cluster API Provider （cluster-api-provider-openstack based） & AKE Cluster Manager クラスタ オートスケール AKE Cluster Autoscaler (cloudprovider/clusterapi based) ノード オートヒーリング AKE Node Autorepair
14. クラスタのオートスケール: AKE Cluster Autoscaler • 基本的には Cluster API ⽤の Cluster Autoscaler を利⽤ • https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler/cloudprovider/clusterapi • gRPC Expander を利⽤して、独⾃のロジックを差し込み https://static.sched.com/hosted_files/kccnceu2022 /13/KubeCon%20EU%202022%20- %20SIG%20Autoscaling%20%282%29.pdf Hypervisor の在庫を考慮した Anti-affinity の可否の確認 コアが空いているゾーンへの 優先的なスケジューリング
15. AKE におけるクラスタの管理 クラスタ アップグレード AKE Cluster API Provider （cluster-api-provider-openstack based） & AKE Cluster Manager クラスタ オートスケール AKE Cluster Autoscaler (cloudprovider/clusterapi based) ノード オートヒーリング AKE Node Autorepair
16. ノードの⾃動復旧: AKE Node Autorepair • コンテナランタイム、kubelet の問題発⽣時 => アプリケーションの再起動 • GKE でも利⽤されているスクリプトを利⽤ • https://github.com/kubernetes/kubernetes/blob/master/cluster/gce/gci/health-monitor.sh • ⼀定時間 NotReady が継続 => OSの再起動 • tmpfs で overlay を⾏い、再起動でディスク領域の初期化も⾏う https://www.slideshare.net/h-otter/kubernetes-1-250593952
17. Workload Cluster ͱΫϥ΢υϓϩόΠμͷ࿈ܞ
18. Workload Cluster とクラウドプロバイダの連携 “type: LoadBalancer” Service Ingress Cycloud SLB Ingress Controller CSI Driver Cinder CSI Driver （cloud-provider-openstack/pkg/csi/cinder original） Cloud Provider Cycloud （cloud-provider-openstack based） Cloud Provider Izanami （cloud-provider-openstack based） ＆ Auth Cycloud IAM integration
19. AKE ʹ͓͚ΔΞυΦϯ؅ཧͱࣗಈԽ
20. ユーザークラスタ郡に対するエコシステムの管理 管理クラスタ上にデプロイ 管理クラスタ ユーザークラスタ 「ユーザー側では直接利⽤しないもの」 「KaaS としての⾃動管理系の機能」 などで利⽤ e.g. Cluster Autoscaler 管理クラスタからユーザクラスタの状態を監視し、スケールが必要になったらスケールアウト e.g. Node Auto Repair 管理クラスタから、ユーザークラスタのノードの状態を確認し、問題が⽣じたら修復 ユーザー向けクラスタ上にデプロイ 管理クラスタ ユーザークラスタ 「ユーザが直接利⽤する必要があるもの」 「ユーザクラスタ上の情報が必要なもの」 などで利⽤ e.g. Cert Manager CRD を含む⼀式をデプロイし、ユーザーの Ingress などで証明書が利⽤できるように e.g. Prometheus / Exporter 類 ユーザのクラスタ上でメトリクスを収集する（管理クラスタへ集約）
21. 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
22. ⾃作 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
23. 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 か否かはここでは取り扱いません
24. 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 namespace: someproject 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 namespace: amsy ※ この構成が GitOps か否かはここでは取り扱いません
25. Argo CD ApplicationSet (Cluster generator) Argo CD の拡張機能の ApplicationSet を利⽤して、 Argo CD 管理下の各サーバーに同⼀のアプリケーションを追加 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 }}' e.g. KaaS の各クラスタに Cilium を登録する
26. ブランチ戦略 • 新たな Kubernetes マイナーバージョンが出るたびに main ブランチから切り出す • 変更は main ブランチに⾏い、各ブランチには⾃動的に cherry-pick（実際には PR） • リリースを⾏うタイミングで各ブランチで tag を発⾏
27. 各クラスタの 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
28. 各クラスタのごとに利⽤するアドオンの切り替え 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: {...}
29. Kubernetes マニフェストの⾃動更新の⽬指す形 Config リポジトリに対して、各エコシステムに対する ⾃動的なアップグレードのPRと変更差分の表⽰ Config Repo manifest manifest
30. 【参考】 アドオンの管理、⾃動更新周りについての詳細は… https://speakerdeck.com/masayaaoyama/cndt2021-amsy810
31. AKE ͕໨ࢦ͢ੈք؍ͱͦΕΛࢧ͑Δػೳ
32. Kubernetes 運⽤の課題と AKE が⽬指す世界観 Cloud Native ではサービスアプリケーションを進化させ続けることが注⽬されがち… Kubernetes / Platform 側も塩漬けせずに進化させ続けるべき CloudNative / Kubernetes はキャッチアップが⼤変 「適切に扱うためのベストプラクティス」 「広がり続けるエコシステム」を提供 CloudNative / Kubernetes は運⽤が⼤変 「CI/CDなどで組み込む必要があった機能」 「コンサルが改善提案する内容」なども Platform 側で提供
33. Observability を実現する環境 管理クラスタ ユーザークラスタ ユーザークラスタ M etrics Metrics Promtail Promtail Log Log Datasource Datasource Datasource Datasource proxy テナント A テナント B prometheus-community/prom-label-proxy を利⽤して Project ラベルを元にテナント分離 Dashboard Alerting Dashboard Alerting AKE 利⽤ユーザの監視基盤としては Grafana Alerting を提供 ※ 別途 Datadog のアドオンも提供 Datasource Alertmanager AKE利⽤者 AKE利⽤者 AKEチーム Alerting ダッシュボード ⼀般的なアラートなども提供
34. Kubernetes 利⽤の最適化・改善⽀援 余剰権限 の検知と通知（In progress） 余剰リソース の検知と通知 ⾮推奨・廃⽌ API の検知と通知 監査ログと Role/RoleBinding を元に不要な権限を算出し、通知を⾏う VPA を利⽤して Requests / Limits の改善提案を⾏う ユーザーはワークロードをデプロイするだけで、⾃動的に最適 なリソース設定の取得・適⽤までを⾏うことが可能 ⾮推奨 API ⽤の Constraints の .status.violations を利⽤し、 現在の Kubernetes version で⾮推奨なリソースの洗い出し
35. CyberAgent 横断での Gatekeeper Policy 合計 63 個のポリシーを実装 順次 さまざまな Kubernetes への導⼊推進へ 導⼊を始めやすい提供⽅法 • Namespace 単位の Opt-in • リソース単位の Opt-out
36. ORAS による Constraint の OCI Image 化 Conftest の代わりに gator test コマンドを利⽤（実際は kustomize/helm 対応のためラッパーツールを提供） ConstraintTemplate / Constraint を OCI Image として保存して提供 ユーザーの任意のポリシーも組み合わせ可能 https://open-policy-agent.github.io/gatekeeper/website/docs/gator/#bundling-policy-into-oci-artifacts ConstraintTemplate / Constraint ConstraintTemplate / Constraint ConstraintTemplate / Constraint Git Repository apply Pull Request ConstraintTemplate / Constraint ConstraintTemplate / Constraint ConstraintTemplate / Constraint OCI Image 化したポリシー群 $ gator test --image policy:v0.1
37. その他の OSS の利⽤・提供 SBOM / 脆弱性スキャンの提供 Cisco 発の OpenClarity プロジェクトの kubeclarity を利⽤ • Syft: SBOM の⽣成 • Grype: SBOM を元にした脆弱性スキャン [特徴1] クラスタ上で動作しているコンテナイメージを対象にスキャン [特徴2] クラスタ上で起動しているコンテナを対象にした検索も可能 Cilium CNI の提供（In-progress） 現在は Calico CNI を利⽤ 期待していること • ebpf / DSR 構成による レイテンシ削減 • DSR 構成による ClientIP の保持 • 可観測性の向上 • より柔軟な Network Policy • 将来的な eBPF-based Service mesh 参考: https://amsy810.hateblo.jp/entry/2022/12/02/122209 ⾼機能化 アドテク領域に おけるメリット
38. ·ͱΊ
39. まとめ AKE は約 6 年に渡って稼働し、OpenStack Heat > Clsuter API へ 少⼈数で効率的に運⽤するために、ソフトウェアによる⾃律化を推進 ⻑年の Kubernetes 運⽤の経験から、 ユーザーが負担と感じる運⽤や実装、 進化し続けるベストプラクティスを AKE チームが提供 アプリケーションだけではなく、進化し続ける Platform へ
40. We are hiring ! • Kubernetes クラスタの⾼度な運⽤⾃動化 with CustomController • ユーザクラスタに対するセキュリティ・SRE ⽀援機能 • 機械学習 × 運⽤⽀援 • , and many more… ご相談は下記までお気軽にどうぞ Twitter: @amsy810 E-mail: aoyama_masaya_xa@cyberagent.co.jp
41. 学⽣向けイベント
42. Thank you for your attention Twitter: @amsy810