Merge pull request #31160 from riita10069/ja-fix-link
Replace all inappropriate links to English pages in Japanese documentation.pull/31419/head
Kubernetes Prow Robot
GitHub
commit
624ebf19f5
|
|
@ -177,7 +177,7 @@ rules:
|
|||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
[Cloud Controller Manager Administration](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager)
|
||||
[Cloud Controller Manager Administration](/ja/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager)
|
||||
はクラウドコントラーマネージャーの実行と管理を説明しています。
|
||||
|
||||
どのようにあなた自身のクラウドコントローラーマネージャーが実装されるのか、もしくは既存プロジェクトの拡張について知りたいですか？
|
||||
|
|
@ -186,4 +186,4 @@ rules:
|
|||
|
||||
本ドキュメントでハイライトした共有コントローラー（Node、Route、Service）の実装と共有クラウドプロバイダーインターフェースに沿ったいくつかの足場は、Kubernetesコアの一部です。クラウドプロバイダに特化した実装は、Kubernetesのコアの外部として、また`CloudProvider`インターフェースを実装します。
|
||||
|
||||
プラグイン開発ついての詳細な情報は、[Developing Cloud Controller Manager](/docs/tasks/administer-cluster/developing-cloud-controller-manager/)を見てください。
|
||||
プラグイン開発ついての詳細な情報は、[Developing Cloud Controller Manager](/ja/docs/tasks/administer-cluster/developing-cloud-controller-manager/)を見てください。
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ weight: 20
|
|||
## クラスターからマスターへの通信
|
||||
|
||||
クラスターからマスターへのすべての通信経路は、APIサーバーで終端します(他のマスターコンポーネントはどれもリモートサービスを公開するように設計されていません)。
|
||||
一般的には、1つ以上の形式のクライアント[認証](/docs/reference/access-authn-authz/authentication/)が有効になっている状態で、APIサーバーはセキュアなHTTPSポート(443)でリモート接続をlistenするように構成されています。
|
||||
一般的には、1つ以上の形式のクライアント[認証](/ja/docs/reference/access-authn-authz/authentication/)が有効になっている状態で、APIサーバーはセキュアなHTTPSポート(443)でリモート接続をlistenするように構成されています。
|
||||
特に[匿名のリクエスト](/docs/reference/access-authn-authz/authentication/#anonymous-requests)または[サービスアカウントトークン](/docs/reference/access-authn-authz/authentication/#service-account-tokens)が許可されている場合は、1つまたは複数の[認証](/docs/reference/access-authn-authz/authorization/)を有効にする必要があります。
|
||||
|
||||
ノードには、有効なクライアント認証情報を使って安全にAPIサーバーに接続できるように、クラスターのパブリックなルート証明書をプロビジョニングする必要があります。
|
||||
|
|
|
|||
|
|
@ -267,7 +267,7 @@ Pod以外のプロセス用にリソースを明示的に予約したい場合
|
|||
{{< feature-state state="alpha" for_k8s_version="v1.16" >}}
|
||||
`TopologyManager`の[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にすると、
|
||||
kubeletはリソースの割当を決定する際にトポロジーのヒントを利用できます。
|
||||
詳細は、[ノードのトポロジー管理ポリシーを制御する](/docs/tasks/administer-cluster/topology-manager/)を参照してください。
|
||||
詳細は、[ノードのトポロジー管理ポリシーを制御する](/ja/docs/tasks/administer-cluster/topology-manager/)を参照してください。
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
|
|
|||
|
|
@ -30,7 +30,7 @@ content_type: concept
|
|||
* [OVN4NFV-K8S-Plugin](https://github.com/opnfv/ovn4nfv-k8s-plugin)は、クラウドネイティブベースのService function chaining(SFC)、Multiple OVNオーバーレイネットワーク、動的なサブネットの作成、動的な仮想ネットワークの作成、VLANプロバイダーネットワーク、Directプロバイダーネットワークを提供し、他のMulti-networkプラグインと付け替え可能なOVNベースのCNIコントローラープラグインです。
|
||||
* [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) Container Plug-in(NCP)は、VMware NSX-TとKubernetesなどのコンテナオーケストレーター間のインテグレーションを提供します。また、NSX-Tと、Pivotal Container Service(PKS)とOpenShiftなどのコンテナベースのCaaS/PaaSプラットフォームとのインテグレーションも提供します。
|
||||
* [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst)は、Kubernetes Podと非Kubernetes環境間で可視化とセキュリティモニタリングを使用してポリシーベースのネットワークを提供するSDNプラットフォームです。
|
||||
* [Romana](https://romana.io)は、[NetworkPolicy API](/docs/concepts/services-networking/network-policies/)もサポートするPodネットワーク向けのL3のネットワークソリューションです。Kubeadmアドオンのインストールの詳細は[こちら](https://github.com/romana/romana/tree/master/containerize)で確認できます。
|
||||
* [Romana](https://romana.io)は、[NetworkPolicy API](/ja/docs/concepts/services-networking/network-policies/)もサポートするPodネットワーク向けのL3のネットワークソリューションです。Kubeadmアドオンのインストールの詳細は[こちら](https://github.com/romana/romana/tree/master/containerize)で確認できます。
|
||||
* [Weave Net](https://www.weave.works/docs/net/latest/kubernetes/kube-addon/)は、ネットワークパーティションの両面で機能し、外部データベースを必要とせずに、ネットワークとネットワークポリシーを提供します。
|
||||
|
||||
## サービスディスカバリ
|
||||
|
|
|
|||
|
|
@ -31,7 +31,7 @@ Kubernetesクラスターの計画、セットアップ、設定の例を知る
|
|||
|
||||
* [ノードの管理](/ja/docs/concepts/architecture/nodes/)方法について学んでください。
|
||||
|
||||
* 共有クラスターにおける[リソースクォータ](/docs/concepts/policy/resource-quotas/)のセットアップと管理方法について学んでください。
|
||||
* 共有クラスターにおける[リソースクォータ](/ja/docs/concepts/policy/resource-quotas/)のセットアップと管理方法について学んでください。
|
||||
|
||||
## クラスターをセキュアにする
|
||||
|
||||
|
|
|
|||
|
|
@ -157,7 +157,7 @@ deployment.apps/my-deployment created
|
|||
persistentvolumeclaim/my-pvc created
|
||||
```
|
||||
|
||||
`kubectl`についてさらに知りたい場合は、[kubectlの概要](/docs/reference/kubectl/overview/)を参照してください。
|
||||
`kubectl`についてさらに知りたい場合は、[kubectlの概要](/ja/docs/reference/kubectl/overview/)を参照してください。
|
||||
|
||||
## ラベルを有効に使う
|
||||
|
||||
|
|
@ -294,7 +294,7 @@ my-nginx-2035384211-u3t6x 1/1 Running 0 23m fe
|
|||
|
||||
このコマンドでは"app=nginx"というラベルのついた全てのPodを出力し、Podのtierという項目も表示します(`-L`または`--label-columns`で指定)。
|
||||
|
||||
さらなる情報は、[ラベル](/docs/concepts/overview/working-with-objects/labels/)や[kubectl label](/docs/reference/generated/kubectl/kubectl-commands/#label)を参照してください。
|
||||
さらなる情報は、[ラベル](/ja/docs/concepts/overview/working-with-objects/labels/)や[kubectl label](/docs/reference/generated/kubectl/kubectl-commands/#label)を参照してください。
|
||||
|
||||
## アノテーションの更新
|
||||
|
||||
|
|
@ -313,7 +313,7 @@ metadata:
|
|||
...
|
||||
```
|
||||
|
||||
さらなる情報は、[アノテーション](/docs/concepts/overview/working-with-objects/annotations/) や、[kubectl annotate](/docs/reference/generated/kubectl/kubectl-commands/#annotate)を参照してください。
|
||||
さらなる情報は、[アノテーション](/ja/docs/concepts/overview/working-with-objects/annotations/) や、[kubectl annotate](/docs/reference/generated/kubectl/kubectl-commands/#annotate)を参照してください。
|
||||
|
||||
## アプリケーションのスケール
|
||||
|
||||
|
|
@ -443,7 +443,7 @@ deployment.apps/my-nginx scaled
|
|||
kubectl edit deployment/my-nginx
|
||||
```
|
||||
|
||||
できました!Deploymentはデプロイされたnginxのアプリケーションを宣言的にプログレッシブに更新します。更新途中では、決まった数の古いレプリカのみダウンし、一定数の新しいレプリカが希望するPod数以上作成されても良いことを保証します。詳細について学ぶには[Deployment page](/docs/concepts/workloads/controllers/deployment/)を参照してください。
|
||||
できました!Deploymentはデプロイされたnginxのアプリケーションを宣言的にプログレッシブに更新します。更新途中では、決まった数の古いレプリカのみダウンし、一定数の新しいレプリカが希望するPod数以上作成されても良いことを保証します。詳細について学ぶには[Deployment page](/ja/docs/concepts/workloads/controllers/deployment/)を参照してください。
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -192,6 +192,6 @@ immutable: true
|
|||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* [Secret](/docs/concepts/configuration/secret/)について読む。
|
||||
* [Secret](/ja/docs/concepts/configuration/secret/)について読む。
|
||||
* [Podを構成してConfigMapを使用する](/ja/docs/tasks/configure-pod-container/configure-pod-configmap/)を読む。
|
||||
* コードを設定から分離する動機を理解するために[The Twelve-Factor App](https://12factor.net/ja/)を読む。
|
||||
|
|
|
|||
|
|
@ -51,8 +51,8 @@ Huge PageはLinux固有の機能であり、Nodeのカーネルはデフォル
|
|||
|
||||
CPUとメモリーは、まとめて*コンピュートリソース*または単に*リソース*と呼ばれます。
|
||||
コンピューティングリソースは、要求され、割り当てられ、消費され得る測定可能な量です。
|
||||
それらは[API resources](/docs/concepts/overview/kubernetes-api/)とは異なります。
|
||||
Podや[Services](/docs/concepts/services-networking/service/)などのAPIリソースは、Kubernetes APIサーバーを介して読み取りおよび変更できるオブジェクトです。
|
||||
それらは[API resources](/ja/docs/concepts/overview/kubernetes-api/)とは異なります。
|
||||
Podや[Services](/ja/docs/concepts/services-networking/service/)などのAPIリソースは、Kubernetes APIサーバーを介して読み取りおよび変更できるオブジェクトです。
|
||||
|
||||
## Podとコンテナのリソース要求と制限
|
||||
|
||||
|
|
@ -624,9 +624,9 @@ LastState: map[terminated:map[exitCode:137 reason:OOM Killed startedAt:2015-07-0
|
|||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* [コンテナとPodへのメモリーリソースの割り当て](/docs/tasks/configure-pod-container/assign-memory-resource/)ハンズオンを行う
|
||||
* [コンテナとPodへのメモリーリソースの割り当て](/ja/docs/tasks/configure-pod-container/assign-memory-resource/)ハンズオンを行う
|
||||
|
||||
* [コンテナとPodへのCPUリソースの割り当て](/docs/tasks/configure-pod-container/assign-cpu-resource/)ハンズオンを行う
|
||||
* [コンテナとPodへのCPUリソースの割り当て](/ja/docs/tasks/configure-pod-container/assign-cpu-resource/)ハンズオンを行う
|
||||
|
||||
* 要求と制限の違いの詳細については、[リソースQoS](https://git.k8s.io/community/contributors/design-proposals/node/resource-qos.md)を参照する
|
||||
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ kubeconfigを使用すると、クラスターに、ユーザー、名前空間
|
|||
|
||||
デフォルトでは、`kubectl`は`$HOME/.kube`ディレクトリ内にある`config`という名前のファイルを探します。`KUBECONFIG`環境変数を設定するか、[`--kubeconfig`](/docs/reference/generated/kubectl/kubectl/)フラグで指定することで、別のkubeconfigファイルを指定することもできます。
|
||||
|
||||
kubeconfigファイルの作成と指定に関するステップバイステップの手順を知りたいときは、[複数のクラスターへのアクセスを設定する](/docs/tasks/access-application-cluster/configure-access-multiple-clusters)を参照してください。
|
||||
kubeconfigファイルの作成と指定に関するステップバイステップの手順を知りたいときは、[複数のクラスターへのアクセスを設定する](/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters)を参照してください。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
|
|
|
|||
|
|
@ -311,9 +311,9 @@ stringData:
|
|||
|
||||
Secretを作成するには、いくつかのオプションがあります。
|
||||
|
||||
- [create Secret using `kubectl` command](/docs/tasks/configmap-secret/managing-secret-using-kubectl/)
|
||||
- [create Secret from config file](/docs/tasks/configmap-secret/managing-secret-using-config-file/)
|
||||
- [create Secret using kustomize](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)
|
||||
- [create Secret using `kubectl` command](/ja/docs/tasks/configmap-secret/managing-secret-using-kubectl/)
|
||||
- [create Secret from config file](/ja/docs/tasks/configmap-secret/managing-secret-using-config-file/)
|
||||
- [create Secret using kustomize](/ja/docs/tasks/configmap-secret/managing-secret-using-kustomize/)
|
||||
|
||||
## Secretの編集
|
||||
|
||||
|
|
@ -636,7 +636,7 @@ Kubernetesベータ機能*ImmutableSecrets and ConfigMaps*は、個々のSecrets
|
|||
- アプリケーションの停止を引き起こす可能性のある偶発的な（または不要な）更新からユーザーを保護します
|
||||
- imutableとしてマークされたSecretのウォッチを閉じることで、kube-apiserverの負荷を大幅に削減することができ、クラスターのパフォーマンスを向上させます。
|
||||
|
||||
この機能は、`ImmutableEphemeralVolumes`[feature gate](/docs/reference/command-line-tools-reference/feature-gates/)によって制御されます。これは、v1.19以降デフォルトで有効になっています。`immutable`フィールドを`true`に設定することで、imutableのSecretを作成できます。例えば、
|
||||
この機能は、`ImmutableEphemeralVolumes`[feature gate](/ja/docs/reference/command-line-tools-reference/feature-gates/)によって制御されます。これは、v1.19以降デフォルトで有効になっています。`immutable`フィールドを`true`に設定することで、imutableのSecretを作成できます。例えば、
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
|
|
@ -662,7 +662,7 @@ kubeletはこの情報をPodのためにプライベートイメージをpullす
|
|||
|
||||
#### imagePullSecretを手動で指定する
|
||||
|
||||
`ImagePullSecrets`の指定の方法は[コンテナイメージのドキュメント](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod)に記載されています。
|
||||
`ImagePullSecrets`の指定の方法は[コンテナイメージのドキュメント](/ja/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod)に記載されています。
|
||||
|
||||
### imagePullSecretsが自動的にアタッチされるようにする
|
||||
|
||||
|
|
@ -1006,7 +1006,7 @@ HTTPリクエストを扱い、複雑なビジネスロジックを処理し、
|
|||
### Secret APIを使用するクライアント
|
||||
|
||||
Secret APIとやりとりするアプリケーションをデプロイするときには、[RBAC](
|
||||
/docs/reference/access-authn-authz/rbac/)のような[認可ポリシー](
|
||||
/ja/docs/reference/access-authn-authz/rbac/)のような[認可ポリシー](
|
||||
/docs/reference/access-authn-authz/authorization/)を使用して、アクセスを制限すべきです。
|
||||
Secretは様々な種類の重要な値を保持することが多く、サービスアカウントのトークンのようにKubernetes内部や、外部のシステムで昇格できるものも多くあります。個々のアプリケーションが、Secretの能力について推論することができたとしても、同じネームスペースの別のアプリケーションがその推定を覆すこともあります。
|
||||
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ no_list: true
|
|||
<!-- body -->
|
||||
|
||||
## コンテナイメージ {#container-images}
|
||||
[コンテナイメージ](/docs/concepts/containers/images/)はすぐに実行可能なソフトウェアパッケージで、アプリケーションの実行に必要なものをすべて含んています。コードと必要なランタイム、アプリケーションとシステムのライブラリ、そして必須な設定項目のデフォルト値を含みます。
|
||||
[コンテナイメージ](/ja/docs/concepts/containers/images/)はすぐに実行可能なソフトウェアパッケージで、アプリケーションの実行に必要なものをすべて含んています。コードと必要なランタイム、アプリケーションとシステムのライブラリ、そして必須な設定項目のデフォルト値を含みます。
|
||||
|
||||
設計上、コンテナは不変で、既に実行中のコンテナのコードを変更することはできません。コンテナ化されたアプリケーションがあり変更したい場合は、変更を含んだ新しいイメージをビルドし、コンテナを再作成して、更新されたイメージから起動する必要があります。
|
||||
|
||||
|
|
|
|||
|
|
@ -50,7 +50,7 @@ FOO_SERVICE_PORT=<サービスが実行されているポート>
|
|||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* [コンテナライフサイクルフック](/docs/concepts/containers/container-lifecycle-hooks/)の詳細
|
||||
* [コンテナライフサイクルイベントへのハンドラー紐付け](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)のハンズオン
|
||||
* [コンテナライフサイクルフック](/ja/docs/concepts/containers/container-lifecycle-hooks/)の詳細
|
||||
* [コンテナライフサイクルイベントへのハンドラー紐付け](/ja/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)のハンズオン
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ weight: 20
|
|||
|
||||
アグリゲーションレイヤーを使用すると、KubernetesのコアAPIで提供されている機能を超えて、追加のAPIでKubernetesを拡張できます。追加のAPIは、[service-catalog](/docs/concepts/extend-kubernetes/service-catalog/)のような既製のソリューション、または自分で開発したAPIのいずれかです。
|
||||
|
||||
アグリゲーションレイヤーは、[カスタムリソース](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)とは異なり、{{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}}に新しい種類のオブジェクトを認識させる方法です。
|
||||
アグリゲーションレイヤーは、[カスタムリソース](/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources/)とは異なり、{{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}}に新しい種類のオブジェクトを認識させる方法です。
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -26,8 +26,9 @@ Kubernetes上でワークロードを稼働させている人は、しばしば
|
|||
Kubernetesは自動化のために設計されています。追加の作業、設定無しに、Kubernetesのコア機能によって多数のビルトインされた自動化機能が提供されます。
|
||||
ワークロードのデプロイおよび稼働を自動化するためにKubernetesを使うことができます。 *さらに* Kubernetesがそれをどのように行うかの自動化も可能です。
|
||||
|
||||
|
||||
Kubernetesの{{< glossary_tooltip text="オペレーターパターン" term_id="operator-pattern" >}}コンセプトは、Kubernetesのソースコードを修正すること無く、一つ以上のカスタムリソースに{{< glossary_tooltip text="カスタムコントローラー" term_id="controller" >}}をリンクすることで、クラスターの振る舞いを拡張することを可能にします。
|
||||
オペレーターはKubernetes APIのクライアントで、[Custom Resource](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)にとっての、コントローラーのように振る舞います。
|
||||
オペレーターはKubernetes APIのクライアントで、[Custom Resource](/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources/)にとっての、コントローラーのように振る舞います。
|
||||
|
||||
## オペレーターの例 {#example}
|
||||
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: フィールドセレクター(Field Selectors)
|
|||
weight: 60
|
||||
---
|
||||
|
||||
_フィールドセレクター(Field Selectors)_ は、1つかそれ以上のリソースフィールドの値を元に[Kubernetesリソースを選択](/docs/concepts/overview/working-with-objects/kubernetes-objects)するためのものです。
|
||||
_フィールドセレクター(Field Selectors)_ は、1つかそれ以上のリソースフィールドの値を元に[Kubernetesリソースを選択](/ja/docs/concepts/overview/working-with-objects/kubernetes-objects)するためのものです。
|
||||
フィールドセレクタークエリの例は以下の通りです。
|
||||
|
||||
* `metadata.name=my-service`
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ weight: 20
|
|||
|
||||
クラスター内の各オブジェクトには、そのタイプのリソースに固有の[_名前_](#names)があります。すべてのKubernetesオブジェクトには、クラスター全体で一意の[_UID_](#uids)もあります。
|
||||
|
||||
たとえば、同じ[名前空間](/docs/concepts/overview/working-with-objects/namespaces/)内に`myapp-1234`という名前のPodは1つしか含められませんが、`myapp-1234`という名前の1つのPodと1つのDeploymentを含めることができます。
|
||||
たとえば、同じ[名前空間](/ja/docs/concepts/overview/working-with-objects/namespaces/)内に`myapp-1234`という名前のPodは1つしか含められませんが、`myapp-1234`という名前の1つのPodと1つのDeploymentを含めることができます。
|
||||
|
||||
ユーザーが一意ではない属性を付与するために、Kubernetesは[ラベル](/ja/docs/concepts/overview/working-with-objects/labels/)と[アノテーション](/ja/docs/concepts/overview/working-with-objects/annotations/)を提供しています。
|
||||
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ weight: 10
|
|||
|
||||
<!-- overview -->
|
||||
|
||||
デフォルトでは、コンテナは、Kubernetesクラスター上の[計算リソース](/docs/concepts/configuration/manage-resources-containers/)の消費を制限されずに実行されます。リソースクォータを利用すれば、クラスター管理者はリソースの消費と作成を{{< glossary_tooltip text="名前空間" term_id="namespace" >}}ベースで制限することができます。名前空間内では、Podやコンテナは名前空間のリソースクォータで定義された範囲内でできるだけ多くのCPUとメモリーを消費できてしまうため、1つのPodまたはコンテナが利用可能なすべてのリソースを専有してしまう恐れがあります。LimitRangeを利用すれば、このような名前空間内での(Podやコンテナへの)リソースの割り当てを制限するポリシーを定めることができます。
|
||||
デフォルトでは、コンテナは、Kubernetesクラスター上の[計算リソース](/ja/docs/concepts/configuration/manage-resources-containers/)の消費を制限されずに実行されます。リソースクォータを利用すれば、クラスター管理者はリソースの消費と作成を{{< glossary_tooltip text="名前空間" term_id="namespace" >}}ベースで制限することができます。名前空間内では、Podやコンテナは名前空間のリソースクォータで定義された範囲内でできるだけ多くのCPUとメモリーを消費できてしまうため、1つのPodまたはコンテナが利用可能なすべてのリソースを専有してしまう恐れがあります。LimitRangeを利用すれば、このような名前空間内での(Podやコンテナへの)リソースの割り当てを制限するポリシーを定めることができます。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
|
|
@ -50,7 +50,7 @@ LimitRangeに対する競合や変更は、すでに作成済みのリソース
|
|||
制限の使用例については、以下のページを読んでください。
|
||||
|
||||
- [名前空間ごとにCPUの最小値と最大値の制約を設定する方法](/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/)。
|
||||
- [名前空間ごとにメモリーの最小値と最大値の制約を設定する方法](/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/)。
|
||||
- [名前空間ごとにメモリーの最小値と最大値の制約を設定する方法](/ja/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/)。
|
||||
- [名前空間ごとにCPUのRequestとLimitのデフォルト値を設定する方法](/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/)。
|
||||
- [名前空間ごとにメモリーのRequestとLimitのデフォルト値を設定する方法](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)。
|
||||
- [名前空間ごとにストレージ消費量の最小値と最大値を設定する方法](/docs/tasks/administer-cluster/limit-storage-consumption/#limitrange-to-limit-requests-for-storage)。
|
||||
|
|
|
|||
|
|
@ -44,7 +44,7 @@ ResourceQuotaのオブジェクト名は、有効な[DNSサブドメイン名](/
|
|||
|
||||
## リソースクォータの計算
|
||||
|
||||
特定の名前空間において、[コンピュートリソース](/docs/concepts/configuration/manage-resources-containers/)の合計に上限を設定できます。
|
||||
特定の名前空間において、[コンピュートリソース](/ja/docs/concepts/configuration/manage-resources-containers/)の合計に上限を設定できます。
|
||||
|
||||
下記のリソースタイプがサポートされています。
|
||||
|
||||
|
|
@ -152,7 +152,7 @@ Kubernetes v1.8において、ローカルのエフェメラルストレージ
|
|||
| `NotTerminating` | `.spec.activeDeadlineSecondsがnil`であるPodに一致します。 |
|
||||
| `BestEffort` | ベストエフォート型のサービス品質のPodに一致します。 |
|
||||
| `NotBestEffort` | ベストエフォート型のサービス品質でないPodに一致します。 |
|
||||
| `PriorityClass` | 指定された[優先度クラス](/docs/concepts/configuration/pod-priority-preemption)と関連付いているPodに一致します。 |
|
||||
| `PriorityClass` | 指定された[優先度クラス](/ja/docs/concepts/configuration/pod-priority-preemption)と関連付いているPodに一致します。 |
|
||||
|
||||
`BestEffort`スコープはリソースクォータを次のリソースに対するトラッキングのみに制限します:
|
||||
|
||||
|
|
@ -201,7 +201,7 @@ Kubernetes v1.8において、ローカルのエフェメラルストレージ
|
|||
|
||||
{{< feature-state for_k8s_version="v1.17" state="stable" >}}
|
||||
|
||||
Podは特定の[優先度](/docs/concepts/configuration/pod-priority-preemption/#pod-priority)で作成されます。リソースクォータのSpec内にある`scopeSelector`フィールドを使用して、Podの優先度に基づいてPodのシステムリソースの消費をコントロールできます。
|
||||
Podは特定の[優先度](/ja/docs/concepts/configuration/pod-priority-preemption/#pod-priority)で作成されます。リソースクォータのSpec内にある`scopeSelector`フィールドを使用して、Podの優先度に基づいてPodのシステムリソースの消費をコントロールできます。
|
||||
|
||||
リソースクォータのSpec内の`scopeSelector`によってPodが選択されたときのみ、そのリソースクォータが一致し、消費されます。
|
||||
|
||||
|
|
|
|||
|
|
@ -66,5 +66,5 @@ _スコアリング_ ステップでは、Podを割り当てるのに最も適
|
|||
* [Podのオーバーヘッド](/docs/concepts/scheduling-eviction/pod-overhead/)について学んでください。
|
||||
* ボリュームを使用するPodのスケジューリングについて以下で学んでください。
|
||||
* [Volume Topology Support](/docs/concepts/storage/storage-classes/#volume-binding-mode)
|
||||
* [ストレージ容量の追跡](/ja//docs/concepts/storage/storage-capacity/)
|
||||
* [ストレージ容量の追跡](/ja//ja/docs/concepts/storage/storage-capacity/)
|
||||
* [Node-specific Volume Limits](/docs/concepts/storage/storage-limits/)
|
||||
|
|
|
|||
|
|
@ -40,7 +40,7 @@ kubectl get pods -n kube-system | grep kube-scheduler
|
|||
|
||||
スケジューリング性能を改善するため、kube-schedulerは割り当て可能なノードが十分に見つかるとノードの検索を停止できます。大規模クラスターでは、すべてのノードを考慮する単純なアプローチと比較して時間を節約できます。
|
||||
|
||||
クラスター内のすべてのノードに対する十分なノード数を整数パーセンテージで指定します。kube-schedulerは、これをノード数に変換します。スケジューリング中に、kube-schedulerが設定されたパーセンテージを超える十分な割り当て可能なノードを見つけた場合、kube-schedulerはこれ以上割り当て可能なノードを探すのを止め、[スコアリングフェーズ](/docs/concepts/scheduling-eviction/kube-scheduler/#kube-scheduler-implementation)に進みます。
|
||||
クラスター内のすべてのノードに対する十分なノード数を整数パーセンテージで指定します。kube-schedulerは、これをノード数に変換します。スケジューリング中に、kube-schedulerが設定されたパーセンテージを超える十分な割り当て可能なノードを見つけた場合、kube-schedulerはこれ以上割り当て可能なノードを探すのを止め、[スコアリングフェーズ](/ja/docs/concepts/scheduling-eviction/kube-scheduler/#kube-scheduler-implementation)に進みます。
|
||||
|
||||
[スケジューラーはどのようにノードを探索するか](#how-the-scheduler-iterates-over-nodes)で処理を詳しく説明しています。
|
||||
|
||||
|
|
|
|||
|
|
@ -191,7 +191,7 @@ Kubernetesはユーザーまたはコントローラーが明示的に指定し
|
|||
自動的に設定されるtolerationは、taintに対応する問題がNodeで検知されても5分間はそのNodeにPodが残されることを意味します。
|
||||
{{< /note >}}
|
||||
|
||||
[DaemonSet](/docs/concepts/workloads/controllers/daemonset/)のPodは次のtaintに対して`NoExecute`のtolerationが`tolerationSeconds`を指定せずに設定されます。
|
||||
[DaemonSet](/ja/docs/concepts/workloads/controllers/daemonset/)のPodは次のtaintに対して`NoExecute`のtolerationが`tolerationSeconds`を指定せずに設定されます。
|
||||
|
||||
* `node.kubernetes.io/unreachable`
|
||||
* `node.kubernetes.io/not-ready`
|
||||
|
|
|
|||
|
|
@ -281,7 +281,7 @@ Gatekeeper](https://github.com/open-policy-agent/gatekeeper)があります。
|
|||
### WindowsのPodにはどのプロファイルを適用すればよいですか?
|
||||
|
||||
Kubernetesでは、Linuxベースのワークロードと比べてWindowsの使用は制限や差異があります。
|
||||
特に、PodのSecurityContextフィールドは[Windows環境では効果がありません](/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#v1-podsecuritycontext)。
|
||||
特に、PodのSecurityContextフィールドは[Windows環境では効果がありません](/ja/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#v1-podsecuritycontext)。
|
||||
したがって、現段階では標準化されたセキュリティポリシーは存在しません。
|
||||
|
||||
### サンドボックス化されたPodはどのように扱えばよいでしょうか?
|
||||
|
|
|
|||
|
|
@ -62,7 +62,7 @@ kubectl get pods -l run=my-nginx -o yaml | grep podIP
|
|||
つまり、同じcontainerPortを使用して同じノードで複数のnginx Podを実行し、IPを使用してクラスター内の他のPodやノードからそれらにアクセスできます。
|
||||
Dockerと同様に、ポートは引き続きホストノードのインターフェイスに公開できますが、ネットワークモデルにより、この必要性は根本的に減少します。
|
||||
|
||||
興味があれば、これを[どのように達成するか](/docs/concepts/cluster-administration/networking/#how-to-achieve-this)について詳しく読むことができます。
|
||||
興味があれば、これを[どのように達成するか](/ja/docs/concepts/cluster-administration/networking/#how-to-achieve-this)について詳しく読むことができます。
|
||||
|
||||
## Serviceを作成する
|
||||
|
||||
|
|
@ -203,7 +203,7 @@ NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
|||
kube-dns ClusterIP 10.0.0.10 <none> 53/UDP,53/TCP 8m
|
||||
```
|
||||
|
||||
このセクションの残りの部分は、寿命の長いIP(my-nginx)を持つServiceと、そのIPに名前を割り当てたDNSサーバーがあることを前提にしています。ここではCoreDNSクラスターアドオン(アプリケーション名: `kube-dns`)を使用しているため、標準的なメソッド(`gethostbyname()`など) を使用してクラスター内の任意のPodからServiceに通信できます。CoreDNSが起動していない場合、[CoreDNS README](https://github.com/coredns/deployment/tree/master/kubernetes)または[Installing CoreDNS](/docs/tasks/administer-cluster/coredns/#installing-coredns)を参照し、有効にする事ができます。curlアプリケーションを実行して、これをテストしてみましょう。
|
||||
このセクションの残りの部分は、寿命の長いIP(my-nginx)を持つServiceと、そのIPに名前を割り当てたDNSサーバーがあることを前提にしています。ここではCoreDNSクラスターアドオン(アプリケーション名: `kube-dns`)を使用しているため、標準的なメソッド(`gethostbyname()`など) を使用してクラスター内の任意のPodからServiceに通信できます。CoreDNSが起動していない場合、[CoreDNS README](https://github.com/coredns/deployment/tree/master/kubernetes)または[Installing CoreDNS](/ja/docs/tasks/administer-cluster/coredns/#installing-coredns)を参照し、有効にする事ができます。curlアプリケーションを実行して、これをテストしてみましょう。
|
||||
|
||||
```shell
|
||||
kubectl run curl --image=radial/busyboxplus:curl -i --tty
|
||||
|
|
@ -232,7 +232,7 @@ Address 1: 10.0.162.149
|
|||
|
||||
* https用の自己署名証明書(既にID証明書を持っている場合を除く)
|
||||
* 証明書を使用するように構成されたnginxサーバー
|
||||
* Podが証明書にアクセスできるようにする[Secret](/docs/concepts/configuration/secret/)
|
||||
* Podが証明書にアクセスできるようにする[Secret](/ja/docs/concepts/configuration/secret/)
|
||||
|
||||
これらはすべて[nginx httpsの例](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/https-nginx/)から取得できます。
|
||||
これにはツールをインストールする必要があります。
|
||||
|
|
|
|||
|
|
@ -98,4 +98,4 @@ IPv6が有効になった外部ロードバランサーをサポートしてい
|
|||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* [IPv4/IPv6デュアルスタックのネットワークを検証する](/docs/tasks/network/validate-dual-stack)
|
||||
* [IPv4/IPv6デュアルスタックのネットワークを検証する](/ja/docs/tasks/network/validate-dual-stack)
|
||||
|
|
|
|||
|
|
@ -127,6 +127,6 @@ EndpointSliceを使用する実装では、エンドポイントを複数のス
|
|||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* [EndpointSliceの有効化](/docs/tasks/administer-cluster/enabling-endpointslices)について学ぶ
|
||||
* [EndpointSliceの有効化](/ja/docs/tasks/administer-cluster/enabling-endpointslices)について学ぶ
|
||||
* [サービスとアプリケーションの接続](/ja/docs/concepts/services-networking/connect-applications-service/)を読む
|
||||
|
||||
|
|
|
|||
|
|
@ -139,6 +139,6 @@ spec:
|
|||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* [Serviceトポトジーを有効にする](/docs/tasks/administer-cluster/enabling-service-topology)を読む。
|
||||
* [Serviceトポトジーを有効にする](/ja/docs/tasks/administer-cluster/enabling-service-topology)を読む。
|
||||
* [サービスとアプリケーションの接続](/ja/docs/concepts/services-networking/connect-applications-service/)を読む。
|
||||
|
||||
|
|
|
|||
|
|
@ -38,7 +38,7 @@ CronJobは、クラスターがアイドル状態になりそうなときにJob
|
|||
|
||||
{{< codenew file="application/job/cronjob.yaml" >}}
|
||||
|
||||
([Running Automated Tasks with a CronJob](/docs/tasks/job/automated-tasks-with-cron-jobs/)ではこの例をより詳しく説明しています。).
|
||||
([Running Automated Tasks with a CronJob](/ja/docs/tasks/job/automated-tasks-with-cron-jobs/)ではこの例をより詳しく説明しています。).
|
||||
|
||||
## CronJobの制限 {#cron-job-limitations}
|
||||
|
||||
|
|
|
|||
|
|
@ -105,7 +105,7 @@ nodeAffinity:
|
|||
|
||||
### TaintsとTolerations
|
||||
|
||||
DaemonSetのPodは[TaintsとTolerations](/docs/concepts/scheduling-eviction/taint-and-toleration/)の設定を尊重します。下記のTolerationsは、関連する機能によって自動的にDaemonSetのPodに追加されます。
|
||||
DaemonSetのPodは[TaintsとTolerations](/ja/docs/concepts/scheduling-eviction/taint-and-toleration/)の設定を尊重します。下記のTolerationsは、関連する機能によって自動的にDaemonSetのPodに追加されます。
|
||||
|
||||
| Toleration Key | Effect | Version | Description |
|
||||
| ---------------------------------------- | ---------- | ------- | ----------- |
|
||||
|
|
@ -151,7 +151,7 @@ Node上で直接起動することにより(例: `init`、`upstartd`、`systemd`
|
|||
|
||||
### 静的Pod Pods
|
||||
|
||||
Kubeletによって監視されているディレクトリに対してファイルを書き込むことによって、Podを作成することが可能です。これは[静的Pod](/docs/tasks/configure-pod-container/static-pod/)と呼ばれます。DaemonSetと違い、静的Podはkubectlや他のKubernetes APIクライアントで管理できません。静的PodはApiServerに依存しておらず、クラスターの自立起動時に最適です。また、静的Podは将来的には廃止される予定です。
|
||||
Kubeletによって監視されているディレクトリに対してファイルを書き込むことによって、Podを作成することが可能です。これは[静的Pod](/ja/docs/tasks/configure-pod-container/static-pod/)と呼ばれます。DaemonSetと違い、静的Podはkubectlや他のKubernetes APIクライアントで管理できません。静的PodはApiServerに依存しておらず、クラスターの自立起動時に最適です。また、静的Podは将来的には廃止される予定です。
|
||||
|
||||
### Deployment
|
||||
|
||||
|
|
|
|||
|
|
@ -562,7 +562,7 @@ kubectl scale deployment.v1.apps/nginx-deployment --replicas=10
|
|||
deployment.apps/nginx-deployment scaled
|
||||
```
|
||||
|
||||
クラスター内で[水平Podオートスケーラー](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)が有効になっていると仮定します。ここでDeploymentのオートスケーラーを設定し、稼働しているPodのCPU使用量に基づいて、稼働させたいPodのレプリカ数の最小値と最大値を設定できます。
|
||||
クラスター内で[水平Podオートスケーラー](/ja/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)が有効になっていると仮定します。ここでDeploymentのオートスケーラーを設定し、稼働しているPodのCPU使用量に基づいて、稼働させたいPodのレプリカ数の最小値と最大値を設定できます。
|
||||
|
||||
```shell
|
||||
kubectl autoscale deployment.v1.apps/nginx-deployment --min=10 --max=15 --cpu-percent=80
|
||||
|
|
|
|||
|
|
@ -94,7 +94,7 @@ spec:
|
|||
|
||||
* nginxという名前のHeadlessServiceは、ネットワークドメインをコントロールするために使われます。
|
||||
* webという名前のStatefulSetは、specで3つのnginxコンテナのレプリカを持ち、そのコンテナはそれぞれ別のPodで稼働するように設定されています。
|
||||
* volumeClaimTemplatesは、PersistentVolumeプロビジョナーによってプロビジョンされた[PersistentVolume](/docs/concepts/storage/persistent-volumes/)を使って安定したストレージを提供します。
|
||||
* volumeClaimTemplatesは、PersistentVolumeプロビジョナーによってプロビジョンされた[PersistentVolume](/ja/docs/concepts/storage/persistent-volumes/)を使って安定したストレージを提供します。
|
||||
|
||||
StatefulSetの名前は有効な[名前](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。
|
||||
|
||||
|
|
@ -159,7 +159,7 @@ StatefulSet {{< glossary_tooltip text="コントローラー" term_id="controlle
|
|||
|
||||
StatefulSetは`pod.Spec.TerminationGracePeriodSeconds`を0に指定すべきではありません。これは不安全で、やらないことを強く推奨します。さらなる説明としては、[StatefulSetのPodの強制削除](/ja/docs/tasks/run-application/force-delete-stateful-set-pod/)を参照してください。
|
||||
|
||||
上記の例のnginxが作成されたとき、3つのPodは`web-0`、`web-1`、`web-2`の順番でデプロイされます。`web-1`は`web-0`が[RunningかつReady状態](/docs/concepts/workloads/pods/pod-lifecycle/)になるまでは決してデプロイされないのと、同様に`web-2`は`web-1`がRunningかつReady状態にならないとデプロイされません。もし`web-0`が`web-1`がRunningかつReady状態になった後だが、`web-2`が起動する前に失敗した場合、`web-2`は`web-0`の再起動が成功し、RunningかつReady状態にならないと再起動されません。
|
||||
上記の例のnginxが作成されたとき、3つのPodは`web-0`、`web-1`、`web-2`の順番でデプロイされます。`web-1`は`web-0`が[RunningかつReady状態](/ja/docs/concepts/workloads/pods/pod-lifecycle/)になるまでは決してデプロイされないのと、同様に`web-2`は`web-1`がRunningかつReady状態にならないとデプロイされません。もし`web-0`が`web-1`がRunningかつReady状態になった後だが、`web-2`が起動する前に失敗した場合、`web-2`は`web-0`の再起動が成功し、RunningかつReady状態にならないと再起動されません。
|
||||
|
||||
もしユーザーが`replicas=1`といったようにStatefulSetにパッチをあてることにより、デプロイされたものをスケールすることになった場合、`web-2`は最初に停止されます。`web-1`は`web-2`が完全にシャットダウンされ削除されるまでは、停止されません。もし`web-0`が、`web-2`が完全に停止され削除された後だが、`web-1`の停止の前に失敗した場合、`web-1`は`web-0`がRunningかつReady状態になるまでは停止されません。
|
||||
|
||||
|
|
@ -205,6 +205,6 @@ Kubernetes1.7とそれ以降のバージョンにおいて、StatefulSetの`.spe
|
|||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* [ステートフルなアプリケーションのデプロイ](/docs/tutorials/stateful-application/basic-stateful-set/)の例を参考にしてください。
|
||||
* [StatefulSetを使ったCassandraのデプロイ](/docs/tutorials/stateful-application/cassandra/)の例を参考にしてください。
|
||||
* [ステートフルなアプリケーションのデプロイ](/ja/docs/tutorials/stateful-application/basic-stateful-set/)の例を参考にしてください。
|
||||
* [StatefulSetを使ったCassandraのデプロイ](/ja/docs/tutorials/stateful-application/cassandra/)の例を参考にしてください。
|
||||
* [レプリカを持つステートフルアプリケーションを実行する](/ja/docs/tasks/run-application/run-replicated-stateful-application/)の例を参考にしてください。
|
||||
|
|
|
|||
|
|
@ -89,7 +89,7 @@ PodにはPodStatusがあります。それはPodが成功したかどうかの
|
|||
|
||||
* `PodScheduled`: PodがNodeにスケジュールされました。
|
||||
* `ContainersReady`: Pod内のすべてのコンテナが準備できた状態です。
|
||||
* `Initialized`: すべての[Initコンテナ](/docs/concepts/workloads/pods/init-containers)が正常に実行されました。
|
||||
* `Initialized`: すべての[Initコンテナ](/ja/docs/concepts/workloads/pods/init-containers)が正常に実行されました。
|
||||
* `Ready`: Podはリクエストを処理でき、一致するすべてのサービスの負荷分散プールに追加されます。
|
||||
|
||||
フィールド名 | 内容
|
||||
|
|
|
|||
|
|
@ -39,17 +39,17 @@ Kubernetesコミュニティで効果的に働くためには、[git](https://gi
|
|||
|
||||
1. CNCFの[Contributor License Agreement](https://github.com/kubernetes/community/blob/master/CLA.md)にサインしてください。
|
||||
2. [ドキュメンテーションのリポジトリー](https://github.com/kubernetes/website)と、ウェブサイトの[静的サイトジェネレーター](https://gohugo.io)に慣れ親しんでください。
|
||||
3. [プルリクエストのオープン](/docs/contribute/new-content/open-a-pr/)と[変更レビュー](/docs/contribute/review/reviewing-prs/)の基本的なプロセスを理解していることを確認してください。
|
||||
3. [プルリクエストのオープン](/docs/contribute/new-content/open-a-pr/)と[変更レビュー](/ja/docs/contribute/review/reviewing-prs/)の基本的なプロセスを理解していることを確認してください。
|
||||
|
||||
一部のタスクでは、Kubernetes organizationで、より多くの信頼とアクセス権限が必要です。
|
||||
役割と権限についての詳細は、[SIG Docsへの参加](/docs/contribute/participating/)を参照してください。
|
||||
|
||||
## はじめての貢献
|
||||
- 貢献のための複数の方法について学ぶために[貢献の概要](/docs/contribute/new-content/overview/)を読んでください。
|
||||
- 貢献のための複数の方法について学ぶために[貢献の概要](/ja/docs/contribute/new-content/overview/)を読んでください。
|
||||
- 良い開始地点を探すために[`kubernetes/website` issueリスト](https://github.com/kubernetes/website/issues/)を確認してください。
|
||||
- 既存のドキュメントに対して[GitHubを使ってプルリクエストをオープン](/docs/contribute/new-content/open-a-pr/#changes-using-github)し、GitHubへのissueの登録について学んでください。
|
||||
- 正確さと言語の校正のため、他のKubernetesコミュニティメンバーから[プルリクエストのレビュー](/docs/contribute/review/reviewing-prs/)を受けてください。
|
||||
- 見識のあるコメントを残せるようにするため、Kubernetesの[コンテンツ](/docs/contribute/style/content-guide/)と[スタイルガイド](/docs/contribute/style/style-guide/)を読んでください。
|
||||
- 見識のあるコメントを残せるようにするため、Kubernetesの[コンテンツ](/ja/docs/contribute/style/content-guide/)と[スタイルガイド](/docs/contribute/style/style-guide/)を読んでください。
|
||||
- [ページコンテンツの種類](/docs/contribute/style/page-content-types/)と[Hugoショートコード](/docs/contribute/style/hugo-shortcodes/)について勉強してください。
|
||||
|
||||
## 次のステップ
|
||||
|
|
@ -57,7 +57,7 @@ Kubernetesコミュニティで効果的に働くためには、[git](https://gi
|
|||
- リポジトリの[ローカルクローンでの作業](/docs/contribute/new-content/open-a-pr/#fork-the-repo)について学んでください。
|
||||
- [リリース機能](/docs/contribute/new-content/new-features/)について記載してください。
|
||||
- [SIG Docs](/docs/contribute/participate/)に参加し、[memberやreviewer](/docs/contribute/participate/roles-and-responsibilities/)になってください。
|
||||
- [国際化](/docs/contribute/localization/)を始めたり、支援したりしてください。
|
||||
- [国際化](/ja/docs/contribute/localization/)を始めたり、支援したりしてください。
|
||||
|
||||
## SIG Docsに参加する
|
||||
|
||||
|
|
|
|||
|
|
@ -330,7 +330,7 @@ GAになってからさらなる変更を加えることは現実的ではない
|
|||
- `APIListChunking`: APIクライアントがAPIサーバーからチャンク単位で（`LIST`や`GET`の）リソースを取得できるようにします。
|
||||
`APIPriorityAndFairness`: 各サーバーで優先順位付けと公平性を備えた要求の並行性を管理できるようにします(`RequestManagement`から名前が変更されました)。
|
||||
- `APIResponseCompression`:`LIST`や`GET`リクエストのAPIレスポンスを圧縮します。
|
||||
- `AppArmor`: Dockerを使用する場合にLinuxノードでAppArmorによる強制アクセスコントロールを有効にします。詳細は[AppArmorチュートリアル](/docs/tutorials/clusters/apparmor/)で確認できます。
|
||||
- `AppArmor`: Dockerを使用する場合にLinuxノードでAppArmorによる強制アクセスコントロールを有効にします。詳細は[AppArmorチュートリアル](/ja/docs/tutorials/clusters/apparmor/)で確認できます。
|
||||
- `AttachVolumeLimit`: ボリュームプラグインを有効にすることでノードにアタッチできるボリューム数の制限を設定できます。
|
||||
- `BalanceAttachedNodeVolumes`: スケジューリング中にバランスのとれたリソース割り当てを考慮するノードのボリュームカウントを含めます。判断を行う際に、CPU、メモリー使用率、およびボリュームカウントが近いノードがスケジューラーによって優先されます。
|
||||
- `BlockVolume`: PodでRawブロックデバイスの定義と使用を有効にします。詳細は[Rawブロックボリュームのサポート](/docs/concepts/storage/persistent-volumes/#raw-block-volume-support)で確認できます。
|
||||
|
|
@ -379,7 +379,7 @@ GAになってからさらなる変更を加えることは現実的ではない
|
|||
- `EndpointSlice`: よりスケーラブルで拡張可能なネットワークエンドポイントのエンドポイントスライスを有効にします。[Enabling Endpoint Slices](/docs/tasks/administer-cluster/enabling-endpointslices/)をご覧ください。
|
||||
- `EndpointSliceProxying`: このフィーチャーゲートを有効にすると、kube-proxyはエンドポイントの代わりにエンドポイントスライスをプライマリデータソースとして使用し、スケーラビリティとパフォーマンスの向上を実現します。[Enabling Endpoint Slices](/docs/tasks/administer-cluster/enabling-endpointslices/).をご覧ください。
|
||||
- `GCERegionalPersistentDisk`: GCEでリージョナルPD機能を有効にします。
|
||||
- `HugePages`: 事前に割り当てられた[huge pages](/docs/tasks/manage-hugepages/scheduling-hugepages/)の割り当てと消費を有効にします。
|
||||
- `HugePages`: 事前に割り当てられた[huge pages](/ja/docs/tasks/manage-hugepages/scheduling-hugepages/)の割り当てと消費を有効にします。
|
||||
- `HugePageStorageMediumSize`: 事前に割り当てられた複数のサイズの[huge pages](/docs/tasks/manage-hugepages/scheduling-hugepages/)のサポートを有効にします。
|
||||
- `HyperVContainer`: Windowsコンテナの[Hyper-Vによる分離](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/hyperv-container)を有効にします。
|
||||
- `HPAScaleToZero`: カスタムメトリクスまたは外部メトリクスを使用するときに、`HorizontalPodAutoscaler`リソースの`minReplicas`を0に設定できるようにします。
|
||||
|
|
@ -400,7 +400,7 @@ GAになってからさらなる変更を加えることは現実的ではない
|
|||
- `PodDisruptionBudget`: [PodDisruptionBudget](/docs/tasks/run-application/configure-pdb/)機能を有効にします。
|
||||
- `PodPriority`: [優先度](/docs/concepts/configuration/pod-priority-preemption/)に基づいてPodの再スケジューリングとプリエンプションを有効にします。
|
||||
- `PodReadinessGates`: Podのreadinessの評価を拡張するために`PodReadinessGate`フィールドの設定を有効にします。詳細は[Pod readiness gate](/ja/docs/concepts/workloads/pods/pod-lifecycle/#pod-readiness-gate)で確認できます。
|
||||
- `PodShareProcessNamespace`: Podで実行されているコンテナ間で単一のプロセス名前空間を共有するには、Podで`shareProcessNamespace`の設定を有効にします。詳細については、[Pod内のコンテナ間でプロセス名前空間を共有する](/docs/tasks/configure-pod-container/share-process-namespace/)をご覧ください。
|
||||
- `PodShareProcessNamespace`: Podで実行されているコンテナ間で単一のプロセス名前空間を共有するには、Podで`shareProcessNamespace`の設定を有効にします。詳細については、[Pod内のコンテナ間でプロセス名前空間を共有する](/ja/docs/tasks/configure-pod-container/share-process-namespace/)をご覧ください。
|
||||
- `ProcMountType`: コンテナのProcMountTypeの制御を有効にします。
|
||||
- `PVCProtection`: 永続ボリューム要求（PVC）がPodでまだ使用されているときに削除されないようにします。詳細は[ここ](/docs/tasks/administer-cluster/storage-object-in-use-protection/)で確認できます。
|
||||
- `QOSReserved`: QoSレベルでのリソース予約を許可して、低いQoSレベルのポッドが高いQoSレベルで要求されたリソースにバーストするのを防ぎます（現時点ではメモリのみ）。
|
||||
|
|
@ -409,7 +409,7 @@ GAになってからさらなる変更を加えることは現実的ではない
|
|||
- `RotateKubeletClientCertificate`: kubeletでクライアントTLS証明書のローテーションを有効にします。詳細は[kubeletの設定](/docs/tasks/administer-cluster/storage-object-in-use-protection/)で確認できます。
|
||||
- `RotateKubeletServerCertificate`: kubeletでサーバーTLS証明書のローテーションを有効にします。詳細は[kubeletの設定](/docs/tasks/administer-cluster/storage-object-in-use-protection/)で確認できます。
|
||||
- `RunAsGroup`: コンテナの初期化プロセスで設定されたプライマリグループIDの制御を有効にします。
|
||||
- `RuntimeClass`: コンテナのランタイム構成を選択するには[RuntimeClass](/docs/concepts/containers/runtime-class/)機能を有効にします。
|
||||
- `RuntimeClass`: コンテナのランタイム構成を選択するには[RuntimeClass](/ja/docs/concepts/containers/runtime-class/)機能を有効にします。
|
||||
- `ScheduleDaemonSetPods`: DaemonSetのPodをDaemonSetコントローラーではなく、デフォルトのスケジューラーによってスケジュールされるようにします。
|
||||
- `SCTPSupport`: `Service`、`Endpoints`、`NetworkPolicy`、`Pod`の定義で`protocol`の値としてSCTPを使用できるようにします
|
||||
- `ServerSideApply`: APIサーバーで[サーバーサイドApply(SSA)](/docs/reference/using-api/api-concepts/#server-side-apply)のパスを有効にします。
|
||||
|
|
@ -429,7 +429,7 @@ GAになってからさらなる変更を加えることは現実的ではない
|
|||
- `TaintNodesByCondition`: [ノードの条件](/ja/docs/concepts/architecture/nodes/#condition)に基づいてノードの自動Taintを有効にします。
|
||||
- `TokenRequest`: サービスアカウントリソースで`TokenRequest`エンドポイントを有効にします。
|
||||
- `TokenRequestProjection`: [Projectedボリューム](/docs/concepts/storage/volumes/#projected)を使用したPodへのサービスアカウントのトークンの注入を有効にします。
|
||||
- `TTLAfterFinished`: [TTLコントローラー](/docs/concepts/workloads/controllers/ttlafterfinished/)が実行終了後にリソースをクリーンアップできるようにします。
|
||||
- `TTLAfterFinished`: [TTLコントローラー](/ja/docs/concepts/workloads/controllers/ttlafterfinished/)が実行終了後にリソースをクリーンアップできるようにします。
|
||||
- `VolumePVCDataSource`: 既存のPVCをデータソースとして指定するサポートを有効にします。
|
||||
- `VolumeScheduling`: ボリュームトポロジー対応のスケジューリングを有効にし、PersistentVolumeClaim（PVC）バインディングにスケジューリングの決定を認識させます。また`PersistentLocalVolumes`フィーチャーゲートと一緒に使用すると[`local`](/docs/concepts/storage/volumes/#local)ボリュームタイプの使用が可能になります。
|
||||
- `VolumeSnapshotDataSource`: ボリュームスナップショットのデータソースサポートを有効にします。
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
title: コンテナ
|
||||
id: container
|
||||
date: 2018-04-12
|
||||
full_link: /docs/concepts/overview/what-is-kubernetes/#why-containers
|
||||
full_link: /ja/docs/concepts/overview/what-is-kubernetes/#why-containers
|
||||
short_description: >
|
||||
軽量でポータブルなソフトウェアとそのすべての依存関係が含まれている実行可能なイメージです。
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
title: Controller
|
||||
id: controller
|
||||
date: 2018-04-12
|
||||
full_link: /docs/concepts/architecture/controller/
|
||||
full_link: /ja/docs/concepts/architecture/controller/
|
||||
short_description: >
|
||||
クラスターの状態をAPIサーバーから取得、見張る制御ループで、現在の状態を望ましい状態に移行するように更新します。
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
title: APIサーバー
|
||||
id: kube-apiserver
|
||||
date: 2018-04-12
|
||||
full_link: /docs/concepts/overview/components/#kube-apiserver
|
||||
full_link: /ja/docs/concepts/overview/components/#kube-apiserver
|
||||
short_description: >
|
||||
Kubernetes APIを提供するコントロールプレーンのコンポーネントです。
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
title: Namespace
|
||||
id: namespace
|
||||
date: 2018-04-12
|
||||
full_link: /docs/concepts/overview/working-with-objects/namespaces
|
||||
full_link: /ja/docs/concepts/overview/working-with-objects/namespaces
|
||||
short_description: >
|
||||
同一の物理クラスター上で複数の仮想クラスターをサポートするために使われる抽象概念です。
|
||||
|
||||
|
|
|
|||
|
|
@ -347,7 +347,7 @@ kubectl api-resources --api-group=extensions # "extensions" APIグループの
|
|||
`-o=custom-columns=<spec>` | コンマ区切りされたカスタムカラムのリストを指定してテーブルを表示します
|
||||
`-o=custom-columns-file=<filename>` | `<filename>`ファイル内のカスタムカラムテンプレートを使用してテーブルを表示します
|
||||
`-o=json` | JSON形式のAPIオブジェクトを出力します
|
||||
`-o=jsonpath=<template>` | [jsonpath](/docs/reference/kubectl/jsonpath)式で定義されたフィールドを出力します
|
||||
`-o=jsonpath=<template>` | [jsonpath](/ja/docs/reference/kubectl/jsonpath)式で定義されたフィールドを出力します
|
||||
`-o=jsonpath-file=<filename>` | `<filename>`ファイル内の[jsonpath](/docs/reference/kubectl/jsonpath)式で定義されたフィールドを出力します
|
||||
`-o=name` | リソース名のみを出力し、それ以外は何も出力しません。
|
||||
`-o=wide` | 追加の情報を含むプレーンテキスト形式で出力します。Podの場合、Node名が含まれます。
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ card:
|
|||
---
|
||||
|
||||
<!-- overview -->
|
||||
`kubectl`コマンドラインツールを使うと、Kubernetesクラスターを制御できます。環境設定のために、`kubectl`は、`$HOME/.kube`ディレクトリにある`config`という名前のファイルを探します。他の[kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)ファイルは、`KUBECONFIG`環境変数を設定するか、[`--kubeconfig`](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)フラグを設定することで指定できます。
|
||||
`kubectl`コマンドラインツールを使うと、Kubernetesクラスターを制御できます。環境設定のために、`kubectl`は、`$HOME/.kube`ディレクトリにある`config`という名前のファイルを探します。他の[kubeconfig](/ja/docs/concepts/configuration/organize-cluster-access-kubeconfig/)ファイルは、`KUBECONFIG`環境変数を設定するか、[`--kubeconfig`](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)フラグを設定することで指定できます。
|
||||
この概要では、`kubectl`の構文を扱い、コマンド操作を説明し、一般的な例を示します。サポートされているすべてのフラグやサブコマンドを含め、各コマンドの詳細については、[kubectl](/docs/reference/generated/kubectl/kubectl-commands/)リファレンスドキュメントを参照してください。インストール方法については、[kubectlのインストールおよびセットアップ](/ja/docs/tasks/tools/install-kubectl/)をご覧ください。
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ Kubernetesには、Kubernetesシステムの操作に役立ついくつかの組
|
|||
|
||||
<!-- body -->
|
||||
## Kubectl
|
||||
[`kubectl`](/docs/tasks/tools/install-kubectl/)は、Kubernetesのためのコマンドラインツールです。このコマンドはKubernetes cluster managerを操作します。
|
||||
[`kubectl`](/ja/docs/tasks/tools/install-kubectl/)は、Kubernetesのためのコマンドラインツールです。このコマンドはKubernetes cluster managerを操作します。
|
||||
|
||||
## Kubeadm
|
||||
[`kubeadm`](docs/setup/production-environment/tools/kubeadm/install-kubeadm/)は、物理サーバやクラウドサーバ、仮想マシン上にKubernetesクラスタを容易にプロビジョニングするためのコマンドラインツールです(現在はアルファ版です)。
|
||||
|
|
@ -17,7 +17,7 @@ Kubernetesには、Kubernetesシステムの操作に役立ついくつかの組
|
|||
[`minikube`](https://minikube.sigs.k8s.io/docs/)は、開発やテストのためにワークステーション上でシングルノードのKubernetesクラスタをローカルで実行するツールです。
|
||||
|
||||
## Dashboard
|
||||
[`Dashboard`](/docs/tasks/access-application-cluster/web-ui-dashboard/)は、KubernetesのWebベースのユーザインタフェースで、コンテナ化されたアプリケーションをKubernetesクラスタにデプロイしたり、トラブルシューティングしたり、クラスタとそのリソース自体を管理したりすることが出来ます。
|
||||
[`Dashboard`](/ja/docs/tasks/access-application-cluster/web-ui-dashboard/)は、KubernetesのWebベースのユーザインタフェースで、コンテナ化されたアプリケーションをKubernetesクラスタにデプロイしたり、トラブルシューティングしたり、クラスタとそのリソース自体を管理したりすることが出来ます。
|
||||
|
||||
## Helm
|
||||
[`Kubernetes Helm`](https://github.com/helm/helm)は、事前に設定されたKubernetesリソースのパッケージ、別名Kubernetes chartsを管理するためのツールです。
|
||||
|
|
|
|||
|
|
@ -220,7 +220,7 @@ for production clusters!
|
|||
|
||||
### 他のアドオンの参照
|
||||
|
||||
See the [list of add-ons](/docs/concepts/cluster-administration/addons/) to explore other add-ons, including tools for logging, monitoring, network policy, visualization, and control of your Kubernetes cluster.
|
||||
See the [list of add-ons](/ja/docs/concepts/cluster-administration/addons/) to explore other add-ons, including tools for logging, monitoring, network policy, visualization, and control of your Kubernetes cluster.
|
||||
|
||||
## クリーンアップ
|
||||
|
||||
|
|
|
|||
|
|
@ -162,7 +162,7 @@ To start using your cluster, you need to run the following as a regular user:
|
|||
|
||||
You should now deploy a Pod network to the cluster.
|
||||
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
|
||||
/docs/concepts/cluster-administration/addons/
|
||||
/ja/docs/concepts/cluster-administration/addons/
|
||||
|
||||
You can now join any number of machines by running the following on each node
|
||||
as root:
|
||||
|
|
@ -395,8 +395,8 @@ kubectl delete node <node name>
|
|||
* <a id="lifecycle" />`kubeadm`を使用したクラスターをアップグレードする方法について、[kubeadmクラスターをアップグレードする](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)を読む。
|
||||
* `kubeadm`の高度な利用方法について[kubeadmリファレンスドキュメント](/docs/reference/setup-tools/kubeadm/kubeadm)で学ぶ。
|
||||
* Kubernetesの[コンセプト](/ja/docs/concepts/)や[`kubectl`](/ja/docs/reference/kubectl/overview/)についてもっと学ぶ。
|
||||
* Podネットワークアドオンのより完全なリストを[クラスターのネットワーク](/docs/concepts/cluster-administration/networking/)で確認する。
|
||||
* <a id="other-addons" />ロギング、モニタリング、ネットワークポリシー、仮想化、Kubernetesクラスターの制御のためのツールなど、その他のアドオンについて、[アドオンのリスト](/docs/concepts/cluster-administration/addons/)で確認する。
|
||||
* Podネットワークアドオンのより完全なリストを[クラスターのネットワーク](/ja/docs/concepts/cluster-administration/networking/)で確認する。
|
||||
* <a id="other-addons" />ロギング、モニタリング、ネットワークポリシー、仮想化、Kubernetesクラスターの制御のためのツールなど、その他のアドオンについて、[アドオンのリスト](/ja/docs/concepts/cluster-administration/addons/)で確認する。
|
||||
* クラスターイベントやPod内で実行中のアプリケーションから送られるログをクラスターがハンドリングする方法を設定する。関係する要素の概要を理解するために、[ロギングのアーキテクチャ](/docs/concepts/cluster-administration/logging/)を読んでください。
|
||||
|
||||
### フィードバック {#feedback}
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@ when using kubeadm to set up a kubernetes cluster.
|
|||
* Three hosts that can talk to each other over ports 2379 and 2380. This
|
||||
document assumes these default ports. However, they are configurable through
|
||||
the kubeadm config file.
|
||||
* Each host must [have docker, kubelet, and kubeadm installed](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/).
|
||||
* Each host must [have docker, kubelet, and kubeadm installed](/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm/).
|
||||
* Each host should have access to the Kubernetes container image registry (`k8s.gcr.io`) or list/pull the required etcd image using `kubeadm config images list/pull`. This guide will setup etcd instances as [static pods](/docs/tasks/configure-pod-container/static-pod/) managed by a kubelet.
|
||||
* Some infrastructure to copy files between hosts. For example `ssh` and `scp`
|
||||
can satisfy this requirement.
|
||||
|
|
|
|||
|
|
@ -147,7 +147,7 @@ Calico、Canal、FlannelのCNIプロバイダは、HostPortをサポートして
|
|||
|
||||
## サービスIP経由でPodにアクセスすることができない
|
||||
|
||||
- 多くのネットワークアドオンは、PodがサービスIPを介して自分自身にアクセスできるようにする[ヘアピンモード](/docs/tasks/debug-application-cluster/debug-service/#a-pod-cannot-reach-itself-via-service-ip)を有効にしていません。これは[CNI](https://github.com/containernetworking/cni/issues/476)に関連する問題です。ヘアピンモードのサポート状況については、ネットワークアドオンプロバイダにお問い合わせください。
|
||||
- 多くのネットワークアドオンは、PodがサービスIPを介して自分自身にアクセスできるようにする[ヘアピンモード](/ja/docs/tasks/debug-application-cluster/debug-service/#a-pod-cannot-reach-itself-via-service-ip)を有効にしていません。これは[CNI](https://github.com/containernetworking/cni/issues/476)に関連する問題です。ヘアピンモードのサポート状況については、ネットワークアドオンプロバイダにお問い合わせください。
|
||||
|
||||
- VirtualBoxを使用している場合(直接またはVagrant経由)は、`hostname -i`がルーティング可能なIPアドレスを返すことを確認する必要があります。デフォルトでは、最初のインターフェースはルーティング可能でないホスト専用のネットワークに接続されています。これを回避するには`/etc/hosts`を修正する必要があります。例としてはこの[Vagrantfile](https://github.com/errordeveloper/k8s-playground/blob/22dd39dfc06111235620e6c4404a96ae146f26fd/Vagrantfile#L11)を参照してください。
|
||||
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ Kubespray is a composition of [Ansible](https://docs.ansible.com/) playbooks, [i
|
|||
* continuous integration tests
|
||||
|
||||
To choose a tool which best fits your use case, read [this comparison](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/comparisons.md) to
|
||||
[kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) and [kops](/docs/setup/production-environment/tools/kops/).
|
||||
[kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) and [kops](/ja/docs/setup/production-environment/tools/kops/).
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -241,4 +241,4 @@ spec:
|
|||
app: iis-2019
|
||||
```
|
||||
|
||||
[RuntimeClass]: https://kubernetes.io/docs/concepts/containers/runtime-class/
|
||||
[RuntimeClass]: https://kubernetes.io/ja/docs/concepts/containers/runtime-class/
|
||||
|
|
|
|||
|
|
@ -290,7 +290,7 @@ contexts:
|
|||
name: exp-scratch
|
||||
```
|
||||
|
||||
kubeconfigファイルに関するさらなる情報を参照するには、[kubeconfigファイルを使ってクラスターへのアクセスを管理する](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)を参照してください。
|
||||
kubeconfigファイルに関するさらなる情報を参照するには、[kubeconfigファイルを使ってクラスターへのアクセスを管理する](/ja/docs/concepts/configuration/organize-cluster-access-kubeconfig/)を参照してください。
|
||||
|
||||
## $HOME/.kubeディレクトリの内容を確認する
|
||||
|
||||
|
|
|
|||
|
|
@ -143,7 +143,7 @@ service/frontend created
|
|||
|
||||
{{< note >}}
|
||||
nginxの構成は、[コンテナイメージ](/examples/service/access/Dockerfile)に焼き付けられます。
|
||||
これを行うためのより良い方法は、[ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/)を使用して、構成をより簡単に変更できるようにすることです。
|
||||
これを行うためのより良い方法は、[ConfigMap](/ja/docs/tasks/configure-pod-container/configure-pod-configmap/)を使用して、構成をより簡単に変更できるようにすることです。
|
||||
{{< /note >}}
|
||||
|
||||
## フロントエンドServiceと対話
|
||||
|
|
|
|||
|
|
@ -140,6 +140,6 @@ Hello Worldアプリケーションが稼働しているDeployment、ReplicaSet
|
|||
|
||||
|
||||
詳細は
|
||||
[serviceを利用してアプリケーションと接続する](/docs/concepts/services-networking/connect-applications-service/)
|
||||
[serviceを利用してアプリケーションと接続する](/ja/docs/concepts/services-networking/connect-applications-service/)
|
||||
を確認してください。
|
||||
|
||||
|
|
|
|||
|
|
@ -38,5 +38,5 @@ EndpoitSliceはベータ版の機能です。APIとEndpointSlice{{< glossary_too
|
|||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* [EndpointSlice](/docs/concepts/services-networking/endpoint-slices/)を参照してください。
|
||||
* [EndpointSlice](/ja/docs/concepts/services-networking/endpoint-slices/)を参照してください。
|
||||
* [サービスとアプリケーションの接続](/ja/docs/concepts/services-networking/connect-applications-service/)を参照してください。
|
||||
|
|
|
|||
|
|
@ -85,7 +85,7 @@ Capacity:
|
|||
example.com/dongle: 4
|
||||
```
|
||||
|
||||
これで、アプリケーション開発者は特定の数のdongleをリクエストするPodを作成できるようになりました。詳しくは、[拡張リソースをコンテナに割り当てる](/docs/tasks/configure-pod-container/extended-resource/)を読んでください。
|
||||
これで、アプリケーション開発者は特定の数のdongleをリクエストするPodを作成できるようになりました。詳しくは、[拡張リソースをコンテナに割り当てる](/ja/docs/tasks/configure-pod-container/extended-resource/)を読んでください。
|
||||
|
||||
## 議論
|
||||
|
||||
|
|
|
|||
|
|
@ -178,4 +178,4 @@ flannel Podが実行されると、ノードは`Ready`状態になり、ワー
|
|||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
- [Windows kubeadmノードのアップグレード](/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes)
|
||||
- [Windows kubeadmノードのアップグレード](/ja/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes)
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ weight: 40
|
|||
|
||||
{{< feature-state for_k8s_version="v1.18" state="beta" >}}
|
||||
|
||||
このページでは、[kubeadmで作られた](/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes)Windowsノードをアップグレードする方法について説明します。
|
||||
このページでは、[kubeadmで作られた](/ja/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes)Windowsノードをアップグレードする方法について説明します。
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -255,4 +255,4 @@ kubectl delete namespace constraints-mem-example
|
|||
|
||||
* [コンテナとPodへのCPUリソースの割り当て](/docs/tasks/configure-pod-container/assign-cpu-resource/)
|
||||
|
||||
* [PodのQoS(サービス品質)を設定](/docs/tasks/configure-pod-container/quality-service-pod/)
|
||||
* [PodのQoS(サービス品質)を設定](/ja/docs/tasks/configure-pod-container/quality-service-pod/)
|
||||
|
|
|
|||
|
|
@ -111,5 +111,5 @@ weight: 120
|
|||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
[Node Affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity)についてさらに学ぶ。
|
||||
[Node Affinity](/ja/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity)についてさらに学ぶ。
|
||||
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ kubectl get pods -l app=myapp
|
|||
```
|
||||
|
||||
Podが長期間`Unknown`または`Terminating`の状態になっていることがわかった場合は、それらを処理する方法について[StatefulSetの削除](/ja/docs/tasks/run-application/delete-stateful-set/)タスクを参照してください。
|
||||
[Podのデバッグ](/docs/tasks/debug-application-cluster/debug-pod-replication-controller/)ガイドを使用して、StatefulSet内の個々のPodをデバッグできます。
|
||||
[Podのデバッグ](/ja/docs/tasks/debug-application-cluster/debug-pod-replication-controller/)ガイドを使用して、StatefulSet内の個々のPodをデバッグできます。
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -108,7 +108,7 @@ spec:
|
|||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* [環境変数](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)の詳細
|
||||
* [環境変数](/ja/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)の詳細
|
||||
* [Secretを環境変数として使用する](/docs/concepts/configuration/secret/#using-secrets-as-environment-variables)詳細
|
||||
* [EnvVarSource](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvarsource-v1-core)をご覧ください。
|
||||
|
||||
|
|
|
|||
|
|
@ -111,7 +111,7 @@ Googleは、GKE上でNVIDIAのGPUを使用するための[手順](https://cloud.
|
|||
|
||||
## 異なる種類のGPUを搭載するクラスター
|
||||
|
||||
クラスター上の別のノードに異なる種類のGPUが搭載されている場合、[NodeラベルとNodeセレクター](/docs/tasks/configure-pod-container/assign-pods-nodes/)を使用することで、Podを適切なノードにスケジューリングできます。
|
||||
クラスター上の別のノードに異なる種類のGPUが搭載されている場合、[NodeラベルとNodeセレクター](/ja/docs/tasks/configure-pod-container/assign-pods-nodes/)を使用することで、Podを適切なノードにスケジューリングできます。
|
||||
|
||||
以下に例を示します。
|
||||
|
||||
|
|
|
|||
|
|
@ -74,5 +74,5 @@ StatefulSet Podの強制削除は、常に慎重に、関連するリスクを
|
|||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
[StatefulSetのデバッグ](/docs/tasks/debug-application-cluster/debug-stateful-set/)の詳細
|
||||
[StatefulSetのデバッグ](/ja/docs/tasks/debug-application-cluster/debug-stateful-set/)の詳細
|
||||
|
||||
|
|
|
|||
|
|
@ -24,19 +24,19 @@ content_type: concept
|
|||
|
||||
## 設定
|
||||
|
||||
* [ConfigMapを用いたRedisの設定](/docs/tutorials/configuration/configure-redis-using-configmap/)
|
||||
* [ConfigMapを用いたRedisの設定](/ja/docs/tutorials/configuration/configure-redis-using-configmap/)
|
||||
|
||||
## ステートレスアプリケーション
|
||||
|
||||
* [クラスター内のアプリケーションにアクセスするために外部IPアドレスを公開する](/ja/docs/tutorials/stateless-application/expose-external-ip-address/)
|
||||
|
||||
* [例: Redisを使用したPHPゲストブックアプリケーションのデプロイ](/docs/tutorials/stateless-application/guestbook/)
|
||||
* [例: Redisを使用したPHPゲストブックアプリケーションのデプロイ](/ja/docs/tutorials/stateless-application/guestbook/)
|
||||
|
||||
## ステートフルアプリケーション
|
||||
|
||||
* [StatefulSetの基本](/docs/tutorials/stateful-application/basic-stateful-set/)
|
||||
|
||||
* [例: 永続ボリュームを使ったWordPressとMySQLのデプロイ](/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/)
|
||||
* [例: 永続ボリュームを使ったWordPressとMySQLのデプロイ](/ja/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/)
|
||||
|
||||
* [例: Stateful Setsを使ったCassandraのデプロイ](/docs/tutorials/stateful-application/cassandra/)
|
||||
|
||||
|
|
@ -50,7 +50,7 @@ content_type: concept
|
|||
|
||||
## サービス
|
||||
|
||||
* [Source IPを使う](/docs/tutorials/services/source-ip/)
|
||||
* [Source IPを使う](/ja/docs/tutorials/services/source-ip/)
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -30,7 +30,7 @@ weight: 10
|
|||
|
||||
<p>Kubernetes Podの寿命は永続的ではありません。実際、<a href="/ja/docs/concepts/workloads/pods/pod/">Pod</a>には<a href="/ja/docs/concepts/workloads/pods/pod-lifecycle/">ライフサイクル</a>があります。ワーカーのノードが停止すると、そのノードで実行されているPodも失われます。そうなると、<a href="/ja/docs/concepts/workloads/controllers/replicaset/">ReplicaSet</a>は、新しいPodを作成してアプリケーションを実行し続けるために、クラスターを動的に目的の状態に戻すことができます。別の例として、3つのレプリカを持つ画像処理バックエンドを考えます。それらのレプリカは交換可能です。フロントエンドシステムはバックエンドのレプリカを気にしたり、Podが失われて再作成されたとしても配慮すべきではありません。ただし、Kubernetesクラスター内の各Podは、同じノード上のPodであっても一意のIPアドレスを持っているため、アプリケーションが機能し続けるように、Pod間の変更を自動的に調整する方法が必要です。</p>
|
||||
|
||||
<p>KubernetesのServiceは、Podの論理セットと、それらにアクセスするためのポリシーを定義する抽象概念です。Serviceによって、依存Pod間の疎結合が可能になります。Serviceは、すべてのKubernetesオブジェクトのように、YAML<a href="/docs/concepts/configuration/overview/#general-configuration-tips">(推奨)</a>またはJSONを使って定義されます。Serviceが対象とするPodのセットは通常、<i>LabelSelector</i>によって決定されます(なぜ仕様に<code>セレクタ</code>を含めずにServiceが必要になるのかについては下記を参照してください)。</p>
|
||||
<p>KubernetesのServiceは、Podの論理セットと、それらにアクセスするためのポリシーを定義する抽象概念です。Serviceによって、依存Pod間の疎結合が可能になります。Serviceは、すべてのKubernetesオブジェクトのように、YAML<a href="/ja/docs/concepts/configuration/overview/#general-configuration-tips">(推奨)</a>またはJSONを使って定義されます。Serviceが対象とするPodのセットは通常、<i>LabelSelector</i>によって決定されます(なぜ仕様に<code>セレクタ</code>を含めずにServiceが必要になるのかについては下記を参照してください)。</p>
|
||||
|
||||
<p>各Podには固有のIPアドレスがありますが、それらのIPは、Serviceなしではクラスターの外部に公開されません。Serviceによって、アプリケーションはトラフィックを受信できるようになります。ServiceSpecで<code>type</code>を指定することで、Serviceをさまざまな方法で公開することができます。</p>
|
||||
<ul>
|
||||
|
|
|
|||
Loading…
Reference in New Issue