了解 Linkerd Service Mesh 架构

简介: 了解 Linkerd Service Mesh 架构

从较高的层次上看,Linkerd 由一个控制平面(control plane) 和一个 数据平面(data plane) 组成。


控制平面是一组服务,提供对 Linkerd 整体的控制。

数据平面由在每个服务实例“旁边”运行的透明微代理(micro-proxies)组成,作为 Pod 中的 sidecar。这些代理会自动处理进出服务的所有 TCP 流量,并与控制平面进行通信以进行配置。


Linkerd 还提供了一个 CLI,可用于与控制平面数据平面进行交互。


系列



中文手册(https://hacker-linner.com)


CLI



Linkerd CLI 通常在集群外部运行(例如在您的本地机器上),用于与 Linkerd 交互。


控制平面(control plane)



Linkerd 控制平面是一组在专用 Kubernetes 命名空间(默认为 linkerd)中运行的服务。控制平面有几个组件,列举如下。


目标服务(destination)


数据平面代理使用 destination 服务来确定其行为的各个方面。它用于获取服务发现信息(即发送特定请求的位置和另一端预期的 TLS 身份);获取有关允许哪些类型的请求的策略信息;获取用于通知每条路由指标重试超时的服务配置文件信息;和更多其它有用信息。


身份服务(identity)


identity 服务充当 TLS 证书颁发机构, 接受来自代理的 CSR 并返回签名证书。这些证书在代理初始化时颁发,用于代理到代理连接以实现 mTLS


代理注入器(proxy injector)


proxy injector 是一个 Kubernetes admission controller,它在每次创建 pod 时接收一个 webhook 请求。此 injector 检查特定于 Linkerdannotationlinkerd.io/inject: enabled)的资源。当该 annotation 存在时,injector 会改变 pod 的规范, 并将 proxy-initlinkerd-proxy 容器以及相关的启动时间配置添加到 pod 中。


数据平面(data plane)



Linkerd 数据平面包含超轻型微代理,这些微代理部署为应用程序 Pod 内的 sidecar 容器。由于由 linkerd-init(或者,由 LinkerdCNI 插件)制定的 iptables 规则, 这些代理透明地拦截进出每个 podTCP 连接。


代理(Linkerd2-proxy)


Linkerd2-proxy 是一个用 Rust 编写的超轻、透明的微代理Linkerd2-proxy 专为 service mesh 用例而设计,并非设计为通用代理。

代理的功能包括:


  • HTTPHTTP/2 和任意 TCP 协议的透明、零配置代理。
  • HTTPTCP 流量的自动 Prometheus 指标导出。
  • 透明、零配置的 WebSocket 代理。
  • 自动、延迟感知、第 7 层负载平衡。
  • HTTP 流量的自动第 4 层负载平衡。
  • 自动 TLS
  • 按需诊断 Tap API
  • 还有更多。

代理支持通过 DNS 和目标 gRPC API 进行服务发现。


您可以在此处阅读有关这些微代理的更多信息:

  • 为什么 Linkerd 不使用 Envoy
  • Linkerd 最先进的 Rust 代理 Linkerd2-proxy


Linkerd init 容器


linkerd-init 容器作为 Kubernetes init 容器 添加到每个网格 pod 中,该容器在任何其他容器启动之前运行。它使用 iptables 通过代理将所有 TCP 流量,进出 Pod 的所有流量。

相关文章
|
18天前
|
自然语言处理 监控 Cloud Native
探索微服务架构中的服务网格Service Mesh
【10月更文挑战第7天】服务网格(Service Mesh)是微服务架构中的关键组件,通过在每个服务实例旁部署Sidecar代理,实现服务间通信的管理、监控和安全增强。本文介绍了服务网格的基本概念、核心组件、优势及实施步骤,探讨了其在现代开发中的应用,并提供了实战技巧。
|
3月前
|
运维 负载均衡 监控
探索微服务架构下的服务网格(Service Mesh)实践之路
【8月更文挑战第30天】 在当今日益复杂的分布式系统中,微服务架构已成为众多企业解决系统扩展与维护难题的利器。然而,随着服务的不断增多和网络交互的复杂性提升,传统的微服务管理方式开始显得力不从心。服务网格(Service Mesh)作为一种新兴的解决方案,旨在通过提供应用层的网络基础设施来简化服务间通讯,并增强系统的可观察性和安全性。本文将分享我在采用服务网格技术过程中的经验与思考,探讨如何在现代云原生环境中有效地实施服务网格,以及它给开发和运维带来的变革。
|
4月前
|
负载均衡 监控 Kubernetes
Service Mesh 是一种用于处理服务间通信的基础设施层,它通常与微服务架构一起使用,以提供诸如服务发现、负载均衡、熔断、监控、追踪和安全性等功能。
Service Mesh 是一种用于处理服务间通信的基础设施层,它通常与微服务架构一起使用,以提供诸如服务发现、负载均衡、熔断、监控、追踪和安全性等功能。
|
4月前
|
消息中间件 监控 中间件
业务系统架构实践问题之Service间网状调用如何解决
业务系统架构实践问题之Service间网状调用如何解决
|
6月前
|
监控 负载均衡 数据安全/隐私保护
探索微服务架构下的服务网格(Service Mesh)实践
【5月更文挑战第6天】 在现代软件工程的复杂多变的开发环境中,微服务架构已成为构建、部署和扩展应用的一种流行方式。随着微服务架构的普及,服务网格(Service Mesh)作为一种新兴技术范式,旨在提供一种透明且高效的方式来管理微服务间的通讯。本文将深入探讨服务网格的核心概念、它在微服务架构中的作用以及如何在实际项目中落地实施服务网格。通过剖析服务网格的关键组件及其与现有系统的协同工作方式,我们揭示了服务网格提高系统可观察性、安全性和可操作性的内在机制。此外,文章还将分享一些实践中的挑战和应对策略,为开发者和企业决策者提供实用的参考。
|
6月前
|
运维 监控 负载均衡
探索微服务架构下的服务网格(Service Mesh)实践之路
【4月更文挑战第30天】 在现代云计算的大背景下,微服务架构以其灵活性和可扩展性成为众多企业转型的首选。然而,随着服务的激增和网络交互的复杂化,传统的服务通信模式已无法满足需求,服务网格(Service Mesh)应运而生。本文通过分析服务网格的核心组件、运作机制以及在企业中的实际应用案例,探讨了服务网格在微服务架构中的关键作用及其带来的变革,同时提出了实施过程中面临的挑战和解决策略。
|
21天前
|
缓存 监控 API
探索微服务架构中的API网关模式
【10月更文挑战第5天】随着微服务架构的兴起,企业纷纷采用这一模式构建复杂应用。在这种架构下,应用被拆分成若干小型、独立的服务,每个服务围绕特定业务功能构建并通过HTTP协议协作。随着服务数量增加,统一管理这些服务间的交互变得至关重要。API网关作为微服务架构的关键组件,承担起路由请求、聚合数据、处理认证与授权等功能。本文通过一个在线零售平台的具体案例,探讨API网关的优势及其实现细节,展示其在简化客户端集成、提升安全性和性能方面的关键作用。
62 2
|
25天前
|
存储 缓存 监控
探索微服务架构中的API网关模式
【10月更文挑战第1天】探索微服务架构中的API网关模式
76 2
|
2月前
|
安全 应用服务中间件 API
微服务分布式系统架构之zookeeper与dubbo-2
微服务分布式系统架构之zookeeper与dubbo-2
|
4天前
|
监控 Cloud Native Java
云原生架构下微服务治理策略与实践####
【10月更文挑战第20天】 本文深入探讨了云原生环境下微服务架构的治理策略,通过分析当前技术趋势与挑战,提出了一系列高效、可扩展的微服务治理最佳实践方案。不同于传统摘要概述内容要点,本部分直接聚焦于治理核心——如何在动态多变的分布式系统中实现服务的自动发现、配置管理、流量控制及故障恢复,旨在为开发者提供一套系统性的方法论,助力企业在云端构建更加健壮、灵活的应用程序。 ####
44 10

热门文章

最新文章