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 install epel-release yum -y install 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 install 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 がクラスタに追加されるはずである。
クラスタの状態
クラスタが立ち上がってから、各ノードのリソースを見てみたところ、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画面に順次割り振りが行われる
アクセスできることを確認した後、以下のリンクの通り、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 を使うため、使用できなくなっている
Config: 引き続き使用可能
UVE: 引き続き使用可能
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
参考リンク
[1ノードでのcephインストール]
https://www.berrange.com/posts/2015/12/21/ceph-single-node-deployment-on-fedora-23/
[rbd-mirror]
https://access.redhat.com/documentation/en-us/red_hat_ceph_storage/3/html/block_device_guide/block_device_mirroring
https://cloud.garr.it/support/kb/ceph/ceph-enabling-rbd-mirror/
https://blog.devnu11.net/2016/10/ceph-setting-up-rbd-mirror-between-two-ceph-clusters/
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 内への疎通が出来るようである。
内部の通信にはテナント分離を使用したいが、外部からの通信を受けるサブネットについては、共通のサブネットを使用する、という構成の場合に、使用できるのではなかろうか。