From 80b9ccd641b8c0b124747047487847a85d30db43 Mon Sep 17 00:00:00 2001
From: Nayeon Keum <rmaskdus0208@gmail.com>
Date: Thu, 25 Aug 2022 01:12:03 +0900
Subject: [PATCH] [ko] Update outdated files in dev-1.24-ko.3 (M53-M62)
 (#35876)

* [ko] Update outdated files in dev-1.24-ko.3 (M53-M62)

Signed-off-by: Nayeon Keum <rmaskdus0208@gmail.com>

* Fix anchor in Ko managing-tls-in-a-cluster.md

Signed-off-by: Nayeon Keum <rmaskdus0208@gmail.com>
Co-authored-by: Seokho Son <shsongist@gmail.com>
---
 .../debug-application/debug-statefulset.md    |  4 +-
 .../determine-reason-pod-failure.md           |  8 +++-
 .../job/automated-tasks-with-cron-jobs.md     |  2 +-
 .../imperative-command.md                     |  6 +--
 .../imperative-config.md                      | 38 +++++++++----------
 .../docs/tasks/network/validate-dual-stack.md | 16 ++++----
 .../run-application/delete-stateful-set.md    | 10 ++---
 .../tasks/tls/managing-tls-in-a-cluster.md    |  2 +-
 .../docs/tasks/tools/install-kubectl-linux.md | 11 +++++-
 9 files changed, 54 insertions(+), 43 deletions(-)

diff --git a/content/ko/docs/tasks/debug/debug-application/debug-statefulset.md b/content/ko/docs/tasks/debug/debug-application/debug-statefulset.md
index 92c5b96d59..b42951b5ec 100644
--- a/content/ko/docs/tasks/debug/debug-application/debug-statefulset.md
+++ b/content/ko/docs/tasks/debug/debug-application/debug-statefulset.md
@@ -24,11 +24,11 @@ weight: 30
 
 ## 스테이트풀셋 디버깅하기
 
-레이블이 `app=myapp`으로 지정된 스테이트풀셋 파드를 전부 나열하기 위해서는
+레이블이 `app.kubernetes.io/name=MyApp`으로 지정된 스테이트풀셋 파드를 전부 나열하기 위해서는
 다음의 명령을 사용할 수 있다.
 
 ```shell
-kubectl get pods -l app=myapp
+kubectl get pods -l app.kubernetes.io/name=MyApp
 ```
 
 만약 오랜 시간동안 `Unknown`이나 `Terminating` 상태에 있는
diff --git a/content/ko/docs/tasks/debug/debug-application/determine-reason-pod-failure.md b/content/ko/docs/tasks/debug/debug-application/determine-reason-pod-failure.md
index 40b9a24205..0ca469e212 100644
--- a/content/ko/docs/tasks/debug/debug-application/determine-reason-pod-failure.md
+++ b/content/ko/docs/tasks/debug/debug-application/determine-reason-pod-failure.md
@@ -90,8 +90,12 @@ kubectl get pod multi-container-pod -o go-template='{{range .status.containerSta
 쿠버네티스는 지정된 파일의 내용을 사용하여 컨테이너의 성공 및 실패에 대한 상태 메시지를 채운다.
 
 종료 메시지는 assertion failure 메세지처럼 간결한 최종 상태로 생성된다.
-kubelet은 4096 바이트보다 긴 메시지를 자른다. 모든 컨테이너의 총 메시지 길이는
-12KiB로 제한된다. 기본 종료 메시지 경로는 `/dev/termination-log`이다.
+kubelet은 4096 바이트보다 긴 메시지를 자른다. 
+
+모든 컨테이너의 총 메시지 길이는 12KiB로 제한되며, 각 컨테이너에 균등하게 분할된다. 
+예를 들어, 12개의 컨테이너(`initContainers` 또는 `containers`)가 있는 경우 각 컨테이너에는 1024 바이트의 사용 가능한 종료 메시지 공간이 있다.
+
+기본 종료 메시지 경로는 `/dev/termination-log`이다.
 파드가 시작된 후에는 종료 메시지 경로를 설정할 수 없다.
 
 다음의 예제에서 컨테이너는, 쿠버네티스가 조회할 수 있도록
diff --git a/content/ko/docs/tasks/job/automated-tasks-with-cron-jobs.md b/content/ko/docs/tasks/job/automated-tasks-with-cron-jobs.md
index c9020cc3d5..a582f80d8a 100644
--- a/content/ko/docs/tasks/job/automated-tasks-with-cron-jobs.md
+++ b/content/ko/docs/tasks/job/automated-tasks-with-cron-jobs.md
@@ -141,7 +141,7 @@ kubectl delete cronjob hello
 크론잡(CronJob)의 각 매니페스트에는 [`.spec`](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/#오브젝트-명세-spec-와-상태-status) 섹션도 필요하다.
 
 {{< note >}}
-크론잡(CrontJob)을 수정한 경우, 수정 후 새로 실행하는 작업부터 적용된다. 이미 시작된 작업(및 해당 파드)은 변경 없이 계속 실행된다. 즉, 크론잡(CrontJob)은 기존 작업이 계속 실행 중이라면, 작업을 변경하지 _않는다._
+크론잡(CronJob)을 수정한 경우, 수정 후 새로 실행하는 작업부터 적용된다. 이미 시작된 작업(및 해당 파드)은 변경 없이 계속 실행된다. 즉, 크론잡(CronJob)은 기존 작업이 계속 실행 중이라면, 작업을 변경하지 _않는다._
 {{< /note >}}
 
 ### 스케줄
diff --git a/content/ko/docs/tasks/manage-kubernetes-objects/imperative-command.md b/content/ko/docs/tasks/manage-kubernetes-objects/imperative-command.md
index 8b4d5afe36..86f5dd2745 100644
--- a/content/ko/docs/tasks/manage-kubernetes-objects/imperative-command.md
+++ b/content/ko/docs/tasks/manage-kubernetes-objects/imperative-command.md
@@ -158,14 +158,14 @@ kubectl create --edit -f /tmp/srv.yaml
 ```
 
 1. `kubectl create service` 커맨드는 서비스에 대한 구성을 생성하고 이를 `/tmp/srv.yaml`에 저장한다.
-1. `kubectl create --edit` 커맨드는 오브젝트를 생성하기 전에 편집을 위해 구성파일을 열어준다.
+1. `kubectl create --edit` 커맨드는 오브젝트를 생성하기 전에 편집을 위해 구성 파일을 열어준다.
 
 
 
 ## {{% heading "whatsnext" %}}
 
 
-* [오브젝트 구성을 이용하여 쿠버네티스 관리하기(명령형)](/ko/docs/tasks/manage-kubernetes-objects/imperative-config/)
-* [오브젝트 구성을 이용하여 쿠버네티스 관리하기(선언형)](/ko/docs/tasks/manage-kubernetes-objects/declarative-config/)
+* [구성 파일을 이용한 명령형 쿠버네티스 오브젝트 관리](/ko/docs/tasks/manage-kubernetes-objects/imperative-config/)
+* [구성 파일을 이용한 쿠버네티스 오브젝트의 선언형 관리](/ko/docs/tasks/manage-kubernetes-objects/declarative-config/)
 * [Kubectl 커맨드 참조](/docs/reference/generated/kubectl/kubectl-commands/)
 * [쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
diff --git a/content/ko/docs/tasks/manage-kubernetes-objects/imperative-config.md b/content/ko/docs/tasks/manage-kubernetes-objects/imperative-config.md
index 678814de3d..b186432d85 100644
--- a/content/ko/docs/tasks/manage-kubernetes-objects/imperative-config.md
+++ b/content/ko/docs/tasks/manage-kubernetes-objects/imperative-config.md
@@ -1,13 +1,13 @@
 ---
-title: 구성파일을 이용한 명령형 쿠버네티스 오브젝트 관리
+title: 구성 파일을 이용한 명령형 쿠버네티스 오브젝트 관리
 content_type: task
 weight: 40
 ---
 
 <!-- overview -->
-쿠버네티스 오브젝트는 YAML 또는 JSON으로 작성된 오프젝트 구성파일과 함께 `kubectl`
+쿠버네티스 오브젝트는 YAML 또는 JSON으로 작성된 오프젝트 구성 파일과 함께 `kubectl`
 커맨드 라인 툴을 이용하여 생성, 업데이트 및 삭제할 수 있다.
-이 문서는 구성파일을 이용하여 어떻게 오브젝트를 정의하고 관리할 수 있는지에 대해 설명한다.
+이 문서는 구성 파일을 이용하여 어떻게 오브젝트를 정의하고 관리할 수 있는지에 대해 설명한다.
 
 
 ## {{% heading "prerequisites" %}}
@@ -34,7 +34,7 @@ weight: 40
 
 ## 오브젝트 생성 방법
 
-구성파일로부터 오브젝트를 생성하기 위해 `kubectl create -f`를 사용할 수 있다.
+구성 파일로부터 오브젝트를 생성하기 위해 `kubectl create -f`를 사용할 수 있다.
 보다 상세한 정보는 [쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)를
 참조한다.
 
@@ -44,22 +44,22 @@ weight: 40
 
 {{< warning >}}
 `replace` 커맨드로 오브젝트를 업데이트 하게되면,
-구성파일에 정의되지 않은 스펙의 모든 부분이 삭제된다. 이는
-`externalIPs`필드가 구성파일로부터 독립적으로 관리되는
+구성 파일에 정의되지 않은 스펙의 모든 부분이 삭제된다. 이는
+`externalIPs`필드가 구성 파일로부터 독립적으로 관리되는
 `LoadBalancer`타입의 서비스와 같이, 클러스터 의해 부분적으로
 관리되는 스펙의 오브젝트와 함께 사용되어서는 안된다.
 독립적으로 관리되는 필드는 `replace`로 삭제되는 것을 방지하기 위해
-구성파일에 복사되어져야만 한다.
+구성 파일에 복사되어져야만 한다.
 {{< /warning >}}
 
-구성파일에 따라 활성 오브젝트를 업데이트하기 위해 `kubectl replace -f`
+구성 파일에 따라 활성 오브젝트를 업데이트하기 위해 `kubectl replace -f`
 를 사용할 수 있다.
 
 * `kubectl replace -f <파일명|url>`
 
 ## 오브젝트 삭제 방법
 
-구성파일에 정의한 오브젝트를 삭제하기 위해 `kubectl delete -f`를
+구성 파일에 정의한 오브젝트를 삭제하기 위해 `kubectl delete -f`를
 사용할 수 있다.
 
 * `kubectl delete -f <파일명|url>`
@@ -78,7 +78,7 @@ kubectl delete <type> -l <label>
 
 ## 오브젝트 확인 방법
 
-구성파일에 정의한 오브젝트에 관한 정보 확인을 위해 `kubectl get -f`
+구성 파일에 정의한 오브젝트에 관한 정보 확인을 위해 `kubectl get -f`
 명령을 사용할 수 있다.
 
 * `kubectl get -f <파일명|url> -o yaml`
@@ -89,16 +89,16 @@ kubectl delete <type> -l <label>
 ## 제약사항
 
 `create`, `replace`, 그리고 `delete` 명령은 각 오브젝트의 구성이
-그 구성파일 내에 완전하게 정의되고 기록되어질 경우 잘 동작한다.
-그러나 활성 오브젝트가 업데이트 되고, 구성파일 안에 병합되지 않으면,
+그 구성 파일 내에 완전하게 정의되고 기록되어질 경우 잘 동작한다.
+그러나 활성 오브젝트가 업데이트 되고, 구성 파일 안에 병합되지 않으면,
 업데이트 내용은 다음번 `replace`가 실행될 때 삭제될 것이다.
 이는 HorizontalPodAutoscaler와 같은 컨트롤러가
 활성 오브젝트를 직접적으로 업데이트하도록 할 경우 발생한다.
 여기 예시가 있다.
 
-1. 구성파일로부터 오브젝트를 생성할 경우
+1. 구성 파일로부터 오브젝트를 생성할 경우
 1. 또 다른 소스가 일부 필드를 변경함으로써 오브젝트가 업데이트 되는 경우
-1. 구성파일로부터 오브젝트를 대체할 경우. 스텝 2에서의
+1. 구성 파일로부터 오브젝트를 대체할 경우. 스텝 2에서의
 다른 소스에 의해 이루어진 변경은 유실된다.
 
 동일 오브젝트에 대해 여러 명의 작성자들로부터의 지원이 필요한 경우, 오브젝트를 관리하기 위해
@@ -106,9 +106,9 @@ kubectl delete <type> -l <label>
 
 ## 구성 저장 없이 URL로부터 오브젝트 생성과 편집하기
 
-구성파일에 대한 URL을 가진다고 가정해보자.
+구성 파일에 대한 URL을 가진다고 가정해보자.
 `kubectl create --edit`을 사용하여 오브젝트가 생성되기 전에
-구성을 변경할 수 있다. 이는 독자가 수정할 수 있는 구성파일을
+구성을 변경할 수 있다. 이는 독자가 수정할 수 있는 구성 파일을
 가르키는 튜토리얼과 작업에 특히 유용하다.
 
 ```shell
@@ -120,13 +120,13 @@ kubectl create -f <url> --edit
 령형 커맨드에서 명령형 오브젝트 구성으로 전환하기 위해
 몇 가지 수동 단계를 포함한다.
 
-1. 다음과 같이 활성 오브젝트를 로컬 오브젝트 구성파일로 내보낸다.
+1. 다음과 같이 활성 오브젝트를 로컬 오브젝트 구성 파일로 내보낸다.
 
     ```shell
     kubectl get <종류>/<이름> -o yaml > <종류>_<이름>.yaml
     ```
 
-1. 수동으로 오브젝트 구성파일에서 상태 필드를 제거한다.
+1. 수동으로 오브젝트 구성 파일에서 상태 필드를 제거한다.
 
 1. 이후 오브젝트 관리를 위해, `replace`만 사용한다.
 
@@ -161,6 +161,6 @@ template:
 
 
 * [명령형 커맨드를 이용한 쿠버네티스 오브젝트 관리하기](/ko/docs/tasks/manage-kubernetes-objects/imperative-command/)
-* [오브젝트 구성을 이용하여 쿠버네티스 오브젝트 관리하기 (선언형)](/ko/docs/tasks/manage-kubernetes-objects/declarative-config/)
+* [구성 파일을 이용한 쿠버네티스 오브젝트의 선언형 관리](/ko/docs/tasks/manage-kubernetes-objects/declarative-config/)
 * [Kubectl 커맨드 참조](/docs/reference/generated/kubectl/kubectl-commands/)
 * [쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
diff --git a/content/ko/docs/tasks/network/validate-dual-stack.md b/content/ko/docs/tasks/network/validate-dual-stack.md
index 36730ac66b..7e3754a24e 100644
--- a/content/ko/docs/tasks/network/validate-dual-stack.md
+++ b/content/ko/docs/tasks/network/validate-dual-stack.md
@@ -134,7 +134,7 @@ spec:
     protocol: TCP
     targetPort: 9376
   selector:
-    app: MyApp
+    app.kubernetes.io/name: MyApp
   sessionAffinity: None
   type: ClusterIP
 status:
@@ -158,7 +158,7 @@ apiVersion: v1
 kind: Service
 metadata:
   labels:
-    app: MyApp
+    app.kubernetes.io/name: MyApp
   name: my-service
 spec:
   clusterIP: fd00::5118
@@ -172,7 +172,7 @@ spec:
     protocol: TCP
     targetPort: 80
   selector:
-    app: MyApp
+    app.kubernetes.io/name: MyApp
   sessionAffinity: None
   type: ClusterIP
 status:
@@ -187,7 +187,7 @@ status:
 `kubectl get svc` 명령어는 오직 `CLUSTER-IP` 필드에 주요 IP만 표시한다.
 
 ```shell
- kubectl get svc -l app=MyApp
+ kubectl get svc -l app.kubernetes.io/name: MyApp
 
 NAME         TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGE
 my-service   ClusterIP   10.0.216.242   <none>        80/TCP    5s
@@ -197,15 +197,15 @@ my-service   ClusterIP   10.0.216.242   <none>        80/TCP    5s
 서비스가 `kubectl describe` 를 사용하여 IPv4 및 IPv6 주소 블록에서 클러스터 IP를 가져오는지 확인한다. 그런 다음 IP 및 포트를 통해 서비스에 대한 접속을 확인할 수 있다.
 
 ```shell
-kubectl describe svc -l app=MyApp
+kubectl describe svc -l app.kubernetes.io/name: MyApp
 ```
 
 ```
 Name:              my-service
 Namespace:         default
-Labels:            app=MyApp
+Labels:            app.kubernetes.io/name: MyApp
 Annotations:       <none>
-Selector:          app=MyApp
+Selector:          app.kubernetes.io/name: MyApp
 Type:              ClusterIP
 IP Family Policy:  PreferDualStack
 IP Families:       IPv4,IPv6
@@ -227,7 +227,7 @@ Events:            <none>
 Check the Service:
 
 ```shell
-kubectl get svc -l app=MyApp
+kubectl get svc -l app.kubernetes.io/name: MyApp
 ```
 
 서비스가 IPv6 주소 블록에서 `CLUSTER-IP` 주소 및 `EXTERNAL-IP` 주소를 할당받는지 검증한다. 그리고 나서 IP 및 포트로 서비스 접근이 가능한지 검증할 수 있다.
diff --git a/content/ko/docs/tasks/run-application/delete-stateful-set.md b/content/ko/docs/tasks/run-application/delete-stateful-set.md
index 8aeb8aa67b..82914bd0a7 100644
--- a/content/ko/docs/tasks/run-application/delete-stateful-set.md
+++ b/content/ko/docs/tasks/run-application/delete-stateful-set.md
@@ -50,10 +50,10 @@ kubectl을 통해 스테이트풀셋을 삭제하면, 스테이트풀셋의 크
 kubectl delete -f <file.yaml> --cascade=orphan
 ```
 
-`kubectl delete` 에 `--cascade=orphan` 를 사용하면 스테이트풀셋 오브젝트가 삭제된 후에도 스테이트풀셋에 의해 관리된 파드는 남게 된다. 만약 파드가 `app=myapp` 레이블을 갖고 있다면, 다음과 같이 파드를 삭제할 수 있다.
+`kubectl delete` 에 `--cascade=orphan` 를 사용하면 스테이트풀셋 오브젝트가 삭제된 후에도 스테이트풀셋에 의해 관리된 파드는 남게 된다. 만약 파드가 `app.kubernetes.io/name=MyApp` 레이블을 갖고 있다면, 다음과 같이 파드를 삭제할 수 있다.
 
 ```shell
-kubectl delete pods -l app=myapp
+kubectl delete pods -l app.kubernetes.io/name=MyApp
 ```
 
 ### 퍼시스턴트볼륨(PersistentVolume)
@@ -70,13 +70,13 @@ PVC를 삭제할 때 데이터 손실될 수 있음에 주의하자.
 
 ```shell
 grace=$(kubectl get pods <stateful-set-pod> --template '{{.spec.terminationGracePeriodSeconds}}')
-kubectl delete statefulset -l app=myapp
+kubectl delete statefulset -l app.kubernetes.io/name=MyApp
 sleep $grace
-kubectl delete pvc -l app=myapp
+kubectl delete pvc -l app.kubernetes.io/name=MyApp
 
 ```
 
-위의 예에서 파드에는 `app=myapp` 라는 레이블이 있다. 사용자에게 적절한 레이블로 대체하자.
+위의 예에서 파드에는 `app.kubernetes.io/name=MyApp` 라는 레이블이 있다. 사용자에게 적절한 레이블로 대체하자.
 
 ### 스테이트풀셋 파드의 강제 삭제
 
diff --git a/content/ko/docs/tasks/tls/managing-tls-in-a-cluster.md b/content/ko/docs/tasks/tls/managing-tls-in-a-cluster.md
index 8a67143f54..6f0f415056 100644
--- a/content/ko/docs/tasks/tls/managing-tls-in-a-cluster.md
+++ b/content/ko/docs/tasks/tls/managing-tls-in-a-cluster.md
@@ -355,7 +355,7 @@ CSR이 다음 두 가지 요구 사항을 충족하는지 확인하는 것이다
 [인증서 서명 요청](/docs/reference/access-authn-authz/certificate-signing-requests/) 레퍼런스 페이지를 
 참조한다.
 
-## 서명을 제공하도록 클러스터 구성하기 {#a-note-to-cluster-administrators}
+## 서명을 제공하도록 클러스터 구성하기
 
 이 페이지에서는 서명자가 인증서 API를 제공하도록 설정되었다고 가정한다. 쿠버네티스 
 컨트롤러 관리자는 서명자의 기본 구현을 제공한다. 이를 
diff --git a/content/ko/docs/tasks/tools/install-kubectl-linux.md b/content/ko/docs/tasks/tools/install-kubectl-linux.md
index bb7605fde4..d0782fab65 100644
--- a/content/ko/docs/tasks/tools/install-kubectl-linux.md
+++ b/content/ko/docs/tasks/tools/install-kubectl-linux.md
@@ -112,6 +112,10 @@ card:
    sudo apt-get update
    sudo apt-get install -y apt-transport-https ca-certificates curl
    ```
+   Debian 9(stretch) 또는 그 이전 버전을 사용하는 경우 `apt-transport-https`도 설치해야 한다.
+   ```shell
+   sudo apt-get install -y apt-transport-https
+   ```
 
 2. 구글 클라우드 공개 사이닝 키를 다운로드한다.
 
@@ -134,7 +138,8 @@ card:
 
 {{% /tab %}}
 
-{{< tab name="레드햇 기반의 배포판" codelang="bash" >}}
+{{% tab name="레드햇 기반의 배포판" %}}
+```bash
 cat <<EOF | sudo tee /etc/yum.repos.d/kubernetes.repo
 [kubernetes]
 name=Kubernetes
@@ -144,7 +149,9 @@ gpgcheck=1
 gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
 EOF
 sudo yum install -y kubectl
-{{< /tab >}}
+```
+
+{{% /tab %}}
 {{< /tabs >}}
 
 ### 다른 패키지 관리 도구를 사용하여 설치 {#install-using-other-package-management}