Move NetworkPolicy to v1 #39164
Move NetworkPolicy to v1 #39164
Conversation
k8s-ci-robot
added
the
cncf-cla: yes
|
This change is |
k8s-github-robot
added
kind/api-change
(Just to clarify, that work is blocked on decisions being made about the questions I asked above) |
|
Sorry for radio silence I was OOO and am still catching up. asking in the api-machinery slack channel is probably your best bet if you have open api machinery questions. |
|
I think we need to address the issues of "real" service VIPs before we can
merge this (on sig-network mailing list)
…On Tue, Jan 10, 2017 at 5:23 PM, Daniel Smith ***@***.***> wrote:
Sorry for radio silence I was OOO and am still catching up. asking in the
api-machinery slack channel is probably your best bet if you have open api
machinery questions.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
<#39164 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFVgVGjaeV6gRi5Qms-3jlMvl5QhBt9Yks5rRC8ogaJpZM4LURyY>
.
|
|
Before declaring v1 done we should probably land #35660 (e2e NetworkPolicy tests), extend it to cover all features that are going to be part of v1, and make sure existing implementations actually implement all those features. And if most/all of them don't implement a feature, maybe we should consider dropping it for v1. eg, as far as I can tell, none of Calico, Romana, or Weave implement string-valued Ports (qv #39769) |
This message to kubernetes-dev says they're not maintaining any backward compatibility with alpha annotations for scheduling features so maybe we can do the same thing? (Although that's alpha->beta, not beta->v1...) |
k8s-github-robot
added
the
needs-rebase
k8s-github-robot
assigned lavalamp, erictune and smarterclayton and unassigned thockin, lavalamp, erictune and smarterclayton
Yep, I think those comments are accurate now.
Well, a "match no ports" or a "match no peers" rule can be represented in the v1beta1 API by just removing that rule altogether, right? That rule is essentially useless I think.
Not sure (and I don't think I have a very strong opinion).
Can probably respect the annotation if it is present and the Namespace field is not, but prioritize the Namespace field if it is present? I don't think any special migration code is necessary - up to the implementations what they want to do, but I suspect that they'll want to support both for some period of time.
I'd opt for keeping it as is since we've seen no reason for changing it during it's time in beta. I'm really keen to not change things from beta -> GA unless we've seen a compelling reason to do so.
I imagine that can stay under proposals, right? I don't think the intention is that those evolve as the API evolves. All-in-all, I'm still a little bit uneasy about the empty vs nil change. It feels like extra work for implementors that doesn't buy us anything. I keep asking myself "when did we ever get feedback from a user asking for this distinction? when did it confuse a user of the API? when did it make things harder for implementations?" and the answers always come back "never". |
Speaking for Weave, that is indeed not presently implemented. It complicates matters, but does not seem insurmountable. |
Yep, Calico doesn't implement this yet either. It's not impossible but it's not a one-liner to add support. I've not heard any user demand for this. |
Ah, indeed
Well, OK, but we need to document NetworkPolicy somewhere that isn't just a "proposal". But I guess that's an easier question: just add the new docs wherever they fit in best.
Yeah, I don't think anyone actually wanted the distinction, it's just that the way that v1beta1 ended up being implemented (empty Ports means "all ports", empty From means "from anywhere") makes us inconsistent with other APIs (and in particular, it makes Ports/From inconsistent with PodSelector/NamespaceSelector, meaning NetworkPolicy isn't even internally self-consistent). But yeah, the "fix" is ugly. I'd be fine sticking with the v1beta1 behavior. (But there were objections to that when it was discussed in the SIG.) |
I noticed while poking around the ClusterRole specification that it seems there are other APIs using an empty slice to indicate "all" rather than "none". // ResourceNames is an optional white list of names that the rule applies to. An empty set means that everything is allowed.
ResourceNames []string |
danwinship
force-pushed
the
networkpolicy-v1
branch
from
214b51c
to
0923f86
Compare
|
@danwinship: The following test(s) failed:
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. 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/test-infra repository. I understand the commands that are listed here. |
|
@thockin: fixed defaults, rebased, regenerated |
|
/lgtm
…On May 28, 2017 8:16 AM, "Dan Winship" ***@***.***> wrote:
@thockin <https://github.com/thockin>: fixed defaults, rebased,
regenerated
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#39164 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFVgVDb3K28TWBHE2XI33mlF2oBvwHhmks5r-Y_KgaJpZM4LURyY>
.
|
k8s-ci-robot
added
the
lgtm
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: danwinship, thockin
Needs approval from an approver in each of these OWNERS Files:
You can indicate your approval by writing |
|
Automatic merge from submit-queue |
@thockin you could register the types from the other package. For example, // Adds the list of known types to api.Scheme.
func addKnownTypes(scheme *runtime.Scheme) error {
// TODO this will get cleaned up with the scheme types are fixed
scheme.AddKnownTypes(SchemeGroupVersion,
&extensions.Deployment{},
&extensions.DeploymentList{},
&extensions.DeploymentRollback{},
&extensions.Scale{},
&StatefulSet{},
&StatefulSetList{},
)
return nil
} |
|
I removed the should-be-totally-unnecessary code for NP from
pkg/apis/extensions - leaving it in pkg/apis/extensions/v1beta1
It compiles.
I can POST a networking/v1 object, and it is stored in etcd as
extensions/v1beta1 - yay!
I can NOT POST an extensions/v1beta1 object.
```
$ cat /tmp/netpol.yaml
apiVersion: extensions/v1beta1
kind: NetworkPolicy
metadata:
name: my-netpol
spec:
podSelector: {}
$ kubectl create -f /tmp/netpol.yaml
error: error validating "/tmp/netpol.yaml": error validating data: couldn't
find type: v1beta1.NetworkPolicy; if you choose to ignore these errors,
turn validation off with --validate=false
$ kubectl create -f /tmp/netpol.yaml --validate=false
error: unable to recognize "/tmp/netpol.yaml": no matches for extensions/,
Kind=NetworkPolicy
```
Looking up that 2nd error, I get to staging/src/
k8s.io/apimachinery/pkg/api/meta/multirestmapper.go, where I see things
like:
```
return nil, &NoKindMatchError{PartialKind: gk.WithVersion("")}
```
...and I am lost
…On Mon, May 29, 2017 at 10:49 AM, Mo Khan ***@***.***> wrote:
If we delete the extensions.NetworkPolicy - who would register the
v1beta1 endpoint? Ugh, I don't understand the apiserver anymore....
@thockin <https://github.com/thockin> you could register the types from
the other package. For example, pkg/apis/apps registers the
pkg/apis/extensions types:
// Adds the list of known types to api.Scheme.func addKnownTypes(scheme *runtime.Scheme) error {
// TODO this will get cleaned up with the scheme types are fixed
scheme.AddKnownTypes(SchemeGroupVersion,
&extensions.Deployment{},
&extensions.DeploymentList{},
&extensions.DeploymentRollback{},
&extensions.Scale{},
&StatefulSet{},
&StatefulSetList{},
)
return nil
}
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#39164 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFVgVN6AGr3qfsvX3mYsIln_DGDVzpIrks5r-wVDgaJpZM4LURyY>
.
|
|
… On Tue, May 30, 2017 at 2:14 PM, Tim Hockin ***@***.***> wrote:
I removed the should-be-totally-unnecessary code for NP from
pkg/apis/extensions - leaving it in pkg/apis/extensions/v1beta1
It compiles.
I can POST a networking/v1 object, and it is stored in etcd as
extensions/v1beta1 - yay!
I can NOT POST an extensions/v1beta1 object.
```
$ cat /tmp/netpol.yaml
apiVersion: extensions/v1beta1
kind: NetworkPolicy
metadata:
name: my-netpol
spec:
podSelector: {}
$ kubectl create -f /tmp/netpol.yaml
error: error validating "/tmp/netpol.yaml": error validating data:
couldn't find type: v1beta1.NetworkPolicy; if you choose to ignore these
errors, turn validation off with --validate=false
$ kubectl create -f /tmp/netpol.yaml --validate=false
error: unable to recognize "/tmp/netpol.yaml": no matches for extensions/,
Kind=NetworkPolicy
```
Looking up that 2nd error, I get to staging/src/k8s.io/
apimachinery/pkg/api/meta/multirestmapper.go, where I see things like:
```
return nil, &NoKindMatchError{PartialKind: gk.WithVersion("")}
```
...and I am lost
On Mon, May 29, 2017 at 10:49 AM, Mo Khan ***@***.***>
wrote:
> If we delete the extensions.NetworkPolicy - who would register the
> v1beta1 endpoint? Ugh, I don't understand the apiserver anymore....
>
> @thockin <https://github.com/thockin> you could register the types from
> the other package. For example, pkg/apis/apps registers the
> pkg/apis/extensions types:
>
> // Adds the list of known types to api.Scheme.func addKnownTypes(scheme *runtime.Scheme) error {
> // TODO this will get cleaned up with the scheme types are fixed
> scheme.AddKnownTypes(SchemeGroupVersion,
> &extensions.Deployment{},
> &extensions.DeploymentList{},
> &extensions.DeploymentRollback{},
> &extensions.Scale{},
> &StatefulSet{},
> &StatefulSetList{},
> )
> return nil
> }
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#39164 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AFVgVN6AGr3qfsvX3mYsIln_DGDVzpIrks5r-wVDgaJpZM4LURyY>
> .
>
|
|
At this point, I am stopping my investigation. I don't have time to crawl
around. If the worst problem we have is duplicated code, I guess I will
live. It does feel like this should be possible.
…On Tue, May 30, 2017 at 2:15 PM, Tim Hockin ***@***.***> wrote:
https://github.com/kubernetes/kubernetes/compare/master...
thockin:pr-39164-plus?expand=1
On Tue, May 30, 2017 at 2:14 PM, Tim Hockin ***@***.***> wrote:
> I removed the should-be-totally-unnecessary code for NP from
> pkg/apis/extensions - leaving it in pkg/apis/extensions/v1beta1
>
> It compiles.
>
> I can POST a networking/v1 object, and it is stored in etcd as
> extensions/v1beta1 - yay!
>
> I can NOT POST an extensions/v1beta1 object.
>
>
> ```
> $ cat /tmp/netpol.yaml
> apiVersion: extensions/v1beta1
> kind: NetworkPolicy
> metadata:
> name: my-netpol
> spec:
> podSelector: {}
>
> $ kubectl create -f /tmp/netpol.yaml
> error: error validating "/tmp/netpol.yaml": error validating data:
> couldn't find type: v1beta1.NetworkPolicy; if you choose to ignore these
> errors, turn validation off with --validate=false
>
> $ kubectl create -f /tmp/netpol.yaml --validate=false
> error: unable to recognize "/tmp/netpol.yaml": no matches for
> extensions/, Kind=NetworkPolicy
> ```
>
> Looking up that 2nd error, I get to staging/src/k8s.io/apimachi
> nery/pkg/api/meta/multirestmapper.go, where I see things like:
>
> ```
> return nil, &NoKindMatchError{PartialKind: gk.WithVersion("")}
> ```
>
> ...and I am lost
>
> On Mon, May 29, 2017 at 10:49 AM, Mo Khan ***@***.***>
> wrote:
>
>> If we delete the extensions.NetworkPolicy - who would register the
>> v1beta1 endpoint? Ugh, I don't understand the apiserver anymore....
>>
>> @thockin <https://github.com/thockin> you could register the types from
>> the other package. For example, pkg/apis/apps registers the
>> pkg/apis/extensions types:
>>
>> // Adds the list of known types to api.Scheme.func addKnownTypes(scheme *runtime.Scheme) error {
>> // TODO this will get cleaned up with the scheme types are fixed
>> scheme.AddKnownTypes(SchemeGroupVersion,
>> &extensions.Deployment{},
>> &extensions.DeploymentList{},
>> &extensions.DeploymentRollback{},
>> &extensions.Scale{},
>> &StatefulSet{},
>> &StatefulSetList{},
>> )
>> return nil
>> }
>>
>> —
>> You are receiving this because you were mentioned.
>> Reply to this email directly, view it on GitHub
>> <#39164 (comment)>,
>> or mute the thread
>> <https://github.com/notifications/unsubscribe-auth/AFVgVN6AGr3qfsvX3mYsIln_DGDVzpIrks5r-wVDgaJpZM4LURyY>
>> .
>>
>
>
|
|
One question here is if I upgrade NetworkPolicy to v1, do I also need to upgrade the calico? Currently, I was using calico node image as 1.2.1 and calico policy controller image as 0.6.0. @danwinship |
|
I filed an issue for calico https://github.com/projectcalico/k8s-policy/issues/108 , the NetworkPolicy of NetworkPolicy has been promoted from extensions/v1beta1 to the new networking.k8s.io/v1 API group. The structure remains unchanged from the v1beta1 API. The net.beta.kubernetes.io/network-policy annotation on Namespaces (used to opt in to isolation) has been removed. |
From the 1.7 release notes: NetworkPolicy has been moved from extensions/v1beta1 to the new (kubernetes#39164, @danwinship) networking.k8s.io/v1 API group. From the 1.8 release notes: The Deployment, DaemonSet, and ReplicaSet kinds in the extensions/v1beta1 group version are now deprecated, as are the Deployment, StatefulSet, and ControllerRevision kinds in apps/v1beta1. As they will not be removed until after a GA version becomes available, you may continue to use these kinds in existing code. However, all new code should be developed against the apps/v1beta2 group version This PR disables these extensions/v1beta1 resources from being served by default in 1.10, though they can be re-enabled via --runtime-config. Objects already stored in etcd in extensions/v1beta1 format can still be read
Move NetworkPolicy to v1
@kubernetes/sig-network-misc
Release note: