Kubeapps 实战:在 VMware Tanzu Community Edition 非托管集群上部署 Kubeapps 并配置 Service Account 认证-平芜编程栈

云原生
后端
前端

【免费下载链接】kubeapps

A web-based UI for deploying and managing applications in Kubernetes clusters

项目地址：https://gitcode.com/gh_mirrors/ku/kubeapps

本文以 Kubeapps 官方教程site/content/docs/latest/tutorials/kubeapps-on-tce/02-TCE-unmanaged-cluster.md为主线,讲解如何在 VMware Tanzu Community Edition(下文简称 TCE)上创建一个非托管(unmanaged)集群,验证 TCE 软件目录已自动注入,并通过 Service Account 方式生成访问 Kubeapps 与 Kubernetes 的 token。读完本篇后,你将能够独立在本地环境拉起一个装有 kapp-controller 的单节点 K8s 集群、确认 TCE 主目录与 tkg-core-repository 可用,并拿到后续部署 Kubeapps 所需的认证凭据。

一、背景:TCE 非托管集群是什么

TCE 是用于快速引导和管理 Kubernetes 集群的一组组件,主要包括 Tanzu CLI、managed(托管)集群和 unmanaged(非托管)集群三种形态(参见 TCE 集群部署准备文档):

Tanzu CLI:安装在本地的命令行工具,用于在目标平台上操作集群;
Managed 集群:Tanzu 生态的主要部署模型,推荐用于生产场景;
Unmanaged 集群:单节点、本地工作站规模的集群,适合开发/测试环境。

非托管集群的默认行为是:基于 kind(默认)或 minikube 在本地运行,并在其上叠加 Tanzu 组件(如 kapp-controller、CNI、包仓库等)。因此它是"用最低成本获得一个 Tanzu 完整能力集群"的方式,非常适合跑通 Kubeapps 的部署教程。本文属于整个 TCE 教程的第 2 步(非托管分支),前置步骤是安装 Tanzu CLI 并确认tanzu version可用。

二、创建 TCE 非托管集群

2.1 启动集群

执行一条命令即可创建一个集群,例如命名为kubeapps-cluster:

tanzu unmanaged-cluster create kubeapps-cluster

该命令会同步等待集群完成初始化,典型输出如下(原文档中的完整输出,保留了各阶段标记,便于排查卡点):

📁 Created cluster directory 🧲 Resolving and checking Tanzu Kubernetes release (TKr) compatibility file projects.registry.vmware.com/tce/compatibility Compatibility file exists at ~/.config/tanzu/tkg/unmanaged/compatibility/projects.registry.vmware.com_tce_compatibility_v9 🔧 Resolving TKr projects.registry.vmware.com/tce/tkr:v1.22.7-2 TKr exists at ~/.config/tanzu/tkg/unmanaged/bom/projects.registry.vmware.com_tce_tkr_v1.22.7-2 Rendered Config: ~/.config/tanzu/tkg/unmanaged/kubeapps-cluster/config.yaml Bootstrap Logs: ~/.config/tanzu/tkg/unmanaged/kubeapps-cluster/bootstrap.log 🔧 Processing Tanzu Kubernetes Release 🎨 Selected base image projects.registry.vmware.com/tce/kind:v1.22.7 📦 Selected core package repository projects.registry.vmware.com/tce/repo-12:0.12.0 📦 Selected additional package repositories projects.registry.vmware.com/tce/main:0.12.0 📦 Selected kapp-controller image bundle projects.registry.vmware.com/tce/kapp-controller-multi-pkg:v0.30.1 🚀 Creating cluster kubeapps-cluster Cluster creation using kind! ❤️ Checkout this awesome project at https://kind.sigs.k8s.io Base image downloaded Cluster created To troubleshoot, use: kubectl ${COMMAND} --kubeconfig ~/.config/tanzu/tkg/unmanaged/kubeapps-cluster/kube.conf 📧 Installing kapp-controller kapp-controller status: Running 📧 Installing package repositories tkg-core-repository package repo status: Reconcile succeeded 🌐 Installing CNI calico.community.tanzu.vmware.com:3.22.1 ✅ Cluster created 🎮 kubectl context set to kubeapps-cluster View available packages: tanzu package available list View running pods: kubectl get po -A Delete this cluster: tanzu unmanaged delete kubeapps-cluster

从输出中可以读出该流程的完整阶段划分,这也是排查问题的检查清单:

集群目录创建:配置与日志统一存放在~/.config/tanzu/tkg/unmanaged/<集群名>/下;
TKr(Tanzu Kubernetes Release)解析:校验兼容性文件并渲染出config.yaml,同时记录bootstrap.log;示例中解析到的是v1.22.7-2对应的 K8s 1.22.7 基础镜像;
包仓库选择:核心仓库repo-12与附加仓库main均来自projects.registry.vmware.com/tce仓库,版本为 0.12.0;
kind 建群 + Tanzu 组件安装:依次安装 kapp-controller(状态 Running)、包仓库(Reconcile succeeded)和 Calico CNI(3.22.1);
收尾:自动切换 kubectl context 到新集群,并给出常用命令提示——查看可用包用tanzu package available list,查看 Pod 用kubectl get po -A,删除集群用tanzu unmanaged delete kubeapps-cluster。

2.2 使用 kubectl 与集群交互

集群创建完成后会被自动追加到本地 kubeconfig。只要本地安装了 kubectl,即可直接操作集群;如果需要手动指定 kubeconfig(例如脚本场景),输出中已给出路径约定:

kubectl <COMMAND> --kubeconfig ~/.config/tanzu/tkg/unmanaged/kubeapps-cluster/kube.conf

2.3 验证 TCE 目录已自动注入

非托管集群在创建过程中会自动安装包仓库。集群就绪后,运行:

tanzu package repository list --all-namespaces

输出中应包含最新的 TCE main 目录,例如:

NAME REPOSITORY TAG STATUS DETAILS NAMESPACE projects.registry.vmware.com-tce-main-0.12.0 projects.registry.vmware.com/tce/main 0.12.0 Reconcile succeeded tanzu-package-repo-global tkg-core-repository projects.registry.vmware.com/tce/repo-12 0.12.0 Reconcile succeeded tkg-system

两条记录分别对应两个 PackageRepository 资源:

projects.registry.vmware.com-tce-main-0.12.0位于tanzu-package-repo-global命名空间,是 TCE 主应用目录(后续部署 Kubeapps、Contour 等包都从这里查找);
tkg-core-repository位于tkg-system命名空间,提供 Tanzu 引导集群自身所需的底层组件。

两者状态均为Reconcile succeeded才能进入教程的下一步;若处于 Reconciling 或失败状态,应检查节点能否拉取projects.registry.vmware.com的镜像与制品。

三、认证:为 Kubeapps 创建 Service Account 凭据

非托管集群主要面向开发/测试场景,因此本教程采用Service Account 认证方式访问 Kubeapps 与 Kubernetes。需要牢记:对于任何面向用户的正式安装,都应配置 OAuth2/OIDC 提供商以获得安全的用户认证(参见使用 OIDC Provider 教程),Service Account 只是本教程的简化路径。

Kubeapps 自身没有独立的认证层,而是复用 Kubernetes 原生的认证机制;每次对 Kubeapps 的请求都需要一个被集群 API Server 信任的 token。这一设计在 Access Control 文档中有完整说明,其中也明确"Service Account 认证不推荐用于生产"。

3.1 创建演示凭据

创建一个名为kubeapps-operator的 Service Account,并授予cluster-admin角色:

kubectl create --namespace default serviceaccount kubeapps-operator kubectl create clusterrolebinding kubeapps-operator --clusterrole=cluster-admin --serviceaccount=default:kubeapps-operator cat <<EOF | kubectl apply -f - apiVersion: v1 kind: Secret metadata: name: kubeapps-operator-token namespace: default annotations: kubernetes.io/service-account.name: kubeapps-operator type: kubernetes.io/service-account-token EOF

三条命令的作用分别是:

在default命名空间创建 Service Account;
通过 ClusterRoleBinding 将该 Service Account 与cluster-admin集群角色绑定,使其具备集群级管理权限;
创建一个kubernetes.io/service-account-token类型的 Secret,通过kubernetes.io/service-account.name注解声明"该 token 属于哪个 Service Account"——API Server 会为这个 Secret 自动签发长期有效的 token,这正是后续手动取 token 的依据。

注意:原文档特别提醒,不建议在 Kubeapps 生产使用场景中给用户分配cluster-admin角色。生产环境应参照 Access Control 文档配置细粒度 RBAC(例如按命名空间授予应用读/写角色)。本教程使用cluster-admin仅为简化演示。

3.2 获取 token

访问 Kubeapps 需要一个 token。由于这里是纯 Service Account 认证,获取 token 十分直接。请妥善保存该 token,教程后续步骤(部署 Kubeapps 后登录界面)会用到。

Linux / macOS:

kubectl get --namespace default secret kubeapps-operator-token -o go-template='{{.data.token | base64decode}}'

Windows:

打开 PowerShell 终端执行:

[Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String($(kubectl get --namespace default secret kubeapps-operator-token -o jsonpath='{.data.token}')))

两种写法本质相同:.data.token在 etcd/API 中以 base64 编码存储,需要先解码出原始 JWT 字符串才能作为凭据使用;PowerShell 版本只是把 base64 解码换成了 .NET 的Convert.FromBase64String。

3.3 源码视角:这个 token 在 Kubeapps 里如何被使用

从源码结构看,上述 token 的生命周期在 Kubeapps 前端中有明确的落点:

登录页面在未启用 OAuth 时渲染 Token 登录组件,提示 "Your cluster operator should provide you with a Kubernetes API token",用户粘贴 token 提交;
提交后 auth action 调用 Auth.validateToken / Auth.setAuthToken 校验并保存 token;
之后所有对集群的 gRPC-web 请求都会通过 KubeappsGrpcClient 把 token 放入Authorization: Bearer <token>请求头。

也就是说,Kubeapps 只是把浏览器提交的 token 原样透传给 Kubernetes API 链路,鉴权边界始终在 API Server 一侧。这也解释了为什么第 2 步创建的 ClusterRoleBinding 直接决定了 Kubeapps UI 能执行哪些操作:token 权限 = Service Account 的 RBAC 权限。

3.4 与 OIDC 认证的对照

如果改用 OIDC(面向用户的推荐方案),认证由 Kubeapps 自带的 OAuth2 proxy 完成,相关参数在 Helm/TCE 配置值文件中声明,例如(参见 chart values 文件):

authProxy: enabled: true provider: oidc clientID: <YOUR_CLIENT_ID> clientSecret: <YOUR_CLIENT_SECRET> cookieSecret: <COOKIE_SECRET> scope: "openid email groups" extraFlags: - --oidc-issuer-url=<YOUR_OIDC_ISSUER_URL>

该示例摘自教程的配置准备文档。与之相对,本文的 Service Account 路径下authProxy保持关闭,Kubeapps 直接展示 Token 登录页,两者互斥、不可同时启用。

四、小结与后续步骤

完成本篇后,你手上应当具备两样东西:一个已加入本地 kubeconfig、TCE 目录就绪的非托管集群,以及一个可用的kubeapps-operatortoken。按照教程索引继续:

TCE 集群部署准备
部署托管集群或部署非托管集群(本文)
准备 Kubeapps 部署(配置 values 文件)
通过tanzu package install部署 Kubeapps
在 Kubeapps 中管理应用

适用前提与限制:本流程面向 TCE 0.12.x 时代的组件版本(示例输出对应 TKr v1.22.7-2、kind 1.22.7、kapp-controller v0.30.1),仅适用于开发/测试环境;非托管集群为单节点本地集群,不具备高可用与横向扩展能力;cluster-admin级 Service Account 仅用于演示,生产环境务必替换为 OIDC + 细粒度 RBAC。