From 100a5be64c56dcc6e2775da3fea2ba873fe9d3a3 Mon Sep 17 00:00:00 2001 From: Aldo Culquicondor Date: Thu, 21 Jan 2021 17:01:08 -0500 Subject: [PATCH] Add KEP for job tracking in provisional status Signed-off-by: Aldo Culquicondor --- .../README.md | 578 ++++++++++++++++++ .../kep.yaml | 39 ++ 2 files changed, 617 insertions(+) create mode 100644 keps/sig-apps/2307-job-tracking-wihout-lingering-pods/README.md create mode 100644 keps/sig-apps/2307-job-tracking-wihout-lingering-pods/kep.yaml diff --git a/keps/sig-apps/2307-job-tracking-wihout-lingering-pods/README.md b/keps/sig-apps/2307-job-tracking-wihout-lingering-pods/README.md new file mode 100644 index 000000000000..0f2460a6c730 --- /dev/null +++ b/keps/sig-apps/2307-job-tracking-wihout-lingering-pods/README.md @@ -0,0 +1,578 @@ + +# KEP-2307: Job tracking without lingering Pods + + +- [Release Signoff Checklist](#release-signoff-checklist) +- [Summary](#summary) +- [Motivation](#motivation) + - [Goals](#goals) + - [Non-Goals](#non-goals) +- [Proposal](#proposal) + - [Notes/Constraints/Caveats (Optional)](#notesconstraintscaveats-optional) + - [Risks and Mitigations](#risks-and-mitigations) +- [Design Details](#design-details) + - [API changes](#api-changes) + - [Algorithm](#algorithm) + - [Test Plan](#test-plan) + - [Graduation Criteria](#graduation-criteria) + - [Upgrade / Downgrade Strategy](#upgrade--downgrade-strategy) + - [Version Skew Strategy](#version-skew-strategy) +- [Production Readiness Review Questionnaire](#production-readiness-review-questionnaire) + - [Feature Enablement and Rollback](#feature-enablement-and-rollback) + - [Rollout, Upgrade and Rollback Planning](#rollout-upgrade-and-rollback-planning) + - [Monitoring Requirements](#monitoring-requirements) + - [Dependencies](#dependencies) + - [Scalability](#scalability) + - [Troubleshooting](#troubleshooting) +- [Implementation History](#implementation-history) +- [Drawbacks](#drawbacks) +- [Alternatives](#alternatives) +- [Infrastructure Needed (Optional)](#infrastructure-needed-optional) + + +## Release Signoff Checklist + +Items marked with (R) are required *prior to targeting to a milestone / release*. + +- [x] (R) Enhancement issue in release milestone, which links to KEP dir in [kubernetes/enhancements] (not the initial KEP PR) +- [ ] (R) KEP approvers have approved the KEP status as `implementable` +- [x] (R) Design details are appropriately documented +- [x] (R) Test plan is in place, giving consideration to SIG Architecture and SIG Testing input +- [ ] (R) Graduation criteria is in place +- [x] (R) Production readiness review completed +- [x] (R) Production readiness review approved +- [ ] "Implementation History" section is up-to-date for milestone +- [ ] User-facing documentation has been created in [kubernetes/website], for publication to [kubernetes.io] +- [ ] Supporting documentation—e.g., additional design documents, links to mailing list discussions/SIG meetings, relevant PRs/issues, release notes + +[kubernetes.io]: https://kubernetes.io/ +[kubernetes/enhancements]: https://git.k8s.io/enhancements +[kubernetes/kubernetes]: https://git.k8s.io/kubernetes +[kubernetes/website]: https://git.k8s.io/website + +## Summary + +The current Job controller currently relies on completed Pods to not be removed +in order to track the Job completion status. This proposal presents an +alternative implementation for Job tracking that does not have this dependency. + +## Motivation + +The current approach of relying on the Pods existence is problematic for Jobs +that require a big number of completions or for clusters with too many Jobs +running at the same time. The finished Pods cannot be removed until the entire +Job completes, even if the Pods failed. + +Furthermore, once the number of finished Pods reaches a threshold, the Pod +garbage collection controller starts removing Pods. Today, the Job controller +relies on the garbage collector having a big threshold. + +### Goals + +- Perform Job completion and failures tracking without relying on lingering + Pods. + +### Non-Goals + +- Remove Pods once they have been accounted for. + +## Proposal + +The Job controller creates Pods with a finalizer to prevent finished Pods to be +removed by the garbage collection. The Job controller removes the finalizer from +the finished Pods once it has accounted for them. In subsequent Job syncs, the +controller ignores finished Pods that don't have a finalizer. + +### Notes/Constraints/Caveats (Optional) + +Due to the lack of support of atomic changes across kubernetes objects, an +intermediate state is necessary. Before removing the Pod finalizers, +the controller adds finished Pods to a list in the Job status. After removing +the Pod finalizers, the controller clears the list and updates the counters. + +### Risks and Mitigations + +1. The new implementation produces new API calls: one per Pod to remove + finalizers and one for each Job sync, to track the intermediate state. + However, the ability to handle higher number of Pods and Jobs at a given + point justifies the added cost of the new API calls. +2. Changes in the status not produced by the Job controller in + kube-controller-manager could affect the Job tracking. Cluster administrators + should make sure to protect the Job status endpoint via RBAC. + +## Design Details + +### API changes + +The Job status gets a new struct to hold the uncounted Pods before they are +added to the counters. + +```golang +type JobStatus struct { + Succeeded int32 + Failed int32 + ... + + // UncountedPodUIDs holds UIDs of Pods that have finished but haven't + // been accounted in the counters. + UncountedPodUIDs UncountedPodUIDs +} + +// UncountedPodUIDs holds UIDs of Pods that have finished but haven't been +// accounted in Job status counters. +type UncountedPodUIDs struct { + // Enabled indicates whether Job tracking uses this struct. + Enabled bool + // Succeeded holds UIDs of succeeded Pods. + Succeeded []string + // Succeeded holds UIDs of failed Pods. + Failed []string +} +``` + +### Algorithm + +The following algorithm updates the status counters without relying on finished +Pods to be present indefinitely. The algorithm assumes that the Job controller +could be stopped at any point and executed again from the first step without +losing information. Generally, all the steps happen in a single Job sync +cycle. + +1. The Job controller creates missing Pods with the finalizer + `batch.kubernetes.io/job-completion` +2. The Job controller adds Pod UIDs to the `.status.uncountedPodUIDs.succeeded` + and `.status.uncountedPodsUIDs.failed` lists if the Pod has the + `batch.kubernetes.io/job-completion` finalizer and the Pod is on Succeeded + or Failed phase, respectively. The controller sends a status update. +3. The Job controller removes the `batch.kubernetes.io/job-completion` finalizer + from all Pods on Succeeded or Failed phase. We can assume that all of them + have been added to the lists if the previous step succeeded. +4. The Job controller increments the `.status.failed` and `.status.succeeded` + counters with the lengths of the `.status.uncountedPodsUIDs` lists, clearing + them afterwards. The controller sends a status update. + +In the case where a user or another controller removes a Pod, which sets a +deletion timestamp, the Job controller removes the finalizer. This is along with +other Pods in step 3. Note that step 2 doesn't pay attention to deletion +timestamps. So deleted Pods will be accounted in the lists and counters if they +are in a Failed or Succeeded phase. + +<<[UNRESOLVED Pod adoption ]>> +If a Job with `.status.uncountedPodUIDs.enabled = true` can adopt a Pod, this +might not have a finalizer. We can: +1. Prevent adoption if the Pod doesn't have the finalizer. This is a breaking + change. +1. Add the finalizer in the same patch request that modifies the owner + reference. +<<[/UNRESOLVED]>> + +### Test Plan + + + +### Graduation Criteria + + + +### Upgrade / Downgrade Strategy + +When the feature `JobTrackingWithoutLingeringPods` is enabled for the first +time, the cluster can have Jobs whose Pods don't have the +`batch.kubernetes.io/job-completion` finalizer. It would be hard to add the +finalizer to all Pods while preventing race conditions. + +We use `.status.uncountedPodUIDs.enabled` to indicate whether the Job was +created after the feature was enabled. If this boolean is false, the Job +controller tracks Pods using the legacy algorithm. + +The kube-apiserver sets `.status.uncountedPodUIDs.enabled = true` when the +feature gate `JobTrackingWithoutLingeringPods` is enabled, at Job creation. + +When the feature is disabled after being enabled for some time, the next time +the Job controller syncs a Job: +1. It removes finalizers from all Pods owned by the Job. +2. Sets `.status.uncountedPodUIDs.enabled = false` + +### Version Skew Strategy + + + +## Production Readiness Review Questionnaire + + + +### Feature Enablement and Rollback + +_This section must be completed when targeting alpha to a release._ + +* **How can this feature be enabled / disabled in a live cluster?** + - [ ] Feature gate (also fill in values in `kep.yaml`) + - Feature gate name: + - Components depending on the feature gate: + - [ ] Other + - Describe the mechanism: + - Will enabling / disabling the feature require downtime of the control + plane? + - Will enabling / disabling the feature require downtime or reprovisioning + of a node? (Do not assume `Dynamic Kubelet Config` feature is enabled). + +* **Does enabling the feature change any default behavior?** + Any change of default behavior may be surprising to users or break existing + automations, so be extremely careful here. + +* **Can the feature be disabled once it has been enabled (i.e. can we roll back + the enablement)?** + Also set `disable-supported` to `true` or `false` in `kep.yaml`. + Describe the consequences on existing workloads (e.g., if this is a runtime + feature, can it break the existing applications?). + +* **What happens if we reenable the feature if it was previously rolled back?** + +* **Are there any tests for feature enablement/disablement?** + The e2e framework does not currently support enabling or disabling feature + gates. However, unit tests in each component dealing with managing data, created + with and without the feature, are necessary. At the very least, think about + conversion tests if API types are being modified. + +### Rollout, Upgrade and Rollback Planning + +_This section must be completed when targeting beta graduation to a release._ + +* **How can a rollout fail? Can it impact already running workloads?** + Try to be as paranoid as possible - e.g., what if some components will restart + mid-rollout? + +* **What specific metrics should inform a rollback?** + +* **Were upgrade and rollback tested? Was the upgrade->downgrade->upgrade path tested?** + Describe manual testing that was done and the outcomes. + Longer term, we may want to require automated upgrade/rollback tests, but we + are missing a bunch of machinery and tooling and can't do that now. + +* **Is the rollout accompanied by any deprecations and/or removals of features, APIs, +fields of API types, flags, etc.?** + Even if applying deprecation policies, they may still surprise some users. + +### Monitoring Requirements + +_This section must be completed when targeting beta graduation to a release._ + +* **How can an operator determine if the feature is in use by workloads?** + Ideally, this should be a metric. Operations against the Kubernetes API (e.g., + checking if there are objects with field X set) may be a last resort. Avoid + logs or events for this purpose. + +* **What are the SLIs (Service Level Indicators) an operator can use to determine +the health of the service?** + - [ ] Metrics + - Metric name: + - [Optional] Aggregation method: + - Components exposing the metric: + - [ ] Other (treat as last resort) + - Details: + +* **What are the reasonable SLOs (Service Level Objectives) for the above SLIs?** + At a high level, this usually will be in the form of "high percentile of SLI + per day <= X". It's impossible to provide comprehensive guidance, but at the very + high level (needs more precise definitions) those may be things like: + - per-day percentage of API calls finishing with 5XX errors <= 1% + - 99% percentile over day of absolute value from (job creation time minus expected + job creation time) for cron job <= 10% + - 99,9% of /health requests per day finish with 200 code + +* **Are there any missing metrics that would be useful to have to improve observability +of this feature?** + Describe the metrics themselves and the reasons why they weren't added (e.g., cost, + implementation difficulties, etc.). + +### Dependencies + +_This section must be completed when targeting beta graduation to a release._ + +* **Does this feature depend on any specific services running in the cluster?** + Think about both cluster-level services (e.g. metrics-server) as well + as node-level agents (e.g. specific version of CRI). Focus on external or + optional services that are needed. For example, if this feature depends on + a cloud provider API, or upon an external software-defined storage or network + control plane. + + For each of these, fill in the following—thinking about running existing user workloads + and creating new ones, as well as about cluster-level services (e.g. DNS): + - [Dependency name] + - Usage description: + - Impact of its outage on the feature: + - Impact of its degraded performance or high-error rates on the feature: + + +### Scalability + +_For alpha, this section is encouraged: reviewers should consider these questions +and attempt to answer them._ + +_For beta, this section is required: reviewers must answer these questions._ + +_For GA, this section is required: approvers should be able to confirm the +previous answers based on experience in the field._ + +* **Will enabling / using this feature result in any new API calls?** + Describe them, providing: + - API call type (e.g. PATCH pods) + - estimated throughput + - originating component(s) (e.g. Kubelet, Feature-X-controller) + focusing mostly on: + - components listing and/or watching resources they didn't before + - API calls that may be triggered by changes of some Kubernetes resources + (e.g. update of object X triggers new updates of object Y) + - periodic API calls to reconcile state (e.g. periodic fetching state, + heartbeats, leader election, etc.) + +* **Will enabling / using this feature result in introducing new API types?** + Describe them, providing: + - API type + - Supported number of objects per cluster + - Supported number of objects per namespace (for namespace-scoped objects) + +* **Will enabling / using this feature result in any new calls to the cloud +provider?** + +* **Will enabling / using this feature result in increasing size or count of +the existing API objects?** + Describe them, providing: + - API type(s): + - Estimated increase in size: (e.g., new annotation of size 32B) + - Estimated amount of new objects: (e.g., new Object X for every existing Pod) + +* **Will enabling / using this feature result in increasing time taken by any +operations covered by [existing SLIs/SLOs]?** + Think about adding additional work or introducing new steps in between + (e.g. need to do X to start a container), etc. Please describe the details. + +* **Will enabling / using this feature result in non-negligible increase of +resource usage (CPU, RAM, disk, IO, ...) in any components?** + Things to keep in mind include: additional in-memory state, additional + non-trivial computations, excessive access to disks (including increased log + volume), significant amount of data sent and/or received over network, etc. + This through this both in small and large cases, again with respect to the + [supported limits]. + +### Troubleshooting + +The Troubleshooting section currently serves the `Playbook` role. We may consider +splitting it into a dedicated `Playbook` document (potentially with some monitoring +details). For now, we leave it here. + +_This section must be completed when targeting beta graduation to a release._ + +* **How does this feature react if the API server and/or etcd is unavailable?** + +* **What are other known failure modes?** + For each of them, fill in the following information by copying the below template: + - [Failure mode brief description] + - Detection: How can it be detected via metrics? Stated another way: + how can an operator troubleshoot without logging into a master or worker node? + - Mitigations: What can be done to stop the bleeding, especially for already + running user workloads? + - Diagnostics: What are the useful log messages and their required logging + levels that could help debug the issue? + Not required until feature graduated to beta. + - Testing: Are there any tests for failure mode? If not, describe why. + +* **What steps should be taken if SLOs are not being met to determine the problem?** + +[supported limits]: https://git.k8s.io/community//sig-scalability/configs-and-limits/thresholds.md +[existing SLIs/SLOs]: https://git.k8s.io/community/sig-scalability/slos/slos.md#kubernetes-slisslos + +## Implementation History + + + +## Drawbacks + + + +## Alternatives + + + +## Infrastructure Needed (Optional) + + diff --git a/keps/sig-apps/2307-job-tracking-wihout-lingering-pods/kep.yaml b/keps/sig-apps/2307-job-tracking-wihout-lingering-pods/kep.yaml new file mode 100644 index 000000000000..0b469f2ca130 --- /dev/null +++ b/keps/sig-apps/2307-job-tracking-wihout-lingering-pods/kep.yaml @@ -0,0 +1,39 @@ +title: Job tracking without lingering Pods +kep-number: 2307 +authors: + - "@alculquicondor" +owning-sig: sig-apps +status: provisional +creation-date: 2020-01-21 +reviewers: + - "@erictune" + - "@lavalamp" +approvers: + - "@janetkuo" + +# The target maturity stage in the current dev cycle for this KEP. +stage: alpha + +# The most recent milestone for which work toward delivery of this KEP has been +# done. This can be the current (upcoming) milestone, if it is being actively +# worked on. +latest-milestone: "v1.21" + +# The milestone at which this feature was, or is targeted to be, at each stage. +milestone: + alpha: "v1.21" + beta: "v1.22" + stable: "v1.24" + +# The following PRR answers are required at alpha release +# List the feature gate name and the components for which it must be enabled +feature-gates: + - name: JobTrackingWithoutLingeringPods + components: + - kube-apiserver + - kube-controller-manager +disable-supported: true + +# The following PRR answers are required at beta release +metrics: + - TBD