Linkerd Service Mesh

服务配置文件是一种自定义 Kubernetes 资源 (CRD)， 可以提供有关服务的 Linkerd 附加信息。 特别是，它允许您定义服务的路由列表。 每个路由都使用一个正则表达式来定义哪些路径应该

简介 Server 和 ServerAuthorization 是 Linkerd 中的两种策略资源， 用于控制对 mesh 应用程序的入站访问。 在 linkerd 安装期间，policyContr

从较高的层次上看，Linkerd 由一个控制平面(control plane) 和一个 数据平面(data plane) 组成。 控制平面是一组服务，提供对 Linkerd 整体的控制。 数据平面由在

1. 将您的服务添加到 Linkerd. 为了让您的服务利用 Linkerd，它们还需要通过将 Linkerd 的数据平面代理注入到它们的 pod 中来进行 网格化 。 https://linkerd

Service Mesh Interface 是 Kubernetes 上服务网格的标准接口。 它定义了一组资源，可用于实现该资源的服务网格。 您可以在规范中阅读有关它的更多信息。 https://s

API Gateway(API 网关) API gateway 位于应用程序的前面，旨在解决身份验证和授权、速率限制以及为外部消费者提供公共访问点等业务问题。 相比之下，service mesh 专注

Linkerd 的新服务器授权策略(server authorization policy)功能使您可以细粒度控制允许哪些服务相互通信。这些策略直接建立在 Linkerd 的自动 mTLS 功能提供的

协议检测(Protocol detection)，顾名思义，允许 Linkerd 自动检测 TCP 连接中使用的协议。 Linkerd 的设计原则之一是“just work”，协议检测是 Linker

Flagger Linkerd Traffic Split(流量拆分) 本指南向您展示如何使用 Linkerd 和 Flagger 来自动化金丝雀部署与 A/B 测试。 前提条件 Flagger 需要

在我们 service mesh 之旅的第一部分中，我们讨论了“什么是服务网格以及我们为什么选择 Linkerd2？”。在第二部分，我们将讨论我们面临的问题以及我们如何解决这些问题。

在 Intenseye，我们 follow(跟随) trends(趋势) & hype(最被炒作) 的技术，并在使用时应用最佳实践。 我们在用 Scala、Go、Python 等编写的 Kuberne

一个微服务应用程序，允许用户为他们最喜欢的表情符号(emoji)投票，并跟踪排行榜上收到的投票。愿最好的 emoji 获胜。

Service profiles 为 Linkerd 提供 了关于服务以及如何处理服务请求的附加信息。 当 Linkerd proxy 接收到 HTTP（非 HTTPS）请求时， 会识别该请求的目标服

调试服务网格(service mesh)可能很困难。当某些东西不起作用时， 是代理(proxy)有问题吗？与应用程序(application)？ 与客户端(client)？与底层网络？(underly

GitOps 是一种使用 Git 作为单一事实来源自动管理和交付 Kubernetes 基础设施和应用程序的方法。 它通常利用一些软件代理来检测和协调 Git 中受版本控制的工件与集群中运行的工件之间

本指南将引导您安装和配置 Linkerd，以便两个集群可以与托管在两个集群上的服务通信。 这里有很多活动的部分和概念，因此通读我们的介绍很有价值， 该介绍解释了它在幕后是如何工作的。 在本指南结束时，

发送日志对于网络代理来说是一项昂贵的操作， 默认情况下，Linkerd 数据平面代理配置为仅记录异常事件。 但是，有时增加代理日志的详细程度以帮助诊断代理行为很有用。 令人高兴的是，Linkerd 允

Linkerd 的自动 mTLS 功能 使用一组 TLS 凭据为代理生成 TLS 证书：信任锚、颁发者证书和私钥。 信任锚的有效期有限：365 天（如果由 linkerd install 生成）或 自

Linkerd 控制平面带有自己的最低特权 Pod Security Policy 和相关的 RBAC 资源。 仅当启用 PodSecurityPolicy admission controller