Contents
- 1 1️⃣ 前提条件・ハードウェア要件
- 2 2️⃣ コンテナランタイム – containerd の導入
- 3 3️⃣ Kubernetes コアコンポーネント（kubeadm/kubelet/kubectl）インストール
- 4 4️⃣ シングルマスタ構成でのクラスタ初期化
- 5 5️⃣ CNI デプロイ – Calico
- 6 6️⃣ 外部 etcd（本番向け）
- 7 7️⃣ コントロールプレーンの増設（HA）
- 8 8️⃣ ワーカーノード参加手順
- 9 9️⃣ Conformance テストの実行（containerd 環境）
- 10 10️⃣ セキュリティベストプラクティス
- 11 11️⃣ アップグレード戦略（例：v1.30 → v1.31）
- 12 12️⃣ まとめ（要点）
スポンサードリンク
1️⃣ 前提条件・ハードウェア要件
| 項目 | 推奨設定 |
|---|---|
| OS | Ubuntu 22.04 LTS (64‑bit) |
| CPU | 2 コア以上（4 コア推奨） |
| メモリ | 4 GiB 以上（8 GiB 推奨） |
| ストレージ | SSD ≥ 100 GB |
| ネットワーク | TCP/UDP 443, 6443, 2379‑2380, 10250, 10251, 10252 を相互に開放 |
| 時刻同期 | chrony または ntp による NTP 同期 |
ポイント
Ubuntu 22.04 は Kubernetes が公式にサポートしている LTS ディストリビューションです。CPU・メモリの最低要件は各コンポーネントが 1 GiB 程度を必要とすることから、上表のスペックで本番レベルのシングルマスタ／小規模 HA 環境が十分に確保できます。
必須 OS 設定
|
1 2 3 4 5 6 7 8 9 10 11 12 |
# 1. パッケージ情報更新 sudo apt-get update && sudo apt-get install -y apt-transport-https ca-certificates curl gnupg lsb-release # 2. スワップ無効化（kubeadm が要求） sudo swapoff -a # ランタイムで即時無効 sudo sed -i '/ swap / s/^/#/' /etc/fstab # 永続的に無効化 # 3. ファイアウォール例（ufw 使用）※本番環境では更に細かく制御してください sudo ufw allow 22/tcp && sudo ufw allow 6443/tcp && \ sudo ufw allow 2379:2380/tcp && sudo ufw allow 10250:10252/tcp && \ sudo ufw enable |
備考
swapoff -aのみで一時的に無効化できますが、再起動後もスワップを使用しないよう/etc/fstabにコメントを書き込んでおくことがベストプラクティスです。
2️⃣ コンテナランタイム – containerd の導入
Docker が非推奨になった背景（正確なバージョン）
- Kubernetes v1.24（2022 年 5 月リリース）で Docker Engine の CRI 実装が削除され、以降は
containerdまたは他の CRI 対応ランタイムが必須となります。 - 公式ドキュメント: https://kubernetes.io/ja/docs/setup/production-environment/container-runtimes/
containerd のインストール手順
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
# (A) 必要ツールはすでにインストール済みと想定 # (B) Kubernetes 用リポジトリを追加（後続の kubeadm/kubelet/kubectl 取得に必要） curl -fsSL https://packages.cloud.google.com/apt/doc/apt-key.gpg | \ sudo gpg --dearmor -o /usr/share/keyrings/kubernetes-archive-keyring.gpg echo "deb [signed-by=/usr/share/keyrings/kubernetes-archive-keyring.gpg] \ https://apt.kubernetes.io/ kubernetes-xenial main" | \ sudo tee /etc/apt/sources.list.d/kubernetes.list # (C) containerd 本体をインストール sudo apt-get update && sudo apt-get install -y containerd # (D) systemd で自動起動し、現在の設定ファイルを生成 sudo mkdir -p /etc/containerd containerd config default | sudo tee /etc/containerd/config.toml sudo systemctl restart containerd sudo systemctl enable --now containerd |
ポイント
containerdのデフォルト設定は CRI ソケット/run/containerd/containerd.sockを提供します。以後のkubeadm init／joinではこのパスを明示してください。
3️⃣ Kubernetes コアコンポーネント（kubeadm/kubelet/kubectl）インストール
バージョン統一とアップデート防止
|
1 2 3 4 5 |
K8S_VERSION=1.30.0-00 # 任意の安定版を指定 sudo apt-get update && \ sudo apt-get install -y kubeadm=$K8S_VERSION kubelet=$K8S_VERSION kubectl=$K8S_VERSION sudo apt-mark hold kubeadm kubelet kubectl # 予期せぬ自動更新を防止 |
kubelet の有効化
|
1 2 |
sudo systemctl enable --now kubelet |
注意
kubeletは起動時に/run/containerd/containerd.sockを自動検出しますが、明示的に指定したい場合は/etc/default/kubeletにKUBELET_EXTRA_ARGS=--container-runtime=remote --container-runtime-endpoint=unix:///run/containerd/containerd.sockを追記してください。
4️⃣ シングルマスタ構成でのクラスタ初期化
kubeadm init の必須フラグ
| フラグ | 用途 |
|---|---|
--pod-network-cidr=192.168.0.0/16 |
Calico など CNI が使用する Pod IP 範囲 |
--cri-socket=/run/containerd/containerd.sock |
Docker ではなく containerd を利用させる |
--control-plane-endpoint=<IP>:6443 (任意) |
後で外部ロードバランサを導入する際の固定エンドポイント |
|
1 2 3 4 5 |
sudo kubeadm init \ --pod-network-cidr=192.168.0.0/16 \ --cri-socket=/run/containerd/containerd.sock \ --control-plane-endpoint=$(hostname -I | awk '{print $1}'):6443 |
管理者用 kubeconfig の設定
|
1 2 3 4 |
mkdir -p $HOME/.kube sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config sudo chown $(id -u):$(id -g) $HOME/.kube/config |
結果確認
bash
kubectl get nodes # Master が Ready と表示されるはずです
5️⃣ CNI デプロイ – Calico
|
1 2 3 4 5 6 7 8 9 10 11 12 |
# 最新の Calico マニフェストを取得（v3.28 系が執筆時点で最新） curl -LO https://projectcalico.docs.tigera.io/manifests/calico.yaml # Pod CIDR が一致しているか確認／必要なら置換 sed -i 's|192.168.0.0/16|192.168.0.0/16|' calico.yaml # ここでは同一なのでそのままで OK # デプロイ kubectl apply -f calico.yaml # 稼働確認（数十秒待つこと） kubectl get pods -n kube-system -l k8s-app=calico-node |
ポイント
Calico は BGP ルーティングと NetworkPolicy を提供し、Kubernetes が推奨する CNI のひとつです。Pod CIDR と一致させるだけで即座にネットワークが有効になります。
6️⃣ 外部 etcd（本番向け）
重要
apt-get install -y etcdはテスト環境向きです。本番では公式バイナリを直接ダウンロードし、検証済みの設定で systemd 管理することが推奨されます。
公式バイナリによるインストール手順
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 |
ETCD_VER=v3.5.13 DOWNLOAD_URL=https://github.com/etcd-io/etcd/releases/download/${ETCD_VER}/etcd-${ETCD_VER}-linux-amd64.tar.gz # バイナリ取得 & 展開 curl -L ${DOWNLOAD_URL} | tar xz sudo mv etcd-${ETCD_VER}-linux-amd64/etcd* /usr/local/bin/ sudo chmod +x /usr/local/bin/etcd* # ディレクトリ作成 sudo mkdir -p /etc/etcd /var/lib/etcd sudo chown -R $(id -u):$(id -g) /etc/etcd /var/lib/etcd # systemd ユニット作成（例：3 ノード構成の 1 台目） cat <<EOF | sudo tee /etc/systemd/system/etcd.service [Unit] Description=etcd key-value store Documentation=https://github.com/etcd-io/etcd After=network.target [Service] Type=notify ExecStart=/usr/local/bin/etcd \\ --name etcd1 \\ --data-dir /var/lib/etcd \\ --listen-peer-urls http://10.0.0.11:2380 \\ --listen-client-urls http://10.0.0.11:2379,http://127.0.0.1:2379 \\ --advertise-client-urls http://10.0.0.11:2379 \\ --initial-advertise-peer-urls http://10.0.0.11:2380 \\ --initial-cluster etcd1=http://10.0.0.11:2380,etcd2=http://10.0.0.12:2380,etcd3=http://10.0.0.13:2380 \\ --initial-cluster-state new \\ --initial-cluster-token etcd-cluster-2026 Restart=always LimitNOFILE=65536 [Install] WantedBy=multi-user.target EOF # 起動 & 有効化 sudo systemctl daemon-reload sudo systemctl enable --now etcd |
確認
bash
ETCDCTL_API=3 etcdctl endpoint health --endpoints=http://10.0.0.11:2379
kubeadm で外部 etcd を利用する設定
kubeadm init 時に以下のフラグを追加：
|
1 2 3 4 5 |
--external-etcd-endpoints=https://10.0.0.11:2379,https://10.0.0.12:2379,https://10.0.0.13:2379 \ --external-etcd-cafile=/etc/kubernetes/pki/etcd/ca.crt \ --external-etcd-certfile=/etc/kubernetes/pki/apiserver-etcd-client.crt \ --external-etcd-keyfile=/etc/kubernetes/pki/apiserver-etcd-client.key |
ポイント
証明書はkubeadm init phase certs allで事前に生成しておくとスムーズです。
7️⃣ コントロールプレーンの増設（HA）
|
1 2 3 4 5 6 7 |
# マスター側でトークン・証明書キー取得 JOIN_CMD=$(kubeadm token create --print-join-command) CERT_KEY=$(kubeadm init phase upload-certs --upload-certs | tail -1) # 例：取得結果を変数に格納（実際は出力内容をコピー） echo "$JOIN_CMD --control-plane --certificate-key $CERT_KEY" |
新しいマスターで実行（IP は対象ノードの IP）
|
1 2 3 4 5 6 |
sudo kubeadm join 10.0.0.10:6443 \ --token <TOKEN> \ --discovery-token-ca-cert-hash sha256:<HASH> \ --control-plane \ --certificate-key $CERT_KEY |
結果確認
bash
kubectl get nodes -o wide # 2 台以上が Ready になるはずです
8️⃣ ワーカーノード参加手順
|
1 2 3 |
# マスターでトークン取得（1 回だけで OK） kubeadm token create --print-join-command |
ワーカー側：
|
1 2 3 4 |
sudo kubeadm join 10.0.0.10:6443 \ --token <TOKEN> \ --discovery-token-ca-cert-hash sha256:<HASH> |
ポイント
kubeadm joinは--cri-socketを省略すると自動的に/run/containerd/containerd.sockが使用されます（Docker がインストールされていても影響なし）。
9️⃣ Conformance テストの実行（containerd 環境）
(1) Conformance イメージ取得
Kubernetes の公式 Conformance イメージは Docker/ctr 両方でプル可能です。runtime が containerd でも docker pull だけでローカルにキャッシュされ、後続の sonobuoy が利用します。
|
1 2 3 |
# Docker（または Podman）を使ってイメージを取得 sudo docker pull registry.k8s.io/conformance/kube-conformance:v1.30.0 |
(2) Sonobuoy でテスト実行
|
1 2 3 4 5 6 7 |
SONOBUOY_VER=v0.57.2 curl -L https://github.com/vmware-tanzu/sonobuoy/releases/download/${SONOBUOY_VER}/sonobuoy_${SONOBUOY_VER}_linux_amd64.tar.gz | \ tar xz && sudo mv sonobuoy /usr/local/bin/ # テスト開始（Certified Conformance モード） sudo sonobuoy run --mode=certified-conformance |
(3) 結果取得
|
1 2 3 4 5 |
# 完了待ち（約10分程度）後にレポートを取得 RESULTS=$(sonobuoy retrieve .) tar -xvf $RESULTS cat plugins/e2e/results/*.xml # JUnit 形式のテスト結果 |
合格基準
All tests passed が出力され、plugins/e2e/results/ 配下にエラーが無いことを確認すれば Conformance 合格です。
10️⃣ セキュリティベストプラクティス
| 項目 | 推奨設定 |
|---|---|
| RBAC | デフォルトで有効。最小権限のロールを作成し、ClusterRoleBinding は必要最小限に限定 |
| API 認証・監査 | kube-apiserver に --authorization-mode=Node,RBAC --audit-policy-file=/etc/kubernetes/audit-policy.yaml を付与。ログは外部 SIEM へ転送 |
| TLS 強化 | etcd・kubelet·apiserver の通信は TLS 1.3 以上を使用し、証明書は cert-manager で自動更新 |
| トークン管理 | kubeadm token create --ttl 0 は長期間の運用では危険。定期的にローテーションし、不要になったトークンは kubeadm token delete <token> で削除 |
| etcd バックアップ | ETCDCTL_API=3 etcdctl snapshot save /var/backups/etcd-$(date +%F).db を cron に登録。復元手順もドキュメント化 |
11️⃣ アップグレード戦略（例：v1.30 → v1.31）
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
# (A) 現行バージョン確認 & プラン取得 kubectl version --short && kubeadm upgrade plan # (B) コントロールプレーンの段階的更新 sudo kubeadm upgrade apply v1.31.x # まずマスター1台で実施 sudo systemctl restart kubelet # 必要に応じて # (C) 各残りマスターでも同様に適用 → 全ノードが新バージョンになるまで繰り返す # (D) ワーカーノードの更新 sudo apt-get install -y kubelet=1.31.x-00 kubectl=1.31.x-00 sudo systemctl restart kubelet |
必須：アップグレード前に必ず
etcd snapshotを取得し、テストクラスターでリハーサルを行うこと。
12️⃣ まとめ（要点）
- Swap 無効化 と containerd の導入 が kubeadm 実行の前提条件。
- 本番環境では etcd を公式バイナリでデプロイ し、
apt install etcdは避ける。 - Docker は Conformance イメージ取得にだけ使用（runtime は containerd）。
kubeadm initの必須フラグは--pod-network-cidrと--cri-socket、必要なら--control-plane-endpoint。- Calico で Pod ネットワークと NetworkPolicy を即座に有効化。
- 外部 etcd +
kubeadm join --control-planeにより HA（複数コントロールプレーン） が数ステップで実現できる。 - ワーカーノードはトークン共有だけで参加可能、Conformance テストは Sonobuoy で自動化。
- RBAC・TLS・監査ログなど セキュリティ設定 を忘れずに適用し、定期的なバックアップとバージョン管理で運用を安定させる。
これらの手順をそのまま実行すれば、2026 年時点でも 本番向け・高可用性・セキュア な Kubernetes クラスタが構築できます。 Happy K8s!
スポンサードリンク