近日我们很高兴的宣布Kmesh发布了v0.4.0版本。感谢社区的贡献者在两个多月的时间里做出了巨大的努力，使得Kmesh取得功能完整度、稳定性、可靠性的多重提升。当前Kmesh相较业界其他方案已经具备显著的资源开销小和低延时等优势，后续我们会继续在核心功能和大规模稳定性等方面重点投入，争取尽快达到GA（生产可用）。
Kmesh背景回顾
尽管服务网格已经在过去几年持续曝光，获得了很大的知名度，但是Sidecar模式在资源开销、数据链路时延等方面对工作负载产生了很大的影响。所以用户在落地选型时，还是比较谨慎。除此之外，Sidecar模式还有一个比较大的缺点是Sidecar与业务容器生命周期完全绑定，无法做到独立升级。
因此Kmesh创新性的提出基于内核的Sidecarless的流量治理方案，将流量治理下沉到内核以解决Sidecar模式用户关心的一些问题。eBPF技术非常适合四层的流量治理，加上可编程内核模块可以进行七层的流量编排。Kmesh最早完全通过eBPF和内核模块进行L4-L7的治理。Kmesh采用随流治理的策略，不会额外增加服务通信过程中的连接跳数，相比Sidecar模式，服务之间的通信连接数从三条减少到一条。
为了丰富七层协议的治理能力，今年Kmesh增加了一种新的治理模式Workload：远端流量治理，利用ebpf将流量转发到kmesh-waypoint，进行高级的七层协议治理，这是一种更加灵活的分层治理模型，能够按需满足不同用户的需求。
Kmesh 0.4版本关键特性解析
IPv6支持
以前Kmesh只支持采用IPv4通信的服务治理，但是当前Kubernetes集群已经默认支持双栈集群，我们不能假设服务只采用IPv4协议通信，因此在0.4版本中我们适配了IPv6的协议特征，支持了IPv6的服务治理。
值得注意的是：即使在IPv4集群中，Java应用在通信时，默认采用IPv6地址族进行通信，所以如果需要采用Kmesh对Java服务进行治理，请一定要升级Kmesh 0.4版本。
IPv6目前只在Workload模式下完整支持。请期待下一个版本中，Kmesh本地模式（流量治理完全下沉内核）也将完全支持IPv6协议族。
细粒度的流量治理
v0.4版本，除了按照Namespace进行服务的纳管以外，我们还支持了按照pod粒度进行流量的纳管治理。一定程度上增加了灵活性，满足了客户只针对一个命名空间下的特定工作负载进行治理的需求。
特定Pod纳管
kubectl label pod <podName> istio.io/dataplane-mode=kmesh -n {namespace}
整个Namespace纳管
kubectl label ns <namespace> istio.io/dataplane-mode=kmesh
Kmesh通过检查Pod及Namespace上面标签，在不同的组件中进行Pod的纳管。
场景一：Pod创建时已经打上了标签，那么kmesh通过Kmesh-cni在容器网络初始化的时候通知kmesh eBPF程序进行纳管，保证工作负载启动之前完成纳管，不会遗漏任何数据包的治理。
场景二：在pod启动之后，再为Pod打上istio.io/dataplane-mode：kmesh标签，那么Kmesh-daemon会监听Pod事件，检查到标签更新后，通知kmesh ebpf程序进行纳管。
场景三：去掉istio.io/dataplane-mode：kmesh标签，允许Pod不被Kmesh纳管。
这种纳管方式更加灵活，也方便了用户在发现服务访问故障之后，快速进行故障隔离，定位定界。
支持集群外部服务治理
在服务网格中，我们可以通过ServiceEntry定义网格外部服务，一般为DNS类型。
apiVersion: networking.istio.io/v1
kind: ServiceEntry
metadata:
name: external-svc
spec:
hosts:
- news.google.com
location: MESH_EXTERNAL
ports:
- number: 80
name: http
protocol: HTTP
resolution: DNS
对于这种服务，控制面为其生成STRICT_DNS类型的Cluster, endpoint地址为域名。
eBPF程序不能进行DNS解析，因此不能根据域名进行DNAT。在Kmesh 0.4版本中，我们新增了DNS解析模块，在用户态首先进行DNS解析，然后重写Cluster将域名替换成IP地址，再刷新给eBPF程序进行DNAT。典型工作原理如图所示:
DNS类型服务的治理，大大拓展了Kmesh服务治理的范畴，由Kubernets集群，扩展到外部服务。
基于eBPF的轻量化可观测
可观测性是服务网格中很重要的基础能力，对于了解数据面通信的状态具有重大意义，可以基于监控进行告警。Kmesh采用了分层观测架构，在治理数据面，内核中存在大量可用于观测的指标数据，Kmesh通过eBPF以极低的代价将这些微观、细粒度指标收集起来，并支持链路级、Pod级等多维度信息采集；并通过ringbuf map上报给kmesh-daemon组件，daemon中根据实时订阅的观测数据，再组织加工成用户可理解的可观测信息。。
当前Kmesh已支持以下四种监控指标，每一种指标都通过标签标识源和目的应用，用户还可以配置Prometheus进行采集。
kmesh_tcp_connections_opened_total kmesh_tcp_connections_closed_total kmesh_tcp_received_bytes_total kmesh_tcp_sent_bytes_total
接下来，社区将继续丰富metrics、access log等观测的采集，并完善与Prometheus、Grafana等观测平台的对接；
在线日志级别调整
# Adjust kmesh-daemon log level (e.g., debug | error | info)
kubectl exec -ti -n kmesh-system kmesh-6ct4h -- kmesh-daemon log --set default:debug# Adjust kmesh eBPF data plane log level
kubectl exec -ti -n kmesh-system kmesh-6ct4h -- kmesh-daemon log --set bpf:debug除了新特性的加入，v0.4版本在可维护性、大规模性能、可测试性等方面也做出了诸多改进：
大规模集群支持
生产环境中，根据部署业务的不同，集群规模可大可小，对于Kmesh来说，大规模集群更能展现Kmesh架构的优势，经过评估，Kmesh需要支持5000服务，10万pod级的集群管理，以满足绝大多数生产使用诉求。
对于远端模式，Kmesh修改了bpf map的创建模式，支持按需申请bpf map中的记录，这样我们可以很容易的支持大规模集群，且不引入冗余的内存开销；
对于本地模式， bpf map更新慢的问题一直困扰着我们，原本刷新一条规则需要几十甚至上百毫秒，0.4版本，我们优化了map-in-map的初始化逻辑，通过空间换时间的策略，消除了map-in-map的刷新耗时，将规则的刷新降低到ms以内，这为后续支持大规模奠定了坚实的基础。
E2E测试
Kmesh当前正处于快速膨胀的成长期，新特性正源源不断的加入到Kmesh中，如何保障社区的整体质量，确保Kmesh平稳有序的向前发展是社区面临的重要挑战；虽然社区已经有UT test做功能防护，但我们还缺少黑盒视角、集群级的功能防护；为此社区引入了E2E测试框架，并将其部署在PR门禁中，这样，每个新PR提交时，就可以及时检查新提交对于已有功能的影响，这对于Kmesh非常有用，当前E2E测试框架已经部署上线，并增加了部分测试用例，后续将不断丰富测试集，也欢迎社区的小伙伴们共同完善Kmesh测试防护网。详细的运行E2E测试请参考https://kmesh.net/en/docs/developer/e2e-guide/
加入社区贡献
我们希望借助在Istio社区长期的积累，始终以开放中立的态度发展Kmesh，打造Sidecarless服务网格业界标杆方案，服务千行百业，促进服务网格健康有序的发展。Kmesh当前正处于高速发展阶段，我们诚邀广大有志之士加入！
参考链接
Kmesh Website：https://kmesh.net/
回复Kmesh进入技术交流群
