1. 概要

Kubernetesは、Googleによって開発されたコンテナ運用管理を支援するオープンソースです。Dockerなどのコンテナ仮想化ソフトウェアを管理、および自動化するために使用される強力なコンテナオーケストレーションプラットフォームとなります。
Kubernetesの主な機能は以下の通りです。

コンテナ起動管理：コンテナの起動、停止、再起動などを自動的に行う
コンテナ起動ノードの自動選定：リソースの状況に応じて、最適なノードでコンテナを実行
コンテナとKubernetesクラスタ外部との接続や負荷分散：サービスの公開や負荷分散を自動化
コンテナとボリュームの連携：データの永続化を実現

このガイドでは、Ubuntu 22.04 に Kubernetes をインストールする手順をステップバイステップで説明しています。想定するクラスター構成はひとつのマスターノードと複数のワーカーノードです。
なお、本ガイドでは CNI プラグインに Calico を使用しています。

1.1. Kubernetes ノード

Kubernetes クラスターには、2 種類のノードが存在します。クラスターの構成は下図のようになります。

1.1.1. マスターノード

マスターノード（コントロールプレーンノードとも呼ばれます）は、クラスターの管理と制御を担当します。以下に、その主な役割と機能を示します。

API Server
Kubernetes APIを公開し、ユーザーや kubelet のようなクラスターコンポーネントからのリクエストを処理します。
Scheduler
Pod がどのノードに配置されるべきかを決定します。
Controller Manager
クラスター全体の状態を監視し、必要に応じて自動的に調整します。例えば、ReplicaSet のレプリカの数が指定した数と一致していない場合、新しい Pod を作成します。
etcd
すべてのクラスターデータを保持するための高信頼性キーバリューストアです。

1.1.2. ワーカーノード

ワーカーノードは、アプリケーションのワークロードを実行するマシンです。以下に、その主な役割と機能を示します

リソースの提供
ワーカーノードは計算リソース（CPU、メモリ）、ストレージ、ネットワークを提供します。
Podの実行
ワーカーノードは、マスターノードから割り当てられたタスクを実行します。これらのタスクは、Pod と呼ばれる Kubernetes の基本的なデプロイ単位で、1つ以上のコンテナを含むことができます。
kubeletの実行
kubelet は各ワーカーノード上で実行されるサービスでありコンテナの管理を担当します。kubeletは、コンテナが稼働していることを確認し、健康状態を監視し、APIサーバーと通信してノード上のリソースを管理します。
kube-proxyの実行
kube-proxyは各ワーカーノード上で実行されるネットワークプロキシであり、Kubernetesのサービス抽象化を実装します。

2. 導入の前提条件

インストールを始める前に、環境が次の前提条件を満たしていることを確認してください。

Ubuntu 22.04 システム
1 台当たり最低 2 GB以上のメモリ
2 コア以上の CPU
特権アクセス (root または sudo ユーザー)
インターネット接続が可能
/var に 20 GB 以上の空きディスク容量

3. 導入手順

3.1. Ubuntu の更新およびアップグレード (全ノード)

最初に、システムが最新であることを確認します。ターミナルで、次のコマンドを実行します。

sudo apt update
sudo apt upgrade

3.2. スワップの無効化（全ノード）

Kubernetes のパフォーマンス向上とリソース制限の予測可能性を高めるため、スワップを無効にして、必要なカーネルパラメータを設定します。すべてのスワップを無効にするには、すべてのノードで次のコマンドを実行します。

sudo swapoff -a 
sudo sed -i '/ swap / s/^\(.*\)$/#\1/g' /etc/fstab

/etc/fstab が正しく編集されているか確認します。/swapfile がコメントアウトされていれば OK です。
これでサーバを再起動しても常に swapoff の状態になります。

cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda3 during installation
UUID=d3256226-bfc2-43f0-b029-df5700264b3d /               ext4    errors=remount-ro 0       1
# /boot/efi was on /dev/sda2 during installation
UUID=7B11-A72D  /boot/efi       vfat    umask=0077      0       1
#/swapfile                                 none            swap    sw              0       0
#/dev/fd0        /media/floppy0  auto    rw,user,noauto,exec,utf8 0       0

/etc/fstab ファイル内で " swap " という文字列が含まれる行を探し、その行の先頭に "#" を追加します。これにより、その行はコメントアウトされます。

sed: ストリームエディタで、テキストファイルを操作するためのコマンド
-i: sedのオプションで、ファイルを直接編集することを指定
'/ swap / s/^\(.*\)\$/#\1/g' :　" swap " というパターンが含まれる行を探し、その行全体（^(.*)$）を#\1（#とその行の内容）に置き換え

3.3. カーネルパラメータの追加（全ノード）

すべてのノードに必要なカーネルモジュールをロードします。

sudo tee /etc/modules-load.d/containerd.conf << EOF
overlay
br_netfilter
EOF
sudo modprobe overlay
sudo modprobe br_netfilter

Flannel や Calico などの CNI プラグインは、オーバーレイネットワークを実現する一つの手段として使用されますが、それらのCNIプラグインを使用するためには、overlay と br_netfilter の２つのカーネルモジュールが必要です。
overlay
物理的な接続や配置に関係なく、任意のノード間で仮想的なネットワークを形成することができるようにします。
br_netfilter
Pod 間や異なるネットワークセグメント間の通信においても、トラフィックの制御とフィルタリングを可能にします。

次のコマンドを使用して、Kubernetes に必要なカーネルパラメータを構成します。

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

次に、変更をリロードします。

sudo sysctl --system

net.bridge.bridge-nf-call-ip6tables = 1 と net.bridge.bridge-nf-call-iptables = 1 は、Linux ブリッジが IPテーブル（iptables/ip6tables）のルールを適用するようにします。これにより、Kubernetes の Pod 間のネットワークトラフィックが正しくルーティングされます。
net.ipv4.ip_forward = 1 は、IPv4トラフィックの転送を有効にします。これにより、異なるネットワーク間でのパケットの転送が可能になります。
この設定ファイルを作成した後、sudo sysctl --system コマンドを実行することで、これらの新しいカーネルパラメータがシステムに適用されます。

3.4. Containerd Runtime をインストール（全ノード）

containerd ランタイムを使用するため、次のコマンドを使用して、containerd とその依存関係をインストールします。

sudo apt install -y curl gnupg2 software-properties-common apt-transport-https ca-certificates

curl
コマンドラインツールで、URL構文を使用してデータを転送します。HTTP, HTTPS, FTP, FTPSなどの多くのプロトコルをサポートしています。データのアップロードやダウンロード、HTTPリクエストの送信など、さまざまなネットワーク操作を行うことができます。
gnupg
GnuPG（GNU Privacy Guard）のバージョン2です。これはデータの暗号化とデジタル署名を行うためのツールです。公開鍵暗号方式を使用しており、情報のプライバシーと真正性を保証します。
software-properties-common
Ubuntu のソフトウェアプロパティの管理ツールです。PPA (Personal Package Archives) などの追加リポジトリをシステムに追加するために使用されます。これにより、デフォルトの Ubuntu リポジトリにはないソフトウェアを簡単にインストールできます。
apt-transport-https
APTパッケージ管理ツールが HTTPS 経由でパッケージリポジトリにアクセスできるようにするモジュールです。これにより、セキュアな接続を通じてソフトウェアパッケージをダウンロードできます。
ca-certificates
一連の「信頼された」CA（認証局）の証明書をシステムにインストールします。これらの証明書は、HTTPS 接続の際にサーバー証明書を検証するために使用されます。

Docker をインストールするためのリポジトリを有効にします。

sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmour -o /etc/apt/trusted.gpg.d/docker.gpg 
sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"

1行目
Docker の公式 GPG キーをダウンロードし、それを APT パッケージマネージャが信頼するキーとしてシステムに追加します（--dearmour は ASCII形式でエンコードされた入力をバイナリ形式に変換）。これにより、後続の Docker パッケージのインストールが信頼できるソースから行われることをシステムが認識できます。
2行目
システムの APT リポジトリリストに Docker の公式 Ubuntuリポジトリを追加します。これにより、apt-get install コマンドを使用して Docker パッケージをインストールできるようになります。$(lsb_release -cs)は、現在の Ubuntu のバージョン（例えば、jammy など）を出力します。これにより、適切なバージョンの Docker がインストールされます。

パッケージリストを更新し、containerd をインストールします。

sudo apt update 
sudo apt install -y containerd.io

systemd を cgroup として使用するために containerd を設定します。

containerd config default | sudo tee /etc/containerd/config.toml >/dev/null 2>&1 
sudo sed -i 's/SystemdCgroup \= false/SystemdCgroup \= true/g' /etc/containerd/config.toml

containerd config default コマンドは、containerdのデフォルト設定を生成します。このコマンドを実行すると、containerdのデーモンに対する設定ファイルが出力されます。この設定ファイルは /etc/containerd/config.toml に配置することが一般的です。
次にこのファイル内の SystemdCgroup の値を false から true に変更します。

containerd サービスを再起動して有効にします。

sudo systemctl restart containerd
sudo systemctl enable containerd

3.5. Kubernetes 用の Apt リポジトリを追加 (全ノード)

Kubernetes パッケージは、デフォルトの Ubuntu 22.04 リポジトリでは利用できません。次のコマンドを使用して Kubernetes リポジトリを追加します。

curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo gpg --dearmour -o /etc/apt/trusted.gpg.d/kubernetes-xenial.gpg 
sudo apt-add-repository "deb http://apt.kubernetes.io/ kubernetes-xenial main"

3.6. Kubectl、Kubeadm、Kubelet をインストール (全ノード)

リポジトリを追加したら、次のコマンドを使用して、kubectl、kubelet、kubeadm などの重要な Kubernetes コンポーネントをすべてのノードにインストールします。

sudo apt update 
sudo apt install -y kubelet kubeadm kubectl 
sudo apt-mark hold kubelet kubeadm kubectl

3.7. Kubeadm (マスターノード) を使用して Kubernetes クラスターを初期化

すべての前提条件が整ったら、次の Kubeadm コマンドを使用してマスターノード上の Kubernetes クラスターを初期化します。

sudo kubeadm init
[init] Using Kubernetes version: v1.30.2
[preflight] Running pre-flight checks
[preflight] Pulling images required for setting up a Kubernetes cluster
[preflight] This might take a minute or two, depending on the speed of your internet connection
[preflight] You can also perform this action in beforehand using 'kubeadm config images pull'
W1102 19:06:53.288119   10840 checks.go:835] detected that the sandbox image "registry.k8s.io/pause:3.6" of the container runtime is inconsistent with that used by kubeadm. It is recommended that using "registry.k8s.io/pause:3.9" as the CRI sandbox image.
[certs] Using certificateDir folder "/etc/kubernetes/pki"
[certs] Generating "ca" certificate and key
[certs] Generating "apiserver" certificate and key
[certs] apiserver serving cert is signed for DNS names [kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local master] and IPs [10.96.0.1 192.168.79.130]
[certs] Generating "apiserver-kubelet-client" certificate and key
[certs] Generating "front-proxy-ca" certificate and key
[certs] Generating "front-proxy-client" certificate and key
[certs] Generating "etcd/ca" certificate and key
[certs] Generating "etcd/server" certificate and key
[certs] etcd/server serving cert is signed for DNS names [localhost master] and IPs [192.168.79.130 127.0.0.1 ::1]
[certs] Generating "etcd/peer" certificate and key
[certs] etcd/peer serving cert is signed for DNS names [localhost master] and IPs [192.168.79.130 127.0.0.1 ::1]
[certs] Generating "etcd/healthcheck-client" certificate and key
[certs] Generating "apiserver-etcd-client" certificate and key
[certs] Generating "sa" key and public key
[kubeconfig] Using kubeconfig folder "/etc/kubernetes"
[kubeconfig] Writing "admin.conf" kubeconfig file
[kubeconfig] Writing "kubelet.conf" kubeconfig file
[kubeconfig] Writing "controller-manager.conf" kubeconfig file
[kubeconfig] Writing "scheduler.conf" kubeconfig file
[etcd] Creating static Pod manifest for local etcd in "/etc/kubernetes/manifests"
[control-plane] Using manifest folder "/etc/kubernetes/manifests"
[control-plane] Creating static Pod manifest for "kube-apiserver"
[control-plane] Creating static Pod manifest for "kube-controller-manager"
[control-plane] Creating static Pod manifest for "kube-scheduler"
[kubelet-start] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet-start] Starting the kubelet
[wait-control-plane] Waiting for the kubelet to boot up the control plane as static Pods from directory "/etc/kubernetes/manifests". This can take up to 4m0s
[apiclient] All control plane components are healthy after 8.002720 seconds
[upload-config] Storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
[kubelet] Creating a ConfigMap "kubelet-config" in namespace kube-system with the configuration for the kubelets in the cluster
[upload-certs] Skipping phase. Please see --upload-certs
[mark-control-plane] Marking the node master as control-plane by adding the labels: [node-role.kubernetes.io/control-plane node.kubernetes.io/exclude-from-external-load-balancers]
[mark-control-plane] Marking the node master as control-plane by adding the taints [node-role.kubernetes.io/control-plane:NoSchedule]
[bootstrap-token] Using token: g0bo7g.l2bdtuli276oc7fw
[bootstrap-token] Configuring bootstrap tokens, cluster-info ConfigMap, RBAC Roles
[bootstrap-token] Configured RBAC rules to allow Node Bootstrap tokens to get nodes
[bootstrap-token] Configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials
[bootstrap-token] Configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token
[bootstrap-token] Configured RBAC rules to allow certificate rotation for all node client certificates in the cluster
[bootstrap-token] Creating the "cluster-info" ConfigMap in the "kube-public" namespace
[kubelet-finalize] Updating "/etc/kubernetes/kubelet.conf" to point to a rotatable kubelet client certificate and key
[addons] Applied essential addon: CoreDNS
[addons] Applied essential addon: kube-proxy

Your Kubernetes control-plane has initialized successfully!

To start using your cluster, you need to run the following as a regular user:

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

Alternatively, if you are the root user, you can run:

  export KUBECONFIG=/etc/kubernetes/admin.conf

You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
  https://kubernetes.io/docs/concepts/cluster-administration/addons/

Then you can join any number of worker nodes by running the following on each as root:

kubeadm join 192.168.79.130:6443 --token g0bo7g.l2bdtuli276oc7fw --discovery-token-ca-cert-hash sha256:312c9bd63e270090fc601806c3f3786acd89015dc7c89b606893e810c235d66d

初期化が完了したら、後でワーカーノードを Kubernetes クラスターに参加させるとき参照できるように kubeadm join コマンドをメモしておきます。

マスターノードで次のコマンドを実行します。

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

kubeadm で自動的に作成される /etc/kubernetes/admin.conf ファイルの内容を $HOME/.kube 配下に config というファイル名でコピーします。

sudo cat /etc/kubernetes/admin.conf
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURCVENDQWUyZ0F3SUJBZ0lJTm10Y3IyeXB0LzB3RFFZSktvWklodmNOQVFFTEJRQXdGVEVUTUJFR0ExVUUKQXhNS2EzVmlaWEp1WlhSbGN6QWVGdzB5TkRBM01EVXdOalUyTURsYUZ3MHpOREEzTURNd056QXhNRGxhTUJVeApFekFSQmdOVkJBTVRDbXQxWW1WeWJtVjBaWE13Z2dFaU1BMEdDU3FHU0liM0RRRUJBUVVBQTRJQkR3QXdnZ0VLCkFvSUJBUURKd2xkVExNbzJTdzZpV0NLaUdMTUpRa3orYUxVRDZqWE5uSDQwekdsZFdCcm5aNWRDOHV2YjVodGkKR1Y3NmxSa1NoQlF0QU9CN0M3N2pIMlcwZSszVzFsTDhLVzlHVStuckxURG9QZHczMUZ4VHE2MDVRUExCdExxYQo1WmFBWWo3NjIydkxqOXc3TDFTdzhyU0VyVjg1bWorZjVjMTc5NHpzZUdkUEZBMGFMMHpWc2F0TnJqekNReGlRCkVHdXN2VEtMVE1pMmc0amkwaXRVYk5tTnMzbFlTcWVad2VUV0tIRG1OSGJpWTFGbWNydkZHc2ExTjhrcnJQcjIKT2hONS90YzNrL25LdHoxY1RSYzNnOEprd3lMUXRxR0Z4QmlVa1BBMS85VUgyU3pXQXlsYlNJZWkydTNzNk83bwpEa0pyL2NNNHEyWmd3Ukk5TkF5dDlwUVFJeDJuQWdNQkFBR2pXVEJYTUE0R0ExVWREd0VCL3dRRUF3SUNwREFQCkJnTlZIUk1CQWY4RUJUQURBUUgvTUIwR0ExVWREZ1FXQkJRd21kdEY0QjYyUlFnT0FLT3prYXc5OTNVaXh6QVYKQmdOVkhSRUVEakFNZ2dwcmRXSmxjbTVsZEdWek1BMEdDU3FHU0liM0RRRUJDd1VBQTRJQkFRQmpUbElxOGIwRQpJNFFKWkZERERHdVhxbWIxOFFKK2x4eE5iYnBDbTF5VGJSWjVwTmJVdExNeHlIdC9kOTBJV2tlZTVjU3FEeXZvCjhoTGxsaW1QTDE5OUhoVXZYanl2NFZRanJRbExEcGJGUW9wN1ZubjVKbzBhYjBGNG9JY1kvb2dZbG9ZZ2FEcFkKQ0dEdmpBSjZSTjc2aUcwV052Lzl1bStIRFU2WFJjU1g2QkNESm1uaWdDYW5FZUFOM0loYkZNR0Voajc4dVpXSwpERFpYaDZGdmluRENpZHp6K0tvMXBBUUt1UFNOZU10NjQrNVhOSmR5TDdrZ0RheWU0enFUUzVqUVlwbDNMTFlvCjZiU2RjQnA4QlVON2c4UHlQMUZxMXpRYlAwMnE5U0Q4VjdMSTdDRFZNZGltWU44MDJITjNyZVpXVWI4Skd4aGYKN2lOUHYwNWJlTkVrCi0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K
    server: https://192.168.79.130:6443
  name: kubernetes
contexts:
- context:
    cluster: kubernetes
    user: kubernetes-admin
  name: kubernetes-admin@kubernetes
current-context: kubernetes-admin@kubernetes
kind: Config
preferences: {}
users:
- name: kubernetes-admin
  user:
    client-certificate-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURLVENDQWhHZ0F3SUJBZ0lJZFo3ckpoOStzKzB3RFFZSktvWklodmNOQVFFTEJRQXdGVEVUTUJFR0ExVUUKQXhNS2EzVmlaWEp1WlhSbGN6QWVGdzB5TkRBM01EVXdOalUyTURsYUZ3MHlOVEEzTURVd056QXhNVEZhTUR3eApIekFkQmdOVkJBb1RGbXQxWW1WaFpHMDZZMngxYzNSbGNpMWhaRzFwYm5NeEdUQVhCZ05WQkFNVEVHdDFZbVZ5CmJtVjBaWE10WVdSdGFXNHdnZ0VpTUEwR0NTcUdTSWIzRFFFQkFRVUFBNElCRHdBd2dnRUtBb0lCQVFDNlM2ZFUKUS9ZQjA5WDUxbjFSeWNBUHAwTVpvK2ZKbGUyOWtKYzU5R2NWcVBYdk9BM0tkYklNYndtai93U2Nwck5OQjczRgpuSE5CNTJaWFVBbXJLeGNHYlZsZiswY1BqcGFZRUFQVEJxejJaT1duMm1rdm9KSDFuZGtHSWpLSjM1UFNEd2tXCkpuS1NYaHRPcVRnY0JnRW4xQjFMNWNsbTIvcXdCU1JOWGpzd0VXQkI4R2lsYnFobDA3STc2REd4YXJKOS95Q2IKV3pSYU9aaU0xdnJCK2YrRmJSUWpjc0diZTQvU1lIRVRqRG5XVVVwZERISWxQM0Y3ZitVU28zQTJ5QkVZZ0FUYgpCRVRBajlhc1pOc3JaMFk2Y0o5Qm1NY1ZwRTZnTS9NOFBXcXYranNqTVA2ZCtwNUM3cVBCdHZ6WHRrZnh4RERSClB6bE0zb3huaXZDQzM2dnhBZ01CQUFHalZqQlVNQTRHQTFVZER3RUIvd1FFQXdJRm9EQVRCZ05WSFNVRUREQUsKQmdnckJnRUZCUWNEQWpBTUJnTlZIUk1CQWY4RUFqQUFNQjhHQTFVZEl3UVlNQmFBRkRDWjIwWGdIclpGQ0E0QQpvN09SckQzM2RTTEhNQTBHQ1NxR1NJYjNEUUVCQ3dVQUE0SUJBUUJVUkIvaG9TYlYyQmdZdFE2Q29pMzVDMW5FCk5QeFl2NTJ6cjh0Q1h0NnBHQUJYbUJHZjNNR2xwU2RXV2ZyZEluVCt5dXEzQkx3aUNOM29aQ1hpL2kyTStKZWYKS3hPR1VyaG93WjJScnFtS1NCaklYL0t4NFYrakFLOGtUaFdzaHhLZzNCTGNWNEdXMzdqRG9DWUY2QlVYQWRXaQpsOU5aQVhRRFhEaUxYUFoxOEliVTFPT1E2YXNNZ1VJQTNLcE1ydlpIZjYyOEZWR3UvdTJqOTBXekQ2OWRMU2RFClpJZWEwTk1CbHRmRkQvNTZYOVoyMWFxMW00Mm1Kc09CY0l5TjUyOUtPa0p0bGttU0x6c3hSejBtWGluOEwrUVYKU3ZDZVczTEpUY09zdnFNa1JTamlya2twZ2k4ZE03ci9aUTgwSFBzQTBMZi91STY2eUZxZFdLa0NSSWVZCi0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K
    client-key-data: LS0tLS1CRUdJTiBSU0EgUFJJVkFURSBLRVktLS0tLQpNSUlFb3dJQkFBS0NBUUVBdWt1blZFUDJBZFBWK2RaOVVjbkFENmRER2FQbnlaWHR2WkNYT2ZSbkZhajE3emdOCnluV3lERzhKby84RW5LYXpUUWU5eFp4elFlZG1WMUFKcXlzWEJtMVpYL3RIRDQ2V21CQUQwd2FzOW1UbHA5cHAKTDZDUjlaM1pCaUl5aWQrVDBnOEpGaVp5a2w0YlRxazRIQVlCSjlRZFMrWEpadHY2c0FVa1RWNDdNQkZnUWZCbwpwVzZvWmRPeU8rZ3hzV3F5ZmY4Z20xczBXam1Zak5iNndmbi9oVzBVSTNMQm0zdVAwbUJ4RTR3NTFsRktYUXh5CkpUOXhlMy9sRXFOd05zZ1JHSUFFMndSRXdJL1dyR1RiSzJkR09uQ2ZRWmpIRmFST29EUHpQRDFxci9vN0l6RCsKbmZxZVF1Nmp3YmI4MTdaSDhjUXcwVDg1VE42TVo0cndndCtyOFFJREFRQUJBb0lCQUdDNXBRQm9aTk5nRkdvcQpobGl2d291ZUVZVy9oem93SVFiYWl0b3BYbGh0cUh0ekJCNEphODl1MjNlTmtleHYxUXA2cVhwdmw1d3hNLzdECmJMRzFwcmZNa0tuNEFsWStkMHd1akgzRnFvb25xdUd5MGdoTGUxMG1mcWJqbkkvZlNKVzQvc1BFWkpwQVNEZFkKUHV5MTVXV3ppUjUrQ1VyaGpsQlQ2eHhNZjdpZGVVbXVnd1ZKN2dOSktHQk56L1Z4c3liYjdBa2w0MmZ0VEtkbAoxK2l4YzFueUdPU25PYVM2Z3E3akJYRzNkYWdQWnRpS1dKS1EyU0pzUXJPejhRNWlPR2tveGxsRWt5QmZWMGhvClN5b00rYVJxWGdjbnBsNHZOaStzWFhkb2tmaVN0eVBOT0ZuQTFNUSt4emNMVXhuQm4vVzhnYTVFT1diODVwMjUKKzEwN2NGRUNnWUVBN3NyMGwrRVNIM1lpK09BNUhOS0o1L2VNYUhNUjYyaTBTS0d5dmd2RHNkdjMvNFhGeWJEawpXakJtVU5TSVR6MFRBU0VOREFYNGRCQWs5MHhnQnNya0hYU20vOFEyVmtnanRhUWYrRW9DbFJpRkU4c1BRS1drCkZsNE1CYkcrL0NHNVk1bnNaTWI0ckJ3N0JNUVRXdzRZemtIMndHUFJBekJxa1QyazhUclRINTBDZ1lFQXg3aEcKQjJkYmEwNnYveS90R2s3aHoxQTcwbGFobDBPSk5IZkFOK0N2em5tcVE5SGhRUXRtTXVCTHdMVS9NTlZnc1FOYQpMUVVialVYZ3d5V2VPTFJxRHZ3Z1dJUWl0YzNrZzU4T2w4T0wrMHVzMDNrejh4dDJrWE1iV1AvOHM4N09ob1VhCjFHVWR6dzNEenRzeFhXdmwwcVlPWHUzOTRhVFgyYVpKVkJXQ0QyVUNnWUE2RE9UQk4xbnNoQStrYVAzNVg4VmUKdXZOTFFRNE9LSG9MWGlQUng1SmZYcFkvYkFuVktrZVpGVU1LUzJDSHd0VW41UjBDMjBDM0ZtV21LTTcvVjd0MAozYkxyWW92REZlNTRiZG5IeGxZeVlLK1pURGY5QTBlTW1IaGJ1Z1l2elJNQWY1N1VNUHFxL0lIc2VxNHA2SmRuCkxPb0xnemlBaWZpZUxsbzJ1cEl3a1FLQmdCd3BUcTZTazJCeEt2M25xeDR2aTBXcFFaWXFJd1RxUC9tRy9US2oKMndaWlAzbnFxVUY3c3dCdmdoNzlMNWphTFpVb0xObjJRMmxMTmlNdU5iNDNLbEZNbWQ4QldzZVo3YVBsbExBdgpvWmhnbGxFSFlSemhmWG1LNm90RkpVUFJZR3UxYnhBTjVnTWhKTUFSUmtldkJDd013REFBalBENVJucHBLU1BUCkdKREZBb0dCQU5zUjVzZFFqZ2hyMHNjczdZckQ5OW9xUWpyNWdJbmEvYlJta0NEaHNvbFQzYnNhVWk3dkZWUmIKRmN1NGhVT2pndEs2UmJwSDVYOWxOQUVzVlR2ZXhrU0hIQm1Gd1pPSGwzK0JDMDlhbVk3VU5rSHd0SEVob1B0WgpvV1JoK1VYbDAxNHRqSDFCVFljNi9XWitQMFcwZEFVVFUvNEMvUEgrUlhVQm9XajBmSkg1Ci0tLS0tRU5EIFJTQSBQUklWQVRFIEtFWS0tLS0tCg==

/etc/kubernetes/admin.conf ファイルは、Kubernetesクラスターの管理者がクラスターを操作するために使用する設定ファイルです。このファイルには以下のような情報が含まれています。

クラスター情報
クラスターのAPIサーバーのエンドポイントや、クラスターの証明書情報などが含まれます。
認証情報
クラスターにアクセスするためのユーザー名やパスワード、または証明書ベースの認証情報が含まれます。
コンテキスト
現在アクティブなコンテキスト（クラスター、ユーザー、名前空間の組み合わせ）が含まれます。
このファイルは、kubectl コマンドラインツールがクラスターに接続するための必要な情報を提供します。

次に、kubectlコマンドを使用してクラスターとノードのステータスを確認します。

kubectl get nodes
NAME           STATUS      ROLES           AGE     VERSION
k8s-master     NotReady    control-plane   3m11s   v1.30.2

3.8. クラスターにワーカーノードを追加 (ワーカーノード)

マスターノードで実行した kubeadm init 時にターミナルに表示された kubeadm join の部分（メモしておいたコマンド）をワーカーノードで実行します。

sudo kubeadm join 192.168.79.130:6443 --token g0bo7g.l2bdtuli276oc7fw --discovery-token-ca-cert-hash sha256:312c9bd63e270090fc601806c3f3786acd89015dc7c89b606893e810c235d66d

kubeadm によって生成されたトークンの有効期限は 24時間 (1日) ですトークンが無効になってしまったら以下の方法で再作成してください。
token 再作成の方法

kubeadm token create
7e08sj.mo352ypnk5e9339n

また、discovery-token-ca-cert-hash の値を忘れてしまったら以下の方法で調べてください。
discovery-token-ca-cert-hashの調べ方

openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | openssl rsa -pubin -outform der 2>/dev/null | openssl dgst -sha256 -hex | sed 's/^.* //'
312c9bd63e270090fc601806c3f3786acd89015dc7c89b606893e810c235d66d

この出力（312c9bd63e... ）の先頭に "sha256:" を付けるのを忘れないよう注意してください。

3.9. Kubernetes コンテナ― ネットワークプラグインをインストール (マスターノード)

クラスター内のポッド間の通信を有効にするには、コンテナ― ネットワークプラグインが必要です。マスターノードから次のコマンドを使用して、Calico ネットワークプラグインをインストールします。

kubectl apply -f https://raw.githubusercontent.com/projectcalico/calico/v3.25.0/manifests/calico.yaml

Flannel を使用する場合は、初期化（kubeadm init）時に
kubeadm init --pod-network-cidr=10.244.0.0/16　のように
--pod-network-cidr が必要になるので注意してください。

3.10. クラスターの検証とテスト (マスターノード)

最後に、クラスターが正常に作成されたかどうかを確認します。

kubectl get nodes
NAME           STATUS   ROLES           AGE  VERSION
k8s-master     Ready    control-plane   3h   v1.30.2
k8s-worker-1   Ready    <none>          3h   v1.30.2
k8s-worker-2   Ready    <none>          3h   v1.30.2

kubectl get pods -n kube-system
NAME                                         READY   STATUS    RESTARTS       AGE
calico-kube-controllers-5b9b456c66-qhsvj     1/1     Running   0              3h
calico-node-4bz6f                            1/1     Running   0              3h
calico-node-5dw9n                            1/1     Running   0              3h
calico-node-z95hl                            1/1     Running   0              3h
coredns-7db6d8ff4d-75xgp                     1/1     Running   0              3h
coredns-7db6d8ff4d-n6szh                     1/1     Running   0              3h
etcd-k8s-master                              1/1     Running   0              3h
kube-apiserver-k8s-master                    1/1     Running   0              3h
kube-controller-manager-k8s-master           1/1     Running   0              3h
kube-proxy-442rm                             1/1     Running   0              3h
kube-proxy-m6sm5                             1/1     Running   0              3h
kube-proxy-p24ng                             1/1     Running   0              3h
kube-scheduler-k8s-master                    1/1     Running   0              3h

3.11. マスターノードでテストアプリケーション（nginx）を実行

kubectl run nginx --image=nginx
kubectl get pods
NAME                         READY   STATUS    RESTARTS   AGE
nginx                        1/1     Running   0          21s

ポッドの STATUS が Running になっていれば OK です。

4. おわりに

Kubernetes クラスター構築に関する記事や投稿は多々ありますが、一般的にコマンドの羅列が多く、その意味を含めて説明してくれるているものは多くありませんでした。そこでステップバイステップでコマンドを実行しながら、そのコマンドの意味が理解できるように説明を加えたガイドを作成してみました。
間違いや分かり難い点がありましたら、ぜひフィードバックしてください。

参考文献

kubeadmを使ってクラスターを構築する
 整理しながら理解するKubernetesネットワークの仕組み / Kubernetes Network Fundamentals
k8sにおけるトラブルシューティング実例2: br_netfilterの有効化