3 ms·

At least in my case, because your ops team has decided that everything that gets deployed, gets deployed in k8s (unless you have a Very! good reason not to)

• dijit 5y ago
  Kubernetes is great but not everything fits in kubernetes, this is a bad ops team if this is the case.
  • jpgvm 5y ago
    Note the "except if you have a very good reason" caveat. I think this is a good ops team mantra. PostgreSQL unless you have a very good reason otherwise, and k8s unless you have a very good reason otherwise. Decisions like this allow for economies of scale with tooling, monitoring/observability, etc. Saying no to snowflakes is an important part of having a good ops team.
    • dijit 5y ago
      Guess it depends on who is defining “very”. A persistent connection is antithetical to the design of kubernetes. Persistent storage is hard to get right in kubernetes and puts a lot of pressure on the cluster being perfect, which is something a good ops team will tell you is hard. If your application is stateless http services then kubernetes is great, but there are common things that don’t fit well, and forcing people into a solution which may require a complete rethinking is not very pragmatic.
  • dagw 5y ago
    Eh, for what it's worth they've deployed a couple of PostgreSQL instances for me using Kubernetes and it's worked exactly like I've wanted it to. But then again I've never had push those instances to breaking point either when it comes to IO or concurrency so who knows.
• tveita 5y ago
  A middle ground would be provisioning managed services through Kubernetes resources using a controller like Config Connector (GCP) or ACK (AWS) https://cloud.google.com/config-connector/docs/reference/resource-docs/sql/sqlinstance https://cloud.google.com/config-connector/docs/reference/res... https://aws-controllers-k8s.github.io/community/reference/rds/v1alpha1/dbinstance/ https://aws-controllers-k8s.github.io/community/reference/rd...