CA 1day Youth Bootcamp CIU Kubernetes

Slide 1

Slide 1 text

2021新卒研修 Kubernetes の基礎編 CA 1Day Youth Boot Camp Version CyberAgent group Infrastructure Unit / Katsuya Kawabe

Slide 2

Slide 2 text

1.Kubernetes とは何か 2.Kubernetes Basic Hands On 3.Kubernetes の仕組み 4.業務で使いそうなエコシステムの紹介

Slide 3

Slide 3 text

Katsuya Kawabe •CyberAgent group Infrastructure Unit インフラ基盤を開発するソフトウェアエンジニアです AKE, OpenStack, ML Platform などの開発、運用をしています •趣味漫画最近は「ブルーロック」「左利きのエレン」が熱い音楽なんでも聴きます。BUMP OF CHICKEN が一番好き

Slide 4

Slide 4 text

今日のゴール • Kubernetes の雰囲気を掴む • Kubernetes の最低限の操作における知識のインデックスを作る • Kubernetes のリソースの知識のインデックスを作る • 今日やったことを後日ググれるようにしましょう！

Slide 5

Slide 5 text

1.Kubernetes とは何か 2.Kubernetes Basic Hands On 3.Kubernetes の仕組み 4.業務で使いそうなエコシステムの紹介

Slide 6

Slide 6 text

Kubernetes 触った or 知ってる人🤚

Slide 7

Slide 7 text

🤔

Slide 8

Slide 8 text

No content

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

余談: VMは必要なくなったのか？ •そんなことは全然ないそもそも GKE や EKS といった、パブリッククラウドにおける Kubernetes as a Service も結局は GCE や EC2 といった仮想化基盤の上で動いている •VM時代に比べてバックエンドエンジニアが知るべき領域は減ったのか？抽象化が進み確実に「バックエンドエンジニアでもOS、ネットワーク、ミドルウェアの知識も必要」という場面は減ってきている（気がする） •「とりあえず Kubernetes でアプリを運用してみる」ってどう？ 2, 3年前なら批判されていたかもしれないが、今は GKE Autopilot などの登場により、Kubernetes 自体の運用もかなり楽になってきている。後述する魅力的な機能やエコシステムに楽に乗っかれるようになってきたので今なら全然ありだと思う

Slide 11

Slide 11 text

これらの機能を全て紹介するには余白が少なすぎる詳しく知りたい人はこの本を買おう

Slide 12

Slide 12 text

コンテナを宣言的な構成管理でパッケージングし、その運用の自動化を促進するポータブルなプラットフォーム

Slide 13

Slide 13 text

コンテナを宣言的な構成管理でパッケージングし、その運用の自動化を促進するポータブルなプラットフォーム Infrastructure as Code GitOps CI/CD On-Premise Public Cloud

Slide 14

Slide 14 text

1.Kubernetes とは何か 2.Kubernetes Basic Hands On 3.Kubernetes の仕組み 4.業務で使いそうなエコシステムの紹介

Slide 15

Slide 15 text

宣言的なコードによる管理 ● Kubernetes で管理するリソースは全て宣言的な YAML で定義されます ● 「Desired State」: こうあるべきという状態を宣言するもの (ex: Nginx の Pod が3つ立って欲しい ● 宣言された状態に遷移させるのは Kubernetes のコンポーネントが責務を持ちます ● 基本的に Kubernetes で軽くアプリを動かすだけならよく使うリソースの YAML の書き方を知っておけば大丈夫なはず

Slide 16

Slide 16 text

宣言的なコードによる管理 Developer or SRE or Program ... kubectl apply -f deployment.yaml Nginx Nginx Nginx Node Node Node

Slide 17

Slide 17 text

宣言的なコードによる管理 Developer or SRE or Program ... kubectl apply * Nginx Nginx Nginx 様々なリソースをマニフェストとして Kubernetes に登録する Node Node Node

Slide 18

Slide 18 text

Kubernetes のリソース - Workloads リソース - コンテナ実行に関わるリソース - この研修で主に触れます。Pod, Deployment, ReplicaSet 等が含まれます - Discovery & LB リソース - コンテナを外部公開するためのリソース - Service, Ingress リソース等が含まれます - Config & Storage リソース - 設定情報、機密情報、永続化するようなデータに関するリソースです - Cluster リソース - クラスタで共通なセキュリティやクォータに関するリソースです - Metadata リソース - Kubernetes のリソースを操作するためのリソースです - CustomResourceDefinition のような拡張機能も含まれます

Slide 19

Slide 19 text

Namespace による分離 Pod Pod Pod Service Service Pod Pod Service Service “Staging” Namespace Pod Pod Service “Decvelopment” Namespace アプリ開発者 Namespace という分離機能があり、リソースの分離や Namespace 単位でのアクセス許可といったことができます。今回は default Namespace 内での操作しかしませんが、重要な概念です “Production” Namespace SRE

Slide 20

Slide 20 text

宣言的なコードによる管理 • 今日はこの Infrastructure as a Code をサンプルや課題のコードを実際に動かして体感してもらいます • とはいってもやることはシンプル • ファイルを編集 -> kubectl apply -f *.yaml -> 修正したかったらファイルを修正 -> 再度 kubectl apply -f *.yaml

Slide 21

Slide 21 text

使用する環境: GCP, GCE, Kind • GCP は Google が提供するパブリッククラウド • Kind on GCE: GCE 上で Kind (Kubernetes in Docker) を動かして Kubernetes を体験してもらいます • Kind: Docker 上に Kubernetes のコンポーネントを動作させて、お手軽に Kubernetes を試すことができるツールです。類似ツールに Minikube があります • GKE でない理由はこのインターンの後皆さんの手元の PC でも簡単に環境を再現できるようにするためです

Slide 22

Slide 22 text

使用する環境: 1人1クラスタ Pod Pod Pod Service Service “User A” Cluster User A User B VM に SSH してもらい、kubectl コマンドでクラスタを操作してもらいます。他人のクラスタは SSH しないと操作できませんが、間違えないように注意してください。 Pod Pod Pod Service Service “User B” Cluster

Slide 23

Slide 23 text

サンプルマニフェストの準備 $ git clone https://github.com/CyberAgentHack/one-day-youth-bootcamp-ciu.git $ cd one-day-youth-bootcamp-ciu

Slide 24

Slide 24 text

リポジトリの構造 $ tree ├── examples │ ├── deployment.yaml │ ├── ingress.yaml │ ├── pod.yaml │ ├── replicaset.yaml │ └── service.yaml ├── exercises │ ├── deployment │ │ └── answer.md │ ├── ingress │ │ ├── answer.md │ │ ├── gencert.sh │ │ ├── ingress.yaml │ │ ├── server.crt │ │ ├── server.key │ │ └── ssl.conf │ └── pod │ ├── advance_answer.md │ └── basic_answer.md

Slide 25

Slide 25 text

Pod リソース

Slide 26

Slide 26 text

Pod とは Container Container NIC Container Container NIC NIC Pod は一つ以上のコンテナから構成される、Kubernetes におけるコンテナ実行に関する最小単位のリソースです。アプリケーションをコンテナ化して動かしたい場合は最終的には Pod が作成されることになるはず。 IP アドレスは Pod 単位で割り当てられます => ネットワークの名前空間を共有つまり、内部のコンテナで同じポート番号でサーバをリッスンしようとするとどちらかは失敗します

Slide 27

Slide 27 text

Pod のアプライ $ kubectl apply -f examples/pod.yaml # Pod が動いているか確認してみよう $ kubectl get po NAME READY STATUS RESTARTS AGE echo-pod 1/1 Running 0 3d3h

Slide 28

Slide 28 text

Pod のマニフェストについて • kind: Kubernetes のリソースの種類 • apiVersion: kind のバージョン • metadata: 管理用の付加情報 • name: コンテナを識別するための名前。他のと重複できない • command: コンテナのエントリーポイント • image: コンテナのイメージとタグ • imagePullPolicy: image を pull する際、キャッシュしたものを使うのか( IfNotPresent )、常にリモートから取得するのか( Always ) • ports.ContainerPort : Pod の IP から Expose するコンテナのポート番号を指定 • args: command に対する引数

Slide 29

Slide 29 text

Pod にリクエストを投げてみよう # Pod の IP を確認しよう $ kubectl get pod -owide # kubectl run でデバッグ用の Pod を建てて echo-pod にアクセスしてみる # foo と出力されれば成功 $ kubectl run busybox -it --rm --image=busybox --restart=Never -- /bin/sh -c "wget -q -O- :8080"

Slide 30

Slide 30 text

# Tips - kubectl apply -f - 一番お世話になるであろうコマンド。マニフェストを適用する - http のアドレスを指定してもいいので GitHub 上の生マニフェストも適用できます - create もあるが、こちらは既にリソースがあるとエラーになる - apply は作成も更新も可能 - kubectl get resource_kind - 恐らく一番お世話になるであろうコマンド第二弾。リソースの一覧を取得します - kubectl get -oyaml で生のリソースを yaml 形式で確認できます。-ojson とかだと json になる - -owide を Pod や Node に使うと IP をぱっと確認できて便利 - kubectl run - 実運用で使うことはあまりないが、Pod 間の疎通を確認するのに便利 - --it は --stdin と --tty オプションを同時に指定しており Pod の標準入出力を取得しています - --rm は実行後 Pod を削除します - busybox イメージ - busybox という unix のユーティリティを詰め合わせたバイナリのコンテナイメージ - 軽量なので立ち上がるのが早いです。とりあえず Pod 建てるなら busybox でいいんじゃないかな - sh 自体も busybox に含まれる - curl とか dig はないので注意 (ping はある)

Slide 31

Slide 31 text

問題 1 ● busybox イメージのコンテナ2つを含む Pod を建ててみよう。 ○ 1つ目のコンテナの name は foo、2つ目のコンテナの name は bar で作成してみよう ○ foo, bar コンテナで実行するコマンドは sh -c “echo bootcamp; sleep infinity” にしてみよう ○ busybox のイメージは image: busybox で使用できます ● 上級者向け: nginx の Pod を建て、init container に busyboxy のコンテナを作成して echo -n “Hello, World!” > /work-dir/index.html を実行しよう。 ○ 作成するとき、emptyDir をinit container の /work-dir、nginx の /usr/share/nginx/html にマウントしよう ○ nginx のポート番号などはお任せします。 ○ kubectl run busybox -it --rm --image=busybox --restart=Never -- /bin/sh -c "wget -q -O- $POD_IP" で Hello, World! と出力されるか確認してみよう ● 解説は exercises/pod 以下の Markdown に書いてあります

Slide 32

Slide 32 text

ReplicaSet リソース

Slide 33

Slide 33 text

ReplicaSet で複数の Pod を管理 • Pod のレプリカを作成して指定した数の Pod を稼働させるリソース • 冗長性、スケールインやスケールアウトを実現するリソースの一つ • 後述する Deployment と合わせて Pod -> ReplicaSet -> Deployment という親子構造がある Pod Pod Pod Pod Pod ReplicaSet (Replica 数 = 5) 図引用: Kubernetes 完全ガイド第一版

Slide 34

Slide 34 text

ReplicaSet で複数の Pod を管理 • オートヒーリングも ReplicaSet で実現可能 Pod Pod Pod Pod Pod ReplicaSet (Replica 数 = 5) Pod Pod 図引用: Kubernetes 完全ガイド第一版

Slide 35

Slide 35 text

ReplicaSet で複数の Pod を管理 • Pod のラベルで数を調節 ReplicaSet (Replica 数 = 3) metadata.labels で該当する app: nginx ラベルがついた Pod を探す Pod app: echo Pod app: test Pod app: nginx Pod app: nginx Pod app: nginx 図引用: Kubernetes 完全ガイド第一版

Slide 36

Slide 36 text

ReplicaSet で使う Label • .metadata.labels で定義される • .metadata.labels を基にリソースを検索することが多い • .metadata.annotations の違いはフィルタリングに使うか否か

Slide 37

Slide 37 text

ReplicaSet のデプロイ $ kubectl apply -f examples/replicaset.yaml # Pod が作成されているか確認 $ kubectl get po -l app=echoserver # spec.replicas を 5 に変更してみよう $ kubectl apply -f examples/replicaset.yaml # 動作確認ができたら削除しておこう $ kubectl delete -f examples/replicaset.yaml

Slide 38

Slide 38 text

# Tips - kubectl edit - Kubernetes 上のリソースを直接操作できます - しかし、手元に修正後のマニフェストが残らないので本番環境とかではやらないほうがいい - edit 時に開かれるエディタは EDITOR 環境変数で変更できます - kubectl label - 対象リソースにラベルの付与、更新、削除ができます - 付与: kubectl label pod/test app=test - 削除: kubectl label pod/test app- - 更新: kubectl label --overwrite pod/test app=test2

Slide 39

Slide 39 text

ReplicaSet マニフェストの解説 ● spec.replicas: Pod の数 ● selector.matchLabels: 管理する Pod のラベル ● spec.template: Pod のテンプレートを書きます。中身は pod.yaml のものと一緒 selector には他にも matchExpressions という複雑な条件をもとに Pod を管理する方法もあるがここでは割愛します

Slide 40

Slide 40 text

Deployment リソース

Slide 41

Slide 41 text

Deployment で ReplicaSet を管理 • 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 図引用: Kubernetes 完全ガイド第一版

Slide 42

Slide 42 text

Deployment で ReplicaSet を管理 • 新しい ReplicaSet の Pod がちゃんと立ち上がったかを HealthCheck しながら切り替えてくれる • Rolling Update の際の許容される不足 Pod 数や超過 Pod 数なども設定可能 • ロールバックするための、Pod の Revision などをどれだけ保持するかなどの設定も可能 • Kubernetes でコンテナを起動する際に、最も推奨されている方法

Slide 43

Slide 43 text

Deployment のデプロイ $ kubectl apply -f examples/deployment.yaml # Pod が作成されているか確認 $ kubectl get po -l app=echoserver # Pod Template の imagePullPolicy を IfNotPresent に変更してみよう $ kubectl apply -f examples/deployment.yaml # ReplicaSet が二つできているはず $ kubectl get rs # ReplicaSet を一つ目の Revision に戻してみる $ kubectl rollout undo deployment echoserver --to-revision=1 # 動作確認ができたら削除しておこう $ kubectl delete -f examples/deployment.yaml

Slide 44

Slide 44 text

# Tips - kubectl rollout - kubectl rollout restart deploy で一台ずつ安全にリスタートできます

Slide 45

Slide 45 text

問題 2 ● nginx:1.18.0 の Deployment を作成しよう ○ Replica は 3 ○ Port は 80 を expose していること ○ command と args は指定しなくて大丈夫です ● 上級者向け問題 ● Deployment に対して Horizontal Pod Autoscaler を設定しよう ○ 最小 Replica = 5, 最大 Replica = 10, メトリクスは CPU 使用率 80 %

Slide 46

Slide 46 text

次は Service, Ingress といった Pod へのアクセスを制御する仕組みを学びましょう

Slide 47

Slide 47 text

Service リソース

Slide 48

Slide 48 text

Service: Kubernetes のネットワーク • Service は Pod 宛のトラフィックをロードバランシングするリソースです • サービスディスカバリとクラスタ内 DNS で利用 • 外部からのリクエストもロードバランシングできる NIC Pod Pod NIC Pod NIC Pod Pod Node Network Pod Network 図引用: Kubernetes 完全ガイド第一版

Slide 49

Slide 49 text

Service: Kubernetes のネットワーク NIC Pod In Cluster VIP NIC Pod Pod NIC Endpoint (LB VIP) Pod Pod Pod kube-proxy kube-proxy kube-proxy 図引用: Kubernetes 完全ガイド第一版 Node Network Pod Network • 外部のロードバランサが払い出す IP やクラスタ内でのみ使用可能な IP などを提供するリソース • それぞれの外部のロードバランサを利用する場合、プロバイダごとに実装が異なります • Pod への通信は kube-proxy によってノードから Pod の仮想 NIC にルーティングされます

Slide 50

Slide 50 text

Kubernetes でのサービスディスカバリ NIC Pod In Cluster VIP NIC Pod Pod NIC Pod Pod Pod kube-proxy kube-proxy kube-proxy 図引用: Kubernetes 完全ガイド第一版 Node Network Pod Network • クラスタ内でのみ有効な DNS を利用してサービス間の通信を実現できる • Pod, Service に対して固有のレコードがクラスタ上の DNS に追加される • Pod から透過的に、別サービスの Pod へリクエストを送信することができる To: service-b.default.svc.cluster.local

Slide 51

Slide 51 text

Service の種類 • Cluster IP : クラスタ内部でのみ使用可能な仮想 IP を持つ Service • NodePort : <全ての Node の IP アドレス>: Port の組みでトラフィックを受ける Service • LoadBalancer : Kubernetes クラスタ外のロードバランサを利用して、トラフィックを受ける Service。L4 のロードバランシング実現するためのリソース

Slide 52

Slide 52 text

Cluster IP のルーティング NIC Pod Pod Pod Network app: echo 10.0.0.10:80 NIC Pod app: echo 10.0.1.20:80 NIC Pod Pod app: echo 10.0.2.30:80 ClusterIP Service (10.100.100.100:8080) kube-proxy 図引用: Kubernetes 完全ガイド第一版

Slide 53

Slide 53 text

Cluster IP Service のデプロイ # 受け付ける Pod が必要なので Deployment を用意 $ kubectl apply -f examples/deployment.yaml # Pod が作成されているか確認 $ kubectl get po -l app=echoserver # Service をデプロイ $ kubectl apply -f examples/service.yaml # 割り振られた IP を確認。kubectl get svc でも可 $ kubectl describe svc echoserver # クラスタ内に適当に Pod を建ててアクセスしてみる $ kubectl run --image=centos:6 --restart=Never --rm -i testpo -- curl -s http://:80 # 今度はクラスタ内DNS経由でアクセスしてみる $ kubectl run --image=centos:6 --restart=Never --rm -i testpo -- curl -s http://echoserver.default.svc.cluster.local:80

Slide 54

Slide 54 text

# Tips - kubectl describe - リソースの詳細を知ることができます - 綺麗に整形されて表示されるので見やすいです - kubectl get -oyaml では生のマニフェストを見れますが整形されてないので慣れてないとわかりづらい - kubectl get -oyaml だと describe で表示されない情報も確認できるのでトラブルシュートの時はこちらを使うことが多いかも

Slide 55

Slide 55 text

ClusterIP のマニフェスト解説 ● spec.ports[].port : ClusterIP で受けるポート番号 ● spec.ports[].targetPort: コンテナで受けるポート番号 ● spec.ports[].protocol: 受け付けるプロトコル

Slide 56

Slide 56 text

NodePort のルーティング NIC Pod Pod Pod Network app: echo 10.0.0.10:80 NIC Pod app: echo 10.0.1.20:80 NIC Pod Pod app: echo 10.0.2.30:80 NodePort Service (*:30010) • 全ての Node の特定の Port でリクエストを受け付けるサービスを作成する • Kubernetes 外部からも 30010 にアクセスするとバックエンドの Pod にリクエストが送信できる • 外部との疎通性を確立する手法の1つ • ポート番号は指定できるが、指定しない場合は Kubernetes が使用していないポート番号をあらかじめ指定したレンジから割り振ります

Slide 57

Slide 57 text

NodePort Service のデプロイ # 受け付ける Pod が必要なので Deployment を用意 $ kubectl apply -f examples/deployment.yaml # Pod が作成されているか確認 $ kubectl get po -l app=echoserver # Service をデプロイ $ kubectl apply -f manifests/service-node-port.yaml # Service に割り振られた Port を確認 $ kubectl get svc -owide # 割り振られた Node の IP を確認 $ kubectl get node -owide # クラスタ内に適当に Pod を建ててアクセスしてみる $ kubectl run busybox -it --rm --image=busybox --restart=Never -- /bin/sh -c "wget -q -O- :"

Slide 58

Slide 58 text

NodePort のマニフェスト ● spec.type : Service の種類 ● spec.ports[].nodePort: NodePort で受け付ける Port を指定する場合に使用

Slide 59

Slide 59 text

Ingress リソース

Slide 60

Slide 60 text

Ingress • L7 ロードバランシングを提供するリソース • HTTPS 終端なども行えるので、使われることが多い • これもクラウドプロバイダごとに実装が異なる • GCP だったら GCLB、AWS だったら ALB、オンプレだったら MetalLB や物理LB

Slide 61

Slide 61 text

Ingress のルーティング NIC Pod Service A Service B NIC Pod Pod NIC Pod Ingress /foo: Service A, /bar: Service B Pod Pod 図引用: Kubernetes 完全ガイド第一版

Slide 62

Slide 62 text

Ingress のデプロイ # Ingress をデプロイ。マニフェストに Deployment と Service も含まれています。 $ kubectl apply -f examples/ingress.yaml # Ingress にアクセス可能なアドレスが付与されたか確認 $ kubectl get ingress NAME CLASS HOSTS ADDRESS PORTS AGE example-ingress echo.info localhost 80 105m # Ingress 経由でアクセス $ curl -XGET -H “Host: echo.info” http://localhost/foo # cleanup $ kubectl delete -f examples/ingress.yaml

Slide 63

Slide 63 text

Ingress のマニフェスト ● spec.rules[].host: リクエストを受け付ける Host 名 ● spec.rules[].http.paths: HTTP のパスに対するルーティングルールを記述する ● pathType: Prefix は前方一致。 ○ Exact を指定した場合は完全一致 ○ ImplementationSpecific というプロバイダごとに異なるマッチ条件も指定可能 ● path: リクエストをルーティングするパス ● backend: ○ リクエストを流す Service を指定しているが、その他のリソースも指定可能 ○ GCS のストレージなども指定可能だったりする

Slide 64

Slide 64 text

# Tips - 複数マニフェストを同一ファイルに記述 - “---” で区切ることによって複数のマニフェストを同一ファイルに書ける - Ingress のホストは * を指定できる - あらゆるホストへのリクエストをバックエンドの Pod に流せるが、あまり使わない - Ingress の作成時間 - 裏でクラウドごとに LB やファイヤウォールのリソースを作成していたりするので意外と時間がかかる。気長に待ちましょう

Slide 65

Slide 65 text

問題 3 • Examples の Ingress で /bar でアクセスしたとき `bar` を返すようにしてみよう • 超上級者向け • Examples の Ingress で TLS 終端してみよう自己署名証明書で終端してください (Let’s encrypt やその他正式な認証局による証明書はなし) cert-manager を使わずに openssl コマンドで証明書を作成してみよう curl --cacert ./ca.crt https://echo.info/foo --resolve echo.info:443:127.0.0.1 が通ればOK

Slide 66

Slide 66 text

今回説明できなかったリソース • Secret : その名の通り秘密情報をもつリソース • ConfigMap : 何らかの設定情報をもつリソース • Job & CronJob : 周期的、または何かを起点にした OneShot なコンテナの起動を行うリソース • DaemonSet : ノード単位で Pod をデプロイするリソース • PersistentVolume : コンテナのライフサイクルとは独立した永続化ボリュームを表現するリソース • Role & RoleBinding & ServiceAccount : Kubernetes のリソースに対しての認証認可を司るリソース

Slide 67

Slide 67 text

今回説明できなかった仕組み • requests & limits Pod 単位で CPU や Memory の割り当てについて指定できる • コンテナライフサイクル preStop, preStart : コンテナの起動、終了に任意の処理を挟み込む仕組み livenessProbe, readinessProbe : コンテナが起動しているか、準備完了かをチェックする仕組み

Slide 68

Slide 68 text

1.Kubernetes とは何か 2.Kubernetes Basic Hands On 3.Kubernetes の仕組み 4.業務で使いそうなエコシステムの紹介

Slide 69

Slide 69 text

Kubernetes 内部の仕組み • 知らなくてもそこまで困らないけど、やはり知っておくと色々トラブルシューティングする時楽なので軽く触れます • 詳しくコアコンポーネントの仕様とか動きを知りたい人は「Kubernetes The Hard Way」とググって一から Kubernetes を構築してみよう！ • ちなみに弊社でも「おうちk8sインターン」というので Raspberry Pi4 にベアメタルK8sを構築するというのをやっていて手順も公開されているのでよかったらZehi

Slide 70

Slide 70 text

Kubernetes 内部の仕組み Kubernetes Nodes kubelet + kube-proxy kube-apiserver LoadBalancer データストアとして利用 kube-scheduler Pod のスケジューリング自ノードに割り当てられてる Pod があれば起動 kube-controller-manager Deployment などのリソースの制御 kube-dns 名前解決サービスディスカバリ図引用: Kubernetes 完全ガイド第一版

Slide 71

Slide 71 text

etcd • Kubernetes で扱う全ての情報が保存されているため単一障害点になりうる。冗長化必須 • Raft という分散合意アルゴリズムが使われている KVS です • etcd のデータが壊れればクラスタも壊れる

Slide 72

Slide 72 text

kube-apiserver • Kubernetes の API を提供するコンポーネントです • kubectl コマンドは kube-apiserver に対してリクエストを送っています • 受け付けたリクエストを etcd に書き込んだり、読み込んだりする • kube-scheduler や kubelet といったコンポーネントも kube-apiserver にリクエストを送り、処理を行っている • kube-apiserver が死ぬとクラスタが操作不能になるのでこれも冗長化必須

Slide 73

Slide 73 text

kube-scheduler • kube-apiserver からまだノードで起動していない Pod の情報を受け取り、どのノードで起動するかの情報を etcd に書き込む • 実際の Pod の起動は kubelet が行う

Slide 74

Slide 74 text

kube-controller-manager • リソースの状態を Desired State を持っていくために様々な処理を行うコントローラ • 例えば Pod が 3つ動いて欲しいが2つしかないとき、Pod の情報を etcd に追加したりする • 組み込みのリソースのコントローラは全て kube-controller-manager で処理される • 運用者独自のリソースとコントローラを導入したい場合は「CustomResourceDefinition」と「Custom Controller」という仕組みを使います

Slide 75

Slide 75 text

kubelet • kubelet は各ノード上で稼働するコンポーネントです • Docker などのコンテナランタイムを呼び出して、実際にコンテナの起動や停止などを行います • kube-scheduler によって Pod が起動されるノードが決定すると、それを検知して自身で起動すべきコンテナを起動します • Docker 以外でも OCI というコンテナランタイムのインタフェースに則ったランタイムであれば利用可能です(e.g. Containerd, CRI-O, gVisor) • ちなみに Docker は kubelet のランタイムとしては v1.24 で使用できなくなるので注意

Slide 76

Slide 76 text

kube-proxy • kube-proxy もノード上で動作するコンポーネントです • Service リソースを作成した際に、仮想的な IP 宛のトラフィックを対象の Pod へ転送されるようにします • 実際にはノードの iptables や IPVS のような Linux カーネルに組み込まれてるネットワークトラフィックを制御する仕組みをラップして、トラフィックの転送を実現しています

Slide 77

Slide 77 text

kube-dns • Kubernetes クラスタ内部の名前解決やサービスディスカバリに利用される DNS です • Pod からのリクエストを解決する際は、まず kube-dns に問合せが行われ、それでも解決できない場合は上流の DNS で解決を試みます • 最初から kube-dns ではなく、自前で建てた DNS に解決させたい場合も Pod 側で個別に設定可能

Slide 78

Slide 78 text

1.Kubernetes とは何か 2.Kubernetes Basic Hands On 3.Kubernetes の仕組み 4.業務で使いそうなエコシステムの紹介

Slide 79

Slide 79 text

Argo CD • GitOps な CI/CD を構築可能 • Argo Rollouts を使って Blue/Green や Canary といった高度なデプロイも可能 • 手動のマニフェストデプロイが必要なくなるのでかなり便利

Slide 80

Slide 80 text

Prometheus / Grafana • 様々な Exporter からメトリクスを収集してクエリをかけることが可能なモニタリングツール • Grafana はそれのビジュアライズ担当 • Exporter は特定のフォーマットに従えばいいので拡張性が高い

Slide 81

Slide 81 text

Istio • Service Mesh の代表格 • サイドカーでサーキットブレイクや HTTPS 終端、認証といった処理を担うことができる • Kubernetes 上で一貫したネットワークポリシーやロギングなどが可能 • 大規模な分散システムでは役立つ

Slide 82

Slide 82 text

参考資料集 - Kubernetes 完全ガイド - https://speakerdeck.com/inductor/kubernetes-networking-beginners-guide