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

[ko] Remove invisible chars

pull/31762/head
Jihoon Seo 2022-02-16 14:25:35 +09:00
parent b7e6cf5d55
commit 0f1e8df67f
16 changed files with 21 additions and 21 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -160,7 +160,7 @@ systemd를 사용하지 않으면, kubelet과 컨테이너 런타임은 `/var/lo
각 사이드카 컨테이너는 자체 `stdout` 또는 `stderr` 스트림에 로그를 출력한다.
이 방법을 사용하면 애플리케이션의 다른 부분에서 여러 로그 스트림을
분리할 수 ​​있고, 이 중 일부는 `stdout` 또는 `stderr` 에
분리할 수 있고, 이 중 일부는 `stdout` 또는 `stderr` 에
작성하기 위한 지원이 부족할 수 있다. 로그를 리디렉션하는 로직은
최소화되어 있기 때문에, 심각한 오버헤드가 아니다. 또한,
`stdout` 및 `stderr` 가 kubelet에서 처리되므로, `kubectl logs` 와 같은

2
content/ko/docs/concepts/cluster-administration/manage-deployment.md
View File

@ -397,7 +397,7 @@ deployment.apps/my-nginx configured
rm /tmp/nginx.yaml
```
이를 통해 보다 중요한 변경을 더 쉽게 ​​수행할 수 있다. 참고로 `EDITOR` 또는 `KUBE_EDITOR` 환경 변수를 사용하여 편집기를 지정할 수 있다.
이를 통해 보다 중요한 변경을 더 쉽게 수행할 수 있다. 참고로 `EDITOR` 또는 `KUBE_EDITOR` 환경 변수를 사용하여 편집기를 지정할 수 있다.
더 자세한 내용은, [kubectl edit](/docs/reference/generated/kubectl/kubectl-commands/#edit) 문서를 참고하길 바란다.

4
content/ko/docs/concepts/configuration/manage-resources-containers.md
View File

@ -618,7 +618,7 @@ spec:
파드가 배치될 수 있는 노드를 스케줄러가 찾을 수 없으면, 노드를
찾을 수 있을 때까지 파드는 스케줄되지 않은 상태로 유지한다. 스케줄러가 다음과 같이
파드의 위치를 ​​찾지 못하면 이벤트가 생성된다.
파드의 위치를 찾지 못하면 이벤트가 생성된다.
```shell
kubectl describe pod frontend | grep -A 3 Events
@ -673,7 +673,7 @@ Allocated resources:
680m (34%) 400m (20%) 920Mi (11%) 1070Mi (13%)
```
위의 출력에서, ​파드가 1120m 이상의 CPU 또는 6.23Gi의 메모리를
위의 출력에서, 파드가 1120m 이상의 CPU 또는 6.23Gi의 메모리를
요청하는 것은 노드에 맞지 않음을 알 수 있다.
`Pods` 섹션을 살펴보면, 파드가 노드에서 공간을 차지하는 것을

2
content/ko/docs/concepts/containers/_index.md
View File

@ -13,7 +13,7 @@ no_list: true
의미한다.
컨테이너는 기본 호스트 인프라에서 애플리케이션을 분리한다.
따라서 다양한 클라우드 또는 OS 환경에서 보다 쉽게 ​​배포할 수 있다.
따라서 다양한 클라우드 또는 OS 환경에서 보다 쉽게 배포할 수 있다.

2
content/ko/docs/concepts/containers/images.md
View File

@ -436,7 +436,7 @@ imagePullSecrets을 셋팅하여 자동화할 수 있다.
- 위에 설명된 바와 같이 수동으로 .docker/config.json을 구성한다.
- 또는, 방화벽 뒤에서 읽기 접근 권한을 가진 내부 프라이빗 레지스트리를 실행한다.
- 쿠버네티스 구성은 필요 없다.
- 이미지 접근을 제어하는 ​​호스팅된 컨테이너 이미지 레지스트리 서비스를 사용한다.
- 이미지 접근을 제어하는 호스팅된 컨테이너 이미지 레지스트리 서비스를 사용한다.
- 그것은 수동 노드 구성에 비해서 클러스터 오토스케일링과 더 잘 동작할 것이다.
- 또는, 노드의 구성 변경이 불편한 클러스터에서는, `imagePullSecrets`를 사용한다.
1. 독점 이미지를 가진 클러스터로, 그 중 일부가 더 엄격한 접근 제어를 필요로 하는 경우.

4
content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md
View File

@ -145,7 +145,7 @@ CRD 오브젝트의 이름은 유효한
## API 서버 애그리게이션
일반적으로 쿠버네티스 API의 각 리소스에는 REST 요청을 처리하고 오브젝트의 퍼시스턴트 스토리지를 관리하는 코드가 필요하다. 주요 쿠버네티스 API 서버는 *파드* 및 *서비스* 와 같은 빌트인 리소스를 처리하고, 일반적으로 [CRD](#커스텀리소스데피니션)를 통해 커스텀 리소스를 처리할 수 ​​있다.
일반적으로 쿠버네티스 API의 각 리소스에는 REST 요청을 처리하고 오브젝트의 퍼시스턴트 스토리지를 관리하는 코드가 필요하다. 주요 쿠버네티스 API 서버는 *파드* 및 *서비스* 와 같은 빌트인 리소스를 처리하고, 일반적으로 [CRD](#커스텀리소스데피니션)를 통해 커스텀 리소스를 처리할 수 있다.
[애그리게이션 레이어](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)를 사용하면 자체 API 서버를
작성하고 배포하여 커스텀 리소스에 대한 특수한 구현을 제공할 수 있다.
@ -180,7 +180,7 @@ CRD는 애그리게이트 API보다 생성하기가 쉽다.
| ------- | ----------- | ---- | -------------- |
| 유효성 검사 | 사용자가 오류를 방지하고 클라이언트와 독립적으로 API를 발전시킬 수 있도록 도와준다. 이러한 기능은 동시에 많은 클라이언트를 모두 업데이트할 수 없는 경우에 아주 유용하다. | 예. [OpenAPI v3.0 유효성 검사](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation)를 사용하여 CRD에서 대부분의 유효성 검사를 지정할 수 있다. [웹훅 유효성 검사](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook-alpha-in-1-8-beta-in-1-9)를 추가해서 다른 모든 유효성 검사를 지원한다. | 예, 임의의 유효성 검사를 지원한다. |
| 기본 설정 | 위를 참고하자. | 예, [OpenAPI v3.0 유효성 검사](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#defaulting)의 `default` 키워드(1.17에서 GA) 또는 [웹훅 변형(mutating)](/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook)(이전 오브젝트의 etcd에서 읽을 때는 실행되지 않음)을 통해 지원한다. | 예 |
| 다중 버전 관리 | 두 가지 API 버전을 통해 동일한 오브젝트를 제공할 수 있다. 필드 이름 바꾸기와 같은 API 변경을 쉽게 할 수 있다. 클라이언트 버전을 제어하는 ​​경우는 덜 중요하다. | [예](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning) | 예 |
| 다중 버전 관리 | 두 가지 API 버전을 통해 동일한 오브젝트를 제공할 수 있다. 필드 이름 바꾸기와 같은 API 변경을 쉽게 할 수 있다. 클라이언트 버전을 제어하는 경우는 덜 중요하다. | [예](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning) | 예 |
| 사용자 정의 스토리지 | 다른 성능 모드(예를 들어, 키-값 저장소 대신 시계열 데이터베이스)나 보안에 대한 격리(예를 들어, 암호화된 시크릿이나 다른 암호화) 기능을 가진 스토리지가 필요한 경우 | 아니오 | 예 |
| 사용자 정의 비즈니스 로직 | 오브젝트를 생성, 읽기, 업데이트 또는 삭제를 할 때 임의의 점검 또는 조치를 수행한다. | 예, [웹훅](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)을 사용한다. | 예 |
| 서브리소스 크기 조정 | HorizontalPodAutoscaler 및 PodDisruptionBudget과 같은 시스템이 새로운 리소스와 상호 작용할 수 있다. | [예](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource) | 예 |

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

@ -302,7 +302,7 @@ NUMA 셀은 불분명한(opaque) 정수 ID를 사용하여 식별되며, 이 값
gRPC 서비스는 `/var/lib/kubelet/pod-resources/kubelet.sock` 의 유닉스 소켓을 통해 제공된다.
장치 플러그인 리소스에 대한 모니터링 에이전트는 데몬 또는 데몬셋으로 배포할 수 있다.
표준 디렉터리 `/var/lib/kubelet/pod-resources` 에는 특권을 가진 접근이 필요하므로, 모니터링
에이전트는 특권을 가진 ​​보안 컨텍스트에서 실행해야 한다. 장치 모니터링 에이전트가
에이전트는 특권을 가진 보안 컨텍스트에서 실행해야 한다. 장치 모니터링 에이전트가
데몬셋으로 실행 중인 경우, 해당 장치 모니터링 에이전트의 [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)에서
`/var/lib/kubelet/pod-resources` 를
{{< glossary_tooltip text="볼륨" term_id="volume" >}}으로 마운트해야 한다.

4
content/ko/docs/concepts/policy/pod-security-policy.md
View File

@ -21,7 +21,7 @@ weight: 30
## 파드 시큐리티 폴리시란?
_Pod Security Policy_ 는 파드 명세의 보안 관련 측면을 제어하는 ​​클러스터-레벨의
_Pod Security Policy_ 는 파드 명세의 보안 관련 측면을 제어하는 클러스터-레벨의
리소스이다. [파드시큐리티폴리시](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy) 오브젝트는
관련 필드에 대한 기본값뿐만 아니라 시스템에 적용하기 위해 파드가 실행해야만 하는
조건 셋을 정의한다. 관리자는
@ -195,7 +195,7 @@ API 서버 접근 제어에 대한 자세한 내용은
## 정책 순서
파드 생성 및 업데이트를 제한할 뿐만 아니라 파드 시큐리티 폴리시를 사용하여
제어하는 ​​많은 필드에 기본값을 제공할 수도 있다. 여러 정책을
제어하는 많은 필드에 기본값을 제공할 수도 있다. 여러 정책을
사용할 수 있는 경우 파드 시큐리티 폴리시 컨트롤러는
다음 기준에 따라 정책을 선택한다.

2
content/ko/docs/concepts/policy/resource-quotas.md
View File

@ -104,7 +104,7 @@ GPU 리소스를 다음과 같이 쿼터를 정의할 수 있다.
지정된 네임스페이스에서 요청할 수 있는 총 [스토리지 리소스](/ko/docs/concepts/storage/persistent-volumes/) 합을 제한할 수 있다.
또한 연관된 ​​스토리지 클래스를 기반으로 스토리지 리소스 사용을 제한할 수 있다.
또한 연관된 스토리지 클래스를 기반으로 스토리지 리소스 사용을 제한할 수 있다.
| 리소스 이름 | 설명 |
| --------------------- | ----------------------------------------------------------- |

2
content/ko/docs/concepts/services-networking/service.md
View File

@ -61,7 +61,7 @@ _서비스_ 로 들어가보자.
애플리케이션에서 서비스 디스커버리를 위해 쿠버네티스 API를 사용할 수 있는 경우,
서비스 내 파드 세트가 변경될 때마다 업데이트되는 엔드포인트를 {{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}}에
질의할 수 ​​있다.
질의할 수 있다.
네이티브 애플리케이션이 아닌 (non-native applications) 경우, 쿠버네티스는 애플리케이션과 백엔드 파드 사이에 네트워크 포트 또는 로드
밸런서를 배치할 수 있는 방법을 제공한다.

4
content/ko/docs/concepts/storage/persistent-volumes.md
View File

@ -73,8 +73,8 @@ API 서버 커맨드라인 플래그에 대한 자세한 정보는
일단 사용자에게 클레임이 있고 그 클레임이 바인딩되면, 바인딩된 PV는 사용자가 필요로 하는 한 사용자에게 속한다. 사용자는 파드의 `volumes` 블록에 `persistentVolumeClaim`을 포함하여 파드를 스케줄링하고 클레임한 PV에 접근한다. 이에 대한 자세한 내용은 [볼륨으로 클레임하기](#볼륨으로-클레임하기)를 참고하길 바란다.
### 사용 중인 스토리지 오브젝트 ​​보호
사용 중인 스토리지 오브젝트 ​​보호 기능의 목적은 PVC에 바인딩된 파드와 퍼시스턴트볼륨(PV)이 사용 중인 퍼시스턴트볼륨클레임(PVC)을 시스템에서 삭제되지 않도록 하는 것이다. 삭제되면 이로 인해 데이터의 손실이 발생할 수 있기 때문이다.
### 사용 중인 스토리지 오브젝트 보호
사용 중인 스토리지 오브젝트 보호 기능의 목적은 PVC에 바인딩된 파드와 퍼시스턴트볼륨(PV)이 사용 중인 퍼시스턴트볼륨클레임(PVC)을 시스템에서 삭제되지 않도록 하는 것이다. 삭제되면 이로 인해 데이터의 손실이 발생할 수 있기 때문이다.
{{< note >}}
PVC를 사용하는 파드 오브젝트가 존재하면 파드가 PVC를 사용하고 있는 상태이다.

2
content/ko/docs/concepts/workloads/pods/_index.md
View File

@ -117,7 +117,7 @@ term_id="deployment" >}} 또는 {{< glossary_tooltip text="잡(Job)" term_id="jo
일부 파드에는 {{< glossary_tooltip text="앱 컨테이너" term_id="app-container" >}} 뿐만 아니라 {{< glossary_tooltip text="초기화 컨테이너" term_id="init-container" >}}를 갖고 있다. 초기화 컨테이너는 앱 컨테이너가 시작되기 전에 실행되고 완료된다.
파드는 기본적으로 파드에 속한 컨테이너에 [네트워킹](#파드-네트워킹)과 [스토리지](#pod-storage)라는
두 가지 종류의 공유 ​​리소스를 제공한다.
두 가지 종류의 공유 리소스를 제공한다.
## 파드 작업

2
content/ko/docs/contribute/review/for-approvers.md
View File

@ -72,7 +72,7 @@ PR 코멘트를 남기는 것이 도움이 되지만, 대신 다른 사람의 PR
[Prow](https://github.com/kubernetes/test-infra/blob/master/prow/README.md)는
풀 리퀘스트 (PR)에 대한 작업을 실행하는 쿠버네티스 기반 CI/CD 시스템이다. Prow는
챗봇 스타일 명령으로 쿠버네티스
조직 전체에서 [레이블 추가와 제거](#이슈-레이블-추가와-제거), 이슈 종료 및 승인자 할당과 같은 GitHub 작업을 처리할 수 ​​있다. `/<command-name>` 형식을 사용하여 Prow 명령을 GitHub 코멘트로 입력한다.
조직 전체에서 [레이블 추가와 제거](#이슈-레이블-추가와-제거), 이슈 종료 및 승인자 할당과 같은 GitHub 작업을 처리할 수 있다. `/<command-name>` 형식을 사용하여 Prow 명령을 GitHub 코멘트로 입력한다.
리뷰어와 승인자가 사용하는 가장 일반적인 Prow 명령은 다음과 같다.

4
content/ko/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md
View File

@ -702,7 +702,7 @@ kubelet 파라미터 `--kubelet-reserve` 를 사용하여 CPU 사용량을
* 시크릿에 대한 하위 경로 볼륨 마운트
* 호스트 마운트 프로젝션
* DefaultMode(UID/GID 종속성에 기인함)
* 읽기 전용 루트 파일시스템. 매핑된 볼륨은 여전히 ​​읽기 전용을 지원한다.
* 읽기 전용 루트 파일시스템. 매핑된 볼륨은 여전히 읽기 전용을 지원한다.
* 블록 디바이스 매핑
* 저장 매체로서의 메모리
* uui/guid, 사용자별 리눅스 파일시스템 권한과 같은 파일시스템 기능
@ -763,7 +763,7 @@ DNS, 라우트, 메트릭과 같은 많은 구성은 리눅스에서와 같이 /
파드에서 외부 인터넷으로의 통신)은 치환될 수 없으므로
소스로 다시 라우팅되지 않는다.
* TCP/UDP 패킷은 여전히 ​​치환될 수 있기 때문에
* TCP/UDP 패킷은 여전히 치환될 수 있기 때문에
`ping <destination>`을 `curl <destination>`으로 대체하여
외부와의 연결을 디버깅할 수 있다.

2
content/ko/docs/tasks/tls/managing-tls-in-a-cluster.md
View File

@ -9,7 +9,7 @@ content_type: task
<!-- overview -->
쿠버네티스는 사용자가 제어하는 ​​인증 기관 (CA)에서 서명한 TLS 인증서를
쿠버네티스는 사용자가 제어하는 인증 기관 (CA)에서 서명한 TLS 인증서를
프로비저닝 할 수 있는 `certificates.k8s.io` API를 제공한다.
이러한 CA 및 인증서는 워크로드 간의 신뢰 관계를 구성하는 용도로 사용할 수 있다.

2
content/ko/docs/tutorials/configuration/configure-java-microservice/configure-java-microservice.md
View File

@ -24,7 +24,7 @@ weight: 10
CDI는 느슨하게 결합된 협업 빈(beans)을 통해 애플리케이션을 어셈블할 수 있는 표준 종속성 주입(standard dependency injection) 기능을 제공한다. MicroProfile Config는 애플리케이션, 런타임 및 환경을 포함한 다양한 소스에서 구성 속성을 가져오는 표준 방법을 앱과 마이크로서비스에 제공한다. 소스의 정의된 우선순위에 따라 속성은 애플리케이션이 API를 통해 접근할 수 있는 단일 속성 집합으로 자동 결합된다. 대화형 튜토리얼에서는 CDI와 MicroProfile을 함께 사용하여 쿠버네티스 컨피그맵 및 시크릿을 통한 외부 제공 속성을 검색하고 애플리케이션 코드에 삽입한다.
많은 오픈 소스 프레임워크와 런타임이 MicroProfile Config를 구현하고 지원한다. 대화형 튜토리얼을 통해 클라우드 네이티브 앱과 마이크로서비스를 빌드하고 실행하기 위한 유연한 오픈 소스 Java 런타임인 ​​Open Liberty를 사용하게 될 것이다. 그러나, 모든 MicroProfile 호환 런타임을 대신 사용할 수 있다.
많은 오픈 소스 프레임워크와 런타임이 MicroProfile Config를 구현하고 지원한다. 대화형 튜토리얼을 통해 클라우드 네이티브 앱과 마이크로서비스를 빌드하고 실행하기 위한 유연한 오픈 소스 Java 런타임인 Open Liberty를 사용하게 될 것이다. 그러나, 모든 MicroProfile 호환 런타임을 대신 사용할 수 있다.
## {{% heading "objectives" %}}