K8s网络学习【五】

5、K8s网络说明

5.1 概述

---

Kubernetes网络模型定义了容器如何相互通信以及与外界交互的方式。下面是Kubernetes网络模型的主要组成部分：

1. Pod：Kubernetes的最小调度单元，可以包含一个或多个容器。Pod内的容器之间共享同一网络命名空间和IP地址，它们可以通过localhost进行通信。
2. Service：抽象了一组具有相同功能的Pod，并为这些Pod提供稳定的虚拟IP地址和DNS名称。Service允许应用程序直接使用DNS名称访问后端，而无需了解后端Pod的实际IP地址。
3. Endpoint：Service的实际后端，由一组Pod和其对应的IP地址和端口组成。当Service接收到请求时，它会将请求转发给Endpoint中的一个或多个Pod进行处理。
4. Node：Kubernetes集群中的物理机器或虚拟机，每个Node上都运行着一个kubelet代理，负责管理该Node上的Pod和容器。
5. Network Plugin：Kubernetes网络插件实现了Pod之间和Pod与外部的网络通信。不同的网络插件可以实现不同的网络拓扑结构，例如VXLAN、BGP等。
6. Network Policy：Kubernetes网络策略控制了Pod之间和Pod与外部的流量。通过定义网络策略规则，可以限制流量源和目标、协议类型、端口等。

Kubernetes网络模型具有灵活性和可扩展性，可以根据需要选择不同的网络插件和网络策略来实现各种网络拓扑结构和安全控制。

附加说明

K8s的网络模型首先明确了所有Pod应在一个扁平化的网络空间里面，既所有Pod之间都可以通过ip直接互通；
有了这个前提，我们需要思考一些问题，如下：
    1、现实物理网络结构中，局域网之间的互通方式是什么？
    2、docker里面有一种网络模型为host模式，直接复用主机的所有网络设置，但是为什么默认的网络模型为bridge既桥接模式？
    3、K8s之间的`通讯类型`都有哪些？

针对以上问题做出以下解答：
    1. 路由器、交换机等；
    2. 解耦、一旦复用主机的网络模式，后续不容易维护，容易混淆docker和宿主机的网络设置，而且仅能通过端口进行区分，并且端口是不能重复的；
    3. pod内部多容器互通；同一宿主机不同pod之间互通；不同宿主机不同pod之间互通；外部网络访问K8s内部pod;K8s内部访问外部网络；

针对以上思考，总结如下：

K8s应该是需要一种自己实现的网络模型（肯定不能直接使用宿主机的网络设置，因为K8s是一个容器云的概念，并不是一个‘物理机器云’），并且需要和宿主机进行网络隔离，而且能够实现同一主机不同pod、不同主机不同pod、pod内部容器、pod与service、宿主机与service等之间的网络互通；因此引申出我们下面将要了解的网络插件知识，这些网络插件就是帮助我们实现上面我们所需要的网络模型的，其中主要实现的目的是为实现Pod容器之间的网络互通

补充说明：

1、Pod内部多容器互通

同一个pod内部不同容器间，通常使用loopback（本地回环）来实现，因为他们公用一个pause容器的网络空间；注意pod内部容器端口不能冲突

2、各Pod之间互相通信

通过K8s全覆盖网络进行通信，此处也是需要借助flannel、calico等插件进行自行实现的部分

3、Pod与Service互相通信

通过IPVS或iptables规则进行通信

4、外部网络与Service互相通信

5.2 CNI (容器网络接口)说明

	CNI是Container Network Interface，是一个标准的，通用的接口。现在容器平台：docker，Podman，LXC和LXD等，容器网络解决方案：flannel，calico，weave，cilium等。只要提供一个标准的接口，就能为同样满足该协议的所有容器平台提供网络功能，而CNI正是这样的一个标准接口协议。
	CNI用于连接容器管理系统和网络插件。提供一个容器所在的network namespace，将network interface插入该network namespace中（比如veth的一端），并且在宿主机做一些必要的配置（例如将veth的另一端加入bridge中），最后对namespace中的interface进行IP和路由的配置。
	CNI的工作是从容器管理系统处获取运行时信息，包括network namespace的路径，容器ID以及network interface name，再从容器网络的配置文件中加载网络配置信息，再将这些信息传递给对应的插件，由插件进行具体的网络配置工作，并将配置的结果再返回到容器管理系统中。
	CNI plugin 只需要通过 CNI 库实现两类方法, 一类是创建容器时调用, 一类是删除容器时调用.

5.3 网络插件选型标准

选择Kubernetes网络插件需要考虑以下因素：

1. 网络拓扑结构：插件支持哪些网络拓扑结构，例如单主机、多主机、跨数据中心等。
2. 性能和可扩展性：插件的性能和可扩展性如何，是否能适应高负载和大规模部署？
3. 安全性：插件的安全性如何，是否支持网络隔离和访问控制等功能？
4. 社区支持：插件的开发者社区是否活跃，是否有持续的更新和支持？

根据不同需求，可以选择不同的Kubernetes网络插件，常见的选择包括：

1. Flannel：简单易用，适合小规模集群部署，网络模型基于VXLAN，性能较差。
2. Calico：支持多种网络拓扑结构，适合大规模部署，具有良好的性能和可扩展性，支持网络隔离和访问控制等功能。
3. Cilium：使用eBPF技术实现网络隔离和安全性，适合需要高度安全性的场景，但部署相对复杂。
4. Weave Net：提供简单易用的网络解决方案，支持多种网络拓扑结构，但性能和可扩展性稍逊于Calico。
5. Kubenet：Kubernetes默认的网络插件，仅支持简单网络拓扑结构，性能和可扩展性较差，仅适合小规模集群部署。

除了上述提到的因素，选择Kubernetes网络插件还需要考虑以下几点：

1. 容器网络接口（CNI）兼容性：Kubernetes使用CNI规范来定义插件和容器之间的交互方式，因此插件必须要支持CNI规范。
2. 跨平台支持：如果集群中有不同的操作系统和硬件架构，需要确保插件能够跨平台支持。
3. 管理和监控：插件是否易于管理和监控，是否提供了统一的API和UI等。
4. 支持的功能和协议：插件是否支持所需的功能和协议，例如IP地址管理、负载均衡、DNS解析、IPv6等。
5. 集成程度：插件是否与其他组件有良好的集成程度，例如容器运行时、调度器、网络策略等。
6. 性价比：插件的价格和性能是否匹配，是否值得投入部署和维护。

总之，在选择Kubernetes网络插件时，需要仔细评估各种因素，并根据实际需求进行权衡和取舍。

**CNI(**容器网络接口)：

iptable是内核中的一个网络数据包处理模块，它具有网络数据包修改，网络地址转换（NAT）等功能。而Routes路由表存储着指向特定网络地址的路径，即下一跳的地址。ACL其实是一种报文过滤器，根据ACL中的匹配条件对进站和出站的报文进行过滤处理