= Helm
<
== Deploying FeatureHub on Kubernetes
Helm chart is designed to support FeatureHub's most scalable deployment option (REST + Streaming real-time feature updates). Read more about it https://docs.featurehub.io/featurehub/latest/installation.html#_option_2a_scalable_deployment_streaming_rest_feature_updates[here]
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. Please note, you will likely need to modify certain values in the chart to suit your production needs.
== Local Development/Testing
The helm chart on the kind cluster installs with a default of Postgres and NATs. There are deploy scripts for using both, but a simple
$ helm upgrade -i featurehub featurehub -n featurehub
will work as long as the other kinD dependencies are installed. Below are the setup instructions for ensuring that kinD is installed and configured correctly (it needs an ingress running on port 80) before installing the charts.
=== 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 https://kind.sigs.k8s.io/docs/user/quick-start/#installation[KinD]
=== 2. Create the KinD cluster
=== 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
=== 4. Install Chart dependencies
$ cd featurehub && helm dependency update && cd ..
=== 5. Install FeatureHub (with defaults)
(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
It should show something like this:
$ kubectl get pods
=== 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. This is 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 the chart, 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). For example:
$ kubectl get pods
and then port-forward
The management port is exposed on a service:
$ kubectl port-forward featurehub-management-repository-bf8b79d4d-2pkdl 8701
A curl to check it's health:
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 [[changelog]]
=== 4.1.4
=== 4.1.3
=== 4.1.0
=== 4.0.9
=== 4.0.8
=== 4.0.7
=== 4.0.6
Release for version 1.7.0
=== 4.0.5
Release for version 1.6.3
=== 4.0.4
The backend services port for MR was not open so Dacha2 was failing to connect on a restart of service.
=== 4.0.3
Release 1.6.2 of FeatureHub.
=== 4.0.2
Shifting path in global ingress to deal with k8s installs that can't handle default routes.
=== 4.0.1
Release 1.6.1 of FeatureHub
=== 4.0.0 - enabling Dacha2
FeatureHub v1.6.0 with https://docs.featurehub.io/featurehub/latest/migration.html#_overview[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 https://github.com/norwoodj/helm-docs[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 link:https://github.com/featurehub-io/featurehub/blob/master/LICENSE.txt[here].