Update outdated files in dev-1.18-ko.7

content/ko/docs/concepts/containers/images.md

@@ -86,7 +86,7 @@ weight: 10
 
 이들 옵션은 아래에서 더 자세히 설명한다.
 
-### 개인 레지스트리에 인증하도록 노드 구성
+### 프라이빗 레지스트리에 인증하도록 노드 구성
 
 노드에서 도커를 실행하는 경우, 프라이빗 컨테이너 레지스트리를 인증하도록
 도커 컨테이너 런타임을 구성할 수 있다.
@@ -224,7 +224,7 @@ kubectl create secret docker-registry <name> --docker-server=DOCKER_REGISTRY_SER
 [기존 도커 자격 증명으로 시크릿 생성](/docs/tasks/configure-pod-container/pull-image-private-registry/#registry-secret-existing-credentials)에서 관련 방법을 설명하고 있다.
 
 `kubectl create secret docker-registry`는
-하나의 개인 레지스트리에서만 작동하는 시크릿을 생성하기 때문에,
+하나의 프라이빗 레지스트리에서만 작동하는 시크릿을 생성하기 때문에,
 여러 프라이빗 컨테이너 레지스트리를 사용하는 경우 특히 유용하다.
 
 {{< note >}}

content/ko/docs/concepts/overview/what-is-kubernetes.md

@@ -71,7 +71,7 @@ card:
 
 ## 쿠버네티스가 아닌 것
 
-쿠버네티스는 전통적인, 모든 것이 포함된 Platform as a Service(PaaS)가 아니다. 쿠버네티스는 하드웨어 수준보다는 컨테이너 수준에서 운영되기 때문에, PaaS가 일반적으로 제공하는 배포, 확장, 로드 밸런싱과 같은 기능을 제공하며, 사용자가 로깅, 모니터링 및 알림 솔루션을 통합할 수 있다. 하지만, 쿠버네티스는 모놀리식(monolithic)이 아니어서, 이런 기본 솔루션이 선택적이며 추가나 제거가 용이하다. 쿠버네티스는 개발자 플랫폼을 만드는 구성 요소를 제공하지만, 필요한 경우 사용자의 선택권과 유연성을 지켜준다.
+쿠버네티스는 전통적인, 모든 것이 포함된 Platform as a Service(PaaS)가 아니다. 쿠버네티스는 하드웨어 수준보다는 컨테이너 수준에서 운영되기 때문에, PaaS가 일반적으로 제공하는 배포, 스케일링, 로드 밸런싱과 같은 기능을 제공하며, 사용자가 로깅, 모니터링 및 알림 솔루션을 통합할 수 있다. 하지만, 쿠버네티스는 모놀리식(monolithic)이 아니어서, 이런 기본 솔루션이 선택적이며 추가나 제거가 용이하다. 쿠버네티스는 개발자 플랫폼을 만드는 구성 요소를 제공하지만, 필요한 경우 사용자의 선택권과 유연성을 지켜준다.
 
 쿠버네티스는:
 

content/ko/docs/concepts/overview/working-with-objects/namespaces.md

@@ -63,7 +63,7 @@ kube-system       Active   1d
    * `default` 다른 네임스페이스가 없는 오브젝트를 위한 기본 네임스페이스
    * `kube-system` 쿠버네티스 시스템에서 생성한 오브젝트를 위한 네임스페이스
    * `kube-public` 이 네임스페이스는 자동으로 생성되며 모든 사용자(인증되지 않은 사용자 포함)가 읽기 권한으로 접근할 수 있다. 이 네임스페이스는 주로 전체 클러스터 중에 공개적으로 드러나서 읽을 수 있는 리소스를 위해 예약되어 있다. 이 네임스페이스의 공개적인 성격은 단지 관례이지 요구 사항은 아니다.
-   * `kube-node-lease` 클러스터가 확장될 때 노드 하트비트의 성능을 향상시키는 각 노드와 관련된 리스(lease) 오브젝트에 대한 네임스페이스
+   * `kube-node-lease` 클러스터가 스케일링될 때 노드 하트비트의 성능을 향상시키는 각 노드와 관련된 리스(lease) 오브젝트에 대한 네임스페이스
 
 ### 요청에 네임스페이스 설정하기
 

content/ko/docs/concepts/security/overview.md

@@ -148,6 +148,6 @@ TLS를 통한 접근 | 코드가 TCP를 통해 통신해야 한다면, 미리 
 * [파드에 대한 네트워크 정책](/ko/docs/concepts/services-networking/network-policies/)
 * [클러스터 보안](/docs/tasks/administer-cluster/securing-a-cluster/)
 * [API 접근 통제](/docs/reference/access-authn-authz/controlling-access/)
-* [전송 데이터 암호화](/docs/tasks/tls/managing-tls-in-a-cluster/) for the control plane
+* 컨트롤 플레인을 위한 [전송 데이터 암호화](/docs/tasks/tls/managing-tls-in-a-cluster/)
 * [Rest에서 데이터 암호화](/docs/tasks/administer-cluster/encrypt-data/)
 * [쿠버네티스 시크릿](/docs/concepts/configuration/secret/)

content/ko/docs/concepts/storage/volume-snapshot-classes.md

@@ -6,7 +6,7 @@ weight: 30
 
 <!-- overview -->
 
-이 문서는 쿠버네티스의 `VolumeSnapshotClass` 개요를 설명한다.
+이 문서는 쿠버네티스의 볼륨스냅샷클래스(VolumeSnapshotClass) 개요를 설명한다.
 [볼륨 스냅샷](/ko/docs/concepts/storage/volume-snapshots/)과
 [스토리지 클래스](/ko/docs/concepts/storage/storage-classes)의 숙지를 추천한다.
 
@@ -17,29 +17,42 @@ weight: 30
 
 ## 소개
 
-`StorageClass` 는 관리자가 볼륨을 프로비저닝할 때 제공하는 스토리지의 "클래스"를
-설명하는 방법을 제공하는 것처럼, `VolumeSnapshotClass` 는 볼륨 스냅샷을
+스토리지클래스(StorageClass)는 관리자가 볼륨을 프로비저닝할 때 제공하는 스토리지의 "클래스"를
+설명하는 방법을 제공하는 것처럼, 볼륨스냅샷클래스는 볼륨 스냅샷을
 프로비저닝할 때 스토리지의 "클래스"를 설명하는 방법을 제공한다.
 
 ## VolumeSnapshotClass 리소스
 
-각 `VolumeSnapshotClass` 에는 클래스에 속하는 `VolumeSnapshot` 을
+각 볼륨스냅샷클래스에는 클래스에 속하는 볼륨스냅샷을
 동적으로 프로비전 할 때 사용되는 `driver`, `deletionPolicy` 그리고 `parameters`
 필드를 포함한다.
 
-`VolumeSnapshotClass` 오브젝트의 이름은 중요하며, 사용자가 특정
-클래스를 요청할 수 있는 방법이다. 관리자는 `VolumeSnapshotClass` 오브젝트를
+볼륨스냅샷클래스 오브젝트의 이름은 중요하며, 사용자가 특정
+클래스를 요청할 수 있는 방법이다. 관리자는 볼륨스냅샷클래스 오브젝트를
 처음 생성할 때 클래스의 이름과 기타 파라미터를 설정하고, 오브젝트가
 생성된 이후에는 업데이트할 수 없다.
 
-관리자는 특정 클래스의 바인딩을 요청하지 않는 볼륨스냅샷에만
-기본 `VolumeSnapshotClass` 를 지정할 수 있다.
+```yaml
+apiVersion: snapshot.storage.k8s.io/v1beta1
+kind: VolumeSnapshotClass
+metadata:
+  name: csi-hostpath-snapclass
+driver: hostpath.csi.k8s.io
+deletionPolicy: Delete
+parameters:
+```
+
+관리자는`snapshot.storage.kubernetes.io/is-default-class: "true"` 어노테이션을 추가하여
+바인딩할 특정 클래스를 요청하지 않는 볼륨스냅샷에 대한
+기본 볼륨스냅샷클래스를 지정할 수 있다.
 
 ```yaml
 apiVersion: snapshot.storage.k8s.io/v1beta1
 kind: VolumeSnapshotClass
 metadata:
   name: csi-hostpath-snapclass
+  annotations:
+    snapshot.storage.kubernetes.io/is-default-class: "true"
 driver: hostpath.csi.k8s.io
 deletionPolicy: Delete
 parameters:
@@ -52,9 +65,9 @@ parameters:
 
 ### 삭제정책(DeletionPolicy)
 
-볼륨 스냅샷 클래스는 삭제정책을 가지고 있다. 바인딩 된 `VolumeSnapshot` 오브젝트를 삭제할 때 `VolumeSnapshotContent` 의 상황을 구성할 수 있다. 볼륨 스냅삿의 삭제정책은 `Retain` 또는 `Delete` 일 수 있다. 이 필드는 반드시 지정해야 한다.
+볼륨 스냅샷 클래스는 삭제정책을 가지고 있다. 바인딩된 볼륨스냅샷 오브젝트를 삭제할 때 VolumeSnapshotContent의 상황을 구성할 수 있다. 볼륨 스냅삿의 삭제정책은 `Retain` 또는 `Delete` 일 수 있다. 이 필드는 반드시 지정해야 한다.
 
-삭제정책이 `Delete` 인 경우 기본 스토리지 스냅샷이 `VolumeSnapshotContent` 오브젝트와 함께 삭제된다. 삭제정책이 `Retain` 인 경우 기본 스냅샷과 `VolumeSnapshotContent` 모두 유지된다.
+삭제정책이 `Delete` 인 경우 기본 스토리지 스냅샷이 VolumeSnapshotContent 오브젝트와 함께 삭제된다. 삭제정책이 `Retain` 인 경우 기본 스냅샷과 VolumeSnapshotContent 모두 유지된다.
 
 ## 파라미터
 

content/ko/docs/concepts/storage/volumes.md

@@ -23,7 +23,7 @@ kubelet은 컨테이너를 재시작시키지만, 컨테이너는 깨끗한 상
 ## 배경
 
 도커는 다소 느슨하고, 덜 관리되지만
-[볼륨](https://docs.docker.com/engine/admin/volumes/)이라는
+[볼륨](https://docs.docker.com/storage/)이라는
 개념을 가지고 있다. 도커에서 볼륨은 단순한 디스크 내 디렉터리 또는
 다른 컨테이너에 있는 디렉터리다.  수명은 관리되지 않으며 최근까지는
 로컬 디스크 백업 볼륨만 있었다. 도커는 이제 볼륨 드라이버를

content/ko/docs/concepts/workloads/controllers/deployment.md

@@ -861,7 +861,12 @@ kubectl rollout status deployment.v1.apps/nginx-deployment
 ```
 Waiting for rollout to finish: 2 of 3 updated replicas are available...
 deployment.apps/nginx-deployment successfully rolled out
-$ echo $?
+```
+그리고 `kubectl rollout` 의 종료 상태는 0(success)이다.
+```shell
+echo $?
+```
+```
 0
 ```
 
@@ -1003,7 +1008,12 @@ kubectl rollout status deployment.v1.apps/nginx-deployment
 ```
 Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
 error: deployment "nginx" exceeded its progress deadline
-$ echo $?
+```
+그리고 `kubectl rollout` 의 종료 상태는 1(error를 의미함)이다.
+```shell
+echo $?
+```
+```
 1
 ```
 

content/ko/docs/concepts/workloads/controllers/garbage-collection.md

@@ -1,7 +1,7 @@
 ---
 title: 가비지(Garbage) 수집
 content_type: concept
-weight: 60
+weight: 70
 ---
 
 <!-- overview -->
@@ -10,8 +10,6 @@ weight: 60
 소유자가 없는 오브젝트들을 삭제하는 역할을 한다.
 
 
-
-
 <!-- body -->
 
 ## 소유자(owner)와 종속(dependent)
@@ -170,15 +168,9 @@ kubectl delete replicaset my-repset --cascade=false
 
 
 
-
 ## {{% heading "whatsnext" %}}
 
 
 [디자인 문서 1](https://git.k8s.io/community/contributors/design-proposals/api-machinery/garbage-collection.md)
 
 [디자인 문서 2](https://git.k8s.io/community/contributors/design-proposals/api-machinery/synchronous-garbage-collection.md)
-
-
-
-
-

content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md

@@ -1,7 +1,7 @@
 ---
 title: 완료된 리소스를 위한 TTL 컨트롤러
 content_type: concept
-weight: 65
+weight: 70
 ---
 
 <!-- overview -->
@@ -10,7 +10,7 @@ weight: 65
 
 TTL 컨트롤러는 실행이 완료된 리소스 오브젝트의 수명을
 제한하는 TTL (time to live) 메커니즘을 제공한다. TTL 컨트롤러는 현재
-[잡(Job)](/ko/docs/concepts/workloads/controllers/jobs-run-to-completion/)만
+{{< glossary_tooltip text="잡(Job)" term_id="job" >}}만
 처리하며, 파드와 커스텀 리소스와 같이 실행을 완료할 다른 리소스를
 처리하도록 확장될 수 있다.
 
@@ -29,7 +29,7 @@ kube-apiserver와 kube-controller-manager와 함께
 ## TTL 컨트롤러
 
 현재의 TTL 컨트롤러는 잡만 지원한다. 클러스터 운영자는
-[예시](/ko/docs/concepts/workloads/controllers/jobs-run-to-completion/#완료된-잡을-자동으로-정리)
+[예시](/ko/docs/concepts/workloads/controllers/job/#완료된-잡을-자동으로-정리)
 와 같이 `.spec.ttlSecondsAfterFinished` 필드를 명시하여
 완료된 잡(`완료` 또는 `실패`)을 자동으로 정리하기 위해 이 기능을 사용할 수 있다.
 리소스의 작업이 완료된 TTL 초(sec) 후 (다른 말로는, TTL이 만료되었을 때),

content/ko/docs/concepts/workloads/pods/pod-lifecycle.md

@@ -77,7 +77,7 @@ PodCondition 배열의 각 요소는 다음 여섯 가지 필드를 가질 수 
 컨테이너에서 [kubelet](/docs/admin/kubelet/)에 의해 주기적으로 수행되는 진단(diagnostic)이다.
 진단을 수행하기 위해서,
 kubelet은 컨테이너에 의해서 구현된
-[핸들러](https://godoc.org/k8s.io/kubernetes/pkg/api/v1#Handler)를 호출한다.
+[핸들러](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#handler-v1-core)를 호출한다.
 핸들러에는 다음과 같이 세 가지 타입이 있다.
 
 * [ExecAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#execaction-v1-core)
@@ -406,4 +406,3 @@ spec:
 
 
 
-

content/ko/docs/contribute/advanced.md

@@ -39,6 +39,7 @@ PR 랭글러의 임무는 다음과 같다.
   - 리뷰가 진행되었고, 병합하기 전에 추가 입력이나 조치가 필요한 PR에 `Doc Review: Open Issues` 나 `Tech Review: Open Issues` 를 할당한다.
   - 병합할 수 있는 PR에 `/lgtm` 과 `/approve` 를 할당한다.
 - PR이 준비가 되면 병합하거나, 수락해서는 안되는 PR을 닫는다.
+  - 콘텐츠가 문서의 [스타일 가이드라인](/docs/contribute/style/style-guide/) 중 일부만 충족하더라도 정확한 기술 콘텐츠를 수락하는 것이 좋다. 스타일 문제를 해결하기 위해 `good first issue` 라는 레이블로 새로운 이슈를 연다.
 - 새로운 이슈를 매일 심사하고 태그를 지정한다. SIG Docs가 메타데이터를 사용하는 방법에 대한 지침은 [이슈 심사 및 분류](/ko/docs/contribute/review/for-approvers/#이슈-심사와-분류)를 참고한다.
 
 ## 랭글러에게 유용한 GitHub 쿼리

content/ko/docs/contribute/new-content/open-a-pr.md

@@ -217,21 +217,39 @@ git에 익숙하거나, 변경 사항이 몇 줄보다 클 경우,
 
 변경 사항을 푸시하거나 풀 리퀘스트를 열기 전에 변경 사항을 로컬에서 미리 보는 것이 좋다. 미리보기를 사용하면 빌드 오류나 마크다운 형식 문제를 알아낼 수 있다.
 
-website의 도커 이미지를 만들거나 Hugo를 로컬에서 실행할 수 있다. 도커 이미지 빌드는 느리지만 [Hugo 단축코드](/docs/contribute/style/hugo-shortcodes/)를 표시하므로, 디버깅에 유용할 수 있다.
+website의 컨테이너 이미지를 만들거나 Hugo를 로컬에서 실행할 수 있다. 도커 이미지 빌드는 느리지만 [Hugo 단축코드](/docs/contribute/style/hugo-shortcodes/)를 표시하므로, 디버깅에 유용할 수 있다.
 
 {{< tabs name="tab_with_hugo" >}}
 {{% tab name="Hugo 컨테이너" %}}
 
+{{< note >}}
+아래 명령은 도커를 기본 컨테이너 엔진으로 사용한다. 이 동작을 무시하려면 `CONTAINER_ENGINE` 환경변수를 설정한다.
+{{< /note >}}
+
 1.  로컬에서 이미지를 빌드한다.
 
       ```bash
       make docker-image
+      # docker 사용(기본값)
+      make container-image
+
+      ### 또는 ###
+
+      # podman 사용
+      CONTAINER_ENGINE=podman make container-image
       ```
 
 2. 로컬에서 `kubernetes-hugo` 이미지를 빌드한 후, 사이트를 빌드하고 서비스한다.
 
       ```bash
       make docker-serve
+      # docker 사용(기본값)
+      make container-serve
+
+      ### 또는 ###
+
+      # podman 사용
+      CONTAINER_ENGINE=podman make container-serve
       ```
 
 3.  웹 브라우저에서 `https://localhost:1313` 로 이동한다. Hugo는

content/ko/docs/home/_index.md

@@ -57,6 +57,8 @@ cards:
 - name: release-notes
   title: 릴리스 노트
   description: 쿠버네티스를 설치하거나 최신의 버전으로 업그레이드하는 경우, 현재 릴리스 노트를 참고한다.
+  button: "쿠버네티스 다운로드"
+  button_path: "/docs/setup/release/notes"
 - name: about
   title: 문서에 대하여
   description: 이 웹사이트는 현재 버전과 이전 4개 버전의 쿠버네티스 문서를 포함한다.

content/ko/docs/reference/glossary/cronjob.md

@@ -11,9 +11,9 @@ tags:
 - core-object
 - workload
 ---
- 주기적인 일정에 따라 실행되는 [잡](/ko/docs/concepts/workloads/controllers/jobs-run-to-completion/)을 관리.
+ 주기적인 일정에 따라 실행되는 [잡](/ko/docs/concepts/workloads/controllers/job/)을 관리.
 
 <!--more-->
 
-*crontab* 파일의 라인과 유사하게, 크론잡 오브젝트는 [크론](https://en.wikipedia.org/wiki/Cron) 형식을 사용하여 일정을 지정한다.
+*crontab* 파일의 라인과 유사하게, 크론잡 오브젝트는 [크론](https://ko.wikipedia.org/wiki/Cron) 형식을 사용하여 일정을 지정한다.
 

content/ko/docs/reference/glossary/job.md

@@ -2,7 +2,7 @@
 title: 잡(Job)
 id: job
 date: 2018-04-12
-full_link: /docs/concepts/workloads/controllers/jobs-run-to-completion
+full_link: /docs/concepts/workloads/controllers/job
 short_description: >
   완료를 목표로 실행되는 유한 또는 배치 작업.
 

content/ko/docs/reference/kubectl/cheatsheet.md

@@ -286,6 +286,11 @@ kubectl logs -f my-pod                              # 실시간 스트림 파드
 kubectl logs -f my-pod -c my-container              # 실시간 스트림 파드 로그(stdout, 멀티-컨테이너 경우)
 kubectl logs -f -l name=myLabel --all-containers    # name이 myLabel인 모든 파드의 로그 스트리밍 (stdout)
 kubectl run -i --tty busybox --image=busybox -- sh  # 대화형 셸로 파드를 실행
+kubectl run nginx --image=nginx -n
+mynamespace                                         # 특정 네임스페이스에서 nginx 파드 실행
+kubectl run nginx --image=nginx                     # nginx 파드를 실행하고 해당 스펙을 pod.yaml 파일에 기록
+--dry-run=client -o yaml > pod.yaml
+
 kubectl attach my-pod -i                            # 실행중인 컨테이너에 연결
 kubectl port-forward my-pod 5000:6000               # 로컬 머신의 5000번 포트를 리스닝하고, my-pod의 6000번 포트로 전달
 kubectl exec my-pod -- ls /                         # 기존 파드에서 명령 실행(한 개 컨테이너 경우)