ancient-wolf-19325
07/12/2024, 9:13 AMv1.12.0) has been throwing some intermittent error while starting task as our workload increase where they are many pod starting at the same time. This happen once every 1-2 days, which isn't that bad but still breaks our workflow requiring manual intervention on alerts. Retries doesn't seem to work, because the task are not even started.
Grace period [3m0s] exceeded|containers with unready status: [f6140adc65c3a4d47000-n1-0]|failed to reserve container name "f6140adc65c3a4d47000-n1-0...": name "f6140adc65c3a4d47000-n1-0..." is reserved for "189f5dbee3fbc4a26ff7a619fcea34ad..."
Grace period [0s] exceeded|containers with unready status: [f9fd2612618924083000-n2-0]|failed to sync secret cache: timed out waiting for the condition
So far, we have increased the grace period for config.K8sPluginConfig
create-container-config-error-grace-period: 0s
create-container-error-grace-period: 3m0s
Beside upgrade the cluster resource for the load, are there other config that we can tweak to improve this or to have retries kicking in? Thanks!
# Answer
The errors you are encountering are related to transient issues during pod initialization, such as container name reservation conflicts and secret cache synchronization timeouts. Increasing the grace period for create-container-config-error-grace-period can help mitigate these issues by allowing more time for the container to initialize successfully before marking it as failed.
Configuration Adjustments
1. Increase Grace Periods:
- Increase create-container-config-error-grace-period to allow more time for the container to resolve transient issues.
- Ensure that create-container-error-grace-period is sufficiently long for your workload.
Example configuration:
create-container-config-error-grace-period: 5m0s
create-container-error-grace-period: 5m0s
2. Resource Requests and Limits:
- Ensure that resource requests and limits for your pods are properly configured to avoid contention.
- Set requests equal to limits to ensure consistent resource allocation.
Example configuration:
resources:
limits:
cpu: 2
memory: 4Gi
requests:
cpu: 2
memory: 4Gi
3. Kubelet Configuration:
- Adjust kubelet settings to handle higher loads, such as increasing registryPullQPS and registryBurst values.
Example configuration:
kubelet:
registryPullQPS: 50
registryBurst: 100
Implementation
Update your Flyte configuration to include these changes. Here is an example of how to adjust the configurations in the Flyte Helm chart:
flyteadmin:
config:
K8sPluginConfig:
create-container-config-error-grace-period: 5m0s
create-container-error-grace-period: 5m0s
resources:
limits:
cpu: 2
memory: 4Gi
requests:
cpu: 2ancient-wolf-19325
07/12/2024, 9:13 AM>>```memory: 4Gi ``` Further Investigation If the issue persists, you may need to investigate further by examining the Kubernetes and FlytePropeller logs for any anomalies during the pod lifecycle. Additionally, consider enabling finalizers to prevent Kubernetes from prematurely garbage collecting resources, as discussed in this Flyte discussion. Would you like more detailed steps on how to implement these changes or further troubleshooting steps? Sources: - Flyte discussion on finalizers - Flyte discussion on unexpected pod deletions - Flyte Helm Chart Configuration Slack Link https://flyte-org.slack.com/archives/CP2HDHKE1/p1720775616.159299 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.