Merge pull request #31695 from jihoon-seo/220211_Outdated_M1-M8

[ko] Update outdated files in `dev-1.23-ko.2` (M1-M8)

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

@@ -15,7 +15,7 @@ weight: 50
 {{< glossary_tooltip text="파드" term_id="pod" >}}들과 컨테이너들을 
 구동할 수 있다.
 
-{{< glossary_definition term_id="container-runtime-interface" length="all" >}}
+{{< glossary_definition prepend="컨테이너 런타임 인터페이스(CRI)는" term_id="container-runtime-interface" length="all" >}}
 
 <!-- body -->
 

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

@@ -33,7 +33,7 @@ weight: 10
 1. 노드의 kubelet으로 컨트롤 플레인에 자체 등록
 2. 사용자(또는 다른 사용자)가 노드 오브젝트를 수동으로 추가
 
-노드 오브젝트 또는 노드의 kubelet으로 자체 등록한 후
+노드 {{< glossary_tooltip text="오브젝트" term_id="object" >}} 또는 노드의 kubelet으로 자체 등록한 후
 컨트롤 플레인은 새 노드 오브젝트가 유효한지 확인한다.
 예를 들어 다음 JSON 매니페스트에서 노드를 만들려는 경우이다.
 

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

@@ -30,46 +30,7 @@ weight: 50
 찾는 방법 등을 알아야 한다. 쿠버네티스는 이런 것들을 다루는 대신
 다른 접근법을 취한다.
 
-## 쿠버네티스 네트워크 모델
+쿠버네티스 네트워킹 모델에 대한 상세 정보는 [여기](/ko/docs/concepts/services-networking/)를 참고한다.
-
-모든 `Pod` 에는 고유의 IP 주소가 있다. 즉, `Pod` 간에 링크를 명시적으로
-생성할 필요가 없으며 컨테이너 포트를 호스트 포트에 매핑할
-필요가 거의 없다. 이렇게 하면 포트 할당, 이름 지정, 서비스 검색, 로드 밸런싱,
-애플리케이션 구성 및 마이그레이션 관점에서 `Pod` 를 VM 또는
-물리적 호스트처럼 취급할 수 있는 깔끔하고, 하위 호환성
-있는 모델이 생성된다.
-
-쿠버네티스는 모든 네트워크 구현에 다음과 같은
-기본 요구 사항을 적용한다(의도적 네트워크 세분화 정책 제외).
-
-   * 노드의 파드는 NAT 없이 모든 노드의 모든 파드와 통신할 수 있다.
-   * 노드의 에이전트(예: 시스템 데몬, kubelet)는 해당 노드의 모든
-     파드와 통신할 수 있다.
-
-참고: 호스트 네트워크에서 실행되는 `Pod` 를 지원하는 리눅스와 같은 플랫폼의 경우, 다음의 요구 사항을
-적용한다.
-
-   * 노드의 호스트 네트워크에 있는 파드는 NAT 없이 모든 노드에 있는 모든
-     파드와 통신할 수 있다.
-
-이 모델은 전체적으로 덜 복잡할 뿐만 아니라, 쿠버네티스를 위해 VM에서
-컨테이너로 애플리케이션을 포팅할 때 충돌이 적게 구현하려는 요구와
-주로 호환된다. 잡이 이전에 VM에서 실행된 경우, VM에 IP가 있고
-프로젝트의 다른 VM과 통신할 수 있다. 이것은 동일한 기본 모델이다.
-
-쿠버네티스의 IP 주소는 그것의 IP 주소와 MAC 주소를 포함하여 `Pod` 범위에 존재한다(`Pod` 내
-컨테이너는 네트워크 네임스페이스를 공유함). 이것은 `Pod` 내 컨테이너가 모두
-`localhost` 에서 서로의 포트에 도달할 수 있다는 것을 의미한다. 또한
-`Pod` 내부의 컨테이너 포트의 사용을 조정해야하는 것을 의미하지만, 이것도
-VM 내의 프로세스와 동일하다. 이것을 "IP-per-pod(파드별 IP)" 모델이라고 
-한다.
-
-이것이 어떻게 구현되는 지는 사용 중인 특정 컨테이너 런타임의 세부 사항이다. 비슷하게, 사용자가 선택한 네트워킹 옵션이 [IPv4/IPv6 이중 스택](/ko/docs/concepts/services-networking/dual-stack/)을 지원할 수도 있으며, 구현 방법은 다양할 수 있다.
-
-`Pod` 로 전달하는 `Node` 자체의 포트(호스트 포트라고 함)를
-요청할 수 있지만, 이는 매우 틈새 작업이다. 전달이 구현되는 방법은
-컨테이너 런타임의 세부 사항이기도 하다. `Pod` 자체는
-호스트 포트의 존재 여부에 대해 인식하지 못한다.
 
 ## 쿠버네티스 네트워크 모델의 구현 방법
 
@@ -106,7 +67,7 @@ Azure CNI는 [Azure 쿠버네티스 서비스(Azure Kubernetes Service, AKS)](ht
 
 ### 캘리코
 
-[캘리코](https://docs.projectcalico.org/)는 컨테이너, 가상 시스템 및 기본 호스트 기반 워크로드를 위한 오픈소스 네트워킹 및 네트워크 보안 솔루션이다. 캘리코는 순수 리눅스 eBPF 데이터플레인, 표준 리눅스 네트워킹 데이터플레인, 윈도우 HNS 데이터플레인을 포함한 여러 데이터플레인을 지원한다. 캘리코는 완전한 네트워킹 스택을 제공하지만, [클라우드 제공자 CNI](https://docs.projectcalico.org/networking/determine-best-networking#calico-compatible-cni-plugins-and-cloud-provider-integrations)와 함께 사용하여 네트워크 정책 시행을 제공할 수도 있다.
+[캘리코](https://projectcalico.docs.tigera.io/about/about-calico/)는 컨테이너, 가상 시스템 및 기본 호스트 기반 워크로드를 위한 오픈소스 네트워킹 및 네트워크 보안 솔루션이다. 캘리코는 순수 리눅스 eBPF 데이터플레인, 표준 리눅스 네트워킹 데이터플레인, 윈도우 HNS 데이터플레인을 포함한 여러 데이터플레인을 지원한다. 캘리코는 완전한 네트워킹 스택을 제공하지만, [클라우드 제공자 CNI](https://projectcalico.docs.tigera.io/networking/determine-best-networking#calico-compatible-cni-plugins-and-cloud-provider-integrations)와 함께 사용하여 네트워크 정책 시행을 제공할 수도 있다.
 
 ### 실리움(Cilium)
 
@@ -118,9 +79,9 @@ Azure CNI는 [Azure 쿠버네티스 서비스(Azure Kubernetes Service, AKS)](ht
 
 ### 화웨이의 CNI-Genie
 
-[CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie)는 쿠버네티스가 런타임 시 [쿠버네티스 네트워크 모델](/ko/docs/concepts/cluster-administration/networking/#쿠버네티스-네트워크-모델)의 [서로 다른 구현에 동시에 접근](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-cni-plugins/README.md#what-cni-genie-feature-1-multiple-cni-plugins-enables)할 수 있는 CNI 플러그인이다. 여기에는 [플라넬(Flannel)](https://github.com/coreos/flannel#flannel), [캘리코](https://docs.projectcalico.org/), [로마나(Romana)](https://romana.io), [위브넷(Weave-net)](https://www.weave.works/products/weave-net/)과 같은 [CNI 플러그인](https://github.com/containernetworking/cni#3rd-party-plugins)으로 실행되는 모든 구현이 포함된다.
+[CNI-Genie](https://github.com/cni-genie/CNI-Genie)는 쿠버네티스가 런타임 시 [쿠버네티스 네트워크 모델](/ko/docs/concepts/cluster-administration/networking/#쿠버네티스-네트워크-모델)의 [서로 다른 구현에 동시에 접근](https://github.com/cni-genie/CNI-Genie/blob/master/docs/multiple-cni-plugins/README.md#what-cni-genie-feature-1-multiple-cni-plugins-enables)할 수 있는 CNI 플러그인이다. 여기에는 [플라넬(Flannel)](https://github.com/flannel-io/flannel#flannel), [캘리코](https://projectcalico.docs.tigera.io/about/about-calico/), [위브넷(Weave-net)](https://www.weave.works/oss/net/)과 같은 [CNI 플러그인](https://github.com/containernetworking/cni#3rd-party-plugins)으로 실행되는 모든 구현이 포함된다.
 
-CNI-Genie는 각각 다른 CNI 플러그인에서 [하나의 파드에 여러 IP 주소를 할당](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-ips/README.md#feature-2-extension-cni-genie-multiple-ip-addresses-per-pod)하는 것도 지원한다.
+CNI-Genie는 각각 다른 CNI 플러그인에서 [하나의 파드에 여러 IP 주소를 할당](https://github.com/cni-genie/CNI-Genie/blob/master/docs/multiple-ips/README.md#feature-2-extension-cni-genie-multiple-ip-addresses-per-pod)하는 것도 지원한다.
 
 ### cni-ipvlan-vpc-k8s
 [cni-ipvlan-vpc-k8s](https://github.com/lyft/cni-ipvlan-vpc-k8s)는
@@ -143,9 +104,10 @@ VPC 라우팅 테이블을 조정하여 각 호스트에 인스턴스별 서브
 [Coil](https://github.com/cybozu-go/coil)은 통합이 용이하도록 설계된 CNI 플러그인으로 유연한 이그레스(egress) 네트워킹을 제공한다.
 Coil은 베어메탈에 비해 낮은 오버헤드로 작동하며, 외부 네트워크에 대해 임의의 이그레스 NAT 게이트웨이를 정의할 수 있다.
 
-### 콘티브(Contiv)
+### 콘티브-VPP(Contiv-VPP)
 
-[콘티브](https://github.com/contiv/netplugin)는 다양한 적용 사례에서 구성 가능한 네트워킹(BGP를 사용하는 네이티브 L3, vxlan을 사용하는 오버레이, 클래식 L2 또는 Cisco-SDN/ACI)을 제공한다.
+[Contiv-VPP](https://contivpp.io/)는 유저 스페이스에서 동작하고 성능을 중시하는 쿠버네티스 네트워크 플러그인이며, 
+데이터 플레인으로 [fd.io](https://fd.io/)를 사용한다.
 
 ### 콘트레일(Contrail) / 텅스텐 패브릭(Tungsten Fabric)
 
@@ -165,10 +127,14 @@ Coil은 베어메탈에 비해 낮은 오버헤드로 작동하며, 외부 네
 
 ### 플라넬
 
-[플라넬](https://github.com/coreos/flannel#flannel)은 쿠버네티스 요구 사항을
+[플라넬](https://github.com/flannel-io/flannel#flannel)은 쿠버네티스 요구 사항을
 충족하는 매우 간단한 오버레이 네트워크이다. 많은
 경우에 쿠버네티스와 플라넬은 성공적으로 적용이 가능하다.
 
+### Hybridnet
+
+[Hybridnet](https://github.com/alibaba/hybridnet)은 하이브리드 클라우드를 위해 디자인된 오픈소스 CNI 플러그인이며 하나 또는 다수의 클러스터에 있는 컨테이너를 위한 오버레이 및 언더레이 네트워킹을 제공한다. 오버레이 및 언더레이 컨테이너는 동일한 노드에서 실행될 수 있으며 클러스터 범위의 양방향 네트워크 연결성을 가진다.
+
 ### 재규어(Jaguar)
 
 [재규어](https://gitlab.com/sdnlab/jaguar)는 OpenDaylight 기반의 쿠버네티스 네트워크를 위한 오픈소스 솔루션이다. 재규어는 vxlan을 사용하여 오버레이 네트워크를 제공하고 재규어 CNI 플러그인은 파드별로 하나의 IP 주소를 제공한다.
@@ -227,7 +193,7 @@ OVN은 Open vSwitch 커뮤니티에서 개발한 오픈소스 네트워크
 
 ### Weaveworks의 위브넷
 
-[위브넷](https://www.weave.works/products/weave-net/)은
+[위브넷](https://www.weave.works/oss/net/)은
 쿠버네티스 및 호스팅된 애플리케이션을 위한 탄력적이고 사용하기 쉬운 네트워크이다.
 위브넷은 [CNI 플러그인](https://www.weave.works/docs/net/latest/cni-plugin/) 또는
 독립형으로 실행된다. 두 버전에서, 실행하기 위해 구성이나 추가 코드가 필요하지 않으며,

content/ko/docs/concepts/cluster-administration/system-logs.md

@@ -17,23 +17,70 @@ weight: 60
 
 ## Klog
 
-klog는 쿠버네티스의 로깅 라이브러리다. [klog](https://github.com/kubernetes/klog)
+klog는 쿠버네티스의 로깅 라이브러리다. [klog](https://github.com/kubernetes/klog)는 
-는 쿠버네티스 시스템 컴포넌트의 로그 메시지를 생성한다.
+쿠버네티스 시스템 컴포넌트의 로그 메시지를 생성한다.
 
 klog 설정에 대한 더 많은 정보는, [커맨드라인 툴](/ko/docs/reference/command-line-tools-reference/)을 참고한다.
 
+쿠버네티스는 각 컴포넌트의 로깅을 간소화하는 중에 있다. 
+다음 klog 명령줄 플래그는 쿠버네티스 1.23에서 
+[사용 중단](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/2845-deprecate-klog-specific-flags-in-k8s-components)되었으며 
+이후 릴리스에서 제거될 것이다.
+
+- `--add-dir-header`
+- `--alsologtostderr`
+- `--log-backtrace-at`
+- `--log-dir`
+- `--log-file`
+- `--log-file-max-size`
+- `--logtostderr`
+- `--one-output`
+- `--skip-headers`
+- `--skip-log-headers`
+- `--stderrthreshold`
+
+출력은 출력 형식에 관계없이 항상 표준 에러(stderr)에 기록될 것이다. 
+출력 리다이렉션은 쿠버네티스 컴포넌트를 호출하는 컴포넌트가 담당할 것으로 기대된다. 
+이는 POSIX 셸 또는 systemd와 같은 도구일 수 
+있다.
+
+배포판과 무관한(distroless) 컨테이너 또는 윈도우 시스템 서비스와 같은 몇몇 경우에서, 
+위의 옵션은 사용할 수 없다. 
+그런 경우 출력을 리다이렉트하기 위해 
+[`kube-log-runner`](https://github.com/kubernetes/kubernetes/blob/d2a8a81639fcff8d1221b900f66d28361a170654/staging/src/k8s.io/component-base/logs/kube-log-runner/README.md) 
+바이너리를 쿠버네티스 컴포넌트의 래퍼(wrapper)로 사용할 수 있다. 
+미리 빌드된 바이너리가 몇몇 쿠버네티스 베이스 이미지에 기본 이름 `/go-runner` 와 
+서버 및 노드 릴리스 아카이브에는 `kube-log-runner`라는 이름으로 포함되어 있다.
+
+다음 표는 각 `kube-log-runner` 실행법이 어떤 셸 리다이렉션에 해당되는지 보여준다.
+
+| 사용법                                    | POSIX 셸 (예:) bash) | `kube-log-runner <options> <cmd>`                           |
+| -----------------------------------------|----------------------------|-------------------------------------------------------------|
+| stderr와 stdout을 합치고, stdout으로 출력 | `2>&1`                     | `kube-log-runner` (기본 동작))                        |
+| stderr와 stdout을 로그 파일에 기록              | `1>>/tmp/log 2>&1`         | `kube-log-runner -log-file=/tmp/log`                        |
+| 로그 파일에 기록하면서 stdout으로 출력        | `2>&1 \| tee -a /tmp/log`  | `kube-log-runner -log-file=/tmp/log -also-stdout`           |
+| stdout만 로그 파일에 기록      | `>/tmp/log`                | `kube-log-runner -log-file=/tmp/log -redirect-stderr=false` |
+
+### Klog 출력
+
 klog 네이티브 형식 예 : 
 ```
 I1025 00:15:15.525108       1 httplog.go:79] GET /api/v1/namespaces/kube-system/pods/metrics-server-v0.3.1-57c75779f-9p8wg: (1.512ms) 200 [pod_nanny/v0.0.0 (linux/amd64) kubernetes/$Format 10.56.1.19:51756]
 ```
 
+메시지 문자열은 줄바꿈을 포함하고 있을 수도 있다.
+```
+I1025 00:15:15.525108       1 example.go:79] This is a message
+which has a line break.
+```
+
+
 ### 구조화된 로깅
 
-{{< feature-state for_k8s_version="v1.19" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.23" state="beta" >}}
 
-{{<warning>}}
+{{< warning >}}
-구조화된 로그메시지로 마이그레이션은 진행중인 작업이다. 이 버전에서는 모든 로그 메시지가 구조화되지 않는다. 로그 파일을
+구조화된 로그메시지로 마이그레이션은 진행중인 작업이다. 이 버전에서는 모든 로그 메시지가 구조화되지 않는다. 로그 파일을 파싱할 때, 구조화되지 않은 로그 메시지도 처리해야 한다.
-파싱할 때, 구조화되지 않은 로그 메시지도 처리해야 한다.
 
 로그 형식 및 값 직렬화는 변경될 수 있다.
 {{< /warning>}}
@@ -42,7 +89,8 @@ I1025 00:15:15.525108       1 httplog.go:79] GET /api/v1/namespaces/kube-system/
 로그를 보다 쉽고 저렴하게 저장하고 처리하는 작업이다.
 새로운 메시지 형식은 이전 버전과 호환되며 기본적으로 활성화 된다.
 
-구조화된 로그 형식:
+구조화된 로그 메시지의 기본 형식은 텍스트이며, 
+기존 klog와 하위 호환되는 형식이다.
 
 ```ini
 <klog header> "<message>" <key1>="<value1>" <key2>="<value2>" ...
@@ -54,24 +102,28 @@ I1025 00:15:15.525108       1 httplog.go:79] GET /api/v1/namespaces/kube-system/
 I1025 00:15:15.525108       1 controller_utils.go:116] "Pod status updated" pod="kube-system/kubedns" status="ready"
 ```
 
+문자열은 따옴표로 감싸진다. 다른 값들은 
+[`%+v`](https://pkg.go.dev/fmt#hdr-Printing)로 포맷팅되며, 이로 인해 
+[데이터에 따라](https://github.com/kubernetes/kubernetes/issues/106428) 로그 메시지가 다음 줄로 이어질 수 있다.
+```
+I1025 00:15:15.525108       1 example.go:116] "Example" data="This is text with a line break\nand \"quotation marks\"." someInt=1 someFloat=0.1 someStruct={StringField: First line,
+second line.}
+```
 
 ### JSON 로그 형식
 
 {{< feature-state for_k8s_version="v1.19" state="alpha" >}}
 
 {{<warning >}}
-
 JSON 출력은 많은 표준 klog 플래그를 지원하지 않는다. 지원하지 않는 klog 플래그 목록은, [커맨드라인 툴](/ko/docs/reference/command-line-tools-reference/)을 참고한다.
 
-모든 로그가 JSON 형식으로 작성되는 것은 아니다(예: 프로세스 시작 중). 로그를 파싱하려는 경우
+모든 로그가 JSON 형식으로 작성되는 것은 아니다(예: 프로세스 시작 중). 로그를 파싱하려는 경우 JSON 형식이 아닌 로그 행을 처리할 수 있는지 확인해야 한다.
-JSON 형식이 아닌 로그 행을 처리할 수 있는지 확인해야 한다.
 
 필드 이름과 JSON 직렬화는 변경될 수 있다.
 {{< /warning >}}
 
 `--logging-format=json` 플래그는 로그 형식을 klog 기본 형식에서 JSON 형식으로 변경한다.
-JSON 로그 형식 예시(보기좋게 출력된 형태):
+JSON 로그 형식 예시(보기좋게 출력된 형태)는 다음과 같다.
-
 ```json
 {
    "ts": 1580306777.04728,
@@ -106,9 +158,8 @@ JSON 로그 형식 예시(보기좋게 출력된 형태):
 로그 정리(sanitization)는 상당한 오버 헤드를 발생시킬 수 있으므로 프로덕션 환경에서는 사용하지 않아야한다.
 {{< /warning >}}
 
- `--experimental-logging-sanitization` 플래그는 klog 정리(sanitization) 필터를 활성화 한다.
+ `--experimental-logging-sanitization` 플래그는 klog 정리(sanitization) 필터를 활성화한다.
-활성화된 경우 모든 로그 인자에서 민감한 데이터(예: 비밀번호, 키, 토큰)가 표시된 필드를 검사하고
+활성화된 경우 모든 로그 인자에서 민감한 데이터(예: 비밀번호, 키, 토큰)가 표시된 필드를 검사하고 이러한 필드의 로깅이 방지된다.
-이러한 필드의 로깅이 방지된다.
 
 현재 로그 정리(sanitization)를 지원하는 컴포넌트 목록:
 * kube-controller-manager
@@ -122,16 +173,17 @@ JSON 로그 형식 예시(보기좋게 출력된 형태):
 
 ### 로그 상세 레벨(verbosity)
 
-`-v` 플래그로 로그 상세 레벨(verbosity)을 제어한다. 값을 늘리면 기록된 이벤트 수가 증가한다. 값을 줄이면
+`-v` 플래그로 로그 상세 레벨(verbosity)을 제어한다. 값을 늘리면 기록된 이벤트 수가 증가한다. 값을 줄이면 기록된 이벤트 수가 줄어든다.
-기록된 이벤트 수가 줄어든다.
 로그 상세 레벨(verbosity)를 높이면 점점 덜 심각한 이벤트가 기록된다. 로그 상세 레벨(verbosity)을 0으로 설정하면 중요한 이벤트만 기록된다.
 
 ### 로그 위치
 
-시스템 컴포넌트에는 컨테이너에서 실행되는 것과 컨테이너에서 실행되지 않는 두 가지 유형이 있다.  예를 들면 다음과 같다.
+시스템 컴포넌트에는 컨테이너에서 실행되는 것과 컨테이너에서 실행되지 않는 두 가지 유형이 있다.
+예를 들면 다음과 같다.
 
 * 쿠버네티스 스케줄러와 kube-proxy는 컨테이너에서 실행된다.
-* kubelet과 컨테이너 런타임(예: 도커)은 컨테이너에서 실행되지 않는다.
+* kubelet과 {{<glossary_tooltip term_id="container-runtime" text="컨테이너 런타임">}}은 
+  컨테이너에서 실행되지 않는다.
 
 systemd를 사용하는 시스템에서는, kubelet과 컨테이너 런타임은 jounald에 기록한다.
 그 외 시스템에서는, `/var/log` 디렉터리의 `.log` 파일에 기록한다.
@@ -145,4 +197,5 @@ systemd를 사용하는 시스템에서는, kubelet과 컨테이너 런타임은
 
 * [쿠버네티스 로깅 아키텍처](/ko/docs/concepts/cluster-administration/logging/) 알아보기
 * [구조화된 로깅](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/1602-structured-logging) 알아보기
+* [klog 플래그 사용 중단](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/2845-deprecate-klog-specific-flags-in-k8s-components) 알아보기
 * [로깅 심각도(serverity) 규칙](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md) 알아보기

content/ko/docs/concepts/configuration/configmap.md

@@ -239,6 +239,10 @@ kubelet은 모든 주기적인 동기화에서 마운트된 컨피그맵이 최
 
 환경 변수로 사용되는 컨피그맵은 자동으로 업데이트되지 않으며 파드를 다시 시작해야 한다.
 
+{{< note >}}
+컨피그맵을 [subPath](/ko/docs/concepts/storage/volumes/#using-subpath) 볼륨 마운트로 사용하는 컨테이너는 컨피그맵 업데이트를 받지 못할 것이다.
+{{< /note >}}
+
 ## 변경할 수 없는(immutable) 컨피그맵 {#configmap-immutable}
 
 {{< feature-state for_k8s_version="v1.21" state="stable" >}}