Add a new check to verify if the platform is supported and node affinity criteria

[camilamacedo86]

Describe the rationale for the suggested feature.

See that kots only ships amd64 images so far replicatedhq/kots#3360.
Also, it seems to have some nodeAffinity to verify the labels as well: replicatedhq/kots#3361

Describe the feature

Therefore, the idea here would to be proposed a new check to verify the cluster node platform and the labels (nodeAffinity criteria)

[xavpaice]

Hi, thanks for raising this.

Just to understand the request better, it looks like we have two things:

• Firstly, check the content of metadata.status.conditions.nodeInfo.architecture (though it's also present in metadata.labels.kubernetes.io/arch and/or beta.kubernetes.io/arch) in nodes.json for the architecture. We could add this to the nodeResources analyzer as something like cpuArch.
• Second, a nodeAffinity filter check - I need some more details or an example to be able to understand that clearly, as I'm sure I'm missing something. Can you give us some more info or an example?

Please note that there is a matchLabel filter in nodeResources that would certainly allow us to filter for architecture, though not as easily as we'd like, and that might work also for the nodeAffinity filter if I understand the related KOTS issue correctly.

[camilamacedo86]

Hi @xavpaice,

First, thank you for your time and your attention.
Sorry, if the idea/suggestion were not clear enough.

I was doing some tests and I thought if would not be interesting the "support bundle" (see here the doc) have a check for the following scenario.

• Scenario: The pod for kotsadm is only schedule on linux/amd64. (see this spot in the code)
• Use Case: I am as a user or support eng. I'd like to be able to have a check into the "kubectl support bundle" to verify if the cluster is running on the supported platforms so that I could easily identify why kotsadmin was not scheduled.

(addtional thought). Then, by looking some other spots on the code seems like that its has other conditions ( see here ). Therefore, If we check the nodes in a Kind cluster we can see that the node-role.kubernetes.io/master label cannot be found. Also, I tried to suggest the nodeAffinity be changed in this case see: replicatedhq/kots#3361. Then, not sure if would be valid or not also add this check to it.

I hope that clarifies better the suggestion.
Please, feel free to reach me out.

P.S.: I'd be happy to try to collaborate with this one if this RFE be accepted.

[xavpaice]

Thanks. I think what we need to do here then is to add a check for the content of metadata.status.conditions.nodeInfo.architecture to the nodeResources analyzer as something like cpuArch. That, and using the existing matchLabel filters should be adequate.

Once the analyzer has been updated, we will want to update the bundles in https://github.com/replicatedhq/troubleshoot-specs to cover this.

I believe this could be a good addition to the kURL preflights run as well.

[adamancini]

@camilamacedo86 @xavpaice so the outcome should be:

if I am running a cluster with a mix of cpu architectures, the analyzer should report a PASS if the cluster has

• at least 1 node with amd64 arch &&
• at least 1 of ^ these is marked with the node-role.kubernetes.io/master label

and that will tell us if this cluster is capable of deploying kotsadm?

[xavpaice]

@adamancini that sounds right to me.