K
Q

activeDeadlineSeconds is coming invalid

5/5/2020

we are facing issue while trying to set up activeDeadlineSeconds on Deployment. While we see at kubectl explain, according to that; it is a valid parameter on deployment. Please refer to this image:

enter image description here

Now, when we try to set same parameter to deployment; it say's this is invalid. Please refer to image below:

enter image description here

Please let us know, if we are doing something wrong here. You can use following yaml to do quick experiments:

apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: test
  name: test
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: test
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: test
    spec:
      containers:
      - image: nginx
        name: nginx
        resources: {}
status: {}

we are trying this because in our case there is an init-container which sometimes hangs, because activeDeadlineSeconds includes init containers too; progressdeadlineseconds doesn't include init containers

Is there an alternative to this?

-- Prateek Jain
kubernetes

Similar Questions

Using Digital Ocean Kubernetes Auto-Scaling for auto-downgrading node availability
What will be faster: using gridsearchcv or map-reduce
Nginx Ingress Controller - Failed Calling Webhook
Azure, Containers and horizontal scaling

2 Answers

5/22/2020

Is there an alternative to this?

It's a pretty simple linux task that could be solved using timeout or timelimit binary.

$ timeout -k 1 5 bash -c "while true ; do sleep 1 && echo 1 ; done" || echo
# the above task will be terminated in 5 secs or killed in 6 secs.

# timeout [OPTION] DURATION COMMAND [ARG]...
# -k, --kill-after=DURATION also send a KILL signal if COMMAND is still running
    this long after the initial signal was sent (not available on some containers)
# DURATION is a floating point number with an optional suffix: 's' for
#   seconds (the default), 'm' for minutes, 'h' for hours or 'd' for
#   days.  A duration of 0 disables the associated timeout.
# the above task will be terminated in 5 secs or killed in 6 secs.


$ timelimit -t 5 -T 1 bash -c "while true ; do sleep 1 && echo 1 ; done" || exit 0
# the above task will be terminated in 5 secs or killed in 6 secs.

# -t 5 - five seconds before sending SIGTERM to the process  
# -T 1 - one second after SIGTERM was sent and before sending SIGKILL

Just specify it in the InitContainer command to stop the task after some reasonable time.

To make the InitContainer think that the command is completed successfully even if it was terminated, add || echo or || exit 0 to the end of the command as it shown in the example above.

timeout is present in the system by default (checked on busybox, ubuntu, centos, alpine), but timelimit isn't and could be installed by appropriate packet manager. For ex.:

$ apt-cache search timelimit
timelimit  - simple utility to limit a process's absolute execution time

$ apt-get -y install timelimit

You can find other ways to kill a process using bash commands only:

-- VAS
Source: StackOverflow
5/6/2020

The idea of using activeDeadlineSeconds on a Deployment means that you want to run something that will not last for too long. This goes against the purpose of having a Deployment. A Deployment is meant for things you want to last.

As Amit Kumar Gupta explained:

Syntactically, deployment.spec.template.spec is the same as pod.spec (which is why you see activeDeadlineSeconds in kubectl explain output), but semantically not all the fields in a pod spec are meaningful/allowed/supported in the context of a Deployment (which is why you’re seeing the forbidden error message — under the hood, creating a Deployment results in creating ReplicaSets).

If we check the documentation we can see that activeDeadlineSeconds is available for Jobs and Pods only.

Jobs and Pods are meant to run a task and die after if finishes.

activeDeadlineSeconds

Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer

If you are considering to set activeDeadlineSeconds it means that you don't want you Deployment Pods to last and this is a wrong approach.

Is there an alternative to this?

It really depends on why your application needs this approach. If you really think this approach makes sense, you can open an issue and make a feature request for this.

-- mWatney
Source: StackOverflow