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

Merge branch 'dev-1.22-ko.3' into out-ko.3-m1

pull/30473/head
Seokho Son 2021-11-23 02:45:15 +09:00 committed by GitHub
parent d75f6f2a46 0fcaddc0c9
commit c8deb047c2
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
67 changed files with 126 additions and 129 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
content/ko/docs/concepts/architecture/control-plane-node-communication.md
View File

@ -67,4 +67,4 @@ SSH 터널은 현재 더 이상 사용되지 않으므로, 수행 중인 작업
SSH 터널을 대체하는 Konnectivity 서비스는 컨트롤 플레인에서 클러스터 통신에 TCP 레벨 프록시를 제공한다. Konnectivity 서비스는 컨트롤 플레인 네트워크의 Konnectivity 서버와 노드 네트워크의 Konnectivity 에이전트, 두 부분으로 구성된다. Konnectivity 에이전트는 Konnectivity 서버에 대한 연결을 시작하고 네트워크 연결을 유지한다.
Konnectivity 서비스를 활성화한 후, 모든 컨트롤 플레인에서 노드로의 트래픽은 이 연결을 통과한다.
[Konnectivity 서비스 태스크](/docs/tasks/extend-kubernetes/setup-konnectivity/)에 따라 클러스터에서 Konnectivity 서비스를 설정한다.
[Konnectivity 서비스 태스크](/ko/docs/tasks/extend-kubernetes/setup-konnectivity/)에 따라 클러스터에서 Konnectivity 서비스를 설정한다.

14
content/ko/docs/concepts/architecture/nodes.md
View File

@ -51,7 +51,7 @@ weight: 10
```
쿠버네티스는 내부적으로 노드 오브젝트를 생성한다(표시한다). 쿠버네티스는
kubelet이 노드의 `metadata.name` 필드와 일치하는 API 서버에 등록이 되어있는지 확인한다.
kubelet이 노드의 `metadata.name` 필드와 일치하는 API 서버에 등록이 되어 있는지 확인한다.
노드가 정상이면(예를 들어 필요한 모든 서비스가 실행중인 경우) 파드를 실행할 수 있게 된다.
그렇지 않으면, 해당 노드는 정상이 될 때까지 모든 클러스터 활동에
대해 무시된다.
@ -162,7 +162,7 @@ kubectl cordon $NODENAME
kubectl describe node <insert-node-name-here>
```
출력되는 각 섹션은 아래에 설명되어있다.
출력되는 각 섹션은 아래에 설명되어 있다.
### 주소 {#addresses}
@ -310,7 +310,7 @@ kubelet은 노드의 `.status` 생성과 업데이트 및
내에 있는 NodeReady 컨디션을 업데이트한다.
이 경우에는 노드 컨트롤러가 NodeReady 컨디션을 `ConditionUnknown`으로 설정한다.
- 노드가 계속 접근 불가능 상태로 남아있는 경우, 해당 노드의 모든 파드에 대해서
[API를 이용한 축출](/docs/concepts/scheduling-eviction/api-eviction/)을
[API를 이용한 축출](/ko/docs/concepts/scheduling-eviction/api-eviction/)을
트리거한다. 기본적으로, 노드 컨트롤러는 노드를
`ConditionUnknown`으로 마킹한 뒤 5분을 기다렸다가
최초의 축출 요청을 시작한다.
@ -409,19 +409,19 @@ Kubelet은 노드가 종료되는 동안 파드가 일반 [파드 종료 프로
그레이스풀 셧다운 중에 kubelet은 다음의 두 단계로 파드를 종료한다.
1. 노드에서 실행 중인 일반 파드를 종료시킨다.
2. 노드에서 실행 중인 [중요(critical) 파드](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)를 종료시킨다.
2. 노드에서 실행 중인 [중요(critical) 파드](/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#파드를-중요-critical-로-표시하기)를 종료시킨다.
그레이스풀 노드 셧다운 기능은 두 개의 [`KubeletConfiguration`](/docs/tasks/administer-cluster/kubelet-config-file/) 옵션으로 구성된다.
* `ShutdownGracePeriod`:
* 노드가 종료를 지연해야 하는 총 기간을 지정한다. 이것은 모든 일반 및 [중요 파드](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)의 파드 종료에 필요한 총 유예 기간에 해당한다.
* 노드가 종료를 지연해야 하는 총 기간을 지정한다. 이것은 모든 일반 및 [중요 파드](/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#파드를-중요-critical-로-표시하기)의 파드 종료에 필요한 총 유예 기간에 해당한다.
* `ShutdownGracePeriodCriticalPods`:
* 노드 종료 중에 [중요 파드](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)를 종료하는 데 사용되는 기간을 지정한다. 이 값은 `ShutdownGracePeriod` 보다 작아야 한다.
* 노드 종료 중에 [중요 파드](/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#파드를-중요-critical-로-표시하기)를 종료하는 데 사용되는 기간을 지정한다. 이 값은 `ShutdownGracePeriod` 보다 작아야 한다.
예를 들어, `ShutdownGracePeriod=30s`,
`ShutdownGracePeriodCriticalPods=10s` 인 경우, kubelet은 노드 종료를 30초까지
지연시킨다. 종료하는 동안 처음 20(30-10)초는 일반 파드의
유예 종료에 할당되고, 마지막 10초는
[중요 파드](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)의 종료에 할당된다.
[중요 파드](/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#파드를-중요-critical-로-표시하기)의 종료에 할당된다.
{{< note >}}
그레이스풀 노드 셧다운 과정에서 축출된 파드는 `Failed` 라고 표시된다.

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

@ -57,7 +57,7 @@ no_list: true
* [어드미션 컨트롤러 사용하기](/docs/reference/access-authn-authz/admission-controllers/)는 인증과 권한 부여 후 쿠버네티스 API 서버에 대한 요청을 가로채는 플러그인에 대해 설명한다.
* [쿠버네티스 클러스터에서 Sysctls 사용하기](/docs/tasks/administer-cluster/sysctl-cluster/)는 관리자가 `sysctl` 커맨드라인 도구를 사용하여 커널 파라미터를 설정하는 방법에 대해 설명한다.
* [쿠버네티스 클러스터에서 Sysctls 사용하기](/ko/docs/tasks/administer-cluster/sysctl-cluster/)는 관리자가 `sysctl` 커맨드라인 도구를 사용하여 커널 파라미터를 설정하는 방법에 대해 설명한다.
* [감사(audit)](/docs/tasks/debug-application-cluster/audit/)는 쿠버네티스의 감사 로그를 다루는 방법에 대해 설명한다.

2
content/ko/docs/concepts/cluster-administration/kubelet-garbage-collection.md
View File

@ -105,5 +105,5 @@ kubelet이 관리하지 않는 컨테이너는 컨테이너 가비지 수집 대
## {{% heading "whatsnext" %}}
자세한 내용은 [리소스 부족 처리 구성](/docs/concepts/scheduling-eviction/node-pressure-eviction/)를
자세한 내용은 [리소스 부족 처리 구성](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/)를
본다.

8
content/ko/docs/concepts/cluster-administration/networking.md
View File

@ -145,7 +145,7 @@ Coil은 베어메탈에 비해 낮은 오버헤드로 작동하며, 외부 네
### 콘티브(Contiv)
[콘티브](https://github.com/contiv/netplugin)는 다양한 적용 사례에서 구성 가능한 네트워킹(BGP를 사용하는 네이티브 L3, vxlan을 사용하는 오버레이, 클래식 L2 또는 Cisco-SDN/ACI)을 제공한다. [콘티브](https://contiv.io)는 모두 오픈소스이다.
[콘티브](https://github.com/contiv/netplugin)는 다양한 적용 사례에서 구성 가능한 네트워킹(BGP를 사용하는 네이티브 L3, vxlan을 사용하는 오버레이, 클래식 L2 또는 Cisco-SDN/ACI)을 제공한다.
### 콘트레일(Contrail) / 텅스텐 패브릭(Tungsten Fabric)
@ -260,12 +260,6 @@ Multus는 CNI 명세를 구현하는 모든 [레퍼런스 플러그인](https://
[NSX-T 컨테이너 플러그인(NCP)](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf)은 NSX-T와 쿠버네티스와 같은 컨테이너 오케스트레이터 사이의 통합은 물론, NSX-T와 Pivotal 컨테이너 서비스(PKS) 및 OpenShift와 같은 컨테이너 기반 CaaS/PaaS 플랫폼 간의 통합을 제공한다.
### Nuage Networks VCS(가상 클라우드 서비스)
[Nuage](https://www.nuagenetworks.net)는 확장성이 뛰어난 정책 기반의 소프트웨어 정의 네트워킹(SDN) 플랫폼을 제공한다. Nuage는 개방형 표준을 기반으로 구축된 풍부한 기능의 SDN 컨트롤러와 함께 데이터 플레인용 오픈소스 Open vSwitch를 사용한다.
Nuage 플랫폼은 오버레이를 사용하여 쿠버네티스 파드와 쿠버네티스가 아닌 환경(VM 및 베어메탈 서버) 간에 완벽한 정책 기반의 네트워킹을 제공한다. Nuage의 정책 추상화 모델은 애플리케이션을 염두에 두고 설계되었으며 애플리케이션에 대한 세분화된 정책을 쉽게 선언할 수 있도록 한다. 플랫폼의 실시간 분석 엔진을 통해 쿠버네티스 애플리케이션에 대한 가시성과 보안 모니터링이 가능하다.
### OpenVSwitch
[OpenVSwitch](https://www.openvswitch.org/)는 다소 성숙하지만

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

@ -37,7 +37,7 @@ weight: 30
1. 시크릿에 대한 [암호화 활성화](/docs/tasks/administer-cluster/encrypt-data/).
2. 시크릿의 데이터 읽기 및 쓰기(간접적인 방식 포함)를 제한하는 [RBAC 규칙](/ko/docs/reference/access-authn-authz/authorization/)
활성화 또는 구성.
3. 적절한 경우, RBAC와 같은 메커니즘을 사용하여 새로운 시크릿을 생성하거나 기존 시크릿을 대체할 수 있는 주체(principal)들을 제한한다.
3. 적절한 경우, RBAC과 같은 메커니즘을 사용하여 새로운 시크릿을 생성하거나 기존 시크릿을 대체할 수 있는 주체(principal)들을 제한한다.
{{< /caution >}}
@ -425,9 +425,9 @@ stringData:
시크릿을 생성하기 위한 몇 가지 옵션이 있다.
- [`kubectl` 명령을 사용하여 시크릿 생성하기](/docs/tasks/configmap-secret/managing-secret-using-kubectl/)
- [구성 파일로 시크릿 생성하기](/docs/tasks/configmap-secret/managing-secret-using-config-file/)
- [kustomize를 사용하여 시크릿 생성하기](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)
- [`kubectl` 명령을 사용하여 시크릿 생성하기](/ko/docs/tasks/configmap-secret/managing-secret-using-kubectl/)
- [구성 파일로 시크릿 생성하기](/ko/docs/tasks/configmap-secret/managing-secret-using-config-file/)
- [kustomize를 사용하여 시크릿 생성하기](/ko/docs/tasks/configmap-secret/managing-secret-using-kustomize/)
## 시크릿 편집하기
@ -1259,7 +1259,7 @@ API 서버에서 kubelet으로의 통신은 SSL/TLS로 보호된다.
## {{% heading "whatsnext" %}}
- [`kubectl` 을 사용한 시크릿 관리](/docs/tasks/configmap-secret/managing-secret-using-kubectl/)하는 방법 배우기
- [구성 파일을 사용한 시크릿 관리](/docs/tasks/configmap-secret/managing-secret-using-config-file/)하는 방법 배우기
- [kustomize를 사용한 시크릿 관리](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)하는 방법 배우기
- [`kubectl` 을 사용한 시크릿 관리](/ko/docs/tasks/configmap-secret/managing-secret-using-kubectl/)하는 방법 배우기
- [구성 파일을 사용한 시크릿 관리](/ko/docs/tasks/configmap-secret/managing-secret-using-config-file/)하는 방법 배우기
- [kustomize를 사용한 시크릿 관리](/ko/docs/tasks/configmap-secret/managing-secret-using-kustomize/)하는 방법 배우기
- [API 레퍼런스](/docs/reference/kubernetes-api/config-and-storage-resources/secret-v1/)에서 `Secret`에 대해 읽기

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

@ -22,7 +22,7 @@ no_list: true
## 컨테이너 이미지
[컨테이너 이미지](/ko/docs/concepts/containers/images/)는 애플리케이션을
실행하는 데 필요한 모든 것이 포함된 실행할 준비가 되어있는(ready-to-run) 소프트웨어 패키지이다.
실행하는 데 필요한 모든 것이 포함된 실행할 준비가 되어 있는(ready-to-run) 소프트웨어 패키지이다.
여기에는 실행하는 데 필요한 코드와 모든 런타임, 애플리케이션 및 시스템 라이브러리,
그리고 모든 필수 설정에 대한 기본값이 포함된다.

2
content/ko/docs/concepts/containers/container-environment.md
View File

@ -32,7 +32,7 @@ weight: 20
함수 호출을 통해서 구할 수 있다.
파드 이름과 네임스페이스는
[다운워드(Downward) API](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/)를 통해 환경 변수로 구할 수 있다.
[다운워드(Downward) API](/ko/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/)를 통해 환경 변수로 구할 수 있다.
Docker 이미지에 정적으로 명시된 환경 변수와 마찬가지로,
파드 정의에서의 사용자 정의 환경 변수도 컨테이너가 사용할 수 있다.

23
content/ko/docs/concepts/extend-kubernetes/_index.md
View File

@ -2,6 +2,11 @@
title: 쿠버네티스 확장
weight: 110
description: 쿠버네티스 클러스터의 동작을 변경하는 다양한 방법
feature:
title: 확장성을 고려하여 설계됨
description: >
@ -47,9 +52,9 @@ no_list: true
익스텐션은 쿠버네티스를 확장하고 쿠버네티스와 긴밀하게 통합되는 소프트웨어 컴포넌트이다.
이들 컴포넌트는 쿠버네티스가 새로운 유형과 새로운 종류의 하드웨어를 지원할 수 있게 해준다.
대부분의 클러스터 관리자는 쿠버네티스의 호스팅 또는 배포판 인스턴스를 사용한다.
결과적으로 대부분의 쿠버네티스 사용자는 익스텐션 기능을 설치할 필요가 없고
새로운 익스텐션 기능을 작성할 필요가 있는 사람은 더 적다.
많은 클러스터 관리자가 호스팅 또는 배포판 쿠버네티스 인스턴스를 사용한다.
이러한 클러스터들은 미리 설치된 익스텐션을 포함한다. 결과적으로 대부분의
쿠버네티스 사용자는 익스텐션을 설치할 필요가 없고, 새로운 익스텐션을 만들 필요가 있는 사용자는 더 적다.
## 익스텐션 패턴
@ -74,14 +79,12 @@ no_list: true
바이너리 플러그인은 kubelet(예:
[Flex Volume 플러그인](/ko/docs/concepts/storage/volumes/#flexVolume)과
[네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/))과
kubectl에서
사용한다.
kubectl에서 사용한다.
아래는 익스텐션 포인트가 쿠버네티스 컨트롤 플레인과 상호 작용하는 방법을
보여주는 다이어그램이다.
<!-- image source drawing https://docs.google.com/drawings/d/1muJ7Oxuj_7Gtv7HV9-2zJbOnkQJnjxq-v1ym_kZfB-4/edit?ts=5a01e054 -->
![익스텐션 포인트와 컨트롤 플레인](/ko/docs/concepts/extend-kubernetes/control-plane.png)
## 익스텐션 포인트
@ -89,7 +92,6 @@ kubectl에서
이 다이어그램은 쿠버네티스 시스템의 익스텐션 포인트를 보여준다.
<!-- image source diagrams: https://docs.google.com/drawings/d/1k2YdJgNTtNfW7_A8moIIkij-DmVgEhNrn3y2OODwqQQ/view -->
![익스텐션 포인트](/docs/concepts/extend-kubernetes/extension-points.png)
1. 사용자는 종종 `kubectl`을 사용하여 쿠버네티스 API와 상호 작용한다. [Kubectl 플러그인](/ko/docs/tasks/extend-kubectl/kubectl-plugins/)은 kubectl 바이너리를 확장한다. 개별 사용자의 로컬 환경에만 영향을 미치므로 사이트 전체 정책을 적용할 수는 없다.
@ -103,10 +105,10 @@ kubectl에서
어디서부터 시작해야 할지 모르겠다면, 이 플로우 차트가 도움이 될 수 있다. 일부 솔루션에는 여러 유형의 익스텐션이 포함될 수 있다.
<!-- image source drawing: https://docs.google.com/drawings/d/1sdviU6lDz4BpnzJNHfNpQrqI9F19QZ07KnhnxVrp2yg/edit -->
![익스텐션 플로우차트](/ko/docs/concepts/extend-kubernetes/flowchart.png)
## API 익스텐션
### 사용자 정의 유형
새 컨트롤러, 애플리케이션 구성 오브젝트 또는 기타 선언적 API를 정의하고 `kubectl` 과 같은 쿠버네티스 도구를 사용하여 관리하려면 쿠버네티스에 커스텀 리소스를 추가하자.
@ -155,7 +157,6 @@ API를 추가해도 기존 API(예: 파드)의 동작에 직접 영향을 미치
## 인프라스트럭처 익스텐션
### 스토리지 플러그인
[Flex Volumes](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/flexvolume-deployment.md)을 사용하면
@ -172,7 +173,8 @@ Kubelet이 바이너리 플러그인을 호출하여 볼륨을 마운트하도
### 네트워크 플러그인
노드-레벨의 [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)을 통해 다양한 네트워킹 패브릭을 지원할 수 있다.
노드-레벨의 [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
을 통해 다양한 네트워킹 패브릭을 지원할 수 있다.
### 스케줄러 익스텐션
@ -200,3 +202,4 @@ Kubelet이 바이너리 플러그인을 호출하여 볼륨을 마운트하도
* [장치 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)
* [kubectl 플러그인](/ko/docs/tasks/extend-kubectl/kubectl-plugins/)에 대해 알아보기
* [오퍼레이터 패턴](/ko/docs/concepts/extend-kubernetes/operator/)에 대해 알아보기

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

@ -85,7 +85,7 @@ CNI 네트워킹 플러그인은 파드 수신 및 송신 트래픽 셰이핑도
플러그인을 사용하거나 대역폭 제어 기능이 있는 자체 플러그인을 사용할 수 있다.
트래픽 셰이핑 지원을 활성화하려면, CNI 구성 파일 (기본값 `/etc/cni/net.d`)에 `bandwidth` 플러그인을
추가하고, 바이너리가 CNI 실행 파일 디렉터리(기본값: `/opt/cni/bin`)에 포함되어있는지 확인한다.
추가하고, 바이너리가 CNI 실행 파일 디렉터리(기본값: `/opt/cni/bin`)에 포함되어 있는지 확인한다.
```json
{

6
content/ko/docs/concepts/overview/working-with-objects/labels.md
View File

@ -50,7 +50,7 @@ _레이블_ 은 키와 값의 쌍이다. 유효한 레이블 키에는 슬래시
접두사를 생략하면 키 레이블은 개인용으로 간주한다. 최종 사용자의 오브젝트에 자동화된 시스템 컴포넌트(예: `kube-scheduler`, `kube-controller-manager`, `kube-apiserver`, `kubectl` 또는 다른 타사의 자동화 구성 요소)의 접두사를 지정해야 한다.
`kubernetes.io/`와 `k8s.io/` 접두사는 쿠버네티스의 핵심 컴포넌트로 [예약](/ko/docs/reference/labels-annotations-taints/)되어있다.
`kubernetes.io/`와 `k8s.io/` 접두사는 쿠버네티스의 핵심 컴포넌트로 [예약](/ko/docs/reference/labels-annotations-taints/)되어 있다.
유효한 레이블 값은 다음과 같다.
* 63 자 이하여야 하고 (공백일 수도 있음),
@ -95,7 +95,7 @@ API는 현재 _일치성 기준_ 과 _집합성 기준_ 이라는 두 종류의
{{< /note >}}
{{< caution >}}
일치성 기준과 집합성 기준 조건 모두에 대해 논리적인 _OR_ (`||`) 연산자가 없다. 필터 구문이 적절히 구성되어있는지 확인해야 한다.
일치성 기준과 집합성 기준 조건 모두에 대해 논리적인 _OR_ (`||`) 연산자가 없다. 필터 구문이 적절히 구성되어 있는지 확인해야 한다.
{{< /caution >}}
### _일치성 기준_ 요건
@ -231,7 +231,7 @@ selector:
- {key: environment, operator: NotIn, values: [dev]}
```
`matchLabels`는 `{key,value}`의 쌍과 매칭된다. `matchLabels`에 매칭된 단일 `{key,value}`는 `matchExpressions`의 요소와 같으며 `key` 필드는 "key"로, `operator`는 "In" 그리고 `values`에는 "value"만 나열되어 있다. `matchExpressions`는 파드 셀렉터의 요건 목록이다. 유효한 연산자에는 In, NotIn, Exists 및 DoNotExist가 포함된다. In 및 NotIn은 설정된 값이 있어야 한다. `matchLabels`와 `matchExpressions` 모두 AND로 되어있어 일치하기 위해서는 모든 요건을 만족해야 한다.
`matchLabels`는 `{key,value}`의 쌍과 매칭된다. `matchLabels`에 매칭된 단일 `{key,value}`는 `matchExpressions`의 요소와 같으며 `key` 필드는 "key"로, `operator`는 "In" 그리고 `values`에는 "value"만 나열되어 있다. `matchExpressions`는 파드 셀렉터의 요건 목록이다. 유효한 연산자에는 In, NotIn, Exists 및 DoNotExist가 포함된다. In 및 NotIn은 설정된 값이 있어야 한다. `matchLabels`와 `matchExpressions` 모두 AND로 되어 있어 일치하기 위해서는 모든 요건을 만족해야 한다.
#### 노드 셋 선택

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

@ -695,7 +695,7 @@ spec:
- `allowedUnsafeSysctls` - `forbiddenSysctls`에 나열되지 않는 한 기본 목록에서 허용하지 않은 특정 sysctls를 허용한다.
[Sysctl 문서](
/docs/tasks/administer-cluster/sysctl-cluster/#podsecuritypolicy)를 참고하길 바란다.
/ko/docs/tasks/administer-cluster/sysctl-cluster/#파드시큐리티폴리시-podsecuritypolicy)를 참고하길 바란다.
## {{% heading "whatsnext" %}}

2
content/ko/docs/concepts/scheduling-eviction/_index.md
View File

@ -33,5 +33,5 @@ no_list: true
{{<glossary_definition term_id="pod-disruption" length="all">}}
* [파드 우선순위와 선점](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/)
* [노드-압박 축출](/docs/concepts/scheduling-eviction/node-pressure-eviction/)
* [노드-압박 축출](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/)
* [API를 이용한 축출](/ko/docs/concepts/scheduling-eviction/api-eviction/)

2
content/ko/docs/concepts/scheduling-eviction/api-eviction.md
View File

@ -14,5 +14,5 @@ API를 이용한 축출은 구성된 [`PodDisruptionBudgets`](/docs/tasks/run-ap
## {{% heading "whatsnext" %}}
- [노드-압박 축출](/docs/concepts/scheduling-eviction/node-pressure-eviction/)에 대해 더 배우기
- [노드-압박 축출](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/)에 대해 더 배우기
- [파드 우선순위와 선점](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/)에 대해 더 배우기

2
content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md
View File

@ -265,7 +265,7 @@ PodSpec에 지정된 NodeAffinity도 적용된다.
`labelSelector` 와 `topologyKey` 외에도 `labelSelector` 와 일치해야 하는 네임스페이스 목록 `namespaces` 를
선택적으로 지정할 수 있다(이것은 `labelSelector` 와 `topologyKey` 와 같은 수준의 정의이다).
생략되어있거나 비어있을 경우 어피니티/안티-어피니티 정의가 있는 파드의 네임스페이스가 기본 값이다.
생략되어 있거나 비어있을 경우 어피니티/안티-어피니티 정의가 있는 파드의 네임스페이스가 기본 값이다.
파드를 노드에 스케줄하려면 `requiredDuringSchedulingIgnoredDuringExecution` 어피니티와 안티-어피니티와
연관된 `matchExpressions` 가 모두 충족되어야 한다.

2
content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md
View File

@ -91,5 +91,5 @@ _스코어링_ 단계에서 스케줄러는 목록에 남아있는 노드의 순
* [파드 오버헤드](/ko/docs/concepts/scheduling-eviction/pod-overhead/)에 대해 배우기
* 볼륨을 사용하는 파드의 스케줄링에 대해 배우기
* [볼륨 토폴리지 지원](/ko/docs/concepts/storage/storage-classes/#볼륨-바인딩-모드)
* [스토리지 용량 추적](/docs/concepts/storage/storage-capacity/)
* [스토리지 용량 추적](/ko/docs/concepts/storage/storage-capacity/)
* [노드별 볼륨 한도](/ko/docs/concepts/storage/storage-limits/)

6
content/ko/docs/concepts/scheduling-eviction/pod-priority-preemption.md
View File

@ -48,7 +48,7 @@ weight: 70
{{< note >}}
쿠버네티스는 이미 `system-cluster-critical` 과 `system-node-critical`,
두 개의 프라이어리티클래스를 제공한다.
이들은 일반적인 클래스이며 [중요한(critical) 컴포넌트가 항상 먼저 스케줄링이 되도록 하는 데](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/) 사용된다.
이들은 일반적인 클래스이며 [중요한(critical) 컴포넌트가 항상 먼저 스케줄링이 되도록 하는 데](/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/) 사용된다.
{{< /note >}}
## 프라이어리티클래스
@ -357,11 +357,11 @@ kubelet은 우선순위를 사용하여 파드의 [노드-압박(node-pressure)
사용자는 QoS 클래스를 사용하여 어떤 파드가 축출될 것인지
예상할 수 있다. kubelet은 다음의 요소들을 통해서 파드의 축출 순위를 매긴다.
1. 부족한 리소스 사용량이 요청을 초과하는지 여부
1. 기아(starved) 리소스 사용량이 요청을 초과하는지 여부
1. 파드 우선순위
1. 요청 대비 리소스 사용량
더 자세한 내용은 [kubelet 축출에서 파드 선택](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/#kubelet-축출을-위한-파드-선택)을
더 자세한 내용은 [kubelet 축출을 위한 파드 선택](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/#kubelet-축출을-위한-파드-선택)을
참조한다.
kubelet 노드-압박 축출은 사용량이 요청을 초과하지 않는 경우

4
content/ko/docs/concepts/services-networking/connect-applications-service.md
View File

@ -56,7 +56,7 @@ kubectl get pods -l run=my-nginx -o yaml | grep podIP
평평하고 넓은 클러스터 전체의 주소 공간에서 nginx를 실행하는 파드가 있다고 가정하자. 이론적으로는 이러한 파드와 직접 대화할 수 있지만, 노드가 죽으면 어떻게 되는가? 파드가 함께 죽으면 디플로이먼트에서 다른 IP를 가진 새로운 파드를 생성한다. 이 문제를 서비스가 해결한다.
쿠버네티스 서비스는 클러스터 어딘가에서 실행되는 논리적인 파드 집합을 정의하고 추상화함으로써 모두 동일한 기능을 제공한다. 생성시 각 서비스에는 고유한 IP 주소(clusterIP라고도 한다)가 할당된다. 이 주소는 서비스의 수명과 연관되어 있으며, 서비스가 활성화 되어있는 동안에는 변경되지 않는다. 파드는 서비스와 통신하도록 구성할 수 있으며, 서비스와의 통신은 서비스의 맴버 중 일부 파드에 자동적으로 로드-밸런싱 된다.
쿠버네티스 서비스는 클러스터 어딘가에서 실행되는 논리적인 파드 집합을 정의하고 추상화함으로써 모두 동일한 기능을 제공한다. 생성시 각 서비스에는 고유한 IP 주소(clusterIP라고도 한다)가 할당된다. 이 주소는 서비스의 수명과 연관되어 있으며, 서비스가 활성화 되어 있는 동안에는 변경되지 않는다. 파드는 서비스와 통신하도록 구성할 수 있으며, 서비스와의 통신은 서비스의 맴버 중 일부 파드에 자동적으로 로드-밸런싱 된다.
`kubectl expose` 를 사용해서 2개의 nginx 레플리카에 대한 서비스를 생성할 수 있다.
@ -346,7 +346,7 @@ kubectl exec curl-deployment-1515033274-1410r -- curl https://my-nginx --cacert
노출할 수 있다. 쿠버네티스는 이를 수행하는 2가지 방법인 NodePorts와
LoadBalancers를지원한다. 마지막 섹션에서 생성된 서비스는 이미 `NodePort` 를 사용했기에
노드에 공용 IP가 있는경우 nginx HTTPS 레플리카가 인터넷 트래픽을 처리할
준비가 되어있다.
준비가 되어 있다.
```shell
kubectl get svc my-nginx -o yaml | grep nodePort -C 5

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

@ -233,7 +233,7 @@ DNS 정책은 파드별로 설정할 수 있다.
자세한 내용을 확인할 수 있다.
{{< note >}}
"Default"는 기본 DNS 정책이 아니다. `dnsPolicy`가 명시적으로 지정되어있지 않다면
"Default"는 기본 DNS 정책이 아니다. `dnsPolicy`가 명시적으로 지정되어 있지 않다면
"ClusterFirst"가 기본값으로 사용된다.
{{< /note >}}

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

@ -76,4 +76,4 @@ weight: 40
* [인그레스](/ko/docs/concepts/services-networking/ingress/)에 대해 자세히 알아보기.
* [NGINX 컨트롤러로 Minikube에서 인그레스를 설정하기](/docs/tasks/access-application-cluster/ingress-minikube).
* [NGINX 컨트롤러로 Minikube에서 인그레스를 설정하기](/ko/docs/tasks/access-application-cluster/ingress-minikube/).

4
content/ko/docs/concepts/services-networking/ingress.md
View File

@ -77,7 +77,7 @@ graph LR;
다른 모든 쿠버네티스 리소스와 마찬가지로 인그레스에는 `apiVersion`, `kind`, 그리고 `metadata` 필드가 필요하다.
인그레스 오브젝트의 이름은 유효한
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
설정 파일의 작성에 대한 일반적인 내용은 [애플리케이션 배포하기](/docs/tasks/run-application/run-stateless-application-deployment/), [컨테이너 구성하기](/docs/tasks/configure-pod-container/configure-pod-configmap/), [리소스 관리하기](/ko/docs/concepts/cluster-administration/manage-deployment/)를 참조한다.
설정 파일의 작성에 대한 일반적인 내용은 [애플리케이션 배포하기](/ko/docs/tasks/run-application/run-stateless-application-deployment/), [컨테이너 구성하기](/docs/tasks/configure-pod-container/configure-pod-configmap/), [리소스 관리하기](/ko/docs/concepts/cluster-administration/manage-deployment/)를 참조한다.
인그레스는 종종 어노테이션을 이용해서 인그레스 컨트롤러에 따라 몇 가지 옵션을 구성하는데,
그 예시는 [재작성-타겟 어노테이션](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md)이다.
다른 [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)는 다른 어노테이션을 지원한다.
@ -567,4 +567,4 @@ Events:
* [인그레스 API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io)에 대해 배우기
* [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers/)에 대해 배우기
* [NGINX 컨트롤러로 Minikube에서 인그레스 구성하기](/docs/tasks/access-application-cluster/ingress-minikube/)
* [NGINX 컨트롤러로 Minikube에서 인그레스 구성하기](/ko/docs/tasks/access-application-cluster/ingress-minikube/)

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

@ -96,7 +96,7 @@ __podSelector__: 각 네트워크폴리시에는 정책이 적용되는 파드
__policyTypes__: 각 네트워크폴리시에는 `Ingress`, `Egress` 또는 두 가지 모두를 포함할 수 있는 `policyTypes` 목록이 포함된다. `policyTypes` 필드는 선택한 파드에 대한 인그레스 트래픽 정책, 선택한 파드에 대한 이그레스 트래픽 정책 또는 두 가지 모두에 지정된 정책의 적용 여부를 나타낸다. 만약 네트워크폴리시에 `policyTypes` 가 지정되어 있지 않으면 기본적으로 `Ingress` 가 항상 설정되고, 네트워크폴리시에 `Egress` 가 있으면 이그레스 규칙이 설정된다.
__ingress__: 각 네트워크폴리시에는 화이트리스트 `ingress` 규칙 목록이 포함될 수 있다. 각 규칙은 `from` 과 `ports` 부분과 모두 일치하는 트래픽을 허용한다. 예시 정책에는 단일 규칙이 포함되어있는데 첫 번째 포트는 `ipBlock` 을 통해 지정되고, 두 번째는 `namespaceSelector` 를 통해 그리고 세 번째는 `podSelector` 를 통해 세 가지 소스 중 하나의 단일 포트에서 발생하는 트래픽과 일치 시킨다.
__ingress__: 각 네트워크폴리시에는 화이트리스트 `ingress` 규칙 목록이 포함될 수 있다. 각 규칙은 `from` 과 `ports` 부분과 모두 일치하는 트래픽을 허용한다. 예시 정책에는 단일 규칙이 포함되어 있는데 첫 번째 포트는 `ipBlock` 을 통해 지정되고, 두 번째는 `namespaceSelector` 를 통해 그리고 세 번째는 `podSelector` 를 통해 세 가지 소스 중 하나의 단일 포트에서 발생하는 트래픽과 일치 시킨다.
__egress__: 각 네트워크폴리시에는 화이트리스트 `egress` 규칙이 포함될 수 있다. 각 규칙은 `to` 와 `ports` 부분과 모두 일치하는 트래픽을 허용한다. 예시 정책에는 단일 포트의 트래픽을 `10.0.0.0/24` 의 모든 대상과 일치시키는 단일 규칙을 포함하고 있다.

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

@ -96,7 +96,7 @@ _서비스 토폴로지_ 를 활성화 하면 서비스는 클러스터의 노
* 유효한 토폴로지 키는 현재 `kubernetes.io/hostname`,
`topology.kubernetes.io/zone` 그리고 `topology.kubernetes.io/region` 로
제한되어있지만, 앞으로 다른 노드 레이블로 일반화 될 것이다.
제한되어 있지만, 앞으로 다른 노드 레이블로 일반화 될 것이다.
* 토폴로지 키는 유효한 레이블 키이어야 하며 최대 16개의 키를 지정할 수 있다.

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

@ -68,6 +68,6 @@ kube-proxy는 `spec.internalTrafficPolicy` 의 설정에 따라서 라우팅되
## {{% heading "whatsnext" %}}
* [토폴로지 인식 힌트 활성화](/docs/tasks/administer-cluster/enabling-topology-aware-hints)에 대해서 읽기
* [토폴로지 인식 힌트 활성화](/ko/docs/tasks/administer-cluster/enabling-topology-aware-hints/)에 대해서 읽기
* [서비스 외부 트래픽 정책](/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip)에 대해서 읽기
* [서비스와 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/) 읽기

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

@ -280,7 +280,7 @@ spec:
업데이트를 수신하지 않는다.
{{< /note >}}
더 자세한 내용은 [다운워드 API 예시](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/)를 참고한다.
더 자세한 내용은 [다운워드 API 예시](/ko/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/)를 참고한다.
### emptyDir {#emptydir}
@ -358,7 +358,7 @@ targetWWN은 해당 WWN이 다중 경로 연결에서 온 것으로 예상한다
`flocker` 볼륨은 Flocker 데이터셋을 파드에 마운트할 수 있게 한다. 만약
Flocker내에 데이터셋이 없는 경우, 먼저 Flocker
CLI 또는 Flocker API를 사용해서 생성해야 한다. 만약 데이터셋이 이미 있다면
Flocker는 파드가 스케줄 되어있는 노드에 다시 연결한다. 이는 필요에
Flocker는 파드가 스케줄 되어 있는 노드에 다시 연결한다. 이는 필요에
따라 파드 간에 데이터를 공유할 수 있다는 의미이다.
{{< note >}}

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

@ -60,7 +60,7 @@ _모든_ 파드가 가용한 경우가 아닌 경우 멈추고 싶다면(아마
각 리소스에 대해 읽을 수 있을 뿐만 아니라, 리소스와 관련된 특정 작업에 대해서도 알아볼 수 있다.
* [`Deployment` 를 사용하여 스테이트리스(stateless) 애플리케이션 실행](/docs/tasks/run-application/run-stateless-application-deployment/)
* [`Deployment` 를 사용하여 스테이트리스(stateless) 애플리케이션 실행](/ko/docs/tasks/run-application/run-stateless-application-deployment/)
* 스테이트풀(stateful) 애플리케이션을 [단일 인스턴스](/ko/docs/tasks/run-application/run-single-instance-stateful-application/)
또는 [복제된 세트](/docs/tasks/run-application/run-replicated-stateful-application/)로 실행
* [`CronJob` 을 사용하여 자동화된 작업 실행](/ko/docs/tasks/job/automated-tasks-with-cron-jobs/)

4
content/ko/docs/concepts/workloads/controllers/daemonset.md
View File

@ -47,7 +47,7 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
다른 모든 쿠버네티스 설정과 마찬가지로 데몬셋에는 `apiVersion`, `kind` 그리고 `metadata` 필드가 필요하다.
일반적인 설정파일 작업에 대한 정보는
[스테이트리스 애플리케이션 실행하기](/docs/tasks/run-application/run-stateless-application-deployment/)와
[스테이트리스 애플리케이션 실행하기](/ko/docs/tasks/run-application/run-stateless-application-deployment/)와
[kubectl을 사용한 오브젝트 관리](/ko/docs/concepts/overview/working-with-objects/object-management/)를 참고한다.
데몬셋 오브젝트의 이름은 유효한
@ -166,7 +166,7 @@ nodeAffinity:
데몬셋의 파드와 통신할 수 있는 몇 가지 패턴은 다음과 같다.
- **푸시(Push)**: 데몬셋의 파드는 통계 데이터베이스와 같은 다른 서비스로 업데이트를 보내도록
구성되어있다. 그들은 클라이언트들을 가지지 않는다.
구성되어 있다. 그들은 클라이언트들을 가지지 않는다.
- **노드IP와 알려진 포트**: 데몬셋의 파드는 `호스트 포트`를 사용할 수 있으며,
노드IP를 통해 파드에 접근할 수 있다.
클라이언트는 노드IP를 어떻게든지 알고 있으며, 관례에 따라 포트를 알고 있다.

8
content/ko/docs/concepts/workloads/controllers/deployment.md
View File

@ -50,13 +50,13 @@ _디플로이먼트(Deployment)_ 는 {{< glossary_tooltip text="파드" term_id=
보다 정교한 선택 규칙의 적용이 가능하다.
{{< note >}}
`.spec.selector.matchLabels` 필드는 {key,value}의 쌍으로 매핑되어있다. `matchLabels` 에 매핑된
`.spec.selector.matchLabels` 필드는 {key,value}의 쌍으로 매핑되어 있다. `matchLabels` 에 매핑된
단일 {key,value}은 `matchExpressions` 의 요소에 해당하며, `key` 필드는 "key"에 그리고 `operator`는 "In"에 대응되며
`value` 배열은 "value"만 포함한다.
매칭을 위해서는 `matchLabels` 와 `matchExpressions` 의 모든 요건이 충족되어야 한다.
{{< /note >}}
* `template` 필드에는 다음 하위 필드가 포함되어있다.
* `template` 필드에는 다음 하위 필드가 포함되어 있다.
* 파드는 `.metadata.labels` 필드를 사용해서 `app: nginx` 라는 레이블을 붙인다.
* 파드 템플릿의 사양 또는 `.template.spec` 필드는
파드가 [도커 허브](https://hub.docker.com/)의 `nginx` 1.14.2 버전 이미지를 실행하는
@ -1023,7 +1023,7 @@ echo $?
디플로이먼트의 `.spec.revisionHistoryLimit` 필드를 설정해서
디플로이먼트에서 유지해야 하는 이전 레플리카셋의 수를 명시할 수 있다. 나머지는 백그라운드에서 가비지-수집이 진행된다.
기본적으로 10으로 되어있다.
기본적으로 10으로 되어 있다.
{{< note >}}
명시적으로 이 필드를 0으로 설정하면 그 결과로 디플로이먼트의 기록을 전부 초기화를 하고,
@ -1040,7 +1040,7 @@ echo $?
다른 모든 쿠버네티스 설정과 마찬가지로 디플로이먼트에는 `.apiVersion`, `.kind` 그리고 `.metadata` 필드가 필요하다.
설정 파일 작업에 대한 일반적인 내용은
[애플리케이션 배포하기](/docs/tasks/run-application/run-stateless-application-deployment/),
[애플리케이션 배포하기](/ko/docs/tasks/run-application/run-stateless-application-deployment/),
컨테이너 구성하기 그리고 [kubectl을 사용해서 리소스 관리하기](/ko/docs/concepts/overview/working-with-objects/object-management/) 문서를 참조한다.
디플로이먼트 오브젝트의 이름은 유효한
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.

2
content/ko/docs/concepts/workloads/controllers/job.md
View File

@ -369,7 +369,7 @@ spec:
다른 접근 방식들은 기존에 컨테이너화된 애플리케이션에 보다 쉽게 적용할 수 있다.
여기에 트레이드오프가 요약되어있고, 2열에서 4열까지가 위의 트레이드오프에 해당한다.
여기에 트레이드오프가 요약되어 있고, 2열에서 4열까지가 위의 트레이드오프에 해당한다.
패턴 이름은 예시와 더 자세한 설명을 위한 링크이다.
| 패턴 | 단일 잡 오브젝트 | 작업 항목보다 파드가 적은가? | 수정되지 않은 앱을 사용하는가? |

10
content/ko/docs/concepts/workloads/controllers/replicaset.md
View File

@ -50,7 +50,7 @@ OwnerReference가 {{< glossary_tooltip term_id="controller" >}} 가 아니고
{{< codenew file="controllers/frontend.yaml" >}}
이 매니페스트를 `frontend.yaml`에 저장하고 쿠버네티스 클러스터에 적용하면 정의되어있는 레플리카셋이
이 매니페스트를 `frontend.yaml`에 저장하고 쿠버네티스 클러스터에 적용하면 정의되어 있는 레플리카셋이
생성되고 레플리카셋이 관리하는 파드가 생성된다.
```shell
@ -128,7 +128,7 @@ frontend-wtsmm 1/1 Running 0 6m36s
kubectl get pods frontend-b2zdv -o yaml
```
메타데이터의 ownerReferences 필드에 설정되어있는 프런트엔드 레플리카셋의 정보가 다음과 유사하게 나오는 것을 볼 수 있다.
메타데이터의 ownerReferences 필드에 설정되어 있는 프런트엔드 레플리카셋의 정보가 다음과 유사하게 나오는 것을 볼 수 있다.
```shell
apiVersion: v1
@ -223,7 +223,7 @@ pod2 1/1 Running 0 36s
레플리카셋은 모든 쿠버네티스 API 오브젝트와 마찬가지로 `apiVersion`, `kind`, `metadata` 필드가 필요하다.
레플리카셋에 대한 `kind` 필드의 값은 항상 레플리카셋이다.
쿠버네티스 1.9에서의 레플리카셋의 kind에 있는 API 버전 `apps/v1`은 현재 버전이며, 기본으로 활성화 되어있다. API 버전 `apps/v1beta2`은 사용 중단(deprecated)되었다.
쿠버네티스 1.9에서의 레플리카셋의 kind에 있는 API 버전 `apps/v1`은 현재 버전이며, 기본으로 활성화 되어 있다. API 버전 `apps/v1beta2`은 사용 중단(deprecated)되었다.
API 버전에 대해서는 `frontend.yaml` 예제의 첫 번째 줄을 참고한다.
레플리카셋 오브젝트의 이름은 유효한
@ -233,7 +233,7 @@ API 버전에 대해서는 `frontend.yaml` 예제의 첫 번째 줄을 참고한
### 파드 템플릿
`.spec.template`은 레이블을 붙이도록 되어있는 [파드 템플릿](/ko/docs/concepts/workloads/pods/#파드-템플릿)이다.
`.spec.template`은 레이블을 붙이도록 되어 있는 [파드 템플릿](/ko/docs/concepts/workloads/pods/#파드-템플릿)이다.
우리는 `frontend.yaml` 예제에서 `tier: frontend`이라는 레이블을 하나 가지고 있다.
이 파드를 다른 컨트롤러가 취하지 않도록 다른 컨트롤러의 셀렉터와 겹치지 않도록 주의해야 한다.
@ -269,7 +269,7 @@ matchLabels:
### 레플리카셋과 해당 파드 삭제
레플리카셋 및 모든 파드를 삭제하려면 [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete)를 사용한다. [가비지 수집기](/ko/docs/concepts/workloads/controllers/garbage-collection/)는 기본적으로 종속되어있는 모든 파드를 자동으로 삭제한다.
레플리카셋 및 모든 파드를 삭제하려면 [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete)를 사용한다. [가비지 수집기](/ko/docs/concepts/workloads/controllers/garbage-collection/)는 기본적으로 종속되어 있는 모든 파드를 자동으로 삭제한다.
REST API또는 `client-go` 라이브러리를 이용할 때는 -d 옵션으로 `propagationPolicy`를 `Background`또는 `Foreground`로
설정해야 한다.

2
content/ko/docs/concepts/workloads/controllers/statefulset.md
View File

@ -189,7 +189,7 @@ N개의 레플리카가 있는 스테이트풀셋은 스테이트풀셋에 있
* 파드에 스케일링 작업을 적용하기 전에 모든 선행 파드가 Running 및 Ready 상태여야 한다.
* 파드가 종료되기 전에 모든 후속 파드가 완전히 종료 되어야 한다.
스테이트풀셋은 `pod.Spec.TerminationGracePeriodSeconds` 을 0으로 명시해서는 안된다. 이 방법은 안전하지 않으며, 사용하지 않기를 강권한다. 자세한 설명은 [스테이트풀셋 파드 강제 삭제](/docs/tasks/run-application/force-delete-stateful-set-pod/)를 참고한다.
스테이트풀셋은 `pod.Spec.TerminationGracePeriodSeconds` 을 0으로 명시해서는 안된다. 이 방법은 안전하지 않으며, 사용하지 않기를 강권한다. 자세한 설명은 [스테이트풀셋 파드 강제 삭제](/ko/docs/tasks/run-application/force-delete-stateful-set-pod/)를 참고한다.
위의 nginx 예시가 생성될 때 web-0, web-1, web-2 순서로 3개 파드가
배포된다. web-1은 web-0이

4
content/ko/docs/concepts/workloads/pods/disruptions.md
View File

@ -31,7 +31,7 @@ weight: 60
- 클라우드 공급자 또는 하이퍼바이저의 오류로 인한 VM 장애
- 커널 패닉
- 클러스터 네트워크 파티션의 발생으로 클러스터에서 노드가 사라짐
- 노드의 [리소스 부족](/docs/concepts/scheduling-eviction/node-pressure-eviction/)으로 파드가 축출됨
- 노드의 [리소스 부족](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/)으로 파드가 축출됨
리소스 부족을 제외한 나머지 조건은 대부분의 사용자가 익숙할 것이다.
왜냐하면
@ -71,7 +71,7 @@ weight: 60
- 파드가 필요로 하는 [리소스를 요청](/ko/docs/tasks/configure-pod-container/assign-memory-resource/)하는지 확인한다.
- 고가용성이 필요한 경우 애플리케이션을 복제한다.
(복제된 [스테이트리스](/docs/tasks/run-application/run-stateless-application-deployment/) 및
(복제된 [스테이트리스](/ko/docs/tasks/run-application/run-stateless-application-deployment/) 및
[스테이트풀](/docs/tasks/run-application/run-replicated-stateful-application/) 애플리케이션에 대해 알아보기.)
- 복제된 애플리케이션의 구동 시 훨씬 더 높은 가용성을 위해 랙 전체
([안티-어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#파드간-어피니티와-안티-어피니티) 이용)

2
content/ko/docs/concepts/workloads/pods/ephemeral-containers.md
View File

@ -76,4 +76,4 @@ API에서 특별한 `ephemeralcontainers` 핸들러를 사용해서 만들어지
## {{% heading "whatsnext" %}}
* [임시 컨테이너 디버깅하기](/docs/tasks/debug-application-cluster/debug-running-pod/#ephemeral-container)에 대해 알아보기.
* [임시 컨테이너 디버깅하기](/ko/docs/tasks/debug-application-cluster/debug-running-pod/#ephemeral-container)에 대해 알아보기.

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

@ -433,7 +433,7 @@ API에서 즉시 파드를 제거하므로 동일한 이름으로 새로운 파
작은 유예 기간이 계속 제공된다.
스테이트풀셋(StatefulSet)의 일부인 파드를 강제 삭제해야 하는 경우,
[스테이트풀셋에서 파드를 삭제하기](/docs/tasks/run-application/force-delete-stateful-set-pod/)에 대한
[스테이트풀셋에서 파드를 삭제하기](/ko/docs/tasks/run-application/force-delete-stateful-set-pod/)에 대한
태스크 문서를 참고한다.
### 실패한 파드의 가비지 콜렉션 {#pod-garbage-collection}

2
content/ko/docs/contribute/_index.md
View File

@ -56,7 +56,7 @@ card:
## 첫 번째 기여
- [기여 개요](/ko/docs/contribute/new-content/overview/)를 읽고
- [기여 개요](/ko/docs/contribute/new-content/)를 읽고
기여할 수 있는 다양한 방법에 대해 알아봅니다.
- [`kubernetes/website` 이슈 목록](https://github.com/kubernetes/website/issues/)을
확인하여 좋은 진입점이 되는 이슈를 찾을 수 있습니다.

2
content/ko/docs/contribute/advanced.md
View File

@ -8,7 +8,7 @@ weight: 98
<!-- overview -->
이 페이지에서는 당신이
[새로운 콘텐츠에 기여](/ko/docs/contribute/new-content/overview)하고
[새로운 콘텐츠에 기여](/ko/docs/contribute/new-content/)하고
[다른 사람의 작업을 리뷰](/ko/docs/contribute/review/reviewing-prs/)하는 방법을
이해한다고 가정한다. 또한 기여하기 위한 더 많은 방법에 대해 배울 준비가 되었다고 가정한다. 이러한
작업 중 일부에는 Git 커맨드 라인 클라이언트와 다른 도구를 사용해야 한다.

2
content/ko/docs/contribute/new-content/open-a-pr.md
View File

@ -15,7 +15,7 @@ card:
[새 기능 문서화](/docs/contribute/new-content/new-features/)를 참고한다.
{{< /note >}}
새 콘텐츠 페이지를 기여하거나 기존 콘텐츠 페이지를 개선하려면, 풀 리퀘스트(PR)를 연다. [시작하기 전에](/ko/docs/contribute/new-content/overview/#before-you-begin) 섹션의 모든 요구 사항을 준수해야 한다.
새 콘텐츠 페이지를 기여하거나 기존 콘텐츠 페이지를 개선하려면, 풀 리퀘스트(PR)를 연다. [시작하기 전에](/ko/docs/contribute/new-content/#before-you-begin) 섹션의 모든 요구 사항을 준수해야 한다.
변경 사항이 작거나, git에 익숙하지 않은 경우, [GitHub을 사용하여 변경하기](#github을-사용하여-변경하기)를 읽고 페이지를 편집하는 방법을 알아보자.

2
content/ko/docs/contribute/participate/_index.md
View File

@ -116,6 +116,6 @@ PR 소유자에게 조언하는데 활용된다.
쿠버네티스 문서화에 기여하는 일에 대한 보다 많은 정보는 다음 문서를 참고한다.
- [신규 콘텐츠 기여하기](/ko/docs/contribute/new-content/overview/)
- [신규 콘텐츠 기여하기](/ko/docs/contribute/new-content/)
- [콘텐츠 검토하기](/ko/docs/contribute/review/reviewing-prs/)
- [문서 스타일 가이드](/ko/docs/contribute/style/)

2
content/ko/docs/contribute/participate/roles-and-responsibilities.md
View File

@ -32,7 +32,7 @@ GitHub 계정을 가진 누구나 쿠버네티스에 기여할 수 있다. SIG D
- [슬랙](https://slack.k8s.io/) 또는
[SIG docs 메일링 리스트](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)에 개선을 제안한다.
[CLA에 서명](/ko/docs/contribute/new-content/overview/#sign-the-cla) 후에 누구나 다음을 할 수 있다.
[CLA에 서명](/ko/docs/contribute/new-content/#sign-the-cla) 후에 누구나 다음을 할 수 있다.
- 기존 콘텐츠를 개선하거나, 새 콘텐츠를 추가하거나, 블로그 게시물 또는 사례연구 작성을 위해 풀 리퀘스트를 연다.
- 다이어그램, 그래픽 자산 그리고 포함할 수 있는 스크린캐스트와 비디오를 제작한다.

2
content/ko/docs/contribute/review/reviewing-prs.md
View File

@ -43,7 +43,7 @@ weight: 10
표시된다.
2. 다음 레이블 중 하나 또는 모두를 사용하여 열린 PR을 필터링한다.
- `cncf-cla: yes`(권장): CLA에 서명하지 않은 기여자가 제출한 PR은 병합할 수 없다. 자세한 내용은 [CLA 서명](/ko/docs/contribute/new-content/overview/#sign-the-cla)을 참고한다.
- `cncf-cla: yes`(권장): CLA에 서명하지 않은 기여자가 제출한 PR은 병합할 수 없다. 자세한 내용은 [CLA 서명](/ko/docs/contribute/new-content/#sign-the-cla)을 참고한다.
- `language/en`(권장): 영어 문서에 대한 PR 전용 필터이다.
- `size/<size>`: 특정 크기의 PR을 필터링한다. 새로 시작하는 사람이라면, 더 작은 PR로 시작한다.

2
content/ko/docs/contribute/style/write-new-topic.md
View File

@ -105,7 +105,7 @@ YAML 블록이다. 여기 예시가 있다.
포함할 수 있다.
- 이 코드의 목적은 더 큰 파일의 일부를 강조하는 것이기 때문에
불완전한 예제다. 예를 들어 몇 가지 이유로
[PodSecurityPolicy](/docs/tasks/administer-cluster/sysctl-cluster/#podsecuritypolicy)
[PodSecurityPolicy](/ko/docs/tasks/administer-cluster/sysctl-cluster/#파드시큐리티폴리시-podsecuritypolicy)
를 사용자 정의 방법을 설명할 때 문서 파일에서 직접 짧은 요약 정보를 제공할 수 있다.
- 이 코드는 사용자가 다른 이유로 시도하기 위한 것이 아니다. 예를 들어
`kubectl edit` 명령을 사용하여 리소스에 새 속성을 추가하는 방법을

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

@ -654,7 +654,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
[토큰 요청](https://kubernetes-csi.github.io/docs/token-requests.html)을 참조한다.
- `CSIStorageCapacity`: CSI 드라이버가 스토리지 용량 정보를 게시하고
쿠버네티스 스케줄러가 파드를 스케줄할 때 해당 정보를 사용하도록 한다.
[스토리지 용량](/docs/concepts/storage/storage-capacity/)을 참고한다.
[스토리지 용량](/ko/docs/concepts/storage/storage-capacity/)을 참고한다.
자세한 내용은 [`csi` 볼륨 유형](/ko/docs/concepts/storage/volumes/#csi) 문서를 확인한다.
- `CSIVolumeFSGroupPolicy`: CSI드라이버가 `fsGroupPolicy` 필드를 사용하도록 허용한다.
이 필드는 CSI드라이버에서 생성된 볼륨이 마운트될 때 볼륨 소유권과
@ -698,7 +698,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
- `DisableCloudProviders`: `kube-apiserver`, `kube-controller-manager`,
`--cloud-provider` 컴포넌트 플래그와 관련된 `kubelet`의
모든 기능을 비활성화한다.
- `DownwardAPIHugePages`: [다운워드 API](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information)에서
- `DownwardAPIHugePages`: [다운워드 API](/ko/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/)에서
hugepages 사용을 활성화한다.
- `DryRun`: 서버 측의 [dry run](/docs/reference/using-api/api-concepts/#dry-run) 요청을
요청을 활성화하여 커밋하지 않고 유효성 검사, 병합 및 변화를 테스트할 수 있다.
@ -738,13 +738,13 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
- `ExpandCSIVolumes`: CSI 볼륨 확장을 활성화한다.
- `ExpandedDNSConfig`: 더 많은 DNS 검색 경로와 더 긴 DNS 검색 경로 목록을 허용하려면
kubelet과 kube-apiserver를 사용하도록 설정한다.
[확장된 DNS 구성](/docs/concepts/services-networking/dns-pod-service/#expanded-dns-configuration)을 참고한다.
[확장된 DNS 구성](/ko/docs/concepts/services-networking/dns-pod-service/#확장된-dns-환경-설정)을 참고한다.
- `ExpandInUsePersistentVolumes`: 사용 중인 PVC를 확장할 수 있다.
[사용 중인 퍼시스턴트볼륨클레임 크기 조정](/ko/docs/concepts/storage/persistent-volumes/#사용-중인-퍼시스턴트볼륨클레임-크기-조정)을 참고한다.
- `ExpandPersistentVolumes`: 퍼시스턴트 볼륨 확장을 활성화한다.
[퍼시스턴트 볼륨 클레임 확장](/ko/docs/concepts/storage/persistent-volumes/#퍼시스턴트-볼륨-클레임-확장)을 참고한다.
- `ExperimentalCriticalPodAnnotation`: 특정 파드에 *critical* 로
어노테이션을 달아서 [스케줄링이 보장되도록](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/) 한다.
어노테이션을 달아서 [스케줄링이 보장되도록](/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/) 한다.
이 기능은 v1.13부터 파드 우선 순위 및 선점으로 인해 사용 중단되었다.
- `ExperimentalHostUserNamespaceDefaulting`: 사용자 네임스페이스를 호스트로
기본 활성화한다. 이것은 다른 호스트 네임스페이스, 호스트 마운트,
@ -847,7 +847,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
- `NodeLease`: 새로운 리스(Lease) API가 노드 상태 신호로 사용될 수 있는 노드 하트비트(heartbeats)를 보고할 수 있게 한다.
- `NodeSwap`: 노드의 쿠버네티스 워크로드용 스왑 메모리를 할당하려면 kubelet을 활성화한다.
반드시 `KubeletConfiguration.failSwapOn`를 false로 설정한 후 사용해야 한다.
더 자세한 정보는 [스왑 메모리](/docs/concepts/architecture/nodes/#swap-memory)를 참고한다.
더 자세한 정보는 [스왑 메모리](/ko/docs/concepts/architecture/nodes/#swap-memory)를 참고한다.
- `NonPreemptingPriority`: 프라이어리티클래스(PriorityClass)와 파드에 `preemptionPolicy` 필드를 활성화한다.
- `PVCProtection`: 파드에서 사용 중일 때 퍼시스턴트볼륨클레임(PVC)이
삭제되지 않도록 한다.
@ -970,7 +970,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
참고한다.
- `Sysctls`: 각 파드에 설정할 수 있는 네임스페이스 커널
파라미터(sysctl)를 지원한다. 자세한 내용은
[sysctl](/docs/tasks/administer-cluster/sysctl-cluster/)을 참고한다.
[sysctl](/ko/docs/tasks/administer-cluster/sysctl-cluster/)을 참고한다.
- `TTLAfterFinished`: [TTL 컨트롤러](/ko/docs/concepts/workloads/controllers/ttlafterfinished/)가
실행이 끝난 후 리소스를 정리하도록
허용한다.

2
content/ko/docs/reference/glossary/sysctl.md
View File

@ -2,7 +2,7 @@
title: sysctl
id: sysctl
date: 2019-02-12
full_link: /docs/tasks/administer-cluster/sysctl-cluster/
full_link: /ko/docs/tasks/administer-cluster/sysctl-cluster/
short_description: >
유닉스 커널 파라미터를 가져오거나 설정하는 데 사용하는 인터페이스

2
content/ko/docs/reference/kubectl/docker-cli-to-kubectl.md
View File

@ -187,7 +187,7 @@ kubectl exec -ti nginx-app-5jyvm -- /bin/sh
# exit
```
자세한 내용은 [실행 중인 컨테이너의 셸 얻기](/docs/tasks/debug-application-cluster/get-shell-running-container/)를 참고한다.
자세한 내용은 [실행 중인 컨테이너의 셸 얻기](/ko/docs/tasks/debug-application-cluster/get-shell-running-container/)를 참고한다.
## docker logs

2
content/ko/docs/setup/production-environment/windows/user-guide-windows-containers.md
View File

@ -147,7 +147,7 @@ LogMonitor가 로그를 STDOUT으로 푸시할 수 있도록 필요한 엔트리
그룹 매니지드 서비스 어카운트는 액티브 디렉터리 어카운트의 특정한 종류로 자동 암호 관리 기능,
단순화된 서비스 주체 이름(SPN, simplified service principal name), 여러 서버의 다른 관리자에게 관리를 위임하는 기능을 제공한다.
GMSA로 구성한 컨테이너는 GMSA로 구성된 신원을 들고 있는 동안 외부 액티브 디렉터리 도메인 리소스를 접근할 수 있다.
윈도우 컨테이너를 위한 GMSA를 이용하고 구성하는 방법은 [여기](/docs/tasks/configure-pod-container/configure-gmsa/)에서 알아보자.
윈도우 컨테이너를 위한 GMSA를 이용하고 구성하는 방법은 [여기](/ko/docs/tasks/configure-pod-container/configure-gmsa/)에서 알아보자.
## 테인트(Taint)와 톨러레이션(Toleration)

2
content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md
View File

@ -182,7 +182,7 @@ Kubeconfig 인증 방법은 외부 아이덴티티 프로바이더
특권을 가진(privileged) 컨테이너는 네트워크 스택과 디바이스에 접근하는 것을 조작하도록 활용할 수 있다.
- **환경 변수**: 쿠버네티스 서비스를
[환경 변수](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)를 통해 노출한다.
[환경 변수](/ko/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)를 통해 노출한다.
환경 변수 또는 인자를 환경 변수들의 값으로 커맨드를 통해 구성할 수 있다.
애플리케이션들이 서비스를 찾는데 사용된다.
값들은 `$(VAR_NAME)` 구문을 사용하는 다른 변수들로 참조할 수 있다.

2
content/ko/docs/tasks/administer-cluster/change-default-storage-class.md
View File

@ -80,7 +80,7 @@ content_type: task
최대 1개의 스토리지클래스를 기본값으로 표시할 수 있다는 것을 알아두자. 만약
2개 이상이 기본값으로 표시되면, 명시적으로 `storageClassName` 가 지정되지 않은 `PersistentVolumeClaim` 은 생성될 수 없다.
1. 사용자가 선택한 스토리지클래스가 기본값으로 되어있는지 확인한다.
1. 사용자가 선택한 스토리지클래스가 기본값으로 되어 있는지 확인한다.
```bash
kubectl get storageclass

2
content/ko/docs/tasks/administer-cluster/sysctl-cluster.md
View File

@ -156,7 +156,7 @@ sysctl 설정이 필요한 노드에만 파드를 예약하는 것이 좋다.
두 _unsafe_ sysctl을 명시적으로 활성화하지 않은 노드에서 _unsafe_ sysctl을 사용하는
파드가 시작되지 않는다. _node-level_ sysctl과 마찬가지로
[_테인트와 톨러레이션_ 특징](/docs/reference/generated/kubectl/kubectl-commands/#taint) 또는
[노드 테인트](/docs/concepts/scheduling-eviction/taint-and-toleration/)를
[노드 테인트](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)를
사용하여 해당 파드를 오른쪽 노드에
스케줄하는 것을 추천한다.

2
content/ko/docs/tasks/configure-pod-container/configure-runasusername.md
View File

@ -122,5 +122,5 @@ ContainerAdministrator
* [쿠버네티스에서 윈도우 컨테이너 스케줄링을 위한 가이드](/ko/docs/setup/production-environment/windows/user-guide-windows-containers/)
* [그룹 매니지드 서비스 어카운트를 이용하여 워크로드 신원 관리하기](/ko/docs/setup/production-environment/windows/user-guide-windows-containers/#그룹-매니지드-서비스-어카운트를-이용하여-워크로드-신원-관리하기)
* [윈도우 파드와 컨테이너의 GMSA 구성](/docs/tasks/configure-pod-container/configure-gmsa/)
* [윈도우 파드와 컨테이너의 GMSA 구성](/ko/docs/tasks/configure-pod-container/configure-gmsa/)

2
content/ko/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md
View File

@ -91,7 +91,7 @@ kubectl describe pods ${POD_NAME}
### 파드가 손상(crashing)되었거나 양호하지 않을(unhealthy) 경우
일단 사용자의 파드가 스케줄 되면, [구동중인 파드 디버그하기](/docs/tasks/debug-application-cluster/debug-running-pod/)에
일단 사용자의 파드가 스케줄 되면, [구동중인 파드 디버그하기](/ko/docs/tasks/debug-application-cluster/debug-running-pod/)에
기술된 메서드를 디버깅에 사용할 수 있다.

4
content/ko/docs/tasks/debug-application-cluster/debug-running-pod.md
View File

@ -69,7 +69,7 @@ kubectl exec -it cassandra -- sh
```
더욱 상세한 내용은 다음 [동작중인 컨테이너의 쉘에 접근하기](
/docs/tasks/debug-application-cluster/get-shell-running-container/)를 참고하라.
/ko/docs/tasks/debug-application-cluster/get-shell-running-container/)를 참고하라.
## 임시(ephemeral) 디버그 컨테이너를 사용해서 디버깅하기 {#ephemeral-container}
@ -87,7 +87,7 @@ kubectl exec -it cassandra -- sh
{{< note >}}
이 섹션에서 소개하는 예시를 사용하기 위해서는
여러분의 클러스터에 `EphemeralContainers` [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)가
여러분의 클러스터에 `EphemeralContainers` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가
활성화되어 있어야 하고 `kubectl`의 버전이 v1.18 이상이어야 한다.
{{< /note >}}

2
content/ko/docs/tasks/debug-application-cluster/debug-stateful-set.md
View File

@ -32,7 +32,7 @@ kubectl get pods -l app=myapp
만약 오랜 시간동안 `Unknown`이나 `Terminating` 상태에 있는
파드들을 발견하였다면, 이러한 파드들을 어떻게 다루는지 알아보기 위해
[스테이트풀셋 파드 삭제하기](/docs/tasks/run-application/delete-stateful-set/)를 참고하길 바란다.
[스테이트풀셋 파드 삭제하기](/ko/docs/tasks/run-application/delete-stateful-set/)를 참고하길 바란다.
스테이트풀셋에 포함된 개별 파드들을 디버깅하기 위해서는
[파드 디버그하기](/ko/docs/tasks/debug-application-cluster/debug-pod-replication-controller/) 가이드를 참고하길 바란다.

2
content/ko/docs/tasks/inject-data-application/define-command-argument-container.md
View File

@ -152,5 +152,5 @@ EntryPoint 값과 기본 Cmd 값이 덮어쓰여진다. `command`가 `args` 값
* [파드와 컨테이너를 구성하는 방법](/ko/docs/tasks/)에 대해 더 알아본다.
* [컨테이너 안에서 커맨드를 실행하는 방법](/docs/tasks/debug-application-cluster/get-shell-running-container/)에 대해 더 알아본다.
* [컨테이너 안에서 커맨드를 실행하는 방법](/ko/docs/tasks/debug-application-cluster/get-shell-running-container/)에 대해 더 알아본다.
* [컨테이너](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)를 확인한다.

2
content/ko/docs/tasks/inject-data-application/define-environment-variable-container.md
View File

@ -110,6 +110,6 @@ spec:
## {{% heading "whatsnext" %}}
* [환경 변수](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)에 대해 알아본다.
* [환경 변수](/ko/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)에 대해 알아본다.
* [시크릿을 환경 변수로 사용하기](/ko/docs/concepts/configuration/secret/#시크릿을-환경-변수로-사용하기)에 대해 알아본다.
* [EnvVarSource](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvarsource-v1-core)를 확인한다.

2
content/ko/docs/tasks/inject-data-application/define-interdependent-environment-variables.md
View File

@ -72,6 +72,6 @@ weight: 20
## {{% heading "whatsnext" %}}
* [환경 변수](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)에 대해 알아본다.
* [환경 변수](/ko/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)에 대해 알아본다.
* [EnvVarSource](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvarsource-v1-core)를 확인한다.

8
content/ko/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md
View File

@ -25,7 +25,7 @@ weight: 40
실행 중인 컨테이너에 파드 및 컨테이너 필드를 노출하는 방법에는 두 가지가 있다.
* [환경 변수](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/#the-downward-api)
* [환경 변수](/ko/docs/tasks/inject-data-application/environment-variable-expose-pod-information/#다운워드-downward-api)
* 볼륨 파일
파드 및 컨테이너 필드를 노출하는 이 두 가지 방법을 *다운워드 API*라고 한다.
@ -134,7 +134,7 @@ total 8
원자적(atomic)으로 갱신한다.
{{< note >}}
다운워드 API를 [subPath](/docs/concepts/storage/volumes/#using-subpath)
다운워드 API를 [subPath](/ko/docs/concepts/storage/volumes/#using-subpath)
볼륨 마운트로 사용하는 컨테이너는 다운워드 API 업데이트를 수신하지 않는다.
{{< /note >}}
@ -200,8 +200,8 @@ kubectl exec -it kubernetes-downwardapi-volume-example-2 -- sh
* 컨테이너의 CPU 요청(request)
* 컨테이너의 메모리 한도(limit)
* 컨테이너의 메모리 요청(request)
* 컨테이너의 hugepages 한도(limit) (`DownwardAPIHugePages` [기능 게이트(feature gate)](/docs/reference/command-line-tools-reference/feature-gates/)가 활성화된 경우)
* 컨테이너의 hugepages 요청(request) (`DownwardAPIHugePages` [기능 게이트(feature gate)](/docs/reference/command-line-tools-reference/feature-gates/)가 활성화된 경우)
* 컨테이너의 hugepages 한도(limit) (`DownwardAPIHugePages` [기능 게이트(feature gate)](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화된 경우)
* 컨테이너의 hugepages 요청(request) (`DownwardAPIHugePages` [기능 게이트(feature gate)](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화된 경우)
* 컨테이너의 임시-스토리지 한도(limit)
* 컨테이너의 임시-스토리지 요청(request)

4
content/ko/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md
View File

@ -27,7 +27,7 @@ weight: 30
파드 및 컨테이너 필드를 실행 중인 컨테이너에 노출하는 두 가지 방법이 있다.
* 환경 변수
* [볼륨 파일](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/#the-downward-api)
* [볼륨 파일](/ko/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/#다운워드-downward-api)
파드 및 컨테이너 필드를 노출하는 이 두 가지 방법을 *다운워드 API*라고 한다.
@ -145,7 +145,7 @@ kubectl logs dapi-envars-resourcefieldref
## {{% heading "whatsnext" %}}
* [컨테이너를 위한 환경 변수 정의하기](/docs/tasks/inject-data-application/define-environment-variable-container/)
* [컨테이너를 위한 환경 변수 정의하기](/ko/docs/tasks/inject-data-application/define-environment-variable-container/)
* [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)
* [컨테이너](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)
* [EnvVar](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvar-v1-core)

2
content/ko/docs/tasks/job/automated-tasks-with-cron-jobs.md
View File

@ -132,7 +132,7 @@ kubectl delete cronjob hello
## 크론 잡 명세 작성
다른 모든 쿠버네티스 구성과 마찬가지로, 크론 잡은 `apiVersion`, `kind` 그리고 `metadata` 필드가 필요하다. 구성 파일
작업에 대한 일반적인 정보는 [애플리케이션 배포](/docs/tasks/run-application/run-stateless-application-deployment/)와
작업에 대한 일반적인 정보는 [애플리케이션 배포](/ko/docs/tasks/run-application/run-stateless-application-deployment/)와
[kubectl을 사용하여 리소스 관리하기](/ko/docs/concepts/overview/working-with-objects/object-management/) 문서를 참고한다.
크론 잡 구성에는 [`.spec` 섹션](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)도 필요하다.

2
content/ko/docs/tasks/manage-daemon/update-daemon-set.md
View File

@ -147,7 +147,7 @@ daemonset "fluentd-elasticsearch" successfully rolled out
#### 일부 노드에 리소스가 부족하다
적어도 하나의 노드에서 새 데몬셋 파드를 스케줄링할 수 없어서 롤아웃이
중단되었다. 노드에 [리소스가 부족](/docs/concepts/scheduling-eviction/node-pressure-eviction/)할 때
중단되었다. 노드에 [리소스가 부족](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/)할 때
발생할 수 있다.
이 경우, `kubectl get nodes` 의 출력 결과와 다음의 출력 결과를 비교하여

4
content/ko/docs/tasks/run-application/delete-stateful-set.md
View File

@ -80,11 +80,11 @@ kubectl delete pvc -l app=myapp
### 스테이트풀셋 파드의 강제 삭제
스테이트풀셋의 일부 파드가 오랫동안 'Terminating' 또는 'Unknown' 상태에 있는 경우, apiserver에 수동적으로 개입하여 파드를 강제 삭제할 수도 있다. 이것은 잠재적으로 위험한 작업이다. 자세한 설명은 [스테이트풀셋 파드 강제 삭제하기](/docs/tasks/run-application/force-delete-stateful-set-pod/)를 참고한다.
스테이트풀셋의 일부 파드가 오랫동안 'Terminating' 또는 'Unknown' 상태에 있는 경우, apiserver에 수동적으로 개입하여 파드를 강제 삭제할 수도 있다. 이것은 잠재적으로 위험한 작업이다. 자세한 설명은 [스테이트풀셋 파드 강제 삭제하기](/ko/docs/tasks/run-application/force-delete-stateful-set-pod/)를 참고한다.
## {{% heading "whatsnext" %}}
[스테이트풀셋 파드 강제 삭제하기](/docs/tasks/run-application/force-delete-stateful-set-pod/)에 대해 더 알아보기.
[스테이트풀셋 파드 강제 삭제하기](/ko/docs/tasks/run-application/force-delete-stateful-set-pod/)에 대해 더 알아보기.

2
content/ko/docs/tasks/run-application/force-delete-stateful-set-pod.md
View File

@ -91,6 +91,6 @@ kubectl patch pod <pod> -p '{"metadata":{"finalizers":null}}'
## {{% heading "whatsnext" %}}
[스테이트풀셋 디버깅하기](/docs/tasks/debug-application-cluster/debug-stateful-set/)에 대해 더 알아보기.
[스테이트풀셋 디버깅하기](/ko/docs/tasks/debug-application-cluster/debug-stateful-set/)에 대해 더 알아보기.

2
content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
View File

@ -447,7 +447,7 @@ Events:
이 HorizontalPodAutoscaler 경우, 건강 상태의 여러 조건들을 볼 수 있다.
첫 번째 `AbleToScale`는 HPA가 스케일을 가져오고 업데이트할 수 있는지,
백 오프 관련 조건으로 스케일링이 방지되는지 여부를 나타낸다.
두 번째 `ScalingActive`는 HPA가 활성화되어있는지(즉 대상 레플리카 개수가 0이 아닌지),
두 번째 `ScalingActive`는 HPA가 활성화되어 있는지(즉 대상 레플리카 개수가 0이 아닌지),
원하는 스케일을 계산할 수 있는지 여부를 나타낸다. 만약 `False` 인 경우,
일반적으로 메트릭을 가져오는데 문제가 있다.
마지막으로, 마지막 조건인 `ScalingLimited`는

2
content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md
View File

@ -398,7 +398,7 @@ behavior:
안정화 윈도우는 스케일링에 사용되는 메트릭이 계속 변동할 때 레플리카의 플래핑을
다시 제한하기 위해 사용된다. 안정화 윈도우는 스케일링을 방지하기 위해 과거부터
계산된 의도한 상태를 고려하는 오토스케일링 알고리즘에 의해 사용된다.
다음의 예시에서 `scaleDown` 에 대해 안정화 윈도우가 지정되어있다.
다음의 예시에서 `scaleDown` 에 대해 안정화 윈도우가 지정되어 있다.
```yaml
scaleDown:

2
content/ko/docs/tasks/run-application/run-single-instance-stateful-application.md
View File

@ -196,7 +196,7 @@ kubectl delete pv mysql-pv-volume
* [디플로이먼트 오브젝트](/ko/docs/concepts/workloads/controllers/deployment/)에 대해 더 배워 보기
* [애플리케이션 배포하기](/docs/tasks/run-application/run-stateless-application-deployment/)에 대해 더 배워보기
* [애플리케이션 배포하기](/ko/docs/tasks/run-application/run-stateless-application-deployment/)에 대해 더 배워보기
* [kubectl run 문서](/docs/reference/generated/kubectl/kubectl-commands/#run)

18
content/ko/docs/tutorials/clusters/apparmor.md
View File

@ -346,21 +346,21 @@ Events:
[노드 셀렉터](/ko/docs/concepts/scheduling-eviction/assign-pod-node/)를 이용하여
파드가 필요한 프로파일이 있는 노드에서 실행되도록 한다.
### PodSecurityPolicy로 프로파일 제한하기 {#restricting-profiles-with-the-podsecuritypolicy}
### 파드시큐리티폴리시(PodSecurityPolicy)로 프로파일 제한하기 {#restricting-profiles-with-the-podsecuritypolicy}
{{< note >}}
PodSecurityPolicy는 쿠버네티스 v1.21에서 사용 중지되었으며, v1.25에서 제거될 예정이다.
더 자세한 내용은 [PodSecurityPolicy 문서](/ko/docs/concepts/policy/pod-security-policy/)를 참고한다.
파드시큐리티폴리시는 쿠버네티스 v1.21에서 사용 중단되었으며, v1.25에서 제거될 예정이다.
더 자세한 내용은 [파드시큐리티폴리시 문서](/ko/docs/concepts/policy/pod-security-policy/)를 참고한다.
{{< /note >}}
만약 PodSecurityPolicy 확장을 사용하면, 클러스터 단위로 AppArmor 제한을 적용할 수 있다.
PodSecurityPolicy를 사용하려면 위해 다음의 플래그를 반드시 `apiserver`에 설정해야 한다.
만약 파드시큐리티폴리시 확장을 사용하면, 클러스터 단위로 AppArmor 제한을 적용할 수 있다.
파드시큐리티폴리시를 사용하려면 위해 다음의 플래그를 반드시 `apiserver`에 설정해야 한다.
```
--enable-admission-plugins=PodSecurityPolicy[,others...]
```
AppArmor 옵션은 PodSecurityPolicy의 어노테이션으로 지정할 수 있다.
AppArmor 옵션은 파드시큐리티폴리시의 어노테이션으로 지정할 수 있다.
```yaml
apparmor.security.beta.kubernetes.io/defaultProfileName: <profile_ref>
@ -390,7 +390,7 @@ AppArmor가 일반 사용자 버전이 되면 제거된다.
### AppArmor와 함께 쿠버네티스 1.4로 업그레이드 하기 {#upgrading-to-kubernetes-v1.4-with-apparmor}
클러스터 버전을 v1.4로 업그레이드하기 위해 AppArmor쪽 작업은 없다.
그러나 AppArmor 어노테이션을 가진 파드는 유효성 검사(혹은 PodSecurityPolicy 승인)을 거치지 않는다.
그러나 AppArmor 어노테이션을 가진 파드는 유효성 검사(혹은 파드시큐리티폴리시 승인)을 거치지 않는다.
그 노드에 허용 프로파일이 로드되면, 악의적인 사용자가 허가 프로필을 미리 적용하여
파드의 권한을 docker-default 보다 높일 수 있다.
이것이 염려된다면 `apparmor.security.beta.kubernetes.io` 어노테이션이 포함된
@ -439,7 +439,7 @@ AppArmor 로그는 `dmesg`에서 보이며, 오류는 보통 시스템 로그나
### 프로파일 참조 {#profile-reference}
- `runtime/default`: 기본 런타임 프로파일을 참조한다.
- (기본 PodSecurityPolicy 없이) 프로파일을 지정하지 않고
- (기본 파드시큐리티폴리시 없이) 프로파일을 지정하지 않고
AppArmor를 사용하는 것과 동등하다.
- 도커에서는 권한 없는 컨테이너의 경우는
[`docker-default`](https://docs.docker.com/engine/security/apparmor/) 프로파일로,
@ -451,7 +451,7 @@ AppArmor 로그는 `dmesg`에서 보이며, 오류는 보통 시스템 로그나
다른 어떤 프로파일 참조 형식도 유효하지 않다.
### PodSecurityPolicy 어노테이션 {#podsecuritypolicy-annotations}
### 파드시큐리티폴리시 어노테이션 {#podsecuritypolicy-annotations}
아무 프로파일도 제공하지 않을 때에 컨테이너에 적용할 기본 프로파일을 지정하기

2
content/ko/docs/tutorials/hello-minikube.md
View File

@ -301,5 +301,5 @@ minikube delete
* [디플로이먼트 오브젝트](/ko/docs/concepts/workloads/controllers/deployment/)에 대해서 더 배워 본다.
* [애플리케이션 배포](/docs/tasks/run-application/run-stateless-application-deployment/)에 대해서 더 배워 본다.
* [애플리케이션 배포](/ko/docs/tasks/run-application/run-stateless-application-deployment/)에 대해서 더 배워 본다.
* [서비스 오브젝트](/ko/docs/concepts/services-networking/service/)에 대해서 더 배워 본다.

2
content/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md
View File

@ -239,4 +239,4 @@ kubectl apply -k ./
* [인트로스펙션과 디버깅](/docs/tasks/debug-application-cluster/debug-application-introspection/)를 알아보자.
* [잡](/ko/docs/concepts/workloads/controllers/job/)를 알아보자.
* [포트 포워딩](/ko/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)를 알아보자.
* 어떻게 [컨테이너에서 셸을 사용하는지](/docs/tasks/debug-application-cluster/get-shell-running-container/)를 알아보자.
* 어떻게 [컨테이너에서 셸을 사용하는지](/ko/docs/tasks/debug-application-cluster/get-shell-running-container/)를 알아보자.