<p>Kubernetes breaks (no response from <code>kubectl</code>) when I have <strong>too many Pods</strong> running in the cluster (1000 pods).  </p>

<p>There are <strong>more than enough resources</strong> (CPU and memory), so it seems to me that some kind of controller is breaking and unable to handle a large number of Pods.  </p>

<p>The workload I need to run can be massively parallel processed, hence I have a high number of Pods.  </p>

<p>Actually, I would like to be able to run many more times 1000 Pods. Maybe even <strong>100,000 Pods</strong>.    </p>

<p>My Kubernetes master node is an <code>AWS EC2 m4.xlarge</code> instance. </p>

<p>My intuition tells me that it is the master node's network performance that is holding the cluster back?  </p>

<p>Any ideas?  </p>

<p><strong>Details:</strong><br>
I am running 1000 Pods in a Deployment.<br>
when I do <code>kubectl get deploy</code><br>
it shows:  </p>

<pre><code>DESIRED  CURRENT  UP-TO-DATE  AVAILABLE  
1000     1000     1000        458  
</code></pre>

<p>and through my application-side DB, I can see that there are only 458 Pods working.  </p>

<p>when I do <code>kops validate cluster</code><br>
I receive the warning:  </p>

<pre><code>VALIDATION ERRORS
KIND            NAME                                                                    MESSAGE
ComponentStatus controller-manager                                                      component is unhealthy
ComponentStatus scheduler                                                               component is unhealthy
Pod             kube-system/kube-controller-manager-&lt;ip&gt;.ec2.internal        
kube-system pod 
"kube-controller-manager-&lt;ip&gt;.ec2.internal" is not healthy
Pod             
kube-system/kube-scheduler-&lt;ip&gt;.ec2.internal                 
kube-system pod "kube-scheduler-&lt;ip&gt;.ec2.internal" is not healthy
</code></pre>

cryanbhu
<p>The fact that it takes a long time to list your pods is not really about your nodes as they will able to handle pods as much depending on the resources they have such CPUs and Memory.</p>

<p>The issue you are seeing is more about the <code>kubeapi-server</code> being able query/reply a large number of pods or resources.</p>

<p>So the two contention points here are the kube-apiserver and etcd where the state for everything in a Kubernetes cluster is stored. So you can focus on optimizing those two components and the faster you'll get responses from say <code>kubectl get pods</code> (Networking is another contention point but that's if you are issuing kubectl commands from a slow broadband connection).</p>

<p>You can try:</p>

<ul>
<li><p>Setting up an <a href="https://kubernetes.io/docs/setup/independent/setup-ha-etcd-with-kubeadm/" rel="nofollow noreferrer">HA external etcd cluster</a> with pretty beefy machines and fast disks.</p></li>
<li><p>Upgrade the machines where your <code>kubeapi-server</code>(s) lives.</p></li>
<li><p>Follow more guidelines described <a href="https://kubernetes.io/docs/setup/cluster-large/" rel="nofollow noreferrer">here</a>.</p></li>
</ul>
