-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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.
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
Introduce v3 backend maps #21797
Introduce v3 backend maps #21797
Conversation
a25440c
to
0fcc61a
Compare
Have we decided to have or not to have the V3 -> V2 downgrade path? |
Yep, we should have it. Should be covered with separate PRs. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks okay from my side given up/downgrade path is added later.
Just curious, why do we bother renaming LB6_BACKEND_MAP_V2
to LB6_BACKEND_MAP_V3
if it's a macro? Updating the cDefinesMap
entry should be sufficient.
Small nit, but the first two commits could probably be combined into one. They are both small and edit the same file. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
0fcc61a
to
710860c
Compare
Squashed the first two commits, as Louis mentioned. Also, I noticed third commit was not used anywhere at all. I mistakenly ported it from my dev branch, so I dropped the third commit. |
/test Job 'Cilium-PR-K8s-1.16-kernel-4.9' failed: Click to show.Test Name
Failure Output
If it is a flake and a GitHub issue doesn't already exist to track it, comment |
Ok, the Upgrade/Downgrade test passed. I'll do run rest of the tests and if they pass, I'll revert the |
/test |
Add some missing helper functions to implement v3 backend map. 1. A new AddrCluster constructor AddrClusterFrom 2. A new method of AddrCluster to extract ClusterID Signed-off-by: Yutaro Hayakawa <yutaro.hayakawa@isovalent.com>
Extend current backend map values (struct lb4_backend and struct lb6_backend) to contain a new cluster_id field. With this field, we can distinguish two backends which have the same IP address, but belong to different clusters. Since we don't have available padding bit for both structs anymore, we need to extend the structs and bump the map version as well. This commit also contains migration code from v2 backend map to v3 backend map. Signed-off-by: Yutaro Hayakawa <yutaro.hayakawa@isovalent.com>
Some tests failed with |
5e31186
to
2b9cc3b
Compare
/test Job 'Cilium-PR-K8s-1.25-kernel-4.19' failed: Click to show.Test Name
Failure Output
If it is a flake and a GitHub issue doesn't already exist to track it, comment |
/ci-eks |
/ci-aks |
/test-runtime |
/test-1.25-4.19 |
/test-runtime |
2b9cc3b
to
ac14a28
Compare
Seeing a lot of CI job reruns without justifications here 😬 |
Introduce new v3 backend maps for IPv4 and IPv6. Since it modifies the value size of the backend maps, this PR contains the map migration logic as well. The change from the previous map version now includes the
cluster_id
field. This field will be filled by the control plane that implements Cluster Mesh with overlapping PodCIDR support. When the global service contains backends from the remote clusters with overlapping PodCIDR, we can distinguish them by cluster-aware addressing scheme (see #21161). Note that since the current agent doesn't have actual logic to realize global service with cluster-aware addressing,cluster_id
should always be zero for now.