Kubernetes入門【サイボウズ新人研修2025】

Transcript

1. Kubernetes入門 2025年度 開運研修 1
2. 目次 ▌コンテナオーケストレーション ▌Kubernetesとは ▌Kubernetesの構造と動作 ▌ローカルで動くKubernetesクラスタ ▌Kubernetesの代表的なリソース ▌まとめ 2
3. コンテナオーケストレーション ▌ アプリケーションをコンテナ化することにより、数百・数千のコンテナを管理する必要が出てくる ▌ コンテナオーケストレーションが無いと・・・ ⚫ デプロイのたびに1個1個docker run ⚫ コンテナの設定は手作業orスクリプトで管理 ⚫ コンテナが止まるたびにdocker runしなおし 運用・管理を自動化したい →コンテナオーケストレーション (代表例: Kubernetes, Docker Swarm, Apache Mesosなど) 3
4. Kubernetesとは ▌ コンテナを複数のサーバー上で協調動作、管理するためのシステム(=コンテナオーケストレーション) ▌ Googleの社内で使用していた「borg」を元にして作られた 主要な機能 ⚫ 宣言的なリソースの管理 ⚫ 「あるべき状態」を定義する ⚫ スケジューリング ⚫ アプリケーションを複数のサーバーに適切にスケジュールする ⚫ サービスディスカバリーと負荷分散 ⚫ アプリケーション間の通信を容易にし、負荷分散を可能にする ⚫ セルフヒーリング ⚫ コンテナに障害が発生した際の自動回復 4
5. Kubernetesが解決する問題 ▌運用の自動化 ⚫ デプロイのたびに煩雑なオペレーションを行わなくて済む ▌高可用性 ⚫ ローリングアップデート ⚫ 障害が発生したときの自動回復 ⚫ 負荷分散 ▌サーバ群の抽象化 ⚫ ユーザはサーバ1個1個のことを考えずに、大量のサーバー上にアプリケーションをデ プロイできる 5
6. Kubernetesの構造 6
7. Kubernetesの構造 7 control-plane クラスタを管理するためのコンポーネントの総称 • etcd • kube-apiserver • kube-scheduler • kube-controller-manager Node アプリケーションがデプロイされるサーバ(数台~数千台) • kubelet • kube-proxy CLIツールやプログ ラム等からの操作
8. コントロールプレーン control-plane クラスタを管理するための領域 • etcd • kube-apiserver • kube-scheduler • kube-controller-manager
9. コントロールプレーンコンポーネント ▌ etcd • 分散KVS(Key-Value Store) • リソースの情報が保存されるデータベースのようなもの ▌ kube-apiserver • リソースにアクセスするためのAPIサーバ • ユーザーや各コンポーネントからの操作はすべてkube-apiserverを経 由する • etcdに保存された情報を用いる ▌ kube-scheduler • 作成されたPod*をどのNodeに配置するかを決定する • *Pod:アプリケーションをデプロイする単位のこと(後で説明) • 配置には様々な条件式や設定が存在する ▌ kube-controller-manager • リソースの状態を管理するコンポーネント • リソースの状態を監視し、あるべき状態になるように操作する 9
10. ノード 10 Node アプリケーションがデプロイされるサーバ(数台~数千台) • kubelet • kube-proxy
11. ノードコンポーネント ▌ kubelet ⚫ Node上のコンテナを管理する ⚫ スケジュールされたPodの作成や死活監視などを行う ⚫ コンテナランタイムのインタフェース(CRI)を通じてコンテナ の操作を行う ▌ kube-proxy ⚫ Podへの通信の設定を行うコンポーネント ⚫ Linuxのネットワーク機能を用いてパケットの転送を行う 11
12. Kubernetesの動作 12
13. 宣言的な構成管理 ▌Kubernetesはリソースの「あるべき状態」をmanifestで定義し、システムはそれを 満たすように動作する(=reconcile) 13 ◼ 宣言的 (k8sのmanifestなど) ◼ 結果が同じになる ◼ 管理が容易 ◼ 手続き的 (Dockerfileなど) ◼ 結果が変わることがある ◼ 直感的な記述 apiVersion: v1 kind: Pod metadata: name: my-first-pod labels: component: nginx spec: containers: - name: nginx image: nginx:latest Podの定義 • 名前はmy-first-pod • component:nginxと いうラベルを付与 コンテナの定義 Nginxのコンテナを使う FROM nginx:latest COPY ./html /usr/share/nginx/html RUN apt-get update && \ apt-get install -y curl 1. ファイルをコピー 2. apt update 3. curlをインストール 4. …
14. Reconcileループ ⚫ あるべき状態と現在の状態を比較し、差分を無くすように処理を行う ⚫ 結果があるべき状態に自動的に収束する 14 https://zoetrope.github.io/kubebuilder-training/introduction/basics.html 例: nginxのDeployment 3つのnginxのPodがある状態が「あるべき状態」 • 現在のPodの数を観測して • 3個未満ならPodを増やす • 4個以上ならPodを削除する
15. ローカルで動くKubernetesクラスタ 15
16. ローカルで動くKubernetesクラスタ ▌kindというソフトウェアで、ローカル環境にKubernetesクラスタを作ることができる ▌NecoではE2Eテストや開発時の動作確認に使用している ▌DockerコンテナでKubernetesノードを動かし、その中でPodが動作する ⚫ Docker in Docker 16 https://kind.sigs.k8s.io/ https://kind.sigs.k8s.io/docs/design/initial
17. ローカルで動くKubernetesクラスタ kind以外のもの ▌minikube ⚫ VMベース、kindで動かないものがあるときに使っている ▌kubeadm ⚫ Kubernetesクラスタを構築するための公式ツール ⚫ Kubernetesのコンポーネント自体をいじりたい場合に使う ⚫ 仮想環境ではなく生のk8sコンポーネントが動く 17
18. Kubernetesの代表的なリソース 18
19. Pod ▌ アプリケーションをデプロイするための最小単位 ⚫ 1個以上のコンテナをまとめたもの ▌ Pod毎にIPアドレスを持ち、各コンテナはnetwork namespaceを共有する ▌ PID namespaceはコンテナ毎に別々(共有することも 可能) ▌ ファイルシステムもコンテナ毎に別々 19 複数コンテナのよくある使い方 1. アプリケーションのコンテナ 2. Proxyなどのコンテナ 3. メトリクスやログを取るコンテナ をまとめてPodにする
20. Podの作成 20 apiVersion: v1 kind: Pod metadata: name: my-first-pod labels: component: nginx spec: containers: - name: nginx image: nginx:latest $ kubectl apply –f nginx-pod.yaml でmanifestを適用する ❯ kubectl apply -f nginx-pod.yaml pod/my-first-pod created # Podの名前 # コンテナの名前 # Podにつけるラベル # コンテナイメージ nginx-pod.yaml # リソースの種類 # コンテナの配列 # リソースが所属するグループとバージョン
21. デプロイしたPodの確認 21 ❯ kubectl get pod NAME READY STATUS RESTARTS AGE my-first-pod 1/1 Running 0 3m47s ❯ kubectl exec -it my-first-pod -- bash root@my-first-pod:/# curl -i localhost:80 HTTP/1.1 200 OK Server: nginx/1.25.4 … $ kubectl get pod でpod一覧を取得 $ kubectl execでPodの中に入りシェルを実行、curlでnginxの動作を確認 ← my-first-podが作られている
22. Podが作られるまで ▌ manifestを適用(kubectl apply)するとetcd(データベース)にPodのmanifestが保存される ▌ kube-apiserver経由でPodをwatchしているkube-schedulerが新しいPodの作成を検知し、スケジューリン グする ▌ kube-apiserver経由でPodをwatchしている各ノードのkubeletが、自分のノードにPodがスケジュールされた ことを検知すると、コンテナランタイムを通じてコンテナを作成する 22
23. Podのライフサイクル 23 ▌ manifestが適用されると、Podが作成され、Pendingとなる ▌ PodがNodeにスケジュールされると、そのNodeのkubeletがコンテナを起動し、Runnningに入る ▌ その後、正常終了すればSucceeded,異常終了すればFailedとなる ▌ HTTPサーバのような、動き続けるプロセスはずっとRunningになる コンテナのアップデートやNodeの再起動・故障 などで消される →Podのライフサイクルは短い Podの状態遷移
24. Podのライフサイクルの確認 24 ❯ kubectl get pod -w NAME READY STATUS RESTARTS AGE my-first-pod 0/1 Pending 0 0s my-first-pod 0/1 Pending 0 0s my-first-pod 0/1 ContainerCreating 0 0s my-first-pod 1/1 Running 0 4s ▌ kubectl get に–wオプションを付けると変更をwatchすることができる ❯ kubectl apply -f nginx-pod.yaml pod/my-first-pod created Podを作成すると、Pending→Runningに推移することがわかる
25. ReplicaSet & Deployment ▌ ReplicaSet ⚫ 負荷分散・可用性のために、複数のPodをまとめたもの ⚫ ※Replicaset単体で使う事はほぼない ▌ Deployment ⚫ ReplicaSetを用いてローリングアップデートの機能などを提供 する ▌ ReplicaSetのセルフヒーリング ⚫ ReplicaSetは指定した数のPodが動作することを保証する ⚫ Node故障などでPodが消されると、新しく作り直す 25 Nodeの故障などでPodを作り直す例
26. Deploymentのローリングアップデート ▌ コンテナのアップデートなど、再起動を伴う場合に提供しているサービスが止まらないように、一気に更新するのではなく少しづづ更新を行 う仕組み ▌ ReplicaSetを新旧で用意しreplica数を変えることで実現する 26 1. 新しいReplicaSetを作る 2. 新しいReplicaSetの方に新しいPodを1個作る 3. 古いReplicaSetのPodを1個消す 4. 2,3を繰り返す 何個ずつ行うかはパラメータで設定できる
27. Deploymentの作成 27 apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment labels: component: nginx spec: replicas: 3 selector: matchLabels: component: nginx template: metadata: labels: component: nginx spec: containers: - name: nginx image: nginx:1.20 nginx-deployment.yaml # Podのレプリカ数 # Deployment配下のPodを識別するためのラベル # 作成するPodの内容 ▌ .spec以下にDeploymentの設定を書く ▌ .spec.replicsasがレプリカ数の設定 ▌ .spec.selectorで配下にするPodの指定をする ▌ .spec.templateにPodのテンプレートを書く
28. デプロイしたDeploymentの確認 28 ❯ kubectl get deployment NAME READY UP-TO-DATE AVAILABLE AGE nginx-deployment 3/3 3 3 28m ❯ kubectl get pod NAME READY STATUS RESTARTS AGE nginx-deployment-6655674d65-bvxqm 1/1 Running 0 26m nginx-deployment-6655674d65-pbvnf 1/1 Running 0 26m nginx-deployment-6655674d65-pqhcz 1/1 Running 0 26m nginxのPodが3つデプロイされている
29. Deploymentのセルフヒーリングを試す 29 ❯ kubectl delete pod nginx-deployment-6566fcf8b5-bcl2s pod "nginx-deployment-6566fcf8b5-bcl2s" deleted ❯ kubectl get pod NAME READY STATUS RESTARTS AGE nginx-deployment-6655674d65-lvb5m 1/1 Running 0 3s nginx-deployment-6655674d65-pbvnf 1/1 Running 0 25m nginx-deployment-6655674d65-pqhcz 1/1 Running 0 25m DeploymentのPodを１個消してみる 新たに１個作成され、Pod３個の状態が復元される NEW
30. Service ▌ Podとの通信を抽象化する ▌ 負荷分散の機能を持つ ▌ Podと通信をする時に、Podの名前やIPアドレスの直接指定は基本的にしない ⚫ Podのライフサイクルは短いので、IPアドレスはすぐに変わる ⚫ 特定のPodではなく、「ある機能を持つPodのどれか」で指定したい ▌ 4つのタイプがある ⚫ ClusterIP: クラスタ内のみでアクセスできる ⚫ NodePort: 各Nodeの指定したポートに来たトラフィックをPodに転送する ⚫ LoadBalancer: 外部のロードバランサーを利用してトラフィックを転送する ⚫ ExternalName:クラスタ外のドメインをServiceのCNAMEに登録する NodePort,LoadBalancerを使うことでクラスタ外からのアクセスを受け付けられる 30
31. Pod間の通信 31 apiVersion: v1 kind: Pod metadata: name: bastion spec: containers: - name: bastion image: debian:stable command: ["sleep", "infinity"] Pod間の通信を行う方法 ①PodのIPアドレスを使う ②ServiceのClusterIPを使う bastion.yaml アクセスする側のPodを作成する $ kubectl apply -f bastion.yaml でmanifest適用 Bastion Pod nginx Pod Kubernetesクラスタ HTTP nginx Pod nginx Pod
32. Pod間の通信① 直接通信 32 ❯ kubectl get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES bastion 1/1 Running 0 116m 10.244.0.6 kind-control-plane <none> <none> my-first-pod 1/1 Running 0 136m 10.244.0.5 kind-control-plane <none> <none> ・・・ ❯ kubectl exec -it bastion -- bash root@bastion:/# apt update && apt install -y curl root@bastion:/# curl -i http://10.244.0.5 HTTP/1.1 200 OK Server: nginx/1.25.4 NginxのPodのIPアドレスは10.244.0.5 $ kubectl get pod でpod一覧を取得 $ kubectl execでbastion Podの中に入りシェルを実行、curlでnginx PodのIPアドレスにリクエストしてみる Bastion Pod nginx Pod Kubernetesクラスタ curl 10.244.0.5 10.244.0.5 10.244.0.6
33. Pod間の通信② Serviceを使った通信 33 apiVersion: v1 kind: Service metadata: name: my-first-service spec: type: CluterIP selector: component: nginx ports: - protocol: TCP port: 80 targetPort: 80 my-first-serviceにアクセスが来ると、配下のnginxのPodにトラフィックが振り分けられる ▌ Nodeの障害などでPodが減った場合、そのPodは振り分け先から自動的に外される ▌ Deploymentのセルフヒーリングによって新たにPodが作られた場合、振り分け先に自動的に追 加される # ClusterIP, NodePort,LoadBalancer, ExternalNameから選ぶ # トラフィックを流す先のPodを指定する # 待ち受けるPortやプロトコルの設定 Bastion Pod nginx Pod Kubernetesクラスタ Service nginx Pod nginx Pod ロードバランス
34. Pod間の通信② 34 ❯ kubectl get service NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 160m my-first-service ClusterIP 10.96.207.133 <none> 80/TCP 4s ❯ kubectl exec -it bastion -- bash root@bastion:/# curl -i http://my-first-service/ HTTP/1.1 200 OK Server: nginx/1.25.4 $ kubectl execでbastion Podの中に入りシェルを実行 curlでserviceにリクエストを送る ※Kubernetes内にServiceのIPアドレスと名前を解決するDNSがあるので、Serviceの名前でアクセスできる Serviceが作られている
35. Kubernetesクラスタ 外部からのリクエストを受け付ける ▌ type:NodePort, LoadblancerのServiceを使うことでKubernetesの外からのリクエストを受け 付けることができる ▌ 最も簡単なNodePortを使ってみる ⚫ 各ノードの指定したポートに来たトラフィックをPodに流すService 35 apiVersion: v1 kind: Service metadata: name: my-first-service spec: type: NodePort selector: component: nginx ports: - protocol: TCP port: 80 targetPort: 80 nodePort: 30000 # NodePortを指定 nginx Pod nginx Pod nginx Pod Node1 :30000 Node2 :30000 client
36. 36 ❯ docker exec -it kind-worker bash root@kind-worker:/# root@kind-worker:/# curl –i localhost:30000 HTTP/1.1 200 OK Server: nginx/1.27.5 外部からのリクエストを受け付ける kindでkubernetesクラスタを作っているのでノードがDockerコンテナになっている Dockerコンテナの中に入ってNodePortのポートにアクセスする Kubernetesクラスタ nginx Pod nginx Pod nginx Pod kind-woker :30000
37. リソースのまとめ ▌Podは複数コンテナをまとめたもの、最小単位 ▌Deploymentを使ってPodを作ると負荷分散・セルフヒーリング・ローリングアップデー トを行うことができる ▌Serviceを使うことで、複数のPodにロードバランスできるエンドポイントを作成できる Deployment+Serviceが使えれば基本的なWebアプリケーションはデプロイできる！ 37
38. 全体まとめ ▌Kubernetesの基礎知識と、アプリケーションをデプロイする方法について学 びました。 ▌より詳しいことを学びたい場合、以下の情報をお勧めしています。 ⚫ 公式ドキュメント https://kubernetes.io/docs/concepts/overview/ ⚫ Introduction to Kubernetes https://cybozu.github.io/introduction-to-kubernetes/ ⚫ Kubernetes完全ガイド https://book.impress.co.jp/books/1119101148 ⚫ つくって学ぶKubebuilder https://zoetrope.github.io/kubebuilder-training/ 38