WiF接続による Kubernetes クラスタの安定稼働

Kubernetes クラスタに WiFi 接続のノード追加して安定運用するための Tips を紹介します．

背景
要因
1. MetalLB関連の要因
2. Ingress関連の要因
解決方法

背景

Raspberry 4 以降であれば，問題なく Kubernetes クラスタに参加させることができます．Raspberry Pi のお手軽さを活かすために WiFi 接続をさせることも多いかと思います．

ただ，その状態で普通に運用していると，突如クラスタの調子が悪くなることがあります．症状としては，次のようなものです．

MetalLB や Ingress で公開している Service への通信が遅くなる
MetalLB や Ingress で公開している Service との通信が時々できなくなる

要因

以上の問題は，大きく次の2つに起因します．

MetalLB 関連
Ingress関連

以下でそれぞれについて説明します．

MetalLB関連の要因

MetalLB を L2 モードで運用している場合，原因の1つとして WiFi アクセスポイントに備わっている Proxy ARP 機能が考えられます．

MelatLB の L2　モードでは下図のように Speaker に選ばれたノードが，Service が動いているノードに変わって　ARP　に応答した上で，TCPやUDPでやってくる通信を kube-proxy でそノードに中継する動作を行います．

[出典: http://timd.cn/k8s/metallb/]

もし，Speaker ノードが WiFi 接続のノードに割り当てられた場合，最初の ARP には　Speaker ノードが応答しますが，それ以降の ARP には Proxy ARP 機能によって WiFi アクセスポイントが応答するようになります．

一方，Kubenetes の特性上，Speaker ノードの割り当ては動的に変化します．ところが，WiFi アクセスポイントはこれを察知することができません．そのため，時間が経過するとネットワーク機器の Proxy ARP が応答する MAC　アドレスと，Speaker ノードの MAC アドレスが食い違ってきます．この状態になってしまうと，Service へのアクセスが不安定になったり出来なくなってきます．

Ingress関連の要因

Ingress を使って Service をクラスター外に公開している場合，クラスター外から Service へのアクセスは下図のように全て Ingress が配置されたノードを経由するようになります．

もし，Ingress が WiFi 接続されたノードに割り当てられてしまうと，クラスタ外から Service への全ての通信が WiFI を経由するようになり，有線接続に比べて通信が不安定になたり，遅くなったりします．

解決方法

以上の課題は，MetalLB や Ingress の機能が配置されるノードを制限することで解決できます．

今回は，node-role.kubernetes.io/metallb が true になっているもののみに配置されるように設定することにします．

具体的には MetalLB の設定については，下記のように nodeSelectors から始まる 3行を追加します．

apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
    name: default
    namespace: metallb-system
spec:
    ipAddressPools:
        - default
        - ingress-pool
+     nodeSelectors:
+         - matchLabels:
+               node-role.kubernetes.io/metallb: 'true'

apiVersion: metallb.io/v1beta1

kind: L2Advertisement

metadata:

namespace: metallb-system

spec:

ipAddressPools:

- default

- ingress-pool

+ nodeSelectors:

+ - matchLabels:

+ node-role.kubernetes.io/metallb: 'true'

同様に Ingress の設定についても，下記のように nodeSelectors から始まる 3行を追加します．(Ingres としてingress-nginx を使っていることを想定)

apiVersion: apps/v1
kind: Deployment
metadata:
    labels:
        app.kubernetes.io/component: controller
        app.kubernetes.io/instance: ingress-nginx
        app.kubernetes.io/name: ingress-nginx
        app.kubernetes.io/part-of: ingress-nginx
        app.kubernetes.io/version: 1.11.1
    name: ingress-nginx-controller
    namespace: ingress-nginx
spec:
(中略)
+            nodeSelector:
+                kubernetes.io/os: linux
+                node-role.kubernetes.io/metallb: 'true'
            serviceAccountName: ingress-nginx
            terminationGracePeriodSeconds: 300

apiVersion: apps/v1

kind: Deployment

metadata:

labels:

app.kubernetes.io/component: controller

app.kubernetes.io/instance: ingress-nginx

app.kubernetes.io/name: ingress-nginx

app.kubernetes.io/part-of: ingress-nginx

app.kubernetes.io/version: 1.11.1

namespace: ingress-nginx

spec:

(中略)

+ nodeSelector:

+ kubernetes.io/os: linux

+ node-role.kubernetes.io/metallb: 'true'

serviceAccountName: ingress-nginx

terminationGracePeriodSeconds: 300

その上で，MetalLB や Ingress を配置しても問題ないノードに対して，node-role.kubernetes.io/metallb ラベルを設定します．

kind: Node
apiVersion: v1
metadata:
    name: ノード名
    labels:
        node-role.kubernetes.io/metallb: 'true'

kind: Node

apiVersion: v1

metadata:

labels:

node-role.kubernetes.io/metallb: 'true'

以上で設定は完了です．

今時点でクラスターで問題が発生している場合は，設定後に Kubernetes に WiFi 接続で参加しているノードを再起動してあげて 10分も待てば問題は解決すると思います．