了解 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 的所有流量。

相关文章
|
1月前
|
自然语言处理 监控 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)应运而生。本文通过分析服务网格的核心组件、运作机制以及在企业中的实际应用案例,探讨了服务网格在微服务架构中的关键作用及其带来的变革,同时提出了实施过程中面临的挑战和解决策略。
|
5天前
|
缓存 负载均衡 JavaScript
探索微服务架构下的API网关模式
【10月更文挑战第37天】在微服务架构的海洋中,API网关犹如一座灯塔,指引着服务的航向。它不仅是客户端请求的集散地,更是后端微服务的守门人。本文将深入探讨API网关的设计哲学、核心功能以及它在微服务生态中扮演的角色,同时通过实际代码示例,揭示如何实现一个高效、可靠的API网关。
|
4天前
|
Cloud Native 安全 数据安全/隐私保护
云原生架构下的微服务治理与挑战####
随着云计算技术的飞速发展,云原生架构以其高效、灵活、可扩展的特性成为现代企业IT架构的首选。本文聚焦于云原生环境下的微服务治理问题,探讨其在促进业务敏捷性的同时所面临的挑战及应对策略。通过分析微服务拆分、服务间通信、故障隔离与恢复等关键环节,本文旨在为读者提供一个关于如何在云原生环境中有效实施微服务治理的全面视角,助力企业在数字化转型的道路上稳健前行。 ####
|
4天前
|
Dubbo Java 应用服务中间件
服务架构的演进:从单体到微服务的探索之旅
随着企业业务的不断拓展和复杂度的提升,对软件系统架构的要求也日益严苛。传统的架构模式在应对现代业务场景时逐渐暴露出诸多局限性,于是服务架构开启了持续演变之路。从单体架构的简易便捷,到分布式架构的模块化解耦,再到微服务架构的精细化管理,企业对技术的选择变得至关重要,尤其是 Spring Cloud 和 Dubbo 等微服务技术的对比和应用,直接影响着项目的成败。 本篇文章会从服务架构的演进开始分析,探索从单体项目到微服务项目的演变过程。然后也会对目前常见的微服务技术进行对比,找到目前市面上所常用的技术给大家进行讲解。
15 1
服务架构的演进:从单体到微服务的探索之旅
|
3天前
|
Cloud Native 安全 API
云原生架构下的微服务治理策略与实践####
—透过云原生的棱镜,探索微服务架构下的挑战与应对之道 本文旨在探讨云原生环境下,微服务架构所面临的关键挑战及有效的治理策略。随着云计算技术的深入发展,越来越多的企业选择采用云原生架构来构建和部署其应用程序,以期获得更高的灵活性、可扩展性和效率。然而,微服务架构的复杂性也带来了服务发现、负载均衡、故障恢复等一系列治理难题。本文将深入分析这些问题,并提出一套基于云原生技术栈的微服务治理框架,包括服务网格的应用、API网关的集成、以及动态配置管理等关键方面,旨在为企业实现高效、稳定的微服务架构提供参考路径。 ####
23 5