Helm

We publish helm charts to .

Note	If you are coming from an earlier version, please read the Changelog.

Deploying FeatureHub on Kubernetes

These instructions are designed to get you up and running on a local kubernetes running on KinD. They will be fleshed out over time as we have these examples running on Google’s GKE/Autopilot, AWS’s EKS/Fargate, and Azure’s AKS.

Note

This set of Helm charts is designed to be run the local kinD cluster and be fully operable by anyone following these instructions. Without modification of the values in the charts, it is not intended to be production ready just "go". That said, considerable effort has been put in by contributors to make this as easy to adapt to your needs as possible.

Please feel free to visit our documentation for further information.

Steps

1. Install KinD

We assume KinD here rather than Docker for Kubernetes or Minikube or k3s. If you are familiar with those, you should be able to use them too and you can skip this step.

If you don’t have KinD installed, follow these instructions KinD

2. Create the KinD cluster

kind create cluster --config=kind-cluster.yaml

3. Install Ingress - allow traffic into the cluster

kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/static/provider/kind/deploy.yaml

kubectl wait --namespace ingress-nginx \
  --for=condition=ready pod \
  --selector=app.kubernetes.io/component=controller \
  --timeout=90s

4. Install Chart dependencies

$ cd featurehub && helm dependency update && cd ..

5. Install FeatureHub (with defaults)

helm upgrade --install featurehub featurehub

(If you receive an error 'Error: Internal error occurred: failed calling webhook …​', try deleting the ingress-nginx-admission resource kubectl delete -A ValidatingWebhookConfiguration ingress-nginx-admission and try again)

The FeatureHub services will initially 'crash' because they expect the Postgres and NATs services to already be available. Its ok, they will recover fairly quickly and start up.

To update it with config changes, just

helm upgrade featurehub featurehub

It should show something like this:

$  kubectl get pods

NAME                                                READY   STATUS              RESTARTS   AGE
featurehub-dacha-7d65db8c48-r59l6                   0/1     Pending             0          7s
featurehub-dacha-7d65db8c48-zqb8s                   0/1     Running             0          8s
featurehub-edge-86b6b5cf46-4cqvr                    0/1     ContainerCreating   0          7s
featurehub-edge-86b6b5cf46-n8cm5                    0/1     ContainerCreating   0          8s
featurehub-management-repository-567b8fbffb-7vcbf   0/1     ContainerCreating   0          8s
featurehub-nats-0                                   0/3     ContainerCreating   0          8s
featurehub-nats-1                                   2/3     Running             0          7s
featurehub-nats-2                                   0/3     Pending             0          7s
featurehub-nats-box-78587c4478-nkbzt                0/1     ContainerCreating   0          8s
featurehub-postgresql-0                             0/1     Running             0          8s

6. Test

It should be running on port 80, so you can login, create a new system, add features, etc. The Edge service is also running on port 80.

Notes about the helm chart

The ingress

By default, the helm chart will create a global ingress - as defined by the values - which means all traffic routing into your namespace will go through that ingress and be routed as per its rules. This means default traffic to MR and /features to Edge - Dacha never receives edge traffic.

All services generally have a separate monitoring and server port, as per the docs - MR is 8701 for monitoring, 8085 for the server. It does this to ensure your liveness and prometheus traffic endpoints aren’t exposed to the world.

If your services aren’t coming up - and you have modified these charts, its likely because the port configuration is wrong.

You will need to find a pod (unless you have enabled prometheus on the MR, in which case you get a service endpoint for it). So e.g.

$ kubectl get pods

to find a pod and then

The management port is exposed on a service, so:

$ kubectl port-forward featurehub-management-repository-bf8b79d4d-2pkdl 8701

A curl to it:

curl  localhost:8701
featurehub is here%

If there is something wrong with the health check of a service, then the logs should be printing out exactly what is wrong, and so should the endpoint.

Changelog

4.0.0 - enabling Dacha2

FeatureHub v1.6.0 with Dacha2, the new caching layer. Dacha2 will start up faster, but will initially have no data in it, so it will be slower (on the first request) to respond The addition is that it needs to know where MR is, because when it comes across an environment or service key it doesn’t understand, it will ask MR (failures get cached so MR doesn’t get spammed with invalid requests). Dacha1 is being supported over the new few major versions but is slowly being phased out.

The changes to the chart include turning off Dacha1 support and turning on Dacha2 and telling Dacha2 where the MR is.

We have also upgraded the embedded NATS chart to version 2.9.1 of NATS, and the Postgres chart to version 15 of Postgres. The new schema permissions model has required a minor tweak of the startup script here.

3.2.0 - FeatureHub v1.6.0 release

Includes FeatureHub v1.6.0 release. No other changes were made to the chart.

Contributing

Please ensure that you install and run helm-docs before issuing a PR because the workflow confirms it is up to date. It is required for publishing to the Helm Artifact Registry.

License

FeatureHub is operating under Apache 2.0 license. Please refer to the full license here.