kubernetes Service

參考文獻：
https://blog.csdn.net/watermelonbig/article/details/79693962

A错负、k8s的Service定義了一個服務的訪問入口地址失乾，前端的應用通過這個入口地址訪問其背 后的一組由Pod副本組成的集群實例，來自外部的訪問請求被負載均衡到后端的各個容器應用上锚沸。
B、Service與其后端Pod副本集群之間則是通過Label Selector來實現(xiàn)對接的涕癣；
C哗蜈、而RC的作用相當于是保證Service的服務能力和服務質量始終處于預期的標準。Service 定義可以基于 POST 方式坠韩，請求 apiserver 創(chuàng)建新的實例距潘。
D、一個 Service 在 Kubernetes 中是一個 REST 對象只搁。
本文對Service的使用進行詳細說明音比，包括Service的負載均衡、外網(wǎng)訪問氢惋、DNS服務的搭建洞翩、Ingress7層路由機制等。

1焰望、Service 定義詳解

1.1 yaml格式的Service定義文件的完整內容

apiVersion: v1
kind: Service
matadata:
  name: string
  namespace: string
  labels:
  - name: string
  annotations:
  - name: string
spec:
  selector: []
  type: string
  clusterIP: string
  sessionAffinity: string
  ports:
  - name: string
    protocol: string
    port: int
    targetPort: int
    nodePort: int
  status:
    loadBalancer:
      ingress:
        ip: string
        hostname: string

1.2 對Service定義文件中各屬性的說明表

2 Service, RC, Pod 架構層次關系

image

3 VIP和Service 代理

3.1 kube-proxy

運行在每個Node上的kube-proxy進程其實就是一個智能的軟件負載均衡器枉圃，它會負責把對Service的請求轉發(fā)到后端的某個Pod實例上并在內部實現(xiàn)服務的負載均衡與會話保持機制功茴。Service不是共用一個負載均衡器的IP，而是被分配了一個全局唯一的虛擬IP地址孽亲，稱為Cluster IP痊土。
在Service的整個生命周期內，它的Cluster IP不會改變墨林。
kube-proxy 負責為 Service 實現(xiàn)了一種 VIP（虛擬 IP）的形式赁酝，而不是 ExternalName 的形式。
在k8s v1.2版本之前默認使用userspace提供vip代理服務旭等，從 Kubernetes v1.2 起酌呆，默認是使用 iptables 代理。

3.2 iptables 代理模式

這種模式搔耕，kube-proxy 會監(jiān)視 Kubernetes master 對 Service 對象和 Endpoints 對象的添加和移除隙袁。 對每個 Service，它會創(chuàng)建相關 iptables 規(guī)則弃榨，從而捕獲到達該 Service 的 clusterIP（虛擬 IP）和端口的請求菩收，進而將請求重定向到 Service 的一組 backend 中的某個上面。 對于每個 Endpoints 對象鲸睛，它也會創(chuàng)建 iptables 規(guī)則娜饵，這個規(guī)則會選擇一個 backend Pod。
默認的策略是官辈，隨機選擇一個 backend箱舞。 實現(xiàn)基于客戶端 IP 的會話親和性，可以將 service.spec.sessionAffinity 的值設置為 "ClientIP" （默認值為 "None"）拳亿。
和 userspace 代理類似晴股，網(wǎng)絡返回的結果是，任何到達 Service 的 IP:Port 的請求肺魁，都會被代理到一個合適的 backend电湘，不需要客戶端知道關于 Kubernetes、Service、或 Pod 的任何信息寂呛。 這應該比 userspace 代理更快怎诫、更可靠。然而昧谊，不像 userspace 代理，如果初始選擇的 Pod 沒有響應酗捌，iptables 代理能夠自動地重試另一個 Pod呢诬，所以它需要依賴 readiness probes。

image

4胖缤、 發(fā)布服務---type類型

對一些應用希望通過外部（Kubernetes 集群外部）IP 地址暴露 Service尚镰。
Kubernetes ServiceTypes 允許指定一個需要的類型的 Service，默認是 ClusterIP 類型哪廓。
Type 的取值以及行為如下：

• ClusterIP：通過集群的內部 IP 暴露服務狗唉，選擇該值，服務只能夠在集群內部可以訪問涡真，這也是默認的 ServiceType分俯。
• NodePort：通過每個 Node 上的 IP 和靜態(tài)端口（NodePort）暴露服務。NodePort 服務會路由到 ClusterIP 服務哆料，這個 ClusterIP 服務會自動創(chuàng)建缸剪。通過請求<NodeIP>:<NodePort>，可以從集群的外部訪問一個 NodePort 服務东亦。
• LoadBalancer：使用云提供商的負載局衡器杏节，可以向外部暴露服務。外部的負載均衡器可以路由到 NodePort 服務和 ClusterIP 服務典阵。
• ExternalName：通過返回 CNAME 和它的值奋渔，可以將服務映射到 externalName 字段的內容（例如， foo.bar.example.com）壮啊。 沒有任何類型代理被創(chuàng)建嫉鲸，這只有 Kubernetes 1.7 或更高版本的 kube-dns 才支持。

k8s中有3種IP地址：

• Node IP： Node節(jié)點的IP地址歹啼，這是集群中每個節(jié)點的物理網(wǎng)卡的IP地址充坑；
• Pod IP： Pod的IP地址，這是Docker Engine根據(jù)docker0網(wǎng)橋的IP地址段進行分配的染突，通常是一個虛擬的二層網(wǎng)絡捻爷；
• Cluster IP：Service 的IP地址，這也是一個虛擬的IP份企，但它更像是一個“偽造”的IP地址也榄，因為它沒有一個實體網(wǎng)絡對象，所以無法響應ping命令。它只能結合Service Port組成一個具體的通信服務端口甜紫，單獨的Cluster IP不具備TCP/IP通信的基礎降宅。

在k8s集群之內，Node IP網(wǎng)囚霸、Pod IP網(wǎng)與Cluster IP網(wǎng)之間的通信采用的是k8s自己設計的一種編程實現(xiàn)的特殊的路由規(guī)則腰根，不同于常見的IP路由實現(xiàn)

5、 服務發(fā)現(xiàn)

Kubernetes 支持2種基本的服務發(fā)現(xiàn)模式 —— 環(huán)境變量和 DNS拓型。
環(huán)境變量
當 Pod 運行在 Node 上额嘿，kubelet 會為每個活躍的 Service 添加一組環(huán)境變量。 它同時支持 Docker links兼容 變量劣挫、簡單的 {SVCNAME}_SERVICE_HOST 和 {SVCNAME}_SERVICE_PORT 變量册养，這里 Service 的名稱需大寫，橫線被轉換成下劃線压固。
舉個例子球拦，一個名稱為 "redis-master" 的 Service 暴露了 TCP 端口 6379，同時給它分配了 Cluster IP 地址 10.0.0.11帐我，這個 Service 生成了如下環(huán)境變量：

REDIS_MASTER_SERVICE_HOST=10.0.0.11
REDIS_MASTER_SERVICE_PORT=6379
REDIS_MASTER_PORT=tcp://10.0.0.11:6379
REDIS_MASTER_PORT_6379_TCP=tcp://10.0.0.11:6379
REDIS_MASTER_PORT_6379_TCP_PROTO=tcp
REDIS_MASTER_PORT_6379_TCP_PORT=6379
REDIS_MASTER_PORT_6379_TCP_ADDR=10.0.0.11

這意味著需要有順序的要求 —— Pod 想要訪問的任何 Service 必須在 Pod 自己之前被創(chuàng)建坎炼，否則這些環(huán)境變量就不會被賦值。DNS 并沒有這個限制拦键。
DNS
一個強烈推薦的集群插件 是 DNS 服務器点弯。 DNS 服務器監(jiān)視著創(chuàng)建新 Service 的 Kubernetes API，從而為每一個 Service 創(chuàng)建一組 DNS 記錄矿咕。 如果整個集群的 DNS 一直被啟用抢肛，那么所有的 Pod 應該能夠自動對 Service 進行名稱解析。
例如碳柱，有一個名稱為 "my-service" 的 Service捡絮，它在 Kubernetes 集群中名為 "my-ns" 的 Namespace 中，為 "my-service.my-ns" 創(chuàng)建了一條 DNS 記錄莲镣。 在名稱為 "my-ns" 的 Namespace 中的 Pod 應該能夠簡單地通過名稱查詢找到 "my-service"福稳。 在另一個 Namespace 中的 Pod 必須限定名稱為 "my-service.my-ns"。 這些名稱查詢的結果是 Cluster IP瑞侮。
Kubernetes 也支持對端口名稱的 DNS SRV（Service）記錄的圆。 如果名稱為 "my-service.my-ns" 的 Service 有一個名為 "http" 的 TCP 端口，可以對 "_http._tcp.my-service.my-ns" 執(zhí)行 DNS SRV 查詢半火，得到 "http" 的端口號越妈。
Kubernetes DNS 服務器是唯一的一種能夠訪問 ExternalName 類型的 Service 的方式。 更多信息可以查看DNS Pod 和 Service钮糖。
Kubernetes 從 1.3 版本起梅掠， DNS 是內置的服務酌住，通過插件管理器 集群插件 自動被啟動。Kubernetes DNS 在集群中調度 DNS Pod 和 Service 阎抒，配置 kubelet 以通知個別容器使用 DNS Service 的 IP 解析 DNS 名字酪我。

6、 Service的基本用法

????一般來說且叁，對外提供服務的應用程序需要通過某種機制來實現(xiàn)都哭，對于容器應用最簡便的方式就是通過TCP/IP機制及監(jiān)聽IP和端口號來實現(xiàn)。
創(chuàng)建一個基本功能的Service
(1) 例如逞带，我們定義一個提供web服務的RC欺矫，由兩個tomcat容器副本組成，每個容器通過containerPort設置提供服務號為8080：
webapp-rc.yaml

apiVersion: v1
kind: ReplicationController
metadata:
  name: webapp
spec:
  replicas: 2
  template:
    metadata:
      name: webapp
      labels:
        app: webapp
    spec:
      containers:
      - name: webapp
        image: tomcat
        ports:
        - containerPort: 8080

創(chuàng)建該RC

kubectl create -f webapp-rc.yaml 

獲取Pod的IP地址：

[root@master service]# kubectl get pods -l app=webapp -o yaml| grep podIP | grep -v cni
    podIP: 192.168.2.94
    podIP: 192.168.1.73
[root@master service]# 

直接通過這兩個Pod的IP地址和端口號訪問Tomcat服務：

[root@master service]# curl 192.168.2.94:8080



<!DOCTYPE html>
<html lang="en">
    <head>
        <meta charset="UTF-8" />
        <title>Apache Tomcat/8.5.34</title>
        <link href="favicon.ico" rel="icon" type="image/x-icon" />
        <link href="favicon.ico" rel="shortcut icon" type="image/x-icon" />
        <link href="tomcat.css" rel="stylesheet" type="text/css" />
    </head>
........

說明可以直接通過podIP進行訪問
直接通過Pod的IP地址和端口號可以訪問容器內的應用服務掰担，但是Pod的IP地址是不可靠的汇陆，例如Pod所在的Node發(fā)生故障怒炸，Pod將被k8s重新調度到另一臺Node带饱。Pod的IP地址將發(fā)生變化，更重要的是阅羹，如果容器應用本身是分布式的部署方式勺疼，通過多個實例共同提供服務，就需要在這些實例的前端設置一個負載均衡器來實現(xiàn)請求的分發(fā)捏鱼。kubernetes中的Service就是設計出來用于解決這些問題的核心組件执庐。

(2) 為了讓客戶端應用能夠訪問到兩個Tomcat Pod 實例，需要創(chuàng)建一個Service來提供服務
k8s提供了一種快速的方法导梆，即通過kubectl expose命令來創(chuàng)建：

[root@master service]# kubectl expose deployment webapp
service/webapp exposed

查看新創(chuàng)建的Service可以看到系統(tǒng)為它分配了一個虛擬的IP地址（clusterIP）轨淌，而Service所需的端口號則從Pod中的containerPort復制而來：

[root@master service]# kubectl get svc
NAME         TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)    AGE
kubernetes   ClusterIP   10.96.0.1      <none>        443/TCP    6d10h
webapp       ClusterIP   10.103.4.220   <none>        8080/TCP   5s
[root@master service]# 

接下來，我們就可以通過Service的IP地址和Service的端口號訪問該Service了：

image

這里看尼，對Service地址10.103.4.220:8080的訪問被自動負載分發(fā)到了后端兩個Pod之一递鹉。

(3) 除了使用kubectl expose命令創(chuàng)建Service，我們也可以通過配置文件定義Service藏斩，再通過kubectl create命令進行創(chuàng)建
例如前面的webapp就用躏结，我們可以設置一個Service：
webapp-svc.yaml

apiVersion: v1
kind: Service
metadata:
  name: webapp
spec:
  ports:
  - port: 8081
    targetPort: 8080
  selector:
    app: webapp

本例中ports定義部分指定了Service所需的虛擬端口號為8081，由于與Pod容器端口號8080不一樣狰域，所以需要在通過targetPort來指定后端Pod的端口
selector定義部分設置的是后端Pod所擁有的label: app=webapp
(4) 目前kubernetes提供了兩種負載分發(fā)策略：RoundRobin和SessionAffinity

• RoundRobin：輪詢模式媳拴，即輪詢將請求轉發(fā)到后端的各個Pod上
• SessionAffinity：基于客戶端IP地址進行會話保持的模式，第一次客戶端訪問后端某個Pod兆览，之后的請求都轉發(fā)到這個Pod上
  默認是RoundRobin模式屈溉。

7、 多端口Service

有時候抬探，一個容器應用提供多個端口服務语婴，可以按下面這樣定義：

apiVersion: v1
kind: Service
metadata:
  name: webapp
spec:
  ports:
  - name: web
    port: 8080
    targetPort: 8080
  - name: management
    port: 8005
    targetPort: 8005
  selector:
    app: webapp 

另一個例子是兩個端口使用了不同的4層協(xié)議，即TCP和UDP

apiVersion: v1
kind: Service
metadata:
  name: kube-dns
  namespace: kube-system
  labels:
    k8s-app: kube-dns
    kubernetes.io/cluster-service: "true"
    kubernetes.io/name: "KubeDNS"
spec:
  selector:
    k8s-app: kube-dns
  clusterIP: 10.10.10.100
  ports:
  - name: dns
    port: 53
    protocol: UDP
  - name: dns-tcp
    port: 53
    protocol: TCP

8、 Headless Service

有時不需要或不想要負載均衡砰左，以及單獨的 Service IP匿醒。 遇到這種情況，可以通過指定 Cluster IP（spec.clusterIP）的值為 "None" 來創(chuàng)建 Headless Service缠导。
這個選項允許開發(fā)人員自由尋找他們自己的方式廉羔，從而降低與 Kubernetes 系統(tǒng)的耦合性。 應用仍然可以使用一種自注冊的模式和適配器僻造，對其它需要發(fā)現(xiàn)機制的系統(tǒng)能夠很容易地基于這個 API 來構建憋他。
對這類 Service 并不會分配 Cluster IP，kube-proxy 不會處理它們髓削，而且平臺也不會為它們進行負載均衡和路由竹挡。僅依賴于Label Selector將后端的Pod列表返回給調用的客戶端。

apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  ports:
  - port: 80
  clusterIP: None
  selector:
    app: nginx

這樣立膛，Service就不再具有一個特定的ClusterIP地址揪罕，對其進行訪問將獲得包含Label"app=nginx"的全部Pod列表，然后客戶端程序自行決定如何處理這個Pod列表宝泵。
例如, StatefulSet就是使用Headless Service為客戶端返回多個服務地址好啰。
Lable Secector：
配置 Selector：對定義了 selector 的 Headless Service，Endpoint 控制器在 API 中創(chuàng)建了 Endpoints 記錄儿奶，并且修改 DNS 配置返回 A 記錄（地址）框往，通過這個地址直接到達 Service 的后端 Pod上。
不配置 Selector：對沒有定義 selector 的 Headless Service闯捎，Endpoint 控制器不會創(chuàng)建 Endpoints 記錄椰弊。

9、 外部服務Service——沒有 selector 的 Service

在某些環(huán)境中瓤鼻，應用系統(tǒng)需要將一個外部數(shù)據(jù)庫用為后端服務進行連接秉版，或將另一個集群或Namespace中的服務作為服務的后端，這時可以通過創(chuàng)建一個無Label Selector的Service實現(xiàn)：

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80

Servcie 抽象了該如何訪問 Kubernetes Pod娱仔，但也能夠抽象其它類型的 backend沐飘，例如：
希望在生產環(huán)境中使用外部的數(shù)據(jù)庫集群。
希望服務指向另一個 Namespace 中或其它集群中的服務牲迫。
正在將工作負載同時轉移到 Kubernetes 集群和運行在 Kubernetes 集群之外的 backend耐朴。
由于這個 Service 沒有 selector，就不會創(chuàng)建相關的 Endpoints 對象盹憎∩盖停可以手動將 Service 映射到指定的 Endpoints：

kind: Endpoints
apiVersion: v1
metadata:
  name: my-service
subsets:
  - addresses:
      - ip: 1.2.3.4
    ports:
      - port: 9376

注意：Endpoint IP 地址不能是 loopback（127.0.0.0/8）、 link-local（169.254.0.0/16）陪每、或者 link-local 多播（224.0.0.0/24）影晓。
訪問沒有 selector 的 Service镰吵，與有 selector 的 Service 的原理相同。請求將被路由到用戶定義的 Endpoint（該示例中為 1.2.3.4:9376）挂签。
ExternalName Service 是 Service 的特例疤祭，它沒有 selector，也沒有定義任何的端口和 Endpoint饵婆。 相反地勺馆，對于運行在集群外部的服務，它通過返回該外部服務的別名這種方式來提供服務侨核。

kind: Service
apiVersion: v1
metadata:
  name: my-service
  namespace: prod
spec:
  type: ExternalName
  externalName: my.database.example.com

當查詢主機 my-service.prod.svc.CLUSTER時草穆，集群的 DNS 服務將返回一個值為 my.database.example.com 的 CNAME 記錄。 訪問這個服務的工作方式與其它的相同搓译，唯一不同的是重定向發(fā)生在 DNS 層悲柱，而且不會進行代理或轉發(fā)。 如果后續(xù)決定要將數(shù)據(jù)庫遷移到 Kubernetes 集群中些己，可以啟動對應的 Pod豌鸡，增加合適的 Selector 或 Endpoint，修改 Service 的 type轴总。

10直颅、集群外部訪問Pod或Service的方法

由于Pod和Service是k8s集群范圍內的虛擬概念博个，所以集群外的客戶端系統(tǒng)無法通過Pod的IP地址或者Service的虛擬IP地址和虛擬端口號訪問到它們怀樟。
為了讓外部客戶端可以訪問這些服務，可以將Pod或Service的端口號映射到宿主機盆佣，以使得客戶端應用能夠通過物理機訪問容器應用往堡。

10.1、將容器應用的端口號映射到物理機

(1) 通過設置容器級別的hostPort共耍，將容器應用的端口號映射到物理機上
文件pod-hostport.yaml

apiVersion: v1
kind: Pod
metadata:
  name: webapp
  labels:
    app: webapp
spec:
  containers:
  - name: webapp
    image: tomcat
    ports:
    - containerPort: 8080
      hostPort: 8081

hostPort的值可以跟containerPort的值一樣
通過kubectl create創(chuàng)建這個Pod：

kubectl create -f pod-hostport.yaml

通過物理機的IP地址和8081端口號訪問Pod內的容器服務：

curl 172.16.91.137:8081

(2) 通過設置Pod級別的hostNetwork=true虑灰，該Pod中所有容器的端口號都將被直接映射到物理機上
設置hostWork=true時需要注意，在容器的ports定義部分如果不指定hostPort痹兜，則默認hostPort等于containerPort穆咐，如果指定了hostPort，則hostPort必須等于containerPort的值字旭。
文件pod-hostnetwork.yaml

apiVersion: v1
kind: Pod
metadata:
  name: webapp-hostnetwork
  labels:
    app: webapp-hostnetwork
spec:
  hostNetwork: true
  containers:
  - name: webapp-hostnetwork
    image: tomcat
    imagePullPolicy: Never
    ports:
    - containerPort: 8080

創(chuàng)建這個Pod：

kubectl create -f pod-hostnetwork.yaml

[root@master pod]# kubectl get pod -owide
NAME                      READY   STATUS    RESTARTS   AGE   IP              NODE     NOMINATED NODE
webapp-77df6fff64-dhczl   1/1     Running   1          14h   192.168.2.95    slave2   <none>
webapp-77df6fff64-kpl6w   1/1     Running   1          14h   192.168.1.74    slave1   <none>
webapp-hostnetwork        1/1     Running   0          7s    172.16.91.136   slave1   <none>

通過物理機的IP地址和8080端口訪問Pod的容器服務

curl slave1:8080  

10.2 將Service的端口號映射到物理機

(1) 通過設置nodePort映射到物理機对湃，同時設置Service的類型為NodePort
文件webapp-svc-nodeport.yaml

apiVersion: v1
kind: Service
metadata:
  name: webapp-nodeport
spec:
  type: NodePort
  ports:
  - port: 8090
    targetPort: 8080
    nodePort: 8090
  selector:
    app: webapp

創(chuàng)建這個Service：

kubectl create -f webapp-svc-nodeport.yaml

[root@master service]# kubectl get svc
NAME              TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)          AGE
kubernetes        ClusterIP   10.96.0.1      <none>        443/TCP          7d1h
webapp            ClusterIP   10.103.4.220   <none>        8080/TCP         14h
webapp-nodeport   NodePort    10.99.248.88   <none>        8090:31090/TCP   6s

通過物理機的IP和端口訪問：(4種方式訪問)

#Service的IP，即ClusterIP
curl 10.99.248.88:8090 
#master的IP遗淳，
curl master:31090 
curl slave1:31090 
curl slave2:31090 

也就是說拍柒，只要是nodePort端口，就會在物理機上開始監(jiān)聽端口號

image

image

(2) 通過設置LoadBalancer映射到云服務商提供的LoadBalancer地址
這種用法僅用于在公有云服務提供商的云平臺上設置Service的場景脂男。
status.loadBalancer.ingress.ip設置的146.148.47.155為云服務商提供的負載均衡器的IP地址。對該Service的訪問請求將會通過LoadBalancer轉發(fā)到后端的Pod上种呐，負載分發(fā)的實現(xiàn)方式依賴云服務商提供的LoadBalancer的實現(xiàn)機制宰翅。

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: Myapp
  ports:
  - protocol: TCP
    port: 80
    targetPort: 9376
    nodePort: 30061
  clusterIP: 10.0.171.239
  loadBalancerIP: 78.11.24.19
  type: LoadBalancer
status:
  loadBalancer:
    ingree:
    - ip: 146.148.47.155