5 ms·
That would need similar LTS support for the databases too. Also if you are migrating the databases once in a decade is that really something where you want/need
by SahAssar 2y ago
That would need similar LTS support for the databases too. Also if you are migrating the databases once in a decade is that really something where you want/need k8s? Why not run straight on the OS at that point?
- solatic 2y agoNo, not necessarily. You have databases like Kafka and Elasticsearch that can benefit greatly from elastically adding additional nodes as needed. You now have Kubernetes Operators for lots of databases that help with quick HA failover when the underlying node fails. But Kubernetes itself is fairly mature at this point and there's much less likelihood that there's going to be some kind of feature that's really ground-breaking and need a new version of Kubernetes... The only one that comes to mind is in-place container resource resizing without a restart: https://kubernetes.io/docs/tasks/configure-pod-container/resize-container-resources/ https://kubernetes.io/docs/tasks/configure-pod-container/res... This is separate from the problem of needing to gradually roll pods (and their disks) to new nodes for every node in the fleet to accommodate a Kubernetes version rollout (i.e. with immutable nodes), which is an incredible pain for large database fleets and more or less not realistic to carry out quickly for critical security fixes. Having LTS nodes with LTS kubelet that you restart in place is much easier.
- SahAssar 2y agoSo who provides 12 years of LTS for those database versions and operators? Who provides 12 years of LTS for the clients of those databases?