大家好,基于 Kubernetes 的服务网格相信很多的网友都不是很明白,包括也是一样,不过没有关系,接下来就来为大家分享关于基于 Kubernetes 的服务网格和的一些知识点,大家可以关注收藏,免得下次来找不到哦,下面我们开始吧!
Kubernetes解决了容器编排的问题。对于云原生生态来说,剩下的问题是如何让微服务的交付更加高效和弹性。这个问题可以通过Service Mesh技术来解决。
[[311992]]
什么是服务网格?
服务网格是一个网络基础设施层,通过它可以控制和可视化应用程序不同部分之间的通信。当今的应用程序通常以这种方式工作。网络被分为不同的部分,每个部分都是一个服务,每个服务执行特定的业务功能。
服务可能需要从其他服务请求数据才能执行其功能。通常,某些服务会因请求而过载,这就是服务网格派上用场的地方。服务网格通过将请求从一项服务路由到另一项服务来优化不同部分之间的通信。
服务网络组件包括:
控制平面:主要负责代理配置、策略管理和TLS证书权限。控制平面收集所有网络指标,一些服务网格实现还可以跟踪服务。数据平面:由轻量级代理组成。这些代理作为sidecar 进行分发。代理包括Envoy 或NGINX。您可以使用数据平面创建您自己的Kubernetes 服务网格。普通Kubernetes 面临的挑战以及服务网格在这方面的作用
当您使用普通Kubernetes 集群而不是服务网格时,您将遇到以下问题:
服务器之间的安全通讯普通Kubernetes 不会对集群节点之间的流量进行加密,因此服务之间的通信不安全。您可以使用TLS 证书来确保Kubernetes 服务之间的通信安全。
使用TLS 意味着DevOps 团队必须管理和替换证书。此外,您的开发团队必须将TLS 证书集成到每个服务中。
服务网格会对所有网络流量进行加密,从而节省团队时间。服务网格将TLS sidecar 插入到每个Kubernetes Pod 中,并通过控制平面为您替换证书。
服务延迟追踪对单个普通Kubernetes 集群进行故障排除并不总能为您提供问题的根本原因。例如,对于延迟问题,必须分析来自单个服务的数据。但是,该数据可能与与外部服务的通信无关。问题原因可能与查询或前端应用程序有关。
为了解决这个问题,您必须监视代码的性能、分析错误并跟踪应用程序中的每个服务请求。像Istio 这样的服务网格平台提供内置的分布式跟踪,并且不需要对代码进行检测。
服务网格使用代理sidecar 通过出口和入口路由流量。然后sidecar 添加请求头信息,以便于请求跟踪,因此无需分析代码即可获取所有请求的跟踪信息。
有限负载均衡当前端需要处理更多流量时,如何更快地定位流量瓶颈,扩大前端规模?仅靠Kubernetes 无法提供解决方案。另一方面,服务网格提供内置指标,您可以利用这些指标来实现更高级的负载平衡。
不同的Kubernetes服务网格实现
以下列表回顾了当前存在的三种Kubernetes 服务网格产品。该列表清楚地指出了在不同服务网格产品之间进行选择时的重要区别。
IstioIstio 是一个开源服务网格,主要用于管理多个服务代理。 Istio 由Google、IBM 和Lyft 联合开发。最初它仅针对Kubernetes 部署,后来重新设计以支持所有微服务平台。 Istio 默认与Envoy 代理集成。 Istio 更注重可扩展性、性能、可移植性以及维护松散耦合组件的灵活性。
Istio 的控制平面是用Go 语言编写的。运营商使用控制平面来组合不同的管理策略。每个控制平面组件都是针对不同的应用程序而设计的,因此Istio 可以与不同的底层数据平面配对。
Istio 的主要特点包括:
安全功能包括RBAC、身份和密钥管理。高级限流、策略和配额支持HTTP/1.x、HTTP/2、GRPC、WebSockets 和所有TCP 流量故障注入多平台、混合部署LinkerdLinkerd 是一个于2016 年2 月发布的开源服务网格项目。服务网格系列中的首款产品。该平台的服务网格设计非常强大且功能丰富,可以在任何环境中运行。 Linkerd 基于Finagle 库并用Scala 编写。它可以扩展以管理每秒数千个请求。
Linkerd 的包由控制平面和代理数据平面组成。 Linkerd 还有一个由Buoyant 提供支持的商业版本。 Linkerd 的当前版本包括服务网格接口(SMI) 流量API,它可以帮助您自动化金丝雀部署和其他高级交付方法。
Linkerd 的主要功能包括:
支持不同平台,如Kubernetes、Docker、Amazon ECS、DC/OS 使用内置服务发现抽象统一多个系统支持HTTP/1.x、HTTP/2、GRPC、WebSockets 和所有TCP 流量
AWS应用程序网格
AWS 应用程序网格是一种服务网格解决方案,可简化AWS 中的微服务监控和管理,使您能够控制AWS 服务(例如ECS、EKS、EC2)之间的通信和网络流量。此外,应用程序网格使您能够监视、跟踪和查看微服务日志记录。
您可以在应用程序内部署应用程序网格的数据平面,但控制平面由Amazon 管理,用户无法访问它。
本文采摘于网络,不代表本站立场,转载联系作者并注明出处:https://www.iotsj.com//kuaixun/7114.html
用户评论
这个标题终于说到点上了!一直想了解一下如何在Kubernetes里面搭建服务网格。
有17位网友表示赞同!
Kubernetes已经很强大啦,有了微服务的技术更能发挥它作用吧?
有20位网友表示赞同!
感觉学习一下服务网格技术很有必要,对部署和管理微服务应该会有很大帮助。
有19位网友表示赞同!
最近在研究Kubernetes,希望可以了解基于它的服务网格有什么好处。
有16位网友表示赞同!
这篇文章正好能解决我的一块心病,我一直想提升微服务的可靠性和安全性。
有14位网友表示赞同!
Kubernetes微服务架构听起来很复杂,服务网格会不会简单化一些操作?
有12位网友表示赞同!
看了这个标题好激动,终于有人分享kubernetes和微服务的结合啦!
有7位网友表示赞同!
想知道基于Kubernetes的服务网格具体有哪些应用场景?
有16位网友表示赞同!
希望这篇文章能详细介绍服务网格的设计原理,方便我学习。
有11位网友表示赞同!
从标题来看,我觉得这篇文章肯定会讲很多实用的技术细节。
有6位网友表示赞同!
我对微服务的概念越来越感兴趣了,期待这篇关于Kubernetes服务网格的文章。
有5位网友表示赞同!
有了服务网格,会不会更方便监控和管理Kubernetes集群?
有13位网友表示赞同!
不知道服务网格能带来哪些性能提升,很想知道文章的详细介绍。
有11位网友表示赞同!
这篇文章是不是针对有一定Kubernetes基础的人写的?
有6位网友表示赞同!
希望这篇文章能结合一些实例讲解服务网格的使用方法,这样更易于理解。
有6位网友表示赞同!
感觉学习服务网格技术可以让我对微服务架构有更深入的了解。
有7位网友表示赞同!
好久没有看到关于Kubernetes和微服务的深度文章了,期待这篇分享的内容!
有15位网友表示赞同!
这篇文章正好可以帮助我进一步巩固我对Kubernetes的掌握。
有13位网友表示赞同!