<p>I am creating a docker container ( using docker run) in a kubernetes Environment by invoking a rest API.<br>
I have mounted the docker.sock of the host machine and i am building an image and running that image from RESTAPI..<br>
Now i need to connect to this container from some other container which is actually started by Kubectl from deployment.yml file.<br>
But when used kubeclt describe pod (Pod name), my container created using Rest API is not there..  <strong>So where is this container running and how can i connect to it from some other container</strong> ?</p>

avinashjha
<p>You probably shouldn't be directly accessing the Docker API from anywhere in Kubernetes.  Kubernetes will be totally unaware of anything you manually <code>docker run</code> (or equivalent) and as you note normal administrative calls like <code>kubectl get pods</code> won't see it; the CPU and memory used by the pod won't be known about by the node interface and this could cause a node to become over utilized.  The Kubernetes network environment is also pretty complicated, and unless you know the details of your specific CNI provider it'll be hard to make your container accessible at all, much less from a pod running on a different node.</p>

<p>A process running in a pod can <a href="https://kubernetes.io/docs/tasks/administer-cluster/access-cluster-api/" rel="nofollow noreferrer">access the Kubernetes API directly</a>, though.  That page notes that all of the official client libraries are aware of the conventions this uses.  This means that you should be able to directly create a Job that launches your target pod, and a Service that connects to it, and get the normal Kubernetes features around this.  (For example, <code>servicename.namespacename.svc.cluster.local</code> is a valid DNS name that reaches any Pod connected to the Service.)</p>

<p>You should also consider whether you actually need this sort of interface.  For many applications, it will work just as well to deploy some sort of message-queue system (<em>e.g.</em>, RabbitMQ) and then launch a pool of workers that connects to it.  You can control the size of the worker queue using a Deployment.  This is easier to develop since it avoids a hard dependency on Kubernetes, and easier to manage since it prevents a flood of dynamic jobs from overwhelming your cluster.</p>
