Second Korean l10n work for release-1.19
- Fix issue with links to already translated documents (#23829) - Update outdated files in the dev-1.19-ko.2 branch (#23827) - Fix issue with links to already translated documents (#23999) - Translate tasks/configure-pod-container/configure-persistent-volume-storage in Korean (#23867) - Translate reference/access-authn-authz/service-accounts-admin/ into Korean (#23974) - Translate reference/access-authn-authz/controlling-access/ into Korean (#23955) - Translate tasks/job/automated-tasks-with-cron-jobs.md into Korean (#23543) - Translate reference/access-authn-authz/authorization/ into Korean (#23989) - Update Ko localization guide (#24023) - Translate tasks/job/fine-parallel-processing-work-queue/ into Korean (#23841) - Translate setup/production-environment/windows/intro-windows-in-kubernetes and reflect reviews (#23879) - Translate tasks/debug-application-cluster/debug-pod-replication-controller in Korean (#23896) Co-authored-by: seokho-son <shsongist@gmail.com> Co-authored-by: jmyung <jesang.myung@gmail.com> Co-authored-by: Jerry Park <jaehwa@gmail.com> Co-authored-by: markruler <csu0414@gmail.com> Co-authored-by: bluefriday <bluefriday86@gmail.com>
This commit is contained in:
Jerry Park
@@ -214,9 +214,11 @@ kubelet은 모든 주기적인 동기화에서 마운트된 컨피그맵이 최
|
||||
전파 지연은 선택한 캐시 유형에 따라 달라질 수 있다(전파
|
||||
지연을 지켜보거나, 캐시의 ttl 또는 0에 상응함).
|
||||
|
||||
## 변경할 수 없는(immutable) 컨피그맵 {#configmap-immutable}
|
||||
|
||||
{{< feature-state for_k8s_version="v1.19" state="beta" >}}
|
||||
|
||||
쿠버네티스 베타 기능인 _변경할 수 없는(immutable) 시크릿과 컨피그맵_ 은 개별 시크릿과
|
||||
쿠버네티스 베타 기능인 _변경할 수 없는 시크릿과 컨피그맵_ 은 개별 시크릿과
|
||||
컨피그맵을 변경할 수 없는 것으로 설정하는 옵션을 제공한다. 컨피그맵을 광범위하게
|
||||
사용하는 클러스터(최소 수만 개의 고유한 컨피그맵이 파드에 마운트)의 경우
|
||||
데이터 변경을 방지하면 다음과 같은 이점이 있다.
|
||||
@@ -224,9 +226,10 @@ kubelet은 모든 주기적인 동기화에서 마운트된 컨피그맵이 최
|
||||
- 애플리케이션 중단을 일으킬 수 있는 우발적(또는 원하지 않는) 업데이트로부터 보호
|
||||
- immutable로 표시된 컨피그맵에 대한 감시를 중단하여, kube-apiserver의 부하를 크게 줄임으로써 클러스터의 성능을 향상시킴
|
||||
|
||||
이 기능을 사용하려면 `ImmutableEphemeralVolumes`
|
||||
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화하고
|
||||
시크릿 또는 컨피그맵의 `immutable` 필드를 `true` 로 한다. 다음은 예시이다.
|
||||
이 기능은 v1.19부터 기본적으로 활성화된 `ImmutableEphemeralVolumes` [기능
|
||||
게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)에
|
||||
의해 제어된다. `immutable` 필드를 `true` 로 설정하여
|
||||
변경할 수 없는 컨피그맵을 생성할 수 있다. 다음은 예시이다.
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: ConfigMap
|
||||
@@ -247,7 +250,7 @@ immutable: true
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* [시크릿](/docs/concepts/configuration/secret/)에 대해 읽어본다.
|
||||
* [시크릿](/ko/docs/concepts/configuration/secret/)에 대해 읽어본다.
|
||||
* [컨피그맵을 사용하도록 파드 구성하기](/docs/tasks/configure-pod-container/configure-pod-configmap/)를 읽어본다.
|
||||
* 코드를 구성에서 분리하려는 동기를 이해하려면
|
||||
[Twelve-Factor 앱](https://12factor.net/ko/)을 읽어본다.
|
||||
|
||||
@@ -101,4 +101,4 @@ DNS 서버는 새로운 `서비스`를 위한 쿠버네티스 API를 Watch하며
|
||||
|
||||
- `get`과 `delete` 동작을 위해 특정 오브젝트의 이름 대신 레이블 셀렉터를 사용한다. [레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/#레이블-셀렉터)와 [효율적으로 레이블 사용하기](/ko/docs/concepts/cluster-administration/manage-deployment/#효과적인-레이블-사용)를 참고할 수 있다.
|
||||
|
||||
- 단일 컨테이너로 구성된 디플로이먼트와 서비스를 빠르게 생성하기 위해 `kubectl create deployment` 와 `kubectl expose` 를 사용한다. [클러스터 내부의 애플리케이션에 접근하기 위한 서비스 사용](/docs/tasks/access-application-cluster/service-access-application-cluster/)에서 예시를 확인할 수 있다.
|
||||
- 단일 컨테이너로 구성된 디플로이먼트와 서비스를 빠르게 생성하기 위해 `kubectl create deployment` 와 `kubectl expose` 를 사용한다. [클러스터 내부의 애플리케이션에 접근하기 위한 서비스 사용](/ko/docs/tasks/access-application-cluster/service-access-application-cluster/)에서 예시를 확인할 수 있다.
|
||||
|
||||
@@ -1,191 +0,0 @@
|
||||
---
|
||||
title: 확장된 리소스를 위한 리소스 빈 패킹(bin packing)
|
||||
content_type: concept
|
||||
weight: 50
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
|
||||
|
||||
kube-scheduler는 `RequestedToCapacityRatioResourceAllocation` 우선 순위 기능을 사용해서 확장된 리소스와 함께 리소스의 빈 패킹이 가능하도록 구성할 수 있다. 우선 순위 기능을 사용해서 맞춤 요구에 따라 kube-scheduler를 미세 조정할 수 있다.
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## RequestedToCapacityRatioResourceAllocation을 사용해서 빈 패킹 활성화하기
|
||||
|
||||
쿠버네티스 1.15 이전에는 Kube-scheduler가 CPU 및 메모리와 같은 리소스의 용량 대비 요청 비율을 기반으로 노드의 점수를 매기는 것을 허용했다. 쿠버네티스 1.16은 우선 순위 기능에 새로운 파라미터를 추가해서 사용자가 용량 대비 요청 비율을 기반으로 노드에 점수를 매기도록 각 리소스의 가중치와 함께 리소스를 지정할 수 있다. 이를 통해 사용자는 적절한 파라미터를 사용해서 확장된 리소스를 빈 팩으로 만들수 있어 대규모의 클러스터에서 부족한 리소스의 활용도가 향상된다. `RequestedToCapacityRatioResourceAllocation` 우선 순위 기능의 동작은 `requestedToCapacityRatioArguments`라는 구성 옵션으로 제어할 수 있다. 이 인수는 `shape`와 `resources` 두 개의 파라미터로 구성된다. 셰이프(shape)는 사용자가 `utilization`과 `score` 값을 기반으로 최소 요청 또는 최대 요청된 대로 기능을 조정할 수 있게 한다. 리소스는
|
||||
점수를 매길 때 고려할 리소스를 지정하는 `name` 과 각 리소스의 가중치를 지정하는 `weight` 로 구성된다.
|
||||
|
||||
다음은 확장된 리소스 `intel.com/foo` 와 `intel.com/bar` 에 대한 `requestedToCapacityRatioArguments` 를 빈 패킹 동작으로 설정하는 구성의 예시이다.
|
||||
|
||||
```json
|
||||
{
|
||||
"kind" : "Policy",
|
||||
"apiVersion" : "v1",
|
||||
|
||||
...
|
||||
|
||||
"priorities" : [
|
||||
|
||||
...
|
||||
|
||||
{
|
||||
"name": "RequestedToCapacityRatioPriority",
|
||||
"weight": 2,
|
||||
"argument": {
|
||||
"requestedToCapacityRatioArguments": {
|
||||
"shape": [
|
||||
{"utilization": 0, "score": 0},
|
||||
{"utilization": 100, "score": 10}
|
||||
],
|
||||
"resources": [
|
||||
{"name": "intel.com/foo", "weight": 3},
|
||||
{"name": "intel.com/bar", "weight": 5}
|
||||
]
|
||||
}
|
||||
}
|
||||
}
|
||||
],
|
||||
}
|
||||
```
|
||||
|
||||
**이 기능은 기본적으로 비활성화되어 있다.**
|
||||
|
||||
### RequestedToCapacityRatioResourceAllocation 우선 순위 기능 튜닝하기
|
||||
|
||||
`shape` 는 `RequestedToCapacityRatioPriority` 기능의 동작을 지정하는 데 사용된다.
|
||||
|
||||
```yaml
|
||||
{"utilization": 0, "score": 0},
|
||||
{"utilization": 100, "score": 10}
|
||||
```
|
||||
|
||||
위의 인수는 사용률이 0%인 경우 점수는 0, 사용률이 100%인 경우 10으로 하여, 빈 패킹 동작을 활성화한다. 최소 요청을 활성화하려면 점수 값을 다음과 같이 변경해야 한다.
|
||||
|
||||
```yaml
|
||||
{"utilization": 0, "score": 100},
|
||||
{"utilization": 100, "score": 0}
|
||||
```
|
||||
|
||||
`resources` 는 기본적으로 다음과 같이 설정되는 선택적인 파라미터이다.
|
||||
|
||||
``` yaml
|
||||
"resources": [
|
||||
{"name": "CPU", "weight": 1},
|
||||
{"name": "Memory", "weight": 1}
|
||||
]
|
||||
```
|
||||
|
||||
다음과 같이 확장된 리소스를 추가하는 데 사용할 수 있다.
|
||||
|
||||
```yaml
|
||||
"resources": [
|
||||
{"name": "intel.com/foo", "weight": 5},
|
||||
{"name": "CPU", "weight": 3},
|
||||
{"name": "Memory", "weight": 1}
|
||||
]
|
||||
```
|
||||
|
||||
가중치 파라미터는 선택 사항이며 지정되지 않은 경우 1로 설정 된다. 또한, 가중치는 음수로 설정할 수 없다.
|
||||
|
||||
### RequestedToCapacityRatioResourceAllocation 우선 순위 기능이 노드에 점수를 매기는 방법
|
||||
|
||||
이 섹션은 이 기능 내부의 세부적인 사항을 이해하려는 사람들을
|
||||
위한 것이다.
|
||||
아래는 주어진 값의 집합에 대해 노드 점수가 계산되는 방법의 예시이다.
|
||||
|
||||
```
|
||||
Requested Resources
|
||||
|
||||
intel.com/foo : 2
|
||||
Memory: 256MB
|
||||
CPU: 2
|
||||
|
||||
Resource Weights
|
||||
|
||||
intel.com/foo : 5
|
||||
Memory: 1
|
||||
CPU: 3
|
||||
|
||||
FunctionShapePoint {{0, 0}, {100, 10}}
|
||||
|
||||
Node 1 Spec
|
||||
|
||||
Available:
|
||||
intel.com/foo : 4
|
||||
Memory : 1 GB
|
||||
CPU: 8
|
||||
|
||||
Used:
|
||||
intel.com/foo: 1
|
||||
Memory: 256MB
|
||||
CPU: 1
|
||||
|
||||
|
||||
Node Score:
|
||||
|
||||
intel.com/foo = resourceScoringFunction((2+1),4)
|
||||
= (100 - ((4-3)*100/4)
|
||||
= (100 - 25)
|
||||
= 75 # requested + used = 75% * available
|
||||
= rawScoringFunction(75)
|
||||
= 7 # floor(75/10)
|
||||
|
||||
Memory = resourceScoringFunction((256+256),1024)
|
||||
= (100 -((1024-512)*100/1024))
|
||||
= 50 # requested + used = 50% * available
|
||||
= rawScoringFunction(50)
|
||||
= 5 # floor(50/10)
|
||||
|
||||
CPU = resourceScoringFunction((2+1),8)
|
||||
= (100 -((8-3)*100/8))
|
||||
= 37.5 # requested + used = 37.5% * available
|
||||
= rawScoringFunction(37.5)
|
||||
= 3 # floor(37.5/10)
|
||||
|
||||
NodeScore = (7 * 5) + (5 * 1) + (3 * 3) / (5 + 1 + 3)
|
||||
= 5
|
||||
|
||||
|
||||
Node 2 Spec
|
||||
|
||||
Available:
|
||||
intel.com/foo: 8
|
||||
Memory: 1GB
|
||||
CPU: 8
|
||||
|
||||
Used:
|
||||
|
||||
intel.com/foo: 2
|
||||
Memory: 512MB
|
||||
CPU: 6
|
||||
|
||||
|
||||
Node Score:
|
||||
|
||||
intel.com/foo = resourceScoringFunction((2+2),8)
|
||||
= (100 - ((8-4)*100/8)
|
||||
= (100 - 50)
|
||||
= 50
|
||||
= rawScoringFunction(50)
|
||||
= 5
|
||||
|
||||
Memory = resourceScoringFunction((256+512),1024)
|
||||
= (100 -((1024-768)*100/1024))
|
||||
= 75
|
||||
= rawScoringFunction(75)
|
||||
= 7
|
||||
|
||||
CPU = resourceScoringFunction((2+6),8)
|
||||
= (100 -((8-8)*100/8))
|
||||
= 100
|
||||
= rawScoringFunction(100)
|
||||
= 10
|
||||
|
||||
NodeScore = (5 * 5) + (7 * 1) + (10 * 3) / (5 + 1 + 3)
|
||||
= 7
|
||||
|
||||
```
|
||||
@@ -715,37 +715,6 @@ kubelet은 마운트된 시크릿이 모든 주기적인 동기화에서 최신
|
||||
받지 않는다.
|
||||
{{< /note >}}
|
||||
|
||||
{{< feature-state for_k8s_version="v1.19" state="beta" >}}
|
||||
|
||||
쿠버네티스 베타 기능인 _변경할 수 없는(immutable) 시크릿과 컨피그맵_ 은
|
||||
개별 시크릿과 컨피그맵을 변경할 수 없는 것으로 설정하는 옵션을 제공한다. 시크릿을 광범위하게 사용하는
|
||||
클러스터(최소 수만 개의 고유한 시크릿이 파드에 마운트)의 경우, 데이터 변경을 방지하면
|
||||
다음과 같은 이점이 있다.
|
||||
|
||||
- 애플리케이션 중단을 유발할 수 있는 우발적(또는 원하지 않는) 업데이트로부터 보호
|
||||
- immutable로 표시된 시크릿에 대한 감시를 중단하여, kube-apiserver의 부하를
|
||||
크게 줄임으로써 클러스터의 성능을 향상시킴
|
||||
|
||||
이 기능을 사용하려면, `ImmutableEphemeralVolumes`
|
||||
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화하고
|
||||
시크릿 또는 컨피그맵의 `immutable` 필드를 `true` 로 한다. 다음은 예시이다.
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
...
|
||||
data:
|
||||
...
|
||||
immutable: true
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
시크릿 또는 컨피그맵을 immutable로 표시하면, 이 변경 사항을 되돌리거나
|
||||
`data` 필드 내용을 변경할 수 _없다_. 시크릿을 삭제하고 다시 생성할 수만 있다.
|
||||
기존 파드는 삭제된 시크릿에 대한 마운트 포인트를 유지하며, 이러한 파드를 다시 생성하는 것을
|
||||
권장한다.
|
||||
{{< /note >}}
|
||||
|
||||
### 시크릿을 환경 변수로 사용하기
|
||||
|
||||
파드에서 {{< glossary_tooltip text="환경 변수" term_id="container-env-variables" >}}에
|
||||
@@ -806,6 +775,40 @@ echo $SECRET_PASSWORD
|
||||
1f2d1e2e67df
|
||||
```
|
||||
|
||||
## 변경할 수 없는(immutable) 시크릿 {#secret-immutable}
|
||||
|
||||
{{< feature-state for_k8s_version="v1.19" state="beta" >}}
|
||||
|
||||
쿠버네티스 베타 기능인 _변경할 수 없는 시크릿과 컨피그맵_ 은
|
||||
개별 시크릿과 컨피그맵을 변경할 수 없는 것으로 설정하는 옵션을 제공한다. 시크릿을 광범위하게 사용하는
|
||||
클러스터(최소 수만 개의 고유한 시크릿이 파드에 마운트)의 경우, 데이터 변경을 방지하면
|
||||
다음과 같은 이점이 있다.
|
||||
|
||||
- 애플리케이션 중단을 유발할 수 있는 우발적(또는 원하지 않는) 업데이트로부터 보호
|
||||
- immutable로 표시된 시크릿에 대한 감시를 중단하여, kube-apiserver의 부하를
|
||||
크게 줄임으로써 클러스터의 성능을 향상시킴
|
||||
|
||||
이 기능은 v1.19부터 기본적으로 활성화된 `ImmutableEphemeralVolumes` [기능
|
||||
게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)에
|
||||
의해 제어된다. `immutable` 필드를 `true` 로 설정하여
|
||||
변경할 수 없는 시크릿을 생성할 수 있다. 다음은 예시이다.
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
...
|
||||
data:
|
||||
...
|
||||
immutable: true
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
시크릿 또는 컨피그맵을 immutable로 표시하면, 이 변경 사항을 되돌리거나
|
||||
`data` 필드 내용을 변경할 수 _없다_. 시크릿을 삭제하고 다시 생성할 수만 있다.
|
||||
기존 파드는 삭제된 시크릿에 대한 마운트 포인트를 유지하며, 이러한 파드를 다시 생성하는 것을
|
||||
권장한다.
|
||||
{{< /note >}}
|
||||
|
||||
### imagePullSecrets 사용하기
|
||||
|
||||
`imagePullSecrets` 필드는 동일한 네임스페이스의 시크릿에 대한 참조 목록이다.
|
||||
|
||||
Reference in New Issue
Block a user