After applying the following ResourceQuota compute-resources to my GKE Cluster
apiVersion: v1
kind: ResourceQuota
metadata:
name: compute-resources
spec:
hard:
limits.cpu: "1"
limits.memory: 1Giand updating a Deployment to
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-service
spec:
selector:
matchLabels:
app: my-service
tier: backend
track: stable
replicas: 2
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 50%
template:
metadata:
labels:
app: my-service
tier: backend
track: stable
spec:
containers:
- name: my-service
image: registry/namespace/my-service:latest
ports:
- name: http
containerPort: 8080
resources:
requests:
memory: "128Mi"
cpu: "125m"
limits:
memory: "256Mi"
cpu: "125m"the scheduling fails 100% of tries due to pods "my-service-5bc4c68df6-4z8wp" is forbidden: failed quota: compute-resources: must specify limits.cpu,limits.memory. Since limits and requests are specified and they fulfill the limit, I don't see a reason why the pods should be forbidden.
How pod limits resource on kubernetes enforced when the pod exceed limits after pods is created ? is a different question.
I upgraded my cluster to 1.13.6-gke.0.
I was about to suggest to test within separate namespace, but see that you already tried.
As another workaround try to setup default limits by enabling LimitRanger admission controller and setting it up e.g.
apiVersion: v1
kind: LimitRange
metadata:
name: cpu-limit-range
spec:
limits:
- default:
memory: 256Mi
cpu: 125m
defaultRequest:
cpu: 125m
memory: 128Mi
type: ContainerNow if a Container is created in the default namespace, and the Container does not specify its own values for CPU request and CPU limit, the Container is given a default CPU limits of 125m and a default memory limit of 256Mi
Also, after setting up LimitRange, make sure you removed your deployment and there are no pods stuck in failed state.