本ブログでは、数回に分けてKubernetesの構築手順を記載してきた。
今まではコントロールプレーンをシングル構成にて構築していたが、コントロールプレーン停止時にコンテナ間の通信ができなくなり、影響が発生するという問題がある。
そこで、本記事では、Kubernetesの管理機能であるコントールプレーンを冗長構成にて構築する手順を記載する。
環境
以下に今回構築する各種ソフトウェアのバージョンを記載する。
- ホストOS : AlmaLinux 8.6
- Docker : 23.0.1
- cri-dockerd: 0.3.1-dev
- Kubernetes: v1.27.1
なお、私の環境ではインターネット接続時にプロキシ接続が必要となるため、プロキシ経由で接続するための設定も併せて行っている。
今回の構成の概要図を以下に記載する。負荷分散装置にてkube-apiserverへのアクセスを冗長化する点が、大きな差異となる。
NGINXによる負荷分散装置作成
負荷分散装置は何を用いてもよいが、NGINXにて簡単に作成できる。NGINXを用いた負荷分散装置の構成手順は以下を参照いただきたい。
NGINXでロードバランサを設定する際に、 /etc/nginx/stream.conf.d/servers.stream.confという設定ファイルを作成する。kube-apiserverは待ち受けポートとなる6443となることから、負荷分散設定としては以下のとおり設定すればよい。
# kube-apiserver
upstream kube-apiserver {
least_conn;
server 192.168.3.51:6443;
server 192.168.3.52:6443;
server 192.168.3.53:6443;
}
server {
listen 192.168.3.43:6443;
proxy_pass kube-apiserver;
}
Dockerインストール
今回はcri-dockerdを使ってKubernetes環境を構築する。本手順については、過去記事の手順を参照いただきたい。
Kubernetesインストール
こちらも手順については、過去記事の手順を参照いただきたい。
kubeadmコマンドを用いてKubernetesクラスター作成
1. kubeadmコマンド実行
kubeadmコマンドを用いて、Kubernetesクラスターの作成を行う。クラスターの作成はkubeadm initコマンドにて実施する。「Your Kubernetes control-plane has initialized successfully!」が表示されれば成功となる。
コントロールプレーンを冗長化する場合は、--control-plane-endpointと--upload-certsのオプションが追加となる。オプションの説明を以下に記載する。
| オプション |
説明 |
--pod-network-cidr=10.244.0.0/16 |
ネットワークアドオンとしてflannelを追加する際に必要となる設定となる。Pod用のクラスターネットワークのネットワークアドレスを指定する。 |
--cri-socket=unix:///var/run/cri-dockerd.sock |
CRIとしてcri-dockerdを使うことを明示的に指定するために指定する。指定しない場合、containerdとcri-dockerdの2つがインストールされていることにより、「Found multiple CRI endpoints on the host」のエラーにてクラスターの作成に失敗するので注意しよう。 |
--control-plane-endpoint |
コントロールプレーンへアクセスするためのKubernetes APIのDNS名やIPアドレスを指定する。すべてのコントロールプレーンで共通のアクセス先を指定する必要があることから、kube-apiserverへ振り分けを行う負荷分散装置のDNS名やIPアドレスを指定する。 |
--upload-certs |
新たにコントロールプレーンが参加する際に、自動的に必要な証明書の登録を行うための設定。本オプションを省略した場合、手動による証明書のコピーが必要となる。 |
以下に実行結果を記載する。
# kubeadm init --pod-network-cidr=10.244.0.0/16 --cri-socket=unix:///var/run/cri-dockerd.sock \
> --control-plane-endpoint "t3043kube.test.local:6443" --upload-certs
[init] Using Kubernetes version: v1.27.2
[preflight] Running pre-flight checks
[preflight] Pulling images required for setting up a Kubernetes cluster
～(中略)～
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/
You can now join any number of the control-plane node running the following command on each as root:
kubeadm join t3043kube.test.local:6443 --token jf1wss.euqu6slbvc1c4kry \
--discovery-token-ca-cert-hash sha256:abcdefgh5a4463ce8dc2761a89187036b1719abbb7a907aed96650ca8162d3d9 \
--control-plane --certificate-key abcdefgh89a9c0d36e026014d9c9885119cd8c336e45420be92578832456a85a
Please note that the certificate-key gives access to cluster sensitive data, keep it secret!
As a safeguard, uploaded-certs will be deleted in two hours; If necessary, you can use
"kubeadm init phase upload-certs --upload-certs" to reload certs afterward.
Then you can join any number of worker nodes by running the following on each as root:
kubeadm join t3043kube.test.local:6443 --token jf1wss.euqu6slbvc1c4kry \
--discovery-token-ca-cert-hash sha256:abcdefgh5a4463ce8dc2761a89187036b1719abbb7a907aed96650ca8162d3d9
2. Kubernetesクラスター状態確認
Kubernetesの管理はkubectlコマンドを使って実施するが、そのままでは使用できない。以下の通り設定ファイルをコピーすることでkubectlによるコマンドが使えるようになる。
# mkdir -p $HOME/.kube
# sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
# sudo chown $(id -u):$(id -g) $HOME/.kube/config
それでは、kubectlコマンドを使って、ノードとPodの状態を確認してみよう。以下の通り、各種コントロールプレーン用のPodと1台のノードが表示される。
# kubectl get node
NAME STATUS ROLES AGE VERSION
t3051kube NotReady control-plane 83s v1.27.1
# kubectl get pod -A
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-flannel kube-flannel-ds-zjw8w 1/1 Running 0 42s
kube-system coredns-5d78c9869d-2lcjq 1/1 Running 0 6m55s
kube-system coredns-5d78c9869d-fqbw9 1/1 Running 0 6m55s
kube-system etcd-t3053kube 1/1 Running 0 7m4s
kube-system kube-apiserver-t3053kube 1/1 Running 0 7m4s
kube-system kube-controller-manager-t3053kube 1/1 Running 0 7m4s
kube-system kube-proxy-nhl5c 1/1 Running 0 6m55s
kube-system kube-scheduler-t3053kube 1/1 Running 0 7m4s
上記を見ると、corednsがPendingのステータスとなっており、NodeのステータスもNotReadyとなっている。これはPod用のネットワークアドオンがインストールされていないために発生しており、後続の手順にてflannelをインストールするとステータスがRunningになるため、現時点では気にしなくて問題ない。
ネットワークアドオンインストール (flannelインストール)
こちらも手順については、過去記事の手順を参照いただきたい。
flannelインストールが完了すると、ノードのステータスがReadyに変化する。
# kubectl get node
NAME STATUS ROLES AGE VERSION
t3053kube Ready control-plane 7m16s v1.27.1
# kubectl get pod -A
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-flannel kube-flannel-ds-zjw8w 1/1 Running 0 42s
kube-system coredns-5d78c9869d-2lcjq 1/1 Running 0 6m55s
kube-system coredns-5d78c9869d-fqbw9 1/1 Running 0 6m55s
kube-system etcd-t3053kube 1/1 Running 0 7m4s
kube-system kube-apiserver-t3053kube 1/1 Running 0 7m4s
kube-system kube-controller-manager-t3053kube 1/1 Running 0 7m4s
kube-system kube-proxy-nhl5c 1/1 Running 0 6m55s
kube-system kube-scheduler-t3053kube 1/1 Running 0 7m4s
2台目のコントロールプレーンの追加
1. kubeadm joinコマンドにてコントロールプレーンを追加
CRIとしてcri-dockerdを用いる場合は、--cri-socketのオプション追加が必要となるため注意すること。
# kubeadm join t3043kube.test.local:6443 --token jf1wss.euqu6slbvc1c4kry \
--discovery-token-ca-cert-hash sha256:abcdefgh5a4463ce8dc2761a89187036b1719abbb7a907aed96650ca8162d3d9 \
--control-plane --certificate-key abcdefgh89a9c0d36e026014d9c9885119cd8c336e45420be92578832456a85a \
--cri-socket=unix:///var/run/cri-dockerd.sock
# kubeadm join t3043kube.test.local:6443 --token jf1wss.euqu6slbvc1c4kry \
--discovery-token-ca-cert-hash sha256:abcdefgh5a4463ce8dc2761a89187036b1719abbb7a907aed96650ca8162d3d9 \
--cri-socket=unix:///var/run/cri-dockerd.sock
2. Kubernetesクラスター状態確認
1台目のコントロールプレーンと同様、以下の通り設定ファイルをコピーすることで、2台目のコントロールプレーンにおいてもkubectlによるコマンドが使えるようになる
# mkdir -p $HOME/.kube
# sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
# sudo chown $(id -u):$(id -g) $HOME/.kube/config
ノードとPodの状態を確認すると、ノードのROLESがcontorol-planeとなっており、各ノードにて、etcd、kube-apiserver、kube-controller-manager、kube-schedulerが起動していることが確認できる(kube-proxyはワーカーノードにおいても起動する)。
# kubectl get node
NAME STATUS ROLES AGE VERSION
t3052kube Ready control-plane 47s v1.27.1
t3053kube Ready control-plane 15m v1.27.1
# kubectl get pod -A
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-flannel kube-flannel-ds-xtq5b 1/1 Running 0 59s
kube-flannel kube-flannel-ds-zjw8w 1/1 Running 0 9m27s
kube-system coredns-5d78c9869d-2lcjq 1/1 Running 0 15m
kube-system coredns-5d78c9869d-fqbw9 1/1 Running 0 15m
kube-system etcd-t3052kube 1/1 Running 0 58s
kube-system etcd-t3053kube 1/1 Running 0 15m
kube-system kube-apiserver-t3052kube 1/1 Running 0 59s
kube-system kube-apiserver-t3053kube 1/1 Running 0 15m
kube-system kube-controller-manager-t3052kube 1/1 Running 0 59s
kube-system kube-controller-manager-t3053kube 1/1 Running 1 (48s ago) 15m
kube-system kube-proxy-nhl5c 1/1 Running 0 15m
kube-system kube-proxy-zq88d 1/1 Running 0 59s
kube-system kube-scheduler-t3052kube 1/1 Running 0 59s
kube-system kube-scheduler-t3053kube 1/1 Running 1 (44s ago) 15m
参考：コントロールプレーンにおいても管理用Pod「以外」を起動させる設定 (taintの解除)
初期設定時は、コントロールプレーンにおいては管理用Podのみ起動できる設定が入っている。これは「taint (汚れ、汚染という意味)」と呼ばれる設定において制御されている。
検証用途などにおいては、コントロールプレーンにおいても管理用Pod「以外」を起動したい場合は、以下コマンドでtaintを解除する。
※今回は説明しないが、Pod側の設定で「toleration (耐える、黙認という意味)」という対となる設定をすることでも対処できる。
# kubectl taint node t3051kube node-role.kubernetes.io/control-plane:NoSchedule-
# kubectl taint node t3052kube node-role.kubernetes.io/control-plane:NoSchedule-
taintの設定を戻す場合は、以下の通り行う(解除コマンドの最後の-を取る)。
# kubectl taint node t3051kube node-role.kubernetes.io/control-plane:NoSchedule
# kubectl taint node t3052kube node-role.kubernetes.io/control-plane:NoSchedule
以上で、Kubernetesの管理機能であるコントールプレーンを冗長構成にて構築する手順は完了となる。
