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

Third Korean l10n work for release-1.19

Browse Source 
- Fix issue with broken links in ko documents (#24190)
- Fix issue with links to already translated ko documents (#24158)
- Translate docs/reference/kubectl/docker-cli-to-kubectl/ into Korean (#24131)
- Translate docs/setup/production-environment/tools/kubespray.md in Korean (#24144)
- Translated titles into korean (#24394)
- DNS subdomain translation corrected (#24393)
- Update ko/docs/concepts/overview/working-with-objects/common-labels/ (#24370)
- Translate tasks/job/coarse-parallel-processing-work-queue in Korean (#24218)
- Update outdated files in the dev-1.19-ko.3 branch (#24151)
- Add missing dot on job.md (#24084)

Co-authored-by: chhanz <han0495@gmail.com>
Co-authored-by: Yuuraa <yoorachoi8937@gmail.com>
Co-authored-by: sushil <sushilktiwari.st@gmail.com>
Co-authored-by: June Yi <june.yi@samsung.com>
Co-authored-by: Jerry Park <jaehwa@gmail.com>
Co-authored-by: Jihoon Seo <46767780+jihoon-seo@users.noreply.github.com>
Co-authored-by: Jonghun Park <jonghun.park.194@gmail.com>
Co-authored-by: Leo <leo.lab001@gmail.com>
This commit is contained in:
June Yi
2020-10-16 09:54:30 +09:00
parent 28980202c1
commit a6566dc277
56 changed files with 1389 additions and 844 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/ko/docs/reference/access-authn-authz/authorization.md
+3 -3
View File
@@ -11,7 +11,7 @@ weight: 60
<!-- body -->
쿠버네티스에서는 사용자의 요청이 인가(접근 권한을 부여) 받기 전에 사용자가 인증(로그인)되어야 한다.
인증에 대한 자세한 내용은 [쿠버네티스 API 접근 제어하기](/docs/reference/access-authn-authz/controlling-access/)를
인증에 대한 자세한 내용은 [쿠버네티스 API 접근 제어하기](/ko/docs/reference/access-authn-authz/controlling-access/)를
참고한다.
쿠버네티스는 REST API 요청에 공통적인 속성을 요구한다.
@@ -42,7 +42,7 @@ weight: 60
* **extra** - 인증 계층에서 제공하는 문자열 값에 대한 임의의 문자열 키 맵.
* **API** - 요청이 API 리소스에 대한 것인지 여부.
* **Request path** - `/api` 또는 `/healthz`와 같이 다양한 리소스가 아닌 엔드포인트의 경로.
* **API request verb** - `get`, `list`, `create`, `update`, `patch`, `watch`, `delete`, `deletecollection`과 같은 리소스 요청에 사용하는 API 동사. 리소스 API 엔드포인트의 요청 동사를 결정하려면 [요청 동사 결정](/docs/reference/access-authn-authz/authorization/#determine-the-request-verb)을 참고한다.
* **API request verb** - `get`, `list`, `create`, `update`, `patch`, `watch`, `delete`, `deletecollection`과 같은 리소스 요청에 사용하는 API 동사. 리소스 API 엔드포인트의 요청 동사를 결정하려면 [요청 동사 결정](/ko/docs/reference/access-authn-authz/authorization/#요청-동사-결정)을 참고한다.
* **HTTP request verb** - `get`, `post`, `put`, `delete`처럼 소문자 HTTP 메서드는 리소스가 아닌 요청에 사용한다.
* **Resource** - 접근 중인 리소스의 ID 또는 이름(리소스 요청만 해당) -- `get`, `update`, `patch`, `delete` 동사를 사용하는 리소스 요청의 경우 리소스 이름을 지정해야 한다.
* **Subresource** - 접근 중인 하위 리소스(리소스 요청만 해당).
@@ -197,5 +197,5 @@ status:
## {{% heading "whatsnext" %}}
* 인증에 대한 자세한 내용은 [쿠버네티스 API 접근 제어하기](/docs/reference/access-authn-authz/controlling-access/)에서 **인증**을 참조한다.
* 인증에 대한 자세한 내용은 [쿠버네티스 API 접근 제어하기](/ko/docs/reference/access-authn-authz/controlling-access/)에서 **인증**을 참조한다.
* 어드미션 제어에 대한 자세한 내용은 [어드미션 컨트롤러 사용하기](/docs/reference/access-authn-authz/admission-controllers/)를 참조한다.
content/ko/docs/reference/access-authn-authz/controlling-access.md
+2 -3
View File
@@ -11,7 +11,7 @@ weight: 5
<!-- body -->
사용자는 `kubectl`, 클라이언트 라이브러리
또는 REST 요청을 통해
[API에 접근한다](/docs/tasks/access-application-cluster/access-cluster/).
[API에 접근한다](/ko/docs/tasks/access-application-cluster/access-cluster/).
사용자와 쿠버네티스 서비스 어카운트 모두 API에 접근할 수 있다.
요청이 API에 도달하면,
다음 다이어그램에 설명된 몇 가지 단계를 거친다.
@@ -100,7 +100,7 @@ Bob이 `projectCaribou` 네임스페이스에 있는 오브젝트에 쓰기(`cre
쿠버네티스는 ABAC 모드, RBAC 모드, 웹훅 모드와 같은 여러 개의 인가 모듈을 지원한다. 관리자가 클러스터를 생성할 때 API 서버에서 사용해야 하는 인가 모듈을 구성했다. 인가 모듈이 2개 이상 구성되면 쿠버네티스가 각 모듈을 확인하고, 어느 모듈이 요청을 승인하면 요청을 진행할 수 있다. 모든 모듈이 요청을 거부하면 요청이 거부된다(HTTP 상태 코드 403).
인가 모듈을 사용한 정책 생성을 포함해 쿠버네티스 인가에 대해 더 배우려면 [인가 개요](/docs/reference/access-authz/authorization/)를 참조한다.
인가 모듈을 사용한 정책 생성을 포함해 쿠버네티스 인가에 대해 더 배우려면 [인가 개요](/ko/docs/reference/access-authn-authz/authorization/)를 참조한다.
## 어드미션 제어
@@ -159,4 +159,3 @@ GCE(구글 컴퓨트 엔진) 및 다른 클라우드 제공자에서 `kube-up.sh
API 서버는 포트 443에서 서비스한다.
GCE에서는 외부 HTTPS가 API에 접근할 수 있도록 프로젝트에서 방화벽 규칙이 구성된다.
이외에 클러스터 설정 방법은 다양하다.
content/ko/docs/reference/glossary/index.md
+1 -1
View File
@@ -7,6 +7,6 @@ weight: 5
card:
name: reference
weight: 10
title: Glossary
title: 용어집
---
content/ko/docs/reference/glossary/pod-lifecycle.md
+1 -1
View File
@@ -16,4 +16,4 @@ short-description: >
<!--more-->
[파드 라이프사이클](/ko/docs/concepts/workloads/pods/pod-lifecycle/)은 파드의 라이프사이클에 대한 고수준의 요약이다. 다섯 가지 파드 단계가 있다: Pending, Running, Succeeded, Failed, 그리고 Unknown. [파드 스테이터스](/docs/reference/generated/kubernetes-api/v1.13/#podstatus-v1-core)의 `phase` 필드에 파드 상태에 대한 자세한 설명이 요약되어 있다.
[파드 라이프사이클](/ko/docs/concepts/workloads/pods/pod-lifecycle/)은 파드의 라이프사이클에 대한 고수준의 요약이다. 다섯 가지 파드 단계가 있다: Pending, Running, Succeeded, Failed, 그리고 Unknown. [파드 스테이터스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core)의 `phase` 필드에 파드 상태에 대한 자세한 설명이 요약되어 있다.
content/ko/docs/reference/kubectl/docker-cli-to-kubectl.md
+372
View File
@@ -0,0 +1,372 @@
---
title: 도커 사용자를 위한 kubectl
content_type: concept
---
<!-- overview -->
당신은 쿠버네티스 커맨드 라인 도구인 kubectl을 사용하여 API 서버와 상호 작용할 수 있다. 만약 도커 커맨드 라인 도구에 익숙하다면 kubectl을 사용하는 것은 간단하다. 다음 섹션에서는 도커의 하위 명령을 보여주고 kubectl과 같은 명령어를 설명한다.
<!-- body -->
## docker run
nginx 디플로이먼트(Deployment)를 실행하고 해당 디플로이먼트를 노출시키려면, [kubectl create deployment](/docs/reference/generated/kubectl/kubectl-commands#-em-deployment-em-)을 참고한다.
docker:
```shell
docker run -d --restart=always -e DOMAIN=cluster --name nginx-app -p 80:80 nginx
```
```
55c103fa129692154a7652490236fee9be47d70a8dd562281ae7d2f9a339a6db
```
```shell
docker ps
```
```
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
55c103fa1296 nginx "nginx -g 'daemon of…" 9 seconds ago Up 9 seconds 0.0.0.0:80->80/tcp nginx-app
```
kubectl:
```shell
# nginx 실행하는 파드를 시작한다
kubectl create deployment --image=nginx nginx-app
```
```shell
# nginx-app 에 env를 추가한다
kubectl set env deployment/nginx-app DOMAIN=cluster
```
```
deployment.apps/nginx-app created
```
```
# nginx-app 에 env를 추가한다
kubectl set env deployment/nginx-app DOMAIN=cluster
```
```
deployment.apps/nginx-app env updated
```
{{< note >}}
`kubectl` 커맨드는 생성되거나 변경된 리소스의 유형과 이름을 출력하므로, 이를 후속 커맨드에 사용할 수 있다. 디플로이먼트가 생성된 후에는 새로운 서비스를 노출할 수 있다.
{{< /note >}}
```shell
# 서비스를 통해 포트를 노출
kubectl expose deployment nginx-app --port=80 --name=nginx-http
```
```
service "nginx-http" exposed
```
kubectl을 사용하면, N개의 파드가 nginx를 실행하도록 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)를 생성할 수 있다. 여기서 N은 스펙에 명시된 레플리카 수이며, 기본값은 1이다. 또한 파드의 레이블과 셀럭터를 사용하여 서비스를 생성할 수 있다. 자세한 내용은 [클러스터 내 애플리케이션에 접근하기 위해 서비스 사용하기](/ko/docs/tasks/access-application-cluster/service-access-application-cluster)를 참고한다.
기본적으로 이미지는 `docker run -d ...` 와 비슷하게 백그라운드로 실행된다. 포그라운드로 실행하려면 [`kubectl run`](/docs/reference/generated/kubectl/kubectl-commands/#run)을 이용하여 파드를 생성한다.
```shell
kubectl run [-i] [--tty] --attach <name> --image=<image>
```
`docker run ...` 과 달리 `--attach` 를 지정하면 `표준 입력(stdin)`, `표준 출력(stdout)` 및 `표준 오류(stderr)`가 붙는다. 연결된(attached) 스트림을 제어할 수 없다(`docker -a ...`).
해당 컨테이너에서 분리(detach)하려면 이스케이프 시퀀스(escape sequence) Ctrl+P를 입력한 다음 Ctrl+Q를 입력한다.
## docker ps
현재 실행 중인 목록을 보기 위해서는 [kubectl get](/docs/reference/generated/kubectl/kubectl-commands/#get)을 참고한다.
docker:
```shell
docker ps -a
```
```
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
14636241935f ubuntu:16.04 "echo test" 5 seconds ago Exited (0) 5 seconds ago cocky_fermi
55c103fa1296 nginx "nginx -g 'daemon of…" About a minute ago Up About a minute 0.0.0.0:80->80/tcp nginx-app
```
kubectl:
```shell
kubectl get po
```
```
NAME READY STATUS RESTARTS AGE
nginx-app-8df569cb7-4gd89 1/1 Running 0 3m
ubuntu 0/1 Completed 0 20s
```
## docker attach
이미 실행 중인 컨테이너에 연결하려면 [kubectl attach](/docs/reference/generated/kubectl/kubectl-commands/#attach)를 참고한다.
docker:
```shell
docker ps
```
```
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
55c103fa1296 nginx "nginx -g 'daemon of…" 5 minutes ago Up 5 minutes 0.0.0.0:80->80/tcp nginx-app
```
```shell
docker attach 55c103fa1296
...
```
kubectl:
```shell
kubectl get pods
```
```
NAME READY STATUS RESTARTS AGE
nginx-app-5jyvm 1/1 Running 0 10m
```
```shell
kubectl attach -it nginx-app-5jyvm
...
```
컨테이너에서 분리하려면 이스케이프 시퀀스 Ctrl+P를 입력한 다음 Ctrl+Q를 입력한다.
## docker exec
컨테이너에서 커맨드를 실행하려면 [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec)를 참고한다.
docker:
```shell
docker ps
```
```
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
55c103fa1296 nginx "nginx -g 'daemon of…" 6 minutes ago Up 6 minutes 0.0.0.0:80->80/tcp nginx-app
```
```shell
docker exec 55c103fa1296 cat /etc/hostname
```
```
55c103fa1296
```
kubectl:
```shell
kubectl get po
```
```
NAME READY STATUS RESTARTS AGE
nginx-app-5jyvm 1/1 Running 0 10m
```
```shell
kubectl exec nginx-app-5jyvm -- cat /etc/hostname
```
```
nginx-app-5jyvm
```
대화형 커맨드를 사용한다.
docker:
```shell
docker exec -ti 55c103fa1296 /bin/sh
# exit
```
kubectl:
```shell
kubectl exec -ti nginx-app-5jyvm -- /bin/sh
# exit
```
자세한 내용은 [실행 중인 컨테이너의 셸 얻기](/docs/tasks/debug-application-cluster/get-shell-running-container/)를 참고한다.
## docker logs
실행 중인 프로세스의 표준 입력(stdout)/표준 오류(stderr)를 수행하려면 [kubectl logs](/docs/reference/generated/kubectl/kubectl-commands/#logs)를 참고한다.
docker:
```shell
docker logs -f a9e
```
```
192.168.9.1 - - [14/Jul/2015:01:04:02 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.35.0" "-"
192.168.9.1 - - [14/Jul/2015:01:04:03 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.35.0" "-"
```
kubectl:
```shell
kubectl logs -f nginx-app-zibvs
```
```
10.240.63.110 - - [14/Jul/2015:01:09:01 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.26.0" "-"
10.240.63.110 - - [14/Jul/2015:01:09:02 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.26.0" "-"
```
파드와 컨테이너에는 근소한 차이가 있다. 기본적으로 파드는 프로세스가 종료되어도 종료되지 않는다. 대신 파드가 프로세스를 다시 시작한다. 이는 도커의 실행 옵션인 `--restart=always`와 유사하지만, 한 가지 큰 차이점이 있다. 도커에서는 프로세스의 각 호출에 대한 출력이 연결되지만, 쿠버네티스의 경우 각 호출은 별개다. 쿠버네티스에서 이전 실행의 출력 내용을 보려면 다음을 수행한다.
```shell
kubectl logs --previous nginx-app-zibvs
```
```
10.240.63.110 - - [14/Jul/2015:01:09:01 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.26.0" "-"
10.240.63.110 - - [14/Jul/2015:01:09:02 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.26.0" "-"
```
자세한 정보는 [로깅 아키텍처](/ko/docs/concepts/cluster-administration/logging/)를 참고한다.
## docker stop 과 docker rm
실행 중인 프로세스를 중지하고 삭제하려면 [kubectl delete](/docs/reference/generated/kubectl/kubectl-commands/#delete)을 참고한다.
docker:
```shell
docker ps
```
```
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
a9ec34d98787 nginx "nginx -g 'daemon of" 22 hours ago Up 22 hours 0.0.0.0:80->80/tcp, 443/tcp nginx-app
```
```shell
docker stop a9ec34d98787
```
```
a9ec34d98787
```
```shell
docker rm a9ec34d98787
```
```
a9ec34d98787
```
kubectl:
```shell
kubectl get deployment nginx-app
```
```
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-app 1/1 1 1 2m
```
```shell
kubectl get po -l run=nginx-app
```
```
NAME READY STATUS RESTARTS AGE
nginx-app-2883164633-aklf7 1/1 Running 0 2m
```
```shell
kubectl delete deployment nginx-app
```
```
deployment "nginx-app" deleted
```
```shell
kubectl get po -l run=nginx-app
# 아무것도 반환하지 않는다
```
{{< note >}}
kubectl을 사용할 때는 파드를 직접 삭제하지 않는다. 먼저 파드를 소유한 디플로이먼트를 삭제해야 한다. 만약 파드를 직접 삭제하면 디플로이먼트가 파드를 재생성할 것이다.
{{< /note >}}
## docker login
kubectl은 `docker login`와 직접적인 유사점은 없다. 프라이빗 레지스트리와 함께 쿠버네티스를 사용하려면 [프라이빗 레지스트리 사용](/ko/docs/concepts/containers/images/#프라이빗-레지스트리-사용)을 참고한다.
## docker version
클라이언트와 서버의 버전을 가져오려면 [kubectl version](/docs/reference/generated/kubectl/kubectl-commands/#version)을 참고한다.
docker:
```shell
docker version
```
```
Client version: 1.7.0
Client API version: 1.19
Go version (client): go1.4.2
Git commit (client): 0baf609
OS/Arch (client): linux/amd64
Server version: 1.7.0
Server API version: 1.19
Go version (server): go1.4.2
Git commit (server): 0baf609
OS/Arch (server): linux/amd64
```
kubectl:
```shell
kubectl version
```
```
Client Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.9+a3d1dfa6f4335", GitCommit:"9b77fed11a9843ce3780f70dd251e92901c43072", GitTreeState:"dirty", BuildDate:"2017-08-29T20:32:58Z", OpenPaasKubernetesVersion:"v1.03.02", GoVersion:"go1.7.5", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.9+a3d1dfa6f4335", GitCommit:"9b77fed11a9843ce3780f70dd251e92901c43072", GitTreeState:"dirty", BuildDate:"2017-08-29T20:32:58Z", OpenPaasKubernetesVersion:"v1.03.02", GoVersion:"go1.7.5", Compiler:"gc", Platform:"linux/amd64"}
```
## docker info
환경 및 설정에 대한 자세한 정보는 [kubectl cluster-info](/docs/reference/generated/kubectl/kubectl-commands/#cluster-info)를 참고한다.
docker:
```shell
docker info
```
```
Containers: 40
Images: 168
Storage Driver: aufs
Root Dir: /usr/local/google/docker/aufs
Backing Filesystem: extfs
Dirs: 248
Dirperm1 Supported: false
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 3.13.0-53-generic
Operating System: Ubuntu 14.04.2 LTS
CPUs: 12
Total Memory: 31.32 GiB
Name: k8s-is-fun.mtv.corp.google.com
ID: ADUV:GCYR:B3VJ:HMPO:LNPQ:KD5S:YKFQ:76VN:IANZ:7TFV:ZBF4:BYJO
WARNING: No swap limit support
```
kubectl:
```shell
kubectl cluster-info
```
```
Kubernetes master is running at https://203.0.113.141
KubeDNS is running at https://203.0.113.141/api/v1/namespaces/kube-system/services/kube-dns/proxy
kubernetes-dashboard is running at https://203.0.113.141/api/v1/namespaces/kube-system/services/kubernetes-dashboard/proxy
Grafana is running at https://203.0.113.141/api/v1/namespaces/kube-system/services/monitoring-grafana/proxy
Heapster is running at https://203.0.113.141/api/v1/namespaces/kube-system/services/monitoring-heapster/proxy
InfluxDB is running at https://203.0.113.141/api/v1/namespaces/kube-system/services/monitoring-influxdb/proxy
```
content/ko/docs/reference/kubectl/overview.md
+13 -6
View File
@@ -125,14 +125,15 @@ kubectl [command] [TYPE] [NAME] [flags]
다음 표에는 지원되는 모든 리소스 타입과 해당 약어가 나열되어 있다.
(이 출력은 `kubectl api-resources` 에서 확인할 수 있으며, 쿠버네티스 1.13.3 부터 일치했다.)
(이 출력은 `kubectl api-resources` 에서 확인할 수 있으며, 쿠버네티스 1.19.1 에서의 출력을 기준으로 한다.)
| 리소스 이름 | 짧은 이름 | API 그룹 | 네임스페이스 | 리소스 종류 |
| NAME | SHORTNAMES | APIGROUP | NAMESPACED | KIND |
|---|---|---|---|---|
| `bindings` | | | true | Binding|
| `bindings` | | | true | Binding |
| `componentstatuses` | `cs` | | false | ComponentStatus |
| `configmaps` | `cm` | | true | ConfigMap |
| `endpoints` | `ep` | | true | Endpoints |
| `events` | `ev` | | true | Event |
| `limitranges` | `limits` | | true | LimitRange |
| `namespaces` | `ns` | | false | Namespace |
| `nodes` | `no` | | false | Node |
@@ -140,14 +141,14 @@ kubectl [command] [TYPE] [NAME] [flags]
| `persistentvolumes` | `pv` | | false | PersistentVolume |
| `pods` | `po` | | true | Pod |
| `podtemplates` | | | true | PodTemplate |
| `replicationcontrollers` | `rc` | | true| ReplicationController |
| `replicationcontrollers` | `rc` | | true | ReplicationController |
| `resourcequotas` | `quota` | | true | ResourceQuota |
| `secrets` | | | true | Secret |
| `serviceaccounts` | `sa` | | true | ServiceAccount |
| `services` | `svc` | | true | Service |
| `mutatingwebhookconfigurations` | | admissionregistration.k8s.io | false | MutatingWebhookConfiguration |
| `validatingwebhookconfigurations` | | admissionregistration.k8s.io | false | ValidatingWebhookConfiguration |
| `customresourcedefinitions` | `crd`, `crds` | apiextensions.k8s.io | false | CustomResourceDefinition |
| `customresourcedefinitions` | `crd,crds` | apiextensions.k8s.io | false | CustomResourceDefinition |
| `apiservices` | | apiregistration.k8s.io | false | APIService |
| `controllerrevisions` | | apps | true | ControllerRevision |
| `daemonsets` | `ds` | apps | true | DaemonSet |
@@ -164,9 +165,15 @@ kubectl [command] [TYPE] [NAME] [flags]
| `jobs` | | batch | true | Job |
| `certificatesigningrequests` | `csr` | certificates.k8s.io | false | CertificateSigningRequest |
| `leases` | | coordination.k8s.io | true | Lease |
| `endpointslices` | | discovery.k8s.io | true | EndpointSlice |
| `events` | `ev` | events.k8s.io | true | Event |
| `ingresses` | `ing` | extensions | true | Ingress |
| `flowschemas` | | flowcontrol.apiserver.k8s.io | false | FlowSchema |
| `prioritylevelconfigurations` | | flowcontrol.apiserver.k8s.io | false | PriorityLevelConfiguration |
| `ingressclasses` | | networking.k8s.io | false | IngressClass |
| `ingresses` | `ing` | networking.k8s.io | true | Ingress |
| `networkpolicies` | `netpol` | networking.k8s.io | true | NetworkPolicy |
| `runtimeclasses` | | node.k8s.io | false | RuntimeClass |
| `poddisruptionbudgets` | `pdb` | policy | true | PodDisruptionBudget |
| `podsecuritypolicies` | `psp` | policy | false | PodSecurityPolicy |
| `clusterrolebindings` | | rbac.authorization.k8s.io | false | ClusterRoleBinding |
@@ -176,7 +183,7 @@ kubectl [command] [TYPE] [NAME] [flags]
| `priorityclasses` | `pc` | scheduling.k8s.io | false | PriorityClass |
| `csidrivers` | | storage.k8s.io | false | CSIDriver |
| `csinodes` | | storage.k8s.io | false | CSINode |
| `storageclasses` | `sc` | storage.k8s.io | false | StorageClass |
| `storageclasses` | `sc` | storage.k8s.io | false | StorageClass |
| `volumeattachments` | | storage.k8s.io | false | VolumeAttachment |
## 출력 옵션
content/ko/docs/reference/scheduling/policies.md
+2 -2
View File
@@ -26,7 +26,7 @@ weight: 10
- `PodFitsResources`: 파드의 요구 사항을 충족할 만큼 노드에 사용할 수 있는
리소스(예: CPU 및 메모리)가 있는지 확인한다.
- `PodMatchNodeSelector`: 파드의 노드 {{< glossary_tooltip text="셀렉터" term_id="selector" >}}가
- `MatchNodeSelector`: 파드의 노드 {{< glossary_tooltip text="셀렉터" term_id="selector" >}}가
노드의 {{< glossary_tooltip text="레이블" term_id="label" >}}과 일치하는지 확인한다.
- `NoVolumeZoneConflict`: 해당 스토리지에 대한 장애 영역 제한이 주어지면
@@ -115,4 +115,4 @@ weight: 10
## {{% heading "whatsnext" %}}
* [스케줄링](/ko/docs/concepts/scheduling-eviction/kube-scheduler/)에 대해 배우기
* [kube-scheduler 프로파일](/docs/reference/scheduling/profiles/)에 대해 배우기
* [kube-scheduler 프로파일](/docs/reference/scheduling/profiles/)에 대해 배우기
content/ko/docs/reference/using-api/api-overview.md
+61 -51
View File
@@ -9,62 +9,61 @@ card:
---
<!-- overview -->
이 페이지는 쿠버네티스 API에 대한 개요를 제공한다.
<!-- body -->
REST API는 쿠버네티스의 근본적인 구조이다. 모든 조작, 컴포넌트 간의 통신과 외부 사용자의 명령은 API 서버에서 처리할 수 있는 REST API 호출이다. 따라서, 쿠버네티스 플랫폼 안의 모든 것은
REST API는 쿠버네티스의 근본적인 구조이다. 모든 조작,
컴포넌트 간의 통신과 외부 사용자의 명령은 API 서버에서 처리할 수 있는
REST API 호출이다. 따라서, 쿠버네티스 플랫폼 안의 모든 것은
API 오브젝트로 취급되고,
[API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)에 상응하는 항목이 있다.
대부분의 작업은 API에 의존하고 있는
[kubectl](/ko/docs/reference/kubectl/overview/) 커맨드라인 인터페이스 또는
[kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/)과 같은 다른 커맨드라인 툴을 통해 수행할 수 있다.
그러나, REST 호출 사용을 통해서 API에 직접 접근할 수도 있다.
쿠버네티스 API를 사용하는 애플리케이션을 작성하는 경우
[클라이언트 라이브러리](/ko/docs/reference/using-api/client-libraries/)중 하나의 사용을 고려한다.
## API 버전 규칙
필드를 없애거나 리소스 표현을 재구성하기 쉽도록,
쿠버네티스는 `/api/v1`이나 `/apis/rbac.authorization.k8s.io/v1alpha1`과 같이
각각 다른 API 경로에서 복수의 API 버전을 지원한다.
JSON과 Protobuf 직렬화 스키마 모두 스키마 변경에 대해서
동일한 가이드라인을 따른다. 이후 설명에서는 이 형식 모두를 다룬다.
아래를 위해 버전은 리소스나 필드 수준보다는 API 수준에서 설정된다.
- API가 시스템 리소스와 동작에 대해 명확하고 일관성 있게 표현하는 것을 보장
- 수명 종료(end-of-life) 또는 실험적인 API 접근 제어 활성화
JSON과 Protobuf 직렬화 스키마 모두 스키마 변경에 대해서 동일한 가이드라인을 따른다. 이후 설명에서는 이 형식 모두를 다룬다.
{{< note >}}
API 버전 규칙과 소프트웨어 버전 규칙은 간접적으로 연관된다.
[API와 릴리스 버전 부여에 관한 제안](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md)에는 API 버전 규칙과 소프트웨어 버전 규칙 간의 관계가 기술되어 있다.
{{< /note >}}
[API와 릴리스 버전 부여에 관한 제안](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md)에는
API 버전 규칙과 소프트웨어 버전 규칙 간의 관계가 기술되어 있다.
API 버전의 차이는 수준의 안정성과 지원의 차이를 나타낸다. [API 변경 문서](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions)에서 각 수준의 기준에 대한 더 많은 정보를 찾을 수 있다.
API 버전의 차이는 수준의 안정성과 지원의 차이를 나타낸다.
[API 변경 문서](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions)에서
각 수준의 기준에 대한 더 많은 정보를 찾을 수 있다.
아래는 각 수준의 기준에 대한 요약이다.
- 알파(Alpha) 수준:
- 버전 이름에 `alpha`가 포함된다. (예: `v1alpha1`)
- 버그가 있을 수도 있다. 이 기능을 활성화하면 버그가 노출될 수 있다. 기본적으로 비활성화되어 있다.
- 버그가 있을 수도 있다. 이 기능을 활성화하면 버그가 노출될 수 있다.
기본적으로 비활성화되어 있다.
- 기능에 대한 기술 지원이 언제든 공지 없이 중단될 수 있다.
- 다음 소프트웨어를 릴리스할 때 공지 없이 API의 호환성이 깨지는 방식으로 변경될 수 있다.
- 버그의 위험이 높고 장기간 지원되지 않으므로 단기간 테스트 용도의 클러스터에서만 사용하기를 권장한다.
- 버그의 위험이 높고 장기간 지원되지 않으므로
단기간 테스트 용도의 클러스터에서만 사용하기를 권장한다.
- 베타(Beta) 수준:
- 버전 이름에 `beta`가 포함된다. (예: `v2beta3`).
- 코드가 잘 테스트되었다. 이 기능을 활성화 시켜도 안전하다. 기본적으로 활성화되어 있다.
- 코드가 잘 테스트되었다. 이 기능을 활성화 시켜도 안전하다.
기본적으로 활성화되어 있다.
- 구체적인 내용이 바뀔 수는 있지만, 전반적인 기능에 대한 기술 지원이 중단되지 않는다.
- 오브젝트에 대한 스키마나 문법이 다음 베타 또는 안정화 릴리스에서 호환되지 않는 방식으로 바뀔 수도 있다. 이런 경우, 다음 버전으로 이관할 수 있는 가이드가 제공된다. 이때 API 오브젝트의 삭제, 편집 또는 재생성이
필요할 수도 있다. 편집 절차는 좀 생각해볼 필요가 있다. 이 기능에 의존하고 있는 애플리케이션은 다운타임이 필요할 수도 있다.
- 이후 여러 버전에서 잠재적으로 호환되지 않을 수도 있으므로 사업적으로 중요하지 않은 용도로만 사용하기를 권장한다. 복수의 클러스터를 가지고 있어서 독립적으로 업그레이드할 수 있다면, 이런 제약에서 안심이 될 수도 있겠다.
{{< note >}}
베타 기능을 사용해보고 피드백을 제공하자. 일단 베타가 끝나면, 실질적으로 더 많은 변경이 어렵다.
{{< /note >}}
- 오브젝트에 대한 스키마나 문법이 다음 베타 또는 안정화 릴리스에서
호환되지 않는 방식으로 바뀔 수도 있다. 이런 경우, 다음 버전으로
이관할 수 있는 가이드가 제공된다. 스키마 변경은 API 오브젝트의 삭제, 편집 또는 재생성이
필요할 수도 있다. 편집 절차는 좀 생각해볼 필요가 있다.
이 기능에 의존하고 있는 애플리케이션은 다운타임이 필요할 수도 있다.
- 이 소프트웨어는 프로덕션 용도로 권장되지 않는다. 이후 여러 버전에서
호환되지 않는 변경 사항이 적용될 수 있다. 복수의 클러스터를 가지고 있어서
독립적으로 업그레이드할 수 있다면, 이런 제약에서 벗어날 수도 있다.
{{< note >}}
베타 기능을 사용해보고 피드백을 제공하자. 기능이 베타 수준을 벗어난 이후에는
실질적으로 더 많은 변경이 어렵다.
{{< /note >}}
- 안정화(stable) 수준:
- 버전 이름이 `vX`이고 `X` 는 정수다.
@@ -72,32 +71,43 @@ API 버전의 차이는 수준의 안정성과 지원의 차이를 나타낸다.
## API 그룹
[*API 그룹*](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md)은 쿠버네티스 API를 더 쉽게 확장하게 해준다. API 그룹은 REST 경로와 직렬화된 객체의 `apiVersion` 필드에 명시된다.
[API 그룹](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md)은
쿠버네티스 API를 더 쉽게 확장하게 해준다.
API 그룹은 REST 경로와 직렬화된 객체의 `apiVersion` 필드에
명시된다.
현재 다음과 같은 다양한 API 그룹이 사용되고 있다:
현재 다음과 같은 다양한 API 그룹이 사용되고 있다.
* *핵심* (또는 *레거시* 라고 불리는) 그룹은 `apiVersion: v1`와 같이 `apiVersion` 필드에 명시되지 않고 REST 경로 `/api/v1`에 있다.
* 이름이 있는 그룹은 REST 경로 `/apis/$GROUP_NAME/$VERSION`에 있으며 `apiVersion: $GROUP_NAME/$VERSION`을 사용한다
(예를 들어 `apiVersion: batch/v1`). 지원되는 API 그룹 전체의 목록은 [쿠버네티스 API 참조 문서](/ko/docs/reference/)에서 확인할 수 있다.
* *핵심* (또는 *레거시* 라고 불리는) 그룹은 REST 경로 `/api/v1`에 있다.
핵심 그룹은 `apiVersion` 필드의 일부로 명시되지 않는다. 예를
들어, `apiVersion: v1` 와 같다.
* 이름이 있는 그룹은 REST 경로 `/apis/$GROUP_NAME/$VERSION`에 있으며
`apiVersion: $GROUP_NAME/$VERSION`을 사용한다(예를 들어, `apiVersion: batch/v1`).
지원되는 API 그룹 전체의 목록은
[쿠버네티스 API 참조 문서](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)에서 확인할 수 있다.
[사용자 정의 리소스](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)로 API를 확장하는 경우에는 다음 두 종류의 경로가 지원된다.
## API 그룹 활성화 또는 비활성화 {#enabling-or-disabling}
- 기본적인 CRUD 요구에는
[커스텀리소스데피니션(CustomResourceDefinition)](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)
- 쿠버네티스 API의 의미론적 전체 집합으로 사용자만의 Apiserver를 구현하려는 경우에는 [aggregator](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/aggregated-api-servers.md)
특정 리소스 및 API 그룹은 기본적으로 활성화된다. API 서버에서
`--runtime-config` 를 설정하여 활성화 또는 비활성화할 수 있다.
`--runtime-config` 플래그는 API 서버의 런타임 구성을 설명하는
쉼표로 구분된 `<key>=<value>` 쌍을 허용한다. 예를 들면, 다음과 같다.
## API 그룹 활성화 또는 비활성화 하기
특정 리소스와 API 그룹은 기본적으로 활성화되어 있다. 이들은 apiserver에서 `--runtime-config`를 설정해서 활성화하거나
비활성화 시킬 수 있다. `--runtime-config`는 쉼표로 분리된 값을 허용한다. 예를 들어:
- batch/v1을 비활성화하려면 `--runtime-config=batch/v1=false`로 설정
- batch/v2alpha1을 활성화하려면 `--runtime-config=batch/v2alpha1`로 설정
이 플래그는 apiserver의 런타임 구성을 설명하는 쉼표로 분리된 키=값 쌍의 집합을 허용한다.
- `batch/v1` 을 비활성화하려면, `--runtime-config=batch/v1=false` 로 설정
- `batch/v2alpha1` 을 활성화하려면, `--runtime-config=batch/v2alpha1` 으로 설정
{{< note >}}
그룹이나 리소스를 활성화 또는 비활성화하려면, apiserver와 controller-manager를 재시작하여
`--runtime-config` 변경을 반영해야 한다.
{{< /note >}}
## 지속성
쿠버네티스는 {{< glossary_tooltip term_id="etcd" >}}에 기록하여 API 리소스 측면에서
직렬화된 상태를 저장한다.
## {{% heading "whatsnext" %}}
- [API 규칙](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#api-conventions)에 대해 자세히 알아보기
- [애그리게이터(aggregator)](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/aggregated-api-servers.md)에
대한 디자인 문서 읽기