Skip to content

Commit

Permalink
working
Browse files Browse the repository at this point in the history
  • Loading branch information
kohbis committed Aug 12, 2024
1 parent d75f71a commit 076cadd
Showing 1 changed file with 57 additions and 72 deletions.
129 changes: 57 additions & 72 deletions content/ja/docs/reference/using-api/deprecation-policy.md
Original file line number Diff line number Diff line change
Expand Up @@ -310,85 +310,70 @@ KubernetesリリースではこれらのプログラムのフラグやCLIコマ

CLI要素は事実上システムに対するAPIの一部ですが、REST APIと同じ方法ではバージョン管理されておらず、非推奨のルールは次のようになっています:

**Rule #5a: CLI elements of user-facing components (e.g. kubectl) must function
after their announced deprecation for no less than:**
**ルール #5a: ユーザー向けのコンポーネントのCLI要素(例. kubectl)は
非推奨がアナウンスされてから以下の期間は機能しなければなりません:**

* **GA: 12 months or 2 releases (whichever is longer)**
* **Beta: 3 months or 1 release (whichever is longer)**
* **Alpha: 0 releases**
* **GA: 12ヶ月または2リリース(いずれか長い方)**
* **Beta: 3ヶ月または1リリース(いずれか長い方)**
* **Alpha: 0リリース**

**Rule #5b: CLI elements of admin-facing components (e.g. kubelet) must function
after their announced deprecation for no less than:**
**ルール #5b: 管理者向けのコンポーネントのCLI要素(例. kubelet)は
非推奨がアナウンスされてから以下の期間は機能しなければなりません:**

* **GA: 6 months or 1 release (whichever is longer)**
* **Beta: 3 months or 1 release (whichever is longer)**
* **Alpha: 0 releases**
* **GA: 6ヶ月または1リリース(いずれか長い方)**
* **Beta: 3ヶ月または1リリース(いずれか長い方)**
* **Alpha: 0リリース**

**Rule #5c: Command line interface (CLI) elements cannot be deprecated in favor of
less stable CLI elements**
**ルール #5c: コマンドラインインターフェース(CLI)の要素は
より不安定なCLI要素の代わりに廃止されることはありません**

Similar to the Rule #3 for APIs, if an element of a command line interface is being replaced with an
alternative implementation, such as by renaming an existing element, or by switching to
use configuration sourced from a file
instead of a command line argument, that recommended alternative must be of
the same or higher stability level.

**Rule #6: Deprecated CLI elements must emit warnings (optionally disable)
when used.**

## Deprecating a feature or behavior

Occasionally a Kubernetes release needs to deprecate some feature or behavior
of the system that is not controlled by the API or CLI. In this case, the
rules for deprecation are as follows:

**Rule #7: Deprecated behaviors must function for no less than 1 year after their
announced deprecation.**

If the feature or behavior is being replaced with an alternative implementation
that requires work to adopt the change, there should be an effort to simplify
the transition whenever possible. If an alternative implementation is under
Kubernetes organization control, the following rules apply:

**Rule #8: The feature of behavior must not be deprecated in favor of an alternative
implementation that is less stable**

For example, a generally available feature cannot be deprecated in favor of a Beta
replacement.
The Kubernetes project does, however, encourage users to adopt and transitions to alternative
implementations even before they reach the same maturity level. This is particularly important
for exploring new use cases of a feature or getting an early feedback on the replacement.

Alternative implementations may sometimes be external tools or products,
for example a feature may move from the kubelet to container runtime
that is not under Kubernetes project control. In such cases, the rule cannot be
applied, but there must be an effort to ensure that there is a transition path
that does not compromise on components' maturity levels. In the example with
container runtimes, the effort may involve trying to ensure that popular container runtimes
have versions that offer the same level of stability while implementing that replacement behavior.

Deprecation rules for features and behaviors do not imply that all changes
to the system are governed by this policy.
These rules applies only to significant, user-visible behaviors which impact the
correctness of applications running on Kubernetes or that impact the
administration of Kubernetes clusters, and which are being removed entirely.

An exception to the above rule is _feature gates_. Feature gates are key=value
pairs that allow for users to enable/disable experimental features.

Feature gates are intended to cover the development life cycle of a feature - they
are not intended to be long-term APIs. As such, they are expected to be deprecated
and removed after a feature becomes GA or is dropped.

As a feature moves through the stages, the associated feature gate evolves.
The feature life cycle matched to its corresponding feature gate is:

* Alpha: the feature gate is disabled by default and can be enabled by the user.
* Beta: the feature gate is enabled by default and can be disabled by the user.
* GA: the feature gate is deprecated (see ["Deprecation"](#deprecation)) and becomes
non-operational.
* GA, deprecation window complete: the feature gate is removed and calls to it are
no longer accepted.
APIに関するルール#3と同様、コマンドラインインターフェースの要素が代替実装にリプレイスされる、
例えば既存の要素名の変更やコマンドライン引数の代わりにファイルから取得した設定を使用するように切り替える場合、
推奨される代替案は同じかそれ以上の安定性レベルでなければなりません。

**ルール #6: 非推奨のCLI要素は使用時に警告を表示しなければなりません(オプションで無効化可能)**

## 機能や動作の非推奨化

時には、KubernetesリリースではAPIやCLIによって制御されないシステムの機能や動作を非推奨にする必要があります。
その場合、非推奨に関するルールは以下の通りです:

**ルール #7: 非推奨となる動作はアナウンスされてから最低1年間は機能しなければなりません。**

機能や動作が、変更を取り込む作業が必要な代替実装に置き換えられる場合、
可能な限り移行を簡素化する努力が必要です。
代替実装がKubernetes organizationの管理下にある場合、以下のルールが適用されます:

**ルール #8: 安定性の低い代替実装を優先して、動作の機能を非推奨にしてはなりません**

例えば、一般提供されている機能がBeta版にリプレイスために非推奨にされることはありません。
ただし、Kubernetesプロジェクトは同じ成熟度に達する前であっても、ユーザーが代替実装を採用して移行することを推奨しています。
これは、機能の新しいユースケースを検討したり、リプレイスについての早期フィードバックを得るために特に重要です。

代替実装は、外部のツールや製品である場合があります。
例えば、機能がkubeletからKubernetesプロジェクト管理外のコンテナランタイムに移行することがあります。
このような場合、ルールを適用することはできませんが、コンポーネントの成熟度を損なわない移行方法を確保するための努力が必要です。
コンテナランタイムを例に挙げると、一般的なコンテナランタイムが、リプレイスする動作を実装しながら同等の安定性を提供するバージョンを持つように取り組む必要があるかもしれません。

機能と動作の非推奨ルールは、システムに対するすべての変更がこのポリシーによって管理されることを意味するものではありません。
これらのルールはKubernetes上で実行されているアプリケーションの正確性やKubernetesクラスターの管理に影響する、また完全に削除されるものにのみ適用されます。

上記のルールの例外は _フィーチャーゲート_ です。
フィーチャーゲートはユーザーが実験的な機能を有効/無効にできるようにするキー=バリューのペアです。

フィーチャーゲートは機能の開発ライフサイクルをカバーすることを目的としており、
長期的なAPIを目的としたものではありません。
そのため、機能がGAになるが削除された後は、非推奨となり削除されることが期待されます。

機能が段階を踏むにつれて、関連するフィーチャーゲートも進化します。
機能のライフサイクルと対応するフィーチャーゲートの関係は以下の通りです:

* Alpha: フィーチャーゲートはデフォルトで無効化されており、ユーザーによって有効化できます。
* Beta: フィーチャーゲートはデフォルトで有効化されており、ユーザーによって無効化できます。
* GA: フィーチャーゲートは非推奨となり(["非推奨"](#deprecation)を参照)動作しなくなります。
* GA、非推奨期間終了後: フィーチャーゲートは削除され、呼び出しは受け付けられなくなります。

### Deprecation

Expand Down

0 comments on commit 076cadd

Please sign in to comment.