[構築] Rock5B + Armbian(noble) で作るkubernetesクラスタ (5)

前記事からの続き。

前回はAnsibleでノードを一括セットアップしたところで終わっていたので、いよいよkubernetesクラスタの構築に入る。


マスターノードの構築

基本的には公式のマニュアルに従う形で進む。

ただし環境によってオプションとして与えるものが結構ある。今回は以下のようなコマンドでマスターノードを初期化した。

kubeadm init --upload-certs --pod-network-cidr=172.16.0.0/16 --control-plane-endpoint="kube-cp.offline.to" --skip-phases=addon/kube-proxy --feature-gates="PublicKeysECDSA=true" --v=5

マスターノードを増やしたくなった時のために一応 --upload-certs と --control-plane-endpoint を指定しておく。control-plane-endpointとして指定している kube-cp.offline.to というのはNGINXで作ったリバースプロキシ。control-planeを増やす想定がない人はマスターノードのIPアドレスを直接指定しちゃってもいいと思う。たぶん。

NGINXでは以下のような設定で kube-cp.offline.to へのアクセスをマスターノードに渡しているだけ。192.168.2.249はNGINXが動いているノードのIPアドレス。

upstream kube_cp {
  zone kube_cp 64k;
  server 192.168.2.240:6443;
}

server {
  listen 192.168.2.249:6443;
  proxy_pass kube_cp;
}

あとは適当にpodが使うネットワークを172.16.0.0/16としたり、kube-proxyを使うつもりはないのでskipしたりしている。kubeadm initを実行し成功すると最終的に以下のような出力が得られるはず。

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 kube-cp.offline.to:6443 --token vpdcbw.pxkbg7q80c9a2ajo \
        --discovery-token-ca-cert-hash sha256:126d80a8942ca3f2b674261fdb36895f4bba770fc307e221b66af7cfbb3da98e \
        --control-plane --certificate-key a76645b67f7c8c630eb19b09f1568271401d9c2eee0ab2bbdbfcd4235ed4bf69

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 kube-cp.offline.to:6443 --token vpdcbw.pxkbg7q80c9a2ajo \
        --discovery-token-ca-cert-hash sha256:126d80a8942ca3f2b674261fdb36895f4bba770fc307e221b66af7cfbb3da98e

ここで出力される内容は後で必要になるのでコピペしてどこかに保存していくこと。実際にコマンドを実行している動画を置いておく。

kubectlはopsユーザで実行できるようにしておきたいので、出力にある通り以下のコマンドを実行しておく。

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

最後にちゃんと動いているか確認のためnamespaceとpodを表示してみる。

kubectl get ns
kubectl get pod

いずれもエラーなく実行できればたぶん構築に成功しているはず。

ワーカーノードの構築

構築と言ってもやる事はさっき出力された内容をペーストして実行するだけ。なんだけど、5台あると面倒なのでansibleで各ノードに放り込むことにする。ansibleはマスターノードではなくarmbianをビルドしたホストから実行していることに注意。

ansible -bK -i inventories/ nodes -m shell -a 'kubeadm join kube-cp.offline.to:6443 --token vpdcbw.pxkbg7q80c9a2ajo --discovery-token-ca-cert-hash sha256:126d80a8942ca3f2b674261fdb36895f4bba770fc307e221b66af7cfbb3da98e'

ワーカーノードを対象にshellモジュールでコマンドを放り込むだけ。ただし実行はrootで行う必要があるためbecomeモードかつbecomeモードで使うパスワードが必要なため -bK というオプションになる。

Then you can join any number of worker nodes by running the following on each as root:

マスターノードのkubeadm init出力より

マスターノードの構築時、最後に得られるメッセージに上のようなメッセージとともにコマンドがあるはずなので、その内容をコピペして実行する。実際の様子を動画として置いておく。

ワーカーノードでのkubeadmコマンド実行が成功していれば以下のコマンドでm240,n230-n234までのノードが表示されるはず。ansibleはビルド用ホストから実行したけど、確認用のkubectlはマスターノードから実行しているので注意。

kubectl get nodes
NAME              STATUS      ROLES           AGE   VERSION
m240.offline.to   NotReady    control-plane   60m   v1.30.2
n230.offline.to   NotReady    <none>          22s   v1.30.2
n231.offline.to   NotReady    <none>          22s   v1.30.2
n232.offline.to   NotReady    <none>          22s   v1.30.2
n233.offline.to   NotReady    <none>          22s   v1.30.2
n234.offline.to   NotReady    <none>          22s   v1.30.2

最後にワーカーノードたちにラベルをつけておく。

for i in $(seq 0 4);do kubectl label node n23${i}.offline.to node-role.kubernetes.io/worker=worker; done

確認のため再度ノード一覧を表示してみる。

kubectl get nodes 
NAME              STATUS      ROLES           AGE   VERSION
m240.offline.to   NotReady    control-plane   61m   v1.30.2
n230.offline.to   NotReady    worker          90s   v1.30.2
n231.offline.to   NotReady    worker          90s   v1.30.2
n232.offline.to   NotReady    worker          90s   v1.30.2
n233.offline.to   NotReady    worker          90s   v1.30.2
n234.offline.to   NotReady    worker          90s   v1.30.2

kubectl get nodes --show-labels
NAME              STATUS      ROLES           AGE   VERSION   LABELS
m240.offline.to   NotReady    control-plane   61m   v1.30.2   beta.kubernetes.io/arch=arm64,beta.kubernetes.io/os=linux,kubernetes.io/arch=arm64,kubernetes.io/hostname=m240.offline.to,kubernetes.io/os=linux,node-role.kubernetes.io/control-plane=,node.kubernetes.io/exclude-from-external-load-balancers=
n230.offline.to   NotReady    worker          94s   v1.30.2   beta.kubernetes.io/arch=arm64,beta.kubernetes.io/os=linux,kubernetes.io/arch=arm64,kubernetes.io/hostname=n230.offline.to,kubernetes.io/os=linux,node-role.kubernetes.io/worker=worker
n231.offline.to   NotReady    worker          94s   v1.30.2   beta.kubernetes.io/arch=arm64,beta.kubernetes.io/os=linux,kubernetes.io/arch=arm64,kubernetes.io/hostname=n231.offline.to,kubernetes.io/os=linux,node-role.kubernetes.io/worker=worker
n232.offline.to   NotReady    worker          94s   v1.30.2   beta.kubernetes.io/arch=arm64,beta.kubernetes.io/os=linux,kubernetes.io/arch=arm64,kubernetes.io/hostname=n232.offline.to,kubernetes.io/os=linux,node-role.kubernetes.io/worker=worker
n233.offline.to   NotReady    worker          95s   v1.30.2   beta.kubernetes.io/arch=arm64,beta.kubernetes.io/os=linux,kubernetes.io/arch=arm64,kubernetes.io/hostname=n233.offline.to,kubernetes.io/os=linux,node-role.kubernetes.io/worker=worker
n234.offline.to   NotReady    worker          95s   v1.30.2   beta.kubernetes.io/arch=arm64,beta.kubernetes.io/os=linux,kubernetes.io/arch=arm64,kubernetes.io/hostname=n234.offline.to,kubernetes.io/os=linux,node-role.kubernetes.io/worker=worker

こんな感じでROLESがworkerになっていればOK。しかしStatusはNotReadyとなっておりkubernetesクラスタとしてはまだ不完全な状態。

CNIのインストール

ノードの構築自体は終わったけどkubernetesクラスタとしてはまだ不完全なので、完全に動作させるためにCNIをインストールする。CNIとはContainer Network Interfaceと言ってpod(コンテナ)間のネットワークを構成するためのものらしい。

ciliumとかcalicoとかflannelとか色々あるけど、とりあえずciliumを使うことにしてインストールを進めていく。

kubectl -n kube-system get pod
NAME                                      READY   STATUS              RESTARTS       AGE
coredns-7db6d8ff4d-29w4s                  0/1     ContainerCreating   0              8m46s
coredns-7db6d8ff4d-qwws8                  0/1     ContainerCreating   0              8m46s
etcd-m240.offline.to                      1/1     Running             12 (113s ago)  7m49s
kube-apiserver-m240.offline.to            1/1     Running             12 (113s ago)  7m49s
kube-controller-manager-m240.offline.to   1/1     Running             14 (113s ago)  7m49s
kube-scheduler-m240.offline.to            1/1     Running             13 (113s ago)  7m49s

事前の確認としてkube-systemというネームスペースのpodを表示してみると、kubernetesのコアコンポーネントであるcorednsがRunningになっていない事が確認できる。CNIをインストールするとこれがまともに動くようになるはず。

 インストール方法はいくつかあるようだけど今回はhelmを使ってインストールする。helm repoにciliumのリポジトリを追加してインストールするだけ。

helm repo add cilium https://helm.cilium.io/
helm repo update
helm install cilium cilium/cilium --version 1.15.6 --namespace kube-system --set l2announcements.enabled=true --set k8sClientRateLimit.qps=50 --set k8sClientRateLimit.burst=100 --set kubeProxyReplacement=true --set k8sServiceHost=kube-cp.offline.to --set k8sServicePort=6443 --set routingMode=native --set externalIPs.enabled=true --set ipv4NativeRoutingCIDR=172.16.0.0/16 --set ipam.mode=kubernetes --set bpf.masquerade=true --set autoDirectNodeRoutes=true --set endpointRoutes.enable=true

だけなんだけど、色々オプションがついてしまった。まぁこのへんは必要に応じて変更してもらいたい。とりあえず必須なのは k8sServiceHost, k8sServicePort あたりだろうか。詳しい事はciliumの公式ページを参考にしてほしい。(正直よくわからん)

で、インストールが終わったらまたkube-systemのpodを見てみる。

kubectl get pod -n kube-system
NAME                                      READY   STATUS    RESTARTS       AGE
cilium-g5x7t                              1/1     Running   0              21h
cilium-h8t5w                              1/1     Running   0              21h
cilium-lb9bc                              1/1     Running   0              21h
cilium-operator-d59fc86f5-ptlfg           1/1     Running   0              21h
cilium-operator-d59fc86f5-wfcf5           1/1     Running   0              21h
cilium-q2pxk                              1/1     Running   0              21h
cilium-r9ltz                              1/1     Running   0              21h
cilium-vrl4s                              1/1     Running   0              21h
coredns-7db6d8ff4d-29w4s                  1/1     Running   0              21h
coredns-7db6d8ff4d-qwws8                  1/1     Running   0              21h
etcd-m240.offline.to                      1/1     Running   12 (21h ago)   21h
kube-apiserver-m240.offline.to            1/1     Running   12 (21h ago)   21h
kube-controller-manager-m240.offline.to   1/1     Running   14 (21h ago)   21h
kube-scheduler-m240.offline.to            1/1     Running   13 (21h ago)   21h

こんな感じでciliumのoperatorが2つと各ノードにpodが1つずつ立ち上がっているはず。最初のうちはInitとかが混じると思うけど、最終的に全てRunningになって、Readyの項目も 1/1 や 2/2 など欠けなく実行できていればOK。

実際のインストールの様子はこんな感じ。必要に応じて参考にしてほしい。

kubectl get nodes 
NAME              STATUS   ROLES           AGE   VERSION
m240.offline.to   Ready    control-plane   95m   v1.30.2
n230.offline.to   Ready    worker          34m   v1.30.2
n231.offline.to   Ready    worker          34m   v1.30.2
n232.offline.to   Ready    worker          34m   v1.30.2
n233.offline.to   Ready    worker          34m   v1.30.2
n234.offline.to   Ready    worker          34m   v1.30.2

最終的にノード一覧を表示するとこんな感じでReadyになっているはず。というわけで、これでクラスタとして一応動作するようになったはず。

とりあえず今回はここまにしておく。次はrook-cephをセットアップしてその上でナニカを動かすところまでやりたいなぁ。

この記事が気に入ったらサポートをしてみませんか?