服務可以提供負載平衡的能力，但它在使用中有以下限制:
K8s有四種服務。
svc基礎知識介紹
在Kubernetes集群中，每個節點運行壹個kube-proxy進程。Kube-proxy負責為服務實現壹種形式的VIP(虛擬IP)，而不是ExternalName的形式。在Kubernetes v1.0版本中，代理完全在用戶空間中。在Kubernetes v1.1版本中增加了Iptables代理，但不是默認的運行模式。從Kubernetes v1.2開始，默認情況下它是iptables代理。在Kubernetes v 1 . 8 . 0-beta 0中，添加了ipvs代理。
在Kubernetes版本1.14中默認使用Ipvs代理。
在Kubernetes v1.0版本中，服務是“TCP/UDP over IP”的概念。在Kubernetes v1.1版本中，增加了Ingress API(beta版)來表示“7層”(HTTP)服務。
為什麽不使用循環DNS？
DNS會緩存在很多客戶端，很多服務在訪問DNS解析域名得到地址後不會清空緩存，所以壹旦有了他的地址信息，無論訪問多少次，負載均衡都會失效。
在這種模式下，kube-proxy將監控Kubernetes服務對象和端點，調用netlink接口相應地創建ipvs規則，並定期將ipvs規則與Kubernetes服務對象和端點對象同步，以確保ipvs狀態與預期壹致。當訪問服務時，流量將被重定向到其中壹個後端pod。
與iptables類似，ipvs類似於netfilter的hook函數，但使用哈希表作為底層數據結構，在內核空間工作。這意味著ipv可以更快地重定向流量，並且在同步代理規則時具有更好的性能。此外，ipvs為負載平衡算法提供了更多選項，例如:
註意:ipvs模式假設在運行kube-proxy之前，IPVS內核模塊已經安裝在所有節點上。當kube-proxy在ipvs代理模式下啟動時，kube-proxy將驗證節點上是否安裝了IPVS模塊，如果沒有，kube-proxy將退回到iptables代理模式。
ClusterIP主要在各個節點使用iptables，將發送到clusterIP對應端口的數據轉發給kube-proxy。然後kube-proxy在內部實現了壹個負載均衡的方法，可以在這個服務下查詢對應pod的地址和端口，然後將數據轉發到對應pod的地址和端口。
為了實現圖上的功能，以下組件主要需要協同工作:
創建myapp-deploy.yaml文件。
創建服務信息
有時候妳不需要或者不想要負載平衡和壹個單獨的服務IP。在這種情況下，您可以通過將ClusterIP(spec.clusterIP)的值指定為“None”來創建壹個無頭服務。這種服務不分配集群IP，kube-proxy不會處理它們，平臺也不會對它們進行負載均衡和路由。
主要特點是通過無頭服務解決主機名和端口名的更改問題，即通過它進行綁定。
對於svc，壹旦創建成功，就會寫入coreDNS。當我們的svc被創建時，壹個主機名將被寫入coreDNS，寫入的格式是svc的名稱+命名空間的名稱+當前集群的域名。
意思是在無頭服務中，雖然它沒有ip，但仍然可以通過訪問域名來訪問服務下的pod。
nodePort的原理是在node上打開壹個端口，將該端口的流量導入到kube-proxy，再由kube-proxy進壹步發送到對應的pod。
負載平衡器和節點端口實際上是相同的方式。不同的是，loadBalancer比nodePort多了壹步，即可以調用雲提供商cloud provider來創建LB負載均衡，將流量分流到節點。
這種類型的服務可以通過返回CNAME及其值將服務映射到externalName字段的內容(例如，hub.yibo.cn)。ExternalName服務是服務的壹個特例。它沒有選擇器，也沒有定義端口或端點。相反，對於運行在集群之外的服務，它通過返回外部服務的別名來提供服務。
當查詢主機my-service時。default . SVC . cluster . local(SVC _ name . namespace . SVC . cluster . local)，群集的DNS服務將返回壹個值為my.database.example.com的CNAME記錄。對該服務的訪問方式與其他服務相同，唯壹的區別是重定向發生在DNS層，不執行代理或轉發。
Iptables詳細解釋:blogs.com/hongdada/p/9758939.html
blogs.com/LiuQizhong/p/11573173.html LVS詳解
blogs.com/fanqisoft/p/11579061.html