201–210 of 681 posts
For me, and many others: infrastructure as code. Kubernetes is very complex and took a long time to learn properly. And there have been fires among the way. I plan to write extensively on my blog about it. But at the end of the day: having my entire application stack as YAML files, fully reproducible [1] is invaluable. Even cron jobs. Note: I don't use micro services, service meshes, or any fancy stuff. Just a plain…
TIL about kudo, The Kubernetes Universal Declarative Operator. We've been doing the exact same things in a custom go CLI for 2 years. The kubernetes ecosystem is really amazing and full of invaluable resources. It's vast, complex, but well-thought. Getting to know all ins and outs of the project is time consuming. So much things to learn and so little time to practice...
Earlier quoted context omitted.
Yup, even monoliths can benefit from certain k8s tooling (HPAs, batch jobs, etc).
"What cron jobs does this app run?" Open cron.yaml and see. With schedule. Self documented. Amazing. Every time. Even when some as my k8s battle wounds are still healing (or permanently scarred). See other replies for more info.
The simple answer is that Kubernetes isn't really any of the things it's been described as. What it /is/, though, is an operating system for the Cloud. It's a set of universal abstraction layers that can sit on top of and work with any IaaS provider and allows you to build and deploy applications using infrastructure-as-code concepts through a standardized and approachable API. Most companies who were late on the Clo…
IaaS is not "the cloud". it was in 2008 when all we had was EC2 and RDS. Today Kubernetes is the antithesis of the cloud - Instead of consuming resources on demand you're launching VMs that need to run 24/7 and have specific roles and names like "master-1". Might as well rent bare-metal servers. It will cost you less.
Long term, but up front costs are what make cloud services appealing.
FWIW, it's possible to minimize your idle VM costs to an extent. For example, you could use one or more autoscale groups for your cluster and keep them scaled to one vm each. Then use tools like cluster auto scaler to resize on demand as your workload grows. You are correct that idle vm costs can't be completely avoided. At least not as far as I am aware.
Earlier quoted context omitted.
How are you deploying the workloads into the cluster? Manual kubectl or Helm, GitOps with something like Flux, something else?
Alas, still rely on bash for that. Practically a one liner. Mainly just kustomize piped into kube apply. But, but, but. Having to a create a one-off database migration script imperatively.
Earlier quoted context omitted.
Out of curiosity, are you using terraform to deploy k8s, your app stack on k8s, or both?
To follow this - what do you feel K8S provides on top of terraform? We used K8S on a large project and I felt like it really, really wasn't necessary.
Earlier quoted context omitted.
Have you tried or considered Nomad (from the makers of Terraform)?
can it handle networking (including load balancing and reverse proxies with automatic TLS) or virtualized persistent storage? Make it easy to integrate common logging system? Cause those are the parts that I miss probably the most when dealing with non-k8s deployment, and I haven't had the occasion to use Nomad.
What Nomad doesn’t do is setup a cloud provider load balancer for you.
For persistent storage, Nomad uses CSI which is the same technology K8s does: https://learn.hashicorp.com/nomad/stateful-workloads/csi-vol...
Logging should be very similar to K8S. Both Nomad and K8S log to a file and a logging agent tails and ships the logs.
Disclosure, I am a HashiCorp employee.
Earlier quoted context omitted.
Even though Ansible is declarative in spirit, in practice I feel like a lot of playbooks just read like imperative code.
I use Ansible for managing my infra, and the only time my playbooks look imperative is when I execute a shell script or similar, which is about 5% of total commands in my playbooks.
Earlier quoted context omitted.
Doesn't kubernetes also have autoscaling capabilities? https://kubernetes.io/blog/2016/07/autoscaling-in-kubernetes...
That is autoscaling within the cluster.... not the cluster itself. Although, managed kubernetes clusters let you auto-scale the cluster itself, so i think the GP is wrong.
This tool allows you to autoscale the cluster itself with various cloud providers. There is a list of cloud providers it supports at the end of the readme.
Earlier quoted context omitted.
Hmm really? My experience is that, with k8s I end up learning all the complexities of k8s in addition to AWS. Besides, personally I find AWS console much easier to understand. I don't get why people hate it.
> I don't get why people hate it. Because it is hard to manage the configuration. It's why tools like terraform exist. Anecdote. I worked for a small company that was later acquired. It turned out one of the long time employees had set up the company's AWS account using his own Amazon account. Bad on it's own. We built out the infra in AWS. A lot of it was "click-ops". There was no configuration management. Not even…
+1 for "click-ops", perfectly put.