Azure AKS中typedef服务NodePort私网访问的问题与最佳实践咨询

一、NodePort Service的正确配置姿势 #

别把Service和Deployment塞在同一个YAML文件里，分开写才是最佳实践，维护起来更清晰。给你一个标准的NodePort Service配置示例：

apiVersion: v1
kind: Service
metadata:
  name: typedef-service
spec:
  type: NodePort
  selector:
    app: typedef  # 这里必须和你Deployment里Pod的label完全对应
  ports:
    - port: 8080  # Service内部的访问端口
      targetPort: 8080  # 对应Pod容器暴露的端口
      nodePort: 30007  # 可选，只能用30000-32767之间的端口，不写的话K8s会自动分配

核心注意点：selector和Pod的label必须完全匹配，否则Service找不到Pod；targetPort要和容器里启动的服务端口一致。

二、排查Expose命令失效的问题 #

如果你用kubectl expose deployment typedef-deployment --type=NodePort --port=8080 --target-port=8080没起作用，按下面步骤查：

• 先确认Deployment的label是不是正确，expose命令是自动用Deployment的selector来创建Service的
• 查Service有没有创建成功：kubectl get svc
• 看Service的详细事件，排查关联问题：kubectl describe svc typedef-service，重点看Endpoint是不是空的——如果是空的，就是Pod和Service的label没匹配上
• 确认Pod是Running状态：kubectl get pods，Pod没起来的话服务肯定访问不了

三、私网访问的验证方式 #

私网内访问的时候，直接用AKS节点的私网IP加上NodePort端口就行，比如http://<节点私网IP>:30007

• 拿节点私网IP的命令：kubectl get nodes -o wide，看INTERNAL-IP那列的地址
• 多节点集群的话，随便找一个节点的私网IP都能访问，AKS的NodePort会在所有节点上监听

四、最佳实践总结 #

• 分开管理资源配置：Deployment和Service各写一个YAML文件，方便版本控制和单独修改
• 尽量不指定固定NodePort：除非有特殊需求，让K8s自动分配端口，避免端口冲突
• 严格规范Label和Selector：这是Service关联Pod的核心，写错一个字符都不行
• 场景允许的话优先用ClusterIP+私网Ingress：如果私网内有多个服务要访问，ClusterIP配合私网Ingress比NodePort更灵活，NodePort适合简单的单服务私网访问场景
• 加安全限制：可以用NetworkPolicy配置只允许指定私网IP段访问这个NodePort Service，避免不必要的访问

内容的提问来源于stack exchange，提问作者ayaz basha