前言
今天上班就發現這個情況,istio的服務無法訪問,但同一個叢集的另一個istio pod卻正常。
雖然每次將istio 整個砍掉後再重裝就能正常,
但不可能每次都砍阿。😱
正文
看事件錯誤寫的是
Readiness probe failed: HTTP probe failed with statuscode: 503
(fig.1)
pod 的狀態是running ,但istio-proxy 卻是 containers with unready status
(fig.2)
根據錯誤訊息都沒找到相符合的資料
ref.
Readiness probe failed: HTTP probe failed with statuscode: 503 #23283。
現在看istio-proxy的日誌,上面寫的是
Envoy proxy is NOT ready: config not received from Pilot (is Pilot
running?)
這個似乎是原因…
-
查看網格的狀況
istioctl proxy-status
(fig.3)
所屬的網格LDS寫 Never Ackonwledged
各欄位的意思如下
- LDS,Listener 發現服務:Listener 監聽器控制 sidecar 啟動端口監聽(目前只支持 TCP 協議),並配置 L3/L4 層過濾器,當網絡連接達到後,配置好的網絡過濾器堆棧開始處理後續事件。
- RDS,Router 發現服務:用於 HTTP 連接管理過濾器動態獲取路由配置,路由配置包含 HTTP 頭部修改(增加、刪除 HTTP 頭部鍵值),virtual hosts (虛擬主機),以及 virtual hosts 定義的各個路由條目。
- CDS,Cluster 發現服務:用於動態獲取 Cluster 信息。
- EDS,Endpoint 發現服務:用於動態維護端點信息,端點信息中還包括負載均衡權重、金絲雀狀態等,基於這些信息,sidecar 可以做出智能的負載均衡決策。
ref. Pilot
- 查看pod錯誤
Envoy proxy is NOT ready: config not received from Pilot (is Pilot running?): cds updates: 1 successful, 0 rejected; lds updates: 0 successful, 1 rejected
我一直以爲關鍵字是查前面的config not received from Pilot(is Pilot running?)
但後來開了工單找了Google工程師,他說重點是後面那句 lds updates: 0 successful,
1 rejected
然後查看 istiod log,可以看到lds為什麼會rejected
warn ads ADS:LDS: ACK ERROR router~10.131.1.19~istio-ingressgateway-794bbdb877-np94z.istio-system~istio-system.svc.cluster.local-994 Internal:Error adding/updating listener(s) 0.0.0.0_8443: Invalid path: /etc/istio/ingressgateway-certs/tls.crt
這段在pod剛開始建立時也有出現此錯誤,看起來是https的憑證有問題,
本來佈署gateway的yaml檔像這樣
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
name: istio-ingressgateway-video
namespace: sex-system
spec:
selector:
istio: ingressgateway # 使用默認的控制器
servers:
- port: #加密傳輸
number: 443
name: http
protocol: HTTPS
tls:
mode: SIMPLE
serverCertificate: /etc/istio/ingressgateway-certs/tls.crt #設定憑證路徑
privateKey: /etc/istio/ingressgateway-certs/tls.key #設定憑證路徑
hosts:
- "*" #該服務對應domain
- port:
number: 80
name: http
protocol: HTTP
hosts:
- "*" #該服務對應domain
憑證路徑是直接指向pod裡面的路徑,
但
google工程師說 istio v1.6開始gateway的tls已经不支援file mount类的设置了(i.e.
privateKey
,serverCertificate
). 。
所以,要麻自己建立 https的憑證 ,或者是乾脆不要https。
(ref.
Secure Gateways)
自己建立憑證的話,
根據上面的網址,產生 crt 跟 key ,然後使用
kubectl create secret tls credential-httpbin -n istio-system --cert=./httpbin.com.crt --key=./httpbin.com.key
建立sercret,最後再yaml內直接使用這個sercret的name
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
name: istio-ingressgateway-custom
namespace: abc
spec:
selector:
istio: ingressgateway-private # 使用默認的控制器
servers:
- hosts:
- httpbin.com
port:
name: httpbin
number: 443
protocol: HTTPS
tls:
credentialName: credential-httpbin
mode: SIMPLE
- port:
number: 80
name: http
protocol: HTTP
hosts:
- "*" #該服務對應domain
目前看起來是有直接解掉這個問題,
剛剛掛掉的pod,有變回正常的狀態。
但當初兩個pod,一個活着,另一個陣亡,還不知道爲何會這樣。
後來聽工程師講原因應該是這樣,
因為第一次起來的時候,是還沒有服務掛載,所以不會啟動。
但當有新的pod啟動時(因為此時已經有服務掛載了),
所以會導致此問題發生。
所以只要掛載服務後,將第一個正常的pod刪掉,就會發生此狀況
0 意見:
張貼留言