[ko] Update outdated files in dev-1.23-ko.2 M9-M17

content/ko/docs/concepts/containers/container-environment.md

@@ -34,15 +34,14 @@ weight: 20
 파드 이름과 네임스페이스는
 [다운워드(Downward) API](/ko/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/)를 통해 환경 변수로 구할 수 있다.
 
-Docker 이미지에 정적으로 명시된 환경 변수와 마찬가지로,
+컨테이너 이미지에 정적으로 명시된 환경 변수와 마찬가지로,
 파드 정의에서의 사용자 정의 환경 변수도 컨테이너가 사용할 수 있다.
 
 ### 클러스터 정보
 
 컨테이너가 생성될 때 실행 중이던 모든 서비스의 목록은 환경 변수로 해당 컨테이너에서 사용할 수
 있다.
 이 목록은 새로운 컨테이너의 파드 및 쿠버네티스 컨트롤 플레인 서비스와 동일한 네임스페이스 내에 있는 서비스로 한정된다.
-이러한 환경 변수는 Docker 링크 구문과 일치한다.
 
 *bar* 라는 이름의 컨테이너에 매핑되는 *foo* 라는 이름의 서비스에 대해서는,
 다음의 형태로 변수가 정의된다.

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

@@ -109,6 +109,11 @@ CRI 런타임 설치에 대한 자세한 내용은 [CRI 설치](/ko/docs/setup/p
 
 #### dockershim
 
+{{< feature-state for_k8s_version="v1.20" state="deprecated" >}}
+
+dockershim은 쿠버네티스 v1.20에서 사용 중단되었으며, v1.24에서 제거될 것이다. 상세 사항은 
+[dockershim 사용 중단](/blog/2020/12/08/kubernetes-1-20-release-announcement/#dockershim-deprecation)을 참고한다.
+
 dockershim을 사용하는 경우 RuntimeClass는 런타임 핸들러를 `docker`로 고정한다.
 dockershim은 사용자 정의 런타임 핸들러를 지원하지 않는다.
 

content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md

@@ -1,7 +1,6 @@
 ---
-
 title: 장치 플러그인
-description: GPU, NIC, FPGA, InfiniBand 및 공급 업체별 설정이 필요한 유사한 리소스를 위한 플러그인을 구현하는데 쿠버네티스 장치 플러그인 프레임워크를 사용한다.
+description: 장치 플러그인을 사용하여 GPU, NIC, FPGA, 또는 비휘발성 주 메모리와 같이 공급 업체별 설정이 필요한 장치 또는 리소스를 클러스터에서 지원하도록 설정할 수 있다.
 content_type: concept
 weight: 20
 ---
@@ -48,13 +47,15 @@ service Registration {
 노드에 두 개의 정상 장치를 보고하고 나면, 노드 상태가 업데이트되어
 노드에 2개의 "Foo" 장치가 설치되어 사용 가능함을 알릴 수 있다.
 
-그러고 나면, 사용자가
-[컨테이너](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core) 명세에 있는 장치를 요청할 수 있다.
-다만, 다른 종류의 리소스를 요청하는 것이므로 다음과 같은 제한이 있다.
-
+그러고 나면, 사용자가 장치를 파드 스펙의 일부로 요청할 수 
+있다([`container`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#Container) 참조). 
+확장 리소스를 요청하는 것은 다른 자원의 요청 및 제한을 관리하는 것과 비슷하지만, 
+다음과 같은 차이점이 존재한다.
 * 확장된 리소스는 정수(integer) 형태만 지원되며 오버커밋(overcommit) 될 수 없다.
 * 컨테이너간에 장치를 공유할 수 없다.
 
+### 예제 {#example-pod}
+
 쿠버네티스 클러스터가 특정 노드에서 `hardware-vendor.example/foo` 리소스를 알리는 장치 플러그인을 실행한다고
 가정해 보자. 다음은 데모 워크로드를 실행하기 위해 이 리소스를 요청하는 파드의 예이다.
 
@@ -338,6 +339,8 @@ pluginapi.Device{ID: "25102017", Health: pluginapi.Healthy, Topology:&pluginapi.
 
 ## 장치 플러그인 예시 {#examples}
 
+{{% thirdparty-content %}}
+
 다음은 장치 플러그인 구현의 예이다.
 
 * [AMD GPU 장치 플러그인](https://github.com/RadeonOpenCompute/k8s-device-plugin)
@@ -357,5 +360,5 @@ pluginapi.Device{ID: "25102017", Health: pluginapi.Healthy, Topology:&pluginapi.
 
 * 장치 플러그인을 사용한 [GPU 리소스 스케줄링](/ko/docs/tasks/manage-gpus/scheduling-gpus/)에 대해 알아보기
 * 노드에서의 [확장 리소스 알리기](/ko/docs/tasks/administer-cluster/extended-resource-node/)에 대해 배우기
-* 쿠버네티스에서 [TLS 수신에 하드웨어 가속](https://kubernetes.io/blog/2019/04/24/hardware-accelerated-ssl/tls-termination-in-ingress-controllers-using-kubernetes-device-plugins-and-runtimeclass/) 사용에 대해 읽기
 * [토폴로지 관리자](/docs/tasks/administer-cluster/topology-manager/)에 대해 알아보기
+* 쿠버네티스에서 [TLS 수신에 하드웨어 가속](/blog/2019/04/24/hardware-accelerated-ssl/tls-termination-in-ingress-controllers-using-kubernetes-device-plugins-and-runtimeclass/) 사용에 대해 읽기

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

@@ -42,9 +42,10 @@ kubectl과 대시보드와 같은 많은 도구들로 쿠버네티스 오브젝
 | `app.kubernetes.io/managed-by`      | 애플리케이션의 작동을 관리하는 데 사용되는 도구 | `helm` | 문자열 |
 | `app.kubernetes.io/created-by`      | 이 리소스를 만든 컨트롤러/사용자 | `controller-manager` | 문자열 |
 
-위 레이블의 실제 예시는 다음 스테이트풀셋 오브젝트를 고려한다.
+위 레이블의 실제 예시는 다음 {{< glossary_tooltip text="스테이트풀셋" term_id="statefulset" >}} 오브젝트를 고려한다.
 
 ```yaml
+# 아래는 전체 명세의 일부분이다
 apiVersion: apps/v1
 kind: StatefulSet
 metadata:

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

@@ -95,7 +95,26 @@ kubectl config view --minify | grep namespace:
 이 엔트리는 `<서비스-이름>.<네임스페이스-이름>.svc.cluster.local`의 형식을 갖는데,
 이는 컨테이너가 `<서비스-이름>`만 사용하는 경우, 네임스페이스 내에 국한된 서비스로 연결된다.
 개발, 스테이징, 운영과 같이 여러 네임스페이스 내에서 동일한 설정을 사용하는 경우에 유용하다.
-네임스페이스를 넘어서 접근하기 위해서는, 전체 주소 도메인 이름(FQDN)을 사용해야 한다.
+네임스페이스를 넘어서 접근하기 위해서는, 
+전체 주소 도메인 이름(FQDN)을 사용해야 한다.
+
+그렇기 때문에, 모든 네임스페이스 이름은 유효한 
+[RFC 1123 DNS 레이블](/ko/docs/concepts/overview/working-with-objects/names/#dns-label-names)이어야 한다.
+
+{{< warning >}}
+네임스페이스의 이름을 [공개 최상위 도메인](https://data.iana.org/TLD/tlds-alpha-by-domain.txt) 중 하나와 동일하게 만들면, 
+해당 네임스페이스 내의 서비스의 짧은 DNS 이름이 공개 DNS 레코드와 겹칠 수 있다. 
+어떠한 네임스페이스 내의 워크로드가 
+[접미점(trailing dot)](https://datatracker.ietf.org/doc/html/rfc1034#page-8) 없이 DNS 룩업을 수행하면 
+공개 DNS 레코드가 아니라 이러한 서비스로 리다이렉트될 것이다.
+
+이를 방지하기 위해, 신뢰하는 사용자만 네임스페이스를 
+생성할 수 있도록 권한을 제한한다. 
+필요한 경우, 추가적으로 써드파티 보안 컨트롤을 구성할 수 있으며, 
+예를 들어 [어드미션 웹훅](/docs/reference/access-authn-authz/extensible-admission-controllers/)을 이용하여 
+[공개 TLD](https://data.iana.org/TLD/tlds-alpha-by-domain.txt)와 
+동일한 이름의 네임스페이스 생성을 금지시킬 수 있다.
+{{< /warning >}}
 
 ## 모든 오브젝트가 네임스페이스에 속하지는 않음
 

content/ko/docs/concepts/policy/pod-security-policy.md

@@ -11,8 +11,9 @@ weight: 30
 
 {{< feature-state for_k8s_version="v1.21" state="deprecated" >}}
 
-파드시큐리티폴리시(PodSecurityPolicy)는 쿠버네티스 v1.21부터 더이상 사용되지 않으며, v1.25에서 제거된다. 사용 중단에 대한 상세 사항은
-[파드시큐리티폴리시 사용 중단: 과거, 현재, 그리고 미래](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/)를 참조한다.
+파드시큐리티폴리시(PodSecurityPolicy)는 쿠버네티스 v1.21부터 더이상 사용되지 않으며, v1.25에서 제거된다. 
+파드시큐리티폴리시는 [파드 시큐리티 어드미션](/docs/concepts/security/pod-security-admission/)으로 대체되었다.
+사용 중단에 대한 상세 사항은 [파드시큐리티폴리시 사용 중단: 과거, 현재, 그리고 미래](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/)를 참조한다.
 
 파드 시큐리티 폴리시를 사용하면 파드 생성 및 업데이트에 대한 세분화된 권한을
 부여할 수 있다.

content/ko/docs/concepts/scheduling-eviction/node-pressure-eviction.md

@@ -235,7 +235,7 @@ QoS는 EphemeralStorage 요청에 적용되지 않으므로,
 `Guaranteed` 파드는 모든 컨테이너에 대해 자원 요청량과 제한이 명시되고 
 그 둘이 동일할 때에만 보장(guaranteed)된다. 다른 파드의 자원 사용으로 인해 
 `Guaranteed` 파드가 축출되는 일은 발생하지 않는다. 만약 시스템 데몬(예: 
-`kubelet`, `docker`, `journald`)이 `system-reserved` 또는 `kube-reserved` 
+`kubelet`, `journald`)이 `system-reserved` 또는 `kube-reserved` 
 할당을 통해 예약된 것보다 더 많은 자원을 소비하고, 노드에는 요청량보다 적은 양의 
 자원을 사용하고 있는 `Guaranteed` / `Burstable` 파드만 존재한다면, 
 kubelet은 노드 안정성을 유지하고 자원 고갈이 다른 파드에 미칠 영향을 통제하기 위해 

content/ko/docs/concepts/scheduling-eviction/pod-priority-preemption.md

@@ -106,7 +106,7 @@ description: "이 프라이어리티클래스는 XYZ 서비스 파드에만 사
 
 {{< feature-state for_k8s_version="v1.19" state="beta" >}}
 
-`PreemptionPolicy: Never` 를 가진 파드는 낮은 우선순위 파드의 스케줄링 대기열의
+`preemptionPolicy: Never` 를 가진 파드는 낮은 우선순위 파드의 스케줄링 대기열의
 앞쪽에 배치되지만,
 그 파드는 다른 파드를 축출할 수 없다.
 스케줄링 대기 중인 비-선점 파드는 충분한 리소스가 확보되고
@@ -122,17 +122,17 @@ description: "이 프라이어리티클래스는 XYZ 서비스 파드에만 사
 비-선점 파드는 다른 우선순위가 높은 파드에 의해
 축출될 수 있다.
 
-`PreemptionPolicy` 는 기본값으로 `PreemptLowerPriority` 로 설정되어,
+`preemptionPolicy` 는 기본값으로 `PreemptLowerPriority` 로 설정되어,
 해당 프라이어리티클래스의 파드가 우선순위가 낮은 파드를 축출할 수
 있다(기존의 기본 동작과 동일).
-`PreemptionPolicy` 가 `Never` 로 설정된 경우,
+`preemptionPolicy` 가 `Never` 로 설정된 경우,
 해당 프라이어리티클래스의 파드는 비-선점될 것이다.
 
 예제 유스케이스는 데이터 과학 관련 워크로드이다.
 사용자는 다른 워크로드보다 우선순위가 높은 잡(job)을 제출할 수 있지만,
 실행 중인 파드를 축출하여 기존의 작업을 삭제하지는 않을 것이다.
 클러스터 리소스가 "자연스럽게" 충분히 사용할 수 있게 되면,
-`PreemptionPolicy: Never` 의 우선순위가 높은 잡이
+`preemptionPolicy: Never` 의 우선순위가 높은 잡이
 다른 대기 중인 파드보다 먼저 스케줄링된다.
 
 ### 비-선점 프라이어리티클래스 예제