现在把nginx的流量调度恢复

4层的也进行恢复

两台nginx上跑了一个keepalive，把另外一台也配置上

把配置黏贴过来

这样nginx也都好了

完全是用traefik-ingress控制器来对流量进行分发，也就是ingress的资源就是一个可视化的nginx

把容器删了，自己会钻到21上了

dashboard现在就一个副本，想要2个

就会给你起来一个，这样就很方便对容器横向扩容

小人输入dashboard.od.com,流量是从笔记本浏览器经过dns解析到vip 10.4.7.10上（也就是10.4.7.11/12），进入到11节点上的7层负载均衡nginx里，nginx看到你请求的域名是dashboard.od.com，于是匹配到了自定义的dashboard.od.com，rewrite 443，卸载到了证书，然后帮你抛到了ingress上，ingress监听在了每个宿主机运算节点的81端口，把dashboard.od.com抛到了ingress，ingress控制器就会根据你的ingress资源配置找到host:dashboard.od.com，路径 /给你抛到dashboard的service上，相当于kubelet 把service和pod链接起来了，帮你找到了pod，pod在不同的节点，由kube-proxy的轮询算法，ipvs

这里就是dashboard，kube-proxy找到了192.168.40.188:443，用永不排队的NQ，lvs的轮询算法，轮询到172.7.21.5:8443，让两个dashboard能够交替给你服务。
跨宿主机能够通信，是因为装了CNI网络插件

Dubbo是一个阿里开源的微服务框架，基于java开发

Dubbo的架构，最主要的组件是registry（注册中心，服务发现就依赖这个注册中心，不管是消费者还是提供者都需要去链接注册中心，提供者provider到注册中心是注册地过程，消费者consumer到registry是订阅subscribe）
consumer 调用invoke provider提供者，是通过rpc协议去调用的，也就是远程过程调用，就好像在调用本地方法一样

这样就可以一些服务拆开了，consumer是web工程（各种页面调用的方法是后台不同的provider）

consumer是web工程（各种页面调用的方法是后台不同的provider），以前是调用本地方法，消耗本地资源 ，服务器就需要升级，不利于横向扩容，调用这些服务的时候，都可以让他们独立的一个个写成单独的服务,web服务区调用服务的时候，就好像在调用本地方法一样，实际上是资源不重叠的

真正交付Dubbo，要交付registry，provider，然后monitor和consumer

实验架构图，右上角是注册中心，Dubbo微服务的注册中心是依赖于zookeeper来做的，中间段是k8s集群，有DUbbo微服务提供者集群和Dubbo微服务消费者集群，都是封装pod，交付到k8s里，把能够动态扩容的服务都放到k8s里，把微服务的消费者和提供者交付到k8s集群里，同时把Dubbo-monitor交付到k8s集群里。
开发会把代码放到版本控制中心，运维使用恰当工具持续集成部署

编译代码，打包成docker镜像，放到harbor仓库里，ops服务器就是hdss7-200，做一个k8s的资源配置清单，应用到k8s里，就把代码变成了pod

用户访问找ingress，ingress配置好规则daemon.od.com,然后到消费者集群，消费者集群是一个web服务

这里需要把zk放在k8s外面，原因是zk是典型的有状态服务，不适宜放到k8s里进行管理

k8s具有很强的动态性，pod是可以漂移的，所以pod管理的一定是不能有状态的，无状态的意思就是这个容器死了就死了，无所谓，随便扩容，随便死。
有状态服务，是要有数据持久化下来，很不适合放在k8s里管理，k8s也有专门管理有状态服务的，叫是StatefulSet，这个pod控制器来管理有状态服务

ES MYSQL,ZK这种有状态服务，最好放到k8s外面去