Tungsten Fabric知识库丨测试2000个vRouter节点部署

最新推荐文章于 2020-12-29 17:26:28 发布

TungstenFabric

最新推荐文章于 2020-12-29 17:26:28 发布

阅读量627

点赞数

本文链接：https://blog.csdn.net/TungstenFabric/article/details/108601738

版权

本文详细介绍了在GCP上进行大规模Tungsten Fabric部署的过程，涉及2000个vRouter节点的设置，包括控制平面、分析节点和Kubernetes集群的配置。通过调整参数如XMPP_KEEPALIVE_SECONDS，优化了系统的可扩展性和性能。文章还讨论了vRouter的ERM-VPN功能，展示了如何在多节点集群中实现有效的多播流量管理。

摘要由CSDN通过智能技术生成

作者：Tatsuya Naganawa 译者：TF编译组

由于GCP允许启动多达5k个节点:)，因此vRouter的规模测试程序主要针对该平台来介绍。

话虽如此，AWS也可以使用相同的程序

第一个目标是2k个vRouter节点，但是据我尝试，这不是最大值，可以通过更多的控制节点或添加CPU/MEM来达到更大的数值。

在GCP中，可以使用多个子网创建VPC，将控制平面节点分配为172.16.1.0/24，而vRouter节点分配为10.0.0.0/9。（默认子网为/12，最多可达到4k个节点）

默认情况下，并非所有实例都可以具有全局IP，因此需要为vRouter节点定义Cloud NAT才能访问Internet。（我将全局IP分配给控制平面节点，因为节点数量不会那么多）

所有节点均由instance-group创建，并且禁用了auto-scaling，并分配了固定编号。所有节点都为了降低成本而配置了抢占模式（vRouter为$0.01/1hr（n1-standard-1），控制平面节点为$0.64/1hr（n1-standard-64））

总体程序描述如下：

使用此程序设置control/config x 5，analytics x 3，kube-master x 1。

https://github.com/tnaganawa/tungstenfabric-docs/blob/master/TungstenFabricPrimer.md#2-tungstenfabric-up-and-running

这一步最多需要30分钟。

使用了2002版本。JVM_EXTRA_OPTS：设置为“-Xms128m -Xmx20g”。

需要补充一点的是，XMPP_KEEPALIVE_SECONDS决定了XMPP的可扩展性，我将其设置为3。因此，在vRouter节点故障之后，control组件需要9秒才能识别出它来。（默认情况下设置为10/30）对于IaaS用例，我认为这是一个中等的选择，但如果这个值需要较低，则需要有更多的CPU。

为了后续使用，这里还创建了虚拟网络vn1（10.1.0.0/12，l2/l3）。

https://github.com/tnaganawa/tungctl/blob/master/samples.yaml#L3

使用此程序设置一个kube-master。

https://github.com/tnaganawa/tungstenfabric-docs/blob/master/TungstenFabricPrimer.md#kubeadm

这一步最多需要20分钟。

对于cni.yaml，使用以下URL。

https://github.com/tnaganawa/tungstenfabric-docs/blob/master/multi-kube-master-deployment-cni-tungsten-fabric.yaml

XMPP_KEEPALIVE_SECONDS：“3”已经添加到env中。

由于GCP上的vRouter问题，

https://github.com/tnaganawa/tungstenfabric-docs/blob/master/TungstenFabricKnowledgeBase.md#vrouters-on-gce-cannot-reach-other-nodes-in-the-same-subnet

vrouter-agent容器已打补丁，并且yaml需要更改。

  - name: contrail-vrouter-agent
    image: "tnaganawa/contrail-vrouter-agent:2002-latest"  ### 这一行改变了

set-label.sh和kubectl apply -f cni.yaml此时已完成。

启动vRouter节点，并使用以下命令转储ips。

(for GCP)
gcloud --format="value(networkInterfaces[0].networkIP)" compute instances list

(for AWS, this command can be used)
aws ec2 describe-instances --query 'Reservations[*].Instances[*].PrivateIpAddress' --output text | tr '\t' '\n'

这大约需要10-20分钟。

在vRouter节点上安装Kubernetes，然后等待它安装vRouter节点。

(/tmp/aaa.pem is the secret key for GCP)
sudo yum -y install epel-release
sudo yum -y install parallel
sudo su - -c "ulimit -n 8192; su - centos"
cat all.txt | parallel -j3500 scp -i /tmp/aaa.pem -o StrictHostKeyChecking=no install-k8s-packages.sh centos@{}:/tmp
cat all.txt | parallel -j3500 ssh -i /tmp/aaa.pem -o StrictHostKeyChecking=no centos@{} chmod 755 /tmp/install-k8s-packages.sh
cat all.txt | parallel -j3500 ssh -i /tmp/aaa.pem -o StrictHostKeyChecking=no centos@{} sudo /tmp/install-k8s-packages.sh

###该命令需要最多200个并行执行，如果不执行该命令，会导致kubeadm连接超时
cat all.txt | parallel -j200 ssh -i /tmp/aaa.pem -o StrictHostKeyChecking=no centos@{} sudo kubeadm join 172.16.1.x:6443 --token we70in.mvy0yu0hnxb6kxip --discovery-token-ca-cert-hash sha256:13cf52534ab14ee1f4dc561de746e95bc7684f2a0355cb82eebdbd5b1e9f3634

kubeadm加入大约需要20-30分钟。vRouter安装大约需要40-50分钟。（基于Cloud NAT性能，在VPC中添加docker注册表会缩短docker pull time）。

之后，可以使用replica: 2000创建first-containers.yaml，并检查容器之间的ping。要查看BUM行为，vn1也可以与具有2k replica的容器一起使用。

https://github.com/tnaganawa/tungstenfabric-docs/blob/master/8-leaves-contrail-config.txt#L99

创建容器最多需要15-20分钟。

[config results]

2200 instances are created, and 2188 kube workers are available.
(some are restarted and not available, since those instance are preemptive VM)

[centos@instance-group-1-srwq ~]$ kubectl get node | wc -l
2188
[centos@instance-group-1-srwq ~]$ 

When vRouters are installed, some more nodes are rebooted, and 2140 vRouters become available.

Every 10.0s: kubectl get pod --all-namespaces | grep contrail | grep Running | wc -l     Sun Feb 16 17:25:16 2020
2140

After start creating 2k containers, 15 minutes is needed before 2k containers are up.

Every 5.0s: kubectl get pod -n myns11 | grep Running | wc -l                                                             Sun Feb 16 17:43:06 2020
1927


ping between containers works fine:

$ kubectl get pod -n myns11
(snip)
vn11-deployment-68565f967b-zxgl4   1/1     Running             0          15m   10.0.6.0     instance-group-3-bqv4              
vn11-deployment-68565f967b-zz2f8   1/1     Running             0          15m   10.0.6.16