Change:
Once that's up you can list the pods in the cluster, to verify that the master and slaves are running: <del> ```shell cluster/cloudcfg.sh list /pods </del> <ins> ```js $ cluster/cloudcfg.sh list /pods Using master: kubernetes-master (external IP: 23.236.49.160) { "kind": "cluster#podList", "items": [ { "id": "redis-master-2", "labels": { "name": "redis-master" }, "desiredState": { "manifest": { "version": "", "volumes": null, "containers": [ { "name": "master", "image": "dockerfile/redis", "ports": [ { "hostPort": 6379, "containerPort": 6379 } ] } ] } }, "currentState": { "manifest": { "version": "", "volumes": null, "containers": null }, "host": "kubernetes-minion-3.c.{project-id}.internal" } }, { "id": "4d65822107fcfd52", "labels": { "name": "redisslave", "replicationController": "redisSlaveController" }, "desiredState": { "manifest": { "version": "", "volumes": null, "containers": [ { "image": "brendanburns/redis-slave", "ports": [ { "hostPort": 6380, "containerPort": 6379 } ] } ] } }, "currentState": { "manifest": { "version": "", "volumes": null, "containers": null }, "host": "kubernetes-minion-3.c.{project-id}.internal" } }, { "id": "78629a0f5f3f164f", "labels": { "name": "redisslave", "replicationController": "redisSlaveController" }, "desiredState": { "manifest": { "version": "", "volumes": null, "containers": [ { "image": "brendanburns/redis-slave", "ports": [ { "hostPort": 6380, "containerPort": 6379 } ] } ] } }, "currentState": { "manifest": { "version": "", "volumes": null, "containers": null }, "host": "kubernetes-minion-2.c.{project-id}.internal" } } ] } </ins> ``` <del> You should see a single redis master pod, and two redis slave pods. </del> <ins> You will see a single redis master pod and two redis slave pods. </ins> ### Step Four: Create the redis slave service. Just like the master, we want to have a service to proxy connections to the read slaves.  In this case, in addition to discovery, the slave service provides transparent load balancing to clients.  As before, create a service specification: <del> ```javascript </del> <ins> ```js </ins> { "id": "redisslave", "port": 10001,

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: I am running an admission webhook using If there it has been hours since the last mutating request to the webhook, then the next mutating request will take many seconds to be processed. This may even take long enough to have the request time out. What you expected to happen: A request takes approximately the same amount of time to be processed regardless of how long it has been since the last request. How to reproduce it (as minimally and precisely as possible): Create an API server for handling a new API group. Wait a couple hours. Send a CREATE request to the API server. Observe that the CREATE request takes a few seconds to complete. Anything else we need to know?: This is the offending code. It must loop through once for every second since the last request. Environment: Kubernetes version (use ): 1.19.0
/sig api-machinery
I thought we'd already merged a fix for this from before the release?
I assume that the fix was supposed to be From my understanding, those changes only are in effect if the apiserver is running with priority and fairness enabled. In my situation, I do not have that enabled.
Ack, if we have the problem in both places we need the fix in both places :)
/triage accepted
I think we have fixed this in , do you guys agree?