template fix

pull/21746/head
inductor 2020-06-15 03:44:25 +09:00
parent 8207f905f5
commit dbd55b85c1
7 changed files with 31 additions and 54 deletions

View File

@ -1,20 +1,19 @@
---
reviewers:
title: リソースクォータ
content_template: templates/concept
content_type: concept
weight: 10
---
{{% capture overview %}}
<!-- overview -->
複数のユーザーやチームが決められた数のードを持つクラスターを共有しているとき、1つのチームが公平に使えるリソース量を超えて使用するといった問題が出てきます。
リソースクォータはこの問題に対処するための管理者向けツールです。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
`ResourceQuota`オブジェクトによって定義されるリソースクォータは、名前空間ごとの総リソース消費を制限するための制約を提供します。リソースクォータは同じ名前空間のクラスター内でタイプごとに作成できるオブジェクト数や、プロジェクト内のリソースによって消費されるコンピュートリソースの総量を制限できます。
@ -547,10 +546,8 @@ plugins:
[リソースクォータの使用方法の例](/docs/tasks/administer-cluster/quota-api-object/)を参照してください。
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
さらなる情報は[クォータの design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md)を参照してください。
{{% /capture %}}

View File

@ -4,12 +4,11 @@ content_type: concept
weight: 40
---
{{% capture overview %}}
<!-- overview -->
このページでは、Initコンテナについて概観します。Initコンテナとは、{{< glossary_tooltip text="Pod" term_id="pod" >}}内でアプリケーションコンテナの前に実行される特別なコンテナです。
Initコンテナにはアプリケーションコンテナのイメージに存在しないセットアップスクリプトやユーティリティーを含めることができます。
Initコンテナは、Podの仕様のうち`containers`という配列(これがアプリケーションコンテナを示します)と並べて指定します。
{{% /capture %}}
<!-- body -->
## Initコンテナを理解する {#understanding-init-containers}
@ -246,7 +245,7 @@ Podレベルのコントロールグループcgroupsは、スケジュー
* `restartPolicy`が`Always`と設定されているPod内の全てのコンテナが停止され、再起動が行われた場合。およびガーベージコレクションによりInitコンテナの完了記録が失われた場合。
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* [Initコンテナを含むPodの作成](/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container)方法について学ぶ。
* [Initコンテナのデバッグ](/ja/docs/tasks/debug-application-cluster/debug-init-containers/)を行う方法について学ぶ。

View File

@ -1,20 +1,19 @@
---
title: kubectlの概要
content_template: templates/concept
content_type: concept
weight: 20
card:
name: reference
weight: 20
---
{{% capture overview %}}
<!-- overview -->
`kubectl`は、Kubernetesクラスターを制御するためのコマンドラインツールです。`kubectl`は、`$HOME/.kube`ディレクトリにある`config`という名前のファイルを探します。他の[kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)ファイルは、`KUBECONFIG`環境変数を設定するか、[`--kubeconfig`](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)フラグを設定することで指定できます。
この概要では、`kubectl`の構文を扱い、コマンド操作を説明し、一般的な例を示します。サポートされているすべてのフラグやサブコマンドを含め、各コマンドの詳細については、[kubectl](/docs/reference/generated/kubectl/kubectl-commands/)リファレンスドキュメントを参照してください。インストール方法については、[kubectlのインストールおよびセットアップ](/ja/docs/tasks/kubectl/install/)をご覧ください。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## 構文
@ -457,10 +456,8 @@ Current user: plugins-user
プラグインについてより詳しく知りたい場合は、[example cli plugin](https://github.com/kubernetes/sample-cli-plugin)をご覧ください。
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
[kubectl](/docs/reference/generated/kubectl/kubectl-commands/)を使い始めてください。
{{% /capture %}}

View File

@ -1,6 +1,6 @@
---
title: Web UI (Dashboard)
content_template: templates/concept
content_type: concept
weight: 10
card:
name: tasks
@ -8,7 +8,7 @@ card:
title: Web UIダッシュボードを使用する
---
{{% capture overview %}}
<!-- overview -->
ダッシュボードは、WebベースのKubernetesユーザーインターフェイスです。ダッシュボードを使用して、コンテナ化されたアプリケーションをKubernetesクラスターにデプロイしたり、コンテナ化されたアプリケーションをトラブルシューティングしたり、クラスターリソースを管理したりすることができます。ダッシュボードを使用して、クラスター上で実行されているアプリケーションの概要を把握したり、個々のKubernetesリソース(Deployments、Jobs、DaemonSetsなど)を作成または修正したりすることができます。たとえば、Deploymentのスケール、ローリングアップデートの開始、Podの再起動、デプロイウィザードを使用した新しいアプリケーションのデプロイなどが可能です。
@ -16,10 +16,9 @@ card:
![Kubernetes Dashboard UI](/images/docs/ui-dashboard.png)
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## ダッシュボードUIのデプロイ
@ -158,10 +157,8 @@ Podのリストと詳細ページは、ダッシュボードに組み込まれ
![Logs viewer](/images/docs/ui-dashboard-logs-view.png)
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
詳細については[Kubernetes Dashboardプロジェクトページ](https://github.com/kubernetes/dashboard)をご覧ください。
{{% /capture %}}

View File

@ -1,10 +1,10 @@
---
title: Liveness Probe、Readiness ProbeおよびStartup Probeを使用する
content_template: templates/task
content_type: task
weight: 110
---
{{% capture overview %}}
<!-- overview -->
このページでは、Liveness Probe、Readiness ProbeおよびStartup Probeの使用方法について説明します。
@ -23,15 +23,13 @@ Readiness Probeによるチェックを無効にし、これらがアプリケ
例えば、これを起動が遅いコンテナの起動チェックとして使用することで、起動する前にkubeletによって
強制終了されることを防ぐことができます。
{{% /capture %}}
{{% capture prerequisites %}}
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
{{% /capture %}}
{{% capture steps %}}
<!-- steps -->
## コマンド実行によるLiveness Probeを定義する {#define-a-liveness-command}
@ -322,9 +320,8 @@ HTTPによるProbeの場合、kubeletは指定したパスとポートに対す
TCPによるProbeの場合、kubeletはPodの中ではなく、ードに対してコネクションを確立するProbeを実行します。
kubeletはServiceの名前を解決できないため、`host`パラメーター内でServiceの名前を使用することはできません。
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* [Container Probes](/ja/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)についてもっと学ぶ
@ -334,4 +331,3 @@ kubeletはServiceの名前を解決できないため、`host`パラメーター
* [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)
* [Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core)
{{% /capture %}}

View File

@ -1,24 +1,22 @@
---
title: Podを構成してConfigMapを使用する
content_template: templates/task
content_type: task
weight: 150
card:
name: tasks
weight: 50
---
{{% capture overview %}}
<!-- overview -->
ConfigMapを使用すると、設定をイメージのコンテンツから切り離して、コンテナ化されたアプリケーションの移植性を維持できます。このページでは、ConfigMapを作成し、ConfigMapに保存されているデータを使用してPodを構成する一連の使用例を示します。
{{% /capture %}}
{{% capture prerequisites %}}
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
{{% /capture %}}
{{% capture steps %}}
<!-- steps -->
## ConfigMapを作成する
@ -557,7 +555,7 @@ kubectl create -f https://kubernetes.io/examples/configmap/configmap-multikeys.y
### ConfigMapに保存されているデータをボリュームに入力する
ConfigMap名をPod specificationの`volumes`セクション配下に追加します。
ConfigMap名をPod specificationの`volumes`セクション配下に追加します。
これによりConfigMapデータが`volumeMounts.mountPath`で指定されたディレクトリに追加されます (このケースでは、`/etc/config`に)。`command`セクションはConfigMapのキーに合致したディレクトリファイルを名前別でリスト表示します。
{{< codenew file="pods/pod-configmap-volume.yaml" >}}
@ -614,9 +612,8 @@ very
ConfigMapを[subPath](/docs/concepts/storage/volumes/#using-subpath)ボリュームとして利用するコンテナはConfigMapの更新を受け取りません。
{{< /note >}}
{{% /capture %}}
{{% capture discussion %}}
<!-- discussion -->
## ConfigMapとPodsを理解する
@ -666,9 +663,7 @@ data:
- {{< glossary_tooltip text="static pods" term_id="static-pod" >}}はKubeletがサポートしていないため、ConfigMapに使用できません。
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* 実践例[Configuring Redis using a ConfigMap](/docs/tutorials/configuration/configure-redis-using-configmap/)を続けて読む。
{{% /capture %}}

View File

@ -1,24 +1,22 @@
---
title: コンテナの環境変数の定義
content_template: templates/task
content_type: task
weight: 20
---
{{% capture overview %}}
<!-- overview -->
このページでは、Kubernetes Podでコンテナの環境変数を定義する方法を説明します。
{{% /capture %}}
{{% capture prerequisites %}}
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
{{% /capture %}}
{{% capture steps %}}
<!-- steps -->
## コンテナの環境変数を定義する {#define-an-environment-variable-for-a-container}
@ -102,12 +100,10 @@ spec:
作成されると、コンテナ上で`echo Warm greetings to The Most Honorable Kubernetes`というコマンドが実行されます。
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* [環境変数](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)の詳細
* [Secretを環境変数として使用する](/docs/concepts/configuration/secret/#using-secrets-as-environment-variables)詳細
* [EnvVarSource](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvarsource-v1-core)をご覧ください。
{{% /capture %}}