-
Notifications
You must be signed in to change notification settings - Fork 373
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
Add Egress CRD types #1433
Add Egress CRD types #1433
Conversation
Thanks for your PR. The following commands are available:
|
Codecov Report
@@ Coverage Diff @@
## main #1433 +/- ##
==========================================
+ Coverage 61.92% 63.13% +1.20%
==========================================
Files 262 262
Lines 19473 19473
==========================================
+ Hits 12059 12294 +235
+ Misses 6167 5915 -252
- Partials 1247 1264 +17
Flags with carried forward coverage won't be shown. Click here to find out more.
|
// +genclient:noStatus | ||
// +k8s:deepcopy-gen:interfaces=k8s.io/apimachinery/pkg/runtime.Object | ||
|
||
type SNATPolicy struct { |
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.
is this going to be a Namespaced scope CRD?
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.
I plan to start from cluster scoped.
@tnqn : please let me know what you think about my new version? |
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.
I guess your command didn't finish successfully, there are 130 files are affected because of the year update.
pkg/apis/core/v1alpha2/types.go
Outdated
// workloads in To/From fields. If set with PodSelector, | ||
// Pods are matched from Namespaces matched by the NamespaceSelector. | ||
// +optional | ||
NamespaceSelector *metav1.LabelSelector `json:"namespaceSelector,omitempty"` |
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.
Not related to this PR, I'm wondering if we could add a Namespace field to the EntitySelector which means selecting Pods in this namespace, just like how NetworkPolicyPeer in K8s NetworkPolicy works. Is this easier to use compared with "antrea.io/metadata.name" or "kubernetes.io/metadata.name" label?
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.
I think Abishek and Yang proposed the label way, because upstream NetworkPolicy decide to go that direction. @Dyanngg: please comment.
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.
Thanks for bringing it up. In the upstream proposal, we're replacing the NamespaceSelector
field with a new Namespaces
field, which look like the following
type Namespaces struct {
Self bool
Selector *metav1.LabelSelector
Except []*metav1.LabelSelector
}
Namespaces.Selector
will essentially replace NamespaceSelector
. And user can easily write a Namespace isolation policy by setting Namespaces.Self=true
. We are still on the fence about whether the Except
field is necessary so I wouldn't put that in to start with (although there are quite some usecases which can be greatly simplified by except
, like deny all traffic except from kube-system).
Link to the KEP: kubernetes/enhancements#2522
pkg/apis/egress/v1alpha1/types.go
Outdated
type EgressSpec struct { | ||
// AppliedTo selects Pods to which the Egress will be applied. | ||
// +optional | ||
AppliedTo *antreacore.AppliedTo `json:"appliedTo,omitempty"` |
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.
should this be non pointer? It doesn't have a proper mean if it's nil, right?
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.
In NetworkPolicy AppliedTo can be nil today, which means applied to all I think. Should we keep the behavior?
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.
Thought over and now also feel empty AppliedTo probably makes more sense. Do you think so?
pkg/apis/core/v1alpha2/types.go
Outdated
type AppliedTo struct { | ||
// Selectors is the set of EntitySelectors that select entities. | ||
// +optional | ||
Selectors []EntitySelector `json:"selectors,omitempty"` |
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.
@Dyanngg, @tnqn, @antoninbas : do you see any reason to make it a slice? Today Antrea NetworkPolicy uses a slice of NetworkPolicyPeer so can be multiple Selectors too.
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.
I meant I am thinking about:
type AppliedTo struct {
PodSelector *metav1.LabelSelector
NamespaceSelector *metav1.LabelSelector
Groups []string
}
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.
Changed to a single selector (pair) per inputs from Abhishek and Yang.
be92580
to
3b3dbdd
Compare
I found out it is due to a previous failed run, which I commited to local. Fixed it. |
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.
@jianjuns I tested this patch with controller code and it basically works. The only thing missing is the CRD manifest, do you plan to add it in this PR? or I could do it with another PR.
pkg/apis/core/v1alpha2/types.go
Outdated
NamespaceSelector *metav1.LabelSelector `json:"namespaceSelector,omitempty"` | ||
// Groups is the set of ClusterGroup names. | ||
// +optional | ||
Groups []string `json:"groups,omitempty"` |
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.
This is not consistent with Antrea NetworkPolicy where only a Group is allowed. It looks like multiple group will be supported by a nested group #1920.
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.
Yes. I think we should support multiple groups finally, but if we want to change NetworkPolicy together, I can switch to a single group for now.
@Dyanngg : thoughts?
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.
I think last time we discussed, the cardinality issue is not here in particular: the issue is that currently Antrea-native policies support multiple appliedTos, while @jianjuns suggests we only use a single core/v1alpha2.appliedTo for Antrea-native policies if we decide to share the appliedTo. So in upgrade case, there could be extra namespaceSelector
and podSelector
in the appliedTo list today that can not fit in the new spec. If we want to do some hacks (i.e. translating 1 old ACNP to multiple new ACNPs once appliedTo is unified), then I don't really have a preference here. If not, then maybe a list for Groups
here would help, as we only need to put the groups mentioned in the old list of appliedTos in the slice there?
pkg/apis/egress/doc.go
Outdated
// +k8s:deepcopy-gen=package | ||
// +groupName=egress.antrea.tanzu.vmware.com | ||
|
||
package egress |
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.
do you plan to change to crd group after the renaming is done?
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.
Yes.
If we generate YAML then the CRDs are visible to users. I think we can publish YAML after the feature is complete. What you think? |
pkg/apis/egress/v1alpha1/types.go
Outdated
|
||
// +genclient | ||
// +genclient:noStatus | ||
// +k8s:deepcopy-gen:interfaces=k8s.io/apimachinery/pkg/runtime.Object |
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.
// +genclient:nonNamespaced
@jianjuns the tag is needed to generate proper Lister, otherwise it will require a namespace to get an Egress.
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.
Fixed it.
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
/test-all |
Add types for egress policy CRDs, including Egress for the egress policy definition, and a common AppliedTo struct for defining the scope to which a policy is applied.
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
/test-all |
/test-e2e |
Add types for egress policy CRDs, including Egress for the egress
policy definition, and a common AppliedTo struct for defining the scope
to which a policy is applied.
Issue: #667