今天給大家介紹下k8s的service的幾種訪問模式。
概述
我們知道pod的ip不是固定的，是根據所在宿主機的docker0網卡生成的，每次重啟，更新，調度等情況IP都會變，那pod與pod之間需要互相調用，肯定不能用ip的，因為地址不是固定的， 如何能保障pod之前訪問的可靠性，由此就衍生出Service的概念。
在實際生產環境中，一般有兩種訪問 對集群內部的訪問， 集群外部的訪問。service現在分為以下類型
ClusterIP
集群內部容器訪問地址，會生成一個虛擬IP 與pod不在一個網段。
**NodePort **
會在宿主機上映射一個端口，供外部應用訪問模式。
**Headless CluserIP **
無頭模式，無serviceip，即把spec.clusterip設置為None 。
LoadBalancer
使用外部負載均衡。
Port類型
我們先理解Service Port的幾種類型。
NodePort
指定暴露到宿主機的端口，不指定的話會隨機分配個，分配的IP在apiserver的配置文件中指定了--service-node-port-range=30000-50000，表示只允許分配30000-50000之間的端口。
比如一個nginx應用需要能被外部訪問，就需要配置類型為type=NodePort,並且需要配置下nodePort: 30002(指定固定端口)，這樣的話外部使用http://ip:30002就可以訪問這個應用了。
也有一些內部服務是需要外部訪問的，那就不需要到使用NodePort模式了。
apiVersion: v1
Port
集群內部服務之間訪問的端口。
比如一個nginx容器暴露了80端口，但是其他容器需要通過nginx:80訪問，就需要配置port:80 ,外部是沒法訪問這個端口的，因為沒有對外開放端口。
apiVersion: v1
targetPort
容器本身暴露的端口，和dockerfile中的expose意思一樣
例子說明
接下來我們通過幾個例子來理解說明
創建NodePort類型Service
如果選擇了“NodePort”，那么 Kubernetes master 會分配一個區域范圍內，（默認是30000-32767），並且，每一個node，都會代理（proxy）這個端口到你的服務中，我們可以在spec.ports[*].nodePort 找到具體的值
如果我們指定一個端口，我們可以直接寫在nodePort上，系統就會給你指派指定端口，但是這個值必須是指定范圍內的。
Cluster service 的 IP 地址是虛擬的，因此，只能從node節點上使用該IP 地址訪問應用。為了從集群外訪問應用，K8S 提供了使用 node 節點的IP 地址訪問應用的方式。
基本上，NodePort 服務與普通的 “ClusterIP” 服務 YAML 定義有兩點區別。 首先，type 是 “NodePort”。還有一個稱為 nodePort 的附加端口，指定在節點上打開哪個端口。 如果你不指定這個端口，它會選擇一個隨機端口。
該端口號的范圍是 kube-apiserver 的啟動參數 –service-node-port-range指定的，在當前測試環境中其值是 30000-50000。表示只允許分配30000-50000之間的端口。
ps：一般使用NodePort 都會在外部搭建負載均衡來代理多個node節點。
創建一個Deployment
[root@master-01 ~]# cat nginx-deploy.yaml
**創建service **
[root@master-01 ~]# cat ng-svc.yaml
查看詳情
[root@master-01 ~]# kubectl describe svc nginx
查看狀態
[root@master-01 ~]# kubectl get po,ep,svc
訪問測試
# 通過endpoint 訪問
在pod中也可以通過service的名稱訪問（一般都這樣使用）
創建ClusterIP類型Service
會生成一個集群內部的虛擬IP（網段和pod不同）只是給集群內部和pod之間訪問的，外部無法訪問，網段通過配置文件指定。
ClusterIP也是Kubernetes service的默認類型。
原理
用戶通過kubectl命令向apiserver發送創建service的命令，apiserver接收到請求以后將數據存儲到etcd中。
每個節點中都有一個叫做kube-proxy的進程，這個進程負責感知service，pod的變化，並將變化的信息寫入本地的iptables中。
iptables 使用NAT等技術將virtualIP的流量轉至endpoint中。
創建pod
[root@master-01 ~]# cat nginx-deployment.yaml
創建Service
[root@master-01 ~]# cat ng-svc-clusterip.yaml
創建HeadlessClusterIP類型Service
有時候我們可能不需要一個固定的IP和分發，這個時候我們只需要將spec.clusterIP的值設置為none就可以了，通過設置標簽綁定到pod的方式完成，對於這樣的服務來說，集群IP沒有分配，這個時候當你查詢服務的名稱的時候，DNS會返回多個A記錄，這些記錄都是指向后端Pod的。Kube-proxy代理不會處理這個服務，在服務的前端也沒有負載均衡器。但是endpoints controller還是會創建Endpoints,在訪問服務的時候返回后端的全部的Pod IP地址。
創建pod
[root@master-01 ~]# cat busybox-deploy.yaml
創建service
[root@master-01 ~]# cat busybox-svc-headless.yaml
查看狀態
可以看到CLUSTER-IP 為None了，
[root@master-01 ~]# kubectl get svc,ep,po
以上可以看出后端的pod列表已經加到該svc。
我們進容器中通過service名字是否能夠解析訪問到pod
查看dns域
root@busybox-deploy-b47575595-khxsp:/# cat /etc/resolv.conf
可以看到以上的A記錄，解析出的是pod的ip地址
1.普通 Service：解析成 ClusterIP
2.Headless Service：解析為指定 Pod的IP列表，Serivce域名也起到了通過dns做負載的能力。
往期文章一覽
2、Kubernetes集群搭建之企業級環境中基於Harbor搭建自己的私有倉庫
4、Kubernetes集群搭建之CNI-Flanneld部署篇**
6、Kubernetes系列之Coredns and Dashboard介紹篇
7、Kubernetes系列之監控Metres-server實戰篇
如果您覺得不錯，請別忘了轉發、分享、點贊讓更多的人去學習， 您的舉手之勞，就是對小編最好的支持，非常感謝！
