Kubernetes（k8s）的Service - 代理模式詳細介紹

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？ 
  

代理模式的分類 

Ⅰ、userspace 代理模式 

Ⅱ、iptables 代理模式 

Ⅲ、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 ： 不排隊調度

創建 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 。遇到這種情況，可以通過指定 Cluster IP(spec.clusterIP) 的值為 “None” 來創建 Headless Service 。這類 Service 並不會分配 Cluster IP， kubeproxy 不會處理它們，而且平台也不會為它們進行負載均衡和路由

apiVersion: v1
kind: Service
metadata:
  name: myapp-headless
  namespace: default
spec:
  selector:
    app: myapp
  clusterIP: "None"
  ports: 
  - port: 80
    targetPort: 80

解析

dig -t A myapp-headless.default.svc.cluster.local. @10.244.1.2

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

 

LoadBalancer 

loadBalancer 和 nodePort 其實是同一種方式。區別在於 loadBalancer 比 nodePort 多了一步，就是可以調用 cloud provider 去創建 LB 來向節點導流

ExternalName 

這種類型的 Service 通過返回 CNAME 和它的值，可以將服務映射到 externalName 字段的內容( 例如： hub.atguigu.com )。ExternalName Service 是 Service 的特例，它沒有 selector，也沒有定義任何的端口和 Endpoint。相反的，對於運行在集群外部的服務，它通過返回該外部服務的別名這種方式來提供服務

kind: Service
apiVersion: v1
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 層，而且不會進行代理或轉發