resolve conflict

This commit is contained in:
inductor
2020-06-15 02:59:15 +09:00
2451 changed files with 127381 additions and 564546 deletions
+8 -7
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 %}}
@@ -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 %}}
@@ -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 -->
ここでは、設定ファイルを使って複数のクラスターにアクセスする方法を紹介します。クラスター、ユーザー、コンテキストの情報を一つ以上の設定ファイルにまとめることで、`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 -->
## クラスター、ユーザー、コンテキストを設定する
@@ -327,11 +328,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 %}}
@@ -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 %}}
@@ -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を作成
@@ -123,10 +125,11 @@ weight: 60
[service configuration file](/ja/docs/concepts/services-networking/service/)
を使用してServiceを作成することもできます。
{{% /capture %}}
{{% capture cleanup %}}
## {{% heading "cleanup" %}}
Serviceを削除するには、以下のコマンドを実行します:
@@ -136,12 +139,13 @@ Hello Worldアプリケーションが稼働しているDeployment、ReplicaSet
kubectl delete deployment hello-world
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
詳細は
[serviceを利用してアプリケーションと接続する](/docs/concepts/services-networking/connect-applications-service/)
を確認してください。
{{% /capture %}}
@@ -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/6371aabbd7a7726f4b358444cca40def793950c2/plugins.go#L55-L63)を呼び出すことによって独自のクラウドプロバイダーを登録する点です。
{{% /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 %}}
@@ -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 %}}
@@ -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 %}}
@@ -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 %}}
@@ -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 %}}
@@ -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 %}}
@@ -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 %}}
@@ -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 %}}
@@ -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" %}}
### アプリケーション開発者向け
@@ -250,7 +252,6 @@ kubectl delete namespace qos-example
* [APIオブジェクトのクォータを設定する](/docs/tasks/administer-cluster/quota-api-object/)
* [ノードのトポロジー管理ポリシーを制御する](/docs/tasks/administer-cluster/topology-manager/)
{{% /capture %}}
@@ -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 %}}
@@ -1,24 +1,25 @@
---
title: Initコンテナのデバッグ
content_template: templates/task
content_type: task
---
{{% capture overview %}}
<!-- overview -->
このページでは、Initコンテナの実行に関連する問題を調査する方法を説明します。以下のコマンドラインの例では、Podを`<pod-name>`、Initコンテナを`<init-container-1>`および`<init-container-2>`として参照しています。
{{% /capture %}}
{{% capture prerequisites %}}
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
* [Initコンテナ](/ja/docs/concepts/abstractions/init-containers/)の基本を理解しておきましょう。
* [Initコンテナを設定](/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container/)しておきましょう。
{{% /capture %}}
{{% capture steps %}}
<!-- steps -->
## Initコンテナのステータスを確認する
@@ -95,9 +96,9 @@ kubectl logs <pod-name> -c <init-container-2>
シェルスクリプトを実行するInitコンテナは、実行時にコマンドを出力します。たとえば、スクリプトの始めに`set -x`を実行することでBashで同じことができます。
{{% /capture %}}
{{% capture discussion %}}
<!-- discussion -->
## Podのステータスを理解する
@@ -111,7 +112,7 @@ kubectl logs <pod-name> -c <init-container-2>
`Pending` | PodはまだInitコンテナの実行を開始していません。
`PodInitializing` or `Running` | PodはすでにInitコンテナの実行を終了しています。
{{% /capture %}}
@@ -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のデバッグ
@@ -124,4 +125,4 @@ Podを作成できない場合は、[上述の手順](#Podのデバッグ)を参
`kubectl describe rc ${CONTROLLER_NAME}`を使用して、レプリケーションコントローラーに関連するイベントを調べることもできます。
{{% /capture %}}
@@ -1,18 +1,18 @@
---
content_template: templates/concept
content_type: concept
title: Serviceのデバッグ
---
{{% capture overview %}}
<!-- overview -->
新規にKubernetesをインストールした環境でかなり頻繁に発生する問題は、Serviceが適切に機能しないというものです。
Deployment(または他のワークロードコントローラー)を通じてPodを実行し、サービスを作成したにもかかわらず、アクセスしようとしても応答がありません。
何が問題になっているのかを理解するのに、このドキュメントがきっと役立つでしょう。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Pod内でコマンドを実行する
@@ -658,10 +658,11 @@ DNSは動作していて、`kube-proxy`も誤動作していないようです
[Forum](https://discuss.kubernetes.io)または
[GitHub](https://github.com/kubernetes/kubernetes)でお問い合わせください。
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
詳細については、[トラブルシューティングドキュメント](/docs/troubleshooting/)をご覧ください。
{{% /capture %}}
@@ -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コンテナのデバッグ](/ja/docs/tasks/debug-application-cluster/debug-init-containers/)の詳細
{{% /capture %}}
@@ -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 %}}
@@ -1,24 +1,25 @@
---
title: 実行中のコンテナへのシェルを取得する
content_template: templates/task
content_type: task
---
{{% capture overview %}}
<!-- overview -->
このページは`kubectl exec`を使用して実行中のコンテナへのシェルを取得する方法を説明します。
{{% /capture %}}
{{% capture prerequisites %}}
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
{{% /capture %}}
{{% capture steps %}}
<!-- steps -->
## コンテナへのシェルの取得
@@ -115,9 +116,9 @@ kubectl exec shell-demo ls /
kubectl exec shell-demo cat /proc/1/mounts
```
{{% /capture %}}
{{% capture discussion %}}
<!-- discussion -->
## Podが1つ以上のコンテナを持つ場合にシェルを開く
@@ -129,14 +130,15 @@ Podが1つ以上のコンテナを持つ場合、`--container`か`-c`を使用
kubectl exec -it my-pod --container main-app -- /bin/bash
```
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec)
{{% /capture %}}
@@ -1,22 +1,23 @@
---
title: StatefulSetの削除
content_template: templates/task
content_type: task
weight: 60
---
{{% capture overview %}}
<!-- overview -->
このタスクでは、StatefulSetを削除する方法を説明します。
{{% /capture %}}
{{% capture prerequisites %}}
## {{% heading "prerequisites" %}}
* このタスクは、クラスター上で、StatefulSetで表現されるアプリケーションが実行されていることを前提としています。
{{% /capture %}}
{{% capture steps %}}
<!-- steps -->
## StatefulSetの削除
@@ -74,12 +75,13 @@ kubectl delete pvc -l app=myapp
StatefulSet内の一部のPodが長期間`Terminating`または`Unknown`状態のままになっていることが判明した場合は、手動でapiserverからPodを強制的に削除する必要があります。これは潜在的に危険な作業です。詳細は[StatefulSet Podの強制削除](/ja/docs/tasks/run-application/force-delete-stateful-set-pod/)を参照してください。
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
[StatefulSet Podの強制削除](/ja/docs/tasks/run-application/force-delete-stateful-set-pod/)の詳細
{{% /capture %}}
@@ -1,20 +1,21 @@
---
title: StatefulSet Podの強制削除
content_template: templates/task
content_type: task
weight: 70
---
{{% capture overview %}}
<!-- overview -->
このページでは、StatefulSetの一部であるPodを削除する方法と、削除する際に考慮すべき事項について説明します。
{{% /capture %}}
{{% capture prerequisites %}}
## {{% heading "prerequisites" %}}
* これはかなり高度なタスクであり、StatefulSetに固有のいくつかの特性に反する可能性があります。
* 先に進む前に、以下に列挙されている考慮事項をよく理解してください。
{{% /capture %}}
{{% capture steps %}}
<!-- steps -->
## StatefulSetに関する考慮事項
@@ -68,10 +69,11 @@ kubectl patch pod <pod> -p '{"metadata":{"finalizers":null}}'
StatefulSet Podの強制削除は、常に慎重に、関連するリスクを完全に把握して実行してください。
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
[StatefulSetのデバッグ](/docs/tasks/debug-application-cluster/debug-stateful-set/)の詳細
{{% /capture %}}
@@ -1,10 +1,10 @@
---
title: レプリカを持つステートフルアプリケーションを実行する
content_template: templates/tutorial
content_type: tutorial
weight: 30
---
{{% capture overview %}}
<!-- overview -->
このページでは、[StatefulSet](/ja/docs/concepts/workloads/controllers/statefulset/)
コントローラーを使用して、レプリカを持つステートフルアプリケーションを実行する方法を説明します。
@@ -14,9 +14,10 @@ weight: 30
具体的には、MySQLの設定が安全ではないデフォルトのままとなっています。
これはKubernetesでステートフルアプリケーションを実行するための一般的なパターンに焦点を当てるためです。
{{% /capture %}}
{{% capture prerequisites %}}
## {{% heading "prerequisites" %}}
* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
* {{< include "default-storage-class-prereqs.md" >}}
@@ -29,18 +30,19 @@ weight: 30
* MySQLに関する知識は記事の理解に役立ちますが、
このチュートリアルは他のシステムにも役立つ一般的なパターンを提示することを目的としています。
{{% /capture %}}
{{% capture objectives %}}
## {{% heading "objectives" %}}
* StatefulSetコントローラーを使用して、レプリカを持つMySQLトポロジーをデプロイします。
* MySQLクライアントトラフィックを送信します。
* ダウンタイムに対する耐性を観察します。
* StatefulSetをスケールアップおよびスケールダウンします。
{{% /capture %}}
{{% capture lessoncontent %}}
<!-- lessoncontent -->
## MySQLをデプロイする
@@ -437,9 +439,10 @@ kubectl delete pvc data-mysql-3
kubectl delete pvc data-mysql-4
```
{{% /capture %}}
{{% capture cleanup %}}
## {{% heading "cleanup" %}}
1. `SELECT @@server_id`ループを実行している端末で**Ctrl+C**を押すか、
別の端末から次のコマンドを実行して、ループをキャンセルします。
@@ -478,13 +481,14 @@ kubectl delete pvc data-mysql-4
動的プロビジョニング機能を使用した場合は、PersistentVolumeClaimを削除すれば、自動的にPersistentVolumeも削除されます。
一部の動的プロビジョナー(EBSやPDなど)は、PersistentVolumeを削除すると同時に下層にあるリソースも解放します。
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* その他のステートフルアプリケーションの例は、[Helm Charts repository](https://github.com/kubernetes/charts)を見てください。
{{% /capture %}}
@@ -1,35 +1,37 @@
---
title: 単一レプリカのステートフルアプリケーションを実行する
content_template: templates/tutorial
content_type: tutorial
weight: 20
---
{{% capture overview %}}
<!-- overview -->
このページでは、PersistentVolumeとDeploymentを使用して、Kubernetesで単一レプリカのステートフルアプリケーションを実行する方法を説明します。アプリケーションはMySQLです。
{{% /capture %}}
{{% capture objectives %}}
## {{% heading "objectives" %}}
* 自身の環境のディスクを参照するPersistentVolumeを作成します。
* MySQLのDeploymentを作成します。
* MySQLをDNS名でクラスター内の他のPodに公開します。
{{% /capture %}}
{{% capture prerequisites %}}
## {{% heading "prerequisites" %}}
* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
* {{< include "default-storage-class-prereqs.md" >}}
{{% /capture %}}
{{% capture lessoncontent %}}
<!-- lessoncontent -->
## MySQLをデプロイする
@@ -163,10 +165,11 @@ PersistentVolumeを手動でプロビジョニングした場合は、Persistent
動的プロビジョニング機能を使用した場合は、PersistentVolumeClaimを削除すれば、自動的にPersistentVolumeも削除されます。
一部の動的プロビジョナー(EBSやPDなど)は、PersistentVolumeを削除すると同時に下層にあるリソースも解放します。
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* [Deploymentオブジェクト](/ja/docs/concepts/workloads/controllers/deployment/)についてもっと学ぶ
@@ -176,6 +179,6 @@ PersistentVolumeを手動でプロビジョニングした場合は、Persistent
* [Volumes](/docs/concepts/storage/volumes/)と[Persistent Volumes](/docs/concepts/storage/persistent-volumes/)
{{% /capture %}}
@@ -1,34 +1,36 @@
---
title: Deploymentを使用してステートレスアプリケーションを実行する
min-kubernetes-server-version: v1.9
content_template: templates/tutorial
content_type: tutorial
weight: 10
---
{{% capture overview %}}
<!-- overview -->
このページでは、Kubernetes Deploymentオブジェクトを使用してアプリケーションを実行する方法を説明します。
{{% /capture %}}
{{% capture objectives %}}
## {{% heading "objectives" %}}
* nginx deploymentを作成します。
* kubectlを使ってdeploymentに関する情報を一覧表示します。
* deploymentを更新します。
{{% /capture %}}
{{% capture prerequisites %}}
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
{{% /capture %}}
{{% capture lessoncontent %}}
<!-- lessoncontent -->
## nginx deploymentの作成と探検
@@ -138,13 +140,14 @@ Deploymentを名前を指定して削除します:
複製アプリケーションを作成するための好ましい方法はDeploymentを使用することです。そして、DeploymentはReplicaSetを使用します。 DeploymentとReplicaSetがKubernetesに追加される前は、[ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/)を使用して複製アプリケーションを構成していました。
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* [Deploymentオブジェクト](/ja/docs/concepts/workloads/controllers/deployment/)の詳細
{{% /capture %}}
@@ -1,14 +1,15 @@
---
title: StatefulSetのスケール
content_template: templates/task
content_type: task
weight: 50
---
{{% capture overview %}}
<!-- overview -->
このタスクは、StatefulSetをスケールする方法を示します。StatefulSetをスケーリングするとは、レプリカの数を増減することです。
{{% /capture %}}
{{% capture prerequisites %}}
## {{% heading "prerequisites" %}}
* StatefulSetはKubernetesバージョン1.5以降でのみ利用可能です。
Kubernetesのバージョンを確認するには、`kubectl version`を実行してください。
@@ -17,9 +18,9 @@ weight: 50
* ステートフルアプリケーションクラスターが完全に健全であると確信できる場合にのみ、スケーリングを実行してください。
{{% /capture %}}
{{% capture steps %}}
<!-- steps -->
## StatefulSetのスケール
@@ -71,10 +72,11 @@ spec.replicas > 1の場合、Kubernetesは不健康なPodの理由を判断で
一時的な障害によってPodが正常でなくなり、Podが再び使用可能になる可能性がある場合は、一時的なエラーがスケールアップまたはスケールダウン操作の妨げになる可能性があります。一部の分散データベースでは、ノードが同時に参加および脱退するときに問題があります。このような場合は、アプリケーションレベルでスケーリング操作を考えることをお勧めします。また、ステートフルアプリケーションクラスタが完全に健全であることが確実な場合にのみスケーリングを実行してください。
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* [StatefulSetの削除](/ja/docs/tasks/run-application/delete-stateful-set/)の詳細
{{% /capture %}}
@@ -1,17 +1,18 @@
---
title: Helmを使用したサービスカタログのインストール
content_template: templates/task
content_type: task
---
{{% capture overview %}}
<!-- overview -->
{{< glossary_definition term_id="service-catalog" length="all" prepend="サービスカタログは" >}}
[Helm](https://helm.sh/)を使用してKubernetesクラスターにサービスカタログをインストールします。手順の最新情報は[kubernetes-sigs/service-catalog](https://github.com/kubernetes-sigs/service-catalog/blob/master/docs/install.md)リポジトリーを参照してください。
{{% /capture %}}
{{% capture prerequisites %}}
## {{% heading "prerequisites" %}}
* [サービスカタログ](/docs/concepts/service-catalog/)の基本概念を理解してください。
* サービスカタログを使用するには、Kubernetesクラスターのバージョンが1.7以降である必要があります。
* KubernetesクラスターのクラスターDNSを有効化する必要があります。
@@ -22,10 +23,10 @@ content_template: templates/task
* [Helm install instructions](https://helm.sh/docs/intro/install/)を参考にしてください。
* 上記のバージョンのHelmをすでにインストールしている場合は、`helm init`を実行し、HelmのサーバーサイドコンポーネントであるTillerをインストールしてください。
{{% /capture %}}
{{% capture steps %}}
<!-- steps -->
## Helmリポジトリーにサービスカタログを追加
Helmをインストールし、以下のコマンドを実行することでローカルマシンに*service-catalog*のHelmリポジトリーを追加します。
@@ -106,11 +107,12 @@ helm install svc-cat/catalog --name catalog --namespace catalog
```
{{% /tab %}}
{{< /tabs >}}
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* [sample service brokers](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#sample-service-brokers)
* [kubernetes-sigs/service-catalog](https://github.com/kubernetes-sigs/service-catalog)
{{% /capture %}}
+11 -9
View File
@@ -1,6 +1,6 @@
---
title: kubectlのインストールおよびセットアップ
content_template: templates/task
content_type: task
weight: 10
card:
name: tasks
@@ -8,15 +8,16 @@ card:
title: Install kubectl
---
{{% capture overview %}}
<!-- overview -->
Kubernetesのコマンドラインツールである[kubectl](/docs/user-guide/kubectl/)を使用して、Kubernetesクラスターに対してコマンドを実行することができます。kubectlによってアプリケーションのデプロイや、クラスターのリソース管理および検査を行うことができます。kubectlの操作に関する完全なリストは、[Overview of kubectl](/docs/reference/kubectl/overview/)を参照してください。
{{% /capture %}}
{{% capture prerequisites %}}
## {{% heading "prerequisites" %}}
kubectlのバージョンは、クラスターのマイナーバージョンとの差分が1つ以内でなければなりません。たとえば、クライアントがv1.2であれば、v1.1、v1.2、v1.3のマスターで動作するはずです。最新バージョンのkubectlを使うことで、不測の事態を避けることができるでしょう。
{{% /capture %}}
{{% capture steps %}}
<!-- steps -->
## Linuxへkubectlをインストールする {#install-kubectl-on-linux}
@@ -488,12 +489,13 @@ compinit
{{% /tab %}}
{{< /tabs >}}
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* [Minikubeをインストールする](/ja/docs/tasks/tools/install-minikube/)
* クラスターの作成に関する詳細を[スタートガイド](/docs/setup/)で確認する
* [アプリケーションを起動して公開する方法を学ぶ](/docs/tasks/access-application-cluster/service-access-application-cluster/)
* あなたが作成していないクラスターにアクセスする必要がある場合は、[クラスターアクセスドキュメントの共有](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)を参照してください
* [kubectlリファレンスドキュメント](/docs/reference/kubectl/kubectl/)を参照する
{{% /capture %}}
+15 -13
View File
@@ -1,19 +1,20 @@
---
title: Minikubeのインストール
content_template: templates/task
content_type: task
weight: 20
card:
name: tasks
weight: 10
---
{{% capture overview %}}
<!-- overview -->
このページでは[Minikube](/ja/docs/tutorials/hello-minikube)のインストール方法を説明し、コンピューターの仮想マシン上で単一ノードのKubernetesクラスターを実行します。
{{% /capture %}}
{{% capture prerequisites %}}
## {{% heading "prerequisites" %}}
{{< tabs name="minikube_before_you_begin" >}}
{{% tab name="Linux" %}}
@@ -53,11 +54,11 @@ Hyper-V Requirements: A hypervisor has been detected. Features required for
{{% /tab %}}
{{< /tabs >}}
{{% /capture %}}
{{% capture steps %}}
# minikubeのインストール
<!-- steps -->
## minikubeのインストール
{{< tabs name="tab_with_md" >}}
{{% tab name="Linux" %}}
@@ -200,13 +201,7 @@ WindowsにMinikubeを手動でインストールするには、[`minikube-window
{{% /tab %}}
{{< /tabs >}}
{{% /capture %}}
{{% capture whatsnext %}}
* [Minikubeを使ってローカルでKubernetesを実行する](/ja/docs/setup/learning-environment/minikube/)
{{% /capture %}}
## インストールの確認
@@ -259,3 +254,10 @@ minikubeのローカル状態をクリアする必要があります:
```shell
minikube delete
```
## {{% heading "whatsnext" %}}
* [Minikubeを使ってローカルでKubernetesを実行する](/ja/docs/setup/learning-environment/minikube/)