古い Kubernetes クラスター構築メモ – kubeadm 手順を現在の記事へ読み替える

この記事は、過去に Kubernetes クラスターを kubeadm で構築したときのメモを、現在読み直せる形に整理したものです。現在の構築手順としては、より整理した記事を別に用意しています。

現在の kubeadm 構築手順は、Kubernetes クラスター構築 – kubeadm で controlPlaneEndpoint と CNI を整理する を参照してください。この記事では、当時の構築で何を考えていたのか、どこを現在の手順へ読み替えるべきかを中心に整理します。

この記事の位置づけ

• 古い Kubernetes クラスター構築メモを整理した記事である
• 現在の手順そのものではなく、当時の設計意図を読むための記事である
• kubeadm、Control Plane、CNI、Worker node 追加という基本構成は今でも参考になる
• 実際に構築する場合は、現在の kubeadm 記事と公式ドキュメントを優先する
• 古いリポジトリ、バージョン、マニフェスト URL はそのまま使わない

当時の記事の核

元の記事の中心は、kubeadm を使って Control Plane を起動し、CNI を追加し、Worker node をクラスターへ参加させるという流れでした。これは Kubernetes クラスター構築の基本形として、現在でも大きくは変わりません。

一方で、Kubernetes はバージョンごとの変更が大きく、リポジトリ、CNI マニフェスト、CRI、cgroup driver、kubeadm API version などは変わります。そのため、古いコマンドをそのまま実行する記事として読むのは危険です。

現在読む場合の注意点

• kubeadm の設定 API version を現在のバージョンに合わせる
• containerd の SystemdCgroup を確認する
• CNI のマニフェスト URL とバージョンを確認する
• Pod CIDR と Service CIDR が既存ネットワークと重複しないようにする
• API endpoint を単一ノード名ではなくロードバランサーの FQDN / VIP として考える

Control Plane の起動は設計値が重要

Control Plane の起動では、kubeadm init のコマンドよりも、事前に決める設計値が重要です。特に controlPlaneEndpoint、Pod CIDR、Service CIDR、node IP、CNI の選択は、クラスターの後戻りしにくい部分です。

# 現在は単発コマンドよりも、設定ファイルに設計値をまとめてから初期化する
sudo kubeadm init --config ~/work/k8s/kubeadm-config.yaml --upload-certs

古いメモではその場の構築手順として書いていましたが、現在の記事としては、設計値を kubeadm-config.yaml にまとめる方が読みやすく、再利用もしやすいです。

CNI はバージョンと CIDR を確認する

CNI の追加も、古いマニフェスト URL をそのまま使うのではなく、利用する Kubernetes バージョンと CNI バージョンの対応を確認します。Calico を使う場合でも、Pod CIDR を変更しているなら CNI 側の設定も合わせる必要があります。

kubectl get pods -n kube-system
kubectl get nodes -o wide

CNI 導入後にノードが Ready にならない場合は、CNI Pod、kubelet、containerd、Pod CIDR、ノード IP の順に確認します。

Worker node 追加は join コマンドの意味を分ける

Worker node の追加では kubeadm join を実行します。Control Plane 追加用の join コマンドとは意味が違うため、出力されたコマンドを混同しないことが重要です。

kubeadm token create --print-join-command
kubectl get nodes -o wide

トークンは期限切れになるため、古いメモに残っている join コマンドは再利用できません。必要なときに再発行します。

現在の手順へ読み替える

現在の構築では、この記事を入口にするより、次の順番で読む方が分かりやすいです。

• Ubuntu 22.04 の基本設定を整える
• containerd を Kubernetes ノード向けに設定する
• kubeadm ノードの事前準備を行う
• kubeadm 設定ファイルを作成して Control Plane を初期化する
• CNI を導入し、Worker node を追加する

まとめ

この古い Kubernetes 構築メモは、当時の試行錯誤としては有用ですが、現在そのまま実行する手順としては扱わない方がよいです。Kubernetes はバージョン、CRI、CNI、リポジトリ構成が変わるため、古いコマンドを保存するより、設計の考え方として読む方が安全です。

現在の構築では、containerd、kubeadm ノード準備、kubeadm 設定ファイル、CNI、join コマンドの意味を分けて整理します。古いメモはその背景を知るための記事として残し、実際の手順は現在の整理済み記事へ寄せます。

関連記事

• Kubernetes クラスター構築 – kubeadm で controlPlaneEndpoint と CNI を整理する
• Ubuntu 22.04 Kubernetes クラスター構築の事前準備 – kubeadm ノードの前提を整える
• Ubuntu 22.04 containerd の設定 – Kubernetes ノード向けに SystemdCgroup を有効化する
• Ubuntu 22.04 Kubernetes 管理ツールのインストール – kubectl / Helm / calicoctl を整理する
• Ubuntu 22.04 HAProxy ロードバランサー – frontend / backend とヘルスチェック

Related posts:

Kubernetes クラスタの初期化 – kubeadm reset の基本 Ubuntu 22.04 Kubernetes クラスター構築の事前準備 – kubeadm ノードの前提を整える Kubernetes クラスター構築 – kubeadm で controlPlaneEndpoint と CNI を整理する Kubernetes Helmの導入 Kubernetes MetalLB導入 Helm版 Kubernetes 1 つの Pod 内で複数の CentOS コンテナを実行する Kubernetes Nginx コンテナと Service NodePort Kubernetes Nginx コンテナと Service LoadBalancer Kubernetes に Docker / Podman のような stop/start がない理由 Kubernetes Multus がうまく動かない時に考えること – CNI を複数持つ難しさ Kubernetes を前提とした仮想 アーキテクチャの考察 Kubernetes コントロールプレーンノードを追加できない場合