221–230 of 433 posts
Earlier quoted context omitted.
Please, do not manage deployments with imperative kubectl commands, I beg of you.
This is a declarative kubectl command.
[0] https://kubernetes.io/docs/tasks/manage-kubernetes-objects/i...
Kubernetes is a Google scale solution. Lots of teams said “hey if Google does it then it must be good!”…but forgot that they didn’t have the scale. It caught on so much that for whatever reason it’s now the horrendous default. I’ve worked on at least 3 consulting projects that incorporated K8s and it slowed everything down and took way too much time, and we got nothing in return - because those projects only needed s…
Asking as someone who has only tipped his toes into devops lately and is looking to learn K8, what is considered a reasonable "lightweight" alternative to Kubernetes these days?
The premise of your question is invalid. Have you ever tried setting up a Kubernetes cluster and deploying apps in it? Kubernetes doesn't save work, it adds work. In return, you get a lot of benefits, but it wasn't designed to reduce human work, nor was it designed to eliminate devops jobs. It was designed for scalability and availability more than anything. Most people using Kubernetes should be using something simp…
Earlier quoted context omitted.
Anybody who watched "Kubernetes: The Documentary" knows the answer: https://youtu.be/BE77h7dmoQU Kubernetes only exists, because Google lost the Cloud Wars, and this was their Hail Mary pass.
And I might cynically offer it was "invented" to solve the problem of ex-googlers not having any useful immediately transferable skills as the Google internal tech stack had nothing in common with industry.
All this is not to say that Kubernetes is the right solution to your problem, or to almost anyone's problem. It was just an improvement to Google's infrastructure, for the sort of problems that Google had. For some people it makes sense... for you it might not.
The premise of your question is invalid. Have you ever tried setting up a Kubernetes cluster and deploying apps in it? Kubernetes doesn't save work, it adds work. In return, you get a lot of benefits, but it wasn't designed to reduce human work, nor was it designed to eliminate devops jobs. It was designed for scalability and availability more than anything. Most people using Kubernetes should be using something simp…
It could have been designed better to be easier to set up and use. Especially for ad-hoc or more casual use. If it is easy to use casually, people will use it more and they will learn how to use it faster. It is also easier to see why you would invest in learning to create more complex configurations. Pretty much every piece of software I've written in the past decade that tends to have configs in production can also…
Of course, there's a huge cost to building your own framework as well... And it's easy to get wrong.
I started https://www.jetpack.io/ recently to try and build a better solution on top of Kubernetes. If you're interested in checking it out and giving us early feedback, you can signup on the website, or email us at `demo at jetpack.io`
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…
Moreover, people in this thread also don't know what "declarative" means. The patch is declarative, and "declarative" doesn't provide the claimed benefits. For example, as with the patch command, I can create, apply, and delete a Kubernetes manifest file (indeed, I can apply directly from stdin!) and there is no additional record of the change beyond that which would exist if I had just applied the patch.
Earlier quoted context omitted.
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…
It's not drift, because the infra-as-code doesn't manage the image field (the application's CD pipeline does). You don't trawl through someone's shell history', you look at the CD pipeline history. Rollbacks are easy--you just deploy the prior version via your CD tool. I think you're assuming that invoking kubectl means invoking it directly from a user's command line , but kubectl can also be called in a CD script.
It helps standardize:
- deployments of containers
- health checks
- cron jobs
- load balancing
Is it same/similar across teams within and outside your organization.
If not, what would it cost to build consensus and shared understanding?
How would you build this consensus outside your organization?
For small organizations, one should do whatever makes them productive.
However, as soon as you need to standardize across teams and projects, you can either build your own standards and tooling or use something like K8S.
Once you have K8S, the extensibility feature kicks in to address issues such as:
- Encrypted comms between pods
- Rotating short lived certificates
However, if not K8S then, what alternative should we consider to build consensus and a shared understanding?