在Kubernetes上部署Alluxio
Alluxio可以在Kubernetes上运行。本指南演示了如何使用Docker映像或helm
中包含的规范在Kubernetes上运行Alluxio
*目录
先决条件
一个Kubernetes集群(版本> = 1.8)。在默认规范下,Alluxio workers可以通过设置sizeLimit
参数来决定emptyDir
卷的大小。这是Kubernetes 1.8版本中的一个Alpha特性。在使用前请确保此功能已启用。
一个Alluxio Docker镜像alluxio/alluxio。如果使用私有Docker注册表,请参阅Kubernetes documentation。
确保Kubernetes网络策略允许应用程序(Alluxio客户端)和Alluxio Pods之间在已定义端口上的连接。
基本设置
本教程介绍了在Kubernetes上的基本Alluxio安装。 Alluxio支持在Kubernetes上两种安装方法:使用helm图表或使用kubectl
。如果可选,helm
是首选安装Alluxio方法。如果没法使用helm
安装或需要额外定制化部署,则可以直接通过原生Kubernetes资源规范使用kubectl
。
注意:从Alluxio 2.3起,Alluxio仅支持helm 3。
参阅如何从helm 2迁移到helm 3。
如果使用私有helm
仓库或使用原生Kubernetes规范,从Docker镜像中提取部署Alluxio所需的Kubernetes规范。
$ id=$(docker create alluxio/alluxio:2.10.0-SNAPSHOT)
$ docker cp $id:/opt/alluxio/integration/kubernetes/ - > kubernetes.tar
$ docker rm -v $id 1>/dev/null
$ tar -xvf kubernetes.tar
$ cd kubernetes
注意:嵌入式日志
需要为每个要发放的 master Pod设置一个持久卷,这是Alluxio运行在kubernetes上的首选HA机制。一旦创建了该卷,即使master进程重启不会影响持久卷的内容。
当使用UFS日志时,Alluxio master也可以配置为使用持久卷
来存储日志。如果你在用UFS日志并使用外部日志存储位置(例如HDFS),可以跳过此节所余部分。
有多种创建持久卷的方法。
下面是一个用hostPath
来定义的示例:
# Name the file alluxio-master-journal-pv.yaml
kind: 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
注意:默认每个日志卷应至少1GI,因为每个alluxio master Pod将有一个请求1Gi存储的PersistentVolumeClaim。后面部分会介绍如何设置日志大小。
然后使用kubectl
来创建持久卷:
$ kubectl create -f alluxio-master-journal-pv.yaml
还有其他方法来创建持久卷如文档
部署
前提条件
A.安装Helm
你应该已经安装了helm 3.X。
可以按照此处中的说明安装helm。
B.必须有包括Alluxio helm chart的helm repro
$ helm repo add alluxio-charts https://alluxio-charts.storage.googleapis.com/openSource/2.10.0-SNAPSHOT
配置
一旦helm repository可用,就可以准备Alluxio配置。
最小配置必须包含底层存储地址:
properties:
alluxio.master.mount.table.root.ufs: "<under_storage_address>"
注意:必须修改底层文件系统地址。任何凭证都必须修改。
要查看完整的支持属性列表,请运行helm inspect
命令
$ helm inspect values alluxio-charts/alluxio
本节的剩余部分通过例子描述各种配置选项。
To mount S3
在Alluxio根名称空间以key-value pair方式指定所有必须属性。
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>"
The following configures UFS Journal 将一个持久卷本地挂载在master Pod的位置 /journal
。
master:
count: 1 # For multiMaster mode increase this to >1
journal:
type: "UFS"
ufsType: "local"
folder: "/journal"
size: 1Gi
# volumeType controls the type of journal volume.
# It can be "persistentVolumeClaim" or "emptyDir"
volumeType: persistentVolumeClaim
# Attributes to use when the journal is persistentVolumeClaim
storageClass: "standard"
accessModes:
- ReadWriteOnce
‘/journal’位置来配置 UFS Journal
将一个emptyDir
卷本地挂载在master Pod的位置/journal
master:
count: 1 # For multiMaster mode increase this to >1
journal:
type: "UFS"
ufsType: "local"
folder: "/journal"
size: 1Gi
# volumeType controls the type of journal volume.
# It can be "persistentVolumeClaim" or "emptyDir"
volumeType: emptyDir
# Attributes to use when the journal is emptyDir
medium: ""
注意:emptyDir
卷的寿命与Pod寿命相同。
它不是持久性存储。
当Pod重新启动或被重新调度时,Alluxio日志将丢失。请仅在实验用例中使用。检查emptyDir了解更详细信息。
首先为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.xml
journal:
type: "UFS"
ufsType: "HDFS"
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:
count: 3
journal:
type: "EMBEDDED"
folder: "/journal"
# volumeType controls the type of journal volume.
# It can be "persistentVolumeClaim" or "emptyDir"
volumeType: persistentVolumeClaim
size: 1Gi
# Attributes to use when the journal is persistentVolumeClaim
storageClass: "standard"
accessModes:
- ReadWriteOnce
master:
count: 3
journal:
type: "UFS"
ufsType: "local"
folder: "/journal"
size: 1Gi
# volumeType controls the type of journal volume.
# It can be "persistentVolumeClaim" or "emptyDir"
volumeType: emptyDir
# Attributes to use when the journal is emptyDir
medium: ""
注意:emptyDir
卷的寿命与Pod寿命相同。 它不是持久性存储。当Pod重新启动或被重新调度时,Alluxio日志将丢失。请仅在实验用例中使用。检查emptyDir了解更详细信息。
首先为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.xml
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
以下配置为每个Alluxio master Pod创建一个PersistentVolumeClaim
,并将Pod
配置为使用该卷作为一个on-disk基于RocksDB的metastore。
properties:
alluxio.master.metastore: ROCKS
alluxio.master.metastore.dir: /metastore
metastore:
volumeType: persistentVolumeClaim # Options: "persistentVolumeClaim" or "emptyDir"
size: 1Gi
mountPath: /metastore
# Attributes to use when the metastore is persistentVolumeClaim
storageClass: "standard"
accessModes:
- ReadWriteOnce
以下配置为每个Alluxio master Pod创建一个emptyDir
卷,并将Pod配置为使用该卷作为一个on-disk基于RocksDB的metastore。
properties:
alluxio.master.metastore: ROCKS
alluxio.master.metastore.dir: /metastore
metastore:
volumeType: emptyDir # Options: "persistentVolumeClaim" or "emptyDir"
size: 1Gi
mountPath: /metastore
# Attributes to use when the metastore is emptyDir
medium: ""
注意:emptyDir
卷的寿命与Pod寿命相同。
它不是持久性存储。
当Pod重新启动或被重新调度时,Alluxio日志将丢失。请仅在实验用例中使用。检查emptyDir了解更详细信息)。
可以将多个secrets同时挂载到master和workerPods。每个Pod区域的格式为<secretName>:<mountPath>
secrets:
master:
alluxio-hdfs-config: hdfsConfig
alluxio-ceph-config: cephConfig
worker:
alluxio-hdfs-config: hdfsConfig
alluxio-ceph-config: cephConfig
Alluxio在worker Pods上管理本地存储,包括内存。Multiple-Tier Storage 可以使用以下参考配置来设置。
支持的3 种卷类型 type
:hostPath,emptyDir
和persistentVolumeClaim。
仅内存级
tieredstore:
levels:
- level: 0
mediumtype: MEM
path: /dev/shm
type: emptyDir
high: 0.95
low: 0.7
内存和SSD存储多级
tieredstore:
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存储 多级存储使用PVC
你还可以每层使用PVC并发放PersistentVolume。对于worker分层存储,使用hostPath
或local
卷,以便worker可以在本地读写,以实现最佳性能。
tieredstore:
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上的本地路径。本地
卷需要nodeAffinity
,并且使用此卷的Pod只能在nodeAffinity
卷规则中指定的节点上运行。可以在此处中找到更多详细信息。
内存和SSD存储 单级存储
可以在同一层上拥有多个卷。此配置将为每个卷创建一个persistentVolumeClaim
。
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
安装
一旦完成名为’config.yaml`的文件,运行如下命令安装:
$ helm install alluxio -f config.yaml alluxio-charts/alluxio
卸载
运行如下命令卸载Alluxio:
格式化日志
StatefulSet中的master Pods在启动是使用initContainer
来格式化日志。initContainer
由journal.format.runFormat = true
设置打开。 默认情况下,master启动时日志没有格式化。
可以使用升级现有的helm部署来触发日志格式化
journal.format.runFormat = true
。
# Use the same config.yaml and switch on journal formatting
$ helm upgrade alluxio -f config.yaml --set journal.format.runFormat=true alluxio-charts/alluxio
注:’helm upgrade`将重新创建 master Pods。
或者,可以在部署时触发日志格式化。
$ helm install alluxio -f config.yaml --set journal.format.runFormat=true alluxio-charts/alluxio
选择YAML模板样例
规范目录下的子目录包含一组常见部署方案的YAML模板:
singleMaster-localJournal, singleMaster-hdfsJournal and multiMaster-embeddedJournal.
singleMaster *意味者模板会产生一个 Alluxio master进程, *multiMaster意味者 三个. embedded和ufs是两个journal modes Alluxio 支持.
-singleMaster-localJournal *目录为你提供必要的Kubernetes ConfigMap,1个Alluxio master进程和一组Alluxio workers。Alluxio master将日志写入volumeClaimTemplates
请求的日志卷中。
-multiMaster-EmbeddedJournal目录为你提供Kubernetes ConfigMap,3个Alluxio masters和
一组Alluxio workers。每个Alluxio master将日志写入由volumeClaimTemplates请求的自己的日志卷中。
-singleMaster-hdfsJournal*目录为你提供Kubernetes ConfigMap,1个Aluxio master以及一
组workers。日志位于共享的UFS路径。在此模板中,我们将用HDFS作为UFS。
配置
一旦部署选项确定,从相应子目录复制模板
$ cp alluxio-configmap.yaml.template alluxio-configmap.yaml
按需要修改或添加任何配置属性。必须修改Alluxi底层文件系统地址。
任何凭证都必须修改。
添加到ALLUXIO_JAVA_OPTS
:
-Dalluxio.master.mount.table.root.ufs=<under_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定义好。
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
模板中StatefulSet或DaemonSet类型下,应该按如下所示将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。运行以下命令为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
。现在Pods已经知道如何连接到HDFS服务,下面更新alluxio.master.journal.folder
和alluxio.master.mount.table .root.ufs
并指向要连接的目标HDFS服务。
一旦完成所有先决条件和配置,就可以部署部署Alluxio了。
$ kubectl create -f ./master/
$ kubectl create -f ./worker/
卸载
卸载Alluxio如下
$ kubectl delete -f ./worker/
$ kubectl delete -f ./master/
$ kubectl delete configmap alluxio-config
注意:这将删除./master/
和./worker/
下的所有资源。 如果在这些目录下由持久卷或其他重要资源请注意不要不小心一并删除。
格式化日志
您可以手动添加一个initContainer
以便在Pod创建时格式化日志。initContainer
将在创建Pod时运行alluxio formatJournal
并格式化日志。
- name: journal-format
image: alluxio/alluxio:2.10.0-SNAPSHOT
imagePullPolicy: IfNotPresent
securityContext:
runAsUser: 1000
command: ["alluxio","formatJournal"]
volumeMounts:
- name: alluxio-journal
mountPath: /journal
注:从Alluxio V2.1及更高版本,默认Alluxio Docker容器除了Fuse以外将以非root 具有UID 1000和GID 1000 的用户alluxio
身份运行。 确保Alluxio master Pod运行和日志格式化都是以同一用户身份进行的。
升级
本节将介绍如何使用kubectl
升级Kubernetes集群中的Alluxio。
步骤1:升级docker镜像版本标签
每个Alluxio版本发布都会有相对应的docker镜像发布在
dockerhub。
你应该更新所有Alluxio容器的image
字段使用目标版本标签。标签latest
将指向最新的稳定版本。
例如,如果要将Alluxio升级到最新的稳定版本,按如下更新容器:
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进行来终止所有正在运行的Alluxio worker Pods。
$ kubectl delete daemonset -l app=alluxio
然后通过终止每个StatefulSet和每个标签为app=alluxio
的服务来终止所有正在运行的Alluxio master
$ kubectl delete service -l app=alluxio
$ kubectl delete statefulset -l app=alluxio
确保在进行下一步之前所有Pods都已经终止。
步骤3:如有必要,格式化日志和Alluxio存储
看下Alluxio升级之指南关于是否要格式化Alluxio master日志。如果不需要格式化,则可以跳过本节的剩余部分直接跳到重新启动所有Alluxio master和worker Pod部分。
您可以按照formatting journal with kubectl
来格式化Alluxio日志。
如果你在使用分层存储来运行Alluxio workers,并且已为Alluxio配置了持久卷,则也要清除存储。您应该删除现有并重新创建新持久卷。
一旦完成格式化所有日志和Alluxio存储后,就可以重新启动Alluxio master和worker Pods了。
步骤4:重新启动Alluxio master和worker Pods
现在Alluxio masters and worker容器都升级到所要的版本。可以重新启动运行了。
从YAML文件中重新启动Alluxio master and worker Pods。
$ kubectl create -f ./master/
$ kubectl create -f ./worker/
第5步:验证Alluxio master and worker Pods已经重新启动运行
你应该确认Alluxio Pods已经重新启动并在运行状态。
# You should see all Alluxio master and worker Pods
$ kubectl get pods
你可以根据以下文档做更全面的确认 Verify Alluxio.
访问Web UI
可以使用端口转发从kubernetes集群外部访问Alluxio UI。
$ kubectl port-forward alluxio-master-$i 19999:19999
注意:第一个master Pod i = 0
。当运行多个masters时,转发每个主机的端口。仅首席maste为Web UI提供服务。
###验证
一旦准备就绪,就可以从master Pod访问Alluxio CLI并运行基本的I/O测试。
$ kubectl exec -ti alluxio-master-0 /bin/bash
从master Pod,执行以下命令
(可选)如果Alluxio master使用持久卷,则卷的状态应更改为CLAIMED
,卷声明的状态应为 BOUNDED
。你可以验证其状态如下
$ kubectl get pv
$ kubectl get pvc
高级设置
POSIX API
一旦Alluxio部署到Kubernetes上,客户端应用程序可以通过多种方式连接。对于使用POSIX API的应用程序,应用程序容器可以通过挂载Alluxio FileSystem方式连接。
为了使用POSIX API,首先部署Alluxio FUSE守护程序。
通过配置以下属性来部署FUSE守护程序:
fuse:
enabled: true
clientEnabled: true
默认情况下,装载路径是/mnt/alluxio-fuse
。如果想修改FUSE装载路径,请更新以下属性
fuse:
enabled: true
clientEnabled: true
mountPath: /mnt/alluxio-fuse
然后按照以下步骤用helm安装Alluxio此处。
如果已经通过helm部署了Alluxio,现在想启用FUSE,则可以使用helm upgrade
来添加FUSE守护程序。
$ helm upgrade alluxio -f config.yaml --set fuse.enabled=true --set fuse.clientEnabled=true alluxio-charts/alluxio
$ cp alluxio-fuse.yaml.template alluxio-fuse.yaml
$ kubectl create -f alluxio-fuse.yaml
注:
运行Alluxio FUSE守护程序容器必须有SYS_ADMIN
能力和securityContext.privileged = TRUE
。需要Alluxio访问权限的应用程序容器不需要此特权。
需要基于ubuntu
而不是alpine
的Docker镜像来运行FUSE守护程序。
alluxio/alluxio-fuse应用程序容器可以在任何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进行跨多个容器访问。
短路访问
短路访问使客户端可以绕过网络接口直接对worker执行读写操作。对于性能至关重要的应用程序,建议对Alluxio启用短路操作,因为当与Alluxio worker共置时,可以增加客户端的读写吞吐量。
启用短路操作的属性。
此特性默认启用的,但在Kubernetes环境下需要额外的配置才能在正常工作。有关如何配置短路访问参见以下各节。
禁用短路操作。
要禁用短路操作,该操作取决于你是如何部署的Alluxio。
注意:如前所述,禁用对Alluxio workers短路访问会导致更低I/O吞吐量
你可以通过设置以下属性来禁用短路:
shortCircuit:
enabled: false
您应该在ALLUXIO_WORKER_JAVA_OPTS
把属性alluxio.user.short.circuit.enabled
设置为FALSE
。
-Dalluxio.user.short.circuit.enabled=false
你还应该从Pod定义的卷中的alluxio-domain
卷和每个容器中的volumeMounts
,如果存在的话
短路模式。
使用短路访问有两种模式
A.local
在这种模式下,如果客户端主机名与worker主机名匹配,Alluxio客户端和本地Alluxio worker就能互识。
这称为主机名自省。
在这种模式下,Alluxio客户端和本地Alluxio worker共享Alluxio worker的分层存储。
您可以通过如下设置属性来使用local
政策
shortCircuit:
enabled: true
policy: local
在你的alluxio-configmap.yaml
模板中,应将以下属性添加到ALLUXIO_WORKER_JAVA_OPTS
:
-Dalluxio.user.short.circuit.enabled=true -Dalluxio.worker.data.server.domain.socket.as.uuid=false
同时,你应该删除属性-Dalluxio.worker.data.server.domain.socket.address
。
B. uuid
这是在Kubernetes中使用短路访问的默认策略
如果客户端或工作容器在使用虚拟网络,则其主机名可能不匹配。在这种情况下,请将以下属性设置为使用文件系统检查来启用短路操作,并确保客户端容器按域套接字路径挂载目录。
如果worker UUID位于客户端文件系统上,则启用短路写操作。
域套接字路径。
域套接字是一个应挂载在以下上的卷:
- 所有Alluxio workers
- 打算通过Alluxio进行读写的所有应用容器。
该域套接字卷可以是PersistentVolumeClaim
或一个hostPath Volume
。
使用PersistentVolumeClaim。
默认情况下,此域套接字卷为PersistentVolumeClaim
。
你需要为此PersistentVolumeClaim
发放一个PersistentVolume
。这个PersistentVolume
应该是local
或hostPath
。
你可以通过如下属性设置来使用uuid
策略:
# These are the default configurations
shortCircuit:
enabled: true
policy: uuid
size: 1Mi
# volumeType controls the type of shortCircuit volume.
# It can be "persistentVolumeClaim" or "hostPath"
volumeType: persistentVolumeClaim
# Attributes to use if the domain socket volume is PVC
pvcName: alluxio-worker-domain-socket
accessModes:
- ReadWriteOnce
storageClass: standard
shortCircuit.pvcName
字段定义域套接字的PersistentVolumeClaim
名称。该PVC将作为helm install
的一部分被创建。
您应该在ALLUXIO_WORKER_JAVA_OPTS
中验证以下属性。
实际它们被默认设置为这些值:
-Dalluxio.worker.data.server.domain.socket.address=/opt/domain -Dalluxio.worker.data.server.domain.socket.as.uuid=true
你还应该确保worker Pods在volumes
中有定义域套接字,以及所有相关容器域套接字卷已挂载。该域套接字默认定义如下:
volumes:
- name: alluxio-domain
persistentVolumeClaim:
claimName: "alluxio-worker-domain-socket"
注:计算应用程序容器必须将域套接字卷挂载到为Alluxio workers配置的相同路径
(/opt/domain
)。
PersistenceVolumeClaim
定义于worker/alluxio-worker-pvc.yaml.template
模板。
使用hostPath卷。
您也可以直接定义workers将hostPath Volume
用于域套接字。
您可以切换为直接将hostPath
卷用于域套接字。这可以通过将shortCircuit.volumeType
字段更改为hostPath
来完成的。注意,你还需要定义hostPath
卷用的路径。
shortCircuit:
enabled: true
policy: uuid
size: 1Mi
# volumeType controls the type of shortCircuit volume.
# It can be "persistentVolumeClaim" or "hostPath"
volumeType: hostPath
# Attributes to use if the domain socket volume is hostPath
hostPath: "/tmp/alluxio-domain" # The hostPath directory to use
你应该以与使用PersistentVolumeClaim
相同的方式来验证ALLUXIO_WORKER_JAVA_OPTS
中的属性。
另外,您还应确保worker Pod在volumes
中定义了域套接字,并且所有相关的容器都已挂载了域套接字卷。域套接字默认定义如下:
volumes:
- name: alluxio-domain
hostPath:
path: /tmp/alluxio-domain
type: DirectoryOrCreate
注意:计算应用容器必须将域套接字卷挂载到为Alluxio workers配置的相同路径(/opt/domain
)。
验证。 要验证短路读取和写入,请监控以下显示的指标
- Web UI的指标
Domain Socket Alluxio Read
和 Domain Socket Alluxio
Write
1.或metrics json as cluster.BytesReadDomain
和 cluster.BytesWrittenDomain
1.或the fsadmin metrics CLI as Short-circuit Read (Domain Socket)
和 Alluxio Write (Domain Socket)
故障排除
Alluxio worker使用以物理主机IP作为主机名的主机网络。检查集群防火墙是否遇到诸如以下错误:
Caused by: io.netty.channel.AbstractChannel$AnnotatedConnectException: finishConnect(..) failed: Host is unreachable: <host>/<IP>:29999
-检查<host>
与物理主机地址匹配,而不是一个虚拟容器主机名。从远程客户端ping以检查地址是否可解析。
-验证客户端可以按worker部署规范指定的端口上连接到workers。默认端口为[29998,29999,29996,30001,30002,30003]
。使用网络工具如ncat
来检查是否可以从远程客户端访问特定的端口:
从alluxio V2.1及更高版本,默认alluxio Docker容器除了Fuse以外将以非root 具有UID 1000和GID 1000 的用户alluxio
身份运行。
Kubernetes hostPath
卷
只能由root写入,因此你需要相应地更新权限。
要更改Alluxio服务器(master and workers)的日志级别,使用CLI命令logLevel
,如下所示:
从master Pod访问Alluxio CLI。
$ 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-worker
为了让一个应用程序容器挂载hostPath
卷,运行容器的节点
必须有Alluxio FUSE守护程序已在运行。默认规范alluxio-fuse.yaml
作为DaemonSet运行
,在集群的每个节点上启动Alluxio FUSE守护程序。
如果在使用POSIX API访问Alluxio时遇到问题:
1.使用命令kubectl describe pods
或仪表板确定应用容器运行的节点。
1.使用命令kubectl describe nodes <node>
来识别在节点上运行的alluxio-fuse
Pod。
1.尾部记录已识别Pod的日志以查看遇到的任何错误:
kubectl logs -f alluxio-fuse- <id>
。