运维-平台域名访问最佳实践，内容包括：

安装配置实例
Node节点标签设置和节点服务关联
开发集群IP和生产集群IP和节点关联
负载均衡和Keepalived虚拟IP的使用
dns解析问题
服务器和客户端内外网关系

1. 安装配置实例

假设安装配置config.yaml和hosts.yaml如下

config.yaml片段


# baseDomain 云平台的主域名
# appDomain ide和app相关的分配域名，可和baseDomain相同
domains:
  baseDomain: mypaas.local
  appDomain: mypaas.local

# 外部访问协议 https/http
ingressProtocol: 'https'
ingressPort: '8443'

# sshd 端口范围 （不填默认: 10001-19999）
sshd:
  beginPort: '10001'

hosts.yaml片段（node1和node2 配置为proxy，node3和node4 配置为ingress）

nodes:
  - name: node1
    host: 192.168.10.21
    label:
      - proxy
  - name: node2
    host: 192.168.10.22
    label:
      - proxy
  - name: node3
    host: 192.168.10.23
    label:
      - ingress
  - name: node4
    host: 192.168.10.24
    label:
      - ingress

2. 节点标签设置和节点服务关联

proxy

proxy标签：
1. proxy标签的节点表示运行开发集群IP对应的服务，服务是Kubernetes的DaemonSet类型
2. 每个设置标签的节点，有且只有一个对应的proxy服务，实例中proxy标签节点有两个，会运行两个对应的proxy服务。
3. 服务都是HostNework的类型，也就是对应容器服务是直接使用的节点的网络，而不是Kubernetes的内部网络，等价于直接在节点上启动服务。
proxy-deploy
1. 运行config.yaml中ingressProtocol和ingressPort定义的服务
2. ingressProtocol目前默认都用https，ingressPort就是后续客户端访问平台需要指定的端口，例如下面地址就访问了平台的控制台：https://console.mypaas.local:8443
sshd-proxy-deploy
1. sshd-proxy服务用于本地IDE，config.yaml的sshd下的beginPort表示本地IDE分配的端口，默认是10001，可根据实际情况调整。
2. 假设平台有5个本地IDE的池（相关内容参考平台文档池部分），那第一个打开本地IDE的池会使用10001端口，第二个是10002，以此类推，最终会使用10001到10005共5个端口
3. 池解绑后，对应的端口会暂停监听，下次有新的本地IDE打开会10001开始查找未使用的端口并分配。
4. 本地IDE的端口是sshd服务，如果是打开状态，可通过如下指令可连接（证书登录模式，下面指令执行会提示登录）：ssh -p 10001 ssh.mypaas.local
端口监听
1. 上面hosts.yaml中node1和node2定义的proxy标签，也就是最终node1和node2会监听如下端口：
  1. 8443 https协议，一定会监听
  2. 10001-10005 ssh协议，有本地IDE池打开会路由到对应池的sshd服务，没打开时仅监听但无有效服务
    ingress
ingress标签：
1. ingress标签的节点会运行nginx-ingress-controller的DaemonSet类型服务，这个是Kubernetes的基于Nginx实现的符合Kubernetes规范的Ingresss
2. 通过设置Kubernetes的Ingress可把应用暴露出来访问。
3. 提示：这里提的Ingress是特指Kubernetes的Ingresss，具体可参考Kubernetes的文档 https://kubernetes.io/zh-cn/docs/concepts/services-networking/ingress/
端口监听
1. 上面hosts.yaml中node3和node4定义的ingress标签，也就是最终node3和node4会监听如下端口
  1. 80 http协议，一定会监听
  2. 443 https协议，一定会监听

上面端口没有提供定义，后续平台提供自定义端口的方式

3. 开发集群IP和生产集群IP的关系

例如：部署环境开发集群IP是192.168.10.100，生产集群IP是192.168.10.101

开发集群IP

暴露proxy标签的服务给客户端
这里的客户端包括开发人员和运维人员用的机器，主要服务有：
1. https://console.myapaas.local:8443 控制器基础服务，注册license，应急管理
2. https://www.myapaas.local:8443 控制器服务，租户管理，中间件管理等所有平台相关的管理功能都在这里
3. https://xxx-yyy-ide.myapaas.local:8443 yyy用户的xxx应用开发环境
4. https://xxxyyy3-vip.myapaas.local:8443 yyy租户的xxx应用的开发测试，yyy用户默认是yyy租户的管理员

生产集群IP

暴露ingress标签的客户端
这里的客户端主要是指应用的最终使用用户，主要服务有：
1. https://xxxyyy3-vip.myapaas.local:8443 yyy租户的xxx应用
2. 是不是发现上面地址和开发集群IP完全相同
  1. 重要提示：开发集群IP可以完成平台所有服务的访问，但由于开发有一定的动态性，例如应用可能随时有增加删除，另外平台为了充分利用资源，IDE采用池模式，需要有动态绑定特性。
  2. proxy的https服务有较多的动态感知特性，会导致大并发将影响访问性能。
  3. 一个PaaS环境的开发人员数量有限，远小于一个应用最终用户的数量，一个应用要暴露给最终用户使用，需要用生产集群IP的方式，而使用生产集群IP，其实就只要把访问应用域名解析到生产集群IP就可以。

4. 负载均衡和Keepalived虚拟IP的使用

集群IP一般有两种方式提供

基于IaaS层提供的tcp方式的负载均衡

例如阿里云NLB（之前叫SLB）、华为叫ELB、腾讯叫CLB。各家称谓可能不同，但本质上确认对应产品是基于4层TCP的负载均衡就可以，后续统一用SLB表示
集群IP是两个，那对应的需要有两个SLB，他们的IP分别是192.168.10.100和192.168.10.101，需要对后端做如下设置：
1. 开发集群IP
  1. 把192.168.10.100的SLB端口8443、10001-10005分别指向node1（192.168.10.21）和node2（192.168.10.22）的对应端口
  2. 注意使用TCP模式，包括8443的https服务使用TCP ``` 192.168.10.100:8443 -> 192.168.10.21:8443 192.168.10.100:10001 -> 192.168.10.21:10001 ... 192.168.10.100:10005 -> 192.168.10.21:10005 192.168.10.100:8443 -> 192.168.10.22:8443 192.168.10.100:10001 -> 192.168.10.22:10001 ...
    
    192.168.10.100:10005 -> 192.168.10.22:10005

```

生产集群IP
1. 把192.168.10.101的SLB端口443分别指向node3（192.168.10.23）和node4（192.168.10.24）的对应端口
2. 注意使用TCP模式，用https也可以，但证书需要单独配置，这里采用TCP会更简单，平台应用管理就可以设置https证书
```
192.168.10.101:443 -> 192.168.10.23:443

192.168.10.101:443 -> 192.168.10.24:443
```

Keepalived实现的虚拟IP
1. 如果IaaS层没有负载均衡，可提供一个与Node节点一致同网段IP，平台安装时候可通过安装Keepalived服务基于虚拟IP实现集群IP特性。
2. Keepalived会感知proxy或ingress标签，在对应节点启动服务，并动态把虚拟IP绑定到节点上。
3. Keepalived服务会安装两份，分别对应开发集群IP的proxy标签，以及对应生产集群IP的ingress标签。
4. 安装好Keepalived后，访问虚拟IP就等价于访问对应节点的IP，不需要SLB那样做端口映射。
5. Keepalived的本质是动态选择一个可用的节点，并把虚拟IP地址绑定到节点IP上，类似于直接在节点IP上设置这个虚拟IP。
6. 注意：Keepalived实现了高可用，但不支持入口服务的负载均衡。如果节点有故障，将自动虚IP会漂移到正常节点IP。
7. 虽然入口服务不支持负载均衡，但后端服务都是基于Kubernertes的service，天然支持负载均衡。例如上面node3和node3，假设一开始虚IP候选的是node3，那node3的nginx-ingress-controller将作为入口，所有流量先集中放到到这里在分发到后端。

开发集群IP的并发有限，Keepalived的模式一般不会导致流量瓶颈。生产集群IP要留意下ingress标签的节点对外的网络，不要有网络瓶颈。

提示：

如果要达到负载均衡效果，可把newdao-console名空间下的ingresss-svc的service设置为NodePort方式，并访问443对应的3xxxxx的端口，这样所有的nginx-ingress-controller都将接收入口流量。通过虚IP+NodePort实现高可用的复杂均衡。

5. dns解析问题

有上面可知，一个PaasS平台环境，需要对安装安装域名做泛域名A记录解析到开发集群IP,如：*.mypaas.local 增加A记录192.168.10.100，这样平台开发和应用发布都能正常访问
一个应用做了发布并准备正式启用给最终用户，那需要把对应的应用域名解析到生产集群IP： xxxyyy3-vip.myapaas.local 增加A记录192.168.10.101
一个应用还可以自定义域名访问，在平台的应用管理哪里增加需要最终访问的域名就可以，也需要把这个自定义域名增加A记录解析到192.168.10.101
提示：*.mypaas.local解析到192.168.0.21或192.168.10.22其实也能正常使用，但这样不具备高可用，如果对应节点故障了，服务也将访问异常；同样，xxxyyy3-vip.myapaas.local解析到192.168.10.23或192.168.10.24也是可以正常访问的，同样不是高可用结构。

6. 服务器和客户端内外网关系

本文档例子中服务器使用了192.168.10.0/24的网络，实际使用过程中，客户端不会和服务器在一个局域网，一般有三种方式暴露给客户端

对外的SLB

也就是SLB应该是一个公网IP或客户端可访问到的局域网IP，这个SLB本身是和服务器网络192.168.10.0/24是相通的（或node有映射了可访问到的IP），参考上面把对应端口做好映射就可以，注意dns解析应该解析到这里的SLB的IP

IaaS层对外的虚拟机IP

这种场景可能在企业环境会多一点，一般基于堡垒机访问服务器保证安全性，而服务器有另外的IP暴露出来给客户端使用，客户端直连或通过VPN连接

如果基于Keepalived来做高可用，需要IaaS层把虚拟IP也有对应的对外IP暴露出来，dns解析应该解析为这个对外的IP

双网卡

node节点都使用双网卡，一块网卡是192.168.10.0/24能和服务器的其它集群互联，另外一快网卡是客户端局域网的IP

如果基于Keepalived来做高可用，Keepalived监听的虚拟IP应该是客户端这边的IP，dns也是解析为客户端的Keepalived对应的虚拟IP

运维-平台域名访问最佳实践