先日のDocker編の続きのエントリーとなります。Docker編ではVirtualBox上のUbuntuにDockerをインストールし、コマンドラインでコンテナ操作をイチから叩き直しました。今回はその同じ環境をそのまま使い、MinikubeでKubernetesの世界に足を踏み入れます。

参考

uepon.hatenadiary.com

正直なところ、Kubernetesは「なんとなく難しそう」というイメージがずっとありました。Pod、Deployment、Service、ReplicaSet…概念が多いし、YAMLも書かなければいけない。でも実際にMinikubeで手を動かしてみると、「あ、Dockerでやっていたことの自動化なんだな」という感覚がつかめてきます。特にオートヒーリングやローリングアップデートを体験すると、「これがあれば深夜のメンテナンス作業が…」と、かつてのオンプレ運用時代の苦労が走馬灯のように蘇りました。

---

この記事の対象読者

• 前回のDockerの基本操作を終えた方（環境をそのまま使います）
• Kubernetesの概念は聞いたことがあるけど、実際に触ったことがない方
• 「コンテナオーケストレーション」がなぜ必要なのかを体で理解したい方

• この記事の対象読者
• 実施環境
• 事前準備：Minikubeとkubectlのインストール
  • Minikubeのインストール
    • kubectlの設定
  • 起動確認
• Kubernetesで出てくる用語関連
• Hello Minikube！
  • Deploymentの作成
  • Serviceの作成とアクセス
  • リソースの確認
  • クリーンアップ
• 基本的なKubernetes操作
  • Pod操作：YAMLマニフェストを使用する
    • Pod内でのコマンド実行
    • ポートフォワーディング
  • Podの数を自在に変えるスケーリング
  • ダウンタイムなしでアプリを更新するローリングアップデート
    • 「やっぱり戻して！」にも即対応できるロールバック
  • リソースの整理をするためのラベルとセレクタ
  • ConfigMapとSecret：設定と機密情報の管理
• 応用操作
  • GUIでクラスタを確認するDashboard機能
  • Kubernetesの真の実力であるAuto-healing
    • 準備
    • テスト1：Podの手動削除
    • テスト2：コンテナプロセスの強制終了
    • テスト3：Liveness Probeによる自動回復
    • 実験後の環境のクリーンアップ
  • クラスタの管理
• 今回行った実験
  • 基本操作
  • 応用操作
• おわりに

---

実施環境

第1部と同じVirtualBox + Ubuntu環境に、MinikubeとkubectlをインストールしてKubernetesの学習環境を構築しました。

項目	内容
ホストOS	Windows 11
仮想化ソフト	VirtualBox 7.2.6 r172322
ゲストOS	Ubuntu 24.04 Server
VM プロセッサ数	2
VM メモリ	6128 MB
Docker	29.2.1
Minikube	1.38.0　※今回導入
kubectl	Minikube同梱版を使用（エイリアス設定）※今回導入

Minikubeは「手元のPCで動くシングルノードのKubernetesクラスタ」です。本番環境のようなマルチノード構成ではありませんが、Kubernetesの基本的な概念や操作を学ぶには十分です。Dockerドライバで動作させるので、第1部の環境がそのまま使えます。

---

事前準備：Minikubeとkubectlのインストール

Minikubeのインストール

# Minikubeのダウンロードとインストール
$ curl -LO https://github.com/kubernetes/minikube/releases/latest/download/minikube-linux-amd64
$ sudo install minikube-linux-amd64 /usr/local/bin/minikube && rm minikube-linux-amd64

# バージョン確認
$ minikube version

# クラスタの起動（Dockerドライバの設定もここで行われます）
$ minikube start

# ドライバの確認
$ minikube profile list
# DRIVER 列が「docker」になっていればOK

minikube のクラスタ起動結果

kubectlの設定

kubectlのインストールについて、公式サイトでも個別のインストール方法がすぐに見つからなかったのですが、調べてみるとMinikubeにはkubectlが同梱されており、minikube kubectl -- で使用できることがわかりました。ただ、毎回 minikube kubectl -- と打つのは面倒なので、エイリアスを設定して kubectl だけで使えるようにします。

# エイリアスの設定
$ alias kubectl="minikube kubectl --"

# 永続化する場合は .bashrc に追記
$ echo 'alias kubectl="minikube kubectl --"' >> ~/.bashrc
$ source ~/.bashrc

# 動作確認
$ kubectl version --client

👉kubectlを単体でインストールすることも可能ですが、今回のような学習目的であればMinikube同梱版で十分です。バージョンの不整合を気にしなくて良いのもメリットですね。

起動確認

# クラスタの状態確認
$ minikube status

# ノードの確認
$ kubectl get nodes

kubectl get nodes で STATUS が Ready になっていれば準備完了です。

$ kubectl get nodes
NAME       STATUS   ROLES           AGE   VERSION
minikube   Ready    control-plane   10m   v1.35.1

kubectl get nodes の実行結果

これで準備は完了です。

---

Kubernetesで出てくる用語関連

Kubernetesの操作に入る前に、まずは登場する用語を整理しておきます。Dockerでは「コンテナ」と「イメージ」くらい覚えておけばなんとかなりましたが、Kubernetesではもう少し登場人物が増えます。最初は「なんでこんなに概念が多いんだ…」と感じますが、それぞれが明確な役割を持っているので、触っているうちに「なるほど、だからこう分かれているのか」とわかってきます。

用語	ざっくり説明	Dockerで言うと…
Cluster（クラスタ）	Kubernetesが動作する環境全体。今回はMinikubeで1台構成	Docker Engineが動いているホストマシン
Node（ノード）	クラスタ内の1台のマシン（物理 or 仮想）。Podが実際に動く場所	Dockerホスト
Pod（ポッド）	コンテナの実行単位。1つ以上のコンテナをまとめたもの	docker run で起動したコンテナ
Deployment（デプロイメント）	Podの「あるべき状態」を定義し、自動で維持してくれる管理者	（Dockerには直接の対応なし）
ReplicaSet（レプリカセット）	指定した数のPodが常に動いていることを保証する仕組み。Deploymentが内部的に作る	（Dockerには直接の対応なし）
Service（サービス）	Podへの安定したアクセスポイント。Pod のIPが変わっても同じ名前でアクセスできる	docker run -p のポートマッピング + DNS解決
Namespace（ネームスペース）	リソースを論理的に分離する区画。チームや環境（dev/staging/prod）ごとに分けられる	（Dockerには直接の対応なし）
ConfigMap / Secret	アプリの設定値や機密情報をコンテナの外で管理する仕組み	docker run -e の環境変数指定
Label（ラベル）	リソースに付けるタグ。フィルタリングや管理に使う	docker run --label
マニフェスト	リソースの定義を書いたYAMLファイル	Dockerfile / docker-compose.yml

図にするとこんな感じでしょうか。

Cluster（クラスタ）
└── Node（ノード）
    └── Pod（ポッド）
        └── Container（コンテナ）  ← Dockerで触っていたのはココ

Deployment が Pod の数や状態を管理
Service が Pod へのアクセスを仲介

Dockerで触っていたのは一番内側の「コンテナ」の部分です。Kubernetesはその外側に管理の仕組みを何層か被せて、「勝手に増やす」「勝手に治す」「勝手に更新する」を実現しています。第1部で「手動でやっていたこと」が、第2部では「自動化されていく」感覚がつかめるかなと。

---

Hello Minikube！

まずは公式チュートリアル「Hello Minikube」に沿って、Kubernetesの基本的な動きを実験します。

kubernetes.io

Deploymentの作成

Deploymentは「Podをどう作って、どう維持するか」を定義するリソースです。Dockerでは docker run でコンテナを1つ起動していましたが、Kubernetesでは「この状態であるべき」を宣言し、その状態をKubernetesが自動的に維持してくれます。これが 宣言的（Declarative） なアプローチとなります。

# echoserverアプリケーションのDeploymentを作成
$ kubectl create deployment hello-node \
  --image=registry.k8s.io/e2e-test-images/agnhost:2.39 \
  -- /agnhost netexec --http-port=8080

# Deploymentの確認
$ kubectl get deployments

# Podの確認
$ kubectl get pods

Podの STATUS が Running になっていれば、アプリケーションが動作しています。

kubectl get deployments と kubectl get pods の実行結果

Serviceの作成とアクセス

Podは起動するたびにIPアドレスが変わります。外部からPodにアクセスするための安定したエンドポイントを提供するのがServiceです。第1部のDockerで「デフォルトbridgeネットワークではコンテナ名でDNS解決できない」という不便さを感じましたが、Kubernetesでは Service名によるクラスタ内名前解決が最初から組み込まれています。この差は大きいです。

# ServiceをNodePort型で公開
$ kubectl expose deployment hello-node --type=NodePort --port=8080

# Serviceの確認
$ kubectl get services

# MinikubeでServiceのURLを取得
$ minikube service hello-node --url

# curlでアクセス
$ curl $(minikube service hello-node --url)

レスポンスが返ってくれば成功です。使用しているのは現在のタイムスタンプを返すサービスです。

curl でhello-nodeのレスポンスが返ってきた結果

👉Dockerではポートマッピング（-p 8080:80）でホストとコンテナを直接つないでいましたが、KubernetesではService経由でアクセスします。Serviceは裏側にあるPodが何個でも、どのノードにいても、一貫したアクセスポイントを提供してくれます。

リソースの確認

# すべてのリソースを一覧表示
$ kubectl get all

# Podのログ確認
$ kubectl logs $(kubectl get pods -l app=hello-node -o jsonpath='{.items[0].metadata.name}')

# イベントの確認（トラブルシューティングに有用）
$ kubectl get events --sort-by='.lastTimestamp'

kubectl get events はトラブルシューティング時に使用します。Podが起動しない、イメージのpullに失敗した、リソースが足りないなど、何か問題が起きたときにまずイベントを確認する習慣をつけておくと特定がしやすいです。

クリーンアップ

次の実験に向けて、一旦環境をクリーンにしておきます。

$ kubectl delete service hello-node
$ kubectl delete deployment hello-node

---

基本的なKubernetes操作

Hello Minikubeで全体の流れを掴んだところで、ここからはKubernetesの主な機能をさらに実験をしてみます。

Pod操作：YAMLマニフェストを使用する

先ほどは kubectl create deployment でコマンドラインからリソースを作りましたが、実際には、YAMLマニフェストを書いてリソースを定義するのが一般的だと思います。YAMLファイルを作成します。

$ mkdir minikube-sample
$ cd minikube-sample
$ nano nginx-pod.yaml

nginx-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  labels:
    app: nginx
    env: exercise
spec:
  containers:
  - name: nginx
    image: nginx:latest
    ports:
    - containerPort: 80

# Podの作成
$ kubectl apply -f nginx-pod.yaml

# Podの確認
$ kubectl get pods

# Podの詳細情報
$ kubectl describe pod nginx-pod

kubectl apply -f nginx-pod.yaml と kubectl get pods の結果（末尾は切れています）

使用しているYAMLファイルは「apiVersion」「kind」「metadata」「spec」という構造をとっています。最初は「書くことが多いな…」と感じますが慣れるしかないんでしょうね。このファイルはDockerでいうところのDockerfileにあたるものですが、Kubernetesのマニフェストはもっと宣言的で、「あるべき状態」を記述するという考え方になっている点が少し異なります。

Pod内でのコマンド実行

Dockerの docker exec と同様に、Pod内でコマンド（bashなど）を実行できます。

# Pod内でbashシェルを起動
$ kubectl exec -it nginx-pod -- /bin/bash

# コンテナ内で確認
$ hostname
$ curl localhost
$ exit

# 1回限りのコマンド実行
$ kubectl exec nginx-pod -- cat /etc/os-release

ポートフォワーディング

また、ポートフォワーディングを行うことも可能です。

# ローカルの8080ポートをPodの80ポートに転送
$ kubectl port-forward nginx-pod 8080:80 --address 0.0.0.0 &

# アクセス確認
$ curl http://localhost:8080

# ポートフォワーディングの停止
$ kill %1

⚠️ここでも第1部と同じように、VirtualBox環境特有の注意点があります。kubectl port-forward はデフォルトで 127.0.0.1（VM内のlocalhost）にしかバインドされません。WindowsのブラウザからアクセスするにはDockerのときと同様に --address 0.0.0.0 を付ける必要があり、さらにVirtualBox側のポートフォワード設定も必要です。第1部・第2部を通じて、この多段仮想化環境のネットワーク設定には何度もお付き合いすることになりました😓

VirtualBoxのポートフォワーディングの設定

Windowsのブラウザからのアクセステスト（http://localhost:8888）

次の実験に向けて、一旦環境をクリーンにしておきます。

$ kubectl delete pod nginx-pod

---

Podの数を自在に変えるスケーリング

ここからはKubernetesの代表的な機能を見ていきます。

Kubernetesの大きな魅力の一つとなっているのがスケーリングです。「アクセスが増えたからサーバーを増やしたい」「落ち着いたから減らしたい」をコマンド一発で実現できます。これはとても便利🤩

# Deploymentの作成（レプリカ数1）
$ kubectl create deployment nginx-deploy --image=nginx --replicas=1

# 現在の状態確認
$ kubectl get pods -l app=nginx-deploy

# レプリカ数を3にスケールアウト
$ kubectl scale deployment nginx-deploy --replicas=3

# Podが3つに増えたことを確認
$ kubectl get pods -l app=nginx-deploy

# レプリカ数を1にスケールイン
$ kubectl scale deployment nginx-deploy --replicas=1

# Podが1つに減ったことを確認
$ kubectl get pods -l app=nginx-deploy

スケールアウト後の kubectl get pods 結果（Podが3つ表示されている状態）

kubectl scale を実行すると、数秒（あっという間かも）でPodが増減します。オンプレ時代は「サーバーを追加するぞ」となったら物理機器の手配から始まり、OSインストール、ネットワーク設定、アプリのデプロイと、下手したら数週間かかっていました。それがコマンド一発で終わるのは、やはり感慨深いです😊

👉例えば、ECサイトのセール時期やキャンペーン時にアクセスが急増する場合などのスケーリングで対応できます。さらにHPA（Horizontal Pod Autoscaler）を使えば、CPU使用率やメモリ使用率に応じて自動的にスケーリングすることも可能になるそうです。

次の実験に向けて、一旦環境をクリーンにしておきます。

$ kubectl delete deployment nginx-deploy

---

ダウンタイムなしでアプリを更新するローリングアップデート

個人的に、今回のハンズオンで最も「これは便利だ」と感じた機能がローリングアップデートです。クラウド上のEC2インスタンスでサービスを運用していることが多いですが、そういった場合、メンテナンス時にはダウンタイムを設定していて深夜作業になることもザラでした。Kubernetesのローリングアップデートを使えば、ダウンタイムなしでのメンテナンスが比較的容易に実現可能です。

# Deploymentの作成（nginx 1.24、レプリカ3）
$ kubectl create deployment web-app --image=nginx:1.24 --replicas=3

# 現在のイメージを確認
$ kubectl describe deployment web-app | grep Image

# ローリングアップデートの実行（nginx 1.25 に更新）
$ kubectl set image deployment/web-app nginx=nginx:1.25

# アップデートの進行状況を確認
kubectl rollout status deployment/web-app

# 更新後のイメージを確認
kubectl describe deployment web-app | grep Image

kubectl rollout status でアップデートの進行状況

ローリングアップデート中、Podが段階的に入れ替わります。古いバージョンのPodを1つ停止し、新しいバージョンのPodを1つ起動する、というサイクルが繰り返されるため、常にいくつかのPodが稼働し続けています。つまりユーザーから見るとサービスが途切れることなくアプリが更新できます。これはセキュリティアップデートに便利🤩

「やっぱり戻して！」にも即対応できるロールバック

アップデートした結果、不具合が見つかった。本番運用ではよくある話です。Kubernetesならロールバックもコマンド一発です。

# 前のバージョンにロールバック
$ kubectl rollout undo deployment/web-app

# ロールバック後のイメージを確認
$ kubectl describe deployment web-app | grep Image

# アップデート履歴の確認
$ kubectl rollout history deployment/web-app

👉 CI/CDパイプラインと組み合わせることで、「GitにプッシュしたらテストとビルドとデプロイまでCIが自動で回す。もし問題が起きたらロールバック」といった運用フローも構築できます。深夜に電話で叩き起こされて手動でデプロイをロールバックしていた時代が懐かしくなります（そんなのはもう辞めたいですが…😢）。

次の実験に向けて、一旦環境をクリーンにしておきます。

$ kubectl delete deployment web-app

---

リソースの整理をするためのラベルとセレクタ

Kubernetesではラベルを使ってリソースを分類・フィルタリングします。コンテナの数が増えてくると「このPodはフロントエンド用、こっちはバックエンド用」といった管理が必要になり、ラベルがその整理手段になります。

$ nano labeled-pods.yaml

labeled-pods.yaml

apiVersion: v1
kind: Pod
metadata:
  name: app-frontend
  labels:
    app: myapp
    tier: frontend
spec:
  containers:
  - name: nginx
    image: nginx
---
apiVersion: v1
kind: Pod
metadata:
  name: app-backend
  labels:
    app: myapp
    tier: backend
spec:
  containers:
  - name: nginx
    image: nginx
---
apiVersion: v1
kind: Pod
metadata:
  name: app-db
  labels:
    app: myapp
    tier: database
spec:
  containers:
  - name: nginx
    image: nginx

$ kubectl apply -f labeled-pods.yaml

# すべてのPodとラベルを表示
$ kubectl get pods --show-labels

# ラベルセレクタでフィルタリング
$ kubectl get pods -l tier=frontend
$ kubectl get pods -l tier=backend
$ kubectl get pods -l app=myapp

# 複数条件のフィルタリング
$ kubectl get pods -l "app=myapp,tier!=database"

kubectl get pods --show-labels の結果

👉本番環境ではラベルの命名規則をチームで統一するのが重要のようです。「app」「tier」「version」「env（production/staging/development）」といったラベルを体系的に付けておくと、障害時の影響範囲の特定やリソースの管理が格段に楽になるとのこと。こういうのは後回しにしがちですが設計時に行うべきでしょうね😊

次の実験に向けて、一旦環境をクリーンにしておきます。

$ kubectl delete -f labeled-pods.yaml

---

ConfigMapとSecret：設定と機密情報の管理

アプリケーションの設定値やデータベースのパスワードなどを、コンテナイメージに直接埋め込むのはセキュリティ上好ましくないです。そういう場合には、ConfigMap（設定情報）とSecret（機密情報）を使えば、設定とイメージを分離できます。

# ConfigMapの作成
$ kubectl create configmap app-config \
  --from-literal=APP_ENV=production \
  --from-literal=APP_DEBUG=false \
  --from-literal=APP_PORT=8080

# Secretの作成
$ kubectl create secret generic app-secret \
  --from-literal=DB_PASSWORD=mysecretpassword \
  --from-literal=API_KEY=abc123xyz

# ConfigMapの確認
$ kubectl get configmap app-config -o yaml

# Secretの確認（値はbase64エンコードされている）
$ kubectl get secret app-secret -o yaml

これらを環境変数としてPodに反映します。

$ nano configmap-pod.yaml

configmap-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: config-test-pod
spec:
  containers:
  - name: test
    image: busybox
    command: ["sh", "-c", "echo ENV=$APP_ENV DEBUG=$APP_DEBUG PORT=$APP_PORT PASSWORD=$DB_PASSWORD && sleep 3600"]
    env:
    - name: APP_ENV
      valueFrom:
        configMapKeyRef:
          name: app-config
          key: APP_ENV
    - name: APP_DEBUG
      valueFrom:
        configMapKeyRef:
          name: app-config
          key: APP_DEBUG
    - name: APP_PORT
      valueFrom:
        configMapKeyRef:
          name: app-config
          key: APP_PORT
    - name: DB_PASSWORD
      valueFrom:
        secretKeyRef:
          name: app-secret
          key: DB_PASSWORD

$ kubectl apply -f configmap-pod.yaml

# Podのログで環境変数が設定されていることを確認
$ kubectl logs config-test-pod

ENV=production DEBUG=false PORT=8080 PASSWORD=mysecretpassword と出力されれば成功です。

👉同じコンテナイメージを、開発・ステージング・本番で使い回せるようになります。環境ごとにConfigMapとSecretを切り替えるだけで、接続先のデータベースやログレベルを変更できます。「本番イメージには本番用の設定が焼き込まれている」という状態から脱却できるのは大きなメリットです。

次の実験に向けて、一旦環境をクリーンにしておきます。

$ kubectl delete pod config-test-pod
$ kubectl delete configmap app-config
$ kubectl delete secret app-secret

---

応用操作

GUIでクラスタを確認するDashboard機能

Kubernetes DashboardはクラスタをGUIで確認・管理できるWebベースのツールです。CLIに慣れていない方や、クラスタの全体像をパッと把握したいときに便利です。

# Dashboardアドオンの有効化
$ minikube addons enable dashboard

# メトリクス収集（Dashboard上でリソース使用量を表示するため）
$ minikube addons enable metrics-server

VirtualBox上のLinuxで実行している場合、minikube dashboard はVM内のブラウザを開こうとするため使えません。以下の手順でホストOSのWindowsブラウザからアクセスします。

# 0.0.0.0でプロキシを起動
kubectl proxy --address=0.0.0.0 --accept-hosts='.*' &

VirtualBox側でポートフォワード設定（ホスト8001 → ゲスト8001）を行い

Windowsのブラウザから以下にアクセスします。

http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/http:kubernetes-dashboard:/proxy/

DashboardのWorkloads画面

Dashboard上からDeploymentの作成・削除もできます。右上の「＋」ボタンからYAMLを直接入力してリソースを作成できるので、CLIと同等の操作がGUIでも可能です。

# Dashboard上で作ったリソースをCLIでも確認
$ kubectl get deployment dashboard-test
$ kubectl get pods -l app=dashboard-test

# 次の実験に向けて環境をクリーンアップ
$ kubectl delete deployment dashboard-test

👉Dashboardは運用チームがクラスタの状態を素早く確認するのに役立ちます。

⚠️今回は実験のために --accept-hosts='.*' と設定していますが実験環境であることを認識してください。

---

Kubernetesの真の実力であるAuto-healing

個人的に、Kubernetesの機能の中で最も「これはすごい」と感じたのがオートヒーリングです。Podに障害が発生しても、Kubernetesが自動的に復旧してくれます。3つのパターンで検証しました。

準備

# 3つのレプリカを持つDeploymentを作成
$ kubectl create deployment auto-heal-test --image=nginx --replicas=3

# Podが3つ起動していることを確認
$ kubectl get pods -l app=auto-heal-test -o wide

テスト1：Podの手動削除

「Podが突然死んだ」というシナリオです。

# Podを1つ手動で削除
$ kubectl delete pod $(kubectl get pods -l app=auto-heal-test -o jsonpath='{.items[0].metadata.name}')

# すぐにPodの状態を確認（新しいPodが自動作成される）
$ kubectl get pods -l app=auto-heal-test

# しばらく待ってから再確認（3つに戻っている）
$ kubectl get pods -l app=auto-heal-test

Pod削除直後と復旧後の kubectl get pods の結果（ageが違っていることがわかります）

削除したPodとは別の名前で新しいPodが即座に作成され、レプリカ数が3に維持されました。「あるべき状態（3つ）」と「現在の状態（2つ）」の差を検知して、自動的に補充してくれるわけです。

テスト2：コンテナプロセスの強制終了

「コンテナ内のアプリがクラッシュした」というシナリオです。

# Pod内のnginxプロセスを強制終了
$ kubectl exec $(kubectl get pods -l app=auto-heal-test -o jsonpath='{.items[0].metadata.name}') -- /bin/sh -c "kill 1"

# Podの状態を確認（RESTARTS カウントが増える）
$ kubectl get pods -l app=auto-heal-test

RESTARTSカウントが増加し、コンテナが自動で再起動されました。Pod自体は削除されず、中のコンテナだけがリスタートされます。

テスト3：Liveness Probeによる自動回復

最後は「アプリは動いているけど、正常に応答しなくなった」というシナリオ。Liveness Probeを使って、ヘルスチェック失敗時の自動回復を確認します。

$ nano liveness-pod.yaml

liveness-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: liveness-test
spec:
  containers:
  - name: liveness
    image: busybox
    args:
    - /bin/sh
    - -c
    # 起動後30秒間は /tmp/healthy が存在 → その後削除される
    - touch /tmp/healthy; sleep 30; rm -f /tmp/healthy; sleep 600
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5    # 起動後5秒でチェック開始
      periodSeconds: 5           # 5秒ごとにチェック

$ kubectl apply -f liveness-pod.yaml

# Podの状態を監視（約30秒後にProbeが失敗し、自動再起動される）
$ kubectl get pod liveness-test --watch
# （Ctrl+C で終了）

30秒後に /tmp/healthy ファイルが削除されると、Liveness Probeが失敗し、Kubernetesが自動的にコンテナを再起動します。

$ kubectl get pod liveness-test --watch
NAME            READY   STATUS    RESTARTS   AGE
liveness-test   1/1     Running   0          12s
liveness-test   1/1     Running   1 (3s ago)   79s
liveness-test   1/1     Running   2 (5s ago)   2m35s

kubectl get pod liveness-test --watch の結果（RESTARTSが増えている様子）

# イベントでProbe失敗の記録を確認
$ kubectl describe pod liveness-test | grep -A 30 "Events:"

「Liveness probe failed」「Container liveness killed」「Started container」のイベントが記録されていることが確認できます。

kubectl describe pod のEvents部分（Probe失敗と再起動のログ）

👉Liveness Probeはアプリケーションの「生存確認」、Readiness Probeは「リクエストを受け付けられるか」の確認に使います。例えば、アプリの起動に時間がかかる場合（DBマイグレーションなど）、Readiness ProbeでOKになるまでServiceのルーティング対象から外しておくことで、ユーザーがエラーページを見ることを防げます。

24時間稼働のシステムを運用していた経験から言うと、この自動回復の仕組みがあるだけで、深夜のアラート対応がどれだけ減るかを想像するだけでも価値を感じます😊

実験後の環境のクリーンアップ

$ kubectl delete pod liveness-test
$ kubectl delete deployment auto-heal-test
$ rm -f nginx-pod.yaml labeled-pods.yaml configmap-pod.yaml liveness-pod.yaml

---

クラスタの管理

演習が終わったら、クラスタを停止・削除します。

# クラスタの停止（状態は保持される）
$ minikube stop

# クラスタの削除（完全にリセットする場合）
$ minikube delete

# クラスタの再起動
$ minikube start

---

今回行った実験

基本操作

操作	内容
Minikubeインストール	インストールとクラスタ起動
Hello Minikube	Deployment・Serviceの作成とアクセス
Pod操作	YAML作成、exec、ログ、ポートフォワード
スケーリング	レプリカ数の増減
ローリングアップデート	イメージ更新とロールバック
ラベルとセレクタ	ラベル付与とフィルタリング
ConfigMap / Secret	環境変数の注入

応用操作

操作	内容
Dashboard	GUI管理画面の起動と操作
Auto-healing（Pod削除）	Pod手動削除後の自動復旧
Auto-healing（プロセス終了）	コンテナ再起動の確認
Auto-healing（Liveness Probe）	ヘルスチェック失敗時の自動再起動

---

おわりに

前回のDockerと今回のKubernetesを続けて体験してみて、「コンテナ単体の操作」から「コンテナ群のオーケストレーション」への発展を体感できたように思います。特に印象的だったのは以下の点です。

Kubernetesの機能の中でも、オートヒーリング、スケーリング、ローリングアップデート、ロールバックは特に便利だと感じました。自社の情報部門ではクラウド上のEC2インスタンスでサービスを運用しており、メンテナンス時にはダウンタイムを設定していますが、Kubernetesのローリングアップデートを活用すればダウンタイムなしでのメンテナンスが比較的容易に実現できるという実感が湧きました。

前回はDockerのデフォルトネットワークでコンテナ名による名前解決ができない不便さを感じましたが、KubernetesではService名によるクラスタ内の名前解決が最初から組み込まれており、サービス間の通信が自然に行える点が対照的でした。DockerからKubernetesへと演習を進めることで、なぜオーケストレーターが必要とされるのかが納得できました。

前回と同様に、VirtualBox上のLinuxで実行する構成では、kubectl port-forward やDashboardのプロキシがデフォルトで 127.0.0.1 にバインドされるため、ホストOSのWindowsからアクセスするには --address 0.0.0.0 の指定やVirtualBoxのポートフォワード設定が必要でした。第1部・第2部を通じて、多段の仮想化環境におけるネットワーク設定の注意点を繰り返し体験しました。面倒ではありましたが、50代のオンプレ経験者としては「ネットワークの階層が増えただけ」と捉えることもでき、経験が無駄になっていないことを改めて実感する機会にもなったかな😊

「50代からの学び直し」という感じの内容でしたが、結局のところ、手を動かして試行錯誤することが一番の学びだというのは何歳になっても変わらないですね。この記事が、これからKubernetesを触ってみようという方の一歩目の参考になれば嬉しいです。

参考

uepon.hatenadiary.com