whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Ko: 1st Korean l10n work for release-1.20

Browse Source 
- Translate reference/glossary/persistent-volume.md in Korean (#25474)
- Update outdated files in the dev-1.20-ko.1 branch (1) (#25576)
- Translate blog/dont-panic-kubernetes-and-docker into Korean (#25596)
- Update outdated files in the dev-1.20-ko.1 branch(3) (#25728)
- Ko: enhance tutorials//cluster-intro translation (#25754)
- Fix Outdated files in the dev-1.20-ko.1 branch (2) (#25765)

Co-authored-by: seokho-son <shsongist@gmail.com>
Co-authored-by: jmyung <jesang.myung@gmail.com>
Co-authored-by: Jerry Park <jaehwa@gmail.com>
Co-authored-by: santachopa <santachopa@naver.com>
Co-authored-by: SEUNGHYUN KO <kosehy@gmail.com>
Co-authored-by: June Yi <gochist@gmail.com>
This commit is contained in:
Jerry Park
2020-12-14 00:16:04 +00:00
committed by seokho-son
parent 8fd80c3e35
commit 0ed380d4aa
60 changed files with 1290 additions and 731 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/ko/docs/concepts/architecture/nodes.md
+21
View File
@@ -327,6 +327,26 @@ kubelet은 `NodeStatus` 와 리스 오브젝트를 생성하고 업데이트 할
자세한 내용은
[노드의 컨트롤 토폴로지 관리 정책](/docs/tasks/administer-cluster/topology-manager/)을 본다.
## 그레이스풀(Graceful) 노드 셧다운
{{< feature-state state="alpha" for_k8s_version="v1.20" >}}
`GracefulNodeShutdown` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화한 경우 kubelet은 노드 시스템 종료를 감지하고 노드에서 실행 중인 파드를 종료한다.
Kubelet은 노드가 종료되는 동안 파드가 일반 [파드 종료 프로세스](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)를 따르도록 한다.
`GracefulNodeShutdown` 기능 게이트가 활성화되면 kubelet은 [systemd inhibitor locks](https://www.freedesktop.org/wiki/Software/systemd/inhibit/)를 사용하여 주어진 기간 동안 노드 종료를 지연시킨다. 종료 중에 kubelet은 두 단계로 파드를 종료시킨다.
1. 노드에서 실행 중인 일반 파드를 종료시킨다.
2. 노드에서 실행 중인 [중요(critical) 파드](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)를 종료시킨다.
그레이스풀 노드 셧다운 기능은 두 개의 [`KubeletConfiguration`](/docs/tasks/administer-cluster/kubelet-config-file/) 옵션으로 구성된다.
* `ShutdownGracePeriod`:
* 노드가 종료를 지연해야 하는 총 기간을 지정한다. 이것은 모든 일반 및 [중요 파드](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)의 파드 종료에 필요한 총 유예 기간에 해당한다.
* `ShutdownGracePeriodCriticalPods`:
* 노드 종료 중에 [중요 파드](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-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)의 종료에 할당된다.
## {{% heading "whatsnext" %}}
@@ -335,3 +355,4 @@ kubelet은 `NodeStatus` 와 리스 오브젝트를 생성하고 업데이트 할
* 아키텍처 디자인 문서의 [노드](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node)
섹션을 읽어본다.
* [테인트와 톨러레이션](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)을 읽어본다.
content/ko/docs/concepts/cluster-administration/kubelet-garbage-collection.md
+8 -10
View File
@@ -17,7 +17,7 @@ weight: 70
## 이미지 수집
쿠버네티스는 cadvisor와 imageManager를 통하여 모든 이미지들의
쿠버네티스는 cadvisor와 imageManager를 통하여 모든 이미지들의
라이프사이클을 관리한다.
이미지들에 대한 가비지 수집 정책에는 다음 2가지 요소가 고려된다:
@@ -36,26 +36,26 @@ kubelet이 관리하지 않는 컨테이너는 컨테이너 가비지 수집 대
## 사용자 설정
사용자는 후술될 kubelet 플래그들을 통하여 이미지 가비지 수집을 조정하기 위하여 다음의 임계값을 조정할 수 있다.
여러분은 후술될 kubelet 플래그들을 통하여 이미지 가비지 수집을 조정하기 위하여 다음의 임계값을 조정할 수 있다.
1. `image-gc-high-threshold`, 이미지 가비지 수집을 발생시키는 디스크 사용량의 비율로
기본값은 85% 이다.
2. `image-gc-low-threshold`, 이미지 가비지 수집을 더 이상 시도하지 않는 디스크 사용량의 비율로
기본값은 80% 이다.
또한 사용자는 다음의 kubelet 플래그를 통해 가비지 수집 정책을 사용자 정의 할 수 있다.
다음의 kubelet 플래그를 통해 가비지 수집 정책을 사용자 정의할 수 있다.
1. `minimum-container-ttl-duration`, 종료된 컨테이너가 가비지 수집
되기 전의 최소 시간. 기본 값은 0 분이며, 이 경우 모든 종료된 컨테이너는 바로 가비지 수집의 대상이 된다.
1. `minimum-container-ttl-duration`, 종료된 컨테이너가 가비지 수집
되기 전의 최소 시간. 기본 값은 0 분이며, 이 경우 모든 종료된 컨테이너는 바로 가비지 수집의 대상이 된다.
2. `maximum-dead-containers-per-container`, 컨테이너가 보유할 수 있는 오래된
인스턴스의 최대 수. 기본 값은 1 이다.
3. `maximum-dead-containers`, 글로벌하게 보유 할 컨테이너의 최대 오래된 인스턴스의 최대 수.
기본 값은 -1이며, 이 경우 인스턴스 수의 제한은 없다.
컨테이너들은 유용성이 만료되기 이전에도 가비지 수집이 될 수 있다. 이러한 컨테이너들은
문제 해결에 도움이 될 수 있는 로그나 다른 데이터를 포함하고 있을 수 있다. 컨테이너 당 적어도
1개의 죽은 컨테이너가 허용될 수 있도록 `maximum-dead-containers-per-container`
값을 충분히 큰 값으로 지정하는 것을 권장한다. 동일한 이유로 `maximum-dead-containers`
문제 해결에 도움이 될 수 있는 로그나 다른 데이터를 포함하고 있을 수 있다. 컨테이너 당 적어도
1개의 죽은 컨테이너가 허용될 수 있도록 `maximum-dead-containers-per-container`
값을 충분히 큰 값으로 지정하는 것을 권장한다. 동일한 이유로 `maximum-dead-containers`
의 값도 상대적으로 더 큰 값을 권장한다.
자세한 내용은 [해당 이슈](https://github.com/kubernetes/kubernetes/issues/13287)를 참고한다.
@@ -82,5 +82,3 @@ kubelet이 관리하지 않는 컨테이너는 컨테이너 가비지 수집 대
자세한 내용은 [리소스 부족 처리 구성](/docs/tasks/administer-cluster/out-of-resource/)를 본다.
content/ko/docs/concepts/cluster-administration/networking.md
+3 -2
View File
@@ -55,11 +55,12 @@ weight: 50
주로 호환된다. 잡이 이전에 VM에서 실행된 경우, VM에 IP가 있고
프로젝트의 다른 VM과 통신할 수 있다. 이것은 동일한 기본 모델이다.
쿠버네티스의 IP 주소는 그것의 IP 주소를 포함하여 `Pod` 범위에 존재한다(`Pod` 내
쿠버네티스의 IP 주소는 그것의 IP 주소와 MAC 주소를 포함하여 `Pod` 범위에 존재한다(`Pod` 내
컨테이너는 네트워크 네임스페이스를 공유함). 이것은 `Pod` 내 컨테이너가 모두
`localhost` 에서 서로의 포트에 도달할 수 있다는 것을 의미한다. 또한
`Pod` 내부의 컨테이너 포트의 사용을 조정해야하는 것을 의미하지만, 이것도
VM 내의 프로세스와 동일하다. 이것을 "IP-per-pod(파드별 IP)" 모델이라고 한다.
VM 내의 프로세스와 동일하다. 이것을 "IP-per-pod(파드별 IP)" 모델이라고
한다.
이것이 어떻게 구현되는 지는 사용 중인 특정 컨테이너 런타임의 세부 사항이다.
content/ko/docs/concepts/cluster-administration/system-metrics.md
+19
View File
@@ -128,6 +128,25 @@ cloudprovider_gce_api_request_duration_seconds { request = "detach_disk"}
cloudprovider_gce_api_request_duration_seconds { request = "list_disk"}
```
### kube-scheduler 메트릭
{{< feature-state for_k8s_version="v1.20" state="alpha" >}}
스케줄러는 실행 중인 모든 파드의 요청(request)된 리소스와 요구되는 제한(limit)을 보고하는 선택적 메트릭을 노출한다. 이러한 메트릭은 용량 계획(capacity planning) 대시보드를 구축하고, 현재 또는 과거 스케줄링 제한을 평가하고, 리소스 부족으로 스케줄할 수 없는 워크로드를 빠르게 식별하고, 실제 사용량을 파드의 요청과 비교하는 데 사용할 수 있다.
kube-scheduler는 각 파드에 대해 구성된 리소스 [요청과 제한](/ko/docs/concepts/configuration/manage-resources-containers/)을 식별한다. 요청 또는 제한이 0이 아닌 경우 kube-scheduler는 메트릭 시계열을 보고한다. 시계열에는 다음과 같은 레이블이 지정된다.
- 네임스페이스
- 파드 이름
- 파드가 스케줄된 노드 또는 아직 스케줄되지 않은 경우 빈 문자열
- 우선순위
- 해당 파드에 할당된 스케줄러
- 리소스 이름 (예: `cpu`)
- 알려진 경우 리소스 단위 (예: `cores`)
파드가 완료되면 (`Never` 또는 `OnFailure`의 `restartPolicy`가 있고 `Succeeded` 또는 `Failed` 파드 단계에 있거나, 삭제되고 모든 컨테이너가 종료된 상태에 있음) 스케줄러가 이제 다른 파드를 실행하도록 스케줄할 수 있으므로 시리즈가 더 이상 보고되지 않는다. 두 메트릭을 `kube_pod_resource_request` 및 `kube_pod_resource_limit` 라고 한다.
메트릭은 HTTP 엔드포인트 `/metrics/resources`에 노출되며 스케줄러의 `/metrics` 엔드포인트
와 동일한 인증이 필요하다. 이러한 알파 수준의 메트릭을 노출시키려면 `--show-hidden-metrics-for-version=1.20` 플래그를 사용해야 한다.
## {{% heading "whatsnext" %}}
content/ko/docs/concepts/configuration/manage-resources-containers.md
+4
View File
@@ -600,6 +600,10 @@ spec:
example.com/foo: 1
```
## PID 제한
프로세스 ID(PID) 제한은 kubelet의 구성에 대해 주어진 파드가 사용할 수 있는 PID 수를 제한할 수 있도록 허용한다. 자세한 내용은 [Pid 제한](/docs/concepts/policy/pid-limiting/)을 참고한다.
## 문제 해결
### 내 파드가 failedScheduling 이벤트 메시지로 보류 중이다
content/ko/docs/concepts/configuration/secret.md
+11 -7
View File
@@ -134,7 +134,7 @@ data:
[서비스 어카운트](/docs/tasks/configure-pod-container/configure-service-account/) 문서를 보면
서비스 어카운트가 동작하는 방법에 대한 더 자세한 정보를 얻을 수 있다.
또한 파드에서 서비스 어카운트를 참조하는 방법을
[`Pod`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core)의
[`Pod`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)의
`automountServiceAccountToken` 필드와 `serviceAccountName`
필드를 통해 확인할 수 있다.
@@ -152,7 +152,7 @@ data:
인코딩된 `~/.dockercfg` 파일의 콘텐츠를 값으로 가지는 `.dockercfg` 키를 포함하고 있는지
확실히 확인해야 한다.
`kubernetes/dockerconfigjson` 타입은 `~/.dockercfg` 의
`kubernetes.io/dockerconfigjson` 타입은 `~/.dockercfg` 의
새로운 포맷인 `~/.docker/config.json` 파일과 동일한 포맷 법칙을
따르는 직렬화 된 JSON의 저장을 위해 디자인되었다.
이 시크릿 타입을 사용할 때는, 시크릿 오브젝트의 `data` 필드가 `.dockerconfigjson` 키를
@@ -347,22 +347,21 @@ data:
usage-bootstrap-signing: dHJ1ZQ==
```
부트스트랩 타입은 `data` 아래 명시된 다음의 키들을 가진다.
부트스트랩 타입 시크릿은 `data` 아래 명시된 다음의 키들을 가진다.
- `token_id`: 토큰 식별자로 임의의 6개 문자의 문자열. 필수 사항.
- `token-secret`: 실제 토큰 시크릿으로 임의의 16개 문자의 문자열. 필수 사항.
- `description1`: 토큰의 사용처를 설명하는 사람이 읽을 수 있는
- `description`: 토큰의 사용처를 설명하는 사람이 읽을 수 있는
문자열. 선택 사항.
- `expiration`: 토큰이 만료되어야 하는 시기를 명시한 RFC3339를
사용하는 절대 UTC 시간. 선택 사항.
- `usage-bootstrap-<usage>`: 부트스트랩 토큰의 추가적인 사용처를 나타내는
불리언(boolean) 플래그.
- `auth-extra-groups`: system:bootstrappers 그룹에 추가로 인증될
- `auth-extra-groups`: `system:bootstrappers` 그룹에 추가로 인증될
쉼표로 구분된 그룹 이름 목록.
위의 YAML은 모두 base64로 인코딩된 문자열 값이므로 혼란스러워 보일
수 있다. 사실은 다음 YAML을 사용하여 동일한 시크릿 오브젝트 결과를 만드는
동일한 시크릿을 생성할 수 있다.
수 있다. 사실은 다음 YAML을 사용하여 동일한 시크릿을 생성할 수 있다.
```yaml
apiVersion: v1
@@ -724,6 +723,11 @@ echo $SECRET_PASSWORD
1f2d1e2e67df
```
#### 시크릿 업데이트 후 환경 변수가 업데이트되지 않음
컨테이너가 환경 변수에서 이미 시크릿을 사용하는 경우, 다시 시작하지 않는 한 컨테이너에서 시크릿 업데이트를 볼 수 없다.
시크릿이 변경될 때 재시작을 트리거하는 써드파티 솔루션이 있다.
## 변경할 수 없는(immutable) 시크릿 {#secret-immutable}
{{< feature-state for_k8s_version="v1.19" state="beta" >}}
content/ko/docs/concepts/containers/runtime-class.md
+2 -2
View File
@@ -6,7 +6,7 @@ weight: 20
<!-- overview -->
{{< feature-state for_k8s_version="v1.12" state="alpha" >}}
{{< feature-state for_k8s_version="v1.20" state="stable" >}}
이 페이지는 런타임클래스 리소스와 런타임 선택 메커니즘에 대해서 설명한다.
@@ -63,7 +63,7 @@ weight: 20
(`handler`)로 단 2개의 중요 필드만 가지고 있다. 오브젝트 정의는 다음과 같은 형태이다.
```yaml
apiVersion: node.k8s.io/v1beta1 # 런타임클래스는 node.k8s.io API 그룹에 정의되어 있음
apiVersion: node.k8s.io/v1 # 런타임클래스는 node.k8s.io API 그룹에 정의되어 있음
kind: RuntimeClass
metadata:
name: myclass # 런타임클래스는 해당 이름을 통해서 참조됨
content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md
+1 -3
View File
@@ -203,7 +203,7 @@ gRPC 서비스는 `/var/lib/kubelet/pod-resources/kubelet.sock` 의 유닉스
`/var/lib/kubelet/pod-resources` 를
{{< glossary_tooltip text="볼륨" term_id="volume" >}}으로 마운트해야 한다.
"PodResources 서비스"를 지원하려면 `KubeletPodResources` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다. 쿠버네티스 1.15부터 기본적으로 활성화되어 있다.
"PodResources 서비스"를 지원하려면 `KubeletPodResources` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다.
## 토폴로지 관리자와 장치 플러그인 통합
@@ -254,5 +254,3 @@ pluginapi.Device{ID: "25102017", Health: pluginapi.Healthy, Topology:&pluginapi.
* 노드에서의 [확장 리소스 알리기](/ko/docs/tasks/administer-cluster/extended-resource-node/)에 대해 배우기
* 쿠버네티스에서 [TLS 수신에 하드웨어 가속](https://kubernetes.io/blog/2019/04/24/hardware-accelerated-ssl/tls-termination-in-ingress-controllers-using-kubernetes-device-plugins-and-runtimeclass/) 사용에 대해 읽기
* [토폴로지 관리자](/docs/tasks/administer-cluster/topology-manager/)에 대해 알아보기
content/ko/docs/concepts/overview/kubernetes-api.md
+37 -29
View File
@@ -75,19 +75,10 @@ Protobuf에 기반한 직렬화 형식을 구현한다. 이 형식에 대한
API 오브젝트를 정의하는 Go 패키지에 들어있는 각각의 스키마에 대한
IDL(인터페이스 정의 언어) 파일을 참고한다.
## API 변경 사항
## 지속성
성공적인 시스템은 새로운 유스케이스가 등장하거나 기존 사례가 변경됨에 따라 성장하고 변화해야 한다.
따라서, 쿠버네티스는 쿠버네티스 API가 지속적으로 변경되고 성장할 수 있도록 기능을 설계했다.
쿠버네티스 프로젝트는 기존 클라이언트와의 호환성을 깨지 _않고_ 다른 프로젝트가
적응할 기회를 가질 수 있도록 장기간 해당 호환성을 유지하는 것을 목표로 한다.
일반적으로, 새 API 리소스와 새 리소스 필드는 자주 추가될 수 있다.
리소스 또는 필드를 제거하려면
[API 지원 중단 정책](/docs/reference/using-api/deprecation-policy/)을 따라야 한다.
호환 가능한 변경 사항과 API 변경 방법은
[API 변경 사항](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme)에 자세히 설명되어 있다.
쿠버네티스는 오브젝트의 직렬화된 상태를
{{< glossary_tooltip term_id="etcd" >}}에 기록하여 저장한다.
## API 그룹과 버전 규칙
@@ -105,29 +96,44 @@ API가 시스템 리소스 및 동작에 대한 명확하고 일관된 보기를
가능한 [API 그룹](/ko/docs/reference/using-api/#api-그룹)을 구현한다.
API 리소스는 API 그룹, 리소스 유형, 네임스페이스
(네임스페이스 리소스용) 및 이름으로 구분된다. API 서버는
여러 API 버전을 통해 동일한 기본 데이터를 제공하고 API 버전 간의
변환을 투명하게 처리할 수 있다. 이 모든 다른 버전은 실제로
같은 리소스의 표현이다. 예를 들어 동일한 리소스에 대해
두 가지 버전 `v1`과 `v1beta1`이 있다고 가정해 보자.
`v1beta1` 버전에서 생성된 오브젝트를 `v1beta1` 또는 `v1` 버전에서
읽기, 업데이트 및 삭제할 수 있다.
(네임스페이스 리소스용) 및 이름으로 구분된다. API 서버는 API 버전 간의
변환을 투명하게 처리한다. 서로 다른 모든 버전은 실제로
동일한 지속 데이터의 표현이다. API 서버는 여러 API 버전을 통해
동일한 기본 데이터를 제공할 수 있다.
API 버전 수준 정의에 대한 자세한 내용은
[API 버전 레퍼런스](/ko/docs/reference/using-api/#api-버전-규칙)를 참조한다.
예를 들어, 동일한 리소스에 대해 `v1` 과 `v1beta1` 이라는 두 가지 API 버전이
있다고 가정한다. 원래 API의 `v1beta1` 버전을 사용하여 오브젝트를
만든 경우, 나중에 `v1beta1` 또는 `v1` API 버전을 사용하여 해당 오브젝트를
읽거나, 업데이트하거나, 삭제할 수 있다.
API 리소스는 해당 API 그룹, 리소스 유형, 네임스페이스
(네임스페이스 리소스용) 및 이름으로 구분된다. API 서버는 여러 API 버전을 통해 동일한
기본 데이터를 제공하고 API 버전 간의 변환을 투명하게
처리할 수 있다. 이 모든 다른 버전은 실제로
동일한 리소스의 표현이다. 예를 들어, 동일한 리소스에 대해 두 가지
버전 `v1` 과 `v1beta1` 이 있다고 가정한다. 그런 다음 `v1beta1` 버전에서
생성된 오브젝트를 `v1beta1` 또는 `v1` 버전에서 읽고 업데이트하고
삭제할 수 있다.
## API 변경 사항
성공적인 시스템은 새로운 유스케이스가 등장하거나 기존 사례가 변경됨에 따라 성장하고 변화해야 한다.
따라서, 쿠버네티스는 쿠버네티스 API가 지속적으로 변경되고 성장할 수 있도록 설계했다.
쿠버네티스 프로젝트는 기존 클라이언트와의 호환성을 깨지 _않고_ 다른 프로젝트가
적응할 기회를 가질 수 있도록 장기간 해당 호환성을 유지하는 것을 목표로 한다.
일반적으로, 새 API 리소스와 새 리소스 필드는 자주 추가될 수 있다.
리소스 또는 필드를 제거하려면
[API 지원 중단 정책](/docs/reference/using-api/deprecation-policy/)을 따라야 한다.
쿠버네티스는 일반적으로 API 버전 `v1` 에서 안정 버전(GA)에 도달하면, 공식 쿠버네티스 API에
대한 호환성 유지를 강력하게 이행한다. 또한,
쿠버네티스는 가능한 경우 _베타_ API 버전에서도 호환성을 유지한다.
베타 API를 채택하면 기능이 안정된 후에도 해당 API를 사용하여 클러스터와
계속 상호 작용할 수 있다.
{{< note >}}
쿠버네티스는 또한 _알파_ API 버전에 대한 호환성을 유지하는 것을 목표로 하지만, 일부
상황에서는 호환성이 깨진다. 알파 API 버전을 사용하는 경우, API가 변경된 경우 클러스터를
업그레이드할 때 쿠버네티스에 대한 릴리스 정보를 확인한다.
{{< /note >}}
API 버전 수준 정의에 대한 자세한 내용은
[API 버전 레퍼런스](/ko/docs/reference/using-api/api-overview/#api-버전-규칙)를 참조한다.
## API 확장
쿠버네티스 API는 다음 두 가지 방법 중 하나로 확장할 수 있다.
@@ -145,3 +151,5 @@ API 버전 수준 정의에 대한 자세한 내용은
클러스터가 API 접근을 위한 인증 및 권한을 관리하는 방법을 설명한다.
- [API 레퍼런스](/docs/reference/kubernetes-api/)를
읽고 API 엔드포인트, 리소스 유형 및 샘플에 대해 배우기.
- [API 변경 사항](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme)에서
호환 가능한 변경 사항을 구성하고, API를 변경하는 방법에 대해 알아본다.
content/ko/docs/concepts/overview/working-with-objects/labels.md
+5 -4
View File
@@ -138,10 +138,11 @@ partition
!partition
```
첫 번째 예시에서 키가 `environment`이고 값이 `production` 또는 `qa`인 모든 리소스를 선택한다.
두 번째 예시에서 키가 `tier`이고 값이 `frontend`와 `backend`를 가지는 리소스를 제외한 모든 리소스와 키로 `tier`를 가지고 값을 공백으로 가지는 모든 리소스를 선택한다.
세 번째 예시에서 레이블의 값에 상관없이 키가 `partition`을 포함하는 모든 리소스를 선택한다.
네 번째 예시에서 레이블의 값에 상관없이 키가 `partition`을 포함하지 않는 모든 리소스를 선택한다.
* 첫 번째 예시에서 키가 `environment`이고 값이 `production` 또는 `qa`인 모든 리소스를 선택한다.
* 두 번째 예시에서 키가 `tier`이고 값이 `frontend`와 `backend`를 가지는 리소스를 제외한 모든 리소스와 키로 `tier`를 가지고 값을 공백으로 가지는 모든 리소스를 선택한다.
* 세 번째 예시에서 레이블의 값에 상관없이 키가 `partition`을 포함하는 모든 리소스를 선택한다.
* 네 번째 예시에서 레이블의 값에 상관없이 키가 `partition`을 포함하지 않는 모든 리소스를 선택한다.
마찬가지로 쉼표는 _AND_ 연산자로 작동한다. 따라서 `partition,environment notin (qa)`와 같이 사용하면 값과 상관없이 키가 `partition`인 것과 키가 `environment`이고 값이 `qa`와 다른 리소스를 필터링할 수 있다.
_집합성 기준_ 레이블 셀렉터는 일반적으로 `environment=production`과 `environment in (production)`을 같은 것으로 본다. 유사하게는 `!=`과 `notin`을 같은 것으로 본다.
content/ko/docs/concepts/policy/pod-security-policy.md
+1 -1
View File
@@ -1,7 +1,7 @@
---
title: 파드 시큐리티 폴리시
content_type: concept
weight: 20
weight: 30
---
<!-- overview -->
content/ko/docs/concepts/policy/resource-quotas.md
+1 -1
View File
@@ -1,7 +1,7 @@
---
title: 리소스 쿼터
content_type: concept
weight: 10
weight: 20
---
<!-- overview -->
content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md
+45
View File
@@ -154,6 +154,49 @@ spec:
`preferredDuringSchedulingIgnoredDuringExecution` 의 `weight` 필드의 범위는 1-100이다. 모든 스케줄링 요구 사항 (리소스 요청, RequiredDuringScheduling 어피니티 표현식 등)을 만족하는 각 노드들에 대해 스케줄러는 이 필드의 요소들을 반복해서 합계를 계산하고 노드가 MatchExpressions 에 일치하는 경우 합계에 "가중치(weight)"를 추가한다. 이후에 이 점수는 노드에 대한 다른 우선순위 함수의 점수와 합쳐진다. 전체 점수가 가장 높은 노드를 가장 선호한다.
#### 스케줄링 프로파일당 노드 어피니티
{{< feature-state for_k8s_version="v1.20" state="beta" >}}
여러 [스케줄링 프로파일](/ko/docs/reference/scheduling/config/#여러-프로파일)을 구성할 때
노드 어피니티가 있는 프로파일을 연결할 수 있는데, 이는 프로파일이 특정 노드 집합에만 적용되는 경우 유용하다.
이렇게 하려면 [스케줄러 구성](/ko/docs/reference/scheduling/config/)에 있는
[`NodeAffinity` 플러그인](/ko/docs/reference/scheduling/config/#스케줄링-플러그인-1)의 인수에 `addedAffinity`를 추가한다. 예를 들면
```yaml
apiVersion: kubescheduler.config.k8s.io/v1beta1
kind: KubeSchedulerConfiguration
profiles:
- schedulerName: default-scheduler
- schedulerName: foo-scheduler
pluginConfig:
- name: NodeAffinity
args:
addedAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: scheduler-profile
operator: In
values:
- foo
```
`addedAffinity`는 `.spec.schedulerName`을 `foo-scheduler`로 설정하는 모든 파드에 적용되며
PodSpec에 지정된 NodeAffinity도 적용된다.
즉, 파드를 매칭시키려면, 노드가 `addedAffinity`와 파드의 `.spec.NodeAffinity`를 충족해야 한다.
`addedAffinity`는 엔드 유저에게 표시되지 않으므로, 예상치 못한 동작이 일어날 수 있다. 프로파일의
스케줄러 이름과 명확한 상관 관계가 있는 노드 레이블을 사용하는 것이 좋다.
{{< note >}}
[데몬셋용 파드를 생성](/ko/docs/concepts/workloads/controllers/daemonset/#기본-스케줄러로-스케줄)하는 데몬셋 컨트롤러는
스케줄링 프로파일을 인식하지 못한다.
따라서 `addedAffinity`없이 `default-scheduler`와 같은 스케줄러 프로파일을 유지하는 것이 좋다. 그런 다음 데몬셋의 파드 템플릿이 스케줄러 이름을 사용해야 한다.
그렇지 않으면, 데몬셋 컨트롤러에 의해 생성된 일부 파드가 스케줄되지 않은 상태로 유지될 수 있다.
{{< /note >}}
### 파드간 어피니티와 안티-어피니티
파드간 어피니티와 안티-어피니티를 사용하면 노드의 레이블을 기반으로 하지 않고, *노드에서 이미 실행 중인 파드 레이블을 기반으로*
@@ -386,3 +429,5 @@ spec:
파드가 노드에 할당되면 kubelet은 파드를 실행하고 노드의 로컬 리소스를 할당한다.
[토폴로지 매니저](/docs/tasks/administer-cluster/topology-manager/)는
노드 수준의 리소스 할당 결정에 참여할 수 있다.
content/ko/docs/concepts/scheduling-eviction/pod-overhead.md
+1 -1
View File
@@ -44,7 +44,7 @@ _파드 오버헤드_ 는 컨테이너 리소스 요청과 상한 위에서 파
```yaml
---
kind: RuntimeClass
apiVersion: node.k8s.io/v1beta1
apiVersion: node.k8s.io/v1
metadata:
name: kata-fc
handler: kata-fc
content/ko/docs/concepts/services-networking/dns-pod-service.md
+1 -5
View File
@@ -165,11 +165,7 @@ A 또는 AAAA 레코드만 생성할 수 있다. (`default-subdomain.my-namespac
### 파드의 setHostnameAsFQDN 필드 {# pod-sethostnameasfqdn-field}
{{< feature-state for_k8s_version="v1.19" state="alpha" >}}
**전제 조건**: `SetHostnameAsFQDN` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를
{{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}}에
대해 활성화해야 한다.
{{< feature-state for_k8s_version="v1.20" state="beta" >}}
파드가 전체 주소 도메인 이름(FQDN)을 갖도록 구성된 경우, 해당 호스트네임은 짧은 호스트네임이다. 예를 들어, 전체 주소 도메인 이름이 `busybox-1.default-subdomain.my-namespace.svc.cluster-domain.example` 인 파드가 있는 경우, 기본적으로 해당 파드 내부의 `hostname` 명령어는 `busybox-1` 을 반환하고 `hostname --fqdn` 명령은 FQDN을 반환한다.
content/ko/docs/concepts/services-networking/dual-stack.md
+151 -20
View File
@@ -26,14 +26,17 @@ weight: 70
쿠버네티스 클러스터에서 IPv4/IPv6 이중 스택을 활성화하면 다음의 기능을 제공한다.
* 이중 스택 파드 네트워킹(파드 당 단일 IPv4와 IPv6 주소 할당)
* IPv4와 IPv6 지원 서비스(각 서비스는 단일 주소 패밀리이어야 한다.)
* IPv4와 IPv6 지원 서비스
* IPv4와 IPv6 인터페이스를 통한 파드 오프(off) 클러스터 이그레스 라우팅(예: 인터넷)
## 필수 구성 요소
IPv4/IPv6 이중 스택 쿠버네티스 클러스터를 활용하려면 다음의 필수 구성 요소가 필요하다.
* 쿠버네티스 1.16 또는 이후 버전
* 쿠버네티스 1.20 이상
이전 버전과 함께 이중 스택 서비스를 사용하는 방법에 대한 정보
쿠버네티스 버전, 쿠버네티스 해당 버전에 대한
문서 참조
* 이중 스택 네트워킹을 위한 공급자의 지원(클라우드 공급자 또는 다른 방식으로 쿠버네티스 노드에 라우팅 가능한 IPv4/IPv6 네트워크 인터페이스를 제공할 수 있어야 한다.)
* 이중 스택(예: Kubenet 또는 Calico)을 지원하는 네트워크 플러그인
@@ -64,45 +67,173 @@ IPv6 CIDR의 예: `fdXY:IJKL:MNOP:15::/64` (이 형식으로 표시되지만,
## 서비스
만약 클러스터 IPv4/IPv6 이중 스택 네트워킹을 활성화한 경우, IPv4 또는 IPv6 주소로 {{< glossary_tooltip text="서비스" term_id="service" >}} 를 만들 수 있다. 해당 서비스에서 `.spec.ipFamily` 필드를 설정하면, 서비스 클러스터 IP의 주소 패밀리를 선택할 수 있다.
새 서비스를 생성할 때만 이 필드를 설정할 수 있다. `.spec.ipFamily` 필드는 선택 사항이며 클러스터에서 {{< glossary_tooltip text="서비스" term_id="service" >}} 와 {{< glossary_tooltip text="인그레스" term_id="ingress" >}} 를 IPv4와 IPv6로 사용하도록 설정할 경우에만 사용해야 한다. 이 필드의 구성은 [이그레스](#이그레스-트래픽)에 대한 요구사항이 아니다.
클러스터에 이중 스택이 활성화된 경우 IPv4, IPv6 또는 둘 다를 사용할 수 있는 {{< glossary_tooltip text="서비스" term_id="service" >}}를 만들 수 있다.
서비스의 주소 계열은 기본적으로 첫 번째 서비스 클러스터 IP 범위의 주소 계열로 설정된다. (`--service-cluster-ip-range` 플래그를 통해 kube-controller-manager에 구성)
서비스를 정의할 때 선택적으로 이중 스택으로 구성할 수 있다. 원하는 동작을 지정하려면 `.spec.ipFamilyPolicy` 필드를
다음 값 중 하나로 설정한다.
* `SingleStack`: 단일 스택 서비스. 컨트롤 플레인은 첫 번째로 구성된 서비스 클러스터 IP 범위를 사용하여 서비스에 대한 클러스터 IP를 할당한다.
* `PreferDualStack`:
* 클러스터에 이중 스택이 활성화된 경우에만 사용된다. 서비스에 대해 IPv4 및 IPv6 클러스터 IP를 할당한다.
* 클러스터에 이중 스택이 활성화되지 않은 경우, 이 설정은 `SingleStack`과 동일한 동작을 따른다.
* `RequireDualStack`: IPv4 및 IPv6 주소 범위 모두에서 서비스 `.spec.ClusterIPs`를 할당한다.
* `.spec.ipFamilies` 배열의 첫 번째 요소의 주소 계열을 기반으로 `.spec.ClusterIPs` 목록에서 `.spec.ClusterIP`를 선택한다.
* 클러스터에는 이중 스택 네트워킹이 구성되어 있어야 한다.
단일 스택에 사용할 IP 계열을 정의하거나 이중 스택에 대한 IP 군의 순서를 정의하려는 경우, 서비스에서 옵션 필드 `.spec.ipFamilies`를 설정하여 주소 군을 선택할 수 있다.
{{< note >}}
클러스터의 기본 주소 패밀리는 `--service-cluster-ip-range` 플래그로 kube-controller-manager에 구성된 첫 번째 서비스 클러스터 IP 범위의 주소 패밀리이다.
`.spec.ipFamilies` 필드는 이미 존재하는 서비스에 `.spec.ClusterIP`를 재할당할 수 없기 때문에 변경할 수 없다. `.spec.ipFamilies`를 변경하려면 서비스를 삭제하고 다시 생성한다.
{{< /note >}}
`.spec.ipFamily` 를 다음 중 하나로 설정할 수 있다.
`.spec.ipFamilies`를 다음 배열 값 중 하나로 설정할 수 있다.
* `IPv4`: API 서버는 `ipv4` 인 `service-cluster-ip-range` 의 IP를 할당 한다.
* `IPv6`: API 서버는 `ipv6` 인 `service-cluster-ip-range` 의 IP를 할당 한다.
- `["IPv4"]`
- `["IPv6"]`
- `["IPv4","IPv6"]` (이중 스택)
- `["IPv6","IPv4"]` (이중 스택)
다음 서비스 사양에는 `ipFamily` 필드가 포함되어 있지 않다. 쿠버네티스는 처음 구성된 `service-cluster-ip-range` 의 IP 주소("클러스터 IP" 라고도 함)를 이 서비스에 할당 한다.
나열한 첫 번째 군은 레거시`.spec.ClusterIP` 필드에 사용된다.
### 이중 스택 서비스 구성 시나리오
이 예제는 다양한 이중 스택 서비스 구성 시나리오의 동작을 보여준다.
#### 새로운 서비스에 대한 이중 스택 옵션
1. 이 서비스 사양은 `.spec.ipFamilyPolicy`를 명시적으로 정의하지 않는다. 이 서비스를 만들 때 쿠버네티스는 처음 구성된 `service-cluster-ip-range`에서 서비스에 대한 클러스터 IP를 할당하고 `.spec.ipFamilyPolicy`를 `SingleStack`으로 설정한다. ([셀렉터가 없는 서비스](/ko/docs/concepts/services-networking/service/#셀렉터가-없는-서비스) 및 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)와 같은 방식으로 동작한다.)
{{< codenew file="service/networking/dual-stack-default-svc.yaml" >}}
다음 서비스 명세에는 `ipFamily` 필드가 포함되어 있다. 쿠버네티스는 구성된 `service-cluster-ip-range` 의 IPv6 주소("클러스터 IP" 라고도 함)를 이 서비스에 할당 한다.
1. 이 서비스 사양은 `.spec.ipFamilyPolicy`에 `PreferDualStack`을 명시적으로 정의한다. 이중 스택 클러스터에서 이 서비스를 생성하면 쿠버네티스는 서비스에 대해 IPv4 및 IPv6 주소를 모두 할당한다. 컨트롤 플레인은 서비스의 `.spec`을 업데이트하여 IP 주소 할당을 기록한다. 필드 `.spec.ClusterIPs`는 기본 필드이며 할당된 IP 주소를 모두 포함한다. `.spec.ClusterIP`는 값이 `.spec.ClusterIPs`에서 계산된 보조 필드이다.
{{< codenew file="service/networking/dual-stack-ipv6-svc.yaml" >}}
* `.spec.ClusterIP` 필드의 경우 컨트롤 플레인은 첫 번째 서비스 클러스터 IP 범위와 동일한 주소 계열의 IP 주소를 기록한다.
* 단일 스택 클러스터에서 `.spec.ClusterIPs` 및 `.spec.ClusterIP` 필드는 모두 하나의 주소만 나열한다.
* 이중 스택이 활성화된 클러스터에서 `.spec.ipFamilyPolicy`에 `RequireDualStack`을 지정하면 `PreferDualStack`과 동일하게 작동한다.
비교를 위해, 다음 서비스 명세에는 구성된 `service-cluster-ip-range` 의 IPv4 주소("클러스터 IP" 라고도 함)를 이 서비스에 할당한다.
{{< codenew file="service/networking/dual-stack-preferred-svc.yaml" >}}
{{< codenew file="service/networking/dual-stack-ipv4-svc.yaml" >}}
1. 이 서비스 사양은 `.spec.ipFamilies`에` IPv6`과 `IPv4`를 명시적으로 정의하고 `.spec.ipFamilyPolicy`에 `PreferDualStack`을 정의한다. 쿠버네티스가 `.spec.ClusterIPs`에 IPv6 및 IPv4 주소를 할당할 때 `.spec.ClusterIP`는 `.spec.ClusterIPs` 배열의 첫 번째 요소이므로 IPv6 주소로 설정되어 기본값을 재정의한다.
### 로드밸런서 유형
{{< codenew file="service/networking/dual-stack-preferred-ipfamilies-svc.yaml" >}}
IPv6가 활성화된 외부 로드 밸런서를 지원하는 클라우드 공급자들은 `type` 필드를 `LoadBalancer` 로 설정하고, 추가적으로 `ipFamily` 필드를 `IPv6` 로 설정하면 서비스에 대한 클라우드 로드 밸런서가 구축된다.
#### 기존 서비스의 이중 스택 기본값
## 이그레스 트래픽
이 예제는 서비스가 이미있는 클러스터에서 이중 스택이 새로 활성화된 경우의 기본 동작을 보여준다.
근본적으로 {{< glossary_tooltip text="CNI" term_id="cni" >}} 공급자가 전송을 구현할 수 있는 경우 공개적으로 라우팅 하거나 비공개 라우팅만 가능한 IPv6 주소 블록의 사용은 허용된다. 만약 비공개 라우팅만 가능한 IPv6를 사용하는 파드가 있고, 해당 파드가 오프 클러스터 목적지(예: 공용 인터넷)에 도달하기를 원하는 경우에는 이그레스 트래픽과 모든 응답을 위한 마스커레이딩 IP를 설정해야 한다. [ip-masq-agent](https://github.com/kubernetes-sigs/ip-masq-agent)는 이중 스택을 인식하기에, 이중 스택 클러스터에서 마스커레이딩 IP에 ip-masq-agent를 사용할 수 있다.
1. 클러스터에서 이중 스택이 활성화된 경우 기존 서비스 (`IPv4` 또는 `IPv6`)는 컨트롤 플레인이 `.spec.ipFamilyPolicy`를 `SingleStack`으로 지정하고 `.spec.ipFamilies`를 기존 서비스의 주소 계열로 설정한다. 기존 서비스 클러스터 IP는 `.spec.ClusterIPs`에 저장한다.
## 알려진 이슈들
{{< codenew file="service/networking/dual-stack-default-svc.yaml" >}}
* Kubenet은 IP의 IPv4,IPv6의 위치 보고를 강제로 수행한다. (--cluster-cidr)
kubectl을 사용하여 기존 서비스를 검사하여 이 동작을 검증할 수 있다.
```shell
kubectl get svc my-service -o yaml
```
```yaml
apiVersion: v1
kind: Service
metadata:
labels:
app: MyApp
name: my-service
spec:
clusterIP: 10.0.197.123
clusterIPs:
- 10.0.197.123
ipFamilies:
- IPv4
ipFamilyPolicy: SingleStack
ports:
- port: 80
protocol: TCP
targetPort: 80
selector:
app: MyApp
type: ClusterIP
status:
loadBalancer: {}
```
1. 클러스터에서 이중 스택이 활성화된 경우, 셀렉터가 있는 기존 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)는 `.spec.ClusterIP`가 `None`이라도 컨트롤 플레인이 `.spec.ipFamilyPolicy`을 `SingleStack`으로 지정하고 `.spec.ipFamilies`는 첫 번째 서비스 클러스터 IP 범위(kube-controller-manager에 대한 `--service-cluster-ip-range` 플래그를 통해 구성)의 주소 계열으로 지정한다.
{{< codenew file="service/networking/dual-stack-default-svc.yaml" >}}
kubectl을 사용하여 셀렉터로 기존 헤드리스 서비스를 검사하여 이 동작의 유효성을 검사 할 수 있다.
```shell
kubectl get svc my-service -o yaml
```
```yaml
apiVersion: v1
kind: Service
metadata:
labels:
app: MyApp
name: my-service
spec:
clusterIP: None
clusterIPs:
- None
ipFamilies:
- IPv4
ipFamilyPolicy: SingleStack
ports:
- port: 80
protocol: TCP
targetPort: 80
selector:
app: MyApp
```
#### 단일 스택과 이중 스택 간 서비스 전환
서비스는 단일 스택에서 이중 스택으로, 이중 스택에서 단일 스택으로 변경할 수 있다.
1. 서비스를 단일 스택에서 이중 스택으로 변경하려면 원하는 대로 `.spec.ipFamilyPolicy`를 `SingleStack`에서 `PreferDualStack` 또는 `RequireDualStack`으로 변경한다. 이 서비스를 단일 스택에서 이중 스택으로 변경하면 쿠버네티스는 누락된 주소 계열의 것을 배정하므로 해당 서비스는 이제 IPv4와 IPv6 주소를 갖게된다.
`.spec.ipFamilyPolicy`를 `SingleStack`에서 `PreferDualStack`으로 업데이트하는 서비스 사양을 편집한다.
이전:
```yaml
spec:
ipFamilyPolicy: SingleStack
```
이후:
```yaml
spec:
ipFamilyPolicy: PreferDualStack
```
1. 서비스를 이중 스택에서 단일 스택으로 변경하려면 `.spec.ipFamilyPolicy`를 `PreferDualStack`에서 또는 `RequireDualStack`을 `SingleStack`으로 변경한다. 이 서비스를 이중 스택에서 단일 스택으로 변경하면 쿠버네티스는 `.spec.ClusterIPs` 배열의 첫 번째 요소 만 유지하고 `.spec.ClusterIP`를 해당 IP 주소로 설정하고 `.spec.ipFamilies`를 `.spec.ClusterIPs`의 주소 계열로 설정한다.
### 셀렉터가 없는 헤드리스 서비스
[셀렉터가 없는 서비스](/ko/docs/concepts/services-networking/service/#셀렉터가-없는-서비스) 및 `.spec.ipFamilyPolicy`가 명시적으로 설정되지 않은 경우 `.spec.ipFamilyPolicy` 필드의 기본값은 `RequireDualStack` 이다.
### 로드밸런서 서비스 유형
서비스에 이중 스택 로드밸런서를 프로비저닝하려면
* `.spec.type` 필드를 `LoadBalancer`로 설정
* `.spec.ipFamilyPolicy` 필드를 `PreferDualStack` 또는 `RequireDualStack`으로 설정
{{< note >}}
이중 스택 `LoadBalancer` 유형 서비스를 사용하려면 클라우드 공급자가 IPv4 및 IPv6로드 밸런서를 지원해야 한다.
{{< /note >}}
## 이그레스(Egress) 트래픽
비공개로 라우팅할 수 있는 IPv6 주소를 사용하는 파드에서 클러스터 외부 대상 (예: 공용 인터넷)에 도달하기 위해 이그레스 트래픽을 활성화하려면 투명 프록시 또는 IP 위장과 같은 메커니즘을 통해 공개적으로 라우팅한 IPv6 주소를 사용하도록 파드를 활성화해야 한다. [ip-masq-agent](https://github.com/kubernetes-sigs/ip-masq-agent) 프로젝트는 이중 스택 클러스터에서 IP 위장을 지원한다.
{{< note >}}
{{< glossary_tooltip text="CNI" term_id="cni" >}} 공급자가 IPv6를 지원하는지 확인한다.
{{< /note >}}
## {{% heading "whatsnext" %}}
* [IPv4/IPv6 이중 스택 확인](/ko/docs/tasks/network/validate-dual-stack) 네트워킹
* [IPv4/IPv6 이중 스택 검증](/ko/docs/tasks/network/validate-dual-stack) 네트워킹
content/ko/docs/concepts/services-networking/endpoint-slices.md
+52 -1
View File
@@ -73,7 +73,8 @@ endpoints:
```
기본적으로, 컨트롤 플레인은 각각 100개 이하의 엔드포인트를
갖도록 엔드포인트슬라이스를 생성하고 관리한다. `--max-endpoints-per-slice`
갖도록 엔드포인트슬라이스를
생성하고 관리한다. `--max-endpoints-per-slice`
{{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}}
플래그를 사용하여, 최대 1000개까지 구성할 수 있다.
@@ -90,8 +91,58 @@ endpoints:
* IPv6
* FQDN (전체 주소 도메인 이름)
### 조건
엔드포인트슬라이스 API는 컨슈머에게 유용한 엔드포인트에 대한 조건을 저장한다.
조건은 `준비`, `제공` 및 `종료` 세 가지가 있다.
#### 준비
`ready`는 파드의 `Ready` 조건에 매핑되는 조건이다. `Ready` 조건이 `True`로 설정된 실행 중인 파드는
이 엔드포인트슬라이스 조건도 `true`로 설정되어야 한다. 호환성의
이유로, 파드가 종료될 때 `ready`는 절대 `true`가 되면 안 된다. 컨슈머는 `serving` 조건을 참조하여
파드 종료 준비 상태(readiness)를 검사해야 한다.
이 규칙의 유일한 예외는 `spec.publishNotReadyAddresses`가 `true`로 설정된 서비스이다.
이러한 서비스의 엔드 포인트는 항상 `ready`조건이 `true`로 설정된다.
#### 제공(Serving)
{{< feature-state for_k8s_version="v1.20" state="alpha" >}}
`serving`은 종료 상태를 고려하지 않는다는 점을 제외하면 `ready` 조건과 동일하다.
엔드포인트슬라이스 API 컨슈머는 파드가 종료되는 동안 파드 준비 상태에 관심이 있다면
이 조건을 확인해야 한다.
{{< note >}}
`serving`은 `ready`와 거의 동일하지만 `ready`의 기존 의미가 깨지는 것을 방지하기 위해 추가되었다.
엔드포인트를 종료하기 위해 `ready`가 `true` 일 수 있다면 기존 클라이언트에게는 예상치 못한 일이 될 수 있다.
역사적으로 종료된 엔드포인트는 처음부터 엔드포인트 또는 엔드포인트슬라이스 API에 포함되지 않았기 때문이다.
이러한 이유로 `ready`는 엔드포인트 종료를 위해 _always_ `false`이며,
클라이언트가 `ready`에 대한 기존 의미와 관계없이 파드 종료 준비 상태를
추적 할 수 있도록 v1.20에 새로운 조건 `serving`이 추가되었다.
{{< /note >}}
#### 종료(Terminating)
{{< feature-state for_k8s_version="v1.20" state="alpha" >}}
`종료(Terminating)`는 엔드포인트가 종료되는지 여부를 나타내는 조건이다.
파드의 경우 삭제 타임 스탬프가 설정된 모든 파드이다.
### 토폴로지 정보 {#토폴로지}
{{< feature-state for_k8s_version="v1.20" state="deprecated" >}}
{{< note >}}
엔드포인트슬라이스의 토폴로지 필드는 사용 중단되었으며 향후 릴리스에서 제거된다.
토폴로지에서 `kubernetes.io/hostname`을 설정하는 대신 새로운 `nodeName` 필드가
사용된다. 영역 및 리전을 커버하는 다른 토폴로지 필드는
엔드포인트슬라이스 내의 모든 엔드포인트에 적용되는
엔드포인트슬라이스 레이블을 이용해 더 잘 표현될 수 있다.
{{< /note >}}
엔드포인트슬라이스 내 각 엔드포인트는 연관된 토폴로지 정보를 포함할 수 있다.
이는 해당 노드, 영역 그리고 지역에 대한 정보가 포함된
엔드포인트가 있는 위치를 나타나는데 사용 한다. 값을 사용할 수 있으면,
content/ko/docs/concepts/services-networking/ingress-controllers.md
+28 -27
View File
@@ -13,8 +13,8 @@ kube-controller-manager 바이너리의 일부로 실행되는 컨트롤러의
클러스터와 함께 자동으로 실행되지 않는다.
클러스터에 가장 적합한 인그레스 컨트롤러 구현을 선택하는데 이 페이지를 사용한다.
프로젝트로써 쿠버네티스는 현재 [GCE](https://git.k8s.io/ingress-gce/README.md) 와
[nginx](https://git.k8s.io/ingress-nginx/README.md) 컨트롤러를 지원하고 유지한다.
프로젝트로써 쿠버네티스는 [AWS](https://github.com/kubernetes-sigs/aws-load-balancer-controller#readme), [GCE](https://git.k8s.io/ingress-gce/README.md#readme)와
[nginx](https://git.k8s.io/ingress-nginx/README.md#readme) 인그레스 컨트롤러를 지원하고 유지한다.
@@ -24,31 +24,31 @@ kube-controller-manager 바이너리의 일부로 실행되는 컨트롤러의
{{% thirdparty-content %}}
* [AKS Application Gateway Ingress Controller](https://github.com/Azure/application-gateway-kubernetes-ingress) is an ingress controller that enables ingress to [AKS clusters](https://docs.microsoft.com/azure/aks/kubernetes-walkthrough-portal) using the [Azure Application Gateway](https://docs.microsoft.com/azure/application-gateway/overview).
* [Ambassador](https://www.getambassador.io/) API 게이트웨이는 [Datawire](https://www.datawire.io/)의
[커뮤니티](https://www.getambassador.io/docs) 혹은 [상업적](https://www.getambassador.io/pro/) 지원을 제공하는
[Envoy](https://www.envoyproxy.io) 기반 인그레스 컨트롤러다.
* [AppsCode Inc.](https://appscode.com) 는 가장 널리 사용되는 [HAProxy](https://www.haproxy.org/) 기반 인그레스 컨트롤러인 [Voyager](https://appscode.com/products/voyager)에 대한 지원 및 유지 보수를 제공한다.
* [AWS 로드 밸런서 컨트롤러](https://github.com/kubernetes-sigs/aws-load-balancer-controller)(이전의 AWS ALB 인그레스 컨트롤러)는 [AWS Elastic Load Balancing](https://aws.amazon.com/elasticloadbalancing/)을 사용하여 인그레스를 활성화한다.
* [Contour](https://projectcontour.io/)는 [Envoy](https://www.envoyproxy.io/) 기반 인그레스 컨트롤러로
VMware에서 제공하고 지원한다.
* Citrix는 [베어메탈](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment/baremetal)과 [클라우드](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment) 배포를 위해 하드웨어 (MPX), 가상화 (VPX) 및 [무료 컨테이너화 (CPX) ADC](https://www.citrix.com/products/citrix-adc/cpx-express.html)를 위한 [인그레스 컨트롤러](https://github.com/citrix/citrix-k8s-ingress-controller)를 제공한다.
* F5 Networks는 [쿠버네티스를 위한 F5 BIG-IP 컨테이너 인그레스 서비스](http://clouddocs.f5.com/products/connectors/k8s-bigip-ctlr/latest)에 대한
[지원과 유지 보수](https://support.f5.com/csp/article/K86859508)를 제공한다.
* [Gloo](https://gloo.solo.io)는 [solo.io](https://www.solo.io)의 엔터프라이즈 지원과 함께 API 게이트웨이 기능을 제공하는 [Envoy](https://www.envoyproxy.io) 기반의 오픈 소스 인그레스 컨트롤러다.
* [HAProxy 인그레스](https://haproxy-ingress.github.io)는 HAProxy를 위한 고도로 커스터마이징 가능한 커뮤니티 주도형 인그레스 컨트롤러다.
* [HAProxy Technologies](https://www.haproxy.com/)는 [쿠버네티스를 위한 HAProxy 인그레스 컨트롤러](https://github.com/haproxytech/kubernetes-ingress)를 지원하고 유지 보수한다. [공식 문서](https://www.haproxy.com/documentation/hapee/1-9r1/traffic-management/kubernetes-ingress-controller/)를 통해 확인할 수 있다.
* [Istio](https://istio.io/)는 인그레스 컨트롤러 기반으로
[인그레스 트래픽을 제어](https://istio.io/docs/tasks/traffic-management/ingress/).
* [Kong](https://konghq.com/)은 [쿠버네티스를 위한 Kong 인그레스 컨트롤러](https://github.com/Kong/kubernetes-ingress-controller)에 대한
[커뮤니티](https://discuss.konghq.com/c/kubernetes) 또는
[상업적](https://konghq.com/kong-enterprise/) 지원과 유지 보수를 제공한다.
* [NGINX, Inc.](https://www.nginx.com/)는
[쿠버네티스를 위한 NGINX 인그레스 컨트롤러](https://www.nginx.com/products/nginx/kubernetes-ingress-controller)에 대한 지원과 유지 보수를 제공한다.
* [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/)는 쿠버네티스 인그레스와 같은 유스케이스를 포함하는 서비스 구성을 위한 HTTP 라우터와 리버스 프록시는 사용자 정의 프록시를 빌드하기 위한 라이브러리로 설계되었다.
* [Traefik](https://github.com/traefik/traefik)은
모든 기능([Let's Encrypt](https://letsencrypt.org), secrets, http2, 웹 소켓)을 갖춘 인그레스 컨트롤러로,
[Traefik Labs](https://traefik.io)에서 상업적인 지원을 제공한다.
* [AKS 애플리케이션 게이트웨이 인그레스 컨트롤러] (https://azure.github.io/application-gateway-kubernetes-ingress/)는 [Azure 애플리케이션 게이트웨이](https://docs.microsoft.com)를 구성하는 인그레스 컨트롤러다.
* [Ambassador](https://www.getambassador.io/) API 게이트웨이는 [Envoy](https://www.envoyproxy.io) 기반 인그레스
컨트롤러다.
* [Citrix 인그레스 컨트롤러](https://github.com/citrix/citrix-k8s-ingress-controller#readme)는
Citrix 애플리케이션 딜리버리 컨트롤러에서 작동한다.
* [Contour](https://projectcontour.io/)는 [Envoy](https://www.envoyproxy.io/) 기반 인그레스 컨트롤러다.
* F5 BIG-IP [쿠버네티스 용 컨테이너 인그레스 서비스](https://clouddocs.f5.com/containers/latest/userguide/kubernetes/)를
이용하면 인그레스를 사용하여 F5 BIG-IP 가상 서버를 구성할 수 있다.
* [Gloo](https://gloo.solo.io)는 API 게이트웨이 기능을 제공하는 [Envoy](https://www.envoyproxy.io) 기반의
오픈소스 인그레스 컨트롤러다.
* [HAProxy 인그레스](https://haproxy-ingress.github.io/)는 [HAProxy](http://www.haproxy.org/#desc)의
인그레스 컨트롤러다.
* [쿠버네티스 용 HAProxy 인그레스 컨트롤러](https://github.com/haproxytech/kubernetes-ingress#readme)는 [HAProxy](http://www.haproxy.org/#desc) 용
인그레스 컨트롤러이기도 하다.
* [Istio 인그레스](https://istio.io/latest/docs/tasks/traffic-management/ingress/kubernetes-ingress/)는 [Istio](https://istio.io/)
기반 인그레스 컨트롤러다.
* [쿠버네티스 용 Kong 인그레스 컨트롤러](https://github.com/Kong/kubernetes-ingress-controller#readme)는 [Kong 게이트웨이](https://konghq.com/kong/)를
구동하는 인그레스 컨트롤러다.
* [쿠버네티스 용 NGINX 인그레스 컨트롤러](https://www.nginx.com/products/nginx/kubernetes-ingress-controller)는 [NGINX](https://www.nginx.com/resources/glossary)
웹서버(프록시로 사용)와 함께 작동한다.
* [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/)는 사용자의 커스텀 프록시를 구축하기 위한 라이브러리로 설계된 쿠버네티스 인그레스와 같은 유스케이스를 포함한 서비스 구성을 위한 HTTP 라우터 및 역방향 프록시다.
* [Traefik 쿠버네티스 인그레스 제공자](https://doc.traefik.io/traefik/providers/kubernetes-ingress/)는
[Traefik](https://traefik.io/traefik/) 프록시 용 인그레스 컨트롤러다.
* [Voyager](https://appscode.com/products/voyager)는
[HAProxy](http://www.haproxy.org/#desc)의 인그레스 컨트롤러다.
## 여러 인그레스 컨트롤러 사용
@@ -73,3 +73,4 @@ kube-controller-manager 바이너리의 일부로 실행되는 컨트롤러의
* [인그레스](/ko/docs/concepts/services-networking/ingress/)에 대해 자세히 알아보기.
* [NGINX 컨트롤러로 Minikube에서 인그레스를 설정하기](/docs/tasks/access-application-cluster/ingress-minikube).
content/ko/docs/concepts/services-networking/service.md
+67 -49
View File
@@ -201,10 +201,15 @@ API 리소스이다. 개념적으로 엔드포인트와 매우 유사하지만,
### 애플리케이션 프로토콜
{{< feature-state for_k8s_version="v1.19" state="beta" >}}
{{< feature-state for_k8s_version="v1.20" state="stable" >}}
`AppProtocol` 필드는 각 서비스 포트에 대한 애플리케이션 프로토콜을 지정하는 방법을 제공한다.
이 필드의 값은 해당 엔드포인트와 엔드포인트슬라이스 리소스에 의해 미러링된다.
`appProtocol` 필드는 각 서비스 포트에 대한 애플리케이션 프로토콜을 지정하는 방법을 제공한다.
이 필드의 값은 해당 엔드포인트와 엔드포인트슬라이스
오브젝트에 의해 미러링된다.
이 필드는 표준 쿠버네티스 레이블 구문을 따른다. 값은
[IANA 표준 서비스 이름](http://www.iana.org/assignments/service-names) 또는
`mycompany.com/my-custom-protocol`과 같은 도메인 접두사 이름 중 하나여야 한다.
## 가상 IP와 서비스 프록시
@@ -576,21 +581,12 @@ status:
외부 로드 밸런서의 트래픽은 백엔드 파드로 전달된다. 클라우드 공급자는 로드 밸런싱 방식을 결정한다.
로드 밸런서 서비스 유형의 경우 두 개 이상의 포트가 정의된 경우,
모든 포트의 프로토콜이 동일해야 하고, 프로토콜은 `TCP`, `UDP` 그리고
`SCTP` 중 하나여야 한다.
일부 클라우드 공급자는 `loadBalancerIP`를 지정할 수 있도록 허용한다. 이 경우, 로드 밸런서는
사용자 지정 `loadBalancerIP`로 생성된다. `loadBalancerIP` 필드가 지정되지 않으면,
임시 IP 주소로 loadBalancer가 설정된다. `loadBalancerIP`를 지정했지만
클라우드 공급자가 이 기능을 지원하지 않는 경우, 설정한 `loadbalancerIP` 필드는
무시된다.
{{< note >}}
SCTP를 사용하는 경우, `LoadBalancer` 서비스 유형에 대한 아래의 [경고](#caveat-sctp-loadbalancer-service-type)를
참고한다.
{{< /note >}}
{{< note >}}
**Azure** 에서 사용자 지정 공개(public) 유형 `loadBalancerIP`를 사용하려면, 먼저
@@ -602,7 +598,35 @@ SCTP를 사용하는 경우, `LoadBalancer` 서비스 유형에 대한 아래의
{{< /note >}}
#### 내부 로드 밸런서 {#internal-load-balancer}
#### 프로토콜 유형이 혼합된 로드밸런서
{{< feature-state for_k8s_version="v1.20" state="alpha" >}}
기본적으로 로드밸런서 서비스 유형의 경우 둘 이상의 포트가 정의되어 있을 때 모든
포트는 동일한 프로토콜을 가져야 하며 프로토콜은 클라우드 공급자가
지원하는 프로토콜이어야 한다.
kube-apiserver에 대해 기능 게이트 `MixedProtocolLBService`가 활성화된 경우 둘 이상의 포트가 정의되어 있을 때 다른 프로토콜을 사용할 수 있다.
{{< note >}}
로드밸런서 서비스 유형에 사용할 수 있는 프로토콜 세트는 여전히 클라우드 제공 업체에서 정의한다.
{{< /note >}}
#### 로드밸런서 NodePort 할당 비활성화
{{< feature-state for_k8s_version="v1.20" state="alpha" >}}
v1.20부터는 `spec.allocateLoadBalancerNodePorts`필드를 `false`로 설정하여 서비스 Type=LoadBalancer에
대한 노드 포트 할당을 선택적으로 비활성화 할 수 있다.
노드 포트를 사용하는 대신 트래픽을 파드로 직접 라우팅하는 로드 밸런서 구현에만 사용해야 한다.
기본적으로 `spec.allocateLoadBalancerNodePorts`는 `true`이며 로드밸런서 서비스 유형은 계속해서 노드 포트를 할당한다.
노드 포트가 할당된 기존 서비스에서 `spec.allocateLoadBalancerNodePorts`가 `false`로 설정된 경우 해당 노드 포트는 자동으로 할당 해제되지 않는다.
이러한 노드 포트를 할당 해제하려면 모든 서비스 포트에서 `nodePorts` 항목을 명시적으로 제거해야 한다.
이 필드를 사용하려면 `ServiceLBNodePortControl` 기능 게이트를 활성화해야 한다.
#### 내부 로드 밸런서
혼재된 환경에서는 서비스의 트래픽을 동일한 (가상) 네트워크 주소 블록 내로
라우팅해야 하는 경우가 있다.
@@ -1182,6 +1206,36 @@ IPVS는 로드 밸런싱을 위해 설계되었고 커널-내부 해시 테이
대부분의 서비스에 UDP를 사용할 수 있다. type=LoadBalancer 서비스의 경우, UDP 지원은
이 기능을 제공하는 클라우드 공급자에 따라 다르다.
### SCTP
{{< feature-state for_k8s_version="v1.20" state="stable" >}}
SCTP 트래픽을 지원하는 네트워크 플러그인을 사용하는 경우 대부분의 서비스에 SCTP를 사용할 수 있다.
type=LoadBalancer 서비스의 경우 SCTP 지원은 이 기능을 제공하는
클라우드 공급자에 따라 다르다. (대부분 그렇지 않음)
#### 경고 {#caveat-sctp-overview}
##### 멀티홈드(multihomed) SCTP 연결을 위한 지원 {#caveat-sctp-multihomed}
{{< warning >}}
멀티홈 SCTP 연결을 위해서는 먼저 CNI 플러그인이 파드에 대해 멀티 인터페이스 및 IP 주소 할당이 지원되어야 한다.
멀티홈 SCTP 연결을 위한 NAT는 해당 커널 모듈 내에 특수한 로직을 필요로 한다.
{{< /warning >}}
##### 윈도우 {#caveat-sctp-windows-os}
{{< warning >}}
SCTP는 윈도우 기반 노드를 지원하지 않는다.
{{< /warning >}}
##### 유저스페이스 kube-proxy {#caveat-sctp-kube-proxy-userspace}
{{< warning >}}
kube-proxy는 유저스페이스 모드에 있을 때 SCTP 연결 관리를 지원하지 않는다.
{{< /warning >}}
### HTTP
클라우드 공급자가 이를 지원하는 경우, LoadBalancer 모드의
@@ -1209,42 +1263,6 @@ PROXY TCP4 192.0.2.202 10.0.42.7 12345 7\r\n
클라이언트 데이터가 뒤따라온다.
### SCTP
{{< feature-state for_k8s_version="v1.19" state="beta" >}}
쿠버네티스는 서비스, 엔드포인트, 엔드포인트슬라이스, 네트워크폴리시 및 파드 정의에서 SCTP를 `protocol` 값으로 지원한다. 이 기능은 베타 기능으로, 기본 활성화되어 있다. 클러스터 수준에서 SCTP를 비활성화하려면, 사용자(또는 클러스터 관리자)가 API 서버에서 `--feature-gates=SCTPSupport=false,…` 를 사용해서 `SCTPSupport` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 비활성화해야 한다.
기능 게이트가 활성화되면, 서비스, 엔드포인트, 엔드포인트슬라이스, 네트워크폴리시 또는 파드의 `protocol` 필드를 `SCTP` 로 설정할 수 있다. 쿠버네티스는 TCP 연결과 마찬가지로, SCTP 연결에 맞게 네트워크를 설정한다.
#### 경고 {#caveat-sctp-overview}
##### 멀티홈드(multihomed) SCTP 연결을 위한 지원 {#caveat-sctp-multihomed}
{{< warning >}}
멀티홈 SCTP 연결을 위해서는 먼저 CNI 플러그인이 파드에 대해 멀티 인터페이스 및 IP 주소 할당이 지원되어야 한다.
멀티홈 SCTP 연결을 위한 NAT는 해당 커널 모듈 내에 특수한 로직을 필요로 한다.
{{< /warning >}}
##### type=LoadBalancer 서비스 {#caveat-sctp-loadbalancer-service-type}
{{< warning >}}
클라우드 공급자의 로드 밸런서 구현이 프로토콜로서 SCTP를 지원하는 경우에만 LoadBalancer `유형`과 SCTP `프로토콜`을 사용하여 서비스를 생성할 수 있다. 그렇지 않으면, 서비스 생성 요청이 거부된다. 현재 클라우드 로드 밸런서 공급자 세트 (Azure, AWS, CloudStack, GCE, OpenStack)는 모두 SCTP에 대한 지원이 없다.
{{< /warning >}}
##### 윈도우 {#caveat-sctp-windows-os}
{{< warning >}}
SCTP는 윈도우 기반 노드를 지원하지 않는다.
{{< /warning >}}
##### 유저스페이스 kube-proxy {#caveat-sctp-kube-proxy-userspace}
{{< warning >}}
kube-proxy는 유저스페이스 모드에 있을 때 SCTP 연결 관리를 지원하지 않는다.
{{< /warning >}}
## {{% heading "whatsnext" %}}
* [서비스와 애플리케이션 연결](/ko/docs/concepts/services-networking/connect-applications-service/) 알아보기
content/ko/docs/concepts/storage/persistent-volumes.md
+32 -25
View File
@@ -304,26 +304,35 @@ EBS 볼륨 확장은 시간이 많이 걸리는 작업이다. 또한 6시간마
퍼시스턴트볼륨 유형은 플러그인으로 구현된다. 쿠버네티스는 현재 다음의 플러그인을 지원한다.
* GCEPersistentDisk
* AWSElasticBlockStore
* AzureFile
* AzureDisk
* CSI
* FC (파이버 채널)
* FlexVolume
* Flocker
* NFS
* iSCSI
* RBD (Ceph Block Device)
* CephFS
* Cinder (OpenStack 블록 스토리지)
* Glusterfs
* VsphereVolume
* Quobyte Volumes
* HostPath (단일 노드 테스트 전용 – 로컬 스토리지는 어떤 방식으로도 지원되지 않으며 다중-노드 클러스터에서 작동하지 않음)
* Portworx Volumes
* ScaleIO Volumes
* StorageOS
* [`awsElasticBlockStore`](/ko/docs/concepts/storage/volumes/#awselasticblockstore) - AWS Elastic Block Store (EBS)
* [`azureDisk`](/ko/docs/concepts/storage/volumes/#azuredisk) - Azure Disk
* [`azureFile`](/ko/docs/concepts/storage/volumes/#azurefile) - Azure File
* [`cephfs`](/ko/docs/concepts/storage/volumes/#cephfs) - CephFS 볼륨
* [`cinder`](/ko/docs/concepts/storage/volumes/#cinder) - Cinder (오픈스택 블록 스토리지)
(**사용 중단**)
* [`csi`](/ko/docs/concepts/storage/volumes/#csi) - 컨테이너 스토리지 인터페이스 (CSI)
* [`fc`](/ko/docs/concepts/storage/volumes/#fc) - Fibre Channel (FC) 스토리지
* [`flexVolume`](/ko/docs/concepts/storage/volumes/#flexVolume) - FlexVolume
* [`flocker`](/ko/docs/concepts/storage/volumes/#flocker) - Flocker 스토리지
* [`gcePersistentDisk`](/ko/docs/concepts/storage/volumes/#gcepersistentdisk) - GCE Persistent Disk
* [`glusterfs`](/ko/docs/concepts/storage/volumes/#glusterfs) - Glusterfs 볼륨
* [`hostPath`](/ko/docs/concepts/storage/volumes/#hostpath) - HostPath 볼륨
(단일 노드 테스트 전용. 다중-노드 클러스터에서 작동하지 않음.
대신 `로컬` 볼륨 사용 고려)
* [`iscsi`](/ko/docs/concepts/storage/volumes/#iscsi) - iSCSI (SCSI over IP) 스토리지
* [`local`](/ko/docs/concepts/storage/volumes/#local) - 노드에 마운트된
로컬 스토리지 디바이스
* [`nfs`](/ko/docs/concepts/storage/volumes/#nfs) - 네트워크 파일 시스템 (NFS) 스토리지
* `photonPersistentDisk` - Photon 컨트롤러 퍼시스턴트 디스크.
(이 볼륨 유형은 해당 클라우드 공급자가 없어진 이후 더 이상
작동하지 않는다.)
* [`portworxVolume`](/ko/docs/concepts/storage/volumes/#portworxvolume) - Portworx 볼륨
* [`quobyte`](/ko/docs/concepts/storage/volumes/#quobyte) - Quobyte 볼륨
* [`rbd`](/ko/docs/concepts/storage/volumes/#rbd) - Rados Block Device (RBD) 볼륨
* [`scaleIO`](/ko/docs/concepts/storage/volumes/#scaleio) - ScaleIO 볼륨
(**사용 중단**)
* [`storageos`](/ko/docs/concepts/storage/volumes/#storageos) - StorageOS 볼륨
* [`vsphereVolume`](/ko/docs/concepts/storage/volumes/#vspherevolume) - vSphere VMDK 볼륨
## 퍼시스턴트 볼륨
@@ -717,12 +726,10 @@ spec:
## 볼륨 스냅샷 및 스냅샷 지원에서 볼륨 복원
{{< feature-state for_k8s_version="v1.17" state="beta" >}}
{{< feature-state for_k8s_version="v1.20" state="stable" >}}
CSI 볼륨 플러그인만 지원하도록 볼륨 스냅샷 기능이 추가되었다. 자세한 내용은 [볼륨 스냅샷](/ko/docs/concepts/storage/volume-snapshots/)을 참고한다.
볼륨 스냅샷 데이터 소스에서 볼륨 복원을 지원하려면 apiserver와 controller-manager에서
`VolumeSnapshotDataSource` 기능 게이트를 활성화한다.
볼륨 스냅 샷은 아웃-오브-트리 CSI 볼륨 플러그인만 지원한다. 자세한 내용은 [볼륨 스냅샷](/ko/docs/concepts/storage/volume-snapshots/)을 참조한다.
인-트리 볼륨 플러그인은 사용 중단 되었다. [볼륨 플러그인 FAQ](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md)에서 사용 중단된 볼륨 플러그인에 대해 확인할 수 있다.
### 볼륨 스냅샷에서 퍼시스턴트볼륨클레임 생성 {#create-persistent-volume-claim-from-volume-snapshot}
content/ko/docs/concepts/storage/volume-snapshot-classes.md
+2 -2
View File
@@ -33,7 +33,7 @@ weight: 30
생성된 이후에는 업데이트할 수 없다.
```yaml
apiVersion: snapshot.storage.k8s.io/v1beta1
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
name: csi-hostpath-snapclass
@@ -47,7 +47,7 @@ parameters:
기본 볼륨스냅샷클래스를 지정할 수 있다.
```yaml
apiVersion: snapshot.storage.k8s.io/v1beta1
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
name: csi-hostpath-snapclass
content/ko/docs/concepts/storage/volume-snapshots.md
+5 -5
View File
@@ -6,7 +6,6 @@ weight: 20
<!-- overview -->
{{< feature-state for_k8s_version="v1.17" state="beta" >}}
쿠버네티스에서 스토리지 시스템 볼륨 스냅샷은 _VolumeSnapshot_ 을 나타낸다. 이 문서는 이미 쿠버네티스 [퍼시스턴트 볼륨](/ko/docs/concepts/storage/persistent-volumes/)에 대해 잘 알고 있다고 가정한다.
@@ -30,7 +29,8 @@ API 리소스 `PersistentVolume` 및 `PersistentVolumeClaim` 가 사용자 및
* API 오브젝트인 `VolumeSnapshot`, `VolumeSnapshotContent`, `VolumeSnapshotClass` 는 핵심 API가 아닌, {{< glossary_tooltip term_id="CustomResourceDefinition" text="CRDs" >}}이다.
* `VolumeSnapshot` 은 CSI 드라이버에서만 사용할 수 있다.
* 쿠버네티스 팀은 `VolumeSnapshot` 베타 버젼의 배포 프로세스 일부로써, 컨트롤 플레인에 배포할 스냅샷 컨트롤러와 CSI 드라이버와 함께 배포할 csi-snapshotter라는 사이드카 헬퍼(helper) 컨테이너를 제공한다. 스냅샷 컨트롤러는 `VolumeSnapshot` 및 `VolumeSnapshotContent` 오브젝트를 관찰하고 동적 프로비저닝에서 `VolumeSnapshotContent` 오브젝트의 생성 및 삭제를 할 수 있다.사이드카 csi-snapshotter는 `VolumeSnapshotContent` 오브젝트를 관찰하고 CSI 엔드포인트에 대해 `CreateSnapshot` 및 `DeleteSnapshot` 을 트리거(trigger)한다.
* 쿠버네티스 팀은 `VolumeSnapshot` 의 배포 프로세스 일부로써, 컨트롤 플레인에 배포할 스냅샷 컨트롤러와 CSI 드라이버와 함께 배포할 csi-snapshotter라는 사이드카 헬퍼(helper) 컨테이너를 제공한다. 스냅샷 컨트롤러는 `VolumeSnapshot` 및 `VolumeSnapshotContent` 오브젝트를 관찰하고 동적 프로비저닝에서 `VolumeSnapshotContent` 오브젝트의 생성 및 삭제를 할 수 있다.사이드카 csi-snapshotter는 `VolumeSnapshotContent` 오브젝트를 관찰하고 CSI 엔드포인트에 대해 `CreateSnapshot` 및 `DeleteSnapshot` 을 트리거(trigger)한다.
* 스냅샷 오브젝트에 대한 강화된 검증을 제공하는 검증 웹훅 서버도 있다. 이는 CSI 드라이버가 아닌 스냅샷 컨트롤러 및 CRD와 함께 쿠버네티스 배포판에 의해 설치되어야 한다. 스냅샷 기능이 활성화된 모든 쿠버네티스 클러스터에 설치해야 한다.
* CSI 드라이버에서의 볼륨 스냅샷 기능 유무는 확실하지 않다. 볼륨 스냅샷 서포트를 제공하는 CSI 드라이버는 csi-snapshotter를 사용할 가능성이 높다. 자세한 사항은 [CSI 드라이버 문서](https://kubernetes-csi.github.io/docs/)를 확인하면 된다.
* CRDs 및 스냅샷 컨트롤러는 쿠버네티스 배포 시 설치된다.
@@ -71,7 +71,7 @@ API 오브젝트가 시스템에서 지워지지 않게 하는 것이다(데이
각각의 볼륨 스냅샷은 스펙과 상태를 포함한다.
```yaml
apiVersion: snapshot.storage.k8s.io/v1beta1
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
name: new-snapshot-test
@@ -90,7 +90,7 @@ spec:
사전 프로비저닝된 스냅샷의 경우, 다음 예와 같이 `volumeSnapshotContentName`을 스냅샷 소스로 지정해야 한다. 사전 프로비저닝된 스냅샷에는 `volumeSnapshotContentName` 소스 필드가 필요하다.
```yaml
apiVersion: snapshot.storage.k8s.io/v1beta1
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
name: test-snapshot
@@ -125,7 +125,7 @@ spec:
사전 프로비저닝된 스냅샷의 경우, (클러스터 관리자로서) 다음과 같이 `VolumeSnapshotContent` 오브젝트를 작성해야 한다.
```yaml
apiVersion: snapshot.storage.k8s.io/v1beta1
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotContent
metadata:
name: new-snapshot-content-test
content/ko/docs/concepts/storage/volumes.md
+6
View File
@@ -296,6 +296,12 @@ tmpfs는 매우 빠르지만, 디스크와 다르게 노드 재부팅시 tmpfs
작성하는 모든 파일이 컨테이너 메모리
제한에 포함된다.
{{< note >}}
`SizeMemoryBackedVolumes` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화된 경우,
메모리 기반 볼륨의 크기를 지정할 수 있다. 크기를 지정하지 않으면, 메모리
기반 볼륨의 크기는 리눅스 호스트 메모리의 50%로 조정된다.
{{< /note >}}
#### emptyDir 구성 예시
```yaml
content/ko/docs/concepts/workloads/controllers/cron-jobs.md
+8 -2
View File
@@ -28,8 +28,6 @@ kube-controller-manager 컨테이너에 설정된 시간대는
11자를 자동으로 추가하고, 작업 이름의 최대 길이는
63자라는 제약 조건이 있기 때문이다.
<!-- body -->
## 크론잡
@@ -78,6 +76,14 @@ Cannot determine if job needs to be started. Too many missed start time (> 100).
크론잡은 오직 그 일정에 맞는 잡 생성에 책임이 있고,
잡은 그 잡이 대표하는 파드 관리에 책임이 있다.
## 새 컨트롤러
쿠버네티스 1.20부터 알파 기능으로 사용할 수 있는 크론잡 컨트롤러의 대체 구현이 있다. 크론잡 컨트롤러의 버전 2를 선택하려면, 다음의 [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/) 플래그를 {{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}}에 전달한다.
```
--feature-gates="CronJobControllerV2=true"
```
## {{% heading "whatsnext" %}}
content/ko/docs/concepts/workloads/controllers/daemonset.md
-6
View File
@@ -81,12 +81,6 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
만약 `.spec.selector` 를 명시하면, 이것은 `.spec.template.metadata.labels` 와 일치해야 한다. 일치하지 않는 구성은 API에 의해 거부된다.
또한 일반적으로 다른 데몬셋이나 레플리카셋과 같은 다른 컨트롤러를 통해 직접적으로
레이블이 셀렉터와 일치하는 다른 파드를 생성하지 않아야 한다. 그렇지 않으면 데몬셋
{{< glossary_tooltip term_id="controller" text="컨트롤러" >}}는 해당 파드가 생성된 것으로 생각한다. 쿠버네티스는 이런 일을 하는 것을
막지 못한다. 사용자가 이와 같은 일을 하게 되는 한 가지 경우는 테스트를 목적으로 한 노드에서 다른 값을 가지는 파드들을
수동으로 생성하는 것이다.
### 오직 일부 노드에서만 파드 실행
만약 `.spec.template.spec.nodeSelector` 를 명시하면 데몬셋 컨트롤러는
content/ko/docs/concepts/workloads/controllers/deployment.md
+4 -4
View File
@@ -95,7 +95,7 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml
`.spec.replicas` 필드에 따라 의도한 레플리카의 수가 3개인지 알 수 있다.
3. 디플로이먼트의 롤아웃 상태를 보려면, `kubectl rollout status deployment.v1.apps/nginx-deployment` 를 실행한다.
3. 디플로이먼트의 롤아웃 상태를 보려면, `kubectl rollout status deployment/nginx-deployment` 를 실행한다.
다음과 유사하게 출력된다.
```
@@ -194,7 +194,7 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml
2. 롤아웃 상태를 보려면 다음을 실행한다.
```shell
kubectl rollout status deployment.v1.apps/nginx-deployment
kubectl rollout status deployment/nginx-deployment
```
이와 유사하게 출력된다.
@@ -373,7 +373,7 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성
```shell
kubectl rollout status deployment.v1.apps/nginx-deployment
kubectl rollout status deployment/nginx-deployment
```
이와 유사하게 출력된다.
@@ -850,7 +850,7 @@ nginx-deployment-618515232 11 11 11 7m
만약 롤아웃이 성공적으로 완료되면 `kubectl rollout status` 는 종료 코드로 0이 반환된다.
```shell
kubectl rollout status deployment.v1.apps/nginx-deployment
kubectl rollout status deployment/nginx-deployment
```
이와 유사하게 출력된다.
```
content/ko/docs/concepts/workloads/controllers/garbage-collection.md
+16 -5
View File
@@ -59,11 +59,22 @@ metadata:
```
{{< note >}}
교차 네임스페이스(cross-namespace)의 소유자 참조는 디자인상 허용되지 않는다. 이는 다음을 의미한다.
1) 네임스페이스 범위의 종속 항목은 동일한 네임스페이스의 소유자와
클러스터 범위의 소유자만 지정할 수 있다.
2) 클러스터 범위의 종속 항목은 클러스터 범위의 소유자만 지정할 수 있으며,
네임스페이스 범위의 소유자는 불가하다.
교차 네임스페이스(cross-namespace)의 소유자 참조는 디자인상 허용되지 않는다.
네임스페이스 종속 항목은 클러스터 범위 또는 네임스페이스 소유자를 지정할 수 있다.
네임스페이스 소유자는 **반드시** 종속 항목과 동일한 네임스페이스에 있어야 한다.
그렇지 않은 경우, 소유자 참조는 없는 것으로 처리되며, 소유자가 없는 것으로 확인되면
종속 항목이 삭제될 수 있다.
클러스터 범위의 종속 항목은 클러스터 범위의 소유자만 지정할 수 있다.
v1.20 이상에서 클러스터 범위의 종속 항목이 네임스페이스 종류를 소유자로 지정하면,
확인할 수 없는 소유자 참조가 있는 것으로 처리되고 가비지 수집이 될 수 없다.
v1.20 이상에서 가비지 수집기가 잘못된 교차 네임스페이스 `ownerReference`
또는 네임스페이스 종류를 참조하는 `ownerReference` 가 있는 클러스터 범위의 종속 항목을 감지하면,
`OwnerRefInvalidNamespace` 의 원인이 있는 경고 이벤트와 유효하지 않은 종속 항목의 `involvedObject` 가 보고된다.
`kubectl get events -A --field-selector=reason=OwnerRefInvalidNamespace` 를 실행하여
이러한 종류의 이벤트를 확인할 수 있다.
{{< /note >}}
## 가비지 수집기의 종속 항목 삭제 방식 제어
content/ko/docs/concepts/workloads/pods/_index.md
-1
View File
@@ -255,7 +255,6 @@ kubelet은 자동으로 각 정적 파드에 대한 쿠버네티스 API 서버
## {{% heading "whatsnext" %}}
* [파드의 라이프사이클](/ko/docs/concepts/workloads/pods/pod-lifecycle/)에 대해 알아본다.
* [PodPresets](/ko/docs/concepts/workloads/pods/podpreset/)에 대해 알아본다.
* [런타임클래스(RuntimeClass)](/ko/docs/concepts/containers/runtime-class/)와 이를 사용하여
다양한 컨테이너 런타임 구성으로 다양한 파드를 설정하는 방법에 대해 알아본다.
* [파드 토폴로지 분배 제약 조건](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/)에 대해 읽어본다.
content/ko/docs/concepts/workloads/pods/ephemeral-containers.md
+1 -1
View File
@@ -87,7 +87,7 @@ API에서 특별한 `ephemeralcontainers` 핸들러를 사용해서 만들어지
{{< /note >}}
이 섹션의 예시는 임시 컨테이너가 어떻게 API에 나타나는지
보여준다. 일반적으로 `kubectl alpha debug` 또는
보여준다. 일반적으로 `kubectl debug` 또는
다른 `kubectl` [플러그인](/ko/docs/tasks/extend-kubectl/kubectl-plugins/)을
사용해서 API를 직접 호출하지 않고 이런 단계들을 자동화 한다.
content/ko/docs/concepts/workloads/pods/pod-lifecycle.md
+1 -1
View File
@@ -316,7 +316,7 @@ kubelet은 실행 중인 컨테이너들에 대해서 선택적으로 세 가지
### 언제 스타트업 프로브를 사용해야 하는가?
{{< feature-state for_k8s_version="v1.18" state="beta" >}}
{{< feature-state for_k8s_version="v1.20" state="stable" >}}
스타트업 프로브는 서비스를 시작하는 데 오랜 시간이 걸리는 컨테이너가 있는
파드에 유용하다. 긴 활성 간격을 설정하는 대신, 컨테이너가 시작될 때
content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
+19 -2
View File
@@ -310,6 +310,7 @@ profiles:
- maxSkew: 1
topologyKey: topology.kubernetes.io/zone
whenUnsatisfiable: ScheduleAnyway
defaultingType: List
```
{{< note >}}
@@ -322,9 +323,9 @@ profiles:
#### 내부 기본 제약
{{< feature-state for_k8s_version="v1.19" state="alpha" >}}
{{< feature-state for_k8s_version="v1.20" state="beta" >}}
`DefaultPodTopologySpread` 기능 게이트를 활성화하면, 기존
기본적으로 활성화된 `DefaultPodTopologySpread` 기능 게이트를 사용하면, 기존
`SelectorSpread` 플러그인이 비활성화된다.
kube-scheduler는 `PodTopologySpread` 플러그인 구성에 다음과 같은
기본 토폴로지 제약 조건을 사용한다.
@@ -351,6 +352,22 @@ defaultConstraints:
없는 노드에 점수를 매기지 않는다.
{{< /note >}}
클러스터에 기본 파드 분배 제약 조건을 사용하지 않으려면,
`PodTopologySpread` 플러그인 구성에서 `defaultingType` 을 `List` 로 설정하고
`defaultConstraints` 를 비워두어 기본값을 비활성화할 수 있다.
```yaml
apiVersion: kubescheduler.config.k8s.io/v1beta1
kind: KubeSchedulerConfiguration
profiles:
- pluginConfig:
- name: PodTopologySpread
args:
defaultConstraints: []
defaultingType: List
```
## 파드어피니티(PodAffinity)/파드안티어피니티(PodAntiAffinity)와의 비교
쿠버네티스에서 "어피니티(Affinity)"와 관련된 지침은 파드가
content/ko/docs/concepts/workloads/pods/podpreset.md
-89
View File
@@ -1,89 +0,0 @@
---
title: 파드 프리셋
content_type: concept
weight: 50
---
<!-- overview -->
{{< feature-state for_k8s_version="v1.6" state="alpha" >}}
이 페이지는 파드프리셋(PodPreset)에 대한 개요를 제공한다. 파드프리셋은 파드 생성 시간에 파드에
특정 정보를 주입하기 위한 오브젝트이다. 해당 정보에는
시크릿, 볼륨, 볼륨 마운트, 환경 변수가 포함될 수 있다.
<!-- body -->
## 파드 프리셋 이해하기
파드프리셋은 파드 생성 시간에 파드에 추가적인 런타임 요구사항을
주입하기 위한 API 리소스이다.
주어진 파드프리셋이 적용되도록 파드에 명시하기 위해서는
[레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/#레이블-셀렉터)를 사용한다.
파드프리셋을 사용하는 것은 파드 템플릿 작성자에게 모든 파드를 위한 모든 정보를 명시적으로
제공하지는 않아도 되도록 한다. 이렇게 하면, 어떤 특정 서비스를 사용할 파드의 파드
템플릿 작성자는 해당 서비스에 대한 모든 세부 사항을 알 필요가 없다.
## 클러스터에서 파드프리셋 활성화하기 {#enable-pod-preset}
클러스터에서 파드 프리셋을 사용하기 위해서는 다음 사항이 반드시 이행되어야 한다.
1. API 타입 `settings.k8s.io/v1alpha1/podpreset`을 활성화하였다.
예를 들면, 이것은 API 서버의 `--runtime-config` 옵션에 `settings.k8s.io/v1alpha1=true`을 포함하여 완료할 수 있다.
minikube에서는 클러스터가 시작할 때
`--extra-config=apiserver.runtime-config=settings.k8s.io/v1alpha1=true`
플래그를 추가한다.
1. 어드미션 컨트롤러 `PodPreset`을 활성화하였다. 이것을 이루는 방법 중 하나는
API 서버를 위해서 명시된 `--enable-admission-plugins` 옵션에 `PodPreset`을 포함하는 것이다.
minikube에서는 클러스터가 시작할 때
```shell
--extra-config=apiserver.enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,PodPreset
```
플래그를 추가한다.
## 어떻게 동작하는가
쿠버네티스는 어드미션 컨트롤러(`PodPreset`)를 제공한다. 어드미션 컨트롤러가 활성화되면,
파드 프리셋을 파드 생성 요청에 적용한다.
파드 생성 요청이 발생하면, 시스템은 다음의 내용을 수행한다.
1. 사용 가능한 모든 `PodPresets`을 검색한다.
1. `PodPreset`의 레이블 셀렉터들 중 하나라도 생성되는 파드의 레이블과 일치하는
것이 있는지 확인한다.
1. `PodPreset`에 의해서 정의된 다양한 리소스가 생성되는 파드에
병합되도록 시도한다.
1. 오류 시, 파드의 병합 오류를 문서화하는 이벤트를 발생시키고, `PodPreset`으로
부터 주입된 어떤 리소스도 _없이_ 파드를 생성한다.
1. 수정된 파드 스펙의 결과에 어노테이션을 달아 `PodPreset`에 의해서
수정되었음을 표시한다. 해당 어노테이션은 다음의 양식을 따른다.
`podpreset.admission.kubernetes.io/podpreset-<파드-프리셋 이름>: "<리소스 버전>"`.
각 파드는 0개 이상의 파드프리셋에 일치될 수 있고, 각 파드프리셋은 0개 이상의
파드에 적용될 수 있다. 하나의 파드프리셋이 한 개 이상의 파드에 적용되었을
때, 쿠버네티스는 해당 파드의 스펙을 수정한다. `env`, `envFrom`, `volumeMounts`의
변경에 대해서는, 쿠버네티스가 파드 내의 모든 컨테이너의 컨테이너 스펙을
수정한다. `volume` 변경에 대해서는, 쿠버네티스는 해당 파드의 스펙을 수정한다.
{{< note >}}
파드 프리셋은 적절한 경우 파드 스펙의 다음 필드를 수정할 수도 있다.
- `.spec.containers` 필드
- `.spec.initContainers` 필드
{{< /note >}}
### 특정 파드의 파드 프리셋 비활성화하기
어떠한 파드 프리셋 변이에 의해서도 파드에 변경이 일어나지 않게 하고 싶은 경우가
있을 것이다. 이 경우에는, 다음과 같은 양식으로 어노테이션을 파드의 `.spec` 에
추가한다. `podpreset.admission.kubernetes.io/exclude: "true"`.
## {{% heading "whatsnext" %}}
[파드프리셋을 사용하여 파드에 데이터 주입하기](/docs/tasks/inject-data-application/podpreset/)를 본다.
배경에 대한 자세한 정보를 위해서는, [파드프리셋을 위한 디자인 제안](https://git.k8s.io/community/contributors/design-proposals/service-catalog/pod-preset.md)을 본다.