Tailscale Operator 1.104.1: egress readiness and the ACME upgrade catch

Identify the upgrade, then separate ingress from egress

Tailscale published Kubernetes Operator 1.104.1 on October 13, 2026. The Operator manages Tailscale proxies inside a cluster; a ProxyGroup runs several proxy Pods together, with two replicas by default. Start with the two changes that affect an upgrade: egress update sequencing and ingress certificate renewal identity.

Egress connects cluster workloads to resources in a tailnet, the private network managed through Tailscale. Ingress exposes cluster workloads to that network. Egress routing readiness and ingress TLS certificates are separate paths; a shared ACME account does not repair an egress route.

First check the target Operator, proxy and Helm chart versions in your own release configuration. The stable chart repository is pkgs.tailscale.com/helmcharts. Installation docs say stable charts and containers normally follow a client release by a few days, so the October 7 client release with the same version number does not stand in for this Operator announcement.

Check the cluster and administrator prerequisites

The current overview makes the Operator available on all plans. That does not waive charges for account services, cluster compute or networking, and these sources do not announce a new country-by-country availability list. Account and infrastructure requirements apply regardless of the language you use.

The minimum supported Kubernetes version is 1.23.0. Tailscale recommends matching Operator and proxy versions. It supports proxies up to four minor versions older than the Operator, but not proxies newer than it. Record the existing versions before choosing an upgrade order.

Initial setup needs a Kubernetes cluster and access to the Tailscale admin console’s Access controls and Trust credentials pages. Confirm permission to manage tags and credentials. Workload identity federation is a documented alternative to OAuth credentials.

The OAuth method makes tag:k8s-operator an owner of tag:k8s and grants tag-scoped write access for General/Services, Devices/Core and Keys/Auth Keys.

EKS Fargate supports Ingress and the API server proxy, but not ingress Services, egress Services or Connector configurations. Changing the version number does not remove that restriction.

With Cilium kube-proxy replacement and socket load balancing enabled, exposing a Tailscale LoadBalancer Service, a tailscale.com/expose Service or a Service CIDR through Connector requires bypassing socket load balancing in Pod namespaces.

What does an egress rolling update now wait for?

The 1.104.1 announcement says an egress ProxyGroup rolling update waits for each new Pod to route traffic to all of its egress Services before moving on to the next Pod. The condition covers every assigned Service, rather than one connection that happens to succeed.

For a hypothetical example, suppose an egress group serves a database and an internal API. If the replacement Pod can reach the database but not the API, the database result does not demonstrate readiness for both. Observe each existing application path while following the rollout; this example is not a test result.

Before upgrading, review replicas, resource allocation and scheduling. A referenced ProxyClass must already exist and be Ready; node maintenance also calls for a PodDisruptionBudget. A custom TS_LOCAL_ADDR_PORT disables egress graceful failover. The release does not specify how long an old Pod stays alive or guarantee uninterrupted traffic under every network condition.

Choose where the shared ACME account applies

ACME automates TLS certificate issuance and renewal. The ingress ProxyGroup change keeps a persistent account key for the tailnet so recreating a proxy Pod does not discard its renewal account identity. Preserving that identity does not grant unlimited capacity to every ACME client or certificate order.

For an Operator-wide choice, set operatorConfig.sharedACMEAccountKey to true in Helm values.

For an individual ProxyGroup, set tailscale.com/share-acme-account to the string true under metadata.annotations. The group annotation works without the global setting and takes precedence over it.

The Operator creates the tailscale-acme-accounts Secret in its own namespace when the first opted-in ProxyGroup reconciles. Proxies populate the key at their next issuance or renewal. The Secret appearing does not mean every certificate has migrated. Keep its sensitive contents out of troubleshooting chats.

Let existing certificates migrate on renewal

Enabling the shared account on an existing deployment restarts affected Ingress proxy Pods while retaining their current certificates; it does not immediately reissue every certificate. Migration happens on normal renewal. The exemption is not retroactive, and the full transition can take a certificate lifetime.

Do not delete certificates to force migration. Immediate reissuance consumes a limit slot and can fail when the limit is exhausted. Initial issuance for a new hostname remains subject to limits. Tailscale documents 50 new-hostname certificates per tailnet per week and 5 duplicate certificates across clusters per week, so plan large additions in batches.

The CA also distinguishes renewal methods. Let’s Encrypt exempts qualifying ARI replacement orders from all rate limits, while legacy same-identifier renewals remain subject to some limits. Do not turn the Tailscale account mechanism into a claim that every renewal is unlimited. Revoking certificates does not reset issuance limits.

Check three outcomes after the upgrade

First confirm that the controller joined the intended tailnet. The installation guide checks the admin console’s Machines page for an Operator node tagged tag:k8s-operator. Compare the controller and proxy versions with your recorded plan instead of checking only a client version.

Next use your existing ProxyGroup status and application observations to cover every egress Service. A replica count, one Ready Pod or one successful request alone does not establish completion for every application path. No cluster upgrade, connection or failover test was performed for this guide.

Finally follow normal Ingress certificate renewals and the shared account state, keeping existing certificates and account keys. If issuance is already rate-limited, use the specific error and CA documentation to plan recovery, allowing time for ordinary migration. Deleting the Secret or an entire proxy group is not an immediate remedy.