2023年3月18日土曜日

Kubernetes構築手順② (ワーカーノードを追加)

前回、Kubernetesのコントロールプレーンを構築する手順を記載した。

本記事では、作成したKubernetesクラスターにワーカーノードを追加する手順を記載する。

環境

以下に今回構築する各種ソフトウェアのバージョンを記載する。

  • ホストOS : AlmaLinux 8.6
  • Docker : 23.0.1
  • cri-dockerd: 0.3.1-dev
  • Kubernetes: v1.26.2

今回の構成の概要図を以下に記載する。

ワーカーノードの構築

ワーカーノードの構築は、kubeadmコマンドを実行する直前までは、コントロールプレーンと同様の作業が必要となる。前回記事を参考にあらかじめ以下作業を実施しておこう。

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-dskube-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 件のコメント:

コメントを投稿

人気の投稿