앱(장기 실행 프로세스)과 달리 태스크는 일정 시간 동안 실행된 후 중단됩니다. 태스크는 상위 앱의 구성에 따라 자체 컨테이너에서 실행되며 제한된 리소스(예: CPU/메모리/이페머럴 디스크 스토리지)를 사용하도록 구성할 수 있습니다.
태스크 사용 사례
데이터베이스 마이그레이션
일괄 작업(예약됨/예약되지 않음) 실행
이메일 보내기
데이터 변환(ETL)
데이터 처리(업로드/백업/다운로드)
태스크 작동 방식
태스크는 비동기식으로 실행되며 상위 앱 또는 동일한 앱에서 실행되는 다른 태스크와 독립적으로 실행됩니다. 태스크를 실행하기 위해 만든 앱에는 생성되거나 할당된 경로가 없으며 실행 수명 주기를 건너뜁니다. 소스 코드 업로드 및 빌드 수명 주기는 계속 작동하며 앱을 푸시한 후 태스크를 실행하는 데 사용되는 컨테이너 이미지에 결과가 나타납니다(애플리케이션 배포 시 앱 수명 주기 참조).
태스크의 수명 주기는 다음과 같습니다.
kf push APP_NAME --task 명령어를 사용하여 태스크를 실행하기 위해 앱을 푸시합니다.
kf run-task APP_NAME 명령어를 사용하여 앱에서 태스크를 실행합니다. 태스크는 앱에 결합된 환경 변수, 서비스 결합, 리소스 할당, 시작 명령어, 보안 그룹을 상속합니다.
Kf는 앱의 값과 run-task 명령어의 매개변수를 사용하여 Tekton PipelineRun을 만듭니다.
Tekton PipelineRun은 앱과 태스크의 구성을 기반으로 컨테이너를 시작하는 Kubernetes Pod를 만듭니다.
태스크 실행이 중지되고(태스크 종료 또는 수동 종료) 기본 Pod가 중지되거나 종료됩니다. 중지된 태스크의 Pod가 보존되므로 kf logs APP_NAME --task 명령어를 통해 태스크 로그에 액세스할 수 있습니다.
태스크가 중지하기 전에 종료하면 Tekton PipelineRun이 취소되며(PipelineRun 취소 참조) 로그와 함께 기본 Pod가 삭제됩니다. 종료된 태스크의 로그는 구성된 경우 클러스터 수준 로깅 스트림으로 전달됩니다(예: Stackdriver, Fluentd).
앱에서 실행되는 태스크 수가 500개를 초과하면 오래된 태스크가 자동으로 삭제됩니다.
태스크 보관 정책
태스크는 Kubernetes 클러스터에서 커스텀 리소스로 생성되므로 기본 etcd 데이터베이스의 공간을 소진하지 않는 것이 중요합니다. 기본적으로 Kf는 각 앱마다 최신 500개의 태스크만 유지합니다. 태스크 수가 500개에 도달하면 가장 오래된 태스크(기본 Pod 및 로그 포함)가 자동으로 삭제됩니다.
태스크 로깅 및 실행 기록
STDOUT 또는 STDERR에 태스크가 출력하는 모든 데이터 또는 메시지는 kf logs APP_NAME --task 명령어를 사용하여 사용할 수 있습니다. 클러스터 수준 로깅 메커니즘(예: Stackdriver, Fluentd)은 구성된 로깅 대상에 태스크 로그를 제공합니다.
태스크 예약
위에서 설명한 것처럼 kf run-task APP_NAME 명령어를 사용하면 태스크를 비동기적으로 실행할 수 있습니다.
또는 먼저 kf create-job 명령어를 사용하여 작업을 만든 후 kf schedule-job JOB_NAME 명령어로 예약하여 실행할 태스크를 예약할 수 있습니다. 지정된 unix-cron 일정에 따라 태스크가 자동으로 실행되도록 작업을 예약할 수 있습니다.
태스크 예약 방법
태스크를 실행할 작업을 만들고 예약합니다. 작업은 실행할 태스크를 설명하고 태스크 생성을 자동으로 관리합니다.
이전에 실행한 태스크가 여전히 실행 중이더라도 일정에 따라 태스크가 생성됩니다.
어떤 이유로든 실행이 누락될 경우 시스템이 복구되면 가장 최근에 누락된 실행만 실행됩니다.
작업을 삭제하면 연결된 모든 태스크가 삭제됩니다. 연결된 태스크가 아직 진행 중이라면 완료될 때까지 실행되지 않고 강제로 삭제됩니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-04(UTC)"],[],[],null,["# Tasks overview\n\nAbout Tasks\n-----------\n\nIn contrast to Apps (long-running processes), Tasks run for a finite amount of time and then stops. Tasks run in their own containers based on configuration on the parent App, and it could be configured to use limited resources (e.g. CPU/memory/ephermeral disk storage).\n\nUse cases for Tasks\n-------------------\n\n- Migrating a database\n- Running a batch job (scheduled/unscheduled)\n- Sending an email\n- Transforming data (ETL)\n- Processing data (upload/backup/download)\n\nHow Tasks work\n--------------\n\nTasks are executed asynchronously and run independently from the parent App or other Tasks running on the same App. An App created for running Tasks does not have routes created or assigned, and the **Run** lifecycle is skipped. The **Source code upload** and **Build** lifecycles still proceed and result in a container image used for running Tasks after pushing the App (see App lifecycles at [Deploying an Application](../how-to/deploying-an-app)).\n\nThe lifecycle of a Task is as follows:\n\n1. You push an App for running tasks with the `kf push APP_NAME --task` command.\n2. You run a Task on the App with the `kf run-task APP_NAME` command. Task inherits the environment variables, service bindings, resource allocation, start-up command, and security groups bound to the App.\n3. Kf creates a Tekton [PipelineRun](https://github.com/tektoncd/pipeline/blob/master/docs/pipelineruns.md) with values from the App and parameters from the `run-task` command.\n4. The Tekton PipelineRun creates a Kubernetes Pod which launches a container based on the configurations on the App and Task.\n5. Task execution stops (Task exits or is terminated manually), the underlying Pod is either stopped or terminated. Pods of stopped Tasks are preserved and thus Task logs are accessible via the `kf logs APP_NAME --task` command.\n6. If you terminate a Task before it stops, the Tekton PipelineRun is cancelled (see [Cancelling a PipelineRun](https://github.com/tektoncd/pipeline/blob/master/docs/pipelineruns.md#cancelling-a-pipelinerun)), the underlying Pod together with the logs are deleted. The logs of termianted Tasks are delivered to the cluster level logging streams if configured (e.g. Stackdriver, Fluentd).\n7. If the number of Tasks run on an App is greater than 500, the oldest Tasks are automatically deleted.\n\nTasks retention policy\n----------------------\n\nTasks are created as custom resources in the Kubernetes cluster, therefore, it is important not to exhaust the space of the underlying `etcd` database. By default, Kf only keeps the latest 500 Tasks per each App. Once the number of Tasks reach 500, the oldest Tasks (together with the underlying Pods and logs) will be automatically deleted.\n\nTask logging and execution history\n----------------------------------\n\nAny data or messages the Task outputs to STDOUT or STDERR is available by using the `kf logs APP_NAME --task` command. Cluster level logging mechanism (such as Stackdriver, Fluentd) will deliver the Task logs to the configured logging destination.\n\nScheduling Tasks\n----------------\n\nAs described above, Tasks can be run asynchronously by using the `kf run-task APP_NAME` command.\nAlternatively, you can schedule Tasks for execution by first creating a Job using\nthe `kf create-job` command, and then scheduling it with the\n`kf schedule-job JOB_NAME` command. You can schedule that Job to automatically\nrun Tasks on a specified [unix-cron](https://man7.org/linux/man-pages/man5/crontab.5.html) schedule.\n\n### How Tasks are scheduled\n\nCreate and schedule a Job to run the Task. A Job describes the Task to execute\nand automatically manages Task creation.\n\nTasks are created on the schedule even if previous executions of the Task are still running.\nIf any executions are missed for any reason, only the most recently missed execution\nare executed when the system recovers.\n\nDeleting a Job deletes all associated Tasks. If any associated Tasks were still\nin progress, they are forcefully deleted without running to completion.\n\nTasks created by a scheduled Job are still subject to the\n[Task retention policy](#tasks_retention_policy).\n\n### Differences from PCF Scheduler\n\nPCF Scheduler allows multiple schedules for a single Job while Kf\nonly supports a single schedule per Job. You can replicate the PCF Scheduler\nbehavior by creating multiple Jobs, one for each schedule."]]
