Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Container technologies at Coinbase: Why Kubernetes is not part of our stack

blog.coinbase.com

Post reply on HN
Print view View original

341–350 of 414 posts

Re: Container technologies at Coinbase: Why Kubernetes is not part of our stack

#341

Post by dtech »

whatsmyusername wrote: post #186
threeseed wrote: post #91

Earlier quoted context omitted.

AWS Kubernetes (EKS) with Fargate is just as simple as ECS. Far simpler if you can include the fact that with Kubernetes you can install new applications as simply as "helm install prometheus".

Are they still charging something ridiculous for control planes? When I looked at it they were like $200/month. I wasn't aware they were offering fargate on EKS now. They weren't when I looked at it last.

Since December 2019: https://aws.amazon.com/blogs/aws/amazon-eks-on-aws-fargate-n...

Re: Container technologies at Coinbase: Why Kubernetes is not part of our stack

#342

Post by kasra85 »

gnud wrote: post #320
GOTERTHe wrote: post #207

Earlier quoted context omitted.

Tried Dokku, but found CapRover [1] to be a much better / easier option [1] https://caprover.com/

Looks interesting - but the installation instructions put me off a bit. Open a port on your server, and don't change the default password `captain42` - then run a cli tool from your dev machine. I'll look more into it, but it didn't really inspire confidence.

You can choose a custom password during installation

Re: Container technologies at Coinbase: Why Kubernetes is not part of our stack

#343

Post by kasra85 »

Lukas_Skywalker wrote: post #226
GOTERTHe wrote: post #207

Earlier quoted context omitted.

Tried Dokku, but found CapRover [1] to be a much better / easier option [1] https://caprover.com/

Better for what reason? It seems Dokku wins at "easier" since in many cases, you can just push the application code you used for development and the required stack is automatically detected. Adding a database is two commands. No need to know Dockerfiles.

It's easier because for many cases you don't even need to search the document ro know what command to run to fire up a database. You just select it from a GUI list.

Re: Container technologies at Coinbase: Why Kubernetes is not part of our stack

#344

Post by tylermenezes »

patricjansson wrote: post #261
silvester23 wrote: post #229

Earlier quoted context omitted.

It is, but at this point it is unclear for how long Docker Swarm will be supported, see e.g. https://boxboat.com/2019/12/10/migrate-docker-swarm-to-kuber... We are actually currently in the process of migrating from Docker Swarm to k8s and I am not 100% sure that's a good idea. We will see.

"conversations have led us to the conclusion that our customers want continued support of Swarm without an implied end date." https://www.mirantis.com/blog/mirantis-will-continue-to-supp...

No matter what they claim, it's really not supported in the sense most commercial oss projects are. We finally switched off after a minor version introduced a segfault when adding nodes in certain conditions, and the issue was unfixed after 5 months.

Re: Container technologies at Coinbase: Why Kubernetes is not part of our stack

#345

Post by gnud »

kasra85 wrote: post #342
gnud wrote: post #320

Earlier quoted context omitted.

Looks interesting - but the installation instructions put me off a bit. Open a port on your server, and don't change the default password `captain42` - then run a cli tool from your dev machine. I'll look more into it, but it didn't really inspire confidence.

You can choose a custom password during installation

I just don't understand why you can't change the password (or even better, choose a certificate) before you open the ports to the world.

Re: Container technologies at Coinbase: Why Kubernetes is not part of our stack

#346

Post by OOPMan »

flowerlad wrote: post #100
zaptheimpaler wrote: post #75

Earlier quoted context omitted.

Plain old linux is the alternative, which is also "learn once, use everywhere" whether its AWS EC2 or GCP Instances or nearly any machine under the sun. I don't see how k8s avoids the need to learn about cloud vendor specific tech. e.g searching "aws RDS k8s" gives me a beta github packages and a bunch of blog posts on how to configure it right. It doesn't sound like much less work than learning how to use RDS withou…

> Plain old linux is the alternative How do you run an application on a cluster of plain old linux machines? How do you do load balancing? How do you scale up and down? How do you update your app without downtime? How do you roll back easily if something goes wrong? How do you ensure all your servers are running the same version of dependencies? How do you update those dependencies? How do you replicate your environm…

I call bullshit on any 1-man team needing to worry much about this stuff.

Also, see jen20's response.

If your only tool is a hammer (called k8s) then I'm sure everything really does look like a nail...

Re: Container technologies at Coinbase: Why Kubernetes is not part of our stack

#347

Post by tylermenezes »

dvt wrote: post #11

> We would need to build/staff a full-time Compute team This actually was a very real problem at my current job. The data pipeline was migrated to k8s and I was one of the engineers that worked to do that. Unfortunately, neither myself (nor the other data engineer) was a Kubernetes guy, so we kept running into dev-ops walls while also trying to build features and maintain the current codebase. It was a nightmare. If…

Nomad + Consul has been pretty great to us over the last year. We're a small nonprofit and chose it specifically because we can't afford to pay someone to keep watch over k8s

Re: Container technologies at Coinbase: Why Kubernetes is not part of our stack

#348

Post by andrenth »

lsofzz wrote: post #314
andrenth wrote: post #128

Earlier quoted context omitted.

I think this is a big failing of the DevOps movement as a whole (at least what DevOps became in practice — devs doing ops) which results in things like passwordless mongodb exposed to the internet...

> I think this is a big failing of the DevOps movement as a whole (at least what DevOps became in practice — devs doing ops) which results in things like passwordless mongodb exposed to the internet... Hardly. If anything at all, it tells about the _team_ and/or the culture of the organisation. In any DevOps/SRE/Opsec culture worth the salt, an immediate blameless postmortem analysis would be performed to help with p…

I'm not your son, nor am I talking about what DevOps "is about", but about what is became in practice, which you would have understood hadn't you rushed to reply in the most condescending tone you managed to invoke.

Re: Container technologies at Coinbase: Why Kubernetes is not part of our stack

#349

Post by thedevopsguy »

I find it interesting that many people seem to conflate the complexity of managing infrastructure and services with K8s.

K8s is complex because managing distributed services is. Not using it doesn't mean it goes away. The complexity migrates and ends up being bundled up in a separate tool or a runbook process or some script.

It's hard to maintain because the tools and apis are different from what some engineering teams are accustomed to using. Building an in-house tool gives them a warm fuzzy feeling and comfort that they can handle problems when they appear due to familiarity with their own code and design choices.

It's a fair trade off. I do wonder how much of the time spent doing this exercise could have been spent on K8S training.

I do feel that the K8S community do downplay how much a PITA k8s configuration can be and that the perceived robustness of cloud-managed K8S isn't up to scratch for something this complex.

Re: Container technologies at Coinbase: Why Kubernetes is not part of our stack

#350

Post by skj »

cameronbrown wrote: post #289
spottybanana wrote: post #284

Earlier quoted context omitted.

"Why piece all of that functionality together yourself into some fragile framework instead of using a industry standard?" Quite recently developed "industry standard". Many tools mentioned have been used for tens of years, they work robustly, are well documented and there is lots of people who can use them. I personally would use the word "industry standard" a little bit differently.

> Quite recently developed "industry standard". Many tools mentioned have been used for tens of years, they work robustly, are well documented and there is lots of people who can use them. k8s is based off of Borg, which has existed for far longer. https://research.google/pubs/pub43438/

Really it's just "inspired" by borg. Using both, they're really not very similar.
Post reply on HN