Configuring communal storage

Vertica on Kubernetes supports a variety of communal storage providers to accommodate your storage requirements.

Vertica on Kubernetes supports a variety of communal storage providers to accommodate your storage requirements. Configuring each storage provider requires that you create a Secret or ConfigMap to store sensitive information so that you can declare it in your Custom Resource (CR) without exposing any literal values.

Note

If your Kubernetes cluster is in the cloud or on a managed service, each Vertica node must operate in the same availability zone.

Amazon Web Services (AWS) S3 or S3-Compatible storage

Vertica on Kubernetes supports AWS communal storage locations, and private cloud S3 storage such as MinIO.

To connect to an S3-compatible storage location, create a Secret to store both your communal access and secret key credentials. Then, add the Secret, path, and S3 endpoint to the CR spec.

The following command stores both your S3-compatible communal access and secret key credentials in a Secret named s3-creds:
```
$ kubectl create secret generic s3-creds --from-literal=accesskey=accesskey --from-literal=secretkey=secretkey
```

Add the Secret to the communal section of the CR spec:

spec:
  ...
  communal:
    credentialSecret: s3-creds
    endpoint: https://path/to/s3-endpoint
    path: s3://bucket-name/key-name
    ...

For a detailed description of an S3-compatible storage implementation, see Creating a custom resource. For additional details about Vertica and AWS, see Vertica on Amazon Web Services.

Google Cloud Storage

Authenticating to Google Cloud Storage (GCS) requires your hash-based message authentication code (HMAC) access and secret keys, and the path to your GCS bucket. For details about HMAC keys, see Eon Mode on GCP prerequisites.

The following command stores your HMAC access and secret key in a Secret named gcs-creds:

$ kubectl create secret generic gcs-creds --from-literal=accesskey=accessKey --from-literal=secretkey=secretkey

Add the Secret and the path to the GCS bucket that contains your Vertica database to the communal section of the CR spec:

spec:
  ...
  communal:
    credentialSecret: gcs-creds
    path: gs://bucket-name/path/to/database-name
    ...

For additional details about Vertica and GCS, see Vertica on Google Cloud Platform.

Azure Blob Storage

Micosoft Azure provides a variety of options to authenticate to Azure Blob Storage location. Depending on your environment, you can use one of the following combinations to store credentials in a Secret:

accountName and accountKey
accountName and shared access signature (SAS)

If you use an Azure storage emulator such as Azurite in a tesing environment, you can authenticate with accountName and blobStorage values.

Important

Vertica does not officially support Azure storage emulators as a communal storage location.

The following command stores accountName and accountKey in a Secret named azb-creds:

$ kubectl create secret generic azb-creds --from-literal=accountKey=accessKey --from-literal=accountName=accountName

Alternately, you could store your accountName and your SAS credentials in azb-creds:

$ kubectl create secret generic azb-creds --from-literal=sharedAccessSignature=sharedAccessSignature --from-literal=accountName=accountName

Add the Secret and the path that contains your AZB storage bucket to the communal section of the CR spec:

spec:
  ...
  communal:
    credentialSecret: azb-creds
    path: azb://accountName/bucket-name/database-name
    ...

For details about Vertica and authenticating to Microsoft Azure, see Eon Mode databases on Azure.

Hadoop file storage

Connect to Hadoop Distributed Filesystem (HDFS) communal storage with the standard webhdfs scheme, or the swebhdfs scheme for wire encryption. In addition, you must add your HDFS configuration files in a ConfigMap, a Kubernetes object that stores data in key-value pairs. You can optionally configure Kerberos to authenticate connections to your HDFS storage location.

The following example uses the swebhdfs wire encryption scheme that requires a certificate authority (CA) bundle in the CR spec.

The following command stores a PEM-encoded CA bundle in a secret named hadoop-cert:
```
$ kubectl create secret generic hadoop-cert --from-file=ca-bundle.pem
```
HDFS configuration files are located in the /etc/hadoop directory. The following command creates a ConfigMap named hadoop-conf:
```
$ kubectl create configmap hadoop-conf --from-file=/etc/hadoop
```
Add the configuration values to the communal and certSecrets sections of the spec:
```
spec:
  ...
  communal:
    path: "swebhdfs://path/to/database"
    hadoopConfig: hadoop-conf
    caFile: /certs/hadoop-cert/ca-bundle.pem
  certSecrets:
    - name: hadoop-cert
  ...
```
The previous example defines the following:
- communal.path: The path to the database, using the wire encryption scheme. Enclose the path in double quotes.
- communal.hadoopConfig: The ConfigMap storing the contents of the /etc/hadoop directory.
- communal.caFile: The mount path in the container filesystem containing the CA bundle used to create the hadoop-cert Secret.
- certSecrets.name: The Secret containing the CA bundle.

For additional details about HDFS and Vertica, see Apache Hadoop integration.

Kerberos authentication (optional)

Vertica authenticates connections to HDFS with Kerberos. The Kerberos configuration between Vertica on Kubernetes is the same as between a standard Eon Mode database and Kerberos, as described in Kerberos authentication.

The following command stores the krb5.conf and krb5.keytab files in a Secret named krb5-creds:
```
$ kubectl create secret generic krb5-creds --from-file=kerberos-conf=/etc/krb5.conf --from-file=kerberos-keytab=/etc/krb5.keytab
```
Consider the following when managing the krb5.conf and krb5.keytab files in Vertica on Kubernetes:
- Each pod uses the same krb5.keytab file, so you must update the krb5.keytab file before you begin any scaling operation.
- When you update the contents of the krb5.keytab file, the operator updates the mounted files automatically, a process that does not require a pod restart.
- The krb5.conf file must include a [domain_realm] section that maps the Kubernetes cluster domain to the Kerberos realm. The following example maps the default .cluster.local domain to a Kerberos realm named EXAMPLE.COM:
```
[domain_realm]
  .cluster.local = EXAMPLE.COM
```

Add the Secret and additional Kerberos configuration information to the CR:

spec:
  ...
  communal:
    path: "swebhdfs://path/to/database"
    hadoopConfig: hadoop-conf
    kerberosServiceName: verticadb
    kerberosRealm: EXAMPLE.COM
  kerberosSecret: krb5-creds
  ...

The previous example defines the following:

communal.path: The path to the database, using the wire encryption scheme. Enclose the path in double quotes.
communal.hadoopConfig: The ConfigMap storing the contents of the /etc/hadoop directory.
communal.kerberosServiceName: The service name for the Vertica principal.
communal.kerberosRealm: The realm portion of the principal.
kerberosSecret: The Secret containing the krb5.conf and krb5.keytab files.

For a complete definition of each of the previous values, see Custom resource definition parameters.