Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We're Leaving Kubernetes

gitpod.io

Post reply on HN
Print view View original

91–100 of 348 posts

Re: We're Leaving Kubernetes

#91

Post by zo1 »

haolez wrote: post #64
ctippett wrote: post #63

Earlier quoted context omitted.

I'm not going to second-guess what works for you, but Python makes it so easy to work with an ephemeral environment. python -m venv .venv

Yeah, I know. But then you have to make sure that your IDE is using the correct environment, that the notebook is using the correct environment, that the debugger is using the correct environment. It's trivial to setup a venv, but sometimes it's just not worth it for me.

This is one of the main reasons I tell people not to use VSCode. The people most likely to use it are juniors and people new to python specifically, and they're the most likely to fall victim to 'but my "IDE" says it's running 3.8 with everything installed, but when I run it from my terminal it's a different python 3.8'

I watched it last week. With 4 (I hope junior) Devs in a "pair programming" session that forced me to figure out how VSCode does virtual envs, and still I had to tell them like 3 times "stop opening a damn new terminal, it's obviously not setup with our python version, run the command inside the one that has the virtual env activated".

Re: We're Leaving Kubernetes

#94

Post by vbezhenar »

I read this article and I still don't understand what's wrong with Kubernetes for this task. Everything you would do with virtual machines could be done with Kubernetes with very similar results.

I guess team just wants to rewrite everything, it happens. Manager should prevent that.

Re: We're Leaving Kubernetes

#95

Post by ensignavenger »

loujaybee wrote: post #23
ensignavenger wrote: post #8

The article does a great job of explaining the challenges they ran into with Kubernetes, and some of the things they tried... but I feel like it drops the ball at the end by not telling us at least a little what they chose instead. The article mentions they call their new solution "Gitpod Flex" but there is nothing about what Gitpod Flex is. They said they tried microVMs and decided against them, and of course Kubern…

Yeah, that's fair. The blog was getting quite long, so we need to do some deeper dives in follow-ups. Gitpod Flex is runner-based. The runner interface is intentionally generic so that we can support different clouds, on-prem or just Linux in future. The first implemented runner is built around AWS primitives like EC2, EBS and ECS. But because of the more generic interface Gitpod now supports local / desktop environm…

Awesome, looking forward to hearing more. I only recently began testing out Theia and OpenVSCodeServer, I really appreciate Gitpod's contributions to open source!

Re: We're Leaving Kubernetes

#96

Post by __MatrixMan__ »

haolez wrote: post #49
horsawlarway wrote: post #33

Personally - just let the developer own the machine they use for development. If you really need consistency for the environment - Let them own the machine, and then give them a stable base VM image, and pay for decent virtualization tooling that they run... on their own machine. I have seen several attempts to move dev environments to a remote host. They invariably suck. Yes - that means you need to pay for decent h…

Sometimes I don't even use virtual envs when developing locally in Python. I just install everything that I need with pip --user and be done with it. Never had any conflicts with system packages whatsoever. If I somehow break my --user environment, I simply delete it and start again. Never had any major version mismatch in dependencies between my machine and what was running in production. At least not anything that…

When doing this re-evaluation, please consider that others might be quietly working very hard to discover and recreate locally whatever secret sauce you and production share.

Re: We're Leaving Kubernetes

#97

Post by dwroberts »

> Autoscaler plugins: In June 2022, we switched to using cluster-autoscaler plugins when they were introduced.

Does anyone have any links for cluster-autoscaler plugins? Searching drawing a blank, even in the cluster-autoscaler repo itself. Did this concept get ditched/removed?

Re: We're Leaving Kubernetes

#98

Post by rfoo »

pmarreck wrote: post #88
horsawlarway wrote: post #33

Personally - just let the developer own the machine they use for development. If you really need consistency for the environment - Let them own the machine, and then give them a stable base VM image, and pay for decent virtualization tooling that they run... on their own machine. I have seen several attempts to move dev environments to a remote host. They invariably suck. Yes - that means you need to pay for decent h…

In my last role as a director of engineering at a startup, I found that a project `flake.nix` file (coupled with simply asking people to use https://determinate.systems/posts/determinate-nix-installer/ to install Nix) led to the fastest "new-hire-to-able-to-contribute" time of anything I've seen. Unfortunately, after a few hires (hand-picked by me), this is what happened: 1) People didn't want to learn Nix, neither d…

In a worse world, worse is better.

Re: We're Leaving Kubernetes

#99

Post by eptcyka »

clvx wrote: post #5

I tried doing a dev environment on Kubernetes but the fact you have to be dealing with a set of containers that could change if the base layer changed meant instability in certain cases which threw me off. I ended up with a mix of nix and it's vm build system which is based on qemu. The issue is too tied to NixOS and all services run in the same place which forces you to manage ports and other things. How I wish it c…

Have you tried https://github.com/astro/microvm.nix ? You can use the same NixOS module for both declarative VMs and imperatively configured and spawned VMs.

Re: We're Leaving Kubernetes

#100

Post by dilyevsky »

concerndc1tizen wrote: post #81

Sounds more to me like they need a new CTO. And that they're desperate to tell customers that they've fixed their problems. Kubernetes is absolutely the wrong tool for this use case, and I argue that this should be obvious to someone in a CTO-level position, or their immediate advisors. Kubernetes excels as a microservices platform, running reasonably trustworthy workloads. The key features of Kubernetes are rollout…

I agree on the cloud thing. Don't agree that "high performance disks, ballooning memory, live migrations, and isolated workloads" preclude from using k8s - you can still run it as base layer. You get some central configuration storage, machine management and some other niceties for free and you can push your VM-specific features into your application pod. In fact, that's how Google Cloud is designed (except they use Borg not k8s but same idea).
Post reply on HN