[ko] Update outdate files in dev-1.25-ko.1 (M74-M89)
bconfiden2
parent
6d9de69e23
commit
2aafb85f6d
|
|
@ -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 접근
|
||||
|
|
|
|||
|
|
@ -192,12 +192,12 @@ kubectl delete namespaces <insert-some-namespace-name>
|
|||
|
||||
하나의 네임스페이스와 상호 작용하는 사용자는 다른 네임스페이스의 내용을 볼 수 없다.
|
||||
|
||||
이를 보여주기 위해 `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 <insert-some-namespace-name>
|
|||
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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
...
|
||||
```
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -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="레이블" >}} 은
|
||||
|
|
|
|||
|
|
@ -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` 등의 작업은 수행될 수 없다.
|
||||
* 특권을 가진 파드가 필요한 경우에는 직접 생성한다.
|
||||
|
||||
사용이 모두 끝나면, 디버깅에 사용된 파드를 잊지 말고 정리한다.
|
||||
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@ weight: 15
|
|||
|
||||
<!-- steps -->
|
||||
|
||||
## 애그리게이션 레이어와 작동하도록 확장 API 서버 설정
|
||||
## 애그리게이션 레이어와 작동하도록 확장 API 서버 설정하기
|
||||
|
||||
다음 단계는 확장 API 서버를 *높은 수준* 으로 설정하는 방법을 설명한다. 이 단계는 YAML 구성을 사용하거나 API를 사용하는 것에 상관없이 적용된다. 둘 사이의 차이점을 구체적으로 식별하려고 시도한다. YAML 구성을 사용하여 구현하는 방법에 대한 구체적인 예를 보려면, 쿠버네티스 리포지터리에서 [sample-apiserver](https://github.com/kubernetes/sample-apiserver/blob/master/README.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
|
||||
```
|
||||
|
||||
## 인자를 정의하기 위해 환경 변수를 사용하기
|
||||
|
||||
|
|
|
|||
|
|
@ -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` 필드를 이용해 설정된 환경 변수들은 컨테이너 이미지
|
||||
|
|
|
|||
|
|
@ -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)`)
|
||||
이스케이프된 참조는 참조된 변수가 정의되었는지 여부에 관계없이 해석을 수행하지 않는다.
|
||||
|
|
|
|||
|
|
@ -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: <none>
|
||||
Annotations: <none>
|
||||
```
|
||||
Name: test-secret
|
||||
Namespace: default
|
||||
Labels: <none>
|
||||
Annotations: <none>
|
||||
|
||||
Type: Opaque
|
||||
Type: Opaque
|
||||
|
||||
Data
|
||||
====
|
||||
password: 13 bytes
|
||||
username: 7 bytes
|
||||
```
|
||||
Data
|
||||
====
|
||||
password: 13 bytes
|
||||
username: 7 bytes
|
||||
```
|
||||
|
||||
### kubectl로 직접 시크릿 생성하기
|
||||
|
||||
|
|
|
|||
|
|
@ -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` 리소스에 대한 바이트 수를 의미한다.
|
||||
|
||||
파드를 생성한다.
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue