APP
簡單說明：
port: 80 【本服務的集群端口】【服務會有獨立集群IP和DNS】
targetPort: 80【集群里的容器端口】
nodePort: 32180【本服務的集群外界端口】
?
容器網絡實例
?
?
服務中的3個端口設置
這幾個port的概念很容易混淆，比如創(chuàng)建如下service：
apiVersion: v1
kind: Service
metadata:
labels:
name: app1
name: app1
namespace: default
spec:
type: NodePort
ports:
- <strong>port: 8080
targetPort: 8080
nodePort: 30062</strong>
selector:
name: app1
port
The port that the service is exposed on the service’s cluster ip (virsual ip). Port is the service port which is accessed by others with cluster ip.
即，這里的port表示：service暴露在cluster ip上的端口，<cluster ip>:port 是提供給集群內部客戶訪問service的入口。
nodePort
On top of having a cluster-internal IP, expose the service on a port on each node of the cluster (the same port on each node). You'll be able to contact the service on any<nodeIP>:nodePortaddress. So nodePort is alse the service port which can be accessed by the node ip by others with external ip.
首先，nodePort是kubernetes提供給集群外部客戶訪問service入口的一種方式（另一種方式是LoadBalancer），所以，<nodeIP>:nodePort 是提供給集群外部客戶訪問service的入口。
targetPort
The port on the pod that the service should proxy traffic to.
targetPort很好理解，targetPort是pod上的端口，從port和nodePort上到來的數據最終經過kube-proxy流入到后端pod的targetPort上進入容器。
port、nodePort總結
總的來說，port和nodePort都是service的端口，前者暴露給集群內客戶訪問服務，后者暴露給集群外客戶訪問服務。從這兩個端口到來的數據都需要經過反向代理kube-proxy流入后端pod的targetPod，從而到達pod上的容器內。
When a client connects to the VIP the iptables rule kicks in, and redirects the packets to the serviceproxy's own port (random port). The service proxy chooses a backend, and starts proxying traffic from the client to the backend. This means that service owers can choose any port they want without risk of collision.The same basic flow executes when traffic comes in through a nodePort or through a LoadBalancer, though in those cases the client IP does get altered.
kube-proxy與iptables
當service有了port和nodePort之后，就可以對內/外提供服務。那么其具體是通過什么原理來實現的呢？奧妙就在kube-proxy在本地node上創(chuàng)建的iptables規(guī)則。
Kube-Proxy 通過配置 DNAT 規(guī)則（從容器出來的訪問，從本地主機出來的訪問兩方面），將到這個服務地址的訪問映射到本地的kube-proxy端口（隨機端口）。然后 Kube-Proxy 會監(jiān)聽在本地的對應端口，將到這個端口的訪問給代理到遠端真實的 pod 地址上去。
?
?
kube-proxy會在nat表里生成4個chain，分別如上所示（主要是從容器出來的訪問，從本地主機出來的訪問兩方面）。
創(chuàng)建service以后，kube-proxy會自動在集群里的node上創(chuàng)建以下兩條規(guī)則：
KUBE-PORTALS-CONTAINER
KUBE-PORTALS-HOST
如果是NodePort方式，還會額外生成兩條：
KUBE-NODEPORT-CONTAINER
KUBE-NODEPORT-HOST
KUBE-PORTALS-CONTAINER
主要將由網絡接口到來的通過服務集群入口<cluster ip>:port的請求重定向到本地kube-proxy端口（隨機端口）的映射，即來自本地容器的服務訪問請求；
注：我認為，這種情況的網絡包不可能來自外部網絡，因為cluster ip是個virtual ip，外部網絡中不存在這樣的路由將該數據包發(fā)送到本機；所以該請求只能來自本地容器，從本地容器出來的訪問，服務訪問請求是通過本地容器虛擬網卡輸入到本地網絡接口的。
KUBE-NODEPORT-CONTAINER
主要將由網絡接口到來的通過服務集群外部入口<node ip>:nodePort的請求重定向到本地kube-proxy端口（隨機端口）的映射；即來自k8s集群外部網絡的服務訪問請求，可以來自本機容器，也可以來自其他node的容器，還可以來自其他node的進程；
KUBE-PORTALS-HOST
主要將該node本地進程通過服務集群入口<cluster ip>:port的請求重定向到本地kube-proxy端口（隨機端口）的映射。
KUBE-NODEPORT-HOST
主要將該node本地進程通過服務集群外部入口<node ip>:nodePort的請求重定向到本地kube-proxy端口（隨機端口）的映射。
kube-proxy反向代理
不管是通過集群內部服務入口<cluster ip>:port還是通過集群外部服務入口<node ip>:nodePort的請求都將重定向到本地kube-proxy端口（隨機端口）的映射，然后將到這個kube-proxy端口的訪問給代理到遠端真實的 pod 地址上去。
一個例子
?
?
另外一個例子
?
?
?
歡迎一起討論
————————————————
版權聲明：本文為CSDN博主「xinghun_4」的原創(chuàng)文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/xinghun_4/article/details/50492041
?
-------------------
kind: Service
apiVersion: v1
metadata:
name: examsoft-ui-manage
namespace: exam-reg-sys
labels:
app: examsoft-ui-manage
annotations:
kubesphere.io/alias-name: examsoft-ui-manage
kubesphere.io/creator: admin
spec:
ports:
- name: http-80
protocol: TCP
port: 32180
targetPort: 80
nodePort: 31824
selector:
app: examsoft-ui-manage
clusterIP: 10.233.63.168
clusterIPs:
- 10.233.63.168
type: NodePort
sessionAffinity: None
externalTrafficPolicy: Cluster
ipFamilies:
- IPv4
ipFamilyPolicy: SingleStack
本文摘自 ：https://www.cnblogs.com/
