Merge pull request #29160 from seokho-son/out1-1.21-ko.7

[ko] Update outdated files in dev-1.21-ko.7 (p1)
2021-08-04 15:55:12 -07:00
parent 4af87260d3 25f168f2f6
commit 2c66264fab
10 changed files with 65 additions and 43 deletions
@@ -210,7 +210,7 @@ rules:

 자체 클라우드 컨트롤러 매니저를 구현하거나 기존 프로젝트를 확장하는 방법을 알고 싶은가?

-클라우드 컨트롤러 매니저는 Go 인터페이스를 사용해서 모든 클라우드 플러그인을 구현할 수 있다. 구체적으로, [kubernetes/cloud-provider](https://github.com/kubernetes/cloud-provider)의 [`cloud.go`](https://github.com/kubernetes/cloud-provider/blob/release-1.17/cloud.go#L42-L62)에 정의된 `CloudProvider` 인터페이스를 사용한다.
+클라우드 컨트롤러 매니저는 Go 인터페이스를 사용함으로써, 어떠한 클라우드에 대한 구현체(implementation)라도 플러그인 될 수 있도록 한다. 구체적으로는, [kubernetes/cloud-provider](https://github.com/kubernetes/cloud-provider)의 [`cloud.go`](https://github.com/kubernetes/cloud-provider/blob/release-1.21/cloud.go#L42-L69)에 정의된 `CloudProvider` 인터페이스를 사용한다.

 이 문서(노드, 라우트와 서비스)에서 강조된 공유 컨트롤러의 구현과 공유 cloudprovider 인터페이스와 함께 일부 스캐폴딩(scaffolding)은 쿠버네티스 핵심의 일부이다. 클라우드 공급자 전용 구현은 쿠버네티스의 핵심 바깥에 있으며 `CloudProvider` 인터페이스를 구현한다.

@@ -83,8 +83,11 @@ 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` 를 사용하여 각 로그 파일의 최대 크기와 각 컨테이너에 허용되는 최대 파일 수를 각각 구성할 수 있다.
+**CRI 컨테이너 런타임** 을 사용할 때, kubelet은 로그를 로테이션하고 로깅 디렉터리 구조를 관리한다.
+kubelet은 이 정보를 CRI 컨테이너 런타임에 전송하고 런타임은 컨테이너 로그를 지정된 위치에 기록한다.
+[kubelet config file](/docs/tasks/administer-cluster/kubelet-config-file/)에 있는
+두 개의 kubelet 파라미터 [`containerLogMaxSize` 및 `containerLogMaxFiles`](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)를
+사용하여 각 로그 파일의 최대 크기와 각 컨테이너에 허용되는 최대 파일 수를 각각 구성할 수 있다.

 기본 로깅 예제에서와 같이 [`kubectl logs`](/docs/reference/generated/kubectl/kubectl-commands#logs)를
 실행하면, 노드의 kubelet이 요청을 처리하고
@@ -1156,8 +1156,8 @@ HTTP 요청을 처리하고, 복잡한 비즈니스 로직을 수행한 다음,

 ### 시크릿 API를 사용하는 클라이언트

-시크릿 API와 상호 작용하는 애플리케이션을 배포할 때, 
-[RBAC](/docs/reference/access-authn-authz/rbac/)과 같은 
+시크릿 API와 상호 작용하는 애플리케이션을 배포할 때,
+[RBAC](/docs/reference/access-authn-authz/rbac/)과 같은
 [인가 정책](/ko/docs/reference/access-authn-authz/authorization/)을
 사용하여 접근을 제한해야 한다.

@@ -1235,10 +1235,6 @@ API 서버에서 kubelet으로의 통신은 SSL/TLS로 보호된다.
 - 시크릿을 사용하는 파드를 생성할 수 있는 사용자는 해당 시크릿의 값도 볼 수 있다.
   API 서버 정책이 해당 사용자가 시크릿을 읽을 수 있도록 허용하지 않더라도, 사용자는
   시크릿을 노출하는 파드를 실행할 수 있다.
- - 현재, 모든 노드에 대한 루트 권한이 있는 모든 사용자는 kubelet을 가장하여
-   API 서버에서 _모든_ 시크릿을 읽을 수 있다. 단일 노드에 대한 루트 취약점 공격의
-   영향을 제한하기 위해, 실제로 필요한 노드에만 시크릿을 보내는 것이 앞으로 계획된
-   기능이다.


 ## {{% heading "whatsnext" %}}
@@ -51,8 +51,7 @@ weight: 30
 * 내부 멤버 선출 절차없이 분산 애플리케이션의
  리더를 선택

-오퍼레이터의 모습을 더 자세하게 볼 수 있는 방법은 무엇인가? 자세한 예는
-다음과 같다.
+오퍼레이터의 모습을 더 자세하게 볼 수 있는 방법은 무엇인가? 예시는 다음과 같다.

 1. 클러스터에 구성할 수 있는 SampleDB라는 사용자 정의 리소스.
 2. 오퍼레이터의 컨트롤러 부분이 포함된 파드의 실행을
@@ -1,4 +1,9 @@
 ---
+
+
+
+
+
 title: 스토리지 클래스
 content_type: concept
 weight: 30
@@ -184,7 +189,7 @@ CSI | 1.14 (alpha), 1.16 (beta)
 CSI 드라이버에 대한 문서를 본다.

 {{< note >}}
-   `waitForFirstConsumer`를 사용한다면, 노드 어피니티를 지정하기 위해서 파드 스펙에 `nodeName`을 사용하지는 않아야 한다.
+   `WaitForFirstConsumer`를 사용한다면, 노드 어피니티를 지정하기 위해서 파드 스펙에 `nodeName`을 사용하지는 않아야 한다.
   만약 `nodeName`을 사용한다면, 스케줄러가 바이패스되고 PVC가 `pending` 상태로 있을 것이다.

   대신, 아래와 같이 호스트네임을 이용하는 노드셀렉터를 사용할 수 있다.
@@ -304,13 +304,23 @@ kubelet은 실행 중인 컨테이너들에 대해서 선택적으로 세 가지
 보일 수도 있지만, 스팩에 준비성 프로브가 존재한다는 것은 파드가
 트래픽을 받지 않는 상태에서 시작되고 프로브가 성공하기 시작한 이후에만
 트래픽을 받는다는 뜻이다.
-만약 컨테이너가 대량의 데이터, 설정 파일들,
-또는 시동 중 마그레이션을 처리해야 한다면, 준비성 프로브를 지정하길 바란다.

-만약 당신의 컨테이너가 유지 관리를 위해서 자체 중단되게 하려면,
+만약 컨테이너가 유지 관리를 위해서 자체 중단되게 하려면,
 준비성 프로브를 지정하길 바란다.
 준비성 프로브는 활성 프로브와는 다르게 준비성에 특정된 엔드포인트를 확인한다.

+만약 애플리케이션이 백엔드 서비스에 엄격한 의존성이 있다면,
+활성 프로브와 준비성 프로브 모두 활용할 수도 있다. 활성 프로브는 애플리케이션 스스로가 건강한 상태면
+통과하지만, 준비성 프로브는 추가적으로 요구되는 각 백-엔드 서비스가 가용한지 확인한다. 이를 이용하여,
+오류 메시지만 응답하는 파드로
+트래픽이 가는 것을 막을 수 있다.
+
+만약 컨테이너가 시동 시 대량 데이터의 로딩, 구성 파일, 또는
+마이그레이션에 대한 작업을
+수행해야 한다면, [스타트업 프로브](#언제-스타트업-프로브를-사용해야-하는가)를 사용하면 된다. 그러나, 만약
+failed 애플리케이션과 시동 중에 아직 데이터를 처리하고 있는 애플리케이션을 구분하여 탐지하고
+싶다면, 준비성 프로브를 사용하는 것이 더 적합할 것이다.
+
 {{< note >}}
 파드가 삭제될 때 요청들을 흘려 보내기(drain) 위해
 준비성 프로브가 꼭 필요한 것은 아니다. 삭제 시에, 파드는