This PR is the third Korean l10n work for release-1.14. (#14185)
* Fixed the ko-typo (#13983) * ko: Update outdated files in dev-1.14-ko.3 (#14055) * Translate concepts/overview/working-with-objects/annotations in Korean (#14115) Co-authored-by: Chirag Shah <programmergeekynerd9696@gmail.com> Co-authored-by: June Yi <june.yi@samsung.com> Co-authored-by: Claudia J. Kang <claudiajkang@gmail.com> Co-authored-by: uncle-elephant <48449695+uncle-elephant@users.noreply.github.com> Co-authored-by: Seokho <shsongist@gmail.com>
This commit is contained in:
Claudia J.Kang
committed by
Kubernetes Prow Robot
Kubernetes Prow Robot
parent
df287989b2
commit
1054269082
@@ -37,7 +37,7 @@ card:
|
||||
Infrastructure as a Service (IaaS)의 유연함을 더해 주며, 인프라스트럭처
|
||||
제공자 간 이식이 가능하게 해준다.
|
||||
|
||||
## 어떻게 쿠버네티스가 플랫폼이 될 수 있는가?
|
||||
## 어떻게 쿠버네티스가 플랫폼인가
|
||||
|
||||
쿠버네티스가 제공하는 많은 기능이 있지만, 신규 기능을 통해 혜택을 얻을 수 있는
|
||||
새로운 시나리오는 항상 있게 마련이다. 개발자의 생산성을 극대화할 수 있도록
|
||||
@@ -101,7 +101,7 @@ PaaS가 일반적으로 제공하는 배포, 스케일링, 로드 밸런싱, 로
|
||||
A에서 C로 어떻게 갔는지는 상관이 없다. 중앙화된 제어도 필요치 않다. 이로써 시스템이
|
||||
보다 더 사용하기 쉬워지고, 강력해지며, 견고하고, 회복력을 갖추게 되며, 확장 가능해진다.
|
||||
|
||||
## 왜 컨테이너인가?
|
||||
## 왜 컨테이너인가
|
||||
|
||||
왜 컨테이너를 써야하는지 이유를 알고 싶은가?
|
||||
|
||||
@@ -165,7 +165,7 @@ A에서 C로 어떻게 갔는지는 상관이 없다. 중앙화된 제어도 필
|
||||
* **지원 사용량**:
|
||||
고효율 고집적.
|
||||
|
||||
## 쿠버네티스(Kubernetes)의 뜻은? K8s?
|
||||
## 쿠버네티스의 뜻은? K8s?
|
||||
|
||||
**쿠버네티스**는 *키잡이* 나 *파일럿* 을 뜻하는 그리스어에서 유래했으며,
|
||||
이는 *governor*(통치자)와 [cybernetic(인공두뇌학)](http://www.etymonline.com/index.php?term=cybernetics)의
|
||||
|
||||
@@ -0,0 +1,76 @@
|
||||
---
|
||||
title: 어노테이션
|
||||
content_template: templates/concept
|
||||
weight: 50
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
쿠버네티스 어노테이션을 사용하여 임의의 비-식별 메타데이터를
|
||||
오브젝트에 첨부할 수 있다. 도구 및 라이브러리와 같은 클라이언트는 이 메타데이터를 검색할 수 있다.
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
## 오브젝트에 메타데이터 첨부
|
||||
|
||||
레이블이나 어노테이션을 사용하여 쿠버네티스
|
||||
오브젝트에 메타데이터를 첨부할 수 있다. 레이블을 사용하여 오브젝트를 선택하고, 특정 조건을 만족하는 오브젝트
|
||||
컬렉션을 찾을 수 있다. 반면에, 어노테이션은
|
||||
오브젝트를 식별하고 선택하는데 사용되지 않는다. 어노테이션의 메타데이터는
|
||||
작거나 크고, 구조적이거나 구조적이지 않을 수 있으며, 레이블에서
|
||||
허용되지 않는 문자를 포함할 수 있다.
|
||||
|
||||
어노테이션은 레이블과 같이 키/값 맵이다.
|
||||
|
||||
```json
|
||||
"metadata": {
|
||||
"annotations": {
|
||||
"key1" : "value1",
|
||||
"key2" : "value2"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
다음은 어노테이션에 기록할 수 있는 정보의 예제이다.
|
||||
|
||||
* 필드는 선언적 구성 계층에 의해 관리된다. 이러한 필드를 어노테이션으로 첨부하는 것은
|
||||
클라이언트 또는 서버가 설정한 기본 값,
|
||||
자동 생성된 필드, 그리고
|
||||
오토사이징 또는 오토스케일링 시스템에 의해 설정된 필드와 구분된다.
|
||||
|
||||
* 빌드, 릴리스, 또는 타임 스탬프, 릴리즈 ID, git 브랜치,
|
||||
PR 번호, 이미지 해시 및 레지스트리 주소와 같은 이미지 정보.
|
||||
|
||||
* 로깅, 모니터링, 분석 또는 감사 리포지터리에 대한 포인터.
|
||||
|
||||
* 디버깅 목적으로 사용될 수 있는 클라이언트 라이브러리 또는 도구 정보:
|
||||
예를 들면, 이름, 버전, 그리고 빌드 정보.
|
||||
|
||||
* 다른 생태계 구성 요소의 관련 오브젝트 URL과 같은
|
||||
사용자 또는 도구/시스템 출처 정보.
|
||||
|
||||
* 경량 롤아웃 도구 메타데이터. 예: 구성 또는 체크포인트
|
||||
|
||||
* 책임자의 전화번호 또는 호출기 번호, 또는 팀 웹 사이트 같은
|
||||
해당 정보를 찾을 수 있는 디렉토리 진입점.
|
||||
|
||||
* 행동을 수정하거나 비표준 기능을 수행하기 위한
|
||||
최종 사용자의 지시 사항.
|
||||
|
||||
어노테이션을 사용하는 대신, 이 유형의 정보를
|
||||
외부 데이터베이스 또는 디렉토리에 저장할 수 있지만, 이는 배포, 관리, 인트로스펙션(introspection) 등을 위한
|
||||
공유 클라이언트 라이브러리와 도구 생성을
|
||||
훨씬 더 어렵게 만들 수 있다.
|
||||
|
||||
## 문법과 캐릭터 셋
|
||||
|
||||
_어노테이션_ 은 키/값 쌍이다. 유효한 어노테이션 키에는 두 개의 세그먼트가 있다. 두 개의 세그먼트는 선택적인 접두사와 이름(name)이며, 슬래시(`/`)로 구분된다. 이름 세그먼트는 필수이며, 영문 숫자(`[a-z0-9A-Z]`)로 시작하고 끝나는 63자 이하이어야 하고, 사이에 대시(`-`), 밑줄(`_`), 점(`.`)이 들어갈 수 있다. 접두사는 선택적이다. 지정된 경우, 접두사는 DNS 하위 도메인이어야 한다. 점(`.`)으로 구분된 일련의 DNS 레이블은 총 253자를 넘지 않고, 뒤에 슬래시(`/`)가 붙는다.
|
||||
|
||||
접두사가 생략되면, 어노테이션 키는 사용자에게 비공개로 간주된다. 최종 사용자 오브젝트에 어노테이션을 추가하는 자동화된 시스템 구성 요소(예 :`kube-scheduler`, `kube-controller-manager`, `kube-apiserver`, `kubectl`, 또는 다른 써드파티 자동화)는 접두사를 지정해야 한다.
|
||||
|
||||
`kubernetes.io/`와 `k8s.io/` 접두사는 쿠버네티스 핵심 구성 요소를 위해 예약되어 있다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
[레이블과 셀렉터](/docs/concepts/overview/working-with-objects/labels/)에 대해 알아본다.
|
||||
{{% /capture %}}
|
||||
@@ -20,13 +20,13 @@ card:
|
||||
* 그 애플리케이션이 이용할 수 있는 리소스
|
||||
* 그 애플리케이션이 어떻게 재구동 정책, 업그레이드, 그리고 내고장성과 같은 것에 동작해야 하는지에 대한 정책
|
||||
|
||||
쿠버네티스 오브젝트는 하나의 "의도를 담은 레코드" 이다. 오브젝트를 생성하게 되면, 쿠버네티스 시스템은 그 오브젝트 생성을 보장하기 위해 지속적으로 작동할 것이다. 오브젝트를 생성함으로써, 여러분이 클러스터의 워크로드를 어떤 형태로 보이고자 하는지에 대해 효과적으로 쿠버네티스 시스템에 전한다. 이것이 바로 여러분의 클러스터에 대해 **의도한 상태** 가 된다.
|
||||
쿠버네티스 오브젝트는 하나의 "의도를 담은 레코드" 이다. 오브젝트를 생성하게 되면, 쿠버네티스 시스템은 그 오브젝트 생성을 보장하기 위해 지속적으로 작동할 것이다. 오브젝트를 생성함으로써, 여러분이 클러스터의 워크로드를 어떤 형태로 보이고자 하는지에 대해 효과적으로 쿠버네티스 시스템에 전한다. 이것이 바로 여러분의 클러스터에 대해 *의도한 상태* 가 된다.
|
||||
|
||||
생성이든, 수정이든, 또는 삭제든 쿠버네티스 오브젝트를 동작시키려면, [Kubernetes API](/docs/concepts/overview/kubernetes-api/)를 이용해야 한다. 예를 들어, `kubectl` 커맨드-라인 인터페이스를 이용할 때, CLI는 여러분 대신 필요한 쿠버네티스 API를 호출해 준다. 또한, 여러분은 [Client Libraries](/docs/reference/using-api/client-libraries/) 중 하나를 이용하여 여러분만의 프로그램에서 쿠버네티스 API를 직접 이용할 수도 있다.
|
||||
|
||||
### 오브젝트 스펙(spec)과 상태(status)
|
||||
|
||||
모든 쿠버네티스 오브젝트는 오브젝트의 구성을 결정해주는 두 개의 중첩된 오브젝트 필드를 포함하는데 오브젝트 *spec* 과 오브젝트 *status* 가 그것이다. 필히 제공되어야만 하는 *spec* 은, 여러분이 오브젝트가 가졌으면 하고 원하는 특징, 즉 *의도한 상태* 를 기술한다. *status* 는 오브젝트의 *실제 상태* 를 기술하고, 쿠버네티스 시스템에 의해 제공되고 업데이트 된다. 주어진 임의의 시간에, 쿠버네티스 컨트롤 플레인은 오브젝트의 실제 상태를 여러분이 제시한 의도한 상태에 일치시키기 위해 능동적으로 관리한다.
|
||||
모든 쿠버네티스 오브젝트는 오브젝트의 구성을 결정해주는 두 개의 중첩된 오브젝트 필드를 포함하는데 오브젝트 *spec* 과 오브젝트 *status* 가 그것이다. 필히 제공되어야만 하는 *spec* 은, 여러분이 오브젝트가 가졌으면 하고 원하는 특징, 즉 의도한 상태를 기술한다. *status* 는 오브젝트의 *실제 상태* 를 기술하고, 쿠버네티스 시스템에 의해 제공되고 업데이트 된다. 주어진 임의의 시간에, 쿠버네티스 컨트롤 플레인은 오브젝트의 실제 상태를 여러분이 제시한 의도한 상태에 일치시키기 위해 능동적으로 관리한다.
|
||||
|
||||
|
||||
예를 들어, 쿠버네티스 디플로이먼트는 클러스터에서 동작하는 애플리케이션을 표현해 줄 수 있는 오브젝트이다. 디플로이먼트를 생성할 때, 디플로이먼트 spec에 3개의 애플리케이션 레플리카가 동작되도록 설정할 수 있다. 쿠버네티스 시스템은 그 디플로이먼트 spec을 읽어 spec에 일치되도록 상태를 업데이트하여 3개의 의도한 애플리케이션 인스턴스를 구동시킨다. 만약, 그 인스턴스들 중 어느 하나가 (상태 변경에) 실패가 난다면, 쿠버네티스 시스템은 보정을 통해, 이 경우에는 인스턴스 대체를 착수하여, spec과 status 간의 차이에 대응한다.
|
||||
@@ -61,9 +61,10 @@ deployment.apps/nginx-deployment created
|
||||
|
||||
* `apiVersion` - 이 오브젝트를 생성하기 위해 사용하고 있는 쿠버네티스 API 버전이 어떤 것인지
|
||||
* `kind` - 어떤 종류의 오브젝트를 생성하고자 하는지
|
||||
* `metadata` - `이름` 문자열, UID, 그리고 선택적인 `네임스페이스` 를 포함하여 오브젝트를 유일하게 구분지어 줄 데이터
|
||||
* `metadata` - `이름` 문자열, `UID`, 그리고 선택적인 `네임스페이스` 를 포함하여 오브젝트를 유일하게 구분지어 줄 데이터
|
||||
|
||||
여러분은 또한 오브젝트 `spec` 필드를 제공해야만 할 것이다. 오브젝트 `spec`에 대한 정확한 포맷은 모든 쿠버네티스 오브젝트마다 다르고, 그 오브젝트 특유의 중첩된 필드를 포함한다. [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) 는 쿠버네티스를 이용하여 생성할 수 있는 오브젝트에 대한 모든 spec 포맷을 살펴볼 수 있도록 해준다. 예를 들어, `파드` 오브젝트에 대한 `spec` 포맷은 [여기](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)에서 확인할 수 있고, `디플로이먼트` 오브젝트에 대한 `spec` 포맷은 [여기](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deploymentspec-v1-apps)에서 확인할 수 있다.
|
||||
여러분은 또한 오브젝트 `spec` 필드를 제공해야만 할 것이다. 오브젝트 `spec`에 대한 정확한 포맷은 모든 쿠버네티스 오브젝트마다 다르고, 그 오브젝트 특유의 중첩된 필드를 포함한다. [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) 는 쿠버네티스를 이용하여 생성할 수 있는 오브젝트에 대한 모든 spec 포맷을 살펴볼 수 있도록 해준다.
|
||||
예를 들어, `파드`에 대한 `spec` 포맷은 [여기](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)에서 확인할 수 있고, `디플로이먼트`에 대한 `spec` 포맷은 [여기](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deploymentspec-v1-apps)에서 확인할 수 있다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -25,7 +25,8 @@ weight: 30
|
||||
네임스페이스는 클러스터 자원을 ([리소스 쿼터](/docs/concepts/policy/resource-quotas/)를 통해) 복수의 사용자 사이에서 나누는 방법이다.
|
||||
|
||||
다음 버전의 쿠버네티스에서는, 같은 네임스페이스의 오브젝트는 기본적을 동일한 접근
|
||||
제어 정책을 갖게 된다.
|
||||
제어 정책을 갖게 된다. 네임스페이스는 서로 중첩될 수 없으며, 각 쿠버네티스
|
||||
리소스는 하나의 네임스페이스에만 있을 수 있다.
|
||||
|
||||
같은 소프트웨어의 다른 버전과 같이 단지 약간의 차이가 있는 리소스를 분리하기 위해서
|
||||
복수의 네임스페이스를 사용할 필요가 있다. 동일한 네임스페이스에 있는 리소스를
|
||||
|
||||
Reference in New Issue
Block a user