Skip to content

flannel migration: document removing leftover flannel iptables rules #2768

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
stitrace wants to merge 4 commits into
base: main
Choose a base branch
from
Open

flannel migration: document removing leftover flannel iptables rules #2768

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
353ddd8
flannel migration: document removing leftover flannel iptables rules
stitrace Jun 5, 2026
199d7d2
flannel migration: recommend rolling node reboot as primary cleanup path
stitrace Jul 25, 2026
3bb5864
docs: tighten leftover flannel iptables cleanup step
stitrace Aug 12, 2026
1019f4b
docs: move flannel iptables cleanup step to versioned docs only
stitrace Aug 12, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
24 changes: 24 additions & 0 deletions ...docs/version-3.29/getting-started/kubernetes/flannel/migration-from-flannel.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -92,6 +92,30 @@ There are two ways to switch your cluster to use $[prodname] networking. Both me
kubectl delete -f $[manifestsUrl]/manifests/flannel-migration/migration-job.yaml
```

1. Remove leftover flannel `iptables` rules from each node.

The migration controller deletes the flannel network devices but leaves flannel's `iptables` chains (`FLANNEL-POSTRTG` in `nat`, `FLANNEL-FWD` in `filter`) in place. Their masquerade rule SNATs cross-node pod traffic, which breaks Kubernetes `NetworkPolicy` for policy-selected pods. Because flannel is no longer running, you only need to clear the chains once. Use either method:

**Method 1: Reboot or replace nodes**

Perform a rolling reboot (drain, reboot, uncordon each node in turn), or replace the nodes if you use immutable or managed node pools. The rules do not persist across a reboot, so no work on the nodes is needed.

**Method 2: Remove the chains in place**

Run the following on every node. It takes effect immediately without disrupting workloads, covers both the legacy and nft backends, and is safe to re-run:

```bash
for ipt in iptables-legacy iptables-nft ip6tables-legacy ip6tables-nft; do
command -v "$ipt" >/dev/null 2>&1 || continue
"$ipt" -w -t nat -D POSTROUTING -j FLANNEL-POSTRTG 2>/dev/null
"$ipt" -w -t nat -F FLANNEL-POSTRTG 2>/dev/null
"$ipt" -w -t nat -X FLANNEL-POSTRTG 2>/dev/null
"$ipt" -w -t filter -D FORWARD -j FLANNEL-FWD 2>/dev/null
"$ipt" -w -t filter -F FLANNEL-FWD 2>/dev/null
"$ipt" -w -t filter -X FLANNEL-FWD 2>/dev/null
done
```

### Modify flannel configuration

The migration controller autodetects your flannel configuration, and in most cases, does not require
Expand Down
24 changes: 24 additions & 0 deletions ...docs/version-3.30/getting-started/kubernetes/flannel/migration-from-flannel.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -92,6 +92,30 @@ There are two ways to switch your cluster to use $[prodname] networking. Both me
kubectl delete -f $[manifestsUrl]/manifests/flannel-migration/migration-job.yaml
```

1. Remove leftover flannel `iptables` rules from each node.

The migration controller deletes the flannel network devices but leaves flannel's `iptables` chains (`FLANNEL-POSTRTG` in `nat`, `FLANNEL-FWD` in `filter`) in place. Their masquerade rule SNATs cross-node pod traffic, which breaks Kubernetes `NetworkPolicy` for policy-selected pods. Because flannel is no longer running, you only need to clear the chains once. Use either method:

**Method 1: Reboot or replace nodes**

Perform a rolling reboot (drain, reboot, uncordon each node in turn), or replace the nodes if you use immutable or managed node pools. The rules do not persist across a reboot, so no work on the nodes is needed.

**Method 2: Remove the chains in place**

Run the following on every node. It takes effect immediately without disrupting workloads, covers both the legacy and nft backends, and is safe to re-run:

```bash
for ipt in iptables-legacy iptables-nft ip6tables-legacy ip6tables-nft; do
command -v "$ipt" >/dev/null 2>&1 || continue
"$ipt" -w -t nat -D POSTROUTING -j FLANNEL-POSTRTG 2>/dev/null
"$ipt" -w -t nat -F FLANNEL-POSTRTG 2>/dev/null
"$ipt" -w -t nat -X FLANNEL-POSTRTG 2>/dev/null
"$ipt" -w -t filter -D FORWARD -j FLANNEL-FWD 2>/dev/null
"$ipt" -w -t filter -F FLANNEL-FWD 2>/dev/null
"$ipt" -w -t filter -X FLANNEL-FWD 2>/dev/null
done
```

### Modify flannel configuration

The migration controller autodetects your flannel configuration, and in most cases, does not require
Expand Down
24 changes: 24 additions & 0 deletions ...docs/version-3.31/getting-started/kubernetes/flannel/migration-from-flannel.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -92,6 +92,30 @@ There are two ways to switch your cluster to use $[prodname] networking. Both me
kubectl delete -f $[manifestsUrl]/manifests/flannel-migration/migration-job.yaml
```

1. Remove leftover flannel `iptables` rules from each node.

The migration controller deletes the flannel network devices but leaves flannel's `iptables` chains (`FLANNEL-POSTRTG` in `nat`, `FLANNEL-FWD` in `filter`) in place. Their masquerade rule SNATs cross-node pod traffic, which breaks Kubernetes `NetworkPolicy` for policy-selected pods. Because flannel is no longer running, you only need to clear the chains once. Use either method:

**Method 1: Reboot or replace nodes**

Perform a rolling reboot (drain, reboot, uncordon each node in turn), or replace the nodes if you use immutable or managed node pools. The rules do not persist across a reboot, so no work on the nodes is needed.

**Method 2: Remove the chains in place**

Run the following on every node. It takes effect immediately without disrupting workloads, covers both the legacy and nft backends, and is safe to re-run:

```bash
for ipt in iptables-legacy iptables-nft ip6tables-legacy ip6tables-nft; do
command -v "$ipt" >/dev/null 2>&1 || continue
"$ipt" -w -t nat -D POSTROUTING -j FLANNEL-POSTRTG 2>/dev/null
"$ipt" -w -t nat -F FLANNEL-POSTRTG 2>/dev/null
"$ipt" -w -t nat -X FLANNEL-POSTRTG 2>/dev/null
"$ipt" -w -t filter -D FORWARD -j FLANNEL-FWD 2>/dev/null
"$ipt" -w -t filter -F FLANNEL-FWD 2>/dev/null
"$ipt" -w -t filter -X FLANNEL-FWD 2>/dev/null
done
```

### Modify flannel configuration

The migration controller autodetects your flannel configuration, and in most cases, does not require
Expand Down
24 changes: 24 additions & 0 deletions ...docs/version-3.32/getting-started/kubernetes/flannel/migration-from-flannel.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -92,6 +92,30 @@ There are two ways to switch your cluster to use $[prodname] networking. Both me
kubectl delete -f $[manifestsUrl]/manifests/flannel-migration/migration-job.yaml
```

1. Remove leftover flannel `iptables` rules from each node.

The migration controller deletes the flannel network devices but leaves flannel's `iptables` chains (`FLANNEL-POSTRTG` in `nat`, `FLANNEL-FWD` in `filter`) in place. Their masquerade rule SNATs cross-node pod traffic, which breaks Kubernetes `NetworkPolicy` for policy-selected pods. Because flannel is no longer running, you only need to clear the chains once. Use either method:

**Method 1: Reboot or replace nodes**

Perform a rolling reboot (drain, reboot, uncordon each node in turn), or replace the nodes if you use immutable or managed node pools. The rules do not persist across a reboot, so no work on the nodes is needed.

**Method 2: Remove the chains in place**

Run the following on every node. It takes effect immediately without disrupting workloads, covers both the legacy and nft backends, and is safe to re-run:

```bash
for ipt in iptables-legacy iptables-nft ip6tables-legacy ip6tables-nft; do
command -v "$ipt" >/dev/null 2>&1 || continue
"$ipt" -w -t nat -D POSTROUTING -j FLANNEL-POSTRTG 2>/dev/null
"$ipt" -w -t nat -F FLANNEL-POSTRTG 2>/dev/null
"$ipt" -w -t nat -X FLANNEL-POSTRTG 2>/dev/null
"$ipt" -w -t filter -D FORWARD -j FLANNEL-FWD 2>/dev/null
"$ipt" -w -t filter -F FLANNEL-FWD 2>/dev/null
"$ipt" -w -t filter -X FLANNEL-FWD 2>/dev/null
done
```

### Modify flannel configuration

The migration controller autodetects your flannel configuration, and in most cases, does not require
Expand Down