问题描述
在Kubernetes中，git push origin与container port有何区别？
它们可以互换使用吗？如果可以，为什么？
我遇到了下面的代码段，其中targetports用来表示Kubernetes中一个pod上的containerPort。
port在上面的代码片段中，他们为apiVersion: apps/v1
kind: Deployment
Metadata:
name: postgres-deployment
labels:
app: demo-voting-app
spec:
replicas: 1
selector:
matchLabels:
name: postgres-pod
app: demo-voting-app
template:
Metadata:
name: postgres-pod
labels:
name: postgres-pod
app: demo-voting-app
spec:
containers:
- name: postgres
image: postgres:9.4
ports:
- containerPort: 5432
参数提供了5432（在最后一行）。那么，containerPort与containerPort有何不同？
据我所知，术语targetport通常是指port（Kubernetes）上的port。如果我不正确，请纠正我。
解决方法
简而言之： 0.0.0.0/0和targetPort基本上指的是同一端口（因此，如果两者都使用，则它们的值应相同），但是它们使用的是相同的端口在两种不同的情况下具有完全不同的目的。
它们不能互换使用，因为它们都是两个不同的kubernetes资源/对象的规范的一部分：分别为containerPort和Service。虽然Pod的目的可以视为纯粹参考性的，但containerPort却需要targetPort，而Service则需要公开Pods的集合。
重要的是要理解，通过在containerPort / Pod规范中声明具有特定值的Deployment，您将无法使Pod暴露此特定端口，例如如果您在containerPort字段中声明nginx Pod公开了端口8080而不是默认的80，则仍需要在容器中配置nginx服务器以侦听此端口
在containerPort规范中声明Pod是可选的。即使没有它，您的Service也会根据在其targetPort中声明的信息知道将请求定向到何处。
请记住，不需要在targetPort定义中声明Service。如果省略它，则默认为您为port声明的值（这是Service本身的端口）。
容器规范中的ContainerPort
要从容器公开的端口列表。在此处公开端口可为系统提供有关容器使用的网络连接的其他信息，但主要是参考信息。在此处未指定端口并不能防止该端口暴露
服务规范中的targetPort
要在服务目标的Pod上访问的端口号或名称。数字必须在1到65535之间。名称必须是IANA_SVC_NAME。如果是字符串，它将在目标Pod的容器端口中查找为命名端口。如果未指定，则使用“端口”字段的值（身份映射）。
因此，服务中的targetPort必须与pod规范中的containerPort相匹配，因为这是服务知道如何将目的地转发到哪个容器端口的方式。
containerPort 是可以访问容器内的应用程序的端口。
targetPort 是端口，它暴露在集群中，服务将 pod 连接到其他服务或用户。