I'm working with Helm Chart testing, and I'm a bit confused. I have a couple (dumb) questions,

1. What does the Test Pod do? Why even make a Test Pod? Why can't the original Pod do testing?
2. How does the Test Pod communicate with the original Pod?
3. Does the test Pod tell the original Pod to perform certain tasks?
4. If I want to check Ports and Hosts (ping server), does the test Pod tell the original Pod to perform a ping command, or does the test Pod perform the ping? If the test Pod is running tests, how can you be sure that the original Pod is working correctly (i.e. if it is not doing anything)?

Perhaps some theory on Helm tests would be very beneficial for me. If there is a document with detailed information on Helm tests please let me know.

CodePudding user response：

Imagine you want to know if Stack Overflow is working. So you run curl https://stackoverflow.com. 99.9% of the time, some magic with load balancers and databases and what not happens and you'll get a list of questions, but 0.1% of the time you get a "something is wrong" page. That is, by making an HTTP GET request from somewhere outside the application, you can still get a high-level view of whether it's working.

You can do as much or as little testing as you want from a test pod. Sending ICMP ECHO packets, as ping(1) does, isn't really that interesting, since it only verifies that the Service exists and the Kubernetes network layer is functional; it doesn't reach your application at all. A simple "are you alive" call can be interesting, but readiness and liveness probes do that too. I might try to write something that depends on the whole application and its dependencies being available, a little bit more than just seeing whether an HTTP endpoint responds.

1. The test tools you need probably aren't part of your main application. As an extreme example of this, many Go images are built on images FROM scratch that literally include nothing at all besides the application binary, so you need a separate image that contains curl and a shell. You could imagine running a larger test system that needs some sort of language runtime that doesn't match the normal language.

2. The test pod "makes normal requests" to the application service. Frequently this would be via HTTP, but it depends on what exactly the application does.

3. The test pod could make HTTP POST requests that cause some action, and verify its result. You could also argue that the test pod shouldn't modify data during a production rollout. Beyond the ordinary network-request path, there's not a way for the test pod to cause the application to "perform a task".

4. The test pod can make a known set of (HTTP) requests and verify the results that come back. If it gets 503 Service Unavailable that's almost certainly bad, for example. It can verify that a response has the right format as per an OpenAPI spec. There probably isn't a path for a random other pod to cause the application to run an arbitrary command and that wouldn't help you demonstrate the application is working correctly.