whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

[ko] Remove deprecated 'kubelet-garbage-collection' page

Browse Source
This commit is contained in:
Jihoon Seo
2022-03-25 10:04:27 +09:00
parent 7e2afa9bbf
commit 80fe41b86d
3 changed files with 1 additions and 306 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/ko/docs/concepts/cluster-administration/kubelet-garbage-collection.md
-109
View File
@@ -1,109 +0,0 @@
---
title: kubelet 가비지(Garbage) 수집 설정하기
content_type: concept
weight: 70
---
<!-- overview -->
{{< note >}}
이 한글 문서는 더 이상 관리되지 않습니다.
이 문서의 기반이 된 영어 원문은 삭제되었으며,
[Garbage Collection](/docs/concepts/architecture/garbage-collection/)에 병합되었습니다.
[Garbage Collection](/docs/concepts/architecture/garbage-collection/)의 한글화가 완료되면,
이 문서는 삭제될 수 있습니다.
{{< /note >}}
가비지 수집은 사용되지 않는
[이미지](/ko/docs/concepts/containers/#컨테이너-이미지)들과
[컨테이너](/ko/docs/concepts/containers/)들을 정리하는 kubelet의 유용한 기능이다. Kubelet은
1분마다 컨테이너들에 대하여 가비지 수집을 수행하며, 5분마다 이미지들에 대하여 가비지 수집을 수행한다.
별도의 가비지 수집 도구들을 사용하는 것은, 이러한 도구들이 존재할 수도 있는 컨테이너들을 제거함으로써
kubelet을 중단시킬 수도 있으므로 권장하지 않는다.
<!-- body -->
## 이미지 수집
쿠버네티스는 cadvisor와 imageManager를 통하여 모든 이미지들의
라이프사이클을 관리한다.
이미지들에 대한 가비지 수집 정책은 다음의 2가지 요소를 고려한다.
`HighThresholdPercent` 와 `LowThresholdPercent`. 임계값을 초과하는
디스크 사용량은 가비지 수집을 트리거 한다. 가비지 수집은 낮은 입계값에 도달 할 때까지 최근에 가장 적게 사용한
이미지들을 삭제한다.
## 컨테이너 수집
컨테이너에 대한 가비지 수집 정책은 세 가지 사용자 정의 변수들을 고려한다.
`MinAge` 는 컨테이너를 가비지 수집할 수 있는 최소 연령이다.
`MaxPerPodContainer` 는 모든 단일 파드(UID, 컨테이너 이름)
쌍이 가질 수 있는 최대 비활성 컨테이너의 수량이다.
`MaxContainers` 는 죽은 컨테이너의 최대 수량이다.
이러한 변수는 `MinAge` 를 0으로 설정하고,
`MaxPerPodContainer` 와 `MaxContainers` 를 각각 0 보다 작게 설정해서 비활성화할 수 있다.
Kubelet은 미확인, 삭제 또는 앞에서 언급한
플래그가 설정한 경계를 벗어나거나, 확인되지 않은 컨테이너에 대해 조치를 취한다.
일반적으로 가장 오래된 컨테이너가 먼저 제거된다. `MaxPerPodContainer` 와 `MaxContainer` 는
파드 당 최대
컨테이너 수(`MaxPerPodContainer`)가 허용 가능한 범위의
전체 죽은 컨테이너의 수(`MaxContainers`)를 벗어나는 상황에서 잠재적으로 서로 충돌할 수 있다.
다음의 상황에서 `MaxPerPodContainer` 가 조정된다.
최악의 시나리오는 `MaxPerPodContainer` 를 1로 다운그레이드하고
가장 오래된 컨테이너를 제거하는 것이다. 추가로, 삭제된 파드가 소유한 컨테이너는
`MinAge` 보다 오래되면 제거된다.
kubelet이 관리하지 않는 컨테이너는 컨테이너 가비지 수집 대상이 아니다.
## 사용자 설정
여러분은 후술될 kubelet 플래그들을 통하여 이미지 가비지 수집을 조정하기 위하여 다음의 임계값을 조정할 수 있다.
1. `image-gc-high-threshold`, 이미지 가비지 수집을 발생시키는 디스크 사용량의 비율로
기본값은 85% 이다.
2. `image-gc-low-threshold`, 이미지 가비지 수집을 더 이상 시도하지 않는 디스크 사용량의 비율로
기본값은 80% 이다.
다음의 kubelet 플래그를 통해 가비지 수집 정책을 사용자 정의할 수 있다.
1. `minimum-container-ttl-duration`, 종료된 컨테이너가 가비지 수집
되기 전의 최소 시간. 기본 값은 0 분이며, 이 경우 모든 종료된 컨테이너는 바로 가비지 수집의 대상이 된다.
2. `maximum-dead-containers-per-container`, 컨테이너가 보유할 수 있는 오래된
인스턴스의 최대 수. 기본 값은 1 이다.
3. `maximum-dead-containers`, 글로벌하게 보유 할 컨테이너의 최대 오래된 인스턴스의 최대 수.
기본 값은 -1이며, 이 경우 인스턴스 수의 제한은 없다.
컨테이너들은 유용성이 만료되기 이전에도 가비지 수집이 될 수 있다. 이러한 컨테이너들은
문제 해결에 도움이 될 수 있는 로그나 다른 데이터를 포함하고 있을 수 있다. 컨테이너 당 적어도
1개의 죽은 컨테이너가 허용될 수 있도록 `maximum-dead-containers-per-container`
값을 충분히 큰 값으로 지정하는 것을 권장한다. 동일한 이유로 `maximum-dead-containers`
의 값도 상대적으로 더 큰 값을 권장한다.
자세한 내용은 [해당 이슈](https://github.com/kubernetes/kubernetes/issues/13287)를 참고한다.
## 사용 중단(Deprecation)
문서에 있는 몇 가지 kubelet의 가비지 수집 특징은 향후에 kubelet 축출(eviction) 기능으로 대체될 예정이다.
포함:
| 기존 Flag | 신규 Flag | 근거 |
| ------------- | -------- | --------- |
| `--image-gc-high-threshold` | `--eviction-hard` or `--eviction-soft` | 기존의 축출 신호로 인하여 이미지 가비지 수집이 트리거 될 수 있음 |
| `--image-gc-low-threshold` | `--eviction-minimum-reclaim` | 축출 리클레임 기능이 동일한 행동을 수행 |
| `--maximum-dead-containers` | | 컨테이너의 외부 영역에 오래된 로그가 저장되어 사용중단(deprecated)됨 |
| `--maximum-dead-containers-per-container` | | 컨테이너의 외부 영역에 오래된 로그가 저장되어 사용중단(deprecated)됨 |
| `--minimum-container-ttl-duration` | | 컨테이너의 외부 영역에 오래된 로그가 저장되어 사용중단(deprecated)됨 |
| `--low-diskspace-threshold-mb` | `--eviction-hard` or `eviction-soft` | 축출이 다른 리소스에 대한 디스크 임계값을 일반화 함 |
| `--outofdisk-transition-frequency` | `--eviction-pressure-transition-period` | 축출이 다른 리소스로의 디스크 압력전환을 일반화 함 |
## {{% heading "whatsnext" %}}
자세한 내용은 [리소스 부족 처리 구성](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/)를
본다.
content/ko/docs/concepts/scheduling-eviction/node-pressure-eviction.md
+1 -1
View File
@@ -87,7 +87,7 @@ Kubelet은 다른 구성은 지원하지 않는다.
{{<note>}}
일부 kubelet 가비지 수집 기능은 더 이상 사용되지 않으며 축출로 대체되었다.
사용 중지된 기능의 목록은 [kubelet 가비지 수집 사용 중단](/ko/docs/concepts/cluster-administration/kubelet-garbage-collection/#사용-중단-deprecation)을 참조한다.
사용 중지된 기능의 목록은 [kubelet 가비지 수집 사용 중단](/ko/docs/concepts/architecture/garbage-collection/#containers-images)을 참조한다.
{{</note>}}
### 축출 임계값
content/ko/docs/concepts/workloads/controllers/garbage-collection.md
-196
View File
@@ -1,196 +0,0 @@
---
title: 가비지(Garbage) 수집
content_type: concept
weight: 60
---
<!-- overview -->
{{< note >}}
이 한글 문서는 더 이상 관리되지 않습니다.
이 문서의 기반이 된 영어 원문은 삭제되었으며,
[Garbage Collection](/docs/concepts/architecture/garbage-collection/)에 병합되었습니다.
[Garbage Collection](/docs/concepts/architecture/garbage-collection/)의 한글화가 완료되면,
이 문서는 삭제될 수 있습니다.
{{< /note >}}
쿠버네티스의 가비지 수집기는 한때 소유자가 있었지만, 더 이상
소유자가 없는 오브젝트들을 삭제하는 역할을 한다.
<!-- body -->
## 소유자(owner)와 종속(dependent)
일부 쿠버네티스 오브젝트는 다른 오브젝트의 소유자이다. 예를 들어 레플리카셋은
파드 집합의 소유자이다. 소유자 오브젝트에게 소유된 오브젝트를 *종속*
이라고 한다. 모든 종속 오브젝트는 소유하는 오브젝트를 가르키는 `metadata.ownerReferences`
필드를 가지고 있다.
때때로, 쿠버네티스는 `ownerReference` 값을 자동적으로 설정한다.
예를 들어 레플리카셋을 만들 때 쿠버네티스는 레플리카셋에 있는 각 파드의
`ownerReference` 필드를 자동으로 설정한다. 1.8 에서는 쿠버네티스가
레플리케이션컨트롤러, 레플리카셋, 스테이트풀셋, 데몬셋, 디플로이먼트, 잡
그리고 크론잡에 의해서 생성되거나 차용된 오브젝트의 `ownerReference` 값을
자동으로 설정한다.
또한 `ownerReference` 필드를 수동으로 설정해서 소유자와 종속 항목 간의
관계를 지정할 수도 있다.
여기에 파드 3개가 있는 레플리카셋의 구성 파일이 있다.
{{< codenew file="controllers/replicaset.yaml" >}}
레플리카셋을 생성하고 파드의 메타데이터를 본다면,
OwnerReferences 필드를 찾을 수 있다.
```shell
kubectl apply -f https://k8s.io/examples/controllers/replicaset.yaml
kubectl get pods --output=yaml
```
출력 결과는 파드의 소유자가 `my-repset` 이라는 이름의 레플리카셋인 것을 보여준다.
```yaml
apiVersion: v1
kind: Pod
metadata:
...
ownerReferences:
- apiVersion: apps/v1
controller: true
blockOwnerDeletion: true
kind: ReplicaSet
name: my-repset
uid: d9607e19-f88f-11e6-a518-42010a800195
...
```
{{< note >}}
교차 네임스페이스(cross-namespace)의 소유자 참조는 디자인상 허용되지 않는다.
네임스페이스 종속 항목은 클러스터 범위 또는 네임스페이스 소유자를 지정할 수 있다.
네임스페이스 소유자는 **반드시** 종속 항목과 동일한 네임스페이스에 있어야 한다.
그렇지 않은 경우, 소유자 참조는 없는 것으로 처리되며, 소유자가 없는 것으로 확인되면
종속 항목이 삭제될 수 있다.
클러스터 범위의 종속 항목은 클러스터 범위의 소유자만 지정할 수 있다.
v1.20 이상에서 클러스터 범위의 종속 항목이 네임스페이스 종류를 소유자로 지정하면,
확인할 수 없는 소유자 참조가 있는 것으로 처리되고 가비지 수집이 될 수 없다.
v1.20 이상에서 가비지 수집기가 잘못된 교차 네임스페이스 `ownerReference`
또는 네임스페이스 종류를 참조하는 `ownerReference` 가 있는 클러스터 범위의 종속 항목을 감지하면,
`OwnerRefInvalidNamespace` 의 원인이 있는 경고 이벤트와 유효하지 않은 종속 항목의 `involvedObject` 가 보고된다.
`kubectl get events -A --field-selector=reason=OwnerRefInvalidNamespace` 를 실행하여
이러한 종류의 이벤트를 확인할 수 있다.
{{< /note >}}
## 가비지 수집기의 종속 항목 삭제 방식 제어
오브젝트를 삭제할 때, 오브젝트의 종속 항목을 자동으로 삭제하는지의
여부를 지정할 수 있다. 종속 항목을 자동으로 삭제하는 것을 *캐스케이딩(cascading)
삭제* 라고 한다. *캐스케이딩 삭제* 에는 *백그라운드* 와 *포어그라운드* 2가지 모드가 있다.
만약 종속 항목을 자동으로 삭제하지 않고 오브젝트를 삭제한다면,
종속 항목은 *분리됨(orphaned)* 이라고 한다.
### 포어그라운드 캐스케이딩 삭제
*포어그라운드 캐스케이딩 삭제* 에서는 루트 오브젝트가 먼저
"삭제 중(deletion in progress)" 상태가 된다. "삭제 중" 상태에서는
다음 사항이 적용된다.
* 오브젝트는 REST API를 통해 여전히 볼 수 있음
* 오브젝트에 `deletionTimestamp` 가 설정됨
* 오브젝트의 "foregroundDeletion"에 `metadata.finalizers` 값이 포함됨.
"삭제 중" 상태가 설정되면, 가비지
수집기는 오브젝트의 종속 항목을 삭제한다. 가비지 수집기는 모든
"차단" 종속 항목(`ownerReference.blockOwnerDeletion=true` 가 있는 오브젝트)의 삭제가 완료되면,
소유자 오브젝트를 삭제한다.
"foregroundDeletion" 에서는 ownerReference.blockOwnerDeletion=true 로
설정된 종속 항목만 소유자 오브젝트의 삭제를 차단한다는 것을 참고한다.
쿠버네티스 버전 1.7에서는 소유자 오브젝트에 대한 삭제 권한에 따라 `blockOwnerDeletion` 를 true로 설정하기 위해 사용자 접근을 제어하는
[어드미션 컨트롤러](/docs/reference/access-authn-authz/admission-controllers/#ownerreferencespermissionenforcement)가
추가되었기에 권한이 없는 종속 항목은 소유자 오브젝트의 삭제를 지연시킬 수 없다.
만약 오브젝트의 `ownerReferences` 필드가 컨트롤러(디플로이먼트 또는 레플리카셋과 같은)에
의해 설정된 경우 blockOwnerDeletion이 자동으로 설정되므로 이 필드를 수동으로 수정할 필요가 없다.
### 백그라운드 캐스케이딩 삭제
*백그라운드 캐스케이딩 삭제* 에서 쿠버네티스는 소유자 오브젝트를
즉시 삭제하고, 가비지 수집기는 백그라운드에서 종속 항목을
삭제한다.
### 캐스케이딩 삭제 정책 설정하기
캐스케이딩 삭제 정책을 제어하려면, 오브젝트를 삭제할 때 `deleteOptions`
인수를 `propagationPolicy` 필드에 설정한다. 여기에 가능한 값으로는 "Orphan",
"Foreground" 또는 "Background" 이다.
여기에 백그라운드에서 종속 항목을 삭제하는 예시가 있다.
```shell
kubectl proxy --port=8080
curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-repset \
-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Background"}' \
-H "Content-Type: application/json"
```
여기에 포어그라운드에서 종속 항목을 삭제하는 예시가 있다.
```shell
kubectl proxy --port=8080
curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-repset \
-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Foreground"}' \
-H "Content-Type: application/json"
```
여기에 종속 항목을 분리됨으로 하는 예시가 있다.
```shell
kubectl proxy --port=8080
curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-repset \
-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Orphan"}' \
-H "Content-Type: application/json"
```
kubectl도 캐스케이딩 삭제를 지원한다.
kubectl을 사용해서 포어그라운드의 종속 항목을 삭제하려면 `--cascade=foreground` 를 설정한다. 종속 항목을
분리하기 위해서는 `--cascade=orphan` 를 설정한다.
기본 동작은 백그라운드의 종속 항목을 삭제하는 것이며,
이는 `--cascade` 를 생략하거나 명시적으로 `background` 를 설정한 경우의 동작에 해당한다.
여기에 레플리카셋의 종속 항목을 분리로 만드는 예시가 있다.
```shell
kubectl delete replicaset my-repset --cascade=false
```
### 디플로이먼트에 대한 추가 참고
1.7 이전에서는 디플로이먼트와 캐스케이딩 삭제를 사용하면 반드시 `propagationPolicy: Foreground`
를 사용해서 생성된 레플리카셋뿐만 아니라 해당 파드도 삭제해야 한다. 만약 이 _propagationPolicy_
유형을 사용하지 않는다면, 레플리카셋만 삭제되고 파드는 분리된 상태로 남을 것이다.
더 많은 정보는 [kubeadm/#149](https://github.com/kubernetes/kubeadm/issues/149#issuecomment-284766613)를 본다.
## 알려진 이슈들
[#26120](https://github.com/kubernetes/kubernetes/issues/26120)을 추적한다.
## {{% heading "whatsnext" %}}
[디자인 문서 1](https://git.k8s.io/community/contributors/design-proposals/api-machinery/garbage-collection.md)
[디자인 문서 2](https://git.k8s.io/community/contributors/design-proposals/api-machinery/synchronous-garbage-collection.md)