kubernetes 的 Services 的分類

kubernetes 的 Services

標籤（空格分隔）： kubernetes系列

---

• 一： kubernetes 的 Services

---

一： kubernetes 的 Services

1.1 Service 的概念

Kubernetes Service  定義了這樣一種抽象：一個  Pod  的邏輯分組，一種能夠訪問它們的策略 —— 一般稱爲微
服務。 這一組  Pod  可以被  Service  訪問到，一般是經過  Label Selector

Service可以提供負載均衡的能力，可是在使用上有如下限制：
只提供 4 層負載均衡能力，而沒有 7 層功能，但有時咱們可能須要更多的匹配規則來轉發請求，這點上 4 層
負載均衡是不支持的

1.2 Service 的類型

Service 在 K8s 中有如下四種類型

1.ClusterIp：默認類型，自動分配一個僅 Cluster 內部能夠訪問的虛擬 IP

2.NodePort：在 ClusterIP 基礎上爲 Service 在每臺機器上綁定一個端口，這樣就能夠經過 : NodePort 來訪
問該服務

3.LoadBalancer：在 NodePort 的基礎上，藉助 cloud provider 建立一個外部負載均衡器，並將請求轉發
到: NodePort

4.ExternalName：把集羣外部的服務引入到集羣內部來，在集羣內部直接使用。沒有任何類型代理被建立，
這隻有 kubernetes 1.7 或更高版本的 kube-dns 才支持

1.3 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？
  由於DNS 有緩存

1.4 代理模式的分類

1.4.1 userspace 代理模式

1.4.2 iptables 代理模式

1.4.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 ： 不排隊調度

1.5 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中

---

定義一個deployment

vim svc-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
---

kubectl apply -f svc-deploy.yaml

定義service 對外訪問：
vim myapp-service.yaml
---
apiVersion: v1
kind: Service
metadata:
  name: myapp
  namespace: default
spec:
  type: ClusterIP
  selector:
    app: myapp
    release: stabel
  ports:
    - name: http
      port: 80
      targetPort: 80
---

kubectl apply -f service.yaml

1.6 Headless Service

有時不須要或不想要負載均衡，以及單獨的 Service IP 。遇到這種狀況，能夠經過指定 Cluster
IP(spec.clusterIP) 的值爲 「None」 來建立 Headless Service 。這類 Service 並不會分配 Cluster IP， kube-
proxy 不會處理它們，並且平臺也不會爲它們進行負載均衡和路由

---

vim myapp-svc-headless.yaml
---
apiVersion: v1
kind: Service
metadata:
  name: myapp-headless
  namespace: default
spec:
  selector:
    app: myapp
  clusterIP: "None"
  ports:
  - port: 80
    targetPort: 80
---
kubectl apply -f myapp-svc-headless.yaml

kubectl get pods -n kube-system -o wide 

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

kubectl get pod -o wide 
---

1.7: NodePort

nodePort 的原理在於在 node 上開了一個端口，將向該端口的流量導入到 kube-proxy，而後由 kube-proxy 進
一步到給對應的 pod

---

vim nodeport.yaml
---
apiVersion: v1
kind: Service
metadata:
  name: myapp
  namespace: default
spec:
  type: NodePort
  selector:
    app: myapp
    release: stabel
  ports:
  - name: http
    port: 80
    targetPort: 80
---
kubectl apply -f nodeport.yaml

kubectl get svc

---

1.8 LoadBalancer

loadBalancer 和 nodePort 實際上是同一種方式。區別在於 loadBalancer 比 nodePort 多了一步，就是能夠調用
cloud provider 去建立 LB 來向節點導流

---

1.9 ExternalName

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

---

vim externalName.yaml
---
kind: Service
apiVersion: v1
metadata:
  name: my-service-1
  namespace: default
spec:
  type: ExternalName
  externalName: www.baidu.com
---

kubectl apply -f externalName.yaml

當查詢主機 my-service.defalut.svc.cluster.local ( SVC_NAME.NAMESPACE.svc.cluster.local )時，集羣的
DNS 服務將返回一個值 my.database.example.com 的 CNAME 記錄。訪問這個服務的工做方式和其餘的相
同，惟一不一樣的是重定向發生在 DNS 層，並且不會進行代理或轉發

dig -t A my-service-1.default.svc.cluster.local. @10.244.0.11