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.
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.
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.
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.
Yes, that’s the current state of affairs. My bank receives the money in my account from my employer’s bank but it takes a couple days to clear. Right now many banks will make this money available to you right away rather than waiting for it to clear.
That’s spot on. I work at a large cloud provider and one of our larger eCommerce customers had an outage in a kubernetes cluster which handled the front end traffic routed through a large CDN provider. Well sure enough “just turn it back on” wasn’t an option since the surge of traffic was too rapid for the services and the cluster to scale out. They ended up having to turn the traffic back on incrementally to let things scale up to the point where they could handle the load.
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.