1,000ノードクラスタの負荷状況

多数のノードが含まれるクラスタでの負荷状況を確認するため、aws の環境を使って、1,000ノードのTungstenFabricクラスタを試してみている。

台数が多く、ansible-deployer だと構築に時間がかかったため、今回は以下のリンク先に従って、 kube-manager, vRouter のモジュールについては、kubernetes の機能を使って配布するようにした。
https://github.com/Juniper/contrail-ansible-deployer/wiki/Provision-Contrail-Kubernetes-Cluster-in-Non-nested-Mode

AMIについては、引き続き CentOS7.5 (ami-3185744e) を使用し、インスタンスタイプは、TungstenFabric controller, k8s master については、m3.xlarge (4vCPU, 16GB mem) 各1台, k8s node については、m3.medium (1vCPU, 4GB mem) 1,000台、を使用している。

1. TungstenFabric controller の構築

以下のリンクと同様、 ansible-deployer でインストールを行う。
http://aaabbb-200904.hatenablog.jp/entry/2019/02/10/222958

instance.yaml は、以下のように、controller 1台だけを指定している。(k8s_master, kube-managerは削除)

provider_config:
  bms:
   ssh_user: root
   ssh_public_key: /root/.ssh/id_rsa.pub
   ssh_private_key: /root/.ssh/id_rsa
   domainsuffix: local
   ntpserver: ntp.nict.jp
instances:
  bms1:
   provider: bms
   roles:
      config_database:
      config:
      control:
      analytics:
      webui:
   ip: 172.31.xx.xx
contrail_configuration:
  CONTAINER_REGISTRY: opencontrailnightly
  CONTRAIL_VERSION: latest
  KUBERNETES_CLUSTER_PROJECT: {}
  JVM_EXTRA_OPTS: "-Xms128m -Xmx1g"
global_configuration:

2. k8s master の構築

以下のリンクに従い、kubeadm を使った k8s master の構築を実施している。
https://github.com/Juniper/contrail-docker/wiki/Provision-Contrail-CNI-for-Kubernetes#faqs

# cd
# cat install-k8s-packages.sh
bash -c 'cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg
     https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF'
setenforce 0
yum install -y kubelet kubeadm kubectl docker
systemctl enable docker && systemctl start docker
systemctl enable kubelet && systemctl start kubelet
echo 1 > /proc/sys/net/bridge/bridge-nf-call-iptables
swapoff -a

# bash install-k8s-packages.sh

# kubeadm init
※ 以下のようなコマンドが表示されるのでひかえておく
kubeadm join 172.31.18.113:6443 --token we70in.mvy0yu0hnxb6kxip --discovery-token-ca-cert-hash sha256:13cf52534ab14ee1f4dc561de746e95bc7684f2a0355cb82eebdbd5b1e9f3634

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

3. k8s node の構築

上記のスクリプトk8s node でも実行し、その後、 kubeadm join を実施する必要がある。
並列で処理を実行するため、今回は GNU parallel と ssh を使用した。

まず、aws 内のノードについて、private ip の一覧を取得する。 (TungstenFabric controller, k8s master の ip は手動で削っておく)

$ pip install awscli
$ aws configure
 (access key, secret key, region 等を入力 (必要に応じて、 IAM から作成))
$ aws ec2 describe-instances --query 'Reservations[*].Instances[*].PrivateIpAddress' --output text | tr '\t' '\n' > /tmp/aaa.txt

その後、上記のリストを k8s master のインスタンスに送り、以下のようなコマンドで k8s node での実行を行う。(/tmp/aaa.pem は、EC2 インスタンス立ち上げ時に指定した pem ファイル)
※ 10-15分程度で完了した

yum -y epel-release 
yum -y parallel
ulimit -n 4096
cat aaa.txt | parallel -j1000 scp -i /tmp/aaa.pem -o StrictHostKeyChecking=no install-k8s-packages.sh centos@{}:/tmp
cat aaa.txt | parallel -j1000 ssh -i /tmp/aaa.pem -o StrictHostKeyChecking=no centos@{} chmod 755 /tmp/install-k8s-packages.sh
cat aaa.txt | parallel -j1000 ssh -i /tmp/aaa.pem -o StrictHostKeyChecking=no centos@{} sudo /tmp/install-k8s-packages.sh
cat aaa.txt | parallel -j1000 ssh -i /tmp/aaa.pem -o StrictHostKeyChecking=no centos@{} sudo kubeadm join 172.31.18.113:6443 --token we70in.mvy0yu0hnxb6kxip --discovery-token-ca-cert-hash sha256:13cf52534ab14ee1f4dc561de746e95bc7684f2a0355cb82eebdbd5b1e9f3634

4. vRouter の展開

上記が完了した後、 k8s master 上で以下を発行し、vRouter の展開を行う。(余分なコストがかかるのを防ぐため、kubectl apply 直前までは、k8s node を立ち上げる前に実施した方がよいかもしれない)

# cd
# yum -y git
# git clone https://github.com/Juniper/contrail-container-builder.git
# cd /root/contrail-container-builder/kubernetes/manifests
# vi ../../common.env
(以下を追記)
CONTRAIL_CONTAINER_TAG=latest
CONTRAIL_REGISTRY=opencontrailnightly

# ./resolve-manifest.sh contrail-non-nested-kubernetes.yaml > cni-vrouter.yaml 
※ 手動で以下の修正を行う (1. Null になってしまう行を削除, 2. k8s master の ip が入ってしまう部分の一部を TungstenFabric controller の ip で置き換え)
--- cni-vrouter.yaml.orig	2019-03-17 21:17:25.218399040 +0900
+++ cni-vrouter.yaml	2019-03-17 21:19:40.744368162 +0900
@@ -11,36 +11,20 @@
   namespace: kube-system
 data:
   AUTH_MODE: {{ AUTH_MODE }}
-  KEYSTONE_AUTH_HOST: {{ KEYSTONE_AUTH_HOST }}
-  KEYSTONE_AUTH_ADMIN_TENANT: "{{ KEYSTONE_AUTH_ADMIN_TENANT }}"
-  KEYSTONE_AUTH_ADMIN_USER: "{{ KEYSTONE_AUTH_ADMIN_USER }}"
-  KEYSTONE_AUTH_ADMIN_PASSWORD: "{{ KEYSTONE_AUTH_ADMIN_PASSWORD }}"
-  KEYSTONE_AUTH_ADMIN_PORT: "{{ KEYSTONE_AUTH_ADMIN_PORT }}"
-  KEYSTONE_AUTH_URL_VERSION: "{{ KEYSTONE_AUTH_URL_VERSION }}"
-  ANALYTICS_API_VIP: {{ ANALYTICS_API_VIP }}
-  ANALYTICS_NODES: {{ ANALYTICS_NODES }}
-  ANALYTICSDB_NODES: {{ ANALYTICSDB_NODES }}
+  ANALYTICS_NODES: TungstenFabric controller IP
+  ANALYTICSDB_NODES: TungstenFabric controller IP
   CLOUD_ORCHESTRATOR: {{ CLOUD_ORCHESTRATOR }}
-  CONFIG_API_VIP: {{ CONFIG_API_VIP }}
-  CONFIG_NODES: {{ CONFIG_NODES }}
-  CONFIGDB_NODES: {{ CONFIGDB_NODES }}
-  CONTROL_NODES: {{ CONTROL_NODES }}
-  CONTROLLER_NODES: {{ CONTROLLER_NODES }}
+  CONFIG_NODES: TungstenFabric controller IP
+  CONFIGDB_NODES: TungstenFabric controller IP
+  CONTROL_NODES: TungstenFabric controller IP
+  CONTROLLER_NODES: TungstenFabric controller IP
   LOG_LEVEL: {{ LOG_LEVEL }}
   METADATA_PROXY_SECRET: {{ METADATA_PROXY_SECRET }}
-  RABBITMQ_NODES: {{ RABBITMQ_NODES }}
+  RABBITMQ_NODES: TungstenFabric controller IP
   RABBITMQ_NODE_PORT: "{{ RABBITMQ_NODE_PORT }}"
-  ZOOKEEPER_NODES: {{ ZOOKEEPER_NODES }}
+  ZOOKEEPER_NODES: TungstenFabric controller IP
   ZOOKEEPER_PORTS: "{{ ZOOKEEPER_PORTS }}"
   ZOOKEEPER_PORT: "{{ ZOOKEEPER_PORT }}"
-  KUBERNETES_CLUSTER_NETWORK: "{{ KUBERNETES_CLUSTER_NETWORK }}"
-  KUBERNETES_CLUSTER_NAME: {{ KUBERNETES_CLUSTER_NAME }}
-  KUBERNETES_POD_SUBNETS: {{ KUBERNETES_POD_SUBNETS }}
-  KUBERNETES_IP_FABRIC_SUBNETS: {{ KUBERNETES_IP_FABRIC_SUBNETS }}
-  KUBERNETES_SERVICE_SUBNETS: {{ KUBERNETES_SERVICE_SUBNETS }}
-  KUBERNETES_IP_FABRIC_FORWARDING: "{{ KUBERNETES_IP_FABRIC_FORWARDING }}"
-  KUBERNETES_IP_FABRIC_SNAT: "{{ KUBERNETES_IP_FABRIC_SNAT }}"
-  KUBERNETES_PUBLIC_FIP_POOL: "{{ KUBERNETES_PUBLIC_FIP_POOL }}"
 ---
 apiVersion: v1
 kind: ConfigMap

# kubectl apply -f cni-vrouter.yaml

うまく適用されると、以下のように、1,000台の vRouter がクラスタに追加されるはずである。
f:id:aaabbb_200904:20190317221631p:plain

クラスタの状態

クラスタが立ち上がってから、各ノードのリソースを見てみたところ、TungstenFabric controller, k8s master で、以下のように CPU 使用率が高い状況になっていた。
※ TungstenFabric controller では、contrail-collector, redis 等、analytics の負荷が高く、k8s master では kube-apiserver, etcd の負荷が高くなった。
安定して稼働させるには、リソースの追加割り当てや、controller/analytics のスケールアウトなど、追加の考慮が必要かもしれない。

TungstenFabric controller, analytics:

top - 12:13:59 up 43 min,  1 user,  load average: 5.77, 12.05, 7.24
Tasks: 153 total,   1 running, 152 sleeping,   0 stopped,   0 zombie
%Cpu(s): 22.0 us, 16.9 sy,  0.0 ni, 60.3 id,  0.0 wa,  0.0 hi,  0.7 si,  0.1 st
KiB Mem : 15233672 total,  7091360 free,  3899712 used,  4242600 buff/cache
KiB Swap:        0 total,        0 free,        0 used. 10779720 avail Mem 

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                 
21165 root      20   0 1035220 333448  10996 S  48.2  2.2   3:26.06 contrail-collec                         
18891 root      20   0  906588 249180   7524 S  31.9  1.6   0:09.03 node                                    
12763 polkitd   20   0  243412 189736   1668 S  28.6  1.2   2:45.55 redis-server                            
19410 root      20   0 1375424 108644  12148 S  14.3  0.7   1:40.42 contrail-dns                            
18864 root      20   0  810588 165356   7196 S  13.0  1.1   0:05.14 node                                    
19448 root      20   0 2167860   1.0g  13732 S  10.6  7.0  10:04.95 contrail-contro                         
11985 root      20   0  776036  94764  35204 S   3.0  0.6   2:38.34 dockerd                                 
15803 root      20   0  248324  40180   5332 S   2.3  0.3   0:27.72 python   


k8s master:

top - 12:14:09 up 43 min,  1 user,  load average: 11.84, 12.30, 8.06
Tasks: 133 total,   1 running, 132 sleeping,   0 stopped,   0 zombie
%Cpu(s): 87.2 us,  6.6 sy,  0.1 ni,  3.5 id,  0.2 wa,  0.0 hi,  2.4 si,  0.0 st
KiB Mem : 15233672 total,  8167188 free,  4032788 used,  3033696 buff/cache
KiB Swap:        0 total,        0 free,        0 used. 10702748 avail Mem 

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                                                                 
11583 root      20   0 2999520   2.7g  37840 S 309.3 18.6  38:35.47 kube-apiserver                                                                                                          
 5854 root      20   0   10.3g 520460 181348 S  47.5  3.4   1:50.44 etcd                                                                                                                    
18836 root      20   0  481984 350196  27724 S  17.6  2.3   0:19.61 kube-controller                                                                                                         
11211 root      20   0 1572404  74628  31760 S   3.7  0.5   0:52.85 kubelet                                                                                                                 
18460 root      20   0  209628 119648  13428 S   2.7  0.8   0:08.79 kube-scheduler                                                                                                          
10663 root      20   0 1280720  60912  16316 S   0.7  0.4   1:12.93 dockerd-current                                                                                                         
  377 root      20   0  145808  88372  87852 S   0.3  0.6   0:42.88 systemd-journal  

一方、メモリ, disk については、数台での小規模なクラスタと比べて、大きな違いは見られなかった。
※ analyticsdb を有効化している場合、こちらも大きくリソースを使う可能性が高いため注意

TungstenFabric controller, analytics:
[root@ip-172-31-13-135 ~]# free -h
              total        used        free      shared  buff/cache   available
Mem:            14G        4.3G        6.1G         17M        4.1G        9.7G
Swap:            0B          0B          0B
[root@ip-172-31-13-135 ~]# 
[root@ip-172-31-13-135 ~]# 
[root@ip-172-31-13-135 ~]# df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/xvda1       20G  4.3G   16G  22% /
[root@ip-172-31-13-135 ~]# 

k8s master:
[root@ip-172-31-18-113 ~]# free -h
              total        used        free      shared  buff/cache   available
Mem:            14G        3.5G        7.9G        105M        3.2G         10G
Swap:            0B          0B          0B
[root@ip-172-31-18-113 ~]# 
[root@ip-172-31-18-113 ~]# df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/xvda1       20G  3.6G   17G  18% /
[root@ip-172-31-18-113 ~]#

TungstenFabric の deployment pattern

TungstenFabric には多数の機能があるため、どのケースでどの機能を使えるのか、をまとめてみている。

1. openstack, kubernetes を使うケース

この場合、vm, container へのアクセスは floating-ip 経由になるため、もっとも簡単な構成は、gatewayless の仮想ネットワークから、floating-ip を取得する使い方となる。
ルーター/スイッチは、ipv4 の bgp が使えればよいため、インオペは問題になりにくい、ものと思われる
http://aaabbb-200904.hatenablog.jp/entry/2019/02/03/195348

この場合も、内部の通信は、overlay で実施できるため、calico と ml2 を合わせたような動作が可能になる。

2. oVirt 等と組み合わせて使うケース

1 と違い、全てのサブネットを external にするようなケースを想定する。
※ このケースは、TungstenFabric を使わず、hypervisor からは vlan でパケットを出すような設定でも構成可能だが、vRouter の distributed firewall を使いたい場合、等を考え、このケースも考慮している

この場合、機材が EVPN/VXLAN に対応しているかどうか、で動作が変わってくる。

2-1. 機材がEVPN/VXLANに対応している場合

この場合は、vRouterとcore-switch でEVPN/VXLANを設定し、core-switch で vxlan routing を行う構成が基本となる。
https://github.com/Juniper/contrail-specs/blob/master/5.1/cfm-erb-unicast-crb-multicast-roles.md

この場合、vm 間通信は、通常と変わらず vRouter間のオーバーレイで実施される。
vm から baremetal への疎通は、inter-vxlan は spine を通じて、vxlan-routing され、intra-vxlan は、leaf と vRouter が vtep として動作する動きとなる。intra-vxlan については、BUM等もオーバーレイを通じて、replicate されるため、SDN の機能を使用しつつ、既存に近い構成が可能となる。

2-2. 機材がEVPN/VXLANに対応していない場合

この場合、vRouter と core-switch (vlan間ルーティングを行う機材) とのやりとりは、gatewayless を通じて実施することになる。
この場合も、仮想ネットワークを全て gatewayless 扱いにし、core-switch と ipv4 の bgp を行うことで、一応、vRouter を導入することは出来る (distbuted firewall 等も使用可能) ものと思われるが、vRouter 内との BUM のやり取りが出来なくなるため、仮想ネットワークと baremetal を同じサブネットに置くことは出来ない。
https://github.com/Juniper/contrail-specs/blob/master/gateway-less-forwarding.md#broadcast--multicast

このため、ブロードキャスト、マルチキャストを必要とするアプリケーションがある場合は、対応について考慮が必要となる。

3. openstack, kubenetes を使うケース (multi-tenancy を考慮する必要がある場合)

1 に似たケースで、multi-tenancy (ip重複を含む) を考慮する場合がある。
- aws vpc のように、テナントごとに重複可能なipを払い出したい場合, MSPのようなケースを想定
この場合、gatewayless だと、ip重複の場合が扱えないため、この場合は、floating-ip も overlay から取得する必要がある。
http://aaabbb-200904.hatenablog.jp/entry/2017/10/24/234846

overlay は、MPLS over UDP(GRE) か EVPN / VXLAN のどちらも可能だが、使える機材によって、どちらを採用するかを選ぶ形になるものと思われる。
※ 大まかにはルーターから直接 overlay を張る場合 (既にVRFで ipsec / mpls-over-mpls 等を受けている場合、など) はそのまま MPLS over GRE(UDP), 上記に対応する機材が無い場合、EVPN / VXLAN ということになる、ものと思われる。

4. NFVI として使うケース

NFVIとして使いたい場合、主に、controller からの bgp で、トラフィックを VNF に引き込む部分を実施することになる。
機能としては、BGPaaS, サービスチェイン等を使い、オーバーレイとしては、MPLS over GRE(UDP) が中心となる。
※ ml2 等だと、VNFにはSR-IOV 等を割り当て、トラフィックの引き込みは別途実施する、等、工夫が必要となるため、NFVI で引き込みまで実施したい場合、TungstenFabricが一つの選択肢になるものと思われる。

まとめ

TungstenFabric は、どちらかというと、3, 4 のケースで使われる場合が多いが、1, 2-1 についても、既存との互換性を保ちつつ、overlay を使ったSDNらしい動作を、提供することが出来る。
2-2 のケースについては考慮が必要だが、それ以外のケースでは、使っていってよいのではなかろうか。

TungstenFabric環境でのIstioインストール

以下の動画の構成で、TungstenFabric環境でのIstioインストールを試してみている。
https://www.youtube.com/watch?v=VSNc9qd2poA

環境としては、AWS 上の CentOS7 (ami-3185744e) を使用し、
controller x 1: mem 8GB, disk 8GB, vRouter x 1: mem 4GB, disk 8GB
※ tungstenfabric, r5.0.1, istio-1.0.5 のモジュールで確認
で構築している。

instance.yaml 、インストール手順はこちらと同様となる。
http://aaabbb-200904.hatenablog.jp/entry/2019/02/03/195348

k8s, tungsten-fabric のインストールが完了した後、以下の参考リンクに従い、istio, および、 bookinfo のインストールを行っていく。
https://istio.io/docs/setup/kubernetes/download-release/
https://istio.io/docs/setup/kubernetes/quick-start/
https://istio.io/docs/examples/bookinfo/

まず最初に、istio 本体のインストールを行う。

$ curl -L https://git.io/getLatestIstio | sh -
$ cd istio*
$ export PATH=$PWD/bin:$PATH
$ kubectl apply -f install/kubernetes/helm/istio/templates/crds.yaml
$ kubectl apply -f install/kubernetes/istio-demo.yaml
$ kubectl get pods -n istio-system -o wide
※ 5分程度で全 pod が起動
[root@ip-172-31-10-93 istio-1.0.5]# kubectl get pods -n istio-system -o wide
NAME                                      READY     STATUS    RESTARTS   AGE       IP              NODE
grafana-647f464b47-z5kqf                  1/1       Running   0          2m        10.47.255.245   ip-172-31-4-44.ap-northeast-1.compute.internal
istio-citadel-55f4559bf4-lpfll            1/1       Running   0          2m        10.47.255.241   ip-172-31-4-44.ap-northeast-1.compute.internal
istio-egressgateway-5f6cc9565f-zz6x9      1/1       Running   0          2m        10.47.255.247   ip-172-31-4-44.ap-northeast-1.compute.internal
istio-galley-6555f7b787-6zrxl             1/1       Running   0          2m        10.47.255.248   ip-172-31-4-44.ap-northeast-1.compute.internal
istio-ingressgateway-7477597868-c9p66     1/1       Running   0          2m        10.47.255.246   ip-172-31-4-44.ap-northeast-1.compute.internal
istio-pilot-5758759cf6-6vkn6              2/2       Running   0          2m        10.47.255.242   ip-172-31-4-44.ap-northeast-1.compute.internal
istio-policy-6866bb777-h6shx              2/2       Running   0          2m        10.47.255.244   ip-172-31-4-44.ap-northeast-1.compute.internal
istio-sidecar-injector-785d946b9f-8nl6p   1/1       Running   0          2m        10.47.255.238   ip-172-31-4-44.ap-northeast-1.compute.internal
istio-telemetry-659c98f9d7-72j8r          2/2       Running   0          2m        10.47.255.243   ip-172-31-4-44.ap-northeast-1.compute.internal
istio-tracing-77f9f94b98-zrxgg            1/1       Running   0          2m        10.47.255.237   ip-172-31-4-44.ap-northeast-1.compute.internal
prometheus-67d4988588-zt6vb               1/1       Running   0          2m        10.47.255.240   ip-172-31-4-44.ap-northeast-1.compute.internal
servicegraph-6948967d88-zvh9p             1/1       Running   0          2m        10.47.255.239   ip-172-31-4-44.ap-northeast-1.compute.internal
[root@ip-172-31-10-93 istio-1.0.5]#

istio の pod が起動した後、以下のコマンドで、サンプルアプリである、 bookinfo のインストールを実施する。

$ kubectl apply -f <(istioctl kube-inject -f samples/bookinfo/platform/kube/bookinfo.yaml)
$ kubectl get svc -o wide
[root@ip-172-31-10-93 istio-1.0.5]# kubectl get svc -o wide
NAME          TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE       SELECTOR
details       ClusterIP   10.108.145.18    <none>        9080/TCP   11s       app=details
kubernetes    ClusterIP   10.96.0.1        <none>        443/TCP    11m       <none>
productpage   ClusterIP   10.106.227.189   <none>        9080/TCP   9s        app=productpage
ratings       ClusterIP   10.107.149.71    <none>        9080/TCP   10s       app=ratings
reviews       ClusterIP   10.109.60.194    <none>        9080/TCP   9s        app=reviews
[root@ip-172-31-10-93 istio-1.0.5]#

[root@ip-172-31-10-93 istio-1.0.5]# kubectl get pod -o wide
NAME                             READY     STATUS    RESTARTS   AGE       IP              NODE
details-v1-845fc857bd-rfp2l      2/2       Running   0          1m        10.47.255.236   ip-172-31-4-44.ap-northeast-1.compute.internal
productpage-v1-c8dbcd7f8-jblpx   2/2       Running   0          1m        10.47.255.231   ip-172-31-4-44.ap-northeast-1.compute.internal
ratings-v1-6c788fb884-g5kb4      2/2       Running   0          1m        10.47.255.235   ip-172-31-4-44.ap-northeast-1.compute.internal
reviews-v1-84476bcf59-55shq      2/2       Running   0          1m        10.47.255.234   ip-172-31-4-44.ap-northeast-1.compute.internal
reviews-v2-5f69f77764-kf784      2/2       Running   0          1m        10.47.255.233   ip-172-31-4-44.ap-northeast-1.compute.internal
reviews-v3-6f64f77457-fmqdx      2/2       Running   0          1m        10.47.255.232   ip-172-31-4-44.ap-northeast-1.compute.internal
[root@ip-172-31-10-93 istio-1.0.5]#
※ 各 pod で2つのコンテナが起動していることを確認する (アプリケーションコンテナと envoy コンテナ)

この後、istio-ingress への external-ip の払い出しのため、以下のリンクと同様に、 gatewayless による floating-ip の設定を行う。
http://aaabbb-200904.hatenablog.jp/entry/2019/02/03/195348

※ kubemanager にコンテナ外で設定を行う場合、以下で実施することも可能
# tail /etc/contrail/common_kubemanager.env
(snip)
KUBERNETES_PUBLIC_FIP_POOL={'domain': 'default-domain', 'project': 'k8s-default', 'network': 'public-network1', 'name': 'default' }
#
# docker-compose -f /etc/contrail/kubemanager/docker-compose.yaml down
# docker-compose -f /etc/contrail/kubemanager/docker-compose.yaml up -d

floating-ip の設定が終わったら、istio経由の外部アクセスを提供するため、istio-ingress のインストールを行う。

$ kubectl apply -f samples/bookinfo/networking/bookinfo-gateway.yaml
$ kubectl get gateway
[root@ip-172-31-10-93 istio-1.0.5]# kubectl get gateway -o wide
NAME               AGE
bookinfo-gateway   17s
[root@ip-172-31-10-93 istio-1.0.5]# 

$ kubectl get svc --all-namespaces -o wide
[root@ip-172-31-10-93 istio-1.0.5]# kubectl get svc --all-namespaces -o wide
NAMESPACE      NAME                     TYPE           CLUSTER-IP       EXTERNAL-IP   PORT(S)                                                                                                                   AGE       SELECTOR
default        details                  ClusterIP      10.108.145.18    <none>        9080/TCP                                                                                                                  5m        app=details
default        kubernetes               ClusterIP      10.96.0.1        <none>        443/TCP                                                                                                                   17m       <none>
default        productpage              ClusterIP      10.106.227.189   <none>        9080/TCP                                                                                                                  5m        app=productpage
default        ratings                  ClusterIP      10.107.149.71    <none>        9080/TCP                                                                                                                  5m        app=ratings
default        reviews                  ClusterIP      10.109.60.194    <none>        9080/TCP                                                                                                                  5m        app=reviews
istio-system   grafana                  ClusterIP      10.98.191.116    <none>        3000/TCP                                                                                                                  9m        app=grafana
istio-system   istio-citadel            ClusterIP      10.105.46.119    <none>        8060/TCP,9093/TCP                                                                                                         9m        istio=citadel
istio-system   istio-egressgateway      ClusterIP      10.99.227.1      <none>        80/TCP,443/TCP                                                                                                            9m        app=istio-egressgateway,istio=egressgateway
istio-system   istio-galley             ClusterIP      10.97.53.49      <none>        443/TCP,9093/TCP                                                                                                          9m        istio=galley
istio-system   istio-ingressgateway     LoadBalancer   10.107.161.49    10.0.11.3     80:31380/TCP,443:31390/TCP,31400:31400/TCP,15011:31245/TCP,8060:32417/TCP,853:31014/TCP,15030:32577/TCP,15031:31476/TCP   9m        app=istio-ingressgateway,istio=ingressgateway
istio-system   istio-pilot              ClusterIP      10.107.3.44      <none>        15010/TCP,15011/TCP,8080/TCP,9093/TCP                                                                                     9m        istio=pilot
istio-system   istio-policy             ClusterIP      10.107.98.144    <none>        9091/TCP,15004/TCP,9093/TCP                                                                                               9m        istio-mixer-type=policy,istio=mixer
istio-system   istio-sidecar-injector   ClusterIP      10.96.59.151     <none>        443/TCP                                                                                                                   9m        istio=sidecar-injector
istio-system   istio-telemetry          ClusterIP      10.98.180.42     <none>        9091/TCP,15004/TCP,9093/TCP,42422/TCP                                                                                     9m        istio-mixer-type=telemetry,istio=mixer
istio-system   jaeger-agent             ClusterIP      None             <none>        5775/UDP,6831/UDP,6832/UDP                                                                                                9m        app=jaeger
istio-system   jaeger-collector         ClusterIP      10.111.92.176    <none>        14267/TCP,14268/TCP                                                                                                       9m        app=jaeger
istio-system   jaeger-query             ClusterIP      10.110.71.53     <none>        16686/TCP                                                                                                                 9m        app=jaeger
istio-system   prometheus               ClusterIP      10.106.27.29     <none>        9090/TCP                                                                                                                  9m        app=prometheus
istio-system   servicegraph             ClusterIP      10.108.204.215   <none>        8088/TCP                                                                                                                  9m        app=servicegraph
istio-system   tracing                  ClusterIP      10.98.103.145    <none>        80/TCP                                                                                                                    9m        app=jaeger
istio-system   zipkin                   ClusterIP      10.109.197.58    <none>        9411/TCP                                                                                                                  9m        app=jaeger
kube-system    kube-dns                 ClusterIP      10.96.0.10       <none>        53/UDP,53/TCP                                                                                                             17m       k8s-app=kube-dns
kube-system    kubernetes-dashboard     ClusterIP      10.105.122.165   <none>        443/TCP                                                                                                                   16m       k8s-app=kubernetes-dashboard
[root@ip-172-31-10-93 istio-1.0.5]# 

※ istio-ingressgateway に external-ip が付いていることを確認する。

istio-ingressgateway が構成出来た後、上記の external-ip にアクセスを行い、以下の3画面 (review-1, review-2, review-3) にアクセスできることを確認している。
※ デフォルトの動作では、3画面に順次割り振りが行われる
f:id:aaabbb_200904:20190212233228p:plain
f:id:aaabbb_200904:20190212233250p:plain
f:id:aaabbb_200904:20190212233308p:plain

アクセスできることを確認した後、以下のリンクの通り、virtual-service の適用を行い、envoy によって割り振り制御が行われることを確認できている。
(設定を投入してから切り替わるまで、最大1-2分程度かかった)
https://istio.io/docs/examples/intelligent-routing/
https://istio.io/docs/tasks/traffic-management/request-routing/
https://istio.io/docs/tasks/traffic-management/traffic-shifting/

$ kubectl apply -f samples/bookinfo/networking/destination-rule-all.yaml
$ kubectl get destinationrules -o yaml

$ kubectl apply -f samples/bookinfo/networking/virtual-service-all-v1.yaml
$ kubectl get virtualservices -o yaml
 -> review-1 (文字のみの画面) だけに割り振りが行われる。

$ kubectl apply -f samples/bookinfo/networking/virtual-service-reviews-test-v2.yaml
 -> review-1 だけにアクセスが行われるが、jason という名前でログインした場合、 review-2 (黒い星の画面) に割り振りが行われる。
$ kubectl delete -f samples/bookinfo/networking/virtual-service-reviews-test-v2.yaml


$ kubectl apply -f samples/bookinfo/networking/virtual-service-reviews-50-v3.yaml
 -> review-1, review-3 (文字のみの画面 / 赤い星の画面) に 50% ずつ割り振りが行われる。

analytics_database 無しでのインストール

直近の tungsten fabric では、以下の spec に従い、analytics 関連の各コンポーネント無しでのインストールが可能となっている。
https://github.com/Juniper/contrail-analytics/blob/master/specs/analytics_optional_components.md

今回は analytics のみでのインストールを行ってみている。

環境は AWS上のCentOS7.5 AMI (ami-3185744e) を t2.medium (vCPU x2, mem 4GB) で 2台起動し、 / に disk 8GB を割り当てている。

インストールの手順は以下に従い、
http://aaabbb-200904.hatenablog.jp/entry/2018/04/28/215922

instance.yaml としては、以下を使用した。

[root@ip-172-31-12-85 contrail-ansible-deployer]# cat config/instances.yaml
provider_config:
  bms:
   ssh_user: root
   ssh_public_key: /root/.ssh/id_rsa.pub
   ssh_private_key: /root/.ssh/id_rsa
   domainsuffix: local
   ntpserver: ntp.nict.jp
instances:
  bms1:
   provider: bms
   roles:
      config_database:
      config:
      control:
      analytics:
      webui:
      k8s_master:
      kubemanager:
   ip: 172.31.12.85
  bms2:
   provider: bms
   roles:
     vrouter:
     k8s_node:
   ip: 172.31.2.9
contrail_configuration:
  CONTAINER_REGISTRY: opencontrailnightly
  CONTRAIL_VERSION: latest
  KUBERNETES_CLUSTER_PROJECT: {}
  JVM_EXTRA_OPTS: "-Xms128m -Xmx1g"
global_configuration:
[root@ip-172-31-12-85 contrail-ansible-deployer]#

※ configure_instances.yaml のコマンドが少し変わっているので注意

ansible-playbook -e orchestrator=kubernetes -i inventory/ playbooks/configure_instances.yml
※ 10分ほどかかる
ansible-playbook -e orchestrator=kubernetes -i inventory/ playbooks/install_k8s.yml
※ 5分ほどかかる
ansible-playbook -e orchestrator=kubernetes -i inventory/ playbooks/install_contrail.yml
※ 20分ほどかかる

インストールが完了した後、controller の memory を確認してみたところ、1.9GB 程度の使用量におさまっていた。
今まで memory 不足で tungsten fabric がインストール出来なかった環境でも、試してみることが出来るのではなかろうか。

free -h:
[root@ip-172-31-12-85 ~]# free -h
              total        used        free      shared  buff/cache   available
Mem:           3.7G        1.9G        470M         17M        1.3G        1.3G
Swap:            0B          0B          0B
[root@ip-172-31-12-85 ~]# 

[root@ip-172-31-2-9 ~]# free -h
              total        used        free      shared  buff/cache   available
Mem:           3.7G        532M        2.4G         16M        750M        2.9G
Swap:            0B          0B          0B
[root@ip-172-31-2-9 ~]#


contrail-status:
[root@ip-172-31-12-85 ~]# contrail-status 
Pod              Service         Original Name                          State    Id            Status        
                 redis           contrail-external-redis                running  44398f4345c5  Up 7 minutes  
analytics        api             contrail-analytics-api                 running  f507d25e2e3b  Up 4 minutes  
analytics        collector       contrail-analytics-collector           running  743fd12abac1  Up 4 minutes  
analytics        nodemgr         contrail-nodemgr                       running  66bae291cf04  Up 4 minutes  
config           api             contrail-controller-config-api         running  c92962e7e533  Up 5 minutes  
config           device-manager  contrail-controller-config-devicemgr   running  ae0a0282086a  Up 5 minutes  
config           nodemgr         contrail-nodemgr                       running  549aa0a93751  Up 5 minutes  
config           schema          contrail-controller-config-schema      running  c988dbcb9b4a  Up 5 minutes  
config           svc-monitor     contrail-controller-config-svcmonitor  running  ec7cf57e4bd2  Up 5 minutes  
config-database  cassandra       contrail-external-cassandra            running  d771c85d5e50  Up 6 minutes  
config-database  nodemgr         contrail-nodemgr                       running  6e50281203fc  Up 6 minutes  
config-database  rabbitmq        contrail-external-rabbitmq             running  f5e7f99be03d  Up 6 minutes  
config-database  zookeeper       contrail-external-zookeeper            running  0b996607586b  Up 6 minutes  
control          control         contrail-controller-control-control    running  4269d4ca1ac7  Up 4 minutes  
control          dns             contrail-controller-control-dns        running  b5ba2ad81120  Up 4 minutes  
control          named           contrail-controller-control-named      running  35538b126133  Up 4 minutes  
control          nodemgr         contrail-nodemgr                       running  9242c85d41f3  Up 4 minutes  
device-manager   dnsmasq         contrail-external-dnsmasq              running  be46fd7c4095  Up 5 minutes  
kubernetes       kube-manager    contrail-kubernetes-kube-manager       running  bf9f42f1f502  Up 3 minutes  
webui            job             contrail-controller-webui-job          running  96fb6a5fb728  Up 5 minutes  
webui            web             contrail-controller-webui-web          running  a995118b17ae  Up 5 minutes  

== Contrail control ==
control: active
nodemgr: active
named: active
dns: active

== Contrail config-database ==
nodemgr: initializing (Disk for DB is too low. )
zookeeper: active
rabbitmq: active
cassandra: active

== Contrail kubernetes ==
kube-manager: active

== Contrail analytics ==
nodemgr: active
api: active
collector: active

== Contrail webui ==
web: active
job: active

== Contrail device-manager ==

== Contrail config ==
svc-monitor: active
nodemgr: active
device-manager: active
api: active
schema: active

[root@ip-172-31-12-85 ~]# 

[root@ip-172-31-2-9 ~]# contrail-status 
Pod      Service  Original Name           State    Id            Status        
vrouter  agent    contrail-vrouter-agent  running  5a37fe17859d  Up 2 minutes  
vrouter  nodemgr  contrail-nodemgr        running  dfea2a8b4ad0  Up 2 minutes  

vrouter kernel module is PRESENT
== Contrail vrouter ==
nodemgr: active
agent: active

[root@ip-172-31-2-9 ~]# 


nodetool -p 7201 info:
root@ip-172-31-12-85:/# nodetool -p 7201 info | grep -i heap
Heap Memory (MB)       : 54.32 / 1004.00
Off Heap Memory (MB)   : 0.00
root@ip-172-31-12-85:/#


df -h:
[root@ip-172-31-12-85 ~]# df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/xvda1      8.0G  6.0G  2.1G  75% /
[root@ip-172-31-12-85 ~]#

[root@ip-172-31-2-9 ~]# df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/xvda1      8.0G  3.1G  5.0G  39% /
[root@ip-172-31-2-9 ~]#


Monitor > Dashboard
※ alarm 等の機能は無効化されている, webui の Query タブ, contrail-flows, contrail-logs 等は query-engine / analyticsdb cassandra を使うため、使用できなくなっている
f:id:aaabbb_200904:20190210222211p:plain

Config: 引き続き使用可能
f:id:aaabbb_200904:20190210222252p:plain

UVE: 引き続き使用可能
f:id:aaabbb_200904:20190210222323p:plain

2ノードでの rbd-mirror設定

ceph を2台 (1ノード1クラスタ) にインストールし、その間で rbd mirror を設定してみている。

環境はAWS上のCentOS7.5 AMI (ami-3185744e) を t2.medium で起動し、 disk は / に 8GB, /dev/xvdb として 8GB を割り当てている。

1ノードへのceph インストール

以下の設定で、1ノード上のceph でも HEALTH OK になることを確認できた。
※ デフォルト設定だと、同じクラスタ内に3ノード必要だったため、1ノードで動かしたい場合、ceph.conf に2行追記する必要があった。

hostname=$(hostname | awk -F. '{print $1}')
yum -y install epel-release

cat << EOM > /etc/yum.repos.d/ceph.repo
[ceph-noarch]
name=Ceph noarch packages
baseurl=https://download.ceph.com/rpm-mimic/el7/noarch
enabled=1
gpgcheck=1
type=rpm-md
gpgkey=https://download.ceph.com/keys/release.asc
EOM

yum install -y ceph-deploy
mv -i /etc/yum.repos.d/ceph.repo /tmp

mkdir /root/my-cluster
cd /root/my-cluster/

ceph-deploy new ${hostname}

## 以下の2行を追記
echo 'osd_crush_chooseleaf_type = 0' >> ceph.conf
echo 'osd_pool_default_size = 1' >> ceph.conf


ceph-deploy install ${hostname}
ceph-deploy mon create-initial
ceph-deploy admin ${hostname}
ceph-deploy mgr create ${hostname}
ceph-deploy osd create --data /dev/xvdb ${hostname}

作成後、以下のように pool / image の作成を行い、block device として使用できることを確認している。
※ rbd-mirror の設定を続けて行う場合、mirror 先のクラスタにも、pool1 の作成 (# ceph osd pool create pool1 8) を実施しておく

ceph status
ceph osd pool create pool1 8
rbd pool init pool1
rbd create image1 --size 4096 --image-feature layering -p pool1
rbd map image1 --name client.admin -p pool1
ls -lhtr /dev/rbd/pool1/image1
mkfs -t xfs /dev/rbd/pool1/image1
mount /dev/rbd/pool1/image1 /mnt

rbd-mirror の設定

pool の作成が終わった後、rbd-mirror の設定を行う。

実際にミラーを行う rbd-mirror デーモンは、データ元の ceph クラスタに ceph クライアントとして接続するため、事前にデータ元クラスタでのkeyring作成と、mirror先クラスタからの疎通確認を行う必要がある。

上記のインストール手順だと データ元、 mirror 先ともに、ceph クラスタ名が 'ceph' となっており、mirror 時に別クラスタの指定が出来なくなってしまうため、事前にクラスタ名指定用のファイルを変更しておく。

各ノードで
/etc/sysconfig/ceph
CLUSTER=cluster1
-
CLUSTER=cluster2
を追記
※ cluster1 がデータ元、cluster2 を mirror 先とする


次に、以下のコマンドにより、cluster1 アクセス用の keyring (id: replusr1) を作成する。

※ データ元ノード上で実施
cd /etc/ceph
ln -s ceph.conf cluster1.conf
ln -s ceph.client.admin.keyring cluster1.client.admin.keyring
※ --cluster cluster1 の cli 指定を動作させるために必要

ceph auth get-or-create client.replusr1 mon 'profile rbd' osd 'profile rbd pool=pool1' -o /etc/ceph/cluster1.client.replusr1.keyring --cluster cluster1

ファイルが出来たら以下の2ファイルを、mirror 先ノードの /etc/ceph 以下に、scp 等でコピーする。

/etc/ceph/cluster1.conf
/etc/ceph/cluster1.client.replusr1.keyring

この段階で、mirror先のノードで以下を発行し、データ元のcephクラスタにアクセス出来ることを確認しておく。

※ mirror 先のノードで実施
ceph --id replusr1 --cluster cluster1 -s

また、後で、rbd-mirror デーモン起動時に使用するので、mirror 先のノードでも、cluster2 用の設定ファイルを作成しておく。

※ mirror 先のノード上で実施
cd /etc/ceph
ln -s ceph.conf cluster2.conf
ln -s ceph.client.admin.keyring cluster2.client.admin.keyring

ceph auth get-or-create client.replusr2 mon 'profile rbd' osd 'profile rbd pool=pool1' -o /etc/ceph/cluster2.client.replusr2.keyring --cluster cluster2

この後、実際にmirrorを始めるために、mirror を有効化する pool に対して以下を発行する。

※ データ元のノードで実施
# rbd feature enable pool1/image1 exclusive-lock
# rbd feature enable pool1/image1 journaling
※ 両方のノードで実施
# rbd mirror pool enable pool1 pool

最後に、mirror 先のノードにて、rbd-mirror デーモンの起動と、pool への peer 設定を実施する。

※ mirror 先のノードで実施
yum -y install rbd-mirror
systemctl enable ceph-rbd-mirror.target
systemctl enable ceph-rbd-mirror@replusr2
systemctl start ceph-rbd-mirror@replusr2

# rbd --cluster cluster2 mirror pool peer add pool1 client.replusr1@cluster1
# rbd --cluster cluster2 mirror pool info pool1
Mode: pool
Peers: 
  UUID                                 NAME     CLIENT          
  f383c009-2adf-419b-9f57-03030287fb8e cluster1 client.replusr1

# rbd mirror image status pool1/image1
image1:
  global_id:   ce71a13a-2a1d-4e5f-beb6-d95ca8e6558a
  state:       up+replaying
  description: replaying, master_position=[object_number=3, tag_tid=1, entry_tid=3], mirror_position=[object_number=3, tag_tid=1, entry_tid=3], entries_behind_master=0
  last_update: 2019-02-09 11:09:40

この状態で、以下のように、pool に image を追加すると、数秒後に mirror 先にも追加されるようになるはずである。

# rbd create image2 --size 4096 --image-feature layering,exclusive-lock,journaling -p pool1


※ 反映までの時間を計測した結果、約2秒後に反映された
[root@ip-172-31-12-196 ceph]# date; rbd create image2 --size 4096 --image-feature layering,exclusive-lock,journaling -p pool1
Sat Feb  9 12:30:20 UTC 2019
[root@ip-172-31-12-196 ceph]# 

[root@ip-172-31-7-146 ~]# while true; do date; rbd -p pool1 ls; sleep 0.5; done
(snip)
Sat Feb  9 12:30:19 UTC 2019
image1
Sat Feb  9 12:30:19 UTC 2019
image1
Sat Feb  9 12:30:20 UTC 2019
image1
Sat Feb  9 12:30:20 UTC 2019
image1
Sat Feb  9 12:30:21 UTC 2019
image1
Sat Feb  9 12:30:21 UTC 2019
image1
Sat Feb  9 12:30:22 UTC 2019
image1
image2
Sat Feb  9 12:30:23 UTC 2019
image1
image2

Ubuntu18.04でのTungstenFabricインストール

Ubuntu18.04 での Tungsten Fabric インストールを試してみている。

今回もAWS上のインスタンスを使用している。
AMIとしては、Ubuntu Server 18.04 LTS (HVM) (ami-07ad4b1c3af1ea214) を使用した。

環境としては、controller 1台 (t2.large, disk 30GB)、vRouter 1台 (t2.medium, disk 8GB) で、 kubernetes 環境を構築している。

まず、準備として、各ノードで 以下を実施している。

(all node) apt update
(controller node) apt install python-pip git
(controller node) pip install ansible==2.4.2.0
(vRouter node) apt install python

(controller node) ssh-keygen
(controller node) cd .ssh/
(controller node) cat id_rsa.pub >> authorized_keys
 (vRouter node の .ssh/authorized_keys にも上記の公開鍵を登録)
(controller node) cd

(controller node) git clone -b R5.0 http://github.com/Juniper/contrail-ansible-deployer
(controller node) cd contrail-ansible-deployer
(controller node) vi config/instances.yaml
(以下を記述)
provider_config:
  bms:
   ssh_user: root
   ssh_public_key: /root/.ssh/id_rsa.pub
   ssh_private_key: /root/.ssh/id_rsa
   domainsuffix: local
   ntpserver: ntp.nict.jp
instances:
  bms1:
   provider: bms
   roles:
      config_database:
      config:
      control:
      analytics:
      analytics_database:
      webui:
      k8s_master:
      kubemanager:
   ip: 172.31.6.88 # controller node の ip
  bms11:
   provider: bms
   roles:
     vrouter:
     k8s_node:
   ip: 172.31.9.130 # vRouter node の ip
contrail_configuration:
  CONTRAIL_VERSION: r5.0.1
  KUBERNETES_CLUSTER_PROJECT: {}
  JVM_EXTRA_OPTS: "-Xms128m -Xmx1g"
global_configuration:
  CONTAINER_REGISTRY: tungstenfabric

また、vrouter.ko ビルド時のエラーを回避するため、vRouter node にて、以下を実施している。

(vRouter node) # vi /usr/src/linux-aws-headers-4.15.0-1021/include/linux/uuid.h
(以下の3行をコメントアウト)
// typedef struct {
//      __u8 b[UUID_SIZE];
// } uuid_t;
(直後の行に、以下を追記)
typedef unsigned char uuid_t[16];


準備が終わったら、以下で実際のインストールを実施する。

ansible-playbook -i inventory/ playbooks/configure_instances.yml
ansible-playbook -e orchestrator=kubernetes -i inventory/ playbooks/install_k8s.yml
ansible-playbook -e orchestrator=kubernetes -i inventory/ playbooks/install_contrail.yml

※ インストール完了後、vhost0 が作成された後に、vRouter node で名前解決が出来なくなった場合、以下を実施する

(vRouter node) # vi /etc/systemd/resolved.conf
(以下を追記)
DNS=172.31.0.2
(vRouter node) # systemctl restart systemd-resolved.service

この後、以下の yaml ファイル ( https://github.com/tnaganawa/contrail-k8s-tutorial/tree/master/yml/1_initial ) で テスト用のコンテナを作成し、コンテナ間、およびGW IPへの疎通ができることを確認している。

root@ip-172-31-6-88:~/contrail-k8s-tutorial/yml/1_initial# kubectl get pod -o wide
NAME      READY     STATUS    RESTARTS   AGE       IP              NODE
cirros1   1/1       Running   0          38s       10.47.255.251   ip-172-31-9-130
cirros2   1/1       Running   0          16s       10.47.255.250   ip-172-31-9-130
root@ip-172-31-6-88:~/contrail-k8s-tutorial/yml/1_initial# kubectl exec -it cirros1 sh
/ # ping 10.47.255.250
PING 10.47.255.250 (10.47.255.250): 56 data bytes
64 bytes from 10.47.255.250: seq=0 ttl=63 time=1.482 ms
64 bytes from 10.47.255.250: seq=1 ttl=63 time=0.065 ms
^C
--- 10.47.255.250 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.065/0.773/1.482 ms
/ # ping 10.47.255.254
PING 10.47.255.254 (10.47.255.254): 56 data bytes
64 bytes from 10.47.255.254: seq=0 ttl=64 time=1.304 ms
64 bytes from 10.47.255.254: seq=1 ttl=64 time=0.128 ms
^C
--- 10.47.255.254 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.128/0.716/1.304 ms
/ # 

gatewayless からの floating-ip 取得

Tungsten Fabric の floating-ip は、通常、SDN-GW に MPLS over (GRE/UDP) で拡張したサブネットから取得するが、
gatewayless を指定したサブネットから取得することが出来るかどうかも調べてみた。
結果として、少なくとも kubernetes から service, ingress として使用する範囲では、特に問題なく取得することが出来た。


インストールについては、以下の instance.yaml を使用し、tungsten fabric controller 1台、vRouter 2台の kubernetes 環境を構築した。
http://aaabbb-200904.hatenablog.jp/entry/2018/04/28/215922

provider_config:
  bms:
   ssh_user: root
   ssh_public_key: /root/.ssh/id_rsa.pub
   ssh_private_key: /root/.ssh/id_rsa
   domainsuffix: local
   ntpserver: ntp.nict.jp
instances:
  bms1:
   provider: bms
   roles:
      config_database:
      config:
      control:
      analytics:
      analytics_database:
      webui:
      k8s_master:
      kubemanager:
   ip: 172.31.3.152
  bms11:
   provider: bms
   roles:
     vrouter:
     k8s_node:
   ip: 172.31.12.1
  bms12:
   provider: bms
   roles:
     vrouter:
     k8s_node:
   ip: 172.31.15.196
contrail_configuration:
  CONTRAIL_VERSION: r5.0.1
  KUBERNETES_CLUSTER_PROJECT: {}
  JVM_EXTRA_OPTS: "-Xms128m -Xmx1g"
global_configuration:
  CONTAINER_REGISTRY: tungstenfabric

また、以下のリンクと同様、kubernetes 環境のfloating-ip の取り先として、public-network1 (10.0.11.0/24) を指定した。
http://aaabbb-200904.hatenablog.jp/entry/2017/11/04/022638

gatewayless については、以下のリンクと同様、作成した public-network1 に、'IP Fabric Forwarding', 'External' にチェックを入れた。
また、public-network1 には、Policy として、'default-domain:k8s-default:k8s-default-ip-fabric-np' をアタッチした。 (この定義が無いと、vRouter 内のRPFでドロップされる)
http://aaabbb-200904.hatenablog.jp/entry/2018/05/14/003319

この状態で、以下のファイルを適用することで、service (Type: LoadBalancer), ingress を作成した。

[service]
https://github.com/tnaganawa/contrail-k8s-tutorial/blob/master/yml/3_contrail-cni-features/1-2_deployment/cirros-deployment.yaml
https://github.com/tnaganawa/contrail-k8s-tutorial/blob/master/yml/3_contrail-cni-features/2_service/loadbalancer.yaml

[ingress]
https://github.com/tnaganawa/contrail-k8s-tutorial/tree/master/yml/3_contrail-cni-features/3_ingress


上記設定によって、service, ingress で取得されたexternal-ip への経路が VyOS に配布され、別のEC2インスタンスから VyOS 経由でアクセス出来ることを確認している。
※ VyOS の設定については以下を参照
http://aaabbb-200904.hatenablog.jp/entry/2018/06/10/000427
aws 上で他のインスタンスから gatewayless のサブネットにアクセスする場合、'ネットワーク&セキュリティ > ネットワークインターフェース' から、'送信元/送信先の変更チェック' を 無効にする必要があるので注意
※※ vRouter, VyOS のノードに対して必要

稼働確認用の端末: 172.31.11.23
VyOS: 172.31.13.61
TungstenFabric Controller: 172.31.3.152
TungstenFabric vRouter: 172.31.12.1, 172.31.15.196


[root@ip-172-31-11-23 ~]# ip route
default via 172.31.0.1 dev eth0 
10.0.11.0/24 via 172.31.13.61 dev eth0 
172.31.0.0/20 dev eth0 proto kernel scope link src 172.31.11.23 
[root@ip-172-31-11-23 ~]# 
[root@ip-172-31-11-23 ~]# ssh cirros@10.0.11.3
cirros@10.0.11.3's password: 
$ 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
11: eth0@if12: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue \    link/ether 02:49:77:dc:06:27 brd ff:ff:ff:ff:ff:ff
11: eth0    inet 10.47.255.250/12 scope global eth0\       valid_lft forever preferred_lft forever
$ Connection to 10.0.11.3 closed.
[root@ip-172-31-11-23 ~]# 
[root@ip-172-31-11-23 ~]# 
[root@ip-172-31-11-23 ~]# curl -I 10.0.11.4
HTTP/1.1 200 OK
Server: nginx/1.7.9
Date: Sun, 03 Feb 2019 10:19:54 GMT
Content-Type: text/html
Content-Length: 612
Last-Modified: Tue, 23 Dec 2014 16:25:09 GMT
ETag: "54999765-264"
Accept-Ranges: bytes

[root@ip-172-31-11-23 ~]# 


vyos@VyOS-AMI:~$ show interfaces 
Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down
Interface        IP Address                        S/L  Description
---------        ----------                        ---  -----------
eth0             172.31.13.61/20                   u/u  
lo               127.0.0.1/8                       u/u  
                 ::1/128
vyos@VyOS-AMI:~$ 
vyos@VyOS-AMI:~$ show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
       I - ISIS, B - BGP, > - selected route, * - FIB route

S>* 0.0.0.0/0 [210/0] via 172.31.0.1, eth0
B>* 10.0.11.3/32 [20/100] via 172.31.12.1, eth0, 00:04:31
B>* 10.0.11.4/32 [20/100] via 172.31.15.196, eth0, 00:04:31
C>* 127.0.0.0/8 is directly connected, lo
C>* 172.31.0.0/20 is directly connected, eth0
vyos@VyOS-AMI:~$ 
vyos@VyOS-AMI:~$ show ip bgp summary 
BGP router identifier 172.31.13.61, local AS number 65311
IPv4 Unicast - max multipaths: ebgp 1 ibgp 1
RIB entries 3, using 288 bytes of memory
Peers 1, using 4560 bytes of memory

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
172.31.3.152    4 64512      17      17        0    0    0 00:04:39        2

Total number of neighbors 1
vyos@VyOS-AMI:~$ 


[root@ip-172-31-3-152 ~]# kubectl get pod -o wide
NAME                                 READY     STATUS    RESTARTS   AGE       IP              NODE
cirros-deployment-54b65ccf48-9pptp   1/1       Running   0          24m       10.47.255.250   ip-172-31-12-1.ap-northeast-1.compute.internal
cirros-deployment-54b65ccf48-fnbzv   1/1       Running   0          24m       10.47.255.251   ip-172-31-15-196.ap-northeast-1.compute.internal
nginx-deployment-64b46ddcc7-2s5dj    1/1       Running   0          23m       10.47.255.248   ip-172-31-12-1.ap-northeast-1.compute.internal
nginx-deployment-64b46ddcc7-65ffz    1/1       Running   0          23m       10.47.255.249   ip-172-31-15-196.ap-northeast-1.compute.internal

[root@ip-172-31-3-152 ~]# kubectl get svc -o wide
NAME                  TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE       SELECTOR
cirros-loadbalancer   LoadBalancer   10.107.23.224   10.0.11.3     22:30464/TCP   24m       app=cirros-deployment
kubernetes            ClusterIP      10.96.0.1       <none>        443/TCP        36m       <none>
nginx-svc             ClusterIP      10.96.143.176   <none>        80/TCP         23m       app=nginx-deployment

[root@ip-172-31-3-152 ~]# kubectl get ing -o wide
NAME            HOSTS     ADDRESS                   PORTS     AGE
nginx-ingress   *         10.0.11.4,10.47.255.247   80        23m
[root@ip-172-31-3-152 ~]# 


上記の通り、少なくとも vRouter 内に入る際、floating-ip を使う構成であれば、
SDN-GW に L3VPN / EVPN の機能が無くても
gatewayless との組み合わせによって、vRouter 内への疎通が出来るようである。

内部の通信にはテナント分離を使用したいが、外部からの通信を受けるサブネットについては、共通のサブネットを使用する、という構成の場合に、使用できるのではなかろうか。