Slide 1

Slide 1 text

2024/04/10 CyberAgent group Infrastructure Unit Kubernetes のススメ 新卒研修 2024 Development Division: Kota Kimura

Slide 2

Slide 2 text

自己紹介 木村 洸太 - Kota Kimura ● 株式会社サイバーエージェント グループIT推進本部 CIU Development Division 所属 2023年5月中途入社 ● KaaS プロダクト AKE の開発・運用を担当 ● 趣味はサウナ巡り

Slide 3

Slide 3 text

1 アジェンダ - コンテナ・Kubernetes の登場背景 - Kubernetes の仕組みとできること - より高度なシステムを構築するためのエコシステムの紹介 Kubernetes の登場背景と利点について知ってもらうのが今日のゴール 3

Slide 4

Slide 4 text

CyberAgent group Infrastructure Unit 1. Kubernetes の登場背景 4

Slide 5

Slide 5 text

Kubernetes の登場背景 5 Kubernetes 触ってる or 知ってる人🤚

Slide 6

Slide 6 text

Kubernetes の登場背景 6 https://kubernetes.io/ja/docs/concepts/overview/

Slide 7

Slide 7 text

コンテナ の登場背景 7 コンテナの登場や普及の背景を 「インフラ構築、アプリケーションのデプロイ」 という側面で考えてみます ※ VM とコンテナの優劣の比較ではありません コンテナの登場によって新しい方法論が出てきたという意味合いに近いです

Slide 8

Slide 8 text

→ 作業ミスや差分が生まれやすい 必要なリソースが増えてくると 作業に限界が.... VM の場合 (インフラのコード化なし) 8 ssh Server OS Hypervisor Guest OS Library Library Application 仮想サーバ Server OS Hypervisor Guest OS Library Library Application 仮想サーバ VM を手動構築し直接 ssh して、アプリのデプロイなどの諸々を手動作業

Slide 9

Slide 9 text

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 仮想サーバ 環境差分

Slide 10

Slide 10 text

コンテナ の場合 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 でコンテナイメージのビルドを行い、コンテナランタイム上で コンテナイメージを取得し実行

Slide 11

Slide 11 text

コンテナ の場合 11 Server OS Container Runtime Library Library Application コンテナ Server OS Container Runtime Library Library Application コンテナ Dockerfile でコンテナイメージのビルドを行い、コンテナランタイム上で コンテナイメージを取得し実行 ● 同一環境になることが保証される ● docker でビルドから起動まで可能 ○ 開発者(Dev) 側が関わりやすい

Slide 12

Slide 12 text

コンテナの特徴 12 コンテナはファイルシステムやプロセス空間などを隔離して、(namespace) CPU, Memory などリソース使用量を制限を行うことで(cgroup) 動作環境の分離を実現する コンテナはプロセスとして実行するため、高速な起動といった特徴を持つ namespace/cgroup に関して興味ある人は以下の連載がわかりやすいです LXCで学ぶコンテナ入門 -軽量仮想化環境を実現する技術 namespace: 第2回 cgroup: 第3-5回 (cgroupv1)、第37-41,45-48回 (cgroupv2)

Slide 13

Slide 13 text

コンテナのまとめ 13 コンテナは以下の特徴を持つ ● 異なる環境でも同じ動作する ポータビリティの高さを持つ ● 高速な起動が可能

Slide 14

Slide 14 text

では、コンテナのアプリケーションを運用するのは簡単? 14 アプリケーションをコンテナ化する上で、沢山のことを考えなくてはいけない 1. アプリケーションコンテナが落ちてしまった場合のリカバリはどうするか? 2. リソースが足りなくなった時の マシン のスケールアウトはどうするか 3. 逆にリソース過多でスケールインさせたい場合はどうするか? 4. コンテナに割り振る IP アドレスはどうやって管理するか 5. コンテナ間のサービスディスカバリはどうするか 6. 複数のコンテナへのロードバランシングはどうするか 7. コンテナに依存しない永続化したデータはどうやって管理するか などなど、人類は欲深いのでこれら全てを解決できるソリューションを求めていました

Slide 15

Slide 15 text

CyberAgent group Infrastructure Unit 2. Kubernetes でできること 15

Slide 16

Slide 16 text

Kubernetes とは? 16 構造化されたデータ (主にYAMLファイル) を元に宣言的にリソースを管理 Kubernetes はコンテナオーケストレーションツール 複数のノードから構成されたコンピューティングプールに対してコンテナを起動

Slide 17

Slide 17 text

Reconciliation Loop 17 あるべき理想の状態 (Desired State) を宣言的に定義 Controller によって理想の状態へと収束するように振る舞う e.g. 何か問題が発生した場合でも、Controller によってセルフヒーリングされる 登録 (via API Request) watch コンテナの作成・削除 登録時にただ起動させるだけではない! Controller

Slide 18

Slide 18 text

Reconciliation Loop 18 Controller 内では、Reconciliation loop (調整ループ) と呼ばれる あるべき状態へと収束させるループ処理が実行されている Kubernetes の内部には様々な Controller と呼ばれるプログラムが動作している Observe: 現状の確認 Diff: 理想と現状の差分を計算 Act: 差分に対する処理を実施

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

Reconciliation Loop 20 e.g. ReplicaSet Controller の場合 コンテナ (Pod) を3つ起動させるReplicaSet リソースの場合 Observe: 現状の確認 Diff: 理想と現状の差分を計算 Act: 差分に対する処理を実施

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

Kubernetes の構成要素 24 Kubernetes では非常に多くの Controller が動いている ● ReplicaSet Controller ● Deployment Controller ● Ingress Controller ● Node Controller ● Scheduler ● etc... これらの Controller が非同期に動作することで、 1つの分散システムとして成り立っている

Slide 25

Slide 25 text

Reconciliation Loop 25 Reconciliation Loop のまとめ リソースあるべき理想の状態を構造化データで宣言的に定義することで Controller の Reconciliation Loop によって、理想の状態へ収束する → 人が考えること (運用ロジック) をプログラムで落とし込んで自動化できる = 運用を Kubernetes に任せることができる 1. アプリケーションコンテナが落ちてしまった場合のリカバリはどうするか? 2. リソースが足りなくなった時の マシン のスケールアウトはどうするか 3. 逆にリソース過多でスケールインさせたい場合はどうするか? … 再掲

Slide 26

Slide 26 text

CyberAgent group Infrastructure Unit 2.1. アプリケーションを実行する 26

Slide 27

Slide 27 text

Pod の冗長化 27 ● ReplicaSet, Deployment ● Kubernetes でアプリケーションを動かす時ほぼ確実にお世話になる

Slide 28

Slide 28 text

ReplicaSet による冗長化 28 • Pod のレプリカを作成して指定した数の Pod を稼働させるリソース • Pod -> ReplicaSet -> Deployment という親子構造がある Cluster Node Pod Node Pod Pod Container Container Container Container Container Pod Container Container Node Pod Container

Slide 29

Slide 29 text

Pod のオートヒーリング 29 • Node がダウンしても Kubernetes がその上で動いていた Pod を避難させてくれる Cluster Node Pod Node Pod Pod Container Container Container Container Container Pod Container Container Node Pod Container 運用課題: アプリケーションコンテナが落ちてしまった場合のリカバリはどうするか?

Slide 30

Slide 30 text

30 じゃあアプリを冗長化するなら ReplicaSet だけでよくね?

Slide 31

Slide 31 text

31 じゃあアプリを冗長化するなら ReplicaSet だけでよくね?

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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 の機能で可能

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

クラスタオートスケール (スケールイン)
 37 Cluster Node Pod Node Pod Pod Container Container Container Container Container Pod Container Container Node Pod Container Container 自動でスケールインも可能 運用課題: 逆にリソース過多でスケールインさせたい場合はどうするか?

Slide 38

Slide 38 text

キーワード 38 ● Pod ● Deployment, ReplicaSet ● クラスタオートスケール

Slide 39

Slide 39 text

CyberAgent group Infrastructure Unit 2.2. アプリケーションの公開と負荷分散 39

Slide 40

Slide 40 text

Kubernetes のネットワーク機能 40 ● Service ○ LoadBalancer: ■ 外部からアクセスできる ■ クラウドごとに実装が異なる ■ L4 のロードバランシング ○ ClusterIP: ■ クラスタ内のみからアクセスできる ○ NodePort: ■ Node の IP で外部からもアクセスできる ■ 前段に LB を挟まないので負荷分散としては弱い ● Ingress ○ L7 のロードバランサをするならこれ。TLS終端もこれじゃないとできない ○ 実際にプロダクションでアプリを公開するなら Ingress を使うことになるはず ○ クラウドごとに実装が異なる 最近では Ingress リソースの課題を解決した Gateway リソースが GA されました 今後利用ケースが増えてくると思われます

Slide 41

Slide 41 text

Ingress の仕組み 41 Ingress-managed load balancer が個々のクラウドによって異なる。 GCP であれば GLB、AWS であれば ALB、ベアメタルであれば物理 LB や MetalLB など。 トラブルシューティングの役に立つので覚えておくとお得

Slide 42

Slide 42 text

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 ● どのホストで ● どのパスに合致するときに ● どのサービスに リクエストをルーティングするかを記述

Slide 43

Slide 43 text

キーワード 43 ● Service リソース ● LoadBalancer, ClusterIP, NodePort ● Ingress

Slide 44

Slide 44 text

CyberAgent group Infrastructure Unit 3. より高度なシステムを構築するた めのエコシステムの紹介 44

Slide 45

Slide 45 text

Kubernetes 周辺のエコシステム 45 https://landscape.cncf.io/

Slide 46

Slide 46 text

1 Kubernetes 周辺のエコシステム - Graduated Project を中心に紹介します - Public Cloud との対応関係なども私見ですが紹介します 46

Slide 47

Slide 47 text

1 ArgoCD - GitOps といえばこれ的なところがある - CLI, WebUI などユーザにあった操作も可能 - Kustomize, Helm との連携もサポート - 依存関係のあるデプロイメントプロセスもサポート - 弊社での利用実績も多い - Public Cloud => Cloud Deploy, Code Deploy 47

Slide 48

Slide 48 text

1 Prometheus - 監視といえばこれ。Pull型の監視モデル - exporter という HTTP サーバでフォーマットに準拠したデータを出力するようにすれば 独自のメトリクスを監視することもできる - 複数Prometheusのメトリクスを集約して監視するソフトウェアもある(例: VictoriaMetrics, Thanos, Cortex) - ブラウザで監視したデータをよしなに見るには Grafana を使う - Public Cloud => Cloud Monitoring, Cloud Watch, DataDog 48

Slide 49

Slide 49 text

1 Open Policy Agent - Kubernetes で使用する場合、マニフェストの制限に使われることが多い - Rego という DSL をベースにポリシーをGo ライクにプログラミングできる - クラスタのセキュリティ向上に役立つ - 全社的にベストプラクティスを集約した Open Policy Agent のポリシーを公開予定です 49

Slide 50

Slide 50 text

1 TiKV, TiDB - Cloud Spanner インスパイアな NewSQL - TiDB は TiKV をストレージエンジンにした MySQL 互換なクエリエンジン - Raft という分散合意アルゴリズムで耐障害性が高い 50

Slide 51

Slide 51 text

1 Linkerd, Istio, Envoy - クラスタ内通信のポリシー、ロードバランシング、ルーティングに対して一元的な管理が できる - ネットワークの「信頼性」「可観測性」「安全性」を担保できる - 弊社では Istio の方が利用されている印象 - Envoy は Istio 内で利用されているL7プロキシ - xDS という機能によって拡張性も高い - Public Cloud => App Mesh, Anthos Service Mesh - 高機能で便利だが運用も大変。利用する前に本当に必要なのか考えてみよう 51

Slide 52

Slide 52 text

CyberAgent group Infrastructure Unit ご清聴ありがとうございました! 52