Getting Started kubernetes

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

Slide 11

Slide 11 text

コンテナの場合 11 Server OS Container Runtime Library Library Application コンテナ Server OS Container Runtime Library Library Application コンテナ Dockerﬁle でコンテナイメージのビルドを行い、コンテナランタイム上でコンテナイメージを取得し実行 ● 同一環境になることが保証される ● 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: 現状の確認 Diﬀ: 理想と現状の差分を計算 Act: 差分に対する処理を実施

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

Reconciliation Loop 23 e.g. ReplicaSet Controller の場合 2つしかコンテナ (Pod) が起動していない場合... Act: 1つ nginx:1.16 のコンテナ (Pod) を作成する Observe: 現状の確認 Diﬀ: 理想と現状の差分を計算 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