TLDR: Kubernetes is an anti-pattern.
The future of Kubernetes is virtual machines
111–120 of 128 posts
Re: The future of Kubernetes is virtual machines
#112Earlier quoted context omitted.
You don't need them until you're hired by a client with nation-wide deployment requirements, and then you need them.
Not necessarily. Needless to say containers and kubernetes are pretty new technologies and nation wide deployment requirement existed before docker / k8s. Most of the old big companies aren't using docker or k8s for their core services. They're all using legacy fat apps that are load balanced in baremetal or vms.
I doubt a home-made solution to load balancing will be seen as simpler, which is what's being argued by the comment I replied to.
The point isn't that you need Kubernetes specifically, it's that requiring a system that scales well is not as uncommon as the OP puts it.
Re: The future of Kubernetes is virtual machines
#113Earlier quoted context omitted.
That's a very simplistic view on the issue. Most businesses do not have a constant workload 24/7, which means the ability to scale up and down will save more money than reducing the overhead of not running directly on metal. There is also the cost of having to care about hardware to begin with. Also, in the big picture, having 100 companies doing their own bare metal deployments is not terrible efficient, compared to…
This sounds like classic devops/cloud snake oil. I wonder what industry pays your bills? * The most businesses/always on reasoning appeals to executive decision makers and rolls down hill to the technical people who are best educated to make the decision. Many people who believe that you can cut cost by sizing workloads end up racing their own models when it doesn't scale financially or computationally over time. * W…
> Yes, monopolies are healthy.
Seems all 3 major cloud providers, aws, google and azure, are providing facilities to run docker containers. Seems Digital Ocean is getting there too. Hardly a monopoly, init?
> What is so difficult about hardware?
All of it. This is knowledge my company doesn't have and there is no point in investing in accuiring this knowledge at this time, since we have an easier solution. Not to mention that if we decide going bare metal is the way to go, we can do that later.
> The most businesses [...]
I think my english is failing me, I don't really understand this paragraph.
> This sounds like classic devops/cloud snake oil. I wonder what industry pays your bills?
Not the snarky remarks industry...
Re: The future of Kubernetes is virtual machines
#114An important element of Kubernetes is that it standardizes the infrastructure control plane, and allows different pieces to be plugged in (for networking, storage, etc.). The "virtual kubelet" essentially throws that all that away and keeps Kubernetes "in API only". For example, with virtual kubelets, scheduling is meaningless and networking and storage are restricted to whatever the virtual kubelet target supports (…
What we need is an open technology stack such that we can get full standardization and integration with k8s and other systems. We might get that with RISC-V.
Re: The future of Kubernetes is virtual machines
#115Earlier quoted context omitted.
I agree with you, being in the same position. I wonder if the DevOps trend started because of the constant friction between devs and ops. While devs main concern and job is to deliver new features, ops main concern and job is to keep things stable. These different goals caused ops to be seen as an obstacle to dev job. Being the devs close to the business was easy to predict that we would be taken out or at least requ…
It has become manageable to do both for one person.
But not allowed in many many organizations and firms.
Governance and security forbid people to be op and dev in one person.
Or God forbid: control the dev, pre stage and production environment.
Re: The future of Kubernetes is virtual machines
#116Earlier quoted context omitted.
Not necessarily. Needless to say containers and kubernetes are pretty new technologies and nation wide deployment requirement existed before docker / k8s. Most of the old big companies aren't using docker or k8s for their core services. They're all using legacy fat apps that are load balanced in baremetal or vms.
I doubt a home-made solution to load balancing will be seen as simpler , which is what's being argued by the comment I replied to. The point isn't that you need Kubernetes specifically, it's that requiring a system that scales well is not as uncommon as the OP puts it.
k8ts is not the only avenue to building scalable systems -- scaling is mostly about architecture, not how you run your software.
Re: The future of Kubernetes is virtual machines
#117Earlier quoted context omitted.
I don't have an example to hand, so it's obvious I went on second-hand accounts. Do you have something you'd normally point customers to when describing the tradeoffs? For myself I see the argument for fewer clusters as about utilisation, the argument for more clusters about isolation. It's the oldest tug-of-war in computing. I think that shared node pools for multiple masters is going to be the combination that for…
It's also about tooling. I've seen many clusters being sold, but with no tooling to automatically build, monitor, secure and maintain these clusters, so you've got a DevOps team playing cluster wack-a-mole. Of course the consultancies love that because it's a bespoke layer for them to build and support, but the reality is setting up a small team to run a couple of clusters eases the job of discoverability and secops,…
> It's also about tooling. I've seen many clusters being sold, but with no tooling to automatically build, monitor, secure and maintain these clusters, so you've got a DevOps team playing cluster wack-a-mole.
Pivotal's doctrine of how to use Kubernetes is explicitly multi-cluster oriented, but that's because we come to the table with tooling that excels at this kind of problem: BOSH.
Re: The future of Kubernetes is virtual machines
#118Earlier quoted context omitted.
> I don't think multi-tenancy has been "retrofitted" onto Kubernetes. Kubernetes was designed with multi-tenancy in mind from the very early releases -- namespaces, authn/authz (initially ABAC, later RBAC), ResourceQuota, PodSecurityPolicy, etc. My complaint is that these require assembly and are in many cases opt-in (making RBAC opt-out was a massive leap forward). Namespaces are the lynchpin, but are globally visib…
> The biggest is going to be utilisation. Combining workloads pools variance, meaning you can safely run at a higher baseline load. Utilization is arguably the biggest benefit (fewer nodes if you can share nodes among users/workloads, fewer masters if you can share the control plane among users/workloads), but I wouldn't under-estimate the manageability benefit of having fewer clusters to run. Also, for applications…
I'd like to understand more about your second paragraph, since it shapes some of the work I want to do in 2019. What should I be reading or looking up?
Re: The future of Kubernetes is virtual machines
#119Earlier quoted context omitted.
I don't have an example to hand, so it's obvious I went on second-hand accounts. Do you have something you'd normally point customers to when describing the tradeoffs? For myself I see the argument for fewer clusters as about utilisation, the argument for more clusters about isolation. It's the oldest tug-of-war in computing. I think that shared node pools for multiple masters is going to be the combination that for…
In Red Hat OpenShift Consulting, we openly advise against “One cluster to rule them all” and the vast majority of our customers heed our advice. Our default delivery models support Sandbox, Nonprod, Prod cluster stand up. Some of us even support the idea that good IaC/EaC practices get our customers to where the cluster can be treated like cattle (much like pods and containers) in well-designed apps. My colleague Raf…
> In Red Hat OpenShift Consulting, we openly advise against “One cluster to rule them all” and the vast majority of our customers heed our advice. ... My colleague Raffaele hinted as much when describing the problem as a matter of availability, disaster recovery and federation [0].
To be honest, I should have realised this would be so.
> At least in OpenShift, multi-tenancy is a solved problem when cluster right-sizing has taken place. RBAC, node labels and selectors, EgressIP, quotas, requests and limits, multi-tenant or networkpolicy plug-ins go a long way.
Well, as you can guess, I am not convinced that this is really solved -- it looks like multiple discretionary access control mechanisms that need to be aligned properly, instead of a single mandatory access control mechanism to which other things align.
Re: The future of Kubernetes is virtual machines
#120Earlier quoted context omitted.
Very much this. People time is always the biggest cost. Docker and Kubernetes have been a game changer in time-to-production. Unless you need maximum performance out of the biggest iron available, it's cheaper to buy the next tier of EC2 instance than to waste developer and operations staff time trying to squeeze more out of existing servers. There are many levels of abstraction, but...who cares? It's about productiv…
> People time is always the biggest cost It really depends on scale. If I spend 15 minutes improving the utilization of my home cluster by 10%, the only payoff I get is experience. If I do the same to Google's indexing infrastructure, I probably delayed the collapse of civilization by global warming by a full year. This attitude leaves a lot of low-hanging fruit that, as the operation grows, can shave a couple millio…
[deleted]