gashirar's blog

ウイスキーがすき/美味しいものがすき/k8sがすき

トップ > Kubernetes > MinikubeのMulti-Node機能（Experimental）を試す

MinikubeのMulti-Node機能（Experimental）を試す

Kubernetes

はじめに

ローカル環境でKubernetesを簡単に実行するためのツールであるMinikubeにMulti-Node機能が追加された。
まだExperimentalな機能なので深堀はせず、まずは試しに動かしてみる。

おまけとしてこの機能が実装されるにいたるIssueを軽く眺めてみた。

環境

  • ホストマシン
  • minikube
    • v1.9.2
  • minikubeで構築されるKubernetes
    • v1.18.0

疎通

minikube start

--nodesオプションを利用してNode数を指定する。

# --vm-driverのところは適宜変更
minikube start --vm-driver=virtualbox --nodes=3

実行結果は下記の通り。--vm-driver=virtualboxを選択したので、3台のVMが作られている。
デフォルトでは1台当たり

  • CPU
    • 2core
  • Memory
    • 5000MB
  • Disk
    • 200000MB

のリソースが必要になるのでなかなかにマシンリソースは必要。

😄  Ubuntu 18.04 上の minikube v1.9.2
✨  Using the virtualbox driver based on user configuration
💿  VM ブートイメージをダウンロードしています...
    > minikube-v1.9.0.iso.sha256: 65 B / 65 B [--------------] 100.00% ? p/s 0s
    > minikube-v1.9.0.iso: 174.93 MiB / 174.93 MiB [-] 100.00% 54.61 MiB p/s 3s
👍  Starting control plane node m01 in cluster minikube
💾  Kubernetes v1.18.0 のダウンロードの準備をしています
    > preloaded-images-k8s-v2-v1.18.0-docker-overlay2-amd64.tar.lz4: 542.91 MiB
🔥  Creating virtualbox VM (CPUs=2, Memory=5000MB, Disk=20000MB) ...
❗  Unable to verify SSH connectivity: dial tcp 192.168.99.100:22: i/o timeout. Will retry...
❗  Unable to verify SSH connectivity: dial tcp 192.168.99.100:22: i/o timeout. Will retry...
🐳  Docker 19.03.8 で Kubernetes v1.18.0 を準備しています...
🌟  アドオンを有効化しています: default-storageclass, storage-provisioner

👍  Starting node m02 in cluster minikube
🔥  Creating virtualbox VM (CPUs=2, Memory=5000MB, Disk=20000MB) ...
🌐  ネットワーク オプションが見つかりました
    ▪ NO_PROXY=192.168.99.100
❗  Unable to verify SSH connectivity: dial tcp 192.168.99.101:22: i/o timeout. Will retry...
❗  Unable to verify SSH connectivity: dial tcp 192.168.99.101:22: i/o timeout. Will retry...
🐳  Docker 19.03.8 で Kubernetes v1.18.0 を準備しています...

👍  Starting node m03 in cluster minikube
🔥  Creating virtualbox VM (CPUs=2, Memory=5000MB, Disk=20000MB) ...
🌐  ネットワーク オプションが見つかりました
    ▪ NO_PROXY=192.168.99.100,192.168.99.101
🐳  Docker 19.03.8 で Kubernetes v1.18.0 を準備しています...
🏄  Done! kubectl is now configured to use "minikube"

DaemonSetをapplyしてみる

Kubernetes公式ドキュメントにあるYAMLを一部修正して適用（tolerationsの削除）

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd-elasticsearch
  namespace: kube-system
  labels:
    k8s-app: fluentd-logging
spec:
  selector:
    matchLabels:
      name: fluentd-elasticsearch
  template:
    metadata:
      labels:
        name: fluentd-elasticsearch
    spec:
      containers:
      - name: fluentd-elasticsearch
        image: quay.io/fluentd_elasticsearch/fluentd:v2.5.2
        resources:
          limits:
            memory: 200Mi
          requests:
            cpu: 100m
            memory: 200Mi
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        - name: varlibdockercontainers
          mountPath: /var/lib/docker/containers
          readOnly: true
      terminationGracePeriodSeconds: 30
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
      - name: varlibdockercontainers
        hostPath:
          path: /var/lib/docker/containers

kubectl get pod -n kube-system -o wideの結果は下記の通り。
fluentdのPodがminikube/minikube-m02/minikube-m03にそれぞれ配置されていることがわかる。

NAME                               READY   STATUS    RESTARTS   AGE     IP               NODE           NOMINATED NODE   READINESS GATES
coredns-66bff467f8-4xp56           1/1     Running   0          16m     172.17.0.2       minikube       <none>           <none>
coredns-66bff467f8-zccs9           1/1     Running   0          16m     172.17.0.3       minikube       <none>           <none>
etcd-minikube                      1/1     Running   0          16m     192.168.99.100   minikube       <none>           <none>
fluentd-elasticsearch-2n2fj        1/1     Running   0          5m46s   172.17.0.2       minikube-m02   <none>           <none>
fluentd-elasticsearch-4hv5f        1/1     Running   0          5m46s   172.17.0.4       minikube       <none>           <none>
fluentd-elasticsearch-85plw        1/1     Running   0          5m46s   172.17.0.2       minikube-m03   <none>           <none>
kube-apiserver-minikube            1/1     Running   0          16m     192.168.99.100   minikube       <none>           <none>
kube-controller-manager-minikube   1/1     Running   0          16m     192.168.99.100   minikube       <none>           <none>
kube-proxy-h7m5h                   1/1     Running   0          16m     192.168.99.100   minikube       <none>           <none>
kube-proxy-hcrdf                   1/1     Running   0          12m     <none>           minikube-m03   <none>           <none>
kube-proxy-lh9jh                   1/1     Running   0          14m     <none>           minikube-m02   <none>           <none>
kube-scheduler-minikube            1/1     Running   0          16m     192.168.99.100   minikube       <none>           <none>
storage-provisioner                1/1     Running   0          16m     192.168.99.100   minikube       <none>           <none>

issueを眺める

Multi-Node対応のIssueは2016年の5月あたりに出ていたので、それから約4年ごしの実装となった模様。

github.com

  • 2016年5月
    • Issueが立つ
  • 2018年2月
    • pbitty氏によるプロトタイプがcommitされる
      • このプロトタイプではVMを複数立ててクラスタを構成
  • 2019年2月
    • Rotten issuesとみなされ、k8s-ci-robotによりClose
  • 2019年3月
    • 再Open
  • 2020年3月
    • sharifelgamal氏によるmulti-node supportのcommitがMergeされる
  • 2020年4月
    • Close

ときどき「kind使えば実現できるよ」だったり「k3s使えばいいんじゃない？」的なcommentがあったり。

所感

ローカルでMulti-NodeなKubernetesクラスタを作成する場合はkindを利用していたが、MinikubeでもMulti-Nodeな構成が取れるのは選択肢が広がるので良いと思う。
KindのようにNodeをコンテナとして建てるか、現在のMinikaubeのようにNodeをVMとして建てるかの議論はあるが、自分はあまりそのレイヤを意識していないのでコメントは特になし。
（Operatorの開発者のようにK8s自体の機能拡張をするエンジニアであれば「テストに使うなら〇〇の方が良いよ」みたいなのがあるかも）

あとやはりVM立てるにはリソースはかなり要るな、と。