Kubernetes クラスタ構築ガイド：kubeadmでシングルノードからHAまでの手順

2026年4月21日

Contents

1 前提条件とハードウェア・ネットワーク要件
- 1.1 補足：ディスク容量について
2 必須ソフトウェアのインストールとシステム設定
3 シングルノードクラスタ構築（kubeadm init）
4 マルチノード・高可用性構成の構築
5 運用・保守ガイド（検証、アップグレード、クリーンアップ）
6 まとめ

スポンサードリンク

前提条件とハードウェア・ネットワーク要件

結論：本番環境で安定稼働させる最小構成は以下の通りです。

項目	推奨スペック
CPU	2 コア以上（4 コア推奨）
メモリ	4 GiB 以上（8 GiB 推奨）
ディスク	SSD 20 GiB 空き容量 ※ワークロードやログ保管の要件に応じて増量が必要
OS	Ubuntu 24.04 LTS (kernel 6.5 系)
ネットワーク	各ノードに固定 IP、プライベート CIDR（例: `10.0.0.0/24`）
DNS	外部 DNS が正引きできること（Google 8.8.8.8 等）
時刻同期	NTP または `systemd-timesyncd` による自動同期

補足：ディスク容量について

最低: コンテナイメージと etcd のスナップショットだけで約 15 GiB が必要です。
実務的には: アプリケーションのイメージサイズや永続ボリューム（PV）を考慮し、50 GiB 以上、可能なら 100 GiB を確保すると安全です。

必須ソフトウェアのインストールとシステム設定

2‑1. containerd の公式パッケージによるインストール

Docker リポジトリ経由ではなく、Ubuntu が提供する 公式 containerd パッケージ を利用します。これにより署名や依存関係が保証され、将来的なアップデートもシームレスです。

# 1. 基本ツールと GPG 鍵の取得
sudo apt-get update &amp;&amp; sudo apt-get install -y ca-certificates curl gnupg lsb-release

# 2. Ubuntu の公式リポジトリから containerd をインストール
sudo apt-get install -y containerd

# 3. デフォルト設定ファイルを生成し、systemd cgroup を有効化
sudo mkdir -p /etc/containerd
containerd config default | sudo tee /etc/containerd/config.toml

#   以下の行を検索して true に変更（systemd が cgroup 管理を担当）
sudo sed -i 's|systemd_cgroup = false|systemd_cgroup = true|' /etc/containerd/config.toml

# 4. containerd を起動・有効化
sudo systemctl restart containerd
sudo systemctl enable containerd

# 1. 基本ツールと GPG 鍵の取得

sudo apt-get update && sudo apt-get install -y ca-certificates curl gnupg lsb-release

# 2. Ubuntu の公式リポジトリから containerd をインストール

sudo apt-get install -y containerd

# 3. デフォルト設定ファイルを生成し、systemd cgroup を有効化

sudo mkdir -p /etc/containerd

containerd config default | sudo tee /etc/containerd/config.toml

# 以下の行を検索して true に変更（systemd が cgroup 管理を担当）

sudo sed -i 's|systemd_cgroup = false|systemd_cgroup = true|' /etc/containerd/config.toml

# 4. containerd を起動・有効化

sudo systemctl restart containerd

sudo systemctl enable containerd

ポイント
- systemd_cgroup = true が推奨設定です。Kubelet と同一の cgroup ドライバを使用することで、将来のアップグレード時に互換性が保たれます。
- Ubuntu 24.04 の公式リポジトリは containerd.io パッケージとして提供されているため、外部リポジトリ追加は不要です。

2‑2. kubelet・kubeadm・kubectl の取得（apt リポジトリ）

以前の「kubernetes-xenial」表記は古く、Ubuntu 24.04 でも同様に機能しますが混乱を招きます。公式ドキュメントでは ディストリビューション名を動的に取得 することが推奨されています。

# 1. Google Cloud の公開 GPG 鍵をインポート（キーは常に最新）
curl -fsSL https://packages.cloud.google.com/apt/doc/apt-key.gpg \
 | sudo gpg --dearmor -o /usr/share/keyrings/kubernetes-archive-keyring.gpg

# 2. apt ソースリストに Kubernetes リポジトリを追加
#    $(lsb_release -cs) は Ubuntu のコード名 (jammy, noble 等) を自動取得します。
echo &quot;deb [signed-by=/usr/share/keyrings/kubernetes-archive-keyring.gpg] \
https://apt.kubernetes.io/ kubernetes-$(lsb_release -cs) main&quot; | \
sudo tee /etc/apt/sources.list.d/kubernetes.list

# 3. パッケージリスト更新・インストール
sudo apt-get update
sudo apt-get install -y kubelet kubeadm kubectl

# 4. バージョンロック（必要に応じて）※例: v1.30 系を固定したい場合
#    sudo apt-mark hold kubelet kubeadm kubectl

# 1. Google Cloud の公開 GPG 鍵をインポート（キーは常に最新）

curl -fsSL https://packages.cloud.google.com/apt/doc/apt-key.gpg \

| sudo gpg --dearmor -o /usr/share/keyrings/kubernetes-archive-keyring.gpg

# 2. apt ソースリストに Kubernetes リポジトリを追加

# $(lsb_release -cs) は Ubuntu のコード名 (jammy, noble 等) を自動取得します。

echo "deb [signed-by=/usr/share/keyrings/kubernetes-archive-keyring.gpg] \

https://apt.kubernetes.io/ kubernetes-$(lsb_release -cs) main" | \

sudo tee /etc/apt/sources.list.d/kubernetes.list

# 3. パッケージリスト更新・インストール

sudo apt-get update

sudo apt-get install -y kubelet kubeadm kubectl

# 4. バージョンロック（必要に応じて）※例: v1.30 系を固定したい場合

# sudo apt-mark hold kubelet kubeadm kubectl

注意書き
- 本稿執筆時点（2025‑08）は v1.30 系が最新安定版 です。v1.31 はまだリリースされていない可能性があります。将来のバージョンをインストールする際は、公式リリースノートで対応可否を必ず確認してください。

2‑3. Swap 無効化と sysctl 推奨設定

# 1. Swap を即時オフにし、永続的に無効化
sudo swapoff -a
sudo sed -i '/\bswap\b/d' /etc/fstab   # fstab から swap 行を削除

# 2. 必要なカーネルパラメータを /etc/sysctl.d/k8s.conf に保存
cat &lt;&lt;EOF | sudo tee /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-iptables = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.ipv4.ip_forward = 1
EOF

# 3. 設定を反映
sudo sysctl --system

# 1. Swap を即時オフにし、永続的に無効化

sudo swapoff -a

sudo sed -i '/\bswap\b/d' /etc/fstab # fstab から swap 行を削除

# 2. 必要なカーネルパラメータを /etc/sysctl.d/k8s.conf に保存

cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf

net.bridge.bridge-nf-call-iptables = 1

net.bridge.bridge-nf-call-ip6tables = 1

net.ipv4.ip_forward = 1

EOF

# 3. 設定を反映

sudo sysctl --system

ポイント
- bridge-nf-call-iptables 系は CNI がパケットフィルタリングを行うために必須です。
- ip_forward を有効化しないと、Pod ネットワークが外部へ通信できません。

シングルノードクラスタ構築（kubeadm init）

3‑1. 初期化コマンド例

以下は 単一ノード（master と worker を同一マシンで実行）を想定した kubeadm init の最小構成です。IP アドレスや CIDR は環境に合わせて変更してください。

# 例: IP が 10.0.0.10、Pod ネットワークは Calico 推奨の /16
sudo kubeadm init \
  --apiserver-advertise-address=10.0.0.10 \
  --control-plane-endpoint=10.0.0.10:6443 \
  --pod-network-cidr=192.168.0.0/16 \
  --cri-socket=/run/containerd/containerd.sock

# 例: IP が 10.0.0.10、Pod ネットワークは Calico 推奨の /16

sudo kubeadm init \

--apiserver-advertise-address=10.0.0.10 \

--control-plane-endpoint=10.0.0.10:6443 \

--pod-network-cidr=192.168.0.0/16 \

--cri-socket=/run/containerd/containerd.sock

主なオプションの意味

オプション	説明
`--apiserver-advertise-address`	API Server がリッスンする IP（マスタの固定アドレス）
`--control-plane-endpoint`	HA 構成時に外部ロードバランサが提供するエンドポイント。シングルノードでも明示すると後工程で変更が楽です
`--pod-network-cidr`	CNI が割り当てる Pod 用 IP 範囲（Calico のデフォルトは 192.168.0.0/16）
`--cri-socket`	使用するコンテナランタイムのソケットパス。containerd の場合は `/run/containerd/containerd.sock`

3‑2. kubeconfig の設定（一般ユーザーで利用できるように）

# 実行後に表示される指示をそのままコピー
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

# 実行後に表示される指示をそのままコピー

mkdir -p $HOME/.kube

sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config

sudo chown $(id -u):$(id -g) $HOME/.kube/config

3‑3. CNI プラグインのデプロイと動作確認

Calico（推奨）

kubectl apply -f https://projectcalico.docs.tigera.io/manifests/calico.yaml

1 2	kubectl apply -f https://projectcalico.docs.tigera.io/manifests/calico.yaml

Weave Net（代替例）

kubectl apply -f &quot;https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version --short | base64 | tr -d '\n')&quot;

1 2	kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version --short \| base64 \| tr -d '\n')"

動作確認

# 1. Pod がすべて Ready になるまで待つ（例: calico-node）
kubectl get pods -n kube-system -w

# 2. テスト用 nginx デプロイ &amp; Service 暴露
kubectl create deployment nginx --image=nginx:stable
kubectl expose deployment nginx --port=80 --target-port=80 --type=ClusterIP

# 3. Pod の IP と Service 経由でアクセス確認
POD_IP=$(kubectl get pod -l app=nginx -o jsonpath=&quot;{.items[0].status.podIP}&quot;)
curl -s http://$POD_IP:80 | head
#   → &quot;Welcome to nginx!&quot; が出力されれば成功

# 1. Pod がすべて Ready になるまで待つ（例: calico-node）

kubectl get pods -n kube-system -w

# 2. テスト用 nginx デプロイ & Service 暴露

kubectl create deployment nginx --image=nginx:stable

kubectl expose deployment nginx --port=80 --target-port=80 --type=ClusterIP

# 3. Pod の IP と Service 経由でアクセス確認

POD_IP=$(kubectl get pod -l app=nginx -o jsonpath="{.items[0].status.podIP}")

curl -s http://$POD_IP:80 | head

# → "Welcome to nginx!" が出力されれば成功

マルチノード・高可用性構成の構築

4‑1. HA 用 control‑plane の設計ポイント

項目	推奨
コントロールプレーン数	奇数台（最低 3 台）
ロードバランサ	外部 HAProxy / nginx / MetalLB (外部)
etcd データストレージ	各マスタにローカル SSD、バックアップは定期的に取得

4‑2. 初回 init（ロードバランサエンドポイント指定）

# LB の IP が 10.0.0.100 と仮定
sudo kubeadm init \
  --control-plane-endpoint=10.0.0.100:6443 \
  --upload-certs \
  --pod-network-cidr=192.168.0.0/16 \
  --cri-socket=/run/containerd/containerd.sock

# LB の IP が 10.0.0.100 と仮定

sudo kubeadm init \

--control-plane-endpoint=10.0.0.100:6443 \

--upload-certs \

--pod-network-cidr=192.168.0.0/16 \

--cri-socket=/run/containerd/containerd.sock

--upload-certs：以降の control‑plane ノードが証明書を取得できるようにするフラグ
初回実行後、証明書キー と kubeadm join コマンド が標準出力に表示されます。必ずコピーして安全な場所に保管してください。

4‑3. 2 台目・3 台目の control‑plane ノードでの `join`

sudo kubeadm join 10.0.0.100:6443 \
  --token &lt;TOKEN&gt; \
  --discovery-token-ca-cert-hash sha256:&lt;HASH&gt; \
  --control-plane \
  --certificate-key &lt;CERT_KEY&gt;

sudo kubeadm join 10.0.0.100:6443 \

--token <TOKEN> \

--discovery-token-ca-cert-hash sha256:<HASH> \

--control-plane \

--certificate-key <CERT_KEY>

注意点

各マスタは 同一バージョン（例: v1.30.0）である必要があります。
--certificate-key が無いと etcd の証明書が取得できず、join に失敗します。

4‑4. kubeadm Config File を使った再利用可能なテンプレート

# kubeadm-config.yaml（v1beta4 対応）
apiVersion: kubeadm.k8s.io/v1beta4
kind: ClusterConfiguration
controlPlaneEndpoint: &quot;10.0.0.100:6443&quot;
networking:
  podSubnet: &quot;192.168.0.0/16&quot;
etcd:
  local:
    dataDir: &quot;/var/lib/etcd&quot;

---
apiVersion: kubeadm.k8s.io/v1beta4
kind: InitConfiguration
nodeRegistration:
  name: &quot;master-01&quot;
  criSocket: &quot;/run/containerd/containerd.sock&quot;
localAPIEndpoint:
  advertiseAddress: &quot;10.0.0.11&quot;

# kubeadm-config.yaml（v1beta4 対応）

apiVersion: kubeadm.k8s.io/v1beta4

kind: ClusterConfiguration

controlPlaneEndpoint: "10.0.0.100:6443"

networking:

podSubnet: "192.168.0.0/16"

etcd:

local:

dataDir: "/var/lib/etcd"

---

apiVersion: kubeadm.k8s.io/v1beta4

kind: InitConfiguration

nodeRegistration:

name: "master-01"

criSocket: "/run/containerd/containerd.sock"

localAPIEndpoint:

advertiseAddress: "10.0.0.11"

# 初回起動（マスタ 1）
sudo kubeadm init --config=kubeadm-config.yaml --upload-certs

# 後続ノードは同一ファイルの InitConfiguration 部分だけ書き換えて使用可能

# 初回起動（マスタ 1）

sudo kubeadm init --config=kubeadm-config.yaml --upload-certs

# 後続ノードは同一ファイルの InitConfiguration 部分だけ書き換えて使用可能

4‑5. ワーカーノードの参加手順とトラブルシューティング

参加コマンド取得（マスタ側）

kubeadm token create --print-join-command
# 出力例:
# sudo kubeadm join 10.0.0.100:6443 --token abcdef.0123456789abcdef \
#   --discovery-token-ca-cert-hash sha256:1234567890abcdef...

kubeadm token create --print-join-command

# 出力例:

# sudo kubeadm join 10.0.0.100:6443 --token abcdef.0123456789abcdef \

# --discovery-token-ca-cert-hash sha256:1234567890abcdef...

ワーカーノードで実行

sudo &lt;上記コマンド&gt;

1 2	sudo <上記コマンド>

症状	確認ポイント
`kubeadm join` がタイムアウト	`timedatectl status` → NTP 同期が有効か
kubelet が起動しない	`systemctl status kubelet`、`free -h` で swap が残っていないか
CNI が機能せず Pod が Pending	`kubectl get pods -n kube-system` で calico/weave の状態確認、iptables に DROP ルールが無いか

運用・保守ガイド（検証、アップグレード、クリーンアップ）

5‑1. クラスタ全体のヘルスチェック

# コンポーネント状態
kubectl get componentstatuses

# API Server / etcd のバージョン情報
kubectl version

# 全ノードの Ready 状態確認
kubectl get nodes -o wide

# コンポーネント状態

kubectl get componentstatuses

# API Server / etcd のバージョン情報

kubectl version

# 全ノードの Ready 状態確認

kubectl get nodes -o wide

サンプルアプリで動作検証

# 名前空間作成
kubectl create namespace demo

# Deployment 作成（hello-kubernetes）
cat &lt;&lt;EOF | kubectl apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-app
  namespace: demo
spec:
  replicas: 2
  selector:
    matchLabels:
      app: hello
  template:
    metadata:
      labels:
        app: hello
    spec:
      containers:
      - name: hello
        image: ghcr.io/paulbouwer/hello-kubernetes:1.10
        ports:
        - containerPort: 8080
EOF

# Service 暴露（ClusterIP）
kubectl expose deployment hello-app --type=ClusterIP --port=80 --target-port=8080 -n demo

# Pod の IP 取得 &amp; curl テスト
POD_IP=$(kubectl get pod -l app=hello -n demo -o jsonpath=&quot;{.items[0].status.podIP}&quot;)
curl -s http://$POD_IP:80 | head   # =&gt; &quot;Hello Kubernetes!&quot;

# 名前空間作成

kubectl create namespace demo

# Deployment 作成（hello-kubernetes）

cat <<EOF | kubectl apply -f -

apiVersion: apps/v1

kind: Deployment

metadata:

name: hello-app

namespace: demo

spec:

replicas: 2

selector:

matchLabels:

app: hello

template:

metadata:

labels:

app: hello

spec:

containers:

- name: hello

image: ghcr.io/paulbouwer/hello-kubernetes:1.10

ports:

- containerPort: 8080

EOF

# Service 暴露（ClusterIP）

kubectl expose deployment hello-app --type=ClusterIP --port=80 --target-port=8080 -n demo

# Pod の IP 取得 & curl テスト

POD_IP=$(kubectl get pod -l app=hello -n demo -o jsonpath="{.items[0].status.podIP}")

curl -s http://$POD_IP:80 | head # => "Hello Kubernetes!"

5‑2. バージョン管理とアップグレード手順

バージョンスキューポリシー

サポート対象は「直前のマイナーバージョン」まで。例: v1.30 → v1.31 は可能だが、v1.30 → v1.32 は非対応。
注意：執筆時点（2025‑08）では v1.31 がリリースされていない可能性があります。実際に適用する前に公式リリースノートで確認してください。

アップグレードフロー（例: v1.30 → v1.31）

# 1. 現在のバージョン確認
kubectl version

# 2. 利用可能なアップグレード候補を表示
sudo kubeadm upgrade plan

# 3. マスタノードで適用（--yes は自動承認オプション）
sudo kubeadm upgrade apply v1.31.0 --yes

# 4. 各ワーカーノードでも kubelet と kubectl を同バージョンに更新
sudo apt-get update &amp;&amp; sudo apt-get install -y \
    kubelet=1.31.0-00 kubectl=1.31.0-00

# 5. kubelet の再起動と状態確認
sudo systemctl daemon-reload
sudo systemctl restart kubelet
kubectl get nodes   # 全ノードが Ready になることを確認

# 1. 現在のバージョン確認

kubectl version

# 2. 利用可能なアップグレード候補を表示

sudo kubeadm upgrade plan

# 3. マスタノードで適用（--yes は自動承認オプション）

sudo kubeadm upgrade apply v1.31.0 --yes

# 4. 各ワーカーノードでも kubelet と kubectl を同バージョンに更新

sudo apt-get update && sudo apt-get install -y \

kubelet=1.31.0-00 kubectl=1.31.0-00

# 5. kubelet の再起動と状態確認

sudo systemctl daemon-reload

sudo systemctl restart kubelet

kubectl get nodes # 全ノードが Ready になることを確認

重要
- kubeadm upgrade apply が完了したら、必ず kubectl get cs と kubectl get pods -A で全コンポーネントが正常に起動しているか検証してください。
- 重大な変更（etcd バージョンアップ等）が含まれる場合は事前にバックアップを取得し、テスト環境でリハーサルすることを推奨します。

5‑3. 障害復旧・ログ取得・クリーンアップ

ログ収集のベストプラクティス

ソース	コマンド例
systemd ジャーナル（kubelet）	`journalctl -u kubelet -n 200 --no-pager`
API Server ログ	`journalctl -u kube-apiserver -n 200`
etcd ログ	`journalctl -u etcd -n 200`
コンテナランタイム（containerd）	`journalctl -u containerd -n 200`
Kubernetes マニフェストのイベント	`kubectl describe pod <pod> -n kube-system`

障害復旧フロー

コントロールプレーンの状態確認
bash kubectl get componentstatuses journalctl -u kube-apiserver -n 100
ワーカーノードで kubelet エラーを特定
bash ssh user@worker01 "journalctl -u kubelet -n 200"
リソースの詳細情報取得（イベント含む）
bash kubectl describe pod <pod-name> -n <namespace>
必要に応じてパッケージ再インストール（例: containerd のバグ修正）
bash sudo apt-get reinstall -y containerd kubelet sudo systemctl restart containerd kubelet
最終手段：kubeadm reset + 完全クリーンアップ

bash # ローカル設定・データの削除（注意: 永続ボリュームは残ります） sudo kubeadm reset --force


# パッケージとディレクトリを完全に除去

   sudo apt-get purge -y kubelet kubeadm kubectl containerd

   sudo rm -rf /etc/kubernetes /var/lib/etcd /var/lib/kubelet /var/run/kubernetes \

               /var/lib/containerd

# ログの保存（障害報告用に tar アーカイブ化） journalctl > ~/k8s-journal.log tar czf ~/k8s-logs-$(date +%F).tgz /var/log/kubernetes ~/.kube

注意：kubeadm reset はローカルの設定のみを削除します。外部 etcd クラスタやクラウドプロバイダ上のリソースは手動で削除してください。

まとめ

ハードウェア要件は CPU 2 コア、メモリ 4 GiB、SSD 20 GiB（実運用では余裕を持って増量）を最低ラインとし、ネットワークは固定 IP とプライベート CIDR を採用。
containerd は Ubuntu 公式パッケージからインストールし、systemd_cgroup = true を必ず有効化。Docker リポジトリは使用せず、安全性を確保。
Kubernetes apt リポジトリはディストリビューション名を自動取得し、古い kubernetes-xenial 表記は廃止。
**バージョン例として v1.31 を挙げる際は「将来のリリースである可能性がある」旨の注意書きを必ず付与。
ディスク容量は最低 20 GiB に加えて、イメージやログ・永続データを想定した余裕分を確保することが推奨。
HA 構成ではロードバランサエンドポイントの明示と --upload-certs の利用で証明書共有を自動化し、kubeadm-config.yaml による再利用可能なテンプレート化でヒューマンエラーを削減。
運用フェーズはヘルスチェック・サンプルアプリによる検証、バージョンスキューに沿った段階的アップグレード、障害時のログ取得と kubeadm reset による安全なクリーンアップ手順を標準化することが重要です。

以上の手順とベストプラクティスに従えば、シングルノードから HA クラスタまで、Ubuntu 24.04 上で安全かつ再現性の高い Kubernetes 環境を構築・運用できます。

本稿は 2025‑08 の公式リリース情報に基づき執筆していますが、Kubernetes は頻繁にアップデートされます。実装前には必ず最新の公式ドキュメントをご確認ください。