CockroachDB 19.2 • Hacker News Board

Re: CockroachDB 19.2

#61

Post by zzyzxd » Wed, Nov 13, 2019, 7:50 PM UTC

tyingq wrote: post #59

zzyzxd wrote: post #45

Earlier quoted context omitted.

Last month I tried to deploy cockroachdb in Kubernetes and I felt the documentation wanted to treat me like a 5-year-old. I don't think the your product documentation has to explain what Kubernetes is or its terminologies[1]. The worst part is that it does not tell the cluster admins what need to be setup in the Kubernetes cluster at all, instead, it wraps a bunch of `kubectl` commands in a Python script and says "ju…

I'm curious why you would want to deploy CockroachDB in a K8 cluster. Not being critical...genuinely curious. Since it has its own idea of a cluster, it sounds complex to me. Especially since the typical geographically wide CockroachDB cluster would likely span outside a region centric k8s cluster.

All our CRUD apps run in k8s, so putting the database in the same cluster makes the cluster self-contained and can be easily controlled by a single GitOps pipeline. Since our k8s clusters already have traffic control (service mesh), monitoring, and log aggregation, cockroachdb instances get these for free.

I do admit that, although it has improved a lot over the years, running stateful applications in k8s is still problematic and I had to do some weird dances for networking and data volumes. I won't say this is complex because end of day they are just a bunch of yaml files in git (infrastructure-as-code is sweet).

Re: CockroachDB 19.2

#62

Post by BobVawter » Thu, Nov 14, 2019, 5:59 PM UTC

tyingq wrote: post #59

zzyzxd wrote: post #45

Earlier quoted context omitted.

Last month I tried to deploy cockroachdb in Kubernetes and I felt the documentation wanted to treat me like a 5-year-old. I don't think the your product documentation has to explain what Kubernetes is or its terminologies[1]. The worst part is that it does not tell the cluster admins what need to be setup in the Kubernetes cluster at all, instead, it wraps a bunch of `kubectl` commands in a Python script and says "ju…

I'm curious why you would want to deploy CockroachDB in a K8 cluster. Not being critical...genuinely curious. Since it has its own idea of a cluster, it sounds complex to me. Especially since the typical geographically wide CockroachDB cluster would likely span outside a region centric k8s cluster.

(Cockroach Labs developer here) In CockroachDB parlance, a "cluster" is just some number of cockroach binaries that have local storage and can connect to one another via TCP/IP. It's entirely feasible to run a multi-node cluster on a single laptop by just starting several instances of cockroach bound to different port numbers.

The Kubernetes concept of a "cluster" is a much broader term, encompassing the compute nodes and a lot of control-plane software to make all of the magic happen.

Fundamentally, running CockroachDB on a Kubernetes cluster abstracts away the process of getting the cockroach binary running and offers a lot of convenience to the human operator vis-a-vis reliability and service discovery.

We like to say that CockroachDB is "Kubernetes native" in that you can easily build a CRDB cluster using only the basic k8s building blocks, without requiring a separate operator program to manage the deployment.

You can `kubectl apply` this config and get a fully-functioning cluster. https://github.com/cockroachdb/cockroach/blob/master/cloud/k...

Utilities like Helm et al. are certainly easier than managing a bunch of YAML configs, but they are entirely optional.

Some other CockroachDB+Kubernetes synergies to consider:

1) When using a StatefulSet and PersistentVolumes, a CockroachDB node will easily survive being rescheduled off of its underlying host (e.g. due to maintenance or hardware failure) with no human effort needed.

2) All cockroach instances are, from the perspective of a client, homogenous. That is, a client can send a SQL query to any member of a CockroachDB cluster and get a meaningful response. This maps exactly onto the k8s Service abstraction.

3) Federated k8s clusters and multi-region network fabrics do exist, although they're not exactly common yet. CockroachDB can maintain its clustering across "non-uniform network architectures" that exist within- and cross-region.

Re: CockroachDB 19.2

#63

Post by sporkland » Sun, Nov 24, 2019, 3:00 PM UTC

jaytaylor wrote: post #49

rubyn00bie wrote: post #44

Is the primary advantage of CockroachDB over FoundationDB primarily in supporting SQL out of the box? The multi-region support seems pretty banger at first glance. P.S. ... and I had a tirade here about the licensing information being largely absent on their FAQ or product pages, but I did find this after a google before posting: https://www.cockroachlabs.com/blog/oss-relicensing-cockroach... which... from what I can…

> Is the primary advantage of CockroachDB over FoundationDB primarily in supporting SQL out of the box. That + foundation db pulled the carpet out from all their users at the time apple purchased them. Cannot trust that team / product again, it would be incredibly and blasphemously foolish. At least CDB likely won't pull any such stunt. Disclaimer: I was personally affected by the FDB team making this choice back in…

The situation is completely different these days. Back then they were a small startup. The DB space is incredibly challenging especially because engineers tend to want things for free and are pretty demanding. An acquisition seemed like a likely outcome. To partially offset that risk they offered source code escrow to prospective customers.

Now it's an opensource project backed by Apple. And from what I can tell the team is massively different these days. I'm not sure why the obvious conclusion is "we can't trust them".

I've heard this narrative from people that got burned by fdb's purchase so I'll never use it again multiple times. It's largely confusing to me, as it doesn't feel connected to the current realities.