外部访问Kubernetes集群内服务的方法

Kubernetes 中 Service 默认使用 ClusterIP 类型，只能在集群内部网络访问。外部主机（开发机、公网客户端等）无法直接连通。本文介绍几种将集群内服务暴露给外部访问的主流方法，涵盖临时调试、私有化部署、云上生产等不同场景，并给出选型建议。

先分清"外部主机"是哪类

在动手之前，先确认你的"外部"到底是指什么：

• 集群外的主机（开发机、公网用户）—— 需要用下文介绍的几种暴露方式
• 同一集群内的其他 Pod / Namespace —— 不用折腾，直接通过 <service>.<namespace>.svc.cluster.local:<port> 即可访问（集群 DNS 内置支持）
• 本地开发临时调试 —— kubectl port-forward 是最快的选择

暴露方式

1. NodePort —— 临时或私有环境的最简单方案

在 Service 上指定 type: NodePort，Kubernetes 会在每个节点上开放一个固定端口（范围 30000–32767），将流量转发到后端 Pod。

apiVersion: v1
kind: Service
metadata:
  name: nodeport-demo
spec:
  type: NodePort
  selector:
    app: nginx
  ports:
    - port: 80
      targetPort: 80
      nodePort: 31000   # 30000–32767 范围，不指定则自动分配

外部通过 http://<任意节点IP>:31000 即可访问。

• 优点：零依赖，任何集群都能用
• 缺点：端口范围受限；节点 IP 变更后需要同步修改 DNS；节点挂了需要客户端自行重试
• 适用场景：临时演示、私有化环境过渡

2. LoadBalancer —— 云上标准方案

将 Service 类型设为 LoadBalancer，云厂商会自动创建外部负载均衡器并分配公网 IP。

apiVersion: v1
kind: Service
metadata:
  name: cloud-lb-demo
spec:
  type: LoadBalancer
  selector:
    app: nginx
  ports:
    - port: 80
      targetPort: 80

创建后通过 kubectl get svc 查看 EXTERNAL-IP 列获取公网地址。

• 优点：一键创建，自带健康检查和后端池管理
• 缺点：每个 LoadBalancer 单独计费；裸金属环境不能直接用（需要部署 MetalLB 等方案）
• 适用场景：云上生产环境暴露单个服务

3. Ingress —— 多服务统一入口（生产环境标配）

NodePort 和 LoadBalancer 工作在四层（IP + 端口），Ingress 工作在七层，可以按域名和路径路由请求，并支持 TLS 终止。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - host: my-app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-service
            port:
              name: http

使用 Ingress 需要在集群中先部署 Ingress Controller（如 nginx-ingress、traefik），Controller 本身通过 NodePort 或 LoadBalancer 对外暴露，Ingress 资源只定义路由规则。

• 优点：一个入口承载多个 Service，节省 LoadBalancer 费用；天然支持 HTTPS
• 缺点：仅适用于 HTTP/HTTPS，TCP/UDP 需要另外处理
• 适用场景：多服务、多域名的生产环境

4. ExternalIPs —— 裸金属固定 IP 方案

在 Service 中配置 externalIPs，将外部可路由的 IP 直接绑定到 Service 上。

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  type: ClusterIP
  externalIPs:
  - 192.0.2.10   # 某个能路由到集群节点的外部 IP
  ports:
  - port: 80
    targetPort: 8080

外部主机访问 192.0.2.10:80 即可到达后端服务。

• 优点：配置简单，适合传统 IDC 或裸金属环境
• 缺点：Kubernetes 不负责 IP 的路由配置，需要自行确保外部 IP 可以路由到集群节点
• 适用场景：节点已有固定外网 IP 的裸金属或 IDC 环境

5. kubectl port-forward —— 本地调试专用

kubectl port-forward 通过 kube-apiserver 在本地和集群之间建立一条安全隧道，将本地端口映射到集群内的 Service 或 Pod。

# 转发到 Service
kubectl port-forward svc/my-service 8080:80
# 转发到 Pod
kubectl port-forward pod/nginx-pod 8080:80
# 指定命名空间
kubectl port-forward -n prod svc/my-service 8080:80

执行后，访问 http://localhost:8080 即等同于访问集群内的 my-service:80。

工作原理：

localhost:8080  -->  kubectl  -->  kube-apiserver  -->  my-service:80  -->  Pod

请求经过 Service → Endpoint → Pod 的完整链路，但不需要 Service 本身是 NodePort 或 LoadBalancer 类型，也不需要集群对外暴露任何端口。

关键特性：

• 不走 Service 负载均衡：port-forward 随机选中一个 Pod 建立连接，不会轮询，没有健康检查。目标 Pod 重启后连接会断开。
• 依赖 kubectl 权限：只要能执行 kubectl get svc 就可以使用 port-forward，本质是 kube-apiserver 的代理转发。
• 命令运行期间有效：Ctrl+C 或进程退出即断开，不能用于长期服务。

适用场景： 本地开发调试、临时访问集群内数据库或中间件、排查微服务接口。

不适用场景： 生产环境对外提供服务、多人共享访问。

选型速查

方式对比

补充说明

hostPort 与 hostNetwork

这两种方式也能将 Pod 端口直接映射到节点上，让外部访问。但 Pod 调度到其他节点后 IP 会变，还需要处理端口冲突问题。生产环境一般不推荐使用，除非你对调度和网络有明确的掌控。

externalTrafficPolicy

LoadBalancer 和 NodePort 的 externalTrafficPolicy 默认值为 Cluster，所有节点都会转发流量，可能引入跨节点额外一跳。设为 Local 可以保留客户端源 IP，但要求流量只能发送到运行着目标 Pod 的节点，需要配合 session affinity 使用。

port-forward 常见误区

• "port-forward 可以共享给同事使用"：不可以。它只在你本地生效，除非额外搭建 SSH 隧道转发。
• "port-forward 等同于暴露 Service"：完全不同。它只是 kube-apiserver 的临时代理，不改变 Service 的网络可达性。
• "port-forward 比正式暴露更稳定"：不会。命令断开即失效，不适合任何需要持续在线的场景。