目錄
kube-proxy會一直watch api-service關於service的變動, 只要有變化就會生成可以排程到後端pod的iptables或者ipvs規則訪問k8s集群中的pod， 客戶端需要知道pod位址，需要感知pod的狀態。那如何獲取各個pod的位址？若某一node上的pod故障，客戶端如何感知？
通過selector發現後端發現具有同一label的pod;
為這些pod提供統一的入口位址;
將請求進行負載分發到後端的各個容器應用上的控制器;
clusterip:
提供乙個集群內部的虛擬ip以供pod訪問
用來對集群外暴露service, 你可以通過訪問集群內的每個nodeip:nodeport的方式訪問到對應的service後端的endpoint
#nodeport: 30080 nodeport可以自己指定, 如果沒有指定, k8s會自動生成乙個埠, 指定的好處是便於記憶, 壞處是容易衝突
externalname是 service 的特例。此模式主要面向執行在集群外部的服務，通過它可以將外部服務對映進k8s集群，且具備k8s內服務的一些特徵（如具備namespace等屬性），來為集群內部提供服務。此模式要求kube-dns的版本為1.7或以上。這種模式和前三種模式（除headless service）最大的不同是重定向依賴的是dns層次，而不是通過kube-proxy。
loadbalancer
這是將k8s集群部署在公有雲上的一種service型別, 會呼叫公有雲loadbalance介面
headless
headless service也是一種service，但不同的是會定義spec:clusterip: none，也就是不需要cluster ip的service。
apiversion: v1
kind: service
metadata:
namespace: default
spec:
selector:
release: canary
clusterip: none
ports:
- port: 80
targetport: 80
k8s 修改 k8s service 埠範圍
kubernetes 1.20.6 spring boot 2.5.1 在 k8s 中使用 nodeport 的時候，隨機分配的埠範圍預設在 30000 32767 之間。為了方便我們直接訪問位址，不需要加埠，可以擴大埠範圍，缺點是可能占用其它程式會使用的埠。下面的配置是基於 kubeadm 安裝的...
k8s service的四種型別
預設型別，每個node分配乙個集群內部的ip，內部可以互相訪問，外部無法訪問集群內部。基於clusterip，另外在每個node上開放乙個埠，可以從所有的位置訪問這個位址。基於nodeport，並且有云服務商在外部建立了乙個負載均衡層，將流量匯入到對應port。要收費的。將外部位址經過集群內部的再一...
對k8s service的一些理解
service是乙個抽象概念，定義了乙個服務的多個pod邏輯合集和訪問pod的策略，一般把service稱為微服務 舉個例子乙個a服務執行3個pod，b服務怎麼訪問a服務的pod，pod的ip都不是持久化的重啟之後就會有變化。這時候b服務可以訪問跟a服務繫結的service，service資訊是固定...