I’ve come to the conclusion that Habitat has almost no place in Kubernetes. I’ve been using them together for nearly two years and over that time period have used less and less of Habitat.
Here’s what’s left:
- Packaging / dependency management
- Config templating
- user.toml watch+reload
The binding mechanism introduced an unacceptable amount of instability into my systems (entire clustered services having their config re-templated and getting reloaded/restarted if a single pod drops out and again when the new one spawns) and had to be removed before anything was prod-ready. The config and file gossip system were never useful and always ran orthogonal to the (much better) ConfigMap/Secret mechanism.
I’m still struggling with the inability to have some config template changes restart the service and some not.
At this point, I would recommend against adoption of Habitat for any greenfield project targeting Kubernetes deployment. It is still an extremely valuable tool for migration from traditional VM deployments into containers and Kubernetes, but I’d encourage elimination of the useful bridging features as soon as possible post-migration for the reasons outlined above.
That being said, please see the issues I filed against the operator while I still used it. All of these are still valid: https://github.com/habitat-sh/habitat-operator/issues/created_by/HT154