Merge pull request #25598 from pjhwa/outdated2-25522

Update outdated kubernetes-api.md file in the dev-1.19-ko.7
This commit is contained in:
Kubernetes Prow Robot
2020-12-14 21:47:48 -08:00
committed by GitHub
@@ -75,19 +75,10 @@ Protobuf에 기반한 직렬화 형식을 구현한다. 이 형식에 대한
API 오브젝트를 정의하는 Go 패키지에 들어있는 각각의 스키마에 대한
IDL(인터페이스 정의 언어) 파일을 참고한다.
## API 변경 사항
## 지속성
성공적인 시스템은 새로운 유스케이스가 등장하거나 기존 사례가 변경됨에 따라 성장하고 변화해야 한다.
따라서, 쿠버네티스는 쿠버네티스 API가 지속적으로 변경되고 성장할 수 있도록 기능을 설계했다.
쿠버네티스 프로젝트는 기존 클라이언트와의 호환성을 깨지 _않고_ 다른 프로젝트가
적응할 기회를 가질 수 있도록 장기간 해당 호환성을 유지하는 것을 목표로 한다.
일반적으로, 새 API 리소스와 새 리소스 필드는 자주 추가될 수 있다.
리소스 또는 필드를 제거하려면
[API 지원 중단 정책](/docs/reference/using-api/deprecation-policy/)을 따라야 한다.
호환 가능한 변경 사항과 API 변경 방법은
[API 변경 사항](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme)에 자세히 설명되어 있다.
쿠버네티스는 오브젝트의 직렬화된 상태를
{{< glossary_tooltip term_id="etcd" >}}에 기록하여 저장한다.
## API 그룹과 버전 규칙
@@ -105,29 +96,44 @@ API가 시스템 리소스 및 동작에 대한 명확하고 일관된 보기를
가능한 [API 그룹](/ko/docs/reference/using-api/#api-그룹)을 구현한다.
API 리소스는 API 그룹, 리소스 유형, 네임스페이스
(네임스페이스 리소스용) 및 이름으로 구분된다. API 서버는
여러 API 버전을 통해 동일한 기본 데이터를 제공하고 API 버전 간의
변환을 투명하게 처리할 수 있다. 이 모든 다른 버전은 실제로
같은 리소스의 표현이다. 예를 들어 동일한 리소스에 대해
두 가지 버전 `v1``v1beta1`이 있다고 가정해 보자.
`v1beta1` 버전에서 생성된 오브젝트를 `v1beta1` 또는 `v1` 버전에서
읽기, 업데이트 및 삭제할 수 있다.
(네임스페이스 리소스용) 및 이름으로 구분된다. API 서버는 API 버전 간의
변환을 투명하게 처리한다. 서로 다른 모든 버전은 실제로
동일한 지속 데이터의 표현이다. API 서버는 여러 API 버전을 통해
동일한 기본 데이터를 제공할 수 있다.
API 버전 수준 정의에 대한 자세한 내용은
[API 버전 레퍼런스](/ko/docs/reference/using-api/#api-버전-규칙)를 참조한다.
예를 들어, 동일한 리소스에 대해 `v1``v1beta1` 이라는 두 가지 API 버전이
있다고 가정한다. 원래 API의 `v1beta1` 버전을 사용하여 오브젝트를
만든 경우, 나중에 `v1beta1` 또는 `v1` API 버전을 사용하여 해당 오브젝트를
읽거나, 업데이트하거나, 삭제할 수 있다.
API 리소스는 해당 API 그룹, 리소스 유형, 네임스페이스
(네임스페이스 리소스용) 및 이름으로 구분된다. API 서버는 여러 API 버전을 통해 동일한
기본 데이터를 제공하고 API 버전 간의 변환을 투명하게
처리할 수 있다. 이 모든 다른 버전은 실제로
동일한 리소스의 표현이다. 예를 들어, 동일한 리소스에 대해 두 가지
버전 `v1``v1beta1` 이 있다고 가정한다. 그런 다음 `v1beta1` 버전에서
생성된 오브젝트를 `v1beta1` 또는 `v1` 버전에서 읽고 업데이트하고
삭제할 수 있다.
## API 변경 사항
성공적인 시스템은 새로운 유스케이스가 등장하거나 기존 사례가 변경됨에 따라 성장하고 변화해야 한다.
따라서, 쿠버네티스는 쿠버네티스 API가 지속적으로 변경되고 성장할 수 있도록 설계했다.
쿠버네티스 프로젝트는 기존 클라이언트와의 호환성을 깨지 _않고_ 다른 프로젝트가
적응할 기회를 가질 수 있도록 장기간 해당 호환성을 유지하는 것을 목표로 한다.
일반적으로, 새 API 리소스와 새 리소스 필드는 자주 추가될 수 있다.
리소스 또는 필드를 제거하려면
[API 지원 중단 정책](/docs/reference/using-api/deprecation-policy/)을 따라야 한다.
쿠버네티스는 일반적으로 API 버전 `v1` 에서 안정 버전(GA)에 도달하면, 공식 쿠버네티스 API에
대한 호환성 유지를 강력하게 이행한다. 또한,
쿠버네티스는 가능한 경우 _베타_ API 버전에서도 호환성을 유지한다.
베타 API를 채택하면 기능이 안정된 후에도 해당 API를 사용하여 클러스터와
계속 상호 작용할 수 있다.
{{< note >}}
쿠버네티스는 또한 _알파_ API 버전에 대한 호환성을 유지하는 것을 목표로 하지만, 일부
상황에서는 호환성이 깨진다. 알파 API 버전을 사용하는 경우, API가 변경된 경우 클러스터를
업그레이드할 때 쿠버네티스에 대한 릴리스 정보를 확인한다.
{{< /note >}}
API 버전 수준 정의에 대한 자세한 내용은
[API 버전 레퍼런스](/ko/docs/reference/using-api/api-overview/#api-버전-규칙)를 참조한다.
## API 확장
쿠버네티스 API는 다음 두 가지 방법 중 하나로 확장할 수 있다.
@@ -145,3 +151,5 @@ API 버전 수준 정의에 대한 자세한 내용은
클러스터가 API 접근을 위한 인증 및 권한을 관리하는 방법을 설명한다.
- [API 레퍼런스](/docs/reference/kubernetes-api/)를
읽고 API 엔드포인트, 리소스 유형 및 샘플에 대해 배우기.
- [API 변경 사항](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme)에서
호환 가능한 변경 사항을 구성하고, API를 변경하는 방법에 대해 알아본다.