Install on Kubernetes
This documentation shows how to install Alluxio on Kubernetes via Operator, a Kubernetes extension for managing applications.
Prerequisites
Kubernetes
A Kubernetes cluster with version at least 1.19, with feature gates enabled
Ensure the cluster’s Kubernetes Network Policy allows for connectivity between applications (Alluxio clients) and the Alluxio Pods on the defined ports
The Kubernetes cluster has helm 3 with version at least 3.6.0 installed
Image registry for storing and managing container image
Permissions. Reference: Using RBAC Authorization
Permission to create CRD (Custom Resource Definition)
Permission to create ServiceAccount, ClusterRole, and ClusterRoleBinding for the operator pod
Permission to create namespace that the operator will be in
Preparation
Download the files for Alluxio operator and Alluxio cluster
alluxio-operator-1.2.0-helmchart.tgz
is the helm chart for deploying Alluxio operatoralluxio-k8s-operator-1.2.0-docker.tar
is the docker image for Alluxio operatoralluxio-csi-1.2.0-docker.tar
is the docker image for Alluxio CSI, which should be required by defaultalluxio-enterprise-AI-3.2-5.2.0-docker.tar
is the docker image for Alluxio
Upload the images to an image registry
This example shows how to upload Alluxio operator image. Repeat these steps for all the images above.
Extract the helm chart for operator
Prepare configuration files
For the operator, put the configurations in
alluxio-operator/alluxio-operator.yaml
For the Alluxio cluster, put the configurations in
alluxio-operator/alluxio-cluster.yaml
to describe the cluster. To create a standard cluster, you can use the minimal configuration. The properties in.spec.properties
field will pass to Alluxio processes via analluxio-site.properties
configuration file.To mount an external storage to the Alluxio cluster, put the configurations in
alluxio-operator/ufs.yaml
. The example will mount an existing S3 path to Alluxio. For more information, please refer to Storage Overview.
Deployment
Deploy Alluxio operator
Deploy Alluxio
Note that in Alluxio 3.x, the "master" component is not critical on the I/O path and becomes a stateless component that only serves jobs like distributed load.
Mount storage to Alluxio
Configuration
Minimal configuration
Starting with the minimal configuration, we can build a standard cluster:
Common use cases
Change the resource limitations
For every component, like worker, master, and FUSE, we can change the resource by the following configuration:
The container will never be able to access the resource over the limits, and the requests are used during scheduling. For more information, please refer to Resource Management for Pods and Containers
The limit of the memory should be a little bit over the sum of the heap size(
-Xmx
) and the direct memory size(-XX:MaxDirectMemorySize=10g
) to avoid out-of-memory problems.
Use PVC for page store
The PVC will be created by the operator
The
storageClass
defaults tostandard
, but can be specified to empty string for static binding
Mount NAS or other host path
The key is the host path on the node, and the value is the mounted path in the container
If using a NAS as the UFS, the same path needs to be mounted to both the workers and FUSE processes so that the FUSE can fallback if any error occurs
Mount custom config maps
The key is the name of the
ConfigMap
, and the value if the mounted path in the containerThe
/opt/alluxio/conf
is already mounted by default. The custom config maps need to mount to other paths
Use the root user
The FUSE pod will always use the root user. The other processes use the user with uid 1000 by default. In the container, the user is named alluxio
. To change it to the root user, use this configuration:
Sometimes it’s enough to specify the
.spec.fsGroup = 0
only when the files can be accessed by the root groupThe ownership of the mounted host path, such as the page store path and log path, will be transferred to root if changing to the root user.
Last updated