3 ms·

I think I saw you on this thread, but I'd defer to Clayton Coleman of Red Hat/OpenShift in this post: https://news.ycombinator.com/item?id=13680244 https://news

by crb 10y ago

I think I saw you on this thread, but I'd defer to Clayton Coleman of Red Hat/OpenShift in this post: https://news.ycombinator.com/item?id=13680244 https://news.ycombinator.com/item?id=13680244 tl;dr: do you want to be a DBA? do you want to be a cluster admin? If you want to be both you can run databases on Kubernetes. If you don't want to be a DBA, use a managed service.

lobster_johnson 10y ago
Of course. But there's a difference between knowing that there are failure modes, and actually knowing them. Non-containerized environments (VMs, bare metal) are well-understood and fairly predictable; Docker and Kubernetes are moving targets. There are "known unknowns". As an example, I am involved in a project that uses continuous delivery for deploys, and we recently had an incident where the GKE node ran out of inodes because Docker was keeping all the layers of dead containers around. Kubernetes handles this correctly: Best-effort pods were evicted and the node went back to being ready once the inode use went down. PostgreSQL would have stayed up in this case, but it was still a little surprising that GKE, which is nominally managed, does not have a process in place for cleaning up Docker's garbage. (Edit: Apparently it's a bug [1].) When discussing Docker and Kubernetes, there are very often edge cases that come up. For example, until a couple of months ago, Kubernetes had a serious bug that would often cause the wrong network volume to be mounted to a new pod. You can be the world's best containerized-database admin and still be surprised by things like this, which have nothing to do with the nature of containers, and everything to do with the specifics of the software that controls them. [1] https://github.com/kubernetes/kubernetes/issues/41033 https://github.com/kubernetes/kubernetes/issues/41033
- crb 10y ago
  You sound like you might be first in line to use a rkt-powered GKE :)
  - lobster_johnson 10y ago
    I'm indeed hopeful that rkt is the way forward. There are too many competing, overlapping concerns between K8s and Docker.
    - crb 10y ago
      https://twitter.com/chanezon/status/834847669042311168 https://twitter.com/chanezon/status/834847669042311168 "containerd is all we wanted from @docker in @kubernetesio and none of what we didn't need: kudos to the team!"

by crb 10y ago

lobster_johnson 10y ago

Of course. But there's a difference between knowing that there are failure modes, and actually knowing them. Non-containerized environments (VMs, bare metal) are well-understood and fairly predictable; Docker and Kubernetes are moving targets. There are "known unknowns". As an example, I am involved in a project that uses continuous delivery for deploys, and we recently had an incident where the GKE node ran out of inodes because Docker was keeping all the layers of dead containers around. Kubernetes handles this correctly: Best-effort pods were evicted and the node went back to being ready once the inode use went down. PostgreSQL would have stayed up in this case, but it was still a little surprising that GKE, which is nominally managed, does not have a process in place for cleaning up Docker's garbage. (Edit: Apparently it's a bug [1].) When discussing Docker and Kubernetes, there are very often edge cases that come up. For example, until a couple of months ago, Kubernetes had a serious bug that would often cause the wrong network volume to be mounted to a new pod. You can be the world's best containerized-database admin and still be surprised by things like this, which have nothing to do with the nature of containers, and everything to do with the specifics of the software that controls them. [1] https://github.com/kubernetes/kubernetes/issues/41033 https://github.com/kubernetes/kubernetes/issues/41033

crb 10y ago
You sound like you might be first in line to use a rkt-powered GKE :)
- lobster_johnson 10y ago
  I'm indeed hopeful that rkt is the way forward. There are too many competing, overlapping concerns between K8s and Docker.
  - crb 10y ago
    https://twitter.com/chanezon/status/834847669042311168 https://twitter.com/chanezon/status/834847669042311168 "containerd is all we wanted from @docker in @kubernetesio and none of what we didn't need: kudos to the team!"