作者：了哥-duff
來源：https://yq.aliyun.com/articles/603633
摘要： Springcloud在阿里雲的kubernetes上IP互通的實踐
問題
在應用微服務化方案中，Springcloud是比較常見的選擇，畢竟其對於Java 的程序員來說比較友好，基於Springboot的編程方式也使得門檻比較低。但是在將Springcloud的應用運行到Kubernetes容器化平臺的時候，對於集群外的Client要訪問集群內的服務就變得不是那麼容易了。因為通常的Kubernetes部署有以下約束:
- POD的IP段是獨立的IP段，對於集群外的機器是不可訪問
- Springcloud的服務做服務註冊的時候，註冊的是POD的IP
- Springcloud的客戶端從Eureka上獲取服務的IP是POD的IP，從而造成集群外機器訪問該POD的IP是不通的。
解決方案
方案一: Host network
部署的時候，以host network的方式部署Springcloud的服務應用。這個方式雖然簡單，但是其利用的是port mapping的方式，在同一個node節點部署多個實例時，容易造成端口衝突的問題，在kubernetes環境下，一般不建議使用
方案二：Bridge network/Macvlan/Vlan
利用CNI的bridge/Macvlan網絡模式，或者是網絡插件的Vlan模式(如Contiv)，將POD的IP段設置成與主機IP段在同一個段內 ，通過配置交換機的路由，使其能夠互訪。
但是這裡面有一定的侷限性，特別是在公有云上，是無法在虛擬網絡裡再構建這些二層網絡的。
方案三：將集群外的機器也納入集群內管理，但是不運行POD(建議)
依然是將POD的IP段設置為獨立的IP段，和主機IP段隔離。但是將集群外的機器，也納入集群內：安裝對應的kubectl, kubeproxy。這樣在這臺機器是可以直接訪問POD的IP的。為了不讓這些機器接受調度請求而運行對應的POD，需要認為將這些機器設置為非容器調度節點就可：
kubectl cordon
如果不小心在上面已經了POD，則可以將這些POD驅離：
kubectl drain
被驅離的node節點會顯示SchedulingDisabled的狀態：
需要注意的是，可能某些DaemonSet已經在上面運行POD（如flexvolume, kube-proxy等），則忽略就可。這些DaemonSet通常佔用資源很少，無需擔憂起損耗
kubectl cordon--ignore-daemonsets
如果在合適的時候，覺得這個node節點也可以加入kubernetes集群，則一條命令就搞定了：
kubectl uncordon
在阿里雲的kubernetes服務中，建議採用這種方式運行。
一個具體例子：
- 在阿里雲上通過Kubernetes容器服務，構建一個3 master+3 node的集群用來運行Springcloud的服務。
- 部署Eureka服務到Kubernetes集群中，可以參考擴展閱讀部分的章節（也可以部署在Kubernetes集群外）
- 將要在集群外部署不是容器的Springcloud的客戶端程序所在的ECS通過Kubernetes集群添加現有云服務器的方式納入集群管理（注意，這些ECS必須和Kubernetes集群的ECS在同一個VPC）
- 成功添加後，再將該機器設置為非調度節點即可
- 部署Springcloud的客戶端程序
如果特殊情況的確需要將POD的IP段設置成ECS主機所在的VPC的一個段內，則需要特殊處理，請諮詢對應的阿里雲的服務同學。但是不建議該模式。
閱讀更多 javafirst 的文章
