diff --git a/content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md b/content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md index c228a1d937..5827925e82 100644 --- a/content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md +++ b/content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md @@ -37,7 +37,7 @@ card: 대시보드 UI는 기본으로 배포되지 않는다. 배포하려면 다음 커맨드를 실행한다. ``` -kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.5.0/aio/deploy/recommended.yaml +kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.6.1/aio/deploy/recommended.yaml ``` ## 대시보드 UI 접근 diff --git a/content/ko/docs/tasks/administer-cluster/namespaces.md b/content/ko/docs/tasks/administer-cluster/namespaces.md index df33bf8de5..e46db9b852 100644 --- a/content/ko/docs/tasks/administer-cluster/namespaces.md +++ b/content/ko/docs/tasks/administer-cluster/namespaces.md @@ -192,12 +192,12 @@ kubectl delete namespaces 하나의 네임스페이스와 상호 작용하는 사용자는 다른 네임스페이스의 내용을 볼 수 없다. - 이를 보여주기 위해 `development` 네임스페이스에서 간단히 디플로이먼트와 파드를 생성하자. + 이를 보여주기 위해 `development` 네임스페이스에 간단한 디플로이먼트와 파드를 생성하자. ```shell - kubectl create deployment snowflake --image=k8s.gcr.io/serve_hostname -n=development --replicas=2 + kubectl create deployment snowflake --image=registry.k8s.io/serve_hostname -n=development --replicas=2 ``` - 호스트 이름을 제공하는 기본 컨테이너로 `snowflake`라는 이름의 파드를 실행하는 레플리카 사이즈 2의 디플로이먼트를 생성했다. + 단순히 호스트명을 제공해주는 `snowflake`라는 파드의 개수를 2개로 유지하는 디플로이먼트를 생성하였다. ```shell kubectl get deployment -n=development @@ -226,10 +226,10 @@ kubectl delete namespaces kubectl get pods -n=production ``` - 프로덕션은 마치 가축을 키우는 것과 같다. 그래서 우리도 cattle(가축)이라는 이름의 파드들을 생성하도록 하겠다. + 프로덕션이 가축 키우는 것을 좋아하듯이, 우리도 `production` 네임스페이스에 cattle(가축)이라는 이름의 파드를 생성한다. ```shell - kubectl create deployment cattle --image=k8s.gcr.io/serve_hostname -n=production + kubectl create deployment cattle --image=registry.k8s.io/serve_hostname -n=production kubectl scale deployment cattle --replicas=5 -n=production kubectl get deployment -n=production diff --git a/content/ko/docs/tasks/administer-cluster/sysctl-cluster.md b/content/ko/docs/tasks/administer-cluster/sysctl-cluster.md index b0b8a3aacc..516f7efee3 100644 --- a/content/ko/docs/tasks/administer-cluster/sysctl-cluster.md +++ b/content/ko/docs/tasks/administer-cluster/sysctl-cluster.md @@ -15,14 +15,13 @@ content_type: task {{< note >}} 쿠버네티스 버전 1.23부터, kubelet은 `/` 또는 `.`를 -sysctl 이름의 구분자로 사용하는 것을 지원한다. +sysctl 이름의 구분자로 사용하는 것을 지원한다. +쿠버네티스 1.25 버전부터, 파드에 대해서도 sysctl을 설정할 때 슬래시 구분자를 지원하기 시작하였다. 예를 들어, 동일한 sysctl 이름을 `kernel.shm_rmid_forced`와 같이 마침표를 구분자로 사용하여 나타내거나 `kernel/shm_rmid_forced`와 같이 슬래시를 구분자로 사용하여 나타낼 수 있다. sysctl 파라미터 변환에 대한 세부 사항은 리눅스 맨페이지 프로젝트의 -[sysctl.d(5)](https://man7.org/linux/man-pages/man5/sysctl.d.5.html) 페이지를 참고한다. -파드와 파드시큐리티폴리시(PodSecurityPolicy)에 대해 sysctl을 설정하는 기능에서는 -아직 슬래시 구분자를 지원하지 않는다. +[sysctl.d(5)](https://man7.org/linux/man-pages/man5/sysctl.d.5.html) 페이지를 참고한다. {{< /note >}} ## {{% heading "prerequisites" %}} @@ -176,55 +175,3 @@ sysctl 설정이 필요한 노드에만 파드를 예약하는 것이 좋다. [노드 테인트](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)를 사용하여 해당 파드를 오른쪽 노드에 스케줄하는 것을 추천한다. - -## 파드시큐리티폴리시(PodSecurityPolicy) - -{{< feature-state for_k8s_version="v1.21" state="deprecated" >}} - -또한 파드시큐리티폴리시의 `forbiddenSysctls` 및/또는 `allowedUnsafeSysctls` 필드에 -sysctl 또는 sysctl 패턴 목록을 지정하여 파드에서 설정할 -수 있는 sysctl를 제어할 수 있다. sysctl 패턴은 `kernel.*`과 같은 `*` -문자로 끝난다. `*` 문자 자체는 -모든 sysctl와 일치한다. - -기본적으로 모든 safe sysctl은 허용된다. - -`forbiddenSysctls`와 `allowedUnsafeSysctls`는 모두 단순한 sysctl 이름 또는 -sysctl 패턴 목록이다(`*`로 끝남). `*` 문자는 모든 sysctl과 일치한다. - -`forbiddenSysctls` 필드에는 특정 sysctl이 제외된다. -목록에서 safe sysctl과 unsafe sysctl의 조합을 금지할 수 있다. -sysctl 설정을 금지하기 위해서는 `*`를 사용한다. - -`allowedUnsafeSysctls` 필드에 unsafe sysctl을 지정하고 `forbiddenSysctls` 필드가 -존재하지 않는 경우, 파드시큐리티폴리시를 사용하여 -sysctl을 파드에서 사용할 수 있다. -파드시큐리티폴리시의 모든 unsafe sysctl을 설정하려면 `*`를 사용한다. - -이 두 필드를 겹치도록 구성하지 않는다. -이는 지정된 sysctl이 허용 및 금지됨을 의미한다. - -{{< warning >}} -파드시큐리티폴리시의 'allowedUnsafeSysctls' 필드를 통해 unsafe sysctl을 -허용하는 경우, 해당 노드에서 sysctl이 -'--allowed-unsafe-sysctls' kubelet 플래그를 통해 허용되지 않으면, -sysctl을 사용하는 모든 파드가 시작에 실패한다. -{{< /warning >}} - -이 예에서는 `kernel.msg` 접두사가 붙은 unsafe sysctl을 설정할 수 있으며, -`kernel.shm_rmid_forced` sysctl의 설정을 허용하지 않는다. - -```yaml -apiVersion: policy/v1beta1 -kind: PodSecurityPolicy -metadata: - name: sysctl-psp -spec: - allowedUnsafeSysctls: - - kernel.msg* - forbiddenSysctls: - - kernel.shm_rmid_forced - ... -``` - - diff --git a/content/ko/docs/tasks/configure-pod-container/static-pod.md b/content/ko/docs/tasks/configure-pod-container/static-pod.md index 3e3e21ceea..a34628eed3 100644 --- a/content/ko/docs/tasks/configure-pod-container/static-pod.md +++ b/content/ko/docs/tasks/configure-pod-container/static-pod.md @@ -182,7 +182,7 @@ static-web 1/1 Running 0 2m ``` {{< note >}} -Kubelet에 API 서버에서 미러 파드를 생성할 수 있는 권한이 있는지 미리 확인해야 한다. 그렇지 않을 경우 API 서버에 의해서 생성 요청이 거부된다. [파드 시큐리티 어드미션](/docs/concepts/security/pod-security-admission/) 및 [파드시큐리티폴리시(PodSecurityPolicy)](/ko/docs/concepts/security/pod-security-policy/)를 확인한다. +API 서버에서 미러 파드를 생성할 수 있는 권한이 kubelet에게 있는지 미리 확인해야 한다. 그렇지 않을 경우 API 서버에 의해서 생성 요청이 거부된다. {{< /note >}} 스태틱 파드에 있는 {{< glossary_tooltip term_id="label" text="레이블" >}} 은 diff --git a/content/ko/docs/tasks/debug/debug-application/debug-running-pod.md b/content/ko/docs/tasks/debug/debug-application/debug-running-pod.md index 59484f3abb..90e3cc86b4 100644 --- a/content/ko/docs/tasks/debug/debug-application/debug-running-pod.md +++ b/content/ko/docs/tasks/debug/debug-application/debug-running-pod.md @@ -378,7 +378,7 @@ kubectl exec -it cassandra -- sh ## 임시(ephemeral) 디버그 컨테이너를 사용해서 디버깅하기 {#ephemeral-container} -{{< feature-state state="beta" for_k8s_version="v1.23" >}} +{{< feature-state state="stable" for_k8s_version="v1.25" >}} 컨테이너가 크래시 됐거나 [distroless 이미지](https://github.com/GoogleContainerTools/distroless)처럼 @@ -392,7 +392,7 @@ kubectl exec -it cassandra -- sh 먼저, 다음과 같이 파드를 추가한다. ```shell -kubectl run ephemeral-demo --image=k8s.gcr.io/pause:3.1 --restart=Never +kubectl run ephemeral-demo --image=registry.k8s.io/pause:3.1 --restart=Never ``` 이 섹션의 예시에서는 디버깅 도구가 포함되지 않은 이미지의 사례를 보여드리기 위해 @@ -611,7 +611,7 @@ kubectl delete pod myapp myapp-debug ## 노드의 쉘을 사용해서 디버깅하기 {#node-shell-session} 만약 위의 어떠한 방법도 사용할 수 없다면, 파드가 현재 동작 중인 노드를 찾아 -호스트의 네임스페이스로 동작하는 특권 파드를 생성할 수 있다. +해당 노드에서 실행되는 파드를 생성할 수 있다. 다음 `kubectl debug` 명령을 통해 해당 노드에서 인터랙티브한 쉘을 생성할 수 있다. ```shell @@ -628,8 +628,9 @@ root@ek8s:/# * `kubectl debug`는 노드의 이름에 기반해 새로운 파드의 이름을 자동으로 생성한다. -* 컨테이너는 호스트 네임스페이스(IPC, 네트워크, PID 네임스페이스)에서 동작한다. * 노드의 루트 파일시스템은 `/host`에 마운트된다. +* 파드가 특권을 가지고 있지 않더라도, 컨테이너는 호스트 네임스페이스(IPC, 네트워크, PID 네임스페이스)에서 동작한다. 따라서 몇몇 프로세스 정보를 읽어오거나, `chroot /host` 등의 작업은 수행될 수 없다. +* 특권을 가진 파드가 필요한 경우에는 직접 생성한다. 사용이 모두 끝나면, 디버깅에 사용된 파드를 잊지 말고 정리한다. diff --git a/content/ko/docs/tasks/extend-kubernetes/setup-extension-api-server.md b/content/ko/docs/tasks/extend-kubernetes/setup-extension-api-server.md index bd7f8b3742..9d9f34ff16 100644 --- a/content/ko/docs/tasks/extend-kubernetes/setup-extension-api-server.md +++ b/content/ko/docs/tasks/extend-kubernetes/setup-extension-api-server.md @@ -25,7 +25,7 @@ weight: 15 -## 애그리게이션 레이어와 작동하도록 확장 API 서버 설정 +## 애그리게이션 레이어와 작동하도록 확장 API 서버 설정하기 다음 단계는 확장 API 서버를 *높은 수준* 으로 설정하는 방법을 설명한다. 이 단계는 YAML 구성을 사용하거나 API를 사용하는 것에 상관없이 적용된다. 둘 사이의 차이점을 구체적으로 식별하려고 시도한다. YAML 구성을 사용하여 구현하는 방법에 대한 구체적인 예를 보려면, 쿠버네티스 리포지터리에서 [sample-apiserver](https://github.com/kubernetes/sample-apiserver/blob/master/README.md)를 참고할 수 있다. diff --git a/content/ko/docs/tasks/inject-data-application/define-command-argument-container.md b/content/ko/docs/tasks/inject-data-application/define-command-argument-container.md index e785dcf39b..19eafd4b6c 100644 --- a/content/ko/docs/tasks/inject-data-application/define-command-argument-container.md +++ b/content/ko/docs/tasks/inject-data-application/define-command-argument-container.md @@ -46,33 +46,33 @@ weight: 10 1. YAML 구성 파일을 활용해 파드를 생성한다. - ```shell - kubectl apply -f https://k8s.io/examples/pods/commands.yaml - ``` + ```shell + kubectl apply -f https://k8s.io/examples/pods/commands.yaml + ``` 1. 실행 중인 파드들의 목록을 조회한다. - ```shell - kubectl get pods - ``` + ```shell + kubectl get pods + ``` - 출력은 command-demo라는 파드 안에서 실행된 컨테이너가 완료되었다고 표시할 - 것이다. + command-demo라는 파드 안에서 실행된 컨테이너가 완료되었다고 출력될 + 것이다. 1. 컨테이너 안에서 실행된 커맨드의 출력을 보기 위해, 파드의 로그를 확인한다. - ```shell - kubectl logs command-demo - ``` + ```shell + kubectl logs command-demo + ``` - 출력은 HOSTNAME과 KUBERNETES_PORT 환경 변수들의 값들을 표시할 - 것이다. + HOSTNAME과 KUBERNETES_PORT 환경 변수들의 값들이 출력될 + 것이다. - ``` - command-demo - tcp://10.3.240.1:443 - ``` + ``` + command-demo + tcp://10.3.240.1:443 + ``` ## 인자를 정의하기 위해 환경 변수를 사용하기 diff --git a/content/ko/docs/tasks/inject-data-application/define-environment-variable-container.md b/content/ko/docs/tasks/inject-data-application/define-environment-variable-container.md index 40272c3060..5bac138105 100644 --- a/content/ko/docs/tasks/inject-data-application/define-environment-variable-container.md +++ b/content/ko/docs/tasks/inject-data-application/define-environment-variable-container.md @@ -30,39 +30,39 @@ weight: 20 1. YAML 구성 파일을 활용해 파드를 생성한다. - ```shell - kubectl apply -f https://k8s.io/examples/pods/inject/envars.yaml - ``` + ```shell + kubectl apply -f https://k8s.io/examples/pods/inject/envars.yaml + ``` 1. 실행 중인 파드들의 목록을 조회한다. - ```shell - kubectl get pods -l purpose=demonstrate-envars - ``` + ```shell + kubectl get pods -l purpose=demonstrate-envars + ``` - 출력은 아래와 비슷할 것이다. + 결과는 다음과 같다. - ``` - NAME READY STATUS RESTARTS AGE - envar-demo 1/1 Running 0 9s - ``` + ``` + NAME READY STATUS RESTARTS AGE + envar-demo 1/1 Running 0 9s + ``` 1. 파드의 컨테이너 환경 변수를 나열한다. - ```shell - kubectl exec envar-demo -- printenv - ``` + ```shell + kubectl exec envar-demo -- printenv + ``` - 출력은 아래와 비슷할 것이다. + 결과는 다음과 같다. - ``` - NODE_VERSION=4.4.2 - EXAMPLE_SERVICE_PORT_8080_TCP_ADDR=10.3.245.237 - HOSTNAME=envar-demo - ... - DEMO_GREETING=Hello from the environment - DEMO_FAREWELL=Such a sweet sorrow - ``` + ``` + NODE_VERSION=4.4.2 + EXAMPLE_SERVICE_PORT_8080_TCP_ADDR=10.3.245.237 + HOSTNAME=envar-demo + ... + DEMO_GREETING=Hello from the environment + DEMO_FAREWELL=Such a sweet sorrow + ``` {{< note >}} `env` 나 `envFrom` 필드를 이용해 설정된 환경 변수들은 컨테이너 이미지 diff --git a/content/ko/docs/tasks/inject-data-application/define-interdependent-environment-variables.md b/content/ko/docs/tasks/inject-data-application/define-interdependent-environment-variables.md index 54e809cf00..5828606894 100644 --- a/content/ko/docs/tasks/inject-data-application/define-interdependent-environment-variables.md +++ b/content/ko/docs/tasks/inject-data-application/define-interdependent-environment-variables.md @@ -20,50 +20,55 @@ weight: 20 ## 컨테이너를 위한 종속 환경 변수 정의하기 -파드를 생성할 때, 파드 안에서 동작하는 컨테이너를 위한 종속 환경 변수를 설정할 수 있다. -종속 환경 변수를 설정하려면, 구성 파일에서 `env`의 `value`에 $(VAR_NAME)을 사용한다. +파드를 생성할 때, 파드 안에서 동작하는 컨테이너를 위한 종속 환경 변수를 설정할 수 있다. 종속 환경 변수를 설정하려면, 구성 파일에서 `env`의 `value`에 $(VAR_NAME)을 사용한다. -이 예제에서, 한 개의 컨테이너를 실행하는 파드를 생성한다. 파드를 위한 구성 파일은 일반적인 방식으로 정의된 종속 환경 변수를 정의한다. 다음은 파드를 위한 구성 매니페스트 예시이다. +이 예제에서는 한 개의 컨테이너를 실행하는 파드를 생성한다. +파드를 위한 구성 파일은 일반적인 방식으로 정의된 종속 환경 변수를 정의한다. +다음은 파드를 위한 구성 매니페스트 예시이다. {{< codenew file="pods/inject/dependent-envars.yaml" >}} 1. YAML 구성 파일을 활용해 파드를 생성한다. - ```shell - kubectl apply -f https://k8s.io/examples/pods/inject/dependent-envars.yaml - ``` - ``` - pod/dependent-envars-demo created - ``` + ```shell + kubectl apply -f https://k8s.io/examples/pods/inject/dependent-envars.yaml + ``` + ``` + pod/dependent-envars-demo created + ``` 2. 실행 중인 파드의 목록을 조회한다. - ```shell - kubectl get pods dependent-envars-demo - ``` - ``` - NAME READY STATUS RESTARTS AGE - dependent-envars-demo 1/1 Running 0 9s - ``` + ```shell + kubectl get pods dependent-envars-demo + ``` + ``` + NAME READY STATUS RESTARTS AGE + dependent-envars-demo 1/1 Running 0 9s + ``` 3. 파드 안에서 동작 중인 컨테이너의 로그를 확인한다. - ```shell - kubectl logs pod/dependent-envars-demo - ``` - ``` + ```shell + kubectl logs pod/dependent-envars-demo + ``` + ``` - UNCHANGED_REFERENCE=$(PROTOCOL)://172.17.0.1:80 - SERVICE_ADDRESS=https://172.17.0.1:80 - ESCAPED_REFERENCE=$(PROTOCOL)://172.17.0.1:80 - ``` + UNCHANGED_REFERENCE=$(PROTOCOL)://172.17.0.1:80 + SERVICE_ADDRESS=https://172.17.0.1:80 + ESCAPED_REFERENCE=$(PROTOCOL)://172.17.0.1:80 + ``` 위에서 보듯이, `SERVICE_ADDRESS`는 올바른 종속성 참조, `UNCHANGED_REFERENCE`는 잘못된 종속성 참조를 정의했으며 `ESCAPED_REFERENCE`는 종속성 참조를 건너뛴다. -환경 변수가 참조될 때 해당 환경 변수가 미리 정의되어 있으면 `SERVICE_ADDRESS`의 경우와 같이 참조를 올바르게 해석할 수 있다. +미리 정의된 환경 변수를 참조할 때는, +`SERVICE_ADDRESS`의 경우와 같이 참조를 올바르게 해석할 수 있다. -환경 변수가 정의되지 않았거나 일부 변수만 포함된 경우, 정의되지 않은 환경 변수는 `UNCHANGED_REFERENCE`의 경우와 같이 일반 문자열로 처리된다. -일반적으로 환경 변수 해석에 실패하더라도 컨테이너의 시작을 막지는 않는다. +`env` 목록 안에서의 순서가 영향을 준다는 것을 주의하자. +목록에서 더 아래쪽에 명시된 환경 변수는, "정의된" 것으로 보지 않는다. +이것이 바로 위의 예시에서 `UNCHANGED_REFERENCE`가 `$(PROTOCOL)`을 해석하지 못한 이유이다. + +환경 변수가 정의되지 않았거나 일부 변수만 포함된 경우, 정의되지 않은 환경 변수는 `UNCHANGED_REFERENCE`의 경우와 같이 일반 문자열로 처리된다. 일반적으로 환경 변수 해석에 실패하더라도 컨테이너의 시작을 막지는 않는다. `$(VAR_NAME)` 구문은 이중 $로 이스케이프될 수 있다. (예: `$$(VAR_NAME)`) 이스케이프된 참조는 참조된 변수가 정의되었는지 여부에 관계없이 해석을 수행하지 않는다. diff --git a/content/ko/docs/tasks/inject-data-application/distribute-credentials-secure.md b/content/ko/docs/tasks/inject-data-application/distribute-credentials-secure.md index 0ff081f99a..f539b8103a 100644 --- a/content/ko/docs/tasks/inject-data-application/distribute-credentials-secure.md +++ b/content/ko/docs/tasks/inject-data-application/distribute-credentials-secure.md @@ -9,6 +9,7 @@ min-kubernetes-server-version: v1.6 본 페이지는 암호 및 암호화 키와 같은 민감한 데이터를 파드에 안전하게 주입하는 방법을 설명한다. + ## {{% heading "prerequisites" %}} @@ -42,44 +43,44 @@ echo -n '39528$vdg7Jb' | base64 1. 시크릿을 생성한다. - ```shell - kubectl apply -f https://k8s.io/examples/pods/inject/secret.yaml - ``` + ```shell + kubectl apply -f https://k8s.io/examples/pods/inject/secret.yaml + ``` 2. 시크릿에 대한 정보를 확인한다. - ```shell - kubectl get secret test-secret - ``` + ```shell + kubectl get secret test-secret + ``` - Output: + 결과는 다음과 같다. - ``` - NAME TYPE DATA AGE - test-secret Opaque 2 1m - ``` + ``` + NAME TYPE DATA AGE + test-secret Opaque 2 1m + ``` 3. 시크릿에 대한 자세한 정보를 확인한다. - ```shell - kubectl describe secret test-secret - ``` + ```shell + kubectl describe secret test-secret + ``` - Output: + 결과는 다음과 같다. - ``` - Name: test-secret - Namespace: default - Labels: - Annotations: + ``` + Name: test-secret + Namespace: default + Labels: + Annotations: - Type: Opaque + Type: Opaque - Data - ==== - password: 13 bytes - username: 7 bytes - ``` + Data + ==== + password: 13 bytes + username: 7 bytes + ``` ### kubectl로 직접 시크릿 생성하기 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 97db3f944b..105eba0d3c 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 @@ -13,7 +13,7 @@ weight: 40 쿠버네티스에는 실행 중인 컨테이너에 파드 필드 및 컨테이너 필드를 노출하는 두 가지 방법이 있다. -* [환경 변수](/ko/docs/tasks/inject-data-application/environment-variable-expose-pod-information/#다운워드-downward-api) +* [환경 변수](/ko/docs/tasks/inject-data-application/environment-variable-expose-pod-information/) * 볼륨 파일 파드 및 컨테이너 필드를 노출하는 이 두 가지 방법을 @@ -161,11 +161,14 @@ total 8 단일 컨테이너는 `/etc/podinfo`에 볼륨을 마운트하는 것을 확인할 수 있다. -`downwardAPI` 아래의 `items` 배열을 살펴보자. 배열의 각 요소는 downward API 볼륨의 파일을 의미한다. +`downwardAPI` 아래의 `items` 배열을 살펴보자. +배열의 각 요소는 downward API 볼륨의 파일을 의미한다. 첫 번째 요소는 `client-container`라는 컨테이너에서 `1m`으로 지정된 형식의 `limits.cpu` 필드 값이 -`cpu_limit`이라는 파일에 배포되어야 함을 지정한다. `divisor` 필드는 선택 사항이다. divisor 1은 `cpu` 리소스를 위한 코어 수를 의미하거나 `memory` 리소스에 대한 바이트 수를 의미한다. +`cpu_limit`이라는 파일에 배포되어야 함을 지정한다. +`divisor` 필드는 선택 사항이며, 지정하지 않을 경우 `1`의 값을 갖는다. +divisor 1은 `cpu` 리소스를 위한 코어 수를 의미하거나 `memory` 리소스에 대한 바이트 수를 의미한다. 파드를 생성한다.