Habitat’s open source framework allows you to automate your applications’ definition, builds and rebuilds, deployment and management throughout their life cycle. One of Habitat’s fundamental principles is enabling users to deploy their applications anywhere they need to be run, and to preserve this automated behavior. How do we do this on Kubernetes? We use the Kubernetes Operator model, and a bunch of other awesome open source ecosystem tooling, to ensure that the experience and lifecycle management remains first class.
The Kubernetes Operator model is a way to put operational knowledge into the software you are shipping onto Kubernetes. Since Habitat’s framework focuses on doing exactly this in a way that is repeatable, cross-platform and cloud-agnostic, the two concepts are a natural fit. You will see that many distributed services, such as Elasticsearch, Redis, etcd, etc., have distributed their own purpose-baked Operator in order to ensure that their services can behave robustly and reliably within a Kubernetes cluster. Operators leverage Kubernetes Controllers and Resources to enable application behavior automation.
The main thing to take note of is that Habitat is not building a custom Operator for every application you build with Habitat and deploy to a Kubernetes cluster. Instead, Habitat is deploying one Operator, the Habitat Operator for Kubernetes, and then using that Operator to automate all of the application behavior you defined using Habitat’s framework when you originally defined your services. This Operator ensures that all Habitat deployed applications are enjoying Kubernetes’ many awesome features – highly reliable API-driven communication between containers and pods, update strategies, blue/green deploys – while maintaining the operational intelligence encoded into the service at definition using Habitat.
To put it simply, you can run your Habitat built and defined applications on Kubernetes, and leverage the native properties of Kubernetes, without worrying about the two falling out of sync. kubectl commands are kept track of by the Habitat Operator and applied correctly against your services, and your services continue to behave with the operational intelligence you originally encoded using Habitat’s application lifecycle hooks, build channel subscriptions, etc.
Some users who have experienced first hand Habitat’s robust capabilities of the same style of automation on virtual machines, bare metal, and vanilla docker fleets become confused because the way that gossiped service communication, health checks, deployments, update strategies, service binds, etc., are achieved in those ecosystems is via networked gossip protocols and peer to peer communication. That same protocol is not how the same workload is automated on Kubernetes, because that wouldn’t work or make sense on Kubernetes, where Kubernetes’ API-controller model and cluster management capabilities should be used instead. What Habitat is adding to the mix here is that you are getting the same behaviors and application automation cross-platform, in the correct way for the environment into which you are deploying.
The Habitat team is continually adding integrations to make continuous builds and deployments to running Kubernetes clusters more powerful and seamless. Our goal is a framework that allows you to write intelligent applications that know how to behave throughout their life cycles, and that work natively in whatever environment you deploy them in.
Got questions?
- Ask and answer questions on the Habitat forums
- Chat with the Habitat Community on Slack
- Learn more about Habitat