[ko] Update outdated files in dev-1.24-ko.1 M115-M138
This commit is contained in:
Jihoon Seo
+64
-50
@@ -6,19 +6,15 @@ weight: 40
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
본 페이지는 파드가 DownwardAPIVolumeFile을 사용하여 파드에서 실행되는 컨테이너에
|
||||
자신에 대한 정보를 노출하는 방법에 대해 설명한다. DownwardAPIVolumeFile은 파드 필드와
|
||||
컨테이너 필드를 노출할 수 있다.
|
||||
|
||||
|
||||
본 페이지는 파드가
|
||||
[`DownwardAPIVolumeFile`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#downwardapivolumefile-v1-core)을 사용하여
|
||||
파드에서 실행되는 컨테이너에 자신에 대한 정보를 노출하는 방법에 대해 설명한다.
|
||||
`DownwardAPIVolumeFile`은 파드 필드와 컨테이너 필드를 노출할 수 있다.
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## 다운워드(Downward) API
|
||||
@@ -28,7 +24,8 @@ weight: 40
|
||||
* [환경 변수](/ko/docs/tasks/inject-data-application/environment-variable-expose-pod-information/#다운워드-downward-api)
|
||||
* 볼륨 파일
|
||||
|
||||
파드 및 컨테이너 필드를 노출하는 이 두 가지 방법을 *다운워드 API*라고 한다.
|
||||
파드 및 컨테이너 필드를 노출하는 이 두 가지 방법을
|
||||
"다운워드 API"라고 한다.
|
||||
|
||||
## 파드 필드 저장
|
||||
|
||||
@@ -42,11 +39,14 @@ weight: 40
|
||||
|
||||
`downwardAPI` 아래의 배열을 살펴보자. 배열의 각 요소는
|
||||
[DownwardAPIVolumeFile](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#downwardapivolumefile-v1-core)이다.
|
||||
첫 번째 요소는 파드의 `metadata.labels` 필드 값이 `labels`라는 파일에 저장되어야 함을 지정한다.
|
||||
두 번째 요소는 파드의 `annotations` 필드 값이 `annotations`라는 파일에 저장되어야 함을 지정한다.
|
||||
첫 번째 요소는 파드의 `metadata.labels` 필드 값이
|
||||
`labels`라는 파일에 저장되어야 함을 지정한다.
|
||||
두 번째 요소는 파드의 `annotations` 필드 값이
|
||||
`annotations`라는 파일에 저장되어야 함을 지정한다.
|
||||
|
||||
{{< note >}}
|
||||
이 예제의 필드는 파드에 있는 컨테이너의 필드가 아니라 파드 필드이다.
|
||||
이 예제의 필드는 파드에 있는 컨테이너의 필드가 아니라
|
||||
파드 필드이다.
|
||||
{{< /note >}}
|
||||
|
||||
파드를 생성한다.
|
||||
@@ -78,7 +78,7 @@ build="two"
|
||||
builder="john-doe"
|
||||
```
|
||||
|
||||
파드에서 실행 중인 컨테이너의 셸을 가져오자.
|
||||
파드에서 실행 중인 컨테이너의 셸을 가져온다.
|
||||
|
||||
```shell
|
||||
kubectl exec -it kubernetes-downwardapi-volume-example -- sh
|
||||
@@ -90,7 +90,8 @@ kubectl exec -it kubernetes-downwardapi-volume-example -- sh
|
||||
/# cat /etc/podinfo/labels
|
||||
```
|
||||
|
||||
출력을 통해 모든 파드의 레이블이 `labels` 파일에 기록되었음을 확인할 수 있다.
|
||||
출력을 통해 모든 파드의 레이블이
|
||||
`labels` 파일에 기록되었음을 확인할 수 있다.
|
||||
|
||||
```shell
|
||||
cluster="test-cluster1"
|
||||
@@ -130,12 +131,12 @@ total 8
|
||||
|
||||
심볼릭 링크를 사용하면 메타데이터의 동적(dynamic) 원자적(atomic) 갱신이 가능하다.
|
||||
업데이트는 새 임시 디렉터리에 기록되고, `..data` 심볼릭 링크는
|
||||
[rename(2)](http://man7.org/linux/man-pages/man2/rename.2.html)을 사용하여
|
||||
원자적(atomic)으로 갱신한다.
|
||||
[rename(2)](http://man7.org/linux/man-pages/man2/rename.2.html)을 사용하여 원자적(atomic)으로 갱신한다.
|
||||
|
||||
{{< note >}}
|
||||
다운워드 API를 [subPath](/ko/docs/concepts/storage/volumes/#using-subpath)
|
||||
볼륨 마운트로 사용하는 컨테이너는 다운워드 API 업데이트를 수신하지 않는다.
|
||||
볼륨 마운트로 사용하는 컨테이너는
|
||||
다운워드 API 업데이트를 수신하지 않는다.
|
||||
{{< /note >}}
|
||||
|
||||
셸을 종료한다.
|
||||
@@ -146,15 +147,19 @@ total 8
|
||||
|
||||
## 컨테이너 필드 저장
|
||||
|
||||
이전 연습에서는 파드 필드를 DownwardAPIVolumeFile에 저장하였다.
|
||||
이 다음 연습에서는 컨테이너 필드를 저장한다. 다음은 하나의 컨테이너를 가진 파드의 구성 파일이다.
|
||||
이전 연습에서는 파드 필드를
|
||||
[`DownwardAPIVolumeFile`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#downwardapivolumefile-v1-core)에 저장하였다.
|
||||
이 다음 연습에서는 컨테이너 필드를 저장한다.
|
||||
다음은 하나의 컨테이너를 가진 파드의 구성 파일이다.
|
||||
|
||||
{{< codenew file="pods/inject/dapi-volume-resources.yaml" >}}
|
||||
|
||||
구성 파일에서 파드에 `downwardAPI` 볼륨이 있고 컨테이너는 `/etc/podinfo`에 볼륨을
|
||||
마운트하는 것을 확인할 수 있다.
|
||||
구성 파일에서 파드에 [`downwardAPI` 볼륨](/ko/docs/concepts/storage/volumes/#downwardapi)이 있고
|
||||
컨테이너는 `/etc/podinfo`에
|
||||
볼륨을 마운트하는 것을 확인할 수 있다.
|
||||
|
||||
`downwardAPI` 아래의 `items` 배열을 살펴보자. 배열의 각 요소는 DownwardAPIVolumeFile이다.
|
||||
`downwardAPI` 아래의 `items` 배열을 살펴보자. 배열의 각 요소는
|
||||
[`DownwardAPIVolumeFile`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#downwardapivolumefile-v1-core)이다.
|
||||
|
||||
첫 번째 요소는 `client-container`라는 컨테이너에서
|
||||
`1m`으로 지정된 형식의 `limits.cpu` 필드 값이
|
||||
@@ -178,45 +183,56 @@ kubectl exec -it kubernetes-downwardapi-volume-example-2 -- sh
|
||||
```shell
|
||||
/# cat /etc/podinfo/cpu_limit
|
||||
```
|
||||
|
||||
비슷한 명령을 통해 `cpu_request`, `mem_limit` 및
|
||||
`mem_request` 파일을 확인할 수 있다.
|
||||
|
||||
|
||||
|
||||
<!-- discussion -->
|
||||
|
||||
<!-- TODO: This section should be extracted out of the task page. -->
|
||||
## 다운워드 API의 기능
|
||||
|
||||
다음 정보는 환경 변수 및 `downwardAPI` 볼륨을 통해 컨테이너에서 사용할 수 있다.
|
||||
다음 정보는 환경 변수 및 `downwardAPI` 볼륨을 통해
|
||||
컨테이너에서 사용할 수 있다.
|
||||
|
||||
* `fieldRef`를 통해 다음 정보를 사용할 수 있다.
|
||||
|
||||
* `metadata.name` - 파드의 이름
|
||||
* `metadata.namespace` - 파드의 네임스페이스(Namespace)
|
||||
* `metadata.uid` - 파드의 UID
|
||||
* `metadata.labels['<KEY>']` - 파드의 레이블 `<KEY>` 값 (예를 들어, `metadata.labels['mylabel']`)
|
||||
* `metadata.annotations['<KEY>']` - 파드의 어노테이션 `<KEY>` 값 (예를 들어, `metadata.annotations['myannotation']`)
|
||||
* `metadata.labels['<KEY>']` - 파드의 레이블 `<KEY>` 값
|
||||
(예를 들어, `metadata.labels['mylabel']`)
|
||||
* `metadata.annotations['<KEY>']` - 파드의 어노테이션 `<KEY>` 값
|
||||
(예를 들어, `metadata.annotations['myannotation']`)
|
||||
|
||||
* `resourceFieldRef`를 통해 다음 정보를 사용할 수 있다.
|
||||
|
||||
* 컨테이너의 CPU 한도(limit)
|
||||
* 컨테이너의 CPU 요청(request)
|
||||
* 컨테이너의 메모리 한도(limit)
|
||||
* 컨테이너의 메모리 요청(request)
|
||||
* 컨테이너의 hugepages 한도(limit) (`DownwardAPIHugePages` [기능 게이트(feature gate)](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화된 경우)
|
||||
* 컨테이너의 hugepages 요청(request) (`DownwardAPIHugePages` [기능 게이트(feature gate)](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화된 경우)
|
||||
* 컨테이너의 hugepages 한도(limit) (`DownwardAPIHugePages`
|
||||
[기능 게이트(feature gate)](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화된 경우)
|
||||
* 컨테이너의 hugepages 요청(request) (`DownwardAPIHugePages`
|
||||
[기능 게이트(feature gate)](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화된 경우)
|
||||
* 컨테이너의 임시-스토리지 한도(limit)
|
||||
* 컨테이너의 임시-스토리지 요청(request)
|
||||
|
||||
`downwardAPI` 볼륨 `fieldRef`를 통해 다음 정보를 사용할 수 있다.
|
||||
`downwardAPI` 볼륨 `fieldRef`를 통해
|
||||
다음 정보를 사용할 수 있다.
|
||||
|
||||
* `metadata.labels` - 한 줄에 하나의 레이블이 있는
|
||||
`label-key="escaped-label-value"` 형식의 모든 파드 레이블
|
||||
* `metadata.annotations` - 한 줄에 하나의 어노테이션이 있는 `annotation-key="escaped-annotation-value"` 형식의 모든 파드 어노테이션
|
||||
`label-key="escaped-label-value"` 형식의 모든 파드 레이블
|
||||
* `metadata.annotations` - 한 줄에 하나의 어노테이션이 있는
|
||||
`annotation-key="escaped-annotation-value"` 형식의 모든 파드 어노테이션
|
||||
|
||||
환경 변수를 통해 다음 정보를 사용할 수 있다.
|
||||
|
||||
* `status.podIP` - 파드의 IP 주소
|
||||
* `spec.serviceAccountName` - 파드의 서비스 계정 이름, v1.4.0-alpha.3부터 사용 가능
|
||||
* `spec.nodeName` - 노드의 이름, v1.4.0-alpha.3부터 사용 가능
|
||||
* `status.hostIP` - 노드의 IP, v1.7.0-alpha.1 이후 사용 가능
|
||||
* `spec.serviceAccountName` - 파드의 서비스 계정 이름
|
||||
* `spec.nodeName` - 스케줄러가 항상 파드를 스케줄링하려고 시도할
|
||||
노드의 이름
|
||||
* `status.hostIP` - 파드가 할당될 노드의 IP 주소
|
||||
|
||||
{{< note >}}
|
||||
컨테이너에 대해 CPU 및 메모리 한도(limit)가 지정되지 않은 경우 다운워드 API는 기본적으로
|
||||
@@ -231,7 +247,8 @@ CPU 및 메모리에 대해 할당 가능한 노드 값으로 설정한다.
|
||||
|
||||
## 다운워드 API에 대한 동기
|
||||
|
||||
컨테이너가 쿠버네티스에 과도하게 결합되지 않고 자체에 대한 정보를 갖는 것이 때때로 유용하다.
|
||||
컨테이너가 쿠버네티스에 과도하게 결합되지 않고
|
||||
자체에 대한 정보를 갖는 것이 때때로 유용하다.
|
||||
다운워드 API를 사용하면 컨테이너가 쿠버네티스 클라이언트 또는 API 서버를 사용하지 않고
|
||||
자체 또는 클러스터에 대한 정보를 사용할 수 있다.
|
||||
|
||||
@@ -241,19 +258,16 @@ CPU 및 메모리에 대해 할당 가능한 노드 값으로 설정한다.
|
||||
더 나은 옵션은 파드의 이름을 식별자로 사용하고
|
||||
파드의 이름을 잘 알려진 환경 변수에 삽입하는 것이다.
|
||||
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)
|
||||
* [볼륨](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volume-v1-core)
|
||||
* [DownwardAPIVolumeSource](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#downwardapivolumesource-v1-core)
|
||||
* [DownwardAPIVolumeFile](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#downwardapivolumefile-v1-core)
|
||||
* [ResourceFieldSelector](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcefieldselector-v1-core)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
* 파드의 목표 상태(desired state)를 정의하는
|
||||
[`PodSpec`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core) API 정의를 확인한다.
|
||||
* 컨테이너가 접근할 파드 내의 일반 볼륨을 정의하는
|
||||
[`Volume`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volume-v1-core) API 정의를 확인한다.
|
||||
* 다운워드 API 정보를 포함하는 볼륨을 정의하는
|
||||
[`DownwardAPIVolumeSource`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#downwardapivolumesource-v1-core) API 정의를 확인한다.
|
||||
* 다운워드 API 볼륨 내 파일을 채우기 위한
|
||||
오브젝트 또는 리소스 필드로의 레퍼런스를 포함하는
|
||||
[`DownwardAPIVolumeFile`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#downwardapivolumefile-v1-core) API 정의를 확인한다.
|
||||
* 컨테이너 리소스 및 이들의 출력 형식을 지정하는
|
||||
[`ResourceFieldSelector`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcefieldselector-v1-core) API 정의를 확인한다.
|
||||
|
||||
@@ -201,7 +201,7 @@ spec:
|
||||
spec:
|
||||
containers:
|
||||
- name: c
|
||||
image: busybox
|
||||
image: busybox:1.28
|
||||
command: ["sh", "-c", "echo Processing URL {{ url }} && sleep 5"]
|
||||
restartPolicy: Never
|
||||
{% endfor %}
|
||||
|
||||
@@ -34,9 +34,9 @@ weight: 10
|
||||
데몬셋의 롤링 업데이트 기능을 사용하려면,
|
||||
`.spec.updateStrategy.type` 에 `RollingUpdate` 를 설정해야 한다.
|
||||
|
||||
[`.spec.updateStrategy.rollingUpdate.maxUnavailable`](/ko/docs/concepts/workloads/controllers/deployment/#최대-불가max-unavailable)
|
||||
[`.spec.updateStrategy.rollingUpdate.maxUnavailable`](/docs/reference/kubernetes-api/workload-resources/daemon-set-v1/#DaemonSetSpec)
|
||||
(기본값은 1),
|
||||
[`.spec.minReadySeconds`](/ko/docs/concepts/workloads/controllers/deployment/#최소-대기-시간초)
|
||||
[`.spec.minReadySeconds`](/docs/reference/kubernetes-api/workload-resources/daemon-set-v1/#DaemonSetSpec)
|
||||
(기본값은 0),
|
||||
[`.spec.updateStrategy.rollingUpdate.maxSurge`](/docs/reference/kubernetes-api/workload-resources/daemon-set-v1/#DaemonSetSpec)
|
||||
(베타 기능, 기본값은 0)를
|
||||
|
||||
@@ -16,7 +16,7 @@ content_type: task
|
||||
|
||||
|
||||
* 이중 스택 네트워킹을 위한 제공자 지원 (클라우드 제공자 또는 기타 제공자들은 라우팅 가능한 IPv4/IPv6 네트워크 인터페이스를 제공하는 쿠버네티스 노드들을 제공해야 한다.)
|
||||
* 이중 스택을 지원하는 [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) (예: Calico, Cilium 또는 Kubenet)
|
||||
* 이중 스택 네트워킹을 지원하는 [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
|
||||
* [이중 스택 활성화](/ko/docs/concepts/services-networking/dual-stack/) 클러스터
|
||||
|
||||
{{< version-check >}}
|
||||
|
||||
@@ -47,10 +47,11 @@ weight: 120
|
||||
호스트 이름을 사용하여 API 서버를 쿼리할 수 있다. 공식 클라이언트 라이브러리는
|
||||
이를 자동으로 수행한다.
|
||||
|
||||
API 서버를 인증하는 권장 방법은 [서비스 어카운트](/docs/tasks/configure-pod-container/configure-service-account/)
|
||||
자격 증명을 사용하는 것이다. 기본적으로, 파드는
|
||||
서비스 어카운트와 연결되어 있으며, 해당 서비스 어카운트에 대한 자격 증명(토큰)은
|
||||
해당 파드에 있는 각 컨테이너의 파일시스템 트리의
|
||||
API 서버를 인증하는 권장 방법은
|
||||
[서비스 어카운트](/docs/tasks/configure-pod-container/configure-service-account/) 자격 증명을 사용하는 것이다.
|
||||
기본적으로, 파드는 서비스 어카운트와 연결되어 있으며,
|
||||
해당 서비스 어카운트에 대한 자격 증명(토큰)은
|
||||
해당 파드에 있는 각 컨테이너의 파일시스템 트리의
|
||||
`/var/run/secrets/kubernetes.io/serviceaccount/token` 에 있다.
|
||||
|
||||
사용 가능한 경우, 인증서 번들은 각 컨테이너의
|
||||
|
||||
@@ -152,7 +152,7 @@ php-apache Deployment/php-apache/scale 0% / 50% 1 10 1
|
||||
```shell
|
||||
# 부하 생성을 유지하면서 나머지 스텝을 수행할 수 있도록,
|
||||
# 다음의 명령을 별도의 터미널에서 실행한다.
|
||||
kubectl run -i --tty load-generator --rm --image=busybox --restart=Never -- /bin/sh -c "while sleep 0.01; do wget -q -O- http://php-apache; done"
|
||||
kubectl run -i --tty load-generator --rm --image=busybox:1.28 --restart=Never -- /bin/sh -c "while sleep 0.01; do wget -q -O- http://php-apache; done"
|
||||
```
|
||||
|
||||
이제 아래 명령을 실행한다.
|
||||
@@ -321,7 +321,7 @@ object:
|
||||
metric:
|
||||
name: requests-per-second
|
||||
describedObject:
|
||||
apiVersion: networking.k8s.io/v1beta1
|
||||
apiVersion: networking.k8s.io/v1
|
||||
kind: Ingress
|
||||
name: main-route
|
||||
target:
|
||||
@@ -367,7 +367,7 @@ spec:
|
||||
metric:
|
||||
name: requests-per-second
|
||||
describedObject:
|
||||
apiVersion: networking.k8s.io/v1beta1
|
||||
apiVersion: networking.k8s.io/v1
|
||||
kind: Ingress
|
||||
name: main-route
|
||||
target:
|
||||
@@ -390,7 +390,7 @@ status:
|
||||
metric:
|
||||
name: requests-per-second
|
||||
describedObject:
|
||||
apiVersion: networking.k8s.io/v1beta1
|
||||
apiVersion: networking.k8s.io/v1
|
||||
kind: Ingress
|
||||
name: main-route
|
||||
current:
|
||||
|
||||
@@ -329,7 +329,7 @@ API에 접속하려면 클러스터 관리자는 다음을 확인해야 한다.
|
||||
* 해당 API 등록:
|
||||
|
||||
* 리소스 메트릭의 경우, 일반적으로 이것은 [메트릭-서버](https://github.com/kubernetes-sigs/metrics-server)가 제공하는 `metrics.k8s.io` API이다.
|
||||
클러스터 애드온으로 시작할 수 있다.
|
||||
클러스터 애드온으로 실행할 수 있다.
|
||||
|
||||
* 사용자 정의 메트릭의 경우, 이것은 `custom.metrics.k8s.io` API이다. 메트릭 솔루션 공급 업체에서 제공하는 "어댑터" API 서버에서 제공한다.
|
||||
사용 가능한 쿠버네티스 메트릭 어댑터가 있는지 확인하려면 사용하고자 하는 메트릭 파이프라인을 확인한다.
|
||||
@@ -337,9 +337,9 @@ API에 접속하려면 클러스터 관리자는 다음을 확인해야 한다.
|
||||
* 외부 메트릭의 경우, 이것은 `external.metrics.k8s.io` API이다. 위에 제공된 사용자 정의 메트릭 어댑터에서 제공될 수 있다.
|
||||
|
||||
이런 다양한 메트릭 경로와 각각의 다른 점에 대한 상세 내용은 관련 디자인 제안서인
|
||||
[HPA V2](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/autoscaling/hpa-v2.md),
|
||||
[custom.metrics.k8s.io](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/custom-metrics-api.md),
|
||||
[external.metrics.k8s.io](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/external-metrics-api.md)를 참조한다.
|
||||
[HPA V2](https://github.com/kubernetes/design-proposals-archive/blob/main/autoscaling/hpa-v2.md),
|
||||
[custom.metrics.k8s.io](https://github.com/kubernetes/design-proposals-archive/blob/main/instrumentation/custom-metrics-api.md),
|
||||
[external.metrics.k8s.io](https://github.com/kubernetes/design-proposals-archive/blob/main/instrumentation/external-metrics-api.md)를 참조한다.
|
||||
|
||||
어떻게 사용하는지에 대한 예시는 [커스텀 메트릭 사용하는 작업 과정](/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#다양한-메트릭-및-사용자-정의-메트릭을-기초로한-오토스케일링)과
|
||||
[외부 메트릭스 사용하는 작업 과정](/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#쿠버네티스-오브젝트와-관련이-없는-메트릭을-기초로한-오토스케일링)을 참조한다.
|
||||
@@ -514,7 +514,7 @@ Horizontal Pod Autoscaler는 모든 API 리소스와 마찬가지로 `kubectl`
|
||||
|
||||
또한 Horizontal Pod Autoscaler를 생성할 수 있는 `kubectl autoscale`이라는 특별한 명령이 있다.
|
||||
예를 들어 `kubectl autoscale rs foo --min=2 --max=5 --cpu-percent=80`을
|
||||
실행하면 레플리케이션 셋 *foo* 에 대한 오토스케일러가 생성되고, 목표 CPU 사용률은 `80 %`,
|
||||
실행하면 레플리카셋 *foo* 에 대한 오토스케일러가 생성되고, 목표 CPU 사용률은 `80 %`,
|
||||
그리고 2와 5 사이의 레플리카 개수로 설정된다.
|
||||
|
||||
## 암시적 유지 관리 모드 비활성화
|
||||
|
||||
@@ -17,7 +17,7 @@ content_type: task
|
||||
유사한 프로토콜을 사용한다.
|
||||
|
||||
{{< note >}}
|
||||
`certificates.k8s.io` API를 사용하여 생성된 인증서는 전용 CA로 서명된다.
|
||||
`certificates.k8s.io` API를 사용하여 생성된 인증서는 [전용 CA](#a-note-to-cluster-administrators)로 서명된다.
|
||||
이러한 목적을 위해 클러스터 루트 CA를 사용하도록 클러스터를
|
||||
구성할 수 있지만, 절대 이에 의존해서는 안된다.
|
||||
해당 인증서가 클러스터 루트 CA에 대해 유효성을 검사한다고 가정하면 안된다.
|
||||
@@ -29,24 +29,38 @@ content_type: task
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
{{< include "task-tutorial-prereqs.md" >}}
|
||||
|
||||
`cfssl` 도구가 필요하다.
|
||||
[https://github.com/cloudflare/cfssl/releases](https://github.com/cloudflare/cfssl/releases)에서 `cfssl`을 다운로드할 수 있다.
|
||||
|
||||
이 페이지의 일부 단계에서 `jq` 도구를 사용한다.
|
||||
`jq`가 없다면, 사용 중인 운영 체제의 소프트웨어 소스를 통해 설치하거나,
|
||||
[https://stedolan.github.io/jq/](https://stedolan.github.io/jq/)에서 받을 수 있다.
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## 클러스터에서 TLS 신뢰
|
||||
|
||||
파드로 실행되는 애플리케이션에서 사용자 정의 CA를 신뢰하려면
|
||||
파드로 실행되는 애플리케이션에서 [사용자 정의 CA](#a-note-to-cluster-administrators)를 신뢰하려면
|
||||
일반적으로 몇 가지 추가 애플리케이션 구성이 필요하다.
|
||||
TLS 클라이언트 또는 서버가 신뢰하는 CA 인증서 목록에
|
||||
CA 인증서 번들을 추가해야 한다.
|
||||
예를 들어 인증서 체인을 파싱하고, 파싱된 인증서를 [`tls.Config`](https://godoc.org/crypto/tls#Config) 구조체의
|
||||
예를 들어 인증서 체인을 파싱하고, 파싱된 인증서를 [`tls.Config`](https://pkg.go.dev/crypto/tls#Config) 구조체의
|
||||
`RootCAs` 필드에 추가하여, golang TLS 구성으로 이를 수행할 수 있다.
|
||||
|
||||
CA 인증서를 파드에서 사용할 수 있는
|
||||
[ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap)으로
|
||||
배포할 수 있다.
|
||||
{{< note >}}
|
||||
사용자 정의 CA 인증서가
|
||||
파일시스템(`kube-root-ca.crt` 컨피그맵 내)에 포함될 수 있더라도,
|
||||
이 인증서 권한을 내부 쿠버네티스 엔드포인트 검증 용도 외에는 사용하지 말아야 한다.
|
||||
내부 쿠버네티스 엔드포인트에 대한 하나의 예시는
|
||||
기본 네임스페이스에 있는 `kubernetes`라는 서비스이다.
|
||||
|
||||
당신의 워크로드를 위한 사용자 정의 인증서 권한을 사용하고 싶다면,
|
||||
이 CA를 별도로 생성하고, 파드가 읽을 수 있는
|
||||
[컨피그맵](/docs/tasks/configure-pod-container/configure-pod-configmap/) 형태로
|
||||
해당 CA 인증서를 배포해야 한다.
|
||||
{{< /note >}}
|
||||
|
||||
## 인증서 요청
|
||||
|
||||
@@ -57,11 +71,6 @@ TLS 인증서를 생성하는 방법을 보여준다.
|
||||
이 튜토리얼에서는 CFSSL을 사용한다. [여기를 클릭](https://blog.cloudflare.com/introducing-cfssl/)하여 Cloudflare의 PKI 및 TLS 툴킷을 자세히 알아본다.
|
||||
{{< /note >}}
|
||||
|
||||
## CFSSL 다운로드 및 설치
|
||||
|
||||
이 예제에 사용된 cfssl 도구는
|
||||
[https://github.com/cloudflare/cfssl/releases](https://github.com/cloudflare/cfssl/releases)에서 다운로드 할 수 있다.
|
||||
|
||||
## 인증서 서명 요청 (CSR) 생성
|
||||
|
||||
다음 명령을 실행하여 개인 키 및 인증서 서명 요청(또는 CSR)을
|
||||
@@ -98,14 +107,14 @@ EOF
|
||||
```
|
||||
|
||||
이 명령은 두 개의 파일을 생성한다. PEM으로
|
||||
인코딩된 [pkcs#10](https://tools.ietf.org/html/rfc2986)
|
||||
인코딩된 [PKCS#10](https://tools.ietf.org/html/rfc2986)
|
||||
인증 요청이 포함된 `server.csr`과 생성할 인증서 키를 PEM 인코딩한 값이
|
||||
포함된 `server-key.pem`을 생성한다.
|
||||
|
||||
## 쿠버네티스 API로 보낼 인증서 서명 요청 객체 만들기
|
||||
|
||||
CSR yaml blob을 생성하고 다음 명령을 실행하여
|
||||
apiserver로 보낸다.
|
||||
CSR 매니페스트(YAML 형태)를 생성하고, API 서버로 전송한다.
|
||||
다음 명령어를 실행하여 수행할 수 있다.
|
||||
|
||||
```shell
|
||||
cat <<EOF | kubectl apply -f -
|
||||
@@ -157,7 +166,7 @@ Subject Alternative Names:
|
||||
Events: <none>
|
||||
```
|
||||
|
||||
## 인증서 서명 요청 승인 받기
|
||||
## 인증서 서명 요청 승인 받기 {#get-the-certificate-signing-request-approved}
|
||||
|
||||
[인증서 서명 요청](/docs/reference/access-authn-authz/certificate-signing-requests/) 승인은
|
||||
자동화된 승인 프로세스 또는 클러스터 관리자의 일회성 승인으로 수행된다.
|
||||
@@ -186,7 +195,7 @@ my-svc.my-namespace 10m example.com/serving yourname@example.com <none>
|
||||
이는 즉 인증서 요청이 승인되었으며
|
||||
요청받은 서명자의 서명을 기다리고 있음을 나타낸다.
|
||||
|
||||
## 인증서 서명 요청에 서명하기
|
||||
## 인증서 서명 요청에 서명하기 {#sign-the-certificate-signing-request}
|
||||
|
||||
다음으로, 인증서 서명자로서, 인증서를 발급하고, 이를 API에 업로드할 것이다.
|
||||
|
||||
@@ -196,7 +205,9 @@ my-svc.my-namespace 10m example.com/serving yourname@example.com <none>
|
||||
|
||||
### 인증 기관 생성하기
|
||||
|
||||
먼저: 다음을 실행하여 서명 인증서를 생성한다.
|
||||
새 인증서의 디지털 서명에 제공할 인증 기관이 필요하다.
|
||||
|
||||
먼저, 다음을 실행하여 서명 인증서를 생성한다.
|
||||
|
||||
```shell
|
||||
cat <<EOF | cfssl gencert -initca - | cfssljson -bare ca
|
||||
@@ -256,16 +267,19 @@ kubectl get csr my-svc.my-namespace -o json | \
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
위의 명령에서 `.status.certificate` 필드에 base64로 인코딩된 내용을 채우기 위해 [jq](https://stedolan.github.io/jq/) 명령줄 도구를 사용하였다.
|
||||
`jq`가 없다면, JSON 출력을 파일에 저장하고, 해당 필드를 수동으로 채우고, 그 결과 파일을 업로드할 수도 있다.
|
||||
위의 명령에서 `.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
|
||||
@@ -281,37 +295,48 @@ kubectl get csr my-svc.my-namespace -o jsonpath='{.status.certificate}' \
|
||||
| base64 --decode > server.crt
|
||||
```
|
||||
|
||||
이제 `server.crt` 및 `server-key.pem`의 내용으로 시크릿을 생성하고 파드에 마운트하여
|
||||
HTTPS 서버를 시작하는 데 필요한 키페어로 사용할 수 있다.
|
||||
이제 `server.crt` 및 `server-key.pem`의 내용으로
|
||||
{{< glossary_tooltip text="시크릿" term_id="secret" >}}을 생성할 수 있으며,
|
||||
이 시크릿은 추후 파드에 마운트할 수 있다(예를 들어,
|
||||
HTTPS를 제공하는 웹서버에 사용).
|
||||
|
||||
```shell
|
||||
kubectl create secret tls server --cert server.crt --key server-key.pem
|
||||
kubectl create secret tls server --cert server.crt --key server-key.pem
|
||||
```
|
||||
|
||||
```none
|
||||
secret/server created
|
||||
```
|
||||
|
||||
마지막으로, `ca.pem`의 내용으로 컨피그맵을 생성하여
|
||||
마지막으로, `ca.pem`의 내용으로 {{< glossary_tooltip text="컨피그맵" term_id="configmap" >}}을 생성하여
|
||||
제공(serving) 인증서 검증에 필요한 신뢰 루트로 사용할 수 있다.
|
||||
|
||||
```shell
|
||||
kubectl create configmap example-serving-ca --from-file ca.crt=ca.pem
|
||||
kubectl create configmap example-serving-ca --from-file ca.crt=ca.pem
|
||||
```
|
||||
|
||||
```none
|
||||
configmap/example-serving-ca created
|
||||
```
|
||||
|
||||
## 인증서 서명 요청 승인
|
||||
## CertificateSigningRequest 승인 {#approving-certificate-signing-requests}
|
||||
|
||||
(적절한 권한이 있는) 쿠버네티스 관리자는
|
||||
`kubectl certificate approve` 과 `kubectl certificate deny`
|
||||
명령을 사용하여 인증서 서명 요청을 수동으로 승인 (또는 거부) 할 수 있다.
|
||||
명령을 사용하여 CertificateSigningRequest을 수동으로 승인 (또는 거부) 할 수 있다.
|
||||
그러나 이 API를 많이 사용한다면,
|
||||
자동화된 인증서 컨트롤러 작성을 고려할 수 있다.
|
||||
|
||||
위와 같이 kubectl을 사용하는 시스템이든 사람이든, 승인자의 역할은
|
||||
{{< caution >}}
|
||||
CSR을 승인할 수 있는 권한이 있다는 것은 당신의 환경에서 누가 누구를 신뢰할 수 있는지를 결정할 수 있다는 것이다.
|
||||
CSR을 승인할 수 있는 권한은 넓게/가볍게 부여되지 않아야 한다.
|
||||
|
||||
`approve` 권한을 부여하기 전에,
|
||||
승인자에게 할당되는 검증 요구 사항 **및** 특정 인증서 발급에 따른 영향을
|
||||
모두 확실히 이해하고 있는지 확인해야 한다.
|
||||
{{< /caution >}}
|
||||
|
||||
위와 같이 kubectl을 사용하는 시스템이든 사람이든, _승인자_ 의 역할은
|
||||
CSR이 다음 두 가지 요구 사항을 충족하는지 확인하는 것이다.
|
||||
|
||||
1. CSR은 CSR에 서명하는 데 사용되는 개인 키를 제어하는 것이다. 이는
|
||||
@@ -326,17 +351,13 @@ CSR이 다음 두 가지 요구 사항을 충족하는지 확인하는 것이다
|
||||
이 두 가지 요구 사항이 충족되는 경우에만, 승인자가 CSR을 승인하고
|
||||
그렇지 않으면 CSR을 거부해야 한다.
|
||||
|
||||
## 승인 허가에 대한 경고문
|
||||
인증서 승인 및 접근 제어에 대한 추가 정보를 보려면,
|
||||
[인증서 서명 요청](/docs/reference/access-authn-authz/certificate-signing-requests/) 레퍼런스 페이지를
|
||||
참조한다.
|
||||
|
||||
CSR을 승인하는 능력은 환경 내에서 누구를 신뢰하는지 결정한다. CSR 승인
|
||||
능력은 광범위하거나 가볍게 부여해서는 안된다. 이 권한을
|
||||
부여하기 전에 이전 섹션에서 언급한
|
||||
요청의 요구 사항과 특정 인증서 발급의 영향을
|
||||
완전히 이해해야 한다.
|
||||
## 서명을 제공하도록 클러스터 구성하기 {#a-note-to-cluster-administrators}
|
||||
|
||||
## 클러스터 관리자를 위한 참고 사항
|
||||
|
||||
이 가이드에서는 서명자가 인증서 API를 제공하도록 설정되었다고 가정한다. 쿠버네티스
|
||||
이 페이지에서는 서명자가 인증서 API를 제공하도록 설정되었다고 가정한다. 쿠버네티스
|
||||
컨트롤러 관리자는 서명자의 기본 구현을 제공한다. 이를
|
||||
활성화하려면 인증 기관(CA)의 키 쌍에 대한 경로와 함께 `--cluster-signing-cert-file` 와
|
||||
`--cluster-signing-key-file` 매개 변수를
|
||||
|
||||
@@ -12,16 +12,11 @@ Zsh용 kubectl 자동 완성 스크립트는 `kubectl completion zsh` 명령으
|
||||
source <(kubectl completion zsh)
|
||||
```
|
||||
|
||||
kubectl에 대한 앨리어스가 있는 경우, 해당 앨리어스로 작업하도록 셸 자동 완성을 확장할 수 있다.
|
||||
|
||||
```zsh
|
||||
echo 'alias k=kubectl' >>~/.zshrc
|
||||
echo 'compdef __start_kubectl k' >>~/.zshrc
|
||||
```
|
||||
kubectl에 대한 앨리어스가 있는 경우, kubectl 자동완성이 자동으로 동작할 것이다.
|
||||
|
||||
셸을 다시 로드하면, kubectl 자동 완성 기능이 작동할 것이다.
|
||||
|
||||
`complete:13: command not found: compdef` 와 같은 오류가 발생하면, `~/.zshrc` 파일의 시작 부분에 다음을 추가한다.
|
||||
`2: command not found: compdef` 와 같은 오류가 발생하면, `~/.zshrc` 파일의 시작 부분에 다음을 추가한다.
|
||||
|
||||
```zsh
|
||||
autoload -Uz compinit
|
||||
|
||||
@@ -52,7 +52,7 @@ card:
|
||||
kubectl 바이너리를 체크섬 파일을 통해 검증한다.
|
||||
|
||||
```bash
|
||||
echo "$(<kubectl.sha256) kubectl" | sha256sum --check
|
||||
echo "$(cat kubectl.sha256) kubectl" | sha256sum --check
|
||||
```
|
||||
|
||||
검증이 성공한다면, 출력은 다음과 같다.
|
||||
@@ -83,7 +83,7 @@ card:
|
||||
|
||||
```bash
|
||||
chmod +x kubectl
|
||||
mkdir -p ~/.local/bin/kubectl
|
||||
mkdir -p ~/.local/bin
|
||||
mv ./kubectl ~/.local/bin/kubectl
|
||||
# 그리고 ~/.local/bin 을 $PATH의 앞부분 또는 뒷부분에 추가
|
||||
```
|
||||
@@ -95,6 +95,11 @@ card:
|
||||
```bash
|
||||
kubectl version --client
|
||||
```
|
||||
또는 다음을 실행하여 버전에 대한 더 자세한 정보를 본다.
|
||||
|
||||
```cmd
|
||||
kubectl version --client --output=yaml
|
||||
```
|
||||
|
||||
### 기본 패키지 관리 도구를 사용하여 설치 {#install-using-native-package-management}
|
||||
|
||||
@@ -207,7 +212,7 @@ kubectl은 Bash, Zsh, Fish, 및 PowerShell에 대한 자동 완성 지원을 제
|
||||
kubectl-convert 바이너리를 체크섬 파일을 통해 검증한다.
|
||||
|
||||
```bash
|
||||
echo "$(<kubectl-convert.sha256) kubectl-convert" | sha256sum --check
|
||||
echo "$(cat kubectl-convert.sha256) kubectl-convert" | sha256sum --check
|
||||
```
|
||||
|
||||
검증이 성공한다면, 출력은 다음과 같다.
|
||||
|
||||
@@ -69,7 +69,7 @@ card:
|
||||
kubectl 바이너리를 체크섬 파일을 통해 검증한다.
|
||||
|
||||
```bash
|
||||
echo "$(<kubectl.sha256) kubectl" | shasum -a 256 --check
|
||||
echo "$(cat kubectl.sha256) kubectl" | shasum -a 256 --check
|
||||
```
|
||||
|
||||
검증이 성공한다면, 출력은 다음과 같다.
|
||||
@@ -111,6 +111,11 @@ card:
|
||||
```bash
|
||||
kubectl version --client
|
||||
```
|
||||
또는 다음을 실행하여 버전에 대한 더 자세한 정보를 본다.
|
||||
|
||||
```cmd
|
||||
kubectl version --client --output=yaml
|
||||
```
|
||||
|
||||
### macOS에서 Homebrew를 사용하여 설치 {#install-with-homebrew-on-macos}
|
||||
|
||||
@@ -200,7 +205,7 @@ kubectl은 Bash, Zsh, Fish, 및 PowerShell에 대한 자동 완성 지원을 제
|
||||
kubectl-convert 바이너리를 체크섬 파일을 통해 검증한다.
|
||||
|
||||
```bash
|
||||
echo "$(<kubectl-convert.sha256) kubectl-convert" | shasum -a 256 --check
|
||||
echo "$(cat kubectl-convert.sha256) kubectl-convert" | shasum -a 256 --check
|
||||
```
|
||||
|
||||
검증이 성공한다면, 출력은 다음과 같다.
|
||||
|
||||
@@ -38,13 +38,13 @@ card:
|
||||
|
||||
1. 바이너리를 검증한다. (선택 사항)
|
||||
|
||||
kubectl 체크섬 파일을 다운로드한다.
|
||||
`kubectl` 체크섬 파일을 다운로드한다.
|
||||
|
||||
```powershell
|
||||
curl -LO "https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe.sha256"
|
||||
```
|
||||
|
||||
kubectl 바이너리를 체크섬 파일을 통해 검증한다.
|
||||
`kubectl` 바이너리를 체크섬 파일을 통해 검증한다.
|
||||
|
||||
- 커맨드 프롬프트를 사용하는 경우, `CertUtil` 의 출력과 다운로드한 체크섬 파일을 수동으로 비교한다.
|
||||
|
||||
@@ -59,13 +59,18 @@ card:
|
||||
$($(CertUtil -hashfile .\kubectl.exe SHA256)[1] -replace " ", "") -eq $(type .\kubectl.exe.sha256)
|
||||
```
|
||||
|
||||
1. kubectl 바이너리가 있는 폴더를 `PATH` 환경 변수의 앞부분 또는 뒷부분에 추가
|
||||
1. `kubectl` 바이너리가 있는 폴더를 `PATH` 환경 변수의 앞부분 또는 뒷부분에 추가
|
||||
|
||||
1. `kubectl` 의 버전이 다운로드한 버전과 같은지 확인한다.
|
||||
|
||||
```cmd
|
||||
kubectl version --client
|
||||
```
|
||||
또는 다음을 실행하여 버전에 대한 더 자세한 정보를 본다.
|
||||
|
||||
```cmd
|
||||
kubectl version --client --output=yaml
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
[윈도우용 도커 데스크톱](https://docs.docker.com/docker-for-windows/#kubernetes)은 자체 버전의 `kubectl` 을 `PATH` 에 추가한다.
|
||||
@@ -151,13 +156,13 @@ kubectl은 Bash, Zsh, Fish, 및 PowerShell에 대한 자동 완성 지원을 제
|
||||
|
||||
1. 바이너리를 검증한다. (선택 사항)
|
||||
|
||||
kubectl-convert 체크섬(checksum) 파일을 다운로드한다.
|
||||
`kubectl-convert` 체크섬(checksum) 파일을 다운로드한다.
|
||||
|
||||
```powershell
|
||||
curl -LO "https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubectl-convert.exe.sha256"
|
||||
```
|
||||
|
||||
kubectl-convert 바이너리를 체크섬 파일을 통해 검증한다.
|
||||
`kubectl-convert` 바이너리를 체크섬 파일을 통해 검증한다.
|
||||
|
||||
- 커맨드 프롬프트를 사용하는 경우, `CertUtil` 의 출력과 다운로드한 체크섬 파일을 수동으로 비교한다.
|
||||
|
||||
@@ -172,7 +177,7 @@ kubectl은 Bash, Zsh, Fish, 및 PowerShell에 대한 자동 완성 지원을 제
|
||||
$($(CertUtil -hashfile .\kubectl-convert.exe SHA256)[1] -replace " ", "") -eq $(type .\kubectl-convert.exe.sha256)
|
||||
```
|
||||
|
||||
1. kubectl 바이너리가 있는 폴더를 `PATH` 환경 변수의 앞부분 또는 뒷부분에 추가
|
||||
1. `kubectl-convert` 바이너리가 있는 폴더를 `PATH` 환경 변수의 앞부분 또는 뒷부분에 추가
|
||||
|
||||
1. 플러그인이 정상적으로 설치되었는지 확인한다.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user