Create a Valkey instance explicitly¶

Prerequisites¶

• Member of a NAIS team

We recommend creating your Valkey instances in their own workflow for more control over configuration, especially if you intend for multiple applications using the same Valkey instance, or if you need to change configuration.

Creating a Valkey instance is done by adding a Valkey resource to your namespace with detailed configuration. Some configuration is enforced by the NAIS platform, while the rest is up to the users.

Earlier we talked about the "instance name". In reality, the actual name of the valkey instance will be valkey-<team name>-<instance name> (where team name is the same as the namespace your application resides in). The resource needs to have this full name in order to be accepted.

The default Valkey created by NAIS looks like this:

apiVersion: aiven.io/v1alpha1
kind: Valkey
metadata:
  labels:
    app: valkey-tester
    team: myteam
  name: valkey-myteam-sessions
  namespace: myteam
spec:
  plan: startup-4
  project: nav-dev

A minimal Valkey resource only requires plan and project.

• project should match your NAIS tenant (nav) and the environment you are running in (ex. dev, prod), with a dash (-) in between.
• plan is the Aiven plan for your Valkey instance. See Aivens list of possible plan values. The values are lowercased. Make sure you understand the differences between the plans before selecting the one you need. Examples: startup-4, startup-56, business-4, premium-14.

We use Aivens operator, so the Valkey resource is documented in detail in the Aiven documentation. You should look at the reference for any other fields that might be of interest.

Probably the most important value to consider is which plan to use.

The Startup plans are good for things like sessions or cache usage, where High Availability in case of failures is not important. Upgrades and regular maintenance is handled without noticeable downtime, by adding a new upgraded node and replicating data over to it before switching over DNS and shutting down the old node. Startup plans are backed up every 12 hours, keeping 1 backup available.

If you require HA, the Business plans provide for one failover node that takes over should your primary instance fail for any reason. When using business plans, a second node is always available with continuous replication, so it is able to start serving data immediately should the primary node fail. Business plans are backed up every 12 hours, keeping 3 days of backups available.

Once the resource is added to the cluster, some additional fields are filled in by the platform and should be left alone unless you have a good reason:

There are some fields available that should not be used:

ServiceIntegration¶

A ServiceIntegration is used to integrate the Valkey instance with Prometheus. It is pretty straight forward, with little to no configuration needed.

Simple 5 steps procedure:

1. Copy the below yaml into a file (it can be the same file as your Valkey instance)
2. Replace <ENV> with the environment you are running in (ex. dev, prod) (in field project)
3. Replace <MYTEAM> with your team name (in labels, namespace and sourceServiceName)
4. Replace <INSTANCE> with the last part of the name of your Valkey instance (in name and sourceServiceName)
5. Replace <ENDPONT-ID> with the endpoint ID from the table below (in destinationEndpointId)
6. Deploy the resource using the same pipeline as you use for your Valkey instance

---
apiVersion: aiven.io/v1alpha1
kind: ServiceIntegration
metadata:
    labels:
        team: <MYTEAM>
    name: valkey-<MYTEAM>-<INSTANCE>
    namespace: <MYTEAM>
spec:
    project: nav-<ENV>
    integrationType: prometheus
    destinationEndpointId: <ENDPONT-ID>
    sourceServiceName: valkey-<MYTEAM>-<INSTANCE>

Prometheus Endpoint IDs¶