Home > Mobile >  Kubernetes - how to specify image pull secrets, when creating deployment with image from remote priv
Kubernetes - how to specify image pull secrets, when creating deployment with image from remote priv

Time:07-24

I need to create and deploy on an existing Kubernetes cluster, an application based on a docker image which is hosted on private Harbor repo on a remote server.

I could use this if the repo was public:

kubectl create deployment <deployment_name> --image=<full_path_to_remote_repo>:<tag>

Since the repo is private, the username, password etc. are required for it to be pulled. How do I modify the above command to embed that information?

Thanks in advance.

P.S. I'm looking for a way that doesn't involve creating a secret using kubectl create secret and then creating a yaml defining the deployment.

The goal is to have kubectl pull the image using the supplied creds and deploy it on the cluster without any other steps. Could this be achieved with a single (above) command?

Edit: Creating and using a secret is acceptable if there was a way to specify the secret as an option in kubectl command rather than specify it in a yaml (really trying to avoid yaml). Is there a way of doing that?

CodePudding user response:

There are no flags to pass an imagePullSecret to kubectl create deployment, unfortunately.


If you're coming from the world of Docker Compose or Swarm, having one line deployments is fairly common. But even these deployment tools use underlying configuration and .yml files, like docker-compose.yml.

For Kubernetes, there is official documentation on pulling images from private registries, and there is even special handling for docker registries. Check out the article on creating Docker config secrets too.

According to the docs, you must define a secret in this way to make it available to your cluster. Because Kubernetes is built for resiliency/scalability, any machine in your cluster may have to pull your private image, and therefore each machine needs access to your secret. That's why it's treated as its own entity, with its own manifest and YAML file.

  • Related