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

Ko: 1st Korean l10n work for release-1.20

Browse Source 
- Translate reference/glossary/persistent-volume.md in Korean (#25474)
- Update outdated files in the dev-1.20-ko.1 branch (1) (#25576)
- Translate blog/dont-panic-kubernetes-and-docker into Korean (#25596)
- Update outdated files in the dev-1.20-ko.1 branch(3) (#25728)
- Ko: enhance tutorials//cluster-intro translation (#25754)
- Fix Outdated files in the dev-1.20-ko.1 branch (2) (#25765)

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: santachopa <santachopa@naver.com>
Co-authored-by: SEUNGHYUN KO <kosehy@gmail.com>
Co-authored-by: June Yi <gochist@gmail.com>
This commit is contained in:
Jerry Park
2020-12-14 00:16:04 +00:00
committed by seokho-son
parent 8fd80c3e35
commit 0ed380d4aa
60 changed files with 1290 additions and 731 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/ko/docs/concepts/workloads/controllers/cron-jobs.md
+8 -2
View File
@@ -28,8 +28,6 @@ kube-controller-manager 컨테이너에 설정된 시간대는
11자를 자동으로 추가하고, 작업 이름의 최대 길이는
63자라는 제약 조건이 있기 때문이다.
<!-- body -->
## 크론잡
@@ -78,6 +76,14 @@ Cannot determine if job needs to be started. Too many missed start time (> 100).
크론잡은 오직 그 일정에 맞는 잡 생성에 책임이 있고,
잡은 그 잡이 대표하는 파드 관리에 책임이 있다.
## 새 컨트롤러
쿠버네티스 1.20부터 알파 기능으로 사용할 수 있는 크론잡 컨트롤러의 대체 구현이 있다. 크론잡 컨트롤러의 버전 2를 선택하려면, 다음의 [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/) 플래그를 {{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}}에 전달한다.
```
--feature-gates="CronJobControllerV2=true"
```
## {{% heading "whatsnext" %}}
content/ko/docs/concepts/workloads/controllers/daemonset.md
-6
View File
@@ -81,12 +81,6 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
만약 `.spec.selector` 를 명시하면, 이것은 `.spec.template.metadata.labels` 와 일치해야 한다. 일치하지 않는 구성은 API에 의해 거부된다.
또한 일반적으로 다른 데몬셋이나 레플리카셋과 같은 다른 컨트롤러를 통해 직접적으로
레이블이 셀렉터와 일치하는 다른 파드를 생성하지 않아야 한다. 그렇지 않으면 데몬셋
{{< glossary_tooltip term_id="controller" text="컨트롤러" >}}는 해당 파드가 생성된 것으로 생각한다. 쿠버네티스는 이런 일을 하는 것을
막지 못한다. 사용자가 이와 같은 일을 하게 되는 한 가지 경우는 테스트를 목적으로 한 노드에서 다른 값을 가지는 파드들을
수동으로 생성하는 것이다.
### 오직 일부 노드에서만 파드 실행
만약 `.spec.template.spec.nodeSelector` 를 명시하면 데몬셋 컨트롤러는
content/ko/docs/concepts/workloads/controllers/deployment.md
+4 -4
View File
@@ -95,7 +95,7 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml
`.spec.replicas` 필드에 따라 의도한 레플리카의 수가 3개인지 알 수 있다.
3. 디플로이먼트의 롤아웃 상태를 보려면, `kubectl rollout status deployment.v1.apps/nginx-deployment` 를 실행한다.
3. 디플로이먼트의 롤아웃 상태를 보려면, `kubectl rollout status deployment/nginx-deployment` 를 실행한다.
다음과 유사하게 출력된다.
```
@@ -194,7 +194,7 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml
2. 롤아웃 상태를 보려면 다음을 실행한다.
```shell
kubectl rollout status deployment.v1.apps/nginx-deployment
kubectl rollout status deployment/nginx-deployment
```
이와 유사하게 출력된다.
@@ -373,7 +373,7 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성
```shell
kubectl rollout status deployment.v1.apps/nginx-deployment
kubectl rollout status deployment/nginx-deployment
```
이와 유사하게 출력된다.
@@ -850,7 +850,7 @@ nginx-deployment-618515232 11 11 11 7m
만약 롤아웃이 성공적으로 완료되면 `kubectl rollout status` 는 종료 코드로 0이 반환된다.
```shell
kubectl rollout status deployment.v1.apps/nginx-deployment
kubectl rollout status deployment/nginx-deployment
```
이와 유사하게 출력된다.
```
content/ko/docs/concepts/workloads/controllers/garbage-collection.md
+16 -5
View File
@@ -59,11 +59,22 @@ metadata:
```
{{< note >}}
교차 네임스페이스(cross-namespace)의 소유자 참조는 디자인상 허용되지 않는다. 이는 다음을 의미한다.
1) 네임스페이스 범위의 종속 항목은 동일한 네임스페이스의 소유자와
클러스터 범위의 소유자만 지정할 수 있다.
2) 클러스터 범위의 종속 항목은 클러스터 범위의 소유자만 지정할 수 있으며,
네임스페이스 범위의 소유자는 불가하다.
교차 네임스페이스(cross-namespace)의 소유자 참조는 디자인상 허용되지 않는다.
네임스페이스 종속 항목은 클러스터 범위 또는 네임스페이스 소유자를 지정할 수 있다.
네임스페이스 소유자는 **반드시** 종속 항목과 동일한 네임스페이스에 있어야 한다.
그렇지 않은 경우, 소유자 참조는 없는 것으로 처리되며, 소유자가 없는 것으로 확인되면
종속 항목이 삭제될 수 있다.
클러스터 범위의 종속 항목은 클러스터 범위의 소유자만 지정할 수 있다.
v1.20 이상에서 클러스터 범위의 종속 항목이 네임스페이스 종류를 소유자로 지정하면,
확인할 수 없는 소유자 참조가 있는 것으로 처리되고 가비지 수집이 될 수 없다.
v1.20 이상에서 가비지 수집기가 잘못된 교차 네임스페이스 `ownerReference`
또는 네임스페이스 종류를 참조하는 `ownerReference` 가 있는 클러스터 범위의 종속 항목을 감지하면,
`OwnerRefInvalidNamespace` 의 원인이 있는 경고 이벤트와 유효하지 않은 종속 항목의 `involvedObject` 가 보고된다.
`kubectl get events -A --field-selector=reason=OwnerRefInvalidNamespace` 를 실행하여
이러한 종류의 이벤트를 확인할 수 있다.
{{< /note >}}
## 가비지 수집기의 종속 항목 삭제 방식 제어
content/ko/docs/concepts/workloads/pods/_index.md
-1
View File
@@ -255,7 +255,6 @@ kubelet은 자동으로 각 정적 파드에 대한 쿠버네티스 API 서버
## {{% heading "whatsnext" %}}
* [파드의 라이프사이클](/ko/docs/concepts/workloads/pods/pod-lifecycle/)에 대해 알아본다.
* [PodPresets](/ko/docs/concepts/workloads/pods/podpreset/)에 대해 알아본다.
* [런타임클래스(RuntimeClass)](/ko/docs/concepts/containers/runtime-class/)와 이를 사용하여
다양한 컨테이너 런타임 구성으로 다양한 파드를 설정하는 방법에 대해 알아본다.
* [파드 토폴로지 분배 제약 조건](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/)에 대해 읽어본다.
content/ko/docs/concepts/workloads/pods/ephemeral-containers.md
+1 -1
View File
@@ -87,7 +87,7 @@ API에서 특별한 `ephemeralcontainers` 핸들러를 사용해서 만들어지
{{< /note >}}
이 섹션의 예시는 임시 컨테이너가 어떻게 API에 나타나는지
보여준다. 일반적으로 `kubectl alpha debug` 또는
보여준다. 일반적으로 `kubectl debug` 또는
다른 `kubectl` [플러그인](/ko/docs/tasks/extend-kubectl/kubectl-plugins/)을
사용해서 API를 직접 호출하지 않고 이런 단계들을 자동화 한다.
content/ko/docs/concepts/workloads/pods/pod-lifecycle.md
+1 -1
View File
@@ -316,7 +316,7 @@ kubelet은 실행 중인 컨테이너들에 대해서 선택적으로 세 가지
### 언제 스타트업 프로브를 사용해야 하는가?
{{< feature-state for_k8s_version="v1.18" state="beta" >}}
{{< feature-state for_k8s_version="v1.20" state="stable" >}}
스타트업 프로브는 서비스를 시작하는 데 오랜 시간이 걸리는 컨테이너가 있는
파드에 유용하다. 긴 활성 간격을 설정하는 대신, 컨테이너가 시작될 때
content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
+19 -2
View File
@@ -310,6 +310,7 @@ profiles:
- maxSkew: 1
topologyKey: topology.kubernetes.io/zone
whenUnsatisfiable: ScheduleAnyway
defaultingType: List
```
{{< note >}}
@@ -322,9 +323,9 @@ profiles:
#### 내부 기본 제약
{{< feature-state for_k8s_version="v1.19" state="alpha" >}}
{{< feature-state for_k8s_version="v1.20" state="beta" >}}
`DefaultPodTopologySpread` 기능 게이트를 활성화하면, 기존
기본적으로 활성화된 `DefaultPodTopologySpread` 기능 게이트를 사용하면, 기존
`SelectorSpread` 플러그인이 비활성화된다.
kube-scheduler는 `PodTopologySpread` 플러그인 구성에 다음과 같은
기본 토폴로지 제약 조건을 사용한다.
@@ -351,6 +352,22 @@ defaultConstraints:
없는 노드에 점수를 매기지 않는다.
{{< /note >}}
클러스터에 기본 파드 분배 제약 조건을 사용하지 않으려면,
`PodTopologySpread` 플러그인 구성에서 `defaultingType` 을 `List` 로 설정하고
`defaultConstraints` 를 비워두어 기본값을 비활성화할 수 있다.
```yaml
apiVersion: kubescheduler.config.k8s.io/v1beta1
kind: KubeSchedulerConfiguration
profiles:
- pluginConfig:
- name: PodTopologySpread
args:
defaultConstraints: []
defaultingType: List
```
## 파드어피니티(PodAffinity)/파드안티어피니티(PodAntiAffinity)와의 비교
쿠버네티스에서 "어피니티(Affinity)"와 관련된 지침은 파드가
content/ko/docs/concepts/workloads/pods/podpreset.md
-89
View File
@@ -1,89 +0,0 @@
---
title: 파드 프리셋
content_type: concept
weight: 50
---
<!-- overview -->
{{< feature-state for_k8s_version="v1.6" state="alpha" >}}
이 페이지는 파드프리셋(PodPreset)에 대한 개요를 제공한다. 파드프리셋은 파드 생성 시간에 파드에
특정 정보를 주입하기 위한 오브젝트이다. 해당 정보에는
시크릿, 볼륨, 볼륨 마운트, 환경 변수가 포함될 수 있다.
<!-- body -->
## 파드 프리셋 이해하기
파드프리셋은 파드 생성 시간에 파드에 추가적인 런타임 요구사항을
주입하기 위한 API 리소스이다.
주어진 파드프리셋이 적용되도록 파드에 명시하기 위해서는
[레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/#레이블-셀렉터)를 사용한다.
파드프리셋을 사용하는 것은 파드 템플릿 작성자에게 모든 파드를 위한 모든 정보를 명시적으로
제공하지는 않아도 되도록 한다. 이렇게 하면, 어떤 특정 서비스를 사용할 파드의 파드
템플릿 작성자는 해당 서비스에 대한 모든 세부 사항을 알 필요가 없다.
## 클러스터에서 파드프리셋 활성화하기 {#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
```
플래그를 추가한다.
## 어떻게 동작하는가
쿠버네티스는 어드미션 컨트롤러(`PodPreset`)를 제공한다. 어드미션 컨트롤러가 활성화되면,
파드 프리셋을 파드 생성 요청에 적용한다.
파드 생성 요청이 발생하면, 시스템은 다음의 내용을 수행한다.
1. 사용 가능한 모든 `PodPresets`을 검색한다.
1. `PodPreset`의 레이블 셀렉터들 중 하나라도 생성되는 파드의 레이블과 일치하는
것이 있는지 확인한다.
1. `PodPreset`에 의해서 정의된 다양한 리소스가 생성되는 파드에
병합되도록 시도한다.
1. 오류 시, 파드의 병합 오류를 문서화하는 이벤트를 발생시키고, `PodPreset`으로
부터 주입된 어떤 리소스도 _없이_ 파드를 생성한다.
1. 수정된 파드 스펙의 결과에 어노테이션을 달아 `PodPreset`에 의해서
수정되었음을 표시한다. 해당 어노테이션은 다음의 양식을 따른다.
`podpreset.admission.kubernetes.io/podpreset-<파드-프리셋 이름>: "<리소스 버전>"`.
각 파드는 0개 이상의 파드프리셋에 일치될 수 있고, 각 파드프리셋은 0개 이상의
파드에 적용될 수 있다. 하나의 파드프리셋이 한 개 이상의 파드에 적용되었을
때, 쿠버네티스는 해당 파드의 스펙을 수정한다. `env`, `envFrom`, `volumeMounts`의
변경에 대해서는, 쿠버네티스가 파드 내의 모든 컨테이너의 컨테이너 스펙을
수정한다. `volume` 변경에 대해서는, 쿠버네티스는 해당 파드의 스펙을 수정한다.
{{< note >}}
파드 프리셋은 적절한 경우 파드 스펙의 다음 필드를 수정할 수도 있다.
- `.spec.containers` 필드
- `.spec.initContainers` 필드
{{< /note >}}
### 특정 파드의 파드 프리셋 비활성화하기
어떠한 파드 프리셋 변이에 의해서도 파드에 변경이 일어나지 않게 하고 싶은 경우가
있을 것이다. 이 경우에는, 다음과 같은 양식으로 어노테이션을 파드의 `.spec` 에
추가한다. `podpreset.admission.kubernetes.io/exclude: "true"`.
## {{% heading "whatsnext" %}}
[파드프리셋을 사용하여 파드에 데이터 주입하기](/docs/tasks/inject-data-application/podpreset/)를 본다.
배경에 대한 자세한 정보를 위해서는, [파드프리셋을 위한 디자인 제안](https://git.k8s.io/community/contributors/design-proposals/service-catalog/pod-preset.md)을 본다.