What happened?

Creating a CRD with a name of networkpolicies.networking.k8s.io and scope: Cluster appears to replace the in-built networkpolicy type client-side, causing inconsistent behaviour between client and server.

If we have a CRD with the following definition :-

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: networkpolicies.networking.k8s.io 
  annotations:
    "api-approved.kubernetes.io": "https://github.com/kubernetes/kubernetes/pull/78458"
spec:
  group: networking.k8s.io
  versions:
    - name: v1
      served: true
      storage: true
      schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                name:
                  type: string
  scope: Cluster
  names:
    plural: networkpolicies
    singular: networkpolicy
    kind: NetworkPolicy
    shortNames:
    - netpol
    # categories is a list of grouped resources the custom resource belongs to.
    categories:
    - all

And apply that to a Kubernetes cluster. Then run kubectl explain networkpolicies.networking.k8s.io.spec the following information is returned

KIND:     NetworkPolicy
VERSION:  networking.k8s.io/v1

RESOURCE: spec <Object>

DESCRIPTION:
     <empty>

FIELDS:
   name <string>

and it's possible to create an netpol object in the cluster that looks like this

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: lorem
  namespace: default
spec:
  name: lorem

From speaking to @liggitt it seems that it's not actually overwriting the core type but is being persisted server-side and polluting areas of the API used by kubectl explain and for client-side validation.

What did you expect to happen?

My initial expectation that attempts to create a CRD which attempt to overwrite core Kubernetes types would be rejected, as there's no valid use case for that to be allowed.

How can we reproduce it (as minimally and precisely as possible)?

• kind create cluster
• Confirm that creating the sample network policy from the issue does not work (rejected by client-side validation)
• Create CRD from issue
• run kubectl explain networkpolicies.networking.k8s.io.spec and confirm that the new definition from the CRD is returned
• create the sample network policy from the issue and confirm that it's created on the server.

Anything else we need to know?

No response

Kubernetes version

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"21", GitVersion:"v1.21.4", GitCommit:"3cce4a82b44f032d0cd1a1790e6d2f5a55d20aae", GitTreeState:"clean", BuildDate:"2021-08-11T18:16:05Z", GoVersion:"go1.16.7", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"21", GitVersion:"v1.21.1", GitCommit:"5e58841cce77d4bc13713ad2b91fa0d961e69192", GitTreeState:"clean", BuildDate:"2021-05-21T23:01:33Z", GoVersion:"go1.16.4", Compiler:"gc", Platform:"linux/amd64"}

Cloud provider

OS version

# On Linux:
$ cat /etc/os-release
NAME="Ubuntu"
VERSION="20.04.2 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04.2 LTS"
VERSION_ID="20.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=focal
UBUNTU_CODENAME=focal
$ uname -a
Linux DESKTOP-4M2JNS4 5.10.16.3-microsoft-standard-WSL2 #1 SMP Fri Apr 2 22:23:49 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Install tools

Container runtime (CRI) and and version (if applicable)

Related plugins (CNI, CSI, ...) and versions (if applicable)