Not really the best technical solution for this challenge. And this is from a big Ansible + Packer person that deploys 10Ks of VMs and infrastructure with Ansible.
10,000+ VMs? What do you work on?
Deploying Kubernetes with Ansible
31–40 of 61 posts
Re: Deploying Kubernetes with Ansible
#32I thought this was about deploying a Kubernetes cluster with Ansible, but nope, it's really about deploying YAML files to Kubernetes, with Ansible. Just...Why?
Sounds like the title should be "Deploying To Kubernetes With Ansible", since this isn't about deploying a Kubernetes cluster?
Re: Deploying Kubernetes with Ansible
#33Does the author ever heard about using loops in Ansible? with_dict can save you around 20-30 lines of code.
Re: Deploying Kubernetes with Ansible
#34I think the lesson people need to start taking is that any form of declarative form of configuration will spawn an ad-hoc ecosystem to turn it imperative. The complexity of situations that can be expressed is by a configuration system is proportional to the complexity of that system. Simple and declarative is an oxymoron for anything but simple cases. Imperative systems can express arbitrary complexity and you will n…
The lesson is that shockingly few people have realized is that the problem space is not, nor has it ever been, served by declarative solutions. You can describe the state you want a system to be in but there will inevitably be procedures involved to do some of the work. It is unavoidable . At the point people began developing templating around their configuration, ah, templates... which themselves have imperative lan…
I think the root of the issue is not that we need imperative languages for configuring cluster workloads - declarative state as an API contract between clients of the cluster and the cluster itself is a good thing. The reconciliation model is what makes kubernetes work, and that should be preserved.
But I do think we need better tools to generate said declarative state, regardless of its serialization format (yaml, JSON or other). Hand editing the raw declarative state is clearly untenable, hence the development of the various templating solutions. But I don't see an issue with using an imperative program to generate the declarative state either, as long as the declarative state is what forms the substance of the API to the cluster.
Re: Deploying Kubernetes with Ansible
#35I thought this was about deploying a Kubernetes cluster with Ansible, but nope, it's really about deploying YAML files to Kubernetes, with Ansible. Just...Why?
... oh god why.
Also thank you for the very apt and red flagging summary kind sir.
Re: Deploying Kubernetes with Ansible
#36Gosh, I wish the author wouldn't sound so arrogant presenting me his reinvented wheel. What your Ansible is doing (looping over the inventory, imperatively executing tasks) is reinventing what a Kubernetes-internal Operator is doing after you asked it to reconcile your changes. Thing is: You're not only reinventing the internal thing, you will eventually recreate internal logic, e.g. some internal dependencies and kn…
> kustomize and some _trivial_ scripting is usually all you'll need. So not just k8s alone, k8s + kustomize, no Helm charts, right? or can you do k8s + Helm, no kustomize? or can you do kustomize to deploy Helm charts which abstracts away and translates to underlying k8s API calls/generated YAML?
Yes
Re: Deploying Kubernetes with Ansible
#37Gosh, I wish the author wouldn't sound so arrogant presenting me his reinvented wheel. What your Ansible is doing (looping over the inventory, imperatively executing tasks) is reinventing what a Kubernetes-internal Operator is doing after you asked it to reconcile your changes. Thing is: You're not only reinventing the internal thing, you will eventually recreate internal logic, e.g. some internal dependencies and kn…
> kustomize and some _trivial_ scripting is usually all you'll need. So not just k8s alone, k8s + kustomize, no Helm charts, right? or can you do k8s + Helm, no kustomize? or can you do kustomize to deploy Helm charts which abstracts away and translates to underlying k8s API calls/generated YAML?
Hm take it with a grain of salt, but I'm not really a fan of Helm. It might make sense in some bigger corps where you have something like "Platform" teams with dozens of consuming teams to consolidate and version some kind of service. But I lack trust and frequently same-mindedness with Helm chart authors on how to deploy and configure certain things such that I'll use my own thingy anyway.
I forgot to mention the CD tools we have, e.g. Flux or ArgoCD. Use customize to render a "final" yaml for your env/version/whatever and throw it at Flux/Argo (e.g. using GitOps) and be happy. That's imho the Kubernetes way of life.
Re: Deploying Kubernetes with Ansible
#38I thought this was about deploying a Kubernetes cluster with Ansible, but nope, it's really about deploying YAML files to Kubernetes, with Ansible. Just...Why?
Yeah, title made me think kube-spray
Re: Deploying Kubernetes with Ansible
#39This went a different direction than I'd expected. That is, configuring your cluster resources rather than the host machines themselves. I managed to grab 5 or so Raspberry Pi 4s before the availability issues. I've been (slowly) getting a home Kubernetes cluster running over the last year or two, and Ansible helps immensely; I: * Write Ubuntu 20.04 (or now 22.04) to MicroSD card. * Configure the initial user + SSH-P…
Some of the other controllers in the Flux family are also nice. There's also the Terraform and Helm controllers and they all work in a consistent way and produce consistent metrics about what they're doing
Re: Deploying Kubernetes with Ansible
#40Earlier quoted context omitted.
`kubectl apply -f myshit/` is a faster way of getting things on your cluster, ansible is just a bunch of wrapper on top of that.
Until you need to update it, or apply it to multiple environments, or any number of tasks where the concepts of configuration parameters and dependencies become important. Edit: I'm not saying Ansible is an appropriate substitute (it absolutely isn't), rather that `kubectl -f` is not a scalable solution.
All I'm saying is ansible is essentially that and no it isn't at all scalable.