$30 off During Our Annual Pro Sale. View Details »

Kubernetesのススメ(サイバーエージェント新卒研修2024)

 Kubernetesのススメ(サイバーエージェント新卒研修2024)

CyberAgent

June 05, 2024
Tweet

More Decks by CyberAgent

Other Decks in Technology

Transcript

  1. 自己紹介 木村 洸太 - Kota Kimura • 株式会社サイバーエージェント グループIT推進本部 CIU

    Development Division 所属 2023年5月中途入社 • KaaS プロダクト AKE の開発・運用を担当 • 趣味はサウナ巡り
  2. → 作業ミスや差分が生まれやすい 必要なリソースが増えてくると 作業に限界が.... VM の場合 (インフラのコード化なし) 8 ssh Server

    OS Hypervisor Guest OS Library Library Application 仮想サーバ Server OS Hypervisor Guest OS Library Library Application 仮想サーバ VM を手動構築し直接 ssh して、アプリのデプロイなどの諸々を手動作業
  3. VM の場合 (インフラのコード化あり) 9 大規模インフラを管理するために Infrastructure as Code (IaC) といった技術が普及

    e.g. Terraform などで VM を起動し、Ansible などでセットアップを行い、Jenkins などでアプリのデプロイを行う ツールによっては実行時タイミングよって 同一環境になることが保証されない Server OS Hypervisor Guest OS Library Library Application 仮想サーバ Server OS Hypervisor Guest OS Library Library Application 仮想サーバ 環境差分
  4. コンテナ の場合 10 Server OS Container Runtime Library Library Application

    コンテナ Server OS Container Runtime Library Library Application コンテナ Docker Image Build Once, Run Anywhere FROM golang:1.21 AS builder WORKDIR /app COPY go.mod go.sum ./ …. RUN go build -o main /app/main.go FROM gcr.io/distroless/static:nonroot COPY --from=builder /app/main . EXPOSE 8080 CMD ["/app/main"] Dockerfile Dockerfile でコンテナイメージのビルドを行い、コンテナランタイム上で コンテナイメージを取得し実行
  5. コンテナ の場合 11 Server OS Container Runtime Library Library Application

    コンテナ Server OS Container Runtime Library Library Application コンテナ Dockerfile でコンテナイメージのビルドを行い、コンテナランタイム上で コンテナイメージを取得し実行 • 同一環境になることが保証される • docker でビルドから起動まで可能 ◦ 開発者(Dev) 側が関わりやすい
  6. では、コンテナのアプリケーションを運用するのは簡単? 14 アプリケーションをコンテナ化する上で、沢山のことを考えなくてはいけない 1. アプリケーションコンテナが落ちてしまった場合のリカバリはどうするか? 2. リソースが足りなくなった時の マシン のスケールアウトはどうするか 3.

    逆にリソース過多でスケールインさせたい場合はどうするか? 4. コンテナに割り振る IP アドレスはどうやって管理するか 5. コンテナ間のサービスディスカバリはどうするか 6. 複数のコンテナへのロードバランシングはどうするか 7. コンテナに依存しない永続化したデータはどうやって管理するか などなど、人類は欲深いのでこれら全てを解決できるソリューションを求めていました
  7. Reconciliation Loop 17 あるべき理想の状態 (Desired State) を宣言的に定義 Controller によって理想の状態へと収束するように振る舞う e.g.

    何か問題が発生した場合でも、Controller によってセルフヒーリングされる 登録 (via API Request) watch コンテナの作成・削除 登録時にただ起動させるだけではない! Controller
  8. Reconciliation Loop 18 Controller 内では、Reconciliation loop (調整ループ) と呼ばれる あるべき状態へと収束させるループ処理が実行されている Kubernetes

    の内部には様々な Controller と呼ばれるプログラムが動作している Observe: 現状の確認 Diff: 理想と現状の差分を計算 Act: 差分に対する処理を実施
  9. Reconciliation Loop 19 e.g. ReplicaSet Controller の場合 ReplicaSet Controller の責務は

    「指定されたレプリカ数で Pod を維持し続けること」 ※ Pod は 複数のコンテナをまとめた Kubernetes における最小単位 Observe: 現状の確認 Diff: 理想と現状の差分を計算 Act: 差分に対する処理を実施
  10. Reconciliation Loop 20 e.g. ReplicaSet Controller の場合 コンテナ (Pod) を3つ起動させるReplicaSet

    リソースの場合 Observe: 現状の確認 Diff: 理想と現状の差分を計算 Act: 差分に対する処理を実施
  11. Reconciliation Loop 21 e.g. ReplicaSet Controller の場合 2つしかコンテナ (Pod) が起動していない場合...

    Observe: 理想=3、現状=2 Observe: 現状の確認 Diff: 理想と現状の差分を計算 Act: 差分に対する処理を実施
  12. Reconciliation Loop 22 e.g. ReplicaSet Controller の場合 2つしかコンテナ (Pod) が起動していない場合...

    Diff: 1つコンテナ (Pod) が足りない Observe: 現状の確認 Diff: 理想と現状の差分を計算 Act: 差分に対する処理を実施
  13. Reconciliation Loop 23 e.g. ReplicaSet Controller の場合 2つしかコンテナ (Pod) が起動していない場合...

    Act: 1つ nginx:1.16 のコンテナ (Pod) を作成する Observe: 現状の確認 Diff: 理想と現状の差分を計算 Act: 差分に対する処理を実施
  14. Kubernetes の構成要素 24 Kubernetes では非常に多くの Controller が動いている • ReplicaSet Controller

    • Deployment Controller • Ingress Controller • Node Controller • Scheduler • etc... これらの Controller が非同期に動作することで、 1つの分散システムとして成り立っている
  15. Reconciliation Loop 25 Reconciliation Loop のまとめ リソースあるべき理想の状態を構造化データで宣言的に定義することで Controller の Reconciliation

    Loop によって、理想の状態へ収束する → 人が考えること (運用ロジック) をプログラムで落とし込んで自動化できる = 運用を Kubernetes に任せることができる 1. アプリケーションコンテナが落ちてしまった場合のリカバリはどうするか? 2. リソースが足りなくなった時の マシン のスケールアウトはどうするか 3. 逆にリソース過多でスケールインさせたい場合はどうするか? … 再掲
  16. ReplicaSet による冗長化 28 • Pod のレプリカを作成して指定した数の Pod を稼働させるリソース • Pod

    -> ReplicaSet -> Deployment という親子構造がある Cluster Node Pod Node Pod Pod Container Container Container Container Container Pod Container Container Node Pod Container
  17. Pod のオートヒーリング 29 • Node がダウンしても Kubernetes がその上で動いていた Pod を避難させてくれる

    Cluster Node Pod Node Pod Pod Container Container Container Container Container Pod Container Container Node Pod Container 運用課題: アプリケーションコンテナが落ちてしまった場合のリカバリはどうするか?
  18. Deployment とローリングアップデート 32 • Deployment は複数の ReplicaSet を管理することでローリングアップデートや ロールバックといった、実運用においてアプリケーションの稼働状態を保ちながら 変更する仕組みを実現しています

    Pod Pod Pod Old ReplicaSet (Replicas = 3) New ReplicaSet (Replicas = 0) Pod Pod Pod Old ReplicaSet (Replicas = 3) New ReplicaSet (Replicas = 1) Pod Pod Pod Pod Old ReplicaSet (Replicas = 2) New ReplicaSet (Replicas = 2) Pod Pod Pod Old ReplicaSet (Replicas = 0) New ReplicaSet (Replicas = 3) Pod
  19. Deployment とローリングアップデート 33 • Deployment は複数の ReplicaSet を管理することで、ローリングアップデートやロールバックといった、 実運用においてアプリケーションの稼働状態を保ちながら変更する仕組みを実現しています Pod

    Pod Pod Old ReplicaSet (Replicas = 3) New ReplicaSet (Replicas = 0) Pod Pod Pod Old ReplicaSet (Replicas = 3) New ReplicaSet (Replicas = 1) Pod Pod Pod Pod Old ReplicaSet (Replicas = 2) New ReplicaSet (Replicas = 2) Pod Pod Pod Old ReplicaSet (Replicas = 0) New ReplicaSet (Replicas = 3) Pod • 実際にアプリケーションをマニフェストにする際、 ほぼ Deployment か StatefulSet (揮発しないストレージを持つ Deployment) • バグが見つかった時の切り戻しも Deployment の機能で可能
  20. クラスタオートスケール
 34 Cluster Node Pod Node Pod Pod Container Container

    Container Container Container Pod Container Container Node Pod Container Container 負荷によって Node をスケールアウトさせたい 運用課題: リソースが足りなくなった時の マシン のスケールアウトはどうするか
  21. クラスタオートスケール (スケールアウト)
 35 Cluster Node Pod Node Pod Pod Container

    Container Container Container Container Pod Container Container Node Pod Container Container Node が足りなければ自動的に増やすこともできる 運用課題: リソースが足りなくなった時の マシン のスケールアウトはどうするか
  22. クラスタオートスケール (スケールイン)
 36 Cluster Node Pod Node Pod Pod Container

    Container Container Container Container Pod Container Container Node Pod Container Container ピークが終わって増やした分の Node が要らなくなった 運用課題: 逆にリソース過多でスケールインさせたい場合はどうするか?
  23. クラスタオートスケール (スケールイン)
 37 Cluster Node Pod Node Pod Pod Container

    Container Container Container Container Pod Container Container Node Pod Container Container 自動でスケールインも可能 運用課題: 逆にリソース過多でスケールインさせたい場合はどうするか?
  24. Kubernetes のネットワーク機能 40 • Service ◦ LoadBalancer: ▪ 外部からアクセスできる ▪

    クラウドごとに実装が異なる ▪ L4 のロードバランシング ◦ ClusterIP: ▪ クラスタ内のみからアクセスできる ◦ NodePort: ▪ Node の IP で外部からもアクセスできる ▪ 前段に LB を挟まないので負荷分散としては弱い • Ingress ◦ L7 のロードバランサをするならこれ。TLS終端もこれじゃないとできない ◦ 実際にプロダクションでアプリを公開するなら Ingress を使うことになるはず ◦ クラウドごとに実装が異なる 最近では Ingress リソースの課題を解決した Gateway リソースが GA されました 今後利用ケースが増えてくると思われます
  25. Ingress の仕組み 41 Ingress-managed load balancer が個々のクラウドによって異なる。 GCP であれば GLB、AWS

    であれば ALB、ベアメタルであれば物理 LB や MetalLB など。 トラブルシューティングの役に立つので覚えておくとお得
  26. Ingress の仕組み 42 apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: example-ingress

    annotations: nginx.ingress.kubernetes.io/rewrite-target: /$1 spec: rules: - host: hello-world.info http: paths: - path: / pathType: Prefix backend: service: name: web port: number: 8080 • どのホストで • どのパスに合致するときに • どのサービスに リクエストをルーティングするかを記述
  27. 1 ArgoCD - GitOps といえばこれ的なところがある - CLI, WebUI などユーザにあった操作も可能 -

    Kustomize, Helm との連携もサポート - 依存関係のあるデプロイメントプロセスもサポート - 弊社での利用実績も多い - Public Cloud => Cloud Deploy, Code Deploy 47
  28. 1 Prometheus - 監視といえばこれ。Pull型の監視モデル - exporter という HTTP サーバでフォーマットに準拠したデータを出力するようにすれば 独自のメトリクスを監視することもできる

    - 複数Prometheusのメトリクスを集約して監視するソフトウェアもある(例: VictoriaMetrics, Thanos, Cortex) - ブラウザで監視したデータをよしなに見るには Grafana を使う - Public Cloud => Cloud Monitoring, Cloud Watch, DataDog 48
  29. 1 Open Policy Agent - Kubernetes で使用する場合、マニフェストの制限に使われることが多い - Rego という

    DSL をベースにポリシーをGo ライクにプログラミングできる - クラスタのセキュリティ向上に役立つ - 全社的にベストプラクティスを集約した Open Policy Agent のポリシーを公開予定です 49
  30. 1 TiKV, TiDB - Cloud Spanner インスパイアな NewSQL - TiDB

    は TiKV をストレージエンジンにした MySQL 互換なクエリエンジン - Raft という分散合意アルゴリズムで耐障害性が高い 50
  31. 1 Linkerd, Istio, Envoy - クラスタ内通信のポリシー、ロードバランシング、ルーティングに対して一元的な管理が できる - ネットワークの「信頼性」「可観測性」「安全性」を担保できる -

    弊社では Istio の方が利用されている印象 - Envoy は Istio 内で利用されているL7プロキシ - xDS という機能によって拡張性も高い - Public Cloud => App Mesh, Anthos Service Mesh - 高機能で便利だが運用も大変。利用する前に本当に必要なのか考えてみよう 51