第560回の
密に開発されクラスターにも対応したmicrok8s
第560回の記事が公開されたのはmicrok8sのv1.
しかしながら世の中の
Canonicalによるアナウンスでも、
他にもKubeflowやMultusといった人気のアドオンもサポートしている上に、
今回はこのmicrok8sの、
仮想マシン版LXDインスタンスの準備
microk8sそのものはただのKubernetesのインストーラーでしかありませんので、
おおよそmicrok8sが動くマシンに必要なリソースは次のとおりです。
- CPU:
「2コア x ノードの数」 だけCPUコアが必要です。ただしKVMの場合はインスタンスがCPUを占用する必要はありませんし、 昨今のそれなりのマシンはCPUのコアが十分に多いと思いますので、 そこまで気にする必要はないでしょう。 - メモリー:最低でも
「2GiB x ノードの数」 はほしいところです。これもノートPCでもない限り、 困ることはないでしょう。 - ストレージ:microk8sの上で何を動かすかに強く依存します。今回の手順のように本当に小さなコンテナを動かすだけであれば10GiBでも十分です。
ちなみにVirtualBox等の上にインストールしたUbuntuの上で構築することも可能です。VirtualBoxの上で仮想マシン版のLXDを動かす場合は、
では、
HA機能を利用するためには最低でも3台のマシンが必要です。よってまずは以下の手順で3台の仮想マシンを作成してください。
$ lxc launch ubuntu:20.04 k8s0 --vm -c limits.cpu=2 -c limits.memory=4GiB $ lxc launch ubuntu:20.04 k8s1 --vm -c limits.cpu=2 -c limits.memory=4GiB $ lxc launch ubuntu:20.04 k8s2 --vm -c limits.cpu=2 -c limits.memory=4GiB
「--vm
」
LXDの仮想マシンインスタンスは何も指定しないとlxc config set インスタンス名 limits.
」-t t2.
」
ストレージのサイズも変えたい場合は次のように実行してください。
$ lxc stop k8s0 $ lxc config device override k8s0 root size 40GiB $ lxc start k8s0
仮想マシンインスタンスの場合、lxc stop
などでシャットダウンした上で実行してください。lxc config device override
」
必要ならミラーサーバーを設定し、
$ lxc exec k8s0 -- sed -i 's/archive.ubuntu/jp.archive.ubuntu/' /etc/apt/sources.list $ lxc exec k8s0 -- sh -c 'apt update && apt full-upgrade -y' $ lxc restart k8s0 k8s1 k8s2
この3台の仮想マシンインスタンスがKubernetesクラスターのlxc restart
に時間がかかってタイムアウトエラーが発生するかもしれません。その場合は、lxc status
ですべてシャットダウンされたかを確認した上で、lxc start
を実行してください。
microk8sをインストールしてクラスター化する
次に各ノードにmicrok8sをインストールします。手順自体は第560回と同じです。
$ lxc exec k8s0 -- snap install microk8s --classic --channel=1.19 microk8s (1.19/stable) v1.19.2 from Canonical✓ installed
「--channel=1.
」
ここではk8s0ノードにのみインストールしていますが、
インストールが完了したら次のコマンドを実行し、
$ lxc exec k8s0 -- microk8s status --wait-ready microk8s is running high-availability: no datastore master nodes: 127.0.0.1:19001 datastore standby nodes: none addons: enabled: ha-cluster # Configure high availability on the current node disabled: ambassador # Ambassador API Gateway and Ingress cilium # SDN, fast with full network policy dashboard # The Kubernetes dashboard dns # CoreDNS fluentd # Elasticsearch-Fluentd-Kibana logging and monitoring gpu # Automatic enablement of Nvidia CUDA helm # Helm 2 - the package manager for Kubernetes helm3 # Helm 3 - Kubernetes package manager host-access # Allow Pods connecting to Host services smoothly ingress # Ingress controller for external access istio # Core Istio service mesh services jaeger # Kubernetes Jaeger operator with its simple config knative # The Knative framework on Kubernetes. kubeflow # Kubeflow for easy ML deployments linkerd # Linkerd is a service mesh for Kubernetes and other frameworks metallb # Loadbalancer for your Kubernetes cluster metrics-server # K8s Metrics Server for API access to service metrics multus # Multus CNI enables attaching multiple network interfaces to pods prometheus # Prometheus operator for monitoring and logging rbac # Role-Based Access Control for authorisation registry # Private image registry exposed on localhost:32000 storage # Storage class; allocates storage from host directory
上記のようにステータスが表示されたら準備完了です。これも他のノードにも実行しておきます。このタイミングではすべてのノードが独立しているため、
Kubernetesとしては動作している状態になったので、kubectl
を実行できます。
$ lxc exec k8s0 microk8s kubectl get nodes NAME STATUS ROLES AGE VERSION k8s0 Ready <none> 2m33s v1.19.2-34+1b3fa60b402c1c
「microk8s kubectl
」microk8s
」alias kubectl='microk8s kubectl'
」~/.bash_
」lxc exec
」snap alias microk8s.
」
クラスター化は、
クレデンシャルの生成はadd-node
」
$ lxc exec k8s0 microk8s add-node From the node you wish to join to this cluster, run the following: microk8s join 10.203.13.213:25000/b88027fd3b7980a9d61a28ff4f00388f If the node you are adding is not reachable through the default interface you can use one of the following: microk8s join 10.203.13.213:25000/b88027fd3b7980a9d61a28ff4f00388f microk8s join 10.1.150.64:25000/b88027fd3b7980a9d61a28ff4f00388f
「IPアドレス:ポート番号/クレデンシャル」join
」join
」add-node
」
登録する側のノードjoin
サブコマンドを実行します。
$ lxc exec k8s1 -- microk8s join 10.203.13.213:25000/b88027fd3b7980a9d61a28ff4f00388f Contacting cluster at 10.203.13.213 Waiting for this node to finish joining the cluster. ..
登録までにはしばらく時間がかかります。おとなしく待ちましょう。無事に登録できると、kubectl get nodes
」
$ lxc exec k8s0 microk8s kubectl get nodes NAME STATUS ROLES AGE VERSION k8s0 Ready <none> 6m35s v1.19.2-34+1b3fa60b402c1c k8s1 Ready <none> 87s v1.19.2-34+1b3fa60b402c1c k8s2 Ready <none> 86s v1.19.2-34+1b3fa60b402c1c
また、microk8s status
」
$ lxc exec k8s0 -- microk8s status --wait-ready microk8s is running high-availability: yes datastore master nodes: 10.203.13.213:19001 10.203.13.208:19001 10.203.13.95:19001 datastore standby nodes: none (後略)
ポイントはhigh-availability: yes
」master nodes
」
ちなみに
マスターノードにログインする
3台のノードがクラスター化されました。このため、kubectl
で操作可能ですlxc exec
」
$ lxc exec k8s0 -- sudo -i -u ubuntu ssh-import-id gh:(GitHubのアカウント名)
上記のように実行することで、authorized_
にインポートしてくれます。あとはk8s0のIPアドレスlxc list
で確認可能)
$ ssh [email protected]
試しにmicrok8s kubectl
を実行すると次のようなメッセージが表示されます。
k8s0$ microk8s kubectl get nodes Insufficient permissions to access MicroK8s. You can either try again with sudo or add the user ubuntu to the 'microk8s' group: sudo usermod -a -G microk8s ubuntu sudo chown -f -R ubuntu ~/.kube The new group will be available on the user's next login.
microk8sはいくつか管理者権限が必要な操作があります。microk8sグループに入っておくと、chown
しているのは、~/.kube
」lxc exec
」/root/
」chown
は実施しなくてもかまいません。
usermod
とchown
を実行し、
k8s0$ microk8s kubectl get nodes NAME STATUS ROLES AGE VERSION k8s0 Ready <none> 6m35s v1.19.2-34+1b3fa60b402c1c k8s1 Ready <none> 87s v1.19.2-34+1b3fa60b402c1c k8s2 Ready <none> 86s v1.19.2-34+1b3fa60b402c1c k8s0:$ microk8s status microk8s is running high-availability: yes datastore master nodes: 10.203.13.213:19001 10.203.13.208:19001 10.203.13.95:19001 datastore standby nodes: none (後略)
microbotのデプロイ
HA機能の動作確認を行う前に、
k8s0$ microk8s kubectl create deployment microbot --image=dontrebootme/microbot:v1 deployment.apps/microbot created
kubectl
コマンドで実際にデプロイされていることを確認しましょう。
k8s0$ microk8s kubectl get all NAME READY STATUS RESTARTS AGE pod/microbot-5f5499d479-bjjxw 1/1 Running 0 31s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/kubernetes ClusterIP 10.152.183.1 <none> 443/TCP 32m NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/microbot 1/1 1 1 33s NAME DESIRED CURRENT READY AGE replicaset.apps/microbot-5f5499d479 1 1 1 32s
ノードの外からアクセスできるように、
k8s0$ microk8s kubectl expose deployment microbot --type=NodePort --port=80 --name=microbot-service service/microbot-service exposed k8s0$ microk8s kubectl get service microbot-service NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE microbot-service NodePort 10.152.183.25 <none> 80:30085/TCP 27s
今回はExternal-IPは割り当てていません。各ノードのポート300085で受け付けていることがわかるため、
$ curl 10.203.13.213:30085 <!DOCTYPE html> <html> <style type="text/css"> .centered { text-align:center; margin-top:0px; margin-bottom:0px; padding:0px; } </style> <body> <p class="centered"><img src="microbot.png" alt="microbot"/></p> <p class="centered">Container hostname: microbot-5f5499d479-bjjxw</p> </body> </html>
「Container hostname
」kubectl get all
」
本来ならここでウェブブラウザーを使って表示することも試してみたいところではありますが、
ちなみに上記の環境だとPodはk8s2ノード上で動いているようです。
k8s0$ microk8s kubectl describe pod microbot | grep Node: Node: k8s2/10.203.13.208
スタンバイノードの作成とフェイルオーバーのテスト
最後に実際にmicrobotが動いているノードを落として、
まず、
HAクラスターに参加するノードが3台未満になると、
$ lxc launch ubuntu:20.04 k8s3 --vm -c limits.memory=4GB $ lxc exec k8s3 -- sed -i 's/archive.ubuntu/jp.archive.ubuntu/' /etc/apt/sources.list $ lxc exec k8s3 -- sh -c 'apt update && apt full-upgrade -y' $ lxc restart k8s3 $ lxc exec k8s3 -- snap install microk8s --classic --channel=1.19 $ lxc exec k8s3 -- microk8s status --wait-ready
さらにk8s0ノード上で、microk8s add-node
」microk8s join
」microk8s status
を実行するとスタンバイノードが追加されていることがわかりますね。
k8s0$ microk8s status microk8s is running high-availability: yes datastore master nodes: 10.203.13.213:19001 10.203.13.95:19001 10.203.13.208:19001 datastore standby nodes: 10.203.13.186:19001 k8s0$ microk8s kubectl get nodes NAME STATUS ROLES AGE VERSION k8s2 Ready <none> 62m v1.19.2-34+1b3fa60b402c1c k8s1 Ready <none> 62m v1.19.2-34+1b3fa60b402c1c k8s3 Ready <none> 39s v1.19.2-34+1b3fa60b402c1c k8s0 Ready <none> 67m v1.19.2-34+1b3fa60b402c1c
ここでmicrobotが動いているk8s2ノードを落としてしまいましょう。まずmicrobotのノードの位置は次のように確認できます。
k8s0$ microk8s kubectl describe pod microbot | grep Node: Node: k8s2/10.203.13.208
障害発生を装うならk8s2の仮想マシンインスタンスを落としてしまうという手もあります。今回はもう少しおとなしくmicroks leave
」
$ lxc exec k8s2 -- microk8s leave Generating new cluster certificates. Waiting for node to start.
しばらくしてからk8s0側から見ると、
k8s0$ microk8s kubectl get nodes NAME STATUS ROLES AGE VERSION k8s1 Ready <none> 64m v1.19.2-34+1b3fa60b402c1c k8s3 Ready <none> 2m28s v1.19.2-34+1b3fa60b402c1c k8s0 Ready <none> 69m v1.19.2-34+1b3fa60b402c1c k8s2 NotReady <none> 64m v1.19.2-34+1b3fa60b402c1c
取り外されたノードを完全にクラスターから除外するにはmicrok8s remove-node
」
k8s0$ microk8s remove-node k8s2 k8s0$ microk8s kubectl get nodes NAME STATUS ROLES AGE VERSION k8s1 Ready <none> 64m v1.19.2-34+1b3fa60b402c1c k8s3 Ready <none> 3m2s v1.19.2-34+1b3fa60b402c1c k8s0 Ready <none> 69m v1.19.2-34+1b3fa60b402c1c
ステータスを見ると、
k8s0$ microk8s status microk8s is running high-availability: yes datastore master nodes: 10.203.13.213:19001 10.203.13.95:19001 10.203.13.186:19001 datastore standby nodes: none
ここから数秒から数十秒の間に、kubectl describe pod
で確認してみましょう。
k8s0$ microk8s kubectl describe pod microbot | grep Node: Node: k8s3/10.203.13.186
どうやらk8s3ノードに移行したようです。
もちろん、
$ curl 10.203.13.213:30085 <!DOCTYPE html> <html> <style type="text/css"> .centered { text-align:center; margin-top:0px; margin-bottom:0px; padding:0px; } </style> <body> <p class="centered"><img src="microbot.png" alt="microbot"/></p> <p class="centered">Container hostname: microbot-5f5499d479-bkxvd</p> </body> </html>
ポイントはContainer hostname
」microbot-5f5499d479-bjjxw
)
このようにLXDとmicrok8sを組み合わせると、