手当たり次第に書くんだ

飽きっぽいのは本能

Ubuntu 26.04 Kubernetes ノードの事前準備 – swap / kernel module / sysctl / containerd

作者: si62512548投稿日: カテゴリー: Ubuntuタグ: , , , , , , , , , Ubuntu 26.04 Kubernetes ノードの事前準備 – swap / kernel module / sysctl / containerd へのコメントはまだありません

Ubuntu 26.04 を Kubernetes ノードとして使う前に、OS 側で確認・設定しておく項目を整理します。Kubernetes の構築は kubeadm init や kubeadm join から始まるように見えますが、実際にはその前の OS 前提がかなり重要です。

この記事では、swap、kernel module、sysctl、containerd、kubectl、proxy / registry 到達性、再起動後確認をまとめます。実際の環境では構成管理で収束させていますが、ここでは手動で確認できる形に分解します。

参考
書籍
参考書籍

Kubernetes完全ガイド 第2版

Kubernetes の仕組み、リソース、ネットワーク、運用観点を体系的に確認したい場合の参考書籍です。価格や在庫はリンク先で確認してください。

Amazon で見る

このリンクは Amazon アソシエイトリンクです。

Kubernetes ノード事前準備で確認すること

  • swap が無効化されている
  • 必要な kernel module が読み込まれている
  • bridge packet と IP forwarding の sysctl が設定されている
  • containerd が CRI runtime として動作している
  • kubeadm / kubelet / kubectl を導入できる前提がある
  • proxy や registry への到達性を確認している
  • 再起動後も設定が残る

現在の状態を確認する

まず、ノードの現在状態を確認します。ここで swap や kernel module、containerd の状態を把握します。

hostnamectl
uname -a
free -h
swapon --show
lsmod | grep -E 'br_netfilter|overlay' || true
sysctl net.ipv4.ip_forward net.bridge.bridge-nf-call-iptables net.bridge.bridge-nf-call-ip6tables 2>/dev/null || true
systemctl --no-pager --full status containerd.service || true

swap を無効化する

Kubernetes ノードでは、swap を無効化しておくのが基本です。まず即時無効化し、再起動後に戻らないように /etc/fstab も確認します。

sudo swapoff -a
swapon --show

sudo cp -a /etc/fstab /etc/fstab.bak.$(date +%Y%m%d%H%M%S)
sudo sed -i -E 's#^(/swap\.img\s+none\s+swap\s+sw\s+0\s+0)$#\# \1#' /etc/fstab

grep -n 'swap' /etc/fstab || true

環境によって swap の定義は異なります。/swap.img 以外の swap partition や swap file を使っている場合は、実際の /etc/fstab に合わせて無効化します。

kernel module を読み込む

Kubernetes のコンテナネットワークでは、bridge packet を iptables / nftables 側で扱うために br_netfilter を使う構成があります。また overlay filesystem は container runtime で使われます。

sudo tee /etc/modules-load.d/kubernetes.conf <<'EOF'
overlay
br_netfilter
EOF

sudo modprobe overlay
sudo modprobe br_netfilter

lsmod | grep -E 'overlay|br_netfilter'

sysctl を設定する

bridge 経由の packet を netfilter で扱い、IPv4 forwarding を有効化します。CNI やクラスタネットワークの方式によって必要性は変わりますが、kubeadm 系の一般的な前提として設定しておくことが多いです。

sudo tee /etc/sysctl.d/90-kubernetes.conf <<'EOF'
net.bridge.bridge-nf-call-iptables = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.ipv4.ip_forward = 1
EOF

sudo sysctl -p /etc/sysctl.d/90-kubernetes.conf

IPv6 を使うクラスタでは、IPv6 forwarding や CNI 側の IPv6 設計も別途確認します。ここでは Kubernetes ノードとして最低限確認する代表的な項目を示しています。

containerd を確認する

Kubernetes ノードでは、kubelet が CRI socket 経由で containerd を使います。前の記事で設定した containerd が起動しているか、socket が存在するかを確認します。

systemctl --no-pager --full status containerd.service
ls -l /run/containerd/containerd.sock
sudo ctr version
sudo ctr namespaces list

SystemdCgroup = true や pause image の設定は、containerd 側と kubelet 側の整合性に関わります。Kubernetes 本体の構築前に containerd 単体で正常に動く状態にしておきます。

kubectl を用意する場合

control-plane や管理端末では kubectl が必要です。ノード事前準備の段階で、対象 Kubernetes minor version に合わせて kubectl を導入できることを確認します。

ARCH="$(dpkg --print-architecture)"
K8S_MINOR="1.35"
KUBECTL_VERSION="$(curl -fsSL https://dl.k8s.io/release/stable-${K8S_MINOR}.txt)"

curl -fsSLo /tmp/kubectl "https://dl.k8s.io/release/${KUBECTL_VERSION}/bin/linux/${ARCH}/kubectl"
curl -fsSLo /tmp/kubectl.sha256 "https://dl.k8s.io/release/${KUBECTL_VERSION}/bin/linux/${ARCH}/kubectl.sha256"

echo "$(cat /tmp/kubectl.sha256)  /tmp/kubectl" | sha256sum -c -
sudo install -m 0755 /tmp/kubectl /usr/local/bin/kubectl
kubectl version --client=true

実際には kubeadm / kubelet / kubectl の導入元やバージョン固定方針を決めます。kubectl だけ先に入れる場合も、クラスタの minor version と合わせるのが基本です。

proxy と registry 到達性を確認する

proxy 環境や private registry を使う場合、Kubernetes 構築前に image 取得経路を確認します。containerd や Docker の proxy 設定、NO_PROXY の範囲が重要になります。

env | grep -i proxy || true
curl -I https://registry.k8s.io/ || true
sudo ctr -n k8s.io images pull registry.k8s.io/pause:3.10.1
sudo ctr -n k8s.io images list | grep pause

クラスタ内部の service CIDR、pod CIDR、node network、private registry は NO_PROXY に含めるかを検討します。proxy の設定漏れは kubeadm 実行時よりも、Pod 起動時や image pull 時に表面化しがちです。

再起動後に確認する

Kubernetes ノードの前提は、再起動後にも残る必要があります。設定直後だけでなく、再起動後の状態を確認します。

sudo reboot
swapon --show
lsmod | grep -E 'overlay|br_netfilter'
sysctl net.bridge.bridge-nf-call-iptables net.bridge.bridge-nf-call-ip6tables net.ipv4.ip_forward
systemctl --no-pager --full status containerd.service
ls -l /run/containerd/containerd.sock

確認ポイント

  • swap が無効で、再起動後も有効化されない
  • overlay と br_netfilter が読み込まれている
  • bridge netfilter と IPv4 forwarding の sysctl が有効である
  • containerd が起動し、CRI socket が存在する
  • pause image を取得できる
  • proxy / NO_PROXY の範囲がクラスタ設計と合っている
  • kubectl などのクライアントツールのバージョン方針が決まっている

まとめ

Ubuntu 26.04 の Kubernetes ノード事前準備では、kubeadm を実行する前に OS 側の前提を整えておくことが重要です。swap、kernel module、sysctl、containerd、proxy、registry 到達性を先に確認しておくと、control-plane 構築や worker 参加時の切り分けがかなり楽になります。

次は、この前提を使って Kubernetes コントロールプレーンを構築する手順へ進みます。

関連記事

Ubuntu 26.04 Kubernetes ノードの事前準備 – swap / kernel module / sysctl / containerd

Related posts:

Default ThumbnailUbuntu 26.04 sysctl の基本設定 Default ThumbnailUbuntu 26.04 swap の無効化 Ubuntu 22.04 containerd の設定 – Kubernetes ノード向けに SystemdCgroup を有効化する Default ThumbnailUbuntu 26.04 containerd の基本設定 – Kubernetes 用 CRI runtime を整える VM パフォーマンス Day6 – vhost-net / vhost-user と kernel bypass の考え方 Ubuntu 22.04 Kubernetes 管理ツールのインストール – kubectl / Helm / calicoctl を整理する Ubuntu 22.04 Kubernetes Cilium 導入の事前確認 Ubuntu 22.04 Kubernetes クラスター構築の事前準備 – kubeadm ノードの前提を整える Ubuntu 20.04 Kubernetes Multus（準備中） Default ThumbnailUbuntu 26.04 Kubernetes コントロールプレーン構築 – kubeadm init と dual-stack 設計 Default ThumbnailUbuntu 26.04 Kubernetes ワーカーノード参加 Kubernetes で systemd を実行可能な CentOS コンテナを動かす

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

日本語が含まれない投稿は無視されますのでご注意ください。（スパム対策）

トップへ戻る