Consider the installed Linkerd version when running `linkerd check`

[kleimkuhler]

trafficstars

What is the issue?

linked check on 2.12 does not work when run on a cluster with an older version of Linkerd installed.

How can it be reproduced?

Install an older version of Linkerd and then run linkerd check with 2.12.

Logs, error output, etc

$ linkerd version
Client version: stable-2.11.4
Server version: stable-2.11.4

$ linkerd check
Linkerd core checks
===================
...
Status check results are √

$ linkerd version
Client version: stable-2.12.0
Server version: stable-2.11.4

$ linkerd check
Linkerd core checks
===================

kubernetes-api
--------------
√ can initialize the client
√ can query the Kubernetes API

kubernetes-version
------------------
√ is running the minimum Kubernetes API version
√ is running the minimum kubectl version

linkerd-existence
-----------------
√ 'linkerd-config' config map exists
√ heartbeat ServiceAccount exist
√ control plane replica sets are ready
√ no unschedulable pods
√ control plane pods are ready
√ cluster networks contains all node podCIDRs
√ cluster networks contains all pods

linkerd-config
--------------
√ control plane Namespace exists
√ control plane ClusterRoles exist
√ control plane ClusterRoleBindings exist
√ control plane ServiceAccounts exist
× control plane CustomResourceDefinitions exist
    missing authorizationpolicies.policy.linkerd.io, missing httproutes.policy.linkerd.io, missing meshtlsauthentications.policy.linkerd.io, missing networkauthentications.policy.linkerd.io
    see https://linkerd.io/2.12/checks/#l5d-existence-crd for hints

Status check results are ×

output of linkerd check -o short

Pasted above

Environment

$ linkerd version
Client version: stable-2.12.0
Server version: stable-2.11.4

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"24", GitVersion:"v1.24.2", GitCommit:"f66044f4361b9f1f96f0053dd46cb7dce5e990a8", GitTreeState:"clean", BuildDate:"2022-06-15T14:22:29Z", GoVersion:"go1.18.3", Compiler:"gc", Platform:"linux/amd64"}
Kustomize Version: v4.5.4
Server Version: version.Info{Major:"1", Minor:"22", GitVersion:"v1.22.6+k3s1", GitCommit:"3228d9cb9a4727d48f60de4f1ab472f7c50df904", GitTreeState:"clean", BuildDate:"2022-01-25T01:27:44Z", GoVersion:"go1.16.10", Compiler:"gc", Platform:"linux/amd64"}

$ k3d version
k3d version v5.3.0
k3s version v1.22.6-k3s1 (default)

$ uname -a
Linux kleimkuhler-dev-da-c3-small-x86 4.19.0-20-amd64 #1 SMP Debian 4.19.235-1 (2022-03-17) x86_64 GNU/Linux

Possible solution

No response

Additional context

No response

Would you like to work on fixing this bug?

No response

[kleimkuhler]

There are 2 places we check that the CRDs exist in 2.12's CLI: linkerd check --crds and linkerd check. If either of these are being run on a 2.11 or older cluster, we want to check only for the ServiceProfiles definition.

The main issue with these is that we need to check the server version in order to determine if an error should be returned. However, both of these checks happen before we've retried the server version.

linkerd check --crds should be able to be run without a control plane being installed; in this case we'll have to fall back to 2.12's CRDs. If a control plane is installed though, then we can do the version check and conditionally check just for pre-2.12.

linkerd check it's assumed the control plane is installed, so we can move the l5d-version-control check before the CRDs check and use the version then.

[kleimkuhler]

#9287 was closed as this felt like a grody fix to the larger issue that linkerd check is version agnostic. If we are to fix this issue, it should be in a way that linkerd check first considers the installed Linkerd version so that it can choose which suite of checks to run.

[wmorgan]

I'll echo @adleong's comment on #9287 which is that I'm not sure we really need check to support earlier (major) versions on the cluster. Feels like it will be a big maintenance headache for us, vs just asking the user to match CLI and cluster versions which does not impose an undue burden on them. I do think that check should make this choice explicit, tho, rather than just failing in unpredictable ways.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.