2 kubernetes クラスタ間の名前解決

TungstenFabric の kubernetes クラスタ2組で、他のクラスタ内の svc / pod の名前解決、および ping 疎通が出来るか、を確認してみている。
環境としては、AWS 上の CentOS7.5 4台 (ami-3185744e, t2.medium) を使用した。

ansible-deployer でのインストールだと、 kubernetes クラスタが持つ ip subnet が重複してしまうため、今回は、 kubeadm を使って、kubernetes のインストールを行っている。
この際、 kubernetes で使用する subnet / service-dns-domain を変更したかったため、kubeadm init 実行時に以下のコマンドを使用している。

クラスタ0:
kubeadm init --pod-network-cidr=10.32.0.0/24 --service-cidr=10.96.0.0/24
クラスタ1:
kubeadm init --pod-network-cidr=10.32.1.0/24 --service-cidr=10.96.1.0/24 --service-dns-domain=cluster1.local

また、クラスタ1については、 coredns 用の svc ip も変更している (subnet の変更と合わせるため)

# cat /etc/sysconfig/kubelet 
-KUBELET_EXTRA_ARGS=
+KUBELET_EXTRA_ARGS="--cluster-dns=10.96.1.10"
# systemctl restart kubelet


TungstenFabric のインストール方法は、以下とほぼ同じだが、今回は、 TungstenFabric controller も、kubernetes 上で稼働させてみている。
http://aaabbb-200904.hatenablog.jp/entry/2019/03/17/222320

このため、TungstenFabric デプロイ時に使用する yaml が変わっている。

- # ./resolve-manifest.sh contrail-non-nested-kubernetes.yaml > cni-vrouter.yaml
+ # ./resolve-manifest.sh contrail-standalone-kubernetes.yaml > cni-vrouter.yaml 

他に、 cni-vrouter.yaml の編集時、および反映後に、以下を実施している。

cni-vrouter.yaml に以下を追記 (subnet, AS番号は、クラスタごとに重複しない値を指定):
  KUBERNETES_POD_SUBNETS: 10.32.1.0/24
  KUBERNETES_IP_FABRIC_SUBNETS: 10.64.1.0/24
  KUBERNETES_SERVICE_SUBNETS: 10.96.1.0/24
  JVM_EXTRA_OPTS: "-Xms128m -Xmx1g"
  BGP_ASN: "64513"
※ VROUTER_GATEWAY の行を削除 (こちらが残っていると、適用後に vRouter に疎通が取れなくなる)

# vi set-label.sh
masternode=$(kubectl get node | grep -w master | awk '{print $1}')
agentnodes=$(kubectl get node | grep -v -w -e master -e NAME | awk '{print $1}')
for i in config configdb analytics webui control
do
kubectl label node ${masternode} node-role.opencontrail.org/${i}=
done

for i in ${agentnodes}
do
kubectl label node ${i} node-role.opencontrail.org/agent=
done

# bash set-label.sh
※ controller, vrouter に、それぞれの role 割り当てを実施

controller, vrouter が上がってきたら、各クラスタの webui にアクセス出来ることを確認した後、1. k8s-pod-network, k8s-service-network に、route-target: 64512:11 を設定 2. controller 間で bgp peer を設定 を実施し、各クラスタの pod / svc 間で疎通が取れることを確認している。
http://aaabbb-200904.hatenablog.jp/entry/2017/11/06/011959

この後、coredns の設定を行うのだが、 coredns の deployment の状態を確認したところ、 pod が認識されていない状態だったため、以下のコマンドで、livenessProbe, readinessProbe の削除を行い、pod が認識されたことを確認している。(この作業を行わないと、coredns のpodが Service からの割り振り対象にならない)
# kubectl edit deployment -n kube-system coredns

また、1. 名前解決に時間がかかる事象の解消、2. service-dns-domain を元に 他クラスタへのforward、を実施するために、coredns の設定で、以下の変更を実施している。

# kubectl edit -n kube-system configmap coredns
1.
 -        forward . /etc/resolv.conf
 +        forward . 10.32.0.253
の変更を実施 (forward 先は、k8s-pod-network の service-ip に設定)
2.
    cluster1.local:53 {
        errors
        cache 30
        forward . 10.96.1.10
    }
を追記 (domain と forward 先が一致するように設定)

上記を実施することで、以下のように、クラスタ0, クラスタ1から、他のクラスタ内の pod の名前解決 / ping 疎通ができることを確認できた。

cluster0 -> cluster1:

/ # nslookup 10-32-1-249.default.pod.cluster1.local
Server:    10.96.0.10
Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.local

Name:      10-32-1-249.default.pod.cluster1.local
Address 1: 10.32.1.249 ip-10-32-1-249.ap-northeast-1.compute.internal
/ # 

/ # ping 10-32-1-249.default.pod.cluster1.local
PING 10-32-1-249.default.pod.cluster1.local (10.32.1.249): 56 data bytes
64 bytes from 10.32.1.249: seq=0 ttl=63 time=1.025 ms
64 bytes from 10.32.1.249: seq=1 ttl=63 time=0.598 ms
^C
--- 10-32-1-249.default.pod.cluster1.local ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.598/0.811/1.025 ms
/ # 
/ # ip -o a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000\    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
1: lo    inet 127.0.0.1/8 scope host lo\       valid_lft forever preferred_lft forever
1: lo    inet6 ::1/128 scope host \       valid_lft forever preferred_lft forever
15: eth0@if16: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue \    link/ether 02:10:48:88:da:59 brd ff:ff:ff:ff:ff:ff
15: eth0    inet 10.32.0.252/24 scope global eth0\       valid_lft forever preferred_lft forever
15: eth0    inet6 fe80::501c:63ff:fe7e:6166/64 scope link \       valid_lft forever preferred_lft forever
/ # 

cluster1 -> cluster0:

/ # nslookup 10-32-0-252.default.pod.cluster.local
Server:    10.96.1.10
Address 1: 10.96.1.10 kube-dns.kube-system.svc.cluster1.local

Name:      10-32-0-252.default.pod.cluster.local
Address 1: 10.32.0.252 ip-10-32-0-252.ap-northeast-1.compute.internal
/ # 
/ # 
/ # ping 10-32-0-252.default.pod.cluster.local
PING 10-32-0-252.default.pod.cluster.local (10.32.0.252): 56 data bytes
64 bytes from 10.32.0.252: seq=0 ttl=63 time=0.900 ms
64 bytes from 10.32.0.252: seq=1 ttl=63 time=0.535 ms
^C
--- 10-32-0-252.default.pod.cluster.local ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.535/0.717/0.900 ms
/ # 
/ # ip -o a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000\    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
1: lo    inet 127.0.0.1/8 scope host lo\       valid_lft forever preferred_lft forever
1: lo    inet6 ::1/128 scope host \       valid_lft forever preferred_lft forever
9: eth0@if10: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue \    link/ether 02:74:65:28:34:59 brd ff:ff:ff:ff:ff:ff
9: eth0    inet 10.32.1.249/24 scope global eth0\       valid_lft forever preferred_lft forever
9: eth0    inet6 fe80::2c59:7bff:fe92:114c/64 scope link \       valid_lft forever preferred_lft forever
/ #

仮にクラスタが複数に分かれている場合も、 TungstenFabric 内で、かつ fqdn を使用すれば、あまりクラスタの違いを意識すること無く疎通が出来そうなことが分かった。
複数のクラスタを運用する場合は、適用してみてもよいのではなかろうか。