Configure Deployment-level limits for individual Pod sizes
You can useastronomer.houston.config.deployments.maxPodCapacity to configure the maximum size any individual pod can be.
Configure Deployment-level limits for resource usage
Astro Private Cloud limits the amount of resources that can be used by all pods in a Deployment by creating and managing aLimitRange and ResourceQuota for the namespace associated with each Deployment.
These values are automatically adjusted to account for the resource requirements of various components.
You can add additional resources, beyond the standard amount allocated based on the resource-requirements of standing components, to the LimitRange and ResourceQuota. Add resources by configuring astronomer.houston.config.deployments.maxExtraCapacity to account for the requirements of KubernetesExecutor and KubernetesPodOperator tasks.
Configure the sizes of individual Deployment-level components
Components represent different parts of the Astro Private Cloud Deployment. You can customize the default configuration for a component by defining it inastronomer.houston.config.deployments.components.
A list of configurable components and options is provided in Configurable Components.
When defining components, you must include the full definition of the component in the list entry after the components key, instead of only the components you want to define.
For example, to increase the maximum size a Celery worker task from 3 Vcpu/11.5Gi to 3 Vcpu/192Gi, add the equivalent (in milli vCPU and Mi) full Celery worker component definition to astronomer.houston.config.deployments.components in your values.yaml with a higher limit:
Configurable Components
When defining components, you must include the full definition of the component in the list entry after the components key, instead of only the components you want to define.
Airflow Scheduler
Airflow Webserver
Airflow API server (Airflow 3.0 and above)
StatsD
Database Connection Pooler (PgBouncer)
Celery Diagnostic Web Interface (Flower)
Redis
Celery Workers
Triggerer
Dag Processor
Manage Kubernetes worker CPU and memory with global platform config
You can useworkers.resources.enabled for the KubernetesExecutor to manage worker Pod CPU and memory allocations with a platform configuration. When set to false, Astro Private Cloud ignores worker Pod CPU or memory allocations set in the API or UI. This allows you to control Pod resources with your own Kubernetes policies or admission controllers.
API/UI manages Pod resources (Default KubernetesExecutor configuration)
To configure the default behavior where the API and UI manage worker Pod CPU and memory resources for the KubernetesExecutor, use the following configuration:Disable API/UI resource configuration
If you configure your KubernetesExecutor so that CPU and memory requests and limits are set outside of Astro Private Cloud, you must disable resource configuration set with the Astro Private Cloud API/UI. To disable the Astro Private Cloud UI/API configuration, add theresources.enabled: false flag to your values.yaml file. This ensures that Astro Private Cloud applies the worker resource settings exclusively from your preferred source, such as Pod mutation hooks or Pod configuration files. The following configuration sets them as an empty dict.
Configure the size of KubernetesExecutor task pods
Kubernetes Executor task pods are defined at the task level when the Dag passes resource requests as part ofexecutor_config into the Operator. When not defined, these tasks default to using 0.1 Vcpu/384 Mi of memory. This means that when you define resource requests or limits for CPU and memory, ensure the maximum pod size is large enough to avoid errors during pod creation.
Astro Private Cloud does not automatically raise the namespace-level cumulative resource limits for pods created by the KubernetesExecutor. To avoid pod creation failures, increase the
maxExtraCapacity to support your desired level of resourcing and concurrency.LimitRanges and quotas defined within the pod namespace.