Oh My Iron man post - day seven
Oh my K8s service ! 談談Kube-proxy - 1
- 目錄
- 💎 Introduce K8s service - Kube-proxy 💎
- Introduce K8s service - 4 ways to apply service(1)
- Introduce K8s service - 4 ways to apply service(2)
- Service Comparison & Introduce Ingress
- Service Debugging
- How to install Traefik
- Nginx-ingress vs Traefik
承襲昨天講完的Helm,今天要來看看Service到底是如何把你的服務公開到Cluster之外囉!
為什麼要使用service?
在K8s中,所有的Pods隨時處於變動狀態,隨著replicas的變動,或者服務的rolling update, 一個Pods的IP也會跟著變動,那麼Pods之間要如何找到彼此呢?
services這個抽象概念就這麼誕生了。
運作原理
Service在被創建的時候, Service的Informer會透過Kubernetes Watch API得知有一個Service被創建, 然後kube-proxy這個component便會在Nodes上創建一條新的iptable rule。
iptables是什麼?
可以先看看這篇維基百科認識一下iptables, iptables有四張表
- filter表: 用於過濾封包,iptables指令預設會顯示這張表
- nat表: 用於位址轉換(snat, dnat), 要了解詳細定義可以看這
- mangle表: 用於處理封包
- raw表: 用於處理異常
每當有服務被創建時, kube-proxy就會新增rules到filter & nat這兩張表。
如何確認kube-proxy是否真的有將rules加到nodes?
先透過
1 | kubectl get service |
看看先前創建的Service:

然後進入其中一台Node,輸入
1 | sudo iptables-save |
就可以看到有相對應的rules被創建
基本上查過每張表之後,會發現Kube-proxy只會改到filter & nat這兩張表

輸入
1 | sudo iptables -L -t filter |
可以看到
這是異常的服務,前一篇有提到如果沒有endpoint,這個cluster IP是ping不到的
這種才是正常的。
輸入
1 | sudo iptables -L -t nat |
可以看到更多資訊:
這張是node port模式有的chain
取其中一個target “KUBE-SVC-7JGDB7JIEYQ4DQWR” 在log裡翻找
可以看到他對應到的name space, 以及在cluster & node上expose出的port
再繼續找還可以看到這個target的三個rules被選中的概率
這裡之所以會有三條,跟deployments的replicas數量設置有關
可以看到第一條規則是 1/3
第二條規則被選中的機率是 2/3 * 1/2 = 1/3
最後一條規則被選中的機率則是 1 - (1/3 + 1/3) = 1/3
為什麼要這樣設置呢?
因為iptables的rules是由上而下執行的,為了確保在隨機的模式下三條規則被選中的機率都是相同的,機率才這樣設計。
接下來會談談Service的四種Types。
Reference
- Kubernetes Informer: https://www.kubernetes.org.cn/2693.html
- 小信豬的原始部落 - service overview: https://godleon.github.io/blog/Kubernetes/k8s-Service-Overview/
- iptables: https://www.lijiaocn.com/%E9%A1%B9%E7%9B%AE/2017/03/27/Kubernetes-kube-proxy.html
- 維基百科 iptables: https://zh.wikipedia.org/wiki/Iptables
- NAT的兩種模式: https://blog.csdn.net/lasoup/article/details/78289735