Helm charts vs ansible-playbook vs k8s operator in system installation

5
votes

I have a big and fairly complex system for install into the k8s cluster.

60 microservices and 10 helm charts installed to 5 namespaces.

Currently, we run 5 helm install/upgrade commands with a pause of 30 seconds between commands. However, this strategy incurs a serious load on nodes due to the fact that we pull docker images and start applications. We have a long and not clear execution time(timeline) that often results in timeouts of components such as consul, Elasticsearch, and applications that depend on the aforementioned components.

I would like to hear opinions about ways to turn this situation around. First, here is our approach so far:

  1. Write the script that controls installation by helm charts.
  2. Write an ansible-playbook that runs Helm charts and controls the installation status of components.
  3. Write an ansible-playbook install components (either using Jinja2 templates or Golang templates)
  4. Write the k8s operator that installs components and controls the system status.
2
kubernetesinstallationansiblekubernetes-helm
Well it's 2020 and I can tell you having used both Helm and operator-sdk for a similar sized system, I hated both. At least operator-sdk fixed the glacially slow build problem it had pre v1.0 but coding in golang is as disappointing as ever. – jambox

2 Answers

5
votes

To answer my own question, I created an installation that can be used as a quick solution to fairly complex installations.

The solution relies on Ansible as an installation orchestrator and Helm as a package manager.

You can browse my github repo contains the code.

0
votes

There's a lot of ways of doing this. But you can use the kubernetes api directly. You can create any tech server such as Spring Boot, NodeJS, etc that controls the creation of the Kubernetes objects that you want. This way, basically, you'll be doing a customized Helm API, but the main difference is that you'll customize in your way with your needs.