Minikube
private registry
Kubernetes
installation guide
containerization

Install Minikube using private registry

Master System Design with Codemia

Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.

Introduction

Using Minikube with a private container registry is a common requirement when local testing must match production image flows. Most failures come from missing credentials, namespace mismatch, or certificate trust issues rather than from Minikube itself. A clean workflow is to validate cluster health first, then configure pull auth, then validate with a minimal pull test.

Start with a Healthy Minikube Cluster

Bring up the cluster and confirm node readiness before touching registry configuration.

bash
minikube start --driver=docker
kubectl get nodes
kubectl cluster-info

If the node is not Ready, solve that first. Registry debugging is unreliable on an unhealthy cluster.

Create a dedicated namespace for private image tests:

bash
kubectl create namespace app-dev

Using a namespace boundary helps avoid confusing secret placement.

Create a Registry Pull Secret

Kubernetes image pull credentials are namespace-scoped, so create the secret where workloads run.

bash
1kubectl create secret docker-registry regcred \
2  --namespace app-dev \
3  --docker-server=registry.example.com \
4  --docker-username=myuser \
5  --docker-password='mypassword' \
6  --docker-email=[email protected]

Verify secret creation:

bash
kubectl get secret regcred -n app-dev

If your registry uses token auth, use token value in password field according to provider guidance.

Attach Pull Secret to Deployment

Reference the secret in pod template.

yaml
1apiVersion: apps/v1
2kind: Deployment
3metadata:
4  name: private-app
5  namespace: app-dev
6spec:
7  replicas: 1
8  selector:
9    matchLabels:
10      app: private-app
11  template:
12    metadata:
13      labels:
14        app: private-app
15    spec:
16      imagePullSecrets:
17        - name: regcred
18      containers:
19        - name: app
20          image: registry.example.com/team/private-app:1.0.0
21          ports:
22            - containerPort: 8080

Apply and inspect status:

bash
kubectl apply -f deployment.yaml
kubectl get pods -n app-dev
kubectl describe pod -n app-dev <pod-name>

Pod events usually show the exact cause of pull failures.

Set Namespace Default Pull Secret

If every workload in a namespace uses the same registry, patch the default service account.

bash
kubectl patch serviceaccount default \
  -n app-dev \
  -p '{"imagePullSecrets": [{"name": "regcred"}]}'

This avoids repeating imagePullSecrets in every manifest.

Handle Internal Registry TLS Trust

Authentication may be correct while pull still fails because node runtime does not trust registry certificate.

For isolated local development only, insecure registry mode can unblock testing:

bash
minikube delete
minikube start --driver=docker --insecure-registry="registry.example.com"

Use this only in local non-production contexts. In secure environments, install proper CA trust instead.

Validate with a Minimal Pull Test

Test registry pull separately from app behavior using a one-shot pod.

bash
1kubectl run pull-test \
2  --namespace app-dev \
3  --image=registry.example.com/team/private-app:1.0.0 \
4  --restart=Never \
5  --command -- /bin/sh -c "echo pull-ok"
6
7kubectl get pod pull-test -n app-dev
8kubectl logs pull-test -n app-dev
9kubectl describe pod pull-test -n app-dev

If this succeeds, your auth and trust path is likely correct.

Rotate Credentials Safely

When registry credentials rotate, update secret and restart workloads so the new secret is used on subsequent pulls.

bash
1kubectl delete secret regcred -n app-dev
2kubectl create secret docker-registry regcred \
3  --namespace app-dev \
4  --docker-server=registry.example.com \
5  --docker-username=myuser \
6  --docker-password='newpassword' \
7  --docker-email=[email protected]
8kubectl rollout restart deployment/private-app -n app-dev

Skipping rollout restart can leave running workloads on stale pull behavior until rescheduling.

Team Workflow Recommendations

For repeatable local onboarding:

  • keep manifests free of plaintext credentials
  • centralize secret creation commands in secure team docs
  • document one standard Minikube driver and registry setup
  • keep registry URL and image naming conventions consistent

Consistency reduces environment drift and shortens debugging time.

Common Pitfalls

The most common mistake is creating pull secret in the wrong namespace. Secrets are not shared across namespaces by default.

Another issue is forgetting to reference imagePullSecrets in pod spec or service account.

Many developers test only with cached images. The deployment appears healthy until a new tag forces a real pull.

TLS trust errors are often misread as auth failures. Check pod event messages carefully to separate certificate and credential problems.

Finally, storing registry credentials in version-controlled YAML files creates security risk and rotation overhead.

Summary

  • Minikube private registry setup depends on cluster health, credentials, and TLS trust.
  • Create pull secrets in the same namespace as your workloads.
  • Attach secrets in pod specs or namespace service accounts.
  • Use minimal pull tests to isolate registry issues quickly.
  • Treat credential rotation and secret handling as part of normal operations.

Course illustration
Course illustration

All Rights Reserved.