-
-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Run Kubernetes conformance test #1385
Comments
Single node cluster:
I thought I'd go ahead and run the conformance test this morning while I work in neon-desktop and it looks like bad things are happening. I downloaded and extracted sonobuoy as described in the instructions above and then ran it like:
sonobuoy printed out the lines above and exited. Next, I ran this:
and the cluster is in chaos:
and it also looks like the sonobuoy pod is not starting due to disk pressure:
I SSH-ed into the node and see that we have nearly 4GB RAM available and we're at 85% disk full, which will trigger the disk pressure status. I bunch of pods are evicted now, so there may have been less RAM available when sonobuoy started. The sonobuoy pod spec in the cluster reports that it cannot be scheduled due to low RAM. I suspect that even though there's enough RAM now, the scheduler is trying to reschedule the higher priority pods first and can't due to the disk pressure. |
We should increase the disk pressure trigger to 95% and see if that helps: https://github.com/nforgeio/neonCLOUD/issues/241 We may also need to modify Kublet to prevent eviction of high priority pods in certain circumstances like single node clusters. |
I tried this again with a much larger VM for the single node cluster:
NOTE: Sonobouy requires that docker be configured as a default registry, You can configure this in your cluster definition or via a ContainerRegistry resource to an existing cluster:
or via:
Sonobuoy is running much better on the bigger VM! |
The test run completed with 4 failures. Here's the log file: There are several warnings that here that probably don't count as compliance failures but we should address these anyway:
Here are the entire results (the relevant sub-directory is Here are the failures:
|
Here's a summary of the failures:
The issue above is probably the only one that matters. The three tests below require at least 2 cluster node and I only had one:
|
Here's a Kubernetes issue discussing the ServiceAccountIssuerDiscovery problem. ...and here's some documentation: https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/ |
So it looks like the problem is the lack of the https:// scheme prefix for this option in the API server's static pod manifest:
This looks like a Kubernetes problem because the static pod files configured by the kubeadm tool. |
neonKUBE IS COMPLANT!!!
|
We need to run the compliance test so we know where we stand.
https://www.cncf.io/certification/software-conformance/
https://github.com/cncf/k8s-conformance/blob/master/instructions.md
FYI: Looks like we need to join CNCF to be certificated:
https://github.com/cncf/k8s-conformance/blob/master/faq.md#what-is-the-cost-of-certification
The text was updated successfully, but these errors were encountered: