-
Notifications
You must be signed in to change notification settings - Fork 364
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
AdminNetworkPolicy support in Antrea #5170
Conversation
0d119a3
to
acfd72b
Compare
70c6db5
to
3323939
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.
some initial review comments
@@ -42,38 +43,43 @@ const ( | |||
|
|||
// CreateClients creates kube clients from the given config. | |||
func CreateClients(config componentbaseconfig.ClientConnectionConfiguration, kubeAPIServerOverride 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.
not directly related to this PR, but I think we should consider cleaning this up a little bit given the number of clients we now support, maybe by taking some inspiration from the K8s clientset:
type Interface interface {
K8s() clientset.Interface
KubeAggregator() aggregatorclientset.Interface
AntreaCRDs() crdclientset.Interface
APIExtensions() apiextensionclientset.Interface
AntreaMulticluster() mcclientset.Interface
NetworkPolicy() policyclient.Interface
}
We could return an object implementing this interface in this function, and let consumers choose which client(s) they want to use.
cc @tnqn for his opinion
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 can follow up with a PR
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.
The suggestion looks perfect to me.
@@ -1285,7 +1285,7 @@ func resolveService(service *v1beta2.Service, member *v1beta2.GroupMember) *v1be | |||
return service | |||
} | |||
for _, port := range member.Ports { | |||
if port.Name == service.Port.StrVal && port.Protocol == *service.Protocol { | |||
if port.Name == service.Port.StrVal && (service.Protocol == nil || port.Protocol == *service.Protocol) { |
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 the new case (service.Protocol == nil
) specific to this change (AdminNP / BaselineAdminNP support)?
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 it is. The discrepancy is due to the change of how a named port reference is written.
In K8s NP and Antrea-native policies, we can specify a protocol alongside a port name, like
ports:
- protocol: TCP
port: secured
If there is a port name and no protocol is present, by default TCP will be assumed. And of course the namedPort will only match those specified in the deployment pod templates only if port name and protocol (TCP if not provided) both matches. However, during the design of AdminNetworkPolicy the upstream community brought up how they think this was a mistake, since in pod template specs port name already map to port+protocol tuple, i.e.
ports:
- name: nginx-port
containerPort: 80
protocol: TCP
nginx-port <=> TCP port 80.
So in AdminNetworkPolicy, the named port is given a separate struct explicitly eliminating the protocol field. During processing here, we should consider it a match as long as the port name matches.
I will add more comments in the code to explain this
1051a89
to
a4cc497
Compare
85d10c0
to
902a549
Compare
647a842
to
d56c7b0
Compare
3d07fa4
to
eedd6c7
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.
LGTM, I remember you said you will update the PR for some test change?
eedd6c7
to
87a2de3
Compare
It is already included in the latest change. Specifically, in conformance testing it is using my own |
2a7aeeb
to
058b5e4
Compare
Related PR in upstream network-policy-api repo: kubernetes-sigs/network-policy-api#129 |
/test-all |
/test-all |
@Dyanngg There are some conflicts after NetworkPolicy API was upgraded to v1beta1. |
Signed-off-by: Dyanngg <[email protected]> Add BANP controller Signed-off-by: Dyanngg <[email protected]> Add feature gate Signed-off-by: Dyanngg <[email protected]> Add UT Signed-off-by: Dyanngg <[email protected]> Address comments Signed-off-by: Dyanngg <[email protected]> Add conformance file and fix issues Signed-off-by: Dyanngg <[email protected]> Add conformance as a github action Signed-off-by: Dyanngg <[email protected]> Address more comments Signed-off-by: Dyanngg <[email protected]> Use cloned repo for conformance testing Signed-off-by: Dyanngg <[email protected]>
058b5e4
to
e1e3d32
Compare
Signed-off-by: Dyanngg <[email protected]>
e1e3d32
to
8439590
Compare
/test-all |
Kind failure is related to #5296 |
/test-conformance /test-all-features-conformance /test-e2e /test-networkpolicy |
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 |
PR for #5058