企业官网建设流程全解析

• 云原生
• 后端
• 前端

本文对应仓库官方入门指南 site/content/docs/latest/tutorials/getting-started.md（原user/getting-started.md已重定向至该文件）。Kubeapps 是面向 Kubernetes 的云原生 Web 应用商店与运维面板：一次安装即可获得浏览/部署打包应用、可视化定制部署参数、升级/管理/删除集群内应用以及通过 API 管理软件仓库与应用的能力。读完本文，你将掌握在自有集群上从零安装 Kubeapps、创建演示凭据登录 Dashboard，并完成 WordPress 应用从部署到卸载的完整实战链路，同时理解其背后的前端反代、kubeapps-apis 插件服务与 RBAC 鉴权机制。

导读

本指南围绕“试用 Kubeapps 并跑通第一个应用”这条主线展开：先在集群中通过 Helm 安装官方 Chart，再创建 Kubernetes ServiceAccount 作为演示凭据登录 Dashboard，随后在 Catalog 中搜索并部署 WordPress，最后体验一键卸载。对于需要面向真实用户开放的部署场景，指南也会引导你切换到 OIDC 认证与细粒度 RBAC 方案，并给出仓库内对应文档的路径。

前置条件

• 一个可用的 Kubernetes 集群（v1.21+），并已安装、配置好能访问该集群的helm明确声明kubeVersion: '>=1.21.0-0'，与文档要求一致。
• Kubeapps 已在 AKS、GKE、kind、minikube 以及 Docker for Desktop Kubernetes 等环境完成验证。
• Kubeapps 支持在启用 RBAC 的集群上运行，官方建议开启 RBAC 以保证更安全的安装。
• 在 GKE 上安装 Kubeapps 时，需要拥有集群的Owner或Container Engine Admin角色。

第一步：安装 Kubeapps

使用官方 Bitnami Kubeapps Chart 安装最新版本：

kubectl create namespace kubeapps helm install kubeapps --namespace kubeapps oci://registry-1.docker.io/bitnamicharts/kubeapps

上述命令将 Kubeapps 部署到集群的kubeapps命名空间中，通常需要几分钟时间完成。当 Kubeapps 的 Pod 全部处于 Running 状态后，即可进入第二步。

安装背后：这个 Chart 到底装了什么

从仓库内的 chart/kubeapps/Chart.yaml（当前 Chart 版本 17.1.1）可以看到，一次安装会拉起以下核心组件（镜像均基于 bitnami 2.12.1 系列）：

• frontend：Bitnami NGINX 反向代理，是 Dashboard 的对外入口，同时承担向 kubeapps-apis 与 Kubernetes API Server 转发请求的职责（模板见 chart/kubeapps/templates/frontend/deployment.yaml）；
• dashboard：React 前端界面（源码位于 dashboard/src，入口为 dashboard/src/index.tsx）；
• kubeapps-apis：以 gRPC + HTTP gateway 形式暴露的统一 API 服务（入口见 cmd/kubeapps-apis/server/server.go）；
• apprepository-controller：负责监听 AppRepository 资源并周期性同步仓库索引（见 cmd/apprepository-controller/server/controller.go）；
• pinniped-proxy / oauth2-proxy：仅在多集群、OIDC 等场景启用；
• 依赖子 Chart：Helm 打包插件依赖PostgreSQL，Flux 打包插件依赖Redis（见Chart.yaml的dependencies段）。

默认的 chart/kubeapps/values.yaml 中，packaging.helm.enabled默认为true，即开箱即用标准 Helm 打包能力；apprepository.initialRepos预置了 Bitnami 官方仓库（https://charts.bitnami.com/bitnami），这正是第四步能在 Catalog 里搜到 WordPress 等应用的原因。

若需要更详细的安装、配置与升级说明，可直接查阅仓库中的 chart/kubeapps/README.md 以及values.yaml内按@section/@param组织的大量注释（2511 行，覆盖 ingress、service、resources、securityContext 等全部可调参数）。

第二步：创建演示凭据，访问 Kubeapps 与 Kubernetes

面向真实用户的生产安装，官方推荐 配置 OAuth2/OIDC 提供方 实现安全认证；但试用 Kubeapps 时配置 OIDC 开销较大。更简单的做法是创建一个 Kubernetes ServiceAccount，并将其 API Token 作为访问凭据。

注意：生产环境不建议给用户授予cluster-admin角色。细粒度权限配置请参考仓库中的 访问控制文档。

在 Linux / macOS 上创建

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

在 Windows 上创建

kubectl create --namespace default serviceaccount kubeapps-operator kubectl create clusterrolebinding kubeapps-operator --clusterrole=cluster-admin --serviceaccount=default:kubeapps-operator @" 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 "@ | kubectl apply -f -

从 Kubernetes 1.24 起，ServiceAccount 不再自动生成长期 Token，因此这里需要显式创建kubernetes.io/service-account-token类型的 Secret，并通过kubernetes.io/service-account.name注解将其绑定到目标 ServiceAccount。

获取 Token

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}')))

Windows（CMD）

新建文件GetDashToken.cmd，写入以下内容：

@ECHO OFF REM Get the Base64 encoded token kubectl get --namespace default secret kubeapps-operator-token -o jsonpath={.data.token} > b64.txt REM Decode The Token DEL token.txt certutil -decode b64.txt token.txt

在命令提示符中运行GetDashToken.cmd，Token 会输出到token.txt文件中。

为什么 ServiceAccount 方式适合“试用”

从源码看，Kubeapps 本身不实现独立认证层，而是完全复用 Kubernetes 自身的认证与授权机制：cmd/kubeapps-apis/core/plugins/v1alpha1/plugins.go 中的extractToken会从每个 gRPC/HTTP 请求的Authorization: Bearer <token>头中提取凭据，再由kube.NewClusterConfig以该用户身份访问 Kubernetes API Server。因此你给这个 ServiceAccount 授什么权，Dashboard 里就只呈现对应权限范围内的资源——这正是第二步先建 SA、再绑cluster-admin即可“全功能试用”的根本原因。

第三步：启动 Kubeapps Dashboard

Kubeapps 安装完成后，通过端口转发安全地访问 Dashboard：

kubectl port-forward -n kubeapps svc/kubeapps 8080:80

命令在本地 8080 端口与kubeapps命名空间中的kubeappsService 的 80 端口之间建立 HTTP 代理。随后在浏览器中访问 http://127.0.0.1:8080/ 即可打开登录页：

将第二步生成的 Token 粘贴到登录框完成认证，即可进入 Kubeapps Dashboard 主页：

注意：以上port-forward仅适合个人试用。若要让其他人访问 Kubeapps，应改用其他 Service 类型或配置 Ingress。对应可调参数均位于 chart/kubeapps/values.yaml：默认frontend.service.type: ClusterIP、frontend.service.ports.http: 80（这正是8080:80映射的目标端口）；如需对外暴露可改为LoadBalancer/NodePort或启用ingress.enabled（含 TLS 与 cert-manager 注解支持，ingress.tls、ingress.selfSigned、ingress.extraHosts等详见该文件 79 行起的 Ingress 段落）。生产场景的具体接入方式还可参考 howto/dashboard.md。

流量链路：登录后发生了什么

从 chart/kubeapps/templates/frontend/configmap.yaml 的 NGINX 配置可以看到 Dashboard 的请求路由设计：

• location /将页面请求反向代理到kubeapps-internal-dashboard服务（React 应用本体）；
• location ~* /apis将 API 请求重写后转发到kubeapps-internal-kubeappsapis（即 kubeapps-apis 服务），proxy_read_timeout 1h保证部署/升级等长任务期间连接不被掐断；
• location /healthz返回200 "healthy"供探针使用。

前端nginx容器监听 8080（frontend.containerPorts.http），而 cmd/kubeapps-apis/server/server.go 中的Serve则在同一端口上同时挂载 gRPC 服务、Connect 路由与 grpc-gateway：先注册 plugins server，再通过GetPluginsSatisfyingInterface把实现了核心 packaging 接口的插件（默认即helm-packages，见 cmd/kubeapps-apis/plugins/helm/packages/v1alpha1/server.go）注册为PackagesService与RepositoriesService。这就是“Catalog 列表、部署表单、仓库管理”等 Dashboard 功能背后的统一 API 层。

第四步：部署应用——以 WordPress 为例

Dashboard 就绪后即可向集群部署应用：

1. 点击Deploy按钮，或进入 Dashboard 的Catalog页面，从已配置仓库的软件包列表中挑选应用。本示例选择 WordPress：

2. 点击Deploy按钮：

3. Kubeapps 会提示填写 release 名称与应用 values。表单由YAMLvalues 自动渲染生成，可切换到相邻的 YAML 标签页直接编辑：

4. 点击Deploy完成部署。你可以直接在浏览器中跟踪部署进度：页面顶部显示应用状态（含access URL与随应用创建的secret），下方列出各 Kubernetes 资源及就绪 Pod 数量；将鼠标悬停在status上还能看到工作负载与就绪/总 Pod 数：

5. 访问 WordPress 站点：按Notes区域的提示执行命令获取 URL，或直接点击页面上展示的 HTTP/HTTPS 链接。

6. 获取登录凭据：同样参考Notes区域；也可点击wordpress-password旁的“眼睛”图标直接查看密码。

提示：云厂商环境下，访问 URL 可能需要一些时间才会分配，期间 Service 会一直处于 “Pending” 状态。若使用 minikube，需先在终端运行minikube tunnel，应用才会被分配 IP 地址。

（可选）第五步：卸载 / 删除 WordPress

需要清理演示应用时，在应用详情页点击Delete按钮即可完成卸载：

生产环境：从“试用凭据”走向正式访问控制

本文第二步使用的cluster-admin仅适合演示评估。面向生产，官方建议：

• 认证：按 OIDC 提供方配置教程 接入 OAuth2/OIDC，让集群信任 Azure AD、Google OIDC 或自建 Dex 等身份源；
• 授权：按 访问控制文档 配置细粒度 RBAC，例如：
  • 命名空间内只读：kubectl create -n default rolebinding example-view --clusterrole=view --serviceaccount default:example；
  • 命名空间内可写：--clusterrole=edit，可部署/管理大多数应用但不能新建仓库；
  • 管理包仓库（含全局仓库与凭据 Secret 权限，需谨慎）：--clusterrole=kubeapps:${KUBEAPPS_NAMESPACE}:apprepositories-write（另有只读版apprepositories-read）；
  • 多命名空间/全集群授权可分别用 RoleBinding 与 ClusterRoleBinding 实现。
• 对应 RBAC 模板可在 chart/kubeapps/templates/apprepository/rbac.yaml 中查看，仓库级权限模型还受 chart/kubeapps/crds/apprepository-crd.yaml 定义的 AppRepository CRD 约束。

下一步

• 学习 Kubeapps 官方文档目录：site/content/docs/latest（含 background / howto / reference / tutorials 等分区）；
• 深入管理包仓库：管理包仓库教程；
• 了解 Flux / Carvel 打包插件：managing-flux-packages.md、managing-carvel-packages.md；
• 多集群部署与离线安装：howto/deploying-to-multiple-clusters.md、howto/offline-installation.md；
• 关注 ROADMAP.md 了解项目演进方向。

• 云原生
• 后端
• 前端