Kubernetes入門 2024年度 開運研修 クラウド基盤本部 CloudPlatform Necoチーム 三村 柚貴 1

目次 (前半) ▌ コンテナオーケストレーションの必要性 ▌ Kubernetesとは ▌ サイボウズとKubernetes ▌ Kubernetesの構造と動作 ▌ Kubernetesの代表的なリソース ▌ Kubernetesクラスタへのアクセス (後半) ▌ 実際にKubernetesクラスタに触れてみる 2

この講義の目的 ▌ サイボウズの新基盤「Neco」で使われているKubernetesの技術について学ぶ ⚫ コンテナオーケストレーションの重要性 ⚫ Kubernetesの仕組み ⚫ 代表的なリソース ▌ 各チームに配属後、 Kubernetesを利用する際の足掛かり ⚫ アプリケーションのデプロイ方法 3

コンテナオーケストレーション ▌ アプリケーションをコンテナ化することにより、数百・数千のコンテナを管理する必要が出てくる ▌ コンテナオーケストレーションが無いと・・・ ⚫ デプロイのたびに1個1個docker run ⚫ コンテナの設定は手作業orスクリプトで管理 ⚫ コンテナが止まるたびにdocker runしなおし これは無理！ 運用・管理を自動化したい →コンテナオーケストレーション (代表例: Kubernetes, Docker Swarm, Apache Mesosなど) 4

Kubernetesとは ▌ コンテナを複数のサーバー上で協調動作、管理するためのシステム(=コンテナオーケストレーション) ▌ Googleの社内で使用していた「borg」を元にして作られた 主要な機能 ⚫ 宣言的なリソースの管理 ⚫ 「あるべき状態」を定義する ⚫ スケジューリング ⚫ アプリケーションを複数のサーバーに適切にスケジュールする ⚫ サービスディスカバリーと負荷分散 ⚫ アプリケーション間の通信を容易にし、負荷分散を可能にする ⚫ セルフヒーリング ⚫ コンテナに障害が発生した際の自動回復 5

Kubernetesが解決する問題 ▌ 運用の自動化 ⚫ デプロイのたびに煩雑なオペレーションを行わなくて済む ▌ 高可用性 ⚫ ローリングアップデート ⚫ 障害が発生したときの自動回復 ⚫ 負荷分散 ▌ サーバ群の抽象化 ⚫ ユーザはサーバ1個1個のことを考えずに、大量のサーバー上にアプリケーションをデ プロイできる 6

サイボウズとKubernetes ▌ cybozu.comの新基盤「Neco」はKubernetesベース ⚫ 旧基盤からNeco基盤への移行プロジェクトが進行中 ▌ Yakumoチーム(北米版kintone)では、AWSのマネージドKubernetes を用いてサービス提供中 ▌ 運用チームはアプリケーションをデプロイするプラットフォームを提供 ▌ 開発チームはそのプラットフォーム上にアプリケーションを構築し運用する ⚫ →アプリケーション開発者もKubernetesの知識が必要に 7

Kubernetesの構造 8

Kubernetesの構造 9 control-plane クラスタを管理するためのコンポーネントの総称 • etcd • kube-apiserver • kube-scheduler • kube-controller-manager Node アプリケーションがデプロイされるサーバ(数台~数千台) • kubelet • kube-proxy CLIツールやプログ ラム等からの操作

コントロールプレーンコンポーネント ▌ etcd • 分散KVS • リソースの情報が保存される ▌ kube-apiserver • リソースにアクセスするためのAPIサーバ • ユーザーや各コンポーネントからの操作はすべてkube-apiserverを経 由する • etcdに保存された情報を用いる ▌ kube-scheduler • 作成されたPod*をどのNodeに配置するかを決定する • *Pod:アプリケーションをデプロイする単位のこと(後で説明) • 配置には様々な条件式や設定が存在する ▌ kube-controller-manager • リソースの状態を管理するコンポーネント • リソースの状態を監視し、あるべき状態になるように操作する 10

ノードコンポーネント ▌ kubelet ⚫ Node上のコンテナを管理する ⚫ スケジュールされたPodの作成や死活監視などを行う ⚫ コンテナランタイムのインタフェース(CRI)を通じてコンテナ の操作を行う ▌ kube-proxy ⚫ Podへの通信の設定を行うコンポーネント ⚫ Linuxのネットワーク機能を用いてパケットの転送を行う 11

Kubernetesの動作 12

Kubernetesリソース ▌ Kubernetes上で管理されるもののことを「リソース」*と呼び、「manifest」と呼ばれるデータで定 義される ▌ ユーザーはmanifestファイルをYAML/JSONフォーマットで作成し適用することで、Kubernetes にリソースをデプロイできる ※正確にはKubernetes上で管理されるものの構造自体は「オブジェクト」と呼び、そのAPIエンドポイントを「リソース」と呼 ぶ 13

宣言的な構成管理 ▌ Kubernetesはリソースの「あるべき状態」をmanifestで定義し、システムはそれを 満たすように動作する(=reconcile) 14 apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment labels: app: nginx spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.14.2 ports: - containerPort: 80 Deploymentリソースの定義 app:nginxのラベルがついたPodが3個必要 Podリソースの定義 Nginxのコンテナを動かし、80番ポート を使う ※PodやDeploymentの概念は後で説明します ※例 手続的 宣言的 シェルスクリプトで作った インストールスクリプト Kubernetesのmanifest

Reconcileループ ⚫ あるべき状態と現在の状態を比較し、差分を無くすように処理を行う ⚫ 結果があるべき状態に自動的に収束する 15 https://zoetrope.github.io/kubebuilder-training/introduction/basics.html 前ページのNginxのDeploymentを例にすると… • 3つのnginxのPod(コンテナ)がある状態が「あるべき状態」 • 現在のPodの数を観測して • 3個未満ならPodを増やす • 4個以上ならPodを削除する

Kubernetesの代表的なリソース 16

Pod ▌ アプリケーションをデプロイするための最小単位 ⚫ 1個以上のコンテナをまとめたもの ▌ Pod毎にIPアドレスを持ち、各コンテナはnetwork namespaceを共有する ▌ PID namespaceはコンテナ毎に別々(共有することも 可能) ▌ ファイルシステムもコンテナ毎に別々 17 よくある使い方 • アプリケーションのコンテナ • Proxyなどのコンテナ • メトリクスやログを取るコンテナ をまとめてPodにする

Podのmanifest ▌ .spec以下にPodの設定を書く ▌ .spec.containers[]の配列にコンテナの設定を 書いていく ▌ .spec.containers[].commandがDockerの ENTRYPOINTに相当する 18 apiVersion: v1 # リソースが属するグループの名前 kind: Pod # リソースの種類 metadata: name: my-pod # Podの名前 spec: containers: # コンテナの設定 - name: container-1 # 1つめのコンテナの設定 image: ubuntu:latest command: ["sleep", "infinity"] - name: container-2 # 2つめのコンテナの設定 image: ubuntu:latest command: ["sleep", "infinity"]

Podが作られるまで ▌ manifestをapplyするとetcdにPodの定義が保存される ▌ kube-apiserver経由でPodをwatchしているkube-schedulerが新しいPodの作成を検知し、スケジューリン グする ▌ kube-apiserver経由でPodをwatchしている各ノードのkubeletが、自分のノードにPodがスケジュールされた ことを検知すると、コンテナランタイムを通じてコンテナを作成する 19

Podのライフサイクル 20 ▌ manifestが適用されると、Podが作成され、Pendingとなる ▌ PodがNodeにスケジュールされると、そのNodeのkubeletがコンテナを起動し、Runnningに入る ▌ その後、正常終了すればSucceeded,異常終了すればFailedとなる ▌ HTTPサーバのような、動き続けるプロセスはずっとRunningになる コンテナのアップデートやNodeの再起動・故障 などで消される →Podのライフサイクルは短い Podの状態遷移

ReplicaSet & Deployment ▌ ReplicaSet ⚫ 負荷分散・可用性のために、複数のPodをまとめたもの ⚫ ※Replicaset単体で使う事はほぼない ▌ Deployment ⚫ ReplicaSetを用いてローリングアップデートの機能などを提供 する ▌ ReplicaSetのセルフヒーリング ⚫ ReplicaSetは指定した数のPodが動作することを保証する ⚫ Node故障などでPodが消されると、新しく作り直す 21 Nodeの故障などでPodを作り直す例

Deploymentのローリングアップデート ▌ コンテナのアップデートなど、再起動を伴う場合に提供しているサービスが止まらないように、一気に更新するのではなく少しづづ更新を行 う仕組み ▌ ReplicaSetを新旧で用意しreplica数を変えることで実現する 22 1. 新しいReplicaSetを作る 2. 新しいReplicaSetの方に新しいPodを1個作る 3. 古いReplicaSetのPodを1個消す 4. 2,3を繰り返す 何個ずつ行うかはパラメータで設定できる

Deploymentのマニフェスト 23 apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment spec: replicas: 3 # Podのレプリカ数 selector: matchLabels: # app:nginxのラベルを持つPodを配下にする app: nginx template: # 作成するPodのテンプレート metadata: labels: app: nginx # app:nginxのラベルをつける spec: containers: - name: nginx image: nginx:1.14.2 ports: - containerPort: 80 ▌ .spec以下にDeploymentの設定を書く ▌ .spec.replicsasがレプリカ数の設定 ▌ .spec.selectorで配下にするPodの指定をする ▌ .spec.templateにPodのテンプレートを書く

Service ▌ Podとの通信を抽象化する ▌ 負荷分散の機能を持つ ▌ Podと通信をする時に、Podの名前やIPアドレスの直接指定は基本的にしない ⚫ Podのライフサイクルは短いので、IPアドレスはすぐに変わる ⚫ 特定のPodではなく、「ある機能を持つPodのどれか」で指定したい ▌ 4つのタイプがある ⚫ ClusterIP: クラスタ内のみでアクセスできる ⚫ NodePort: 各Nodeの指定したポートに来たトラフィックをPodに転送する ⚫ LoadBalancer: 外部のロードバランサーを利用してトラフィックを転送する ⚫ ExternalName:クラスタ外のドメインをServiceのCNAMEに登録する NodePort,LoadBalancerを使うことでクラスタ外からのアクセスを受け付けられる 24

Serviceのmanifest 25 apiVersion: v1 kind: Service metadata: name: nginx-service spec: type:ClusterIP # Serviceのtypeを指定する selector: app: nginx # app:nginxのラベルを持つPodにトラフィックを流す ports: - protocol: TCP port: 80 # Serviceが公開するポート targetPort: 80 # トラフィックを流す先のPodのポート apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment spec: replicas: 3 # Podのレプリカ数 selector: matchLabels: # app:nginxのラベルを持つPodを配下にする app: nginx template: # 作成するPodのテンプレート metadata: labels: app: nginx # app:nginxのラベルをつける spec: containers: - name: nginx image: nginx:1.14.2 ports: - containerPort: 80 ↓のDeploymentに対するService .spec.typeでServiceのtypeを ClusterIP, NodePort, LoadBalancer, ExternalName から選ぶ .spec.selectorで対象のPodを選択する .spec.portsでプロトコルやポートの設定を行う

Serviceのmanifest 先ほどのmanifestの例を挙げると・・・ nginx-service.default.svc.cluster.local:80 にアクセスが来ると、配下のnginxのPodにトラフィックが振り分けられる ▌ Nodeの障害などでPodが減った場合、そのPodは振り分け先から 自動的に外される ▌ Deploymentのセルフヒーリングによって新たにPodが作られた場合、 振り分け先に自動的に追加される 26 apiVersion: v1 kind: Service metadata: name: nginx-service spec: type:ClusterIP # Serviceのtypeを指定する selector: app: nginx # app:nginxのラベルを持つPodにトラフィックを流す ports: - protocol: TCP port: 80 # Serviceが公開するポート targetPort: 80 # トラフィックを流す先のPodのポート

リソースのまとめ ▌ Pod・・・複数コンテナをまとめたもの ▌ アプリケーションをデプロイする際は負荷分散・セルフヒーリング・ローリングアップデート のために、Deploymentを使う ▌ Serviceを使うことで、Deploymentで作った複数のPodに単一的に接続できる 27

Kubernetesクラスタへのアクセス 28

Kubernetesクラスタへのアクセス ▌ Kubernetesクラスタへのアクセスは、全てkube-apiserverを通じて行われる ▌ REST APIでリソースの操作や取得を行う ▌ 人間が操作する時はCLI(kubectl)を使う ▌ プログラムからアクセスする時はクライアントライブラリを使う ⚫ Go: client-go (https://github.com/kubernetes/client-go) 29

kubectl ▌ Kubernetesクラスタを操作するためのCLIツール よく使うコマンド ▌ リソースの状態の取得(一覧) ⚫ kubectl get <リソース名> kubectl get pod ▌ リソースの状態の取得(個別) ⚫ kubectl get <リソース名> <名前> ⚫ 例:kubectl get pod example-pod ▌ manifestの適用 ⚫ kubectl apply –f <ファイル名> ⚫ 例: kubectl apply –f example-pod.yaml 30

実際にKubernetesクラスタに触れてみる 31

実際にKubernetesクラスタを作って操作してみる ▌ kindというソフトウェアで、ローカル環境にKubernetesクラスタを作ることができる ▌ DockerコンテナでKubernetesノードを動かし、その中でコンテナが動作する (Docker in Docker) 32 https://kind.sigs.k8s.io/ この章では、以下の資料の一部をかいつまんで説明します。 https://cybozu.github.io/introduction-to- kubernetes/introduction-to-kubernetes.html 興味のある方はご自身の環境でも試してみてください

クラスタの立ち上げ $ kind create cluster でシングルノードのクラスタが立ち上がる Configを書いて指定すると複数ノードも可能 33 ❯ kind create cluster Creating cluster "kind" ... ✓ Ensuring node image (kindest/node:v1.27.3) ✓ Preparing nodes ✓ Writing configuration ✓ Starting control-plane ✓ Installing CNI ✓ Installing StorageClass Set kubectl context to "kind-kind" You can now use your cluster with: kubectl cluster-info --context kind-kind Have a question, bug, or feature request? Let us know! https://kind.sigs.k8s.io/#community

クラスタの確認 34 ❯ kubectl get node NAME STATUS ROLES AGE VERSION kind-control-plane Ready control-plane 2m31s v1.27.3 $ kubectl get node でノード一覧を取得 1ノード作られていることがわかる

Podをデプロイしてみる 35 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

デプロイしたPodの確認 36 ❯ 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が作られている

Podとの通信① 37 apiVersion: v1 kind: Pod metadata: name: bastion spec: containers: - name: bastion image: debian:stable command: ["sleep", "infinity"] Pod間の通信を行う方法 ①PodのIPアドレスを使う ②ServiceのClusterIPを使う ←まずはこちらを試す bastion.yaml $ kubectl apply -f bastion.yaml でmanifst適用 Bastion Pod nginx Pod Kubernetesクラスタ HTTP

Podとの通信① 38 ❯ 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 my-first-pod 1/1 Running 0 136m 10.244.0.5 kind-control-plane ❯ 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

Podとの通信② ▌ PodのIPアドレスを使ってPod間で通信できることを確認した。 ▌ Kubernetesにおいて、Podは再デプロイやスケールする際に増えたり消えたりする。 ⚫ PodのIPアドレスを指定していると、通信できなくなる ▌ 特定の1個のPodではなく、ラベル指定で通信相手を指定したい ▌ →Service(ClusterIP)を用いる 39

Podとの通信② 40 apiVersion: v1 kind: Service metadata: name: my-first-service spec: selector: component: nginx ports: - protocol: TCP port: 80 targetPort: 80 nginx-service.yaml #ここで設定したラベルを持つPod にトラフィックが振り分けられる 同様にこのmanifestを適用して Serviceをデプロイする Bastion Pod nginx Pod Kubernetesクラスタ Service

Podとの通信② 41 ❯ kubectl get service NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.96.0.1 443/TCP 160m my-first-service ClusterIP 10.96.207.133 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の中に入りシェルを実行 今度はservice名でリクエストを行う ※Kubernetes内にServiceのIPアドレスと名前を解決するDNSがあるので、Serviceの名前でアクセスできる Serviceが作られている

同じ Pod をいくつも立てる ▌ 前の節のように、複数の同じPodで冗 長構成にするのが一般的 ▌ ReplicaSetを用いて同じPodを指定 しただけ作る この例では、 「component: nginxのラベルを持つ Podを3個デプロイする」 ということになる 42 apiVersion: apps/v1 kind: ReplicaSet metadata: name: nginx-replicaset labels: component: nginx spec: replicas: 3 selector: matchLabels: component: nginx template: metadata: labels: component: nginx spec: containers: - name: nginx image: nginx:latest nginx-replicaset.yaml #Podの数 #ここに一致した条件のPodをReplicaSetが管理する # Podのテンプレート

デプロイしたReplicaSetの確認 43 ❯ kubectl get replicaset NAME DESIRED CURRENT READY AGE nginx-replicaset 3 3 3 7s ❯ kubectl get pod NAME READY STATUS RESTARTS AGE bastion 1/1 Running 0 149m my-first-pod 1/1 Running 0 169m nginx-replicaset-29jmp 1/1 Running 0 10s nginx-replicaset-8ph49 1/1 Running 0 10s 「component: nginxのラベルを持つPod」はすでに1個あったので、追加で2個作成される その際、Podの定義はtemplateに書いた内容が使われる

ReplicaSetの動作の確認 44 ❯ kubectl delete pod my-first-pod pod "my-first-pod" deleted ❯ kubectl get pod NAME READY STATUS RESTARTS AGE bastion 1/1 Running 0 152m nginx-replicaset-29jmp 1/1 Running 0 2m51s nginx-replicaset-8ph49 1/1 Running 0 2m51s nginx-replicaset-cvrv5 1/1 Running 0 4s 「component: nginxのラベルを持つPod」を1個消してみる(my-first-pod) 削除された分、新た1個のPodが作成される

ReplicaSetの動作の確認 45 ❯ vim nginx-replicaset.yaml ❯ kubectl apply -f nginx-replicaset.yaml replicaset.apps/nginx-replicaset configured ❯ kubectl get pod NAME READY STATUS RESTARTS AGE bastion 1/1 Running 0 153m nginx-replicaset-29jmp 1/1 Running 0 3m43s nginx-replicaset-8ph49 1/1 Running 0 3m43s nginx-replicaset-btlk4 1/1 Running 0 3s nginx-replicaset-cvrv5 1/1 Running 0 56s nginx-replicaset.yamlのreplicasを4に変更する replicasが4になり1個足りないので、追加で1個Podがデプロイされる ReplicaSetは定義されたレプリカ数を維持するようにPodを増やしたり減らしたりする

Deploymentを用いてローリングアップデートする ▌ サービスの停止なしでPodをアップデートする ▌ ReplicaSetを用いてローリングアップを行うDeploymentを使う ▌ ※通常ReplicaSet単体で使うことはほぼない 46 1. 新しいReplicaSetを作る 2. 新しいReplicaSetの方に新しいPodを1個作る 3. 古いReplicaSetのPodを1個消す 4. 2,3を繰り返す

Deploymentの作成 47 前の章で作成したReplicaSetは消しておきます $kubectl delete replicaset nginx-replicaset 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 ManifestはReplicaSetとほぼ同じで、リソース名が Deploymentになっているだけ

デプロイしたDeploymentの確認 48 ❯ kubectl get deploy NAME READY UP-TO-DATE AVAILABLE AGE nginx-deployment 3/3 3 3 16s ❯ kubectl get pod -o 'custom- columns=NAME:.metadata.name,IMAGE:.spec.containers[*].image,PHASE:.status.phase' NAME IMAGE PHASE bastion debian:stable Running nginx-deployment-79b59fbc9b-k76vl nginx:1.20 Running nginx-deployment-79b59fbc9b-ppcbj nginx:1.20 Running nginx-deployment-79b59fbc9b-q5zgj nginx:1.20 Running ReplicaSetの時と同様、nginxのPodが3つデプロイされている ※実験のためコンテナイメージのバージョンを表示している

ローリングアップデートしてみる 49 ❯ vim nginx-deployment.yaml ❯ kubectl apply -f nginx-deployment.yaml deployment.apps/nginx-deployment configured ❯ kubectl get pod -o 'custom-columns=NAME:.metadata.name,IMAGE:.spec.containers[*].image,PHASE:.status.phase' NAME IMAGE PHASE bastion debian:stable Running nginx-deployment-6566fcf8b5-bcl2s nginx:1.21 Pending nginx-deployment-79b59fbc9b-k76vl nginx:1.20 Running nginx-deployment-79b59fbc9b-ppcbj nginx:1.20 Running nginx-deployment-79b59fbc9b-q5zgj nginx:1.20 Running ❯ kubectl get replicaset NAME DESIRED CURRENT READY AGE nginx-deployment-6566fcf8b5 2 2 2 5m36s nginx-deployment-79b59fbc9b 2 2 1 6m52s コンテナイメージをnginx:1.20からnginx:1.21に書き換えて適用 新しいReplicaSetで1.21のPodが作られ、置き換えられていくことがわかる

まとめ ▌ Pod,Service,ReplicaSet,Deploymentについて実験を行った ▌ DeploymentとServiceを組み合わせることでアプリケーションの可用性を高めることができる ▌ 補足 ⚫ 冗長度1のアプリケーションの場合でも、セルフヒーリングのためにレプリカ数1のDeploymentで作 成する ⚫ Pod単体の場合、ノードが故障や再起動などで停止した場合にPodも消えてしまう 50

全体まとめ ▌Kubernetesの基礎知識と、アプリケーションをデプロイする方法について 学びました。 ▌より詳しいことを学びたい場合、以下の情報をお勧めしています。 ⚫ 公式ドキュメント https://kubernetes.io/docs/concepts/overview/ ⚫ Kubernetes完全ガイド https://book.impress.co.jp/books/1119101148 ⚫ つくって学ぶKubebuilder https://zoetrope.github.io/kubebuilder-training/ 51