add ja pages

2020-05-30 15:47:59 -04:00
parent 74d006a754
commit 283572af58
114 changed files with 900 additions and 793 deletions
@@ -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 %}}
+
@@ -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 %}}
+
@@ -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 %}}
+
@@ -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 %}}
+
@@ -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 %}}
+


@@ -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 %}}
+
@@ -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 %}}
+
@@ -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 %}}
+
@@ -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 %}}
+


@@ -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 %}}
+
@@ -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 %}}
+
@@ -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 %}}
+
@@ -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 %}}
+

@@ -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 %}}
+
@@ -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 %}}
+
@@ -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 %}}
+
@@ -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 %}}
+
@@ -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 %}}
+
@@ -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 %}}
+


@@ -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 %}}
+

@@ -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 %}}
@@ -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 %}}
+
@@ -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 %}}
+
@@ -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 %}}
+
@@ -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 %}}
+
@@ -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 %}}
+
@@ -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 %}}
+
@@ -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 %}}
+
@@ -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 %}}
+
@@ -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 %}}
+


@@ -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 %}}
+
@@ -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 %}}
+
@@ -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 %}}
+
@@ -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 %}}
+
@@ -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 %}}
+
@@ -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 %}}
+
@@ -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 %}}
+
@@ -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 %}}
+
@@ -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 %}}
+
@@ -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 %}}
+



@@ -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 %}}
+
@@ -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 %}}
+

@@ -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 %}}
+
@@ -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 %}}
+
@@ -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 %}}
+
@@ -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 %}}
+
@@ -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 %}}
+
@@ -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 %}}
+