APP
簡單說明：
port: 80 【本服務(wù)的集群端口】【服務(wù)會有獨立集群IP和DNS】
targetPort: 80【集群里的容器端口】
nodePort: 32180【本服務(wù)的集群外界端口】
?
容器網(wǎng)絡(luò)實例
?
?
服務(wù)中的3個端口設(shè)置
這幾個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 是提供給集群內(nèi)部客戶訪問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上到來的數(shù)據(jù)最終經(jīng)過kube-proxy流入到后端pod的targetPort上進(jìn)入容器。
port、nodePort總結(jié)
總的來說，port和nodePort都是service的端口，前者暴露給集群內(nèi)客戶訪問服務(wù)，后者暴露給集群外客戶訪問服務(wù)。從這兩個端口到來的數(shù)據(jù)都需要經(jīng)過反向代理kube-proxy流入后端pod的targetPod，從而到達(dá)pod上的容器內(nèi)。
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
當(dāng)service有了port和nodePort之后，就可以對內(nèi)/外提供服務(wù)。那么其具體是通過什么原理來實現(xiàn)的呢？奧妙就在kube-proxy在本地node上創(chuàng)建的iptables規(guī)則。
Kube-Proxy 通過配置 DNAT 規(guī)則（從容器出來的訪問，從本地主機(jī)出來的訪問兩方面），將到這個服務(wù)地址的訪問映射到本地的kube-proxy端口（隨機(jī)端口）。然后 Kube-Proxy 會監(jiān)聽在本地的對應(yīng)端口，將到這個端口的訪問給代理到遠(yuǎn)端真實的 pod 地址上去。
?
?
kube-proxy會在nat表里生成4個chain，分別如上所示（主要是從容器出來的訪問，從本地主機(jī)出來的訪問兩方面）。
創(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
主要將由網(wǎng)絡(luò)接口到來的通過服務(wù)集群入口<cluster ip>:port的請求重定向到本地kube-proxy端口（隨機(jī)端口）的映射，即來自本地容器的服務(wù)訪問請求；
注：我認(rèn)為，這種情況的網(wǎng)絡(luò)包不可能來自外部網(wǎng)絡(luò)，因為cluster ip是個virtual ip，外部網(wǎng)絡(luò)中不存在這樣的路由將該數(shù)據(jù)包發(fā)送到本機(jī)；所以該請求只能來自本地容器，從本地容器出來的訪問，服務(wù)訪問請求是通過本地容器虛擬網(wǎng)卡輸入到本地網(wǎng)絡(luò)接口的。
KUBE-NODEPORT-CONTAINER
主要將由網(wǎng)絡(luò)接口到來的通過服務(wù)集群外部入口<node ip>:nodePort的請求重定向到本地kube-proxy端口（隨機(jī)端口）的映射；即來自k8s集群外部網(wǎng)絡(luò)的服務(wù)訪問請求，可以來自本機(jī)容器，也可以來自其他node的容器，還可以來自其他node的進(jìn)程；
KUBE-PORTALS-HOST
主要將該node本地進(jìn)程通過服務(wù)集群入口<cluster ip>:port的請求重定向到本地kube-proxy端口（隨機(jī)端口）的映射。
KUBE-NODEPORT-HOST
主要將該node本地進(jìn)程通過服務(wù)集群外部入口<node ip>:nodePort的請求重定向到本地kube-proxy端口（隨機(jī)端口）的映射。
kube-proxy反向代理
不管是通過集群內(nèi)部服務(wù)入口<cluster ip>:port還是通過集群外部服務(wù)入口<node ip>:nodePort的請求都將重定向到本地kube-proxy端口（隨機(jī)端口）的映射，然后將到這個kube-proxy端口的訪問給代理到遠(yuǎn)端真實的 pod 地址上去。
一個例子
?
?
另外一個例子
?
?
?
歡迎一起討論
————————————————
版權(quán)聲明：本文為CSDN博主「xinghun_4」的原創(chuàng)文章，遵循CC 4.0 BY-SA版權(quán)協(xié)議，轉(zhuǎn)載請附上原文出處鏈接及本聲明。
原文鏈接：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/
