Deploy RisingWave on Kubernetes with Operator

The Operator is a deployment and management system for RisingWave. It runs on top of Kubernetes and provides functionalities like provisioning, upgrading, scaling, and destroying the RisingWave instances inside the cluster.

​

Prerequisites

• Install kubectl Ensure that the Kubernetes command-line tool kubectl is installed in your environment.
• Install psql Ensure that the PostgreSQL interactive terminal psql is installed in your environment.
• Install and run Docker Ensure that Docker is installed in your environment and running.
• Ensure you allocate enough resources for the deployment. For details, see Hardware requirements.

​

Create a Kubernetes cluster

kind create cluster

kubectl cluster-info

​

Deploy the Operator

Before the deployment, ensure that the following requirements are satisfied.

• Docker version ≥ 18.09
• kubectl version ≥ 1.18
• For Linux, set the value of the sysctl parameter net.ipv4.ip_forward to 1.

kubectl apply --server-side -f https://github.com/risingwavelabs/risingwave-operator/releases/latest/download/risingwave-operator.yaml

# Replace ${VERSION} with the version you want to install, e.g., v1.3.0
kubectl apply --server-side -f https://github.com/risingwavelabs/risingwave-operator/releases/download/${VERSION}/risingwave-operator.yaml

Error from server (InternalError): Internal error occurred: failed calling webhook "webhook.cert-manager.io": failed to call webhook: Post "<https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=10s>": dial tcp 10.105.102.32:443: connect: connection refused

kubectl -n cert-manager get pods
kubectl -n risingwave-operator-system get pods

​

Deploy a RisingWave instance

RisingWave Kubernetes Operator extends the Kubernetes with CRDs (Custom Resource Definitions) to manage RisingWave. That means all you need to do is to create a RisingWave resource in your Kubernetes cluster, and the RisingWave Kubernetes Operator will take care of the rest.

​

Use the example resource files

The RisingWave resource is a custom resource that defines a RisingWave cluster. In this directory, you can find resource examples that deploy RisingWave with different configurations of metadata store and state backend. Based on your requirements, you can use these resource files directly or as a reference for your customization. The stable directory contains resource files that we have tested compatibility with the latest released version of the RisingWave Operator:

The resource files are named using the convention of risingwave-<meta_store>-<state_backend>.yaml. For example, risingwave-postgresql-s3.yaml means that this manifest file uses PostgreSQL as the meta storage and AWS S3 as the state backend.

RisingWave supports using these systems or services as state backends.

• MinIO
• AWS S3
• S3-compatible object storages
• Google Cloud Storage
• Azure Blob Storage
• Alibaba Cloud OSS
• HDFS

You can customize the state backend, or customize the state store directory.

​

Optional: Customize the state backend

​

Download source file

If you intend to customize a resource file, download the file to a local path and edit it:

curl https://raw.githubusercontent.com/risingwavelabs/risingwave-operator/main/docs/manifests/<sub-directory> -o risingwave.yaml

You can also create your own resource file from scratch if you are familiar with Kubernetes resource files.

Then, apply the resource file by using the following command:

kubectl apply -f a.yaml      # relative path
kubectl apply -f /tmp/a.yaml # absolute path

​

Customize the state backends

To customize the state backend of your RisingWave cluster, edit the spec:stateStore section under the RisingWave resource (kind: RisingWave).

• AWS S3
• MinIO
• S3-compatible
• Azure Blob Storage
• Google Cloud Storage
• Alibaba Cloud OSS
• HDFS

spec:
  stateStore:
    # Prefix to objects in the object stores or directory in file system. Default to "hummock".
    dataDirectory: hummock

    # Declaration of the S3 state store backend.
    s3:
      # Region of the S3 bucket.
      region: us-east-1

      # Name of the S3 bucket.
      bucket: risingwave

      # Credentials to access the S3 bucket.
      credentials:
        # Name of the Kubernetes secret that stores the credentials.
        secretName: s3-credentials

        # Key of the access key ID in the secret.
        accessKeyRef: AWS_ACCESS_KEY_ID

        # Key of the secret access key in the secret.
        secretAccessKeyRef: AWS_SECRET_ACCESS_KEY

        # Optional, set it to true when the credentials can be retrieved
        # with the service account token, e.g., running inside the EKS.
        #
        # useServiceAccount: true

​

Optional: Customize the state store directory

You can customize the directory for storing state data via the spec: stateStore: dataDirectory parameter in the risingwave.yaml file that you want to use to deploy a RisingWave instance. If you have multiple RisingWave instances, ensure the value of dataDirectory for the new instance is unique (the default value is hummock). Otherwise, the new RisingWave instance may crash. Save the changes to the risingwave.yaml file before running the kubectl apply -f <...risingwave.yaml> command. The directory path cannot be an absolute address, such as /a/b, and must be no longer than 180 characters.

​

Validate the status of the instance

You can check the status of the RisingWave instance by running the following command.

kubectl get risingwave

If the instance is running properly, the output should look like this:

NAME        RUNNING   STORAGE(META)   STORAGE(OBJECT)   AGE
risingwave  True      postgresql      S3                30s

​

Connect to RisingWave

• ClusterIP
• NodePort
• LoadBalancer

kubectl apply -f https://raw.githubusercontent.com/risingwavelabs/risingwave-operator/main/docs/manifests/psql/psql-console.yaml

kubectl exec -it psql-console -- bash

psql -h risingwave-frontend -p 4567 -d dev -U root

Now you can ingest and transform streaming data. See Quick start for details.