管理 Alluxio

本指南全面概述了在 Kubernetes 上管理正在运行的 Alluxio 集群的管理操作。它涵盖了日常任务，如配置更新、扩展和升级，以及高级主题，如命名空间和多租户管理。

1. 集群生命周期和配置

本节涵盖与集群生命周期相关的基本操作，如扩展、升级和动态配置更新。

扩展集群

您可以动态地增加或减少 Alluxio worker 的数量，以适应工作负载的变化。

扩展 Worker：

修改您的 alluxio-cluster.yaml 文件，并增加 worker 部分下的 count。以下示例将 worker 从 2 个扩展到 3 个。
将更改应用到您的集群。

# 将更改应用到 Kubernetes
$ kubectl apply -f alluxio-cluster.yaml
alluxiocluster.k8s-operator.alluxio.com/alluxio-cluster configured

# 验证新的 worker pod 是否正在创建
$ kubectl -n alx-ns get pod
NAME                                          READY   STATUS            RESTARTS   AGE
...
alluxio-cluster-worker-58999f8ddd-p6n59       0/1     PodInitializing   0          4s

# 等待所有 worker 变为 ready
$ kubectl -n alx-ns get pod -l app.kubernetes.io/component=worker
NAME                                          READY   STATUS    RESTARTS   AGE
alluxio-cluster-worker-58999f8ddd-cd6r2       1/1     Running   0          5m21s
alluxio-cluster-worker-58999f8ddd-rtftk       1/1     Running   0          4m21s
alluxio-cluster-worker-58999f8ddd-p6n59       1/1     Running   0          34s

升级 Alluxio

升级过程包括两个主要步骤：升级 Alluxio Operator，然后升级 Alluxio 集群本身。

步骤 1：升级 Operator

Operator 是无状态的，可以安全地重新安装，而不会影响正在运行的 Alluxio 集群。

获取 Operator 的新 Docker 镜像和新的 Helm chart。
卸载旧的 Operator 并安装新的。

# 卸载当前的 Operator
$ helm uninstall operator
release "operator" uninstalled

# 确保 Operator 命名空间已完全移除
$ kubectl get ns alluxio-operator
Error from server (NotFound): namespaces "alluxio-operator" not found

# 从新的 Helm chart 目录创建和替换新的 CRD
$ kubectl create -f alluxio-operator/crds 2>/dev/null
$ kubectl replace -f alluxio-operator/crds 2>/dev/null
customresourcedefinition.apiextensions.k8s.io/alluxioclusters.k8s-operator.alluxio.com replaced
customresourcedefinition.apiextensions.k8s.io/clustergroups.k8s-operator.alluxio.com replaced
customresourcedefinition.apiextensions.k8s.io/collectinfoes.k8s-operator.alluxio.com replaced
customresourcedefinition.apiextensions.k8s.io/licenses.k8s-operator.alluxio.com replaced
customresourcedefinition.apiextensions.k8s.io/underfilesystems.k8s-operator.alluxio.com replaced

# 使用您的配置文件安装新的 Operator（更新镜像标签）
$ helm install operator -f operator-config.yaml alluxio-operator

步骤 2：升级 Alluxio 集群

Operator 将对 Alluxio 组件执行滚动升级。

将新的 Alluxio Docker 镜像上传到您的注册表。
将 alluxio-cluster.yaml 中的 imageTag 更新为新版本。
应用配置更改。

# 应用更新后的集群定义
$ kubectl apply -f alluxio-cluster.yaml
alluxiocluster.k8s-operator.alluxio.com/alluxio-cluster configured

# 监控滚动升级过程
$ kubectl -n alx-ns get pod
NAME                                          READY   STATUS     RESTARTS   AGE
alluxio-cluster-coordinator-0                 0/1     Init:0/2   0          7s
...
alluxio-cluster-worker-58999f8ddd-cd6r2       0/1     Init:0/2   0          7s
alluxio-cluster-worker-5d6786f5bf-cxv5j       1/1     Running    0          10m

# 检查集群状态，直到其返回 'Ready'
$ kubectl -n alx-ns get alluxiocluster
NAME              CLUSTERPHASE   AGE
alluxio-cluster   Updating       10m
...
NAME              CLUSTERPHASE   AGE
alluxio-cluster   Ready          12m

# 验证新版本是否正在运行
$ kubectl -n alx-ns exec -it alluxio-cluster-coordinator-0 -- alluxio info version 2>/dev/null
AI-3.7-13.0.0

在滚动升级过程中，worker 会分批重启，即当前批次中的工作进程必须完全准备就绪后才能启动下一个批次。默认批次大小为 worker 总数的 10%。

可以减少批次中的 worker 数量，以最大程度地减少期间对正在运行的工作负载的中断，但代价是延长升级周期。要控制比例或设置需要重启的具体 worker 数量，请在 alluxio-cluster.yaml 文件中进行以下设置：

apiVersion: k8s-operator.alluxio.com/v1
kind: AlluxioCluster
spec:
  worker:
    rollingUpdate:
      maxUnavailable: 1  # 默认情况下是 10%，但除了设置百分比值外，还可以设置为精确数字

动态更新配置

您可以通过编辑其 ConfigMap 来更改正在运行的集群中的 Alluxio 属性。

找到您的集群的 ConfigMap。

$ kubectl -n alx-ns get configmap
NAME                              DATA   AGE
alluxio-cluster-alluxio-conf      4      7m48s
...

编辑 ConfigMap 以修改 alluxio-site.properties、alluxio-env.sh 等。
```
$ kubectl -n alx-ns edit configmap alluxio-cluster-alluxio-conf
```
重新启动组件 以应用更改。
- Coordinator: kubectl -n alx-ns rollout restart statefulset alluxio-cluster-coordinator
- Workers: kubectl -n alx-ns rollout restart deployment alluxio-cluster-worker
- DaemonSet FUSE: kubectl -n alx-ns rollout restart daemonset alluxio-fuse
- CSI FUSE: 这些 pod 必须通过退出应用程序 pod 或手动删除 FUSE pod 来重新启动（kubectl -n alx-ns delete pod <fuse-pod-name>）。

2. 哈希环管理

重要提示： 哈希环设置应在初始集群设置期间定义。在正在运行的集群上修改这些配置是一项破坏性操作，将导致所有缓存数据丢失，因为它会更改数据到工作节点的映射方式。

Alluxio 使用一致性哈希环以去中心化的方式将数据映射到 worker。您可以微调其行为，以针对不同的集群环境和工作负载进行优化。

配置哈希环模式

一致性哈希环可以以两种模式运行：动态（默认）或静态。

在 动态模式 下，哈希环仅包含在线的 worker。当一个 worker 下线时，它会从环中移除，其虚拟节点也会被重新分配。这是大多数用例的理想选择，提供了高适应性。

在 静态模式 下，哈希环包含所有已注册的 worker，无论其在线状态如何。当您需要所有 worker 的一致视图以最小化从 UFS 重新获取数据时，即使某些 worker 暂时不可用，此模式也很有用。

要配置模式，请设置 alluxio.user.dynamic.consistent.hash.ring.enabled 属性。将其设置为 true 表示动态模式（默认值），设置为 false 表示静态模式。

调整虚拟节点以实现负载均衡

为确保数据和 I/O 请求的均匀分布，Alluxio 使用虚拟节点。每个 worker 都映射到哈希环上的多个虚拟节点，这有助于在集群中更有效地平衡负载。

您可以通过配置 alluxio.user.worker.selection.policy.consistent.hash.virtual.node.count.per.worker 属性（默认值：2000）来调整每个 worker 的虚拟节点数。调整此值有助于微调负载分布，尤其是在具有不同工作负载或少量 worker 的集群中。

针对异构 Worker 进行优化

默认情况下，一致性哈希算法假定所有 worker 都具有相同的容量。在具有异构 worker（例如，不同的存储容量或网络速度）的集群中，您可以启用基于容量的分配，以实现更均衡的资源利用。这确保了具有更多存储空间的 worker 能处理相应更大部分的数据。

要启用此功能，请将 alluxio.user.worker.selection.policy.consistent.hash.provider.impl 属性设置为 CAPACITY。默认值为 DEFAULT，它为每个 worker 分配相同数量的虚拟节点。

3. Worker 管理

Alluxio 的去中心化架构依赖于通过一致性哈希环管理的 worker。

检查 Worker 状态

要查看所有已注册 worker 及其当前状态（在线或离线）的列表：

bin/alluxio info nodes

添加新 Worker

要向集群添加新 worker：

在新节点上安装 Alluxio 软件。
确保 alluxio-site.properties 文件配置为指向您的 etcd 集群。
启动 worker 进程。它将自动在 etcd 中注册自己并加入一致性哈希环。

永久移除 Worker

如果您需要永久停用一个 worker：

在目标节点上关闭 worker 进程。
通过运行 bin/alluxio info nodes 获取 Worker ID。

使用其 ID 移除 worker。

bin/alluxio process remove-worker -n <worker_id>

再次运行 bin/alluxio info nodes 验证移除。

重要提示： 移除 worker 是一个永久性操作，将导致其哈希环部分被重新分配，可能会导致缓存未命中率暂时增加。

重启 Worker

如果您为维护而重启一个 worker，它将被暂时标记为离线。只要其身份被保留（通过 alluxio.worker.identity.uuid.file.path），它将重新加入集群，其缓存数据将保持完整并可用。

4. UFS 挂载管理

Alluxio 的统一命名空间允许您将多个底层存储系统（UFS）挂载到一个逻辑视图中。管理这些连接的挂载表存储在 etcd 中以实现高可用性。Alluxio 组件会定期轮询 etcd 以获取最新的挂载表，因此任何更改都会自动在整个集群中传播。

管理挂载点

使用 UnderFileSystem 的配置来管理 UFS 挂载。要增加新的挂载，请参阅连接到存储指南。

列出挂载：

# 你也可以使用Kubernetes命令行工具列出所有提交的配置
$ kubectl -n alx-ns get ufs
NAME         PHASE   AGE
alluxio-s3   Ready   13d

移除挂载：

$ kubectl -n alx-ns delete ufs alluxio-s3
underfilesystem.k8s-operator.alluxio.com "alluxio-s3" deleted

配置 UFS 凭据

您可以为 UFS 提供全局凭据或按挂载提供凭据。

全局配置： 在 alluxio-site.properties 中为某种类型的所有挂载（例如，所有 S3 挂载）设置属性。
```
# alluxio-site.properties
s3a.accessKeyId=<S3_ACCESS_KEY>
s3a.secretKey=<S3_SECRET_KEY>
```

按挂载配置（推荐）： 在挂载命令期间作为选项提供凭据。这是最灵活和安全的方法，非常适合连接到具有不同凭据的多个系统。按挂载选项会覆盖全局设置。

apiVersion: k8s-operator.alluxio.com/v1
kind: UnderFileSystem
metadata:
  name: alluxio-s3
  namespace: alx-ns
spec:
  alluxioCluster: alluxio-cluster
  path: s3://bucket-a/images
  mountPath: /s3-images
  mountOptions:
    s3a.accessKeyId: <S3_ACCESS_KEY_ID>
    s3a.secretKey: <S3_SECRET_KEY>

挂载规则

在定义命名空间时，您必须遵循两个重要规则，以确保挂载表有效且无歧义。

规则 1：挂载必须是根目录（`/`）的直接子级

您只能在 Alluxio 命名空间的顶层创建挂载点。您不能挂载到根路径（/）本身，也不能在不存在的目录中创建挂载点。

示例：

操作

Alluxio 路径

UFS 路径

有效？

原因

挂载存储桶

/s3-data

s3://my-bucket/

✔️ 是

挂载点是根目录的直接子级。

挂载到根目录

/

s3://my-bucket/

❌ 否

根路径不能是挂载点。

挂载到子路径

/data/images

s3://my-bucket/images/

❌ 否

挂载点不能在子目录中创建。

规则 2：挂载不能嵌套

一个挂载点不能创建在另一个挂载点内部，无论是在 Alluxio 命名空间还是在 UFS 命名空间中。例如，如果 /data 挂载到 s3://my-bucket/data，您不能在 /data/tables 创建新挂载（嵌套的 Alluxio 路径），也不能将另一个 UFS 挂载到 s3://my-bucket/data/tables（嵌套的 UFS 路径）。

示例场景：

假设您有一个现有的挂载点：

Alluxio 路径： /data
UFS 路径： s3://my-bucket/data

以下新挂载将是无效的：

新 Alluxio 路径

新 UFS 路径

有效？

拒绝原因

/data/tables

hdfs://namenode/tables

❌ 否

Alluxio 路径 /data/tables 嵌套在现有的 /data 挂载中。

/tables

s3://my-bucket/data/tables

❌ 否

UFS 路径 s3://.../data/tables 嵌套在现有的 s3://.../data 挂载中。

5. 多租户和联邦

对于大规模企业部署，Alluxio 提供了多租户和集群联邦的高级功能。这允许多个团队和业务部门安全高效地共享数据基础设施，同时简化管理开销。

下面的参考架构展示了一个 API 网关，它集中处理多个 Alluxio 集群的身份验证和授权。

核心概念

身份验证

Alluxio 与外部企业身份提供商（如 Okta）集成。当用户登录时，提供商会对其进行身份验证并生成一个 JSON Web Token (JWT)。此 JWT 随后会与每个后续请求一起发送到 Alluxio API 网关，以验证用户身份。

授权

一旦用户通过身份验证，Alluxio 会使用外部策略引擎 Open Policy Agent (OPA) 来确定用户有权执行哪些操作。管理员可以在 OPA 的声明性语言 Rego 中编写细粒度的访问控制策略，以控制哪些用户可以访问哪些资源。API 网关会为每个请求查询 OPA，以确保其已获授权。

多租户和隔离

Alluxio 在租户之间强制隔离，以确保安全并防止干扰。这是通过以下方式实现的：

用户角色： 定义具有特定访问级别和权限的不同角色。
缓存隔离： 分配特定于租户的缓存配置，包括配额、TTL 和驱逐策略，确保一个租户的工作负载不会对另一个租户产生负面影响。

集群联邦

对于拥有多个 Alluxio 集群（例如，跨不同区域或为不同业务部门）的组织，联邦简化了管理。中央管理控制台提供了一个单一的管理界面，用于：

跨集群监控和指标。
同时在多个集群上执行操作。
所有集群的集中式许可证管理。

示例工作流：更新缓存策略

此工作流演示了各组件如何协同工作：

身份验证： 用户登录到管理控制台，该控制台将他们重定向到 Okta 进行身份验证。成功后，Okta 会颁发一个 JWT。
请求提交： 用户使用控制台提交更改缓存 TTL 的请求。包含 JWT 的请求被发送到 API 网关。
授权： API 网关验证 JWT 并查询 OPA 策略引擎，以检查用户是否有权修改目标租户的缓存设置。
执行： 如果请求获得授权，API 网关会将命令转发到相关 Alluxio 集群的协调器，后者随后应用新的 TTL 策略。

Last updated 4 days ago