# 部署 要启用基于 Web 的管理控制台，请确保在 Operator 配置中同时启用了仪表盘（dashboard）和 网关（Gateway）组件。这将确保控制台能够正确部署在 Kubernetes 集群中。 {% hint style="warning" %} 管理控制台目前仅支持Kubernetes部署。不支持裸机部署。 {% endhint %} ### 配置示例 以下是用于管理控制台的示例配置，可添加到现有的 Alluxio 集群配置 YAML 文件中： ```yaml apiVersion: k8s-operator.alluxio.com/v1 kind: AlluxioCluster spec: gateway: enabled: true image: /alluxio-gateway imageTag: AI-3.6-12.0.2 dashboard: enabled: true image: /alluxio-dashboard imageTag: AI-3.6-12.0.2 ``` ## 访问管理控制台 访问管理控制台有以下几种方式： ### 通过节点主机名访问控制台 控制台将在其主机上的80端口公开其服务。使用kubectl获取主机名： ```shell kubectl -n alx-ns get pod $(kubectl -n alx-ns get pod -l app.kubernetes.io/component=dashboard --no-headers -o custom-columns=:metadata.name) -o jsonpath='{.spec.nodeName}' ``` 假设主机名是`foo.kubernetes.org`，则可以在以下位置访问管理控制台： ``` http://foo.kubernetes.org:80/ ``` ### 通过负载均衡器访问控制台 要在外部公开管理控制台，可以配置类型为`LoadBalancer`的Kubernetes服务。这允许集群外部的流量访问 Dashboard 组件。 以下是通过负载均衡器公开 Dashboard 服务定义的示例： ```yaml apiVersion: v1 kind: Service metadata: name: my-service spec: type: LoadBalancer ports: - protocol: TCP port: 80 targetPort: 80 selector: app.kubernetes.io/instance: alluxio-dashboard app.kubernetes.io/name: dashboard ``` 将上述内容保存为 `load-balancer.yaml` 文件，并通过以下命令创建该服务： ``` kubectl create -f load-balancer.yaml ``` 创建服务后，Kubernetes将提供外部IP或DNS名称，具体取决于您的云服务厂商。可以使用以下命令查看状态： ```bash kubectl -n alx-ns get service load-balancer ``` 示例输出： ```bash my-service LoadBalancer 171.33.111.33 some-random-string.region.elb.amazonaws.com 80:30977/TCP 8m50s ``` 现在，您可以使用外部IP或DNS名称在浏览器中访问管理控制台。 ### 登录控制台 在默认的 `authType` 设置为 `simple` 的情况下，登录页面只会要求输入用户名。由于该模式主要用于测试用途，因此不会进行任何验证，任意用户名均可登录。
在生产环境中，应该将认证类型修改为[使用 Okta 进行身份验证](#okta-ren-zheng-lei-xing)，以确保安全性。 ### 高级配置 #### 启用审计日志 审计日志用于跟踪用户在管理控制台中的活动以及系统事件，以满足安全性和合规性要求。此功能默认启用，无需额外配置。 **访问审计日志：**\ 可在 Web Console Pod 内的`/opt/alluxio/dashboard/audit-logs/dashboard-audit.log`路径查看日志文件。 **配置示例：** ```yaml apiVersion: k8s-operator.alluxio.com/v1 kind: AlluxioCluster spec: dashboard: enabled: true image: /alluxio-dashboard imageTag: AI-3.6-12.0.2 auditLog: enabled: true # Set to false to disable audit logging ``` ### 配置 Gateway 和管理控制台之间的 TLS 连接 当在 Gateway 中启用 TLS（传输层安全协议）时，需要配置管理控制台以建立安全的 TLS 连接。这包括向 Web 控制台提供 CA（证书颁发机构）证书，控制台将使用该证书来验证 Gateway 的 TLS 证书的有效性。 1. **准备 CA 证书** * 已获取有效的 CA 证书文件（通常命名为 `ca.crt`） * 准备好 Gateway 的证书文件（`server.crt`）和私钥文件（`server.key`） * 确保 Gateway 的证书已由该 CA 正确签署 2. **创建 Kubernetes Secret** ```bash # 使用 CA 证书、Gateway 证书和 key 创建 Kubernetes Secret kubectl create secret generic gateway-k8s-secret-name \ --from-file=ca.crt=/path/to/ca.crt \ --from-file=server.key=/path/to/server.key \ --from-file=server.crt=/path/to/server.crt \ --namespace=alx-ns ``` 3. **配置Alluxio 集群** ```yaml apiVersion: k8s-operator.alluxio.com/v1 kind: AlluxioCluster spec: gateway: enabled: true image: /alluxio-gateway imageTag: AI-3.6-12.0.2 tls: enabled: true secretName: gateway-k8s-secret-name certFile: server.crt certKeyFile: server.key dashboard: enabled: true image: /alluxio-dashboard imageTag: AI-3.6-12.0.2 gateway: secretName: gateway-k8s-secret-name caFile: ca.crt ``` #### 重要说明 * 配置中的 `secretName` 必须与创建 Kubernetes secret 时使用的名称完全匹配。 * 所有文件名（如 `caFile`、`certFile`、`certKeyFile`）必须与 Secret 中使用的文件名对应。 * 确保 CA 证书和 Gateway 证书均有效且未过期。 * 管理控制台在连接时会使用 CA 证书来验证 Gateway 的 TLS 证书。 * **重要：** 提供的 CA 证书必须与 Gateway 的 TLS 证书在同一个证书链中。使用来自不同证书链的 CA 证书将导致 TLS 验证失败。 ### Okta 认证类型 Okta认证为您的管理控制台提供安全的企业级访问控制。请按照以下步骤设置和使用Okta认证： **1. Okta中的应用程序配置** 1. 登录到Okta管理控制面板 2. 导航到**Applications** > **Applications** 3. 点击**Create App Integration** 4. 选择\*\*Single-Page Application (SPA)\*\*类型 * 这种应用程序类型利用[带PKCE的授权码流](https://developer.okta.com/docs/guides/implement-grant-type/authcodepkce/main/#about-the-authorization-code-grant-with-pkce)进行安全的客户端 token 获取
5\. 使用应用程序名称和一些选项完成基本配置
6. 在应用程序设置的**Login**部分，配置： * **Sign-in redirect URIs**：`http://your-domain:your-port/login/callback` * **Sign-out redirect URIs**：`http://your-domain:your-port/user/login` * 将`your-domain`和`your-port`替换为实际的域名和端口值 * 这些设置确保Okta认证完成后的正确重定向
7. 保存应用程序配置 **2. 用户组分配和授权** 要控制对管理控制台的访问： 1. 在Okta管理控制面板中，导航到**Directory** > **Groups**
2. 创建用户组（如果尚未创建），例如 "Admins" 3. 将相应的用户添加到这些用户组中 4. 返回到应用程序设置 5. 在**Assignments**选项卡下，分配应该有权访问管理控制台的用户组
**3. 授权服务器配置** 管理控制台需要特定的OAuth作用域才能正常运行： 1. 在Okta管理控制面板中，导航到**Security** > **API** 2. 选择授权服务器（或根据需要创建一个） 3. 转到**Scopes (作用域）**选项卡 4. 点击**Add Scope**
5. 创建一个名为`alluxio`的作用域，并填写适当的描述 6. 管理控制台需要`openid`作用域（Okta中的默认值）和这个自定义的`alluxio`作用域 7. 如果在部署中启用了授权，请将相应的声明（claims) 与此作用域关联。在下面的屏幕截图中，授权配置中的`roleFieldName`设置为`userType`，`groupFieldName`设置为`department`。更多信息请访问[用户角色和访问控制](/ee-ai-cn/ai-3.6/start/overview/user-roles-access-control.md)。
**4. 获取配置值** 完成设置后，请收集以下信息，用于管理控制台的配置： 1. **Okta发行者URL**： * 在Okta管理控制面板中导航到**Security** > **API** * 选择授权服务器 * 复制发行者URL（格式：`https://your-okta-domain/oauth2/default`） 2. **客户端ID**： * 转到应用程序设置 * 从**Client Credentials**部分复制客户端ID 3. 使用这些值更新Alluxio配置： ```yaml web: authType: okta oktaIssuer: https://your-okta-domain/oauth2/default oktaClientID: your-client-id-value ``` **5. 登录过程**

带有Okta选项的管理控制台登录页面

Okta认证门户

使用Okta认证时： 1. 导航到管理控制台URL 2. 登录页面将显示"Login with Okta"按钮 3. 点击此按钮将被重定向到您所在组织的Okta认证门户 4. 输入Okta凭证并完成配置的多因素认证（如果有） 5. 成功认证后，将被重定向回管理控制台 6. 当前会话将根据Okta token的配置保持有效 **6. Okta集成故障排除** 如果您在Okta认证中遇到问题： * 验证重定向URI在Okta和应用程序中是否正确配置 * 检查用户是否分配到具有应用程序访问权限的相应用户组 * 确保`alluxio`作用域正确创建并与授权服务器关联 * 确认配置中的发行者URL和客户端ID与Okta中的值匹配 --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://documentation.alluxio.io/ee-ai-cn/ai-3.6/start/overview/deployment.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.