TKE 集群的可用性与集群 Pod、ConfigMap、CRD、Event 等资源的数量、以及各类资源的 Get/List 读操作 QPS、Patch/Delete/Create/Update 等写操作 QPS 密切相关，应尽量避免对资源数量较多的集群发起类 List 操作，避免把 TKE 集群当数据库使用，写入过多的 ConfigMap/CRD/EndPoints 等，影响集群可用性。
常见的类 List 操作如下（以 Pod 资源为例）：
带标签查询
kubectl get pod -l app=nginx指定 namespace 查询
kubectl get pod -n default查询整个集群的 pod 等
kubectl get pod --all-namespaces通过 client-go 发起的 List 请求
k8sClient.CoreV1().Pods("").List(metav1.ListOptions{})
如您有类似查询集群全量资源的需求，建议使用 K8s 的 informer 机制通过本地 cache 查询。对于一些简单的场景，可以通过在 List 请求中增加 ResourceVersion 参数，在 kube-apiserver cache 中查询，如 k8sClient.CoreV1().Pods("").List(metav1.ListOptions{ResourceVersion: "0"})。需注意，即使从 kube-apiserver cache 查询，如果对大量资源频繁发起 List 请求，仍会对 kube-apiserver 内存造成较大压力，仅建议在请求频率较低时使用该方式。
推荐配置
请在选购集群时参考如下推荐配置，根据业务实际情况选择合适的集群规格，以免集群控制面组件负载过大导致集群不可用。
例如，如果您计划在一个集群中部署50个节点，但是计划部署2000个 Pod, 则应该选用最大管理节点规模为100（而非50）的集群规格。
说明
- 节点指 Kubernetes Node, 包含 CVM 节点**。**
- Pod 包括所有 Namespace 下，所有状态的 Pod，但不包括系统组件相关 Pod（cni-agent 等）。
- CRD 不统计 TKE 系统组件产生的 CRD（如 VPC-CNI 相关组件产生的 CRD）。
- 最大其他 K8s 资源数量指除表格中单独列出的资源外，其他的 K8s 资源的最大数量。例如您购买了最大管理节点规模为L100的集群，为了保障集群的可用性，集群中的 ClusterRole、Service、Endpoint 等 K8s 资源的数量均不应该超过2500。
- 建议每种资源类型的所有对象总和不应超过800MiB，每个资源对象大小不超过100KB。
| 集群规格 | 最大管理节点数量 | 最大 Pod 数量（推荐） | 最大 replicasets 数量 | 最大 ConfigMap 数量（推荐） | 最大 CRD 数量 / 最大其他 K8s 资源数量（推荐） |
|---|---|---|---|---|---|
| L5 | 5 | 150 | 900 | 128 | 150 |
| L20 | 20 | 600 | 3600 | 256 | 600 |
| L50 | 50 | 1500 | 9000 | 512 | 1250 |
| L100 | 100 | 3000 | 18000 | 1024 | 2500 |
| L200 | 200 | 6000 | 36000 | 2048 | 5000 |
| L500 | 500 | 15000 | 90000 | 4096 | 10000 |
| L3000 | 3000 | 90000 | 540000 | 8192 | 50000 |
| L5000 | 5000 | 150000 | 900000 | 10240 | 100000 |