reflect reviews
This commit is contained in:
@@ -62,14 +62,14 @@ v1.20 이상에서, 가비지 수집기가 잘못된 교차 네임스페이스 `
|
||||
이 과정을 `캐스케이딩 삭제`라고 한다.
|
||||
캐스케이딩 삭제에는 다음과 같은 두 가지 종류가 있다.
|
||||
|
||||
* 포어그라운드 캐스케이딩 삭제(Foreground cascading deletion)
|
||||
* 포그라운드 캐스케이딩 삭제(Foreground cascading deletion)
|
||||
* 백그라운드 캐스케이딩 삭제(Background cascading deletion)
|
||||
|
||||
또한 쿠버네티스의 {{<glossary_tooltip text="finalizers" term_id="finalizer">}}를 사용하여 가비지 수집이 소유자 참조가 있는 자원을 언제 어떻게 삭제할 것인지 제어할 수 있다.
|
||||
|
||||
### 포어그라운드 캐스케이딩 삭제 {#foreground-deletion}
|
||||
### 포그라운드 캐스케이딩 삭제 {#foreground-deletion}
|
||||
|
||||
포어그라운드 캐스케이딩 삭제에서는 삭제하려는 소유자 오브젝트가 먼저
|
||||
포그라운드 캐스케이딩 삭제에서는 삭제하려는 소유자 오브젝트가 먼저
|
||||
*삭제 중* 상태가 된다. 이 상태에서는 소유자 오브젝트에게 다음과 같은 일이
|
||||
일어난다:
|
||||
|
||||
@@ -83,7 +83,7 @@ v1.20 이상에서, 가비지 수집기가 잘못된 교차 네임스페이스 `
|
||||
모든 종속 오브젝트들이 삭제되고나면, 컨트롤러가 소유자 오브젝트를 삭제한다.
|
||||
이 시점에서 오브젝트는 더 이상 쿠버네티스 API를 통해 조회할 수 없다.
|
||||
|
||||
포어그라운드 캐스케이딩 삭제 중에 소유자 오브젝트의 삭제를 막는
|
||||
포그라운드 캐스케이딩 삭제 중에 소유자 오브젝트의 삭제를 막는
|
||||
종속 오브젝트는`ownerReference.blockOwnerDeletion=true`필드를 가진 오브젝트다.
|
||||
더 자세한 내용은 [Use foreground cascading deletion](/docs/tasks/administer-cluster/use-cascading-deletion/#use-foreground-cascading-deletion)를
|
||||
참고한다.
|
||||
@@ -92,7 +92,7 @@ v1.20 이상에서, 가비지 수집기가 잘못된 교차 네임스페이스 `
|
||||
|
||||
백그라운드 캐스케이딩 삭제에서는 쿠버네티스 API 서버가 소유자 오브젝트를 즉시 삭제하고
|
||||
백그라운드에서 컨트롤러가 종속 오브젝트들을 삭제한다.
|
||||
쿠버네티스는 수동으로 포어그라운드 삭제를 사용하거나 종속 오브젝트를 분리하지 않는다면, 기본적으로 백그라운드 캐스케이딩 삭제를 사용한다.
|
||||
쿠버네티스는 수동으로 포그라운드 삭제를 사용하거나 종속 오브젝트를 분리하지 않는다면, 기본적으로 백그라운드 캐스케이딩 삭제를 사용한다.
|
||||
|
||||
더 자세한 내용은 [Use background cascading deletion](/docs/tasks/administer-cluster/use-cascading-deletion/#use-background-cascading-deletion)를
|
||||
참고한다.
|
||||
@@ -118,7 +118,7 @@ v1.20 이상에서, 가비지 수집기가 잘못된 교차 네임스페이스 `
|
||||
|
||||
### 컨테이너 이미지 라이프사이클
|
||||
|
||||
쿠버네티스는 Kubelet의 일부인 *이미지 관리자*가 cadvisor와 협동하여
|
||||
쿠버네티스는 Kubelet의 일부인 *이미지 관리자*가 {{< glossary_tooltip text="cadvisor" term_id="cadvisor" >}}와 협동하여
|
||||
모든 이미지의 라이프사이클을 관리한다.
|
||||
Kubelet은 가비지 수집 결정을 내릴 때, 다음 디스크 사용량 제한을 고려한다.
|
||||
|
||||
@@ -148,7 +148,7 @@ Kubelet은 사용자가 정의할 수 있는 다음 변수들을 기반으로
|
||||
서로 충돌이 발생할 수 있다.
|
||||
이 상황에서 Kubelet은 충돌을 해결하기 위해 `MaxPodPerContainer`를 조절한다.
|
||||
최악의 시나리오에서는 `MaxPerPodContainer`를 `1`로 다운그레이드하고
|
||||
가장 오래된 컨테이너들을 쫓아낸다.
|
||||
가장 오래된 컨테이너들을 축출한다.
|
||||
또한, 삭제된 파드가 소유한 컨테이너들은 `MinAge`보다 오래되었을 때 삭제된다.
|
||||
|
||||
{{<note>}}
|
||||
|
||||
@@ -70,7 +70,7 @@ _모든_ 파드가 가용한 경우가 아닌 경우 멈추고 싶다면(아마
|
||||
|
||||
다음은 쿠버네티스가 애플리케이션의 파드를 어떻게 관리하는지를 알 수 있게 해주는
|
||||
두 가지 개념이다.
|
||||
* [가비지(Garbage) 수집](/ko/docs/concepts/workloads/controllers/garbage-collection/)은 _소유하는 리소스_ 가
|
||||
* [가비지(Garbage) 수집](/ko/docs/concepts/architecture/garbage-collection/)은 _소유하는 리소스_ 가
|
||||
제거된 후 클러스터에서 오브젝트를 정리한다.
|
||||
* [_time-to-live after finished_ 컨트롤러](/ko/docs/concepts/workloads/controllers/ttlafterfinished/)는
|
||||
잡이 완료된 이후에 정의된 시간이 경과되면 잡을 제거한다.
|
||||
|
||||
@@ -26,7 +26,7 @@ weight: 20
|
||||
레플리카셋이 새로운 파드를 생성해야 할 경우, 명시된 파드 템플릿을
|
||||
사용한다.
|
||||
|
||||
레플리카셋은 파드의 [metadata.ownerReferences](/ko/docs/concepts/workloads/controllers/garbage-collection/#소유자-owner-와-종속-dependent)
|
||||
레플리카셋은 파드의 [metadata.ownerReferences](/ko/docs/concepts/architecture/garbage-collection/#소유자-owner-와-종속-dependent)
|
||||
필드를 통해 파드에 연결되며, 이는 현재 오브젝트가 소유한 리소스를 명시한다.
|
||||
레플리카셋이 가지고 있는 모든 파드의 ownerReferences 필드는 해당 파드를 소유한 레플리카셋을 식별하기 위한 소유자 정보를 가진다.
|
||||
이 링크를 통해 레플리카셋은 자신이 유지하는 파드의 상태를 확인하고 이에 따라 관리 한다.
|
||||
@@ -269,7 +269,7 @@ matchLabels:
|
||||
|
||||
### 레플리카셋과 해당 파드 삭제
|
||||
|
||||
레플리카셋 및 모든 파드를 삭제하려면 [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete)를 사용한다. [가비지 수집기](/ko/docs/concepts/workloads/controllers/garbage-collection/)는 기본적으로 종속되어 있는 모든 파드를 자동으로 삭제한다.
|
||||
레플리카셋 및 모든 파드를 삭제하려면 [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete)를 사용한다. [가비지 수집기](/ko/docs/concepts/architecture/garbage-collection/)는 기본적으로 종속되어 있는 모든 파드를 자동으로 삭제한다.
|
||||
|
||||
REST API또는 `client-go` 라이브러리를 이용할 때는 -d 옵션으로 `propagationPolicy`를 `Background`또는 `Foreground`로
|
||||
설정해야 한다.
|
||||
|
||||
@@ -15,7 +15,7 @@ tags:
|
||||
|
||||
<!--more-->
|
||||
|
||||
쿠버네티스는 [사용되지 않는 컨테이너와 이미지](/ko/docs/concepts/workloads/controllers/garbage-collection/#containers-images),
|
||||
쿠버네티스는 [사용되지 않는 컨테이너와 이미지](/ko/docs/concepts/architecture/garbage-collection/#containers-images),
|
||||
[실패한 파드](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection),
|
||||
[타겟 리소스가 소유한 오브젝트](/docs/concepts/overview/working-with-objects/owners-dependents/),
|
||||
[종료된 잡](/ko/docs/concepts/workloads/controllers/ttlafterfinished/), 그리고
|
||||
|
||||
@@ -127,7 +127,7 @@ kubectl delete cronjob hello
|
||||
```
|
||||
|
||||
크론 잡을 삭제하면 생성된 모든 잡과 파드가 제거되고 추가 잡 생성이 중지된다.
|
||||
[가비지(garbage) 수집](/ko/docs/concepts/workloads/controllers/garbage-collection/)에서 잡 제거에 대해 상세한 내용을 읽을 수 있다.
|
||||
[가비지(garbage) 수집](/ko/docs/concepts/architecture/garbage-collection/)에서 잡 제거에 대해 상세한 내용을 읽을 수 있다.
|
||||
|
||||
## 크론 잡 명세 작성
|
||||
|
||||
|
||||
Reference in New Issue
Block a user