服务网格云原生可观测性【免费下载链接】linkerd2Ultralight, security-first service mesh for Kubernetes. Main repo for Linkerd 2.x.项目地址https://gitcode.com/gh_mirrors/li/linkerd2点击查看免费下载Linkerd2 是一个面向 Kubernetes 的 ultralight、安全优先的服务网格其代码仓库以 Rust数据面代理、Go控制面与扩展和 React仪表盘 UI三种语言构建。本文以仓库根目录的 BUILD.md 为核心系统讲解如何从源码构建、本地运行 Linkerd2从仓库布局与各组件职责到 k3d 综合开发环境、Go/Web/Rust 各自的开发工作流再到发布镜像、依赖代码生成与 Helm Chart 的修改规范。读完后你将掌握一套可复现的本地构建-部署-调试闭环并能独立维护控制面 Helm Chart 与相关生成代码。仓库布局控制面Go/React与数据面RustLinkerd2 的核心架构由三部分构成用 Rust 编写的高性能数据面代理即每个工作负载 pod 内注入的 sidecar proxy、用 Go 编写的控制面组件及其扩展以及用 React 编写的 Web 仪表盘。仓库根目录下的主要源码模块如下目录职责cli命令行linkerd工具用于查看与驱动控制面controller控制面核心组件Go 微服务controller/api/destination接收proxy实例的请求并返回服务发现信息controller/proxy-injectorPod 创建时触发的 Mutating Webhook将 proxy 容器以 sidecar 形式注入controller/identity提供 CA向 proxy 分发证书使其之间可建立 mTLS 连接vizViz 扩展可视化viz/metrics-api接收 cli、web 等 API 客户端的请求通过 Prometheus 查询返回集群内 proxy 的指标viz/tap/api提供实时的请求流水live pipelineviz/tap/injectorPod 创建时触发的 Mutating Webhook向 proxy 容器注入元数据以启用 tapweb用于查看与驱动控制面的 UI 仪表盘multiclusterMulticluster 扩展多集群multicluster/service-mirror观察目标集群中被标记导出的服务并在本地集群创建对应的镜像服务数据面部分则独立维护linkerd2-proxy仓库存放 Rust 代理源码linkerd2-proxy-api仓库存放数据面 API 的 Protobuf 定义本仓库的 Rust 代码如 policy-controller 与 policy-test位于Cargo.toml/Cargo.lock描述的工作区中。组件间的典型调用关系由 BUILD.md 中的组件图归纳为cli与web都通过metrics-api获取指标、通过tap获取实时请求metrics-api查询prometheustap向proxy发起请求proxy依赖destination做服务发现、依赖identity获取 mTLS 证书destination与identity均读取 Kubernetes APIgrafana与prometheus则负责指标的可视化与存储。开发配置总览针对不同使用场景仓库提供了两套主要开发配置Comprehensive综合配置将全部 Linkerd2 组件构建为 Docker 镜像并部署到 k3d 集群最接近正式发布形态Web专注于 Linkerd2 Dashboard 的迭代开发。下面分别展开。所有 shell 命令默认在仓库根目录执行。Comprehensive 综合配置k3d Docker 镜像 完整安装这套配置会构建所有组件的 Docker 镜像并部署到一个 k3d 集群上流程与官方推荐的生成环境安装方式最接近。前提是你需要先安装 docker buildxbin/_docker.sh 在执行docker buildx时也会做存在性校验。完整命令序列如下# 创建 k3d 集群 bin/k3d cluster create # 构建全部 Docker 镜像 bin/docker-build # 将全部镜像加载进 k3d bin/image-load --k3d # 安装 linkerd先 CRD 后控制面 bin/linkerd install --crds | kubectl apply -f - bin/linkerd install | kubectl apply -f - # 等待核心组件就绪然后安装 linkerd-viz 扩展 bin/linkerd viz install | kubectl apply -f - # 若要对控制面组件使用 linkerd viz tap需要重启它们 # 以便 tap-injector 在它们的 proxy 上启用 tap kubectl -n linkerd rollout restart deploy # 校验 cli 与 server 版本 bin/linkerd version # 校验安装并断言版本与根 tag 一致 bin/linkerd check --expected-version $(bin/root-tag) # 打开 linkerd 仪表盘 bin/linkerd viz dashboard # 安装 demo 应用 emojivoto curl https://run.linkerd.io/emojivoto.yml | bin/linkerd inject - | kubectl apply -f - # 将 demo 前端端口转发到 http://localhost:8080 kubectl -n emojivoto port-forward svc/web-svc 8080:80 # 按 deployment 查看详情 bin/linkerd viz -n emojivoto stat deployments # 查看实时请求流水 bin/linkerd viz -n emojivoto tap deploy voting从源码实现看bin/docker-build 并不是一个单一构建动作而是依次调用bin/docker-build-proxy、bin/docker-build-controller、bin/docker-build-web、bin/docker-build-debug、bin/docker-build-metrics-api、bin/docker-build-tap六个子脚本分别对应数据面代理与控制面/Viz 的关键组件镜像。这意味着你也可以按需只构建某一个组件例如只构建 tap 时用bin/docker-build-tap从而缩短迭代周期。为控制面组件启用分布式追踪控制面组件带有trace-collector标志用于在开发阶段开启分布式追踪。可以通过安装参数全局开启——即同时作用于控制面组件及其 proxylinkerd install \ --set controller.tracing.enabletrue \ --set controller.tracing.collector.endpointyour trace collector endpoint \ | kubectl apply -f -开启后所有组件都会把追踪数据发送到你为集群配置的 collector 端点。在 charts/linkerd-control-plane/values.yaml 中可以看到对应的 Helm 值结构controller.tracing.enabled默认false控制是否启用controller.tracing.collector.endpoint指定 collector 端点且注释明确指出——如果该值未设置但proxy.tracing.collector.endpoint已配置则会复用 proxy 的端点。因此在一个集群里统一配置追踪时只需设置一处端点即可。发布镜像用 DOCKER_REGISTRY 指定目标仓库上面示例把镜像构建并加载进了本地 k3d若要在本地环境之外测试构建出的镜像需要先把镜像发布到外部环境可访问的 registry。bin/docker-build或任意bin/docker-build-*脚本都通过环境变量DOCKER_REGISTRY决定目标仓库默认是官方 registrycr.l5d.io/linkerd见 bin/_docker.sh。用常规方式docker push推送镜像后安装时需把--registry标志的值设为你的 registry与镜像命名保持一致扩展extension没有该标志需改用等价的 Helm 值例如 Viz 使用linkerd viz install --set defaultRegistry...从 bin/_docker.sh 还可以看到更多与发布相关的环境变量DOCKER_TARGET控制目标平台默认取当前宿主os设置为multi-arch时可构建多架构镜像SUPPORTED_ARCHS默认支持linux/amd64,linux/arm64多架构构建必须同时设置DOCKER_PUSH1推送到 registry这是 buildx 多架构构建的约束DOCKER_BUILDER允许指定其他 buildx builder例如基于 Kubernetes 的原生硬件构建驱动。Go 开发工作流用 bin/go-run 替代 go run仓库建议使用 bin/go-run 脚本而非直接go run。该脚本通过go build复用缓存来加速 build/run/debug 循环它先调用bin/root-tag取得当前版本 tag注入-X github.com/linkerd/linkerd2/pkg/version.Version$version的 ldflags再编译并执行目标程序。一般用法是把go run cli/main.go check替换为bin/go-run cli check两者等价于用你当前分支上的代码运行linkerd check。命令形式为bin/go-run path/to/main [args]例如bin/go-run controller/cmd destination -kubeconfig ~/.kube/config。Lint 与格式化用 golangci-lint 分析并检查 Go 代码golangci-lint run所有 Go 源码统一使用goimports格式化项目使用的goimports版本在 go.mod 中指定。要安装一致版本运行go install -modreadonly golang.org/x/tools/cmd/goimports建议将 IDE 或其他开发工具的格式化器配置为goimports。CI 中格式化检查由 bin/fmt 脚本执行justfile 中的go-fmt目标同样调用它go-lint目标则封装golangci-lint run。构建 CLI用 Docker 构建 CLI 二进制的脚本是bin/docker-build-cli-bin它也会被bin/docker-build间接调用默认生成当前宿主 OS/arch 的二进制。要交叉构建其他平台可设置环境变量DOCKER_TARGET其取值对应 cli/Dockerfile 中的最终构建阶段。从该 Dockerfile 可以看到其多阶段结构go-gen阶段预编译慢依赖并复制源码随后build-linux-amd64、build-linux-arm64、build-darwin、build-darwin-arm64、build-windows各阶段用GOOS/GOARCH组合交叉编译出linkerd2-cli-version-os-arch产物linux-amd64与multi-arch两个 scratch 阶段供 CI 提取产物使用。本地开发为追求更快的 edit-build-test 循环可不经过 Docker 容器直接构建bin/build-cli-bin。如果设置环境变量LINKERD_LOCAL_BUILD_CLI1那么bin/docker-build在构建 CLI 那一步也会改用这个方法。本地运行控制面组件Linkerd2 的控制面由若干 Go 微服务组成既可以部署在 Kubernetes 集群中也可以在本地直接运行。用go-run运行单个组件时通过-kubeconfig标志传入有效的 Kubernetes 凭据即可。例如本地运行 destination 服务bin/go-run controller/cmd destination -kubeconfig ~/.kube/config -log-level debug随后可用 controller/script 目录下的destination-client发送测试请求例如bin/go-run controller/script/destination-client -path hello.default.svc.cluster.local:80调试 Tap APIServiceTap APIService 是 Kubernetes 扩展 API server在集群外运行比较困难。最直接的工作流是按上文 Comprehensive 配置把改动构建并加载成容器镜像后在集群内验证只构建该组件可用bin/docker-build-tap。生成 CLI 文档linkerd.io 的 CLI 文档外部站点部分内容由 YAML 生成可通过运行linkerd doc命令重新生成。Web 开发工作流Web 是一个 React 前端 Go 后端的应用使用 webpack 打包静态资源postcss 转换 CSS。以下命令假定已具备可用的 Go 与 Yarn 环境。仓库提供了统一的入口脚本 bin/web其支持子命令包括setup、run、dev、build、port-forward、test。首次配置安装 Yarn 并用它安装 JS 依赖brew install yarn bin/web setup在一个 Kubernetes 集群上安装 LinkerdWeb 仪表盘运行时依赖集群中的控制面与 Viz 组件。独立运行 Webbin/web runWeb 服务会运行在localhost:7777。Webpack dev server 开发模式启动开发服务器bin/web dev该命令会同时启动三个进程可从 bin/web 的dev/run函数确认webGo 进程在 :7777 提供仪表盘webpack-dev-server在 :8080 负责 JS 的重新构建与热重载metrics-api通过kubectl port-forward从 Kubernetes 集群转发到本机 :8085bin/web run会先检查 linkerd-viz 的 metrics-api pod 是否在运行不存在则报错退出。访问 http://localhost:7777 查看效果。注意dev的端口可通过-p参数调整默认DEV_PORT8080。添加 JavaScript 依赖cd web/app yarn add [dep]多语言Translations添加新 localecd web/app yarn lingui add-locale [locales...] # 会为新的 locale 生成 messages.json 文件从既有组件抽取 message keycd web/app yarn lingui extract ... yarn lingui compile # bin/web run 中会自动执行最后还需在以下位置登记新 localeweb/app/package.json 的lingui段web/app/js/index.js 中的make-plural/pluralsimportweb/app/js/index.js 中的langOptions对象。Rust 开发工作流Rust 代理的日常开发在独立的linkerd2-proxy仓库进行本仓库负责将其打包进镜像。Docker 镜像构建bin/docker-build-proxy通过拉取一个预发布的 proxy 二进制来构建镜像bin/docker-build-proxy使用本地构建的 proxy若想部署本地构建的 proxy先在linkerd2-proxy仓库中构建DOCKER_TAGcr.l5d.io/linkerd/proxy:dev make docker然后在本仓库将镜像导入 k3d./bin/k3d image import cr.l5d.io/linkerd/proxy:dev最后让某个 pod 使用你的镜像只需给它加上注解config.linkerd.io/proxy-version: dev另外本仓库自身的 Rust 工作区Cargo.toml、Cargo.lock涵盖了 policy-controller 等组件justfile 中提供了rs-fetch、rs-clippy、rs-test、rs-check-fmt等 Rust 开发/测试目标可作为 Rust 侧辅助参考。依赖与生成代码更新更新 Protobuf 依赖如果你修改了 Protobuf 定义运行bin/protoc-go.sh更新 ServiceProfile 生成代码controller/gen/client 下的 ServiceProfile client 代码由 bin/update-codegen.sh 生成它依赖 K8s 的code-generator而该工具尚未支持 Go Modules。要重新生成这段代码需要把仓库检出到GOPATH中go get -u github.com/linkerd/linkerd2 cd $GOPATH/src/github.com/linkerd/linkerd2 bin/update-codegen.shLinkerd Helm Chart 工程实践Chart 组成与安装Linkerd 控制面 Chart 位于 charts/linkerd-control-plane其依赖的 CRD 在 charts/linkerd-crds Chart 中charts/patch Chart 包含 Linkerd proxy 的规格供 proxy-injector 注入 proxy 容器使用。这三个 Chart 都依赖 charts/partials 子 Chart。注意charts/linkerd-control-plane/values.yaml 中含有一个占位符linkerdVersionValue继续操作前需要替换为合适的字符串如edge-20.2.2。开发期间请使用 bin/helm 包装脚本调用 Helm 命令以确保与 Linkerd CI 系统使用相同的 Helm 版本。例如bin/helm install linkerd-crds -n linkerd --create-namespace charts/linkerd-crds bin/helm install linkerd-control-plane -n linkerd \ --set-file identityTrustAnchorsPEMca.crt \ --set-file identity.issuer.tls.crtPEMissuer.crt \ --set-file identity.issuer.tls.keyPEMissuer.key \ charts/linkerd-control-plane使用 Chart 前还需要提供或自行生成证书identity 的信任锚与 issuer 证书对生成方式可参考官方 Generate Certificates 任务说明。从 charts/linkerd-control-plane/values.yaml 可以看到identityTrustAnchorsPEM是安装时必须提供的信任根证书ECDSAidentityTrustDomain默认取集群的clusterDomain。扩展的 Helm Charts各扩展自带独立的 ChartVizviz/charts/linkerd-vizMulticlustermulticluster/charts/linkerd-multicluster修改 Chart 模板每当你修改 charts/linkerd-control-plane/templates 下的文件或其依赖 charts/partials 时都要运行 bin/helm-build它会刷新依赖并 lint 模板。为 values.yaml 添加注释以驱动 helm-docs为了让 helm-docs 正确生成values.yaml的文档每个值都需要一条描述性注释有两种写法在值上方直接注释双横线会自动将注释关联到该值# -- This is a really nice value显式写出值名# global.MyNiceValue -- I really like this value仓库中的 values.yaml 即遵循此约定例如 charts/linkerd-control-plane/values.yaml 中controller.tracing.collector.endpoint的注释就解释了其在未设置时复用 proxy 端点的行为enableEndpointSlices、enablePodAntiAffinity、enablePprof、enablePodDisruptionBudget等值也都有# --形式的注释。Markdown 模板对于可能没有合适位置放在values.yaml中的额外数据可以修改每个 Chart 对应的README.md.gotmpl文件。该模板支持标准 Markdown 语法以及 Go 模板函数helm-docs 项目提供更多信息。延伸从源码测试关于从源码运行测试的完整指引请参阅仓库根目录的 TEST.md 测试指南其中涵盖了 Go 单测go test -cover -race ./...、JS 测试yarn/jest、Shell 测试以及集成测试含 golden 文件更新等。它与本 BUILD.md 一起构成了 Linkerd2 从构建、运行到测试验证的完整本地开发闭环。此外justfile 中的go-test、policy-test、k3d-create、linkerd-install等目标也为容器化 CI 场景下的构建与测试提供了等效的自动化入口。赞分享服务网格云原生可观测性【免费下载链接】linkerd2Ultralight, security-first service mesh for Kubernetes. Main repo for Linkerd 2.x.项目地址https://gitcode.com/gh_mirrors/li/linkerd2点击查看免费下载相关推荐Apache APISIX 从源码构建与本地开发环境搭建实战指南Apache APISIX 从源码构建与本地开发环境搭建实战指南 本指南面向希望搭建 APISIX 本地开发环境或参与 APISIX 代码贡献的开发者完整覆盖后端微服务云原生Helm 源码仓库开发指南从 AGENTS.md 读懂代码结构、构建测试与贡献规范Helm 源码仓库开发指南从 AGENTS.md 读懂代码结构、构建测试与贡献规范 Helm 是使用 Go 编写的 Kubernetes 包管理器它通过 C云原生容器编排CLI运维Budibase 源码仓库开发全指南Lerna Monorepo 架构、测试规范与本地开发环境搭建Budibase 源码仓库开发全指南Lerna Monorepo 架构、测试规范与本地开发环境搭建 本篇技术指南以 Budibase 仓库根目录的 CLAUD低代码人工智能AI Agent工作流自动化后端前端创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考