Update to Outdated files in the dev-1.18-ko.1 branch.

content/ko/docs/concepts/architecture/nodes.md

@@ -180,7 +180,7 @@ kubelet은 `NodeStatus` 와 리스 오브젝트를 생성하고 업데이트 할
   보다 훨씬 길다).
 - kubelet은 10초마다 리스 오브젝트를 생성하고 업데이트 한다(기본 업데이트 주기).
   리스 업데이트는 `NodeStatus` 업데이트와는
-  독립적으로 발생한다.
+  독립적으로 발생한다. 리스 업데이트가 실패하면 kubelet에 의해 재시도하며 7초로 제한된 지수 백오프를 200 밀리초에서 부터 시작한다.
 
 #### 안정성
 

content/ko/docs/concepts/cluster-administration/cluster-administration-overview.md

@@ -41,7 +41,7 @@ weight: 10
 
 * [인증서](/docs/concepts/cluster-administration/certificates/)는 다른 툴 체인을 이용하여 인증서를 생성하는 방법을 설명한다.
 
-* [쿠버네티스 컨테이너 환경](/ko/docs/concepts/containers/container-environment-variables/)은 쿠버네티스 노드에서 Kubelet에 의해 관리되는 컨테이너 환경에 대해 설명한다.
+* [쿠버네티스 컨테이너 환경](/ko/docs/concepts/containers/container-environment/)은 쿠버네티스 노드에서 Kubelet에 의해 관리되는 컨테이너 환경에 대해 설명한다.
 
 * [쿠버네티스 API에 대한 접근 제어](/docs/reference/access-authn-authz/controlling-access/)는 사용자와 서비스 계정에 어떻게 권한 설정을 하는지 설명한다.
 

content/ko/docs/concepts/configuration/assign-pod-node.md

@@ -315,7 +315,7 @@ spec:
             topologyKey: "kubernetes.io/hostname"
       containers:
       - name: web-app
-        image: nginx:1.12-alpine
+        image: nginx:1.16-alpine
 ```
 
 만약 위의 두 디플로이먼트를 생성하면 세 개의 노드가 있는 클러스터는 다음과 같아야 한다.

content/ko/docs/concepts/containers/container-lifecycle-hooks.md

@@ -113,7 +113,7 @@ Events:
 
 {{% capture whatsnext %}}
 
-* [컨테이너 환경](/ko/docs/concepts/containers/container-environment-variables/)에 대해 더 배우기.
+* [컨테이너 환경](/ko/docs/concepts/containers/container-environment/)에 대해 더 배우기.
 * [컨테이너 라이프사이클 이벤트에 핸들러 부착](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)
   실습 경험하기.
 

content/ko/docs/concepts/containers/runtime-class.md

@@ -10,22 +10,14 @@ weight: 20
 
 이 페이지는 런타임 클래스(RuntimeClass) 리소스와 런타임 선택 메커니즘에 대해서 설명한다.
 
-{{< warning >}}
-런타임클래스는 v1.14 베타 업그레이드에서 *중대한* 변화를 포함한다.
-런타임클래스를 v1.14 이전부터 사용하고 있었다면,
-[런타임 클래스를 알파에서 베타로 업그레이드하기](#upgrading-runtimeclass-from-alpha-to-beta)를 확인한다.
-{{< /warning >}}
+런타임클래스는 컨테이너 런타임을 구성을 선택하는 기능이다. 컨테이너 런타임
+구성은 파드의 컨테이너를 실행하는데 사용된다.
 
 {{% /capture %}}
 
 
 {{% capture body %}}
 
-## 런타임 클래스
-
-런타임 클래스는 컨테이너 런타임 설정을 선택하는 기능이다.
-이 컨테이너 런타임 설정은 파드의 컨테이너를 실행할 때에 이용한다.
-
 ## 동기
 
 서로 다른 파드간에 런타임 클래스를 설정하여
@@ -38,7 +30,7 @@ weight: 20
 또한 런타임 클래스를 사용하여 컨테이너 런타임이 같으나 설정이 다른
 여러 파드를 실행할 수 있다.
 
-### 셋업
+## 셋업
 
 RuntimeClass 특징 게이트가 활성화(기본값)를 확인한다.
 특징 게이트 활성화에 대한 설명은 [특징 게이트](/docs/reference/command-line-tools-reference/feature-gates/)를
@@ -47,7 +39,7 @@ RuntimeClass 특징 게이트가 활성화(기본값)를 확인한다.
 1. CRI 구현(implementation)을 노드에 설정(런타임에 따라서)
 2. 상응하는 런타임 클래스 리소스 생성
 
-#### 1. CRI 구현을 노드에 설정
+### 1. CRI 구현을 노드에 설정
 
 런타임 클래스를 통한 가능한 구성은 컨테이너 런타임 인터페이스(CRI) 구현에 의존적이다.
 사용자의 CRI 구현에 따른 설정 방법은
@@ -62,7 +54,7 @@ RuntimeClass 특징 게이트가 활성화(기본값)를 확인한다.
 해당 설정은 상응하는 `handler` 이름을 가지며, 이는 런타임 클래스에 의해서 참조된다.
 런타임 핸들러는 유효한 DNS 1123 서브도메인(알파-숫자 + `-`와 `.`문자)을 가져야 한다.
 
-#### 2. 상응하는 런타임 클래스 리소스 생성
+### 2. 상응하는 런타임 클래스 리소스 생성
 
 1단계에서 셋업 한 설정은 연관된 `handler` 이름을 가져야 하며, 이를 통해서 설정을 식별할 수 있다.
 각 런타임 핸들러(그리고 선택적으로 비어있는 `""` 핸들러)에 대해서, 상응하는 런타임 클래스 오브젝트를 생성한다.
@@ -88,7 +80,7 @@ handler: myconfiguration  # 상응하는 CRI 설정의 이름임
 더 자세한 정보는 [권한 개요](/docs/reference/access-authn-authz/authorization/)를 참고한다.
 {{< /note >}}
 
-### 사용
+## 사용
 
 클러스터를 위해서 런타임 클래스를 설정하고 나면, 그것을 사용하는 것은 매우 간단하다. 파드 스펙에
 `runtimeClassName`를 명시한다. 예를 들면 다음과 같다.
@@ -147,13 +139,13 @@ https://github.com/containerd/cri/blob/master/docs/config.md
 
 [100]: https://raw.githubusercontent.com/cri-o/cri-o/9f11d1d/docs/crio.conf.5.md
 
-### 스케줄
+## 스케줄
 
 {{< feature-state for_k8s_version="v1.16" state="beta" >}}
 
 쿠버네티스 v1.16 부터, 런타임 클래스는 `scheduling` 필드를 통해 이종의 클러스터 지원을 포함한다.
 이 필드를 사용하면, 이 런타임 클래스를 갖는 파드가 이를 지원하는 노드로 스케줄된다는 것을 보장할 수 있다.
-이 스케줄링 기능을 사용하려면, 런타임 클래스 [어드미션(admission) 컨트롤러][]를 활성화(1.16 부터 기본 값)해야 한다.
+이 스케줄링 기능을 사용하려면, [런타임 클래스 어드미션(admission) 컨트롤러][]를 활성화(1.16 부터 기본 값)해야 한다.
 
 파드가 지정된 런타임 클래스를 지원하는 노드에 안착한다는 것을 보장하려면,
 해당 노드들은 `runtimeClass.scheduling.nodeSelector` 필드에서 선택되는 공통 레이블을 가져야한다.
@@ -168,50 +160,24 @@ https://github.com/containerd/cri/blob/master/docs/config.md
 노드 셀렉터와 톨러레이션 설정에 대해 더 배우려면
 [노드에 파드 할당](/ko/docs/concepts/configuration/assign-pod-node/)을 참고한다.
 
-[어드미션 컨트롤러]: /docs/reference/access-authn-authz/admission-controllers/
+[런타임 클래스 어드미션 컨트롤러]: /docs/reference/access-authn-authz/admission-controllers/#runtimeclass
 
 ### 파드 오버헤드
 
-{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.18" state="beta" >}}
 
-쿠버네티스 v1.16 부터는, 런타임 클래스에는 구동 중인 파드와 관련된 오버헤드를
-지정할 수 있는 기능이 [`PodOverhead`](/docs/concepts/configuration/pod-overhead) 기능을 통해 지원된다.
-`PodOverhead`를 사용하려면, PodOverhead [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)를
-활성화 시켜야 한다. (기본 값으로는 비활성화 되어 있다.)
+파드 실행과 연관되는 _오버헤드_ 리소스를 지정할 수 있다. 오버헤드를 선언하면
+클러스터(스케줄러 포함)가 파드와 리소스에 대한 결정을 내릴 때 처리를 할 수 있다.
+PodOverhead를 사용하려면, PodOverhead [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)
+를 활성화 시켜야 한다. (기본으로 활성화 되어 있다.)
 
 
-파드 오버헤드는 런타임 클래스에서 `Overhead` 필드를 통해 정의된다. 이 필드를 사용하면,
+파드 오버헤드는 런타임 클래스에서 `overhead` 필드를 통해 정의된다. 이 필드를 사용하면,
 해당 런타임 클래스를 사용해서 구동 중인 파드의 오버헤드를 특정할 수 있고 이 오버헤드가
 쿠버네티스 내에서 처리된다는 것을 보장할 수 있다.
 
-### 런타임 클래스를 알파에서 베타로 업그레이드 {#upgrading-runtimeclass-from-alpha-to-beta}
-
-런타임 클래스 베타 기능은 다음의 변화를 포함한다.
-
-- `node.k8s.io` API 그룹과 `runtimeclasses.node.k8s.io` 리소스는 CustomResourceDefinition에서
-  내장 API로 이전되었다.
-- 런타임 클래스 정의에서 `spec`을 직접 사용할 수 있다.
-  (즉, 더 이상 RuntimeClassSpec는 없다).
-- `runtimeHandler` 필드는 `handler`로 이름이 바뀌었다.
-- `handler` 필드는 이제 모두 API 버전에서 요구된다. 이는 알파 API에서도 `runtimeHandler` 필드가
-  필요하다는 의미이다.
-- `handler` 필드는 반드시 올바른 DNS 레이블([RFC 1123](https://tools.ietf.org/html/rfc1123))으로,
-  이는 더 이상 `.` 캐릭터(모든 버전에서)를 포함할 수 없다 의미이다. 올바른 핸들러는
-  다음의 정규 표현식을 따른다. `^[a-z0-9]([-a-z0-9]*[a-z0-9])?$`.
-
-**작업 필요** 다음 작업은 알파 버전의 런타임 기능을
-베타 버전으로 업그레이드하기 위해 진행되어야 한다.
-
-- 런타임 클래스 리소스는 v1.14로 업그레이드 *후에* 반드시 재생성되어야 하고,
-  `runtimeclasses.node.k8s.io` CRD는 다음과 같이 수동으로 지워야 한다.
-  ```
-  kubectl delete customresourcedefinitions.apiextensions.k8s.io runtimeclasses.node.k8s.io
-  ```
-- 지정되지 않았거나 비어 있는 `runtimeHandler` 이거나 핸들러 내에 `.` 캐릭터를 사용한 알파 런타임 클래스는
-  더 이상 올바르지 않으며, 반드시 올바른 핸들러 구성으로 이전헤야 한다
-  (위를 참조).
-
-### 더 읽기
+{{% /capture %}}
+{{% capture whatsnext %}}
 
 - [런타임 클래스 설계](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class.md)
 - [런타임 클래스 스케줄링 설계](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class-scheduling.md)

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

@@ -82,7 +82,7 @@ metadata:
 spec:
   containers:
   - name: nginx
-    image: nginx:1.7.9
+    image: nginx:1.14.2
     ports:
     - containerPort: 80
 

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

@@ -67,7 +67,7 @@ metadata:
 spec:
   containers:
   - name: nginx
-    image: nginx:1.7.9
+    image: nginx:1.14.2
     ports:
     - containerPort: 80
 

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

@@ -62,7 +62,7 @@ metadata:
 spec:
   containers:
   - name: nginx
-    image: nginx:1.7.9
+    image: nginx:1.14.2
     ports:
     - containerPort: 80
 ```

content/ko/docs/concepts/services-networking/ingress.md

@@ -71,6 +71,7 @@ spec:
   - http:
       paths:
       - path: /testpath
+        pathType: Prefix
         backend:
           serviceName: test
           servicePort: 80
@@ -115,6 +116,84 @@ spec:
 만약 인그레스 오브젝트의 HTTP 요청과 일치하는 호스트 또는 경로가 없으면, 트래픽은
 기본 백엔드로 라우팅 된다.
 
+### 경로(Path) 유형
+
+인그레스의 각 경로에는 해당하는 경로 유형이 있다. 지원되는 세 가지의 경로
+유형이 있다.
+
+* _`ImplementationSpecific`_ (기본): 이 경로 유형의 일치 여부는 IngressClass에 따라
+  달라진다. 이를 구현할 때 별도 pathType으로 처리하거나, `Prefix` 또는 `Exact`
+  경로 유형과 같이 동일하게 처리할 수 있다.
+
+* _`Exact`_: URL 경로의 대소문자를 엄격하게 일치시킨다.
+
+* _`Prefix`_: URL 경로의 접두사를 `/` 를 기준으로 분리한 값과 일치시킨다.
+  일치는 대소문자를 구분하고,
+  요소별로 경로 요소에 대해 수행한다.
+  모든 _p_ 가 요청 경로의 요소별 접두사가 _p_ 인 경우
+  요청은 _p_ 경로에 일치한다.
+    {{< note >}}
+    경로의 마지막 요소가 요청 경로에 있는 마지막 요소의
+    하위 문자열인 경우에는 일치하지 않는다(예시: 
+    `/foo/bar` 와 `/foo/bar/baz` 와 일치하지만, `/foo/barbaz` 는 일치하지 않는다).
+    {{< /note >}}
+
+#### 다중 일치
+경우에 따라 인그레스의 여러 경로가 요청과 일치할 수 있다.
+이 경우 가장 긴 일치하는 경로가 우선하게 된다. 두 개의 경로가
+여전히 동일하게 일치하는 경우 접두사(prefix) 경로 유형보다
+정확한(exact) 경로 유형을 가진 경로가 사용 된다.
+
+## 인그레스 클래스
+
+인그레스는 서로 다른 컨트롤러에 의해 구현될 수 있으며, 종종 다른 구성으로
+구현될 수 있다. 각 인그레스에서는 클래스를 구현해야하는 컨트롤러
+이름을 포함하여 추가 구성이 포함된 IngressClass
+리소스에 대한 참조 클래스를 지정해야 한다.
+
+```yaml
+apiVersion: networking.k8s.io/v1beta1
+kind: IngressClass
+metadata:
+  name: external-lb
+spec:
+  controller: example.com/ingress-controller
+  parameters:
+    apiGroup: k8s.example.com/v1alpha
+    kind: IngressParameters
+    name: external-lb
+```
+
+IngressClass 리소스에는 선택적인 파라미터 필드가 있다. 이 클래스에 대한
+추가 구성을 참조하는데 사용할 수 있다.
+
+### 사용중단(Deprecated) 어노테이션
+
+쿠버네티스 1.18에 IngressClass 리소스 및 `ingressClassName` 필드가 추가되기
+전에 인그레스 클래스는 인그레스에서
+`kubernetes.io/ingress.class` 어노테이션으로 지정되었다. 이 어노테이션은
+공식적으로 정의된 것은 아니지만, 인그레스 컨트롤러에서 널리 지원되었었다.
+
+인그레스의 최신 `ingressClassName` 필드는 해당 어노테이션을
+대체하지만, 직접적으로 해당하는 것은 아니다. 어노테이션은 일반적으로
+인그레스를 구현해야 하는 인그레스 컨트롤러의 이름을 참조하는 데 사용되었지만,
+이 필드는 인그레스 컨트롤러의 이름을 포함하는 추가 인그레스 구성이
+포함된 인그레스 클래스 리소스에 대한 참조이다.
+
+### 기본 인그레스 클래스
+
+특정 IngressClass를 클러스터의 기본 값으로 표시할 수 있다. IngressClass
+리소스에서 `ingressclass.kubernetes.io/is-default-class` 를 `true` 로
+설정하면 `ingressClassName` 필드가 지정되지 않은
+새 인그레스에게 기본 IngressClass가 할당된다.
+
+{{< caution >}}
+클러스터의 기본값으로 표시된 IngressClass가 두 개 이상 있는 경우
+어드미션 컨트롤러에서 `ingressClassName` 이 지정되지 않은
+새 인그레스 오브젝트를 생성할 수 없다. 클러스터에서 최대 1개의 IngressClass가
+기본값으로 표시하도록 해서 이 문제를 해결할 수 있다.
+{{< /caution >}}
+
 ## 인그레스 유형들
 
 ### 단일 서비스 인그레스

content/ko/docs/concepts/services-networking/service.md

@@ -202,6 +202,17 @@ API 리소스이다. 개념적으로 엔드포인트와 매우 유사하지만,
 엔드포인트슬라이스는 [엔드포인트슬라이스](/ko/docs/concepts/services-networking/endpoint-slices/)에서
 자세하게 설명된 추가적인 속성 및 기능을 제공한다.
 
+### 애플리케이션 프로토콜
+
+{{< feature-state for_k8s_version="v1.18" state="alpha" >}}
+
+AppProtocol 필드는 각 서비스 포트에 사용될 애플리케이션 프로토콜을
+지정하는 방법을 제공한다.
+
+알파 기능으로 이 필드는 기본적으로 활성화되어 있지 않다. 이 필드를 사용하려면,
+[기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)에서
+`ServiceAppProtocol` 을 활성화해야 한다.
+
 ## 가상 IP와 서비스 프록시
 
 쿠버네티스 클러스터의 모든 노드는 `kube-proxy`를 실행한다. `kube-proxy`는

content/ko/docs/concepts/storage/volume-pvc-datasource.md

@@ -6,7 +6,6 @@ weight: 30
 
 {{% capture overview %}}
 
-{{< feature-state for_k8s_version="v1.16" state="beta" >}}
 이 문서에서는 쿠버네티스의 기존 CSI 볼륨 복제의 개념을 설명한다.  [볼륨]
 (/ko/docs/concepts/storage/volumes)을 숙지하는 것을 추천한다.
 
@@ -32,6 +31,7 @@ weight: 30
 * 복제는 동일한 스토리지 클래스 내에서만 지원된다.
     - 대상 볼륨은 소스와 동일한 스토리지 클래스여야 한다.
     - 기본 스토리지 클래스를 사용할 수 있으며, 사양에 storageClassName을 생략할 수 있다.
+* 동일한 VolumeMode 설정을 사용하는 두 볼륨에만 복제를 수행할 수 있다(블록 모드 볼륨을 요청하는 경우에는 반드시 소스도 블록 모드여야 한다).
 
 
 ## 프로비저닝

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

@@ -1327,19 +1327,13 @@ CSI 호환 볼륨 드라이버가 쿠버네티스 클러스터에 배포되면
 
 #### CSI 원시(raw) 블록 볼륨 지원
 
-{{< feature-state for_k8s_version="v1.14" state="beta" >}}
+{{< feature-state for_k8s_version="v1.18" state="stable" >}}
 
-1.11 버전부터 CSI는 이전 버전의 쿠버네티스에서 도입된 원시
-블록 볼륨 기능에 의존하는 원시 블록 볼륨에 대한 지원을
-도입했다.  이 기능을 사용하면 외부 CSI 드라이버가 있는 벤더들이 쿠버네티스
-워크로드에서 원시 블록 볼륨 지원을 구현할 수 있다.
+외부 CSI 드라이버가 있는 벤더들은 쿠버네티스 워크로드에서 원시(raw) 블록 볼륨
+지원을 구현할 수 있다.
 
-CSI 블록 볼륨은 기능 게이트로 지원하지만, 기본적으로 활성화되어있다. 이
-기능을 위해 활성화 되어야하는 두개의 기능 게이트는 `BlockVolume` 과
-`CSIBlockVolume` 이다.
-
-[원시 블록 볼륨 지원으로 PV/PVC 설정](/docs/concepts/storage/persistent-volumes/#raw-block-volume-support)
-방법을 알아본다.
+CSI 설정 변경 없이 평소와 같이
+[원시 블록 볼륨 지원으로 PV/PVC 설정](/docs/concepts/storage/persistent-volumes/#raw-block-volume-support)을 할 수 있다.
 
 #### CSI 임시(ephemeral) 볼륨
 

content/ko/docs/concepts/workloads/controllers/cron-jobs.md

@@ -14,12 +14,7 @@ _크론 잡은_ 시간 기반의 일정에 따라 [잡](/ko/docs/concepts/worklo
 
 
 {{< caution >}}
-모든 **크론잡** `일정:` 시간은 {{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}}
-의 시간대를 기준으로 한다.
-
-컨트롤 플레인이 파드 또는 베어 컨테이너에서 kube-controller-manager를
-실행하는 경우 kube-controller-manager 컨테이너의 설정된 시간대는 크론 잡 컨트롤러가
-사용하는 시간대로 설정한다.
+모든 **크론잡** `일정:` 시간은 UTC로 표시된다.
 {{< /caution >}}
 
 크론잡 리소스에 대한 매니페스트를 생성할때에는 제공하는 이름이