feat: allow RollingUpdate to be specified for k8s Deployment

[otan]

What

Adds an optional spec.strategy field on WorkerDeployment that mirrors apps/v1 Deployment.spec.strategy. The controller applies it to owned versioned Deployments on create/update and reconciles drift so settings like maxUnavailable / maxSurge stick.

This is distinct from spec.rollout.strategy, which controls Temporal traffic routing across versions.

Why

Owned Deployments currently inherit the Kubernetes default rolling update (25% / 25%). On large fleets, in-place restarts of a Current version (same build ID) can take too many pollers offline at once and spike schedule_to_start. Users need a conservative strategy such as maxUnavailable: 5%.

Testing

• make generate manifests
• go test ./internal/k8s/ ./internal/planner/ -run 'Strategy|ApplyDeploymentStrategyDefaults|ReplicasNilPreserved'

Resolves #496

[CLAassistant]

All committers have signed the CLA.

[jaypipes]

@otan thanks so much for this contribution! I'll review a little later today or tomorrow morning. Been looking into some bug fixes earlier this week.

[jaypipes]

@otan thanks for this! :) Code looks good to me except for a couple requests (see inline). Address those small issues and I'll aim to get this into the v1.9.0 release (set to be cut on August 18th)

[otan]

all good!

[jaypipes]

Awesomesauce, thank you so much @otan :)

[otan]

all done

[jaypipes]

Thank you @otan!

[jlegrone]

I have two concerns with this:

1. Having both deploymentStrategy and rolloutStrategy may be confusing.
2. So far we haven't committed to making the underlying deployment resource type part of the public API. Ie. we could switch to statefulsets or replicasets instead in the future. Ideally we should keep the worker spec agnostic to the underlying k8s resource types.

I also think it needs to be clarified in the documentation when deploymentStrategy would apply, since the controller computes a new build ID (and thus creates a fresh k8s deployment object) for each new worker version. For example does this only matter if you manually perform a rolling update via kubectl rollout restart for a specific version?

Do we actually need to support the Recreate deployment strategy? If not, what would it look like if we only exposed maxUnavailable as an option? I think my concerns would be resolved if the new config was named like spec.maxUnavailablePerVersion which doesn't tie us to deployments as the underlying resource type.

[otan]

Having both deploymentStrategy and rolloutStrategy may be confusing.

For example does this only matter if you manually perform a rolling update via kubectl rollout restart for a specific version?

yep. we just have no control over kubectl rollout restart at the moment (and we do a manual HPA patch to get around it). i can amend that - i originally wanted to keep it to just strategy to meet the original k8s Worker definition but was told to change it. i'm happy to rename it to whatever makes you more comfortable.

So far we haven't committed to making the underlying deployment resource type part of the public API. Ie. we could switch to statefulsets or replicasets instead in the future. Ideally we should keep the worker spec agnostic to the underlying k8s resource types.

AFAICT, this deployment.strategy is an option available to both statefulsets or replicasets