KubeVela篇13：跨地域的多集群管理方案

随着公司全球化战略的布局，业务呈点状分布在亚太、美东、欧洲等多个地域，云原生kubevela在跨地域多集群管控方面也遇到网络上的互通问题。

在公司网络规划上只允许一个区域的一个VPC跟另一个区域的一个VPC打通，同区域不同机房的网络都可以打通的网络架构基础上，由于一个区域可能有多个业务，业务的k8s分布在不同云厂商或机房，要让kubevela管理分布在各个地域机房的K8s集群，需要引入代理。

kubevela作为管控集群，需要管控分布在全球多个机房的k8s集群。考虑到成本计算的问题，以及业务的加入退出问题，我们在每个区域部署一个代理集群，在代理集群上部署四层代理Nginx，通过四层代理将kubevela发起的kubenetates api请求转发给目标k8s集群。

kubevela访问业务集群，是访问api-server，（client-go）通过kubeconfig new一个clinet去访问k8s的api。因此是需要使用https协议的，并且client会从kubeconfig里面获取集群的域名和ssl证书发起请求，kubeconfig是我们给kubevela添加业务集群的时候传给kubevela的。

kubevela所在的集群的vpc和代理集群的vpc会通过terraform申请打通，打通后，Nginx使用NodePort暴露服务，kubevela可以直接使用代理集群的Node的ip加上特定端口号去访问被nginx代理的服务，这个ip可以通过k8s的api拿到。

nginx代理业务k8s集群（业务k8s集群的kubeconfig的server域名），配置将NodeIp:NodePort的请求转发给业务k8s集群。但kubeconfig签名的证书是kubeconfig的server字段的域名，因此不能直接通过代理集群的NodeIP访问。

另外如果kubeconfig中的server域名出现大写，由于域名有大写字母不合法，可以转成小写。证书签的是根域，域名子域部分将大写改成小写不影响证书。 Nginx的配置：

 business-a.conf: |
      server {
        listen            8000;
        // 业务集群的k8s集群的kubeconfig的server字段
        proxy_pass        xxxxxx.us-east-1.eks.amazonaws.com:443;
      }

Service：

apiVersion: v1
kind: Service
metadata:
  name: cross-region-nginx-proxy-svc
  namespace: vela-system
spec:
  type: NodePort
  ports:
  - name: business-a
    nodePort: 30000  
    port: 8000
    protocol: TCP
    targetPort: 8000
  selector:
    app: nginx

Kubevela的pod并不能直接解析业务集群的kubeconfig的server域名，但pod可以通过hostAliases绑定域名解析，将指定的一个域名解析到一个ip。我们通过给kubevela的cluster-gateway Pod添加hostAliases，将原server解析到代理集群的NodeIp。并在给kubevela添加业务集群的时候，将kubeconfig中sever的端口号换成NodePort。这样kubevela就可以用kubeconfig去访问业务集群了。

spec:
  template:
    spec:
      hostAliases:
      - ip: "172.16.8.8"
        hostnames:
        - "xxxxxx.us-east-1.eks.amazonaws.com" 

---

参考文献：

• 多集群应用交付：https://kubevela.io/zh/docs/case-studies/multi-cluster/
• cluster-gateway：https://github.com/oam-dev/cluster-gateway/tree/master
• open-cluster-management-io：https://github.com/open-cluster-management-io/api