kubernetes 服務發現和負載均衡
kubernetes中如何發現服務
如何發現pod提供的服務
如何使用kube-dns發現服務
service：服務，是一個虛擬概念，邏輯上代理后端pod。眾所周知，pod生命周期短，狀態不穩定，pod異常后新生成的pod ip會發生變化，之前pod的訪問方式均不可達。通過service對pod做代理，service有固定的ip和port，ip:port組合自動關聯后端pod，即使pod發生改變，kubernetes內部更新這組關聯關系，使得service能夠匹配到新的pod。這樣，通過service提供的固定ip，用戶再也不用關心需要訪問哪個pod，以及pod是否發生改變，大大提高了服務質量。如果pod使用rc創建了多個副本，那么service就能代理多個相同的pod，通過kube-proxy，實現負載均衡
service 模版
{ "kind": "Service”,
"apiVersion": "v1”,
"metadata”:
{ "name": "my-service" },
"spec": { "selector”:
{ "app": "MyApp" },
"ports": [
{ "protocol": "TCP”,
"port": 80,
"targetPort": 9376 } ] }}
其中這個service代理了所有具有app：
MyApp標簽的pod，服務對外端口是80，
服務ip（clusterip）
在創建service的時候生成，也可以指定，這組ip：port在service的周期里保持固定。訪問ip：port的流量會被重定向到后端pod的9376端口上，就是targetport指定的。
每個節點都有一個組件kube-proxy，實際上是為service服務的，通過kube-proxy，實現流量從service到pod的轉發，kube-proxy也可以實現簡單的負載均衡功能。
kube-proxy代理模式：userspace方式：kube-proxy 在節點上為每一個服務創建一個臨時端口，service的IP：port 過來的流量轉發到這個臨時端口上，kube-proxy會用內部的負載均衡機制（輪詢），選擇一個后端pod，然后建立iptables，把流量導入這個pod里面
服務發現
服務發現在微服務架構里，服務之間經常進行通信，服務發現就是解決不同服務之間通信的問題。比如一個nginx的pod，要訪問一個mysql服務，就需要知道mysql服務的ip和port，獲取ip和port的過程就是服務發現。
kubernetes 支持兩種服務發現模式
1.環境變量：
Pod創建的時候，服務的ip和port會以環境變量的形式注入到pod里，比如pod創建時有一個redis-master服務，服務ip地址是10.0.0.11，port是6379，則會把下面一系列環境變量注入到pod里，通過這些環境變量訪問redis-master服務。 REDIS_MASTER_SERVICE_HOST=10.0.0.11REDIS_MASTER_SERVICE_PORT=6379REDIS_MASTER_PORT=tcp://10.0.0.11:6379
2.dns：
K8s集群會內置一個dns服務器，service創建成功后，會在dns服務器里導入一些記錄，想要訪問某個服務，通過dns服務器解析出對應的ip和port，從而實現服務訪問
service 是微服務架構中的微服務。service 定義了一個服務的訪問入口地址，前端的應用（pod）通過這個入口訪問其背后的一組由pod副本組成的集群實例，service與其后端pod副本集群之間是通過label seletor 實現無縫對接的。而rc的功能實際上是保證servic的服務能力和服務質量處於預期的標准
通常我們的系統是由多個提供不同業務能力而又彼此獨立的微服務單元所組成，服務之間通過tcp／ip進行通信，從而形成了強大而又靈活的彈性網絡，擁有了強大的分布式能力，彈性擴展能力，容錯能力。
nodeip：是k8s集群中每個節點的物理網卡的ip地址，是真實存在的物理地址，所有屬於這個網絡的服務器之間都能通過這個網絡直接通信，不管它們中是否有部分節點不屬於這個集群，這也表明集群之外的節點訪問k8s集群之內的某個節點或者tcp／ip服務的時候，必須通過nodeip進行通信
podip：是每個pod的ip地址，是docker engine根據docker0網橋的ip地址段進行分配的，是一個虛擬的二層網絡，k8s里面的一個pod里面的容器訪問另外一個容器，就是通過podip所在的虛擬二層網絡進行通信的。
每個會被分配一個單獨的ip，每個pod都提供了一個獨立的Endpoint( Pod ip + Container port ）以被客戶端訪問
clusterip：全局的唯一的虛擬ip，在整個service的聲明周期內，一旦創建，就不會改變
僅僅作用於service對象，由k8s管理和分配ip地址
無法被ping，沒有實體網絡對象來響應
必須結合service port 組成一個具體的通信端口，單獨的clusterip不具備tcp／ip通信協議
在k8s內部，nodeip網、podip網和clusterip網之間的通信，采用的是k8s自己設計的一種編程方式的特殊路由規則
外部訪問集群內部容器服務
外部服務對於一些前端應用，需要暴露服務給外網，而其他應用只能運行在內部。service的types字段可以指定服務類型。默認是clusterip類型，這是集群內部的服務類型，服務ip（clutserip）是一個內部ip；
外部服務類型：
1.nodeip + nodeport
為每個節點暴露一個端口，通過nodeip + nodeport可以訪問這個服務，同時服務依然會有cluster類型的ip+port，內部通過clusterip方式訪問，外部通過nodeport方式訪問
2.loadbalance
如果k8s集群運行在第三方雲平台上，比如openstack，那么可以通過外部的loadbalance來暴露服務，還能借用第三方的負載均衡機制實現負載均衡。以openstack為例，借助neutron的lbaas，訪問服務的流量會被直接轉發到后端的pod，跳過了內置的kube-proxy負載均衡。
cluster ip 屬於k8s集群內部的地址，無法在外部使用這個地址，若要外部可以進行訪問，需要進行擴展
type：NodePort
ports:
Nodeport:31002
然后nodeip + nodeport 進行訪問
NodePort的實現方式是在k8s集群里的每個node上為需要外部訪問的service開啟一個對應的tcp監聽端口，外部系統只要任意一個node的ip地址+nodeport端口即可訪問服務
service如何進行服務發現
service可以將pod ip封裝起來，即使pod發生重建，依然可以通過service來訪問pod提供的服務，service還解決了負載均衡的問題
運行在每個node上的kube-proxy進程其實就是一個智能的軟件負載均衡器，他負責把service的請求轉發到后端的某個pod實例。
kube-dns可以解決Service的發現問題，k8s將Service的名稱當做域名注冊到kube-dns中，通過Service的名稱就可以訪問其提供的服務