kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

add ja pages

This commit is contained in:
Karen Bradshaw 2020-05-30 15:47:59 -04:00
parent 74d006a754
commit 283572af58
114 changed files with 900 additions and 793 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

15
content/ja/docs/concepts/_index.md
View File

@ -1,17 +1,17 @@
---
title: コンセプト
main_menu: true
content_template: templates/concept
content_type: concept
weight: 40
---
{{% capture overview %}}
<!-- overview -->
本セクションは、Kubernetesシステムの各パートと、{{< glossary_tooltip text="クラスター" term_id="cluster" length="all" >}}を表現するためにKubernetesが使用する抽象概念について学習し、Kubernetesの仕組みをより深く理解するのに役立ちます。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## 概要
@ -59,12 +59,13 @@ Kubernetesのマスターは、クラスターの望ましい状態を維持す
クラスターのノードは、アプリケーションとクラウドワークフローを実行するマシン(VM、物理サーバーなど)です。Kubernetesのマスターは各ノードを制御します。運用者自身がノードと直接対話することはほとんどありません。
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
コンセプトページを追加したい場合は、
[ページテンプレートの使用](/docs/home/contribute/page-templates/)
のコンセプトページタイプとコンセプトテンプレートに関する情報を確認してください。
{{% /capture %}}

10
content/ja/docs/concepts/architecture/cloud-controller.md
View File

@ -1,10 +1,10 @@
---
title: クラウドコントローラーマネージャーとそのコンセプト
content_template: templates/concept
content_type: concept
weight: 30
---
{{% capture overview %}}
<!-- overview -->
クラウドコントローラマネージャー(CCM)のコンセプト(バイナリと混同しないでください)は、もともとクラウドベンダー固有のソースコードと、Kubernetesのコアソースコードを独立して進化させることが出来るように作られました。クラウドコントローラーマネージャーは、Kubernetesコントローラーマネージャー、APIサーバー、そしてスケジューラーのような他のマスターコンポーネントと並行して動きます。またKubernetesのアドオンとしても動かすことができ、その場合はKubernetes上で動きます。
@ -16,10 +16,10 @@ weight: 30
![Pre CCM Kube Arch](/images/docs/pre-ccm-arch.png)
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## 設計
@ -235,4 +235,4 @@ rules:
CCMを設定、動かすための完全な手順は[こちら](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager)で提供されています。
{{% /capture %}}

10
content/ja/docs/concepts/architecture/master-node-communication.md
View File

@ -1,18 +1,18 @@
---
title: マスターとノード間の通信
content_template: templates/concept
content_type: concept
weight: 20
---
{{% capture overview %}}
<!-- overview -->
本ドキュメントでは、KubernetesにおけるMaster(実態はAPIサーバー)及びクラスター間のコミュニケーション経路についてまとめます。
この文書の目的は、信頼できないネットワーク上（またはクラウドプロバイダ上の完全にパブリックなIP上）でクラスタを実行できるように、ユーザーがインストールをカスタマイズしてネットワーク構成を強化できるようにすることです。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## クラスターからマスターへの通信
@ -69,4 +69,4 @@ Kubernetesはマスターからクラスターへの通信経路を保護する
SSHトンネルは現在非推奨なので、自分がしていることが分からない限り、使用しないでください。この通信チャネルに代わるものが設計されています。
{{% /capture %}}

10
content/ja/docs/concepts/architecture/nodes.md
View File

@ -1,17 +1,17 @@
---
title: ノード
content_template: templates/concept
content_type: concept
weight: 10
---
{{% capture overview %}}
<!-- overview -->
ノードは、以前には `ミニオン` としても知られていた、Kubernetesにおけるワーカーマシンです。1つのノードはクラスターの性質にもよりますが、1つのVMまたは物理的なマシンです。各ノードには[Pod](/ja/docs/concepts/workloads/pods/pod/)を動かすために必要なサービスが含まれており、マスターコンポーネントによって管理されています。ノード上のサービスには[コンテナランタイム](/ja/docs/concepts/overview/components/#container-runtime)、kubelet、kube-proxyが含まれています。詳細については、設計ドキュメントの[Kubernetes Node](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node)セクションをご覧ください。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## ノードのステータス
@ -219,4 +219,4 @@ Pod以外のプロセス用にリソースを明示的に予約したい場合
NodeはKubernetesのREST APIにおけるトップレベルのリソースです。APIオブジェクトに関する詳細は以下の記事にてご覧いただけます:
[Node APIオブジェクト](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core).
{{% /capture %}}

10
content/ja/docs/concepts/cluster-administration/cluster-administration-overview.md
View File

@ -1,15 +1,15 @@
---
reviewers:
title: クラスター管理の概要
content_template: templates/concept
content_type: concept
weight: 10
---
{{% capture overview %}}
<!-- overview -->
このページはKubernetesクラスターの作成や管理者向けの内容です。Kubernetesのコア[コンセプト](/ja/docs/concepts/)についてある程度精通していることを前提とします。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## クラスターのプランニング
Kubernetesクラスターの計画、セットアップ、設定の例を知るには[設定](/ja/docs/setup/)のガイドを参照してください。この記事で列挙されているソリューションは*ディストリビューション* と呼ばれます。
@ -64,6 +64,6 @@ Kubernetesクラスターの計画、セットアップ、設定の例を知る
* [クラスターアクティビィのロギングと監視](/docs/concepts/cluster-administration/logging/)では、Kubernetesにおけるロギングがどのように行われ、どう実装されているかについて解説します。
{{% /capture %}}

10
content/ja/docs/concepts/cluster-administration/controller-metrics.md
View File

@ -1,15 +1,15 @@
---
title: コントローラーマネージャーの指標
content_template: templates/concept
content_type: concept
weight: 100
---
{{% capture overview %}}
<!-- overview -->
コントローラーマネージャーの指標は、コントローラー内部のパフォーマンスについての重要で正確な情報と、クラウドコントローラーの状態についての情報を提供します。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## コントローラーマネージャーの指標とは何か
コントローラーマネージャーの指標は、コントローラー内部のパフォーマンスについての重要で正確な情報と、クラウドコントローラーの状態についての情報を提供します。
@ -39,4 +39,4 @@ cloudprovider_gce_api_request_duration_seconds { request = "list_disk"}
本番環境ではこれらの指標を定期的に収集し、なんらかの時系列データベースで使用できるようにprometheusやその他の指標のスクレイパーを構成することが推奨されます。
{{% /capture %}}

15
content/ja/docs/concepts/cluster-administration/networking.md
View File

@ -1,10 +1,10 @@
---
title: クラスターのネットワーク
content_template: templates/concept
content_type: concept
weight: 50
---
{{% capture overview %}}
<!-- overview -->
ネットワークはKubernetesにおける中心的な部分ですが、どのように動作するかを正確に理解することは難解な場合もあります。
Kubernetesには、4つの異なる対応すべきネットワークの問題があります:
@ -14,10 +14,10 @@ Kubernetesには、4つの異なる対応すべきネットワークの問題が
3. Podからサービスへの通信：これは[Service](/ja/docs/concepts/services-networking/service/)でカバーされています。
4. 外部からサービスへの通信：これは[Service](/ja/docs/concepts/services-networking/service/)でカバーされています。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
Kubernetesは、言ってしまえばアプリケーション間でマシンを共有するためのものです。通常、マシンを共有するには、2つのアプリケーションが同じポートを使用しないようにする必要があります。
複数の開発者間でポートを調整することは、大規模に行うことは非常に難しく、ユーザーが制御できないクラスターレベルの問題に見合うことがあります。
@ -282,10 +282,11 @@ Weave Net runs as a [CNI plug-in](https://www.weave.works/docs/net/latest/cni-pl
or stand-alone. In either version, it doesn't require any configuration or extra code
to run, and in both cases, the network provides one IP address per pod - as is standard for Kubernetes.
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
ネットワークモデルの初期設計とその根拠、および将来の計画については、[ネットワーク設計ドキュメント](https://git.k8s.io/community/contributors/design-proposals/network/networking.md)で詳細に説明されています。
{{% /capture %}}

15
content/ja/docs/concepts/configuration/assign-pod-node.md
View File

@ -1,20 +1,20 @@
---
title: Node上へのPodのスケジューリング
content_template: templates/concept
content_type: concept
weight: 30
---
{{% capture overview %}}
<!-- overview -->
[Pod](/ja/docs/concepts/workloads/pods/pod/)が稼働する[Node](/ja/docs/concepts/architecture/nodes/)を特定のものに指定したり、優先条件を指定して制限することができます。
これを実現するためにはいくつかの方法がありますが、推奨されている方法は[ラベルでの選択](/docs/concepts/overview/working-with-objects/labels/)です。
スケジューラーが最適な配置を選択するため、一般的にはこのような制限は不要です(例えば、複数のPodを別々のNodeへデプロイしたり、Podを配置する際にリソースが不十分なNodeにはデプロイされないことが挙げられます)が、
SSDが搭載されているNodeにPodをデプロイしたり、同じアベイラビリティーゾーン内で通信する異なるサービスのPodを同じNodeにデプロイする等、柔軟な制御が必要なこともあります。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## nodeSelector
@ -357,9 +357,10 @@ spec:
上記のPodはkube-01という名前のNodeで稼働します。
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
[Taints](/docs/concepts/configuration/taint-and-toleration/)を使うことで、NodeはPodを追い出すことができます。
@ -367,4 +368,4 @@ spec:
[Inter-Pod Affinity/Anti-Affinity](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)
には、Taintsの要点に関して様々な背景が紹介されています。
{{% /capture %}}

10
content/ja/docs/concepts/configuration/overview.md
View File

@ -1,16 +1,16 @@
---
title: 設定のベストプラクティス
content_template: templates/concept
content_type: concept
weight: 10
---
{{% capture overview %}}
<!-- overview -->
このドキュメントでは、ユーザーガイド、入門マニュアル、および例を通して紹介されている設定のベストプラクティスを中心に説明します。
このドキュメントは生ものです。このリストには載っていないが他の人に役立つかもしれない何かについて考えている場合、IssueまたはPRを遠慮なく作成してください。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## 一般的な設定のTips
- 構成を定義する際には、最新の安定したAPIバージョンを指定してください。
@ -98,6 +98,6 @@ weight: 10
- `get`や`delete`を行う際は、特定のオブジェクト名を指定するのではなくラベルセレクターを使いましょう。[ラベルセレクター](/docs/concepts/overview/working-with-objects/labels/#label-selectors)と[ラベルの効果的な使い方](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively)のセクションを参照してください。
{{% /capture %}}

15
content/ja/docs/concepts/containers/container-environment-variables.md
View File

@ -1,17 +1,17 @@
---
title: コンテナ環境変数
content_template: templates/concept
content_type: concept
weight: 20
---
{{% capture overview %}}
<!-- overview -->
このページでは、コンテナ環境で利用可能なリソースについて説明します。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## コンテナ環境
@ -45,11 +45,12 @@ FOO_SERVICE_PORT=<サービスが実行されているポート>
サービスは専用のIPアドレスを持ち、[DNSアドオン](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/)が有効の場合、DNSを介してコンテナで利用可能です。
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* [コンテナライフサイクルフック](/docs/concepts/containers/container-lifecycle-hooks/)の詳細
* [コンテナライフサイクルイベントへのハンドラー紐付け](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)のハンズオン
{{% /capture %}}

15
content/ja/docs/concepts/containers/container-lifecycle-hooks.md
View File

@ -1,17 +1,17 @@
---
title: コンテナライフサイクルフック
content_template: templates/concept
content_type: concept
weight: 30
---
{{% capture overview %}}
<!-- overview -->
このページでは、kubeletにより管理されるコンテナがコンテナライフサイクルフックフレームワークを使用して、管理ライフサイクル中にイベントによって引き起こされたコードを実行する方法について説明します。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## 概要
@ -93,12 +93,13 @@ Events:
1m 22s 2 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Warning FailedPostStartHook
```
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* [コンテナ環境](/docs/concepts/containers/container-environment-variables/)の詳細
* [コンテナライフサイクルイベントへのハンドラー紐付け](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)のハンズオン
{{% /capture %}}

10
content/ja/docs/concepts/containers/runtime-class.md
View File

@ -1,11 +1,11 @@
---
reviewers:
title: ランタイムクラス(Runtime Class)
content_template: templates/concept
content_type: concept
weight: 20
---
{{% capture overview %}}
<!-- overview -->
{{< feature-state for_k8s_version="v1.14" state="beta" >}}
@ -15,10 +15,10 @@ weight: 20
RuntimeClassはKubernetes1.14のβ版アップグレードにおいて*破壊的な* 変更を含んでいます。もしユーザーがKubernetes1.14以前のバージョンを使っていた場合、[RuntimeClassのα版からβ版へのアップグレード](#upgrading-runtimeclass-from-alpha-to-beta)を参照してください。
{{< /warning >}}
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## RuntimeClassについて
@ -139,4 +139,4 @@ RuntimeClassのβ版の機能は、下記の変更点を含みます。
```
- `runtimeHandler`の指定がないか、もしくは空文字の場合や、ハンドラー名に`.`文字列が使われている場合はα版のRuntimeClassにおいてもはや有効ではありません。正しい形式のハンドラー設定に変更しなくてはなりません(先ほど記載した内容を確認ください)。
{{% /capture %}}

15
content/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md
View File

@ -1,16 +1,16 @@
---
title: アグリゲーションレイヤーを使ったKubernetes APIの拡張
content_template: templates/concept
content_type: concept
weight: 10
---
{{% capture overview %}}
<!-- overview -->
アグリゲーションレイヤーを使用すると、KubernetesのコアAPIで提供されている機能を超えて、追加のAPIでKubernetesを拡張できます。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## 概要
@ -20,13 +20,14 @@ weight: 10
通常、APIServiceは、クラスター上で動いているPod内の *extension-apiserver* で実装されます。このextension-apiserverは、追加されたリソースに対するアクティブな管理が必要な場合、通常、1つか複数のコントローラーとペアになっている必要があります。そのため、実際にapiserver-builderはextension-apiserverとコントローラーの両方のスケルトンを提供します。一例として、service-catalogがインストールされると、extension-apiserverと提供するサービスのコントローラーの両方を提供します。
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* アグリゲーターをあなたの環境で動かすには、まず[アグリゲーションレイヤーを設定](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/)します
* そして、アグリゲーションレイヤーと一緒に動作させるために[extension api-serverをセットアップ](/docs/tasks/access-kubernetes-api/setup-extension-api-server/)します
* また、[Custom Resource Definitionを使いKubernetes APIを拡張する](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/)方法を学んで下さい
{{% /capture %}}

15
content/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources.md
View File

@ -1,16 +1,16 @@
---
title: カスタムリソース
content_template: templates/concept
content_type: concept
weight: 20
---
{{% capture overview %}}
<!-- overview -->
*カスタムリソース* はKubernetes APIの拡張です。このページでは、いつKubernetesのクラスターにカスタムリソースを追加するべきなのか、そしていつスタンドアローンのサービスを利用するべきなのかを議論します。カスタムリソースを追加する2つの方法と、それらの選択方法について説明します。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## カスタムリソース
@ -213,11 +213,12 @@ Kubernetesの[クライアントライブラリー](/docs/reference/using-api/cl
- 自作のRESTクライアント
- [Kubernetesクライアント生成ツール](https://github.com/kubernetes/code-generator)を使い生成したクライアント(生成は高度な作業ですが、一部のプロジェクトは、CRDまたはAAとともにクライアントを提供する場合があります)
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* [Kubernetes APIをアグリゲーションレイヤーで拡張する方法](/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)について学ぶ
* [Kubernetes APIをCustomResourceDefinitionで拡張する方法](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/)について学ぶ
{{% /capture %}}

15
content/ja/docs/concepts/extend-kubernetes/extend-cluster.md
View File

@ -1,10 +1,10 @@
---
title: Kubernetesクラスターの拡張
content_template: templates/concept
content_type: concept
weight: 10
---
{{% capture overview %}}
<!-- overview -->
Kubernetesは柔軟な設定が可能で、高い拡張性を持っています。
結果として、Kubernetesのプロジェクトソースコードをフォークしたり、パッチを当てて利用することは滅多にありません。
@ -13,9 +13,9 @@ Kubernetesは柔軟な設定が可能で、高い拡張性を持っています
管理しているKubernetesクラスターを、動作環境の要件にどのように適合させるべきかを理解したい{{< glossary_tooltip text="クラスター管理者" term_id="cluster-operator" >}}を対象にしています。
将来の {{< glossary_tooltip text="プラットフォーム開発者" term_id="platform-developer" >}} 、またはKubernetesプロジェクトの{{< glossary_tooltip text="コントリビューター" term_id="contributor" >}}にとっても、どのような拡張のポイントやパターンが存在するのか、また、それぞれのトレードオフや制限事項を学ぶための導入として役立つでしょう。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## 概要
@ -152,9 +152,10 @@ Kubernetesはいくつかのビルトイン認証方式と、それらが要件
スケジューラは[Webhook](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/scheduler_extender.md)もサポートしており、Webhookバックエンド（スケジューラーエクステンション）を通じてPodを配置するために選択されたノードをフィルタリング、優先度付けすることが可能です。
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* [カスタムリソース](/docs/concepts/api-extension/custom-resources/)についてより深く学ぶ
* [動的Admission control](/docs/reference/access-authn-authz/extensible-admission-controllers/)について学ぶ
@ -164,4 +165,4 @@ Kubernetesはいくつかのビルトイン認証方式と、それらが要件
* [kubectlプラグイン](/docs/tasks/extend-kubectl/kubectl-plugins/)について学ぶ
* [オペレーターパターン](/docs/concepts/extend-kubernetes/operator/)について学ぶ
{{% /capture %}}

15
content/ja/docs/concepts/extend-kubernetes/operator.md
View File

@ -1,17 +1,17 @@
---
title: オペレーターパターン
content_template: templates/concept
content_type: concept
weight: 30
---
{{% capture overview %}}
<!-- overview -->
オペレーターはサードパーティのアプリケーション、コンポーネントを管理するためのリソースを活用する、Kubernetesへのソフトウェア拡張です。
オペレーターは、特に[制御ループ](/docs/concepts/#kubernetes-control-plane)のようなKubernetesが持つ仕組みに準拠しています。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## モチベーション
@ -79,9 +79,10 @@ kubectl edit SampleDB/example-database # 手動でいくつかの設定を変更
オペレーター（すなわち、コントローラー）はどの言語/ランタイムでも実装でき、[Kubernetes APIのクライアント](/docs/reference/using-api/client-libraries/)として機能させることができます。
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* [Custom Resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)をより深く学びます
* ユースケースに合わせた、既製のオペレーターを[OperatorHub.io](https://operatorhub.io/)から見つけます
@ -94,4 +95,4 @@ kubectl edit SampleDB/example-database # 手動でいくつかの設定を変更
* オペレーターパターンを紹介している[CoreOSオリジナル記事](https://coreos.com/blog/introducing-operators.html)を読みます
* Google Cloudが出したオペレーター作成のベストプラクティス[記事](https://cloud.google.com/blog/products/containers-kubernetes/best-practices-for-building-kubernetes-operators-and-stateful-apps)を読みます
{{% /capture %}}

15
content/ja/docs/concepts/overview/components.md
View File

@ -1,13 +1,13 @@
---
title: Kubernetesのコンポーネント
content_template: templates/concept
content_type: concept
weight: 20
card:
name: concepts
weight: 20
---
{{% capture overview %}}
<!-- overview -->
Kubernetesをデプロイすると、クラスターが展開されます。
{{< glossary_definition term_id="cluster" length="all" prepend="クラスターは、">}}
@ -17,9 +17,9 @@ Kubernetesをデプロイすると、クラスターが展開されます。
![Kubernetesのコンポーネント](/images/docs/components-of-kubernetes.png)
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## マスターコンポーネント
@ -112,10 +112,11 @@ Kubernetesによって開始されたコンテナは、DNS検索にこのDNSサ
[クラスターレベルログ](/docs/concepts/cluster-administration/logging/)メカニズムは、コンテナのログを、検索／参照インターフェイスを備えた中央ログストアに保存します。
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* [ノード](/ja/docs/concepts/architecture/nodes/)について学ぶ
* [コントローラー](/docs/concepts/architecture/controller/)について学ぶ
* [kube-scheduler](/ja/docs/concepts/scheduling/kube-scheduler/)について学ぶ
* etcdの公式 [ドキュメント](https://etcd.io/docs/)を読む
{{% /capture %}}

10
content/ja/docs/concepts/overview/kubernetes-api.md
View File

@ -1,14 +1,14 @@
---
reviewers:
title: Kubernetes API
content_template: templates/concept
content_type: concept
weight: 30
card:
name: concepts
weight: 30
---
{{% capture overview %}}
<!-- overview -->
全般的なAPIの規則は、[API規則ドキュメント](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md)に記載されています。
@ -22,9 +22,9 @@ Kubernetes APIは、システムの宣言的設定スキーマの基礎として
Kubernetesそれ自身は複数のコンポーネントから構成されており、APIを介して連携しています。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## APIの変更
@ -113,4 +113,4 @@ APIグループは、RESTのパスとシリアライズされたオブジェク
DaemonSets、Deployments、HorizontalPodAutoscalers、Ingresses、JobsReplicaSets、そしてReplicaSetsはデフォルトで有効です。
その他の拡張リソースは、APIサーバーの`--runtime-config`を設定することで有効化できます。`--runtime-config`はカンマ区切りの複数の値を設定可能です。例えば、deploymentsとingressを無効化する場合、`--runtime-config=extensions/v1beta1/deployments=false,extensions/v1beta1/ingresses=false`と設定します。
{{% /capture %}}

15
content/ja/docs/concepts/overview/what-is-kubernetes.md
View File

@ -1,17 +1,17 @@
---
title: Kubernetesとは何か？
content_template: templates/concept
content_type: concept
weight: 10
card:
name: concepts
weight: 10
---
{{% capture overview %}}
<!-- overview -->
このページでは、Kubernetesの概要について説明します。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
Kubernetesは、宣言的な構成管理と自動化を促進し、コンテナ化されたワークロードやサービスを管理するための、ポータブルで拡張性のあるオープンソースプラットホームです。
Kubernetesは膨大で、急速に成長しているエコシステムを備えており、それらのサービス、サポート、ツールは幅広い形で利用可能です。
@ -94,11 +94,12 @@ Kubernetesは...
**Kubernetes** という名前はギリシャ語で *操舵手* や *パイロット* という意味があり、*知事* や[サイバネティックス](http://www.etymonline.com/index.php?term=cybernetics)の語源にもなっています。*K8s* は、8文字の「ubernete」を「8」に置き換えた略語です。
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* [はじめる](/docs/setup/)準備はできましたか？
* さらなる詳細については、[Kubernetesのドキュメント](/ja/docs/home/)を御覧ください。
{{% /capture %}}

15
content/ja/docs/concepts/overview/working-with-objects/annotations.md
View File

@ -1,14 +1,14 @@
---
title: アノテーション(Annotations)
content_template: templates/concept
content_type: concept
weight: 50
---
{{% capture overview %}}
<!-- overview -->
ユーザーは、識別用途でない任意のメタデータをオブジェクトに割り当てるためにアノテーションを使用できます。ツールやライブラリなどのクライアントは、このメタデータを取得できます。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## オブジェクトにメタデータを割り当てる
ユーザーは、Kubernetesオブジェクトに対してラベルやアノテーションの両方またはどちらか一方を割り当てることができます。
@ -59,9 +59,10 @@ _アノテーション_ はキーとバリューのペアです。有効なア
`kubernetes.io/`と`k8s.io/`プレフィックスは、Kubernetesコアコンポーネントのために予約されています。
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
[ラベルとセレクター](/docs/concepts/overview/working-with-objects/labels/)について学習してください。
{{% /capture %}}

9
content/ja/docs/concepts/overview/working-with-objects/common-labels.md
View File

@ -1,15 +1,15 @@
---
title: 推奨ラベル(Recommended Labels)
content_template: templates/concept
content_type: concept
---
{{% capture overview %}}
<!-- overview -->
ユーザーはkubectlやダッシュボード以外に、多くのツールでKubernetesオブジェクトの管理と可視化ができます。共通のラベルセットにより、全てのツールにおいて解釈可能な共通のマナーに沿ってオブジェクトを表現することで、ツールの相互運用を可能にします。
ツール化に対するサポートに加えて、推奨ラベルはクエリ可能な方法でアプリケーションを表現します。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
メタデータは、_アプリケーション_ のコンセプトを中心に構成されています。KubernetesはPaaS(Platform as a Service)でなく、アプリケーションの公式な概念を持たず、またそれを強制することはありません。
そのかわり、アプリケーションは、非公式で、メタデータによって表現されています。単一のアプリケーションが有する項目に対する定義は厳密に決められていません。
@ -153,4 +153,3 @@ metadata:
MySQLの`StatefulSet`と`Service`により、MySQLとWordPressに関するより広範な情報が含まれていることに気づくでしょう。
{{% /capture %}}

15
content/ja/docs/concepts/overview/working-with-objects/kubernetes-objects.md
View File

@ -1,17 +1,17 @@
---
title: Kubernetesオブジェクトを理解する
content_template: templates/concept
content_type: concept
weight: 10
card:
name: concepts
weight: 40
---
{{% capture overview %}}
<!-- overview -->
このページでは、KubernetesオブジェクトがKubernetes APIでどのように表現されているか、またそれらを`.yaml`フォーマットでどのように表現するかを説明します。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Kubernetesオブジェクトを理解する
*Kubernetesオブジェクト* は、Kubernetes上で永続的なエンティティです。Kubernetesはこれらのエンティティを使い、クラスターの状態を表現します。具体的に言うと、下記のような内容が表現出来ます:
@ -63,10 +63,11 @@ Kubernetesオブジェクトを`.yaml`ファイルに記載して作成する場
またオブジェクトの`spec`の値も指定する必要があります。`spec`の正確なフォーマットは、Kubernetesオブジェクトごとに異なり、オブジェクトごとに特有な入れ子のフィールドを持っています。[Kubernetes API リファレンス](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)が、Kubernetesで作成出来る全てのオブジェクトに関するspecのフォーマットを探すのに役立ちます。
例えば、`Pod`オブジェクトに関する`spec`のフォーマットは[こちら](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)を、また`Deployment`オブジェクトに関する`spec`のフォーマットは[こちら](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deploymentspec-v1-apps)をご確認ください。
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* 最も重要、かつ基本的なKubernetesオブジェクト群を学びましょう、例えば、[Pod](/ja/docs/concepts/workloads/pods/pod-overview/)です。
{{% /capture %}}

10
content/ja/docs/concepts/overview/working-with-objects/labels.md
View File

@ -1,10 +1,10 @@
---
title: ラベル(Labels)とセレクター(Selectors)
content_template: templates/concept
content_type: concept
weight: 40
---
{{% capture overview %}}
<!-- overview -->
_ラベル(Labels)_ はPodなどのオブジェクトに割り当てられたキーとバリューのペアです。
ラベルはユーザーに関連した意味のあるオブジェクトの属性を指定するために使われることを目的としています。しかしKubernetesのコアシステムに対して直接的にその意味を暗示するものではありません。
@ -22,10 +22,10 @@ _ラベル(Labels)_ はPodなどのオブジェクトに割り当てられたキ
ラベルは効率的な検索・閲覧を可能にし、UIやCLI上での利用に最適です。
識別用途でない情報は、[アノテーション](/docs/concepts/overview/working-with-objects/annotations/)を用いて記録されるべきです。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## ラベルを使う動機
@ -216,4 +216,4 @@ selector:
ラベルを選択するための1つのユースケースはPodがスケジュールできるNodeのセットを制限することです。
さらなる情報に関しては、[Node選定](/ja/docs/concepts/configuration/assign-pod-node/) のドキュメントを参照してください。
{{% /capture %}}

10
content/ja/docs/concepts/overview/working-with-objects/names.md
View File

@ -1,11 +1,11 @@
---
reviewers:
title: 名前
content_template: templates/concept
content_type: concept
weight: 20
---
{{% capture overview %}}
<!-- overview -->
KubernetesのREST API内の全てのオブジェクトは、名前とUIDで明確に識別されます。
@ -13,9 +13,9 @@ KubernetesのREST API内の全てのオブジェクトは、名前とUIDで明
名前とUIDに関する正確な構文については、[識別子デザインドキュメント](https://git.k8s.io/community/contributors/design-proposals/architecture/identifiers.md)を参照してください。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## 名前
@ -27,4 +27,4 @@ KubernetesのREST API内の全てのオブジェクトは、名前とUIDで明
{{< glossary_definition term_id="uid" length="all" >}}
{{% /capture %}}

10
content/ja/docs/concepts/overview/working-with-objects/namespaces.md
View File

@ -1,18 +1,18 @@
---
title: Namespace(名前空間)
content_template: templates/concept
content_type: concept
weight: 30
---
{{% capture overview %}}
<!-- overview -->
Kubernetesは、同一の物理クラスター上で複数の仮想クラスターの動作をサポートします。
この仮想クラスターをNamespaceと呼びます。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## 複数のNamespaceを使う時
@ -97,4 +97,4 @@ kubectl api-resources --namespaced=true
kubectl api-resources --namespaced=false
```
{{% /capture %}}

15
content/ja/docs/concepts/overview/working-with-objects/object-management.md
View File

@ -1,16 +1,16 @@
---
title: Kubernetesオブジェクト管理
content_template: templates/concept
content_type: concept
weight: 15
---
{{% capture overview %}}
<!-- overview -->
`kubectl`コマンドラインツールは、Kubernetesオブジェクトを作成、管理するためにいくつかの異なる方法をサポートしています。
このドキュメントでは、それらの異なるアプローチごとの概要を提供します。
Kubectlを使ったオブジェクト管理の詳細は、[Kubectl book](https://kubectl.docs.kubernetes.io)を参照してください。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## 管理手法
@ -157,9 +157,10 @@ kubectl apply -R -f configs/
- 宣言型オブジェクト設定は、デバッグ、そして想定外の結果が出たときに理解するのが困難です
- 差分を利用した一部のみの更新は、複雑なマージ、パッチの操作が必要です
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
- [命令型コマンドを利用したKubernetesオブジェクトの管理](/docs/tasks/manage-kubernetes-objects/imperative-command/)
- [オブジェクト設定（命令型）を利用したKubernetesオブジェクトの管理](/docs/tasks/manage-kubernetes-objects/imperative-config/)
@ -169,4 +170,4 @@ kubectl apply -R -f configs/
- [Kubectl Book](https://kubectl.docs.kubernetes.io)
- [Kubernetes APIリファレンス](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
{{% /capture %}}

15
content/ja/docs/concepts/scheduling/kube-scheduler.md
View File

@ -1,16 +1,16 @@
---
title: Kubernetesのスケジューラー
content_template: templates/concept
content_type: concept
weight: 60
---
{{% capture overview %}}
<!-- overview -->
Kubernetesにおいて、_スケジューリング_ とは、{{< glossary_tooltip term_id="kubelet" >}}が{{< glossary_tooltip text="Pod" term_id="pod" >}}を稼働させるために{{< glossary_tooltip text="Node" term_id="node" >}}に割り当てることを意味します。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## スケジューリングの概要{#scheduling}
@ -110,9 +110,10 @@ kube-schedulerは、デフォルトで用意されているスケジューリン
- `EqualPriorityMap`: 全てのNodeに対して等しい重みを与えます。
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* [スケジューラーのパフォーマンスチューニング](/docs/concepts/scheduling/scheduler-perf-tuning/)を参照してください。
* kube-schedulerの[リファレンスドキュメント](/docs/reference/command-line-tools-reference/kube-scheduler/)を参照してください。
* [複数のスケジューラーの設定](https://kubernetes.io/docs/tasks/administer-cluster/configure-multiple-schedulers/)について学んでください。
{{% /capture %}}

10
content/ja/docs/concepts/scheduling/scheduler-perf-tuning.md
View File

@ -1,10 +1,10 @@
---
title: スケジューラーのパフォーマンスチューニング
content_template: templates/concept
content_type: concept
weight: 70
---
{{% capture overview %}}
<!-- overview -->
{{< feature-state for_k8s_version="1.14" state="beta" >}}
@ -14,9 +14,9 @@ weight: 70
このページでは、大規模のKubernetesクラスターにおけるパフォーマンス最適化のためのチューニングについて説明します。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## スコア付けするノードの割合
@ -71,4 +71,4 @@ Node 1, Node 5, Node 2, Node 6, Node 3, Node 4
全てのノードのチェックを終えたら、1番目のノードに戻ってチェックをします。
{{% /capture %}}

15
content/ja/docs/concepts/services-networking/connect-applications-service.md
View File

@ -1,11 +1,11 @@
---
title: サービスとアプリケーションの接続
content_template: templates/concept
content_type: concept
weight: 30
---
{{% capture overview %}}
<!-- overview -->
## コンテナを接続するためのKubernetesモデル
@ -25,9 +25,9 @@ Kubernetesでは、どのホストで稼働するかに関わらず、Podが他
このガイドでは、シンプルなnginxサーバーを使用して概念実証を示します。
同じ原則が、より完全な[Jenkins CIアプリケーション](https://kubernetes.io/blog/2015/07/strong-simple-ssl-for-kubernetes)で具体化されています。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Podをクラスターに公開する
@ -410,11 +410,12 @@ LoadBalancer Ingress: a320587ffd19711e5a37606cf4a74574-1142138393.us-east-1.el
...
```
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
Kubernetesは、複数のクラスターおよびクラウドプロバイダーにまたがるフェデレーションサービスもサポートし、可用性の向上、フォールトトレランスの向上、サービスのスケーラビリティの向上を実現します。
詳細については[フェデレーションサービスユーザーガイド](/docs/concepts/cluster-administration/federation-service-discovery/)を参照してください。
{{% /capture %}}

15
content/ja/docs/concepts/services-networking/dns-pod-service.md
View File

@ -1,14 +1,14 @@
---
reviewers:
title: ServiceとPodに対するDNS
content_template: templates/concept
content_type: concept
weight: 20
---
{{% capture overview %}}
<!-- overview -->
このページではKubernetesによるDNSサポートについて概観します。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## イントロダクション
@ -191,13 +191,14 @@ PodのDNS設定と"`None`"というDNSポリシーの利用可能なバージョ
| 1.10 | β版 (デフォルトで有効)|
| 1.9 | α版 |
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
DNS設定の管理方法に関しては、[DNS Serviceの設定](/docs/tasks/administer-cluster/dns-custom-nameservers/)
を確認してください。
{{% /capture %}}

15
content/ja/docs/concepts/services-networking/ingress.md
View File

@ -1,15 +1,15 @@
---
title: Ingress
content_template: templates/concept
content_type: concept
weight: 40
---
{{% capture overview %}}
<!-- overview -->
{{< feature-state for_k8s_version="v1.1" state="beta" >}}
{{< glossary_definition term_id="ingress" length="all" >}}
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## 用語
@ -395,9 +395,10 @@ Ingressリソースに直接関与しない複数の方法でServiceを公開で
* [Service.Type=LoadBalancer](/ja/docs/concepts/services-networking/service/#loadbalancer)
* [Service.Type=NodePort](/ja/docs/concepts/services-networking/service/#nodeport)
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* [Ingressコントローラー](/docs/concepts/services-networking/ingress-controllers/)について学ぶ
* [MinikubeとNGINXコントローラーでIngressのセットアップを行う](/docs/tasks/access-application-cluster/ingress-minikube)
{{% /capture %}}

15
content/ja/docs/concepts/services-networking/service.md
View File

@ -5,21 +5,21 @@ feature:
description: >
Kubernetesでは、なじみのないサービスディスカバリーのメカニズムを使用するためにユーザーがアプリケーションの修正をする必要はありません。KubernetesはPodにそれぞれのIPアドレス割り振りや、Podのセットに対する単一のDNS名を提供したり、それらのPodのセットに対する負荷分散が可能です。
content_template: templates/concept
content_type: concept
weight: 10
---
{{% capture overview %}}
<!-- overview -->
{{< glossary_definition term_id="service" length="short" >}}
Kubernetesでは、なじみのないサービスディスカバリーのメカニズムを使用するためにユーザーがアプリケーションの修正をする必要はありません。
KubernetesはPodにそれぞれのIPアドレス割り振りや、Podのセットに対する単一のDNS名を提供したり、それらのPodのセットに対する負荷分散が可能です。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Serviceを利用する動機
@ -941,12 +941,13 @@ Kubernetesプロジェクトは、L7 (HTTP) Serviceへのサポートをもっ
Kubernetesプロジェクトは、現在利用可能なClusterIP、NodePortやLoadBalancerタイプのServiceに対して、より柔軟なIngressのモードを追加する予定です。
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/)を参照してください。
* [Ingress](/docs/concepts/services-networking/ingress/)を参照してください。
* [Endpoint Slices](/docs/concepts/services-networking/endpoint-slices/)を参照してください。
{{% /capture %}}

10
content/ja/docs/concepts/storage/dynamic-provisioning.md
View File

@ -1,19 +1,19 @@
---
reviewers:
title: ボリュームの動的プロビジョニング(Dynamic Volume Provisioning)
content_template: templates/concept
content_type: concept
weight: 40
---
{{% capture overview %}}
<!-- overview -->
ボリュームの動的プロビジョニングにより、ストレージ用のボリュームをオンデマンドに作成することができます。
動的プロビジョニングなしでは、クラスター管理者はクラウドプロバイダーまたはストレージプロバイダーに対して新規のストレージ用のボリュームと[`PersistentVolume`オブジェクト](/docs/concepts/storage/persistent-volumes/)を作成するように手動で指示しなければなりません。動的プロビジョニングの機能によって、クラスター管理者がストレージを事前にプロビジョンする必要がなくなります。その代わりに、ユーザーによってリクエストされたときに自動でストレージをプロビジョンします。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## バックグラウンド
@ -87,4 +87,4 @@ spec:
[マルチゾーン](/docs/setup/multiple-zones)クラスター内では、Podは単一のリージョン内のゾーンをまたいでしか稼働できません。シングルゾーンのStorageバックエンドはPodがスケジュールされるゾーン内でプロビジョンされる必要があります。これは[Volume割り当てモード](/docs/concepts/storage/storage-classes/#volume-binding-mode)を設定することにより可能となります。
{{% /capture %}}

10
content/ja/docs/concepts/storage/persistent-volumes.md
View File

@ -5,18 +5,18 @@ feature:
description: >
ローカルストレージや<a href="https://cloud.google.com/storage/">GCP</a>、<a href="https://aws.amazon.com/products/storage/">AWS</a>などのパブリッククラウドプロバイダー、もしくはNFS、iSCSI、Gluster、Ceph、Cinder、Flockerのようなネットワークストレージシステムの中から選択されたものを自動的にマウントします。
content_template: templates/concept
content_type: concept
weight: 20
---
{{% capture overview %}}
<!-- overview -->
このドキュメントではKubernetesの`PersistentVolume`について説明します。[ボリューム](/docs/concepts/storage/volumes/)を一読することをおすすめします。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## 概要
@ -658,4 +658,4 @@ spec:
- ユーザーがストレージクラス名を指定しない場合、`persistentVolumeClaim.storageClassName`フィールドはnilのままにする。これにより、PVはユーザーにクラスターのデフォルトストレージクラスで自動的にプロビジョニングされる。多くのクラスター環境ではデフォルトのストレージクラスがインストールされているが、管理者は独自のデフォルトストレージクラスを作成することができる。
- ツールがPVCを監視し、しばらくしてもバインドされないことをユーザーに表示する。これはクラスターが動的ストレージをサポートしない(この場合ユーザーは対応するPVを作成するべき)、もしくはクラスターがストレージシステムを持っていない(この場合ユーザーはPVCを必要とする設定をデプロイできない)可能性があることを示す。
{{% /capture %}}

10
content/ja/docs/concepts/storage/volume-pvc-datasource.md
View File

@ -1,10 +1,10 @@
---
title: CSI Volume Cloning
content_template: templates/concept
content_type: concept
weight: 30
---
{{% capture overview %}}
<!-- overview -->
{{< feature-state for_k8s_version="v1.15" state="alpha" >}}
このドキュメントではKubernetesで既存のCSIボリュームの複製についてのコンセプトを説明します。このページを読む前にあらかじめ[ボリューム](/docs/concepts/storage/volumes)についてよく理解していることが望ましいです。
@ -16,10 +16,10 @@ weight: 30
```
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## イントロダクション
@ -61,4 +61,4 @@ spec:
新しいPVCが使用可能になると、複製されたPVCは他のPVCと同じように利用されます。またこの時点で新しく作成されたPVCは独立したオブジェクトであることが期待されます。元のdataSource PVCを考慮せず個別に利用、複製、スナップショット、削除できます。これはまた複製元が新しく作成された複製にリンクされておらず、新しく作成された複製に影響を与えずに変更または削除できることを意味します。
{{% /capture %}}

10
content/ja/docs/concepts/storage/volume-snapshot-classes.md
View File

@ -1,19 +1,19 @@
---
reviewers:
title: VolumeSnapshotClass
content_template: templates/concept
content_type: concept
weight: 30
---
{{% capture overview %}}
<!-- overview -->
このドキュメントでは、Kubernetesにおける`VolumeSnapshotClass`のコンセプトについて説明します。
関連する項目として、[Volumeのスナップショット](/docs/concepts/storage/volume-snapshots/)と[ストレージクラス](/docs/concepts/storage/storage-classes)も参照してください。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## イントロダクション
@ -45,4 +45,4 @@ VolumeSnapshotClassは、VolumeSnapshotをプロビジョンするときに何
VolumeSnapshotClassは、そのクラスに属するVolumeSnapshotを指定するパラメータを持っています。
`snapshotter`に応じて様々なパラメータを使用できます。
{{% /capture %}}

10
content/ja/docs/concepts/workloads/controllers/cron-jobs.md
View File

@ -1,10 +1,10 @@
---
title: CronJob
content_template: templates/concept
content_type: concept
weight: 80
---
{{% capture overview %}}
<!-- overview -->
_CronJob_ は時刻ベースのスケジュールによって[Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/)を作成します。
@ -17,9 +17,9 @@ _CronJob_ オブジェクトとは _crontab_ (cron table)ファイルでみら
cronジョブを作成し、実行するインストラクション、または、cronジョブ仕様ファイルのサンプルについては、[Running automated tasks with cron jobs](/docs/tasks/job/automated-tasks-with-cron-jobs)をご覧ください。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## CronJobの制限
@ -43,4 +43,4 @@ Cannot determine if job needs to be started. Too many missed start time (> 100).
CronJobはスケジュールに一致するJobの作成にのみ関与するのに対して、JobはJobが示すPod管理を担います。
{{% /capture %}}

10
content/ja/docs/concepts/workloads/controllers/daemonset.md
View File

@ -1,11 +1,11 @@
---
reviewers:
title: DaemonSet
content_template: templates/concept
content_type: concept
weight: 50
---
{{% capture overview %}}
<!-- overview -->
_DaemonSet_ は全て(またはいくつか)のNodeが単一のPodのコピーを稼働させることを保証します。Nodeがクラスターに追加されるとき、PodがNode上に追加されます。Nodeがクラスターから削除されたとき、それらのPodはガーベージコレクターにより除去されます。DaemonSetの削除により、DaemonSetが作成したPodもクリーンアップします。
@ -18,10 +18,10 @@ DaemonSetのいくつかの典型的な使用例は以下の通りです。
シンプルなケースとして、各タイプのデーモンにおいて、全てのNodeをカバーする1つのDaemonSetが使用されるケースがあります。
さらに複雑な設定では、単一のタイプのデーモン用ですが、異なるフラグや、異なるハードウェアタイプに対するメモリー、CPUリクエストを要求する複数のDaemonSetを使用するケースもあります。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## DaemonSet Specの記述
@ -164,4 +164,4 @@ DaemonSetは、Podの作成し、そのPodが停止されることのないプ
フロントエンドのようなServiceのように、どのホスト上にPodが稼働するか制御するよりも、レプリカ数をスケールアップまたはスケールダウンしたりローリングアップデートする方が重要であるような、状態をもたないServiceに対してDeploymentを使ってください。
Podのコピーが全てまたは特定のホスト上で常に稼働していることが重要な場合や、他のPodの前に起動させる必要があるときにDaemonSetを使ってください。
{{% /capture %}}

10
content/ja/docs/concepts/workloads/controllers/deployment.md
View File

@ -5,11 +5,11 @@ feature:
description: >
Kubernetesはアプリケーションや設定への変更を段階的に行い、アプリケーションの状態を監視しながら、全てのインスタンスが同時停止しないようにします。更新に問題が起きたとき、Kubernetesは変更のロールバックを行います。進化を続けるDeploymnetのエコシステムを活用してください。
content_template: templates/concept
content_type: concept
weight: 30
---
{{% capture overview %}}
<!-- overview -->
_Deployment_ コントローラーは[Pod](/ja/docs/concepts/workloads/pods/pod/)と[ReplicaSet](/ja/docs/concepts/workloads/controllers/replicaset/)の宣言的なアップデート機能を提供します。
@ -19,10 +19,10 @@ _Deployment_ コントローラーは[Pod](/ja/docs/concepts/workloads/pods/pod/
Deploymentによって作成されたReplicaSetを管理しないでください。ユーザーのユースケースが下記の項目をカバーできていない場合はメインのKubernetesリポジトリーにイシューを作成することを検討してください。
{{< /note >}}
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## ユースケース
@ -996,4 +996,4 @@ Deploymentのリビジョン履歴は、Deploymentが管理するReplicaSetに
[`kubectl rolling update`](/docs/reference/generated/kubectl/kubectl-commands#rolling-update)によって、同様の形式でPodとReplicationControllerを更新できます。しかしDeploymentの使用が推奨されます。なぜならDeploymentの作成は宣言的であり、ローリングアップデートが更新された後に過去のリビジョンにロールバックできるなど、いくつかの追加機能があります。
{{% /capture %}}

15
content/ja/docs/concepts/workloads/controllers/garbage-collection.md
View File

@ -1,16 +1,16 @@
---
title: ガベージコレクション
content_template: templates/concept
content_type: concept
weight: 60
---
{{% capture overview %}}
<!-- overview -->
Kubernetesのガベージコレクターの役割は、かつてオーナーがいたが、現時点でもはやオーナーがいないようなオブジェクトの削除を行うことです。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## オーナーとその従属オブジェクト
@ -134,16 +134,17 @@ Kubernetes1.7以前では、Deploymentに対するカスケード削除におい
[#26120](https://github.com/kubernetes/kubernetes/issues/26120)にてイシューがトラックされています。
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
[Design Doc 1](https://git.k8s.io/community/contributors/design-proposals/api-machinery/garbage-collection.md)
[Design Doc 2](https://git.k8s.io/community/contributors/design-proposals/api-machinery/synchronous-garbage-collection.md)
{{% /capture %}}

10
content/ja/docs/concepts/workloads/controllers/replicaset.md
View File

@ -1,18 +1,18 @@
---
reviewers:
title: ReplicaSet
content_template: templates/concept
content_type: concept
weight: 10
---
{{% capture overview %}}
<!-- overview -->
ReplicaSetの目的は、どのような時でも安定したレプリカPodのセットを維持することです。これは、理想的なレプリカ数のPodが利用可能であることを保証するものとして使用されます。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## ReplicaSetがどのように動くか
@ -312,4 +312,4 @@ ReplicaSetは[_ReplicationControllers_](/docs/concepts/workloads/controllers/rep
この2つは、ReplicationControllerが[ラベルについてのユーザーガイド](/docs/concepts/overview/working-with-objects/labels/#label-selectors)に書かれているように、集合ベース(set-based)のセレクター要求をサポートしていないことを除いては、同じ目的を果たし、同じようにふるまいます。
このように、ReplicaSetはReplicationControllerよりも好まれます。
{{% /capture %}}

15
content/ja/docs/concepts/workloads/controllers/statefulset.md
View File

@ -1,11 +1,11 @@
---
reviewers:
title: StatefulSet
content_template: templates/concept
content_type: concept
weight: 40
---
{{% capture overview %}}
<!-- overview -->
StatefulSetはステートフルなアプリケーションを管理するためのワークロードAPIです。
@ -14,9 +14,9 @@ StatefulSetはKubernetes1.9において利用可能(GA)です。
{{< /note >}}
{{< glossary_definition term_id="statefulset" length="all" >}}
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## StatefulSetの使用
@ -195,11 +195,12 @@ Kubernetes1.7とそれ以降のバージョンにおいて、StatefulSetの`.spe
そのテンプレートを戻したあと、ユーザーはまたStatefulSetが異常状態で稼働しようとしていたPodをすべて削除する必要があります。StatefulSetはその戻されたテンプレートを使ってPodの再作成を始めます。
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* [ステートフルなアプリケーションのデプロイ](/docs/tutorials/stateful-application/basic-stateful-set/)の例を参考にしてください。
* [StatefulSetを使ったCassandraのデプロイ](/docs/tutorials/stateful-application/cassandra/)の例を参考にしてください。
{{% /capture %}}

15
content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md
View File

@ -1,11 +1,11 @@
---
reviewers:
title: 終了したリソースのためのTTLコントローラー(TTL Controller for Finished Resources)
content_template: templates/concept
content_type: concept
weight: 65
---
{{% capture overview %}}
<!-- overview -->
{{< feature-state for_k8s_version="v1.12" state="alpha" >}}
@ -14,12 +14,12 @@ TTLコントローラーは現在[Job](/docs/concepts/workloads/controllers/jobs
α版の免責事項: この機能は現在α版の機能で、[Feature Gate](/docs/reference/command-line-tools-reference/feature-gates/)の`TTLAfterFinished`を有効にすることで使用可能です。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## TTLコントローラー
@ -45,12 +45,13 @@ TTLコントローラーが、TTL値が期限切れかそうでないかを決
Kubernetesにおいてタイムスキューを避けるために、全てのNode上でNTPの稼働を必須とします([#6159](https://github.com/kubernetes/kubernetes/issues/6159#issuecomment-93844058)を参照してください)。クロックは常に正しいものではありませんが、Node間におけるその差はとても小さいものとなります。TTLに0でない値をセットするときにこのリスクに対して注意してください。
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
[Jobの自動クリーンアップ](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically)
[設計ドキュメント](https://github.com/kubernetes/community/blob/master/keps/sig-apps/0026-ttl-after-finish.md)
{{% /capture %}}

15
content/ja/docs/concepts/workloads/pods/init-containers.md
View File

@ -1,16 +1,16 @@
---
title: Initコンテナ(Init Containers)
content_template: templates/concept
content_type: concept
weight: 40
---
{{% capture overview %}}
<!-- overview -->
このページでは、Initコンテナについて概観します。Initコンテナとは、アプリケーションコンテナの前に実行され、アプリケーションコンテナのイメージに存在しないセットアップスクリプトやユーティリティーを含んだ特別なコンテナです。
{{% /capture %}}
この機能はKubernetes1.6からβ版の機能として存在しています。InitコンテナはPodSpec内で、アプリケーションの`containers`という配列と並べて指定されます。そのベータ版のアノテーション値はまだ扱われ、PodSpecのフィールド値を上書きします。しかしながら、それらはKubernetesバージョン1.6と1.7において廃止されました。Kubernetesバージョン1.8からはそのアノテーション値はサポートされず、PodSpecフィールドの値に変換する必要があります。
{{% capture body %}}
<!-- body -->
## Initコンテナを理解する
単一の[Pod](/ja/docs/concepts/workloads/pods/pod-overview/)は、Pod内に複数のコンテナを稼働させることができますが、Initコンテナもまた、アプリケーションコンテナが稼働する前に1つまたは複数稼働できます。
@ -266,11 +266,12 @@ ApiServerのバージョン1.6.0かそれ以上のバージョンのクラスタ
ApiServerとKubeletバージョン1.8.0かそれ以上のバージョンでは、α版とβ版のアノテーションは削除されており、廃止されたアノテーションは`.spec.initContainers`フィールドへの移行が必須となります。
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* [Initコンテナを持っているPodの作成](/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container)
{{% /capture %}}

15
content/ja/docs/concepts/workloads/pods/pod-lifecycle.md
View File

@ -1,17 +1,17 @@
---
title: Podのライフサイクル
content_template: templates/concept
content_type: concept
weight: 30
---
{{% capture overview %}}
<!-- overview -->
このページではPodのライフサイクルについて説明します。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## PodのPhase
@ -317,10 +317,11 @@ spec:
* NodeコントローラがPodの`phase`をFailedにします。
* Podがコントローラで作成されていた場合は、別の場所で再作成されます。
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* [attaching handlers to Container lifecycle events](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)のハンズオンをやってみる
@ -328,4 +329,4 @@ spec:
* [Container lifecycle hooks](/docs/concepts/containers/container-lifecycle-hooks/)についてもっと学ぶ
{{% /capture %}}

15
content/ja/docs/concepts/workloads/pods/pod-overview.md
View File

@ -1,18 +1,18 @@
---
title: Podについての概観(Pod Overview)
content_template: templates/concept
content_type: concept
weight: 10
card:
name: concepts
weight: 60
---
{{% capture overview %}}
<!-- overview -->
このページでは、Kubernetesのオブジェクトモデルにおいて、デプロイ可能な最小単位のオブジェクトである`Pod`に関して概観します。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Podについて理解する
*Pod* は、Kubernetesアプリケーションの基本的な実行単位です。これは、作成またはデプロイするKubernetesオブジェクトモデルの中で最小かつ最も単純な単位です。Podは、{{< glossary_tooltip term_id="cluster" >}}で実行されているプロセスを表します。
@ -108,11 +108,12 @@ spec:
全てのレプリカの現在の理想的な状態を指定するというよりも、Podテンプレートはクッキーの抜き型のようなものです。一度クッキーがカットされると、そのクッキーは抜き型から離れて関係が無くなります。そこにはいわゆる”量子もつれ”といったものはありません。テンプレートに対するその後の変更や新しいテンプレートへの切り替えは、すでに作成されたPod上には直接的な影響はありません。
同様に、ReplicationControllerによって作成されたPodは、変更後に直接更新されます。これはPodとの意図的な違いとなり、そのPodに属する全てのコンテナの現在の理想的な状態を指定します。このアプローチは根本的にシステムのセマンティクスを単純化し、機能の柔軟性を高めます。
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* [Pod](/ja/docs/concepts/workloads/pods/pod/)について更に学びましょう
* Podの振る舞いに関して学ぶには下記を参照してください
* [Podの停止](/ja/docs/concepts/workloads/pods/pod/#podの終了)
* [Podのライフサイクル](/ja/docs/concepts/workloads/pods/pod-lifecycle/)
{{% /capture %}}

10
content/ja/docs/concepts/workloads/pods/pod.md
View File

@ -1,18 +1,18 @@
---
reviewers:
title: Pod
content_template: templates/concept
content_type: concept
weight: 20
---
{{% capture overview %}}
<!-- overview -->
_Pod_ は、Kubernetesで作成および管理できる、デプロイ可能な最小のコンピューティング単位です。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Podとは
@ -187,4 +187,4 @@ spec.containers[0].securityContext.privileged: forbidden '<*>(0xc20b222db0)true'
PodはKubernetes REST APIのトップレベルのリソースです。
APIオブジェクトの詳細については、[Pod APIオブジェクト](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)を参照してください 。
{{% /capture %}}

15
content/ja/docs/concepts/workloads/pods/podpreset.md
View File

@ -1,16 +1,16 @@
---
reviewers:
title: Pod Preset
content_template: templates/concept
content_type: concept
weight: 50
---
{{% capture overview %}}
<!-- overview -->
このページではPodPresetについて概観します。PodPresetは、Podの作成時にそのPodに対して、Secret、Volume、VolumeMountや環境変数など、特定の情報を注入するためのオブジェクトです。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## PodPresetを理解する
`PodPreset`はPodの作成時に追加のランタイム要求を注入するためのAPIリソースです。
@ -51,10 +51,11 @@ PodPresetによるPodの変更を受け付けたくないようなインスタ
1. `PodPreset`に対する管理コントローラーを有効にします。これを行うための1つの方法として、API Serverの`--enable-admission-plugins`オプションの値に`PodPreset`を含む方法があります。Minikubeにおいては、クラスターの起動時に`--extra-config=apiserver.enable-admission-plugins=Initializers,NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,PodPreset`を追加することで可能になります。
1. ユーザーが使う予定のNamespaceにおいて、`PodPreset`オブジェクトを作成することによりPodPresetを定義します。
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* [PodPresetを使ったPodへのデータの注入](/docs/tasks/inject-data-application/podpreset/)
{{% /capture %}}

8
content/ja/docs/contribute/_index.md
View File

@ -1,19 +1,19 @@
---
content_template: templates/concept
content_type: concept
title: Kubernetesのドキュメントに貢献する
linktitle: 貢献
main_menu: true
weight: 80
---
{{% capture overview %}}
<!-- overview -->
ドキュメントやウェブサイトに貢献したい方、ご協力お待ちしています。
はじめての方、久しぶりの方、開発者でもエンドユーザでも、はたまたタイポを見逃せない方でもどなたでも貢献可能です。
ドキュメントのスタイルガイドについては[こちら](/docs/contribute/style/style-guide/)。
{{% capture body %}}
<!-- body -->
## コントリビューターの種類
@ -60,4 +60,4 @@ weight: 80
- TwitterやStack Overflowといったオンラインフォーラムを通してKubernetesコミュニティに貢献したい方、または各地のミートアップやイベントについて知りたい方は[Kubernetes community site](/community/)へ。
- 機能開発に貢献したい方は、まずはじめに[Kubernetesコントリビューターチートシート](https://github.com/kubernetes/community/blob/master/contributors/guide/contributor-cheatsheet/README-ja.md)を読んでください。
{{% /capture %}}

10
content/ja/docs/home/supported-doc-versions.md
View File

@ -1,19 +1,19 @@
---
title: Kubernetesドキュメントがサポートしているバージョン
content_template: templates/concept
content_type: concept
card:
name: about
weight: 10
title: ドキュメントがサポートしているバージョン
---
{{% capture overview %}}
<!-- overview -->
本ウェブサイトでは、現行版とその直前4バージョンのKubernetesドキュメントを含んでいます。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## 現行版
@ -24,6 +24,6 @@ card:
{{< versions-other >}}
{{% /capture %}}

10
content/ja/docs/reference/_index.md
View File

@ -3,16 +3,16 @@ title: リファレンス
linkTitle: "リファレンス"
main_menu: true
weight: 70
content_template: templates/concept
content_type: concept
---
{{% capture overview %}}
<!-- overview -->
本セクションには、Kubernetesのドキュメントのリファレンスが含まれています。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## APIリファレンス
@ -52,4 +52,4 @@ content_template: templates/concept
Kubernetesの機能に関する設計ドキュメントのアーカイブです。[Kubernetesアーキテクチャ](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md) と[Kubernetesデザイン概要](https://git.k8s.io/community/contributors/design-proposals)から読み始めると良いでしょう。
{{% /capture %}}

15
content/ja/docs/reference/command-line-tools-reference/feature-gates.md
View File

@ -1,16 +1,16 @@
---
title: フィーチャーゲート
weight: 10
content_template: templates/concept
content_type: concept
---
{{% capture overview %}}
<!-- overview -->
このページでは管理者がそれぞれのKubernetesコンポーネントで指定できるさまざまなフィーチャーゲートの概要について説明しています。
各機能におけるステージの説明については、[機能のステージ](#feature-stages)を参照してください。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## 概要
フィーチャーゲートはアルファ機能または実験的機能を記述するkey=valueのペアのセットです。管理者は各コンポーネントで`--feature-gates`コマンドラインフラグを使用することで機能をオンまたはオフにできます。
@ -398,7 +398,8 @@ GAになってからさらなる変更を加えることは現実的ではない
- `WinDSR`: kube-proxyがWindows用のDSRロードバランサーを作成できるようにします。
- `WinOverlay`: kube-proxyをWindowsのオーバーレイモードで実行できるようにします。
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* Kubernetesの[非推奨ポリシー](/docs/reference/using-api/deprecation-policy/)では、機能とコンポーネントを削除するためのプロジェクトのアプローチを説明しています。
{{% /capture %}}

15
content/ja/docs/reference/kubectl/cheatsheet.md
View File

@ -1,20 +1,20 @@
---
title: kubectlチートシート
content_template: templates/concept
content_type: concept
card:
name: reference
weight: 30
---
{{% capture overview %}}
<!-- overview -->
[Kubectl概要](/docs/reference/kubectl/overview/)と[JsonPathガイド](/docs/reference/kubectl/jsonpath)も合わせてご覧ください。
このページは`kubectl`コマンドの概要です。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
# kubectl - チートシート
@ -369,9 +369,10 @@ kubectlのログレベルは、レベルを表す整数が後に続く`-v`また
`--v=8` | HTTPリクエストのコンテンツを表示します
`--v=9` | HTTPリクエストのコンテンツをtruncationなしで表示します
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* kubectlについてより深く学びたい方は[kubectl概要](/docs/reference/kubectl/overview/)をご覧ください。
@ -381,4 +382,4 @@ kubectlのログレベルは、レベルを表す整数が後に続く`-v`また
* コミュニティ版[kubectlチートシート](https://github.com/dennyzhang/cheatsheet-kubernetes-A4)もご覧ください。
{{% /capture %}}

10
content/ja/docs/setup/_index.md
View File

@ -3,7 +3,7 @@ no_issue: true
title: はじめに
main_menu: true
weight: 20
content_template: templates/concept
content_type: concept
card:
name: setup
weight: 20
@ -14,7 +14,7 @@ card:
title: 本番環境
---
{{% capture overview %}}
<!-- overview -->
このセクションではKubernetesをセットアップして動かすための複数のやり方について説明します。
@ -24,9 +24,9 @@ Kubernetesクラスタはローカルマシン、クラウド、オンプレの
簡潔に言えば、学習用としても、本番環境用としてもKubernetesクラスターを作成することができます。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## 環境について学ぶ
@ -110,4 +110,4 @@ Kubernetesクラスタにおける抽象レイヤには {{< glossary_tooltip tex
| [VMware](https://cloud.vmware.com/) | [VMware Cloud PKS](https://cloud.vmware.com/vmware-cloud-pks) |[VMware Enterprise PKS](https://cloud.vmware.com/vmware-enterprise-pks) | [VMware Enterprise PKS](https://cloud.vmware.com/vmware-enterprise-pks) | [VMware Essential PKS](https://cloud.vmware.com/vmware-essential-pks) | |[VMware Essential PKS](https://cloud.vmware.com/vmware-essential-pks)
| [Z.A.R.V.I.S.](https://zarvis.ai/) | &#x2714; | | | | | |
{{% /capture %}}

10
content/ja/docs/setup/best-practices/certificates.md
View File

@ -1,19 +1,19 @@
---
title: PKI証明書とその要件
content_template: templates/concept
content_type: concept
weight: 40
---
{{% capture overview %}}
<!-- overview -->
Kubernetes requires PKI certificates for authentication over TLS.
If you install Kubernetes with [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/), the certificates that your cluster requires are automatically generated.
You can also generate your own certificates -- for example, to keep your private keys more secure by not storing them on the API server.
This page explains the certificates that your cluster requires.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## クラスタではどのように証明書が使われているのか
@ -140,4 +140,4 @@ These files are used as follows:
[kubeadm]: /docs/reference/setup-tools/kubeadm/kubeadm/
[proxy]: /docs/tasks/access-kubernetes-api/configure-aggregation-layer/
{{% /capture %}}

10
content/ja/docs/setup/best-practices/multiple-zones.md
View File

@ -1,16 +1,16 @@
---
title: 複数のゾーンで動かす
weight: 10
content_template: templates/concept
content_type: concept
---
{{% capture overview %}}
<!-- overview -->
This page describes how to run a cluster in multiple zones.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## 始めに
@ -397,4 +397,4 @@ KUBERNETES_PROVIDER=aws KUBE_USE_EXISTING_MASTER=true KUBE_AWS_ZONE=us-west-2b k
KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2a kubernetes/cluster/kube-down.sh
```
{{% /capture %}}

10
content/ja/docs/setup/learning-environment/minikube.md
View File

@ -1,15 +1,15 @@
---
title: Minikubeを使用してローカル環境でKubernetesを動かす
content_template: templates/concept
content_type: concept
---
{{% capture overview %}}
<!-- overview -->
Minikubeはローカル環境でKubernetesを簡単に実行するためのツールです。Kubernetesを試したり日々の開発への使用を検討するユーザー向けに、PC上のVM内でシングルノードのKubernetesクラスタを実行することができます。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Minikubeの機能
@ -441,4 +441,4 @@ Minikubeの詳細については、[proposal](https://git.k8s.io/community/contr
コントリビューションや質問、コメントは歓迎・奨励されています! Minikubeの開発者は[Slack](https://kubernetes.slack.com)の#minikubeチャンネルにいます(Slackへの招待状は[こちら](http://slack.kubernetes.io/))。[kubernetes-dev Google Groupsメーリングリスト](https://groups.google.com/forum/#!forum/kubernetes-dev)もあります。メーリングリストに投稿する際は件名の最初に "minikube: " をつけてください。
{{% /capture %}}

10
content/ja/docs/setup/production-environment/container-runtimes.md
View File

@ -1,16 +1,16 @@
---
title: CRIのインストール
content_template: templates/concept
content_type: concept
weight: 10
---
{{% capture overview %}}
<!-- overview -->
{{< feature-state for_k8s_version="v1.6" state="stable" >}}
Podのコンテナを実行するために、Kubernetesはコンテナランタイムを使用します。
様々なランタイムのインストール手順は次のとおりです。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
{{< caution >}}
@ -253,4 +253,4 @@ systemctl start containerd
詳細については[Fraktiのクイックスタートガイド](https://github.com/kubernetes/frakti#quickstart)を参照してください。
{{% /capture %}}

10
content/ja/docs/setup/production-environment/on-premises-vm/cloudstack.md
View File

@ -1,9 +1,9 @@
---
title: Cloudstack
content_template: templates/concept
content_type: concept
---
{{% capture overview %}}
<!-- overview -->
[CloudStack](https://cloudstack.apache.org/) is a software to build public and private clouds based on hardware virtualization principles (traditional IaaS). To deploy Kubernetes on CloudStack there are several possibilities depending on the Cloud being used and what images are made available. CloudStack also has a vagrant plugin available, hence Vagrant could be used to deploy Kubernetes either using the existing shell provisioner or using new Salt based recipes.
@ -11,9 +11,9 @@ content_template: templates/concept
This guide uses a single [Ansible playbook](https://github.com/apachecloudstack/k8s), which is completely automated and can deploy Kubernetes on a CloudStack based Cloud using CoreOS images. The playbook, creates an ssh key pair, creates a security group and associated rules and finally starts coreOS instances configured via cloud-init.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## 前提条件
@ -115,4 +115,4 @@ IaaS Provider | Config. Mgmt | OS | Networking | Docs
-------------------- | ------------ | ------ | ---------- | --------------------------------------------- | ---------| ----------------------------
CloudStack | Ansible | CoreOS | flannel | [docs](/docs/setup/production-environment/on-premises-vm/cloudstack/) | | Community ([@Guiques](https://github.com/ltupin/))
{{% /capture %}}

10
content/ja/docs/setup/production-environment/on-premises-vm/dcos.md
View File

@ -1,9 +1,9 @@
---
title: DC/OS上のKubernetes
content_template: templates/concept
content_type: concept
---
{{% capture overview %}}
<!-- overview -->
Mesosphereは[DC/OS](https://mesosphere.com/product/)上にKubernetesを構築する為の簡単な選択肢を提供します。それは
@ -14,12 +14,12 @@ Mesosphereは[DC/OS](https://mesosphere.com/product/)上にKubernetesを構築
です。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## 公式Mesosphereガイド
DC/OS入門の正規のソースは[クイックスタートリポジトリ](https://github.com/mesosphere/dcos-kubernetes-quickstart)にあります。
{{% /capture %}}

10
content/ja/docs/setup/production-environment/on-premises-vm/ovirt.md
View File

@ -1,15 +1,15 @@
---
title: oVirt
content_template: templates/concept
content_type: concept
---
{{% capture overview %}}
<!-- overview -->
oVirt is a virtual datacenter manager that delivers powerful management of multiple virtual machines on multiple hosts. Using KVM and libvirt, oVirt can be installed on Fedora, CentOS, or Red Hat Enterprise Linux hosts to set up and manage your virtual data center.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## oVirtクラウドプロバイダーによる構築
@ -65,4 +65,4 @@ IaaS Provider | Config. Mgmt | OS | Networking | Docs
-------------------- | ------------ | ------ | ---------- | --------------------------------------------- | ---------| ----------------------------
oVirt | | | | [docs](/docs/setup/production-environment/on-premises-vm/ovirt/) | | Community ([@simon3z](https://github.com/simon3z))
{{% /capture %}}

15
content/ja/docs/setup/production-environment/tools/kops.md
View File

@ -1,10 +1,10 @@
---
title: kopsを使ったAWS上でのKubernetesのインストール
content_template: templates/concept
content_type: concept
weight: 20
---
{{% capture overview %}}
<!-- overview -->
This quickstart shows you how to easily install a Kubernetes cluster on AWS.
It uses a tool called [`kops`](https://github.com/kubernetes/kops).
@ -21,9 +21,9 @@ kops is an opinionated provisioning system:
If your opinions differ from these you may prefer to build your own cluster using [kubeadm](/docs/admin/kubeadm/) as
a building block. kops builds on the kubeadm work.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## クラスタの作成
@ -224,12 +224,13 @@ See the [list of add-ons](/docs/concepts/cluster-administration/addons/) to expl
* Slack Channel: [#kops-users](https://kubernetes.slack.com/messages/kops-users/)
* [GitHub Issues](https://github.com/kubernetes/kops/issues)
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* Learn more about Kubernetes [concepts](/docs/concepts/) and [`kubectl`](/docs/user-guide/kubectl-overview/).
* Learn about `kops` [advanced usage](https://github.com/kubernetes/kops)
* See the `kops` [docs](https://github.com/kubernetes/kops) section for tutorials, best practices and advanced configuration options.
{{% /capture %}}

10
content/ja/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md
View File

@ -1,10 +1,10 @@
---
title: kubeadmを使ったコントロールプレーンの設定のカスタマイズ
content_template: templates/concept
content_type: concept
weight: 40
---
{{% capture overview %}}
<!-- overview -->
{{< feature-state for_k8s_version="1.12" state="stable" >}}
@ -27,9 +27,9 @@ kubeadmの`ClusterConfiguration`オブジェクトはAPIServer、ControllerManag
`kubeadm config print init-defaults`を実行し、選択したファイルに出力を保存することで、デフォルト値で`ClusterConfiguration`オブジェクトを生成できます。
{{< /note >}}
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## APIServerフラグ
@ -80,4 +80,4 @@ scheduler:
kubeconfig: /home/johndoe/kubeconfig.yaml
```
{{% /capture %}}

13
content/ja/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md
View File

@ -1,10 +1,10 @@
---
title: kubeadmを使用したシングルコントロールプレーンクラスターの作成
content_template: templates/task
content_type: task
weight: 30
---
{{% capture overview %}}
<!-- overview -->
<img src="https://raw.githubusercontent.com/kubernetes/kubeadm/master/logos/stacked/color/kubeadm-stacked-color.png" align="right" width="150px">**kubeadm** helps you bootstrap a minimum viable Kubernetes cluster that conforms to best practices. With kubeadm, your cluster should pass [Kubernetes Conformance tests](https://kubernetes.io/blog/2017/10/software-conformance-certification). Kubeadm also supports other cluster
lifecycle functions, such as upgrades, downgrade, and managing [bootstrap tokens](/ja/docs/reference/access-authn-authz/bootstrap-tokens/).
@ -53,9 +53,10 @@ timeframe; which also applies to `kubeadm`.
| v1.15.x | June 2019 | March 2020 |
| v1.16.x | September 2019 | June 2020 |
{{% /capture %}}
{{% capture prerequisites %}}
## {{% heading "prerequisites" %}}
- One or more machines running a deb/rpm-compatible OS, for example Ubuntu or CentOS
- 2 GB or more of RAM per machine. Any less leaves little room for your
@ -64,9 +65,9 @@ timeframe; which also applies to `kubeadm`.
- Full network connectivity among all machines in the cluster. A public or
private network is fine.
{{% /capture %}}
{{% capture steps %}}
<!-- steps -->
## 目的

15
content/ja/docs/setup/production-environment/tools/kubeadm/ha-topology.md
View File

@ -1,10 +1,10 @@
---
title: Options for Highly Available topology
content_template: templates/concept
content_type: concept
weight: 50
---
{{% capture overview %}}
<!-- overview -->
This page explains the two options for configuring the topology of your highly available (HA) Kubernetes clusters.
@ -15,9 +15,9 @@ You can set up an HA cluster:
You should carefully consider the advantages and disadvantages of each topology before setting up an HA cluster.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Stacked etcd topology
@ -60,10 +60,11 @@ A minimum of three hosts for control plane nodes and three hosts for etcd nodes
![External etcd topology](/images/kubeadm/kubeadm-ha-topology-external-etcd.svg)
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
- [Set up a highly available cluster with kubeadm](/ja/docs/setup/production-environment/tools/kubeadm/high-availability/)
{{% /capture %}}

15
content/ja/docs/setup/production-environment/tools/kubeadm/high-availability.md
View File

@ -1,10 +1,10 @@
---
title: kubeadmを使用した高可用性クラスターの作成
content_template: templates/task
content_type: task
weight: 60
---
{{% capture overview %}}
<!-- overview -->
このページでは、kubeadmを使用して、高可用性クラスターを作成する、2つの異なるアプローチを説明します:
@ -23,9 +23,10 @@ alpha feature gateである`HighAvailability`はv1.12で非推奨となり、v1.
このページはクラウド上でクラスターを構築することには対応していません。ここで説明されているどちらのアプローチも、クラウド上で、LoadBalancerタイプのServiceオブジェクトや、動的なPersistentVolumeを利用して動かすことはできません。
{{< /caution >}}
{{% /capture %}}
{{% capture prerequisites %}}
## {{% heading "prerequisites" %}}
どちらの方法でも、以下のインフラストラクチャーが必要です:
@ -44,9 +45,9 @@ alpha feature gateである`HighAvailability`はv1.12で非推奨となり、v1.
以下の例では、CalicoをPodネットワーキングプロバイダーとして使用します。別のネットワーキングプロバイダーを使用する場合、必要に応じてデフォルトの値を変更してください。
{{< /note >}}
{{% /capture %}}
{{% capture steps %}}
<!-- steps -->
## 両手順における最初のステップ
@ -299,4 +300,4 @@ Podネットワークをインストールするには、[こちらの手順に
`kubeadm init`コマンドから返されたコマンドを利用して、workerノードをクラスターに参加させることが可能です。workerノードには、`--experimental-control-plane`フラグを追加する必要はありません。
{{% /capture %}}

18
content/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md
View File

@ -1,6 +1,6 @@
---
title: kubeadmのインストール
content_template: templates/task
content_type: task
weight: 20
card:
name: setup
@ -8,14 +8,15 @@ card:
title: kubeadmセットアップツールのインストール
---
{{% capture overview %}}
<!-- overview -->
<img src="https://raw.githubusercontent.com/kubernetes/kubeadm/master/logos/stacked/color/kubeadm-stacked-color.png" align="right" width="150px">
このページでは`kubeadm`コマンドをインストールする方法を示します。このインストール処理実行後にkubeadmを使用してクラスターを作成する方法については、[kubeadmを使用したシングルマスタークラスターの作成](/ja/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/)を参照してください。
{{% /capture %}}
{{% capture prerequisites %}}
## {{% heading "prerequisites" %}}
* 次のいずれかが動作しているマシンが必要です
- Ubuntu 16.04+
@ -32,9 +33,9 @@ card:
* マシン内の特定のポートが開いていること。詳細は[ここ](#必須ポートの確認)を参照してください。
* Swapがオフであること。kubeletが正常に動作するためにはswapは**必ず**オフでなければなりません。
{{% /capture %}}
{{% capture steps %}}
<!-- steps -->
## MACアドレスとproduct_uuidが全てのノードでユニークであることの検証
@ -269,8 +270,9 @@ CRI-Oやcontainerdといった他のコンテナランタイムのcgroup driver
kubeadmで問題が発生した場合は、[トラブルシューティング](/ja/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/)を参照してください。
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* [kubeadmを使用したシングルコントロールプレーンクラスターの作成](/ja/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/)
{{% /capture %}}

10
content/ja/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md
View File

@ -1,10 +1,10 @@
---
title: kubeadmを使用したクラスター内の各kubeletの設定
content_template: templates/concept
content_type: concept
weight: 80
---
{{% capture overview %}}
<!-- overview -->
{{< feature-state for_k8s_version="1.11" state="stable" >}}
@ -24,9 +24,9 @@ characteristics of a given machine, such as OS, storage, and networking. You can
of your kubelets manually, but [kubeadm now provides a `KubeletConfiguration` API type for managing your
kubelet configurations centrally](#configure-kubelets-using-kubeadm).
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Kubeletの設定パターン
@ -197,4 +197,4 @@ The DEB and RPM packages shipped with the Kubernetes releases are:
| `kubernetes-cni` | Installs the official CNI binaries into the `/opt/cni/bin` directory. |
| `cri-tools` | Installs the `/usr/bin/crictl` binary from the [cri-tools git repository](https://github.com/kubernetes-incubator/cri-tools). |
{{% /capture %}}

10
content/ja/docs/setup/production-environment/tools/kubeadm/self-hosting.md
View File

@ -1,10 +1,10 @@
---
title: Configuring your kubernetes cluster to self-host the control plane
content_template: templates/concept
content_type: concept
weight: 100
---
{{% capture overview %}}
<!-- overview -->
### Self-hosting the Kubernetes control plane {#self-hosting}
@ -17,9 +17,9 @@ configured in the kubelet via static files.
To create a self-hosted cluster see the
[kubeadm alpha selfhosting pivot](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/#cmd-selfhosting) command.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
#### Caveats
@ -65,4 +65,4 @@ In summary, `kubeadm alpha selfhosting` works as follows:
1. When the original static control plane stops, the new self-hosted control
plane is able to bind to listening ports and become active.
{{% /capture %}}

20
content/ja/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md
View File

@ -1,10 +1,10 @@
---
title: kubeadmを使用した高可用性etcdクラスターの作成
content_template: templates/task
content_type: task
weight: 70
---
{{% capture overview %}}
<!-- overview -->
Kubeadm defaults to running a single member etcd cluster in a static pod managed
by the kubelet on the control plane node. This is not a high availability setup
@ -13,9 +13,10 @@ becoming unavailable. This task walks through the process of creating a high
availability etcd cluster of three members that can be used as an external etcd
when using kubeadm to set up a kubernetes cluster.
{{% /capture %}}
{{% capture prerequisites %}}
## {{% heading "prerequisites" %}}
* Three hosts that can talk to each other over ports 2379 and 2380. This
document assumes these default ports. However, they are configurable through
@ -26,9 +27,9 @@ when using kubeadm to set up a kubernetes cluster.
[toolbox]: /docs/setup/production-environment/tools/kubeadm/install-kubeadm/
{{% /capture %}}
{{% capture steps %}}
<!-- steps -->
## クラスターの構築
@ -251,14 +252,15 @@ this example.
- Set `${ETCD_TAG}` to the version tag of your etcd image. For example `v3.2.24`.
- Set `${HOST0}`to the IP address of the host you are testing.
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
Once you have a working 3 member etcd cluster, you can continue setting up a
highly available control plane using the [external etcd method with
kubeadm](/ja/docs/setup/production-environment/tools/kubeadm/high-availability/).
{{% /capture %}}

10
content/ja/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md
View File

@ -1,10 +1,10 @@
---
title: kubeadmのトラブルシューティング
content_template: templates/concept
content_type: concept
weight: 90
---
{{% capture overview %}}
<!-- overview -->
As with any program, you might run into an error installing or running kubeadm.
This page lists some common failure scenarios and have provided steps that can help you understand and fix the problem.
@ -18,9 +18,9 @@ If your problem is not listed below, please follow the following steps:
- If you are unsure about how kubeadm works, you can ask on [Slack](http://slack.k8s.io/) in #kubeadm, or open a question on [StackOverflow](https://stackoverflow.com/questions/tagged/kubernetes). Please include
relevant tags like `#kubernetes` and `#kubeadm` so folks can help you.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## インストール中に`ebtables`もしくは他の似たような実行プログラムが見つからない
@ -318,4 +318,4 @@ There are at least two workarounds:
```bash
kubectl taint nodes NODE_NAME role.kubernetes.io/master:NoSchedule-
```
{{% /capture %}}

15
content/ja/docs/setup/production-environment/tools/kubespray.md
View File

@ -1,10 +1,10 @@
---
title: kubesprayを使ったオンプレミス/クラウドプロバイダへのKubernetesのインストール
content_template: templates/concept
content_type: concept
weight: 30
---
{{% capture overview %}}
<!-- overview -->
This quickstart helps to install a Kubernetes cluster hosted on GCE, Azure, OpenStack, AWS, vSphere, Oracle Cloud Infrastructure (Experimental) or Baremetal with [Kubespray](https://github.com/kubernetes-incubator/kubespray).
@ -23,9 +23,9 @@ Kubespray is a composition of [Ansible](http://docs.ansible.com/) playbooks, [in
To choose a tool which best fits your use case, read [this comparison](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/comparisons.md) to [kubeadm](/docs/admin/kubeadm/) and [kops](../kops).
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## クラスタの作成
@ -112,10 +112,11 @@ When running the reset playbook, be sure not to accidentally target your product
* Slack Channel: [#kubespray](https://kubernetes.slack.com/messages/kubespray/)
* [GitHub Issues](https://github.com/kubernetes-incubator/kubespray/issues)
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
Check out planned work on Kubespray's [roadmap](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/roadmap.md).
{{% /capture %}}

15
content/ja/docs/setup/production-environment/turnkey/aws.md
View File

@ -1,15 +1,16 @@
---
title: AWS EC2上でKubernetesを動かす
content_template: templates/task
content_type: task
---
{{% capture overview %}}
<!-- overview -->
このページでは、AWS上でKubernetesクラスターをインストールする方法について説明します。
{{% /capture %}}
{{% capture prerequisites %}}
## {{% heading "prerequisites" %}}
AWS上でKubernetesクラスターを作成するには、AWSからアクセスキーIDおよびシークレットアクセスキーを入手する必要があります。
@ -25,9 +26,9 @@ AWS上でKubernetesクラスターを作成するには、AWSからアクセス
* [KubeOne](https://github.com/kubermatic/kubeone)は可用性の高いKubernetesクラスターを作成、アップグレード、管理するための、オープンソースのライフサイクル管理ツールです。
{{% /capture %}}
{{% capture steps %}}
<!-- steps -->
## クラスターの始まり
@ -84,4 +85,4 @@ AWS | KubeOne | Ubuntu, CoreOS, CentOS | canal, weave
Kubernetesクラスターの利用と管理に関する詳細は、[Kubernetesドキュメント](/ja/docs/)を参照してください。
{{% /capture %}}

15
content/ja/docs/setup/production-environment/turnkey/gce.md
View File

@ -1,15 +1,16 @@
---
title: Google Compute Engine上でKubernetesを動かす
content_template: templates/task
content_type: task
---
{{% capture overview %}}
<!-- overview -->
The example below creates a Kubernetes cluster with 3 worker node Virtual Machines and a master Virtual Machine (i.e. 4 VMs in your cluster). This cluster is set up and controlled from your workstation (or wherever you find convenient).
{{% /capture %}}
{{% capture prerequisites %}}
## {{% heading "prerequisites" %}}
If you want a simplified getting started experience and GUI for managing clusters, please consider trying [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) for hosted cluster installation and management.
@ -31,9 +32,9 @@ If you want to use custom binaries or pure open source Kubernetes, please contin
1. Make sure you can start up a GCE VM from the command line. At least make sure you can do the [Create an instance](https://cloud.google.com/compute/docs/instances/#startinstancegcloud) part of the GCE Quickstart.
1. Make sure you can SSH into the VM without interactive prompts. See the [Log in to the instance](https://cloud.google.com/compute/docs/instances/#sshing) part of the GCE Quickstart.
{{% /capture %}}
{{% capture steps %}}
<!-- steps -->
## クラスターの起動
@ -220,4 +221,4 @@ GCE | Saltstack | Debian | GCE | [docs](/ja/docs/set
Please see the [Kubernetes docs](/ja/docs/) for more details on administering
and using a Kubernetes cluster.
{{% /capture %}}

10
content/ja/docs/setup/production-environment/turnkey/stackpoint.md
View File

@ -1,15 +1,15 @@
---
title: Stackpoint.ioを利用して複数のクラウド上でKubernetesを動かす
content_template: templates/concept
content_type: concept
---
{{% capture overview %}}
<!-- overview -->
[StackPointCloud](https://stackpoint.io/) is the universal control plane for Kubernetes Anywhere. StackPointCloud allows you to deploy and manage a Kubernetes cluster to the cloud provider of your choice in 3 steps using a web-based interface.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## AWS
@ -184,4 +184,4 @@ To create a Kubernetes cluster on Packet, you will need a Packet API Key.
For information on using and managing a Kubernetes cluster on Packet, consult [the official documentation](/ja/docs/home/).
{{% /capture %}}

15
content/ja/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md
View File

@ -1,16 +1,16 @@
---
title: Intro to Windows support in Kubernetes
content_template: templates/concept
content_type: concept
weight: 65
---
{{% capture overview %}}
<!-- overview -->
Windows applications constitute a large portion of the services and applications that run in many organizations. [Windows containers](https://aka.ms/windowscontainers) provide a modern way to encapsulate processes and package dependencies, making it easier to use DevOps practices and follow cloud native patterns for Windows applications. Kubernetes has become the defacto standard container orchestrator, and the release of Kubernetes 1.14 includes production support for scheduling Windows containers on Windows nodes in a Kubernetes cluster, enabling a vast ecosystem of Windows applications to leverage the power of Kubernetes. Organizations with investments in Windows-based applications and Linux-based applications don't have to look for separate orchestrators to manage their workloads, leading to increased operational efficiencies across their deployments, regardless of operating system.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Windows containers in Kubernetes
@ -530,9 +530,10 @@ If filing a bug, please include detailed information about how to reproduce the
* [Relevant logs](https://github.com/kubernetes/community/blob/master/sig-windows/CONTRIBUTING.md#gathering-logs)
* Tag the issue sig/windows by commenting on the issue with `/sig windows` to bring it to a SIG-Windows member's attention
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
We have a lot of features in our roadmap. An abbreviated high level list is included below, but we encourage you to view our [roadmap project](https://github.com/orgs/kubernetes/projects/8) and help us make Windows support better by [contributing](https://github.com/kubernetes/community/blob/master/sig-windows/).
@ -584,4 +585,4 @@ Kubeadm is becoming the de facto standard for users to deploy a Kubernetes clust
* More CNIs
* More Storage Plugins
{{% /capture %}}

10
content/ja/docs/setup/production-environment/windows/user-guide-windows-containers.md
View File

@ -1,16 +1,16 @@
---
title: Guide for scheduling Windows containers in Kubernetes
content_template: templates/concept
content_type: concept
weight: 75
---
{{% capture overview %}}
<!-- overview -->
Windows applications constitute a large portion of the services and applications that run in many organizations. This guide walks you through the steps to configure and deploy a Windows container in Kubernetes.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Objectives
@ -134,4 +134,4 @@ tolerations:
effect: "NoSchedule"
```
{{% /capture %}}

10
content/ja/docs/setup/production-environment/windows/user-guide-windows-nodes.md
View File

@ -1,19 +1,19 @@
---
title: Guide for adding Windows Nodes in Kubernetes
content_template: templates/concept
content_type: concept
weight: 70
---
{{% capture overview %}}
<!-- overview -->
The Kubernetes platform can now be used to run both Linux and Windows containers. One or more Windows nodes can be registered to a cluster. This guide shows how to:
* Register a Windows node to the cluster
* Configure networking so pods on Linux and Windows can communicate
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Before you begin
@ -261,4 +261,4 @@ Kubeadm is becoming the de facto standard for users to deploy a Kubernetes clust
Now that you've configured a Windows worker in your cluster to run Windows containers you may want to add one or more Linux nodes as well to run Linux containers. You are now ready to schedule Windows containers on your cluster.
{{% /capture %}}

10
content/ja/docs/setup/release/building-from-source.md
View File

@ -1,18 +1,18 @@
---
title: リリースのビルド
content_template: templates/concept
content_type: concept
card:
name: download
weight: 20
title: リリースのビルド
---
{{% capture overview %}}
<!-- overview -->
ソースコードからリリースをビルドすることもできますし、既にビルドされたリリースをダウンロードすることも可能です。Kubernetesを開発する予定が無いのであれば、[リリースノート](/docs/setup/release/notes/)内にて既にビルドされたバージョンを使用することを推奨します。
Kubernetes のソースコードは[kubernetes/kubernetes](https://github.com/kubernetes/kubernetes)のリポジトリからダウンロードすることが可能です。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## ソースからのビルド
単にソースからリリースをビルドするだけであれば、完全なGOの環境を準備する必要はなく、全てのビルドはDockerコンテナの中で行われます。
@ -27,4 +27,4 @@ make release
リリース手段の詳細な情報はkubernetes/kubernetes内の[`build`](http://releases.k8s.io/{{< param "githubbranch" >}}/build/)ディレクトリを参照して下さい。
{{% /capture %}}

8
content/ja/docs/setup/release/version-skew-policy.md
View File

@ -1,14 +1,14 @@
---
title: Kubernetesバージョンとバージョンスキューサポートポリシー
content_template: templates/concept
content_type: concept
weight: 30
---
{{% capture overview %}}
<!-- overview -->
このドキュメントでは、さまざまなKubernetesコンポーネント間でサポートされる最大のバージョンの差異（バージョンスキュー）について説明します。特定のクラスターデプロイツールは、バージョンの差異に追加の制限を加える場合があります。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## サポートされるバージョン

15
content/ja/docs/tasks/_index.md
View File

@ -2,19 +2,19 @@
title: タスク
main_menu: true
weight: 50
content_template: templates/concept
content_type: concept
---
{{< toc >}}
{{% capture overview %}}
<!-- overview -->
Kubernetesドキュメントのこのセクションには、個々のタスクの実行方法を示すページが含まれています。
タスクページは、通常、短い手順を実行することにより、1つのことを行う方法を示します。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Web UI (ダッシュボード)
@ -76,10 +76,11 @@ StatefulSetのスケーリング、削除、デバッグなど、ステートフ
クラスター内のスケジュール可能なリソースとしてHuge Pageを構成およびスケジュールします。
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
タスクページを作成する場合は、[ドキュメントのPull Requestの作成](/docs/home/contribute/create-pull-request/)を参照してください。
{{% /capture %}}

24
content/ja/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md
View File

@ -1,25 +1,26 @@
---
title: 共有ボリュームを使用して同じPod内のコンテナ間で通信する
content_template: templates/task
content_type: task
weight: 110
---
{{% capture overview %}}
<!-- overview -->
このページでは、ボリュームを使用して、同じPodで実行されている2つのコンテナ間で通信する方法を示します。
コンテナ間で[プロセス名前空間を共有する](/ja/docs/tasks/configure-pod-container/share-process-namespace/)ことにより、プロセスが通信できるようにする方法も参照してください。
{{% /capture %}}
{{% capture prerequisites %}}
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
{{% /capture %}}
{{% capture steps %}}
<!-- steps -->
## 2つのコンテナを実行するPodの作成
@ -105,10 +106,10 @@ debianコンテナがnginxルートディレクトリに`index.html`ファイル
Hello from the debian container
{{% /capture %}}
{{% capture discussion %}}
<!-- discussion -->
## 議論
@ -121,10 +122,11 @@ Podが複数のコンテナを持つことができる主な理由は、プラ
この演習のボリュームは、コンテナがポッドの寿命中に通信する方法を提供します。
Podを削除して再作成すると、共有ボリュームに保存されているデータはすべて失われます。
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* [複合コンテナのパターン](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)の詳細
@ -138,7 +140,7 @@ Podを削除して再作成すると、共有ボリュームに保存されて
* [Pod](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)を参照
{{% /capture %}}

19
content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md
View File

@ -1,6 +1,6 @@
---
title: 複数のクラスターへのアクセスを設定する
content_template: templates/task
content_type: task
weight: 30
card:
name: tasks
@ -8,7 +8,7 @@ card:
---
{{% capture overview %}}
<!-- overview -->
ここでは、設定ファイルを使って複数のクラスターにアクセスする方法を紹介します。クラスター、ユーザー、contextの情報を一つ以上の設定ファイルにまとめることで、`kubectl config use-context`のコマンドを使ってクラスターを素早く切り替えることができます。
@ -16,15 +16,16 @@ card:
クラスターへのアクセスを設定するファイルを、*kubeconfig* ファイルと呼ぶことがあります。これは設定ファイルの一般的な呼び方です。`kubeconfig`という名前のファイルが存在するわけではありません。
{{< /note >}}
{{% /capture %}}
{{% capture prerequisites %}}
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
{{% /capture %}}
{{% capture steps %}}
<!-- steps -->
## クラスター、ユーザー、contextを設定する
@ -325,11 +326,11 @@ Windows PowerShell
$Env:KUBECONFIG=$ENV:KUBECONFIG_SAVED
```
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* [kubeconfigファイルを使ってクラスターへのアクセスを管理する](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
* [kubectl config](/docs/reference/generated/kubectl/kubectl-commands#config)
{{% /capture %}}

25
content/ja/docs/tasks/access-application-cluster/connecting-frontend-backend.md
View File

@ -1,38 +1,40 @@
---
title: Serviceを使用してフロントエンドをバックエンドに接続する
content_template: templates/tutorial
content_type: tutorial
weight: 70
---
{{% capture overview %}}
<!-- overview -->
このタスクでは、フロントエンドとバックエンドのマイクロサービスを作成する方法を示します。
バックエンドのマイクロサービスは挨拶です。
フロントエンドとバックエンドは、Kubernetes {{< glossary_tooltip term_id="service" >}}オブジェクトを使用して接続されます。
{{% /capture %}}
{{% capture objectives %}}
## {{% heading "objectives" %}}
* {{< glossary_tooltip term_id="deployment" >}}オブジェクトを使用してマイクロサービスを作成および実行します。
* フロントエンドを経由してトラフィックをバックエンドにルーティングします。
* Serviceオブジェクトを使用して、フロントエンドアプリケーションをバックエンドアプリケーションに接続します。
{{% /capture %}}
{{% capture prerequisites %}}
## {{% heading "prerequisites" %}}
* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
* このタスクでは[Serviceで外部ロードバランサー](/docs/tasks/access-application-cluster/create-external-load-balancer/)を使用しますが、外部ロードバランサーの使用がサポートされている環境である必要があります。
ご使用の環境がこれをサポートしていない場合は、代わりにタイプ[NodePort](/ja/docs/concepts/services-networking/service/#nodeport)のServiceを使用できます。
{{% /capture %}}
{{% capture lessoncontent %}}
<!-- lessoncontent -->
### Deploymentを使用したバックエンドの作成
@ -184,14 +186,15 @@ curl http://${EXTERNAL_IP} # これを前に見たEXTERNAL-IPに置き換えま
{"message":"Hello"}
```
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* [Service](/ja/docs/concepts/services-networking/service/)の詳細
* [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/)の詳細
{{% /capture %}}

30
content/ja/docs/tasks/access-application-cluster/service-access-application-cluster.md
View File

@ -1,34 +1,36 @@
---
title: Serviceを利用したクラスター内のアプリケーションへのアクセス
content_template: templates/tutorial
content_type: tutorial
weight: 60
---
{{% capture overview %}}
<!-- overview -->
ここでは、クラスター内で稼働しているアプリケーションに外部からアクセスするために、KubernetesのServiceオブジェクトを作成する方法を紹介します。
例として、2つのインスタンスから成るアプリケーションへのロードバランシングを扱います。
{{% /capture %}}
{{% capture prerequisites %}}
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
{{% /capture %}}
{{% capture objectives %}}
## {{% heading "objectives" %}}
* 2つのHellow Worldアプリケーションを稼働させる。
* Nodeのポートを公開するServiceオブジェクトを作成する。
* 稼働しているアプリケーションにアクセスするためにServiceオブジェクトを使用する。
{{% /capture %}}
{{% capture lessoncontent %}}
<!-- lessoncontent -->
## 2つのPodから成るアプリケーションのServiceを作成
@ -118,10 +120,11 @@ weight: 60
[service configuration file](/ja/docs/concepts/services-networking/service/)
を使用してServiceを作成することもできます。
{{% /capture %}}
{{% capture cleanup %}}
## {{% heading "cleanup" %}}
Serviceを削除するには、以下のコマンドを実行します:
@ -131,12 +134,13 @@ Hello Worldアプリケーションが稼働しているDeployment、ReplicaSet
kubectl delete deployment hello-world
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
詳細は
[serviceを利用してアプリケーションと接続する](/docs/concepts/services-networking/connect-applications-service/)
を確認してください。
{{% /capture %}}

10
content/ja/docs/tasks/administer-cluster/developing-cloud-controller-manager.md
View File

@ -1,9 +1,9 @@
---
title: クラウドコントローラーマネージャーの開発
content_template: templates/concept
content_type: concept
---
{{% capture overview %}}
<!-- overview -->
{{< feature-state for_k8s_version="v1.11" state="beta" >}}
今後のリリースで、クラウドコントローラーマネージャーはKubernetesを任意のクラウドと統合するための良い方法となります。これによりクラウドプロバイダーはKubernetesのコアリリースサイクルから独立して機能を開発できるようになります。
@ -15,10 +15,10 @@ content_template: templates/concept
実装の詳細をもう少し掘り下げてみましょう。すべてのクラウドコントローラーマネージャーはKubernetesコアからパッケージをインポートします。唯一の違いは、各プロジェクトが利用可能なクラウドプロバイダーの情報(グローバル変数)が更新される場所である[cloudprovider.RegisterCloudProvider](https://github.com/kubernetes/cloud-provider/blob/master/plugins.go#L56-L66)を呼び出すことによって独自のクラウドプロバイダーを登録する点です。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## 開発
@ -36,4 +36,4 @@ Kubernetesには登録されていない独自のクラウドプロバイダー
Kubernetesに登録されているクラウドプロバイダーであれば、[Daemonset](https://kubernetes.io/examples/admin/cloud/ccm-example.yaml) を使ってあなたのクラスターで動かすことができます。詳細については[Kubernetesクラウドコントローラーマネージャードキュメント](/docs/tasks/administer-cluster/running-cloud-controller/)を参照してください。
{{% /capture %}}

18
content/ja/docs/tasks/administer-cluster/enabling-endpointslices.md
View File

@ -1,18 +1,19 @@
---
title: EndpointSliceの有効化
content_template: templates/task
content_type: task
---
{{% capture overview %}}
<!-- overview -->
このページはKubernetesのEndpointSliceの有効化の概要を説明します。
{{% /capture %}}
{{% capture prerequisites %}}
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
{{% /capture %}}
{{% capture steps %}}
<!-- steps -->
## 概要
@ -36,9 +37,10 @@ EndpointSliceコントローラーはクラスター内にEndpointSliceを作成
クラスター内でEndpointSliceを完全に有効にすると、各Endpointsリソースに対応するEndpointSliceリソースが表示されます。既存のEndpointsの機能をサポートすることに加えて、EndpointSliceはトポロジーなどの新しい情報を含める必要があります。これらにより、クラスター内のネットワークエンドポイントのスケーラビリティと拡張性が大きく向上します。
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* [EndpointSlice](/docs/concepts/services-networking/endpoint-slices/)を参照してください。
* [サービスとアプリケーションの接続](/ja/docs/concepts/services-networking/connect-applications-service/)を参照してください。
{{% /capture %}}

10
content/ja/docs/tasks/administer-cluster/running-cloud-controller.md
View File

@ -1,9 +1,9 @@
---
title: Kubernetesクラウドコントローラーマネージャー
content_template: templates/concept
content_type: concept
---
{{% capture overview %}}
<!-- overview -->
{{< feature-state state="beta" >}}
@ -11,10 +11,10 @@ Kubernetes v1.6では`cloud-controller-manager`という新しいバイナリが
`cloud-controller-manager`は、[cloudprovider.Interface](https://github.com/kubernetes/cloud-provider/blob/master/cloud.go)を満たす任意のクラウドプロバイダーと接続できます。下位互換性のためにKubernetesのコアプロジェクトで提供される[cloud-controller-manager](https://github.com/kubernetes/kubernetes/tree/master/cmd/cloud-controller-manager)は`kube-controller-manager`と同じクラウドライブラリを使用します。Kubernetesのコアリポジトリで既にサポートされているクラウドプロバイダーは、Kubernetesリポジトリにあるcloud-controller-managerを使用してKubernetesのコアから移行することが期待されています。今後のKubernetesのリリースでは、すべてのクラウドコントローラーマネージャーはsigリードまたはクラウドベンダーが管理するKubernetesのコアプロジェクトの外で開発される予定です。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## 運用
@ -87,4 +87,4 @@ Kubernetesのコアリポジトリにないクラウドコントローラーマ
独自のクラウドコントローラーマネージャーを構築および開発するには[クラウドコントローラーマネージャーの開発](/docs/tasks/administer-cluster/developing-cloud-controller-manager.md)のドキュメントを参照してください。
{{% /capture %}}

20
content/ja/docs/tasks/configure-pod-container/assign-cpu-resource.md
View File

@ -1,17 +1,18 @@
---
title: コンテナおよびPodへのCPUリソースの割り当て
content_template: templates/task
content_type: task
weight: 20
---
{{% capture overview %}}
<!-- overview -->
このページでは、CPUの *request* と *limit* をコンテナに割り当てる方法について示します。コンテナは設定された制限を超えてCPUを使用することはできません。システムにCPUの空き時間がある場合、コンテナには要求されたCPUを割り当てられます。
{{% /capture %}}
{{% capture prerequisites %}}
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
@ -38,10 +39,10 @@ NAME
v1beta1.metrics.k8s.io
```
{{% /capture %}}
{{% capture steps %}}
<!-- steps -->
## namespaceの作成
@ -207,9 +208,10 @@ namespaceを削除してください:
kubectl delete namespace cpu-example
```
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
### アプリケーション開発者向け
@ -234,4 +236,4 @@ kubectl delete namespace cpu-example
* [APIオブジェクトのクォータを設定する](/docs/tasks/administer-cluster/quota-api-object/)
{{% /capture %}}

20
content/ja/docs/tasks/configure-pod-container/assign-memory-resource.md
View File

@ -1,17 +1,18 @@
---
title: コンテナおよびPodへのメモリーリソースの割り当て
content_template: templates/task
content_type: task
weight: 10
---
{{% capture overview %}}
<!-- overview -->
このページでは、メモリーの *要求* と *制限* をコンテナに割り当てる方法について示します。コンテナは要求されたメモリーを確保することを保証しますが、その制限を超えるメモリーの使用は許可されません。
{{% /capture %}}
{{% capture prerequisites %}}
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
@ -38,9 +39,9 @@ NAME
v1beta1.metrics.k8s.io
```
{{% /capture %}}
{{% capture steps %}}
<!-- steps -->
## namespaceの作成
@ -288,9 +289,10 @@ namespaceを削除してください。これにより、今回のタスクで
kubectl delete namespace mem-example
```
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
### アプリケーション開発者向け
@ -314,7 +316,7 @@ kubectl delete namespace mem-example
* [APIオブジェクトのクォータを設定する](/docs/tasks/administer-cluster/quota-api-object/)
{{% /capture %}}

24
content/ja/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md
View File

@ -1,24 +1,25 @@
---
title: コンテナライフサイクルイベントへのハンドラー紐付け
content_template: templates/task
content_type: task
weight: 140
---
{{% capture overview %}}
<!-- overview -->
このページでは、コンテナのライフサイクルイベントにハンドラーを紐付けする方法を説明します。KubernetesはpostStartとpreStopイベントをサポートしています。Kubernetesはコンテナの起動直後にpostStartイベントを送信し、コンテナの終了直前にpreStopイベントを送信します。
{{% /capture %}}
{{% capture prerequisites %}}
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
{{% /capture %}}
{{% capture steps %}}
<!-- steps -->
## postStartハンドラーとpreStopハンドラーを定義する
@ -50,11 +51,11 @@ Pod内で実行されているコンテナでシェルを実行します:
Hello from the postStart handler
{{% /capture %}}
{{% capture discussion %}}
<!-- discussion -->
## 議論
@ -70,10 +71,11 @@ Kubernetesは、Podが *終了* したときにのみpreStopイベントを送
この制限は[issue #55087](https://github.com/kubernetes/kubernetes/issues/55807)で追跡されています。
{{< /note >}}
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* [コンテナライフサイクルフック](/ja/docs/concepts/containers/container-lifecycle-hooks/)の詳細
* [Podのライフサイクル](/ja/docs/concepts/workloads/pods/pod-lifecycle/)の詳細
@ -85,6 +87,6 @@ Kubernetesは、Podが *終了* したときにのみpreStopイベントを送
* [コンテナ](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)
* [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)の`terminationGracePeriodSeconds`
{{% /capture %}}

20
content/ja/docs/tasks/configure-pod-container/configure-projected-volume-storage.md
View File

@ -1,23 +1,24 @@
---
title: ストレージにProjectedボリュームを使用するようPodを設定する
content_template: templates/task
content_type: task
weight: 70
---
{{% capture overview %}}
<!-- overview -->
このページでは、[`projected`](/docs/concepts/storage/volumes/#projected)（投影）ボリュームを使用して、既存の複数のボリュームソースを同一ディレクトリ内にマウントする方法を説明します。
現在、`secret`、`configMap`、`downwardAPI`および`serviceAccountToken`ボリュームを投影できます。
{{< note >}}
`serviceAccountToken`はボリュームタイプではありません。
{{< /note >}}
{{% /capture %}}
{{% capture prerequisites %}}
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
{{% /capture %}}
{{% capture steps %}}
<!-- steps -->
## ProjectedボリュームをPodに設定する
この課題では、ローカルファイルからユーザーネームおよびパスワードの{{< glossary_tooltip text="Secret" term_id="secret" >}}を作成します。
@ -73,9 +74,10 @@ kubectl delete pod test-projected-volume
kubectl delete secret user pass
```
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* [`projected`](/docs/concepts/storage/volumes/#projected)ボリュームについてさらに学ぶ
* [all-in-oneボリューム](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/node/all-in-one-volume.md)のデザインドキュメントを読む
{{% /capture %}}

20
content/ja/docs/tasks/configure-pod-container/configure-volume-storage.md
View File

@ -1,10 +1,10 @@
---
title: ストレージにボリュームを使用するPodを構成する
content_template: templates/task
content_type: task
weight: 50
---
{{% capture overview %}}
<!-- overview -->
このページでは、ストレージにボリュームを使用するPodを構成する方法を示します。
@ -13,15 +13,16 @@ weight: 50
コンテナに依存しない、より一貫したストレージを実現するには、[ボリューム](/docs/concepts/storage/volumes/)を使用できます。
これは、キーバリューストア(Redisなど)やデータベースなどのステートフルアプリケーションにとって特に重要です。
{{% /capture %}}
{{% capture prerequisites %}}
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
{{% /capture %}}
{{% capture steps %}}
<!-- steps -->
## Podのボリュームを構成する
@ -120,9 +121,10 @@ weight: 50
kubectl delete pod redis
```
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* [Volume](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volume-v1-core)参照
@ -130,6 +132,6 @@ weight: 50
* `emptyDir`によって提供されるローカルディスクストレージに加えて、Kubernetesは、GCEのPDやEC2のEBSなど、さまざまなネットワーク接続ストレージソリューションをサポートします。これらは、重要なデータに好ましく、ノード上のデバイスのマウントやアンマウントなどの詳細を処理します。詳細は[ボリューム](/docs/concepts/storage/volumes/)を参照してください。
{{% /capture %}}

20
content/ja/docs/tasks/configure-pod-container/quality-service-pod.md
View File

@ -1,25 +1,26 @@
---
title: PodにQuality of Serviceを設定する
content_template: templates/task
content_type: task
weight: 30
---
{{% capture overview %}}
<!-- overview -->
このページでは、特定のQuality of Service (QoS)クラスをPodに割り当てるための設定方法を示します。Kubernetesは、Podのスケジューリングおよび退役を決定するためにQoSクラスを用います。
{{% /capture %}}
{{% capture prerequisites %}}
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
{{% /capture %}}
{{% capture steps %}}
<!-- steps -->
## QoSクラス
@ -222,9 +223,10 @@ namespaceを削除してください:
kubectl delete namespace qos-example
```
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
### アプリケーション開発者向け
@ -248,7 +250,7 @@ kubectl delete namespace qos-example
* [NamespaceにPodのクォータを設定する](/docs/tasks/administer-cluster/quota-pod-namespace/)
* [APIオブジェクトのクォータを設定する](/docs/tasks/administer-cluster/quota-api-object/)
{{% /capture %}}

19
content/ja/docs/tasks/configure-pod-container/share-process-namespace.md
View File

@ -1,11 +1,11 @@
---
title: Pod内のコンテナ間でプロセス名前空間を共有する
min-kubernetes-server-version: v1.10
content_template: templates/task
content_type: task
weight: 160
---
{{% capture overview %}}
<!-- overview -->
{{< feature-state state="stable" for_k8s_version="v1.17" >}}
@ -14,15 +14,16 @@ weight: 160
この機能を使用して、ログハンドラーサイドカーコンテナなどの協調コンテナを構成したり、シェルなどのデバッグユーティリティを含まないコンテナイメージをトラブルシューティングしたりできます。
{{% /capture %}}
{{% capture prerequisites %}}
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
{{% /capture %}}
{{% capture steps %}}
<!-- steps -->
## Podを構成する
@ -86,9 +87,9 @@ events {
worker_connections 1024;
```
{{% /capture %}}
{{% capture discussion %}}
<!-- discussion -->
## プロセス名前空間の共有について理解する
@ -106,6 +107,6 @@ Podは多くのリソースを共有するため、プロセスの名前空間
1. **コンテナファイルシステムは、`/proc/$pid/root`リンクを介してPod内の他のコンテナに表示されます。**
これによりデバッグが容易になりますが、ファイルシステム内の秘密情報はファイルシステムのアクセス許可によってのみ保護されることも意味します。
{{% /capture %}}

19
content/ja/docs/tasks/debug-application-cluster/debug-init-containers.md
View File

@ -1,24 +1,25 @@
---
title: Init Containerのデバッグ
content_template: templates/task
content_type: task
---
{{% capture overview %}}
<!-- overview -->
このページでは、Init Containerの実行に関連する問題を調査する方法を説明します。以下のコマンドラインの例では、Podを`<pod-name>`、Init Containerを`<init-container-1>`および`<init-container-2>`として参照しています。
{{% /capture %}}
{{% capture prerequisites %}}
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
* [Init Container](/docs/concepts/abstractions/init-containers/)の基本を理解しておきましょう。
* [Init Containerを設定](/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container/)しておきましょう。
{{% /capture %}}
{{% capture steps %}}
<!-- steps -->
## Init Containerのステータスを確認する
@ -95,9 +96,9 @@ kubectl logs <pod-name> -c <init-container-2>
シェルスクリプトを実行するInit Containerは、実行時にコマンドを出力します。たとえば、スクリプトの始めに`set -x`を実行することでBashで同じことができます。
{{% /capture %}}
{{% capture discussion %}}
<!-- discussion -->
## Podのステータスを理解する
@ -111,7 +112,7 @@ kubectl logs <pod-name> -c <init-container-2>
`Pending` | PodはまだInit Containerの実行を開始していません。
`PodInitializing` or `Running` | PodはすでにInit Containerの実行を終了しています。
{{% /capture %}}

15
content/ja/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md
View File

@ -1,23 +1,24 @@
---
title: PodとReplicationControllerのデバッグ
content_template: templates/task
content_type: task
---
{{% capture overview %}}
<!-- overview -->
このページでは、PodとReplicationControllerをデバッグする方法を説明します。
{{% /capture %}}
{{% capture prerequisites %}}
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
* [Pod](/ja/docs/concepts/workloads/pods/pod/)と[Podのライフサイクル](/ja/docs/concepts/workloads/pods/pod-lifecycle/)の基本を理解している必要があります。
{{% /capture %}}
{{% capture steps %}}
<!-- steps -->
## Podのデバッグ
@ -122,4 +123,4 @@ Podを作成できない場合は、[上述の手順](#Podのデバッグ)を参
`kubectl describe rc ${CONTROLLER_NAME}`を使用して、レプリケーションコントローラーに関連するイベントを調べることもできます。
{{% /capture %}}

15
content/ja/docs/tasks/debug-application-cluster/debug-service.md
View File

@ -1,18 +1,18 @@
---
content_template: templates/concept
content_type: concept
title: Serviceのデバッグ
---
{{% capture overview %}}
<!-- overview -->
新規にKubernetesをインストールした環境でかなり頻繁に発生する問題は、`Service`が適切に機能しないというものです。
`Deployment`を実行して`Service`を作成したにもかかわらず、アクセスしようとしても応答がありません。
何が問題になっているのかを理解するのに、このドキュメントがきっと役立つでしょう。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## 規則
@ -588,10 +588,11 @@ DNSは動作していて、`iptables`ルールがインストールされてい
[Forum](https://discuss.kubernetes.io)または
[GitHub](https://github.com/kubernetes/kubernetes)でお問い合わせください。
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
詳細については、[トラブルシューティングドキュメント](/docs/troubleshooting/)をご覧ください。
{{% /capture %}}

20
content/ja/docs/tasks/debug-application-cluster/debug-stateful-set.md
View File

@ -1,22 +1,23 @@
---
title: StatefulSetのデバッグ
content_template: templates/task
content_type: task
---
{{% capture overview %}}
<!-- overview -->
このタスクでは、StatefulSetをデバッグする方法を説明します。
{{% /capture %}}
{{% capture prerequisites %}}
## {{% heading "prerequisites" %}}
* Kubernetesクラスターが必要です。また、kubectlコマンドラインツールがクラスターと通信するように設定されている必要があります。
* 調べたいStatefulSetを実行しておきましょう。
{{% /capture %}}
{{% capture steps %}}
<!-- steps -->
## StatefulSetのデバッグ
@ -29,12 +30,13 @@ kubectl get pods -l app=myapp
Podが長期間`Unknown`または`Terminating`の状態になっていることがわかった場合は、それらを処理する方法について[StatefulSet Podsの削除](/docs/tasks/manage-stateful-set/delete-pods/)タスクを参照してください。
[Podのデバッグ](/docs/tasks/debug-application-cluster/debug-pod-replication-controller/)ガイドを使用して、StatefulSet内の個々のPodをデバッグできます。
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
[Init Containerのデバッグ](/ja/docs/tasks/debug-application-cluster/debug-init-containers/)の詳細
{{% /capture %}}

20
content/ja/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md
View File

@ -1,25 +1,26 @@
---
title: Pod障害の原因を特定する
content_template: templates/task
content_type: task
---
{{% capture overview %}}
<!-- overview -->
このページでは、コンテナ終了メッセージの読み書き方法を説明します。
終了メッセージは、致命的なイベントに関する情報を、ダッシュボードや監視ソフトウェアなどのツールで簡単に取得して表示できる場所にコンテナが書き込むための手段を提供します。 ほとんどの場合、終了メッセージに入力した情報も一般的な[Kubernetesログ](/docs/concepts/cluster-administration/logging/)に書き込まれるはずです。
{{% /capture %}}
{{% capture prerequisites %}}
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
{{% /capture %}}
{{% capture steps %}}
<!-- steps -->
## 終了メッセージの書き込みと読み取り
@ -82,15 +83,16 @@ spec:
さらに、ユーザーは追加のカスタマイズをするためにContainerの`terminationMessagePolicy`フィールドを設定できます。このフィールドのデフォルト値は`File`です。これは、終了メッセージが終了メッセージファイルからのみ取得されることを意味します。`terminationMessagePolicy`を`FallbackToLogsOnError`に設定することで、終了メッセージファイルが空でコンテナがエラーで終了した場合に、コンテナログ出力の最後のチャンクを使用するようにKubernetesに指示できます。ログ出力は、2048バイトまたは80行のどちらか小さい方に制限されています。
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* [コンテナ](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)の`terminationMessagePath`フィールド参照
* [ログ取得](/docs/concepts/cluster-administration/logging/)について
* [Goテンプレート](https://golang.org/pkg/text/template/)について
{{% /capture %}}

Some files were not shown because too many files have changed in this diff Show More