Kubernetes reinvented virtual machines in a good sense

https://iximiuz.com/en/posts/kubernetes-vs-virtual-machines/

by paulgb • 4 years ago

186 196 4 years ago

On the darker side, inefficient scaling (due to uneven daily/yearly traffic distribution), overly complicated deployments (delivering code to many boxes quickly is hard), and fragile service discovery (have you tried running consul or zookeeper at scale?) would lead to higher operational costs.

Obviously, everyone's use-case is different but none of this has been my experience with VMs:

- Both AWS and GCP allow you to define custom scaling policies for an instance group.

- Deploying new code just means updating a template with your new image and pushing that out. Both GCP and AWS would then cycle the existing machines automatically to use this new image.

- At least in our case, there is no need for Service Discovery; you just need to know where the Load Balancer is.

We have moved some things to Kubernetes and now have to deal with inexplicable occasional failures. That and an everyday massive YAML headache.

YMMV

awoimbee• 4 years ago

IMO it takes time to get up to speed but then it's pure bliss in terms of reliability. And don't go to yaml hell, use pulumi or equivalent.

x86x8724• 4 years ago

it's pure bliss in terms of reliability

narrator: it is not. you're not trying very hard if you haven't hit a case where k8s will lead to you banging your heads on any available walls trying to understand a behavior in an edge case (here is one that made walls hate me: https://github.com/kubernetes/kubernetes/issues/96858 and I know of a half dozen developers that learned about this the hard way).

jbverschoor• 4 years ago

I thought we had this kind of covered 20 years ago with J2EE

jayd164• 4 years ago

Doesn't really handle multiple process isolation and IPC as well.

cassianoleal3• 4 years ago

It also doesn't really handle anything that doesn't run on the JVM.

pjmlp4• 4 years ago

It surely does via multiple application servers, and using CORBA/RMI as IPC.

rwmj• 4 years ago

Wouldn't you want to use KubeVirt for this?

z3t4• 4 years ago

The bus factor - your engineering skills that took you 20+ years to acquire are worth nothing if you can't be replaced...

hinkley3• 4 years ago

It’s astounding how long companies can ignore this about their people. Acknowledging that kind of power in an employee probably messes up the power dynamic in uncomfortable ways.

I recently learned that one of the heads of SpaceX is heading his own company now. It’ll be interesting to see if his bus number was high enough that the wheels stay on, if the symptoms will be obvious if it wasn’t, or if they will be explained away by other phenomenon. I have had enough successful bosses that credited the wrong actions that it stands to reason that most failures are also blamed on the wrong chain of events. I know my own narratives in 5 Why’s situations are often in stark contrast to other theories.

mgfist• 4 years ago

It’s astounding how long companies can ignore this about their people.

Is that really a problem? Companies churn people exceptionally fast these days. That inherently involves dealing with the bus problem.

x86x8724• 4 years ago

Did K8s reinvent VMs though? People keep forgetting that vm!=container and the security posture is completely different. Also, for the amounts of complexity K8s adds it's not worth the overhead in 95% of cases (i get it that it's cool and everyone and their dog want to claim they have experience with it - I am affraid that once the "movement" fizzles out we're going to be stuck with a lot of things that are over-overengineered)

k8sToGo4• 4 years ago

Do you know kubernetes or are you just jumping on the hate train?

Can't you argue with that logic against everything remotely complex? If you have people who know how to use it, then why not use it? Would you say the same about complicated engineered car engines?

jmspring• 4 years ago

He has a point, containers and VMs are not the same.

de6u99er• 4 years ago

Do you know kubernetes or are you just jumping on the hate train?

It seems rather that you don't know what kubernetes is. His comment is justified. You can put your pitchfork back.

Can't you argue with that logic against everything remotely complex? If you have people who know how to use it, then why not use it? Would you say the same about complicated engineered car engines?

It seems that you don't understand ehat he's trying to say.

benreesman6• 4 years ago

I actually know k8 as well as another Borg-alike (Tupperware) that actually runs at Borg-like scale.

GP is absolutely right that it is insane overkill with no conceivable way to pay back the complexity investment in all but a few niche cases. Working at a FAANG isn’t the only niche where full-Kube makes sense, there are others, but it’s a niche thing, with the niche being roughly: I rack and run physical gear on a limited number of SKUs at “cattle not pets” scale.

If you’re on a cloud provider? You’ve already got secure, restartable, restorable, on-demand-growable, discoverable, fail-over-able, imaginary machines a zillion times more robust than any half-assed Borg-alike setup most people would come up with.

They’re happy to take your money if you yo dawg like imaginary computers so I put a docker in your Xen VM so you can Kubernetes while you pay me big bucks, but that’s because they’re not running charities.

x86x8724• 4 years ago

I know what it is, have worked with k8s, with borg and another half dozend similar systems.

Saying that you should use it because people know does not hold water. Also, anecdotally very few people understand k8s (setup and running it). Most people just know how to deploy apps on it (and even there most impressionable are young devs that haven't done things in a preK8s world)

MBCook2• 4 years ago

I thought the article went through the whole evolution from boxes to VMs to containers to K8 very well.

It’s so much more than it’s headline.

codsane• 4 years ago

Yeah I’m not sure if it’s the Reddit mentality at play here or actual outage but it just always seems like these types of comments are reacting to a headline, it is unfortunate.

x86x8724• 4 years ago

Docker containers have been deliberately designed to contain just one application.

What is a docker container? As a matter of fact: what is a container?

orwin3• 4 years ago

I am currently overengineering my previous work to run it inside kubernetes. It isn't my decision, i just asked for a VM and the access to ansible, but the chiefs wanted to use kubernetes for everything.

I don't think this is that bad tbh. I runs my unit tests on container construction and while it was tedious to develop, mostly because i cannot run docker on my work PC, i understand that it makes it easier to inventory and check the advancement. The management will always love it, so i think kubernetes is here to stay. Not because it solve a lot of engineering issues (not for me anyway, i'd rather run a cron in my VM than declare a kube cronJob), but because it solve a lot of other fondamental issues for the management (inventory, visibility on existing/running projects. And everybody use the same system without using the _same_ system.)

Already__Taken• 4 years ago

while it was tedious to develop, mostly because I cannot run docker on my work PC

Have a look at tilt.dev You can get it to build in-cluster too so you only need the CLI. I've really enjoyed its workflow.

Or try podman-remote. Should be easier to get those CLI tools on your work PC.

CameronNemo• 4 years ago

Our k8s based deployments go so much smoother than our VM based deployments (Ansible). We have centralized logging set up for k8s, but not VMs. We have post-update health checks for k8s pods, but not systemd services. Et cetera.

k8sToGo4• 4 years ago

I don't know about your team, but in our team I try to move as much as possible to kubernetes so I have a common way of deployment across all members. Of course if you are just thrown into the cold water without help from the Kubernetes guys, it will suck.

Also I noticed that once developers "get it", they actually like it a lot.

sporkland• 4 years ago

Why can't you run docker on your work PC? If it's the licensing issues I'd recommend using lima-vm (https://github.com/lima-vm/lima) as a substitute.

pravus• 4 years ago

I've always said that it reinvented the mainframe by turning it inside-out. I did some work on an IBM 360/370 running VM/CMS and I can see a lot of parallels in how both systems operate. Most of the architecture is an interface that is implemented by some pluggable piece of software and there's also all of the resource scheduling and management which is a first-class component. This makes the system very flexible and reliable.

And I think k8s is here to stay. If what you have is a bunch of containers you can easily push that into k8s. It's not any more complex than any other solution you would use to deploy them.

x86x8724• 4 years ago

We'll see. Containers are definetly a thing and have their usecase. K8s as a whole? Imho the jury is still out.

jstx1• 4 years ago

I don't think it's fizzling out, it's kind of becoming a basic standard. And if your use case is simple enough to not need Kubernetes, then doing it with Kubernetes isn't that much more complicated either.

jiggawatts6• 4 years ago

A standard in the Linux world. Windows doesn’t have “distributions”, so there’s less need for containers in that space. Microsoft uses Service Fabric internally for the Azure back-end, which covers most of the other use-cases of Kubernetes.

x86x8724• 4 years ago

Lol. Famous last words. IMHO K8s is a trojan horse from Google. They are irrelevant in the cloud space and are trying to stay in the game.

K8s is not Borg. Not even close. It's a toy that has limited use.

The revolutionary tech is the Linux kernel features that enabled containers, overlay filesystems and docker image format.

gofreddygo• 4 years ago

Did JVM reinvent VM? Is it a VM or a container?

No one (not enough people?) asked (cared?) for this about the JVM for like 25 years till Linux Cgroups came around and Docker capitalized on it. Its not VM v/s container question that we care about. (I am aware this is a very poor comparison but so is comparing a vm to a container, which is my point)

K8S brings complexity yes, and in a consistent, predictable way. The biggest difference between a k8s based shop vs a DIY VM/Container shop is the former can (in theory) hire some people with intermediate K8S experience, and have them sort out the mess that the people without that experience (or more typically the ones who don't have clear requirements) may have created. With k8s it becomes more predictable to find the boundaries and start pulling things apart in production and make incremental changes. Without k8s, making changes to a production setup is a nightmare that folks who have done that sort of thing don't ever want to repeat.

aprdm• 4 years ago

That’s true if your shop didn’t create a bunch of custom controllers or apis inside the k8s world… or forked it.

x86x8724• 4 years ago

Are you running the k8s control plane yourself? Are you keeping it up-to-date?

pacarvalho• 4 years ago

Agree. As someone that has had to migrate systems from K8s to Elastic Beanstalks or equivalent, there are definitely situations where K8s is overkill and simpler systems can work better.

dijonman2• 4 years ago

I’m not too proficient with containers so maybe I am ignorant, but I view containers more like a package manager.

A proper golden image pipeline can work well, and you can rightsize your workloads easily.

All of the additional features such as ingress controllers and other complexities make debugging a bit obtuse, especially if you are not extremely proficient.

I could be an old curmudgeon but simplicity is my priority.

lamontcg2• 4 years ago

I am also an old curmudgeon.

I think its vastly more useful to think of a container as an RPM with layered tarballs, a chroot/jail, and some cgroup isolation.

Thinking of them as a virtual machine is the wrong metaphor.

Kubernetes replaces the thing we were doing in 2003 blasting around tarballs of software with scp and some scripts to start and stop things, and is the end result of evolving from that point to a much more dynamic one and with cgroups providing the ability to have software teams not quite clobber each other's workloads while running on the same hardware.

The problems it solves overlaps with many of the problems that VMs were addressing, but it is like looking at two different species that look quite similar but are in completely different animal families and are just similar because of the similar environment they evolved in.

vbezhenar10• 4 years ago

How ingress controller makes debugging obtuse? You're using nginx in front of your services anyway, right? Ingress controller is just nginx with some tool autogenerating its config from kubernetes objects. You can view nginx logs easily.

aceBacker• 4 years ago

Kubernetes isn't that complicated, it's distributed computing that is complicated. Kubernetes makes it as simple as it can be without oversimplifying it.

josh2600• 4 years ago

Just wanted to chime in and hard agree on this. I remember the world where people were trying to build things like kubernetes before it existed. There was a period where enough people had left google post ipo to realize that they needed something like borg but nothing really existed like that outside of elgoog.

Twitter had Aurora, then elsewhere mesos and mesosphere popped up and it seemed like there were going to be about 100 different frameworks until Kubernetes dropped and basically ate the industry alive. K8s feels pretty stable from where I’m sitting.

deepGem• 4 years ago

To understand how difficult distributed computing is, at the container level of abstraction, one has to try Docker swarm.

zozbot2343• 4 years ago

K8s is trying to do distributed computing on a low-level OS platform that was never developed or designed for this purpose. Look at things like plan9 to see how much easier and more elegant it could be. Sure, plan9 doesn't provide k8s' autoscaling and provisioning features out of the box but the basic building blocks are all there. (And no, Linux is nowhere close to providing these patterns because custom user-space implementations of kernel-side features are only made possible on a totally ad-hoc basis.)

jayd164• 4 years ago

You have to admit that it's tuned towards stateless and loadbalanced workloads, though. Not every workload fits into the k8s box. I like k8s but for everything else, k8s can make things overly complicated.

ikiris• 4 years ago

Having worked on the system it’s based on: no it could be much simpler.

KronisLV• 4 years ago

Kubernetes makes it as simple as it can be without oversimplifying it.

What about something like Hashicorp Nomad and Docker Swarm? The popularity of the former and the maintenance status of the latter aside, I think they achieve much of the same as Kubernetes in ways that are simpler, which is enough for the majority of deployments out there.

For example, most pieces of software that run in containers have a docker-compose.yml file which can then be fed into Docker Compose to launch an environment on a single node, say for local testing and development, or to just explore a piece of software in a throwaway environment. What Docker Swarm does, is take basically the same specification and add the ability to run containers across multiple loads, do networking across them in a reasonably secure way, whilst being able to set up resource limitations etc. as needed, as well as scale the containers across the available nodes and manage storage with volumes, bind mounts or even plugins for something like GlusterFS or just NFS.

Docker Swarm doesn't concern itself with the concept of Pods because you don't always need those - regular containers can be enough without the additional abstraction in the middle. Docker Swarm doesn't concern itself with the concept of a Service, since you can just access containers based on their names through the built in DNS abstraction, especially if you don't need complicated network isolation (which you can also achieve at server level). Docker Swarm doesn't really care about an Ingress abstraction either, since you can just make your own Nginx/Caddy/Apache container and bind it to ports 80 and 443 on all of the nodes where you want to have your own ingress. No PersistentVolume and PersistentVolumeClaim abstractions either, since the aforementioned bind mounts and volumes, or network storage are usually enough. And the resource usage and API are exceedingly simple, you don't even need to worry about service labels or anything like that, since in most cases you'll only care about the service name to access the container through.

If I built my own container orchestrator, I'd strive for that simplicity. Seems like projects like CapRover also recognized that: https://caprover.com/ Same with Dokku: https://dokku.com/

If you're in a company that has never really run advanced A/B tests or doesn't really need to do complex 2-stage DB migrations or blue-green deployments, circuit breaking and other fancy stuff, there's not that much use in going with Kubernetes, unless you really just want to hire for it and also pay someone else to manage it for you.

Personally, with tools like Kompose https://kompose.io/ I'd advise that you start with Docker and Docker Compose at first (locally, or for dev environments) and then branch out to Docker Swarm or Nomad, before eventually migrating over to Kubernetes, if you need to, maybe with something like K3s or K0s clusters at first. Or maybe even Portainer/Rancher, since those make the learning curve of Kubernetes far more tolerable. Or, at the risk of increasing the complexity of your deployments, go with Helm as well because the templates for Deployments and other objects that Helm creates by default are surprisingly useful in avoiding YAML hell.

Of course, some say that Docker Swarm is dead and you shouldn't ever touch it, which is why I mention Nomad (even though HCL is a little bit odd at times), which is also great, with the added quality of supporting non-container deployments. Either way, ideally look for a way to run apps in containers because they feel like the "right" abstraction, whilst finding the best fit for the features that you actually need vs the complexity introduced.

In short: containers are pretty good, running them has lots of options, although some are indeed complicated. Kubernetes is not the simplest way to run them, in my experience.

closeparen• 4 years ago

Running a microservices architecture on a shared cluster is complicated.

* Because you are running multiple workloads on the same kernel, you need to protect them from each other, from both correctness and performance perspectives.

* Because the workloads have different scaling characteristics, you need to solve a bin-packing problem to make efficient use of the resources.

* Because of said bin-packing, workloads move around a lot, so you invite a service discovery problem much more intense than classic DNS is meant to solve.

* Because normal software only knows how to use DNS, you invite the need for sidecars and virtual network overlays.

When you have this set of problems then k8s seems appropriate. I work at a company with this set of problems but no Kubernetes, and boy is it a production. But my takeaway from that is less "use Kubernetes" and more "try not to have those problems." Use relatively monolithic architectures, one or a few services on their own stable pools of nodes, with boring old reverse-proxy load balancers and DNS, for as long as you possibly can.

remram• 4 years ago

I don't know if I would agree with that. Using Kubernetes on a good day is not complicated, but it does have a lot of moving parts. There are many different flavors and distributions of Kubernetes, a lot of concepts that can prevent your workloads from running (because system pods taking too much resources, affinity, persistent storage, kubelet/etcd/apiservers cyclic dependencies, x509 certificates). An actually HA Kubernetes deployment needs an external load-balancer for no reason at all (kubelet could talk to multiple apiservers like all "distributed system" software does, but that's still not implemented).

zozbot2343• 4 years ago

"Containers" are just a pattern, the real technology behind it is kernel namespaces (plus ordinary process boundaries). (For that matter container security is still half-baked in many ways. The kernel namespacing has been added after-the-fact and it can't really be trusted to make an effective "sandbox" on its own.)

vbezhenar10• 4 years ago

Everyone keep saying that. But containers are battle-tested for years at this point. I think that all low-hanging vulnerabilities have been fixed. Like you can expect that your container IS secure if your system is up to date. Every container escape is kernel bug which is fixed ASAP. And 0-days can be applied to everything, virtualization will not help you with that, there're 0-days in virtualization layers. Yes, surface of attack is significantly larger with containers and chance of 0-day is larger, but for most companies which don't really run code from attackers in their containers, this danger is over-stated. Container security is good enough for most workloads.

Pakdef• 4 years ago

Also, for the amounts of complexity K8s adds it's not worth the overhead in 95% of cases

probably true for the cloud too

otabdeveloper4• 4 years ago

I am affraid that once the "movement" fizzles out we're going to be stuck with a lot of things that are over-overengineered

Have no fear, these k8s specialists are going to be extremely in demand for getting rid of legacy k8s hell. (Not even joking, I'd pay good money for someone to get rid of the k8s cluster previous consultants have cobbled together.)

seabrookmx• 4 years ago

I know most configurations don't use it, but k8s supports different runtimes and today you can use Kata or firecracker to run each pod in it's own "microvm."

You then get the security benefits of a "real" VM while still distributing your software as an OCI (Docker) container, and can operate it like any other k8s cluster.

avereveard• 4 years ago

*chroots

tannhaeuser• 4 years ago

That doesn't make sense? K8s runs Docker images, and a Docker image explicitly is not a VM but, in fact, a lightweight replacement for a full-blown VM. Of course, running Docker on Windows or Mac OS requires a Linux VM, though.

jiggawatts6• 4 years ago

You can run Windows images on Windows clients using Docker.

pjmlp4• 4 years ago

Docker still requires a mini WSL instance running.

aetherspawn• 4 years ago

Good for some use cases, but still plenty of servers that are hostile to K8s because ie you have to login and enter a license key, or something like that.

sureglymop2• 4 years ago

The containerization features used by projects like Docker and Kubernetes are provided by the Linux kernel. Containers are not VMs, they're just regular processes.

x86x8724• 4 years ago

Containers are not regular processes. One could argue that you can have a container without any process in it.

A container is an abstract idea that normally comes together through the synergy of [at least] cgroups, namespaces and overlay filesystems.

sureglymop2• 4 years ago

They are regular linux processes, you can find them in /proc or display them with ps... Croups, namespaces etc are Linux features that can be used with any process.

But i guess i see now what you are saying. That it's a "meta" term for that idea of abstraction.

hinkley3• 4 years ago

Does anyone know of a good, sober treatise on the suitability of microkernels for multitenancy and/or split priority systems?

Hypervisors just seem like particularly impoverished microkernels to me. It reminds me of social programs working hard to avoid the term Socialism because of emotional baggage. Oh this is definitely not a microkernel? Is it a full privilege program that handles a small number of system-wide concerns and delegates the maximum number of other concerns to processes running at a lower privilege level? Yes? Then can we call it a… no? Okay buddy.

alexjurkiewicz• 4 years ago

Most people use kernel to mean "operating system kernel" only. Your definition is a superset of that, so it fits the general definition but then expands it in a way that doesn't have broad consensus. That's why people disagree with you.

gwd3• 4 years ago

Hypervisors just seem like particularly impoverished microkernels to me.

Or, "Microkernels done right":

https://www.usenix.org/legacy/event/hotos05/final_papers/ful...

At the last HotOS, Mendel Rosenblum gave an ‘outrageous’ opinion that the academic obsession with microkernels during the past two decades produced many publications but little impact. He argued that virtual machine monitors (VMMs) had had considerably more practical uptake, despite—or perhaps due to—being principally developed by industry.
In this paper, we investigate this claim in light of our experiences in developing the Xen [1] virtual machine monitor. We argue that modern VMMs present a practical platform which allows the development and deployment of innovative systems research: in essence, VMMs are microkernels done right.

(Edited to add relevant paragraphs from the abstract.)

soraminazuki• 4 years ago

You just described one of the key ideas behind unikernels ;)

202206241203• 4 years ago

Kubernetes... It's something they used to utilise in the past before cloud-native, right?

gwd3• 4 years ago

Most of the comments here are missing the point of the article.

Yes, Docker containers != VMs. That's the point: An old-school VM had all the components needed to run one instance of a service; this might include the core app itself, along with "support processes", like a reverse proxy for TLS termination, and maybe some other services. By design, you cannot run all of those in a single docker container.

The point of the article is to say that Kubernetes pods ~= VMs: A pod has all the components required for a single instance of a service, each one in its own docker container, but with increased access to other containers in the pod (just as processes have increased access to other processes in the same VM). So if you're coming from a VM deployment world, when you see "pod" think "vm", and when you see "sidecar" think "support process".

datalopers• 4 years ago

By design, you cannot run all of those in a single docker container.

Sure you can. The notion that “one container, one process” is the biggest misstep of containerization.

mccorrinall• 4 years ago

Why do you think so? In my opinion it makes debugging, deployment and keeping the architecture clean much easier.

gwd3• 4 years ago

Note that I said "Docker container". And that's an oversimplification, but from the article:

Docker containers have been deliberately designed to contain just one application. One container - one Nginx; one container - one Python web server; one container - one daemon. The lifecycle of a container would be bound to the lifecycle of that application. And running an init process like systemd as a top-level entrypoint was specifically discouraged.

My guess is that the goal of this is to leave "lifecycle" issues at the container boundary. If you put nginx and your golang webapp in the same container, and one of them crashes, Docker / kubernetes you have to have logic inside the container to detect that and restart the correct one. If the goal is to have Docker / Kubernetes is to take care of all that for you, making it one thing per container is the best option.

rektide• 4 years ago

I'd rather use infrastructure to package orthogonal concerns than to figure out how to shoehorn all my concerns into each of many container builds. Keep the containers simpler, no?

This also makes containers more dev friendly, dev accessible.

siliconc0w• 4 years ago

K8s can actually run VMs as well (kube-virt) so you can theoretically align on a common platform for both VMs and Containers. In practice most people just use their cloud provider's implementation of K8s. It's complex but if I had to run on bare-metal I'd probably look in that direction vs playing for an equally complex proprietary solution.

neeleshs2• 4 years ago

A lot of comments here about the complexity. But a takeaway from the article is that driving a car is different from repairing it.

We are a startup, had zero knowledge of k8s before. Without GKE, we would have lost days and days of work to imitate parts of k8s on VMs.

Scaling up and down, everything as a container (even cron jobs. Otherwise we had to keep a vm running and use some scheduler). GKE has been a massive advantage for us. The complexity bits may be true for someone managing a k8s cluster. Even with just 3-4 services, managing everything as cattle has been amazing.

dijit• 4 years ago

To be perfectly fair with you, GKE is another level from every other k8s installation target.

EKS and AKS are not nearly as well polished and put together, and god help you if you decide to run on-prem.

The problem is of course that you’re quite right that it’s like driving a car, but ultimately unless you have a good support contract with your car manufacturer for a specific use of the car, then you have to take it to another mechanic and they’re going to put you over a barrel.

(Maybe the analogy falls apart here)

tc08• 4 years ago

I couldn’t agree more. This and the cloud foundation toolkit for terraform is why we chose GCP, and it got us up and running with an impressive infrastructure in a few days.

x86x8724• 4 years ago

Is your goal really to be up and running in a few days? My goal is to run for years without significant ops effort. Maintainence cost always, always dwarves development cost.

sphix0r• 4 years ago

Hosted k8s is a blessing for development teams. A great benefit is that integrating k8s into tools such as Github or Gitlab pipelines makes it a unified and easy deployment cycle. No more issues regarding different release procedures while someone is out of office.

dirkg• 4 years ago

How do lightweight MicroVMs which have the speed of containers but the isolation of a real vm, as implemented in FIrecracker etc, change the landscape? Or do they? I imagine launching a k8s pod or container is still faster and offers much more management and the security benefits of a real vm arent really applicable or desirable?

x86x8724• 4 years ago

the revolution will start across this dimension at some point in time. We're looking at unikernels (https://en.wikipedia.org/wiki/Unikernel) and boot times of nanoseconds for these super specialized VMs. The tech and the ideas around it are not quite there but this is an exciting space to watch in the next 5-10 years.

AtlasBarfed• 4 years ago

That is so close to a simple process in a multitasking OS ... I get it, you still need dependency isolation, you're just reducing the dependencies to the minimum number as possible, but sometimes I wonder if something (besides cgroups) was missed in OS design.

vbezhenar10• 4 years ago

Launching a container is implementation detail for Kubernetes. I could totally see Kubernetes which runs some pods in containers and some pods in VMs with tiny kernel. May be it even exists, I'm too lazy to google it.

koffiezet6• 4 years ago

Microvms are just the workloads, while Kubernetes is a platform, mostly agnostic of that workload. Yes that's currently mostly containers, but you can already schedule VMs on k8s with KubeVirt.

tzury• 4 years ago

Has anyone ideitified the tools used for the diagrams?

arunc• 4 years ago

Looks like illustrator, but I could be wrong

jq-r• 4 years ago

Pretty sure that’s Excalidraw.

roschdal• 4 years ago

Kubernetes is horribly complex.

x86x8724• 4 years ago

That's the tragedy of software development. People like complex things because it shows how smart they are and how hard the problem they are solving really is.

zxcvbn4038• 4 years ago

Kubernetes reinvented virtual machines? That’s a bold statement. I’m still waiting for them to catch up to where OS/360 was 45 years ago.

People forget that mainframe did it first, mainframe still does it best, the only thing that’s changed is that now you can do it on consumer grade electronics for less then 5 million dollars.

koffiezet6• 4 years ago

Can you elaborate on what mainframes do better? I'm genuinely curious (not being too familiar with mainframes).

Kubernetes reinvented virtual machines in a good sense

Related Stories