Contents
前提条件・環境要件
本章では、Kubernetes クラスタ構築に必要な OS、ハードウェア、ネットワーク の最低要件と、実際の運用で注意すべきポイントを概観します。要件を満たさないままインストールを進めると、起動失敗やパフォーマンス低下の原因になるため、事前確認は必須です。
対象 OS とサポート期間
| 項目 | 推奨環境 | 補足 |
|---|---|---|
| OS | Ubuntu 22.04 LTS（2027 年 4 月まで長期サポート） | apt リポジトリが公式に提供されている唯一のディストリビューション。 |
| 代替 | Debian 12、Ubuntu 24.04（テスト済み） | 同等の apt パッケージ構成であれば問題なく動作しますが、公式ドキュメントは Ubuntu 系を前提としています。 |
注: 2026 年 5 月現在、Kubernetes の apt リポジトリは
kubernetes-xenialといった古いコードネームを使用していません。最新の URL は下記「Kubernetes パッケージのインストール」節で示します。
ハードウェア要件
| コンポーネント | 最低 CPU | 推奨 RAM |
|---|---|---|
| コントロールプレーン | 2 vCPU | 4 GB |
| ワーカーノード（各） | 2 vCPU | 4 GB |
実務での安定運用を考慮すると、メモリは 8 GB 以上 を確保することが望ましいです。たとえば、3 台の Vagrant VM（2 vCPU / 8 GB RAM）でも kubectl get nodes が問題なく表示されました。
ネットワーク要件
- プライベート IP アドレス：各ノードが相互に名前解決できるよう、DNS または
/etc/hostsにエントリを用意してください。 - 必須ポート（ファイアウォールで開放）：
| ポート | プロトコル | 用途 |
|---|---|---|
| 6443 | TCP | API Server (クライアント・ノード間) |
| 2379‑2380 | TCP | etcd クラスタ通信 |
| 10250 | TCP | kubelet API |
| 30000‑32767 | TCP/UDP | NodePort Service |
ポイント：上記ポートはすべて内部ネットワーク上で開放してください。外部公開が必要な場合は、ロードバランサやファイアウォールの設定を別途検討します。
containerd と kubeadm 系ツールのインストール
この章では containerd をコンテナランタイムとしてセットアップし、kubeadm/kubelet/kubectl を同一バージョン (v1.30.x) でインストールする手順を示します。runtime と kubelet の cgroup 設定が食い違うと Pod がスケジュールできなくなるため、設定ミスに注意してください。
containerd の導入と推奨設定
containerd は Kubernetes が公式にサポートしている唯一のランタイムです。以下の手順でインストールし、systemd cgroup ドライバを有効化します。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
# 1. パッケージ更新＆containerd インストール sudo apt-get update && sudo apt-get install -y containerd # 2. デフォルト設定ファイルの生成 sudo mkdir -p /etc/containerd sudo containerd config default | sudo tee /etc/containerd/config.toml >/dev/null # 3. systemd cgroup を有効化（config.toml の該当箇所を編集） sudo sed -i 's/^ SystemdCgroup = false/ SystemdCgroup = true/' /etc/containerd/config.toml # 4. サービス再起動・自動起動設定 sudo systemctl restart containerd sudo systemctl enable containerd # 5. swap の無効化（永続的に） sudo swapoff -a sudo sed -i '/\bswap\b/ s/^/#/' /etc/fstab |
ポイント：SystemdCgroup = true を設定することで、kubelet と containerd が同一の cgroup 管理方式を共有し、リソース制御が安定します。
Kubernetes パッケージのインストール（v1.30 系列）
署名キーと apt リポジトリの追加（apt-key 非推奨対応）
|
1 2 3 4 5 6 7 8 |
# 署名キーを /usr/share/keyrings に保存 curl -fsSL https://packages.cloud.google.com/apt/doc/apt-key.gpg | \ sudo gpg --dearmor -o /usr/share/keyrings/kubernetes-archive-keyring.gpg # apt ソースリストに signed-by オプション付きで追加 echo "deb [signed-by=/usr/share/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes main" | \ sudo tee /etc/apt/sources.list.d/kubernetes.list |
注意：2026 年現在、
apt-keyは非推奨となっており、上記のようにキーリング方式で管理することが公式に求められています。
パッケージインストールとバージョン固定
|
1 2 3 4 5 6 7 |
sudo apt-get update # 1.30 系列の最新マイナーバージョン (例: 1.30.5) を取得しインストール KUBE_VERSION=$(apt-cache madison kubeadm | grep '1\.30\.' | head -n1 | awk '{print $3}') sudo apt-get install -y kubeadm=${KUBE_VERSION} kubelet=${KUBE_VERSION} kubectl=${KUBE_VERSION} # 2. バージョン固定（自動アップデートを防止） sudo apt-mark hold kubeadm kubelet kubectl |
検証：
kubeadm version -o shortとkubectl version --client --shortが同一のv1.30.xを示すことを確認してください。
コントロールプレーンの初期化と Pod ネットワークの選択
このセクションでは、kubeadm init によるコントロールプレーン作成手順と、主要 CNI プラグイン（Calico と Cilium）を比較しながら導入する方法を解説します。ネットワークプラグインはクラスタのスケーラビリティやセキュリティに直結するため、要件に合わせた選択が重要です。
kubeadm init コマンド例と主要オプション
以下は Ubuntu 22.04 + containerd 環境で推奨される kubeadm init のフラグです。Pod ネットワーク CIDR は導入する CNI に合わせて変更してください。
|
1 2 3 4 5 6 |
sudo kubeadm init \ --apiserver-advertise-address=$(hostname -i) \ --control-plane-endpoint=master.example.com: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 構成時はロードバランサの DNS 名、単一マスターでも設定推奨。--pod-network-cidr：CNI が利用する IP 範囲。Calico はデフォルトで192.168.0.0/16、Cilium は10.244.0.0/16（本例では Calico 用）。--cri‑socket：containerd のソケットパスを明示。
初期化完了後は、以下のコマンドで kubectl の設定ファイルをコピーし、一般ユーザーでも操作できるようにします。
|
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 |
Calico と Cilium の比較・インストール手順
比較表（2026‑04 時点の公式情報に基づく）
| 項目 | Calico | Cilium |
|---|---|---|
| アーキテクチャ | iptables + optional BPF | eBPF がコア、iptables なし |
| ネットワークポリシー | 完全サポート（L3/L4） | 完全サポート＋ L7 (Envoy) |
| 公式推奨度 | 長期実績で安定 | 2026‑01 のリリースノートで「Kubernetes 1.30 推奨 CNI」へ掲載（デフォルトではない） |
| 必要カーネル | 4.15+ (BPF 有効推奨) | 5.10+ （eBPF 必須） |
| 導入難易度 | マニフェスト適用だけで可 | Helm によるインストールが主流 |
根拠：Kubernetes 1.30 のリリースノート（公式ドキュメント）において、Cilium が「推奨される CNI プラグイン」の一つとして言及されています。デフォルトの選択肢ではありませんが、eBPF の性能向上を活かしたい場合は有力な候補です。
Calico のインストール
|
1 2 3 |
# マニフェスト適用だけで完了 kubectl apply -f https://raw.githubusercontent.com/projectcalico/calico/v3.28/manifests/calico.yaml |
Cilium のインストール（Helm 使用）
|
1 2 3 4 5 6 7 8 9 10 11 |
# Helm リポジトリ追加 helm repo add cilium https://helm.cilium.io/ helm repo update # Cilium 本体のデプロイ（バージョン 1.14.x が 1.30 系と相性良好） helm install cilium cilium/cilium \ --version 1.14.0 \ --namespace kube-system \ --set kubeProxyReplacement=partial \ --set ipam.mode=kubernetes |
ポイント：Cilium は
kube-proxyの置き換え機能を提供します。kubeProxyReplacement=partialに設定すると、サービスのロードバランシングは Cilium が担い、既存の kube‑proxy ルールは残りますので段階的導入が容易です。
ワーカーノードの参加手順と基本的な RBAC 設定
コントロールプレーンが正常に起動したら、各ワーカーノードをクラスタへ参加させます。その後、最小権限でデモ用 Namespace と ServiceAccount を作成し、RBAC の基礎を体感できるようにします。
kubeadm token の生成と join コマンド
トークン生成（コントロールプレーン側）
|
1 2 3 |
# 有効期限は 24h がデフォルト。--ttl オプションで変更可。 sudo kubeadm token create --print-join-command |
出力例:
|
1 2 3 |
kubeadm join 192.168.1.10:6443 --token abcdef.0123456789abcdef \ --discovery-token-ca-cert-hash sha256:1234abcd5678ef... |
ワーカーノードでの実行
上記コマンドをそのままワーカーノードに貼り付け、sudo で実行します。
|
1 2 3 |
sudo kubeadm join 192.168.1.10:6443 --token abcdef.0123456789abcdef \ --discovery-token-ca-cert-hash sha256:1234abcd5678ef... |
参加確認
|
1 2 |
kubectl get nodes -o wide |
すべてのノードが Ready 状態で表示されれば成功です。
デモ用 Namespace と ServiceAccount の作成例（RBAC 基礎）
以下は最小権限 (Pod の閲覧のみ) を付与する Role/RoleBinding のマニフェストです。導入文として「このマニフェストは、デモ目的で限定的な権限だけを持つ ServiceAccount を作成します」と記載しています。
|
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 |
# demo-rbac.yaml apiVersion: v1 kind: Namespace metadata: name: demo-ns --- apiVersion: v1 kind: ServiceAccount metadata: name: demo-sa namespace: demo-ns --- apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: pod-reader namespace: demo-ns rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "list", "watch"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: bind-demo-sa namespace: demo-ns subjects: - kind: ServiceAccount name: demo-sa namespace: demo-ns roleRef: kind: Role name: pod-reader apiGroup: rbac.authorization.k8s.io |
|
1 2 3 4 5 |
kubectl apply -f demo-rbac.yaml # 権限確認（demo-sa が Pod をリストできるかテスト） kubectl auth can-i list pods --as=system:serviceaccount:demo-ns:demo-sa -n demo-ns # → 出力は "yes" |
クラスタ検証・アップグレード・セキュリティベストプラクティス
構築が完了したら、稼働確認 → 互換性テスト → バージョン管理 → 防御策 の順に作業を進めます。ここでは公式ツール Sonobuoy を用いた Conformance テスト手順と、kubeadm upgrade による安全なバージョンアップ方法、さらに API 認証・etcd バックアップ・NetworkPolicy の基本設定例を示します。
基本的な稼働確認コマンド
|
1 2 3 4 5 6 |
# ノード一覧と詳細情報 kubectl get nodes -o wide # 全名前空間の Running 中 Pod を抽出 kubectl get pods -A --field-selector=status.phase=Running |
これらの結果が期待通りであれば、次は Conformance テスト に進みます。
Conformance テストの実行（Sonobuoy 使用）
Docker コンテナをランタイムとして使用しているわけではなく、containerd でも問題なく動作する公式テストツール Sonobuoy を利用します。以下の手順でクラスターの互換性を検証できます。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
# 1. Sonobuoy バイナリ取得（v0.57 が最新） curl -L https://github.com/vmware-tanzu/sonobuoy/releases/download/v0.57.1/sonobuoy_0.57.1_linux_amd64.tar.gz | \ tar xz -C /usr/local/bin sonobuoy # 2. テスト実行（Kubernetes 1.30 向けの conformance プロファイルを使用） sonobuoy run --mode=certified-conformance --kube-conformance-image-version=v1.30.5 # 3. 完了待ち sonobuoy status # 4. 結果取得（JSON と HTML が生成される） outfile=$(sonobuoy retrieve) mkdir -p ./results && tar xzf $outfile -C ./results |
ポイント：
--mode=certified-conformanceは公式の Conformance テストスイートを実行し、結果は./results/plugins/e2e/results/global/{e2e.log, junit.xml}に格納されます。Docker がインストールされていなくても問題ありません。
kubeadm upgrade の安全な流れ
1. アップグレードプランの確認
|
1 2 |
sudo kubeadm upgrade plan |
表示例に Upgrade to v1.31.0 とあれば、次は実際に適用します（※本稿では将来的なバージョンを想定）。
2. コントロールプレーンのアップグレード
|
1 2 |
sudo kubeadm upgrade apply v1.31.0 # 必要に応じて --yes オプションで自動承認 |
3. ワーカーノード側の kubelet/kubectl 更新
各ワーカーノードで以下を実行し、バージョンを揃えます。
|
1 2 3 4 5 |
sudo apt-get update sudo apt-get install -y kubelet=1.31.* kubectl=1.31.* sudo systemctl daemon-reload sudo systemctl restart kubelet |
ベストプラクティス：アップグレードは必ず バックアップ取得 → テスト環境でのリハーサル → 本番実施 のフローを踏むことが推奨されます。
セキュリティ強化策
| 項目 | 実装例 |
|---|---|
| API Server 認証・認可 | --authorization-mode=Node,RBAC がデフォルト。外部 IdP を利用する場合は OIDC 設定 (--oidc-issuer-url, --oidc-client-id) を追加。 |
| etcd バックアップ | bash sudo ETCDCTL_API=3 etcdctl snapshot save /var/backups/etcd-$(date +%F).db --endpoints=https://127.0.0.1:2379 --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/server.crt --key=/etc/kubernetes/pki/etcd/server.key |
| NetworkPolicy（Calico 例） | yaml apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-all namespace: default spec: podSelector: {} policyTypes: - Ingress - Egress |
| Audit ログ | /etc/kubernetes/manifests/kube-apiserver.yaml に - --audit-policy-file=/etc/kubernetes/audit-policy.yaml と - --audit-log-path=/var/log/kubernetes/apiserver-audit.log を追加。 |
備考：etcd のスナップショットは 2 GB 程度のクラスタで約 30 秒で完了します。cron (
0 */6 * * *) に登録し、定期的に取得すると安全です。
まとめと次のアクション
| 項目 | 内容 |
|---|---|
| 前提条件 | Ubuntu 22.04 LTS+, 2 CPU / 4 GB RAM (推奨 8 GB), 必要ポート開放 |
| containerd 設定 | systemd cgroup 有効化、swap 無効化 |
| Kubernetes インストール | apt リポジトリは signed-by 方式で追加し、v1.30.x 系列をインストール・固定 |
| コントロールプレーン初期化 | 必須フラグ (--pod-network-cidr, --control-plane-endpoint) を明示 |
| CNI 選択 | Calico（安定性）または Cilium（eBPF 高性能）を要件に合わせて導入 |
| ワーカーノード参加 | kubeadm token create --print-join-command → kubeadm join |
| RBAC デモ | Namespace・ServiceAccount・Role/RoleBinding の作成例 |
| クラスタ検証 | kubectl get nodes/pods -A と Sonobuoy による Conformance テスト |
| アップグレード手順 | kubeadm upgrade plan/apply と各ノードの kubelet 更新 |
| セキュリティ | API 認証設定、etcd バックアップ、NetworkPolicy・Audit ログ |
次にすべきこと
1. 本稿の手順を自環境で実行し、全コマンドがエラーなく完了するか検証してください。
2. 取得したsonobuoyの結果や etcd スナップショットを保存し、CI/CD パイプラインに組み込むことで継続的な品質保証を実現します。
3. CNI 選定時は パフォーマンスベンチマーク（kube‑bench、wrk2 など） を走らせ、要件に最適なプラグインを正式に決定してください。
以上の手順とチェックリストに沿って作業すれば、Ubuntu 22.04 上で 本番レベルかつセキュアな Kubernetes v1.30 クラスタ を迅速に構築できます。質問や改善点があれば、GitHub の Issue や公式 Slack へお気軽にご相談ください。