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

Fourth Korean l10n work for release 1.18

Browse Source 
- Translate docs/reference/issues-security/_index.md into Korean (#21145)
- Translate tasks/administer-cluster/kubeadm/adding-windows-nodes.md into Korean (#21003)
- Translate manage-resources/memory-default-namespace.md into Korean (#21089)
- Translate tasks/configure-pod-container/pull-image-private-registry in Korean (#21036)
- Translate contribute/advanced.md into Korean (#21002)
- Update to Outdated files in the dev-1.18-ko.4 branch. (#21102)
- Translate manage-resources/cpu-constraint-namespace.md into Korean (#21048)
- Translate manage-resources/memory-constraint-namespace.md into Korean (#21091)
- Translate setup/release/notes.md in Korean (#21158)
- Translate manage-resources/quota-pod-namespace.md into Korean (#21087)
- Translate tasks/administer-cluster/kubeadm/upgrading-windows-nodes.md into Korean (#20999)
- Translate tasks/administer-cluster/kubeadm/kubeadm-certs.md into Korean (#21000)
- Translate manage-resources/quota-memory-cpu-namespace.md into Korean (#21088)
- Translate manage-resources/cpu-default-namespace.md into Korean (#21090)
- Translate contribute/suggesting-improvements.md into Korean (#21001)
- Translate quality-service-pod in Korean (#21081)

Co-authored-by: Jerry Park <jaehwa@gmail.com>
Co-authored-by: Jesang Myung <jesang.myung@gmail.com>
Co-authored-by: DongMoon Kim <dmoons.kim@gmail.com>
Co-authored-by: Jesang Myung <jesang.myung@gmail.com>
Co-authored-by: Yuk, Yongsu <ysyukr@gmail.com>
Co-authored-by: bluefriday <bluefriday86@gmail.com>
This commit is contained in:
Jerry Park
2020-05-23 21:31:56 +09:00
committed by June Yi
parent 3dee902b75
commit b6760f3ae2
135 changed files with 5336 additions and 1110 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/ko/docs/concepts/workloads/controllers/daemonset.md
+2 -2
View File
@@ -91,9 +91,9 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
### 오직 일부 노드에서만 파드 실행
만약 `.spec.template.spec.nodeSelector` 를 명시하면 데몬셋 컨트롤러는
[노드 셀렉터](/ko/docs/concepts/configuration/assign-pod-node/#노드-셀렉터-nodeselector)와
[노드 셀렉터](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#노드-셀렉터-nodeselector)와
일치하는 노드에 파드를 생성한다. 마찬가지로 `.spec.template.spec.affinity` 를 명시하면
데몬셋 컨트롤러는 [노트 어피니티](/ko/docs/concepts/configuration/assign-pod-node/#노드-어피니티)와 일치하는 노드에 파드를 생성한다.
데몬셋 컨트롤러는 [노트 어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#노드-어피니티)와 일치하는 노드에 파드를 생성한다.
만약 둘 중 하나를 명시하지 않으면 데몬셋 컨트롤러는 모든 노드에서 파드를 생성한다.
## 데몬 파드가 스케줄 되는 방법
content/ko/docs/concepts/workloads/controllers/deployment.md
+95 -78
View File
@@ -51,12 +51,13 @@ _디플로이먼트_ 는 [파드](/ko/docs/concepts/workloads/pods/pod/)와
이 사례에서는 간단하게 파드 템플릿에 정의된 레이블(`app: nginx`)을 선택한다.
그러나 파드 템플릿 자체의 규칙이 만족되는 한,
보다 정교한 선택 규칙의 적용이 가능하다.
{{< note >}}
`.spec.selector.matchLabels` 필드는 {key,value}의 쌍으로 매핑되어있다. `matchLabels` 에 매핑된
단일 {key,value}은 `matchExpressions` 의 요소에 해당하며, 키 필드는 "key"에 그리고 연산자는 "In"에 대응되며
값 배열은 "value"만 포함한다.
매칭을 위해서는 `matchLabels` 와 `matchExpressions` 의 모든 요건이 충족되어야 한다.
{{< /note >}}
{{< note >}}
`.spec.selector.matchLabels` 필드는 {key,value}의 쌍으로 매핑되어있다. `matchLabels` 에 매핑된
단일 {key,value}은 `matchExpressions` 의 요소에 해당하며, 키 필드는 "key"에 그리고 연산자는 "In"에 대응되며
값 배열은 "value"만 포함한다.
매칭을 위해서는 `matchLabels` 와 `matchExpressions` 의 모든 요건이 충족되어야 한다.
{{< /note >}}
* `template` 필드에는 다음 하위 필드가 포함되어있다.
* 파드는 `.metadata.labels` 필드를 사용해서 `app: nginx` 라는 레이블을 붙인다.
@@ -65,86 +66,95 @@ _디플로이먼트_ 는 [파드](/ko/docs/concepts/workloads/pods/pod/)와
`nginx` 컨테이너 1개를 실행하는 것을 나타낸다.
* 컨테이너 1개를 생성하고, `.spec.template.spec.containers[0].name` 필드를 사용해서 `nginx` 이름을 붙인다.
위의 디플로이먼트를 생성하려면 다음 단계를 따른다.
시작하기 전에, 쿠버네티스 클러스터가 시작되고 실행 중인지 확인한다.
위의 디플로이먼트를 생성하려면 다음 단계를 따른다.
시작하기 전에, 쿠버네티스 클러스터가 시작되고 실행 중인지 확인한다.
1. 다음 명령어를 실행해서 디플로이먼트를 생성한다.
1. 다음 명령어를 실행해서 디플로이먼트를 생성한다.
{{< note >}}
`--record` 플래그를 지정해서 실행된 명령을 `kubernetes.io/change-cause` 리소스 어노테이션에 작성할 수 있다. 이것은 향후 인트로스펙션(introspection)에 유용하다.
예를 들면, 디플로이먼트의 각 수정 버전에서 실행된 명령을 볼 수 있다.
{{< /note >}}
```shell
kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml
```
2. `kubectl get deployments` 을 실행해서 디플로이먼트가 생성되었는지 확인한다. 만약 디플로이먼트가 여전히 생성중이면 다음과 유사하게 출력된다.
```shell
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deployment 0/3 0 0 1s
```
클러스터에서 디플로이먼트를 점검할 때 다음 필드가 표시된다.
* `NAME` 은 네임스페이스에 있는 디플로이먼트 이름의 목록이다.
* `READY` 는 사용자가 사용할 수 있는 애플리케이션의 레플리카의 수를 표시한다. ready/desired 패턴을 따른다.
* `UP-TO-DATE` 는 의도한 상태를 얻기위해 업데이트 된 레플리카의 수를 표시한다.
* `AVAILABLE` 은 사용자가 사용 가능한 애플리케이션 레플리카의 수를 표시한다.
* `AGE` 는 애플리케이션의 실행 된 시간을 표시한다.
`.spec.replicas` 필드에 따라 의도한 레플리카의 수가 3개인지 알 수 있다.
3. 디플로이먼트의 롤아웃 상태를 보려면 `kubectl rollout status deployment.v1.apps/nginx-deployment` 를 실행한다. 다음과 유사하게 출력된다.
```shell
Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
deployment.apps/nginx-deployment successfully rolled out
```
4. 몇 초 후 `kubectl get deployments` 를 다시 실행한다. 다음과 유사하게 출력된다.
```shell
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deployment 3/3 3 3 18s
```
디플로이먼트에서 3개의 레플리카가 생성되었고, 모든 레플리카는 최신 상태(최신 파드 템플릿을 포함)이며 사용 가능한 것을 알 수 있다.
5. 디플로이먼트로 생성된 레플리카셋(`rs`)을 보려면 `kubectl get rs` 를 실행한다. 다음과 유사하게 출력된다.
```shell
NAME DESIRED CURRENT READY AGE
nginx-deployment-75675f5897 3 3 3 18s
```
레플리카셋의 출력에는 다음 필드가 표시된다.
* `NAME` 은 네임스페이스에 있는 레플리카셋 이름의 목록이다.
* `DESIRED` 는 디플로이먼트의 생성 시 정의된 의도한 애플리케이션 _레플리카_ 의 수를 표시한다. 이것이 _의도한 상태_ 이다.
* `CURRENT` 는 현재 실행 중인 레플리카의 수를 표시한다.
* `READY` 는 사용자가 사용할 수 있는 애플리케이션의 레플리카의 수를 표시한다.
* `AGE` 는 애플리케이션의 실행된 시간을 표시한다.
레플리카셋의 이름은 항상 `[DEPLOYMENT-NAME]-[RANDOM-STRING]` 형식으로 된 것을 알 수 있다. 무작위 문자열은
무작위로 생성되며, `pod-template-hash` 를 시드(seed)로 사용한다.
6. 각 파드에 자동으로 생성된 레이블을 보려면 `kubectl get pods --show-labels` 를 실행한다. 다음과 유사하게 출력된다.
```shell
NAME READY STATUS RESTARTS AGE LABELS
nginx-deployment-75675f5897-7ci7o 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453
nginx-deployment-75675f5897-kzszj 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453
nginx-deployment-75675f5897-qqcnn 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453
```
만들어진 레플리카셋은 3개의 `nginx` 파드가 있는 것을 보장한다.
```shell
kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml
```
{{< note >}}
디플로이먼트에는 파드 템플릿 레이블과 적절한 셀렉터를 반드시 명시해야 한다(이 예시에서는 `app: nginx`).
레이블 또는 셀렉터는 다른 컨트롤러(다른 디플로이먼트와 스테이트풀 셋 포함)와 겹치지 않아야 한다. 쿠버네티스는 겹치는 것을 막지 않으며, 만약 다중 컨트롤러가 겹치는 셀렉터를 가지는 경우 해당 컨트롤러의 충돌 또는 예기치 않은 동작을 야기할 수 있다.
`--record` 플래그를 지정해서 실행된 명령을 `kubernetes.io/change-cause` 리소스 어노테이션에 작성할 수 있다.
기록된 변경사항은 향후 인트로스펙션(introspection)에 유용하다. 예를 들면, 디플로이먼트의 각 수정 버전에서 실행된 명령을 볼 수 있다.
{{< /note >}}
2. `kubectl get deployments` 을 실행해서 디플로이먼트가 생성되었는지 확인한다.
만약 디플로이먼트가 여전히 생성 중이면, 다음과 유사하게 출력된다.
```shell
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deployment 0/3 0 0 1s
```
클러스터에서 디플로이먼트를 점검할 때, 다음 필드가 표시된다.
* `NAME` 은 네임스페이스에 있는 디플로이먼트 이름의 목록이다.
* `READY` 는 사용자가 사용할 수 있는 애플리케이션의 레플리카의 수를 표시한다. ready/desired 패턴을 따른다.
* `UP-TO-DATE` 는 의도한 상태를 얻기 위해 업데이트된 레플리카의 수를 표시한다.
* `AVAILABLE` 은 사용자가 사용할 수 있는 애플리케이션 레플리카의 수를 표시한다.
* `AGE` 는 애플리케이션의 실행된 시간을 표시한다.
`.spec.replicas` 필드에 따라 의도한 레플리카의 수가 3개인지 알 수 있다.
3. 디플로이먼트의 롤아웃 상태를 보려면, `kubectl rollout status deployment.v1.apps/nginx-deployment` 를 실행한다.
다음과 유사하게 출력된다.
```shell
Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
deployment.apps/nginx-deployment successfully rolled out
```
4. 몇 초 후 `kubectl get deployments` 를 다시 실행한다.
다음과 유사하게 출력된다.
```shell
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deployment 3/3 3 3 18s
```
디플로이먼트에서 3개의 레플리카가 생성되었고, 모든 레플리카는 최신 상태(최신 파드 템플릿을 포함)이며 사용 가능한 것을 알 수 있다.
5. 디플로이먼트로 생성된 레플리카셋(`rs`)을 보려면, `kubectl get rs` 를 실행한다. 다음과 유사하게 출력된다.
```shell
NAME DESIRED CURRENT READY AGE
nginx-deployment-75675f5897 3 3 3 18s
```
레플리카셋의 출력에는 다음 필드가 표시된다.
* `NAME` 은 네임스페이스에 있는 레플리카셋 이름의 목록이다.
* `DESIRED` 는 디플로이먼트의 생성 시 정의된 의도한 애플리케이션 _레플리카_ 의 수를 표시한다. 이것이 _의도한 상태_ 이다.
* `CURRENT` 는 현재 실행 중인 레플리카의 수를 표시한다.
* `READY` 는 사용자가 사용할 수 있는 애플리케이션의 레플리카의 수를 표시한다.
* `AGE` 는 애플리케이션의 실행된 시간을 표시한다.
레플리카셋의 이름은 항상 `[DEPLOYMENT-NAME]-[RANDOM-STRING]` 형식으로 된 것을 알 수 있다. 무작위 문자열은
무작위로 생성되며, `pod-template-hash` 를 시드(seed)로 사용한다.
6. 각 파드에 자동으로 생성된 레이블을 보려면, `kubectl get pods --show-labels` 를 실행한다.
다음과 유사하게 출력된다.
```shell
NAME READY STATUS RESTARTS AGE LABELS
nginx-deployment-75675f5897-7ci7o 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453
nginx-deployment-75675f5897-kzszj 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453
nginx-deployment-75675f5897-qqcnn 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453
```
만들어진 레플리카셋은 실행 중인 3개의 `nginx` 파드를 보장한다.
{{< note >}}
디플로이먼트에는 파드 템플릿 레이블과 적절한 셀렉터를 반드시 명시해야 한다
(이 예시에서는 `app: nginx`).
레이블 또는 셀렉터는 다른 컨트롤러(다른 디플로이먼트와 스테이트풀 셋 포함)와 겹치지 않아야 한다. 쿠버네티스는 겹치는 것을 막지 않으며, 만약 다중 컨트롤러가 겹치는 셀렉터를 가지는 경우 해당 컨트롤러의 충돌 또는 예기치 않은 동작을 야기할 수 있다.
{{< /note >}}
### Pod-template-hash 레이블
{{< note >}}
{{< caution >}}
이 레이블은 변경하면 안 된다.
{{< /note >}}
{{< /caution >}}
`pod-template-hash` 레이블은 디플로이먼트 컨트롤러에 의해서 디플로이먼트가 생성 또는 채택한 모든 레플리케셋에 추가된다.
`pod-template-hash` 레이블은 디플로이먼트 컨트롤러에 의해서 디플로이먼트가 생성 또는 채택한 모든 레플리카셋에 추가된다.
이 레이블은 디플로이먼트의 자식 레플리카셋이 겹치지 않도록 보장한다. 레플리카셋의 `PodTemplate` 을 해싱하고, 해시 결과를 레플리카셋 셀렉터,
파드 템플릿 레이블 및 레플리카셋 이 가질 수 있는 기존의 모든 파드에 레이블 값으로 추가해서 사용하도록 생성한다.
@@ -407,9 +417,7 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성
```
{{< note >}}
디플로이먼트 컨트롤러가 잘못된 롤아웃을 자동으로 중지하고, 새로운 레플리카셋의 스케일 업을 중지한다.
이는 지정한 롤링 업데이트의 파라미터(구체적으로 `maxUnavailable`)에 따라 달라진다.
쿠버네티스는 기본값으로 25%를 설정한다.
디플로이먼트 컨트롤러가 잘못된 롤아웃을 자동으로 중지하고, 새로운 레플리카셋의 스케일 업을 중지한다. 이는 지정한 롤링 업데이트의 파라미터(구체적으로 `maxUnavailable`)에 따라 달라진다. 쿠버네티스는 기본값으로 25%를 설정한다.
{{< /note >}}
* 디플로이먼트에 대한 설명 보기
@@ -1080,6 +1088,15 @@ API 버전 `apps/v1` 에서는 `.spec.selector` 와 `.metadata.labels` 이 설
기존의 모든 파드는 `.spec.strategy.type==Recreate` 이면 새 파드가 생성되기 전에 죽는다.
{{< note >}}
이렇게 하면 업그레이드를 생성하기 전에 파드 종료를 보장할 수 있다. 디플로이먼트를 업그레이드하면,
이전 버전의 모든 파드가 즉시 종료된다. 신규 버전의 파드가 생성되기 전에 성공적으로 제거가
완료되기를 대기한다. 파드를 수동으로 삭제하면, 라이프사이클은 레플리카셋에 의해
제어되며(이전 파드가 여전히 종료 상태에 있는 경우에도) 교체용 파드가 즉시 생성된다. 파드에
대해 "최대" 보장이 필요한 경우
[스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)의 사용을 고려해야 한다.
{{< /note >}}
#### 디플로이먼트 롤링 업데이트
디플로이먼트는 `.spec.strategy.type==RollingUpdate` 이면 파드를 롤링 업데이트
@@ -1114,7 +1131,7 @@ API 버전 `apps/v1` 에서는 `.spec.selector` 와 `.metadata.labels` 이 설
`.spec.progressDeadlineSeconds` 는 디플로어먼트가 표면적으로 `Type=Progressing`, `Status=False`의
상태 그리고 리소스가 `Reason=ProgressDeadlineExceeded` 상태로 [진행 실패](#디플로이먼트-실패)를 보고하기 전에
디플로이먼트가 진행되는 것을 대기시키는 시간(초)를 명시하는 선택적 필드이다.
디플로이먼트 컨트롤러는 디플로이먼트를 계속 재시도 한다.
디플로이먼트 컨트롤러는 디플로이먼트를 계속 재시도 한다. 기본값은 600(초)이다.
미래에 자동화된 롤백이 구현된다면 디플로이먼트 컨트롤러는 상태를 관찰하고,
그 즉시 디플로이먼트를 롤백할 것이다.
content/ko/docs/concepts/workloads/controllers/replicaset.md
+1 -1
View File
@@ -326,7 +326,7 @@ kubectl apply -f https://k8s.io/examples/controllers/hpa-rs.yaml
(그리고 더 쉽다!)
```shell
kubectl autoscale rs frontend --max=10
kubectl autoscale rs frontend --max=10 --min=3 --cpu-percent=50
```
## 레플리카셋의 대안
content/ko/docs/concepts/workloads/pods/disruptions.md
+3 -1
View File
@@ -83,6 +83,8 @@ weight: 60
## Disruption Budgets의 작동 방식
{{< feature-state for_k8s_version="v1.5" state="beta" >}}
애플리케이션 소유자는 각 애플리케이션에 대해 `PodDisruptionBudget` 오브젝트(PDB)를 만들 수 있다.
PDB는 자발적 중단으로 일시에 중지되는 복제된 애플리케이션 파드의 수를 제한한다.
예를 들어 정족수 기반의 애플리케이션이
@@ -192,7 +194,7 @@ drain 커멘드는 `pod-b`를 축출하는데 성공했다.
| node-1 *drained* | node-2 | node-3 | *no node* |
|:--------------------:|:-------------------:|:------------------:|:------------------:|
| | pod-b *available* | pod-c *available* | pod-e *pending* |
| | pod-b *terminating* | pod-c *available* | pod-e *pending* |
| | pod-d *available* | pod-y | |
이 시점에서 클러스터 관리자는
content/ko/docs/concepts/workloads/pods/init-containers.md
+3 -3
View File
@@ -44,8 +44,8 @@ weight: 40
그러나, 초기화 컨테이너를 위한 리소스 요청량과 상한은
[리소스](#리소스)에 문서화된 것처럼 다르게 처리된다.
또한, 초기화 컨테이너는 준비성 프로브(readiness probe)를 지원하지 않는다. 왜냐하면 초기화 컨테이너는
파드가 준비 상태가 되기 전에 완료를 목표로 실행되어야 하기 때문이다.
또한, 초기화 컨테이너는 `lifecycle`, `livenessProbe`, `readinessProbe` 또는 `startupProbe` 를 지원하지 않는다.
왜냐하면 초기화 컨테이너는 파드가 준비 상태가 되기 전에 완료를 목표로 실행되어야 하기 때문이다.
만약 다수의 초기화 컨테이너가 파드에 지정되어 있다면, Kubelet은 해당 초기화 컨테이너들을
한 번에 하나씩 실행한다. 각 초기화 컨테이너는 다음 컨테이너를 실행하기 전에 꼭 성공해야 한다.
@@ -239,7 +239,7 @@ myapp-pod 1/1 Running 0 9m
```
이 간단한 예제는 사용자만의 초기화 컨테이너를 생성하는데
영감을 줄 것이다. [다음 순서](#what-s-next)에는 더 자세한 예제의 링크가 있다.
영감을 줄 것이다. [다음 순서](#다음-내용)에는 더 자세한 예제의 링크가 있다.
## 자세한 동작
content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
+2 -2
View File
@@ -55,7 +55,7 @@ node4 Ready <none> 2m43s v1.16.0 node=node4,zone=zoneB
`pod.spec.topologySpreadConstraints` 필드는 1.16에서 다음과 같이 도입되었다.
```yaml
```
apiVersion: v1
kind: Pod
metadata:
@@ -97,7 +97,7 @@ spec:
{{< codenew file="pods/topology-spread-constraints/one-constraint.yaml" >}}
`topologyKey: zone` 는 "zone:<any value>" 레이블 쌍을 가지는 노드에 대해서만 균등한 분배를 적용하는 것을 의미한다. `whenUnsatisfiable: DoNotSchedule` 은 만약 들어오는 파드가 제약 조건을 만족시키지 못하면 스케줄러에게 pending 상태를 유지하도록 지시한다.
`topologyKey: zone` 는 "zone:&lt;any value&gt;" 레이블 쌍을 가지는 노드에 대해서만 균등한 분배를 적용하는 것을 의미한다. `whenUnsatisfiable: DoNotSchedule` 은 만약 들어오는 파드가 제약 조건을 만족시키지 못하면 스케줄러에게 pending 상태를 유지하도록 지시한다.
만약 스케줄러가 이 신규 파드를 "zoneA"에 배치하면 파드 분포는 [3, 1]이 되며, 따라서 실제 차이(skew)는 2 (3 - 1)가 되어 `maxSkew: 1` 를 위반하게 된다. 이 예시에서는 들어오는 파드는 오직 "zoneB"에만 배치할 수 있다.
content/ko/docs/concepts/workloads/pods/podpreset.md
+27 -27
View File
@@ -5,7 +5,9 @@ weight: 50
---
{{% capture overview %}}
이 페이지는 파드 프리셋에 대한 개요를 제공한다. 파드 프리셋은 파드 생성 시간에 파드에
{{< feature-state for_k8s_version="v1.6" state="alpha" >}}
이 페이지는 파드프리셋(PodPreset)에 대한 개요를 제공한다. 파드프리셋은 파드 생성 시간에 파드에
특정 정보를 주입하기 위한 오브젝트이다. 해당 정보에는
시크릿, 볼륨, 볼륨 마운트, 환경 변수가 포함될 수 있다.
{{% /capture %}}
@@ -14,16 +16,33 @@ weight: 50
{{% capture body %}}
## 파드 프리셋 이해하기
`Pod Preset`은 파드 생성 시간에 파드에 추가적인 런타임 요구사항을
파드프리셋은 파드 생성 시간에 파드에 추가적인 런타임 요구사항을
주입하기 위한 API 리소스이다.
주어진 파드 프리셋이 적용되도록 파드에 명시하기 위해서는
주어진 파드프리셋이 적용되도록 파드에 명시하기 위해서는
[레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/#레이블-셀렉터)를 사용한다.
파드 프리셋을 사용하는 것은 파드 템플릿 작성자에게 모든 파드를 위한 모든 정보를 명시적으로
파드프리셋을 사용하는 것은 파드 템플릿 작성자에게 모든 파드를 위한 모든 정보를 명시적으로
제공하지는 않아도 되도록 한다. 이렇게 하면, 어떤 특정 서비스를 사용할 파드의 파드
템플릿 작성자는 해당 서비스에 대한 모든 세부 사항을 알 필요가 없다.
그 배경에 대한 자세한 정보를 위해서는, [파드 프리셋을 위한 디자인 제안](https://git.k8s.io/community/contributors/design-proposals/service-catalog/pod-preset.md)을 참고한다.
## 클러스터에서 파드프리셋 활성화하기 {#enable-pod-preset}
클러스터에서 파드 프리셋을 사용하기 위해서는 다음 사항이 반드시 이행되어야 한다.
1. API 타입 `settings.k8s.io/v1alpha1/podpreset`을 활성화하였다.
예를 들면, 이것은 API 서버의 `--runtime-config` 옵션에 `settings.k8s.io/v1alpha1=true`을 포함하여 완료할 수 있다.
minikube에서는 클러스터가 시작할 때
`--extra-config=apiserver.runtime-config=settings.k8s.io/v1alpha1=true`
플래그를 추가한다.
1. 어드미션 컨트롤러 `PodPreset`을 활성화하였다. 이것을 이루는 방법 중 하나는
API 서버를 위해서 명시된 `--enable-admission-plugins` 옵션에 `PodPreset`을 포함하는 것이다.
minikube에서는 클러스터가 시작할 때
```shell
--extra-config=apiserver.enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,PodPreset
```
플래그를 추가한다.
## 어떻게 동작하는가
@@ -60,31 +79,12 @@ weight: 50
있을 것이다. 이 경우에는, 다음과 같은 양식으로 어노테이션을 파드 스펙에
추가한다. `podpreset.admission.kubernetes.io/exclude: "true"`.
## 파드 프리셋 활성화하기
클러스터에서 파드 프리셋을 사용하기 위해서는 다음 사항이 반드시 이행되어야 한다.
1. API 타입 `settings.k8s.io/v1alpha1/podpreset`을 활성화하였다.
예를 들면, 이것은 API 서버의 `--runtime-config` 옵션에 `settings.k8s.io/v1alpha1=true`을 포함하여 완료할 수 있다.
minikube에서는 클러스터가 시작할 때
`--extra-config=apiserver.runtime-config=settings.k8s.io/v1alpha1=true`
플래그를 추가한다.
1. 어드미션 컨트롤러 `PodPreset`을 활성화하였다. 이것을 이루는 방법 중 하나는
API 서버를 위해서 명시된 `--enable-admission-plugins` 옵션에 `PodPreset`을 포함하는 것이다.
minikube에서는 클러스터가 시작할 때
```shell
--extra-config=apiserver.enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,PodPreset
```
플래그를 추가한다.
1. 사용할 네임스페이스 안에서 `PodPreset` 오브젝트를 생성하여
파드 프리셋을 정의하였다.
{{% /capture %}}
{{% capture whatsnext %}}
* [파드 프리셋을 사용하여 파드에 데이터 주입하기](/docs/tasks/inject-data-application/podpreset/)
[파드프리셋을 사용하여 파드에 데이터 주입하기](/docs/tasks/inject-data-application/podpreset/)를 본다.
배경에 대한 자세한 정보를 위해서는, [파드프리셋을 위한 디자인 제안](https://git.k8s.io/community/contributors/design-proposals/service-catalog/pod-preset.md)을 본다.
{{% /capture %}}