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

Fifth Korean l10n work for release-1.19

Browse Source 
- Update outdated in concept secret.md (#25254)
- Update outdated resource quotas for ko5 (#25261)
- Mistranslation on kubelet-authentication authorization.md in korean (#25223)
- Update outdated files in dev-1.19-ko.5 part-03 (#25159)
- Update outdated files in the upstream/dev-1.19-ko.5 branch (#25103)
- Update outdated files in dev-1.19-ko.5 part-02 (#25152)
- Translate reference/glossary/container-lifecycle-hooks.md in Korean (#25071)
- Translate reference/command-line-tools-reference/kube-proxy into korean (#24817)
- Translate reference/scheduling/config.md into Korean (#24489)
- Translate reference/kubectl/jsonpath into Korean (#24868)

Co-authored-by: seokho-son <shsongist@gmail.com>
Co-authored-by: Jerry Park <jaehwa@gmail.com>
Co-authored-by: kosehy@gmail.com <kosehy@gmail.com>
Co-authored-by: santachopa <santachopa@naver.com>
This commit is contained in:
kosehy@gmail.com
2020-11-12 22:40:40 +09:00
committed by seokho-son
parent dc5093f2f2
commit 64f9f3ebd4
68 changed files with 2295 additions and 1595 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/ko/docs/reference/_index.md
+3 -3
View File
@@ -16,8 +16,8 @@ content_type: concept
## API 레퍼런스
* [쿠버네티스 API 개요](/ko/docs/reference/using-api/api-overview/) - 쿠버네티스 API에 대한 개요
* [Kubernetes API 레퍼런스 {{< latest-version >}}](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/)
* [쿠버네티스 API 레퍼런스 {{< latest-version >}}](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/)
* [쿠버네티스 API 사용](/ko/docs/reference/using-api/) - 쿠버네티스 API에 대한 개요
## API 클라이언트 라이브러리
@@ -34,7 +34,7 @@ content_type: concept
* [kubectl](/ko/docs/reference/kubectl/overview/) - 명령어를 실행하거나 쿠버네티스 클러스터를 관리하기 위해 사용하는 주된 CLI 도구.
* [JSONPath](/docs/reference/kubectl/jsonpath/) - kubectl에서 [JSONPath 표현](https://goessner.net/articles/JsonPath/)을 사용하기 위한 문법 가이드.
* [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) - 안정적인 쿠버네티스 클러스터를 쉽게 프로비전하기 위한 CLI 도구.
* [kubeadm](/ko/docs/reference/setup-tools/kubeadm/) - 안정적인 쿠버네티스 클러스터를 쉽게 프로비전하기 위한 CLI 도구.
## 컴포넌트 레퍼런스
content/ko/docs/reference/access-authn-authz/_index.md
+24 -2
View File
@@ -1,4 +1,26 @@
---
title: API 접근하기
title: API 접근 제어
weight: 20
---
no_list: true
---
쿠버네티스가 API 접근을 구현 및 제어하는 방법에 대한 자세한 내용은
[쿠버네티스 API에 대한 접근 제어](/ko/docs/concepts/security/controlling-access/)를 참고한다.
참조 문헌
- [인증](/docs/reference/access-authn-authz/authentication/)
- [부트스트랩 토큰 인증](/docs/reference/access-authn-authz/bootstrap-tokens/)
- [승인 컨트롤러](/docs/reference/access-authn-authz/admission-controllers/)
- [동적 승인 제어](/docs/reference/access-authn-authz/extensible-admission-controllers/)
- [인가](/ko/docs/reference/access-authn-authz/authorization/)
- [역할 기반 접근 제어](/docs/reference/access-authn-authz/rbac/)
- [속성 기반 접근 제어](/docs/reference/access-authn-authz/abac/)
- [노드 인가](/docs/reference/access-authn-authz/node/)
- [웹훅 인가](/docs/reference/access-authn-authz/webhook/)
- [인증서 서명 요청](/docs/reference/access-authn-authz/certificate-signing-requests/)
- [CSR 승인](/docs/reference/access-authn-authz/certificate-signing-requests/#approval-rejection)과
[인증서 서명](/docs/reference/access-authn-authz/certificate-signing-requests/#signing)을 포함함
- 서비스 어카운트
- [개발자 가이드](/docs/tasks/configure-pod-container/configure-service-account/)
- [관리](/ko/docs/reference/access-authn-authz/service-accounts-admin/)
content/ko/docs/reference/access-authn-authz/authorization.md
+3 -3
View File
@@ -11,7 +11,7 @@ weight: 60
<!-- body -->
쿠버네티스에서는 사용자의 요청이 인가(접근 권한을 부여) 받기 전에 사용자가 인증(로그인)되어야 한다.
인증에 대한 자세한 내용은 [쿠버네티스 API 접근 제어하기](/ko/docs/reference/access-authn-authz/controlling-access/)를
인증에 대한 자세한 내용은 [쿠버네티스 API 접근 제어하기](/ko/docs/concepts/security/controlling-access/)를
참고한다.
쿠버네티스는 REST API 요청에 공통적인 속성을 요구한다.
@@ -47,7 +47,7 @@ weight: 60
* **Resource** - 접근 중인 리소스의 ID 또는 이름(리소스 요청만 해당) -- `get`, `update`, `patch`, `delete` 동사를 사용하는 리소스 요청의 경우 리소스 이름을 지정해야 한다.
* **Subresource** - 접근 중인 하위 리소스(리소스 요청만 해당).
* **Namespace** - 접근 중인 오브젝트의 네임스페이스(네임스페이스에 할당된 리소스 요청만 해당)
* **API group** - 접근 중인 {{< glossary_tooltip text="API 그룹" term_id="api-group" >}}(리소스 요청에만 해당). 빈 문자열은 [핵심(core) API 그룹](/ko/docs/reference/using-api/api-overview/#api-그룹)을 지정한다.
* **API group** - 접근 중인 {{< glossary_tooltip text="API 그룹" term_id="api-group" >}}(리소스 요청에만 해당). 빈 문자열은 _핵심(core)_ [API 그룹](/ko/docs/reference/using-api/#api-그룹)을 지정한다.
## 요청 동사 결정
@@ -197,5 +197,5 @@ status:
## {{% heading "whatsnext" %}}
* 인증에 대한 자세한 내용은 [쿠버네티스 API 접근 제어하기](/ko/docs/reference/access-authn-authz/controlling-access/)에서 **인증**을 참조한다.
* 인증에 대한 자세한 내용은 [쿠버네티스 API 접근 제어하기](/ko/docs/concepts/security/controlling-access/)에서 **인증** 을 참조한다.
* 어드미션 제어에 대한 자세한 내용은 [어드미션 컨트롤러 사용하기](/docs/reference/access-authn-authz/admission-controllers/)를 참조한다.
content/ko/docs/reference/access-authn-authz/controlling-access.md
-161
View File
@@ -1,161 +0,0 @@
---
title: 쿠버네티스 API 접근 제어하기
content_type: concept
weight: 5
---
<!-- overview -->
이 페이지는 쿠버네티스 API에 대한 접근 제어의 개요를 제공한다.
<!-- body -->
사용자는 `kubectl`, 클라이언트 라이브러리
또는 REST 요청을 통해
[API에 접근한다](/ko/docs/tasks/access-application-cluster/access-cluster/).
사용자와 쿠버네티스 서비스 어카운트 모두 API에 접근할 수 있다.
요청이 API에 도달하면,
다음 다이어그램에 설명된 몇 가지 단계를 거친다.
![Diagram of request handling steps for Kubernetes API request](/images/docs/admin/access-control-overview.svg)
## 전송 보안
일반적인 쿠버네티스 클러스터에서 API는 443번 포트에서 서비스한다.
API 서버는 인증서를 제시한다.
이 인증서는 종종 자체 서명되기 때문에 일반적으로 사용자 머신의 `$USER/.kube/config`는
API 서버의 인증서에 대한 루트 인증서를 포함하며,
시스템 기본 루트 인증서 대신 사용된다.
`kube-up.sh`을 사용하여 클러스터를 직접 생성할 때
이 인증서는 일반적으로 `$USER/.kube/config`에 자동으로 기록된다.
클러스터에 여러 명의 사용자가 있는 경우, 작성자는 인증서를 다른 사용자와 공유해야 한다.
## 인증
TLS가 설정되면 HTTP 요청이 인증 단계로 넘어간다.
이는 다이어그램에 **1**단계로 표시되어 있다.
클러스터 생성 스크립트 또는 클러스터 관리자는
API 서버가 하나 이상의 인증기 모듈을 실행하도록 구성한다.
인증기는 [여기](/docs/reference/access-authn-authz/authentication/)에서 더 자세히 서술한다.
인증 단계로 들어가는 것은 온전한 HTTP 요청이지만
일반적으로 헤더 그리고/또는 클라이언트 인증서만 검사한다.
인증 모듈은 클라이언트 인증서, 암호 및 일반 토큰, 부트스트랩 토큰,
JWT 토큰(서비스 어카운트에 사용됨)을 포함한다.
여러 개의 인증 모듈을 지정할 수 있으며,
이 경우 하나의 인증 모듈이 성공할 때까지 각 모듈을 순차적으로 시도한다.
GCE에서는 클라이언트 인증서, 암호, 일반 토큰 및 JWT 토큰이 모두 사용 가능하다.
요청을 인증할 수 없는 경우 HTTP 상태 코드 401과 함께 거부된다.
이 외에는 사용자가 특정 `username`으로 인증되며,
이 username은 다음 단계에서 사용자의 결정에 사용할 수 있다.
일부 인증기는 사용자 그룹 관리 기능을 제공하는 반면,
이외의 인증기는 그렇지 않다.
쿠버네티스는 접근 제어 결정과 요청 기록 시 `usernames`를 사용하지만,
`user` 오브젝트를 가지고 있지 않고 usernames 나 기타 사용자 정보를
오브젝트 저장소에 저장하지도 않는다.
## 인가
특정 사용자로부터 온 요청이 인증된 후에는 인가되어야 한다. 이는 다이어그램에 **2**단계로 표시되어 있다.
요청은 요청자의 username, 요청된 작업 및 해당 작업이 영향을 주는 오브젝트를 포함해야 한다. 기존 정책이 요청된 작업을 완료할 수 있는 권한이 해당 사용자에게 있다고 선언하는 경우 요청이 인가된다.
예를 들어 Bob이 아래와 같은 정책을 가지고 있다면 `projectCaribou` 네임스페이스에서만 파드를 읽을 수 있다.
```json
{
"apiVersion": "abac.authorization.kubernetes.io/v1beta1",
"kind": "Policy",
"spec": {
"user": "bob",
"namespace": "projectCaribou",
"resource": "pods",
"readonly": true
}
}
```
Bob이 다음과 같은 요청을 하면 'projectCaribou' 네임스페이스의 오브젝트를 읽을 수 있기 때문에 요청이 인가된다.
```json
{
"apiVersion": "authorization.k8s.io/v1beta1",
"kind": "SubjectAccessReview",
"spec": {
"resourceAttributes": {
"namespace": "projectCaribou",
"verb": "get",
"group": "unicorn.example.org",
"resource": "pods"
}
}
}
```
Bob이 `projectCaribou` 네임스페이스에 있는 오브젝트에 쓰기(`create` 또는 `update`) 요청을 하면 그의 인가는 거부된다. 만약 Bob이 `projectFish`처럼 다른 네임스페이스의 오브젝트 읽기(`get`) 요청을 하면 그의 인가는 거부된다.
쿠버네티스 인가는 공통 REST 속성을 사용하여 기존 조직 전체 또는 클라우드 제공자 전체의 접근 제어 시스템과 상호 작용할 것을 요구한다. 이러한 제어 시스템은 쿠버네티스 API 이외의 다른 API와 상호작용할 수 있으므로 REST 형식을 사용하는 것이 중요하다.
쿠버네티스는 ABAC 모드, RBAC 모드, 웹훅 모드와 같은 여러 개의 인가 모듈을 지원한다. 관리자가 클러스터를 생성할 때 API 서버에서 사용해야 하는 인가 모듈을 구성했다. 인가 모듈이 2개 이상 구성되면 쿠버네티스가 각 모듈을 확인하고, 어느 모듈이 요청을 승인하면 요청을 진행할 수 있다. 모든 모듈이 요청을 거부하면 요청이 거부된다(HTTP 상태 코드 403).
인가 모듈을 사용한 정책 생성을 포함해 쿠버네티스 인가에 대해 더 배우려면 [인가 개요](/ko/docs/reference/access-authn-authz/authorization/)를 참조한다.
## 어드미션 제어
어드미션 제어 모듈은 요청을 수정하거나 거부할 수 있는 소프트웨어 모듈이다.
인가 모듈에서 사용할 수 있는 속성 외에도
어드미션 제어 모듈은 생성되거나 수정된 오브젝트 내용에 접근할 수 있다.
어드미션 컨트롤러는 오브젝트를 생성, 수정, 삭제 또는 (프록시에) 연결하는 요청에 따라 작동한다.
어드미션 컨트롤러는 단순히 객체를 읽는 요청에는 작동하지 않는다.
여러 개의 어드미션 컨트롤러가 구성되면 순서대로 호출된다.
이는 다이어그램에 **3**단계로 표시되어 있다.
인증 및 인가 모듈과 달리,
어드미션 제어 모듈이 거부되면 요청은 즉시 거부된다.
어드미션 제어 모듈은 오브젝트를 거부하는 것 외에도
필드의 복잡한 기본값을 설정할 수 있다.
사용 가능한 어드미션 제어 모듈은 [여기](/docs/reference/access-authn-authz/admission-controllers/)에 서술되어 있다.
요청이 모든 어드미션 제어 모듈을 통과하면 유효성 검사 루틴을 사용하여 해당 API 오브젝트를 검증한 후
오브젝트 저장소에 기록(**4**단계)된다.
## API 서버 포트와 IP
이전의 논의는 (일반적인 경우) API 서버의 보안 포트로 전송되는 요청에 적용된다.
API 서버는 실제로 다음과 같이 2개의 포트에서 서비스할 수 있다.
기본적으로 쿠버네티스 API 서버는 2개의 포트에서 HTTP 서비스를 한다.
1. `로컬호스트 포트`:
- 테스트 및 부트스트랩을 하기 위한 것이며 마스터 노드의 다른 구성요소
(스케줄러, 컨트롤러 매니저)가 API와 통신하기 위한 것이다.
- TLS가 없다.
- 기본 포트는 8080이며, `--insecure-port` 플래그를 사용하여 변경한다.
- 기본 IP는 로컬호스트(localhost)이며, `--insecure-bind-address` 플래그를 사용하여 변경한다.
- 요청이 인증 및 인가 모듈을 **우회한다**.
- 요청이 어드미션 제어 모듈(들)에 의해 처리된다.
- 호스트 접근 요구로부터 보호를 받는다.
2. `보안 포트`:
- 가능한 항상 사용하는 것이 좋다.
- TLS를 사용한다. `--tls-cert-file` 플래그로 인증서를 지정하고 `--tls-private-key-file` 플래그로 키를 지정한다.
- 기본 포트는 6443이며, `--secure-port` 플래그를 사용하여 변경한다.
- 기본 IP는 로컬호스트가 아닌 첫 번째 네트워크 인터페이스이며, `--bind-address` 플래그를 사용하여 변경한다.
- 요청이 인증 및 인가 모듈에 의해 처리된다.
- 요청이 어드미션 제어 모듈(들)에 의해 처리된다.
- 인증 및 인가 모듈을 실행한다.
GCE(구글 컴퓨트 엔진) 및 다른 클라우드 제공자에서 `kube-up.sh`로 클러스터를 생성하면
API 서버는 포트 443에서 서비스한다.
GCE에서는 외부 HTTPS가 API에 접근할 수 있도록 프로젝트에서 방화벽 규칙이 구성된다.
이외에 클러스터 설정 방법은 다양하다.
content/ko/docs/reference/command-line-tools-reference/feature-gates.md
+2 -2
View File
@@ -485,7 +485,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
- `PersistentLocalVolumes`: 파드에서 `local` 볼륨 유형의 사용을 활성화한다.
`local` 볼륨을 요청하는 경우 파드 어피니티를 지정해야 한다.
- `PodDisruptionBudget`: [PodDisruptionBudget](/docs/tasks/run-application/configure-pdb/) 기능을 활성화한다.
- `PodOverhead`: 파드 오버헤드를 판단하기 위해 [파드오버헤드(PodOverhead)](/ko/docs/concepts/configuration/pod-overhead/) 기능을 활성화한다.
- `PodOverhead`: 파드 오버헤드를 판단하기 위해 [파드오버헤드(PodOverhead)](/ko/docs/concepts/scheduling-eviction/pod-overhead/) 기능을 활성화한다.
- `PodPriority`: [우선 순위](/ko/docs/concepts/configuration/pod-priority-preemption/)를 기반으로 파드의 스케줄링 취소와 선점을 활성화한다.
- `PodReadinessGates`: 파드 준비성 평가를 확장하기 위해
`PodReadinessGate` 필드 설정을 활성화한다. 자세한 내용은 [파드의 준비성 게이트](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-readiness-gate)를
@@ -511,7 +511,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
- `RuntimeClass`: 컨테이너 런타임 구성을 선택하기 위해 [런타임클래스(RuntimeClass)](/ko/docs/concepts/containers/runtime-class/) 기능을 활성화한다.
- `ScheduleDaemonSetPods`: 데몬셋(DaemonSet) 컨트롤러 대신 기본 스케줄러로 데몬셋 파드를 스케줄링할 수 있다.
- `SCTPSupport`: 파드, 서비스, 엔드포인트, 엔드포인트슬라이스 및 네트워크폴리시 정의에서 _SCTP_ `protocol` 값을 활성화한다.
- `ServerSideApply`: API 서버에서 [SSA(Sever Side Apply)](/docs/reference/using-api/api-concepts/#server-side-apply) 경로를 활성화한다.
- `ServerSideApply`: API 서버에서 [SSA(Sever Side Apply)](/docs/reference/using-api/server-side-apply/) 경로를 활성화한다.
- `ServiceAccountIssuerDiscovery`: API 서버에서 서비스 어카운트 발행자에 대해 OIDC 디스커버리 엔드포인트(발급자 및 JWKS URL)를 활성화한다. 자세한 내용은 [파드의 서비스 어카운트 구성](/docs/tasks/configure-pod-container/configure-service-account/#service-account-issuer-discovery)을 참고한다.
- `ServiceAppProtocol`: 서비스와 엔드포인트에서 `AppProtocol` 필드를 활성화한다.
- `ServiceLoadBalancerFinalizer`: 서비스 로드 밸런서에 대한 Finalizer 보호를 활성화한다.
content/ko/docs/reference/command-line-tools-reference/kube-proxy.md
+343
View File
File diff suppressed because one or more lines are too long
content/ko/docs/reference/command-line-tools-reference/kubelet-authentication-authorization.md
+1 -1
View File
@@ -5,7 +5,7 @@ title: Kubelet 인증/인가
## 개요
kubelet의 HTTPS 엔드포인트는 다양한 민감도의 데이터에 대한 접근을 노출시키며,
kubelet의 HTTPS 엔드포인트는 다양한 민감도의 데이터에 대한 접근을 제공하는 API를 노출하며,
노드와 컨테이너 내에서 다양한 수준의 권한으로 작업을 수행할 수 있도록 허용한다.
이 문서는 kubelet의 HTTPS 엔드포인트에 대한 접근을 인증하고 인가하는 방법을 설명한다.
content/ko/docs/reference/glossary/container-lifecycle-hooks.md
+17
View File
@@ -0,0 +1,17 @@
---
title: 컨테이너 라이프사이클 훅(Container Lifecycle Hooks)
id: container-lifecycle-hooks
date: 2018-10-08
full_link: /ko/docs/concepts/containers/container-lifecycle-hooks/
short_description: >
라이프사이클 훅은 컨테이너 관리 라이프사이클에 이벤트를 노출하고 이벤트가 발생할 때 사용자가 코드를 실행할 수 있도록 한다.
aka:
tags:
- extension
---
라이프사이클 훅은 {{< glossary_tooltip text="컨테이너" term_id="container" >}} 관리 라이프사이클에 이벤트를 노출하고 이벤트가 발생할 때 사용자가 코드를 실행할 수 있도록 한다.
<!--more-->
컨테이너에는 두 개의 훅(컨테이너가 생성된 직후에 실행되는 PostStart와 컨테이너가 종료되기 직전에 차단되고 호출되는 PreStop)이 노출된다.
content/ko/docs/reference/glossary/container.md
+1 -1
View File
@@ -2,7 +2,7 @@
title: 컨테이너(Container)
id: container
date: 2018-04-12
full_link: /ko/docs/concepts/overview/what-is-kubernetes/#왜-컨테이너인가
full_link: /ko/docs/concepts/containers/
short_description: >
소프트웨어와 그것에 종속된 모든 것을 포함한 가볍고 휴대성이 높은 실행 가능 이미지.
content/ko/docs/reference/kubectl/jsonpath.md
+113
View File
@@ -0,0 +1,113 @@
---
title: JSONPath 지원
content_type: concept
weight: 25
---
<!-- overview -->
Kubectl은 JSONPath 템플릿을 지원한다.
<!-- body -->
JSONPath 템플릿은 중괄호 {}로 둘러싸인 JSONPath 표현식으로 구성된다.
Kubectl은 JSONPath 표현식을 사용하여 JSON 오브젝트의 특정 필드를 필터링하고 출력 형식을 지정한다.
원본 JSONPath 템플릿 구문 외에도 다음과 같은 기능과 구문이 유효하다.
1. 큰따옴표를 사용하여 JSONPath 표현식 내부의 텍스트를 인용한다.
2. 목록을 반복하려면 `range`, `end` 오퍼레이터를 사용한다.
3. 목록에서 뒤로 이동하려면 negative slice 인덱스를 사용한다. negative 인덱스는 목록을 "순환(wrap around)" 하지 않으며, `-index + listLength >= 0` 인 한 유효하다.
{{< note >}}
- 표현식은 항상 루트 오브젝트에서 시작하므로 `$` 오퍼레이터는 선택 사항이다.
- 결과 오브젝트는 String() 함수로 출력된다.
{{< /note >}}
JSON 입력 시 다음과 같다.
```json
{
"kind": "List",
"items":[
{
"kind":"None",
"metadata":{"name":"127.0.0.1"},
"status":{
"capacity":{"cpu":"4"},
"addresses":[{"type": "LegacyHostIP", "address":"127.0.0.1"}]
}
},
{
"kind":"None",
"metadata":{"name":"127.0.0.2"},
"status":{
"capacity":{"cpu":"8"},
"addresses":[
{"type": "LegacyHostIP", "address":"127.0.0.2"},
{"type": "another", "address":"127.0.0.3"}
]
}
}
],
"users":[
{
"name": "myself",
"user": {}
},
{
"name": "e2e",
"user": {"username": "admin", "password": "secret"}
}
]
}
```
Function | Description | Example | Result
--------------------|---------------------------|-----------------------------------------------------------------|------------------
`text` | 일반 텍스트 | `kind is {.kind}` | `kind is List`
`@` | 현재 오브젝트 | `{@}` | 입력과 동일
`.` or `[]` | 자식 오퍼레이터 | `{.kind}`, `{['kind']}` or `{['name\.type']}` | `List`
`..` | 재귀 하향(recursive descent)| `{..name}` | `127.0.0.1 127.0.0.2 myself e2e`
`*` | 와일드 카드. 모든 오브젝트 가져오기 | `{.items[*].metadata.name}` | `[127.0.0.1 127.0.0.2]`
`[start:end:step]` | 아래 첨자 오퍼레이터 | `{.users[0].name}` | `myself`
`[,]` | 조합 오퍼레이터 | `{.items[*]['metadata.name', 'status.capacity']}` | `127.0.0.1 127.0.0.2 map[cpu:4] map[cpu:8]`
`?()` | 필터 | `{.users[?(@.name=="e2e")].user.password}` | `secret`
`range`, `end` | 반복 목록 | `{range .items[*]}[{.metadata.name}, {.status.capacity}] {end}` | `[127.0.0.1, map[cpu:4]] [127.0.0.2, map[cpu:8]]`
`''` | 해석된 문자열 인용 | `{range .items[*]}{.metadata.name}{'\t'}{end}` | `127.0.0.1 127.0.0.2`
`kubectl` 및 JSONPath 표현식을 사용하는 예는 다음과 같다.
```shell
kubectl get pods -o json
kubectl get pods -o=jsonpath='{@}'
kubectl get pods -o=jsonpath='{.items[0]}'
kubectl get pods -o=jsonpath='{.items[0].metadata.name}'
kubectl get pods -o=jsonpath="{.items[*]['metadata.name', 'status.capacity']}"
kubectl get pods -o=jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.startTime}{"\n"}{end}'
```
{{< note >}}
윈도우에서 공백이 포함된 JSONPath 템플릿을 큰따옴표(위의 bash에 표시된 작은따옴표가 아님)로 묶어야 한다. 즉, 템플릿의 모든 문자 주변에 작은따옴표 또는 이스케이프된 큰따옴표를 사용해야 한다. 예를 들면, 다음과 같다.
```cmd
kubectl get pods -o=jsonpath="{range .items[*]}{.metadata.name}{'\t'}{.status.startTime}{'\n'}{end}"
kubectl get pods -o=jsonpath="{range .items[*]}{.metadata.name}{\"\t\"}{.status.startTime}{\"\n\"}{end}"
```
{{< /note >}}
{{< note >}}
JSONPath 정규식은 지원되지 않는다. 정규 표현식을 이용해 매치하려면 `jq`와 같은 도구를 사용하면 된다.
```shell
# kubectl은 JSONPath 출력에 대한 정규 표현식을 지원하지 않는다.
# 다음 커맨드는 작동하지 않는다.
kubectl get pods -o jsonpath='{.items[?(@.metadata.name=~/^test$/)].metadata.name}'
# 다음 커맨드는 원하는 결과를 얻는다.
kubectl get pods -o json | jq -r '.items[] | select(.metadata.name | test("test-")).spec.containers[].image'
```
{{< /note >}}
content/ko/docs/reference/scheduling/config.md
+253
View File
@@ -0,0 +1,253 @@
---
title: 스케줄러 구성
content_type: concept
weight: 20
---
{{< feature-state for_k8s_version="v1.19" state="beta" >}}
구성 파일을 작성하고 해당 경로를 커맨드 라인 인수로 전달하여
`kube-scheduler` 의 동작을 사용자 정의할 수 있다.
<!-- overview -->
<!-- body -->
스케줄링 프로파일(Profile)을 사용하면 {{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}}에서
여러 단계의 스케줄링을 구성할 수 있다.
각 단계는 익스텐션 포인트(extension point)를 통해 노출된다. 플러그인은 이러한
익스텐션 포인트 중 하나 이상을 구현하여 스케줄링 동작을 제공한다.
컴포넌트 구성 API([`v1alpha1`](https://pkg.go.dev/k8s.io/kube-scheduler@v0.18.0/config/v1alpha1?tab=doc#KubeSchedulerConfiguration)
또는 [`v1alpha2`](https://pkg.go.dev/k8s.io/kube-scheduler@v0.18.0/config/v1alpha2?tab=doc#KubeSchedulerConfiguration))를
사용하고, `kube-scheduler --config <filename>`을 실행하여
스케줄링 프로파일을 지정할 수 있다.
`v1alpha2` API를 사용하면 [여러 프로파일](#여러-프로파일)을
실행하도록 kube-scheduler를 구성할 수 있다.
최소 구성은 다음과 같다.
```yaml
apiVersion: kubescheduler.config.k8s.io/v1beta1
kind: KubeSchedulerConfiguration
clientConnection:
kubeconfig: /etc/srv/kubernetes/kube-scheduler/kubeconfig
```
## 프로파일
스케줄링 프로파일을 사용하면 {{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}}에서
여러 단계의 스케줄링을 구성할 수 있다.
각 단계는 [익스텐션 포인트](#익스텐션-포인트)에 노출된다.
[플러그인](#스케줄링-플러그인)은 이러한 익스텐션 포인트 중
하나 이상을 구현하여 스케줄링 동작을 제공한다.
`kube-scheduler` 의 단일 인스턴스를 구성하여
[여러 프로파일](#여러-프로파일)을 실행할 수 있다.
### 익스텐션 포인트
스케줄링은 다음 익스텐션 포인트를 통해 노출되는 일련의 단계에서
발생한다.
1. `QueueSort`: 이 플러그인은 스케줄링 대기열에서 보류 중인 파드를
정렬하는 데 사용되는 정렬 기능을 제공한다. 대기열 정렬 플러그인은 한 번에 단 하나만 활성화될 수 있다.
사용할 수 있다.
1. `PreFilter`: 이 플러그인은 필터링하기 전에 파드 또는 클러스터에 대한 정보를
사전 처리하거나 확인하는 데 사용된다. 이 플러그인은 파드를 unschedulable로
표시할 수 있다.
1. `Filter`: 이 플러그인은 스케줄링 정책의 단정(Predicates)과 동일하며
파드를 실행할 수 없는 노드를 필터링하는 데 사용된다. 필터는
구성된 순서대로 호출된다. 노드가 모든 필터를 통과하지 않으면 파드는 unschedulable로
표시된다.
1. `PreScore`: 이것은 사전 스코어링 작업을 수행하는 데 사용할 수 있는
정보성 익스텐션 포인트이다.
1. `Score`: 이 플러그인은 필터링 단계를 통과한 각 노드에 점수를
제공한다. 그런 다음 스케줄러는 가중치 합계가 가장 높은
노드를 선택한다.
1. `Reserve`: 지정된 파드에 리소스가 예약된 경우 플러그인에
알리는 정보성 익스텐션 포인트이다. 플러그인은 또한
`Reserve` 도중 또는 이후에 실패한 경우 호출 되는 `Unreserve` 호출을
구현한다.
1. `Permit`: 이 플러그인은 파드 바인딩을 방지하거나 지연시킬 수 있다.
1. `PreBind`: 이 플러그인은 파드가 바인딩되기 전에 필요한 모든 작업을 수행한다.
1. `Bind`: 플러그인은 파드를 노드에 바인딩한다. Bind 플러그인은 순서대로 호출되며
일단 바인딩이 완료되면 나머지 플러그인은 건너뛴다. Bind
플러그인은 적어도 하나 이상 필요하다.
1. `PostBind`: 파드가 바인드된 후 호출되는
정보성 익스텐션 포인트이다.
각 익스텐션 포인트에 대해 특정 [기본 플러그인](#스케줄링-플러그인)을 비활성화하거나
자체 플러그인을 활성화할 수 있다. 예를 들면, 다음과 같다.
```yaml
apiVersion: kubescheduler.config.k8s.io/v1beta1
kind: KubeSchedulerConfiguration
profiles:
- plugins:
score:
disabled:
- name: NodeResourcesLeastAllocated
enabled:
- name: MyCustomPluginA
weight: 2
- name: MyCustomPluginB
weight: 1
```
비활성화된 배열의 이름으로 `*` 를 사용하여 해당 익스텐션 포인트에 대한
모든 기본 플러그인을 비활성화할 수 있다. 원하는 경우, 플러그인 순서를 재정렬하는 데
사용할 수도 있다.
### 스케줄링 플러그인
1. `UnReserve`: 파드가 예약된 후 거부되고 `Permit` 플러그인에 의해 보류된 경우
호출되는 정보성 익스텐션 포인트이다.
## 스케줄링 플러그인
기본적으로 활성화된 다음의 플러그인은 이들 익스텐션 포인트 중
하나 이상을 구현한다.
- `SelectorSpread`: {{< glossary_tooltip text="서비스" term_id="service" >}},
{{< glossary_tooltip text="레플리카셋(ReplicaSets)" term_id="replica-set" >}} 및
{{< glossary_tooltip text="스테이트풀셋(StatefulSets)" term_id="statefulset" >}}에
속하는 파드에 대해 노드 간 분산을 선호한다.
익스텐션 포인트: `PreScore`, `Score`.
- `ImageLocality`: 파드가 실행하는 컨테이너 이미지가 이미 있는 노드를
선호한다.
익스텐션 포인트: `Score`.
- `TaintToleration`: [테인트(taint)와 톨러레이션(toleration)](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)을
구현한다.
익스텐션 포인트 구현: `Filter`, `Prescore`, `Score`.
- `NodeName`: 파드 명세 노드 이름이 현재 노드와 일치하는지 확인한다.
익스텐션 포인트: `Filter`.
- `NodePorts`: 노드에 요청된 파드 포트에 대해 사용 가능한 포트가 있는지 확인한다.
익스텐션 포인트: `PreFilter`, `Filter`.
- `NodePreferAvoidPods`: 노드 {{< glossary_tooltip text="어노테이션" term_id="annotation" >}}
`scheduler.alpha.kubernetes.io/preferAvoidPods` 에 따라
노드 점수를 매긴다.
익스텐션 포인트: `Score`.
- `NodeAffinity`: [노드 셀렉터](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#노드-셀렉터-nodeselector)와
[노드 어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#노드-어피니티)를
구현한다.
익스텐션 포인트: `Filter`, `Score`.
- `PodTopologySpread`: [파드 토폴로지 분배](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/)를
구현한다.
익스텐션 포인트: `PreFilter`, `Filter`, `PreScore`, `Score`.
- `NodeUnschedulable`: `.spec.unschedulable` 이 true로 설정된 노드를
필터링한다.
익스텐션 포인트: `Filter`.
- `NodeResourcesFit`: 노드에 파드가 요청하는 모든 리소스가 있는지
확인한다.
익스텐션 포인트: `PreFilter`, `Filter`.
- `NodeResourcesBalancedAllocation`: 파드가 스케줄된 경우, 보다 균형잡힌 리소스 사용량을
얻을 수 있는 노드를 선호한다.
익스텐션 포인트: `Score`.
- `NodeResourcesLeastAllocated`: 리소스 할당이 적은 노드를
선호한다.
익스텐션 포인트: `Score`.
- `VolumeBinding`: 노드에 요청된 {{< glossary_tooltip text="볼륨" term_id="volume" >}}이 있는지
또는 바인딩할 수 있는지 확인한다.
익스텐션 포인트: `PreFilter`, `Filter`, `Reserve`, `PreBind`.
- `VolumeRestrictions`: 노드에 마운트된 볼륨이 볼륨 제공자에 특정한
제한 사항을 충족하는지 확인한다.
익스텐션 포인트: `Filter`.
- `VolumeZone`: 요청된 볼륨이 가질 수 있는 영역 요구 사항을 충족하는지
확인한다.
익스텐션 포인트: `Filter`.
- `NodeVolumeLimits`: 노드에 대해 CSI 볼륨 제한을 충족할 수 있는지
확인한다.
익스텐션 포인트: `Filter`.
- `EBSLimits`: 노드에 대해 AWS EBS 볼륨 제한을 충족할 수 있는지 확인한다.
익스텐션 포인트: `Filter`.
- `GCEPDLimits`: 노드에 대해 GCP-PD 볼륨 제한을 충족할 수 있는지 확인한다.
익스텐션 포인트: `Filter`.
- `AzureDiskLimits`: 노드에 대해 Azure 디스크 볼륨 제한을 충족할 수 있는지
확인한다.
익스텐션 포인트: `Filter`.
- `InterPodAffinity`: [파드 간 어피니티 및 안티-어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#파드간-어피니티와-안티-어피니티)를
구현한다.
익스텐션 포인트: `PreFilter`, `Filter`, `PreScore`, `Score`.
- `PrioritySort`: 기본 우선 순위 기반 정렬을 제공한다.
익스텐션 포인트: `QueueSort`.
- `DefaultBinder`: 기본 바인딩 메커니즘을 제공한다.
익스텐션 포인트: `Bind`.
- `DefaultPreemption`: 기본 선점 메커니즘을 제공한다.
익스텐션 포인트: `PostFilter`.
기본으로 활성화되지 않는 다음의 플러그인을
컴포넌트 구성 API를 통해 활성화할 수도 있다.
- `NodeResourcesMostAllocated`: 리소스 할당이 많은 노드를
선호한다.
익스텐션 포인트: `Score`.
- `RequestedToCapacityRatio`: 할당된 리소스의 구성된 기능에 따라 노드를
선호한다.
익스텐션 포인트: `Score`.
- `NodeResourceLimits`: 파드 리소스 제한을 충족하는 노드를 선호한다.
익스텐션 포인트: `PreScore`, `Score`.
- `CinderVolume`: 노드에 대해 OpenStack Cinder 볼륨 제한을 충족할 수 있는지
확인한다.
익스텐션 포인트: `Filter`.
- `NodeLabel`: Filters and / or scores a node according to configured
{{< glossary_tooltip text="label(s)" term_id="label" >}}.
익스텐션 포인트: `Filter`, `Score`.
- `ServiceAffinity`: {{< glossary_tooltip text="서비스" term_id="service" >}}에
속한 파드가 구성된 레이블로 정의된 노드 집합에 맞는지
확인한다. 이 플러그인은 또한 서비스에 속한 파드를 노드 간에
분산하는 것을 선호한다.
익스텐션 포인트: `PreFilter`, `Filter`, `Score`.
### 여러 프로파일
둘 이상의 프로파일을 실행하도록 `kube-scheduler` 를 구성할 수 있다.
각 프로파일에는 연관된 스케줄러 이름이 있으며 [익스텐션 포인트](#익스텐션-포인트)에 구성된
다른 플러그인 세트를 가질 수 있다.
다음의 샘플 구성을 사용하면, 스케줄러는 기본 플러그인이 있는
프로파일과 모든 스코어링 플러그인이 비활성화된 프로파일의 두 가지 프로파일로
실행된다.
```yaml
apiVersion: kubescheduler.config.k8s.io/v1beta1
kind: KubeSchedulerConfiguration
profiles:
- schedulerName: default-scheduler
- schedulerName: no-scoring-scheduler
plugins:
preScore:
disabled:
- name: '*'
score:
disabled:
- name: '*'
```
특정 프로파일에 따라 스케줄하려는 파드는
`.spec.schedulerName` 에 해당 스케줄러 이름을 포함할 수 있다.
기본적으로, 스케줄러 이름 `default-scheduler` 를 가진 하나의 프로파일이 생성된다.
이 프로파일에는 위에서 설명한 기본 플러그인이 포함되어 있다. 둘 이상의
프로파일을 선언할 때, 각각에 대한 고유한 스케줄러 이름이 필요하다.
파드가 스케줄러 이름을 지정하지 않으면, kube-apiserver는 이를 `default-scheduler` 로
설정한다. 따라서, 해당 파드를 스케줄하려면 이 스케줄러 이름을 가진 프로파일이
있어야 한다.
{{< note >}}
파드의 스케줄링 이벤트에는 ReportingController로 `.spec.schedulerName` 이 있다.
리더 선출을 위한 이벤트는 목록에서 첫 번째 프로파일의 스케줄러 이름을
사용한다.
{{< /note >}}
{{< note >}}
모든 프로파일은 QueueSort 익스텐션 포인트에서 동일한 플러그인을 사용해야 하며
동일한 구성 파라미터(해당하는 경우)를 가져야 한다. 그 이유는 스케줄러가 보류 중 상태인 파드 대기열을
단 하나만 가질 수 있기 때문이다.
{{< /note >}}
## {{% heading "whatsnext" %}}
* [kube-scheduler 레퍼런스](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-scheduler/) 읽어보기
* [스케줄링](/ko/docs/concepts/scheduling-eviction/kube-scheduler/)에 대해 알아보기
content/ko/docs/reference/tools.md
+2 -2
View File
@@ -20,7 +20,7 @@ content_type: concept
## Minikube
[`minikube`](/ko/docs/tasks/tools/install-minikube/)는 개발과 테스팅 목적으로 하는
[`minikube`](https://minikube.sigs.k8s.io/docs/)는 개발과 테스팅 목적으로 하는
단일 노드 쿠버네티스 클러스터를 로컬 워크스테이션에서
쉽게 구동시키는 도구이다.
@@ -44,7 +44,7 @@ Helm의 용도
## Kompose
[`Kompose`](https://github.com/kubernetes-incubator/kompose)는 도커 컴포즈 유저들이 쿠버네티스로 이동하는데 도움이 되는 도구이다.
[`Kompose`](https://github.com/kubernetes/kompose)는 도커 컴포즈 유저들이 쿠버네티스로 이동하는데 도움이 되는 도구이다.
Kompose의 용도
content/ko/docs/reference/using-api/_index.md
+118 -1
View File
@@ -1,4 +1,121 @@
---
title: 쿠버네티스 API 사용하기
title: 쿠버네티스 API 개요
content_type: concept
weight: 10
card:
name: 레퍼런스
weight: 50
title: API 개요
---
<!-- overview -->
이 섹션은 쿠버네티스 API에 대한 참조 정보를 제공한다.
REST API는 쿠버네티스의 근본적인 구조이다. 모든 조작,
컴포넌트 간의 통신과 외부 사용자의 명령은 API 서버에서 처리할 수 있는
REST API 호출이다. 따라서, 쿠버네티스 플랫폼 안의 모든 것은
API 오브젝트로 취급되고,
[API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)에 상응하는 항목이 있다.
[쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)는
쿠버네티스 버전 {{< param "version" >}}에 대한 API가 나열되어 있다.
일반적인 배경 정보를 보려면,
[쿠버네티스 API](/ko/docs/concepts/overview/kubernetes-api/)를 참고한다.
[쿠버네티스 API에 대한 접근 제어](/ko/docs/concepts/security/controlling-access/)는
클라이언트가 쿠버네티스 API 서버에 인증하는 방법과
요청이 승인되는 방법을 설명한다.
## API 버전 규칙
JSON과 Protobuf 직렬화 스키마 모두 스키마 변경에 대해서
동일한 가이드라인을 따른다. 이후 설명에서는 이 형식 모두를 다룬다.
API 버전 규칙과 소프트웨어 버전 규칙은 간접적으로 연관된다.
[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)에서
각 수준의 기준에 대한 더 많은 정보를 찾을 수 있다.
아래는 각 수준의 기준에 대한 요약이다.
- 알파(Alpha):
- 버전 이름에 `alpha`가 포함된다(예: `v1alpha1`).
- 버그가 있을 수도 있다. 이 기능을 활성화하면 버그에 노출될 수 있다.
기본적으로 비활성화되어 있다.
- 기능에 대한 기술 지원이 언제든 공지 없이 중단될 수 있다.
- 다음 소프트웨어를 릴리스할 때 공지 없이 API의 호환성이 깨지는 방식으로 변경될 수 있다.
- 버그에 대한 위험이 높고 장기간 지원되지 않으므로
단기간 테스트 용도의 클러스터에서만 사용하기를 권장한다.
- 베타(Beta):
- 버전 이름에 `beta`가 포함된다(예: `v2beta3`).
- 코드가 잘 테스트 되었다. 이 기능을 활성화해도 안전하다.
기본적으로 활성화되어 있다.
- 구체적인 내용이 바뀔 수는 있지만, 전반적인 기능에 대한 기술 지원이 중단되지 않는다.
- 오브젝트에 대한 스키마나 문법이 다음 베타 또는 안정화 릴리스에서
호환되지 않는 방식으로 바뀔 수도 있다. 이런 경우, 다음 버전으로
이관할 수 있는 가이드가 제공된다. 스키마 변경은 API 오브젝트의 삭제, 편집 또는 재생성이
필요할 수도 있다. 편집 절차는 좀 생각해볼 필요가 있다.
이 기능에 의존하고 있는 애플리케이션은 다운타임이 필요할 수도 있다.
- 이 소프트웨어는 프로덕션 용도로 권장하지 않는다. 이후 여러 버전에서
호환되지 않는 변경 사항이 적용될 수 있다. 복수의 클러스터를 가지고 있어서
독립적으로 업그레이드할 수 있다면, 이런 제약에서 벗어날 수도 있다.
{{< note >}}
베타 기능을 사용해보고 피드백을 제공하자. 기능이 베타 수준을 벗어난 이후에는
실질적으로 더 많은 변경이 어렵다.
{{< /note >}}
- 안정화(Stable):
- 버전 이름이 `vX`이고 `X` 는 정수다.
- 안정화 버전의 기능은 이후 여러 버전에 걸쳐서 소프트웨어 릴리스에 포함된다.
## API 그룹
[API 그룹](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md)은
쿠버네티스 API를 더 쉽게 확장하게 해준다.
API 그룹은 REST 경로와 직렬화된 오브젝트의 `apiVersion` 필드에
명시된다.
쿠버네티스에는 다음과 같은 다양한 API 그룹이 있다.
* *핵심* (또는 *레거시* 라고 불리는) 그룹은 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" >}}/#-strong-api-groups-strong-)에서 확인할 수 있다.
## API 그룹 활성화 또는 비활성화
특정 리소스 및 API 그룹은 기본적으로 활성화된다. API 서버에서
`--runtime-config` 를 설정하여 활성화 또는 비활성화할 수 있다.
`--runtime-config` 플래그는 API 서버의 런타임 구성을 설명하는
쉼표로 구분된 `<key>=<value>` 쌍을 허용한다. 만약 `=<value>`
부분을 생략하면, `=true` 가 명시된 것처럼 취급한다. 예를 들면, 다음과 같다.
- `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)에
대한 디자인 문서 읽기
content/ko/docs/reference/using-api/api-overview.md
-113
View File
@@ -1,113 +0,0 @@
---
title: 쿠버네티스 API 개요
content_type: concept
weight: 10
card:
name: 레퍼런스
weight: 50
title: API 개요
---
<!-- overview -->
이 페이지는 쿠버네티스 API에 대한 개요를 제공한다.
<!-- body -->
REST API는 쿠버네티스의 근본적인 구조이다. 모든 조작,
컴포넌트 간의 통신과 외부 사용자의 명령은 API 서버에서 처리할 수 있는
REST API 호출이다. 따라서, 쿠버네티스 플랫폼 안의 모든 것은
API 오브젝트로 취급되고,
[API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)에 상응하는 항목이 있다.
## API 버전 규칙
JSON과 Protobuf 직렬화 스키마 모두 스키마 변경에 대해서
동일한 가이드라인을 따른다. 이후 설명에서는 이 형식 모두를 다룬다.
API 버전 규칙과 소프트웨어 버전 규칙은 간접적으로 연관된다.
[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)에서
각 수준의 기준에 대한 더 많은 정보를 찾을 수 있다.
아래는 각 수준의 기준에 대한 요약이다.
- 알파(Alpha) 수준:
- 버전 이름에 `alpha`가 포함된다. (예: `v1alpha1`)
- 버그가 있을 수도 있다. 이 기능을 활성화하면 버그가 노출될 수 있다.
기본적으로 비활성화되어 있다.
- 기능에 대한 기술 지원이 언제든 공지 없이 중단될 수 있다.
- 다음 소프트웨어를 릴리스할 때 공지 없이 API의 호환성이 깨지는 방식으로 변경될 수 있다.
- 버그의 위험이 높고 장기간 지원되지 않으므로
단기간 테스트 용도의 클러스터에서만 사용하기를 권장한다.
- 베타(Beta) 수준:
- 버전 이름에 `beta`가 포함된다. (예: `v2beta3`).
- 코드가 잘 테스트되었다. 이 기능을 활성화 시켜도 안전하다.
기본적으로 활성화되어 있다.
- 구체적인 내용이 바뀔 수는 있지만, 전반적인 기능에 대한 기술 지원이 중단되지 않는다.
- 오브젝트에 대한 스키마나 문법이 다음 베타 또는 안정화 릴리스에서
호환되지 않는 방식으로 바뀔 수도 있다. 이런 경우, 다음 버전으로
이관할 수 있는 가이드가 제공된다. 스키마 변경은 API 오브젝트의 삭제, 편집 또는 재생성이
필요할 수도 있다. 편집 절차는 좀 생각해볼 필요가 있다.
이 기능에 의존하고 있는 애플리케이션은 다운타임이 필요할 수도 있다.
- 이 소프트웨어는 프로덕션 용도로 권장되지 않는다. 이후 여러 버전에서
호환되지 않는 변경 사항이 적용될 수 있다. 복수의 클러스터를 가지고 있어서
독립적으로 업그레이드할 수 있다면, 이런 제약에서 벗어날 수도 있다.
{{< note >}}
베타 기능을 사용해보고 피드백을 제공하자. 기능이 베타 수준을 벗어난 이후에는
실질적으로 더 많은 변경이 어렵다.
{{< /note >}}
- 안정화(stable) 수준:
- 버전 이름이 `vX`이고 `X` 는 정수다.
- 안정화 버전의 기능은 이후 여러 버전에 걸쳐서 소프트웨어 릴리스에 포함된다.
## API 그룹
[API 그룹](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md)은
쿠버네티스 API를 더 쉽게 확장하게 해준다.
API 그룹은 REST 경로와 직렬화된 객체의 `apiVersion` 필드에
명시된다.
현재 다음과 같은 다양한 API 그룹이 사용되고 있다.
* *핵심* (또는 *레거시* 라고 불리는) 그룹은 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" >}}/)에서 확인할 수 있다.
## API 그룹 활성화 또는 비활성화 {#enabling-or-disabling}
특정 리소스 및 API 그룹은 기본적으로 활성화된다. API 서버에서
`--runtime-config` 를 설정하여 활성화 또는 비활성화할 수 있다.
`--runtime-config` 플래그는 API 서버의 런타임 구성을 설명하는
쉼표로 구분된 `<key>=<value>` 쌍을 허용한다. 예를 들면, 다음과 같다.
- `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)에
대한 디자인 문서 읽기
content/ko/docs/reference/using-api/client-libraries.md
+1 -1
View File
@@ -10,7 +10,7 @@ weight: 30
<!-- body -->
[쿠버네티스 REST API](/ko/docs/reference/using-api/api-overview/)를 사용해 애플리케이션을 작성하기 위해
[쿠버네티스 REST API](/ko/docs/reference/using-api/)를 사용해 애플리케이션을 작성하기 위해
API 호출 또는 요청/응답 타입을 직접 구현할 필요는 없다.
사용하고 있는 프로그래밍 언어를 위한 클라이언트 라이브러리를 사용하면 된다.