作为pod定义的一部分，containerPort仅供参考，如果您希望将其作为集群或节点中的服务公开，则最终必须创建一个服务。
回答你的问题，是的，只要把它作为Kubernetes服务的一部分公开就足够了。作为pod定义的一部分提及它是一个很好的做法，这样当有人查看定义时就可以理解容器服务运行的端口。
这是非常好的解释here
Kubernetes官方参考文档

容器公开的端口和服务的端口在Kubernetes中是不同的概念。
如果你想为你的应用创建一个服务，你的pod必须有一个端口。例如，这是一个pod yaml：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx
spec:
  selector:
    matchLabels:
      run: my-nginx
  replicas: 2
  template:
    metadata:
      labels:
        run: my-nginx
    spec:
      containers:
      - name: my-nginx
        image: nginx
        ports:
        - containerPort: 8080

containerPort设置应用将公开的端口。
要通过服务访问此应用程序，您必须使用以下yaml创建服务对象：

apiVersion: v1
kind: Service
metadata:
  name: my-nginx
  labels:
    run: my-nginx
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 8080
  selector:
    run: my-nginx

在这个yaml中，关键字port设置了服务的端口，targetPort是你的应用的端口，所以服务的端口是不同的。
以下是官方文档中的一个很好的定义：
Kubernetes服务是一种抽象，它定义了一组逻辑Pod以及访问它们的策略（有时称为微服务）。服务所针对的Pod集（通常）由标签选择器确定（请参阅下文，了解您可能希望服务没有选择器的原因）。

让我们举一个例子，并试图理解的帮助下，图。考虑一个集群有2个节点和一个服务。每个节点有2个pod和每个pod有2个容器，即应用容器和网络容器。
NodePort：30001（每个节点的群集级公开端口）
端口：80（服务端口）
targetPort：8080（应在Docker expose中提及相同的应用程序容器端口）
targetPort：80（应在Docker expose中提及相同的Web容器端口）
下面的图表应该能帮助我们更好地理解它。

有关参考和更多详细信息，请参阅以下链接https://theithollow.com/2019/02/05/kubernetes-service-publishing/

实际上，在我看来，有一种情况是pod.spec.ports[].containerPort被“使用”了。
我同意所有的，主要是它的信息，只有，考虑到设计的所有端口都可从吊舱。
但是，如果定义了ports[*].name。这将为端口提供一个Map，该端口可以通过服务进行外部寻址。这有助于简化端口Map。

$kubectl expose pod mypod --port=300 --target-port=MostfamousPort

端口由“名称”寻址，而不是实际端口ID

ports:
- containerPort: 80
  name: MostfamousPort