whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Fourth Korean l10n work for release-1.15 (#16063)

Browse Source 
* ko: update translation in reference/glossary/* (#15776)
* Update outdated files partly in dev-1.15-ko.4 (#15856)
* ko: update translation in tasks/debug-application-cluster/resource-metrics-pipeline (#15798)
* ko: translate setup/production-environment/tools/control-plane-flags (#15820)
* ko: translate user-guide-windows-containers (#15730)
* ko: update translation in reference/glossary/* (#15761)
* ko: Update outdated files partly in dev-1.15-ko.4 (#15790)
* ko: fix corrupt date in glossary/static-pod (#15911)
* ko: translate user-guide-windows-nodes (#15759)
* Translate /docs/concepts/configuration/overview/ in Korean (#15803)
* ko: translate setup/production-environment/tools/ha-topology (#15819)
* ko: translate tasks/administer-cluster/network-policy-provider (#15846)
* Translate tasks/inject-data-application/define-command-argument-container in Korea (#15933)
* ko: translate concepts/configuration/organize-cluster-access-kubeconfig (#15871)
* Translate working-with-objects/common-labels.md in Korean (#15832)
* Translate concepts/workloads/pods/disruptions.md in Korean (#15926)
* Translate tasks/access-application-cluster/web-ui/dashboard in Korean (#15852)
* Translate concepts/overview/working-with-objects/labels.md in Korean (#15831)
* ko: translate guestbook-logs-metrics-with-elk (#15894)
* ko: translate tasks/administer-cluster/highly-available-master (#15928)

Co-Authored-By: Yoon <learder@gmail.com>
Co-Authored-By: Eden <longlg88@naver.com>
Co-Authored-By: Yuk, Yongsu <ysyukr@gmail.com>
Co-Authored-By: June Yi <june.yi@samsung.com>
Co-Authored-By: Seokho Son <shsongist@gmail.com>
Co-Authored-By: Lawrence Kay <lkay9495@hotmail.com>
Co-Authored-By: alice_k106 <alice_k106@naver.com>
Co-Authored-By: Cheolgu Kim <lapee79@gmail.com>
This commit is contained in:
Seokho Son
2019-08-25 20:10:21 +09:00
committed by Kubernetes Prow Robot
parent 270aaf1f16
commit c82a912e29
57 changed files with 2893 additions and 102 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/ko/docs/concepts/overview/components.md
+4 -1
View File
@@ -16,7 +16,7 @@ card:
## 마스터 컴포넌트
마스터 컴포넌트는 클러스터의 컨트롤 플레인을 제공한다. 마스터 컴포넌트는 클러스터에 관한 전반적인 결정
(예를 들어, 스케줄링)을 수행하고 클러스터 이벤트(예를 들어, 레플리케이션 컨트롤러의 `replicas` 필드가 요구조건을 충족되지 않을 경우 새로운 파드를 구동 시키는 것)를 감지하고 반응한다.
(예를 들어, 스케줄링)을 수행하고 클러스터 이벤트(예를 들어, 디플로이먼트의 `replicas` 필드가 요구조건을 충족되지 않을 경우 새로운 {{< glossary_tooltip text="파드" term_id="pod">}}를 구동 시키는 것)를 감지하고 반응한다.
마스터 컴포넌트는 클러스터 내 어떠한 머신에서든지 동작 될 수 있다. 그러나,
간결성을 위하여, 구성 스크립트는 보통 동일 머신 상에 모든 마스터 컴포넌트를 구동시키고,
@@ -110,6 +110,9 @@ cloud-controller-manager는 클라우드 밴더 코드와 쿠버네티스 코드
[클러스터-레벨 로깅](/docs/concepts/cluster-administration/logging/) 메커니즘은
검색/열람 인터페이스와 함께 중앙 로그 저장소에 컨테이너 로그를 저장하는 책임을 가진다.
* [노드](/ko/docs/concepts/architecture/nodes/)에 대해 더 배우기
* [kube-scheduler](/docs/concepts/scheduling/kube-scheduler/)에 대해 더 배우기
* etcd의 공식 [문서](https://etcd.io/docs/) 읽기
{{% /capture %}}
content/ko/docs/concepts/overview/working-with-objects/common-labels.md
+169
View File
@@ -0,0 +1,169 @@
---
title: 권장 레이블
content_template: templates/concept
---
{{% capture overview %}}
kubectl과 대시보드와 같은 많은 도구들로 쿠버네티스 오브젝트를 시각화 하고 관리할 수 있다.
공통 레이블 셋은 모든 도구들이 이해할 수 있는 공통의 방식으로 오브젝트를 식별하고
도구들이 상호 운용적으로 작동할 수 있도록 한다.
권장 레이블은 지원 도구 외에도 쿼리하는 방식으로 애플리케이션을 식별하게 한다.
{{% /capture %}}
{{% capture body %}}
메타데이터는 _애플리케이션_ 의 개념을 중심으로 정리된다.
쿠버네티스는 플랫폼 서비스(PaaS)가 아니며 애플리케이션에 대해 공식적인 개념이 없거나 강요하지 않는다.
대신 애플리케이션은 비공식적이며 메타데이터로 설명된다.
애플리케이션에 포함된 정의는 유연하다.
{{< note >}}
메타데이터들은 권장하는 레이블이다. 애플리케이션을 보다 쉽게 관리할 수 있지만 코어 도구에는 필요하지 않다.
{{< /note >}}
공유 레이블과 주석에는 공통 접두사인 `app.kubernetes.io` 가 있다.
접두사가 없는 레이블은 사용자가 개인적으로 사용할 수 있다.
공유 접두사는 공유 레이블이 사용자 정의 레이블을 방해하지 않도록 한다.
## 레이블
레이블을 최대한 활용하려면 모든 리소스 오브젝트에 적용해야 한다.
| Key | Description | Example | Type |
| ----------------------------------- | --------------------- | -------- | ---- |
| `app.kubernetes.io/name` | 애플리케이션 이름 | `mysql` | 문자열 |
| `app.kubernetes.io/instance` | 애플리케이션의 인스턴스를 식별하는 고유한 이름 | `wordpress-abcxzy` | 문자열 |
| `app.kubernetes.io/version` | 애플리케이션의 현재 버전 (예: a semantic version, revision hash 등.) | `5.7.21` | 문자열 |
| `app.kubernetes.io/component` | 아키텍처 내 구성요소 | `database` | 문자열 |
| `app.kubernetes.io/part-of` | 이 애플리케이션의 전체 이름 | `wordpress` | 문자열 |
| `app.kubernetes.io/managed-by` | 애플리케이션의 작동을 관리하는데 사용되는 도구 | `helm` | 문자열 |
위 레이블의 실제 예시는 다음 스테이트풀셋 오브젝트를 고려한다.
```yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
labels:
app.kubernetes.io/name: mysql
app.kubernetes.io/instance: wordpress-abcxzy
app.kubernetes.io/version: "5.7.21"
app.kubernetes.io/component: database
app.kubernetes.io/part-of: wordpress
app.kubernetes.io/managed-by: helm
```
## 애플리케이션과 애플리케이션 인스턴스
애플리케이션은 때에 따라 쿠버네티스 클러스터의 동일한 네임스페이스에 한번 또는 그 이상 설치할 수 있다.
예를 들어 워드프레스는 다른 워드프레스가 설치되어있는 웹사이트에 한번 한번 또는 그 이상 설치할 수 있다.
애플리케이션의 이름과 인스턴스 이름은 별도로 기록된다.
예를 들어 워드프레스는 `app.kubernetes.io/name` 에 `wordpress` 를 가지며 인스턴스 이름으로는
`app.kubernetes.io/instance` 에 `wordpress-abcxzy` 의 값을 가진다.
이를 통해 애플리케이션과 애플리케이션 인스턴스를 식별할 수 있다.
모든 애플리케이션 인스턴스는 고유한 이름을 가져야 한다.
## 예시
위 레이블을 사용하는 다른 방식에 대한 예시는 다양한 복잡성이 있다.
### 단순한 스테이트리스 서비스
`Deployment` 와 `Service` 오브젝트를 통해 배포된 단순한 스테이트리스 서비스의 경우를 보자. 다음 두 식별자는 레이블을 가장 간단한 형태로 사용하는 방법을 나타낸다.
`Deployment` 는 애플리케이션을 실행하는 파드를 감시하는데 사용한다.
```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app.kubernetes.io/name: myservice
app.kubernetes.io/instance: myservice-abcxzy
...
```
`Service`는 애플리케이션을 노출하기 위해 사용한다.
```yaml
apiVersion: v1
kind: Service
metadata:
labels:
app.kubernetes.io/name: myservice
app.kubernetes.io/instance: myservice-abcxzy
...
```
### 데이터베이스가 있는 웹 애플리케이션
Helm을 이용해서 데이터베이스(MySQL)을 이용하는 웹 애플리케이션(WordPress)을 설치한 것과 같이 좀 더 복잡한 애플리케이션을 고려할 수 있다.
다음 식별자는 이 애플리케이션을 배포하는데 사용하는 오브젝트의 시작을 보여준다.
WordPress를 배포하는데 다음과 같이 `Deployment` 로 시작한다.
```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app.kubernetes.io/name: wordpress
app.kubernetes.io/instance: wordpress-abcxzy
app.kubernetes.io/version: "4.9.4"
app.kubernetes.io/managed-by: helm
app.kubernetes.io/component: server
app.kubernetes.io/part-of: wordpress
...
```
`Service` 는 애플리케이션을 노출하기 위해 사용한다.
```yaml
apiVersion: v1
kind: Service
metadata:
labels:
app.kubernetes.io/name: wordpress
app.kubernetes.io/instance: wordpress-abcxzy
app.kubernetes.io/version: "4.9.4"
app.kubernetes.io/managed-by: helm
app.kubernetes.io/component: server
app.kubernetes.io/part-of: wordpress
...
```
MySQL은 `StatefulSet` 에 MySQL의 소속과 상위 애플리케이션에 대한 메타데이터가 포함되어 노출된다.
```yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
labels:
app.kubernetes.io/name: mysql
app.kubernetes.io/instance: mysql-abcxzy
app.kubernetes.io/version: "5.7.21"
app.kubernetes.io/managed-by: helm
app.kubernetes.io/component: database
app.kubernetes.io/part-of: wordpress
...
```
`Service` 는 WordPress의 일부로 MySQL을 노출하는데 이용한다.
```yaml
apiVersion: v1
kind: Service
metadata:
labels:
app.kubernetes.io/name: mysql
app.kubernetes.io/instance: mysql-abcxzy
app.kubernetes.io/version: "5.7.21"
app.kubernetes.io/managed-by: helm
app.kubernetes.io/component: database
app.kubernetes.io/part-of: wordpress
...
```
MySQL `StatefulSet` 과 `Service` 로 MySQL과 WordPress가 더 큰 범위의 애플리케이션에 포함되어 있는 것을 알게 된다.
{{% /capture %}}
content/ko/docs/concepts/overview/working-with-objects/labels.md
+225
View File
@@ -0,0 +1,225 @@
---
title: 레이블과 셀렉터
content_template: templates/concept
weight: 40
---
{{% capture overview %}}
_레이블_ 은 파드와 같은 오브젝트에 첨부된 키와 값의 쌍이다.
레이블은 오브젝트의 특성을 식별하는 데 사용되어 사용자에게 중요하지만, 코어 시스템에 직접적인 의미는 없다.
레이블로 오브젝트의 하위 집합을 선택하고, 구성하는데 사용할 수 있다. 레이블은 오브젝트를 생성할 때에 붙이거나 생성 이후에 붙이거나 언제든지 수정이 가능하다.
오브젝트마다 키와 값으로 레이블을 정의할 수 있다. 오브젝트의 키는 고유한 값이어야 한다.
```json
"metadata": {
"labels": {
"key1" : "value1",
"key2" : "value2"
}
}
```
레이블은 UI와 CLI에서 효율적인 쿼리를 사용하고 검색에 사용하기에 적합하다. 식별되지 않는 정보는 [어노테이션](/docs/concepts/overview/working-with-objects/annotations/)으로 기록해야 한다.
{{% /capture %}}
{{% capture body %}}
## 사용동기
레이블을 이용하면 사용자가 느슨하게 결합한 방식으로 조직 구조와 시스템 오브젝트를 매핑할 수 있으며, 클라이언트에 매핑 정보를 저장할 필요가 없다.
서비스 배포와 배치 프로세싱 파이프라인은 흔히 다차원의 엔터티들이다(예: 다중파티션 또는 배포, 다중 릴리즈 트랙, 다중 계층, 계층속 여러 마이크로 서비스들). 관리에는 크로스-커팅 작업이 필요한 경우가 많은데 이 작업은 사용자보다는 인프라에 의해 결정된 엄격한 계층 표현인 캡슐화를 깨트린다.
레이블 예시:
* `"release" : "stable"`, `"release" : "canary"`
* `"environment" : "dev"`, `"environment" : "qa"`, `"environment" : "production"`
* `"tier" : "frontend"`, `"tier" : "backend"`, `"tier" : "cache"`
* `"partition" : "customerA"`, `"partition" : "customerB"`
* `"track" : "daily"`, `"track" : "weekly"`
레이블 예시는 일반적으로 사용하는 경우에 해당한다. 당신의 규약에 따라 자유롭게 개발할 수 있다. 오브젝트에 붙여진 레이블 키는 고유해야한다는 것을 기억해야한다.
## 구문과 캐릭터 셋
_레이블_ 은 키와 값의 쌍이다. 유효한 레이블 키에는 슬래시(`/`)로 구분되는 선택한 접두사와 이름이라는 2개의 세그먼트가 있다. 이름 세그먼트는 63자 미만으로 시작과 끝은 알파벳과 숫자(`[a-z0-9A-Z]`)이며, 대시(`-`), 밑줄(`_`), 점(`.`)과 함께 사용할 수 있다. 접두사는 선택이다. 만약 접두사를 지정한 경우 접두사는 DNS의 하위 도메인으로 해야하며, 점(`.`)과, 전체 253자 이하, 슬래시(`/`)로 구분되는 DNS 레이블이다.
접두사를 생략하면 키 레이블은 개인용으로 간주한다. 최종 사용자의 오브젝트에 자동화된 시스템 구성 요소(예: `kube-scheduler`, `kube-controller-manager`, `kube-apiserver`, `kubectl` 또는 다른 타사의 자동화 구성 요소)의 접두사를 지정해야 한다.
`kubernetes.io/`와 `k8s.io/` 접두사는 쿠버네티스의 핵심 구성요소로 예약되어있다.
유효한 레이블 값은 63자 미만 또는 공백이며 시작과 끝은 알파벳과 숫자(`[a-z0-9A-Z]`)이며, 대시(`-`), 밑줄(`_`), 점(`.`)과 함께 사용할 수 있다.
다음의 예시는 파드에 `environment: production` 과 `app: nginx` 2개의 레이블이 있는 구성 파일이다.
```yaml
apiVersion: v1
kind: Pod
metadata:
name: label-demo
labels:
environment: production
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
```
## 레이블 셀렉터
[이름과 UID](/docs/user-guide/identifiers)와 다르게 레이블은 고유하지 않다. 일반적으로 우리는 많은 오브젝트에 같은 레이블을 가질 것으로 예상한다.
레이블 셀렉터를 통해 클라이언트와 사용자는 오브젝트를 식별할 수 있다. 레이블 셀렉터는 쿠버네티스 코어 그룹의 기본이다.
API는 현재 _일치성 기준_ 과 _집합성 기준_ 이라는 두 종류의 셀렉터를 지원한다.
레이블 셀렉터는 쉼표로 구분된 다양한 _요구사항_ 에 따라 만들 수 있다. 다양한 요구사항이 있는 경우 쉼표 기호가 AND(`&&`) 연산자로 구분되는 역할을 하도록 해야 한다.
비어있거나 지정되지 않은 셀렉터는 상황에 따라 달라진다.
셀렉터를 사용하는 API 유형은 유효성과 의미를 문서화 해야 한다.
{{< note >}}
레플리카 셋과 같은 일부 API 유형에서 두 인스턴스의 레이블 셀렉터는 네임스페이스 내에서 겹치지 않아야 한다. 그렇지 않으면 컨트롤러는 상충되는 명령으로 보고, 얼마나 많은 복제본이 필요한지 알 수 없다.
{{< /note >}}
### _일치성 기준_ 요건
_일치성 기준_ 또는 _불일치 기준_ 의 요구사항으로 레이블의 키와 값의 필터링을 허용한다. 일치하는 오브젝트는 추가 레이블을 가질 수 있지만 레이블의 명시된 제약 조건을 모두 만족해야 한다.
`=`,`==`,`!=` 이 3가지 연산자만 허용한다. 처음 두 개의 연산자의 _일치성_(그리고 단순히 동의어일 뿐임), 나머지는 _불일치_를 의미한다. 예를 들면,
```
environment = production
tier != frontend
```
전자는 `environment`를 키로 가지는 것과 `production`를 값으로 가지는 모든 리소스를 선택한다.
후자는 `tier`를 키로 가지고, 값을 `frontend`를 가지는 리소스를 제외한 모든 리소스를 선택하고, `tier`를 키로 가지며, 값을 공백으로 가지는 모든 리소스를 선택한다.
`environment=production,tier!=frontend` 처럼 쉼표를 통해 한 문장으로 `frontend`를 제외한 `production`을 필터링할 수 있다.
균등-기반 레이블의 요건에 대한 하나의 이용 시나리오는 파드가 노드를 선택하는 기준을 지정하는 것이다.
예를 들어, 아래 샘플 파드는 "`accelerator=nvidia-tesla-p100`" 레이블을 가진 노드를 선택한다.
```yaml
apiVersion: v1
kind: Pod
metadata:
name: cuda-test
spec:
containers:
- name: cuda-test
image: "k8s.gcr.io/cuda-vector-add:v0.1"
resources:
limits:
nvidia.com/gpu: 1
nodeSelector:
accelerator: nvidia-tesla-p100
```
### _집합성 기준_ 요건
_집합성 기준_ 레이블 요건에 따라 값 집합을 키로 필터링할 수 있다. `in`,`notin` and `exists`(키 식별자만 해당)의 3개의 연산자를 지원한다. 예를 들면,
```
environment in (production, qa)
tier notin (frontend, backend)
partition
!partition
```
첫 번째 예시에서 키가 `environment`이고 값이 `production` 또는 `qa`인 모든 리소스를 선택한다.
두 번째 예시에서 키가 `tier`이고 값이 `frontend`와 `backend`를 가지는 리소스를 제외한 모든 리소스와, 키로 `tier`를 가지고 값을 공백으로 가지는 모든 리소스를 선택한다.
세 번째 예시에서 레이블의 값에 상관없이 키가 `partition`를 포함하는 모든 리소스를 선택한다.
네 번째 예시에서 레이블의 값에 상관없이 키가 `partition`를 포함하지 않는 모든 리소스를 선택한다.
마찬가지로 쉼표는 _AND_ 연산자로 작동한다. 따라서 `partition,environment notin (qa)`와 같이 사용하면 값과 상관없이 키가 `partition`인 것과 키가 `environment`이고 값이 `qa`와 다른 리소스를 필터링할 수 있다.
_집합성 기준_ 레이블 셀렉터는 일반적으로 `environment=production` 과 `environment in (production)`를 같은 것으로 본다. 유사하게는 `!=`과 `notin`을 같은 것으로 본다.
_집합성 기준_ 요건은 _일치성 기준_ 요건과 조합해서 사용할 수 있다. 예를 들어 `partition in (customerA, customerB),environment!=qa`
## API
### LIST와 WATCH 필터링
LIST와 WATCH 작업은 쿼리 파라미터를 사용해서 반환되는 오브젝트 집합을 필터링하기 위해 레이블 셀럭터를 지정할 수 있다. 다음의 2가지 요건 모두 허용된다(URL 쿼리 문자열을 그대로 표기함).
* _불일치 기준_ 요건: `?labelSelector=environment%3Dproduction,tier%3Dfrontend`
* _집합성 기준_ 요건: `?labelSelector=environment+in+%28production%2Cqa%29%2Ctier+in+%28frontend%29`
두 가지 레이블 셀렉터 스타일은 모두 REST 클라이언트를 통해 선택된 리소스를 확인하거나 목록을 볼 수 있다. 예를 들어, `kubectl`로 `API 서버`를 대상으로 _불일치 기준_으로 하는 셀렉터를 다음과 같이 이용할 수 있다.
```shell
kubectl get pods -l environment=production,tier=frontend
```
또는 _집합성 기준_ 요건을 사용하면
```shell
kubectl get pods -l 'environment in (production),tier in (frontend)'
```
앞서 안내한 것처럼 _집합성 기준_ 요건은 더 보여준다. 예시에서 다음과 같이 OR 연산자를 구현할 수 있다.
```shell
kubectl get pods -l 'environment in (production, qa)'
```
또는 _exists_ 연산자에 불일치한 것으로 제한할 수 있다.
```shell
kubectl get pods -l 'environment,environment notin (frontend)'
```
### API 오브젝트에서 참조 설정
[`서비스`](/docs/user-guide/services) 와 [`레플리케이션 컨트롤러`](/docs/user-guide/replication-controller)와 같은 일부 쿠버네티스 오브젝트는 레이블 셀렉터를 사용해서 [`파드`](/docs/user-guide/pods)와 같은 다른 리소스 집합을 선택한다.
#### 서비스와 리플리케이션 컨트롤러
`서비스`에서 지정하는 파드 집합은 레이블 셀렉터로 정의한다. 마찬가지로 `리플레케이션 컨트롤러`가 관리하는 파드의 개체군도 레이블 셀렉터로 정의한다.
서비스와 리플리케이션 컨트롤러의 레이블 셀렉터는 `json` 또는 `yaml` 파일에 매핑된 _균등-기반_ 요구사항의 셀렉터만 지원한다.
```json
"selector": {
"component" : "redis",
}
```
or
```yaml
selector:
component: redis
```
`json` 또는 `yaml` 서식에서 셀렉터는 `component=redis` 또는 `component in (redis)` 모두 같은 것이다.
#### 세트-기반 요건을 지원하는 리소스
[`잡`](/docs/concepts/jobs/run-to-completion-finite-workloads/), [`디플로이먼트`](/docs/concepts/workloads/controllers/deployment/), [`레플리카 셋`](/docs/concepts/workloads/controllers/replicaset/) 그리고 [`데몬 셋`](/docs/concepts/workloads/controllers/daemonset/) 같은 새로운 리소스들은 집합성 기준의 요건도 지원한다.
```yaml
selector:
matchLabels:
component: redis
matchExpressions:
- {key: tier, operator: In, values: [cache]}
- {key: environment, operator: NotIn, values: [dev]}
```
`matchLabels`는 `{key,value}`의 쌍과 매칭된다. `matchLabels`에 매칭된 단일 `{key,value}`는 `matchExpressions`의 요소와 같으며 `key` 필드는 "key"로, `operator`는 "In" 그리고 `values`에는 "value"만 나열되어 있다. `matchExpressions`는 파드 셀렉터의 요건 목록이다. 유효한 연산자에는 In, NotIn, Exists 및 DoNotExist가 포함된다. In 및 NotIn은 설정된 값이 있어야 한다. `matchLabels`과 `matchExpressions` 모두 AND로 되어있어 일치하기 위해서는 모든 요건을 만족해야 한다.
#### 노드 셋 선택
레이블을 통해 선택하는 사용 사례 중 하나는 파드를 스케줄 할 수 있는 노드 셋을 제한하는 것이다.
자세한 내용은 [노드 선택](/docs/concepts/configuration/assign-pod-node/) 문서를 참조한다.
{{% /capture %}}
content/ko/docs/concepts/overview/working-with-objects/namespaces.md
+10 -3
View File
@@ -61,13 +61,13 @@ kube-public Active 1d
### 요청에 네임스페이스 설정하기
임시로 네임스페이스를 요청에 설정하기 위해서는, `--namespace` 플래그를 사용한다.
네임스페이스를 현재 요청에 설정하기 위해서는, `--namespace` 플래그를 사용한다.
예를 들면,
```shell
kubectl --namespace=<insert-namespace-name-here> run nginx --image=nginx
kubectl --namespace=<insert-namespace-name-here> get pods
kubectl run nginx --image=nginx --namespace=<insert-namespace-name-here>
kubectl get pods --namespace=<insert-namespace-name-here>
```
### 선호하는 네임스페이스 설정하기
@@ -108,3 +108,10 @@ kubectl api-resources --namespaced=false
```
{{% /capture %}}
{{% capture whatsnext %}}
* [신규 네임스페이스 생성](/docs/tasks/administer-cluster/namespaces/#creating-a-new-namespace)에 대해 더 배우기.
* [네임스페이스 삭제](/docs/tasks/administer-cluster/namespaces/#deleting-a-namespace)에 대해 더 배우기.
{{% /capture %}}