@@ -109,12 +109,45 @@ field.
109
109
{{< /note >}}
110
110
111
111
Port definitions in Pods have names, and you can reference these names in the
112
- ` targetPort` attribute of a Service. This works even if there is a mixture
113
- of Pods in the Service using a single configured name, with the same network
114
- protocol available via different port numbers.
115
- This offers a lot of flexibility for deploying and evolving your Services.
116
- For example, you can change the port numbers that Pods expose in the next
117
- version of your backend software, without breaking clients.
112
+ ` targetPort` attribute of a Service. For example, we can bind the `targetPort`
113
+ of the Service to the Pod port in the following way :
114
+
115
+ ` ` ` yaml
116
+ apiVersion: v1
117
+ kind: Pod
118
+ metadata:
119
+ name: nginx
120
+ labels:
121
+ app.kubernetes.io/name: proxy
122
+ spec:
123
+ containers:
124
+ - name: nginx
125
+ image: nginx:11.14.2
126
+ ports:
127
+ - containerPort: 80
128
+ name: http-web-service
129
+
130
+ ---
131
+ apiVersion: v1
132
+ kind: Service
133
+ metadata:
134
+ name: nginx-service
135
+ spec:
136
+ selector:
137
+ app.kubernetes.io/name: proxy
138
+ ports:
139
+ - name: name-of-service-port
140
+ protocol: TCP
141
+ port: 80
142
+ targetPort: http-web-service
143
+ ` ` `
144
+
145
+
146
+ This works even if there is a mixture of Pods in the Service using a single
147
+ configured name, with the same network protocol available via different
148
+ port numbers. This offers a lot of flexibility for deploying and evolving
149
+ your Services. For example, you can change the port numbers that Pods expose
150
+ in the next version of your backend software, without breaking clients.
118
151
119
152
The default protocol for Services is TCP; you can also use any other
120
153
[supported protocol](#protocol-support).
0 commit comments