diff --git a/content/ko/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md b/content/ko/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md index b57c6e5f88..7ed28d0dd3 100644 --- a/content/ko/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md +++ b/content/ko/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md @@ -6,19 +6,15 @@ weight: 40 -본 페이지는 파드가 DownwardAPIVolumeFile을 사용하여 파드에서 실행되는 컨테이너에 -자신에 대한 정보를 노출하는 방법에 대해 설명한다. DownwardAPIVolumeFile은 파드 필드와 -컨테이너 필드를 노출할 수 있다. - - +본 페이지는 파드가 +[`DownwardAPIVolumeFile`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#downwardapivolumefile-v1-core)을 사용하여 +파드에서 실행되는 컨테이너에 자신에 대한 정보를 노출하는 방법에 대해 설명한다. +`DownwardAPIVolumeFile`은 파드 필드와 컨테이너 필드를 노출할 수 있다. ## {{% heading "prerequisites" %}} - {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} - - ## 다운워드(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` 파일을 확인할 수 있다. - - + ## 다운워드 API의 기능 -다음 정보는 환경 변수 및 `downwardAPI` 볼륨을 통해 컨테이너에서 사용할 수 있다. +다음 정보는 환경 변수 및 `downwardAPI` 볼륨을 통해 +컨테이너에서 사용할 수 있다. * `fieldRef`를 통해 다음 정보를 사용할 수 있다. + * `metadata.name` - 파드의 이름 * `metadata.namespace` - 파드의 네임스페이스(Namespace) * `metadata.uid` - 파드의 UID - * `metadata.labels['']` - 파드의 레이블 `` 값 (예를 들어, `metadata.labels['mylabel']`) - * `metadata.annotations['']` - 파드의 어노테이션 `` 값 (예를 들어, `metadata.annotations['myannotation']`) + * `metadata.labels['']` - 파드의 레이블 `` 값 + (예를 들어, `metadata.labels['mylabel']`) + * `metadata.annotations['']` - 파드의 어노테이션 `` 값 + (예를 들어, `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 정의를 확인한다. diff --git a/content/ko/docs/tasks/job/parallel-processing-expansion.md b/content/ko/docs/tasks/job/parallel-processing-expansion.md index 5870b4b314..ddf1bd0b88 100644 --- a/content/ko/docs/tasks/job/parallel-processing-expansion.md +++ b/content/ko/docs/tasks/job/parallel-processing-expansion.md @@ -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 %} diff --git a/content/ko/docs/tasks/manage-daemon/update-daemon-set.md b/content/ko/docs/tasks/manage-daemon/update-daemon-set.md index 8a42e0d034..d8c7aa935b 100644 --- a/content/ko/docs/tasks/manage-daemon/update-daemon-set.md +++ b/content/ko/docs/tasks/manage-daemon/update-daemon-set.md @@ -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)를 diff --git a/content/ko/docs/tasks/network/validate-dual-stack.md b/content/ko/docs/tasks/network/validate-dual-stack.md index 6c14644db1..36730ac66b 100644 --- a/content/ko/docs/tasks/network/validate-dual-stack.md +++ b/content/ko/docs/tasks/network/validate-dual-stack.md @@ -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 >}} diff --git a/content/ko/docs/tasks/run-application/access-api-from-pod.md b/content/ko/docs/tasks/run-application/access-api-from-pod.md index d12f3b2f00..b9a0a8c55e 100644 --- a/content/ko/docs/tasks/run-application/access-api-from-pod.md +++ b/content/ko/docs/tasks/run-application/access-api-from-pod.md @@ -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` 에 있다. 사용 가능한 경우, 인증서 번들은 각 컨테이너의 diff --git a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md index d1e864476a..659da85079 100644 --- a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md +++ b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md @@ -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: diff --git a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md index 99053e98e7..e09dc34f36 100644 --- a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md +++ b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md @@ -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 사이의 레플리카 개수로 설정된다. ## 암시적 유지 관리 모드 비활성화 diff --git a/content/ko/docs/tasks/tls/managing-tls-in-a-cluster.md b/content/ko/docs/tasks/tls/managing-tls-in-a-cluster.md index 3d8c4d5942..8a67143f54 100644 --- a/content/ko/docs/tasks/tls/managing-tls-in-a-cluster.md +++ b/content/ko/docs/tasks/tls/managing-tls-in-a-cluster.md @@ -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/)에서 받을 수 있다. ## 클러스터에서 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 < ``` -## 인증서 서명 요청 승인 받기 +## 인증서 서명 요청 승인 받기 {#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 이는 즉 인증서 요청이 승인되었으며 요청받은 서명자의 서명을 기다리고 있음을 나타낸다. -## 인증서 서명 요청에 서명하기 +## 인증서 서명 요청에 서명하기 {#sign-the-certificate-signing-request} 다음으로, 인증서 서명자로서, 인증서를 발급하고, 이를 API에 업로드할 것이다. @@ -196,7 +205,9 @@ my-svc.my-namespace 10m example.com/serving yourname@example.com ### 인증 기관 생성하기 -먼저: 다음을 실행하여 서명 인증서를 생성한다. +새 인증서의 디지털 서명에 제공할 인증 기관이 필요하다. + +먼저, 다음을 실행하여 서명 인증서를 생성한다. ```shell cat <}} -위의 명령에서 `.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 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` 매개 변수를 diff --git a/content/ko/docs/tasks/tools/included/optional-kubectl-configs-zsh.md b/content/ko/docs/tasks/tools/included/optional-kubectl-configs-zsh.md index 0d2a563c1b..5c857fd2bb 100644 --- a/content/ko/docs/tasks/tools/included/optional-kubectl-configs-zsh.md +++ b/content/ko/docs/tasks/tools/included/optional-kubectl-configs-zsh.md @@ -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 diff --git a/content/ko/docs/tasks/tools/install-kubectl-linux.md b/content/ko/docs/tasks/tools/install-kubectl-linux.md index 06193399ba..df5165c090 100644 --- a/content/ko/docs/tasks/tools/install-kubectl-linux.md +++ b/content/ko/docs/tasks/tools/install-kubectl-linux.md @@ -52,7 +52,7 @@ card: kubectl 바이너리를 체크섬 파일을 통해 검증한다. ```bash - echo "$(}}/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. 플러그인이 정상적으로 설치되었는지 확인한다. diff --git a/content/ko/docs/tutorials/hello-minikube.md b/content/ko/docs/tutorials/hello-minikube.md index cd7e5c9b08..ce93967a59 100644 --- a/content/ko/docs/tutorials/hello-minikube.md +++ b/content/ko/docs/tutorials/hello-minikube.md @@ -136,7 +136,7 @@ minikube dashboard --url ``` {{< note >}} -`kubectl` 명령어에 관해 자세히 알기 원하면 [kubectl 개요](/ko/docs/reference/kubectl/overview/)을 살펴보자. +`kubectl` 명령어에 관해 자세히 알기 원하면 [kubectl 개요](/ko/docs/reference/kubectl/)을 살펴보자. {{< /note >}} ## 서비스 만들기 diff --git a/content/ko/docs/tutorials/security/apparmor.md b/content/ko/docs/tutorials/security/apparmor.md index 7dde58e298..fa65e49c04 100644 --- a/content/ko/docs/tutorials/security/apparmor.md +++ b/content/ko/docs/tutorials/security/apparmor.md @@ -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: [,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)으로 준비되면 현재 어노테이션으로 지정되는 옵션은 필드로 변경될 것이다. -모든 업그레이드와 다운그레이드 방법은 전환을 통해 지원하기에는 매우 미묘하니 -전환이 필요할 때에 상세히 설명할 것이다. -최소 두 번의 릴리스에 대해서는 필드와 어노테이션 모두를 지원할 것이고, -그 이후부터는 어노테이션은 명확히 거부된다. +{{}} +쿠버네티스 기능이 비활성화되어 있어도, 런타임이 계속 기본 프로파일을 강제할 수도 있다. +AppArmor가 general availability (GA) 상태로 바뀌면 +AppArmor 기능을 비활성화하는 옵션은 제거될 것이다. +{{}} ## 프로파일 제작 {#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/`: 노드(localhost)에 적재된 프로파일을 이름으로 참조한다. - 가용한 프로파일 이름의 상세 내용은 [핵심 정책 참조](https://gitlab.com/apparmor/apparmor/wikis/AppArmor_Core_Policy_Reference#profile-names-and-attachment-specifications)에 설명되어 있다. diff --git a/content/ko/docs/tutorials/security/ns-level-pss.md b/content/ko/docs/tutorials/security/ns-level-pss.md index 46e518e43c..06b566d218 100644 --- a/content/ko/docs/tutorials/security/ns-level-pss.md +++ b/content/ko/docs/tutorials/security/ns-level-pss.md @@ -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 < /tmp/pss/nginx-pod.yaml - apiVersion: v1 - kind: Pod - metadata: - name: nginx - spec: - containers: - - image: nginx - name: nginx - ports: - - containerPort: 80 - EOF - ``` + ```shell + cat < /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/) \ No newline at end of file +- [파드 시큐리티 스탠다드를 클러스터 수준에 적용하기](/ko/docs/tutorials/security/cluster-level-pss/) diff --git a/content/ko/docs/tutorials/services/source-ip.md b/content/ko/docs/tutorials/services/source-ip.md index f18da2888a..56489347d6 100644 --- a/content/ko/docs/tutorials/services/source-ip.md +++ b/content/ko/docs/tutorials/services/source-ip.md @@ -119,7 +119,7 @@ clusterip ClusterIP 10.0.170.92 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 ``` 출력은 다음과 같다. ``` diff --git a/content/ko/docs/tutorials/stateful-application/zookeeper.md b/content/ko/docs/tutorials/stateful-application/zookeeper.md index 392612e059..b9cf603032 100644 --- a/content/ko/docs/tutorials/stateful-application/zookeeper.md +++ b/content/ko/docs/tutorials/stateful-application/zookeeper.md @@ -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 ```