Using kubernetes http.keda.sh with zookeeper.streamnative.io

Question

Pulumi · Accepted Answer

Kubernetes is a highly extensible platform, and one aspect of its extensibility comes from the ability to deploy custom workloads and configurations. To manage these, you can use Kubernetes Custom Resource Definitions (CRDs) to define custom resources. Two such extensions that can be used together are KEDA (Kubernetes Event-Driven Autoscaling) and Apache ZooKeeper, a centralized service for maintaining configuration information, naming, providing distributed synchronization, and providing group services.

KEDA allows for fine-grained autoscaling (including to/from zero) for event-driven Kubernetes workloads. The HTTP add-on for KEDA provides a way to autoscale your HTTP workloads based on the number of incoming requests.

Apache ZooKeeper is often used with distributed streaming platforms like Apache Kafka. Kafka integrations might use ZooKeeper as a component, though Kafka itself is moving away from requiring ZooKeeper for its operations.

Here's how you'd typically deploy KEDA in Kubernetes and utilize something like ZooKeeper:

1. Install the KEDA operator on your Kubernetes cluster.
2. Define a ScaledObject resource to inform KEDA how to scale your workload.
3. For ZooKeeper, you would typically deploy it within your cluster or externally.

To proceed, you would need
- a Kubernetes cluster where you have `kubectl` access.
- ZooKeeper to be setup and accessible, either within the cluster or externally.

Below is an example Pulumi program that sets up a KEDA ScaledObject to scale based on an external metric (the actual metric emitted by ZooKeeper is hypothetical in this case):

```typescript
import * as k8s from "@pulumi/kubernetes";

// Deploy KEDA using a Helm chart.
const kedaChart = new k8s.helm.v3.Chart("keda", {
    repo: "kedacore",
    chart: "keda",
    version: "2.0.0", // Replace with the version you want to install
});

// Assuming you have a deployment for a workload that you want to autoscale with KEDA
// and HTTP add-on. The `deploymentName` represents the name of this deployment.
const deploymentName = "example-deployment";

// This is where we define the ScaledObject for KEDA which will scale our deployment
// based on some external metrics, e.g., metrics from ZooKeeper.
const zookeeperScaledObject = new k8s.apiextensions.CustomResource("zookeeper-scaledobject", {
    apiVersion: "keda.sh/v1alpha1",
    kind: "ScaledObject",
    metadata: {
        name: "zookeeper-scaled-object",
        // Ensure this is the same namespace as your deployment.
        namespace: "default",
    },
    spec: {
        scaleTargetRef: {
            name: deploymentName,
        },
        // Assuming ZooKeeper emits a metric `zookeeper_requests` which you want to use for scaling.
        triggers: [
            {
                type: "external",
                metadata: {
                    // Details for connecting to ZooKeeper and fetching metrics would go here.
                    // This is highly dependent on your ZooKeeper setup and what metrics it exposes.
                    scalerAddress: "zookeeper-scalar.keda.scalars",
                    // The name of the metric to scale on.
                    metricName: "zookeeper_requests",
                    // Target average value you want to have for the metric.
                    targetValue: "100",
                },
            },
        ],
    },
});

// Export the name of the ScaledObject
export const scaledObjectName = zookeeperScaledObject.metadata.name;
```

In this code, we are setting up KEDA using a Helm chart. You must have Helm and Tiller installed in your cluster or use Helm 3 which doesn't require Tiller. We then create a `ScaledObject` custom resource that KEDA uses to determine how to scale the specified Kubernetes deployment.

The `ScaledObject` resource includes a triggers section which describes what metrics should trigger scaling events. In this example, we have specified a hypothetical `zookeeper_requests` metric as the trigger, which might represent the number of requests your service makes to ZooKeeper. You'll need to replace this with the actual metrics that your ZooKeeper cluster provides and point it to the right scalar address where your ZooKeeper scaler is running. The scaler could be something custom that you've developed, which serves as an intermediary between KEDA and ZooKeeper.

Please note that properly integrating with ZooKeeper for scaling would likely require you to create a custom scaler if an out-of-the-box scaler for ZooKeeper doesn't exist. This custom scaler would need to interact with ZooKeeper, fetch the necessary metrics, and expose them in a way KEDA can use to make scaling decisions.

Finally, we export the name of the `ScaledObject`, which could be used by other Pulumi programs or for simple referencing within Kubernetes.

Remember to adjust the trigger metadata with the actual configuration that matches how your target workloads interact with ZooKeeper or any other metric source.