181–190 of 433 posts
Earlier quoted context omitted.
I've said it before, and I'll say it again: Kubernetes is hard, huge, complex because it solves hard, huge, complex problems. Or tries to anyway.
The corollary of course is that if you don't currently have hard, huge, complex scalability problems, well, you do now...
Earlier quoted context omitted.
> Have you ever tried setting up a Kubernetes cluster and deploying apps in it? Kubernetes doesn't save work This is wrong, deploying on Kubernetes is easy and quick for most apps, you have one docker image one deployment spec and that's it. https://kubernetes.io/docs/concepts/workloads/controllers/de...
And a service configuration, ingress, other networking, persistent volumes, a mechanism for updating deployed applications, management of the nodes (even with a managed service like EKS or other cloud solutions), logging, roles, security, etc. If you're a developer and all you have to worry about is one deployment spec, thank your devops team for making your life easier. Kubernetes is great for making the dev team's…
A day's work for one person to accomplish that isn't bad, IMO, but what that doesn't capture is the literal weeks I spent poring over documentation, trying things, running tests, learning what didn't work (Rook + Ceph is a nightmare), and so on. I went so far the day before the cutover as to recreate my homelab in Digital Ocean and run through the entire installation process.
Having services that magically work is hard. Having a golden path so you can create a new one with a few clicks is even harder.
Someone put it nicely when they said Kubernetes is like an operating system for containers. If you take linux as an analogy, it's clearly a non-trivial investment to learn linux and learn enough to be effective and efficient in it. Further time perhaps needed to achieve the productivity, functionality and performance of what you were used to on Mac or Windows. Kubernetes definitely achieves this goal well, and in a r…
Earlier quoted context omitted.
I probably wouldn't do this, but what problem does this cause?
Drift, as the other child comment mentions, but also loss of version control. I do not want to have to trawl through someone's shell history to figure out what they changed, nor do I want to have to redirect `kubectl get foo -o yaml` output into diff. If everything is in code, and you have a reasonable branching strategy, it's much easier to control change, to rollback bad merges, to run pre-hooks like security check…
Earlier quoted context omitted.
I hear you about feeling dumb. I think some early decisions in the k8s ecosystem led to a lot of wasted time and effort, and this frustration. YAML: significant whitespace is always unwelcome but YAML also introduces unexpected problems, like how it deals with booleans. For example, say you have this array: foo: - x - y - z You might think this is an array of strings, but you'd be wrong. It's also difficult to read t…
Is that yaml not an array of strings? ["x","y","z"]
Earlier quoted context omitted.
Couldn't agree with this more. At my last company there was a fair bit of time put into making the deployment process for our microservices as simple as added a new YAML file to the deployment repo. That file pulled a custom chart, and as a dev you just needed to configure a few variables to get everything up an running. But if you were deploying something that couldn't use one of the pre-configured charts it was a b…
You can now do something similar with Bunnyshell.com It Handles the devops jobs for dev teams. Full disclosure, I work for Bunnyshell.
Earlier quoted context omitted.
I probably wouldn't do this, but what problem does this cause?
The declarative approach is a more sustainable way to run Kubernetes. If you define some desired state in manifests and apply them to a cluster, they can be applied again to new clusters or the same one and Kubernetes will attempt to maintain the desired state. This state can be version controlled, written in stone, whatever you prefer and it can always be attained. When administrators start issuing imperative comman…
Firstly as you point out, there is a record of the state Kubernetes is being asked to maintain: it's in the API server as the spec of each resource.
Secondly, using `kubectl` "patch" in the manner described is not making changes to the cluster state directly, it's making changes to the specification of what should be maintained, and the various controllers effect the state changes.
Fundamentally, the argument seems to come down to "you don't have a record of what you once asked the API server to do", and that's fair enough - you don't. But that has nothing to do with imperative or declarative models.
I'm not advocating actually doing this on a day-to-day basis, but the arguments against it are not ones of imperative vs declarative.
I have no data to back this up, but my hypothesis is that if you zoom out, and look across the entire industry, the % is vanishingly small. It may seem like every company is running or adopting kubernetes within our bubbles but our perspective is biased.
(Note: I'm not espousing an opinion on kubernetes itself, just about it's total adoption across the entire industry and how that effects the number of devops/sysadmin/SRE roles.
Earlier quoted context omitted.
> so there are more niches where hiring someone to babysit a few hundred VMs is profitable This makes a lot of sense. The same thing happened in the past with new technology, such as the electronic spreadsheet: "since 1980, right around the time the electronic spreadsheet came out, 400,000 bookkeeping and accounting clerk jobs have gone away. But 600,000 accounting jobs have been added." Episode 606: Spreadsheets!, M…
Basically, "why technological innovation creates and transforms jobs, instead of causing unemployment".