Is it possible to spawn a new kubernetes pod via a running container? We want to test this pod by performing various operations on it like query, get, create and delete.
Originally the service was running on native Windows API and docker, so we had to implement a mechanism to restart the service before and after each test. As far as I know, kubernetes knows this by default or at least this should not be difficult to implement.
The communication between the parent pod (the test) and the child pod is interprocess (ipc) and the socket should reside in /tmp/p2/psocket for example (so it has a different socket) . Unfortunately the test fails to connect to the pod and doesn't create the socket on the disk. Wrong mounting perhaps?
I have a feeling the whole concept is bad. I imagine there should not be parent-child relations between pods, but multi container pod for test, where the first container is the test process itself and the other is shm.
But the problem is the "child" should not have the same lifespan as the test pod. The "child" should restart every time a test scenario finishes with it's own thing.
My question basically is how to perform such a thing or is there any best practice for such scenario? I am fairly new to kubernetes, so any ideas or suggestion is welcome here. We're using docker images and kind for cluster creation.
(Previously I mentioned shared memory, but it is not linux shared memory, but a completely different thing).
The communication between the parent pod (the test) and the child pod (shm) is interprocess (ipc) and the socket should reside in /tmp/shm2/shmSocket
Pods can't communicate with each other using Unix sockets or shared memory. Of particular note, any two given Pods aren't guaranteed to be on the same Node, but neither of these mechanisms work across a host boundary. If the service under test is supposed to provide a shared-memory interface to something else, that something else would most likely need to run in the same container.
If the service under test could provide a TCP interface (including HTTP) then you could communicate with it normally via a Kubernetes Service. Without that it's not obvious how it could usefully run in Kubernetes at all.
Is it possible to spawn a new kubernetes pod via a running container? [...] Originally the service was running on native Windows API and docker....
If the "parent" pod has a correct Kubernetes ServiceAccount, and a Role that allows it to create pods, and there is a RoleBinding from one to the other, then this is possible; see the Kubernetes API Overview. The obvious downside of doing this is that you'd have to specifically use a Kubernetes SDK to do it. That'd be a different mechanism from the Windows process system, or the Docker SDK, or the Linux fork/exec calls.
If the interface to the process really is only shared memory, you could build a single pod that includes both the test driver and the process to test, and the test driver could launch the application as a subprocess. How exactly to do this depends on the language you're using; in Python, for example, you'd use the subprocess module. This setup isn't specific to any particular container runtime, and you could run it the exact same way on a native Unix-like system without containers as well.