[ko] Update outdated files in dev-1.24-ko.1 M115-M138
Jihoon Seo
parent
507491e619
commit
3ec9363bca
|
|
@ -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. 플러그인이 정상적으로 설치되었는지 확인한다.
|
||||
|
||||
|
|
|
|||
|
|
@ -136,7 +136,7 @@ minikube dashboard --url
|
|||
```
|
||||
|
||||
{{< note >}}
|
||||
`kubectl` 명령어에 관해 자세히 알기 원하면 [kubectl 개요](/ko/docs/reference/kubectl/overview/)을 살펴보자.
|
||||
`kubectl` 명령어에 관해 자세히 알기 원하면 [kubectl 개요](/ko/docs/reference/kubectl/)을 살펴보자.
|
||||
{{< /note >}}
|
||||
|
||||
## 서비스 만들기
|
||||
|
|
|
|||
|
|
@ -264,7 +264,7 @@ metadata:
|
|||
spec:
|
||||
containers:
|
||||
- name: hello
|
||||
image: busybox
|
||||
image: busybox:1.28
|
||||
command: [ "sh", "-c", "echo 'Hello AppArmor!' && sleep 1h" ]
|
||||
EOF
|
||||
pod/hello-apparmor-2 created
|
||||
|
|
@ -350,7 +350,7 @@ Events:
|
|||
|
||||
{{< note >}}
|
||||
파드시큐리티폴리시는 쿠버네티스 v1.21에서 사용 중단되었으며, v1.25에서 제거될 예정이다.
|
||||
더 자세한 내용은 [파드시큐리티폴리시 문서](/ko/docs/concepts/policy/pod-security-policy/)를 참고한다.
|
||||
더 자세한 내용은 [파드시큐리티폴리시](/ko/docs/concepts/policy/pod-security-policy/) 문서를 참고한다.
|
||||
{{< /note >}}
|
||||
|
||||
만약 파드시큐리티폴리시 확장을 사용하면, 클러스터 단위로 AppArmor 제한을 적용할 수 있다.
|
||||
|
|
@ -381,28 +381,14 @@ apparmor.security.beta.kubernetes.io/allowedProfileNames: <profile_ref>[,others.
|
|||
--feature-gates=AppArmor=false
|
||||
```
|
||||
|
||||
비활성화되면 AppArmor 프로파일을 포함한 파드는 "Forbidden" 오류로 검증 실패한다.
|
||||
기본적으로 도커는 항상 비특권 파드에 "docker-default" 프로파일을 활성화하고(AppArmor 커널모듈이 활성화되었다면),
|
||||
기능 게이트가 비활성화된 것처럼 진행한다.
|
||||
AppArmor를 비활성화하는 이 옵션은
|
||||
AppArmor가 일반 사용자 버전이 되면 제거된다.
|
||||
비활성화되면, AppArmor 프로파일을 포함한 파드는
|
||||
"Forbidden" 오류로 검증 실패한다.
|
||||
|
||||
### AppArmor와 함께 쿠버네티스 1.4로 업그레이드 하기 {#upgrading-to-kubernetes-v1.4-with-apparmor}
|
||||
|
||||
클러스터 버전을 v1.4로 업그레이드하기 위해 AppArmor쪽 작업은 없다.
|
||||
그러나 AppArmor 어노테이션을 가진 파드는 유효성 검사(혹은 파드시큐리티폴리시 승인)을 거치지 않는다.
|
||||
그 노드에 허용 프로파일이 로드되면, 악의적인 사용자가 허가 프로필을 미리 적용하여
|
||||
파드의 권한을 docker-default 보다 높일 수 있다.
|
||||
이것이 염려된다면 `apparmor.security.beta.kubernetes.io` 어노테이션이 포함된
|
||||
모든 파드의 클러스터를 제거하는 것이 좋다.
|
||||
|
||||
### 일반 사용자 버전으로 업그레이드 방법 {#upgrade-path-to-general-availability}
|
||||
|
||||
AppArmor는 일반 사용자 버전(general available)으로 준비되면 현재 어노테이션으로 지정되는 옵션은 필드로 변경될 것이다.
|
||||
모든 업그레이드와 다운그레이드 방법은 전환을 통해 지원하기에는 매우 미묘하니
|
||||
전환이 필요할 때에 상세히 설명할 것이다.
|
||||
최소 두 번의 릴리스에 대해서는 필드와 어노테이션 모두를 지원할 것이고,
|
||||
그 이후부터는 어노테이션은 명확히 거부된다.
|
||||
{{<note>}}
|
||||
쿠버네티스 기능이 비활성화되어 있어도, 런타임이 계속 기본 프로파일을 강제할 수도 있다.
|
||||
AppArmor가 general availability (GA) 상태로 바뀌면
|
||||
AppArmor 기능을 비활성화하는 옵션은 제거될 것이다.
|
||||
{{</note>}}
|
||||
|
||||
## 프로파일 제작 {#authoring-profiles}
|
||||
|
||||
|
|
@ -415,10 +401,6 @@ AppArmor 프로파일을 만들고 올바르게 지정하는 것은 매우 까
|
|||
* [bane](https://github.com/jfrazelle/bane)은 단순화된 프로파일 언어를 이용하는 도커를 위한
|
||||
AppArmor 프로파일 생성기이다.
|
||||
|
||||
개발 장비의 도커를 통해 애플리케이션을 실행하여
|
||||
프로파일을 생성하는 것을 권장하지만,
|
||||
파드가 실행 중인 쿠버네티스 노드에서 도구 실행을 금하지는 않는다.
|
||||
|
||||
AppArmor 문제를 디버깅하기 위해서 거부된 것으로 보이는 시스템 로그를 확인할 수 있다.
|
||||
AppArmor 로그는 `dmesg`에서 보이며, 오류는 보통 시스템 로그나
|
||||
`journalctl`에서 볼 수 있다. 더 많은 정보는
|
||||
|
|
@ -441,9 +423,8 @@ AppArmor 로그는 `dmesg`에서 보이며, 오류는 보통 시스템 로그나
|
|||
- `runtime/default`: 기본 런타임 프로파일을 참조한다.
|
||||
- (기본 파드시큐리티폴리시 없이) 프로파일을 지정하지 않고
|
||||
AppArmor를 사용하는 것과 동등하다.
|
||||
- 도커에서는 권한 없는 컨테이너의 경우는
|
||||
[`docker-default`](https://docs.docker.com/engine/security/apparmor/) 프로파일로,
|
||||
권한이 있는 컨테이너의 경우 unconfined(프로파일 없음)으로 해석한다.
|
||||
- 실제로는, 많은 컨테이너 런타임은 동일한 OCI 기본 프로파일을 사용하며, 이는
|
||||
https://github.com/containers/common/blob/main/pkg/apparmor/apparmor_linux_template.go 에 정의되어 있다.
|
||||
- `localhost/<profile_name>`: 노드(localhost)에 적재된 프로파일을 이름으로 참조한다.
|
||||
- 가용한 프로파일 이름의 상세 내용은
|
||||
[핵심 정책 참조](https://gitlab.com/apparmor/apparmor/wikis/AppArmor_Core_Policy_Reference#profile-names-and-attachment-specifications)에 설명되어 있다.
|
||||
|
|
|
|||
|
|
@ -16,7 +16,9 @@ weight: 10
|
|||
각 네임스페이스별로 `baseline` 파드 시큐리티 스탠다드를 강제(enforce)할 것이다.
|
||||
|
||||
파드 시큐리티 스탠다드를 클러스터 수준에서 여러 네임스페이스에 한 번에 적용할 수도 있다.
|
||||
이에 대한 안내는 [파드 시큐리티 스탠다드를 클러스터 수준에 적용하기](/ko/docs/tutorials/security/cluster-level-pss/)를 참고한다.
|
||||
이에 대한 안내는
|
||||
[파드 시큐리티 스탠다드를 클러스터 수준에 적용하기](/ko/docs/tutorials/security/cluster-level-pss/)를 참고한다.
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
워크스테이션에 다음을 설치한다.
|
||||
|
|
@ -28,37 +30,41 @@ weight: 10
|
|||
|
||||
1. 다음과 같이 `KinD` 클러스터를 생성한다.
|
||||
|
||||
```shell
|
||||
kind create cluster --name psa-ns-level --image kindest/node:v1.23.0
|
||||
```
|
||||
```shell
|
||||
kind create cluster --name psa-ns-level --image kindest/node:v1.23.0
|
||||
```
|
||||
|
||||
다음과 비슷하게 출력될 것이다.
|
||||
```
|
||||
Creating cluster "psa-ns-level" ...
|
||||
✓ Ensuring node image (kindest/node:v1.23.0) 🖼
|
||||
✓ Preparing nodes 📦
|
||||
✓ Writing configuration 📜
|
||||
✓ Starting control-plane 🕹️
|
||||
✓ Installing CNI 🔌
|
||||
✓ Installing StorageClass 💾
|
||||
Set kubectl context to "kind-psa-ns-level"
|
||||
You can now use your cluster with:
|
||||
|
||||
```
|
||||
Creating cluster "psa-ns-level" ...
|
||||
✓ Ensuring node image (kindest/node:v1.23.0) 🖼
|
||||
✓ Preparing nodes 📦
|
||||
✓ Writing configuration 📜
|
||||
✓ Starting control-plane 🕹️
|
||||
✓ Installing CNI 🔌
|
||||
✓ Installing StorageClass 💾
|
||||
Set kubectl context to "kind-psa-ns-level"
|
||||
You can now use your cluster with:
|
||||
|
||||
kubectl cluster-info --context kind-psa-ns-level
|
||||
kubectl cluster-info --context kind-psa-ns-level
|
||||
|
||||
Not sure what to do next? 😅 Check out https://kind.sigs.k8s.io/docs/user/quick-start/
|
||||
```
|
||||
Not sure what to do next? 😅 Check out https://kind.sigs.k8s.io/docs/user/quick-start/
|
||||
```
|
||||
|
||||
1. kubectl context를 새로 생성한 클러스터로 설정한다.
|
||||
```shell
|
||||
kubectl cluster-info --context kind-psa-ns-level
|
||||
```
|
||||
|
||||
```shell
|
||||
kubectl cluster-info --context kind-psa-ns-level
|
||||
```
|
||||
다음과 비슷하게 출력될 것이다.
|
||||
```
|
||||
Kubernetes control plane is running at https://127.0.0.1:50996
|
||||
CoreDNS is running at https://127.0.0.1:50996/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
|
||||
|
||||
```
|
||||
Kubernetes control plane is running at https://127.0.0.1:50996
|
||||
CoreDNS is running at https://127.0.0.1:50996/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
|
||||
|
||||
To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
|
||||
```
|
||||
To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
|
||||
```
|
||||
|
||||
## 네임스페이스 생성하기
|
||||
|
||||
|
|
@ -67,7 +73,9 @@ weight: 10
|
|||
```shell
|
||||
kubectl create ns example
|
||||
```
|
||||
|
||||
다음과 비슷하게 출력될 것이다.
|
||||
|
||||
```
|
||||
namespace/example created
|
||||
```
|
||||
|
|
@ -78,63 +86,68 @@ namespace/example created
|
|||
이 네임스페이스에 파드 시큐리티 스탠다드를 활성화한다.
|
||||
이 단계에서는 `latest` 버전(기본값)에 따라 `baseline(기준)` 파드 시큐리티 스탠다드에 대해 경고를 설정한다.
|
||||
|
||||
```shell
|
||||
kubectl label --overwrite ns example \
|
||||
```shell
|
||||
kubectl label --overwrite ns example \
|
||||
pod-security.kubernetes.io/warn=baseline \
|
||||
pod-security.kubernetes.io/warn-version=latest
|
||||
```
|
||||
```
|
||||
|
||||
2. 어떠한 네임스페이스에도 복수 개의 파드 시큐리티 스탠다드를 활성화할 수 있으며,
|
||||
이는 레이블을 이용하여 가능하다.
|
||||
다음 명령어는 최신 버전(기본값)에 따라, `baseline(기준)` 파드 시큐리티 스탠다드는 `enforce(강제)`하지만
|
||||
`restricted(제한된)` 파드 시큐리티 스탠다드에 대해서는 `warn(경고)` 및 `audit(감사)`하도록 설정한다.
|
||||
|
||||
```
|
||||
kubectl label --overwrite ns example \
|
||||
pod-security.kubernetes.io/enforce=baseline \
|
||||
pod-security.kubernetes.io/enforce-version=latest \
|
||||
pod-security.kubernetes.io/warn=restricted \
|
||||
pod-security.kubernetes.io/warn-version=latest \
|
||||
pod-security.kubernetes.io/audit=restricted \
|
||||
pod-security.kubernetes.io/audit-version=latest
|
||||
```
|
||||
```shell
|
||||
kubectl label --overwrite ns example \
|
||||
pod-security.kubernetes.io/enforce=baseline \
|
||||
pod-security.kubernetes.io/enforce-version=latest \
|
||||
pod-security.kubernetes.io/warn=restricted \
|
||||
pod-security.kubernetes.io/warn-version=latest \
|
||||
pod-security.kubernetes.io/audit=restricted \
|
||||
pod-security.kubernetes.io/audit-version=latest
|
||||
```
|
||||
|
||||
## 파드 시큐리티 스탠다드 검증하기
|
||||
|
||||
1. `example` 네임스페이스에 최소한의 파드를 생성한다.
|
||||
|
||||
```shell
|
||||
cat <<EOF > /tmp/pss/nginx-pod.yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: nginx
|
||||
spec:
|
||||
containers:
|
||||
- image: nginx
|
||||
name: nginx
|
||||
ports:
|
||||
- containerPort: 80
|
||||
EOF
|
||||
```
|
||||
```shell
|
||||
cat <<EOF > /tmp/pss/nginx-pod.yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: nginx
|
||||
spec:
|
||||
containers:
|
||||
- image: nginx
|
||||
name: nginx
|
||||
ports:
|
||||
- containerPort: 80
|
||||
EOF
|
||||
```
|
||||
|
||||
1. 클러스터의 `example` 네임스페이스에 해당 파드 스펙을 적용한다.
|
||||
```shell
|
||||
kubectl apply -n example -f /tmp/pss/nginx-pod.yaml
|
||||
```
|
||||
|
||||
```shell
|
||||
kubectl apply -n example -f /tmp/pss/nginx-pod.yaml
|
||||
```
|
||||
다음과 비슷하게 출력될 것이다.
|
||||
```
|
||||
Warning: would violate PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container "nginx" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "nginx" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "nginx" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "nginx" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")
|
||||
pod/nginx created
|
||||
```
|
||||
|
||||
```
|
||||
Warning: would violate PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container "nginx" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "nginx" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "nginx" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "nginx" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")
|
||||
pod/nginx created
|
||||
```
|
||||
|
||||
1. 클러스터의 `default` 네임스페이스에 해당 파드 스펙을 적용한다.
|
||||
```shell
|
||||
kubectl apply -n default -f /tmp/pss/nginx-pod.yaml
|
||||
```
|
||||
|
||||
```shell
|
||||
kubectl apply -n default -f /tmp/pss/nginx-pod.yaml
|
||||
```
|
||||
다음과 비슷하게 출력될 것이다.
|
||||
```
|
||||
pod/nginx created
|
||||
```
|
||||
|
||||
```
|
||||
pod/nginx created
|
||||
```
|
||||
|
||||
파드 시큐리티 스탠다드는 `example` 네임스페이스에만 적용되었다.
|
||||
동일한 파드를 `default` 네임스페이스에 생성하더라도
|
||||
|
|
@ -149,11 +162,13 @@ namespace/example created
|
|||
- 다음의 모든 단계를 한 번에 수행하려면
|
||||
[셸 스크립트](/examples/security/kind-with-namespace-level-baseline-pod-security.sh)를
|
||||
실행한다.
|
||||
|
||||
1. KinD 클러스터를 생성
|
||||
2. 새로운 네임스페이스를 생성
|
||||
3. `baseline` 파드 시큐리티 스탠다드는 `enforce` 모드로 적용하고
|
||||
`restricted` 파드 시큐리티 스탠다드는 `warn` 및 `audit` 모드로 적용
|
||||
4. 해당 파드 시큐리티 스탠다드가 적용된 상태에서 새로운 파드를 생성
|
||||
|
||||
- [파드 시큐리티 어드미션](/docs/concepts/security/pod-security-admission/)
|
||||
- [파드 시큐리티 스탠다드](/docs/concepts/security/pod-security-standards/)
|
||||
- [파드 시큐리티 스탠다드를 클러스터 수준에 적용하기](/ko/docs/tutorials/security/cluster-level-pss/)
|
||||
- [파드 시큐리티 스탠다드를 클러스터 수준에 적용하기](/ko/docs/tutorials/security/cluster-level-pss/)
|
||||
|
|
|
|||
|
|
@ -119,7 +119,7 @@ clusterip ClusterIP 10.0.170.92 <none> 80/TCP 51s
|
|||
그리고 동일한 클러스터의 파드에서 `클러스터IP`를 치면:
|
||||
|
||||
```shell
|
||||
kubectl run busybox -it --image=busybox --restart=Never --rm
|
||||
kubectl run busybox -it --image=busybox:1.28 --restart=Never --rm
|
||||
```
|
||||
출력은 다음과 같다.
|
||||
```
|
||||
|
|
|
|||
|
|
@ -442,7 +442,7 @@ datadir-zk-2 Bound pvc-bee0817e-bcb1-11e6-994f-42010a800002 20Gi R
|
|||
|
||||
`스테이트풀셋`의 컨테이너 `template`의 `volumeMounts` 부분이 ZooKeeper 서버의 데이터 디렉터리에 퍼시스턴트볼륨 마운트하는 내용이다.
|
||||
|
||||
```shell
|
||||
```yaml
|
||||
volumeMounts:
|
||||
- name: datadir
|
||||
mountPath: /var/lib/zookeeper
|
||||
|
|
@ -661,6 +661,8 @@ statefulset rolling update complete 3 pods at revision zk-5db4499664...
|
|||
kubectl rollout history sts/zk
|
||||
```
|
||||
|
||||
출력은 다음과 비슷할 것이다.
|
||||
|
||||
```
|
||||
statefulsets "zk"
|
||||
REVISION
|
||||
|
|
@ -674,6 +676,8 @@ REVISION
|
|||
kubectl rollout undo sts/zk
|
||||
```
|
||||
|
||||
출력은 다음과 비슷할 것이다.
|
||||
|
||||
```
|
||||
statefulset.apps/zk rolled back
|
||||
```
|
||||
|
|
@ -742,14 +746,14 @@ zk-0 1/1 Running 1 29m
|
|||
`zk` `스테이트풀셋`에 파드 `template`에 활성도 검사를 명시한다.
|
||||
|
||||
```yaml
|
||||
livenessProbe:
|
||||
exec:
|
||||
command:
|
||||
- sh
|
||||
- -c
|
||||
- "zookeeper-ready 2181"
|
||||
initialDelaySeconds: 15
|
||||
timeoutSeconds: 5
|
||||
livenessProbe:
|
||||
exec:
|
||||
command:
|
||||
- sh
|
||||
- -c
|
||||
- "zookeeper-ready 2181"
|
||||
initialDelaySeconds: 15
|
||||
timeoutSeconds: 5
|
||||
```
|
||||
|
||||
검사는 ZooKeeper의 `ruok` 4 글자 단어를 이용해서 서버의 건강을 테스트하는
|
||||
|
|
@ -773,7 +777,7 @@ kubectl get pod -w -l app=zk
|
|||
다른 창에서 `zk-0` 파드의 파일시스템에서 `zookeeper-ready` 스크립트를 삭제하기 위해 다음 명령어를 이용하자.
|
||||
|
||||
```shell
|
||||
kubectl exec zk-0 -- rm /usr/bin/zookeeper-ready
|
||||
kubectl exec zk-0 -- rm /opt/zookeeper/bin/zookeeper-ready
|
||||
```
|
||||
|
||||
ZooKeeper의 활성도 검사에 실패하면,
|
||||
|
|
@ -860,16 +864,16 @@ kubernetes-node-2g2d
|
|||
이는 `zk` `스테이트풀셋`의 파드에 `파드안티어피니티(PodAntiAffinity)`를 지정했기 때문이다.
|
||||
|
||||
```yaml
|
||||
affinity:
|
||||
podAntiAffinity:
|
||||
requiredDuringSchedulingIgnoredDuringExecution:
|
||||
- labelSelector:
|
||||
matchExpressions:
|
||||
- key: "app"
|
||||
operator: In
|
||||
values:
|
||||
- zk
|
||||
topologyKey: "kubernetes.io/hostname"
|
||||
affinity:
|
||||
podAntiAffinity:
|
||||
requiredDuringSchedulingIgnoredDuringExecution:
|
||||
- labelSelector:
|
||||
matchExpressions:
|
||||
- key: "app"
|
||||
operator: In
|
||||
values:
|
||||
- zk
|
||||
topologyKey: "kubernetes.io/hostname"
|
||||
```
|
||||
|
||||
`requiredDuringSchedulingIgnoredDuringExecution` 필드는
|
||||
|
|
@ -926,6 +930,8 @@ kubectl get pods -w -l app=zk
|
|||
for i in 0 1 2; do kubectl get pod zk-$i --template {{.spec.nodeName}}; echo ""; done
|
||||
```
|
||||
|
||||
출력은 다음과 비슷할 것이다.
|
||||
|
||||
```
|
||||
kubernetes-node-pb41
|
||||
kubernetes-node-ixsl
|
||||
|
|
@ -939,6 +945,8 @@ kubernetes-node-i4c4
|
|||
kubectl drain $(kubectl get pod zk-0 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-emptydir-data
|
||||
```
|
||||
|
||||
출력은 다음과 비슷할 것이다.
|
||||
|
||||
```
|
||||
node "kubernetes-node-group-pb41" cordoned
|
||||
|
||||
|
|
@ -971,15 +979,19 @@ zk-0 1/1 Running 0 1m
|
|||
`zk-1` 이 스케줄된 노드를 비워보자.
|
||||
|
||||
```shell
|
||||
kubectl drain $(kubectl get pod zk-1 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-emptydir-data "kubernetes-node-ixsl" cordoned
|
||||
kubectl drain $(kubectl get pod zk-1 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-emptydir-data
|
||||
```
|
||||
|
||||
출력은 다음과 비슷할 것이다.
|
||||
|
||||
```
|
||||
"kubernetes-node-ixsl" cordoned
|
||||
WARNING: Deleting pods not managed by ReplicationController, ReplicaSet, Job, or DaemonSet: fluentd-cloud-logging-kubernetes-node-ixsl, kube-proxy-kubernetes-node-ixsl; Ignoring DaemonSet-managed pods: node-problem-detector-v0.1-voc74
|
||||
pod "zk-1" deleted
|
||||
node "kubernetes-node-ixsl" drained
|
||||
```
|
||||
|
||||
|
||||
`zk-1` 파드는 스케줄되지 않는데 이는 `zk` `StatefulSet`이 오직 2개 노드가 스케줄되도록 파드를 위치시키는 것을 금하는
|
||||
`PodAntiAffinity` 규칙을 포함하였기 때문이고 그 파드는 Pending 상태로 남을 것이다.
|
||||
|
||||
|
|
@ -987,6 +999,8 @@ node "kubernetes-node-ixsl" drained
|
|||
kubectl get pods -w -l app=zk
|
||||
```
|
||||
|
||||
출력은 다음과 비슷할 것이다.
|
||||
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
zk-0 1/1 Running 2 1h
|
||||
|
|
@ -1017,6 +1031,8 @@ zk-1 0/1 Pending 0 0s
|
|||
kubectl drain $(kubectl get pod zk-2 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-emptydir-data
|
||||
```
|
||||
|
||||
출력은 다음과 비슷할 것이다.
|
||||
|
||||
```
|
||||
node "kubernetes-node-i4c4" cordoned
|
||||
|
||||
|
|
@ -1060,6 +1076,8 @@ numChildren = 0
|
|||
kubectl uncordon kubernetes-node-pb41
|
||||
```
|
||||
|
||||
출력은 다음과 비슷할 것이다.
|
||||
|
||||
```
|
||||
node "kubernetes-node-pb41" uncordoned
|
||||
```
|
||||
|
|
@ -1070,6 +1088,8 @@ node "kubernetes-node-pb41" uncordoned
|
|||
kubectl get pods -w -l app=zk
|
||||
```
|
||||
|
||||
출력은 다음과 비슷할 것이다.
|
||||
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
zk-0 1/1 Running 2 1h
|
||||
|
|
@ -1103,7 +1123,7 @@ zk-1 1/1 Running 0 13m
|
|||
kubectl drain $(kubectl get pod zk-2 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-emptydir-data
|
||||
```
|
||||
|
||||
출력은
|
||||
출력은 다음과 비슷할 것이다.
|
||||
|
||||
```
|
||||
node "kubernetes-node-i4c4" already cordoned
|
||||
|
|
@ -1121,6 +1141,8 @@ node "kubernetes-node-i4c4" drained
|
|||
kubectl uncordon kubernetes-node-ixsl
|
||||
```
|
||||
|
||||
출력은 다음과 비슷할 것이다.
|
||||
|
||||
```
|
||||
node "kubernetes-node-ixsl" uncordoned
|
||||
```
|
||||
|
|
|
|||
Loading…
Reference in New Issue