Alluxio Community Day VIII

Join us at our next virtual community event on December 14th featuring fellow Alluxio community users from Apache Iceberg and WeRide.

在Kubernetes上部署Alluxio

Slack Docker Pulls GitHub edit source

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.7.1)
$ 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

还有其他方法来创建持久卷如文档

部署


访问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 runTests

(可选)如果Alluxio master使用持久卷,则卷的状态应更改为CLAIMED,卷声明的状态应为 BOUNDED。你可以验证其状态如下

$ kubectl get pv
$ kubectl get pvc

高级设置

POSIX API

一旦Alluxio部署到Kubernetes上,客户端应用程序可以通过多种方式连接。对于使用POSIX API的应用程序,应用程序容器可以通过挂载Alluxio FileSystem方式连接。

为了使用POSIX API,首先部署Alluxio FUSE守护程序。


短路访问

短路访问使客户端可以绕过网络接口直接对worker执行读写操作。对于性能至关重要的应用程序,建议对Alluxio启用短路操作,因为当与Alluxio worker共置时,可以增加客户端的读写吞吐量。

启用短路操作的属性。 此特性默认启用的,但在Kubernetes环境下需要额外的配置才能在正常工作。有关如何配置短路访问参见以下各节。

禁用短路操作。 要禁用短路操作,该操作取决于你是如何部署的Alluxio。

注意:如前所述,禁用对Alluxio workers短路访问会导致更低I/O吞吐量


短路模式。 使用短路访问有两种模式

A.local 在这种模式下,如果客户端主机名与worker主机名匹配,Alluxio客户端和本地Alluxio worker就能互识。 这称为主机名自省。 在这种模式下,Alluxio客户端和本地Alluxio worker共享Alluxio worker的分层存储。


B. uuid 这是在Kubernetes中使用短路访问的默认策略

如果客户端或工作容器在使用虚拟网络,则其主机名可能不匹配。在这种情况下,请将以下属性设置为使用文件系统检查来启用短路操作,并确保客户端容器按域套接字路径挂载目录。 如果worker UUID位于客户端文件系统上,则启用短路写操作。

域套接字路径。 域套接字是一个应挂载在以下上的卷:

  • 所有Alluxio workers
  • 打算通过Alluxio进行读写的所有应用容器。

该域套接字卷可以是PersistentVolumeClaim或一个hostPath Volume

使用PersistentVolumeClaim。 默认情况下,此域套接字卷为PersistentVolumeClaim。 你需要为此PersistentVolumeClaim发放一个PersistentVolume。这个PersistentVolume应该是localhostPath


使用hostPath卷。 您也可以直接定义workers将hostPath Volume用于域套接字。


验证。 要验证短路读取和写入,请监控以下显示的指标

  1. Web UI的指标Domain Socket Alluxio ReadDomain Socket AlluxioWrite 1.或metrics json as cluster.BytesReadDomaincluster.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以检查地址是否可解析。

$ ping <host>

-验证客户端可以按worker部署规范指定的端口上连接到workers。默认端口为[29998,29999,29996,30001,30002,30003]。使用网络工具如ncat来检查是否可以从远程客户端访问特定的端口:

$ nc -zv <IP> 29999

从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-fusePod。 1.尾部记录已识别Pod的日志以查看遇到的任何错误: kubectl logs -f alluxio-fuse- <id>