欢迎光临
我们一直在努力

服务网格简介

介绍

服务网格是一个基础结构层,允许您管理应用程序的微服务之间的通信。 随着越来越多的开发人员使用微服务,服务网格已经发展到通过在分布式设置中整合通用管理和管理任务,使工作更轻松,更有效。

将微服务方法应用于应用程序架构涉及将应用程序分解为一组松散耦合的服务。 这种方法提供了一些好处:团队可以使用更广泛的工具和语言来迭代设计并快速扩展。 另一方面,微服务对操作复杂性,数据一致性和安全性提出了新的挑战。

服务网格旨在通过提供对服务如何相互通信的细粒度控制来解决其中一些挑战。 具体来说,它们为开发人员提供了管理方式:

  • 服务发现
  • 路由和流量配置
  • 加密和身份验证/授权
  • 度量和监控

虽然可以像Kubernetes这样的容器协调器本地执行这些任务,但与IstioLinkerd提供的服务网状解决方案相比,这种方法涉及更多的前期决策和管理。 从这个意义上讲,服务网格可以简化和简化在微服务架构中使用通用组件的过程。 在某些情况下,它们甚至可以扩展这些组件的功能。

为什么服务网格?

服务网格旨在解决分布式应用程序体系结构固有的一些挑战。

这些体系结构源于三层应用程序模型,它将应用程序分解为Web层,应用程序层和数据库层。 从规模上看,这种模式对于经历快速增长的组织来说是具有挑战性的。 单片应用程序代码库可能会成为笨重的“泥球” ,对开发和部署构成挑战。

为了解决这个问题,Google,Netflix和Twitter等组织开发了内部“胖客户端”库,以便跨服务标准化运行时操作。 这些库提供负载平衡,断路,路由和遥测 – 服务网格功能的前兆。 但是,它们还对开发人员可以使用的语言施加了限制,并且在更新或更改服务时需要对服务进行更改。

微服务设计避免了其中的一些问题。 您拥有一系列代表应用程序功能的离散管理服务,而不是拥有大型集中式应用程序代码库。 微服务方法的好处包括:

  • 由于团队可以独立工作和部署不同的应用程序功能,因此可以提高开发和部署的灵活性。
  • 更好的CI / CD选项,因为可以独立测试和重新部署各个微服务。
  • 更多语言和工具选项。 开发人员可以使用最好的工具来完成手头的任务,而不是仅限于给定的语言或工具集。
  • 易于扩展。
  • 提高正常运行时间,用户体验和稳定性。

与此同时,微服务也带来了挑战:

  • 分布式系统需要不同的方式来考虑延迟,路由,异步工作流和故障。
  • 微服务设置不一定能满足与单片设置相同的数据一致性要求。
  • 更高的分发水平需要更复杂的操作设计,特别是在服务到服务通信方面。
  • 服务的分配增加了安全漏洞的表面积。

服务网格旨在通过提供对服务通信方式的协调和精细控制来解决这些问题。 在接下来的部分中,我们将了解服务网格如何通过服务发现,路由和内部负载平衡,流量配置,加密,身份验证和授权以及指标和监控来促进服务到服务的通信。 我们将使用Istio的Bookinfo示例应用程序 – 四个微服务一起显示有关特定书籍的信息 – 作为说明服务网格如何工作的具体示例。

服务发现

在分布式框架中,有必要知道如何连接到服务以及它们是否可用。 服务实例位置在网络上动态分配,并且在通过自动扩展,升级和故障创建和销毁容器时,有关它们的信息会不断变化。

从历史上看,在微服务框架中有一些用于进行服务发现的工具。 etcd这样的键值存储与Registrator等其他工具配对,提供服务发现解决方案。 Consul这样的工具通过将键值存储与DNS接口相结合来对此进行迭代,该接口允许用户直接使用其DNS服务器或节点。

采用类似的方法,Kubernetes默认提供基于DNS的服务发现。 有了它,您可以查找服务和服务端口,并使用常见的DNS命名约定进行反向IP查找。 通常,Kubernetes服务的A记录符合以下模式: service . namespace .svc.cluster.local service . namespace .svc.cluster.local 让我们看看它如何在Bookinfo应用程序的上下文中工作。 例如,如果您想从Bookinfo应用程序获得有关details服务的details ,您可以查看Kubernetes仪表板中的相关条目:

详细信息服务在Kubernetes Dash

这将为您提供有关服务名称,命名空间和ClusterIP相关信息,您可以使用这些信息连接服务,即使销毁和重新创建单个容器也是如此。

像Istio这样的服务网络还提供服务发现功能。 为了进行服务发现,Istio依靠Kubernetes API,Istio自己的控制平面,由交通管理组件Pilot管理,以及由Envoy边车代理管理的数据平面之间的通信。 Pilot解释来自Kubernetes API服务器的数据以注册Pod位置的更改。 然后,它将该数据转换为规范的Istio表示,并将其转发到sidecar代理上。

这意味着Istio中的服务发现与平台无关,我们可以通过使用Istio的Grafana插件在Istio的服务仪表板中再次查看details服务来查看:

详情服务Istio Dash

我们的应用程序在Kubernetes集群上运行,因此我们再次可以看到有关details服务的相关DNS信息以及其他性能数据。

在分布式架构中,拥有有关服务的最新,准确且易于查找的信息非常重要。 Kubernetes和像Istio这样的服务网格提供了使用DNS约定获取此信息的方法。

路由和流量配置

管理分布式框架中的流量意味着控制流量到达群集的方式以及流量如何定向到您的服务。 您在配置外部和内部流量方面的控制力和特异性越强,您就可以越多地完成设置。 例如,在您正在使用金丝雀部署,将应用程序迁移到新版本或通过故障注入对特定服务进行压力测试的情况下,能够确定您的服务获得的流量以及来自哪里的流量将是关键你的目标的成功。

Kubernetes提供不同的工具,对象和服务,允许开发人员控制集群的外部流量: kubectl proxyNodePort负载均衡器以及Ingress控制器和资源 kubectl proxyNodePort允许您快速将服务公开给外部流量: kubectl proxy创建一个代理服务器,允许使用HTTP路径访问静态内容,而NodePort在每个节点上公开一个随机分配的端口。 虽然这提供了快速访问,但缺点包括在kubectl proxy的情况下必须运行kubectl作为经过身份验证的用户,并且在kubectl proxy的情况下,端口和节点IP缺乏灵活性。 虽然负载均衡器通过附加到特定服务来优化灵活性,但每个服务都需要自己的负载均衡器,这可能成本很高。

入口资源和入口控制器共同提供了比这些其他选项更大程度的灵活性和可配置性。 通过将入口控制器与入口资源配合使用,可以将外部流量路由到服务并配置内部路由和负载平衡。 要使用Ingress资源,您需要配置服务,Ingress Controller和LoadBalancer以及Ingress资源本身,它将指定服务所需的路由。 目前,Kubernetes支持自己的Nginx控制器 ,但您也可以选择其他选项,由NginxKong和其他人管理。

Istio使用Istio网关VirtualServices迭代Kubernetes控制器/资源模式。 与入口控制器一样,网关定义应如何处理传入流量,指定要使用的暴露端口和协议。 它与VirtualService一起使用,VirtualService定义了网格中服务的路由。 这两种资源都将信息传递给Pilot,然后Pilot将该信息转发给Envoy代理。 虽然它们与Ingress控制器和资源类似,但网关和虚拟服务提供不同级别的流量控制:网关和虚拟服务不是组合开放系统互连(OSI)层和协议 ,而是允许您区分设置中的OSI层。 例如,通过使用VirtualServices,使用应用程序层规范的团队可能会将安全操作团队的问题与不同的层规范分开。 VirtualServices可以分离离散应用程序功能或不同信任域内的工作,并可用于金丝雀测试,逐步推出,A / B测试等。

为了可视化服务之间的关系,您可以使用Istio的Servicegraph附加组件 ,该附加组件使用实时流量数据生成服务之间关系的动态表示。 Bookinfo应用程序可能看起来像这样,没有应用任何自定义路由:

Bookinfo服务图

同样,您可以使用Weave Scope等可视化工具查看给定时间的服务之间的关系。 没有高级路由的Bookinfo应用程序可能如下所示:

编织范围服务地图

在分布式框架中配置应用程序流量时,有许多不同的解决方案 – 从Kubernetes本机选项到像Istio这样的服务网格 – 提供各种选项来确定外部流量如何到达您的应用程序资源以及这些资源如何与一个通信另一个。

加密和身份验证/授权

分布式框架为安全漏洞提供了机会。 微服务架构中的服务不是通过本地内部调用进行通信,而是通过单一设置进行通信,而是通过网络传递信息,包括特权信息。 总的来说,这为攻击创造了更大的表面积。

保护Kubernetes集群涉及一系列程序; 我们将专注于身份验证,授权和加密。 Kubernetes提供以下每种方法的原生方法:

  • 身份验证 :Kubernetes中的API请求与需要进行身份验证的用户或服务帐户相关联。 有几种不同的方法可以管理必要的凭据:静态令牌,引导令牌,X509客户端证书以及OpenID Connect等外部工具。
  • 授权 :Kubernetes具有不同的授权模块,允许您根据角色,属性和其他专用功能等内容确定访问权限。 由于默认情况下拒绝向API服务器发出的所有请求,因此必须通过授权策略定义API请求的每个部分。
  • 加密 :这可以指以下任何一种:最终用户和服务之间的连接,秘密数据,Kubernetes控制平面中的端点,以及工作集群组件和主组件之间的通信。 Kubernetes为每个解决方案提供不同的解决方案:

在Kubernetes中配置单独的安全策略和协议需要管理投资。 像Istio这样的服务网络可以整合其中的一些活动。

Istio旨在自动化一些保护服务的工作。 它的控制平面包括几个处理安全性的组件:

  • Citadel :管理密钥和证书。
  • Pilot :监督身份验证和命名策略,并与Envoy代理共享此信息。
  • 混音器 :管理授权和审核。

例如,当您创建服务时,Citadel会从kube-apiserver接收该信息,并为此服务创建SPIFFE证书和密钥。 然后,它将此信息传输到Pods和Envoy sidecars,以促进服务之间的通信。

您还可以通过在Istio安装期间启用相互TLS来实现某些安全功能。 这些包括用于跨群集和群集间通信的强大服务标识,安全的服务到服务和用户到服务通信,以及可以自动执行密钥和证书创建,分发和轮换的密钥管理系统。

通过迭代Kubernetes如何处理身份验证,授权和加密,像Istio这样的服务网络能够整合和扩展一些推荐的运行安全Kubernetes集群的最佳实践。

度量和监控

分布式环境改变了指标和监控的要求。 监控工具需要具有自适应性,考虑到服务和网络地址的频繁变化,并且全面,允许在服务之间传递信息的数量和类型。

Kubernetes默认包含一些内部监控工具。 这些资源属于其资源度量标准管道 ,可确保群集按预期运行。 cAdvisor组件从各个容器和节点收集网络使用情况,内存和CPU统计信息,并将该信息传递给kubelet; kubelet反过来通过REST API公开该信息。 度量服务器从API获取此信息,然后将其传递给kube-aggregator进行格式化。

您可以使用完整的指标解决方案扩展这些内部工具和监控功能。 使用像Prometheus这样的服务作为度量聚合器,您可以直接在Kubernetes资源度量标准管道上构建。 Prometheus通过位于节点上的自己的代理直接与cAdvisor集成。 其主要聚合服务从节点收集和存储数据,并通过仪表板和API公开它。 如果您选择将主聚合服务与后端存储,日志记录和可视化工具(如InfluxDBGrafanaElasticSearchLogstashKibana等)集成,则还可以使用其他存储和可视化选项。

在像Istio这样的服务网格中,完整度量管道的结构是网格设计的一部分。 在Pod级操作的特使侧面车将指标传达给管理策略和遥测的Mixer 此外,默认情况下启用Prometheus和Grafana服务(但如果您使用Helm安装Istio,则需要在安装期间指定granafa.enabled=true )。 与完整度量标准管道一样,您还可以配置其他服务和部署以进行日志记录和查看选项。

有了这些度量和可视化工具,您就可以在中心位置访问有关服务和工作负载的当前信息。 例如,BookInfo应用程序的全局视图在Istio Grafana仪表板中可能如下所示:

来自Grafana dash的Bookinfo服务

通过复制Kubernetes完整度量标准管道的结构并简化对其某些常用组件的访问,像Istio这样的服务网格简化了使用集群时数据收集和可视化的过程。

结论

微服务架构旨在使应用程序开发和部署快速可靠。 然而,服务间通信的增加改变了某些管理任务的最佳实践。 本文讨论了其中一些任务,如何在Kubernetes本地环境中处理它们,以及如何使用服务网格管理它们 – 在本例中为Istio。

有关此处涉及的一些Kubernetes主题的更多信息,请参阅以下资源:

此外, KubernetesIstio文档中心是查找此处讨论主题的详细信息的好地方。

赞(0) 打赏
未经允许不得转载:老赵部落 » 服务网格简介

评论 抢沙发