这个博客最初是由Ayrat Khayretdinov在CloudOps博客上发布
如你所知,已经有很多关于服务网格的资料,但这是另外一篇。是的!但是为什么会有这篇文章呢?因为我想给你们一些不同的视角,他们希望服务网格在10年前就已经存在,远早于Docker和Kubernetes这样的容器平台的兴起。我并不是说这个视角比其他视角更好或更差,但是由于服务网格是相当复杂的“野兽”,所以我相信多种视角有助于更好地理解它们。
Istio 的 Ambient Mesh(环境网格) 为 Istio 服务网格引入了一个新的无 Sidecar(Sidecar-Less)数据平面选项,其目的是简化应用程序的启动,增加增量采用,并降低 Istio 网格用户的基础设施成本。
继续我的第一篇文章关于服务网格的概念和讨论,接下来我将关注NATS 2.0和服务网格在安全领域的概念。服务网格的安全部分包括端到端加密(相互TLS)、身份验证、授权策略以及服务之间的服务到服务访问控制。有了NATS 2.0和NKeys、JWT以及操作员-帐户-用户安全模型的引入,我相信可以使用NATS,实现更安全的通信基础设施。在这篇文章中,我们将详细讨论这个问题,并将NATS模型与主流服务网格的安全模型进行比较和对比。
服务网格是通过sidecar(边车)代理服务实现,控制平面主要是对sidecar的配置和管理,这包括:
本文介绍在 istio 场景下实现优雅终止时需要重点关注的点,一些容器场景通用的关注点请参考 Kubenretes 最佳实践: 优雅终止 。
Istio 在 1.1 版本之前有个问题: Pod 销毁时,如果进程在退出过程中继续调用其它服务 (比如通知另外的服务进行清理),会调用失败。
微服务架构中,各服务间常有通信交互,以完成复杂业务流程,这给安全性和可扩展性带来挑战。启用双向 TLS(mTLS)可提高安全性,本文将详述 mTLS 的使用入门方法。
使用服务网格并非与 Kubernetes 决裂,而是水到渠成的事情。Kubernetes 的本质是通过声明配置对应用进行生命周期管理,而服务网格的本质是提供应用间的流量和安全性管理,以及可观察性。假如已经使用 Kubernetes 构建了稳定的微服务平台,那么如何设置服务间调用的负载均衡和流量控制?
官方解释:An open platform to connect, secure, control and observe services.
金丝雀发布(Canary):也是一种发布策略,和国内常说的灰度发布是同一类策略。蓝绿部署是准备两套系统,在两套系统之间进行切换,金丝雀策略是只有一套系统,逐渐替换这套系统。
因为nginx是代理层,可以转发请求,istio也实现了流量转发的效果,肯定也有代理层,并且识别了前面创建的虚拟服务中定义的规则。
由于所有来自启用了istio的pod的出站流量在默认情况下都被重定向到它的sidecar代理,所以在集群外部访问url取决于代理的配置。默认情况下,Istio将特使代理配置为传递未知服务请求。尽管这为开始使用Istio提供了一种方便的方法,但是配置更严格的控制通常是可取的。
本文是笔者在学习官方文档、相关博客文章和实践过程中,整理了一些知识概念和自己的思考,主要在探索 lstio 的实际应用场景, Sidecar 原理, Service Mesh 为什么出现、要解决什么问题等,帮助我们思考微服务技术架构的升级和落地的可行性。
现在最火的后端架构无疑是微服务了,微服务将之前的单体应用拆分成了许多独立的服务应用,每个微服务都是独立的,好处自然很多,但是随着应用的越来越大,微服务暴露出来的问题也就随之而来了,微服务越来越多,管理越来越麻烦,特别是要你部署一套新环境的时候,你就能体会到这种痛苦了,随之而来的服务发现、负载均衡、Trace跟踪、流量管理、安全认证等等问题。如果从头到尾完成过一套微服务框架的话,你就会知道这里面涉及到的东西真的非常多。当然随着微服务的不断发展,微服务的生态也不断完善,最近新一代的微服务开发就悄然兴起了,那就是服务网格/Service Mesh。
istio的流量路由规则可以简单地控制不同服务间的流量以及API调用。Istio在服务层面提供了断路器,超时,重试等功能,通过这些功能可以简单地实现A/B测试,金丝雀发布,基于百分比的流量分割等,此外还提供了开箱即用的故障恢复功能,用于增加应用的健壮性,以应对服务故障或网络故障。
听说过服务网格并试用过Istio的人可能都会有以下5个疑问。 (1)为什么Istio 要绑定Kubernetes呢? (2)Kubernetes和服务网格分别在云原生中扮演什么角色? (3)Istio扩展了Kubernetes的哪些方面?解决了哪些问题? (4)Kubernetes、xDS协议(Envoy、MOSN等)与Istio之间是什么关系? (5)到底该不该使用Service Mesh? 本文将带读者梳理清楚 Kubernetes、xDS协议与Istio服务网格之间的内在联系。此外,本文还将介绍Kub
在启用了Istio服务网格的Kubernetes集群中,缺省情况下只能在集群内部访问网格中的服务,要如何才能从外部网络访问这些服务呢? Kubernetes和Istio提供了NodePort,LoadBalancer,Kubernetes Ingress,Istio Gateway等多种外部流量入口的方式,面对这么多种方式,我们在产品部署中应该如何选择?
一个完全开源的服务网格产品,对分布式应用是透明的。Istio 管理服务之间的流量,实施访问政策并汇总遥测数据,而不需要更改应用代码。Istio 以透明的方式对现有分布式应用进行分层,从而简化了部署复杂性。
在 Istio 中,Pilot 是 Istio 控制平面的一个重要组件,它具有以下作用:
最近几年,软件体系结构领域发生了巨大的变化。我们都见证了这一重大转变,就是将大型的整体应用程序和粗粒度应用程序分解为被称为微服务的细粒度部署单元,主要通过同步REST和gRPC接口以及异步事件和消息传递进行通信。这种架构的好处很多,但缺点同样明显。在“旧世界”中曾经很简单的软件开发过程,例如调试,概要分析和性能管理,现在变得复杂了一个数量级。此外,微服务架构也带来了自己独特的挑战。
翻译自 Simplifying Cluster Connectivity with Istio Service Mesh 。
根据云原生产业联盟的 2020 年调查数据显示,Kubernetes 在受访人群的采纳率高达 63%,17% 用户选择 Docker Swarm。
7月17日,在Cloud Native Days China云原生多云多集群专场,eBay软件工程师陈佑雄发表了《eBay基于Istio的应用网关的探索和实践》主题演讲,分享了eBay在多集群,多环境,大规模的场景下,Istio落地实践的探索和实践。
gRPC 是长连接服务,而长连接服务负载不均是通病,因为使用四层负载均衡的话,只能在连接调度层面负载均衡,但不能在请求级别负载均衡。不同连接上的请求数量、网络流量、请求耗时、存活时长等可能都不一样,就容易造成不同 Pod 的负载不一样。而 istio 天然支持 gRPC 负载均衡,即在七层进行负载均衡,可以将不同请求转发到不同后端,从而避免负载不均问题,腾讯云容器服务也对 istio 进行了产品化托管,产品叫 TCM,本文介绍如何使用 TCM 来暴露 gRPC 服务。
Istio 是一个服务网格,它允许在集群中的 pods 和服务之间进行更详细、复杂和可观察的通信。
Istio 在设计之初,主要面向 Kubernetes 当中的服务。但是在实际场景中,依旧有不少服务部署在 VM 上,Istio 想成为 Service Mesh 事实上的标准,毫无疑问需要支持 VM 部署的服务。
涵盖官方文档Traffic Management章节中的egress部分。其中有一小部分问题(已在下文标注)待官方解决。
本系列文章将介绍用户从 Spring Cloud,Dubbo 等传统微服务框架迁移到 Istio 服务网格时的一些经验,以及在使用 Istio 过程中可能遇到的一些常见问题的解决方法。
随着业务的增长,一些传统企业对诸如灰度发布、服务路由、服务熔断、服务限流等服务治理的需求越来越强烈,但他们又不想对业务代码做大量的改造,因而 Service Mesh 成了他们比较好的选择;不幸的是业内比较成熟能落地的 Service Mesh 方案如 Istio 都是基于各种容器平台构建的,而这些传统企业很多没有接入容器平台也不想做容器化改造,这就导致 Service mesh 很难应用于这些传统企业或者一些非容器化的场景。
Istio 在不侵入应用代码的情况下,在应用服务之间创建了具备丰富的路由能力、负载均衡、服务间认证、监控等功能的网络。Istio 的目标是使用最小资源开销来提供这些能力,并能够为负载大量请求的大规模集群提供低延迟服务。
签名我们了解了位于服务网格内部的应用应如何访问网格外部的 HTTP 和 HTTPS 服务,我们学习了如何通过 ServiceEntry 对象配置 Istio 以受控的方式访问外部服务,这种方式实际上是通过 Sidecar 直接调用的外部服务,但是有时候我们可能需要通过专用的 Egress Gateway 服务来调用外部服务,这种方式可以更好的控制对外部服务的访问。
像 Istio 这样的服务网格项目为我们的架构引入了许多功能和优势,包括更安全地管理集群微服务之间的流量、服务发现、请求路由以及服务之间的可靠通信。
Istio项目在公开发布14个月后,今天迎来了1.0发布版本。然而,该服务网格管理平台仍然缺少云计算巨头AWS和Azure的正式支持,而且其他云服务供应商仍然在致力于解决测试和易用性等方面的挑战。
作者 | Kasun Talwatta 译者 | 张卫滨 策划 | marsxxl 本文首先介绍了 Istio 的基础知识,然后结合实际的样例阐释了 Istio 是如何将 sidecar 容器注入到 Kubernetes 集群中,并实现流量拦截的。 本文最初发表于 Solo 官方博客,经原作者 Kasun Talwatta 授权,由 InfoQ 中文站翻译分享。 像 Istio 这样的服务网格项目会为我们的架构引入很多的特性和收益,包括更安全地管理集群中微服务之间的流量、服务发现、请求路由以及
作者赵化冰,腾讯云高级工程师,Istio contributor,ServiceMesher管理委员,热衷于开源、网络和云计算。目前主要从事服务网格的开源和研发工作。 本系列文章将介绍用户从 Spring Cloud,Dubbo 等传统微服务框架迁移到 Istio 服务网格时的一些经验,以及在使用 Istio 过程中可能遇到的一些常见问题的解决方法。 失败的 Eureka 心跳通知 在上一篇文章中,我们介绍了 Headless Service 和普通 Service 的区别。由于 Headless Ser
DNS解析是Kubernetes上任何应用程序基础架构的重要组成部分.当您的应用程序代码尝试访问Kubernetes集群中的另一个服务甚至是Internet上的服务时,它必须先查找与该服务的主机名相对应的IP地址,然后再启动与该服务的连接.此名称查找过程通常称为服务发现。在Kubernetes中,server(无论是kube-dnsCoreDNS还是CoreDNS)将服务的主机名解析为唯一的不可路由的虚拟IP(VIP),如果它是clusterIP类型的服务.在kube-proxy每个节点上这个VIP映射到该服务的一组pod,并随机选择一个pod进行转发。使用服务网格时,sidecar的工作原理就流量转发而言与kube-proxy相同。
作者赵化冰,腾讯云高级工程师,Istio contributor,ServiceMesher管理委员,热衷于开源、网络和云计算。目前主要从事服务网格的开源和研发工作。 本系列文章将介绍用户从 Spring Cloud,Dubbo 等传统微服务框架迁移到 Istio 服务网格时的一些经验,以及在使用 Istio 过程中可能遇到的一些常见问题的解决方法。 什么是『无头服务』? 『无头服务』即 Kubernetes 中的 Headless Service。Service 是 Kubernetes 对后端一组提供
为了实现应用高并发和高可用,企业通常会选择将应用部署在多个地域的多个集群,甚至多云、混合云环境中。在这种情况下,如何在多个集群中部署和管理应用,成为了一个挑战,当然多集群方案也逐步成为了企业应用部署的最佳选择了。同样对多云、混合云、虚拟机等异构基础设施的服务治理也是 Istio 重点支持的场景之一,Istio 从 v1.0 版本开始支持一些多集群功能,并在之后的版本中添加了新功能。
在微服务架构中,应用程序是由多个相互连接的服务组成的,这些服务协同工作以实现所需的业务功能。所以,一个典型的企业级微服务架构如下所示:
在微服务中另外一个重点就是网关,网关理论包含入口网关和出口网关,传统意义上的网关很难做到出口网络控制,但是对于Istio是一件非常轻松的事情(因为所有的出口流量都会经过Istio),入口网关控制解析路由数据流向,出口网关控制对外访问的限制,在Istio中使用了 Ingress和Egress 来实现网关的功能.
当配置一个生产级别的Istio时,需要解决一些问题:如网格是单集群使用,还是跨集群使用?所有的服务会放到一个完全可达的网络中,还是需要网关来连接跨网络的服务?使用一个控制面(可能会跨集群共享一个控制面),还是使用多个控制面来实现高可用(HA)?所有的集群都连接到一个多集群服务网格,还是联合成一个多网格形态。
Istio 1.2.0 已发布,距上一个重要版本 1.1 发布过去刚好三个月。更新的内容主要有以下这些。
🎉嗨,各位技术爱好者!猫头虎博主今天带来了又一期的技术分享。在这期中,我们将聚焦于Kubernetes与Istio的结合,为你呈现如何在Kubernetes上一步步安装并配置Istio服务网格。对于那些正在寻找Kubernetes、Istio及服务网格 相关的热点话题的朋友们,你们找对地方了!🚀
Istio帮助使“服务网格”概念变得更加具体和可访问,随着Istio 1.0的最新发布,我们可以预期人们对它的兴趣会激增。Jasmine Jaksic在InfoQ之前的一篇文章中很好地介绍了Istio和服务网格,因此我想借此机会介绍Istio的一个特定领域,它将为云服务和应用程序的开发人员和运营商带来巨大的价值:安全性
译者按:Istio 于2022年9月7日宣布了一种全新的数据平面模式 “ambient mesh”(ambient 意思是“环境的”,这里指 ambient mesh 使用了环境中的共享代理而不是 sidecar,下文直接使用英文原文),简单地讲就是将数据面的代理从应用 pod 中剥离出来独立部署,以彻底解决 mesh 基础设施和应用部署耦合的问题。该变化是 Istio 自创建以来的第二次大的架构变动,也说明 Istio 社区在持续创新,以解决 service mesh 生产中面临的实际问题。
我们知道 istio 支持 lua 和 wasm 两种扩展能力,lua 作为脚本语言,相信写过游戏或 nginx 插件的都了解他,这里以 Lua 为例子,介绍下 istio 的 sidecar 如何编写一个插件。
在kubernetes环境中,kubernetes Ingress Resource常用来指定应该暴露给集群外部的服务。在一个Istio的服务网格中,最好的办法就是使用不同的配置模型,也就是Istio Gateway。一个gateway允许Istio的功能,比如监控和路由规则去应用到进入集群的流量 。
领取专属 10元无门槛券
手把手带您无忧上云