Change:
}, // -- <ins> // k8s.io/kubernetes/pkg/apis/flowcontrol/v1alpha1 gvr("flowcontrol.apiserver.k8s.io", "v1alpha1", "flowschemas"): { Stub:             `{"metadata": {"name": "va1"}, "spec": {"priorityLevelConfiguration": {"name": "name1"}}}`, ExpectedEtcdPath: "/registry/flowschemas/va1", }, // -- // k8s.io/kubernetes/pkg/apis/flowcontrol/v1alpha1 gvr("flowcontrol.apiserver.k8s.io", "v1alpha1", "prioritylevelconfigurations"): { Stub:             `{"metadata": {"name": "conf1"}, "spec": {"type": "Limited", "limited": {"assuredConcurrencyShares":3, "limitResponse": {"type": "Reject"}}}}`, ExpectedEtcdPath: "/registry/prioritylevelconfigurations/conf1", }, // -- </ins> // k8s.io/kubernetes/pkg/apis/storage/v1beta1 gvr("storage.k8s.io", "v1beta1", "volumeattachments"): { Stub:             `{"metadata": {"name": "va2"}, "spec": {"attacher": "gce", "nodeName": "localhost", "source": {"persistentVolumeName": "pv2"}}}`,

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: I am testing API Priority and Fairness. I launched it like this: After the logging said the cluster is running and told me how to set KUBECONFIG, I did so in another shell and went looking for FlowSchema objects. But kubectl erroneously told me there is no such thing. However, looking in the kube-apiserver log shows flowschemas and prioritylevelconfigurations being read and written; for example: Also, I am able to read them with against the insecure port. Interestingly, the kube-apiserver log also includes this complaint: I will attach the kube-apiserver log. What you expected to happen: I expected to list them. How to reproduce it (as minimally and precisely as possible): I think the report above is pretty minimal. Anything else we need to know?: Environment: Kubernetes version (use ): this is the branch, git commit 916edd922e528f2f27542d3ca5967ca11fe153f8Cloud provider or hardware configuration: bare metal, intel, 16 "CPUs", 64 GB of memory OS (e.g: ): 18.04.2 LTS (Bionic Beaver) Kernel (e.g. ): Linux mjs-dev-1 4.15.0-74-generic -Ubuntu SMP Thu Dec 19 08:06:28 UTC 2019 x8664 x8664 x86_64 GNU/Linux Install tools: hack/local-up- Network plugin and version (if this is a network-related bug): Others: Docker version 18.09.7 go version go1.13.4 linux/amd64
/sig api-machinery
/cc /cc /cc /cc
/assign
the "" API group is not included in the list of known groups to register at startup: That means resources inside that group will not appear in discovery, and clients like kubectl will not know how to find them.
You can see all resources visible via discovery by running
just as said, for now we have to manually create an apiservice into the cluster to get kubectl work.

i dont think we're adding this to the list until the beta stage, can we make an exception for the case?
It is fine to add alpha things to the list I linked so they get created automatically if needed. They only get registered if the relevant runtime-config is enabled.
Interrupts control plane upgrade in lazy scenario where it's assumed dns name isn't changed properly to active node or or single node control plane
oh cool actually it succeeds on the second main node but the kube apiserver pod doesnt start
the hacky way being to adjust that api creation based on this?
And I removed the flags too
Wait what is this? This was to my api manifest during kubeadm upgrade?