jbnorth

Honestly I felt the same way for a while but the more I'm exposed to both Fortune 500 companies and ones who have a handful of employees I see Kubernetes as just a good starting point rather than adopting it later.

It removes the overhead of a lot of what sysadmins and devs of yesteryear did by hand or had to have a career's worth of experience to do quickly.

That's not to say that people don't need to know what they're getting into when they adopt kubernetes but especially when you're using a managed offering and not on the bleeding edge of what it supports it's pretty easy in terms of overhead and maintenance.

You’re better off wiping and reinstalling the OS than trying to clean the system.

The hexagon is the best-agon

While I can’t speak for the others, AWS doesn’t replace all of etcd. Only the raft consensus layer which is replaced with Journal which is an internal AWS service.

What is deceleration but acceleration in the opposite direction? /s

Honestly that’s been half the fun of it to me. Trying to out prompt the other players.

All the pressure in the world at work could not make me consider any level of prompt engineering or use of Gen AI.

This got me hooked in 5 minutes. I updated my “word” so many times trying to consider edge cases and other tricks people try.

Looks like it’s run out of credits to use for prompts now but I would gladly throw money at getting this working again.

This is already a thing. AWS instance store volumes are directly attached to the host. I’m pretty sure GCP and Azure also have an equivalent local storage option.

No, that’s AWS.

Your problem here is waiting until 1.28 to be released before starting your upgrades from 1.24. A version or two is one thing but 4 versions and you’re just asking to be constantly struggling to keep your head above water.

The idea with Bottlerocket is that the host itself does not have a direct shell nor a way to access it via SSH or any other method. Instead this responsibility is delegated to the admin container which is where you would actually connect to via SSM/SSH. From here if you needed a root shell you would use the `sheltie` utility to do so.

Well, more or less. The pod IPs are assigned to the host ENIs and not to pods directly. The VPC CNI manages the virtual Ethernet devices in the host and pod network namespaces and sets up routes on the host such that inbound traffic using a pod IP will get routed to the correct virtual Ethernet device for the corresponding pod.

Why even use kubernetes then? You’d be better off just deploying the applications with docker compose on the host.