Fix markdown. Rewrite some kanji to hiragana. Make parentheses half-width.
This commit is contained in:
TAKAHASHI Shuuji
@@ -67,7 +67,7 @@ APIが宣言的ではない兆候として、次のものがあります:
|
||||
- APIをオブジェクトとして簡単に表現できない
|
||||
- 停止している処理を処理ID、もしくは処理オブジェクトで表現することを選択している
|
||||
|
||||
## ConfigMapとカスタムリソースのどちらを使うべきか?
|
||||
## ConfigMapとカスタムリソースのどちらを使うべきか？
|
||||
|
||||
下記のいずれかに該当する場合は、ConfigMapを使ってください:
|
||||
|
||||
@@ -99,7 +99,7 @@ Kubernetesは、クラスターへカスタムリソースを追加する2つの
|
||||
|
||||
Kubernetesは、さまざまなユーザーのニーズを満たすためにこれら2つのオプションを提供しており、使いやすさや柔軟性が損なわれることはありません。
|
||||
|
||||
アグリゲートAPIは、プロキシーとして機能するプライマリAPIサーバーの背後にある、下位のAPIServerです。このような配置は[APIアグリゲーション](/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) (AA)と呼ばれています。ユーザーにとっては、単にAPIサーバーが拡張されているように見えます。
|
||||
アグリゲートAPIは、プロキシーとして機能するプライマリAPIサーバーの背後にある、下位のAPIServerです。このような配置は[APIアグリゲーション](/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)(AA)と呼ばれています。ユーザーにとっては、単にAPIサーバーが拡張されているように見えます。
|
||||
|
||||
CRDでは、APIサーバーの追加なしに、ユーザーが新しい種類のリソースを作成できます。CRDを使うには、APIアグリゲーションを理解する必要はありません。
|
||||
|
||||
@@ -156,7 +156,7 @@ CRDは、アグリゲートAPIと比べ、簡単に作れます。
|
||||
| その他のサブリソース | "logs"や"exec"のような、CRUD以外の処理の追加 | いいえ | はい |
|
||||
| strategic-merge-patch |`Content-Type: application/strategic-merge-patch+json`で、PATCHをサポートする新しいエンドポイント。ローカル、サーバー、どちらでも更新されうるオブジェクトに有用。さらなる情報は["APIオブジェクトをkubectl patchで決まった場所で更新"](/docs/tasks/run-application/update-api-object-kubectl-patch/)を参照 | いいえ | はい |
|
||||
| プロトコルバッファ | プロトコルバッファを使用するクライアントをサポートする新しいリソース | いいえ | はい |
|
||||
| OpenAPIスキーマ | サーバーから動的に取得できる型のOpenAPI(スワッガー)スキーマはあるか、許可されたフィールドのみが設定されるようにすることで、ユーザーはフィールド名のスペルミスから保護されているか、型は強制されているか(言い換えると、「文字列」フィールドに「int」を入れさせない) | はい、[OpenAPI v3.0 validation](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation) スキーマがベース(1.16でGA) | はい |
|
||||
| OpenAPIスキーマ | サーバーから動的に取得できる型のOpenAPI(Swagger)スキーマはあるか、許可されたフィールドのみが設定されるようにすることで、ユーザーはフィールド名のスペルミスから保護されているか、型は強制されているか(言い換えると、「文字列」フィールドに「int」を入れさせない) | はい、[OpenAPI v3.0 validation](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation) スキーマがベース(1.16でGA) | はい |
|
||||
|
||||
### 一般的な機能
|
||||
|
||||
@@ -185,7 +185,7 @@ CRD、またはアグリゲートAPI、どちらを使ってカスタムリソ
|
||||
|
||||
### サードパーティのコードと新しい障害点
|
||||
|
||||
CRDを作成しても、勝手に新しい障害点が追加されてしまうことはありませんが（たとえば、サードパーティのコードをAPIサーバーで実行することによって）、パッケージ（たとえば、チャート）またはその他のインストールバンドルには、多くの場合、CRDと新しいカスタムリソースのビジネスロジックを実装するサードパーティコードが入ったDeploymentが含まれます。
|
||||
CRDを作成しても、勝手に新しい障害点が追加されてしまうことはありませんが(たとえば、サードパーティのコードをAPIサーバーで実行することによって)、パッケージ(たとえば、Chart)またはその他のインストールバンドルには、多くの場合、CRDと新しいカスタムリソースのビジネスロジックを実装するサードパーティコードが入ったDeploymentが含まれます。
|
||||
|
||||
アグリゲートAPIサーバーのインストールすると、常に新しいDeploymentが付いてきます。
|
||||
|
||||
|
||||
@@ -32,7 +32,7 @@ Kubernetesは柔軟な設定が可能で、高い拡張性を持っています
|
||||
|
||||
ホスティングされたKubernetesサービスやマネージドなKubernetesでは、フラグと設定ファイルが常に変更できるとは限りません。変更可能な場合でも、通常はクラスターの管理者のみが変更できます。また、それらは将来のKubernetesバージョンで変更される可能性があり、設定変更にはプロセスの再起動が必要になるかもしれません。これらの理由により、この方法は他の選択肢が無いときにのみ利用するべきです。
|
||||
|
||||
[ResourceQuota](/docs/concepts/policy/resource-quotas/)、[PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/)、[NetworkPolicy](/docs/concepts/services-networking/network-policies/)、そしてロールベースアクセス制御([RBAC](/docs/reference/access-authn-authz/rbac/))といった *ビルトインポリシーAPI* は、ビルトインのKubernetes APIです。APIは通常、ホスティングされたKubernetesサービスやマネージドなKubernetesで利用されます。これらは宣言的で、Podのような他のKubernetesリソースと同じ慣例に従っています。そのため、新しいクラスターの設定は繰り返し再利用することができ、アプリケーションと同じように管理することが可能です。更に、安定版（stable）を利用している場合、他のKubernetes APIのような[定義済みのサポートポリシー](/docs/reference/deprecation-policy/)を利用することができます。これらの理由により、この方法は、適切な用途の場合、 *設定ファイル* や *フラグ* よりも好まれます。
|
||||
[ResourceQuota](/docs/concepts/policy/resource-quotas/)、[PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/)、[NetworkPolicy](/docs/concepts/services-networking/network-policies/)、そしてロールベースアクセス制御([RBAC](/docs/reference/access-authn-authz/rbac/))といった *ビルトインポリシーAPI* は、ビルトインのKubernetes APIです。APIは通常、ホスティングされたKubernetesサービスやマネージドなKubernetesで利用されます。これらは宣言的で、Podのような他のKubernetesリソースと同じ慣例に従っています。そのため、新しいクラスターの設定は繰り返し再利用することができ、アプリケーションと同じように管理することが可能です。さらに、安定版(stable)を利用している場合、他のKubernetes APIのような[定義済みのサポートポリシー](/docs/reference/deprecation-policy/)を利用することができます。これらの理由により、この方法は、適切な用途の場合、 *設定ファイル* や *フラグ* よりも好まれます。
|
||||
|
||||
## エクステンション
|
||||
|
||||
@@ -57,8 +57,8 @@ Kubernetes上でうまく動くクライアントプログラムを書くため
|
||||
呼び出されるサービスは *Webhookバックエンド* と呼ばれます。コントローラーのように、Webhookも障害点を追加します。
|
||||
|
||||
Webhookのモデルでは、Kubernetesは外部のサービスを呼び出します。
|
||||
*バイナリプラグイン* モデルでは、Kubernetesはバイナリ（プログラム）を実行します。
|
||||
バイナリプラグインはkubelet（例、[FlexVolumeプラグイン](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md)、[ネットワークプラグイン](/docs/concepts/cluster-administration/network-plugins/)）、またkubectlで利用されています。
|
||||
*バイナリプラグイン* モデルでは、Kubernetesはバイナリ(プログラム)を実行します。
|
||||
バイナリプラグインはkubelet(例、[FlexVolumeプラグイン](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md)、[ネットワークプラグイン](/docs/concepts/cluster-administration/network-plugins/))、またkubectlで利用されています。
|
||||
|
||||
下図は、それぞれの拡張ポイントが、Kubernetesのコントロールプレーンとどのように関わっているかを示しています。
|
||||
|
||||
@@ -103,7 +103,7 @@ Webhookのモデルでは、Kubernetesは外部のサービスを呼び出しま
|
||||
|
||||
### ビルトインリソースの変更
|
||||
|
||||
カスタムリソースを追加し、KubernetesAPIを拡張する場合、新たに追加されたリソースは常に新しいAPIグループに分類されます。既存のAPIグループを置き換えたり、変更することはできません。APIを追加することは直接、既存のAPI（例、Pod）の振る舞いに影響を与えることは無いですが、APIアクセスエクステンションの場合、その可能性があります。
|
||||
カスタムリソースを追加し、KubernetesAPIを拡張する場合、新たに追加されたリソースは常に新しいAPIグループに分類されます。既存のAPIグループを置き換えたり、変更することはできません。APIを追加することは直接、既存のAPI(例、Pod)の振る舞いに影響を与えることは無いですが、APIアクセスエクステンションの場合、その可能性があります。
|
||||
|
||||
### APIアクセスエクステンション
|
||||
|
||||
@@ -111,7 +111,7 @@ Webhookのモデルでは、Kubernetesは外部のサービスを呼び出しま
|
||||
|
||||
これらの各ステップごとに拡張ポイントが用意されています。
|
||||
|
||||
Kubdernetesはいくつかのビルトイン認証方式をサポートしています。それは認証プロキシの後ろに配置することも可能で、認可ヘッダーを通じて（Webhookの）検証のために外部サービスにトークンを送ることもできます。全てのこれらの方法は[認証ドキュメント](/docs/reference/access-authn-authz/authentication/)でカバーされています。
|
||||
Kubdernetesはいくつかのビルトイン認証方式をサポートしています。それは認証プロキシの後ろに配置することも可能で、認可ヘッダーを通じて(Webhookの)検証のために外部サービスにトークンを送ることもできます。全てのこれらの方法は[認証ドキュメント](/docs/reference/access-authn-authz/authentication/)でカバーされています。
|
||||
|
||||
### 認証
|
||||
|
||||
@@ -138,7 +138,7 @@ Kubernetesはいくつかのビルトイン認証方式と、それらが要件
|
||||
|
||||
### デバイスプラグイン
|
||||
|
||||
[デバイスプラグイン](/docs/concepts/cluster-administration/device-plugins/)を通じて、ノードが新たなノードのリソース（CPU、メモリなどのビルトインのものに加え）を見つけることを可能にします。
|
||||
[デバイスプラグイン](/docs/concepts/cluster-administration/device-plugins/)を通じて、ノードが新たなノードのリソース(CPU、メモリなどのビルトインのものに加え)を見つけることを可能にします。
|
||||
|
||||
### ネットワークプラグイン
|
||||
|
||||
@@ -150,7 +150,7 @@ Kubernetesはいくつかのビルトイン認証方式と、それらが要件
|
||||
|
||||
これはかなりの大きな作業で、ほとんど全てのKubernetesユーザーはスケジューラーを変更する必要はありません。
|
||||
|
||||
スケジューラは[Webhook](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/scheduler_extender.md)もサポートしており、Webhookバックエンド（スケジューラーエクステンション）を通じてPodを配置するために選択されたノードをフィルタリング、優先度付けすることが可能です。
|
||||
スケジューラは[Webhook](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/scheduler_extender.md)もサポートしており、Webhookバックエンド(スケジューラーエクステンション)を通じてPodを配置するために選択されたノードをフィルタリング、優先度付けすることが可能です。
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -24,7 +24,7 @@ Kubernetes上でワークロードを稼働させている人は、しばしば
|
||||
## Kubernetesにおけるオペレーター
|
||||
|
||||
Kubernetesは自動化のために設計されています。追加の作業、設定無しに、Kubernetesのコア機能によって多数のビルトインされた自動化機能が提供されます。
|
||||
ワークロードのデプロイ及び稼働を自動化するためにKubernetesを使うことができます。 *更に* Kubernetesがそれをどのように行うかの自動化も可能です。
|
||||
ワークロードのデプロイおよび稼働を自動化するためにKubernetesを使うことができます。 *さらに* Kubernetesがそれをどのように行うかの自動化も可能です。
|
||||
|
||||
Kubernetesの{{< glossary_tooltip text="コントローラー" term_id="controller" >}}コンセプトは、Kubernetesのソースコードを修正すること無く、クラスターの振る舞いを拡張することを可能にします。
|
||||
オペレーターはKubernetes APIのクライアントで、[Custom Resource](/docs/concepts/api-extension/custom-resources/)にとっての、コントローラーのように振る舞います。
|
||||
|
||||
Reference in New Issue
Block a user