現在把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控制器來管理有狀态服務