claude-skills kubernetes-specialist 网络参考指南Service 类型、Ingress、零信任 NetworkPolicy 与 Istio 流量治理实战【免费下载链接】claude-skills67 Specialized Skills for Full-Stack Developers. Transform Claude Code into your expert pair programmer.项目地址: https://gitcode.com/GitHub_Trending/claud/claude-skills本文以 claude-skills 仓库中kubernetes-specialist技能的网络参考文档skills/kubernetes-specialist/references/networking.md为主体系统讲解 Kubernetes 中四类 Service 的选型与配置、NGINX Ingress 的路由与注解、基于默认拒绝default-deny的零信任 NetworkPolicy、集群 DNS 机制以及 Istio 的 VirtualService / DestinationRule 流量治理。读完本文后你可以独立写出生产级的 Service / Ingress / NetworkPolicy 清单理解 EndpointSlice 这一现代端点发现机制并知道在何时加载仓库中同系列的更深层参考文档。这份参考文档在技能体系中的位置claude-skills 是一个面向全栈开发者的 Claude Code 技能集合其中 kubernetes-specialist 技能 专用于 Kubernetes 工作负载的部署与管理。从 SKILL.md 的 frontmatter 可以看到该技能声明output-format: manifests以清单文件为主要产出并定义了明确的触发词——其中就包含NetworkPolicy、Ingress、service mesh、multi-cluster等网络相关关键词其关联技能包括devops-engineer、cloud-architect、sre-engineer、security-reviewer等。SKILL.md 采用主文件 按需加载参考文档的分层设计其参考指南表格中明确标注当任务涉及 Services、Ingress、NetworkPolicies、DNS 时应加载references/networking.md即本文的主体文档。同目录下的 service-mesh.md、multi-cluster.md、gitops.md 则分别覆盖服务网格深度配置、跨集群网络与 GitOps 流水线是本文内容的自然延伸。该技能的核心工作流为五步分析需求 → 设计架构 → 实现清单声明式 YAML含资源限制与健康检查→ 加固RBAC、NetworkPolicy、最小权限→ 验证kubectl rollout status、kubectl get pods -w等命令确认健康状态必要时kubectl rollout undo回滚。其中加固一步直接要求实现 NetworkPolicies 做网络分段这正是本文第三部分的主题。Service 类型从集群内到集群外的四级抽象Kubernetes 的 Service 是 Pod 对外暴露服务的稳定入口。参考文档依次给出 ClusterIP、Headless、NodePort、LoadBalancer 四种类型的完整清单以下逐一展开。ClusterIP默认类型ClusterIP 是 Service 的默认类型它只在集群内部分配一个虚拟 IP。参考文档的示例是一个双端口服务同时暴露业务 HTTP 端口与 metrics 监控端口并开启了客户端 IP 会话保持apiVersion: v1 kind: Service metadata: name: web-app-service namespace: production labels: app: web-app spec: type: ClusterIP selector: app: web-app tier: frontend ports: - name: http port: 80 targetPort: 8080 protocol: TCP - name: metrics port: 9090 targetPort: metrics protocol: TCP sessionAffinity: ClientIP sessionAffinityConfig: clientIP: timeoutSeconds: 3600几个值得注意的配置点selector 多标签匹配app: web-app与tier: frontend是 AND 关系只有同时带这两个标签的 Pod 才会被纳入端点集合。targetPort的两种写法http端口直接写数值8080匹配容器监听的端口号metrics端口写的是字符串metrics表示引用 Pod 中声明了同名containerPort的端口。后者在镜像换端口时无需改 Service是更稳健的写法。sessionAffinity: ClientIP默认 Service 的负载均衡是无状态的同一客户端的请求可能被转发到不同后端 Pod。开启 ClientIP 保持后同一客户端 IP 在超时窗口内会稳定落到同一后端timeoutSeconds: 3600表示会话保持的过期时间为 1 小时。metrics 端口9090正是 SKILL.md 最佳实践第 8 条为 Prometheus 暴露 metrics 端点的落点——Service 层把监控流量与业务流量显式分端口管理。Headless Service配合 StatefulSetapiVersion: v1 kind: Service metadata: name: postgres-headless namespace: database spec: clusterIP: None # Headless selector: app: postgres ports: - name: postgres port: 5432 targetPort: 5432clusterIP: None声明了一个 Headless无头Service它不分配虚拟 IP也不做负载均衡而是为每个成员 Pod 直接生成一条 DNS 记录。这是 StatefulSet 场景如 PostgreSQL 这类有状态数据库的标准做法——集群内其他组件需要按实例寻址主从复制、指定连到第几个副本时Headless Service 提供的稳定 DNS 是唯一途径。具体 DNS 命名规则见下文DNS 与服务发现一节。NodePortapiVersion: v1 kind: Service metadata: name: external-app namespace: production spec: type: NodePort selector: app: external-app ports: - name: http port: 80 targetPort: 8080 nodePort: 30080 # Range: 30000-32767 protocol: TCPNodePort 在集群每个节点上都开放同一个端口外部流量可通过节点IP:nodePort访问。示例中nodePort: 30080显式指定了端口从文档注释可知可选范围是30000–32767若留空由 apiserver 从该范围自动分配。NodePort 适合开发测试环境或轻量级暴露场景参考文档最佳实践第 3 条也强调默认用 ClusterIP谨慎使用对外暴露类型。LoadBalancerapiVersion: v1 kind: Service metadata: name: public-web namespace: production annotations: service.beta.kubernetes.io/aws-load-balancer-type: nlb service.beta.kubernetes.io/aws-load-balancer-internal: false spec: type: LoadBalancer selector: app: web-app ports: - name: http port: 80 targetPort: 8080 - name: https port: 443 targetPort: 8443 loadBalancerSourceRanges: - 203.0.113.0/24 # Restrict source IPsLoadBalancer 类型会调用云厂商的负载均衡器 provisioning 流程。这个示例展示了两个关键控制面云厂商注解service.beta.kubernetes.io/aws-load-balancer-type: nlb让 AWS 创建网络型负载均衡NLB四层、更低延迟aws-load-balancer-internal: false表示创建公网 LB设为true则为内网 LB。这类注解是 Service 层对接云厂商行为的主要手段。loadBalancerSourceRanges以 CIDR 白名单方式限制 LB 只接受来自指定源网段的流量示例用203.0.113.0/24一个 RFC 5737 文档保留网段实际使用时应替换为你的真实出口网段做来源收敛。四种类型的选型逻辑可以概括为集群内部通信一律 ClusterIP需要按实例寻址用 Headless节点级简单暴露用 NodePort生产公网入口用 LoadBalancer或交给 Ingress 网关且始终配合源 IP 收敛。Ingress基于主机名与路径的统一入口NGINX Ingress多主机、版本路由与完整注解参考文档给出的 NGINX Ingress 示例同时覆盖了 TLS 终结、路径重写、强制跳转、请求体限制、限流和证书自动签发apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: web-ingress namespace: production annotations: nginx.ingress.kubernetes.io/rewrite-target: / nginx.ingress.kubernetes.io/ssl-redirect: true nginx.ingress.kubernetes.io/force-ssl-redirect: true nginx.ingress.kubernetes.io/proxy-body-size: 10m nginx.ingress.kubernetes.io/rate-limit: 100 cert-manager.io/cluster-issuer: letsencrypt-prod spec: ingressClassName: nginx tls: - hosts: - www.example.com - api.example.com secretName: example-tls rules: - host: www.example.com http: paths: - path: / pathType: Prefix backend: service: name: frontend-service port: number: 80 - host: api.example.com http: paths: - path: /v1 pathType: Prefix backend: service: name: api-service port: number: 8080 - path: /v2 pathType: Prefix backend: service: name: api-v2-service port: number: 8080这份清单的信息密度很高逐条解读ingressClassName: nginx显式声明由 nginx Ingress 控制器处理这是networking.k8s.io/v1版本 Ingress 的推荐写法。注解逐条含义rewrite-target: /——将匹配路径重写为/后再转发配合路径前缀路由做 URL 剥离ssl-redirect: true与force-ssl-redirect: true——把 HTTP 请求强制 301 跳转到 HTTPSproxy-body-size: 10m——限制上传请求体最大 10MB防止超大请求打爆后端rate-limit: 100——在入口层施加速率限制对应最佳实践第 7 条在 Ingress 层做限流cert-manager.io/cluster-issuer: letsencrypt-prod——由 cert-manager 按 ClusterIssuer 自动申请/续期 TLS 证书与tls.secretName: example-tls配合证书签发后写入该 Secret。TLS 块tls.hosts列出两个域名secretName指向存放证书与私钥的 Secret实现在入口网关处终结 TLS最佳实践第 5 条。按路径做 API 版本路由api.example.com下/v1前缀路由到api-service/v2前缀路由到api-v2-service——同一个域名下不同版本 API 落到不同 Service是网关层灰度/并行的典型形态。Path-Based Routing纯路径路由apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: app-ingress namespace: production spec: ingressClassName: nginx rules: - host: app.example.com http: paths: - path: /api pathType: Prefix backend: service: name: backend-api port: number: 8080 - path: / pathType: Prefix backend: service: name: frontend port: number: 80这是单域名下前后端分离的最常见拓扑/api/*走后端 API 服务8080其余路径走前端服务80。两个pathType均为Prefix/api比/更具体从 K8s Ingress 的匹配机制看更长的匹配前缀优先命中因此 API 请求不会被/规则截胡。NetworkPolicy构建零信任网络隔离参考文档将 NetworkPolicy 定性为零信任Zero Trust手段给出默认全拒 逐条放行的完整五件套。理解这组清单前先明确三个语义由文档示例体现podSelector: {}空选择器匹配命名空间内所有 PodpolicyTypes声明该策略作用于哪些方向Ingress/Egress声明了某个方向却不写任何规则条目即表示该方向全部拒绝ingress/egress规则列表中各条目之间是 OR 关系单条目内namespaceSelector与podSelector同时出现时为 AND 关系。Default Deny All默认全拒apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default-deny-all namespace: production spec: podSelector: {} policyTypes: - Ingress - Egress这是所有网络策略的起点production命名空间内所有 Pod 的入站与出站流量全部被默认拒绝。SKILL.md 的 MUST DO 清单同样要求实现 NetworkPolicies 做网络分段MUST NOT 清单则明确不允许无限制的网络访问default allow-all两者呼应了先拒绝、后放行的纪律。Allow Frontend to Backend分层放行apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: frontend-to-backend namespace: production spec: podSelector: matchLabels: tier: backend policyTypes: - Ingress ingress: - from: - podSelector: matchLabels: tier: frontend ports: - protocol: TCP port: 8080策略选择tier: backend的 Pod只放行来自同命名空间tier: frontendPod 的 TCP 8080 流量。注意podSelector是策略作用的目标from.podSelector才是来源条件——两者方向相反这是阅读 NetworkPolicy 时最容易混淆的地方。以tier分层标签组织流量方向也呼应了 SKILL.md 中一致地使用标签的要求。Backend to Database数据库入口收敛apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: backend-to-database namespace: production spec: podSelector: matchLabels: app: postgres policyTypes: - Ingress ingress: - from: - podSelector: matchLabels: tier: backend - namespaceSelector: matchLabels: name: production ports: - protocol: TCP port: 5432目标锁定app: postgres的 Pod只开放 5432 端口。from列表有两条 OR 规则第一条允许tier: backend的 Pod 访问第二条只带namespaceSelector要求命名空间带name: production标签允许production命名空间内任意 Pod 访问——从源码结构清单语义看这里是为同命名空间的运维/备份类组件预留的通道。需要提醒的是namespaceSelector.matchLabels要生效production命名空间本身必须预先打上name: production标签。Allow DNS and External HTTPS出站白名单apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-dns-and-https namespace: production spec: podSelector: matchLabels: tier: backend policyTypes: - Egress egress: - to: - namespaceSelector: matchLabels: name: kube-system ports: - protocol: UDP port: 53 - to: - namespaceSelector: {} ports: - protocol: TCP port: 443default-deny 之下Pod 连 DNS 都解析不了因此 Egress 策略必须显式放行出站流量。示例为tier: backendPod 开了两条通道到kube-system命名空间的 UDP 53——即 CoreDNS/kube-dns 服务保证名字解析可用namespaceSelector: {}空选择器匹配所有命名空间的 TCP 443——放行集群内任意命名空间的 HTTPS 出站外部 HTTPS 流量通常经 Egress Gateway 出去最终呈现为 443。这个DNS 443最小出站组合是把 default-deny 真正落地的关键一步。Cross-Namespace Communication跨命名空间授权apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-monitoring namespace: production spec: podSelector: matchLabels: app: web-app policyTypes: - Ingress ingress: - from: - namespaceSelector: matchLabels: name: monitoring podSelector: matchLabels: app: prometheus ports: - protocol: TCP port: 8080跨命名空间流量用namespaceSelectorpodSelector在同一条目内 AND 组合只允许monitoring命名空间中app: prometheus的 Pod需该命名空间带name: monitoring标签访问web-app的 8080 端口——即只给 Prometheus 抓取指标开一条精确通道而非放行整个监控命名空间。配合 SKILL.md 的 MUST DO 条目使用命名空间做逻辑隔离这套清单构成了一套可复制的分层零信任模板default-deny → 分层内部放行frontend→backend→db→ 最小出站DNS/HTTPS→ 跨命名空间最小授权monitoring。DNS 与服务发现Service DNS 命名规则参考文档给出三种 DNS 名称形态原文以清单片段呈现# Within same namespace http://web-app-service # Cross-namespace http://web-app-service.production.svc.cluster.local # Headless service (StatefulSet) postgres-0.postgres-headless.database.svc.cluster.local postgres-1.postgres-headless.database.svc.cluster.local postgres-2.postgres-headless.database.svc.cluster.local同命名空间短名web-app-service即可跨命名空间使用service.namespace.svc.cluster.local完全限定名Headless Service为每个 StatefulSet 副本生成pod-name.service.namespace.svc.cluster.local的稳定地址postgres-0/1/2即对应三个固定身份的成员 Pod——这正是前文 Headless Service 示例postgres-headless位于database命名空间在 DNS 层的兑现主从节点互指、客户端直连特定副本都依赖它。自定义 DNS 策略apiVersion: v1 kind: Pod metadata: name: custom-dns spec: dnsPolicy: None dnsConfig: nameservers: - 8.8.8.8 - 8.8.4.4 searches: - production.svc.cluster.local - svc.cluster.local - cluster.local options: - name: ndots value: 2 containers: - name: app image: myapp:latestdnsPolicy: None表示完全忽略节点默认 DNS改用dnsConfig自定解析器示例用 8.8.8.8/8.8.4.4生产环境请替换为企业内网解析器或自建 DNS。searches保留了集群内搜索域保证短名服务发现仍可用。ndots: 2是性能调优点名字中点号数达到 2 即视为完全限定名不再逐个搜索域展开——避免像postgres-headless.database.svc.cluster.local这类 FQDN 触发大量无效查询。Istio 流量治理VirtualService 与 DestinationRule当网络需求升级到按比例灰度、按 header 路由时参考文档转向 Service Mesh。这里给出两个核心资源。VirtualService路由与金丝雀apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: name: web-app-routes namespace: production spec: hosts: - web-app-service http: - match: - headers: canary: exact: true route: - destination: host: web-app-service subset: v2 - route: - destination: host: web-app-service subset: v1 weight: 90 - destination: host: web-app-service subset: v2 weight: 10路由规则自上而下匹配携带canary: true请求头的流量被精确打到v2子集用于定向验证其余流量按90/10 权重分给v1/v2子集即经典的流量分割式金丝雀发布。subset的具体含义由下一个资源定义。DestinationRule子集、连接池与负载均衡apiVersion: networking.istio.io/v1beta1 kind: DestinationRule metadata: name: web-app-destination namespace: production spec: host: web-app-service trafficPolicy: connectionPool: tcp: maxConnections: 100 http: http1MaxPendingRequests: 50 http2MaxRequests: 100 loadBalancer: simple: LEAST_REQUEST subsets: - name: v1 labels: version: v1.0.0 - name: v2 labels: version: v2.0.0DestinationRule 对web-app-service做三件事子集subsets把带version: v1.0.0/version: v2.0.0标签的端点分别命名为v1/v2供 VirtualService 引用——版本标签成为流量切分的开关连接池TCP 层最多 100 条连接、HTTP/1 最多 50 个挂起请求、HTTP/2 最多 100 个并发请求从代理层防止连接风暴负载均衡LEAST_REQUEST把新请求发给当前负载最轻的端点。需要强调的是文档的边界networking.md只给出流量治理的最小闭环路由 子集 连接池。Gateway 定义、mTLSPeerAuthentication、AuthorizationPolicy、熔断outlierDetection、故障注入与流量镜像等更完整的 Istio 内容以及 Istio/Linkerd 的安装步骤与对比表在同目录的 service-mesh.md 中系统展开技能加载逻辑也会按需切换到该文档。EndpointSlice现代的端点发现机制参考文档最后一组清单展示了 Service 端点的现代表示形式apiVersion: discovery.k8s.io/v1 kind: EndpointSlice metadata: name: web-app-abc123 namespace: production labels: kubernetes.io/service-name: web-app-service addressType: IPv4 ports: - name: http protocol: TCP port: 8080 endpoints: - addresses: - 10.244.1.5 conditions: ready: true nodeName: node-1 - addresses: - 10.244.2.7 conditions: ready: true nodeName: node-2EndpointSlicediscovery.k8s.io/v1是传统 Endpoints 资源的现代替代文档将其定位为 Modern Alternative to Endpoints。从该示例可读出关键结构kubernetes.io/service-name标签把它关联回web-app-service这个 Service端点集合按 Service 分片管理缓解单个 Endpoints 对象条目过多上限 1000 条时的大对象问题conditions.ready: true标记该端点已通过就绪检查、可接受流量nodeName记录端点所在节点是拓扑感知调度/路由同节点优先、跨区容错的数据基础。排查 Service 转发问题时kubectl get endpointslices -n namespace查看各端点的ready状态与分布是判断流量为什么没到某个 Pod的常用入口。最佳实践与技能约束参考文档Best Practices部分给出八条网络层纪律结合 SKILL.md 的强制约束MUST DO / MUST NOT可以形成完整对照#参考文档的最佳实践技能强制约束SKILL.md1以 deny-all NetworkPolicy 起步再放行具体流量MUST NOT允许无限制网络访问default allow-all2最小权限只开必需的端口和协议MUST NOT暴露不必要的端口或服务3Service 选型默认 ClusterIP慎用 LoadBalancer—4使用 Service DNS 名避免硬编码 IP—5尽可能在 Ingress 处终结 TLSMUST敏感数据走 Secret绝不硬编码凭据6配置正确的健康检查路径MUST包含 liveness/readiness 探针7在 Ingress 层做速率限制—8为 Prometheus 暴露 metrics 端点MUST以声明式 YAML 交付不用命令式 kubectl 改动其中第 6 条与 SKILL.md 的 Deployment 模板直接衔接livenessProbe打/healthz、readinessProbe打/ready——readiness 状态同时决定 EndpointSlice 中端点的ready条件把健康检查与流量准入两条线连成一个闭环。部署网络资源后的验证沿用技能的验证命令组见 SKILL.md 的 Validation Commands 部分# 观察 rollout 完成 kubectl rollout status deployment/my-app -n my-namespace # 持续观察 Pod 事件捕捉崩溃循环或镜像拉取错误 kubectl get pods -n my-namespace -w # 检查容器日志--previous 查看已崩溃容器的上一次日志 kubectl logs pod-name -n my-namespace --previous # 查看资源用量对照 limits kubectl top pods -n my-namespace # 回滚失败的部署 kubectl rollout undo deployment/my-app -n my-namespace对于网络资源本身还可以用kubectl get svc -n ns查看 Service 类型与端点分配、kubectl get endpointslices -n ns核对端点 ready 状态来验证本文各清单是否按预期生效。小结这份参考文档的知识地图主题核心产物关键要点Service 四级抽象ClusterIP / Headless / NodePort / LoadBalancer 清单默认 ClusterIPHeadless 服务 StatefulSet 按实例寻址NodePort 限定 30000–32767LB 用注解 loadBalancerSourceRanges收敛IngressNGINX Ingress 双主机示例、路径路由示例注解承担重写/强制 HTTPS/限流/证书签发pathType: Prefix下长前缀优先NetworkPolicydefault-deny 四条放行策略deny-all 起步、按 tier 放行、出站仅 DNS/443、跨命名空间用 namespacepod 双条件 ANDDNS三种 DNS 名形态、自定义 dnsPolicyFQDN 规则ndots调优搜索域展开IstioVirtualService DestinationRuleheader 命中 权重分流的金丝雀subsets 用版本标签切分端点EndpointSlicediscovery.k8s.io/v1 示例按 Service 分片、ready 条件、nodeName 支撑拓扑感知这套清单并非孤立模板而是 claude-skills 技能体系主技能定义纪律、参考文档提供深度设计的组成部分SKILL.md 规定必须做什么/禁止做什么networking.md 给出可复制的生产级清单service-mesh.md、multi-cluster.md 等兄弟文档则按上下文按需加载。想要实际驱动该技能可参考 QUICKSTART.md 的安装流程以及 SKILLS_GUIDE.md 中 Kubernetes Specialist 的选型说明与多技能组合如 Deploy a Python app to Kubernetes 场景下 Kubernetes Specialist 与 Python Pro 的联动。【免费下载链接】claude-skills67 Specialized Skills for Full-Stack Developers. Transform Claude Code into your expert pair programmer.项目地址: https://gitcode.com/GitHub_Trending/claud/claude-skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考