Merge pull request #31880 from jihoon-seo/220224_Outdated_M60
[ko] Update outdated files in `dev-1.23-ko.2` (M60-M73)pull/32789/head
Kubernetes Prow Robot
GitHub
commit
7da9d0d276
|
|
@ -2,6 +2,9 @@
|
|||
title: 네임스페이스에 대한 메모리의 최소 및 최대 제약 조건 구성
|
||||
content_type: task
|
||||
weight: 30
|
||||
description: >-
|
||||
한 네임스페이스 내에서 메모리 리소스 제한의 유효한 범위를 정의하며,
|
||||
이를 통해 해당 네임스페이스의 새로운 파드가 미리 설정한 범위 안에 들어오도록 한다.
|
||||
---
|
||||
|
||||
|
||||
|
|
@ -15,16 +18,14 @@ weight: 30
|
|||
|
||||
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
클러스터의 각 노드에는 최소 1GiB의 메모리가 있어야 한다.
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}}
|
||||
|
||||
클러스터에 네임스페이스를 생성할 수 있는 권한이 있어야 한다.
|
||||
|
||||
클러스터의 각 노드에는 파드가 사용할 수 있는 메모리가 최소 1GiB 이상 있어야 한다.
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
|
|
@ -39,7 +40,7 @@ kubectl create namespace constraints-mem-example
|
|||
|
||||
## 리밋레인지와 파드 생성
|
||||
|
||||
다음은 리밋레인지의 구성 파일이다.
|
||||
다음은 리밋레인지의 예시 매니페스트이다.
|
||||
|
||||
{{< codenew file="admin/resource/memory-constraints.yaml" >}}
|
||||
|
||||
|
|
@ -72,19 +73,20 @@ kubectl get limitrange mem-min-max-demo-lr --namespace=constraints-mem-example -
|
|||
type: Container
|
||||
```
|
||||
|
||||
이제 constraints-mem-example 네임스페이스에 컨테이너가 생성될 때마다, 쿠버네티스는
|
||||
다음 단계를 수행한다.
|
||||
이제 `constraints-mem-example` 네임스페이스에 파드를 생성할 때마다,
|
||||
쿠버네티스는 다음 단계를 수행한다.
|
||||
|
||||
* 컨테이너가 자체 메모리 요청량(request)과 상한(limit)을 지정하지 않으면, 기본 메모리 요청량과
|
||||
상한을 컨테이너에 지정한다.
|
||||
* 해당 파드의 어떤 컨테이너도 자체 메모리 요청량(request)과 상한(limit)을 명시하지 않으면,
|
||||
해당 컨테이너에 메모리 요청량과 상한의 기본값(default)을 지정한다.
|
||||
|
||||
* 컨테이너에 500MiB 이상의 메모리 요청량이 있는지 확인한다.
|
||||
* 해당 파드의 모든 컨테이너의 메모리 요청량이 최소 500 MiB 이상인지 확인한다.
|
||||
|
||||
* 컨테이너의 메모리 상한이 1GiB 이하인지 확인한다.
|
||||
* 해당 파드의 모든 컨테이너의 메모리 요청량이 1024 MiB(1 GiB)를 넘지 않는지
|
||||
확인한다.
|
||||
|
||||
컨테이너가 하나인 파드의 구성 파일은 다음과 같다. 컨테이너 매니페스트는
|
||||
600MiB의 메모리 요청량과 800MiB의 메모리 상한을 지정한다. 이들은
|
||||
리밋레인지에 의해 부과된 메모리의 최소 및 최대 제약 조건을 충족한다.
|
||||
다음은 컨테이너가 하나인 파드의 매니페스트이다.
|
||||
파드 명세 내에, 파드의 유일한 컨테이너는 600 MiB의 메모리 요청량 및 800 MiB의 메모리 상한을 지정하고 있다.
|
||||
이는 리밋레인지에 의해 부과된 최소 및 최대 메모리 제약 조건을 충족시킨다.
|
||||
|
||||
{{< codenew file="admin/resource/memory-constraints-pod.yaml" >}}
|
||||
|
||||
|
|
@ -94,7 +96,7 @@ kubectl get limitrange mem-min-max-demo-lr --namespace=constraints-mem-example -
|
|||
kubectl apply -f https://k8s.io/examples/admin/resource/memory-constraints-pod.yaml --namespace=constraints-mem-example
|
||||
```
|
||||
|
||||
파드의 컨테이너가 실행 중인지 확인한다.
|
||||
파드가 실행 중이고 컨테이너의 상태가 정상인지 확인한다.
|
||||
|
||||
```shell
|
||||
kubectl get pod constraints-mem-demo --namespace=constraints-mem-example
|
||||
|
|
@ -106,8 +108,9 @@ kubectl get pod constraints-mem-demo --namespace=constraints-mem-example
|
|||
kubectl get pod constraints-mem-demo --output=yaml --namespace=constraints-mem-example
|
||||
```
|
||||
|
||||
출력 결과는 컨테이너의 메모리 요청량이 600MiB이고 메모리 상한이 800MiB임을
|
||||
나타낸다. 이는 리밋레인지에 의해 부과된 제약 조건을 충족한다.
|
||||
출력을 보면 파드의 컨테이너의 메모리 요청량이 600 MiB이고 메모리 상한이 800 MiB임을 알 수 있다.
|
||||
이는 리밋레인지에 의해 해당 네임스페이스에 부과된 제약 조건을
|
||||
만족시킨다.
|
||||
|
||||
```yaml
|
||||
resources:
|
||||
|
|
@ -125,8 +128,8 @@ kubectl delete pod constraints-mem-demo --namespace=constraints-mem-example
|
|||
|
||||
## 최대 메모리 제약 조건을 초과하는 파드 생성 시도
|
||||
|
||||
컨테이너가 하나인 파드의 구성 파일은 다음과 같다. 컨테이너는
|
||||
800MiB의 메모리 요청량과 1.5GiB의 메모리 상한을 지정한다.
|
||||
다음은 컨테이너가 하나인 파드의 매니페스트이다.
|
||||
컨테이너는 800MiB의 메모리 요청량과 1.5GiB의 메모리 상한을 지정하고 있다.
|
||||
|
||||
{{< codenew file="admin/resource/memory-constraints-pod-2.yaml" >}}
|
||||
|
||||
|
|
@ -136,8 +139,8 @@ kubectl delete pod constraints-mem-demo --namespace=constraints-mem-example
|
|||
kubectl apply -f https://k8s.io/examples/admin/resource/memory-constraints-pod-2.yaml --namespace=constraints-mem-example
|
||||
```
|
||||
|
||||
컨테이너가 너무 큰 메모리 상한을 지정하므로, 출력 결과에 파드가 생성되지 않은 것으로
|
||||
표시된다.
|
||||
결과를 보면 파드가 생성되지 않은 것을 확인할 수 있으며,
|
||||
이는 해당 파드가 정의하고 있는 컨테이너가 허용된 것보다 더 많은 메모리를 요청하고 있기 때문이다.
|
||||
|
||||
```
|
||||
Error from server (Forbidden): error when creating "examples/admin/resource/memory-constraints-pod-2.yaml":
|
||||
|
|
@ -146,8 +149,8 @@ pods "constraints-mem-demo-2" is forbidden: maximum memory usage per Container i
|
|||
|
||||
## 최소 메모리 요청량을 충족하지 않는 파드 생성 시도
|
||||
|
||||
컨테이너가 하나인 파드의 구성 파일은 다음과 같다. 컨테이너는
|
||||
100MiB의 메모리 요청량과 800MiB의 메모리 상한을 지정한다.
|
||||
다음은 컨테이너가 하나인 파드의 매니페스트이다.
|
||||
컨테이너는 100MiB의 메모리 요청량과 800MiB의 메모리 상한을 지정하고 있다.
|
||||
|
||||
{{< codenew file="admin/resource/memory-constraints-pod-3.yaml" >}}
|
||||
|
||||
|
|
@ -157,8 +160,8 @@ pods "constraints-mem-demo-2" is forbidden: maximum memory usage per Container i
|
|||
kubectl apply -f https://k8s.io/examples/admin/resource/memory-constraints-pod-3.yaml --namespace=constraints-mem-example
|
||||
```
|
||||
|
||||
컨테이너가 너무 작은 메모리 요청량을 지정하므로, 출력 결과에 파드가 생성되지
|
||||
않은 것으로 표시된다.
|
||||
결과를 보면 파드가 생성되지 않은 것을 확인할 수 있으며,
|
||||
이는 해당 파드가 정의하고 있는 컨테이너가 지정된 최저 메모리 요청량보다도 낮은 메모리 요청량을 지정하고 있기 때문이다.
|
||||
|
||||
```
|
||||
Error from server (Forbidden): error when creating "examples/admin/resource/memory-constraints-pod-3.yaml":
|
||||
|
|
@ -167,10 +170,8 @@ pods "constraints-mem-demo-3" is forbidden: minimum memory usage per Container i
|
|||
|
||||
## 메모리 요청량 또는 상한을 지정하지 않은 파드 생성
|
||||
|
||||
|
||||
|
||||
컨테이너가 하나인 파드의 구성 파일은 다음과 같다. 컨테이너는
|
||||
메모리 요청량을 지정하지 않으며, 메모리 상한을 지정하지 않는다.
|
||||
다음은 컨테이너가 하나인 파드의 매니페스트이다.
|
||||
해당 컨테이너는 메모리 요청량과 상한을 지정하지 않는다.
|
||||
|
||||
{{< codenew file="admin/resource/memory-constraints-pod-4.yaml" >}}
|
||||
|
||||
|
|
@ -182,12 +183,12 @@ kubectl apply -f https://k8s.io/examples/admin/resource/memory-constraints-pod-4
|
|||
|
||||
파드에 대한 자세한 정보를 본다.
|
||||
|
||||
```
|
||||
```shell
|
||||
kubectl get pod constraints-mem-demo-4 --namespace=constraints-mem-example --output=yaml
|
||||
```
|
||||
|
||||
출력 결과는 파드의 컨테이너에 1GiB의 메모리 요청량과 1GiB의 메모리 상한이 있음을 보여준다.
|
||||
컨테이너는 이러한 값을 어떻게 얻었을까?
|
||||
출력을 보면 파드의 유일한 컨테이너에 대한 메모리 요청량이 1 GiB이고 메모리 상한도 1 GiB이다.
|
||||
이 컨테이너는 어떻게 이런 값을 얻었을까?
|
||||
|
||||
```
|
||||
resources:
|
||||
|
|
@ -197,11 +198,20 @@ resources:
|
|||
memory: 1Gi
|
||||
```
|
||||
|
||||
컨테이너가 자체 메모리 요청량과 상한을 지정하지 않았으므로,
|
||||
리밋레인지의 [메모리의 요청량과 상한 기본값](/ko/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)이
|
||||
제공되었다.
|
||||
파드가 해당 컨테이너에 대해 메모리 요청량과 상한을 지정하지 않았으므로,
|
||||
클러스터가 리밋레인지로부터
|
||||
[메모리의 요청량과 상한 기본값](/ko/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)을
|
||||
적용하였다.
|
||||
|
||||
이 시점에서, 컨테이너가 실행 중이거나 실행 중이 아닐 수 있다. 이 태스크의 전제 조건은
|
||||
이는 곧 파드 정의에서 이 값들을 볼 수 있음을 의미한다.
|
||||
`kubectl describe` 명령을 사용하여 확인할 수 있다.
|
||||
|
||||
```shell
|
||||
# 출력에서 "Requests:" 섹션을 확인한다
|
||||
kubectl describe pod constraints-mem-demo-4 --namespace=constraints-mem-example
|
||||
```
|
||||
|
||||
이 시점에서, 파드는 실행 중일 수도 있고 아닐 수도 있다. 이 태스크의 전제 조건은
|
||||
노드에 최소 1GiB의 메모리가 있어야 한다는 것이다. 각 노드에
|
||||
1GiB의 메모리만 있는 경우, 노드에 할당할 수 있는 메모리가 1GiB의 메모리 요청량을 수용하기에 충분하지
|
||||
않을 수 있다. 메모리가 2GiB인 노드를 사용하는 경우에는, 메모리가
|
||||
|
|
@ -209,7 +219,7 @@ resources:
|
|||
|
||||
파드를 삭제한다.
|
||||
|
||||
```
|
||||
```shell
|
||||
kubectl delete pod constraints-mem-demo-4 --namespace=constraints-mem-example
|
||||
```
|
||||
|
||||
|
|
@ -224,12 +234,12 @@ kubectl delete pod constraints-mem-demo-4 --namespace=constraints-mem-example
|
|||
클러스터 관리자는 파드가 사용할 수 있는 메모리 양에 제한을 둘 수 있다.
|
||||
예를 들면 다음과 같다.
|
||||
|
||||
* 클러스터의 각 노드에는 2GB의 메모리가 있다. 클러스터의 어떤 노드도 2GB 이상의 요청량을
|
||||
지원할 수 없으므로, 2GB 이상의 메모리를 요청하는 파드를 수락하지 않으려고 한다.
|
||||
* 클러스터의 각 노드에는 2GiB의 메모리가 있다. 클러스터의 어떤 노드도 2GiB 이상의 요청량을
|
||||
지원할 수 없으므로, 2GiB 이상의 메모리를 요청하는 파드를 수락하지 않으려고 한다.
|
||||
|
||||
* 클러스터는 운영 부서와 개발 부서에서 공유한다.
|
||||
프로덕션 워크로드가 최대 8GB의 메모리를 소비하도록 하려면,
|
||||
개발 워크로드를 512MB로 제한해야 한다. 프로덕션 및 개발을 위해
|
||||
프로덕션 워크로드가 최대 8GiB의 메모리를 소비하도록 하려면,
|
||||
개발 워크로드를 512MiB로 제한해야 한다. 프로덕션 및 개발을 위해
|
||||
별도의 네임스페이스를 만들고, 각 네임스페이스에 메모리 제약 조건을 적용한다.
|
||||
|
||||
## 정리
|
||||
|
|
|
|||
|
|
@ -2,21 +2,35 @@
|
|||
title: 네임스페이스에 대한 기본 메모리 요청량과 상한 구성
|
||||
content_type: task
|
||||
weight: 10
|
||||
description: >-
|
||||
한 네임스페이스에 메모리 리소스 상한의 기본값을 정의하며,
|
||||
이를 통해 미리 설정한 메모리 리소스 상한이 해당 네임스페이스의 새로운 파드에 설정되도록 한다.
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
이 페이지는 네임스페이스에 대한 기본 메모리 요청량(request)과 상한(limit)을 구성하는 방법을 보여준다.
|
||||
기본 메모리 상한이 있는 네임스페이스에서 컨테이너가 생성되고, 컨테이너가
|
||||
자체 메모리 상한을 지정하지 않으면, 컨테이너에 기본 메모리 상한이 할당된다.
|
||||
이 페이지는 {{< glossary_tooltip text="네임스페이스" term_id="namespace" >}}에 대한
|
||||
기본 메모리 요청량(request) 및 상한(limit)을 구성하는 방법을 보여준다.
|
||||
|
||||
쿠버네티스 클러스터를 여러 네임스페이스로 나눌 수 있다.
|
||||
기본 메모리 [상한](/ko/docs/concepts/configuration/manage-resources-containers/#요청-및-제한)이
|
||||
설정되어 있는 네임스페이스에 파드를 생성했는데,
|
||||
해당 파드의 모든 컨테이너에 메모리 상한이 명시되어 있지 않다면,
|
||||
{{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}이
|
||||
해당 컨테이너에
|
||||
기본 메모리 상한을 할당한다.
|
||||
|
||||
쿠버네티스는 이 문서의 뒷부분에서 설명하는 특정 조건에서 기본 메모리 요청량을 할당한다.
|
||||
|
||||
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
{{< include "task-tutorial-prereqs.md" >}}
|
||||
|
||||
클러스터에 네임스페이스를 생성할 수 있는 권한이 있어야 한다.
|
||||
|
||||
클러스터의 각 노드에는 최소 2GiB의 메모리가 있어야 한다.
|
||||
|
||||
|
|
@ -35,8 +49,9 @@ kubectl create namespace default-mem-example
|
|||
|
||||
## 리밋레인지(LimitRange)와 파드 생성
|
||||
|
||||
다음은 리밋레인지 오브젝트의 구성 파일이다. 구성은
|
||||
메모리 요청량 기본값(default)과 메모리 상한 기본값을 지정한다.
|
||||
다음은 예시 {{< glossary_tooltip text="리밋레인지" term_id="limitrange" >}}에 대한 매니페스트이다.
|
||||
이 매니페스트는 기본 메모리 요청량 및
|
||||
기본 메모리 상한을 지정한다.
|
||||
|
||||
{{< codenew file="admin/resource/memory-defaults.yaml" >}}
|
||||
|
||||
|
|
@ -46,13 +61,14 @@ default-mem-example 네임스페이스에 리밋레인지를 생성한다.
|
|||
kubectl apply -f https://k8s.io/examples/admin/resource/memory-defaults.yaml --namespace=default-mem-example
|
||||
```
|
||||
|
||||
이제 컨테이너가 default-mem-example 네임스페이스에 생성되고,
|
||||
컨테이너가 메모리 요청량 및 메모리 상한에 대해 고유한 값을 지정하지 않으면,
|
||||
컨테이너에 메모리 요청량 기본값 256MiB와 메모리 상한 기본값
|
||||
512MiB가 지정된다.
|
||||
이제 파드를 `default-mem-example` 네임스페이스에 생성하고,
|
||||
해당 파드의 어떤 컨테이너도 자체 메모리 요청량(request)과 상한(limit)을 명시하지 않으면,
|
||||
컨트롤 플레인이 해당 컨테이너에 메모리 요청량의 기본값(256 MiB)과
|
||||
상한의 기본값(512 MiB)을 지정한다.
|
||||
|
||||
컨테이너가 하나인 파드의 구성 파일은 다음과 같다. 컨테이너는
|
||||
메모리 요청량 및 상한을 지정하지 않는다.
|
||||
|
||||
다음은 컨테이너가 하나인 파드의 매니페스트이다.
|
||||
해당 컨테이너는 메모리 요청량과 상한을 지정하지 않는다.
|
||||
|
||||
{{< codenew file="admin/resource/memory-defaults-pod.yaml" >}}
|
||||
|
||||
|
|
@ -91,8 +107,8 @@ kubectl delete pod default-mem-demo --namespace=default-mem-example
|
|||
|
||||
## 컨테이너 상한은 지정하고, 요청량을 지정하지 않으면 어떻게 되나?
|
||||
|
||||
컨테이너가 하나인 파드의 구성 파일은 다음과 같다. 컨테이너는
|
||||
메모리 상한을 지정하지만, 요청량은 지정하지 않는다.
|
||||
다음은 컨테이너가 하나인 파드의 매니페스트이다.
|
||||
해당 컨테이너는 메모리 상한은 지정하지만, 요청량은 지정하지 않는다.
|
||||
|
||||
{{< codenew file="admin/resource/memory-defaults-pod-2.yaml" >}}
|
||||
|
||||
|
|
@ -122,8 +138,8 @@ resources:
|
|||
|
||||
## 컨테이너의 요청량은 지정하고, 상한을 지정하지 않으면 어떻게 되나?
|
||||
|
||||
컨테이너가 하나인 파드의 구성 파일은 다음과 같다. 컨테이너는
|
||||
메모리 요청량을 지정하지만, 상한은 지정하지 않았다.
|
||||
다음은 컨테이너가 하나인 파드의 예시 매니페스트이다.
|
||||
해당 컨테이너는 메모리 요청량은 지정하지만, 상한은 지정하지 않는다.
|
||||
|
||||
{{< codenew file="admin/resource/memory-defaults-pod-3.yaml" >}}
|
||||
|
||||
|
|
@ -139,9 +155,9 @@ kubectl apply -f https://k8s.io/examples/admin/resource/memory-defaults-pod-3.ya
|
|||
kubectl get pod default-mem-demo-3 --output=yaml --namespace=default-mem-example
|
||||
```
|
||||
|
||||
출력 결과는 컨테이너의 메모리 요청량이 컨테이너의 구성 파일에 지정된 값으로
|
||||
설정되었음을 보여준다. 컨테이너의 메모리 상한은 네임스페이스의
|
||||
기본 메모리 상한인 512Mi로 설정되어 있다.
|
||||
출력을 보면 컨테이너의 매니페스트에 명시한 값대로 컨테이너의 메모리 요청량이 설정된 것을 알 수 있다.
|
||||
해당 컨테이너의 메모리 상한은 512 MiB로 설정되며,
|
||||
이는 네임스페이스의 메모리 상한 기본값과 일치한다.
|
||||
|
||||
```
|
||||
resources:
|
||||
|
|
@ -153,15 +169,23 @@ resources:
|
|||
|
||||
## 기본 메모리 상한 및 요청량에 대한 동기
|
||||
|
||||
네임스페이스에 리소스 쿼터가 있는 경우,
|
||||
네임스페이스에 {{< glossary_tooltip text="리소스 쿼터" term_id="resource-quota" >}}가
|
||||
설정되어 있는 경우,
|
||||
메모리 상한에 기본값을 설정하는 것이 좋다.
|
||||
다음은 리소스 쿼터가 네임스페이스에 적용하는 두 가지 제한 사항이다.
|
||||
|
||||
* 네임스페이스에서 실행되는 모든 컨테이너에는 자체 메모리 상한이 있어야 한다.
|
||||
* 네임스페이스의 모든 컨테이너가 사용하는 총 메모리 양은 지정된 상한을 초과하지 않아야 한다.
|
||||
* 네임스페이스에서 실행되는 모든 파드에 대해, 모든 컨테이너에 메모리 상한이 있어야 한다.
|
||||
(파드의 모든 컨테이너에 대해 메모리 상한을 지정하면,
|
||||
쿠버네티스가 파드 내의 컨테이너의 상한을 합산하여 파드-수준 메모리 상한을 추론할 수 있다.)
|
||||
* 메모리 상한은 해당 파드가 스케줄링될 노드에 리소스 예약을 적용한다.
|
||||
해당 네임스페이스의 모든 파드에 대해 예약된 메모리 총량이 지정된 상한을 초과하지 않아야 한다.
|
||||
* 해당 네임스페이스의 모든 파드가 실제로 사용하고 있는 메모리의 총량 또한 지정된 상한을 초과하지 않아야 한다.
|
||||
|
||||
컨테이너가 자체 메모리 상한을 지정하지 않으면, 기본 상한이 부여되고,
|
||||
쿼터에 의해 제한되는 네임스페이스에서 실행될 수 있다.
|
||||
리밋레인지를 추가할 때에는 다음을 고려해야 한다.
|
||||
|
||||
컨테이너를 갖고 있는 해당 네임스페이스의 파드가 자체 메모리 상한을 지정하지 않았다면,
|
||||
컨트롤 플레인이 해당 컨테이너에 메모리 상한 기본값을 적용하며,
|
||||
해당 파드는 메모리 리소스쿼터가 적용된 네임스페이스에서 실행되도록 허용될 수 있다.
|
||||
|
||||
## 정리
|
||||
|
||||
|
|
|
|||
|
|
@ -2,29 +2,31 @@
|
|||
title: 네임스페이스에 대한 메모리 및 CPU 쿼터 구성
|
||||
content_type: task
|
||||
weight: 50
|
||||
description: >-
|
||||
한 네임스페이스에 대한 총 메모리 및 CPU 자원 상한을 정의한다.
|
||||
---
|
||||
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
이 페이지는 네임스페이스에서 실행 중인 모든 컨테이너가 사용할 수 있는
|
||||
이 페이지는 {{< glossary_tooltip text="네임스페이스" term_id="namespace" >}}에서
|
||||
실행 중인 모든 파드가 사용할 수 있는
|
||||
총 메모리 및 CPU 양에 대한 쿼터를 설정하는 방법을 보여준다.
|
||||
[리소스쿼터(ResourceQuota)](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcequota-v1-core)
|
||||
오브젝트에 쿼터를 지정한다.
|
||||
[리소스쿼터(ResourceQuota)](/docs/reference/kubernetes-api/policy-resources/resource-quota-v1/) 오브젝트에
|
||||
쿼터를 지정할 수 있다.
|
||||
|
||||
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
클러스터에 네임스페이스를 생성할 수 있는 권한이 있어야 한다.
|
||||
|
||||
클러스터의 각 노드에는 최소 1GiB의 메모리가 있어야 한다.
|
||||
|
||||
|
||||
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## 네임스페이스 생성
|
||||
|
|
@ -38,7 +40,7 @@ kubectl create namespace quota-mem-cpu-example
|
|||
|
||||
## 리소스쿼터 생성
|
||||
|
||||
다음은 리소스쿼터 오브젝트의 구성 파일이다.
|
||||
다음은 예시 리소스쿼터 오브젝트에 대한 매니페스트이다.
|
||||
|
||||
{{< codenew file="admin/resource/quota-mem-cpu.yaml" >}}
|
||||
|
||||
|
|
@ -56,15 +58,18 @@ kubectl get resourcequota mem-cpu-demo --namespace=quota-mem-cpu-example --outpu
|
|||
|
||||
리소스쿼터는 이러한 요구 사항을 quota-mem-cpu-example 네임스페이스에 배치한다.
|
||||
|
||||
* 모든 컨테이너에는 메모리 요청량(request), 메모리 상한(limit), CPU 요청량 및 CPU 상한이 있어야 한다.
|
||||
* 모든 컨테이너에 대한 총 메모리 요청량은 1GiB를 초과하지 않아야 한다.
|
||||
* 모든 컨테이너에 대한 총 메모리 상한은 2GiB를 초과하지 않아야 한다.
|
||||
* 모든 컨테이너에 대한 총 CPU 요청량은 1 cpu를 초과해서는 안된다.
|
||||
* 모든 컨테이너에 대한 총 CPU 상한은 2 cpu를 초과해서는 안된다.
|
||||
* 네임스페이스의 모든 파드에 대해, 각 컨테이너에는 메모리 요청량(request), 메모리 상한(limit), CPU 요청량 및 CPU 상한이 있어야 한다.
|
||||
* 네임스페이스의 모든 파드에 대한 총 메모리 요청량은 1GiB를 초과하지 않아야 한다.
|
||||
* 네임스페이스의 모든 파드에 대한 총 메모리 상한은 2GiB를 초과하지 않아야 한다.
|
||||
* 네임스페이스의 모든 파드에 대한 총 CPU 요청량은 1 cpu를 초과해서는 안된다.
|
||||
* 네임스페이스의 모든 파드에 대한 총 CPU 상한은 2 cpu를 초과해서는 안된다.
|
||||
|
||||
쿠버네티스에서 “1 CPU”가 무엇을 의미하는지 알아보려면
|
||||
[CPU의 의미](/ko/docs/concepts/configuration/manage-resources-containers/#cpu의-의미)를 참조한다.
|
||||
|
||||
## 파드 생성
|
||||
|
||||
파드의 구성 파일은 다음과 같다.
|
||||
다음은 예시 파드에 대한 매니페스트이다.
|
||||
|
||||
{{< codenew file="admin/resource/quota-mem-cpu-pod.yaml" >}}
|
||||
|
||||
|
|
@ -75,15 +80,15 @@ kubectl get resourcequota mem-cpu-demo --namespace=quota-mem-cpu-example --outpu
|
|||
kubectl apply -f https://k8s.io/examples/admin/resource/quota-mem-cpu-pod.yaml --namespace=quota-mem-cpu-example
|
||||
```
|
||||
|
||||
파드의 컨테이너가 실행 중인지 확인한다.
|
||||
파드가 실행 중이고 파드의 (유일한) 컨테이너의 상태가 정상인지 확인한다.
|
||||
|
||||
```
|
||||
```shell
|
||||
kubectl get pod quota-mem-cpu-demo --namespace=quota-mem-cpu-example
|
||||
```
|
||||
|
||||
다시 한 번, 리소스쿼터에 대한 자세한 정보를 본다.
|
||||
|
||||
```
|
||||
```shell
|
||||
kubectl get resourcequota mem-cpu-demo --namespace=quota-mem-cpu-example --output=yaml
|
||||
```
|
||||
|
||||
|
|
@ -105,15 +110,22 @@ status:
|
|||
requests.memory: 600Mi
|
||||
```
|
||||
|
||||
`jq` 도구가 설치되어 있으면, ([JSONPath](/ko/docs/reference/kubectl/jsonpath/)를 사용하여) `used` 값만을 질의 **하고**,
|
||||
정돈된 상태로 출력할 수 있다. 예시는 다음과 같다.
|
||||
|
||||
```shell
|
||||
kubectl get resourcequota mem-cpu-demo --namespace=quota-mem-cpu-example -o jsonpath='{ .status.used }' | jq .
|
||||
```
|
||||
|
||||
## 두 번째 파드 생성 시도
|
||||
|
||||
다음은 두 번째 파드의 구성 파일이다.
|
||||
다음은 두 번째 파드에 대한 매니페스트이다.
|
||||
|
||||
{{< codenew file="admin/resource/quota-mem-cpu-pod-2.yaml" >}}
|
||||
|
||||
구성 파일에서, 파드의 메모리 요청량이 700MiB임을 알 수 있다.
|
||||
매니페스트에서, 파드의 메모리 요청량이 700MiB임을 알 수 있다.
|
||||
사용된 메모리 요청량과 이 새 메모리 요청량의 합계가
|
||||
메모리 요청량 쿼터를 초과한다. 600MiB + 700MiB > 1GiB
|
||||
메모리 요청량 쿼터를 초과함에 유의한다(600 MiB + 700 MiB > 1 GiB).
|
||||
|
||||
파드 생성을 시도한다.
|
||||
|
||||
|
|
@ -133,11 +145,12 @@ requested: requests.memory=700Mi,used: requests.memory=600Mi, limited: requests.
|
|||
## 토론
|
||||
|
||||
이 연습에서 보았듯이, 리소스쿼터를 사용하여
|
||||
네임스페이스에서 실행 중인 모든 컨테이너에 대한 메모리 요청량의 총 합계를 제한할 수 있다.
|
||||
네임스페이스에서 실행 중인 모든 파드에 대한 메모리 요청량의 총 합계를 제한할 수 있다.
|
||||
메모리 상한, CPU 요청량 및 CPU 상한의 총 합계를 제한할 수도 있다.
|
||||
|
||||
모든 컨테이너에 대한 합계 대신 개별 컨테이너를 제한하려면,
|
||||
[리밋레인지(LimitRange)](/ko/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/)를 사용한다.
|
||||
네임스페이스 내의 총 자원을 관리하는 것 대신,
|
||||
개별 파드 또는 파드 내의 컨테이너별로 제한하고 싶을 수도 있다.
|
||||
이러한 종류의 제한을 걸려면, [리밋레인지(LimitRange)](/ko/docs/concepts/policy/limit-range/)를 사용한다.
|
||||
|
||||
## 정리
|
||||
|
||||
|
|
|
|||
|
|
@ -2,15 +2,17 @@
|
|||
title: 네임스페이스에 대한 파드 쿼터 구성
|
||||
content_type: task
|
||||
weight: 60
|
||||
description: >-
|
||||
한 네임스페이스 내에 만들 수 있는 파드의 수를 제한한다.
|
||||
---
|
||||
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
이 페이지는 네임스페이스에서 실행할 수 있는 총 파드 수에 대한 쿼터를
|
||||
이 페이지는 {{< glossary_tooltip text="네임스페이스" term_id="namespace" >}}에서 실행할 수 있는 총 파드 수에 대한 쿼터를
|
||||
설정하는 방법을 보여준다.
|
||||
[리소스쿼터(ResourceQuota)](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcequota-v1-core)
|
||||
오브젝트에 쿼터를 지정한다.
|
||||
[리소스쿼터(ResourceQuota)](/docs/reference/kubernetes-api/policy-resources/resource-quota-v1/) 오브젝트에
|
||||
쿼터를 지정할 수 있다.
|
||||
|
||||
|
||||
|
||||
|
|
@ -18,10 +20,9 @@ weight: 60
|
|||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}}
|
||||
|
||||
클러스터에 네임스페이스를 생성할 수 있는 권한이 있어야 한다.
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
|
|
@ -36,7 +37,7 @@ kubectl create namespace quota-pod-example
|
|||
|
||||
## 리소스쿼터 생성
|
||||
|
||||
다음은 리소스쿼터 오브젝트의 구성 파일이다.
|
||||
다음은 예시 리소스쿼터 오브젝트에 대한 매니페스트이다.
|
||||
|
||||
{{< codenew file="admin/resource/quota-pod.yaml" >}}
|
||||
|
||||
|
|
@ -66,11 +67,12 @@ status:
|
|||
pods: "0"
|
||||
```
|
||||
|
||||
다음은 디플로이먼트(Deployment) 구성 파일이다.
|
||||
다음은 {{< glossary_tooltip text="디플로이먼트(Deployment)" term_id="deployment" >}}에 대한 예시 매니페스트이다.
|
||||
|
||||
{{< codenew file="admin/resource/quota-pod-deployment.yaml" >}}
|
||||
|
||||
구성 파일에서, `replicas: 3` 은 쿠버네티스가 모두 동일한 애플리케이션을 실행하는 세 개의 파드를 만들도록 지시한다.
|
||||
매니페스트에서, `replicas: 3` 은 쿠버네티스가 모두 동일한 애플리케이션을 실행하는
|
||||
세 개의 새로운 파드를 만들도록 지시한다.
|
||||
|
||||
디플로이먼트를 생성한다.
|
||||
|
||||
|
|
@ -84,8 +86,8 @@ kubectl apply -f https://k8s.io/examples/admin/resource/quota-pod-deployment.yam
|
|||
kubectl get deployment pod-quota-demo --namespace=quota-pod-example --output=yaml
|
||||
```
|
||||
|
||||
출력 결과는 디플로이먼트에서 3개의 레플리카를 지정하더라도, 쿼터로
|
||||
인해 2개의 파드만 생성되었음을 보여준다.
|
||||
출력을 보면 디플로이먼트가 3개의 레플리카를 정의하고 있음에도,
|
||||
앞서 설정한 쿼터로 인해 2개의 파드만 생성되었음을 보여준다.
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
|
|
@ -95,11 +97,18 @@ spec:
|
|||
status:
|
||||
availableReplicas: 2
|
||||
...
|
||||
lastUpdateTime: 2017-07-07T20:57:05Z
|
||||
lastUpdateTime: 2021-04-02T20:57:05Z
|
||||
message: 'unable to create pods: pods "pod-quota-demo-1650323038-" is forbidden:
|
||||
exceeded quota: pod-demo, requested: pods=1, used: pods=2, limited: pods=2'
|
||||
```
|
||||
|
||||
### 리소스 선택
|
||||
|
||||
이 예제에서는 총 파드 수를 제한하는 리소스쿼터를 정의하였다.
|
||||
하지만, 다른 종류의 오브젝트의 총 수를 제한할 수도 있다.
|
||||
예를 들어, 한 네임스페이스에 존재할 수 있는
|
||||
{{< glossary_tooltip text="크론잡" term_id="cronjob" >}}의 총 수를 제한할 수 있다.
|
||||
|
||||
## 정리
|
||||
|
||||
네임스페이스를 삭제한다.
|
||||
|
|
|
|||
|
|
@ -174,7 +174,7 @@ kubectl get pod memory-demo-2 --output=yaml --namespace=mem-example
|
|||
```shell
|
||||
lastState:
|
||||
terminated:
|
||||
containerID: docker://65183c1877aaec2e8427bc95609cc52677a454b56fcb24340dbd22917c23b10f
|
||||
containerID: 65183c1877aaec2e8427bc95609cc52677a454b56fcb24340dbd22917c23b10f
|
||||
exitCode: 137
|
||||
finishedAt: 2017-06-20T20:52:19Z
|
||||
reason: OOMKilled
|
||||
|
|
|
|||
|
|
@ -10,20 +10,19 @@ weight: 20
|
|||
|
||||
이 페이지는 윈도우 노드에서 실행되는 파드와 컨테이너용으로 [그룹 관리 서비스 어카운트(Group Managed Service Accounts,](https://docs.microsoft.com/ko-kr/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview) GMSA)를 구성하는 방법을 소개한다. 그룹 관리 서비스 어카운트는 자동 암호 관리, 단순화된 서비스 사용자 이름(service principal name, SPN) 관리, 여러 서버에 걸쳐 다른 관리자에게 관리를 위임하는 기능을 제공하는 특정한 유형의 액티브 디렉터리(Active Directory) 계정이다.
|
||||
|
||||
쿠버네티스에서 GMSA 자격 증명 사양은 쿠버네티스 클러스터 전체 범위에서 사용자 정의 리소스(Custom Resources)로 구성된다. 윈도우 파드 및 파드 내의 개별 컨테이너들은 다른 윈도우 서비스와 상호 작용할 때 도메인 기반 기능(예: Kerberos 인증)에 GMSA를 사용하도록 구성할 수 있다. v1.16부터 도커 런타임은 윈도우 워크로드용 GMSA를 지원한다.
|
||||
|
||||
|
||||
쿠버네티스에서 GMSA 자격 증명 사양은 쿠버네티스 클러스터 전체 범위에서 사용자 정의 리소스(Custom Resources)로 구성된다. 윈도우 파드 및 파드 내의 개별 컨테이너들은 다른 윈도우 서비스와 상호 작용할 때 도메인 기반 기능(예: Kerberos 인증)에 GMSA를 사용하도록 구성할 수 있다.
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
쿠버네티스 클러스터가 있어야 하며 클러스터와 통신하도록 `kubectl` 커맨드라인 툴을 구성해야 한다. 클러스터에는 윈도우 워커 노드가 있어야 한다. 이 섹션에서는 각 클러스터에 대해 한 번씩 필요한 일련의 초기 단계를 다룬다.
|
||||
|
||||
|
||||
### GMSACredentialSpec CRD 설치
|
||||
|
||||
GMSA 자격 증명 사양 리소스에 대한 [커스텀리소스데피니션(CustomResourceDefinition,](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/) CRD)을 클러스터에서 구성하여 사용자 정의 리소스 유형 `GMSACredentialSpec`을 정의해야 한다. GMSA CRD [YAML](https://github.com/kubernetes-sigs/windows-gmsa/blob/master/admission-webhook/deploy/gmsa-crd.yml)을 다운로드하고 gmsa-crd.yaml로 저장한다.
|
||||
다음, `kubectl apply -f gmsa-crd.yaml` 로 CRD를 설치한다.
|
||||
|
||||
### GMSA 사용자를 검증하기 위해 웹훅 설치
|
||||
|
||||
쿠버네티스 클러스터에서 두 개의 웹훅을 구성하여 파드 또는 컨테이너 수준에서 GMSA 자격 증명 사양 참조를 채우고 검증한다.
|
||||
|
||||
1. 변형(mutating) 웹훅은 (파드 사양의 이름별로) GMSA에 대한 참조를 파드 사양 내 JSON 형식의 전체 자격 증명 사양으로 확장한다.
|
||||
|
|
@ -44,14 +43,14 @@ GMSA 자격 증명 사양 리소스에 대한 [커스텀리소스데피니션(Cu
|
|||
|
||||
스크립트에서 사용하는 [YAML 템플릿](https://github.com/kubernetes-sigs/windows-gmsa/blob/master/admission-webhook/deploy/gmsa-webhook.yml.tpl)을 사용하여 웹훅 및 (파라미터를 적절히 대체하여) 관련 오브젝트를 수동으로 배포할 수도 있다.
|
||||
|
||||
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## 액티브 디렉터리에서 GMSA 및 윈도우 노드 구성
|
||||
|
||||
쿠버네티스의 파드가 GMSA를 사용하도록 구성되기 전에 [윈도우 GMSA 문서](https://docs.microsoft.com/ko-kr/windows-server/security/group-managed-service-accounts/getting-started-with-group-managed-service-accounts#BKMK_Step1)에 설명된 대로 액티브 디렉터리에서 원하는 GMSA를 프로비저닝해야 한다. [윈도우 GMSA 문서](https://docs.microsoft.com/ko-kr/windows-server/security/group-managed-service-accounts/getting-started-with-group-managed-service-accounts#to-add-member-hosts-using-the-set-adserviceaccount-cmdlet)에 설명된 대로 원하는 GMSA와 연결된 시크릿 자격 증명에 접근하려면 (쿠버네티스 클러스터의 일부인) 윈도우 워커 노드를 액티브 디렉터리에서 구성해야 한다.
|
||||
|
||||
## GMSA 자격 증명 사양 리소스 생성
|
||||
|
||||
(앞에서 설명한 대로) GMSACredentialSpec CRD를 설치하면 GMSA 자격 증명 사양이 포함된 사용자 정의 리소스를 구성할 수 있다. GMSA 자격 증명 사양에는 시크릿 또는 민감한 데이터가 포함되어 있지 않다. 이것은 컨테이너 런타임이 원하는 윈도우 컨테이너 GMSA를 설명하는 데 사용할 수 있는 정보이다. GMSA 자격 증명 사양은 [PowerShell 스크립트](https://github.com/kubernetes-sigs/windows-gmsa/tree/master/scripts/GenerateCredentialSpecResource.ps1) 유틸리티를 사용하여 YAML 형식으로 생성할 수 있다.
|
||||
|
||||
다음은 JSON 형식으로 GMSA 자격 증명 사양 YAML을 수동으로 생성한 다음 변환하는 단계이다.
|
||||
|
|
@ -67,7 +66,7 @@ GMSA 자격 증명 사양 리소스에 대한 [커스텀리소스데피니션(Cu
|
|||
다음 YAML 구성은 `gmsa-WebApp1`이라는 GMSA 자격 증명 사양을 설명한다.
|
||||
|
||||
```yaml
|
||||
apiVersion: windows.k8s.io/v1alpha1
|
||||
apiVersion: windows.k8s.io/v1
|
||||
kind: GMSACredentialSpec
|
||||
metadata:
|
||||
name: gmsa-WebApp1 #임의의 이름이지만 참조로 사용된다.
|
||||
|
|
@ -92,6 +91,7 @@ credspec:
|
|||
위의 자격 증명 사양 리소스는 `gmsa-Webapp1-credspec.yaml`로 저장되고 `kubectl apply -f gmsa-Webapp1-credspec.yml`을 사용하여 클러스터에 적용될 수 있다.
|
||||
|
||||
## 특정 GMSA 자격 증명 사양에서 RBAC를 활성화하도록 cluster role 구성
|
||||
|
||||
각 GMSA 자격 증명 사양 리소스에 대해 cluster role을 정의해야 한다. 이것은 일반적으로 서비스 어카운트인 주체에 의해 특정 GMSA 리소스에 대한 `use` 동사를 승인한다. 다음 예는 위에서 `gmsa-WebApp1` 자격 증명 사양의 사용을 승인하는 클러스터 롤(cluster role)을 보여준다. 파일을 gmsa-webapp1-role.yaml로 저장하고 `kubectl apply -f gmsa-webapp1-role.yaml`을 사용하여 적용한다.
|
||||
|
||||
```yaml
|
||||
|
|
@ -108,6 +108,7 @@ rules:
|
|||
```
|
||||
|
||||
## 특정 GMSA credspecs를 사용하도록 서비스 어카운트에 롤 할당
|
||||
|
||||
(파드가 사용하게 되는) 서비스 어카운트는 위에서 생성한 클러스터 롤에 바인딩되어야 한다. 이렇게 하면 서비스 어카운트가 원하는 GMSA 자격 증명 사양 리소스를 사용할 수 있다. 다음은 위에서 생성한 `gmsa-WebApp1` 자격 증명 사양 리소스를 사용하기 위해 `webapp1-role` 클러스터 롤에 바인딩되는 기본(default) 서비스 어카운트이다.
|
||||
|
||||
```yaml
|
||||
|
|
@ -127,6 +128,7 @@ roleRef:
|
|||
```
|
||||
|
||||
## 파드 사양에서 GMSA 자격 증명 사양 참조 구성
|
||||
|
||||
파드 사양 필드 `securityContext.windowsOptions.gmsaCredentialSpecName`은 파드 사양에서 원하는 GMSA 자격 증명 사양 사용자 정의 리소스에 대한 참조를 지정하는 데 사용된다. 이렇게 하면 지정된 GMSA를 사용하도록 파드 사양의 모든 컨테이너가 구성된다. 다음은 `gmsa-WebApp1`을 참조하도록 채워진 어노테이션이 있는 샘플 파드 사양이다.
|
||||
|
||||
```yaml
|
||||
|
|
@ -197,55 +199,17 @@ spec:
|
|||
|
||||
1. 컨테이너 런타임은 컨테이너가 액티브 디렉터리에서 GMSA의 ID를 가정하고 해당 ID를 사용하여 도메인의 서비스에 접근할 수 있도록 지정된 GMSA 자격 증명 사양으로 각 윈도우 컨테이너를 구성한다.
|
||||
|
||||
## Containerd
|
||||
## 호스트네임 또는 FQDN을 사용하는 경우에 네트워크 공유에 인증하기
|
||||
|
||||
윈도우 서버 2019에서 containerd와 함께 GMSA를 사용하려면 패치 [KB5000822](https://support.microsoft.com/ko-kr/topic/2021년-3월-9일-kb5000822-os-빌드-17763-1817-2eb6197f-e3b1-4f42-ab51-84345e063564)된 OS Build 17763.1817 (또는 이후 버전)을 실행해야 한다.
|
||||
파드에서 호스트네임 또는 FQDN을 사용하여 SMB 공유에 연결할 때 문제를 겪고 있으나, IPv4 주소로는 해당 공유에 접속이 가능한 상황이라면, 윈도우 노드에 다음 레지스트리 키를 등록했는지 확인한다.
|
||||
|
||||
또한 파드에서 SMB 공유에 연결하려고 할 때 발생하는 containerd와 관련된 알려진 문제가 있다. GMSA를 구성하면 파드가 hostname 또는 FQDN을 사용하여 공유에 연결할 수 없지만, IP 주소를 사용하여 공유에 연결하면 예상대로 작동한다.
|
||||
|
||||
```PowerShell
|
||||
ping adserver.ad.local
|
||||
```
|
||||
hostname을 IPv4 주소로 올바르게 변환한다. 출력은 다음과 유사하다.
|
||||
|
||||
```
|
||||
Pinging adserver.ad.local [192.168.111.18] with 32 bytes of data:
|
||||
Reply from 192.168.111.18: bytes=32 time=6ms TTL=124
|
||||
Reply from 192.168.111.18: bytes=32 time=5ms TTL=124
|
||||
Reply from 192.168.111.18: bytes=32 time=5ms TTL=124
|
||||
Reply from 192.168.111.18: bytes=32 time=5ms TTL=124
|
||||
```cmd
|
||||
reg add "HKLM\SYSTEM\CurrentControlSet\Services\hns\State" /v EnableCompartmentNamespace /t REG_DWORD /d 1
|
||||
```
|
||||
|
||||
그러나 hostname을 사용하여 디렉터리를 탐색하려고 할 때
|
||||
|
||||
```PowerShell
|
||||
cd \\adserver.ad.local\test
|
||||
```
|
||||
|
||||
대상 공유가 존재하지 않음을 암시하는 오류가 표시된다.
|
||||
|
||||
```
|
||||
cd : Cannot find path '\\adserver.ad.local\test' because it does not exist.
|
||||
At line:1 char:1
|
||||
+ cd \\adserver.ad.local\test
|
||||
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
+ CategoryInfo : ObjectNotFound: (\\adserver.ad.local\test:String) [Set-Location], ItemNotFoundException
|
||||
+ FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.SetLocationCommand
|
||||
```
|
||||
|
||||
그러나 IPv4 주소를 대신 사용하여 공유를 탐색하면 오류가 사라진다. 다음은 예시이다.
|
||||
|
||||
```PowerShell
|
||||
cd \\192.168.111.18\test
|
||||
```
|
||||
|
||||
공유 내의 디렉터리로 변경하면 다음과 유사한 프롬프트가 표시된다.
|
||||
|
||||
```
|
||||
Microsoft.PowerShell.Core\FileSystem::\\192.168.111.18\test>
|
||||
```
|
||||
|
||||
동작을 수정하려면 노드에서 `reg add "HKLM\SYSTEM\CurrentControlSet\Services\hns\State" /v EnableCompartmentNamespace /t REG_DWORD /d 1`을 실행하여 필요한 레지스트리 키를 추가해야 한다. 이 노드 변경 사항은 새로 생성된 파드에만 적용되는데, SMB 공유에 액세스해야 하는 실행 중인 파드를 다시 생성해야 하는 것을 의미한다.
|
||||
그런 다음 동작 변경 사항을 적용하려면 실행 중인 파드를 다시 생성해야 한다.
|
||||
이 레지스트리 키가 어떻게 사용되는지에 대한 자세한 정보는
|
||||
[여기](https://github.com/microsoft/hcsshim/blob/885f896c5a8548ca36c88c4b87fd2208c8d16543/internal/uvm/create.go#L74-L83)에서 볼 수 있다.
|
||||
|
||||
## 문제 해결
|
||||
|
||||
|
|
@ -258,7 +222,9 @@ GMSA가 사용자 환경에서 작동하도록 하는 데 어려움이 있는
|
|||
```PowerShell
|
||||
kubectl exec -it iis-auth-7776966999-n5nzr powershell.exe
|
||||
```
|
||||
|
||||
`nltest.exe /parentdomain` 는 다음과 같은 오류를 발생시킨다.
|
||||
|
||||
```
|
||||
Getting parent domain failed: Status = 1722 0x6ba RPC_S_SERVER_UNAVAILABLE
|
||||
```
|
||||
|
|
|
|||
|
|
@ -7,8 +7,10 @@ weight: 100
|
|||
<!-- overview -->
|
||||
|
||||
이 페이지는 프라이빗 컨테이너 레지스트리나 리포지터리로부터 이미지를 받아오기 위해
|
||||
{{< glossary_tooltip text="시크릿(Secret)" term_id="secret" >}}을
|
||||
사용하는 파드를 생성하는 방법을 보여준다.
|
||||
{{< glossary_tooltip text="시크릿(Secret)" term_id="secret" >}}을 사용하는
|
||||
파드를 생성하는 방법을 보여준다.
|
||||
현재 많은 곳에서 프라이빗 레지스트리가 사용되고 있다.
|
||||
여기서는 예시 레지스트리로 [Docker Hub](https://www.docker.com/products/docker-hub)을 사용한다.
|
||||
|
||||
{{% thirdparty-content single="true" %}}
|
||||
|
||||
|
|
@ -17,7 +19,9 @@ weight: 100
|
|||
* {{< include "task-tutorial-prereqs.md" >}}
|
||||
|
||||
* 이 실습을 수행하기 위해, `docker` 명령줄 도구와
|
||||
[도커 ID](https://docs.docker.com/docker-id/) 및 비밀번호가 필요하다.
|
||||
[도커 ID](https://docs.docker.com/docker-id/) 및 비밀번호가 필요하다.
|
||||
* 다른 프라이빗 컨테이너 레지스트리를 사용하는 경우,
|
||||
해당 레지스트리를 위한 명령줄 도구 및 레지스트리 로그인 정보가 필요하다.
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
|
|
@ -59,12 +63,13 @@ cat ~/.docker/config.json
|
|||
도커 자격 증명 저장소를 사용하는 경우, `auth` 항목이 아닌, 저장소의 이름을 값으로 사용하는 `credsStore` 항목을 확인할 수 있다.
|
||||
{{< /note >}}
|
||||
|
||||
## 기존의 도커 자격 증명을 기반으로 시크릿 생성하기 {#registry-secret-existing-credentials}
|
||||
## 기존의 자격 증명을 기반으로 시크릿 생성하기 {#registry-secret-existing-credentials}
|
||||
|
||||
쿠버네티스 클러스터는 프라이빗 이미지를 받아올 때, 컨테이너 레지스트리에 인증하기 위하여
|
||||
`kubernetes.io/dockerconfigjson` 타입의 시크릿을 사용한다.
|
||||
|
||||
만약 이미 `docker login` 을 수행하였다면, 이 때 생성된 자격 증명을 쿠버네티스 클러스터로 복사할 수 있다.
|
||||
만약 이미 `docker login` 을 수행하였다면,
|
||||
이 때 생성된 자격 증명을 쿠버네티스 클러스터로 복사할 수 있다.
|
||||
|
||||
```shell
|
||||
kubectl create secret generic regcred \
|
||||
|
|
@ -77,7 +82,7 @@ kubectl create secret generic regcred \
|
|||
다음을 확인하자.
|
||||
|
||||
- 데이터 항목의 이름을 `.dockerconfigjson` 으로 설정한다
|
||||
- 도커 파일을 base64로 인코딩하고 그 문자열을 `data[".dockerconfigjson"]`
|
||||
- 도커 구성 파일을 base64로 인코딩하고 그 문자열을 `data[".dockerconfigjson"]`
|
||||
필드에 자르지 않고 한 줄로 이어서 붙여넣는다
|
||||
- `type` 을 `kubernetes.io/dockerconfigjson` 으로 설정한다
|
||||
|
||||
|
|
|
|||
|
|
@ -42,7 +42,7 @@ API 서버에서 제어될 수는 없다.
|
|||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
이 페이지는 파드를 실행하기 위해 {{< glossary_tooltip term_id="docker" >}}를 사용하며,
|
||||
이 페이지는 파드를 실행하기 위해 {{< glossary_tooltip term_id="cri-o" >}}를 사용하며,
|
||||
노드에서 Fedora 운영 체제를 구동하고 있다고 가정한다.
|
||||
다른 배포판이나 쿠버네티스 설치 지침과는 다소 상이할 수 있다.
|
||||
|
||||
|
|
@ -156,15 +156,20 @@ Kubelet 을 시작하면, 정의된 모든 스태틱 파드가 자동으로 시
|
|||
(노드에서) 구동되고 있는 (스태틱 파드를 포함한) 컨테이너들을 볼 수 있다.
|
||||
```shell
|
||||
# kubelet 이 동작하고 있는 노드에서 이 명령을 수행한다.
|
||||
docker ps
|
||||
crictl ps
|
||||
```
|
||||
|
||||
결과는 다음과 유사하다.
|
||||
|
||||
```console
|
||||
CONTAINER IMAGE CREATED STATE NAME ATTEMPT POD ID
|
||||
129fd7d382018 docker.io/library/nginx@sha256:... 11 minutes ago Running web 0 34533c6729106
|
||||
```
|
||||
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
|
||||
f6d05272b57e nginx:latest "nginx" 8 minutes ago Up 8 minutes k8s_web.6f802af4_static-web-fk-node1_default_67e24ed9466ba55986d120c867395f3c_378e5f3c
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
`crictl`은 이미지 URI와 SHA-256 체크섬을 출력한다. `NAME`은 다음과 같을 것이다.
|
||||
`docker.io/library/nginx@sha256:0d17b565c37bcbd895e9d92315a05c1c3c9a29f762b011a10c54a66cd53c9b31`
|
||||
{{< /note >}}
|
||||
|
||||
API 서버에서 미러 파드를 볼 수 있다.
|
||||
|
||||
|
|
@ -172,8 +177,8 @@ API 서버에서 미러 파드를 볼 수 있다.
|
|||
kubectl get pods
|
||||
```
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
static-web-my-node1 1/1 Running 0 2m
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
static-web 1/1 Running 0 2m
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
|
|
@ -181,7 +186,6 @@ Kubelet에 API 서버에서 미러 파드를 생성할 수 있는 권한이 있
|
|||
[파드시큐리티폴리시(PodSecurityPolicy)](/ko/docs/concepts/policy/pod-security-policy/) 에 대해 보기.
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
스태틱 파드에 있는 {{< glossary_tooltip term_id="label" text="레이블" >}} 은
|
||||
미러 파드로 전파된다. {{< glossary_tooltip term_id="selector" text="셀렉터" >}} 등을
|
||||
통하여 이러한 레이블을 사용할 수 있다.
|
||||
|
|
@ -190,34 +194,33 @@ Kubelet에 API 서버에서 미러 파드를 생성할 수 있는 권한이 있
|
|||
kubelet 은 스태틱 파드를 지우지 _않는다._
|
||||
|
||||
```shell
|
||||
kubectl delete pod static-web-my-node1
|
||||
kubectl delete pod static-web
|
||||
```
|
||||
```
|
||||
pod "static-web-my-node1" deleted
|
||||
pod "static-web" deleted
|
||||
```
|
||||
파드가 여전히 구동 중인 것을 볼 수 있다.
|
||||
```shell
|
||||
kubectl get pods
|
||||
```
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
static-web-my-node1 1/1 Running 0 12s
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
static-web 1/1 Running 0 4s
|
||||
```
|
||||
|
||||
kubelet 이 구동 중인 노드로 돌아가서 도커 컨테이너를 수동으로
|
||||
중지할 수 있다.
|
||||
kubelet 이 구동 중인 노드로 돌아가서 컨테이너를 수동으로 중지할 수 있다.
|
||||
일정 시간이 지나면, kubelet이 파드를 자동으로 인식하고 다시 시작하는
|
||||
것을 볼 수 있다.
|
||||
|
||||
```shell
|
||||
# kubelet 이 동작하고 있는 노드에서 이 명령을 수행한다.
|
||||
docker stop f6d05272b57e # 예제를 수행하는 사용자의 컨테이너 ID로 변경한다.
|
||||
crictl stop 129fd7d382018 # 예제를 수행하는 사용자의 컨테이너 ID로 변경한다.
|
||||
sleep 20
|
||||
docker ps
|
||||
crictl ps
|
||||
```
|
||||
```
|
||||
CONTAINER ID IMAGE COMMAND CREATED ...
|
||||
5b920cbaf8b1 nginx:latest "nginx -g 'daemon of 2 seconds ago ...
|
||||
```console
|
||||
CONTAINER IMAGE CREATED STATE NAME ATTEMPT POD ID
|
||||
89db4553e1eeb docker.io/library/nginx@sha256:... 19 seconds ago Running web 1 34533c6729106
|
||||
```
|
||||
|
||||
## 스태틱 파드의 동적 추가 및 제거
|
||||
|
|
@ -230,13 +233,13 @@ CONTAINER ID IMAGE COMMAND CREATED ...
|
|||
#
|
||||
mv /etc/kubelet.d/static-web.yaml /tmp
|
||||
sleep 20
|
||||
docker ps
|
||||
crictl ps
|
||||
# 구동 중인 nginx 컨테이너가 없는 것을 확인한다.
|
||||
mv /tmp/static-web.yaml /etc/kubelet.d/
|
||||
sleep 20
|
||||
docker ps
|
||||
crictl ps
|
||||
```
|
||||
```
|
||||
CONTAINER ID IMAGE COMMAND CREATED ...
|
||||
e7a62e3427f1 nginx:latest "nginx -g 'daemon of 27 seconds ago
|
||||
```console
|
||||
CONTAINER IMAGE CREATED STATE NAME ATTEMPT POD ID
|
||||
f427638871c35 docker.io/library/nginx@sha256:... 19 seconds ago Running web 1 34533c6729106
|
||||
```
|
||||
|
|
|
|||
|
|
@ -68,7 +68,7 @@ kubelet은 비율 계산에 사용할 윈도우를 선택한다.
|
|||
|
||||
### 요약(Summary) API 소스
|
||||
[Kubelet](/docs/reference/command-line-tools-reference/kubelet/)은 노드, 볼륨, 파드, 컨테이너 수준의 통계를 수집하며,
|
||||
소비자(consumer)가 읽을 수 있도록 이를
|
||||
소비자(consumer)가 읽을 수 있도록 이 통계를
|
||||
[요약 API](https://github.com/kubernetes/kubernetes/blob/7d309e0104fedb57280b261e5677d919cb2a0e2d/staging/src/k8s.io/kubelet/pkg/apis/stats/v1alpha1/types.go)에 기록한다.
|
||||
|
||||
1.23 이전에는 이러한 자원들은 기본적으로 [cAdvisor](https://github.com/google/cadvisor)에 의해 수집되었다.
|
||||
|
|
|
|||
|
|
@ -37,7 +37,6 @@ weight: 10
|
|||
|
||||
{{< note >}}
|
||||
`command` 필드는 일부 컨테이너 런타임에서 `entrypoint`에 해당된다.
|
||||
아래의 [참고사항](#참고사항)을 확인하자.
|
||||
{{< /note >}}
|
||||
|
||||
이 예제에서는 한 개의 컨테이너를 실행하는 파드를 생성한다. 파드를 위한 구성
|
||||
|
|
@ -111,43 +110,6 @@ command: ["/bin/sh"]
|
|||
args: ["-c", "while true; do echo hello; sleep 10;done"]
|
||||
```
|
||||
|
||||
## 참고사항
|
||||
|
||||
이 테이블은 도커와 쿠버네티스에서 사용되는 필드 이름들을 정리한 것이다.
|
||||
|
||||
| 설명 | 도커 필드 이름 | 쿠버네티스 필드 이름 |
|
||||
|----------------------------------------|------------------------|-----------------------|
|
||||
| 컨테이너에서 실행되는 커맨드 | Entrypoint | command |
|
||||
| 커맨드에 전달되는 인자들 | Cmd | arg |
|
||||
|
||||
기본 Entrypoint와 Cmd 값을 덮어쓰려고 한다면, 아래의 규칙들이 적용된다.
|
||||
|
||||
* 만약 컨테이너를 위한 `command` 값이나 `args` 값을 제공하지 않는다면, 도커 이미지 안에
|
||||
제공되는 기본 값들이 사용된다.
|
||||
|
||||
* 만약 컨테이너를 위한 `command` 값을 제공하고, `args` 값을 제공하지 않는다면,
|
||||
제공된 `command` 값만이 사용된다. 도커 이미지 안에 정의된 기본 EntryPoint 값과 기본
|
||||
Cmd 값은 덮어쓰여진다.
|
||||
|
||||
* 만약 컨테이너를 위한 `args` 값만 제공한다면, 도커 이미지 안에 정의된 기본 EntryPoint
|
||||
값이 정의한 `args` 값들과 함께 실행된다.
|
||||
|
||||
* `command` 값과 `args` 값을 동시에 정의한다면, 도커 이미지 안에 정의된 기본
|
||||
EntryPoint 값과 기본 Cmd 값이 덮어쓰여진다. `command`가 `args` 값과 함께
|
||||
실행된다.
|
||||
|
||||
여기 몇 가지 예시들이 있다.
|
||||
|
||||
| 이미지 Entrypoint | 이미지 Cmd | 컨테이너 command | 컨테이너 args | 실행되는 커맨드 |
|
||||
|--------------------|------------------|---------------------|--------------------|------------------|
|
||||
| `[/ep-1]` | `[foo bar]` | <설정되지 않음> | <설정되지 않음> | `[ep-1 foo bar]` |
|
||||
| `[/ep-1]` | `[foo bar]` | `[/ep-2]` | <설정되지 않음> | `[ep-2]` |
|
||||
| `[/ep-1]` | `[foo bar]` | <설정되지 않음> | `[zoo boo]` | `[ep-1 zoo boo]` |
|
||||
| `[/ep-1]` | `[foo bar]` | `[/ep-2]` | `[zoo boo]` | `[ep-2 zoo boo]` |
|
||||
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -38,8 +38,8 @@ weight: 10
|
|||
(기본값은 1),
|
||||
[`.spec.minReadySeconds`](/ko/docs/concepts/workloads/controllers/deployment/#최소-대기-시간초)
|
||||
(기본값은 0),
|
||||
[`.spec.maxSurge`](/ko/docs/concepts/workloads/controllers/deployment/#최대-서지-max-surge)
|
||||
(베타 기능, 기본값은 25%)를
|
||||
[`.spec.updateStrategy.rollingUpdate.maxSurge`](/docs/reference/kubernetes-api/workload-resources/daemon-set-v1/#DaemonSetSpec)
|
||||
(베타 기능, 기본값은 0)를
|
||||
설정할 수도 있다.
|
||||
|
||||
### `RollingUpdate` 업데이트 전략으로 데몬셋 생성
|
||||
|
|
|
|||
|
|
@ -86,12 +86,20 @@ metadata:
|
|||
name: example-configmap-1-8mbdf7882g
|
||||
```
|
||||
|
||||
env 파일에서 컨피그맵을 생성하려면, `configMapGenerator`의 `envs` 리스트에 항목을 추가한다. 다음은 `.env` 파일의 데이터 항목으로 컨피그맵을 생성하는 예시를 보여준다.
|
||||
env 파일에서 컨피그맵을 생성하려면, `configMapGenerator`의 `envs` 리스트에 항목을 추가한다. `=` 및 값을 생략하여 로컬 환경 변수로부터 값을 설정할 수도 있다.
|
||||
|
||||
{{< note >}}
|
||||
로컬 환경 변수 채우기 기능은 꼭 필요한 경우에만 사용하는 것이 좋은데, 이는 패치를 할 수 있는 오버레이가 있는 편이 유지 관리에 더 유리하기 때문이다. 로컬 환경 변수 채우기 기능은 git SHA와 같이 그 값을 쉽게 예측할 수 없는 경우에 유용할 수 있다.
|
||||
{{< /note >}}
|
||||
|
||||
다음은 `.env` 파일의 데이터 항목으로 컨피그맵을 생성하는 예시를 보여준다.
|
||||
|
||||
```shell
|
||||
# .env 파일 생성
|
||||
# BAZ 에는 로컬 환경 변수 $BAZ 의 값이 입력될 것이다
|
||||
cat <<EOF >.env
|
||||
FOO=Bar
|
||||
BAZ
|
||||
EOF
|
||||
|
||||
cat <<EOF >./kustomization.yaml
|
||||
|
|
@ -105,7 +113,7 @@ EOF
|
|||
생성된 컨피그맵은 다음 명령어로 검사할 수 있다.
|
||||
|
||||
```shell
|
||||
kubectl kustomize ./
|
||||
BAZ=Qux kubectl kustomize ./
|
||||
```
|
||||
|
||||
생성된 컨피그맵은 다음과 같다.
|
||||
|
|
@ -113,10 +121,11 @@ kubectl kustomize ./
|
|||
```yaml
|
||||
apiVersion: v1
|
||||
data:
|
||||
FOO=Bar
|
||||
BAZ: Qux
|
||||
FOO: Bar
|
||||
kind: ConfigMap
|
||||
metadata:
|
||||
name: example-configmap-1-8mbdf7882g
|
||||
name: example-configmap-1-892ghb99c8
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
|
|
@ -748,8 +757,8 @@ spec:
|
|||
커맨드 인수 내에 서비스 네임을 하드 코딩하는 것을 권장하지 않는다. 이 용도에서 Kustomize는 `vars`를 통해 containers에 서비스 네임을 삽입할 수 있다.
|
||||
|
||||
```shell
|
||||
# deployment.yaml 파일 생성
|
||||
cat <<EOF > deployment.yaml
|
||||
# deployment.yaml 파일 생성(문서 구분 기호를 따옴표로 감쌈)
|
||||
cat <<'EOF' > deployment.yaml
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
|
|
|
|||
|
|
@ -1,4 +1,7 @@
|
|||
---
|
||||
|
||||
|
||||
|
||||
title: HostAliases로 파드의 /etc/hosts 항목 추가하기
|
||||
content_type: task
|
||||
weight: 60
|
||||
|
|
@ -114,10 +117,15 @@ fe00::2 ip6-allrouters
|
|||
|
||||
## 왜 Kubelet이 호스트 파일을 관리하는가? {#why-does-kubelet-manage-the-hosts-file}
|
||||
|
||||
컨테이너가 이미 시작되고 난 후 도커가 파일을
|
||||
[수정](https://github.com/moby/moby/issues/17190)하는 것을 방지하기 위해
|
||||
Kubelet은 파드의 각 컨테이너의 `hosts` 파일을
|
||||
[관리](https://github.com/kubernetes/kubernetes/issues/14633)한다.
|
||||
컨테이너가 이미 시작되고 난 뒤에
|
||||
컨테이너 런타임이 `hosts` 파일을 수정하는 것을 방지하기 위해,
|
||||
Kubelet이 파드의 각 컨테이너의 `hosts` 파일을 관리한다.
|
||||
역사적으로, 쿠버네티스는 컨테이너 런타임으로 계속 도커 엔진을 사용해 왔으며,
|
||||
각 컨테이너가 시작된 뒤에 도커 엔진이 `/etc/hosts` 파일을 수정할 수 있었다.
|
||||
|
||||
현재 쿠버네티스는 다양한 컨테이너 런타임을 사용할 수 있으며,
|
||||
kubelet이 각 컨테이너 내의 `hosts` 파일을 관리하므로
|
||||
어떤 컨테이너 런타임을 사용하는지에 상관없이 동일한 결과를 얻을 수 있다.
|
||||
|
||||
{{< caution >}}
|
||||
컨테이너 내부의 호스트 파일을 수동으로 변경하면 안된다.
|
||||
|
|
|
|||
|
|
@ -55,10 +55,11 @@ Horizontal Pod Autoscaling을 활용하는
|
|||
실행 주기는 [`kube-controller-manager`](/docs/reference/command-line-tools-reference/kube-controller-manager/)의
|
||||
`--horizontal-pod-autoscaler-sync-period` 파라미터에 의해 설정된다(기본 주기는 15초이다).
|
||||
|
||||
각 주기마다, 컨트롤러 관리자는 각 HorizontalPodAutoscaler 정의에
|
||||
지정된 메트릭에 대해 리소스 사용률을 질의한다. 컨트롤러 관리자는 리소스
|
||||
메트릭 API(파드 단위 리소스 메트릭 용)
|
||||
또는 사용자 지정 메트릭 API(다른 모든 메트릭 용)에서 메트릭을 가져온다.
|
||||
각 주기마다, 컨트롤러 매니저는 각 HorizontalPodAutoscaler 정의에 지정된 메트릭에 대해 리소스 사용률을 질의한다.
|
||||
컨트롤러 매니저는 `scaleTargetRef`에 의해 정의된 타겟 리소스를 찾고 나서,
|
||||
타겟 리소스의 `.spec.selector` 레이블을 보고 파드를 선택하며,
|
||||
리소스 메트릭 API(파드 단위 리소스 메트릭 용) 또는
|
||||
커스텀 메트릭 API(그 외 모든 메트릭 용)로부터 메트릭을 수집한다.
|
||||
|
||||
* 파드 단위 리소스 메트릭(예 : CPU)의 경우 컨트롤러는 HorizontalPodAutoscaler가
|
||||
대상으로하는 각 파드에 대한 리소스 메트릭 API에서 메트릭을 가져온다.
|
||||
|
|
|
|||
Loading…
Reference in New Issue