[ko] Fix outdated files in dev-1.24-ko.2 (M21-M26) (#35220)
* [ko] Fix outdated files in dev-1.24-ko.2 (M21-M26) * Rev fix space typo ko/../taint-and-toleration.md Co-authored-by: Seokho Son <shsongist@gmail.com>pull/35525/head
Jinny Park
GitHub
parent
f8e507e8dd
commit
14d6312957
|
|
@ -51,7 +51,7 @@ _리밋레인지_ 는 다음과 같은 제약 조건을 제공한다.
|
|||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
자세한 내용은 [LimitRanger 디자인 문서](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md)를 참조한다.
|
||||
자세한 내용은 [LimitRanger 디자인 문서](https://git.k8s.io/design-proposals-archive/resource-management/admission_control_limit_range.md)를 참조한다.
|
||||
|
||||
제한의 사용에 대한 예시는 다음을 참조한다.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
|
||||
|
||||
# reviewers:
|
||||
# - derekwaynecarr
|
||||
title: 리소스 쿼터
|
||||
content_type: concept
|
||||
weight: 20
|
||||
|
|
@ -22,8 +22,7 @@ weight: 20
|
|||
|
||||
리소스 쿼터는 다음과 같이 작동한다.
|
||||
|
||||
- 다른 팀은 다른 네임스페이스에서 작동한다. 현재 이것은 자발적이지만 ACL을 통해 이 필수 사항을
|
||||
적용하기 위한 지원이 계획되어 있다.
|
||||
- 다른 팀은 다른 네임스페이스에서 작업한다. 이것은 [RBAC](/docs/reference/access-authn-authz/rbac/)으로 설정할 수 있다.
|
||||
|
||||
- 관리자는 각 네임스페이스에 대해 하나의 리소스쿼터를 생성한다.
|
||||
|
||||
|
|
@ -698,7 +697,7 @@ resourcequota/pods-cluster-services created
|
|||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
- 자세한 내용은 [리소스쿼터 디자인 문서](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md)를 참고한다.
|
||||
- 자세한 내용은 [리소스쿼터 디자인 문서](https://git.k8s.io/design-proposals-archive/resource-management/admission_control_resource_quota.md)를 참고한다.
|
||||
- [리소스 쿼터를 사용하는 방법에 대한 자세한 예](/docs/tasks/administer-cluster/quota-api-object/)를 참고한다.
|
||||
- [우선 순위 클래스에 대한 쿼터 지원 디자인 문서](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/pod-priority-resourcequota.md)를 읽는다.
|
||||
- [우선 순위 클래스에 대한 쿼터 지원 디자인 문서](https://git.k8s.io/design-proposals-archive/scheduling/pod-priority-resourcequota.md)를 읽는다.
|
||||
- [제한된 자원](https://github.com/kubernetes/kubernetes/pull/36765)을 참고한다.
|
||||
|
|
|
|||
|
|
@ -124,8 +124,8 @@ kubelet이 `node-restriction.kubernetes.io/` 접두사를 갖는 레이블을
|
|||
|
||||
이 예시에서는 다음의 규칙이 적용된다.
|
||||
|
||||
* 노드는 키가 `kubernetes.io/os`이고 값이 `linux`인 레이블을
|
||||
갖고 *있어야 한다* .
|
||||
* 노드는 키가 `topology.kubernetes.io/zone`인 레이블을 갖고 *있어야 하며*,
|
||||
레이블의 값이 `antarctica-east1` 혹은 `antarctica-west1`*여야 한다*.
|
||||
* 키가 `another-node-label-key`이고 값이 `another-node-label-value`인 레이블을
|
||||
갖고 있는 노드를 *선호한다* .
|
||||
|
||||
|
|
@ -302,9 +302,8 @@ Y는 쿠버네티스가 충족할 규칙이다.
|
|||
다른 노드도 존재한다면,
|
||||
스케줄러는 `topology.kubernetes.io/zone=R` 레이블이 있는 노드에는 가급적 해당 파드를 스케줄링하지 않야아 한다.
|
||||
|
||||
[디자인 문서](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)에서
|
||||
파드 어피니티와 안티-어피니티에 대한
|
||||
많은 예시를 볼 수 있다.
|
||||
파드 어피니티와 안티-어피니티의 예시에 대해 익숙해지고 싶다면,
|
||||
[디자인 제안](https://git.k8s.io/design-proposals-archive/scheduling/podaffinity.md)을 참조한다.
|
||||
|
||||
파드 어피니티와 안티-어피니티의 `operator` 필드에
|
||||
`In`, `NotIn`, `Exists` 및 `DoesNotExist` 값을 사용할 수 있다.
|
||||
|
|
@ -472,9 +471,11 @@ spec:
|
|||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* [테인트 및 톨러레이션](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)에 대해 더 읽어본다.
|
||||
* [노드 어피니티](https://git.k8s.io/community/contributors/design-proposals/scheduling/nodeaffinity.md)와
|
||||
[파드간 어피니티/안티-어피니티](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)에 대한 디자인 문서를 읽어본다.
|
||||
* [노드 어피니티](https://git.k8s.io/design-proposals-archive/scheduling/nodeaffinity.md)와
|
||||
[파드간 어피니티/안티-어피니티](https://git.k8s.io/design-proposals-archive/scheduling/podaffinity.md)에 대한 디자인 문서를 읽어본다.
|
||||
* [토폴로지 매니저](/docs/tasks/administer-cluster/topology-manager/)가
|
||||
노드 수준 리소스 할당 결정에 어떻게 관여하는지 알아본다.
|
||||
* [노드셀렉터(nodeSelector)](/ko/docs/tasks/configure-pod-container/assign-pods-nodes/)를 어떻게 사용하는지 알아본다.
|
||||
* [어피니티/안티-어피니티](/ko/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity/)를 어떻게 사용하는지 알아본다.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -97,7 +97,7 @@ kubectl get pod test-pod -o jsonpath='{.spec.overhead}'
|
|||
map[cpu:250m memory:120Mi]
|
||||
```
|
||||
|
||||
만약 리소스쿼터 항목이 정의되어 있다면, 컨테이너의 리소스 요청의 합에는
|
||||
만약 [리소스쿼터](/ko/docs/concepts/policy/resource-quotas/) 항목이 정의되어 있다면, 컨테이너의 리소스 요청의 합에는
|
||||
`overhead` 필드도 추가된다.
|
||||
|
||||
kube-scheduler 는 어떤 노드에 파드가 기동 되어야 할지를 정할 때, 파드의 `overhead` 와
|
||||
|
|
@ -196,3 +196,4 @@ sudo crictl inspectp -o=json $POD_ID | grep cgroupsPath
|
|||
* [런타임클래스](/ko/docs/concepts/containers/runtime-class/)에 대해 알아본다.
|
||||
* 더 자세한 문맥은
|
||||
[파드오버헤드 디자인](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/688-pod-overhead) 향상 제안을 확인한다.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,72 +1,102 @@
|
|||
---
|
||||
|
||||
|
||||
|
||||
|
||||
title: 확장된 리소스를 위한 리소스 빈 패킹(bin packing)
|
||||
# reviewers:
|
||||
# - bsalamat
|
||||
# - k82cn
|
||||
# - ahg-g
|
||||
title: 리소스 빈 패킹(bin packing)
|
||||
content_type: concept
|
||||
weight: 80
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
|
||||
|
||||
kube-scheduler는 `RequestedToCapacityRatioResourceAllocation`
|
||||
우선 순위 기능을 사용해서 확장된 리소스와 함께 리소스의 빈 패킹이 가능하도록
|
||||
구성할 수 있다. 우선 순위 기능을 사용해서 맞춤 요구에 따라
|
||||
kube-scheduler를 미세 조정할 수 있다.
|
||||
kube-scheduler의 [스케줄링 플러그인](/ko/docs/reference/scheduling/config/#scheduling-plugins) `NodeResourcesFit`에는,
|
||||
리소스의 빈 패킹(bin packing)을 지원하는 `MostAllocated`과 `RequestedToCapacityRatio`라는 두 가지 점수 산정(scoring) 전략이 있다.
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## RequestedToCapacityRatioResourceAllocation을 사용해서 빈 패킹 활성화하기
|
||||
## MostAllocated 전략을 사용하여 빈 패킹 활성화하기
|
||||
`MostAllocated` 전략은 리소스 사용량을 기반으로 할당량이 많은 노드를 높게 평가하여 노드에 점수를 매긴다.
|
||||
각 리소스 유형별로 가중치를 설정하여 노드 점수에 미치는 영향을 조정할 수 있다.
|
||||
|
||||
쿠버네티스는 사용자가 각 리소스에 대한 가중치와 함께 리소스를 지정하여
|
||||
용량 대비 요청 비율을 기반으로 노드의 점수를 매기는 것을 허용한다.
|
||||
이를 통해 사용자는 적절한 파라미터를 사용해서 확장된 리소스를 빈 팩으로 만들 수 있어
|
||||
대규모의 클러스터에서 부족한 리소스의 활용도가 향상된다.
|
||||
`RequestedToCapacityRatioResourceAllocation` 우선 순위 기능의 동작은
|
||||
`RequestedToCapacityRatioArgs`라는 구성 옵션으로 제어할 수 있다.
|
||||
이 인수는 `shape`와 `resources` 두 개의 파라미터로 구성된다.
|
||||
`shape` 파라미터는 사용자가 `utilization`과 `score` 값을 기반으로
|
||||
최소 요청 또는 최대 요청된 대로 기능을 조정할 수 있게 한다.
|
||||
`NodeResourcesFit` 플러그인에 대한 `MostAllocated` 전략을 설정하려면,
|
||||
다음과 유사한 [스케줄러 설정](/ko/docs/reference/scheduling/config)을 사용한다.
|
||||
|
||||
```yaml
|
||||
apiVersion: kubescheduler.config.k8s.io/v1beta3
|
||||
kind: KubeSchedulerConfiguration
|
||||
profiles:
|
||||
- pluginConfig:
|
||||
- args:
|
||||
scoringStrategy:
|
||||
resources:
|
||||
- name: cpu
|
||||
weight: 1
|
||||
- name: memory
|
||||
weight: 1
|
||||
- name: intel.com/foo
|
||||
weight: 3
|
||||
- name: intel.com/bar
|
||||
weight: 3
|
||||
type: MostAllocated
|
||||
name: NodeResourcesFit
|
||||
```
|
||||
|
||||
기타 파라미터와 기본 구성에 대한 자세한 내용은
|
||||
[`NodeResourcesFitArgs`](/docs/reference/config-api/kube-scheduler-config.v1beta3/#kubescheduler-config-k8s-io-v1beta3-NodeResourcesFitArgs)에 대한 API 문서를 참조한다.
|
||||
|
||||
## RequestedToCapacityRatio을 사용하여 빈 패킹 활성화하기
|
||||
|
||||
`RequestedToCapacityRatio` 전략은 사용자가 각 리소스에 대한 가중치와 함께 리소스를 지정하여
|
||||
용량 대비 요청 비율을 기반으로 노드의 점수를 매길 수 있게 한다.
|
||||
이를 통해 사용자는 적절한 파라미터를 사용하여 확장된 리소스를 빈 팩으로 만들 수 있어
|
||||
대규모의 클러스터에서 부족한 리소스의 활용도를 향상시킬 수 있다. 이 전략은
|
||||
할당된 리소스의 구성된 기능에 따라 노드를 선호하게 한다. `NodeResourcesFit`점수 기능의
|
||||
`RequestedToCapacityRatio` 동작은 [scoringStrategy](/docs/reference/config-api/kube-scheduler-config.v1beta3/#kubescheduler-config-k8s-io-v1beta3-ScoringStrategy)필드를
|
||||
이용하여 제어할 수 있다.
|
||||
`scoringStrategy` 필드에서 `requestedToCapacityRatioParam`와 `resources`라는 두 개의 파라미터를
|
||||
구성할 수 있다. `requestedToCapacityRatioParam`파라미터의
|
||||
`shape`를 사용하면 `utilization`과 `score` 값을 기반으로
|
||||
최소 요청 혹은 최대 요청된 대로 기능을 조정할 수 있게 한다.
|
||||
`resources` 파라미터는 점수를 매길 때 고려할 리소스의 `name` 과
|
||||
각 리소스의 가중치를 지정하는 `weight` 로 구성된다.
|
||||
|
||||
다음은 확장된 리소스 `intel.com/foo` 와 `intel.com/bar` 에 대한
|
||||
`requestedToCapacityRatioArguments` 를 빈 패킹 동작으로
|
||||
다음은 `requestedToCapacityRatio` 를 이용해
|
||||
확장된 리소스 `intel.com/foo` 와 `intel.com/bar` 에 대한 빈 패킹 동작을
|
||||
설정하는 구성의 예시이다.
|
||||
|
||||
```yaml
|
||||
apiVersion: kubescheduler.config.k8s.io/v1beta3
|
||||
kind: KubeSchedulerConfiguration
|
||||
profiles:
|
||||
# ...
|
||||
pluginConfig:
|
||||
- name: RequestedToCapacityRatio
|
||||
args:
|
||||
shape:
|
||||
- utilization: 0
|
||||
score: 10
|
||||
- utilization: 100
|
||||
score: 0
|
||||
resources:
|
||||
- name: intel.com/foo
|
||||
weight: 3
|
||||
- name: intel.com/bar
|
||||
weight: 5
|
||||
- pluginConfig:
|
||||
- args:
|
||||
scoringStrategy:
|
||||
resources:
|
||||
- name: intel.com/foo
|
||||
weight: 3
|
||||
- name: intel.com/bar
|
||||
weight: 3
|
||||
requestedToCapacityRatioParam:
|
||||
shape:
|
||||
- utilization: 0
|
||||
score: 0
|
||||
- utilization: 100
|
||||
score: 10
|
||||
type: RequestedToCapacityRatio
|
||||
name: NodeResourcesFit
|
||||
```
|
||||
|
||||
kube-scheduler 플래그 `--config=/path/to/config/file` 을 사용하여
|
||||
`KubeSchedulerConfiguration` 파일을 참조하면 구성이 스케줄러에
|
||||
전달된다.
|
||||
|
||||
**이 기능은 기본적으로 비활성화되어 있다.**
|
||||
기타 파라미터와 기본 구성에 대한 자세한 내용은
|
||||
[`NodeResourcesFitArgs`](/docs/reference/config-api/kube-scheduler-config.v1beta3/#kubescheduler-config-k8s-io-v1beta3-NodeResourcesFitArgs)에 대한 API 문서를 참조한다.
|
||||
|
||||
### 우선 순위 기능 튜닝하기
|
||||
### 점수 기능 튜닝하기
|
||||
|
||||
`shape` 는 `RequestedToCapacityRatioPriority` 기능의
|
||||
동작을 지정하는 데 사용된다.
|
||||
`shape` 는 `RequestedToCapacityRatio` 기능의 동작을 지정하는 데 사용된다.
|
||||
|
||||
```yaml
|
||||
shape:
|
||||
|
|
@ -221,3 +251,4 @@ NodeScore = (5 * 5) + (7 * 1) + (10 * 3) / (5 + 1 + 3)
|
|||
|
||||
- [스케줄링 프레임워크](/docs/concepts/scheduling-eviction/scheduling-framework/)에 대해 더 읽어본다.
|
||||
- [스케줄러 구성](/ko/docs/reference/scheduling/config/)에 대해 더 읽어본다.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,8 +1,8 @@
|
|||
---
|
||||
|
||||
|
||||
|
||||
|
||||
# reviewers:
|
||||
# - davidopp
|
||||
# - kevin-wangzefeng
|
||||
# - bsalamat
|
||||
title: 테인트(Taints)와 톨러레이션(Tolerations)
|
||||
content_type: concept
|
||||
weight: 40
|
||||
|
|
@ -15,8 +15,7 @@ weight: 40
|
|||
(기본 설정 또는 어려운 요구 사항으로) *끌어들이는* {{< glossary_tooltip text="파드" term_id="pod" >}}의 속성이다.
|
||||
_테인트_ 는 그 반대로, 노드가 파드 셋을 제외할 수 있다.
|
||||
|
||||
_톨러레이션_ 은 파드에 적용되며, 파드를 일치하는 테인트가 있는 노드에
|
||||
스케줄되게 하지만 필수는 아니다.
|
||||
_톨러레이션_ 은 파드에 적용된다. 톨러레이션을 통해 스케줄러는 그와 일치하는 테인트가 있는 파드를 스케줄할 수 있다. 톨러레이션은 스케줄을 허용하지만 보장하지는 않는다. 스케줄러는 그 기능의 일부로서 [다른 매개변수를](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/) 고려한다.
|
||||
|
||||
테인트와 톨러레이션은 함께 작동하여 파드가 부적절한 노드에 스케줄되지
|
||||
않게 한다. 하나 이상의 테인트가 노드에 적용된다. 이것은
|
||||
|
|
|
|||
Loading…
Reference in New Issue