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

Merge pull request #29998 from kubernetes/dev-1.22-ko.1

Browse Source 
[ko] 1st Korean localization work for v1.22
This commit is contained in:
Kubernetes Prow Robot
2021-10-09 06:54:36 -07:00
committed by GitHub
parent 1cd35c2a42 14e5fe697f
commit 38be851062
105 changed files with 3053 additions and 648 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/ko/community/_index.html
+2 -2
View File
@@ -12,8 +12,8 @@ cid: community
<div class="intro">
<br class="mobile">
<p>사용자, 기여자, 그리고 우리가 함께 구축한 문화로 구성된 쿠버네티스 커뮤니티는 이 오픈소스 프로젝트가 급부상하는 가장 큰 이유 중 하나입니다. 프로젝트 자체가 성장 하고 변화함에 따라 우리의 문화와 가치관이 계속 성장하고 변화하고 있습니다. 우리 모두는 프로젝트의 지속적인 개선과 작업 방식을 위해 함께 노력합니다.
<br><br>우리는 이슈를 제기하고 풀 리퀘스트하고, SIG 미팅과 쿠버네티스 모임 그리고 KubeCon에 참석하고 채택과 혁신을 옹호하며, <code>kubectl get pods</code> 을 실행하고, 다른 수천가지 중요한 방법으로 기여하는 사람들 입니다. 여러분이 어떻게 이 놀라운 공동체의 일부가 될 수 있는지 계속 읽어보세요.</p>
<p>사용자, 기여자, 그리고 우리가 함께 구축한 문화를 통해 구성된 쿠버네티스 커뮤니티는 본 오픈소스 프로젝트가 급부상하는 가장 큰 이유 중 하나입니다. 프로젝트 자체가 성장하고 변화함에 따라 우리의 문화와 가치관 또한 지속적으로 성장하고 변화하고 있습니다. 우리 모두는 프로젝트와 작업 방식을 지속적으로 개선하기 위해 함께 노력합니다.
<br><br>우리는 이슈(issue)와 풀 리퀘스트(pull request)를 제출하고, SIG 미팅과 쿠버네티스 모임 그리고 KubeCon에 참석하고, 도입(adoption)과 혁신(innovation)을 지지하며, <code>kubectl get pods</code> 를 실행하고, 다른 수천가지 중요한 방법으로 기여하는 사람들 입니다. 어떻게 하면 이 놀라운 공동체의 일부가 될 수 있는지 계속 읽어보세요.</p>
<br class="mobile">
</div>
content/ko/docs/concepts/architecture/nodes.md
+43
View File
@@ -392,6 +392,49 @@ Message: Node is shutting, evicting pods
이는 갑작스러운 노드 종료의 경우와 비교했을 때 동작에 차이가 있다.
{{< /note >}}
## 스왑(swap) 메모리 관리 {#swap-memory}
{{< feature-state state="alpha" for_k8s_version="v1.22" >}}
쿠버네티스 1.22 이전에는 노드가 스왑 메모리를 지원하지 않았다. 그리고
kubelet은 노드에서 스왑을 발견하지 못한 경우 시작과 동시에 실패하도록 되어 있었다.
1.22부터는 스왑 메모리 지원을 노드 단위로 활성화할 수 있다.
노드에서 스왑을 활성화하려면, `NodeSwap` 기능 게이트가 kubelet에서
활성화되어야 하며, 명령줄 플래그 `--fail-swap-on` 또는
[구성 설정](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)에서 `failSwapOn`가
false로 지정되어야 한다.
사용자는 또한 선택적으로 `memorySwap.swapBehavior`를 구성할 수 있으며,
이를 통해 노드가 스왑 메모리를 사용하는 방식을 명시한다. 예를 들면,
```yaml
memorySwap:
swapBehavior: LimitedSwap
```
`swapBehavior`에 가용한 구성 옵션은 다음과 같다.
- `LimitedSwap`: 쿠버네티스 워크로드는 스왑을 사용할 수 있는 만큼으로
제한된다. 쿠버네티스에 의해 관리되지 않는 노드의 워크로드는 여전히 스왑될 수 있다.
- `UnlimitedSwap`: 쿠버네티스 워크로드는 요청한 만큼 스왑 메모리를 사용할 수 있으며,
시스템의 최대치까지 사용 가능하다.
만약 `memorySwap` 구성이 명시되지 않았고 기능 게이트가 활성화되어 있다면,
kubelet은 `LimitedSwap` 설정과 같은 행동을
기본적으로 적용한다.
`LimitedSwap` 설정에 대한 행동은 노드가 ("cgroups"으로 알려진)
제어 그룹이 v1 또는 v2 중에서 무엇으로 동작하는가에 따라서 결정된다.
- **cgroupsv1:** 쿠버네티스 워크로드는 메모리와 스왑의 조합을 사용할 수 있다.
파드의 메모리 제한이 설정되어 있다면 가용 상한이 된다.
- **cgroupsv2:** 쿠버네티스 워크로드는 스왑 메모리를 사용할 수 없다.
테스트를 지원하고 피드벡을 제공하기 위한 정보는
[KEP-2400](https://github.com/kubernetes/enhancements/issues/2400) 및
[디자인 제안](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/2400-node-swap/README.md)에서 찾을 수 있다.
## {{% heading "whatsnext" %}}
* 노드를 구성하는 [컴포넌트](/ko/docs/concepts/overview/components/#노드-컴포넌트)에 대해 알아본다.
content/ko/docs/concepts/cluster-administration/kubelet-garbage-collection.md
+12
View File
@@ -6,6 +6,18 @@ weight: 70
<!-- overview -->
{{< note >}}
이 한글 문서는 더 이상 관리되지 않습니다.
이 문서의 기반이 된 영어 원문은 삭제되었으며,
[Garbage Collection](/docs/concepts/architecture/garbage-collection/)에 병합되었습니다.
[Garbage Collection](/docs/concepts/architecture/garbage-collection/)의 한글화가 완료되면,
이 문서는 삭제될 수 있습니다.
{{< /note >}}
가비지 수집은 사용되지 않는
[이미지](/ko/docs/concepts/containers/#컨테이너-이미지)들과
[컨테이너](/ko/docs/concepts/containers/)들을 정리하는 kubelet의 유용한 기능이다. Kubelet은
content/ko/docs/concepts/cluster-administration/logging.md
+1 -1
View File
@@ -80,7 +80,7 @@ kubectl logs counter
로테이션하도록 컨테이너 런타임을 설정할 수도 있다.
예를 들어, `kube-up.sh` 가 GCP의 COS 이미지 로깅을 설정하는 방법은
[`configure-helper` 스크립트](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh)를 통해
[`configure-helper` 스크립트](https://github.com/kubernetes/kubernetes/blob/master/cluster/gce/gci/configure-helper.sh)를 통해
자세히 알 수 있다.
**CRI 컨테이너 런타임** 을 사용할 때, kubelet은 로그를 로테이션하고 로깅 디렉터리 구조를 관리한다.
content/ko/docs/concepts/cluster-administration/manage-deployment.md
+1 -1
View File
@@ -160,7 +160,7 @@ persistentvolumeclaim/my-pvc created
지금까지 사용한 예는 모든 리소스에 최대 한 개의 레이블만 적용하는 것이었다. 세트를 서로 구별하기 위해 여러 레이블을 사용해야 하는 많은 시나리오가 있다.
예를 들어, 애플리케이션마다 `app` 레이블에 다른 값을 사용하지만, [방명록 예제](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/)와 같은 멀티-티어 애플리케이션은 각 티어를 추가로 구별해야 한다. 프론트엔드는 다음의 레이블을 가질 수 있다.
예를 들어, 애플리케이션마다 `app` 레이블에 다른 값을 사용하지만, [방명록 예제](https://github.com/kubernetes/examples/tree/master/guestbook/)와 같은 멀티-티어 애플리케이션은 각 티어를 추가로 구별해야 한다. 프론트엔드는 다음의 레이블을 가질 수 있다.
```yaml
labels:
content/ko/docs/concepts/configuration/overview.md
+2 -2
View File
@@ -21,7 +21,7 @@ weight: 10
- JSON보다는 YAML을 사용해 구성 파일을 작성한다. 비록 이러한 포맷들은 대부분의 모든 상황에서 통용되어 사용될 수 있지만, YAML이 좀 더 사용자 친화적인 성향을 가진다.
- 의미상 맞다면 가능한 연관된 오브젝트들을 하나의 파일에 모아 놓는다. 때로는 여러 개의 파일보다 하나의 파일이 더 관리하기 쉽다. 이 문법의 예시로서 [guestbook-all-in-one.yaml](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/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`를 호출할 수 있다.
@@ -63,7 +63,7 @@ DNS 서버는 새로운 `서비스`를 위한 쿠버네티스 API를 Watch하며
## 레이블 사용하기
- `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`처럼 애플리케이션이나 디플로이먼트의 __속성에 대한 의미__ 를 식별하는 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)을 정의해 사용한다. 다른 리소스를 위해 적절한 파드를 선택하는 용도로 이러한 레이블을 이용할 수 있다. 예를 들어, 모든 `tier: frontend` 파드를 선택하거나, `app: myapp`의 모든 `phase: test` 컴포넌트를 선택하는 서비스를 생각해 볼 수 있다. 이 접근 방법의 예시는 [방명록](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) 앱을 참고한다.
- `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`처럼 애플리케이션이나 디플로이먼트의 __속성에 대한 의미__ 를 식별하는 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)을 정의해 사용한다. 다른 리소스를 위해 적절한 파드를 선택하는 용도로 이러한 레이블을 이용할 수 있다. 예를 들어, 모든 `tier: frontend` 파드를 선택하거나, `app: myapp`의 모든 `phase: test` 컴포넌트를 선택하는 서비스를 생각해 볼 수 있다. 이 접근 방법의 예시는 [방명록](https://github.com/kubernetes/examples/tree/master/guestbook/) 앱을 참고한다.
릴리스에 특정되는 레이블을 서비스의 셀렉터에서 생략함으로써 여러 개의 디플로이먼트에 걸치는 서비스를 생성할 수 있다. 동작 중인 서비스를 다운타임 없이 갱신하려면, [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)를 사용한다.
content/ko/docs/concepts/configuration/secret.md
+26 -16
View File
@@ -12,26 +12,33 @@ weight: 30
<!-- overview -->
쿠버네티스 시크릿을 사용하면 비밀번호, OAuth 토큰, ssh 키와 같은
민감한 정보를 저장하고 관리할 수 ​​있다. 기밀 정보를 시크릿에 저장하는 것이
{{< glossary_tooltip term_id="pod" >}} 정의나
{{< glossary_tooltip text="컨테이너 이미지" term_id="image" >}}
내에 그대로 두는 것보다 안전하고 유연하다.
자세한 내용은 [시크릿 디자인 문서](https://git.k8s.io/community/contributors/design-proposals/auth/secrets.md)를 참고한다.
시크릿은 암호, 토큰 또는 키와 같은 소량의 중요한 데이터를
포함하는 오브젝트이다. 그렇지 않으면 이러한 정보가 파드
명세나 이미지에 포함될 수 있다. 사용자는 시크릿을 만들 수 있고 시스템도
일부 시크릿을 만들 수 있다.
포함하는 오브젝트이다. 이를 사용하지 않으면 중요한 정보가 {{< glossary_tooltip text="파드" term_id="pod" >}}
명세나 {{< glossary_tooltip text="컨테이너 이미지" term_id="image" >}}에
포함될 수 있다. 시크릿을 사용한다는 것은 사용자의 기밀 데이터를
애플리케이션 코드에 넣을 필요가
없음을 뜻한다.
시크릿은 시크릿을 사용하는 파드와 독립적으로 생성될 수 있기 때문에,
파드를 생성하고, 확인하고, 수정하는 워크플로우 동안 시크릿(그리고 데이터)이
노출되는 것에 대한 위험을 경감시킬 수 있다. 쿠버네티스
및 클러스터에서 실행되는 애플리케이션은 기밀 데이터를 비휘발성
저장소에 쓰는 것을 피하는 것과 같이, 시크릿에 대해 추가 예방 조치를 취할 수도 있다.
시크릿은 {{< glossary_tooltip text="컨피그맵" term_id="configmap" >}}과 유사하지만
특별히 기밀 데이터를 보관하기 위한 것이다.
{{< caution >}}
쿠버네티스 시크릿은 기본적으로 암호화되지 않은 base64 인코딩 문자열로 저장된다.
기본적으로 API 액세스 권한이 있는 모든 사용자 또는 쿠버네티스의 기본 데이터 저장소 etcd에
액세스할 수 있는 모든 사용자가 일반 텍스트로 검색할 수 있다.
시크릿을 안전하게 사용하려면 (최소한) 다음과 같이 하는 것이 좋다.
쿠버네티스 시크릿은 기본적으로 API 서버의 기본 데이터 저장소(etcd)에 암호화되지 않은 상태로 저장된다. API 접근(access) 권한이 있는 모든 사용자 또는 etcd에 접근할 수 있는 모든 사용자는 시크릿을 조회하거나 수정할 수 있다.
또한 네임스페이스에서 파드를 생성할 권한이 있는 사람은 누구나 해당 접근을 사용하여 해당 네임스페이스의 모든 시크릿을 읽을 수 있다. 여기에는 디플로이먼트 생성 기능과 같은 간접 접근이 포함된다.
시크릿을 안전하게 사용하려면 최소한 다음의 단계를 따르는 것이 좋다.
1. 시크릿에 대한 [암호화 활성화](/docs/tasks/administer-cluster/encrypt-data/).
2. 시크릿 읽기 및 쓰기를 제한하는 [RBAC 규칙 활성화 또는 구성](/ko/docs/reference/access-authn-authz/authorization/). 파드를 만들 권한이 있는 모든 사용자는 시크릿을 암묵적으로 얻을 수 있다.
2. 시크릿의 데이터 읽기 및 쓰기(간접적인 방식 포함)를 제한하는 [RBAC 규칙](/ko/docs/reference/access-authn-authz/authorization/)
활성화 또는 구성.
3. 적절한 경우, RBAC와 같은 메커니즘을 사용하여 새로운 시크릿을 생성하거나 기존 시크릿을 대체할 수 있는 주체(principal)들을 제한한다.
{{< /caution >}}
<!-- body -->
@@ -47,6 +54,10 @@ weight: 30
- [컨테이너 환경 변수](#시크릿을-환경-변수로-사용하기)로써 사용.
- 파드의 [이미지를 가져올 때 kubelet](#imagepullsecrets-사용하기)에 의해 사용.
쿠버네티스 컨트롤 플레인 또한 시크릿을 사용한다. 예를 들어,
[부트스트랩 토큰 시크릿](#부트스트랩-토큰-시크릿)은
노드 등록을 자동화하는 데 도움을 주는 메커니즘이다.
시크릿 오브젝트의 이름은 유효한
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
사용자는 시크릿을 위한 파일을 구성할 때 `data` 및 (또는) `stringData` 필드를
@@ -1236,7 +1247,6 @@ API 서버에서 kubelet으로의 통신은 SSL/TLS로 보호된다.
API 서버 정책이 해당 사용자가 시크릿을 읽을 수 있도록 허용하지 않더라도, 사용자는
시크릿을 노출하는 파드를 실행할 수 있다.
## {{% heading "whatsnext" %}}
- [`kubectl` 을 사용한 시크릿 관리](/docs/tasks/configmap-secret/managing-secret-using-kubectl/)하는 방법 배우기
content/ko/docs/concepts/containers/container-environment.md
+1 -1
View File
@@ -52,7 +52,7 @@ FOO_SERVICE_HOST=<서비스가 동작 중인 호스트>
FOO_SERVICE_PORT=<서비스가 동작 중인 포트>
```
서비스에 지정된 IP 주소가 있고 [DNS 애드온](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/)이 활성화된 경우, DNS를 통해서 컨테이너가 서비스를 사용할 수 있다.
서비스에 지정된 IP 주소가 있고 [DNS 애드온](https://releases.k8s.io/master/cluster/addons/dns/)이 활성화된 경우, DNS를 통해서 컨테이너가 서비스를 사용할 수 있다.
content/ko/docs/concepts/containers/images.md
+5 -8
View File
@@ -1,4 +1,7 @@
---
title: 이미지
content_type: concept
weight: 10
@@ -16,9 +19,6 @@ weight: 10
이 페이지는 컨테이너 이미지 개념의 개요를 제공한다.
<!-- body -->
## 이미지 이름
@@ -210,10 +210,6 @@ kubectl describe pods/private-image-test-1 | grep 'Failed'
### 미리 내려받은 이미지
{{< note >}}
Google 쿠버네티스 엔진에서 동작 중이라면, 이미 각 노드에 Google 컨테이너 레지스트리에 대한 자격 증명과 함께 `.dockercfg`가 있을 것이다. 그렇다면 이 방법은 쓸 수 없다.
{{< /note >}}
{{< note >}}
이 방법은 노드의 구성을 제어할 수 있는 경우에만 적합하다. 이 방법은
클라우드 제공자가 노드를 관리하고 자동으로 교체한다면 안정적으로
@@ -334,4 +330,5 @@ Kubelet은 모든 `imagePullSecrets` 파일을 하나의 가상 `.docker/config.
## {{% heading "whatsnext" %}}
* [OCI 이미지 매니페스트 명세](https://github.com/opencontainers/image-spec/blob/master/manifest.md) 읽어보기
* [OCI 이미지 매니페스트 명세](https://github.com/opencontainers/image-spec/blob/master/manifest.md) 읽어보기.
* [컨테이너 이미지 가비지 수집(garbage collection)](/docs/concepts/architecture/garbage-collection/#container-image-garbage-collection)에 대해 배우기.
content/ko/docs/concepts/containers/runtime-class.md
+4 -1
View File
@@ -1,4 +1,7 @@
---
title: 런타임클래스(RuntimeClass)
content_type: concept
weight: 20
@@ -115,7 +118,7 @@ dockershim은 사용자 정의 런타임 핸들러를 지원하지 않는다.
유효한 핸들러는 runtimes 단락 아래에서 설정한다.
```
[plugins.cri.containerd.runtimes.${HANDLER_NAME}]
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.${HANDLER_NAME}]
```
더 자세한 containerd의 구성 문서를 살펴본다.
content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md
+17 -8
View File
@@ -197,31 +197,39 @@ service PodResourcesLister {
}
```
`List` 엔드포인트는 독점적으로 할당된 CPU의 ID, 장치 플러그인에 의해 보고된 장치 ID,
이러한 장치가 할당된 NUMA 노드의 ID와 같은 세부 정보와 함께
실행 중인 파드의 리소스에 대한 정보를 제공한다.
`List` 엔드포인트는 실행 중인 파드의 리소스에 대한 정보를 제공하며,
독점적으로 할당된 CPU의 ID, 장치 플러그인에 의해 보고된 장치 ID,
이러한 장치가 할당된 NUMA 노드의 ID와 같은 세부 정보를 함께 제공한다. 또한, NUMA 기반 머신의 경우, 컨테이너를 위해 예약된 메모리와 hugepage에 대한 정보를 포함한다.
```gRPC
// ListPodResourcesResponse는 List 함수가 반환하는 응답이다
// ListPodResourcesResponse는 List 함수가 반환하는 응답이다.
message ListPodResourcesResponse {
repeated PodResources pod_resources = 1;
}
// PodResources에는 파드에 할당된 노드 리소스에 대한 정보가 포함된다
// PodResources에는 파드에 할당된 노드 리소스에 대한 정보가 포함된다.
message PodResources {
string name = 1;
string namespace = 2;
repeated ContainerResources containers = 3;
}
// ContainerResources는 컨테이너에 할당된 리소스에 대한 정보를 포함한다
// ContainerResources는 컨테이너에 할당된 리소스에 대한 정보를 포함한다.
message ContainerResources {
string name = 1;
repeated ContainerDevices devices = 2;
repeated int64 cpu_ids = 3;
repeated ContainerMemory memory = 4;
}
// 토폴로지는 리소스의 하드웨어 토폴로지를 설명한다
// ContainerMemory는 컨테이너에 할당된 메모리와 hugepage에 대한 정보를 포함한다.
message ContainerMemory {
string memory_type = 1;
uint64 size = 2;
TopologyInfo topology = 3;
}
// 토폴로지는 리소스의 하드웨어 토폴로지를 설명한다.
message TopologyInfo {
repeated NUMANode nodes = 1;
}
@@ -231,7 +239,7 @@ message NUMANode {
int64 ID = 1;
}
// ContainerDevices는 컨테이너에 할당된 장치에 대한 정보를 포함한다
// ContainerDevices는 컨테이너에 할당된 장치에 대한 정보를 포함한다.
message ContainerDevices {
string resource_name = 1;
repeated string device_ids = 2;
@@ -247,6 +255,7 @@ kubelet이 APIServer로 내보내는 것보다 더 많은 정보를 제공한다
message AllocatableResourcesResponse {
repeated ContainerDevices devices = 1;
repeated int64 cpu_ids = 2;
repeated ContainerMemory memory = 3;
}
```
content/ko/docs/concepts/overview/what-is-kubernetes.md
+1 -1
View File
@@ -45,7 +45,7 @@ sitemap:
* 기민한 애플리케이션 생성과 배포: VM 이미지를 사용하는 것에 비해 컨테이너 이미지 생성이 보다 쉽고 효율적임.
* 지속적인 개발, 통합 및 배포: 안정적이고 주기적으로 컨테이너 이미지를 빌드해서 배포할 수 있고 (이미지의 불변성 덕에) 빠르고 효율적으로 롤백할 수 있다.
* 개발과 운영의 관심사 분리: 배포 시점이 아닌 빌드/릴리스 시점에 애플리케이션 컨테이너 이미지를 만들기 때문에, 애플리케이션이 인프라스트럭처에서 분리된다.
* 가시성은 OS 수준의 정보와 메트릭에 머무르지 않고, 애플리케이션의 헬스와 그 밖의 시그널을 볼 수 있다.
* 가시성(observability): OS 수준의 정보와 메트릭에 머무르지 않고, 애플리케이션의 헬스와 그 밖의 시그널을 볼 수 있다.
* 개발, 테스팅 및 운영 환경에 걸친 일관성: 랩탑에서도 클라우드에서와 동일하게 구동된다.
* 클라우드 및 OS 배포판 간 이식성: Ubuntu, RHEL, CoreOS, 온-프레미스, 주요 퍼블릭 클라우드와 어디에서든 구동된다.
* 애플리케이션 중심 관리: 가상 하드웨어 상에서 OS를 실행하는 수준에서 논리적인 리소스를 사용하는 OS 상에서 애플리케이션을 실행하는 수준으로 추상화 수준이 높아진다.
content/ko/docs/concepts/overview/working-with-objects/annotations.md
+5
View File
@@ -30,6 +30,11 @@ weight: 50
}
```
{{<note>}}
맵의 키와 값은 문자열이어야 한다. 다르게 말해서, 숫자,
불리언(boolean), 리스트 등의 다른 형식을 키나 값에 사용할 수 없다.
{{</note>}}
다음은 어노테이션에 기록할 수 있는 정보의 예제이다.
* 필드는 선언적 구성 계층에 의해 관리된다. 이러한 필드를 어노테이션으로 첨부하는 것은
content/ko/docs/concepts/overview/working-with-objects/labels.md
+2 -4
View File
@@ -42,7 +42,7 @@ _레이블_ 은 파드와 같은 오브젝트에 첨부된 키와 값의 쌍이
* `"partition" : "customerA"`, `"partition" : "customerB"`
* `"track" : "daily"`, `"track" : "weekly"`
이 예시는 일반적으로 사용하는 레이블이며, 사용자는 자신만의 규칙(convention)에 따라 자유롭게 개발할 수 있다. 오브젝트에 붙여진 레이블 키는 고유해야 한다는 것을 기억해야 한다.
이 예시는 [일반적으로 사용하는 레이블](/ko/docs/concepts/overview/working-with-objects/common-labels/)이며, 사용자는 자신만의 규칙(convention)에 따라 자유롭게 개발할 수 있다. 오브젝트에 붙여진 레이블 키는 고유해야 한다는 것을 기억해야 한다.
## 구문과 캐릭터 셋
@@ -50,15 +50,13 @@ _레이블_ 은 키와 값의 쌍이다. 유효한 레이블 키에는 슬래시
접두사를 생략하면 키 레이블은 개인용으로 간주한다. 최종 사용자의 오브젝트에 자동화된 시스템 컴포넌트(예: `kube-scheduler`, `kube-controller-manager`, `kube-apiserver`, `kubectl` 또는 다른 타사의 자동화 구성 요소)의 접두사를 지정해야 한다.
`kubernetes.io/`와 `k8s.io/` 접두사는 쿠버네티스의 핵심 컴포넌트로 예약되어있다.
`kubernetes.io/`와 `k8s.io/` 접두사는 쿠버네티스의 핵심 컴포넌트로 [예약](/ko/docs/reference/labels-annotations-taints/)되어있다.
유효한 레이블 값은 다음과 같다.
* 63 자 이하여야 하고 (공백일 수도 있음),
* (공백이 아니라면) 시작과 끝은 알파벳과 숫자(`[a-z0-9A-Z]`)이며,
* 알파벳과 숫자, 대시(`-`), 밑줄(`_`), 점(`.`)을 중간에 포함할 수 있다.
유효한 레이블 값은 63자 미만 또는 공백이며 시작과 끝은 알파벳과 숫자(`[a-z0-9A-Z]`)이며, 대시(`-`), 밑줄(`_`), 점(`.`)과 함께 사용할 수 있다.
다음의 예시는 파드에 `environment: production` 과 `app: nginx` 2개의 레이블이 있는 구성 파일이다.
```yaml
content/ko/docs/concepts/overview/working-with-objects/names.md
+16 -2
View File
@@ -1,4 +1,7 @@
---
title: 오브젝트 이름과 ID
content_type: concept
weight: 20
@@ -25,7 +28,7 @@ weight: 20
물리적 호스트를 나타내는 노드와 같이 오브젝트가 물리적 엔티티를 나타내는 경우, 노드를 삭제한 후 다시 생성하지 않은 채 동일한 이름으로 호스트를 다시 생성하면, 쿠버네티스는 새 호스트를 불일치로 이어질 수 있는 이전 호스트로 취급한다.
{{< /note >}}
다음은 리소스에 일반적으로 사용되는 세 가지 유형의 이름 제한 조건이다.
다음은 리소스에 일반적으로 사용되는 네 가지 유형의 이름 제한 조건이다.
### DNS 서브도메인 이름
@@ -38,7 +41,7 @@ DNS 서브도메인 이름으로 사용할 수 있는 이름이 필요하다.
- 영숫자로 시작한다.
- 영숫자로 끝난다.
### DNS 레이블 이름
### RFC 1123 레이블 이름 {#dns-label-names}
일부 리소스 유형은 [RFC 1123](https://tools.ietf.org/html/rfc1123)에
정의된 대로 DNS 레이블 표준을 따라야 한다.
@@ -49,6 +52,17 @@ DNS 서브도메인 이름으로 사용할 수 있는 이름이 필요하다.
- 영숫자로 시작한다.
- 영숫자로 끝난다.
### RFC 1035 레이블 이름
몇몇 리소스 타입은 자신의 이름을 [RFC 1035](https://tools.ietf.org/html/rfc1035)에
정의된 DNS 레이블 표준을 따르도록 요구한다.
이것은 이름이 다음을 만족해야 한다는 의미이다.
- 최대 63개 문자를 포함
- 소문자 영숫자 또는 '-'만 포함
- 알파벳 문자로 시작
- 영숫자로 끝남
### 경로 세그먼트 이름
일부 리소스 유형에서는 이름을 경로 세그먼트로 안전하게 인코딩 할 수
content/ko/docs/concepts/policy/resource-quotas.md
+3 -3
View File
@@ -442,7 +442,7 @@ pods 0 10
### 네임스페이스 간 파드 어피니티 쿼터
{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
{{< feature-state for_k8s_version="v1.22" state="beta" >}}
오퍼레이터는 네임스페이스를 교차하는 어피니티가 있는 파드를 가질 수 있는 네임스페이스를
제한하기 위해 `CrossNamespacePodAffinity` 쿼터 범위를 사용할 수 있다. 특히, 파드 어피니티 용어의
@@ -493,9 +493,9 @@ plugins:
해당 필드를 사용하는 파드 수보다 크거나 같은 하드 제한이 있는 경우에만
파드 어피니티에서 `namespaces` 및 `namespaceSelector` 를 사용할 수 있다.
이 기능은 알파이며 기본적으로 비활성화되어 있다. kube-apiserver 및 kube-scheduler 모두에서
이 기능은 베타이며 기본으로 활성화되어 있다. kube-apiserver 및 kube-scheduler 모두에서
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)
`PodAffinityNamespaceSelector` 를 설정하여 활성화할 수 있다.
`PodAffinityNamespaceSelector` 를 사용하여 비활성화할 수 있다.
## 요청과 제한의 비교 {#requests-vs-limits}
content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md
+3 -3
View File
@@ -271,16 +271,16 @@ PodSpec에 지정된 NodeAffinity도 적용된다.
연관된 `matchExpressions` 가 모두 충족되어야 한다.
#### 네임스페이스 셀렉터
{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
{{< feature-state for_k8s_version="v1.22" state="beta" >}}
사용자는 네임스페이스 집합에 대한 레이블 쿼리인 `namespaceSelector` 를 사용하여 일치하는 네임스페이스를 선택할 수도 있다.
어피니티 용어는 `namespaceSelector` 에서 선택한 네임스페이스와 `namespaces` 필드에 나열된 네임스페이스의 결합에 적용된다.
빈 `namespaceSelector` ({})는 모든 네임스페이스와 일치하는 반면, null 또는 빈 `namespaces` 목록과
null `namespaceSelector` 는 "이 파드의 네임스페이스"를 의미한다.
이 기능은 알파이며 기본적으로 비활성화되어 있다. kube-apiserver 및 kube-scheduler 모두에서
이 기능은 베타이며 기본으로 활성화되어 있다. kube-apiserver 및 kube-scheduler 모두에서
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)
`PodAffinityNamespaceSelector` 를 설정하여 활성화할 수 있다.
`PodAffinityNamespaceSelector` 를 사용하여 비활성화할 수 있다.
#### 더 실용적인 유스케이스
content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md
+1 -1
View File
@@ -85,7 +85,7 @@ _스코어링_ 단계에서 스케줄러는 목록에 남아있는 노드의 순
* [스케줄러 성능 튜닝](/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning/)에 대해 읽기
* [파드 토폴로지 분배 제약 조건](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/)에 대해 읽기
* kube-scheduler의 [레퍼런스 문서](/docs/reference/command-line-tools-reference/kube-scheduler/) 읽기
* [kube-scheduler 구성(v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/) 레퍼런스 읽기
* [kube-scheduler 구성(v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2/) 레퍼런스 읽기
* [멀티 스케줄러 구성하기](/docs/tasks/extend-kubernetes/configure-multiple-schedulers/)에 대해 배우기
* [토폴로지 관리 정책](/docs/tasks/administer-cluster/topology-manager/)에 대해 배우기
* [파드 오버헤드](/ko/docs/concepts/scheduling-eviction/pod-overhead/)에 대해 배우기
content/ko/docs/concepts/scheduling-eviction/pod-priority-preemption.md
+17 -10
View File
@@ -1,4 +1,7 @@
---
title: 파드 우선순위(priority)와 선점(preemption)
content_type: concept
weight: 70
@@ -350,21 +353,25 @@ spec:
`PodDisruptionBudget` 으로 보호되는 경우에만, 우선순위가 가장 낮은 파드를
축출 대상으로 고려한다.
QoS와 파드 우선순위를 모두 고려하는 유일한 컴포넌트는
[kubelet 리소스 부족 축출](/docs/concepts/scheduling-eviction/node-pressure-eviction/)이다.
kubelet은 부족한 리소스의 사용이 요청을 초과하는지 여부에 따라, 그런 다음 우선순위에 따라,
파드의 스케줄링 요청에 대한 부족한 컴퓨팅 리소스의 소비에 의해
먼저 축출 대상 파드의 순위를 매긴다.
더 자세한 내용은
[엔드유저 파드 축출](/docs/concepts/scheduling-eviction/node-pressure-eviction/#evicting-end-user-pods)을
kubelet은 우선순위를 사용하여 파드의 [노드-압박(node-pressure) 축출](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/) 순서를 결정한다.
사용자는 QoS 클래스를 사용하여 어떤 파드가 축출될 것인지
예상할 수 있다. kubelet은 다음의 요소들을 통해서 파드의 축출 순위를 매긴다.
1. 부족한 리소스 사용량이 요청을 초과하는지 여부
1. 파드 우선순위
1. 요청 대비 리소스 사용량
더 자세한 내용은 [kubelet 축출에서 파드 선택](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/#kubelet-축출을-위한-파드-선택)을
참조한다.
kubelet 리소스 부족 축출은 사용량이 요청을 초과하지 않는 경우
kubelet 노드-압박 축출은 사용량이 요청을 초과하지 않는 경우
파드를 축출하지 않는다. 우선순위가 낮은 파드가 요청을
초과하지 않으면, 축출되지 않는다. 요청을 초과하는 우선순위가
더 높은 다른 파드가 축출될 수 있다.
## {{% heading "whatsnext" %}}
* 프라이어리티클래스와 관련하여 리소스쿼터 사용에 대해 [기본적으로 프라이어리티클래스 소비 제한](/ko/docs/concepts/policy/resource-quotas/#기본적으로-우선-순위-클래스-소비-제한)을 읽어보자.
* 프라이어리티클래스와 함께 리소스쿼터 사용에 대해 읽기: [기본으로 프라이어리티 클래스 소비 제한](/ko/docs/concepts/policy/resource-quotas/#기본적으로-우선-순위-클래스-소비-제한)
* [파드 중단(disruption)](/ko/docs/concepts/workloads/pods/disruptions/)에 대해 학습한다.
* [API를 이용한 축출](/ko/docs/concepts/scheduling-eviction/api-eviction/)에 대해 학습한다.
* [노드-압박(node-pressure) 축출](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/)에 대해 학습한다.
content/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md
+2 -2
View File
@@ -43,7 +43,7 @@ kube-scheduler 의 `percentageOfNodesToScore` 설정을 통해
마치 100을 설정한 것처럼 작동한다.
값을 변경하려면,
[kube-scheduler 구성 파일](/docs/reference/config-api/kube-scheduler-config.v1beta1/)을
[kube-scheduler 구성 파일](/docs/reference/config-api/kube-scheduler-config.v1beta2/)을
편집한 다음 스케줄러를 재시작한다.
대부분의 경우, 구성 파일은 `/etc/kubernetes/config/kube-scheduler.yaml` 에서 찾을 수 있다.
@@ -161,4 +161,4 @@ percentageOfNodesToScore: 50
## {{% heading "whatsnext" %}}
* [kube-scheduler 구성 레퍼런스(v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/) 확인
* [kube-scheduler 구성 레퍼런스(v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2/) 확인
content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md
+3 -3
View File
@@ -264,10 +264,10 @@ tolerations:
이렇게 하면 이러한 문제로 인해 데몬셋 파드가 축출되지 않는다.
## 컨디션을 기준으로 노드 테인트하기
## 조건(condition)을 기준으로 노드 테인트하기
컨트롤 플레인은 노드 {{<glossary_tooltip text="컨트롤러" term_id="controller">}}를 이용하여
[노드 조건](/docs/concepts/scheduling-eviction/node-pressure-eviction/)에 대한 `NoSchedule` 효과를 사용하여 자동으로 테인트를 생성한다.
[노드 조건](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/#node-conditions)에 대한 `NoSchedule` 효과를 사용하여 자동으로 테인트를 생성한다.
스케줄러는 스케줄링 결정을 내릴 때 노드 조건을 확인하는 것이 아니라 테인트를 확인한다.
이렇게 하면 노드 조건이 스케줄링에 직접적인 영향을 주지 않는다.
@@ -298,5 +298,5 @@ tolerations:
## {{% heading "whatsnext" %}}
* [리소스 부족 다루기](/docs/concepts/scheduling-eviction/node-pressure-eviction/)와 어떻게 구성하는지에 대해 알아보기
* [노드-압박(node-pressure) 축출](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/)과 어떻게 구성하는지에 대해 알아보기
* [파드 우선순위](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/)에 대해 알아보기
content/ko/docs/concepts/security/overview.md
+6 -3
View File
@@ -1,17 +1,21 @@
---
title: 클라우드 네이티브 보안 개요
description: >
클라우드 네이티브 보안 관점에서 쿠버네티스 보안을 생각해보기 위한 모델
content_type: concept
weight: 10
weight: 1
---
<!-- overview -->
이 개요는 클라우드 네이티브 보안의 맥락에서 쿠버네티스 보안에 대한 생각의 모델을 정의한다.
{{< warning >}}
이 컨테이너 보안 모델은 입증된 정보 보안 정책이 아닌 제안 사항을 제공한다.
{{< /warning >}}
<!-- body -->
## 클라우드 네이티브 보안의 4C
@@ -83,7 +87,6 @@ etcd 암호화 | 가능한 한 모든 드라이브를 암호화하는 것이 좋
* 설정 가능한 클러스터 컴포넌트의 보안
* 클러스터에서 실행되는 애플리케이션의 보안
### 클러스터의 컴포넌트 {#cluster-components}
우발적이거나 악의적인 접근으로부터 클러스터를 보호하고,
content/ko/docs/concepts/services-networking/connect-applications-service.md
+3 -3
View File
@@ -129,7 +129,7 @@ curl을 할 수 있을 것이다. 서비스 IP는 완전히 가상이므로 외
쿠버네티스는 서비스를 찾는 두 가지 기본 모드인 환경 변수와 DNS를
지원한다. 전자는 기본적으로 작동하지만 후자는
[CoreDNS 클러스터 애드온](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/coredns)이 필요하다.
[CoreDNS 클러스터 애드온](https://releases.k8s.io/master/cluster/addons/dns/coredns)이 필요하다.
{{< note >}}
만약 서비스 환경 변수가 필요하지 않은 경우(소유한 프로그램과의 예상되는 충돌 가능성,
처리할 변수가 너무 많은 경우, DNS만 사용하는 경우 등) [파드 사양](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)에서
@@ -227,7 +227,7 @@ Address 1: 10.0.162.149
* 인증서를 사용하도록 구성된 nginx 서버
* 파드에 접근할 수 있는 인증서를 만드는 [시크릿](/ko/docs/concepts/configuration/secret/)
[nginx https 예제](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/https-nginx/)에서 이 모든 것을 얻을 수 있다. 이를 위해서는 도구를 설치해야 한다. 만약 설치하지 않으려면 나중에 수동으로 단계를 수행한다. 한마디로:
[nginx https 예제](https://github.com/kubernetes/examples/tree/master/staging/https-nginx/)에서 이 모든 것을 얻을 수 있다. 이를 위해서는 도구를 설치해야 한다. 만약 설치하지 않으려면 나중에 수동으로 단계를 수행한다. 한마디로:
```shell
make keys KEY=/tmp/nginx.key CERT=/tmp/nginx.crt
@@ -299,7 +299,7 @@ nginxsecret kubernetes.io/tls 2 1m
nginx-secure-app의 매니페스트에 대한 주목할만한 점:
- 이것은 동일한 파일에 디플로이먼트와 서비스의 사양을 모두 포함하고 있다.
- [nginx 서버](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/https-nginx/default.conf)
- [nginx 서버](https://github.com/kubernetes/examples/tree/master/staging/https-nginx/default.conf)
는 포트 80에서 HTTP 트래픽을 443에서 HTTPS 트래픽 서비스를 제공하고, nginx 서비스는
두 포트를 모두 노출한다.
- 각 컨테이너는 `/etc/nginx/ssl` 에 마운트된 볼륨을 통해 키에 접근할 수 있다.
content/ko/docs/concepts/services-networking/dns-pod-service.md
+23 -1
View File
@@ -197,7 +197,7 @@ A 또는 AAAA 레코드만 생성할 수 있다. (`default-subdomain.my-namespac
### 파드의 setHostnameAsFQDN 필드 {#pod-sethostnameasfqdn-field}
{{< feature-state for_k8s_version="v1.20" state="beta" >}}
{{< 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을 반환한다.
@@ -313,6 +313,28 @@ search default.svc.cluster-domain.example svc.cluster-domain.example cluster-dom
options ndots:5
```
#### 확장된 DNS 환경 설정
{{< feature-state for_k8s_version="1.22" state="alpha" >}}
쿠버네티스는 파드의 DNS 환경 설정을 위해 기본적으로 최대 6개의 탐색 도메인과
최대 256자의 탐색 도메인 목록을 허용한다.
kube-apiserver와 kubelet에 `ExpandedDNSConfig` 기능 게이트가 활성화되어 있으면,
쿠버네티스는 최대 32개의 탐색 도메인과
최대 2048자의 탐색 도메인 목록을 허용한다.
### 기능 가용성
파드 DNS 환경 설정 기능과 DNS 정책 "`None`" 기능의 쿠버네티스 버전별 가용성은 다음과 같다.
| 쿠버네티스 버전 | 기능 지원 |
| :---------: |:-----------:|
| 1.14 | 안정 |
| 1.10 | 베타 (기본값으로 켜져 있음)|
| 1.9 | 알파 |
## {{% heading "whatsnext" %}}
content/ko/docs/concepts/services-networking/ingress-controllers.md
+1
View File
@@ -32,6 +32,7 @@ weight: 40
Citrix 애플리케이션 딜리버리 컨트롤러에서 작동한다.
* [Contour](https://projectcontour.io/)는 [Envoy](https://www.envoyproxy.io/) 기반 인그레스 컨트롤러다.
* [EnRoute](https://getenroute.io/)는 인그레스 컨트롤러로 실행할 수 있는 [Envoy](https://www.envoyproxy.io) 기반 API 게이트웨이다.
* [Easegress IngressController](https://github.com/megaease/easegress/blob/main/doc/ingresscontroller.md)는 인그레스 컨트롤러로 실행할 수 있는 [Easegress](https://megaease.com/easegress/) 기반 API 게이트웨이다.
* F5 BIG-IP [쿠버네티스 용 컨테이너 인그레스 서비스](https://clouddocs.f5.com/containers/latest/userguide/kubernetes/)를
이용하면 인그레스를 사용하여 F5 BIG-IP 가상 서버를 구성할 수 있다.
* [Gloo](https://gloo.solo.io)는 API 게이트웨이 기능을 제공하는 [Envoy](https://www.envoyproxy.io) 기반의
content/ko/docs/concepts/services-networking/ingress.md
+3 -1
View File
@@ -1,4 +1,6 @@
---
title: 인그레스(Ingress)
content_type: concept
weight: 40
@@ -222,7 +224,7 @@ IngressClass 리소스에는 선택적인 파라미터 필드가 있다. 이 클
#### 네임스페이스 범위의 파라미터
{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
{{< feature-state for_k8s_version="v1.22" state="beta" >}}
`Parameters` 필드에는 인그레스 클래스 구성을 위해 네임스페이스 별 리소스를 참조하는 데
사용할 수 있는 `scope` 및 `namespace` 필드가 있다.
content/ko/docs/concepts/services-networking/network-policies.md
+13 -5
View File
@@ -223,7 +223,7 @@ SCTP 프로토콜 네트워크폴리시를 지원하는 {{< glossary_tooltip tex
## 포트 범위 지정
{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
{{< feature-state for_k8s_version="v1.22" state="beta" >}}
네트워크폴리시를 작성할 때, 단일 포트 대신 포트 범위를 대상으로 지정할 수 있다.
@@ -251,17 +251,25 @@ spec:
endPort: 32768
```
위 규칙은 대상 포트가 32000에서 32768 사이에 있는 경우, 네임스페이스 `default` 에 레이블이 `db` 인 모든 파드가 TCP를 통해 `10.0.0.0/24` 범위 내의 모든 IP와 통신하도록 허용한다.
위 규칙은 대상 포트가 32000에서 32768 사이에 있는 경우,
네임스페이스 `default` 에 레이블이 `db` 인 모든 파드가
TCP를 통해 `10.0.0.0/24` 범위 내의 모든 IP와 통신하도록 허용한다.
이 필드를 사용할 때 다음의 제한 사항이 적용된다.
* 알파 기능으로, 기본적으로 비활성화되어 있다. 클러스터 수준에서 `endPort` 필드를 활성화하려면, 사용자(또는 클러스터 관리자)가 `--feature-gates=NetworkPolicyEndPort=true,…` 가 있는 API 서버에 대해 `NetworkPolicyEndPort` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다.
* 베타 기능으로, 기본적으로 활성화되어 있다.
클러스터 수준에서 `endPort` 필드를 비활성화하려면, 사용자(또는 클러스터 관리자)가
API 서버에 대해 `--feature-gates=NetworkPolicyEndPort=false,…` 명령을 이용하여
`NetworkPolicyEndPort` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 비활성화해야 한다.
* `endPort` 필드는 `port` 필드보다 크거나 같아야 한다.
* `endPort` 는 `port` 도 정의된 경우에만 정의할 수 있다.
* 두 포트 모두 숫자여야 한다.
{{< note >}}
클러스터는 {{< glossary_tooltip text="CNI" term_id="cni" >}} 플러그인을 사용해야 한다.
네트워크폴리시 명세에서 `endPort` 필드를 지원한다.
클러스터가 네트워크폴리시 명세의 `endPort` 필드를 지원하는
{{< glossary_tooltip text="CNI" term_id="cni" >}} 플러그인을 사용해야 한다.
만약 [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)이
`endPort` 필드를 지원하지 않는데 네트워크폴리시의 해당 필드에 명시를 하면,
그 정책은 `port` 필드에만 적용될 것이다.
{{< /note >}}
## 이름으로 네임스페이스 지정
content/ko/docs/concepts/services-networking/service.md
+46 -11
View File
@@ -72,7 +72,7 @@ _서비스_ 로 들어가보자.
마찬가지로, 서비스 정의를 API 서버에 `POST`하여
새 인스턴스를 생성할 수 있다.
서비스 오브젝트의 이름은 유효한
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
[RFC 1035 레이블 이름](/ko/docs/concepts/overview/working-with-objects/names/#rfc-1035-label-names)이어야 한다.
예를 들어, 각각 TCP 포트 9376에서 수신하고
`app=MyApp` 레이블을 가지고 있는 파드 세트가 있다고 가정해 보자.
@@ -188,9 +188,10 @@ DNS명을 대신 사용하는 특수한 상황의 서비스이다. 자세한 내
이 문서 뒷부분의 [ExternalName](#externalname) 섹션을 참조한다.
### 초과 용량 엔드포인트
엔드포인트 리소스에 1,000개가 넘는 엔드포인트가 있는 경우 쿠버네티스 v1.21(또는 그 이상)
클러스터는 해당 엔드포인트에 `endpoints.kubernetes.io/over-capacity: warning` 어노테이션을 추가한다.
이 어노테이션은 영향을 받는 엔드포인트 오브젝트가 용량을 초과했음을 나타낸다.
엔드포인트 리소스에 1,000개가 넘는 엔드포인트가 있는 경우 쿠버네티스 v1.22(또는 그 이상)
클러스터는 해당 엔드포인트에 `endpoints.kubernetes.io/over-capacity: truncated` 어노테이션을 추가한다.
이 어노테이션은 영향을 받는 엔드포인트 오브젝트가 용량을 초과했으며
엔드포인트 컨트롤러가 엔드포인트의 수를 1000으로 줄였음을 나타낸다.
### 엔드포인트슬라이스
@@ -384,6 +385,40 @@ 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는 트래픽을 포워드하지 않는다.
## 서비스 디스커버리하기
쿠버네티스는 서비스를 찾는 두 가지 기본 모드를 지원한다. - 환경
@@ -394,7 +429,7 @@ CIDR 범위 내의 유효한 IPv4 또는 IPv6 주소여야 한다.
파드가 노드에서 실행될 때, kubelet은 각 활성화된 서비스에 대해
환경 변수 세트를 추가한다. [도커 링크
호환](https://docs.docker.com/userguide/dockerlinks/) 변수
([makeLinkVariables](https://releases.k8s.io/{{< param "githubbranch" >}}/pkg/kubelet/envvars/envvars.go#L49) 참조)와
([makeLinkVariables](https://releases.k8s.io/master/pkg/kubelet/envvars/envvars.go#L49) 참조)와
보다 간단한 `{SVCNAME}_SERVICE_HOST` 및 `{SVCNAME}_SERVICE_PORT` 변수를 지원하고,
이때 서비스 이름은 대문자이고 대시는 밑줄로 변환된다.
@@ -523,6 +558,7 @@ API에서 `엔드포인트` 레코드를 생성하고, DNS 구성을 수정하
[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에 대해 사용 가능한 모든 네트워크 인터페이스를 고려해야 한다는 것을 의미한다. (이는 이전 쿠버네티스 릴리스와도 호환된다).
@@ -641,12 +677,12 @@ v1.20부터는 `spec.allocateLoadBalancerNodePorts` 필드를 `false`로 설정
#### 로드 밸런서 구현 클래스 지정 {#load-balancer-class}
{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
{{< feature-state for_k8s_version="v1.22" state="beta" >}}
v1.21부터는, `spec.loadBalancerClass` 필드를 설정하여 `LoadBalancer` 서비스 유형에
대한 로드 밸런서 구현 클래스를 선택적으로 지정할 수 있다.
기본적으로, `spec.loadBalancerClass` 는 `nil` 이고 `LoadBalancer` 유형의 서비스는
클라우드 공급자의 기본 로드 밸런서 구현을 사용한다.
`spec.loadBalancerClass` 필드를 설정하여 클라우드 제공자가 설정한 기본값 이외의 로드 밸런서 구현을 사용할 수 있다. 이 기능은 v1.21부터 사용할 수 있으며, v1.21에서는 이 필드를 사용하기 위해 `ServiceLoadBalancerClass` 기능 게이트를 활성화해야 하지만, v1.22부터는 해당 기능 게이트가 기본적으로 활성화되어 있다.
기본적으로, `spec.loadBalancerClass` 는 `nil` 이고,
클러스터가 클라우드 제공자의 로드밸런서를 이용하도록 `--cloud-provider` 컴포넌트 플래그를 이용하여 설정되어 있으면
`LoadBalancer` 유형의 서비스는 클라우드 공급자의 기본 로드 밸런서 구현을 사용한다.
`spec.loadBalancerClass` 가 지정되면, 지정된 클래스와 일치하는 로드 밸런서
구현이 서비스를 감시하고 있다고 가정한다.
모든 기본 로드 밸런서 구현(예: 클라우드 공급자가 제공하는
@@ -656,7 +692,6 @@ v1.21부터는, `spec.loadBalancerClass` 필드를 설정하여 `LoadBalancer`
`spec.loadBalancerClass` 의 값은 "`internal-vip`" 또는
"`example.com/internal-vip`" 와 같은 선택적 접두사가 있는 레이블 스타일 식별자여야 한다.
접두사가 없는 이름은 최종 사용자를 위해 예약되어 있다.
이 필드를 사용하려면 `ServiceLoadBalancerClass` 기능 게이트를 활성화해야 한다.
#### 내부 로드 밸런서
content/ko/docs/concepts/storage/persistent-volumes.md
+118 -32
View File
@@ -314,12 +314,9 @@ EBS 볼륨 확장은 시간이 많이 걸리는 작업이다. 또한 6시간마
* [`azureDisk`](/ko/docs/concepts/storage/volumes/#azuredisk) - Azure Disk
* [`azureFile`](/ko/docs/concepts/storage/volumes/#azurefile) - Azure File
* [`cephfs`](/ko/docs/concepts/storage/volumes/#cephfs) - CephFS 볼륨
* [`cinder`](/ko/docs/concepts/storage/volumes/#cinder) - Cinder (오픈스택 블록 스토리지)
(**사용 중단**)
* [`csi`](/ko/docs/concepts/storage/volumes/#csi) - 컨테이너 스토리지 인터페이스 (CSI)
* [`fc`](/ko/docs/concepts/storage/volumes/#fc) - Fibre Channel (FC) 스토리지
* [`flexVolume`](/ko/docs/concepts/storage/volumes/#flexVolume) - FlexVolume
* [`flocker`](/ko/docs/concepts/storage/volumes/#flocker) - Flocker 스토리지
* [`gcePersistentDisk`](/ko/docs/concepts/storage/volumes/#gcepersistentdisk) - GCE Persistent Disk
* [`glusterfs`](/ko/docs/concepts/storage/volumes/#glusterfs) - Glusterfs 볼륨
* [`hostPath`](/ko/docs/concepts/storage/volumes/#hostpath) - HostPath 볼륨
@@ -329,17 +326,28 @@ EBS 볼륨 확장은 시간이 많이 걸리는 작업이다. 또한 6시간마
* [`local`](/ko/docs/concepts/storage/volumes/#local) - 노드에 마운트된
로컬 스토리지 디바이스
* [`nfs`](/ko/docs/concepts/storage/volumes/#nfs) - 네트워크 파일 시스템 (NFS) 스토리지
* `photonPersistentDisk` - Photon 컨트롤러 퍼시스턴트 디스크.
(이 볼륨 유형은 해당 클라우드 공급자가 없어진 이후 더 이상
작동하지 않는다.)
* [`portworxVolume`](/ko/docs/concepts/storage/volumes/#portworxvolume) - Portworx 볼륨
* [`quobyte`](/ko/docs/concepts/storage/volumes/#quobyte) - Quobyte 볼륨
* [`rbd`](/ko/docs/concepts/storage/volumes/#rbd) - Rados Block Device (RBD) 볼륨
* [`scaleIO`](/ko/docs/concepts/storage/volumes/#scaleio) - ScaleIO 볼륨
(**사용 중단**)
* [`storageos`](/ko/docs/concepts/storage/volumes/#storageos) - StorageOS 볼륨
* [`vsphereVolume`](/ko/docs/concepts/storage/volumes/#vspherevolume) - vSphere VMDK 볼륨
아래의 PersistentVolume 타입은 사용 중단되었다. 이 말인 즉슨, 지원은 여전히 제공되지만 추후 쿠버네티스 릴리스에서는 삭제될 예정이라는 것이다.
* [`cinder`](/ko/docs/concepts/storage/volumes/#cinder) - Cinder (오픈스택 블록 스토리지)
(v1.18에서 **사용 중단**)
* [`flocker`](/ko/docs/concepts/storage/volumes/#flocker) - Flocker 스토리지
(v1.22에서 **사용 중단**)
* [`quobyte`](/ko/docs/concepts/storage/volumes/#quobyte) - Quobyte 볼륨
(v1.22에서 **사용 중단**)
* [`storageos`](/ko/docs/concepts/storage/volumes/#storageos) - StorageOS 볼륨
(v1.22에서 **사용 중단**)
이전 쿠버네티스 버전은 아래의 인-트리 PersistentVolume 타입도 지원했었다.
* `photonPersistentDisk` - Photon 컨트롤러 퍼시스턴트 디스크.
(v1.15 이후 **사용 불가**)
* [`scaleIO`](/ko/docs/concepts/storage/volumes/#scaleio) - ScaleIO 볼륨
(v1.21 이후 **사용 불가**)
## 퍼시스턴트 볼륨
각 PV에는 스펙과 상태(볼륨의 명세와 상태)가 포함된다.
@@ -407,38 +415,40 @@ spec:
* ReadWriteOnce -- 하나의 노드에서 볼륨을 읽기-쓰기로 마운트할 수 있다
* ReadOnlyMany -- 여러 노드에서 볼륨을 읽기 전용으로 마운트할 수 있다
* ReadWriteMany -- 여러 노드에서 볼륨을 읽기-쓰기로 마운트할 수 있다
* ReadWriteOncePod -- 하나의 파드에서 볼륨을 읽기-쓰기로 마운트할 수 있다.
쿠버네티스 버전 1.22 이상인 경우에 CSI 볼륨에 대해서만 지원된다.
CLI에서 접근 모드는 다음과 같이 약어로 표시된다.
* RWO - ReadWriteOnce
* ROX - ReadOnlyMany
* RWX - ReadWriteMany
* RWOP - ReadWriteOncePod
> __중요!__ 볼륨이 여러 접근 모드를 지원하더라도 한 번에 하나의 접근 모드를 사용하여 마운트할 수 있다. 예를 들어 GCEPersistentDisk는 하나의 노드가 ReadWriteOnce로 마운트하거나 여러 노드가 ReadOnlyMany로 마운트할 수 있지만 동시에는 불가능하다.
| Volume Plugin | ReadWriteOnce | ReadOnlyMany | ReadWriteMany|
| :--- | :---: | :---: | :---: |
| AWSElasticBlockStore | &#x2713; | - | - |
| AzureFile | &#x2713; | &#x2713; | &#x2713; |
| AzureDisk | &#x2713; | - | - |
| CephFS | &#x2713; | &#x2713; | &#x2713; |
| Cinder | &#x2713; | - | - |
| CSI | 드라이버에 따라 다름 | 드라이버에 따라 다름 | 드라이버에 따라 다름 |
| FC | &#x2713; | &#x2713; | - |
| FlexVolume | &#x2713; | &#x2713; | 드라이버에 따라 다름 |
| Flocker | &#x2713; | - | - |
| GCEPersistentDisk | &#x2713; | &#x2713; | - |
| Glusterfs | &#x2713; | &#x2713; | &#x2713; |
| HostPath | &#x2713; | - | - |
| iSCSI | &#x2713; | &#x2713; | - |
| Quobyte | &#x2713; | &#x2713; | &#x2713; |
| NFS | &#x2713; | &#x2713; | &#x2713; |
| RBD | &#x2713; | &#x2713; | - |
| VsphereVolume | &#x2713; | - | - (파드가 병치될(collocated) 때 작동) |
| PortworxVolume | &#x2713; | - | &#x2713; |
| ScaleIO | &#x2713; | &#x2713; | - |
| StorageOS | &#x2713; | - | - |
| Volume Plugin | ReadWriteOnce | ReadOnlyMany | ReadWriteMany | ReadWriteOncePod |
| :--- | :---: | :---: | :---: | - |
| AWSElasticBlockStore | &#x2713; | - | - | - |
| AzureFile | &#x2713; | &#x2713; | &#x2713; | - |
| AzureDisk | &#x2713; | - | - | - |
| CephFS | &#x2713; | &#x2713; | &#x2713; | - |
| Cinder | &#x2713; | - | - | - |
| CSI | depends on the driver | depends on the driver | depends on the driver | depends on the driver |
| FC | &#x2713; | &#x2713; | - | - |
| FlexVolume | &#x2713; | &#x2713; | depends on the driver | - |
| Flocker | &#x2713; | - | - | - |
| GCEPersistentDisk | &#x2713; | &#x2713; | - | - |
| Glusterfs | &#x2713; | &#x2713; | &#x2713; | - |
| HostPath | &#x2713; | - | - | - |
| iSCSI | &#x2713; | &#x2713; | - | - |
| Quobyte | &#x2713; | &#x2713; | &#x2713; | - |
| NFS | &#x2713; | &#x2713; | &#x2713; | - |
| RBD | &#x2713; | &#x2713; | - | - |
| VsphereVolume | &#x2713; | - | - (works when Pods are collocated) | - |
| PortworxVolume | &#x2713; | - | &#x2713; | - | - |
| StorageOS | &#x2713; | - | - | - |
### 클래스
@@ -785,6 +795,82 @@ spec:
storage: 10Gi
```
## 볼륨 파퓰레이터(Volume populator)와 데이터 소스
{{< feature-state for_k8s_version="v1.22" state="alpha" >}}
{{< note >}}
쿠버네티스는 커스텀 볼륨 파퓰레이터를 지원한다.
이 알파 기능은 쿠버네티스 1.18에서 도입되었으며
1.22에서는 새로운 메카니즘과 리디자인된 API로 새롭게 구현되었다.
현재 사용 중인 클러스터의 버전에 맞는 쿠버네티스 문서를 읽고 있는지 다시 한번
확인한다. {{% version-check %}}
커스텀 볼륨 파퓰레이터를 사용하려면, kube-apiserver와 kube-controller-manager에 대해
`AnyVolumeDataSource` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다.
{{< /note >}}
볼륨 파퓰레이터는 `dataSourceRef`라는 PVC 스펙 필드를 활용한다.
다른 PersistentVolumeClaim 또는 VolumeSnapshot을 가리키는 참조만 명시할 수 있는
`dataSource` 필드와는 다르게, `dataSourceRef` 필드는 동일 네임스페이스에 있는
어떠한 오브젝트에 대한 참조도 명시할 수 있다(단, PVC 외의 다른 코어 오브젝트는 제외).
기능 게이트가 활성화된 클러스터에서는 `dataSource`보다 `dataSourceRef`를 사용하는 것을 권장한다.
## 데이터 소스 참조
`dataSourceRef` 필드는 `dataSource` 필드와 거의 동일하게 동작한다.
둘 중 하나만 명시되어 있으면, API 서버는 두 필드에 같은 값을 할당할 것이다.
두 필드 모두 생성 이후에는 변경될 수 없으며,
두 필드에 다른 값을 넣으려고 시도하면 검증 에러가 발생할 것이다.
따라서 두 필드는 항상 같은 값을 갖게 된다.
`dataSourceRef` 필드와 `dataSource` 필드 사이에는
사용자가 알고 있어야 할 두 가지 차이점이 있다.
* `dataSource` 필드는 유효하지 않은 값(예를 들면, 빈 값)을 무시하지만,
`dataSourceRef` 필드는 어떠한 값도 무시하지 않으며 유효하지 않은 값이 들어오면 에러를 발생할 것이다.
유효하지 않은 값은 PVC를 제외한 모든 코어 오브젝트(apiGroup이 없는 오브젝트)이다.
* `dataSourceRef` 필드는 여러 타입의 오브젝트를 포함할 수 있지만, `dataSource` 필드는
PVC와 VolumeSnapshot만 포함할 수 있다.
기능 게이트가 활성화된 클러스터에서는 `dataSourceRef`를 사용해야 하고, 그렇지 않은
클러스터에서는 `dataSource`를 사용해야 한다. 어떤 경우에서든 두 필드 모두를 확인해야
할 필요는 없다. 이렇게 약간의 차이만 있는 중복된 값은 이전 버전 호환성을 위해서만
존재하는 것이다. 상세히 설명하면, 이전 버전과 새로운 버전의 컨트롤러가 함께 동작할
수 있는데, 이는 두 필드가 동일하기 때문이다.
### 볼륨 파퓰레이터 사용하기
볼륨 파퓰레이터는 비어 있지 않은 볼륨(non-empty volume)을 생성할 수 있는 {{< glossary_tooltip text="컨트롤러" term_id="controller" >}}이며,
이 볼륨의 내용물은 커스텀 리소스(Custom Resource)에 의해 결정된다.
파퓰레이티드 볼륨(populated volume)을 생성하려면 `dataSourceRef` 필드에 커스텀 리소스를 기재한다.
```yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: populated-pvc
spec:
dataSourceRef:
name: example-name
kind: ExampleDataSource
apiGroup: example.storage.k8s.io
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 10Gi
```
볼륨 파퓰레이터는 외부 컴포넌트이기 때문에,
만약 적합한 컴포넌트가 설치되어 있지 않다면 볼륨 파퓰레이터를 사용하는 PVC에 대한 생성 요청이 실패할 수 있다.
외부 컨트롤러는 '컴포넌트가 없어서 PVC를 생성할 수 없음' 경고와 같은
PVC 생성 상태에 대한 피드백을 제공하기 위해, PVC에 대한 이벤트를 생성해야 한다.
알파 버전의 [볼륨 데이터 소스 검증기](https://github.com/kubernetes-csi/volume-data-source-validator)를
클러스터에 설치할 수 있다.
해당 데이터 소스를 다루는 파퓰레이터가 등록되어 있지 않다면 이 컨트롤러가 PVC에 경고 이벤트를 생성한다.
PVC를 위한 적절한 파퓰레이터가 설치되어 있다면,
볼륨 생성과 그 과정에서 발생하는 이슈에 대한 이벤트를 생성하는 것은 파퓰레이터 컨트롤러의 몫이다.
## 포터블 구성 작성
광범위한 클러스터에서 실행되고 퍼시스턴트 스토리지가 필요한
content/ko/docs/concepts/storage/storage-capacity.md
+117
View File
@@ -0,0 +1,117 @@
---
title: 스토리지 용량
content_type: concept
weight: 45
---
<!-- overview -->
스토리지 용량은 제한이 있으며, 파드가 실행되는 노드의 상황에 따라 달라질 수 있다.
예를 들어, 일부 노드에서 NAS(Network Attached Storage)에 접근할 수 없는 경우가 있을 수 있으며,
또는 각 노드에 종속적인 로컬 스토리지를 사용하는 경우일 수도 있다.
{{< feature-state for_k8s_version="v1.19" state="alpha" >}}
{{< feature-state for_k8s_version="v1.21" state="beta" >}}
이 페이지에서는 쿠버네티스가 어떻게 스토리지 용량을 추적하고
스케줄러가 남아 있는 볼륨을 제공하기 위해 스토리지 용량이 충분한 노드에
파드를 스케줄링하기 위해 이 정보를 어떻게 사용하는지 설명한다.
스토리지 용량을 추적하지 않으면, 스케줄러는
볼륨을 제공할 충분한 용량이 없는 노드를 선정할 수 있으며,
스케줄링을 여러 번 다시 시도해야 한다.
스토리지 용량 추적은 {{< glossary_tooltip
text="컨테이너 스토리지 인터페이스(CSI)" term_id="csi" >}} 드라이버에서 지원하며,
CSI 드라이버를 설치할 때 [사용하도록 설정](#스토리지-용량-추적-활성화)해야 한다.
<!-- body -->
## API
이 기능에는 다음 두 가지 API 확장이 있다.
- CSIStorageCapacity 오브젝트:
CSI 드라이버가 설치된 네임스페이스에
CSI 드라이버가 이 오브젝트를 생성한다. 각 오브젝트는
하나의 스토리지 클래스에 대한 용량 정보를 담고 있으며,
어떤 노드가 해당 스토리지에 접근할 수 있는지를 정의한다.
- [ `CSIDriverSpec.StorageCapacity` 필드](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#csidriverspec-v1-storage-k8s-io):
`true`로 설정하면, 쿠버네티스 스케줄러가
CSI 드라이버를 사용하는 볼륨의 스토리지 용량을 고려하게 된다.
## 스케줄링
다음과 같은 경우 쿠버네티스 스케줄러에서 스토리지 용량 정보를 사용한다.
- `CSIStorageCapacity` 기능 게이트(feature gate)가 true이고,
- 파드가 아직 생성되지 않은 볼륨을 사용하고,
- 해당 볼륨은 CSI 드라이버를 참조하고
`WaitForFirstConsumer`
[볼륨 바인딩 모드](/ko/docs/concepts/storage/storage-classes/#볼륨-바인딩-모드)를 사용하는
{{< glossary_tooltip text="스토리지클래스(StorageClass)" term_id="storage-class" >}}를 사용하고,
- 드라이버의 `CSIDriver` 오브젝트에 `StorageCapacity` 속성이
true로 설정되어 있다.
이 경우 스케줄러는 파드에 제공할
충분한 스토리지가 있는 노드만 고려한다.
이 검사는 아주 간단한데,
볼륨의 크기를 노드를 포함하는 토폴로지를 가진 `CSIStorageCapacity` 오브젝트에
나열된 용량과 비교한다.
볼륨 바인딩 모드가 `Immediate` 인 볼륨의 경우에는 스토리지 드라이버는
볼륨을 사용하는 파드와 관계없이 볼륨을 생성할 위치를 정한다.
볼륨을 생성한 후에, 스케줄러는
볼륨을 사용할 수 있는 노드에 파드를 스케줄링한다.
[CSI 임시 볼륨](/ko/docs/concepts/storage/volumes/#csi)의 경우에는
볼륨 유형이 로컬 볼륨이고
큰 자원이 필요하지 않은 특정 CSI 드라이버에서만 사용된다는 가정하에,
항상 스토리지 용량을 고려하지 않고
스케줄링한다.
## 리스케줄링
`WaitForFirstConsumer` 볼륨을 가진 파드에 대해
노드가 선정되었더라도 아직은 잠정적인 결정이다. 다음 단계에서
선정한 노드에서 볼륨을 사용할 수 있어야 한다는 힌트를 주고
CSI 스토리지 드라이버에 볼륨 생성을 요청한다
쿠버네티스는 시간이 지난 스토리지 용량 정보를 기반으로
노드를 선정할 수도 있으므로, 볼륨을 실제로 생성하지 않을 수도 있다.
그런 다음 노드 선정이 재설정되고 쿠버네티스 스케줄러가
파드를 위한 노드를 찾는 것을 재시도한다.
## 제한사항
스토리지 용량 추적은 첫 시도에 스케줄링이 성공할 가능성을 높이지만,
스케줄러가 시간이 지난 정보를 기반으로
결정해야 할 수도 있기 때문에 이를 보장하지는 않는다.
일반적으로 스토리지 용량 정보가 없는 스케줄링과
동일한 재시도 메커니즘으로 스케줄링 실패를 처리한다.
스케줄링이 영구적으로 실패할 수 있는 한 가지 상황은
파드가 여러 볼륨을 사용하는 경우이다.
토폴로지 세그먼트에 하나의 볼륨이 이미 생성되어
다른 볼륨에 충분한 용량이 남아 있지 않을 수 있다.
이러한 상황을 복구하려면
용량을 늘리거나 이미 생성된 볼륨을 삭제하는 등의 수작업이 필요하며,
자동으로 처리하려면
[추가 작업](https://github.com/kubernetes/enhancements/pull/1703)이 필요하다.
## 스토리지 용량 추적 활성화
스토리지 용량 추적은 베타 기능이며,
쿠버네티스 1.21 이후 버전부터 쿠버네티스 클러스터에 기본적으로 활성화되어 있다.
클러스터에서 스토리지 용량 추적 기능을 활성화하는 것뿐만 아니라, CSI 드라이버에서도 이 기능을 지원해야 한다.
자세한 내용은 드라이버 문서를 참조한다.
## {{% heading "whatsnext" %}}
- 설계에 대한 자세한 내용은
[파드 스케줄링 스토리지 용량 제약 조건](https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/1472-storage-capacity-tracking/README.md)을 참조한다.
- 이 기능의 추가 개발에 대한 자세한 내용은 [개선 추적 이슈 #1472](https://github.com/kubernetes/enhancements/issues/1472)를 참조한다.
- [쿠버네티스 스케줄러](/ko/docs/concepts/scheduling-eviction/kube-scheduler/)에 대해 살펴본다.
content/ko/docs/concepts/storage/storage-classes.md
+30 -1
View File
@@ -76,7 +76,7 @@ volumeBindingMode: Immediate
| Glusterfs | &#x2713; | [Glusterfs](#glusterfs) |
| iSCSI | - | - |
| Quobyte | &#x2713; | [Quobyte](#quobyte) |
| NFS | - | - |
| NFS | - | [NFS](#nfs) |
| RBD | &#x2713; | [Ceph RBD](#ceph-rbd) |
| VsphereVolume | &#x2713; | [vSphere](#vsphere) |
| PortworxVolume | &#x2713; | [Portworx 볼륨](#portworx-볼륨) |
@@ -423,6 +423,29 @@ parameters:
헤드리스 서비스를 자동으로 생성한다. 퍼시스턴트 볼륨 클레임을
삭제하면 동적 엔드포인트와 서비스가 자동으로 삭제된다.
### NFS
```yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: example-nfs
provisioner: example.com/external-nfs
parameters:
server: nfs-server.example.com
path: /share
readOnly: false
```
* `server`: NFS 서버의 호스트네임 또는 IP 주소.
* `path`: NFS 서버가 익스포트(export)한 경로.
* `readOnly`: 스토리지를 읽기 전용으로 마운트할지 나타내는 플래그(기본값: false).
쿠버네티스에는 내장 NFS 프로비저너가 없다. NFS를 위한 스토리지클래스를 생성하려면 외부 프로비저너를 사용해야 한다.
예시는 다음과 같다.
* [NFS Ganesha server and external provisioner](https://github.com/kubernetes-sigs/nfs-ganesha-server-and-external-provisioner)
* [NFS subdir external provisioner](https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner)
### OpenStack Cinder
```yaml
@@ -578,6 +601,12 @@ parameters:
### Quobyte
{{< feature-state for_k8s_version="v1.22" state="deprecated" >}}
Quobyte 인-트리 스토리지 플러그인은 사용 중단되었으며,
아웃-오브-트리 Quobyte 플러그인에 대한 [예제](https://github.com/quobyte/quobyte-csi/blob/master/example/StorageClass.yaml)
`StorageClass`는 Quobyte CSI 저장소에서 찾을 수 있다.
```yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
content/ko/docs/concepts/storage/volumes.md
+24 -59
View File
@@ -124,13 +124,13 @@ EBS 볼륨이 파티션된 경우, 선택적 필드인 `partition: "<partition n
{{< feature-state for_k8s_version="v1.17" state="alpha" >}}
컨트롤러 관리자와 kubelet에 의해 로드되지 않도록 `awsElasticBlockStore` 스토리지
플러그인을 끄려면, `CSIMigrationAWSComplete` 플래그를 `true` 로 설정한다. 이 기능은 모든 워커 노드에서 `ebs.csi.aws.com` 컨테이너 스토리지 인터페이스(CSI) 드라이버 설치를 필요로 한다.
플러그인을 끄려면, `InTreePluginAWSUnregister` 플래그를 `true` 로 설정한다.
### azureDisk {#azuredisk}
`azureDisk` 볼륨 유형은 Microsoft Azure [데이터 디스크](https://docs.microsoft.com/en-us/azure/aks/csi-storage-drivers)를 파드에 마운트한다.
더 자세한 내용은 [`azureDisk` 볼륨 플러그인](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/azure_disk/README.md)을 참고한다.
더 자세한 내용은 [`azureDisk` 볼륨 플러그인](https://github.com/kubernetes/examples/tree/master/staging/volumes/azure_disk/README.md)을 참고한다.
#### azureDisk CSI 마이그레이션
@@ -148,7 +148,7 @@ EBS 볼륨이 파티션된 경우, 선택적 필드인 `partition: "<partition n
`azureFile` 볼륨 유형은 Microsoft Azure 파일 볼륨(SMB 2.1과 3.0)을 파드에
마운트한다.
더 자세한 내용은 [`azureFile` 볼륨 플러그인](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/azure_file/README.md)을 참고한다.
더 자세한 내용은 [`azureFile` 볼륨 플러그인](https://github.com/kubernetes/examples/tree/master/staging/volumes/azure_file/README.md)을 참고한다.
#### azureFile CSI 마이그레이션
@@ -176,7 +176,7 @@ Azure File CSI 드라이버는 동일한 볼륨을 다른 fsgroup에서 사용
CephFS를 사용하기 위해선 먼저 Ceph 서버를 실행하고 공유를 내보내야 한다.
{{< /note >}}
더 자세한 내용은 [CephFS 예시](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/cephfs/)를 참조한다.
더 자세한 내용은 [CephFS 예시](https://github.com/kubernetes/examples/tree/master/volumes/cephfs/)를 참조한다.
### cinder
@@ -347,7 +347,7 @@ targetWWN은 해당 WWN이 다중 경로 연결에서 온 것으로 예상한다
쿠버네티스 호스트가 해당 LUN에 접근할 수 있다.
{{< /note >}}
더 자세한 내용은 [파이버 채널 예시](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/fibre_channel)를 참고한다.
더 자세한 내용은 [파이버 채널 예시](https://github.com/kubernetes/examples/tree/master/staging/volumes/fibre_channel)를 참고한다.
### flocker (사용 중단됨(deprecated)){#flocker}
@@ -365,7 +365,7 @@ Flocker는 파드가 스케줄 되어있는 노드에 다시 연결한다. 이
`flocker` 볼륨을 사용하기 위해서는 먼저 Flocker를 설치하고 실행한다.
{{< /note >}}
더 자세한 내용은 [Flocker 예시](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/flocker)를 참조한다.
더 자세한 내용은 [Flocker 예시](https://github.com/kubernetes/examples/tree/master/staging/volumes/flocker)를 참조한다.
### gcePersistentDisk
@@ -462,7 +462,8 @@ spec:
required:
nodeSelectorTerms:
- matchExpressions:
- key: failure-domain.beta.kubernetes.io/zone
# 1.21 이전 버전에서는 failure-domain.beta.kubernetes.io/zone 키를 사용해야 한다.
- key: topology.kubernetes.io/zone
operator: In
values:
- us-central1-a
@@ -480,6 +481,13 @@ GCE PD의 `CSIMigration` 기능이 활성화된 경우 기존 인-트리 플러
를 설치하고 `CSIMigration` 과 `CSIMigrationGCE`
베타 기능을 활성화해야 한다.
#### GCE CSI 마이그레이션 완료
{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
컨트롤러 매니저와 kubelet이 `gcePersistentDisk` 스토리지 플러그인을 로드하는 것을 방지하려면,
`InTreePluginGCEUnregister` 플래그를 `true`로 설정한다.
### gitRepo (사용 중단됨) {#gitrepo}
{{< warning >}}
@@ -525,7 +533,7 @@ glusterfs 볼륨에 데이터를 미리 채울 수 있으며, 파드 간에 데
사용하려면 먼저 GlusterFS를 설치하고 실행해야 한다.
{{< /note >}}
더 자세한 내용은 [GlusterFS 예시](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/glusterfs)를 본다.
더 자세한 내용은 [GlusterFS 예시](https://github.com/kubernetes/examples/tree/master/volumes/glusterfs)를 본다.
### hostPath {#hostpath}
@@ -653,7 +661,7 @@ iSCSI 특징은 여러 고객이 읽기 전용으로 마운트할 수
iSCSI 볼륨은 읽기-쓰기 모드에서는 단일 고객만 마운트할 수 있다.
동시 쓰기는 허용되지 않는다.
더 자세한 내용은 [iSCSI 예시](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/iscsi)를 본다.
더 자세한 내용은 [iSCSI 예시](https://github.com/kubernetes/examples/tree/master/volumes/iscsi)를 본다.
### local
@@ -741,7 +749,7 @@ local [스토리지클래스(StorageClas)](/ko/docs/concepts/storage/storage-cla
사용하려면 먼저 NFS 서버를 실행하고 공유를 내보내야 한다.
{{< /note >}}
더 자세한 내용은 [NFS 예시](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/nfs)를 본다.
더 자세한 내용은 [NFS 예시](https://github.com/kubernetes/examples/tree/master/staging/volumes/nfs)를 본다.
### persistentVolumeClaim {#persistentvolumeclaim}
@@ -789,7 +797,7 @@ spec:
있는지 확인한다.
{{< /note >}}
자세한 내용은 [Portworx 볼륨](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/portworx/README.md) 예제를 참고한다.
자세한 내용은 [Portworx 볼륨](https://github.com/kubernetes/examples/tree/master/staging/volumes/portworx/README.md) 예제를 참고한다.
### projected
@@ -803,7 +811,7 @@ spec:
* `serviceAccountToken`
모든 소스는 파드와 동일한 네임스페이스에 있어야 한다. 더 자세한 내용은
[올인원 볼륨 디자인 문서](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/node/all-in-one-volume.md)를 본다.
[올인원 볼륨 디자인 문서](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/all-in-one-volume.md)를 본다.
#### 시크릿, 다운워드 API 그리고 컨피그맵이 있는 구성 예시 {#example-configuration-secret-downwardapi-configmap}
@@ -931,7 +939,7 @@ projected 볼륨 소스를 [`subPath`](#subpath-사용하기) 볼륨으로 마
해당 볼륨 소스의 업데이트를 수신하지 않는다.
{{< /note >}}
### quobyte
### quobyte (사용 중단됨) {#quobyte}
`quobyte` 볼륨을 사용하면 기존 [Quobyte](https://www.quobyte.com) 볼륨을
파드에 마운트할 수 있다.
@@ -964,52 +972,9 @@ RBD의 특징은 여러 고객이 동시에 읽기 전용으로 마운트할 수
RBD는 읽기-쓰기 모드에서 단일 고객만 마운트할 수 있다.
동시 쓰기는 허용되지 않는다.
더 자세한 내용은 [RBD 예시](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/rbd)를
더 자세한 내용은 [RBD 예시](https://github.com/kubernetes/examples/tree/master/volumes/rbd)를
참고한다.
### scaleIO (사용 중단됨) {#scaleio}
ScaleIO는 기존 하드웨어를 사용해서 확장 가능한 공유 블럭 네트워크 스토리지 클러스터를
생성하는 소프트웨어 기반 스토리지 플랫폼이다. `scaleIO` 볼륨
플러그인을 사용하면 배포된 파드가 기존 ScaleIO에 접근할 수
있다. 퍼시스턴트 볼륨 클레임을 위해 새로운 볼륨을 동적으로 프로비저닝하는
방법에 대한 자세한 내용은
[ScaleIO 퍼시스턴트 볼륨](/ko/docs/concepts/storage/persistent-volumes/#scaleio)을 참고한다.
{{< note >}}
사용하기 위해선 먼저 기존에 ScaleIO 클러스터를 먼저 설정하고
생성한 볼륨과 함께 실행해야 한다.
{{< /note >}}
다음의 예시는 ScaleIO를 사용하는 파드 구성이다.
```yaml
apiVersion: v1
kind: Pod
metadata:
name: pod-0
spec:
containers:
- image: k8s.gcr.io/test-webserver
name: pod-0
volumeMounts:
- mountPath: /test-pd
name: vol-0
volumes:
- name: vol-0
scaleIO:
gateway: https://localhost:443/api
system: scaleio
protectionDomain: sd0
storagePool: sp1
volumeName: vol-0
secretRef:
name: sio-secret
fsType: xfs
```
더 자세한 내용은 [ScaleIO](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/scaleio) 예제를 참고한다.
### secret
`secret` 볼륨은 암호와 같은 민감한 정보를 파드에 전달하는데
@@ -1029,7 +994,7 @@ tmpfs(RAM 기반 파일시스템)로 지원되기 때문에 비 휘발성 스토
더 자세한 내용은 [시크릿 구성하기](/ko/docs/concepts/configuration/secret/)를 참고한다.
### storageOS {#storageos}
### storageOS (사용 중단됨) {#storageos}
`storageos` 볼륨을 사용하면 기존 [StorageOS](https://www.storageos.com)
볼륨을 파드에 마운트할 수 있다.
@@ -1177,7 +1142,7 @@ vSphere CSI 드라이버에서 생성된 새 볼륨은 이러한 파라미터를
{{< feature-state for_k8s_version="v1.19" state="beta" >}}
`vsphereVolume` 플러그인이 컨트롤러 관리자와 kubelet에 의해 로드되지 않도록 기능을 비활성화하려면, 이 기능 플래그를 `true` 로 설정해야 한다. 이를 위해서는 모든 워커 노드에 `csi.vsphere.vmware.com` {{< glossary_tooltip text="CSI" term_id="csi" >}} 드라이버가 설치해야 한다.
`vsphereVolume` 플러그인이 컨트롤러 관리자와 kubelet에 의해 로드되지 않도록 기능을 비활성화하려면, `InTreePluginvSphereUnregister` 기능 플래그를 `true` 로 설정해야 한다. 이를 위해서는 모든 워커 노드에 `csi.vsphere.vmware.com` {{< glossary_tooltip text="CSI" term_id="csi" >}} 드라이버를 설치해야 한다.
## subPath 사용하기 {#using-subpath}
content/ko/docs/concepts/workloads/controllers/cron-jobs.md
+4 -3
View File
@@ -36,9 +36,10 @@ kube-controller-manager 컨테이너에 설정된 시간대는
## 크론잡
크론잡은 백업 실행 또는 이메일 전송과 같은 정기적이고 반복적인
작업을 만드는데 유용하다. 또한 크론잡은 클러스터가 유휴 상태일 때 잡을
스케줄링하는 것과 같이 특정 시간 동안의 개별 작업을 스케줄할 수 있다.
크론잡은 백업, 리포트 생성 등의 정기적 작업을 수행하기 위해 사용된다.
각 작업은 무기한 반복되도록 구성해야 한다(예:
1일/1주/1달마다 1회).
작업을 시작해야 하는 해당 간격 내 특정 시점을 정의할 수 있다.
### 예시
content/ko/docs/concepts/workloads/controllers/daemonset.md
+4 -2
View File
@@ -229,5 +229,7 @@ Kubelet이 감시하는 특정 디렉터리에 파일을 작성하는 파드를
파드가 실행되는 호스트를 정확하게 제어하는 것보다 레플리카의 수를 스케일링 업 및 다운 하고,
업데이트 롤아웃이 더 중요한 프런트 엔드와 같은 것은 스테이트리스 서비스의
디플로이먼트를 사용한다. 파드 사본이 항상 모든 호스트 또는 특정 호스트에서 실행되는 것이 중요하고,
다른 파드의 실행 이전에 필요한 경우에는 데몬셋을 사용한다.
디플로이먼트를 사용한다. 데몬셋이 특정 노드에서 다른 파드가 올바르게 실행되도록 하는 노드 수준 기능을 제공한다면,
파드 사본이 항상 모든 호스트 또는 특정 호스트에서 실행되는 것이 중요한 경우에 데몬셋을 사용한다.
예를 들어, [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)은 데몬셋으로 실행되는 컴포넌트를 포함할 수 있다. 데몬셋 컴포넌트는 작동 중인 노드가 정상적인 클러스터 네트워킹을 할 수 있도록 한다.
content/ko/docs/concepts/workloads/controllers/garbage-collection.md
+12
View File
@@ -6,6 +6,18 @@ weight: 60
<!-- overview -->
{{< note >}}
이 한글 문서는 더 이상 관리되지 않습니다.
이 문서의 기반이 된 영어 원문은 삭제되었으며,
[Garbage Collection](/docs/concepts/architecture/garbage-collection/)에 병합되었습니다.
[Garbage Collection](/docs/concepts/architecture/garbage-collection/)의 한글화가 완료되면,
이 문서는 삭제될 수 있습니다.
{{< /note >}}
쿠버네티스의 가비지 수집기는 한때 소유자가 있었지만, 더 이상
소유자가 없는 오브젝트들을 삭제하는 역할을 한다.
content/ko/docs/concepts/workloads/controllers/job.md
+56 -18
View File
@@ -187,14 +187,7 @@ _작업 큐_ 잡은 `.spec.completions` 를 설정하지 않은 상태로 두고
### 완료 모드
{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
{{< note >}}
인덱싱된 잡을 생성하려면, [API 서버](/docs/reference/command-line-tools-reference/kube-apiserver/)
및 [컨트롤러 관리자](/docs/reference/command-line-tools-reference/kube-controller-manager/)에서
`IndexedJob` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를
활성화해야 한다.
{{< /note >}}
{{< feature-state for_k8s_version="v1.22" state="beta" >}}
완료 횟수가 _고정적인 완료 횟수_ 즉, null이 아닌 `.spec.completions` 가 있는 잡은
`.spec.completionMode` 에 지정된 완료 모드를 가질 수 있다.
@@ -203,8 +196,14 @@ _작업 큐_ 잡은 `.spec.completions` 를 설정하지 않은 상태로 두고
완료된 파드가 있는 경우 작업이 완료된 것으로 간주된다. 즉, 각 파드
완료는 서로 상동하다(homologous). null `.spec.completions` 가 있는
잡은 암시적으로 `NonIndexed` 이다.
- `Indexed`: 잡의 파드는 `batch.kubernetes.io/job-completion-index`
어노테이션에서 사용할 수 있는 0에서 `.spec.completions-1` 까지 연결된 완료 인덱스를 가져온다.
- `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` 환경 변수.
각 인덱스에 대해 성공적으로 완료된 파드가 하나 있으면 작업이 완료된 것으로
간주된다. 이 모드를 사용하는 방법에 대한 자세한 내용은
[정적 작업 할당을 사용한 병렬 처리를 위해 인덱싱된 잡](/docs/tasks/job/indexed-parallel-processing-static/)을 참고한다.
@@ -255,7 +254,8 @@ _작업 큐_ 잡은 `.spec.completions` 를 설정하지 않은 상태로 두고
## 잡의 종료와 정리
잡이 완료되면 파드가 더 이상 생성되지도 않지만, 삭제되지도 않는다. 이를 유지하면
잡이 완료되면 파드가 더 이상 생성되지도 않지만, [일반적으로는](#pod-backoff-failure-policy) 삭제되지도 않는다.
이를 유지하면
완료된 파드의 로그를 계속 보며 에러, 경고 또는 다른 기타 진단 출력을 확인할 수 있다.
잡 오브젝트는 완료된 후에도 상태를 볼 수 있도록 남아 있다. 상태를 확인한 후 이전 잡을 삭제하는 것은 사용자의 몫이다.
`kubectl` 로 잡을 삭제할 수 있다 (예: `kubectl delete jobs/pi` 또는 `kubectl delete -f ./job.yaml`). `kubectl` 을 사용해서 잡을 삭제하면 생성된 모든 파드도 함께 삭제된다.
@@ -402,14 +402,12 @@ spec:
### 잡 일시 중지
{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
{{< feature-state for_k8s_version="v1.22" state="beta" >}}
{{< note >}}
잡 일시 중지는 쿠버네티스 버전 1.21 이상에서 사용할 수 있다. 이 기능을
사용하려면 [API 서버](/docs/reference/command-line-tools-reference/kube-apiserver/)
및 [컨트롤러 관리자](/docs/reference/command-line-tools-reference/kube-controller-manager/)에서
`SuspendJob` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를
활성화해야 한다.
이 기능은 쿠버네티스 버전 1.21에서는 알파 상태였으며,
이 때문에 이 기능을 활성화하기 위해서는 추가적인 단계를 진행해야 한다.
[현재 사용 중인 쿠버네티스 버전과 맞는 문서](/ko/docs/home/supported-doc-versions/)를 읽고 있는 것이 맞는지 다시 한번 확인한다.
{{< /note >}}
잡이 생성되면, 잡 컨트롤러는 잡의 요구 사항을 충족하기 위해
@@ -568,6 +566,46 @@ spec:
`manualSelector: true` 를 설정하면 시스템에게 사용자가 무엇을 하는지 알고 있음을 알리고, 이런
불일치를 허용한다.
### 종료자(finalizers)를 이용한 잡 추적
{{< feature-state for_k8s_version="v1.22" state="alpha" >}}
{{< 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/)를 활성화해야 한다.
기본적으로는 비활성화되어 있다.
이 기능이 활성화되면, 컨트롤 플레인은 아래에 설명할 동작을 이용하여 새로운 잡이 생성되는지 추적한다.
기존에 존재하던 잡은 영향을 받지 않는다.
사용자가 느낄 수 있는 유일한 차이점은 컨트롤 플레인이 잡 종료를 좀 더 정확하게 추적할 수 있다는 것이다.
{{< /note >}}
이 기능이 활성화되지 않으면, 잡
{{< glossary_tooltip text="컨트롤러" term_id="controller" >}}는
`succeeded`와 `failed` 파드의 수를 세어 잡 상태를 추적한다.
그런데, 파드는 다음과 같은 이유로 제거될 수 있다.
- 노드가 다운되었을 때 가비지 콜렉터가 버려진(orphan) 파드를 제거
- 가비지 콜렉터가 (`Succeeded` 또는 `Failed` 단계에 있는) 완료된 파드를
일정 임계값 이후에 제거
- 잡에 속한 파드를 사용자가 임의로 제거
- (쿠버네티스에 속하지 않는) 외부 컨트롤러가 파드를 제거하거나
교체
클러스터에서 `JobTrackingWithFinalizers` 기능을 활성화하면,
컨트롤 플레인은 잡에 속하는 파드의 상태를 추적하고
API 서버에서 파드가 제거되면 이를 알아챈다.
이를 위해, 잡 컨트롤러는 `batch.kubernetes.io/job-tracking` 종료자를 갖는 파드를 생성한다.
컨트롤러는 파드의 상태 변화가 잡 상태에 반영된 후에만 종료자를 제거하므로,
이후 다른 컨트롤러나 사용자가 파드를 제거할 수 있다.
잡 컨트롤러는 새로운 잡에 대해서만 새로운 알고리즘을 적용한다.
이 기능이 활성화되기 전에 생성된 잡은 영향을 받지 않는다.
잡에 `batch.kubernetes.io/job-tracking` 어노테이션이 있는지 확인하여,
잡 컨트롤러가 파드 종료자를 이용하여 잡을 추적하고 있는지 여부를 확인할 수 있다.
이 어노테이션을 잡에 수동으로 추가하거나 제거해서는 **안 된다**.
## 대안
### 베어(Bare) 파드
@@ -594,7 +632,7 @@ spec:
시작하기에는 다소 복잡할 수 있으며 쿠버네티스와의 통합성이 낮아진다.
이 패턴의 한 예시는 파드를 시작하는 잡이다. 파드는 스크립트를 실행해서
스파크(Spark) 마스터 컨트롤러 ([스파크 예시](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/spark/README.md)를 본다)를 시작하고,
스파크(Spark) 마스터 컨트롤러 ([스파크 예시](https://github.com/kubernetes/examples/tree/master/staging/spark/README.md)를 본다)를 시작하고,
스파크 드라이버를 실행한 다음, 정리한다.
이 접근 방식의 장점은 전체 프로세스가 잡 오브젝트의 완료를 보장하면서도,
content/ko/docs/concepts/workloads/controllers/replicaset.md
+5 -5
View File
@@ -323,9 +323,9 @@ curl -X DELETE 'localhost:8080/apis/apps/v1/namespaces/default/replicasets/fron
모든 기준에 대해 동등하다면, 스케일 다운할 파드가 임의로 선택된다.
### 파드 삭제 비용
{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
{{< feature-state for_k8s_version="v1.22" state="beta" >}}
[`controller.kubernetes.io/pod-deletion-cost`](/docs/reference/labels-annotations-taints/#pod-deletion-cost) 어노테이션을 이용하여,
[`controller.kubernetes.io/pod-deletion-cost`](/ko/docs/reference/labels-annotations-taints/#pod-deletion-cost) 어노테이션을 이용하여,
레플리카셋을 스케일 다운할 때 어떤 파드부터 먼저 삭제할지에 대한 우선순위를 설정할 수 있다.
이 어노테이션은 파드에 설정되어야 하며, [-2147483647, 2147483647] 범위를 갖는다.
@@ -335,9 +335,9 @@ curl -X DELETE 'localhost:8080/apis/apps/v1/namespaces/default/replicasets/fron
파드에 대해 이 값을 명시하지 않으면 기본값은 0이다. 음수로도 설정할 수 있다.
유효하지 않은 값은 API 서버가 거부한다.
이 기능은 알파 상태이며 기본적으로는 비활성화되어 있다.
kube-apiserver와 kube-controller-manager에서 `PodDeletionCost`
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 켜서 활성화할 수 있다.
이 기능은 베타 상태이며 기본적으로 활성화되어 있다.
kube-apiserver와 kube-controller-manager에 대해 `PodDeletionCost`
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 이용하여 비활성화할 수 있다.
{{< note >}}
- 이 기능은 best-effort 방식으로 동작하므로, 파드 삭제 순서를 보장하지는 않는다.
content/ko/docs/concepts/workloads/controllers/statefulset.md
+32 -17
View File
@@ -32,7 +32,7 @@ weight: 30
## 제한사항
* 파드에 지정된 스토리지는 관리자에 의해 [퍼시스턴트 볼륨 프로비저너](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/README.md)를 기반으로 하는 `storage class` 를 요청해서 프로비전하거나 사전에 프로비전이 되어야 한다.
* 파드에 지정된 스토리지는 관리자에 의해 [퍼시스턴트 볼륨 프로비저너](https://github.com/kubernetes/examples/tree/master/staging/persistent-volume-provisioning/README.md)를 기반으로 하는 `storage class` 를 요청해서 프로비전하거나 사전에 프로비전이 되어야 한다.
* 스테이트풀셋을 삭제 또는 스케일 다운해도 스테이트풀셋과 연관된 볼륨이 *삭제되지 않는다*. 이는 일반적으로 스테이트풀셋과 연관된 모든 리소스를 자동으로 제거하는 것보다 더 중요한 데이터의 안전을 보장하기 위함이다.
* 스테이트풀셋은 현재 파드의 네트워크 신원을 책임지고 있는 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)가 필요하다. 사용자가 이 서비스를 생성할 책임이 있다.
* 스테이트풀셋은 스테이트풀셋의 삭제 시 파드의 종료에 대해 어떠한 보증을 제공하지 않는다. 스테이트풀셋에서는 파드가 순차적이고 정상적으로 종료(graceful termination)되도록 하려면, 삭제 전 스테이트풀셋의 스케일을 0으로 축소할 수 있다.
@@ -223,27 +223,31 @@ web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가
## 업데이트 전략
쿠버네티스 1.7 및 이후에는 스테이트풀셋의 `.spec.updateStrategy` 필드는 스테이트풀셋의
스테이트풀셋의 `.spec.updateStrategy` 필드는 스테이트풀셋의
파드에 대한 컨테이너, 레이블, 리소스의 요청/제한 그리고 주석에 대한 자동화된 롤링 업데이트를
구성하거나 비활성화 할 수 있다.
구성하거나 비활성화할 수 있다. 두 가지 가능한 전략이 있다.
### 삭제 시(On Delete)
`OnDelete` 업데이트 전략은 레거시(1.6과 이전)의 행위를 구현한다. 이때 스테이트풀셋의
`.spec.updateStrategy.type` 은 `OnDelete` 를 설정하며, 스테이트풀셋 컨트롤러는
스테이트풀셋의 파드를 자동으로 업데이트하지 않는다. 사용자는 컨트롤러가 스테이트풀셋의
`OnDelete`(삭제시)
: 스테이트풀셋의 `.spec.updateStrategy.type` 은 `OnDelete` 를 설정하며,
스테이트풀셋 컨트롤러는 스테이트풀셋의 파드를 자동으로 업데이트하지 않는다.
사용자는 컨트롤러가 스테이트풀셋의
`.spec.template`를 반영하는 수정된 새로운 파드를 생성하도록 수동으로 파드를 삭제해야 한다.
### 롤링 업데이트
`RollingUpdate`(롤링 업데이트)
: `롤링 업데이트` 의 업데이트 전략은 스테이트풀셋의 파드에 대한 롤링 업데이트를
구현한다. 롤링 업데이트는 `.spec.updateStrategy` 가 지정되지 않으면 기본 전략이 된다.
`롤링 업데이트` 의 업데이트 전략은 스테이트풀셋의 파드에 대한 롤링 업데이트를
구현한다. 롤링 업데이트는 `.spec.updateStrategy` 가 지정되지 않으면 기본 전략이 된다. 스테이트풀셋에 `롤링 업데이트` 가 `.spec.updateStrategy.type` 에 설정되면
스테이트풀셋 컨트롤러는 스테이트풀셋의 각 파드를 삭제 및 재생성을 한다. 이 과정에서 똑같이
순차적으로 파드가 종료되고(가장 큰 수에서 작은 수까지),
각 파드의 업데이트는 한 번에 하나씩 한다. 이전 버전을 업데이트하기 전까지 업데이트된 파드가 실행 및 준비될
때까지 기다린다.
## 롤링 업데이트
#### 파티션(Partition)
스테이트풀셋에 `롤링 업데이트` 가 `.spec.updateStrategy.type` 에 설정되면
스테이트풀셋 컨트롤러는 스테이트풀셋의 각 파드를 삭제 및 재생성한다. 이 과정에서 똑같이
순차적으로 파드가 종료되고(가장 큰 순서 색인에서부터에서 작은 순서 색인쪽으로),
각 파드의 업데이트는 한 번에 하나씩 한다.
쿠버네티스 컨트롤 플레인은 이전 버전을 업데이트 하기 전에, 업데이트된 파드가 실행 및 준비될 때까지 기다린다.
`.spec.minReadySeconds`([최소 준비 시간 초](#minimum-ready-seconds) 참조)를 설정한 경우, 컨트롤 플레인은 파드가 준비 상태로 전환된 후 해당 시간을 추가로 기다린 후 이동한다.
### 파티션 롤링 업데이트 {#partitions}
`롤링 업데이트` 의 업데이트 전략은 `.spec.updateStrategy.rollingUpdate.partition`
를 명시해서 파티션 할 수 있다. 만약 파티션을 명시하면 스테이트풀셋의 `.spec.template` 가
@@ -255,7 +259,7 @@ web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가
대부분의 케이스는 파티션을 사용할 필요가 없지만 업데이트를 준비하거나,
카나리의 롤 아웃 또는 단계적인 롤 아웃을 행하려는 경우에는 유용하다.
#### 강제 롤백
### 강제 롤백
기본 [파드 관리 정책](#파드-관리-정책) (`OrderedReady`)과
함께 [롤링 업데이트](#롤링-업데이트)를 사용할 경우
@@ -275,6 +279,17 @@ web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가
실행하려고 시도한 모든 파드를 삭제해야 한다.
그러면 스테이트풀셋은 되돌린 템플릿을 사용해서 파드를 다시 생성하기 시작한다.
### 최소 준비 시간 초 {#minimum-ready-seconds}
{{< feature-state for_k8s_version="v1.22" state="alpha" >}}
`.spec.minReadySeconds`는 새로 생성된 파드가 사용가능하다고 간주되도록
컨테이너가 충돌되지 않고 준비되는 최소 시간 초를 지정하는 선택적 필드이다.
기본값은 0이다(파드는 준비되는 대로 사용 가능한 것으로 간주된다).
파드가 준비가 되는 시기에 대해 더 자세히 알아보고 싶다면,
[컨테이너 프로브](/ko/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)를 참고한다.
이 필드는 `StatefulSetMinReadySeconds` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 사용하도록 설정한 경우에만 작동한다.
## {{% heading "whatsnext" %}}
content/ko/docs/concepts/workloads/pods/_index.md
+17 -2
View File
@@ -257,8 +257,12 @@ POSIX 공유 메모리와 같은 표준 프로세스 간 통신을 사용하여
## 컨테이너에 대한 특권 모드
파드의 모든 컨테이너는 컨테이너 명세의 [보안 콘텍스트](/docs/tasks/configure-pod-container/security-context/)에 있는 `privileged` 플래그를 사용하여 특권 모드를 활성화할 수 있다. 이는 네트워크 스택 조작이나 하드웨어 장치 접근과 같은 운영 체제 관리 기능을 사용하려는 컨테이너에 유용하다.
특권이 있는 컨테이너 내의 프로세스는 컨테이너 외부의 프로세스가 가지는 거의 동일한 권한을 가진다.
리눅스에서, 파드의 모든 컨테이너는 컨테이너 명세의 [보안 컨텍스트](/docs/tasks/configure-pod-container/security-context/)에 있는 `privileged` (리눅스) 플래그를 사용하여 특권 모드를 활성화할 수 있다. 이는 네트워크 스택 조작이나 하드웨어 장치 접근과 같은 운영 체제 관리 기능을 사용하려는 컨테이너에 유용하다.
클러스터가 `WindowsHostProcessContainers` 기능을 활성화하였다면, 파드 스펙의 보안 컨텍스트의 `windowsOptions.hostProcess` 에 의해 [윈도우 HostProcess 파드](/docs/tasks/configure-pod-container/create-hostprocess-pod)를 생성할 수 있다. 이러한 모든 컨테이너는 윈도우 HostProcess 컨테이너로 실행해야 한다. HostProcess 파드는 직접적으로 호스트에서 실행하는 것으로, 리눅스 특권있는 컨테이너에서 수행되는 관리 태스크 수행에도 사용할 수 있다.
파드의 모든 컨테이너는 윈도우 HostProcess 컨테이너로 반드시 실행해야 한다.
HostProcess 파드는 호스트에서 직접 실행되며 리눅스 특권있는 컨테이너에서 수행되는 것과 같은 관리 작업을 수행하는데도 사용할 수 있다.
{{< note >}}
이 설정을 사용하려면 사용자의 {{< glossary_tooltip text="컨테이너 런타임" term_id="container-runtime" >}}이 특권이 있는 컨테이너의 개념을 지원해야 한다.
@@ -282,6 +286,17 @@ kubelet은 자동으로 각 정적 파드에 대한 쿠버네티스 API 서버
즉, 노드에서 실행되는 파드는 API 서버에서 보이지만,
여기에서 제어할 수는 없다는 의미이다.
## 컨테이너 프로브
_프로브_는 컨테이너의 kubelet에 의해 주기적으로 실행되는 진단이다. 진단을 수행하기 위하여 kubelet은 다음과 같은 작업을 호출할 수 있다.
- `ExecAction` (컨테이너 런타임의 도움을 받아 수행)
- `TCPSocketAction` (kubelet에 의해 직접 검사)
- `HTTPGetAction` (kubelet에 의해 직접 검사)
[프로브](/ko/docs/concepts/workloads/pods/pod-lifecycle/#컨테이너-프로브-probe)에 대한 자세한 내용은
파드 라이프사이클 문서를 참고한다.
## {{% heading "whatsnext" %}}
* [파드의 라이프사이클](/ko/docs/concepts/workloads/pods/pod-lifecycle/)에 대해 알아본다.
content/ko/docs/concepts/workloads/pods/ephemeral-containers.md
+8 -119
View File
@@ -6,15 +6,15 @@ weight: 80
<!-- overview -->
{{< feature-state state="alpha" for_k8s_version="v1.16" >}}
{{< feature-state state="alpha" for_k8s_version="v1.22" >}}
이 페이지는 임시 컨테이너에 대한 개요를 제공한다: 이 특별한 유형의 컨테이너는
트러블 슈팅과 같은 사용자가 시작한 작업을 완료하기위해 기존 {{< glossary_tooltip text="파드" term_id="pod" >}} 에서
임시적으로 실행된다. 사용자는 애플리케이션 빌드보다는 서비스를 점검할 때 임시
컨테이너를 사용한다.
이 페이지는 임시 컨테이너에 대한 개요를 제공한다.
이 특별한 유형의 컨테이너는 트러블슈팅과 같은 사용자가 시작한 작업을 완료하기 위해
기존 {{< glossary_tooltip text="파드" term_id="pod" >}}에서 임시적으로 실행된다.
임시 컨테이너는 애플리케이션을 빌드하는 경우보다는 서비스 점검과 같은 경우에 더 적합하다.
{{< warning >}}
임시 컨테이너는 초기 알파 상태이며,
임시 컨테이너 기능은 알파 상태이며,
프로덕션 클러스터에는 적합하지 않다.
[쿠버네티스 사용 중단(deprecation) 정책](/docs/reference/using-api/deprecation-policy/)에 따라
이 알파 기능은 향후 크게 변경되거나, 완전히 제거될 수 있다.
@@ -74,117 +74,6 @@ API에서 특별한 `ephemeralcontainers` 핸들러를 사용해서 만들어지
공유](/docs/tasks/configure-pod-container/share-process-namespace/)를
활성화하면 다른 컨테이너 안의 프로세스를 보는 데 도움이 된다.
임시 컨테이너를 사용해서 문제를 해결하는 예시는
[임시 디버깅 컨테이너로 디버깅하기]
(/docs/tasks/debug-application-cluster/debug-running-pod/#ephemeral-container)를 참조한다.
## {{% heading "whatsnext" %}}
## 임시 컨테이너 API
{{< note >}}
이 섹션의 예시는 `EphemeralContainers` [기능
게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)의
활성화를 필요로 하고, 쿠버네티스 클라이언트와 서버는 v1.16 또는 이후의 버전이어야 한다.
{{< /note >}}
이 섹션의 예시는 임시 컨테이너가 어떻게 API에 나타나는지
보여준다. 일반적으로 `kubectl debug` 또는
다른 `kubectl` [플러그인](/ko/docs/tasks/extend-kubectl/kubectl-plugins/)을
사용해서 API를 직접 호출하지 않고 이런 단계들을 자동화 한다.
임시 컨테이너는 파드의 `ephemeralcontainers` 하위 리소스를
사용해서 생성되며, `kubectl --raw` 를 사용해서 보여준다. 먼저
`EphemeralContainers` 목록으로 추가하는 임시 컨테이너를 명시한다.
```json
{
"apiVersion": "v1",
"kind": "EphemeralContainers",
"metadata": {
"name": "example-pod"
},
"ephemeralContainers": [{
"command": [
"sh"
],
"image": "busybox",
"imagePullPolicy": "IfNotPresent",
"name": "debugger",
"stdin": true,
"tty": true,
"terminationMessagePolicy": "File"
}]
}
```
이미 실행중인 `example-pod` 에 임시 컨테이너를 업데이트 한다.
```shell
kubectl replace --raw /api/v1/namespaces/default/pods/example-pod/ephemeralcontainers -f ec.json
```
그러면 새로운 임시 컨테이너 목록이 반환된다.
```json
{
"kind":"EphemeralContainers",
"apiVersion":"v1",
"metadata":{
"name":"example-pod",
"namespace":"default",
"selfLink":"/api/v1/namespaces/default/pods/example-pod/ephemeralcontainers",
"uid":"a14a6d9b-62f2-4119-9d8e-e2ed6bc3a47c",
"resourceVersion":"15886",
"creationTimestamp":"2019-08-29T06:41:42Z"
},
"ephemeralContainers":[
{
"name":"debugger",
"image":"busybox",
"command":[
"sh"
],
"resources":{
},
"terminationMessagePolicy":"File",
"imagePullPolicy":"IfNotPresent",
"stdin":true,
"tty":true
}
]
}
```
사용자는 `kubectl describe` 를 사용해서 새로 만든 임시 컨테이너의 상태를 볼 수 있다.
```shell
kubectl describe pod example-pod
```
```
...
Ephemeral Containers:
debugger:
Container ID: docker://cf81908f149e7e9213d3c3644eda55c72efaff67652a2685c1146f0ce151e80f
Image: busybox
Image ID: docker-pullable://busybox@sha256:9f1003c480699be56815db0f8146ad2e22efea85129b5b5983d0e0fb52d9ab70
Port: <none>
Host Port: <none>
Command:
sh
State: Running
Started: Thu, 29 Aug 2019 06:42:21 +0000
Ready: False
Restart Count: 0
Environment: <none>
Mounts: <none>
...
```
예시와 같이 `kubectl attach`, `kubectl exec`, 그리고 `kubectl logs` 를 사용해서
다른 컨테이너와 같은 방식으로 새로운 임시 컨테이너와
상호작용할 수 있다.
```shell
kubectl attach -it example-pod -c debugger
```
* [임시 컨테이너 디버깅하기](/docs/tasks/debug-application-cluster/debug-running-pod/#ephemeral-container)에 대해 알아보기.
content/ko/docs/concepts/workloads/pods/init-containers.md
+3 -2
View File
@@ -290,8 +290,9 @@ myapp-pod 1/1 Running 0 9m
초기화 컨테이너에게 명령과 실행이 주어진 경우, 리소스 사용에 대한
다음의 규칙이 적용된다.
* 모든 컨테이너에 정의된 특정 리소스 요청량 또는 상한 중 가장
높은 것은 *유효한 초기화 요청량/상한* 이다.
* 모든 컨테이너에 정의된 특정 리소스 요청량 또는 상한 중
가장 높은 것은 *유효 초기화 요청량/상한* 이다. 리소스 제한이 지정되지 않은 리소스는
이 *유효 초기화 요청량/상한*을 가장 높은 요청량/상한으로 간주한다.
* 리소스를 위한 파드의 *유효한 초기화 요청량/상한* 은 다음 보다 더 높다.
* 모든 앱 컨테이너의 리소스에 대한 요청량/상한의 합계
* 리소스에 대한 유효한 초기화 요청량/상한
content/ko/docs/concepts/workloads/pods/pod-lifecycle.md
+1 -1
View File
@@ -379,7 +379,7 @@ TERM 대신 이 값을 보낸다.
확인하는 즉시(정상적인 종료 기간이 설정됨), kubelet은 로컬 파드의 종료
프로세스를 시작한다.
1. 파드의 컨테이너 중 하나가 `preStop`
[훅](/ko/docs/concepts/containers/container-lifecycle-hooks/#hook-details)을 정의한 경우, kubelet은
[훅](/ko/docs/concepts/containers/container-lifecycle-hooks)을 정의한 경우, kubelet은
컨테이너 내부에서 해당 훅을 실행한다. 유예 기간이 만료된 후 `preStop` 훅이
계속 실행되면, kubelet은 2초의 작은 일회성 유예 기간 연장을
요청한다.
content/ko/docs/contribute/generate-ref-docs/quickstart.md
+6 -7
View File
@@ -6,7 +6,7 @@ weight: 40
<!-- overview -->
이 문서에서는 `update-imported-docs` 스크립트를 사용하여
이 문서에서는 `update-imported-docs.py` 스크립트를 사용하여
쿠버네티스 레퍼런스 문서를 생성하는 방법에 대해 설명한다.
이 스크립트는 특정 쿠버네티스 릴리스 버전에 대해 빌드 설정을 자동으로 수행하고 레퍼런스 문서를 생성한다.
@@ -39,7 +39,7 @@ git clone git@github.com:<your_github_username>/website.git
## `update-imported-docs` 스크립트 개요 {#Overview-of-update-imported-docs}
`update-imported-docs` 스크립트는 `<web-base>/update-imported-docs/`
`update-imported-docs.py` 스크립트는 `<web-base>/update-imported-docs/`
디렉터리에 존재한다.
이 스크립트는 다음 레퍼런스를 생성한다.
@@ -48,7 +48,7 @@ git clone git@github.com:<your_github_username>/website.git
* `kubectl` 명령어 레퍼런스
* 쿠버네티스 API 레퍼런스
`update-imported-docs` 스크립트는 쿠버네티스 소스코드로부터 레퍼런스 문서를
`update-imported-docs.py` 스크립트는 쿠버네티스 소스코드로부터 레퍼런스 문서를
생성한다. 스크립트가 실행되면 개발 머신의 `/tmp` 디렉터리 아래에 임시 디렉터리를
생성하고, 이 임시 디렉터리 아래에 레퍼런스 문서 생성에 필요한 `kubernetes/kubernetes` 저장소와
`kubernetes-sigs/reference-docs` 저장소를 클론하며,
@@ -69,7 +69,7 @@ git clone git@github.com:<your_github_username>/website.git
`kubernetes-sigs/reference-docs/Makefile` 에 있는 Make 타겟들을 활용하여 빌드하는 일련의 과정이 명시되어 있다.
`K8S_RELEASE` 환경 변수는 릴리스 버전을 결정한다.
`update-imported-docs` 스크립트는 다음의 과정을 수행한다.
`update-imported-docs.py` 스크립트는 다음의 과정을 수행한다.
1. 환경설정 파일에 있는 관련 저장소를 클론한다.
레퍼런스 문서 생성을 위해
@@ -152,11 +152,11 @@ repos:
## `update-imported-docs` 도구 실행하기 {#Running-the-update-imported-docs-tool}
다음과 같이 `update-imported-docs` 도구를 실행할 수 있다.
다음과 같이 `update-imported-docs.py` 도구를 실행할 수 있다.
```shell
cd <web-base>/update-imported-docs
./update-imported-docs <configuration-file.yml> <release-version>
./update-imported-docs.py <configuration-file.yml> <release-version>
```
예를 들면 다음과 같다.
@@ -254,4 +254,3 @@ static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/fonts/fon
* [kubectl 명령어에 대한 레퍼런스 문서 생성하기](/docs/contribute/generate-ref-docs/kubectl/)
* [쿠버네티스 API에 대한 레퍼런스 문서 생성하기](/docs/contribute/generate-ref-docs/kubernetes-api/)
content/ko/docs/reference/_index.md
+3
View File
@@ -71,8 +71,10 @@ TCP/UDP 스트림 포워딩이나 백-엔드 집합에 걸쳐서 라운드-로
사용/관리하는 데에 중요하지만, 이들 API의 대부분은 아직 API 서버가
제공하지 않는다.
* [kube-apiserver 환경설정 (v1alpha1)](/docs/reference/config-api/apiserver-config.v1alpha1/)
* [kubelet 환경설정 (v1beta1)](/docs/reference/config-api/kubelet-config.v1beta1/)
* [kube-scheduler 환경설정 (v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/)
* [kube-scheduler 환경설정 (v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2/)
* [kube-scheduler 정책 레퍼런스 (v1)](/docs/reference/config-api/kube-scheduler-policy-config.v1/)
* [kube-proxy 환경설정 (v1alpha1)](/docs/reference/config-api/kube-proxy-config.v1alpha1/)
* [`audit.k8s.io/v1` API](/docs/reference/config-api/apiserver-audit.v1/)
@@ -82,6 +84,7 @@ TCP/UDP 스트림 포워딩이나 백-엔드 집합에 걸쳐서 라운드-로
## kubeadm을 위한 API 설정
* [v1beta2](/docs/reference/config-api/kubeadm-config.v1beta2/)
* [v1beta3](/docs/reference/config-api/kubeadm-config.v1beta3/)
## 설계 문서
content/ko/docs/reference/access-authn-authz/service-accounts-admin.md
+2 -7
View File
@@ -57,10 +57,9 @@ weight: 50
#### 바인딩된 서비스 어카운트 토큰 볼륨
{{< feature-state for_k8s_version="v1.21" state="beta" >}}
{{< feature-state for_k8s_version="v1.22" state="stable" >}}
`BoundServiceAccountTokenVolume` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되면,
토큰 컨트롤러에 의해 생성된 무기한 서비스 어카운트 토큰을 위해, 서비스 어카운트 어드미션 컨트롤러가 시크릿 기반 볼륨 대신 다음과 같은 프로젝티드 볼륨을 추가한다.
서비스 어카운트 어드미션 컨트롤러는 토큰 컨트롤러에서 생성한 만료되지 않은 서비스 계정 토큰에 시크릿 기반 볼륨 대신 다음과 같은 프로젝티드 볼륨을 추가한다.
```yaml
- name: kube-api-access-<random-suffix>
@@ -91,10 +90,6 @@ weight: 50
상세 사항은 [프로젝티드 볼륨](/docs/tasks/configure-pod-container/configure-projected-volume-storage/)을 참고한다.
`BoundServiceAccountTokenVolume` 기능 게이트가 활성화되어 있지 않은 경우,
위의 프로젝티드 볼륨을 파드 스펙에 추가하여
시크릿 기반 서비스 어카운트 볼륨을 프로젝티드 볼륨으로 수동으로 옮길 수 있다.
### 토큰 컨트롤러
토큰컨트롤러는 `kube-controller-manager` 의 일부로 실행된다. 이것은 비동기적으로 동작한다. 토큰 컨트롤러는,
content/ko/docs/reference/command-line-tools-reference/feature-gates.md
+215 -66
View File
@@ -2,6 +2,9 @@
weight: 10
title: 기능 게이트
content_type: concept
card:
name: reference
weight: 60
---
<!-- overview -->
@@ -25,7 +28,7 @@ content_type: concept
kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 쌍 목록에 지정된 `--feature-gates` 플래그를 사용한다.
```shell
--feature-gates="...,DynamicKubeletConfig=true"
--feature-gates="...,GracefulNodeShutdown=true"
```
다음 표는 다른 쿠버네티스 컴포넌트에서 설정할 수 있는 기능 게이트를
@@ -55,65 +58,60 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `APIResponseCompression` | `false` | 알파 | 1.7 | 1.15 |
| `APIResponseCompression` | `true` | 베타 | 1.16 | |
| `APIServerIdentity` | `false` | 알파 | 1.20 | |
| `APIServerTracing` | `false` | 알파 | 1.22 | |
| `AllowInsecureBackendProxy` | `true` | 베타 | 1.17 | |
| `AnyVolumeDataSource` | `false` | 알파 | 1.18 | |
| `AppArmor` | `true` | 베타 | 1.4 | |
| `BalanceAttachedNodeVolumes` | `false` | 알파 | 1.11 | |
| `BoundServiceAccountTokenVolume` | `false` | 알파 | 1.13 | 1.20 |
| `BoundServiceAccountTokenVolume` | `true` | 베타 | 1.21 | |
| `ControllerManagerLeaderMigration` | `false` | 알파 | 1.21 | |
| `CPUManager` | `false` | 알파 | 1.8 | 1.9 |
| `CPUManager` | `true` | 베타 | 1.10 | |
| `CPUManagerPolicyOptions` | `false` | 알파 | 1.22 | |
| `CSIInlineVolume` | `false` | 알파 | 1.15 | 1.15 |
| `CSIInlineVolume` | `true` | 베타 | 1.16 | - |
| `CSIMigration` | `false` | 알파 | 1.14 | 1.16 |
| `CSIMigration` | `true` | 베타 | 1.17 | |
| `CSIMigrationAWS` | `false` | 알파 | 1.14 | |
| `CSIMigrationAWS` | `false` | 베타 | 1.17 | |
| `CSIMigrationAWSComplete` | `false` | 알파 | 1.17 | |
| `CSIMigrationAzureDisk` | `false` | 알파 | 1.15 | 1.18 |
| `CSIMigrationAzureDisk` | `false` | 베타 | 1.19 | |
| `CSIMigrationAzureDiskComplete` | `false` | 알파 | 1.17 | |
| `CSIMigrationAzureFile` | `false` | 알파 | 1.15 | 1.19 |
| `CSIMigrationAzureFile` | `false` | 베타 | 1.21 | |
| `CSIMigrationAzureFileComplete` | `false` | 알파 | 1.17 | |
| `CSIMigrationGCE` | `false` | 알파 | 1.14 | 1.16 |
| `CSIMigrationGCE` | `false` | 베타 | 1.17 | |
| `CSIMigrationGCEComplete` | `false` | 알파 | 1.17 | |
| `CSIMigrationOpenStack` | `false` | 알파 | 1.14 | 1.17 |
| `CSIMigrationOpenStack` | `true` | 베타 | 1.18 | |
| `CSIMigrationOpenStackComplete` | `false` | 알파 | 1.17 | |
| `CSIMigrationvSphere` | `false` | 베타 | 1.19 | |
| `CSIMigrationvSphereComplete` | `false` | 베타 | 1.19 | |
| `CSIServiceAccountToken` | `false` | 알파 | 1.20 | 1.20 |
| `CSIServiceAccountToken` | `true` | 베타 | 1.21 | |
| `CSIStorageCapacity` | `false` | 알파 | 1.19 | 1.20 |
| `CSIStorageCapacity` | `true` | 베타 | 1.21 | |
| `CSIVolumeFSGroupPolicy` | `false` | 알파 | 1.19 | 1.19 |
| `CSIVolumeFSGroupPolicy` | `true` | 베타 | 1.20 | |
| `CSIVolumeHealth` | `false` | 알파 | 1.21 | |
| `CSRDuration` | `true` | 베타 | 1.22 | |
| `ConfigurableFSGroupPolicy` | `false` | 알파 | 1.18 | 1.19 |
| `ConfigurableFSGroupPolicy` | `true` | 베타 | 1.20 | |
| `CronJobControllerV2` | `false` | 알파 | 1.20 | 1.20 |
| `CronJobControllerV2` | `true` | 베타 | 1.21 | |
| `ControllerManagerLeaderMigration` | `false` | 알파 | 1.21 | 1.21 |
| `ControllerManagerLeaderMigration` | `true` | 베타 | 1.22 | |
| `CustomCPUCFSQuotaPeriod` | `false` | 알파 | 1.12 | |
| `DaemonSetUpdateSurge` | `false` | 알파 | 1.21 | 1.21 |
| `DaemonSetUpdateSurge` | `true` | 베타 | 1.22 | |
| `DefaultPodTopologySpread` | `false` | 알파 | 1.19 | 1.19 |
| `DefaultPodTopologySpread` | `true` | 베타 | 1.20 | |
| `DelegateFSGroupToCSIDriver` | `false` | 알파 | 1.22 | |
| `DevicePlugins` | `false` | 알파 | 1.8 | 1.9 |
| `DevicePlugins` | `true` | 베타 | 1.10 | |
| `DisableAcceleratorUsageMetrics` | `false` | 알파 | 1.19 | 1.19 |
| `DisableAcceleratorUsageMetrics` | `true` | 베타 | 1.20 | |
| `DisableCloudProviders` | `false` | 알파 | 1.22 | |
| `DownwardAPIHugePages` | `false` | 알파 | 1.20 | 1.20 |
| `DownwardAPIHugePages` | `false` | 베타 | 1.21 | |
| `DynamicKubeletConfig` | `false` | 알파 | 1.4 | 1.10 |
| `DynamicKubeletConfig` | `true` | 베타 | 1.11 | |
| `EfficientWatchResumption` | `false` | 알파 | 1.20 | |
| `EndpointSliceProxying` | `false` | 알파 | 1.18 | 1.18 |
| `EndpointSliceProxying` | `true` | 베타 | 1.19 | |
| `EndpointSliceTerminatingCondition` | `false` | 알파 | 1.20 | |
| `EfficientWatchResumption` | `false` | 알파 | 1.20 | 1.20 |
| `EfficientWatchResumption` | `true` | 베타 | 1.21 | |
| `EndpointSliceTerminatingCondition` | `false` | 알파 | 1.20 | 1.21 |
| `EndpointSliceTerminatingCondition` | `true` | 베타 | 1.22 | |
| `EphemeralContainers` | `false` | 알파 | 1.16 | |
| `ExpandCSIVolumes` | `false` | 알파 | 1.14 | 1.15 |
| `ExpandCSIVolumes` | `true` | 베타 | 1.16 | |
| `ExpandedDNSConfig` | `false` | 알파 | 1.22 | |
| `ExpandInUsePersistentVolumes` | `false` | 알파 | 1.11 | 1.14 |
| `ExpandInUsePersistentVolumes` | `true` | 베타 | 1.15 | |
| `ExpandPersistentVolumes` | `false` | 알파 | 1.8 | 1.10 |
@@ -125,70 +123,83 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `GracefulNodeShutdown` | `true` | 베타 | 1.21 | |
| `HPAContainerMetrics` | `false` | 알파 | 1.20 | |
| `HPAScaleToZero` | `false` | 알파 | 1.16 | |
| `HugePageStorageMediumSize` | `false` | 알파 | 1.18 | 1.18 |
| `HugePageStorageMediumSize` | `true` | 베타 | 1.19 | |
| `IndexedJob` | `false` | 알파 | 1.21 | |
| `IngressClassNamespacedParams` | `false` | 알파 | 1.21 | |
| `IndexedJob` | `false` | 알파 | 1.21 | 1.21 |
| `IndexedJob` | `true` | 베타 | 1.22 | |
| `JobTrackingWithFinalizers` | `false` | 알파 | 1.22 | |
| `IngressClassNamespacedParams` | `false` | 알파 | 1.21 | 1.21 |
| `IngressClassNamespacedParams` | `true` | 베타 | 1.22 | |
| `InTreePluginAWSUnregister` | `false` | 알파 | 1.21 | |
| `InTreePluginAzureDiskUnregister` | `false` | 알파 | 1.21 | |
| `InTreePluginAzureFileUnregister` | `false` | 알파 | 1.21 | |
| `InTreePluginGCEUnregister` | `false` | 알파 | 1.21 | |
| `InTreePluginOpenStackUnregister` | `false` | 알파 | 1.21 | |
| `InTreePluginvSphereUnregister` | `false` | 알파 | 1.21 | |
| `IPv6DualStack` | `false` | 알파 | 1.15 | 1.20 |
| `IPv6DualStack` | `true` | 베타 | 1.21 | |
| `JobTrackingWithFinalizers` | `false` | 알파 | 1.22 | |
| `KubeletCredentialProviders` | `false` | 알파 | 1.20 | |
| `LegacyNodeRoleBehavior` | `false` | 알파 | 1.16 | 1.18 |
| `LegacyNodeRoleBehavior` | `true` | 베타 | 1.19 | 1.20 |
| `LocalStorageCapacityIsolation` | `false` | 알파 | 1.7 | 1.9 |
| `LocalStorageCapacityIsolation` | `true` | 베타 | 1.10 | |
| `LocalStorageCapacityIsolationFSQuotaMonitoring` | `false` | 알파 | 1.15 | |
| `LogarithmicScaleDown` | `false` | 알파 | 1.21 | |
| `LogarithmicScaleDown` | `false` | 알파 | 1.21 | 1.21 |
| `LogarithmicScaleDown` | `true` | 베타 | 1.22 | |
| `KubeletInUserNamespace` | `false` | 알파 | 1.22 | |
| `KubeletPodResourcesGetAllocatable` | `false` | 알파 | 1.21 | |
| `MemoryManager` | `false` | 알파 | 1.21 | 1.21 |
| `MemoryManager` | `true` | 베타 | 1.22 | |
| `MemoryQoS` | `false` | 알파 | 1.22 | |
| `MixedProtocolLBService` | `false` | 알파 | 1.20 | |
| `NamespaceDefaultLabelName` | `true` | 베타 | 1.21 | |
| `NetworkPolicyEndPort` | `false` | 알파 | 1.21 | |
| `NodeDisruptionExclusion` | `false` | 알파 | 1.16 | 1.18 |
| `NodeDisruptionExclusion` | `true` | 베타 | 1.19 | 1.20 |
| `NetworkPolicyEndPort` | `false` | 알파 | 1.21 | 1.21 |
| `NetworkPolicyEndPort` | `true` | 베타 | 1.22 | |
| `NodeSwap` | `false` | 알파 | 1.22 | |
| `NonPreemptingPriority` | `false` | 알파 | 1.15 | 1.18 |
| `NonPreemptingPriority` | `true` | 베타 | 1.19 | |
| `PodDeletionCost` | `false` | 알파 | 1.21 | |
| `PodAffinityNamespaceSelector` | `false` | 알파 | 1.21 | |
| `PodDeletionCost` | `false` | 알파 | 1.21 | 1.21 |
| `PodDeletionCost` | `true` | 베타 | 1.22 | |
| `PodAffinityNamespaceSelector` | `false` | 알파 | 1.21 | 1.21 |
| `PodAffinityNamespaceSelector` | `true` | 베타 | 1.22 | |
| `PodOverhead` | `false` | 알파 | 1.16 | 1.17 |
| `PodOverhead` | `true` | 베타 | 1.18 | |
| `ProbeTerminationGracePeriod` | `false` | 알파 | 1.21 | |
| `PodSecurity` | `false` | 알파 | 1.22 | |
| `PreferNominatedNode` | `false` | 알파 | 1.21 | 1.21 |
| `PreferNominatedNode` | `true` | 베타 | 1.22 | |
| `ProbeTerminationGracePeriod` | `false` | 알파 | 1.21 | 1.21 |
| `ProbeTerminationGracePeriod` | `false` | 베타 | 1.22 | |
| `ProxyTerminatingEndpoints` | `false` | 알파 | 1.22 | |
| `ProcMountType` | `false` | 알파 | 1.12 | |
| `QOSReserved` | `false` | 알파 | 1.11 | |
| `ReadWriteOncePod` | `false` | 알파 | 1.22 | |
| `RemainingItemCount` | `false` | 알파 | 1.15 | 1.15 |
| `RemainingItemCount` | `true` | 베타 | 1.16 | |
| `RemoveSelfLink` | `false` | 알파 | 1.16 | 1.19 |
| `RemoveSelfLink` | `true` | 베타 | 1.20 | |
| `RotateKubeletServerCertificate` | `false` | 알파 | 1.7 | 1.11 |
| `RotateKubeletServerCertificate` | `true` | 베타 | 1.12 | |
| `RunAsGroup` | `true` | 베타 | 1.14 | |
| `ServerSideApply` | `false` | 알파 | 1.14 | 1.15 |
| `ServerSideApply` | `true` | 베타 | 1.16 | |
| `ServiceInternalTrafficPolicy` | `false` | 알파 | 1.21 | |
| `ServiceLBNodePortControl` | `false` | 알파 | 1.20 | |
| `ServiceLoadBalancerClass` | `false` | 알파 | 1.21 | |
| `ServiceNodeExclusion` | `false` | 알파 | 1.8 | 1.18 |
| `ServiceNodeExclusion` | `true` | 베타 | 1.19 | 1.20 |
| `ServiceTopology` | `false` | 알파 | 1.17 | |
| `SetHostnameAsFQDN` | `false` | 알파 | 1.19 | 1.19 |
| `SetHostnameAsFQDN` | `true` | 베타 | 1.20 | |
| `SizeMemoryBackedVolumes` | `false` | 알파 | 1.20 | |
| `SeccompDefault` | `false` | 알파 | 1.22 | |
| `ServiceInternalTrafficPolicy` | `false` | 알파 | 1.21 | 1.21 |
| `ServiceInternalTrafficPolicy` | `true` | 베타 | 1.22 | |
| `ServiceLBNodePortControl` | `false` | 알파 | 1.20 | 1.21 |
| `ServiceLBNodePortControl` | `true` | 베타 | 1.22 | |
| `ServiceLoadBalancerClass` | `false` | 알파 | 1.21 | 1.21 |
| `ServiceLoadBalancerClass` | `true` | 베타 | 1.22 | |
| `SizeMemoryBackedVolumes` | `false` | 알파 | 1.20 | 1.21 |
| `SizeMemoryBackedVolumes` | `true` | 베타 | 1.22 | |
| `StatefulSetMinReadySeconds` | `false` | 알파 | 1.22 | |
| `StorageVersionAPI` | `false` | 알파 | 1.20 | |
| `StorageVersionHash` | `false` | 알파 | 1.14 | 1.14 |
| `StorageVersionHash` | `true` | 베타 | 1.15 | |
| `SuspendJob` | `false` | 알파 | 1.21 | |
| `SuspendJob` | `false` | 알파 | 1.21 | 1.21 |
| `SuspendJob` | `true` | 베타 | 1.22 | |
| `TTLAfterFinished` | `false` | 알파 | 1.12 | 1.20 |
| `TTLAfterFinished` | `true` | 베타 | 1.21 | |
| `TopologyAwareHints` | `false` | 알파 | 1.21 | |
| `TopologyManager` | `false` | 알파 | 1.16 | 1.17 |
| `TopologyManager` | `true` | 베타 | 1.18 | |
| `ValidateProxyRedirects` | `false` | 알파 | 1.12 | 1.13 |
| `ValidateProxyRedirects` | `true` | 베타 | 1.14 | |
| `VolumeCapacityPriority` | `false` | 알파 | 1.21 | - |
| `WarningHeaders` | `true` | 베타 | 1.19 | |
| `WinDSR` | `false` | 알파 | 1.14 | |
| `WinOverlay` | `false` | 알파 | 1.14 | 1.19 |
| `WinOverlay` | `true` | 베타 | 1.20 | |
| `WindowsEndpointSliceProxying` | `false` | 알파 | 1.19 | 1.20 |
| `WindowsEndpointSliceProxying` | `true` | 베타 | 1.21 | |
| `WindowsHostProcessContainers` | `false` | 알파 | 1.22 | |
{{< /table >}}
### GA 또는 사용 중단된 기능을 위한 기능 게이트
@@ -206,9 +217,17 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `AffinityInAnnotations` | - | 사용중단 | 1.8 | - |
| `AllowExtTrafficLocalEndpoints` | `false` | 베타 | 1.4 | 1.6 |
| `AllowExtTrafficLocalEndpoints` | `true` | GA | 1.7 | - |
| `AttachVolumeLimit` | `false` | 알파 | 1.11 | 1.11 |
| `AttachVolumeLimit` | `true` | 베타 | 1.12 | 1.16 |
| `AttachVolumeLimit` | `true` | GA | 1.17 | - |
| `BalanceAttachedNodeVolumes` | `false` | 알파 | 1.11 | 1.21 |
| `BalanceAttachedNodeVolumes` | `false` | 사용중단 | 1.22 | |
| `BlockVolume` | `false` | 알파 | 1.9 | 1.12 |
| `BlockVolume` | `true` | 베타 | 1.13 | 1.17 |
| `BlockVolume` | `true` | GA | 1.18 | - |
| `BoundServiceAccountTokenVolume` | `false` | 알파 | 1.13 | 1.20 |
| `BoundServiceAccountTokenVolume` | `true` | 베타 | 1.21 | 1.21 |
| `BoundServiceAccountTokenVolume` | `true` | GA | 1.22 | - |
| `CRIContainerLogRotation` | `false` | 알파 | 1.10 | 1.10 |
| `CRIContainerLogRotation` | `true` | 베타 | 1.11 | 1.20 |
| `CRIContainerLogRotation` | `true` | GA | 1.21 | - |
@@ -218,15 +237,30 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `CSIDriverRegistry` | `false` | 알파 | 1.12 | 1.13 |
| `CSIDriverRegistry` | `true` | 베타 | 1.14 | 1.17 |
| `CSIDriverRegistry` | `true` | GA | 1.18 | |
| `CSIMigrationAWSComplete` | `false` | 알파 | 1.17 | 1.20 |
| `CSIMigrationAWSComplete` | - | 사용중단 | 1.21 | - |
| `CSIMigrationAzureDiskComplete` | `false` | 알파 | 1.17 | 1.20 |
| `CSIMigrationAzureDiskComplete` | - | 사용중단 | 1.21 | - |
| `CSIMigrationAzureFileComplete` | `false` | 알파 | 1.17 | 1.20 |
| `CSIMigrationAzureFileComplete` | - | 사용중단 | 1.21 | - |
| `CSIMigrationGCEComplete` | `false` | 알파 | 1.17 | 1.20 |
| `CSIMigrationGCEComplete` | - | 사용중단 | 1.21 | - |
| `CSIMigrationOpenStackComplete` | `false` | 알파 | 1.17 | 1.20 |
| `CSIMigrationOpenStackComplete` | - | 사용중단 | 1.21 | - |
| `CSIMigrationvSphereComplete` | `false` | 베타 | 1.19 | 1.21 |
| `CSIMigrationvSphereComplete` | - | 사용중단 | 1.22 | - |
| `CSINodeInfo` | `false` | 알파 | 1.12 | 1.13 |
| `CSINodeInfo` | `true` | 베타 | 1.14 | 1.16 |
| `CSINodeInfo` | `true` | GA | 1.17 | |
| `AttachVolumeLimit` | `false` | 알파 | 1.11 | 1.11 |
| `AttachVolumeLimit` | `true` | 베타 | 1.12 | 1.16 |
| `AttachVolumeLimit` | `true` | GA | 1.17 | - |
| `CSIPersistentVolume` | `false` | 알파 | 1.9 | 1.9 |
| `CSIPersistentVolume` | `true` | 베타 | 1.10 | 1.12 |
| `CSIPersistentVolume` | `true` | GA | 1.13 | - |
| `CSIServiceAccountToken` | `false` | 알파 | 1.20 | 1.20 |
| `CSIServiceAccountToken` | `true` | 베타 | 1.21 | 1.21 |
| `CSIServiceAccountToken` | `true` | GA | 1.22 | |
| `CronJobControllerV2` | `false` | 알파 | 1.20 | 1.20 |
| `CronJobControllerV2` | `true` | 베타 | 1.21 | 1.21 |
| `CronJobControllerV2` | `true` | GA | 1.22 | - |
| `CustomPodDNS` | `false` | 알파 | 1.9 | 1.9 |
| `CustomPodDNS` | `true` | 베타| 1.10 | 1.13 |
| `CustomPodDNS` | `true` | GA | 1.14 | - |
@@ -250,8 +284,14 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `DryRun` | `true` | GA | 1.19 | - |
| `DynamicAuditing` | `false` | 알파 | 1.13 | 1.18 |
| `DynamicAuditing` | - | 사용중단 | 1.19 | - |
| `DynamicKubeletConfig` | `false` | 알파 | 1.4 | 1.10 |
| `DynamicKubeletConfig` | `true` | 베타 | 1.11 | 1.21 |
| `DynamicKubeletConfig` | `false` | 사용중단 | 1.22 | - |
| `DynamicProvisioningScheduling` | `false` | 알파 | 1.11 | 1.11 |
| `DynamicProvisioningScheduling` | - | 사용중단| 1.12 | - |
| `DynamicKubeletConfig` | `false` | 알파 | 1.4 | 1.10 |
| `DynamicKubeletConfig` | `true` | 베타 | 1.11 | 1.21 |
| `DynamicKubeletConfig` | `false` | 사용중단 | 1.22 | - |
| `DynamicVolumeProvisioning` | `true` | 알파 | 1.3 | 1.7 |
| `DynamicVolumeProvisioning` | `true` | GA | 1.8 | - |
| `EnableAggregatedDiscoveryTimeout` | `true` | 사용중단 | 1.16 | - |
@@ -263,6 +303,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `EndpointSlice` | `true` | GA | 1.21 | - |
| `EndpointSliceNodeName` | `false` | 알파 | 1.20 | 1.20 |
| `EndpointSliceNodeName` | `true` | GA | 1.21 | - |
| `EndpointSliceProxying` | `false` | 알파 | 1.18 | 1.18 |
| `EndpointSliceProxying` | `true` | 베타 | 1.19 | 1.21 |
| `EndpointSliceProxying` | `true` | GA | 1.22 | - |
| `ExperimentalCriticalPodAnnotation` | `false` | 알파 | 1.5 | 1.12 |
| `ExperimentalCriticalPodAnnotation` | `false` | 사용중단 | 1.13 | - |
| `EvenPodsSpread` | `false` | 알파 | 1.16 | 1.17 |
@@ -272,9 +315,15 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `ExternalPolicyForExternalIP` | `true` | GA | 1.18 | - |
| `GCERegionalPersistentDisk` | `true` | 베타 | 1.10 | 1.12 |
| `GCERegionalPersistentDisk` | `true` | GA | 1.13 | - |
| `HugePageStorageMediumSize` | `false` | 알파 | 1.18 | 1.18 |
| `HugePageStorageMediumSize` | `true` | 베타 | 1.19 | 1.21 |
| `HugePageStorageMediumSize` | `true` | GA | 1.22 | - |
| `HugePages` | `false` | 알파 | 1.8 | 1.9 |
| `HugePages` | `true` | 베타| 1.10 | 1.13 |
| `HugePages` | `true` | GA | 1.14 | - |
| `HugePageStorageMediumSize` | `false` | 알파 | 1.18 | 1.18 |
| `HugePageStorageMediumSize` | `true` | 베타 | 1.19 | 1.21 |
| `HugePageStorageMediumSize` | `true` | GA | 1.22 | - |
| `HyperVContainer` | `false` | 알파 | 1.10 | 1.19 |
| `HyperVContainer` | `false` | 사용중단 | 1.20 | - |
| `ImmutableEphemeralVolumes` | `false` | 알파 | 1.18 | 1.18 |
@@ -290,16 +339,22 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `KubeletPodResources` | `false` | 알파 | 1.13 | 1.14 |
| `KubeletPodResources` | `true` | 베타 | 1.15 | |
| `KubeletPodResources` | `true` | GA | 1.20 | |
| `LegacyNodeRoleBehavior` | `false` | 알파 | 1.16 | 1.18 |
| `LegacyNodeRoleBehavior` | `true` | 베타 | 1.19 | 1.20 |
| `LegacyNodeRoleBehavior` | `false` | GA | 1.21 | - |
| `MountContainers` | `false` | 알파 | 1.9 | 1.16 |
| `MountContainers` | `false` | 사용중단 | 1.17 | - |
| `MountPropagation` | `false` | 알파 | 1.8 | 1.9 |
| `MountPropagation` | `true` | 베타 | 1.10 | 1.11 |
| `MountPropagation` | `true` | GA | 1.12 | - |
| `NodeDisruptionExclusion` | `false` | 알파 | 1.16 | 1.18 |
| `NodeDisruptionExclusion` | `true` | 베타 | 1.19 | 1.20 |
| `NodeDisruptionExclusion` | `true` | GA | 1.21 | - |
| `NodeLease` | `false` | 알파 | 1.12 | 1.13 |
| `NodeLease` | `true` | 베타 | 1.14 | 1.16 |
| `NodeLease` | `true` | GA | 1.17 | - |
| `NamespaceDefaultLabelName` | `true` | 베타 | 1.21 | 1.21 |
| `NamespaceDefaultLabelName` | `true` | GA | 1.22 | - |
| `PVCProtection` | `false` | 알파 | 1.9 | 1.9 |
| `PVCProtection` | - | 사용중단 | 1.10 | - |
| `PersistentLocalVolumes` | `false` | 알파 | 1.7 | 1.9 |
@@ -329,15 +384,23 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `RootCAConfigMap` | `true` | GA | 1.21 | - |
| `RotateKubeletClientCertificate` | `true` | 베타 | 1.8 | 1.18 |
| `RotateKubeletClientCertificate` | `true` | GA | 1.19 | - |
| `RunAsGroup` | `true` | 베타 | 1.14 | 1.20 |
| `RunAsGroup` | `true` | GA | 1.21 | - |
| `RuntimeClass` | `false` | 알파 | 1.12 | 1.13 |
| `RuntimeClass` | `true` | 베타 | 1.14 | 1.19 |
| `RuntimeClass` | `true` | GA | 1.20 | - |
| `ScheduleDaemonSetPods` | `false` | 알파 | 1.11 | 1.11 |
| `ScheduleDaemonSetPods` | `true` | 베타 | 1.12 | 1.16 |
| `ScheduleDaemonSetPods` | `true` | GA | 1.17 | - |
| `SCTPSupport` | `false` | 알파 | 1.12 | 1.18 |
| `SCTPSupport` | `true` | 베타 | 1.19 | 1.19 |
| `SCTPSupport` | `true` | GA | 1.20 | - |
| `ScheduleDaemonSetPods` | `false` | 알파 | 1.11 | 1.11 |
| `ScheduleDaemonSetPods` | `true` | 베타 | 1.12 | 1.16 |
| `ScheduleDaemonSetPods` | `true` | GA | 1.17 | - |
| `SelectorIndex` | `false` | 알파 | 1.18 | 1.18 |
| `SelectorIndex` | `true` | 베타 | 1.19 | 1.19 |
| `SelectorIndex` | `true` | GA | 1.20 | - |
| `ServerSideApply` | `false` | 알파 | 1.14 | 1.15 |
| `ServerSideApply` | `true` | 베타 | 1.16 | 1.21 |
| `ServerSideApply` | `true` | GA | 1.22 | - |
| `ServiceAccountIssuerDiscovery` | `false` | 알파 | 1.18 | 1.19 |
| `ServiceAccountIssuerDiscovery` | `true` | 베타 | 1.20 | 1.20 |
| `ServiceAccountIssuerDiscovery` | `true` | GA | 1.21 | - |
@@ -347,15 +410,23 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `ServiceLoadBalancerFinalizer` | `false` | 알파 | 1.15 | 1.15 |
| `ServiceLoadBalancerFinalizer` | `true` | 베타 | 1.16 | 1.16 |
| `ServiceLoadBalancerFinalizer` | `true` | GA | 1.17 | - |
| `ServiceNodeExclusion` | `false` | 알파 | 1.8 | 1.18 |
| `ServiceNodeExclusion` | `true` | 베타 | 1.19 | 1.20 |
| `ServiceNodeExclusion` | `true` | GA | 1.21 | - |
| `ServiceTopology` | `false` | 알파 | 1.17 | 1.19 |
| `ServiceTopology` | `false` | 사용중단 | 1.20 | - |
| `SetHostnameAsFQDN` | `false` | 알파 | 1.19 | 1.19 |
| `SetHostnameAsFQDN` | `true` | 베타 | 1.20 | 1.21 |
| `SetHostnameAsFQDN` | `true` | GA | 1.22 | - |
| `StartupProbe` | `false` | 알파 | 1.16 | 1.17 |
| `StartupProbe` | `true` | 베타 | 1.18 | 1.19 |
| `StartupProbe` | `true` | GA | 1.20 | - |
| `StorageObjectInUseProtection` | `true` | 베타 | 1.10 | 1.10 |
| `StorageObjectInUseProtection` | `true` | GA | 1.11 | - |
| `StreamingProxyRedirects` | `false` | 베타 | 1.5 | 1.5 |
| `StreamingProxyRedirects` | `true` | 베타 | 1.6 | 1.18 |
| `StreamingProxyRedirects` | - | GA | 1.19 | - |
| `StreamingProxyRedirects` | `true` | 베타 | 1.6 | 1.17 |
| `StreamingProxyRedirects` | `true` | 사용중단 | 1.18 | 1.21 |
| `StreamingProxyRedirects` | `false` | 사용중단 | 1.22 | - |
| `SupportIPVSProxyMode` | `false` | 알파 | 1.8 | 1.8 |
| `SupportIPVSProxyMode` | `false` | 베타 | 1.9 | 1.9 |
| `SupportIPVSProxyMode` | `true` | 베타 | 1.10 | 1.10 |
@@ -380,6 +451,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `TokenRequestProjection` | `false` | 알파 | 1.11 | 1.11 |
| `TokenRequestProjection` | `true` | 베타 | 1.12 | 1.19 |
| `TokenRequestProjection` | `true` | GA | 1.20 | - |
| `ValidateProxyRedirects` | `false` | 알파 | 1.12 | 1.13 |
| `ValidateProxyRedirects` | `true` | 베타 | 1.14 | 1.21 |
| `ValidateProxyRedirects` | `true` | 사용중단 | 1.22 | - |
| `VolumePVCDataSource` | `false` | 알파 | 1.15 | 1.15 |
| `VolumePVCDataSource` | `true` | 베타 | 1.16 | 1.17 |
| `VolumePVCDataSource` | `true` | GA | 1.18 | - |
@@ -393,12 +467,18 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `VolumeSubpathEnvExpansion` | `false` | 알파 | 1.14 | 1.14 |
| `VolumeSubpathEnvExpansion` | `true` | 베타 | 1.15 | 1.16 |
| `VolumeSubpathEnvExpansion` | `true` | GA | 1.17 | - |
| `WarningHeaders` | `true` | 베타 | 1.19 | 1.21 |
| `WarningHeaders` | `true` | GA | 1.22 | - |
| `WatchBookmark` | `false` | 알파 | 1.15 | 1.15 |
| `WatchBookmark` | `true` | 베타 | 1.16 | 1.16 |
| `WatchBookmark` | `true` | GA | 1.17 | - |
| `WindowsEndpointSliceProxying` | `false` | 알파 | 1.19 | 1.20 |
| `WindowsEndpointSliceProxying` | `true` | 베타 | 1.21 | 1.21 |
| `WindowsEndpointSliceProxying` | `true` | GA | 1.22| - |
| `WindowsGMSA` | `false` | 알파 | 1.14 | 1.15 |
| `WindowsGMSA` | `true` | 베타 | 1.16 | 1.17 |
| `WindowsGMSA` | `true` | GA | 1.18 | - |
| `WindowsHostProcessContainers` | `false` | 알파 | 1.22 |
| `WindowsRunAsUserName` | `false` | 알파 | 1.16 | 1.16 |
| `WindowsRunAsUserName` | `true` | 베타 | 1.17 | 1.17 |
| `WindowsRunAsUserName` | `true` | GA | 1.18 | - |
@@ -453,6 +533,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
관리할 수 있다. (`RequestManagement` 에서 이름이 변경됨)
- `APIResponseCompression`: `LIST` 또는 `GET` 요청에 대한 API 응답을 압축한다.
- `APIServerIdentity`: 클러스터의 각 API 서버에 ID를 할당한다.
- `APIServerTracing`: API 서버에서 분산 추적(tracing)에 대한 지원을 추가한다.
- `Accelerators`: 도커 사용 시 Nvidia GPU 지원 활성화한다.
- `AdvancedAuditing`: [고급 감사](/docs/tasks/debug-application-cluster/audit/#advanced-audit) 기능을 활성화한다.
- `AffinityInAnnotations`: [파드 어피니티 또는 안티-어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#어피니티-affinity-와-안티-어피니티-anti-affinity)
@@ -486,6 +567,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
리더 마이그레이션(Leader Migration)을 활성화한다.
- `CPUManager`: 컨테이너 수준의 CPU 어피니티 지원을 활성화한다.
[CPU 관리 정책](/docs/tasks/administer-cluster/cpu-management-policies/)을 참고한다.
- `CPUManagerPolicyOptions`: CPUManager 정책의 미세 조정을 허용한다.
- `CRIContainerLogRotation`: cri 컨테이너 런타임에 컨테이너 로그 로테이션을 활성화한다. 로그 파일 사이즈 기본값은 10MB이며,
컨테이너 당 최대 로그 파일 수 기본값은 5이다. 이 값은 kubelet 환경설정으로 변경할 수 있다.
더 자세한 내용은 [노드 레벨에서의 로깅](/ko/docs/concepts/cluster-administration/logging/#노드-레벨에서의-로깅)을 참고한다.
@@ -506,6 +588,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
인-트리 플러그인에서 EBS CSI 플러그인으로 라우팅할 수 있다.
클러스터의 모든 노드에 CSIMigration과 CSIMigrationAWS 기능 플래그가 활성화되고
EBS CSI 플러그인이 설치 및 구성이 되어 있어야 한다.
이 플래그는 인-트리 EBS 플러그인의 등록을 막는 `InTreePluginAWSUnregister` 기능 플래그로 인해
더 이상 사용되지 않는다.
- `CSIMigrationAzureDisk`: shim 및 변환 로직을 통해 볼륨 작업을
Azure-Disk 인-트리 플러그인에서 AzureDisk CSI 플러그인으로 라우팅할 수 있다.
노드에 AzureDisk CSI 플러그인이 설치와 구성이 되어 있지 않은 경우 인-트리
@@ -516,7 +600,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
Azure-Disk 인-트리 플러그인에서 AzureDisk CSI 플러그인으로
라우팅할 수 있다. 클러스터의 모든 노드에 CSIMigration과 CSIMigrationAzureDisk 기능
플래그가 활성화되고 AzureDisk CSI 플러그인이 설치 및 구성이 되어
있어야 한다.
있어야 한다. 이 플래그는 인-트리 AzureDisk 플러그인의 등록을 막는 `InTreePluginAzureDiskUnregister` 기능 플래그로 인해
더 이상 사용되지 않는다.
- `CSIMigrationAzureFile`: shim 및 변환 로직을 통해 볼륨 작업을
Azure-File 인-트리 플러그인에서 AzureFile CSI 플러그인으로 라우팅할 수 있다.
노드에 AzureFile CSI 플러그인이 설치 및 구성이 되어 있지 않은 경우 인-트리
@@ -527,7 +612,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
Azure 파일 인-트리 플러그인에서 AzureFile CSI 플러그인으로
라우팅할 수 있다. 클러스터의 모든 노드에 CSIMigration과 CSIMigrationAzureFile 기능
플래그가 활성화되고 AzureFile CSI 플러그인이 설치 및 구성이 되어
있어야 한다.
있어야 한다. 이 플래그는 인-트리 AzureFile 플러그인의 등록을 막는
`InTreePluginAzureFileUnregister` 기능 플래그로 인해
더 이상 사용되지 않는다.
- `CSIMigrationGCE`: shim 및 변환 로직을 통해 볼륨 작업을
GCE-PD 인-트리 플러그인에서 PD CSI 플러그인으로 라우팅할 수 있다. 노드에
PD CSI 플러그인이 설치 및 구성이 되어 있지 않은 경우 인-트리 GCE 플러그인으로 폴백을
@@ -536,7 +623,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
인-트리 플러그인 등록을 중지하고 shim 및 변환 로직을 통해 볼륨 작업을 GCE-PD
인-트리 플러그인에서 PD CSI 플러그인으로 라우팅할 수 있다.
CSIMigration과 CSIMigrationGCE 기능 플래그가 활성화되고 PD CSI
플러그인이 클러스터의 모든 노드에 설치 및 구성이 되어 있어야 한다.
플러그인이 클러스터의 모든 노드에 설치 및 구성이 되어 있어야 한다. 이 플래그는 인-트리 GCE PD 플러그인의 등록을 막는 `InTreePluginGCEUnregister` 기능 플래그로 인해
더 이상 사용되지 않는다.
- `CSIMigrationOpenStack`: shim 및 변환 로직을 통해 볼륨 작업을
Cinder 인-트리 플러그인에서 Cinder CSI 플러그인으로 라우팅할 수 있다. 노드에
Cinder CSI 플러그인이 설치 및 구성이 되어 있지 않은 경우 인-트리
@@ -545,7 +633,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
Cinder 인-트리 플러그인 등록을 중지하고 shim 및 변환 로직이 Cinder 인-트리
플러그인에서 Cinder CSI 플러그인으로 볼륨 작업을 라우팅할 수 있도록 한다.
클러스터의 모든 노드에 CSIMigration과 CSIMigrationOpenStack 기능 플래그가 활성화되고
Cinder CSI 플러그인이 설치 및 구성이 되어 있어야 한다.
Cinder CSI 플러그인이 설치 및 구성이 되어 있어야 한다. 이 플래그는 인-트리 openstack cinder 플러그인의 등록을 막는 `InTreePluginOpenStackUnregister` 기능 플래그로 인해
더 이상 사용되지 않는다.
- `CSIMigrationvSphere`: vSphere 인-트리 플러그인에서 vSphere CSI 플러그인으로 볼륨 작업을
라우팅하는 shim 및 변환 로직을 사용한다.
노드에 vSphere CSI 플러그인이 설치 및 구성이 되어 있지 않은 경우
@@ -554,7 +643,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
플러그인 등록을 중지하고 shim 및 변환 로직을 활성화하여 vSphere 인-트리 플러그인에서
vSphere CSI 플러그인으로 볼륨 작업을 라우팅할 수 있도록 한다. CSIMigration 및
CSIMigrationvSphere 기능 플래그가 활성화되고 vSphere CSI 플러그인이
클러스터의 모든 노드에 설치 및 구성이 되어 있어야 한다.
클러스터의 모든 노드에 설치 및 구성이 되어 있어야 한다. 이 플래그는 인-트리 vsphere 플러그인의 등록을 막는 `InTreePluginvSphereUnregister` 기능 플래그로 인해
더 이상 사용되지 않는다.
- `CSINodeInfo`: csi.storage.k8s.io에서 CSINodeInfo API 오브젝트와 관련된 모든 로직을 활성화한다.
- `CSIPersistentVolume`: [CSI (Container Storage Interface)](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md)
호환 볼륨 플러그인을 통해 프로비저닝된 볼륨을 감지하고
@@ -570,14 +660,17 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
이 필드는 CSI드라이버에서 생성된 볼륨이 마운트될 때 볼륨 소유권과
권한 수정을 지원하는지 여부를 제어한다.
- `CSIVolumeHealth`: 노드에서의 CSI 볼륨 상태 모니터링 기능을 활성화한다.
- `CSRDuration`: 클라이언트가 쿠버네티스 CSR API를 통해 발급된 인증서의 기간을
요청할 수 있다.
- `ConfigurableFSGroupPolicy`: 사용자가 파드에 볼륨을 마운트할 때 fsGroups에 대한
볼륨 권한 변경 정책을 구성할 수 있다. 자세한 내용은
[파드의 볼륨 권한 및 소유권 변경 정책 구성](/docs/tasks/configure-pod-container/security-context/#configure-volume-permission-and-ownership-change-policy-for-pods)을
참고한다.
- `ControllerManagerLeaderMigration`: `kube-controller-manager` 및 `cloud-controller-manager`에
대한 리더 마이그레이션을 지원한다.
- `CronJobControllerV2`: {{< glossary_tooltip text="크론잡(CronJob)" term_id="cronjob" >}}
컨트롤러의 대체 구현을 사용한다. 그렇지 않으면,
동일한 컨트롤러의 버전 1이 선택된다.
버전 2 컨트롤러는 실험적인 성능 향상을 제공한다.
- `CustomCPUCFSQuotaPeriod`: [kubelet config](/docs/tasks/administer-cluster/kubelet-config-file/)에서
`cpuCFSQuotaPeriod` 를 노드가 변경할 수 있도록 한다.
- `CustomPodDNS`: `dnsConfig` 속성을 사용하여 파드의 DNS 설정을 사용자 정의할 수 있다.
@@ -591,12 +684,20 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
생성된 리소스에서 스키마 기반 유효성 검사를 활성화한다.
- `CustomResourceWebhookConversion`: [커스텀리소스데피니션](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)에서
생성된 리소스에 대해 웹 훅 기반의 변환을 활성화한다.
- `DaemonSetUpdateSurge`: 노드당 업데이트 중 가용성을 유지하도록
데몬셋 워크로드를 사용하도록 설정한다.
- `DefaultPodTopologySpread`: `PodTopologySpread` 스케줄링 플러그인을 사용하여
[기본 분배](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/#내부-기본-제약)를 수행한다.
- `DelegateFSGroupToCSIDriver`: CSI 드라이버가 지원할 경우, NodeStageVolume 및 NodePublishVolume CSI 호출을 통해
`fsGroup`를 전달하여 파드의 `securityContext`에서
`fsGroup`를 드라이브에 적용하는 역할을 위임한다.
- `DevicePlugins`: 노드에서 [장치 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)
기반 리소스 프로비저닝을 활성화한다.
- `DisableAcceleratorUsageMetrics`:
[kubelet이 수집한 액셀러레이터 지표 비활성화](/ko/docs/concepts/cluster-administration/system-metrics/#액셀러레이터-메트릭-비활성화).
- `DisableCloudProviders`: `kube-apiserver`, `kube-controller-manager`,
`--cloud-provider` 컴포넌트 플래그와 관련된 `kubelet`의
모든 기능을 비활성화한다.
- `DownwardAPIHugePages`: [다운워드 API](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information)에서
hugepages 사용을 활성화한다.
- `DryRun`: 서버 측의 [dry run](/docs/reference/using-api/api-concepts/#dry-run) 요청을
@@ -635,6 +736,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
현재 수정된 결함에 의존하는 경우 존재한다.
[준비성 프로브](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#configure-probes)를 참조한다.
- `ExpandCSIVolumes`: CSI 볼륨 확장을 활성화한다.
- `ExpandedDNSConfig`: 더 많은 DNS 검색 경로와 더 긴 DNS 검색 경로 목록을 허용하려면
kubelet과 kube-apiserver를 사용하도록 설정한다.
[확장된 DNS 구성](/docs/concepts/services-networking/dns-pod-service/#expanded-dns-configuration)을 참고한다.
- `ExpandInUsePersistentVolumes`: 사용 중인 PVC를 확장할 수 있다.
[사용 중인 퍼시스턴트볼륨클레임 크기 조정](/ko/docs/concepts/storage/persistent-volumes/#사용-중인-퍼시스턴트볼륨클레임-크기-조정)을 참고한다.
- `ExpandPersistentVolumes`: 퍼시스턴트 볼륨 확장을 활성화한다.
@@ -671,8 +775,24 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
기능을 활성화한다.
- `ImmutableEphemeralVolumes`: 안정성과 성능 향상을 위해 개별 시크릿(Secret)과 컨피그맵(ConfigMap)을
변경할 수 없는(immutable) 것으로 표시할 수 있다.
- `InTreePluginAWSUnregister`: kubelet 및 볼륨 컨트롤러에 aws-ebs 인-트리
플러그인의 등록을 중지한다.
- `InTreePluginAzureDiskUnregister`: kubelet 및 볼륨 컨트롤러에 azuredisk 인-트리
플러그인의 등록을 중지한다.
- `InTreePluginAzureFileUnregister`: kubelet 및 볼륨 컨트롤러에 azurefile 인-트리
플러그인의 등록을 중지한다.
- `InTreePluginGCEUnregister`: kubelet 및 볼륨 컨트롤러에 gce-pd 인-트리
플러그인의 등록을 중지한다.
- `InTreePluginOpenStackUnregister`: kubelet 및 볼륨 컨트롤러에 오픈스택 cinder 인-트리
플러그인의 등록을 중지한다.
- `InTreePluginvSphereUnregister`: kubelet 및 볼륨 컨트롤러에 vSphere 인-트리
플러그인의 등록을 중지한다.
- `IndexedJob`: [잡](/ko/docs/concepts/workloads/controllers/job/) 컨트롤러가
완료 횟수를 기반으로 파드 완료를 관리할 수 있도록 한다.
- `JobTrackingWithFinalizers`: 클러스터에 무제한으로 남아 있는 파드에 의존하지 않고
[잡](/ko/docs/concepts/workloads/controllers/job)의 완료를 추적할 수 있다.
잡 컨트롤러는 완료된 파드를 추적하기 위해
완료된 파드의 잡 상태 필드를 사용한다.
- `IngressClassNamespacedParams`: `IngressClass` 리소스가 네임스페이스 범위로
한정된 파라미터를 이용할 수 있도록 한다. 이 기능은 `IngressClass.spec.parameters` 에
`Scope` 와 `Namespace` 2개의 필드를 추가한다.
@@ -680,11 +800,17 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
비동기 조정을 허용한다.
- `IPv6DualStack`: IPv6을 위한 [이중 스택](/ko/docs/concepts/services-networking/dual-stack/)
기능을 활성화한다.
- `JobTrackingWithFinalizers`: 클러스터에 무제한으로 남아있는 파드에
의존하지 않고 잡 완료를 추적할 수 있다.
파드 finalizers는 잡 상태 필드와
아직 구성되지 않은 파드를 추적할 수 있다.
- `KubeletConfigFile`: 구성 파일을 사용하여 지정된 파일에서
kubelet 구성을 로드할 수 있다.
자세한 내용은 [구성 파일을 통해 kubelet 파라미터 설정](/docs/tasks/administer-cluster/kubelet-config-file/)을
참고한다.
- `KubeletCredentialProviders`: 이미지 풀 자격 증명에 대해 kubelet exec 자격 증명 공급자를 활성화한다.
- `KubeletInUserNamespace`: {{<glossary_tooltip text="user namespace" term_id="userns">}}에서 kubelet 실행을 활성화한다.
[루트가 아닌 유저로 쿠버네티스 노드 컴포넌트 실행](/docs/tasks/administer-cluster/kubelet-in-userns/)을 참고한다.
- `KubeletPluginsWatcher`: kubelet이 [CSI 볼륨 드라이버](/ko/docs/concepts/storage/volumes/#csi)와 같은
플러그인을 검색할 수 있도록 프로브 기반 플러그인 감시자(watcher) 유틸리티를 사용한다.
- `KubeletPodResources`: kubelet의 파드 리소스 gPRC 엔드포인트를 활성화한다. 자세한 내용은
@@ -709,6 +835,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
향상시킨다.
- `LogarithmicScaleDown`: 컨트롤러 스케일 다운 시에 파드 타임스탬프를 로그 스케일로 버켓화하여
축출할 파드를 반-랜덤하게 선택하는 기법을 활성화한다.
- `MemoryManager`: NUMA 토폴로지를 기반으로 컨테이너에 대한
메모리 어피니티를 설정할 수 있다.
- `MemoryQoS`: cgroup v2 메모리 컨트롤러를 사용하여 파드/컨테이너에서 메모리 보호 및 사용 제한을 사용하도록 설정한다.
- `MixedProtocolLBService`: 동일한 로드밸런서 유형 서비스 인스턴스에서 다른 프로토콜
사용을 활성화한다.
- `MountContainers`: 호스트의 유틸리티 컨테이너를 볼륨 마운터로 사용할 수 있다.
@@ -720,6 +849,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
- `NodeDisruptionExclusion`: 영역(zone) 장애 시 노드가 제외되지 않도록 노드 레이블 `node.kubernetes.io/exclude-disruption`
사용을 활성화한다.
- `NodeLease`: 새로운 리스(Lease) API가 노드 상태 신호로 사용될 수 있는 노드 하트비트(heartbeats)를 보고할 수 있게 한다.
- `NodeSwap`: 노드의 쿠버네티스 워크로드용 스왑 메모리를 할당하려면 kubelet을 활성화한다.
반드시 `KubeletConfiguration.failSwapOn`를 false로 설정한 후 사용해야 한다.
더 자세한 정보는 [스왑 메모리](/docs/concepts/architecture/nodes/#swap-memory)를 참고한다.
- `NonPreemptingPriority`: 프라이어리티클래스(PriorityClass)와 파드에 `preemptionPolicy` 필드를 활성화한다.
- `PVCProtection`: 파드에서 사용 중일 때 퍼시스턴트볼륨클레임(PVC)이
삭제되지 않도록 한다.
@@ -737,17 +869,25 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
- `PodReadinessGates`: 파드 준비성 평가를 확장하기 위해
`PodReadinessGate` 필드 설정을 활성화한다. 자세한 내용은 [파드의 준비성 게이트](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-readiness-gate)를
참고한다.
- `PodSecurity`: `PodSecurity` 어드미션 플러그인을 사용하도록 설정한다.
- `PodShareProcessNamespace`: 파드에서 실행되는 컨테이너 간에 단일 프로세스 네임스페이스를
공유하기 위해 파드에서 `shareProcessNamespace` 설정을 활성화한다. 자세한 내용은
[파드의 컨테이너 간 프로세스 네임스페이스 공유](/docs/tasks/configure-pod-container/share-process-namespace/)에서 확인할 수 있다.
- `PreferNominatedNode`: 이 플래그는 클러스터에 존재하는 다른 노드를 반복해서 검사하기 전에
지정된 노드를 먼저 검사할지 여부를
스케줄러에 알려준다.
- `ProbeTerminationGracePeriod`: 파드의 [프로브-수준
`terminationGracePeriodSeconds` 설정하기](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#probe-level-terminationgraceperiodseconds) 기능을 활성화한다.
더 자세한 사항은 [기능개선 제안](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/2238-liveness-probe-grace-period)을 참고한다.
- `ProcMountType`: SecurityContext의 `procMount` 필드를 설정하여
컨테이너의 proc 타입의 마운트를 제어할 수 있다.
- `ProxyTerminatingEndpoints`: `ExternalTrafficPolicy=Local`일 때 종료 엔드포인트를 처리하도록
kube-proxy를 활성화한다.
- `QOSReserved`: QoS 수준에서 리소스 예약을 허용하여 낮은 QoS 수준의 파드가
더 높은 QoS 수준에서 요청된 리소스로 파열되는 것을 방지한다
(현재 메모리만 해당).
- `ReadWriteOncePod`: `ReadWriteOncePod` 퍼시스턴트 볼륨 엑세스 모드를
사용한다.
- `RemainingItemCount`: API 서버가
[청크(chunking) 목록 요청](/docs/reference/using-api/api-concepts/#retrieving-large-results-sets-in-chunks)에 대한
응답에서 남은 항목 수를 표시하도록 허용한다.
@@ -779,6 +919,10 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
스케줄링할 수 있다.
- `SCTPSupport`: 파드, 서비스, 엔드포인트, 엔드포인트슬라이스 및 네트워크폴리시 정의에서
_SCTP_ `protocol` 값을 활성화한다.
- `SeccompDefault`: 모든 워크로드의 기본 구분 프로파일로 `RuntimeDefault`을 사용한다.
seccomp 프로파일은 파드 및 컨테이너 `securityContext`에 지정되어 있다.
- `SelectorIndex`: API 서버 감시(watch) 캐시의 레이블 및 필드 기반 인덱스를 사용하여
목록 작업을 가속화할 수 있다.
- `ServerSideApply`: API 서버에서 [SSA(Sever Side Apply)](/docs/reference/using-api/server-side-apply/)
경로를 활성화한다.
- `ServiceAccountIssuerDiscovery`: API 서버에서 서비스 어카운트 발행자에 대해 OIDC 디스커버리 엔드포인트(발급자 및
@@ -806,6 +950,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
- `StartupProbe`: kubelet에서
[스타트업](/ko/docs/concepts/workloads/pods/pod-lifecycle/#언제-스타트업-프로브를-사용해야-하는가)
프로브를 활성화한다.
- `StatefulSetMinReadySeconds`: 스테이트풀셋 컨트롤러가 `minReadySeconds`를
반영할 수 있다.
- `StorageObjectInUseProtection`: 퍼시스턴트볼륨 또는 퍼시스턴트볼륨클레임 오브젝트가 여전히
사용 중인 경우 삭제를 연기한다.
- `StorageVersionAPI`: [스토리지 버전 API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#storageversion-v1alpha1-internal-apiserver-k8s-io)를
@@ -867,6 +1013,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
- `WinDSR`: kube-proxy가 윈도우용 DSR 로드 밸런서를 생성할 수 있다.
- `WinOverlay`: kube-proxy가 윈도우용 오버레이 모드에서 실행될 수 있도록 한다.
- `WindowsGMSA`: 파드에서 컨테이너 런타임으로 GMSA 자격 증명 스펙을 전달할 수 있다.
- `WindowsHostProcessContainers`: 윈도우 HostProcess 컨테이너에 대한 지원을 사용하도록 설정한다.
- `WindowsRunAsUserName` : 기본 사용자가 아닌(non-default) 사용자로 윈도우 컨테이너에서
애플리케이션을 실행할 수 있도록 지원한다. 자세한 내용은
[RunAsUserName 구성](/ko/docs/tasks/configure-pod-container/configure-runasusername/)을
@@ -875,6 +1022,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
엔드포인트 대신 엔드포인트슬라이스를 기본 데이터 소스로 사용하여
확장성과 성능을 향상시킨다.
[엔드포인트슬라이스 활성화하기](/ko/docs/concepts/services-networking/endpoint-slices/)를 참고한다.
- `WindowsHostProcessContainers`: 윈도우 노드에서 `HostProcess`
컨테이너 지원을 활성화한다.
## {{% heading "whatsnext" %}}
content/ko/docs/reference/glossary/api-eviction.md
+1 -1
View File
@@ -2,7 +2,7 @@
title: API를 이용한 축출(Eviction)
id: api-eviction
date: 2021-04-27
full_link: /docs/concepts/scheduling-eviction/pod-eviction/#api-eviction
full_link: /ko/docs/concepts/scheduling-eviction/api-eviction/
short_description: >
API를 이용한 축출은 축출 API를 사용하여 파드의 정상 종료를 트리거하는
축출 오브젝트를 만드는 프로세스이다
content/ko/docs/reference/glossary/csi.md
+21
View File
@@ -0,0 +1,21 @@
---
title: 컨테이너 스토리지 인터페이스(CSI)
id: csi
date: 2018-06-25
full_link: /ko/docs/concepts/storage/volumes/#csi
short_description: >
컨테이너 스토리지 인터페이스(CSI)는 컨테이너에 스토리지 시스템을 노출하는 표준 인터페이스를 정의한다.
aka:
tags:
- storage
---
컨테이너 스토리지 인터페이스(CSI)는 컨테이너에 스토리지 시스템을 노출하는 표준 인터페이스를 정의한다.
<!--more-->
CSI를 통해 공급업체는 쿠버네티스 저장소(트리 외 플러그인)를 추가하지 않고도 쿠버네티스용 사용자 스토리지 플러그인을 생성할 수 있다. 스토리지 제공자가 CSI 드라이버를 사용하려면, 먼저 [클러스터에 배포](https://kubernetes-csi.github.io/docs/deploying.html)해야 한다. 그런 다음 해당 CSI 드라이버를 사용하는 {{< glossary_tooltip text="스토리지클래스(StorageClass)" term_id="storage-class" >}}를 생성할 수 있다.
* [쿠버네티스 문서에서 CSI](/ko/docs/concepts/storage/volumes/#csi)
* [사용 가능한 CSI 드라이버 목록](https://kubernetes-csi.github.io/docs/drivers.html)
content/ko/docs/reference/kubectl/kubectl.md
+24
View File
@@ -328,7 +328,31 @@ kubectl [flags]
</tbody>
</table>
## {{% heading "envvars" %}}
<table style="width: 100%; table-layout: fixed;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">KUBECONFIG</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">kubectl 구성 ("kubeconfig") 파일 경로. 기본: "$HOME/.kube/config"</td>
</tr>
<tr>
<td colspan="2">KUBECTL_COMMAND_HEADERS</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">false로 설정하면, 호출된 kubectl 명령(쿠버네티스 버전 v1.22 이상)을 자세히 설명하는 추가 HTTP 헤더를 해제</td>
</tr>
</tbody>
</table>
## {{% heading "seealso" %}}
content/ko/docs/reference/kubectl/overview.md
+1 -1
View File
@@ -87,7 +87,7 @@ kubectl [command] [TYPE] [NAME] [flags]
`cluster-info` | `kubectl cluster-info [flags]` | 클러스터의 마스터와 서비스에 대한 엔드포인트 정보를 표시한다.
`completion` | `kubectl completion SHELL [options]` | 지정된 셸(bash 또는 zsh)에 대한 셸 완성 코드를 출력한다.
`config` | `kubectl config SUBCOMMAND [flags]` | kubeconfig 파일을 수정한다. 세부 사항은 개별 하위 명령을 참고한다.
`convert` | `kubectl convert -f FILENAME [options]` | 다른 API 버전 간에 구성 파일을 변환한다. YAML 및 JSON 형식이 모두 허용된다.
`convert` | `kubectl convert -f FILENAME [options]` | 다른 API 버전 간에 구성 파일을 변환한다. YAML 및 JSON 형식이 모두 허용된다. 참고 - `kubectl-convert` 플러그인을 설치해야 한다.
`cordon` | `kubectl cordon NODE [options]` | 노드를 스케줄 불가능(unschedulable)으로 표시한다.
`cp` | `kubectl cp <file-spec-src> <file-spec-dest> [options]` | 컨테이너에서 그리고 컨테이너로 파일 및 디렉터리를 복사한다.
`create` | `kubectl create -f FILENAME [flags]` | 파일이나 표준입력에서 하나 이상의 리소스를 생성한다.
content/ko/docs/reference/labels-annotations-taints.md
+106 -3
View File
@@ -200,7 +200,7 @@ kubelet이 Microsoft 윈도우에서 실행되고 있다면, 사용 중인 Windo
kube-proxy 에는 커스텀 프록시를 위한 이와 같은 레이블이 있으며, 이 레이블은 서비스 컨트롤을 커스텀 프록시에 위임한다.
## experimental.windows.kubernetes.io/isolation-type
## experimental.windows.kubernetes.io/isolation-type (deprecated) {#experimental-windows-kubernetes-io-isolation-type}
예시: `experimental.windows.kubernetes.io/isolation-type: "hyperv"`
@@ -210,6 +210,7 @@ Hyper-V 격리(isolation)를 사용하여 윈도우 컨테이너를 실행하려
{{< note >}}
이 어노테이션은 하나의 컨테이너로 구성된 파드에만 설정할 수 있다.
v1.20부터 이 어노테이션은 더이상 사용되지 않는다. 실험적인 Hyper-V 지원은 1.21버전에서 제거되었다.
{{< /note >}}
## ingressclass.kubernetes.io/is-default-class
@@ -262,11 +263,29 @@ kube-controller-manager의 잡(Job) 컨트롤러는
## endpoints.kubernetes.io/over-capacity
예시: `endpoints.kubernetes.io/over-capacity:warning`
예시: `endpoints.kubernetes.io/over-capacity:truncated`
적용 대상: 엔드포인트(Endpoints)
v1.21 이상의 쿠버네티스 클러스터에서, 엔드포인트(Endpoints) 컨트롤러가 1000개 이상의 엔드포인트를 관리하고 있다면 각 엔드포인트 리소스에 이 어노테이션을 추가한다. 이 어노테이션은 엔드포인트 리소스가 용량 초과 되었음을 나타낸다.
v1.22 이상의 쿠버네티스 클러스터에서, 한 엔드포인트(Endpoints) 리소스가 관리하고 있는 엔드포인트의 수가 1000개 이상이면 엔드포인트 컨트롤러가 해당 엔드포인트 리소스에 이 어노테이션을 추가한다. 이 어노테이션은 해당 엔드포인트 리소스가 용량 초과 되었으며 엔드포인트 컨트롤러가 엔드포인트의 수를 1000으로 줄였음을 나타낸다.
## batch.kubernetes.io/job-tracking
예시: `batch.kubernetes.io/job-tracking: ""`
적용 대상: 잡
잡에 어노테이션이 있으면 컨트롤 플레인은 [finalizers를 사용하여 잡 상태 추적](/ko/docs/concepts/workloads/controllers/job/#job-tracking-with-finalizers)
중임을 나타낸다.
어노테이션을 수동으로 추가하거나 제거하지 **않는다**.
## scheduler.alpha.kubernetes.io/preferAvoidPods (deprecated) {#scheduleralphakubernetesio-preferavoidpods}
적용 대상: 노드
이 어노테이션을 사용하려면 [NodePreferAvoidPods 스케줄링 플러그인](/ko/docs/reference/scheduling/config/#scheduling-plugins)이 활성화되어 있어야 한다.
해당 플러그인은 쿠버네티스 1.22에서 사용 중단되었다.
대신 [테인트와 톨러레이션](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)을 사용한다.
**이 이후로 나오는 테인트는 모두 '적용 대상: 노드' 이다.**
@@ -323,3 +342,87 @@ kubelet이 "외부" 클라우드 공급자에 의해 실행되었다면 노드
예시: `node.cloudprovider.kubernetes.io/shutdown:NoSchedule`
노드의 상태가 클라우드 공급자가 정의한 'shutdown' 상태이면, 이에 따라 노드에 `node.cloudprovider.kubernetes.io/shutdown` 테인트가 `NoSchedule` 값으로 설정된다.
## pod-security.kubernetes.io/enforce
예시: `pod-security.kubernetes.io/enforce: baseline`
적용 대상: 네임스페이스
값은 **반드시** [파드 보안 표준](/docs/concepts/security/pod-security-standards) 레벨과 상응하는
`privileged`, `baseline`, 또는 `restricted` 중 하나여야 한다.
특히 `enforce` 레이블은 표시된 수준에 정의된 요구 사항을 충족하지 않는
레이블 네임스페이스에 모든 파드의 생성을 금지한다.
더 많은 정보는 [네임스페이스에서 파드 보안 적용](/docs/concepts/security/pod-security-admission)을
참고한다.
## pod-security.kubernetes.io/enforce-version
예시: `pod-security.kubernetes.io/enforce-version: {{< skew latestVersion >}}`
적용 대상: 네임스페이스
값은 **반드시** `latest`이거나 `v<MAJOR>.<MINOR>` 형식의 유효한 쿠버네티스 버전이어야 한다.
설정된 파드의 유효성을 검사할 때 적용할 [파드 보안 표준](/docs/concepts/security/pod-security-standards)
정책의 버전이 결정된다.
더 많은 정보는 [네임스페이스에서 파드 보안 적용](/docs/concepts/security/pod-security-admission)을
참고한다.
## pod-security.kubernetes.io/audit
예시: `pod-security.kubernetes.io/audit: baseline`
적용 대상: 네임스페이스
값은 **반드시** [파드 보안 표준](/docs/concepts/security/pod-security-standards) 레벨과 상응하는
`privileged`, `baseline`, 또는 `restricted` 중 하나여야 한다.
특히 `audit` 레이블은 표시된 수준에 정의된 요구 사항을 충족하지 않는 레이블 네임스페이스에 파드를 생성하는 것을
방지하지 않지만, 해당 파드에 audit 어노테이션을 추가한다.
더 많은 정보는 [네임스페이스에서 파드 보안 적용](/docs/concepts/security/pod-security-admission)을
참고한다.
## pod-security.kubernetes.io/audit-version
예시: `pod-security.kubernetes.io/audit-version: {{< skew latestVersion >}}`
적용 대상: 네임스페이스
값은 **반드시** `latest`이거나 `v<MAJOR>.<MINOR>` 형식의 유효한 쿠버네티스 버전이어야 한다.
설정된 파드의 유효성을 검사할 때 적용할 [파드 보안 표준](/docs/concepts/security/pod-security-standards)
정책의 버전이 결정된다.
더 많은 정보는 [네임스페이스에서 파드 보안 적용](/docs/concepts/security/pod-security-admission)을
참고한다.
## pod-security.kubernetes.io/warn
예시: `pod-security.kubernetes.io/warn: baseline`
적용 대상: 네임스페이스
값은 **반드시** [파드 보안 표준](/docs/concepts/security/pod-security-standards) 레벨과 상응하는
`privileged`, `baseline`, 또는 `restricted` 중 하나여야 한다.
특히 `warn` 레이블은 해당 레이블이 달린 네임스페이스에, 표시된 레벨에 명시된 요구 사항을 충족하지 않는 파드를 생성하는 것을
방지하지는 않지만, 그러한 파드가 생성되면 사용자에게 경고를 반환한다.
디플로이먼트, 잡, 스테이트풀셋 등과 같은 파드 템플릿을 포함하는
객체를 만들거나 업데이트할 때에도 경고가 표시된다.
더 많은 정보는 [네임스페이스에서 파드 보안 적용](/docs/concepts/security/pod-security-admission)을
참고한다.
## pod-security.kubernetes.io/warn-version
예시: `pod-security.kubernetes.io/warn-version: {{< skew latestVersion >}}`
적용 대상: 네임스페이스
값은 **반드시** `latest`이거나 `v<MAJOR>.<MINOR>` 형식의 유효한 쿠버네티스 버전이어야 한다.
설정된 파드의 유효성을 검사할 때 적용할 [파드 보안 표준](/docs/concepts/security/pod-security-standards)
정책의 버전이 결정된다. 디플로이먼트, 잡, 스테이트풀셋 등과 같은 파드 템플릿을 포함하는
객체를 만들거나 업데이트할 때에도 경고가 표시된다.
더 많은 정보는 [네임스페이스에서 파드 보안 적용](/docs/concepts/security/pod-security-admission)을
참고한다.
content/ko/docs/reference/scheduling/config.md
+65 -55
View File
@@ -18,7 +18,8 @@ weight: 20
각 단계는 익스텐션 포인트(extension point)를 통해 노출된다. 플러그인은 이러한
익스텐션 포인트 중 하나 이상을 구현하여 스케줄링 동작을 제공한다.
[KubeSchedulerConfiguration (v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/)
KubeSchedulerConfiguration ([v1beta1](/docs/reference/config-api/kube-scheduler-config.v1beta1/)
또는 [v1beta2](/docs/reference/config-api/kube-scheduler-config.v1beta2/))
구조에 맞게 파일을 작성하고,
`kube-scheduler --config <filename>`을 실행하여
스케줄링 프로파일을 지정할 수 있다.
@@ -26,7 +27,7 @@ weight: 20
최소 구성은 다음과 같다.
```yaml
apiVersion: kubescheduler.config.k8s.io/v1beta1
apiVersion: kubescheduler.config.k8s.io/v1beta2
kind: KubeSchedulerConfiguration
clientConnection:
kubeconfig: /etc/srv/kubernetes/kube-scheduler/kubeconfig
@@ -48,38 +49,41 @@ clientConnection:
스케줄링은 다음 익스텐션 포인트를 통해 노출되는 일련의 단계에서
발생한다.
1. `QueueSort`: 이 플러그인은 스케줄링 대기열에서 보류 중인 파드를
1. `queueSort`: 이 플러그인은 스케줄링 대기열에서 보류 중인 파드를
정렬하는 데 사용되는 정렬 기능을 제공한다. 대기열 정렬 플러그인은 한 번에 단 하나만 활성화될 수 있다.
사용할 수 있다.
1. `PreFilter`: 이 플러그인은 필터링하기 전에 파드 또는 클러스터에 대한 정보를
1. `preFilter`: 이 플러그인은 필터링하기 전에 파드 또는 클러스터에 대한 정보를
사전 처리하거나 확인하는 데 사용된다. 이 플러그인은 파드를 unschedulable로
표시할 수 있다.
1. `Filter`: 이 플러그인은 스케줄링 정책의 단정(Predicates)과 동일하며
1. `filter`: 이 플러그인은 스케줄링 정책의 단정(Predicates)과 동일하며
파드를 실행할 수 없는 노드를 필터링하는 데 사용된다. 필터는
구성된 순서대로 호출된다. 노드가 모든 필터를 통과하지 않으면 파드는 unschedulable로
표시된다.
1. `PreScore`: 이것은 사전 스코어링 작업을 수행하는 데 사용할 수 있는
1. `postFilter`: 이 플러그인은 파드의 실행 가능한 노드를 찾을 수 없을 때,
구성된 순서대로 호출된다. `postFilter` 플러그인이 파드 _schedulable_ 을 표시하는 경우,
나머지 플러그인은 호출 되지 않는다.
1. `preScore`: 이것은 사전 스코어링 작업을 수행하는 데 사용할 수 있는
정보성 익스텐션 포인트이다.
1. `Score`: 이 플러그인은 필터링 단계를 통과한 각 노드에 점수를
1. `score`: 이 플러그인은 필터링 단계를 통과한 각 노드에 점수를
제공한다. 그런 다음 스케줄러는 가중치 합계가 가장 높은
노드를 선택한다.
1. `Reserve`: 지정된 파드에 리소스가 예약된 경우 플러그인에
1. `reserve`: 지정된 파드에 리소스가 예약된 경우 플러그인에
알리는 정보성 익스텐션 포인트이다. 플러그인은 또한
`Reserve` 도중 또는 이후에 실패한 경우 호출 되는 `Unreserve` 호출을
구현한다.
1. `Permit`: 이 플러그인은 파드 바인딩을 방지하거나 지연시킬 수 있다.
1. `PreBind`: 이 플러그인은 파드가 바인딩되기 전에 필요한 모든 작업을 수행한다.
1. `Bind`: 플러그인은 파드를 노드에 바인딩한다. Bind 플러그인은 순서대로 호출되며
일단 바인딩이 완료되면 나머지 플러그인은 건너뛴다. Bind
1. `permit`: 이 플러그인은 파드 바인딩을 방지하거나 지연시킬 수 있다.
1. `preBind`: 이 플러그인은 파드가 바인딩되기 전에 필요한 모든 작업을 수행한다.
1. `bind`: 플러그인은 파드를 노드에 바인딩한다. `bind` 플러그인은 순서대로 호출되며
일단 바인딩이 완료되면 나머지 플러그인은 건너뛴다. bind
플러그인은 적어도 하나 이상 필요하다.
1. `PostBind`: 파드가 바인드된 후 호출되는
1. `postBind`: 파드가 바인드된 후 호출되는
정보성 익스텐션 포인트이다.
각 익스텐션 포인트에 대해 특정 [기본 플러그인](#스케줄링-플러그인)을 비활성화하거나
자체 플러그인을 활성화할 수 있다. 예를 들면, 다음과 같다.
```yaml
apiVersion: kubescheduler.config.k8s.io/v1beta1
apiVersion: kubescheduler.config.k8s.io/v1beta2
kind: KubeSchedulerConfiguration
profiles:
- plugins:
@@ -99,98 +103,100 @@ profiles:
### 스케줄링 플러그인
1. `UnReserve`: 파드가 예약된 후 거부되고 `Permit` 플러그인에 의해 보류된 경우
호출되는 정보성 익스텐션 포인트이다.
## 스케줄링 플러그인
기본적으로 활성화된 다음의 플러그인은 이들 익스텐션 포인트 중
하나 이상을 구현한다.
- `SelectorSpread`: {{< glossary_tooltip text="서비스" term_id="service" >}},
{{< glossary_tooltip text="레플리카셋(ReplicaSets)" term_id="replica-set" >}} 및
{{< glossary_tooltip text="스테이트풀셋(StatefulSets)" term_id="statefulset" >}}에
속하는 파드에 대해 노드 간 분산을 선호한다.
익스텐션 포인트: `PreScore`, `Score`.
- `ImageLocality`: 파드가 실행하는 컨테이너 이미지가 이미 있는 노드를
선호한다.
익스텐션 포인트: `Score`.
익스텐션 포인트: `score`.
- `TaintToleration`: [테인트(taint)와 톨러레이션(toleration)](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)을
구현한다.
익스텐션 포인트 구현: `Filter`, `Prescore`, `Score`.
익스텐션 포인트 구현: `filter`, `preScore`, `score`.
- `NodeName`: 파드 명세 노드 이름이 현재 노드와 일치하는지 확인한다.
익스텐션 포인트: `Filter`.
익스텐션 포인트: `filter`.
- `NodePorts`: 노드에 요청된 파드 포트에 대해 사용 가능한 포트가 있는지 확인한다.
익스텐션 포인트: `PreFilter`, `Filter`.
익스텐션 포인트: `preFilter`, `filter`.
- `NodePreferAvoidPods`: 노드 {{< glossary_tooltip text="어노테이션" term_id="annotation" >}}
`scheduler.alpha.kubernetes.io/preferAvoidPods` 에 따라
노드 점수를 매긴다.
익스텐션 포인트: `Score`.
익스텐션 포인트: `score`.
- `NodeAffinity`: [노드 셀렉터](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#노드-셀렉터-nodeselector)와
[노드 어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#노드-어피니티)를
구현한다.
익스텐션 포인트: `Filter`, `Score`.
익스텐션 포인트: `filter`, `score`.
- `PodTopologySpread`: [파드 토폴로지 분배](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/)를
구현한다.
익스텐션 포인트: `PreFilter`, `Filter`, `PreScore`, `Score`.
익스텐션 포인트: `preFilter`, `filter`, `preScore`, `score`.
- `NodeUnschedulable`: `.spec.unschedulable` 이 true로 설정된 노드를
필터링한다.
익스텐션 포인트: `Filter`.
익스텐션 포인트: `filter`.
- `NodeResourcesFit`: 노드에 파드가 요청하는 모든 리소스가 있는지
확인한다.
익스텐션 포인트: `PreFilter`, `Filter`.
확인한다. 점수는 `LeastAllocated`(기본값), `MostAllocated`, `RequestedToCapacityRatio` 등 3가지 전략 중 하나를 사용할 수 있다.
익스텐션 포인트: `preFilter`, `filter`, `score`.
- `NodeResourcesBalancedAllocation`: 파드가 스케줄된 경우, 보다 균형잡힌 리소스 사용량을
얻을 수 있는 노드를 선호한다.
익스텐션 포인트: `Score`.
익스텐션 포인트: `score`.
- `NodeResourcesLeastAllocated`: 리소스 할당이 적은 노드를
선호한다.
익스텐션 포인트: `Score`.
- `VolumeBinding`: 노드에 요청된 {{< glossary_tooltip text="볼륨" term_id="volume" >}}이 있는지
또는 바인딩할 수 있는지 확인한다.
익스텐션 포인트: `PreFilter`, `Filter`, `Reserve`, `PreBind`, `Score`.
익스텐션 포인트: `preFilter`, `filter`, `reserve`, `preBind`, `score`.
{{< note >}}
`Score` 익스텐션 포인트는 `VolumeCapacityPriority` 기능이
`score` 익스텐션 포인트는 `VolumeCapacityPriority` 기능이
활성화되어 있어야 활성화되며,
요청된 볼륨 사이즈를 만족하는 가장 작은 PV들을 우선순위 매긴다.
{{< /note >}}
- `VolumeRestrictions`: 노드에 마운트된 볼륨이 볼륨 제공자에 특정한
제한 사항을 충족하는지 확인한다.
익스텐션 포인트: `Filter`.
익스텐션 포인트: `filter`.
- `VolumeZone`: 요청된 볼륨이 가질 수 있는 영역 요구 사항을 충족하는지
확인한다.
익스텐션 포인트: `Filter`.
익스텐션 포인트: `filter`.
- `NodeVolumeLimits`: 노드에 대해 CSI 볼륨 제한을 충족할 수 있는지
확인한다.
익스텐션 포인트: `Filter`.
익스텐션 포인트: `filter`.
- `EBSLimits`: 노드에 대해 AWS EBS 볼륨 제한을 충족할 수 있는지 확인한다.
익스텐션 포인트: `Filter`.
익스텐션 포인트: `filter`.
- `GCEPDLimits`: 노드에 대해 GCP-PD 볼륨 제한을 충족할 수 있는지 확인한다.
익스텐션 포인트: `Filter`.
익스텐션 포인트: `filter`.
- `AzureDiskLimits`: 노드에 대해 Azure 디스크 볼륨 제한을 충족할 수 있는지
확인한다.
익스텐션 포인트: `Filter`.
익스텐션 포인트: `filter`.
- `InterPodAffinity`: [파드 간 어피니티 및 안티-어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#파드간-어피니티와-안티-어피니티)를
구현한다.
익스텐션 포인트: `PreFilter`, `Filter`, `PreScore`, `Score`.
익스텐션 포인트: `preFilter`, `filter`, `preScore`, `score`.
- `PrioritySort`: 기본 우선 순위 기반 정렬을 제공한다.
익스텐션 포인트: `QueueSort`.
익스텐션 포인트: `queueSort`.
- `DefaultBinder`: 기본 바인딩 메커니즘을 제공한다.
익스텐션 포인트: `Bind`.
익스텐션 포인트: `bind`.
- `DefaultPreemption`: 기본 선점 메커니즘을 제공한다.
익스텐션 포인트: `PostFilter`.
익스텐션 포인트: `postFilter`.
기본으로 활성화되지 않는 다음의 플러그인을
컴포넌트 구성 API를 통해 활성화할 수도 있다.
- `SelectorSpread`: {{< glossary_tooltip text="Services" term_id="service" >}},
{{< glossary_tooltip text="ReplicaSets" term_id="replica-set" >}}와
{{< glossary_tooltip text="StatefulSets" term_id="statefulset" >}}에 속하는 파드의 경우,
노드간에 퍼지는 것을 선호한다.
익스텐션 포인트: `preScore`, `score`.
- `CinderLimits`: 노드에 대해 [OpenStack Cinder](https://docs.openstack.org/cinder/)
볼륨 제한이 충족될 수 있는지 확인한다.
익스텐션 포인트: `filter`.
다음 플러그인은 더 이상 사용되지 않으며 `v1beta1`에서만
사용할 수 있다.
- `NodeResourcesLeastAllocated`: 리소스 할당이 낮은 노드를
선호한다.
Extension points: `score`.
- `NodeResourcesMostAllocated`: 리소스 할당이 많은 노드를
선호한다.
익스텐션 포인트: `Score`.
익스텐션 포인트: `score`.
- `RequestedToCapacityRatio`: 할당된 리소스의 구성된 기능에 따라 노드를
선호한다.
익스텐션 포인트: `Score`.
- `CinderVolume`: 노드에 대해 OpenStack Cinder 볼륨 제한을 충족할 수 있는지
확인한다.
익스텐션 포인트: `Filter`.
익스텐션 포인트: `score`.
- `NodeLabel`: Filters and / or scores a node according to configured
{{< glossary_tooltip text="label(s)" term_id="label" >}}.
익스텐션 포인트: `Filter`, `Score`.
@@ -198,7 +204,10 @@ profiles:
속한 파드가 구성된 레이블로 정의된 노드 집합에 맞는지
확인한다. 이 플러그인은 또한 서비스에 속한 파드를 노드 간에
분산하는 것을 선호한다.
익스텐션 포인트: `PreFilter`, `Filter`, `Score`.
익스텐션 포인트: `preFilter`, `filter`, `score`.
- `NodePreferAvoidPods`: 노드 주석 `scheduler.alpha.kubernetes.io/preferAvoidPods`에 따라
노드의 우선 순위를 지정한다.
익스텐션 포인트: `score`.
### 여러 프로파일
@@ -211,7 +220,7 @@ profiles:
실행된다.
```yaml
apiVersion: kubescheduler.config.k8s.io/v1beta1
apiVersion: kubescheduler.config.k8s.io/v1beta2
kind: KubeSchedulerConfiguration
profiles:
- schedulerName: default-scheduler
@@ -243,7 +252,7 @@ profiles:
{{< /note >}}
{{< note >}}
모든 프로파일은 QueueSort 익스텐션 포인트에서 동일한 플러그인을 사용해야 하며
모든 프로파일은 `queueSort` 익스텐션 포인트에서 동일한 플러그인을 사용해야 하며
동일한 구성 파라미터(해당하는 경우)를 가져야 한다. 그 이유는 스케줄러가 보류 중 상태인 파드 대기열을
단 하나만 가질 수 있기 때문이다.
{{< /note >}}
@@ -253,3 +262,4 @@ profiles:
* [kube-scheduler 레퍼런스](/docs/reference/command-line-tools-reference/kube-scheduler/) 읽어보기
* [스케줄링](/ko/docs/concepts/scheduling-eviction/kube-scheduler/)에 대해 알아보기
* [kube-scheduler configuration (v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/) 레퍼런스 읽어보기
* [kube-scheduler configuration (v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2/) 레퍼런스 읽어보기
content/ko/docs/reference/scheduling/policies.md
+1 -1
View File
@@ -98,5 +98,5 @@ weight: 10
* [스케줄링](/ko/docs/concepts/scheduling-eviction/kube-scheduler/)에 대해 배우기
* [kube-scheduler 프로파일](/docs/reference/scheduling/profiles/)에 대해 배우기
* [kube-scheduler configuration 레퍼런스 (v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1) 읽어보기
* [kube-scheduler configuration 레퍼런스 (v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2) 읽어보기
* [kube-scheduler Policy 레퍼런스 (v1)](/docs/reference/config-api/kube-scheduler-policy-config.v1/) 읽어보기
content/ko/docs/reference/tools/_index.md
+1 -2
View File
@@ -8,8 +8,7 @@ no_list: true
---
<!-- overview -->
쿠버네티스는 쿠버네티스 시스템으로 작업하는 데 도움이되는 몇 가지 기본 제공 도구를 포함한다.
쿠버네티스는 쿠버네티스 시스템으로 작업하는 데 필요한 공통적으로 사용되거나 관련성 있는 여러 내장 도구와 외부 도구를 포함한다.
<!-- body -->
content/ko/docs/reference/using-api/health-checks.md
+1 -1
View File
@@ -91,7 +91,7 @@ curl -k 'https://localhost:6443/readyz?verbose&exclude=etcd'
{{< feature-state state="alpha" >}}
각 개별 헬스 체크는 http 엔드포인트를 노출하고 개별적으로 체크가 가능하다.
각 개별 헬스 체크는 HTTP 엔드포인트를 노출하고 개별적으로 체크가 가능하다.
개별 체크를 위한 스키마는 `/livez/<healthcheck-name>` 이고, 여기서 `livez` 와 `readyz` 는 API 서버의 활성 상태 또는 준비 상태인지를 확인할 때 사용한다.
`<healthcheck-name>` 경로 위에서 설명한 `verbose` 플래그를 사용해서 찾을 수 있고, `[+]` 와 `ok` 사이의 경로를 사용한다.
이러한 개별 헬스 체크는 머신에서 사용되서는 안되며, 운영자가 시스템의 현재 상태를 디버깅하는데 유용하다.
content/ko/docs/setup/best-practices/cluster-large.md
+3
View File
@@ -121,3 +121,6 @@ _A_ 영역에 있는 컨트롤 플레인 호스트로만 전달한다. 단일
[클러스터 오토스케일러](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler#readme)는
여러 클라우드 프로바이더와 통합되어 클러스터의 리소스 요구 수준에 맞는
노드 수를 실행할 수 있도록 도와준다.
[addon resizer](https://github.com/kubernetes/autoscaler/tree/master/addon-resizer#readme)는
클러스터 스케일이 변경될 때 자동으로 애드온 크기를 조정할 수 있도록 도와준다.
content/ko/docs/setup/production-environment/container-runtimes.md
+33 -1
View File
@@ -26,7 +26,7 @@ weight: 20
다른 운영 체제의 경우, 해당 플랫폼과 관련된 문서를 찾아보자.
{{< /note >}}
## Cgroup 드라이버
## cgroup 드라이버
Control group은 프로세스에 할당된 리소스를 제한하는데 사용된다.
@@ -57,6 +57,38 @@ kubelet을 재시작하는 것은 에러를 해결할 수 없을 것이다.
교체하거나, 자동화를 사용하여 다시 설치한다.
{{< /caution >}}
## cgroup v2
cgroup v2는 cgroup Linux API의 다음 버전이다.
cgroup v1과는 다르게 각 컨트롤러마다 다른 계층 대신 단일 계층이 있다.
새 버전은 cgroup v1에 비해 몇 가지 향상된 기능을 제공하며, 개선 사항 중 일부는 다음과 같다.
- API를 더 쉽고 깔끔하게 사용할 수 있음
- 컨테이너로의 안전한 하위 트리 위임
- 압력 중지 정보와 같은 새로운 기능
일부 컨트롤러는 cgroup v1에 의해 관리되고 다른 컨트롤러는 cgroup v2에 의해 관리되는 하이브리드 구성을 지원하더라도,
쿠버네티스는 모든 컨트롤러를 관리하기 위해
동일한 cgroup 버전만 지원한다.
systemd가 기본적으로 cgroup v2를 사용하지 않는 경우, 커널 명령줄에 `systemd.unified_cgroup_hierarchy=1`을
추가하여 cgroup v2를 사용하도록 시스템을 구성할 수 있다.
```shell
# dnf install -y grubby && \
sudo grubby \
--update-kernel=ALL \
--args=”systemd.unified_cgroup_hierarchy=1"
```
구성을 적용하려면 노드를 재부팅해야 한다.
cgroup v2로 전환할 때 사용자가 노드 또는 컨테이너 내에서
cgroup 파일 시스템에 직접 접근하지 않는 한 사용자 경험에 현저한 차이가 없어야 한다.
cgroup v2를 사용하려면 CRI 런타임에서도 cgroup v2를 지원해야 한다.
### kubeadm으로 생성한 클러스터의 드라이버를 `systemd`로 변경하기
kubeadm으로 생성한 클러스터의 cgroup 드라이버를 `systemd`로 변경하려면
content/ko/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md
+147 -24
View File
@@ -1,78 +1,108 @@
---
reviewers:
title: kubeadm으로 컨트롤 플레인 사용자 정의하기
title: kubeadm API로 컴포넌트 사용자 정의하기
content_type: concept
weight: 40
---
<!-- overview -->
이 페이지는 kubeadm이 배포하는 컴포넌트(component)들을 사용자 정의하는 방법을 다룬다. 컨트롤 플레인 컴포넌트에
대해서는 `ClusterConfiguration` 구조에서 플래그를 사용하거나 노드당 패치를 사용할 수 있다. kubelet과
kube-proxy의 경우, `KubeletConfiguration`과 `KubeProxyConfiguration`을 각각 사용할 수 있다.
이 모든 옵션이 kubeadm 구성 API를 통해 가용하다.
구성의 각 필드 상세 사항은
[API 참조 페이지](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta3)에서 찾아볼 수 있다.
{{< note >}}
kubeadm의 CoreDNS 디플로이먼트 사용자 정의는 현재 제공되지 않는다.
`kube-system/coredns` {{< glossary_tooltip text="컨피그맵" term_id="configmap" >}}을 수동으로
패치하고, 그 이후에 CoreDNS {{< glossary_tooltip text="파드" term_id="pod" >}}를 다시 생성해야 한다. 또는,
기본 CoreDNS 디플로이먼트를 생략하고 자체 변형(variant)을 배포할 수 있다.
더 자세한 사항은 [kubeadm에서 초기화 단계 사용하기](/docs/reference/setup-tools/kubeadm/kubeadm-init/#init-phases)을 참고한다.
{{< /note >}}
<!-- body -->
{{< feature-state for_k8s_version="v1.12" state="stable" >}}
kubeadm의 `ClusterConfiguration` 오브젝트는 API 서버, 컨트롤러매니저, 스케줄러와 같은 컨트롤 플레인 구성요소에 전달되는
기본 플래그 `extraArgs` 필드를 노출한다. 이 구성요소는 다음 필드를 사용하도록 정의되어 있다.
## `ClusterConfiguration`의 플래그로 컨트롤 플레인 사용자 정의하기
kubeadm의 `ClusterConfiguration` 오브젝트는 API 서버, 컨트롤러매니저, 스케줄러, Etcd와 같은 컨트롤 플레인 컴포넌트에 전달되는
기본 플래그를 사용자가 덮어쓸 수 있도록 노출한다.
이 컴포넌트는 다음 구조체를 사용하여 정의된다.
- `apiServer`
- `controllerManager`
- `scheduler`
- `etcd`
`extraArgs` 필드는 `key: value` 쌍으로 구성되어 있다. 컨트롤 플레인 구성요소를 위한 플래그를 대체하려면 다음을 수행한다.
이 구조체들은 공통 필드인 `extraArgs`를 포함하며, 이 필드는 `키: 값` 쌍으로 구성된다.
컨트롤 플레인 컴포넌트를 위한 플래그를 덮어쓰려면 다음을 수행한다.
1. 사용자 구성에서 적절한 필드를 추가한다.
2. 필드에 대체할 플래그를 추가한다.
1. 사용자 구성에 적절한 `extraArgs` 필드를 추가한다.
2. `extraArgs` 필드에 플래그를 추가한다.
3. `kubeadm init`에 `--config <CONFIG YAML 파일>` 파라미터를 추가해서 실행한다.
각 필드의 구성에서 자세한 정보를 보려면,
[API 참고 문서](/docs/reference/config-api/kubeadm-config.v1beta2/)에서 확인해 볼 수 있다.
{{< note >}}
`kubeadm config print init-defaults`를 실행하고 원하는 파일에 출력을 저장하여 기본값인 `ClusterConfiguration` 오브젝트를 생성할 수 있다.
`kubeadm config print init-defaults`를 실행하고 원하는 파일에 출력을
저장하여 기본값들로 구성된 `ClusterConfiguration` 오브젝트를 생성할 수 있다.
{{< /note >}}
{{< note >}}
`ClusterConfiguration` 오브젝트는 현재 kubeadm 클러스터에서 전역(global)으로 사용된다. 즉, 사용자가 추가하는 모든 플래그는
다른 노드에 있는 동일한 컴포넌트에도 모두 적용될 것이다. 다른 노드에서
컴포넌트별로 개별 구성을 적용하려면 [패치](#patches)를 사용하면 된다.
{{< /note >}}
{{< note >}}
플래그(키)를 복제하거나 동일한 플래그 `--foo`를 여러 번 전달하는 것은 현재 지원하지 않는다.
이 문제를 해결하려면 [패치](#patches)를 사용해야 한다.
{{< /note >}}
<!-- body -->
## APIServer 플래그
### APIServer 플래그
자세한 내용은 [kube-apiserver 레퍼런스 문서](/docs/reference/command-line-tools-reference/kube-apiserver/)를 확인한다.
예시:
사용 예시:
```yaml
apiVersion: kubeadm.k8s.io/v1beta2
apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
kubernetesVersion: v1.16.0
apiServer:
extraArgs:
advertise-address: 192.168.0.103
anonymous-auth: "false"
enable-admission-plugins: AlwaysPullImages,DefaultStorageClass
audit-log-path: /home/johndoe/audit.log
```
## 컨트롤러매니저 플래그
### 컨트롤러매니저 플래그
자세한 내용은 [kube-controller-manager 레퍼런스 문서](/docs/reference/command-line-tools-reference/kube-controller-manager/)를 확인한다.
예시:
사용 예시:
```yaml
apiVersion: kubeadm.k8s.io/v1beta2
apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
kubernetesVersion: v1.16.0
controllerManager:
extraArgs:
cluster-signing-key-file: /home/johndoe/keys/ca.key
bind-address: 0.0.0.0
deployment-controller-sync-period: "50"
```
## 스케줄러 플래그
### 스케줄러 플래그
자세한 내용은 [kube-scheduler 레퍼런스 문서](/docs/reference/command-line-tools-reference/kube-scheduler/)를 확인한다.
예시:
사용 예시:
```yaml
apiVersion: kubeadm.k8s.io/v1beta2
apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
kubernetesVersion: v1.16.0
scheduler:
@@ -85,3 +115,96 @@ scheduler:
readOnly: true
pathType: "File"
```
### Etcd 플래그
자세한 사항은 [etcd 서버 문서](https://etcd.io/docs/)를 확인한다.
사용 예시:
```yaml
apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
etcd:
local:
extraArgs:
election-timeout: 1000
```
## 패치를 통해 컨트롤 플레인 사용자 정의하기 {#patches}
{{< feature-state for_k8s_version="v1.22" state="beta" >}}
Kubeadm을 사용하면 패치 파일이 있는 디렉토리를 개별 노드에 대한 `InitConfiguration`과 `JoinConfiguration`에
전달할 수 있다. 이 패치는 컨트롤 플레인 컴포넌트 메니패스트가 디스크에 기록되기 전에
최종 사용자 정의 단계로 사용될 수 있다.
`--config <YOUR CONFIG YAML>`을 사용하여 이 파일을 `kubeadm init`에 전달할 수 있다.
```yaml
apiVersion: kubeadm.k8s.io/v1beta3
kind: InitConfiguration
nodeRegistration:
patches:
directory: /home/user/somedir
```
{{< note >}}
`kubeadm init`의 경우, `---`로 구분된 `ClusterConfiguration`과 `InitConfiguration`을 모두
포함하는 파일을 전달할 수 있다.
{{< /note >}}
`--config <YOUR CONFIG YAML>`을 사용하여 이 파일을 `kubeadm join`에 전달할 수 있다.
```yaml
apiVersion: kubeadm.k8s.io/v1beta3
kind: JoinConfiguration
nodeRegistration:
patches:
directory: /home/user/somedir
```
디렉토리는 `target[suffix][+patchtype].extension` 형태의 파일을 포함해야 한다.
예를 들면, `kube-apiserver0+merge.yaml` 또는 단순히 `etcd.json`의 형태이다.
- `target`은 `kube-apiserver`, `kube-controller-manager`, `kube-scheduler` 그리고 `etcd` 중 하나가 될 수 있다.
- `patchtype`은 `strategic`, `merge` 그리고 `json` 중 하나가 될 수 있으며
[kubectl에서 지원하는](/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch) 패치 형식을 준수해야 한다.
`patchtype`의 기본값은 `strategic`이다.
- `extension`은 `json` 또는 `yaml` 중 하나여야 한다.
- `suffix`는 어떤 패치가 먼저 적용되는지를 결정하는 데 사용할 수 있는 영숫자 형태의
선택적 문자열이다.
{{< note >}}
`kubeadm upgrade`를 사용하여 kubeadm 노드를 업그레이드하는 경우, 업그레이드 이후에도
사용자 정의를 유지하려면 동일한 패치를 다시 제공해야 한다. 이는 동일한 디렉토리로 지정된 `--patches`
플래그를 사용하여 처리할 수 있다. `kubeadm upgrade`는 동일 목적으로 재사용할 수 있는 구성
API 구조를 현재는 지원하지 않는다.
{{< /note >}}
## kubelet 사용자 정의하기
kubelet을 사용자 정의하려면, `KubeletConfiguration`을 동일한 구성 파일 내에서 `---`로 구분된 `ClusterConfiguration`이나 `InitConfiguration` 다음에 추가하면
된다. 그런 다음 `kubeadm init`에 해당 파일을 전달한다.
{{< note >}}
kubeadm은 클러스터의 모든 노드에 동일한 `KubeletConfiguration`을 적용한다. 노드별 설정을
적용하려면 kubelet 플래그를 덮어쓰기(overrides)로 사용하여, `InitConfiguration` 및
`JoinConfiguration` 모두에서 지원되는 `nodeRegistration.kubeletExtraArgs`에 전달할 수 있다.
일부 kubelet 플래그는 더 이상 사용되지 않는다(deprecated). 따라서 사용하기 전에 [kubelet 참조 문서](/docs/reference/command-line-tools-reference/kubelet)를 통해
상태를 확인해야 한다.
{{< /note >}}
자세한 사항은 [kubeadm을 통해 클러스터의 각 kubelet 구성하기](/docs/setup/production-environment/tools/kubeadm/kubelet-integration)에서 살펴본다.
## kube-proxy 사용자 정의하기
kube-proxy를 사용자 정의하려면, `KubeProxyConfiguration`을 `---`로 구분된 `ClusterConfiguration`이나 `InitConfiguration`
다음에 두고 `kubeadm init`에 전달하면 된다.
자세한 사항은 [API 참조 페이지](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta3)에서 살펴볼 수 있다.
{{< note >}}
kubeadm은 kube-proxy를 {{< glossary_tooltip text="데몬셋" term_id="daemonset" >}}으로 배포한다. 이것은
`KubeProxyConfiguration`이 클러스터의 모든 kube-proxy 인스턴스에 적용된다는 것을 의미한다.
{{< /note >}}
content/ko/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md
+6 -3
View File
@@ -239,8 +239,9 @@ CNI 플러그인 설치(대부분의 파드 네트워크에 필요)
```bash
CNI_VERSION="v0.8.2"
ARCH="amd64"
sudo mkdir -p /opt/cni/bin
curl -L "https://github.com/containernetworking/plugins/releases/download/${CNI_VERSION}/cni-plugins-linux-amd64-${CNI_VERSION}.tgz" | sudo tar -C /opt/cni/bin -xz
curl -L "https://github.com/containernetworking/plugins/releases/download/${CNI_VERSION}/cni-plugins-linux-${ARCH}-${CNI_VERSION}.tgz" | sudo tar -C /opt/cni/bin -xz
```
명령어 파일을 다운로드할 디렉터리 정의
@@ -259,15 +260,17 @@ crictl 설치(kubeadm / Kubelet 컨테이너 런타임 인터페이스(CRI)에
```bash
CRICTL_VERSION="v1.17.0"
curl -L "https://github.com/kubernetes-sigs/cri-tools/releases/download/${CRICTL_VERSION}/crictl-${CRICTL_VERSION}-linux-amd64.tar.gz" | sudo tar -C $DOWNLOAD_DIR -xz
ARCH="amd64"
curl -L "https://github.com/kubernetes-sigs/cri-tools/releases/download/${CRICTL_VERSION}/crictl-${CRICTL_VERSION}-linux-${ARCH}.tar.gz" | sudo tar -C $DOWNLOAD_DIR -xz
```
`kubeadm`, `kubelet`, `kubectl` 설치 및 `kubelet` systemd 서비스 추가
```bash
RELEASE="$(curl -sSL https://dl.k8s.io/release/stable.txt)"
ARCH="amd64"
cd $DOWNLOAD_DIR
sudo curl -L --remote-name-all https://storage.googleapis.com/kubernetes-release/release/${RELEASE}/bin/linux/amd64/{kubeadm,kubelet,kubectl}
sudo curl -L --remote-name-all https://storage.googleapis.com/kubernetes-release/release/${RELEASE}/bin/linux/${ARCH}/{kubeadm,kubelet,kubectl}
sudo chmod +x {kubeadm,kubelet,kubectl}
RELEASE_VERSION="v0.4.0"
content/ko/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md
+35 -24
View File
@@ -67,10 +67,9 @@ weight: 65
| 쿠버네티스 버전 | 윈도우 서버 LTSC 릴리스 | 윈도우 서버 SAC 릴리스 |
| --- | --- | --- | --- |
| *Kubernetes v1.19* | Windows Server 2019 | Windows Server ver 1909, Windows Server ver 2004 |
| *Kubernetes v1.20* | Windows Server 2019 | Windows Server ver 1909, Windows Server ver 2004 |
| *Kubernetes v1.21* | Windows Server 2019 | Windows Server ver 2004, Windows Server ver 20H2 |
| *Kubernetes v1.22* | Windows Server 2019 | Windows Server ver 2004, Windows Server ver 20H2 |
지원 모델을 포함한 다양한 윈도우 서버
서비스 채널에 대한 정보는
@@ -98,12 +97,16 @@ weight: 65
일단 쿠버네티스에서 Hyper-V 격리가 포함된 윈도우 컨테이너를 지원하면,
제한 및 호환성 규칙이 변경될 것이다.
#### 퍼즈(Pause) 이미지
#### 퍼즈(Pause) 이미지 {#pause-image}
Microsoft는 `mcr.microsoft.com/oss/kubernetes/pause:3.4.1`에서
윈도우 퍼즈 인프라 컨테이너를 유지한다.
이외에도 `k8s.gcr.io/pause:3.5`를 통해 쿠버네티스에서 관리하는 다중 아키텍처 이미지를
사용할 수도 있는데, 이 이미지는 리눅스와 윈도우를 모두 지원한다.
쿠버네티스는 윈도우 지원을 포함하는 다중 아키텍처 이미지를 유지보수한다.
쿠버네티스 v1.22의 경우 권장 퍼즈 이미지는 `k8s.gcr.io/pause:3.5`이다.
[소스 코드](https://github.com/kubernetes/kubernetes/tree/master/build/pause)는
GitHub에서 찾을 수 있다.
Microsoft는 리눅스, 윈도우 amd64를 지원하는 다중 아키텍처 이미지를 `mcr.microsoft.com/oss/kubernetes/pause:3.5`에서 유지보수하고 있다.
이 이미지는 쿠버네티스가 유지 관리하는 이미지와 동일한 소스코드에서 생성되었지만, 모든 윈도우 바이너리는 Microsoft에 의해 서명된 [인증 코드](https://docs.microsoft.com/en-us/windows-hardware/drivers/install/authenticode)이다.
프로덕션 환경에서 서명된 바이너리가 필요한 경우, Microsoft가 유지 관리하는 이미지를 사용하는 것을 권장한다.
#### 컴퓨트
@@ -237,7 +240,7 @@ powershell 스크립트로 배포된 다음의 FlexVolume
##### CSI 플러그인
{{< feature-state for_k8s_version="v1.19" state="beta" >}}
{{< feature-state for_k8s_version="v1.22" state="stable" >}}
{{< glossary_tooltip text="CSI" term_id="csi" >}} 플러그인과
관련된 코드는 일반적으로 컨테이너 이미지로 배포되고 데몬셋(DaemonSets)
@@ -246,9 +249,7 @@ powershell 스크립트로 배포된 다음의 FlexVolume
바이너리로 제공된다. CSI 플러그인은 쿠버네티스에서 볼륨 프로비저닝/디-프로비저닝, 볼륨
크기 조정, 쿠버네티스 노드에 볼륨 연결/분리, 파드의 개별 컨테이너에 볼륨
마운트/분리, 스냅샷 및 복제를 사용하여 퍼시스턴트 데이터 백업/복원과 같은
다양한 볼륨 관리 작업을 처리한다. CSI 플러그인은
일반적으로 (각 노드에서 데몬셋으로 실행되는) 노드 플러그인과 컨트롤러
플러그인으로 구성된다.
다양한 볼륨 관리 작업을 처리한다.
CSI 노드 플러그인(특히 블록 디바이스 또는 공유 파일시스템으로 노출된
퍼시스턴트 볼륨과 관련된 플러그인)은 디스크 장치 스캔, 파일 시스템 마운트 등과 같은
@@ -262,6 +263,13 @@ CSI 노드 플러그인에 대한 특권이 필요한 작업은 커뮤니티에
내용은 배포하려는 CSI 플러그인의 배포 가이드를
참조한다.
윈도우 노드에서 CSI 노드 플러그인은 일반적으로 로컬 스토리지 작업을 처리하는
커뮤니티에서 관리하는 [csi-proxy](https://github.com/kubernetes-csi/csi-proxy)에 의해 노출된 API를 호출한다.
설치에 대한 자세한 내용은 윈도우 CSI 플러그인을
배포할 환경의 배포 가이드를 참고한다.
또한 다음 [설치 단계](https://github.com/kubernetes-csi/csi-proxy#installation)를 참고할 수도 있다.
#### 네트워킹
윈도우 컨테이너용 네트워킹은
@@ -1068,9 +1076,8 @@ PodSecurityContext 필드는 윈도우에서 작동하지 않는다. 참조를
kubelet.exe를 등록한다.
```powershell
# Microsoft는 mcr.microsoft.com/oss/kubernetes/pause:1.4.1에서 pause 인프라 컨테이너를 릴리스했다.
nssm install kubelet C:\k\kubelet.exe
nssm set kubelet AppParameters --hostname-override=<hostname> --v=6 --pod-infra-container-image=mcr.microsoft.com/oss/kubernetes/pause:1.4.1 --resolv-conf="" --allow-privileged=true --enable-debugging-handlers --cluster-dns=<DNS-service-IP> --cluster-domain=cluster.local --kubeconfig=c:\k\config --hairpin-mode=promiscuous-bridge --image-pull-progress-deadline=20m --cgroups-per-qos=false --log-dir=<log directory> --logtostderr=false --enforce-node-allocatable="" --network-plugin=cni --cni-bin-dir=c:\k\cni --cni-conf-dir=c:\k\cni\config
nssm set kubelet AppParameters --hostname-override=<hostname> --v=6 --pod-infra-container-image=k8s.gcr.io/pause:3.5 --resolv-conf="" --allow-privileged=true --enable-debugging-handlers --cluster-dns=<DNS-service-IP> --cluster-domain=cluster.local --kubeconfig=c:\k\config --hairpin-mode=promiscuous-bridge --image-pull-progress-deadline=20m --cgroups-per-qos=false --log-dir=<log directory> --logtostderr=false --enforce-node-allocatable="" --network-plugin=cni --cni-bin-dir=c:\k\cni --cni-conf-dir=c:\k\cni\config
nssm set kubelet AppDirectory C:\k
nssm start kubelet
```
@@ -1224,13 +1231,13 @@ PodSecurityContext 필드는 윈도우에서 작동하지 않는다. 참조를
* 내 파드가 "Container Creating"에서 멈췄거나 계속해서 다시 시작된다.
pause 이미지가 OS 버전과 호환되는지 확인한다.
퍼즈 이미지가 OS 버전과 호환되는지 확인한다.
[지침](https://docs.microsoft.com/en-us/virtualization/windowscontainers/kubernetes/deploying-resources)에서는
OS와 컨테이너가 모두 버전 1803이라고 가정한다. 이후 버전의
윈도우가 있는 경우, Insider 빌드와 같이 그에 따라 이미지를
조정해야 한다. 이미지는 Microsoft의
[도커 리포지터리](https://hub.docker.com/u/microsoft/)를 참조한다.
그럼에도 불구하고, pause 이미지 Dockerfile과 샘플 서비스는 이미지가
그럼에도 불구하고, 퍼즈 이미지 Dockerfile과 샘플 서비스는 이미지가
:latest로 태그될 것으로 예상한다.
* DNS 확인(resolution)이 제대로 작동하지 않는다.
@@ -1239,12 +1246,18 @@ PodSecurityContext 필드는 윈도우에서 작동하지 않는다. 참조를
* `kubectl port-forward`가 "unable to do port forwarding: wincat not found"로 실패한다.
이는 쿠버네티스 1.15 및 pause 인프라 컨테이너
이는 쿠버네티스 1.15 및 퍼즈 인프라 컨테이너
`mcr.microsoft.com/oss/kubernetes/pause:1.4.1`에서 구현되었다.
해당 버전 또는 최신 버전을 사용해야 한다. 자체 pause
해당 버전 또는 최신 버전을 사용해야 한다. 자체 퍼즈
인프라 컨테이너를 빌드하려면
[wincat](https://github.com/kubernetes-sigs/sig-windows-tools/tree/master/cmd/wincat)을 포함해야 한다.
윈도우에서 포트 포워딩을 지원하려면 [퍼즈 인프라 컨테이너](#pause-image)를 이용하기 위해서
wincat.exe가 필요하다.
윈도우 OS 버전과 호환되는 지원되는 이미지를 사용하고 있는지 확인해야 한다.
자신만의 퍼즈 인프라 컨테이너를 구축하려면
[wincat](https://github.com/kubernetes/kubernetes/tree/master/build/pause/windows/wincat)을 포함해야 한다.
* 내 윈도우 서버 노드가 프록시 뒤에 있기 때문에 내 쿠버네티스
설치가 실패한다.
@@ -1256,19 +1269,17 @@ PodSecurityContext 필드는 윈도우에서 작동하지 않는다. 참조를
[Environment]::SetEnvironmentVariable("HTTPS_PROXY", "http://proxy.example.com:443/", [EnvironmentVariableTarget]::Machine)
```
* `pause` 컨테이너란 무엇인가?
* 퍼즈(`pause`) 컨테이너란 무엇인가?
쿠버네티스 파드에서는 컨테이너 엔드포인트를 호스팅하기 위해
먼저 인프라 또는 "pause" 컨테이너가 생성된다. 인프라 및 워커 컨테이너를 포함하여
먼저 인프라 또는 "퍼즈" 컨테이너가 생성된다. 인프라 및 워커 컨테이너를 포함하여
동일한 파드에 속하는 컨테이너는 공통 네트워크 네임스페이스 및
엔드포인트(동일한 IP 및 포트 공간)를 공유한다. 네트워크 구성을 잃지 않고
워커 컨테이너가 충돌하거나 다시 시작되도록 하려면 pause 컨테이너가
워커 컨테이너가 충돌하거나 다시 시작되도록 하려면 퍼즈 컨테이너가
필요하다.
"pause" (인프라) 이미지는 Microsoft Container Registry(MCR)에서
호스팅된다. `mcr.microsoft.com/oss/kubernetes/pause:1.4.1`을 사용하여 접근할 수 있다.
자세한 내용은
[DOCKERFILE](https://github.com/kubernetes-sigs/windows-testing/blob/master/images/pause/Dockerfile)을 참고한다.
퍼즈 이미지 추천 버전을 찾기 위해서는
[퍼즈 이미지](#pause-image)를 참고한다.
### 추가 조사
content/ko/docs/setup/production-environment/windows/user-guide-windows-containers.md
+8 -8
View File
@@ -20,8 +20,8 @@ weight: 75
## 시작하기 전에
* [윈도우 서버에서 운영하는 마스터와 워커 노드](/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes)를
포함한 쿠버네티스 클러스터를 생성한다.
* 컨트롤 플레인과 [윈도우 서버로 운영되는 워커 노드](/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes/)를
포함하는 쿠버네티스 클러스터를 생성한다.
* 쿠버네티스에서 서비스와 워크로드를 생성하고 배포하는 것은 리눅스나 윈도우 컨테이너
모두 비슷한 방식이라는 것이 중요하다.
[Kubectl 커맨드](/ko/docs/reference/kubectl/overview/)로 클러스터에 접속하는 것은 동일하다.
@@ -100,15 +100,15 @@ spec:
1. 이 디플로이먼트가 성공적인지 확인한다. 다음을 검토하자.
* 윈도우 노드에 파드당 두 컨테이너가 존재하는지 확인하려면, `docker ps`를 사용한다.
* 리눅스 마스터에서 나열된 두 파드가 존재하는지 확인하려면, `kubectl get pods`를 사용한다.
* 네트워크를 통한 노드에서 파드로의 통신이 되는지 확인하려면, 리눅스 마스터에서 `curl`을
* 리눅스 컨트롤 플레인 노드에서 나열된 두 파드가 존재하는지 확인하려면, `kubectl get pods`를 사용한다.
* 네트워크를 통한 노드에서 파드로의 통신이 되는지 확인하려면, 리눅스 컨트롤 플레인 노드에서 `curl`을
파드 IP 주소의 80 포트로 실행하여 웹 서버 응답을 확인한다.
* 파드 간 통신이 되는지 확인하려면, `docker exec` 나 `kubectl exec`를 이용해 파드 간에
핑(ping)한다(윈도우 노드가 2대 이상이라면, 서로 다른 노드에 있는 파드 간 통신도 확인할 수 있다).
* 서비스에서 파드로의 통신이 되는지 확인하려면, 리눅스 마스터와 독립 파드에서 `curl`을 가상 서비스
* 서비스에서 파드로의 통신이 되는지 확인하려면, 리눅스 컨트롤 플레인 노드와 독립 파드에서 `curl`을 가상 서비스
IP 주소(`kubectl get services`로 볼 수 있는)로 실행한다.
* 서비스 검색(discovery)이 되는지 확인하려면, 쿠버네티스 [기본 DNS 접미사](/ko/docs/concepts/services-networking/dns-pod-service/#서비스)와 서비스 이름으로 `curl`을 실행한다.
* 인바운드 연결이 되는지 확인하려면, 클러스터 외부 장비나 리눅스 마스터에서 NodePort로 `curl`을 실행한다.
* 인바운드 연결이 되는지 확인하려면, 클러스터 외부 장비나 리눅스 컨트롤 플레인 노드에서 NodePort로 `curl`을 실행한다.
* 아웃바운드 연결이 되는지 확인하려면, `kubectl exec`를 이용해서 파드에서 외부 IP 주소로 `curl`을 실행한다.
{{< note >}}
@@ -178,8 +178,8 @@ GMSA로 구성한 컨테이너는 GMSA로 구성된 신원을 들고 있는 동
예를 들면, `--register-with-taints='os=windows:NoSchedule'`
모든 윈도우 노드에 테인트를 추가하여 아무 것도 거기에 스케줄링하지 않게 될 것이다(존재하는 리눅스 파드를 포함하여).
윈도우 파드가 윈도우 노드에 스케줄링되려면,
윈도우를 선택하기 위한 노드 셀렉터 및 적합하게 일치하는 톨러레이션이 모두 필요하다.
윈도우 파드가 윈도우 노드에 스케줄링되도록 하려면,
윈도우 노드가 선택되도록 하기 위한 노드 셀렉터 및 적합하게 일치하는 톨러레이션이 모두 필요하다.
```yaml
nodeSelector:
content/ko/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md
+2 -2
View File
@@ -31,7 +31,7 @@ min-kubernetes-server-version: v1.10
1. MongoDB를 실행하기 위해 디플로이먼트를 생성한다.
```shell
kubectl apply -f https://k8s.io/examples/application/guestbook/mongo-deployment.yaml
kubectl apply -f https://k8s.io/examples/application/mongodb/mongo-deployment.yaml
```
성공적인 명령어의 출력은 디플로이먼트가 생성됐다는 것을 확인해준다.
@@ -84,7 +84,7 @@ min-kubernetes-server-version: v1.10
2. MongoDB를 네트워크에 노출시키기 위해 서비스를 생성한다.
```shell
kubectl apply -f https://k8s.io/examples/application/guestbook/mongo-service.yaml
kubectl apply -f https://k8s.io/examples/application/mongodb/mongo-service.yaml
```
성공적인 커맨드의 출력은 서비스가 생성되었다는 것을 확인해준다.
content/ko/docs/tasks/administer-cluster/access-cluster-api.md
+1 -1
View File
@@ -30,7 +30,7 @@ content_type: task
kubectl config view
```
많은 [예제](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/)는 kubectl 사용에 대한 소개를
많은 [예제](https://github.com/kubernetes/examples/tree/master/)는 kubectl 사용에 대한 소개를
제공한다. 전체 문서는 [kubectl 매뉴얼](/ko/docs/reference/kubectl/overview/)에 있다.
### REST API에 직접 접근
content/ko/docs/tasks/administer-cluster/dns-custom-nameservers.md
+1 -1
View File
@@ -23,7 +23,7 @@ DNS 변환(DNS resolution) 절차를 사용자 정의하는 방법을 설명한
## 소개
DNS는 _애드온 관리자_ 인 [클러스터 애드온](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/README.md)을
DNS는 _애드온 관리자_ 인 [클러스터 애드온](https://releases.k8s.io/master/cluster/addons/README.md)을
사용하여 자동으로 시작되는 쿠버네티스
내장 서비스이다.
content/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md
+2 -2
View File
@@ -158,7 +158,7 @@ Install-WindowsFeature -Name containers
#### wins, kubelet 및 kubeadm 설치
```PowerShell
curl.exe -LO https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/PrepareNode.ps1
curl.exe -LO https://raw.githubusercontent.com/kubernetes-sigs/sig-windows-tools/master/kubeadm/scripts/PrepareNode.ps1
.\PrepareNode.ps1 -KubernetesVersion {{< param "fullversion" >}}
```
@@ -201,7 +201,7 @@ curl.exe -LO https://github.com/kubernetes-sigs/sig-windows-tools/releases/lates
#### wins, kubelet 및 kubeadm 설치
```PowerShell
curl.exe -LO https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/PrepareNode.ps1
curl.exe -LO https://raw.githubusercontent.com/kubernetes-sigs/sig-windows-tools/master/kubeadm/scripts/PrepareNode.ps1
.\PrepareNode.ps1 -KubernetesVersion {{< param "fullversion" >}} -ContainerRuntime containerD
```
content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md
+13 -3
View File
@@ -128,6 +128,16 @@ kubeadm 1.17 이전 버전에는 `kubeadm upgrade node` 명령에서
이 명령은 `/etc/kubernetes/pki` 에 저장된 CA(또는 프론트 프록시 CA) 인증서와 키를 사용하여 갱신을 수행한다.
명령을 실행한 후에는 컨트롤 플레인 파드를 재시작해야 한다.
이는 현재 일부 구성 요소 및 인증서에 대해 인증서를 동적으로 다시 로드하는 것이 지원되지 않기 때문이다.
[스태틱(static) 파드](/ko/docs/tasks/configure-pod-container/static-pod/)는 API 서버가 아닌 로컬 kubelet에서 관리되므로
kubectl을 사용하여 삭제 및 재시작할 수 없다.
스태틱 파드를 다시 시작하려면 `/etc/kubernetes/manifests/`에서 매니페스트 파일을 일시적으로 제거하고
20초를 기다리면 된다 ([KubeletConfiguration struct](/docs/reference/config-api/kubelet-config.v1beta1/)의 `fileCheckFrequency` 값을 참고한다).
파드가 매니페스트 디렉터리에 더 이상 없는 경우 kubelet은 파드를 종료한다.
그런 다음 파일을 다시 이동할 수 있으며 또 다른 `fileCheckFrequency` 기간이 지나면,
kubelet은 파드를 생성하고 구성 요소에 대한 인증서 갱신을 완료할 수 있다.
{{< warning >}}
HA 클러스터를 실행 중인 경우, 모든 컨트롤 플레인 노드에서 이 명령을 실행해야 한다.
{{< /warning >}}
@@ -161,10 +171,10 @@ HA 클러스터를 실행 중인 경우, 모든 컨트롤 플레인 노드에서
빌트인 서명자를 활성화하려면, `--cluster-signing-cert-file` 와 `--cluster-signing-key-file` 플래그를 전달해야 한다.
새 클러스터를 생성하는 경우, kubeadm [구성 파일](/docs/reference/config-api/kubeadm-config.v1beta2/)을 사용할 수 있다.
새 클러스터를 생성하는 경우, kubeadm [구성 파일](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta3)을 사용할 수 있다.
```yaml
apiVersion: kubeadm.k8s.io/v1beta2
apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
controllerManager:
extraArgs:
@@ -223,7 +233,7 @@ TLS로 보안되지 않음을 의미한다.
다음의 최소 구성을 `kubeadm init` 에 전달해야 한다.
```yaml
apiVersion: kubeadm.k8s.io/v1beta2
apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
---
apiVersion: kubelet.config.k8s.io/v1beta1
content/ko/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md
+38 -23
View File
@@ -22,44 +22,59 @@ weight: 20
실리움에 쉽게 친숙해지기 위해
Minikube에 실리움을 기본적인 데몬셋으로 설치를 수행하는
[실리움 쿠버네티스 시작하기 안내](https://docs.cilium.io/en/stable/gettingstarted/minikube/)를 따라 해볼 수 있다.
[실리움 쿠버네티스 시작하기 안내](https://docs.cilium.io/en/stable/gettingstarted/k8s-install-default/)를 따라 해볼 수 있다.
Minikube를 시작하려면 최소 버전으로 >= v1.3.1 이 필요하고,
Minikube를 시작하려면 최소 버전으로 >= v1.5.2 이 필요하고,
다음의 실행 파라미터로 실행한다.
```shell
minikube version
```
```
minikube version: v1.3.1
minikube version: v1.5.2
```
```shell
minikube start --network-plugin=cni --memory=4096
minikube start --network-plugin=cni
```
BPF 파일시스템을 마운트한다
minikube의 경우 CLI 도구를 사용하여 실리움을 설치할 수 있다.
실리움은 클러스터 구성을 자동으로 감지하고
성공적인 설치를 위해 적절한 구성 요소를 설치한다.
```shell
minikube ssh -- sudo mount bpffs -t bpf /sys/fs/bpf
curl -LO https://github.com/cilium/cilium-cli/releases/latest/download/cilium-linux-amd64.tar.gz
sudo tar xzvfC cilium-linux-amd64.tar.gz /usr/local/bin
rm cilium-linux-amd64.tar.gz
cilium install
```
Minikube에서 실리움의 데몬셋 구성과 적절한 RBAC 설정을 포함하는 필요한 구성을
간단한 ``올인원`` YAML 파일로 배포할 수 있다.
```shell
kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.8/install/kubernetes/quick-install.yaml
```
```
configmap/cilium-config created
serviceaccount/cilium created
serviceaccount/cilium-operator created
clusterrole.rbac.authorization.k8s.io/cilium created
clusterrole.rbac.authorization.k8s.io/cilium-operator created
clusterrolebinding.rbac.authorization.k8s.io/cilium created
clusterrolebinding.rbac.authorization.k8s.io/cilium-operator created
daemonset.apps/cilium create
deployment.apps/cilium-operator created
🔮 Auto-detected Kubernetes kind: minikube
✨ Running "minikube" validation checks
✅ Detected minikube version "1.20.0"
ℹ️ Cilium version not set, using default version "v1.10.0"
🔮 Auto-detected cluster name: minikube
🔮 Auto-detected IPAM mode: cluster-pool
🔮 Auto-detected datapath mode: tunnel
🔑 Generating CA...
2021/05/27 02:54:44 [INFO] generate received request
2021/05/27 02:54:44 [INFO] received CSR
2021/05/27 02:54:44 [INFO] generating key: ecdsa-256
2021/05/27 02:54:44 [INFO] encoded CSR
2021/05/27 02:54:44 [INFO] signed certificate with serial number 48713764918856674401136471229482703021230538642
🔑 Generating certificates for Hubble...
2021/05/27 02:54:44 [INFO] generate received request
2021/05/27 02:54:44 [INFO] received CSR
2021/05/27 02:54:44 [INFO] generating key: ecdsa-256
2021/05/27 02:54:44 [INFO] encoded CSR
2021/05/27 02:54:44 [INFO] signed certificate with serial number 3514109734025784310086389188421560613333279574
🚀 Creating Service accounts...
🚀 Creating Cluster roles...
🚀 Creating ConfigMap...
🚀 Creating Agent DaemonSet...
🚀 Creating Operator Deployment...
⌛ Waiting for Cilium to be installed...
```
시작하기 안내서의 나머지 부분은 예제 애플리케이션을 이용하여
@@ -82,14 +97,14 @@ L3/L4(예, IP 주소 + 포트) 모두의 보안 정책뿐만 아니라 L7(예, H
파드의 목록을 보려면 다음을 실행한다.
```shell
kubectl get pods --namespace=kube-system
kubectl get pods --namespace=kube-system -l k8s-app=cilium
```
다음과 유사한 파드의 목록을 볼 것이다.
```console
NAME READY STATUS RESTARTS AGE
cilium-6rxbd 1/1 Running 0 1m
cilium-kkdhz 1/1 Running 0 3m23s
...
```
content/ko/docs/tasks/configmap-secret/managing-secret-using-kubectl.md
+1 -1
View File
@@ -67,7 +67,7 @@ kubectl create secret generic db-user-pass \
다음 커맨드를 실행한다.
```shell
kubectl create secret generic dev-db-secret \
kubectl create secret generic db-user-pass \
--from-literal=username=devuser \
--from-literal=password='S!B\*d$zDsb='
```
content/ko/docs/tasks/debug-application-cluster/debug-running-pod.md
+340
View File
@@ -0,0 +1,340 @@
---
title: 동작 중인 파드 디버그
content_type: task
---
<!-- overview -->
이 페이지는 노드에서 동작 중인(혹은 크래시된) 파드를 디버그하는 방법에 대해 설명한다.
## {{% heading "prerequisites" %}}
* 여러분의 {{< glossary_tooltip text="파드" term_id="pod" >}}는 이미 스케줄링 되어
동작하고 있을 것이다. 만약 파드가 아직 동작중이지 않다면, [애플리케이션
트러블슈팅](/docs/tasks/debug-application-cluster/debug-application/)을 참고한다.
* 일부 고급 디버깅 과정에서는 해당 파드가 어떤 노드에서 동작하고 있는지
알아야 하고, 해당 노드에서 쉘 명령어를 실행시킬 수 있어야 한다.
`kubectl`을 사용하는 일반적인 디버깅 과정에서는 이러한 접근 권한이 필요하지 않다.
<!-- steps -->
## 파드의 로그 확인하기 {#examine-pod-logs}
먼저, 확인하고자 하는 컨테이너의 로그를 확인한다.
```shell
kubectl logs ${POD_NAME} ${CONTAINER_NAME}
```
만약 컨테이너가 이전에 크래시 되었다면, 다음의 명령을 통해 컨테이너의 크래시 로그를 살펴볼 수 있다.
```shell
kubectl logs --previous ${POD_NAME} ${CONTAINER_NAME}
```
## exec를 통해 컨테이너 디버깅하기 {#container-exec}
만약 {{< glossary_tooltip text="컨테이너 이미지" term_id="image" >}}에
디버깅 도구가 포함되어 있다면, `kubectl exec`을 통해 특정 컨테이너에서 해당 명령들을
실행할 수 있다. (리눅스나 윈도우 OS를 기반으로 만들어진 이미지에는 대부분 디버깅 도구를 포함하고
있다.)
```shell
kubectl exec ${POD_NAME} -c ${CONTAINER_NAME} -- ${CMD} ${ARG1} ${ARG2} ... ${ARGN}
```
{{< note >}}
`-c ${CONTAINER_NAME}` 인자는 선택적이다. 만약 하나의 컨테이너만 포함된 파드라면 해당 옵션을 생략할 수 있다.
{{< /note >}}
예를 들어, 동작 중인 카산드라 파드의 로그를 살펴보기 위해서는 다음과 같은 명령을 실행할 수 있다.
```shell
kubectl exec cassandra -- cat /var/log/cassandra/system.log
```
`kubectl exec`에 `-i`와 `-t` 옵션을 사용해서 터미널에서 접근할 수 있는 쉘을 실행시킬 수도 있다.
예를 들면 다음과 같다.
```shell
kubectl exec -it cassandra -- sh
```
더욱 상세한 내용은 다음 [동작중인 컨테이너의 쉘에 접근하기](
/docs/tasks/debug-application-cluster/get-shell-running-container/)를 참고하라.
## 임시(ephemeral) 디버그 컨테이너를 사용해서 디버깅하기 {#ephemeral-container}
{{< feature-state state="alpha" for_k8s_version="v1.18" >}}
컨테이너가 크래시 됐거나 [distroless 이미지](https://github.com/GoogleContainerTools/distroless)처럼
컨테이너 이미지에 디버깅 도구를 포함하고 있지 않아
`kubectl exec`가 충분하지 않을 경우에는
{{< glossary_tooltip text="임시(Ephemeral) 컨테이너" term_id="ephemeral-container" >}}를 사용하는 것이
인터랙티브한 트러블슈팅에 유용하다. `kubectl` `v1.18`
버전부터는 임시 컨테이너를 생성할 수 있는 알파 단계의
명령어가 있다.
### 임시 컨테이너를 사용한 디버깅 예시 {#ephemeral-container-example}
{{< note >}}
이 섹션에서 소개하는 예시를 사용하기 위해서는
여러분의 클러스터에 `EphemeralContainers` [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)가
활성화되어 있어야 하고 `kubectl`의 버전이 v1.18 이상이어야 한다.
{{< /note >}}
`kubectl debug` 명령어를 사용해서 동작 중인 파드에 임시 컨테이너를 추가할 수 있다.
먼저, 다음과 같이 파드를 추가한다.
```shell
kubectl run ephemeral-demo --image=k8s.gcr.io/pause:3.1 --restart=Never
```
이 섹션의 예시에서는 디버깅 도구가 포함되지 않은 이미지의 사례를 보여드리기 위해
`pause` 컨테이너 이미지를 사용했는데, 이 대신 어떠한 이미지를 사용해도
될 것이다.
만약 `kubectl exec`을 통해 쉘을 생성하려 한다면 다음과 같은 에러를
확인할 수 있을 텐데, 그 이유는 이 이미지에 쉘이 존재하지 않기 때문이다.
```shell
kubectl exec -it ephemeral-demo -- sh
```
```
OCI runtime exec failed: exec failed: container_linux.go:346: starting container process caused "exec: \"sh\": executable file not found in $PATH": unknown
```
이 명령어 대신 `kubectl debug`을 사용해서 디버깅 컨테이너를 생성할 수 있다.
만약 `-i`/`--interactive` 인자를 사용한다면, `kubectl`은 임시
컨테이너의 콘솔에 자동으로 연결할 것이다.
```shell
kubectl debug -it ephemeral-demo --image=busybox --target=ephemeral-demo
```
```
Defaulting debug container name to debugger-8xzrl.
If you don't see a command prompt, try pressing enter.
/ #
```
이 명령어는 새로운 busybox 컨테이너를 추가하고 해당 컨테이너로 연결한다. `--target`
파라미터를 사용하면 다른 컨테이너의 프로세스 네임스페이스를 대상으로 하게 된다. 여기서는
이 옵션이 꼭 필요한데, `kubectl run`이 생성하는 파드에 대해
[프로세스 네임스페이스 공유](/docs/tasks/configure-pod-container/share-process-namespace/)를
활성화하지 않기 때문이다.
{{< note >}}
`--target` 파라미터는 사용 중인 {{< glossary_tooltip text="컨테이너 런타임" term_id="container-runtime" >}}에서
지원해야지만 사용할 수 있다. 만일 지원되지 않는다면,
임시 컨테이너가 시작되지 않을 수 있거나 독립적인 프로세스
네임스페이스를 가지고 시작될 수 있다.
{{< /note >}}
`kubectl describe` 명령을 사용하면 새롭게 생성된 임시 컨테이너의 상태를 확인할 수 있다.
```shell
kubectl describe pod ephemeral-demo
```
```
...
Ephemeral Containers:
debugger-8xzrl:
Container ID: docker://b888f9adfd15bd5739fefaa39e1df4dd3c617b9902082b1cfdc29c4028ffb2eb
Image: busybox
Image ID: docker-pullable://busybox@sha256:1828edd60c5efd34b2bf5dd3282ec0cc04d47b2ff9caa0b6d4f07a21d1c08084
Port: <none>
Host Port: <none>
State: Running
Started: Wed, 12 Feb 2020 14:25:42 +0100
Ready: False
Restart Count: 0
Environment: <none>
Mounts: <none>
...
```
디버깅이 다 끝나면 `kubectl delete`을 통해 파드를 제거할 수 있다.
```shell
kubectl delete pod ephemeral-demo
```
## 파드의 복제본을 이용해서 디버깅하기
때때로 파드의 설정 옵션에 따라 특정 상황에서 트러블슈팅을 하기가 어려울 수 있다.
예를 들어, 만일 여러분의 컨테이너 이미지가 쉘을 포함하고 있지 않거나, 여러분의
애플리케이션이 컨테이너 시작에서 크래시가 발생한다면 `kubectl exec`을 이용해서
컨테이너를 트러블슈팅할 수 없을 수 있다. 이러한 상황에서는 `kubectl debug`을 사용해서
파드의 복제본을 디버깅을 위한 추가적인 설정 옵션과 함께 생성할 수 있다.
### 새 컨테이너와 함께 파드의 복제본 생성하기
만일 여러분의 애플리케이션이 동작은 하고 있지만 예상과는 다르게 동작하는 경우,
파드의 복제본에 새로운 컨테이너를 추가함으로써 추가적인 트러블슈팅 도구들을
파드에 함께 추가할 수 있다.
가령, 여러분의 애플리케이션 컨테이너 이미지는 `busybox`를 기반으로 하고 있는데
여러분은 `busybox`에는 없는 디버깅 도구를 필요로 한다고 가정해 보자. 이러한
시나리오는 `kubectl run` 명령을 통해 시뮬레이션 해볼 수 있다.
```shell
kubectl run myapp --image=busybox --restart=Never -- sleep 1d
```
다음의 명령을 실행시켜 디버깅을 위한 새로운 우분투 컨테이너와 함께 `myapp-debug`이란
이름의 `myapp` 컨테이너 복제본을 생성할 수 있다.
```shell
kubectl debug myapp -it --image=ubuntu --share-processes --copy-to=myapp-debug
```
```
Defaulting debug container name to debugger-w7xmf.
If you don't see a command prompt, try pressing enter.
root@myapp-debug:/#
```
{{< note >}}
* 만일 여러분이 새로 생성되는 컨테이너의 이름을 `--container` 플래그와 함께 지정하지 않는다면,
`kubectl debug`는 자동으로 새로운 컨테이너 이름을 생성한다.
* `-i` 플래그를 사용하면 `kubectl debug` 명령이 새로운 컨테이너에 기본적으로 연결되게 된다.
이러한 동작은 `--attach=false`을 지정하여 방지할 수 있다. 만일 여러분의 세션이
연결이 끊어진다면 `kubectl attach`를 사용해서 다시 연결할 수 있다.
* `--share-processes` 옵션은 이 파드에 있는 컨테이너가 해당 파드에 속한 다른 컨테이너의
프로세스를 볼 수 있도록 한다. 이 옵션이 어떻게 동작하는지에 대해 더 알아보기 위해서는
다음의 [파드의 컨테이너 간 프로세스 네임스페이스 공유](
/docs/tasks/configure-pod-container/share-process-namespace/)를 참고하라.
{{< /note >}}
사용이 모두 끝나면, 디버깅에 사용된 파드를 잊지 말고 정리한다.
```shell
kubectl delete pod myapp myapp-debug
```
### 명령어를 변경하며 파드의 복제본 생성하기
때때로 컨테이너의 명령어를 변경하는 것이 유용한 경우가 있는데, 예를 들면 디버그 플래그를 추가하기
위해서나 애플리케이션이 크래시 되는 경우이다.
다음의 `kubectl run` 명령을 통해 즉각적으로 크래시가 발생하는 애플리케이션의
사례를 시뮬레이션해 볼 수 있다.
```
kubectl run --image=busybox myapp -- false
```
`kubectl describe pod myapp` 명령을 통해 이 컨테이너에 크래시가 발생하고 있음을 확인할 수 있다.
```
Containers:
myapp:
Image: busybox
...
Args:
false
State: Waiting
Reason: CrashLoopBackOff
Last State: Terminated
Reason: Error
Exit Code: 1
```
이러한 경우에 `kubectl debug`을 통해 명령어를 지정함으로써 해당 파드의
복제본을 인터랙티브 쉘로 생성할 수 있다.
```
kubectl debug myapp -it --copy-to=myapp-debug --container=myapp -- sh
```
```
If you don't see a command prompt, try pressing enter.
/ #
```
이제 인터랙티브 쉘에 접근할 수 있으니 파일 시스템 경로를 확인하거나
동작 중인 컨테이너의 명령어를 직접 확인하는 등의 작업이 가능하다.
{{< note >}}
* 특정 컨테이너의 명령어를 변경하기 위해서는 `--container` 옵션을 통해 해당 컨테이너의
이름을 지정해야만 한다. 이름을 지정하지 않는다면 `kubectl debug`은 이전에 지정한 명령어를
그대로 사용해서 컨테이너를 생성할 것이다.
* 기본적으로 `-i` 플래그는 `kubectl debug` 명령이 컨테이너에 바로 연결되도록 한다.
이러한 동작을 방지하기 위해서는 `--attach=false` 옵션을 지정할 수 있다. 만약 여러분이 세션이
종료된다면 `kubectl attach` 명령을 통해 다시 연결할 수 있다.
{{< /note >}}
사용이 모두 끝나면, 디버깅에 사용된 파드들을 잊지 말고 정리한다.
```shell
kubectl delete pod myapp myapp-debug
```
### 컨테이너 이미지를 변경하며 파드의 복제본 생성하기
특정한 경우에 여러분은 제대로 동작하지 않는 파드의 이미지를
기존 프로덕션 컨테이너 이미지에서 디버깅 빌드나 추가적인 도구를 포함한
이미지로 변경하고 싶을 수 있다.
이 사례를 보여주기 위해 `kubectl run` 명령을 통해 파드를 생성하였다.
```
kubectl run myapp --image=busybox --restart=Never -- sleep 1d
```
여기서는 `kubectl debug` 명령을 통해 해당 컨테이너 이미지를 `ubuntu`로 변경하며
복제본을 생성하였다.
```
kubectl debug myapp --copy-to=myapp-debug --set-image=*=ubuntu
```
`--set-image`의 문법은 `kubectl set image`와 동일하게 `container_name=image`
형식의 문법을 사용한다. `*=ubuntu`라는 의미는 모든 컨테이너의 이미지를 `ubuntu`로
변경하겠다는 의미이다.
사용이 모두 끝나면, 디버깅에 사용된 파드를 잊지 말고 정리한다.
```shell
kubectl delete pod myapp myapp-debug
```
## 노드의 쉘을 사용해서 디버깅하기 {#node-shell-session}
만약 위의 어떠한 방법도 사용할 수 없다면, 파드가 현재 동작 중인 노드를 찾아
호스트의 네임스페이스로 동작하는 특권 파드를 생성할 수 있다.
다음 `kubectl debug` 명령을 통해 해당 노드에서 인터랙티브한 쉘을 생성할 수 있다.
```shell
kubectl debug node/mynode -it --image=ubuntu
```
```
Creating debugging pod node-debugger-mynode-pdx84 with container debugger on node mynode.
If you don't see a command prompt, try pressing enter.
root@ek8s:/#
```
노드에서 디버깅 세션을 생성할 때 유의해야 할 점은 다음과 같다.
* `kubectl debug`는 노드의 이름에 기반해 새로운 파드의 이름을
자동으로 생성한다.
* 컨테이너는 호스트 네임스페이스(IPC, 네트워크, PID 네임스페이스)에서 동작한다.
* 노드의 루트 파일시스템은 `/host`에 마운트된다.
사용이 모두 끝나면, 디버깅에 사용된 파드를 잊지 말고 정리한다.
```shell
kubectl delete pod node-debugger-mynode-pdx84
```
content/ko/docs/tasks/inject-data-application/define-interdependent-environment-variables.md
+77
View File
@@ -0,0 +1,77 @@
---
title: 종속 환경 변수 정의하기
content_type: task
weight: 20
---
<!-- overview -->
본 페이지는 쿠버네티스 파드의 컨테이너를 위한 종속 환경 변수를
정의하는 방법에 대해 설명한다.
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}}
<!-- steps -->
## 컨테이너를 위한 종속 환경 변수 정의하기
파드를 생성할 때, 파드 안에서 동작하는 컨테이너를 위한 종속 환경 변수를 설정할 수 있다.
종속 환경 변수를 설정하려면, 구성 파일에서 `env`의 `value`에 $(VAR_NAME)을 사용한다.
이 예제에서, 한 개의 컨테이너를 실행하는 파드를 생성한다. 파드를 위한 구성 파일은 일반적인 방식으로 정의된 종속 환경 변수를 정의한다. 다음은 파드를 위한 구성 매니페스트 예시이다.
{{< codenew file="pods/inject/dependent-envars.yaml" >}}
1. YAML 구성 파일을 활용해 파드를 생성한다.
```shell
kubectl apply -f https://k8s.io/examples/pods/inject/dependent-envars.yaml
```
```
pod/dependent-envars-demo created
```
2. 실행 중인 파드의 목록을 조회한다.
```shell
kubectl get pods dependent-envars-demo
```
```
NAME READY STATUS RESTARTS AGE
dependent-envars-demo 1/1 Running 0 9s
```
3. 파드 안에서 동작 중인 컨테이너의 로그를 확인한다.
```shell
kubectl logs pod/dependent-envars-demo
```
```
UNCHANGED_REFERENCE=$(PROTOCOL)://172.17.0.1:80
SERVICE_ADDRESS=https://172.17.0.1:80
ESCAPED_REFERENCE=$(PROTOCOL)://172.17.0.1:80
```
위에서 보듯이, `SERVICE_ADDRESS`는 올바른 종속성 참조, `UNCHANGED_REFERENCE`는 잘못된 종속성 참조를 정의했으며 `ESCAPED_REFERENCE`는 종속성 참조를 건너뛴다.
환경 변수가 참조될 때 해당 환경 변수가 미리 정의되어 있으면 `SERVICE_ADDRESS`의 경우와 같이 참조를 올바르게 해석할 수 있다.
환경 변수가 정의되지 않았거나 일부 변수만 포함된 경우, 정의되지 않은 환경 변수는 `UNCHANGED_REFERENCE`의 경우와 같이 일반 문자열로 처리된다.
일반적으로 환경 변수 해석에 실패하더라도 컨테이너의 시작을 막지는 않는다.
`$(VAR_NAME)` 구문은 이중 $로 이스케이프될 수 있다. (예: `$$(VAR_NAME)`)
이스케이프된 참조는 참조된 변수가 정의되었는지 여부에 관계없이 해석을 수행하지 않는다.
이는 위의 `ESCAPED_REFERENCE`를 통해 확인할 수 있다.
## {{% heading "whatsnext" %}}
* [환경 변수](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)에 대해 알아본다.
* [EnvVarSource](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvarsource-v1-core)를 확인한다.
content/ko/docs/tasks/inject-data-application/distribute-credentials-secure.md
+256
View File
@@ -0,0 +1,256 @@
---
title: 시크릿(Secret)을 사용하여 안전하게 자격증명 배포하기
content_type: task
weight: 50
min-kubernetes-server-version: v1.6
---
<!-- overview -->
본 페이지는 암호 및 암호화 키와 같은 민감한 데이터를 파드에 안전하게
주입하는 방법을 설명한다.
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}}
### 시크릿 데이터를 base-64 표현으로 변환하기
사용자 이름 `my-app`과 비밀번호 `39528$vdg7Jb`의 두 가지 시크릿 데이터가 필요하다고 가정한다.
먼저 base64 인코딩 도구를 사용하여 사용자 이름과 암호를 base64 표현으로 변환한다. 다음은 일반적으로 사용 가능한 base64 프로그램을 사용하는 예제이다.
```shell
echo -n 'my-app' | base64
echo -n '39528$vdg7Jb' | base64
```
사용자 이름의 base-64 표현이 `bXktYXBw`이고 암호의 base-64 표현이 `Mzk1MjgkdmRnN0pi`임을
출력을 통해 확인할 수 있다.
{{< caution >}}
사용자의 OS가 신뢰하는 로컬 툴을 사용하여 외부 툴의 보안 위험을 줄이자.
{{< /caution >}}
<!-- steps -->
## 시크릿 생성하기
다음은 사용자 이름과 암호가 들어 있는 시크릿을 생성하는 데 사용할 수 있는
구성 파일이다.
{{< codenew file="pods/inject/secret.yaml" >}}
1. 시크릿을 생성한다.
```shell
kubectl apply -f https://k8s.io/examples/pods/inject/secret.yaml
```
2. 시크릿에 대한 정보를 확인한다.
```shell
kubectl get secret test-secret
```
Output:
```
NAME TYPE DATA AGE
test-secret Opaque 2 1m
```
3. 시크릿에 대한 자세한 정보를 확인한다.
```shell
kubectl describe secret test-secret
```
Output:
```
Name: test-secret
Namespace: default
Labels: <none>
Annotations: <none>
Type: Opaque
Data
====
password: 13 bytes
username: 7 bytes
```
### kubectl로 직접 시크릿 생성하기
Base64 인코딩 단계를 건너뛰려면 `kubectl create secret` 명령을 사용하여
동일한 Secret을 생성할 수 있다. 다음은 예시이다.
```shell
kubectl create secret generic test-secret --from-literal='username=my-app' --from-literal='password=39528$vdg7Jb'
```
이와 같이 더 편리하게 사용할 수 있다. 앞에서 설명한 자세한 접근 방식은 각 단계를
명시적으로 실행하여 현재 상황을 확인할 수 있다.
## 볼륨을 통해 시크릿 데이터에 접근할 수 있는 파드 생성하기
다음은 파드를 생성하는 데 사용할 수 있는 구성 파일이다.
{{< codenew file="pods/inject/secret-pod.yaml" >}}
1. 파드를 생성한다.
```shell
kubectl apply -f https://k8s.io/examples/pods/inject/secret-pod.yaml
```
2. 파드가 실행중인지 확인한다.
```shell
kubectl get pod secret-test-pod
```
Output:
```
NAME READY STATUS RESTARTS AGE
secret-test-pod 1/1 Running 0 42m
```
3. 파드에서 실행 중인 컨테이너의 셸을 가져오자.
```shell
kubectl exec -i -t secret-test-pod -- /bin/bash
```
4. 시크릿 데이터는 `/etc/secret-volume`에 마운트된 볼륨을 통해
컨테이너에 노출된다.
셸에서 `/etc/secret-volume` 디렉터리의 파일을 나열한다.
```shell
# 컨테이너 내부의 셸에서 실행하자
ls /etc/secret-volume
```
두 개의 파일과 각 파일의 시크릿 데이터 조각을 확인할 수 있다.
```
password username
```
5. 셸에서 `username` 및 `password` 파일의 내용을 출력한다.
```shell
# 컨테이너 내부의 셸에서 실행하자
echo "$( cat /etc/secret-volume/username )"
echo "$( cat /etc/secret-volume/password )"
```
사용자 이름과 비밀번호가 출력된다.
```
my-app
39528$vdg7Jb
```
## 시크릿 데이터를 사용하여 컨테이너 환경 변수 정의하기
### 단일 시크릿 데이터로 컨테이너 환경 변수 정의하기
* 환경 변수를 시크릿의 키-값 쌍으로 정의한다.
```shell
kubectl create secret generic backend-user --from-literal=backend-username='backend-admin'
```
* 시크릿에 정의된 `backend-username` 값을 파드 명세의 `SECRET_USERNAME` 환경 변수에 할당한다.
{{< codenew file="pods/inject/pod-single-secret-env-variable.yaml" >}}
* 파드를 생성한다.
```shell
kubectl create -f https://k8s.io/examples/pods/inject/pod-single-secret-env-variable.yaml
```
* 셸에서 `SECRET_USERNAME` 컨테이너 환경 변수의 내용을 출력한다.
```shell
kubectl exec -i -t env-single-secret -- /bin/sh -c 'echo $SECRET_USERNAME'
```
출력은 다음과 같다.
```
backend-admin
```
### 여러 시크릿 데이터로 컨테이너 환경 변수 정의하기
* 이전 예제와 마찬가지로 시크릿을 먼저 생성한다.
```shell
kubectl create secret generic backend-user --from-literal=backend-username='backend-admin'
kubectl create secret generic db-user --from-literal=db-username='db-admin'
```
* 파드 명세에 환경 변수를 정의한다.
{{< codenew file="pods/inject/pod-multiple-secret-env-variable.yaml" >}}
* 파드를 생성한다.
```shell
kubectl create -f https://k8s.io/examples/pods/inject/pod-multiple-secret-env-variable.yaml
```
* 셸에서 컨테이너 환경 변수를 출력한다.
```shell
kubectl exec -i -t envvars-multiple-secrets -- /bin/sh -c 'env | grep _USERNAME'
```
출력은 다음과 같다.
```
DB_USERNAME=db-admin
BACKEND_USERNAME=backend-admin
```
## 시크릿의 모든 키-값 쌍을 컨테이너 환경 변수로 구성하기
{{< note >}}
이 기능은 쿠버네티스 v1.6 이상에서 사용할 수 있다.
{{< /note >}}
* 여러 키-값 쌍을 포함하는 시크릿을 생성한다.
```shell
kubectl create secret generic test-secret --from-literal=username='my-app' --from-literal=password='39528$vdg7Jb'
```
* envFrom을 사용하여 시크릿의 모든 데이터를 컨테이너 환경 변수로 정의한다. 시크릿의 키는 파드에서 환경 변수의 이름이 된다.
{{< codenew file="pods/inject/pod-secret-envFrom.yaml" >}}
* 파드를 생성한다.
```shell
kubectl create -f https://k8s.io/examples/pods/inject/pod-secret-envFrom.yaml
```
* `username` 및 `password` 컨테이너 환경 변수를 셸에서 출력한다.
```shell
kubectl exec -i -t envfrom-secret -- /bin/sh -c 'echo "username: $username\npassword: $password\n"'
```
출력은 다음과 같다.
```
username: my-app
password: 39528$vdg7Jb
```
### 참고
* [시크릿](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core)
* [볼륨](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volume-v1-core)
* [파드](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)
## {{% heading "whatsnext" %}}
* [시크릿](/ko/docs/concepts/configuration/secret/)에 대해 더 배워 보기.
* [볼륨](/ko/docs/concepts/storage/volumes/)에 대해 더 배워 보기.
content/ko/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md
+259
View File
@@ -0,0 +1,259 @@
---
title: 파일로 컨테이너에 파드 정보 노출하기
content_type: task
weight: 40
---
<!-- overview -->
본 페이지는 파드가 DownwardAPIVolumeFile을 사용하여 파드에서 실행되는 컨테이너에
자신에 대한 정보를 노출하는 방법에 대해 설명한다. DownwardAPIVolumeFile은 파드 필드와
컨테이너 필드를 노출할 수 있다.
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
<!-- steps -->
## 다운워드(Downward) API
실행 중인 컨테이너에 파드 및 컨테이너 필드를 노출하는 방법에는 두 가지가 있다.
* [환경 변수](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/#the-downward-api)
* 볼륨 파일
파드 및 컨테이너 필드를 노출하는 이 두 가지 방법을 *다운워드 API*라고 한다.
## 파드 필드 저장
이 연습에서는 하나의 컨테이너를 가진 파드를 생성한다.
다음은 파드에 대한 구성 파일이다.
{{< codenew file="pods/inject/dapi-volume.yaml" >}}
구성 파일에서 파드에 `downwardAPI` 볼륨이 있고 컨테이너가 `/etc/podinfo`에 볼륨을 마운트하는
것을 확인할 수 있다.
`downwardAPI` 아래의 배열을 살펴보자. 배열의 각 요소는
[DownwardAPIVolumeFile](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#downwardapivolumefile-v1-core)이다.
첫 번째 요소는 파드의 `metadata.labels` 필드 값이 `labels`라는 파일에 저장되어야 함을 지정한다.
두 번째 요소는 파드의 `annotations` 필드 값이 `annotations`라는 파일에 저장되어야 함을 지정한다.
{{< note >}}
이 예제의 필드는 파드에 있는 컨테이너의 필드가 아니라 파드 필드이다.
{{< /note >}}
파드를 생성한다.
```shell
kubectl apply -f https://k8s.io/examples/pods/inject/dapi-volume.yaml
```
파드의 컨테이너가 실행 중인지 확인한다.
```shell
kubectl get pods
```
컨테이너의 로그를 본다.
```shell
kubectl logs kubernetes-downwardapi-volume-example
```
출력은 `labels` 파일과 `annotations` 파일의 내용을 보여준다.
```shell
cluster="test-cluster1"
rack="rack-22"
zone="us-est-coast"
build="two"
builder="john-doe"
```
파드에서 실행 중인 컨테이너의 셸을 가져오자.
```shell
kubectl exec -it kubernetes-downwardapi-volume-example -- sh
```
셸에서 `labels` 파일을 보자.
```shell
/# cat /etc/podinfo/labels
```
출력을 통해 모든 파드의 레이블이 `labels` 파일에 기록되었음을 확인할 수 있다.
```shell
cluster="test-cluster1"
rack="rack-22"
zone="us-est-coast"
```
마찬가지로 `annotations` 파일을 확인하자.
```shell
/# cat /etc/podinfo/annotations
```
`etc/podinfo` 디렉터리에 파일을 확인하자.
```shell
/# ls -laR /etc/podinfo
```
출력에서 `labels` 및 `annotations` 파일이
임시 하위 디렉터리에 있음을 알 수 있다. 이 예제에서는
`..2982_06_02_21_47_53.299460680`이다. `/etc/podinfo` 디렉터리에서 `..data`는
임시 하위 디렉토리에 대한 심볼릭 링크이다. `/etc/podinfo` 디렉토리에서
`labels`와 `annotations` 또한 심볼릭 링크이다.
```
drwxr-xr-x ... Feb 6 21:47 ..2982_06_02_21_47_53.299460680
lrwxrwxrwx ... Feb 6 21:47 ..data -> ..2982_06_02_21_47_53.299460680
lrwxrwxrwx ... Feb 6 21:47 annotations -> ..data/annotations
lrwxrwxrwx ... Feb 6 21:47 labels -> ..data/labels
/etc/..2982_06_02_21_47_53.299460680:
total 8
-rw-r--r-- ... Feb 6 21:47 annotations
-rw-r--r-- ... Feb 6 21:47 labels
```
심볼릭 링크를 사용하면 메타데이터의 동적(dynamic) 원자적(atomic) 갱신이 가능하다.
업데이트는 새 임시 디렉터리에 기록되고, `..data` 심볼릭 링크는
[rename(2)](http://man7.org/linux/man-pages/man2/rename.2.html)을 사용하여
원자적(atomic)으로 갱신한다.
{{< note >}}
다운워드 API를 [subPath](/docs/concepts/storage/volumes/#using-subpath)
볼륨 마운트로 사용하는 컨테이너는 다운워드 API 업데이트를 수신하지 않는다.
{{< /note >}}
셸을 종료한다.
```shell
/# exit
```
## 컨테이너 필드 저장
이전 연습에서는 파드 필드를 DownwardAPIVolumeFile에 저장하였다.
이 다음 연습에서는 컨테이너 필드를 저장한다. 다음은 하나의 컨테이너를 가진 파드의 구성 파일이다.
{{< codenew file="pods/inject/dapi-volume-resources.yaml" >}}
구성 파일에서 파드에 `downwardAPI` 볼륨이 있고 컨테이너는 `/etc/podinfo`에 볼륨을
마운트하는 것을 확인할 수 있다.
`downwardAPI` 아래의 `items` 배열을 살펴보자. 배열의 각 요소는 DownwardAPIVolumeFile이다.
첫 번째 요소는 `client-container`라는 컨테이너에서
`1m`으로 지정된 형식의 `limits.cpu` 필드 값이
`cpu_limit`이라는 파일에 저장되어야 함을 지정한다. `divisor` 필드는 선택 사항이며
기본값인 `1`은 CPU에 대한 코어 및 메모리에 대한 바이트를 의미한다.
파드를 생성한다.
```shell
kubectl apply -f https://k8s.io/examples/pods/inject/dapi-volume-resources.yaml
```
파드에서 실행 중인 컨테이너의 셸을 가져온다.
```shell
kubectl exec -it kubernetes-downwardapi-volume-example-2 -- sh
```
셸에서 `cpu_limit` 파일을 확인한다.
```shell
/# cat /etc/podinfo/cpu_limit
```
비슷한 명령을 통해 `cpu_request`, `mem_limit` 및
`mem_request` 파일을 확인할 수 있다.
<!-- discussion -->
## 다운워드 API의 기능
다음 정보는 환경 변수 및 `downwardAPI` 볼륨을 통해 컨테이너에서 사용할 수 있다.
* `fieldRef`를 통해 다음 정보를 사용할 수 있다.
* `metadata.name` - 파드의 이름
* `metadata.namespace` - 파드의 네임스페이스(Namespace)
* `metadata.uid` - 파드의 UID
* `metadata.labels['<KEY>']` - 파드의 레이블 `<KEY>` 값 (예를 들어, `metadata.labels['mylabel']`)
* `metadata.annotations['<KEY>']` - 파드의 어노테이션 `<KEY>` 값 (예를 들어, `metadata.annotations['myannotation']`)
* `resourceFieldRef`를 통해 다음 정보를 사용할 수 있다.
* 컨테이너의 CPU 한도(limit)
* 컨테이너의 CPU 요청(request)
* 컨테이너의 메모리 한도(limit)
* 컨테이너의 메모리 요청(request)
* 컨테이너의 hugepages 한도(limit) (`DownwardAPIHugePages` [기능 게이트(feature gate)](/docs/reference/command-line-tools-reference/feature-gates/)가 활성화된 경우)
* 컨테이너의 hugepages 요청(request) (`DownwardAPIHugePages` [기능 게이트(feature gate)](/docs/reference/command-line-tools-reference/feature-gates/)가 활성화된 경우)
* 컨테이너의 임시-스토리지 한도(limit)
* 컨테이너의 임시-스토리지 요청(request)
`downwardAPI` 볼륨 `fieldRef`를 통해 다음 정보를 사용할 수 있다.
* `metadata.labels` - 한 줄에 하나의 레이블이 있는
`label-key="escaped-label-value"` 형식의 모든 파드 레이블
* `metadata.annotations` - 한 줄에 하나의 어노테이션이 있는 `annotation-key="escaped-annotation-value"` 형식의 모든 파드 어노테이션
환경 변수를 통해 다음 정보를 사용할 수 있다.
* `status.podIP` - 파드의 IP 주소
* `spec.serviceAccountName` - 파드의 서비스 계정 이름, v1.4.0-alpha.3부터 사용 가능
* `spec.nodeName` - 노드의 이름, v1.4.0-alpha.3부터 사용 가능
* `status.hostIP` - 노드의 IP, v1.7.0-alpha.1 이후 사용 가능
{{< note >}}
컨테이너에 대해 CPU 및 메모리 한도(limit)가 지정되지 않은 경우 다운워드 API는 기본적으로
CPU 및 메모리에 대해 할당 가능한 노드 값으로 설정한다.
{{< /note >}}
## 특정 경로 및 파일 권한에 대한 프로젝트 키
키(key)를 파드 안의 특정 경로에, 특정 권한으로, 파일 단위로 투영(project)할 수 있다.
자세한 내용은
[시크릿(Secrets)](/ko/docs/concepts/configuration/secret/)을 참조한다.
## 다운워드 API에 대한 동기
컨테이너가 쿠버네티스에 과도하게 결합되지 않고 자체에 대한 정보를 갖는 것이 때때로 유용하다.
다운워드 API를 사용하면 컨테이너가 쿠버네티스 클라이언트 또는 API 서버를 사용하지 않고
자체 또는 클러스터에 대한 정보를 사용할 수 있다.
예를 들어 잘 알려진 특정 환경 변수에 고유 식별자가 있다고 가정하는
기존 애플리케이션이 있다. 한 가지 가능성은 애플리케이션을 래핑하는 것이지만
이는 지루하고 오류가 발생하기 쉬우며 낮은 결합 목표를 위반한다.
더 나은 옵션은 파드의 이름을 식별자로 사용하고
파드의 이름을 잘 알려진 환경 변수에 삽입하는 것이다.
## {{% heading "whatsnext" %}}
* [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)
* [볼륨](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volume-v1-core)
* [DownwardAPIVolumeSource](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#downwardapivolumesource-v1-core)
* [DownwardAPIVolumeFile](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#downwardapivolumefile-v1-core)
* [ResourceFieldSelector](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcefieldselector-v1-core)
content/ko/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md
+157
View File
@@ -0,0 +1,157 @@
---
title: 환경 변수로 컨테이너에 파드 정보 노출하기
content_type: task
weight: 30
---
<!-- overview -->
본 페이지는 파드에서 실행 중인 컨테이너에게 파드가 환경 변수를 사용해서 자신의 정보를 노출하는 방법에
대해 설명한다. 환경 변수는 파드 필드와 컨테이너 필드를 노출할 수 있다.
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
<!-- steps -->
## 다운워드(Downward) API
파드 및 컨테이너 필드를 실행 중인 컨테이너에 노출하는 두 가지 방법이 있다.
* 환경 변수
* [볼륨 파일](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/#the-downward-api)
파드 및 컨테이너 필드를 노출하는 이 두 가지 방법을 *다운워드 API*라고 한다.
## 파드 필드를 환경 변수의 값으로 사용하자
이 연습에서는 하나의 컨테이너를 가진 파드를 생성한다. 다음은 파드에 대한 구성 파일이다.
{{< codenew file="pods/inject/dapi-envars-pod.yaml" >}}
구성 파일에서 5개의 환경 변수를 확인할 수 있다. `env` 필드는
[EnvVars](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvar-v1-core)의 배열이다. 배열의 첫 번째 요소는 `MY_NODE_NAME` 환경 변수가 파드의 `spec.nodeName` 필드에서 값을 가져오도록 지정한다. 마찬가지로 다른 환경 변수도 파드 필드에서 이름을 가져온다.
{{< note >}}
이 예제의 필드는 파드에 있는 컨테이너의 필드가 아니라 파드 필드이다.
{{< /note >}}
파드를 생성한다.
```shell
kubectl apply -f https://k8s.io/examples/pods/inject/dapi-envars-pod.yaml
```
파드의 컨테이너가 실행중인지 확인한다.
```shell
kubectl get pods
```
컨테이너의 로그를 본다.
```shell
kubectl logs dapi-envars-fieldref
```
출력은 선택된 환경 변수의 값을 보여준다.
```
minikube
dapi-envars-fieldref
default
172.17.0.4
default
```
이러한 값이 로그에 출력된 이유를 보려면 구성 파일의 `command` 및 `args` 필드를 확인하자.
컨테이너가 시작되면 5개의 환경 변수 값을 stdout에 쓰며 10초마다 이를 반복한다.
다음으로 파드에서 실행 중인 컨테이너의 셸을 가져오자.
```shell
kubectl exec -it dapi-envars-fieldref -- sh
```
셸에서 환경 변수를 보자.
```shell
/# printenv
```
출력은 특정 환경 변수에 파드 필드 값이 할당되었음을 보여준다.
```
MY_POD_SERVICE_ACCOUNT=default
...
MY_POD_NAMESPACE=default
MY_POD_IP=172.17.0.4
...
MY_NODE_NAME=minikube
...
MY_POD_NAME=dapi-envars-fieldref
```
## 컨테이너 필드를 환경 변수의 값으로 사용하기
이전 연습에서는 파드 필드를 환경 변수의 값으로 사용했다. 이 다음 연습에서는 컨테이너 필드를
환경 변수의 값으로 사용한다. 다음은 하나의 컨테이너가 있는 파드의 구성 파일이다.
{{< codenew file="pods/inject/dapi-envars-container.yaml" >}}
구성 파일에서 4개의 환경 변수를 확인할 수 있다. `env` 필드는
[EnvVars](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvar-v1-core)의 배열이다. 배열의 첫 번째 요소는 `MY_CPU_REQUEST` 환경 변수가 `test-container`라는 컨테이너의
`requests.cpu` 필드에서 값을 가져오도록 지정한다. 마찬가지로 다른 환경 변수도 컨테이너 필드에서
값을 가져온다.
파드를 생성한다.
```shell
kubectl apply -f https://k8s.io/examples/pods/inject/dapi-envars-container.yaml
```
파드의 컨테이너가 실행중인지 확인한다.
```shell
kubectl get pods
```
컨테이너의 로그를 본다.
```shell
kubectl logs dapi-envars-resourcefieldref
```
출력은 선택된 환경 변수의 값을 보여준다.
```
1
1
33554432
67108864
```
## {{% heading "whatsnext" %}}
* [컨테이너를 위한 환경 변수 정의하기](/docs/tasks/inject-data-application/define-environment-variable-container/)
* [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)
* [컨테이너](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)
* [EnvVar](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvar-v1-core)
* [EnvVarSource](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvarsource-v1-core)
* [ObjectFieldSelector](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#objectfieldselector-v1-core)
* [ResourceFieldSelector](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcefieldselector-v1-core)
content/ko/docs/tasks/manage-daemon/update-daemon-set.md
+6 -2
View File
@@ -11,6 +11,8 @@ weight: 10
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}}
<!-- steps -->
## 데몬셋 업데이트 전략
@@ -33,9 +35,11 @@ weight: 10
`.spec.updateStrategy.type` 에 `RollingUpdate` 를 설정해야 한다.
[`.spec.updateStrategy.rollingUpdate.maxUnavailable`](/ko/docs/concepts/workloads/controllers/deployment/#최대-불가max-unavailable)
(기본값은 1)과
(기본값은 1),
[`.spec.minReadySeconds`](/ko/docs/concepts/workloads/controllers/deployment/#최소-대기-시간초)
(기본값은 0)으로
(기본값은 0),
[`.spec.maxSurge`](/ko/docs/concepts/workloads/controllers/deployment/#최대-서지-max-surge)
(베타 기능, 기본값은 25%)를
설정할 수도 있다.
### `RollingUpdate` 업데이트 전략으로 데몬셋 생성
content/ko/docs/tasks/manage-hugepages/scheduling-hugepages.md
-6
View File
@@ -113,9 +113,3 @@ spec:
- 네임스페이스에서의 huge page 사용은 `hugepages-<size>` 토큰을 사용하는 `cpu` 또는 `memory` 와 같은
다른 컴퓨트 리소스와 비슷한 리소스쿼터(ResourceQuota)를 통해 제어할 수
있다.
- 다양한 크기의 huge page 지원이 기능 게이트로 제공된다.
{{<glossary_tooltip text="kubelet" term_id="kubelet" >}} 및
{{<glossary_tooltip text="kube-apiserver" term_id="kube-apiserver" >}}
(`--feature-gates=HugePageStorageMediumSize=true`)의 `HugePageStorageMediumSize`
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를
사용하여 비활성화할 수 있다.
content/ko/docs/tasks/network/validate-dual-stack.md
+1 -1
View File
@@ -16,7 +16,7 @@ content_type: task
* 이중 스택 네트워킹을 위한 제공자 지원 (클라우드 제공자 또는 기타 제공자들은 라우팅 가능한 IPv4/IPv6 네트워크 인터페이스를 제공하는 쿠버네티스 노드들을 제공해야 한다.)
* 이중 스택을 지원하는 [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) (예. Kubenet 또는 Calico)
* 이중 스택을 지원하는 [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) (예: Calico, Cilium 또는 Kubenet)
* [이중 스택 활성화](/ko/docs/concepts/services-networking/dual-stack/) 클러스터
{{< version-check >}}
content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
+1 -1
View File
@@ -183,7 +183,7 @@ CPU 사용량은 0으로 떨어졌고, HPA는 레플리카의 개수를 1로 낮
첫 번째로, `autoscaling/v2beta2` 형식으로 HorizontalPodAutoscaler YAML 파일을 생성한다.
```shell
kubectl get hpa.v2beta2.autoscaling -o yaml > /tmp/hpa-v2.yaml
kubectl get hpa php-apache -o yaml > /tmp/hpa-v2.yaml
```
에디터로 `/tmp/hpa-v2.yaml` 파일을 열면, 다음과 같은 YAML을 확인할 수 있다.
content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md
+15 -11
View File
@@ -1,4 +1,8 @@
---
title: Horizontal Pod Autoscaler
feature:
title: Horizontal 스케일링
@@ -9,10 +13,6 @@ content_type: concept
weight: 90
---
<!-- overview -->
Horizontal Pod Autoscaler는 CPU 사용량
@@ -181,6 +181,7 @@ HorizontalPodAutoscaler API 오브젝트 생성시 지정된 이름이 유효한
API 오브젝트에 대한 자세한 내용은
[HorizontalPodAutoscaler 오브젝트](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#horizontalpodautoscaler-v1-autoscaling)에서 찾을 수 있다.
## kubectl에서 Horizontal Pod Autoscaler 지원
Horizontal Pod Autoscaler는 모든 API 리소스와 마찬가지로 `kubectl`에 의해 표준 방식으로 지원된다.
@@ -197,14 +198,17 @@ Horizontal Pod Autoscaler는 모든 API 리소스와 마찬가지로 `kubectl`
## 롤링 업데이트 중 오토스케일링
현재 쿠버네티스에서는 기본 레플리카셋를 관리하는 디플로이먼트 오브젝트를 사용하여 롤링 업데이트를 수행할 수 있다.
Horizontal Pod Autoscaler는 후자의 방법을 지원한다. Horizontal Pod Autoscaler는 디플로이먼트 오브젝트에 바인딩되고,
디플로이먼트 오브젝트를 위한 크기를 설정하며, 디플로이먼트는 기본 레플리카셋의 크기를 결정한다.
쿠버네티스는 디플로이먼트에 대한 롤링 업데이트를 지원한다.
이 경우, 디플로이먼트가 기저 레플리카셋을 알아서 관리한다.
디플로이먼트에 오토스케일링을 설정하려면,
각 디플로이먼트에 대한 HorizontalPodAutoscaler를 생성한다.
HorizontalPodAutoscaler는 디플로이먼트의 `replicas` 필드를 관리한다.
디플로이먼트 컨트롤러는 기저 레플리카셋에 `replicas` 값을 적용하여
롤아웃 과정 중/이후에 적절한 숫자까지 늘어나도록 한다.
Horizontal Pod Autoscaler는 레플리케이션 컨트롤러를 직접 조작하는 롤링 업데이트에서 작동하지 않는다.
즉, Horizontal Pod Autoscaler를 레플리케이션 컨트롤러에 바인딩하고 롤링 업데이트를 수행할 수 없다. (예 : `kubectl rolling-update`)
작동하지 않는 이유는 롤링 업데이트에서 새 레플리케이션 컨트롤러를 만들 때,
Horizontal Pod Autoscaler가 새 레플리케이션 컨트롤러에 바인딩되지 않기 때문이다.
오토스케일된 레플리카가 있는 스테이트풀셋의 롤링 업데이트를 수행하면,
스테이트풀셋이 직접 파드의 숫자를 관리한다(즉,
레플리카셋과 같은 중간 리소스가 없다).
## 쿨-다운 / 지연에 대한 지원
content/ko/docs/tasks/run-application/run-stateless-application-deployment.md
+160
View File
@@ -0,0 +1,160 @@
---
title: 디플로이먼트(Deployment)로 스테이트리스 애플리케이션 실행하기
min-kubernetes-server-version: v1.9
content_type: tutorial
weight: 10
---
<!-- overview -->
이 페이지에서는 쿠버네티스 디플로이먼트 오브젝트를 사용하여 애플리케이션을 실행하는 방법을 설명한다.
## {{% heading "objectives" %}}
* nginx 디플로이먼트 생성하기
* kubectl을 사용하여 디플로이먼트 정보 나열하기
* 디플로이먼트 업데이트하기
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
<!-- lessoncontent -->
## nginx 디플로이먼트 생성하고 탐색하기
쿠버네티스 디플로이먼트 오브젝트를 생성하여 애플리케이션을 실행할 수 있으며,
디플로이먼트에 대한 명세를 YAML 파일에 기술할 수 있다. 예를 들어 이 YAML 파일은
nginx:1.14.2 도커 이미지를 실행하는 디플로이먼트에 대한 명세를 담고 있다.
{{< codenew file="application/deployment.yaml" >}}
1. YAML 파일을 기반으로 디플로이먼트를 생성한다.
kubectl apply -f https://k8s.io/examples/application/deployment.yaml
1. 디플로이먼트에 대한 정보를 살펴본다.
kubectl describe deployment nginx-deployment
출력은 다음과 유사하다.
Name: nginx-deployment
Namespace: default
CreationTimestamp: Tue, 30 Aug 2016 18:11:37 -0700
Labels: app=nginx
Annotations: deployment.kubernetes.io/revision=1
Selector: app=nginx
Replicas: 2 desired | 2 updated | 2 total | 2 available | 0 unavailable
StrategyType: RollingUpdate
MinReadySeconds: 0
RollingUpdateStrategy: 1 max unavailable, 1 max surge
Pod Template:
Labels: app=nginx
Containers:
nginx:
Image: nginx:1.14.2
Port: 80/TCP
Environment: <none>
Mounts: <none>
Volumes: <none>
Conditions:
Type Status Reason
---- ------ ------
Available True MinimumReplicasAvailable
Progressing True NewReplicaSetAvailable
OldReplicaSets: <none>
NewReplicaSet: nginx-deployment-1771418926 (2/2 replicas created)
No events.
1. 디플로이먼트에 의해 생성된 파드를 나열한다.
kubectl get pods -l app=nginx
출력은 다음과 유사하다.
NAME READY STATUS RESTARTS AGE
nginx-deployment-1771418926-7o5ns 1/1 Running 0 16h
nginx-deployment-1771418926-r18az 1/1 Running 0 16h
1. 파드에 대한 정보를 살펴본다.
kubectl describe pod <pod-name>
`<pod-name>`은 파드 중 하나의 이름이다.
## 디플로이먼트 업데이트하기
새 YAML 파일을 적용하여 디플로이먼트를 업데이트할 수 있다. 이 YAML 파일은
nginx 1.16.1을 사용하도록 디플로이먼트를 업데이트해야 함을 명시하고 있다.
{{< codenew file="application/deployment-update.yaml" >}}
1. 새 YAML 파일을 적용한다.
kubectl apply -f https://k8s.io/examples/application/deployment-update.yaml
1. 디플로이먼트가 새 이름으로 파드를 생성하고 이전 파드를 삭제하는 것을 확인한다.
kubectl get pods -l app=nginx
## 레플리카 수를 늘려 애플리케이션 확장하기
새 YAML 파일을 적용하여 디플로이먼트의 파드 수를 늘릴 수 있다.
이 YAML 파일은 `replicas`를 4로 설정하여 디플로이먼트에
4개의 파드가 있어야 함을 명시하고 있다.
{{< codenew file="application/deployment-scale.yaml" >}}
1. 새 YAML 파일을 적용한다.
kubectl apply -f https://k8s.io/examples/application/deployment-scale.yaml
1. 디플로이먼트에 4개의 파드가 있는지 확인한다.
kubectl get pods -l app=nginx
출력은 다음과 유사하다.
NAME READY STATUS RESTARTS AGE
nginx-deployment-148880595-4zdqq 1/1 Running 0 25s
nginx-deployment-148880595-6zgi1 1/1 Running 0 25s
nginx-deployment-148880595-fxcez 1/1 Running 0 2m
nginx-deployment-148880595-rwovn 1/1 Running 0 2m
## 디플로이먼트 삭제하기
이름으로 디플로이먼트를 삭제한다.
kubectl delete deployment nginx-deployment
## ReplicationControllers -- 예전 방식
애플리케이션을 복제하여 생성하는 기본적인 방법은 내부적으로 레플리카셋(ReplicaSet)을 활용하는 디플로이먼트를
사용하는 것이다. 쿠버네티스에 디플로이먼트 및 레플리카셋이 도입되기 전에는
[레플리케이션컨트롤러(ReplicationController)](/ko/docs/concepts/workloads/controllers/replicationcontroller/)를 사용하여 복제 애플리케이션을
구성했었다.
## {{% heading "whatsnext" %}}
* [디플로이먼트 오브젝트](/ko/docs/concepts/workloads/controllers/deployment/)에 대해 더 배워보기
content/ko/docs/tasks/tools/install-kubectl-macos.md
+1 -1
View File
@@ -228,7 +228,7 @@ kubectl은 Bash 및 Zsh에 대한 자동 완성 지원을 제공하므로 입력
1. kubectl-convert 바이너리를 시스템 `PATH` 의 파일 위치로 옮긴다.
```bash
sudo mv ./kubectl /usr/local/bin/kubectl-convert
sudo mv ./kubectl-convert /usr/local/bin/kubectl-convert
sudo chown root: /usr/local/bin/kubectl-convert
```
content/ko/docs/tasks/tools/install-kubectl-windows.md
+6 -6
View File
@@ -47,20 +47,20 @@ card:
kubectl 바이너리를 체크섬 파일을 통해 검증한다.
- 수동으로 `CertUtil` 의 출력과 다운로드한 체크섬 파일을 비교하기 위해서 커맨드 프롬프트를 사용한다.
- 커맨드 프롬프트를 사용하는 경우, `CertUtil` 의 출력과 다운로드한 체크섬 파일을 수동으로 비교한다.
```cmd
CertUtil -hashfile kubectl.exe SHA256
type kubectl.exe.sha256
```
- `-eq` 연산자를 통해 `True` 또는 `False` 결과를 얻는 자동 검증을 위해서 PowerShell을 사용한다.
- PowerShell을 사용하는 경우, `-eq` 연산자를 통해 `True` 또는 `False` 결과가 출력되는 자동 검증을 수행한다.
```powershell
$($(CertUtil -hashfile .\kubectl.exe SHA256)[1] -replace " ", "") -eq $(type .\kubectl.exe.sha256)
```
1. 바이너리를 `PATH` 가 설정된 디렉터리에 추가한다.
1. `PATH`로 설정된 디렉터리 중 하나에 kubectl 바이너리를 추가한다.
1. `kubectl` 의 버전이 다운로드한 버전과 같은지 확인한다.
@@ -160,20 +160,20 @@ kubectl은 Bash 및 Zsh에 대한 자동 완성 지원을 제공하므로 입력
kubectl-convert 바이너리를 체크섬 파일을 통해 검증한다.
- 수동으로 `CertUtil` 의 출력과 다운로드한 체크섬 파일을 비교하기 위해서 커맨드 프롬프트를 사용한다.
- 커맨드 프롬프트를 사용하는 경우, `CertUtil` 의 출력과 다운로드한 체크섬 파일을 수동으로 비교한다.
```cmd
CertUtil -hashfile kubectl-convert.exe SHA256
type kubectl-convert.exe.sha256
```
- `-eq` 연산자를 통해 `True` 또는 `False` 결과를 얻는 자동 검증을 위해서 PowerShell을 사용한다.
- PowerShell을 사용하는 경우, `-eq` 연산자를 통해 `True` 또는 `False` 결과가 출력되는 자동 검증을 수행한다.
```powershell
$($(CertUtil -hashfile .\kubectl-convert.exe SHA256)[1] -replace " ", "") -eq $(type .\kubectl-convert.exe.sha256)
```
1. 바이너리를 `PATH` 가 설정된 디렉터리에 추가한다.
1. `PATH`로 설정된 디렉터리 중 하나에 kubectl-convert 바이너리를 추가한다.
1. 플러그인이 정상적으로 설치되었는지 확인한다.
content/ko/docs/tutorials/clusters/apparmor.md
+5
View File
@@ -348,6 +348,11 @@ Events:
### PodSecurityPolicy로 프로파일 제한하기 {#restricting-profiles-with-the-podsecuritypolicy}
{{< note >}}
PodSecurityPolicy는 쿠버네티스 v1.21에서 사용 중지되었으며, v1.25에서 제거될 예정이다.
더 자세한 내용은 [PodSecurityPolicy 문서](/ko/docs/concepts/policy/pod-security-policy/)를 참고한다.
{{< /note >}}
만약 PodSecurityPolicy 확장을 사용하면, 클러스터 단위로 AppArmor 제한을 적용할 수 있다.
PodSecurityPolicy를 사용하려면 위해 다음의 플래그를 반드시 `apiserver`에 설정해야 한다.
content/ko/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html
+1 -1
View File
@@ -26,7 +26,7 @@ weight: 20
<div class="row">
<div class="col-md-12">
<a class="btn btn-lg btn-success" href="/ko/docs/tutorials/kubernetes-basics/" role="button">홈으로 이동<span class=""></span></a>
<a class="btn btn-lg btn-success" href="/ko/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro/" role="button">모듈 2로 진행하기 &gt<span class=""></span></a>
<a class="btn btn-lg btn-success" href="/ko/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro/" role="button">모듈 2로 진행하기 &gt;<span class=""></span></a>
</div>
</div>
content/ko/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html
+2 -2
View File
@@ -37,9 +37,9 @@ weight: 20
</div>
<div class="row">
<div class="col-md-12">
<a class="btn btn-lg btn-success" href="/ko/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro/" role="button"> &lt 모듈 1로 돌아가기<span class=""></span></a>
<a class="btn btn-lg btn-success" href="/ko/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro/" role="button"> &lt; 모듈 1로 돌아가기<span class=""></span></a>
<a class="btn btn-lg btn-success" href="/ko/docs/tutorials/kubernetes-basics/" role="button">홈으로 이동<span class=""></span></a>
<a class="btn btn-lg btn-success" href="/ko/docs/tutorials/kubernetes-basics/explore/explore-intro/" role="button">모듈 3으로 진행하기 &gt<span class=""></span></a>
<a class="btn btn-lg btn-success" href="/ko/docs/tutorials/kubernetes-basics/explore/explore-intro/" role="button">모듈 3으로 진행하기 &gt;<span class=""></span></a>
</div>
</div>
content/ko/docs/tutorials/kubernetes-basics/explore/explore-interactive.html
+2 -2
View File
@@ -29,9 +29,9 @@ weight: 20
</div>
<div class="row">
<div class="col-md-12">
<a class="btn btn-lg btn-success" href="/ko/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro/" role="button">&lt 모듈 2로 돌아가기<span class="btn"></span></a>
<a class="btn btn-lg btn-success" href="/ko/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro/" role="button">&lt; 모듈 2로 돌아가기<span class="btn"></span></a>
<a class="btn btn-lg btn-success" href="/ko/docs/tutorials/kubernetes-basics/" role="button">홈으로 이동<span class=""></span></a>
<a class="btn btn-lg btn-success" href="/ko/docs/tutorials/kubernetes-basics/expose/expose-intro/" role="button">모듈 4로 진행하기 &gt<span class="btn"></span></a>
<a class="btn btn-lg btn-success" href="/ko/docs/tutorials/kubernetes-basics/expose/expose-intro/" role="button">모듈 4로 진행하기 &gt;<span class="btn"></span></a>
</div>
</div>
content/ko/docs/tutorials/kubernetes-basics/expose/expose-interactive.html
+2 -2
View File
@@ -26,9 +26,9 @@ weight: 20
</div>
<div class="row">
<div class="col-md-12">
<a class="btn btn-lg btn-success" href="/ko/docs/tutorials/kubernetes-basics/explore/explore-intro/" role="button">&lt 모듈 3으로 돌아가기<span class=""></span></a>
<a class="btn btn-lg btn-success" href="/ko/docs/tutorials/kubernetes-basics/explore/explore-intro/" role="button">&lt; 모듈 3으로 돌아가기<span class=""></span></a>
<a class="btn btn-lg btn-success" href="/ko/docs/tutorials/kubernetes-basics/" role="button">홈으로 이동<span class=""></span></a>
<a class="btn btn-lg btn-success" href="/ko/docs/tutorials/kubernetes-basics/scale/scale-intro/" role="button">모듈 5로 진행하기 &gt<span class=""></span></a>
<a class="btn btn-lg btn-success" href="/ko/docs/tutorials/kubernetes-basics/scale/scale-intro/" role="button">모듈 5로 진행하기 &gt;<span class=""></span></a>
</div>
</div>
content/ko/docs/tutorials/kubernetes-basics/expose/expose-intro.html
+1 -1
View File
@@ -37,7 +37,7 @@ weight: 10
<li><i>ClusterIP</i> (기본값) - 클러스터 내에서 내부 IP 에 대해 서비스를 노출해준다. 이 방식은 오직 클러스터 내에서만 서비스가 접근될 수 있도록 해준다.</li>
<li><i>NodePort</i> - NAT가 이용되는 클러스터 내에서 각각 선택된 노드들의 동일한 포트에 서비스를 노출시켜준다. <code>&lt;NodeIP&gt;:&lt;NodePort&gt;</code>를 이용하여 클러스터 외부로부터 서비스가 접근할 수 있도록 해준다. ClusterIP의 상위 집합이다.</li>
<li><i>LoadBalancer</i> - (지원 가능한 경우) 기존 클라우드에서 외부용 로드밸런서를 생성하고 서비스에 고정된 공인 IP를 할당해준다. NodePort의 상위 집합이다. </li>
<li><i>ExternalName</i> - <code>CNAME</code> 레코드 및 값을 반환함으로써 서비스를 <code>externalName</code> 필드의 내용(예를 들면, `foo.bar.example.com`)에 매핑한다. 어떠한 종류의 프록시도 설정되지 않는다. 이 방식은 <code>kube-dns</code> v1.7 이상 또는 CoreDNS 버전 0.0.8 이상을 필요로 한다.</li>
<li><i>ExternalName</i> - <code>CNAME</code> 레코드 및 값을 반환함으로써 서비스를 <code>externalName</code> 필드의 내용(예를 들면, <code>foo.bar.example.com</code>)에 매핑한다. 어떠한 종류의 프록시도 설정되지 않는다. 이 방식은 <code>kube-dns</code> v1.7 이상 또는 CoreDNS 버전 0.0.8 이상을 필요로 한다.</li>
</ul>
<p>다른 서비스 타입들에 대한 추가 정보는 <a href="/ko/docs/tutorials/services/source-ip/">소스 IP 이용하기</a> 튜토리얼에서 확인 가능하다. 또한 <a href="/docs/concepts/services-networking/connect-applications-service">서비스들로 애플리케이션에 접속하기</a>도 참고해 보자.</p>
<p>부가적으로, spec에 <code>selector</code>를 정의하지 않고 말아넣은 서비스들의 몇 가지 유즈케이스들이 있음을 주의하자. <code>selector</code> 없이 생성된 서비스는 상응하는 엔드포인트 오브젝트들 또한 생성하지 않는다. 이로써 사용자들로 하여금 하나의 서비스를 특정한 엔드포인트에 매핑 시킬수 있도록 해준다. selector를 생략하게 되는 또 다른 가능성은 여러분이 <code>type: ExternalName</code>을 이용하겠다고 확고하게 의도하는 경우이다.</p>
content/ko/docs/tutorials/kubernetes-basics/scale/scale-interactive.html
+2 -2
View File
@@ -26,9 +26,9 @@ weight: 20
</div>
<div class="row">
<div class="col-md-12">
<a class="btn btn-lg btn-success" href="/ko/docs/tutorials/kubernetes-basics/expose/expose-interactive/" role="button">&lt 모듈 4로 돌아가기<span class=""></span></a>
<a class="btn btn-lg btn-success" href="/ko/docs/tutorials/kubernetes-basics/expose/expose-interactive/" role="button">&lt; 모듈 4로 돌아가기<span class=""></span></a>
<a class="btn btn-lg btn-success" href="/ko/docs/tutorials/kubernetes-basics/" role="button">홈으로 이동<span class=""></span></a>
<a class="btn btn-lg btn-success" href="/ko/docs/tutorials/kubernetes-basics/update/update-intro/" role="button">모듈 6으로 진행하기 &gt<span class=""></span></a>
<a class="btn btn-lg btn-success" href="/ko/docs/tutorials/kubernetes-basics/update/update-intro/" role="button">모듈 6으로 진행하기 &gt;<span class=""></span></a>
</div>
</div>
content/ko/docs/tutorials/kubernetes-basics/update/update-interactive.html
+1 -1
View File
@@ -26,7 +26,7 @@ weight: 20
</div>
<div class="row">
<div class="col-md-12">
<a class="btn btn-lg btn-success" href="/ko/docs/tutorials/kubernetes-basics/scale/scale-interactive/" role="button">&lt 모듈 5로 돌아가기<span class=""></span></a>
<a class="btn btn-lg btn-success" href="/ko/docs/tutorials/kubernetes-basics/scale/scale-interactive/" role="button">&lt; 모듈 5로 돌아가기<span class=""></span></a>
<a class="btn btn-lg btn-success" href="/ko/docs/tutorials/kubernetes-basics/" role="button">쿠버네티스 기초로 돌아가기<span class=""></span></a>
</div>
</div>
content/ko/docs/tutorials/stateful-application/basic-stateful-set.md
+1 -1
View File
@@ -20,7 +20,7 @@ weight: 10
* [클러스터 DNS(Cluster DNS)](/ko/docs/concepts/services-networking/dns-pod-service/)
* [헤드리스 서비스(Headless Services)](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)
* [퍼시스턴트볼륨(PersistentVolumes)](/ko/docs/concepts/storage/persistent-volumes/)
* [퍼시턴트볼륨 프로비저닝](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/)
* [퍼시턴트볼륨 프로비저닝](https://github.com/kubernetes/examples/tree/master/staging/persistent-volume-provisioning/)
* [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)
* [kubectl](/ko/docs/reference/kubectl/kubectl/) 커맨드 라인 도구
content/ko/docs/tutorials/stateful-application/cassandra.md
+1 -1
View File
@@ -50,7 +50,7 @@ weight: 30
### 추가적인 Minikube 설정 요령
{{< caution >}}
[Minikube](https://minikube.sigs.k8s.io/docs/)는 1024MiB 메모리와 1개 CPU가 기본 설정이다.
[Minikube](https://minikube.sigs.k8s.io/docs/)는 2048MB 메모리와 2개 CPU가 기본 설정이다.
이 튜토리얼에서 Minikube를 기본 리소스 설정으로 실행하면 리소스 부족 오류가
발생한다. 이런 오류를 피하려면 Minikube를 다음 설정으로 실행하자.
content/ko/docs/tutorials/stateful-application/zookeeper.md
+5 -5
View File
@@ -19,7 +19,7 @@ weight: 40
- [클러스터 DNS](/ko/docs/concepts/services-networking/dns-pod-service/)
- [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)
- [퍼시스턴트볼륨](/ko/docs/concepts/storage/persistent-volumes/)
- [퍼시스턴트볼륨 프로비저닝](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/)
- [퍼시스턴트볼륨 프로비저닝](https://github.com/kubernetes/examples/tree/master/staging/persistent-volume-provisioning/)
- [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)
- [PodDisruptionBudget](/ko/docs/concepts/workloads/pods/disruptions/#파드-disruption-budgets)
- [파드안티어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#어피니티-affinity-와-안티-어피니티-anti-affinity)
@@ -929,7 +929,7 @@ kubernetes-node-i4c4
[`kubectl drain`](/docs/reference/generated/kubectl/kubectl-commands/#drain)를 이용하자.
```shell
kubectl drain $(kubectl get pod zk-0 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-local-data
kubectl drain $(kubectl get pod zk-0 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-emptydir-data
```
```
@@ -964,7 +964,7 @@ zk-0 1/1 Running 0 1m
`zk-1` 이 스케줄된 노드를 비워보자.
```shell
kubectl drain $(kubectl get pod zk-1 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-local-data "kubernetes-node-ixsl" cordoned
kubectl drain $(kubectl get pod zk-1 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-emptydir-data "kubernetes-node-ixsl" cordoned
```
```
@@ -1007,7 +1007,7 @@ zk-1 0/1 Pending 0 0s
`zk-2`가 스케줄된 노드를 비워보자.
```shell
kubectl drain $(kubectl get pod zk-2 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-local-data
kubectl drain $(kubectl get pod zk-2 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-emptydir-data
```
```
@@ -1094,7 +1094,7 @@ zk-1 1/1 Running 0 13m
`zk-2`가 스케줄된 노드를 비워보자.
```shell
kubectl drain $(kubectl get pod zk-2 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-local-data
kubectl drain $(kubectl get pod zk-2 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-emptydir-data
```
출력은
content/ko/docs/tutorials/stateless-application/guestbook.md
+1 -1
View File
@@ -19,7 +19,7 @@ _(운영 수준이 아닌)_ 멀티 티어 웹 애플리케이션을 빌드하고
이 예제는 다음과 같은 구성으로
이루어져 있다.
* 방명록 항목을 저장하기 위한 단일 인스턴스 [Redis](https://www.redis.com/)
* 방명록 항목을 저장하기 위한 단일 인스턴스 [Redis](https://www.redis.io/)
* 여러 개의 웹 프론트엔드 인스턴스
## {{% heading "objectives" %}}
content/ko/examples/application/deployment-scale.yaml
+19
View File
@@ -0,0 +1,19 @@
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
selector:
matchLabels:
app: nginx
replicas: 4 # Update the replicas from 2 to 4
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80
content/ko/examples/application/deployment-update.yaml
+19
View File
@@ -0,0 +1,19 @@
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
selector:
matchLabels:
app: nginx
replicas: 2
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.16.1 # Update the version of nginx from 1.14.2 to 1.16.1
ports:
- containerPort: 80
content/ko/examples/pods/inject/dapi-envars-container.yaml
+45
View File
@@ -0,0 +1,45 @@
apiVersion: v1
kind: Pod
metadata:
name: dapi-envars-resourcefieldref
spec:
containers:
- name: test-container
image: k8s.gcr.io/busybox:1.24
command: [ "sh", "-c"]
args:
- while true; do
echo -en '\n';
printenv MY_CPU_REQUEST MY_CPU_LIMIT;
printenv MY_MEM_REQUEST MY_MEM_LIMIT;
sleep 10;
done;
resources:
requests:
memory: "32Mi"
cpu: "125m"
limits:
memory: "64Mi"
cpu: "250m"
env:
- name: MY_CPU_REQUEST
valueFrom:
resourceFieldRef:
containerName: test-container
resource: requests.cpu
- name: MY_CPU_LIMIT
valueFrom:
resourceFieldRef:
containerName: test-container
resource: limits.cpu
- name: MY_MEM_REQUEST
valueFrom:
resourceFieldRef:
containerName: test-container
resource: requests.memory
- name: MY_MEM_LIMIT
valueFrom:
resourceFieldRef:
containerName: test-container
resource: limits.memory
restartPolicy: Never
content/ko/examples/pods/inject/dapi-envars-pod.yaml
+38
View File
@@ -0,0 +1,38 @@
apiVersion: v1
kind: Pod
metadata:
name: dapi-envars-fieldref
spec:
containers:
- name: test-container
image: k8s.gcr.io/busybox
command: [ "sh", "-c"]
args:
- while true; do
echo -en '\n';
printenv MY_NODE_NAME MY_POD_NAME MY_POD_NAMESPACE;
printenv MY_POD_IP MY_POD_SERVICE_ACCOUNT;
sleep 10;
done;
env:
- name: MY_NODE_NAME
valueFrom:
fieldRef:
fieldPath: spec.nodeName
- name: MY_POD_NAME
valueFrom:
fieldRef:
fieldPath: metadata.name
- name: MY_POD_NAMESPACE
valueFrom:
fieldRef:
fieldPath: metadata.namespace
- name: MY_POD_IP
valueFrom:
fieldRef:
fieldPath: status.podIP
- name: MY_POD_SERVICE_ACCOUNT
valueFrom:
fieldRef:
fieldPath: spec.serviceAccountName
restartPolicy: Never
content/ko/examples/pods/inject/dapi-volume-resources.yaml
+57
View File
@@ -0,0 +1,57 @@
apiVersion: v1
kind: Pod
metadata:
name: kubernetes-downwardapi-volume-example-2
spec:
containers:
- name: client-container
image: k8s.gcr.io/busybox:1.24
command: ["sh", "-c"]
args:
- while true; do
echo -en '\n';
if [[ -e /etc/podinfo/cpu_limit ]]; then
echo -en '\n'; cat /etc/podinfo/cpu_limit; fi;
if [[ -e /etc/podinfo/cpu_request ]]; then
echo -en '\n'; cat /etc/podinfo/cpu_request; fi;
if [[ -e /etc/podinfo/mem_limit ]]; then
echo -en '\n'; cat /etc/podinfo/mem_limit; fi;
if [[ -e /etc/podinfo/mem_request ]]; then
echo -en '\n'; cat /etc/podinfo/mem_request; fi;
sleep 5;
done;
resources:
requests:
memory: "32Mi"
cpu: "125m"
limits:
memory: "64Mi"
cpu: "250m"
volumeMounts:
- name: podinfo
mountPath: /etc/podinfo
volumes:
- name: podinfo
downwardAPI:
items:
- path: "cpu_limit"
resourceFieldRef:
containerName: client-container
resource: limits.cpu
divisor: 1m
- path: "cpu_request"
resourceFieldRef:
containerName: client-container
resource: requests.cpu
divisor: 1m
- path: "mem_limit"
resourceFieldRef:
containerName: client-container
resource: limits.memory
divisor: 1Mi
- path: "mem_request"
resourceFieldRef:
containerName: client-container
resource: requests.memory
divisor: 1Mi
content/ko/examples/pods/inject/dapi-volume.yaml
+38
View File
@@ -0,0 +1,38 @@
apiVersion: v1
kind: Pod
metadata:
name: kubernetes-downwardapi-volume-example
labels:
zone: us-est-coast
cluster: test-cluster1
rack: rack-22
annotations:
build: two
builder: john-doe
spec:
containers:
- name: client-container
image: k8s.gcr.io/busybox
command: ["sh", "-c"]
args:
- while true; do
if [[ -e /etc/podinfo/labels ]]; then
echo -en '\n\n'; cat /etc/podinfo/labels; fi;
if [[ -e /etc/podinfo/annotations ]]; then
echo -en '\n\n'; cat /etc/podinfo/annotations; fi;
sleep 5;
done;
volumeMounts:
- name: podinfo
mountPath: /etc/podinfo
volumes:
- name: podinfo
downwardAPI:
items:
- path: "labels"
fieldRef:
fieldPath: metadata.labels
- path: "annotations"
fieldRef:
fieldPath: metadata.annotations
content/ko/examples/pods/inject/dependent-envars.yaml
+26
View File
@@ -0,0 +1,26 @@
apiVersion: v1
kind: Pod
metadata:
name: dependent-envars-demo
spec:
containers:
- name: dependent-envars-demo
args:
- while true; do echo -en '\n'; printf UNCHANGED_REFERENCE=$UNCHANGED_REFERENCE'\n'; printf SERVICE_ADDRESS=$SERVICE_ADDRESS'\n';printf ESCAPED_REFERENCE=$ESCAPED_REFERENCE'\n'; sleep 30; done;
command:
- sh
- -c
image: busybox
env:
- name: SERVICE_PORT
value: "80"
- name: SERVICE_IP
value: "172.17.0.1"
- name: UNCHANGED_REFERENCE
value: "$(PROTOCOL)://$(SERVICE_IP):$(SERVICE_PORT)"
- name: PROTOCOL
value: "https"
- name: SERVICE_ADDRESS
value: "$(PROTOCOL)://$(SERVICE_IP):$(SERVICE_PORT)"
- name: ESCAPED_REFERENCE
value: "$$(PROTOCOL)://$(SERVICE_IP):$(SERVICE_PORT)"

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