5 ms·

You can achieve this without k8s, though. If your goal is, "I want zero-downtime deploys," that alone is not sufficient reason to reach for something as massive

You can achieve this without k8s, though. If your goal is, "I want zero-downtime deploys," that alone is not sufficient reason to reach for something as massively complex as k8s. Set up a reverse proxy and do blue-green deploys behind it.

paulgb 3y ago
> Set up a reverse proxy and do blue-green deploys behind it. That's what I currently use Kubernetes for. What stack are you proposing instead?
- sureglymop 3y ago
  If you only need zero downtime deployments, compose and traefik/caddy are enough. If you need to replicate storage, share networks and otherwise share resources across multiple hosts, kubernetes is better suited. But you'll also have much less control with compose, e.g. no limiting of egress/ingress and more.
  - paulgb 3y ago
    As I see it, managed Kubernetes basically gives me the same abstraction I’d have with Compose, except that I can add nodes easily, have some nice observability through GKE, etc. Compose might be simpler if I were running the cluster myself, but because GKE takes care of that, it’s one less thing that I have to do.
danenania 3y ago
"Set up a reverse proxy and do blue-green deploys behind it." I think this already introduces enough complexity and edge cases to make reinventing the wheel a bad idea. There's a lot involved in doing it robustly. There are alternatives to Kubernetes (I prefer ECS/Fargate if you're on AWS), but trying to do it yourself to a production-ready standard sets you up for a lot of unnecessary yak shaving imho.
- boxed 3y ago
  For small scales you can use Dokku. I do. It's great and simple.
freedomben 3y ago
This sounds like terrible advice. Managing a reverse proxy with blue-green deploys behind it is not going to be trivial, and you have to roll most of that yourself. The deployment scripts alone are going to be hairy. Getting the same from K8s requires having a deploy.yaml file and a `kubectl apply -f <file>`. K8s is way less complex.
- hellcow 3y ago
  I ran such a system in prod over 7 years with >5-9s uptime, multiple deploys per day, and millions of users interacting with it. Our deploy scripts were ~10 line shell scripts, and any more complex logic (e.g. batching, parallelization, health checks) was done in a short Go program. Anyone could read and understand it in full. It deployed much faster than our equivalent stack on k8s. k8s is a large and complex tool. Anyone who's run it in production at scale has had to deal with at least one severe outage caused by it. It's an appropriate choice when you have a team of k8s operators full-time to manage it. It's not necessarily an appropriate choice when you want a zero-downtime deploy.
  - freedomben 3y ago
    > It's an appropriate choice when you have a team of k8s operators full-time to manage it. Are you talking about a full self-run type of scenario where you setup and administer k8s entirely yourself, or a managed system or semi-managed (like OpenShift)? Because if the former then I would agree with you, although I wouldn't recommend a full self-run unless you were a big enough corp to have said team. But if you're talking about even a managed service, I would have to disagree. I've been running for years on a managed service (as the only k8s admin) and have never had a severe outage caused by K8s
  - esafak 3y ago
    Is your short Go program public? I'm curious how you handled progressive rollouts, and automated rollbacks.
    - hellcow 3y ago

paulgb 3y ago

> Set up a reverse proxy and do blue-green deploys behind it. That's what I currently use Kubernetes for. What stack are you proposing instead?

sureglymop 3y ago
If you only need zero downtime deployments, compose and traefik/caddy are enough. If you need to replicate storage, share networks and otherwise share resources across multiple hosts, kubernetes is better suited. But you'll also have much less control with compose, e.g. no limiting of egress/ingress and more.
- paulgb 3y ago
  As I see it, managed Kubernetes basically gives me the same abstraction I’d have with Compose, except that I can add nodes easily, have some nice observability through GKE, etc. Compose might be simpler if I were running the cluster myself, but because GKE takes care of that, it’s one less thing that I have to do.

danenania 3y ago

"Set up a reverse proxy and do blue-green deploys behind it." I think this already introduces enough complexity and edge cases to make reinventing the wheel a bad idea. There's a lot involved in doing it robustly. There are alternatives to Kubernetes (I prefer ECS/Fargate if you're on AWS), but trying to do it yourself to a production-ready standard sets you up for a lot of unnecessary yak shaving imho.

boxed 3y ago
For small scales you can use Dokku. I do. It's great and simple.

freedomben 3y ago

This sounds like terrible advice. Managing a reverse proxy with blue-green deploys behind it is not going to be trivial, and you have to roll most of that yourself. The deployment scripts alone are going to be hairy. Getting the same from K8s requires having a deploy.yaml file and a `kubectl apply -f <file>`. K8s is way less complex.

hellcow 3y ago
I ran such a system in prod over 7 years with >5-9s uptime, multiple deploys per day, and millions of users interacting with it. Our deploy scripts were ~10 line shell scripts, and any more complex logic (e.g. batching, parallelization, health checks) was done in a short Go program. Anyone could read and understand it in full. It deployed much faster than our equivalent stack on k8s. k8s is a large and complex tool. Anyone who's run it in production at scale has had to deal with at least one severe outage caused by it. It's an appropriate choice when you have a team of k8s operators full-time to manage it. It's not necessarily an appropriate choice when you want a zero-downtime deploy.
- freedomben 3y ago
  > It's an appropriate choice when you have a team of k8s operators full-time to manage it. Are you talking about a full self-run type of scenario where you setup and administer k8s entirely yourself, or a managed system or semi-managed (like OpenShift)? Because if the former then I would agree with you, although I wouldn't recommend a full self-run unless you were a big enough corp to have said team. But if you're talking about even a managed service, I would have to disagree. I've been running for years on a managed service (as the only k8s admin) and have never had a severe outage caused by K8s
- esafak 3y ago
  Is your short Go program public? I'm curious how you handled progressive rollouts, and automated rollbacks.
  - hellcow 3y ago