Add APIService fake clientset support

[siggy]

The linkerd upgrade --from-manifests command supports reading the
manifest output via linkerd install. PR #3167 introduced a tap
APIService object into linkerd install, but the manifest-reading code
in fake.go was never updated to support this new object kind.

Update the fake clientset code to support APIService objects.

Fixes #3559

Signed-off-by: Andrew Seigner [email protected]

[adleong]

This change looks good, but I do have some meta-questions about the larger context.

Do we have concerns about this approach being sustainable? We will need to add a fake client set for any API group in our install manifest, even if we never plan to read that object from the real or fake API.

An alternate approach would be to have the upgrade --from-manifest code parse the manifest directly rather than constructing a fake API. Has this already been considered?

Anyway, I'm sure this is fine. It just feels weird that we need to build fake client sets for apigroups that we never interact with.

[adleong]

Is the deps change required?

[siggy]

@adleong

Do we have concerns about this approach being sustainable? We will need to add a fake client set for any API group in our install manifest, even if we never plan to read that object from the real or fake API.

I'm not particularly concerned about the sustainability. Thus far we have special-cased CustomResourceDefinition and APIService.

An alternate approach would be to have the upgrade --from-manifest code parse the manifest directly rather than constructing a fake API. Has this already been considered?

When implementing #2697 I did consider this approach, but realizing we already had NewFakeClientSets in place for testing, re-using that code, which uses Kubernetes libraries to parse manifests, seemed a more sustainable approach.

Anyway, I'm sure this is fine. It just feels weird that we need to build fake client sets for apigroups that we never interact with.

I had two motivations for this branch:

1. Upgrading from a complete install manifest

Our install/check/upgrade/cli ux is extremely clear and often called out as a favorite feature by users. Without this change, the upgrade from manifest flow requires the user to understand which k8s objects are required for upgrade:

linkerd install > linkerd-install.yaml
cat linkerd-install.yaml | kubectl apply -f -
kubectl -n linkerd get \
  secret/linkerd-identity-issuer \
  configmap/linkerd-config \
  -oyaml > linkerd-manifests.yaml
cat linkerd-manifests.yaml | linkerd upgrade --from-manifests - | kubectl apply -f -

... this change allows for a more user friendly upgrade process:

linkerd install > linkerd-install.yaml
cat linkerd-install.yaml | kubectl apply -f -
cat linkerd-install.yaml | linkerd upgrade --from-manifests - | kubectl apply -f -

2. Testing completeness

The fake module in pkg/k8s is used heavily in our testing infrastructure. Anecdotally I find that when there is existing test infrastructure in an area I'm working in, I'm more likely to add more tests during development. If no testing infrastructure is present (for example, if NewFakeClientSets does not support APIService), the barrier to getting tests implemented is much higher, particularly for a small change.

[siggy]

@adleong

Is the deps change required?

I tried minimizing the changes to go.mod while still adding k8s.io/kube-aggregator, by varying the version of that dependency we were importing. This was the smallest change I was able to achieve.

[ihcsim]

@siggy Code change LGTM 👍! Mind fixing up the conflicts?