Service 的概念
Kubernetes Service定義了這樣一種抽象:一個Pod的邏輯分組,一種可以訪問它們的策略 —— 通常稱爲微服務。這一組Pod能夠被Service訪問到,通常是通過Label Selector
Service能夠提供負載均衡的能力,但是在使用上有以下限制:
只提供 4 層負載均衡能力,而沒有 7 層功能,但有時我們可能需要更多的匹配規則來轉發請求,這點上 4 層負載均衡是不支持的
Service 的類型
Service 在 K8s 中有以下四種類型
ClusterIp:默認類型,自動分配一個僅 Cluster 內部可以訪問的虛擬 IP
NodePort:在 ClusterIP 基礎上爲 Service 在每臺機器上綁定一個端口,這樣就可以通過: NodePort 來訪問該服務
LoadBalancer:在 NodePort 的基礎上,藉助 cloud provider 創建一個外部負載均衡器,並將請求轉發到: NodePort
ExternalName:把集羣外部的服務引入到集羣內部來,在集羣內部直接使用。沒有任何類型代理被創建,這隻有 kubernetes 1.7 或更高版本的 kube-dns 才支持
VIP 和 Service 代理
在 Kubernetes 集羣中,每個 Node 運行一個kube-proxy進程。kube-proxy負責爲Service實現了一種VIP(虛擬 IP)的形式,而不是ExternalName的形式。在 Kubernetes v1.0 版本,代理完全在 userspace。在Kubernetes v1.1 版本,新增了 iptables 代理,但並不是默認的運行模式。從 Kubernetes v1.2 起,默認就是iptables 代理。在 Kubernetes v1.8.0-beta.0 中,添加了 ipvs 代理
在 Kubernetes 1.14 版本開始默認使用ipvs 代理
在 Kubernetes v1.0 版本,Service是 “4層”(TCP/UDP over IP)概念。在 Kubernetes v1.1 版本,新增了Ingress API(beta 版),用來表示 “7層”(HTTP)服務
!爲何不使用 round-robin DNS?
代理模式的分類
1、userspace 代理模式
2、iptables 代理模式
3、ipvs 代理模式
這種模式,kube-proxy 會監視 Kubernetes Service對象和Endpoints,調用netlink接口以相應地創建ipvs 規則並定期與 Kubernetes Service對象和Endpoints對象同步 ipvs 規則,以確保 ipvs 狀態與期望一致。訪問服務時,流量將被重定向到其中一個後端 Pod
與 iptables 類似,ipvs 於 netfilter 的 hook 功能,但使用哈希表作爲底層數據結構並在內核空間中工作。這意味着 ipvs 可以更快地重定向流量,並且在同步代理規則時具有更好的性能。此外,ipvs 爲負載均衡算法提供了更多選項,例如:
rr:輪詢調度
lc:最小連接數
dh:目標哈希
sh:源哈希
sed:最短期望延遲
nq:不排隊調度
ClusterIP
clusterIP 主要在每個 node 節點使用 iptables,將發向 clusterIP 對應端口的數據,轉發到 kube-proxy 中。然後 kube-proxy 自己內部實現有負載均衡的方法,並可以查詢到這個 service 下對應 pod 的地址和端口,進而把數據轉發給對應的 pod 的地址和端口
爲了實現圖上的功能,主要需要以下幾個組件的協同工作:
apiserver 用戶通過kubectl命令向apiserver發送創建service的命令,apiserver接收到請求後將數據存儲到etcd中
kube-proxy kubernetes的每個節點中都有一個叫做kube-porxy的進程,這個進程負責感知service,pod的變化,並將變化的信息寫入本地的iptables規則中
iptables 使用NAT等技術將virtualIP的流量轉至endpoint中
創建 myapp-deploy.yaml 文件
apiVersion: apps/ v1
kind: Deployment
metadata:
name: myapp- deploy
namespace: default
spec:
replicas: 3
selector:
matchLabels:
app: myapp
release: stabel
template:
metadata:
labels:
app: myapp
release: stabel
env: test
spec:
containers:
- name: myapp
image: wangyanglinux/ myapp: v2
imagePullPolicy: IfNotPresent
ports:
- name: http
containerPort: 80
創建 Service 信息
apiVersion: v1
kind: Service
metadata:
name: myapp
namespace: default
spec:
type: ClusterIP
selector:
app: myapp
release: stabel
ports:
- name: http
port: 80
targetPort: 80
Headless Service
有時不需要或不想要負載均衡,以及單獨的 Service IP 。遇到這種情況,可以通過指定 ClusterIP(spec.clusterIP) 的值爲 “None” 來創建 Headless Service 。這類 Service 並不會分配 Cluster IP, kube-proxy 不會處理它們,而且平臺也不會爲它們進行負載均衡和路由
apiVersion: v1
kind: Service
metadata:
name: myapp- headless
namespace: default
spec:
selector:
app: myapp
clusterIP: "None"
ports:
- port: 80
targetPort: 80
[ root@k8s - master ~ ] # dig - t A myapp- headless. default . svc. cluster. local. @10 .96 .0 .10
NodePort
nodePort 的原理在於在 node 上開了一個端口,將向該端口的流量導入到 kube-proxy,然後由 kube-proxy 進一步到給對應的 pod
apiVersion: v1
kind: Service
metadata:
name: myapp
namespace: default
spec:
type: NodePort
selector:
app: myapp
release: stabel
ports:
- name: http
port: 80
targetPort: 80
查詢流程
iptables - t nat - nvL KUBE- NODEPORTS
LoadBalancer
loadBalancer 和 nodePort 其實是同一種方式。區別在於 loadBalancer 比 nodePort 多了一步,就是可以調用cloud provider 去創建 LB 來向節點導流
ExternalName
這種類型的 Service 通過返回 CNAME 和它的值,可以將服務映射到 externalName 字段的內容( 例如:hub.atguigu.com )。ExternalName Service 是 Service 的特例,它沒有 selector,也沒有定義任何的端口和Endpoint。相反的,對於運行在集羣外部的服務,它通過返回該外部服務的別名這種方式來提供服務
apiVersion: v1
kind: Service
metadata:
name: my- service- 1
namespace: default
spec:
type: ExternalName
externalName: hub. atguigu. com
當查詢主機 my-service.defalut.svc.cluster.local ( SVC_NAME.NAMESPACE.svc.cluster.local )時,集羣的DNS 服務將返回一個值 my.database.example.com 的 CNAME 記錄。訪問這個服務的工作方式和其他的相同,唯一不同的是重定向發生在 DNS 層,而且不會進行代理或轉發