• [技术干货] Kmesh v0.4发布!迈向大规模 Sidecarless 服务网格
    近日我们很高兴的宣布 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 基于 Istio 控制面,提供了新的服务网格数据面引擎,详细的架构如下:▍Kmesh v0.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 istio.io/dataplane-mode=kmesh -n {namespace}整个 Namespace 纳管kubectl label ns istio.io/dataplane-mode=kmeshKmesh 通过检查 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/v1kind: ServiceEntrymetadata: 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_totalkmesh_tcp_connections_closed_totalkmesh_tcp_received_bytes_totalkmesh_tcp_sent_bytes_total接下来,社区将继续丰富metrics、access log等观测的采集,并完善与Prometheus、Grafana 等观测平台的对接。在线日志级别调整动态日志级别调整对于故障诊断具有很大的帮助,早期的版本,如果要分析 bpf 数据面的问题,获取更详细的定位日志,你需要修改代码并重新构建镜像,整个过程非常低效;新版本中被彻底改善,我们支持了在线日志级别调整,用户通过 Kmesh 运维命令,可实时调整用户态 Kmesh-daemon 和 bpf 程序的日志级别。使用样例如下:#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 levelkubectl 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测试请参考cid:link_2en/docs/developer/e2e-guide/▍加入社区贡献我们希望借助在 Istio 社区长期的积累,始终以开放中立的态度发展 Kmesh,打造 Sidecarless 服务网格业界标杆方案,服务千行百业,促进服务网格健康有序的发展。Kmesh 当前正处于高速发展阶段,我们诚邀广大有志之士加入!参考链接[1] Kmesh Website:cid:link_2[2] Kmesh Release v0.4.0:cid:link_1[3] 可观测性设计:cid:link_0添加小助手k8s2222回复Kmesh进入技术交流群
  • [问题求助] cloudbursting对devops流程有哪些支持和影响?
     Cloudbursting对devops流程有哪些支持和影响?
  • [问题求助] 华为云Serverless容器服务的可用区有多少个?
     华为云Serverless容器服务的可用区有多少个?
  • [问题求助] 华为云Serverless容器服务CCI是如何实现极致弹性和随取随用的特性的?
     华为云Serverless容器服务CCI是如何实现极致弹性和随取随用的特性的?
  • [问题求助] 云原生FinOps中心是如何实现根据用户需求智能规格推荐,及部署方案?
    云原生FinOps中心是如何实现根据用户需求智能规格推荐,及部署方案?
  • [问题求助] 华为云Serverless容器服务的性能指标是什么?
    华为云Serverless容器服务的性能指标是什么?
  • [问题求助] 哪些工作负载适合标识于Cloud bursting?
    哪些工作负载适合标识于Cloud bursting?
  • [问题求助] CloudBursting解决方案如何保证数据安全?
    CloudBursting解决方案如何保证数据安全?
  • [问题求助] 在从私有环境扩展到公有云时,相当于南北向流量转东西向流量,对IDC与公有云网络有什么要求?
    在从私有环境扩展到公有云时,相当于南北向流量转东西向流量,对IDC与公有云网络有什么要求?
  • [问题求助] CCI Pod的容器实例如何与弹性至CCI实例进行通信?
    CCI Pod的容器实例如何与弹性至CCI实例进行通信?
  • [问题求助] CCI Pod的生命周期管理有哪些具体的操作和策略?
    CCI Pod的生命周期管理有哪些具体的操作和策略?
  • [问题求助] FinOps中心是否支持跨多个云平台的成本分析,还是它只适用于华为云生态系统内的集群?
    FinOps中心是否支持跨多个云平台的成本分析,还是它只适用于华为云生态系统内的集群?
  • [问题求助] CCI在大规模多元容器算力支持下,如何平衡资源分配和性能优化?
    CCI在大规模多元容器算力支持下,如何平衡资源分配和性能优化?CCI的市场占比预计在未来会有何变化?在大规模部署CCI时,企业需要考虑哪些因素以确保系统的稳定性和可靠性?
  • [技术干货] ELB Ingress网关助力云原生应用轻松管理流量
    ▍背景通常情况下,K8s集群的容器网络平面和外部网络是隔离的,外部网络无法直接访问到集群内部的容器业务,如何为容器提供并管理统一的外部流量入口?社区提供的常见方式是使用Nodeport Service,Loadbalancer Service,Ingress等K8s资源对象来暴露集群内部的容器原生应用。Service对象提供了四层负载均衡能力,Ingress对象则提供了面向应用层访问(HTTP/HTTPS等)的七层负载均衡能力。而随着云原生架构在企业内的普遍落地,容器作为云原生微服务应用的载体,需要面对更多挑战,如面对微服务的复杂组网,业务请求在云服务之间转发往往需要做源地址转换而导致流量分发损耗;游戏类、电商抢购类等业务在短时间内会进行频繁扩缩容,必须应对高并发的网络流量;网关入口流量应对互联网的安全攻击,如灰产、异常流量,需提供流量安全防护能力;此外,支持更加复杂的路由规则配置、多种应用层协议(HTTP、HTTPS、GRPC等)、应用蓝绿发布、流量可观测性等七层高级转发能力也逐渐成为了云原生应用的普遍诉求。Ingress Nginx,Ingress Kong,Traefik等开源社区方案虽然提供了丰富的七层流量治理功能, 但对于关键生产业务上云,企业在选择Ingress方案时,除了考虑功能性,还需要充分权衡安全性、可维护性和可靠性等方面的需求,以找到最佳平衡点。专业的云服务提供商提供托管的Ingress解决方案,能够较好的应对这些挑战。华为云CCE服务提供了基于应用型负载均衡ELB(Elastic Load Balance)的全托管免运维的企业级 Ingress 流量治理,让用户轻松应对云原生应用流量管理。▍ELB Ingress 介绍在K8s集群中,容器网络平面通常是独立于集群主机网络的一个隔离的网络平面,工作负载在滚动升级或者重新调度后容器的地址会有变化,这就带来一个问题:如何实现某组Pod的服务发现,并提供固定的外部访问入口?Service和Ingress对象就是K8s中实现集群内外应用统一访问入口的一种机制。K8s社区对集群外部的流量暴露提供了三种方式:Nodeport Service、Loadbalancer Service、Ingress,前两者Service对象主要提供集群四层流量入口,Ingres对象提供七层流量治理能力。两者相互配合,共同实现K8s集群应用的对外访问机制。如下图一所示,客户端通过Ingress管理的负载均衡器,访问Ingress申明的路由,由负载均衡器将流量经过后端Service导入至后端容器。ELB Ingress是华为云CCE服务提供的七层流量治理功能,基于社区标准Ingress API实现,提供高可用、高性能、高安全、多协议的全托管免运维负载均衡能力。同时具备弹性能力,在流量突发时支持快速扩展计算资源,支持千万级并发连接,百万级新建连接,是云原生应用流量治理的理想选择。▍ELB Ingress工作原理ELB Ingress部署于CCE集群的master节点上,与ELB实例对接,可将Ingress申明的容器后端地址、转发策略、路由等信息配置至ELB实例,并且支持动态更新。图二是基于Nodeport中转的ELB Ingress工作流图,CCE Standard集群使用该方案的原理如下:用户为集群创建Ingress资源,在Ingress中配置流量访问规则,如负载均衡器实例、URL路由、SSL证书等监听信息,以及访问的后端Service等,控制器通过标签选择器选中工作负载,将工作负载所在节点和Nodeport端口挂载至负载均衡器实例的后端;Ingress Controller监听到Ingress资源发生变化时,会根据其中定义的流量访问规则,在ELB侧重新配置监听器以及后端服务器路由;用户通过ELB访问应用程序,流量根据ELB中配置的转发策略转发到对应的Node节点,再经过Nodeport二次转发访问到关联的工作负载(Nodeport转发机制参见k8s官方文档说明)。该方案中流量经过节点、IPTables/IPVS规则多次转发,网络性能存在损耗。在大流量场景下,网络转发效率、网络连通速度的挑战尤为突出。为此,我们推出了基于CCE Turbo集群的网络加速方案:容器直接使用VPC网络实现直通容器的ELB Ingress,将原有的“容器网络 + 虚拟机网络“两层模型简化为一层。如图三所示,集群中的Pod IP直接从VPC中分配,支持北向ELB直通容器,外部流量可以不经过节点端口转发直接访问集群中的Pod,达到流量分发零损耗的效果。▍ELB Ingress流量治理核心优势ELB Ingress基于原生Kubernetes Ingress,通过声明式API指定Ingress的路由、对接的后端服务,或者通过Annotation配置监听侧的高级选项,由系统保证最终一致性。ELB Ingress为开发者和运维人员提供了极大的开发灵活性和维护便利性,其核心优势包括:高吞吐、高可用、高弹性ELB Ingress搭配独享型ELB实例,最高支持2千万并发连接;通过完善的健康检查机制,保障业务实时在线,支持多可用区的同城双活容灾,无缝实时切换;弹性规格ELB实例支持根据流量负载自动弹性扩缩实例规格,适用于业务用量波动较大的场景,例如游戏、视频等行业,能满足瞬时流量同时成本最小化。高安全性ELB Ingress提供了端到端的全链路安全策略,如下图四是外部流量经过ELB访问CCE Turbo集群的简单示例:在访问端可配置接入WAF引擎检测并拦截恶意攻击流量,而正常流量转发至后端云服务器。通过Ingress的Annotation配置可轻松为ELB实例配置自定义安全策略,例如设置黑白名单,双向认证等。从ELB转发至后端也支持HTTPS加密信道,进一步增强整体安全性。可移植性完全兼容社区Ingress语义,从开源Nginx Ingress等方案迁移过来仅需改造annotation即可轻松适配。可观测性云监控可以按时间轴查看ELB的网络流量和访问日志,动态分析并告警潜在风险;云审计可以实时监控ELB资源更新日志,针对风险动作实时告警,动态监控云上资源安全;Ingress Controller也支持丰富的普罗监控指标,如接口调用时延,reload次数等。免维护性ELB Ingress组件运行在集群的Master节点,用户无需关注运维问题,组件在集群升级时会自动更新,且对业务无感。▍ELB Ingress流量治理核心功能在社区基础功能之上,华为云ELB Ingress在负载均衡、路由规则、流量控制、安全性和可观测性等方面都有较大增强,满足了更复杂的生产环境需求。下面介绍ELB Ingress流量治理核心功能:灰度发布灰度发布是业界常用的版本升级平滑过渡的一种方式。在版本升级时,先让部分用户使用新版本,其他用户继续使用老版本。待新版本稳定后,再逐步扩大新版本的使用范围,直到所有用户流量都迁移到新版本上。这样可以最大限度地控制新版本发布带来的业务风险,降低故障影响范围,同时支持快速回滚。我们提供了基于Header/Cookie/Weight的灰度发布策略,前两种策略通过将用户分成若干组,在不同的时间段内逐步引入新版本,最终扩大新版本的影响范围;基于Weight的策略则是通过控制新版本的权重,在不同时间段内逐步增加新版本的流量比例,直到完全替代旧版本。高级转发策略随着云原生应用组网的日益复杂,传统的基于路由转发的七层流量治理已经难以满足需求。我们提供的高级转发策略可以很好地解决传统方案面临的局限性:基于请求头的负载均衡:根据客户端请求头的不同值,将请求分配到不同的后端服务器。HTTP重定向到HTTPS:系统自动将HTTP监听器流量转发至HTTPS监听,提升网站安全性,防止内容篡改等。URL重定向和重写:支持将URL永久或临时映射到另一个URL。同时,支持正则表达式匹配和实现不同路径的重写规则。慢启动在应用滚动升级时,ELB Ingress会自动更新负载均衡器后端,并且根据后端容器实例副本数自动设置后端权重。但是,在后端健康检查通过后的上线过程中,可能面临流量突增,导致后端容器的CPU或内存资源瞬间高负荷,从而影响业务稳定性。在开启慢启动模式后,系统可以在指定时间内,逐步将流量导入到目标容器后端。这样可以缓解业务容器突增的流量压力,保护系统免受过度负载的影响,实现优雅过渡。▍小结华为云CCE服务的ELB Ingress基于华为云应用型负载均衡ELB(Elastic Load Balance)提供强大的Ingress流量管理能力,兼容Nginx Ingress,具备处理复杂业务路由和证书自动发现的能力,支持HTTP、HTTPS和GRPC等协议,满足在云原生应用场景下对超强弹性和大规模七层流量处理能力的需求。后续我们还将发布系列文章,详细介绍基于ELB Ingress的流量管理最佳实践,欢迎各位读者继续关注。相关链接:华为云云容器引擎CCE服务路由概述:cid:link_3Ingress官方文档:cid:link_24步快速使用云容器引擎01注册账号,并登录CCE控制台点击注册帐号,并授予IAM用户相应的权限。登录CCE控制台帐号无需授权即可拥有所有权限,由帐号创建的IAM子用户需要授予相应的权限才能使用CCE,具体请参见权限管理。02 创建集群如果您需要创建普通Kubernetes集群,请参见快速创建Kubernetes集群。03 部署工作负载通过镜像或编排模板创建工作负载(应用)。· 创建无状态工作负载(Nginx)· 部署有依赖关系的WordPress和MySQL04 生命周期管理查看部署后工作负载的状态和日志信息,对工作负载进行相应的升级、伸缩和监控等。具体请参见管理工作负载和任务
  • [问题求助] 如何评估"Serverless"的总体拥有成本?
    如何评估"Serverless"的总体拥有成本?
总条数:647 到第
上滑加载中