云原生后端前端【免费下载链接】kubeappsA web-based UI for deploying and managing applications in Kubernetes clusters项目地址https://gitcode.com/gh_mirrors/ku/kubeapps点击查看免费下载Kubeapps 是一个面向 Kubernetes 集群的应用部署与管理 Web UI其架构由集群内的多个可独立演进的服务组件协同构成。本文以 architecture.md 为骨架结合仓库内各组件源码与 Helm 部署模板逐一拆解 dashboard、kubeapps-apis、apprepository-controller、asset-syncer、pinniped-proxy、oci-catalog 六大组件的职责边界、关键实现与协作流程并重点深入讲解 kubeapps-apis 的插件化 gRPC 设计与一个 UI 统一管理多种打包格式的实现原理。读完本文你将理解 Kubeapps 各组件之间的数据流与调用链掌握其可插拔、可扩展的架构设计思想。架构总览六大组件各司其职Kubeapps 采用 Kubernetes 原生in-cluster架构所有服务组件都以 Deployment / Job / CronJob 的形式运行在集群内部通过 Helm Chartchart/kubeapps/Chart.yaml统一部署。整体由以下组件构成组件形态核心职责dashboard集群内 Web 服务提供浏览与点击式browse and click的安装/管理界面kubeapps-apisgRPC/HTTP API 服务插件化 API 网关统一对接不同打包格式apprepository-controllerKubernetes Controller监听 AppRepository CRD调度仓库同步任务asset-syncerJob/CronJob 工具扫描仓库并填充数据库中的包元数据pinniped-proxy可选代理服务将 Bearer Token 换取 x509 短期客户端证书oci-catalog可选 gRPC 微服务为 OCI 注册表提供目录catalog查询能力其中 asset-syncer 的元数据最终由 kubeapps-apis 的 Helm 插件对外提供从而形成仓库管理 → 元数据同步 → 统一 API → 前端展示的完整链路。dashboard基于 React 的集群内前端dashboard 是整个 Kubeapps 的核心交互入口位于 dashboard/ 目录使用 JavaScript 编写、基于 React 库开发为用户提供安装 Helm 图表打包的 Kubernetes 应用以及后续管理的浏览点击式体验。它既消费 kubeapps-apis 的 API 来获取包目录与安装信息也借助 resources 插件查询已安装应用关联的 Kubernetes 资源详见后文 kubeapps-apis 部分。从部署模板看dashboard 以独立 Deployment Service 运行chart/kubeapps/templates/dashboard/并通过 dashboard/src/shared/KubeappsGrpcClient.ts 等客户端封装调用 gRPC-Web 接口。其开发环境搭建Telepresence 代理、yarn install、yarn run start等详见 Kubeapps Dashboard 开发者指南。kubeapps-apis插件化、可聚合的 gRPC API 服务kubeapps-apis 是整套架构中技术含量最高的组件位于 cmd/kubeapps-apis/。它提供一套可插拔pluggable、基于 gRPC的 API 服务使 Kubeapps UI或其他客户端能以一致、可扩展的方式与不同的 Kubernetes 打包格式交互。其完整设计背景可参考 Kubeapps APIs 开发者文档。技术栈gRPC grpc-gateway Connect服务采用标准的 gRPC/protobuf 技术栈定义 API并用 buf 做 lint 与 IDL 校验grpc-gateway提供 RESTful JSON 版本的 API——虽然 Kubeapps 客户端本身不用它但保证了 API 对非 gRPC 用户可访问Connect gRPC-Web用于生成 TypeScript gRPC 客户端并在后端把 gRPC-Web 请求翻译成普通 gRPC 调用无需 Envoy 之类的较重翻译层多路复用在同一端口上同时服务 gRPC、gRPC-Web并把 Gateway 的 JSON HTTP 请求也复用在同一端口。这一设计在 cmd/kubeapps-apis/server/server.go 中可见服务以h2c.NewHandler启动 HTTP/2并把 plugins、packages、repositories 三个核心服务同时注册到 gRPC 与 HTTP mux 上最后将所有未匹配请求交给 Gateway。默认监听端口为50051--port见 cmd/kubeapps-apis/cmd/root.go。插件机制Go 插件动态加载一个 kubeapps-apis 插件本质上是一个标准 Go plugin.so文件必须导出两个特定签名的函数func RegisterWithGRPCServer(GRPCPluginRegistrationOptions) (interface{}, error) func RegisterHTTPHandlerFromEndpoint(context.Context, *runtime.ServeMux, string, []grpc.DialOption) error服务启动时plugins.go 会扫描--plugin-dir指定的目录可多次指定下的全部.so文件依次plugin.Open打开并调用每个插件的RegisterWithGRPCServer注册到 gRPC API同时调用RegisterHTTPHandlerFromEndpoint让同一功能经 grpc-gateway 暴露为 HTTP。插件注册时还会调用GetPluginDetail获取插件名称与版本信息。仓库内已内置以下打包插件源码均在 cmd/kubeapps-apis/plugins/helm/packages/v1alpha1提供 Helm 目录浏览与 Helm 包安装能力fluxv2/packages/v1alpha1对接 Flux 的 HelmRepositorykapp_controller/packages/v1alpha1对接 Carvelkapp-controller的 PackageRepositoryresources/v1alpha1可选的 Kubernetes 资源访问插件例如返回已安装包相关的资源要求请求者具备相应 RBAC。核心 packages 接口与聚合查询为了让不同打包格式对 UI 呈现一致项目定义了核心包 APIcore.packages.v1alpha1任何插件都可以选择实现该接口——它包含查询与安装 Kubernetes 包的通用方法例如GetAvailablePackages、CreateInstalledPackage。完整接口定义位于 cmd/kubeapps-apis/proto/kubeappsapis/core/packages/v1alpha1/packages.proto。例如GetAvailablePackageDetailRPC 定义为rpc GetAvailablePackageDetail(GetAvailablePackageDetailRequest) returns (GetAvailablePackageDetailResponse) { option (google.api.http) { get: /core/packages/v1alpha1/availablepackages/... }; }其请求结构message GetAvailablePackageDetailRequest { // 唯一标识一个可用包所需的信息 AvailablePackageReference available_package_ref 1; // 可选的指定版本或版本引用。 // 默认返回最新版本或匹配引用的最新版本。 string pkg_version 2; }插件判定遵循 Go 接口惯例只要插件服务器实现了 core packages 接口的全部方法即被认定满足接口。kubeapps-apis 的插件服务器在完成注册后会遍历已注册插件找出满足 core packages 接口的实现并返回切片// GetPluginsSatisfyingInterface 返回满足特定接口的已注册插件。 // 目前用于返回满足 core.packaging 接口的插件供核心 packaging server 使用。 func (s *pluginsServer) GetPluginsSatisfyingInterface(targetInterface reflect.Type) []PluginWithServer { satisfiedPlugins : []PluginWithServer{} for _, pluginSrv : range s.pluginsWithServers { // 下面的接口实现检查正是 grpc-go 自身所做的参见 // https://github.com/grpc/grpc-go/blob/v1.38.0/server.go#L621 serverType : reflect.TypeOf(pluginSrv.Server) if serverType.Implements(targetInterface) { satisfiedPlugins append(satisfiedPlugins, pluginSrv) } } return satisfiedPlugins }所有插件都会注册各自的 gRPC 服务器、可独立查询但拥有统一的 core packages 接口使得 Kubeapps dashboard 可以用单一客户端呈现统一的应用目录——无论包来自标准 Helm 仓库、Flux 的 HelmRepository还是集群内的 Carvel 包资源。core packages 实现还扮演聚合网关角色查询类方法如GetAvailablePackageSummaries、GetInstalledPackageSummaries会并发扇出fan-in到各打包插件并合并结果。以GetAvailablePackageDetail为例packages.go// GetAvailablePackageDetail 基于请求返回包详情。 func (s packagesServer) GetAvailablePackageDetail(ctx context.Context, request *packages.GetAvailablePackageDetailRequest) (*packages.GetAvailablePackageDetailResponse, error) { ... // 检索与请求的插件名匹配的插件服务器 pluginWithServer : s.getPluginWithServer(request.AvailablePackageRef.Plugin) ... // 从请求的插件获取响应 response, err : pluginWithServer.server.GetAvailablePackageDetail(ctx, request) ... // 构建响应 return packages.GetAvailablePackageDetailResponse{ AvailablePackageDetail: response.AvailablePackageDetail, }, nil }需要说明的是满足 core packages 接口的插件并不被限制于仅实现这些方法——类似 Go 接口插件可以自由扩展额外功能。Helm 插件正是利用这一点额外提供了回滚rollback已安装包的能力该能力对 Carvel/Flux 并非必需且只在 Helm 专属的 gRPC 客户端上可用。认证与授权认证层面沿用 OIDC 标准到达 kubeapps-apis 的每个请求都必须携带用户令牌令牌会被随请求转发给 Kubernetes API确保所有对 API server 的访问都受用户自身 RBAC 约束。每个插件在注册时会收到一个core.KubernetesConfigGetter函数负责为指定请求上下文创建所需的 Kubernetes 配置插件无需关心细节。其实现plugins.go从请求 header 提取Authorization: Bearer xxx令牌再结合集群配置构造rest.Config并可应用--kube-api-qps/--kube-api-burst限流参数。需要注意的是仅在 demo 环境中支持使用 ServiceAccount Token 代替合法 OIDCid_token完成认证。已知限制CaveatsServiceAccount 字段Flux 与 Carvel 安装包时需要选择关联的 ServiceAccount。由于尚未在创建包时提供额外的 schema/字段数据计划在未来版本补充当前实现是根据插件名来决定 ServiceAccount 字段流式 RPCcore packages 接口上未能加入任何流式 gRPC 调用。原因在于grpc-go会为流式响应生成包专属类型导致一个包对某个流式 RPC 的实现无法与另一个包如 core 接口的实现匹配。虽然并非无法绕过但目前流式响应仅用于其他非 packages 插件——例如 resources 插件上报已安装包相关的 Kubernetes 资源变化。resources 插件不暴露 Kubernetes API server 也能访问资源Kubeapps 自诞生起就要求 dashboard 直连 Kubernetes API 以查询已安装包相关资源、创建 Secret、判断用户是否已认证因此前端服务长期内置了一个到 Kubernetes API 的反向代理。新 kubeapps-apis 服务的重要目标之一就是移除这个反向代理。实现方式是创建resources/v1alpha1插件提供 UI 所需的一系列资源相关函数。例如它提供GetResources方法仅流式返回或子集某个已安装包对应的资源实现见 cmd/kubeapps-apis/plugins/resources/v1alpha1/server.gomessage GetResourcesRequest { // InstalledPackageRef // // 已安装包引用其资源将被获取。 kubeappsapis.core.packages.v1alpha1.InstalledPackageReference installed_package_ref 1; // ResourceRefs // // 要获取或监听的资源引用。 // 若为空获取资源时返回该已安装包的全部资源。 // 监听资源时必须填充以避免不必要地监听所有资源。 repeated kubeappsapis.core.packages.v1alpha1.ResourceRef resource_refs 2; // Watch // // 为 true 时流会保持打开并从 Kubernetes API server // 收到事件时持续发送更新后的资源。 bool watch 3; }这使得客户端如 Kubeapps UI可以单次请求监听某个已安装包引用的资源集合任何资源变化都会在流上返回更新——相比之前浏览器向 Kubernetes API 逐个资源发 watch 请求要高效得多。当然插件内部仍需对每个资源向 Kubernetes API 单独发起 watch但在插件中做这件事远好于在浏览器里做浏览器有连接数限制。插件内部把多个资源更新通道合并为单一 watcher// 否则若请求监听资源则将 watchers 合并 // 为单个 resourceWatcher 并随数据到达持续流式发送。 resourceWatcher : mergeWatchers(watchers) for e : range resourceWatcher.ResultChan() { sendResourceData(e.ResourceRef, e.Object, stream) }合并逻辑受 Go 博客的 fan-in 管道示例启发。resources 插件不关心底层打包系统只需知道使用了哪个打包插件以校验已安装包的资源引用因此 dashboard 展示已安装包资源时无需关心背后的打包系统类型。快速验证 kubeapps-apis在集群内可通过端口转发验证服务详见 kubeapps-apis 开发者文档kubectl -n kubeapps port-forward svc/kubeapps-internal-kubeappsapis 8080:8080查看已配置插件HTTP 方式curl -s http://localhost:8080/apis/core/plugins/v1alpha1/configured-plugins | jq . { plugins: [ { name: fluxv2.packages, version: v1alpha1 }, { name: kapp_controller.packages, version: v1alpha1 }, { name: resources, version: v1alpha1 } ] }同一端口也可用 grpcurl 走 gRPC单端口多路复用grpcurl -plaintext localhost:8080 kubeappsapis.core.plugins.v1alpha1.PluginsService.GetConfiguredPlugins其余端点如打包端点需要认证令牌可创建带必要 RBAC 的 ServiceAccount 使用其 Bearer Token或从浏览器复制 JWT id_token。例如查询 flux 插件的可用包export TOKENBearer eyJhbGciO... curl -s http://localhost:8080/plugins/fluxv2/packages/v1alpha1/availablepackages -H Authorization: $TOKEN | jq .调用 core API 则能聚合所有已配置插件下的已安装包grpcurl -plaintext -d {context: {cluster: default, namespace: kubeapps-user-namespace}} \ -H Authorization: $TOKEN localhost:8080 \ kubeappsapis.core.packages.v1alpha1.PackagesService.GetInstalledPackageSummariesAppRepository CRD 与 controller仓库生命周期管理Chart 仓库在 Kubeapps 中通过名为apprepositories.kubeapps.com的 CustomResourceDefinition 管理。每个加入 Kubeapps 的仓库都是一个AppRepository类型对象apprepositories-controller监听这些对象的变更以更新可部署应用列表。CRD 结构完整 CRD 定义见 chart/kubeapps/crds/apprepository-crd.yaml要点如下API group 为kubeapps.comscope: Namespaced版本v1alpha1短名appreposspec.type枚举为[helm, oci]spec.url与spec.type均为必填可选字段包括auth.header.secretKeyRef授权头、auth.customCA.secretKeyRef自定义 CA、dockerRegistrySecrets、tlsInsecureSkipVerify、passCredentials、interval自定义同步间隔、filterRule.jq过滤规则、ociRepositories、resyncRequests、syncJobPodTemplate自定义同步 Job 的 Pod 模板提供additionalPrinterColumnsType / URL便于kubectl get查看。一个最简的 AppRepository 示例apiVersion: kubeapps.com/v1alpha1 kind: AppRepository metadata: name: bitnami spec: url: https://charts.bitnami.com/incubator type: helm控制器工作流监听变更 → 生成 CronJob该控制器基于 Kubernetes Sample Controller 模式开发核心实现见 cmd/apprepository-controller/server/controller.go。运行流程通过 informer 监听 AppRepository 的 Add/Update/Delete 事件controller.go把变更对象放入限速工作队列rate-limited workqueue工作队列消费后调用syncHandler先确保对应的 CronJob 存在且最新ensureCronJob并借助 OwnerReference 建立AppRepository 拥有 CronJob的关系这样 CronJob 被误删时可被自动重建controller.go首次创建 CronJob 时会立即额外创建一个同步 Job做初始同步AppRepository 更新后同样触发一次性同步 Jobcontroller.go通过 finalizerapprepositories.kubeapps.com/apprepo-cleanup-finalizer保证删除仓库时先触发清理 Job、删除对应 CronJob再移除 finalizer 完成删除controller.go。CronJob/Job 的构造细节在 cmd/apprepository-controller/server/job_utils.go同步调度默认使用全局 crontab若 AppRepository 自带spec.interval则优先采用该间隔支持 cron 表达式或时长字符串转换并发策略Allow/Forbid/Replace默认Replace还可注入自定义 labels/annotations、镜像拉取密钥、DB 凭据等。同步 Job 容器即 asset-syncer 镜像命令与参数由控制器拼装如--global-repos-namespace、--namespace、--tls-insecure-skip-verify、--filter-rules等。关键运行参数控制器全部命令行参数见 cmd/apprepository-controller/cmd/root.go常用项包括--repo-sync-image默认docker.io/kubeapps/asset-syncer:latestCronJob 使用的同步镜像--namespace默认kubeapps发现 AppRepository 资源的命名空间--global-repos-namespace默认kubeapps全局仓库命名空间--repos-per-namespace默认true是否监听所有命名空间中的仓库--crontab默认*/10 * * * *默认同步调度--database-url/--database-user/--database-name元数据库连接参数--concurrency-policy默认Replace、--successful-jobs-history-limit默认 3、--failed-jobs-history-limit默认 1--v1-beta1-cron-jobs是否使用 batch/v1beta1 的 CronJob供 K8s 1.20 用户使用。开发调试时可先将集群内控制器缩容到 0再在本机运行二进制kubectl -n kubeapps scale deployment kubeapps-internal-apprepository-controller --replicas0 ./apprepository-controller --repo-sync-imagedocker.io/kubeapps/asset-syncer:myver --kubeconfig ~/.kube/configasset-syncer仓库扫描与元数据入库asset-syncer是一个扫描 Helm Chart 仓库并把图表元数据填充进数据库的工具源码位于 cmd/asset-syncer/其产出由 kubeapps-apis 的 Helm 插件对外提供。它提供三个子命令见 cmd/asset-syncer/cmd/root.gosync [REPO NAME] [REPO URL] [REPO TYPE]新增仓库并周期重同步delete [REPO NAME]删除仓库元数据invalidate-cache清除全部数据以便重建缓存。同步主流程见 cmd/asset-syncer/server/sync.go校验必须恰好三个位置参数依据仓库类型helm/oci构造对应的仓库接口实现OCI 类型可选通过OCI_CATALOG_URL连接 oci-catalog 服务获取仓库列表计算仓库 checksum若与上次一致则直接跳过避免重复同步首次同步时先做一次仅最新版本shallow同步以尽快给出反馈随后执行全量同步通过 channel 流式拉取图表结果、逐条入库同时由文件导入器fileImporter并行抓取图标与 chart 文件并删除缺失图表最后更新数据库中的上次检查时间。数据库连接信息通过DB_PASSWORD环境变量注入生产中由控制器拼装的 Job 从 Secret 读取见 job_utils.go。本机开发调试示例export DB_PASSWORD$(kubectl get secret --namespace kubeapps kubeapps-postgresql \ -o go-template{{index .data postgres-password | base64decode}}) telepresence --namespace kubeapps --docker-run -e DB_PASSWORD$DB_PASSWORD --rm -ti \ kubeapps/asset-syncer /asset-syncer sync --database-userpostgres \ --database-urlkubeapps-postgresql:5432 --database-nameassets \ stable https://kubernetes-charts.storage.googleapis.com常用同步参数root.go还包括--tls-insecure-skip-verify、--filter-rulesJSON 过滤规则、--pass-credentials、--oci-repositoriesOCI 仓库列表、--global-repos-namespace等。pinniped-proxyBearer Token 换 x509 证书的可选代理pinniped-proxy是一个可选组件Rust 实现源码位于 cmd/pinniped-proxy/它代理携带Authorization: Bearer token头的入站请求通过 Pinniped 聚合 API 将该令牌兑换为 x509 短期客户端证书再转发到目标 Kubernetes API server。其价值在于当 Kubernetes API server未配置 OIDC时Kubeapps 前端仍可通过它转发 OIDC 请求——先兑换 OIDC id_token 为 API server 可用的客户端证书再访问 API server。代理默认监听端口3333-p, --port见 cmd/pinniped-proxy/src/cli.rs 中的帮助输出。本机可用 cargo 运行与测试cargo run -- -h # 查看帮助 cargo test # 运行测试 cargo fmt # 格式化代码如需将本地改动推送到集群测试可构建镜像、加载进 kind 并更新 Deployment 镜像IMAGE_TAGdev make kubeapps/pinniped-proxy kind load docker-image kubeapps/pinniped-proxy:dev --name kubeapps kubectl set image -n kubeapps deployment kubeapps pinniped-proxykubeapps/pinniped-proxy:dev kubectl delete pod -n kubeapps -l appkubeapps日志查看方式kubectl logs deployment/kubeapps pinniped-proxy -n kubeapps -f代理日志与kubectl logs deployment/pinniped-concierge -n pinniped-concierge -fPinniped 日志。完整的本地 playground 环境搭建、多集群配置、证书 CA 复制注意事项与故障排查见 Kubeapps Pinniped Proxy 开发者指南。oci-catalogOCI 注册表目录查询的可选服务oci-catalog是一个可选组件Rust 实现源码位于 cmd/oci-catalog/让 Kubeapps 能够展示某个 OCI 注册表或注册表的命名空间中的应用目录。其设计定位是无状态 gRPC 微服务通常但不仅限于作为 asset-syncer Job 的 sidecar 运行为注册表按命名空间提供仓库列表且不依赖具体注册表厂商。从源码看服务采用策略模式strategy pattern以支持不同 OCI 提供方的注册表目录枚举在 OCI Distribution 规范为按命名空间请求注册表仓库确立标准之前。其 gRPC 服务默认监听端口50001OCI_CATALOG_PORT环境变量可覆盖proto 定义位于 cmd/oci-catalog/proto/ocicatalog/v1alpha1/。本机开发cargo run -- --help在 Kubeapps 中当 AppRepository 类型为oci且控制器配置了--oci-catalog-url或通过OCI_CATALOG_URL环境变量注入时asset-syncer 会调用该服务枚举仓库见 sync.go 与 job_utils.go。注意该组件文档仍标记为持续开发中见 oci-catalog 开发者指南。组件协作全景把六个组件串起来一次完整的添加仓库 → 看到应用 → 安装应用流程如下用户在 dashboard 上添加仓库controller 创建 AppRepository CR实际初始仓库也可由 Helm values 的apprepository.initialRepos在安装时预置模板见 chart/kubeapps/templates/apprepository/apprepositories.yamlapprepository-controller 监听到对象后创建 CronJob 并立即触发一次性同步 Job同步 Job 内 asset-syncer 扫描仓库将包元数据写入 PostgreSQLHelm 场景或对接 Redis/Flux打包插件场景kubeapps-apis 的 Helm/Flux/Carvel 插件按需读取这些元数据core packages 服务聚合各插件结果dashboard 通过 gRPC-Web 调用 core packages API统一展示目录、安装与回滚Helm应用展示已安装应用资源时经 resources 插件流式获取不再直连 Kubernetes API server在非 OIDC 集群中Kubernetes API 访问可经 pinniped-proxy 完成令牌兑换。各组件开发者文档分别位于 dashboard.md、kubeapps-apis.md、apprepository-controller.md、asset-syncer.md、pinniped-proxy.md 与 oci-catalog.md可作为进一步深入各组件源码与调试手段的入口。总体而言Kubeapps 架构的核心思想是用插件化解耦打包格式差异、用统一的 core packages API 聚合多种生态同时以 CRD Controller Job 的 Kubernetes 原生模式管理仓库生命周期——这套设计既保证了 UI 层的简单一致也为后续接入新的打包格式留足了扩展空间。赞分享云原生后端前端【免费下载链接】kubeappsA web-based UI for deploying and managing applications in Kubernetes clusters项目地址https://gitcode.com/gh_mirrors/ku/kubeapps点击查看免费下载相关推荐Kubeapps APIs 服务深度解析可插拔 gRPC 架构、核心 Packages 接口与 resources 插件实战Kubeapps APIs 服务深度解析可插拔 gRPC 架构、核心 Packages 接口与 resources 插件实战 Kubeapps APIs se云原生后端前端G-Helper AMD CPU降压调优终极方案华硕笔记本性能深度调优专业指南G Helper AMD CPU降压调优终极方案华硕笔记本性能深度调优专业指南 G Helper作为轻量级的Armoury Crate替代工具为华硕ROG、桌面应用系统编程Velero深度解析架构设计与核心组件Velero深度解析架构设计与核心组件 Velero原名Heptio Ark是一款用于备份和恢复Kubernetes集群资源及持久卷的工具支持公共云平台云原生灾备存储后端创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考