相关文章推荐

虚拟网络之Kubernetes Cilium CNI 网络通信调测

Cilium CNI 是基于Linux 新版本内核中的eBPF实现的,对应数据面转发逻辑和Flannel CNI 比较有了不小的变化,从实现机制上来说,性能上是有很大的提升的;本篇就是将我在环境上实操验证进行一个简单的记录;关于Cilium CNI 安装,可以参考官网,也可以查看我之前的博客;
https://docs.cilium.io/en/v1.9/gettingstarted/k8s-install-default/
https://blog.csdn.net/LL845876425/article/details/110410377

Cilium CNI 配置查看

查看Cilium CNI 相关网络配置;

cat /etc/cni/net.d/05-cilium.conf
kubectl get pods -n kube-system -o wide
kubectl get cm -n kube-system -o wide
kubectl get cm cilium-config -n kube-system -o yaml
[root@master ~]# cat /etc/cni/net.d/05-cilium.conf
  "cniVersion": "0.3.1",
  "name": "cilium",
  "type": "cilium-cni",
  "enable-debug": false
[root@master ~]#

同Node pod 通信:

同节点内部的容器之间的连通性依赖内核协议栈二层转发和BPF程序,不会经过像OVS或Linux bridge这样的二层设备。这部分功能由Cilium Agent负责,使用BPF规则进行流量的管控。简单示意图如下:

官方示意图如下:
可以看到,同节点的容器之间通信直接走BPF规则即可;不同节点的容器的通信需要通过各个节点上的cilium_host接口进行转发;
在这里插入图片描述

容器和所在节点的通信走节点内部的三层路由和BPF转发,BPF程序连接容器的veth pair和它的网关设备。

如下路由中,将cilium_host作为容器的默认网关。容器和容器所在的节点的通信需要经过cilium_host接口

client pod centos-test-764675d946-c2scc 10.0.1.174 master
server pod nginx-nets-c6744f88d-p8kr4 10.0.1.179 master


可以看到没有对应的2层bridge:

client pod 看到 if12,对应node 节点上序号12 的设备,查看node节点网卡配置,即是:

12: lxc175346e62e21@if11: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 2a:b8:ff:5a:83:b5 brd ff:ff:ff:ff:ff:ff link-netnsid 2

指定该设备口抓包,即可抓到从 pod 出的包;

该设备对应设备类型为 veth

[root@centos-test-764675d946-c2scc /]# curl -I 10.0.1.179
HTTP/1.1 200 OK
Server: nginx/1.19.3
Date: Mon, 30 Nov 2020 08:30:11 GMT
Content-Type: text/html
Content-Length: 612
Last-Modified: Tue, 29 Sep 2020 14:12:31 GMT
Connection: keep-alive
ETag: "5f7340cf-264"
Accept-Ranges: bytes
[root@centos-test-764675d946-c2scc /]# ip a s
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
11: eth0@if12: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 4a:a1:12:a5:22:51 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 10.0.1.174/32 scope global eth0
       valid_lft forever preferred_lft forever
[root@centos-test-764675d946-c2scc /]# ip route show
default via 10.0.1.205 dev eth0 mtu 1450
10.0.1.205 dev eth0 scope link
[root@centos-test-764675d946-c2scc /]#

节点和pod上 ip route 记录:

# pod 
[root@centos-test-764675d946-c2scc /]# ip route show
default via 10.0.1.205 dev eth0 mtu 1450
10.0.1.205 dev eth0 scope link
[root@centos-test-764675d946-c2scc /]#
# node节点:
[root@master ~]# ip route show
default via 172.16.0.1 dev eth0
10.0.0.0/24 via 10.0.1.205 dev cilium_host src 10.0.1.205 mtu 1450
10.0.1.0/24 via 10.0.1.205 dev cilium_host src 10.0.1.205 mtu 1450
10.0.1.205 dev cilium_host scope link
169.254.0.0/16 dev eth0 scope link metric 1002
172.16.0.0/20 dev eth0 proto kernel scope link src 172.16.0.5
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
[root@master ~]#


另外还可以看到 Cilium 还是会有一些iptables 规则下发

跨node pod 访问:

下面是使用Host L3进行跨节点通信的流程图

下面是使用vxlan进行跨节点通信的流程图

Cilium cli

使用Cilium后,不会再使用kube-proxy,它会从Kubernetes API服务器获得Service信息,并存入BPF。可以使用cilium命令行查看相关的信息。
如使用# cilium node list查看当前的node节点信息,使用# cilium service list查看service信息等。对于策略的获取,可以通过命令行# cilium policy get,也可以通过Hubble UI查看,如下:

文章目录虚拟网络之Kubernetes Cilium CNI 网络通信调测前言Cilium CNI 配置查看同Node pod 通信:跨node pod 访问:Cilium cli参考:虚拟网络之Kubernetes Cilium CNI 网络通信调测前言Cilium CNI 是基于Linux 新版本内核中的eBPF实现的,对应数据面转发逻辑和Flannel CNI 比较有了不小的变化,从实现机制上来说,性能上是有很大的提升的;本篇就是将我在环境上实操验证进行一个简单的记录;关于Cilium CNI
随着越来越多的企业采用 Kubernetes,围绕多云、安全、可见性和可扩展性等新要求,可编程数据平面的需求用例范围越来越广。此外,服务网格和无服务器等新技术对 Kubernetes 底层提出了更多的定制化要求。这些新需求都有一些共同点:它们需要一个更可编程的数据平面,能够在不牺牲性能的情况下执行 Kubernetes 感知的网络数据操作。 Cilium 项目通过引入扩展的伯克利数据包过滤器(eB...
$ GO111MODULE= " on " go get sigs.k8s.io/kind@v0.10.0 $ curl -LO " https://dl.k8s.io/release/ $( curl -L -s https://dl.k8s.io/release/stable.txt ) /bin/linux/amd64/kubectl " $ curl -LO " https://dl.k8s.io/ $( curl -L -s https://dl.k8s.io/release/stable.txt ) /bin/linux/amd64/kubectl.sha256 " $ echo " $( < kubectl.sha256 ) kubectl " | sha2 cilium-vxlan,用于vxlan封包; cilium-host和cilium-net,一对veth-pair(类似于kube-proxy ipvs创建的dummy网卡)。 1、c1 ping c2的通信细节
文章目录虚拟网络Kubernetes Cilium CNI 快速部署实操前言卸载Flannel CNIInstall Cilium CNI 虚拟网络Kubernetes Cilium CNI 快速部署实操 在之前部署的kubernetes 集群,这里想把已部署的Flannel CNI 更换为 Cilium CNI,本篇记录下实操记录; 之前部署的记录见博客《记一次实操部署Kubernetes_v1.19.2》 卸载Flannel CNI # 一般生产环境是不会这样操作的,因为一旦把 cni 卸载后
1.cilium安装卸载flannel# 一般生产环境是不会这样操作的,因为一旦把 cni 卸载后,所有pod 都会因为没有对应cni 支持,导致pod 无法正常运行和通信异常; # 生产环境如果涉及需要更换cni ,一般不会涉及,即便涉及到更换cni的,也会采用新部署一套集群,然后进行迁移; # 卸载flannel cni 插件: # 根据部署时记录,确认版本; [root@master ~]# kubectl delete -f https://raw.githubusercontent.com/cor
eBPF 是 extended BPF 的简称,eBPF 起源于BPF,它提供了内核的数据包过滤机制,其扩充了 BPF 的功能,丰富了指令集。 在 Cilium 出现之前, Service 由 kube-proxy 来实现,实现方式有 userspace,iptables,ipvs 三种模式。 Cilium 是基于 eBpf 的一种开源网络实现,通过在 Linux 内核动态插入强大的安全性、可见性和网络控制逻辑,提供网络互通,服务负载均衡,安全和可观性等解决方案。简单来说可以理解为 Kube-proxy + CNI 网络实现。Cilium 位于容器编排系统和Linux Kernel 之间,向上可以通过编排平台为容器进行网络以及相应的安全配置,向下可以通过在 Linux 内核挂载 eBPF 程序,来控制容器网络的转发行为以及安全策略执行。
Kubernetes网络,服务和安全性可观察性 什么是哈勃? Hubble是一个用于云原生工作负载的完全分布式的网络和安全性可观察性平台。 它建立在和的基础上,以完全透明的方式深入了解服务以及网络基础结构的通信和行为。 哈勃可以回答以下问题: 服务依赖性和通信图: 哪些服务正在相互通信? 多久一次? 服务依赖关系图是什么样的? 正在进行哪些HTTP用? 服务从哪个卡夫卡主题消费或产生消费? 操作监控和警报: 网络通信是否失败? 为什么通讯失败? 是DNS吗? 是应用程序还是网络问题? 通信在第4层(TCP)或第7层(HTTP)上断开了吗? 哪些服务在最近5分钟内遇到了DNS解析问题? 哪些服务最近经历了TCP连接中断或连接超时? 未答复的TCP SYN请求的速率是多少? 应用监控: 特定服务或跨所有群集的5xx或4xx HTTP响应代码的速率是多少? 在群集中HTTP请求和响应之间的第95和99%的延迟是多少? 哪些服务表现最差? 两项服务之间的延迟是多少? 安全性可观察性: 哪些服务由于网络策略而被阻止连接? 从集群外部访问了哪些服务? 哪些服务已解析特
TL;DR 在本篇,我们分别使用了 Kubernetes 原生的网络策略和 Cilium网络策略实现了 Pod 网络层面的隔离。不同的是,前者只提供了基于 L3/4 的网络策略;后者支持 L3/4、L7 的网络策略。 通过网络策略来提升网络安全,可以极大降低了实现和维护的成本,同时对系统几乎没有影响。 尤其是基于 eBPF 技术的 Cilium,解决了内核扩展性不足的问题,从内核层面为工作负载提供安全可靠、可观网络连接。 为什么说 Kubernetes 网络存在安全隐患?集群中的 Pod 默.
本文主要在centos7系统上基于docker和cilium组件部署v1.23.6版本的k8s原生集群,由于集群主要用于自己平时学习和试使用,加上资源有限,暂不涉及高可用部署。 此前写的一些关于k8s基础知识和集群搭建的一些方案,有需要的同学可以看一下。 1、准备工作 1.1 cilium-集群节点信息 机器均为8C8G的虚拟机,硬盘为100G。
### 回答1: Kubernetes网络模型是一种用于在集群中连接和管理容器的方法。Kubernetes提供了一组核心网络概念,例如Pod,Service和Ingress,来帮助管理网络流量和容器间通信。 Pod是Kubernetes中最小的可管理单位,通常由一个或多个容器组成。Pods共享同一网络空间,并且可以在同一个Node上的不同的Pods之间直接通信。 Service是Kubernetes中的逻辑抽象,用于代表一组相关的Pods。Services通过定义一个统一的IP地址和端口,提供了一种简单的方法来访问Pod的群集。 Ingress是一种在Kubernetes集群外部访问应用程序的方法。Ingress定义了应用程序的URL路径和请求路由方式,并且允许将外部请求路由到集群内的合适的Service或Pod。 Kubernetes还支持使用多种网络插件,如Calico,Flannel,Cilium等来实现它的网络模型。这些插件可以定义如何在集群中配置网络,以及如何管理网络流量。 总的来说,Kubernetes网络模型为在集群中的容器间提供了一种简单,高效和可扩展的方法来进行通信。 ### 回答2: Kubernetes网络模型包括主机网络、Pod网络和服务网络三个方面。 首先,主机网络是指每个Kubernetes节点所连接的物理网络。每个节点上会有一个或多个网络接口,用于与其他节点通信,以及与外部网络进行数据交换。这些接口通常是以太网、无线网络虚拟网桥等。 其次,Pod网络是指在同一个Kubernetes节点上运行的一组容器共享的虚拟网络。在每一个节点上,Kubernetes会创建一个称为容器网络接口(CNI)的软件插件,该插件负责为Pod分配唯一的IP地址、创建虚拟网络和实现跨节点的通信。Pod可以通过直接使用IP地址进行通信,而无需进行任何网络地址转换。 最后,服务网络是一种抽象层,用于为Kubernetes集群中的应用程序提供网络服务的发现和负载均衡功能。Kubernetes中的服务是一组Pod的逻辑分组,并为这些Pod提供一个唯一的DNS名称和虚拟IP地址。当应用程序需要访问服务时,它们可以通过使用该名称和IP地址来进行通信,而无需关心具体的后端Pod在哪个节点上运行。 总的来说,Kubernetes网络模型通过将主机网络、Pod网络和服务网络紧密结合在一起,为容器化应用程序提供了高度灵活、高度可扩展和高度可靠的网络通信方式。它可以让应用程序之间无缝通信,并实现高效的负载均衡和服务发现。 ### 回答3: Kubernetes网络模型是指它提供的网络服务和架构。Kubernetes使用的网络模型主要包括了两个重要概念:Pod和Service。 首先,Pod是Kubernetes中最基本的运行单元,它由一个或多个紧密关联的容器组成,这些容器共享相同的IP地址和网络命名空间。每个Pod都有独立的IP地址,并且可以在集群中的任意节点上运行。Pod内的容器可以通过localhost进行通信,可以实现容器之间的高效通信。 其次,Kubernetes提供了Service来实现对外部网络的访问。Service是一组Pod的逻辑分组,它们可以被集群内外的其他服务访问。Service会为这些Pod分配一个虚拟IP地址,这个虚拟IP地址可以用作其他服务或终端用户与Pod进行通信的入口点。在这个过程中,Service会根据一定的负载均衡算法将请求路由到相应的Pod上。 Kubernetes网络模型还采用了一种称为CNI(Container Network Interface)的标准,它定义了容器和主机之间的网络接口和驱动。Kubernetes集群中的每个节点都有一个CNI插件来管理网络,这些插件可以实现不同的网络方案,如自定义网络、软件定义网络等。CNI插件可以与底层网络设备进行通信,以确保Pod和Service之间的网络正常工作。 总结来说,Kubernetes网络模型通过使用Pod和Service等概念,以及CNI插件来实现容器之间和容器与外部网络之间的通信。这个模型能够提供灵活、可扩展和高性能的网络服务,为Kubernetes集群中的应用程序提供可靠的网络支持。
 
推荐文章