Class CronJobProps.Jsii$Proxy

    • Constructor Detail

      • Jsii$Proxy

        protected Jsii$Proxy​(software.amazon.jsii.JsiiObjectRef objRef)
        Constructor that initializes the object based on values retrieved from the JsiiObject.
        Parameters:
        objRef - Reference to the JSII managed object.
    • Method Detail

      • getSchedule

        public final org.cdk8s.Cron getSchedule()
        Description copied from interface: CronJobProps
        Specifies the time in which the job would run again.

        This is defined as a cron expression in the CronJob resource.

        Specified by:
        getSchedule in interface CronJobProps
      • getFailedJobsRetained

        public final Number getFailedJobsRetained()
        Description copied from interface: CronJobProps
        Specifies the number of failed jobs history retained.

        This would retain the Job and the associated Pod resource and can be useful for debugging.

        Default: 1

        Specified by:
        getFailedJobsRetained in interface CronJobProps
      • getStartingDeadline

        public final org.cdk8s.Duration getStartingDeadline()
        Description copied from interface: CronJobProps
        Kubernetes attempts to start cron jobs at its schedule time, but this is not guaranteed.

        This deadline specifies how much time can pass after a schedule point, for which kubernetes can still start the job. For example, if this is set to 100 seconds, kubernetes is allowed to start the job at a maximum 100 seconds after the scheduled time.

        Note that the Kubernetes CronJobController checks for things every 10 seconds, for this reason, a deadline below 10 seconds is not allowed, as it may cause your job to never be scheduled.

        In addition, kubernetes will stop scheduling jobs if more than 100 schedules were missed (for any reason). This property also controls what time interval should kubernetes consider when counting for missed schedules.

        For example, suppose a CronJob is set to schedule a new Job every one minute beginning at 08:30:00, and its startingDeadline field is not set. If the CronJob controller happens to be down from 08:29:00 to 10:21:00, the job will not start as the number of missed jobs which missed their schedule is greater than 100. However, if startingDeadline is set to 200 seconds, kubernetes will only count 3 missed schedules, and thus start a new execution at 10:22:00.

        Default: Duration.seconds(10)

        Specified by:
        getStartingDeadline in interface CronJobProps
      • getSuccessfulJobsRetained

        public final Number getSuccessfulJobsRetained()
        Description copied from interface: CronJobProps
        Specifies the number of successful jobs history retained.

        This would retain the Job and the associated Pod resource and can be useful for debugging.

        Default: 3

        Specified by:
        getSuccessfulJobsRetained in interface CronJobProps
      • getSuspend

        public final Boolean getSuspend()
        Description copied from interface: CronJobProps
        Specifies if the cron job should be suspended.

        Only applies to future executions, current ones are remained untouched.

        Default: false

        Specified by:
        getSuspend in interface CronJobProps
      • getActiveDeadline

        public final org.cdk8s.Duration getActiveDeadline()
        Description copied from interface: JobProps
        Specifies the duration the job may be active before the system tries to terminate it.

        Default: - If unset, then there is no deadline.

        Specified by:
        getActiveDeadline in interface JobProps
      • getBackoffLimit

        public final Number getBackoffLimit()
        Description copied from interface: JobProps
        Specifies the number of retries before marking this job failed.

        Default: - If not set, system defaults to 6.

        Specified by:
        getBackoffLimit in interface JobProps
      • getTtlAfterFinished

        public final org.cdk8s.Duration getTtlAfterFinished()
        Description copied from interface: JobProps
        Limits the lifetime of a Job that has finished execution (either Complete or Failed).

        If this field is set, after the Job finishes, it is eligible to be automatically deleted. When the Job is being deleted, its lifecycle guarantees (e.g. finalizers) will be honored. If this field is set to zero, the Job becomes eligible to be deleted immediately after it finishes. This field is alpha-level and is only honored by servers that enable the TTLAfterFinished feature.

        Default: - If this field is unset, the Job won't be automatically deleted.

        Specified by:
        getTtlAfterFinished in interface JobProps
      • getPodMetadata

        public final org.cdk8s.ApiObjectMetadata getPodMetadata()
        Description copied from interface: WorkloadProps
        The pod metadata of this workload.
        Specified by:
        getPodMetadata in interface WorkloadProps
      • getSelect

        public final Boolean getSelect()
        Description copied from interface: WorkloadProps
        Automatically allocates a pod label selector for this workload and add it to the pod metadata.

        This ensures this workload manages pods created by its pod template.

        Default: true

        Specified by:
        getSelect in interface WorkloadProps
      • getContainers

        public final List<ContainerProps> getContainers()
        Description copied from interface: AbstractPodProps
        List of containers belonging to the pod.

        Containers cannot currently be added or removed. There must be at least one container in a Pod.

        You can add additionnal containers using podSpec.addContainer()

        Default: - No containers. Note that a pod spec must include at least one container.

        Specified by:
        getContainers in interface AbstractPodProps
      • getInitContainers

        public final List<ContainerProps> getInitContainers()
        Description copied from interface: AbstractPodProps
        List of initialization containers belonging to the pod.

        Init containers are executed in order prior to containers being started. If any init container fails, the pod is considered to have failed and is handled according to its restartPolicy. The name for an init container or normal container must be unique among all containers. Init containers may not have Lifecycle actions, Readiness probes, Liveness probes, or Startup probes. The resourceRequirements of an init container are taken into account during scheduling by finding the highest request/limit for each resource type, and then using the max of of that value or the sum of the normal containers. Limits are applied to init containers in a similar fashion.

        Init containers cannot currently be added ,removed or updated.

        Default: - No init containers.

        Specified by:
        getInitContainers in interface AbstractPodProps
        See Also:
        https://kubernetes.io/docs/concepts/workloads/pods/init-containers/
      • getIsolate

        public final Boolean getIsolate()
        Description copied from interface: AbstractPodProps
        Isolates the pod.

        This will prevent any ingress or egress connections to / from this pod. You can however allow explicit connections post instantiation by using the .connections property.

        Default: false

        Specified by:
        getIsolate in interface AbstractPodProps
      • getSecurityContext

        public final PodSecurityContextProps getSecurityContext()
        Description copied from interface: AbstractPodProps
        SecurityContext holds pod-level security attributes and common container settings.

        Default: fsGroupChangePolicy: FsGroupChangePolicy.FsGroupChangePolicy.ALWAYS ensureNonRoot: true

        Specified by:
        getSecurityContext in interface AbstractPodProps
      • getServiceAccount

        public final IServiceAccount getServiceAccount()
        Description copied from interface: AbstractPodProps
        A service account provides an identity for processes that run in a Pod.

        When you (a human) access the cluster (for example, using kubectl), you are authenticated by the apiserver as a particular User Account (currently this is usually admin, unless your cluster administrator has customized your cluster). Processes in containers inside pods can also contact the apiserver. When they do, they are authenticated as a particular Service Account (for example, default).

        Default: - No service account.

        Specified by:
        getServiceAccount in interface AbstractPodProps
        See Also:
        https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/
      • getMetadata

        public final org.cdk8s.ApiObjectMetadata getMetadata()
        Description copied from interface: ResourceProps
        Metadata that all persisted resources must have, which includes all objects users must create.
        Specified by:
        getMetadata in interface ResourceProps
      • $jsii$toJson

        @Internal
        public com.fasterxml.jackson.databind.JsonNode $jsii$toJson()
        Specified by:
        $jsii$toJson in interface software.amazon.jsii.JsiiSerializable
      • hashCode

        public final int hashCode()
        Overrides:
        hashCode in class Object