Service 的概念
Service能夠提供負載均衡的能力，但是在使用上有以下限制：
只提供 4 層負載均衡能力，而沒有 7 層功能，但有時我們可能需要更多的匹配規則來轉發請求，這點上 4 層負載均衡是不支持的Service 的類型
Service 在 K8s 中有以下四種類型
ClusterIp：默認類型，自動分配一個僅 Cluster 內部可以訪問的虛擬 IPNodePort：在 ClusterIP 基礎上為 Service 在每臺機器上綁定一個端口，這樣就可以通過 : NodePort 來訪問該服務LoadBalancer：在 NodePort 的基礎上，藉助 cloud provider 創建一個外部負載均衡器，並將請求轉發到: NodePortExternalName：把集群外部的服務引入到集群內部來，在集群內部直接使用。沒有任何類型代理被創建，這隻有 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層”（TCPhttps://sun-iot.gitee.io/source.github.io/linux/k8s/service/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： 不排隊調度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 文件
<code>[root@master manifests]# vim 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 /<code>
創建 Service 信息
<code>[root@master manifests]# 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 /<code>
Headless Service
有時不需要或不想要負載均衡，以及單獨的 Service IP 。遇到這種情況，可以通過指定 Cluster IP(spec.clusterIP) 的值為 “None” 來創建 Headless Service 。這類 Service 並不會分配 Cluster IP， kube-proxy 不會處理它們，而且平臺也不會為它們進行負載均衡和路由
<code>[root@k8s-master mainfests]# 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 [root@k8s-master mainfests]# dig -t A myapp-headless.default.svc.cluster.local. @10.96.0.10 /<code>
NodePort
nodePort 的原理在於在 node 上開了一個端口，將向該端口的流量導入到 kube-proxy，然後由 kube-proxy 進一步到給對應的 pod
<code>[root@master manifests]# vim myapp-service.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 /<code>
查詢流程
<code>iptables -t nat -nvL KUBE-NODEPORTS /<code>
LoadBalancer
loadBalancer 和 nodePort 其實是同一種方式。區別在於 loadBalancer 比 nodePort 多了一步，就是可以調用cloud provider 去創建 LB 來向節點導流
ExternalName
這種類型的 Service 通過返回 CNAME 和它的值，可以將服務映射到 externalName 字段的內容( 例如：hub.atguigu.com )。ExternalName Service 是 Service 的特例，它沒有 selector，也沒有定義任何的端口和 Endpoint。相反的，對於運行在集群外部的服務，它通過返回該外部服務的別名這種方式來提供服務
<code>kind: Service apiVersion: v1 metadata: name: my-service-1 namespace: default spec: type: ExternalName externalName: hub.atguigu.com /<code>
當查詢主機 my-service.defalut.svc.cluster.local ( SVC_NAME.NAMESPACE.svc.cluster.local )時，集群的 DNS 服務將返回一個值 my.database.example.com 的 CNAME 記錄。訪問這個服務的工作方式和其他的相同，唯一不同的是重定向發生在 DNS 層，而且不會進行代理或轉發