Hacker News new | ask | show | jobs
by redwood 3548 days ago
Is anyone here running Docker or Kubernetes in production? If so, what parts of your stack are running inside of it, versus what parts are running elsewhere in VMs or bare metal?
3 comments

I've built Kubernetes architecture and a general container "mentality" to development and operations for a couple of clients and I would still not recommend you put your "pets" (relational databases and other stateful stuff) in Kubernetes just yet if it's the crown jewels in your organisation.

I don't mind putting some RDBMS that is not alpha and omega in the business in K8s but I would still exercise caution. K8s does have "PetSets" to help with this but it's still alpha quality. You can do a reasonable job of it without it by using PersistentVolumes and selectors to ensure your pod gets the volume bound dynamically. That does work very well indeed.

Most other things are fairly easy to migrate over but the hardest part -- and the bit that few people leave enough time to do well -- is integrating Kubernetes into the fabric of your business: accessing the service network, proper DNS that works across your organisation both into and out of K8s, access control, etc.

We run only application logic, proxies or cache servers (Redis/Memcached) in containers. Nothing with storage requirements.
2015: stateless Ruby on Rails web pods and sidekiq pods inside Kubernetes. Redis and Postgres provided by AWS Elasticache and Postgres. The single cluster served two customer facing apps and a single, centralized authentication for users that supports both apps.

This was K8S 1.1, before DaemonSet and PetSet.

On the production machines, I ended up provisioning two different node types -- one with burst cpu shares and one with fixed cpu shares. I had to use node labelling. The web workers were sensitive to spikes in traffic and the background workers ate up all the available cpu, and shouldn't be shared with the web workers.