coordination #80142: [saga][epic] Scale out: Redundant/load-balancing deployments of openQA, easy containers, containers on kubernetes
[epic] openQA web UI in kubernetes
Helm charts allows you to automate the deployment of a complex set of items in a kubernetes environment. These elements are not only limited to pods (containers) but also to configurations (configmaps and secrets), and all the resources they need in the correct order and with the proper checks.
Thanks to the work done in #80142 we saw how to divide the web UI into parts, which were could be converted into HA and which had to remain standalone. In addition to how we should configure the load balancer to integrate each of the different services that make up the complete web UI.
This ticket proposes to create a helm chart capable of generating a complete and functional deployment of the web UI based on the following prerequisites:
- There is a pre-existing installation of kubernetes
- AC1: The complete web UI HA is installed with the DB with the default options
- AC2: The web UI is accessible from outside of the cluster
- AC3: The helm chart is configurable with: Typical and basic parameters and, number of replicas for HA, type of persistence for DB, ...
- AC4: Documentation is completed with instructions of use
- AC5: Deployed together with rancher
- Highly recommended based on work already done in #80142, e.g. the existing docker-compose setup
Proof-of-concept of either openQA webUI or worker within kubernetes, e.g. using k3s or try rancher directlydone for both webUI and worker in #110524
- Use local kubernetes deployments to development purposes (this avoid the infra needs). For instance: minikube, k3s,...
- Figure out if is necessary to publish the helm chart and where: https://helm.sh/docs/howto/chart_releaser_action/
- Combine with rancher
- Ensure proper testing of the charts
- Create kubernetes cluster inside docker inside GitHub Actions: https://github.com/marketplace/actions/kind-cluster
- Look at chart-testing tool: https://github.com/marketplace/actions/helm-chart-testing
- Try to deploy the chart inside CI
- Add definitions for init containers to allow fetching tests/needles from git repository during installation
- As an alternative to git, provide a persistent volume claim template for shared volume (ReadMany) -- think about Longhorn
- Add definition for rsyncd container to allow usage of cache service in the worker pod to synchronize data between webui and worker pods
- Enhance customization options of the current chart, add common options (like annotations, pod security, replicas count, ...) which are provided by the blank helm templates (reuse initial templates created by
Updated by ilausuch almost 3 years ago
For validation the helm chart we could use
helm lint ./chart
But also there is an other interesting tool kubeval
helm template ./chart | kubeval --strict
This allows testing with the default helm chart values, but also set different values and test the helm chart with these. This is important in case we have different branches of execution based on conditions
helm template --set area.key="val" | kubeval --strict
Or more complex, creating a VALUES.yaml file with the new values
area: key: "val"
And use to check it
echo "$VALUES" | helm template -f - | kubeval --strict
Updated by ilausuch over 2 years ago
Take in consideration the detected problem and the solutions in https://github.com/os-autoinst/openQA/pull/3821
In a helm chart should be an initial stage (a web UI pod) to create the initial DB (if is not created). This pod can be destroyed after done its job