Alluxio Enterprise AI on K8s 部署视频教程
视频为Alluxio Enterprise AI on K8s 部署视频教程。下面内容将主要介绍如何通过 Operator（Kubernetes 管理应用程序的扩展）在 Kubernetes 上安装 Alluxio。
1. 系统要求
- Kubernetes
- 至少1.19版本的 Kubernetes 集群，支持特性门控
- 确保集群的 Kubernetes 网络策略允许应用程序（Alluxio 客户端）与定义端口上的 Alluxio Pods 之间建立连接
- Kubernetes 集群已安装至少3.6.0版本的 Helm 3
- 用于存储和管理容器镜像的镜像仓库
- 硬件
- 每个节点至少 8个 CPU 和 32GB 内存
- 每个节点至少100GB 的存储空间
- 权限。参考：使用 RBAC 授权
- 创建 CRD（自定义资源定义）的权限
- 为 Operator Pod 创建 ServiceAccount、ClusterRole 和 ClusterRoleBinding 的权限
- 创建 operator 所在命名空间的权限
2. 准备
2.1 下载 Alluxio operator 和 Alluxio 集群的安装包
请进入 Alluxio下载页面，选择 Alluxio Enterprise AI 进行下载，下载完成后解压文件。
$ tar zxf alluxio-enterprise-k8s-ai-trial.tar.gz
解压后可以得到以下文件：
alluxio-operator-2.0.0-helmchart.tgz是部署 Alluxio operator 的 helm chartalluxio-operator-2.0.0-docker.tar是 Alluxio operator 的 docker 镜像alluxio-enterprise-AI-3.3-7.0.0-docker.tar是 Alluxio 的 docker 镜像
2.2 将镜像上传到镜像仓库
镜像仓库是存储和共享容器镜像的中心化位置。镜像仓库可以是公共的，也可以是私有的。云服务提供商会提供容器镜像仓库服务作为其云服务的一部分，
包括 Amazon Elastic Container Registry(ECR)、
Azure Container Registry(ACR)
和 Google Container Registry(GCR)。
您甚至可以在本地系统或组织内部运行私有镜像仓库。
以下示例展示了如何上传 Alluxio operator 镜像。
# 加载镜像到本地
$ docker load -i alluxio-operator-2.0.0-docker.tar
$ docker load -i alluxio-enterprise-AI-3.3-7.0.0-docker.tar
# 将镜像更改为私有镜像仓库
$ docker tag alluxio/operator:2.0.0 <YOUR.PRIVATE.REGISTRY.HERE>/alluxio-operator:2.0.0
$ docker tag alluxio/alluxio-enterprise:AI-3.3-7.0.0 <YOUR.PRIVATE.REGISTRY.HERE>/alluxio-enterprise:AI-3.3-7.0.0
# 上传镜像到私有镜像仓库
$ docker push <YOUR.PRIVATE.REGISTRY.HERE>/alluxio-operator:2.0.0
$ docker push <YOUR.PRIVATE.REGISTRY.HERE>/alluxio-enterprise:AI-3.3-7.0.0
2.3 为 operator 解压 helm chart
# 将文件解压到目录 alluxio-operator
$ tar zxf alluxio-operator-2.0.0-helmchart.tgz
解压后生成的 alluxio-operator 就是负责部署 operator 的 helm chart 文件
3. 部署
3.1 部署 Alluxio operator
创建 alluxio-operator/alliuxio-operator.yaml 文件指定镜像和版本，用于部署 operator。
以下示例展示了如何指定 operator 和 csi 镜像和版本：
global:
image: <YOUR.PRIVATE.REGISTRY.HERE>/alluxio-operator
imageTag: 2.0.0
进入到 alluxio-operator 目录，执行以下命令部署 operator：
$ cd alluxio-operator
# 最后一个参数表示是 helm chart 文件的路径，"." 表示当前目录
$ helm install operator -f alluxio-operator.yaml .
NAME: operator
LAST DEPLOYED: Wed May 15 17:32:34 2024
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST SUITE: None
# 确认 operator 是否正常运行
$ kubectl get pod -n alluxio-operator
NAME READY STATUS RESTARTS AGE
alluxio-cluster-controller-5647cc664d-lrx84 1/1 Running 0 14s
alluxio-collectinfo-controller-667b746fd6-hfzqk 1/1 Running 0 14s
alluxio-csi-controller-7bd66df6cf-7kh6k 2/2 Running 0 14s
alluxio-csi-nodeplugin-9cc9v 2/2 Running 0 14s
alluxio-csi-nodeplugin-fgs5z 2/2 Running 0 14s
alluxio-csi-nodeplugin-v22q6 2/2 Running 0 14s
alluxio-ufs-controller-5f6d7c4d66-drjgm 1/1 Running 0 14s
部署 alluxio operator 需要从公共镜像仓库拉取依赖镜像，
如果您因为网络环境无法访问公共镜像仓库导致部署alluxio-operator失败，
请参考本文【 7.3.1 alluxio-operator 镜像 】章节。
3.2 部署 Alluxio
创建 alluxio-operator/alluxio-cluster.yaml , 用于部署 Alluxio 集群。下面的文件展示了最简配置。
.spec.properties 字段中的属性将通过一个 alluxio-site.properties 配置文件传递给 Alluxio 进程。
以下是翻译后的内容：
指定在
.spec.properties字段下的配置项将会被附加到alluxio-site.properties配置文件中，
Alluxio 进程会读取该文件。你可以在 Alluxio 的 coordinator 和 worker pod 中，
通过查看/opt/alluxio/conf/alluxio-site.properties找到你的配置。
operator 已经默认设置了推荐的配置，这些配置足以启动一个 Alluxio 集群。如果你需要修改配置，
可以编辑alluxio-cluster.yaml文件中的.spec.properties字段。
apiVersion: k8s-operator.alluxio.com/v1
kind: AlluxioCluster
metadata:
name: alluxio
spec:
image: <YOUR.PRIVATE.REGISTRY.HERE>/alluxio-enterprise
imageTag: AI-3.3-7.0.0
properties:
worker:
count: 2
pagestore:
size: 100Gi
- 如果您的训练数据存储在 S3，OSS 等存储中，训练程序可以通过
s3://或者oss://的方式访问到训练数据，
您可以在启动 Alluxio 集群之后通过创建 UFS 资源，实现将底层存储挂载到 Alluxio 中，从而对训练加速。 - 如果您的训练程序是通过 PVC 或者 NAS 的方式访问训练数据，
那么您需要在创建 Alluxio 集群时将训练数据的 PVC 或者 NAS 挂载到 Alluxio pod 中，
请参考本文【 3.3 将底层存储挂载到Alluxio 】章节中的 PVC 或者 NAS/hostPath，
修改alluxio-operator/alluxio-cluster.yaml。
执行以下命令创建 Alluxio 集群：
$ cd alluxio-operator
$ kubectl create -f alluxio-cluster.yaml
alluxiocluster.k8s-operator.alluxio.com/alluxio created
# 集群正在创建，查看集群中组件的状态
$ kubectl get pod
NAME READY STATUS RESTARTS AGE
alluxio-coordinator-0 0/1 Init:0/1 0 7s
alluxio-etcd-0 0/1 ContainerCreating 0 7s
alluxio-etcd-1 0/1 ContainerCreating 0 7s
alluxio-etcd-2 0/1 ContainerCreating 0 7s
alluxio-monitor-grafana-847fd46f4b-84wgg 0/1 Running 0 7s
alluxio-monitor-prometheus-778547fd75-rh6r6 1/1 Running 0 7s
alluxio-worker-76c846bfb6-2jkmr 0/1 Init:0/2 0 7s
alluxio-worker-76c846bfb6-nqldm 0/1 Init:0/2 0 7s
# 检查集群的状态
$ kubectl get alluxiocluster
NAME CLUSTERPHASE AGE
alluxio Ready 2m18s
# 集群准备就绪后，可以查看集群中的 pod
$ kubectl get pod
NAME READY STATUS RESTARTS AGE
alluxio-coordinator-0 1/1 Running 0 2m3s
alluxio-etcd-0 1/1 Running 0 2m3s
alluxio-etcd-1 1/1 Running 0 2m3s
alluxio-etcd-2 1/1 Running 0 2m3s
alluxio-monitor-grafana-7b9477d66-mmcc5 1/1 Running 0 2m3s
alluxio-monitor-prometheus-78dbb89994-xxr4c 1/1 Running 0 2m3s
alluxio-worker-85fd45db46-c7n9p 1/1 Running 0 2m3s
alluxio-worker-85fd45db46-sqv2c 1/1 Running 0 2m3s
在 Alluxio 3.x 中，coordinator 是一个无状态的控制组件，用于托管如分布式加载这样的任务，以及作为 operator 调用 API 的 gateway。
如果集群中的有些组件状态无法达到
Running状态，可以通过kubectl describe pod查看详细信息，找到问题所在。
部署过程中遇到的具体问题，可以参考本文【 7.常见问题 】章节。
注意：etcd需要配置
storageClass字段。不同云厂商的容器服务提供不同的storage class类型。如何配置，详见【 7.常见问题 】章节，如果不清楚当前云厂商容器服务的storage class类型。请执行kubectl get sc查看
启动 Alluxio 集群还包括 etcd 和监控组件，如果无法从公共镜像仓库拉取镜像导致 etcd 和监控启动失败，请参考本文【 7.3.2 配置Alluxio集群镜像 】章节
3.3 将底层存储挂载到 Alluxio
Alluxio 支持对接多种底层存储，包括 S3、HDFS、OSS、COS 和 TOS 等。
请参考存储集成概述
通过 operator 我们可以通过创建 UnderFileSystem 资源来挂载底层存储。一个 UnderFileSystem 资源对应 Alluxio 中的一个挂载点。
关于 Alluxio 以及底层存储命名空间，
请参考Alluxio 命名空间和底层文件系统命名空间
下面我们提供了几种常用的底层存储挂载示例。
3.3.1 S3挂载示例
创建 alluxio-operator/ufs.yaml，示例将挂载现有的 S3 路径到 Alluxio。
apiVersion: k8s-operator.alluxio.com/v1
kind: UnderFileSystem
metadata:
name: alluxio-s3
spec:
alluxioCluster: alluxio
path: s3://my-bucket/path/to/mount
mountPath: /s3
mountOptions:
s3a.accessKeyId: xxx
s3a.secretKey: xxx
alluxio.underfs.s3.region: us-east-1
将 S3 挂载到 Alluxio 的详细信息请参考Amazon AWS S3
3.3.2 OSS挂载示例
创建 alluxio-operator/ufs.yaml，示例将挂载现有的 OSS 路径到 Alluxio。
apiVersion: k8s-operator.alluxio.com/v1
kind: UnderFileSystem
metadata:
name: alluxio-oss
spec:
alluxioCluster: alluxio
path: oss://<OSS_BUCKET>/<OSS_DIRECTORY>
mountPath: /oss
mountOptions:
fs.oss.accessKeyId: <OSS_ACCESS_KEY>
fs.oss.accessKeySecret: <OSS_ACCESS_KEY_SECRET>
fs.oss.endpoint: <OSS_ENDPOINT>
将阿里云 OSS 挂载到 Alluxio 的详细信息请参考阿里云 OSS
3.3.3 NAS挂载示例
为了让 Alluxio pod 可以访问到 NAS 存储，您需要先将 NAS 挂载到节点的路径上。
Alluxio operator 支持将节点本地路径挂载到 Alluxio pod 中。
首先需要在创建 Alluxio 集群之前，在 alluxio-operator/alluxio-cluster.yaml 中增加挂载路径，
启动 Alluxio 集群时，会将这些路径挂载到 Alluxio 组件中。
apiVersion: k8s-operator.alluxio.com/v1
kind: AlluxioCluster
metadata:
name: alluxio
spec:
image: <YOUR.PRIVATE.REGISTRY.HERE>/alluxio-enterprise
imageTag: AI-3.3-7.0.0
hostPaths:
coordinator:
/mnt/nas: /ufs/data
worker:
/mnt/nas: /ufs/data
fuse:
/mnt/nas: /ufs/data
properties:
worker:
count: 2
pagestore:
size: 100Gi
- 键是节点上的宿主机路径，值是容器中的挂载路径。
- 如果使用 NAS 作为 UFS，则 coordinator, worker 和 FUSE 进程都需要挂载相同的路径，以便在发生任何错误时 FUSE 可以回退
创建 alluxio-operator/ufs.yaml，示例将挂载现有的 NAS 路径到 Alluxio。
apiVersion: k8s-operator.alluxio.com/v1
kind: UnderFileSystem
metadata:
name: alluxio-nfs
spec:
alluxioCluster: alluxio
path: file:///ufs/data
mountPath: /nfs
3.3.4 PVC挂载示例
原先，用户的训练任务通过挂载 PVC 到容器内的特定路径，从而可以读取任务数据。
具体而言，训练任务容器内的路径与 PVC 绑定，任务可以通过这个挂载路径访问数据。
现在，我们使用 Alluxio 来优化这一过程。部署 Alluxio 集群时，需要将之前用于存储训练数据的 PVC 挂载到 Alluxio 组件的容器内路径。
然后，再将 Alluxio 组件的容器内路径挂载到 Alluxio 集群中。通过这种方式，训练数据的 PVC 就被成功挂载到 Alluxio 集群中，
使得数据可以通过 Alluxio 的接口进行访问和处理。
首先在创建 Alluxio 集群之前，在 alluxio-cluster.yaml 中增加挂载路径，将原来训练数据的 PVC 挂载到 Alluxio 组件中的路径：
apiVersion: k8s-operator.alluxio.com/v1
kind: AlluxioCluster
metadata:
name: alluxio
spec:
image: <YOUR.PRIVATE.REGISTRY.HERE>/alluxio-enterprise
imageTag: AI-3.3-7.0.0
pvcMounts:
coordinator:
training-data-ufs-pvc: /ufs/data
worker:
training-data-ufs-pvc: /ufs/data
fuse:
training-data-ufs-pvc: /ufs/data
properties:
worker:
count: 2
pagestore:
size: 100Gi
- 键是 PVC，值是容器中的挂载路径。
- 如果使用 PVC 作为 UFS，则 coordinator, worker 和 FUSE 进程都需要挂载相同的路径，以便在发生任何错误时 FUSE 可以回退
创建 alluxio-operator/ufs.yaml，示例将挂载现有的 PVC 到 Alluxio。
apiVersion: k8s-operator.alluxio.com/v1
kind: UnderFileSystem
metadata:
name: alluxio-pvc
spec:
alluxioCluster: alluxio
path: file:///ufs/data
mountPath: /pvc
3.3.5 挂载操作
首先需要确认 Alluxio 集群已经启动，状态为 Ready。(或者状态为 WaitingForReady 也可以挂载 UFS)
# 检查集群的状态
$ kubectl get alluxiocluster
NAME CLUSTERPHASE AGE
alluxio Ready 2m18s
在创建 UnderFileSystem 资源后，执行以下命令将底层存储挂载到 Alluxio 命名空间：
$ cd alluxio-operator
$ kubectl create -f ufs.yaml
underfilesystem.k8s-operator.alluxio.com/alluxio-s3 created
# verify the status of the storage
$ kubectl get ufs
NAME PHASE AGE
alluxio-s3 Ready 46s
# also check the mount table via Alluxio command line
$ kubectl exec -it alluxio-coordinator-0 -- alluxio mount list 2>/dev/null
Listing all mount points
s3://my-bucket/path/to/mount on /s3/ properties={s3a.secretKey=xxx, alluxio.underfs.s3.region=us-east-1, s3a.accessKeyId=xxx}
4. 监控
部署 Alluxio 集群默认开启监控，通过 Grafana 可以直观地查看 Alluxio 各种指标，
请参考监控和指标中的 Kubernetes Operator 章节
5. 数据访问加速
上述步骤中，您部署了 Alluxio 集群，并将底层存储挂载到 Alluxio 中。训练任务通过 Alluxio 读取数据，可以提升训练速度和 GPU 利用率。
Alluxio 提供了3种数据访问方式：
- FUSE based POSIX API: 请参考 FUSE based POSIX API
- S3 API: 请参考 S3 API
- FSSpec Python API: 请参考 FSSPEC Python API
6. 常见用例
6.1 更改资源限制
对于每个组件，如 worker、coordinator 和 FUSE，我们都可以通过以下配置更改资源的使用量：
apiVersion: k8s-operator.alluxio.com/v1
kind: AlluxioCluster
spec:
worker:
resources:
limits:
cpu: "12"
memory: "36Gi"
requests:
cpu: "1"
memory: "32Gi"
jvmOptions:
- "-Xmx22g"
- "-Xms22g"
- "-XX:MaxDirectMemorySize=10g"
- 容器将永远无法访问超过限制的资源，这个请求限制会在调度过程中生效。如需了解更多信息，请参阅 为 Pod 和容器管理资源。
- 内存限制应略大于堆内存（
-Xmx）和直接内存（-XX:MaxDirectMemorySize=10g）的大小之和，以避免内存不足。
6.2 将 PVC 用于 page store
apiVersion: k8s-operator.alluxio.com/v1
kind: AlluxioCluster
spec:
pagestore:
type: persistentVolumeClaim
storageClass: ""
size: 100Gi
- PVC 由 operator 创建
storageClass默认为standard，但可以指定为空字符串进行静态绑定
6.3 挂载自定义映射配置
apiVersion: k8s-operator.alluxio.com/v1
kind: AlluxioCluster
spec:
configMaps:
custom-config-map: /etc/custom
- 键是
ConfigMap的名称，值是容器中的挂载路径 - 默认情况下，
/opt/alluxio/conf已被挂载。自定义配置映射需要挂载到其他路径
6.4 使用 root 用户
FUSE pod 将始终使用 root 用户。其他进程默认使用 uid 为1000的用户。在容器中，用户名为 alluxio。
要将其更改为 root 用户，请使用此配置：
apiVersion: k8s-operator.alluxio.com/v1
kind: AlluxioCluster
spec:
user: 0
group: 0
fsGroup: 0
- 如果文件可由 root 用户组访问，指定
.spec.fsGroup = 0即可。 - 如果将挂载主机路径（如页面存储路径和日志路径）的所有权更改为 root 用户，则其所有权将转移到 root。
6.5 支持的挂载选项
UnderFileSystem 配置中的 mountOptions 支持与 Alluxio 集群属性相同的设置。确切来说，使用不同存储时可使用以下属性
| UFS | Configuration | Description |
|---|---|---|
| S3 | s3a.accessKey | The access key of S3 bucket |
s3a.secretKey | The secret key of S3 bucket | |
alluxio.underfs.s3.region | Optionally, set the S3 bucket region. If not provided, will enable the global bucket access with extra requests |
7. 常见问题
7.1 etcd pod 一直处于 Pending 状态
比如三个 etcd pod 一直处于 Pending 状态，可以通过 kubectl describe pod 查看详细信息：
# 查看集群中的 pod 状态
kubectl get pod
NAME READY STATUS RESTARTS AGE
alluxio-coordinator-0 0/1 Init:1/2 0 73s
alluxio-etcd-0 0/1 Pending 0 73s
alluxio-etcd-1 0/1 Pending 0 73s
alluxio-etcd-2 0/1 Pending 0 73s
alluxio-monitor-grafana-79db8c7dd9-lsq2l 1/1 Running 0 73s
alluxio-monitor-prometheus-7c6cbc4b4c-9nk25 1/1 Running 0 73s
alluxio-worker-8c79d5fd4-2c994 0/1 Init:1/2 0 73s
alluxio-worker-8c79d5fd4-jrchj 0/1 Init:1/2 0 73s
# 查看 etcd pod 的详细信息
kubectl describe pod alluxio-etcd-0
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedScheduling 3m57s default-scheduler 0/3 nodes are available: pod has unbound immediate PersistentVolumeClaims. preemption: 0/3 nodes are available: 3 Preemption is not helpful for scheduling., .
# 查看集群中的 pvc 状态，发现 etcd 的 pvc 一直处于 Pending 状态（alluxio-alluxio-csi-fuse-pvc 处于 Pending 状态是正常现象）
kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
alluxio-alluxio-csi-fuse-pvc Pending alluxio-csi-storage-class 5m31s
data-alluxio-etcd-0 Pending 3h41m
data-alluxio-etcd-1 Pending 3h41m
data-alluxio-etcd-2 Pending 3h41m
可以看到 etcd pod 和 pvc 一直处于 Pending 状态，需要查看 etcd pvc 的详细信息。
下面展示了 etcd pvc 的详细信息，可以看到 pvc 绑定失败的原因是没有设置 storage class。
# 查看 etcd pvc 的详细信息
kubectl describe pvc data-alluxio-etcd-0
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal FailedBinding 4m16s (x889 over 3h44m) persistentvolume-controller no persistent volumes available for this claim and no storage class is set
可以通过在 alluxio-operator/alluxio-cluster.yaml 文件中指定 etcd 的 storageClass 来解决：
etcd:
persistence:
storageClass: <STORAGE.CLASS.HERE>
size:
我们需要先删除 Alluxio 集群, 并且删除 etcd 的 pvc，然后重新创建 Alluxio 集群：
# 删除 Alluxio 集群
$ kubectl delete -f alluxio-operator/alluxio-cluster.yaml
# 删除 etcd 的 pvc
$ kubectl delete pvc data-alluxio-etcd-0
$ kubectl delete pvc data-alluxio-etcd-1
$ kubectl delete pvc data-alluxio-etcd-2
# 重新创建 Alluxio 集群
$ kubectl create -f alluxio-operator/alluxio-cluster.yaml
另外一种情况是 etcd pvc 指定了 storage class，但是 etcd pod 和 pvc 依然是 pending 状态。例如下面的 pvc 详细信息中所展示，
etcd pvc 指定的 storage class 不支持动态制备，存储卷需要由集群管理员手动创建。
# 查看 etcd pvc 的详细信息
kubectl describe pvc data-alluxio-etcd-0
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal WaitForFirstConsumer 25s persistentvolume-controller waiting for first consumer to be created before binding
Normal ExternalProvisioning 8s (x3 over 25s) persistentvolume-controller Waiting for a volume to be created either by the external provisioner 'none' or manually by the system administrator. If volume creation is delayed, please verify that the provisioner is running and correctly registered.
类似的 etcd pod 一直处于 Pending 状态的问题，可以通过上述方法进行排查。如果您只是进行部署验证，同时当前没有方便的 storage class 供集群使用，您可以关闭 etcd 的 persistence 配置，如下。注意该配置无法适用于生产，仅供验证测试使用
etcd:
persistence:
enabled: false
7.2 alluxio-alluxio-csi-fuse-pvc 一直处于 Pending 状态
当我们创建集群之后，发现 alluxio-alluxio-csi-fuse-pvc 一直处于 Pending 状态，
这是正常现象，当 alluxio-csi-fuse-pvc 被业务 pod 使用时，pvc 会自动绑定 pv，pvc 的状态会变为 Bound。
7.3 无法访问公共镜像仓库
7.3.1 配置 alluxio-operator 镜像
部署 alluxio operator 需要从公共镜像仓库拉取依赖镜像，如果您的网络环境无法访问公共镜像仓库，将会出现拉取镜像出现超时错误：
# 确认 operator 是否正常运行
$ kubectl get pod -n alluxio-operator
NAME READY STATUS RESTARTS AGE
alluxio-cluster-controller-65b59f65b4-5d667 1/1 Running 0 22s
alluxio-collectinfo-controller-667b746fd6-hfzqk 1/1 Running 0 22s
alluxio-csi-controller-c85f8f759-sqc56 0/2 ContainerCreating 0 22s
alluxio-csi-nodeplugin-5pgmg 0/2 ContainerCreating 0 22s
alluxio-csi-nodeplugin-fpkcq 0/2 ContainerCreating 0 22s
alluxio-csi-nodeplugin-j9wll 0/2 ContainerCreating 0 22s
alluxio-ufs-controller-5f69bbb878-7km58 1/1 Running 0 22s
可以发现 cluster controller、ufs controller 和 collectinfo controller 启动成功，
但是 csi controller 和 csi nodeplugin 一直在 ContainerCreating 状态，
这是因为拉取依赖镜像超时导致的。通过 kubectl describe pod 查看详细信息，可以看到类似如下的错误信息：
$ kubectl -n alluxio-operator describe pod -l app.kubernetes.io/component=csi-controller
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 10m default-scheduler Successfully assigned alluxio-operator/alluxio-csi-controller-c85f8f759-sqc56 to cn-beijing.10.0.0.252
Normal AllocIPSucceed 10m terway-daemon Alloc IP 10.0.0.27/24 took 28.443992ms
Normal Pulling 10m kubelet Pulling image "registry.xxx.com/alluxio/operator:2.0.0"
Normal Pulled 10m kubelet Successfully pulled image "registry.xxx.com/alluxio/operator:2.0.0" in 5.55s (5.55s including waiting)
Normal Created 10m kubelet Created container csi-controller
Normal Started 10m kubelet Started container csi-controller
Warning Failed 8m20s (x2 over 10m) kubelet Failed to pull image "registry.k8s.io/sig-storage/csi-provisioner:v2.0.5": failed to pull and unpack image "registry.k8s.io/sig-storage/csi-provisioner:v2.0.5": failed to resolve reference "registry.k8s.io/sig-storage/csi-provisioner:v2.0.5": failed to do request: Head "https://us-west2-docker.pkg.dev/v2/k8s-artifacts-prod/images/sig-storage/csi-provisioner/manifests/v2.0.5": dial tcp 142.251.8.82:443: i/o timeout
Warning Failed 8m20s (x3 over 10m) kubelet Error: ErrImagePull
Warning Failed 7m40s (x5 over 10m) kubelet Error: ImagePullBackOff
Warning Failed 6m56s (x2 over 9m19s) kubelet Failed to pull image "registry.k8s.io/sig-storage/csi-provisioner:v2.0.5": rpc error: code = DeadlineExceeded desc = failed to pull and unpack image "registry.k8s.io/sig-storage/csi-provisioner:v2.0.5": failed to resolve reference "registry.k8s.io/sig-storage/csi-provisioner:v2.0.5": failed to do request: Head "https://us-west2-docker.pkg.dev/v2/k8s-artifacts-prod/images/sig-storage/csi-provisioner/manifests/v2.0.5": dial tcp 64.233.187.82:443: i/o timeout
Normal Pulling 5m29s (x5 over 10m) kubelet Pulling image "registry.k8s.io/sig-storage/csi-provisioner:v2.0.5"
Normal BackOff 30s (x28 over 10m) kubelet Back-off pulling image "registry.k8s.io/sig-storage/csi-provisioner:v2.0.5"
您可以将依赖镜像下载到本地，上传到您的私有镜像仓库，然后修改 alluxio-operator.yaml 文件中的镜像地址，再重新部署 operator。
| 组件 | 镜像名 | 版本 | 用途 |
|---|---|---|---|
| operator 的 csi | registry.k8s.io/sig-storage/csi-node-driver-registrar | v2.0.0 | csi driver registrar 依赖 |
| operator 的 csi | registry.k8s.io/sig-storage/csi-provisioner | v2.0.5 | csi provisioner 依赖 |
| 集群的 etcd | docker.io/bitnami/etcd | 3.5.9-debian-11-r24 | etcd 依赖 |
| 集群的 etcd | docker.io/bitnami/os-shell | 11-debian-11-r2 | os-shell 依赖 |
| 集群的监控 | grafana/grafana | 10.4.5 | 监控展示 |
| 集群的监控 | prom/prometheus | v2.52.0 | 指标采集 |
拉取 docker 镜像并且上传到私有镜像仓库的命令如下：
# 拉取镜像到本地
$ docker pull registry.k8s.io/sig-storage/csi-node-driver-registrar:v2.0.0
$ docker pull registry.k8s.io/sig-storage/csi-provisioner:v2.0.5
$ docker pull docker.io/bitnami/etcd:3.5.9-debian-11-r24
$ docker pull docker.io/bitnami/os-shell:11-debian-11-r2
$ docker pull grafana/grafana:10.4.5
$ docker pull prom/prometheus:v2.52.0
# 将镜像更改为私有镜像仓库
$ docker tag registry.k8s.io/sig-storage/csi-node-driver-registrar:v2.0.0 <YOUR.PRIVATE.REGISTRY.HERE>/csi-node-driver-registrar:v2.0.0
$ docker tag registry.k8s.io/sig-storage/csi-provisioner:v2.0.5 <YOUR.PRIVATE.REGISTRY.HERE>/csi-provisioner:v2.0.5
$ docker tag docker.io/bitnami/etcd:3.5.9-debian-11-r24 <YOUR.PRIVATE.REGISTRY.HERE>/etcd:3.5.9-debian-11-r24
$ docker tag docker.io/bitnami/os-shell:11-debian-11-r2 <YOUR.PRIVATE.REGISTRY.HERE>/os-shell:11-debian-11-r2
$ docker tag grafana/grafana:10.4.5 <YOUR.PRIVATE.REGISTRY.HERE>/grafana:10.4.5
$ docker tag prom/prometheus:v2.52.0 <YOUR.PRIVATE.REGISTRY.HERE>/prometheus:v2.52.0
# 上传镜像到私有镜像仓库
$ docker push <YOUR.PRIVATE.REGISTRY.HERE>/csi-node-driver-registrar:v2.0.0
$ docker push <YOUR.PRIVATE.REGISTRY.HERE>/csi-provisioner:v2.0.5
$ docker push <YOUR.PRIVATE.REGISTRY.HERE>/etcd:3.5.9-debian-11-r24
$ docker push <YOUR.PRIVATE.REGISTRY.HERE>/os-shell:11-debian-11-r2
$ docker push <YOUR.PRIVATE.REGISTRY.HERE>/grafana:10.4.5
$ docker push <YOUR.PRIVATE.REGISTRY.HERE>/prometheus:v2.52.0
更改 alluxio-operator/alliuxio-operator.yaml 文件中的镜像地址，增加 provisioner 和 driverRegistrar 的镜像地址：
global:
image: <YOUR.PRIVATE.REGISTRY.HERE>/alluxio-operator
imageTag: 2.0.0
alluxio-csi:
controllerPlugin:
provisioner:
image: <YOUR.PRIVATE.REGISTRY.HERE>/csi-provisioner:v2.0.5
nodePlugin:
driverRegistrar:
image: <YOUR.PRIVATE.REGISTRY.HERE>/csi-node-driver-registrar:v2.0.0
进入到 alluxio-operator 目录，执行以下命令部署 operator：
$ cd alluxio-operator
# 最后一个参数表示是 helm chart 文件的路径，"." 表示当前目录
$ helm install operator -f alluxio-operator.yaml .
NAME: operator
LAST DEPLOYED: Wed May 15 17:32:34 2024
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST SUITE: None
# 确认 operator 是否正常运行
$ kubectl get pod -n alluxio-operator
NAME READY STATUS RESTARTS AGE
alluxio-cluster-controller-5647cc664d-lrx84 1/1 Running 0 14s
alluxio-collectinfo-controller-667b746fd6-hfzqk 1/1 Running 0 14s
alluxio-csi-controller-7bd66df6cf-7kh6k 2/2 Running 0 14s
alluxio-csi-nodeplugin-9cc9v 2/2 Running 0 14s
alluxio-csi-nodeplugin-fgs5z 2/2 Running 0 14s
alluxio-csi-nodeplugin-v22q6 2/2 Running 0 14s
alluxio-ufs-controller-5f6d7c4d66-drjgm 1/1 Running 0 14s
7.3.2 配置 Alluxio 集群镜像
启动 Alluxio 集群还包括 etcd 和监控组件，如果无法访问公共镜像仓库，需要将 etcd 和监控组件的镜像地址替换成私有镜像仓库，修改alluxio-operator/alluxio-cluster.yaml文件中的镜像地址。
apiVersion: k8s-operator.alluxio.com/v1
kind: AlluxioCluster
metadata:
name: alluxio
spec:
image: <YOUR.PRIVATE.REGISTRY.HERE>/alluxio-enterprise
imageTag: AI-3.3-7.0.0
properties:
worker:
count: 2
pagestore:
size: 100Gi
etcd:
image:
registry: <YOUR.PRIVATE.REGISTRY.HERE>
repository: <YOUR.PRIVATE.REPOSITORY.HERE>/etcd
tag: 3.5.9-debian-11-r24
volumePermissions:
image:
registry: <YOUR.PRIVATE.REGISTRY.HERE>
repository: <YOUR.PRIVATE.REPOSITORY.HERE>/os-shell
tag: 11-debian-11-r2
persistence:
storageClass: <STORAGE.CLASS.HERE>
size:
alluxio-monitor:
prometheus:
image: <YOUR.PRIVATE.REGISTRY.HERE>/prometheus
imageTag: v2.52.0
grafana:
image: <YOUR.PRIVATE.REGISTRY.HERE>/grafana
imageTag: 10.4.5
