Hello folks，我是 Luga，今天我们继续来聊一下云原生生态领域相关的技术 - 云原生网关 Traefik ，本文将继续聚焦在针对 Kubernetes 入口网络体系技术进行剖析，使得大家能够了解为什么常见的入口访问以及如何更好地对利用其进行应用及市场开发。
一、关于 Kubernetes 入口网络的一点简要解析
众所周知，Kubernetes 作为领先的容器编排平台，为构建和管理分布式应用提供了强大的功能。然而，在不同的业务场景下，对网络的需求也存在着差异。为了满足这些差异化的需求，我们需要创建不同的 Kubernetes Cluster 网络模式，以提供定制化的网络解决方案。
通常情况下，Kubernetes 中的集群网络需要满足以下几点核心要求，具体如下所示：
- 服务的安全和隔离：确保不同服务之间能够相互隔离，并杜绝恶意访问。
- Pod 的连接、网络和 IP：为 Pod 提供网络连接和 IP 地址分配，并支持动态分配和管理。
- 设置网络以从多个物理集群部署集群抽象：将多个物理节点虚拟化为一个统一的网络，方便应用的部署和管理。
- 跨服务的多个实例的流量负载平衡：将流量均匀分配到多个服务实例，提高系统的负载能力和可靠性。
- 控制对服务的外部访问：限制对服务的访问权限，保证服务的安全性。
在公共和非云环境中使用 Kubernetes 网络：支持在不同的云环境中部署和运行 Kubernetes Cluster。
二、Pod 内访问
针对一个有两个节点的简单 Kubernetes Cluster，当 Kubernetes 创建及运行一个 Pod 时，它会为该 Pod 构建一个独立的网络命名空间，提供了网络层面的隔离环境。
在这个隔离环境中，Pod 可以像运行在独立的服务器上一样，拥有独立的网络栈，包括独立的网卡、IP 地址、路由表、iptables 规则等。这种隔离机制确保了不同 Pod 之间的网络流量互不干扰，保证了网络通信的安全性和可靠性。
除了网络隔离之外，Kubernetes 还为每个 Pod 分配了一个唯一的 IP 地址，使得 Cluster 内的所有 Pod 都可以通过 IP 地址相互访问。这些 IP 地址可以是从专门的子网中静态分配的，也可以通过 DHCP 等动态分配方式获取，由集群自动管理。无论采用何种分配方式，Kubernetes 都会确保整个 Cluster 内不会出现 IP 冲突的情况，从而保证了通信的顺畅和可靠。
具体可参考如下所示：
Pod 网络的隔离性虽然保证了服务的安全性，但也给服务的访问带来了一定的挑战。由于 Pod 内部的 IP 地址在 Cluster 外部是不可访问，因此外部客户端无法直接与该服务通信。这对服务意味着什么?服务在 Pod 网络中的 Pod 内运行。在该 Pod 网络上分配的 IP 地址(用于服务)在 Pod 外部则不可访问。那么如何访问该服务呢?
三、跨 Nodes 访问
在实际的业务场景中，一个服务通常会由多个 Pod 实例组成，这些 Pod 可能分布在集群的不同节点上。比如，某个服务由两个 Pod 构成，分别运行在两个不同的物理节点上。当外部客户端需要访问该服务时，Kubernetes 如何在这两个 Pod 之间进行负载均衡，确保请求能够公平地分发到每个实例上呢?
Kubernetes 采用了 Cluster IP(集群 IP)的抽象机制来解决这个问题。具体来说，Kubernetes 为每个服务分配一个 Cluster IP，作为对外统一的入口点。当客户端发起对该服务的请求时，只需要连接到这个 Cluster IP 即可，而不需要关心后端具体的 Pod 实例。
接下来，Kubernetes 会根据预先设定的负载均衡策略，将接入的请求流量分发到运行该服务的所有 Pod 实例上。常用的负载均衡算法包括基于权重的轮询调度、最少连接调度等,用户也可以根据自身需求自定义调度算法。无论采用何种策略，Kubernetes 都能够确保请求流量在各个 Pod 实例之间合理分配，实现高可用和负载均衡。
值得注意的是，这种负载均衡过程对客户端来说是完全透明的。客户端只需连接集群 IP 即可，而无需关心后端 Pod 的实际分布情况。这不仅简化了客户端的访问逻辑，也实现了服务的高度抽象化，将客户端与底层基础设施解耦。
Cluster IP (集群 IP)是 Kubernetes 实现服务发现和负载均衡的核心机制，其背后依赖于 kube-proxy 组件和一系列网络技术的支持。
通过 kube-proxy、iptables/IPVS、网络插件等多个组件的紧密配合，Kubernetes 为用户提供了一个高度抽象且功能强大的服务网络解决方案，既能够实现高效的流量负载均衡，又支持丰富的网络策略控制，真正释放了云原生应用的潜力，推动了微服务架构的广泛应用。
四、Cluster 外部访问
ClusterIP (集群IP)提供了一种方便的方式来访问运行在 Kubernetes Cluster 内的服务，但它默认情况下只能在集群内部访问，对外部流量是不可见。这是出于安全性的考虑，避免服务被外部直接访问而遭受攻击。
但在某些场景下，我们可能需要将服务暴露给集群外部的客户端访问。比如，某些面向公网的 Web 服务，或者需要跨集群通信的微服务等。为了满足这种需求，Kubernetes 提供了 NodePort 类型的服务。
NodePort 服务通过在每个节点上开放一个指定的端口，将集群外部的流量引入到集群内部，并通过 ClusterIP 将这些流量转发到后端的 Pod 实例上。具体来说，当客户端访问任意一个节点的 NodePort 端口时，Nodes 会将该请求转发到相应的 ClusterIP ，再由ClusterIP 进行负载均衡，将流量分发到提供该服务的所有 Pod 实例上。
这种模式相当于在集群的边缘设置了一个入口网关，为外部流量提供了一个合法的入口点。与直接暴露服务的 ClusterIP 相比，此种方式提供了更好的安全性和灵活性。管理员可以精细化地控制哪些服务可以通过 NodePort 对外开放，同时，还可以根据需要调整 NodePort 的端口映射策略。
值得注意的是，NodePort 服务需要在每个节点上开放一个端口，这意味着该端口在集群的所有节点上都不可复用。为了避免端口资源的浪费，Kubernetes 会自动分配一个可用的高位端口(默认范围为30000-32767)作为 NodePort。当然，用户也可以根据实际需求自定义 NodePort 的端口号。
除了 NodePort 之外，Kubernetes 还支持 LoadBalancer 和 Ingress 等更为高级的服务暴露方式。LoadBalancer 服务通过云服务商提供的负载均衡器，为服务提供一个外部可访问的IP地址;而I ngress 则允许用户自定义配置服务的外部访问规则，实现更精细化的路由和流量管理。
这里，我们撇开公有云不谈，仅聊聊私有云环境下的入口网络...
在私有云中运行时，创建 LoadBalancer 类型的服务需要一个可以配置负载均衡器的 Kubernetes 控制器。在目前的解决方案中，一种这样的实现便是 MetalLb 。MetalLB 是裸机 Kubernetes 集群的负载均衡器实现，使用标准路由协议。其基于分配的 IP 地址来路由集群内的外部流量。从本质上来讲，MetalLB 旨在通过提供与标准网络设备集成的网络 LoadBalancer 实现来纠正这种不平衡，以便使得裸机集群上的外部服务也尽可能地正常发挥作用。
MetalLB 实现了一个实验性的 FRR 模式，它使用 FRR 容器作为处理 BGP 会话的后端。它提供了原生 BGP 实现所不具备的功能，例如将 BGP 会话与 BFD 会话配对，以及发布 IPV6 地址。
MetalLB 是一种可用于裸机环境的 Kubernetes 外部负载均衡器实现。它是谷歌开发的一个简单的负载均衡器，具有为负载均衡器类型的 Service 分配公共 IP 地址(External IP)和向 External IP 公开路由信息等两个功能。基于 MetalLb 设计特性，其主要涉及以下 2 种核心功能：
- 地址分配：当创建 LoadBalancer Service 时，MetalLB 会为其分配 IP 地址。这个 IP 地址是从预先配置的 IP 地址库获取的。同样，当 Service 删除后，已分配的 IP 地址会重新回到地址库。
- 对外广播：分配了 IP 地址之后，需要让集群外的网络知道这个地址的存在。MetalLB 使用了标准路由协议实现：ARP、NDP 或者 BGP。
广播的方式有两种，第一种是 Layer 2 模式，使用 ARP(ipv4)/NDP(ipv6) 协议;第二种是 BPG。
我们来看一下 MetalLB 网络参考示意图，如下所示：
基于上述参考拓扑结构图，我们可以看到：当有外部流量请求访问时，路由器和 ipvs 会根据设置的路由信息调整连接目的地。因此，从某种角度而言，MetalLB 本身并非是一种负载均衡组件设施，而是基于负载均衡场景而设计。
那么，其实，像 Traefik 这样的代理可以通过将其作为服务运行并定义此 LoadBalancer 类型的服务来接收进入集群的所有外部流量。这些代理可以使用 L7 路由和安全规则进行配置。这些规则的集合形成了 Ingress 规则。
基于 Ingress - 将服务置于可通过负载均衡器从外部访问的代理后面。可以在服务之前放置一层 L7 代理，以应用 L7 路由和策略。为此，需要一个入口控制器。Ingress Controller 是 Kubernetes 集群内的服务，配置为 LoadBalancer 类型以接收外部流量。
Ingress Controller 使用定义的 L7 路由规则和 L7 策略将流量路由到服务。具体可参考如下示意图所示：
其实，从本质上来讲，在 Ingress 运行 Ingress Controller 和执行策略有几个明显的优势，具体：
- Ingress 提供了一种可移植的机制来在 Kubernetes 集群内执行策略。在集群内实施的策略更容易跨云移植。可以使用 Kubernetes 服务扩展来水平扩展。
- 多个代理可以使用 Kubernetes 服务进行水平扩展，L7 结构的弹性使其更易于操作和扩展。
- L7 策略可以与集群内的服务一起托管，具有集群原生状态存储。
- 让 L7 策略更接近服务可以简化服务和 API 的策略执行和故障排除。
在 Kubernetes Cluster 中选择 Ingress 控制器 是一个非常重要的决策，直接关系到 Cluster 的网络性能、安全性和可扩展性。作为一款备受推崇的开源 Ingress 控制器，Traefik凭借其卓越的设计理念和强大的功能特性,成为了许多用户的首选之一。
那么，为什么要选择 Traefik 作为首选的 Kubernetes Ingress 呢?具体如下所示：
1.易于使用和维护
Traefik 的安装和配置过程极为简单流畅，使用 YAML 或 TOML 格式的声明式配置文件，可读性和可维护性极佳。与此同时，Traefik 还提供了基于 Web UI 的直观管理界面，用户可以在其中实时查看和管理路由规则、中间件等配置项，极大降低了运维的复杂度。
2.自动化服务发现能力
Traefik 拥有强大的自动服务发现功能，可以自动监测 Kubernetes Cluster 中服务的变化，并基于这些变化动态生成相应的路由规则，无需人工介入。这种自动化能力不仅极大地简化了配置流程，还确保了路由规则的实时更新，保证了服务发现的准确性和及时性。此外，Traefik 支持多种服务发现机制，包括 Kubernetes Ingress、Docker 等，可以适应各种复杂的部署环境。
3.智能动态负载均衡
Traefik 内置了高性能的负载均衡模块，可以根据服务实例的实时状态动态调整后端权重，实现真正意义上的智能负载均衡。同时，Traefik 还支持会话亲和性、熔断机制、重试策略等高级功能，从而确保了服务的高可用性和可靠性，为应用提供了稳定、高效的运行环境。
4.丰富的中间件生态
Traefik 拥有数十种内置的中间件，涵盖了身份认证、速率限制、熔断、重试、缓存等多个方面，用户可以根据实际需求，通过简单的配置即可启用这些中间件，快速构建出功能强大的边缘服务。除了内置中间件之外，Traefik还提供了良好的扩展性，支持用户自行开发和集成定制化的中间件，满足各种复杂场景的需求。
5.卓越的可扩展性
作为一款生产级别的 Ingress 控制器，Traefik 天生具备出色的可扩展性。它支持多种部署模式，包括单实例、集群等，在集群模式下，多个 Traefik 实例可以无缝协作，实现高可用和水平扩展。同时，Traefik 还支持多种后端服务器类型，如 HTTP、gRPC 等，能够满足各种复杂的应用场景需求。
6.全方位的安全保障
安全性是 Traefik 设计时的重中之重，支持 HTTPS/TLS、基于角色的访问控制(RBAC )等多种安全特性。Traefik 可以通过 Let's Encrypt 等方式自动获取和更新 SSL/TLS 证书,确保数据传输的端到端加密。同时，它还提供了完善的身份认证机制，如基本认证、JWT 等，有效保护服务免受未经授权的访问。
