Kubernetes クラスタ構築手順 2026：OS設定・Podman・Kind・Argo CD 完全ガイド

Contents

1 1. 前提条件と OS 設定
2 2. Windows 環境でのローカルクラスター構築（Podman Desktop + Kind）
3 3. Linux サーバー（Ubuntu/Debian）での本番クラスター構築
4 4. ネットワーク・CNI とセキュリティのベストプラクティス
- 4.1 4.1 CNI の選択指針（2026 年版）
  - 4.1.1 Calico デプロイ例
  - 4.1.2 Cilium デプロイ例
- 4.2 4.2 ポリシーと OPA Gatekeeper
  - 4.2.1 サンプル ConstraintTemplate（非 root 必須）
  - 4.2.2 Constraint の適用
5 5. GitOps による継続的デプロイ
6 6. トラブルシューティングと運用チェックリスト
7 おわりに

スポンサードリンク

1. 前提条件と OS 設定

1.1 対応 OS と最低バージョン

OS	推奨バージョン	必要ツール
Windows 11（ビルド 22621 以降）	Podman Desktop v5 系、Kind v0.23 系	PowerShell 7、WSL2 (任意)
macOS Monterey 以上（Intel / Apple Silicon）	Homebrew、Podman Desktop、Kind	Xcode Command Line Tools
Ubuntu 22.04 LTS / Debian 12	Linux カーネル 6.5 系、containerd v2.x、kubeadm v1.30	`apt` (APT 2.7+)、systemd

ポイント
- kubeadm v1.30 は cgroup v2 と Linux カーネル 5.15 以上 を必須とします。Ubuntu/Debian の場合は、6.x 系カーネルがデフォルトで提供されている 22.04/12 にアップグレードしておくのが安全です。
- Windows では WSL2 上に Ubuntu を入れても構いませんが、Podman Desktop が直接コンテナランタイムを提供するため必須ではありません。

1.2 カーネルモジュール・cgroup の有効化

# 必要なカーネルモジュールのロード
sudo modprobe overlay
sudo modprobe br_netfilter

# 永続設定（再起動後も有効）
cat &lt;&lt;EOF | sudo tee /etc/modules-load.d/k8s.conf
overlay
br_netfilter
EOF

# sysctl 設定
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
sudo sysctl --system

# cgroup v2 の強制有効化（Ubuntu/Debian）
sudo sed -i 's/^GRUB_CMDLINE_LINUX=&quot;/&amp;systemd.unified_cgroup_hierarchy=1 /' \
    /etc/default/grub
sudo update-grub &amp;&amp; sudo reboot

# 必要なカーネルモジュールのロード

sudo modprobe overlay

sudo modprobe br_netfilter

# 永続設定（再起動後も有効）

cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf

overlay

br_netfilter

EOF

# sysctl 設定

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

sudo sysctl --system

# cgroup v2 の強制有効化（Ubuntu/Debian）

sudo sed -i 's/^GRUB_CMDLINE_LINUX="/&systemd.unified_cgroup_hierarchy=1 /' \

/etc/default/grub

sudo update-grub && sudo reboot

備考
cgroup v2 が有効になっているかは cat /proc/filesystems | grep cgroup2 で確認できます。

1.3 スワップの無効化

# 今回のセッションだけスワップをオフ
sudo swapoff -a

# 永続的に無効化（/etc/fstab の該当行をコメントアウト）
sudo sed -i '/\bswap\b/ s/^/#/' /etc/fstab

# 今回のセッションだけスワップをオフ

sudo swapoff -a

# 永続的に無効化（/etc/fstab の該当行をコメントアウト）

sudo sed -i '/\bswap\b/ s/^/#/' /etc/fstab

Kubeadm はスワップが有効なノードの起動を拒否します。

2. Windows 環境でのローカルクラスター構築（Podman Desktop + Kind）

2.1 必要ツールと公式ドキュメント

ツール	バージョン	入手先・公式ドキュメント
Podman Desktop	v5.4 以降（2026 年 3 月リリース）	https://podman.io/docs/desktop
Kind	v0.23.x 系（2026 年 1 月最新版）	https://kind.sigs.k8s.io/

注意点
- Podman Desktop のインストーラは MSI または .exe が提供されていますが、公式サイトの「Windows 10/11 (64‑bit)」ページから必ず最新版を取得してください。
- apt-key は廃止済みであり、Podman Desktop でも同様に GPG 鍵は keyring ディレクトリへ配置されます（インストーラが自動処理）。

2.2 Podman Desktop のセットアップ

上記公式リンクから Podman-Desktop-5.x.exe をダウンロードし、管理者権限で実行。
インストール画面の 「Docker Desktop 互換モード」 は OFF、「containerd モード」 を選択。
設定 → Engine タブで "Enable Kubernetes (experimental)" は無効のままで完了。Podman が提供する CRI (/run/podman/io.containerd.runtime.v2.task) をそのまま利用します。

トラブルシューティング
- インストール後に「Podman が起動しない」場合は、%ProgramData%\Podman\podman.service の ExecStart パスが正しいか確認し、サービスを再起動 (services.msc) してください。

2.3 Kind バイナリの取得とパス設定

# 最新リリース情報は GitHub API で取得可能（例：v0.23.1）
$kindVersion = &quot;v0.23.1&quot;
Invoke-WebRequest -Uri &quot;https://kind.sigs.k8s.io/download/${kindVersion}/kind-windows-amd64.exe&quot; `
    -OutFile &quot;$HOME\kind.exe&quot;

# パスを永続化（ユーザープロファイルの環境変数に追加）
[Environment]::SetEnvironmentVariable('Path', $env:Path + &quot;;$HOME&quot;, 'User')

# 最新リリース情報は GitHub API で取得可能（例：v0.23.1）

$kindVersion = "v0.23.1"

Invoke-WebRequest -Uri "https://kind.sigs.k8s.io/download/${kindVersion}/kind-windows-amd64.exe" `

-OutFile "$HOME\kind.exe"

# パスを永続化（ユーザープロファイルの環境変数に追加）

[Environment]::SetEnvironmentVariable('Path', $env:Path + ";$HOME", 'User')

kind version が v0.23.x と表示されればインストール成功です。

2.4 Kind クラスタ作成例

# config.yaml（kubeadm v1.30 相当の設定）
@&quot;
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
  - role: control-plane
    extraPortMappings:
      - containerPort: 6443
        hostPort: 6443
runtimeConfig:
  &quot;containerd.runtimes.runc.options.SystemdCgroup&quot;: true
&quot;@ | Out-File -Encoding utf8 config.yaml

# クラスタ作成
kind create cluster --config=config.yaml

# config.yaml（kubeadm v1.30 相当の設定）

kind: Cluster

apiVersion: kind.x-k8s.io/v1alpha4

nodes:

- role: control-plane

extraPortMappings:

- containerPort: 6443

hostPort: 6443

runtimeConfig:

"containerd.runtimes.runc.options.SystemdCgroup": true

"@ | Out-File -Encoding utf8 config.yaml

# クラスタ作成

kind create cluster --config=config.yaml

作成後は以下でバージョンを確認します。

kubectl version --short   # Server: v1.30.x が出れば OK
kubectl get nodes -o wide  # Ready 状態が確認できる

kubectl version --short # Server: v1.30.x が出れば OK

kubectl get nodes -o wide # Ready 状態が確認できる

3. Linux サーバー（Ubuntu/Debian）での本番クラスター構築

2026 年時点のコンテナランタイム情報
- containerd は v2.2 系 が LTS として提供され、公式リポジトリでも 2.* パッケージとして利用可能です。
- kubeadm の最新安定版は v1.30（2026‑02 リリース）で、cgroup v2・CRI v1 が必須条件です。

3.1 containerd のインストール（apt-key 非推奨対応）

# Docker 社が提供する公式 apt リポジトリを利用（signed-by 方式）
sudo mkdir -p /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg \
    | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg

# Ubuntu 22.04 (jammy) 向けリポジトリ定義
echo &quot;deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] \
https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable&quot; | \
    sudo tee /etc/apt/sources.list.d/docker.list &gt; /dev/null

sudo apt-get update
# バージョン 2.2 系を明示的にインストール
sudo apt-get install -y containerd.io=2.2.*

# Docker 社が提供する公式 apt リポジトリを利用（signed-by 方式）

sudo mkdir -p /etc/apt/keyrings

curl -fsSL https://download.docker.com/linux/ubuntu/gpg \

| sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg

# Ubuntu 22.04 (jammy) 向けリポジトリ定義

echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] \

https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | \

sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt-get update

# バージョン 2.2 系を明示的にインストール

sudo apt-get install -y containerd.io=2.2.*

設定ファイルの調整

sudo mkdir -p /etc/containerd
containerd config default | sudo tee /etc/containerd/config.toml

# systemd cgroup を強制
sudo sed -i 's/systemd_cgroup = false/systemd_cgroup = true/' \
    /etc/containerd/config.toml

sudo systemctl enable --now containerd

sudo mkdir -p /etc/containerd

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

# systemd cgroup を強制

sudo sed -i 's/systemd_cgroup = false/systemd_cgroup = true/' \

/etc/containerd/config.toml

sudo systemctl enable --now containerd

ポイント：/etc/containerd/config.toml の version = 2 がデフォルトで有効です。もし 2.* パッケージが見つからない場合は、Docker リポジトリの stable チャネルではなく test (download.docker.com/linux/ubuntu/... test) を使用してください。

3.2 kubeadm / kubelet / kubectl のインストール

# GPG 鍵は apt-key 非推奨に合わせて keyring に保存
sudo mkdir -p /etc/apt/keyrings
curl -fsSL https://packages.cloud.google.com/apt/doc/apt-key.gpg \
    | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-archive-keyring.gpg

# Kubernetes リポジトリ（v1.30 系）を追加
echo &quot;deb [signed-by=/etc/apt/keyrings/kubernetes-archive-keyring.gpg] \
https://apt.kubernetes.io/ kubernetes-xenial main&quot; | \
    sudo tee /etc/apt/sources.list.d/kubernetes.list

sudo apt-get update
sudo apt-get install -y kubeadm=1.30.* kubelet=1.30.* kubectl=1.30.*

# kubelet の cgroup ドライバを systemd に固定
echo &quot;KUBELET_EXTRA_ARGS=--cgroup-driver=systemd&quot; | \
    sudo tee /etc/default/kubelet

sudo systemctl daemon-reload &amp;&amp; sudo systemctl restart kubelet

# GPG 鍵は apt-key 非推奨に合わせて keyring に保存

sudo mkdir -p /etc/apt/keyrings

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

| sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-archive-keyring.gpg

# Kubernetes リポジトリ（v1.30 系）を追加

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

https://apt.kubernetes.io/ kubernetes-xenial main" | \

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

sudo apt-get update

sudo apt-get install -y kubeadm=1.30.* kubelet=1.30.* kubectl=1.30.*

# kubelet の cgroup ドライバを systemd に固定

echo "KUBELET_EXTRA_ARGS=--cgroup-driver=systemd" | \

sudo tee /etc/default/kubelet

sudo systemctl daemon-reload && sudo systemctl restart kubelet

注意：apt-key add は 2024 年に廃止されたため、上記のように signed-by= オプションで keyring を指定します。

3.3 マスターノード初期化

cat &lt;&lt;EOF &gt; /root/kubeadm-config.yaml
apiVersion: kubeadm.k8s.io/v1beta4
kind: InitConfiguration
nodeRegistration:
  criSocket: /run/containerd/containerd.sock
localAPIEndpoint:
  advertiseAddress: &quot;$(hostname -I | awk '{print $1}')&quot;
---
apiVersion: kubeadm.k8s.io/v1beta4
kind: ClusterConfiguration
kubernetesVersion: v1.30.0
controlPlaneEndpoint: &quot;lb.example.com:6443&quot;
networking:
  podSubnet: &quot;192.168.0.0/16&quot;
cgroupDriver: systemd
EOF

sudo kubeadm init --config=/root/kubeadm-config.yaml

cat <<EOF > /root/kubeadm-config.yaml

apiVersion: kubeadm.k8s.io/v1beta4

kind: InitConfiguration

nodeRegistration:

criSocket: /run/containerd/containerd.sock

localAPIEndpoint:

advertiseAddress: "$(hostname -I | awk '{print $1}')"

---

apiVersion: kubeadm.k8s.io/v1beta4

kind: ClusterConfiguration

kubernetesVersion: v1.30.0

controlPlaneEndpoint: "lb.example.com:6443"

networking:

podSubnet: "192.168.0.0/16"

cgroupDriver: systemd

EOF

sudo kubeadm init --config=/root/kubeadm-config.yaml

初期化が成功したら、管理者用の kubeconfig を設定します。

mkdir -p $HOME/.kube
sudo cp /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

mkdir -p $HOME/.kube

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

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

3.4 ワーカーノードの参加

マスターノードが出力した kubeadm join … コマンドを各ワーカーで実行します。例:

sudo kubeadm join 10.0.1.100:6443 \
    --token abcdef.0123456789abcdef \
    --discovery-token-ca-cert-hash sha256:&lt;hash&gt; \
    --cri-socket /run/containerd/containerd.sock

sudo kubeadm join 10.0.1.100:6443 \

--token abcdef.0123456789abcdef \

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

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

全ノードが kubectl get nodes に Ready と表示されれば完了です。

4. ネットワーク・CNI とセキュリティのベストプラクティス

4.1 CNI の選択指針（2026 年版）

CNI	主な特徴	推奨シナリオ
Calico v3.28	IPIP/VXLAN + BGP、NetworkPolicy が豊富	大規模クラスタ、オンプレ/ハイブリッド
Cilium v1.14	eBPF ベースで高性能、Kube‑Proxy 置換可	高トラフィック・マイクロサービス指向

両方とも kubernetesVersion: v1.30 に対応しており、公式マニフェストは常に最新版が提供されています。

Calico デプロイ例

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

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

Pod CIDR は 192.168.0.0/16（マスタ設定と合わせる）
IPIP 暗号化はデフォルトで有効

Cilium デプロイ例

kubectl apply -f https://raw.githubusercontent.com/cilium/cilium/v1.14/install/kubernetes/quick-install.yaml

1 2	kubectl apply -f https://raw.githubusercontent.com/cilium/cilium/v1.14/install/kubernetes/quick-install.yaml

カーネルが eBPF 対応（5.15 以上）であれば自動的に最適化モードへ切り替わります。

4.2 ポリシーと OPA Gatekeeper

2026 年は PodSecurityPolicy が正式に廃止され、代替として OPA Gatekeeper がデファクトスタンダードです。

kubectl apply -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper/master/deploy/gatekeeper.yaml

1 2	kubectl apply -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper/master/deploy/gatekeeper.yaml

サンプル ConstraintTemplate（非 root 必須）

apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
  name: k8s-nonroot
spec:
  crd:
    spec:
      names:
        kind: K8sNonRoot
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8s.nonroot
        violation[{&quot;msg&quot;: msg}] {
          input.review.object.spec.securityContext.runAsNonRoot != true
          msg := &quot;Containers must run as non‑root&quot;
        }

apiVersion: templates.gatekeeper.sh/v1beta1

kind: ConstraintTemplate

metadata:

spec:

crd:

spec:

names:

kind: K8sNonRoot

targets:

- target: admission.k8s.gatekeeper.sh

rego: |

package k8s.nonroot

violation[{"msg": msg}] {

input.review.object.spec.securityContext.runAsNonRoot != true

msg := "Containers must run as non‑root"

}

Constraint の適用

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sNonRoot
metadata:
  name: require-non-root
spec:
  match:
    kinds:
      - apiGroups: [&quot;&quot;]
        kinds: [&quot;Pod&quot;]

apiVersion: constraints.gatekeeper.sh/v1beta1

kind: K8sNonRoot

metadata:

spec:

match:

kinds:

- apiGroups: [""]

kinds: ["Pod"]

5. GitOps による継続的デプロイ

5.1 Argo CD のインストール（v2.9 系）

kubectl create namespace argocd
helm repo add argo https://argoproj.github.io/argo-helm
helm install argo-cd argo/argo-cd \
    --namespace argocd \
    --version 2.9.0

kubectl create namespace argocd

helm repo add argo https://argoproj.github.io/argo-helm

helm install argo-cd argo/argo-cd \

--namespace argocd \

--version 2.9.0

インストール完了後はポートフォワードで UI にアクセス：

kubectl -n argocd port-forward svc/argocd-server 8080:443
# ブラウザで https://localhost:8080 にアクセス（デフォルトは admin / 初回パスフレーズは `admin.password` Secret）

kubectl -n argocd port-forward svc/argocd-server 8080:443

# ブラウザで https://localhost:8080 にアクセス（デフォルトは admin / 初回パスフレーズは `admin.password` Secret）

5.2 アプリケーション定義例

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: hello-world
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/example/hello-k8s
    targetRevision: HEAD
    path: manifests
  destination:
    server: https://kubernetes.default.svc
    namespace: default
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

apiVersion: argoproj.io/v1alpha1

kind: Application

metadata:

namespace: argocd

spec:

project: default

source:

repoURL: https://github.com/example/hello-k8s

targetRevision: HEAD

path: manifests

destination:

server: https://kubernetes.default.svc

namespace: default

syncPolicy:

automated:

prune: true

selfHeal: true

Argo CD は Git の状態とクラスタの実際の状態を常に比較し、差分があれば自動で修正（プルリクエストベースでも可）します。

5.3 リソース制限・監視・ロギングの統合

コンポーネント	Helm Chart	主な目的
kube‑prometheus‑stack	prometheus-community/kube-prometheus-stack	メトリクス収集、アラート
Loki + Promtail	grafana/loki-stack	ログ集約・検索
Grafana	grafana/grafana	可視化ダッシュボード

例：Prometheus のインストール

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm install monitoring prometheus-community/kube-prometheus-stack \
    --namespace monitoring --create-namespace

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts

helm install monitoring prometheus-community/kube-prometheus-stack \

--namespace monitoring --create-namespace

6. トラブルシューティングと運用チェックリスト

6.1 基本的な診断フロー

コンポーネントのステータス確認
bash systemctl status kubelet containerd
ジャーナルログでエラーワード検索
bash journalctl -u kubelet | grep -i error journalctl -u containerd | grep -i failed
Pod の詳細確認
bash kubectl get pods -A -o wide kubectl describe pod <pod> -n kube-system
ネットワークの疎通テスト
bash kubectl run -i --tty net-test --image=busybox -- sh # コンテナ内で ping -c 3 8.8.8.8 nslookup kubernetes.default

6.2 よくある障害と対処法

障害シナリオ	原因例	対策
kubelet が起動しない	`cgroupDriver` の不一致、/etc/default/kubelet 設定ミス	`/var/log/syslog` と `journalctl -u kubelet` で `systemd_cgroup` が true か確認
containerd がイメージ取得に失敗	DNS 解決不可、ストレージドライバ (overlay2) の不整合	`/etc/containerd/config.toml` の `snapshotter = "overlayfs"` を明示し、`/etc/resolv.conf` に正しい nameserver を設定
CoreDNS が名前解決できない	ConfigMap の `forward . /etc/resolv.conf` が削除されている	`kubectl -n kube-system edit configmap coredns` で `forward` セクションを復元
PodSecurity (Gatekeeper) による拒否	コンテナが root ユーザーで起動している	Manifest の `securityContext.runAsNonRoot: true` を追加、または ConstraintTemplate を調整

6.3 運用時の定期チェックリスト

毎日：kubectl get nodes, kubectl top nodes（リソース余裕を確認）
週次：Prometheus のアラート履歴レビュー、helm list -A でチャートバージョン更新有無をチェック
月次：Kubernetes と containerd のパッチ適用計画作成（例：kubeadm upgrade plan）

おわりに

本稿では 2026 年版 の Kubernetes クラスタ構築・運用フローを、Windows のローカル開発環境から Ubuntu/Debian 本番サーバーまで一貫してカバーしました。
- 最新のパッケージ取得方法（apt-key 非推奨対応） を示したことで、インストール時のエラーを回避できます。
- Podman Desktop + Kind の公式リンク と手順により、Windows ユーザーでも安全にクラスターを作成可能です。
- containerd v2.x と kubeadm v1.30 の正確な前提条件 を明記し、リスクの低減を図っています。

このガイドをベースに、組織独自の CI/CD パイプラインやセキュリティ基準へ拡張すれば、2026 年以降も安定した Kubernetes 運用が実現できるでしょう。

スポンサードリンク