iT邦幫忙

第 11 屆 iThome 鐵人賽

DAY 3
2
DevOps

Kubernetes and Istio 三十天系列 第 3

[Day03]為什麼我們要用Istio,Native Kubernetes有什麼做不到

前言

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

Kubernetes VS Istio

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

gRPC Service

在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

Tcp TimeOut

Ingress

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並沒有任何資源上的大量使用


上一篇
[Day02]在討論Istio之前,我們先來說說什麼是Service Mesh
下一篇
[Day04]Istio幫助我們解決了什麼
系列文
Kubernetes and Istio 三十天30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

2 則留言

0
小夫
iT邦新手 2 級 ‧ 2019-09-20 20:56:08

作者您好~
是否可以探尋,有關 kube-proxy time out、service loadbalance不平均
如何了解到這兩個問題的存在,是採用什麼方式得知問題呢?

感謝作者。

做個壓力測試+監控應該很容易發現狀況

小夫 iT邦新手 2 級 ‧ 2019-09-24 23:28:19 檢舉

也是 XD

0
Blackie Tsai
iT邦新手 5 級 ‧ 2019-09-24 21:15:09

gRPC 不是 Grpc, 可能要正名一下歐!大小寫有差的

我要留言

立即登入留言