Service eligibility and regional restrictions
PuppyIP serves only compliant overseas businesses and their authorized personnel. Proxy services are not available in mainland China. The service may only be used for lawful business activities outside mainland China. Use of this service within mainland China is prohibited.
Hosting a proxy IP or server overseas does not change these restrictions. The service must not be provided to end users in mainland China through relaying, forwarding, sharing or resale. Before use, read the Terms of Service.
Key Takeaways
- The fix concerns GKE Sandbox Pods using the Cloud Storage FUSE CSI driver that can remain Terminating indefinitely. It does not explain every Pod termination problem.
- Google requires node pools at 1.37.1-gke.1552000 or later AND dev.gvisor.fuse.abort-on-teardown: "true". Both conditions are required.
- The release notes say Pod or Deployment metadata without an exact manifest path. The overview still lists Sandbox as unsupported, so support scope needs confirmation.
- The sources do not promise automatic recovery for already-stuck Pods or specify a waiting period, universal recreation procedure or force-delete steps.
A published fix, with conflicting support documentation
In its October 14, 2026 GKE release notes, Google reports that Pods using the Cloud Storage FUSE CSI driver in GKE Sandbox could remain Terminating indefinitely. It gives a combination of a version upgrade and an annotation to address that specific defect.
The directly linked driver overview still explicitly lists GKE Sandbox as unsupported under its limitations and shows an October 13 last-updated date. These sources are not aligned. The defect fix alone does not establish general support or justify a new Sandbox/FUSE deployment; existing users should confirm applicability with their platform owner or Google.
Check the node pool, not only the control plane
The release notes require upgrading node pools to GKE 1.37.1-gke.1552000 or later. The stated target is node pools. Upgrading only the cluster control plane does not establish compliance; the check must cover the pool hosting the affected Pod.
Meeting the version threshold is only one condition. In a hypothetical case, the control plane is current but the workload still runs on an older node pool, or the annotation is missing. Neither case meets the complete published conditions. The actual cluster maintainer must still confirm upgrade scheduling and the change window.
The annotation is named; its exact placement is not
The second condition is dev.gvisor.fuse.abort-on-teardown: "true". Google describes its location as Pod or Deployment metadata. The release notes do not specify an exact path within a Deployment manifest or provide YAML to copy.
Have the workload owner inspect the existing Pod and its managing Deployment, then confirm the supported annotation location and replacement behavior. Do not guess a template path or assume that editing some Deployment metadata, or a single existing Pod, makes future workloads inherit the intended setting. Neither directly linked document fills this gap.
Already-stuck Pods have no automatic recovery guarantee
The release notes do not explain how the two conditions apply to Pods already Terminating. They do not promise automatic recovery, a particular waiting period or universal recreation. A fix being included in a new version does not mean every old Pod will immediately exit.
For an existing incident, retain the Pod state, relevant events, node-pool version and workload configuration to help establish whether this combination is involved. If a change is approved, observe actual termination and replacement results and follow the approved rollback and incident procedures. These are investigation suggestions, not a record of changes performed or recovery verified.
Do not combine remedies for different Terminating defects
GKE Known Issues lists other termination problems involving the NFS in-tree driver, a gVisor shim and different causes. The same state does not establish the same root cause. A version number or symptom alone is not enough to apply another defect’s remedy.
For example, force-delete steps for an NFS issue in Known Issues do not belong to this Sandbox/FUSE fix. A separate Cloud Storage FUSE rename or move I/O error also has its own version and sidecar guidance. Those procedures should not be combined into a universal termination checklist.
Resolve support and configuration questions before a change
Existing users can narrow the review to four questions: is this actually Sandbox with Cloud Storage FUSE CSI; does the hosting node pool meet the threshold; where should the annotation be applied in a supported configuration; and how should already-stuck Pods be handled? The release notes establish the first two conditions to check. The latter questions still need workload-specific clarification and further guidance from Google.
Both directly linked documents show October 13 as their last-updated date, and neither contains the new annotation or fix version. Give the change owner both facts: specific fix conditions have been published, while support and configuration details remain incomplete. The order of page dates does not resolve that conflict.
Sources
Frequently Asked Questions
Does the unsupported statement mean Google withdrew the October 14 fix?
That cannot be inferred. The current release notes still contain the fix, and the overview still retains the GKE Sandbox limitation. Their dates do not prove withdrawal or general support. Keep both facts and ask Google to clarify.
Should every ordinary GKE workload using FUSE receive this annotation?
The reviewed release note targets the specific GKE Sandbox and Cloud Storage FUSE CSI combination. It does not require adding the annotation to all ordinary GKE workloads. Do not turn this defect-specific condition into a global configuration requirement.
Can I wait a fixed timeout and then follow a generic force-delete tutorial?
This fix specifies neither that waiting period nor a force-delete procedure. Different causes can produce the same Terminating state. The maintainer should use the actual events, storage and node conditions to decide next steps rather than borrow another known issue’s remedy.