ReplicaFailure indicates that the Kubernetes ReplicaSet controller cannot create or maintain the desired number of pod replicas. This is usually caused by resource constraints, image pull errors, or security policy violations that prevent pod creation.
ReplicaFailure is a Deployment condition that appears when the ReplicaSet controller repeatedly fails to create new pods. When you describe a deployment with this condition, you'll see `Type: ReplicaFailure, Status: True, Reason: FailedCreate`. The ReplicaSet wants to create pods but something is blocking creation—either the pod specification is invalid, resources are exhausted, or admission controllers are rejecting the pods. This is different from pods failing after creation (CrashLoopBackOff). ReplicaFailure means the pods never get created in the first place.
This is the most common cause. Run:
kubectl describe quota -n <namespace>
kubectl describe resourcequota -n <namespace>Look at Used vs Limit columns. If requests are at or near the limit, that's blocking new pods. Either scale down other deployments or increase the quota:
kubectl edit resourcequota <quota-name> -n <namespace>
# Increase the limits for cpu, memory, and podsGet more information than the Deployment:
kubectl get replicaset -n <namespace>
kubectl describe replicaset <rs-name> -n <namespace>The Events section at the bottom shows the actual error. Common ones:
- "Insufficient cpu": Pod requests exceed available resources
- "pod already exists": State inconsistency
- "Pod creation blocked": Admission controller rejection (PodSecurityPolicy, Istio, custom webhooks)
Check the image reference in your deployment:
kubectl get deploy <name> -o yaml | grep -A2 image:Verify the image exists:
docker pull myregistry.com/myimage:tagFor private registries, verify imagePullSecrets:
spec:
imagePullSecrets:
- name: regcred # Must match a valid secret
containers:
- image: private.registry/image:tagCreate if missing: kubectl create secret docker-registry regcred --docker-server=... --docker-username=... --docker-password=...
Validate your deployment YAML:
kubectl apply -f deployment.yaml --dry-run=clientCommon issues:
- typos in field names
- invalid resource requests (e.g., "100G" instead of "100Gi")
- missing or malformed probe configurations
- invalid security contexts
Get current spec to review: kubectl get deploy <name> -o yaml
Check overall cluster capacity:
kubectl top nodes
kubectl describe nodes
kubectl get --raw /api/v1/namespaces/<ns>/podsIf all nodes show CPU/memory pressure, the cluster is full. Solutions:
- Scale down other deployments
- Add more worker nodes
- Reduce resource requests in your pod spec
For resource requests, check current deployment:
kubectl get deploy <name> -o yaml | grep -A5 resources:Check the service account:
kubectl get sa -n <namespace>
kubectl describe sa <sa-name> -n <namespace>Verify RBAC bindings allow pod creation:
kubectl get rolebindings,clusterrolebindings -n <namespace> -o wideIf missing, create a role with pod creation permissions:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: pod-creator
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["create", "get", "list"]If using Istio, service mesh, or custom admission webhooks, they may be rejecting pods:
kubectl get validatingwebhookconfigurations
kubectl get mutatingwebhookconfigurationsDescribe to see rules:
kubectl describe validatingwebhookconfigurations <name>Check admission controller logs:
kubectl logs -n istio-system deployment/istiod # For Istio
kubectl logs -n kube-system <admission-pod> # For custom controllersIf everything looks correct but pods take time to schedule, increase the timeout:
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp
spec:
progressDeadlineSeconds: 1800 # 30 minutes instead of default 10
# ... rest of specApply: kubectl apply -f deployment.yaml
In Docker Desktop's limited single-node cluster, resource quotas are common bottlenecks—try removing or increasing them. For Minikube, allocate more CPUs/memory at startup. In multi-node clusters, uneven resource distribution may schedule pods on under-resourced nodes despite overall available resources. Limit Range violations are similar to quota issues but apply per-pod rather than namespace-wide—check with kubectl describe limits. For WSL2-based Kubernetes, ensure adequate disk space and memory in the WSL environment. In GitOps workflows, if deployment was previously working, ReplicaFailure may indicate external changes (quotas modified, admission webhooks added, node resources consumed by other workloads).
Failed to connect to server: connection refused (HTTP/2)
How to fix "HTTP/2 connection refused" error in Kubernetes
missing request for cpu in container
How to fix "missing request for cpu in container" in Kubernetes HPA
error: invalid configuration
How to fix "error: invalid configuration" in Kubernetes
etcdserver: cluster ID mismatch
How to fix "etcdserver: cluster ID mismatch" in Kubernetes
running with swap on is not supported
How to fix "running with swap on is not supported" in kubeadm