本ブログでは、数回に分けて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.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の管理機能であるコントールプレーンを冗長構成にて構築する手順は完了となる。

 
 
 
 
0 件のコメント:
コメントを投稿