Merge pull request #27530 from jihoon-seo/210413-Update-outdated-files-of-dev-1.20-ko.7

[ko] Update outdated files in dev-1.21-ko.1 branch (p1)
This commit is contained in:
Kubernetes Prow Robot 2021-04-21 03:52:10 -07:00 committed by GitHub
commit b073f3ee73
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
14 changed files with 52 additions and 46 deletions

View File

@ -2,7 +2,7 @@
title: 확장을 사용한 병렬 처리
content_type: task
min-kubernetes-server-version: v1.8
weight: 20
weight: 50
---
<!-- overview -->

View File

@ -111,8 +111,8 @@ kubectl edit ds/fluentd-elasticsearch -n kube-system
##### 컨테이너 이미지만 업데이트
데몬셋 템플릿에서 컨테이너 이미지를 업데이트해야 하는
경우(예: `.spec.template.spec.containers[*].image`), `kubectl set image` 를 사용한다.
데몬셋 템플릿(예: `.spec.template.spec.containers[*].image`)에 의해 정의된 컨테이너 이미지만 업데이트하려면,
`kubectl set image` 를 사용한다.
```shell
kubectl set image ds/fluentd-elasticsearch fluentd-elasticsearch=quay.io/fluentd_elasticsearch/fluentd:v2.6.0 -n kube-system
@ -168,7 +168,7 @@ kubectl get pods -l name=fluentd-elasticsearch -o wide -n kube-system
데몬셋 롤아웃이 진행되지 않는다.
이 문제를 해결하려면, 데몬셋 템플릿을 다시 업데이트한다. 이전의 비정상 롤아웃으로 인해
새로운 롤아웃이 차단되지 않는다.
새로운 롤아웃이 차단되지 않는다.
#### 클럭 차이(skew)

View File

@ -13,7 +13,7 @@ description: 클러스터의 노드별로 리소스로 사용할 GPU를 구성
쿠버네티스는 AMD 및 NVIDIA GPU(그래픽 프로세싱 유닛)를 노드들에 걸쳐 관리하기 위한 **실험적인**
지원을 포함한다.
이 페이지는 다른 쿠버네티스 버전 간에 걸쳐 사용자가 GPU들을 소비할 수 있는 방법과
이 페이지는 여러 쿠버네티스 버전에서 사용자가 GPU를 활용할 수 있는 방법과
현재의 제약 사항을 설명한다.
@ -37,7 +37,7 @@ description: 클러스터의 노드별로 리소스로 사용할 GPU를 구성
`nvidia.com/gpu` 를 스케줄 가능한 리소스로써 노출시킨다.
사용자는 이 GPU들을 `cpu``memory` 를 요청하는 방식과 동일하게
`<vendor>.com/gpu` 를 요청함으로써 컨테이너를 통해 소비할 수 있다.
`<vendor>.com/gpu` 를 요청함으로써 컨테이너에서 활용할 수 있다.
그러나 GPU를 사용할 때는 리소스 요구 사항을 명시하는 방식에 약간의
제약이 있다.

View File

@ -37,8 +37,8 @@ kubectl delete statefulsets <statefulset-name>
kubectl delete service <service-name>
```
kubectl을 통해 스테이트풀셋을 삭제하면 0으로 스케일이 낮아지고, 스테이트풀셋에 포함된 모든 파드가 삭제된다.
파드가 아닌 스테이트풀셋만 삭제하려면, `--cascade=false` 를 사용한다.
kubectl을 통해 스테이트풀셋을 삭제하면, 스테이트풀셋의 크기가 0으로 설정되고 이로 인해 스테이트풀셋에 포함된 모든 파드가 삭제된다. 파드가 아닌 스테이트풀셋만 삭제하려면, `--cascade=false` 옵션을 사용한다.
예시는 다음과 같다.
```shell
kubectl delete -f <file.yaml> --cascade=false

View File

@ -381,7 +381,7 @@ object:
외부 메트릭 사용시, 먼저 모니터링 시스템에 대한 이해가 있어야 한다.
이 설치는 사용자 정의 메트릭과 유사하다.
외부 메트릭을 사용하면 모니터링 시스템의 사용 가능한 메트릭에 기반하여 클러스터를 오토스케일링 할 수 있다.
위의 예제처럼 `name``selector`를 갖는 `metric` 블록을 제공하고,
위의 예제처럼 `name``selector`를 갖는 `metric` 블록을 명시하고,
`Object` 대신에 `External` 메트릭 타입을 사용한다.
만일 여러 개의 시계열이 `metricSelector`와 일치하면, HorizontalPodAutoscaler가 값의 합을 사용한다.
외부 메트릭들은 `Value``AverageValue` 대상 타입을 모두 지원하고,

View File

@ -23,9 +23,7 @@ Pod Autoscaler는 크기를 조정할 수 없는 오브젝트(예: 데몬셋(Dae
Horizontal Pod Autoscaler는 쿠버네티스 API 리소스 및 컨트롤러로 구현된다.
리소스는 컨트롤러의 동작을 결정한다.
컨트롤러는 관찰된 평균 CPU 사용률이 사용자가 지정한 대상과 일치하도록 레플리케이션
컨트롤러 또는 디플로이먼트에서 레플리카 개수를 주기적으로 조정한다.
컨트롤러는 평균 CPU 사용률, 평균 메모리 사용률 또는 다른 커스텀 메트릭과 같은 관찰 대상 메트릭이 사용자가 지정한 목표값과 일치하도록 레플리케이션 컨트롤러 또는 디플로이먼트에서 레플리카 개수를 주기적으로 조정한다.
@ -355,7 +353,7 @@ API에 접속하려면 클러스터 관리자는 다음을 확인해야 한다.
## 구성가능한 스케일링 동작 지원
[v1.18](https://github.com/kubernetes/enhancements/blob/master/keps/sig-autoscaling/20190307-configurable-scale-velocity-for-hpa.md)
[v1.18](https://github.com/kubernetes/enhancements/blob/master/keps/sig-autoscaling/853-configurable-hpa-scale-velocity/README.md)
부터 `v2beta2` API는 HPA `behavior` 필드를 통해
스케일링 동작을 구성할 수 있다.
동작은 `behavior` 필드 아래의 `scaleUp` 또는 `scaleDown`

View File

@ -17,9 +17,9 @@ no_list: true
`kubectl` 은 다양한 리눅스 플랫폼, macOS, 그리고 윈도우에 설치할 수 있다.
각각에 대한 설치 가이드는 다음과 같다.
- [리눅스에 `kubectl` 설치하기](install-kubectl-linux)
- [macOS에 `kubectl` 설치하기](install-kubectl-macos)
- [윈도우에 `kubectl` 설치하기](install-kubectl-windows)
- [리눅스에 `kubectl` 설치하기](/ko/docs/tasks/tools/install-kubectl-linux/)
- [macOS에 `kubectl` 설치하기](/ko/docs/tasks/tools/install-kubectl-macos/)
- [윈도우에 `kubectl` 설치하기](/ko/docs/tasks/tools/install-kubectl-windows/)
## kind

View File

@ -27,6 +27,8 @@ content_type: concept
## 구성
* [예제: Java 마이크로서비스 구성하기](/ko/docs/tutorials/configuration/configure-java-microservice/)
* [컨피그 맵을 사용해서 Redis 설정하기](/ko/docs/tutorials/configuration/configure-redis-using-configmap/)
## 상태 유지를 하지 않는(stateless) 애플리케이션

View File

@ -322,7 +322,7 @@ Events:
23s 23s 1 {kubelet e2e-test-stclair-node-pool-t1f5} Warning AppArmor Cannot enforce AppArmor: profile "k8s-apparmor-example-allow-write" is not loaded
```
파드 상태는 Failed이며 오류메시지는 `Pod Cannot enforce AppArmor: profile
파드 상태는 Pending이며, 오류 메시지는 `Pod Cannot enforce AppArmor: profile
"k8s-apparmor-example-allow-write" is not loaded`이다. 이벤트도 동일한 메시지로 기록되었다.
## 관리 {#administration}

View File

@ -48,7 +48,7 @@ Katacode는 무료로 브라우저에서 쿠버네티스 환경을 제공한다.
{{< kat-button >}}
{{< note >}}
minikube를 로컬에 설치했다면 `minikube start`를 실행한다.
minikube를 로컬에 설치했다면 `minikube start`를 실행한다. `minikube dashboard` 명령을 실행하기 전에, 새 터미널을 열고, 그 터미널에서 `minikube dashboard` 명령을 실행한 후, 원래의 터미널로 돌아온다.
{{< /note >}}
2. 브라우저에서 쿠버네티스 대시보드를 열어보자.
@ -154,7 +154,7 @@ minikube dashboard --url
`k8s.gcr.io/echoserver` 이미지 내의 애플리케이션 코드는 TCP 포트 8080에서만 수신한다. `kubectl expose`
사용하여 다른 포트를 노출한 경우, 클라이언트는 다른 포트에 연결할 수 없다.
2. 방금 생성한 서비스 살펴보기
2. 생성한 서비스 살펴보기
```shell
kubectl get services
@ -229,7 +229,7 @@ minikube 툴은 활성화하거나 비활성화할 수 있고 로컬 쿠버네
metrics-server was successfully enabled
```
3. 방금 생성한 파드와 서비스를 확인한다.
3. 생성한 파드와 서비스를 확인한다.
```shell
kubectl get pod,svc -n kube-system

View File

@ -434,7 +434,7 @@ web-4 0/1 ContainerCreating 0 0s
web-4 1/1 Running 0 19s
```
스테이트풀셋 컨트롤러는 레플리카개수를 스케일링한다.
스테이트풀셋 컨트롤러는 레플리카 개수를 스케일링한다.
[스테이트풀셋 생성](#차례대로-파드-생성하기)으로 스테이트풀셋 컨트롤러는
각 파드을 순차적으로 각 순번에 따라 생성하고 후속 파드 시작 전에
이전 파드가 Running과 Ready 상태가 될 때까지
@ -1067,9 +1067,10 @@ statefulset "web" deleted
### Parallel 파드 관리
`Parallel` 파드 관리는 스테이트풀셋 컨트롤러가 모든 파드를
병렬로 시작하고 종료하는 것으로 다른 파드를 시작/종료하기 전에
병렬로 시작하고 종료하는 것으로, 다른 파드를 시작/종료하기 전에
파드가 Running과 Ready 상태로 전환되거나 완전히 종료되기까지
기다리지 않음을 뜻한다.
이 옵션은 스케일링 동작에만 영향을 미치며, 업데이트 동작에는 영향을 미치지 않는다.
{{< codenew file="application/web/web-parallel.yaml" >}}
@ -1114,7 +1115,7 @@ web-1 1/1 Running 0 10s
스테이트풀셋 컨트롤러는 `web-0``web-1`를 둘 다 동시에 시작했다.
두 번째 터미널을 열어 놓고 다른 터미널창에서 스테이트풀셋을
스케일링 하자.
스케일링하자.
```shell
kubectl scale statefulset/web --replicas=4

View File

@ -49,13 +49,15 @@ min-kubernetes-server-version: v1.14
1. 매니페스트 파일을 다운로드한 디렉터리에서 터미널 창을 시작한다.
1. `mongo-deployment.yaml` 파일을 통해 MongoDB 디플로이먼트에 적용한다.
<!--
콘텐츠에 대한 로컬 테스트는 파일의 상대 경로로 한다.
kubectl apply -f ./content/en/examples/application/guestbook/mongo-deployment.yaml
-->
```shell
kubectl apply -f https://k8s.io/examples/application/guestbook/mongo-deployment.yaml
```
<!--
컨텐츠에 대한 로컬 테스트는 파일의 상대경로로 한다.
kubectl apply -f ./content/en/examples/application/guestbook/mongo-deployment.yaml
-->
1. 파드의 목록을 질의하여 MongoDB 파드가 실행 중인지 확인한다.
@ -84,14 +86,15 @@ kubectl apply -f ./content/en/examples/application/guestbook/mongo-deployment.ya
1. `mongo-service.yaml` 파일을 통해 MongoDB 서비스에 적용한다.
<!--
콘텐츠에 대한 로컬 테스트는 파일의 상대 경로로 한다.
kubectl apply -f ./content/en/examples/application/guestbook/mongo-service.yaml
-->
```shell
kubectl apply -f https://k8s.io/examples/application/guestbook/mongo-service.yaml
```
<!--
컨텐츠에 대한 로컬 테스트는 파일의 상대경로로 한다.
kubectl apply -f ./content/en/examples/application/guestbook/mongo-service.yaml
-->
1. 서비스의 목록을 질의하여 MongoDB 서비스가 실행 중인지 확인한다.
@ -122,14 +125,15 @@ kubectl apply -f ./content/en/examples/application/guestbook/mongo-service.yaml
1. `frontend-deployment.yaml` 파일을 통해 프론트엔드의 디플로이먼트에 적용한다.
<!--
콘텐츠에 대한 로컬 테스트는 파일의 상대 경로로 한다.
kubectl apply -f ./content/en/examples/application/guestbook/frontend-deployment.yaml
-->
```shell
kubectl apply -f https://k8s.io/examples/application/guestbook/frontend-deployment.yaml
```
<!--
컨텐츠에 대한 로컬 테스트는 파일의 상대경로로 한다.
kubectl apply -f ./content/en/examples/application/guestbook/frontend-deployment.yaml
-->
1. 파드의 목록을 질의하여 세 개의 프론트엔드 복제본이 실행되고 있는지 확인한다.
@ -160,14 +164,15 @@ Google Compute Engine 또는 Google Kubernetes Engine과 같은 일부 클라우
1. `frontend-service.yaml` 파일을 통해 프론트엔드 서비스에 적용시킨다.
<!--
콘텐츠에 대한 로컬 테스트는 파일의 상대 경로로 한다.
kubectl apply -f ./content/en/examples/application/guestbook/frontend-service.yaml
-->
```shell
kubectl apply -f https://k8s.io/examples/application/guestbook/frontend-service.yaml
```
<!--
컨텐츠에 대한 로컬 테스트는 파일의 상대경로로 한다.
kubectl apply -f ./content/en/examples/application/guestbook/frontend-service.yaml
-->
1. 서비스의 목록을 질의하여 프론트엔드 서비스가 실행 중인지 확인한다.
@ -179,7 +184,7 @@ kubectl apply -f ./content/en/examples/application/guestbook/frontend-service.ya
```
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
frontend ClusterIP 10.0.0.112 <none> 80/TCP 6s
frontend ClusterIP 10.0.0.112 <none> 80/TCP 6s
kubernetes ClusterIP 10.0.0.1 <none> 443/TCP 4m
mongo ClusterIP 10.0.0.151 <none> 6379/TCP 2m
```
@ -214,8 +219,8 @@ kubectl apply -f ./content/en/examples/application/guestbook/frontend-service.ya
결과는 아래와 같은 형태로 나타난다.
```
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
frontend ClusterIP 10.51.242.136 109.197.92.229 80:32372/TCP 1m
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
frontend LoadBalancer 10.51.242.136 109.197.92.229 80:32372/TCP 1m
```
1. IP 주소를 복사하고, 방명록을 보기 위해 브라우저에서 페이지를 로드한다.
@ -245,7 +250,7 @@ kubectl apply -f ./content/en/examples/application/guestbook/frontend-service.ya
frontend-3823415956-k22zn 1/1 Running 0 54m
frontend-3823415956-w9gbt 1/1 Running 0 54m
frontend-3823415956-x2pld 1/1 Running 0 5s
mongo-1068406935-3lswp 1/1 Running 0 56m
mongo-1068406935-3lswp 1/1 Running 0 56m
```
1. 프론트엔드 파드의 수를 축소하기 위해 아래 명령어를 실행한다.
@ -266,7 +271,7 @@ kubectl apply -f ./content/en/examples/application/guestbook/frontend-service.ya
NAME READY STATUS RESTARTS AGE
frontend-3823415956-k22zn 1/1 Running 0 1h
frontend-3823415956-w9gbt 1/1 Running 0 1h
mongo-1068406935-3lswp 1/1 Running 0 1h
mongo-1068406935-3lswp 1/1 Running 0 1h
```

View File

@ -1,4 +1,4 @@
apiVersion: batch/v1beta1
apiVersion: batch/v1
kind: CronJob
metadata:
name: hello

View File

@ -27,7 +27,7 @@ spec:
selector:
app: zk
---
apiVersion: policy/v1beta1
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
name: zk-pdb