前回、Kubernetesのコントロールプレーンを構築する手順を記載した。
- Kubernetes構築手順① (cri-dockerdを使ってコントロールプレーンを構築)
- Kubernetes構築手順② (ワーカーノードを追加) ★本記事
- Kubernetes構築手順③ (マニフェストファイルを使ってDockerコンテナをデプロイ)
- Kubernetes構築手順④ (コントロールプレーンを冗長構成にする)
本記事では、作成したKubernetesクラスターにワーカーノードを追加する手順を記載する。
環境
以下に今回構築する各種ソフトウェアのバージョンを記載する。
- ホストOS : AlmaLinux 8.6
- Docker : 23.0.1
- cri-dockerd: 0.3.1-dev
- Kubernetes: v1.26.2
今回の構成の概要図を以下に記載する。
ワーカーノードの構築
ワーカーノードの構築は、kubeadm
コマンドを実行する直前までは、コントロールプレーンと同様の作業が必要となる。前回記事を参考にあらかじめ以下作業を実施しておこう。
- Kubernetes構築手順① (cri-dockerdを使ってコントロールプレーンを構築)
- Dockerインストール
- Kubernetesインストール
- cri-dockerdインストール
Kubernetesクラスターへ参加
1. Tokenを確認
ワーカーノードをKubernetesクラスターへの参加させるため、kubeadm join
コマンドを実行する必要があるが、この際にコントロールプレーンが持つTokenの情報が必要となる。Tokenは、Kubernetesクラスターを作成した際に表示されるものとなる。
# kubeadm init --pod-network-cidr=10.244.0.0/16 --cri-socket=unix:///var/run/cri-dockerd.sock
[init] Using Kubernetes version: v1.26.2
~(中略)~
Then you can join any number of worker nodes by running the following on each as root:
kubeadm join 192.168.11.51:6443 --token bexxee.xx866gxx91sxxa69 \
--discovery-token-ca-cert-hash sha256:06d8e3077c71a3f7af2xx8d6b389d43673xx9a8axxa5d003ed8dccb356a42f80
もし、クラスター作成時の情報が不明だったり、Tokenの有効期限が切れた場合は、以下コマンドを実行することでTokenを作成し表示させることができる。
# kubeadm token create --print-join-command
kubeadm join 192.168.11.51:6443 --token berssm.biqyhxls0jsdxxxx --discovery-token-ca-cert-hash sha256:c65f49b8ad89d2a2ee1790695a4d7fd0d5583e7f8a7e3a900e04cf5c2356xxxx
# kubeadm token list
TOKEN TTL EXPIRES USAGES DESCRIPTION EXTRA GROUPS
3b4zsz.26fm7d17lb1jxxxx 3h 2023-03-04T23:54:16Z authentication,signing The default bootstrap token generated by 'kubeadm init'. system:bootstrappers:kubeadm:default-node-token
berssm.biqyhxls0jsdxxxx 23h 2023-03-05T20:46:09Z authentication,signing <none> system:bootstrappers:kubeadm:default-node-token
[root@t1051kube ~]#
2. kubeadmコマンド実行
それではワーカーノードとしてKubernetesクラスターに参加させてみよう。
今回はCRIにcri-dockerdを用いるため、確認したTokenのコマンドに、--cri-socket=unix:///var/run/cri-dockerd.sock
のオプションを追加し、kubeadm join
コマンドを実行する。
※なお、本作業はインターネット接続できない状態であっても、特にプロキシ設定などは行わずに実施できる。
# kubeadm join 192.168.11.51:6443 --token berssm.biqyhxls0jsdxxxx \
--discovery-token-ca-cert-hash sha256:c65f49b8ad89d2a2ee1790695a4d7fd0d5583e7f8a7e3a900e04cf5c2356xxxx \
--cri-socket=unix:///var/run/cri-dockerd.sock
[preflight] Running pre-flight checks
[preflight] Reading configuration from the cluster...
[preflight] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -o yaml'
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet-start] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[kubelet-start] Starting the kubelet
[kubelet-start] Waiting for the kubelet to perform the TLS Bootstrap...
This node has joined the cluster:
* Certificate signing request was sent to apiserver and a response was received.
* The Kubelet was informed of the new secure connection details.
Run 'kubectl get nodes' on the control-plane to see this node join the cluster.
3. Kubernetesクラスター状態確認
Kubernetesの管理はkubectl
コマンドを使って実施するが、そのままでは使用できないので、環境変数で設定ファイルのパスを指定しておく。
# export KUBECONFIG=/etc/kubernetes/kubelet.conf
それでは、kubectl
コマンドを使って、PodとNodeの状態を確認してみよう。以下の通り、kube-flannel-ds
とkube-proxy
のPodが各Nodeで起動しており、参加したワーカーノードはReadyとなっていれば成功となる。
# kubectl get pod -A -o=wide
NAMESPACE NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
kube-flannel kube-flannel-ds-8s4cq 1/1 Running 0 21h 192.168.11.51 t1051kube <none> <none>
kube-flannel kube-flannel-ds-sfkg7 1/1 Running 0 4m40s 192.168.11.52 t1052kube <none> <none>
kube-system coredns-787d4945fb-cf2sf 1/1 Running 0 21h 10.244.0.2 t1051kube <none> <none>
kube-system coredns-787d4945fb-wkp86 1/1 Running 0 21h 10.244.0.3 t1051kube <none> <none>
kube-system etcd-t1051kube 1/1 Running 0 21h 192.168.11.51 t1051kube <none> <none>
kube-system kube-apiserver-t1051kube 1/1 Running 0 21h 192.168.11.51 t1051kube <none> <none>
kube-system kube-controller-manager-t1051kube 1/1 Running 0 21h 192.168.11.51 t1051kube <none> <none>
kube-system kube-proxy-lscpc 1/1 Running 0 21h 192.168.11.51 t1051kube <none> <none>
kube-system kube-proxy-vz4v8 1/1 Running 0 4m40s 192.168.11.52 t1052kube <none> <none>
kube-system kube-scheduler-t1051kube 1/1 Running 0 21h 192.168.11.51 t1051kube <none> <none>
# kubectl get node
NAME STATUS ROLES AGE VERSION
t1051kube Ready control-plane 21h v1.26.2
t1052kube Ready <none> 4m43s v1.26.2
最終的に1台のコントロールプレーンと2台のワーカーノードを追加いした場合は、以下のような状態となる。
# kubectl get pod -A -o=wide
NAMESPACE NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
kube-flannel kube-flannel-ds-8s4cq 1/1 Running 0 21h 192.168.11.51 t1051kube <none> <none>
kube-flannel kube-flannel-ds-mrpsm 1/1 Running 0 3m13s 192.168.11.53 t1053kube <none> <none>
kube-flannel kube-flannel-ds-sfkg7 1/1 Running 0 11m 192.168.11.52 t1052kube <none> <none>
kube-system coredns-787d4945fb-cf2sf 1/1 Running 0 21h 10.244.0.2 t1051kube <none> <none>
kube-system coredns-787d4945fb-wkp86 1/1 Running 0 21h 10.244.0.3 t1051kube <none> <none>
kube-system etcd-t1051kube 1/1 Running 0 21h 192.168.11.51 t1051kube <none> <none>
kube-system kube-apiserver-t1051kube 1/1 Running 0 21h 192.168.11.51 t1051kube <none> <none>
kube-system kube-controller-manager-t1051kube 1/1 Running 0 21h 192.168.11.51 t1051kube <none> <none>
kube-system kube-proxy-jfg8b 1/1 Running 0 3m13s 192.168.11.53 t1053kube <none> <none>
kube-system kube-proxy-lscpc 1/1 Running 0 21h 192.168.11.51 t1051kube <none> <none>
kube-system kube-proxy-vz4v8 1/1 Running 0 11m 192.168.11.52 t1052kube <none> <none>
kube-system kube-scheduler-t1051kube 1/1 Running 0 21h 192.168.11.51 t1051kube <none> <none>
# kubectl get node
NAME STATUS ROLES AGE VERSION
t1051kube Ready control-plane 21h v1.26.2
t1052kube Ready <none> 11m v1.26.2
t1053kube Ready <none> 3m18s v1.26.2
参考:コントロールプレーンにおいても管理用Pod「以外」を起動させる設定 (taintの解除)
初期設定時は、コントロールプレーンにおいては管理用Podのみ起動できる設定が入っている。これは「taint (汚れ、汚染という意味)」と呼ばれる設定において制御されている。
検証用途などにおいては、コントロールプレーンにおいても管理用Pod「以外」を起動したい場合は、以下コマンドでtaintを解除する。
※今回は説明しないが、Pod側の設定で「toleration (耐える、黙認という意味)」という対となる設定をすることでも対処できる。
# kubectl describe node t1051kube | grep Taints
Taints: node-role.kubernetes.io/control-plane:NoSchedule
# kubectl taint node t1051kube node-role.kubernetes.io/control-plane:NoSchedule-
node/t1051kube untainted
# kubectl describe node t1051kube | grep Taints
Taints: <none>
もし、taintの設定を戻したい場合は以下コマンドを実行する。
# kubectl taint node t1051kube node-role.kubernetes.io/control-plane:NoSchedule
node/t1051kube tainted
以上で、Kubernetesクラスターにワーカーノードを追加する手順は完了となる。次回は、本環境に実際にDockerコンテナをPodとしてデプロイし、外部からアクセスできることを確認する。
0 件のコメント:
コメントを投稿