Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

Avatar for Cybozu Cybozu
July 06, 2025
1.5k

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

Avatar for Cybozu

Cybozu

July 06, 2025
Tweet

More Decks by Cybozu

Transcript

  1. Kubernetesとは ▌ コンテナを複数のサーバー上で協調動作、管理するためのシステム(=コンテナオーケストレーション) ▌ Googleの社内で使用していた「borg」を元にして作られた 主要な機能 ⚫ 宣言的なリソースの管理 ⚫ 「あるべき状態」を定義する

    ⚫ スケジューリング ⚫ アプリケーションを複数のサーバーに適切にスケジュールする ⚫ サービスディスカバリーと負荷分散 ⚫ アプリケーション間の通信を容易にし、負荷分散を可能にする ⚫ セルフヒーリング ⚫ コンテナに障害が発生した際の自動回復 4
  2. Kubernetesが解決する問題 ▌運用の自動化 ⚫ デプロイのたびに煩雑なオペレーションを行わなくて済む ▌高可用性 ⚫ ローリングアップデート ⚫ 障害が発生したときの自動回復 ⚫

    負荷分散 ▌サーバ群の抽象化 ⚫ ユーザはサーバ1個1個のことを考えずに、大量のサーバー上にアプリケーションをデ プロイできる 5
  3. Kubernetesの構造 7 control-plane クラスタを管理するためのコンポーネントの総称 • etcd • kube-apiserver • kube-scheduler

    • kube-controller-manager Node アプリケーションがデプロイされるサーバ(数台~数千台) • kubelet • kube-proxy CLIツールやプログ ラム等からの操作
  4. コントロールプレーンコンポーネント ▌ etcd • 分散KVS(Key-Value Store) • リソースの情報が保存されるデータベースのようなもの ▌ kube-apiserver

    • リソースにアクセスするためのAPIサーバ • ユーザーや各コンポーネントからの操作はすべてkube-apiserverを経 由する • etcdに保存された情報を用いる ▌ kube-scheduler • 作成されたPod*をどのNodeに配置するかを決定する • *Pod:アプリケーションをデプロイする単位のこと(後で説明) • 配置には様々な条件式や設定が存在する ▌ kube-controller-manager • リソースの状態を管理するコンポーネント • リソースの状態を監視し、あるべき状態になるように操作する 9
  5. 宣言的な構成管理 ▌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. …
  6. Pod ▌ アプリケーションをデプロイするための最小単位 ⚫ 1個以上のコンテナをまとめたもの ▌ Pod毎にIPアドレスを持ち、各コンテナはnetwork namespaceを共有する ▌ PID

    namespaceはコンテナ毎に別々(共有することも 可能) ▌ ファイルシステムもコンテナ毎に別々 19 複数コンテナのよくある使い方 1. アプリケーションのコンテナ 2. Proxyなどのコンテナ 3. メトリクスやログを取るコンテナ をまとめてPodにする
  7. 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 # リソースの種類 # コンテナの配列 # リソースが所属するグループとバージョン
  8. デプロイした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が作られている
  9. 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に推移することがわかる
  10. ReplicaSet & Deployment ▌ ReplicaSet ⚫ 負荷分散・可用性のために、複数のPodをまとめたもの ⚫ ※Replicaset単体で使う事はほぼない ▌

    Deployment ⚫ ReplicaSetを用いてローリングアップデートの機能などを提供 する ▌ ReplicaSetのセルフヒーリング ⚫ ReplicaSetは指定した数のPodが動作することを保証する ⚫ Node故障などでPodが消されると、新しく作り直す 25 Nodeの故障などでPodを作り直す例
  11. 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のテンプレートを書く
  12. デプロイした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つデプロイされている
  13. 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を1個消してみる 新たに1個作成され、Pod3個の状態が復元される NEW
  14. Service ▌ Podとの通信を抽象化する ▌ 負荷分散の機能を持つ ▌ Podと通信をする時に、Podの名前やIPアドレスの直接指定は基本的にしない ⚫ Podのライフサイクルは短いので、IPアドレスはすぐに変わる ⚫

    特定のPodではなく、「ある機能を持つPodのどれか」で指定したい ▌ 4つのタイプがある ⚫ ClusterIP: クラスタ内のみでアクセスできる ⚫ NodePort: 各Nodeの指定したポートに来たトラフィックをPodに転送する ⚫ LoadBalancer: 外部のロードバランサーを利用してトラフィックを転送する ⚫ ExternalName:クラスタ外のドメインをServiceのCNAMEに登録する NodePort,LoadBalancerを使うことでクラスタ外からのアクセスを受け付けられる 30
  15. 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
  16. 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
  17. 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 ロードバランス
  18. 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が作られている
  19. 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
  20. 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
  21. 全体まとめ ▌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