拓冰网站定制 
存储分布式文件系统缓存大数据【免费下载链接】alluxioAlluxio, data orchestration for analytics and machine learning in the cloud项目地址https://gitcode.com/gh_mirrors/al/alluxio点击查看免费下载本篇指南以 Alluxio 官方中文部署文档为主体完整演示如何在 Kubernetes 集群上通过helm推荐或原生kubectl规范运行 Alluxio覆盖先决条件、日志持久化、分层存储、短路访问、POSIX API、升级与故障排查。读完本文你将能够独立完成 Alluxio 在 Kubernetes 上的生产级部署并理解 Helm Chart 中各配置项在 integration/kubernetes/helm-chart/alluxio/values.yaml 与模板中的实际映射关系。先决条件在开始部署前需要准备以下环境一个 Kubernetes 集群版本 1.8。在默认规范下Alluxio workers 通过sizeLimit参数决定emptyDir卷的大小这是 Kubernetes 1.8 版本中的 Alpha 特性使用前请确保该特性已启用。一个可访问的 Alluxio Docker 镜像。仓库的 Helm Chart 默认使用alluxio/alluxio镜像镜像标签对应各版本。如果使用私有 Docker 注册表请参阅 Kubernetes 私有镜像仓库拉取相关文档。确保集群的 Kubernetes 网络策略允许应用程序Alluxio 客户端与 Alluxio Pods 之间在已定义端口上的连接。基本设置两种部署方式总览Alluxio 支持两种 Kubernetes 安装方式使用 Helm Chart首选当环境允许时推荐通过helm安装配置集中在单个config.yaml中便于版本化管理与回滚。使用kubectl原生资源规范当无法使用helm或需要更细粒度的自定义部署时可以直接基于 Kubernetes YAML 模板部署。注意从 Alluxio 2.3 起Alluxio 仅支持 Helm 3。如需从 Helm 2 迁移请参考 Helm 官方的 v2→v3 迁移文档。可选从 Docker 镜像提取 Kubernetes 规范如果使用私有 Helm 仓库或打算使用原生 Kubernetes 规范可以先将部署所需的 Kubernetes 规范从 Docker 镜像中提取出来本仓库的模板源头即 integration/kubernetes/helm-chart/alluxio 下的 Helm Chart$ id$(docker create alluxio/alluxio:version) $ docker cp $id:/opt/alluxio/integration/kubernetes/ - kubernetes.tar $ docker rm -v $id 1/dev/null $ tar -xvf kubernetes.tar $ cd kubernetes可选发放持久卷Persistent Volume日志是 Alluxio master 最关键的状态。根据部署配置的不同通常需要为 master 发放持久卷嵌入式日志Embedded JournalAlluxio 运行在 Kubernetes 上的首选 HA 机制。需要为每个要发放的 master Pod 设置一个持久卷。一旦创建了该卷即使 master 进程重启也不会影响持久卷的内容。相关细节可参考 Journal 文档。UFS 日志UFS JournalAlluxio master 也可以配置为使用持久卷存储日志。如果使用 UFS 日志且日志位置在外部如 HDFS可以跳过本节剩余部分。下面是一个用hostPath定义的持久卷示例保存为alluxio-master-journal-pv.yamlkind: PersistentVolume apiVersion: v1 metadata: name: alluxio-journal-0 labels: type: local spec: storageClassName: standard capacity: storage: 1Gi accessModes: - ReadWriteOnce hostPath: path: /tmp/alluxio-journal-0然后使用kubectl创建持久卷$ kubectl create -f alluxio-master-journal-pv.yaml注意默认每个日志卷应至少为 1Gi因为每个 Alluxio master Pod 会有一个请求 1Gi 存储的 PersistentVolumeClaim后文会介绍如何设置日志大小。从源码看master/statefulset.yaml 中通过volumeClaimTemplates为每个 master 动态申请alluxio-journal卷storageClassName、accessModes与storage大小均直接取自values.yaml中的journal段当journal.volumeType为emptyDir时则改用带sizeLimit的emptyDir卷。部署方式一Helm 安装前提条件安装 Helm 3.X安装方式见 Helm 官方文档。添加包含 Alluxio Helm Chart 的仓库$ helm repo add alluxio-charts https://alluxio-charts.storage.googleapis.com/openSource/version最小配置一旦 Helm 仓库可用即可准备 Alluxio 配置。最小配置必须包含底层存储地址properties: alluxio.master.mount.table.root.ufs: under_storage_address注意底层文件系统地址必须修改。任何涉及凭据的配置也必须一并修改。要查看完整的支持属性列表运行$ helm inspect values alluxio-charts/alluxio常用配置示例以下示例均写入config.yaml通过-f config.yaml传入helm install。本节配置在 values.yaml 中均有对应的默认值与注释说明。示例一以 Amazon S3 作为底层存储要以根挂载点方式将 S3 挂载到 Alluxio 根命名空间参见 S3 文档在properties下以 key-value 形式指定所有必需属性properties: alluxio.master.mount.table.root.ufs: s3a://bucket alluxio.master.mount.table.root.option.s3a.accessKeyId: accessKey alluxio.master.mount.table.root.option.s3a.secretKey: secretKey示例二单 Master 持久卷日志以下配置使用 UFS 日志参见 Journal 文档 的 UFS journal 部分将一个持久卷本地挂载到 master Pod 的/journal位置master: count: 1 # 多 Master 模式下增加该值 1 journal: type: UFS # UFS 或 EMBEDDED 之一 ufsType: local # local 或 HDFSlocal 会为每个 Master Pod 分配 PV folder: /journal # master 日志目录 size: 1Gi # volumeType 控制日志卷类型可为 persistentVolumeClaim 或 emptyDir volumeType: persistentVolumeClaim # 当日志卷为 persistentVolumeClaim 时的属性 storageClass: standard accessModes: - ReadWriteOnce示例三单 Master emptyDir日志同样配置 UFS 日志但使用emptyDir卷master: count: 1 journal: type: UFS ufsType: local folder: /journal size: 1Gi volumeType: emptyDir # 当日志卷为 emptyDir 时的属性 medium: 注意emptyDir卷的寿命与 Pod 相同不是持久性存储。当 Pod 重启或被重新调度时Alluxio 日志将丢失请仅在实验场景中使用。示例四以 HDFS 作为日志存储首先为 HDFS 客户端所需的任何配置创建 Secrets它们将挂载在/secrets下$ kubectl create secret generic alluxio-hdfs-config --from-file${HADOOP_CONF_DIR}/core-site.xml --from-file${HADOOP_CONF_DIR}/hdfs-site.xmljournal: type: UFS ufsType: HDFS # HDFS 类型不会为 master 分配 PV folder: hdfs://hostname:hostport/journal properties: alluxio.master.mount.table.root.ufs: hdfs://ns alluxio.master.journal.ufs.option.alluxio.underfs.hdfs.configuration: /secrets/hdfsConfig/core-site.xml:/secrets/hdfsConfig/hdfs-site.xml secrets: master: alluxio-hdfs-config: hdfsConfig worker: alluxio-hdfs-config: hdfsConfig示例五多 Master 持久卷嵌入式日志Embedded Journalmaster: count: 3 journal: type: EMBEDDED folder: /journal volumeType: persistentVolumeClaim size: 1Gi storageClass: standard accessModes: - ReadWriteOnce从源码看config/alluxio-conf.yaml 会为多 master 嵌入式日志场景自动生成-Dalluxio.master.embedded.journal.addressesalluxio-master-0:19200,...的地址列表并在 master/statefulset.yaml 中通过ALLUXIO_MASTER_HOSTNAME环境变量注入 Pod 名HA 模式或 Pod IP单 master 模式这是嵌入式日志多节点互通的关键。示例六多 Master emptyDir嵌入式日志master: count: 3 journal: type: UFS ufsType: local folder: /journal size: 1Gi volumeType: emptyDir medium: 注意同上emptyDir卷与 Pod 同生命周期日志会随 Pod 重启丢失仅限实验使用。示例七以 HDFS 作为底层存储properties: alluxio.master.mount.table.root.ufs: hdfs://ns alluxio.master.mount.table.root.option.alluxio.underfs.hdfs.configuration: /secrets/hdfsConfig/core-site.xml:/secrets/hdfsConfig/hdfs-site.xml secrets: master: alluxio-hdfs-config: hdfsConfig worker: alluxio-hdfs-config: hdfsConfig示例八Off-heap Metastore 管理持久卷以下配置为每个 Alluxio master Pod 创建一个PersistentVolumeClaim并将 Pod 配置为使用该卷作为基于 RocksDB 的 on-disk metastoreproperties: alluxio.master.metastore: ROCKS alluxio.master.metastore.dir: /metastore metastore: volumeType: persistentVolumeClaim # 可选 persistentVolumeClaim 或 emptyDir size: 1Gi mountPath: /metastore storageClass: standard accessModes: - ReadWriteOnce示例九Off-heap Metastore 管理emptyDir卷properties: alluxio.master.metastore: ROCKS alluxio.master.metastore.dir: /metastore metastore: volumeType: emptyDir size: 1Gi mountPath: /metastore medium: 注意emptyDir卷与 Pod 同生命周期元数据会随 Pod 重启丢失仅限实验使用。示例十同时挂载多个 Secrets多个 Secrets 可以同时挂载到 master 和 worker Pods每个 Pod 区域的格式为secretName: mountPathsecrets: master: alluxio-hdfs-config: hdfsConfig alluxio-ceph-config: cephConfig worker: alluxio-hdfs-config: hdfsConfig alluxio-ceph-config: cephConfig示例十一Alluxio 存储分层存储管理Alluxio 在 worker Pods 上管理本地存储包括内存。多级存储Multiple-Tier Storage参见 Caching 文档可以通过以下参考配置设置。支持的 3 种卷类型type为hostPath、emptyDir和persistentVolumeClaim。仅内存级tieredstore: levels: - level: 0 mediumtype: MEM path: /dev/shm type: emptyDir high: 0.95 low: 0.7内存和 SSD 多级存储hostPathtieredstore: levels: - level: 0 mediumtype: MEM path: /dev/shm type: hostPath high: 0.95 low: 0.7 - level: 1 mediumtype: SSD path: /ssd-disk type: hostPath high: 0.95 low: 0.7注意如果在运行时创建了hostPath文件或目录只有root用户能使用。hostPath卷没有资源大小限制。可以以root权限运行 Alluxio 容器或者确保存在具有 UID 和 GID 1000 的alluxio用户可访问的本地路径。内存和 SSD 多级存储使用 PVCtieredstore: levels: - level: 0 mediumtype: MEM path: /dev/shm type: persistentVolumeClaim name: alluxio-mem quota: 1G high: 0.95 low: 0.7 - level: 1 mediumtype: SSD path: /ssd-disk type: persistentVolumeClaim name: alluxio-ssd quota: 10G high: 0.95 low: 0.7注意每一层有一个 PVC。当 PVC 绑定到类型为hostPath或local的 PV 时每个 worker Pod 都会使用 Node 上的本地路径。对于 worker 分层存储建议使用hostPath或local卷以便 worker 本地读写获得最佳性能。local卷需要nodeAffinity使用该卷的 Pod 只能运行在卷nodeAffinity规则指定的节点上。单级多卷存储内存 SSD 在同一层tieredstore: levels: - level: 0 mediumtype: MEM,SSD path: /dev/shm,/alluxio-ssd type: persistentVolumeClaim name: alluxio-mem,alluxio-ssd quota: 1GB,10GB high: 0.95 low: 0.7该配置会为每个卷创建一个persistentVolumeClaim。在 config/alluxio-conf.yaml 中tieredstore.levels会被转换为-Dalluxio.worker.tieredstore.levelsN、-Dalluxio.worker.tieredstore.level{n}.dirs.path、-Dalluxio.worker.tieredstore.level{n}.dirs.quota、-Dalluxio.worker.tieredstore.level{n}.watermark.high/low.ratio等 JVM 参数写入 ConfigMaphigh/low即高低水位线比例。安装完成名为config.yaml的配置文件后执行$ helm install alluxio -f config.yaml alluxio-charts/alluxio卸载$ helm delete alluxio格式化日志StatefulSet 中的 master Pods 在启动时使用initContainer格式化日志。该initContainer由journal.format.runFormattrue开启默认情况下 master 启动时日志不会被格式化参见 values.yaml 中journal.format.runFormat: false。可以通过升级现有 Helm 部署来触发日志格式化# 使用相同的 config.yaml 并打开日志格式化开关 $ helm upgrade alluxio -f config.yaml --set journal.format.runFormattrue alluxio-charts/alluxio注意helm upgrade将重新创建 master Pods。也可以在部署时直接触发日志格式化$ helm install alluxio -f config.yaml --set journal.format.runFormattrue alluxio-charts/alluxio从源码看master/statefulset.yaml 中的journal-formatinitContainer 使用command: [alluxio, formatJournal]并从alluxio-configConfigMap 注入环境变量同时挂载alluxio-journal卷到journal.folder保证格式化与 master 写入同一目录。部署方式二kubectl 原生部署选择 YAML 模板样例提取规范目录下的子目录包含一组常见部署方案的 YAML 模板singleMaster-localJournal、singleMaster-hdfsJournal和multiMaster-embeddedJournal。singleMaster表示模板生成 1 个 Alluxio master 进程multiMaster表示 3 个。embedded和ufs是 Alluxio 支持的两种日志模式参见 Journal 文档。singleMaster-localJournal提供必要的 Kubernetes ConfigMap、1 个 Alluxio master 进程和一组 Alluxio workers。master 将日志写入volumeClaimTemplates请求的日志卷中。multiMaster-embeddedJournal提供 Kubernetes ConfigMap、3 个 Alluxio masters 和一组 workers。每个 master 将日志写入由volumeClaimTemplates请求的自己的日志卷中。singleMaster-hdfsJournal提供 Kubernetes ConfigMap、1 个 Alluxio master 以及一组 workers。日志位于共享的 UFS 路径此模板中以 HDFS 作为 UFS。配置 ConfigMap确定部署选项后从相应子目录复制模板$ cp alluxio-configmap.yaml.template alluxio-configmap.yaml按需修改或添加任何配置属性。底层文件系统地址必须修改任何凭据也必须修改。在ALLUXIO_JAVA_OPTS中添加-Dalluxio.master.mount.table.root.ufsunder_storage_address注意用适当的 URI 替换under_storage_address例如s3://my-bucket。如果底层存储要求凭据请确保一并指定。使用主机网络运行 Alluxio 时分配给 Alluxio 服务的端口不得被预先占用。创建 ConfigMap$ kubectl create -f alluxio-configmap.yaml安装准备规范。基于模板准备 Alluxio 部署规范修改任何所需参数例如 Docker 镜像的位置以及 Pod 的 CPU 和内存要求。为 master(s) 创建Service和StatefulSet$ mv master/alluxio-master-service.yaml.template master/alluxio-master-service.yaml $ mv master/alluxio-master-statefulset.yaml.template master/alluxio-master-statefulset.yaml注意alluxio-master-statefulset.yaml使用volumeClaimTemplates为每个 master 定义日志卷如果需要的话。为 workers 创建DaemonSet$ mv worker/alluxio-worker-daemonset.yaml.template worker/alluxio-worker-daemonset.yaml注意请确保 Kubernetes 规范版本与所使用的 Alluxio Docker 镜像版本一致。可选远程存储访问当 Alluxio 需要连接到所部署 Kubernetes 集群之外的存储主机时可能需要额外步骤。以下说明如何配置可访问但不受 Kubernetes 管理的远程 HDFS 连接。步骤 1为 HDFS 连接添加hostAliases。Kubernetes Pods 无法识别不由 Kubernetes 管理的网络主机名因为不是 Kubernetes Service除非已通过hostAliases定义好。例如如果 HDFS 服务可通过hdfs://namenode:9000访问其中namenode是主机名则需要在spec中为所有 Alluxio Pod 添加hostAliases建立主机名到 IP 地址的映射spec: hostAliases: - ip: namenode_ip hostnames: - namenode对于alluxio-master-statefulset.yaml.template和alluxio-worker-daemonset.yaml.template模板hostAliases部分应添加到spec.template.spec中如下所示kind: StatefulSet metadata: name: alluxio-master spec: ... serviceName: alluxio-master replicas: 1 template: metadata: labels: app: alluxio-master spec: hostAliases: - ip: ip for hdfs-host hostnames: - hdfs-host步骤 2为 HDFS 配置文件创建 Kubernetes Secret。$ kubectl create secret generic alluxio-hdfs-config --from-file${HADOOP_CONF_DIR}/core-site.xml --from-file${HADOOP_CONF_DIR}/hdfs-site.xml这两个配置文件在alluxio-master-statefulset.yaml和alluxio-worker-daemonset.yaml中被引用。Alluxio 进程需要 HDFS 配置文件才能连接这些文件在容器中的位置由属性alluxio.underfs.hdfs.configuration控制。步骤 3修改alluxio-configmap.yaml.template。更新alluxio.master.journal.folder和alluxio.master.mount.table.root.ufs指向目标 HDFS 服务。部署完成所有先决条件和配置后部署 Alluxio$ kubectl create -f ./master/ $ kubectl create -f ./worker/卸载$ kubectl delete -f ./worker/ $ kubectl delete -f ./master/ $ kubectl delete configmap alluxio-config注意这将删除./master/和./worker/下的所有资源。如果这些目录下有想保留的持久卷或其他重要资源请注意不要误删。格式化日志kubectl可以手动添加一个initContainer在 Pod 创建时运行alluxio formatJournal以格式化日志- name: journal-format image: alluxio/alluxio:version imagePullPolicy: IfNotPresent securityContext: runAsUser: 1000 command: [alluxio,formatJournal] envFrom: - configMapRef: name: alluxio-config volumeMounts: - name: alluxio-journal mountPath: /journal注意从 Alluxio v2.1 及更高版本起默认 Alluxio Docker 容器Fuse 除外以非 root 用户alluxioUID 1000、GID 1000身份运行。请确保 Alluxio master Pod 的运行用户与日志格式化用户一致。升级kubectl本节介绍如何使用kubectl升级 Kubernetes 集群中的 Alluxio。步骤 1升级 Docker 镜像版本标签。每个 Alluxio 版本发布都会对应发布 Docker 镜像。更新所有 Alluxio 容器的image字段为目标版本标签标签latest指向最新的稳定版本containers: - name: alluxio-master image: alluxio/alluxio:latest imagePullPolicy: IfNotPresent ... - name: alluxio-job-master image: alluxio/alluxio:latest imagePullPolicy: IfNotPresent ...步骤 2停止运行中的 Alluxio master 和 worker Pods。通过删除 DaemonSet 终止所有 worker Pods$ kubectl delete daemonset -l appalluxio然后终止所有 master PodsStatefulSet 与 Service$ kubectl delete service -l appalluxio $ kubectl delete statefulset -l appalluxio确保进行下一步前所有 Pods 都已终止。步骤 3如有必要格式化日志和 Alluxio 存储。参考 Upgrade 文档 判断是否需要格式化 Alluxio master 日志。若不需要可跳过本步骤。格式化方式见上文 格式化日志kubectl。如果使用分层存储参见 Caching 文档且已为 Alluxio 配置持久卷则需删除并重新创建持久卷以清理存储。步骤 4重新启动 Alluxio master 和 worker Pods。$ kubectl create -f ./master/ $ kubectl create -f ./worker/步骤 5验证 Pods 已重新启动并运行。# 应看到所有 Alluxio master 和 worker Pods $ kubectl get pods更全面的验证可参考 Running-Alluxio-Locally 文档 的 Verify 部分。验证部署与访问 Web UI验证如果使用了持久卷卷的状态应更改为CLAIMED卷声明的状态应为BOUNDED$ kubectl get pv $ kubectl get pvc如果存在未绑定的 PersistentVolumeClaim请确认已发放匹配的 PersistentVolume参见上文 可选发放持久卷。准备就绪后从 master Pod 访问 Alluxio CLI 并运行基本 I/O 测试$ kubectl exec -ti alluxio-master-0 /bin/bash从 master Pod 内执行$ alluxio runTests访问 Web UI可以使用端口转发从 Kubernetes 集群外部访问 Alluxio Web UI$ kubectl port-forward alluxio-master-$i 19999:19999注意第一个 master Pod 的i0。运行多个 masters 时需要为每个 master 转发端口但仅 primary master 提供 Web UI 服务。也可以指定本地端口映射kubectl port-forward alluxio-master-0 local-port:19999Pod 不必运行在当前节点上。高级设置POSIX APIAlluxio 部署到 Kubernetes 后客户端应用可通过多种方式连接。对于使用 POSIX API参见 POSIX-API 文档的应用程序应用容器可以通过挂载 Alluxio FileSystem 的方式连接。为此首先需要部署 Alluxio FUSE 守护程序。通过 Helm 启用 FUSEfuse: enabled: true clientEnabled: true默认挂载路径是/mnt/alluxio-fuse可通过mountPath修改对应 values.yaml 中的fuse.mountPointfuse: enabled: true clientEnabled: true mountPath: /mnt/alluxio-fuse如果已经通过 Helm 部署了 Alluxio 且希望追加启用 FUSE使用helm upgrade$ helm upgrade alluxio -f config.yaml --set fuse.enabledtrue --set fuse.clientEnabledtrue alluxio-charts/alluxio通过 kubectl 部署 FUSE$ cp alluxio-fuse.yaml.template alluxio-fuse.yaml $ kubectl create -f alluxio-fuse.yaml注意运行 Alluxio FUSE 守护程序容器需要SYS_ADMIN能力和securityContext.privileged TRUE需要 Alluxio 访问权限的应用容器不需要此特权。运行 FUSE 守护程序需要基于ubuntu而非alpine的 Docker 镜像。应用容器可以在任意 Docker 镜像上运行。验证应用容器可以无需任何定制二进制或能力通过hostPath挂载到/alluxio-fuse路径简单挂载 Alluxio FileSystem$ cp alluxio-fuse-client.yaml.template alluxio-fuse-client.yaml $ kubectl create -f alluxio-fuse-client.yaml如果使用该模板Alluxio 会挂载到/alluxio-fuse可通过 POSIX API 跨多个容器访问。FUSE 守护程序默认作为 DaemonSet 运行对应 templates/fuse/daemonset.yaml在每个节点上启动。短路访问Short-circuit Access短路访问使客户端可以绕过网络接口直接对 worker 执行读写操作。对性能敏感的应用建议启用短路操作因为与 Alluxio worker 共置时可提升客户端读写吞吐量。注意该特性默认启用但在 Kubernetes 环境下需要额外配置才能正常工作。禁用会降低 I/O 吞吐量。禁用短路操作HelmshortCircuit: enabled: false禁用短路操作kubectl在ALLUXIO_WORKER_JAVA_OPTS中设置alluxio.user.short.circuit.enabledfalse并从 Pod 定义的卷及每个容器的volumeMounts中移除alluxio-domain卷如果存在-Dalluxio.user.short.circuit.enabledfalse从源码看config/alluxio-conf.yaml 会在shortCircuit.enabledfalse时向ALLUXIO_WORKER_JAVA_OPTS追加该属性而 worker/daemonset.yaml 则在需要域套接字卷时挂载到/opt/domain。短路模式一local。如果客户端主机名与 worker 主机名匹配Alluxio 客户端和本地 Alluxio worker 就能互识这称为主机名自省。此模式下客户端与本地 worker 共享 worker 的分层存储。Helm 配置shortCircuit: enabled: true policy: localkubectl 配置在alluxio-configmap.yaml的ALLUXIO_WORKER_JAVA_OPTS中添加同时删除-Dalluxio.worker.data.server.domain.socket.address属性-Dalluxio.user.short.circuit.enabledtrue -Dalluxio.worker.data.server.domain.socket.as.uuidfalse短路模式二uuid默认。这是 Kubernetes 中短路访问的默认策略。如果客户端或 worker 容器使用虚拟网络主机名可能不匹配此时设置以下属性使用文件系统检查来启用短路操作并确保客户端容器按域套接字路径挂载目录——如果 worker UUID 位于客户端文件系统上则启用短路写操作。域套接字路径域套接字是一个卷应挂载在所有 Alluxio workers 上所有打算通过 Alluxio 进行读写的应用容器上。该域套接字卷可以是PersistentVolumeClaim或hostPath Volume。使用 PersistentVolumeClaim默认域套接字卷为 PVC。需要为该 PVC 发放一个PersistentVolume且该 PV 应为local或hostPath类型。Helm 配置这些也是默认配置参见 values.yaml# 以下为默认配置 shortCircuit: enabled: true policy: uuid size: 1Mi # volumeType 控制短路卷类型可为 persistentVolumeClaim 或 hostPath volumeType: persistentVolumeClaim # 域套接字卷为 PVC 时的属性 pvcName: alluxio-worker-domain-socket accessModes: - ReadWriteOnce storageClass: standardshortCircuit.pvcName定义域套接字 PVC 的名称该 PVC 会作为helm install的一部分被创建对应模板 worker/domain-socket-pvc.yaml。kubectl 配置验证ALLUXIO_WORKER_JAVA_OPTS中的以下属性默认即为这些值-Dalluxio.worker.data.server.domain.socket.address/opt/domain -Dalluxio.worker.data.server.domain.socket.as.uuidtrue同时确保 worker Pods 在volumes中定义了域套接字且所有相关容器挂载了域套接字卷volumes: - name: alluxio-domain persistentVolumeClaim: claimName: alluxio-worker-domain-socket注意计算应用容器必须将域套接字卷挂载到与 Alluxio workers 配置相同的路径/opt/domain。PVC 定义见worker/alluxio-worker-pvc.yaml.template模板。使用 hostPath 卷也可以让 workers 直接使用hostPath卷作为域套接字。将shortCircuit.volumeType改为hostPath并定义hostPath卷路径shortCircuit: enabled: true policy: uuid size: 1Mi # volumeType 控制短路卷类型可为 persistentVolumeClaim 或 hostPath volumeType: hostPath # 域套接字卷为 hostPath 时的属性 hostPath: /tmp/alluxio-domain # 使用的 hostPath 目录kubectl 方式与 PVC 相同验证ALLUXIO_WORKER_JAVA_OPTS中的属性并确保 worker Pod 的volumes定义域套接字volumes: - name: alluxio-domain hostPath: path: /tmp/alluxio-domain type: DirectoryOrCreate同样计算应用容器必须将域套接字卷挂载到与 workers 相同的路径/opt/domain。验证短路读写监控以下指标Web UI 指标Domain Socket Alluxio Read和Domain Socket Alluxio WriteMetrics-System 文档 中所述 metrics JSON 的cluster.BytesReadDomain和cluster.BytesWrittenDomainAdmin-CLI 文档 中所述 fsadmin metrics CLI 的Short-circuit Read (Domain Socket)和Alluxio Write (Domain Socket)。故障排除Worker Host UnreachableAlluxio worker 使用以物理主机 IP 作为主机名的主机网络。检查集群防火墙是否遇到类似错误Caused by: io.netty.channel.AbstractChannel$AnnotatedConnectException: finishConnect(..) failed: Host is unreachable: host/IP:29999排查步骤检查host与物理主机地址匹配而不是虚拟容器主机名。从远程客户端 ping 检查地址是否可解析$ ping host验证客户端可以按 worker 部署规范指定的端口连接到 workers。默认端口为[29998, 29999, 29996, 30001, 30002, 30003]在 values.yaml 中分别对应 worker.rpc29999、worker.web30000、jobWorker.rpc30001、jobWorker.data30002、jobWorker.web30003 等。使用网络工具检查端口可达性$ nc -zv IP 29999Permission Denied从 Alluxio v2.1 及更高版本起默认 Alluxio Docker 容器Fuse 除外以非 root 用户alluxioUID 1000、GID 1000身份运行。KuberneteshostPath卷默认只能由 root 写入因此需要相应地更新权限。这也与 values.yaml 中默认的user: 1000 / group: 1000 / fsGroup: 1000安全上下文一致。启用调试日志使用 CLI 命令logLevel更改 Alluxio 服务器master 和 workers的日志级别。先进入 master Pod$ kubectl exec -ti alluxio-master-0 /bin/bash在 master Pod 内执行$ alluxio logLevel --level DEBUG --logName alluxio访问日志Alluxio master 和 job master 作为 master Pod 的独立容器分别运行同样Alluxio worker 和 job worker 作为 worker Pod 的独立容器分别运行。按以下方式访问各容器日志# Master $ kubectl logs -f alluxio-master-0 -c alluxio-master # Worker $ kubectl logs -f alluxio-worker-id -c alluxio-worker # Job Master $ kubectl logs -f alluxio-master-0 -c alluxio-job-master # Job Worker $ kubectl logs -f alluxio-worker-id -c alluxio-job-workerPOSIX API 问题为了让应用容器挂载hostPath卷运行容器的节点必须已有 Alluxio FUSE 守护程序运行。默认规范alluxio-fuse.yaml作为 DaemonSet 运行会在集群的每个节点上启动 FUSE 守护程序。使用 POSIX API 访问 Alluxio 遇到问题时使用kubectl describe pods或仪表板确定应用容器运行的节点使用kubectl describe nodes node识别节点上运行的alluxio-fusePod跟踪已识别 Pod 的日志以查看错误kubectl logs -f alluxio-fuse-id。仓库参考Helm Chart 结构速览本文涉及的配置均可对照仓库中 integration/kubernetes/helm-chart/alluxio 下的实现进一步深入values.yaml全部可配置项、默认值与注释镜像、master/worker 资源、journal、tieredstore、shortCircuit、fuse、secrets、metrics、logserver、csi 等templates/config/alluxio-conf.yaml将 values 渲染为ALLUXIO_JAVA_OPTS、ALLUXIO_WORKER_JAVA_OPTS等 ConfigMap 数据是理解配置传递的核心templates/master/statefulset.yamlmaster StatefulSet、journal 格式化 initContainer、volumeClaimTemplates 与探针定义templates/worker/daemonset.yamlworker DaemonSet 与域套接字卷挂载templates/worker/domain-socket-pvc.yaml短路访问域套接字 PVC 模板helm-generate.sh可依据 Helm Chart 生成 kubectl 使用的原生 YAML 模板。理解这些模板与 values 的映射关系可以让你在helm与kubectl两种部署方式之间自由切换并按需定制生产部署。赞分享存储分布式文件系统缓存大数据【免费下载链接】alluxioAlluxio, data orchestration for analytics and machine learning in the cloud项目地址https://gitcode.com/gh_mirrors/al/alluxio点击查看免费下载相关推荐TDengine 在 Kubernetes 上的部署实战基于 kubectl 与 Helm 构建高可用集群TDengine 在 Kubernetes 上的部署实战基于 kubectl 与 Helm 构建高可用集群 TDengine 作为面向云原生架构设计的时间序列数据库时序数据库物联网大数据实时分析云原生kubernetes-handbook 实战基于 Helm 与 ConfigMap 的 nginx-ingress 控制器完整部署与配置指南kubernetes handbook 实战基于 Helm 与 ConfigMap 的 nginx ingress 控制器完整部署与配置指南 本篇技术指南以教程云原生容器编排NATS on Kubernetes使用 Helm 的 Kubernetes 部署指南NATS on Kubernetes使用 Helm 的 Kubernetes 部署指南 项目基础介绍 NATS on Kubernetes 是一个开源项目旨云原生消息队列上一篇SwinIR智能外交如何用图像修复技术革新外交活动污染监测下一篇HSTracker炉石套牌追踪器免费完整指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Alluxio on Kubernetes 部署实战：基于 Helm 与 kubectl 的完整指南
存储分布式文件系统缓存大数据【免费下载链接】alluxioAlluxio, data orchestration for analytics and machine learning in the cloud项目地址https://gitcode.com/gh_mirrors/al/alluxio点击查看免费下载本篇指南以 Alluxio 官方中文部署文档为主体完整演示如何在 Kubernetes 集群上通过helm推荐或原生kubectl规范运行 Alluxio覆盖先决条件、日志持久化、分层存储、短路访问、POSIX API、升级与故障排查。读完本文你将能够独立完成 Alluxio 在 Kubernetes 上的生产级部署并理解 Helm Chart 中各配置项在 integration/kubernetes/helm-chart/alluxio/values.yaml 与模板中的实际映射关系。先决条件在开始部署前需要准备以下环境一个 Kubernetes 集群版本 1.8。在默认规范下Alluxio workers 通过sizeLimit参数决定emptyDir卷的大小这是 Kubernetes 1.8 版本中的 Alpha 特性使用前请确保该特性已启用。一个可访问的 Alluxio Docker 镜像。仓库的 Helm Chart 默认使用alluxio/alluxio镜像镜像标签对应各版本。如果使用私有 Docker 注册表请参阅 Kubernetes 私有镜像仓库拉取相关文档。确保集群的 Kubernetes 网络策略允许应用程序Alluxio 客户端与 Alluxio Pods 之间在已定义端口上的连接。基本设置两种部署方式总览Alluxio 支持两种 Kubernetes 安装方式使用 Helm Chart首选当环境允许时推荐通过helm安装配置集中在单个config.yaml中便于版本化管理与回滚。使用kubectl原生资源规范当无法使用helm或需要更细粒度的自定义部署时可以直接基于 Kubernetes YAML 模板部署。注意从 Alluxio 2.3 起Alluxio 仅支持 Helm 3。如需从 Helm 2 迁移请参考 Helm 官方的 v2→v3 迁移文档。可选从 Docker 镜像提取 Kubernetes 规范如果使用私有 Helm 仓库或打算使用原生 Kubernetes 规范可以先将部署所需的 Kubernetes 规范从 Docker 镜像中提取出来本仓库的模板源头即 integration/kubernetes/helm-chart/alluxio 下的 Helm Chart$ id$(docker create alluxio/alluxio:version) $ docker cp $id:/opt/alluxio/integration/kubernetes/ - kubernetes.tar $ docker rm -v $id 1/dev/null $ tar -xvf kubernetes.tar $ cd kubernetes可选发放持久卷Persistent Volume日志是 Alluxio master 最关键的状态。根据部署配置的不同通常需要为 master 发放持久卷嵌入式日志Embedded JournalAlluxio 运行在 Kubernetes 上的首选 HA 机制。需要为每个要发放的 master Pod 设置一个持久卷。一旦创建了该卷即使 master 进程重启也不会影响持久卷的内容。相关细节可参考 Journal 文档。UFS 日志UFS JournalAlluxio master 也可以配置为使用持久卷存储日志。如果使用 UFS 日志且日志位置在外部如 HDFS可以跳过本节剩余部分。下面是一个用hostPath定义的持久卷示例保存为alluxio-master-journal-pv.yamlkind: PersistentVolume apiVersion: v1 metadata: name: alluxio-journal-0 labels: type: local spec: storageClassName: standard capacity: storage: 1Gi accessModes: - ReadWriteOnce hostPath: path: /tmp/alluxio-journal-0然后使用kubectl创建持久卷$ kubectl create -f alluxio-master-journal-pv.yaml注意默认每个日志卷应至少为 1Gi因为每个 Alluxio master Pod 会有一个请求 1Gi 存储的 PersistentVolumeClaim后文会介绍如何设置日志大小。从源码看master/statefulset.yaml 中通过volumeClaimTemplates为每个 master 动态申请alluxio-journal卷storageClassName、accessModes与storage大小均直接取自values.yaml中的journal段当journal.volumeType为emptyDir时则改用带sizeLimit的emptyDir卷。部署方式一Helm 安装前提条件安装 Helm 3.X安装方式见 Helm 官方文档。添加包含 Alluxio Helm Chart 的仓库$ helm repo add alluxio-charts https://alluxio-charts.storage.googleapis.com/openSource/version最小配置一旦 Helm 仓库可用即可准备 Alluxio 配置。最小配置必须包含底层存储地址properties: alluxio.master.mount.table.root.ufs: under_storage_address注意底层文件系统地址必须修改。任何涉及凭据的配置也必须一并修改。要查看完整的支持属性列表运行$ helm inspect values alluxio-charts/alluxio常用配置示例以下示例均写入config.yaml通过-f config.yaml传入helm install。本节配置在 values.yaml 中均有对应的默认值与注释说明。示例一以 Amazon S3 作为底层存储要以根挂载点方式将 S3 挂载到 Alluxio 根命名空间参见 S3 文档在properties下以 key-value 形式指定所有必需属性properties: alluxio.master.mount.table.root.ufs: s3a://bucket alluxio.master.mount.table.root.option.s3a.accessKeyId: accessKey alluxio.master.mount.table.root.option.s3a.secretKey: secretKey示例二单 Master 持久卷日志以下配置使用 UFS 日志参见 Journal 文档 的 UFS journal 部分将一个持久卷本地挂载到 master Pod 的/journal位置master: count: 1 # 多 Master 模式下增加该值 1 journal: type: UFS # UFS 或 EMBEDDED 之一 ufsType: local # local 或 HDFSlocal 会为每个 Master Pod 分配 PV folder: /journal # master 日志目录 size: 1Gi # volumeType 控制日志卷类型可为 persistentVolumeClaim 或 emptyDir volumeType: persistentVolumeClaim # 当日志卷为 persistentVolumeClaim 时的属性 storageClass: standard accessModes: - ReadWriteOnce示例三单 Master emptyDir日志同样配置 UFS 日志但使用emptyDir卷master: count: 1 journal: type: UFS ufsType: local folder: /journal size: 1Gi volumeType: emptyDir # 当日志卷为 emptyDir 时的属性 medium: 注意emptyDir卷的寿命与 Pod 相同不是持久性存储。当 Pod 重启或被重新调度时Alluxio 日志将丢失请仅在实验场景中使用。示例四以 HDFS 作为日志存储首先为 HDFS 客户端所需的任何配置创建 Secrets它们将挂载在/secrets下$ kubectl create secret generic alluxio-hdfs-config --from-file${HADOOP_CONF_DIR}/core-site.xml --from-file${HADOOP_CONF_DIR}/hdfs-site.xmljournal: type: UFS ufsType: HDFS # HDFS 类型不会为 master 分配 PV folder: hdfs://hostname:hostport/journal properties: alluxio.master.mount.table.root.ufs: hdfs://ns alluxio.master.journal.ufs.option.alluxio.underfs.hdfs.configuration: /secrets/hdfsConfig/core-site.xml:/secrets/hdfsConfig/hdfs-site.xml secrets: master: alluxio-hdfs-config: hdfsConfig worker: alluxio-hdfs-config: hdfsConfig示例五多 Master 持久卷嵌入式日志Embedded Journalmaster: count: 3 journal: type: EMBEDDED folder: /journal volumeType: persistentVolumeClaim size: 1Gi storageClass: standard accessModes: - ReadWriteOnce从源码看config/alluxio-conf.yaml 会为多 master 嵌入式日志场景自动生成-Dalluxio.master.embedded.journal.addressesalluxio-master-0:19200,...的地址列表并在 master/statefulset.yaml 中通过ALLUXIO_MASTER_HOSTNAME环境变量注入 Pod 名HA 模式或 Pod IP单 master 模式这是嵌入式日志多节点互通的关键。示例六多 Master emptyDir嵌入式日志master: count: 3 journal: type: UFS ufsType: local folder: /journal size: 1Gi volumeType: emptyDir medium: 注意同上emptyDir卷与 Pod 同生命周期日志会随 Pod 重启丢失仅限实验使用。示例七以 HDFS 作为底层存储properties: alluxio.master.mount.table.root.ufs: hdfs://ns alluxio.master.mount.table.root.option.alluxio.underfs.hdfs.configuration: /secrets/hdfsConfig/core-site.xml:/secrets/hdfsConfig/hdfs-site.xml secrets: master: alluxio-hdfs-config: hdfsConfig worker: alluxio-hdfs-config: hdfsConfig示例八Off-heap Metastore 管理持久卷以下配置为每个 Alluxio master Pod 创建一个PersistentVolumeClaim并将 Pod 配置为使用该卷作为基于 RocksDB 的 on-disk metastoreproperties: alluxio.master.metastore: ROCKS alluxio.master.metastore.dir: /metastore metastore: volumeType: persistentVolumeClaim # 可选 persistentVolumeClaim 或 emptyDir size: 1Gi mountPath: /metastore storageClass: standard accessModes: - ReadWriteOnce示例九Off-heap Metastore 管理emptyDir卷properties: alluxio.master.metastore: ROCKS alluxio.master.metastore.dir: /metastore metastore: volumeType: emptyDir size: 1Gi mountPath: /metastore medium: 注意emptyDir卷与 Pod 同生命周期元数据会随 Pod 重启丢失仅限实验使用。示例十同时挂载多个 Secrets多个 Secrets 可以同时挂载到 master 和 worker Pods每个 Pod 区域的格式为secretName: mountPathsecrets: master: alluxio-hdfs-config: hdfsConfig alluxio-ceph-config: cephConfig worker: alluxio-hdfs-config: hdfsConfig alluxio-ceph-config: cephConfig示例十一Alluxio 存储分层存储管理Alluxio 在 worker Pods 上管理本地存储包括内存。多级存储Multiple-Tier Storage参见 Caching 文档可以通过以下参考配置设置。支持的 3 种卷类型type为hostPath、emptyDir和persistentVolumeClaim。仅内存级tieredstore: levels: - level: 0 mediumtype: MEM path: /dev/shm type: emptyDir high: 0.95 low: 0.7内存和 SSD 多级存储hostPathtieredstore: levels: - level: 0 mediumtype: MEM path: /dev/shm type: hostPath high: 0.95 low: 0.7 - level: 1 mediumtype: SSD path: /ssd-disk type: hostPath high: 0.95 low: 0.7注意如果在运行时创建了hostPath文件或目录只有root用户能使用。hostPath卷没有资源大小限制。可以以root权限运行 Alluxio 容器或者确保存在具有 UID 和 GID 1000 的alluxio用户可访问的本地路径。内存和 SSD 多级存储使用 PVCtieredstore: levels: - level: 0 mediumtype: MEM path: /dev/shm type: persistentVolumeClaim name: alluxio-mem quota: 1G high: 0.95 low: 0.7 - level: 1 mediumtype: SSD path: /ssd-disk type: persistentVolumeClaim name: alluxio-ssd quota: 10G high: 0.95 low: 0.7注意每一层有一个 PVC。当 PVC 绑定到类型为hostPath或local的 PV 时每个 worker Pod 都会使用 Node 上的本地路径。对于 worker 分层存储建议使用hostPath或local卷以便 worker 本地读写获得最佳性能。local卷需要nodeAffinity使用该卷的 Pod 只能运行在卷nodeAffinity规则指定的节点上。单级多卷存储内存 SSD 在同一层tieredstore: levels: - level: 0 mediumtype: MEM,SSD path: /dev/shm,/alluxio-ssd type: persistentVolumeClaim name: alluxio-mem,alluxio-ssd quota: 1GB,10GB high: 0.95 low: 0.7该配置会为每个卷创建一个persistentVolumeClaim。在 config/alluxio-conf.yaml 中tieredstore.levels会被转换为-Dalluxio.worker.tieredstore.levelsN、-Dalluxio.worker.tieredstore.level{n}.dirs.path、-Dalluxio.worker.tieredstore.level{n}.dirs.quota、-Dalluxio.worker.tieredstore.level{n}.watermark.high/low.ratio等 JVM 参数写入 ConfigMaphigh/low即高低水位线比例。安装完成名为config.yaml的配置文件后执行$ helm install alluxio -f config.yaml alluxio-charts/alluxio卸载$ helm delete alluxio格式化日志StatefulSet 中的 master Pods 在启动时使用initContainer格式化日志。该initContainer由journal.format.runFormattrue开启默认情况下 master 启动时日志不会被格式化参见 values.yaml 中journal.format.runFormat: false。可以通过升级现有 Helm 部署来触发日志格式化# 使用相同的 config.yaml 并打开日志格式化开关 $ helm upgrade alluxio -f config.yaml --set journal.format.runFormattrue alluxio-charts/alluxio注意helm upgrade将重新创建 master Pods。也可以在部署时直接触发日志格式化$ helm install alluxio -f config.yaml --set journal.format.runFormattrue alluxio-charts/alluxio从源码看master/statefulset.yaml 中的journal-formatinitContainer 使用command: [alluxio, formatJournal]并从alluxio-configConfigMap 注入环境变量同时挂载alluxio-journal卷到journal.folder保证格式化与 master 写入同一目录。部署方式二kubectl 原生部署选择 YAML 模板样例提取规范目录下的子目录包含一组常见部署方案的 YAML 模板singleMaster-localJournal、singleMaster-hdfsJournal和multiMaster-embeddedJournal。singleMaster表示模板生成 1 个 Alluxio master 进程multiMaster表示 3 个。embedded和ufs是 Alluxio 支持的两种日志模式参见 Journal 文档。singleMaster-localJournal提供必要的 Kubernetes ConfigMap、1 个 Alluxio master 进程和一组 Alluxio workers。master 将日志写入volumeClaimTemplates请求的日志卷中。multiMaster-embeddedJournal提供 Kubernetes ConfigMap、3 个 Alluxio masters 和一组 workers。每个 master 将日志写入由volumeClaimTemplates请求的自己的日志卷中。singleMaster-hdfsJournal提供 Kubernetes ConfigMap、1 个 Alluxio master 以及一组 workers。日志位于共享的 UFS 路径此模板中以 HDFS 作为 UFS。配置 ConfigMap确定部署选项后从相应子目录复制模板$ cp alluxio-configmap.yaml.template alluxio-configmap.yaml按需修改或添加任何配置属性。底层文件系统地址必须修改任何凭据也必须修改。在ALLUXIO_JAVA_OPTS中添加-Dalluxio.master.mount.table.root.ufsunder_storage_address注意用适当的 URI 替换under_storage_address例如s3://my-bucket。如果底层存储要求凭据请确保一并指定。使用主机网络运行 Alluxio 时分配给 Alluxio 服务的端口不得被预先占用。创建 ConfigMap$ kubectl create -f alluxio-configmap.yaml安装准备规范。基于模板准备 Alluxio 部署规范修改任何所需参数例如 Docker 镜像的位置以及 Pod 的 CPU 和内存要求。为 master(s) 创建Service和StatefulSet$ mv master/alluxio-master-service.yaml.template master/alluxio-master-service.yaml $ mv master/alluxio-master-statefulset.yaml.template master/alluxio-master-statefulset.yaml注意alluxio-master-statefulset.yaml使用volumeClaimTemplates为每个 master 定义日志卷如果需要的话。为 workers 创建DaemonSet$ mv worker/alluxio-worker-daemonset.yaml.template worker/alluxio-worker-daemonset.yaml注意请确保 Kubernetes 规范版本与所使用的 Alluxio Docker 镜像版本一致。可选远程存储访问当 Alluxio 需要连接到所部署 Kubernetes 集群之外的存储主机时可能需要额外步骤。以下说明如何配置可访问但不受 Kubernetes 管理的远程 HDFS 连接。步骤 1为 HDFS 连接添加hostAliases。Kubernetes Pods 无法识别不由 Kubernetes 管理的网络主机名因为不是 Kubernetes Service除非已通过hostAliases定义好。例如如果 HDFS 服务可通过hdfs://namenode:9000访问其中namenode是主机名则需要在spec中为所有 Alluxio Pod 添加hostAliases建立主机名到 IP 地址的映射spec: hostAliases: - ip: namenode_ip hostnames: - namenode对于alluxio-master-statefulset.yaml.template和alluxio-worker-daemonset.yaml.template模板hostAliases部分应添加到spec.template.spec中如下所示kind: StatefulSet metadata: name: alluxio-master spec: ... serviceName: alluxio-master replicas: 1 template: metadata: labels: app: alluxio-master spec: hostAliases: - ip: ip for hdfs-host hostnames: - hdfs-host步骤 2为 HDFS 配置文件创建 Kubernetes Secret。$ kubectl create secret generic alluxio-hdfs-config --from-file${HADOOP_CONF_DIR}/core-site.xml --from-file${HADOOP_CONF_DIR}/hdfs-site.xml这两个配置文件在alluxio-master-statefulset.yaml和alluxio-worker-daemonset.yaml中被引用。Alluxio 进程需要 HDFS 配置文件才能连接这些文件在容器中的位置由属性alluxio.underfs.hdfs.configuration控制。步骤 3修改alluxio-configmap.yaml.template。更新alluxio.master.journal.folder和alluxio.master.mount.table.root.ufs指向目标 HDFS 服务。部署完成所有先决条件和配置后部署 Alluxio$ kubectl create -f ./master/ $ kubectl create -f ./worker/卸载$ kubectl delete -f ./worker/ $ kubectl delete -f ./master/ $ kubectl delete configmap alluxio-config注意这将删除./master/和./worker/下的所有资源。如果这些目录下有想保留的持久卷或其他重要资源请注意不要误删。格式化日志kubectl可以手动添加一个initContainer在 Pod 创建时运行alluxio formatJournal以格式化日志- name: journal-format image: alluxio/alluxio:version imagePullPolicy: IfNotPresent securityContext: runAsUser: 1000 command: [alluxio,formatJournal] envFrom: - configMapRef: name: alluxio-config volumeMounts: - name: alluxio-journal mountPath: /journal注意从 Alluxio v2.1 及更高版本起默认 Alluxio Docker 容器Fuse 除外以非 root 用户alluxioUID 1000、GID 1000身份运行。请确保 Alluxio master Pod 的运行用户与日志格式化用户一致。升级kubectl本节介绍如何使用kubectl升级 Kubernetes 集群中的 Alluxio。步骤 1升级 Docker 镜像版本标签。每个 Alluxio 版本发布都会对应发布 Docker 镜像。更新所有 Alluxio 容器的image字段为目标版本标签标签latest指向最新的稳定版本containers: - name: alluxio-master image: alluxio/alluxio:latest imagePullPolicy: IfNotPresent ... - name: alluxio-job-master image: alluxio/alluxio:latest imagePullPolicy: IfNotPresent ...步骤 2停止运行中的 Alluxio master 和 worker Pods。通过删除 DaemonSet 终止所有 worker Pods$ kubectl delete daemonset -l appalluxio然后终止所有 master PodsStatefulSet 与 Service$ kubectl delete service -l appalluxio $ kubectl delete statefulset -l appalluxio确保进行下一步前所有 Pods 都已终止。步骤 3如有必要格式化日志和 Alluxio 存储。参考 Upgrade 文档 判断是否需要格式化 Alluxio master 日志。若不需要可跳过本步骤。格式化方式见上文 格式化日志kubectl。如果使用分层存储参见 Caching 文档且已为 Alluxio 配置持久卷则需删除并重新创建持久卷以清理存储。步骤 4重新启动 Alluxio master 和 worker Pods。$ kubectl create -f ./master/ $ kubectl create -f ./worker/步骤 5验证 Pods 已重新启动并运行。# 应看到所有 Alluxio master 和 worker Pods $ kubectl get pods更全面的验证可参考 Running-Alluxio-Locally 文档 的 Verify 部分。验证部署与访问 Web UI验证如果使用了持久卷卷的状态应更改为CLAIMED卷声明的状态应为BOUNDED$ kubectl get pv $ kubectl get pvc如果存在未绑定的 PersistentVolumeClaim请确认已发放匹配的 PersistentVolume参见上文 可选发放持久卷。准备就绪后从 master Pod 访问 Alluxio CLI 并运行基本 I/O 测试$ kubectl exec -ti alluxio-master-0 /bin/bash从 master Pod 内执行$ alluxio runTests访问 Web UI可以使用端口转发从 Kubernetes 集群外部访问 Alluxio Web UI$ kubectl port-forward alluxio-master-$i 19999:19999注意第一个 master Pod 的i0。运行多个 masters 时需要为每个 master 转发端口但仅 primary master 提供 Web UI 服务。也可以指定本地端口映射kubectl port-forward alluxio-master-0 local-port:19999Pod 不必运行在当前节点上。高级设置POSIX APIAlluxio 部署到 Kubernetes 后客户端应用可通过多种方式连接。对于使用 POSIX API参见 POSIX-API 文档的应用程序应用容器可以通过挂载 Alluxio FileSystem 的方式连接。为此首先需要部署 Alluxio FUSE 守护程序。通过 Helm 启用 FUSEfuse: enabled: true clientEnabled: true默认挂载路径是/mnt/alluxio-fuse可通过mountPath修改对应 values.yaml 中的fuse.mountPointfuse: enabled: true clientEnabled: true mountPath: /mnt/alluxio-fuse如果已经通过 Helm 部署了 Alluxio 且希望追加启用 FUSE使用helm upgrade$ helm upgrade alluxio -f config.yaml --set fuse.enabledtrue --set fuse.clientEnabledtrue alluxio-charts/alluxio通过 kubectl 部署 FUSE$ cp alluxio-fuse.yaml.template alluxio-fuse.yaml $ kubectl create -f alluxio-fuse.yaml注意运行 Alluxio FUSE 守护程序容器需要SYS_ADMIN能力和securityContext.privileged TRUE需要 Alluxio 访问权限的应用容器不需要此特权。运行 FUSE 守护程序需要基于ubuntu而非alpine的 Docker 镜像。应用容器可以在任意 Docker 镜像上运行。验证应用容器可以无需任何定制二进制或能力通过hostPath挂载到/alluxio-fuse路径简单挂载 Alluxio FileSystem$ cp alluxio-fuse-client.yaml.template alluxio-fuse-client.yaml $ kubectl create -f alluxio-fuse-client.yaml如果使用该模板Alluxio 会挂载到/alluxio-fuse可通过 POSIX API 跨多个容器访问。FUSE 守护程序默认作为 DaemonSet 运行对应 templates/fuse/daemonset.yaml在每个节点上启动。短路访问Short-circuit Access短路访问使客户端可以绕过网络接口直接对 worker 执行读写操作。对性能敏感的应用建议启用短路操作因为与 Alluxio worker 共置时可提升客户端读写吞吐量。注意该特性默认启用但在 Kubernetes 环境下需要额外配置才能正常工作。禁用会降低 I/O 吞吐量。禁用短路操作HelmshortCircuit: enabled: false禁用短路操作kubectl在ALLUXIO_WORKER_JAVA_OPTS中设置alluxio.user.short.circuit.enabledfalse并从 Pod 定义的卷及每个容器的volumeMounts中移除alluxio-domain卷如果存在-Dalluxio.user.short.circuit.enabledfalse从源码看config/alluxio-conf.yaml 会在shortCircuit.enabledfalse时向ALLUXIO_WORKER_JAVA_OPTS追加该属性而 worker/daemonset.yaml 则在需要域套接字卷时挂载到/opt/domain。短路模式一local。如果客户端主机名与 worker 主机名匹配Alluxio 客户端和本地 Alluxio worker 就能互识这称为主机名自省。此模式下客户端与本地 worker 共享 worker 的分层存储。Helm 配置shortCircuit: enabled: true policy: localkubectl 配置在alluxio-configmap.yaml的ALLUXIO_WORKER_JAVA_OPTS中添加同时删除-Dalluxio.worker.data.server.domain.socket.address属性-Dalluxio.user.short.circuit.enabledtrue -Dalluxio.worker.data.server.domain.socket.as.uuidfalse短路模式二uuid默认。这是 Kubernetes 中短路访问的默认策略。如果客户端或 worker 容器使用虚拟网络主机名可能不匹配此时设置以下属性使用文件系统检查来启用短路操作并确保客户端容器按域套接字路径挂载目录——如果 worker UUID 位于客户端文件系统上则启用短路写操作。域套接字路径域套接字是一个卷应挂载在所有 Alluxio workers 上所有打算通过 Alluxio 进行读写的应用容器上。该域套接字卷可以是PersistentVolumeClaim或hostPath Volume。使用 PersistentVolumeClaim默认域套接字卷为 PVC。需要为该 PVC 发放一个PersistentVolume且该 PV 应为local或hostPath类型。Helm 配置这些也是默认配置参见 values.yaml# 以下为默认配置 shortCircuit: enabled: true policy: uuid size: 1Mi # volumeType 控制短路卷类型可为 persistentVolumeClaim 或 hostPath volumeType: persistentVolumeClaim # 域套接字卷为 PVC 时的属性 pvcName: alluxio-worker-domain-socket accessModes: - ReadWriteOnce storageClass: standardshortCircuit.pvcName定义域套接字 PVC 的名称该 PVC 会作为helm install的一部分被创建对应模板 worker/domain-socket-pvc.yaml。kubectl 配置验证ALLUXIO_WORKER_JAVA_OPTS中的以下属性默认即为这些值-Dalluxio.worker.data.server.domain.socket.address/opt/domain -Dalluxio.worker.data.server.domain.socket.as.uuidtrue同时确保 worker Pods 在volumes中定义了域套接字且所有相关容器挂载了域套接字卷volumes: - name: alluxio-domain persistentVolumeClaim: claimName: alluxio-worker-domain-socket注意计算应用容器必须将域套接字卷挂载到与 Alluxio workers 配置相同的路径/opt/domain。PVC 定义见worker/alluxio-worker-pvc.yaml.template模板。使用 hostPath 卷也可以让 workers 直接使用hostPath卷作为域套接字。将shortCircuit.volumeType改为hostPath并定义hostPath卷路径shortCircuit: enabled: true policy: uuid size: 1Mi # volumeType 控制短路卷类型可为 persistentVolumeClaim 或 hostPath volumeType: hostPath # 域套接字卷为 hostPath 时的属性 hostPath: /tmp/alluxio-domain # 使用的 hostPath 目录kubectl 方式与 PVC 相同验证ALLUXIO_WORKER_JAVA_OPTS中的属性并确保 worker Pod 的volumes定义域套接字volumes: - name: alluxio-domain hostPath: path: /tmp/alluxio-domain type: DirectoryOrCreate同样计算应用容器必须将域套接字卷挂载到与 workers 相同的路径/opt/domain。验证短路读写监控以下指标Web UI 指标Domain Socket Alluxio Read和Domain Socket Alluxio WriteMetrics-System 文档 中所述 metrics JSON 的cluster.BytesReadDomain和cluster.BytesWrittenDomainAdmin-CLI 文档 中所述 fsadmin metrics CLI 的Short-circuit Read (Domain Socket)和Alluxio Write (Domain Socket)。故障排除Worker Host UnreachableAlluxio worker 使用以物理主机 IP 作为主机名的主机网络。检查集群防火墙是否遇到类似错误Caused by: io.netty.channel.AbstractChannel$AnnotatedConnectException: finishConnect(..) failed: Host is unreachable: host/IP:29999排查步骤检查host与物理主机地址匹配而不是虚拟容器主机名。从远程客户端 ping 检查地址是否可解析$ ping host验证客户端可以按 worker 部署规范指定的端口连接到 workers。默认端口为[29998, 29999, 29996, 30001, 30002, 30003]在 values.yaml 中分别对应 worker.rpc29999、worker.web30000、jobWorker.rpc30001、jobWorker.data30002、jobWorker.web30003 等。使用网络工具检查端口可达性$ nc -zv IP 29999Permission Denied从 Alluxio v2.1 及更高版本起默认 Alluxio Docker 容器Fuse 除外以非 root 用户alluxioUID 1000、GID 1000身份运行。KuberneteshostPath卷默认只能由 root 写入因此需要相应地更新权限。这也与 values.yaml 中默认的user: 1000 / group: 1000 / fsGroup: 1000安全上下文一致。启用调试日志使用 CLI 命令logLevel更改 Alluxio 服务器master 和 workers的日志级别。先进入 master Pod$ kubectl exec -ti alluxio-master-0 /bin/bash在 master Pod 内执行$ alluxio logLevel --level DEBUG --logName alluxio访问日志Alluxio master 和 job master 作为 master Pod 的独立容器分别运行同样Alluxio worker 和 job worker 作为 worker Pod 的独立容器分别运行。按以下方式访问各容器日志# Master $ kubectl logs -f alluxio-master-0 -c alluxio-master # Worker $ kubectl logs -f alluxio-worker-id -c alluxio-worker # Job Master $ kubectl logs -f alluxio-master-0 -c alluxio-job-master # Job Worker $ kubectl logs -f alluxio-worker-id -c alluxio-job-workerPOSIX API 问题为了让应用容器挂载hostPath卷运行容器的节点必须已有 Alluxio FUSE 守护程序运行。默认规范alluxio-fuse.yaml作为 DaemonSet 运行会在集群的每个节点上启动 FUSE 守护程序。使用 POSIX API 访问 Alluxio 遇到问题时使用kubectl describe pods或仪表板确定应用容器运行的节点使用kubectl describe nodes node识别节点上运行的alluxio-fusePod跟踪已识别 Pod 的日志以查看错误kubectl logs -f alluxio-fuse-id。仓库参考Helm Chart 结构速览本文涉及的配置均可对照仓库中 integration/kubernetes/helm-chart/alluxio 下的实现进一步深入values.yaml全部可配置项、默认值与注释镜像、master/worker 资源、journal、tieredstore、shortCircuit、fuse、secrets、metrics、logserver、csi 等templates/config/alluxio-conf.yaml将 values 渲染为ALLUXIO_JAVA_OPTS、ALLUXIO_WORKER_JAVA_OPTS等 ConfigMap 数据是理解配置传递的核心templates/master/statefulset.yamlmaster StatefulSet、journal 格式化 initContainer、volumeClaimTemplates 与探针定义templates/worker/daemonset.yamlworker DaemonSet 与域套接字卷挂载templates/worker/domain-socket-pvc.yaml短路访问域套接字 PVC 模板helm-generate.sh可依据 Helm Chart 生成 kubectl 使用的原生 YAML 模板。理解这些模板与 values 的映射关系可以让你在helm与kubectl两种部署方式之间自由切换并按需定制生产部署。赞分享存储分布式文件系统缓存大数据【免费下载链接】alluxioAlluxio, data orchestration for analytics and machine learning in the cloud项目地址https://gitcode.com/gh_mirrors/al/alluxio点击查看免费下载相关推荐TDengine 在 Kubernetes 上的部署实战基于 kubectl 与 Helm 构建高可用集群TDengine 在 Kubernetes 上的部署实战基于 kubectl 与 Helm 构建高可用集群 TDengine 作为面向云原生架构设计的时间序列数据库时序数据库物联网大数据实时分析云原生kubernetes-handbook 实战基于 Helm 与 ConfigMap 的 nginx-ingress 控制器完整部署与配置指南kubernetes handbook 实战基于 Helm 与 ConfigMap 的 nginx ingress 控制器完整部署与配置指南 本篇技术指南以教程云原生容器编排NATS on Kubernetes使用 Helm 的 Kubernetes 部署指南NATS on Kubernetes使用 Helm 的 Kubernetes 部署指南 项目基础介绍 NATS on Kubernetes 是一个开源项目旨云原生消息队列上一篇SwinIR智能外交如何用图像修复技术革新外交活动污染监测下一篇HSTracker炉石套牌追踪器免费完整指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考