前言

這一天主要是來探討，為什麼我們團隊一定要用Istio，Native Kubernetes有什麼是目前有缺乏，無法辦到的事情。

Kubernetes VS Istio

Kubernetes在Pod之間的溝通都是採用Service，也就是說你可以有多個Pod但是會有一個抽象層Service，而Native Kubernetes在node之間的交換，也可以說Service To Service(Pod To Pod)是藉由Kube-Proxy來進行。

反之Istio(Service Mesh)，則是採用我上次有提到的Sidecar Pattern，在每一個Pod注入一個Sidecar(Agent)，在Istio的目前架構下是採用Envoy Proxy，所以不會透過Kube-Proxy進行Service To Service(Pod To Pod)交流。

為什麼不用Kube-Proxy，因為Kube-Proxy有一些非常致命性的缺點，

• NodePort的情況無法添加TLS服務
• 無法解析第七層協定ex Http,Http2,gRPC...等等
• 也必須再添加Ingress來建立複雜的DestionRule

gRPC

在Kubernetes上實作gRPC服務，利用Service To Service去讓gRPC Client(PodA)跟gRPC Server(PodB)能夠互相溝通，

gRPC是利用Http/2的概念去實作出來的RPC協議，它的一大特色就是不需要像 HTTP 一樣，每次發出請求的時候都要建立一個 TCP 連線，而是會重用已建好的連線。

gRPC Load Balancing Kubernetes

一開始我們沒有想太多，直接就用上Kube-Proxy，結果發生一些不可預期的狀況。

預期狀況

實際狀況

這導致 kube-proxy 只有在連線建立的當下，才成功做了負載均衡，之後的每一次 RPC 請求，都會利用原本的連線。這種情況其實後續的每一次的 RPC 請求都跑到了同一個地方，這並不是我們所期望的負載均衡，我們希望每一次的 RPC 請求都會根據我們的路由策略被轉送到適當的目的地。

Kube-Proxy IPVS Timeout

依據上面的方式建立，因服務暫時性採用Kubernetes NodePort，因此所有的Request Response實際上都是在Kube-Proxy上，Kube-Proxy並不能解析第七層協議導致會有連線無法KeepAlive，被Kube-Proxy主動斷去連線，失去gRPC的優勢，因此我們想加入Ingress讓服務不再從NodePort進行Request Response。

Ingress

很多人都知道Kubernetes Ingress只是一個標準，有非常多的第三方Gateway只要有符合Ingress標準的都可以套用在Kubernetes上，但是目前多數的Ingress Gateway都只有處理如何將Kubernetes Cluster內的服務Expose，而沒有考慮到Kubernetes Cluster內的服務如果要往外。因此我們沒有採用Ingress常見的解決方案。

External Service

系統可能會有許多外部服務的相依，雖然Kubernetes已經在1.7版以後提供了Service type: ExternalName，可以做到跨NameSpace以及外部服務訪問的功能，但是Service ExternalName註冊的時候必須是固定的Domain，並且CoreDNS能夠解析，會造成維運上有過多的負擔。因此沒有使用Service ExternalName來進行外部服務的統一管理。

結語

上面就是目前團隊踩過的坑，明天會介紹我們是使用了哪些Istio的功能來幫助我們解決上面的問題。如果解釋得不夠好，再麻煩各位多多斧正。

圖片來源

Service Mesh Handbook
gRPC Load Balancing on Kubernetes without Tears
Kubernetes NodePort vs LoadBalancer vs Ingress? When should I use what?

F&Q

• kube-proxy time out 的發現點是我們在執行Auto-acceptance-test 會突發性的斷線,以及在QA人員操作上回饋會有斷線的狀況

• service loadbalance 的發現點是我們在執行Load Test的時候,目前我們有建立一套Monitor是 Prometheus+Grafana 針對Kubernetes Cluster進行Container,Pod,Machine這幾個等級搜集必要的資訊,Load Test的過程剛好有觸發到Horizontal Pod Autoscaler規則,但是Scaling Pod並沒有任何資源上的大量使用