Docker image names in Kubernetes manifests follow the same rules as everywhere else. If you have an image name like postgres:9.6 or myname/myimage:foo, those will be looked up on Docker Hub like normal. If you're using a third-party repository (Google GCR, Amazon ECR, quay.io, ...) you need to include the repository name in the image name. It's the exact same string you'd give to docker run or docker build -t.

Helm doesn't directly talk to the Docker registry. The Helm flow here is:

1. The local Helm client sends the chart to the Helm Tiller.
2. Tiller applies any templating in the chart, and sends it to the Kubernetes API.
3. This creates a Deployment object with an embedded Pod spec.
4. Kubernetes creates Pods from the Deployment, which have image name references.

So if your Helm chart names an image that doesn't exist, all of this flow will run normally, until it creates Pods that wind up in ImagePullBackOff state.

P.S.: if you're not already doing this, you should make the image tag (the part after the colon) configurable in your Helm chart, and declare your image name as something like myregistry.io/myname/myimage:{{ .Values.tag }}. Your CD system can then give each build a distinct tag and pass it into helm install. This makes it possible to roll back fairly seamlessly.