2023年6月10日土曜日

Kubernetes構築手順④ (コントロールプレーンを冗長構成にする)

本ブログでは、数回に分けて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 件のコメント:

コメントを投稿

人気の投稿