Change:
} } <ins> // TODO: Remove in 1.6. Returns if kubectl is older than v1.5.0 func isOldKubectl(userAgent string) bool { // example userAgent string: kubectl-1.3/v1.3.8 (linux/amd64) kubernetes/e328d5b if !strings.Contains(userAgent, "kubectl") { return false } userAgent = strings.Split(userAgent, " ")[0] subs := strings.Split(userAgent, "/") if len(subs) != 2 { return false } kubectlVersion, versionErr := version.Parse(subs[1]) if versionErr != nil { return false } return kubectlVersion.LT(version.MustParse("v1.5.0")) } // TODO: Remove in 1.6. This is for backward compatibility with 1.4 kubectl. // See https://github.com/kubernetes/kubernetes/issues/35791 var groupsWithNewVersionsIn1_5 = sets.NewString("apps", "policy") // TODO: Remove in 1.6. func filterAPIGroups(req *restful.Request, groups []unversioned.APIGroup) []unversioned.APIGroup { if !isOldKubectl(req.HeaderParameter("User-Agent")) { return groups } // hide API group that has new versions added in 1.5. var ret []unversioned.APIGroup for _, group := range groups { if groupsWithNewVersionsIn1_5.Has(group.Name) { continue } ret = append(ret, group) } return ret } </ins> // RootAPIHandler returns a handler which will list the provided groups and versions as available. func RootAPIHandler(s runtime.NegotiatedSerializer, f func(req *restful.Request) []unversioned.APIGroup) restful.RouteFunction { return func(req *restful.Request, resp *restful.Response) { <del> writeNegotiated(s, unversioned.GroupVersion{}, resp.ResponseWriter, req.Request, http.StatusOK, &unversioned.APIGroupList{Groups: f(req)}) </del> <ins> writeNegotiated(s, unversioned.GroupVersion{}, resp.ResponseWriter, req.Request, http.StatusOK, &unversioned.APIGroupList{Groups: filterAPIGroups(req, f(req))}) </ins> } }

Discussion:
Is this expected? Does it mean that we cannot drop and replace alpha api without waiting for the new gcloud version?
cc:
cc
cc:
My money is on the TPR discovery code that is trying to identify TPR versions and hacks them into the list of registered APIs.
I guess it's not on HEAD? Do you have the PR#?
had a PR moving StatefulSet from v1alpha1 to v1beta1 and she didn't have the same problem. It's interesting why graduating PDB will have the problem
My PR has similar failure but different symptom. I created a GCE cluster locally. doesn't give me that error, but addon-manager isn't working properly. From addon-manager container log, I saw similar error:
Ah, I was using new kubectl
was using the newly built kubectl so we didn't see the problem at first. Addon-manager is using 1.4.4 kubectl, so we observed problem later.
Hmm, if the problem is the old versions of kubectl unable to dealing with new REST endpoints, then the problem is hard. I'll take a look.
is correct. See this .
I thought the TPR code was inert by default and required a flag to kick in
It seems the flag is enabled for most commands:
We need to support 1 minor version skew for kubectl, so we have to workaround in the server. We can hide those new APIVersions in the discovery API from old kubectl. I'm going to send a PR. In the mean time, if someone can come up with a better idea.
kubectl bug is fixed in , need to cherrypick the change to 1.4. is working on server side temp fix
should fix the problem.
The issue was "fixed" because the "unable to register" error was ignored (not returned, just logged), see:
that line in doesn't seem like a fix... it seems like it's leaving the client restmapper in an unknown state, which seems bad to me
Yeah it's not really a fix
Looks like kubectl should try to register the version to the existing group. IMO this isn't a blocker for
can you make sure there's a 1.5 issue tracking the failure to register the new versions into existing groups correctly, or we'll have a related issue in the future
Filed to track this