kubernetes中Service詳解（圖解）
目錄
容器及Pod間通信
Kube-proxy
DNS服務發現機制
Kubernetes服務
第一部分：容器及Pod間通信
Kubernets網絡模型設計的一個基礎原則是：每個Pod都擁有一個獨立的IP地址，而且假定所有的Pod都在一個可以之間聯通的，扁平的網絡空間里，所以不管是否運行在同一個Node中，都要求他們可以直接通過對方的IP進行訪問。設計這個原則的原因是用戶不需要額外考慮如何建立Pod之間的連接，也不需要將容器端口映射到主機端口等問題
按照上述的網絡抽象原則，Kubernets對集群的網絡有以下要求：
1）所有容器都可以在不用NAT的方式下同其他容器通信
2）所有節點都可以在不用NAT的方式下同其他容器通信
3）容器的地址和別人看到的地址是同一個地址
下面我們介紹kubernets中有哪些通信場景
一.同一Pod中的容器間通信
同一個Pod中的容器共享同一個網絡命名空間，他們之間的訪問可以通過localhost地址和容器端口來實現
二.同一Node中Pod間通信
同一Node中的Pod默認路由都是Docker0的地址，由於他們關聯在同一個Docker0網橋上，地址網段相同，所以他們能直接通信
三.不同Node之間Pod間的通信
Docker0網橋與宿主機網卡是完全不同的IP網段，並且Node之間的通信只能通過宿主機的物理網卡進行，因此要想實現位於不同Node上的Pod容器之間的通信，就必須想辦法通過主機的IP地址進行尋址和通信
另一方面，這些動態分配並且隱藏在Docker0之后的所謂“私有IP地址”也是可以找到的，Kubernetes會記錄所有正在運行的Pod的IP分配信息，並且將這些信息保存在etcd中（作為Service的Endpoint），這些私有IP對Pod到Pod之間的通信是非常重要的
想要實現支持不同Node上的Pod之間的通信，要達到兩個條件
1.在整個kubernetes集群中對Pod的IP進行規划，不能有沖突
2.找到一種方法，將Pod的IP和所在的Node關聯起來，通過這個關聯可以讓Pod可以互相訪問
應對條件一，Kubernetes的網絡增強軟件Flannel就能夠管理網段的划分
應對條件二，Pod中的的數據在發出時需要一個機制，能夠知道對方Pod的IP地址掛載具體哪個Pod上，也就是要先找到Node對應宿主機的IP地址，將數據發送到這個宿主機的網卡上，然后在宿主機上將相應的數據發送到具體的Docker0上，一旦數據到達宿主機Node，則該Node內部的Docker0便知道如何將數據發送到Pod上
關於上述三種通信的模型圖解，請查看筆者的另一篇文章Dokcer網絡模型
第二部分：kube-proxy
kube-proxy是一個簡單的網絡代理和負載均衡器，它的作用主要是負載Service的實現，實現從Pod到Service，以及從NodePort到Service的訪問
一.kube-proxy實現方式
usersapce方式：通過kube-proxy實現LB的代理服務，是kube0proxy的最初版本，較為穩定，但是效率不高
iptables方式：采用iptables來實現LB，是當前kube-proxy的默認方式
kube-proxy監視Kubernetes主服務器對服務/端點對象的各種增，刪，改等操作。對於每個服務，它配置iptables規則，捕獲Service的ClusterIP和端口的流量，並將流量重定向到服務的后端之一。對於每個Endpoint對象，它選擇后端Pod的iptables規則
默認情況下，后端的選擇是隨機的。可通過Service.spec.sessionAffinity設置為“ClientIP”來選擇基於客戶端IP的會話關聯
第三部分：DNS服務發現機制
在Kubernetes系統中，當Pod需要訪問其他Service時，可以通過兩種方式來發現服務，即環境變量和DNS方式。前者有非常大的局限性，所以實際我們一般都選用第二種DNS方式來實現服務的注冊和發現
kube-dns用來為Service分配子域名，以便集群中的Pod可通過域名獲取Service的訪問地址，通常kube-dns會為Service賦予一個名為“service_name.namespace_name.svc.cluster_domain”的記錄，用來解析Service的Cluster_IP。Kubernetes v1.4版本之后，其主要由Kubedns，Dnsmasq，Exechealthz三個組件構成
Kubedns通過Kubernetes API監視Service資源變化並更新DNS記錄，主要為Dnsmasq提供查詢服務，服務端口是10053
Dnsmasq是一款小巧的DNS配置工具，其在kube-dns插件中的作用是：通過kube-dns容器獲取DNS規則，在集群中提供DNS查詢服務，提供DNS緩存，提高查詢性能，降低kube-dns容器的壓力
Exechealthz主要提供監控檢查功能
service的類型有四種:
1. ExternalName: 用於將集群外部的服務引入到集群內部，在集群內部可直接訪問來獲取服務。
它的值必須是 FQDN, 此FQDN為集群內部的FQDN, 即: ServiceName.Namespace.Domain.LTD.
然后CoreDNS接受到該FQDN后，能解析出一個CNAME記錄, 該別名記錄為真正互聯網上的域名.
如: www.test.com, 接着CoreDNS在向互聯網上的根域DNS解析該域名，獲得其真實互聯網IP.
2. ClusterIP： 用於為集群內Pod訪問時,提供的固定訪問地址,默認是自動分配地址,可使用ClusterIP關鍵字指定固定IP.
3. NodePort: 用於為集群外部訪問Service后面Pod提供訪問接入端口.
這種類型的service工作流程為:
Client----->NodeIP:NodePort----->ClusterIP:ServicePort----->PodIP:ContainerPort
4. LoadBalancer: 用於當K8s運行在一個雲環境內時,若該雲環境支持LBaaS,則此類型可自動觸發創建
一個軟件負載均衡器用於對Service做負載均衡調度.
因為外部所有Client都訪問一個NodeIP,該節點的壓力將會很大, 而LoadBalancer則可解決這個問題。
而且它還直接動態監測后端Node是否被移除或新增了，然后動態更新調度的節點數。
到這里我們其實可以簡單描述一下整個Kubernetes之間到底是如何各組件之間進行協作的了！
第四部分：Kubernetes服務
Service是Kubernets最核心的概念，通過創建Service，可以為一組具有相同功能的容器應用提供一個統一的入口地址，並且將請求進行負載均衡分發到后端的各個容器應用上。
Service是一個虛擬的概念，真正實現Service功能的是kube-proxy，kube-proxy起到一個代理和負載均衡的作用
下面我們介紹一下Service的類型
Service的類型，即Service的訪問方式
Service的類型默認是ClusterIP
ClusterIP，虛擬服務IP地址，該地址用於Kubernetes集群內部的Pod訪問，在Node上kube-proxy通過設置的iptables規則進行轉發
NodePort模式，使用宿主機的端口，使能夠訪問各Node的外部客戶端通過Node的IP地址和端口號就能訪問服務
LoadBalancer模式：使用外部負載均衡器完成到服務的負載分發，需要在spec.status.loadBalancer字段指定外部負載均衡器的地址，並同時定義nodePort和cluster IP，用於公有雲環境
一.ClusterIP
ClusterIP服務是Kubernetes默認的服務類型。如果用戶在集群內創建一個服務，
則在集群內部的其他應用程序可以對這個服務進行訪問，但是不具備集群外部訪問的能力
Service的ClusterIP地址是Kubernetes系統中虛擬的IP地址，由系統動態分配
二.NodePort
NodePort服務是外部訪問服務的最基本方式，顧名思義，NodePort就是在所有節點或者虛擬機上開放特點的端口，該端口的流量將被轉發到對應的服務
我們來分析一下上圖要表達的意思，當集群外部的客戶想要訪問ServiceA時，它可以訪問Host1-10.10.1.2的31600端口，也可以訪問Host2-10.10.1.3的31600端口。這兩個訪問地址最終都會連接到ServiceA上，並且集群內部的Pod還是可以通過訪問192.168.1.22這個集群地址來訪問到ServiceA
從ServiceA 到到后邊多個Pod(A) 的訪問和負載均衡是通過iptables的nat轉發實現的。kube-proxy一方面負責啟動服務開啟端口，同時也維護每台服務器的iptabls。因為ClusterIP 是個實際不存在的IP，每台node會通過iptables的nat轉發規則，將請求分發到多個不同的pod的實際ip地址。然后按照flannel 的vxlan方式或者calico 的iptables轉發方式發送實際請求。在iptables nat 轉發中會增加probability 的方式實現一部分的負載均衡。
可總結如下：
在具有集群內部IP的基礎上，在集群的每個節點上的端口（每個節點上的相同端口）上公開服務。用戶可以在任何< Node IP >:NodePort地址上訪問
NodePort方式的缺點主要有：
1）每個服務占用一個端口
2）可以使用的范圍端口為30000~32767
3）如果節點/虛擬機IP地址發生更改，需要進行相關處理
三. LoadBalancer
LoadBalancer服務是暴露服務至互聯網最標准的方案，除了具有集群內部IP以及在NodePort上公開服務之外，還要求雲提供商負載均衡將請求轉發到每個Node節點的NodePort端口商
來自外部負載均衡器的流量將被定向到后端Pod，盡管其工作原理取決於雲提供商。一些雲提供商允許指定LoadBalancer IP。在這些情況下，將使用用戶指定的LoadBalancerIP創建負載均衡器
四.Ingress
Ingress並不是服務類型的一種，它位於多個服務的前端，充當一個智能路由表或者集群的入口點，GKE默認的Ingress控制器將啟動一個HTTP（S）的負載均衡器，這將使用戶可以基於訪問路徑和子域名將流量路由到后端服務
例如下圖，我們可以將app.sample.com下的流量轉發到服務A，將app.comlpex.com路徑下的流量轉發到服務B
