Kubernetes Service 完整实战指南类型选型、服务发现与生产级网络配置【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agentsService 是 Kubernetes 中为 Pod 提供稳定网络访问端点的核心抽象也是微服务架构中服务发现与负载均衡的基石。本文以 k8s-manifest-generator 技能的 service-spec.md 规范文档为主体结合本仓库内可直接复用的 service-template.yaml 模板与相关源码佐证系统讲解四种 Service 类型、端口与亲和性配置、流量策略、服务发现机制、负载均衡与排障方法帮助你写出可投入生产的 Service 清单。一、Service 是什么稳定网络端点的价值Service 为动态变化的 Pod 集合提供稳定的网络入口。Pod 的 IP 会随着重建、扩缩容、调度漂移而不断变化而 Service 提供了一层稳定的抽象通过selector标签选择后端 Pod由 kube-proxy / kube-dns 等组件维护 IP 与端点映射从而实现服务发现Service Discovery客户端只需知道 Service 名称无需关心后端 Pod IP 变化负载均衡Load Balancing流量自动分发到满足选择器的多个 Pod 上松耦合Loose Coupling微服务之间通过服务名交互解耦部署与拓扑变化。从源码结构看本仓库的 k8s-manifest-generator 技能将 Service 定义为「Define Service resources for network connectivity」的核心能力之一并在 details.md 的工作流中将其作为 Deployment 之后的第二步「Create Service Manifest」——先定义工作负载再为其建立网络端点。二、四种 Service 类型选型与完整示例spec.type决定 Service 的暴露方式共有四种类型。1. ClusterIP默认类型集群内部访问将 Service 暴露在集群内部虚拟 IP 上仅集群内可访问。所有未显式指定type的 Service 默认都是 ClusterIP。apiVersion: v1 kind: Service metadata: name: backend-service namespace: production spec: type: ClusterIP selector: app: backend ports: - name: http port: 80 targetPort: 8080 protocol: TCP sessionAffinity: None典型使用场景内部微服务通信、数据库服务、内部 API、消息队列。2. NodePort节点静态端口暴露在每个节点的固定端口30000-32767上暴露 Service通过NodeIP:nodePort从集群外部访问。apiVersion: v1 kind: Service metadata: name: frontend-service spec: type: NodePort selector: app: frontend ports: - name: http port: 80 targetPort: 8080 nodePort: 30080 # 可选省略时自动分配 protocol: TCP使用场景开发/测试的外部访问、没有负载均衡器的小规模部署、需要直连节点的场景。限制端口范围受限30000-32767需要自行处理节点故障节点之间没有内置负载均衡。3. LoadBalancer云厂商负载均衡器通过云厂商的负载均衡器将 Service 暴露到公网通常依赖云环境提供的实现如 AWS NLB、Azure LB、GCP LB。apiVersion: v1 kind: Service metadata: name: public-api annotations: service.beta.kubernetes.io/aws-load-balancer-type: nlb service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing spec: type: LoadBalancer selector: app: api ports: - name: https port: 443 targetPort: 8443 protocol: TCP loadBalancerSourceRanges: - 203.0.113.0/24loadBalancerSourceRanges用于限定允许访问的来源 IP 网段是公网服务的安全基线。云厂商特定注解AWSNLB / CLBannotations: service.beta.kubernetes.io/aws-load-balancer-type: nlb # 或 external service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled: true service.beta.kubernetes.io/aws-load-balancer-ssl-cert: arn:aws:acm:... service.beta.kubernetes.io/aws-load-balancer-backend-protocol: httpAzureannotations: service.beta.kubernetes.io/azure-load-balancer-internal: true service.beta.kubernetes.io/azure-pip-name: my-public-ipGCPannotations: cloud.google.com/load-balancer-type: Internal cloud.google.com/backend-config: {default: my-backend-config}本仓库的 service-template.yaml 中 Template 2 给出了生产可用的 LoadBalancer 模板并注释了externalTrafficPolicy: Local保留客户端真实 IP与可选的loadBalancerSourceRanges白名单# Template 2: LoadBalancer Service (External Access) apiVersion: v1 kind: Service metadata: name: app-name-lb namespace: namespace labels: app.kubernetes.io/name: app-name annotations: service.beta.kubernetes.io/aws-load-balancer-type: nlb service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled: true spec: type: LoadBalancer externalTrafficPolicy: Local # 保留客户端 IP selector: app.kubernetes.io/name: app-name ports: - name: http port: 80 targetPort: http protocol: TCP - name: https port: 443 targetPort: https protocol: TCP # loadBalancerSourceRanges: # - 203.0.113.0/244. ExternalName映射外部 DNS 名称返回一条 CNAME 记录将 Service 名称映射到集群外的 DNS 域名不产生 selector 与端点。apiVersion: v1 kind: Service metadata: name: external-db spec: type: ExternalName externalName: db.external.example.com ports: - port: 5432使用场景访问外部托管服务如云数据库、服务迁移过渡期内外地址无缝切换、多集群服务引用。三、完整 Service 规范逐字段解读规范文档给出了一份覆盖全部核心字段的完整示例这里是结合本仓库模板扩充注释后的生产级版本apiVersion: v1 kind: Service metadata: name: my-service namespace: production labels: app: my-app tier: backend annotations: description: Main application service prometheus.io/scrape: true spec: # Service 类型ClusterIP / NodePort / LoadBalancer / ExternalName type: ClusterIP # Pod 选择器决定流量转发到哪些 Pod selector: app: my-app version: v1 # 端口配置 ports: - name: http port: 80 # Service 端口虚拟端口 targetPort: 8080 # 容器端口或具名端口 protocol: TCP # TCP、UDP 或 SCTP # 会话亲和性None默认或 ClientIP sessionAffinity: ClientIP sessionAffinityConfig: clientIP: timeoutSeconds: 10800 # 亲和性超时默认 3 小时 # IP 配置 clusterIP: 10.0.0.10 # 可选指定集群 IP clusterIPs: - 10.0.0.10 ipFamilies: - IPv4 ipFamilyPolicy: SingleStack # 外部流量策略Cluster默认或 Local externalTrafficPolicy: Local # 内部流量策略Cluster默认或 Local internalTrafficPolicy: Local # 健康检查端口externalTrafficPolicyLocal 时用于节点健康检查 healthCheckNodePort: 30000 # LoadBalancer 配置仅 type: LoadBalancer 生效 loadBalancerIP: 203.0.113.100 loadBalancerSourceRanges: - 203.0.113.0/24 # 外部 IP将流量转发到指定外部 IP externalIPs: - 80.11.12.10 # 是否发布未就绪 Pod 的地址 publishNotReadyAddresses: false注意本仓库模板中对标签体系的规范service-template.yaml的 7 个模板统一使用app.kubernetes.io/name与app.kubernetes.io/instance作为选择器标签这与 details.md 推荐的 Kubernetes 标准推荐标签app.kubernetes.io/name、instance、version、component、part-of、managed-by一致确保 Deployment 与 Service 的选择器天然对齐。四、端口配置具名端口与多端口具名端口Named Ports为容器端口命名后Service 的targetPort可以直接引用名称从而把「Service 端口」与「容器端口」解耦——调整容器端口时无需修改 Service。Deployment 侧spec: template: spec: containers: - name: app ports: - name: http containerPort: 8080 - name: metrics containerPort: 9090Service 侧spec: ports: - name: http port: 80 targetPort: http # 引用具名端口 - name: metrics port: 9090 targetPort: metrics多端口一个 Service 可以同时暴露多个协议端口但必须为每个端口指定namespec: ports: - name: http port: 80 targetPort: 8080 protocol: TCP - name: https port: 443 targetPort: 8443 protocol: TCP - name: grpc port: 9090 targetPort: 9090 protocol: TCP仓库中的 service-template.yaml Template 5 给出了「多端口 指标端口」的完整示例同时暴露 http、https、grpc、metrics 四个端口并配置 Prometheus 抓取注解可直接套用到可观测性改造场景。五、会话亲和性Session Affinity会话亲和性决定来自同一客户端的请求是否总是被路由到同一个 Pod。None默认请求在 Pod 之间随机分发适合无状态服务。spec: sessionAffinity: NoneClientIP来自同一客户端 IP 的请求被路由到同一 Pod适用于有状态或会话型应用。spec: sessionAffinity: ClientIP sessionAffinityConfig: clientIP: timeoutSeconds: 10800 # 3 小时使用场景有状态应用、基于会话的应用、WebSocket 长连接。仓库 Template 6 提供了可直接使用的「粘性会话」模板app-name-sticky默认timeoutSeconds: 108003 小时。六、流量策略外部与内部External Traffic Policy外部流量策略策略行为特点Cluster默认跨所有节点负载均衡可能引入额外网络跳数客户端源 IP 被隐藏SNATLocal流量只发送到接收节点上的 Pod保留客户端真实源 IP性能更好无额外跳数可能导致节点间负载不均spec: externalTrafficPolicy: LocalInternal Traffic Policy内部流量策略控制集群内部客户端Pod 间通信的流量路由同样支持Local或Cluster。Local时集群内流量只路由到本节点的 Pod可用于降低跨节点转发开销spec: internalTrafficPolicy: Local # 或 Cluster七、Headless Service无集群 IP 的直连模式将clusterIP设为None即创建 Headless Service不分配集群 IP、不做负载均衡DNS 直接返回后端 Pod 的 IP 列表适合 StatefulSet 场景。apiVersion: v1 kind: Service metadata: name: database spec: clusterIP: None # Headless selector: app: database ports: - port: 5432 targetPort: 5432使用场景StatefulSet 的 Pod 发现、Pod 间直连、自定义负载均衡、数据库集群。DNS 返回行为返回各 Pod 的独立 IP 而非 Service IP格式为pod-name.service-name.namespace.svc.cluster.local仓库 Template 4Headless Service额外展示了publishNotReadyAddresses: true的用法——将未就绪 Pod 也纳入 DNS 发布这在 StatefulSet 滚动启动阶段的集群成员发现中很关键。常见模式StatefulSet Headless ServiceapiVersion: v1 kind: Service metadata: name: cassandra spec: clusterIP: None selector: app: cassandra ports: - port: 9042 targetPort: 9042 --- apiVersion: apps/v1 kind: StatefulSet metadata: name: cassandra spec: serviceName: cassandra replicas: 3 selector: matchLabels: app: cassandra template: metadata: labels: app: cassandra spec: containers: - name: cassandra image: cassandra:4.0八、服务发现机制DNS 与环境变量集群内 DNSService 创建后自动注册到集群 DNS通常是 CoreDNS解析规则如下ClusterIP Service返回 Service 集群 IPservice-name.namespace.svc.cluster.local同命名空间内可直接使用短名curl http://backend-service跨命名空间使用全限定域名curl http://backend-service.production.svc.cluster.localHeadless Service返回各 Pod IPpod-name.service-name.namespace.svc.cluster.local环境变量注入Kubernetes 会将 Service 信息以环境变量形式注入 Pod# Service 主机与端口 BACKEND_SERVICE_SERVICE_HOST10.0.0.100 BACKEND_SERVICE_SERVICE_PORT80 # 具名端口的变量 BACKEND_SERVICE_SERVICE_PORT_HTTP80注意环境变量只在 Pod创建晚于 Service时才注入且命名基于 Service 名称大写转换——这也是生产环境推荐优先使用 DNS 而非环境变量做服务发现的原因。九、负载均衡与连接治理负载均衡算法Kubernetes 默认使用随机选择random分发流量。需要更精细的负载均衡策略时可借助服务网格Service Mesh例如 Istio 的DestinationRuleapiVersion: networking.istio.io/v1beta1 kind: DestinationRule metadata: name: my-destination-rule spec: host: my-service trafficPolicy: loadBalancer: simple: LEAST_REQUEST # 或 ROUND_ROBIN、RANDOM、PASSTHROUGH connectionPool: tcp: maxConnections: 100连接数与可用性保护通过 PodDisruptionBudget 保证滚动更新/节点维护期间的最小可用副本数避免连接被中断apiVersion: policy/v1 kind: PodDisruptionBudget metadata: name: my-app-pdb spec: minAvailable: 2 selector: matchLabels: app: my-app流量切分Istio VirtualService服务网格还能实现基于请求头的流量切分与金丝雀发布apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: name: my-service spec: hosts: - my-service http: - match: - headers: version: exact: v2 route: - destination: host: my-service subset: v2 - route: - destination: host: my-service subset: v1 weight: 90 - destination: host: my-service subset: v2 weight: 10本仓库 kubernetes-architect.md 代理同样将 Istio/Linkerd 流量管理、金丝雀发布列为服务网格核心能力可作为 Service 之上的进阶参考资料。十、五种常见落地模式模式 1内部微服务ClusterIPapiVersion: v1 kind: Service metadata: name: user-service namespace: backend labels: app: user-service tier: backend spec: type: ClusterIP selector: app: user-service ports: - name: http port: 8080 targetPort: http protocol: TCP - name: grpc port: 9090 targetPort: grpc protocol: TCP模式 2带负载均衡的公网 APIapiVersion: v1 kind: Service metadata: name: api-gateway annotations: service.beta.kubernetes.io/aws-load-balancer-type: nlb service.beta.kubernetes.io/aws-load-balancer-ssl-cert: arn:aws:acm:... spec: type: LoadBalancer externalTrafficPolicy: Local selector: app: api-gateway ports: - name: https port: 443 targetPort: 8443 protocol: TCP loadBalancerSourceRanges: - 0.0.0.0/0模式 3StatefulSet 的 Headless Service见第七节 Cassandra 示例模式 4外部服务映射除ExternalNameCNAME 方式外还可以通过自定义Endpoints将 Service 指向集群外的固定 IPapiVersion: v1 kind: Service metadata: name: external-api spec: ports: - port: 443 targetPort: 443 protocol: TCP --- apiVersion: v1 kind: Endpoints metadata: name: external-api subsets: - addresses: - ip: 203.0.113.100 ports: - port: 443这种方式适合连接没有 DNS 域名的外部系统如云厂商固定 IP 服务。模式 5带指标端口的 Web 服务apiVersion: v1 kind: Service metadata: name: web-app annotations: prometheus.io/scrape: true prometheus.io/port: 9090 prometheus.io/path: /metrics spec: type: ClusterIP selector: app: web-app ports: - name: http port: 80 targetPort: 8080 - name: metrics port: 9090 targetPort: 9090prometheus.io/*注解会被 Prometheus 的kubernetes_sd_configs自动发现机制识别与本仓库 configmap-template.yaml 中 Template 7 的 Prometheus 抓取配置__meta_kubernetes_pod_annotation_prometheus_io_scrape等 relabel 规则配套使用。十一、用 NetworkPolicy 加固 Service 流量Service 只负责流量转发不提供网络隔离。生产环境务必用 NetworkPolicy 控制流向 Service 后端 Pod 的流量。以下示例仅允许app: frontend的 Pod 访问app: backend的 8080 端口apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-frontend-to-backend spec: podSelector: matchLabels: app: backend policyTypes: - Ingress ingress: - from: - podSelector: matchLabels: app: frontend ports: - protocol: TCP port: 8080本仓库 k8s-security-policies 技能提供了 network-policy-template.yaml包含「默认拒绝一切」「放行 DNS」「Ingress Controller 放行」「Prometheus 抓取放行」「数据库访问」等 8 个可直接套用的策略模板与 Service 配套使用可形成完整的南北向 东西向安全边界。十二、最佳实践与生产检查清单配置要点使用具名端口解耦 Service 端口与容器端口提升可维护性按暴露需求选择类型内部通信用 ClusterIP开发测试用 NodePort公网用 LoadBalancer外部域名用 ExternalName标签与选择器保持一致Deployment 与 Service 的标签要严格对齐本仓库模板统一使用app.kubernetes.io/name/app.kubernetes.io/instance有状态应用配置会话亲和性需要保留源 IP 时设置externalTrafficPolicy: LocalStatefulSet 使用 Headless Service用 NetworkPolicy 实现安全隔离添加监控注解prometheus.io/scrape等以保障可观测性。生产检查清单Service 类型与使用场景匹配Selector 与 Pod 标签匹配使用具名端口提升可读性按需配置会话亲和性流量策略设置合理负载均衡器注解已配置如适用公网服务已限制来源 IP 范围健康检查配置已校验已添加监控注解已定义 NetworkPolicy性能调优参考高流量场景spec: externalTrafficPolicy: Local sessionAffinity: ClientIP sessionAffinityConfig: clientIP: timeoutSeconds: 3600WebSocket / 长连接场景spec: sessionAffinity: ClientIP sessionAffinityConfig: clientIP: timeoutSeconds: 86400 # 24 小时十三、排障指南Service 不可访问# 检查 Service 是否存在 kubectl get service service-name # 检查 Endpoints应显示 Pod IP为空说明 selector 没匹配上 kubectl get endpoints service-name # 查看 Service 详情 kubectl describe service service-name # 检查 Pod 是否匹配选择器 kubectl get pods -l appapp-name常见原因selector 与 Pod 标签不匹配、没有运行中的 PodEndpoints 为空、端口配置错误、NetworkPolicy 拦截流量。DNS 解析失败# 在 Pod 内测试 DNS 解析 kubectl run debug --rm -it --imagebusybox -- nslookup service-name # 检查 CoreDNS Pod 状态与日志 kubectl get pods -n kube-system -l k8s-appkube-dns kubectl logs -n kube-system -l k8s-appkube-dns负载均衡器异常# 查看负载均衡器状态EXTERNAL-IP 列 kubectl describe service service-name # 查看相关事件 kubectl get events --sort-by.lastTimestamp # 验证云厂商配置节点标签、可用区等 kubectl describe node十四、在 k8s-manifest-generator 工作流中的定位根据 SKILL.md 的定义k8s-manifest-generator技能用于生成生产级 Kubernetes 清单Deployments、Services、ConfigMaps、Secrets、PVC。Service 清单的生成遵循 details.md 中的完整流程收集需求应用类型、端口、暴露需求创建 Deployment 清单参考 deployment-spec.md 与 deployment-template.yaml创建 Service 清单参考本文所述 service-spec.md 与 service-template.yaml创建 ConfigMap / Secret / PVC应用安全最佳实践添加标签与注解组织多资源清单---分隔 / 独立文件 / Kustomize验证与测试# 客户端 dry-run 校验 kubectl apply -f manifest.yaml --dry-runclient # 服务端校验 kubectl apply -f manifest.yaml --dry-runserver # 第三方校验工具 kubeval manifest.yaml kube-score score manifest.yaml kube-linter lint manifest.yaml其中service-template.yaml提供的 7 个模板ClusterIP、LoadBalancer、NodePort、Headless、多端口指标、会话亲和性、ExternalName覆盖了绝大多数生产场景配合本文的字段级解读即可快速生成合规、可运行的 Service 清单。更高阶的 GitOps 交付ArgoCD/Flux、Helm 打包等能力可进一步参考同仓库的 gitops-workflow 与 helm-chart-scaffolding 技能。【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agents创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Kubernetes Service 完整实战指南：类型选型、服务发现与生产级网络配置
Kubernetes Service 完整实战指南类型选型、服务发现与生产级网络配置【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agentsService 是 Kubernetes 中为 Pod 提供稳定网络访问端点的核心抽象也是微服务架构中服务发现与负载均衡的基石。本文以 k8s-manifest-generator 技能的 service-spec.md 规范文档为主体结合本仓库内可直接复用的 service-template.yaml 模板与相关源码佐证系统讲解四种 Service 类型、端口与亲和性配置、流量策略、服务发现机制、负载均衡与排障方法帮助你写出可投入生产的 Service 清单。一、Service 是什么稳定网络端点的价值Service 为动态变化的 Pod 集合提供稳定的网络入口。Pod 的 IP 会随着重建、扩缩容、调度漂移而不断变化而 Service 提供了一层稳定的抽象通过selector标签选择后端 Pod由 kube-proxy / kube-dns 等组件维护 IP 与端点映射从而实现服务发现Service Discovery客户端只需知道 Service 名称无需关心后端 Pod IP 变化负载均衡Load Balancing流量自动分发到满足选择器的多个 Pod 上松耦合Loose Coupling微服务之间通过服务名交互解耦部署与拓扑变化。从源码结构看本仓库的 k8s-manifest-generator 技能将 Service 定义为「Define Service resources for network connectivity」的核心能力之一并在 details.md 的工作流中将其作为 Deployment 之后的第二步「Create Service Manifest」——先定义工作负载再为其建立网络端点。二、四种 Service 类型选型与完整示例spec.type决定 Service 的暴露方式共有四种类型。1. ClusterIP默认类型集群内部访问将 Service 暴露在集群内部虚拟 IP 上仅集群内可访问。所有未显式指定type的 Service 默认都是 ClusterIP。apiVersion: v1 kind: Service metadata: name: backend-service namespace: production spec: type: ClusterIP selector: app: backend ports: - name: http port: 80 targetPort: 8080 protocol: TCP sessionAffinity: None典型使用场景内部微服务通信、数据库服务、内部 API、消息队列。2. NodePort节点静态端口暴露在每个节点的固定端口30000-32767上暴露 Service通过NodeIP:nodePort从集群外部访问。apiVersion: v1 kind: Service metadata: name: frontend-service spec: type: NodePort selector: app: frontend ports: - name: http port: 80 targetPort: 8080 nodePort: 30080 # 可选省略时自动分配 protocol: TCP使用场景开发/测试的外部访问、没有负载均衡器的小规模部署、需要直连节点的场景。限制端口范围受限30000-32767需要自行处理节点故障节点之间没有内置负载均衡。3. LoadBalancer云厂商负载均衡器通过云厂商的负载均衡器将 Service 暴露到公网通常依赖云环境提供的实现如 AWS NLB、Azure LB、GCP LB。apiVersion: v1 kind: Service metadata: name: public-api annotations: service.beta.kubernetes.io/aws-load-balancer-type: nlb service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing spec: type: LoadBalancer selector: app: api ports: - name: https port: 443 targetPort: 8443 protocol: TCP loadBalancerSourceRanges: - 203.0.113.0/24loadBalancerSourceRanges用于限定允许访问的来源 IP 网段是公网服务的安全基线。云厂商特定注解AWSNLB / CLBannotations: service.beta.kubernetes.io/aws-load-balancer-type: nlb # 或 external service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled: true service.beta.kubernetes.io/aws-load-balancer-ssl-cert: arn:aws:acm:... service.beta.kubernetes.io/aws-load-balancer-backend-protocol: httpAzureannotations: service.beta.kubernetes.io/azure-load-balancer-internal: true service.beta.kubernetes.io/azure-pip-name: my-public-ipGCPannotations: cloud.google.com/load-balancer-type: Internal cloud.google.com/backend-config: {default: my-backend-config}本仓库的 service-template.yaml 中 Template 2 给出了生产可用的 LoadBalancer 模板并注释了externalTrafficPolicy: Local保留客户端真实 IP与可选的loadBalancerSourceRanges白名单# Template 2: LoadBalancer Service (External Access) apiVersion: v1 kind: Service metadata: name: app-name-lb namespace: namespace labels: app.kubernetes.io/name: app-name annotations: service.beta.kubernetes.io/aws-load-balancer-type: nlb service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled: true spec: type: LoadBalancer externalTrafficPolicy: Local # 保留客户端 IP selector: app.kubernetes.io/name: app-name ports: - name: http port: 80 targetPort: http protocol: TCP - name: https port: 443 targetPort: https protocol: TCP # loadBalancerSourceRanges: # - 203.0.113.0/244. ExternalName映射外部 DNS 名称返回一条 CNAME 记录将 Service 名称映射到集群外的 DNS 域名不产生 selector 与端点。apiVersion: v1 kind: Service metadata: name: external-db spec: type: ExternalName externalName: db.external.example.com ports: - port: 5432使用场景访问外部托管服务如云数据库、服务迁移过渡期内外地址无缝切换、多集群服务引用。三、完整 Service 规范逐字段解读规范文档给出了一份覆盖全部核心字段的完整示例这里是结合本仓库模板扩充注释后的生产级版本apiVersion: v1 kind: Service metadata: name: my-service namespace: production labels: app: my-app tier: backend annotations: description: Main application service prometheus.io/scrape: true spec: # Service 类型ClusterIP / NodePort / LoadBalancer / ExternalName type: ClusterIP # Pod 选择器决定流量转发到哪些 Pod selector: app: my-app version: v1 # 端口配置 ports: - name: http port: 80 # Service 端口虚拟端口 targetPort: 8080 # 容器端口或具名端口 protocol: TCP # TCP、UDP 或 SCTP # 会话亲和性None默认或 ClientIP sessionAffinity: ClientIP sessionAffinityConfig: clientIP: timeoutSeconds: 10800 # 亲和性超时默认 3 小时 # IP 配置 clusterIP: 10.0.0.10 # 可选指定集群 IP clusterIPs: - 10.0.0.10 ipFamilies: - IPv4 ipFamilyPolicy: SingleStack # 外部流量策略Cluster默认或 Local externalTrafficPolicy: Local # 内部流量策略Cluster默认或 Local internalTrafficPolicy: Local # 健康检查端口externalTrafficPolicyLocal 时用于节点健康检查 healthCheckNodePort: 30000 # LoadBalancer 配置仅 type: LoadBalancer 生效 loadBalancerIP: 203.0.113.100 loadBalancerSourceRanges: - 203.0.113.0/24 # 外部 IP将流量转发到指定外部 IP externalIPs: - 80.11.12.10 # 是否发布未就绪 Pod 的地址 publishNotReadyAddresses: false注意本仓库模板中对标签体系的规范service-template.yaml的 7 个模板统一使用app.kubernetes.io/name与app.kubernetes.io/instance作为选择器标签这与 details.md 推荐的 Kubernetes 标准推荐标签app.kubernetes.io/name、instance、version、component、part-of、managed-by一致确保 Deployment 与 Service 的选择器天然对齐。四、端口配置具名端口与多端口具名端口Named Ports为容器端口命名后Service 的targetPort可以直接引用名称从而把「Service 端口」与「容器端口」解耦——调整容器端口时无需修改 Service。Deployment 侧spec: template: spec: containers: - name: app ports: - name: http containerPort: 8080 - name: metrics containerPort: 9090Service 侧spec: ports: - name: http port: 80 targetPort: http # 引用具名端口 - name: metrics port: 9090 targetPort: metrics多端口一个 Service 可以同时暴露多个协议端口但必须为每个端口指定namespec: ports: - name: http port: 80 targetPort: 8080 protocol: TCP - name: https port: 443 targetPort: 8443 protocol: TCP - name: grpc port: 9090 targetPort: 9090 protocol: TCP仓库中的 service-template.yaml Template 5 给出了「多端口 指标端口」的完整示例同时暴露 http、https、grpc、metrics 四个端口并配置 Prometheus 抓取注解可直接套用到可观测性改造场景。五、会话亲和性Session Affinity会话亲和性决定来自同一客户端的请求是否总是被路由到同一个 Pod。None默认请求在 Pod 之间随机分发适合无状态服务。spec: sessionAffinity: NoneClientIP来自同一客户端 IP 的请求被路由到同一 Pod适用于有状态或会话型应用。spec: sessionAffinity: ClientIP sessionAffinityConfig: clientIP: timeoutSeconds: 10800 # 3 小时使用场景有状态应用、基于会话的应用、WebSocket 长连接。仓库 Template 6 提供了可直接使用的「粘性会话」模板app-name-sticky默认timeoutSeconds: 108003 小时。六、流量策略外部与内部External Traffic Policy外部流量策略策略行为特点Cluster默认跨所有节点负载均衡可能引入额外网络跳数客户端源 IP 被隐藏SNATLocal流量只发送到接收节点上的 Pod保留客户端真实源 IP性能更好无额外跳数可能导致节点间负载不均spec: externalTrafficPolicy: LocalInternal Traffic Policy内部流量策略控制集群内部客户端Pod 间通信的流量路由同样支持Local或Cluster。Local时集群内流量只路由到本节点的 Pod可用于降低跨节点转发开销spec: internalTrafficPolicy: Local # 或 Cluster七、Headless Service无集群 IP 的直连模式将clusterIP设为None即创建 Headless Service不分配集群 IP、不做负载均衡DNS 直接返回后端 Pod 的 IP 列表适合 StatefulSet 场景。apiVersion: v1 kind: Service metadata: name: database spec: clusterIP: None # Headless selector: app: database ports: - port: 5432 targetPort: 5432使用场景StatefulSet 的 Pod 发现、Pod 间直连、自定义负载均衡、数据库集群。DNS 返回行为返回各 Pod 的独立 IP 而非 Service IP格式为pod-name.service-name.namespace.svc.cluster.local仓库 Template 4Headless Service额外展示了publishNotReadyAddresses: true的用法——将未就绪 Pod 也纳入 DNS 发布这在 StatefulSet 滚动启动阶段的集群成员发现中很关键。常见模式StatefulSet Headless ServiceapiVersion: v1 kind: Service metadata: name: cassandra spec: clusterIP: None selector: app: cassandra ports: - port: 9042 targetPort: 9042 --- apiVersion: apps/v1 kind: StatefulSet metadata: name: cassandra spec: serviceName: cassandra replicas: 3 selector: matchLabels: app: cassandra template: metadata: labels: app: cassandra spec: containers: - name: cassandra image: cassandra:4.0八、服务发现机制DNS 与环境变量集群内 DNSService 创建后自动注册到集群 DNS通常是 CoreDNS解析规则如下ClusterIP Service返回 Service 集群 IPservice-name.namespace.svc.cluster.local同命名空间内可直接使用短名curl http://backend-service跨命名空间使用全限定域名curl http://backend-service.production.svc.cluster.localHeadless Service返回各 Pod IPpod-name.service-name.namespace.svc.cluster.local环境变量注入Kubernetes 会将 Service 信息以环境变量形式注入 Pod# Service 主机与端口 BACKEND_SERVICE_SERVICE_HOST10.0.0.100 BACKEND_SERVICE_SERVICE_PORT80 # 具名端口的变量 BACKEND_SERVICE_SERVICE_PORT_HTTP80注意环境变量只在 Pod创建晚于 Service时才注入且命名基于 Service 名称大写转换——这也是生产环境推荐优先使用 DNS 而非环境变量做服务发现的原因。九、负载均衡与连接治理负载均衡算法Kubernetes 默认使用随机选择random分发流量。需要更精细的负载均衡策略时可借助服务网格Service Mesh例如 Istio 的DestinationRuleapiVersion: networking.istio.io/v1beta1 kind: DestinationRule metadata: name: my-destination-rule spec: host: my-service trafficPolicy: loadBalancer: simple: LEAST_REQUEST # 或 ROUND_ROBIN、RANDOM、PASSTHROUGH connectionPool: tcp: maxConnections: 100连接数与可用性保护通过 PodDisruptionBudget 保证滚动更新/节点维护期间的最小可用副本数避免连接被中断apiVersion: policy/v1 kind: PodDisruptionBudget metadata: name: my-app-pdb spec: minAvailable: 2 selector: matchLabels: app: my-app流量切分Istio VirtualService服务网格还能实现基于请求头的流量切分与金丝雀发布apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: name: my-service spec: hosts: - my-service http: - match: - headers: version: exact: v2 route: - destination: host: my-service subset: v2 - route: - destination: host: my-service subset: v1 weight: 90 - destination: host: my-service subset: v2 weight: 10本仓库 kubernetes-architect.md 代理同样将 Istio/Linkerd 流量管理、金丝雀发布列为服务网格核心能力可作为 Service 之上的进阶参考资料。十、五种常见落地模式模式 1内部微服务ClusterIPapiVersion: v1 kind: Service metadata: name: user-service namespace: backend labels: app: user-service tier: backend spec: type: ClusterIP selector: app: user-service ports: - name: http port: 8080 targetPort: http protocol: TCP - name: grpc port: 9090 targetPort: grpc protocol: TCP模式 2带负载均衡的公网 APIapiVersion: v1 kind: Service metadata: name: api-gateway annotations: service.beta.kubernetes.io/aws-load-balancer-type: nlb service.beta.kubernetes.io/aws-load-balancer-ssl-cert: arn:aws:acm:... spec: type: LoadBalancer externalTrafficPolicy: Local selector: app: api-gateway ports: - name: https port: 443 targetPort: 8443 protocol: TCP loadBalancerSourceRanges: - 0.0.0.0/0模式 3StatefulSet 的 Headless Service见第七节 Cassandra 示例模式 4外部服务映射除ExternalNameCNAME 方式外还可以通过自定义Endpoints将 Service 指向集群外的固定 IPapiVersion: v1 kind: Service metadata: name: external-api spec: ports: - port: 443 targetPort: 443 protocol: TCP --- apiVersion: v1 kind: Endpoints metadata: name: external-api subsets: - addresses: - ip: 203.0.113.100 ports: - port: 443这种方式适合连接没有 DNS 域名的外部系统如云厂商固定 IP 服务。模式 5带指标端口的 Web 服务apiVersion: v1 kind: Service metadata: name: web-app annotations: prometheus.io/scrape: true prometheus.io/port: 9090 prometheus.io/path: /metrics spec: type: ClusterIP selector: app: web-app ports: - name: http port: 80 targetPort: 8080 - name: metrics port: 9090 targetPort: 9090prometheus.io/*注解会被 Prometheus 的kubernetes_sd_configs自动发现机制识别与本仓库 configmap-template.yaml 中 Template 7 的 Prometheus 抓取配置__meta_kubernetes_pod_annotation_prometheus_io_scrape等 relabel 规则配套使用。十一、用 NetworkPolicy 加固 Service 流量Service 只负责流量转发不提供网络隔离。生产环境务必用 NetworkPolicy 控制流向 Service 后端 Pod 的流量。以下示例仅允许app: frontend的 Pod 访问app: backend的 8080 端口apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-frontend-to-backend spec: podSelector: matchLabels: app: backend policyTypes: - Ingress ingress: - from: - podSelector: matchLabels: app: frontend ports: - protocol: TCP port: 8080本仓库 k8s-security-policies 技能提供了 network-policy-template.yaml包含「默认拒绝一切」「放行 DNS」「Ingress Controller 放行」「Prometheus 抓取放行」「数据库访问」等 8 个可直接套用的策略模板与 Service 配套使用可形成完整的南北向 东西向安全边界。十二、最佳实践与生产检查清单配置要点使用具名端口解耦 Service 端口与容器端口提升可维护性按暴露需求选择类型内部通信用 ClusterIP开发测试用 NodePort公网用 LoadBalancer外部域名用 ExternalName标签与选择器保持一致Deployment 与 Service 的标签要严格对齐本仓库模板统一使用app.kubernetes.io/name/app.kubernetes.io/instance有状态应用配置会话亲和性需要保留源 IP 时设置externalTrafficPolicy: LocalStatefulSet 使用 Headless Service用 NetworkPolicy 实现安全隔离添加监控注解prometheus.io/scrape等以保障可观测性。生产检查清单Service 类型与使用场景匹配Selector 与 Pod 标签匹配使用具名端口提升可读性按需配置会话亲和性流量策略设置合理负载均衡器注解已配置如适用公网服务已限制来源 IP 范围健康检查配置已校验已添加监控注解已定义 NetworkPolicy性能调优参考高流量场景spec: externalTrafficPolicy: Local sessionAffinity: ClientIP sessionAffinityConfig: clientIP: timeoutSeconds: 3600WebSocket / 长连接场景spec: sessionAffinity: ClientIP sessionAffinityConfig: clientIP: timeoutSeconds: 86400 # 24 小时十三、排障指南Service 不可访问# 检查 Service 是否存在 kubectl get service service-name # 检查 Endpoints应显示 Pod IP为空说明 selector 没匹配上 kubectl get endpoints service-name # 查看 Service 详情 kubectl describe service service-name # 检查 Pod 是否匹配选择器 kubectl get pods -l appapp-name常见原因selector 与 Pod 标签不匹配、没有运行中的 PodEndpoints 为空、端口配置错误、NetworkPolicy 拦截流量。DNS 解析失败# 在 Pod 内测试 DNS 解析 kubectl run debug --rm -it --imagebusybox -- nslookup service-name # 检查 CoreDNS Pod 状态与日志 kubectl get pods -n kube-system -l k8s-appkube-dns kubectl logs -n kube-system -l k8s-appkube-dns负载均衡器异常# 查看负载均衡器状态EXTERNAL-IP 列 kubectl describe service service-name # 查看相关事件 kubectl get events --sort-by.lastTimestamp # 验证云厂商配置节点标签、可用区等 kubectl describe node十四、在 k8s-manifest-generator 工作流中的定位根据 SKILL.md 的定义k8s-manifest-generator技能用于生成生产级 Kubernetes 清单Deployments、Services、ConfigMaps、Secrets、PVC。Service 清单的生成遵循 details.md 中的完整流程收集需求应用类型、端口、暴露需求创建 Deployment 清单参考 deployment-spec.md 与 deployment-template.yaml创建 Service 清单参考本文所述 service-spec.md 与 service-template.yaml创建 ConfigMap / Secret / PVC应用安全最佳实践添加标签与注解组织多资源清单---分隔 / 独立文件 / Kustomize验证与测试# 客户端 dry-run 校验 kubectl apply -f manifest.yaml --dry-runclient # 服务端校验 kubectl apply -f manifest.yaml --dry-runserver # 第三方校验工具 kubeval manifest.yaml kube-score score manifest.yaml kube-linter lint manifest.yaml其中service-template.yaml提供的 7 个模板ClusterIP、LoadBalancer、NodePort、Headless、多端口指标、会话亲和性、ExternalName覆盖了绝大多数生产场景配合本文的字段级解读即可快速生成合规、可运行的 Service 清单。更高阶的 GitOps 交付ArgoCD/Flux、Helm 打包等能力可进一步参考同仓库的 gitops-workflow 与 helm-chart-scaffolding 技能。【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agents创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考