I've inherited an app with K8s services with the following config

spec:
  ...
  replicas: 1
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
    type: RollingUpdate

For most of these light-weight services, we run a single instance of a pod on GCP. We're expanding into blue-green deploys for some services, but the majority are still run this way.

When we update the GCR image to a new version, the service becomes temporarily unavailable (maybe 10-30 seconds). I'm assuming this is because K8s is killing the old pod while it brings up the new pod. Is there anyway to configure K8s to actually bring up a new pod, direct new traffic to it, and only then shutdown the old pod? This would seemingly allow for a deployment with no downtime, and not rely on having two pods running all the time (saving cost). All docs I can find typically start with N pods so they don't have this issue...

I've inherited an app with K8s services with the following config

spec:
  ...
  replicas: 1
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
    type: RollingUpdate

For most of these light-weight services, we run a single instance of a pod on GCP. We're expanding into blue-green deploys for some services, but the majority are still run this way.

When we update the GCR image to a new version, the service becomes temporarily unavailable (maybe 10-30 seconds). I'm assuming this is because K8s is killing the old pod while it brings up the new pod. Is there anyway to configure K8s to actually bring up a new pod, direct new traffic to it, and only then shutdown the old pod? This would seemingly allow for a deployment with no downtime, and not rely on having two pods running all the time (saving cost). All docs I can find typically start with N pods so they don't have this issue...

UPDATE

So the issue is not related to maxsurge (changing it had no effect). Actually I realized what's happening is that the pod is getting traffic routed to it before the app is actually completely ready. These are spring apps, so they take like 30 seconds to start, and the service disruption we're seeing is occurring in the 30s window while the app is booting and the pod has already sent traffic to it. So I guess what I really am after is as follows

how can k8s be configured to bring up a second pod, wait until it passes startup probe/healthcheck, and only then have the first pod route traffic to it and self-terminate?

I've inherited an app with K8s services with the following config

For most of these light-weight services, we run a single instance of a pod on GCP. We're expanding into blue-green deploys for some services, but the majority are still run this way.

When we update the GCR image to a new version, the service becomes temporarily unavailable (maybe 10-30 seconds). I'm assuming this is because K8s is killing the old pod while it brings up the new pod. Is there anyway to configure K8s to actually bring up a new pod, direct new traffic to it, and only then shutdown the old pod? This would seemingly allow for a deployment with no downtime, and not rely on having two pods running all the time (saving cost). All docs I can find typically start with N pods so they don't have this issue...

I've inherited an app with K8s services with the following config

spec:
  ...
  replicas: 1
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
    type: RollingUpdate

For most of these light-weight services, we run a single instance of a pod on GCP. We're expanding into blue-green deploys for some services, but the majority are still run this way.

When we update the GCR image to a new version, the service becomes temporarily unavailable (maybe 10-30 seconds). I'm assuming this is because K8s is killing the old pod while it brings up the new pod. Is there anyway to configure K8s to actually bring up a new pod, direct new traffic to it, and only then shutdown the old pod? This would seemingly allow for a deployment with no downtime, and not rely on having two pods running all the time (saving cost). All docs I can find typically start with N pods so they don't have this issue...