From 838b81120c121ad98417a8436bcc5b8d0e3be55c Mon Sep 17 00:00:00 2001 From: CaoShuFeng Date: Tue, 13 Mar 2018 09:39:09 +0800 Subject: [PATCH] remove description about "scale jobs" (#7712) --- .../concepts/workloads/controllers/jobs-run-to-completion.md | 3 +-- docs/tasks/job/parallel-processing-expansion.md | 5 ----- 2 files changed, 1 insertion(+), 7 deletions(-) diff --git a/docs/concepts/workloads/controllers/jobs-run-to-completion.md b/docs/concepts/workloads/controllers/jobs-run-to-completion.md index b582e0e6fb..b6086c91c7 100644 --- a/docs/concepts/workloads/controllers/jobs-run-to-completion.md +++ b/docs/concepts/workloads/controllers/jobs-run-to-completion.md @@ -257,8 +257,7 @@ The tradeoffs are: - One Job object for each work item, vs. a single Job object for all work items. The latter is better for large numbers of work items. The former creates some overhead for the user and for the - system to manage large numbers of Job objects. Also, with the latter, the resource usage of the job - (number of concurrently running pods) can be easily adjusted using the `kubectl scale` command. + system to manage large numbers of Job objects. - Number of pods created equals number of work items, vs. each pod can process multiple work items. The former typically requires less modification to existing code and containers. The latter is better for large numbers of work items, for similar reasons to the previous bullet. diff --git a/docs/tasks/job/parallel-processing-expansion.md b/docs/tasks/job/parallel-processing-expansion.md index 2d4199a217..639867a7ba 100644 --- a/docs/tasks/job/parallel-processing-expansion.md +++ b/docs/tasks/job/parallel-processing-expansion.md @@ -184,11 +184,6 @@ If you have a large number of job objects, you may find that: - Even using labels, managing so many Job objects is cumbersome. - You exceed resource quota when creating all the Jobs at once, and do not want to wait to create them incrementally. -- You need a way to easily scale the number of pods running - concurrently. One reason would be to avoid using too many - compute resources. Another would be to limit the number of - concurrent requests to a shared resource, such as a database, - used by all the pods in the job. - Very large numbers of jobs created at once overload the Kubernetes apiserver, controller, or scheduler.