歡迎各位讀者評論留言，共同學習，共同進步。
《kubernetes權威指南》筆記
1.4kubernetes基本概念和術語(1)
1.4kubernetes基本概念和術語(2)
1.4kubernetes基本概念和術語(3)
8.Service
-
Service服務也是Kubernetes里的核心資源對象之一，Kubernetes里的每個Service其實就是我們經(jīng)常提起的微服務架構中的一個微服務。
Kubernetes的Service定義了一個服務的訪問入口地址，
前端的應用（Pod）通過這個入口地址訪問其背后的一組由Pod副本組成的集群實例，
Service與其后端Pod副本集群之間則是通過Label Selector來實現(xiàn)無縫對接的。
RC的作用實際上是保證Service的服務能力和服務質量始終符合預期標準。 -
我們的系統(tǒng)最終由多個提供不同業(yè)務能力而又彼此獨立的微服務單元組成的，服務之間通過TCP/IP進行通信，從而形成了強大而又靈活的彈性網(wǎng)格，擁有強大的分布式能力、彈性擴展能力、容錯能力，程序架構也變得簡單和直觀許多
Q1: 客戶端如何訪問service?
- (1) 一般做法：給這些Pod的Endpoint列表加入如8000端口轉發(fā)列表，客戶端通過負載均衡起的對外Ip地址+服務器端口來訪問此服務。
k8s上每個Node上的Kube-proxy進程就是一個智能的軟件負載均衡器，負責把對Service的請求轉發(fā)到后端的某個Pod實例上，并在內部實現(xiàn)服務的負載均衡與會話保持機制
(2) service做法：給每個service都分配一個全局唯一的虛擬IP地址，成為cluster Ip，這樣服務間可以通過唯一IP地址進行通信。
原因：pod的Endpoint地址會隨著Pod的銷毀和重新創(chuàng)建而改變，因為新Pod的Ip地址和之前舊的Pod的不同。而service一旦被創(chuàng)建，在其生命周期內 cluster Ip不會變。最后只要用Service的Name與Service的Cluster IP地址做一個DNS域名映射即可完美解決問題。
(3) 結論：客戶端 -- 通過serviceName --> service --通過label selector --> 實際service節(jié)點
配置文件使用：
targetPort: 在spec.ports的定義中，targetPort屬性用來確定提供該服務的容器所暴露（EXPOSE）的端口號，即具體業(yè)務進程在容器內的targetPort上提供TCP/IP接入；
port: port屬性則定義了Service的虛端口。前面定義Tomcat服務時沒有指定targetPort，則默認targetPort與port相同
Q2: 多端口為什么要定義多個端口名？服務發(fā)現(xiàn)機制是什么？
- 大多數(shù)大數(shù)據(jù)分布式系統(tǒng)采用的是特定API接口實習服務發(fā)現(xiàn)，但這樣做會導致平臺的侵入性比較強，也增加了開發(fā)、測試的難度。
- k8s的方法： cluster Ip和service Name是固定的，只需要存儲這兩個的關系即可。
最早時Kubernetes采用了Linux環(huán)境變量解決這個問題，即每個Service都生成一些對應的Linux環(huán)境變量（ENV），并在每個Pod的容器啟動時自動注入這些環(huán)境變量。
通過環(huán)境變量獲取Service地址的方式仍然不太方便、不夠直觀，后來Kubernetes通過Add-On增值包引入了DNS系統(tǒng)，把服務名作為DNS域名，這樣程序就可以直接使用服務名來建立通信連接了。目前，Kubernetes上的大部分應用都已經(jīng)采用了DNS這種新興的服務發(fā)現(xiàn)機制，后面會講解如何部署DNS系統(tǒng)。
Q3:外部系統(tǒng)如何訪問serice?
- a. Node Ip:實際物理網(wǎng)卡的Ip地址
- b.Pod Ip: 它是Docker Engine根據(jù)docker0網(wǎng)橋的IP地址段進行分配的，通常是一個虛擬的二層網(wǎng)絡。
Kubernetes要求位于不同Node上的Pod都能夠彼此直接通信，所以Kubernetes里一個Pod里的容器訪問另外一個Pod里的容器時，就是通過Pod IP所在的虛擬二層網(wǎng)絡進行通信的，而真實的TCP/IP流量是通過Node IP所在的物理網(wǎng)卡流出的。 - c. Cluster Ip: 虛擬ip，
特點：◎ Cluster IP僅僅作用于Kubernetes Service這個對象，并由Kubernetes管理和分配IP地址（來源于ClusterIP地址池）。
◎ Cluster IP無法被Ping，因為沒有一個“實體網(wǎng)絡對象”來響應。
◎ Cluster IP只能結合Service Port組成一個具體的通信端口，單獨的Cluster IP不具備TCP/IP通信的基礎，并且它們屬于Kubernetes集群這樣一個封閉的空間，集群外的節(jié)點如果要訪問這個通信端口，則需要做一些額外的工作。
◎ 在Kubernetes集群內，Node IP網(wǎng)、Pod IP網(wǎng)與Cluster IP網(wǎng)之間的通信，采用的是Kubernetes自己設計的一種編程方式的特殊路由規(guī)則，與我們熟知的IP路由有很大的不同。
實際訪問是通過NodeIp+NodePort.
a. NodePort的實現(xiàn)方式是在Kubernetes集群里的每個Node上都為需要外部訪問的Service開啟一個對應的TCP監(jiān)聽端口，外部系統(tǒng)只要用任意一個Node的IP地址+具體的NodePort端口號即可訪問此服務。
b. 負載均衡問題：假如在我們的集群中有10個Node，則此時最好有一個負載均衡器，外部的請求只需訪問此負載均衡器的IP地址，由負載均衡器負責轉發(fā)流量到后面某個Node的NodePort上。
Load balancer組件獨立于Kubernetes集群之外，通常是一個硬件的負載均衡器，或者是以軟件方式實現(xiàn)的，例如HAProxy或者Nginx。對于每個Service，我們通常需要配置一個對應的Load balancer實例來轉發(fā)流量到后端的Node上，這的確增加了工作量及出錯的概率。于是Kubernetes提供了自動化的解決方案，如果我們的集群運行在谷歌的公有云GCE上，那么只要把Service的type=NodePort改為type=LoadBalancer，Kubernetes就會自動創(chuàng)建一個對應的Load balancer實例并返回它的IP地址供外部客戶端使用。其他公有云提供商只要實現(xiàn)了支持此特性的驅動，則也可以達到上述目的。此外，裸機上的類似機制（Bare Metal Service Load Balancers）也在被開發(fā)。
總結： 外部客戶端請求-- 通過load balancer (如nginx) --> 分配一個Node IP ，根據(jù)Node Port 訪問 k8s某個Node 節(jié)點 --> Node IP 通過 Cluster Ip ，找到集群對應Pod（注意是整個集群中的Pod，而非某個Node上的Pod） --> 通過kube-proxy 從service 轉發(fā)到后端某個Pod實例上。
