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

Fifth Korean l10n work for release 1.17 (#19335)

Browse Source 
* Update to Outdated files in dev-1.17-ko.5 branch. (#19145)
* Translate apiserver-aggregation into Korean (#19168)
* Translate storage/volumes.md in Korean. (#18594)
* Reflect new docs reference links since dev-1.17-ko.1 (#19159)

Co-authored-by: Yuk, Yongsu <ysyukr@gmail.com>
Co-authored-by: Yoon <learder@gmail.com>
Co-authored-by: June Yi <june.yi@samsung.com>
Co-authored-by: Claudia J.Kang <claudiajkang@gmail.com>
Co-authored-by: Seokho Son <shsongist@gmail.com>

Co-authored-by: Yuk, Yongsu <ysyukr@gmail.com>
Co-authored-by: Yoon <learder@gmail.com>
Co-authored-by: Claudia J.Kang <claudiajkang@gmail.com>
Co-authored-by: Seokho Son <shsongist@gmail.com>
This commit is contained in:
June Yi
2020-02-28 11:56:38 +09:00
committed by GitHub
parent 66a8d34a4d
commit f9a9884c0c
58 changed files with 2014 additions and 570 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/ko/docs/tasks/access-application-cluster/access-cluster.md
+1 -1
View File
@@ -352,7 +352,7 @@ redirect 기능은 deprecated되고 제거 되었다. 대신 (아래의) proxy
- 노드, 파드, 서비스에 접근하는 데 사용될 수 있다
- 서비스에 접근하는 데 사용되면 load balacing한다
1. [kube proxy](/docs/concepts/services-networking/service/#ips-and-vips):
1. [kube proxy](/ko/docs/concepts/services-networking/service/#ips-and-vips):
- 각 노드 상에서 실행된다
- UDP와 TCP를 proxy한다
content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md
+1 -1
View File
@@ -79,7 +79,7 @@ Kubeconfig 인증 방법은 외부 아이덴티티 프로파이더 또는 x509
클러스터에 의도한 파드의 수를 유지하기 위해서 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)가 생성될 것이다.
- **서비스(Service)** (선택): 일부 애플리케이션의 경우, (예를 들어, 프론트엔드) 아마도 클러스터 바깥의 퍼블릭 IP 주소를 가진 (외부 서비스) 외부에 [서비스(Service)](/docs/concepts/services-networking/service/)를 노출 시키고 싶을 수 있다. 외부 서비스들을 위해, 한개 또는 여러 개의 포트들을 열어 둘 필요가 있다. [이 곳](/docs/tasks/access-application-cluster/configure-cloud-provider-firewall/) 내용을 참고한다.
- **서비스(Service)** (선택): 일부 애플리케이션의 경우, (예를 들어, 프론트엔드) 아마도 클러스터 바깥의 퍼블릭 IP 주소를 가진 (외부 서비스) 외부에 [서비스(Service)](/ko/docs/concepts/services-networking/service/)를 노출 시키고 싶을 수 있다. 외부 서비스들을 위해, 한개 또는 여러 개의 포트들을 열어 둘 필요가 있다. [이 곳](/docs/tasks/access-application-cluster/configure-cloud-provider-firewall/) 내용을 참고한다.
클러스터 내부에서만 보고 싶은 어떤 서비스(Serivce)들이 있을 것인다. 이를 내부 서비스라고 한다.
content/ko/docs/tasks/debug-application-cluster/resource-usage-monitoring.md
+1 -1
View File
@@ -8,7 +8,7 @@ title: 리소스 모니터링 도구
애플리케이션을 스케일하여 신뢰할 수 있는 서비스를 제공하려면,
애플리케이션이 배포되었을 때 애플리케이션이 어떻게 동작하는지를 이해해야 한다.
컨테이너, [파드](/ko/docs/concepts/workloads/pods/pod),
[서비스](/docs/concepts/services-networking/service), 그리고 전체 클러스터의 특성을
[서비스](/ko/docs/concepts/services-networking/service), 그리고 전체 클러스터의 특성을
검사하여 쿠버네티스 클러스터 내의 애플리케이션 성능을 검사할 수 있다. 쿠버네티스는 각 레벨에서
애플리케이션의 리소스 사용량에 대한 상세 정보를 제공한다.
이 정보는 애플리케이션의 성능을 평가하고
content/ko/docs/tasks/manage-kubernetes-objects/declarative-config.md
+8 -1
View File
@@ -81,7 +81,14 @@ kubectl apply -f <디렉터리>/
kubectl diff -f https://k8s.io/examples/application/simple_deployment.yaml
```
{{< note >}}
`diff`는 `kube-apiserver`의 활성화가 필요한 [서버사이드 dry-run](/docs/reference/using-api/api-concepts/#dry-run)을 사용한다.
`diff`는 `kube-apiserver`의 활성화가 필요한
[서버사이드 dry-run](/docs/reference/using-api/api-concepts/#dry-run)을 사용한다.
`diff` 는 dry-run 모드에서 서버 측 적용 요청을 수행하므로,
`PATCH`, `CREATE`, 그리고 `UPDATE` 권한을 부여해야 한다.
자세한 것은
[Dry-Run 인증](/docs/reference/using-api/api-concepts#dry-run-authorization)을 본다.
{{< /note >}}
`kubectl apply`를 사용하여 오브젝트를 생성한다.
content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
+8 -3
View File
@@ -57,14 +57,19 @@ index.php는 CPU 과부하 연산을 수행한다.
?>
```
첫 번째 단계로, 실행 중인 이미지의 디플로이먼트를 시작하고 서비스로 노출시킨다.
첫 번째 단계로, 다음 구성을 사용해서 실행 중인 이미지의 디플로이먼트를
시작하고 서비스로 노출시킨다.
{{< codenew file="application/php-apache.yaml" >}}
다음의 명령어를 실행한다.
```shell
kubectl run php-apache --image=k8s.gcr.io/hpa-example --requests=cpu=200m --limits=cpu=500m --expose --port=80
kubectl apply -f https://k8s.io/examples/application/php-apache.yaml
```
```
service/php-apache created
deployment.apps/php-apache created
service/php-apache created
```
## Horizontal Pod Autoscaler 생성
content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md
+8 -162
View File
@@ -158,15 +158,11 @@ HorizontalPodAutoscaler에 여러 메트릭이 지정된 경우, 이 계산은
현재 값보다 높은 `desiredReplicas` 을 제공하는 경우
HPA가 여전히 확장할 수 있음을 의미한다.
마지막으로, HPA가 목표를 스케일하기 직전에 스케일 권장 사항이
기록된다. 컨트롤러는 구성 가능한 창(window) 내에서 가장 높은 권장
사항을 선택하도록 해당 창 내의 모든 권장 사항을 고려한다. 이 값은
`--horizontal-pod-autoscaler-downscale-stabilization` 플래그 또는 HPA 오브젝트
동작 `behavior.scaleDown.stabilizationWindowSeconds` ([구성가능한
스케일링 동작 지원](#구성가능한-스케일링-동작-지원)을 본다)을
사용하여 설정할 수 있고, 기본 값은 5분이다.
즉, 스케일 다운이 점진적으로 발생하여 급격히 변동하는 메트릭 값의
영향을 완만하게 한다.
마지막으로, HPA가 목표를 스케일하기 직전에 스케일 권장 사항이 기록된다.
컨트롤러는 구성 가능한 창(window) 내에서 가장 높은 권장 사항을 선택하도록 해당 창 내의
모든 권장 사항을 고려한다. 이 값은 `--horizontal-pod-autoscaler-downscale-stabilization` 플래그를 사용하여 설정할 수 있고, 기본 값은 5분이다.
즉, 스케일 다운이 점진적으로 발생하여 급격히 변동하는
메트릭 값의 영향을 완만하게 한다.
## API 오브젝트
@@ -213,6 +209,9 @@ Horizontal Pod Autoscaler를 사용하여 레플리카 그룹의 스케일을
평가된 메트릭의 동적인 특징 때문에 레플리카 수가
자주 변동할 수 있다. 이것은 때로는 *스래싱 (thrashing)* 이라고도 한다.
v1.6 부터 클러스터 운영자는 `kube-controller-manager` 컴포넌트의 플래그로
노출된 글로벌 HPA 설정을 튜닝하여 이 문제를 완화할 수 있다.
v1.12부터는 새로운 알고리즘 업데이트가 업스케일 지연에 대한
필요성을 제거하였다.
@@ -229,11 +228,6 @@ v1.12부터는 새로운 알고리즘 업데이트가 업스케일 지연에 대
있다.
{{< /note >}}
v1.17 부터 v2beta2 API 필드에서 `behavior.scaleDown.stabilizationWindowSeconds`
를 설정하여 다운스케일 안정화 창을 HPA별로 설정할 수 있다.
[구성가능한 스케일링
동작 지원](#구성가능한-스케일링-동작-지원)을 본다.
## 멀티 메트릭을 위한 지원
Kubernetes 1.6은 멀티 메트릭을 기반으로 스케일링을 지원한다. `autoscaling/v2beta2` API
@@ -284,154 +278,6 @@ API에 접속하려면 클러스터 관리자는 다음을 확인해야 한다.
어떻게 사용하는지에 대한 예시는 [커스텀 메트릭 사용하는 작업 과정](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#autoscaling-on-multiple-metrics-and-custom-metrics)과
[외부 메트릭스 사용하는 작업 과정](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#autoscaling-on-metrics-not-related-to-kubernetes-objects)을 참조한다.
## 구성가능한 스케일링 동작 지원
[v1.17](https://github.com/kubernetes/enhancements/blob/master/keps/sig-autoscaling/20190307-configurable-scale-velocity-for-hpa.md)
부터 `v2beta2` API는 HPA `behavior` 필드를 통해
스케일링 동작을 구성할 수 있다.
동작은 `behavior` 필드 아래의 `scaleUp` 또는 `scaleDown`
섹션에서 스케일링 업과 다운을 위해 별도로 지정된다. 안정화 윈도우는
스케일링 대상에서 레플리카 수의 플래핑(flapping)을 방지하는
양방향에 대해 지정할 수 있다. 마찬가지로 스케일링 정책을 지정하면
스케일링 중 레플리카 변경 속도를 제어할 수 있다.
### 스케일링 정책
스펙의 `behavior` 섹션에 하나 이상의 스케일링 폴리시를 지정할 수 있다.
폴리시가 여러 개 지정된 경우 가장 많은 양의 변경을
허용하는 정책이 기본적으로 선택된 폴리시이다. 다음 예시는 스케일 다운 중 이
동작을 보여준다.
```yaml
behavior:
scaleDown:
policies:
- type: Pods
value: 4
periodSeconds: 60
- type: Percent
value: 10
periodSeconds: 60
```
파드 수가 40개를 초과하면 두 번째 폴리시가 스케일링 다운에 사용된다.
예를 들어 80개의 레플리카가 있고 대상을 10개의 레플리카로 축소해야 하는
경우 첫 번째 단계에서 8개의 레플리카가 스케일 다운 된다. 레플리카의 수가 72개일 때
다음 반복에서 파드의 10%는 7.2 이지만, 숫자는 8로 올림된다. 오토스케일러 컨트롤러의
각 루프에서 변경될 파드의 수는 현재 레플리카의 수에 따라 재계산된다. 레플리카의 수가 40
미만으로 떨어지면 첫 번째 폴리시 _(파드들)_ 가 적용되고 한번에
4개의 레플리카가 줄어든다.
`periodSeconds` 는 폴리시가 참(true)으로 유지되어야 하는 기간을 나타낸다.
첫 번째 정책은 1분 내에 최대 4개의 레플리카를 스케일 다운할 수 있도록 허용한다.
두 번째 정책은 현재 레플리카의 최대 10%를 1분 내에 스케일 다운할 수 있도록 허용한다.
확장 방향에 대해 `selectPolicy` 필드를 확인하여 폴리시 선택을 변경할 수 있다.
레플리카의 수를 최소로 변경할 수 있는 폴리시를 선택하는 `최소(Min)`로 값을 설정한다.
값을 `Disabled` 로 설정하면 해당 방향으로 스케일링이 완전히
비활성화 된다.
### 안정화 윈도우
안정화 윈도우는 스케일링에 사용되는 메트릭이 계속 변동할 때 레플리카의 플래핑을
다시 제한하기 위해 사용된다. 안정화 윈도우는 스케일링을 방지하기 위해 과거부터
계산된 의도한 상태를 고려하는 오토스케일링 알고리즘에 의해 사용된다.
다음의 예시에서 `scaleDown` 에 대해 안정화 윈도우가 지정되어있다.
```yaml
scaleDown:
stabilizationWindowSeconds: 300
```
메트릭이 대상을 축소해야하는 것을 나타내는 경우 알고리즘은
이전에 계산된 의도한 상태를 살펴보고 지정된 간격의 최고 값을 사용한다.
위의 예시에서 지난 5분 동안 모든 의도한 상태가 고려된다.
### 기본 동작
사용자 지정 스케일링을 사용하려면 일부 필드를 지정해야 한다. 사용자 정의해야
하는 값만 지정할 수 있다. 이러한 사용자 지정 값은 기본값과 병합된다. 기본값은 HPA
알고리즘의 기존 동작과 일치한다.
```yaml
behavior:
scaleDown:
stabilizationWindowSeconds: 300
policies:
- type: Percent
value: 100
periodSeconds: 15
scaleUp:
stabilizationWindowSeconds: 0
policies:
- type: Percent
value: 100
periodSeconds: 15
- type: Pods
value: 4
periodSeconds: 15
selectPolicy: Max
```
안정화 윈도우의 스케일링 다운의 경우 _300_ 초(또는 제공된
경우`--horizontal-pod-autoscaler-downscale-stabilization` 플래그의 값)이다. 스케일링 다운에서는 현재
실행 중인 레플리카의 100%를 제거할 수 있는 단일 정책만 있으며, 이는 스케일링
대상을 최소 허용 레플리카로 축소할 수 있음을 의미한다.
스케일링 업에는 안정화 윈도우가 없다. 메트릭이 대상을 스케일 업해야 한다고 표시된다면 대상이 즉시 스케일 업된다.
두 가지 폴리시가 있다. HPA가 정상 상태에 도달 할 때까지 15초 마다
4개의 파드 또는 현재 실행 중인 레플리카의 100% 가 추가된다.
### 예시: 다운스케일 안정화 윈도우 변경
사용자 지정 다운스케일 안정화 윈도우를 1분 동안 제공하기 위해
다음 동작이 HPA에 추가된다.
```yaml
behavior:
scaleDown:
stabilizationWindowSeconds: 60
```
### 예시: 스케일 다운 비율 제한
HPA에 의해 파드가 제거되는 속도를 분당 10%로 제한하기 위해
다음 동작이 HPA에 추가된다.
```yaml
behavior:
scaleDown:
policies:
- type: Percent
value: 10
periodSeconds: 60
```
마지막으로 5개의 파드를 드롭하기 위해 다른 폴리시를 추가하고, 최소 선택
전략을 추가할 수 있다.
```yaml
behavior:
scaleDown:
policies:
- type: Percent
value: 10
periodSeconds: 60
- type: Pods
value: 5
periodSeconds: 60
selectPolicy: Max
```
### 예시: 스케일 다운 비활성화
`selectPolicy` 의 `Disabled` 값은 주어진 방향으로의 스케일링을 끈다.
따라서 다운 스케일링을 방지하기 위해 다음 폴리시가 사용된다.
```yaml
behavior:
scaleDown:
selectPolicy: Disabled
```
{{% /capture %}}
{{% capture whatsnext %}}
content/ko/docs/tasks/tools/install-minikube.md
+11 -3
View File
@@ -74,9 +74,17 @@ kubectl이 설치되었는지 확인한다. kubectl은 [kubectl 설치하고 설
• [VirtualBox](https://www.virtualbox.org/wiki/Downloads)
{{< note >}}
Minikube는 쿠버네티스 컴포넌트를 VM이 아닌 호스트에서도 동작하도록 `--vm-driver=none` 옵션도 지원한다. 이 드라이버를 사용하려면 [도커](https://www.docker.com/products/docker-desktop) 와 Linux 환경이 필요하지만, 하이퍼바이저는 필요하지 않는다. none 드라이버를 사용하려면 [도커](https://www.docker.com/products/docker-desktop) 에서 도커를 apt로 설치하기를 사용하는 것을 권장한다. 도커의 스냅 설치는 minikube에서 작동하지 않는다.
{{< /note >}}
Minikube는 쿠버네티스 컴포넌트를 VM이 아닌 호스트에서도 동작하도록 `--vm-driver=none` 옵션도 지원한다.
이 드라이버를 사용하려면 [도커](https://www.docker.com/products/docker-desktop) 와 Linux 환경이 필요하지만, 하이퍼바이저는 필요하지 않다.
데비안(Debian) 또는 파생된 배포판에서 `none` 드라이버를 사용하는 경우,
Minikube에서는 동작하지 않는 스냅 패키지 대신 도커용 `.deb` 패키지를 사용한다.
[도커](https://www.docker.com/products/docker-desktop)에서 `.deb` 패키지를 다운로드 할 수 있다.
{{< caution >}}
`none` VM 드라이버는 보안과 데이터 손실 이슈를 일으킬 수 있다.
`--vm-driver=none` 을 사용하기 전에 [이 문서](https://minikube.sigs.k8s.io/docs/reference/drivers/none/)를 참조해서 더 자세한 내용을 본다.
{{< /caution >}}
### 패키지를 이용하여 Minikube 설치