kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Update outdated files in dev-1.21-ko.7 (p1)

pull/29160/head
seokho-son 2021-07-30 14:49:06 +09:00
parent 1c15c9167e
commit 25f168f2f6
10 changed files with 65 additions and 43 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
content/ko/docs/concepts/architecture/cloud-controller.md
View File

@ -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` 인터페이스를 구현한다.

7
content/ko/docs/concepts/cluster-administration/logging.md
View File

@ -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이 요청을 처리하고

8
content/ko/docs/concepts/configuration/secret.md
View File

@ -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" %}}

3
content/ko/docs/concepts/extend-kubernetes/operator.md
View File

@ -51,8 +51,7 @@ weight: 30
* 내부 멤버 선출 절차없이 분산 애플리케이션의
리더를 선택
오퍼레이터의 모습을 더 자세하게 볼 수 있는 방법은 무엇인가? 자세한 예는
다음과 같다.
오퍼레이터의 모습을 더 자세하게 볼 수 있는 방법은 무엇인가? 예시는 다음과 같다.
1. 클러스터에 구성할 수 있는 SampleDB라는 사용자 정의 리소스.
2. 오퍼레이터의 컨트롤러 부분이 포함된 파드의 실행을

7
content/ko/docs/concepts/storage/storage-classes.md
View File

@ -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` 상태로 있을 것이다.
대신, 아래와 같이 호스트네임을 이용하는 노드셀렉터를 사용할 수 있다.

16
content/ko/docs/concepts/workloads/pods/pod-lifecycle.md
View File

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

25
content/ko/docs/reference/_index.md
View File

@ -9,6 +9,7 @@ content_type: concept
no_list: true
---
<!-- overview -->
쿠버네티스 문서의 본 섹션에서는 레퍼런스를 다룬다.
@ -48,26 +49,26 @@ no_list: true
## 컴포넌트
* [kubelet](/docs/reference/command-line-tools-reference/kubelet/) - 각
노드에서 구동되는 주요한 에이전트. kubelet은 PodSpecs 집합을 가지며
* [kubelet](/docs/reference/command-line-tools-reference/kubelet/) - 각
노드에서 구동되는 주요한 에이전트. kubelet은 PodSpecs 집합을 가지며
기술된 컨테이너가 구동되고 있는지, 정상 작동하는지를 보장한다.
* [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/) -
파드, 서비스, 레플리케이션 컨트롤러와 같은 API 오브젝트에 대한 검증과 구성을
* [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/) -
파드, 서비스, 레플리케이션 컨트롤러와 같은 API 오브젝트에 대한 검증과 구성을
수행하는 REST API.
* [kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/) - 쿠버네티스에 탑재된 핵심 제어 루프를 포함하는 데몬.
* [kube-proxy](/ko/docs/reference/command-line-tools-reference/kube-proxy/) - 간단한
TCP/UDP 스트림 포워딩이나 백-엔드 집합에 걸쳐서 라운드-로빈 TCP/UDP 포워딩을
* [kube-proxy](/ko/docs/reference/command-line-tools-reference/kube-proxy/) - 간단한
TCP/UDP 스트림 포워딩이나 백-엔드 집합에 걸쳐서 라운드-로빈 TCP/UDP 포워딩을
할 수 있다.
* [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/) - 가용성, 성능 및 용량을 관리하는 스케줄러.
* [kube-scheduler 정책](/ko/docs/reference/scheduling/policies)
* [kube-scheduler 프로파일](/ko/docs/reference/scheduling/config/#여러-프로파일)
## 환경설정 API
## API 설정
이 섹션은 쿠버네티스 구성요소 또는 도구를 환경설정하는 데에 사용되는
"미발표된" API를 다룬다. 이 API들은 사용자나 관리자가 클러스터를
사용/관리하는 데에 중요하지만, 이들 API의 대부분은 아직 API 서버가
이 섹션은 쿠버네티스 구성요소 또는 도구를 환경설정하는 데에 사용되는
"미발표된" API를 다룬다. 이 API들은 사용자나 관리자가 클러스터를
사용/관리하는 데에 중요하지만, 이들 API의 대부분은 아직 API 서버가
제공하지 않는다.
* [kubelet 환경설정 (v1beta1)](/docs/reference/config-api/kubelet-config.v1beta1/)
@ -78,6 +79,10 @@ TCP/UDP 스트림 포워딩이나 백-엔드 집합에 걸쳐서 라운드-로
* [클라이언트 인증 API (v1beta1)](/docs/reference/config-api/client-authentication.v1beta1/)
* [WebhookAdmission 환경설정 (v1)](/docs/reference/config-api/apiserver-webhookadmission.v1/)
## kubeadm을 위한 API 설정
* [v1beta2](/docs/reference/config-api/kubeadm-config.v1beta2/)
## 설계 문서
쿠버네티스 기능에 대한 설계 문서의 아카이브.

13
content/ko/docs/reference/command-line-tools-reference/feature-gates.md
View File

@ -61,6 +61,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `BalanceAttachedNodeVolumes` | `false` | 알파 | 1.11 | |
| `BoundServiceAccountTokenVolume` | `false` | 알파 | 1.13 | 1.20 |
| `BoundServiceAccountTokenVolume` | `true` | 베타 | 1.21 | |
| `ControllerManagerLeaderMigration` | `false` | 알파 | 1.21 | |
| `CPUManager` | `false` | 알파 | 1.8 | 1.9 |
| `CPUManager` | `true` | 베타 | 1.10 | |
| `CSIInlineVolume` | `false` | 알파 | 1.15 | 1.15 |
@ -379,7 +380,6 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `TokenRequestProjection` | `false` | 알파 | 1.11 | 1.11 |
| `TokenRequestProjection` | `true` | 베타 | 1.12 | 1.19 |
| `TokenRequestProjection` | `true` | GA | 1.20 | - |
| `VolumeCapacityPriority` | `false` | 알파 | 1.21 | - |
| `VolumePVCDataSource` | `false` | 알파 | 1.15 | 1.15 |
| `VolumePVCDataSource` | `true` | 베타 | 1.16 | 1.17 |
| `VolumePVCDataSource` | `true` | GA | 1.18 | - |
@ -479,6 +479,11 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
`kube-apiserver`를 시작하여 확장 토큰 기능을 끈다.
자세한 내용은 [바운드 서비스 계정 토큰](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/1205-bound-service-account-tokens/README.md)을
확인한다.
- `ControllerManagerLeaderMigration`: HA 클러스터에서 클러스터 오퍼레이터가
kube-controller-manager의 컨트롤러들을 외부 controller-manager(예를 들면,
cloud-controller-manager)로 다운타임 없이 라이브 마이그레이션할 수 있도록 허용하도록
[kube-controller-manager](/docs/tasks/administer-cluster/controller-manager-leader-migration/#initial-leader-migration-configuration)와 [cloud-controller-manager](/docs/tasks/administer-cluster/controller-manager-leader-migration/#deploy-cloud-controller-manager)의
리더 마이그레이션(Leader Migration)을 활성화한다.
- `CPUManager`: 컨테이너 수준의 CPU 어피니티 지원을 활성화한다.
[CPU 관리 정책](/docs/tasks/administer-cluster/cpu-management-policies/)을 참고한다.
- `CRIContainerLogRotation`: cri 컨테이너 런타임에 컨테이너 로그 로테이션을 활성화한다. 로그 파일 사이즈 기본값은 10MB이며,
@ -637,7 +642,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
- `ExperimentalCriticalPodAnnotation`: 특정 파드에 *critical* 로
어노테이션을 달아서 [스케줄링이 보장되도록](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/) 한다.
이 기능은 v1.13부터 파드 우선 순위 및 선점으로 인해 사용 중단되었다.
- `ExperimentalHostUserNamespaceDefaultingGate`: 사용자 네임스페이스를 호스트로
- `ExperimentalHostUserNamespaceDefaulting`: 사용자 네임스페이스를 호스트로
기본 활성화한다. 이것은 다른 호스트 네임스페이스, 호스트 마운트,
권한이 있는 컨테이너 또는 특정 비-네임스페이스(non-namespaced) 기능(예: `MKNODE`, `SYS_MODULE` 등)을
사용하는 컨테이너를 위한 것이다. 도커 데몬에서 사용자 네임스페이스
@ -764,6 +769,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
- `RotateKubeletClientCertificate`: kubelet에서 클라이언트 TLS 인증서의 로테이션을 활성화한다.
자세한 내용은 [kubelet 구성](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#kubelet-configuration)을 참고한다.
- `RotateKubeletServerCertificate`: kubelet에서 서버 TLS 인증서의 로테이션을 활성화한다.
자세한 사항은
[kubelet 구성](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#kubelet-configuration)을 확인한다.
- `RunAsGroup`: 컨테이너의 init 프로세스에 설정된 기본 그룹 ID 제어를
활성화한다.
- `RuntimeClass`: 컨테이너 런타임 구성을 선택하기 위해 [런타임클래스(RuntimeClass)](/ko/docs/concepts/containers/runtime-class/)
@ -794,6 +801,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
- `SetHostnameAsFQDN`: 전체 주소 도메인 이름(FQDN)을 파드의 호스트 이름으로
설정하는 기능을 활성화한다.
[파드의 `setHostnameAsFQDN` 필드](/ko/docs/concepts/services-networking/dns-pod-service/#pod-sethostnameasfqdn-field)를 참고한다.
- `SizeMemoryBackedVolumes`: memory-backed 볼륨(보통 `emptyDir` 볼륨)의 크기 상한을
지정할 수 있도록 kubelets를 활성화한다.
- `StartupProbe`: kubelet에서
[스타트업](/ko/docs/concepts/workloads/pods/pod-lifecycle/#언제-스타트업-프로브를-사용해야-하는가)
프로브를 활성화한다.

10
content/ko/docs/reference/glossary/kube-controller-manager.md
View File

@ -4,15 +4,15 @@ id: kube-controller-manager
date: 2018-04-12
full_link: /docs/reference/command-line-tools-reference/kube-controller-manager/
short_description: >
{{< glossary_tooltip text="컨트롤러" term_id="controller" >}} 프로세스를 실행하는 컨트롤 플레인 컴포넌트.
컨트롤러 프로세스를 실행하는 컨트롤 플레인 컴포넌트.
aka:
aka:
tags:
- architecture
- fundamental
---
{{< glossary_tooltip text="컨트롤러" term_id="controller" >}}를 구동하는 마스터 상의 컴포넌트.
{{< glossary_tooltip text="컨트롤러" term_id="controller" >}} 프로세스를 실행하는 컨트롤 플레인 컴포넌트.
<!--more-->
<!--more-->
논리적으로, 각 {{< glossary_tooltip text="컨트롤러" term_id="controller" >}}는 개별 프로세스이지만, 복잡성을 낮추기 위해 모두 단일 바이너리로 컴파일되고 단일 프로세스 내에서 실행된다.
논리적으로, 각 {{< glossary_tooltip text="컨트롤러" term_id="controller" >}}는 분리된 프로세스이지만, 복잡성을 낮추기 위해 모두 단일 바이너리로 컴파일되고 단일 프로세스 내에서 실행된다.

17
content/ko/docs/reference/tools/_index.md
View File

@ -1,8 +1,10 @@
---
title: 도구
content_type: concept
weight: 80
no_list: true
---
<!-- overview -->
@ -10,13 +12,6 @@ content_type: concept
<!-- body -->
## Kubectl
[`kubectl`](/ko/docs/tasks/tools/#kubectl)은 쿠버네티스를 위한 커맨드라인 툴이며, 쿠버네티스 클러스터 매니저을 제어한다.
## Kubeadm
[`kubeadm`](/ko/docs/setup/production-environment/tools/kubeadm/install-kubeadm/)은 물리적 환경, 클라우드 서버, 또는 가상머신 상에서 안전한 쿠버네티스를 쉽게 프로비저닝하기 위한 커맨드라인 툴이다(현재는 알파 상태).
## Minikube
@ -31,8 +26,8 @@ content_type: concept
## Helm
[`쿠버네티스 Helm`](https://github.com/kubernetes/helm)은 사전 구성된 쿠버네티스 리소스를 관리하기위한 도구이며
또한 Helm의 쿠버네티스 차트라고도 한다.
[Helm](https://helm.sh/)은 사전 구성된 쿠버네티스 리소스 패키지를 관리하기 위한 도구이다.
이 패키지는 _Helm charts_ 라고 알려져 있다.
Helm의 용도