在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.3)
$ 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>