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

Transcript

1. 2024/04/10 CyberAgent group Infrastructure Unit Kubernetes のススメ 新卒研修 2024 Development Division: Kota Kimura
2. 自己紹介 木村 洸太 - Kota Kimura • 株式会社サイバーエージェント グループIT推進本部 CIU Development Division 所属 2023年5月中途入社 • KaaS プロダクト AKE の開発・運用を担当 • 趣味はサウナ巡り
3. 1 アジェンダ - コンテナ・Kubernetes の登場背景 - Kubernetes の仕組みとできること - より高度なシステムを構築するためのエコシステムの紹介 Kubernetes の登場背景と利点について知ってもらうのが今日のゴール 3
4. CyberAgent group Infrastructure Unit 1. Kubernetes の登場背景 4
5. Kubernetes の登場背景 5 Kubernetes 触ってる or 知ってる人🤚
6. Kubernetes の登場背景 6 https://kubernetes.io/ja/docs/concepts/overview/
7. コンテナ の登場背景 7 コンテナの登場や普及の背景を 「インフラ構築、アプリケーションのデプロイ」 という側面で考えてみます ※ VM とコンテナの優劣の比較ではありません コンテナの登場によって新しい方法論が出てきたという意味合いに近いです
8. → 作業ミスや差分が生まれやすい 必要なリソースが増えてくると 作業に限界が.... VM の場合 (インフラのコード化なし) 8 ssh Server OS Hypervisor Guest OS Library Library Application 仮想サーバ Server OS Hypervisor Guest OS Library Library Application 仮想サーバ VM を手動構築し直接 ssh して、アプリのデプロイなどの諸々を手動作業
9. 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 仮想サーバ 環境差分
10. コンテナ の場合 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 でコンテナイメージのビルドを行い、コンテナランタイム上で コンテナイメージを取得し実行
11. コンテナ の場合 11 Server OS Container Runtime Library Library Application コンテナ Server OS Container Runtime Library Library Application コンテナ Dockerfile でコンテナイメージのビルドを行い、コンテナランタイム上で コンテナイメージを取得し実行 • 同一環境になることが保証される • docker でビルドから起動まで可能 ◦ 開発者(Dev) 側が関わりやすい
12. コンテナの特徴 12 コンテナはファイルシステムやプロセス空間などを隔離して、(namespace) CPU, Memory などリソース使用量を制限を行うことで(cgroup) 動作環境の分離を実現する コンテナはプロセスとして実行するため、高速な起動といった特徴を持つ namespace/cgroup に関して興味ある人は以下の連載がわかりやすいです LXCで学ぶコンテナ入門 －軽量仮想化環境を実現する技術 namespace: 第2回 cgroup: 第3-5回 (cgroupv1)、第37-41,45-48回 (cgroupv2)
13. コンテナのまとめ 13 コンテナは以下の特徴を持つ • 異なる環境でも同じ動作する ポータビリティの高さを持つ • 高速な起動が可能
14. では、コンテナのアプリケーションを運用するのは簡単？ 14 アプリケーションをコンテナ化する上で、沢山のことを考えなくてはいけない 1. アプリケーションコンテナが落ちてしまった場合のリカバリはどうするか？ 2. リソースが足りなくなった時の マシン のスケールアウトはどうするか 3. 逆にリソース過多でスケールインさせたい場合はどうするか？ 4. コンテナに割り振る IP アドレスはどうやって管理するか 5. コンテナ間のサービスディスカバリはどうするか 6. 複数のコンテナへのロードバランシングはどうするか 7. コンテナに依存しない永続化したデータはどうやって管理するか などなど、人類は欲深いのでこれら全てを解決できるソリューションを求めていました
15. CyberAgent group Infrastructure Unit 2. Kubernetes でできること 15
16. Kubernetes とは? 16 構造化されたデータ (主にYAMLファイル) を元に宣言的にリソースを管理 Kubernetes はコンテナオーケストレーションツール 複数のノードから構成されたコンピューティングプールに対してコンテナを起動
17. Reconciliation Loop 17 あるべき理想の状態 (Desired State) を宣言的に定義 Controller によって理想の状態へと収束するように振る舞う e.g. 何か問題が発生した場合でも、Controller によってセルフヒーリングされる 登録 (via API Request) watch コンテナの作成・削除 登録時にただ起動させるだけではない！ Controller
18. Reconciliation Loop 18 Controller 内では、Reconciliation loop (調整ループ) と呼ばれる あるべき状態へと収束させるループ処理が実行されている Kubernetes の内部には様々な Controller と呼ばれるプログラムが動作している Observe: 現状の確認 Diff: 理想と現状の差分を計算 Act: 差分に対する処理を実施
19. Reconciliation Loop 19 e.g. ReplicaSet Controller の場合 ReplicaSet Controller の責務は 「指定されたレプリカ数で Pod を維持し続けること」 ※ Pod は 複数のコンテナをまとめた Kubernetes における最小単位 Observe: 現状の確認 Diff: 理想と現状の差分を計算 Act: 差分に対する処理を実施
20. Reconciliation Loop 20 e.g. ReplicaSet Controller の場合 コンテナ (Pod) を3つ起動させるReplicaSet リソースの場合 Observe: 現状の確認 Diff: 理想と現状の差分を計算 Act: 差分に対する処理を実施
21. Reconciliation Loop 21 e.g. ReplicaSet Controller の場合 2つしかコンテナ (Pod) が起動していない場合... Observe: 理想=3、現状=2 Observe: 現状の確認 Diff: 理想と現状の差分を計算 Act: 差分に対する処理を実施
22. Reconciliation Loop 22 e.g. ReplicaSet Controller の場合 2つしかコンテナ (Pod) が起動していない場合... Diff: 1つコンテナ (Pod) が足りない Observe: 現状の確認 Diff: 理想と現状の差分を計算 Act: 差分に対する処理を実施
23. Reconciliation Loop 23 e.g. ReplicaSet Controller の場合 2つしかコンテナ (Pod) が起動していない場合... Act: 1つ nginx:1.16 のコンテナ (Pod) を作成する Observe: 現状の確認 Diff: 理想と現状の差分を計算 Act: 差分に対する処理を実施
24. Kubernetes の構成要素 24 Kubernetes では非常に多くの Controller が動いている • ReplicaSet Controller • Deployment Controller • Ingress Controller • Node Controller • Scheduler • etc... これらの Controller が非同期に動作することで、 1つの分散システムとして成り立っている
25. Reconciliation Loop 25 Reconciliation Loop のまとめ リソースあるべき理想の状態を構造化データで宣言的に定義することで Controller の Reconciliation Loop によって、理想の状態へ収束する → 人が考えること (運用ロジック) をプログラムで落とし込んで自動化できる = 運用を Kubernetes に任せることができる 1. アプリケーションコンテナが落ちてしまった場合のリカバリはどうするか？ 2. リソースが足りなくなった時の マシン のスケールアウトはどうするか 3. 逆にリソース過多でスケールインさせたい場合はどうするか？ … 再掲
26. CyberAgent group Infrastructure Unit 2.1. アプリケーションを実行する 26
27. Pod の冗長化 27 • ReplicaSet, Deployment • Kubernetes でアプリケーションを動かす時ほぼ確実にお世話になる
28. ReplicaSet による冗長化 28 • Pod のレプリカを作成して指定した数の Pod を稼働させるリソース • Pod -> ReplicaSet -> Deployment という親子構造がある Cluster Node Pod Node Pod Pod Container Container Container Container Container Pod Container Container Node Pod Container
29. Pod のオートヒーリング 29 • Node がダウンしても Kubernetes がその上で動いていた Pod を避難させてくれる Cluster Node Pod Node Pod Pod Container Container Container Container Container Pod Container Container Node Pod Container 運用課題: アプリケーションコンテナが落ちてしまった場合のリカバリはどうするか？
30. 30 じゃあアプリを冗長化するなら ReplicaSet だけでよくね？
31. 31 じゃあアプリを冗長化するなら ReplicaSet だけでよくね？
32. 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
33. 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 の機能で可能
34. クラスタオートスケール
 34 Cluster Node Pod Node Pod Pod Container Container Container Container Container Pod Container Container Node Pod Container Container 負荷によって Node をスケールアウトさせたい 運用課題: リソースが足りなくなった時の マシン のスケールアウトはどうするか
35. クラスタオートスケール (スケールアウト)
 35 Cluster Node Pod Node Pod Pod Container Container Container Container Container Pod Container Container Node Pod Container Container Node が足りなければ自動的に増やすこともできる 運用課題: リソースが足りなくなった時の マシン のスケールアウトはどうするか
36. クラスタオートスケール (スケールイン)
 36 Cluster Node Pod Node Pod Pod Container Container Container Container Container Pod Container Container Node Pod Container Container ピークが終わって増やした分の Node が要らなくなった 運用課題: 逆にリソース過多でスケールインさせたい場合はどうするか？
37. クラスタオートスケール (スケールイン)
 37 Cluster Node Pod Node Pod Pod Container Container Container Container Container Pod Container Container Node Pod Container Container 自動でスケールインも可能 運用課題: 逆にリソース過多でスケールインさせたい場合はどうするか？
38. キーワード 38 • Pod • Deployment, ReplicaSet • クラスタオートスケール
39. CyberAgent group Infrastructure Unit 2.2. アプリケーションの公開と負荷分散 39
40. Kubernetes のネットワーク機能 40 • Service ◦ LoadBalancer: ▪ 外部からアクセスできる ▪ クラウドごとに実装が異なる ▪ L4 のロードバランシング ◦ ClusterIP: ▪ クラスタ内のみからアクセスできる ◦ NodePort: ▪ Node の IP で外部からもアクセスできる ▪ 前段に LB を挟まないので負荷分散としては弱い • Ingress ◦ L7 のロードバランサをするならこれ。TLS終端もこれじゃないとできない ◦ 実際にプロダクションでアプリを公開するなら Ingress を使うことになるはず ◦ クラウドごとに実装が異なる 最近では Ingress リソースの課題を解決した Gateway リソースが GA されました 今後利用ケースが増えてくると思われます
41. Ingress の仕組み 41 Ingress-managed load balancer が個々のクラウドによって異なる。 GCP であれば GLB、AWS であれば ALB、ベアメタルであれば物理 LB や MetalLB など。 トラブルシューティングの役に立つので覚えておくとお得
42. 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 • どのホストで • どのパスに合致するときに • どのサービスに リクエストをルーティングするかを記述
43. キーワード 43 • Service リソース • LoadBalancer, ClusterIP, NodePort • Ingress
44. CyberAgent group Infrastructure Unit 3. より高度なシステムを構築するた めのエコシステムの紹介 44
45. Kubernetes 周辺のエコシステム 45 https://landscape.cncf.io/
46. 1 Kubernetes 周辺のエコシステム - Graduated Project を中心に紹介します - Public Cloud との対応関係なども私見ですが紹介します 46
47. 1 ArgoCD - GitOps といえばこれ的なところがある - CLI, WebUI などユーザにあった操作も可能 - Kustomize, Helm との連携もサポート - 依存関係のあるデプロイメントプロセスもサポート - 弊社での利用実績も多い - Public Cloud => Cloud Deploy, Code Deploy 47
48. 1 Prometheus - 監視といえばこれ。Pull型の監視モデル - exporter という HTTP サーバでフォーマットに準拠したデータを出力するようにすれば 独自のメトリクスを監視することもできる - 複数Prometheusのメトリクスを集約して監視するソフトウェアもある（例: VictoriaMetrics, Thanos, Cortex） - ブラウザで監視したデータをよしなに見るには Grafana を使う - Public Cloud => Cloud Monitoring, Cloud Watch, DataDog 48
49. 1 Open Policy Agent - Kubernetes で使用する場合、マニフェストの制限に使われることが多い - Rego という DSL をベースにポリシーをGo ライクにプログラミングできる - クラスタのセキュリティ向上に役立つ - 全社的にベストプラクティスを集約した Open Policy Agent のポリシーを公開予定です 49
50. 1 TiKV, TiDB - Cloud Spanner インスパイアな NewSQL - TiDB は TiKV をストレージエンジンにした MySQL 互換なクエリエンジン - Raft という分散合意アルゴリズムで耐障害性が高い 50
51. 1 Linkerd, Istio, Envoy - クラスタ内通信のポリシー、ロードバランシング、ルーティングに対して一元的な管理が できる - ネットワークの「信頼性」「可観測性」「安全性」を担保できる - 弊社では Istio の方が利用されている印象 - Envoy は Istio 内で利用されているL7プロキシ - xDS という機能によって拡張性も高い - Public Cloud => App Mesh, Anthos Service Mesh - 高機能で便利だが運用も大変。利用する前に本当に必要なのか考えてみよう 51
52. CyberAgent group Infrastructure Unit ご清聴ありがとうございました！ 52