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

Merge pull request #41321 from kubernetes/dev-1.26-ko.1 

[ko] 1st Korean localization work for v1.26
This commit is contained in:
Kubernetes Prow Robot 2023-06-12 05:37:48 -07:00 committed by GitHub
parent 6b87e648c6 7742964a0c
commit 761fd84a4c
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
251 changed files with 8522 additions and 3414 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
content/ko/community/_index.html
View File

@ -1,5 +1,5 @@
---
title: Community
title: 커뮤니티
layout: basic
cid: community
community_styles_migrated: true

2
content/ko/community/code-of-conduct.md
View File

@ -9,7 +9,7 @@ community_styles_migrated: true
<p>
쿠버네티스는
<a href="https://github.com/cncf/foundation/blob/main/code-of-conduct.md">CNCF의 행동 강령</a>을 따르고 있습니다.
<a href="https://github.com/cncf/foundation/blob/71b12a2f8b4589788ef2d69b351a3d035c68d927/code-of-conduct.md">커밋 71b12a2</a>
<a href="https://github.com/cncf/foundation/blob/fff715fb000ba4d7422684eca1d50d80676be254/code-of-conduct.md">커밋 fff715fb0</a>
에 따라 CNCF 행동 강령의 내용이 아래에 복제됩니다.
만약 최신 버전이 아닌 경우에는
<a href="https://github.com/kubernetes/website/issues/new">이슈를 제기해 주세요</a>.

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

@ -107,7 +107,7 @@ IP 주소, 네트워크 패킷 필터링 그리고 대상 상태 확인과 같
### 서비스 컨트롤러 {#authorization-service-controller}
서비스 컨트롤러는 서비스 오브젝트 생성, 업데이트 그리고 삭제 이벤트를 수신한 다음 해당 서비스에 대한 엔드포인트를 적절하게 구성한다.
서비스 컨트롤러는 서비스 오브젝트 생성, 업데이트 그리고 삭제 이벤트를 수신한 다음 해당 서비스에 대한 엔드포인트를 적절하게 구성한다(엔드포인트슬라이스(EndpointSlice)의 경우, kube-controller-manager가 필요에 따라 이들을 관리한다).
서비스에 접근하려면, 목록과 감시 접근 권한이 필요하다. 서비스를 업데이트하려면, 패치와 업데이트 접근 권한이 필요하다.

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

@ -13,7 +13,7 @@ weight: 30
사용자는 온도를 설정해서, 사용자가 *의도한 상태* 를
온도 조절기에 알려준다.
*현재 상태* 이다. 온도 조절기는 장비를 켜거나 꺼서
실제 실내 온도는 *현재 상태* 이다. 온도 조절기는 장비를 켜거나 꺼서
현재 상태를 의도한 상태에 가깝게 만든다.
{{< glossary_definition term_id="controller" length="short">}}

2
content/ko/docs/concepts/architecture/cri.md
View File

@ -1,7 +1,7 @@
---
title: 컨테이너 런타임 인터페이스(CRI)
content_type: concept
weight: 50
weight: 60
---
<!-- overview -->

2
content/ko/docs/concepts/architecture/garbage-collection.md
View File

@ -1,7 +1,7 @@
---
title: 가비지(Garbage) 수집
content_type: concept
weight: 50
weight: 70
---
<!-- overview -->

80
content/ko/docs/concepts/architecture/leases.md Normal file
View File

@ -0,0 +1,80 @@
---
title: 리스(Lease)
content_type: concept
weight: 30
---
<!-- overview -->
분산 시스템에는 종종 공유 리소스를 잠그고 노드 간의 활동을 조정하는 메커니즘을 제공하는 "리스(Lease)"가 필요하다.
쿠버네티스에서 "리스" 개념은 `coordination.k8s.io` API 그룹에 있는 `Lease` 오브젝트로 표현되며,
노드 하트비트 및 컴포넌트 수준의 리더 선출과 같은 시스템 핵심 기능에서 사용된다.
<!-- body -->
## 노드 하트비트
쿠버네티스는 리스 API를 사용하여 kubelet 노드의 하트비트를 쿠버네티스 API 서버에 전달한다.
모든 `노드`에는 같은 이름을 가진 `Lease` 오브젝트가 `kube-node-lease` 네임스페이스에 존재한다.
내부적으로, 모든 kubelet 하트비트는 이 `Lease` 오브젝트에 대한 업데이트 요청이며,
이 업데이트 요청은 `spec.renewTime` 필드를 업데이트한다.
쿠버네티스 컨트롤 플레인은 이 필드의 타임스탬프를 사용하여 해당 `노드`의 가용성을 확인한다.
자세한 내용은 [노드 리스 오브젝트](/ko/docs/concepts/architecture/nodes/#heartbeats)를 참조한다.
## 리더 선출
리스는 쿠버네티스에서도 특정 시간 동안 컴포넌트의 인스턴스 하나만 실행되도록 보장하는 데에도 사용된다.
이는 구성 요소의 한 인스턴스만 활성 상태로 실행되고 다른 인스턴스는 대기 상태여야 하는
`kube-controller-manager` 및 `kube-scheduler`와 같은 컨트롤 플레인 컴포넌트의
고가용성 설정에서 사용된다.
## API 서버 신원
{{< feature-state for_k8s_version="v1.26" state="beta" >}}
쿠버네티스 v1.26부터, 각 `kube-apiserver`는 리스 API를 사용하여 시스템의 나머지 부분에 자신의 신원을 게시한다.
그 자체로는 특별히 유용하지는 않지만, 이것은 클라이언트가 쿠버네티스 컨트롤 플레인을 운영 중인 `kube-apiserver` 인스턴스 수를
파악할 수 있는 메커니즘을 제공한다.
kube-apiserver 리스의 존재는 향후 각 kube-apiserver 간의 조정이 필요할 때
기능을 제공해 줄 수 있다.
각 kube-apiserver가 소유한 리스는 `kube-system` 네임스페이스에서`kube-apiserver-<sha256-hash>`라는 이름의
리스 오브젝트를 확인하여 볼 수 있다. 또는 `k8s.io/component=kube-apiserver` 레이블 설렉터를 사용하여 볼 수도 있다.
```shell
$ kubectl -n kube-system get lease -l k8s.io/component=kube-apiserver
NAME HOLDER AGE
kube-apiserver-c4vwjftbvpc5os2vvzle4qg27a kube-apiserver-c4vwjftbvpc5os2vvzle4qg27a_9cbf54e5-1136-44bd-8f9a-1dcd15c346b4 5m33s
kube-apiserver-dz2dqprdpsgnm756t5rnov7yka kube-apiserver-dz2dqprdpsgnm756t5rnov7yka_84f2a85d-37c1-4b14-b6b9-603e62e4896f 4m23s
kube-apiserver-fyloo45sdenffw2ugwaz3likua kube-apiserver-fyloo45sdenffw2ugwaz3likua_c5ffa286-8a9a-45d4-91e7-61118ed58d2e 4m43s
```
리스 이름에 사용된 SHA256 해시는 kube-apiserver가 보는 OS 호스트 이름을 기반으로 한다.
각 kube-apiserver는 클러스터 내에서 고유한 호스트 이름을 사용하도록 구성해야 한다.
동일한 호스트명을 사용하는 새로운 kube-apiserver 인스턴스는 새 리스 오브젝트를 인스턴스화하는 대신 새로운 소유자 ID를 사용하여 기존 리스를 차지할 수 있다.
kube-apiserver가 사용하는 호스트네임은 `kubernetes.io/hostname` 레이블의 값을 확인하여 확인할 수 있다.
```shell
$ kubectl -n kube-system get lease kube-apiserver-c4vwjftbvpc5os2vvzle4qg27a -o yaml
```
```yaml
apiVersion: coordination.k8s.io/v1
kind: Lease
metadata:
creationTimestamp: "2022-11-30T15:37:15Z"
labels:
k8s.io/component: kube-apiserver
kubernetes.io/hostname: kind-control-plane
name: kube-apiserver-c4vwjftbvpc5os2vvzle4qg27a
namespace: kube-system
resourceVersion: "18171"
uid: d6c68901-4ec5-4385-b1ef-2d783738da6c
spec:
holderIdentity: kube-apiserver-c4vwjftbvpc5os2vvzle4qg27a_9cbf54e5-1136-44bd-8f9a-1dcd15c346b4
leaseDurationSeconds: 3600
renewTime: "2022-11-30T18:04:27.912073Z"
```
더 이상 존재하지 않는 kube-apiserver의 만료된 임대는 1시간 후에 새로운 kube-apiserver에 의해 가비지 컬렉션된다.

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

@ -456,7 +456,7 @@ Message: Pod was terminated in response to imminent node shutdown.
## 논 그레이스풀 노드 셧다운 {#non-graceful-node-shutdown}
{{< feature-state state="alpha" for_k8s_version="v1.24" >}}
{{< feature-state state="beta" for_k8s_version="v1.26" >}}
전달한 명령이 kubelet에서 사용하는 금지 잠금 메커니즘(inhibitor locks mechanism)을 트리거하지 않거나,
또는 사용자 오류(예: ShutdownGracePeriod 및 ShutdownGracePeriodCriticalPods가 제대로 설정되지 않음)로 인해

1
content/ko/docs/concepts/cluster-administration/addons.md
View File

@ -1,6 +1,7 @@
---
title: 애드온 설치
content_type: concept
weight: 120
---
<!-- overview -->

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

@ -9,24 +9,35 @@ weight: 60
<!-- overview -->
애플리케이션 로그는 애플리케이션 내부에서 발생하는 상황을 이해하는 데 도움이 된다. 로그는 문제를 디버깅하고 클러스터 활동을 모니터링하는 데 특히 유용하다. 대부분의 최신 애플리케이션에는 일종의 로깅 메커니즘이 있다. 마찬가지로, 컨테이너 엔진들도 로깅을 지원하도록 설계되었다. 컨테이너화된 애플리케이션에 가장 쉽고 가장 널리 사용되는 로깅 방법은 표준 출력과 표준 에러 스트림에 작성하는 것이다.
애플리케이션 로그는 애플리케이션 내부에서 발생하는 상황을 이해하는 데 도움이 된다.
로그는 문제를 디버깅하고 클러스터 활동을 모니터링하는 데 특히 유용하다.
대부분의 최신 애플리케이션에는 일종의 로깅 메커니즘이 있다.
마찬가지로, 컨테이너 엔진들도 로깅을 지원하도록 설계되었다.
컨테이너화된 애플리케이션에 가장 쉽고 가장 널리 사용되는 로깅 방법은 표준 출력과 표준 에러 스트림에 작성하는 것이다.
그러나, 일반적으로 컨테이너 엔진이나 런타임에서 제공하는 기본 기능은 완전한 로깅 솔루션으로 충분하지 않다.
그러나, 일반적으로 컨테이너 엔진이나 런타임에서 제공하는 기본 기능은
완전한 로깅 솔루션으로 충분하지 않다.
예를 들어, 컨테이너가 크래시되거나, 파드가 축출되거나, 노드가 종료된 경우에도 애플리케이션의 로그에 접근하고 싶을 것이다.
예를 들어, 컨테이너가 크래시되거나, 파드가 축출되거나, 노드가 종료된 경우에
애플리케이션의 로그에 접근하고 싶을 것이다.
클러스터에서 로그는 노드, 파드 또는 컨테이너와는 독립적으로 별도의 스토리지와 라이프사이클을 가져야 한다. 이 개념을 _클러스터-레벨-로깅_ 이라고 한다.
클러스터에서 로그는 노드, 파드 또는 컨테이너와는 독립적으로
별도의 스토리지와 라이프사이클을 가져야 한다.
이 개념을 [클러스터-레벨 로깅](#cluster-level-logging-architectures)이라고 한다.
클러스터-레벨 로깅은 로그를 저장, 분석, 쿼리하기 위해서는 별도의 백엔드가 필요하다.
쿠버네티스가 로그 데이터를 위한 네이티브 스토리지 솔루션을 제공하지는 않지만,
쿠버네티스에 통합될 수 있는 기존의 로깅 솔루션이 많이 있다.
아래 내용은 로그를 어떻게 처리하고 관리하는지 설명한다.
<!-- body -->
클러스터-레벨 로깅은 로그를 저장, 분석, 쿼리하기 위해서는 별도의 백엔드가 필요하다. 쿠버네티스가
로그 데이터를 위한 네이티브 스토리지 솔루션을 제공하지는 않지만,
쿠버네티스에 통합될 수 있는 기존의 로깅 솔루션이 많이 있다.
## 파드와 컨테이너 로그 {#basic-logging-in-kubernetes}
## 쿠버네티스의 기본 로깅
쿠버네티스는 실행중인 파드의 컨테이너에서 출력하는 로그를 감시한다.
이 예시는 텍스트를 초당 한 번씩 표준 출력에 쓰는
컨테이너에 대한 `Pod` 명세를 사용한다.
아래 예시는, 초당 한 번씩 표준 출력에 텍스트를 기록하는
컨테이너를 포함하는 `파드` 매니페스트를 사용한다.
{{< codenew file="debug/counter-pod.yaml" >}}
@ -51,10 +62,9 @@ kubectl logs counter
출력은 다음과 같다.
```console
0: Mon Jan 1 00:00:00 UTC 2001
1: Mon Jan 1 00:00:01 UTC 2001
2: Mon Jan 1 00:00:02 UTC 2001
...
0: Fri Apr 1 11:42:23 UTC 2022
1: Fri Apr 1 11:42:24 UTC 2022
2: Fri Apr 1 11:42:25 UTC 2022
```
`kubectl logs --previous` 를 사용해서 컨테이너의 이전 인스턴스에 대한 로그를 검색할 수 있다.
@ -67,72 +77,129 @@ kubectl logs counter -c count
자세한 내용은 [`kubectl logs` 문서](/docs/reference/generated/kubectl/kubectl-commands#logs)를 참조한다.
## 노드 레벨에서의 로깅
### 노드가 컨테이너 로그를 처리하는 방법
![노드 레벨 로깅](/images/docs/user-guide/logging/logging-node-level.png)
컨테이너화된 애플리케이션의 `stdout(표준 출력)` 및 `stderr(표준 에러)` 스트림에 의해 생성된 모든 출력은 컨테이너 엔진이 처리 및 리디렉션 한다.
예를 들어, 도커 컨테이너 엔진은 이 두 스트림을 [로깅 드라이버](https://docs.docker.com/engine/admin/logging/overview)로 리디렉션 한다. 이 드라이버는 쿠버네티스에서 JSON 형식의 파일에 작성하도록 구성된다.
컨테이너화된 애플리케이션의 `stdout(표준 출력)` 및 `stderr(표준 에러)` 스트림에 의해 생성된 모든 출력은 컨테이너 런타임이 처리하고 리디렉션 시킨다.
다양한 컨테이너 런타임들은 이를 각자 다른 방법으로 구현하였지만,
kubelet과의 호환성은 _CRI 로깅 포맷_ 으로 표준화되어 있다.
{{< note >}}
도커 JSON 로깅 드라이버는 각 라인을 별도의 메시지로 취급한다. 도커 로깅 드라이버를 사용하는 경우, 멀티-라인 메시지를 직접 지원하지 않는다. 로깅 에이전트 레벨 이상에서 멀티-라인 메시지를 처리해야 한다.
{{< /note >}}
기본적으로 컨테이너가 재시작하는 경우, kubelet은 종료된 컨테이너 하나를 로그와 함께 유지한다.
파드가 노드에서 축출되면, 해당하는 모든 컨테이너와 로그가 함께 축출된다.
기본적으로, 컨테이너가 다시 시작되면, kubelet은 종료된 컨테이너 하나를 로그와 함께 유지한다. 파드가 노드에서 축출되면, 해당하는 모든 컨테이너도 로그와 함께 축출된다.
kubelet은 쿠버네티스의 특정 API를 통해 사용자들에게 로그를 공개하며,
일반적으로 `kubectl logs`를 통해 접근할 수 있다.
노드-레벨 로깅에서 중요한 고려 사항은 로그 로테이션을 구현하여,
로그가 노드에서 사용 가능한 모든 스토리지를 사용하지 않도록 하는 것이다. 쿠버네티스는
로그 로테이션에 대한 의무는 없지만, 디플로이먼트 도구로
이를 해결하기 위한 솔루션을 설정해야 한다.
예를 들어, `kube-up.sh` 스크립트에 의해 배포된 쿠버네티스 클러스터에는,
매시간 실행되도록 구성된 [`logrotate`](https://linux.die.net/man/8/logrotate)
도구가 있다. 애플리케이션의 로그를 자동으로
로테이션하도록 컨테이너 런타임을 설정할 수도 있다.
### 로그 로테이션
예를 들어, `kube-up.sh` 가 GCP의 COS 이미지 로깅을 설정하는 방법은
[`configure-helper` 스크립트](https://github.com/kubernetes/kubernetes/blob/master/cluster/gce/gci/configure-helper.sh)를 통해
자세히 알 수 있다.
{{< feature-state for_k8s_version="v1.21" state="stable" >}}
**CRI 컨테이너 런타임** 을 사용할 때, kubelet은 로그를 로테이션하고 로깅 디렉터리 구조를 관리한다.
kubelet은 이 정보를 CRI 컨테이너 런타임에 전송하고 런타임은 컨테이너 로그를 지정된 위치에 기록한다.
[kubelet config file](/docs/tasks/administer-cluster/kubelet-config-file/)에 있는
두 개의 kubelet 파라미터 [`containerLogMaxSize` 및 `containerLogMaxFiles`](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)를
사용하여 각 로그 파일의 최대 크기와 각 컨테이너에 허용되는 최대 파일 수를 각각 구성할 수 있다.
kubelet이 로그를 자동으로 로테이트하도록 설정할 수 있다.
로테이션을 구성해놓으면, kubelet은 컨테이너 로그를 로테이트하고 로깅 경로 구조를 관리한다.
kubelet은 이 정보를 컨테이너 런타임에 전송하고(CRI를 사용),
런타임은 지정된 위치에 컨테이너 로그를 기록한다.
[kubelet 설정 파일](/docs/tasks/administer-cluster/kubelet-config-file/)을 사용하여
두 개의 kubelet 파라미터
[`containerLogMaxSize` 및 `containerLogMaxFiles`](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)를 설정 가능하다.
이러한 설정을 통해 각 로그 파일의 최대 크기와 각 컨테이너에 허용되는 최대 파일 수를 각각 구성할 수 있다.
기본 로깅 예제에서와 같이 [`kubectl logs`](/docs/reference/generated/kubectl/kubectl-commands#logs)를
실행하면, 노드의 kubelet이 요청을 처리하고
로그 파일에서 직접 읽는다. kubelet은 로그 파일의 내용을 반환한다.
실행하면, 노드의 kubelet이 요청을 처리하고 로그 파일에서 직접 읽는다.
kubelet은 로그 파일의 내용을 반환한다.
{{< note >}}
만약, 일부 외부 시스템이 로테이션을 수행했거나 CRI 컨테이너 런타임이 사용된 경우,
`kubectl logs` 를 통해 최신 로그 파일의 내용만
사용할 수 있다. 예를 들어, 10MB 파일이 있으면, `logrotate` 가
로테이션을 수행하고 두 개의 파일이 생긴다. (크기가 10MB인 파일 하나와 비어있는 파일)
`kubectl logs` 는 이 예시에서는 빈 응답에 해당하는 최신 로그 파일을 반환한다.
`kubectl logs`를 통해서는
최신 로그만 확인할 수 있다.
예를 들어, 파드가 40MiB 크기의 로그를 기록했고 kubelet이 10MiB 마다 로그를 로테이트하는 경우
`kubectl logs`는 최근의 10MiB 데이터만 반환한다.
{{< /note >}}
### 시스템 컴포넌트 로그
## 시스템 컴포넌트 로그
시스템 컴포넌트에는 컨테이너에서 실행되는 것과 컨테이너에서 실행되지 않는 두 가지 유형이 있다.
시스템 컴포넌트에는 두 가지 유형이 있는데, 컨테이너에서 실행되는 것과 실행 중인 컨테이너와 관련된 것이다.
예를 들면 다음과 같다.
* 쿠버네티스 스케줄러와 kube-proxy는 컨테이너에서 실행된다.
* Kubelet과 컨테이너 런타임은 컨테이너에서 실행되지 않는다.
* kubelet과 컨테이너 런타임은 컨테이너에서 실행되지 않는다.
kubelet이 컨테이너({{< glossary_tooltip text="파드" term_id="pod" >}}와 그룹화된)를 실행시킨다.
* 쿠버네티스의 스케줄러, 컨트롤러 매니저, API 서버는
파드(일반적으로 {{< glossary_tooltip text="스태틱 파드" term_id="static-pod" >}})로 실행된다.
etcd는 컨트롤 플레인에서 실행되며, 대부분의 경우 역시 스태틱 파드로써 실행된다.
클러스터가 kube-proxy를 사용하는 경우는 `데몬셋(DaemonSet)`으로써 실행된다.
systemd를 사용하는 시스템에서는, kubelet과 컨테이너 런타임은 journald에 작성한다.
systemd를 사용하지 않으면, kubelet과 컨테이너 런타임은 `/var/log` 디렉터리의
`.log` 파일에 작성한다. 컨테이너 내부의 시스템 컴포넌트는 기본 로깅 메커니즘을 무시하고,
항상 `/var/log` 디렉터리에 기록한다.
시스템 컴포넌트는 [klog](https://github.com/kubernetes/klog)
로깅 라이브러리를 사용한다. [로깅에 대한 개발 문서](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md)에서
해당 컴포넌트의 로깅 심각도(severity)에 대한 규칙을 찾을 수 있다.
### 로그의 위치 {#log-location-node}
컨테이너 로그와 마찬가지로, `/var/log` 디렉터리의 시스템 컴포넌트 로그를
로테이트해야 한다. `kube-up.sh` 스크립트로 구축한 쿠버네티스 클러스터에서
로그는 매일 또는 크기가 100MB를 초과하면
`logrotate` 도구에 의해 로테이트가 되도록 구성된다.
kubelet과 컨테이너 런타임이 로그를 기록하는 방법은,
노드의 운영체제에 따라 다르다.
## 클러스터 레벨 로깅 아키텍처
{{< tabs name="log_location_node_tabs" >}}
{{% tab name="리눅스" %}}
systemd를 사용하는 시스템에서는 kubelet과 컨테이너 런타임은 기본적으로 로그를 journald에 작성한다.
`journalctl`을 사용하여 이를 확인할 수 있다.
예를 들어 `journalctl -u kubelet`.
systemd를 사용하지 않는 시스템에서, kubelet과 컨테이너 런타임은 로그를 `/var/log` 디렉터리의 `.log` 파일에 작성한다.
다른 경로에 로그를 기록하고 싶은 경우에는, `kube-log-runner`를 통해
간접적으로 kubelet을 실행하여
kubelet의 로그를 지정한 디렉토리로 리디렉션할 수 있다.
kubelet을 실행할 때 `--log-dir` 인자를 통해 로그가 저장될 디렉토리를 지정할 수 있다.
그러나 해당 인자는 더 이상 지원되지 않으며(deprecated), kubelet은 항상 컨테이너 런타임으로 하여금
`/var/log/pods` 아래에 로그를 기록하도록 지시한다.
`kube-log-runner`에 대한 자세한 정보는 [시스템 로그](/ko/docs/concepts/cluster-administration/system-logs/#klog)를 확인한다.
{{% /tab %}}
{{% tab name="윈도우" %}}
kubelet은 기본적으로 `C:\var\logs` 아래에 로그를 기록한다
(`C:\var\log`가 아님에 주의한다).
`C:\var\log` 경로가 쿠버네티스에 설정된 기본값이지만,
몇몇 클러스터 배포 도구들은 윈도우 노드의 로그 경로로 `C:\var\log\kubelet`를 사용하기도 한다.
다른 경로에 로그를 기록하고 싶은 경우에는, `kube-log-runner`를 통해
간접적으로 kubelet을 실행하여
kubelet의 로그를 지정한 디렉토리로 리디렉션할 수 있다.
그러나, kubelet은 항상 컨테이너 런타임으로 하여금
`C:\var\log\pods` 아래에 로그를 기록하도록 지시한다.
`kube-log-runner`에 대한 자세한 정보는 [시스템 로그](/ko/docs/concepts/cluster-administration/system-logs/#klog)를 확인한다.
{{% /tab %}}
{{< /tabs >}}
<br /><!-- work around rendering nit -->
파드로 실행되는 쿠버네티스 컴포넌트의 경우,
기본 로깅 메커니즘을 따르지 않고 `/var/log` 아래에 로그를 기록한다
(즉, 해당 컴포넌트들은 systemd의 journal에 로그를 기록하지 않는다).
쿠버네티스의 저장 메커니즘을 사용하여, 컴포넌트를 실행하는 컨테이너에 영구적으로 사용 가능한 저장 공간을 연결할 수 있다.
etcd와 etcd의 로그를 기록하는 방식에 대한 자세한 정보는 [etcd 공식 문서](https://etcd.io/docs/)를 확인한다.
다시 언급하자면, 쿠버네티스의 저장 메커니즘을 사용하여
컴포넌트를 실행하는 컨테이너에 영구적으로 사용 가능한 저장 공간을 연결할 수 있다.
{{< note >}}
스케줄러와 같은 쿠버네티스 클러스터의 컴포넌트를 배포하여 상위 노드에서 공유된 볼륨에 로그를 기록하는 경우,
해당 로그들이 로테이트되는지 확인하고 관리해야 한다.
**쿠버네티스는 로그 로테이션을 관리하지 않는다**.
몇몇 로그 로테이션은 운영체제가 자동적으로 구현할 수도 있다.
예를 들어, 컴포넌트를 실행하는 스태틱 파드에 `/var/log` 디렉토리를 공유하여 로그를 기록하면,
노드-레벨 로그 로테이션은 해당 경로의 파일을
쿠버네티스 외부의 다른 컴포넌트들이 기록한 파일과 동일하게 취급한다.
몇몇 배포 도구들은 로그 로테이션을 자동화하지만,
나머지 도구들은 이를 사용자의 책임으로 둔다.
{{< /note >}}
## 클러스터-레벨 로깅 아키텍처 {#cluster-level-logging-architectures}
쿠버네티스는 클러스터-레벨 로깅을 위한 네이티브 솔루션을 제공하지 않지만, 고려해야 할 몇 가지 일반적인 접근 방법을 고려할 수 있다. 여기 몇 가지 옵션이 있다.
@ -165,7 +232,7 @@ systemd를 사용하지 않으면, kubelet과 컨테이너 런타임은 `/var/lo
![스트리밍 컨테이너가 있는 사이드카 컨테이너](/images/docs/user-guide/logging/logging-with-streaming-sidecar.png)
사이드카 컨테이너가 자체 `stdout` 및 `stderr` 스트림으로
쓰도록 하면, 각 노드에서 이미 실행 중인 kubelet과 로깅 에이전트를
기록하도록 하면, 각 노드에서 이미 실행 중인 kubelet과 로깅 에이전트를
활용할 수 있다. 사이드카 컨테이너는 파일, 소켓 또는 journald에서 로그를 읽는다.
각 사이드카 컨테이너는 자체 `stdout` 또는 `stderr` 스트림에 로그를 출력한다.
@ -177,8 +244,8 @@ systemd를 사용하지 않으면, kubelet과 컨테이너 런타임은 `/var/lo
빌트인 도구를 사용할 수 있다.
예를 들어, 파드는 단일 컨테이너를 실행하고, 컨테이너는
서로 다른 두 가지 형식을 사용하여 서로 다른 두 개의 로그 파일에 기록한다. 파드에 대한
구성 파일은 다음과 같다.
서로 다른 두 가지 형식을 사용하여 서로 다른 두 개의 로그 파일에 기록한다.
다음은 파드에 대한 매니페스트이다.
{{< codenew file="admin/logging/two-files-counter-pod.yaml" >}}
@ -188,7 +255,7 @@ systemd를 사용하지 않으면, kubelet과 컨테이너 런타임은 `/var/lo
컨테이너는 공유 볼륨에서 특정 로그 파일을 테일(tail)한 다음 로그를
자체 `stdout` 스트림으로 리디렉션할 수 있다.
다음은 사이드카 컨테이너가 두 개인 파드에 대한 구성 파일이다.
다음은 사이드카 컨테이너가 두 개인 파드에 대한 매니페스트이다.
{{< codenew file="admin/logging/two-files-counter-pod-streaming-sidecar.yaml" >}}
@ -202,9 +269,9 @@ kubectl logs counter count-log-1
출력은 다음과 같다.
```console
0: Mon Jan 1 00:00:00 UTC 2001
1: Mon Jan 1 00:00:01 UTC 2001
2: Mon Jan 1 00:00:02 UTC 2001
0: Fri Apr 1 11:42:26 UTC 2022
1: Fri Apr 1 11:42:27 UTC 2022
2: Fri Apr 1 11:42:28 UTC 2022
...
```
@ -215,27 +282,28 @@ kubectl logs counter count-log-2
출력은 다음과 같다.
```console
Mon Jan 1 00:00:00 UTC 2001 INFO 0
Mon Jan 1 00:00:01 UTC 2001 INFO 1
Mon Jan 1 00:00:02 UTC 2001 INFO 2
Fri Apr 1 11:42:29 UTC 2022 INFO 0
Fri Apr 1 11:42:30 UTC 2022 INFO 0
Fri Apr 1 11:42:31 UTC 2022 INFO 0
...
```
클러스터에 설치된 노드-레벨 에이전트는 추가 구성없이
클러스터에 노드-레벨 에이전트를 설치했다면, 에이전트는 추가적인 설정 없이도
자동으로 해당 로그 스트림을 선택한다. 원한다면, 소스 컨테이너에
따라 로그 라인을 파싱(parse)하도록 에이전트를 구성할 수 있다.
따라 로그 라인을 파싱(parse)하도록 에이전트를 구성할 수도 있다.
참고로, CPU 및 메모리 사용량이 낮음에도 불구하고(cpu에 대한 몇 밀리코어의
요구와 메모리에 대한 몇 메가바이트의 요구), 로그를 파일에 기록한 다음
`stdout` 으로 스트리밍하면 디스크 사용량은 두 배가 될 수 있다. 단일 파일에
쓰는 애플리케이션이 있는 경우, 일반적으로 스트리밍
사이드카 컨테이너 방식을 구현하는 대신 `/dev/stdout` 을 대상으로
설정하는 것을 추천한다.
CPU 및 메모리 사용량이 낮은(몇 밀리코어 수준의 CPU와 몇 메가바이트 수준의 메모리 요청) 파드라고 할지라도,
로그를 파일에 기록한 다음 `stdout` 으로 스트리밍하는 것은
노드가 필요로 하는 스토리지 양을 두 배로 늘릴 수 있다.
단일 파일에 로그를 기록하는 애플리케이션이 있는 경우,
일반적으로 스트리밍 사이드카 컨테이너 방식을 구현하는 대신
`/dev/stdout` 을 대상으로 설정하는 것을 추천한다.
사이드카 컨테이너를 사용하여 애플리케이션 자체에서 로테이션할 수 없는
로그 파일을 로테이션할 수도 있다. 이 방법의 예시는 정기적으로 `logrotate` 를 실행하는 작은 컨테이너를 두는 것이다.
사이드카 컨테이너를 사용하여
애플리케이션 자체에서 로테이션할 수 없는 로그 파일을 로테이션할 수도 있다.
이 방법의 예시는 정기적으로 `logrotate` 를 실행하는 작은 컨테이너를 두는 것이다.
그러나, `stdout` 및 `stderr` 을 직접 사용하고 로테이션과
유지 정책을 kubelet에 두는 것이 권장된다.
유지 정책을 kubelet에 두는 것이 더욱 직관적이다.
#### 로깅 에이전트가 있는 사이드카 컨테이너
@ -252,24 +320,30 @@ Mon Jan 1 00:00:02 UTC 2001 INFO 2
접근할 수 없다.
{{< /note >}}
여기에 로깅 에이전트가 포함된 사이드카 컨테이너를 구현하는 데 사용할 수 있는 두 가지 구성 파일이 있다. 첫 번째 파일에는
fluentd를 구성하기 위한 [`ConfigMap`](/docs/tasks/configure-pod-container/configure-pod-configmap/)이 포함되어 있다.
아래는 로깅 에이전트가 포함된 사이드카 컨테이너를 구현하는 데 사용할 수 있는 두 가지 매니페스트이다.
첫 번째 매니페스트는 fluentd를 구성하는
[`컨피그맵(ConfigMap)`](/docs/tasks/configure-pod-container/configure-pod-configmap/)이 포함되어 있다.
{{< codenew file="admin/logging/fluentd-sidecar-config.yaml" >}}
{{< note >}}
fluentd를 구성하는 것에 대한 자세한 내용은, [fluentd 문서](https://docs.fluentd.org/)를 참고한다.
예제 매니페스트에서, 꼭 fluentd가 아니더라도,
애플리케이션 컨테이너 내의 모든 소스에서 로그를 읽어올 수 있는 다른 로깅 에이전트를 사용할 수 있다.
{{< /note >}}
두 번째 파일은 fluentd가 실행되는 사이드카 컨테이너가 있는 파드를 설명한다.
두 번째 매니페스트는 fluentd가 실행되는 사이드카 컨테이너가 있는 파드를 설명한다.
파드는 fluentd가 구성 데이터를 가져올 수 있는 볼륨을 마운트한다.
{{< codenew file="admin/logging/two-files-counter-pod-agent-sidecar.yaml" >}}
이 예시 구성에서, 사용자는 애플리케이션 컨테이너 내의 모든 소스을 읽는 fluentd를 다른 로깅 에이전트로 대체할 수 있다.
### 애플리케이션에서 직접 로그 노출
![애플리케이션에서 직접 로그 노출](/images/docs/user-guide/logging/logging-from-application.png)
애플리케이션에서 직접 로그를 노출하거나 푸시하는 클러스터-로깅은 쿠버네티스의 범위를 벗어난다.
## {{% heading "whatsnext" %}}
* [쿠버네티스 시스템 로그](/ko/docs/concepts/cluster-administration/system-logs/) 살펴보기.
* [쿠버네티스 시스템 컴포넌트에 대한 추적(trace)](/docs/concepts/cluster-administration/system-traces/) 살펴보기.
* 파드가 실패했을 때 쿠버네티스가 어떻게 로그를 남기는지에 대해, [종료 메시지를 사용자가 정의하는 방법](/ko/docs/tasks/debug/debug-application/determine-reason-pod-failure/#종료-메시지-사용자-정의하기) 살펴보기.

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

@ -15,7 +15,7 @@ weight: 50
{{< glossary_tooltip text="파드" term_id="pod" >}}와 `localhost` 통신으로 해결된다.
2. 파드 간 통신: 이 문제가 이 문서의 주요 초점이다.
3. 파드와 서비스 간 통신: 이 문제는 [서비스](/ko/docs/concepts/services-networking/service/)에서 다룬다.
4. 외부와 서비스 간 통신: 이 문제는 [서비스](/ko/docs/concepts/services-networking/service/)에서 다룬다.
4. 외부와 서비스 간 통신: 이 문제도 서비스에서 다룬다.
<!-- body -->

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

@ -1,7 +1,7 @@
---
title: 쿠버네티스에서 프락시(Proxy)
content_type: concept
weight: 90
weight: 100
---
<!-- overview -->

52
content/ko/docs/concepts/cluster-administration/system-logs.md
View File

@ -4,14 +4,16 @@
# - 44past4
title: 시스템 로그
content_type: concept
weight: 60
weight: 80
---
<!-- overview -->
시스템 컴포넌트 로그는 클러스터에서 발생하는 이벤트를 기록하며, 이는 디버깅에 아주 유용하다.
더 많거나 적은 세부 정보를 표시하도록 다양하게 로그를 설정할 수 있다.
로그는 컴포넌트 내에서 오류를 표시하는 것 처럼 간단하거나, 이벤트의 단계적 추적(예: HTTP 엑세스 로그, 파드의 상태 변경, 컨트롤러 작업 또는 스케줄러의 결정)을 표시하는 것처럼 세밀할 수 있다.
로그는 컴포넌트 내에서 오류를 표시하는 것 처럼 간단하거나,
이벤트의 단계적 추적(예: HTTP 엑세스 로그, 파드의 상태 변경, 컨트롤러 작업 또는 스케줄러의 결정)을
표시하는 것처럼 세밀할 수 있다.
<!-- body -->
@ -39,14 +41,13 @@ klog 설정에 대한 더 많은 정보는, [커맨드라인 툴](/ko/docs/refer
- `--skip-log-headers`
- `--stderrthreshold`
출력은 출력 형식에 관계없이 항상 표준 에러(stderr)에 기록될 것이다.
출력 리다이렉션은 쿠버네티스 컴포넌트를 호출하는 컴포넌트가 담당할 것으로 기대된다.
이는 POSIX 셸 또는 systemd와 같은 도구일 수
있다.
출력은 출력 형식에 관계없이 항상 표준 에러(stderr)에 기록될 것이다. 출력 리다이렉션은
쿠버네티스 컴포넌트를 호출하는 컴포넌트가 담당할 것으로 기대된다. 이는 POSIX
셸 또는 systemd와 같은 도구일 수 있다.
배포판과 무관한(distroless) 컨테이너 또는 윈도우 시스템 서비스와 같은 몇몇 경우에서,
위의 옵션은 사용할 수 없다.
그런 경우 출력을 리다이렉트하기 위해
배포판과 무관한(distroless) 컨테이너 또는 윈도우 시스템 서비스와 같은 몇몇 경우에서, 위의 옵션은
사용할 수 없다. 그런 경우
출력을 리다이렉트하기 위해
[`kube-log-runner`](https://github.com/kubernetes/kubernetes/blob/d2a8a81639fcff8d1221b900f66d28361a170654/staging/src/k8s.io/component-base/logs/kube-log-runner/README.md)
바이너리를 쿠버네티스 컴포넌트의 래퍼(wrapper)로 사용할 수 있다.
미리 빌드된 바이너리가 몇몇 쿠버네티스 베이스 이미지에 기본 이름 `/go-runner` 와
@ -63,31 +64,34 @@ klog 설정에 대한 더 많은 정보는, [커맨드라인 툴](/ko/docs/refer
### Klog 출력
klog 네이티브 형식 예 :
klog 네이티브 형식 예 :
```
I1025 00:15:15.525108 1 httplog.go:79] GET /api/v1/namespaces/kube-system/pods/metrics-server-v0.3.1-57c75779f-9p8wg: (1.512ms) 200 [pod_nanny/v0.0.0 (linux/amd64) kubernetes/$Format 10.56.1.19:51756]
```
메시지 문자열은 줄바꿈을 포함하고 있을 수도 있다.
```
I1025 00:15:15.525108 1 example.go:79] This is a message
which has a line break.
```
### 구조화된 로깅
{{< feature-state for_k8s_version="v1.23" state="beta" >}}
{{< warning >}}
구조화된 로그메시지로 마이그레이션은 진행중인 작업이다. 이 버전에서는 모든 로그 메시지가 구조화되지 않는다. 로그 파일을 파싱할 때, 구조화되지 않은 로그 메시지도 처리해야 한다.
구조화된 로그메시지로 마이그레이션은 진행중인 작업이다. 이 버전에서는 모든 로그 메시지가 구조화되지 않는다.
로그 파일을 파싱할 때, 구조화되지 않은 로그 메시지도 처리해야 한다.
로그 형식 및 값 직렬화는 변경될 수 있다.
{{< /warning>}}
구조화된 로깅은 로그 메시지에 통일된 구조를 적용하여 정보를 쉽게 추출하고,
로그를 보다 쉽고 저렴하게 저장하고 처리하는 작업이다.
새로운 메시지 형식은 이전 버전과 호환되며 기본적으로 활성화 된다.
구조화된 로깅은 로그 메시지에 유니폼 구조를 적용하여
정보를 쉽게 추출하고, 로그를 보다 쉽고 저렴하게 저장하고 처리하는 작업이다.
로그 메세지를 생성하는 코드는 기존의 구조화되지 않은 klog 출력을 사용 또는
구조화된 로깅을 사용할지 여부를 결정합니다.
구조화된 로그 메시지의 기본 형식은 텍스트이며,
기존 klog와 하위 호환되는 형식이다.
@ -105,6 +109,7 @@ I1025 00:15:15.525108 1 controller_utils.go:116] "Pod status updated" pod=
문자열은 따옴표로 감싸진다. 다른 값들은
[`%+v`](https://pkg.go.dev/fmt#hdr-Printing)로 포맷팅되며, 이로 인해
[데이터에 따라](https://github.com/kubernetes/kubernetes/issues/106428) 로그 메시지가 다음 줄로 이어질 수 있다.
```
I1025 00:15:15.525108 1 example.go:116] "Example" data="This is text with a line break\nand \"quotation marks\"." someInt=1 someFloat=0.1 someStruct={StringField: First line,
second line.}
@ -164,15 +169,18 @@ I0404 18:03:31.171962 452150 logger.go:95] "another runtime" duration="1m0s"
{{< feature-state for_k8s_version="v1.19" state="alpha" >}}
{{<warning >}}
JSON 출력은 많은 표준 klog 플래그를 지원하지 않는다. 지원하지 않는 klog 플래그 목록은, [커맨드라인 툴](/ko/docs/reference/command-line-tools-reference/)을 참고한다.
JSON 출력은 많은 표준 klog 플래그를 지원하지 않는다. 지원하지 않는 klog 플래그 목록은,
[커맨드라인 툴](/ko/docs/reference/command-line-tools-reference/)을 참고한다.
모든 로그가 JSON 형식으로 작성되는 것은 아니다(예: 프로세스 시작 중). 로그를 파싱하려는 경우 JSON 형식이 아닌 로그 행을 처리할 수 있는지 확인해야 한다.
모든 로그가 JSON 형식으로 작성되는 것은 아니다(예: 프로세스 시작 중).
로그를 파싱하려는 경우 JSON 형식이 아닌 로그 행을 처리할 수 있는지 확인해야 한다.
필드 이름과 JSON 직렬화는 변경될 수 있다.
{{< /warning >}}
`--logging-format=json` 플래그는 로그 형식을 klog 기본 형식에서 JSON 형식으로 변경한다.
JSON 로그 형식 예시(보기좋게 출력된 형태)는 다음과 같다.
```json
{
"ts": 1580306777.04728,
@ -186,14 +194,15 @@ JSON 로그 형식 예시(보기좋게 출력된 형태)는 다음과 같다.
}
```
특별한 의미가 있는 키:
특별한 의미가 있는 키:
* `ts` - Unix 시간의 타임스탬프 (필수, 부동 소수점)
* `v` - 자세한 정도 (필수, 정수, 기본 값 0)
* `err` - 오류 문자열 (선택 사항, 문자열)
* `msg` - 메시지 (필수, 문자열)
현재 JSON 형식을 지원하는 컴포넌트 목록:
* {{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}}
* {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}}
* {{< glossary_tooltip term_id="kube-scheduler" text="kube-scheduler" >}}
@ -201,8 +210,9 @@ JSON 로그 형식 예시(보기좋게 출력된 형태)는 다음과 같다.
### 로그 상세 레벨(verbosity)
`-v` 플래그로 로그 상세 레벨(verbosity)을 제어한다. 값을 늘리면 기록된 이벤트 수가 증가한다. 값을 줄이면 기록된 이벤트 수가 줄어든다.
로그 상세 레벨(verbosity)를 높이면 점점 덜 심각한 이벤트가 기록된다. 로그 상세 레벨(verbosity)을 0으로 설정하면 중요한 이벤트만 기록된다.
`-v` 플래그로 로그 상세 레벨(verbosity)을 제어한다. 값을 늘리면 기록된 이벤트 수가 증가한다.
값을 줄이면 기록된 이벤트 수가 줄어든다. 로그 상세 레벨(verbosity)를 높이면
점점 덜 심각한 이벤트가 기록된다. 로그 상세 레벨(verbosity)을 0으로 설정하면 중요한 이벤트만 기록된다.
### 로그 위치

107
content/ko/docs/concepts/cluster-administration/system-metrics.md
View File

@ -5,12 +5,13 @@ title: 쿠버네티스 시스템 컴포넌트에 대한 메트릭
# - logicalhan
# - RainbowMango
content_type: concept
weight: 60
weight: 70
---
<!-- overview -->
시스템 컴포넌트 메트릭으로 내부에서 발생하는 상황을 더 잘 파악할 수 있다. 메트릭은 대시보드와 경고를 만드는 데 특히 유용하다.
시스템 컴포넌트 메트릭으로 내부에서 발생하는 상황을 더 잘 파악할 수 있다. 메트릭은
대시보드와 경고를 만드는 데 특히 유용하다.
쿠버네티스 컴포넌트의 메트릭은 [프로메테우스 형식](https://prometheus.io/docs/instrumenting/exposition_formats/)으로 출력된다.
이 형식은 구조화된 평문으로 디자인되어 있으므로 사람과 기계 모두가 쉽게 읽을 수 있다.
@ -19,7 +20,8 @@ weight: 60
## 쿠버네티스의 메트릭
대부분의 경우 메트릭은 HTTP 서버의 `/metrics` 엔드포인트에서 사용할 수 있다. 기본적으로 엔드포인트를 노출하지 않는 컴포넌트의 경우 `--bind-address` 플래그를 사용하여 활성화할 수 있다.
대부분의 경우 메트릭은 HTTP 서버의 `/metrics` 엔드포인트에서 사용할 수 있다.
기본적으로 엔드포인트를 노출하지 않는 컴포넌트의 경우 `--bind-address` 플래그를 사용하여 활성화할 수 있다.
해당 컴포넌트의 예는 다음과 같다.
@ -29,13 +31,18 @@ weight: 60
* {{< glossary_tooltip term_id="kube-scheduler" text="kube-scheduler" >}}
* {{< glossary_tooltip term_id="kubelet" text="kubelet" >}}
프로덕션 환경에서는 이러한 메트릭을 주기적으로 수집하고 시계열 데이터베이스에서 사용할 수 있도록
[프로메테우스 서버](https://prometheus.io/) 또는 다른 메트릭 수집기(scraper)를 구성할 수 있다.
프로덕션 환경에서는 이러한 메트릭을 주기적으로 수집하고
시계열 데이터베이스에서 사용할 수 있도록 [프로메테우스 서버](https://prometheus.io/) 또는
다른 메트릭 수집기(scraper)를 구성할 수 있다.
참고로 {{< glossary_tooltip term_id="kubelet" text="kubelet" >}}도 `/metrics/cadvisor`, `/metrics/resource` 그리고 `/metrics/probes` 엔드포인트에서 메트릭을 노출한다. 이러한 메트릭은 동일한 라이프사이클을 가지지 않는다.
참고로 {{< glossary_tooltip term_id="kubelet" text="kubelet" >}}도
`/metrics/cadvisor`, `/metrics/resource` 그리고 `/metrics/probes` 엔드포인트에서 메트릭을 노출한다.
이러한 메트릭은 동일한 라이프사이클을 가지지 않는다.
클러스터가 {{< glossary_tooltip term_id="rbac" text="RBAC" >}}을 사용하는 경우, 메트릭을 읽으려면 `/metrics` 에 접근을 허용하는 클러스터롤(ClusterRole)을 가지는 사용자, 그룹 또는 서비스어카운트(ServiceAccount)를 통한 권한이 필요하다.
클러스터가 {{< glossary_tooltip term_id="rbac" text="RBAC" >}}을 사용하는 경우, 메트릭을 읽으려면
`/metrics` 에 접근을 허용하는 클러스터롤(ClusterRole)을 가지는 사용자, 그룹 또는 서비스어카운트(ServiceAccount)를 통한 권한이 필요하다.
예를 들면, 다음과 같다.
```yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
@ -55,6 +62,7 @@ rules:
알파 메트릭은 안정성을 보장하지 않는다. 따라서 언제든지 수정되거나 삭제될 수 있다.
안정적인 메트릭은 변경되지 않는다는 것을 보장한다. 이것은 다음을 의미한다.
* 사용 중단 표기가 없는 안정적인 메트릭은, 이름이 변경되거나 삭제되지 않는다.
* 안정적인 메트릭의 유형(type)은 수정되지 않는다.
@ -79,34 +87,52 @@ some_counter 0
some_counter 0
```
히든 메트릭은 깔끔함(scraping)을 위해 더 이상 게시되지는 않지만, 여전히 사용은 가능하다. 히든 메트릭을 사용하려면, [히든 메트릭 표시](#히든-메트릭-표시) 섹션을 참고한다.
히든 메트릭은 깔끔함(scraping)을 위해 더 이상 게시되지는 않지만, 여전히 사용은 가능하다.
히든 메트릭을 사용하려면, [히든 메트릭 표시](#히든-메트릭-표시) 섹션을 참고한다.
삭제된 메트릭은 더 이상 게시되거나 사용할 수 없다.
## 히든 메트릭 표시
위에서 설명한 것처럼, 관리자는 특정 바이너리의 커맨드 라인 플래그를 통해 히든 메트릭을 활성화할 수 있다. 관리자가 지난 릴리스에서 사용 중단된 메트릭의 마이그레이션을 놓친 경우 관리자를 위한 임시방편으로 사용된다.
위에서 설명한 것처럼, 관리자는 특정 바이너리의 커맨드 라인 플래그를 통해 히든 메트릭을 활성화할 수 있다.
관리자가 지난 릴리스에서 사용 중단된 메트릭의 마이그레이션을 놓친 경우
관리자를 위한 임시방편으로 사용된다.
`show-hidden-metrics-for-version` 플래그는 해당 릴리스에서 사용 중단된 메트릭을 보여주려는 버전을 사용한다. 버전은 xy로 표시되며, 여기서 x는 메이저(major) 버전이고, y는 마이너(minor) 버전이다. 패치 릴리스에서 메트릭이 사용 중단될 수 있지만, 패치 버전은 필요하지 않다. 그 이유는 메트릭 사용 중단 정책이 마이너 릴리스에 대해 실행되기 때문이다.
`show-hidden-metrics-for-version` 플래그는 해당 릴리스에서 사용 중단된 메트릭을 보여주려는
버전을 사용한다. 버전은 xy로 표시되며, 여기서 x는 메이저(major) 버전이고,
y는 마이너(minor) 버전이다. 패치 릴리스에서 메트릭이 사용 중단될 수 있지만, 패치 버전은 필요하지 않다.
그 이유는 메트릭 사용 중단 정책이 마이너 릴리스에 대해 실행되기 때문이다.
플래그는 그 값으로 이전의 마이너 버전만 사용할 수 있다. 관리자가 이전 버전을 `show-hidden-metrics-for-version` 에 설정하면 이전 버전의 모든 히든 메트릭이 생성된다. 사용 중단 메트릭 정책을 위반하기 때문에 너무 오래된 버전은 허용되지 않는다.
플래그는 그 값으로 이전의 마이너 버전만 사용할 수 있다. 관리자가 이전 버전을
`show-hidden-metrics-for-version` 에 설정하면 이전 버전의 모든 히든 메트릭이 생성된다.
사용 중단 메트릭 정책을 위반하기 때문에 너무 오래된 버전은 허용되지 않는다.
1.n 버전에서 사용 중단되었다고 가정한 메트릭 `A` 를 예로 들어보겠다. 메트릭 사용 중단 정책에 따르면, 다음과 같은 결론에 도달할 수 있다.
1.n 버전에서 사용 중단되었다고 가정한 메트릭 `A` 를 예로 들어보겠다.
메트릭 사용 중단 정책에 따르면, 다음과 같은 결론에 도달할 수 있다.
* `1.n` 릴리스에서는 메트릭이 사용 중단되었으며, 기본적으로 생성될 수 있다.
* `1.n+1` 릴리스에서는 기본적으로 메트릭이 숨겨져 있으며, `show-hidden-metrics-for-version=1.n` 커맨드 라인에 의해서 생성될 수 있다.
* `1.n+1` 릴리스에서는 기본적으로 메트릭이 숨겨져 있으며,
`show-hidden-metrics-for-version=1.n` 커맨드 라인에 의해서 생성될 수 있다.
* `1.n+2` 릴리스에서는 코드베이스에서 메트릭이 제거되어야 한다. 더이상 임시방편은 존재하지 않는다.
릴리스 `1.12` 에서 `1.13` 으로 업그레이드 중이지만, `1.12` 에서 사용 중단된 메트릭 `A` 를 사용하고 있다면, 커맨드 라인에서 `--show-hidden-metrics=1.12` 플래그로 히든 메트릭을 설정해야 하고, `1.14` 로 업그레이드하기 전에 이 메트릭을 사용하지 않도록 의존성을 제거하는 것을 기억해야 한다.
릴리스 `1.12` 에서 `1.13` 으로 업그레이드 중이지만, `1.12` 에서 사용 중단된 메트릭 `A` 를 사용하고 있다면,
커맨드 라인에서 `--show-hidden-metrics=1.12` 플래그로 히든 메트릭을 설정해야 하고,
`1.14` 로 업그레이드하기 전에 이 메트릭을 사용하지 않도록 의존성을 제거하는 것을 기억해야 한다.
## 액셀러레이터 메트릭 비활성화
kubelet은 cAdvisor를 통해 액셀러레이터 메트릭을 수집한다. NVIDIA GPU와 같은 액셀러레이터의 경우, 이러한 메트릭을 수집하기 위해 kubelet은 드라이버에 열린 핸들을 가진다. 이는 인프라 변경(예: 드라이버 업데이트)을 수행하기 위해 클러스터 관리자가 kubelet 에이전트를 중지해야 함을 의미한다.
kubelet은 cAdvisor를 통해 액셀러레이터 메트릭을 수집한다. 이러한 메트릭을 수집하기 위해,
NVIDIA GPU와 같은 액셀러레이터의 경우, kubelet은 드라이버에 열린 핸들을 가진다.
이는 인프라 변경(예: 드라이버 업데이트)을 수행하기 위해,
클러스터 관리자가 kubelet 에이전트를 중지해야 함을 의미한다.
액셀러레이터 메트릭을 수집하는 책임은 이제 kubelet이 아닌 공급 업체에 있다. 공급 업체는 메트릭을 수집하여 메트릭 서비스(예: 프로메테우스)에 노출할 컨테이너를 제공해야 한다.
액셀러레이터 메트릭을 수집하는 책임은 이제 kubelet이 아닌 공급 업체에 있다.
공급 업체는 메트릭을 수집하여 메트릭 서비스(예: 프로메테우스)에 노출할
컨테이너를 제공해야 한다.
[`DisableAcceleratorUsageMetrics` 기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/#알파-또는-베타-기능을-위한-기능-게이트:~:text= DisableAcceleratorUsageMetrics,-false)는 [이 기능을 기본적으로 사용하도록 설정하는 타임라인](https://github.com/kubernetes/enhancements/tree/411e51027db842355bd489691af897afc1a41a5e/keps/sig-node/1867-disable-accelerator-usage-metrics#graduation-criteria)를 사용하여 kubelet에서 수집한 메트릭을 비활성화한다.
[`DisableAcceleratorUsageMetrics` 기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/#알파-또는-베타-기능을-위한-기능-게이트:~:text=DisableAcceleratorUsageMetrics,-false)는
[이 기능을 기본적으로 사용하도록 설정하는 타임라인](https://github.com/kubernetes/enhancements/tree/411e51027db842355bd489691af897afc1a41a5e/keps/sig-node/1867-disable-accelerator-usage-metrics#graduation-criteria)를
사용하여 kubelet에서 수집한 메트릭을 비활성화한다.
## 컴포넌트 메트릭
@ -117,7 +143,8 @@ kubelet은 cAdvisor를 통해 액셀러레이터 메트릭을 수집한다. NVID
etcd 요청 대기 시간 또는 Cloudprovider(AWS, GCE, OpenStack) API 대기 시간과 같은 컨트롤러 특정 메트릭이 포함되어
클러스터의 상태를 측정하는 데 사용할 수 있다.
쿠버네티스 1.7부터 GCE, AWS, Vsphere 및 OpenStack의 스토리지 운영에 대한 상세한 Cloudprovider 메트릭을 사용할 수 있다.
쿠버네티스 1.7부터 GCE, AWS, Vsphere 및 OpenStack의 스토리지 운영에 대한
상세한 Cloudprovider 메트릭을 사용할 수 있다.
이 메트릭은 퍼시스턴트 볼륨 동작의 상태를 모니터링하는 데 사용할 수 있다.
예를 들어, GCE의 경우 이러한 메트릭을 다음과 같이 호출한다.
@ -136,9 +163,15 @@ cloudprovider_gce_api_request_duration_seconds { request = "list_disk"}
{{< feature-state for_k8s_version="v1.21" state="beta" >}}
스케줄러는 실행 중인 모든 파드의 요청(request)된 리소스와 요구되는 제한(limit)을 보고하는 선택적 메트릭을 노출한다. 이러한 메트릭은 용량 계획(capacity planning) 대시보드를 구축하고, 현재 또는 과거 스케줄링 제한을 평가하고, 리소스 부족으로 스케줄할 수 없는 워크로드를 빠르게 식별하고, 실제 사용량을 파드의 요청과 비교하는 데 사용할 수 있다.
스케줄러는 실행 중인 모든 파드의 요청(request)된 리소스와 요구되는 제한(limit)을 보고하는 선택적 메트릭을 노출한다.
이러한 메트릭은 용량 계획(capacity planning) 대시보드를 구축하고,
현재 또는 과거 스케줄링 제한을 평가하고, 리소스 부족으로 스케줄할 수 없는 워크로드를 빠르게 식별하고,
실제 사용량을 파드의 요청과 비교하는 데 사용할 수 있다.
kube-scheduler는 각 파드에 대해 구성된 리소스 [요청과 제한](/ko/docs/concepts/configuration/manage-resources-containers/)을 식별한다.
요청 또는 제한이 0이 아닌 경우 kube-scheduler는 메트릭 시계열을 보고한다.
시계열에는 다음과 같은 레이블이 지정된다.
kube-scheduler는 각 파드에 대해 구성된 리소스 [요청과 제한](/ko/docs/concepts/configuration/manage-resources-containers/)을 식별한다. 요청 또는 제한이 0이 아닌 경우 kube-scheduler는 메트릭 시계열을 보고한다. 시계열에는 다음과 같은 레이블이 지정된다.
- 네임스페이스
- 파드 이름
- 파드가 스케줄된 노드 또는 아직 스케줄되지 않은 경우 빈 문자열
@ -147,32 +180,46 @@ kube-scheduler는 각 파드에 대해 구성된 리소스 [요청과 제한](/k
- 리소스 이름 (예: `cpu`)
- 알려진 경우 리소스 단위 (예: `cores`)
파드가 완료되면 (`Never` 또는 `OnFailure`의 `restartPolicy`가 있고 `Succeeded` 또는 `Failed` 파드 단계에 있거나, 삭제되고 모든 컨테이너가 종료된 상태에 있음) 스케줄러가 이제 다른 파드를 실행하도록 스케줄할 수 있으므로 시리즈가 더 이상 보고되지 않는다. 두 메트릭을 `kube_pod_resource_request` 및 `kube_pod_resource_limit` 라고 한다.
파드가 완료되면 (`Never` 또는 `OnFailure`의 `restartPolicy`가 있고
`Succeeded` 또는 `Failed` 파드 단계에 있거나, 삭제되고 모든 컨테이너가 종료된 상태에 있음)
스케줄러가 이제 다른 파드를 실행하도록 스케줄할 수 있으므로 시리즈가 더 이상 보고되지 않는다.
두 메트릭을 `kube_pod_resource_request` 및 `kube_pod_resource_limit` 라고 한다.
메트릭은 HTTP 엔드포인트 `/metrics/resources`에 노출되며 스케줄러의 `/metrics` 엔드포인트
와 동일한 인증이 필요하다. 이러한 알파 수준의 메트릭을 노출시키려면 `--show-hidden-metrics-for-version=1.20` 플래그를 사용해야 한다.
메트릭은 HTTP 엔드포인트 `/metrics/resources`에 노출되며
스케줄러의 `/metrics` 엔드포인트와 동일한 인증이 필요하다.
이러한 알파 수준의 메트릭을 노출시키려면 `--show-hidden-metrics-for-version=1.20` 플래그를 사용해야 한다.
## 메트릭 비활성화
커맨드 라인 플래그 `--disabled-metrics` 를 통해 메트릭을 명시적으로 끌 수 있다. 이 방법이 필요한 이유는 메트릭이 성능 문제를 일으키는 경우을 예로 들 수 있다. 입력값은 비활성화되는 메트릭 목록이다(예: `--disabled-metrics=metric1,metric2`).
커맨드 라인 플래그 `--disabled-metrics` 를 통해 메트릭을 명시적으로 끌 수 있다.
이 방법이 필요한 이유는 메트릭이 성능 문제를 일으키는 경우을 예로 들 수 있다.
입력값은 비활성화되는 메트릭 목록이다(예: `--disabled-metrics=metric1,metric2`).
## 메트릭 카디널리티(cardinality) 적용
제한되지 않은 차원의 메트릭은 계측하는 컴포넌트에서 메모리 문제를 일으킬 수 있다. 리소스 사용을 제한하려면, `--allow-label-value` 커맨드 라인 옵션을 사용하여 메트릭 항목에 대한 레이블 값의 허용 목록(allow-list)을 동적으로 구성한다.
제한되지 않은 차원의 메트릭은 계측하는 컴포넌트에서 메모리 문제를 일으킬 수 있다.
리소스 사용을 제한하려면, `--allow-label-value` 커맨드 라인 옵션을 사용하여
메트릭 항목에 대한 레이블 값의 허용 목록(allow-list)을 동적으로 구성한다.
알파 단계에서, 플래그는 메트릭 레이블 허용 목록으로 일련의 매핑만 가져올 수 있다.
각 매핑은 `<metric_name>,<label_name>=<allowed_labels>` 형식이다. 여기서
`<allowed_labels>` 는 허용되는 레이블 이름의 쉼표로 구분된 목록이다.
전체 형식은 다음과 같다.
`--allow-label-value <metric_name>,<label_name>='<allow_value1>, <allow_value2>...', <metric_name2>,<label_name>='<allow_value1>, <allow_value2>...', ...`.
```
--allow-label-value <metric_name>,<label_name>='<allow_value1>, <allow_value2>...', <metric_name2>,<label_name>='<allow_value1>, <allow_value2>...', ...
```
예시는 다음과 같다.
`--allow-label-value number_count_metric,odd_number='1,3,5', number_count_metric,even_number='2,4,6', date_gauge_metric,weekend='Saturday,Sunday'`
```none
--allow-label-value number_count_metric,odd_number='1,3,5', number_count_metric,even_number='2,4,6', date_gauge_metric,weekend='Saturday,Sunday'
```
## {{% heading "whatsnext" %}}
* 메트릭에 대한 [프로메테우스 텍스트 형식](https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md#text-based-format)에 대해 읽어본다
* 메트릭에 대한 [프로메테우스 텍스트 형식](https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md#text-based-format)
에 대해 읽어본다
* [안정 버전의 쿠버네티스 메트릭](https://github.com/kubernetes/kubernetes/blob/master/test/instrumentation/testdata/stable-metrics-list.yaml) 목록을 살펴본다
* [쿠버네티스 사용 중단 정책](/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior)에 대해 읽어본다
* [쿠버네티스 사용 중단 정책](/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior)에 대해 읽어본다

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

@ -4,7 +4,7 @@ title: 쿠버네티스 시스템 컴포넌트에 대한 추적(trace)
# - logicalhan
# - lilic
content_type: concept
weight: 60
weight: 90
---
<!-- overview -->

41
content/ko/docs/concepts/configuration/configmap.md
View File

@ -111,46 +111,7 @@ data:
다음은 `game-demo` 의 값을 사용하여 파드를 구성하는 파드 예시이다.
```yaml
apiVersion: v1
kind: Pod
metadata:
name: configmap-demo-pod
spec:
containers:
- name: demo
image: alpine
command: ["sleep", "3600"]
env:
# 환경 변수 정의
- name: PLAYER_INITIAL_LIVES # 참고로 여기서는 컨피그맵의 키 이름과
# 대소문자가 다르다.
valueFrom:
configMapKeyRef:
name: game-demo # 이 값의 컨피그맵.
key: player_initial_lives # 가져올 키.
- name: UI_PROPERTIES_FILE_NAME
valueFrom:
configMapKeyRef:
name: game-demo
key: ui_properties_file_name
volumeMounts:
- name: config
mountPath: "/config"
readOnly: true
volumes:
# 파드 레벨에서 볼륨을 설정한 다음, 해당 파드 내의 컨테이너에 마운트한다.
- name: config
configMap:
# 마운트하려는 컨피그맵의 이름을 제공한다.
name: game-demo
# 컨피그맵에서 파일로 생성할 키 배열
items:
- key: "game.properties"
path: "game.properties"
- key: "user-interface.properties"
path: "user-interface.properties"
```
{{< codenew file="configmap/configure-pod.yaml" >}}
컨피그맵은 단일 라인 속성(single line property) 값과 멀티 라인의 파일과 비슷한(multi-line file-like) 값을
구분하지 않는다.

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

@ -317,6 +317,10 @@ kubelet은 로컬 임시 스토리지가 아닌 컨테이너 메모리 사용으
`tmpfs` emptyDir 볼륨을 추적한다.
{{< /note >}}
{{< note >}}
kubelet은 임시 스토리지을 위해 오직 루트 파일시스템만을 추적한다. `/var/lib/kubelet` 혹은 `/var/lib/containers`에 대해 별도의 디스크를 마운트하는 OS 레이아웃은 임시 스토리지를 정확하게 보고하지 않을 것이다.
{{< /note >}}
### 로컬 임시 스토리지에 대한 요청 및 제한 설정
`ephemeral-storage`를 명시하여 로컬 임시 저장소를 관리할 수 있다.
@ -343,6 +347,7 @@ Ei, Pi, Ti, Gi, Mi, Ki와 같은 2의 거듭제곱을 사용할 수도 있다.
각 컨테이너에는 2GiB의 로컬 임시 스토리지 요청이 있다.
각 컨테이너에는 4GiB의 로컬 임시 스토리지 제한이 있다.
따라서, 파드는 4GiB의 로컬 임시 스토리지 요청과 8GiB 로컬 임시 스토리지 제한을 가진다.
이 제한 중 500Mi까지는 `emptyDir` 볼륨에 의해 소진될 수 있다.
```yaml
apiVersion: v1
@ -373,7 +378,8 @@ spec:
mountPath: "/tmp"
volumes:
- name: ephemeral
emptyDir: {}
emptyDir:
sizeLimit: 500Mi
```
### `ephemeral-storage` 요청이 있는 파드의 스케줄링 방법
@ -796,7 +802,7 @@ Events:
## {{% heading "whatsnext" %}}
* [컨테이너와 파드에 메모리 리소스를 할당](/ko/docs/tasks/configure-pod-container/assign-memory-resource/)하는 핸즈온 경험을 해보자.
* [컨테이너와 파드에 CPU 리소스를 할당](/docs/tasks/configure-pod-container/assign-cpu-resource/)하는 핸즈온 경험을 해보자.
* [컨테이너와 파드에 CPU 리소스를 할당](/ko/docs/tasks/configure-pod-container/assign-cpu-resource/)하는 핸즈온 경험을 해보자.
* API 레퍼런스에 [컨테이너](/docs/reference/kubernetes-api/workload-resources/pod-v1/#Container)와
[컨테이너 리소스 요구사항](/docs/reference/kubernetes-api/workload-resources/pod-v1/#resources)이 어떻게 정의되어 있는지 확인한다.
* XFS의 [프로젝트 쿼터](https://xfs.org/index.php/XFS_FAQ#Q:_Quota:_Do_quotas_work_on_XFS.3F)에 대해 읽어보기

109
content/ko/docs/concepts/configuration/overview.md
View File

@ -7,76 +7,131 @@ weight: 10
---
<!-- overview -->
이 문서는 사용자 가이드, 시작하기 문서 및 예제들에 걸쳐 소개된 구성 모범 사례를 강조하고 통합한다.
이 문서는 지속적으로 변경 가능하다. 이 목록에 없지만 다른 사람들에게 유용할 것 같은 무엇인가를 생각하고 있다면, 새로운 이슈를 생성하거나 풀 리퀘스트를 제출하는 것을 망설이지 말기를 바란다.
이 문서는 사용자 가이드, 시작하기 문서 및 예제들에 걸쳐 소개된
구성 모범 사례를 강조하고 통합한다.
이 문서는 지속적으로 변경 가능하다. 이 목록에 없지만 다른 사람들에게 유용할 것 같은 무엇인가를 생각하고 있다면,
새로운 이슈를 생성하거나 풀 리퀘스트를 제출하는 것을 망설이지 말기를 바란다.
<!-- body -->
## 일반적인 구성 팁
- 구성을 정의할 때, 안정된 최신 API 버전을 명시한다.
- 구성 파일들은 클러스터에 적용되기 전에 버전 컨트롤에 저장되어 있어야 한다. 이는 만약 필요하다면 구성의 변경 사항을 빠르게 되돌릴 수 있도록 해준다. 이는 또한 클러스터의 재-생성과 복원을 도와준다.
- 구성 파일들은 클러스터에 적용되기 전에 버전 컨트롤에 저장되어 있어야 한다. 이는 만약 필요하다면
구성의 변경 사항을 빠르게 되돌릴 수 있도록 해준다. 이는 또한 클러스터의
재-생성과 복원을 도와준다.
- JSON보다는 YAML을 사용해 구성 파일을 작성한다. 비록 이러한 포맷들은 대부분의 모든 상황에서 통용되어 사용될 수 있지만, YAML이 좀 더 사용자 친화적인 성향을 가진다.
- JSON보다는 YAML을 사용해 구성 파일을 작성한다. 비록 이러한 포맷들은 대부분의 모든 상황에서 통용되어 사용될 수 있지만,
YAML이 좀 더 사용자 친화적인 성향을 가진다.
- 의미상 맞다면 가능한 연관된 오브젝트들을 하나의 파일에 모아 놓는다. 때로는 여러 개의 파일보다 하나의 파일이 더 관리하기 쉽다. 이 문법의 예시로서 [guestbook-all-in-one.yaml](https://github.com/kubernetes/examples/tree/master/guestbook/all-in-one/guestbook-all-in-one.yaml) 파일을 참고한다.
- 의미상 맞다면 가능한 연관된 오브젝트들을 하나의 파일에 모아 놓는다.
때로는 여러 개의 파일보다 하나의 파일이 더 관리하기 쉽다. 이 문법의 예시로서
[guestbook-all-in-one.yaml](https://github.com/kubernetes/examples/tree/master/guestbook/all-in-one/guestbook-all-in-one.yaml)
파일을 참고한다.
- 많은 `kubectl` 커맨드들은 디렉터리에 대해 호출될 수 있다. 예를 들어, 구성 파일들의 디렉터리에 대해 `kubectl apply`를 호출할 수 있다.
- 많은 `kubectl` 커맨드들은 디렉터리에 대해 호출될 수 있다. 예를 들어,
구성 파일들의 디렉터리에 대해 `kubectl apply`를 호출할 수 있다.
- 불필요하게 기본 값을 명시하지 않는다. 간단하고 최소한의 설정은 에러를 덜 발생시킨다.
- 더 나은 인트로스펙션(introspection)을 위해서, 어노테이션에 오브젝트의 설명을 넣는다.
## "단독(Naked)" 파드 vs 레플리카셋(ReplicaSet), 디플로이먼트(Deployment), 그리고 잡(Job) {#naked-pods-vs-replicasets-deployments-and-jobs}
- 가능하다면 단독 파드(즉, [레플리카셋](/ko/docs/concepts/workloads/controllers/replicaset/)이나 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)에 연결되지 않은 파드)를 사용하지 않는다. 단독 파드는 노드 장애 이벤트가 발생해도 다시 스케줄링되지 않는다.
명백하게 [`restartPolicy: Never`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#재시작-정책)를 사용하는 상황을 제외한다면, 의도한 파드의 수가 항상 사용 가능한 상태를 유지하는 레플리카셋을 생성하고, 파드를 교체하는 전략([롤링 업데이트](/ko/docs/concepts/workloads/controllers/deployment/#디플로이먼트-롤링-업데이트)와 같은)을 명시하는 디플로이먼트는 파드를 직접 생성하기 위해 항상 선호되는 방법이다. [잡](/ko/docs/concepts/workloads/controllers/job/) 또한 적절할 수 있다.
- 가능하다면 단독 파드(즉, [레플리카셋](/ko/docs/concepts/workloads/controllers/replicaset/)이나
[디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)에 연결되지 않은 파드)를 사용하지 않는다.
단독 파드는 노드 장애 이벤트가 발생해도 다시 스케줄링되지 않는다.
명시적으로 [`restartPolicy: Never`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)를
사용하는 상황을 제외한다면, 의도한 파드의 수가 항상 사용 가능한 상태를 유지하는 레플리카셋을 생성하고,
([롤링 업데이트](/ko/docs/concepts/workloads/controllers/deployment/#디플로이먼트-롤링-업데이트)와 같이)
파드를 교체하는 전략을 명시하는 디플로이먼트는
파드를 직접 생성하기 위해 항상 선호되는 방법이다.
[잡](/ko/docs/concepts/workloads/controllers/job/) 또한 적절할 수 있다.
## 서비스
- 서비스에 대응하는 백엔드 워크로드(디플로이먼트 또는 레플리카셋) 또는 서비스 접근이 필요한 어떠한 워크로드를 생성하기 전에 [서비스](/ko/docs/concepts/services-networking/service/)를 미리 생성한다. 쿠버네티스가 컨테이너를 시작할 때, 쿠버네티스는 컨테이너 시작 당시에 생성되어 있는 모든 서비스를 가리키는 환경 변수를 컨테이너에 제공한다. 예를 들어, `foo` 라는 이름의 서비스가 존재한다면, 모든 컨테이너들은 초기 환경에서 다음의 변수들을 얻을 것이다.
- 서비스에 대응하는 백엔드 워크로드(디플로이먼트 또는 레플리카셋) 또는 서비스 접근이 필요한 어떠한 워크로드를 생성하기 전에
[서비스](/ko/docs/concepts/services-networking/service/)를 미리 생성한다. 쿠버네티스가 컨테이너를 시작할 때,
쿠버네티스는 컨테이너 시작 당시에 생성되어 있는 모든 서비스를 가리키는 환경 변수를 컨테이너에 제공한다.
예를 들어, `foo` 라는 이름의 서비스가 존재한다면,
모든 컨테이너들은 초기 환경에서 다음의 변수들을 얻을 것이다.
```shell
FOO_SERVICE_HOST=<서비스가 동작 중인 호스트>
FOO_SERVICE_PORT=<서비스가 동작 중인 포트>
```
*이는 순서를 정하는 일이 요구됨을 암시한다* - `파드`가 접근하기를 원하는 어떠한 `서비스`는 `파드` 스스로가 생성되기 전에 미리 생성되어 있어야 하며, 그렇지 않으면 환경 변수가 설정되지 않을 것이다. DNS는 이러한 제한을 가지고 있지 않다.
*이는 순서를 정하는 일이 요구됨을 암시한다* - `파드`가 접근하기를 원하는 어떠한 `서비스`는 `파드`
스스로가 생성되기 전에 미리 생성되어 있어야 하며, 그렇지 않으면 환경 변수가 설정되지 않을 것이다.
DNS는 이러한 제한을 가지고 있지 않다.
- 선택적인(그렇지만 매우 권장되는) [클러스터 애드온](/ko/docs/concepts/cluster-administration/addons/)은 DNS 서버이다.
DNS 서버는 새로운 `서비스`를 위한 쿠버네티스 API를 Watch하며, 각 서비스를 위한 DNS 레코드 셋을 생성한다. 만약 DNS가 클러스터에 걸쳐 활성화되어 있다면, 모든 `파드`는 `서비스`의 이름을 자동으로 해석할 수 있어야 한다.
- 선택적인(그렇지만 매우 권장되는) [클러스터 애드온](/ko/docs/concepts/cluster-administration/addons/)은
DNS 서버이다. DNS 서버는 새로운 `서비스`를 위한 쿠버네티스 API를 Watch하며, 각 서비스를 위한 DNS 레코드 셋을 생성한다.
만약 DNS가 클러스터에 걸쳐 활성화되어 있다면,
모든 `파드`는 `서비스`의 이름을 자동으로 해석할 수 있어야 한다.
- 반드시 필요한 것이 아니라면 파드에 `hostPort` 를 명시하지 않는다. <`hostIP`, `hostPort`, `protocol`> 조합은 유일해야 하기 때문에, `hostPort`로 바인드하는 것은 파드가 스케줄링될 수 있는 위치의 개수를 제한한다. 만약 `hostIP`와 `protocol`을 뚜렷히 명시하지 않으면, 쿠버네티스는 `hostIP`의 기본 값으로 `0.0.0.0`를, `protocol`의 기본 값으로 `TCP`를 사용한다.
- 반드시 필요한 것이 아니라면 파드에 `hostPort` 를 명시하지 않는다. <`hostIP`, `hostPort`, `protocol`> 조합은
유일해야 하기 때문에, `hostPort`로 바인드하는 것은 파드가 스케줄링될 수 있는 위치의 개수를 제한한다.
만약 `hostIP`와 `protocol`을 뚜렷히 명시하지 않으면,
쿠버네티스는 `hostIP`의 기본 값으로 `0.0.0.0`를,
`protocol`의 기본 값으로 `TCP`를 사용한다.
만약 오직 디버깅의 목적으로 포트에 접근해야 한다면, [apiserver proxy](/ko/docs/tasks/access-application-cluster/access-cluster/#수작업으로-apiserver-proxy-url을-구축) 또는 [`kubectl port-forward`](/ko/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)를 사용할 수 있다.
만약 오직 디버깅의 목적으로 포트에 접근해야 한다면,
[apiserver proxy](/ko/docs/tasks/access-application-cluster/access-cluster/#수작업으로-apiserver-proxy-url을-구축)
또는 [`kubectl port-forward`](/ko/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)를 사용할 수 있다.
만약 파드의 포트를 노드에서 명시적으로 노출해야 한다면, `hostPort`에 의존하기 전에 [NodePort](/ko/docs/concepts/services-networking/service/#type-nodeport) 서비스를 사용하는 것을 고려할 수 있다.
만약 파드의 포트를 노드에서 명시적으로 노출해야 한다면, `hostPort`에 의존하기 전에
[NodePort](/ko/docs/concepts/services-networking/service/#type-nodeport)
서비스를 사용하는 것을 고려할 수 있다.
- `hostPort`와 같은 이유로, `hostNetwork`를 사용하는 것을 피한다.
- `kube-proxy` 로드 밸런싱이 필요하지 않을 때, 서비스 발견을 위해 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)(`ClusterIP`의 값을 `None`으로 가지는)를 사용한다.
- `kube-proxy` 로드 밸런싱이 필요하지 않을 때, 서비스 발견을 위해
[헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)(`ClusterIP`의
값을 `None`으로 가지는)를 사용한다.
## 레이블 사용하기
- `{ app.kubernetes.io/name: MyApp, tier: frontend, phase: test, deployment: v3 }`처럼 애플리케이션이나 디플로이먼트의 __속성에 대한 의미__ 를 식별하는 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)을 정의해 사용한다. 다른 리소스를 위해 적절한 파드를 선택하는 용도로 이러한 레이블을 이용할 수 있다. 예를 들어, 모든 `tier: frontend` 파드를 선택하거나, `app.kubernetes.io/name: MyApp`의 모든 `phase: test` 컴포넌트를 선택하는 서비스를 생각해 볼 수 있다. 이 접근 방법의 예시는 [방명록](https://github.com/kubernetes/examples/tree/master/guestbook/) 앱을 참고한다.
- `{ app.kubernetes.io/name: MyApp, tier: frontend, phase: test, deployment: v3 }`처럼
애플리케이션이나 디플로이먼트의 __속성에 대한 의미__ 를 식별하는
[레이블](/ko/docs/concepts/overview/working-with-objects/labels/)을 정의해 사용한다.
다른 리소스를 위해 적절한 파드를 선택하는 용도로 이러한 레이블을 이용할 수 있다.
예를 들어, 모든 `tier: frontend` 파드를 선택하거나, `app.kubernetes.io/name: MyApp`의
모든 `phase: test` 컴포넌트를 선택하는 서비스를 생각해 볼 수 있다.
이 접근 방법의 예시는 [방명록](https://github.com/kubernetes/examples/tree/master/guestbook/) 앱을 참고한다.
릴리스에 특정되는 레이블을 서비스의 셀렉터에서 생략함으로써 여러 개의 디플로이먼트에 걸치는 서비스를 생성할 수 있다. 동작 중인 서비스를 다운타임 없이 갱신하려면, [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)를 사용한다.
릴리스에 특정되는 레이블을 서비스의 셀렉터에서 생략함으로써 여러 개의 디플로이먼트에 걸치는 서비스를
생성할 수 있다. 동작 중인 서비스를 다운타임 없이 갱신하려면,
[디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)를 사용한다.
오브젝트의 의도한 상태는 디플로이먼트에 의해 기술되며, 만약 그 스펙에 대한 변화가 _적용될_ 경우, 디플로이먼트 컨트롤러는 일정한 비율로 실제 상태를 의도한 상태로 변화시킨다.
오브젝트의 의도한 상태는 디플로이먼트에 의해 기술되며, 만약 그 스펙에 대한 변화가
_적용될_ 경우, 디플로이먼트 컨트롤러는
일정한 비율로 실제 상태를 의도한 상태로 변화시킨다.
- 일반적인 활용 사례인 경우 [쿠버네티스 공통 레이블](/ko/docs/concepts/overview/working-with-objects/common-labels/)을 사용한다. 이 표준화된 레이블은 `kubectl` 및 [대시보드](/ko/docs/tasks/access-application-cluster/web-ui-dashboard)와 같은 도구들이 상호 운용이 가능한 방식으로 동작할 수 있도록 메타데이터를 향상시킨다.
- 일반적인 활용 사례인 경우 [쿠버네티스 공통 레이블](/ko/docs/concepts/overview/working-with-objects/common-labels/)을
사용한다. 이 표준화된 레이블은 `kubectl` 및
[대시보드](/ko/docs/tasks/access-application-cluster/web-ui-dashboard)와
같은 도구들이 상호 운용이 가능한 방식으로 동작할 수 있도록 메타데이터를 향상시킨다.
- 디버깅을 위해 레이블을 조작할 수 있다. (레플리카셋과 같은) 쿠버네티스 컨트롤러와 서비스는 셀렉터 레이블을 사용해 파드를 선택하기 때문에, 관련된 레이블을 파드에서 삭제하는 것은 컨트롤러로부터 관리되거나 서비스로부터 트래픽을 전달받는 것을 중단시킨다. 만약 이미 존재하는 파드의 레이블을 삭제한다면, 파드의 컨트롤러는 그 자리를 대신할 새로운 파드를 생성한다. 이것은 이전에 "살아 있는" 파드를 "격리된" 환경에서 디버그할 수 있는 유용한 방법이다. 레이블을 상호적으로 추가하고 삭제하기 위해서, [`kubectl label`](/docs/reference/generated/kubectl/kubectl-commands#label)를 사용할 수 있다.
- 디버깅을 위해 레이블을 조작할 수 있다. (레플리카셋과 같은) 쿠버네티스 컨트롤러와 서비스는
셀렉터 레이블을 사용해 파드를 선택하기 때문에,
관련된 레이블을 파드에서 삭제하는 것은 컨트롤러로부터 관리되거나 서비스로부터 트래픽을 전달받는 것을 중단시킨다.
만약 이미 존재하는 파드의 레이블을 삭제한다면, 파드의 컨트롤러는 그 자리를 대신할 새로운 파드를 생성한다. 이것은 이전에
"살아 있는" 파드를 "격리된" 환경에서 디버그할 수 있는 유용한 방법이다. 레이블을 상호적으로 추가하고 삭제하기 위해서,
[`kubectl label`](/docs/reference/generated/kubectl/kubectl-commands#label)를 사용할 수 있다.
## kubectl 사용하기
- `kubectl apply -f <디렉터리>`를 사용한다. 이 명령어는 `<디렉터리>` 내부의 모든 `.yaml`, `.yml`, 그리고 `.json` 쿠버네티스 구성 파일을 찾아 `apply`에 전달한다.
- `kubectl apply -f <디렉터리>`를 사용한다. 이 명령어는 `<디렉터리>` 내부의 모든 `.yaml`, `.yml`,
그리고 `.json` 쿠버네티스 구성 파일을 찾아 `apply`에 전달한다.
- `get`과 `delete` 동작을 위해 특정 오브젝트의 이름 대신 레이블 셀렉터를 사용한다. [레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/#레이블-셀렉터)와 [효율적으로 레이블 사용하기](/ko/docs/concepts/cluster-administration/manage-deployment/#효과적인-레이블-사용)를 참고할 수 있다.
- `get`과 `delete` 동작을 위해 특정 오브젝트의 이름 대신 레이블 셀렉터를 사용한다.
[레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/#레이블-셀렉터)와
[효율적으로 레이블 사용하기](/ko/docs/concepts/cluster-administration/manage-deployment/#효과적인-레이블-사용)를
참고할 수 있다.
- 단일 컨테이너로 구성된 디플로이먼트와 서비스를 빠르게 생성하기 위해 `kubectl create deployment` 와 `kubectl expose` 를 사용한다. [클러스터 내부의 애플리케이션에 접근하기 위한 서비스 사용](/ko/docs/tasks/access-application-cluster/service-access-application-cluster/)에서 예시를 확인할 수 있다.
- 단일 컨테이너로 구성된 디플로이먼트와 서비스를 빠르게 생성하기 위해 `kubectl create deployment` 와 `kubectl expose` 를 사용한다.
[클러스터 내부의 애플리케이션에 접근하기 위한 서비스 사용](/ko/docs/tasks/access-application-cluster/service-access-application-cluster/)에서
예시를 확인할 수 있다.

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

@ -30,17 +30,22 @@ weight: 30
특별히 기밀 데이터를 보관하기 위한 것이다.
{{< caution >}}
쿠버네티스 시크릿은 기본적으로 API 서버의 기본 데이터 저장소(etcd)에 암호화되지 않은 상태로 저장된다. API 접근(access) 권한이 있는 모든 사용자 또는 etcd에 접근할 수 있는 모든 사용자는 시크릿을 조회하거나 수정할 수 있다.
또한 네임스페이스에서 파드를 생성할 권한이 있는 사람은 누구나 해당 접근을 사용하여 해당 네임스페이스의 모든 시크릿을 읽을 수 있다. 여기에는 디플로이먼트 생성 기능과 같은 간접 접근이 포함된다.
쿠버네티스 시크릿은 기본적으로 API 서버의 기본 데이터 저장소(etcd)에 암호화되지 않은 상태로 저장된다.
API 접근(access) 권한이 있는 모든 사용자 또는 etcd에 접근할 수 있는 모든 사용자는 시크릿을 조회하거나 수정할 수 있다.
또한 네임스페이스에서 파드를 생성할 권한이 있는 사람은 누구나
해당 접근을 사용하여 해당 네임스페이스의 모든 시크릿을 읽을 수 있다.
여기에는 디플로이먼트 생성 기능과 같은 간접 접근이 포함된다.
시크릿을 안전하게 사용하려면 최소한 다음의 단계를 따르는 것이 좋다.
1. 시크릿에 대해 [저장된 데이터 암호화(Encryption at Rest)를 활성화](/docs/tasks/administer-cluster/encrypt-data/)한다.
1. 시크릿 읽기 및 쓰기를 제한하는
[RBAC 규칙을 활성화 또는 구성](/ko/docs/reference/access-authn-authz/authorization/)한다.
파드 생성 권한을 가진 사람은 암묵적으로 시크릿에 접근할 수 있음에 주의한다.
1. 적절한 경우, RBAC과 같은 메커니즘을 사용하여 새로운 시크릿을 생성하거나
기존 시크릿을 대체할 수 있는 주체(principal)들을 제한한다.
1. 시크릿에 대한 최소한의 접근 권한을 지니도록
[RBAC 규칙을 활성화 또는 구성](/ko/docs/reference/access-authn-authz/authorization/)한다.
1. 특정 컨테이너에서만 시크릿에 접근하도록 한다.
1. [외부 시크릿 저장소 제공 서비스를 사용하는 것을 고려](https://secrets-store-csi-driver.sigs.k8s.io/concepts.html#provider-for-the-secrets-store-csi-driver)한다.
시크릿의 보안성을 높이고 관리하는 데에 관한 가이드라인은
[쿠버네티스 시크릿에 관한 좋은 관행](/ko/docs/concepts/security/secrets-good-practices/)를 참고한다.
{{< /caution >}}
@ -96,9 +101,9 @@ weight: 30
시크릿 생성에는 다음과 같은 방법이 있다.
- [`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/)
- [`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/)
#### 시크릿 이름 및 데이터에 대한 제약 사항 {#restriction-names-data}
@ -125,43 +130,20 @@ weight: 30
[리소스 쿼터](/ko/docs/concepts/policy/resource-quotas/)를 사용하여
한 네임스페이스의 시크릿 (또는 다른 리소스) 수를 제한할 수 있다.
### 시크릿 편집하기
### 시크릿 수정하기
kubectl을 사용하여 기존 시크릿을 편집할 수 있다.
만들어진 시크릿은 [불변(immutable)](#secret-immutable)만 아니라면 수정될 수 있다.
시크릿 수정 방식은 다음과 같다.
```shell
kubectl edit secrets mysecret
```
* [`kubectl` 사용하기](/ko/docs/tasks/configmap-secret/managing-secret-using-kubectl/#edit-secret)
* [설정 파일 사용하기](/ko/docs/tasks/configmap-secret/managing-secret-using-config-file/#edit-secret)
이렇게 하면 기본으로 설정된 에디터가 열리며,
다음과 같이 `data` 필드에 base64로 인코딩된 시크릿 값을 업데이트할 수 있다.
[Kustomize 도구](/ko/docs/tasks/configmap-secret/managing-secret-using-kustomize/#edit-secret)로
시크릿 내부의 데이터를 수정하는 것도 가능하지만, 이 경우 수정된 데이터를 지닌 새로운 `Secret` 오브젝트가 생성된다.
```yaml
# 아래 오브젝트를 수정한다. '#'로 시작하는 줄은 무시되고,
# 빈 파일을 저장하면 편집이 취소된다. 이 파일을 저장하는 도중에 오류가 발생하면
# 관련 오류와 함께 파일이 다시 열릴 것이다.
#
apiVersion: v1
data:
username: YWRtaW4=
password: MWYyZDFlMmU2N2Rm
kind: Secret
metadata:
annotations:
kubectl.kubernetes.io/last-applied-configuration: { ... }
creationTimestamp: 2020-01-22T18:41:56Z
name: mysecret
namespace: default
resourceVersion: "164619"
uid: cfee02d6-c137-11e5-8d73-42010af00002
type: Opaque
```
위의 예시 매니페스트는 `data`에 `username` 및 `password` 2개의 키를 갖는 시크릿을 정의한다.
매니페스트에서 이 값들은 Base64 문자열이지만,
이 시크릿을 파드에 대해 사용할 때에는 kubelet이 파드와 컨테이너에 _디코드된_ 데이터를 제공한다.
한 시크릿에 여러 키 및 값을 넣을 수도 있고, 여러 시크릿으로 정의할 수도 있으며, 둘 중 편리한 쪽을 고르면 된다.
시크릿을 생성한 방법이나 파드에서 시크릿이 어떻게 사용되는지에 따라,
존재하는 `Secret` 오브젝트에 대한 수정은 해당 데이터를 사용하는 파드들에 자동으로 전파된다.
자세한 정보는 [마운트된 시크릿의 자동 업데이트](#마운트된-시크릿의-자동-업데이트)를 참고하라.
### 시크릿 사용하기
@ -202,9 +184,14 @@ kubelet은 또한 시크릿을 가져올 수 없는 문제에 대한 세부 정
이렇게 구성하려면, 다음을 수행한다.
1. 시크릿을 생성하거나 기존 시크릿을 사용한다. 여러 파드가 동일한 시크릿을 참조할 수 있다.
1. `.spec.volumes[].` 아래에 볼륨을 추가하려면 파드 정의를 수정한다. 볼륨의 이름을 뭐든지 지정하고, 시크릿 오브젝트의 이름과 동일한 `.spec.volumes[].secret.secretName` 필드를 생성한다.
1. 시크릿이 필요한 각 컨테이너에 `.spec.containers[].volumeMounts[]` 를 추가한다. 시크릿을 표시하려는 사용되지 않은 디렉터리 이름에 `.spec.containers[].volumeMounts[].readOnly = true` 와 `.spec.containers[].volumeMounts[].mountPath` 를 지정한다.
1. 프로그램이 해당 디렉터리에서 파일을 찾도록 이미지 또는 커맨드 라인을 수정한다. 시크릿 `data` 맵의 각 키는 `mountPath` 아래의 파일명이 된다.
1. `.spec.volumes[].` 아래에 볼륨을 추가하려면 파드 정의를 수정한다. 볼륨의 이름을 뭐든지 지정하고,
시크릿 오브젝트의 이름과 동일한 `.spec.volumes[].secret.secretName` 필드를 생성한다.
1. 시크릿이 필요한 각 컨테이너에 `.spec.containers[].volumeMounts[]` 를 추가한다.
시크릿을 표시하려는 사용되지 않은 디렉터리 이름에
`.spec.containers[].volumeMounts[].readOnly = true`와
`.spec.containers[].volumeMounts[].mountPath`를 지정한다.
1. 프로그램이 해당 디렉터리에서 파일을 찾도록 이미지 또는 커맨드 라인을 수정한다. 시크릿 `data` 맵의
각 키는 `mountPath` 아래의 파일명이 된다.
다음은 볼륨에 `mysecret`이라는 시크릿을 마운트하는 파드의 예시이다.
@ -320,11 +307,10 @@ spec:
시크릿이 `/etc/foo` 에 마운트되고,
시크릿 볼륨 마운트로 생성된 모든 파일의 퍼미션은 `0400` 이다.
{{< note >}}
JSON을 사용하여 파드 또는 파드 템플릿을 정의하는 경우,
JSON 스펙은 8진수 표기법을 지원하지 않음에 유의한다.
`defaultMode` 값으로 대신 10진수를 사용할 수 있다(예를 들어, 8진수 0400은 10진수로는 256이다).
JSON을 사용하여 파드 또는 파드 템플릿을 정의하는 경우,
JSON 스펙은 8진수 표기법을 지원하지 않음에 유의한다.
`defaultMode` 값으로 대신 10진수를 사용할 수 있다(예를 들어, 8진수 0400은 10진수로는 256이다).
YAML로 작성하는 경우, `defaultMode` 값을 8진수로 표기할 수 있다.
{{< /note >}}
@ -369,7 +355,7 @@ cat /etc/foo/password
컨테이너의 프로그램은 필요에 따라
이러한 파일에서 시크릿 데이터를 읽는다.
#### 마운트된 시크릿은 자동으로 업데이트됨
#### 마운트된 시크릿의 자동 업데이트
볼륨이 시크릿의 데이터를 포함하고 있는 상태에서 시크릿이 업데이트되면, 쿠버네티스는 이를 추적하고
최종적으로 일관된(eventually-consistent) 접근 방식을 사용하여 볼륨 안의 데이터를 업데이트한다.
@ -1186,7 +1172,7 @@ data:
- `token-secret`: 실제 토큰 시크릿으로 임의의 16개 문자의 문자열. 필수 사항.
- `description`: 토큰의 사용처를 설명하는 사람이 읽을 수 있는
문자열. 선택 사항.
- `expiration`: 토큰이 만료되어야 하는 시기를 명시한 RFC3339를
- `expiration`: 토큰이 만료되어야 하는 시기를 명시한 [RFC3339](https://datatracker.ietf.org/doc/html/rfc3339)를
사용하는 절대 UTC 시간. 선택 사항.
- `usage-bootstrap-<usage>`: 부트스트랩 토큰의 추가적인 사용처를 나타내는
불리언(boolean) 플래그.
@ -1218,22 +1204,23 @@ stringData:
```
## 수정 불가능한(immutable) 시크릿 {#secret-immutable}
## 불변(immutable) 시크릿 {#secret-immutable}
{{< feature-state for_k8s_version="v1.21" state="stable" >}}
쿠버네티스에서 특정 시크릿(및 컨피그맵)을 _수정 불가능_ 으로 표시할 수 있다.
쿠버네티스에서 특정 시크릿(및 컨피그맵)을 _불변_ 으로 표시할 수 있다.
기존 시크릿 데이터의 변경을 금지시키면 다음과 같은 이점을 가진다.
- 잘못된(또는 원치 않은) 업데이트를 차단하여 애플리케이션 중단을 방지
- (수만 개 이상의 시크릿-파드 마운트와 같이 시크릿을 대규모로 사용하는 클러스터의 경우,)
수정 불가능한 시크릿으로 전환하면 kube-apiserver의 부하를 크게 줄여 클러스터의 성능을 향상시킬 수 있다.
kubelet은 수정 불가능으로 지정된 시크릿에 대해서는
불변 시크릿으로 전환하면 kube-apiserver의 부하를 크게 줄여 클러스터의 성능을 향상시킬 수 있다.
kubelet은 불변으로 지정된 시크릿에 대해서는
[감시(watch)]를 유지할 필요가 없기 때문이다.
### 시크릿을 수정 불가능으로 지정하기 {#secret-immutable-create}
### 시크릿을 불변으로 지정하기 {#secret-immutable-create}
다음과 같이 시크릿의 `immutable` 필드를 `true`로 설정하여 불변 시크릿을 만들 수 있다.
다음과 같이 시크릿의 `immutable` 필드를 `true`로 설정하여 수정 불가능한 시크릿을 만들 수 있다.
```yaml
apiVersion: v1
kind: Secret
@ -1244,10 +1231,10 @@ data:
immutable: true
```
또한 기존의 수정 가능한 시크릿을 변경하여 수정 불가능한 시크릿으로 바꿀 수도 있다.
또한 기존의 수정 가능한 시크릿을 변경하여 불변 시크릿으로 바꿀 수도 있다.
{{< note >}}
시크릿 또는 컨피그맵이 수정 불가능으로 지정되면, 이 변경을 취소하거나 `data` 필드의 내용을 바꿀 수 _없다_.
시크릿 또는 컨피그맵이 불변으로 지정되면, 이 변경을 취소하거나 `data` 필드의 내용을 바꿀 수 _없다_.
시크릿을 삭제하고 다시 만드는 것만 가능하다.
기존의 파드는 삭제된 시크릿으로의 마운트 포인트를 유지하기 때문에,
이러한 파드는 재생성하는 것을 추천한다.
@ -1280,61 +1267,14 @@ kubelet은 시크릿에 있던 기밀 데이터의 로컬 복사본을 삭제한
따라서, 하나의 파드는 다른 파드의 시크릿에 접근할 수 없다.
{{< warning >}}
노드 상의 높은 권한을 갖는(privileged) 컨테이너는
해당 노드에 있는 모든 시크릿에 접근할 수 있다.
특정 노드에 대해 `privileged: true`가 설정되어 실행 중인 컨테이너들은 전부
해당 노드에서 사용 중인 모든 시크릿에 접근할 수 있다.
{{< /warning >}}
### 개발자를 위한 보안 추천 사항
- 애플리케이션은 환경 변수 또는 볼륨에서 기밀 정보를 읽은 뒤에 기밀 정보를 계속 보호해야 한다.
예를 들어, 애플리케이션은 비밀 데이터를 암호화되지 않은 상태로 기록하거나
신뢰할 수 없는 당사자에게 전송하지 말아야 한다.
- 파드에 여러 컨테이너가 있고,
그 중 한 컨테이너만 시크릿에 접근해야 하는 경우,
다른 컨테이너는 해당 시크릿에 접근할 수 없도록
볼륨 마운트 또는 환경 변수 구성을 적절히 정의한다.
- {{< glossary_tooltip text="매니페스트" term_id="manifest" >}}를 통해 시크릿을 구성하고,
이 안에 비밀 데이터가 base64로 인코딩된 경우,
이 파일을 공유하거나 소스 저장소에 올리면
해당 매니페스트를 읽을 수 있는 모든 사람이 이 비밀 정보를 볼 수 있음에 주의한다.
base64 인코딩은 암호화 수단이 _아니기 때문에_, 평문과 마찬가지로 기밀성을 제공하지 않는다.
- 시크릿 API와 통신하는 애플리케이션을 배포할 때,
[RBAC](/docs/reference/access-authn-authz/rbac/)과 같은
[인증 정책](/ko/docs/reference/access-authn-authz/authorization/)을 사용하여
접근을 제한해야 한다.
- 쿠버네티스 API에서, 네임스페이스 내 시크릿에 대한 `watch` 와 `list` 요청은 매우 강력한 기능이다.
시크릿 목록 조회를 가능하게 하면
클라이언트가 해당 네임스페이스에 있는 모든 시크릿의 값을 검사할 수도 있기 때문에
가능한 한 이러한 접근 권한을 주는 것은 피해야 한다.
### 클러스터 관리자를 위한 보안 추천 사항
{{< caution >}}
시크릿을 사용하는 파드를 생성할 수 있는 사용자는 해당 시크릿의 값을 볼 수도 있다.
클러스터 정책에서 사용자가 직접 시크릿을 조회하는 것을 금지했더라도,
동일한 사용자가 시크릿을 노출하는 파드에 접근 권한을 가질 수 있다.
{{< /caution >}}
- (쿠버네티스 API를 사용하여) 클러스터의 모든 시크릿을 감시(`watch`) 또는 나열(`list`)하는 권한을 제한하여,
가장 특권이 있는 시스템 레벨의 컴포넌트에만 이 동작을 허용한다.
- 시크릿 API와 통신하는 애플리케이션을 배포할 때,
[RBAC](/docs/reference/access-authn-authz/rbac/)과 같은
[인증 정책](/ko/docs/reference/access-authn-authz/authorization/)을 사용하여
접근을 제한해야 한다.
- API 서버에서, (시크릿을 포함한) 오브젝트는
{{< glossary_tooltip term_id="etcd" >}}에 저장된다. 그러므로
- 클러스터 관리자만 etcd에 접근할 수 있도록 한다(읽기 전용 접근 포함)
- 시크릿 오브젝트에 대해
[저장된 데이터 암호화(encryption at rest)](/docs/tasks/administer-cluster/encrypt-data/)를 활성화하여,
이러한 시크릿의 데이터가 {{< glossary_tooltip term_id="etcd" >}}에 암호화되지 않은 상태로 저장되지 않도록 한다.
- etcd가 동작하던 장기 저장 장치를 더 이상 사용하지 않는다면
초기화 또는 파쇄하는 것을 검토한다.
- etcd 인스턴스가 여러 개라면,
etcd 피어 간 통신에 SSL/TLS를 사용하고 있는지 확인한다.
## {{% heading "whatsnext" %}}
- 시크릿의 보안성을 높이고 관리하는 데에 관한 가이드라인을 원한다면
[쿠버네티스 시크릿을 다루는 좋은 관행들](/ko/docs/concepts/security/secrets-good-practices/)을 참고하라.
- [`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/)하는 방법 배우기

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

@ -6,7 +6,6 @@ description: 런타임 의존성과 함께 애플리케이션을 패키징하는
# - erictune
# - thockin
content_type: concept
no_list: true
---
<!-- overview -->
@ -18,7 +17,10 @@ no_list: true
컨테이너는 기본 호스트 인프라에서 애플리케이션을 분리한다.
따라서 다양한 클라우드 또는 OS 환경에서 보다 쉽게 배포할 수 있다.
쿠버네티스 클러스터에 있는 개별 {{< glossary_tooltip text="node" term_id="node" >}}는
해당 노드에 할당된 [파드](/ko/docs/concepts/workloads/pods/)를
구성하는 컨테이너들을 실행한다.
파드 내부에 컨테이너들은 같은 노드에서 실행될 수 있도록 같은 곳에 위치하고 함께 스케줄된다.
<!-- body -->
@ -29,16 +31,23 @@ no_list: true
여기에는 실행하는 데 필요한 코드와 모든 런타임, 애플리케이션 및 시스템 라이브러리,
그리고 모든 필수 설정에 대한 기본값이 포함된다.
설계 상, 컨테이너는 변경할 수 없다. 이미 실행 중인 컨테이너의 코드를
변경할 수 없다. 컨테이너화된 애플리케이션이 있고
변경하려는 경우, 변경 사항이 포함된 새 이미지를 빌드한
다음, 업데이트된 이미지에서 시작하도록 컨테이너를 다시 생성해야 한다.
컨테이너는 스테이트리스하며
[불변(immutable)](https://glossary.cncf.io/immutable-infrastructure/)일 것으로 계획되었다.
즉, 이미 실행 중인 컨테이너의 코드를 수정해서는 안된다.
만일 컨테이너화된 애플리케이션에 수정을 가하고 싶다면,
수정 내역을 포함한 새로운 이미지를 빌드하고,
업데이트된 이미지로부터
컨테이너를 새로 생성하는 것이 올바른 방법이다.
## 컨테이너 런타임
{{< glossary_definition term_id="container-runtime" length="all" >}}
## {{% heading "whatsnext" %}}
일반적으로 클러스터에서 파드의 기본 컨테이너 런타임을 선택하도록 허용할 수 있다.
만일 클러스터에서 복수의 컨테이너 런타임을 사용해야 하는 경우,
파드에 대해 [런타임클래스(RuntimeClass)](/ko/docs/concepts/containers/runtime-class/)을 명시함으로써
쿠버네티스가 특정 컨테이너 런타임으로
해당 컨테이너들을 실행하도록 설정할 수 있다.
* [컨테이너 이미지](/ko/docs/concepts/containers/images/)에 대해 읽어보기
* [파드](/ko/docs/concepts/workloads/pods/)에 대해 읽어보기
또한 런타임클래스을 사용하면 하나의 컨테이너 런타임을 사용하여 복수의 파드들을
각자 다른 설정으로 실행할 수도 있다.

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

@ -51,7 +51,7 @@ FOO_SERVICE_HOST=<서비스가 동작 중인 호스트>
FOO_SERVICE_PORT=<서비스가 동작 중인 포트>
```
서비스에 지정된 IP 주소가 있고 [DNS 애드온](https://releases.k8s.io/{{< param "fullversion" >}}/cluster/addons/dns/)이 활성화된 경우, DNS를 통해서 컨테이너가 서비스를 사용할 수 있다.
서비스에 지정된 IP 주소가 있고 [DNS 애드온](https://releases.k8s.io/v{{< skew currentPatchVersion >}}/cluster/addons/dns/)이 활성화된 경우, DNS를 통해서 컨테이너가 서비스를 사용할 수 있다.

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

@ -4,7 +4,7 @@
# - thockin
title: 컨테이너 라이프사이클 훅(Hook)
content_type: concept
weight: 30
weight: 40
---
<!-- overview -->

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

@ -5,6 +5,7 @@
title: 이미지
content_type: concept
weight: 10
hide_summary: true # 섹션의 목차에 별도로 기재
---
<!-- overview -->
@ -19,6 +20,12 @@ weight: 10
이 페이지는 컨테이너 이미지 개념의 개요를 제공한다.
{{< note >}}
(v{{< skew latestVersion >}}와 같은 최신 마이너 릴리즈와 같은)
쿠버네티스 릴리즈에 대한 컨테이너 이미지를 찾고 있다면
[쿠버네티스 다운로드](https://kubernetes.io/releases/download/)를 확인하라.
{{< /note >}}
<!-- body -->
## 이미지 이름
@ -149,9 +156,16 @@ kubelet이 컨테이너 런타임을 사용하여 파드의 컨테이너 생성
## 이미지 인덱스가 있는 다중 아키텍처 이미지
바이너리 이미지를 제공할 뿐만 아니라, 컨테이너 레지스트리는 [컨테이너 이미지 인덱스](https://github.com/opencontainers/image-spec/blob/master/image-index.md)를 제공할 수도 있다. 이미지 인덱스는 컨테이너의 아키텍처별 버전에 대한 여러 [이미지 매니페스트](https://github.com/opencontainers/image-spec/blob/master/manifest.md)를 가리킬 수 있다. 아이디어는 이미지의 이름(예를 들어, `pause`, `example/mycontainer`, `kube-apiserver`)을 가질 수 있다는 것이다. 그래서 다른 시스템들이 사용하고 있는 컴퓨터 아키텍처에 적합한 바이너리 이미지를 가져올 수 있다.
바이너리 이미지를 제공할 뿐만 아니라, 컨테이너 레지스트리는
[컨테이너 이미지 인덱스](https://github.com/opencontainers/image-spec/blob/master/image-index.md)를
제공할 수도 있다. 이미지 인덱스는 컨테이너의 아키텍처별 버전에 대한 여러
[이미지 매니페스트](https://github.com/opencontainers/image-spec/blob/master/manifest.md)를 가리킬 수 있다.
아이디어는 이미지의 이름(예를 들어, `pause`, `example/mycontainer`, `kube-apiserver`)을 가질 수 있다는 것이다.
그래서 다른 시스템들이 사용하고 있는 컴퓨터 아키텍처에 적합한 바이너리 이미지를 가져올 수 있다.
쿠버네티스 자체는 일반적으로 `-$(ARCH)` 접미사로 컨테이너 이미지의 이름을 지정한다. 이전 버전과의 호환성을 위해, 접미사가 있는 오래된 이미지를 생성한다. 아이디어는 모든 아키텍처에 대한 매니페스트가 있는 `pause` 이미지와 이전 구성 또는 이전에 접미사로 이미지를 하드 코딩한 YAML 파일과 호환되는 `pause-amd64` 라고 하는 이미지를 생성한다.
쿠버네티스 자체는 일반적으로 `-$(ARCH)` 접미사로 컨테이너 이미지의 이름을 지정한다. 이전 버전과의 호환성을 위해,
접미사가 있는 오래된 이미지를 생성한다. 아이디어는 모든 아키텍처에 대한 매니페스트가 있는 `pause` 이미지와 이전 구성
또는 이전에 접미사로 이미지를 하드 코딩한 YAML 파일과 호환되는 `pause-amd64` 라고 하는 이미지를 생성한다.
## 프라이빗 레지스트리 사용
@ -160,6 +174,9 @@ kubelet이 컨테이너 런타임을 사용하여 파드의 컨테이너 생성
- 프라이빗 레지스트리에 대한 인증을 위한 노드 구성
- 모든 파드는 구성된 프라이빗 레지스트리를 읽을 수 있음
- 클러스터 관리자에 의한 노드 구성 필요
- Kubelet 자격증명 제공자(Credential Provider)를 통해 프라이빗 레지스트리로부터 동적으로 자격증명을 가져오기
- kubelet은 특정 프라이빗 레지스트리에 대해 자격증명 제공자 실행
플러그인(credential provider exec plugin)을 사용하도록 설정될 수 있다.
- 미리 내려받은(pre-pulled) 이미지
- 모든 파드는 노드에 캐시된 모든 이미지를 사용 가능
- 셋업을 위해서는 모든 노드에 대해서 root 접근이 필요
@ -180,6 +197,18 @@ kubelet이 컨테이너 런타임을 사용하여 파드의 컨테이너 생성
[프라이빗 레지스트리에서 이미지 가져오기](/ko/docs/tasks/configure-pod-container/pull-image-private-registry/)를 참조한다.
해당 예시는 도커 허브에서 제공하는 프라이빗 레지스트리를 사용한다.
### 인증된 이미지를 가져오기 위한 Kubelet 자격증명 제공자(Credential Provider) {#kubelet-credential-provider}
{{< note >}}
해당 방식은 kubelet이 자격증명을 동적으로 가져와야 할 때 특히 적절하다.
가장 일반적으로 클라우드 제공자로부터 제공받은 레지스트리에 대해 사용된다. 인증 토큰의 수명이 짧기 때문이다.
{{< /note >}}
kubelet에서 플러그인 바이너리를 호출하여 컨테이너 이미지에 대한 레지스트리 자격증명을 동적으로 가져오도록 설정할 수 있다.
이는 프라이빗 레지스트리에서 자격증명을 가져오는 방법 중 가장 강력하며 휘발성이 있는 방식이지만, 활성화하기 위해 kubelet 수준의 구성이 필요하다.
자세한 내용은 [kubelet 이미지 자격증명 제공자 설정하기](/ko/docs/tasks/administer-cluster/kubelet-credential-provider/)를 참고한다.
### config.json 파일 해석 {#config-json}
`config.json` 파일의 해석에 있어서, 기존 도커의 구현과 쿠버네티스의 구현에 차이가 있다.

3
content/ko/docs/concepts/containers/runtime-class.md
View File

@ -4,7 +4,8 @@
# - dchen1107
title: 런타임클래스(RuntimeClass)
content_type: concept
weight: 20
weight: 30
hide_summary: true # 섹션의 목차에 별도로 기재
---
<!-- overview -->

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

@ -28,41 +28,38 @@ no_list: true
어떤 익스텐션(extension) 포인트와 패턴이 있는지,
그리고 그것의 트레이드오프와 제약을 이해하는 데 도움이 될 것이다.
<!-- body -->
## 개요
사용자 정의 방식은 크게 플래그, 로컬 구성 파일 또는 API 리소스 변경만
포함하는 *구성* 과 추가 프로그램이나 서비스 실행과 관련된 *익스텐션* 으로
나눌 수 있다. 이 문서는 주로 익스텐션에 관한 것이다.
포함하는 [구성](#구성)과 추가적인 프로그램, 추가적인 네트워크 서비스,
또는 둘 다의 실행을 요구하는 [익스텐션](#익스텐션)으로 나눌 수 있다.
이 문서는 주로 _익스텐션_ 에 관한 것이다.
<!-- body -->
## 구성
*구성 파일* 및 *플래그* 는 온라인 문서의 레퍼런스 섹션에
*구성 파일* 및 *명령행 인자* 는 온라인 문서의 [레퍼런스](/ko/docs/reference/) 섹션에
각 바이너리 별로 문서화되어 있다.
* [kubelet](/docs/reference/command-line-tools-reference/kubelet/)
* [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/)
* [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/)
* [kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/)
* [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/).
* [`kube-apiserver`](/docs/reference/command-line-tools-reference/kube-apiserver/)
* [`kube-controller-manager`](/docs/reference/command-line-tools-reference/kube-controller-manager/)
* [`kube-scheduler`](/docs/reference/command-line-tools-reference/kube-scheduler/).
* [`kubelet`](/docs/reference/command-line-tools-reference/kubelet/)
* [`kube-proxy`](/docs/reference/command-line-tools-reference/kube-proxy/)
호스팅된 쿠버네티스 서비스 또는 매니지드 설치 환경의 배포판에서
플래그 및 구성 파일을 항상 변경할 수 있는 것은 아니다. 변경
가능한 경우 일반적으로 클러스터 관리자만 변경할 수 있다. 또한 향후
쿠버네티스 버전에서 변경될 수 있으며, 이를 설정하려면 프로세스를 다시
호스팅된 쿠버네티스 서비스 또는 매니지드 설치 환경의 배포판에서
명령행 인자 및 구성 파일을 항상 변경할 수 있는 것은 아니다. 변경
가능하더라도 일반적으로 클러스터 오퍼레이터를 통해서만 변경될 수 있다. 또한 향후
쿠버네티스 버전에서 변경될 수 있으며, 이를 설정하려면 프로세스를 다시
시작해야 할 수도 있다. 이러한 이유로 다른 옵션이 없는 경우에만 사용해야 한다.
[리소스쿼터](/ko/docs/concepts/policy/resource-quotas/),
[파드시큐리티폴리시(PodSecurityPolicy)](/ko/docs/concepts/security/pod-security-policy/),
[네트워크폴리시](/ko/docs/concepts/services-networking/network-policies/) 및
역할 기반 접근 제어([RBAC](/docs/reference/access-authn-authz/rbac/))와 같은
*빌트인 정책 API(built-in Policy API)* 는 기본적으로 제공되는 쿠버네티스 API이다. API는
일반적으로 호스팅된 쿠버네티스 서비스 및 매니지드 쿠버네티스 설치 환경과 함께 사용된다. 그것들은
선언적이며 파드와 같은 다른 쿠버네티스 리소스와 동일한 규칙을 사용하므로, 새로운 클러스터
구성을 반복할 수 있고 애플리케이션과 동일한 방식으로 관리할 수 있다. 또한, 이들 API가 안정적인
경우, 다른 쿠버네티스 API와 같이 [정의된 지원 정책](/docs/reference/using-api/deprecation-policy/)을
사용할 수 있다. 이러한 이유로 인해 *구성 파일* 과 *플래그* 보다 선호된다.
[리소스쿼터](/ko/docs/concepts/policy/resource-quotas/),
[네트워크폴리시](/ko/docs/concepts/services-networking/network-policies/) 및
역할 기반 접근 제어([RBAC](/docs/reference/access-authn-authz/rbac/))와 같은 빌트인 *정책 API(Policy API)* 는 선언적으로 구성된 정책 설정을 제공하는 내장 쿠버네티스 API이다. API는
일반적으로 호스팅된 쿠버네티스 서비스 및 매니지드 쿠버네티스 설치 환경과 함께 사용할 수도 있다.
빌트인 정책 API는 파드와 같은 다른 쿠버네티스 리소스와 동일한 규칙을 따른다.
[안정적인](/ko/docs/reference/using-api/#api-versioning) 정책 API를 사용하는 경우
다른 쿠버네티스 API와 같이 [정의된 지원 정책](/docs/reference/using-api/deprecation-policy/)의 혜택을 볼 수 있다.
이러한 이유로 인해 적절한 상황에서는 정책 API는 *구성 파일* 과 *명령행 인자* 보다 권장된다.
## 익스텐션
@ -73,7 +70,7 @@ no_list: true
이러한 클러스터들은 미리 설치된 익스텐션을 포함한다. 결과적으로 대부분의
쿠버네티스 사용자는 익스텐션을 설치할 필요가 없고, 새로운 익스텐션을 만들 필요가 있는 사용자는 더 적다.
## 익스텐션 패턴
### 익스텐션 패턴
쿠버네티스는 클라이언트 프로그램을 작성하여 자동화 되도록 설계되었다.
쿠버네티스 API를 읽고 쓰는 프로그램은 유용한 자동화를 제공할 수 있다.
@ -82,125 +79,161 @@ no_list: true
자동화는 일반적으로 호스트 클러스터 및 매니지드 설치 환경을 포함한 모든
쿠버네티스 클러스터에서 작동한다.
쿠버네티스와 잘 작동하는 클라이언트 프로그램을 작성하기 위한 특정 패턴은 *컨트롤러* 패턴이라고 한다.
쿠버네티스와 잘 작동하는 클라이언트 프로그램을 작성하기 위한 특정 패턴은
{{< glossary_tooltip term_id="controller" text="컨트롤러" >}} 패턴이라고 한다.
컨트롤러는 일반적으로 오브젝트의 `.spec`을 읽고, 가능한 경우 수행한 다음
오브젝트의 `.status`를 업데이트 한다.
컨트롤러는 쿠버네티스의 클라이언트이다. 쿠버네티스가 클라이언트이고 원격 서비스를 호출할 때
이를 *웹훅(Webhook)* 이라고 한다. 원격 서비스를 *웹훅 백엔드* 라고 한다. 컨트롤러와
마찬가지로 웹훅은 장애 지점을 추가한다.
컨트롤러는 쿠버네티스 API의 클라이언트이다. 쿠버네티스가 클라이언트이고 원격 서비스를 호출할 때,
쿠버네티스는 이를 *웹훅(Webhook)* 이라고 한다. 원격 서비스는 *웹훅 백엔드* 라고 한다.
커스텀 컨트롤러와 마찬가지로 웹훅은 새로운 장애 지점이 된다.
{{< note >}}
쿠버네티스와 별개로 "웹훅"이라는 용어는 일반적으로 비동기 알림 메커니즘을 의미한다.
이때 웹훅 호출은 다른 시스템 혹은 컴포넌트로 보내지는 단방향적인 알림의 역할을 수행한다.
쿠버네티스 생태계에서는 동기적인 HTTP 호출도
"웹훅"이라고 불린다.
{{< /note >}}
웹훅 모델에서 쿠버네티스는 원격 서비스에 네트워크 요청을 한다.
*바이너리 플러그인* 모델에서 쿠버네티스는 바이너리(프로그램)를 실행한다.
바이너리 플러그인은 kubelet(예:
[Flex Volume 플러그인](/ko/docs/concepts/storage/volumes/#flexvolume)과
[네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/))과
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)
그 대안인 *바이너리 플러그인* 모델에서는 쿠버네티스에서 바이너리(프로그램)를 실행한다.
바이너리 플러그인은 kubelet(예: [CSI 스토리지 플러그인](https://kubernetes-csi.github.io/docs/)과
[CNI 네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)) 및
kubectl에서 사용된다. ([플러그인으로 kubectl 확장](/ko/docs/tasks/extend-kubectl/kubectl-plugins/)을 참고하자.)
## 익스텐션 포인트
이 다이어그램은 쿠버네티스 시스템의 익스텐션 포인트를 보여준다.
이 다이어그램은 쿠버네티스 클러스터의 익스텐션 포인트와
그에 접근하는 클라이언트를 보여준다.
<!-- image source diagrams: https://docs.google.com/drawings/d/1k2YdJgNTtNfW7_A8moIIkij-DmVgEhNrn3y2OODwqQQ/view -->
![익스텐션 포인트](/docs/concepts/extend-kubernetes/extension-points.png)
<!-- image source: https://docs.google.com/drawings/d/1k2YdJgNTtNfW7_A8moIIkij-DmVgEhNrn3y2OODwqQQ/view -->
1. 사용자는 종종 `kubectl`을 사용하여 쿠버네티스 API와 상호 작용한다.
[Kubectl 플러그인](/ko/docs/tasks/extend-kubectl/kubectl-plugins/)은 kubectl 바이너리를 확장한다.
개별 사용자의 로컬 환경에만 영향을 미치므로 사이트 전체 정책을 적용할 수는 없다.
{{< figure src="/docs/concepts/extend-kubernetes/extension-points.png"
alt="쿠버네티스의 익스텐션 포인트를 7개의 숫자 심볼로 표시"
class="diagram-large" caption="쿠버네티스 익스텐션 포인트" >}}
1. apiserver는 모든 요청을 처리한다. apiserver의 여러 유형의 익스텐션 포인트는 요청을 인증하거나,
콘텐츠를 기반으로 요청을 차단하거나, 콘텐츠를 편집하고, 삭제 처리를 허용한다. 이 내용은
#### 그림의 핵심
1. 사용자는 종종 `kubectl`을 사용하여 쿠버네티스 API와 상호 작용한다. [플러그인](#client-extensions)을 통해
클라이언트의 행동을 커스터마이징할 수 있다. 다양한 클라이언트들에 적용될 수 있는 일반적인 익스텐션도 있으며,
`kubectl`을 확장하기 위한 구체적인 방법도 존재한다.
1. apiserver는 모든 요청을 처리한다. apiserver의 여러 유형의 익스텐션 포인트는 요청을 인증하거나,
콘텐츠를 기반으로 요청을 차단하거나, 콘텐츠를 편집하고, 삭제 처리를 허용한다. 이 내용은
[API 접근 익스텐션](#api-접근-익스텐션) 섹션에 설명되어 있다.
1. apiserver는 다양한 종류의 *리소스* 를 제공한다. `pods`와 같은 *빌트인 리소스 종류* 는
쿠버네티스 프로젝트에 의해 정의되며 변경할 수 없다. 직접 정의한 리소스를
추가할 수도 있고, [커스텀 리소스](#사용자-정의-유형) 섹션에 설명된 대로
*커스텀 리소스* 라고 부르는 다른 프로젝트에서 정의한 리소스를 추가할 수도 있다.
커스텀 리소스는 종종 API 접근 익스텐션과 함께 사용된다.
1. apiserver는 다양한 종류의 *리소스* 를 제공한다. `pod`와 같은 *빌트인 리소스 종류* 는
쿠버네티스 프로젝트에 의해 정의되며 변경할 수 없다.
쿠버네티스 API를 확장하는 것에 대한 내용은 [API 익스텐션](#api-익스텐션)에 설명되어 있다.
1. 쿠버네티스 스케줄러는 파드를 배치할 노드를 결정한다. 스케줄링을 확장하는 몇 가지
방법이 있다. 이들은 [스케줄러 익스텐션](#스케줄러-익스텐션) 섹션에 설명되어 있다.
1. 쿠버네티스 스케줄러는 파드를 어느 노드에 배치할지
[결정](/ko/docs/concepts/scheduling-eviction/assign-pod-node/)한다. 스케줄링을 확장하는 몇 가지
방법이 있으며, 이는 [스케줄링 익스텐션](#스케줄링-익스텐션) 섹션에 설명되어 있다.
1. 쿠버네티스의 많은 동작은 API-Server의 클라이언트인 컨트롤러(Controller)라는 프로그램으로
구현된다. 컨트롤러는 종종 커스텀 리소스와 함께 사용된다.
1. 쿠버네티스의 많은 동작은 API-Server의 클라이언트인
{{< glossary_tooltip term_id="controller" text="컨트롤러" >}}라는
프로그램으로 구현된다. 컨트롤러는 종종 커스텀 리소스와 함께 사용된다.
[새로운 API와 자동화의 결합](#combining-new-apis-with-automation)과
[빌트인 리소스 변경](#빌트인-리소스-변경)에 설명되어 있다.
1. kubelet은 서버에서 실행되며 파드가 클러스터 네트워크에서 자체 IP를 가진 가상 서버처럼
보이도록 한다. [네트워크 플러그인](#네트워크-플러그인)을 사용하면 다양한
1. kubelet은 서버(노드)에서 실행되며 파드가 클러스터 네트워크에서 자체 IP를 가진 가상 서버처럼
보이도록 한다. [네트워크 플러그인](#네트워크-플러그인)을 사용하면 다양한
파드 네트워킹 구현이 가능하다.
1. kubelet은 컨테이너의 볼륨을 마운트 및 마운트 해제한다. 새로운 유형의 스토리지는
[스토리지 플러그인](#스토리지-플러그인)을 통해 지원될 수 있다.
1. [장치 플러그인](#device-plugins)을 사용하여 커스텀 하드웨어나 노드에 설치된 특수한 장치와 통합하고,
클러스터에서 실행 중인 파드에서 사용 가능하도록 할 수 있다.
kubelet을 통해 장치 플러그인를 조작할 수 있다.
어디서부터 시작해야 할지 모르겠다면, 이 플로우 차트가 도움이 될 수 있다. 일부 솔루션에는
kubelet은 컨테이너의 {{< glossary_tooltip text="볼륨" term_id="volume" >}}을
마운트 및 마운트 해제한다.
[스토리지 플러그인](#storage-plugins)을 사용하여 새로운 종류의 스토리지와
다른 볼륨 타입에 대한 지원을 추가할 수 있다.
#### 익스텐션 포인트 선택 순서도 {#extension-flowchart}
어디서부터 시작해야 할지 모르겠다면, 이 순서도가 도움이 될 수 있다. 일부 솔루션에는
여러 유형의 익스텐션이 포함될 수 있다.
<!-- image source drawing: https://docs.google.com/drawings/d/1sdviU6lDz4BpnzJNHfNpQrqI9F19QZ07KnhnxVrp2yg/edit -->
![익스텐션 플로우차트](/ko/docs/concepts/extend-kubernetes/flowchart.png)
<!-- image source for flowchart: https://docs.google.com/drawings/d/1sdviU6lDz4BpnzJNHfNpQrqI9F19QZ07KnhnxVrp2yg/edit -->
{{< figure src="/docs/concepts/extend-kubernetes/flowchart.png"
alt="유스케이스에 따른 질문과 가이드를 포함하는 순서도. 초록색 원은 예를 뜻하고, 빨간색 원은 아니오를 뜻함"
class="diagram-large" caption="익스텐션 방법 선택을 가이드하기 위한 순서도" >}}
---
## 클라이언트 익스텐션 {#client-extensions}
kubectl을 위한 플러그인은 별도의 바이너리로 특정한 하위 명령어를 추가하거나 변경해준다.
또한 `kubectl` 은 [자격증명 플러그인](/docs/reference/access-authn-authz/authentication/#client-go-credential-plugins)과 통합될 수도 있다.
이러한 익스텐션은 개별 사용자의 로컬 환경에만 영향을 주기 때문에 거시적인 정책을 강제할 수 없다.
`kubectl` 자체를 확장하는 방법은 [플러그인으로 kubectl 확장](/ko/docs/tasks/extend-kubectl/kubectl-plugins/)에 설명되어 있다.
## API 익스텐션
### 사용자 정의 유형
### 커스텀 리소스 데피니션
새 컨트롤러, 애플리케이션 구성 오브젝트 또는 기타 선언적 API를 정의하고
`kubectl` 과 같은 쿠버네티스 도구를 사용하여 관리하려면
쿠버네티스에 커스텀 리소스를 추가하자.
애플리케이션, 사용자 또는 모니터링 데이터의 데이터 저장소로 커스텀 리소스를 사용하지 않는다.
쿠버네티스에 _커스텀 리소스_ 를 추가하자.
커스텀 리소스에 대한 자세한 내용은
[커스텀 리소스 개념 가이드](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)를 참고하길 바란다.
[커스텀 리소스](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/) 개념 가이드를 참고하길 바란다.
### API 애그리게이션 레이어
### 새로운 API와 자동화의 결합
쿠버네티스의 [API 애그리게이션 레이어](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)를 사용하면
[메트릭](/ko/docs/tasks/debug/debug-cluster/resource-metrics-pipeline/) 등을 목적으로
쿠버네티스 API를 추가적인 서비스와 통합할 수 있다.
사용자 정의 리소스 API와 컨트롤 루프의 조합을
[오퍼레이터(operator) 패턴](/ko/docs/concepts/extend-kubernetes/operator/)이라고 한다. 오퍼레이터 패턴은
특정 애플리케이션, 일반적으로 스테이트풀(stateful) 애플리케이션을 관리하는 데 사용된다. 이러한
사용자 정의 API 및 컨트롤 루프를 사용하여 스토리지나 정책과 같은 다른 리소스를 제어할 수도 있다.
### 새로운 API와 자동화의 결합 {#combining-new-apis-with-automation}
사용자 정의 리소스 API와 컨트롤 루프의 조합을
{{< glossary_tooltip term_id="controller" text="컨트롤러" >}} 패턴이라고 한다.
만약 컨트롤러가 의도한 상태에 따라 인프라스트럭쳐를 배포하는 인간 오퍼레이터의 역할을 대신하고 있다면,
컨트롤러는 {{< glossary_tooltip text="오퍼레이터 패턴" term_id="operator-pattern" >}}을 따르고 있을지도 모른다.
오퍼레이터 패턴은 특정 애플리케이션을 관리하는 데 사용된다.
주로 이러한 애플리케이션들은 상태를 지니며 상태를 어떻게 관리해야 하는지에 관한 주의를 요한다.
또한 스토리지와 같은 다른 리소스를 관리하거나 접근 제어 제한 등의 정책을 정의하기 위해
커스텀 API와 제어 루프를 만드는 것도 가능하다.
### 빌트인 리소스 변경
사용자 정의 리소스를 추가하여 쿠버네티스 API를 확장하면 추가된 리소스는 항상
사용자 정의 리소스를 추가하여 쿠버네티스 API를 확장하면 추가된 리소스는 항상
새로운 API 그룹에 속한다. 기존 API 그룹을 바꾸거나 변경할 수 없다.
API를 추가해도 기존 API(예: 파드)의 동작에 직접 영향을 미치지는 않지만 API
접근 익스텐션은 영향을 준다.
API를 추가해도 기존 API(예: 파드)의 동작에 직접 영향을 미치지는 않지만
_API 접근 익스텐션_ 은 영향을 준다.
### API 접근 익스텐션
## API 접근 익스텐션
요청이 쿠버네티스 API 서버에 도달하면 먼저 인증이 되고, 그런 다음 승인된 후
다양한 유형의 어드미션 컨트롤이 적용된다. 이 흐름에
대한 자세한 내용은 [쿠버네티스 API에 대한 접근 제어](/ko/docs/concepts/security/controlling-access/)를
요청이 쿠버네티스 API 서버에 도달하면 먼저 _인증_ 이 되고, 그런 다음 _인가_ 된 후
다양한 유형의 _어드미션 컨트롤_ 을 거치게 된다. (사실, 일부 요청은 인증되지 않고 특별한 과정을 거친다.)
이 흐름에 대한 자세한 내용은 [쿠버네티스 API에 대한 접근 제어](/ko/docs/concepts/security/controlling-access/)를
참고하길 바란다.
이러한 각 단계는 익스텐션 포인트를 제공한다.
쿠버네티스에는 이를 지원하는 몇 가지 빌트인 인증 방법이 있다. 또한 인증 프록시 뒤에
있을 수 있으며 인증 헤더에서 원격 서비스로 토큰을 전송하여
확인할 수 있다(웹훅). 이러한 방법은 모두
[인증 설명서](/docs/reference/access-authn-authz/authentication/)에 설명되어 있다.
쿠버네티스의 인증/인가 흐름의 각 단계는 익스텐션 포인트를 제공한다.
### 인증
[인증](/docs/reference/access-authn-authz/authentication/)은 모든 요청의 헤더 또는 인증서를
[인증](/docs/reference/access-authn-authz/authentication/)은 모든 요청의 헤더 또는 인증서를
요청하는 클라이언트의 사용자 이름에 매핑한다.
쿠버네티스는 몇 가지 빌트인 인증 방법과
필요에 맞지 않는 경우
[인증 웹훅](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) 방법을 제공한다.
쿠버네티스는 몇 가지 빌트인 인증 방법을 지원한다.
이러한 방법이 사용자 요구 사항을 충족시키지 못한다면
인증 프록시 뒤에 위치하면서 `Authorization:` 헤더로 받은 토큰을 원격 서비스로 보내 검증받는
방법([인증 웹훅](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication))도 존재하므로, 참고하길 바란다.
### 인가
[인가](/ko/docs/reference/access-authn-authz/authorization/)는 특정
사용자가 API 리소스에서 읽고, 쓰고, 다른 작업을 수행할 수 있는지를 결정한다. 전체 리소스 레벨에서
작동하며 임의의 오브젝트 필드를 기준으로 구별하지 않는다. 빌트인
인증 옵션이 사용자의 요구를 충족시키지 못하면 [인가 웹훅](/docs/reference/access-authn-authz/webhook/)을
작동하며 임의의 오브젝트 필드를 기준으로 구별하지 않는다.
빌트인 인증 옵션이 사용자의 요구를 충족시키지 못하면
[인가 웹훅](/docs/reference/access-authn-authz/webhook/)을
통해 사용자가 제공한 코드를 호출하여 인증 결정을 내릴 수 있다.
### 동적 어드미션 컨트롤
@ -214,32 +247,43 @@ API를 추가해도 기존 API(예: 파드)의 동작에 직접 영향을 미치
* 임의의 어드미션 컨트롤 결정을 내리기 위해 일반적인
[어드미션 웹훅](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)을
사용할 수 있다. 어드미션 웹훅은 생성 또는 업데이트를 거부할 수 있다.
어떤 어드미션 웹훅은 쿠버네티스에 의해 처리되기 전에 들어오는 요청의 데이터에 변경을 가할 수도 있다.
## 인프라스트럭처 익스텐션
### 스토리지 플러그인
### 장치 플러그인 {#device-plugins}
[Flex Volumes](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/flexvolume-deployment.md)을
사용하면 Kubelet이 바이너리 플러그인을 호출하여 볼륨을 마운트하도록 함으로써 빌트인 지원 없이
볼륨 유형을 마운트 할 수 있다.
_장치 플러그인_ 은 노드가 [장치 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)을
통해 (CPU 및 메모리와 같은 빌트인 자원 외에 추가적으로) 새로운 노드 리소스를
발견할 수 있게 해준다.
FlexVolume은 쿠버네티스 v1.23부터 사용 중단(deprecated)되었다. Out-of-tree CSI 드라이버가 쿠버네티스에서 볼륨 드라이버를 작성할 때
추천하는 방식이다. 자세한 정보는
### 스토리지 플러그인 {#storage-plugins}
{{< glossary_tooltip text="컨테이너 스토리지 인터페이스" term_id="csi" >}} (CSI) 플러그인은
새로운 종류의 볼륨을 지원하도록 쿠버네티스를 확장할 수 있게 해준다.
볼륨은 내구성 높은 외부 스토리지에 연결되거나, 일시적인 스토리지를 제공하거나,
파일시스템 패러다임을 토대로 정보에 대한 읽기 전용 인터페이스를 제공할 수도 있다.
또한 쿠버네티스는 (CSI를 권장하며) v1.23부터 사용 중단된
[FlexVolume](/ko/docs/concepts/storage/volumes/#flexvolume-deprecated) 플러그인에 대한 지원도 포함한다.
FlexVolume 플러그인은 쿠버네티스에서 네이티브하게 지원하지 않는 볼륨 종류도 마운트할 수 있도록 해준다.
FlexVolume 스토리지에 의존하는 파드를 실행하는 경우 kubelet은 바이너리 플러그인을 호출하여 볼륨을 마운트한다.
아카이브된 [FlexVolume](https://git.k8s.io/design-proposals-archive/storage/flexvolume-deployment.md) 디자인 제안은 이러한 접근방법에 대한 자세한 설명을 포함하고 있다.
스토리지 플러그인에 대한 전반적인 정보는
[스토리지 업체를 위한 쿠버네티스 볼륨 플러그인 FAQ](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md#kubernetes-volume-plugin-faq-for-storage-vendors)에서
찾을 수 있다.
### 장치 플러그인
장치 플러그인은 노드가 [장치 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)을
통해 새로운 노드 리소스(CPU 및 메모리와 같은 빌트인 자원 외에)를
발견할 수 있게 해준다.
### 네트워크 플러그인
노드-레벨의 [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
을 통해 다양한 네트워킹 패브릭을 지원할 수 있다.
제대로 동작하는 파드 네트워크와 쿠버네티스 네트워크 모델의 다양한 측면을 지원하기 위해
쿠버네티스 클러스터는 _네트워크 플러그인_ 을 필요로 한다.
### 스케줄러 익스텐션
[네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)을 통해
쿠버네티스는 다양한 네트워크 토폴로지 및 기술을 활용할 수 있게 된다.
### 스케줄링 익스텐션
스케줄러는 파드를 감시하고 파드를 노드에 할당하는 특수한 유형의
컨트롤러이다. 다른 쿠버네티스 컴포넌트를 계속 사용하면서
@ -250,19 +294,30 @@ FlexVolume은 쿠버네티스 v1.23부터 사용 중단(deprecated)되었다. Ou
이것은 중요한 부분이며, 거의 모든 쿠버네티스 사용자는 스케줄러를 수정할
필요가 없다는 것을 알게 된다.
스케줄러는 또한 웹훅 백엔드(스케줄러 익스텐션)가
파드에 대해 선택된 노드를 필터링하고 우선 순위를 지정할 수 있도록 하는
[웹훅](https://git.k8s.io/design-proposals-archive/scheduling/scheduler_extender.md)을
지원한다.
어떤 [스케줄링 플러그인](/ko/docs/reference/scheduling/config/#scheduling-plugins)을 활성화시킬지 제어하거나,
플러그인들을 다른 이름의 [스케줄러 프로파일](/ko/docs/reference/scheduling/config/#여러-프로파일)과 연결지을 수도 있다.
kube-scheduler의 [익스텐션 포인트](/docs/concepts/scheduling-eviction/scheduling-framework/#extension-points) 중
하나 이상과 통합되는 플러그인을 직접 작성할 수도 있다.
마지막으로 빌트인 `kube-scheduler` 컴포넌트는 원격 HTTP 백엔드 (스케줄러 익스텐션)에서
kube-scheduler가 파드를 위해 선택한 노드를
필터링하고 우선하도록 지정할 수 있도록 하는
[웹훅](https://git.k8s.io/design-proposals-archive/scheduling/scheduler_extender.md)을 지원한다.
{{< note >}}
노드 필터링과 노트 우선순위에 영향을 미치는 것은
스케줄러 인스텐션 웹훅을 통해서만 가능하다.
다른 익스텐션 포인트는 웹훅 통합으로 제공되지 않는다.
{{< /note >}}
## {{% heading "whatsnext" %}}
* [커스텀 리소스](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)에 대해 더 알아보기
* [동적 어드미션 컨트롤](/docs/reference/access-authn-authz/extensible-admission-controllers/)에 대해 알아보기
* 인프라스트럭처 익스텐션에 대해 더 알아보기
* [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
* [장치 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)
* [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
* CSI [스토리지 플러그인](https://kubernetes-csi.github.io/docs/)
* [kubectl 플러그인](/ko/docs/tasks/extend-kubectl/kubectl-plugins/)에 대해 알아보기
* [커스텀 리소스](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)에 대해 더 알아보기
* [익스텐션 API 서버](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)에 대해 알아보기
* [동적 어드미션 컨트롤](/docs/reference/access-authn-authz/extensible-admission-controllers/)에 대해 알아보기
* [오퍼레이터 패턴](/ko/docs/concepts/extend-kubernetes/operator/)에 대해 알아보기

2
content/ko/docs/concepts/extend-kubernetes/api-extension/_index.md
View File

@ -1,4 +1,4 @@
---
title: 쿠버네티스 API 확장하기
weight: 20
weight: 30
---

21
content/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md
View File

@ -10,18 +10,29 @@ weight: 10
<!-- overview -->
애그리게이션 레이어는 코어 쿠버네티스 API가 제공하는 기능 이외에 더 많은 기능을 제공할 수 있도록 추가 API를 더해 쿠버네티스를 확장할 수 있게 해준다.
추가 API는 [메트릭 서버](https://github.com/kubernetes-sigs/metrics-server)와 같이 미리 만들어진 솔루션이거나 사용자가 직접 개발한 API일 수 있다.
애그리게이션 레이어는 코어 쿠버네티스 API가 제공하는 기능 이외에 더 많은 기능을 제공할 수 있도록 추가 API를 더해
쿠버네티스를 확장할 수 있게 해준다.
추가 API는 [메트릭 서버](https://github.com/kubernetes-sigs/metrics-server)와 같이
미리 만들어진 솔루션이거나 사용자가 직접 개발한 API일 수 있다.
애그리게이션 레이어는 {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}}가 새로운 종류의 오브젝트를 인식하도록 하는 방법인 [사용자 정의 리소스](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)와는 다르다.
애그리게이션 레이어는 {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}}가
새로운 종류의 오브젝트를 인식하도록 하는 방법인
[사용자 정의 리소스](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)와는 다르다.
<!-- body -->
## 애그리게이션 레이어
애그리게이션 레이어는 kube-apiserver 프로세스 안에서 구동된다. 확장 리소스가 등록되기 전까지, 애그리게이션 레이어는 아무 일도 하지 않는다. API를 등록하기 위해서, 사용자는 쿠버네티스 API 내에서 URL 경로를 "요구하는(claim)" APIService 오브젝트를 추가해야 한다. 이때, 애그리게이션 레이어는 해당 API 경로(예: /apis/myextensions.mycompany.io/v1/...)로 전송되는 모든 것을 등록된 APIService로 프록시하게 된다.
애그리게이션 레이어는 kube-apiserver 프로세스 안에서 구동된다. 확장 리소스가 등록되기 전까지,
애그리게이션 레이어는 아무 일도 하지 않는다. API를 등록하기 위해서, 사용자는 쿠버네티스 API 내에서 URL 경로를
"요구하는(claim)" APIService 오브젝트를 추가해야 한다. 이때, 애그리게이션 레이어는
해당 API 경로(예: /apis/myextensions.mycompany.io/v1/...)로 전송되는 모든 것을 등록된 APIService로 프록시하게 된다.
APIService를 구현하는 가장 일반적인 방법은 클러스터 내에 실행되고 있는 파드에서 *extension API server* 를 실행하는 것이다. extension API server를 사용해서 클러스터의 리소스를 관리하는 경우 extension API server("extension-apiserver" 라고도 한다)는 일반적으로 하나 이상의 {{< glossary_tooltip text="컨트롤러" term_id="controller" >}}와 쌍을 이룬다. apiserver-builder 라이브러리는 extension API server와 연관된 컨틀로러에 대한 스켈레톤을 제공한다.
APIService를 구현하는 가장 일반적인 방법은 클러스터 내에 실행되고 있는 파드에서 *extension API server* 를 실행하는 것이다.
extension API server를 사용해서 클러스터의 리소스를 관리하는 경우
extension API server("extension-apiserver" 라고도 한다)는 일반적으로 하나 이상의
{{< glossary_tooltip text="컨트롤러" term_id="controller" >}}와 쌍을 이룬다.
apiserver-builder 라이브러리는 extension API server와 연관된 컨틀로러에 대한 스켈레톤을 제공한다.
### 응답 레이턴시

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

@ -17,7 +17,8 @@ weight: 10
## 커스텀 리소스
*리소스* 는 [쿠버네티스 API](/ko/docs/concepts/overview/kubernetes-api/)에서 특정 종류의
[API 오브젝트](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/) 모음을 저장하는 엔드포인트이다. 예를 들어 빌트인 *파드* 리소스에는 파드 오브젝트 모음이 포함되어 있다.
[API 오브젝트](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/) 모음을 저장하는 엔드포인트이다.
예를 들어 빌트인 *파드* 리소스에는 파드 오브젝트 모음이 포함되어 있다.
*커스텀 리소스* 는 쿠버네티스 API의 익스텐션으로, 기본 쿠버네티스 설치에서 반드시
사용할 수 있는 것은 아니다. 이는 특정 쿠버네티스 설치에 수정이 가해졌음을 나타낸다. 그러나
@ -68,63 +69,88 @@ _선언적(declarative) API_ 를 제공하게 된다.
선언적 API에서는 다음의 특성이 있다.
- API는 상대적으로 적은 수의 상대적으로 작은 오브젝트(리소스)로 구성된다.
- 오브젝트는 애플리케이션 또는 인프라의 구성을 정의한다.
- 오브젝트는 비교적 드물게 업데이트 된다.
- 사람이 종종 오브젝트를 읽고 쓸 필요가 있다.
- 오브젝트의 주요 작업은 CRUD-y(생성, 읽기, 업데이트 및 삭제)이다.
- 오브젝트 간 트랜잭션은 필요하지 않다. API는 정확한(exact) 상태가 아니라 의도한 상태를 나타낸다.
- API는 상대적으로 적은 수의 상대적으로 작은 오브젝트(리소스)로 구성된다.
- 오브젝트는 애플리케이션 또는 인프라의 구성을 정의한다.
- 오브젝트는 비교적 드물게 업데이트 된다.
- 사람이 종종 오브젝트를 읽고 쓸 필요가 있다.
- 오브젝트의 주요 작업은 CRUD-y(생성, 읽기, 업데이트 및 삭제)이다.
- 오브젝트 간 트랜잭션은 필요하지 않다. API는 정확한(exact) 상태가 아니라 의도한 상태를 나타낸다.
명령형 API는 선언적이지 않다.
자신의 API가 선언적이지 않을 수 있다는 징후는 다음과 같다.
- 클라이언트는 "이 작업을 수행한다"라고 말하고 완료되면 동기(synchronous) 응답을 받는다.
- 클라이언트는 "이 작업을 수행한다"라고 말한 다음 작업 ID를 다시 가져오고 별도의 오퍼레이션(operation) 오브젝트를 확인하여 요청의 완료 여부를 결정해야 한다.
- RPC(원격 프로시저 호출)에 대해 얘기한다.
- 대량의 데이터를 직접 저장한다. 예: > 오브젝트별 몇 kB 또는 > 1000개의 오브젝트.
- 높은 대역폭 접근(초당 10개의 지속적인 요청)이 필요하다.
- 최종 사용자 데이터(예: 이미지, PII 등) 또는 애플리케이션에서 처리한 기타 대규모 데이터를 저장한다.
- 오브젝트에 대한 자연스러운 조작은 CRUD-y가 아니다.
- API는 오브젝트로 쉽게 모델링되지 않는다.
- 작업 ID 또는 작업 오브젝트로 보류 중인 작업을 나타내도록 선택했다.
- 클라이언트는 "이 작업을 수행한다"라고 말하고 완료되면 동기(synchronous) 응답을 받는다.
- 클라이언트는 "이 작업을 수행한다"라고 말한 다음 작업 ID를 다시 가져오고 별도의
오퍼레이션(operation) 오브젝트를 확인하여 요청의 완료 여부를 결정해야 한다.
- RPC(원격 프로시저 호출)에 대해 얘기한다.
- 대량의 데이터를 직접 저장한다. 예: > 오브젝트별 몇 kB 또는 > 1000개의 오브젝트.
- 높은 대역폭 접근(초당 10개의 지속적인 요청)이 필요하다.
- 최종 사용자 데이터(예: 이미지, PII 등) 또는 애플리케이션에서 처리한 기타 대규모 데이터를 저장한다.
- 오브젝트에 대한 자연스러운 조작은 CRUD-y가 아니다.
- API는 오브젝트로 쉽게 모델링되지 않는다.
- 작업 ID 또는 작업 오브젝트로 보류 중인 작업을 나타내도록 선택했다.
## 컨피그맵을 사용해야 하나, 커스텀 리소스를 사용해야 하나?
다음 중 하나에 해당하면 컨피그맵을 사용하자.
* `mysql.cnf` 또는 `pom.xml`과 같이 잘 문서화된 기존 구성 파일 형식이 있다.
* `mysql.cnf` 또는 `pom.xml`과 같이 잘 문서화된
기존 구성 파일 형식이 있다.
* 전체 구성 파일을 컨피그맵의 하나의 키에 넣고 싶다.
* 구성 파일의 주요 용도는 클러스터의 파드에서 실행 중인 프로그램이 파일을 사용하여 자체 구성하는 것이다.
* 파일 사용자는 쿠버네티스 API가 아닌 파드의 환경 변수 또는 파드의 파일을 통해 사용하는 것을 선호한다.
* 구성 파일의 주요 용도는 클러스터의 파드에서 실행 중인 프로그램이 파일을 사용하여
자체 구성하는 것이다.
* 파일 사용자는 쿠버네티스 API가 아닌 파드의 환경 변수 또는 파드의 파일을 통해
사용하는 것을 선호한다.
* 파일이 업데이트될 때 디플로이먼트 등을 통해 롤링 업데이트를 수행하려고 한다.
{{< note >}}
민감한 데이터에는 {{< glossary_tooltip text="시크릿" term_id="secret" >}}을 사용하자. 이는 컨피그맵과 비슷하지만 더 안전하다.
민감한 데이터에는 {{< glossary_tooltip text="시크릿" term_id="secret" >}}을 사용하자.
이는 컨피그맵과 비슷하지만 더 안전하다.
{{< /note >}}
다음 중 대부분이 적용되는 경우 커스텀 리소스(CRD 또는 애그리게이트 API(aggregated API))를 사용하자.
* 쿠버네티스 클라이언트 라이브러리 및 CLI를 사용하여 새 리소스를 만들고 업데이트하려고 한다.
* `kubectl` 의 최상위 지원을 원한다. 예: `kubectl get my-object object-name`.
* 새 오브젝트에 대한 업데이트를 감시한 다음 다른 오브젝트를 CRUD하거나 그 반대로 하는 새로운 자동화를 구축하려고 한다.
* 새 오브젝트에 대한 업데이트를 감시한 다음 다른 오브젝트를 CRUD하거나 그 반대로 하는 새로운 자동화를
구축하려고 한다.
* 오브젝트의 업데이트를 처리하는 자동화를 작성하려고 한다.
* `.spec`, `.status` 및 `.metadata`와 같은 쿠버네티스 API 규칙을 사용하려고 한다.
* 제어된 리소스의 콜렉션 또는 다른 리소스의 요약에 대한 오브젝트가 되기를 원한다.
* 제어된 리소스의 콜렉션 또는 다른 리소스의 요약에 대한 오브젝트가 되기를
원한다.
## 커스텀 리소스 추가
쿠버네티스는 클러스터에 커스텀 리소스를 추가하는 두 가지 방법을 제공한다.
- CRD는 간단하며 프로그래밍 없이 만들 수 있다.
- [API 애그리게이션](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)에는 프로그래밍이 필요하지만, 데이터 저장 방법 및 API 버전 간 변환과 같은 API 동작을 보다 강력하게 제어할 수 있다.
- [API 애그리게이션](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)에는
프로그래밍이 필요하지만, 데이터 저장 방법 및 API 버전 간 변환과 같은
API 동작을 보다 강력하게 제어할 수 있다.
쿠버네티스는 다양한 사용자의 요구를 충족시키기 위해 이 두 가지 옵션을 제공하므로 사용의 용이성이나 유연성이 저하되지 않는다.
쿠버네티스는 다양한 사용자의 요구를 충족시키기 위해 이 두 가지 옵션을 제공하므로
사용의 용이성이나 유연성이 저하되지 않는다.
애그리게이트 API는 기본 API 서버 뒤에 있는 하위 API 서버이며 프록시 역할을 한다. 이 배치를 [API 애그리게이션](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)(AA)이라고 한다. 사용자에게는 쿠버네티스 API가 확장된 것으로 나타난다.
애그리게이트 API는 기본 API 서버 뒤에 있는 하위 API 서버이며 프록시 역할을 한다. 이 배치를
[API 애그리게이션](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)(AA)이라고 한다.
사용자에게는 쿠버네티스 API가 확장된 것으로 나타난다.
CRD를 사용하면 다른 API 서버를 추가하지 않고도 새로운 타입의 리소스를 생성할 수 있다. CRD를 사용하기 위해 API 애그리게이션을 이해할 필요는 없다.
CRD를 사용하면 다른 API 서버를 추가하지 않고도 새로운 타입의 리소스를 생성할 수 있다. CRD를 사용하기 위해 API
애그리게이션을 이해할 필요는 없다.
설치 방법에 관계없이 새 리소스는 커스텀 리소스라고 하며 빌트인 쿠버네티스 리소스(파드 등)와 구별된다.
설치 방법에 관계없이 새 리소스는 커스텀 리소스라고 하며
빌트인 쿠버네티스 리소스(파드 등)와 구별된다.
{{< note >}}
커스텀 리소스를 애플리케이션, 최종 사용자, 데이터 모니터링을 위한 데이터 스토리지로 사용하는 것은 피해야 한다.
쿠버네티스 API에서 애플리케이션 데이터를 저장하는 아키텍처 구조는
일반적으로 결합도가 너무 높기 때문이다.
아키텍처적으로 [클라우드 네이티브](https://www.cncf.io/about/faq/#what-is-cloud-native) 애플리케이션 아키텍처들은
컴포넌트 간 결합도를 낮추는 것을 선호한다.
워크로드 중 일부가 주기적인 작업을 위해 보조 서비스를 필요로 한다면, 해당 보조 서비스를 별도의 컴포넌트로 실행하거나 외부 서비스로 사용하자.
이를 통해 해당 워크로드는 일반적인 작업을 위해 쿠버네티스 API에 의존하지 않게 된다.
{{< /note >}}
## 커스텀리소스데피니션
@ -145,10 +171,14 @@ CRD 오브젝트의 이름은 유효한
## API 서버 애그리게이션
일반적으로 쿠버네티스 API의 각 리소스에는 REST 요청을 처리하고 오브젝트의 퍼시스턴트 스토리지를 관리하는 코드가 필요하다. 주요 쿠버네티스 API 서버는 *파드* 및 *서비스* 와 같은 빌트인 리소스를 처리하고, 일반적으로 [CRD](#커스텀리소스데피니션)를 통해 커스텀 리소스를 처리할 수 있다.
일반적으로 쿠버네티스 API의 각 리소스에는 REST 요청을 처리하고
오브젝트의 퍼시스턴트 스토리지를 관리하는 코드가 필요하다.
주요 쿠버네티스 API 서버는 *파드* 및 *서비스* 와 같은 빌트인 리소스를 처리하고, 일반적으로
[CRD](#커스텀리소스데피니션)를 통해 커스텀 리소스를 처리할 수 있다.
[애그리게이션 레이어](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)를 사용하면 자체 API 서버를
작성하고 배포하여 커스텀 리소스에 대한 특수한 구현을 제공할 수 있다.
[애그리게이션 레이어](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)를
사용하면 자체 API 서버를 작성하고 배포하여 커스텀 리소스에 대한
특수한 구현을 제공할 수 있다.
주(main) API 서버는 사용자의 커스텀 리소스에 대한 요청을 사용자의 자체 API 서버에 위임하여
모든 클라이언트가 사용할 수 있게 한다.
@ -159,7 +189,8 @@ CRD는 사용하기가 더 쉽다. 애그리게이트 API가 더 유연하다.
일반적으로 CRD는 다음과 같은 경우에 적합하다.
* 필드가 몇 개 되지 않는다
* 회사 내에서 또는 소규모 오픈소스 프로젝트의 일부인(상용 제품이 아닌) 리소스를 사용하고 있다.
* 회사 내에서 또는 소규모 오픈소스 프로젝트의 일부인(상용 제품이 아닌)
리소스를 사용하고 있다.
### 사용 편의성 비교
@ -192,7 +223,8 @@ CRD는 애그리게이트 API보다 생성하기가 쉽다.
### 일반적인 기능
CRD 또는 AA를 통해 커스텀 리소스를 생성하면 쿠버네티스 플랫폼 외부에서 구현하는 것과 비교하여 API에 대한 많은 기능이 제공된다.
CRD 또는 AA를 통해 커스텀 리소스를 생성하면 쿠버네티스 플랫폼 외부에서 구현하는 것과 비교하여
API에 대한 많은 기능이 제공된다.
| 기능 | 설명 |
| ------- | ------------ |
@ -217,40 +249,50 @@ CRD 또는 AA를 통해 커스텀 리소스를 생성하면 쿠버네티스 플
### 써드파티 코드 및 새로운 장애 포인트
CRD를 생성해도 새로운 장애 포인트(예를 들어, API 서버에서 장애를 유발하는 써드파티 코드가 실행됨)가 자동으로 추가되지는 않지만, 패키지(예: 차트(Charts)) 또는 기타 설치 번들에는 CRD 및 새로운 커스텀 리소스에 대한 비즈니스 로직을 구현하는 써드파티 코드의 디플로이먼트가 포함되는 경우가 종종 있다.
CRD를 생성해도 새로운 장애 포인트(예를 들어, API 서버에서 장애를 유발하는 써드파티 코드가 실행됨)가
자동으로 추가되지는 않지만, 패키지(예: 차트(Charts)) 또는 기타 설치 번들에는
CRD 및 새로운 커스텀 리소스에 대한 비즈니스 로직을 구현하는
써드파티 코드의 디플로이먼트가 포함되는 경우가 종종 있다.
애그리게이트 API 서버를 설치하려면 항상 새 디플로이먼트를 실행해야 한다.
### 스토리지
커스텀 리소스는 컨피그맵과 동일한 방식으로 스토리지 공간을 사용한다. 너무 많은 커스텀 리소스를 생성하면 API 서버의 스토리지 공간이 과부하될 수 있다.
커스텀 리소스는 컨피그맵과 동일한 방식으로 스토리지 공간을 사용한다. 너무 많은 커스텀 리소스를 생성하면
API 서버의 스토리지 공간이 과부하될 수 있다.
애그리게이트 API 서버는 기본 API 서버와 동일한 스토리지를 사용할 수 있으며 이 경우 동일한 경고가 적용된다.
애그리게이트 API 서버는 기본 API 서버와 동일한 스토리지를 사용할 수 있으며
이 경우 동일한 경고가 적용된다.
### 인증, 권한 부여 및 감사
CRD는 항상 API 서버의 빌트인 리소스와 동일한 인증, 권한 부여 및 감사 로깅을 사용한다.
CRD는 항상 API 서버의 빌트인 리소스와 동일한 인증, 권한 부여 및
감사 로깅을 사용한다.
권한 부여에 RBAC를 사용하는 경우 대부분의 RBAC 역할은 새로운 리소스에 대한 접근 권한을 부여하지 않는다(클러스터 관리자 역할 또는 와일드 카드 규칙으로 생성된 역할 제외). 새로운 리소스에 대한 접근 권한을 명시적으로 부여해야 한다. CRD 및 애그리게이트 API는 종종 추가하는 타입에 대한 새로운 역할 정의와 함께 제공된다.
권한 부여에 RBAC를 사용하는 경우 대부분의 RBAC 역할은 새로운 리소스에 대한 접근 권한을
부여하지 않는다(클러스터 관리자 역할 또는 와일드 카드 규칙으로 생성된 역할 제외).
새로운 리소스에 대한 접근 권한을 명시적으로 부여해야 한다. CRD 및 애그리게이트 API는 종종 추가하는
타입에 대한 새로운 역할 정의와 함께 제공된다.
애그리게이트 API 서버는 기본 API 서버와 동일한 인증, 권한 부여 및 감사를 사용하거나 사용하지 않을 수 있다.
애그리게이트 API 서버는 기본 API 서버와 동일한 인증, 권한 부여 및 감사를 사용하거나
사용하지 않을 수 있다.
## 커스텀 리소스에 접근
쿠버네티스 [클라이언트 라이브러리](/ko/docs/reference/using-api/client-libraries/)를 사용하여 커스텀 리소스에 접근할 수 있다. 모든 클라이언트 라이브러리가 커스텀 리소스를 지원하는 것은 아니다. _Go_ 와 _python_ 클라이언트 라이브러리가 지원한다.
쿠버네티스 [클라이언트 라이브러리](/ko/docs/reference/using-api/client-libraries/)를 사용하여
커스텀 리소스에 접근할 수 있다. 모든 클라이언트 라이브러리가 커스텀 리소스를 지원하는 것은 아니다.
_Go_ 와 _python_ 클라이언트 라이브러리가 지원한다.
커스텀 리소스를 추가하면 다음을 사용하여 접근할 수 있다.
- `kubectl`
- 쿠버네티스 동적 클라이언트
- 작성한 REST 클라이언트
- [쿠버네티스 클라이언트 생성 도구](https://github.com/kubernetes/code-generator)를 사용하여 생성된 클라이언트(하나를 생성하는 것은 고급 기능이지만, 일부 프로젝트는 CRD 또는 AA와 함께 클라이언트를 제공할 수 있다).
- [쿠버네티스 클라이언트 생성 도구](https://github.com/kubernetes/code-generator)를 사용하여
생성된 클라이언트(하나를 생성하는 것은 고급 기능이지만, 일부 프로젝트는
CRD 또는 AA와 함께 클라이언트를 제공할 수 있다).
## {{% heading "whatsnext" %}}
* [애그리게이션 레이어(aggregation layer)로 쿠버네티스 API 확장](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)하는 방법에 대해 배우기.
* [커스텀리소스데피니션으로 쿠버네티스 API 확장](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)하는 방법에 대해 배우기.

39
content/ko/docs/concepts/extend-kubernetes/compute-storage-net/_index.md
View File

@ -1,4 +1,43 @@
---
title: 컴퓨트, 스토리지 및 네트워킹 익스텐션
weight: 30
no_list: true
---
해당 섹션은 쿠버네티스 자체에 포함되어있지 않지만 클러스터에 설정할 수 있는 익스텐션들에 대해 다룬다.
이러한 익스텐션을 활용하여 클러스터의 노드를 향상시키거나,
파드들을 연결시키는 네트워크 장치를 제공할 수 있다.
* [CSI](/ko/docs/concepts/storage/volumes/#csi) 와 [FlexVolume](/ko/docs/concepts/storage/volumes/#flexvolume) 스토리지 플러그인
{{< glossary_tooltip text="컨테이너 스토리지 인터페이스" term_id="csi" >}} (CSI) 플러그인은
새로운 종류의 볼륨을 지원하도록 쿠버네티스를 확장할 수 있게 해준다.
볼륨은 내구성 높은 외부 스토리지에 연결되거나, 일시적인 스토리지를 제공하거나,
파일시스템 패러다임을 토대로 정보에 대한 읽기 전용 인터페이스를 제공할 수도 있다.
또한 쿠버네티스는 (CSI를 권장하며) v1.23부터 사용 중단된
[FlexVolume](/ko/docs/concepts/storage/volumes/#flexvolume-deprecated) 플러그인에 대한 지원도 포함한다.
FlexVolume 플러그인은 쿠버네티스에서 네이티브하게
지원하지 않는 볼륨 종류도 마운트할 수 있도록 해준다.
FlexVolume 스토리지에 의존하는 파드를 실행하는 경우 kubelet은 바이너리 플러그인을 호출하여 볼륨을 마운트한다.
아카이브된 [FlexVolume](https://git.k8s.io/design-proposals-archive/storage/flexvolume-deployment.md)
디자인 제안은 이러한 접근방법에 대한 자세한 설명을 포함하고 있다.
스토리지 플러그인에 대한 전반적인 정보는 [스토리지 업체를 위한 쿠버네티스 볼륨 플러그인 FAQ](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md#kubernetes-volume-plugin-faq-for-storage-vendors)에서
찾을 수 있다.
* [장치 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)
장치 플러그인은 노드에서 (`cpu`와 `memory`와 같은 내장 노드 리소스에서 추가로)
새로운 노드 장치(Node facility)를 발견할 수 있게 해주며,
이러한 커스텀 노드 장치를 요청하는 파드들에게 이를 제공한다.
* [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
네트워크 플러그인을 통해 쿠버네티스는 다양한 네트워크 토폴로지 및 기술을 활용할 수 있게 된다.
제대로 동작하는 파드 네트워크을 구성하고 쿠버네티스 네트워크 모델의 다양한 측면을 지원하기 위해
쿠버네티스 클러스터는 *네트워크 플러그인*을 필요로 한다.
쿠버네티스 {{< skew currentVersion >}}은 {{< glossary_tooltip text="CNI" term_id="cni" >}}
네트워크 플러그인들에 호환된다.

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

@ -1,12 +1,14 @@
---
title: 장치 플러그인
description: 장치 플러그인을 사용하여 GPU, NIC, FPGA, 또는 비휘발성 주 메모리와 같이 공급 업체별 설정이 필요한 장치 또는 리소스를 클러스터에서 지원하도록 설정할 수 있다.
description: >
장치 플러그인을 사용하여 GPU, NIC, FPGA, 또는 비휘발성 주 메모리와 같이 공급 업체별 설정이 필요한 장치
또는 리소스를 클러스터에서 지원하도록 설정할 수 있다.
content_type: concept
weight: 20
---
<!-- overview -->
{{< feature-state for_k8s_version="v1.10" state="beta" >}}
{{< feature-state for_k8s_version="v1.26" state="stable" >}}
쿠버네티스는 시스템 하드웨어 리소스를 {{< glossary_tooltip term_id="kubelet" >}}에 알리는 데 사용할 수 있는
[장치 플러그인 프레임워크](https://git.k8s.io/design-proposals-archive/resource-management/device-plugin.md)를
@ -33,12 +35,12 @@ service Registration {
장치 플러그인은 이 gRPC 서비스를 통해 kubelet에 자체 등록할 수 있다.
등록하는 동안, 장치 플러그인은 다음을 보내야 한다.
* 유닉스 소켓의 이름.
* 빌드된 장치 플러그인 API 버전.
* 알리려는 `ResourceName`. 여기서 `ResourceName` 은
[확장된 리소스 네이밍 체계](/ko/docs/concepts/configuration/manage-resources-containers/#확장된-리소스)를
`vendor-domain/resourcetype` 의 형식으로 따라야 한다.
(예를 들어, NVIDIA GPU는 `nvidia.com/gpu` 로 알려진다.)
* 유닉스 소켓의 이름.
* 빌드된 장치 플러그인 API 버전.
* 알리려는 `ResourceName`. 여기서 `ResourceName` 은
[확장된 리소스 네이밍 체계](/ko/docs/concepts/configuration/manage-resources-containers/#확장된-리소스)를
`vendor-domain/resourcetype` 의 형식으로 따라야 한다.
(예를 들어, NVIDIA GPU는 `nvidia.com/gpu` 로 알려진다.)
성공적으로 등록하고 나면, 장치 플러그인은 kubelet이 관리하는
장치 목록을 전송한 다음, kubelet은 kubelet 노드 상태 업데이트의 일부로
@ -102,7 +104,7 @@ spec:
rpc ListAndWatch(Empty) returns (stream ListAndWatchResponse) {}
// 컨테이너를 생성하는 동안 Allocate가 호출되어 장치
// 플러그인이 장치별 작업을 실행하고 Kubelet에 장치를
// 플러그인이 장치별 작업을 실행하고 kubelet에 장치를
// 컨테이너에서 사용할 수 있도록 하는 단계를 지시할 수 있다.
rpc Allocate(AllocateRequest) returns (AllocateResponse) {}
@ -133,17 +135,17 @@ spec:
유닉스 소켓을 통해 kubelet에 직접 등록한다.
* 성공적으로 등록하고 나면, 장치 플러그인은 서빙(serving) 모드에서 실행되며, 그 동안 플러그인은 장치 상태를
모니터링하고 장치 상태 변경 시 kubelet에 다시 보고한다.
또한 gRPC 요청 `Allocate` 를 담당한다. `Allocate` 하는 동안, 장치 플러그인은
GPU 정리 또는 QRNG 초기화와 같은 장치별 준비를 수행할 수 있다.
작업이 성공하면, 장치 플러그인은 할당된 장치에 접근하기 위한 컨테이너 런타임 구성이 포함된
`AllocateResponse` 를 반환한다. kubelet은 이 정보를
컨테이너 런타임에 전달한다.
모니터링하고 장치 상태 변경 시 kubelet에 다시 보고한다.
또한 gRPC 요청 `Allocate` 를 담당한다. `Allocate` 하는 동안, 장치 플러그인은
GPU 정리 또는 QRNG 초기화와 같은 장치별 준비를 수행할 수 있다.
작업이 성공하면, 장치 플러그인은 할당된 장치에 접근하기 위한 컨테이너 런타임 구성이 포함된
`AllocateResponse` 를 반환한다. kubelet은 이 정보를
컨테이너 런타임에 전달한다.
### kubelet 재시작 처리
장치 플러그인은 일반적으로 kubelet의 재시작을 감지하고 새로운
kubelet 인스턴스에 자신을 다시 등록할 것으로 기대된다. 현재의 구현에서, 새 kubelet 인스턴스는 시작될 때
kubelet 인스턴스에 자신을 다시 등록할 것으로 기대된다. 새 kubelet 인스턴스는 시작될 때
`/var/lib/kubelet/device-plugins` 아래에 있는 모든 기존의 유닉스 소켓을 삭제한다. 장치 플러그인은 유닉스 소켓의
삭제를 모니터링하고 이러한 이벤트가 발생하면 다시 자신을 등록할 수 있다.
@ -164,16 +166,26 @@ kubelet 인스턴스에 자신을 다시 등록할 것으로 기대된다. 현
## API 호환성
쿠버네티스 장치 플러그인 지원은 베타 버전이다. 호환되지 않는 방식으로 안정화 전에 API가
변경될 수 있다. 프로젝트로서, 쿠버네티스는 장치 플러그인 개발자에게 다음 사항을 권장한다.
과거에는 장치 플러그인의 API 버전을 반드시 kubelet의 버전과 정확하게 일치시켜야 했다.
해당 기능이 v1.12의 베타 버전으로 올라오면서 이는 필수 요구사항이 아니게 되었다.
해당 기능이 베타 버전이 된 이후로 API는 버전화되었고 그동안 변하지 않았다.
그러므로 kubelet 업그레이드를 원활하게 진행할 수 있을 것이지만,
안정화되기 전까지는 향후 API가 변할 수도 있으므로 업그레이드를 했을 때 절대로 문제가 없을 것이라고는 보장할 수는 없다.
* 향후 릴리스에서 변경 사항을 확인하자.
* 이전/이후 버전과의 호환성을 위해 여러 버전의 장치 플러그인 API를 지원한다.
{{< caution >}}
쿠버네티스의 장치 관리자 컴포넌트는 안정화된(GA) 기능이지만 _장치 플러그인 API_는 안정화되지 않았다.
장치 플러그인 API와 버전 호환성에 대한 정보는 [장치 플러그인 API 버전](/docs/reference/node/device-plugin-api-versions/)를 참고하라.
{{< caution >}}
최신 장치 플러그인 API 버전의 쿠버네티스 릴리스로 업그레이드해야 하는 노드에서 DevicePlugins 기능을 활성화하고
장치 플러그인을 실행하는 경우, 이 노드를 업그레이드하기 전에
두 버전을 모두 지원하도록 장치 플러그인을 업그레이드한다. 이 방법을 사용하면
업그레이드 중에 장치 할당이 지속적으로 작동한다.
프로젝트로서, 쿠버네티스는 장치 플러그인 개발자에게 다음 사항을 권장한다.
* 향후 릴리스에서 장치 플러그인 API의 변경 사항을 확인하자.
* 이전/이후 버전과의 호환성을 위해 여러 버전의 장치 플러그인 API를 지원하자.
최신 장치 플러그인 API 버전의 쿠버네티스 릴리스로 업그레이드해야 하는 노드에서
장치 플러그인을 실행하기 위해서는, 해당 노드를 업그레이드하기 전에
두 버전을 모두 지원하도록 장치 플러그인을 업그레이드해야 한다. 이러한 방법은
업그레이드 중에 장치 할당이 지속적으로 동작할 것을 보장한다.
## 장치 플러그인 리소스 모니터링
@ -273,8 +285,9 @@ List() 엔드포인트와 함께 사용되어야 한다. `GetAllocableResources`
노출된 기본 리소스가 변경되지 않는 한 동일하게 유지된다. 이러한 변경은 드물지만, 발생하게 된다면
(예를 들면: hotplug/hotunplug, 장치 상태 변경) 클라이언트가 `GetAlloctableResources` 엔드포인트를
호출할 것으로 가정한다.
그러나 CPU 및/또는 메모리가 갱신된 경우 `GetAllocateableResources` 엔드포인트를 호출하는 것만으로는
충분하지 않으며, Kubelet을 다시 시작하여 올바른 리소스 용량과 할당 가능(allocatable) 리소스를 반영해야 한다.
충분하지 않으며, kubelet을 다시 시작하여 올바른 리소스 용량과 할당 가능(allocatable) 리소스를 반영해야 한다.
{{< /note >}}
@ -288,12 +301,14 @@ message AllocatableResourcesResponse {
```
쿠버네티스 v1.23부터, `GetAllocatableResources`가 기본으로 활성화된다.
이를 비활성화하려면 `KubeletPodResourcesGetAllocatable` [기능 게이트(feature gate)](/ko/docs/reference/command-line-tools-reference/feature-gates/)를
끄면 된다.
이를 비활성화하려면 `KubeletPodResourcesGetAllocatable`
[기능 게이트(feature gate)](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 끄면 된다.
쿠버네티스 v1.23 이전 버전에서 이 기능을 활성화하려면 `kubelet`이 다음 플래그를 가지고 시작되어야 한다.
`--feature-gates=KubeletPodResourcesGetAllocatable=true`
```
--feature-gates=KubeletPodResourcesGetAllocatable=true
```
`ContainerDevices` 는 장치가 어떤 NUMA 셀과 연관되는지를 선언하는 토폴로지 정보를 노출한다.
NUMA 셀은 불분명한(opaque) 정수 ID를 사용하여 식별되며, 이 값은
@ -315,7 +330,8 @@ gRPC 서비스는 `/var/lib/kubelet/pod-resources/kubelet.sock` 의 유닉스
{{< feature-state for_k8s_version="v1.18" state="beta" >}}
토폴로지 관리자는 Kubelet 컴포넌트로, 리소스를 토폴로지 정렬 방식으로 조정할 수 있다. 이를 위해, 장치 플러그인 API가 `TopologyInfo` 구조체를 포함하도록 확장되었다.
토폴로지 관리자는 kubelet 컴포넌트로, 리소스를 토폴로지 정렬 방식으로 조정할 수 있다.
이를 위해, 장치 플러그인 API가 `TopologyInfo` 구조체를 포함하도록 확장되었다.
```gRPC
@ -327,9 +343,15 @@ message NUMANode {
int64 ID = 1;
}
```
토폴로지 관리자를 활용하려는 장치 플러그인은 장치 ID 및 장치의 정상 상태와 함께 장치 등록의 일부로 채워진 TopologyInfo 구조체를 다시 보낼 수 있다. 그런 다음 장치 관리자는 이 정보를 사용하여 토폴로지 관리자와 상의하고 리소스 할당 결정을 내린다.
`TopologyInfo` 는 `nil`(기본값) 또는 NUMA 노드 목록인 `nodes` 필드를 지원한다. 이를 통해 NUMA 노드에 걸쳐있을 수 있는 장치 플러그인을 게시할 수 있다.
토폴로지 관리자를 활용하려는 장치 플러그인은 장치 ID 및 장치의 정상 상태와 함께 장치 등록의 일부로 채워진 TopologyInfo 구조체를 다시 보낼 수 있다.
그런 다음 장치 관리자는 이 정보를 사용하여 토폴로지 관리자와 상의하고 리소스 할당 결정을 내린다.
`TopologyInfo` 는 `nodes` 필드에 `nil`(기본값) 또는 NUMA 노드 목록을 설정하는 것을 지원한다.
이를 통해 복수의 NUMA 노드에 연관된 장치에 대해 장치 플러그인을 설정할 수 있다.
특정 장치에 대해 `TopologyInfo`를 `nil`로 설정하거나 비어있는 NUMA 노드 목록을 제공하는 것은
장치 플러그인이 해당 장치에 대한 NUMA 선호도(affinity)를 지니지 못함을 시사한다.
장치 플러그인으로 장치에 대해 채워진 `TopologyInfo` 구조체의 예는 다음과 같다.
@ -351,8 +373,7 @@ pluginapi.Device{ID: "25102017", Health: pluginapi.Healthy, Topology:&pluginapi.
* [SocketCAN 장치 플러그인](https://github.com/collabora/k8s-socketcan)
* [Solarflare 장치 플러그인](https://github.com/vikaschoudhary16/sfc-device-plugin)
* [SR-IOV 네트워크 장치 플러그인](https://github.com/intel/sriov-network-device-plugin)
* Xilinx FPGA 장치용 [Xilinx FPGA 장치 플러그인](https://github.com/Xilinx/FPGA_as_a_Service/tree/master/k8s-fpga-device-plugin)
* Xilinx FPGA 장치용 [Xilinx FPGA 장치 플러그인](https://github.com/Xilinx/FPGA_as_a_Service/tree/master/k8s-device-plugin)
## {{% heading "whatsnext" %}}

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

@ -11,8 +11,10 @@ weight: 10
<!-- overview -->
쿠버네티스 {{< skew currentVersion >}} 버전은 클러스터 네트워킹을 위해 [컨테이너 네트워크 인터페이스](https://github.com/containernetworking/cni)(CNI) 플러그인을 지원한다.
클러스터와 호환되며 사용자의 요구 사항을 충족하는 CNI 플러그인을 사용해야 한다. 더 넓은 쿠버네티스 생태계에 다양한 플러그인이 존재한다(오픈소스 및 클로즈드 소스).
쿠버네티스 {{< skew currentVersion >}} 버전은 클러스터 네트워킹을 위해
[컨테이너 네트워크 인터페이스](https://github.com/containernetworking/cni)(CNI) 플러그인을 지원한다.
사용 중인 클러스터와 호환되며 사용자의 요구 사항을 충족하는 CNI 플러그인을 사용해야 한다.
더 넓은 쿠버네티스 생태계에 다양한 플러그인이 (오픈소스와 클로즈드 소스로) 존재한다.
CNI 플러그인은 [쿠버네티스 네트워크 모델](/ko/docs/concepts/services-networking/#쿠버네티스-네트워크-모델)을 구현해야 한다.
@ -26,7 +28,8 @@ CNI 스펙 [v1.0.0](https://github.com/containernetworking/cni/blob/spec-v1.0.0/
## 설치
네트워킹 컨텍스트에서 컨테이너 런타임은 kubelet을 위한 CRI 서비스를 제공하도록 구성된 노드의 데몬이다. 특히, 컨테이너 런타임은 쿠버네티스 네트워크 모델을 구현하는 데 필요한 CNI 플러그인을 로드하도록 구성되어야 한다.
네트워킹 컨텍스트에서 컨테이너 런타임은 kubelet을 위한 CRI 서비스를 제공하도록 구성된 노드의 데몬이다.
특히, 컨테이너 런타임은 쿠버네티스 네트워크 모델을 구현하는 데 필요한 CNI 플러그인을 로드하도록 구성되어야 한다.
{{< note >}}
쿠버네티스 1.24 이전까지는 `cni-bin-dir`과 `network-plugin` 커맨드 라인 파라미터를 사용해 kubelet이 CNI 플러그인을 관리하게 할 수도 있었다.
@ -37,28 +40,35 @@ CNI 스펙 [v1.0.0](https://github.com/containernetworking/cni/blob/spec-v1.0.0/
{{< /note >}}
컨테이너 런타임에서 CNI 플러그인을 관리하는 방법에 관한 자세한 내용은 아래 예시와 같은 컨테이너 런타임에 대한 문서를 참조하자.
- [containerd](https://github.com/containerd/containerd/blob/main/script/setup/install-cni)
- [CRI-O](https://github.com/cri-o/cri-o/blob/main/contrib/cni/README.md)
CNI 플러그인을 설치하고 관리하는 방법에 관한 자세한 내용은 해당 플러그인 또는 [네트워킹 프로바이더](/ko/docs/concepts/cluster-administration/networking/#쿠버네티스-네트워크-모델의-구현-방법) 문서를 참조한다.
- [containerd](https://github.com/containerd/containerd/blob/main/script/setup/install-cni)
- [CRI-O](https://github.com/cri-o/cri-o/blob/main/contrib/cni/README.md)
CNI 플러그인을 설치하고 관리하는 방법에 관한 자세한 내용은 해당 플러그인 또는
[네트워킹 프로바이더](/ko/docs/concepts/cluster-administration/networking/#쿠버네티스-네트워크-모델의-구현-방법) 문서를 참조하자.
## 네트워크 플러그인 요구 사항
쿠버네티스를 빌드하거나 배포하는 플러그인 개발자와 사용자들을 위해, 플러그인은 kube-proxy를 지원하기 위한 특정 설정이 필요할 수도 있다.
iptables 프록시는 iptables에 의존하며, 플러그인은 컨테이너 트래픽이 iptables에 사용 가능하도록 해야 한다.
예를 들어, 플러그인이 컨테이너를 리눅스 브릿지에 연결하는 경우, 플러그인은 `net/bridge/bridge-nf-call-iptables` sysctl을 `1` 로 설정하여 iptables 프록시가 올바르게 작동하는지 확인해야 한다.
예를 들어, 플러그인이 컨테이너를 리눅스 브릿지에 연결하는 경우, 플러그인은 `net/bridge/bridge-nf-call-iptables` sysctl을
`1`로 설정하여 iptables 프록시가 올바르게 작동하는지 확인해야 한다.
플러그인이 Linux 브리지를 사용하지 않고 대신 Open vSwitch나 다른 메커니즘을 사용하는 경우, 컨테이너 트래픽이 프록시에 대해 적절하게 라우팅되도록 해야 한다.
kubelet 네트워크 플러그인이 지정되지 않은 경우, 기본적으로 `noop` 플러그인이 사용되며, `net/bridge/bridge-nf-call-iptables=1` 을 설정하여 간단한 구성(브릿지가 있는 도커 등)이 iptables 프록시에서 올바르게 작동하도록 한다.
kubelet 네트워크 플러그인이 지정되지 않은 경우, 기본적으로 `noop` 플러그인이 사용되며,
`net/bridge/bridge-nf-call-iptables=1`을 설정하여 간단한 구성(브릿지가 있는 도커 등)이 iptables 프록시에서 올바르게 작동하도록 한다.
### 루프백 CNI
쿠버네티스 네트워크 모델을 구현하기 위해 노드에 설치된 CNI 플러그인 외에도, 쿠버네티스는 각 샌드박스(파드 샌드박스, VM 샌드박스 등)에 사용되는 루프백 인터페이스 `lo`를 제공하기 위한 컨테이너 런타임도 요구한다.
루프백 인터페이스 구현은 [CNI 루프백 플러그인](https://github.com/containernetworking/plugins/blob/master/plugins/main/loopback/loopback.go)을 재사용하거나 자체 코드를 개발하여 수행할 수 있다. ([CRI-O 예시 참조](https://github.com/cri-o/ocicni/blob/release-1.24/pkg/ocicni/util_linux.go#L91))
쿠버네티스 네트워크 모델을 구현하기 위해 노드에 설치된 CNI 플러그인 외에도, 쿠버네티스는 각 샌드박스(파드 샌드박스, VM 샌드박스 등)에
사용되는 루프백 인터페이스 `lo`를 제공하기 위한 컨테이너 런타임도 요구한다.
루프백 인터페이스 구현은 [CNI 루프백 플러그인](https://github.com/containernetworking/plugins/blob/master/plugins/main/loopback/loopback.go)을
재사용하거나 자체 코드를 개발하여 수행할 수 있다. ([CRI-O 예시 참조](https://github.com/cri-o/ocicni/blob/release-1.24/pkg/ocicni/util_linux.go#L91))
### hostPort 지원
CNI 네트워킹 플러그인은 `hostPort` 를 지원한다. CNI 플러그인 팀이 제공하는 공식 [포트맵(portmap)](https://github.com/containernetworking/plugins/tree/master/plugins/meta/portmap)
CNI 네트워킹 플러그인은 `hostPort` 를 지원한다. CNI 플러그인 팀이 제공하는 공식
[포트맵(portmap)](https://github.com/containernetworking/plugins/tree/master/plugins/meta/portmap)
플러그인을 사용하거나 portMapping 기능이 있는 자체 플러그인을 사용할 수 있다.
`hostPort` 지원을 사용하려면, `cni-conf-dir` 에 `portMappings capability` 를 지정해야 한다.
@ -97,7 +107,8 @@ CNI 네트워킹 플러그인은 `hostPort` 를 지원한다. CNI 플러그인
**실험적인 기능입니다**
CNI 네트워킹 플러그인은 파드 수신 및 송신 트래픽 셰이핑도 지원한다. CNI 플러그인 팀에서 제공하는 공식 [대역폭(bandwidth)](https://github.com/containernetworking/plugins/tree/master/plugins/meta/bandwidth)
CNI 네트워킹 플러그인은 파드 수신 및 송신 트래픽 셰이핑도 지원한다. CNI 플러그인 팀에서 제공하는
공식 [대역폭(bandwidth)](https://github.com/containernetworking/plugins/tree/master/plugins/meta/bandwidth)
플러그인을 사용하거나 대역폭 제어 기능이 있는 자체 플러그인을 사용할 수 있다.
트래픽 셰이핑 지원을 활성화하려면, CNI 구성 파일 (기본값 `/etc/cni/net.d`)에 `bandwidth` 플러그인을

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

@ -15,7 +15,7 @@ weight: 30
## 동기 부여
_오퍼레이터 패턴_은 서비스 또는 서비스 셋을 관리하는 운영자의
_오퍼레이터 패턴_ 은 서비스 또는 서비스 셋을 관리하는 운영자의
주요 목표를 포착하는 것을 목표로 한다. 특정 애플리케이션 및
서비스를 돌보는 운영자는 시스템의 작동 방식, 배포 방법 및 문제가 있는 경우
대처 방법에 대해 깊이 알고 있다.
@ -31,9 +31,11 @@ _오퍼레이터 패턴_은 서비스 또는 서비스 셋을 관리하는 운
및 실행을 자동화할 수 있고, *또한* 쿠버네티스가 수행하는 방식을
자동화할 수 있다.
쿠버네티스의 {{< glossary_tooltip text="오퍼레이터 패턴" term_id="operator-pattern" >}} 개념을 통해 쿠버네티스 코드 자체를 수정하지 않고도 {{< glossary_tooltip text="컨트롤러" term_id="controller" >}}를 하나 이상의 사용자 정의 리소스(custom resource)에 연결하여 클러스터의 동작을 확장할 수 있다.
쿠버네티스의 {{< glossary_tooltip text="오퍼레이터 패턴" term_id="operator-pattern" >}}
개념을 통해 쿠버네티스 코드 자체를 수정하지 않고도 {{< glossary_tooltip text="컨트롤러" term_id="controller" >}}를
하나 이상의 사용자 정의 리소스(custom resource)에 연결하여 클러스터의 동작을 확장할 수 있다.
오퍼레이터는 [사용자 정의 리소스](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)의
컨트롤러 역할을 하는 쿠버네티스 API의 클라이언트이다.
컨트롤러 역할을 하는 쿠버네티스 API의 클라이언트다.
## 오퍼레이터 예시 {#example}

105
content/ko/docs/concepts/overview/_index.md
View File

@ -18,9 +18,16 @@ no_list: true
<!-- body -->
쿠버네티스는 컨테이너화된 워크로드와 서비스를 관리하기 위한 이식성이 있고, 확장가능한 오픈소스 플랫폼이다. 쿠버네티스는 선언적 구성과 자동화를 모두 용이하게 해준다. 쿠버네티스는 크고, 빠르게 성장하는 생태계를 가지고 있다. 쿠버네티스 서비스, 기술 지원 및 도구는 어디서나 쉽게 이용할 수 있다.
쿠버네티스란 명칭은 키잡이(helmsman)나 파일럿을 뜻하는 그리스어에서 유래했다. K8s라는 표기는 "K"와 "s"와 그 사이에 있는 8글자를 나타내는 약식 표기이다. 구글이 2014년에 쿠버네티스 프로젝트를 오픈소스화했다. 쿠버네티스는 프로덕션 워크로드를 대규모로 운영하는 [15년 이상의 구글 경험](/blog/2015/04/borg-predecessor-to-kubernetes/)과 커뮤니티의 최고의 아이디어와 적용 사례가 결합되어 있다.
쿠버네티스는 컨테이너화된 워크로드와 서비스를 관리하기 위한 이식성이 있고, 확장가능한 오픈소스 플랫폼이다.
쿠버네티스는 선언적 구성과 자동화를 모두 용이하게 해준다. 쿠버네티스는 크고, 빠르게 성장하는 생태계를 가지고 있다.
쿠버네티스 서비스, 기술 지원 및 도구는 어디서나 쉽게 이용할 수 있다.
쿠버네티스란 명칭은 키잡이(helmsman)나 파일럿을 뜻하는 그리스어에서 유래했다. K8s라는 표기는 "K"와 "s"와
그 사이에 있는 8글자를 나타내는 약식 표기이다. 구글이 2014년에 쿠버네티스 프로젝트를 오픈소스화했다.
쿠버네티스는 프로덕션 워크로드를 대규모로 운영하는
[15년 이상의 구글 경험](/blog/2015/04/borg-predecessor-to-kubernetes/)과
커뮤니티의 최고의 아이디어와 적용 사례가 결합되어 있다.
## 여정 돌아보기
@ -29,69 +36,101 @@ no_list: true
![배포 혁명](/images/docs/Container_Evolution.svg)
**전통적인 배포 시대:**
초기 조직은 애플리케이션을 물리 서버에서 실행했었다. 한 물리 서버에서 여러 애플리케이션의 리소스 한계를 정의할 방법이 없었기에, 리소스 할당의 문제가 발생했다. 예를 들어 물리 서버 하나에서 여러 애플리케이션을 실행하면, 리소스 전부를 차지하는 애플리케이션 인스턴스가 있을 수 있고, 결과적으로는 다른 애플리케이션의 성능이 저하될 수 있었다. 이에 대한 해결책은 서로 다른 여러 물리 서버에서 각 애플리케이션을 실행하는 것이 있다. 그러나 이는 리소스가 충분히 활용되지 않는다는 점에서 확장 가능하지 않았으므로, 물리 서버를 많이 유지하기 위해서 조직에게 많은 비용이 들었다.
초기 조직은 애플리케이션을 물리 서버에서 실행했었다. 한 물리 서버에서 여러 애플리케이션의 리소스 한계를 정의할 방법이 없었기에,
리소스 할당의 문제가 발생했다. 예를 들어 물리 서버 하나에서 여러 애플리케이션을 실행하면, 리소스 전부를 차지하는 애플리케이션 인스턴스가 있을 수 있고,
결과적으로는 다른 애플리케이션의 성능이 저하될 수 있었다. 이에 대한 해결책으로 서로 다른 여러 물리 서버에서 각 애플리케이션을 실행할 수도 있다.
그러나 이는 리소스가 충분히 활용되지 않는다는 점에서 확장 가능하지 않았으며, 조직이 많은 물리 서버를 유지하는 데에 높은 비용이 들었다.
**가상화된 배포 시대:** 그 해결책으로 가상화가 도입되었다. 이는 단일 물리 서버의 CPU에서 여러 가상 시스템 (VM)을 실행할 수 있게 한다. 가상화를 사용하면 VM간에 애플리케이션을 격리하고 애플리케이션의 정보를 다른 애플리케이션에서 자유롭게 액세스 할 수 없으므로, 일정 수준의 보안성을 제공할 수 있다.
**가상화된 배포 시대:** 그 해결책으로 가상화가 도입되었다. 이는 단일 물리 서버의 CPU에서 여러 가상 시스템 (VM)을 실행할 수 있게 한다.
가상화를 사용하면 VM간에 애플리케이션을 격리하고 애플리케이션의 정보를 다른 애플리케이션에서 자유롭게 액세스할 수 없으므로, 일정 수준의 보안성을 제공할 수 있다.
가상화를 사용하면 물리 서버에서 리소스를 보다 효율적으로 활용할 수 있으며, 쉽게 애플리케이션을 추가하거나 업데이트할 수 있고 하드웨어 비용을 절감할 수 있어 더 나은 확장성을 제공한다. 가상화를 통해 일련의 물리 리소스를 폐기 가능한(disposable) 가상 머신으로 구성된 클러스터로 만들 수 있다.
가상화를 사용하면 물리 서버에서 리소스를 보다 효율적으로 활용할 수 있으며, 쉽게 애플리케이션을 추가하거나 업데이트할 수 있고
하드웨어 비용을 절감할 수 있어 더 나은 확장성을 제공한다. 가상화를 통해 일련의 물리 리소스를 폐기 가능한(disposable)
가상 머신으로 구성된 클러스터로 만들 수 있다.
각 VM은 가상화된 하드웨어 상에서 자체 운영체제를 포함한 모든 구성 요소를 실행하는 하나의 완전한 머신이다.
**컨테이너 개발 시대:** 컨테이너는 VM과 유사하지만 격리 속성을 완화하여 애플리케이션 간에 운영체제(OS)를 공유한다. 그러므로 컨테이너는 가볍다고 여겨진다. VM과 마찬가지로 컨테이너에는 자체 파일 시스템, CPU 점유율, 메모리, 프로세스 공간 등이 있다. 기본 인프라와의 종속성을 끊었기 때문에, 클라우드나 OS 배포본에 모두 이식할 수 있다.
**컨테이너 개발 시대:** 컨테이너는 VM과 유사하지만 격리 속성을 완화하여 애플리케이션 간에 운영체제(OS)를 공유한다.
그러므로 컨테이너는 가볍다고 여겨진다. VM과 마찬가지로 컨테이너에는 자체 파일 시스템, CPU 점유율, 메모리, 프로세스 공간 등이 있다.
기본 인프라와의 종속성을 끊었기 때문에, 클라우드나 OS 배포본에 모두 이식할 수 있다.
컨테이너는 다음과 같은 추가적인 혜택을 제공하기 때문에 인기가 있다.
컨테이너는 다음과 같은 추가적인 혜택을 제공하기 때문에 유명해졌다.
* 기민한 애플리케이션 생성과 배포: VM 이미지를 사용하는 것에 비해 컨테이너 이미지 생성이 보다 쉽고 효율적임.
* 지속적인 개발, 통합 및 배포: 안정적이고 주기적으로 컨테이너 이미지를 빌드해서 배포할 수 있고 (이미지의 불변성 덕에) 빠르고 효율적으로 롤백할 수 있다.
* 개발과 운영의 관심사 분리: 배포 시점이 아닌 빌드/릴리스 시점에 애플리케이션 컨테이너 이미지를 만들기 때문에, 애플리케이션이 인프라스트럭처에서 분리된다.
* 기민한 애플리케이션 생성과 배포: VM 이미지를 사용하는 것에 비해 컨테이너 이미지 생성이 보다 쉽고 효율적이다.
* 지속적인 개발, 통합 및 배포: 안정적이고 주기적으로 컨테이너 이미지를 빌드해서 배포할 수 있고 (이미지의 불변성 덕에) 빠르고
효율적으로 롤백할 수 있다.
* 개발과 운영의 관심사 분리: 배포 시점이 아닌 빌드/릴리스 시점에 애플리케이션 컨테이너 이미지를 만들기 때문에, 애플리케이션이
인프라스트럭처에서 분리된다.
* 가시성(observability): OS 수준의 정보와 메트릭에 머무르지 않고, 애플리케이션의 헬스와 그 밖의 시그널을 볼 수 있다.
* 개발, 테스팅 및 운영 환경에 걸친 일관성: 랩탑에서도 클라우드에서와 동일하게 구동된다.
* 클라우드 및 OS 배포판 간 이식성: Ubuntu, RHEL, CoreOS, 온-프레미스, 주요 퍼블릭 클라우드와 어디에서든 구동된다.
* 애플리케이션 중심 관리: 가상 하드웨어 상에서 OS를 실행하는 수준에서 논리적인 리소스를 사용하는 OS 상에서 애플리케이션을 실행하는 수준으로 추상화 수준이 높아진다.
* 느슨하게 커플되고, 분산되고, 유연하며, 자유로운 마이크로서비스: 애플리케이션은 단일 목적의 머신에서 모놀리식 스택으로 구동되지 않고 보다 작고 독립적인 단위로 쪼개져서 동적으로 배포되고 관리될 수 있다.
* 리소스 격리: 애플리케이션 성능을 예측할 수 있다.
* 리소스 사용량: 고효율 고집적.
* 애플리케이션 중심 관리: 가상 하드웨어 상에서 OS를 실행하는 수준에서 논리적인 리소스를 사용하는 OS 상에서 애플리케이션을
실행하는 수준으로 추상화 수준이 높아진다.
* 느슨하게 커플되고, 분산되고, 유연하며, 자유로운 마이크로서비스: 애플리케이션은 단일 목적의 머신에서 모놀리식 스택으로 구동되지 않고
보다 작고 독립적인 단위로 쪼개져서 동적으로 배포되고 관리될 수 있다.
* 리소스 격리: 애플리케이션 성능을 예측할 수 있다.
* 리소스 사용량: 고효율 고집적.
## 쿠버네티스가 왜 필요하고 무엇을 할 수 있나 {#why-you-need-kubernetes-and-what-can-it-do}
컨테이너는 애플리케이션을 포장하고 실행하는 좋은 방법이다. 프로덕션 환경에서는 애플리케이션을 실행하는 컨테이너를 관리하고 가동 중지 시간이 없는지 확인해야 한다. 예를 들어 컨테이너가 다운되면 다른 컨테이너를 다시 시작해야 한다. 이 문제를 시스템에 의해 처리한다면 더 쉽지 않을까?
컨테이너는 애플리케이션을 포장하고 실행하는 좋은 방법이다. 프로덕션 환경에서는 애플리케이션을 실행하는 컨테이너를 관리하고
가동 중지 시간이 없는지 확인해야 한다. 예를 들어 컨테이너가 다운되면 다른 컨테이너를 다시 시작해야 한다.
이 문제를 시스템에 의해 처리한다면 더 쉽지 않을까?
그것이 쿠버네티스가 필요한 이유이다! 쿠버네티스는 분산 시스템을 탄력적으로 실행하기 위한 프레임 워크를 제공한다. 애플리케이션의 확장과 장애 조치를 처리하고, 배포 패턴 등을 제공한다. 예를 들어, 쿠버네티스는 시스템의 카나리아 배포를 쉽게 관리 할 수 있다.
그것이 쿠버네티스가 필요한 이유이다! 쿠버네티스는 분산 시스템을 탄력적으로 실행하기 위한 프레임 워크를 제공한다.
애플리케이션의 확장과 장애 조치를 처리하고, 배포 패턴 등을 제공한다. 예를 들어, 쿠버네티스는 시스템의 카나리아 배포를 쉽게 관리할 수 있다.
쿠버네티스는 다음을 제공한다.
* **서비스 디스커버리와 로드 밸런싱**
쿠버네티스는 DNS 이름을 사용하거나 자체 IP 주소를 사용하여 컨테이너를 노출할 수 있다. 컨테이너에 대한 트래픽이 많으면, 쿠버네티스는 네트워크 트래픽을 로드밸런싱하고 배포하여 배포가 안정적으로 이루어질 수 있다.
쿠버네티스는 DNS 이름을 사용하거나 자체 IP 주소를 사용하여 컨테이너를 노출할 수 있다. 컨테이너에 대한 트래픽이 많으면,
쿠버네티스는 네트워크 트래픽을 로드밸런싱하고 배포하여 배포가 안정적으로 이루어질 수 있다.
* **스토리지 오케스트레이션**
쿠버네티스를 사용하면 로컬 저장소, 공용 클라우드 공급자 등과 같이 원하는 저장소 시스템을 자동으로 탑재 할 수 있다.
쿠버네티스를 사용하면 로컬 저장소, 공용 클라우드 공급자 등과 같이 원하는 저장소 시스템을 자동으로 탑재할 수 있다
* **자동화된 롤아웃과 롤백**
쿠버네티스를 사용하여 배포된 컨테이너의 원하는 상태를 서술할 수 있으며 현재 상태를 원하는 상태로 설정한 속도에 따라 변경할 수 있다. 예를 들어 쿠버네티스를 자동화해서 배포용 새 컨테이너를 만들고, 기존 컨테이너를 제거하고, 모든 리소스를 새 컨테이너에 적용할 수 있다.
쿠버네티스를 사용하여 배포된 컨테이너의 원하는 상태를 서술할 수 있으며 현재 상태를 원하는 상태로 설정한 속도에 따라 변경할 수 있다.
예를 들어 쿠버네티스를 자동화해서 배포용 새 컨테이너를 만들고, 기존 컨테이너를 제거하고, 모든 리소스를 새 컨테이너에 적용할 수 있다.
* **자동화된 빈 패킹(bin packing)**
컨테이너화된 작업을 실행하는데 사용할 수 있는 쿠버네티스 클러스터 노드를 제공한다. 각 컨테이너가 필요로 하는 CPU와 메모리(RAM)를 쿠버네티스에게 지시한다. 쿠버네티스는 컨테이너를 노드에 맞추어서 리소스를 가장 잘 사용할 수 있도록 해준다.
컨테이너화된 작업을 실행하는데 사용할 수 있는 쿠버네티스 클러스터 노드를 제공한다. 각 컨테이너가 필요로 하는 CPU와 메모리(RAM)를
쿠버네티스에게 지시한다. 쿠버네티스는 컨테이너를 노드에 맞추어서 리소스를 가장 잘 사용할 수 있도록 해준다.
* **자동화된 복구(self-healing)**
쿠버네티스는 실패한 컨테이너를 다시 시작하고, 컨테이너를 교체하며, '사용자 정의 상태 검사'에 응답하지 않는 컨테이너를 죽이고, 서비스 준비가 끝날 때까지 그러한 과정을 클라이언트에 보여주지 않는다.
쿠버네티스는 실패한 컨테이너를 다시 시작하고, 컨테이너를 교체하며, '사용자 정의 상태 검사'에 응답하지 않는 컨테이너를 죽이고,
서비스 준비가 끝날 때까지 그러한 과정을 클라이언트에 보여주지 않는다.
* **시크릿과 구성 관리**
쿠버네티스를 사용하면 암호, OAuth 토큰 및 SSH 키와 같은 중요한 정보를 저장하고 관리 할 수 있다. 컨테이너 이미지를 재구성하지 않고 스택 구성에 시크릿을 노출하지 않고도 시크릿 및 애플리케이션 구성을 배포 및 업데이트 할 수 있다.
쿠버네티스를 사용하면 암호, OAuth 토큰 및 SSH 키와 같은 중요한 정보를 저장하고 관리할 수 있다.
컨테이너 이미지를 재구성하지 않고 스택 구성에 시크릿을 노출하지 않고도 시크릿 및 애플리케이션 구성을 배포 및 업데이트할 수 있다.
## 쿠버네티스가 아닌 것
쿠버네티스는 전통적인, 모든 것이 포함된 Platform as a Service(PaaS)가 아니다. 쿠버네티스는 하드웨어 수준보다는 컨테이너 수준에서 운영되기 때문에, PaaS가 일반적으로 제공하는 배포, 스케일링, 로드 밸런싱과 같은 기능을 제공하며, 사용자가 로깅, 모니터링 및 알림 솔루션을 통합할 수 있다. 하지만, 쿠버네티스는 모놀리식(monolithic)이 아니어서, 이런 기본 솔루션이 선택적이며 추가나 제거가 용이하다. 쿠버네티스는 개발자 플랫폼을 만드는 구성 요소를 제공하지만, 필요한 경우 사용자의 선택권과 유연성을 지켜준다.
쿠버네티스는 전통적인, 모든 것이 포함된 Platform as a Service(PaaS)가 아니다.
쿠버네티스는 하드웨어 수준보다는 컨테이너 수준에서 운영되기 때문에, PaaS가 일반적으로 제공하는 배포, 스케일링,
로드 밸런싱과 같은 기능을 제공하며, 사용자가 로깅, 모니터링 및 알림 솔루션을 통합할 수 있다. 하지만,
쿠버네티스는 모놀리식(monolithic)이 아니어서, 이런 기본 솔루션이 선택적이며 추가나 제거가 용이하다.
쿠버네티스는 개발자 플랫폼을 만드는 구성 요소를 제공하지만, 필요한 경우 사용자의 선택권과 유연성을 지켜준다.
쿠버네티스는:
* 지원하는 애플리케이션의 유형을 제약하지 않는다. 쿠버네티스는 상태 유지가 필요 없는(stateless) 워크로드, 상태 유지가 필요한(stateful) 워크로드, 데이터 처리를 위한 워크로드를 포함해서 극단적으로 다양한 워크로드를 지원하는 것을 목표로 한다. 애플리케이션이 컨테이너에서 구동될 수 있다면, 쿠버네티스에서도 잘 동작할 것이다.
* 소스 코드를 배포하지 않으며 애플리케이션을 빌드하지 않는다. 지속적인 통합과 전달과 배포, 곧 CI/CD 워크플로우는 조직 문화와 취향에 따를 뿐만 아니라 기술적인 요구사항으로 결정된다.
* 애플리케이션 레벨의 서비스를 제공하지 않는다. 애플리케이션 레벨의 서비스에는 미들웨어(예, 메시지 버스), 데이터 처리 프레임워크(예, Spark), 데이터베이스(예, MySQL), 캐시 또는 클러스터 스토리지 시스템(예, Ceph) 등이 있다. 이런 컴포넌트는 쿠버네티스 상에서 구동될 수 있고, 쿠버네티스 상에서 구동 중인 애플리케이션이 [Open Service Broker](https://openservicebrokerapi.org/) 와 같은 이식 가능한 메커니즘을 통해 접근할 수도 있다.
* 지원하는 애플리케이션의 유형을 제약하지 않는다. 쿠버네티스는 상태 유지가 필요 없는(stateless) 워크로드,
상태 유지가 필요한(stateful) 워크로드, 데이터 처리를 위한 워크로드를 포함해서 극단적으로 다양한 워크로드를 지원하는 것을 목표로 한다.
애플리케이션이 컨테이너에서 구동될 수 있다면, 쿠버네티스에서도 잘 동작할 것이다.
* 소스 코드를 배포하지 않으며 애플리케이션을 빌드하지 않는다. 지속적인 통합과 전달과 배포, 곧 CI/CD 워크플로우는 조직 문화와
취향에 따를 뿐만 아니라 기술적인 요구사항으로 결정된다.
* 애플리케이션 레벨의 서비스를 제공하지 않는다. 애플리케이션 레벨의 서비스에는 미들웨어(예, 메시지 버스),
데이터 처리 프레임워크(예, Spark), 데이터베이스(예, MySQL), 캐시 또는 클러스터 스토리지 시스템(예, Ceph) 등이 있다.
이런 컴포넌트는 쿠버네티스 상에서 구동될 수 있고, 쿠버네티스 상에서 구동 중인 애플리케이션이
[Open Service Broker](https://openservicebrokerapi.org/)와 같은 이식 가능한 메커니즘을 통해 접근할 수도 있다.
* 로깅, 모니터링 또는 경보 솔루션을 포함하지 않는다. 개념 증명을 위한 일부 통합이나, 메트릭을 수집하고 노출하는 메커니즘을 제공한다.
* 기본 설정 언어/시스템(예, Jsonnet)을 제공하거나 요구하지 않는다. 선언적 명세의 임의적인 형식을 목적으로 하는 선언적 API를 제공한다.
* 포괄적인 머신 설정, 유지보수, 관리, 자동 복구 시스템을 제공하거나 채택하지 않는다.
* 추가로, 쿠버네티스는 단순한 오케스트레이션 시스템이 아니다. 사실, 쿠버네티스는 오케스트레이션의 필요성을 없애준다. 오케스트레이션의 기술적인 정의는 A를 먼저 한 다음, B를 하고, C를 하는 것과 같이 정의된 워크플로우를 수행하는 것이다. 반면에, 쿠버네티스는 독립적이고 조합 가능한 제어 프로세스들로 구성되어 있다. 이 프로세스는 지속적으로 현재 상태를 입력받은 의도한 상태로 나아가도록 한다. A에서 C로 어떻게 갔는지는 상관이 없다. 중앙화된 제어도 필요치 않다. 이로써 시스템이 보다 더 사용하기 쉬워지고, 강력해지며, 견고하고, 회복력을 갖추게 되며, 확장 가능해진다.
* 추가로, 쿠버네티스는 단순한 오케스트레이션 시스템이 아니다. 사실, 쿠버네티스는 오케스트레이션의 필요성을 없애준다.
오케스트레이션의 기술적인 정의는 A를 먼저 한 다음, B를 하고, C를 하는 것과 같이 정의된 워크플로우를 수행하는 것이다.
반면에, 쿠버네티스는 독립적이고 조합 가능한 제어 프로세스들로 구성되어 있다. 이 프로세스는 지속적으로 현재 상태를 입력받은
의도한 상태로 나아가도록 한다. A에서 C로 어떻게 갔는지는 상관이 없다. 중앙화된 제어도 필요치 않다. 이로써 시스템이 보다 더
사용하기 쉬워지고, 강력해지며, 견고하고, 회복력을 갖추게 되며, 확장 가능해진다.
## {{% heading "whatsnext" %}}
* [쿠버네티스 구성요소](/ko/docs/concepts/overview/components/) 살펴보기
* [쿠버네티스 API](/ko/docs/concepts/overview/kubernetes-api/) 살펴보기
* [클러스터 아키텍처](/ko/docs/concepts/architecture/) 살펴보기
* [시작하기](/ko/docs/setup/) 준비가 되었는가?
* [쿠버네티스 구성요소](/ko/docs/concepts/overview/components/) 살펴보기
* [쿠버네티스 API](/ko/docs/concepts/overview/kubernetes-api/) 살펴보기
* [클러스터 아키텍처](/ko/docs/concepts/architecture/) 살펴보기
* [시작](/ko/docs/setup/)할 준비가 되었는가?

6
content/ko/docs/concepts/overview/components.md
View File

@ -6,7 +6,7 @@ content_type: concept
description: >
쿠버네티스 클러스터는 컴퓨터 집합인 노드 컴포넌트와 컨트롤 플레인
컴포넌트로 구성된다.
weight: 20
weight: 30
card:
name: concepts
weight: 20
@ -53,8 +53,8 @@ card:
* 노드 컨트롤러: 노드가 다운되었을 때 통지와 대응에 관한 책임을 가진다.
* 잡 컨트롤러: 일회성 작업을 나타내는 잡 오브젝트를 감시한 다음, 해당 작업을
완료할 때까지 동작하는 파드를 생성한다.
* 엔드포인트 컨트롤러: 엔드포인트 오브젝트를 채운다(즉, 서비스와 파드를 연결시킨다.)
* 서비스 어카운트 & 토큰 컨트롤러: 새로운 네임스페이스에 대한 기본 계정과 API 접근 토큰을 생성한다.
* 엔드포인트슬라이스 컨트롤러: (서비스와 파드 사이의 연결고리를 제공하기 위해) 엔드포인트슬라이스(EndpointSlice) 오브젝트를 채운다
* 서비스어카운트 컨트롤러: 새로운 네임스페이스에 대한 기본 서비스어카운트(ServiceAccount)를 생성한다.
### cloud-controller-manager

25
content/ko/docs/concepts/overview/kubernetes-api.md
View File

@ -3,7 +3,7 @@
# - chenopis
title: 쿠버네티스 API
content_type: concept
weight: 30
weight: 40
description: >
쿠버네티스 API를 사용하면 쿠버네티스 오브젝트들의 상태를 쿼리하고 조작할 수 있다.
쿠버네티스 컨트롤 플레인의 핵심은 API 서버와 그것이 노출하는 HTTP API이다. 사용자와 클러스터의 다른 부분 및 모든 외부 컴포넌트는 API 서버를 통해 서로 통신한다.
@ -180,9 +180,10 @@ API 리소스는 API 그룹, 리소스 유형, 네임스페이스
동일한 기본 데이터를 제공할 수 있다.
예를 들어, 동일한 리소스에 대해 `v1` 과 `v1beta1` 이라는 두 가지 API 버전이
있다고 가정한다. 원래 API의 `v1beta1` 버전을 사용하여 오브젝트를
만든 경우, 나중에 `v1beta1` 또는 `v1` API 버전을 사용하여 해당 오브젝트를
읽거나, 업데이트하거나, 삭제할 수 있다.
있다고 가정하자. API의 `v1beta1` 버전을 사용하여 오브젝트를 만든 경우,
`v1beta1` 버전이 사용 중단(deprecated)되고 제거될 때까지는
`v1beta1` 또는 `v1` API 버전을 사용하여 해당 오브젝트를 읽거나, 업데이트하거나, 삭제할 수 있다.
그 이후부터는 `v1` API를 사용하여 계속 오브젝트에 접근하고 수정할 수 있다.
## API 변경 사항
@ -197,14 +198,18 @@ API 리소스는 API 그룹, 리소스 유형, 네임스페이스
쿠버네티스는 일반적으로 API 버전 `v1` 에서 안정 버전(GA)에 도달하면, 공식 쿠버네티스 API에
대한 호환성 유지를 강력하게 이행한다. 또한,
쿠버네티스는 가능한 경우 _베타_ API 버전에서도 호환성을 유지한다.
베타 API를 채택하면 기능이 안정된 후에도 해당 API를 사용하여 클러스터와
계속 상호 작용할 수 있다.
쿠버네티스는 공식 쿠버네티스 API의 _베타_ API 버전으로 만들어진 데이터와도 호환성을 유지하며,
해당 기능이 안정화되었을 때 해당 데이터가 안정 버전(GA)의 API 버전들에 의해 변환되고 접근될 수 있도록 보장한다.
만약 베타 API 버전을 사용했다면, 해당 API가 승급했을 때 후속 베타 버전 혹은 안정된 버전의 API로 전환해야 한다.
해당 작업은 오브젝트 접근을 위해 두 API 버전 모두 사용할 수 있는 베타 API의 사용 중단(deprecation) 시기일 때 진행하는 것이 최선이다.
베타 API의 사용 중단(deprecation) 시기가 끝나고 더 이상 사용될 수 없다면 반드시 대체 API 버전을 사용해야 한다.
{{< note >}}
쿠버네티스는 또한 _알파_ API 버전에 대한 호환성을 유지하는 것을 목표로 하지만, 일부
상황에서는 호환성이 깨진다. 알파 API 버전을 사용하는 경우, API가 변경된 경우 클러스터를
업그레이드할 때 쿠버네티스에 대한 릴리스 정보를 확인한다.
비록 쿠버네티스는 _알파_ API 버전에 대한 호환성을 유지하는 것을 목표로 하지만, 일부
상황에서 이는 불가능하다. 알파 API 버전을 사용하는 경우, 클러스터를 업그레이드해야 할 때에는
API 변경으로 인해 호환성이 깨지고 업그레이드 전에 기존 오브젝트를 전부 제거해야 하는 상황에 대비하기 위해
쿠버네티스의 릴리스 정보를 확인하자.
{{< /note >}}
API 버전 수준 정의에 대한 자세한 내용은

2
content/ko/docs/concepts/overview/working-with-objects/annotations.md
View File

@ -1,7 +1,7 @@
---
title: 어노테이션
content_type: concept
weight: 50
weight: 60
---
<!-- overview -->

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

@ -1,6 +1,7 @@
---
title: 권장 레이블
content_type: concept
weight: 100
---
<!-- overview -->

3
content/ko/docs/concepts/overview/working-with-objects/field-selectors.md
View File

@ -1,6 +1,7 @@
---
title: 필드 셀렉터
weight: 60
content_type: concept
weight: 70
---
_필드 셀렉터_ 는 한 개 이상의 리소스 필드 값에 따라 [쿠버네티스 리소스를 선택](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/)하기 위해 사용된다. 필드 셀렉터 쿼리의 예시는 다음과 같다.

2
content/ko/docs/concepts/overview/working-with-objects/finalizers.md
View File

@ -1,7 +1,7 @@
---
title: 파이널라이저
content_type: concept
weight: 60
weight: 80
---
<!-- overview -->

2
content/ko/docs/concepts/overview/working-with-objects/kubernetes-objects.md
View File

@ -8,10 +8,12 @@ card:
---
<!-- overview -->
이 페이지에서는 쿠버네티스 오브젝트가 쿠버네티스 API에서 어떻게 표현되고, 그 오브젝트를
어떻게 `.yaml` 형식으로 표현할 수 있는지에 대해 설명한다.
<!-- body -->
## 쿠버네티스 오브젝트 이해하기 {#kubernetes-objects}
*쿠버네티스 오브젝트* 는 쿠버네티스 시스템에서 영속성을 가지는 오브젝트이다. 쿠버네티스는 클러스터의 상태를

4
content/ko/docs/concepts/overview/working-with-objects/names.md
View File

@ -4,7 +4,7 @@
# - thockin
title: 오브젝트 이름과 ID
content_type: concept
weight: 20
weight: 30
---
<!-- overview -->
@ -99,5 +99,5 @@ UUID는 ISO/IEC 9834-8 과 ITU-T X.667 로 표준화 되어 있다.
## {{% heading "whatsnext" %}}
* 쿠버네티스의 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)에 대해 읽기.
* 쿠버네티스의 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)과 [어노테이션](/ko/docs/concepts/overview/working-with-objects/annotations/)에 대해 읽기.
* [쿠버네티스의 식별자와 이름](https://git.k8s.io/design-proposals-archive/architecture/identifiers.md) 디자인 문서 읽기.

33
content/ko/docs/concepts/overview/working-with-objects/namespaces.md
View File

@ -5,7 +5,7 @@
# - thockin
title: 네임스페이스
content_type: concept
weight: 30
weight: 45
---
<!-- overview -->
@ -32,6 +32,26 @@ weight: 30
구별하기 위해 {{< glossary_tooltip text="레이블" term_id="label" >}}을
사용한다.
{{< note >}}
프로덕션 클러스터의 경우, `default` 네임스페이스를 _사용하지 않는_ 것을 고려한다. 대신에, 다른 네임스페이스를 만들어 사용한다.
{{< /note >}}
## 초기 네임스페이스
쿠버네티스는 처음에 네 개의 초기 네임스페이스를 갖는다.
`default`
: 쿠버네티스에는 이 네임스페이스가 포함되어 있으므로 먼저 네임스페이스를 생성하지 않고도 새 클러스터를 사용할 수 있다.
`kube-node-lease`
: 이 네임스페이스는 각 노드와 연관된 [리스](/docs/reference/kubernetes-api/cluster-resources/lease-v1/) 오브젝트를 갖는다. 노드 리스는 kubelet이 [하트비트](/ko/docs/concepts/architecture/nodes/#하트비트)를 보내서 컨트롤 플레인이 노드의 장애를 탐지할 수 있게 한다.
`kube-public`
: 이 네임스페이스는 **모든** 클라이언트(인증되지 않은 클라이언트 포함)가 읽기 권한으로 접근할 수 있다. 이 네임스페이스는 주로 전체 클러스터 중에 공개적으로 드러나서 읽을 수 있는 리소스를 위해 예약되어 있다. 이 네임스페이스의 공개적인 성격은 단지 관례이지 요구 사항은 아니다.
`kube-system`
: 쿠버네티스 시스템에서 생성한 오브젝트를 위한 네임스페이스.
## 네임스페이스 다루기
네임스페이스의 생성과 삭제는
@ -56,15 +76,6 @@ kube-public Active 1d
kube-system Active 1d
```
쿠버네티스는 처음에 네 개의 초기 네임스페이스를 갖는다.
* `default` 다른 네임스페이스가 없는 오브젝트를 위한 기본 네임스페이스
* `kube-system` 쿠버네티스 시스템에서 생성한 오브젝트를 위한 네임스페이스
* `kube-public` 이 네임스페이스는 자동으로 생성되며 모든 사용자(인증되지 않은 사용자 포함)가 읽기 권한으로 접근할 수 있다. 이 네임스페이스는 주로 전체 클러스터 중에 공개적으로 드러나서 읽을 수 있는 리소스를 위해 예약되어 있다. 이 네임스페이스의 공개적인 성격은 단지 관례이지 요구 사항은 아니다.
* `kube-node-lease` 이 네임스페이스는 각 노드와 연관된 [리스](/docs/reference/kubernetes-api/cluster-resources/lease-v1/)
오브젝트를 갖는다. 노드 리스는 kubelet이 [하트비트](/ko/docs/concepts/architecture/nodes/#하트비트)를
보내서 컨트롤 플레인이 노드의 장애를 탐지할 수 있게 한다.
### 요청에 네임스페이스 설정하기
현재 요청에 대한 네임스페이스를 설정하기 위해서 `--namespace` 플래그를 사용한다.
@ -120,7 +131,7 @@ kubectl config view --minify | grep namespace:
대부분의 쿠버네티스 리소스(예를 들어, 파드, 서비스, 레플리케이션 컨트롤러 외)는
네임스페이스에 속한다. 하지만 네임스페이스 리소스 자체는 네임스페이스에 속하지 않는다.
그리고 [노드](/ko/docs/concepts/architecture/nodes/)나
퍼시스턴트 볼륨과 같은 저수준 리소스는 어느
[퍼시스턴트 볼륨](/ko/docs/concepts/storage/persistent-volumes/)과 같은 저수준 리소스는 어느
네임스페이스에도 속하지 않는다.
다음은 네임스페이스에 속하지 않는 쿠버네티스 리소스를 조회하는 방법이다.

2
content/ko/docs/concepts/overview/working-with-objects/object-management.md
View File

@ -1,7 +1,7 @@
---
title: 쿠버네티스 오브젝트 관리
content_type: concept
weight: 15
weight: 20
---
<!-- overview -->

5
content/ko/docs/concepts/policy/_index.md
View File

@ -4,3 +4,8 @@ weight: 90
description: >
리소스의 그룹에 적용되도록 구성할 수 있는 정책
---
{{< note >}}
쿠버네티스의 네트워크폴리시(NetworkPolicy)에 대한 설명은
[네트워크 정책](/ko//docs/concepts/services-networking/network-policies/)을 참고한다.
{{< /note >}}

65
content/ko/docs/concepts/policy/limit-range.md
View File

@ -9,21 +9,23 @@ weight: 10
<!-- overview -->
기본적으로 컨테이너는 쿠버네티스 클러스터에서 무제한 [컴퓨팅 리소스](/ko/docs/concepts/configuration/manage-resources-containers/)로 실행된다.
리소스 쿼터을 사용하면 클러스터 관리자는 {{< glossary_tooltip text="네임스페이스" term_id="namespace" >}}별로 리소스 사용과 생성을 제한할 수 있다.
네임스페이스 내에서 파드나 컨테이너는 네임스페이스의 리소스 쿼터에 정의된 만큼의 CPU와 메모리를 사용할 수 있다. 하나의 파드 또는 컨테이너가 사용 가능한 모든 리소스를 독점할 수 있다는 우려가 있다. 리밋레인지는 네임스페이스에서 리소스 할당(파드 또는 컨테이너)을 제한하는 정책이다.
쿠버네티스의 [리소스 쿼터](/ko/docs/concepts/policy/resource-quotas/)를 사용하면
클러스터 관리자(또는 _클러스터 오퍼레이터_ 라고 함)는
{{< glossary_tooltip text="네임스페이스" term_id="namespace" >}}별로
리소스(CPU 시간, 메모리 및 퍼시스턴트 스토리지) 사용과 생성을 제한할 수 있다.
네임스페이스 내에서 {{< glossary_tooltip text="파드" term_id="Pod" >}}는 네임스페이스의 리소스 쿼터에 정의된 만큼의 CPU와 메모리를 사용할 수 있다. 클러스터 운영자 또는 네임스페이스 수준 관리자는 단일 오브젝트가 네임스페이스 내에서 사용 가능한 모든 리소스를 독점하지 못하도록 하는 것에 대해 우려할 수도 있다.
리밋레인지는 네임스페이스의 각 적용 가능한 오브젝트 종류(예: 파드 또는 {{< glossary_tooltip text="퍼시스턴트볼륨클레임" term_id="persistent-volume-claim" >}})에 대해 지정할 수 있는 리소스 할당(제한 및 요청)을 제한하는 정책이다.
<!-- body -->
_리밋레인지_ 는 다음과 같은 제약 조건을 제공한다.
- 네임스페이스에서 파드 또는 컨테이너별 최소 및 최대 컴퓨팅 리소스 사용량을 지정한다.
- 네임스페이스에서 스토리지클래스별 최소 및 최대 스토리지 요청을 지정한다.
- 네임스페이스에서 {{< glossary_tooltip text="퍼시스턴트볼륨클레임" term_id="persistent-volume-claim" >}}별 최소 및 최대 스토리지 요청을 지정한다.
- 네임스페이스에서 리소스에 대한 요청과 제한 사이의 비율을 지정한다.
- 네임스페이스에서 컴퓨팅 리소스에 대한 기본 요청/제한을 설정하고 런타임에 있는 컨테이너에 자동으로 설정한다.
## 리밋레인지 활성화
쿠버네티스 1.10 버전부터 리밋레인지 지원이 기본적으로 활성화되었다.
해당 네임스페이스에 리밋레인지 오브젝트가 있는 경우
특정 네임스페이스에 리밋레인지가 지정된다.
@ -31,17 +33,47 @@ _리밋레인지_ 는 다음과 같은 제약 조건을 제공한다.
리밋레인지 오브젝트의 이름은 유효한
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
### 리밋 레인지 개요
### 리소스 제한 및 요청에 대한 제약
- 관리자는 하나의 네임스페이스에 하나의 리밋레인지를 만든다.
- 사용자는 네임스페이스에서 파드, 컨테이너 및 퍼시스턴트볼륨클레임과 같은 리소스를 생성한다.
- `LimitRanger` 어드미션 컨트롤러는 컴퓨팅 리소스 요청 사항을 설정하지 않은 모든 파드와 컨테이너에 대한 기본값과 제한을 지정하고 네임스페이스의 리밋레인지에 정의된 리소스의 최소, 최대 및 비율을 초과하지 않도록 사용량을 추적한다.
- 리밋레인지 제약 조건을 위반하는 리소스(파드, 컨테이너, 퍼시스턴트볼륨클레임)를 생성하거나 업데이트하는 경우 HTTP 상태 코드 `403 FORBIDDEN` 및 위반된 제약 조건을 설명하는 메시지와 함께 API 서버에 대한 요청이 실패한다.
- `cpu`, `memory`와 같은 컴퓨팅 리소스의 네임스페이스에서 리밋레인지가 활성화된 경우 사용자는 해당 값에
- 관리자는 네임스페이스에 리밋레인지를 생성한다.
- 사용자는 해당 네임스페이스에서 파드 또는 퍼시스턴트볼륨클레임과 같은 오브젝트를 생성하거나 생성하려고 시도한다.
- 첫째, `LimitRange` 어드미션 컨트롤러는 컴퓨팅 리소스 요구사항을 설정하지 않은 모든 파드(및 해당 컨테이너)에 대해 기본 요청 및 제한 값을 적용한다.
- 둘째, `LimitRange`는 사용량을 추적하여 네임스페이스에 존재하는 `LimitRange`에 정의된 리소스 최소, 최대 및 비율을 초과하지 않는지 확인한다.
- 리밋레인지 제약 조건을 위반하는 리소스(파드, 컨테이너, 퍼시스턴트볼륨클레임)를 생성하거나 업데이트하려고 하는 경우 HTTP 상태 코드 `403 FORBIDDEN` 및 위반된 제약 조건을 설명하는 메시지와 함께 API 서버에 대한 요청이 실패한다.
- `cpu`, `memory`와 같은 컴퓨팅 리소스의 네임스페이스에서
리밋레인지를 추가한 경우 사용자는 해당 값에
대한 요청 또는 제한을 지정해야 한다. 그렇지 않으면 시스템에서 파드 생성이 거부될 수 있다.
- 리밋레인지 유효성 검사는 파드 실행 단계가 아닌 파드 어드미션 단계에서만 발생한다.
- `LimitRange` 유효성 검사는 실행 중인 파드가 아닌 파드 어드미션 단계에서만 수행된다.
리밋레인지가 추가되거나 수정되면, 해당
네임스페이스에 이미 존재하는 파드는 변경되지 않고 계속 유지된다.
- 네임스페이스에 두 개 이상의 `LimitRange` 오브젝트가 존재하는 경우, 어떤 기본값이 적용될지는 결정적이지 않다.
리밋 레인지를 사용하여 생성할 수 있는 정책의 예는 다음과 같다.
## 파드에 대한 리밋레인지 및 어드미션 확인
`LimitRange`는 적용하는 기본값의 일관성을 확인하지 **않는다**. 즉, `LimitRange`에 의해 설정된 _limit_ 의 기본값이 클라이언트가 API 서버에 제출하는 스펙에서 컨테이너에 지정된 _request_ 값보다 작을 수 있다. 이 경우, 최종 파드는 스케줄링할 수 없다.
예를 들어, 이 매니페스트에 `LimitRange`를 정의한다.
{{< codenew file="concepts/policy/limit-range/problematic-limit-range.yaml" >}}
이 때 CPU 리소스 요청을 `700m`로 선언하지만 제한은 선언하지 않는 파드를 포함한다.
{{< codenew file="concepts/policy/limit-range/example-conflict-with-limitrange-cpu.yaml" >}}
그러면 해당 파드는 스케줄링되지 않고 다음과 유사한 오류와 함께 실패한다.
```
Pod "example-conflict-with-limitrange-cpu" is invalid: spec.containers[0].resources.requests: Invalid value: "700m": must be less than or equal to cpu limit
```
`request`와 `limit`를 모두 설정하면, 동일한 `LimitRange`가 적용되어 있어도 새 파드는 성공적으로 스케줄링된다.
{{< codenew file="concepts/policy/limit-range/example-no-conflict-with-limitrange-cpu.yaml" >}}
## 리소스 제약 예시
`LimitRange`를 사용하여 생성할 수 있는 정책의 예는 다음과 같다.
- 용량이 8GiB RAM과 16 코어인 2 노드 클러스터에서 네임스페이스의 파드를 제한하여 CPU의 최대 제한이 500m인 CPU 100m를 요청하고 메모리의 최대 제한이 600M인 메모리 200Mi를 요청하라.
- 스펙에 CPU 및 메모리 요청없이 시작된 컨테이너에 대해 기본 CPU 제한 및 요청을 150m로, 메모리 기본 요청을 300Mi로 정의하라.
@ -53,8 +85,6 @@ _리밋레인지_ 는 다음과 같은 제약 조건을 제공한다.
## {{% heading "whatsnext" %}}
자세한 내용은 [LimitRanger 디자인 문서](https://git.k8s.io/design-proposals-archive/resource-management/admission_control_limit_range.md)를 참조한다.
제한의 사용에 대한 예시는 다음을 참조한다.
- [네임스페이스당 최소 및 최대 CPU 제약 조건을 설정하는 방법](/ko/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/).
@ -63,3 +93,6 @@ _리밋레인지_ 는 다음과 같은 제약 조건을 제공한다.
- [네임스페이스당 기본 메모리 요청과 제한을 설정하는 방법](/ko/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/).
- [네임스페이스당 최소 및 최대 스토리지 사용량을 설정하는 방법](/ko/docs/tasks/administer-cluster/limit-storage-consumption/#스토리지-요청을-제한하기-위한-리밋레인지-limitrange).
- [네임스페이스당 할당량을 설정하는 자세한 예시](/ko/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/).
컨텍스트 및 기록 정보는 [LimitRanger 디자인 문서](https://git.k8s.io/design-proposals-archive/resource-management/admission_control_limit_range.md)를 참조한다.

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

@ -39,6 +39,18 @@ weight: 20
이 문제를 회피하는 방법에 대한 예제는
[연습](/ko/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)을 참고하길 바란다.
{{< note >}}
- 리소스쿼터는 `cpu` 및 `memory` 리소스의 경우, 해당 네임스페이스의 **모든**
(신규) 파드가 해당 리소스에 대한 제한을 설정하도록 강제한다.
네임스페이스에서 `cpu` 또는 `memory`에 대해 리소스 할당량을 적용하는 경우,
사용자와 다른 클라이언트는 **반드시** 제출하는 모든 새 파드에 대해
해당 리소스에 `requests` 또는 `limits` 중 하나를 지정해야 한다.
그렇지 않으면 컨트롤 플레인이 해당 파드에 대한 어드미션을 거부할 수 있다.
- 다른 리소스의 경우: 리소스쿼터는 작동하며 해당 리소스에 대한 제한이나 요청을 설정하지 않고 네임스페이스의 파드를 무시한다. 즉, 리소스 쿼터가 이 네임스페이스의 임시 스토리지를 제한하는 경우 임시 스토리지를 제한/요청하지 않고 새 파드를 생성할 수 있다.
[리밋 레인지(Limit Range)](/ko/docs/concepts/policy/limit-range/)를 사용하여
이러한 리소스에 대한 기본 요청을 자동으로 설정할 수 있다.
{{< /note >}}
리소스쿼터 오브젝트의 이름은 유효한
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names#dns-서브도메인-이름)이어야 한다.

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

@ -1,6 +1,6 @@
---
title: "스케줄링, 선점(Preemption), 축출(Eviction)"
weight: 90
weight: 95
content_type: concept
description: >
쿠버네티스에서, 스케줄링은 kubelet이 파드를 실행할 수 있도록
@ -26,8 +26,10 @@ no_list: true
* [파드 토폴로지 분배 제약 조건](/ko/docs/concepts/scheduling-eviction/topology-spread-constraints/)
* [테인트(Taints)와 톨러레이션(Tolerations)](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)
* [스케줄링 프레임워크](/docs/concepts/scheduling-eviction/scheduling-framework/)
* [동적 리소스 할당](/docs/concepts/scheduling-eviction/dynamic-resource-allocation)
* [스케줄러 성능 튜닝](/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning/)
* [확장된 리소스를 위한 리소스 빈 패킹(bin packing)](/ko/docs/concepts/scheduling-eviction/resource-bin-packing/)
* [파드 스케줄링 준비성(readiness)](/ko/docs/concepts/scheduling-eviction/pod-scheduling-readiness/)
## 파드 중단(disruption)

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

@ -1,7 +1,7 @@
---
title: API를 이용한 축출(API-initiated Eviction)
content_type: concept
weight: 70
weight: 110
---
{{< glossary_definition term_id="api-eviction" length="short" >}} </br>

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

@ -2,7 +2,7 @@
# reviewers:
# - davidopp
# - kevin-wangzefeng
# - bsalamat
# - alculquicondor
title: 노드에 파드 할당하기
content_type: concept
weight: 20
@ -144,13 +144,13 @@ kubelet이 `node-restriction.kubernetes.io/` 접두사를 갖는 레이블을
`nodeSelector`와 `nodeAffinity`를 모두 사용하는 경우,
파드가 노드에 스케줄링되려면 두 조건 *모두* 만족되어야 한다.
`nodeAffinity`에 연결된 `nodeSelectorTerms`를 여러 개 명시한 경우,
명시된 `nodeSelectorTerms` 중 하나를 만족하는 노드에도
파드가 스케줄링될 수 있다.
`nodeAffinity`의 `nodeSelectorTerms`에 여러 조건(term)을 명시한 경우,
노드가 명시된 조건 중 하나만 만족해도 파드가
해당 노드에 스케줄링될 수 있다. (조건들은 OR 연산자로 처리)
단일 `nodeSelectorTerms`와 연결된 `matchExpressions`를 여러 개 명시한 경우,
모든 `matchExpressions`를 만족하는 노드에만
파드가 스케줄링될 수 있다.
`nodeSelectorTerms`의 조건으로 단일 `matchExpressions` 필드에 여러 표현식(expression)을 명시한 경우,
모든 표현식을 동시에 만족하는 노드에만
파드가 스케줄링될 수 있다. (표현식들은 AND 연산자로 처리)
{{</note>}}
[노드 어피니티를 사용해 노드에 파드 할당](/ko/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity/)에서

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

@ -32,11 +32,11 @@ weight: 10
kube-scheduler는 원하거나 필요에 따라 자체 스케줄링 컴포넌트를
만들고 대신 사용할 수 있도록 설계되었다.
새로 생성된 모든 파드 또는 예약되지 않은 다른 파드에 대해 kube-scheduler는
실행할 최적의 노드를 선택한다. 그러나 파드의 모든 컨테이너에는
리소스에 대한 요구사항이 다르며 모든 파드에도
요구사항이 다르다. 따라서 기존 노드들은
특정 스케줄링 요구사항에 따라 필터링 되어야 한다.
kube-scheduler는 새로 생성되었거나 아직
예약되지 않은(스케줄링되지 않은) 파드를 실행할 최적의 노드를 선택한다. 파드의 컨테이너와 파드 자체는
서로 다른 요구사항을 가질 수 있으므로, 스케줄러는 파드의 특정 스케줄링 요구사항을
충족하지 않는 모든 노드를 필터링한다. 또는 API를 사용하면 파드를 생성할 때 노드를 지정할 수 있지만, 이는 드문 경우이며
특별한 경우에만 수행된다.
클러스터에서 파드에 대한 스케줄링 요구사항을 충족하는 노드를
_실행 가능한(feasible)_ 노드라고 한다. 적합한 노드가 없으면 스케줄러가

10
content/ko/docs/concepts/scheduling-eviction/node-pressure-eviction.md
View File

@ -1,13 +1,13 @@
---
title: 노드-압박 축출
content_type: concept
weight: 60
weight: 100
---
{{<glossary_definition term_id="node-pressure-eviction" length="short">}}</br>
{{<glossary_tooltip term_id="kubelet" text="kubelet">}}은
클러스터 노드의 CPU, 메모리, 디스크 공간, 파일시스템 inode와 같은 자원을 모니터링한다.
클러스터 노드의 메모리, 디스크 공간, 파일시스템 inode와 같은 자원을 모니터링한다.
이러한 자원 중 하나 이상이 특정 소모 수준에 도달하면,
kubelet은 하나 이상의 파드를 능동적으로 중단시켜
자원을 회수하고 고갈 상황을 방지할 수 있다.
@ -154,6 +154,12 @@ kubelet은 다음과 같은 하드 축출 임계값을 기본적으로 설정하
* `imagefs.available<15%`
* `nodefs.inodesFree<5%` (리눅스 노드)
이러한 하드 축출 임계값의 기본값은
매개변수가 변경되지 않은 경우에만 설정된다. 어떤 매개변수의 값을 변경한 경우,
다른 매개변수의 값은 기본값으로 상속되지 않고
0으로 설정된다. 사용자 지정 값을 제공하려면,
모든 임계값을 각각 제공해야 한다.
### 축출 모니터링 시간 간격
kubelet은 `housekeeping-interval`에 설정된 시간 간격(기본값: `10s`)마다

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

@ -4,7 +4,7 @@
# - wojtek-t
title: 파드 우선순위(priority)와 선점(preemption)
content_type: concept
weight: 70
weight: 90
---
<!-- overview -->

109
content/ko/docs/concepts/scheduling-eviction/pod-scheduling-readiness.md Normal file
View File

@ -0,0 +1,109 @@
---
title: 파드 스케줄링 준비성(readiness)
content_type: concept
weight: 40
---
<!-- overview -->
{{< feature-state for_k8s_version="v1.26" state="alpha" >}}
파드는 생성되면 스케줄링 될 준비가 된 것으로 간주된다. 쿠버네티스 스케줄러는
모든 Pending 중인 파드를 배치할 노드를 찾기 위한 철저한 조사 과정을 수행한다. 그러나 일부 파드는
오랜 기간 동안 "필수 리소스 누락" 상태에 머물 수 있다.
이러한 파드는 실제로 스케줄러(그리고 클러스터 오토스케일러와 같은 다운스트림 통합자)
불필요한 방식으로 작동하게 만들 수 있다.
파드의 `.spec.schedulingGates`를 지정하거나 제거함으로써,
파드가 스케줄링 될 준비가 되는 시기를 제어할 수 있다.
<!-- body -->
## 파드 스케줄링게이트(schedulingGates) 구성하기
`스케줄링게이트(schedulingGates)` 필드는 문자열 목록을 포함하며, 각 문자열 리터럴은
파드가 스케줄링 가능한 것으로 간주되기 전에 충족해야 하는 기준으로 인식된다. 이 필드는
파드가 생성될 때만 초기화할 수 있다(클라이언트에 의해 생성되거나, 어드미션 중에 변경될 때).
생성 후 각 스케줄링게이트는 임의의 순서로 제거될 수 있지만, 새로운 스케줄링게이트의 추가는 허용되지 않는다.
{{<mermaid>}}
stateDiagram-v2
s1: 파드 생성
s2: 파드 스케줄링 게이트됨
s3: 파드 스케줄링 준비됨
s4: 파드 실행
if: 스케줄링 게이트가 비어 있는가?
[*] --> s1
s1 --> if
s2 --> if: 스케줄링 게이트 제거됨
if --> s2: 아니오
if --> s3: 네
s3 --> s4
s4 --> [*]
{{< /mermaid >}}
## 사용 예시
파드가 스케줄링 될 준비가 되지 않았다고 표시하려면, 다음과 같이 하나 이상의 스케줄링 게이트를 생성하여 표시할 수 있다.
{{< codenew file="pods/pod-with-scheduling-gates.yaml" >}}
파드가 생성된 후에는 다음 명령을 사용하여 상태를 확인할 수 있다.
```bash
kubectl get pod test-pod
```
출력은 파드가 `SchedulingGated` 상태임을 보여준다.
```none
NAME READY STATUS RESTARTS AGE
test-pod 0/1 SchedulingGated 0 7s
```
다음 명령을 실행하여 `schedulingGates` 필드를 확인할 수도 있다.
```bash
kubectl get pod test-pod -o jsonpath='{.spec.schedulingGates}'
```
출력은 다음과 같다.
```none
[{"name":"foo"},{"name":"bar"}]
```
스케줄러에게 이 파드가 스케줄링 될 준비가 되었음을 알리기 위해, 수정된 매니페스트를 다시 적용하여
`schedulingGates`를 완전히 제거할 수 있다.
{{< codenew file="pods/pod-without-scheduling-gates.yaml" >}}
`schedulingGates`가 지워졌는지 확인하려면 다음 명령을 실행하여 확인할 수 있다.
```bash
kubectl get pod test-pod -o jsonpath='{.spec.schedulingGates}'
```
출력은 비어 있을 것이다. 그리고 다음 명령을 실행하여 최신 상태를 확인할 수 있다.
```bash
kubectl get pod test-pod -o wide
```
test-pod가 CPU/메모리 리소스를 요청하지 않았기 때문에, 이 파드의 상태는 이전의 `SchedulingGated`에서
`Running`으로 전환됐을 것이다.
```none
NAME READY STATUS RESTARTS AGE IP NODE
test-pod 1/1 Running 0 15s 10.0.0.4 node-2
```
## 가시성(Observability)
스케줄링을 시도했지만 스케줄링할 수 없다고 클레임되거나 스케줄링할 준비가 되지 않은 것으로 명시적으로 표시된 파드를
구분하기 위해 `scheduler_pending_pods` 메트릭은 `”gated"`라는 새로운 레이블과 함께 제공된다.
`scheduler_pending_pods{queue="gated"}`를 사용하여 메트릭 결과를 확인할 수 있다.
## {{% heading "whatsnext" %}}
* 자세한 내용은 [PodSchedulingReadiness KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/3521-pod-scheduling-readiness)를 참고한다.

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

@ -3,7 +3,7 @@
# - bsalamat
title: 스케줄러 성능 튜닝
content_type: concept
weight: 100
weight: 70
---
<!-- overview -->

2
content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md
View File

@ -5,7 +5,7 @@
# - bsalamat
title: 테인트(Taints)와 톨러레이션(Tolerations)
content_type: concept
weight: 40
weight: 50
---

20
content/ko/docs/concepts/scheduling-eviction/topology-spread-constraints.md
View File

@ -45,7 +45,6 @@ weight: 40
파드 토폴로지 분배 제약 조건은 이러한 설정을 할 수 있도록 하는 선언적인 방법을 제공한다.
## `topologySpreadConstraints` 필드
파드 API에 `spec.topologySpreadConstraints` 필드가 있다. 이 필드는 다음과 같이
@ -66,8 +65,8 @@ spec:
whenUnsatisfiable: <string>
labelSelector: <object>
matchLabelKeys: <list> # 선택 사항이며, v1.25에서 알파 기능으로 도입되었다.
nodeAffinityPolicy: [Honor|Ignore] # 선택 사항이며, v1.25에서 알파 기능으로 도입되었다.
nodeTaintsPolicy: [Honor|Ignore] # 선택 사항이며, v1.25에서 알파 기능으로 도입되었다.
nodeAffinityPolicy: [Honor|Ignore] # 선택 사항이며, v1.26에서 베타 기능으로 도입되었다.
nodeTaintsPolicy: [Honor|Ignore] # 선택 사항이며, v1.26에서 베타 기능으로 도입되었다.
### 파드의 다른 필드가 이 아래에 오게 된다.
```
@ -99,7 +98,7 @@ kube-scheduler가 어떻게 클러스터 내에서 기존 파드와의 관계를
{{< note >}}
`minDomains` 필드는 1.25에서 기본적으로 사용하도록 설정된 베타 필드이다. 사용을 원하지 않을 경우
`MinDomainsInPodToplogySpread` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 비활성화한다.
`MinDomainsInPodTopologySpread` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 비활성화한다.
{{< /note >}}
- `minDomains` 값을 명시하는 경우, 이 값은 0보다 커야 한다.
@ -158,9 +157,9 @@ kube-scheduler가 어떻게 클러스터 내에서 기존 파드와의 관계를
옵션의 값이 null일 경우, Honor 정책과 동일하게 동작한다.
{{< note >}}
`nodeAffinityPolicy` 필드는 1.25에서 추가된 알파 필드이다. 이 필드를 사용하려면
`nodeAffinityPolicy` 필드는 베타 필드이고 1.26에서 기본적으로 활성화되어 있다. 이 필드를 비활성화하려면
`NodeInclusionPolicyInPodTopologySpread` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)
를 활성화시켜야 한다.
를 비활성화하면 된다.
{{< /note >}}
- **nodeTaintsPolicy**는 파드 토폴로지의 스프레드 스큐(spread skew)를 계산할 때 노드 테인트(taint)를
@ -172,9 +171,9 @@ kube-scheduler가 어떻게 클러스터 내에서 기존 파드와의 관계를
옵션의 값이 null일 경우, Ignore 정책과 동일하게 동작한다.
{{< note >}}
`nodeTaintsPolicy` 필드는 1.25에서 추가된 알파 필드이다. 이 필드를 사용하려면
`nodeTaintsPolicy` 필드는 베타 필드이고 1.26에서 기본적으로 활성화되어 있다. 이 필드를 비활성화하려면
`NodeInclusionPolicyInPodTopologySpread` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)
를 활성화시켜야 한다.
를 비활성화하면 된다.
{{< /note >}}
파드에 2개 이상의 `topologySpreadConstraint`가 정의되어 있으면,
@ -202,7 +201,6 @@ kube-scheduler는 새로운 파드의 모든 제약 조건을 만족하는 노
모두 우리의 생각과 같을 것이라고 가정할 수는 없다.
{{< /note >}}
각각 다음과 같은 레이블을 갖는 4개의 노드로 구성된 클러스터가 있다고 가정한다.
```
@ -496,7 +494,7 @@ class zoneC cluster;
기본 제약 조건은
[스케줄링 프로파일](/ko/docs/reference/scheduling/config/#프로파일)내의 플러그인 인자 중 하나로 설정할 수 있다.
제약 조건은 [위에서 설명한 것과 동일한 API](#api)를 이용하여 정의되는데,
제약 조건은 [위에서 설명한 것과 동일한 API](#topologyspreadconstraints-필드)를 이용하여 정의되는데,
다만 `labelSelector`는 비워 두어야 한다.
셀렉터는 파드가 속한 서비스, 레플리카셋, 스테이트풀셋, 또는 레플리케이션 컨트롤러를 바탕으로 계산한다.
@ -581,6 +579,7 @@ profiles:
`podAffinity`
: 파드를 끌어당긴다. 조건이 충족되는 토폴로지 도메인에는
원하는 수의 파드를 얼마든지 채울 수 있다.
`podAntiAffinity`
: 파드를 밀어낸다.
이를 `requiredDuringSchedulingIgnoredDuringExecution` 모드로 설정하면
@ -616,7 +615,6 @@ profiles:
전반적인 토폴로지 도메인 집합에 대한 정보를 인지하고 동작하는
클러스터 오토스케일링 도구를 이용할 수 있다.
## {{% heading "whatsnext" %}}
- [블로그: PodTopologySpread 소개](/blog/2020/05/introducing-podtopologyspread/)에서는

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

@ -1,6 +1,6 @@
---
title: "보안"
weight: 81
weight: 85
description: >
클라우드 네이티브 워크로드를 안전하게 유지하기 위한 개념
---

13
content/ko/docs/concepts/security/multi-tenancy.md
View File

@ -1,7 +1,7 @@
---
title: 멀티 테넌시(multi-tenancy)
content_type: concept
weight: 70
weight: 80
---
<!-- overview -->
@ -27,7 +27,7 @@ _멀티 테넌시_ 라는 포괄적 용어로 통칭한다.
사용 가능한 패턴과 툴을 산정하기 위해 유스케이스를 이해하는 것이다. 일반적으로 쿠버네티스에서의 멀티 테넌시는
다양한 형태로 변형 또는 혼합이 가능하지만, 넓게는 두 가지 범주로 분류된다.
### 다수의 팀
### 다수의 팀
흔히 사용하는 멀티 테넌시의 형태는 하나 또는 그 이상의 워크로드를
운영하는 한 조직 소속의 여러 팀이 하나의 클러스터를 공유하는 형태이다. 이러한 워크로드는
@ -39,7 +39,7 @@ GitOps 컨트롤러 혹은 다른 종류의 배포 자동화 툴을 통해 간
안전하고 공평한 클러스터 공유를 위해서는
RBAC, 쿼터(quota), 네트워크 정책과 같은 쿠버네티스 정책이 필수이다.
### 다수의 고객
### 다수의 고객
다른 주요 멀티 테넌시 형태로는 서비스형소프트웨어(SaaS) 사업자가
여러 고객의 워크로드 인스턴스를 실행하는 것과 관련이 있다.
@ -217,8 +217,10 @@ _소란스러운 이웃_ 문제를 예방하기 위한 목적을 가지고 있
의해 제어될 수 있다. 테넌트 간의 엄격한 네트워크 격리가 필요한 멀티 테넌트 환경에서는,
파드 간의 통신을 거부하는 기본 정책과 모든 파드가 네임 해석(name resolution)을 위해
DNS 서버를 쿼리하도록 하는 규칙을 시작에 설정하는 것을 권고한다. 이러한 기본 정책을
기반으로 하여, 네임스페이스 내에서 통신을 허용하는 관대한 규칙을 추가할 수 있다. 이러한
방식은 요구에 따라 한 단계 더 정제할 수 있다. 이는 하나의 컨트롤 플레인 내의 파드에
기반으로 하여, 네임스페이스 내에서 통신을 허용하는 관대한 규칙을 추가할 수 있다.
또한 네임스페이스 간에 트래픽을 허용해야 하는 경우 네트워크 정책 정의의
namespaceSelector 필드에 빈 레이블 셀렉터 '{}'를 사용하지 않는 것이 좋다.
이러한 방식은 요구에 따라 한 단계 더 정제할 수 있다. 이는 하나의 컨트롤 플레인 내의 파드에
대해서만 적용된다는 것을 알아두어야 한다. 서로 다른 가상의 컨트롤 플레인에 소속된 파드는
쿠버네티스 네트워킹을 통해 통신할 수 없다.
@ -513,4 +515,3 @@ _가상 컨트롤 플레인_ 이라고 부른다.
* [Kamaji](https://github.com/clastix/kamaji)
* [vcluster](https://github.com/loft-sh/vcluster)

10
content/ko/docs/concepts/security/overview.md
View File

@ -56,13 +56,13 @@ weight: 1
IaaS 공급자 | 링크 |
-------------------- | ------------ |
Alibaba Cloud | https://www.alibabacloud.com/trust-center |
Amazon Web Services | https://aws.amazon.com/security/ |
Google Cloud Platform | https://cloud.google.com/security/ |
Huawei Cloud | https://www.huaweicloud.com/securecenter/overallsafety.html |
Amazon Web Services | https://aws.amazon.com/security |
Google Cloud Platform | https://cloud.google.com/security |
Huawei Cloud | https://www.huaweicloud.com/securecenter/overallsafety |
IBM Cloud | https://www.ibm.com/cloud/security |
Microsoft Azure | https://docs.microsoft.com/en-us/azure/security/azure-security |
Oracle Cloud Infrastructure | https://www.oracle.com/security/ |
VMWare VSphere | https://www.vmware.com/security/hardening-guides.html |
Oracle Cloud Infrastructure | https://www.oracle.com/security |
VMware vSphere | https://www.vmware.com/security/hardening-guides.html |
{{< /table >}}

134
content/ko/docs/concepts/security/pod-security-admission.md Normal file
View File

@ -0,0 +1,134 @@
---
# reviewers:
# - tallclair
# - liggitt
title: 파드 시큐리티 어드미션
description: >
파드 보안을 적용할 수 있는 파드 시큐리티 어드미션 컨트롤러에 대한
개요
content_type: concept
weight: 20
---
<!-- overview -->
{{< feature-state for_k8s_version="v1.25" state="stable" >}}
쿠버네티스 [파드 시큐리티 스탠다드](/ko/docs/concepts/security/pod-security-standards/)는
파드에 대해 서로 다른 격리 수준을 정의한다. 이러한 표준을 사용하면 파드의 동작을
명확하고 일관된 방식으로 제한하는 방법을 정의할 수 있다.
쿠버네티스는 파드 시큐리티 스탠다드를 적용하기 위해 내장된 _파드 시큐리티_
{{< glossary_tooltip text="어드미션 컨트롤러" term_id="admission-controller" >}}를 제공한다. 파드 시큐리티의 제한은
파드가 생성될 때 {{< glossary_tooltip text="네임스페이스" term_id="namespace" >}} 수준에서
적용된다.
### 내장된 파드 시큐리티 어드미션 적용
이 페이지는 쿠버네티스 v{{< skew currentVersion >}}에 대한 문서 일부이다.
다른 버전의 쿠버네티스를 실행 중인 경우, 해당 릴리즈에 대한 문서를 참고한다.
<!-- body -->
## 파드 시큐리티 수준
파드 시큐리티 어드미션은 파드의
[시큐리티 컨텍스트](/docs/tasks/configure-pod-container/security-context/) 및 기타 관련 필드인
[파드 시큐리티 스탠다드](/ko/docs/concepts/security/pod-security-standards)에 정의된 세가지 수준에 따라 요구사항을 적용한다:
`특권(privileged)`, `기본(baseline)` 그리고 `제한(restricted)`.
이러한 요구사항에 대한 자세한 내용은
[파드 시큐리티 스탠다드](/ko/docs/concepts/security/pod-security-standards) 페이지를 참고한다.
## 네임스페이스에 대한 파드 시큐리티 어드미션 레이블
이 기능이 활성화되거나 웹훅이 설치되면, 네임스페이스를 구성하여
각 네임스페이스에서 파드 보안에 사용할 어드미션 제어 모드를 정의할 수 있다.
쿠버네티스는 미리 정의된 파드 시큐리티 스탠다드 수준을 사용자가 네임스페이스에 정의하여
사용할 수 있도록 {{< glossary_tooltip term_id="label" text="레이블" >}} 집합을 정의한다.
선택한 레이블은 잠재적인 위반이 감지될 경우 {{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}이
취하는 조치를 정의한다.
{{< table caption="파드 시큐리티 어드미션 모드" >}}
모드 | 설명
:---------|:------------
**강제(enforce)** | 정책 위반 시 파드가 거부된다.
**감사(audit)** | 정책 위반이 [감사 로그](/ko/docs/tasks/debug/debug-cluster/audit/)에 감사 어노테이션 이벤트로 추가되지만, 허용은 된다.
**경고(warn)** | 정책 위반이 사용자에게 드러나도록 경고를 트리거하지만, 허용은 된다.
{{< /table >}}
네임스페이스는 일부 또는 모든 모드를 구성하거나, 모드마다 다른 수준을 설정할 수 있다.
각 모드에는, 사용되는 정책을 결정하는 두 개의 레이블이 존재한다.
```yaml
# 모드별 단계 레이블은 모드에 적용할 정책 수준을 나타낸다.
#
# 모드(MODE)는 반드시 `강제(enforce)`, `감사(audit)` 혹은 `경고(warn)`중 하나여야 한다.
# 단계(LEVEL)는 반드시 `특권(privileged)`, `기본(baseline)`, or `제한(restricted)` 중 하나여야 한다.
pod-security.kubernetes.io/<MODE>: <LEVEL>
# 선택 사항: 특정 쿠버네티스 마이너 버전(예를 들어, v{{< skew currentVersion >}})과 함께
# 제공된 버전에 정책을 고정하는 데 사용할 수 있는 모드별 버전 레이블
#
# 모드(MODE)는 반드시 `강제(enforce)`, `감사(audit)` 혹은 `경고(warn)`중 하나여야 한다.
# 버전(VERSION)은 반드시 올바른 쿠버네티스의 마이너(minor) 버전 혹은 '최신(latest)'하나여야 한다.
pod-security.kubernetes.io/<MODE>-version: <VERSION>
```
[네임스페이스 레이블로 파드 시큐리티 스탠다드 적용하기](/docs/tasks/configure-pod-container/enforce-standards-namespace-labels) 문서를 확인하여 사용 예시를 확인한다.
## 워크로드 리소스 및 파드 템플릿
파드는 {{< glossary_tooltip term_id="deployment" >}}나 {{< glossary_tooltip term_id="job">}}과 같은
[워크로드 오브젝트](/ko/docs/concepts/workloads/controllers/) 생성을 통해
간접적으로 생성되는 경우가 많다. 워크로드 오브젝트는 _파드 템플릿_을 정의하고
워크로드 리소스에 대한 {{< glossary_tooltip term_id="controller" text="컨트롤러" >}}는
해당 템플릿을 기반으로 파드를 생성한다. 위반을 조기에 발견할 수 있도록 감사 모드와 경고 모드가
모두 워크로드 리소스에 적용된다. 그러나 강제 모드에서는 워크로드 리소스에
적용되지 **않으며**, 결과가 되는 파드 오브젝트에만 적용된다.
## 면제 (exemptions)
지정된 네임스페이스와 관련된 정책으로 인해 금지된
파드 생성을 허용하기 위해 파드 보안 강제에서 _면제_ 를 정의할 수 있다.
면제는 [어드미션 컨트롤러 구성하기](/docs/tasks/configure-pod-container/enforce-standards-admission-controller/#configure-the-admission-controller)
에서 정적으로 구성할 수 있다.
면제는 명시적으로 열거해야 한다. 면제 기준을 충족하는 요청은
어드미션 컨트롤러에 의해 _무시_ 된다. 면제 기준은 다음과 같다.
- **사용자 이름(Usernames):** 면제 인증된(혹은 사칭한) 사용자 이름을 가진 사용자의 요청은
무시된다.
- **런타임 클래스 이름(RuntimeClassNames):** 면제 런타임 클래스 이름을 지정하는 파드 및 [워크로드 리소스](#워크로드-리소스-및-파드-템플릿)는
무시된다.
- **네임스페이스(Namespaces):** 파드 및 [워크로드 리소스](#워크로드-리소스-및-파드-템플릿)는 면제 네임스페이스에서 무시된다.
{{< caution >}}
대부분의 파드는 컨트롤러가 [워크로드 리소스](#워크로드-리소스-및-파드-템플릿)
에 대한 응답으로 생성되므로, 최종 사용자가 파드를 직접 생성할 때만
적용을 면제하고 워크로드 리소스를 생성할 때는 적용이 면제하지 않는다.
컨트롤러 서비스 어카운트(예로 `system:serviceaccount:kube-system:replicaset-controller`)
는 일반적으로 해당 워크로드 리소스를 생성할 수 있는 모든 사용자를 암시적으로
면제할 수 있으므로 면제해서는 안 된다.
{{< /caution >}}
다음 파드 필드에 대한 업데이트는 정책 검사에서 제외되므로, 파드 업데이트 요청이
이러한 필드만 변경하는 경우, 파드가 현재 정책 수준을 위반하더라도
거부되지 않는다.
- seccomp 또는 AppArmor 어노테이션에 대한 변경 사항을 **제외한** 모든 메타데이터 업데이트.
- `seccomp.security.alpha.kubernetes.io/pod` (사용 중단)
- `container.seccomp.security.alpha.kubernetes.io/*` (사용 중단)
- `container.apparmor.security.beta.kubernetes.io/*`
- `.spec.activeDeadlineSeconds` 에 대해 유효한 업데이트
- `.spec.tolerations` 에 대해 유효한 업데이트
## {{% heading "whatsnext" %}}
- [파드 시큐리티 스탠다드](/ko/docs/concepts/security/pod-security-standards)
- [파드 시큐리티 스탠다드 적용하기](/ko/docs/setup/best-practices/enforcing-pod-security-standards)
- [기본 제공 어드미션 컨트롤러를 구성하여 파드 시큐리티 스탠다드 적용하기](/docs/tasks/configure-pod-container/enforce-standards-admission-controller)
- [네임스페이스 레이블로 파드 시큐리티 스탠다드 적용하기](/docs/tasks/configure-pod-container/enforce-standards-namespace-labels)
- [파드시큐리티폴리시(PodSecurityPolicy)에서 내장 파드시큐리티어드미션컨트롤러(PodSecurity Admission Controller)로 마이그레이션](/docs/tasks/configure-pod-container/migrate-from-psp)

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

@ -1,7 +1,4 @@
---
# reviewers:
# - liggitt
# - tallclair
title: 파드 시큐리티 폴리시
content_type: concept
weight: 30
@ -9,15 +6,15 @@ weight: 30
<!-- overview -->
{{< feature-state for_k8s_version="v1.21" state="deprecated" >}}
{{< note >}}
{{% alert title="제거된 기능" color="warning" %}}
파드시큐리티폴리시(PodSecurityPolicy)는 쿠버네티스 1.21 버전부터 [사용 중단(deprecated)](/blog/2021/04/08/kubernetes-1-21-release-announcement/#podsecuritypolicy-deprecation)되었으며,
v1.25 버전 때 쿠버네티스에서 제거되었다.
{{% /alert %}}
파드시큐리티폴리시를 사용하는 것 대신, 다음 중 하나를 사용하거나 둘 다 사용하여 파드에 유사한 제한을
적용할 수 있다.
- [파드 시큐리티 어드미션](/docs/concepts/security/pod-security-admission/)
- [파드 시큐리티 어드미션](/ko/docs/concepts/security/pod-security-admission/)
- 직접 배포하고 구성할 수 있는 서드파티 어드미션 플러그인
마이그레이션에 관한 설명이 필요하다면 [파드시큐리티폴리시(PodSecurityPolicy)에서 빌트인 파드시큐리티어드미션컨트롤러(PodSecurity Admission Controller)로 마이그레이션](/docs/tasks/configure-pod-container/migrate-from-psp/)을 참고한다.
@ -26,4 +23,3 @@ v1.25 버전 때 쿠버네티스에서 제거되었다.
쿠버네티스 v{{< skew currentVersion >}} 이외의 버전을 실행 중이라면,
해당 쿠버네티스 버전에 대한 문서를 확인한다.
{{< /note >}}

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

@ -445,7 +445,7 @@ weight: 10
메커니즘이 발달함에 따라, 아래와 같이 정책별로 정의가 될 것이다.
개별 정책에 대한 시행 방식은 여기서 정의하고 있지 않는다.
[**파드 시큐리티 어드미션 컨트롤러**](/docs/concepts/security/pod-security-admission/)
[**파드 시큐리티 어드미션 컨트롤러**](/ko/docs/concepts/security/pod-security-admission/)
- {{< example file="security/podsecurity-privileged.yaml" >}}특권 네임스페이스{{< /example >}}
- {{< example file="security/podsecurity-baseline.yaml" >}}기본 네임스페이스{{< /example >}}
@ -506,7 +506,7 @@ v1.24 이전 Kubelet은 파드 OS 필드를 필수로 요구하지 않으며,
시큐리티 프로필은 컨트롤 플레인 메커니즘으로, 시큐리티 컨텍스트의 상세 설정을 비롯하여
시큐리티 컨텍스트 외부의 다른 관련된 파라미터도 적용한다.
2021년 7월부로, [파드 시큐리티 폴리시](/ko/docs/concepts/security/pod-security-policy/)는
내장된 [파드 시큐리티 어드미션 컨트롤러](/docs/concepts/security/pod-security-admission/)에 의해 대체되어 사용이 중단되었다.
내장된 [파드 시큐리티 어드미션 컨트롤러](/ko/docs/concepts/security/pod-security-admission/)에 의해 대체되어 사용이 중단되었다.
### 샌드박스 파드는 어떠한가?

2
content/ko/docs/concepts/security/rbac-good-practices.md
View File

@ -111,7 +111,7 @@ weight: 60
더 나아가 권한을 상승시킬 수 있는 가능성도 존재한다.
특정 사용자 혹은, 적절히 안정 및 격리 된 파드를 생성할 수 있는 자격을 가진 다른 주체를 완전히 신뢰하지 못하는 상황이라면,
**베이스라인** 혹은 **제한된** 파드 시큐리티 스탠다드를 사용해야 한다.
이는 [파드 시큐리티 어드미션](/docs/concepts/security/pod-security-admission/)
이는 [파드 시큐리티 어드미션](/ko/docs/concepts/security/pod-security-admission/)
또는 다른 (서드 파티) 매커니즘을 통해 시행할 수 있다.
이러한 이유로, 네임스페이스는 서로 다른 수준의 보안 또는 테넌시가 필요한 리소스들을 분리하는 데 사용해야

116
content/ko/docs/concepts/security/secrets-good-practices.md Normal file
View File

@ -0,0 +1,116 @@
---
title: 쿠버네티스 시크릿 모범 사례
description: >
클러스터 운영자와 애플리케이션 개발자를 위한 모범 시크릿 관리 규칙 및 사례.
content_type: concept
weight: 70
---
<!-- overview -->
{{<glossary_definition prepend="쿠버네티스에서 시크릿은"
term_id="secret" length="all">}}
다음 모범 사례는 클러스터 관리자와 애플리케이션 개발자 모두를 위한 것이다.
이 가이드라인을 사용하여 시크릿 오브젝트에 있는
민감한 정보의 보안을 개선하고
시크릿을 보다 효과적으로 관리할 수 있다.
<!-- body -->
## 클러스터 관리자
이 섹션에서는 클러스터 관리자가 클러스터의 기밀 정보 보안을 개선하는 데
사용할 수 있는 모범 사례를 제공한다.
### 저장된 데이터(at rest)에 암호화 구성
기본적으로 시크릿 오브젝트는 {{<glossary_tooltip term_id="etcd" text="etcd">}}에
암호화되지 않은 상태로 저장된다. 따라서 `etcd`의 시크릿 데이터에 암호화를 구성해야 한다.
자세한 내용은
[Encrypt Secret Data at Rest](/docs/tasks/administer-cluster/encrypt-data/)를 참고한다.
### 시크릿에 대한 최소 권한 접근 구성 {#least-privilege-secrets}
쿠버네티스 {{<glossary_tooltip term_id="rbac" text="역할 기반 접근 제어 (RBAC)">}}
[(RBAC)](/ko/docs/reference/access-authn-authz/rbac/)와 같은 접근 제어 메커니즘을 계획할 때,
`Secret` 오브젝트에 대한 접근에 대해 다음 가이드라인을 고려한다. 또한
[역할 기반 접근 제어 (RBAC) 모범 사례](/ko/docs/concepts/security/rbac-good-practices)의
다른 가이드라인도 따라야 한다.
- **컴포넌트**: 가장 권한이 높은 시스템 수준의 구성 요소에 대해서만
`watch`나 `list` 액세스를 제한한다. 컴포넌트의 정상 동작에 필요한 경우에만
시크릿에 대한 `get` 액세스를 허용한다.
- **사람**: 시크릿에 `get`, `watch` 또는 `list` 액세스를 제한한다. 클러스터 관리자에게만
`etcd`에 대한 액세스를 허용한다. 여기에는 읽기 전용 액세스가 포함된다. 특정 어노테이션을
사용하여 시크릿에 대한 액세스를 제한하는 등의 더 복잡한 액세스 제어를 수행하려면
써드파티(third-party) 권한 부여 메커니즘을 사용하는 것을 고려한다.
{{< caution >}}
시크릿에 대한 `list` 액세스 권한을 부여하면 주체가 암시적으로
시크릿의 내용을 가져갈 수 있다.
{{< /caution >}}
시크릿을 사용하는 파드를 생성할 수 있는 사용자는 해당 시크릿의 값도 볼 수 있다.
클러스터 정책에서 사용자가 시크릿을 직접 읽는 것을 허용하지 않더라도,
동일한 사용자가 시크릿을 노출하는 파드를 실행할 수 있다.
이 액세스 권한을 가진 사용자가 의도적이든 의도적이지 않든 시크릿 데이터를 노출시켜
발생할 수 있는 영향을 감지하거나 제한할 수 있다.
몇 가지 권장 사항은 다음과 같다.
* 수명이 짧은 시크릿 사용
* 한 사용자가 여러 비밀을 동시에 읽는 것과 같은 특정 이벤트에 대해
경고하는 감사 규칙 구현
### etcd 관리 정책 개선
더 이상 사용하지 않는다면 `etcd`에서 사용하는 내구성 스토리지를
지우거나 파쇄하는 것을 고려한다.
여러 개의 `etcd` 인스턴스가 있는 경우, 인스턴스 간에 암호화된 SSL/TLS 통신을 구성하여
전송 중(in transit)인 시크릿 데이터를 보호한다.
### 외부 시크릿에 대한 액세스 구성
{{% thirdparty-content %}}
써드파티 시크릿 저장소 공급자를 사용하여 기밀 데이터를 클러스터 외부에 보관한 다음
해당 정보에 액세스하도록 파드를 구성할 수 있다.
[쿠버네티스 시크릿 스토어 CSI 드라이버](https://secrets-store-csi-driver.sigs.k8s.io/)는
kubelet이 외부 스토어에서 시크릿을 검색하고
접근 권한을 부여한 특정 파드에 시크릿을 볼륨으로 마운트할 수 있도록 하는
데몬셋(DaemonSet)이다.
지원되는 제공자 목록은 다음을 참고한다.
[시크릿 스토어 CSI 드라이버 제공자](https://secrets-store-csi-driver.sigs.k8s.io/concepts.html#provider-for-the-secrets-store-csi-driver).
## 개발자
이 섹션은 개발자가 쿠버네티스 리소스를 구축하고 배포할 때
기밀 데이터의 보안을 개선하기 위해 사용할 수 있는 모범 사례를 제공한다.
### 특정 컨테이너에 시크릿 액세스 제한
파드에 여러 개의 컨테이너를 정의하고 있고 그 중 하나만 시크릿에 접근해야 하는 경우,
볼륨 마운트 또는 환경 변수 구성을 정의하여
다른 컨테이너가 해당 시크릿에 액세스하지 못하도록
한다.
### 읽기 후 시크릿 데이터 보호
애플리케이션은 환경 변수나 볼륨에서 기밀 정보를 읽은 후에도 그 값을 보호해야 한다.
예를 들어, 애플리케이션은 시크릿 데이터를 로그에 남기거나
신뢰할 수 없는 상대에게
전송하지 않아야 한다.
### 시크릿 매니페스트 공유 방지
시크릿 데이터가 base64로 인코딩된
{{< glossary_tooltip text="매니페스트" term_id="manifest" >}}를 통해 시크릿을 구성하는 경우,
이 파일을 공유하거나 소스 리포지토리에 체크인하면 매니페스트를 읽을 수 있는 모든 사람이
시크릿을 사용할 수 있다는 것을 의미한다.
{{<caution>}}
Base64 인코딩은 암호화 방식이 _아니며_, 일반 텍스트에 비해 추가적인
기밀성을 제공하지 않는다.
{{</caution>}}

14
content/ko/docs/concepts/services-networking/_index.md
View File

@ -49,5 +49,15 @@ NAT 없이 모든 노드의 모든 파드와 통신할 수 있다.
쿠버네티스 네트워킹은 다음의 네 가지 문제를 해결한다.
- 파드 내의 컨테이너는 루프백(loopback)을 통한 [네트워킹을 사용하여 통신](/ko/docs/concepts/services-networking/dns-pod-service/)한다.
- 클러스터 네트워킹은 서로 다른 파드 간의 통신을 제공한다.
- [서비스 리소스](/ko/docs/concepts/services-networking/service/)를 사용하면 [파드에서 실행 중인 애플리케이션을 클러스터 외부에서 접근](/ko/docs/concepts/services-networking/connect-applications-service/)할 수 있다.
- 또한 서비스를 사용하여 [서비스를 클러스터 내부에서만 사용할 수 있도록 게시](/ko/docs/concepts/services-networking/service-traffic-policy/)할 수 있다.
- [서비스](/ko/docs/concepts/services-networking/service/) API를 사용하면
[파드에서 실행 중인 애플리케이션을 클러스터 외부에서 접근](/ko/docs/tutorials/services/connect-applications-service/)
할 수 있다.
- [인그레스](/ko/docs/concepts/services-networking/ingress/)는
특히 HTTP 애플리케이션, 웹사이트 그리고 API를 노출하기 위한 추가 기능을 제공한다.
- 또한 서비스를 사용하여
[서비스를 클러스터 내부에서만 사용할 수 있도록 게시](/ko/docs/concepts/services-networking/service-traffic-policy/)할 수 있다.
- [서비스와 애플리케이션 연결하기](/ko/docs/tutorials/services/connect-applications-service/) 튜토리얼에서는 실습 예제를 통해 서비스와 쿠버네티스 네트워킹에 대해 배울 수 있다.
[클러스터 네트워킹](/ko/docs/concepts/cluster-administration/networking/)은
클러스터에 네트워킹을 설정하는 방법과 관련된 기술에 대한 개요도 제공한다.

148
content/ko/docs/concepts/services-networking/cluster-ip-allocation.md Normal file
View File

@ -0,0 +1,148 @@
---
# reviewers:
# - sftim
# - thockin
title: 서비스 클러스터IP 할당
content_type: concept
weight: 120
---
<!-- overview -->
쿠버네티스에서 [서비스](/ko/docs/concepts/services-networking/service/)는 파드 집합에서
실행되는 애플리케이션을 노출하는 추상적인 방법이다. 서비스는
(`type: ClusterIP`인 서비스를 통해) 클러스터-범위의 가상 IP 주소를 가진다.
클라이언트는 해당 가상 IP 주소로 접속할 수 있으며, 쿠버네티스는 해당 서비스를 거치는 트래픽을
서비스 뒷단의 파드들에게 로드 밸런싱한다.
<!-- body -->
## 어떻게 서비스 클러스터IP가 할당되는가?
쿠버네티스가 서비스에 가상 IP를 할당해야 할 때,
해당 요청분에는 두가지 방법 중 하나가 수행된다.
_동적 할당_
: 클러스터의 컨트롤 플레인이 자동으로 `type: ClusterIP` 서비스의 설정된 IP 범위 내에서 가용 IP 주소를 선택한다.
_정적 할당_
: 서비스용으로 설정된 IP 범위 내에서 사용자가 IP 주소를 선택한다.
클러스터 전체에 걸쳐, 모든 서비스의 `ClusterIP`는 항상 고유해야 한다.
이미 할당된 특정 `ClusterIP`로 서비스를 생성하려고 하면
에러가 발생한다.
## 왜 서비스 클러스터 IP를 예약해야 하는가?
때로는 클러스터의 다른 컴포넌트들이나 사용자들이 사용할 수 있도록 이미 알려진 IP 주소를 통해
서비스를 실행하고 싶을 것이다.
가장 좋은 방법은 클러스터의 DNS 서비스이다.
가벼운 관례로 일부 쿠버네티스 설치 관리자들은 DNS 서비스의 10번째 주소를 서비스 IP 범위로 지정한다.
클러스터의 서비스 IP 범위가 10.96.0.0/16 인 상황에서 DNS 서비스 IP를 10.96.0.10 으로 지정하고 싶다면,
아래와 같이 서비스를 생성해야 할 것이다.
```yaml
apiVersion: v1
kind: Service
metadata:
labels:
k8s-app: kube-dns
kubernetes.io/cluster-service: "true"
kubernetes.io/name: CoreDNS
name: kube-dns
namespace: kube-system
spec:
clusterIP: 10.96.0.10
ports:
- name: dns
port: 53
protocol: UDP
targetPort: 53
- name: dns-tcp
port: 53
protocol: TCP
targetPort: 53
selector:
k8s-app: kube-dns
type: ClusterIP
```
하지만 이전에도 설명했듯이, IP 주소 10.96.0.10는 예약된 상태가 아니다. 만약 다른 서비스들이
그 전에 동적 할당으로 생성되었거나, 동시에 생성되었다면, 해당 서비스들이 IP를 할당받았을 수도 있다.
따라서, 충돌 에러로 인해 DNS 서비스를 생성하지 못할 것이다.
## 어떻게 하면 서비스 클러스터IP 충돌을 피할 수 있는가? {#avoid-ClusterIP-conflict}
쿠버네티스에 구현된 할당 전략은
서비스에 클러스터IP 할당의 충돌 위험을 줄여준다.
`ClusterIP` 범위는 16 이상 256 미만의 단계적인 차수를 나타내는
`min(max(16, cidrSize / 16), 256)` 공식을 기반으로 나누어져 있다.
동적 IP 할당은 기본값으로 위쪽 밴드를 사용한다. 위쪽 범위가 모두 소진되었다면 아래쪽 밴드를
사용할 것이다. 이것은 사용자로 하여금 아래쪽 밴드의 정적 할당을 낮은 충돌 확률로 수행할 수 있게
해준다.
## 예시 {#allocation-examples}
### 예시 1 {#allocation-example-1}
아래 예시는 서비스 IP 주소들로 10.96.0.0/24 (CIDR 표기법) IP 주소 범위를
사용한다.
범위 크기: 2<sup>8</sup> - 2 = 254
밴드 오프셋: `min(max(16, 256/16), 256)` = `min(16, 256)` = 16
정적 밴드 시작점: 10.96.0.1
정적 밴드 끝점: 10.96.0.16
범위 끝점: 10.96.0.254
{{< mermaid >}}
pie showData
title 10.96.0.0/24
"정적" : 16
"동적" : 238
{{< /mermaid >}}
### 예시 2 {#allocation-example-2}
아래 예시는 서비스 IP 주소들로 10.96.0.0/20 (CIDR 표기법) IP 주소 범위를
사용한다.
범위 크기: 2<sup>12</sup> - 2 = 4094
밴드 오프셋: `min(max(16, 4096/16), 256)` = `min(256, 256)` = 256
정적 밴드 시작점: 10.96.0.1
정적 밴드 끝점: 10.96.1.0
범위 끝점: 10.96.15.254
{{< mermaid >}}
pie showData
title 10.96.0.0/20
"정적" : 256
"동적" : 3838
{{< /mermaid >}}
### 예시 3 {#allocation-example-3}
아래 예시는 서비스 IP 주소들로 10.96.0.0/16 (CIDR 표기법) IP 주소 범위를
사용한다.
범위 크기: 2<sup>16</sup> - 2 = 65534
밴드 오프셋: `min(max(16, 65536/16), 256)` = `min(4096, 256)` = 256
정적 밴드 시작점: 10.96.0.1
정적 밴드 끝점: 10.96.1.0
범위 끝점: 10.96.255.254
{{< mermaid >}}
pie showData
title 10.96.0.0/16
"정적" : 256
"동적" : 65278
{{< /mermaid >}}
## {{% heading "whatsnext" %}}
* [클라이언트 소스 IP 보존하기](/ko/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip)에 대해 알아보기
* [서비스와 애플리케이션 연결하기](/ko/docs/tutorials/services/connect-applications-service/)에 대해 알아보기
* [서비스](/ko/docs/concepts/services-networking/service/)에 대해 알아보기

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

@ -1,10 +1,14 @@
---
# reviewers:
# - davidopp
# - jbelamaric
# - bowei
# - thockin
title: 서비스 및 파드용 DNS
content_type: concept
weight: 20
weight: 80
description: >-
워크로드는 DNS를 사용하여 클러스터 내의 서비스들을 발견할 수 있다;
이 페이지는 이것이 어떻게 동작하는지를 설명한다.
---
<!-- overview -->
@ -13,13 +17,11 @@ weight: 20
<!-- body -->
## 소개
쿠버네티스는 DNS를 설정 하기 위해 사용되는
파드와 서비스에 대한 정보를 발행한다. Kubelet은 실행 중인 컨테이너가
IP가 아닌 이름으로 서비스를 검색할 수 있도록 파드의 DNS를 설정한다.
쿠버네티스 DNS는 클러스터의 서비스와 DNS 파드를 관리하며,
개별 컨테이너들이 DNS 네임을 해석할 때
DNS 서비스의 IP를 사용하도록 kubelets를 구성한다.
클러스터 내의 모든 서비스(DNS 서버 자신도 포함하여)에는 DNS 네임이 할당된다.
클러스터 내의 서비스에는 DNS 네임이 할당된다.
기본적으로 클라이언트 파드의 DNS 검색 리스트는 파드 자체의 네임스페이스와
클러스터의 기본 도메인을 포함한다.
@ -49,8 +51,8 @@ search <namespace>.svc.cluster.local svc.cluster.local cluster.local
options ndots:5
```
요약하면, _test_ 네임스페이스에 있는 파드는 `data.prod` 또는
`data.prod.svc.cluster.local` 중 하나를 통해 성공적으로 해석될 수 있다.
요약하면, _test_ 네임스페이스에 있는 파드는, `prod` 네임스페이스에 있는 `data` 파드를 가리키는 도메인 이름인
`data.prod` 또는 `data.prod.svc.cluster.local` 을 성공적으로 해석할 수 있다.
### DNS 레코드
@ -69,29 +71,28 @@ options ndots:5
### A/AAAA 레코드
"노멀"(헤드리스가 아닌) 서비스는 서비스 IP 계열에 따라
"노멀"(헤드리스가 아닌) 서비스는 서비스의 IP family 혹은 IP families 에 따라
`my-svc.my-namespace.svc.cluster-domain.example`
형식의 이름을 가진 DNS A 또는 AAAA 레코드가 할당된다. 이는 서비스의 클러스터
IP로 해석된다.
"헤드리스"(클러스터 IP가 없는) 서비스 또한 서비스 IP 계열에 따라
`my-svc.my-namespace.svc.cluster-domain.example`
형식의 이름을 가진 DNS A 또는 AAAA 레코드가 할당된다.
노멀 서비스와는 다르게 이는 서비스에 의해 선택된 파드들의 IP 집합으로 해석된다.
[헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)
(클러스터 IP가 없는) 또한 `my-svc.my-namespace.svc.cluster-domain.example`
형식의 이름을 가진 DNS A 또는 AAAA 레코드가 할당된다. 노멀 서비스와는 달리
이는 서비스에 의해 선택된 파드들의 IP 집합으로 해석된다.
클라이언트는 해석된 IP 집합에서 IP를 직접 선택하거나 표준 라운드로빈을
통해 선택할 수 있다.
### SRV 레코드
SRV 레코드는 노멀 서비스 또는
[헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)에
속하는 네임드 포트를 위해 만들어졌다. 각각의 네임드 포트에 대해서 SRV 레코드는 다음과 같은 형식을 가질 수 있다.
`_my-port-name._my-port-protocol.my-svc.my-namespace.svc.cluster-domain.example`.
정규 서비스의 경우, 이는 포트 번호와 도메인 네임으로 해석된다.
SRV 레코드는 노멀 서비스 또는 헤드리스 서비스에 속하는 네임드 포트를 위해 만들어졌다.
각각의 네임드 포트에 대해서 SRV 레코드는 다음과 같은 형식을 갖는다.
`_port-name._port-protocol.my-svc.my-namespace.svc.cluster-domain.example`.
정규 서비스의 경우, 이는 포트 번호와 도메인 네임으로 해석된다:
`my-svc.my-namespace.svc.cluster-domain.example`.
헤드리스 서비스의 경우, 서비스를 지원하는 각 파드에 대해 하나씩 복수 응답으로 해석되며 이 응답은 파드의
포트 번호와 도메인 이름을 포함한다.
`auto-generated-name.my-svc.my-namespace.svc.cluster-domain.example`.
`hostname.my-svc.my-namespace.svc.cluster-domain.example`.
## 파드
@ -112,17 +113,25 @@ SRV 레코드는 노멀 서비스 또는
### 파드의 hostname 및 subdomain 필드
파드가 생성되면 hostname은 해당 파드의 `metadata.name` 값이 된다.
파드가 생성되면 hostname(파드 내부에서 확인된 것 처럼)은
해당 파드의 `metadata.name` 값이 된다.
파드 스펙(Pod spec)에는 선택적 필드인 `hostname`이 있다.
이 필드는 파드의 호스트네임을 지정할 수 있다.
`hostname` 필드가 지정되면, 파드의 이름보다 파드의 호스트네임이 우선시된다.
예를 들어 `hostname` 필드가 "`my-host`"로 설정된 파드는 호스트네임이 "`my-host`"로 설정된다.
파드 스펙(Pod spec)에는 선택적 필드인 `hostname`이 있다. 이 필드는
다른 호스트네임을 지정할 수 있다. `hostname` 필드가 지정되면, 파드의 이름보다
파드의 호스트네임이 우선시된다.(역시 파드 내에서 확인된 것 처럼) 예를 들어,
`spec.hostname` 필드가 "`my-host`"로 설정된 파드는
호스트네임이 "`my-host`"로 설정된다.
또한, 파드 스펙에는 선택적 필드인 `subdomain`이 있다. 이 필드는 서브도메인을 지정할 수 있다.
예를 들어 "`my-namespace`" 네임스페이스에서, `hostname` 필드가 "`foo`"로 설정되고,
`subdomain` 필드가 "`bar`"로 설정된 파드는 전체 주소 도메인 네임(FQDN)을 가지게 된다.
"`foo.bar.my-namespace.svc.cluster-domain.example`".
또한, 파드 스펙에는 선택적 필드인 `subdomain`이 있다. 이 필드는 파드가 네임스페이스의
서브 그룹의 일부임을 나타낼 수 있다. 예를 들어 "`my-namespace`" 네임스페이스에서, `spec.hostname` 필드가
"`foo`"로 설정되고, `spec.subdomain` 필드가 "`bar`"로 설정된 파드는
전체 주소 도메인 네임(FQDN)을 가지게 된다.
"`foo.bar.my-namespace.svc.cluster-domain.example`" (다시 한 번, 파드 내부 에서
확인된 것 처럼).
파드와 동일한 네임스페이스 내에 같은 서브도메인 이름을 가진
헤드리스 서비스가 있다면, 클러스터의 DNS 서버는
파드의 전체 주소 호스트네임(fully qualified hostname)인 A 또는 AAAA 레코드를 반환한다.
예시:
@ -130,15 +139,14 @@ SRV 레코드는 노멀 서비스 또는
apiVersion: v1
kind: Service
metadata:
name: default-subdomain
name: busybox-subdomain
spec:
selector:
name: busybox
clusterIP: None
ports:
- name: foo # 사실 포트는 필요하지 않다.
- name: foo # 단일 포트 서비스에 이름은 필수사항이 아니다.
port: 1234
targetPort: 1234
---
apiVersion: v1
kind: Pod
@ -148,7 +156,7 @@ metadata:
name: busybox
spec:
hostname: busybox-1
subdomain: default-subdomain
subdomain: busy-subdomain
containers:
- image: busybox:1.28
command:
@ -164,7 +172,7 @@ metadata:
name: busybox
spec:
hostname: busybox-2
subdomain: default-subdomain
subdomain: busy-subdomain
containers:
- image: busybox:1.28
command:
@ -173,24 +181,20 @@ spec:
name: busybox
```
파드와 동일한 네임스페이스 내에 같은 서브도메인 이름을 가진 헤드리스 서비스가 있다면,
클러스터의 DNS 서버는 파드의 전체 주소 호스트네임(fully qualified hostname)인 A 또는 AAAA 레코드를 반환한다.
예를 들어 호스트네임이 "`busybox-1`"이고,
서브도메인이 "`default-subdomain`"이고,
같은 네임스페이스 내 헤드리스 서비스의 이름이 "`default-subdomain`"이면,
파드는 다음과 같이 자기 자신의 FQDN을 얻게 된다.
"`busybox-1.default-subdomain.my-namespace.svc.cluster-domain.example`".
DNS는 위 FQDN에 대해 파드의 IP를 가리키는 A 또는 AAAA 레코드를 제공한다.
"`busybox1`"와 "`busybox2`" 파드 모두 각 파드를 구분 가능한 A 또는 AAAA 레코드를 가지고 있다.
위의 주어진 서비스 "`busybox-subdomain`"과 `spec.subdomain`이
"`busybox-subdomain`"으로 설정된 파드에서, 첫번째 파드는 다음과 같은 자기 자신의 FQDN을 확인하게 된다.
"`busybox-1.busybox-subdomain.my-namespace.svc.cluster-domain.example`". DNS는
위 FQDN에 대해 파드의 IP를 가리키는 A 또는 AAAA 레코드를 제공한다. "`busybox1`"와
"`busybox2`" 파드 모두 각 파드의 주소 레코드를 갖게 된다.
엔드포인트 오브젝트는 `hostname` 필드를
임의의 엔드포인트 IP 주소로 지정할 수 있다.
{{<glossary_tooltip term_id="endpoint-slice" text="엔드포인트슬라이스(EndpointSlice)">}}는
임의의 엔드포인트 주소에 대해 해당 IP와 함께 DNS 호스트 네임을 지정할 수 있다.
{{< note >}}
A 또는 AAAA 레코드는 파드의 이름으로 생성되지 않기 때문에
A 와 AAAA 레코드는 파드의 이름으로 생성되지 않기 때문에
파드의 A 또는 AAAA 레코드를 생성하기 위해서는 `hostname` 필드를 작성해야 한다.
`hostname` 필드는 없고 `subdomain` 필드만 있는 파드는 파드의 IP 주소를 가리키는 헤드리스 서비스의
A 또는 AAAA 레코드만 생성할 수 있다. (`default-subdomain.my-namespace.svc.cluster-domain.example`)
A 또는 AAAA 레코드만 생성할 수 있다. (`busybox-subdomain.my-namespace.svc.cluster-domain.example`)
또한 서비스에서 `publishNotReadyAddresses=True` 를 설정하지 않았다면, 파드가 준비 상태가 되어야 레코드를 가질 수 있다.
{{< /note >}}
@ -198,7 +202,11 @@ A 또는 AAAA 레코드만 생성할 수 있다. (`default-subdomain.my-namespac
{{< feature-state for_k8s_version="v1.22" state="stable" >}}
파드가 전체 주소 도메인 이름(FQDN)을 갖도록 구성된 경우, 해당 호스트네임은 짧은 호스트네임이다. 예를 들어, 전체 주소 도메인 이름이 `busybox-1.default-subdomain.my-namespace.svc.cluster-domain.example` 인 파드가 있는 경우, 기본적으로 해당 파드 내부의 `hostname` 명령어는 `busybox-1` 을 반환하고 `hostname --fqdn` 명령은 FQDN을 반환한다.
파드가 전체 주소 도메인 이름(FQDN)을 갖도록 구성된 경우,
해당 호스트네임은 짧은 호스트네임이다.
예를 들어, 전체 주소 도메인 이름이 `busybox-1.busybox-subdomain.my-namespace.svc.cluster-domain.example` 인 파드가 있는 경우,
기본적으로 해당 파드 내부의 `hostname` 명령어는 `busybox-1` 을 반환하고
`hostname --fqdn` 명령은 FQDN을 반환한다.
파드 명세에서 `setHostnameAsFQDN: true` 를 설정하면, kubelet은 파드의 FQDN을 해당 파드 네임스페이스의 호스트네임에 기록한다. 이 경우, `hostname` 과 `hostname --fqdn` 은 모두 파드의 FQDN을 반환한다.
@ -214,18 +222,20 @@ DNS 정책은 파드별로 설정할 수 있다.
현재 쿠버네티스는 다음과 같은 파드별 DNS 정책을 지원한다.
이 정책들은 파드 스펙의 `dnsPolicy` 필드에서 지정할 수 있다.
- "`Default`": 파드는 파드가 실행되고 있는 노드로부터 네임 해석 설정(the name resolution configuration)을 상속받는다.
자세한 내용은
[관련 논의](/ko/docs/tasks/administer-cluster/dns-custom-nameservers)에서
- "`Default`": 파드는 파드가 실행되고 있는 노드로부터
네임 해석 설정(the name resolution configuration)을 상속받는다.
자세한 내용은 [관련 논의](/ko/docs/tasks/administer-cluster/dns-custom-nameservers)에서
확인할 수 있다.
- "`ClusterFirst`": "`www.kubernetes.io`"와 같이 클러스터 도메인 suffix 구성과
일치하지 않는 DNS 쿼리는 노드에서 상속된 업스트림 네임서버로 전달된다.
일치하지 않는 DNS 쿼리는 DNS 서버에 의해 업스트림 네임서버로 전달된다.
클러스터 관리자는 추가 스텁-도메인(stub-domain)과 업스트림 DNS 서버를 구축할 수 있다.
그러한 경우 DNS 쿼리를 어떻게 처리하는지에 대한 자세한 내용은
[관련 논의](/ko/docs/tasks/administer-cluster/dns-custom-nameservers)에서
확인할 수 있다.
- "`ClusterFirstWithHostNet`": hostNetwork에서 running 상태인 파드의 경우 DNS 정책인
"`ClusterFirstWithHostNet`"을 명시적으로 설정해야 한다.
"`ClusterFirstWithHostNet`"을 명시적으로 설정해야 한다. 그렇지 않으면,
hostNetwork와 `"ClusterFirst"`로 실행되고 있는 파드는
`"Default"` 정책으로 동작한다.
- 참고: 윈도우에서는 지원되지 않는다.상세 정보는 [아래](#dns-windows)에서 확인한다.
- "`None`": 이 정책은 파드가 쿠버네티스 환경의 DNS 설정을 무시하도록 한다.
모든 DNS 설정은 파드 스펙 내에 `dnsConfig`필드를 사용하여 제공해야 한다.
@ -313,16 +323,24 @@ search default.svc.cluster-domain.example svc.cluster-domain.example cluster-dom
options ndots:5
```
#### 확장된 DNS 환경 설정
## DNS 탐색 도메인 리스트 제한
{{< feature-state for_k8s_version="1.22" state="alpha" >}}
{{< feature-state for_k8s_version="1.26" state="beta" >}}
쿠버네티스는 파드의 DNS 환경 설정을 위해 기본적으로 최대 6개의 탐색 도메인과
최대 256자의 탐색 도메인 목록을 허용한다.
쿠버네티스는 탐색 도메인 리스트가 32개를 넘거나 모든 탐색 도메인의 길이가 2048자를
초과할 때까지 DNS Config에 자체적인 제한을 하지 않는다.
이 제한은 노드의 resolver 설정 파일, 파드의 DNS Config,
그리고 합쳐진 DNS Config에 각각 적용된다.
kube-apiserver와 kubelet에 `ExpandedDNSConfig` 기능 게이트가 활성화되어 있으면,
쿠버네티스는 최대 32개의 탐색 도메인과
최대 2048자의 탐색 도메인 목록을 허용한다.
{{< note >}}
이전 버전의 일부 컨테이너 런타임은 DNS 탐색 도메인 수에 대해
자체적인 제한을 가지고 있을 수 있다. 컨테이너 런타임 환경에 따라
많은 수의 DNS 검색 도메인을 갖는 파드는
pending 상태로 고착될 수 있다.
containerd v1.5.5 혹은 그 이전 그리고 CRI-O v1.21 혹은 그 이전에서 이러한 문제가
발생하는 것으로 알려졌다.
{{< /note >}}
## 윈도우 노드에서 DNS 해석(resolution) {#dns-windows}

6
content/ko/docs/concepts/services-networking/dual-stack.md
View File

@ -1,5 +1,9 @@
---
title: IPv4/IPv6 이중 스택
description: >-
쿠버네티스는 단일 스택 IPv4 네트워킹,
단일 스택 IPv6 네트워킹 혹은 두 네트워크 패밀리를 활성화한
이중 스택 네트워킹 설정할 수 있도록 해준다. 이 페이지는 이 방법을 설명한다.
feature:
title: IPv4/IPv6 이중 스택
description: >
@ -10,7 +14,7 @@ content_type: concept
# - khenidak
# - aramase
# - bridgetkromhout
weight: 70
weight: 90
---
<!-- overview -->

99
content/ko/docs/concepts/services-networking/endpoint-slices.md
View File

@ -3,7 +3,11 @@
# - freehan
title: 엔드포인트슬라이스
content_type: concept
weight: 45
weight: 60
description: >-
엔드포인트슬라이스 API는 서비스가 대규모 백엔드를 처리할 수 있도록 확장할 수 있게 해주고,
클러스터가 정상적인 백엔드의 리스트를 효율적으로 업데이트 할 수 있도록
쿠버네티스가 사용하는 메커니즘이다.
---
@ -11,32 +15,13 @@ weight: 45
{{< feature-state for_k8s_version="v1.21" state="stable" >}}
_엔드포인트슬라이스_ 는 쿠버네티스 클러스터 내의 네트워크 엔드포인트를
추적하는 간단한 방법을 제공한다. 이것은 엔드포인트를 더 확장하고, 확장 가능한
쿠버네티스의 _엔드포인트슬라이스_ API 는 쿠버네티스 클러스터 내의 네트워크 엔드포인트를
추적하는 방법을 제공한다. 엔드포인트슬라이스는 [엔드포인트](/ko/docs/concepts/services-networking/service/#endpoints)보다 더 유동적이고, 확장 가능한
대안을 제안한다.
<!-- body -->
## 사용동기
엔드포인트 API는 쿠버네티스에서 네트워크 엔드포인트를 추적하는
간단하고 직접적인 방법을 제공한다. 불행하게도 쿠버네티스 클러스터와
{{< glossary_tooltip text="서비스" term_id="service" >}}가 더 많은 수의 백엔드 파드로
더 많은 트래픽을 처리하고 전송하는 방향으로 성장함에 따라, 이 API의 한계가 더욱 눈에 띄게
되었다.
특히나, 많은 수의 네트워크 엔드포인트로 확장하는 것에
어려움이 있었다.
이후로 서비스에 대한 모든 네트워크 엔드포인트가 단일 엔드포인트
리소스에 저장되기 때문에 엔드포인트 리소스가 상당히 커질 수 있다. 이것은 쿠버네티스
구성요소 (특히 마스터 컨트롤 플레인)의 성능에 영향을 미쳤고
엔드포인트가 변경될 때 상당한 양의 네트워크 트래픽과 처리를 초래했다.
엔드포인트슬라이스는 이러한 문제를 완화하고 토폴로지 라우팅과
같은 추가 기능을 위한 확장 가능한 플랫폼을 제공한다.
## 엔드포인트슬라이스 리소스 {#endpointslice-resource}
## 엔드포인트슬라이스 API {#endpointslice-resource}
쿠버네티스에서 엔드포인트슬라이스는 일련의 네트워크 엔드포인트에 대한
참조를 포함한다. 쿠버네티스 서비스에 {{< glossary_tooltip text="셀렉터"
@ -48,8 +33,8 @@ term_id="selector" >}}가 지정되면 컨트롤 플레인은 자동으로
엔드포인트슬라이스 오브젝트의 이름은 유효한
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
예를 들어, 여기에 `example` 쿠버네티스 서비스를 위한 엔드포인트슬라이스
리소스 샘플이 있다.
예를 들어, 여기에 `example` 쿠버네티스 서비스가 소유하는 엔드포인트슬라이스
객체 샘플이 있다.
```yaml
apiVersion: discovery.k8s.io/v1
@ -81,8 +66,7 @@ endpoints:
엔드포인트슬라이스는 내부 트래픽을 라우트하는 방법에 대해
{{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}}에
신뢰할 수 있는 소스로 역할을 할 수 있다. 이를 활성화 하면, 많은 수의 엔드포인트를 가지는
서비스에 대해 성능 향상을 제공해야 한다.
신뢰할 수 있는 소스로 역할을 할 수 있다.
### 주소 유형
@ -92,12 +76,16 @@ endpoints:
* IPv6
* FQDN (전체 주소 도메인 이름)
### 조건
각 엔드포인트슬라이스 객체는 특정한 IP 주소 유형을 나타낸다.
IPv4와 IPv6를 사용할 수 있는 서비스가 있을 경우,
최소 두개의 엔드포인트슬라이스 객체가 존재한다(IPv4를 위해 하나, IPv6를 위해 하나).
### 컨디션
엔드포인트슬라이스 API는 컨슈머에게 유용한 엔드포인트에 대한 조건을 저장한다.
조건은 `준비`, `제공` 및 `종료` 세 가지가 있다.
조건은 `ready`, `serving` 및 `Terminating` 세 가지가 있다.
#### 준비
#### Ready
`ready`는 파드의 `Ready` 조건에 매핑되는 조건이다. `Ready` 조건이 `True`로 설정된 실행 중인 파드는
이 엔드포인트슬라이스 조건도 `true`로 설정되어야 한다. 호환성의
@ -106,7 +94,7 @@ endpoints:
이 규칙의 유일한 예외는 `spec.publishNotReadyAddresses`가 `true`로 설정된 서비스이다.
이러한 서비스의 엔드 포인트는 항상 `ready`조건이 `true`로 설정된다.
#### 제공(Serving)
#### Serving
{{< feature-state for_k8s_version="v1.22" state="beta" >}}
@ -125,14 +113,14 @@ endpoints:
{{< /note >}}
#### 종료(Terminating)
#### Terminating
{{< feature-state for_k8s_version="v1.22" state="beta" >}}
`종료(Terminating)`는 엔드포인트가 종료되는지 여부를 나타내는 조건이다.
파드의 경우 삭제 타임 스탬프가 설정된 모든 파드이다.
### 토폴로지 정보 {#토폴로지}
### 토폴로지 정보 {#topology}
엔드포인트슬라이스 내의 각 엔드 포인트는 관련 토폴로지 정보를 포함할 수 있다.
토폴로지 정보에는 엔드 포인트의 위치와 해당 노드 및
@ -242,11 +230,48 @@ v1 API의 `zone` 필드로 접근할 수 있다.
엔드포인트슬라이스 변경의 특성으로 인해, 엔드포인트는 동시에 둘 이상의
엔드포인트슬라이스에 표시될 수 있다. 이는 다른 엔드포인트슬라이스 오브젝트에
대한 변경 사항이 다른 시간에서의 쿠버네티스 클라이언트 워치(watch)/캐시에
도착할 수 있기 때문에 자연스럽게 발생한다. 엔드포인트슬라이스를 사용하는 구현은
엔드포인트가 둘 이상의 슬라이스에 표시되도록 할 수 있어야 한다. 엔드포인트
중복 제거를 수행하는 방법에 대한 레퍼런스 구현은 `kube-proxy` 의
도착할 수 있기 때문에 자연스럽게 발생한다.
{{< note >}}
엔드포인트슬라이스 API의 클라이언트는 반드시 서비스에 연관된 모든 존재하는 엔드포인트슬라이스에 대해
반복하고, 고유한 각 네트워크 엔드포인트들의 완전한 리스트를 구성해야 한다. 엔드포인트는 다른
엔드포인트슬라이스에서 중복될 수 있음에 유의한다.
엔드포인트 집계와 중복 제거 방법에 대한 레퍼런스 구현은 `kube-proxy` 의
`EndpointSliceCache` 구현에서 찾을 수 있다.
{{< /note >}}
## 엔드포인트와 비교 {#motivation}
기존 엔드포인트 API는 쿠버네티스에서 네트워크 엔드포인트를 추적하는
간단하고 직접적인 방법을 제공했다. 쿠버네티스 클러스터와
{{< glossary_tooltip text="서비스" term_id="service" >}}가 더 많은 수의 백엔드 파드로
더 많은 트래픽을 처리하고 전송하는 방향으로 성장함에 따라, 이 API의 한계가 더욱 눈에 띄게
되었다.
특히나, 많은 수의 네트워크 엔드포인트로 확장하는 것에
어려움이 있었다.
서비스에 대한 모든 네트워크 엔드포인트가 단일 엔드포인트
객체에 저장되기 때문에 이러한 엔드포인트 객체들이 상당히 커지는 경우도 있었다. 안정적인
서비스(오랜 기간 동안 같은 엔드포인트 세트)의 경우 영향은
비교적 덜 눈에 띄지만, 여전히 쿠버네티스의 일부 사용 사례들은 잘 처리되지 않았다.
서비스가 많은 백엔드 엔드포인트를 가지고
워크로드가 자주 증가하거나, 새로운 변경사항이 자주 롤 아웃 될 경우,
해당 서비스의 단일 엔드포인트 객체에 대한 각 업데이트는
쿠버네티스 클러스터 컴포넌트 사이(컨트롤 플레인 내, 그리고 노드와 API 서버 사이)에
상당한 네트워크 트래픽이 발생할 것임을 의미했다.
이러한 추가 트래픽은 또한 CPU 사용 관점에서도 굉장한 비용을 발생시켰다.
엔드포인트슬라이스 사용 시, 단일 파드를 추가하거나 삭제하는 작업은 (다수의 파드를 추가/삭제하는 작업과 비교했을 때)
해당 변경을 감시하고 있는 클라이언트에 동일한 _수_의 업데이트를 트리거한다.
하지만, 파드 대규모 추가/삭제의 경우 업데이트 메시지의 크기는 훨씬 작다.
엔드포인트슬라이스는 듀얼 스택 네트워킹과 토폴로지 인식 라우팅과 같은
새로운 기능에 대한 혁신을 가능하게 했다.
## {{% heading "whatsnext" %}}
* [서비스와 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)를 읽어보기
* [서비스와 애플리케이션 연결하기](/ko/docs/tutorials/services/connect-applications-service/) 튜토리얼을 따라하기
* [엔드포인트슬라이스 API 레퍼런스](/docs/reference/kubernetes-api/service-resources/endpoint-slice-v1/) 를 읽어보기
* [엔드포인트 API 레퍼런스](/docs/reference/kubernetes-api/service-resources/endpoints-v1/) 를 읽어보기

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

@ -1,8 +1,12 @@
---
title: 인그레스 컨트롤러
# reviewers:
description: >-
클러스터 내의 [인그레스](/ko/docs/concepts/services-networking/ingress/)가 작동하려면,
인그레스 컨트롤러가 실행되고 있어야 한다.
적어도 하나의 인그레스 컨트롤러를 선택하고 이를 클러스터 내에 설치한다.
이 페이지는 배포할 수 있는 일반적인 인그레스 컨트롤러를 나열한다.
content_type: concept
weight: 40
weight: 50
---
<!-- overview -->
@ -59,12 +63,11 @@ weight: 40
## 여러 인그레스 컨트롤러 사용
하나의 클러스터 내에 [여러 개의 인그레스 컨트롤러](https://git.k8s.io/ingress-nginx/docs/user-guide/multiple-ingress.md#multiple-ingress-controllers)를 배포할 수 있다.
인그레스를 생성할 때, 클러스터 내에 둘 이상의 인그레스 컨트롤러가 존재하는 경우
어떤 인그레스 컨트롤러를 사용해야 하는지 표시해주는 적절한 [`ingress.class`](https://git.k8s.io/ingress-gce/docs/faq/README.md#how-do-i-run-multiple-ingress-controllers-in-the-same-cluster)
어노테이션을 각각의 인그레스에 달아야 한다.
하나의 클러스터 내에 [인그레스 클래스](/ko/docs/concepts/services-networking/ingress/#ingress-class)를 이용하여 여러 개의 인그레스 컨트롤러를 배포할 수 있다.
`.metadata.name` 필드를 확인해둔다. 인그레스를 생성할 때 인그레스 오브젝트([IngressSpec v1 참고](/docs/reference/kubernetes-api/service-resources/ingress-v1/#IngressSpec))의 `ingressClassName` 필드에 해당 이름을 명시해야 한다. `ingressClassName`은 이전 [어노테이션 방식](/ko/docs/concepts/services-networking/ingress/#사용중단-deprecated-어노테이션)의 대체 수단이다.
만약 클래스를 정의하지 않으면, 클라우드 제공자는 기본 인그레스 컨트롤러를 사용할 수 있다.
인그레스에 대한 인그레스 클래스를 설정하지 않았고, 클러스터에 기본으로 설정된 인그레스 클래스가 정확히 하나만 존재하는 경우, 쿠버네티스는 클러스터의 기본 인그레스 클래스를 인그레스에 [적용](/ko/docs/concepts/services-networking/ingress/#default-ingress-class)한다.
인그레스 클래스에 [`ingressclass.kubernetes.io/is-default-class` 어노테이션](/ko/docs/reference/labels-annotations-taints/#ingressclass-kubernetes-io-is-default-class)을 문자열 값 `"true"`로 설정하여, 해당 인그레스 클래스를 기본으로 설정할 수 있다.
이상적으로는 모든 인그레스 컨트롤러가 이 사양을 충족해야 하지만,
다양한 인그레스 컨트롤러는 약간 다르게 작동한다.

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

@ -3,7 +3,12 @@
# - bprashanth
title: 인그레스(Ingress)
content_type: concept
weight: 40
description: >-
URI, 호스트네임, 경로 등과 같은 웹 개념을 이해하는 프로토콜-인지형(protocol-aware configuration) 설정 메커니즘을 이용하여
HTTP (혹은 HTTPS) 네트워크 서비스를 사용 가능하게 한다.
인그레스 개념은 쿠버네티스 API를 통해 정의한 규칙에 기반하여 트래픽을 다른 백엔드에
매핑할 수 있게 해준다.
weight: 30
---
<!-- overview -->
@ -95,7 +100,7 @@ weight: 40
보내기 전에 호스트와 경로가 모두 수신 요청의 내용과
일치해야 한다.
* 백엔드는 [서비스 문서](/ko/docs/concepts/services-networking/service/) 또는 [사용자 정의 리소스 백엔드](#resource-backend)에 설명된 바와 같이
서비스와 포트 이름의 조합이다. 호스트와 규칙 경로가 일치하는 인그레스에 대한
서비스와 포트 이름의 조합이다. 규칙의 호스트와 경로가 일치하는 인그레스에 대한
HTTP(와 HTTPS) 요청은 백엔드 목록으로 전송된다.
`defaultBackend` 는 종종 사양의 경로와 일치하지 않는 서비스에 대한 모든 요청을 처리하도록 인그레스

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

@ -5,7 +5,12 @@
# - danwinship
title: 네트워크 정책
content_type: concept
weight: 50
weight: 70
description: >-
IP 주소 또는 포트 수준(OSI 계층 3 또는 4)에서 트래픽 흐름을 제어하려는 경우,
네트워크 정책은 클러스터 내의 트래픽 흐름뿐만 아니라
파드와 외부 간의 규칙을 정의할 수 있도록 해준다.
클러스터는 반드시 네트워크 정책을 지원하는 네트워크 플러그인을 사용해야 한다.
---
<!-- overview -->

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

@ -4,7 +4,7 @@
# - imroc
title: 토폴로지 키를 사용하여 토폴로지-인지 트래픽 라우팅
content_type: concept
weight: 10
weight: 150
---
@ -18,7 +18,6 @@ weight: 10
더 이상 사용되지 않는다.
쿠버네티스 v1.21에 도입된 [토폴로지 인지 힌트](/ko/docs/concepts/services-networking/topology-aware-hints/)는
유사한 기능을 제공한다.
{{</ note >}}
_서비스 토폴로지_ 를 활성화 하면 서비스는 클러스터의 노드 토폴로지를
@ -195,11 +194,7 @@ spec:
- "*"
```
## {{% heading "whatsnext" %}}
* [서비스 토폴로지 활성화하기](/docs/tasks/administer-cluster/enabling-service-topology)를 읽어보기.
* [서비스와 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)를 읽어보기.
* [토폴로지 인지 힌트](/ko/docs/concepts/services-networking/topology-aware-hints/)를 읽어보기.
* [서비스와 애플리케이션 연결하기](/ko/docs/tutorials/services/connect-applications-service/)를 읽어보기.

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

@ -3,13 +3,18 @@
# - maplain
title: 서비스 내부 트래픽 정책
content_type: concept
weight: 45
weight: 120
description: >-
클러스터 내의 두 파드가 통신을 하려고 하고 두 파드가 동일한 노드에서 실행되는 경우,
_서비스 내부 트래픽 정책_을 사용하여 네트워크 트래픽을 해당 노드 안에서 유지할 수 있다.
클러스터 네트워크를 통한 왕복 이동을 피하면 안전성, 성능
(네트워크 지연 및 처리량) 혹은 비용 측면에 도움이 될 수 있다.
---
<!-- overview -->
{{< feature-state for_k8s_version="v1.23" state="beta" >}}
{{< feature-state for_k8s_version="v1.26" state="stable" >}}
_서비스 내부 트래픽 정책_ 을 사용하면 내부 트래픽 제한이 트래픽이 시작된
노드 내의 엔드포인트로만 내부 트래픽을 라우팅하도록 한다.
@ -20,9 +25,6 @@ _서비스 내부 트래픽 정책_ 을 사용하면 내부 트래픽 제한이
## 서비스 내부 트래픽 정책 사용
`ServiceInternalTrafficPolicy` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)는
베타 기능이며 기본적으로 활성화되어 있다.
이 기능이 활성화되어 있으면,
{{< glossary_tooltip text="서비스" term_id="service" >}}의
`.spec.internalTrafficPolicy`를 `Local`로 설정하여 내부 전용 트래픽 정책을 활성화 할 수 있다.
이것은 kube-proxy가 클러스터 내부 트래픽을 위해 노드 내부 엔드포인트로만 사용하도록 한다.
@ -56,12 +58,10 @@ spec:
kube-proxy는 `spec.internalTrafficPolicy` 의 설정에 따라서 라우팅되는
엔드포인트를 필터링한다.
이것을 `Local`로 설정하면, 노드 내부 엔드포인트만 고려한다.
이 설정이 `Cluster`이거나 누락되었다면 모든 엔드포인트를 고려한다.
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)의
`ServiceInternalTrafficPolicy`를 활성화한다면, `spec.internalTrafficPolicy`는 기본값 "Cluster"로 설정된다.
이 설정이 `Cluster`(기본)이거나 설정되지 않았다면 모든 엔드포인트를 고려한다.
## {{% heading "whatsnext" %}}
* [토폴로지 인지 힌트](/ko/docs/concepts/services-networking/topology-aware-hints/)에 대해서 읽기
* [서비스 외부 트래픽 정책](/ko/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip)에 대해서 읽기
* [서비스와 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/) 읽기
* [서비스와 애플리케이션 연결하기](/ko/docs/tutorials/services/connect-applications-service/) 를 따라하기

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

@ -6,7 +6,9 @@ feature:
title: 서비스 디스커버리와 로드 밸런싱
description: >
쿠버네티스를 사용하면 익숙하지 않은 서비스 디스커버리 메커니즘을 사용하기 위해 애플리케이션을 수정할 필요가 없다. 쿠버네티스는 파드에게 고유한 IP 주소와 파드 집합에 대한 단일 DNS 명을 부여하고, 그것들 간에 로드-밸런스를 수행할 수 있다.
description: >-
외부와 접하는 단일 엔드포인트 뒤에 있는 클러스터에서 실행되는 애플리케이션을 노출시키며,
이는 워크로드가 여러 백엔드로 나뉘어 있는 경우에도 가능하다.
content_type: concept
weight: 10
---
@ -59,9 +61,10 @@ _서비스_ 로 들어가보자.
### 클라우드-네이티브 서비스 디스커버리
애플리케이션에서 서비스 디스커버리를 위해 쿠버네티스 API를 사용할 수 있는 경우,
서비스 내 파드 세트가 변경될 때마다 업데이트되는 엔드포인트를 {{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}}에
질의할 수 있다.
애플리케이션에서 서비스 디스커버리를 위해 쿠버네티스 API를 사용할 수 있는 경우,
매치되는 엔드포인트슬라이스를
{{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}}에 질의할 수 있다.
쿠버네티스는 서비스의 파드가 변경될 때마다 서비스의 엔드포인트슬라이스를 업데이트한다.
네이티브 애플리케이션이 아닌 (non-native applications) 경우, 쿠버네티스는 애플리케이션과 백엔드 파드 사이에 네트워크 포트 또는 로드
밸런서를 배치할 수 있는 방법을 제공한다.
@ -149,8 +152,9 @@ spec:
예를 들어, 클라이언트를 망가뜨리지 않고,
백엔드 소프트웨어의 다음 버전에서 파드가 노출시키는 포트 번호를 변경할 수 있다.
서비스의 기본 프로토콜은 TCP이다. 다른
[지원되는 프로토콜](#protocol-support)을 사용할 수도 있다.
서비스의 기본 프로토콜은
[TCP](/ko/docs/reference/networking/service-protocols/#protocol-tcp)이다.
다른 [지원되는 프로토콜](#protocol-support)을 사용할 수도 있다.
많은 서비스가 하나 이상의 포트를 노출해야 하기 때문에, 쿠버네티스는 서비스 오브젝트에서 다중
포트 정의를 지원한다.
@ -159,8 +163,12 @@ spec:
### 셀렉터가 없는 서비스
서비스는 일반적으로 셀렉터를 이용하여 쿠버네티스 파드에 대한 접근을 추상화하지만,
셀렉터 대신 매칭되는(corresponding) 엔드포인트와 함께 사용되면 다른 종류의 백엔드도 추상화할 수 있으며,
여기에는 클러스터 외부에서 실행되는 것도 포함된다. 예시는 다음과 같다.
셀렉터 대신 매칭되는(corresponding)
{{<glossary_tooltip term_id="endpoint-slice" text="엔드포인트슬라이스">}}
오브젝트와 함께 사용되면 다른 종류의 백엔드도 추상화할 수 있으며,
여기에는 클러스터 외부에서 실행되는 것도 포함된다.
예시는 다음과 같다.
* 프로덕션 환경에서는 외부 데이터베이스 클러스터를 사용하려고 하지만,
테스트 환경에서는 자체 데이터베이스를 사용한다.
@ -169,7 +177,7 @@ spec:
* 워크로드를 쿠버네티스로 마이그레이션하고 있다. 해당 방식을 평가하는 동안,
쿠버네티스에서는 백엔드의 일부만 실행한다.
이러한 시나리오 중에서 파드 셀렉터 _없이_ 서비스를 정의 할 수 있다.
이러한 시나리오에서는 파드 셀렉터 _없이_ 서비스를 정의 할 수 있다.
예를 들면
```yaml
@ -184,29 +192,41 @@ spec:
targetPort: 9376
```
이 서비스에는 셀렉터가 없으므로, 해당 엔드포인트 오브젝트가 자동으로
생성되지 않는다. 엔드포인트 오브젝트를 수동으로 추가하여, 서비스를 실행 중인 네트워크 주소 및 포트에
서비스를 수동으로 매핑할 수 있다.
이 서비스에는 셀렉터가 없으므로, 매칭되는 엔드포인트슬라이스
(및 레거시 엔드포인트) 오브젝트가 자동으로 생성되지 않는다.
엔드포인트슬라이스 오브젝트를 수동으로 추가하여,
서비스를 실행 중인 네트워크 주소 및 포트에 서비스를 수동으로 매핑할 수 있다. 예시는 다음과 같다.
```yaml
apiVersion: v1
kind: Endpoints
apiVersion: discovery.k8s.io/v1
kind: EndpointSlice
metadata:
# 여기서의 이름은 서비스의 이름과 일치해야 한다.
name: my-service
subsets:
name: my-service-1 # 관행적으로, 서비스의 이름을
# 엔드포인트슬라이스 이름의 접두어로 사용한다.
labels:
# "kubernetes.io/service-name" 레이블을 설정해야 한다.
# 이 레이블의 값은 서비스의 이름과 일치하도록 지정한다.
kubernetes.io/service-name: my-service
addressType: IPv4
ports:
- name: '' # 9376 포트는 (IANA에 의해) 잘 알려진 포트로 할당되어 있지 않으므로
# 이 칸은 비워 둔다.
appProtocol: http
protocol: TCP
port: 9376
endpoints:
- addresses:
- ip: 192.0.2.42
ports:
- port: 9376
- "10.4.5.6" # 이 목록에 IP 주소를 기재할 때 순서는 상관하지 않는다.
- "10.1.2.3"
```
엔드포인트 오브젝트의 이름은 유효한
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
#### 커스텀 엔드포인트슬라이스
서비스를 위한 객체인 [엔드포인트](/docs/reference/kubernetes-api/service-resources/endpoints-v1/)를 만들 때,
새로운 객체의 이름을
그것의 서비스 이름과 같게 설정해야 한다.
서비스를 위한 [엔드포인트슬라이스](#엔드포인트슬라이스) 오브젝트를 생성할 때,
엔드포인트슬라이스 이름으로는 원하는 어떤 이름도 사용할 수 있다.
네임스페이스 내의 각 엔드포인트슬라이스 이름은 고유해야 한다.
해당 엔드포인트슬라이스에 `kubernetes.io/service-name` {{< glossary_tooltip text="레이블" term_id="label" >}}을 설정하여
엔드포인트슬라이스를 서비스와 연결할 수 있다.
{{< note >}}
엔드포인트 IP는 루프백(loopback) (IPv4의 경우 127.0.0.0/8, IPv6의 경우 ::1/128), 또는
@ -217,204 +237,94 @@ subsets:
목적지(destination)로 지원하지 않기 때문이다.
{{< /note >}}
셀렉터가 없는 서비스에 접근하면 셀렉터가 있는 것처럼 동일하게 작동한다.
위의 예에서, 트래픽은 YAML에 정의된 단일 엔드 포인트로
라우팅된다. `192.0.2.42:9376` (TCP)
직접 생성했거나 직접 작성한 코드에 의해 생성된 엔드포인트슬라이스를 위해,
[`endpointslice.kubernetes.io/managed-by`](/ko/docs/reference/labels-annotations-taints/#endpointslicekubernetesiomanaged-by)
레이블에 사용할 값을 골라야 한다.
엔드포인트슬라이스를 관리하는 컨트롤러 코드를 직접 작성하는 경우,
`"my-domain.example/name-of-controller"`와 같은 값을 사용할 수 있다.
써드파티 도구를 사용하는 경우, 도구의 이름에서 대문자는 모두 소문자로 바꾸고
공백 및 다른 문장 부호는 하이픈(`-`)으로 대체한 문자열을 사용한다.
`kubectl`과 같은 도구를 사용하여 직접 엔드포인트슬라이스를 관리하는 경우,
`"staff"` 또는 `"cluster-admins"`와 같이 이러한 수동 관리를 명시하는 이름을 사용한다.
쿠버네티스 자체 컨트롤 플레인이 관리하는 엔드포인트슬라이스를 가리키는
`"controller"`라는 예약된 값은 사용하지 말아야 한다.
{{< note >}}
쿠버네티스 API 서버는 파드에 매핑되지 않은 엔드포인트를 프록시하는 것을 허용하지 않는다.
셀렉터가 없는 서비스에 대해서 `kubectl proxy <service-name>`과 같은 행위는
이런 제약으로 인해 실패할 것이다. 이는 사용자가 쿠버네티스 API 서버를
프록시로 사용하여 허가받지 않은 엔드포인트에 접근하는 것을 막아준다.
{{< /note >}}
#### 셀렉터가 없는 서비스에 접근하기 {#service-no-selector-access}
ExternalName 서비스는 셀렉터가 없고
DNS명을 대신 사용하는 특수한 상황의 서비스이다. 자세한 내용은
이 문서 뒷부분의 [ExternalName](#externalname) 섹션을 참조한다.
셀렉터가 없는 서비스에 접근하는 것은 셀렉터가 있는 서비스에 접근하는 것과 동일하게 동작한다.
셀렉터가 없는 서비스 [예시](#services-without-selectors)에서, 트래픽은
엔드포인트슬라이스 매니페스트에 정의된 두 엔드포인트 중 하나로 라우트된다(10.1.2.3:9376 또는 10.4.5.6:9376으로의 TCP 연결).
### 초과 용량 엔드포인트
엔드포인트 리소스에 1,000개가 넘는 엔드포인트가 있는 경우 쿠버네티스 v1.22(또는 그 이상)
클러스터는 해당 엔드포인트에 `endpoints.kubernetes.io/over-capacity: truncated` 어노테이션을 추가한다.
이 어노테이션은 영향을 받는 엔드포인트 오브젝트가 용량을 초과했으며
엔드포인트 컨트롤러가 엔드포인트의 수를 1000으로 줄였음을 나타낸다.
ExternalName 서비스는 셀렉터가 없고
대신 DNS 이름을 사용하는 특이 케이스 서비스이다.
자세한 내용은 이 문서 뒷부분의 [ExternalName](#externalname) 섹션을 참조한다.
### 엔드포인트슬라이스
{{< feature-state for_k8s_version="v1.21" state="stable" >}}
엔드포인트슬라이스는 엔드포인트에 보다 확장 가능한 대안을 제공할 수 있는
API 리소스이다. 개념적으로 엔드포인트와 매우 유사하지만, 엔드포인트슬라이스를
사용하면 여러 리소스에 네트워크 엔드포인트를 분산시킬 수 있다. 기본적으로,
엔드포인트슬라이스는 100개의 엔드포인트에 도달하면 "가득찬 것"로 간주되며,
추가 엔드포인트를 저장하기 위해서는 추가 엔드포인트슬라이스가
생성된다.
[엔드포인트슬라이스](/ko/docs/concepts/services-networking/endpoint-slices/)는
특정 서비스의 하위(backing) 네트워크 엔드포인트 부분집합(_슬라이스_)을 나타내는 오브젝트이다.
엔드포인트슬라이스는 [엔드포인트슬라이스](/ko/docs/concepts/services-networking/endpoint-slices/)에서
자세하게 설명된 추가적인 속성 및 기능을 제공한다.
쿠버네티스 클러스터는 각 엔드포인트슬라이스가 얼마나 많은 엔드포인트를 나타내는지를 추적한다.
한 서비스의 엔드포인트가 너무 많아 역치에 도달하면,
쿠버네티스는 빈 엔드포인트슬라이스를 생성하고 여기에 새로운 엔드포인트 정보를 저장한다.
기본적으로, 쿠버네티스는 기존의 모든 엔드포인트슬라이스가
엔드포인트를 최소 100개 이상 갖게 되면 새 엔드포인트슬라이스를 생성한다.
쿠버네티스는 새 엔드포인트가 추가되어야 하는 상황이 아니라면
새 엔드포인트슬라이스를 생성하지 않는다.
이 API에 대한 더 많은 정보는
[엔드포인트슬라이스](/ko/docs/concepts/services-networking/endpoint-slices/)를 참고한다.
### 엔드포인트
쿠버네티스 API에서,
[엔드포인트(Endpoints)](/docs/reference/kubernetes-api/service-resources/endpoints-v1/)(리소스 명칭이 복수형임)는
네트워크 엔드포인트의 목록을 정의하며,
일반적으로 트래픽이 어떤 파드에 보내질 수 있는지를 정의하기 위해 서비스가 참조한다.
엔드포인트 대신 엔드포인트슬라이스 API를 사용하는 것을 권장한다.
#### 용량 한계를 넘어선 엔드포인트
쿠버네티스는 단일 엔드포인트(Endpoints) 오브젝트에 포함될 수 있는 엔드포인트(endpoints)의 수를 제한한다.
단일 서비스에 1000개 이상의 하위(backing) 엔드포인트가 있으면,
쿠버네티스는 엔드포인트 오브젝트의 데이터를 덜어낸다(truncate).
서비스는 하나 이상의 엔드포인트슬라이스와 연결될 수 있기 때문에,
하위 엔드포인트 1000개 제한은 기존(legacy) 엔드포인트 API에만 적용된다.
이러한 경우, 쿠버네티스는 엔드포인트(Endpoints) 오브젝트에 저장될 수 있는
백엔드 엔드포인트(endpoints)를 최대 1000개 선정하고,
엔드포인트 오브젝트에 [`endpoints.kubernetes.io/over-capacity: truncated`](/docs/reference/labels-annotations-taints/#endpoints-kubernetes-io-over-capacity)
{{< glossary_tooltip text="어노테이션" term_id="annotation" >}}을 설정한다.
컨트롤 플레인은 또한 백엔드 파드 수가 1000 미만으로 내려가면
해당 어노테이션을 제거한다.
트래픽은 여전히 백엔드로 전송되지만, 기존(legacy) 엔드포인트 API에 의존하는 모든 로드 밸런싱 메커니즘은
사용 가능한 하위(backing) 엔드포인트 중에서 최대 1000개까지에만 트래픽을 전송한다.
동일한 API 상한은 곧 하나의 엔드포인트(Endpoints) 객체가 1000개 이상의 엔드포인트(endpoints)를 갖도록 수동으로 업데이트할 수는 없음을 의미한다.
### 애플리케이션 프로토콜
{{< feature-state for_k8s_version="v1.20" state="stable" >}}
`appProtocol` 필드는 각 서비스 포트에 대한 애플리케이션 프로토콜을 지정하는 방법을 제공한다.
이 필드의 값은 해당 엔드포인트와 엔드포인트슬라이스
이 필드의 값은 상응하는 엔드포인트와 엔드포인트슬라이스
오브젝트에 의해 미러링된다.
이 필드는 표준 쿠버네티스 레이블 구문을 따른다. 값은
[IANA 표준 서비스 이름](https://www.iana.org/assignments/service-names) 또는
`mycompany.com/my-custom-protocol`과 같은 도메인 접두사 이름 중 하나여야 한다.
## 가상 IP와 서비스 프록시
쿠버네티스 클러스터의 모든 노드는 `kube-proxy`를 실행한다. `kube-proxy`는
[`ExternalName`](#externalname) 이외의 유형의 `서비스`에 대한
가상 IP 형식을 구현한다.
### 라운드-로빈 DNS를 사용하지 않는 이유
항상 발생하는 질문은 왜 쿠버네티스가 인바운드 트래픽을 백엔드로 전달하기 위해 프록시에
의존하는가 하는 점이다. 다른 접근법이
있는가? 예를 들어, 여러 A 값 (또는 IPv6의 경우 AAAA)을 가진
DNS 레코드를 구성하고, 라운드-로빈 이름 확인 방식을
취할 수 있는가?
서비스에 프록시를 사용하는 데는 몇 가지 이유가 있다.
* 레코드 TTL을 고려하지 않고, 만료된 이름 검색 결과를
캐싱하는 DNS 구현에 대한 오래된 역사가 있다.
* 일부 앱은 DNS 검색을 한 번만 수행하고 결과를 무기한으로 캐시한다.
* 앱과 라이브러리가 적절히 재-확인을 했다고 하더라도, DNS 레코드의 TTL이
낮거나 0이면 DNS에 부하가 높아 관리하기가
어려워 질 수 있다.
본 페이지의 뒷 부분에서 다양한 kube-proxy 구현이 동작하는 방식에 대해 읽을 수 있다.
우선 알아두어야 할 것은, `kube-proxy`를 구동할 때, 커널 수준의 규칙이
수정(예를 들어, iptables 규칙이 생성될 수 있음)될 수 있고,
이는 때로는 리부트 전까지 정리되지 않을 수도 있다.
그래서, kube-proxy는 컴퓨터에서 저수준의, 특권을 가진(privileged) 네트워킹
프록시 서비스가 구동됨으로써 발생하는 결과를 이해하고 있는 관리자에 의해서만 구동되어야 한다.
비록 `kube-proxy` 실행 파일이 `cleanup` 기능을 지원하기는 하지만, 이 기능은 공식적인 기능이
아니기 때문에 구현된 그대로만 사용할 수 있다.
### 구성
kube-proxy는 구성에 따라 결정되는 여러 모드에서 기동될 수 있다.
- kube-proxy의 구성은 컨피그맵(ConfigMap)을 통해 이루어진다. 그리고 해당 kube-proxy를 위한
컨피그맵은 실효성있게 거의 대부분의 kube-proxy의 플래그의 행위를 더 이상 사용하지 않도록 한다.
- kube-proxy를 위한 해당 컨피그맵은 기동 중 구성의 재적용(live reloading)은 지원하지 않는다.
- kube-proxy를 위한 컨피그맵 파라미터는 기동 시에 검증이나 확인을 하지 않는다.
예를 들어, 운영 체계가 iptables 명령을 허용하지 않을 경우,
표준 커널 kube-proxy 구현체는 작동하지 않을 것이다.
마찬가지로, `netsh`을 지원하지 않는 운영 체계에서는,
윈도우 유저스페이스 모드로는 기동하지 않을 것이다.
### 유저 스페이스(User space) 프록시 모드 {#proxy-mode-userspace}
이 모드에서는, kube-proxy는 쿠버네티스 컨트롤 플레인의 서비스 및 엔드포인트 오브젝트의
추가와 제거를 감시한다. 각 서비스는 로컬 노드에서
포트(임의로 선택됨)를 연다. 이 "프록시 포트"에 대한 모든
연결은 (엔드포인트를 통해 보고된 대로) 서비스의 백엔드 파드 중 하나로 프록시된다.
kube-proxy는 사용할 백엔드 파드를 결정할 때 서비스의
`SessionAffinity` 설정을 고려한다.
마지막으로, 유저-스페이스 프록시는 서비스의
`clusterIP` (가상)와 `port` 에 대한 트래픽을 캡처하는 iptables 규칙을 설치한다. 이 규칙은
트래픽을 백엔드 파드를 프록시하는 프록시 포트로 리다이렉션한다.
기본적으로, 유저스페이스 모드의 kube-proxy는 라운드-로빈 알고리즘으로 백엔드를 선택한다.
![유저스페이스 프록시에 대한 서비스 개요 다이어그램](/images/docs/services-userspace-overview.svg)
### `iptables` 프록시 모드 {#proxy-mode-iptables}
이 모드에서는, kube-proxy는 쿠버네티스 컨트롤 플레인의 서비스, 엔드포인트 오브젝트의
추가와 제거를 감시한다. 각 서비스에 대해, 서비스의
`clusterIP` 및 `port`에 대한 트래픽을 캡처하고 해당 트래픽을 서비스의
백엔드 세트 중 하나로 리다이렉트(redirect)하는
iptables 규칙을 설치한다. 각 엔드포인트 오브젝트에 대해,
백엔드 파드를 선택하는 iptables 규칙을 설치한다.
기본적으로, iptables 모드의 kube-proxy는 임의의 백엔드를 선택한다.
트래픽을 처리하기 위해 iptables를 사용하면 시스템 오버헤드가 줄어드는데, 유저스페이스와
커널 스페이스 사이를 전환할 필요없이 리눅스 넷필터(netfilter)가 트래픽을 처리하기
때문이다. 이 접근 방식은 더 신뢰할 수 있기도 하다.
kube-proxy가 iptables 모드에서 실행 중이고 선택된 첫 번째 파드가
응답하지 않으면, 연결이 실패한다. 이는 userspace 모드와
다르다. 해당 시나리오에서는, kube-proxy는 첫 번째
파드에 대한 연결이 실패했음을 감지하고 다른 백엔드 파드로 자동으로 재시도한다.
파드 [준비성 프로브(readiness probe)](/ko/docs/concepts/workloads/pods/pod-lifecycle/#컨테이너-프로브-probe)를 사용하여
백엔드 파드가 제대로 작동하는지 확인할 수 있으므로, iptables 모드의 kube-proxy는
정상으로 테스트된 백엔드만 볼 수 있다. 이렇게 하면 트래픽이 kube-proxy를 통해
실패한 것으로 알려진 파드로 전송되는 것을 막을 수 있다.
![iptables 프록시에 대한 서비스 개요 다이어그램](/images/docs/services-iptables-overview.svg)
### IPVS 프록시 모드 {#proxy-mode-ipvs}
{{< feature-state for_k8s_version="v1.11" state="stable" >}}
`ipvs` 모드에서는, kube-proxy는 쿠버네티스 서비스와 엔드포인트를 감시하고,
`netlink` 인터페이스를 호출하여 그에 따라 IPVS 규칙을 생성하고
IPVS 규칙을 쿠버네티스 서비스와 엔드포인트와 주기적으로 동기화한다.
이 제어 루프는 IPVS 상태가 원하는 상태와 일치하도록
보장한다.
서비스에 접근하면, IPVS는 트래픽을 백엔드 파드 중 하나로 보낸다.
IPVS 프록시 모드는 iptables 모드와 유사한 넷필터 후크 기능을
기반으로 하지만, 해시 테이블을 기본 데이터 구조로 사용하고
커널 스페이스에서 동작한다.
이는 IPVS 모드의 kube-proxy는 iptables 모드의 kube-proxy보다
지연 시간이 짧은 트래픽을 리다이렉션하고, 프록시 규칙을 동기화할 때 성능이
훨씬 향상됨을 의미한다. 다른 프록시 모드와 비교했을 때, IPVS 모드는
높은 네트워크 트래픽 처리량도 지원한다.
IPVS는 트래픽을 백엔드 파드로 밸런싱하기 위한 추가 옵션을 제공한다.
다음과 같다.
* `rr`: 라운드-로빈
* `lc`: 최소 연결 (가장 적은 수의 열려있는 연결)
* `dh`: 목적지 해싱
* `sh`: 소스 해싱
* `sed`: 최단 예상 지연 (shortest expected delay)
* `nq`: 큐 미사용 (never queue)
{{< note >}}
IPVS 모드에서 kube-proxy를 실행하려면, kube-proxy를 시작하기 전에 노드에서 IPVS를
사용 가능하도록 해야 한다.
kube-proxy가 IPVS 프록시 모드에서 시작될 때, IPVS 커널 모듈을
사용할 수 있는지 확인한다. IPVS 커널 모듈이 감지되지 않으면, kube-proxy는
iptables 프록시 모드에서 다시 실행된다.
{{< /note >}}
![IPVS 프록시에 대한 서비스 개요 다이어그램](/images/docs/services-ipvs-overview.svg)
이 프록시 모델에서 클라이언트가 쿠버네티스 또는 서비스 또는 파드에
대해 알지 못하는 경우 서비스의 IP:포트로 향하는 트래픽은
적절한 백엔드로 프록시된다.
특정 클라이언트의 연결이 매번 동일한 파드로
전달되도록 하려면, `service.spec.sessionAffinity`를 "ClientIP"로 설정하여
클라이언트의 IP 주소를 기반으로 세션 어피니티(Affinity)를 선택할 수 있다.
(기본값은 "None")
`service.spec.sessionAffinityConfig.clientIP.timeoutSeconds`를 적절히 설정하여
최대 세션 고정 시간을 설정할 수도 있다.
(기본값은 10800으로, 3시간)
{{< note >}}
윈도우에서, 서비스들의 최대 세션 고정 시간(maximum session sticky time)을 설정하는 것은 지원되지 않는다.
{{< /note >}}
## 멀티-포트 서비스
일부 서비스의 경우, 둘 이상의 포트를 노출해야 한다.
쿠버네티스는 서비스 오브젝트에서 멀티 포트 정의를 구성할 수 있도록 지원한다.
서비스에 멀티 포트를 사용하는 경우, 모든 포트 이름을
명확하게 지정해야 한다.
예를 들면
예를 들면 다음과 같다.
```yaml
apiVersion: v1
@ -455,40 +365,6 @@ CIDR 범위 내의 유효한 IPv4 또는 IPv6 주소여야 한다.
유효하지 않은 clusterIP 주소 값으로 서비스를 생성하려고 하면, API 서버는
422 HTTP 상태 코드를 리턴하여 문제점이 있음을 알린다.
## 트래픽 정책
### 외부 트래픽 정책
`spec.externalTrafficPolicy` 필드를 설정하여 외부 소스에서 오는 트래픽이 어떻게 라우트될지를 제어할 수 있다.
이 필드는 `Cluster` 또는 `Local`로 설정할 수 있다. 필드를 `Cluster`로 설정하면 외부 트래픽을 준비 상태의 모든 엔드포인트로 라우트하며,
`Local`로 설정하면 준비 상태의 노드-로컬 엔드포인트로만 라우트한다. 만약 트래픽 정책이 `Local`로 설정되어 있는데 노드-로컬
엔드포인트가 하나도 없는 경우, kube-proxy는 연관된 서비스로의 트래픽을 포워드하지 않는다.
{{< note >}}
{{< feature-state for_k8s_version="v1.22" state="alpha" >}}
kube-proxy에 대해 `ProxyTerminatingEndpoints`
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를
활성화하면, kube-proxy는 노드에 로컬 엔드포인트가 있는지,
그리고 모든 로컬 엔드포인트가 "종료 중(terminating)"으로 표시되어 있는지 여부를 확인한다.
만약 로컬 엔드포인트가 존재하는데 **모두**가 종료 중이면, kube-proxy는 `Local`로 설정된 모든 외부 트래픽 정책을 무시한다.
대신, 모든 노드-로컬 엔드포인트가 "종료 중" 상태를 유지하는 동안,
kube-proxy는 마치 외부 트래픽 정책이 `Cluster`로 설정되어 있는 것처럼
그 서비스에 대한 트래픽을 정상 상태의 다른 엔드포인트로 포워드한다.
이러한 종료 중인 엔드포인트에 대한 포워딩 정책은 `NodePort` 서비스로 트래픽을 로드밸런싱하던 외부 로드밸런서가
헬스 체크 노드 포트가 작동하지 않을 때에도 연결들을 비돌발적으로(gracefully) 종료시킬 수 있도록 하기 위해 존재한다.
이러한 정책이 없다면, 노드가 여전히 로드밸런서 노드 풀에 있지만
파드 종료 과정에서 트래픽이 제거(drop)되는 상황에서 트래픽이 유실될 수 있다.
{{< /note >}}
### 내부 트래픽 정책
{{< feature-state for_k8s_version="v1.22" state="beta" >}}
`spec.internalTrafficPolicy` 필드를 설정하여 내부 소스에서 오는 트래픽이 어떻게 라우트될지를 제어할 수 있다.
이 필드는 `Cluster` 또는 `Local`로 설정할 수 있다. 필드를 `Cluster`로 설정하면 내부 트래픽을 준비 상태의 모든 엔드포인트로 라우트하며,
`Local`로 설정하면 준비 상태의 노드-로컬 엔드포인트로만 라우트한다. 만약 트래픽 정책이 `Local`로 설정되어 있는데 노드-로컬
엔드포인트가 하나도 없는 경우, kube-proxy는 트래픽을 포워드하지 않는다.
## 서비스 디스커버리하기
쿠버네티스는 서비스를 찾는 두 가지 기본 모드를 지원한다. - 환경
@ -571,50 +447,57 @@ DNS SRV 쿼리를 수행할 수 있다.
### 셀렉터가 있는 경우
셀렉터를 정의하는 헤드리스 서비스의 경우, 엔드포인트 컨트롤러는
API에서 `엔드포인트` 레코드를 생성하고, DNS 구성을 수정하여
`서비스` 를 지원하는 `파드` 를 직접 가리키는 A 레코드(IP 주소)를 반환한다.
셀렉터를 정의하는 헤드리스 서비스의 경우, 쿠버네티스 컨트롤 플레인은
쿠버네티스 API 내에서 엔드포인트슬라이스 오브젝트를 생성하고,
서비스 하위(backing) 파드들을 직접 가리키는
A 또는 AAAA 레코드(IPv4 또는 IPv6 주소)를 반환하도록 DNS 구성을 변경한다.
### 셀렉터가 없는 경우
셀렉터를 정의하지 않는 헤드리스 서비스의 경우, 엔드포인트 컨트롤러는
`엔드포인트` 레코드를 생성하지 않는다. 그러나 DNS 시스템은 다음 중 하나를 찾고
구성한다.
셀렉터를 정의하지 않는 헤드리스 서비스의 경우,
쿠버네티스 컨트롤 플레인은 엔드포인트슬라이스 오브젝트를 생성하지 않는다.
하지만, DNS 시스템은 다음 중 하나를 탐색한 뒤 구성한다.
* [`ExternalName`](#externalname)-유형 서비스에 대한 CNAME 레코드
* 다른 모든 유형에 대해, 서비스의 이름을 공유하는 모든 `엔드포인트`에
대한 레코드
* [`type: ExternalName`](#externalname) 서비스에 대한 DNS CNAME 레코드
* `ExternalName` 이외의 모든 서비스 타입에 대해,
서비스의 활성(ready) 엔드포인트의 모든 IP 주소에 대한 DNS A / AAAA 레코드
* IPv4 엔드포인트에 대해, DNS 시스템은 A 레코드를 생성한다.
* IPv6 엔드포인트에 대해, DNS 시스템은 AAAA 레코드를 생성한다.
## 서비스 퍼블리싱 (ServiceTypes) {#publishing-services-service-types}
애플리케이션 중 일부(예: 프론트엔드)는 서비스를 클러스터 밖에
위치한 외부 IP 주소에 노출하고 싶은 경우가 있을 것이다.
쿠버네티스 `ServiceTypes`는 원하는 서비스 종류를 지정할 수 있도록 해준다.
기본 값은 `ClusterIP`이다.
쿠버네티스 `ServiceTypes`는 원하는 서비스 종류를 지정할 수 있도록 해 준다.
`Type` 값과 그 동작은 다음과 같다.
* `ClusterIP`: 서비스를 클러스터-내부 IP에 노출시킨다. 이 값을 선택하면
클러스터 내에서만 서비스에 도달할 수 있다. 이것은
`ServiceTypes`의 기본 값이다.
* [`NodePort`](#type-nodeport): 고정 포트 (`NodePort`)로 각 노드의 IP에 서비스를
노출시킨다. `NodePort` 서비스가 라우팅되는 `ClusterIP` 서비스가
자동으로 생성된다. `<NodeIP>:<NodePort>`를 요청하여,
클러스터 외부에서
`NodePort` 서비스에 접속할 수 있다.
* `ClusterIP`: 서비스를 클러스터-내부 IP에 노출시킨다.
이 값을 선택하면 클러스터 내에서만 서비스에 도달할 수 있다.
이것은 서비스의 `type`을 명시적으로 지정하지 않았을 때의 기본값이다.
* [`NodePort`](#type-nodeport): 고정 포트 (`NodePort`)로 각 노드의 IP에
서비스를 노출시킨다. 노드 포트를 사용할 수 있도록 하기 위해,
쿠버네티스는 `type: ClusterIP`인 서비스를 요청했을 때와 마찬가지로
클러스터 IP 주소를 구성한다.
* [`LoadBalancer`](#loadbalancer): 클라우드 공급자의 로드 밸런서를 사용하여
서비스를 외부에 노출시킨다. 외부 로드 밸런서가 라우팅되는
`NodePort`와 `ClusterIP` 서비스가 자동으로 생성된다.
* [`ExternalName`](#externalname): 값과 함께 CNAME 레코드를 리턴하여, 서비스를
`externalName` 필드의 콘텐츠 (예:`foo.bar.example.com`)에
매핑한다. 어떤 종류의 프록시도 설정되어 있지 않다.
{{< note >}}`ExternalName` 유형을 사용하려면 kube-dns 버전 1.7 또는
CoreDNS 버전 1.7 이상이 필요하다.
서비스를 외부에 노출시킨다.
* [`ExternalName`](#externalname): 값과 함께 CNAME 레코드를 리턴하여,
서비스를 `externalName` 필드의 내용(예:`foo.bar.example.com`)에 매핑한다.
어떠한 종류의 프록시도 설정되지 않는다.
{{< note >}}
`ExternalName` 유형을 사용하려면 `kube-dns` 버전 1.7 또는
CoreDNS 버전 0.0.8 이상이 필요하다.
{{< /note >}}
`type` 필드는 중첩(nested) 기능으로 설계되어, 각 단계는 이전 단계에 더해지는 형태이다.
이는 모든 클라우드 공급자에 대해 엄격히 요구되는 사항은 아니다(예:
Google Compute Engine에서는 `type: LoadBalancer`가 동작하기 위해 노드 포트를 할당할 필요가 없지만,
다른 클라우드 공급자 통합 시에는 필요할 수 있음).
엄격한 중첩이 필수 사항은 아니지만, 서비스에 대한 쿠버네티스 API 디자인은 이와 상관없이 엄격한 중첩 구조를 가정한다.
[인그레스](/ko/docs/concepts/services-networking/ingress/)를 사용하여 서비스를 노출시킬 수도 있다.
인그레스는 서비스 유형이 아니지만, 클러스터의 진입점 역할을 한다.
인그레스는 서비스 유형은 아니지만, 클러스터의 진입점 역할을 한다.
동일한 IP 주소로 여러 서비스를 노출시킬 수 있기 때문에
라우팅 규칙을 단일 리소스로 통합할 수 있다.
@ -625,38 +508,28 @@ API에서 `엔드포인트` 레코드를 생성하고, DNS 구성을 수정하
각 노드는 해당 포트 (모든 노드에서 동일한 포트 번호)를 서비스로 프록시한다.
서비스는 할당된 포트를 `.spec.ports[*].nodePort` 필드에 나타낸다.
포트를 프록시하기 위해 특정 IP를 지정하려면, kube-proxy에 대한
`--nodeport-addresses` 플래그 또는
[kube-proxy 구성 파일](/docs/reference/config-api/kube-proxy-config.v1alpha1/)의
동등한 `nodePortAddresses` 필드를
특정 IP 블록으로 설정할 수 있다.
이 플래그는 쉼표로 구분된 IP 블록 목록(예: `10.0.0.0/8`, `192.0.2.0/25`)을 사용하여
kube-proxy가 로컬 노드로 고려해야 하는 IP 주소 범위를 지정한다.
예를 들어, `--nodeport-addresses=127.0.0.0/8` 플래그로 kube-proxy를 시작하면,
kube-proxy는 NodePort 서비스에 대하여 루프백(loopback) 인터페이스만 선택한다.
`--nodeport-addresses`의 기본 값은 비어있는 목록이다.
이것은 kube-proxy가 NodePort에 대해 사용 가능한 모든 네트워크 인터페이스를 고려해야 한다는 것을 의미한다.
(이는 이전 쿠버네티스 릴리스와도 호환된다).
특정 포트 번호를 원한다면, `nodePort` 필드에 값을 지정할 수
있다. 컨트롤 플레인은 해당 포트를 할당하거나 API 트랜잭션이
실패했다고 보고한다.
이는 사용자 스스로 포트 충돌의 가능성을 고려해야 한다는 의미이다.
또한 NodePort 사용을 위해 구성된 범위 내에 있는, 유효한 포트 번호를
사용해야 한다.
NodePort를 사용하면 자유롭게 자체 로드 밸런싱 솔루션을 설정하거나,
쿠버네티스가 완벽하게 지원하지 않는 환경을 구성하거나,
하나 이상의 노드 IP를 직접 노출시킬 수 있다.
이 서비스는 `<NodeIP>:spec.ports[*].nodePort`와
`.spec.clusterIP:spec.ports[*].port`로 표기된다.
kube-proxy에 대한 `--nodeport-addresses` 플래그 또는 kube-proxy 구성 파일의
동등한 필드가 설정된 경우, `<NodeIP>` 는 노드 IP를 필터링한다.
NodePort 서비스에 대해, 쿠버네티스는 포트를 추가로
할당한다(서비스의 프로토콜에 매치되도록 TCP, UDP, SCTP 중 하나).
클러스터의 모든 노드는 할당된 해당 포트를 리슨하고
해당 서비스에 연결된 활성(ready) 엔드포인트 중 하나로 트래픽을 전달하도록 자기 자신을 구성한다.
적절한 프로토콜(예: TCP) 및 적절한 포트(해당 서비스에 할당된 대로)로
클러스터 외부에서 클러스터의 아무 노드에 연결하여 `type: NodePort` 서비스로 접근할 수 있다.
예를 들면
#### 포트 직접 선택하기 {#nodeport-custom-port}
특정 포트 번호를 원한다면, `nodePort` 필드에 값을 명시할 수 있다.
컨트롤 플레인은 해당 포트를 할당해 주거나 또는
해당 API 트랜젝션이 실패했다고 알려줄 것이다.
이는 사용자 스스로 포트 충돌의 가능성을 고려해야 한다는 의미이다.
또한 유효한(NodePort용으로 사용할 수 있도록 구성된 범위 내의)
포트 번호를 사용해야 한다.
다음은 NodePort 값을 명시하는(이 예시에서는 30007)
`type: NodePort` 서비스에 대한 예시 매니페스트이다.
```yaml
apiVersion: v1
@ -676,6 +549,33 @@ spec:
nodePort: 30007
```
#### `type: NodePort` 서비스를 위한 커스텀 IP 주소 구성 {#service-nodeport-custom-listen-address}
NodePort 서비스 노출에 특정 IP 주소를 사용하도록
클러스터의 노드를 설정할 수 있다.
각 노드가 여러 네트워크(예: 애플리케이션 트래픽용 네트워크 및
노드/컨트롤 플레인 간 트래픽용 네트워크)에 연결되어 있는 경우에 이러한 구성을 고려할 수 있다.
포트를 프록시하기 위해 특정 IP를 지정하려면, kube-proxy에 대한
`--nodeport-addresses` 플래그 또는
[kube-proxy 구성 파일](/docs/reference/config-api/kube-proxy-config.v1alpha1/)의
동등한 `nodePortAddresses` 필드를
특정 IP 블록으로 설정할 수 있다.
이 플래그는 쉼표로 구분된 IP 블록 목록(예: `10.0.0.0/8`, `192.0.2.0/25`)을 사용하여
kube-proxy가 로컬 노드로 고려해야 하는 IP 주소 범위를 지정한다.
예를 들어, `--nodeport-addresses=127.0.0.0/8` 플래그로 kube-proxy를 시작하면,
kube-proxy는 NodePort 서비스에 대하여 루프백(loopback) 인터페이스만 선택한다.
`--nodeport-addresses`의 기본 값은 비어있는 목록이다.
이것은 kube-proxy가 NodePort에 대해 사용 가능한 모든 네트워크 인터페이스를 고려해야 한다는 것을 의미한다.
(이는 이전 쿠버네티스 릴리스와도 호환된다).
{{< note >}}
이 서비스는 `<NodeIP>:spec.ports[*].nodePort`와 `.spec.clusterIP:spec.ports[*].port`로 표기된다.
kube-proxy에 대한 `--nodeport-addresses` 플래그 또는 kube-proxy 구성 파일의 동등한 필드가 설정된 경우,
`<NodeIP>` 는 노드 IP를 필터링한다.
{{< /note >}}
### 로드밸런서 유형 {#loadbalancer}
외부 로드 밸런서를 지원하는 클라우드 공급자 상에서, `type`
@ -683,7 +583,7 @@ spec:
로드 밸런서의 실제 생성은 비동기적으로 수행되고,
프로비저닝된 밸런서에 대한 정보는 서비스의
`.status.loadBalancer` 필드에 발행된다.
예를 들면
예를 들면 다음과 같다.
```yaml
apiVersion: v1
@ -714,6 +614,16 @@ status:
클라우드 공급자가 이 기능을 지원하지 않는 경우, 설정한 `loadbalancerIP` 필드는
무시된다.
`type: LoadBalancer`인 서비스를 구현하기 위해,
쿠버네티스는 일반적으로 `type: NodePort` 서비스를 요청했을 때와 동일한 변경사항을 적용하면서 시작한다.
그런 다음 cloud-controller-manager 컴포넌트는
할당된 해당 NodePort로 트래픽을 전달하도록 외부 로드 밸런서를 구성한다.
_알파 기능으로서_, 로드 밸런스된 서비스가 NodePort 할당을
[생략](#load-balancer-nodeport-allocation)하도록 구성할 수 있는데,
이는 클라우드 공급자의 구현이 이를 지원할 때에만 가능하다.
{{< note >}}
**Azure** 에서 사용자 지정 공개(public) 유형 `loadBalancerIP`를 사용하려면, 먼저
@ -1273,211 +1183,34 @@ spec:
- 80.11.12.10
```
## 단점
## 세션 스티킹(stickiness)
VIP용 유저스페이스 프록시를 사용하면 중소 규모의 스케일에서는 동작하지만, 수천 개의
서비스가 포함된 대규모 클러스터로는 확장되지 않는다.
[포털에 대한 독창적인 설계 제안](https://github.com/kubernetes/kubernetes/issues/1107)에 이에 대한 자세한 내용이
있다.
유저스페이스 프록시를 사용하면 서비스에 접근하는 패킷의 소스 IP 주소가
가려진다.
이것은 일종의 네트워크 필터링 (방화벽)을 불가능하게 만든다. iptables
프록시 모드는 클러스터 내
소스 IP를 가리지 않지만, 여전히 로드 밸런서 또는 노드-포트를 통해 오는
클라이언트에 영향을 미친다.
`Type` 필드는 중첩된 기능으로 설계되었다. - 각 레벨은 이전 레벨에
추가된다. 이는 모든 클라우드 공급자에 반드시 필요한 것은 아니지만, (예: Google Compute Engine는
`LoadBalancer`를 작동시키기 위해 `NodePort`를 할당할 필요는 없지만, AWS는 필요하다)
현재 API에는 필요하다.
## 가상 IP 구현 {#the-gory-details-of-virtual-ips}
서비스를 사용하려는 많은 사람들에게 이전 정보가
충분해야 한다. 그러나, 이해가 필요한 부분 뒤에는
많은 일이 있다.
### 충돌 방지 {#avoiding-collisions}
쿠버네티스의 주요 철학 중 하나는 잘못한 것이
없는 경우 실패할 수 있는 상황에 노출되어서는
안된다는 것이다. 서비스 리소스 설계 시, 다른 사람의 포트 선택과
충돌할 경우에 대비해 자신의 포트 번호를 선택하지
않아도 된다. 그것은 격리 실패이다.
서비스에 대한 포트 번호를 선택할 수 있도록 하기 위해,
두 개의 서비스가 충돌하지 않도록 해야 한다.
쿠버네티스는 API 서버에 설정되어 있는 `service-cluster-ip-range` CIDR 범위에서
각 서비스에 고유한 IP 주소를 할당하여 이를 달성한다.
각 서비스가 고유한 IP를 받도록 하기 위해, 내부 할당기는
각 서비스를 만들기 전에 {{< glossary_tooltip term_id="etcd" >}}에서
글로벌 할당 맵을 원자적으로(atomically) 업데이트한다. 서비스가 IP 주소 할당을 가져오려면
레지스트리에 맵 오브젝트가 있어야 하는데, 그렇지 않으면
IP 주소를 할당할 수 없다는 메시지와 함께 생성에 실패한다.
컨트롤 플레인에서, 백그라운드 컨트롤러는 해당 맵을
생성해야 한다. (인-메모리 잠금을 사용하는 이전 버전의 쿠버네티스에서 마이그레이션
지원 필요함) 쿠버네티스는 또한 컨트롤러를 사용하여 유효하지 않은
할당 (예: 관리자 개입으로)을 체크하고 더 이상 서비스에서 사용하지 않는 할당된
IP 주소를 정리한다.
#### `type: ClusterIP` 서비스의 IP 주소 범위 {#service-ip-static-sub-range}
{{< feature-state for_k8s_version="v1.25" state="beta" >}}
그러나, 이러한 `ClusterIP` 할당 전략에는 한 가지 문제가 있는데,
그것은 사용자 또한 [서비스의 IP 주소를 직접 고를 수 있기 때문이다](#choosing-your-own-ip-address).
이로 인해 만약 내부 할당기(allocator)가 다른 서비스에 대해 동일한 IP 주소를 선택하면
충돌이 발생할 수 있다.
`ServiceIPStaticSubrange`
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)는 v1.25 이상에서 기본적으로 활성화되며,
이 때 사용하는 할당 전략은 `min(max(16, cidrSize / 16), 256)` 공식을 사용하여 얻어진
`service-cluster-ip-range`의 크기에 기반하여 `ClusterIP` 범위를 두 대역으로 나누며,
여기서 이 공식은 _16 이상 256 이하이며, 그 사이에 계단 함수가 있음_ 으로 설명할 수 있다.
동적 IP 할당은 상위 대역에서 우선적으로 선택하며,
이를 통해 하위 대역에서 할당된 IP와의 충돌 위험을 줄인다.
이렇게 함으로써 사용자가 서비스의 고정 IP를
`service-cluster-ip-range`의 하위 대역에서 할당하면서도
충돌 위험을 줄일 수 있다.
### 서비스 IP 주소 {#ips-and-vips}
실제로 고정된 목적지로 라우팅되는 파드 IP 주소와 달리,
서비스 IP는 실제로 단일 호스트에서 응답하지 않는다. 대신에, kube-proxy는
iptables (리눅스의 패킷 처리 로직)를 필요에 따라
명백하게 리다이렉션되는 _가상_ IP 주소를 정의하기 위해 사용한다. 클라이언트가 VIP에
연결하면, 트래픽이 자동으로 적절한 엔드포인트로 전송된다.
환경 변수와 서비스 용 DNS는 실제로 서비스의
가상 IP 주소 (및 포트)로 채워진다.
kube-proxy는 조금씩 다르게 작동하는 세 가지 프록시 모드&mdash;유저스페이스, iptables and IPVS&mdash;를
지원한다.
#### 유저스페이스 (Userspace)
예를 들어, 위에서 설명한 이미지 처리 애플리케이션을 고려한다.
백엔드 서비스가 생성되면, 쿠버네티스 마스터는 가상
IP 주소(예 : 10.0.0.1)를 할당한다. 서비스 포트를 1234라고 가정하면, 서비스는
클러스터의 모든 kube-proxy 인스턴스에서 관찰된다.
프록시가 새 서비스를 발견하면, 새로운 임의의 포트를 열고, 가상 IP 주소에서
이 새로운 포트로 iptables 리다이렉션을 설정한 후,
연결을 수락하기 시작한다.
클라이언트가 서비스의 가상 IP 주소에 연결하면, iptables
규칙이 시작되고, 패킷을 프록시의 자체 포트로 리다이렉션한다.
"서비스 프록시"는 백엔드를 선택하고, 클라이언트에서 백엔드로의 트래픽을 프록시하기 시작한다.
이는 서비스 소유자가 충돌 위험 없이 원하는 어떤 포트든 선택할 수 있음을
의미한다. 클라이언트는 실제로 접근하는 파드를 몰라도, IP와 포트에
연결할 수 있다.
#### iptables
다시 한번, 위에서 설명한 이미지 처리 애플리케이션을 고려한다.
백엔드 서비스가 생성되면, 쿠버네티스 컨트롤 플레인은 가상
IP 주소(예 : 10.0.0.1)를 할당한다. 서비스 포트를 1234라고 가정하면, 서비스는
클러스터의 모든 kube-proxy 인스턴스에서 관찰된다.
프록시가 새로운 서비스를 발견하면, 가상 IP 주소에서 서비스-별 규칙으로
리다이렉션되는 일련의 iptables 규칙을 설치한다. 서비스-별
규칙은 트래픽을 (목적지 NAT를 사용하여) 백엔드로 리다이렉션하는 엔드포인트-별 규칙에
연결한다.
클라이언트가 서비스의 가상 IP 주소에 연결하면 iptables 규칙이 시작한다.
(세션 어피니티(Affinity)에 따라 또는 무작위로) 백엔드가 선택되고 패킷이
백엔드로 리다이렉션된다. 유저스페이스 프록시와 달리, 패킷은 유저스페이스로
복사되지 않으며, 가상 IP 주소가 작동하기 위해 kube-proxy가
실행 중일 필요는 없으며, 노드는 변경되지 않은 클라이언트 IP 주소에서 오는
트래픽을 본다.
트래픽이 노드-포트 또는 로드 밸런서를 통해 들어오는 경우에도,
이와 동일한 기본 흐름이 실행되지만, 클라이언트 IP는 변경된다.
#### IPVS
iptables 작업은 대규모 클러스터 (예: 10,000 서비스)에서 크게 느려진다.
IPVS는 로드 밸런싱을 위해 설계되었고 커널-내부 해시 테이블을 기반으로 한다.
따라서 IPVS 기반 kube-proxy로부터 많은 개수의 서비스에서 일관성 있는 성능을 가질 수 있다.
한편, IPVS 기반 kube-proxy는 보다 정교한 로드 밸런싱 알고리즘
(least conns, locality, weighted, persistence)을 가진다.
특정 클라이언트로부터의 연결이 매번 동일한 파드로 전달되도록 하고 싶다면,
클라이언트의 IP 주소 기반으로 세션 어피니티를 구성할 수 있다.
더 자세한 정보는 [세션 어피니티](/ko/docs/reference/networking/virtual-ips/#session-affinity)를
참고한다.
## API 오브젝트
서비스는 쿠버네티스 REST API의 최상위 리소스이다. [서비스 API 오브젝트](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#service-v1-core)에 대한
자세한 내용을 참고할 수 있다.
## 지원되는 프로토콜 {#protocol-support}
<!-- preserve existing hyperlinks -->
<a id="shortcomings" /><a id="#the-gory-details-of-virtual-ips" />
### TCP
## 가상 IP 주소 메커니즘
모든 종류의 서비스에 TCP를 사용할 수 있으며, 이는 기본 네트워크 프로토콜이다.
### UDP
대부분의 서비스에 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 모드의
서비스를 사용하여 서비스의 엔드포인트로 전달하는 외부 HTTP / HTTPS 리버스 프록시를
설정할 수 있다.
{{< note >}}
서비스 대신 {{< glossary_tooltip term_id="ingress" text="인그레스" >}} 를 사용하여
HTTP/HTTPS 서비스를 노출할 수도 있다.
{{< /note >}}
### PROXY 프로토콜
클라우드 공급자가 지원하는 경우에,
LoadBalancer 모드의 서비스를 사용하여 쿠버네티스 자체 외부에
로드 밸런서를 구성할 수 있으며, 이때 접두사가
[PROXY 프로토콜](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt) 인 연결을 전달하게 된다.
로드 밸런서는 들어오는 연결을 설명하는 초기 일련의
옥텟(octets)을 전송하며, 이 예와 유사하게
```
PROXY TCP4 192.0.2.202 10.0.42.7 12345 7\r\n
```
클라이언트 데이터가 뒤따라온다.
[가상 IP 및 서비스 프록시](/ko/docs/reference/networking/virtual-ips/)에서
가상 IP 주소를 갖는 서비스를 노출하기 위해 쿠버네티스가 제공하는 메커니즘에 대해 알아본다.
## {{% heading "whatsnext" %}}
* [서비스와 애플리케이션 연결](/ko/docs/concepts/services-networking/connect-applications-service/) 알아보기
* [서비스와 애플리케이션 연결](/ko/docs/tutorials/services/connect-applications-service/) 알아보기
* [인그레스](/ko/docs/concepts/services-networking/ingress/)에 대해 알아보기
* [엔드포인트슬라이스](/ko/docs/concepts/services-networking/endpoint-slices/)에 대해 알아보기
추가적으로,
* [가상 IP 및 서비스 프록시](/ko/docs/reference/networking/virtual-ips/)를 살펴보기
* 서비스(Service) API에 대한 [API 레퍼런스](/docs/reference/kubernetes-api/service-resources/service-v1/) 살펴보기
* 엔드포인트(Endpoints) API에 대한 [API 레퍼런스](/docs/reference/kubernetes-api/service-resources/endpoints-v1/) 살펴보기
* 엔드포인트슬라이스 API에 대한 [API 레퍼런스](/docs/reference/kubernetes-api/service-resources/endpoint-slice-v1/) 살펴보기

18
content/ko/docs/concepts/services-networking/topology-aware-hints.md
View File

@ -3,7 +3,11 @@
# - robscott
title: 토폴로지 인지 힌트
content_type: concept
weight: 45
weight: 100
description: >-
_토폴로지 인지 힌트_ 는 트래픽이 발생한 존 내에서 네트워크 트래픽을 유지하도록 처리하는
메커니즘을 제공한다. 클러스터의 파드간 동일한 존의 트래픽을 선호하는 것은
안전성, 성능(네트워크 지연 및 처리량) 혹은 비용 측면에 도움이 될 수 있다.
---
@ -11,20 +15,14 @@ weight: 45
{{< feature-state for_k8s_version="v1.23" state="beta" >}}
_토폴로지 인지 힌트(Topology Aware Hints)_ 는 클라이언트가 엔드포인트를 어떻게 사용해야 하는지에 대한 제안을 포함시킴으로써
_토폴로지 인지 힌트(Topology Aware Hints)_ 는 클라이언트가 엔드포인트(endpoint)를 어떻게 사용해야 하는지에 대한 제안을 포함시킴으로써
토폴로지 인지 라우팅을 가능하게 한다.
이러한 접근은 엔드포인트슬라이스(EndpointSlice) 및 엔드포인트(Endpoint) 오브젝트의 소비자(consumer)가 이용할 수 있는 메타데이터를 추가하며,
이러한 접근은 엔드포인트슬라이스(EndpointSlice) 또는 엔드포인트(Endpoints) 오브젝트의 소비자(consumer)가 이용할 수 있는 메타데이터를 추가하며,
이를 통해 해당 네트워크 엔드포인트로의 트래픽이 근원지에 더 가깝게 라우트될 수 있다.
예를 들어, 비용을 줄이거나 네트워크 성능을 높이기 위해,
인접성을 고려하여 트래픽을 라우트할 수 있다.
{{< note >}}
"토폴로지 인지 힌트" 기능은 베타 단계이며 기본적으로 활성화되어 있지 **않다**.
이 기능을 사용해 보려면,
`TopologyAwareHints` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다.
{{< /note >}}
<!-- body -->
## 동기(motivation)
@ -161,4 +159,4 @@ kube-proxy 구성요소는 엔드포인트슬라이스 컨트롤러가 설정한
## {{% heading "whatsnext" %}}
* [서비스와 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)를 읽어본다.
* [서비스와 애플리케이션 연결하기](/ko/docs/tutorials/services/connect-applications-service/)를 따라하기.

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

@ -6,7 +6,7 @@
# - marosset
title: 윈도우에서의 네트워킹
content_type: concept
weight: 75
weight: 110
---
<!-- overview -->

9
content/ko/docs/concepts/storage/dynamic-provisioning.md
View File

@ -6,7 +6,7 @@
# - msau42
title: 동적 볼륨 프로비저닝
content_type: concept
weight: 40
weight: 50
---
<!-- overview -->
@ -19,9 +19,6 @@ weight: 40
스토리지를 사전 프로비저닝 할 필요가 없다. 대신 사용자가
스토리지를 요청하면 자동으로 프로비저닝 한다.
<!-- body -->
## 배경
@ -115,8 +112,8 @@ spec:
- API 서버에서 [`DefaultStorageClass` 어드미션 컨트롤러](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass)를
사용하도록 설정한다.
관리자는 `storageclass.kubernetes.io/is-default-class` [어노테이션](/ko/docs/reference/labels-annotations-taints/#storageclass-kubernetes-io-is-default-class)을
추가해서 특정 `StorageClass` 를 기본으로 표시할 수 있다.
관리자는 [`storageclass.kubernetes.io/is-default-class` 어노테이션](/ko/docs/reference/labels-annotations-taints/#storageclass-kubernetes-io-is-default-class)을
추가하여 특정 `StorageClass` 를 기본으로 표시할 수 있다.
기본 `StorageClass` 가 클러스터에 존재하고 사용자가
`storageClassName` 를 지정하지 않은 `PersistentVolumeClaim` 을
작성하면, `DefaultStorageClass` 어드미션 컨트롤러가 디폴트

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

@ -297,18 +297,17 @@ spec:
* {{< glossary_tooltip text="csi" term_id="csi" >}}
* flexVolume (deprecated)
* gcePersistentDisk
* glusterfs
* rbd
* portworxVolume
스토리지 클래스의 `allowVolumeExpansion` 필드가 true로 설정된 경우에만 PVC를 확장할 수 있다.
``` yaml
```yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: gluster-vol-default
provisioner: kubernetes.io/glusterfs
name: example-vol-default
provisioner: vendor-name.example/magicstorage
parameters:
resturl: "http://192.168.10.100:8080"
restuser: ""
@ -333,7 +332,7 @@ PVC에 대해 더 큰 볼륨을 요청하려면 PVC 오브젝트를 수정하여
#### CSI 볼륨 확장
{{< feature-state for_k8s_version="v1.16" state="beta" >}}
{{< feature-state for_k8s_version="v1.24" state="stable" >}}
CSI 볼륨 확장 지원은 기본적으로 활성화되어 있지만 볼륨 확장을 지원하려면 특정 CSI 드라이버도 필요하다. 자세한 내용은 특정 CSI 드라이버 문서를 참고한다.
@ -438,8 +437,6 @@ PVC 확장 실패의 사용자에 의한 복구는 쿠버네티스 1.23부터
(v1.23에서 **사용 중단**)
* [`gcePersistentDisk`](/ko/docs/concepts/storage/volumes/#gcepersistentdisk) - GCE Persistent Disk
(v1.17에서 **사용 중단**)
* [`glusterfs`](/ko/docs/concepts/storage/volumes/#glusterfs) - Glusterfs 볼륨
(v1.25에서 **사용 중단**)
* [`portworxVolume`](/ko/docs/concepts/storage/volumes/#portworxvolume) - Portworx 볼륨
(v1.25에서 **사용 중단**)
* [`vsphereVolume`](/ko/docs/concepts/storage/volumes/#vspherevolume) - vSphere VMDK 볼륨
@ -616,7 +613,6 @@ PV는 `storageClassName` 속성을
* `cephfs`
* `cinder` (v1.18에서 **사용 중단됨**)
* `gcePersistentDisk`
* `glusterfs`
* `iscsi`
* `nfs`
* `rbd`
@ -745,10 +741,9 @@ AND 조건으로 동작한다. 요청된 클래스와 요청된 레이블이 있
#### 기본 스토리지클래스 할당 소급 적용하기 {#retroactive-default-storageclass-assignment}
{{< feature-state for_k8s_version="v1.25" state="alpha" >}}
{{< feature-state for_k8s_version="v1.26" state="beta" >}}
새로운 PVC를 위한 `storageClassName`을 설정하지 않고 퍼시스턴트볼륨클레임을 생성할 수 있으며, 이는 클러스터에 기본 스토리지클래스가 존재하지 않을 때에도 가능하다. 이 경우, 새로운 PVC는 정의된 대로 생성되며, 해당 PVC의 `storageClassName`은 기본값이 사용 가능해질 때까지 미설정 상태로 남는다.
하지만, [`RetroactiveDefaultStorageClass` 기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화하면 쿠버네티스는 다르게 동작하여, 기존에 존재하는 PVC 중 `storageClassName`가 설정되지 않은 PVC는 새로운 기본 스토리지클래스를 사용하도록 갱신된다.
기본 스토리지클래스가 사용 가능해지면, 컨트롤플레인은 `storageClassName`가 없는 PVC를 찾는다. `storageClassName`의 값이 비어있거나 해당 키 자체가 없는 PVC라면, 컨트롤플레인은 해당 PVC의 `storageClassName`가 새로운 기본 스토리지클래스와 일치하도록 설정하여 갱신한다. `storageClassName`가 `""`인 PVC가 있고, 기본 스토리지클래스를 설정한다면, 해당 PVC는 갱신되지 않는다.
@ -953,6 +948,25 @@ kube-apiserver와 kube-controller-manager에 대해 `AnyVolumeDataSource`
어떠한 오브젝트에 대한 참조도 명시할 수 있다(단, PVC 외의 다른 코어 오브젝트는 제외).
기능 게이트가 활성화된 클러스터에서는 `dataSource`보다 `dataSourceRef`를 사용하는 것을 권장한다.
## 네임스페이스를 교차하는 데이터 소스
{{< feature-state for_k8s_version="v1.26" state="alpha" >}}
쿠버네티스는 네임스페이스를 교차하는 볼륨 데이터 소스를 지원한다.
네임스페이스를 교차하는 볼륨 데이터 소스를 사용하기 위해서는, kube-apiserver, kube-controller-manager에 대해서 `AnyVolumeDataSource`와 `CrossNamespaceVolumeDataSource`
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를
활성화해야 한다.
또한, csi-provisioner에 대한 `CrossNamespaceVolumeDataSource` 기능 게이트도 활성화해야 한다.
`CrossNamespaceVolumeDataSource` 기능 게이트를 활성화하면 dataSourceRef 필드에 네임스페이스를 명시할 수 있다.
{{< note >}}
볼륨 데이터 소스의 네임스페이스를 명시하면, 쿠버네티스는
참조를 받아들이기 전에 다른 네임스페이스의 레퍼런스그랜트를 확인한다.
레퍼런스그랜트는 `gateway.networking.k8s.io` 확장 API에 속한다.
자세한 정보는 게이트웨이 API 문서의 [레퍼런스그랜트](https://gateway-api.sigs.k8s.io/api-types/referencegrant/)를 참고하라.
즉 이 방법을 사용하려면 우선 게이트웨이 API에서 최소한 레퍼런스그랜트 이상을 사용하여
쿠버네티스 클러스터를 확장해야 한다는 것을 의미한다.
{{< /note >}}
## 데이터 소스 참조
`dataSourceRef` 필드는 `dataSource` 필드와 거의 동일하게 동작한다.
@ -970,6 +984,11 @@ kube-apiserver와 kube-controller-manager에 대해 `AnyVolumeDataSource`
* `dataSourceRef` 필드는 여러 타입의 오브젝트를 포함할 수 있지만, `dataSource` 필드는
PVC와 VolumeSnapshot만 포함할 수 있다.
`CrossNamespaceVolumeDataSource` 기능이 활성화되어 있을 때, 추가적인 차이점이 존재한다:
* `dataSource` 필드는 로컬 오브젝트만을 허용하지만, `dataSourceRef` 필드는 모든 네임스페이스의 오브젝트를 허용한다.
* 네임스페이스가 명시되어 있을 때, `dataSource`와 `dataSourceRef`는 동기화되지 않는다.
기능 게이트가 활성화된 클러스터에서는 `dataSourceRef`를 사용해야 하고, 그렇지 않은
클러스터에서는 `dataSource`를 사용해야 한다. 어떤 경우에서든 두 필드 모두를 확인해야
할 필요는 없다. 이렇게 약간의 차이만 있는 중복된 값은 이전 버전 호환성을 위해서만
@ -1010,6 +1029,50 @@ PVC 생성 상태에 대한 피드백을 제공하기 위해, PVC에 대한 이
PVC를 위한 적절한 파퓰레이터가 설치되어 있다면,
볼륨 생성과 그 과정에서 발생하는 이슈에 대한 이벤트를 생성하는 것은 파퓰레이터 컨트롤러의 몫이다.
### 네임스페이스를 교차하는 볼륨 데이터 소스 사용하기
{{< feature-state for_k8s_version="v1.26" state="alpha" >}}
네임스페이스 소유자가 참조를 받아들일 수 있도록 레퍼런스그랜트를 생성한다.
`dataSourceRef` 필드를 사용하여 네임스페이스를 교차하는 볼륨 데이터 소스를 명시해서 파퓰레이트된 볼륨을 정의한다. 이 때, 원천 네임스페이스에 유효한 레퍼런스그랜트를 보유하고 있어야 한다:
```yaml
apiVersion: gateway.networking.k8s.io/v1beta1
kind: ReferenceGrant
metadata:
name: allow-ns1-pvc
namespace: default
spec:
from:
- group: ""
kind: PersistentVolumeClaim
namespace: ns1
to:
- group: snapshot.storage.k8s.io
kind: VolumeSnapshot
name: new-snapshot-demo
```
```yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: foo-pvc
namespace: ns1
spec:
storageClassName: example
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
dataSourceRef:
apiGroup: snapshot.storage.k8s.io
kind: VolumeSnapshot
name: new-snapshot-demo
namespace: default
volumeMode: Filesystem
```
## 포터블 구성 작성
광범위한 클러스터에서 실행되고 퍼시스턴트 스토리지가 필요한

18
content/ko/docs/concepts/storage/projected-volumes.md
View File

@ -46,7 +46,6 @@ weight: 21 # just after persistent volumes
`mode`를 명시적으로 지정할 수 있다.
## 서비스어카운트토큰 프로젝티드 볼륨 {#serviceaccounttoken}
`TokenRequestProjection` 기능이 활성화 된 경우
파드의 지정된 경로에 [서비스어카운트토큰](/docs/reference/access-authn-authz/authentication/#service-account-tokens)을
주입할 수 있다.
@ -82,6 +81,23 @@ weight: 21 # just after persistent volumes
`RunAsUser`가 설정된 리눅스 파드에서는
프로젝티드파일이 컨테이너 사용자 소유권을 포함한 올바른 소유권 집합을 가진다.
파드의 모든 컨테이너의
[`PodSecurityContext`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#security-context)나
컨테이너
[`SecurityContext`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#security-context-1)의 `runAsUser` 설정이 동일하다면,
kubelet은 `serviceAccountToken` 볼륨의 내용이 해당 사용자의 소유이며,
토큰 파일의 권한 모드는 `0600`로 설정됨을 보장한다.
{{< note >}}
생성된 후 파드에 추가되는 {{< glossary_tooltip text="임시 컨테이너" term_id="ephemeral-container" >}}는
파드 생성 시 설정된 볼륨 권한을
변경하지 *않는다*.
파드 내 그 외의 모든 컨테이너의 `runAsUser`가 동일하여
파드의 `serviceAccountToken` 볼륨 권한이 `0600`으로 설정되어 있다면, 임시
컨테이너는 토큰을 읽을 수 있도록 동일한 `runAsUser`를 사용해야 한다.
{{< /note >}}
### 윈도우
윈도우 파드에서 프로젝티드 볼륨과 파드 `SecurityContext`에 `RunAsUsername`이 설정된 경우,

2
content/ko/docs/concepts/storage/storage-capacity.md
View File

@ -7,7 +7,7 @@
# - pohly
title: 스토리지 용량
content_type: concept
weight: 70
weight: 80
---
<!-- overview -->

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

@ -6,7 +6,7 @@
# - msau42
title: 스토리지 클래스
content_type: concept
weight: 30
weight: 40
---
<!-- overview -->
@ -72,7 +72,6 @@ volumeBindingMode: Immediate
| FC | - | - |
| FlexVolume | - | - |
| GCEPersistentDisk | &#x2713; | [GCE PD](#gce-pd) |
| Glusterfs | &#x2713; | [Glusterfs](#glusterfs) |
| iSCSI | - | - |
| NFS | - | [NFS](#nfs) |
| RBD | &#x2713; | [Ceph RBD](#ceph-rbd) |
@ -123,7 +122,6 @@ true로 설정된 경우 볼륨 확장을 지원한다.
gcePersistentDisk | 1.11
awsElasticBlockStore | 1.11
Cinder | 1.11
glusterfs | 1.11
rbd | 1.11
Azure File | 1.11
Azure Disk | 1.11
@ -338,87 +336,6 @@ parameters:
[allowedTopologies](#allowed-topologies)로 대체되었다.
{{< /note >}}
### Glusterfs
```yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: slow
provisioner: kubernetes.io/glusterfs
parameters:
resturl: "http://127.0.0.1:8081"
clusterid: "630372ccdc720a92c681fb928f27b53f"
restauthenabled: "true"
restuser: "admin"
secretNamespace: "default"
secretName: "heketi-secret"
gidMin: "40000"
gidMax: "50000"
volumetype: "replicate:3"
```
* `resturl`: 필요에 따라 gluster 볼륨을 프로비전하는 Gluster REST 서비스/Heketi
서비스 url 이다. 일반적인 형식은 `IPaddress:Port` 이어야 하며 이는 GlusterFS
동적 프로비저너의 필수 파라미터이다. Heketi 서비스가 openshift/kubernetes
설정에서 라우팅이 가능한 서비스로 노출이 되는 경우 이것은 fqdn이 해석할 수 있는
Heketi 서비스 url인 `http://heketi-storage-project.cloudapps.mystorage.com` 과
유사한 형식을 가질 수 있다.
* `restauthenabled` : REST 서버에 대한 인증을 가능하게 하는 Gluster REST 서비스
인증 부울이다. 이 값이 `"true"` 이면, `restuser` 와 `restuserkey`
또는 `secretNamespace` + `secretName` 을 채워야 한다. 이 옵션은
사용 중단이며, `restuser`, `restuserkey`, `secretName` 또는
`secretNamespace` 중 하나를 지정하면 인증이 활성화된다.
* `restuser` : Gluster REST 서비스/Heketi 사용자로 Gluster Trusted Pool에서
볼륨을 생성할 수 있다.
* `restuserkey` : REST 서버에 대한 인증에 사용될 Gluster REST 서비스/Heketi
사용자의 암호이다. 이 파라미터는 `secretNamespace` + `secretName` 을 위해
사용 중단 되었다.
* `secretNamespace`, `secretName` : Gluster REST 서비스와 통신할 때 사용할
사용자 암호가 포함된 시크릿 인스턴스를 식별한다. 이 파라미터는
선택 사항으로 `secretNamespace` 와 `secretName` 을 모두 생략하면
빈 암호가 사용된다. 제공된 시크릿은 `"kubernetes.io/glusterfs"` 유형이어야
하며, 예를 들어 다음과 같이 생성한다.
```
kubectl create secret generic heketi-secret \
--type="kubernetes.io/glusterfs" --from-literal=key='opensesame' \
--namespace=default
```
시크릿의 예시는
[glusterfs-provisioning-secret.yaml](https://github.com/kubernetes/examples/tree/master/staging/persistent-volume-provisioning/glusterfs/glusterfs-secret.yaml)에서 찾을 수 있다.
* `clusterid`: `630372ccdc720a92c681fb928f27b53f` 는 볼륨을 프로비저닝할
때 Heketi가 사용할 클러스터의 ID이다. 또한, 예시와 같이 클러스터
ID 목록이 될 수 있다. 예:
`"8452344e2becec931ece4e33c4674e4e,42982310de6c63381718ccfa6d8cf397"`. 이것은
선택적 파라미터이다.
* `gidMin`, `gidMax` : 스토리지클래스에 대한 GID 범위의 최소값과
최대값이다. 이 범위( gidMin-gidMax )의 고유한 값(GID)은 동적으로
프로비전된 볼륨에 사용된다. 이것은 선택적인 값이다. 지정하지 않으면,
볼륨은 각각 gidMin과 gidMax의 기본값인 2000-2147483647
사이의 값으로 프로비전된다.
* `volumetype` : 볼륨 유형과 파라미터는 이 선택적 값으로 구성할
수 있다. 볼륨 유형을 언급하지 않는 경우, 볼륨 유형을 결정하는 것은
프로비저너의 책임이다.
예를 들어:
* 레플리카 볼륨: `volumetype: replicate:3` 여기서 '3'은 레플리카의 수이다.
* Disperse/EC 볼륨: `volumetype: disperse:4:2` 여기서 '4'는 데이터이고 '2'는 중복 횟수이다.
* Distribute 볼륨: `volumetype: none`
사용 가능한 볼륨 유형과 관리 옵션에 대해서는
[관리 가이드](https://access.redhat.com/documentation/en-us/red_hat_gluster_storage/)를 참조한다.
자세한 정보는
[Heketi 구성 방법](https://github.com/heketi/heketi/wiki/Setting-up-the-topology)을 참조한다.
퍼시스턴트 볼륨이 동적으로 프로비전되면 Gluster 플러그인은
`gluster-dynamic-<claimname>` 이라는 이름으로 엔드포인트와
헤드리스 서비스를 자동으로 생성한다. 퍼시스턴트 볼륨 클레임을
삭제하면 동적 엔드포인트와 서비스가 자동으로 삭제된다.
### NFS
```yaml

1
content/ko/docs/concepts/storage/storage-limits.md
View File

@ -6,6 +6,7 @@
# - msau42
title: 노드 별 볼륨 한도
content_type: concept
weight: 90
---
<!-- overview -->

1
content/ko/docs/concepts/storage/volume-health-monitoring.md
View File

@ -6,6 +6,7 @@
# - xing-yang
title: 볼륨 헬스 모니터링
content_type: concept
weight: 100
---
<!-- overview -->

2
content/ko/docs/concepts/storage/volume-pvc-datasource.md
View File

@ -6,7 +6,7 @@
# - msau42
title: CSI 볼륨 복제하기
content_type: concept
weight: 60
weight: 70
---
<!-- overview -->

2
content/ko/docs/concepts/storage/volume-snapshot-classes.md
View File

@ -8,7 +8,7 @@
# - yuxiangqian
title: 볼륨 스냅샷 클래스
content_type: concept
weight: 41 # just after volume snapshots
weight: 61 # just after volume snapshots
---
<!-- overview -->

142
content/ko/docs/concepts/storage/volume-snapshots.md
View File

@ -8,70 +8,112 @@
# - yuxiangqian
title: 볼륨 스냅샷
content_type: concept
weight: 40
weight: 60
---
<!-- overview -->
쿠버네티스에서 스토리지 시스템 볼륨 스냅샷은 _VolumeSnapshot_ 을 나타낸다. 이 문서는 이미 쿠버네티스 [퍼시스턴트 볼륨](/ko/docs/concepts/storage/persistent-volumes/)에 대해 잘 알고 있다고 가정한다.
쿠버네티스에서 _VolumeSnapshot_ 은 스토리지 시스템 볼륨 스냅샷을
나타낸다. 이 문서는 이미 쿠버네티스
[퍼시스턴트 볼륨](/ko/docs/concepts/storage/persistent-volumes/)에 대해 잘 알고 있다고 가정한다.
<!-- body -->
## 소개
API 리소스 `PersistentVolume` 및 `PersistentVolumeClaim` 가 사용자 및 관리자가 볼륨을 프로비전할 때의 방법과 유사하게, `VolumeSnapshotContent` 및 `VolumeSnapshot` API 리소스는 볼륨 스냅샷을 생성하기 위해 제공된다.
API 리소스 `PersistentVolume` 및 `PersistentVolumeClaim` 가
사용자와 관리자를 위해 볼륨을 프로비전할 때 사용되는 것과 유사하게, `VolumeSnapshotContent`
및 `VolumeSnapshot` API 리소스는 사용자와 관리자를 위한 볼륨 스냅샷을 생성하기 위해
제공된다.
`VolumeSnapshotContent` 는 관리자가 프로버져닝한 클러스터 볼륨에서의 스냅샷이다. 퍼시스턴트볼륨이 클러스터 리소스인 것처럼 이것 또한 클러스터 리소스이다.
`VolumeSnapshotContent` 는 관리자가
프로비져닝한 클러스터 내 볼륨의 스냅샷이다. 퍼시스턴트볼륨이
클러스터 리소스인 것처럼 이것 또한 클러스터 리소스이다.
`VolumeSnapshot` 은 사용자가 볼륨의 스냅샷을 요청할 수 있는 방법이다. 이는 퍼시스턴트볼륨클레임과 유사하다.
`VolumeSnapshot` 은 사용자가 볼륨의 스냅샷을 요청할 수 있는 방법이다. 이는
퍼시스턴트볼륨클레임과 유사하다.
`VolumeSnapshotClass` 을 사용하면 `VolumeSnapshot` 에 속한 다른 속성을 지정할 수 있다. 이러한 속성은 스토리지 시스템에의 동일한 볼륨에서 가져온 스냅샷마다 다를 수 있으므로 `PersistentVolumeClaim` 의 `StorageClass` 를 사용하여 표현할 수는 없다.
`VolumeSnapshotClass` 을 사용하면
`VolumeSnapshot` 에 속한 다른 속성을 지정할 수 있다. 이러한 속성은 스토리지 시스템에의 동일한
볼륨에서 가져온 스냅샷마다 다를 수 있으므로
`PersistentVolumeClaim` 의 동일한 `StorageClass` 를 사용하여 표현할 수는 없다.
볼륨 스냅샷은 쿠버네티스 사용자에게 완전히 새로운 볼륨을 생성하지 않고도 특정 시점에 볼륨의 콘텐츠를 복사하는 표준화된 방법을 제공한다. 예를 들어, 데이터베이스 관리자는 이 기능을 사용하여 수정 사항을 편집 또는 삭제하기 전에 데이터베이스를 백업할 수 있다.
볼륨 스냅샷은 쿠버네티스 사용자에게 완전히 새로운 볼륨을 생성하지 않고도 특정 시점에 볼륨의 콘텐츠를 복사하는
표준화된 방법을 제공한다.
예를 들어, 데이터베이스 관리자는 이 기능을 사용하여
수정 사항을 편집 또는 삭제하기 전에 데이터베이스를 백업할 수 있다.
사용자는 이 기능을 사용할 때 다음 사항을 알고 있어야 한다.
* 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)한다.
* 스냅샷 오브젝트에 대한 강화된 검증을 제공하는 검증 웹훅 서버도 있다. 이는 CSI 드라이버가 아닌 스냅샷 컨트롤러 및 CRD와 함께 쿠버네티스 배포판에 의해 설치되어야 한다. 스냅샷 기능이 활성화된 모든 쿠버네티스 클러스터에 설치해야 한다.
* CSI 드라이버에서의 볼륨 스냅샷 기능 유무는 확실하지 않다. 볼륨 스냅샷 서포트를 제공하는 CSI 드라이버는 csi-snapshotter를 사용할 가능성이 높다. 자세한 사항은 [CSI 드라이버 문서](https://kubernetes-csi.github.io/docs/)를 확인하면 된다.
* CRDs 및 스냅샷 컨트롤러는 쿠버네티스 배포 시 설치된다.
- 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)한다.
- 스냅샷 오브젝트에 대한 강화된 검증을 제공하는 검증 웹훅
서버도 있다. 이는
CSI 드라이버가 아닌 스냅샷 컨트롤러 및 CRD와 함께 쿠버네티스 배포판에 의해 설치되어야 한다. 스냅샷 기능이
활성화된 모든 쿠버네티스 클러스터에 설치해야 한다.
- CSI 드라이버에서의 볼륨 스냅샷 기능 유무는 확실하지 않다.
볼륨 스냅샷 서포트를 제공하는 CSI 드라이버는
csi-snapshotter를 사용할 가능성이 높다. 자세한 사항은 [CSI 드라이버 문서](https://kubernetes-csi.github.io/docs/)를 확인하면 된다.
- CRDs 및 스냅샷 컨트롤러는 쿠버네티스 배포 시 설치된다.
## 볼륨 스냅샷 및 볼륨 스냅샷 컨텐츠의 라이프사이클
`VolumeSnapshotContents` 은 클러스터 리소스이다. `VolumeSnapshots` 은 이러한 리소스의 요청이다. `VolumeSnapshotContents` 과 `VolumeSnapshots`의 상호 작용은 다음과 같은 라이프사이클을 따른다.
`VolumeSnapshotContents` 은 클러스터 리소스이다. `VolumeSnapshots` 은
이러한 리소스의 요청이다. `VolumeSnapshotContents` 과 `VolumeSnapshots`의 상호 작용은
다음과 같은 라이프사이클을 따른다.
### 프로비저닝 볼륨 스냅샷
스냅샷을 프로비저닝할 수 있는 방법에는 사전 프로비저닝 혹은 동적 프로비저닝의 두 가지가 있다: .
#### 사전 프로비전 {#static}
클러스터 관리자는 많은 `VolumeSnapshotContents` 을 생성한다. 그들은 클러스터 사용자들이 사용 가능한 스토리지 시스템의 실제 볼륨 스냅샷 세부 정보를 제공한다. 이것은 쿠버네티스 API에 있고 사용 가능하다.
클러스터 관리자는 많은 `VolumeSnapshotContents` 을 생성한다. 그들은
클러스터 사용자들이 사용 가능한 스토리지 시스템의 실제 볼륨 스냅샷 세부 정보를 제공한다.
이것은 쿠버네티스 API에 있고 사용 가능하다.
#### 동적
사전 프로비저닝을 사용하는 대신 퍼시스턴트볼륨클레임에서 스냅샷을 동적으로 가져오도록 요청할 수 있다. [볼륨스냅샷클래스](/ko/docs/concepts/storage/volume-snapshot-classes/)는 스냅샷 사용 시 스토리지 제공자의 특정 파라미터를 명세한다.
사전 프로비저닝을 사용하는 대신 퍼시스턴트볼륨클레임에서 스냅샷을 동적으로
가져오도록 요청할 수 있다. [볼륨스냅샷클래스](/ko/docs/concepts/storage/volume-snapshot-classes/)는
스냅샷 실행 시 스토리지 제공자의 특정 파라미터를 명세한다.
### 바인딩
스냅샷 컨트롤러는 사전 프로비저닝과 동적 프로비저닝된 시나리오에서 `VolumeSnapshot` 오브젝트와 적절한 `VolumeSnapshotContent` 오브젝트와의 바인딩을 처리한다. 바인딩은 1:1 매핑이다.
스냅샷 컨트롤러는 사전 프로비저닝과 동적 프로비저닝된 시나리오에서 `VolumeSnapshot` 오브젝트와 적절한
`VolumeSnapshotContent` 오브젝트와의 바인딩을 처리한다.
바인딩은 1:1 매핑이다.
사전 프로비저닝된 경우, 볼륨스냅샷은 볼륨스냅샷컨텐츠 오브젝트 생성이 요청될 때까지 바인드되지 않은 상태로 유지된다.
사전 프로비저닝된 경우, 볼륨스냅샷은 요청된 볼륨스냅샷컨텐츠 오브젝트가 생성될 때까지
바인드되지 않은 상태로 유지된다.
### 스냅샷 소스 보호로서의 퍼시스턴트 볼륨 클레임
이 보호의 목적은 스냅샷이 생성되는 동안 사용 중인
{{< glossary_tooltip text="퍼시스턴트볼륨클레임" term_id="persistent-volume-claim" >}}
API 오브젝트가 시스템에서 지워지지 않게 하는 것이다(데이터 손실이 발생할 수 있기 때문에).
API 오브젝트가 시스템에서 지워지지 않게 하는 것이다
(데이터 손실이 발생할 수 있기 때문에).
퍼시스턴트볼륨클레임이 스냅샷을 생성할 동안에는 해당 퍼시스턴트볼륨클레임은 사용 중인 상태이다. 스냅샷 소스로 사용 중인 퍼시스턴트볼륨클레임 API 오브젝트를 삭제한다면, 퍼시스턴트볼륨클레임 오브젝트는 즉시 삭제되지 않는다. 대신, 퍼시스턴트볼륨클레임 오브젝트 삭제는 스냅샷이 준비(readyToUse) 혹은 중단(aborted) 상태가 될 때까지 연기된다.
퍼시스턴트볼륨클레임이 스냅샷을 생성할 동안에는 해당 퍼시스턴트볼륨클레임은
사용 중인 상태이다. 스냅샷 소스로 사용 중인 퍼시스턴트볼륨클레임 API 오브젝트를
삭제한다면, 퍼시스턴트볼륨클레임 오브젝트는 즉시 삭제되지 않는다. 대신,
퍼시스턴트볼륨클레임 오브젝트 삭제는 스냅샷이 준비(readyToUse) 혹은 중단(aborted) 상태가 될 때까지 연기된다.
### 삭제
삭제는 `VolumeSnapshot` 를 삭제 시 트리거로 `DeletionPolicy` 가 실행된다. `DeletionPolicy` 가 `Delete` 라면, 기본 스토리지 스냅샷이 `VolumeSnapshotContent` 오브젝트와 함께 삭제될 것이다. `DeletionPolicy` 이 `Retain` 이라면, 기본 스트리지 스냅샷과 `VolumeSnapshotContent` 둘 다 유지된다.
`VolumeSnapshot` 를 삭제하면 삭제 과정이 트리거되고, `DeletionPolicy` 가
이어서 실행된다. `DeletionPolicy` 가 `Delete` 라면, 기본 스토리지 스냅샷이
`VolumeSnapshotContent` 오브젝트와 함께 삭제될 것이다. `DeletionPolicy` 가
`Retain` 이라면, 기본 스트리지 스냅샷과 `VolumeSnapshotContent` 둘 다 유지된다.
## 볼륨 스냅샷
@ -88,13 +130,17 @@ spec:
persistentVolumeClaimName: pvc-test
```
`persistentVolumeClaimName` 은 스냅샷을 위한 퍼시스턴트볼륨클레임 데이터 소스의 이름이다. 이 필드는 동적 프로비저닝 스냅샷이 필요하다.
`persistentVolumeClaimName` 은 스냅샷을 위한 퍼시스턴트볼륨클레임 데이터 소스의
이름이다. 이 필드는 동적 프로비저닝 스냅샷이 필요하다.
볼륨 스냅샷은 `volumeSnapshotClassName` 속성을 사용하여
[볼륨스냅샷클래스](/ko/docs/concepts/storage/volume-snapshot-classes/)의 이름을 지정하여
특정 클래스를 요청할 수 있다. 아무것도 설정하지 않으면, 사용 가능한 경우 기본 클래스가 사용될 것이다.
특정 클래스를 요청할 수 있다. 아무것도 설정하지 않으면, 사용 가능한 경우
기본 클래스가 사용될 것이다.
사전 프로비저닝된 스냅샷의 경우, 다음 예와 같이 `volumeSnapshotContentName`을 스냅샷 소스로 지정해야 한다. 사전 프로비저닝된 스냅샷에는 `volumeSnapshotContentName` 소스 필드가 필요하다.
사전 프로비저닝된 스냅샷의 경우, 다음 예와 같이 `volumeSnapshotContentName`을
스냅샷 소스로 지정해야 한다. 사전 프로비저닝된 스냅샷에는
`volumeSnapshotContentName` 소스 필드가 필요하다.
```yaml
apiVersion: snapshot.storage.k8s.io/v1
@ -108,7 +154,8 @@ spec:
## 볼륨 스냅샷 컨텐츠
각각의 볼륨스냅샷컨텐츠는 스펙과 상태를 포함한다. 동적 프로비저닝에서는, 스냅샷 공통 컨트롤러는 `VolumeSnapshotContent` 오브젝트를 생성한다. 예시는 다음과 같다.
각각의 볼륨스냅샷컨텐츠는 스펙과 상태를 포함한다. 동적 프로비저닝에서는,
스냅샷 공통 컨트롤러는 `VolumeSnapshotContent` 오브젝트를 생성한다. 예시는 다음과 같다.
```yaml
apiVersion: snapshot.storage.k8s.io/v1beta1
@ -128,9 +175,13 @@ spec:
uid: 72d9a349-aacd-42d2-a240-d775650d2455
```
`volumeHandle` 은 스토리지 백엔드에서 생성되고 볼륨 생성 중에 CSI 드라이버가 반환하는 볼륨의 고유 식별자이다. 이 필드는 스냅샷을 동적 프로비저닝하는 데 필요하다. 이것은 스냅샷의 볼륨 소스를 지정한다.
`volumeHandle` 은 스토리지 백엔드에서 생성되고
볼륨 생성 중에 CSI 드라이버가 반환하는 볼륨의 고유 식별자이다. 이 필드는
스냅샷을 동적 프로비저닝하는 데 필요하다.
이것은 스냅샷의 볼륨 소스를 지정한다.
사전 프로비저닝된 스냅샷의 경우, (클러스터 관리자로서) 다음과 같이 `VolumeSnapshotContent` 오브젝트를 작성해야 한다.
사전 프로비저닝된 스냅샷의 경우, (클러스터 관리자로서) 다음과 같이
`VolumeSnapshotContent` 오브젝트를 생성해야 한다.
```yaml
apiVersion: snapshot.storage.k8s.io/v1
@ -148,19 +199,24 @@ spec:
namespace: default
```
`snapshotHandle` 은 스토리지 백엔드에서 생성된 볼륨 스냅샷의 고유 식별자이다. 이 필드는 사전 프로비저닝된 스냅샷에 필요하다. `VolumeSnapshotContent` 가 나타내는 스토리지 시스템의 CSI 스냅샷 id를 지정한다.
`snapshotHandle` 은 스토리지 백엔드에서 생성된 볼륨 스냅샷의
고유 식별자이다. 이 필드는 사전 프로비저닝된 스냅샷에 필요하다.
`VolumeSnapshotContent` 가 나타내는 스토리지 시스템의 CSI 스냅샷 id를
지정한다.
`sourceVolumeMode` 은 스냅샷이 생성된 볼륨의 모드를 나타낸다.
`sourceVolumeMode` 필드의 값은 `Filesystem` 또는 `Block` 일 수 있다.
소스 볼륨 모드가 명시되어 있지 않으면,
`sourceVolumeMode` 은 스냅샷이 생성된 볼륨의 모드를 나타낸다.
`sourceVolumeMode` 필드의 값은 `Filesystem` 또는 `Block` 일 수 있다.
소스 볼륨 모드가 명시되어 있지 않으면,
쿠버네티스는 해당 스냅샷의 소스 볼륨 모드를 알려지지 않은 상태(unknown)로 간주하여 스냅샷을 처리한다.
`volumeSnapshotRef`은 상응하는 `VolumeSnapshot`의 참조이다. `VolumeSnapshotContent`이 이전에 프로비전된 스냅샷으로 생성된 경우, `volumeSnapshotRef`에서 참조하는 `VolumeSnapshot`은 아직 존재하지 않을 수도 있음에 주의한다.
`volumeSnapshotRef`은 상응하는 `VolumeSnapshot`의 참조이다.
`VolumeSnapshotContent`이 이전에 프로비전된 스냅샷으로 생성된 경우,
`volumeSnapshotRef`에서 참조하는 `VolumeSnapshot`은 아직 존재하지 않을 수도 있음에 주의한다.
## 스냅샷의 볼륨 모드 변환하기 {#convert-volume-mode}
클러스터에 설치된 `VolumeSnapshots` API가 `sourceVolumeMode` 필드를 지원한다면,
인증되지 않은 사용자가 볼륨의 모드를 변경하는 것을 금지하는 기능이
클러스터에 설치된 `VolumeSnapshots` API가 `sourceVolumeMode` 필드를 지원한다면,
인증되지 않은 사용자가 볼륨의 모드를 변경하는 것을 금지하는 기능이
API에 있는 것이다.
클러스터가 이 기능을 지원하는지 확인하려면, 다음 명령어를 실행한다.
@ -169,13 +225,13 @@ API에 있는 것이다.
$ kubectl get crd volumesnapshotcontent -o yaml
```
사용자가 기존 `VolumeSnapshot`으로부터 `PersistentVolumeClaim`을 생성할 때
기존 소스와 다른 볼륨 모드를 지정할 수 있도록 하려면,
`VolumeSnapshot`와 연관된 `VolumeSnapshotContent`에
사용자가 기존 `VolumeSnapshot`으로부터 `PersistentVolumeClaim`을 생성할 때
기존 소스와 다른 볼륨 모드를 지정할 수 있도록 하려면,
`VolumeSnapshot`와 연관된 `VolumeSnapshotContent`에
`snapshot.storage.kubernetes.io/allowVolumeModeChange: "true"` 어노테이션을 추가해야 한다.
이전에 프로비전된 스냅샷의 경우에는,
클러스터 관리자가 `Spec.SourceVolumeMode`를 추가해야 한다.
이전에 프로비전된 스냅샷의 경우에는, 클러스터 관리자가 `spec.sourceVolumeMode`를
추가해야 한다.
이 기능이 활성화된 예시 `VolumeSnapshotContent` 리소스는 다음과 같을 것이다.
@ -199,7 +255,7 @@ spec:
## 스냅샷을 위한 프로비저닝 볼륨
`PersistentVolumeClaim` 오브젝트의 *dataSource* 필드를 사용하여
`PersistentVolumeClaim` 오브젝트의 _dataSource_ 필드를 사용하여
스냅샷 데이터로 미리 채워진 새 볼륨을 프로비저닝할 수 있다.
보다 자세한 사항은

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

@ -172,7 +172,7 @@ EBS 볼륨이 파티션된 경우, 선택적 필드인 `partition: "<partition n
#### azureFile CSI 마이그레이션
{{< feature-state for_k8s_version="v1.21" state="beta" >}}
{{< feature-state for_k8s_version="v1.26" state="stable" >}}
`azureFile` 의 `CSIMigration` 기능이 활성화된 경우, 기존 트리 내 플러그인에서
`file.csi.azure.com` 컨테이너 스토리지 인터페이스(CSI)
@ -335,12 +335,20 @@ spec:
* 웹 서버 컨테이너가 데이터를 처리하는 동안 컨텐츠 매니저
컨테이너가 가져오는 파일을 보관
환경에 따라, `emptyDir` 볼륨은 디스크, SSD 또는 네트워크 스토리지와
같이 노드를 지원하는 모든 매체에 저장된다. 그러나, `emptyDir.medium` 필드를
`"Memory"`로 설정하면, 쿠버네티스에 tmpfs(RAM 기반 파일시스템)를 마운트하도록 할 수 있다.
tmpfs는 매우 빠르지만, 디스크와 다르게 노드 재부팅시 tmpfs가 지워지고,
작성하는 모든 파일이 컨테이너 메모리
제한에 포함된다.
`emptyDir.medium` 필드는 `emptyDir` 볼륨이 저장되는 곳을 제어한다.
기본 `emptyDir` 볼륨은 환경에 따라
디스크, SSD 또는 네트워크 스토리지와 같이 노드를 지원하는 모든 매체에 저장된다.
`emptyDir.medium` 필드를 `"Memory"`로 설정하면, 쿠버네티스는 tmpfs(RAM 기반 파일시스템)를 대신
마운트한다. tmpfs는 매우 빠르지만, 디스크와 다르게
노드 재부팅시 tmpfs는 마운트 해제되고, 작성하는 모든 파일이
컨테이너 메모리 제한에 포함된다.
`emptyDir` 볼륨의 용량을 제한하는 기본 medium을 위해,
크기 제한을 명시할 수 있다. 스토리지는 [노드 임시
스토리지](/ko/docs/concepts/configuration/manage-resources-containers/#로컬-임시-스토리지에-대한-요청-및-제한-설정)로부터 할당된다.
만약 해당 공간이 다른 소스(예를 들어, 로그 파일이나 이미지 오버레이)에 의해
채워져있다면, `emptyDir`는 지정된 제한 이전에 용량을 다 쓰게 될 수 있다.
{{< note >}}
`SizeMemoryBackedVolumes` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화된 경우,
@ -364,7 +372,8 @@ spec:
name: cache-volume
volumes:
- name: cache-volume
emptyDir: {}
emptyDir:
sizeLimit: 500Mi
```
### fc (파이버 채널) {#fc}
@ -533,24 +542,15 @@ spec:
repository: "git@somewhere:me/my-git-repository.git"
revision: "22f1d8406d464b0c0874075539c1f2e96c253775"
```
### glusterfs (제거됨) {#glusterfs}
### glusterfs (사용 중단됨)
<!-- maintenance note: OK to remove all mention of glusterfs once the v1.25 release of
Kubernetes has gone out of support -->
-
쿠버네티스 {{< skew currentVersion >}} 는 `glusterfs` 볼륨 타입을 포함하지 않는다.
{{< feature-state for_k8s_version="v1.25" state="deprecated" >}}
`glusterfs` 볼륨을 사용하면 [Glusterfs](https://www.gluster.org) (오픈
소스 네트워크 파일시스템) 볼륨을 파드에 마운트할 수 있다. 파드를
제거할 때 지워지는 `emptyDir` 와는 다르게 `glusterfs`
볼륨의 내용은 유지되고, 볼륨은 마운트 해제만 된다. 이 의미는
glusterfs 볼륨에 데이터를 미리 채울 수 있으며, 파드 간에 데이터를
공유할 수 있다. GlusterFS는 여러 작성자가 동시에
마운트할 수 있다.
{{< note >}}
사용하려면 먼저 GlusterFS를 설치하고 실행해야 한다.
{{< /note >}}
더 자세한 내용은 [GlusterFS 예시](https://github.com/kubernetes/examples/tree/master/volumes/glusterfs)를 본다.
GlusterFS 인-트리 스토리지 드라이버는 쿠버네티스 1.25에서 사용 중단되었고
v1.26 릴리즈에서 완전히 제거되었다.
### hostPath {#hostpath}
@ -762,11 +762,33 @@ local [스토리지클래스(StorageClas)](/ko/docs/concepts/storage/storage-cla
파드 간에 데이터를 공유할 수 있다는 뜻이다. NFS는 여러 작성자가
동시에 마운트할 수 있다.
```yaml
apiVersion: v1
kind: Pod
metadata:
name: test-pd
spec:
containers:
- image: registry.k8s.io/test-webserver
name: test-container
volumeMounts:
- mountPath: /my-nfs-data
name: test-volume
volumes:
- name: test-volume
nfs:
server: my-nfs-server.example.com
path: /my-nfs-volume
readOnly: true
```
{{< note >}}
사용하려면 먼저 NFS 서버를 실행하고 공유를 내보내야 한다.
또한 파드 스펙에 NFS 마운트 옵션을 명시할 수 없음을 기억하라. 마운트 옵션을 서버에서 설정하거나, [/etc/nfsmount.conf](https://man7.org/linux/man-pages/man5/nfsmount.conf.5.html)를 사용해야 한다. 마운트 옵션을 설정할 수 있게 허용하는 퍼시스턴트볼륨을 통해 NFS 볼륨을 마운트할 수도 있다.
{{< /note >}}
더 자세한 내용은 [NFS 예시](https://github.com/kubernetes/examples/tree/master/staging/volumes/nfs)를 본다.
퍼시스턴트볼륨을 사용하여 NFS 볼륨을 마운트하는 예제는 [NFS 예시](https://github.com/kubernetes/examples/tree/master/staging/volumes/nfs)를 본다.
### persistentVolumeClaim {#persistentvolumeclaim}
@ -921,20 +943,17 @@ tmpfs(RAM 기반 파일시스템)로 지원되기 때문에 비 휘발성 스토
#### vSphere CSI 마이그레이션 {#vsphere-csi-migration}
{{< feature-state for_k8s_version="v1.19" state="beta" >}}
`vsphereVolume` 용 `CSIMigrationvSphere` 기능은 쿠버네티스 v1.25부터 기본적으로 활성화되어 있다.
인-트리 `vspherevolume`의 모든 플러그인 작업은 `CSIMigrationvSphere` 기능 게이트가 비활성화된 경우를 제외하고 `csi.vsphere.vmware.com` {{< glossary_tooltip text="CSI" term_id="csi" >}}로 리다이렉트된다.
{{< feature-state for_k8s_version="v1.26" state="stable" >}}
쿠버네티스 {{< skew currentVersion >}}에서, 인-트리 `vsphereVolume` 타입을 위한 모든 작업은
`csi.vsphere.vmware.com` {{< glossary_tooltip text="CSI" term_id="csi" >}} 드라이버로 리다이렉트된다.
[vSphere CSI 드라이버](https://github.com/kubernetes-sigs/vsphere-csi-driver)가
클러스터에 설치되어 있어야 한다. 인-트리 `vsphereVolume` 마이그레이션에 대한 추가 조언은 VMware의 문서 페이지
클러스터에 설치되어 있어야 한다. 인-트리 `vsphereVolume` 마이그레이션에 대한 추가 조언은 VMware의 문서 페이지
[인-트리 vSphere 볼륨을 vSphere 컨테이너 스토리지 플러그인으로 마이그레이션하기](https://docs.vmware.com/en/VMware-vSphere-Container-Storage-Plug-in/2.0/vmware-vsphere-csp-getting-started/GUID-968D421F-D464-4E22-8127-6CB9FF54423F.html)를 참고한다.
vSphere CSI 드라이버가 설치되어있지 않다면 볼륨 작업은 인-트리 `vsphereVolume` 타입으로 생성된 PV에서 수행될 수 없다.
쿠버네티스 v1.25 현재, 7.0u2 이하의 vSphere는
(사용 중단된) 인-트리 vSphere 스토리지 드라이버가 지원되지 않는다.
사용 중단된 드라이버를 계속 사용하거나, 교체된 CSI 드라이버로
마이그레이션하기 위해서는 vSphere 7.0u2 이상을 사용해야 한다.
vSphere CSI 드라이버로 마이그레이션하기 위해서는 vSphere 7.0u2 이상을 사용해야 한다.
v{{< skew currentVersion >}} 외의 쿠버네티스 버전을 사용 중인 경우,
해당 쿠버네티스 버전의 문서를 참고한다.
@ -1220,7 +1239,7 @@ CSI 드라이버로 전환할 때 기존 스토리지 클래스, 퍼시스턴트
* [`gcePersistentDisk`](#gcepersistentdisk)
* [`vsphereVolume`](#vspherevolume)
### flexVolume (사용 중단됨) {#flexvolume-deprecated}
### flexVolume (사용 중단됨) {#flexvolume}
{{< feature-state for_k8s_version="v1.23" state="deprecated" >}}

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

@ -8,6 +8,7 @@
# - aravindhp
title: 윈도우 스토리지
content_type: concept
weight: 110
---
<!-- overview -->
@ -56,9 +57,9 @@ content_type: concept
[플러그인](/ko/docs/concepts/storage/volumes/#volume-types) 형태로 제공된다.
윈도우는 다음의 광역 쿠버네티스 볼륨 플러그인 클래스를 지원한다.
* [`FlexVolume 플러그인`](/ko/docs/concepts/storage/volumes/#flexvolume-deprecated)
* FlexVolumes은 1.23부터 사용 중단되었음에 유의한다.
* [`CSI 플러그인`](/ko/docs/concepts/storage/volumes/#csi)
* [`FlexVolume` 플러그인](/ko/docs/concepts/storage/volumes/#flexvolume)
* FlexVolume은 1.23부터 사용 중단되었음에 유의한다.
* [`CSI` 플러그인](/ko/docs/concepts/storage/volumes/#csi)
##### 인-트리(In-tree) 볼륨 플러그인

17
content/ko/docs/concepts/windows/intro.md
View File

@ -212,7 +212,7 @@ API 및 kubectl의 관점에서, 윈도우 컨테이너는 리눅스 기반 컨
* `securityContext.capabilities` -
POSIX 기능은 윈도우에서 구현되지 않았다.
* `securityContext.privileged` -
윈도우는 특권을 가진(privileged) 컨테이너를 지원하지 않는다.
윈도우는 특권을 가진(privileged) 컨테이너를 지원하지 않는다. 대신 [호스트 프로세스 컨테이너](/docs/tasks/configure-pod-container/create-hostprocess-pod/)를 사용한다.
* `securityContext.procMount` -
윈도우에는 `/proc` 파일시스템이 없다.
* `securityContext.readOnlyRootFilesystem` -
@ -238,11 +238,11 @@ API 및 kubectl의 관점에서, 윈도우 컨테이너는 리눅스 기반 컨
다음 목록은 윈도우와 리눅스에서 파드 명세가 어떻게 다르게 동작하는지 기술한다.
* `hostIPC` 및 `hostpid` - 호스트 네임스페이스 공유 기능은 윈도우에서 사용할 수 없다.
* `hostNetwork` - 윈도우 운영 체제에서 호스트 네트워크 공유 기능을 지원하지 않는다.
* `hostNetwork` - [하단 참조](#compatibility-v1-pod-spec-containers-hostnetwork)
* `dnsPolicy` - 윈도우에서 호스트 네트워킹이 지원되지 않기 때문에
`dnsPolicy`를 `ClusterFirstWithHostNet`로 설정할 수 없다.
파드는 항상 컨테이너 네트워크와 함께 동작한다.
* `podSecurityContext` (하단 참조)
* `podSecurityContext` [하단 참조](#compatibility-v1-pod-spec-containers-securitycontext)
* `shareProcessNamespace` - 이것은 베타 기능이며, 윈도우에서 구현되지 않은 리눅스 네임스페이스에 의존한다.
윈도우는 프로세스 네임스페이스 또는 컨테이너의 루트 파일시스템을 공유할 수 없다.
네트워크만 공유할 수 있다.
@ -261,6 +261,17 @@ API 및 kubectl의 관점에서, 윈도우 컨테이너는 리눅스 기반 컨
* `mountPropagation` - 마운트 전파(propagation)는 윈도우에서 지원되지 않으므로
이 필드는 활성화할 수 없다.
#### 호스트 네트워크(hostNetwork)의 필드 호환성 {#compatibility-v1-pod-spec-containers-hostnetwork}
{{< feature-state for_k8s_version="v1.26" state="alpha" >}}
이제 kubelet은, 윈도우 노드에서 실행되는 파드가 새로운 파드 네트워크 네임스페이스를 생성하는 대신 호스트의 네트워크 네임스페이스를 사용하도록 요청할 수 있다.
이 기능을 활성화하려면 kubelet에 `--feature-gates=WindowsHostNetwork=true`를 전달한다.
{{< note >}}
이 기능을 지원하는 컨테이너 런타임을 필요로 한다.
{{< /note >}}
#### 파드 시큐리티 컨텍스트의 필드 호환성 {#compatibility-v1-pod-spec-containers-securitycontext}
파드 [`securityContext`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#security-context)의 모든 필드는 윈도우에서 작동하지 않는다.

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

@ -1,6 +1,6 @@
---
title: "워크로드"
weight: 50
weight: 55
description: >
쿠버네티스에서 배포할 수 있는 가장 작은 컴퓨트 오브젝트인 파드와, 이를 실행하는 데 도움이 되는 하이-레벨(higher-level) 추상화
no_list: true
@ -62,7 +62,7 @@ _모든_ 파드가 가용한 경우가 아닌 경우 멈추고 싶다면(아마
* [`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/)로 실행
또는 [복제된 세트](/ko/docs/tasks/run-application/run-replicated-stateful-application/)로 실행
* [`CronJob` 을 사용하여 자동화된 작업 실행](/ko/docs/tasks/job/automated-tasks-with-cron-jobs/)
코드를 구성(configuration)에서 분리하는 쿠버네티스의 메커니즘을 배우기 위해서는,

9
content/ko/docs/concepts/workloads/controllers/cron-jobs.md
View File

@ -92,6 +92,7 @@ kube-controller-manager 컨테이너에 설정된 시간대는
크론잡 스케줄 표현을 생성하기 위해서 [crontab.guru](https://crontab.guru/)와 같은 웹 도구를 사용할 수도 있다.
## 타임 존
크론잡에 타임 존이 명시되어 있지 않으면, kube-controller-manager는 로컬 타임 존을 기준으로 스케줄을 해석한다.
{{< feature-state for_k8s_version="v1.25" state="beta" >}}
@ -101,7 +102,7 @@ kube-controller-manager 컨테이너에 설정된 시간대는
타임 존에 대한 실험적 지원을 제공하지 않는 쿠버네티스 버전을 사용 중인 경우,
클러스터의 모든 크론잡은 타임 존이 명시되지 않은 것으로 동작한다).
이 기능을 활성화하면, `spec.timeZone`을 유효한 [타임 존](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones) 이름으로 지정할 수 있다.
이 기능을 활성화하면, `spec.timeZone`을 유효한 [타임 존](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones)으로 지정할 수 있다.
예를 들어, `spec.timeZone: "Etc/UTC"`와 같이 설정하면 쿠버네티스는 협정 세계시를 기준으로 스케줄을 해석한다.
Go 표준 라이브러리의 타임 존 데이터베이스가 바이너리로 인클루드되며, 시스템에서 외부 데이터베이스를 사용할 수 없을 때 폴백(fallback)으로 사용된다.
@ -123,13 +124,13 @@ Go 표준 라이브러리의 타임 존 데이터베이스가 바이너리로
모든 크론잡에 대해 크론잡 {{< glossary_tooltip term_id="controller" text="컨트롤러" >}} 는 마지막 일정부터 지금까지 얼마나 많은 일정이 누락되었는지 확인한다. 만약 100회 이상의 일정이 누락되었다면, 잡을 실행하지 않고 아래와 같은 에러 로그를 남긴다.
````
```
Cannot determine if job needs to be started. Too many missed start time (> 100). Set or decrease .spec.startingDeadlineSeconds or check clock skew.
````
```
중요한 것은 만약 `startingDeadlineSeconds` 필드가 설정이 되면(`nil` 이 아닌 값으로), 컨트롤러는 마지막 일정부터 지금까지 대신 `startingDeadlineSeconds` 값에서 몇 개의 잡이 누락되었는지 카운팅한다. 예를 들면, `startingDeadlineSeconds` 가 `200` 이면, 컨트롤러는 최근 200초 내 몇 개의 잡이 누락되었는지 카운팅한다.
크론잡은 정해진 일정에 잡 실행을 실패하면 놓쳤다고 카운팅된다. 예를 들면, `concurrencyPolicy` 가 `Forbid` 로 설정되었고, 크론잡이 이전 일정이 스케줄되어 여전히 시도하고 있을 때, 그 때 누락되었다고 판단한다.
크론잡은 정해진 시간에 생성되는데 실패하면 누락(missed)된 것으로 집계된다. 예를 들어 `concurrencyPolicy`가 `Forbid` 로 설정되어 있고 이전 크론잡이 여전히 실행 중인 상태라면, 크론잡은 일정에 따라 시도되었다가 생성을 실패하고 누락된 것으로 집계될 것이다.
즉, 크론잡이 `08:30:00` 에 시작하여 매 분마다 새로운 잡을 실행하도록 설정이 되었고,
`startingDeadlineSeconds` 값이 설정되어 있지 않는다고 가정해보자. 만약 크론잡 컨트롤러가

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

@ -203,8 +203,7 @@ nodeAffinity:
- 애플리케이션과 동일한 방법으로 데몬을 모니터링하고 로그 관리를 할 수 있다.
- 데몬 및 애플리케이션과 동일한 구성 언어와 도구(예: 파드 템플릿, `kubectl`).
- 리소스 제한이 있는 컨테이너에서 데몬을 실행하면 앱 컨테이너에서
데몬간의 격리를 증가시킨다. 그러나 이것은 파드가 아닌 컨테이너에서 데몬을 실행해서 이루어진다
(예: 도커에서 직접적으로 시작).
데몬간의 격리를 증가시킨다. 그러나 이것은 파드가 아닌 컨테이너에서 데몬을 실행해서 이루어진다.
### 베어(Bare) 파드

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

@ -44,9 +44,9 @@ _디플로이먼트(Deployment)_ 는 {{< glossary_tooltip text="파드" term_id=
이 예시에 대한 설명은 다음과 같다.
* `.metadata.name` 필드에 따라 `nginx-deployment` 이름으로 디플로이먼트가 생성된다.
* `.spec.replicas` 필드에 따라 디플로이먼트는 3개의 레플리카 파드를 생성한다.
* `.spec.selector` 필드는 디플로이먼트가 관리할 파드를 찾는 방법을 정의한다.
* `.metadata.name` 필드에 따라, `nginx-deployment` 이름을 가진 디플로이먼트가 생성된다.
* `.spec.replicas` 필드에 따라, 디플로이먼트는 3개의 레플리카 파드를 생성하는 레플리카셋을 생성한다.
* `.spec.selector` 필드는, 생성된 레플리카셋이 관리할 파드를 찾아내는 방법을 정의한다.
이 사례에서는 파드 템플릿에 정의된 레이블(`app: nginx`)을 선택한다.
그러나 파드 템플릿 자체의 규칙이 만족되는 한,
보다 정교한 선택 규칙의 적용이 가능하다.

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

@ -1,5 +1,6 @@
---
# reviewers:
# - alculquicondor
# - erictune
# - soltysh
title: 잡
@ -260,11 +261,12 @@ _작업 큐_ 잡은 `.spec.completions` 를 설정하지 않은 상태로 두고
- `Indexed`: 잡의 파드는 연결된 완료 인덱스를 0에서 `.spec.completions-1` 까지
가져온다. 이 인덱스는 다음의 세 가지 메카니즘으로 얻을 수 있다.
- 파드 어노테이션 `batch.kubernetes.io/job-completion-index`.
- 파드 호스트네임 중 일부(`$(job-name)-$(index)` 형태). 인덱스된(Indexed) 잡과
{{< glossary_tooltip text="서비스" term_id="Service" >}}를 결합하여 사용하고
있다면, 잡에 속한 파드는 DNS를 이용하여 서로를 디스커버 하기 위해 사전에 결정된
호스트네임을 사용할 수 있다.
- 컨테이너화된 태스크의 경우, `JOB_COMPLETION_INDEX` 환경 변수.
- 파드 호스트네임 중 일부(`$(job-name)-$(index)` 형태).
인덱스된(Indexed) 잡과
{{< glossary_tooltip text="서비스" term_id="Service" >}}를 결합하여 사용하고 있다면, 잡에 속한 파드는
DNS를 이용하여 서로를 디스커버 하기 위해 사전에 결정된 호스트네임을 사용할 수 있다.
이를 어떻게 설정하는지에 대해 궁금하다면, [파드 간 통신을 위한 잡](/ko/docs/tasks/job/job-with-pod-to-pod-communication/)를 확인한다.
- 컨테이너화된 태스크의 경우, 환경 변수 `JOB_COMPLETION_INDEX`에 있다.
각 인덱스에 대해 성공적으로 완료된 파드가 하나 있으면 작업이 완료된 것으로
간주된다. 이 모드를 사용하는 방법에 대한 자세한 내용은
@ -289,6 +291,10 @@ _작업 큐_ 잡은 `.spec.completions` 를 설정하지 않은 상태로 두고
한다는 점이다. 특히, 이전 실행으로 인한 임시파일, 잠금, 불완전한 출력 그리고 이와 유사한
것들을 처리해야 한다.
기본적으로 파드의 실패는 `.spec.backoffLimit` 제한값으로 계산되며,
자세한 내용은 [파드 백오프(backoff) 실패 정책](#파드-백오프-backoff-실패-정책)을 확인한다. 그러나,
잡의 [파드 실패 정책](#pod-failure-policy)을 설정하여 파드의 실패 수준을 조절하여 사용할 수도 있다.
`.spec.parallelism = 1`, `.spec.completions = 1` 그리고
`.spec.template.spec.restartPolicy = "Never"` 를 지정하더라도 같은 프로그램을
두 번 시작하는 경우가 있다는 점을 참고한다.
@ -296,6 +302,19 @@ _작업 큐_ 잡은 `.spec.completions` 를 설정하지 않은 상태로 두고
`.spec.parallelism` 그리고 `.spec.completions` 를 모두 1보다 크게 지정한다면 한번에
여러 개의 파드가 실행될 수 있다. 따라서 파드는 동시성에 대해서도 관대(tolerant)해야 한다.
만약 [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)인
`PodDisruptionConditions`와 `JobPodFailurePolicy`가 모두 활성화되어 있고,
`.spec.podFailurePolicy` 필드가 설정되어 있다면, 잡 컨트롤러는 종료 중인
파드(`.metadata.deletionTimestamp` 필드가 설정된 파드)가 종료 상태(`.status.phase` 값이 `Failed` 혹은 `Succeeded`)가 될 때 까지
해당 파드를 실패로 간주하지 않는다. 그러나, 잡 컨트롤러는
파드가 명백히 종료되었다고 판단하면 곧바로 대체 파드를 생성한다.
파드가 한 번 종료되면, 잡 컨트롤러는 방금 종료된 파드를 고려하여
관련 작업에 대해 `.backoffLimit`과 `.podFailurePolicy`를 평가한다.
이러한 조건들이 하나라도 충족되지 않을 경우, 잡 컨트롤러는
종료 중인 파드가 추후 `phase: "Succeded"`로 종료된다고 할지라도,
해당 파드를 실패한 파드로 즉시 간주한다.
### 파드 백오프(backoff) 실패 정책
구성에 논리적 오류가 포함되어 있어서 몇 회의 재시도 이후에
@ -313,10 +332,6 @@ _작업 큐_ 잡은 `.spec.completions` 를 설정하지 않은 상태로 두고
계산 중 하나가 `.spec.backoffLimit`에 도달하면, 잡이
실패한 것으로 간주한다.
[`JobTrackingWithFinalizers`](#종료자-finalizers-를-이용한-잡-추적) 기능이 비활성화되어
있다면, 실패한 파드의 수는 API에 여전히 표시되고 있는 파드로만
계산된다.
{{< note >}}
만약 잡에 `restartPolicy = "OnFailure"` 가 있는 경우 잡 백오프 한계에
도달하면 잡을 실행 중인 파드가 종료된다. 이로 인해 잡 실행 파일의 디버깅이
@ -461,12 +476,13 @@ spec:
여기에 트레이드오프가 요약되어 있고, 2열에서 4열까지가 위의 트레이드오프에 해당한다.
패턴 이름은 예시와 더 자세한 설명을 위한 링크이다.
| 패턴 | 단일 잡 오브젝트 | 작업 항목보다 파드가 적은가? | 수정되지 않은 앱을 사용하는가? |
| ----------------------------------------- |:-----------------:|:---------------------------:|:-------------------:|
| [작업 항목 당 파드가 있는 큐] | ✓ | | 때때로 |
| [가변 파드 수를 가진 큐] | ✓ | ✓ | |
| [정적 작업 할당을 사용한 인덱싱된 잡] | ✓ | | ✓ |
| [잡 템플릿 확장] | | | ✓ |
| 패턴 | 단일 잡 오브젝트 | 작업 항목보다 파드가 적은가? | 수정되지 않은 앱을 사용하는가? |
| ----------------------------------------------- |:-----------------:|:---------------------------:|:-------------------:|
| [작업 항목 당 파드가 있는 큐] | ✓ | | 때때로 |
| [가변 파드 수를 가진 큐] | ✓ | ✓ | |
| [정적 작업 할당을 사용한 인덱싱된 잡] | ✓ | | ✓ |
| [잡 템플릿 확장] | | | ✓ |
| [파드 간 통신을 위한 잡] | ✓ | 때때로 | 때때로 |
`.spec.completions` 로 완료를 지정할 때, 잡 컨트롤러에 의해 생성된 각 파드는
동일한 [`사양`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)을 갖는다. 이 의미는
@ -477,17 +493,19 @@ spec:
이 표는 각 패턴에 필요한 `.spec.parallelism` 그리고 `.spec.completions` 설정을 보여준다.
여기서 `W` 는 작업 항목의 수이다.
| 패턴 | `.spec.completions` | `.spec.parallelism` |
| ----------------------------------------- |:-------------------:|:--------------------:|
| [작업 항목 당 파드가 있는 큐] | W | any |
| [가변 파드 수를 가진 큐] | null | any |
| [정적 작업 할당을 사용한 인덱싱된 잡] | W | any |
| [잡 템플릿 확장] | 1 | 1이어야 함 |
| 패턴 | `.spec.completions` | `.spec.parallelism` |
| ----------------------------------------------- |:-------------------:|:--------------------:|
| [작업 항목 당 파드가 있는 큐] | W | any |
| [가변 파드 수를 가진 큐] | null | any |
| [정적 작업 할당을 사용한 인덱싱된 잡] | W | any |
| [잡 템플릿 확장] | 1 | 1이어야 함 |
| [파드 간 통신을 위한 잡] | W | W |
[작업 항목 당 파드가 있는 큐]: /ko/docs/tasks/job/coarse-parallel-processing-work-queue/
[가변 파드 수를 가진 큐]: /ko/docs/tasks/job/fine-parallel-processing-work-queue/
[정적 작업 할당을 사용한 인덱싱된 잡]: /ko/docs/tasks/job/indexed-parallel-processing-static/
[잡 템플릿 확장]: /ko/docs/tasks/job/parallel-processing-expansion/
[파드 간 통신을 위한 잡]: /ko/docs/tasks/job/job-with-pod-to-pod-communication/
## 고급 사용법
@ -697,7 +715,7 @@ spec:
### 파드 실패 정책{#pod-failure-policy}
{{< feature-state for_k8s_version="v1.25" state="alpha" >}}
{{< feature-state for_k8s_version="v1.26" state="beta" >}}
{{< note >}}
잡(Job)에 대한 파드 실패 정책은
@ -706,7 +724,7 @@ spec:
파드 장애 정책의 파드 중단 조건 (참조:
[파드 중단 조건](/ko/docs/concepts/workloads/pods/disruptions#pod-disruption-conditions))을
감지하고 처리할 수 있도록 `PodDisruptionConditions` 기능 게이트를 활성화하는 것을 권장한다. 두 기능 게이트 모두
쿠버네티스 v1.25에서 사용할 수 있다.
쿠버네티스 {{< skew currentVersion >}}에서 사용할 수 있다.
{{< /note >}}
`.spec.podFailurePolicy` 필드로 정의되는 파드 실패 정책은, 클러스터가
@ -780,43 +798,33 @@ kubelet은 특정 파드에서 `main` 컨테이너를 재시작하지 않는다.
### 종료자(finalizers)를 이용한 잡 추적
{{< feature-state for_k8s_version="v1.23" state="beta" >}}
{{< feature-state for_k8s_version="v1.26" state="stable" >}}
{{< note >}}
이 기능을 이용하기 위해서는
[API 서버](/docs/reference/command-line-tools-reference/kube-apiserver/)와
[컨트롤러 매니저](/docs/reference/command-line-tools-reference/kube-controller-manager/)에 대해
`JobTrackingWithFinalizers` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다.
이 기능이 활성화되면, 컨트롤 플레인은 아래에 설명할 동작을 이용하여 새로운 잡이 생성되는지 추적한다.
이 기능이 활성화되기 이전에 생성된 잡은 영향을 받지 않는다.
사용자가 느낄 수 있는 유일한 차이점은
컨트롤 플레인이 잡 종료를 좀 더 정확하게 추적할 수 있다는 것이다.
컨트롤 플레인을 1.26으로 업그레이드하더라도,
기능 게이트 `JobTrackingWithFinalizers`가 비활성화되어 있을 때 생성된 잡이라면,
컨트롤 플레인은 종료자를 사용하는 잡을 추적하지 않는다.
{{< /note >}}
이 기능이 활성화되지 않으면, 잡
{{< glossary_tooltip text="컨트롤러" term_id="controller" >}}는
`succeeded`와 `failed` 파드의 수를 세어 잡 상태를 추적한다.
그런데, 파드는 다음과 같은 이유로 제거될 수 있다.
- 노드가 다운되었을 때 가비지 콜렉터가 버려진(orphan) 파드를 제거
- 가비지 콜렉터가 (`Succeeded` 또는 `Failed` 단계에 있는) 완료된 파드를
일정 임계값 이후에 제거
- 잡에 속한 파드를 사용자가 임의로 제거
- (쿠버네티스에 속하지 않는) 외부 컨트롤러가 파드를 제거하거나
교체
컨트롤 플레인은 잡에 속한 파드들을 계속 추적하고,
API 서버로부터 제거된 파드가 있는지에 대해 알려준다. 이를 위해 잡 컨트롤러는
`batch.kubernetes.io/job-tracking` 종료자를 갖는 파드를 생성한다.
컨트롤러는 파드가 잡 상태로 처리된 이후에만 종료자를 제거하여,
다른 컨트롤러나 사용자가 파드를 제거할 수 있도록 한다.
클러스터에서 `JobTrackingWithFinalizers` 기능을 활성화하면,
컨트롤 플레인은 잡에 속하는 파드의 상태를 추적하고
API 서버에서 파드가 제거되면 이를 알아챈다.
이를 위해, 잡 컨트롤러는 `batch.kubernetes.io/job-tracking` 종료자를 갖는 파드를 생성한다.
컨트롤러는 파드의 상태 변화가 잡 상태에 반영된 후에만 종료자를 제거하므로,
이후 다른 컨트롤러나 사용자가 파드를 제거할 수 있다.
쿠버네티스를 1.26으로 업그레이드하기 전이나, 기능 게이트
`JobTrackingWithFinalizers`를 활성화시키기 전에 생성한 잡은 파드 종료자를 사용하지 않고
추적된다.
잡 {{< glossary_tooltip term_id="controller" text="컨트롤러" >}}는
클러스터에 존재하는 파드들에 대해서만 `succeded`와 `failed` 파드들에 대한 상태 카운터를 갱신한다.
만약 파드가 클러스터에서 제거된다면,
컨트롤 플레인은 잡의 진행 상황을 제대로 추적하지 못할 수 있다.
잡 컨트롤러는 새로운 잡에 대해서만 새로운 알고리즘을 적용한다.
이 기능이 활성화되기 전에 생성된 잡은 영향을 받지 않는다.
잡에 `batch.kubernetes.io/job-tracking` 어노테이션이 있는지 확인하여,
잡 컨트롤러가 파드 종료자를 이용하여 잡을 추적하고 있는지 여부를 확인할 수 있다.
이 어노테이션을 잡에 수동으로 추가하거나 제거해서는 **안 된다**.
잡이 `batch.kubernetes.io/job-tracking` 어노테이션을 가지고 있는지 확인함으로써
컨트롤 플레인이 파드 종료자를 사용하여 잡을 추적하고 있는지 알 수 있다.
따라서 잡으로부터 이 어노테이션을 수동으로 추가하거나 제거해서는 **안 된다**.
그 대신, 파드 종료자를 사용하여
추적이 가능한 잡을 재생성하면 된다.
## 대안
@ -856,7 +864,7 @@ API 서버에서 파드가 제거되면 이를 알아챈다.
* 다른 방식으로 잡을 구동하는 방법에 대해서 읽는다.
* [작업 대기열을 사용한 거친 병렬 처리](/ko/docs/tasks/job/coarse-parallel-processing-work-queue/)
* [작업 대기열을 사용한 정밀 병렬 처리](/ko/docs/tasks/job/fine-parallel-processing-work-queue/)
* [병렬 처리를 위한 정적 작업 할당으로 인덱스된 잡](/ko/docs/tasks/job/indexed-parallel-processing-static/)(베타) 사용
* [병렬 처리를 위한 정적 작업 할당으로 인덱스된 잡](/ko/docs/tasks/job/indexed-parallel-processing-static/) 사용
* 템플릿 기반으로 복수의 잡 생성: [확장을 사용한 병렬 처리](/ko/docs/tasks/job/parallel-processing-expansion/)
* [완료된 잡을 자동으로 정리](#clean-up-finished-jobs-automatically) 섹션 내 링크를 따라서
클러스터가 완료되거나 실패된 태스크를 어떻게 정리하는지에 대해 더 배운다.
@ -866,4 +874,5 @@ API 서버에서 파드가 제거되면 이를 알아챈다.
오브젝트 정의를 읽는다.
* 스케줄을 기반으로 실행되는 일련의 잡을 정의하는데 사용할 수 있고, 유닉스 툴 `cron`과 유사한
[`CronJob`](/ko/docs/concepts/workloads/controllers/cron-jobs/)에 대해 읽는다.
* 단계별로 구성된 [예제](/docs/tasks/job/pod-failure-policy/)를 통해, `podFailurePolicy`를 사용하여 재시도 가능 및 재시도 불가능 파드의 실패 처리를 하기위한 구성 방법을 연습한다.
* 단계별로 구성된 [예제](/docs/tasks/job/pod-failure-policy/)를 통해,
`podFailurePolicy`를 사용하여 재시도 가능 및 재시도 불가능 파드의 실패 처리를 하기위한 구성 방법을 연습한다.

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

@ -4,6 +4,13 @@
#- bprashanth
#- madhusudancs
title: 레플리카셋
feature:
title: 자가 치유
anchor: 레플리카셋 동작 방식
description: >
실패한 컨테이너를 재시작하고, 노드가 죽는 경우 컨테이너들을 교체하기 위해 다시 스케줄링을 하며,
사용자가 정의한 상태 체크에 응답하지 않는 컨테이너들을 종료시키며,
서비스를 제공할 준비가 완료될 때까지 해당 컨테이너를 클라이언트에 알리지 않는다.
content_type: concept
weight: 20
---
@ -37,8 +44,8 @@ OwnerReference가 없거나, OwnerReference가 {{< glossary_tooltip term_id="con
레플리카셋은 지정된 수의 파드 레플리카가 항상 실행되도록 보장한다.
그러나 디플로이먼트는 레플리카셋을 관리하고 다른 유용한 기능과 함께
파드에 대한 선언적 업데이트를 제공하는 상위 개념이다.
따라서 우리는 사용자 지정 오케스트레이션이 필요하거나 업데이트가 전혀 필요하지 않은 경우라면
레플리카셋을 직접적으로 사용하기 보다는 디플로이먼트를 사용하는 것을 권장한다.
따라서 별도의 사용자 정의(custom) 업데이트 오케스트레이션이 필요한 경우 또는 업데이트가 전혀 필요 없는 경우가 아니라면,
레플리카셋을 직접 사용하기보다는 디플로이먼트를 사용하는 것을 권장한다.
이는 레플리카셋 오브젝트를 직접 조작할 필요가 없다는 것을 의미한다.
대신 디플로이먼트를 이용하고 사양 부분에서 애플리케이션을 정의하면 된다.

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

@ -3,12 +3,6 @@
# - bprashanth
# - janetkuo
title: 레플리케이션 컨트롤러
feature:
title: 자가 치유
anchor: 레플리케이션 컨트롤러의 동작 방식
description: >
오류가 발생한 컨테이너를 재시작하고, 노드가 죽었을 때 컨테이너를 교체하기 위해 다시 스케줄하고, 사용자 정의 상태 체크에 응답하지 않는 컨테이너를 제거하며, 서비스를 제공할 준비가 될 때까지 클라이언트에 해당 컨테이너를 알리지 않는다.
content_type: concept
weight: 90
---
@ -139,7 +133,7 @@ nginx-3ntk0 nginx-4ok8v nginx-qrm3m
오직 `Always` 와 동일한 [`.spec.template.spec.restartPolicy`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#재시작-정책)만 허용되며, 특별히 지정되지 않으면 기본값이다.
로컬 컨테이너의 재시작의 경우, 레플리케이션 컨트롤러는 노드의 에이전트에게 위임한다.
예를 들어 [Kubelet](/docs/reference/command-line-tools-reference/kubelet/) 혹은 도커이다.
예를 들어 [Kubelet](/docs/reference/command-line-tools-reference/kubelet/)이다.
### 레플리케이션 컨트롤러에서 레이블
@ -270,7 +264,7 @@ API 오브젝트에 대한 더 자세한 것은
### 베어 파드
사용자가 직접 파드를 만든 경우와 달리 레플리케이션 컨트롤러는 노드 오류 또는 커널 업그레이드와 같은 장애가 발생하는 노드 유지 관리의 경우와 같이 어떤 이유로든 삭제되거나 종료된 파드를 대체한다. 따라서 애플리케이션에 하나의 파드만 필요한 경우에도 레플리케이션 컨트롤러를 사용하는 것이 좋다. 프로세스 관리자와 비슷하게 생각하면, 단지 단일 노드의 개별 프로세스가 아닌 여러 노드에서 여러 파드를 감독하는 것이다. 레플리케이션 컨트롤러는 로컬 컨테이너가 노드의 에이전트로 (예를 들어 Kubelet 또는 도커 ) 재시작하도록 위임한다.
사용자가 직접 파드를 만든 경우와 달리 레플리케이션 컨트롤러는 노드 오류 또는 커널 업그레이드와 같은 장애가 발생하는 노드 유지 관리의 경우와 같이 어떤 이유로든 삭제되거나 종료된 파드를 대체한다. 따라서 애플리케이션에 하나의 파드만 필요한 경우에도 레플리케이션 컨트롤러를 사용하는 것이 좋다. 프로세스 관리자와 비슷하게 생각하면, 단지 단일 노드의 개별 프로세스가 아닌 여러 노드에서 여러 파드를 감독하는 것이다. 레플리케이션 컨트롤러는 로컬 컨테이너가 kubelet과 같은 노드의 에이전트로 재시작하도록 위임한다.
### 잡

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

@ -144,8 +144,7 @@ spec:
문제 없이 실행되고 준비되는 최소 시간(초)을 나타내는 선택적인 필드이다.
[롤링 업데이트](#롤링-업데이트) 전략을 사용할 때 롤아웃 진행 상황을 확인하는 데 사용된다.
이 필드의 기본값은 0이다(이 경우, 파드가 Ready 상태가 되면 바로 사용 가능하다고 간주된다.)
파드가 언제 사용 가능하다고 간주되는지에 대한 자세한 정보는
[컨테이너 프로브(probe)](/ko/docs/concepts/workloads/pods/pod-lifecycle/#컨테이너-프로브-probe)를 참고한다.
파드가 언제 사용 가능하다고 간주되는지에 대한 자세한 정보는 [컨테이너 프로브(probe)](/ko/docs/concepts/workloads/pods/pod-lifecycle/#컨테이너-프로브-probe)를 참고한다.
## 파드 신원
@ -155,8 +154,23 @@ spec:
### 순서 색인
N개의 레플리카가 있는 스테이트풀셋은 스테이트풀셋에 있는
N개의 [레플리카](#레플리카)가 있는 스테이트풀셋은 스테이트풀셋에 있는
각 파드에 0에서 N-1 까지의 정수가 순서대로 할당되며 해당 스테이트풀셋 내에서 고유 하다.
기본적으로 파드는 0부터 N-1까지의 순서대로 할당된다.
### 시작 순서
{{< feature-state for_k8s_version="v1.26" state="alpha" >}}
`.spec.ordinals`은 각 파드에 할당할 순서에 대한
정수값을 설정할 수 있게 해주는 선택적인 필드로, 기본값은 nil이다.
이 필드를 사용하기 위해서는
`StatefulSetStartOrdinal` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다.
활성화 시, 다음과 같은 옵션들을 설정할 수 있다.
* `.spec.ordinals.start`: 만약 `.spec.ordinals.start` 필드가 세팅되지 않을 경우, 파드는
`.spec.ordinals.start` 부터
`.spec.ordinals.start + .spec.replicas - 1`의 순서대로 할당된다.
### 안정적인 네트워크 신원
@ -215,7 +229,7 @@ PersistentVolumeClaim을 받는다. 위의 nginx 예시에서 각 파드는 `my-
### 파드 이름 레이블
스테이트풀셋 {{< glossary_tooltip term_id="controller" >}}
스테이트풀셋 {{< glossary_tooltip text="컨트롤러" term_id="controller" >}}
가 파드를 생성할 때 파드 이름으로 `statefulset.kubernetes.io/pod-name`
레이블이 추가된다. 이 레이블로 스테이트풀셋의 특정 파드에 서비스를
연결할 수 있다.
@ -351,7 +365,7 @@ web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가
선택적 필드인 `.spec.persistentVolumeClaimRetentionPolicy` 는
스테이트풀셋의 생애주기동안 PVC를 삭제할 것인지,
삭제한다면 어떻게 삭제하는지를 관리한다.
이 필드를 사용하려면 `StatefulSetAutoDeletePVC` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다.
이 필드를 사용하려면 API 서버와 컨트롤러 매니저에 `StatefulSetAutoDeletePVC` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다.
활성화 시, 각 스테이트풀셋에 대해 두 가지 정책을 설정할 수 있다.
`whenDeleted`
@ -444,7 +458,7 @@ spec:
* 스테이트풀셋을 사용하는 방법을 알아본다.
* [스테이트풀셋 애플리케이션 배포](/ko/docs/tutorials/stateful-application/basic-stateful-set/) 예제를 따라한다.
* [스테이트풀셋으로 카산드라 배포](/ko/docs/tutorials/stateful-application/cassandra/) 예제를 따라한다.
* [복제된 스테이트풀셋 애플리케이션 구동하기](/docs/tasks/run-application/run-replicated-stateful-application/) 예제를 따라한다.
* [복제된 스테이트풀셋 애플리케이션 구동하기](/ko/docs/tasks/run-application/run-replicated-stateful-application/) 예제를 따라한다.
* [스테이트풀셋 확장하기](/ko/docs/tasks/run-application/scale-stateful-set/)에 대해 배운다.
* [스테이트풀셋을 삭제하면](/ko/docs/tasks/run-application/delete-stateful-set/) 어떤 일이 수반되는지를 배운다.
* [스토리지의 볼륨을 사용하는 파드 구성](/ko/docs/tasks/configure-pod-container/configure-volume-storage/)을 하는 방법을 배운다.

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

@ -39,12 +39,10 @@ _파드_ (고래 떼(pod of whales)나 콩꼬투리(pea pod)와 마찬가지로)
{{< /note >}}
파드의 공유 콘텍스트는 리눅스 네임스페이스, 컨트롤 그룹(cgroup) 및
도커 컨테이너를 격리하는 것과 같이 잠재적으로 다른 격리 요소들이다.
파드의 콘텍스트 내에서 개별 애플리케이션은
추가적으로 하위 격리가 적용된다.
{{< glossary_tooltip text="컨테이너" term_id="container" >}}를 격리하는 것과 같이 잠재적으로 다른 격리 요소들이다.
파드의 콘텍스트 내에서 개별 애플리케이션은 추가적으로 하위 격리가 적용된다.
도커 개념 측면에서, 파드는 공유 네임스페이스와 공유 파일시스템 볼륨이
있는 도커 컨테이너 그룹과 비슷하다.
파드는 공유 네임스페이스와 공유 파일시스템 볼륨이 있는 컨테이너들의 집합과 비슷하다.
## 파드의 사용

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

@ -72,7 +72,7 @@ weight: 60
- 파드가 필요로 하는 [리소스를 요청](/ko/docs/tasks/configure-pod-container/assign-memory-resource/)하는지 확인한다.
- 고가용성이 필요한 경우 애플리케이션을 복제한다.
(복제된 [스테이트리스](/ko/docs/tasks/run-application/run-stateless-application-deployment/) 및
[스테이트풀](/docs/tasks/run-application/run-replicated-stateful-application/) 애플리케이션에 대해 알아보기.)
[스테이트풀](/ko/docs/tasks/run-application/run-replicated-stateful-application/) 애플리케이션에 대해 알아보기.)
- 복제된 애플리케이션의 구동 시 훨씬 더 높은 가용성을 위해 랙 전체
([안티-어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#파드간-어피니티와-안티-어피니티) 이용)
또는 영역 간
@ -229,7 +229,12 @@ drain 커멘드는 `pod-b` 를 축출하는데 성공했다.
## 파드 중단 조건 {#pod-disruption-conditions}
{{< feature-state for_k8s_version="v1.25" state="alpha" >}}
{{< feature-state for_k8s_version="v1.26" state="beta" >}}
{{< note >}}
만약 쿠버네티스 {{< skew currentVersion >}} 보다 낮은 버전을 사용하고 있다면,
해당 버전의 문서를 참조하자.
{{< /note >}}
{{< note >}}
클러스터에서 이 동작을 사용하려면 `PodDisruptionConditions`
@ -254,6 +259,9 @@ drain 커멘드는 `pod-b` 를 축출하는데 성공했다.
`DeletionByPodGC`
: 더 이상 존재하지 않는 노드에 바인딩된 파드는 [파드의 가비지 콜렉션](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection)에 의해 삭제될 예정이다.
`TerminationByKubelet`
: {{<glossary_tooltip term_id="node-pressure-eviction" text="노드 압박-축출">}} 또는 [그레이스풀 노드 셧다운](/ko/docs/concepts/architecture/nodes/#graceful-node-shutdown)으로 인해 kubelet이 파드를 종료시켰다.
{{< note >}}
파드 중단은 중단될 수 있다. 컨트롤 플레인은 동일한 파드의 중단을
계속 다시 시도하지만, 파드의 중단이 보장되지는 않는다. 결과적으로,

Some files were not shown because too many files have changed in this diff Show More