The reason that you're having trouble is that the kubelet agent running on the node where the pod is scheduled is what pulls the container image, not your workstation, and port-forwarding the registry to your local workstation does not provide this access.

In previous Kubernetes versions, there was to be a registry cluster addon, but that has been taken out of the mainline tree (though some distributions like Microk8s and Minikube have their own), so you will need to use a bit of elbow grease to get this working. I would caution, though, that using a registry external to the cluster, such as Google Container Registry (GKE), or even just a private Docker Hub repository is, generally, a much better design pattern for production use as it avoids things like circular dependencies and also removes the operational effort of keeping the registry running and secured.

In general, the steps are:

1. Get the registry running. You can use the docker-registry Helm chart, for example.
2. Expose the registry to the host. This could be as a ClusterIP, NodePort service, via Host Networking, or, if you have an appropriate CNI plugin, by simply exposing a host-routable IP address. The most "compatible" way to do this will be a ClusterIP service (i.e. this strategy will work on almost any cluster), but is also the most clunky as you will not be able to push images into it from outside of the cluster.
3. Refer to the registry by its "publicly" accessible address (i.e. the one that the node can use to connect) in the image field on the Pod/Deployment spec.
4. If required, use an ImagePullSecret to provide credentials to pull the private image with.

A related question can be found here: Kubernetes: Pull images from internal registry with on-premise deployment and a reasonably comprehensive blog post can be found here: https://medium.com/@jmarhee/deploying-a-docker-registry-with-persistent-storage-and-local-only-access-on-your-kubernetes-1c6470d3611c