Merge pull request #28174 from seokho-son/dev-1.21-ko.3-out.28

[ko] Update outdated files in dev-1.21-ko.3(M28-M36)

content/ko/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md

@@ -111,7 +111,6 @@ min-kubernetes-server-version: v1.10
     ```shell
     # mongo-75f59d57f4-4nd6q 를 당신의 파드 이름으로 대체한다.
     kubectl get pod mongo-75f59d57f4-4nd6q --template='{{(index (index .spec.containers 0).ports 0).containerPort}}{{"\n"}}'
-
     ```
 
     출력은 파드 내 MongoDB 포트 번호를 보여준다.
@@ -124,7 +123,7 @@ min-kubernetes-server-version: v1.10
 
 ## 파드의 포트를 로컬 포트로 포워딩하기
 
-1.  	`kubectl port-forward` 명령어는 파드 이름과 같이 리소스 이름을 사용하여 일치하는 파드를 선택해 포트 포워딩하는 것을 허용한다.
+1.  `kubectl port-forward` 명령어는 파드 이름과 같이 리소스 이름을 사용하여 일치하는 파드를 선택해 포트 포워딩하는 것을 허용한다.
 
 
     ```shell
@@ -177,7 +176,7 @@ min-kubernetes-server-version: v1.10
 
 3.  MongoDB 커맨드라인 프롬프트에 `ping` 명령을 입력한다.
 
-    ```shell
+    ```
     db.runCommand( { ping: 1 } )
     ```
 

content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md

@@ -1,4 +1,8 @@
 ---
+
+
+
+
 title: 웹 UI (대시보드)
 content_type: concept
 weight: 10
@@ -30,12 +34,11 @@ card:
 대시보드 UI는 기본으로 배포되지 않는다. 배포하려면 다음 커맨드를 동작한다.
 
 ```
-kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0/aio/deploy/recommended.yaml
+kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.2.0/aio/deploy/recommended.yaml
 ```
 
 ## 대시보드 UI 접근
 
-
 클러스터 데이터를 보호하기 위해, 대시보드는 기본적으로 최소한의 RBAC 설정을 제공한다.
 현재, 대시보드는 Bearer 토큰으로 로그인 하는 방법을 제공한다.
 본 시연을 위한 토큰을 생성하기 위해서는,

content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md

@@ -229,7 +229,7 @@ serverTLSBootstrap: true
 
 만약 이미 클러스터를 생성했다면 다음을 따라 이를 조정해야 한다.
  - `kube-system` 네임스페이스에서 `kubelet-config-{{< skew latestVersion >}}` 컨피그맵을 찾아서 수정한다.
-해당 컨피그맵에는 `config` 키가
+해당 컨피그맵에는 `kubelet` 키가
 [KubeletConfiguration](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)
 문서를 값으로 가진다. `serverTLSBootstrap: true` 가 되도록 KubeletConfiguration 문서를 수정한다.
 - 각 노드에서, `serverTLSBootstrap: true` 필드를 `/var/lib/kubelet/config.yaml` 에 추가한다.

content/ko/docs/tasks/job/automated-tasks-with-cron-jobs.md

@@ -1,6 +1,8 @@
 ---
 title: 크론잡(CronJob)으로 자동화된 작업 실행
 min-kubernetes-server-version: v1.21
+
+
 content_type: task
 weight: 10
 ---
@@ -144,7 +146,7 @@ kubectl delete cronjob hello
 `.spec.schedule` 은 `.spec` 의 필수 필드이다.
 이는 해당 잡이 생성되고 실행되는 스케줄 시간으로 `0 * * * *` 또는 `@hourly` 와 같이 [크론](https://ko.wikipedia.org/wiki/Cron) 형식의 문자열을 받아들인다.
 
-이 형식은 확장된 `vixie cron` 스텝(step) 값도 포함한다. 이 내용은
+이 형식은 확장된 "Vixie cron" 스텝(step) 값도 포함한다. 이 내용은
 [FreeBSD 매뉴얼](https://www.freebsd.org/cgi/man.cgi?crontab%285%29)에 설명되어 있다.
 
 > 스텝 값은 범위(range)와 함께 사용할 수 있다. 범위 뒤에 `/<number>` 를
@@ -172,8 +174,8 @@ kubectl delete cronjob hello
 이러한 방식으로 기한을 맞추지 못한 잡은 실패한 작업으로 간주된다.
 이 필드를 지정하지 않으면, 잡에 기한이 없다.
 
-`.spec.startingDeadlineSeconds` 필드가 (null이 아닌 값으로) 설정되어 있다면, 
+`.spec.startingDeadlineSeconds` 필드가 (null이 아닌 값으로) 설정되어 있다면,
-크론잡 컨트롤러는 잡 생성 완료 예상 시각과 현재 시각의 차이를 측정하고, 
+크론잡 컨트롤러는 잡 생성 완료 예상 시각과 현재 시각의 차이를 측정하고,
 시각 차이가 설정한 값보다 커지면 잡 생성 동작을 스킵한다.
 
 예를 들어, `200` 으로 설정되었다면, 잡 생성 완료 예상 시각으로부터 200초까지는 잡이 생성될 수 있다.

content/ko/docs/tasks/manage-kubernetes-objects/kustomization.md

@@ -86,6 +86,43 @@ metadata:
   name: example-configmap-1-8mbdf7882g
 ```
 
+env 파일에서 컨피그맵을 생성하려면, `configMapGenerator`의 `envs` 리스트에 항목을 추가한다. 다음은 `.env` 파일의 데이터 항목으로 컨피그맵을 생성하는 예시를 보여준다.
+
+```shell
+# .env 파일 생성
+cat <<EOF >.env
+FOO=Bar
+EOF
+
+cat <<EOF >./kustomization.yaml
+configMapGenerator:
+- name: example-configmap-1
+  envs:
+  - .env
+EOF
+```
+
+생성된 컨피그맵은 다음 명령어로 검사할 수 있다.
+
+```shell
+kubectl kustomize ./
+```
+
+생성된 컨피그맵은 다음과 같다.
+
+```yaml
+apiVersion: v1
+data:
+    FOO=Bar
+kind: ConfigMap
+metadata:
+  name: example-configmap-1-8mbdf7882g
+```
+
+{{< note >}}
+`.env` 파일의 각 변수는 생성한 컨피그맵에서 분리된 키가 된다. `.properties` 라는 이름의 파일을 내장하는 이전 예시(그리고 모든 항목들)는 단일 키를 위한 값이므로 이 예시와는 다르다.
+{{< /note >}}
+
 컨피그맵은 문자로된 키-값 쌍들로도 생성할 수 있다. 문자로된 키-값 쌍에서 컨피그맵을 생성하려면, configMapGenerator 내의 `literals` 리스트에 항목을 추가한다. 다음은 키-값 쌍을 데이터 항목으로 받는 컨피그맵을 생성하는 예제이다.
 
 ```shell

content/ko/docs/tasks/run-application/delete-stateful-set.md

@@ -1,4 +1,10 @@
 ---
+
+
+
+
+
+
 title: 스테이트풀셋(StatefulSet) 삭제하기
 content_type: task
 weight: 60
@@ -37,14 +43,14 @@ kubectl delete statefulsets <statefulset-name>
 kubectl delete service <service-name>
 ```
 
-kubectl을 통해 스테이트풀셋을 삭제하면, 스테이트풀셋의 크기가 0으로 설정되고 이로 인해 스테이트풀셋에 포함된 모든 파드가 삭제된다. 파드가 아닌 스테이트풀셋만 삭제하려면, `--cascade=false` 옵션을 사용한다. 
+kubectl을 통해 스테이트풀셋을 삭제하면, 스테이트풀셋의 크기가 0으로 설정되고 이로 인해 스테이트풀셋에 포함된 모든 파드가 삭제된다. 파드가 아닌 스테이트풀셋만 삭제하려면, `--cascade=orphan` 옵션을 사용한다.
 예시는 다음과 같다.
 
 ```shell
-kubectl delete -f <file.yaml> --cascade=false
+kubectl delete -f <file.yaml> --cascade=orphan
 ```
 
-`kubectl delete` 에 `--cascade=false` 를 사용하면 스테이트풀셋 오브젝트가 삭제된 후에도 스테이트풀셋에 의해 관리된 파드는 남게 된다. 만약 파드가 `app=myapp` 레이블을 갖고 있다면, 다음과 같이 파드를 삭제할 수 있다.
+`kubectl delete` 에 `--cascade=orphan` 를 사용하면 스테이트풀셋 오브젝트가 삭제된 후에도 스테이트풀셋에 의해 관리된 파드는 남게 된다. 만약 파드가 `app=myapp` 레이블을 갖고 있다면, 다음과 같이 파드를 삭제할 수 있다.
 
 ```shell
 kubectl delete pods -l app=myapp

content/ko/examples/application/job/redis/worker.py

@@ -8,11 +8,11 @@ host="redis"
 # import os
 # host = os.getenv("REDIS_SERVICE_HOST")
 
-q = rediswq.RedisWQ(name="job2", host="redis")
+q = rediswq.RedisWQ(name="job2", host=host)
 print("Worker with sessionID: " +  q.sessionID())
 print("Initial queue state: empty=" + str(q.empty()))
 while not q.empty():
-  item = q.lease(lease_secs=10, block=True, timeout=2) 
+  item = q.lease(lease_secs=10, block=True, timeout=2)
   if item is not None:
     itemstr = item.decode("utf-8")
     print("Working on " + itemstr)

content/ko/examples/controllers/daemonset.yaml

@@ -18,6 +18,7 @@ spec:
       # this toleration is to have the daemonset runnable on master nodes
       # remove it if your masters can't run pods
       - key: node-role.kubernetes.io/master
+        operator: Exists
         effect: NoSchedule
       containers:
       - name: fluentd-elasticsearch

content/ko/includes/task-tutorial-prereqs.md

@@ -1,6 +1,6 @@
 쿠버네티스 클러스터가 필요하고, kubectl 커맨드-라인 툴이 클러스터와
-통신할 수 있도록 설정되어 있어야 한다.
+통신할 수 있도록 설정되어 있어야 한다. 이 튜토리얼은 컨트롤 플레인 호스트가 아닌 노드가 적어도 2개 포함된 클러스터에서 실행하는 것을 추천한다. 만약, 아직 클러스터를 가지고
-만약, 아직 클러스터를 가지고 있지 않다면,
+있지 않다면,
 [minikube](/ko/docs/tasks/tools/#minikube)를 사용해서 생성하거나
 다음의 쿠버네티스 플레이그라운드 중 하나를 사용할 수 있다.