02.Service · k8s原理與實踐

[TOC] > 官網：https://kubernetes.io/docs/concepts/services-networking/service/ # 介紹 * RC、RS和Deployment保障支撐服務Pod的數量 * Service解決訪問Pod的問題 * 每個Service對應集群內部一個有效虛擬IP * 集群內部通過虛擬IP訪問一個服務 * K8s內部負載均衡為Kube-proxy * 每個節點都有一個Kube-proxy * Service是由標簽選擇器定義的一組pods * `Service`能將一個接收`port`映射到任意的`targetPort` * 默認`Service`的`targetPort`和`port`的值相同 * 支持多個端口、協議可以相同也可以不相同 ![](https://img.kancloud.cn/af/19/af19d85a1bd730016f5254ead0e9719b_652x343.png) # 舉例 ## 有selector的Service 一組`Pod`對外暴露6379端口，標簽為`app=MyRedis` ```yaml apiVersion: v1 kind: Service metadata: name: redis-master spec: selector: app: MyRedis ports: - protocol: TCP port: 80 targetPort: 6379 ``` > 通過上述配置創建名稱為“redis-master”的`Service`對象，將請求代理到使用TCP端口6379，并且標簽為`app=MyRedis`的`Pod` ## 無selector的Service Service常規用法是抽象化對·Pod·的訪問，也可以抽象化其他種類的后端: * 在生產環和測試環境中使用不同的數據庫集群 * 服務指向另一個命名空間中或其他集群中的服務 * 在K8s集群中運行部分后端，用于評估將工作負載遷移到K8S ``` apiVersion: v1 kind: Service metadata: name: redis-master spec: ports: - protocol: TCP port: 80 targetPort: 6379 ``` 由于定義的`Service`沒有selector，所以不會自動創建相應的Endpoint對象，需要手動添加Endpoint對象，將服務手動映射到運行該服務的網絡地址和端口 ```yaml apiVersion: v1 kind: Endpoints metadata: name: redis-master subsets: - addresses: - ip: 192.168.136.200 ports: - port: 6379 ``` > * 端點 IPs 不可以是環回( IPv4 的 127.0.0.0/8 , IPv6 的 ::1/128 ） > * 不可以是本地鏈接（IPv4 的 169.254.0.0/16 和 224.0.0.0/24，IPv6 的 fe80::/64) > * 端點 IP 地址不能是其他 Kubernetes Services 的群集 IP，因為kube-proxy不支持將虛擬 IP 作為目標訪問沒有 selector 的`Service`，與有 selector 的`Service`的原理相同。請求將被路由到用戶定義的 Endpoint， YAML中為:`192.168.136.200:6379`(TCP) ### ExternalName Service * ExternalName `Service`無Selector，也沒有用DNS名稱代替，是`Service`的特例 * ExternalName類型的`Service`將服務映射到DNS名稱，如`redis-service`，可以通過`spec.externalNmae`參數指定服務 #### 舉例將`prod`名稱空間中的`redis-master`服務映射到`my.redis.pmk8s.com` ```yaml apiVersion: v1 kind: Service metadata: name: redis-master namespace: prod spec: type: ExternalName externalName: my.redis.pmk8s.com ``` > ExternalName 接受 IPv4 地址字符串，但作為包含數字的 DNS 名稱，而不是 IP 地址。類似于 IPv4 地址的外部名稱不能由 CoreDNS 或 ingress-nginx 解析，因為外部名稱旨在指定規范的 DNS 名稱。要對 IP 地址進行硬編碼，需要使用`headless Services` 當查找主機`redis-service.prod.svc.cluster.local`時，群集DNS服務返回`CNAME`記錄，其值為`my.redis.pmk8s.com`。訪問`redis-service`的方式與其他服務的方式相同，但主要區別在于重定向發生在 DNS 級別，而不是通過代理或轉發 # Service代理 kube-proxy負責為`Service`實現了一種VIP（虛擬IP）的形式，而不是ExternalName的形式 ## userspace代理模式 ## iptables代理模式 ## IPVS代理模式 # 多端口Service * 定義多個端口時，必須提供端口名稱 * 端口名稱只能包含小寫字母、數字字符和`-` * 端口號名稱必須以字母數字字符開頭和結尾 ``` apiVersion: v1 kind: Service metadata: name: redis-master spec: selector: app: MyRedis ports: - name: http protocol: TCP port: 80 targetPort: 6379 - name: https protocol: TCP port: 443 targetPort: 6380 ``` # 選擇自己的IP地址 * 在` Service`創建請求中，通過設置`spec.clusterIP`字段指定自己的集群IP地址 * 指定的IP地址必須合法，并且這個IP地址在`service-cluster-ip-range` CIDR范圍內 ``` apiVersion: v1 kind: Service metadata: name: redis-master spec: selector: app: MyRedis clusterIP: 10.96.0.13 ports: - name: http protocol: TCP port: 80 targetPort: 6379 - name: https protocol: TCP port: 443 targetPort: 6380 ``` # 服務發現 K8s支持環境變量和DNS兩種服務發現模式 * 環境變量 * 當`Pod`運行在`Node`上，kubelet 會為每個活躍的`Service`添加一組環境變量 * 它同時支持 Docker links兼容變量、簡單的`{SVCNAME}_SERVICE_HOST`和`{SVCNAME}_SERVICE_PORT`變量 * 這里`Service`的名稱需大寫，橫線被轉換成下劃線。例子，一個名稱為`"redis-master"`的 Service 暴露了 TCP 端口 6379，同時給它分配了 Cluster IP 地址 10.96.0.13，這個 Service 生成了如下環境變量： ```shell REDIS_MASTER_SERVICE_HOST=10.96.0.13 REDIS_MASTER_SERVICE_PORT=6379 REDIS_MASTER_PORT=tcp://10.96.0.13:6379 REDIS_MASTER_PORT_6379_TCP=tcp://10.96.0.13:6379 REDIS_MASTER_PORT_6379_TCP_PROTO=tcp REDIS_MASTER_PORT_6379_TCP_PORT=6379 REDIS_MASTER_PORT_6379_TCP_ADDR=10.96.0.13 ``` > 通過環境變量訪問服務的Pod時，服務創建必須在客戶端Pod出現之前創建好 * DNS * 使用[附加組件](https://kubernetes.io/docs/concepts/cluster-administration/addons/)為Kubernetes集群設置DNS服務。 * 支持群集的DNS服務器（例如CoreDNS）監視 Kubernetes API 中的新服務，并為每個服務創建一組 DNS 記錄 * 如果在整個群集中都啟用了 DNS，則所有 Pod 都應該能夠通過其 DNS 名稱自動解析服務 * Kubernetes DNS 服務器是唯一的一種能夠訪問`ExternalName`類型的 Service 的方式 * Kubernetes 還支持命名端口的 DNS SRV（服務）記錄例如，如果您在 Kubernetes 命名空間`"my-ns"`中有一個名為`"redis-master"`的服務，則控制平面和DNS服務共同為`"redis-master.my-ns"`創建 DNS 記錄。`"my-ns"`命名空間中的Pod應該能夠通過簡單地對`redis-master`進行名稱查找來找到它（`"redis-master.my-ns"`也可以工作）。其他命名空間中的Pod必須將名稱限定為`redis-master.my-ns`。這些名稱將解析為為服務分配的群集IP。如果`"redis-master.my-ns"`服務具有名為`"http"`　的端口，且協議設置為`TCP`，則可以對`_http._tcp.redis-master.my-ns`執行DNS SRV查詢查詢以發現該端口號,`"http"`以及IP地址 # Headless Services 有時不需要或不想要負載均衡，以及單獨的 Service IP。遇到這種情況，可以通過指定 Cluster IP（`spec.clusterIP`）的值為`"None"`來創建`Headless`Service。您可以使用 headless Service 與其他服務發現機制進行接口，而不必與 Kubernetes 的實現捆綁在一起。對這 headless`Service`并不會分配 Cluster IP，kube-proxy 不會處理它們，而且平臺也不會為它們進行負載均衡和路由。 DNS 如何實現自動配置，依賴于`Service`是否定義了 selecto # 發布服務 * Kubernetes`ServiceTypes`允許指定一個需要的類型的 Service，默認是`ClusterIP`類型 * `Type`的取值以及行為如下： * `ClusterIP`：通過集群的內部 IP 暴露服務，選擇該值，服務只能夠在集群內部可以訪問，這也是默認的`ServiceType`。 \*[`NodePort`](https://kubernetes.io/zh/docs/concepts/services-networking/service/#nodeport)：通過每個 Node 上的 IP 和靜態端口（`NodePort`）暴露服務。 * `NodePort`服務會路由到`ClusterIP`服務，這個`ClusterIP`服務會自動創建。通過請求`<NodeIP>:<NodePort>`，可以從集群的外部訪問一個`NodePort`服務。 * `LoadBalancer`：使用云提供商的負載局衡器，可以向外部暴露服務。外部的負載均衡器可以路由到`NodePort`服務和`ClusterIP`服務。 * `ExternalName`：通過返回`CNAME`和它的值，可以將服務映射到`externalName`字段的內容（例如，`foo.bar.example.com`）。沒有任何類型代理被創建 ## NodePort類型如果將`type`字段設置為`NodePort`，則 Kubernetes 控制平面將在`--service-node-port-range`標志指定的范圍內分配端口（默認值：30000-32767）。每個節點將那個端口（每個節點上的相同端口號）代理到您的服務中。您的服務在其`.spec.ports[*].nodePort`字段中要求分配的端口。如果您想指定特定的IP代理端口，則可以將 kube-proxy 中的`--nodeport-addresses`標志設置為特定的IP塊。從Kubernetes v1.10開始支持此功能。該標志采用逗號分隔的IP塊列表（例如10.0.0.0/8、192.0.2.0/25）來指定 kube-proxy 應該認為是此節點本地的IP地址范圍。例如，如果您使用`--nodeport-addresses=127.0.0.0/8`標志啟動 kube-proxy，則 kube-proxy 僅選擇 NodePort Services 的環回接口。`--nodeport-addresses`的默認值是一個空列表。這意味著 kube-proxy 應該考慮 NodePort 的所有可用網絡接口。（這也與早期的Kubernetes版本兼容）。如果需要特定的端口號，則可以在`nodePort`字段中指定一個值。控制平面將為您分配該端口或向API報告事務失敗。這意味著您需要自己注意可能發生的端口沖突。您還必須使用有效的端口號，該端口號在配置用于NodePort的范圍內。使用 NodePort 可以讓您自由設置自己的負載平衡解決方案，配置 Kubernetes 不完全支持的環境，甚至直接暴露一個或多個節點的IP。需要注意的是，Service 能夠通過`<NodeIP>:spec.ports[*].nodePort`和`spec.clusterIp:spec.ports[*].port`而對外可見 ## LoadBalancer 類型使用支持外部負載均衡器的云提供商的服務，設置`type`的值為`"LoadBalancer"`，將為`Service`提供負載均衡器。負載均衡器是異步創建的，關于被提供的負載均衡器的信息將會通過`Service`的`status.loadBalancer`字段被發布出去外部IP，如轉到外部的DB存儲 ```yaml apiVersion: v1 kind: Service metadata: name: redis-master spec: selector: app: MyApp ports: - protocol: TCP port: 80 targetPort: 6379 clusterIP: 10.0.171.239 loadBalancerIP: 78.11.24.19 type: LoadBalancer status: loadBalancer: ingress: - ip: 146.148.47.155 ``` 來自外部負載均衡器的流量將直接打到 backend`Pod`上，不過實際它們是如何工作的，這要依賴于云提供商。在這些情況下，將根據用戶設置的`loadBalancerIP`來創建負載均衡器。某些云提供商允許設置`loadBalancerIP`。如果沒有設置`loadBalancerIP`，將會給負載均衡器指派一個臨時 IP。如果設置了`loadBalancerIP`，但云提供商并不支持這種特性，那么設置的`loadBalancerIP`值將會被忽略掉。 ## 外部 IP 如果外部的 IP 路由到集群中一個或多個 Node 上，Kubernetes`Service`會被暴露給這些`externalIPs`。通過外部 IP（作為目的 IP 地址）進入到集群，打到`Service`的端口上的流量，將會被路由到`Service`的 Endpoint 上。`externalIPs`不會被 Kubernetes 管理，它屬于集群管理員的職責范疇。根據`Service`的規定，`externalIPs`可以同任意的`ServiceType`來一起指定。在上面的例子中，`redis-master`可以在 “`192.168.136.200:80`”(`externalIP:port`) 上被客戶端訪問 ```yaml apiVersion: v1 kind: Service metadata: name: redis-master spec: selector: app: MyApp ports: - name: http protocol: TCP port: 80 targetPort: 6379 externalIPs: - 192.168.136.200 ```