Support for Kubernetes
The new Docker features debuting in recent versions of Octopus are really promising, and I'm excited by the Docker Compose RFC published late last year.
Kubernetes is becoming increasingly popular as the production deployment environment of choice for containerised applications. It offers functionality very similar to Azure Service Fabric, in terms of auto-scaling and self-healing of services and applications, but is based around container images rather than zip files.
Kubernetes and Helm support has been added as a preview feature in 2018.8.0. We will be working on these steps in future releases based on the feedback from this release.
This has been added as a preview in 2018.8.0. See https://octopus.com/docs/deployment-examples/kubernetes-deployments for more documentation.
Jeremy Gaither commented
+1 for helm as well, and we're already using it to deploy to kubernetes from octopus.
Aaron Roydhouse commented
Opinionated view incoming :-)
This is great - no fantastic - you are thinking about Kubernetes. But I think your Kubernetes strategy should be to integrate support for a helm client and chart repositories, and use the power of Octopus to push variables and secrets into helm charts.
I looked at the you github concept page, and there is no way you're going to make the form match the expressiveness of yaml manifests that Kubernetes provides, let alone the expressiveness of yaml+go templates. It is a lot of work and it won't get used because there will always be 2% that is missing or not up to date with the fast-moving k8s versions, that means users can't do what they want.
And few people still use raw yaml manifests anyway. They either generate the manifests from e.g. terraform or most often they create or re-use helm charts.
I think competitively you want Octopus to be the best darn way to inject variables and secrets and automate helm deployments.
You introduced docker support just when docker was hitting the skids, if you go for for
k8s manifest forms now you're again targeting the tail end of the zeitgeist.
We already to use Octopus for Kubernetes for about a year, we use Octopus action steps to pull helm charts from git or helm repos, inject values, and run the helm client on an ssh target. Works great. But would be better if the helm client was integrated with Octopus and Octopus understood helm charts and value files. The Kubernetes support you're planning, we'll never use, we moved on from that era 18 months ago.
Stanislav Hordiyenko commented
Meanwhile, I set up linux box with Calamari, installed gcloud, kubectl, docker. Added this box to all environments and configured a project to do deployment to the Kubernetes cluster. Use namespaces to separate environments. Works like a charm.
Looking forward to seeing and using this feature. Expect this to be a key part in our CD processes.
Great to see this getting on the roadmap.
As for the lack of parameters files and the variable substitution, I'd encourage using Helm charts (and their values.yaml) as a good design pattern.
Hello, Just wondering when this will be on the cards