1、概述

• Pod 网络：每个 Pod 分配集群内唯一的 IP 地址，所有 Pod 可以直接跨节点通信（无需 NAT），基于 CNI 插件实现（如 Calico、Flannel、WeaveNet 等）。

• Service 网络：一组功能相同的 Pod 的网络抽象层，每个 Service 都有一个虚拟 IP（ClusterIP），访问虚拟 IP 会负载均衡到后端 Pod，只适用于集群内部通信，基于 kube-proxy 或 IPVS 实现均衡负载。

• Node 网络：物理宿主机的网络，由底层基础设施（如云厂商或物理网络）提供，Pod 与外部通信需要经过 NAT 或路由。

• 外部访问网络（可选）：集群内部和外部通信，基于 Ingress Controller 实现，涉及外部的均衡负载器或者外部 IP。

2、Pod网络

• 同一 Pod 内的容器通信：可通过 localhost 通信。Pod 内的所有容器共享相同的网络命名空间（共享 IP 和端口空间）。

• 跨 Pod 通信：可通过 Node IP 通信。每个 Pod 分配集群内唯一的 IP 地址，不管同一个 Node 上的不同 Pod，还是跨 Node 的 Pod，都可以通过 Pod IP 直接通信，无需 NAT。原理是通过 CNI 插件实现的 Overlay/非Overlay 网络。

• 为 Pod 分配 IP：每个节点从预定义的 Pod CIDR 中获取一个子网，然后从子网中分配一个 Pod IP。

• 访问 Pod：
• Overlay 网络：在现有网络之上构建虚拟网络（如 Flannel 的 VXLAN）
• 非 Overlay 网络：直接路由（如 Calico 的 BGP）

• DNS 和服务发现：CoreDNS 为服务和 Pod 提供 DNS 解析，服务可通过 ClusterIP 或 DNS 名称访问

CNI (Container Network Interface)

1. 容器运行时调用 CNI 插件（例如 Flannel ）

2. 插件根据配置文件配置网络，包括：
• 创建网络接口
• 分配 IP 地址
• 设置路由规则
• 配置防火墙规则

Network Policy

• 如果没有 Network Policy 选择 Pod，则所有流量都被允许

• 一旦 Pod 被某个 Network Policy 选中，就会进入"默认拒绝"模式。

• podSelector：选择应用策略的 Pod（通过标签匹配）。

• policyTypes：指定策略类型（ Ingress、 Egress 或两者）。

• ingress：入站规则，允许哪些来源（其他 Pod、IP 块）访问目标 Pod。

• egress：出站规则，允许目标 Pod 访问哪些外部资源。

• Network Policy 是命名空间范围的资源。

• 要使用 Network Policy，你的 Kubernetes 集群必须使用支持 NetworkPolicy 的网络解决方案（Flannel 不支持 Network Policy），例如：
• Calico
• Cilium
• Kube-router
• Romana
• Weave Net

• 策略规则是叠加的，多个策略可以选择同一个 Pod。

3、Service网络

既然 Pod 有可访问的 IP 地址，为什么不直接访问 Pod，而是抽象出 Service 层，通过 Service 层来访问 Pod 呢？

• Pod 随时可能会被销毁重建，重建后的 Pod IP 地址也会变化。如果直接通过 Pod IP 地址来访问 Pod，这个 Pod IP 地址可能会随时失效。

• 生产中往往需要一个类似于均衡负载器的组件，为一组功能相同的 Pod 想提供统一的访问入口， 并自动均衡负载到合适的 Pod。

1. 分配 Cluster IP：Kubernetes 控制平面从集群的可用服务 IP 池中为每个新创建的服务分配一个稳定的集群内访问 IP 地址，称为 Cluster IP。这个 Cluster IP 是虚拟的，不依赖于底层网络实现。

2. 关联 Pod：通过标签选择器关联 Pod，被 Service 选中的 Pod，当它们运行且能对外提供服务后，Endpoints Controller 会生成一个新的 Endpoints 对象，记录 Pod 的 IP 和端口。查看 Service 的详情可以看到它的 Endpoints 列表，如下所示：

3. 生成 DNS 记录：DNS 服务（CoreDNS）为 Service 的 Cluster IP 分配一个域名 <serviceName>.<namespace>.svc.cluster.local，并生成一条 A 记录存储域名和 Cluster IP 的映射关系。

4. 访问 Service：在 Pod 中可以通过域名 <serviceName>.<namespace>.svc.cluster.local访问任何服务，也可以使用缩写 <serviceName>.<namespace> 直接访问。如果 Pod 和 Service 在同一个 namespace 中，那么甚至可以直接使用 <serviceName>访问。当然也可以通过 Service 的 Cluster IP 直接访问 Service。

5. 实现转发：kube-proxy 组件负责实现 Service 的虚拟 IP 到 Pod IP 的转发，有三种转发模式：
• userspace (已弃用)
• iptables：默认模式，基于 Netfilter 框架，通过顺序遍历规则链来匹配数据包，匹配成功后执行动作（如 ACCEPT、DROP、REDIRECT）。性能较低，适用于小规模或低流量负载均衡（如开发测试环境）。
• IPVS：高性能，基于内核的哈希表直接管理流量转发，数据包到达后 IPVS 直接根据哈希表快速选择后端服务器，无需逐条匹配规则，性能接近线性扩展，适用于高并发负载均衡（如大规模 Web 服务、数据库集群）。

• ClusterIP：默认类型，ClusterIP 为 Service 分配一个集群内部的 IP 地址，这个 IP 地址只能在集群内部进行访问。例如从 Service 网络网段（10.96.0.0/12）里面为 Service 分配一个 IP 地址（10.96.123.45），集群内可以直接访问 10.96.123.45 这个 IP 地址，请求均衡负载后自动转发到后端的 Pod。

• NodePort：在 Node 节点上为 Service 分配一个端口 Port（通常是 30000 ～ 32767），可以通过 Node IP + Port 访问后端的 Pod，支持从集群外部访问。NodePort 为 Service 在 Kubernetes 集群的每个 Node 上分配一个真实的端口，即 NodePort。集群内/外部都可以可以通过 http://<NodeIP>:NodePort访问 Serivce。NodePort 支持TCP、UDP、SCTP，默认端口范围是 30000-32767，在创建 NodePort 类型 Service 对象时会随机选取一个端口，而且要求每个 Service 需占用不同端口。NodePort 是解决服务对外暴露的最简单方法，但是一般只用于开发/测试环境。

• LoadBalancer：使用云提供商的负载均衡器向外部暴露服务，自动分配 EXTERNAL-IP。内部可以使用 Cluster IP 加端口来访问该服务，在我们这个例子中就是 10.97.121.42:8086。外部可以使用 EXTERNAL-IP + 端口来访问该服务，这是一个云供应商提供的负载均衡器 IP，在我们这个例子中就是 10.13.242.236:8086。

• ExternalName：通过返回 CNAME 记录将服务重定向到 externalName 字段的内容（通常是一个外部域名），用于访问集群外部的服务。

4、DNS服务

1. DNS 服务器：一个运行在集群内的 DNS 服务器，通常以 Deployment 的形式部署在 kube-system 命名空间下。

2. kubelet：每个节点上的 kubelet 会负责配置所有 Pod 的 /etc/resolv.conf 文件，使其能够找到这个集群内的 DNS 服务器。

DNS记录类型

1. Service 的 DNS 记录。包含两种类型：
• A/AAAA 记录（最常用的记录）
• 格式：<service-name>.<namespace-name>.svc.cluster.local
• 解析结果：该 Service 的 Cluster IP。
• 使用方式：
• 在同一个命名空间中，你可以直接使用 <service-name> 来访问。
• 在不同命名空间中，你需要使用 <service-name>.<namespace-name>。
• 示例：假设在 default 命名空间中有一个名为 my-service 的 Service。
• 在同一个命名空间（default）的 Pod 里，你可以通过 ping my-service 或 curl http://my-service 来访问。
• 在 my-namespace 命名空间的 Pod 里，你需要使用 my-service.default 或 my-service.default.svc.cluster.local 来访问。
• SRV 记录：用于记录那些定义了命名端口（named ports）的 Service 的端口信息。

2. Pod 的 DNS 记录：通常，Pod 的 IP 地址是不稳定的，所以一般不直接通过 Pod DNS 访问。但在某些场景下（例如 StatefulSet），也需要稳定的 Pod 标识。包含两种类型：
• A/AAAA 记录（需要显式启用）
• 格式：<pod-ip>.<namespace-name>.pod.cluster.local
• 例如，一个 IP 为 172.17.0.7 的 Pod 在 default 命名空间中，其 DNS 名为 172-17-0-7.default.pod.cluster.local（IP 中的点被替换成了横线）。
• StatefulSet 的 DNS 记录：这是 Pod DNS 最主要的使用场景。StatefulSet 为其每个 Pod 提供一个稳定的主机名。
• 格式：<statefulset-name>-<ordinal>.<service-name>.<namespace-name>.svc.cluster.local
• 示例：一个名为 web 的 StatefulSet，它关联的 Headless Service 也叫 web，在 default 命名空间中。那么它的第一个 Pod 的 DNS 名是：web-0.web.default.svc.cluster.local

CoreDNS

• 它作为一个 Deployment (coredns) 运行在 kube-system 命名空间中。

• 它通过一个 Service (kube-dns) 暴露其 DNS 服务，其拥有一个稳定的 Cluster IP（通常是 10.96.0.10）。

• 这个 Cluster IP 会被 kubelet 写入到每个新创建 Pod 的 /etc/resolv.conf 文件中。

• nameserver：指定了 Pod 应该使用的 DNS 服务器，即集群内的 CoreDNS。

• search：指定了 DNS 查询的搜索域。当你使用一个不完整的域名（如 my-service）时，系统会尝试依次在这些搜索域中查找。例如，在 default 命名空间的 Pod 中访问 my-service，系统会依次尝试查找：
1. my-service.default.svc.cluster.local -> 成功，找到！
2. my-service.svc.cluster.local -> （如果上一步失败）
3. my-service.cluster.local -> （如果上一步失败）

• options ndots:5：这是一个性能优化选项。它意味着任何包含不少于 5 个点的域名（如 www.google.com）都会被首先尝试作为绝对域名（FQDN）直接查询。如果失败，才会使用搜索域。而点数少于 5 的域名（如 my-service）会先使用搜索域进行查询。

1. 当创建 Service 时，CoreDNS 会自动为 Service 或 Pod 创建 DNS 的 A 记录：
• 普通的 Service 的 DNS 记录：<serviceName>.<namespace>.svc.cluster.local → Cluster IP
• Headless Service 的 DNS 记录：<serviceName>.<namespace>.svc.cluster.local → 后端 Pod IP 列表，同时还会为 Pod 分配 A 记录 <podIp>.<namespace>.pod.cluster.local

2. 当服务访问 <serviceName>.<namespace>.svc.cluster.local 时，请求发送到 CoreDNS。

3. CoreDNS 查询 Kubernetes API，获取 Service 对应的 Cluster IP。另外还支持 Headless Service，可以直接解析为 Pod IP。

4. 如果遇到集群内无法解析的域名，将请求转发到上游 DNS（如配置的 /etc/resolv.conf 中的外部 DNS 服务器）。

5. 返回解析结果，完成服务发现。

5、Ingress网络

• 基于路径的路由：将不同 URL 路径路由到不同服务

• 基于主机名的路由：将不同域名路由到不同服务

• TLS/SSL 终止：处理 HTTPS 流量

• 重定向和重写：URL 重定向和路径重写

Ingress 与 Service 的区别和关系是什么？

• Service 主要是用于集群内部访问，基于 IP 地址 + 端口 访问，作用是为一组 Pod 提供稳定的内部访问入口（通过标签选择器关联 Pod）。虽然前文提到 NodePort 和 Load Balancer 类型的 Service 在功能上也能起到对外暴露服务的作用，但是 Service 只提供 L4 负载均衡功能，一些高级的 L7 转发功能，例如基于 HTTP header、cookie、URL 的转发就做不了。

• Ingress 主要用于集群外部访问，基于 HTTP/HTTPS 协议访问，作用是为集群提供一个外部入口，避免为每个 Service 单独配置外部访问（如不需要为每个服务创建 LoadBalancer）。Ingress 提供了负载平衡器的典型特性：HTTP 路由、黏性会话、SSL 终止、SSL 直通、TCP 和 UDP 负载平衡等。

• Service 可以独立存在：即使没有 Ingress，Service 仍可通过 ClusterIP、NodePort 或 LoadBalancer 提供访问。

• Ingress 依赖 Service：Ingress 本身不直接暴露服务，而是通过规则将外部流量路由到后端的 Service，再由 Service 转发到 Pod。例如api.company.com/foo → service-foo → pod。

Ingress Controller

1. 管理员创建 Ingress 资源定义路由规则

2. Ingress Controller 检测到 Ingress 资源变化

3. Ingress Controller 根据规则配置底层负载均衡器

4. 外部流量通过负载均衡器按照规则路由到相应服务

1. Nginx Ingress Controller：基于 Nginx 的流行选择

2. Traefik：功能丰富的现代反向代理

3. HAProxy Ingress：高性能负载均衡器

4. AWS ALB Ingress Controller：与 AWS 负载均衡器集成

5. GKE Ingress：Google Kubernetes Engine 的原生实现

6、网络问题排查

Pod 网络连接问题

• Pod 无法访问其他 Pod

• Pod 无法访问 Service

• Pod 无法访问外部网络

1. 检查 Pod 状态：

2. 进入 Pod 测试网络：

3. 检查 DNS 解析：

4. 检查 CNI 插件：

Service 访问问题

• Service 无法访问

• Service DNS 解析失败

• 访问 Service 超时

1. 检查 Service 配置：

2. 检查 Endpoints：

3. 检查 kube-proxy：

4. 检查 iptables/nftables 规则：

节点网络问题

• 节点间网络不通

• 节点无法访问 Pod 网络

• 节点无法访问 Service

1. 检查节点网络配置：

2. 测试节点间连通性：

3. 检查网络插件：

DNS 问题

• DNS 解析失败

• DNS 查询超时

• 间歇性 DNS 问题

1. 检查 CoreDNS/kube-dns Pod：

2. 检查 DNS 配置：

3. 检查 resolv.conf：

网络策略问题

• 网络策略未按预期工作

• 允许/拒绝规则不生效

1. 检查 NetworkPolicy：

2. 验证网络插件是否支持 NetworkPolicy：
• Calico, Cilium, Weave 等支持 NetworkPolicy

Ingress 问题

• Ingress 无法访问

• 路由规则不生效

• SSL/TLS 问题

1. 检查 Ingress 资源：

2. 检查 Ingress Controller：

常用网络诊断工具

1. 网络连通性测试：

2. Kubernetes 网络诊断工具：

3. 高级诊断工具：