Sixth Korean l10n work for release 1.18
- Update outdated files in dev-1.18-ko.6 partly (#21714) - Translate StorageClass to Korean word (#21805) - Translate StatefulSet to Korean word in pods.md (#21794) - Translate tasks/run-application/delete-stateful-set/ in Korean (#21686) - Translate tasks/administer-cluster/change-default-storage-class in Korean (#21801) - update outdated docs (#21940) - Modify spacing term StatefulSet in Korean (#21871) - Translate /tasks/administer-cluster/coredns in Korean (#21876) - Fix typo in k8s.io/ko/docs/contribute/new-content/new-content/ (#21975) - Translation error correction in /concepts/containers/runtime-class.md (#21868) - Translate tasks/tls/certificate-rotation/ in Korean (#21838) - Translate /tasks/configure-pod-container/static-pod in Korean (#21798) - Update to Outdated files in the dev-1.18-ko.6 branch - (1/4) (#21911) - Fix English bugs in Korean documentation (#21994) - Update outdated dev-1.18-ko.6 partly (#22067) Co-authored-by: Jerry Park <jaehwa@gmail.com> Co-authored-by: PyungHo Yoon <learder@gmail.com> Co-authored-by: Yuk, Yongsu <ysyukr@gmail.com> Co-authored-by: Jerry Park <jaehwa@gmail.com> Co-authored-by: Seokho Son <shsongist@gmail.com> Co-authored-by: Jordy Ruiter <jordy.ruiter@gmail.com> Co-authored-by: bluefriday <bluefriday86@gmail.com> Co-authored-by: Dajin Gwon <d.gweon@samsung.com> Co-authored-by: Hyungseok Lee <hs0426.lee@samsung.com> Co-authored-by: Jihoon Seo <jihoon.seo@etri.re.kr> Co-authored-by: coolguyhong <podolsmith@naver.com> Co-authored-by: jmyung <jesang.myung@gmail.com> Co-authored-by: June Yi <june.yi@samsung.com>
This commit is contained in:
June Yi
+1
-1
@@ -6,7 +6,7 @@ weight: 110
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
이 페이지에서는 동일한 파드(Pod)에서 실행 중인 두 개의 컨테이너 간에 통신할 때에, 어떻게 볼륨(Volume)을 이용하는지
|
||||
이 페이지에서는 동일한 파드에서 실행 중인 두 개의 컨테이너 간에 통신할 때에, 어떻게 볼륨을 이용하는지
|
||||
살펴본다. 컨테이너 간에 [프로세스 네임스페이스 공유하기](/docs/tasks/configure-pod-container/share-process-namespace/)를 통해 통신할 수 있는 방법을 참고하자.
|
||||
|
||||
|
||||
|
||||
+46
-41
@@ -10,14 +10,14 @@ card:
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
이 페이지에서는 구성 파일을 사용하여 다수의 클러스터에 접근할 수 있도록
|
||||
설정하는 방식을 보여준다. 클러스터, 사용자, 컨텍스트가 하나 이상의
|
||||
구성 파일에 정의된 다음 `kubectl config use-context` 커맨드를
|
||||
이 페이지에서는 구성 파일을 사용하여 다수의 클러스터에 접근할 수 있도록
|
||||
설정하는 방식을 보여준다. 클러스터, 사용자, 컨텍스트가 하나 이상의
|
||||
구성 파일에 정의된 다음 `kubectl config use-context` 커맨드를
|
||||
사용하여 클러스터를 빠르게 변경할 수 있다.
|
||||
|
||||
{{< note >}}
|
||||
클러스터에 접근할 수 있도록 설정하는데 사용되는 파일은 종종 *kubeconfig file* 이라고
|
||||
불린다. 이는 구성 파일을 참조하는 일반적인 방식으로 `kubeconfig`라는 이름을 가진 파일이
|
||||
클러스터에 접근할 수 있도록 설정하는데 사용되는 파일은 종종 *kubeconfig file* 이라고
|
||||
불린다. 이는 구성 파일을 참조하는 일반적인 방식으로 `kubeconfig`라는 이름을 가진 파일이
|
||||
반드시 존재해야 한다는 것을 의미하는 것은 아니다.
|
||||
{{< /note >}}
|
||||
|
||||
@@ -26,7 +26,12 @@ card:
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
{{< include "task-tutorial-prereqs.md" >}}
|
||||
|
||||
{{< glossary_tooltip text="kubectl" term_id="kubectl" >}}이 설치되었는지 확인하려면,
|
||||
`kubectl version --client`을 실행한다. kubectl 버전은 클러스터의 API 서버 버전과
|
||||
[마이너 버전 하나 차이 이내](/ko/docs/setup/release/version-skew-policy/#kubectl)여야
|
||||
한다.
|
||||
|
||||
|
||||
|
||||
@@ -34,14 +39,14 @@ card:
|
||||
|
||||
## 클러스터, 사용자, 컨텍스트 정의
|
||||
|
||||
당신이 개발 작업을 위한 클러스터와 스크래치 작업을 위한 클러스터를 가지고 있다고 가정해보자.
|
||||
`development` 클러스터에서는 프런트 엔드 개발자들이 `frontend`라는 네임스페이스에서
|
||||
작업을 하고 있고, 스토리지 개발자들은 `storage`라는 네임스페이스에서 작업을 하고 있다.
|
||||
`scratch` 클러스터에서는 개발자들이 default 네임스페이스에서 개발하거나 필요에 따라 보조
|
||||
네임스페이스들을 생성하고 있다. development 클러스터에 접근하려면 인증서로 인증을 해야 하고,
|
||||
당신이 개발 작업을 위한 클러스터와 스크래치 작업을 위한 클러스터를 가지고 있다고 가정해보자.
|
||||
`development` 클러스터에서는 프런트 엔드 개발자들이 `frontend`라는 네임스페이스에서
|
||||
작업을 하고 있고, 스토리지 개발자들은 `storage`라는 네임스페이스에서 작업을 하고 있다.
|
||||
`scratch` 클러스터에서는 개발자들이 default 네임스페이스에서 개발하거나 필요에 따라 보조
|
||||
네임스페이스들을 생성하고 있다. development 클러스터에 접근하려면 인증서로 인증을 해야 하고,
|
||||
scratch 클러스터에 접근하려면 사용자네임과 패스워드로 인증을 해야 한다.
|
||||
|
||||
`config-exercise`라는 디렉토리를 생성한다. `config-exercise` 디렉토리에
|
||||
`config-exercise`라는 디렉토리를 생성한다. `config-exercise` 디렉토리에
|
||||
다음 내용을 가진 `config-demo`라는 파일을 생성한다.
|
||||
|
||||
```shell
|
||||
@@ -68,10 +73,10 @@ contexts:
|
||||
name: exp-scratch
|
||||
```
|
||||
|
||||
구성 파일은 클러스터들, 사용자들, 컨텍스트들을 기술한다. `config-demo` 파일은 두 클러스터들과
|
||||
구성 파일은 클러스터들, 사용자들, 컨텍스트들을 기술한다. `config-demo` 파일은 두 클러스터들과
|
||||
두 사용자들, 세 컨텍스트들을 기술하기 위한 프레임워크를 가진다.
|
||||
|
||||
`config-exercise` 디렉토리로 이동한다. 그리고 다음 커맨드들을 실행하여 구성 파일에 클러스터의
|
||||
`config-exercise` 디렉토리로 이동한다. 그리고 다음 커맨드들을 실행하여 구성 파일에 클러스터의
|
||||
세부사항들을 추가한다.
|
||||
|
||||
```shell
|
||||
@@ -100,7 +105,7 @@ kubectl config --kubeconfig=config-demo set-context dev-storage --cluster=develo
|
||||
kubectl config --kubeconfig=config-demo set-context exp-scratch --cluster=scratch --namespace=default --user=experimenter
|
||||
```
|
||||
|
||||
`config-demo` 파일을 열어서 세부사항들이 추가되었는지 확인한다. `config-demo` 파일을 열어보는
|
||||
`config-demo` 파일을 열어서 세부사항들이 추가되었는지 확인한다. `config-demo` 파일을 열어보는
|
||||
것 대신에 `config view` 커맨드를 사용할 수도 있다.
|
||||
|
||||
```shell
|
||||
@@ -150,16 +155,16 @@ users:
|
||||
username: exp
|
||||
```
|
||||
|
||||
위 `fake-ca-file`, `fake-cert-file`, `fake-key-file`은 인증서 파일들의 실제 경로 이름을 위한
|
||||
플레이스홀더(placeholder)이다.
|
||||
위 `fake-ca-file`, `fake-cert-file`, `fake-key-file`은 인증서 파일들의 실제 경로 이름을 위한
|
||||
플레이스홀더(placeholder)이다.
|
||||
당신의 환경에 맞게 이들을 실제 인증서 경로로 변경해줘야 한다.
|
||||
|
||||
만약 당신이 인증서 파일들의 경로 대신에 여기에 포함된 base64로 인코딩된 데이터를 사용하려고 한다면
|
||||
이 경우 키에 `-data` 접미사를 추가해야 한다. 예를 들면 `certificate-authority-data`,
|
||||
만약 당신이 인증서 파일들의 경로 대신에 여기에 포함된 base64로 인코딩된 데이터를 사용하려고 한다면
|
||||
이 경우 키에 `-data` 접미사를 추가해야 한다. 예를 들면 `certificate-authority-data`,
|
||||
`client-certificate-data`, `client-key-data` 같이 사용할 수 있다.
|
||||
|
||||
컨텍스트는 세 가지(클러스터, 사용자, 네임스페이스) 요소들로 이뤄진다. 예를 들어
|
||||
`dev-frontend` 컨텍스트는 "`development` 클러스터의 `frontend` 네임스페이스에 접근하는데
|
||||
컨텍스트는 세 가지(클러스터, 사용자, 네임스페이스) 요소들로 이뤄진다. 예를 들어
|
||||
`dev-frontend` 컨텍스트는 "`development` 클러스터의 `frontend` 네임스페이스에 접근하는데
|
||||
`developer` 사용자 자격증명을 사용하라고 알려준다."
|
||||
|
||||
현재 컨텍스트를 설정한다.
|
||||
@@ -168,11 +173,11 @@ users:
|
||||
kubectl config --kubeconfig=config-demo use-context dev-frontend
|
||||
```
|
||||
|
||||
이제 당신이 `kubectl` 커맨드를 입력할 때마다 `dev-frontend` 컨텍스트에 명시된 클러스터와
|
||||
네임스페이스 상에서 동작하게 될 것이다. 그리고 커맨드는 `dev-frontend` 컨텍스트 내에 명시된
|
||||
이제 당신이 `kubectl` 커맨드를 입력할 때마다 `dev-frontend` 컨텍스트에 명시된 클러스터와
|
||||
네임스페이스 상에서 동작하게 될 것이다. 그리고 커맨드는 `dev-frontend` 컨텍스트 내에 명시된
|
||||
사용자 자격증명을 사용할 것이다.
|
||||
|
||||
현재 컨텍스트에 관련된 구성 정보만을 보려면
|
||||
현재 컨텍스트에 관련된 구성 정보만을 보려면
|
||||
`--minify` 플래그를 사용한다.
|
||||
|
||||
```shell
|
||||
@@ -212,8 +217,8 @@ users:
|
||||
kubectl config --kubeconfig=config-demo use-context exp-scratch
|
||||
```
|
||||
|
||||
이제 당신이 실행하는 모든 `kubectl` 커맨드는 `scratch` 클러스터의
|
||||
default 네임스페이스에 적용되며 `exp-scratch` 컨텍스트에 나열된
|
||||
이제 당신이 실행하는 모든 `kubectl` 커맨드는 `scratch` 클러스터의
|
||||
default 네임스페이스에 적용되며 `exp-scratch` 컨텍스트에 나열된
|
||||
사용자의 자격증명을 사용할 것이다.
|
||||
|
||||
현재의 컨텍스트인 `exp-scratch`에 관련된 설정을 보자.
|
||||
@@ -222,7 +227,7 @@ default 네임스페이스에 적용되며 `exp-scratch` 컨텍스트에 나열
|
||||
kubectl config --kubeconfig=config-demo view --minify
|
||||
```
|
||||
|
||||
마지막으로 당신이 `development` 클러스터의 `storage` 네임스페이스에서
|
||||
마지막으로 당신이 `development` 클러스터의 `storage` 네임스페이스에서
|
||||
잠시 작업을 하려고 한다고 가정해보자.
|
||||
|
||||
현재 컨텍스트를 `dev-storage`로 변경한다.
|
||||
@@ -259,7 +264,7 @@ contexts:
|
||||
|
||||
## KUBECONFIG 환경 변수 설정
|
||||
|
||||
`KUBECONFIG`라는 환경 변수를 가지고 있는지 확인해보자. 만약 가지고 있다면,
|
||||
`KUBECONFIG`라는 환경 변수를 가지고 있는지 확인해보자. 만약 가지고 있다면,
|
||||
이후에 복원할 수 있도록 `KUBECONFIG` 환경 변수의 현재 값을 저장한다.
|
||||
예:
|
||||
|
||||
@@ -271,9 +276,9 @@ export KUBECONFIG_SAVED=$KUBECONFIG
|
||||
```shell
|
||||
$Env:KUBECONFIG_SAVED=$ENV:KUBECONFIG
|
||||
```
|
||||
`KUBECONFIG` 환경 변수는 구성 파일들의 경로의 리스트이다. 이 리스트는
|
||||
Linux와 Mac에서는 콜론으로 구분되며 Windows에서는 세미콜론으로 구분된다.
|
||||
`KUBECONFIG` 환경 변수를 가지고 있다면, 리스트에 포함된 구성 파일들에
|
||||
`KUBECONFIG` 환경 변수는 구성 파일들의 경로의 리스트이다. 이 리스트는
|
||||
Linux와 Mac에서는 콜론으로 구분되며 Windows에서는 세미콜론으로 구분된다.
|
||||
`KUBECONFIG` 환경 변수를 가지고 있다면, 리스트에 포함된 구성 파일들에
|
||||
익숙해지길 바란다.
|
||||
|
||||
다음 예와 같이 임시로 `KUBECONFIG` 환경 변수에 두 개의 경로들을 덧붙여보자.
|
||||
@@ -293,9 +298,9 @@ $Env:KUBECONFIG=("config-demo;config-demo-2")
|
||||
kubectl config view
|
||||
```
|
||||
|
||||
당신의 `KUBECONFIG` 환경 변수에 나열된 모든 파일들이 합쳐진 정보가 출력 결과로
|
||||
표시될 것이다. 특히, 합쳐진 정보가 `config-demo-2` 파일의 `dev-ramp-up`
|
||||
컨텍스트와 `config-demo` 파일의 세 개의 컨텍스트들을
|
||||
당신의 `KUBECONFIG` 환경 변수에 나열된 모든 파일들이 합쳐진 정보가 출력 결과로
|
||||
표시될 것이다. 특히, 합쳐진 정보가 `config-demo-2` 파일의 `dev-ramp-up`
|
||||
컨텍스트와 `config-demo` 파일의 세 개의 컨텍스트들을
|
||||
가지고 있다는 것에 주목하길 바란다.
|
||||
|
||||
```shell
|
||||
@@ -322,22 +327,22 @@ contexts:
|
||||
name: exp-scratch
|
||||
```
|
||||
|
||||
kubeconfig 파일들을 어떻게 병합하는지에 대한 상세정보는
|
||||
kubeconfig 파일들을 어떻게 병합하는지에 대한 상세정보는
|
||||
[kubeconfig 파일을 사용하여 클러스터 접근 구성하기](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/)를 참조한다.
|
||||
|
||||
## $HOME/.kube 디렉토리 탐색
|
||||
|
||||
만약 당신이 이미 클러스터를 가지고 있고 `kubectl`을 사용하여
|
||||
해당 클러스터를 제어하고 있다면, 아마 `$HOME/.kube` 디렉토리에 `config`라는
|
||||
만약 당신이 이미 클러스터를 가지고 있고 `kubectl`을 사용하여
|
||||
해당 클러스터를 제어하고 있다면, 아마 `$HOME/.kube` 디렉토리에 `config`라는
|
||||
파일을 가지고 있을 것이다.
|
||||
|
||||
`$HOME/.kube`로 가서 어떤 파일들이 존재하는지 보자.
|
||||
보통 `config`라는 파일이 존재할 것이다. 해당 디렉토리 내에는 다른 구성 파일들도 있을 수 있다.
|
||||
`$HOME/.kube`로 가서 어떤 파일들이 존재하는지 보자.
|
||||
보통 `config`라는 파일이 존재할 것이다. 해당 디렉토리 내에는 다른 구성 파일들도 있을 수 있다.
|
||||
간단하게 말하자면 당신은 이 파일들의 컨텐츠에 익숙해져야 한다.
|
||||
|
||||
## $HOME/.kube/config를 KUBECONFIG 환경 변수에 추가
|
||||
|
||||
당신이 `$HOME/.kube/config` 파일을 가지고 있는데 `KUBECONFIG`
|
||||
당신이 `$HOME/.kube/config` 파일을 가지고 있는데 `KUBECONFIG`
|
||||
환경 변수에 나타나지 않는다면 `KUBECONFIG` 환경 변수에 추가해보자.
|
||||
예:
|
||||
|
||||
@@ -350,7 +355,7 @@ export KUBECONFIG=$KUBECONFIG:$HOME/.kube/config
|
||||
$Env:KUBECONFIG="$Env:KUBECONFIG;$HOME\.kube\config"
|
||||
```
|
||||
|
||||
이제 `KUBECONFIG` 환경 변수에 리스트에 포함된 모든 파일들이 합쳐진 구성 정보를 보자.
|
||||
이제 `KUBECONFIG` 환경 변수에 리스트에 포함된 모든 파일들이 합쳐진 구성 정보를 보자.
|
||||
config-exercise 디렉토리에서 다음 커맨드를 실행한다.
|
||||
|
||||
```shell
|
||||
|
||||
@@ -61,7 +61,7 @@ Kubeconfig 인증 방법은 외부 아이덴티티 프로파이더 또는 x509
|
||||
|
||||
## 컨테이너화 된 애플리케이션 배포
|
||||
|
||||
대시보드를 이용하여 컨테이너화 된 애플리케이션을 디플로이먼트와 간단한 마법사를 통한 선택적인 서비스(Service) 로 생성하고 배포할 수 있다. 애플리케이션 세부 정보를 수동으로 지정할 수 있고, 또는 애플리케이션 구성을 포함한 YAML, JSON 파일을 업로드 할 수 있다.
|
||||
대시보드를 이용하여 컨테이너화 된 애플리케이션을 디플로이먼트와 간단한 마법사를 통한 선택적인 서비스로 생성하고 배포할 수 있다. 애플리케이션 세부 정보를 수동으로 지정할 수 있고, 또는 애플리케이션 구성을 포함한 YAML, JSON 파일을 업로드 할 수 있다.
|
||||
|
||||
시작하는 페이지의 상위 오른쪽 코너에 있는 **CREATE** 버튼을 클릭한다.
|
||||
|
||||
@@ -69,7 +69,7 @@ Kubeconfig 인증 방법은 외부 아이덴티티 프로파이더 또는 x509
|
||||
|
||||
배포 마법사는 다음 정보를 제공한다.
|
||||
|
||||
- **앱 이름** (필수): 애플리케이션 이름. [레이블](/ko/docs/concepts/overview/working-with-objects/labels/) 이름은 배포할 모든 디플로이먼트와 서비스(Service)에 추가되어야 한다.
|
||||
- **앱 이름** (필수): 애플리케이션 이름. [레이블](/ko/docs/concepts/overview/working-with-objects/labels/) 이름은 배포할 모든 디플로이먼트와 서비스에 추가되어야 한다.
|
||||
|
||||
애플리케이션 이름은 선택된 쿠버네티스 [네임스페이스](/docs/tasks/administer-cluster/namespaces/) 안에서 유일해야 한다. 소문자로 시작해야하며, 소문자 또는 숫자로 끝나고, 소문자, 숫자 및 대쉬(-)만을 포함해야한다. 24 문자만을 제한한다. 처음과 끝의 스페이스는 무시된다.
|
||||
|
||||
@@ -79,17 +79,21 @@ Kubeconfig 인증 방법은 외부 아이덴티티 프로파이더 또는 x509
|
||||
|
||||
클러스터에 의도한 파드의 수를 유지하기 위해서 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)가 생성될 것이다.
|
||||
|
||||
- **서비스(Service)** (선택): 일부 애플리케이션의 경우, (예를 들어, 프론트엔드) 아마도 클러스터 바깥의 퍼블릭 IP 주소를 가진 (외부 서비스) 외부에 [서비스(Service)](/ko/docs/concepts/services-networking/service/)를 노출 시키고 싶을 수 있다. 외부 서비스들을 위해, 한개 또는 여러 개의 포트들을 열어 둘 필요가 있다. [이 곳](/docs/tasks/access-application-cluster/configure-cloud-provider-firewall/) 내용을 참고한다.
|
||||
- **서비스** (선택): 일부 애플리케이션의 경우, (예를 들어, 프론트엔드) 아마도 클러스터 바깥의 퍼블릭 IP 주소를 가진 (외부 서비스) 외부에 [서비스](/ko/docs/concepts/services-networking/service/)를 노출 시키고 싶을 수 있다.
|
||||
|
||||
클러스터 내부에서만 보고 싶은 어떤 서비스(Serivce)들이 있을 것인다. 이를 내부 서비스라고 한다.
|
||||
{{< note >}}
|
||||
외부 서비스들을 위해, 한 개 또는 여러 개의 포트를 열어 둘 필요가 있다.
|
||||
{{< /note >}}
|
||||
|
||||
서비스(Service) 타입과는 무관하게, 서비스(Service) 생성을 선택해서 컨테이너의 (들어오는 패킷의) 포트를 리슨한다면, 두 개의 포트를 정의해야 한다. 서비스(Service)는 컨테이너가 바라보는 타겟 포트와 (들어오는 패킷의) 맵핑하는 포트가 만들어져야 할 것이다. 서비스(Service)는 배포된 파드에 라우팅 될 것이다. 지원하는 프로토콜은 TCP와 UDP이다. 서비스(Service)가 이용하는 내부 DNS 이름은 애플리케이션 이름으로 지정한 값이 될 것이다.
|
||||
클러스터 내부에서만 보고 싶은 어떤 서비스들이 있을 것이다. 이를 내부 서비스라고 한다.
|
||||
|
||||
서비스 타입과는 무관하게, 서비스 생성을 선택해서 컨테이너의 (들어오는 패킷의) 포트를 리슨한다면, 두 개의 포트를 정의해야 한다. 서비스는 컨테이너가 바라보는 타겟 포트와 (들어오는 패킷의) 맵핑하는 포트가 만들어져야 할 것이다. 서비스는 배포된 파드에 라우팅 될 것이다. 지원하는 프로토콜은 TCP와 UDP이다. 서비스가 이용하는 내부 DNS 이름은 애플리케이션 이름으로 지정한 값이 될 것이다.
|
||||
|
||||
만약 필요하다면, 더 많은 세팅을 지정할 수 있는 **자세한 옵션 보기** 섹션에서 확장할 수 있다.
|
||||
|
||||
- **설명**: 입력하는 텍스트값은 디플로이먼트에 [어노테이션](/ko/docs/concepts/overview/working-with-objects/annotations/) 으로 추가될 것이고, 애플리케이션의 세부사항에 표시될 것이다.
|
||||
|
||||
- **레이블**: 애플리케이션에 사용되는 기본적인 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)은 애플리케이션 이름과 버전이다. 릴리스, 환경, 티어, 파티션, 그리고 릴리스 트랙과 같은 레이블을 디플로이먼트, 서비스(Service), 그리고 파드를 생성할 때 추가적으로 정의할 수 있다.
|
||||
- **레이블**: 애플리케이션에 사용되는 기본적인 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)은 애플리케이션 이름과 버전이다. 릴리스, 환경, 티어, 파티션, 그리고 릴리스 트랙과 같은 레이블을 디플로이먼트, 서비스, 그리고 파드를 생성할 때 추가적으로 정의할 수 있다.
|
||||
|
||||
예를 들면:
|
||||
|
||||
@@ -119,13 +123,13 @@ track=stable
|
||||
|
||||
- **특권을 가진(privileged) 상태로 실행**: 다음 세팅은 호스트에서 루트 권한을 가진 프로세스들이 [특권을 가진 컨테이너](/docs/user-guide/pods/#privileged-mode-for-pod-containers)의 프로세스들과 동등한 지 아닌지 정의한다. 특권을 가진(privileged) 컨테이너는 네트워크 스택과 디바이스에 접근하는 것을 조작하도록 활용할 수 있다.
|
||||
|
||||
- **환경 변수**: 쿠버네티스 서비스(Service)를 [환경 변수](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)를 통해 노출한다. 환경 변수 또는 인자를 환경 변수들의 값으로 커맨드를 통해 구성할 수 있다. 애플리케이션들이 서비스(Service)를 찾는데 사용된다. 값들은 `$(VAR_NAME)` 구문을 사용하는 다른 변수들로 참조할 수 있다.
|
||||
- **환경 변수**: 쿠버네티스 서비스를 [환경 변수](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)를 통해 노출한다. 환경 변수 또는 인자를 환경 변수들의 값으로 커맨드를 통해 구성할 수 있다. 애플리케이션들이 서비스를 찾는데 사용된다. 값들은 `$(VAR_NAME)` 구문을 사용하는 다른 변수들로 참조할 수 있다.
|
||||
|
||||
### YAML 또는 JSON 파일 업로드
|
||||
|
||||
쿠버네티스는 선언적인 설정을 제공한다. 이 방식으로 모든 설정은 쿠버네티스 [API](/docs/concepts/overview/kubernetes-api/) 리소스 스키마를 이용하여 YAML 또는 JSON 설정 파일에 저장한다.
|
||||
|
||||
배포 마법사를 통해 애플리케이션 세부사항들을 지정하는 대신, 애플리케이션을 YAML 또는 JSON 파일로 정의할 수 있고 대시보드를 이용해서 파일을 업로드할 수 있다.
|
||||
배포 마법사를 통해 애플리케이션 세부사항들을 지정하는 대신, 애플리케이션을 YAML 또는 JSON 파일로 정의할 수 있고 대시보드를 이용해서 파일을 업로드할 수 있다.
|
||||
|
||||
## 대시보드 사용
|
||||
다음 섹션들은 어떻게 제공하고 어떻게 사용할 수 있는지에 대한 쿠버네티스 대시보드 UI의 모습을 보여준다.
|
||||
@@ -140,12 +144,12 @@ track=stable
|
||||
클러스터와 네임스페이스 관리자에게 대시보드는 노드, 네임스페이스 그리고 퍼시스턴트 볼륨과 세부사항들이 보여진다. 노드는 모든 노드를 통틀어 CPU와 메모리 사용량을 보여준다. 세부사항은 각 노드들에 대한 사용량, 사양, 상태, 할당된 리소스, 이벤트 그리고 노드에서 돌아가는 파드를 보여준다.
|
||||
|
||||
#### 워크로드
|
||||
선택된 네임스페이스에서 구동되는 모든 애플리케이션을 보여준다. 애플리케이션의 워크로드 종류(예를 들어, 디플로이먼트, 레플리카 셋, 스테이트풀 셋 등)를 보여주고 각각의 워크로드 종류는 따로 보여진다. 리스트는 예를 들어 레플리카 셋에서 준비된 파드의 숫자 또는 파드의 현재 메모리 사용량과 같은 워크로드에 대한 실용적인 정보를 요약한다.
|
||||
선택된 네임스페이스에서 구동되는 모든 애플리케이션을 보여준다. 애플리케이션의 워크로드 종류(예를 들어, 디플로이먼트, 레플리카 셋, 스테이트풀셋(StatefulSet) 등)를 보여주고 각각의 워크로드 종류는 따로 보여진다. 리스트는 예를 들어 레플리카 셋에서 준비된 파드의 숫자 또는 파드의 현재 메모리 사용량과 같은 워크로드에 대한 실용적인 정보를 요약한다.
|
||||
|
||||
워크로드에 대한 세부적인 것들은 상태와 사양 정보, 오프젝트들 간의 관계를 보여준다. 예를 들어, 레플리카 셋으로 관리하는 파드들 또는 새로운 레플리카 셋과 디플로이먼트를 위한 Horizontal Pod Autoscalers 이다.
|
||||
|
||||
#### 서비스(Service)
|
||||
외부로 노출되는 서비스들과 클러스터 내에 발견되는 서비스들을 허용하는 쿠버네티스 리소스들을 보여준다. 이러한 이유로 서비스(Service)와 인그레스는 클러스터간의 연결을 위한 내부 엔드포인트들과 외부 사용자를 위한 외부 엔드포인트들에 의해 타게팅된 파드들을 보여준다.
|
||||
#### 서비스
|
||||
외부로 노출되는 서비스들과 클러스터 내에 발견되는 서비스들을 허용하는 쿠버네티스 리소스들을 보여준다. 이러한 이유로 서비스와 인그레스는 클러스터간의 연결을 위한 내부 엔드포인트들과 외부 사용자를 위한 외부 엔드포인트들에 의해 타게팅된 파드들을 보여준다.
|
||||
|
||||
#### 스토리지
|
||||
스토리지는 애플리케이션이 데이터를 저장하기 위해 사용하는 퍼시턴트 볼륨 클레임 리소스들을 보여준다.
|
||||
@@ -163,7 +167,7 @@ track=stable
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
더 많은 정보는
|
||||
더 많은 정보는
|
||||
[쿠버네티스 대시보드 프로젝트 페이지](https://github.com/kubernetes/dashboard)를 참고한다.
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user