[ko] Update outdated files in dev-1.21-ko.1 (p5)

2021-04-17 16:25:40 +09:00
parent 5d949f9e5b
commit 6338d1b811
36 changed files with 644 additions and 201 deletions
@@ -16,6 +16,7 @@ content_type: concept
 ## 네트워킹과 네트워크 폴리시

 * [ACI](https://www.github.com/noironetworks/aci-containers)는 Cisco ACI로 통합 컨테이너 네트워킹 및 네트워크 보안을 제공한다.
+* [Antrea](https://antrea.io/)는 레이어 3/4에서 작동하여 쿠버네티스를 위한 네트워킹 및 보안 서비스를 제공하며, Open vSwitch를 네트워킹 데이터 플레인으로 활용한다.
 * [Calico](https://docs.projectcalico.org/latest/introduction/)는 네트워킹 및 네트워크 폴리시 제공자이다. Calico는 유연한 네트워킹 옵션을 지원하므로 BGP 유무에 관계없이 비-오버레이 및 오버레이 네트워크를 포함하여 가장 상황에 맞는 옵션을 선택할 수 있다. Calico는 동일한 엔진을 사용하여 서비스 메시 계층(service mesh layer)에서 호스트, 파드 및 (이스티오(istio)와 Envoy를 사용하는 경우) 애플리케이션에 대한 네트워크 폴리시를 적용한다.
 * [Canal](https://github.com/tigera/canal/tree/master/k8s-install)은 Flannel과 Calico를 통합하여 네트워킹 및 네트워크 폴리시를 제공한다.
 * [Cilium](https://github.com/cilium/cilium)은 L3 네트워크 및 네트워크 폴리시 플러그인으로 HTTP/API/L7 폴리시를 투명하게 시행할 수 있다. 라우팅 및 오버레이/캡슐화 모드를 모두 지원하며, 다른 CNI 플러그인 위에서 작동할 수 있다.
@@ -83,12 +83,15 @@ kubectl logs counter
 [`configure-helper` 스크립트](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh)를 통해
 자세히 알 수 있다.

+**CRI 컨테이너 런타임** 을 사용할 때, kubelet은 로그를 로테이션하고 로깅 디렉터리 구조를 관리한다. kubelet은
+이 정보를 CRI 컨테이너 런타임에 전송하고 런타임은 컨테이너 로그를 지정된 위치에 기록한다. 두 개의 kubelet 플래그 `container-log-max-size` 및 `container-log-max-files` 를 사용하여 각 로그 파일의 최대 크기와 각 컨테이너에 허용되는 최대 파일 수를 각각 구성할 수 있다.
+
 기본 로깅 예제에서와 같이 [`kubectl logs`](/docs/reference/generated/kubectl/kubectl-commands#logs)를
 실행하면, 노드의 kubelet이 요청을 처리하고
 로그 파일에서 직접 읽는다. kubelet은 로그 파일의 내용을 반환한다.

 {{< note >}}
-만약, 일부 외부 시스템이 로테이션을 수행한 경우,
+만약, 일부 외부 시스템이 로테이션을 수행했거나 CRI 컨테이너 런타임이 사용된 경우,
 `kubectl logs` 를 통해 최신 로그 파일의 내용만
 사용할 수 있다. 예를 들어, 10MB 파일이 있으면, `logrotate` 가
 로테이션을 수행하고 두 개의 파일이 생긴다. (크기가 10MB인 파일 하나와 비어있는 파일)
@@ -278,7 +278,7 @@ pod/my-nginx-2035384211-u3t6x labeled
 ```

 먼저 "app=nginx" 레이블이 있는 모든 파드를 필터링한 다음, "tier=fe" 레이블을 지정한다.
-방금 레이블을 지정한 파드를 보려면, 다음을 실행한다.
+레이블을 지정한 파드를 보려면, 다음을 실행한다.

 ```shell
 kubectl get pods -l app=nginx -L tier
@@ -39,7 +39,7 @@ weight: 90
    - UDP, TCP, SCTP를 이용하여 프락시 한다.
    - HTTP는 이해하지 못한다.
    - 로드 밸런싱을 제공한다.
-    - 단지 서비스에 도달하는데 사용한다.
+    - 서비스에 도달하는데만 사용한다.

 1.  API 서버 앞단의 프락시/로드밸런서

@@ -61,7 +61,3 @@ weight: 90
 ## 요청을 리다이렉트하기

 프락시는 리다이렉트 기능을 대체했다. 리다이렉트는 더 이상 사용하지 않는다.
-
-
-
-
@@ -130,7 +130,7 @@ cloudprovider_gce_api_request_duration_seconds { request = "list_disk"}

 ### kube-scheduler 메트릭

-{{< feature-state for_k8s_version="v1.20" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.21" state="beta" >}}

 스케줄러는 실행 중인 모든 파드의 요청(request)된 리소스와 요구되는 제한(limit)을 보고하는 선택적 메트릭을 노출한다. 이러한 메트릭은 용량 계획(capacity planning) 대시보드를 구축하고, 현재 또는 과거 스케줄링 제한을 평가하고, 리소스 부족으로 스케줄할 수 없는 워크로드를 빠르게 식별하고, 실제 사용량을 파드의 요청과 비교하는 데 사용할 수 있다.

@@ -148,6 +148,24 @@ kube-scheduler는 각 파드에 대해 구성된 리소스 [요청과 제한](/k
 메트릭은 HTTP 엔드포인트 `/metrics/resources`에 노출되며 스케줄러의 `/metrics` 엔드포인트
 와 동일한 인증이 필요하다. 이러한 알파 수준의 메트릭을 노출시키려면 `--show-hidden-metrics-for-version=1.20` 플래그를 사용해야 한다.

+## 메트릭 비활성화
+
+커맨드 라인 플래그 `--disabled-metrics` 를 통해 메트릭을 명시적으로 끌 수 있다. 이 방법이 필요한 이유는 메트릭이 성능 문제를 일으키는 경우을 예로 들 수 있다. 입력값은 비활성화되는 메트릭 목록이다(예: `--disabled-metrics=metric1,metric2`).
+
+## 메트릭 카디널리티(cardinality) 적용
+
+제한되지 않은 차원의 메트릭은 계측하는 컴포넌트에서 메모리 문제를 일으킬 수 있다. 리소스 사용을 제한하려면, `--allow-label-value` 커맨드 라인 옵션을 사용하여 메트릭 항목에 대한 레이블 값의 허용 목록(allow-list)을 동적으로 구성한다.
+
+알파 단계에서, 플래그는 메트릭 레이블 허용 목록으로 일련의 매핑만 가져올 수 있다.
+각 매핑은 `<metric_name>,<label_name>=<allowed_labels>` 형식이다. 여기서
+`<allowed_labels>` 는 허용되는 레이블 이름의 쉼표로 구분된 목록이다.
+
+전체 형식은 다음과 같다.
+`--allow-label-value <metric_name>,<label_name>='<allow_value1>, <allow_value2>...', <metric_name2>,<label_name>='<allow_value1>, <allow_value2>...', ...`.
+
+예시는 다음과 같다.
+`--allow-label-value number_count_metric,odd_number='1,3,5', number_count_metric,even_number='2,4,6', date_gauge_metric,weekend='Saturday,Sunday'`
+

 ## {{% heading "whatsnext" %}}