Merge pull request #40989 from bugoverdose/dev-1.26-ko.1-outdated-24-26

[ko] Update outdated files in dev-1.26.-ko.1 [M24-26]
2023-05-24 16:16:49 -07:00 · 2023-05-24 16:16:49 -07:00 · 39f73058c9
parent 74c2a2c8a4 72549f240a
commit 39f73058c9
3 changed files with 103 additions and 50 deletions
--- a/content/ko/docs/concepts/extend-kubernetes/api-extension/_index.md
+++ b/content/ko/docs/concepts/extend-kubernetes/api-extension/_index.md
@ -1,4 +1,4 @@
 ---
 title: 쿠버네티스 API 확장하기
-weight: 20
+weight: 30
 ---
--- a/content/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md
+++ b/content/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md
@ -10,18 +10,29 @@ weight: 10

 <!-- overview -->

-애그리게이션 레이어는 코어 쿠버네티스 API가 제공하는 기능 이외에 더 많은 기능을 제공할 수 있도록 추가 API를 더해 쿠버네티스를 확장할 수 있게 해준다.
-추가 API는 [메트릭 서버](https://github.com/kubernetes-sigs/metrics-server)와 같이 미리 만들어진 솔루션이거나 사용자가 직접 개발한 API일 수 있다.
+애그리게이션 레이어는 코어 쿠버네티스 API가 제공하는 기능 이외에 더 많은 기능을 제공할 수 있도록 추가 API를 더해 
+쿠버네티스를 확장할 수 있게 해준다.
+추가 API는 [메트릭 서버](https://github.com/kubernetes-sigs/metrics-server)와 같이 
+미리 만들어진 솔루션이거나 사용자가 직접 개발한 API일 수 있다.

-애그리게이션 레이어는 {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}}가 새로운 종류의 오브젝트를 인식하도록 하는 방법인 [사용자 정의 리소스](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)와는 다르다.
+애그리게이션 레이어는 {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}}가 
+새로운 종류의 오브젝트를 인식하도록 하는 방법인 
+[사용자 정의 리소스](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)와는 다르다.

 <!-- body -->

 ## 애그리게이션 레이어

-애그리게이션 레이어는 kube-apiserver 프로세스 안에서 구동된다. 확장 리소스가 등록되기 전까지, 애그리게이션 레이어는 아무 일도 하지 않는다. API를 등록하기 위해서, 사용자는 쿠버네티스 API 내에서 URL 경로를 "요구하는(claim)" APIService 오브젝트를 추가해야 한다. 이때, 애그리게이션 레이어는 해당 API 경로(예: /apis/myextensions.mycompany.io/v1/...)로 전송되는 모든 것을 등록된 APIService로 프록시하게 된다.
+애그리게이션 레이어는 kube-apiserver 프로세스 안에서 구동된다. 확장 리소스가 등록되기 전까지, 
+애그리게이션 레이어는 아무 일도 하지 않는다. API를 등록하기 위해서, 사용자는 쿠버네티스 API 내에서 URL 경로를 
+"요구하는(claim)" APIService 오브젝트를 추가해야 한다. 이때, 애그리게이션 레이어는 
+해당 API 경로(예: /apis/myextensions.mycompany.io/v1/...)로 전송되는 모든 것을 등록된 APIService로 프록시하게 된다.

-APIService를 구현하는 가장 일반적인 방법은 클러스터 내에 실행되고 있는 파드에서 *extension API server* 를 실행하는 것이다. extension API server를 사용해서 클러스터의 리소스를 관리하는 경우 extension API server("extension-apiserver" 라고도 한다)는 일반적으로 하나 이상의 {{< glossary_tooltip text="컨트롤러" term_id="controller" >}}와 쌍을 이룬다. apiserver-builder 라이브러리는 extension API server와 연관된 컨틀로러에 대한 스켈레톤을 제공한다.
+APIService를 구현하는 가장 일반적인 방법은 클러스터 내에 실행되고 있는 파드에서 *extension API server* 를 실행하는 것이다. 
+extension API server를 사용해서 클러스터의 리소스를 관리하는 경우 
+extension API server("extension-apiserver" 라고도 한다)는 일반적으로 하나 이상의 
+{{< glossary_tooltip text="컨트롤러" term_id="controller" >}}와 쌍을 이룬다. 
+apiserver-builder 라이브러리는 extension API server와 연관된 컨틀로러에 대한 스켈레톤을 제공한다.

 ### 응답 레이턴시

--- a/content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md
+++ b/content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md
@ -17,7 +17,8 @@ weight: 10
 ## 커스텀 리소스

 *리소스* 는 [쿠버네티스 API](/ko/docs/concepts/overview/kubernetes-api/)에서 특정 종류의
-[API 오브젝트](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/) 모음을 저장하는 엔드포인트이다. 예를 들어 빌트인 *파드* 리소스에는 파드 오브젝트 모음이 포함되어 있다.
+[API 오브젝트](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/) 모음을 저장하는 엔드포인트이다. 
+예를 들어 빌트인 *파드* 리소스에는 파드 오브젝트 모음이 포함되어 있다.

 *커스텀 리소스* 는 쿠버네티스 API의 익스텐션으로, 기본 쿠버네티스 설치에서 반드시
 사용할 수 있는 것은 아니다. 이는 특정 쿠버네티스 설치에 수정이 가해졌음을 나타낸다. 그러나
@ -68,63 +69,88 @@ _선언적(declarative) API_ 를 제공하게 된다.

 선언적 API에서는 다음의 특성이 있다.

- - API는 상대적으로 적은 수의 상대적으로 작은 오브젝트(리소스)로 구성된다.
- - 오브젝트는 애플리케이션 또는 인프라의 구성을 정의한다.
- - 오브젝트는 비교적 드물게 업데이트 된다.
- - 사람이 종종 오브젝트를 읽고 쓸 필요가 있다.
- - 오브젝트의 주요 작업은 CRUD-y(생성, 읽기, 업데이트 및 삭제)이다.
- - 오브젝트 간 트랜잭션은 필요하지 않다. API는 정확한(exact) 상태가 아니라 의도한 상태를 나타낸다.
+- API는 상대적으로 적은 수의 상대적으로 작은 오브젝트(리소스)로 구성된다.
+- 오브젝트는 애플리케이션 또는 인프라의 구성을 정의한다.
+- 오브젝트는 비교적 드물게 업데이트 된다.
+- 사람이 종종 오브젝트를 읽고 쓸 필요가 있다.
+- 오브젝트의 주요 작업은 CRUD-y(생성, 읽기, 업데이트 및 삭제)이다.
+- 오브젝트 간 트랜잭션은 필요하지 않다. API는 정확한(exact) 상태가 아니라 의도한 상태를 나타낸다.

 명령형 API는 선언적이지 않다.
 자신의 API가 선언적이지 않을 수 있다는 징후는 다음과 같다.

- - 클라이언트는 "이 작업을 수행한다"라고 말하고 완료되면 동기(synchronous) 응답을 받는다.
- - 클라이언트는 "이 작업을 수행한다"라고 말한 다음 작업 ID를 다시 가져오고 별도의 오퍼레이션(operation) 오브젝트를 확인하여 요청의 완료 여부를 결정해야 한다.
- - RPC(원격 프로시저 호출)에 대해 얘기한다.
- - 대량의 데이터를 직접 저장한다. 예: > 오브젝트별 몇 kB 또는 > 1000개의 오브젝트.
- - 높은 대역폭 접근(초당 10개의 지속적인 요청)이 필요하다.
- - 최종 사용자 데이터(예: 이미지, PII 등) 또는 애플리케이션에서 처리한 기타 대규모 데이터를 저장한다.
- - 오브젝트에 대한 자연스러운 조작은 CRUD-y가 아니다.
- - API는 오브젝트로 쉽게 모델링되지 않는다.
- - 작업 ID 또는 작업 오브젝트로 보류 중인 작업을 나타내도록 선택했다.
+- 클라이언트는 "이 작업을 수행한다"라고 말하고 완료되면 동기(synchronous) 응답을 받는다.
+- 클라이언트는 "이 작업을 수행한다"라고 말한 다음 작업 ID를 다시 가져오고 별도의 
+  오퍼레이션(operation) 오브젝트를 확인하여 요청의 완료 여부를 결정해야 한다.
+- RPC(원격 프로시저 호출)에 대해 얘기한다.
+- 대량의 데이터를 직접 저장한다. 예: > 오브젝트별 몇 kB 또는 > 1000개의 오브젝트.
+- 높은 대역폭 접근(초당 10개의 지속적인 요청)이 필요하다.
+- 최종 사용자 데이터(예: 이미지, PII 등) 또는 애플리케이션에서 처리한 기타 대규모 데이터를 저장한다.
+- 오브젝트에 대한 자연스러운 조작은 CRUD-y가 아니다.
+- API는 오브젝트로 쉽게 모델링되지 않는다.
+- 작업 ID 또는 작업 오브젝트로 보류 중인 작업을 나타내도록 선택했다.

 ## 컨피그맵을 사용해야 하나, 커스텀 리소스를 사용해야 하나?

 다음 중 하나에 해당하면 컨피그맵을 사용하자.

-* `mysql.cnf` 또는 `pom.xml`과 같이 잘 문서화된 기존 구성 파일 형식이 있다.
+* `mysql.cnf` 또는 `pom.xml`과 같이 잘 문서화된
+  기존 구성 파일 형식이 있다.
 * 전체 구성 파일을 컨피그맵의 하나의 키에 넣고 싶다.
-* 구성 파일의 주요 용도는 클러스터의 파드에서 실행 중인 프로그램이 파일을 사용하여 자체 구성하는 것이다.
-* 파일 사용자는 쿠버네티스 API가 아닌 파드의 환경 변수 또는 파드의 파일을 통해 사용하는 것을 선호한다.
+* 구성 파일의 주요 용도는 클러스터의 파드에서 실행 중인 프로그램이 파일을 사용하여
+  자체 구성하는 것이다.
+* 파일 사용자는 쿠버네티스 API가 아닌 파드의 환경 변수 또는 파드의 파일을 통해
+  사용하는 것을 선호한다.
 * 파일이 업데이트될 때 디플로이먼트 등을 통해 롤링 업데이트를 수행하려고 한다.

 {{< note >}}
-민감한 데이터에는 {{< glossary_tooltip text="시크릿" term_id="secret" >}}을 사용하자. 이는 컨피그맵과 비슷하지만 더 안전하다.
+민감한 데이터에는 {{< glossary_tooltip text="시크릿" term_id="secret" >}}을 사용하자.
+이는 컨피그맵과 비슷하지만 더 안전하다.
 {{< /note >}}

 다음 중 대부분이 적용되는 경우 커스텀 리소스(CRD 또는 애그리게이트 API(aggregated API))를 사용하자.

 * 쿠버네티스 클라이언트 라이브러리 및 CLI를 사용하여 새 리소스를 만들고 업데이트하려고 한다.
 * `kubectl` 의 최상위 지원을 원한다. 예: `kubectl get my-object object-name`.
-* 새 오브젝트에 대한 업데이트를 감시한 다음 다른 오브젝트를 CRUD하거나 그 반대로 하는 새로운 자동화를 구축하려고 한다.
+* 새 오브젝트에 대한 업데이트를 감시한 다음 다른 오브젝트를 CRUD하거나 그 반대로 하는 새로운 자동화를
+  구축하려고 한다.
 * 오브젝트의 업데이트를 처리하는 자동화를 작성하려고 한다.
 * `.spec`, `.status` 및 `.metadata`와 같은 쿠버네티스 API 규칙을 사용하려고 한다.
-* 제어된 리소스의 콜렉션 또는 다른 리소스의 요약에 대한 오브젝트가 되기를 원한다.
+* 제어된 리소스의 콜렉션 또는 다른 리소스의 요약에 대한 오브젝트가 되기를
+  원한다.

 ## 커스텀 리소스 추가

 쿠버네티스는 클러스터에 커스텀 리소스를 추가하는 두 가지 방법을 제공한다.

 - CRD는 간단하며 프로그래밍 없이 만들 수 있다.
- [API 애그리게이션](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)에는 프로그래밍이 필요하지만, 데이터 저장 방법 및 API 버전 간 변환과 같은 API 동작을 보다 강력하게 제어할 수 있다.
+- [API 애그리게이션](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)에는
+  프로그래밍이 필요하지만, 데이터 저장 방법 및 API 버전 간 변환과 같은
+  API 동작을 보다 강력하게 제어할 수 있다.

-쿠버네티스는 다양한 사용자의 요구를 충족시키기 위해 이 두 가지 옵션을 제공하므로 사용의 용이성이나 유연성이 저하되지 않는다.
+쿠버네티스는 다양한 사용자의 요구를 충족시키기 위해 이 두 가지 옵션을 제공하므로
+사용의 용이성이나 유연성이 저하되지 않는다.

-애그리게이트 API는 기본 API 서버 뒤에 있는 하위 API 서버이며 프록시 역할을 한다. 이 배치를 [API 애그리게이션](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)(AA)이라고 한다. 사용자에게는 쿠버네티스 API가 확장된 것으로 나타난다.
+애그리게이트 API는 기본 API 서버 뒤에 있는 하위 API 서버이며 프록시 역할을 한다. 이 배치를
+[API 애그리게이션](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)(AA)이라고 한다. 
+사용자에게는 쿠버네티스 API가 확장된 것으로 나타난다.

-CRD를 사용하면 다른 API 서버를 추가하지 않고도 새로운 타입의 리소스를 생성할 수 있다. CRD를 사용하기 위해 API 애그리게이션을 이해할 필요는 없다.
+CRD를 사용하면 다른 API 서버를 추가하지 않고도 새로운 타입의 리소스를 생성할 수 있다. CRD를 사용하기 위해 API 
+애그리게이션을 이해할 필요는 없다.

-설치 방법에 관계없이 새 리소스는 커스텀 리소스라고 하며 빌트인 쿠버네티스 리소스(파드 등)와 구별된다.
+설치 방법에 관계없이 새 리소스는 커스텀 리소스라고 하며
+빌트인 쿠버네티스 리소스(파드 등)와 구별된다.
+
+{{< note >}}
+커스텀 리소스를 애플리케이션, 최종 사용자, 데이터 모니터링을 위한 데이터 스토리지로 사용하는 것은 피해야 한다.
+쿠버네티스 API에서 애플리케이션 데이터를 저장하는 아키텍처 구조는
+일반적으로 결합도가 너무 높기 때문이다.
+
+아키텍처적으로 [클라우드 네이티브](https://www.cncf.io/about/faq/#what-is-cloud-native) 애플리케이션 아키텍처들은
+컴포넌트 간 결합도를 낮추는 것을 선호한다. 
+워크로드 중 일부가 주기적인 작업을 위해 보조 서비스를 필요로 한다면, 해당 보조 서비스를 별도의 컴포넌트로 실행하거나 외부 서비스로 사용하자.
+이를 통해 해당 워크로드는 일반적인 작업을 위해 쿠버네티스 API에 의존하지 않게 된다.
+{{< /note >}}

 ## 커스텀리소스데피니션

@ -145,10 +171,14 @@ CRD 오브젝트의 이름은 유효한

 ## API 서버 애그리게이션

-일반적으로 쿠버네티스 API의 각 리소스에는 REST 요청을 처리하고 오브젝트의 퍼시스턴트 스토리지를 관리하는 코드가 필요하다. 주요 쿠버네티스 API 서버는 *파드* 및 *서비스* 와 같은 빌트인 리소스를 처리하고, 일반적으로 [CRD](#커스텀리소스데피니션)를 통해 커스텀 리소스를 처리할 수 있다.
+일반적으로 쿠버네티스 API의 각 리소스에는 REST 요청을 처리하고
+오브젝트의 퍼시스턴트 스토리지를 관리하는 코드가 필요하다. 
+주요 쿠버네티스 API 서버는 *파드* 및 *서비스* 와 같은 빌트인 리소스를 처리하고, 일반적으로
+[CRD](#커스텀리소스데피니션)를 통해 커스텀 리소스를 처리할 수 있다.

-[애그리게이션 레이어](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)를 사용하면 자체 API 서버를
-작성하고 배포하여 커스텀 리소스에 대한 특수한 구현을 제공할 수 있다.
+[애그리게이션 레이어](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)를
+사용하면 자체 API 서버를 작성하고 배포하여 커스텀 리소스에 대한
+특수한 구현을 제공할 수 있다.
 주(main) API 서버는 사용자의 커스텀 리소스에 대한 요청을 사용자의 자체 API 서버에 위임하여
 모든 클라이언트가 사용할 수 있게 한다.

@ -159,7 +189,8 @@ CRD는 사용하기가 더 쉽다. 애그리게이트 API가 더 유연하다.
 일반적으로 CRD는 다음과 같은 경우에 적합하다.

 * 필드가 몇 개 되지 않는다
-* 회사 내에서 또는 소규모 오픈소스 프로젝트의 일부인(상용 제품이 아닌) 리소스를 사용하고 있다.
+* 회사 내에서 또는 소규모 오픈소스 프로젝트의 일부인(상용 제품이 아닌)
+  리소스를 사용하고 있다.

 ### 사용 편의성 비교

@ -192,7 +223,8 @@ CRD는 애그리게이트 API보다 생성하기가 쉽다.

 ### 일반적인 기능

-CRD 또는 AA를 통해 커스텀 리소스를 생성하면 쿠버네티스 플랫폼 외부에서 구현하는 것과 비교하여 API에 대한 많은 기능이 제공된다.
+CRD 또는 AA를 통해 커스텀 리소스를 생성하면 쿠버네티스 플랫폼 외부에서 구현하는 것과 비교하여
+API에 대한 많은 기능이 제공된다.

 | 기능     | 설명          |
 | ------- | ------------ |
@ -217,40 +249,50 @@ CRD 또는 AA를 통해 커스텀 리소스를 생성하면 쿠버네티스 플

 ### 써드파티 코드 및 새로운 장애 포인트

-CRD를 생성해도 새로운 장애 포인트(예를 들어, API 서버에서 장애를 유발하는 써드파티 코드가 실행됨)가 자동으로 추가되지는 않지만, 패키지(예: 차트(Charts)) 또는 기타 설치 번들에는 CRD 및 새로운 커스텀 리소스에 대한 비즈니스 로직을 구현하는 써드파티 코드의 디플로이먼트가 포함되는 경우가 종종 있다.
+CRD를 생성해도 새로운 장애 포인트(예를 들어, API 서버에서 장애를 유발하는 써드파티 코드가 실행됨)가 
+자동으로 추가되지는 않지만, 패키지(예: 차트(Charts)) 또는 기타 설치 번들에는
+CRD 및 새로운 커스텀 리소스에 대한 비즈니스 로직을 구현하는
+써드파티 코드의 디플로이먼트가 포함되는 경우가 종종 있다.

 애그리게이트 API 서버를 설치하려면 항상 새 디플로이먼트를 실행해야 한다.

 ### 스토리지

-커스텀 리소스는 컨피그맵과 동일한 방식으로 스토리지 공간을 사용한다. 너무 많은 커스텀 리소스를 생성하면 API 서버의 스토리지 공간이 과부하될 수 있다.
+커스텀 리소스는 컨피그맵과 동일한 방식으로 스토리지 공간을 사용한다. 너무 많은 커스텀 리소스를 생성하면 
+API 서버의 스토리지 공간이 과부하될 수 있다.

-애그리게이트 API 서버는 기본 API 서버와 동일한 스토리지를 사용할 수 있으며 이 경우 동일한 경고가 적용된다.
+애그리게이트 API 서버는 기본 API 서버와 동일한 스토리지를 사용할 수 있으며
+이 경우 동일한 경고가 적용된다.

 ### 인증, 권한 부여 및 감사

-CRD는 항상 API 서버의 빌트인 리소스와 동일한 인증, 권한 부여 및 감사 로깅을 사용한다.
+CRD는 항상 API 서버의 빌트인 리소스와 동일한 인증, 권한 부여 및
+감사 로깅을 사용한다.

-권한 부여에 RBAC를 사용하는 경우 대부분의 RBAC 역할은 새로운 리소스에 대한 접근 권한을 부여하지 않는다(클러스터 관리자 역할 또는 와일드 카드 규칙으로 생성된 역할 제외). 새로운 리소스에 대한 접근 권한을 명시적으로 부여해야 한다. CRD 및 애그리게이트 API는 종종 추가하는 타입에 대한 새로운 역할 정의와 함께 제공된다.
+권한 부여에 RBAC를 사용하는 경우 대부분의 RBAC 역할은 새로운 리소스에 대한 접근 권한을 
+부여하지 않는다(클러스터 관리자 역할 또는 와일드 카드 규칙으로 생성된 역할 제외). 
+새로운 리소스에 대한 접근 권한을 명시적으로 부여해야 한다. CRD 및 애그리게이트 API는 종종 추가하는 
+타입에 대한 새로운 역할 정의와 함께 제공된다.

-애그리게이트 API 서버는 기본 API 서버와 동일한 인증, 권한 부여 및 감사를 사용하거나 사용하지 않을 수 있다.
+애그리게이트 API 서버는 기본 API 서버와 동일한 인증, 권한 부여 및 감사를 사용하거나
+사용하지 않을 수 있다.

 ## 커스텀 리소스에 접근

-쿠버네티스 [클라이언트 라이브러리](/ko/docs/reference/using-api/client-libraries/)를 사용하여 커스텀 리소스에 접근할 수 있다. 모든 클라이언트 라이브러리가 커스텀 리소스를 지원하는 것은 아니다. _Go_ 와 _python_ 클라이언트 라이브러리가 지원한다.
+쿠버네티스 [클라이언트 라이브러리](/ko/docs/reference/using-api/client-libraries/)를 사용하여 
+커스텀 리소스에 접근할 수 있다. 모든 클라이언트 라이브러리가 커스텀 리소스를 지원하는 것은 아니다.
+_Go_ 와 _python_ 클라이언트 라이브러리가 지원한다.

 커스텀 리소스를 추가하면 다음을 사용하여 접근할 수 있다.

 - `kubectl`
 - 쿠버네티스 동적 클라이언트
 - 작성한 REST 클라이언트
- [쿠버네티스 클라이언트 생성 도구](https://github.com/kubernetes/code-generator)를 사용하여 생성된 클라이언트(하나를 생성하는 것은 고급 기능이지만, 일부 프로젝트는 CRD 또는 AA와 함께 클라이언트를 제공할 수 있다).
-
-
+- [쿠버네티스 클라이언트 생성 도구](https://github.com/kubernetes/code-generator)를 사용하여 
+  생성된 클라이언트(하나를 생성하는 것은 고급 기능이지만, 일부 프로젝트는
+  CRD 또는 AA와 함께 클라이언트를 제공할 수 있다).

 ## {{% heading "whatsnext" %}}

-
 * [애그리게이션 레이어(aggregation layer)로 쿠버네티스 API 확장](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)하는 방법에 대해 배우기.
-
 * [커스텀리소스데피니션으로 쿠버네티스 API 확장](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)하는 방법에 대해 배우기.