@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.

@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.

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