Are you running the container in the same namespace as namespace with deployment.yml? One of the option to check that would be to run -

kubectl get pods --all-namespaces

If you are not able to find the docker container there than I would suggest performing below steps -

1. docker ps -a {verify running docker status}
2. Ensuring that while mounting docker.sock there are no permission errors
3. If there are permission errors, escalate privileges to the appropriate level

To answer the second question, connection between two containers should be possible by referencing cluster DNS in below format -

"<servicename>.<namespacename>.svc.cluster.local"

I would also request you to detail steps, codes and errors(if there are any) for me to better answer the question.

You probably shouldn't be directly accessing the Docker API from anywhere in Kubernetes. Kubernetes will be totally unaware of anything you manually docker run (or equivalent) and as you note normal administrative calls like kubectl get pods 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.

A process running in a pod can access the Kubernetes API directly, 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, servicename.namespacename.svc.cluster.local is a valid DNS name that reaches any Pod connected to the Service.)

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 (e.g., 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.