服務發現與負載均衡 · kubernetes完整攻略

# 服務發現與負載均衡 Kubernetes在設計之初就充分考慮了針對容器的服務發現與負載均衡機制，提供了Service資源，并通過kube-proxy配合cloud provider來適應不同的應用場景。隨著kubernetes用戶的激增，用戶場景的不斷豐富，又產生了一些新的負載均衡機制。目前，kubernetes中的負載均衡大致可以分為以下幾種機制，每種機制都有其特定的應用場景： - Service：直接用Service提供cluster內部的負載均衡，并借助cloud provider提供的LB提供外部訪問 - Ingress Controller：還是用Service提供cluster內部的負載均衡，但是通過自定義LB提供外部訪問 - Service Load Balancer：把load balancer直接跑在容器中，實現Bare Metal的Service Load Balancer - Custom Load Balancer：自定義負載均衡，并替代kube-proxy，一般在物理部署Kubernetes時使用，方便接入公司已有的外部服務 ## Service Service是對一組提供相同功能的Pods的抽象，并為它們提供一個統一的入口。借助Service，應用可以方便的實現服務發現與負載均衡，并實現應用的零宕機升級。Service通過標簽來選取服務后端，一般配合Replication Controller或者Deployment來保證后端容器的正常運行。 Service有三種類型： - ClusterIP：默認類型，自動分配一個僅cluster內部可以訪問的虛擬IP - NodePort：在ClusterIP基礎上為Service在每臺機器上綁定一個端口，這樣就可以通過`<NodeIP>:NodePort`來訪問該服務 - LoadBalancer：在NodePort的基礎上，借助cloud provider創建一個外部的負載均衡器，并將請求轉發到`<NodeIP>:NodePort` 另外，也可以將已有的服務以Service的形式加入到Kubernetes集群中來，只需要在創建Service的時候不指定Label selector，而是在Service創建好后手動為其添加endpoint。 ## Ingress Controller Service雖然解決了服務發現和負載均衡的問題，但它在使用上還是有一些限制，比如 - 對外訪問的時候，NodePort類型需要在外部搭建額外的負載均衡，而LoadBalancer要求kubernetes必須跑在支持的cloud provider上面 Ingress就是為了解決這些限制而引入的新資源，主要用來將服務暴露到cluster外面，并且可以自定義服務的訪問策略。比如想要通過負載均衡器實現不同子域名到不同服務的訪問： ``` foo.bar.com --| |-> foo.bar.com s1:80 | 178.91.123.132 | bar.foo.com --| |-> bar.foo.com s2:80 ``` 可以這樣來定義Ingress： ```yaml apiVersion: extensions/v1beta1 kind: Ingress metadata: name: test spec: rules: - host: foo.bar.com http: paths: - backend: serviceName: s1 servicePort: 80 - host: bar.foo.com http: paths: - backend: serviceName: s2 servicePort: 80 ``` **注意：** Ingress本身并不會自動創建負載均衡器，cluster中需要運行一個ingress controller來根據Ingress的定義來管理負載均衡器。目前社區提供了nginx和gce的參考實現。 [Traefik](https://traefik.io)提供了易用的Ingress Controller，使用方法見<https://docs.traefik.io/user-guide/kubernetes/>。 ## Service Load Balancer 在Ingress出現以前，Service Load Balancer是推薦的解決Service局限性的方式。Service Load Balancer將haproxy跑在容器中，并監控service和endpoint的變化，通過容器IP對外提供4層和7層負載均衡服務。社區提供的Service Load Balancer支持四種負載均衡協議：TCP、HTTP、HTTPS和SSL TERMINATION，并支持ACL訪問控制。 ## Custom Load Balancer 雖然Kubernetes提供了豐富的負載均衡機制，但在實際使用的時候，還是會碰到一些復雜的場景是它不能支持的，比如： - 接入已有的負載均衡設備 - 多租戶網絡情況下，容器網絡和主機網絡是隔離的，這樣`kube-proxy`就不能正常工作這個時候就可以自定義組件，并代替kube-proxy來做負載均衡。基本的思路是監控kubernetes中service和endpoints的變化，并根據這些變化來配置負載均衡器。比如weave flux、nginx plus、kube2haproxy等。 ## Endpoints 有幾種情況下需要用到沒有selector的service。 - 使用kubernetes集群外部的數據庫時 - service中用到了其他namespace或kubernetes集群中的service - 在kubernetes的工作負載與集群外的后端之間互相遷移可以這樣定義一個沒有selector的service。 ```yaml kind: Service apiVersion: v1 metadata: name: my-service spec: ports: - protocol: TCP port: 80 targetPort: 9376 ``` 定義一個Endpoints來對應該service。 ```yaml kind: Endpoints apiVersion: v1 metadata: name: my-service subsets: - addresses: - ip: 1.2.3.4 ports: - port: 9376 ``` 訪問沒有selector的service跟訪問有selector的service時沒有任何區別。使用kubernetes時有一個很常見的需求，就是當數據庫部署在kubernetes集群之外的時候，集群內的service如何訪問數據庫呢？當然你可以直接使用數據庫的IP地址和端口號來直接訪問，有沒有什么優雅的方式呢？你需要用到`ExternalName Service`。 ```yaml kind: Service apiVersion: v1 metadata: name: my-service namespace: prod spec: type: ExternalName externalName: my.database.example.com ports: - port: 12345 ``` 這個例子中，在kubernetes集群內訪問`my-service`實際上會重定向到`my.database.example.com:12345`這個地址。 ## 參考資料 - https://kubernetes.io/docs/concepts/services-networking/service/ - http://kubernetes.io/docs/user-guide/ingress/ - https://github.com/kubernetes/contrib/tree/master/service-loadbalancer - https://www.nginx.com/blog/load-balancing-kubernetes-services-nginx-plus/ - https://github.com/weaveworks/flux - https://github.com/AdoHe/kube2haproxy