Seventh Korean l10n work for release 1.18
- Translate reference/command-line-tools-reference/feature-gates.md int… (#22240) - Fix issue of broken links to translated docs (#22105) - Fix issue of document link in some ko documents (#22379) - Translate tasks/administer-cluster/access-cluster-services.md into Ko… (#21776) - Fix issue with 'Linux' and 'Windows' notation in Korean docs (#22362) - Fix issue of broken links to translated docs #2 (#22270) - Fix issue with k8s.io/ko/docs/concepts/overview/kubernetes-api.md (#22261) - Fix issue with k8s.io/ko/docs/concepts/overview/working-with-objects/ (#22263) - Fix incorrect notation of 'directory' into Korean (#22155) - Fix issue with k8s.io/ko/docs/concepts/overview/components.md (#22232) - Update outdated files in dev-1.18-ko.7 (#22128) - Modify spacing term ReplicaSet in Korean (#22148) - Translate tasks/administer-cluster/extended-resource-node.md into Korean (#21849) - Translate tasks/administer-cluster/access-cluster-api.md into Korean (#21730) Co-authored-by: Jerry Park <jaehwa@gmail.com> Co-authored-by: woopyoung <ywp041@gmail.com> Co-authored-by: coolguyhong <podolsmith@naver.com> Co-authored-by: PyungHo Yoon <learder@gmail.com> Co-authored-by: Seokho Son <shsongist@gmail.com> Co-authored-by: jmyung <jesang.myung@gmail.com> Co-authored-by: Ian Y. Choi <ianyrchoi@gmail.com>
This commit is contained in:
June Yi
@@ -1,4 +1,7 @@
|
||||
---
|
||||
title: "쿠버네티스 오브젝트로 작업하기"
|
||||
weight: 40
|
||||
description: >
|
||||
쿠버네티스 오브젝트는 쿠버네티스 시스템의 영구 엔티티이다. 쿠버네티스는 이러한 엔티티들을 사용하여 클러스터의 상태를 나타낸다.
|
||||
쿠버네티스 오브젝트 모델과 쿠버네티스 오브젝트를 사용하는 방법에 대해 학습한다.
|
||||
---
|
||||
|
||||
@@ -51,13 +51,13 @@ weight: 50
|
||||
* 경량 롤아웃 도구 메타데이터. 예: 구성 또는 체크포인트
|
||||
|
||||
* 책임자의 전화번호 또는 호출기 번호, 또는 팀 웹 사이트 같은
|
||||
해당 정보를 찾을 수 있는 디렉토리 진입점.
|
||||
해당 정보를 찾을 수 있는 디렉터리 진입점.
|
||||
|
||||
* 행동을 수정하거나 비표준 기능을 수행하기 위한
|
||||
최종 사용자의 지시 사항.
|
||||
|
||||
어노테이션을 사용하는 대신, 이 유형의 정보를
|
||||
외부 데이터베이스 또는 디렉토리에 저장할 수 있지만, 이는 배포, 관리, 인트로스펙션(introspection) 등을 위한
|
||||
외부 데이터베이스 또는 디렉터리에 저장할 수 있지만, 이는 배포, 관리, 인트로스펙션(introspection) 등을 위한
|
||||
공유 클라이언트 라이브러리와 도구 생성을
|
||||
훨씬 더 어렵게 만들 수 있다.
|
||||
|
||||
|
||||
@@ -9,7 +9,7 @@ _필드 셀렉터_ 는 한 개 이상의 리소스 필드 값에 따라 [쿠버
|
||||
* `metadata.namespace!=default`
|
||||
* `status.phase=Pending`
|
||||
|
||||
다음의 `kubectl` 커맨드는 [`status.phase`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase) 필드의 값이 `Running` 인 모든 파드를 선택한다.
|
||||
다음의 `kubectl` 커맨드는 [`status.phase`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-단계-phase) 필드의 값이 `Running` 인 모든 파드를 선택한다.
|
||||
|
||||
```shell
|
||||
kubectl get pods --field-selector status.phase=Running
|
||||
|
||||
@@ -87,7 +87,7 @@ API는 현재 _일치성 기준_ 과 _집합성 기준_ 이라는 두 종류의
|
||||
문서화해야 한다.
|
||||
|
||||
{{< note >}}
|
||||
레플리카 셋과 같은 일부 API 유형에서 두 인스턴스의 레이블 셀렉터는 네임스페이스 내에서 겹치지 않아야 한다. 그렇지 않으면 컨트롤러는 상충하는 명령으로 보고, 얼마나 많은 복제본이 필요한지 알 수 없다.
|
||||
레플리카셋(ReplicaSet)과 같은 일부 API 유형에서 두 인스턴스의 레이블 셀렉터는 네임스페이스 내에서 겹치지 않아야 한다. 그렇지 않으면 컨트롤러는 상충하는 명령으로 보고, 얼마나 많은 복제본이 필요한지 알 수 없다.
|
||||
{{< /note >}}
|
||||
|
||||
{{< caution >}}
|
||||
|
||||
@@ -27,7 +27,7 @@ weight: 30
|
||||
|
||||
네임스페이스는 클러스터 자원을 ([리소스 쿼터](/ko/docs/concepts/policy/resource-quotas/)를 통해) 여러 사용자 사이에서 나누는 방법이다.
|
||||
|
||||
이후 버전의 쿠버네티스에서는 같은 네임스페이스의 오브젝트는 기본적으로
|
||||
이후 버전의 쿠버네티스에서는 같은 네임스페이스의 오브젝트는 기본적으로
|
||||
동일한 접근 제어 정책을 갖게 된다.
|
||||
|
||||
동일한 소프트웨어의 다른 버전과 같이 약간 다른 리소스를 분리하기 위해
|
||||
@@ -39,6 +39,10 @@ weight: 30
|
||||
네임스페이스의 생성과 삭제는 [네임스페이스 관리자 가이드 문서](/docs/tasks/administer-cluster/namespaces/)에
|
||||
기술되어 있다.
|
||||
|
||||
{{< note >}}
|
||||
쿠버네티스 시스템 네임스페이스용으로 예약되어 있으므로, `kube-` 접두사로 네임스페이스를 생성하지 않는다.
|
||||
{{< /note >}}
|
||||
|
||||
### 네임스페이스 조회
|
||||
|
||||
사용 중인 클러스터의 현재 네임스페이스를 나열할 수 있다.
|
||||
@@ -54,11 +58,12 @@ kube-public Active 1d
|
||||
kube-system Active 1d
|
||||
```
|
||||
|
||||
쿠버네티스는 처음에 세 개의 초기 네임스페이스를 갖는다.
|
||||
쿠버네티스는 처음에 네 개의 초기 네임스페이스를 갖는다.
|
||||
|
||||
* `default` 다른 네임스페이스가 없는 오브젝트를 위한 기본 네임스페이스
|
||||
* `kube-system` 쿠버네티스 시스템에서 생성한 오브젝트를 위한 네임스페이스
|
||||
* `kube-public` 이 네임스페이스는 자동으로 생성되며 모든 사용자(인증되지 않은 사용자 포함)가 읽기 권한으로 접근할 수 있다. 이 네임스페이스는 주로 전체 클러스터 중에 공개적으로 드러나서 읽을 수 있는 리소스를 위해 예약되어 있다. 이 네임스페이스의 공개적인 성격은 단지 관례이지 요구 사항은 아니다.
|
||||
* `kube-node-lease` 클러스터가 스케일링될 때 노드 하트비트의 성능을 향상시키는 각 노드와 관련된 리스(lease) 오브젝트에 대한 네임스페이스
|
||||
|
||||
### 요청에 네임스페이스 설정하기
|
||||
|
||||
@@ -114,6 +119,3 @@ kubectl api-resources --namespaced=false
|
||||
|
||||
* [신규 네임스페이스 생성](/docs/tasks/administer-cluster/namespaces/#creating-a-new-namespace)에 대해 더 배우기.
|
||||
* [네임스페이스 삭제](/docs/tasks/administer-cluster/namespaces/#deleting-a-namespace)에 대해 더 배우기.
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -7,7 +7,7 @@ weight: 15
|
||||
<!-- overview -->
|
||||
`kubectl` 커맨드라인 툴은 쿠버네티스 오브젝트를 생성하고 관리하기 위한
|
||||
몇 가지 상이한 방법을 지원한다. 이 문서는 여러가지 접근법에 대한 개요을
|
||||
제공한다. Kubectl로 오브젝트 관리하기에 대한 자세한 설명은
|
||||
제공한다. Kubectl로 오브젝트 관리하기에 대한 자세한 설명은
|
||||
[Kubectl 서적](https://kubectl.docs.kubernetes.io)에서 확인한다.
|
||||
|
||||
|
||||
@@ -40,12 +40,6 @@ weight: 15
|
||||
|
||||
디플로이먼트 오브젝트를 생성하기 위해 nginx 컨테이너의 인스턴스를 구동시킨다.
|
||||
|
||||
```sh
|
||||
kubectl run nginx --image nginx
|
||||
```
|
||||
|
||||
다른 문법을 이용하여 동일한 작업을 수행한다.
|
||||
|
||||
```sh
|
||||
kubectl create deployment nginx --image nginx
|
||||
```
|
||||
@@ -75,11 +69,11 @@ kubectl create deployment nginx --image nginx
|
||||
참고한다.
|
||||
|
||||
{{< warning >}}
|
||||
명령형 `replace` 커맨드는 기존 spec을 새로 제공된 spec으로 바꾸고
|
||||
구성 파일에서 누락된 오브젝트의 모든 변경 사항을 삭제한다.
|
||||
이 방법은 spec이 구성 파일과는 별개로 업데이트되는 리소스 유형에는
|
||||
사용하지 말아야한다.
|
||||
예를 들어 `LoadBalancer` 유형의 서비스는 클러스터의 구성과 별도로
|
||||
명령형 `replace` 커맨드는 기존 spec을 새로 제공된 spec으로 바꾸고
|
||||
구성 파일에서 누락된 오브젝트의 모든 변경 사항을 삭제한다.
|
||||
이 방법은 spec이 구성 파일과는 별개로 업데이트되는 리소스 유형에는
|
||||
사용하지 말아야한다.
|
||||
예를 들어 `LoadBalancer` 유형의 서비스는 클러스터의 구성과 별도로
|
||||
`externalIPs` 필드가 업데이트된다.
|
||||
{{< /warning >}}
|
||||
|
||||
@@ -124,7 +118,7 @@ kubectl replace -f nginx.yaml
|
||||
|
||||
선언형 오브젝트 구성에 비해 단점은 다음과 같다.
|
||||
|
||||
- 명령형 오브젝트 구성은 디렉토리가 아닌, 파일에 대해 가장 효과가 있다.
|
||||
- 명령형 오브젝트 구성은 디렉터리가 아닌, 파일에 대해 가장 효과가 있다.
|
||||
- 활성 오브젝트에 대한 업데이트는 구성 파일에 반영되어야 한다. 그렇지 않으면 다음 교체 중에 손실된다.
|
||||
|
||||
## 선언형 오브젝트 구성
|
||||
@@ -133,19 +127,19 @@ kubectl replace -f nginx.yaml
|
||||
구성 파일을 대상으로 작동시키지만, 사용자는 파일에서 수행 할
|
||||
작업을 정의하지 않는다. 생성, 업데이트, 그리고 삭제 작업은
|
||||
`kubectl`에 의해 오브젝트 마다 자동으로 감지된다. 이를 통해 다른 오브젝트에 대해
|
||||
다른 조작이 필요할 수 있는 디렉토리에서 작업할 수 있다.
|
||||
다른 조작이 필요할 수 있는 디렉터리에서 작업할 수 있다.
|
||||
|
||||
{{< note >}}
|
||||
선언형 오브젝트 구성은 변경 사항이 오브젝트 구성 파일에
|
||||
다시 병합되지 않더라도 다른 작성자가 작성한 변경 사항을 유지한다.
|
||||
선언형 오브젝트 구성은 변경 사항이 오브젝트 구성 파일에
|
||||
다시 병합되지 않더라도 다른 작성자가 작성한 변경 사항을 유지한다.
|
||||
이것은 전체 오브젝트 구성 변경을 위한 `replace` API를
|
||||
사용하는 대신, `patch` API를 사용하여 인지되는 차이만
|
||||
사용하는 대신, `patch` API를 사용하여 인지되는 차이만
|
||||
작성하기 때문에 가능하다.
|
||||
{{< /note >}}
|
||||
|
||||
### 예시
|
||||
|
||||
`configs` 디렉토리 내 모든 오브젝트 구성 파일을 처리하고 활성 오브젝트를
|
||||
`configs` 디렉터리 내 모든 오브젝트 구성 파일을 처리하고 활성 오브젝트를
|
||||
생성 또는 패치한다. 먼저 어떠한 변경이 이루어지게 될지 알아보기 위해 `diff`
|
||||
하고 나서 적용할 수 있다.
|
||||
|
||||
@@ -154,7 +148,7 @@ kubectl diff -f configs/
|
||||
kubectl apply -f configs/
|
||||
```
|
||||
|
||||
재귀적으로 디렉토리를 처리한다.
|
||||
재귀적으로 디렉터리를 처리한다.
|
||||
|
||||
```sh
|
||||
kubectl diff -R -f configs/
|
||||
@@ -166,7 +160,7 @@ kubectl apply -R -f configs/
|
||||
명령형 오브젝트 구성에 비해 장점은 다음과 같다.
|
||||
|
||||
- 활성 오브젝트에 직접 작성된 변경 사항은 구성 파일로 다시 병합되지 않더라도 유지된다.
|
||||
- 선언형 오브젝트 구성은 디렉토리에서의 작업 및 오브젝트 별 작업 유형(생성, 패치, 삭제)의 자동 감지에 더 나은 지원을 제공한다.
|
||||
- 선언형 오브젝트 구성은 디렉터리에서의 작업 및 오브젝트 별 작업 유형(생성, 패치, 삭제)의 자동 감지에 더 나은 지원을 제공한다.
|
||||
|
||||
명령형 오브젝트 구성에 비해 단점은 다음과 같다.
|
||||
|
||||
@@ -185,5 +179,3 @@ kubectl apply -R -f configs/
|
||||
- [Kubectl 커맨드 참조](/docs/reference/generated/kubectl/kubectl-commands/)
|
||||
- [Kubectl 서적](https://kubectl.docs.kubernetes.io)
|
||||
- [쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user