Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Kubernetesとともに育てるアプリケーション実行基盤 / cloudnativelounge-01-amsy810

Kubernetesとともに育てるアプリケーション実行基盤 / cloudnativelounge-01-amsy810

青山 真也 氏(@amsy810)

▍発表内容について
このセッションでは、Kubernetes を触り始めた人、これから実務で利用していく人に向けて、Kubernetes をアプリケーション実行基盤として選び、OSS エコシステムによって実行基盤に機能追加を施し育てていく方法について紹介します。

Network や Storage の抽象化に始まり、様々なものが "リソース" として表現されています。 これらの "リソース" は Kubernetes Controller によって管理することができ、様々な Controller が非同期に連携することで自律的なシステムとして動作します。

このセッションの前半では Controller による自動化の仕組みと紹介し、後半では昨今の Kubernetes と連携する OSS エコシステムについて紹介します。

Masaya Aoyama (@amsy810)

June 17, 2021
Tweet

More Decks by Masaya Aoyama (@amsy810)

Other Decks in Programming

Transcript

  1. - Co-chair ੨ࢁ ਅ໵ + CREATIONLINE - 技術アドバイザ + SAKURA

    Internet Research Center – 客員研究員 + 3-shake 技術顧問 + PLAID - Organizer - KaaS Product Owner - Publications Twitter: @amsy810
  2. Kubernetes と「リソース」 Google Borg をベースとしたアプリケーション実⾏基盤 • ローリングアップデート • オートスケール •

    ロードバランサとの⾃動連携(抽象化) • etc 様々なものを「リソース」として扱う リソースを記述したマニフェストを K8s に登録 ReplicaSet リソースを登録
  3. あるべき理想の状態(Desired State)≒ Declarative へと収束する 何か問題が発⽣した場合でも、Controller により セルフヒーリング される ※ 厳密には

    Controller も API を⽤いて変更します。 reconcile( ) { … } 登録 (via API Request) Watch クラスタの状態 コンテナの作成・削除 Controller 登録された時に、ただ起動させるだけではない Kubernetes と Reconciliation Loop
  4. Controller 内では Reconciliation loop(調整ループ)と呼ばれる あるべき状態へと収束させるループ処理 が実⾏されている Kubernetes の内部には様々な Controller と呼ばれるプログラムが動作している

    Observe Diff Act Observe: 現状を確認 Diff: 理想と現実の差分を計算 Act: 差分に対する処理を実施 reconcile( ) { … } Controller Kubernetes と Reconciliation Loop
  5. ReplicaSet Controller の責務は 「指定されたレプリカ数で Pod を維持し続けること」 Observe Diff Act Observe:

    現状を確認 Diff: 理想と現実の差分を計算 Act: 差分に対する処理を実施 クラスタの状態 理想の状態 reconcile( ) { … } Controller 例︓ ReplicaSet Controller の例
  6. 例えば、Pod(コンテナ)を 3 つ起動させる ReplicaSet リソースの場合 Observe Diff Act Observe: 現状を確認

    Diff: 理想と現実の差分を計算 Act: 差分に対する処理を実施 クラスタの状態 理想の状態 reconcile( ) { … } Controller 例︓ ReplicaSet Controller の例
  7. たとえば 2 つしかPod(コンテナ)が起動していない場合… Observe: 理想=3、現状=2 Observe Diff Act Observe: 現状を確認

    Diff: 理想と現実の差分を計算 Act: 差分に対する処理を実施 クラスタの状態 理想の状態 reconcile( ) { … } Controller 例︓ ReplicaSet Controller の例
  8. たとえば 2 つしかPod(コンテナ)が起動していない場合… Diff: 1 つPod(コンテナ)が⾜りない Observe Diff Act Observe:

    現状を確認 Diff: 理想と現実の差分を計算 Act: 差分に対する処理を実施 クラスタの状態 理想の状態 reconcile( ) { … } Controller 例︓ ReplicaSet Controller の例
  9. たとえば 2 つしかPod(コンテナ)が起動していない場合… Act: 1つ nginx:1.16 のPod(コンテナ)を作成する Observe Diff Act

    Observe: 現状を確認 Diff: 理想と現実の差分を計算 Act: 差分に対する処理を実施 クラスタの状態 理想の状態 reconcile( ) { … } Controller 例︓ ReplicaSet Controller の例
  10. 起動したPod(コンテナ)には ラベル が付与されている Kubernetes や周辺エコシステムでは ラベルを元に様々な処理を⾏う apiVersion: apps/v1 kind: Deployment

    metadata: name: sample-deployment spec: replicas: 3 template: metadata: labels: {app: a} spec: containers: - name: app-container image: app:A app: a app: a app: a 例︓ロードバランサとの連携の例
  11. ⾃動的に LoadBalancer を作成し、⾃動的に連携を⾏う • コンテナやノードの追加時にも⾃動的にメンバ更新 • ローリングアップデート時のメンバ管理 apiVersion: v1 kind:

    Service metadata: name: sample-svc spec: type: LoadBalancer ports: - name: "http-port" protocol: "TCP" port: 8080 targetPort: 80 selector: app: a app: a app: a app: a LB app: a 例︓ロードバランサとの連携の例 reconcile( ) { … } Controller
  12. Reconciliation Loop のまとめ ⼈が考えること(運⽤ロジック)をプログラムに落とし込んで⾃動化する = 運⽤を Kubernetes に任せることができる 多くの状態は Kubernetes

    に保存されている ため、API 経由で確認可能 外部システムを観測するものも状態を Kubernetes に保存 運⽤者 ReplicaSet の監視(watch) Pod の制御 (create / delete / patch) via API ReplicaSet の設定を見ておき 、 指定されたレプリカ数で Podを維持する
  13. Reconciliation Loop のまとめ ⼈が考えること(運⽤ロジック)をプログラムに落とし込んで⾃動化する = 運⽤を Kubernetes に任せることができる 多くの状態は Kubernetes

    に保存されている ため、API 経由で確認可能 外部システムを観測するものも状態を Kubernetes に保存 reconcile( ) { … } Controller ReplicaSet の監視(watch) Pod の制御 (create / delete / patch) via API 運⽤のコード化 ReplicaSet の設定を見ておき 、 指定されたレプリカ数で Podを維持する
  14. Kubernetes の構成要素 Kubernetes では⾮常に沢⼭の Controller が動いている • ReplicaSet Controller •

    Deployment Controller • Ingress Controller • Node Controller • Scheduler • etc. これらの Controller が⾮同期に動作することで ⼀つの分散システムとして成り⽴っている reconcile( ) { … } Controller reconcile( ) { … } Controller reconcile( ) { … } Controller reconcile( ) { … } Controller reconcile( ) { … } Controller 実際の状態 理想の状態 watch
  15. Controller による運⽤の⾃動化パターン(1/3) 1.⼀般的な運⽤⾃動化ロジック • 社内に伝わる秘伝の闇の運⽤スクリプトを駆逐 • Kubernetes-way な統⼀化された⽅法 • Reconciliation

    モデルにより「運⽤」のロジック化に適している • 汎化した形で実装し、オープンソースのエコシステムとして共有 例) リポジトリのマニフェストを Kubernetes に apply する︓ArgoCD 払い出されたロードバランサの IP アドレスを DNS に登録する︓ExternalDNS Issuer から証明書を発⾏して Secret として登録する︓Cert Manager コンテナのリソースの使⽤率から⾃動的にリソース割当を変える︓VerticalPodAutoscaler
  16. ExternalDNS – 払い出された IP アドレスを DNS へ ロードバランサーを⾃動的に払い出す機能は Kubernetes や

    IaaS に存在する 払い出された IP アドレスを DNS に登録するのは運⽤者の仕事 LB 203.0.113.1 DNS 運⽤者 1. 払い出された IP アドレスの確認 2. 登録するドメイン名の確認 3. 外部の DNS に対して登録処理を⾏う 203.0.113.1 = svc.example.com
  17. ExternalDNS – 払い出された IP アドレスを DNS へ ロードバランサーを⾃動的に払い出す機能は Kubernetes や

    IaaS に存在する 払い出された IP アドレスを DNS に登録するのは運⽤者の仕事 払い出された IP アドレスや登録するドメイン名などは Kubernetes が保持している LB 203.0.113.1 DNS Controller 1. 払い出された IP アドレスの確認 2. 登録するドメイン名の確認 3. 外部の DNS に対して登録処理を⾏う ExternalDNS Controller 203.0.113.1 = svc.example.com
  18. Cert-manager HTTPS で利⽤する証明書を取得するのは、運⽤者の仕事 IP Address を DNS に登録することに⽐べると、より複雑な処理が多い LB svc.example.com

    = 203.0.113.1 Letʼs Encrypt ドメイン名の確認 証明書リクエストの作成 ACME HTTP or DNS Challenge の実施 証明書ファイルの作成 DNS 運⽤者
  19. Cert-manager HTTPS で利⽤する証明書を取得するのは、運⽤者の仕事 IP Address を DNS に登録することに⽐べると、より複雑な処理が多い LB svc.example.com

    = 203.0.113.1 Letʼs Encrypt Controller ドメイン名の確認 証明書リクエストの作成 ACME HTTP or DNS Challenge の実施 証明書ファイルの作成 Cert-manager Controller DNS
  20. Controller による運⽤の⾃動化パターン(2/3) 2.ステートフルなミドルウェアを運⽤する Controller がつくられる Databaseなどの運⽤を任せられる時代に。 Message Queue/KVS に関しては近いうちに現実的に (個⼈的にステートを持つ

    Computing リソースの延⻑に感じている) ステートフルなミドルウェアが進まない理由 • Podのライフサイクルに適応できるものが少ない • 現状はクラスタ間のボリューム移⾏が得意ではない
  21. Controller による運⽤の⾃動化パターン(2/3) Kubernetes は ⼩さなクラウド に近い Message Queue Key Value

    Store Document DB Relational DB Developer ステートフルなもの以外にも ML、Serverless、バッチJobなど 様々なものを Kubernetes 上で提供する エコシステムが発達
  22. Controller による運⽤の⾃動化パターン(3/3) Computing Computing 定期的な運⽤が必要 3.外部システムを制御・運⽤するための仕組み • Reconcile を踏襲した管理 •

    e.g. Config Connector︓ GCP リソースの制御 既存の問題点 1.クラウドリソースが適切な状態か判別できない Terraformなどは構築ツール的 2.管理系が複数に分かれている 認証情報等はどうするか
  23. Controller による運⽤の⾃動化パターン(3/3) KVS DB Computing Computing KVS (meta) DB (meta)

    3.外部システムを制御・運⽤するための仕組み • Reconcile を踏襲した管理 • e.g. Config Connector︓ GCP リソースの制御 既存の問題点 1.クラウドリソースが適切な状態か判別できない Terraformなどは構築ツール的 => Controller 内ロジックにより担保 2.管理系が複数に分かれている 認証情報等はどうするか => Secret リソースとして⾃動展開し アプリから利⽤可能に(CCに機能的にあるか不明) 定期的な運⽤
  24. 運⽤オペレーションのプログラム化 運⽤オペレーションの挙動 = Reconcile() 関数の処理内容(+CustomResource による設定値) 考慮すべき点 様々なタイミングで複数回実⾏されるため、冪等性が担保されていること 複雑な処理の場合は物事の関⼼事を分離し、個別のオペレーションに分割すること (OSS

    の実装などを参考にすると良い) ※ 今回は紹介しないがその他の有効な⼿段 • client-go と CronJob を利⽤する • フレームワークを利⽤して Build-in Resource を扱う • 追加の Annotations を付与して設定値として利⽤する • etc Observe Diff Act
  25. ReplicaSet の Reconcile() 関数の例(擬似) RS=$(kubectl -n NAMESPACE get rs NAME

    -o json) FPods=$(kubectl get pods -l SELECTOR | wc -l) DIFF=$(( $FPods – RS.SPEC.REPLICAS )) if $FPods -lt 0; then kubectl -n NAMESPACE create pod –f RS.SPEC.TEMPLATE else if $FPods –gt 0; then kubectl -n NAMESPACE delete pods TARGET_POD fi rs, err := rsc.rsLister.ReplicaSets(namespace).Get(name) allPods, err := rsc.podLister.Pods(rs.Namespace).List(labels.Everything()) filteredPods := controller.FilterActivePods(allPods) filteredPods, err = rsc.claimPods(rs, selector, filteredPods) diff := len(filteredPods) - int(*(rs.Spec.Replicas)) if diff < 0 { rsc.podControl.CreatePodsWithControllerRef( rs.Namespace, &rs.Spec.Template, ... ) } else if diff > 0 { rsc.podControl.DeletePod(rs.Namespace, targetPod.Name, rs) } https://github.com/kubernetes/kubernetes/blob/release-1.21/pkg/controller/replicaset/replica_set.go より改変して抜粋 Observe Diff Act
  26. PersistentVolumeClaim 作成時にアノテーションを付与することで S3 / GCS からデータをロード 後述のクラウド向け認証情報を利⽤することで、Private Bucket のロードも可能 1.

    PVC にデータをロードする Job の作成 2. PVC の .status.conditions で状態管理 (type = Loading を拡張して追加) 課題︓.status.conditions が特に使われておらず、 ロード完了前にも PVC の attach が⾏われてしまう 機械学習の元データを効率的に扱えるように、 Volume Snapshot との連携も検討中 ※ その他にも 元データを変更されないように ReadOnly なマウントなど、いくつかの機能も実装 ML 基盤での Controller の例
  27. クラウド向けの認証情報⽤に Secret の type を拡張 (Validating webhook で検証) • type:

    gcp-credential • type: aws-credential クラウド向けの認証情報を⾃動マウント (Mutating webhook で挿⼊) • Pod のアノテーションに指定 • ServiceAccount への紐付け ML 基盤での Controller Webhook による拡張の例
  28. PersistentVolumeClaim 作成時にアノテーションを付与することで S3 / GCS からデータをロード 前述のクラウド向け認証情報を利⽤することで、Private Bucket のロードも可能 1.

    PVC にデータをロードする Job の作成 2. PVC の .status.conditions で状態管理 (type = Loading を拡張して追加) 課題︓.status.conditions が特に使われておらず、 ロード完了前にも PVC の attach が⾏われてしまう 機械学習の元データを効率的に扱えるように、 Volume Snapshot との連携も検討中 ※ その他にも 元データを変更されないように ReadOnly なマウントなど、いくつかの機能も実装 ML 基盤での Controller の例 Ref: https://event.cloudnativedays.jp/cndo2021/talks/451
  29. ExternalDNS は Service / Ingress / HTTPProxy (Contour) など、 ロードバランサ作成時に紐付けられる

    IP アドレスを DNS に⾃動的に連携する DNSEndpoint CustomResource を使うと、 静的な DNS レコードの管理も可能 デフォルトでは利⽤できないので、下記の設定が必要 1.DNSEndpoint CRD の追加 2.External DNS の起動オプションの追加 (--source=crd --crd-source-apiversion=externaldns.k8s.io/v1alpha1 --crd-source-kind=DNSEndpoint) ExternalDNS
  30. Prometheus / Grafana などのコンポーネント それらで利⽤する Alert / Dashboard などを Code

    で管理可能 kube-prometheus を利⽤している場合、 Grafana に関する部分は delete patch を当てて利⽤すること Grafana Operator はまだ少しバグが多い (e.g. default storageclass が利⽤できない、replicas field が効かない) Prometheus Operator / Grafana Operator
  31. 外部の Secret Manager と連携した Secret 管理 • クラスタ移設が容易に • マルチクラスタ・マルチクラウド環境でも利⽤可能

    • VM 環境と Kubernetes 環境での共存も容易 2020年末頃から CRD の⾒直しなどもしつつ Golang ベースに再実装中 External Secrets Ref: https://github.com/external-secrets/kubernetes-external-secrets/issues/554#issuecomment-728984416
  32. ArgoCD 2.0 • Pod view • ArgoCD notifications Argo Rollouts

    • Progressive delivery 様々な拡張性 • 各リソースの health check を Lua を使って定義・上書き可能 Argo Family