To support creating multiple docker bridges for multiple kind job runs

[rajnkamr]

Describe what you are trying to solve

Currently, a single Docker bridge is created for each Kind CI job. However, when running multiple Kind jobs on the same test bed, it's crucial to ensure that each Kind cluster (or specific job) operates on its own dedicated Docker bridge network. This approach is especially important for tests that require network isolation, such as those involving IPAM (IP Address Management) or Egress configurations, where the networking environment must be segregated to prevent interference between tests. By using dedicated Docker bridge networks for each Kind cluster, we can maintain network isolation, ensure test reliability, and avoid potential conflicts between tests that modify network settings.

Describe the solution you have in mind

For supporting multiple egress tests on same kind test beds running in parallel we need to create multiple docker bridges like below

br-9bb19d1.11@br-9bb19d1d4e07: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
br-9bb19d1.12@br-9bb19d1d4e07: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
br-9bb19d1d4e07: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default 
    link/ether 02:42:a0:48:de:ad brd ff:ff:ff:ff:ff:ff

br-9bb19d1.11@br-9bb19d1d4e0x: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
br-9bb19d1.12@br-9bb19d1d4e0x: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
br-9bb19d1d4e0x: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default 
    link/ether 02:42:a0:48:de:ad brd ff:ff:ff:ff:ff:ff

Describe how your solution impacts user flows

N/A
Describe the main design/architecture of your solution

Change docker bridge creation in kind CI scripts
Alternative solutions that you considered

N/A
Test plan

Run multiple egress jobs on a single kind test bed
Additional context

#5734
#6468
#6446

[tnqn]

I don't quite get the goal and the approach. What do you mean by "multiple docker bridges"? I see only one bridge in the output under "Describe the solution you have in mind".

And if you actually mean multiple clusters on single bridge, can multiple clusters just share the same vlan interface? I don't see why there must be one interface for each job.

[rajnkamr]

I don't quite get the goal and the approach. What do you mean by "multiple docker bridges"? I see only one bridge in the output under "Describe the solution you have in mind".

And if you actually mean multiple clusters on single bridge, can multiple clusters just share the same vlan interface? I don't see why there must be one interface for each job.

Edited with multiple bridges( Had added one bridge as a sample ).
Multiple jobs needs to run independent of each other, Meant in case of multiple clusters, for this reason we need multiple docker bridges as the bridges needs to be created with each new kind egress job run and will be cleaned up after job is ended/terminated, hence each job need to create/delete their own docker network.

[github-actions]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment, or this will be closed in 90 days

[github-actions]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment, or this will be closed in 90 days. You can add a label "lifecycle/frozen" to skip stale checking.