Service資源在k8s上主要用來解決pod訪問問題；我們知道在k8s上pod由於各種原因重建，對於重建後的podip地址和名稱都是變化的，這樣一來使得我們訪問pod就變得有些不便；為了解決pod訪問能有一個固定的端點，在k8s上就是用service來解決的；簡單來講，service對象就是工作在節點上的一組iptables或ipvs規則，用於將到達service對象ip地址的流量調度轉發至相應endpoint對象指向的ip地址和埠之上；
工作於每個節點的kube-proxy組件通過apiserver持續監控著各service及其關聯的pod對象，並將其創建或變動實時反映至當前工作節點上相應的iptables或ipvs規則；其實service和pod或其他資源的關聯，本質上不是直接關聯，它依靠一個中間組件endpoint；endpoint主要作用就是引用後端pod或其他資源（比如k8s外部的服務也可以被endpoint引用）；所謂endpoint就是ip地址+埠；
提示：在k8s上kube-proxy它會監視著apiserver上的service資源變動，及時將變動轉化為本機的iptables或ipvs規則；對應客戶端pod訪問對應serverpod，報文首先會從本機的iptables或ipvs規則所匹配，然後再由對應規則邏輯把請求調度到對應的pod上；
service代理模式模式
在k8s上service代理模式有三種，早期的k8s版本（1.1之前包含1.1的版本）默認的代理模式為userspace，後面的版本（1.11起）默認代理模式為ipvs，如果對應ipvs的模塊沒有加載，它會自動降級為iptables;
userspace代理模式
提示：userspace是指Linux作業系統上的用戶空間；在這種代理模型下iptables只是做轉發並不調度，對應調度由kube-proxy完成；userspace這種調度模型用戶請求從內核空間到用戶空間再到內核空間，性能效率比較低下；
iptables代理模式
提示：iptables這種代理模式，對於每個service對象，kube-proxy會創建iptables規則直接捕獲到達Clusterip和port的流量，並將其重定向至當前service對象的後端pod資源；對於每個endpoint對象，service資源會為其創建iptables規則並關聯至挑選的後端pod資源對象；相對於userspace代理模式來說，該模式用戶請求無須在用戶空間和內核空間來回切換，因此效率高效；此種模式下kube-proxy就只負責生成iptalbes規則，調度有iptables規則完成；
ipvs代理模式
提示：ipvs代理模式，kube-proxy會跟蹤apiserver上service和endpoint對象的變動，據此來調用netlink接口創建ipvs規則，並確保與apiserver中的變動保持同步；這種模式與iptables的模式不同之處僅在於其請求調度由ipvs完成，餘下其他功能仍由iptables完成；比如流量捕獲，nat等等功能都會由iptables完成；ipvs代理模型類似iptables模型，ipvs構建於netfilter的鉤子函數之上，但它使用hash表作為底層數據結構並工作於內核空間，因此具有流量轉發速度快，規則同步性能好的特點，除此之外，ipvs還支持眾多調度算法，比如rr，lc，sh，dh等等；
service類型
在k8s上service的類型有4種，第一種是clusterIP，我們在創建service資源時，如果不指定其type類型，默認就是clusterip；第二種是NodePort類型，第三種是LoadBalancer，第四種是ExternalName；不同類型的service，其功能和作用也有所不同；
ClusterIP
提示：如上所示，ClusterIP類型的service就是在k8s節點上創建一個滿足serviceip地址的iptables或ipvs規則；這種類型的service的ip地址一定是我們在初始化集群時，指定的service網絡（10.96.0.0/12）中的地址；這也意味著這種類型service不能被集群外部客戶端所訪問，僅能在集群節點上訪問；
NodePort
提示：NodePort類型的service，是建構在ClusterIP的基礎上做的擴展，主要解決了集群外部客戶端訪問問題；如上圖所示，NodePort類型service在創建時，它會每個節點上創建一條DNAT規則，外部客戶端訪問集群任意節點的指定埠，都會被DNAT到對應的service上，從而實現訪問集群內部Pod；對於集群內部客戶端的訪問它還是通過ClusterIP進行的；NodePort類型service與ClusterIP類型service唯一不同的是，NodePort類型service能夠被外部客戶端所訪問，在集群每個節點上都有對應的DNAT規則；
LoadBalancer
提示：LoadBalancer這種類型的service是在NodePort的基礎上做的擴展，這種類型service只能在底層是雲環境的K8s上創建，如果底層是非雲環境，這種類型無法實現，只能手動搭建反向代理進行對NodePort類型的service進行反代；它主要解決NodePort類型service被集群外部訪問時的埠映射以及負載；
ExternalName
提示：ExternalName這種類型service主要用來解決對應service引用集群外部的服務；我們知道對於service來說，它就是一條iptables或ipvs規則，對於後端引用的資源是什麼，取決於對應endpoint關聯的是什麼資源的ip地址和埠；如果我們需要在集群中使用集群外部的服務，我們就可以創建ExternalName類型的service，指定後端關聯外部某個服務端ip地址或域名即可；它的工作流程如上圖所示，在集群內部客戶端訪問對應service時，首先要去core-DNS上查詢對應域名的ip地址，然後再根據dns返回的ip地址去連接對應的服務；使用這種類型service的前提是對應的coredns能夠連接到外部網絡解析對應的域名；
service資源的創建
示例：創建ClusterIP類型的service
提示：在創建service資源時，主要要需要在spec欄位中指定port和targetPort，port是service的埠，targetPort是後端資源的埠；其次就是需要定義標籤選擇器，這裡的標籤選擇器用selector欄位指定，它的值是一個字典，即kv鍵值對；默認不指定type類型就是使用的ClusterIP類型，默認不指定ClusterIP就表示自動生成對應的ClusterIP；
應用資源清單
驗證：訪問對應的ClusterIP看看是否能夠訪問到對應的資源？
提示：可以看到訪問對應serviceip地址能夠訪問到對應的pod；
查看service詳細信息
提示：可以看到對應service的type類型為ClusterIP，port為80，targetPort為80，endpoins對應了3個podip地址+targetPort；其實在創建service時，系統默認會創建一個同service相同名稱的endpoints；
查看endpoints
提示：可以看到ngx-dep-svc這個endpoint關聯了3個podip地址；
示例：創建NodePort類型service
提示：創建nodeport類型service需要在spec欄位中使用type欄位來指定其類型為NodePort；只有type的值為NodePort，對應ports欄位中指定的nodePort 才有意義，默認不指定它會隨機生成一個埠，指定nodePort就相當於固定了埠；通常不建議指定nodePort；
應用資源配置清單
提示：可以看到nodeport類型的service，對應port就有兩個值，後面的30080就是外部客戶端訪問集群內部資源的埠；
驗證：使用瀏覽器訪問k8s任意節點的30080埠，看看是否能夠訪問到對應的pod？
提示：可以看到集群外部客戶端可以通過訪問集群節點上的一個埠實現訪問對應集群內部資源；
示例：創建ExternalName類型service
提示：以上配置清單表示創建一個名為
的Service，對應Service的類型為ExternalName；引用外部服務為
應用資源配置清單
提示：可以看到應用配置清單以後，service詳細信息中，沒有標籤，沒有選擇器，沒有ip地址；只有externalName和對應targetPort；
測試：把dns伺服器地址指向coredns,然後訪問對應服務名稱，看看對應服務是否會有響應？
提示：可以看到訪問對應服務名稱，響應碼是302，說明我們的請求被代理出去了；
進入任意pod內部，使用nslookup查詢coredns上對應服務名稱是否能夠解析？
提示：可以看到對應服務名稱也能正常被解析；
示例：創建無頭service
提示：所謂無頭service是指沒有clusterIP的service，我們知道clusterip是service作為訪問後端pod的入口，那麼沒有clusterip，它怎麼訪問後端pod呢？沒有ip地址我們只能使用名稱來訪問；在k8s上無頭service默認會被coredns把對應名稱的service解析為後端關聯的多個pod地址；
應用資源配置清單
提示：可以看到對應service沒有clusterIP；
驗證：進入任意pod，使用名稱訪問service，看看對應名稱是否能夠訪問到pod？
提示：在pod內部使用名稱service名稱可以訪問到對應的pod；
驗證：查看coredns是否將對應service名稱解析為對應擁有service指定的標籤選擇器的podip呢？
提示：可以看到coredns把對應名稱解析成了3個地址；這三個地址都是對應pod上擁有service指定的標籤選擇器上的標籤的podip地址；
配置k8s使用ipvs代理模式
編寫加載ipvs相關模塊腳本
提示：以上腳本主要做了一件事，就是把ipvs_mods_dir所指定的目錄下的所有模塊加載到內核；
給腳本添加執行權限
複製該腳本到其他節點
提示：把腳本放在/etc/sysconfig/modules目錄下以點modules結尾的腳本，在系統重啟以後，它會自動執行對應目錄下的腳本；
執行腳本，加載模塊
驗證：查看對應模塊是否加載？
提示：能夠看到以上信息表示ipvs相關模塊已經加載；
編輯kube-proxy的配置
修改mode欄位的值為「ipvs」，然後保存退出
刪除現有k8s kube-proxy pod
提示：kube-proxy是一個ds控制器所管理的pod，它能容忍主節點上的汙點在集群每個節點上創建對應pod；我們手動刪除它，對應控制器會重新新建對應數量的pod，從而實現應用新配置的目的；生產環境不提倡這樣修改，應該在集群初始化前就規劃好使用哪種代理模式；
驗證：在集群任意節點安裝ipvs客戶端工具，看看是否有對應的ipvs規則生成？
安裝ipvsadm
使用ipvsadm查看是否生成的有ipvs規則？
提示：能夠看到有ipvs規則生成，說明此時k8s就是使用的ipvs代理模式；