5 ms·
This is nice and an interesting overview, but it still leaves me confused whether one should even use k8s. We currently use a docker-compose to set up and run m
by ricw 10y ago
This is nice and an interesting overview, but it still leaves me confused whether one should even use k8s. We currently use a docker-compose to set up and run multi-container services (django, celery & workers, nginx, cron/backup), yet I'm somewhat unconvinced of why we should invest in "upgrading" to kubernetes.
My understanding is that it will make the system deal automatically with failing containers, though docker-compose already does that for us. Load balancing is another strength, though that is currently not an issue for us. It might automate certain container managing scripts, but that is less of an issue right now
In other words, I currently don't see an actual benefit of k8s over even docker-compose (not docker-swarm, which I understand is the direct k8s alternative). Anyone able to elaborate?!
- why-el 10y agoI have been thinking about this myself lately, and always wondered whether K8s is missing a chance to position itself as the "resource manager" by default, regardless of what size your current load is at. In other words, change the terminology so that K8s appears to be a good choice even if you are just starting (this is the marketing part). Granted it will seem too complex for most apps, but how about a community effort, perhaps backed by a company, that essentially wraps most stacks (say Rails and PG, Django and Mysql, perhaps a caching layer, nginx, and so on) in a K8s module so that devs can start coding and be oblivious to changing loads as their apps grow? In this scenario, K8s will just feel natural, and will be something you just have to learn as part of your journey (Git was like this for a lot of developers, but I concede the analogy is not that great). Even if most devs reject this as being too complex, the few who pick it will be an invaluable feedback source.
- bpineau 10y agoA few improvments I enjoyed when migrating from Swarm to Kubernetes (older Swarm version, though): * Namespaces, to group objets and prevent names clashs. Ideal when many devs runs their own copy of the same distributed app from the same manifests and having the same names. * ConfigMap, to share common configs and project them to files in the containers (and keep them updated in the container, etc), and to provide the configuration separately * Automatic (EBS, or GCS, or NFS...) volume attachment, ie. to the node hosting your database; and re-attaching elsewhere if the node fails and the database is re-scheduler on an other host. Automated database HA/failover is very nice. * Ingress manifests, to version the http routing with your app. Though this is very young and incomplete yet. But yes, k8s is much more complex than Compose (and Swarm), so if the later works for you, changing is probably overkill.
- justinsaccount 10y ago> In other words, I currently don't see an actual benefit of k8s over even docker-compose Do you currently have more than one server? It sounds like you don't.
- ricw 10y agowe do. about a handful right now. it's still manageable, though automation of server resources may be another reason to use k8s?!
- untoreh 10y agoBut how many more? If its just pet servers k8s is still not worth it, despite it having statefulsets since 1.5. K8s is mostly for cattle, and pets when you need them, imho.
- justinsaccount 10y agoTake your example of 'django, celery & workers' What would you currently do if your celery workers couldn't keep up and you needed to add additional machines to handle the load?