Skip to main content

Blogs

Field report of the CNCF conformance test

Introduction

The Cloud Native Computing Foundation is a project to improve cloud computing, microservices and container visualization. Over 450 companies are a part of it, what makes the conformance test so valuable.

Therefore, individual employees carried out the conformance test and came to a result of eleven errors. I was assigned to take care of the information retrieval of the errors. After a certain time of researching those errors I decided to do another test run on my own. In this test I got only one error at the end, which made me realize that the test run is subject to certain dependencies.
The new error was: "CustomResourcePublishOpenAPI", while I was inquiring about this error, I decided to do another test run, this one ran on the side and lasted for about two hours.
It was important for me to do the test run in an isolated environment with an empty Centos 7 machine with only my settings and to our delight there were no complications, so nothing stood in the way of moving on to the next phase.
In the following I will explain how and why I proceeded in this way, it is a continuous text in which I first go into the requirements, then into the necessary creation of files/folders and structures. Then on the creation of the cluster itself followed by the test of sonobuoy and finally with my conclusion.

Procedure

As I mentioned before, we need new or clean machines, a cluster master (node), an admin (node) and two workers (nodes). All of them run OS Centos7. From the download area of our website we get our .rpm file, which is essential for the test run.

Now we need two folders which we create and name “yamlFiles” and “clusterStorage”. In the folder “clusterStorage” we need to create an environment variable, which is permanently. In the folder “yamlFiles” two new files are needed, called “createCluster.yaml” and “addNode.yaml”. There are parameters for creating a cluster in the “createCluster.yaml”, e.g., IP addresses, parameter values, login data, registry to which we refer, etc. All the nodes are listed in the “addNode.yaml” which represents the cluster itself. The node itself is defined here with IP address and login data.

After all this is done, we start docker and enable docker, reboot docker and activate it permanently, this is a more precautionary measure.

Finally, we came to the main part of this field report in which we create a cluster, note that the path must be the same, so if you are in the root directory, you can create the cluster executable and correct. Now we set up the cluster on the cluster master, which is defined in “createCluster.yaml”, which will direct our traffic. Now we let the other nodes join the cluster.
If the cluster has been built successfully, we can now download the relevant program for the conformance test on the sonobuoy page and drag & drop it into our MobaXterm.
After we downloaded it, we unpack the file and move it into the given directory.
Now we start the test, which can take up to 2.5h.

As soon as the test is done, we extract the relevant files. Then we can see the relevant files, but e2e.log is the most important one for us.

Conclusion

At the end of my second test run I had 0 errors, which shows us that such a conformance test is very environment dependent, to go into more detail, there is a difference between installing the cluster in an already running and used environment and installing the cluster in a new and clean environment. This dependency is also related to the operating system, to my advantage our .rpm (kubeops-1.0.0-3-rc2el7.x86_64.rpm) on Centos 7 did not cause any problems as it is adjusted and improved every day. In the end I did another test run which was well done and the result was the same as expected.

Check out our latest blogpost


Visit KubeOps at it-sa 2024! Booth 341, Hall 9, Nuremberg, October 22-24. Secure your free ticket now!