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

Merge pull request #32789 from kubernetes/dev-1.23-ko.2

Browse Source 
[ko] 2nd Korean localization work for v1.23
This commit is contained in:
Kubernetes Prow Robot
2022-04-06 23:53:56 -07:00
committed by GitHub
parent a6aee0c410 7da9d0d276
commit c38941a3b1
126 changed files with 2393 additions and 1157 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/ko/docs/tasks/access-application-cluster/access-cluster.md
+1 -1
View File
@@ -214,7 +214,7 @@ apiserver의 인증서 제공을 검증하는데 사용되어야 한다.
## 클러스터에서 실행되는 서비스로 접근
이전 섹션에서는 쿠버네티스 API 서버에 연결하는 방법을 소개하였다. 쿠버네티스 클러스터에서 실행되는 다른 서비스에 연결하는 방법은 [클러스터 접근](/ko/docs/tasks/access-application-cluster/access-cluster/) 페이지를 참조한다.
이전 섹션에서는 쿠버네티스 API 서버에 연결하는 방법을 소개하였다. 쿠버네티스 클러스터에서 실행되는 다른 서비스에 연결하는 방법은 [클러스터 서비스에 접근](/ko/docs/tasks/administer-cluster/access-cluster-services/) 페이지를 참조한다.
## redirect 요청하기
content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md
+2 -2
View File
@@ -218,8 +218,8 @@ Kubeconfig 인증 방법은 외부 아이덴티티 프로바이더
#### 워크로드
선택된 네임스페이스에서 구동되는 모든 애플리케이션을 보여준다.
애플리케이션의 워크로드 종류(예시: 디플로이먼트, 레플리카셋(ReplicaSet), 스테이트풀셋(StatefulSet))를 보여주고
각각의 워크로드 종류는 따로 보여진다.
해당 뷰는 애플리케이션의 워크로드 종류(예시: 디플로이먼트, 레플리카셋(ReplicaSet), 스테이트풀셋(StatefulSet))를 보여준다.
각각의 워크로드 종류는 분리하여 볼 수 있다.
리스트는 예를 들어 레플리카셋에서 준비된 파드의 숫자 또는 파드의 현재 메모리 사용량과 같은
워크로드에 대한 실용적인 정보를 요약한다.
content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md
+2 -2
View File
@@ -282,8 +282,8 @@ CSR 서명자를 가지고 있는지 문의하는 것을 추천한다.
{{% thirdparty-content %}}
제 3 자 커스텀 컨트롤러도 사용될 수 있다.
- [kubelet-rubber-stamp](https://github.com/kontena/kubelet-rubber-stamp)
써드파티 커스텀 컨트롤러도 사용될 수 있다.
- [kubelet-csr-approver](https://github.com/postfinance/kubelet-csr-approver)
이러한 컨트롤러는 CSR의 CommonName과 요청된 IPs 및 도메인 네임을
모두 검증하지 않는 한, 보안이 되는 메커니즘이 아니다. 이것을 통해 악의적 행위자가
content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md
+9 -6
View File
@@ -16,10 +16,10 @@ weight: 20
이전 버전의 kubeadm을 사용하여 생성된 클러스터 업그레이드에 대한 정보를 보려면,
이 페이지 대신 다음의 페이지들을 참고한다.
- [kubeadm 클러스터를 {{< skew currentVersionAddMinor -2 >}}에서 {{< skew currentVersionAddMinor -1 >}}로 업그레이드](https://v{{< skew currentVersionAddMinor -1 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
- [kubeadm 클러스터를 {{< skew currentVersionAddMinor -3 >}}에서 {{< skew currentVersionAddMinor -2 >}}로 업그레이드](https://v{{< skew currentVersionAddMinor -2 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
- [kubeadm 클러스터를 {{< skew currentVersionAddMinor -4 >}}에서 {{< skew currentVersionAddMinor -3 >}}로 업그레이드](https://v{{< skew currentVersionAddMinor -3 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
- [kubeadm 클러스터를 {{< skew currentVersionAddMinor -5 >}}에서 {{< skew currentVersionAddMinor -4 >}}으로 업그레이드](https://v{{< skew currentVersionAddMinor -4 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
- [kubeadm 클러스터를 {{< skew currentVersionAddMinor -2 >}}에서 {{< skew currentVersionAddMinor -1 >}}로 업그레이드](https://v{{< skew currentVersionAddMinor -1 "-" >}}.docs.kubernetes.io/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
- [kubeadm 클러스터를 {{< skew currentVersionAddMinor -3 >}}에서 {{< skew currentVersionAddMinor -2 >}}로 업그레이드](https://v{{< skew currentVersionAddMinor -2 "-" >}}.docs.kubernetes.io/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
- [kubeadm 클러스터를 {{< skew currentVersionAddMinor -4 >}}에서 {{< skew currentVersionAddMinor -3 >}}로 업그레이드](https://v{{< skew currentVersionAddMinor -3 "-" >}}.docs.kubernetes.io/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
- [kubeadm 클러스터를 {{< skew currentVersionAddMinor -5 >}}에서 {{< skew currentVersionAddMinor -4 >}}으로 업그레이드](https://v{{< skew currentVersionAddMinor -4 "-" >}}.docs.kubernetes.io/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
추상적인 업그레이드 작업 절차는 다음과 같다.
@@ -37,8 +37,11 @@ weight: 20
### 추가 정보
- kubelet 마이너 버전을 업그레이드하기 전에 [노드 드레이닝(draining)](/docs/tasks/administer-cluster/safely-drain-node/)이
필요하다. 컨트롤 플레인 노드의 경우 CoreDNS 파드 또는 기타 중요한 워크로드를 실행할 수 있다.
- 아래의 지침은 업그레이드 과정 중 언제 각 노드를 드레인해야 하는지를 제시한다.
kubelet에 대해 **마이너** 버전 업그레이드를 하는 경우,
먼저 업그레이드할 노드(들)을 드레인**해야 한다**.
컨트롤 플레인 노드의 경우, CoreDNS 파드 또는 다른 중요한 워크로드를 실행 중일 수 있다.
더 많은 정보는 [노드 드레인하기](/docs/tasks/administer-cluster/safely-drain-node/)를 참조한다.
- 컨테이너 사양 해시 값이 변경되므로, 업그레이드 후 모든 컨테이너가 다시 시작된다.
<!-- steps -->
content/ko/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace.md
+44 -35
View File
@@ -2,16 +2,20 @@
title: 네임스페이스에 대한 CPU의 최소 및 최대 제약 조건 구성
content_type: task
weight: 40
description: >-
한 네임스페이스 내에서 CPU 리소스 제한의 유효한 범위를 정의하며,
이를 통해 해당 네임스페이스의 새로운 파드가 미리 설정한 범위 안에 들어오도록 한다.
---
<!-- overview -->
이 페이지는 네임스페이스에서 컨테이너와 파드가 사용하는 CPU 리소스의 최솟값과 최댓값을 설정하는
방법을 보여준다. [리밋레인지(LimitRange)](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#limitrange-v1-core)
오브젝트에 CPU의 최솟값과 최댓값을
지정한다. 리밋레인지에 의해 부과된 제약 조건을 파드가 충족하지 않으면, 네임스페이스에서
생성될 수 없다.
이 페이지는 {{< glossary_tooltip text="네임스페이스" term_id="namespace" >}}에서
컨테이너와 파드가 사용하는 CPU 리소스의 최솟값과 최댓값을 설정하는 방법을 보여준다.
[리밋레인지(LimitRange)](/docs/reference/kubernetes-api/policy-resources/limit-range-v1/) 오브젝트에
CPU의 최솟값과 최댓값을 지정한다.
리밋레인지에 의해 부과된 제약 조건을 파드가 충족하지 않으면,
해당 네임스페이스에 생성될 수 없다.
@@ -19,11 +23,13 @@ weight: 40
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
태스크 예제를 실행하려면 클러스터에 적어도 1 CPU 이상이 사용 가능해야 한다.
{{< include "task-tutorial-prereqs.md" >}}
클러스터에 네임스페이스를 생성할 수 있는 권한이 있어야 한다.
태스크 예제를 실행하려면 클러스터에 적어도 1.0 CPU 이상이 사용 가능해야 한다.
쿠버네티스에서 “1 CPU”가 무엇을 의미하는지 알아보려면
[CPU의 의미](/ko/docs/concepts/configuration/manage-resources-containers/#cpu의-의미)를 참조한다.
<!-- steps -->
@@ -39,7 +45,7 @@ kubectl create namespace constraints-cpu-example
## 리밋레인지와 파드 생성
다음은 리밋레인지에 대한 구성 파일이다.
다음은 리밋레인지에 대한 예시 매니페스트이다.
{{< codenew file="admin/resource/cpu-constraints.yaml" >}}
@@ -72,15 +78,15 @@ limits:
type: Container
```
이제 constraints-cpu-example 네임스페이스에 컨테이너가 생성될 때마다, 쿠버네티스는
다음 단계를 수행한다.
이제 `constraints-cpu-example` 네임스페이스에 파드를 생성할 때마다(또는
다른 쿠버네티스 API 클라이언트가 동일한 파드를 생성할 때마다), 쿠버네티스는 다음 단계를 수행한다.
* 컨테이너가 자체 CPU 요청량(request)과 상한(limit)을 지정하지 않으면, 컨테이너에
CPU 요청량과 상한의 기본값(default)을 지정한다.
* 해당 파드의 어떤 컨테이너도 자체 CPU 요청량(request)과 상한(limit)을 명시하지 않으면,
컨트롤 플레인이 해당 컨테이너에 CPU 요청량과 상한의 기본값(default)을 지정한다.
* 컨테이너가 200 millicpu 이상의 CPU 요청량을 지정하는지 확인한다.
* 해당 파드의 모든 컨테이너가 200 millicpu 이상의 CPU 요청량을 지정하는지 확인한다.
* 컨테이너가 800 millicpu 이하의 CPU 상한을 지정하는지 확인한다.
* 해당 파드의 모든 컨테이너가 800 millicpu 이하의 CPU 상한을 지정하는지 확인한다.
{{< note >}}
`LimitRange` 오브젝트를 생성할 때, huge-pages
@@ -88,8 +94,8 @@ CPU 요청량과 상한의 기본값(default)을 지정한다.
모두 지정되어 있으면, 두 값은 같아야 한다.
{{< /note >}}
컨테이너가 하나인 파드의 구성 파일은 다음과 같다. 컨테이너 매니페스트는
500 millicpu의 CPU 요청량 및 800 millicpu의 CPU 상한을 지정한다. 이는 리밋레인지에
다음은 컨테이너가 하나인 파드의 매니페스트이다. 컨테이너 매니페스트는
500 millicpu의 CPU 요청량 및 800 millicpu의 CPU 상한을 지정하고 있다. 이는 리밋레인지에
의해 부과된 CPU의 최소와 최대 제약 조건을 충족시킨다.
{{< codenew file="admin/resource/cpu-constraints-pod.yaml" >}}
@@ -100,7 +106,7 @@ CPU 요청량과 상한의 기본값(default)을 지정한다.
kubectl apply -f https://k8s.io/examples/admin/resource/cpu-constraints-pod.yaml --namespace=constraints-cpu-example
```
파드의 컨테이너가 실행 중인지 확인한다.
파드가 실행 중이고 컨테이너의 상태가 정상인지 확인한다.
```shell
kubectl get pod constraints-cpu-demo --namespace=constraints-cpu-example
@@ -112,7 +118,7 @@ kubectl get pod constraints-cpu-demo --namespace=constraints-cpu-example
kubectl get pod constraints-cpu-demo --output=yaml --namespace=constraints-cpu-example
```
출력 결과는 컨테이너의 CPU 요청량이 500 millicpu이고, CPU 상한이 800 millicpu임을
출력 결과는 파드 내 유일한 컨테이너의 CPU 요청량이 500 millicpu이고, CPU 상한이 800 millicpu임을
나타낸다. 이는 리밋레인지에 의해 부과된 제약 조건을 만족시킨다.
```yaml
@@ -131,8 +137,8 @@ kubectl delete pod constraints-cpu-demo --namespace=constraints-cpu-example
## CPU 최대 제약 조건을 초과하는 파드 생성 시도
컨테이너가 하나인 파드의 구성 파일은 다음과 같다. 컨테이너는
500 millicpu의 CPU 요청량과 1.5 cpu의 CPU 상한을 지정한다.
다음은 컨테이너가 하나인 파드의 매니페스트이다. 컨테이너는
500 millicpu의 CPU 요청량과 1.5 cpu의 CPU 상한을 지정하고 있다.
{{< codenew file="admin/resource/cpu-constraints-pod-2.yaml" >}}
@@ -142,8 +148,8 @@ kubectl delete pod constraints-cpu-demo --namespace=constraints-cpu-example
kubectl apply -f https://k8s.io/examples/admin/resource/cpu-constraints-pod-2.yaml --namespace=constraints-cpu-example
```
컨테이너가 너무 큰 CPU 상한을 지정하므로, 출력 결과에 파드가 생성되지 않은 것으로
표시된다.
결과를 보면 파드가 생성되지 않은 것을 확인할 수 있으며, 이는 해당 파드가 수용 불가능한 컨테이너를 정의하고 있기 때문이다.
해당 컨테이너가 수용 불가능한 이유는 너무 큰 CPU 상한을 지정하고 있기 때문이다.
```
Error from server (Forbidden): error when creating "examples/admin/resource/cpu-constraints-pod-2.yaml":
@@ -152,8 +158,8 @@ pods "constraints-cpu-demo-2" is forbidden: maximum cpu usage per Container is 8
## 최소 CPU 요청량을 충족하지 않는 파드 생성 시도
컨테이너가 하나인 파드의 구성 파일은 다음과 같다. 컨테이너는
100 millicpu의 CPU 요청량과 800 millicpu의 CPU 상한을 지정한다.
다음은 컨테이너가 하나인 파드의 매니페스트이다. 컨테이너는
100 millicpu의 CPU 요청량과 800 millicpu의 CPU 상한을 지정하고 있다.
{{< codenew file="admin/resource/cpu-constraints-pod-3.yaml" >}}
@@ -163,8 +169,9 @@ pods "constraints-cpu-demo-2" is forbidden: maximum cpu usage per Container is 8
kubectl apply -f https://k8s.io/examples/admin/resource/cpu-constraints-pod-3.yaml --namespace=constraints-cpu-example
```
컨테이너가 너무 작은 CPU 요청량을 지정하므로, 출력 결과에 파드가 생성되지
않은 것으로 표시된다.
결과를 보면 파드가 생성되지 않은 것을 확인할 수 있으며, 이는 해당 파드가 수용 불가능한 컨테이너를 정의하고 있기 때문이다.
해당 컨테이너가 수용 불가능한 이유는
지정된 최저 CPU 상한보다도 낮은 CPU 상한을 지정하고 있기 때문이다.
```
Error from server (Forbidden): error when creating "examples/admin/resource/cpu-constraints-pod-3.yaml":
@@ -173,8 +180,8 @@ pods "constraints-cpu-demo-3" is forbidden: minimum cpu usage per Container is 2
## CPU 요청량 또는 상한을 지정하지 않은 파드 생성
컨테이너가 하나인 파드의 구성 파일은 다음과 같다. 컨테이너는
CPU 요청량을 지정하지 않으며, CPU 상한을 지정하지 않는다.
다음은 컨테이너가 하나인 파드의 매니페스트이다. 컨테이너는
CPU 요청량을 지정하지 않았으며, CPU 상한도 지정하지 않았다.
{{< codenew file="admin/resource/cpu-constraints-pod-4.yaml" >}}
@@ -190,8 +197,9 @@ kubectl apply -f https://k8s.io/examples/admin/resource/cpu-constraints-pod-4.ya
kubectl get pod constraints-cpu-demo-4 --namespace=constraints-cpu-example --output=yaml
```
출력 결과는 파드의 컨테이너에 대한 CPU 요청량이 800 millicpu이고, CPU 상한이 800 millicpu임을 나타낸다.
컨테이너는 어떻게 이런 값을 얻었을까?
출력을 보면 파드의 유일한 컨테이너에 대한 CPU 요청량이 800 millicpu이고,
CPU 상한이 800 millicpu이다.
이 컨테이너는 어떻게 이런 값을 얻었을까?
```yaml
resources:
@@ -201,11 +209,12 @@ resources:
cpu: 800m
```
컨테이너가 자체 CPU 요청량과 상한을 지정하지 않았으므로, 리밋레인지로부터
[CPU 요청량과 상한의 기본값](/ko/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/)이
주어졌다.
컨테이너가 자체 CPU 요청량과 상한을 지정하지 않았으므로,
컨테이너가 이 네임스페이스에 대해 리밋레인지로부터
[CPU 요청량과 상한의 기본값](/ko/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/)을
적용했다.
이 시점에서, 컨테이너는 실행 중이거나 실행 중이 아닐 수 있다. 이 태스크의 전제 조건은 클러스터에 1 CPU 이상 사용 가능해야 한다는 것이다. 각 노드에 1 CPU만 있는 경우, 노드에 할당할 수 있는 CPU가 800 millicpu의 요청량을 수용하기에 충분하지 않을 수 있다. 2 CPU인 노드를 사용하는 경우에는, CPU가 800 millicpu 요청량을 수용하기에 충분할 것이다.
이 시점에서, 파드는 실행 중일 수도 있고 아닐 수도 있다. 이 태스크의 전제 조건은 클러스터에 1 CPU 이상 사용 가능해야 한다는 것이다. 각 노드에 1 CPU만 있는 경우, 노드에 할당할 수 있는 CPU가 800 millicpu의 요청량을 수용하기에 충분하지 않을 수 있다. 2 CPU인 노드를 사용하는 경우에는, CPU가 800 millicpu 요청량을 수용하기에 충분할 것이다.
파드를 삭제한다.
content/ko/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace.md
+55 -32
View File
@@ -2,23 +2,36 @@
title: 네임스페이스에 대한 기본 CPU 요청량과 상한 구성
content_type: task
weight: 20
description: >-
한 네임스페이스에 CPU 리소스 상한의 기본값을 정의하며,
이를 통해 미리 설정한 CPU 리소스 상한이 해당 네임스페이스의 새로운 파드에 설정되도록 한다.
---
<!-- overview -->
이 페이지는 네임스페이스에 대한 기본 CPU 요청량(request) 및 상한(limit)을 구성하는 방법을 보여준다.
쿠버네티스 클러스터는 네임스페이스로 나눌 수 있다. 기본 CPU 상한이 있는 네임스페이스에서
컨테이너가 생성되고, 컨테이너가 자체 CPU 상한을 지정하지 않으면,
컨테이너에 기본 CPU 상한이 할당된다. 쿠버네티스는 이 문서의 뒷부분에서
설명하는 특정 조건에서 기본 CPU 요청량을 할당한다.
이 페이지는 {{< glossary_tooltip text="네임스페이스" term_id="namespace" >}}에 대한
기본 CPU 요청량(request) 및 상한(limit)을 구성하는 방법을 보여준다.
쿠버네티스 클러스터를 여러 네임스페이스로 나눌 수 있다.
기본 CPU [상한](/ko/docs/concepts/configuration/manage-resources-containers/#요청-및-제한)이
설정되어 있는 네임스페이스에 파드를 생성했는데,
해당 파드의 모든 컨테이너에 CPU 상한이 명시되어 있지 않다면,
{{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}이
해당 컨테이너에 기본 CPU 상한을 할당한다.
쿠버네티스는 기본 CPU
[사용량](/ko/docs/concepts/configuration/manage-resources-containers/#요청-및-제한)을 할당하는데,
이는 이 페이지의 이후 부분에서 설명될 특정 조건 하에서만 수행된다.
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
{{< include "task-tutorial-prereqs.md" >}}
클러스터에 네임스페이스를 생성할 수 있는 권한이 있어야 한다.
쿠버네티스에서 “1.0 CPU”가 무엇을 의미하는지 익숙하지 않다면,
[CPU의 의미](/ko/docs/concepts/configuration/manage-resources-containers/#cpu의-의미)를 참조한다.
<!-- steps -->
@@ -33,8 +46,8 @@ kubectl create namespace default-cpu-example
## 리밋레인지(LimitRange)와 파드 생성
다음은 리밋레인지 오브젝트의 구성 파일이다. 구성은
기본 CPU 요청량 및 기본 CPU 상한을 지정한다.
다음은 예시 {{< glossary_tooltip text="리밋레인지" term_id="limitrange" >}}에 대한 매니페스트이다.
이 매니페스트는 기본 CPU 요청량 및 기본 CPU 상한을 지정한다.
{{< codenew file="admin/resource/cpu-defaults.yaml" >}}
@@ -44,13 +57,13 @@ default-cpu-example 네임스페이스에 리밋레인지를 생성한다.
kubectl apply -f https://k8s.io/examples/admin/resource/cpu-defaults.yaml --namespace=default-cpu-example
```
이제 컨테이너가 default-cpu-example 네임스페이스에 생성되고,
컨테이너가 CPU 요청량 및 CPU 상한에 대해 고유한 값을 지정하지 않으면,
컨테이너에 CPU 요청량의 기본값 0.5와 CPU 상한
기본값 1이 부여된다.
이제 파드를 `default-cpu-example` 네임스페이스에 생성하고,
해당 파드의 어떤 컨테이너도 자체 CPU 요청량(request)과 상한(limit)을 명시하지 않으면,
컨트롤 플레인이 해당 컨테이너에 CPU 요청량의 기본값(0.5)과
상한의 기본값(1)을 지정한다.
컨테이너가 하나인 파드의 구성 파일은 다음과 같다. 컨테이너는
CPU 요청량과 상한을 지정하지 않는다.
다음은 컨테이너가 하나인 파드의 매니페스트이다.
해당 컨테이너는 CPU 요청량과 상한을 지정하지 않는다.
{{< codenew file="admin/resource/cpu-defaults-pod.yaml" >}}
@@ -66,8 +79,9 @@ kubectl apply -f https://k8s.io/examples/admin/resource/cpu-defaults-pod.yaml --
kubectl get pod default-cpu-demo --output=yaml --namespace=default-cpu-example
```
출력 결과는 파드의 컨테이너에 500 milicpu의 CPU 요청량과
1 cpu의 CPU 상한이 있음을 나타낸다. 이것은 리밋레인지에 의해 지정된 기본값이다.
출력을 보면 파드 내 유일한 컨테이너의 CPU 요청량이 500m `cpu`("500 밀리cpu"로 읽을 수 있음)이고,
CPU 상한이 1 `cpu`임을 알 수 있다.
이것은 리밋레인지에 의해 지정된 기본값이다.
```shell
containers:
@@ -83,8 +97,8 @@ containers:
## 컨테이너 상한은 지정하고, 요청량을 지정하지 않으면 어떻게 되나?
컨테이너가 하나인 파드의 구성 파일은 다음과 같다. 컨테이너는
CPU 상한을 지정하지만, 요청량은 지정하지 않는다.
다음은 컨테이너가 하나인 파드의 매니페스트이다.
해당 컨테이너는 CPU 상한은 지정하지만, 요청량은 지정하지 않는다.
{{< codenew file="admin/resource/cpu-defaults-pod-2.yaml" >}}
@@ -95,14 +109,15 @@ CPU 상한을 지정하지만, 요청량은 지정하지 않는다.
kubectl apply -f https://k8s.io/examples/admin/resource/cpu-defaults-pod-2.yaml --namespace=default-cpu-example
```
파드 사양을 확인한다.
생성한 파드의
[명세](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/#오브젝트-명세-spec-와-상태-status)를 확인한다.
```
kubectl get pod default-cpu-demo-2 --output=yaml --namespace=default-cpu-example
```
출력 결과는 컨테이너의 CPU 요청량이 CPU 상한과 일치하도록 설정되었음을 보여준다.
참고로 컨테이너에는 CPU 요청량의 기본값인 0.5 cpu가 할당되지 않았다.
참고로 컨테이너에는 CPU 요청량의 기본값인 0.5 `cpu`가 할당되지 않았다.
```
resources:
@@ -114,8 +129,8 @@ resources:
## 컨테이너의 요청량은 지정하고, 상한을 지정하지 않으면 어떻게 되나?
컨테이너가 하나인 파드의 구성 파일은 다음과 같다. 컨테이너는
CPU 요청량을 지정하지만, 상한은 지정하지 않았다.
다음은 컨테이너가 하나인 파드의 예시 매니페스트이다.
해당 컨테이너는 CPU 요청량은 지정하지만, 상한은 지정하지 않는다.
{{< codenew file="admin/resource/cpu-defaults-pod-3.yaml" >}}
@@ -125,15 +140,16 @@ CPU 요청량을 지정하지만, 상한은 지정하지 않았다.
kubectl apply -f https://k8s.io/examples/admin/resource/cpu-defaults-pod-3.yaml --namespace=default-cpu-example
```
파드 사양을 확인한다.
생성한 파드의 명세를 확인한다.
```
kubectl get pod default-cpu-demo-3 --output=yaml --namespace=default-cpu-example
```
출력 결과는 컨테이너의 CPU 요청량이 컨테이너의 구성 파일에 지정된 값으로
설정되었음을 보여준다. 컨테이너의 CPU 상한은 1 cpu로 설정되며, 이는
네임스페이스의 CPU 상한 기본값이다.
출력을 보면 파드 생성 시 명시한 값대로
컨테이너의 CPU 요청량이 설정된 것을 알 수 있다(다시 말해, 매니페스트와 일치한다).
그러나, 해당 컨테이너의 CPU 상한은 1 `cpu`로 설정되며,
이는 네임스페이스의 CPU 상한 기본값이다.
```
resources:
@@ -145,15 +161,22 @@ resources:
## CPU 상한 및 요청량의 기본값에 대한 동기
네임스페이스에 [리소스 쿼터](/ko/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)가 있는 경우,
네임스페이스에 {{< glossary_tooltip text="리소스 쿼터" term_id="resource-quota" >}}가
설정되어 있는 경우,
CPU 상한에 대해 기본값을 설정하는 것이 좋다.
다음은 리소스 쿼터가 네임스페이스에 적용하는 두 가지 제한 사항이다.
다음은 CPU 리소스 쿼터가 네임스페이스에 적용하는 두 가지 제한 사항이다.
* 네임스페이스에서 실행되는 모든 컨테이너에는 자체 CPU 상한이 있어야 한다.
* 네임스페이스의 모든 컨테이너가 사용하는 총 CPU 양은 지정된 상한을 초과하지 않아야 한다.
* 네임스페이스에서 실행되는 모든 파드에 대해, 모든 컨테이너에 CPU 상한이 있어야 한다.
* CPU 상한은 해당 파드가 스케줄링될 노드에 리소스 예약을 적용한다.
해당 네임스페이스의 모든 파드에 대해 예약된 CPU 총량이
지정된 상한을 초과하지 않아야 한다.
리밋레인지를 추가할 때에는 다음을 고려해야 한다.
컨테이너를 갖고 있는 해당 네임스페이스의 파드가 자체 CPU 상한을 지정하지 않았다면,
컨트롤 플레인이 해당 컨테이너에 CPU 상한 기본값을 적용하며,
해당 파드는 CPU 리소스쿼터가 적용된 네임스페이스에서 실행되도록 허용될 수 있다.
컨테이너가 자체 CPU 상한을 지정하지 않으면, 상한 기본값이 부여되고, 쿼터에
의해 제한되는 네임스페이스에서 실행될 수 있다.
## 정리
content/ko/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md
+52 -42
View File
@@ -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로 제한해야 한다. 프로덕션 및 개발을 위해
별도의 네임스페이스를 만들고, 각 네임스페이스에 메모리 제약 조건을 적용한다.
## 정리
content/ko/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md
+48 -24
View File
@@ -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" >}}가
설정되어 있는 경우,
메모리 상한에 기본값을 설정하는 것이 좋다.
다음은 리소스 쿼터가 네임스페이스에 적용하는 두 가지 제한 사항이다.
* 네임스페이스에서 실행되는 모든 컨테이너에는 자체 메모리 상한이 있어야 한다.
* 네임스페이스의 모든 컨테이너가 사용하는 총 메모리 양은 지정된 상한을 초과하지 않아야 한다.
* 네임스페이스에서 실행되는 모든 파드에 대해, 모든 컨테이너에 메모리 상한이 있어야 한다.
(파드의 모든 컨테이너에 대해 메모리 상한을 지정하면,
쿠버네티스가 파드 내의 컨테이너의 상한을 합산하여 파드-수준 메모리 상한을 추론할 수 있다.)
* 메모리 상한은 해당 파드가 스케줄링될 노드에 리소스 예약을 적용한다.
해당 네임스페이스의 모든 파드에 대해 예약된 메모리 총량이 지정된 상한을 초과하지 않아야 한다.
* 해당 네임스페이스의 모든 파드가 실제로 사용하고 있는 메모리의 총량 또한 지정된 상한을 초과하지 않아야 한다.
컨테이너가 자체 메모리 상한을 지정하지 않으면, 기본 상한이 부여되고,
쿼터에 의해 제한되는 네임스페이스에서 실행될 수 있다.
리밋레인지를 추가할 때에는 다음을 고려해야 한다.
컨테이너를 갖고 있는 해당 네임스페이스의 파드가 자체 메모리 상한을 지정하지 않았다면,
컨트롤 플레인이 해당 컨테이너에 메모리 상한 기본값을 적용하며,
해당 파드는 메모리 리소스쿼터가 적용된 네임스페이스에서 실행되도록 허용될 수 있다.
## 정리
content/ko/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace.md
+35 -22
View File
@@ -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/)를 사용한다.
## 정리
content/ko/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace.md
+21 -12
View File
@@ -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" >}}의 총 수를 제한할 수 있다.
## 정리
네임스페이스를 삭제한다.
content/ko/docs/tasks/configure-pod-container/assign-memory-resource.md
+1 -1
View File
@@ -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
content/ko/docs/tasks/configure-pod-container/configure-gmsa.md
+18 -52
View File
@@ -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
```
content/ko/docs/tasks/configure-pod-container/pull-image-private-registry.md
+11 -6
View File
@@ -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` 으로 설정한다
content/ko/docs/tasks/configure-pod-container/static-pod.md
+27 -24
View File
@@ -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
```
content/ko/docs/tasks/debug-application-cluster/get-shell-running-container.md
+1 -2
View File
@@ -154,5 +154,4 @@ kubectl exec -i -t my-pod --container main-app -- /bin/bash
## {{% heading "whatsnext" %}}
* [kubectl
* exec](/docs/reference/generated/kubectl/kubectl-commands/#exec)를참고한다.
* [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec)를 참고한다.
content/ko/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md
+1 -1
View File
@@ -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)에 의해 수집되었다.
content/ko/docs/tasks/inject-data-application/define-command-argument-container.md
-38
View File
@@ -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]` | &lt;설정되지 않음&gt; | &lt;설정되지 않음&gt; | `[ep-1 foo bar]` |
| `[/ep-1]` | `[foo bar]` | `[/ep-2]` | &lt;설정되지 않음&gt; | `[ep-2]` |
| `[/ep-1]` | `[foo bar]` | &lt;설정되지 않음&gt; | `[zoo boo]` | `[ep-1 zoo boo]` |
| `[/ep-1]` | `[foo bar]` | `[/ep-2]` | `[zoo boo]` | `[ep-2 zoo boo]` |
## {{% heading "whatsnext" %}}
content/ko/docs/tasks/job/automated-tasks-with-cron-jobs.md
+1 -1
View File
@@ -127,7 +127,7 @@ kubectl delete cronjob hello
```
크론 잡을 삭제하면 생성된 모든 잡과 파드가 제거되고 추가 잡 생성이 중지된다.
[가비지(garbage) 수집](/ko/docs/concepts/workloads/controllers/garbage-collection/)에서 잡 제거에 대해 상세한 내용을 읽을 수 있다.
[가비지(garbage) 수집](/ko/docs/concepts/architecture/garbage-collection/)에서 잡 제거에 대해 상세한 내용을 읽을 수 있다.
## 크론 잡 명세 작성
content/ko/docs/tasks/manage-daemon/update-daemon-set.md
+2 -2
View File
@@ -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` 업데이트 전략으로 데몬셋 생성
content/ko/docs/tasks/manage-kubernetes-objects/kustomization.md
+15 -6
View File
@@ -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:
content/ko/docs/tasks/network/customize-hosts-file-for-pods.md
+12 -4
View File
@@ -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 >}}
컨테이너 내부의 호스트 파일을 수동으로 변경하면 안된다.
content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md
+5 -4
View File
@@ -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에서 메트릭을 가져온다.
content/ko/docs/tasks/tls/managing-tls-in-a-cluster.md
+131 -28
View File
@@ -9,7 +9,7 @@ content_type: task
<!-- overview -->
쿠버네티스는 사용자가 제어하는 ​​인증 기관 (CA)에서 서명한 TLS 인증서를
쿠버네티스는 사용자가 제어하는 인증 기관 (CA)에서 서명한 TLS 인증서를
프로비저닝 할 수 있는 `certificates.k8s.io` API를 제공한다.
이러한 CA 및 인증서는 워크로드 간의 신뢰 관계를 구성하는 용도로 사용할 수 있다.
@@ -76,16 +76,11 @@ cat <<EOF | cfssl genkey - | cfssljson -bare server
"192.0.2.24",
"10.0.34.2"
],
"CN": "system:node:my-pod.my-namespace.pod.cluster.local",
"CN": "my-pod.my-namespace.pod.cluster.local",
"key": {
"algo": "ecdsa",
"size": 256
},
"names": [
{
"O": "system:nodes"
}
]
}
}
EOF
```
@@ -93,13 +88,13 @@ EOF
여기서 `192.0.2.24`는 서비스의 클러스터 IP,
`my-svc.my-namespace.svc.cluster.local`은 서비스의 DNS 이름,
`10.0.34.2`는 파드의 IP,`my-pod.my-namespace.pod.cluster.local`은
파드의 DNS 이름이다. 다음 출력이 표시되어야 한다.
파드의 DNS 이름이다. 다음과 비슷한 출력이 표시되어야 한다.
```
2017/03/21 06:48:17 [INFO] generate received request
2017/03/21 06:48:17 [INFO] received CSR
2017/03/21 06:48:17 [INFO] generating key: ecdsa-256
2017/03/21 06:48:17 [INFO] encoded CSR
2022/02/01 11:45:32 [INFO] generate received request
2022/02/01 11:45:32 [INFO] received CSR
2022/02/01 11:45:32 [INFO] generating key: ecdsa-256
2022/02/01 11:45:32 [INFO] encoded CSR
```
이 명령은 두 개의 파일을 생성한다. PEM으로
@@ -120,7 +115,7 @@ metadata:
name: my-svc.my-namespace
spec:
request: $(cat server.csr | base64 | tr -d '\n')
signerName: kubernetes.io/kubelet-serving
signerName: example.com/serving
usages:
- digital signature
- key encipherment
@@ -130,7 +125,7 @@ EOF
1단계에서 만든 `server.csr` 파일은 base64로 인코딩되고
`.spec.request` 필드에 숨겨져 있다.
또한 `kubernetes.io/kubelet-serving` 서명자가 서명한
또한 예시 `example.com/serving` 서명자가 서명한
"digitalSignature", "keyEnciperment" 및 "serverAuth" 키 사용(keyUsage)이 있는 인증서를 요청한다.
특정 `signerName`을 요청해야 한다.
자세한 내용은 [지원되는 서명자 이름](/docs/reference/access-authn-authz/certificate-signing-requests/#signers)
@@ -147,14 +142,16 @@ kubectl describe csr my-svc.my-namespace
Name: my-svc.my-namespace
Labels: <none>
Annotations: <none>
CreationTimestamp: Tue, 21 Mar 2017 07:03:51 -0700
CreationTimestamp: Tue, 01 Feb 2022 11:49:15 -0500
Requesting User: yourname@example.com
Signer: example.com/serving
Status: Pending
Subject:
Common Name: my-svc.my-namespace.svc.cluster.local
Common Name: my-pod.my-namespace.pod.cluster.local
Serial Number:
Subject Alternative Names:
DNS Names: my-svc.my-namespace.svc.cluster.local
DNS Names: my-pod.my-namespace.pod.cluster.local
my-svc.my-namespace.svc.cluster.local
IP Addresses: 192.0.2.24
10.0.34.2
Events: <none>
@@ -175,30 +172,136 @@ kubectl certificate approve my-svc.my-namespace
certificatesigningrequest.certificates.k8s.io/my-svc.my-namespace approved
```
## 인증서 다운로드 및 사용
CSR이 서명되고 승인되면 다음이 표시된다.
출력은 다음과 같을 것이다.
```shell
kubectl get csr
```
```none
NAME AGE REQUESTOR CONDITION
my-svc.my-namespace 10m yourname@example.com Approved,Issued
NAME AGE SIGNERNAME REQUESTOR REQUESTEDDURATION CONDITION
my-svc.my-namespace 10m example.com/serving yourname@example.com <none> Approved
```
다음을 실행하여 발급된 인증서를 다운로드하고 `server.crt` 파일에
저장할 수 있다.
이는 즉 인증서 요청이 승인되었으며
요청받은 서명자의 서명을 기다리고 있음을 나타낸다.
## 인증서 서명 요청에 서명하기
다음으로, 인증서 서명자로서, 인증서를 발급하고, 이를 API에 업로드할 것이다.
서명자는 일반적으로 인증서 서명 요청 API를 조회하여 오브젝트의 `signerName`을 확인하고,
요청이 승인되었는지 체크하고, 해당 요청에 대해 인증서에 서명하고,
발급된 인증서로 API 오브젝트 상태를 업데이트한다.
### 인증 기관 생성하기
먼저: 다음을 실행하여 서명 인증서를 생성한다.
```shell
cat <<EOF | cfssl gencert -initca - | cfssljson -bare ca
{
"CN": "My Example Signer",
"key": {
"algo": "rsa",
"size": 2048
}
}
EOF
```
출력은 다음과 같을 것이다.
```none
2022/02/01 11:50:39 [INFO] generating a new CA key and certificate from CSR
2022/02/01 11:50:39 [INFO] generate received request
2022/02/01 11:50:39 [INFO] received CSR
2022/02/01 11:50:39 [INFO] generating key: rsa-2048
2022/02/01 11:50:39 [INFO] encoded CSR
2022/02/01 11:50:39 [INFO] signed certificate with serial number 263983151013686720899716354349605500797834580472
```
이제 인증 기관 키 파일(`ca-key.pem`)과 인증서(`ca.pem`)가 생성되었다.
### 인증서 발급하기
{{< codenew file="tls/server-signing-config.json" >}}
`server-signing-config.json` 서명 구성 파일, 인증 기관 키 파일 및 인증서를 사용하여
인증서 요청에 서명한다.
```shell
kubectl get csr my-svc.my-namespace -o jsonpath='{.spec.request}' | \
base64 --decode | \
cfssl sign -ca ca.pem -ca-key ca-key.pem -config server-signing-config.json - | \
cfssljson -bare ca-signed-server
```
출력은 다음과 같을 것이다.
```
2022/02/01 11:52:26 [INFO] signed certificate with serial number 576048928624926584381415936700914530534472870337
```
이제 서명된 제공(serving) 인증서 파일 `ca-signed-server.pem`이 생성되었다.
### 서명된 인증서 업로드하기
마지막으로, 서명된 인증서를 API 오브젝트의 상태에 기재한다.
```shell
kubectl get csr my-svc.my-namespace -o json | \
jq '.status.certificate = "'$(base64 ca-signed-server.pem | tr -d '\n')'"' | \
kubectl replace --raw /apis/certificates.k8s.io/v1/certificatesigningrequests/my-svc.my-namespace/status -f -
```
{{< note >}}
위의 명령에서 `.status.certificate` 필드에 base64로 인코딩된 내용을 채우기 위해 [jq](https://stedolan.github.io/jq/) 명령줄 도구를 사용하였다.
`jq`가 없다면, JSON 출력을 파일에 저장하고, 해당 필드를 수동으로 채우고, 그 결과 파일을 업로드할 수도 있다.
{{< /note >}}
인증서 서명 요청이 승인되고 서명된 인증서가 업로드되면 다음과 같은 출력을 볼 수 있을 것이다.
```shell
kubectl get csr
```
```none
NAME AGE SIGNERNAME REQUESTOR REQUESTEDDURATION CONDITION
my-svc.my-namespace 20m example.com/serving yourname@example.com <none> Approved,Issued
```
## 인증서 다운로드 및 사용
이제, 요청하는 사용자로서, 다음 명령을 실행하여
발급된 인증서를 다운로드하고 `server.crt` 파일에 저장할 수 있다.
```shell
kubectl get csr my-svc.my-namespace -o jsonpath='{.status.certificate}' \
| base64 --decode > server.crt
```
이제 `server.crt` 및 `server-key.pem`을 키페어(keypair)로 사용하여
HTTPS 서버를 시작할 수 있다.
이제 `server.crt` 및 `server-key.pem`의 내용으로 시크릿을 생성하고 파드에 마운트하여
HTTPS 서버를 시작하는 데 필요한 키페어로 사용할 수 있다.
```shell
kubectl create secret tls server --cert server.crt --key server-key.pem
```
```none
secret/server created
```
마지막으로, `ca.pem`의 내용으로 컨피그맵을 생성하여
제공(serving) 인증서 검증에 필요한 신뢰 루트로 사용할 수 있다.
```shell
kubectl create configmap example-serving-ca --from-file ca.crt=ca.pem
```
```none
configmap/example-serving-ca created
```
## 인증서 서명 요청 승인
content/ko/docs/tasks/tools/included/optional-kubectl-configs-bash-linux.md
+10 -11
View File
@@ -26,19 +26,18 @@ source /usr/share/bash-completion/bash_completion
### kubectl 자동 완성 활성화
#### Bash
이제 kubectl 자동 완성 스크립트가 모든 셸 세션에서 제공되도록 해야 한다. 이를 수행할 수 있는 두 가지 방법이 있다.
- `~/.bashrc` 파일에서 자동 완성 스크립트를 소싱한다.
```bash
echo 'source <(kubectl completion bash)' >>~/.bashrc
```
- 자동 완성 스크립트를 `/etc/bash_completion.d` 디렉터리에 추가한다.
```bash
kubectl completion bash >/etc/bash_completion.d/kubectl
```
{{< tabs name="kubectl_bash_autocompletion" >}}
{{{< tab name="현재 사용자에만 적용" codelang="bash" >}}
echo 'source <(kubectl completion bash)' >>~/.bashrc
{{< /tab >}}
{{< tab name="시스템 전체에 적용" codelang="bash" >}}
kubectl completion bash | sudo tee /etc/bash_completion.d/kubectl > /dev/null
{{< /tab >}}}
{{< /tabs >}}
kubectl에 대한 앨리어스(alias)가 있는 경우, 해당 앨리어스로 작업하도록 셸 자동 완성을 확장할 수 있다.
content/ko/docs/tasks/tools/included/optional-kubectl-configs-fish.md
+15
View File
@@ -0,0 +1,15 @@
---
title: "fish auto-completion"
description: "fish 자동 완성을 활성화하기 위한 선택적 구성"
headless: true
---
Fish용 kubectl 자동 완성 스크립트는 `kubectl completion fish` 명령으로 생성할 수 있다. 셸에서 자동 완성 스크립트를 소싱하면 kubectl 자동 완성 기능이 활성화된다.
모든 셸 세션에서 사용하려면, `~/.config/fish/config.fish` 파일에 다음을 추가한다.
```shell
kubectl completion fish | source
```
셸을 다시 로드하면, kubectl 자동 완성 기능이 작동할 것이다.
content/ko/docs/tasks/tools/install-kubectl-linux.md
+5 -4
View File
@@ -52,7 +52,7 @@ card:
kubectl 바이너리를 체크섬 파일을 통해 검증한다.
```bash
echo "$(<kubectl.sha256) kubectl" | sha256sum --check
echo "$(<kubectl.sha256) kubectl" | sha256sum --check
```
검증이 성공한다면, 출력은 다음과 같다.
@@ -85,7 +85,7 @@ card:
chmod +x kubectl
mkdir -p ~/.local/bin/kubectl
mv ./kubectl ~/.local/bin/kubectl
# 그리고 ~/.local/bin/kubectl을 $PATH에 추가
# 그리고 ~/.local/bin 을 $PATH의 앞부분 또는 뒷부분에 추가
```
{{< /note >}}
@@ -178,10 +178,11 @@ kubectl version --client
kubectl은 Bash, Zsh, Fish, 및 PowerShell에 대한 자동 완성 지원을 제공하므로 입력을 위한 타이핑을 많이 절약할 수 있다.
다음은 Bash 및 Zsh에 대한 자동 완성을 설정하는 절차이다.
다음은 Bash, Fish, 및 Zsh에 대한 자동 완성을 설정하는 절차이다.
{{< tabs name="kubectl_autocompletion" >}}
{{< tab name="Bash" include="included/optional-kubectl-configs-bash-linux.md" />}}
{{< tab name="Fish" include="included/optional-kubectl-configs-fish.md" />}}
{{< tab name="Zsh" include="included/optional-kubectl-configs-zsh.md" />}}
{{< /tabs >}}
@@ -192,7 +193,7 @@ kubectl은 Bash, Zsh, Fish, 및 PowerShell에 대한 자동 완성 지원을 제
1. 다음 명령으로 최신 릴리스를 다운로드한다.
```bash
curl -LO https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl-convert
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl-convert"
```
1. 바이너리를 검증한다. (선택 사항)
content/ko/docs/tasks/tools/install-kubectl-macos.md
+2 -1
View File
@@ -161,10 +161,11 @@ macOS에서 [Macports](https://macports.org/) 패키지 관리자를 사용하
kubectl은 Bash, Zsh, Fish, 및 PowerShell에 대한 자동 완성 지원을 제공하므로 입력을 위한 타이핑을 많이 절약할 수 있다.
다음은 Bash 및 Zsh에 대한 자동 완성을 설정하는 절차이다.
다음은 Bash, Fish, 및 Zsh에 대한 자동 완성을 설정하는 절차이다.
{{< tabs name="kubectl_autocompletion" >}}
{{< tab name="Bash" include="included/optional-kubectl-configs-bash-mac.md" />}}
{{< tab name="Fish" include="included/optional-kubectl-configs-fish.md" />}}
{{< tab name="Zsh" include="included/optional-kubectl-configs-zsh.md" />}}
{{< /tabs >}}
content/ko/docs/tasks/tools/install-kubectl-windows.md
+2 -2
View File
@@ -59,7 +59,7 @@ card:
$($(CertUtil -hashfile .\kubectl.exe SHA256)[1] -replace " ", "") -eq $(type .\kubectl.exe.sha256)
```
1. `PATH`로 설정된 디렉터리 중 하나에 kubectl 바이너리를 추가한다.
1. kubectl 바이너리가 있는 폴더를 `PATH` 환경 변수의 앞부분 또는 뒷부분에 추가
1. `kubectl` 의 버전이 다운로드한 버전과 같은지 확인한다.
@@ -172,7 +172,7 @@ kubectl은 Bash, Zsh, Fish, 및 PowerShell에 대한 자동 완성 지원을 제
$($(CertUtil -hashfile .\kubectl-convert.exe SHA256)[1] -replace " ", "") -eq $(type .\kubectl-convert.exe.sha256)
```
1. `PATH`로 설정된 디렉터리 중 하나에 kubectl-convert 바이너리를 추가한다.
1. kubectl 바이너리가 있는 폴더를 `PATH` 환경 변수의 앞부분 또는 뒷부분에 추가
1. 플러그인이 정상적으로 설치되었는지 확인한다.