-
Notifications
You must be signed in to change notification settings - Fork 23
[RFC][POC][WIP] Multi Cluster Network Policy Flat model #217
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
base: main
Are you sure you want to change the base?
Conversation
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: aojea The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
f675f23
to
c45f07f
Compare
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.
Pull Request Overview
This PR implements NPEP-308 Extended Network Policy API multicluster support, enabling network policies to be enforced across multiple Kubernetes clusters. The implementation introduces multi-cluster awareness through cluster labeling and scope annotations.
Key Changes:
- Added multicluster network policy evaluator with cross-cluster and cluster-local scopes
- Implemented multicluster IP tracker for sharing pod information across clusters
- Created comprehensive e2e test suite for multicluster scenarios
Reviewed Changes
Copilot reviewed 16 out of 18 changed files in this pull request and generated 5 comments.
Show a summary per file
File | Description |
---|---|
plugins/multicluster/multicluster_networkpolicy.go | Core multicluster network policy evaluator implementation |
plugins/multicluster/multicluster_networkpolicy_test.go | Unit tests for multicluster network policy evaluation |
cmd/kube-network-policies/multicluster/main.go | Main entry point for multicluster network policy agent |
cmd/kube-ip-tracker/multicluster/main.go | Multicluster IP tracker service implementation |
tests/e2e_multicluster.bats | End-to-end tests for multicluster functionality |
tests/e2e_standard.bats | Updated standard e2e tests with cluster setup |
tests/e2e_npa_v1alpha1.bats | Updated NPA e2e tests with cluster setup |
pkg/networkpolicy/networkpolicy.go | Exported helper functions for multicluster use |
pkg/networkpolicy/networkpolicy_test.go | Updated tests to use exported functions |
install-multicluster.yaml | Deployment manifest for multicluster components |
docs/multicluster.md | User guide for multicluster setup |
Makefile | Build targets for multicluster binaries |
Dockerfile.iptracker | Docker build for IP tracker variants |
go.mod | Added fsnotify dependency for file watching |
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
038c960
to
a4e3e10
Compare
4a07ae2
to
4b63c3c
Compare
4708ad9
to
8efb2a4
Compare
8fbc531
to
c858cd5
Compare
based on a flat model and namespace seamless SIG Multicluster concept. Network Policies are cluster local. Selectors are cluster set global. Administrators MUST own the label schema to apply multi cluster policies. avoid conflict on artifacts
The multi-cluster feature is composed of two main components: | ||
|
||
* **`kube-ip-tracker`**: A central component that runs as a **Deployment** in | ||
each cluster. It watches for `Pods`, `Namespaces`, and `Nodes` in all |
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.
Given how it works, it seems it could technically run in only one cluster (assuming a flat network), with the associated concerns regarding availability of course — but an unreachable IP tracker would imply an unreachable cluster so policy decidability at that point would be moot. (Not implying this is necessarily a good idea, just thinking out loud.)
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.
Yeah, but the recommended options is that you run a deployment with a kube-ip-tracer
in EACH cluster.
This creates a full mesh and this guarantee that the local network policies depend of a component that runs in its own cluster.
moved to its own project https://github.com/gke-labs/multicluster-network-policy , we can always bring it if we standardize |
PR needs rebase. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
Implement flat model of network policies across clusters
Ref: kubernetes-sigs/network-policy-api#311