作者范建明、洪志国、张浩，均为腾讯云容器产品中心高级工程师，负责容器网络和Service Mesh，容器Runtime，调度等相关研发工作。
作者范建明、洪志国、张浩，均为腾讯云容器产品中心高级工程师，负责容器网络和Service Mesh，容器Runtime，调度等相关研发工作。 Kubernetes Service[1] 用于实现集群中业务之间的互相调用和负载均衡，目前社区的实现主要有userspace，iptables和IPVS三种模式。IPVS模式的性能最好，但依然有优化的空间。该模式利用IPVS内核模块实现DNAT，利用nf_conntrack/iptables实现SNAT。nf_conntrack是为通用目的设计的，其内部的状态和流程
618 买了几个便宜的 Purple PI OH 开发板[1] (500 块多一点买了 3 个🤑), 这个开发板类似树莓派，是基于 Rockchip（瑞芯微） 的 rx3566 arm64 芯片。如下：
将 Kubernetes 的 CNI 从其他组件切换为 Cilium, 已经可以有效地提升网络的性能. 但是通过对 Cilium 不同模式的切换/功能的启用, 可以进一步提升 Cilium 的网络性能. 具体调优项包括不限于:
Debian 项目近日发布了针对 Debian GNU/Linux 9 “ Stretch ” 系列操作系统新的 Linux 内核安全更新，修复了最近发现的几个漏洞 。
https://cloud.tencent.com/document/product/457/35747 一些containerd与docker的对应
译自：http://docs.cilium.io/en/stable/architecture/
在linux系统中为了更好的实现网络流量的管理，使用了内核的mark来标识网络流量。这样造成了用户层再使用mark来标记多线负载，两种mark会互相覆盖，达不到想要的结果。在此种情况下，通过研究发现可以扩展mark模块来解决这种冲突。 1 Iptables的结构和命令格式分析 1.1 Iptables的结构分析 Iptables是linux系统为用户提供的一个配置防火墙的工具。它提供一个命名规则集。在linux中iptables防火墙实现的核心模块是netfilter，它负责维护防火墙的规则链表，实现防火墙安全防御能力。Netfilter主要有三种功能：数据包过滤、网络地址转换（nat）以及数据包处理（mangle）。数据包过滤模块的功能是过滤报文，不作任何修改，或者接受，或者拒绝。Nat是网络地址转换，该模块以connection tracking模块为基础，仅对每个连接的第一个报文进行匹配和处理，然后交由connection tracking模块将处理结果应用到该连接之后的所有报文。Mangle是属于可以进行报文内容修改的ip tables，可供修改的报文内容包括mark、tos、ttl等。同时该模块带有用户空间和内核交流的接口。 1.2 Iptables命令格式分析 一个最简单的规则可以描述为拒绝所有转发报文，用iptables命令表示就是：iptables -A FORWORD -j DROP。Iptables应用程序将命令行输入转换为程序可读的格式，然后再调用libiptc库提供的iptc_commit（）函数向核心提交该操作请求。它根据请求设置了一个struct ipt_replace结构，用来描述规则所涉及的表和HOOK点等信息，并在其后附接当前这条规则，一个struct ipt_entry结构。组织好这些数据后，iptc_commit（）调用setsockopt（）系统调用来启动核心处理这一请求。 2 Netfilter的结构分析 Netfilter是linux系统中的内核防火墙框架，主要进行包过滤，连接跟踪，地址转换的功能，是防火墙的基础。其主要通过表、链实现。在netfilter中，每种网络协议都有自己的一套hook函数。数据报经过协议栈的几个关键点时调用hook函数，hook函数标号和协议栈数据报作为参数，传递给netfilter框架。其主要框架如图1所示： 3 Netfilter和 Iptables相关模块属性分析 3.1 与netfilter有关的结构 Netfilter一个重大修正思想就是将netfilter作为一个协议无关的框架，表现在内核结构树中单独建立net/netfilter目录，在net/netfilter下的匹配和目标模块文件名称以“xt_”开头。 为了和iptables兼容，这些文件中增加了一个新的宏定义：module_alias，来表示模块的别名。所有扩展程序的名称也是以xt开头。 Netfilter扩展的程序框架： Xt_kzmark.c： Static unsigned int kzmark_tg（struct sk_buff *skb， const struct xt_action_param *par） Static int kzmark_tg_check（const struct xt_tgchk_param *par） Static void kzmark_tg_destroy（const struct xt_tgdtor_param *par） Static boool kzmark_mt（const struct sk_buff *skb， struct xt_action_param *par） Static int kzmark_mt_check（const struct xt_mtchk_param *par） Static void kzmark_mt_destroy（const struct xt_mtdtor_param *par） Static struct xt_target kzmark_tg_reg __read_mostly = {} Static struct xt_match kzmark_mt_reg __read_mostly = {} Static int __init kzmark_mt_init（void） {Int ret； Need_ipv4_conntrack（）； Ret = xt_register_target（&kzmark_tg_reg）； Ret = xt_register_match（&kzmark_mt_reg）；} Static void_exi
一个 Kubernetes 应用程序在逻辑上分成两部分：一部分是计算资源（由 pod 表示），另一部分提供对应用程序的访问（由服务表示）。应用程序客户端可以使用抽象名称访问它，而无需关心实际上有哪个 pod 处理请求。并且，由于单个服务可能有多个 pod 作为后端，因此它还充当负载平衡器的角色。在默认的 Kubernetes 部署中，此负载平衡功能使用非常简单的 iptables 或 Linux IPVS 来实现——两者都在 L4（比如 TCP）层工作，并且执行朴素的、基于随机的循环机制。当然，云提供商还可以提供更传统的负载平衡解决方案来公开应用程序，但我们先从简单的开始。
K8S 当前重度依赖 iptables 来实现 Service 的抽象，对于每个 Service 及其 backend pods，在 K8s 里会生成很多 iptables 规则。例如 5K 个 Service 时，iptables 规则将达到 25K 条，导致的后果：
这篇是Network Policy最后一篇，主题是关于eBPF。前面两篇，我们聊完了Network Policy的意义和iptables实现，今天我们聊聊如何借助eBPF来摆脱对iptables的依赖，并实现Network Policy。
问卷链接（https://www.wjx.cn/jq/97146486.aspx） ---- 本文翻译自 2020 年 Daniel Borkmann 在 KubeCon 的一篇分享: eBPF and Kubernetes: Little Helper Minions for Scaling Microservices(https://kccnceu20.sched.com/event/ZemQ/ebpf-and-kubernetes-little-helper-minions-for-scaling-m
Netfilter （配合 iptables）使得用户空间应用程序可以注册内核网络栈在处理数据包时应用的处理规则，实现高效的网络转发和过滤。很多常见的主机防火墙程序以及 Kubernetes 的 Service 转发都是通过 iptables 来实现的。
关于 netfilter 的介绍文章大部分只描述了抽象的概念，实际上其内核代码的基本实现不算复杂，本文主要参考 Linux 内核 2.6 版本代码（早期版本较为简单），与最新的 5.x 版本在实现上可能有较大差异，但基本设计变化不大，不影响理解其原理。
“eBPF 是我见过的 Linux 中最神奇的技术，没有之一，已成为 Linux 内核中顶级子模块，从 tcpdump 中用作网络包过滤的经典 cbpf，到成为通用 Linux 内核技术的 eBPF，已经完成华丽蜕变，为应用与神奇的内核打造了一座桥梁，在系统跟踪、观测、性能调优、安全和网络等领域发挥重要的角色。为 Service Mesh 打造了具备 API 感知和安全高效的容器网络方案 Cilium，其底层正是基于 eBPF 技术”
•Cilium 1.13.4•K3s v1.26.6+k3s1•OS•Debian 10, Kernel 4.19.232, arm64•Ubuntu 23.04, Kernel 6.2, x86
近两年BPF技术跃然成为了一项热门技术，在刚刚结束的KubeCon 2020 Europe会议上有7个关于BPF的技术分享， 而在KubeCon 2020 China会议上也已有了3个关于BPF技术的中文分享，分别来自腾讯和PingCAP，涉足网络优化和系统追踪等领域。在中文社区里，包括阿里巴巴、网易、字节跳动等国内第一梯队IT公司也越来越关注BPF这项新技术。本文主要介绍BPF技术发展和应用，以及我是如何学习BPF技术的。
xtables-addons是一款基于国家GeoIP信息来识别网络流量，用于netfilter/iptables的过滤器扩展。其采用了模块化设计理念，并通过内部的xt_geoip模块实现信息过滤。 在你的Linux系统上，可以很方便的自行编译或通过RPM包安装的方式来构建xtables-addons，而无需重新编译内核或是iptables，构建完成后即可立即使用而无需重启服务或系统。
1. Node之间的网络是未知的，有可能是物理服务器直接联网，有可能是虚拟机通过VPC互联，也可以是物理服务器以裸金属方式接入VPC；
朱瑜坚，腾讯云后台工程师，主要负责腾讯云 TKE 容器网络的构建和相关网络组件的设计、开发和维护工作。 张浩，腾讯云高级工程师，主要负责容器网络多个组件的开发和维护，也关注调度、服务网格等领域。 前言 Kubernetes 已经成为容器管理领域的事实标准，而网络系统是 Kubernetes 核心部分，随着越来越多的业务部署在 Kubernetes，对容器网络也提出了一些新的需求 怎么提升网络的可观测性，serverless 类产品该需求尤为突出 怎么尽可能减少容器引入的网络性能损耗 上述需求冲击了 ipt
eBPF 是 Linux Kernel 3.15 中引入的全新设计，将原先的 BPF 发展成一个指令集更复杂、应用范围更广的“内核虚拟机”。
在上一篇文章中，我们简要地解析了 eBPF 内核独立子系统的基本概念、发展历史、架构模型以及优缺点等，具体可参考：Linux eBPF解析。
将 Kubernetes 的 CNI 从其他组件切换为 Cilium, 已经可以有效地提升网络的性能。但是通过对 Cilium 不同模式的切换/功能的启用，可以进一步提升 Cilium 的网络性能。具体调优项包括不限于：
在排查网络问题与深入了解网络协议的工作原理的时候，sre最常使用tcpdump。但是实际上tcpdump只能告诉你网络上传输了哪些包，没有体现为什么这么传输，在排查网络丢包问题的时候是存在一定的局限性的。这时候就需要依赖BCC这个工具来深入地排查网络的问题了。(对于tcpdump与bcc的使用后续可以单独介绍)。
2020 年 9 月，UCloud 上线了 Serverless 容器产品 Cube，它具备了虚拟机级别的安全隔离、轻量化的系统占用、秒级的启动速度，高度自动化的弹性伸缩，以及简洁明了的易用性。结合虚拟节点技术（Virtual Kubelet），Cube 可以和 UCloud 容器托管产品 UK8S 无缝对接，极大地丰富了 Kubernetes 集群的弹性能力。如下图所示，Virtual Node 作为一个虚拟 Node 在 Kubernetes 集群中，每个 Cube 实例被视为 VK 节点上的一个 Pod。
昨天给一台新机器装安装docker，但报错了，解决了一整天也没有头绪。今天起了个大早，破天荒的吃了早饭，然后继续解决。终于找到了问题。
翻译自：Network security for microservices with eBPF
Iptables的recent模块用于限制一段时间内的连接数, 是谨防大量请求攻击的必杀绝技! 善加利用该模块可充分保证服务器安全。
Linux内核在2022年主要发布了5.16-5.19以及6.0和6.1这几个版本，每个版本都为eBPF引入了大量的新特性。本文将对这些新特性进行一点简要的介绍，更详细的资料请参考对应的链接信息。总体而言，eBPF在内核中依然是最活跃的模块之一，它的功能特性也还在高速发展中。某种意义上说，eBPF正朝着一个完备的内核态可编程接口快速进化。
前一阵子把我曾经折腾的那套透明代理方案（细节可以看https://blog.kaaass.net/archives/1446）搬到了NAS上，不过由于众所周知的原因，文章就没在当时发出来。于是虽然都整了3个星期5个月了，现在才整理当时的各种操作。文章主要的操作是安装clash、supervisor、overture、ipt2socks、n2n、透明代理规则。如果不需要透明代理，那仅完成第1项或前2项就可以实现HTTP代理了。而后面配置的主要难点其实是iptables相关组件的安装，由于涉及到了内核组件编译，因此不建议没有编译经验的朋友尝试。另外，由于本篇文章只是记录了编译、配置的方法，所以大概会非常枯燥，还请见谅。
刘旭，腾讯云高级工程师，专注容器云原生领域，有多年大规模 Kubernetes 集群管理及微服务治理经验，现负责腾讯云服务网格 TCM 数据面产品架构设计和研发工作。 引言 目前以 Istio[1] 为代表的服务网格普遍使用 Sidecar 架构，并使用 iptables 将流量劫持到 Sidecar 代理，优点是对应用程序无侵入，但是 Sidecar 代理会增加请求时延和资源占用。 性能一直是用户十分关心的一个点，也是用户评估是否使用服务网格产品的关键因素，腾讯云 TCM 团队一直致力于优化服务网格性能
8月1日凌晨，Istio 1.0发布，已生产就绪！ Cilium社区感谢所有Istio贡献者为此付出的巨大努力。我们很幸运能够参与社区活动，为Istio做出贡献，并帮助一些用户通过Istio和Cilium进行生产部署。如果您有兴趣在深入了解技术细节之前了解Istio + Cilium的用户故事，请考虑阅读HP FitStation团队（最大的Cilium + Istio用户之一）发布的以下Istio博客: Istio是惠普FitStation平台的游戏规则的改变者。
前面介绍了BCC可观测性和BCC网络，但对底层使用的eBPF的介绍相对较少，且官方欠缺对网络方面的介绍。下面对eBPF进行全面介绍。
Tethering技术在移动平台上已经运用的越来越广泛了。它能够把移动设备当做一个接入点，其它的设备能够通过Wi-Fi。USB或是Bluetooth等方式连接到此移动设备。在Android中能够将Wifi设为AP模式作为WLAN接入点。从而与其它设备共享Android的互联网连接。Android成为接入点后。就无法通过WLAN连接使用Android的应用程序訪问互联网，但能够通过其它方式如以太网或移动网络訪问互联网。
本文翻译自 2019 年 DigitalOcean 的工程师 Nate Sweet 在 KubeCon 的一篇分享:
本文翻译自 2019 年 DigitalOcean 的工程师 Nate Sweet 在 KubeCon 的一篇分享: Understanding (and Troubleshooting) the eBPF Datapath in Cilium[1] 。
第一次在Thomas的Twitter上看到要办eBPF技术大会的时候，兴奋不已，作为一个已经学习BPF技术大半年并且还在持续学习中的爱好者，就像粉丝看到偶像要办演唱会一样，迫不及待地要买票入场，一睹偶像们的音容笑貌。这次是Thomas所在的公司Isovalent作为主办方，说是邀请了一众BPF圈内大咖，看到会议日程出来后，直呼简直是神仙阵容，然后我就连续熬了两个通宵，在线看完了这场技术盛宴的直播，下面是我从个人角度出发的对大会的回顾文字。
iptables是一个配置Linux内核防火墙的命令行工具，它基于内核的netfilter机制。新版本的内核（3.13+）也提供了nftables，用于取代iptables
BPF是近年来Linux 系统技术领域一个巨大的创新。作为 Linux 内核的一个关键发展节点，其重要程度不亚于虚拟化、容器、SDN 等技术。
感谢 CNI（容器网络接口），Kubernetes 提供了大量选项来满足您的网络需求。在多年依赖简单的网络解决方案之后，我们面临着对以客户需求为后盾的高级功能的日益增长的需求。Cilium 将我们 K8s 平台中的网络提升到了一个新的水平。
在现代微服务架构中, Service Mesh 作为基础设施层为服务间通信提供了强大支持，其中透明代理是一项关键技术，这篇文章做了一个比较细致的分析，彻底弄懂 TPROXY 透明代理/REDIRECT 的技术细节，涉及到下面这些内容：
描述：iptables是常见于linux系统下的应用层防火墙也就是我们所说的软防火墙,从逻辑上隔离开来有效的避免了恶意攻击,还能进行访问过滤;所以使用防火墙正是强有力的防护措施之一。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
即时通信 IM
实时音视频
