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

Convergence to Kubernetes

medium.com

Post reply on HN
Print view View original

81–90 of 124 posts

Re: Convergence to Kubernetes

#81

Post by JD557 »

hardwaresofton wrote: post #30

Can anyone who used Docker Swarm/Mesos/Nomad and then switched to Kubernetes comment on anything that was done better by Swarm/Mesos/Nomad? I invested in Kubernetes early and always meant to give the others a try (so I could at least know the differences), but never got a chance to.

We are currently migrating from Mesos/Marathon to Kubernetes. One of the things I miss the most is the auto-refresh in the web interface.

I know that's a minor issue, but after getting used to it, it's really weird having to do manual refreshes.

Also, the Kubernetes UI feels too clutered, but that's probably just because I'm not used to it

Re: Convergence to Kubernetes

#82

Post by brianwawok »

JD557 wrote: post #81
hardwaresofton wrote: post #30

Can anyone who used Docker Swarm/Mesos/Nomad and then switched to Kubernetes comment on anything that was done better by Swarm/Mesos/Nomad? I invested in Kubernetes early and always meant to give the others a try (so I could at least know the differences), but never got a chance to.

We are currently migrating from Mesos/Marathon to Kubernetes. One of the things I miss the most is the auto-refresh in the web interface. I know that's a minor issue, but after getting used to it, it's really weird having to do manual refreshes. Also, the Kubernetes UI feels too clutered, but that's probably just because I'm not used to it

The Kubernetes UI is deprecated anyway.

Re: Convergence to Kubernetes

#83

Post by lima »

JD557 wrote: post #81
hardwaresofton wrote: post #30

Can anyone who used Docker Swarm/Mesos/Nomad and then switched to Kubernetes comment on anything that was done better by Swarm/Mesos/Nomad? I invested in Kubernetes early and always meant to give the others a try (so I could at least know the differences), but never got a chance to.

We are currently migrating from Mesos/Marathon to Kubernetes. One of the things I miss the most is the auto-refresh in the web interface. I know that's a minor issue, but after getting used to it, it's really weird having to do manual refreshes. Also, the Kubernetes UI feels too clutered, but that's probably just because I'm not used to it

Try OpenShift's UI. It has auto-refresh as well as very good UX design.

Re: Convergence to Kubernetes

#84

Post by brianwawok »

piva00 wrote: post #55
minieggs wrote: post #40

Earlier quoted context omitted.

I would love to see a comparison between Docker Swarm and Kubernetes. From talking to peeps I've got that Kubernetes is better for a large number of nodes? I self host all my side projects with Docker Swarm and it's been so good I haven't needed to look into other container management solutions (but I've only got eight nodes).

At the moment I'd say that Kubernetes is only worthy the effort if you have a bunch of idle capacity in your nodes and some tens of machines at least. The setup can get a bit complex quite early and won't be worth the effort to manage 8 nodes, when you begin to scale to around 20 nodes running a bunch of different workloads (batch jobs, web services, etc.), can avoid provisioning on the application side, etc., then k…

Why should node count matter?

Two clicks to get 1-1000 nodes on GKE. The work is to learn the yaml syntax and the way to deploy to GKE... but most apps need to learn something about how it will be deployed (be it how to use ansible to deploy vs how to setup on k8s vs how to use serverless). But you need to do this for 1-1000 nodes, may as well just do it once...

Re: Convergence to Kubernetes

#85

Post by lima »

ajross wrote: post #15

> We have close to 30 teams that run some or all of their workloads on our clusters. Approximately 70% of all HTTP traffic we serve is generated from applications within our Kubernetes clusters. Sounds big. But then per wikipedia: > uSwitch.com [...] allows consumers to compare prices for a range of energy, personal finance, insurance and communications services. And: > On 30 April 2015, the property website firm Zoo…

I've seen way too many companies who started out with 2-3 hand-managed servers and suddenly found themselves with 100 hand-managed servers.

Configuration management and deployment is one of these things you should get right from the start.

Re: Convergence to Kubernetes

#86

Post by kronin »

polskibus wrote: post #6

Is there a recommended way to handle database migrations in kubernetes? Is there a best practice or a tool for that?

Spring boot microservices using liquibase as schema evolver, we are using helm hooks to run a job pre-deploy that leverages a spring boot profile which runs the evolutions. If it fails, return non-zero exit code and the deploy doesn't continue. The only pain point we've run into with this model is that the configmaps that the service depends on (we use the same docker image in both the deployment and evolution job) aren't created before the hook is called, so we need to duplicate part of the config with -D startup params.

Re: Convergence to Kubernetes

#87

Post by merb »

brianwawok wrote: post #82
JD557 wrote: post #81

Earlier quoted context omitted.

We are currently migrating from Mesos/Marathon to Kubernetes. One of the things I miss the most is the auto-refresh in the web interface. I know that's a minor issue, but after getting used to it, it's really weird having to do manual refreshes. Also, the Kubernetes UI feels too clutered, but that's probably just because I'm not used to it

The Kubernetes UI is deprecated anyway.

I think he meant Kubernetes Dashboard.

Re: Convergence to Kubernetes

#88

Post by merb »

keypusher wrote: post #13
ordinaryperson wrote: post #2

Dumb question from someone who doesn't use Kubernetes (or Docker) in production: don't routine security updates mean you're constantly rebuilding and redeploying these images? And if so, how is that more efficient than just using Puppet / Chef / Ansible and a 'real' server?

I don't think people primarily choose Docker because it's more efficient(?) to deploy than a real server. The benefits of Docker, to me, are having a single artifact and reproducible builds where a developer can run the docker image locally, it then gets built once on Jenkins, and the same image is deployed to staging, production, etc. It eliminates an entire class of problems related to the operating system, install…

docker containers are not reproducible.

if you built the same content on machine a and built the same content on machine b the hash of the image would differ. and the timestamp probably too

Re: Convergence to Kubernetes

#89

Post by jacques_chester »

chairmanwow wrote: post #43
tonyarkles wrote: post #28

Earlier quoted context omitted.

I'm perpetually curious about what kind of resource usage you'd expect given those 250 repos, and which runtime you're deploying. I've recently been playing with Go and looking at existing JVM-based services (Spring Boot + starters + our microservices). We've seen rewrites of small services change from ~500MB of RAM to ~10MB of RAM. 250 Go-based services would probably fit very comfortably on a small cluster of cheap…

Can you go into detail about what things changed in the rewrites that enabled this reduction in RAM usage?

The JVM is traditionally memory-hungry. There are lines of engineering underway which will change that quite a bit (GraalVM looks particularly promising), but for now seeing a JVM process merrily consuming hundreds of Mb of RAM as the base case is not unusual.

Re: Convergence to Kubernetes

#90

Post by polskibus »

majewsky wrote: post #62
polskibus wrote: post #49

Earlier quoted context omitted.

So if you want to migrate a particular env from schema version 3 to version 6, do you deploying 3 different init containers manually, or is there a single migration container that always contains all migrations and it by itself understands from which level to which level should the migration be run? Schema migration failure is a stop the world a scenario for our entire stack.

> Schema migration failure is a stop the world a scenario for our entire stack. That's the big problem, and I don't believe that Kubernetes can help with that. It's too intimately tied to your application internals. The recommended practice for migrations is to do them in multiple zero-downtime steps, e.g. first deploy code that handles both old and new schema, then migrate, then deploy to remove transitional code.

Sorry, I forgot to mention that it is acceptable to stop the world. We do in-house deployments and a lot can fail on the customer's side (IT disabling the DB Server, network failure, etc.). We'd rather have the stop and be focused on fixing it ASAP, than be tricked into thinking that the issue may resolve itself.

What I need is a recipe on how to handle db migrations, which are quite frequent, every customer has different current version of the app and therefore is on different db schema. We have our own tool to do that, I suppose we could wrap into a kubernetes-something, the only thing special is that it should run : after old version containers are brought down, before new version of containers are brought up, run only single time, include backing up the db and stopping the entire process on failure.

Post reply on HN