网络管理

Calico

Calico 概述

Calico 是一个开源的联网及网络安全方案，用于基于容器、虚拟机和本地主机的工作负载。 Calico 支持多个数据面，包括：纯 Linux eBPF 的数据面、标准的 Linux 联网数据面以及 Windows HNS 数据面。Calico 在提供完整的联网堆栈的同时，还可与云驱动 CNIs 联合使用，以保证网络策略实施。

Calico 相比 flannel 支持更多的网络层安全策略

Calico 是一个联网和网络策略供应商。 Calico 支持一套灵活的网络选项，因此你可以根据自己的情况选择最有效的选项，包括非覆盖和覆盖网络，带或不带 BGP。 Calico 使用相同的引擎为主机、Pod 和（如果使用 Istio 和 Envoy）应用程序在服务网格层执行网络策略。

Calico是一个开源的容器网络解决方案，旨在为Kubernetes和容器化环境提供高性能、安全可靠的网络连接。它使用CNI（Container Network Interface）规范，并提供了强大的网络策略和安全功能。

下面是Calico的一些详解：

BGP路由：Calico使用BGP（Border Gateway Protocol）作为底层网络路由协议，实现跨节点的容器网络互连。每个节点上的Calico代理（Calico Node）会运行BGP守护进程，并与其他节点建立BGP邻居关系。这样，容器的通信流量可以通过BGP路由表进行路由选择和转发。
IP地址管理：Calico使用IP池（IP Pool）来管理容器的IP地址分配。管理员可以定义一个或多个IP池，并为每个池指定IP地址范围。当容器创建时，Calico会从IP池中动态分配IP地址，并确保IP地址的唯一性和一致性。
网络策略：Calico提供了强大的网络策略功能，用于定义和控制容器之间的网络访问规则。网络策略可以基于源IP、目标IP、端口等条件来过滤和限制流量。这使得管理员可以灵活地配置容器之间的通信，增强网络安全性。
安全性：Calico提供了多层次的安全功能，用于保护容器网络。它支持网络隔离，确保容器之间的互相隔离和安全性。此外，Calico还支持加密和认证等功能，用于保护容器间的通信和控制平面。
可扩展性：Calico的设计目标之一是可扩展性。它使用分布式架构，并充分利用BGP协议的可扩展性特性。每个节点上的Calico代理只负责本地节点的网络配置和管理，减轻了集中式控制的压力，并提高了系统的可扩展性和性能。

Calico被广泛应用于Kubernetes集群和容器化环境中，因其高性能、可靠性和丰富的安全功能而受到青睐。它提供了灵活的网络配置、强大的网络策略和高度可扩展的架构，为容器网络提供了可靠的基础设施。

参考文档

https://github.com/projectcalico/calico
https://www.tigera.io/project-calico/
https://docs.tigera.io/
https://www.ibm.com/docs/fr/cloud-private/3.1.1?topic=ins-calico
https://blog.palark.com/calico-for-kubernetes-networking-the-basics-examples/
https://tanzu.vmware.com/developer/guides/container-networking-calico-refarch/
overlay：https://docs.tigera.io/calico/latest/networking/determine-best-networking#overlay-networks

获取 Calico 版本

不同版本间的配置参数可能会有所不同，获取版本信息后可以根据 calico 版本来查看指定的文档

下面的命令将返回 Calico Node 容器的镜像名称，其中包含了 Calico 的版本信息。通常情况下，Calico 的版本号被包含在镜像名称中。

Cilium

Cilium 概述

Cilium 是一个开源的网络连接和安全性解决方案，专为容器化、微服务和云原生应用程序设计。它提供了一种高级网络和网络安全层，以帮助管理和保护在大规模分布式环境中运行的应用程序。

以下是 Cilium 的一些关键特性和概念的详细解释：

eBPF (Extended Berkeley Packet Filter)：Cilium 使用 eBPF 技术在 Linux 内核中实现其核心功能。eBPF 是一种灵活而强大的虚拟机技术，允许在内核中执行自定义的网络过滤和操作。Cilium 利用 eBPF 来拦截和检查网络流量，并在运行时动态地应用安全策略。
网络连接和路由管理：Cilium 具有灵活的网络连接管理功能，可以自动为容器和微服务创建和管理网络连接。它使用透明的代理来管理和路由流量，无需修改应用程序代码或配置网络规则。Cilium 还支持多种网络层协议和服务发现机制，使得在复杂的应用程序和服务间建立可靠的通信变得更加容易。
安全策略和访问控制：Cilium 提供了强大的安全性功能，可以定义细粒度的网络安全策略和访问控制规则。它可以基于网络标识、应用程序协议、服务和微服务之间的关系等因素来控制流量。Cilium 还支持网络加密和身份验证，以保护敏感数据和应用程序免受未经授权的访问。
服务发现和负载均衡：Cilium 集成了强大的服务发现和负载均衡功能，使得在容器和微服务之间进行动态的流量分发变得更加容易。它可以自动检测和跟踪服务的变化，并使用智能路由算法将流量引导到可用的实例上，以实现高可用性和可扩展性。
观察性和监控：Cilium 提供了全面的观察性和监控功能，帮助用户了解应用程序和网络的运行状况。它集成了 Prometheus、Grafana 等流行的监控工具，提供实时的指标和可视化仪表板，帮助用户诊断问题、监测性能和进行容量规划。

总之，Cilium 是一个功能强大的容器和云原生网络解决方案，通过利用 eBPF 技术和灵活的网络连接管理，帮助用户构

参考文档：

eBPF

eBPF（extended Berkeley Packet Filter）是一种扩展的伯克利数据包过滤器，它是一个在Linux内核中执行代码的虚拟机。eBPF的设计目标是为了提供一种安全、高效的机制，用于对内核中的事件进行动态的、实时的数据包过滤、网络分析和性能跟踪。

以下是eBPF的一些关键概念和详细解释：

原理：eBPF利用了内核中的一组虚拟机指令，允许用户在不修改内核源代码的情况下，在内核空间中执行自定义的程序。这些程序可以被动态加载到内核中，并在特定事件（如数据包到达、系统调用等）发生时执行。
安全性：eBPF程序在执行之前会进行严格的验证和限制，以确保它们不会破坏内核的稳定性和安全性。eBPF使用了一种基于LLVM的前端编译器，将高级的eBPF程序转换为安全的、可验证的内核字节码。
事件钩子：eBPF程序可以与内核中的各种事件钩子（如网络协议栈、系统调用、硬件事件等）关联起来。这使得用户能够对事件进行过滤、修改或收集数据，从而实现各种用途，如防火墙、网络监控、流量分析和性能调优等。
动态加载：eBPF程序可以动态地加载到内核中，而无需重新启动系统。这使得用户能够实时地修改和更新eBPF逻辑，而无需中断正在运行的应用程序或服务。
多种用途：eBPF的灵活性使其在许多领域得到广泛应用。它可以用于网络安全，例如实现高性能的数据包过滤、DDoS防御和流量分析。此外，eBPF还可以用于性能分析和故障排查，以监控系统调用、函数调用和硬件事件等。
生态系统：eBPF拥有丰富的生态系统，包括各种工具、库和框架，用于开发、调试和部署eBPF程序。例如，BCC（BPF Compiler Collection）提供了一组用于eBPF开发的工具和库，而Cilium和Falco等项目则将eBPF用于容器网络和容器安全领域。

eBPF 和 iptables 与 ipvs 对比

eBPF、iptables和IPVS都是在Linux系统中用于网络和安全领域的工具，但它们在功能、应用场景和实现方式上有所不同。下面是它们之间的对比：

功能：

eBPF：eBPF是一种灵活的内核扩展机制，可以用于数据包过滤、网络分析和性能跟踪等多种用途。它可以在内核中动态加载自定义程序，通过事件钩子来处理网络数据包或系统调用。
iptables：iptables是Linux系统上用于数据包过滤和网络地址转换（NAT）的工具。它基于规则表和链来对数据包进行过滤、修改和重定向。iptables通常用于实现防火墙规则和网络流量控制。
IPVS：IPVS（IP Virtual Server）是Linux系统上的一种负载均衡工具，用于将传入的网络流量分发到多个后端服务器上。它支持多种负载均衡算法，并提供高性能的流量分发和会话保持功能。

应用场景：

eBPF：eBPF适用于需要进行实时数据包过滤、网络分析和性能跟踪的场景。它可以实现高级的网络安全策略、网络监控和故障排查。
iptables：iptables主要用于配置和管理防火墙规则，进行数据包过滤和网络地址转换。它可以实现访问控制、端口转发、NAT等功能。
IPVS：IPVS用于负载均衡，将传入的流量分发到后端服务器上，提高服务的可扩展性和可用性。

实现方式：

eBPF：eBPF是一个在内核中执行代码的虚拟机。它使用特定的eBPF指令集，以及LLVM前端编译器将高级的eBPF程序转换为安全的内核字节码。
iptables：iptables是基于Netfilter框架的用户空间工具，通过配置Netfilter规则表和链来实现数据包过滤和转发。iptables规则会转换为内核中的Netfilter规则集。
IPVS：IPVS是内核中的一个模块，通过Linux虚拟服务器（LVS）框架提供负载均衡功能。它使用内核中的IPVS子系统来进行负载均衡决策和流量分发。

需要注意的是，尽管eBPF具有灵活的功能和强大的性能，但它的使用需要更高级的技术和开发经验。而iptables和IPVS则更加成熟和易于使用，适用于常见的网络安全和负载均衡需求。

Flannel

Flannel 概述

Flannel 是 Kubernetes 中常用的 CNI 插件之一，用于提供容器之间的网络通信和与外部网络的通信。

Flannel 的原理是通过将每个节点上的 Pod IP 地址转换为一个不同的子网 IP 地址，实现容器之间的通信。

Flannel 使用的是虚拟网络的方式，将每个节点的 Pod IP 地址映射到一个虚拟的网络中，然后通过网络隧道将不同节点上的容器连接起来。

Flannel 的优点包括：

简单易用：Flannel 的安装和配置相对简单，且能够轻松地与 Kubernetes 集成。
多种网络后端：Flannel 支持多种网络后端，包括 VXLAN、UDP 和 Host-GW，可以满足不同场景的需求。
性能高效：Flannel 采用了虚拟网络技术，能够快速实现容器之间的通信，且网络延迟较小。
可扩展性强：Flannel 可以方便地扩展到大规模的集群环境中，且支持跨云平台的部署。

然而，Flannel 也存在一些缺点，例如：

网络拓扑不稳定：Flannel 的网络拓扑依赖于底层网络设施，例如路由器和交换机等，若底层网络拓扑发生变化，可能会影响容器之间的通信。
部署复杂性：对于一些复杂的网络拓扑场景，Flannel 的部署和配置可能会比较繁琐。
IP 碰撞问题：在 Flannel 中，每个节点上的 Pod IP 地址都是唯一的，因此在大规模集群中，可能会出现 IP 地址碰撞的问题。

Flannel 负责在集群中的多个节点之间提供第 3 层 IPv4 网络。Flannel 不控制容器如何与主机联网，只控制流量在主机之间的传输方式。
Flannel 通过在每一个节点上启动一个叫做flanneld的进程，负责每一个节点上的子网划分，并将相关的配置信息（如各个节点的子网网段、外部IP等）保存到etcd中，flanneld只需要WATCH这些数据的变化，然后实时更新路由表即可，而具体的网络包转发交给具体的backend实现
Flannel 专注于网络。对于网络策略，可以使用Calico等其他项目。

参考文档：

https://github.com/flannel-io/flannel

flanneld

Flannel 确实以 DaemonSet 的方式在每个节点上运行 flanneld 守护进程，而 flanneld 守护进程主要负责以下任务：

NetworkPolicy

NetworkPolicy 概述

网络策略，管控Pod间的通信流量；
k8s的名称空间，仅用于为资源名称提供隔离机制，而默认Pod与Pod间通信都是放行的；
egress：出站流量
ingress：入站流量

NetworkPolicy Explain

apiVersion: networking.k8s.io/v1  # 资源隶属的API群组及版本号
kind: NetworkPolicy  # 资源类型的名称，名称空间级别的资源；
metadata:  # 资源元数据
  	name <string>  # 资源名称标识
  	namespace <string>  # NetworkPolicy是名称空间级别的资源
spec:  # 期望的状态
  	podSelector <Object>  # 当前规则生效的同一名称空间中的一组目标Pod对象，必选字段，空值表示当前名称空间中的所有Pod资源
  	policyTypes <[]string>  # Ingress表示生效ingress字段；Egress表示生效egress字段，同时提供表示二者均有效
	ingress <[]Object>  # 入站流量源端点对象列表，白名单，空值表示“所有”
	- from <[]Object>  # 具体的端点对象列表，空值表示所有合法端点
	  - ipBlock  <Object> # IP地址块范围内的端点，不能与另外两个字段同时使用
	  - namespaceSelector <Object> # 匹配的名称空间内的端点
	    podSelector <Object>  # 由Pod标签选择器匹配到的端点，空值表示<none>
	  ports <[]Object>  # 具体的端口对象列表，空值表示所有合法端口
	egress <[]Object>  # 出站流量目标端点对象列表，白名单，空值表示“所有”
	- to <[]Object>  # 具体的端点对象列表，空值表示所有合法端点，格式同ingres.from；
	  ports <[]Object>  # 具体的端口对象列表，空值表示所有合法端口

NetworkPolicy Example-1

定义允许的入站流量

DNS

K8s 中的 DNS 解析流程

Pod → 本节点 nodelocaldns → CoreDNS → 外部上游

本节点 nodelocaldns 为容器 /etc/resolv.conf 文件中 nameserver 所定义的 IP

nodelocaldns

每个 Node 上会以 DaemonSet 形式运行一个 nodelocaldns（本地 DNS 缓存代理）

该 Pod 监听地址通常为 169.254.25.10:53 以及 ::ffff:169.254.25.10:53

该 IP 源自于 kubelet 的配置参数

这个本地缓存代理再把请求向上游转发（上游通常就是 CoreDNS 的 ClusterIP）

CoreDNS

CoreDNS 是 k8s 的核心插件，提供了 DNS 和 Serviec Discover 功能；
Serviec Discover 可以动态发现 endpoint 中的 pod 列表，从而实现动态添加和删除相关解析记录。
CoreDNS 将传统的DNS服务直接提供一个云原生解决方案，他支持从apiserver动态加载相关的service及端点信息，并自动生成资源记录。

# kubectl get pod -n kube-system -l k8s-app=kube-dns
NAME                       READY   STATUS    RESTARTS       AGE
coredns-65c54cc984-8sfk8   1/1     Running   35 (43h ago)   104d
coredns-65c54cc984-fpv5f   1/1     Running   35 (43h ago)   104d

# kubectl describe svc -n kube-system kube-dns 
Name:              kube-dns
Namespace:         kube-system
Labels:            k8s-app=kube-dns
                   kubernetes.io/cluster-service=true
                   kubernetes.io/name=CoreDNS
Annotations:       prometheus.io/port: 9153
                   prometheus.io/scrape: true
Selector:          k8s-app=kube-dns
Type:              ClusterIP
IP Family Policy:  SingleStack
IP Families:       IPv4
IP:                10.96.0.10 # 默认为10.96.0.10
IPs:               10.96.0.10
Port:              dns  53/UDP
TargetPort:        53/UDP
Endpoints:         10.244.0.74:53,10.244.0.75:53
Port:              dns-tcp  53/TCP
TargetPort:        53/TCP
Endpoints:         10.244.0.74:53,10.244.0.75:53
Port:              metrics  9153/TCP
TargetPort:        9153/TCP
Endpoints:         10.244.0.74:9153,10.244.0.75:9153
Session Affinity:  None
Events:            <none>

参考文档：