k8s网络架构

Kubernetes 网络架构的设计目标是为 Pod 提供一个高效、灵活且可扩展的网络环境，同时确保 Pod 之间的通信简单直接，类似于在同一个物理网络中。以下是 Kubernetes 网络架构的原理和核心组件的详细解析：
一、Kubernetes 网络模型的基本原则
Kubernetes 的网络模型遵循以下三个基本原则：
1.每个 Pod 都有一个独立的 IP 地址：
Pod 内的容器共享网络命名空间，可以通过 localhost 相互访问。
Pod 之间的通信不需要 NAT（网络地址转换），可以直接通过 IP 地址访问。
Pod 的 IP 地址在集群内是唯一的，即使 Pod 被重新调度到其他节点，IP 地址也会保持不变。
2.Pod 之间的通信是直接的：
Pod 可以通过 IP 地址直接与其他 Pod 通信，而不需要经过额外的代理或网关。
这种直接通信的方式简化了网络配置，提高了通信效率。
3.Pod 的网络配置是动态的：
Pod 的生命周期是短暂的，可能会因为更新、故障等原因被销毁和重建。
Kubernetes 通过 CNI（容器网络接口）插件动态管理 Pod 的网络配置。

二、Kubernetes 网络架构的核心组件

1.Pod 网络
Pod 是 Kubernetes 中的最小部署单位，每个 Pod 都有一个独立的网络命名空间。Pod 网络的实现依赖于 CNI 插件，常见的 CNI 插件包括 Flannel、Calico 和 WeaveNet。
Flannel：
使用 VXLAN 或 UDP 封装数据包，实现跨节点的 Pod 通信。
简单易用，适合中小规模集群。
通过 etcd 存储网络配置信息。
Calico：
基于 BGP 协议，直接在物理网络上建立路由，无需封装。
支持高性能路由和细粒度的网络策略。
适合大规模集群，性能优于 Flannel。
WeaveNet：
提供加密的 Pod 到 Pod 通信，确保数据传输的安全性。
支持网络隔离和加密功能。

2.Service 网络
Service 是 Kubernetes 中用于抽象 Pod 的逻辑集合，通过一个稳定的虚拟 IP（ClusterIP）和端口将流量转发到后端 Pod。
kube-proxy：
运行在每个节点上，负责实现 Service 的负载均衡和网络代理功能。
使用 iptables 或 IPVS 规则将流量转发到后端 Pod。
支持多种负载均衡算法，如轮询、最少连接等。
Endpoint：
Endpoint 是 Service 和 Pod 之间的映射关系，记录了所有健康且可用的 Pod 的 IP 地址和端口。
Endpoint Controller 会监控 Pod 的状态变化，并动态更新 Endpoint 列表。

3.Ingress 网络
Ingress 是 Kubernetes 中用于管理外部访问到集群内服务的 HTTP/HTTPS 流量。
Ingress Controller：
监控 Ingress 资源，动态生成和更新路由规则。
常见的 Ingress Controller 包括 Nginx Ingress Controller、Traefik 等。
提供负载均衡、SSL/TLS 终端、重定向等功能。
Ingress 资源：
定义了 HTTP/HTTPS 流量的路由规则，包括路径、后端 Service 和域名等。
示例配置：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /path1
        pathType: Prefix
        backend:
          service:
            name: service1
            port:
              number: 80
      - path: /path2
        pathType: Prefix
        backend:
          service:
            name: service2
            port:
              number: 80

4.网络策略
Kubernetes 支持通过 NetworkPolicy 资源定义 Pod 之间的访问规则，控制流量的流入和流出。
NetworkPolicy：
定义了 Pod 之间的网络隔离策略，支持白名单和黑名单模式。
示例配置：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-access
spec:
  podSelector:
    matchLabels:
      role: frontend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: backend

三、Kubernetes 网络架构的工作原理
1.Pod 网络的创建和管理
当一个新的 Pod 被创建时，CNI 插件会为 Pod 分配一个 IP 地址，并将其加入到集群的网络中。CNI 插件通过以下步骤实现 Pod 网络的创建：
**1.分配 IP 地址：**从预定义的 IP 池中为 Pod 分配一个唯一的 IP 地址。
**2.创建网络接口：**在宿主机上创建一个虚拟网络接口（如 veth pair），并将一个端连接到 Pod 的网络命名空间。
**3.配置路由：**在宿主机上配置路由规则，确保 Pod 的流量能够正确转发到目标 Pod。
2. Service 的流量转发
Service 通过一个稳定的虚拟 IP（ClusterIP）和端口将流量转发到后端 Pod。kube-proxy 负责实现 Service 的负载均衡和网络代理功能，其工作原理如下：
1.监控 Endpoint 列表：kube-proxy 会监控 Service 的 Endpoint 列表，动态更新后端 Pod 的 IP 地址和端口。
2.配置 iptables 或 IPVS 规则：kube-proxy 会根据 Endpoint 列表配置 iptables 或 IPVS 规则，将流量转发到后端 Pod。
3.负载均衡：kube-proxy 使用负载均衡算法（如轮询、最少连接等）将流量分配到后端 Pod。
3. Ingress 的流量管理
Ingress Controller 负责管理外部访问到集群内服务的 HTTP/HTTPS 流量。其工作原理如下：
监控 Ingress 资源：Ingress Controller 会监控 Ingress 资源，动态生成和更新路由规则。
解析域名和路径：Ingress Controller 根据 Ingress 资源的配置，解析请求的域名和路径，将流量转发到对应的 Service。
负载均衡：Ingress Controller 使用负载均衡算法将流量分配到后端的 Pod。
4. 网络策略的执行
NetworkPolicy 资源定义了 Pod 之间的访问规则，CNI 插件负责执行这些规则。其工作原理如下：
监控 NetworkPolicy 资源：CNI 插件会监控 NetworkPolicy 资源，动态更新网络策略。
配置防火墙规则：CNI 插件会根据 NetworkPolicy 资源的配置，为 Pod 配置防火墙规则，控制流量的流入和流出。

四、Calico网络走向
BGP（Border Gateway Protocol，边界网关协议）是一种用于在不同自治系统（Autonomous Systems，AS）之间交换路由信息的协议。它是互联网的核心路由协议之一，主要用于实现跨网络的路由选择和路径优化。
BGP 的工作原理
1.建立 BGP 会话：
BGP 对等体（peers）之间通过 TCP 连接建立会话。默认情况下，BGP 使用 TCP 端口 179。
会话建立后，对等体之间交换路由信息。
2.路由信息交换：
BGP 对等体之间交换路由信息，包括前缀（IP 地址范围）、下一跳地址、自治系统路径（AS_PATH）等。
每个 BGP 对等体维护一个路由表，记录到达各个目的地的最优路径。
3.路径选择：
BGP 使用多种属性来选择最优路径，包括：
AS_PATH：记录到达目的地所经过的自治系统路径，用于避免环路。
本地优先级（Local Preference）：用于在自治系统内部选择最优路径。
权重（Weight）：仅在本地路由器上使用，用于选择最优路径。
MED（Multi-Exit Discriminator）：用于在多个出口点选择最优路径。
IGP 度量值：用于选择自治系统内部的最优路径。
4.路由传播：
BGP 对等体之间定期交换路由更新信息，以确保路由表的一致性。
路由更新信息包括新增、删除和修改的路由。

Calico 网络架构图
以下是 Calico 的简化架构图，用于说明流量走向：

一、架构图中的核心组件
Node：
每个 Kubernetes 节点上运行的组件。
包括 Felix、BGP 客户端等。
Felix：
运行在每个节点上的代理进程。
负责管理网络接口、路由规则、ACL 规则等。
Felix 监听 etcd 中的配置变化，并在本地应用这些配置。
BGP 客户端：
负责广播和接收路由信息。
使用 BGP 协议将本地节点的路由信息传播到其他节点。
etcd：
分布式键值存储，用于存储 Calico 的网络配置和状态信息。
确保网络元数据的一致性。

二、流量走向解析
1.Pod 创建时的流量走向
假设在 Node 1 上创建了一个新的 Pod A：
1.IP 分配：
Felix 从 etcd 中获取 IP 池信息，为 Pod A 分配一个 IP 地址（例如 192.168.1.2）。
这个 IP 地址属于 Node 1 的子网范围（例如 192.168.1.0/24）。
2.网络接口配置：
Felix 在 Node 1 上创建一个虚拟网络接口（如 veth），并将一端连接到 Pod A 的网络命名空间，另一端连接到虚拟网桥（如 cali0）。
Felix 在内核路由表中添加一条路由规则，将 Pod A 的 IP 地址（192.168.1.2）指向虚拟网桥（cali0）。
3.BGP 路由广播：
Felix 将 Pod A 的路由信息（192.168.1.2/32）注入到 BGP 客户端。
BGP 客户端将这条路由信息通过 BGP 协议广播到其他节点（Node 2、Node N 等）。
其他节点的 BGP 客户端接收到路由信息后，将其添加到本地路由表中。

2.跨节点 Pod 通信的流量走向
假设 Pod A（在 Node 1 上）需要与 Pod B（在 Node 2 上）通信：
1.发送流量：
Pod A 发送一个数据包到 Pod B 的 IP 地址（例如 192.168.2.2）。
数据包首先到达 Node 1 上的虚拟网桥（cali0）。
2.查找路由：
Node 1 的内核路由表根据 Pod B 的 IP 地址（192.168.2.2）查找路由。
路由表中有一条指向 Node 2 的路由（通过 BGP 协议广播的）。
3.转发到目标节点：
数据包通过 Node 1 的物理网络接口发送到 Node 2。
Node 2 接收到数据包后，根据本地路由表将数据包转发到虚拟网桥（cali0）。
4.到达目标 Pod：
数据包从 Node 2 的虚拟网桥（cali0）到达 Pod B 的虚拟网络接口（veth）。
Pod B 接收到数据包并处理。

3.网络策略的流量控制
假设为 Pod A 和 Pod B 定义了网络策略，限制 Pod A 只能访问 Pod B 的特定端口（例如 TCP 80）：
1.策略配置：
网络策略通过 Kubernetes 的 NetworkPolicy 资源定义。
Calico 的 Felix 会将这些策略转换为 iptables 或 eBPF 规则。
2.流量过滤：
当 Pod A 发送数据包到 Pod B 时，数据包首先到达 Node 1 的虚拟网桥（cali0）。
Felix 在 Node 1 上应用的 iptables 或 eBPF 规则会检查数据包是否符合网络策略。
如果数据包符合策略（例如目标端口是 TCP 80），则允许通过；否则，丢弃数据包。
3.返回流量：
Pod B 的响应数据包会通过相同的路径返回到 Pod A。
在 Node 2 上，Felix 也会检查返回流量是否符合网络策略。

三、架构图中的流量走向示例
1.Pod A（Node 1）到 Pod B（Node 2）的流量走向
Pod A (192.168.1.2) --> Node 1 (cali0) --> Node 1 (路由表) --> Node 2 (物理网络) --> Node 2 (路由表) --> Node 2 (cali0) --> Pod B (192.168.2.2)
2.返回流量（Pod B 到 Pod A）
Pod B (192.168.2.2) --> Node 2 (cali0) --> Node 2 (路由表) --> Node 1 (物理网络) --> Node 1 (路由表) --> Node 1 (cali0) --> Pod A (192.168.1.2)

四、Calico 的优势
1.高性能：
使用纯三层网络模型，无封装开销，性能高。
数据包直接通过物理网络传输，无需额外的解封装处理。
2.安全性：
支持细粒度的网络策略，通过 iptables 或 eBPF 规则实现流量控制。
3.可扩展性：
使用 BGP 协议，适合大规模集群。
可以通过 BGP Route Reflector 减少 BGP 连接数量，提高效率。
五、总结
Calico 通过纯三层网络模型和 BGP 协议实现了高效的 Pod 通信。在跨节点通信中，数据包通过内核路由表和物理网络传输，无需额外的封装和解封装。同时，Calico 的网络策略功能确保了流量的安全性。这种设计使得 Calico 成为 Kubernetes 环境中一个高性能、可扩展且安全的网络解决方案。

五、Flannel 网络走向
VXLAN（Virtual Extensible LAN）是一种网络虚拟化技术，用于在大型数据中心和云环境中创建虚拟网络。它通过在物理网络之上构建一个虚拟的、可扩展的网络层，解决了传统 VLAN（Virtual LAN）技术在大规模环境中的限制。

VXLAN 的工作原理
VXLAN 通过在以太网帧中封装额外的 VXLAN 头来实现虚拟网络。以下是其工作原理的详细说明：
1.封装和解封装
封装：当一个虚拟机（VM）发送数据包时，VXLAN 网关（通常是虚拟交换机或物理交换机）会将原始以太网帧封装到一个 UDP 数据包中。封装的 UDP 数据包包含一个 8 字节的 VXLAN 头，其中包含 VNI。
解封装：当数据包到达目标 VXLAN 网关时，网关会解封装 UDP 数据包，提取原始以太网帧，并将其转发到目标 VM。
2.VXLAN 头结构
VXLAN 头包含以下字段：
VNI（VXLAN Network Identifier）：24 位字段，用于标识不同的虚拟网络。
Flags：8 位字段，其中第 3 位（I）必须设置为 1，表示 VNI 字段有效。
Reserved：保留字段，用于未来扩展。
3.VXLAN 网关
VXLAN 网关是实现 VXLAN 功能的关键组件，通常由虚拟交换机（如 VMware vSphere Distributed Switch 或 Open vSwitch）或物理交换机实现。网关负责封装和解封装数据包，并管理 VXLAN 隧道。
4.VXLAN 隧道
VXLAN 使用 UDP 协议在物理网络上传输封装的数据包。每个 VXLAN 隧道由一个源 IP 地址和目标 IP 地址标识，这些地址通常是 VXLAN 网关的 IP 地址。

以下是 Flannel 的网络原理和架构图的详细解析。

一、Flannel 网络原理
1.覆盖网络（Overlay Network）
Flannel 使用覆盖网络技术，通过在现有物理网络之上构建一个虚拟网络层，实现跨主机的 Pod 通信。具体来说，Flannel 将 Pod 的网络流量封装在宿主机的网络协议中（如 VXLAN 或 UDP），从而实现跨主机的通信。
2.子网分配
Flannel 为每个 Kubernetes 节点分配一个子网段，每个子网段中的 IP 地址用于该节点上的 Pod。例如：
集群的总 IP 池是 10.244.0.0/16。
每个节点分配一个 /24 的子网，如 10.244.1.0/24、10.244.2.0/24 等。
3.后端实现
Flannel 支持多种后端实现方式，包括：
VXLAN：使用虚拟扩展局域网（VXLAN）封装数据包，适用于大多数环境。
UDP：使用 UDP 封装数据包，适合不支持 VXLAN 的环境。
Host-GW：直接在物理网络上建立路由，不使用封装，性能最高，但需要集群节点在同一个 L2 网络中。

Flannel 流量走向
1.Pod 创建时的流量走向
假设在 Node 1 上创建了一个新的 Pod A：
1.IP 分配：
Flannel Agent 从 etcd 或 Kubernetes API 中获取子网信息，为 Pod A 分配一个 IP 地址（例如 10.244.1.2）。
这个 IP 地址属于 Node 1 的子网范围（例如 10.244.1.0/24）。
2.网络接口配置：
Flannel Agent 在 Node 1 上创建一个虚拟网络接口（如 veth），并将一端连接到 Pod A 的网络命名空间，另一端连接到虚拟网桥（如 flannel.1）。
Flannel Agent 在内核路由表中添加一条路由规则，将 Pod A 的 IP 地址（10.244.1.2）指向虚拟网桥（flannel.1）。
2. 跨节点 Pod 通信的流量走向
假设 Pod A（在 Node 1 上）需要与 Pod B（在 Node 2 上）通信：
1.发送流量：
Pod A 发送一个数据包到 Pod B 的 IP 地址（例如 10.244.2.2）。
数据包首先到达 Node 1 上的虚拟网桥（flannel.1）。
2.封装数据包：
Flannel Agent 检查目标 IP 地址（10.244.2.2），发现它属于 Node 2 的子网。
Flannel Agent 将数据包封装在 VXLAN 或 UDP 数据包中，目标地址是 Node 2 的宿主机 IP。
3.传输到目标节点：
封装后的数据包通过 Node 1 的物理网络接口发送到 Node 2。
Node 2 接收到封装后的数据包后，Flannel Agent 解封装数据包，提取出原始的 Pod 数据包。
4.到达目标 Pod：
解封装后的数据包被发送到 Node 2 上的虚拟网桥（flannel.1），并最终到达目标 Pod（Pod B）。
3. 返回流量（Pod B 到 Pod A）
返回流量的路径与上述过程类似：
1.Pod B 发送数据包：
Pod B 发送一个数据包到 Pod A 的 IP 地址（例如 10.244.1.2）。
数据包首先到达 Node 2 上的虚拟网桥（flannel.1）。
2.封装数据包：
Flannel Agent 将数据包封装在 VXLAN 或 UDP 数据包中，目标地址是 Node 1 的宿主机 IP。
3.传输到目标节点：
封装后的数据包通过 Node 2 的物理网络接口发送到 Node 1。
Node 1 接收到封装后的数据包后，Flannel Agent 解封装数据包，提取出原始的 Pod 数据包。
4.到达目标 Pod：
解封装后的数据包被发送到 Node 1 上的虚拟网桥（flannel.1），并最终到达目标 Pod（Pod A）。

五、Flannel 的优势与局限性
优势
简单易用：
Flannel 的配置和使用相对简单，适合中小规模的 Kubernetes 集群。
兼容性强：
支持多种后端实现（VXLAN、UDP、Host-GW），适用于不同的网络环境。
社区支持：
作为 Kubernetes 官方推荐的 CNI 插件之一，Flannel 有广泛的社区支持和丰富的文档。
局限性
性能瓶颈：
在大规模集群中，VXLAN 和 UDP 后端可能会引入额外的网络开销，影响性能。
网络复杂性：
虽然 Flannel 本身比较简单，但覆盖网络的实现可能会增加网络的复杂性，尤其是在故障排查时。
不支持网络策略：
Flannel 本身不支持 Kubernetes 的 NetworkPolicy，需要额外的解决方案（如 Calico）来实现网络隔离和访问控制。