Hacker News new | ask | show | jobs
by jillyboel 408 days ago
The docs don't make it clear, can it do "zero downtime" deployments? Meaning it first creates the new pod, waits for it to be healthy using the defined health checks and then removes the old one? Somehow integrating this with service/ingress/whatever so network traffic only goes to the healthy one?
2 comments
ffsm8 408 days ago
I can't speak on it's capabilities, but I feel like I have to ask: for what conceivable reason would you even want that extra error potential with migrations etc?

It means you're forced to make everything always compatible between versions etc.

For a deployment that isn't even making money and is running on a single node droplet with basically no performance... Why?

link
jillyboel 408 days ago
> I can't speak on it's capabilities, but I feel like I have to ask: for what conceivable reason would you even want that extra error potential with migrations etc?

It's the default behavior of a kubernetes deployment which we're comparing things to.

> It means you're forced to make everything always compatible between versions etc.

For stateless services, not at all. The outside world just keeps talking to the previous version while the new version is starting up. For stateful services, it depends. Often there are software changes without changes to the schema.

> For a deployment that isn't even making money

I don't like looking at 504 gateway errors

> and is running on a single node droplet with basically no performance

I'm running this stuff on a server in my home, it has plenty of performance. Still don't want to waste it on kubernetes overhead, though. But even for a droplet, running the same application 2x isn't usually a big ask.

link
deepsun 408 days ago
GP talks about personal websites on 1vCPU, there's no point in zero downtime then. Apples to oranges.
link
foepys 408 days ago
Zero downtime doesn't mean redundancy here. It means that no request gets lost or interrupted due to a container upgrade.

The new container spins up while the old container is still answering requests and only when the new container is running and all requests to the old container are done, then the old container gets discarded.

link