Live data from Hacker News

Deploying Kubernetes with Ansible

erichreich.com

11–20 of 61 posts

Re: Deploying Kubernetes with Ansible

#11
post #9

This 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…

`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.

Re: Deploying Kubernetes with Ansible

#12
Wat? If you really need to, you can use Ansible to bootstrap a cluster but I wouldn't use it for anything more than that - that's the responsibility of CD. Ideally you would just have Terraform apply a manifest that installs Argo or Flux and that's it.

Re: Deploying Kubernetes with Ansible

#13
post #2

As your cluster grows, so does the complexity of managing it. That's where Ansible comes in.

I completely agree that for managing the host nodes/machines, Ansible is a huge win. Though this article focuses on deploying ON the cluster.

Ideally the complexity of deploying ON a cluster (i.e. 'kubectl apply') doesn't increase with its size. In some ways it actually gets simpler, as you can worry less about per-node scheduling due to resource constraints/packing.

Re: Deploying Kubernetes with Ansible

#14
post #4

I 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 language constructs awkwardly (and badly, cough Golang) embedded in them, it should have been clear to everyone with a shred of talent that it wasn't a good solution.

Declarative configuration is wholly expressible by imperative languages. The converse is not true. Declarative configuration is appropriate for declaring state (i.e., values), and not for describing procedures.

Stop using half-baked YAML crap and start using real tools.

Re: Deploying Kubernetes with Ansible

#15
post #9

This 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…

`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.

Re: Deploying Kubernetes with Ansible

#16

Earlier 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.

[deleted]

Re: Deploying Kubernetes with Ansible

#17
post #9

This 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…

`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.

And when you outgrow it you can move on to `kubectl apply -k`...

Re: Deploying Kubernetes with Ansible

#19
post #5
post #3

My conclusion is that using Ansible with Kubernetes is the WRONG way to go about it. So now instead of a directory of yaml or helm charts we have a bunch of ansible uselessly wrapping the yaml for application.

The problem is when you're in a situation where "over here we need YAML document A, and over there we need YAML document B." You either shove a templating system in front of your YAML and fight with that or throw in the towel just use a programming language where constructs in your YAML map to objects.

Helm3 made it a solved problem years ago.

Re: Deploying Kubernetes with Ansible

#20
post #5
post #3

My conclusion is that using Ansible with Kubernetes is the WRONG way to go about it. So now instead of a directory of yaml or helm charts we have a bunch of ansible uselessly wrapping the yaml for application.

The problem is when you're in a situation where "over here we need YAML document A, and over there we need YAML document B." You either shove a templating system in front of your YAML and fight with that or throw in the towel just use a programming language where constructs in your YAML map to objects.

I think we need to burn this whole thing down and rethink it at this point. A huge amount of the total operational cost of our business is working around weird YAML problems and helm charts.

Had one a while back where quoted strings containing padded numbers in were used for something. "01" fine ... "05" fine, "06" fine, "07" fine, "08" kaboom. 01-07 were treated as strings and 08 was suddenly being treated as octal, which it's not and exploded.

Post reply on HN