# Kubernetes核心技術Service ## 前言 前面我們了解到 Deployment 只是保證了支撐服務的微服務Pod的數量，但是沒有解決如何訪問這些服務的問題。一個Pod只是一個運行服務的實例，隨時可能在一個節點上停止，在另一個節點以一個新的IP啟動一個新的Pod，因此不能以確定的IP和端口號提供服務。 要穩定地提供服務需要服務發現和負載均衡能力。服務發現完成的工作，是針對客戶端訪問的服務，找到對應的后端服務實例。在K8S集群中，客戶端需要訪問的服務就是Service對象。每個Service會對應一個集群內部有效的虛擬IP，集群內部通過虛擬IP訪問一個服務。 在K8S集群中，微服務的負載均衡是由kube-proxy實現的。kube-proxy是k8s集群內部的負載均衡器。它是一個分布式代理服務器，在K8S的每個節點上都有一個；這一設計體現了它的伸縮性優勢，需要訪問服務的節點越多，提供負載均衡能力的kube-proxy就越多，高可用節點也隨之增多。與之相比，我們平時在服務器端使用反向代理作負載均衡，還要進一步解決反向代理的高可用問題。 ## Service存在的意義 ### 防止Pod失聯【服務發現】 因為Pod每次創建都對應一個IP地址，而這個IP地址是短暫的，每次隨著Pod的更新都會變化，假設當我們的前端頁面有多個Pod時候，同時后端也多個Pod，這個時候，他們之間的相互訪問，就需要通過注冊中心，拿到Pod的IP地址，然后去訪問對應的Pod  ### 定義Pod訪問策略【負載均衡】 頁面前端的Pod訪問到后端的Pod，中間會通過Service一層，而Service在這里還能做負載均衡，負載均衡的策略有很多種實現策略，例如： - 隨機 - 輪詢 - 響應比  ## Pod和Service的關系 這里Pod 和 Service 之間還是根據 label 和 selector 建立關聯的 【和Controller一樣】  我們在訪問service的時候，其實也是需要有一個ip地址，這個ip肯定不是pod的ip地址，而是 虛擬IP `vip` ## Service常用類型 Service常用類型有三種 - ClusterIp：集群內部訪問 - NodePort：對外訪問應用使用 - LoadBalancer：對外訪問應用使用，公有云 ### 舉例 我們可以導出一個文件 包含service的配置信息 ```bash kubectl expose deployment web --port=80 --target-port=80 --dry-run -o yaml > service.yaml ``` service.yaml 如下所示 ```yaml apiVersion: v1 kind: Service metadata: creationTimestamp: null labels: app: web name: web spec: ports: - port: 80 protocol: TCP targetPort: 80 selector: app: web status: loadBalancer: {} ``` 如果我們沒有做設置的話，默認使用的是第一種方式 ClusterIp，也就是只能在集群內部使用，我們可以添加一個type字段，用來設置我們的service類型 ```yaml apiVersion: v1 kind: Service metadata: creationTimestamp: null labels: app: web name: web spec: ports: - port: 80 protocol: TCP targetPort: 80 selector: app: web type: NodePort status: loadBalancer: {} ``` 修改完命令后，我們使用創建一個pod ```bash kubectl apply -f service.yaml ``` 然后能夠看到，已經成功修改為 NodePort類型了，最后剩下的一種方式就是LoadBalanced：對外訪問應用使用公有云 node一般是在內網進行部署，而外網一般是不能訪問到的，那么如何訪問的呢？ - 找到一臺可以通過外網訪問機器，安裝nginx，反向代理 - 手動把可以訪問的節點添加到nginx中 如果我們使用LoadBalancer，就會有負載均衡的控制器，類似于nginx的功能，就不需要自己添加到nginx上