Control plane scalability

Cloudfleet provides a fully managed Kubernetes service, so we take on the operational work of scaling and maintaining your cluster’s control plane. A healthy, responsive cluster depends on a well-performing control plane, and our team makes sure it handles your growing demands. Cloudfleet handles the underlying scaling. This guide explains how the components interact and how you can optimize your usage patterns for the best performance. This guide gives best practices for how your interactions with the API Server can affect the performance and scaling of other managed components, like the Controller Manager and Scheduler.

Understanding API server scalability

The API Server is often the most heavily used component. Efficient requests and interactions with it are key.

API priority and fairness (APF)

Think of the Kubernetes API server as a busy intersection in a city. All requests for your cluster pass through it: every kubectl command, every deployment update, every application query. Without good traffic management, the intersection can quickly become blocked, especially if one or two sources send a flood of requests. Kubernetes API Priority and Fairness (APF) acts as the traffic controller for your cluster.

APF keeps the API server responsive and stable for everyone. It sorts incoming requests into priority levels and uses flow schemas to decide which priority a request gets. It works like a road with express lanes for emergency vehicles (critical system operations), where regular traffic (user and application requests) still flows fairly. No single driver takes all the lanes. This prioritization stops a single user or a badly behaving application from overloading the API server and slowing down other critical cluster functions.

Cloudfleet uses APF to keep the platform stable for all users. To manage resources and keep fairness, especially on Basic clusters, we use specific APF settings. These include a priority class for Basic cluster users. This class has defined concurrency shares (how many requests the server handles at once). It also has queuing mechanisms (what happens if too many requests arrive at the same time). Pro cluster users, on the other hand, are not subject to these specific Basic cluster limitations. They get higher, dedicated concurrency limits, and their control plane runs on dedicated resources. Their production workloads get the priority and throughput they need.

To find out if APF affects your API requests, look for specific symptoms and metrics. You might see increased latency for your kubectl commands, or HTTP 429 “Too Many Requests” errors from the API server. If you suspect APF, and you have the necessary permissions, check the API server’s metrics. Query the /metrics endpoint (for example, with kubectl get --raw /metrics) and look for specific indicators. These commands can produce a lot of data. In a production environment, you typically track these metrics with a monitoring system like Prometheus:

bash 
# Check for any rejected requests by APF (filter by 'priority_level' if needed)
kubectl get --raw /metrics \
  | grep "apiserver_flowcontrol_rejected_requests_total"

# Check current in-queue requests (filter by 'priority_level' if needed)
kubectl get --raw /metrics \
  | grep "apiserver_flowcontrol_current_inqueue_requests"

# Check request wait duration
# (filter by 'priority_level' if needed, shows buckets)
kubectl get --raw /metrics \
  | grep "apiserver_flowcontrol_request_wait_duration_seconds_bucket"

If queued or rejected requests seem to correspond with your activity, review your API usage patterns (see the next section). If you use Basic clusters and consistently hit these limits, upgrade to Pro clusters for higher throughput.

Optimizing your interactions with the API server

APF manages overall traffic. The way your own applications, scripts, and tools communicate with the API server also strongly affects its load, and so your application’s performance. Efficient API usage patterns are key. For example, to monitor changes to resources, open a WATCH connection instead of polling repeatedly with GET or LIST requests. A watch gives a continuous stream of updates and greatly reduces the number of individual requests. When you list resources, be specific. Avoid broad LIST requests like kubectl get pods --all-namespaces if you don’t need information from every Namespace. Use Field Selectors and Label Selectors to limit your query to the objects you need. For very large result sets, use pagination (limit and continue parameters) to get objects in manageable chunks. If you need only the names of resources, request a specific output format like kubectl get ... -o name. This is much lighter on the API server than full YAML or JSON manifests. If you develop custom controllers or applications that interact heavily with the API server, implement client-side throttling. Kubernetes client libraries, such as client-go, often include built-in rate limiters that stop your application from overloading the API. Avoid many small, frequent updates to the same object. If possible, batch them into fewer, larger updates. Stay within the object size and data store quotas that the cluster’s storage backend enforces. Finally, be careful with GET requests inside tight loops. If you fetch the same object repeatedly and it changes rarely, cache it locally, or use a WATCH for updates.

Considerations for custom resource definitions (CRDs)

Custom Resource Definitions (CRDs) extend the Kubernetes API and let you define your own resource types. CRDs can also affect API server performance. Each CRD adds new API endpoints that the server must handle. A very large number of CRDs, or CRDs with very complex schemas or validation rules, can increase the API server’s memory footprint. They can also slow down operations like API discovery. When you design and use CRDs, aim for clarity and efficiency. Keep your CRD schemas as concise as your use case allows. If your custom controllers interact with these CRDs, make sure they follow the efficient API usage patterns above to avoid unnecessary load. Careful CRD management improves all API server interactions.

Impact of your workloads on other control plane components

Cloudfleet scales the Controller Manager and Scheduler appropriately. The type and volume of your workloads still affect their efficiency. Keep these key aspects in mind:

  • Volume of objects: A very high number of Kubernetes objects (like Pods, Deployments, Services, and Endpoints) increases the work these components do. The Controller Manager watches and reconciles more resources. The Scheduler considers more Pods and nodes for each placement decision.
  • Controller efficiency: If you develop custom controllers, make them use efficient selectors and avoid unnecessary API calls. This prevents extra strain on the system.
  • Pod churn: A very large number of very short-lived Pods (high churn) also loads these components, because they constantly process creation and deletion events.
  • Resource definitions: Define resource requests and limits for your Pods. With them, the Scheduler makes optimal placement decisions, which improves cluster stability and resource efficiency.

Consider these factors when you design and deploy your applications, so the managed Controller Manager and Scheduler run as efficiently as possible. A reliable, high-performing cluster depends on how your workloads interact with the managed Kubernetes control plane. When you follow best practices in API usage and workload design, you support the stability and efficiency of Cloudfleet’s managed service. Our APF configurations give a stable platform for all users. They include specific settings for the Basic cluster, and dedicated resources and higher limits for Pro cluster users. If you have specific scaling challenges or more questions, contact the Cloudfleet support team.

Previous
← Kubernetes versions and upgrades
On this page