最近业界使用范围最广的K8S CNI网络方案 Calico 宣布支持 eBPF,而作为第一个通过 eBPF 实现了 kube-proxy 所有功能的 K8S 网络方案——Cilium,它的先见之名是否能转成优势,继而成为 CNI 新的头牌呢?今天我们一起来入门最 Cool Kubernetes 网络方案 Cilium。Cilium介绍
以下基于 Cilium官网文档翻译整理。
当前趋势
现代数据中心的应用系统已经逐渐转向基于微服务架构的开发体系,一个微服务架构的应用系统是由多个小的独立的服务组成,它们之间通过轻量通信协议如 HTTP、gRPC、Kafka 等进行通信。微服务架构下的服务天然具有动态变化的特点,结合容器化部署,时常会引起大规模的容器实例启动或重启。要确保这种向高度动态化的微服务应用之间的安全可达,既是挑战,也是机遇。现有问题
传统的 Linux 网络访问安全控制机制(如 iptables)是基于静态环境的IP地址和端口配置网络转发、过滤等规则,但是 IP 地址在微服务架构下是不断变化的,非固定的;出于安全目的,协议端口(例如 HTTP 传输的 TCP 端口 80)也不再固定用来区分应用系统。为了匹配大规模容器实例快速变化的生命周期,传统网络技术需要维护成千上万的负载均衡规则和访问控制规则,并且需要以不断增长的频率更新这些规则,而如果没有准确的可视化功能,要维护这些规则也是十分困难,这些对传统网络技术的可用性和性能都是极大的挑战。比如经常会有人对 kube-proxy 基于 iptables 的服务负载均衡功能在大规模容器场景下具有严重的性能瓶颈,同时由于容器的创建和销毁非常频繁,基于 IP 做身份关联的故障排除和安全审计等也很难实现。解决方案
Cilium 作为一款 Kubernetes CNI 插件,从一开始就是为大规模和高度动态的容器环境而设计,并且带来了 API 级别感知的网络安全管理功能,通过使用基于 Linux 内核特性的新技术——BPF,提供了基于 service/pod/container 作为标识,而非传统的 IP 地址,来定义和加强容器和 Pod 之间网络层、应用层的安全策略。因此,Cilium 不仅将安全控制与寻址解耦来简化在高度动态环境中应用安全性策略,而且提供传统网络第 3 层、4 层隔离功能,以及基于 http 层上隔离控制,来提供更强的安全性隔离。另外,由于 BPF 可以动态地插入控制 Linux 系统的程序,实现了强大的安全可视化功能,而且这些变化是不需要更新应用代码或重启应用服务本身就可以生效,因为 BPF 是运行在系统内核中的。以上这些特性,使 Cilium 能够在大规模容器环境中也具有高度可伸缩性、可视化以及安全性。部署 Cilium部署 Cilium 非常简单,可以通过单独的 yaml 文件部署全部组件(目前我使用了这个方式部署了1.7.1 版本),也可以通过 helm chart 一键完成。重要的是部署环境和时机:- 官方建议所有部署节点都使用 Linux 最新稳定内核版本,这样所有的功能都能启用,具体部署环境建议可以参照这里。
- 作为一个 Kubernetes 网络组件,它应该在部署 Kubernetes 其他基础组件之后,才进行部署。这里,我自己遇到的问题是,因为还没有 CNI 插件,coredns 组件的状态一直是 pending的,直到部署完 Cilium 后,coredns 完成了重置变成running状态。
>kubectlapply-fconnectivity-check.yaml NAMEREADYUP-TO-DATEAVAILABLEAGE echo-a1/11116d echo-b1/11116d host-to-b-multi-node-clusterip1/11116d host-to-b-multi-node-headless1/11116d pod-to-a1/11116d pod-to-a-allowed-cnp1/11116d pod-to-a-external-11111/11116d pod-to-a-l3-denied-cnp1/11116d pod-to-b-intra-node1/11116d pod-to-b-multi-node-clusterip1/11116d pod-to-b-multi-node-headless1/11116d pod-to-external-fqdn-allow-google-cnp1/11116d 如果所有的 deployment 都能成功运行起来,说明 Cilium 已经成功部署并工作正常。网络可视化神器 Hubble上文提到了 Cilium 强大之处就是提供了简单高效的网络可视化功能,它是通过 Hubble组件完成的。Cilium在1.7版本后推出并开源了Hubble,它是专门为网络可视化设计,能够利用 Cilium 提供的 eBPF 数据路径,获得对 Kubernetes 应用和服务的网络流量的深度可见性。这些网络流量信息可以对接 Hubble CLI、UI 工具,可以通过交互式的方式快速诊断如与 DNS 相关的问题。除了 Hubble 自身的监控工具,还可以对接主流的云原生监控体系—— Prometheus 和 Grafana,实现可扩展的监控策略。
部署 Hubble 和 Hubble UI
官方提供了基于 Helm Chart 部署方式,这样可以灵活控制部署变量,实现不同监控策略。出于想要试用 hubble UI 和对接 Grafana,我是这样的部署的:>helmtemplatehubble --namespacekube-system --setmetrics.enabled="{dns:query;ignoreAAAA;destinationContext=pod-short,drop:sourceContext=pod;destinationContext=pod,tcp,flow,port-distribution,icmp,http}" --setui.enabled=true >hubble.yaml >kubectlapply-fhubble.yaml #包含两个组件 #-daemonsethubble #-deploymenthubbleUI >kubectlgetpod-nkube-system|grephubble hubble-67ldp1/1Running021h hubble-f287p1/1Running021h hubble-fxzms1/1Running021h hubble-tlq641/1Running121h hubble-ui-5f9fc85849-hkzkr1/1Running015h hubble-vpxcb1/1Running021h
运行效果
由于默认的 Hubble UI 只提供了 ClusterIP 类似的 service,无法通过外部访问。因此需要创建一个 NodePort 类型的 service,如下所示:#hubble-ui-nodeport-svc.yaml kind:Service apiVersion:v1 metadata: namespace:kube-system name:hubble-ui-np spec: selector: k8s-app:hubble-ui ports: -name:http port:12000 nodePort:32321 type:NodePort执行
kubectl apply -f hubble-ui-nodeport-svc.yaml
,就可以通过任意集群节点 IP 地址加上 32321 端口访问 Hubble UI 的 web 服务了。打开效果如下所示:
-
页面上半部分是之前部署的一整套 conectivity-check 组件的数据流向图,官方叫做
Service Map
,默认情况下可以自动发现基于网络 3 层和 4 层的访问依赖路径,看上去非常 cool,也有点分布式链路追踪图的感觉。点击某个服务,还能看到更为详细的关系图:
- 下图是 kube-system 命名空间下的数据流图,能看到 Hubble-UI 组件和 Hubble 组件是通过gRPC 进行通信的,非常有趣。但令人感到的好奇的是,为何没有显示 Kubernetes 核心组件之间的调用关系图:
对接 Grafana + Prometheus
如果你跟一样是 Grafana+ Prometheus 的忠实粉丝,那么使 Hubble 对接它们就是必然操作了。仔细的同学已经发现之前 helm template 的玄机了:--setmetrics.enabled="{dns:query;ignoreAAAA;destinationContext=pod-short,drop:sourceContext=pod;destinationContext=pod,tcp,flow,port-distribution,icmp,http}" #上面的设置,表示开启了 hubble 的 metrics 输出模式,并输出以上这些信息。 #默认情况下,Hubble daemonset 会自动暴露 metrics API 给 Prometheus。 你可以对接现有的 Grafana+Prometheus 服务,也可以部署一个简单的:
#下面的命令会在命名空间cilium-monitoring下部署一个Grafana服务和Prometheus服务 $kubectlapply-fhttps://raw.githubusercontent.com/cilium/cilium/v1.6/examples/kubernetes/addons/prometheus/monitoring-example.yaml #创建对应NodePortService,方便外部访问web服务 $kubectlexposedeployment/grafana--type=NodePort--port=3000--name=gnp-ncilium-monitoring $kubectlexposedeployment/prometheus--type=NodePort--port=9090--name=pnp-ncilium-monitoring 完成部署后,打开 Grafana 网页,导入官方制作的 dashboard,可以快速创建基于 Hubble 的 metrics 监控。等待一段时间,就能在 Grafana 上看到数据了: Cilium 配合 Hubble,的确非常好用!取代 kube-proxy 组件Cilium 另外一个很大的宣传点是宣称已经全面实现kube-proxy的功能,包括
ClusterIP
,NodePort
,ExternalIPs
和LoadBalancer
,可以完全取代它的位置,同时提供更好的性能、可靠性以及可调试性。当然,这些都要归功于 eBPF 的能力。官方文档中提到,如果你是在先有 kube-proxy 后部署的 Cilium,那么他们是一个 “共存” 状态,Cilium 会根据节点操作系统的内核版本来决定是否还需要依赖 kube-proxy 实现某些功能,可以通过以下手段验证是否能停止 kube-proxy 组件:#检查Cilium对于取代kube-proxy的状态 >kubectlexec-it-nkube-system[Cilium-agent-pod]--ciliumstatus|grepKubeProxyReplacement #默认是Probe状态 #当Ciliumagent启动并运行,它将探测节点内核版本,判断BPF内核特性的可用性, #如果不满足,则通过依赖kube-proxy来补充剩余的Kubernetess, #并禁用BPF中的一部分功能 KubeProxyReplacement:Probe[NodePort(SNAT,30000-32767),ExternalIPs,HostReachableServices(TCP,UDP)] #查看Cilium保存的应用服务访问列表 #有了这些信息,就不需要kube-proxy进行中转了 >kubectlexec-it-nkube-system[Cilium-agent-pod]--ciliumservicelist IDFrontendServiceTypeBackend 110.96.0.10:53ClusterIP1=>100.64.0.98:53 2=>100.64.3.65:53 210.96.0.10:9153ClusterIP1=>100.64.0.98:9153 2=>100.64.3.65:9153 310.96.143.131:9090ClusterIP1=>100.64.4.100:9090 410.96.90.39:9090ClusterIP1=>100.64.4.100:9090 50.0.0.0:32447NodePort1=>100.64.4.100:9090 610.1.1.179:32447NodePort1=>100.64.4.100:9090 7100.64.0.74:32447NodePort1=>100.64.4.100:9090 810.96.190.1:80ClusterIP 910.96.201.51:80ClusterIP 1010.96.0.1:443ClusterIP1=>10.1.1.171:6443 2=>10.1.1.179:6443 3=>10.1.1.188:6443 1110.96.129.193:12000ClusterIP1=>100.64.4.221:12000 120.0.0.0:32321NodePort1=>100.64.4.221:12000 1310.1.1.179:32321NodePort1=>100.64.4.221:12000 14100.64.0.74:32321NodePort1=>100.64.4.221:12000 1510.96.0.30:3000ClusterIP 1610.96.156.253:3000ClusterIP 17100.64.0.74:31332NodePort 180.0.0.0:31332NodePort 1910.1.1.179:31332NodePort 2010.96.131.215:12000ClusterIP1=>100.64.4.221:12000 #查看iptables是否有kube-proxy维护的规则 >iptables-save|grepKUBE-SVC
责任编辑:haq
声明:本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人,不代表电子发烧友网立场。文章及其配图仅供工程师学习之用,如有内容侵权或者其他违规问题,请联系本站处理。
举报投诉
-
网络
+关注
关注
14文章
7511浏览量
88605 -
容器
+关注
关注
0文章
492浏览量
22041
原文标题:Kubernetes 网络方案——炫酷的 Cilium
文章出处:【微信号:magedu-Linux,微信公众号:马哥Linux运维】欢迎添加关注!文章转载请注明出处。
发布评论请先 登录
相关推荐
Kubernetes集群搭建容器云需要几台服务器?
Kubernetes集群搭建容器云需要几台服务器?至少需要4台服务器。搭建容器云所需的服务器数量以及具体的搭建步骤,会根据所选用的技术栈、业务规模、架构设计以及安全需求等因素而有所不同。以下是一个基于Kubernetes集群的容器云搭建的概述:
基于DPU与SmartNIC的K8s Service解决方案
1. 方案背景 1.1. Kubernetes Service介绍 Kubernetes Service是Kubernetes中的一个核心概念,它定义了一种抽象,用于表示一组提供相同
TSN时间敏感网络技术入门级解决方案TSN BasicSolution
随着TSN技术获得越来越多的关注和广泛应用,TSN Systems公司推出了一款入门级的解决方案TSN BasicSolution,通过简化的方式为用户提供关键功能,基于硬件与软件的无缝集成,帮助您提升生产力,更快实现目标并且有效应对复杂的任务和分析需求。
如何使用Kubeadm命令在PetaExpress Ubuntu系统上安装Kubernetes集群
Kubernetes,通常缩写为K8s,是一个开源的容器编排平台,旨在自动化容器化应用的部署、扩展和管理。有了Kubernetes,您可以轻松地部署、更新和扩展应用,而无需担心底层基础设施。
CK-RA6M5上的RA AWS云连接,带蜂窝网络-入门指南
电子发烧友网站提供《CK-RA6M5上的RA AWS云连接,带蜂窝网络-入门指南.pdf》资料免费下载
发表于 02-19 10:50
•0次下载
Kubernetes Gateway API攻略教程
Kubernetes Gateway API 刚刚 GA,旨在改进将集群服务暴露给外部的过程。这其中包括一套更标准、更强大的 API资源,用于管理已暴露的服务。在这篇文章中,我将介绍 Gateway
配置Kubernetes中Pod使用代理的两种常见方式
在企业网络环境中进行Kubernetes集群的管理时,经常会遇到需要配置Pods通过HTTP代理服务器访问Internet的情况。这可能是由于各种原因,如安全策略限制、网络架构要求或者访问特定资源
使用Jenkins和单个模板部署多个Kubernetes组件
在持续集成和部署中,我们通常需要部署多个实例或组件到Kubernetes集群中。通过Jenkins的管道脚本,我们可以自动化这个过程。在本文中,我将演示如何使用Jenkins Pipeline及单个
Kubernetes RBAC:掌握权限管理的精髓
Kubernetes RBAC(Role-Based Access Control)是 Kubernetes 中一项关键的安全功能,它通过细粒度的权限控制机制,确保集群资源仅被授权的用户或服务账号访问。
Kubernetes开发指南之深入理解CRD
CRD本身是Kubernetes内置的资源类型,全称是CustomResourceDefinition,可以通过命令查看,kubectl get查看集群内定义的CRD资源。
Art.Galaxy酷芯AI工具链解决方案
Art. Galaxy 是酷芯微电子为 AR 系列视觉 AI SoC 打造的 AI 解决方案,它包含运行在 ARM Cortex-A 系列处理器、CEVA DSP、NPU 等多个硬件处理单元上的板端
评论