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
   

   View Slide

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

   View Slide

3. Agenda
   • CyberAgent ͷϓϥΠϕʔτΫϥ΢υͱAKE
   • AKE ʹ͓͚ΔΫϥελͷΦʔέετϨʔγϣϯ
   • Workload ΫϥελͱΫϥ΢υϓϩόΠμͷ࿈ܞ
   • AKE ʹ͓͚ΔΞυΦϯ؅ཧͱࣗಈԽ
   • AKE ͕໨ࢦ͢ੈք؍ͱͦΕΛࢧ͑Δػೳ
   

   View Slide

4. CyberAgent ͷϓϥΠϕʔτΫϥ΢υͱAKE
   

   View Slide

5. CyberAgent のプライベートクラウド
   CyberAgent には もともと事業領域ごとに、2 つのプライベートクラウド環境が存在
   2021年ごろに合併し、 CIU（CyberAgent group Infrastructure Unit）へ
   AI・広告事業側
   プライベートクラウド
   （OpenStack ベース）
   メディア・ゲーム事業側
   プライベートクラウド
   （OpenStack ベース）
   

   View Slide

6. KaaS / ML Platform 開発チーム
   

   View Slide

7. AKE の歴史
   

   View Slide

8. AKE ʹ͓͚ΔΫϥελͷΦʔέετϨʔγϣϯ
   

   View Slide

9. AKE におけるクラスタの管理
   クラスタ
   アップグレード
   AKE Cluster API Provider
   （cluster-api-provider-openstack based）
   &
   AKE Cluster Manager
   クラスタ
   オートスケール
   AKE Cluster Autoscaler
   (cloudprovider/clusterapi based)
   ノード
   オートヒーリング
   AKE Node Autorepair
   

   View Slide

10. AKE におけるクラスタの管理
    クラスタ
    アップグレード
    AKE Cluster API Provider
    （cluster-api-provider-openstack based）
    &
    AKE Cluster Manager
    クラスタ
    オートスケール
    AKE Cluster Autoscaler
    (cloudprovider/clusterapi based)
    ノード
    オートヒーリング
    AKE Node Autorepair
    

    View Slide

11. クラスタの管理: AKE Cluster API Provider
    

    View Slide

12. クラスタのライフサイクル管理: AKE Cluster Manager
    • 更新処理の同時実⾏制御、
    • ノード構成のアップデート（インスタンスタイプ・ ストレージ・AZ・ノード数・etc）
    • Kubernetes バージョンのアップグレード
    • AKE バージョンのアップグレード（アドオンのアップグレード）
    • 更新失敗時のロールバック
    • 利⽤可能なバージョンの制御
    • クラスタステータスのメトリクス公開
    • 課⾦情報の⽣成
    • (故障予兆ノードの退避)
    sum(ake_controlplane_status{})
    by (status, cluster_name)
    

    View Slide

13. AKE におけるクラスタの管理
    クラスタ
    アップグレード
    AKE Cluster API Provider
    （cluster-api-provider-openstack based）
    &
    AKE Cluster Manager
    クラスタ
    オートスケール
    AKE Cluster Autoscaler
    (cloudprovider/clusterapi based)
    ノード
    オートヒーリング
    AKE Node Autorepair
    

    View Slide

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 の可否の確認
    コアが空いているゾーンへの
    優先的なスケジューリング
    

    View Slide

15. AKE におけるクラスタの管理
    クラスタ
    アップグレード
    AKE Cluster API Provider
    （cluster-api-provider-openstack based）
    &
    AKE Cluster Manager
    クラスタ
    オートスケール
    AKE Cluster Autoscaler
    (cloudprovider/clusterapi based)
    ノード
    オートヒーリング
    AKE Node Autorepair
    

    View Slide

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
    

    View Slide

17. Workload Cluster ͱΫϥ΢υϓϩόΠμͷ࿈ܞ
    

    View Slide

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
    

    View Slide

19. AKE ʹ͓͚ΔΞυΦϯ؅ཧͱࣗಈԽ
    

    View Slide

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

    View Slide

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
    

    View Slide

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
    

    View Slide

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

    View Slide

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

    View Slide

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 を登録する
    

    View Slide

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

    View Slide

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
    

    View Slide

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: {...}
    

    View Slide

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

    View Slide

30. 【参考】 アドオンの管理、⾃動更新周りについての詳細は…
    https://speakerdeck.com/masayaaoyama/cndt2021-amsy810
    

    View Slide

31. AKE ͕໨ࢦ͢ੈք؍ͱͦΕΛࢧ͑Δػೳ
    

    View Slide

32. Kubernetes 運⽤の課題と AKE が⽬指す世界観
    Cloud Native ではサービスアプリケーションを進化させ続けることが注⽬されがち…
    Kubernetes / Platform 側も塩漬けせずに進化させ続けるべき
    CloudNative / Kubernetes はキャッチアップが⼤変
    「適切に扱うためのベストプラクティス」 「広がり続けるエコシステム」を提供
    CloudNative / Kubernetes は運⽤が⼤変
    「CI/CDなどで組み込む必要があった機能」 「コンサルが改善提案する内容」なども Platform 側で提供
    

    View Slide

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
    ダッシュボード
    ⼀般的なアラートなども提供
    

    View Slide

34. Kubernetes 利⽤の最適化・改善⽀援
    余剰権限 の検知と通知（In progress）
    余剰リソース の検知と通知 ⾮推奨・廃⽌ API の検知と通知
    監査ログと Role/RoleBinding を元に不要な権限を算出し、通知を⾏う
    VPA を利⽤して Requests / Limits の改善提案を⾏う
    ユーザーはワークロードをデプロイするだけで、⾃動的に最適
    なリソース設定の取得・適⽤までを⾏うことが可能
    ⾮推奨 API ⽤の Constraints の .status.violations を利⽤し、
    現在の Kubernetes version で⾮推奨なリソースの洗い出し
    

    View Slide

35. CyberAgent 横断での Gatekeeper Policy
    合計 63 個のポリシーを実装
    順次 さまざまな Kubernetes への導⼊推進へ
    導⼊を始めやすい提供⽅法
    • Namespace 単位の Opt-in
    • リソース単位の Opt-out
    

    View Slide

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
    

    View Slide

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
    ⾼機能化
    アドテク領域に
    おけるメリット
    

    View Slide

38. ·ͱΊ
    

    View Slide

39. まとめ
    AKE は約 6 年に渡って稼働し、OpenStack Heat > Clsuter API へ
    少⼈数で効率的に運⽤するために、ソフトウェアによる⾃律化を推進
    ⻑年の Kubernetes 運⽤の経験から、
    ユーザーが負担と感じる運⽤や実装、
    進化し続けるベストプラクティスを AKE チームが提供
    アプリケーションだけではなく、進化し続ける Platform へ
    

    View Slide

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

    View Slide

41. 学⽣向けイベント
    

    View Slide

42. Thank you for your attention
    Twitter: @amsy810
    

    View Slide