whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

merge everything

Browse Source
This commit is contained in:
inductor
2020-06-12 23:38:22 +09:00
parent d0e6fd0aa3 7b6a907b53
commit 687d343d56
105 changed files with 3228 additions and 781 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/ja/_index.html
-3
View File
@@ -3,9 +3,6 @@ title: "プロダクショングレードのコンテナ管理基盤"
abstract: "自動化されたコンテナのデプロイ・スケール・管理"
cid: home
---
{{< announcement >}}
{{< deprecationwarning >}}
{{< blocks/section id="oceanNodes" >}}
{{% blocks/feature image="flower" %}}
content/ja/docs/concepts/_index.md
+2 -2
View File
@@ -15,7 +15,7 @@ weight: 40
## 概要
Kubernetesを機能させるには、*Kubernetes API オブジェクト* を使用して、実行したいアプリケーションやその他のワークロード、使用するコンテナイメージ、レプリカ(複製)の数、どんなネットワークやディスクリソースを利用可能にするかなど、クラスターの *desired state* (望ましい状態)を記述します。desired sate (望ましい状態)をセットするには、Kubernetes APIを使用してオブジェクトを作成します。通常はコマンドラインインターフェイス `kubectl` を用いてKubernetes APIを操作しますが、Kubernetes APIを直接使用してクラスターと対話し、desired state (望ましい状態)を設定、または変更することもできます。
Kubernetesを機能させるには、*Kubernetes API オブジェクト* を使用して、実行したいアプリケーションやその他のワークロード、使用するコンテナイメージ、レプリカ(複製)の数、どんなネットワークやディスクリソースを利用可能にするかなど、クラスターの *desired state* (望ましい状態)を記述します。desired state (望ましい状態)をセットするには、Kubernetes APIを使用してオブジェクトを作成します。通常はコマンドラインインターフェイス `kubectl` を用いてKubernetes APIを操作しますが、Kubernetes APIを直接使用してクラスターと対話し、desired state (望ましい状態)を設定、または変更することもできます。
一旦desired state (望ましい状態)を設定すると、Pod Lifecycle Event Generator([PLEG](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/pod-lifecycle-event-generator.md))を使用した*Kubernetes コントロールプレーン*が機能し、クラスターの現在の状態をdesired state (望ましい状態)に一致させます。そのためにKubernetesはさまざまなタスク(たとえば、コンテナの起動または再起動、特定アプリケーションのレプリカ数のスケーリング等)を自動的に実行します。Kubernetesコントロールプレーンは、クラスターで実行されている以下のプロセスで構成されています。
@@ -26,7 +26,7 @@ Kubernetesを機能させるには、*Kubernetes API オブジェクト* を使
## Kubernetesオブジェクト
Kubernetesには、デプロイ済みのコンテナ化されたアプリケーションやワークロード、関連するネットワークとディスクリソース、クラスターが何をしているかに関するその他の情報といった、システムの状態を表現する抽象が含まれています。これらの抽象は、Kubernetes APIのオブジェクトによって表現されます。詳細については、[Kubernetesオブジェクトについて知る](/docs/concepts/overview/working-with-objects/kubernetes-objects/)をご覧ください。
Kubernetesには、デプロイ済みのコンテナ化されたアプリケーションやワークロード、関連するネットワークとディスクリソース、クラスターが何をしているかに関するその他の情報といった、システムの状態を表現する抽象が含まれています。これらの抽象は、Kubernetes APIのオブジェクトによって表現されます。詳細については、[Kubernetesオブジェクトについて知る](/ja/docs/concepts/overview/working-with-objects/kubernetes-objects/)をご覧ください。
基本的なKubernetesのオブジェクトは次のとおりです。
content/ja/docs/concepts/cluster-administration/cluster-administration-overview.md
+2 -2
View File
@@ -20,7 +20,7 @@ Kubernetesクラスターの計画、セットアップ、設定の例を知る
- **もしあなたが高可用性を求める場合**、 [複数ゾーンにまたがるクラスター](/docs/concepts/cluster-administration/federation/)の設定について学んでください。
- [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/)のような**ホストされているKubernetesクラスター**を使用するのか、それとも**自分自身でクラスターをホストするのでしょうか**?
- 使用するクラスターは**オンプレミス**なのか、それとも**クラウド (IaaS)**でしょうか? Kubernetesはハイブリッドクラスターを直接サポートしていません。その代わりユーザーは複数のクラスターをセットアップできます。
- Kubernetesを**"ベアメタル"なハードウェア** 上で稼働させるますか? それとも**仮想マシン (VMs)** 上で稼働させますか?
- Kubernetesを**"ベアメタル"なハードウェア** 上で稼働させますか? それとも**仮想マシン (VMs)** 上で稼働させますか?
- **もしオンプレミスでKubernetesを構築する場合**、どの[ネットワークモデル](/ja/docs/concepts/cluster-administration/networking/)が最適か検討してください。
- **ただクラスターを稼働させたいだけ**でしょうか、それとも**Kubernetesプロジェクトのコードの開発**を行いたいでしょうか? もし後者の場合、開発が進行中のディストリビューションを選択してください。いくつかのディストリビューションはバイナリリリースのみ使用していますが、多くの選択肢があります。
- クラスターを稼働させるのに必要な[コンポーネント](/ja/docs/concepts/overview/components/)についてよく理解してください。
@@ -39,7 +39,7 @@ Kubernetesクラスターの計画、セットアップ、設定の例を知る
* [Certificates](/docs/concepts/cluster-administration/certificates/)では、異なるツールチェインを使用して証明書を作成する方法を説明します。
* [Kubernetes コンテナの環境](/ja/docs/concepts/containers/container-environment-variables/)では、Kubernetesノード上でのKubeletが管理するコンテナの環境について説明します。
* [Kubernetes コンテナの環境](/ja/docs/concepts/containers/container-environment/)では、Kubernetesノード上でのKubeletが管理するコンテナの環境について説明します。
* [Kubernetes APIへのアクセス制御](/docs/reference/access-authn-authz/controlling-access/)では、ユーザーとサービスアカウントの権限の設定方法について説明します。
content/ja/docs/concepts/configuration/assign-pod-node.md
+1 -1
View File
@@ -8,7 +8,7 @@ weight: 30
<!-- overview -->
[Pod](/ja/docs/concepts/workloads/pods/pod/)が稼働する[Node](/ja/docs/concepts/architecture/nodes/)を特定のものに指定したり、優先条件を指定して制限することができます。
これを実現するためにはいくつかの方法がありますが、推奨されている方法は[ラベルでの選択](/docs/concepts/overview/working-with-objects/labels/)です。
これを実現するためにはいくつかの方法がありますが、推奨されている方法は[ラベルでの選択](/ja/docs/concepts/overview/working-with-objects/labels/)です。
スケジューラーが最適な配置を選択するため、一般的にはこのような制限は不要です(例えば、複数のPodを別々のNodeへデプロイしたり、Podを配置する際にリソースが不十分なNodeにはデプロイされないことが挙げられます)が、
SSDが搭載されているNodeにPodをデプロイしたり、同じアベイラビリティーゾーン内で通信する異なるサービスのPodを同じNodeにデプロイする等、柔軟な制御が必要なこともあります。
content/ja/docs/concepts/configuration/overview.md
+3 -3
View File
@@ -31,7 +31,7 @@ weight: 10
- 可能な限り、"真っ裸"のPod([ReplicaSet](/ja/docs/concepts/workloads/controllers/replicaset/)や[Deployment](/ja/docs/concepts/workloads/controllers/deployment/)にバインドされていないPod)は使わないでください。Nodeに障害が発生した場合、これらのPodは再スケジュールされません。
明示的に[`restartPolicy: Never`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)を使いたいシーンを除いて、DeploymentはPodを直接作成するよりもほとんど常に望ましい方法です。Deploymentには、希望する数のPodが常に使用可能であることを確認するためにReplicaSetを作成したり、Podを置き換えるための戦略（RollingUpdateなど）を指定したりできます。[Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/)のほうが適切な場合もあるかもしれません。
明示的に[`restartPolicy: Never`](/ja/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)を使いたいシーンを除いて、DeploymentはPodを直接作成するよりもほとんど常に望ましい方法です。Deploymentには、希望する数のPodが常に使用可能であることを確認するためにReplicaSetを作成したり、Podを置き換えるための戦略（RollingUpdateなど）を指定したりできます。[Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/)のほうが適切な場合もあるかもしれません。
## Service
@@ -58,7 +58,7 @@ weight: 10
## ラベルの使用
- `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`のように、アプリケーションまたはデプロイメントの__セマンティック属性__を識別する[ラベル](/docs/concepts/overview/working-with-objects/labels/)を定義して使いましょう。これらのラベルを使用して、他のリソースに適切なポッドを選択できます。例えば、すべての`tier：frontend`を持つPodを選択するServiceや、`app：myapp`に属するすべての`phase：test`コンポーネント、などです。このアプローチの例を知るには、[ゲストブック](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/)アプリも合わせてご覧ください。
- `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`のように、アプリケーションまたはデプロイメントの__セマンティック属性__を識別する[ラベル](/ja/docs/concepts/overview/working-with-objects/labels/)を定義して使いましょう。これらのラベルを使用して、他のリソースに適切なポッドを選択できます。例えば、すべての`tier：frontend`を持つPodを選択するServiceや、`app：myapp`に属するすべての`phase：test`コンポーネント、などです。このアプローチの例を知るには、[ゲストブック](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/)アプリも合わせてご覧ください。
セレクターからリリース固有のラベルを省略することで、Serviceを複数のDeploymentにまたがるように作成できます。 [Deployment](/ja/docs/concepts/workloads/controllers/deployment/)により、ダウンタイムなしで実行中のサービスを簡単に更新できます。
@@ -96,7 +96,7 @@ weight: 10
- `kubectl apply -f <directory>`を使いましょう。これを使うと、ディレクトリ内のすべての`.yaml`、`.yml`、および`.json`ファイルが`apply`に渡されます。
- `get`や`delete`を行う際は、特定のオブジェクト名を指定するのではなくラベルセレクターを使いましょう。[ラベルセレクター](/docs/concepts/overview/working-with-objects/labels/#label-selectors)と[ラベルの効果的な使い方](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively)のセクションを参照してください。
- `get`や`delete`を行う際は、特定のオブジェクト名を指定するのではなくラベルセレクターを使いましょう。[ラベルセレクター](/ja/docs/concepts/overview/working-with-objects/labels/#label-selectors)と[ラベルの効果的な使い方](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively)のセクションを参照してください。
content/ja/docs/concepts/containers/container-environment-variables.md → content/ja/docs/concepts/containers/container-environment.md
+1 -1
View File
@@ -1,5 +1,5 @@
---
title: コンテナ環境変数
title: コンテナ環境
content_type: concept
weight: 20
---
content/ja/docs/concepts/containers/container-lifecycle-hooks.md
+2 -2
View File
@@ -34,7 +34,7 @@ Angularなどのコンポーネントライフサイクルフックを持つ多
これはブロッキング、つまり同期的であるため、コンテナを削除するための呼び出しを送信する前に完了する必要があります。
ハンドラーにパラメーターは渡されません。
終了動作の詳細な説明は、[Termination of Pods](/ja/docs/concepts/workloads/pods/pod/#podの終了)にあります。
終了動作の詳細な説明は、[Termination of Pods](/ja/docs/concepts/workloads/pods/pod/#termination-of-pods)にあります。
### フックハンドラーの実装
@@ -98,7 +98,7 @@ Events:
## {{% heading "whatsnext" %}}
* [コンテナ環境](/docs/concepts/containers/container-environment-variables/)の詳細
* [コンテナ環境](/ja/docs/concepts/containers/container-environment/)の詳細
* [コンテナライフサイクルイベントへのハンドラー紐付け](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)のハンズオン
content/ja/docs/concepts/containers/overview.md
+31
View File
@@ -0,0 +1,31 @@
---
title: コンテナの概要
content_template: templates/concept
weight: 1
---
{{% capture overview %}}
コンテナは、アプリケーションの(コンパイルされた)コードと、実行時に必要な依存関係をパッケージ化するための技術です。実行する各コンテナは再現性があります。依存関係を含めることによる標準化は、どこで実行しても同じ動作が得られることを意味します。
コンテナは、基礎となるホストインフラストラクチャからアプリケーションを切り離します。これにより、さまざまなクラウド環境やOS環境でのデプロイが容易になります。
{{% /capture %}}
{{% capture body %}}
## コンテナイメージ {#container-images}
[コンテナイメージ](/docs/concepts/containers/images/)は、アプリケーションを実行するために必要なすべてのものを含んだ、すぐに実行可能なソフトウェアパッケージです。コードとそれが必要とする任意のランタイム、アプリケーションとシステムのライブラリ、および必須の設定のデフォルト値が含まれています。
設計上、コンテナは不変であるため、すでに実行中のコンテナのコードを変更することはできません。コンテナ化されたアプリケーションがあり、変更を加えたい場合は、変更を含む新しいコンテナをビルドし、コンテナを再作成して更新されたイメージから起動する必要があります。
## コンテナランタイム {#container-runtimes}
{{< glossary_definition term_id="container-runtime" length="all" >}}
{{% /capture %}}
{{% capture whatsnext %}}
* [コンテナイメージ](/docs/concepts/containers/images/)についてお読みください。
* [Pod](/ja/docs/concepts/workloads/pods/)についてお読みください。
{{% /capture %}}
content/ja/docs/concepts/containers/runtime-class.md
+1 -1
View File
@@ -81,7 +81,7 @@ spec:
# ...
```
これは、Kubeletに対してPodを稼働させるためのRuntimeClassを使うように指示します。もし設定されたRuntimeClassが存在しない場合や、CRIが対応するハンドラーを実行できない場合、そのPodは`Failed`という[フェーズ](/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase)になります。
これは、Kubeletに対してPodを稼働させるためのRuntimeClassを使うように指示します。もし設定されたRuntimeClassが存在しない場合や、CRIが対応するハンドラーを実行できない場合、そのPodは`Failed`という[フェーズ](/ja/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase)になります。
エラーメッセージに関しては対応する[イベント](/docs/tasks/debug-application-cluster/debug-application-introspection/)を参照して下さい。
もし`runtimeClassName`が指定されていない場合、デフォルトのRuntimeHandlerが使用され、これはRuntimeClassの機能が無効であるときのふるまいと同じものとなります。
content/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md
+14 -6
View File
@@ -1,24 +1,31 @@
---
title: アグリゲーションレイヤーを使ったKubernetes APIの拡張
content_type: concept
weight: 10
weight: 20
---
<!-- overview -->
アグリゲーションレイヤーを使用すると、KubernetesのコアAPIで提供されている機能を超えて、追加のAPIでKubernetesを拡張できます。
アグリゲーションレイヤーを使用すると、KubernetesのコアAPIで提供されている機能を超えて、追加のAPIでKubernetesを拡張できます。追加のAPIは、[service-catalog](/docs/concepts/extend-kubernetes/service-catalog/)のような既製のソリューション、または自分で開発したAPIのいずれかです。
アグリゲーションレイヤーは、[カスタムリソース](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)とは異なり、{{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}}に新しい種類のオブジェクトを認識させる方法です。
<!-- body -->
## 概要
## アグリゲーションレイヤー
アグリゲーションレイヤーを使用すると、クラスターにKubernetesスタイルのAPIを追加でインストールできます。これらは、[service-catalog](https://github.com/kubernetes-incubator/service-catalog/blob/master/README.md)や、[apiserver-builder](https://github.com/kubernetes-incubator/apiserver-builder/blob/master/README.md)のようなユーザーが作成したAPIなど、出来合いのもの、また既存のサードパーティソリューションに関わらず使い始めることができます。
アグリゲーションレイヤーは、kube-apiserverのプロセス内で動きます。拡張リソースが登録されるまでは、アグリゲーションレイヤーは何もしません。APIを登録するには、ユーザーはKubernetes APIで使われるURLのパスを"要求"した、_APIService_ オブジェクトを追加します。それを追加すると、アグリゲーションレイヤーはAPIパス(例、`/apis/myextension.mycompany.io/v1/…`)への全てのアクセスを、登録されたAPIServiceにプロキシーします。
バージョン1.7において、アグリゲーションレイヤーは、kube-apiserverのプロセス内で動きます。拡張リソースが登録されるまでは、アグリゲーションレイヤーは何もしません。APIを登録するには、ユーザーはKubernetes APIで使われるURLのパスを"要求"した、APIServiceオブジェクトを追加しなければなりません。それを追加すると、アグリゲーションレイヤーはAPIパス（例、/apis/myextension.mycompany.io/v1/…）への全てのアクセスを、登録されたAPIServiceにプロキシします。
APIServiceを実装する最も一般的な方法は、クラスター内で実行されるPodで*拡張APIサーバー* を実行することです。クラスター内のリソース管理に拡張APIサーバーを使用している場合、拡張APIサーバー("extension-apiserver"とも呼ばれます)は通常、1つ以上の{{< glossary_tooltip text="コントローラー" term_id="controller" >}}とペアになっています。apiserver-builderライブラリは、拡張APIサーバーと関連するコントローラーの両方にスケルトンを提供します。
通常、APIServiceは、クラスター上で動いているPod内の *extension-apiserver* で実装されます。このextension-apiserverは、追加されたリソースに対するアクティブな管理が必要な場合、通常、1つか複数のコントローラーとペアになっている必要があります。そのため、実際にapiserver-builderはextension-apiserverとコントローラーの両方のスケルトンを提供します。一例として、service-catalogがインストールされると、extension-apiserverと提供するサービスのコントローラーの両方を提供します。
### 応答遅延
拡張APIサーバーは、kube-apiserverとの間の低遅延ネットワーキングが必要です。
kube-apiserverとの間を5秒以内に往復するためには、ディスカバリーリクエストが必要です。
拡張APIサーバーがそのレイテンシ要件を達成できない場合は、その要件を満たすように変更することを検討してください。また、kube-apiserverで`EnableAggregatedDiscoveryTimeout=false` [フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を設定することで、タイムアウト制限を無効にすることができます。この非推奨のフィーチャーゲートは将来のリリースで削除される予定です。
@@ -28,6 +35,7 @@ weight: 10
* アグリゲーターをあなたの環境で動かすには、まず[アグリゲーションレイヤーを設定](/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/)方法を学んで下さい
* [APIService](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#apiservice-v1-apiregistration-k8s-io)の仕様をお読み下さい
content/ja/docs/concepts/extend-kubernetes/operator.md
+1 -1
View File
@@ -84,7 +84,7 @@ kubectl edit SampleDB/example-database # 手動でいくつかの設定を変更
## {{% heading "whatsnext" %}}
* [Custom Resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)をより深く学びます
* [Custom Resources](/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources/)をより深く学びます
* ユースケースに合わせた、既製のオペレーターを[OperatorHub.io](https://operatorhub.io/)から見つけます
* 自前のオペレーターを書くために既存のツールを使います、例:
* [KUDO](https://kudo.dev/)（Kubernetes Universal Declarative Operator）を使います
content/ja/docs/concepts/overview/components.md
+2 -2
View File
@@ -93,7 +93,7 @@ cloud-controller-managerを使用すると、クラウドベンダーのコー
### DNS
クラスターDNS以外のアドオンは必須ではありませんが、すべてのKubernetesクラスターは[クラスターDNS](/docs/concepts/services-networking/dns-pod-service/)を持つべきです。多くの使用例がクラスターDNSを前提としています。
クラスターDNS以外のアドオンは必須ではありませんが、すべてのKubernetesクラスターは[クラスターDNS](/ja/docs/concepts/services-networking/dns-pod-service/)を持つべきです。多くの使用例がクラスターDNSを前提としています。
クラスターDNSは、環境内の他のDNSサーバーに加えて、KubernetesサービスのDNSレコードを提供するDNSサーバーです。
@@ -102,7 +102,7 @@ Kubernetesによって開始されたコンテナは、DNS検索にこのDNSサ
### Web UI (ダッシュボード)
[ダッシュボード](/docs/tasks/access-application-cluster/web-ui-dashboard/)は、Kubernetesクラスター用の汎用WebベースUIです。これによりユーザーはクラスターおよびクラスター内で実行されているアプリケーションについて、管理およびトラブルシューティングを行うことができます。
[ダッシュボード](/ja/docs/tasks/access-application-cluster/web-ui-dashboard/)は、Kubernetesクラスター用の汎用WebベースUIです。これによりユーザーはクラスターおよびクラスター内で実行されているアプリケーションについて、管理およびトラブルシューティングを行うことができます。
### コンテナリソース監視
content/ja/docs/concepts/overview/kubernetes-api.md
+1 -1
View File
@@ -86,7 +86,7 @@ APIとソフトウエアのバージョニングは、間接的にしか関連
- バージョン名は`vX`のようになっており、`X`は整数です。
- 安定版の機能は、今後のリリースバージョンにも適用されます。
## APIグループ
## APIグループ {#api-groups}
KubernetesAPIの拡張を簡易に行えるようにするため、[*APIグループ*](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md)を実装しました。
APIグループは、RESTのパスとシリアライズされたオブジェクトの`apiVersion`フィールドで指定されます。
content/ja/docs/concepts/overview/what-is-kubernetes.md
+1 -1
View File
@@ -34,7 +34,7 @@ Kubernetesは、**コンテナを中心とした**管理基盤です。ユーザ
Kubernetesが多くの機能を提供すると言いつつも、新しい機能から恩恵を受ける新しいシナリオは常にあります。アプリケーション固有のワークフローを効率化して開発者のスピードを早めることができます。最初は許容できるアドホックなオーケストレーションでも、大規模で堅牢な自動化が必要となることはしばしばあります。これが、Kubernetesがアプリケーションのデプロイ、拡張、および管理を容易にするために、コンポーネントとツールのエコシステムを構築するための基盤としても機能するように設計された理由です。
[ラベル](/docs/concepts/overview/working-with-objects/labels/)を使用すると、ユーザーは自分のリソースを整理できます。[アノテーション](/docs/concepts/overview/working-with-objects/annotations/)を使用すると、ユーザーは自分のワークフローを容易にし、管理ツールが状態をチェックするための簡単な方法を提供するためにカスタムデータを使ってリソースを装飾できるようになります。
[ラベル](/ja/docs/concepts/overview/working-with-objects/labels/)を使用すると、ユーザーは自分のリソースを整理できます。[アノテーション](/ja/docs/concepts/overview/working-with-objects/annotations/)を使用すると、ユーザーは自分のワークフローを容易にし、管理ツールが状態をチェックするための簡単な方法を提供するためにカスタムデータを使ってリソースを装飾できるようになります。
さらに、[Kubernetesコントロールプレーン](/ja/docs/concepts/overview/components/)は、開発者やユーザーが使える[API](/docs/reference/using-api/api-overview/)の上で成り立っています。ユーザーは[スケジューラー](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/devel/scheduler.md)などの独自のコントローラーを、汎用の[コマンドラインツール](/docs/user-guide/kubectl-overview/)で使える[独自のAPI](/docs/concepts/api-extension/custom-resources/)を持たせて作成することができます。
content/ja/docs/concepts/overview/working-with-objects/annotations.md
+27 -14
View File
@@ -5,16 +5,16 @@ weight: 50
---
<!-- overview -->
ユーザーは、識別用途でない任意のメタデータをオブジェクトに割り当てるためにアノテーションを使用できます。ツールやライブラリなどのクライアントは、このメタデータを取得できます。
ユーザーは、識別用途でない任意のメタデータをオブジェクトに割り当てるためにアノテーションを使用できます。ツールやライブラリなどのクライアントは、このメタデータを取得できます。
<!-- body -->
## オブジェクトにメタデータを割り当てる
ユーザーは、Kubernetesオブジェクトに対してラベルやアノテーションの両方またはどちらか一方を割り当てることができます。
ラベルはオブジェクトの選択や、特定の条件を満たしたオブジェクトの集合を探すことに使うことができます。
それと対照的に、アノテーションはオブジェクトを識別、または選択するために使用されません。
アノテーション内のメタデータは大小様々で、構造化されているものや、そうでないものも設定でき、ラベルでは許可されていない文字も含むことができます。
ラベルはオブジェクトの選択や、特定の条件を満たしたオブジェクトの集合を探すことに使うことができます。
それと対照的に、アノテーションはオブジェクトを識別、または選択するために使用されません。
アノテーション内のメタデータは大小様々で、構造化されているものや、そうでないものも設定でき、ラベルでは許可されていない文字も含むことができます。
アノテーションは、ラベルと同様に、キーとバリューのマップとなります。
@@ -49,20 +49,33 @@ weight: 50
## 構文と文字セット
_アノテーション_ はキーとバリューのペアです。有効なアノテーションのキーの形式は2つのセグメントがあります。
プレフィックス(オプション)と名前で、それらはスラッシュ`/`で区切られます。
名前セグメントは必須で、63文字以下である必要があり、文字列の最初と最後は英数字(`[a-z0-9A-Z]`)と、文字列の間にダッシュ(`-`)、アンダースコア(`_`)、ドット(`.`)を使うことができます。
プレフィックスはオプションです。もしプレフィックスが指定されていた場合、プレフィックスはDNSサブドメイン形式である必要があり、それはドット(`.`)で区切られたDNSラベルのセットで、253文字以下である必要があり、最後にスラッシュ(`/`)が続きます。
_アノテーション_ はキーとバリューのペアです。有効なアノテーションのキーの形式は2つのセグメントがあります。
プレフィックス(オプション)と名前で、それらはスラッシュ`/`で区切られます。
名前セグメントは必須で、63文字以下である必要があり、文字列の最初と最後は英数字(`[a-z0-9A-Z]`)と、文字列の間にダッシュ(`-`)、アンダースコア(`_`)、ドット(`.`)を使うことができます。
プレフィックスはオプションです。もしプレフィックスが指定されていた場合、プレフィックスはDNSサブドメイン形式である必要があり、それはドット(`.`)で区切られたDNSラベルのセットで、253文字以下である必要があり、最後にスラッシュ(`/`)が続きます。
もしプレフィックスが除外された場合、アノテーションキーはそのユーザーに対してプライベートであると推定されます。
エンドユーザーのオブジェクトにアノテーションを追加するような自動化されたシステムコンポーネント(例: `kube-scheduler` `kube-controller-manager` `kube-apiserver` `kubectl`やその他のサードパーティツール)は、プレフィックスを指定しなくてはなりません。
もしプレフィックスが除外された場合、アノテーションキーはそのユーザーに対してプライベートであると推定されます。
エンドユーザーのオブジェクトにアノテーションを追加するような自動化されたシステムコンポーネント(例: `kube-scheduler` `kube-controller-manager` `kube-apiserver` `kubectl`やその他のサードパーティツール)は、プレフィックスを指定しなくてはなりません。
`kubernetes.io/`と`k8s.io/`プレフィックスは、Kubernetesコアコンポーネントのために予約されています。
`kubernetes.io/`と`k8s.io/`プレフィックスは、Kubernetesコアコンポーネントのために予約されています。
たとえば、`imageregistry: https://hub.docker.com/`というアノテーションが付いたPodの構成ファイルは次のとおりです:
```yaml
apiVersion: v1
kind: Pod
metadata:
name: annotations-demo
annotations:
imageregistry: "https://hub.docker.com/"
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80
```
## {{% heading "whatsnext" %}}
[ラベルとセレクター](/docs/concepts/overview/working-with-objects/labels/)について学習してください。
[ラベルとセレクター](/ja/docs/concepts/overview/working-with-objects/labels/)について学習してください。
content/ja/docs/concepts/overview/working-with-objects/common-labels.md
+7 -7
View File
@@ -49,10 +49,10 @@ metadata:
## アプリケーションとアプリケーションのインスタンス
単一のアプリケーションは、Kubernetesクラスタ内で、いくつかのケースでは同一の名前空間に対して1回または複数回インストールされることがあります。
単一のアプリケーションは、Kubernetesクラスタ内で、いくつかのケースでは同一の名前空間に対して1回または複数回インストールされることがあります。
例えば、WordPressは複数のウェブサイトがあれば、それぞれ別のWordPressが複数回インストールされることがあります。
アプリケーション名と、アプリケーションのインスタンス名はそれぞれ別に記録されます。
アプリケーション名と、アプリケーションのインスタンス名はそれぞれ別に記録されます。
例えば、WordPressは`app.kubernetes.io/name`に`wordpress`と記述され、インスタンス名に関しては`app.kubernetes.io/instance`に`wordpress-abcxzy`と記述されます。この仕組みはアプリケーションと、アプリケーションのインスタンスを特定可能にします。全てのアプリケーションインスタンスは固有の名前を持たなければなりません。
## ラベルの使用例
@@ -86,7 +86,7 @@ metadata:
### データベースを使ったウェブアプリケーション
次にもう少し複雑なアプリケーションについて考えます。データベース(MySQL)を使ったウェブアプリケーション(WordPress)で、Helmを使ってインストールします。
次にもう少し複雑なアプリケーションについて考えます。データベース(MySQL)を使ったウェブアプリケーション(WordPress)で、Helmを使ってインストールします。
下記のスニペットは、このアプリケーションをデプロイするために使うオブジェクト設定の出だし部分です。
はじめに下記の`Deployment`は、WordPressのために使われます。
@@ -128,11 +128,11 @@ kind: StatefulSet
metadata:
labels:
app.kubernetes.io/name: mysql
app.kubernetes.io/instance: wordpress-abcxzy
app.kubernetes.io/instance: mysql-abcxzy
app.kubernetes.io/version: "5.7.21"
app.kubernetes.io/managed-by: helm
app.kubernetes.io/component: database
app.kubernetes.io/part-of: wordpress
app.kubernetes.io/version: "5.7.21"
...
```
@@ -143,11 +143,11 @@ kind: Service
metadata:
labels:
app.kubernetes.io/name: mysql
app.kubernetes.io/instance: wordpress-abcxzy
app.kubernetes.io/instance: mysql-abcxzy
app.kubernetes.io/version: "5.7.21"
app.kubernetes.io/managed-by: helm
app.kubernetes.io/component: database
app.kubernetes.io/part-of: wordpress
app.kubernetes.io/version: "5.7.21"
...
```
content/ja/docs/concepts/overview/working-with-objects/field-selectors.md
+3 -3
View File
@@ -10,7 +10,7 @@ _フィールドセレクター(Field Selectors)_ は、1つかそれ以上の
* `metadata.namespace!=default`
* `status.phase=Pending`
下記の`kubectl`コマンドは、[`status.phase`](/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase)フィールドの値が`Running`である全てのPodを選択します。
下記の`kubectl`コマンドは、[`status.phase`](/ja/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase)フィールドの値が`Running`である全てのPodを選択します。
```shell
kubectl get pods --field-selector status.phase=Running
@@ -43,7 +43,7 @@ Error from server (BadRequest): Unable to find "ingresses" that match label sele
例として、下記の`kubectl`コマンドは`default`ネームスペースに属していない全てのKubernetes Serviceを選択します。
```shell
kubectl get services --field-selector metadata.namespace!=default
kubectl get services --all-namespaces --field-selector metadata.namespace!=default
```
## 連結されたセレクター
@@ -51,7 +51,7 @@ kubectl get services --field-selector metadata.namespace!=default
下記の`kubectl`コマンドは、`status.phase`が`Runnning`でなく、かつ`spec.restartPolicy`フィールドが`Always`に等しいような全てのPodを選択します。
```shell
kubectl get pods --field-selector=status.phase!=Running,spec.restartPolicy=Always
kubectl get statefulsets,services --all-namespaces --field-selector metadata.namespace!=default
```
## 複数のリソースタイプ
content/ja/docs/concepts/overview/working-with-objects/kubernetes-objects.md
+10 -4
View File
@@ -22,11 +22,13 @@ card:
Kubernetesオブジェクトは"意図の記録"です。一度オブジェクトを作成すると、Kubernetesは常にそのオブジェクトが存在し続けるように動きます。オブジェクトを作成することで、Kubernetesに対し効果的にあなたのクラスターのワークロードがこのようになっていて欲しいと伝えているのです。これが、あなたのクラスターの**望ましい状態**です。
Kubernetesオブジェクトを操作するには、作成、変更、または削除に関わらず[Kubernetes API](/docs/concepts/overview/kubernetes-api/)を使う必要があるでしょう。例えば`kubectl`コマンドラインインターフェースを使った場合、このCLIが処理に必要なKubernetes API命令を、あなたに代わり発行します。あなたのプログラムから[クライアントライブラリ](/docs/reference/using-api/client-libraries/)を利用し、直接Kubernetes APIを利用することも可能です。
Kubernetesオブジェクトを操作するには、作成、変更、または削除に関わらず[Kubernetes API](/ja/docs/concepts/overview/kubernetes-api/)を使う必要があるでしょう。例えば`kubectl`コマンドラインインターフェースを使った場合、このCLIが処理に必要なKubernetes API命令を、あなたに代わり発行します。あなたのプログラムから[クライアントライブラリ](/docs/reference/using-api/client-libraries/)を利用し、直接Kubernetes APIを利用することも可能です。
### オブジェクトのspec（仕様）とstatus（状態）
全てのKubernetesオブジェクトは、オブジェクトの設定を管理する２つの入れ子になったオブジェクトのフィールドを持っています。それは *spec* オブジェクトと *status* オブジェクトです。*spec* オブジェクトはあなたが指定しなければならない項目で、オブジェクトの *望ましい状態* を記述し、オブジェクトに持たせたい特徴を表現します。*status* オブジェクトはオブジェクトの *現在の状態* を示し、その情報はKubernetesから与えられ、更新されます。常に、Kubernetesコントロールプレーンは、あなたから指定された望ましい状態と現在の状態が一致するよう積極的に管理をします。
ほとんどのKubernetesオブジェクトは、オブジェクトの設定を管理する２つの入れ子になったオブジェクトのフィールドを持っています。それはオブジェクト *`spec`* とオブジェクト *`status`* です。`spec`を持っているオブジェクトに関しては、オブジェクト作成時に`spec`を設定する必要があり、望ましい状態としてオブジェクトに持たせたい特徴を記述する必要があります。
`status` オブジェクトはオブジェクトの *現在の状態* を示し、その情報はKubernetesから与えられ、更新されます。Kubernetes{{< glossary_tooltip text="コントロールプレーン" term_id="control-plane" >}}は、あなたから指定された望ましい状態と現在の状態が一致するよう常にかつ積極的に管理をします。
例えば、KubernetesのDeploymentはクラスター上で稼働するアプリケーションを表現するオブジェクトです。Deploymentを作成するとき、アプリケーションの複製を３つ稼働させるようDeploymentのspecで指定するかもしれません。KubernetesはDeploymentのspecを読み取り、指定されたアプリケーションを３つ起動し、現在の状態がspecに一致するようにします。もしこれらのインスタンスでどれかが落ちた場合（statusが変わる）、Kubernetesはspecと、statusの違いに反応し、修正しようとします。この場合は、落ちたインスタンスの代わりのインスタンスを立ち上げます。
@@ -58,9 +60,10 @@ Kubernetesオブジェクトを`.yaml`ファイルに記載して作成する場
* `apiVersion` - どのバージョンのKubernetesAPIを利用してオブジェクトを作成するか
* `kind` - どの種類のオブジェクトを作成するか
* `metadata` - オブジェクトを一意に特定するための情報、`name`、string、UID、また任意の`namespace`が該当する
* `metadata` - オブジェクトを一意に特定するための情報、文字列の`name`、`UID`、また任意の`namespace`が該当する
* `spec` - オブジェクトの望ましい状態
またオブジェクトの`spec`の値も指定する必要があります。`spec`の正確なフォーマットは、Kubernetesオブジェクトごとに異なり、オブジェクトごとに特有な入れ子のフィールドを持っています。[Kubernetes API リファレンス](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)が、Kubernetesで作成出来る全てのオブジェクトに関する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)をご確認ください。
@@ -68,6 +71,9 @@ Kubernetesオブジェクトを`.yaml`ファイルに記載して作成する場
## {{% heading "whatsnext" %}}
* [Kubernetes API overview](/docs/reference/using-api/api-overview/)はこのページでは取り上げていない他のAPIについて説明します。
* 最も重要、かつ基本的なKubernetesオブジェクト群を学びましょう、例えば、[Pod](/ja/docs/concepts/workloads/pods/pod-overview/)です。
* Kubernetesの[コントローラー](/docs/concepts/architecture/controller/)を学びましょう。
content/ja/docs/concepts/overview/working-with-objects/labels.md
+28 -4
View File
@@ -20,7 +20,7 @@ _ラベル(Labels)_ はPodなどのオブジェクトに割り当てられたキ
```
ラベルは効率的な検索・閲覧を可能にし、UIやCLI上での利用に最適です。
識別用途でない情報は、[アノテーション](/docs/concepts/overview/working-with-objects/annotations/)を用いて記録されるべきです。
識別用途でない情報は、[アノテーション](/ja/docs/concepts/overview/working-with-objects/annotations/)を用いて記録されるべきです。
@@ -45,7 +45,7 @@ _ラベル(Labels)_ はPodなどのオブジェクトに割り当てられたキ
これらは単によく使われるラベルの例です。ユーザーは自由に規約を決めることができます。
ラベルのキーは、ある1つのオブジェクトに対してユニークである必要があることは覚えておかなくてはなりません。
## 構文と文字セット
## 構文と文字セット {#syntax-and-character-set}
ラベルは、キーとバリューのベアです。正しいラベルキーは2つのセグメントを持ちます。
それは`/`によって分割されたオプショナルなプレフィックスと名前です。
@@ -59,7 +59,27 @@ _ラベル(Labels)_ はPodなどのオブジェクトに割り当てられたキ
正しいラベル値は63文字以下の長さで、空文字か、もしくは開始と終了が英数字(`[a-z0-9A-Z]`)で、文字列の間がダッシュ(`-`)、アンダースコア(`_`)、ドット(`.`)と英数字である文字列を使うことができます。
## ラベルセレクター
例えば、`environment: production`と`app: nginx`の2つのラベルを持つPodの設定ファイルは下記のようになります。
```yaml
apiVersion: v1
kind: Pod
metadata:
name: label-demo
labels:
environment: production
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80
```
## ラベルセレクター {#label-selectors}
[名前とUID](/docs/user-guide/identifiers)とは異なり、ラベルはユニーク性を提供しません。通常、多くのオブジェクトが同じラベルを保持することを想定します。
@@ -77,6 +97,10 @@ Kubernetes APIは現在2タイプのセレクターをサポートしていま
ReplicaSetなど、いくつかのAPIタイプにおいて、2つのインスタンスのラベルセレクターは単一の名前空間において重複してはいけません。重複していると、コントローラがそれらのラベルセレクターがコンフリクトした操作とみなし、どれだけの数のレプリカを稼働させるべきか決めることができなくなります。
{{< /note >}}
{{< caution >}}
等価ベース、集合ベースともに、論理OR (`||`) オペレーターは存在しません。フィルターステートメントが意図した通りになっていることを確認してください。
{{< /caution >}}
### *等価ベース(Equality-based)* の要件(requirement)
*等価ベース(Equality-based)* もしくは*不等ベース(Inequality-based)* の要件は、ラベルキーとラベル値によるフィルタリングを可能にします。
@@ -174,7 +198,7 @@ kubectl get pods -l 'environment,environment notin (frontend)'
```
### APIオブジェクトに参照を設定する
[`Service`](/docs/user-guide/services) と [`ReplicationController`](/docs/user-guide/replication-controller)のような、いくつかのKubernetesオブジェクトでは、ラベルセレクターを[Pod](/docs/user-guide/pods)のような他のリソースのセットを指定するのにも使われます。
[`Service`](/ja/docs/concepts/services-networking/service/) と [`ReplicationController`](/docs/concepts/workloads/controllers/replicationcontroller/)のような、いくつかのKubernetesオブジェクトでは、ラベルセレクターを[Pod](/ja/docs/concepts/workloads/pods/pod/)のような他のリソースのセットを指定するのにも使われます。
#### ServiceとReplicationController
`Service`が対象とするPodの集合は、ラベルセレクターによって定義されます。
content/ja/docs/concepts/overview/working-with-objects/names.md
+56 -7
View File
@@ -1,30 +1,79 @@
---
reviewers:
title: 名前
title: オブジェクトの名前とID
content_type: concept
weight: 20
---
<!-- overview -->
KubernetesのREST API内の全てのオブジェクトは、名前とUIDで明確に識別されます。
クラスター内の各オブジェクトには、そのタイプのリソースに固有の[_名前_](#names)があります。すべてのKubernetesオブジェクトには、クラスター全体で一意の[_UID_](#uids)もあります。
ユーザーが付与する一意ではない属性については、Kubernetesが[ラベル](/docs/user-guide/labels)と[アノテーション](/docs/concepts/overview/working-with-objects/annotations/)を付与します。
たとえば、同じ[名前空間](/docs/concepts/overview/working-with-objects/namespaces/)内に`myapp-1234`という名前のPodは1つしか含められませんが、`myapp-1234`という名前の1つのPodと1つのDeploymentを含めることができます。
名前とUIDに関する正確な構文については、[識別子デザインドキュメント](https://git.k8s.io/community/contributors/design-proposals/architecture/identifiers.md)を参照してください。
ユーザーが一意ではない属性を付与するために、Kubernetesは[ラベル](/ja/docs/concepts/overview/working-with-objects/labels/)と[アノテーション](/ja/docs/concepts/overview/working-with-objects/annotations/)を提供しています。
<!-- body -->
## 名前
## 名前 {#names}
{{< glossary_definition term_id="name" length="all" >}}
慣例的に、Kubernetesリソースの名前は最長253文字で、かつ英小文字、数字、また`-`、`.`から構成します。しかし、特定のリソースはより具体的な制限があります。
次の3つの命名規則がよく使われます。
## UID
### DNSサブドメイン名 {#dns-subdomain-names}
ほとんどのリソースタイプには、[RFC 1123](https://tools.ietf.org/html/rfc1123)で定義されているDNSサブドメイン名として使用できる名前が必要です。
つまり、名前は次のとおりでなければなりません:
- 253文字以内
- 英小文字、数字、「-」または「.」のみを含む
- 英数字で始まる
- 英数字で終わる
### DNSラベル名 {#dns-label-names}
一部のリソースタイプでは、[RFC 1123](https://tools.ietf.org/html/rfc1123)で定義されているDNSラベル標準に従う名前が必要です。
つまり、名前は次のとおりでなければなりません:
- 63文字以内
- 英小文字、数字または「-」のみを含む
- 英数字で始まる
- 英数字で終わる
### パスセグメント名 {#path-segment-names}
一部のリソースタイプでは、名前をパスセグメントとして安全にエンコードできるようにする必要があります。
つまり、名前を「.」や「..」にすることはできず、名前に「/」または「%」を含めることはできません。
以下は、`nginx-demo`という名前のPodのマニフェストの例です。
```yaml
apiVersion: v1
kind: Pod
metadata:
name: nginx-demo
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80
```
{{< note >}}
一部のリソースタイプには、名前に追加の制限があります。
{{< /note >}}
## UID {#uids}
{{< glossary_definition term_id="uid" length="all" >}}
Kubernetes UIDは、UUIDのことを指します。
UUIDは、ISO/IEC 9834-8およびITU-T X.667として標準化されています。
## {{% heading "whatsnext" %}}
* Kubernetesの[ラベル](/ja/docs/concepts/overview/working-with-objects/labels/)についてお読みください。
* [Kubernetesの識別子と名前](https://git.k8s.io/community/contributors/design-proposals/architecture/identifiers.md)デザインドキュメントをご覧ください。
content/ja/docs/concepts/overview/working-with-objects/namespaces.md
+32 -29
View File
@@ -6,8 +6,8 @@ weight: 30
<!-- overview -->
Kubernetesは、同一の物理クラスター上で複数の仮想クラスターの動作をサポートします。
この仮想クラスターをNamespaceと呼びます。
Kubernetesは、同一の物理クラスター上で複数の仮想クラスターの動作をサポートします。
この仮想クラスターをNamespaceと呼びます。
@@ -16,29 +16,29 @@ Kubernetesは、同一の物理クラスター上で複数の仮想クラスタ
## 複数のNamespaceを使う時
Namespaceは、複数のチーム・プロジェクトにまたがる多くのユーザーがいる環境での使用を目的としています。
Namespaceは、複数のチーム・プロジェクトにまたがる多くのユーザーがいる環境での使用を目的としています。
数人から数十人しかユーザーのいないクラスターに対して、あなたはNamespaceを作成したり、考える必要は全くありません。
Kubernetesが提供するNamespaceの機能が必要となった時に、Namespaceの使用を始めてください。
Kubernetesが提供するNamespaceの機能が必要となった時に、Namespaceの使用を始めてください。
Namespaceは名前空間のスコープを提供します。リソース名は単一のNamespace内ではユニークである必要がありますが、Namespace全体ではその必要はありません。
Namespaceは名前空間のスコープを提供します。リソース名は単一のNamespace内ではユニークである必要がありますが、Namespace全体ではその必要はありません。Namespaceは相互にネストすることはできず、各Kubernetesリソースは1つのNamespaceにのみ存在できます。
Namespaceは、複数のユーザーの間でクラスターリソースを分割する方法です。(これは[リソースクォータ](/docs/concepts/policy/resource-quotas/)を介して分割します。)
Namespaceは、複数のユーザーの間でクラスターリソースを分割する方法です。(これは[リソースクォータ](/docs/concepts/policy/resource-quotas/)を介して分割します。)
Kubernetesの将来的なバージョンにおいて、同一のNamespace内のオブジェクトは、デフォルトで同一のアクセスコントロールポリシーが適用されます。
同じアプリケーションの異なるバージョンなど、少し違うリソースをただ分割するだけに、複数のNamespaceを使う必要はありません。
同一のNamespace内でリソースを区別するためには[ラベル](/docs/user-guide/labels)を使用してください。
同じアプリケーションの異なるバージョンなど、少し違うリソースをただ分割するだけに、複数のNamespaceを使う必要はありません。
同一のNamespace内でリソースを区別するためには[ラベル](/ja/docs/concepts/overview/working-with-objects/labels/)を使用してください。
## Namespaceを利用する
Namespaceの作成と削除方法は[Namespaceの管理ガイドドキュメント](/docs/admin/namespaces)に記載されています。
Namespaceの作成と削除方法は[Namespaceの管理ガイドドキュメント](/docs/tasks/administer-cluster/namespaces/)に記載されています。
### Namespaceの表示
ユーザーは、以下の方法で単一クラスター内の現在のNamespaceの一覧を表示できます。
ユーザーは、以下の方法で単一クラスター内の現在のNamespaceの一覧を表示できます。
```shell
kubectl get namespaces
kubectl get namespace
```
```
NAME STATUS AGE
@@ -49,45 +49,46 @@ kube-public Active 1d
Kubernetesの起動時には3つの初期Namespaceが作成されています。
* `default` 他にNamespaceを持っていないオブジェクトのためのデフォルトNamespace
* `kube-system` Kubernetesシステムによって作成されたオブジェクトのためのNamespace
* `kube-public` このNamespaceは自動的に作成され、全てのユーザーから読み取り可能です。(認証されていないユーザーも含みます。)
* `default` 他にNamespaceを持っていないオブジェクトのためのデフォルトNamespace
* `kube-system` Kubernetesシステムによって作成されたオブジェクトのためのNamespace
* `kube-public` このNamespaceは自動的に作成され、全てのユーザーから読み取り可能です。(認証されていないユーザーも含みます。)
このNamespaceは、リソースをクラスター全体を通じてパブリックに表示・読み取り可能にするため、ほとんどクラスターによって使用される用途で予約されます。 このNamespaceのパブリックな側面は単なる慣例であり、要件ではありません。
### Namespaceの設定
一時的な要求のためにNamespaceを設定したい場合、`--namespace`フラグを使用します。
現在のリクエストのNamespaceを設定するには、`--namespace`フラグを使用します。
例:
```shell
kubectl --namespace=<insert-namespace-name-here> run nginx --image=nginx
kubectl --namespace=<insert-namespace-name-here> get pods
kubectl run nginx --image=nginx --namespace=<insert-namespace-name-here>
kubectl get pods --namespace=<insert-namespace-name-here>
```
### Namespace設定の永続化
ユーザーはあるコンテキストのその後のコマンドで使うために、コンテキスト内で永続的にNamespaceを保存できます。
ユーザーはあるコンテキストのその後のコマンドで使うために、コンテキスト内で永続的にNamespaceを保存できます。
```shell
kubectl config set-context $(kubectl config current-context) --namespace=<insert-namespace-name-here>
kubectl config set-context --current --namespace=<insert-namespace-name-here>
# Validate it
kubectl config view | grep namespace:
kubectl config view --minify | grep namespace:
```
## NamespaceとDNS
ユーザーが[Service](/docs/user-guide/services)を作成するとき、Serviceは対応する[DNSエントリ](/docs/concepts/services-networking/dns-pod-service/)を作成します。
このエントリは`<service-name>.<namespace-name>.svc.cluster.local`という形式になり,これはもしあるコンテナがただ`<service-name>`を指定していた場合、Namespace内のローカルのServiceに対して名前解決されます。
これはデベロップメント、ステージング、プロダクションといって複数のNamespaceをまたいで同じ設定を使う時に効果的です。
もしユーザーがNamespaceをまたいでアクセスしたい時、 完全修飾ドメイン名(FQDN)を指定する必要があります。
ユーザーが[Service](/ja/docs/concepts/services-networking/service/)を作成するとき、Serviceは対応する[DNSエントリ](/ja/docs/concepts/services-networking/dns-pod-service/)を作成します。
このエントリは`<service-name>.<namespace-name>.svc.cluster.local`という形式になり,これはもしあるコンテナがただ`<service-name>`を指定していた場合、Namespace内のローカルのServiceに対して名前解決されます。
これはデベロップメント、ステージング、プロダクションといって複数のNamespaceをまたいで同じ設定を使う時に効果的です。
もしユーザーがNamespaceをまたいでアクセスしたい時、 完全修飾ドメイン名(FQDN)を指定する必要があります。
## すべてのオブジェクトはNamespaceに属しているとは限らない
ほとんどのKubernetesリソース(例えば、Pod、Service、ReplicationControllerなど)はいくつかのNamespaceにあります。
しかしNamespaceのリソースそれ自体は単一のNamespace内にありません。
そして[Node](/docs/admin/node)やPersistentVolumeのような低レベルのリソースはどのNamespaceにも属していません。
ほとんどのKubernetesリソース(例えば、Pod、Service、ReplicationControllerなど)はいくつかのNamespaceにあります。
しかしNamespaceのリソースそれ自体は単一のNamespace内にありません。
そして[Node](/ja/docs/concepts/architecture/nodes/)やPersistentVolumeのような低レベルのリソースはどのNamespaceにも属していません。
どのKubernetesリソースがNamespaceに属しているか、属していないかを見るためには、以下のコマンドで確認できます。
どのKubernetesリソースがNamespaceに属しているか、属していないかを見るためには、以下のコマンドで確認できます。
```shell
# Namespaceに属しているもの
@@ -97,4 +98,6 @@ kubectl api-resources --namespaced=true
kubectl api-resources --namespaced=false
```
## {{% heading "whatsnext" %}}
* [新しいNamespaceの作成](/docs/tasks/administer-cluster/namespaces/#creating-a-new-namespace)について学習してください。
* [Namespaceの削除](/docs/tasks/administer-cluster/namespaces/#deleting-a-namespace)について学習してください。
content/ja/docs/concepts/policy/_index.md
Executable
+5
View File
@@ -0,0 +1,5 @@
---
title: "ポリシー"
weight: 90
---
content/ja/docs/concepts/policy/resource-quotas.md
+556
View File
@@ -0,0 +1,556 @@
---
reviewers:
title: リソースクォータ
content_template: templates/concept
weight: 10
---
{{% capture overview %}}
複数のユーザーやチームが決められた数のノードを持つクラスターを共有しているとき、1つのチームが公平に使えるリソース量を超えて使用するといった問題が出てきます。
リソースクォータはこの問題に対処するための管理者向けツールです。
{{% /capture %}}
{{% capture body %}}
`ResourceQuota`オブジェクトによって定義されるリソースクォータは、名前空間ごとの総リソース消費を制限するための制約を提供します。リソースクォータは同じ名前空間のクラスター内でタイプごとに作成できるオブジェクト数や、プロジェクト内のリソースによって消費されるコンピュートリソースの総量を制限できます。
リソースクォータは下記のように働きます。
- 異なる名前空間で異なるチームが存在するとき。現時点ではこれは自主的なものですが、将来的にはACLsを介してリソースクォータの設定を強制するように計画されています。
- 管理者は各名前空間で1つの`ResourceQuota`を作成します。
- ユーザーが名前空間内でリソース(Pod、Serviceなど)を作成し、クォータシステムが`ResourceQuota`によって定義されたハードリソースリミットを超えないことを保証するために、リソースの使用量をトラッキングします。
- リソースの作成や更新がクォータの制約に違反しているとき、そのリクエストはHTTPステータスコード`403 FORBIDDEN`で失敗し、違反した制約を説明するメッセージが表示されます。
- `cpu`や`memory`といったコンピューターリソースに対するクォータが名前空間内で有効になっているとき、ユーザーはそれらの値に対する`requests`や`limits`を設定する必要があります。設定しないとクォータシステムがPodの作成を拒否します。 ヒント: コンピュートリソースの要求を設定しないPodに対してデフォルト値を強制するために、`LimitRanger`アドミッションコントローラーを使用してください。この問題を解決する例は[walkthrough](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/)で参照できます。
`ResourceQuota`のオブジェクト名は、有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります.
名前空間とクォータを使用して作成できるポリシーの例は以下の通りです。
- 32GiB RAM、16コアのキャパシティーを持つクラスターで、Aチームに20GiB、10コアを割り当て、Bチームに10GiB、4コアを割り当て、将来の割り当てのために2GiB、2コアを予約しておく。
- "testing"という名前空間に対して1コア、1GiB RAMの使用制限をかけ、"production"という名前空間には制限をかけない。
クラスターの総キャパシティーが、その名前空間のクォータの合計より少ない場合、リソースの競合が発生する場合があります。このとき、リソースの先着順で処理されます。
リソースの競合もクォータの変更も、作成済みのリソースには影響しません。
## リソースクォータを有効にする
多くのKubernetesディストリビューションにおいてリソースクォータはデフォルトで有効になっています。APIサーバーで`--enable-admission-plugins=`の値に`ResourceQuota`が含まれるときに有効になります。
特定の名前空間に`ResourceQuota`があるとき、そのリソースクォータはその名前空間に適用されます。
## リソースクォータの計算
特定の名前空間において、[コンピュートリソース](/docs/concepts/configuration/manage-resources-containers/)の合計に上限を設定できます。
下記のリソースタイプがサポートされています。
| リソース名 | 説明 |
| --------------------- | ----------------------------------------------------------- |
| `limits.cpu` | 停止していない状態の全てのPodで、CPUリミットの合計がこの値を超えることができません。 |
| `limits.memory` | 停止していない状態の全てのPodで、メモリーの合計がこの値を超えることができません。 |
| `requests.cpu` | 停止していない状態の全てのPodで、CPUリクエストの合計がこの値を超えることができません。 |
| `requests.memory` | 停止していない状態の全てのPodで、メモリーリクエストの合計がこの値を超えることができません。 |
### 拡張リソースのためのリソースクォータ
上記で取り上げたリソースに加えて、Kubernetes v1.10において、[拡張リソース](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources)のためのリソースクォータのサポートが追加されました。
拡張リソースに対するオーバーコミットが禁止されているのと同様に、リソースクォータで拡張リソース用に`requests`と`lmits`の両方を指定しても意味がありません。現在、拡張リソースに対しては`requests.`というプレフィックスのついたクォータアイテムのみ設定できます。
GPUリソースを例にすると、もしリソース名が`nvidia.com/gpu`で、ユーザーが名前空間内でリクエストされるGPUの上限を4に指定するとき、下記のようにリソースクォータを定義します。
* `requests.nvidia.com/gpu: 4`
さらなる詳細は[クォータの確認と設定](#viewing-and-setting-quotas)を参照してください。
## ストレージのリソースクォータ
特定の名前空間において[ストレージリソース](/ja/docs/concepts/storage/persistent-volumes/)の総数に上限をかけることができます。
さらに、関連するストレージクラスに基づいて、ストレージリソースの消費量に上限をかけることもできます。
| リソース名 | 説明 |
| --------------------- | ----------------------------------------------------------- |
| `requests.storage` | 全てのPersistentVolumeClaimにおいて、ストレージのリクエストの合計がこの値を超えないようにします。 |
| `persistentvolumeclaims` | 特定の名前空間内で作成可能な[PersistentVolumeClaim](/ja/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)の総数。 |
| `<storage-class-name>.storageclass.storage.k8s.io/requests.storage` | ストレージクラス名に関連する全てのPersistentVolumeClaimにおいて、ストレージリクエストの合計がこの値を超えないようにします。 |
| `<storage-class-name>.storageclass.storage.k8s.io/persistentvolumeclaims` | ストレージクラス名に関連する全てのPersistentVolumeClaimにおいて、特定の名前空間内で作成可能な[PersistentVolumeClaim](/ja/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)の総数。 |
例えば、もし管理者が`gold`ストレージクラスを`bronze`ストレージクラスと分けてリソースクォータを設定するとき、管理者はリソースクォータを下記のように指定できます。
* `gold.storageclass.storage.k8s.io/requests.storage: 500Gi`
* `bronze.storageclass.storage.k8s.io/requests.storage: 100Gi`
Kubernetes v1.8において、ローカルのエフェメラルストレージに対するリソースクォータのサポートがα版の機能として追加されました。
| リソース名 | 説明 |
| ------------------------------- |----------------------------------------------------------- |
| `requests.ephemeral-storage` | 名前空間内の全てのPodで、ローカルのエフェメラルストレージのリクエストの合計がこの値を超えないようにします。 |
| `limits.ephemeral-storage` | 名前空間内の全てのPodで、ローカルのエフェメラルストレージのリミットの合計がこの値を超えないようにします。 |
## オブジェクト数に対するクォータ
Kubernetes v1.9では下記のシンタックスを使用して、名前空間に紐づいた全ての標準リソースタイプに対するリソースクォータのサポートが追加されました。
* `count/<resource>.<group>`
オブジェクト数に対するクォータでユーザーが設定するリソースの例は下記の通りです。
* `count/persistentvolumeclaims`
* `count/services`
* `count/secrets`
* `count/configmaps`
* `count/replicationcontrollers`
* `count/deployments.apps`
* `count/replicasets.apps`
* `count/statefulsets.apps`
* `count/jobs.batch`
* `count/cronjobs.batch`
* `count/deployments.extensions`
Kubernetes v1.15において、同一のシンタックスを使用して、カスタムリソースに対するサポートが追加されました。例えば、`example.com`というAPIグループ内の`widgets`というカスタムリソースのリソースクォータを設定するには`count/widgets.example.com`と記述します。
`count/*`リソースクォータの使用において、オブジェクトがサーバーストレージに存在するときオブジェクトはクォータの計算対象となります。このようなタイプのリソースクォータはストレージリソース浪費の防止に有効です。例えば、もしSecretが大量に存在するとき、そのSecretリソースの総数に対してリソースクォータの制限をかけたい場合です。クラスター内でSecretが大量にあると、サーバーとコントローラーの起動を妨げることになります！また、適切に設定されていないCronJobが名前空間内で大量のJobを作成し、サービスが利用不可能になることを防ぐためにリソースクォータを設定できます。
Kubernetes v1.9より前のバージョンでは、限定されたリソースのセットにおいて汎用オブジェクトカウントのリソースクォータを実行可能でした。さらに、特定のリソースに対するリソースクォータを種類ごとに制限することができます。
下記のタイプのリソースがサポートされています。
| リソース名 | 説明 |
| ------------------------------- | ------------------------------------------------- |
| `configmaps` | 名前空間内で存在可能なConfigMapの総数。 |
| `persistentvolumeclaims` | 名前空間内で存在可能な[PersistentVolumeClaim](/ja/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)の総数。 |
| `pods` | 名前空間内で存在可能な停止していないPodの総数。`.status.phase in (Failed, Succeeded)`がtrueのとき、Podは停止状態にあります。 |
| `replicationcontrollers` | 名前空間内で存在可能なReplicationControlerの総数。 |
| `resourcequotas` | 名前空間内で存在可能な[リソースクォータ](/docs/reference/access-authn-authz/admission-controllers/#resourcequota)の総数。 |
| `services` | 名前空間内で存在可能なServiceの総数。 |
| `services.loadbalancers` | 名前空間内で存在可能なtype:LoadBalancerであるServiceの総数。 |
| `services.nodeports` | 名前空間内で存在可能なtype:NodePortであるServiceの総数。 |
| `secrets` | 名前空間内で存在可能なSecretの総数。 |
例えば、`pods`のリソースクォータは`Pod`の総数をカウントし、特定の名前空間内で作成された`Pod`の総数の最大数を設定します。またユーザーが多くのPodを作成し、クラスターのPodのIPが枯渇する状況を避けるために`pods`のリソースクォータを名前空間に設定したい場合があります。
## クォータのスコープについて
各リソースクォータには関連するスコープのセットを関連づけることができます。クォータは、列挙されたスコープの共通部分と一致する場合にのみリソースの使用量を計測します。
スコープがクォータに追加されると、サポートするリソースの数がスコープに関連するリソースに制限されます。許可されたセット以外のクォータ上でリソースを指定するとバリデーションエラーになります。
| スコープ | 説明 |
| ----- | ----------- |
| `Terminating` | `.spec.activeDeadlineSeconds >= 0`であるPodに一致します。 |
| `NotTerminating` | `.spec.activeDeadlineSecondsがnil`であるPodに一致します。 |
| `BestEffort` | ベストエフォート型のサービス品質のPodに一致します。 |
| `NotBestEffort` | ベストエフォート型のサービス品質でないPodに一致します。 |
`BestEffort`スコープはリソースクォータを次のリソースに対するトラッキングのみに制限します: `pods`
`Terminating`、`NotTerminating`、`NotBestEffort`スコープは、リソースクォータを次のリソースに対するトラッキングのみに制限します:
* `cpu`
* `limits.cpu`
* `limits.memory`
* `memory`
* `pods`
* `requests.cpu`
* `requests.memory`
### PriorityClass毎のリソースクォータ
{{< feature-state for_k8s_version="1.12" state="beta" >}}
Podは特定の[優先度](/docs/concepts/configuration/pod-priority-preemption/#pod-priority)で作成されます。リソースクォータのSpec内にある`scopeSelector`フィールドを使用して、Podの優先度に基づいてPodのシステムリソースの消費をコントロールできます。
リソースクォータのSpec内の`scopeSelector`によってPodが選択されたときのみ、そのリソースクォータが一致し、消費されます。
この例ではリソースクォータのオブジェクトを作成し、特定の優先度を持つPodに一致させます。この例は下記のように動作します。
- クラスター内のPodは"low"、"medium"、"high"の3つの優先度クラスのうち1つをもちます。
- 1つのリソースクォータのオブジェクトは優先度毎に作成されます。
下記のYAMLを`quota.yml`というファイルに保存します。
```yaml
apiVersion: v1
kind: List
items:
- apiVersion: v1
kind: ResourceQuota
metadata:
name: pods-high
spec:
hard:
cpu: "1000"
memory: 200Gi
pods: "10"
scopeSelector:
matchExpressions:
- operator : In
scopeName: PriorityClass
values: ["high"]
- apiVersion: v1
kind: ResourceQuota
metadata:
name: pods-medium
spec:
hard:
cpu: "10"
memory: 20Gi
pods: "10"
scopeSelector:
matchExpressions:
- operator : In
scopeName: PriorityClass
values: ["medium"]
- apiVersion: v1
kind: ResourceQuota
metadata:
name: pods-low
spec:
hard:
cpu: "5"
memory: 10Gi
pods: "10"
scopeSelector:
matchExpressions:
- operator : In
scopeName: PriorityClass
values: ["low"]
```
`kubectl create`を実行してYAMLの内容を適用します。
```shell
kubectl create -f ./quota.yml
```
```shell
resourcequota/pods-high created
resourcequota/pods-medium created
resourcequota/pods-low created
```
`kubectl describe quota`を実行して`Used`クォータが`0`であることを確認します。
```shell
kubectl describe quota
```
```shell
Name: pods-high
Namespace: default
Resource Used Hard
-------- ---- ----
cpu 0 1k
memory 0 200Gi
pods 0 10
Name: pods-low
Namespace: default
Resource Used Hard
-------- ---- ----
cpu 0 5
memory 0 10Gi
pods 0 10
Name: pods-medium
Namespace: default
Resource Used Hard
-------- ---- ----
cpu 0 10
memory 0 20Gi
pods 0 10
```
プライオリティーが"high"であるPodを作成します。下記の内容を`high-priority-pod.yml`というファイルに保存します。
```yaml
apiVersion: v1
kind: Pod
metadata:
name: high-priority
spec:
containers:
- name: high-priority
image: ubuntu
command: ["/bin/sh"]
args: ["-c", "while true; do echo hello; sleep 10;done"]
resources:
requests:
memory: "10Gi"
cpu: "500m"
limits:
memory: "10Gi"
cpu: "500m"
priorityClassName: high
```
`kubectl create`でマニフェストを適用します。
```shell
kubectl create -f ./high-priority-pod.yml
```
`pods-high`という名前のプライオリティーが"high"のクォータにおける"Used"項目の値が変更され、それ以外の2つの値は変更されていないことを確認してください。
```shell
kubectl describe quota
```
```shell
Name: pods-high
Namespace: default
Resource Used Hard
-------- ---- ----
cpu 500m 1k
memory 10Gi 200Gi
pods 1 10
Name: pods-low
Namespace: default
Resource Used Hard
-------- ---- ----
cpu 0 5
memory 0 10Gi
pods 0 10
Name: pods-medium
Namespace: default
Resource Used Hard
-------- ---- ----
cpu 0 10
memory 0 20Gi
pods 0 10
```
`scopeSelector`は`operator`フィールドにおいて下記の値をサポートしています。
* `In`
* `NotIn`
* `Exist`
* `DoesNotExist`
## リクエスト vs リミット
コンピュートリソースを分配する際に、各コンテナはCPUとメモリーそれぞれのリクエストとリミット値を指定します。クォータはそれぞれの値を設定できます。
クォータに`requests.cpu`や`requests.memory`の値が指定されている場合は、コンテナはそれらのリソースに対する明示的な要求を行います。同様に、クォータに`limits.cpu`や`limits.memory`の値が指定されている場合は、コンテナはそれらのリソースに対する明示的な制限を行います。
## クォータの確認と設定 {#viewing-and-setting-quotas}
kubectlでは、クォータの作成、更新、確認をサポートしています。
```shell
kubectl create namespace myspace
```
```shell
cat <<EOF > compute-resources.yaml
apiVersion: v1
kind: ResourceQuota
metadata:
name: compute-resources
spec:
hard:
requests.cpu: "1"
requests.memory: 1Gi
limits.cpu: "2"
limits.memory: 2Gi
requests.nvidia.com/gpu: 4
EOF
```
```shell
kubectl create -f ./compute-resources.yaml --namespace=myspace
```
```shell
cat <<EOF > object-counts.yaml
apiVersion: v1
kind: ResourceQuota
metadata:
name: object-counts
spec:
hard:
configmaps: "10"
persistentvolumeclaims: "4"
pods: "4"
replicationcontrollers: "20"
secrets: "10"
services: "10"
services.loadbalancers: "2"
EOF
```
```shell
kubectl create -f ./object-counts.yaml --namespace=myspace
```
```shell
kubectl get quota --namespace=myspace
```
```shell
NAME AGE
compute-resources 30s
object-counts 32s
```
```shell
kubectl describe quota compute-resources --namespace=myspace
```
```shell
Name: compute-resources
Namespace: myspace
Resource Used Hard
-------- ---- ----
limits.cpu 0 2
limits.memory 0 2Gi
requests.cpu 0 1
requests.memory 0 1Gi
requests.nvidia.com/gpu 0 4
```
```shell
kubectl describe quota object-counts --namespace=myspace
```
```shell
Name: object-counts
Namespace: myspace
Resource Used Hard
-------- ---- ----
configmaps 0 10
persistentvolumeclaims 0 4
pods 0 4
replicationcontrollers 0 20
secrets 1 10
services 0 10
services.loadbalancers 0 2
```
また、kubectlは`count/<resource>.<group>`というシンタックスを用いることにより、名前空間に依存した全ての主要なリソースに対するオブジェクト数のクォータをサポートしています。
```shell
kubectl create namespace myspace
```
```shell
kubectl create quota test --hard=count/deployments.extensions=2,count/replicasets.extensions=4,count/pods=3,count/secrets=4 --namespace=myspace
```
```shell
kubectl run nginx --image=nginx --replicas=2 --namespace=myspace
```
```shell
kubectl describe quota --namespace=myspace
```
```shell
Name: test
Namespace: myspace
Resource Used Hard
-------- ---- ----
count/deployments.extensions 1 2
count/pods 2 3
count/replicasets.extensions 1 4
count/secrets 1 4
```
## クォータとクラスター容量
`ResourceQuotas`はクラスター容量に依存しません。またユニット数の絶対値で表されます。そのためクラスターにノードを追加したことにより、各名前空間が自動的により多くのリソースを消費するような機能が提供されるわけでは*ありません*。
下記のようなより複雑なポリシーが必要な状況があります。
- 複数チーム間でクラスターリソースの総量を分けあう。
- 各テナントが必要な時にリソース使用量を増やせるようにするが、偶発的なリソースの枯渇を防ぐために上限を設定する。
- 1つの名前空間に対してリソース消費の需要を検出し、ノードを追加し、クォータを増加させる。
このようなポリシーは、クォータの使用量の監視と、他のシグナルにしたがってクォータのハードの制限を調整する"コントローラー"を記述することにより、`ResourceQuotas`をビルディングブロックのように使用して実装できます。
リソースクォータは集約されたクラスターリソースを分割しますが、ノードに対しては何の制限も行わないことに注意して下さい。例: 複数の名前空間のPodは同一のノード上で稼働する可能性があります。
## デフォルトで優先度クラスの消費を制限する
例えば"cluster-services"のように、条件に一致するクォータオブジェクトが存在する場合に限り、特定の優先度のPodを名前空間で許可することが望ましい場合があります。
このメカニズムにより、オペレーターは特定の高優先度クラスの使用を限られた数の名前空間に制限することができ、全ての名前空間でこれらの優先度クラスをデフォルトで使用することはできなくなります。
これを実施するには、kube-apiserverの`--admission-control-config-file`というフラグを使い、下記の設定ファイルに対してパスを渡す必要がります。
{{< tabs name="example1" >}}
{{% tab name="apiserver.config.k8s.io/v1" %}}
```yaml
apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
- name: "ResourceQuota"
configuration:
apiVersion: apiserver.config.k8s.io/v1
kind: ResourceQuotaConfiguration
limitedResources:
- resource: pods
matchScopes:
- scopeName: PriorityClass
operator: In
values: ["cluster-services"]
```
{{% /tab %}}
{{% tab name="apiserver.k8s.io/v1alpha1" %}}
```yaml
# v1.17では非推奨になり、apiserver.config.k8s.io/v1の使用を推奨します。
apiVersion: apiserver.k8s.io/v1alpha1
kind: AdmissionConfiguration
plugins:
- name: "ResourceQuota"
configuration:
# v1.17では非推奨になり、apiserver.config.k8s.io/v1、ResourceQuotaConfigurationの使用を推奨します。
apiVersion: resourcequota.admission.k8s.io/v1beta1
kind: Configuration
limitedResources:
- resource: pods
matchScopes:
- scopeName: PriorityClass
operator: In
values: ["cluster-services"]
```
{{% /tab %}}
{{< /tabs >}}
なお、"cluster-services"Podは、条件に一致する`scopeSelector`を持つクォータオブジェクトが存在する名前空間でのみ許可されます。
```yaml
scopeSelector:
matchExpressions:
- scopeName: PriorityClass
operator: In
values: ["cluster-services"]
```
さらなる情報は、[LimitedResources](https://github.com/kubernetes/kubernetes/pull/36765)と[優先度クラスに対するクォータサポートの design doc](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/pod-priority-resourcequota.md)を参照してください。
## 例
[リソースクォータの使用方法の例](/docs/tasks/administer-cluster/quota-api-object/)を参照してください。
{{% /capture %}}
{{% capture whatsnext %}}
さらなる情報は[クォータの design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md)を参照してください。
{{% /capture %}}
content/ja/docs/concepts/scheduling/kube-scheduler.md
+12 -10
View File
@@ -20,16 +20,16 @@ Podが特定のNodeに割り当てられる理由を理解したい場合や、
## kube-scheduler
[kube-scheduler](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-scheduler/)はKubernetesにおけるデフォルトのスケジューラーで、{{< glossary_tooltip text="コントロールプレーン" term_id="control-plane" >}}の一部分として稼働します。
[kube-scheduler](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-scheduler/)はKubernetesにおけるデフォルトのスケジューラーで、{{< glossary_tooltip text="コントロールプレーン" term_id="control-plane" >}}の一部分として稼働します。
kube-schedulerは、もし希望するのであれば自分自身でスケジューリングのコンポーネントを実装でき、それを代わりに使用できるように設計されています。
kube-schedulerは、新規に作成された各Podや他のスケジューリングされていないPodを稼働させるために最適なNodeを選択します。
kube-schedulerは、新規に作成された各Podや他のスケジューリングされていないPodを稼働させるために最適なNodeを選択します。
しかし、Pod内の各コンテナにはそれぞれ異なるリソースの要件があり、各Pod自体にもそれぞれ異なる要件があります。そのため、既存のNodeは特定のスケジューリング要求によってフィルターされる必要があります。
クラスター内でPodに対する割り当て要求を満たしたNodeは_割り当て可能_ なNodeと呼ばれます。
クラスター内でPodに対する割り当て要求を満たしたNodeは_割り当て可能_ なNodeと呼ばれます。
もし適切なNodeが一つもない場合、スケジューラーがNodeを割り当てることができるまで、そのPodはスケジュールされずに残ります。
スケジューラーはPodに対する割り当て可能なNodeをみつけ、それらの割り当て可能なNodeにスコアをつけます。その中から最も高いスコアのNodeを選択し、Podに割り当てるためのいくつかの関数を実行します。
スケジューラーはPodに対する割り当て可能なNodeをみつけ、それらの割り当て可能なNodeにスコアをつけます。その中から最も高いスコアのNodeを選択し、Podに割り当てるためのいくつかの関数を実行します。
スケジューラーは_binding_ と呼ばれる処理中において、APIサーバーに対して割り当てが決まったNodeの情報を通知します。
スケジューリングを決定する上で考慮が必要な要素としては、個別または複数のリソース要求や、ハードウェア/ソフトウェアのポリシー制約、affinityやanti-affinityの設定、データの局所性や、ワークロード間での干渉などが挙げられます。
@@ -42,10 +42,10 @@ kube-schedulerは2ステップの操作によってPodに割り当てるNodeを
2. スコアリング
_フィルタリング_ ステップでは、Podに割り当て可能なNodeのセットを探します。例えばPodFitsResourcesフィルターは、Podのリソース要求を満たすのに十分なリソースをもつNodeがどれかをチェックします。このステップの後、候補のNodeのリストは、要求を満たすNodeを含みます。
_フィルタリング_ ステップでは、Podに割り当て可能なNodeのセットを探します。例えばPodFitsResourcesフィルターは、Podのリソース要求を満たすのに十分なリソースをもつNodeがどれかをチェックします。このステップの後、候補のNodeのリストは、要求を満たすNodeを含みます。
たいてい、リストの要素は複数となります。もしこのリストが空の場合、そのPodはスケジュール可能な状態とはなりません。
_スコアリング_ ステップでは、Podを割り当てるのに最も適したNodeを選択するために、スケジューラーはリストの中のNodeをランク付けします。
_スコアリング_ ステップでは、Podを割り当てるのに最も適したNodeを選択するために、スケジューラーはリストの中のNodeをランク付けします。
スケジューラーは、フィルタリングによって選ばれた各Nodeに対してスコアを付けます。このスコアはアクティブなスコア付けのルールに基づいています。
最後に、kube-schedulerは最も高いランクのNodeに対してPodを割り当てます。もし同一のスコアのNodeが複数ある場合は、kube-schedulerがランダムに1つ選択します。
@@ -56,7 +56,7 @@ kube-schedulerは、デフォルトで用意されているスケジューリン
### フィルタリング
- `PodFitsHostPorts`: Nodeに、Podが要求するポートが利用可能かどうかをチェックします。
- `PodFitsHostPorts`: Nodeに、Podが要求するポートが利用可能かどうかをチェックします。
- `PodFitsHost`: Podがそのホスト名において特定のNodeを指定しているかをチェックします。
@@ -106,7 +106,7 @@ kube-schedulerは、デフォルトで用意されているスケジューリン
- `ServiceSpreadingPriority`: このポリシーの目的は、特定のServiceに対するバックエンドのPodが、それぞれ異なるNodeで実行されるようにすることです。このポリシーではServiceのバックエンドのPodが既に実行されていないNode上にスケジュールするように優先します。これによる結果として、Serviceは単体のNode障害に対してより耐障害性が高まります。
- `CalculateAntiAffinityPriorityMap`: このポリシーは[PodのAnti-Affinity](https://kubernetes.io/ja/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity)の実装に役立ちます。
- `CalculateAntiAffinityPriorityMap`: このポリシーは[PodのAnti-Affinity](/ja/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity)の実装に役立ちます。
- `EqualPriorityMap`: 全てのNodeに対して等しい重みを与えます。
@@ -114,6 +114,8 @@ kube-schedulerは、デフォルトで用意されているスケジューリン
## {{% heading "whatsnext" %}}
* [スケジューラーのパフォーマンスチューニング](/docs/concepts/scheduling/scheduler-perf-tuning/)を参照してください。
* [Podトポロジーの分散制約](/docs/concepts/workloads/pods/pod-topology-spread-constraints/)を参照してください。
* kube-schedulerの[リファレンスドキュメント](/docs/reference/command-line-tools-reference/kube-scheduler/)を参照してください。
* [複数のスケジューラーの設定](https://kubernetes.io/docs/tasks/administer-cluster/configure-multiple-schedulers/)について学んでください。
* [複数のスケジューラーの設定](/docs/tasks/administer-cluster/configure-multiple-schedulers/)について学んでください。
* [トポロジーの管理ポリシー](/docs/tasks/administer-cluster/topology-manager/)について学んでください。
* [Podのオーバーヘッド](/docs/concepts/configuration/pod-overhead/)について学んでください。
content/ja/docs/concepts/services-networking/connect-applications-service.md
+1 -1
View File
@@ -77,7 +77,7 @@ Kubernetes Serviceは、クラスター内のどこかで実行されるPodの
このアドレスはServiceの有効期間に関連付けられており、Serviceが動作している間は変更されません。
Podは、Serviceと通信するように構成でき、Serviceへの通信は、ServiceのメンバーであるPodに自動的に負荷分散されることを認識できます。
2つのnginxレプリカのサービスを`kubectl exposed`で作成できます:
2つのnginxレプリカのサービスを`kubectl expose`で作成できます:
```shell
kubectl expose deployment/my-nginx
content/ja/docs/concepts/services-networking/dns-pod-service.md
+8 -14
View File
@@ -25,13 +25,13 @@ Kubernetesの`bar`というネームスペース内で`foo`という名前のSer
うまく機能する他のレイアウト、名前、またはクエリーは、実装の詳細を考慮し、警告なしに変更されることがあります。
最新の仕様に関する詳細は、[KubernetesにおけるDNSベースのServiceディスカバリ](https://github.com/kubernetes/dns/blob/master/docs/specification.md)を参照ください。
## Service
## Service {#services}
### Aレコード
### A/AAAAレコード
"通常の"(Headlessでない)Serviceは、`my-svc.my-namespace.svc.cluster.local`という形式のDNS Aレコードを割り当てられます。このAレコードはそのServiceのClusterIPへと名前解決されます。
"通常の"(Headlessでない)Serviceは、`my-svc.my-namespace.svc.cluster.local`という形式のDNS A(AAAA)レコードを、ServiceのIPバージョンに応じて割り当てられます。このAレコードはそのServiceのClusterIPへと名前解決されます。
"Headless"(ClusterIPなしの)Serviceもまた`my-svc.my-namespace.svc.cluster.local`という形式のDNS Aレコードを割り当てられます。通常のServiceとは異なり、このAレコードはServiceによって選択されたPodのIPの一覧へと名前解決されます。クライアントはこの一覧のIPを使うか、その一覧から標準のラウンドロビン方式によって選択されたIPを使います…
"Headless"(ClusterIPなしの)Serviceもまた`my-svc.my-namespace.svc.cluster.local`という形式のDNS A(AAAA)レコードを、ServiceのIPバージョンに応じて割り当てられます。通常のServiceとは異なり、このレコードはServiceによって選択されたPodのIPの一覧へと名前解決されます。クライアントはこの一覧のIPを使うか、その一覧から標準のラウンドロビン方式によって選択されたIPを使います。
### SRVレコード
@@ -42,12 +42,6 @@ Headless Serviceに対しては、このSRVレコードは複数の結果を返
## Pod
### Aレコード
DNSが有効なとき、Podは"`pod-ip-address.my-namespace.pod.cluster.local`"という形式のAレコードを割り当てられます。
例えば、`default`ネームスペース内で`cluster.local`というDNS名を持ち、`1.2.3.4`というIPを持ったPodは次の形式のエントリーを持ちます。: `1-2-3-4.default.pod.cluster.local`。
### Podのhostnameとsubdomainフィールド
現在、Podが作成されたとき、そのPodのホスト名はPodの`metadata.name`フィールドの値となります。
@@ -105,13 +99,13 @@ spec:
name: busybox
```
もしそのPodと同じネームスペース内で、同じサブドメインを持ったHeadless Serviceが存在していた場合、クラスターのKubeDNSサーバーもまた、そのPodの完全修飾ドメイン名(FQDN)に対するAレコードを返します。
例えば、"`busybox-1`"というホスト名で、"`default-subdomain`"というサブドメインを持ったPodと、そのPodと同じネームスペース内にある"`default-subdomain`"という名前のHeadless Serviceがあると考えると、そのPodは自身の完全修飾ドメイン名(FQDN)を"`busybox-1.default-subdomain.my-namespace.svc.cluster.local`"として扱います。DNSはそのPodのIPを指し示すAレコードを返します。"`busybox1`"と"`busybox2`"の両方のPodはそれぞれ独立したAレコードを持ちます。
もしそのPodと同じネームスペース内で、同じサブドメインを持ったHeadless Serviceが存在していた場合、クラスターのDNSサーバーもまた、そのPodの完全修飾ドメイン名(FQDN)に対するA(AAAA)レコードを返します。
例えば、"`busybox-1`"というホスト名で、"`default-subdomain`"というサブドメインを持ったPodと、そのPodと同じネームスペース内にある"`default-subdomain`"という名前のHeadless Serviceがあると考えると、そのPodは自身の完全修飾ドメイン名(FQDN)を"`busybox-1.default-subdomain.my-namespace.svc.cluster.local`"として扱います。DNSはそのPodのIPを指し示すA(AAAA)レコードを返します。"`busybox1`"と"`busybox2`"の両方のPodはそれぞれ独立したA(AAAA)レコードを持ちます。
そのエンドポイントオブジェクトはそのIPに加えて`hostname`を任意のエンドポイントアドレスに対して指定できます。
{{< note >}}
AレコードはPodの名前に対して作成されないため、`hostname`はPodのAレコードが作成されるために必須となります。`hostname`を持たないが`subdomain`を持つようなPodは、そのPodのIPアドレスを指し示すHeadless Service(`default-subdomain.my-namespace.svc.cluster.local`)に対するAレコードのみ作成します。
A(AAAA)レコードはPodの名前に対して作成されないため、`hostname`はPodのA(AAAA)レコードが作成されるために必須となります。`hostname`を持たないが`subdomain`を持つようなPodは、そのPodのIPアドレスを指し示すHeadless Service(`default-subdomain.my-namespace.svc.cluster.local`)に対するA(AAAA)レコードのみ作成します。
{{< /note >}}
### PodのDNSポリシー
@@ -148,7 +142,7 @@ spec:
dnsPolicy: ClusterFirstWithHostNet
```
### PodのDNS設定
### PodのDNS設定 {#pods-dns-config}
PodのDNS設定は、ユーザーがPodに対してそのDNS設定上でさらに制御するための手段を提供します。
content/ja/docs/concepts/services-networking/ingress.md
+13 -17
View File
@@ -15,19 +15,15 @@ weight: 40
まずわかりやすくするために、このガイドでは次の用語を定義します。
- ノード: Kubernetes内のワーカーマシンで、クラスターの一部です。
- クラスター: Kubernetesによって管理されているコンテナ化されたアプリケーションを実行させるノードのセットです。この例や、多くのKubernetesによるデプロイでは、クラスター内のノードはパブリックインターネットとして公開されていません。
- エッジルーター: クラスターでファイアウォールのポリシーを強制するルーターです。エッジルーターはクラウドプロバイダーやハードウェアの物理的な一部として管理されたゲートウェイとなります。
- クラスターネットワーク: 物理的または論理的なリンクのセットで、Kubernetesの[ネットワークモデル](/docs/concepts/cluster-administration/networking/)によって、クラスター内でのコミュニケーションを司るものです。
- Service: {{< glossary_tooltip text="ラベル" term_id="label" >}}セレクターを使ったPodのセットを特定するKubernetes {{< glossary_tooltip term_id="service" >}}です。特に言及がない限り、Serviceはクラスターネットワーク内でのみ疎通可能な仮想IPを持つと想定されます。
* ノード: Kubernetes内のワーカーマシンで、クラスターの一部です。
* クラスター: Kubernetesによって管理されているコンテナ化されたアプリケーションを実行させるノードのセットです。この例や、多くのKubernetesによるデプロイでは、クラスター内のノードはパブリックインターネットとして公開されていません。
* エッジルーター: クラスターでファイアウォールのポリシーを強制するルーターです。エッジルーターはクラウドプロバイダーやハードウェアの物理的な一部として管理されたゲートウェイとなります。
* クラスターネットワーク: 物理的または論理的なリンクのセットで、Kubernetesの[ネットワークモデル](/docs/concepts/cluster-administration/networking/)によって、クラスター内でのコミュニケーションを司るものです。
* Service: {{< glossary_tooltip text="ラベル" term_id="label" >}}セレクターを使ったPodのセットを特定するKubernetes {{< glossary_tooltip term_id="service" >}}です。特に言及がない限り、Serviceはクラスターネットワーク内でのみ疎通可能な仮想IPを持つと想定されます。
## Ingressとは何か
Ingressはクラスター外からクラスター内{{< link text="Service" url="/ja/docs/concepts/services-networking/service/" >}}へのHTTPとHTTPSのルートを公開します。トラフィックのルーティングはIngressリソース上で定義されるルールによって制御されます。
[Ingress](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io)はクラスター外からクラスター内{{< link text="Service" url="/ja/docs/concepts/services-networking/service/" >}}へのHTTPとHTTPSのルートを公開します。トラフィックのルーティングはIngressリソース上で定義されるルールによって制御されます。
```none
internet
@@ -74,8 +70,9 @@ spec:
servicePort: 80
```
他の全てのKubernetesリソースと同様に、Ingressは`apiVersion`、`kind`や`metadata`フィールドが必要です。設定ファイルの利用に関する一般的な情報は、[アプリケーションのデプロイ](/docs/tasks/run-application/run-stateless-application-deployment/)、[コンテナーの設定](/docs/tasks/configure-pod-container/configure-pod-configmap/)、[リソースの管理](/docs/concepts/cluster-administration/manage-deployment/)を参照してください。
Ingressでは、Ingressコントローラーに依存しているいくつかのオプションの設定をするためにアノテーションを使うことが多いです。その例としては、[rewrite-targetアノテーション](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md)などがあります。
他の全てのKubernetesリソースと同様に、Ingressは`apiVersion`、`kind`や`metadata`フィールドが必要です。Ingressオブジェクトの名前は、有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。
設定ファイルの利用に関する一般的な情報は、[アプリケーションのデプロイ](/ja/docs/tasks/run-application/run-stateless-application-deployment/)、[コンテナの設定](/docs/tasks/configure-pod-container/configure-pod-configmap/)、[リソースの管理](/docs/concepts/cluster-administration/manage-deployment/)を参照してください。
Ingressでは、Ingressコントローラーに依存しているいくつかのオプションの設定をするためにアノテーションを使うことが多いです。その例としては、[rewrite-targetアノテーション](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md)などがあります。
[Ingressコントローラー](/docs/concepts/services-networking/ingress-controllers)の種類が異なれば、サポートするアノテーションも異なります。サポートされているアノテーションについて学ぶために、ユーザーが使用するIngressコントローラーのドキュメントを確認してください。
Ingress [Spec](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)は、ロードバランサーやプロキシーサーバーを設定するために必要な全ての情報を持っています。最も重要なものとして、外部からくる全てのリクエストに対して一致したルールのリストを含みます。IngressリソースはHTTPトラフィックに対してのルールのみサポートしています。
@@ -112,10 +109,10 @@ kubectl get ingress test-ingress
```
NAME HOSTS ADDRESS PORTS AGE
test-ingress * 107.178.254.228 80 59s
test-ingress * 203.0.113.123 80 59s
```
`107.178.254.228`はIngressコントローラーによって割り当てられたIPで、このIngressを利用するためのものです。
`203.0.113.123`はIngressコントローラーによって割り当てられたIPで、このIngressを利用するためのものです。
{{< note >}}
IngressコントローラーとロードバランサーがIPアドレス割り当てるのに1、2分ほどかかります。この間、ADDRESSの情報は`<pending>`となっているのを確認できます。
@@ -288,7 +285,7 @@ spec:
```
{{< note >}}
Ingressコントローラーによって、サポートされるTLSの機能に違いがあります。利用する環境でTLSがどのように動作するかを理解するために、[nginx](https://git.k8s.io/ingress-nginx/README.md#https)や、[GCE](https://git.k8s.io/ingress-gce/README.md#frontend-https)、他のプラットフォーム固有のIngressコントローラーのドキュメントを確認してください。
Ingressコントローラーによって、サポートされるTLSの機能に違いがあります。利用する環境でTLSがどのように動作するかを理解するために、[nginx](https://kubernetes.github.io/ingress-nginx/user-guide/tls/)や、[GCE](https://git.k8s.io/ingress-gce/README.md#frontend-https)、他のプラットフォーム固有のIngressコントローラーのドキュメントを確認してください。
{{< /note >}}
### 負荷分散
@@ -396,9 +393,8 @@ Ingressリソースに直接関与しない複数の方法でServiceを公開で
* [Service.Type=NodePort](/ja/docs/concepts/services-networking/service/#nodeport)
## {{% heading "whatsnext" %}}
* [Ingress API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io)について学ぶ
* [Ingressコントローラー](/docs/concepts/services-networking/ingress-controllers/)について学ぶ
* [MinikubeとNGINXコントローラーでIngressのセットアップを行う](/docs/tasks/access-application-cluster/ingress-minikube)
content/ja/docs/concepts/services-networking/service.md
+126 -140
View File
@@ -14,7 +14,7 @@ weight: 10
{{< glossary_definition term_id="service" length="short" >}}
Kubernetesでは、なじみのないサービスディスカバリーのメカニズムを使用するためにユーザーがアプリケーションの修正をする必要はありません。
Kubernetesでは、なじみのないサービスディスカバリーのメカニズムを使用するためにユーザーがアプリケーションの修正をする必要はありません。
KubernetesはPodにそれぞれのIPアドレス割り振りや、Podのセットに対する単一のDNS名を提供したり、それらのPodのセットに対する負荷分散が可能です。
@@ -28,14 +28,14 @@ KubernetesはPodにそれぞれのIPアドレス割り振りや、Podのセッ
各Podはそれ自身のIPアドレスを持ちます。しかしDeploymentでは、ある時点において同時に稼働しているPodのセットは、その後のある時点において稼働しているPodのセットとは異なる場合があります。
この仕組みはある問題を引き起こします。もし、あるPodのセット(ここでは"バックエンド"と呼びます)がクラスター内で他のPodのセット(ここでは"フロントエンド"と呼びます)に対して機能を提供する場合、フロントエンドのPodがワークロードにおけるバックエンドを使用するために、バックエンドのPodのIPアドレスを探し出したり、記録し続けるためにはどうすればよいでしょうか?
この仕組みはある問題を引き起こします。もし、あるPodのセット(ここでは"バックエンド"と呼びます)がクラスター内で他のPodのセット(ここでは"フロントエンド"と呼びます)に対して機能を提供する場合、フロントエンドのPodがワークロードにおけるバックエンドを使用するために、バックエンドのPodのIPアドレスを探し出したり、記録し続けるためにはどうすればよいでしょうか?
ここで _Service_ について説明します。
## Serviceリソース {#service-resource}
Kubernetesにおいて、ServiceはPodの論理的なセットや、そのPodのセットにアクセスするためのポリシーを定義します(このパターンはよくマイクロサービスと呼ばることがあります)。
ServiceによってターゲットとされたPodのセットは、たいてい {{< glossary_tooltip text="セレクター" term_id="selector" >}} (セレクターなしのServiceを利用したい場合は[下記](#services-without-selectors)を参照してください)によって定義されます。
Kubernetesにおいて、ServiceはPodの論理的なセットや、そのPodのセットにアクセスするためのポリシーを定義します(このパターンはよくマイクロサービスと呼ばることがあります)。
ServiceによってターゲットとされたPodのセットは、たいてい {{< glossary_tooltip text="セレクター" term_id="selector" >}} (セレクターなしのServiceを利用したい場合は[下記](#services-without-selectors)を参照してください)によって定義されます。
例えば、3つのレプリカが稼働しているステートレスな画像処理用のバックエンドを考えます。これらのレプリカは代替可能です。&mdash; フロントエンドはバックエンドが何であろうと気にしません。バックエンドのセットを構成する実際のPodのセットが変更された際、フロントエンドクライアントはその変更を気にしたり、バックエンドのPodのセットの情報を記録しておく必要はありません。
@@ -45,11 +45,11 @@ Serviceによる抽象化は、クライアントからバックエンドのPod
アプリケーション内でサービスディスカバリーのためにKubernetes APIが使える場合、ユーザーはエンドポイントを{{< glossary_tooltip text="API Server" term_id="kube-apiserver" >}}に問い合わせることができ、またService内のPodのセットが変更された時はいつでも更新されたエンドポイントの情報を取得できます。
非ネイティブなアプリケーションのために、KubernetesはアプリケーションとバックエンドPodの間で、ネットワークポートやロードバランサーを配置する方法を提供します。
非ネイティブなアプリケーションのために、KubernetesはアプリケーションとバックエンドPodの間で、ネットワークポートやロードバランサーを配置する方法を提供します。
## Serviceの定義
KubernetesのServiceはPodと同様にRESTのオブジェクトです。他のRESTオブジェクトと同様に、ユーザーはServiceの新しいインスタンスを作成するためにAPIサーバーに対してServiceの定義を`POST`できます。
KubernetesのServiceはPodと同様にRESTのオブジェクトです。他のRESTオブジェクトと同様に、ユーザーはServiceの新しいインスタンスを作成するためにAPIサーバーに対してServiceの定義を`POST`できます。Serviceオブジェクトの名前は、有効な[DNSラベル名](/ja/docs/concepts/overview/working-with-objects/names#dns-label-names)である必要があります。
例えば、TCPで9376番ポートで待ち受けていて、`app=Myapp`というラベルをもつPodのセットがあるとします。
@@ -82,7 +82,7 @@ Pod内のポートの定義は名前を設定でき、Serviceの`targetPort`属
ServiceのデフォルトプロトコルはTCPです。また、他の[サポートされているプロトコル](#protocol-support)も利用可能です。
多くのServiceが、1つ以上のポートを公開する必要があるように、Kubernetesは1つのServiceオブジェクトに対して複数のポートの定義をサポートしています。
多くのServiceが、1つ以上のポートを公開する必要があるように、Kubernetesは1つのServiceオブジェクトに対して複数のポートの定義をサポートしています。
各ポート定義は同一の`protocol`または異なる値を設定できます。
### セレクターなしのService {#services-without-selectors}
@@ -94,7 +94,7 @@ Serviceは多くの場合、KubernetesのPodに対するアクセスを抽象化
* Serviceを、異なるNamespace内のServiceや他のクラスターのServiceに向ける場合
* ワークロードをKubernetesに移行するとき、アプリケーションに対する処理をしながら、バックエンドの一部をKubernetesで実行する場合
このような場合において、ユーザーはPodセレクター_なしで_ Serviceを定義できます。
このような場合において、ユーザーはPodセレクター_なしで_ Serviceを定義できます。
```yaml
apiVersion: v1
@@ -108,7 +108,7 @@ spec:
targetPort: 9376
```
このServiceはセレクターがないため、対応するEndpointsオブジェクトは自動的に作成されません。
このServiceはセレクターがないため、対応するEndpointsオブジェクトは自動的に作成されません。
ユーザーはEndpointsオブジェクトを手動で追加することにより、向き先のネットワークアドレスとポートを手動でマッピングできます。
```yaml
@@ -123,6 +123,8 @@ subsets:
- port: 9376
```
Endpointsオブジェクトの名前は、有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。
{{< note >}}
Endpointsのipは、loopback (127.0.0.0/8 for IPv4, ::1/128 for IPv6), や
link-local (169.254.0.0/16 and 224.0.0.0/24 for IPv4, fe80::/64 for IPv6)に設定することができません。
@@ -147,7 +149,7 @@ Kubernetesクラスターの各Nodeは`kube-proxy`を稼働させています。
### なぜ、DNSラウンドロビンを使わないのでしょうか。
ここで湧き上がる質問として、なぜKubernetesは内部のトラフィックをバックエンドへ転送するためにプロキシーに頼るのでしょうか。
ここで湧き上がる質問として、なぜKubernetesは内部のトラフィックをバックエンドへ転送するためにプロキシーに頼るのでしょうか。
他のアプローチはどうなのでしょうか。例えば、複数のAバリュー(もしくはIPv6用にAAAAバリューなど)をもつDNSレコードを設定し、ラウンドロビン方式で名前を解決することは可能でしょうか。
Serviceにおいてプロキシーを使う理由はいくつかあります。
@@ -158,11 +160,11 @@ Serviceにおいてプロキシーを使う理由はいくつかあります。
### user-spaceプロキシーモード {#proxy-mode-userspace}
このモードでは、kube-proxyはServiceやEndpointsオブジェクトの追加・削除をチェックするために、Kubernetes Masterを監視します。
各Serviceは、ローカルのNode上でポート(ランダムに選ばれたもの)を公開します。この"プロキシーポート"に対するどのようなリクエストも、そのServiceのバックエンドPodのどれか1つにプロキシーされます(Endpointsを介して通知されたPodに対して)。
kube-proxyは、どのバックエンドPodを使うかを決める際にServiceの`SessionAffinity`項目の設定を考慮に入れます。
このモードでは、kube-proxyはServiceやEndpointsオブジェクトの追加・削除をチェックするために、Kubernetes Masterを監視します。
各Serviceは、ローカルのNode上でポート(ランダムに選ばれたもの)を公開します。この"プロキシーポート"に対するどのようなリクエストも、そのServiceのバックエンドPodのどれか1つにプロキシーされます(Endpointsを介して通知されたPodに対して)。
kube-proxyは、どのバックエンドPodを使うかを決める際にServiceの`SessionAffinity`項目の設定を考慮に入れます。
最後に、user-spaceプロキシーはServiceの`clusterIP`(仮想IP)と`port`に対するトラフィックをキャプチャするiptablesルールをインストールします。
最後に、user-spaceプロキシーはServiceの`clusterIP`(仮想IP)と`port`に対するトラフィックをキャプチャするiptablesルールをインストールします。
そのルールは、トラフィックをバックエンドPodにプロキシーするためのプロキシーポートにリダイレクトします。
デフォルトでは、user-spaceモードにおけるkube-proxyはラウンドロビンアルゴリズムによってバックエンドPodを選択します。
@@ -171,19 +173,19 @@ kube-proxyは、どのバックエンドPodを使うかを決める際にService
### `iptables`プロキシーモード {#proxy-mode-iptables}
このモードでは、kube-proxyはServiceやEndpointsオブジェクトの追加・削除のチェックのためにKubernetesコントロールプレーンを監視します。
各Serviceでは、そのServiceの`clusterIP`と`port`に対するトラフィックをキャプチャするiptablesルールをインストールし、そのトラフィックをServiceのあるバックエンドのセットに対してリダイレクトします。
各Endpointsオブジェクトは、バックエンドのPodを選択するiptablesルールをインストールします。
このモードでは、kube-proxyはServiceやEndpointsオブジェクトの追加・削除のチェックのためにKubernetesコントロールプレーンを監視します。
各Serviceでは、そのServiceの`clusterIP`と`port`に対するトラフィックをキャプチャするiptablesルールをインストールし、そのトラフィックをServiceのあるバックエンドのセットに対してリダイレクトします。
各Endpointsオブジェクトは、バックエンドのPodを選択するiptablesルールをインストールします。
デフォルトでは、iptablesモードにおけるkube-proxyはバックエンドPodをランダムで選択します。
デフォルトでは、iptablesモードにおけるkube-proxyはバックエンドPodをランダムで選択します。
トラフィックのハンドリングのためにiptablesを使用すると、システムのオーバーヘッドが少なくなります。これは、トラフィックがLinuxのnetfilterによってuser-spaceとkernel-spaceを切り替える必要がないためです。
このアプローチは、オーバーヘッドが少ないことに加えて、より信頼できる方法でもあります。
トラフィックのハンドリングのためにiptablesを使用すると、システムのオーバーヘッドが少なくなります。これは、トラフィックがLinuxのnetfilterによってuser-spaceとkernel-spaceを切り替える必要がないためです。
このアプローチは、オーバーヘッドが少ないことに加えて、より信頼できる方法でもあります。
kube-proxyがiptablesモードで稼働し、最初に選択されたPodが応答しない場合、そのコネクションは失敗します。
kube-proxyがiptablesモードで稼働し、最初に選択されたPodが応答しない場合、そのコネクションは失敗します。
これはuser-spaceモードでの挙動と異なります: user-spaceモードにおいては、kube-proxyは最初のPodに対するコネクションが失敗したら、自動的に他のバックエンドPodに対して再接続を試みます。
iptablesモードのkube-proxyが正常なバックエンドPodのみをリダイレクト対象とするために、Podの[ReadinessProbe](/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)を使用してバックエンドPodが正常に動作しているか確認できます。これは、ユーザーがkube-proxyを介して、コネクションに失敗したPodに対してトラフィックをリダイレクトするのを除外することを意味します。
iptablesモードのkube-proxyが正常なバックエンドPodのみをリダイレクト対象とするために、Podの[ReadinessProbe](/ja/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)を使用してバックエンドPodが正常に動作しているか確認できます。これは、ユーザーがkube-proxyを介して、コネクションに失敗したPodに対してトラフィックをリダイレクトするのを除外することを意味します。
![iptablesプロキシーのService概要ダイアグラム](/images/docs/services-iptables-overview.svg)
@@ -191,15 +193,15 @@ iptablesモードのkube-proxyが正常なバックエンドPodのみをリダ
{{< feature-state for_k8s_version="v1.11" state="stable" >}}
`ipvs`モードにおいて、kube-proxyはServiceとEndpointsオブジェクトを監視し、IPVSルールを作成するために`netlink`インターフェースを呼び出し、定期的にKubernetesのServiceとEndpointsとIPVSルールを同期させます。
このコントロールループはIPVSのステータスが理想的な状態になることを保証します。
`ipvs`モードにおいて、kube-proxyはServiceとEndpointsオブジェクトを監視し、IPVSルールを作成するために`netlink`インターフェースを呼び出し、定期的にKubernetesのServiceとEndpointsとIPVSルールを同期させます。
このコントロールループはIPVSのステータスが理想的な状態になることを保証します。
Serviceにアクセスするとき、IPVSはトラフィックをバックエンドのPodに向けます。
IPVSプロキシーモードはiptablesモードと同様に、netfilterのフック関数に基づいています。ただし、基礎となるデータ構造としてハッシュテーブルを使っているのと、kernel-spaceで動作します。
これは、IPVSモードにおけるkube-proxyはiptablesモードに比べてより低いレイテンシーでトラフィックをリダイレクトし、プロキシーのルールを同期する際にはよりパフォーマンスがよいことを意味します。　　
他のプロキシーモードと比較して、IPVSモードはより高いネットワークトラフィックのスループットをサポートしています。
IPVSプロキシーモードはiptablesモードと同様に、netfilterのフック関数に基づいています。ただし、基礎となるデータ構造としてハッシュテーブルを使っているのと、kernel-spaceで動作します。
これは、IPVSモードにおけるkube-proxyはiptablesモードに比べてより低いレイテンシーでトラフィックをリダイレクトし、プロキシーのルールを同期する際にはよりパフォーマンスがよいことを意味します。
他のプロキシーモードと比較して、IPVSモードはより高いネットワークトラフィックのスループットをサポートしています。
IPVSはバックエンドPodに対するトラフィックのバランシングのために多くのオプションを下記のとおりに提供します。
IPVSはバックエンドPodに対するトラフィックのバランシングのために多くのオプションを下記のとおりに提供します。
- `rr`: ラウンドロビン
- `lc`: 最低コネクション数(オープンされているコネクション数がもっとも小さいもの)
@@ -211,7 +213,7 @@ IPVSはバックエンドPodに対するトラフィックのバランシング
{{< note >}}
IPVSモードでkube-proxyを稼働させるためには、kube-proxyを稼働させる前にNode上でIPVSを有効にしなければなりません。
kube-proxyはIPVSモードで起動する場合、IPVSカーネルモジュールが利用可能かどうかを確認します。
kube-proxyはIPVSモードで起動する場合、IPVSカーネルモジュールが利用可能かどうかを確認します。
もしIPVSカーネルモジュールが見つからなかった場合、kube-proxyはiptablesモードで稼働するようにフォールバックされます。
{{< /note >}}
@@ -219,12 +221,12 @@ kube-proxyはIPVSモードで起動する場合、IPVSカーネルモジュー
このダイアグラムのプロキシーモデルにおいて、ServiceのIP:Portに対するトラフィックは、クライアントがKubernetesのServiceやPodについて何も知ることなく適切にバックエンドにプロキシーされています。
特定のクライアントからのコネクションが、毎回同一のPodにリダイレクトされるようにするためには、`service.spec.sessionAffinity`を"ClientIP"にセットすることにより、クライアントのIPアドレスに基づいたSessionAffinityを選択することができます(デフォルトは"None")。
特定のクライアントからのコネクションが、毎回同一のPodにリダイレクトされるようにするためには、`service.spec.sessionAffinity`に"ClientIP"を設定することにより、クライアントのIPアドレスに基づいたSessionAffinityを選択することができます(デフォルトは"None")。
また、`service.spec.sessionAffinityConfig.clientIP.timeoutSeconds`を適切に設定することにより、セッションのタイムアウト時間を設定できます(デフォルトではこの値は18,000で、3時間となります)。
## 複数のポートを公開するService
## 複数のポートを公開するService
いくつかのServiceにおいて、ユーザーは1つ以上のポートを公開する必要があります。Kubernetesは、Serviceオブジェクト上で複数のポートを定義するように設定できます。
いくつかのServiceにおいて、ユーザーは1つ以上のポートを公開する必要があります。Kubernetesは、Serviceオブジェクト上で複数のポートを定義するように設定できます。
Serviceで複数のポートを使用するとき、どのポートかを明確にするために、複数のポート全てに対して名前をつける必要があります。
例えば:
@@ -255,14 +257,14 @@ KubernetesのPod名と同様に、ポート名は小文字の英数字と`-`の
## ユーザー所有のIPアドレスを選択する
`Service`を作成するリクエストの一部として、ユーザー所有のclusterIPアドレスを指定することができます。
これを行うためには`.spec.clusterIP`フィールドにセットします。
`Service`を作成するリクエストの一部として、ユーザー所有のclusterIPアドレスを指定することができます。
これを行うためには`.spec.clusterIP`フィールドにセットします。
使用例として、もしすでに再利用したいDNSエントリーが存在していた場合や、特定のIPアドレスを設定されたレガシーなシステムや、IPの再設定が難しい場合です。
ユーザーが指定したIPアドレスは、そのAPIサーバーのために設定されている`service-cluster-ip-range`というCIDRレンジ内の有効なIPv4またはIPv6アドレスである必要があります。
ユーザーが指定したIPアドレスは、そのAPIサーバーのために設定されている`service-cluster-ip-range`というCIDRレンジ内の有効なIPv4またはIPv6アドレスである必要があります。
もし無効なclusterIPアドレスの値を設定してServiceを作成した場合、問題があることを示すためにAPIサーバーはHTTPステータスコード422を返します。
## サービスディスカバリー
## サービスディスカバリー
Kubernetesは、Serviceオブジェクトを見つけ出すために2つの主要なモードをサポートしています。 - それは環境変数とDNSです。
@@ -285,8 +287,8 @@ REDIS_MASTER_PORT_6379_TCP_ADDR=10.0.0.11
```
{{< note >}}
Serviceにアクセスする必要のあるPodがあり、クライアントであるそのPodに対して環境変数を使ってポートとclusterIPを公開する場合、クライアントのPodが存在する*前に* Serviceを作成しなくてはなりません。
そうでない場合、クライアントのPodはそれらの環境変数を作成しません。
Serviceにアクセスする必要のあるPodがあり、クライアントであるそのPodに対して環境変数を使ってポートとclusterIPを公開する場合、クライアントのPodが存在する*前に* Serviceを作成しなくてはなりません。
そうでない場合、クライアントのPodはそれらの環境変数を作成しません。
ServiceのclusterIPを発見するためにDNSのみを使う場合、このような問題を心配する必要はありません。
{{< /note >}}
@@ -295,28 +297,28 @@ ServiceのclusterIPを発見するためにDNSのみを使う場合、このよ
ユーザーは[アドオン](/docs/concepts/cluster-administration/addons/)を使ってKubernetesクラスターにDNS Serviceをセットアップできます(常にセットアップすべきです)。
CoreDNSなどのクラスター対応のDNSサーバーは新しいServiceや、各Service用のDNSレコードのセットのためにKubernetes APIを常に監視します。
CoreDNSなどのクラスター対応のDNSサーバーは新しいServiceや、各Service用のDNSレコードのセットのためにKubernetes APIを常に監視します。
もしクラスターを通してDNSが有効になっている場合、全てのPodはDNS名によって自動的にServiceに対する名前解決をするようにできるはずです。
例えば、Kubernetesの`"my-ns"`というNamespace内で`"my-service"`というServiceがある場合、KubernetesコントロールプレーンとDNS Serviceが協調して動作し、`"my-service.my-ns"`というDNSレコードを作成します。
例えば、Kubernetesの`"my-ns"`というNamespace内で`"my-service"`というServiceがある場合、KubernetesコントロールプレーンとDNS Serviceが協調して動作し、`"my-service.my-ns"`というDNSレコードを作成します。
`"my-ns"`というNamespace内のPodは`my-service`という名前で簡単に名前解決できるはずです(`"my-service.my-ns"`でも動作します)。
他のNamespace内でのPodは`my-service.my-ns`といった形で指定しなくてはなりません。これらのDNS名は、そのServiceのclusterIPに名前解決されます。
Kubernetesは名前付きのポートに対するDNS SRV(Service)レコードもサポートしています。もし`"my-service.my-ns"`というServiceが`"http"`という名前のTCPポートを持っていた場合、IPアドレスと同様に、`"http"`のポート番号を探すために`_http._tcp.my-service.my-ns`というDNS SRVクエリを実行できます。
KubernetesのDNSサーバーは`ExternalName` Serviceにアクセスする唯一の方法です。
[DNS Pods と Service](/docs/concepts/services-networking/dns-pod-service/)にて`ExternalName`による名前解決に関するさらなる情報を確認できます。
KubernetesのDNSサーバーは`ExternalName` Serviceにアクセスする唯一の方法です。
[DNS Pods と Service](/ja/docs/concepts/services-networking/dns-pod-service/)にて`ExternalName`による名前解決に関するさらなる情報を確認できます。
## Headless Service {#headless-service}
場合によっては、負荷分散と単一のService IPは不要です。このケースにおいて、clusterIP(`.spec.clusterIP`)の値を`"None"`に設定することにより、"Headless"とよばれるServiceを作成できます。
ユーザーは、Kubernetesの実装と紐づくことなく、他のサービスディスカバリーのメカニズムと連携するためにHeadless Serviceを使用できます。
ユーザーは、Kubernetesの実装と紐づくことなく、他のサービスディスカバリーのメカニズムと連携するためにHeadless Serviceを使用できます。
例えば、ユーザーはこのAPI上でカスタム{{< glossary_tooltip term_id="operator-pattern" text="オペレーター" >}}を実装することができます。
この`Service`においては、clusterIPは割り当てられず、kube-proxyはこのServiceをハンドリングしないのと、プラットフォームによって行われるはずの
ロードバランシングやプロキシーとしての処理は行われません。DNSがどのように自動で設定されるかは、定義されたServiceが定義されたラベルセレクターを持っているかどうかに依存します。
ロードバランシングやプロキシーとしての処理は行われません。DNSがどのように自動で設定されるかは、定義されたServiceが定義されたラベルセレクターを持っているかどうかに依存します。
### ラベルセレクターの利用
@@ -324,7 +326,7 @@ KubernetesのDNSサーバーは`ExternalName` Serviceにアクセスする唯一
### ラベルセレクターなしの場合
ラベルセレクターを定義しないHeadless Serviceにおいては、Endpointsコントローラーは`Endpoints`レコードを作成しません。
ラベルセレクターを定義しないHeadless Serviceにおいては、Endpointsコントローラーは`Endpoints`レコードを作成しません。
しかしDNSのシステムは下記の2つ両方を探索し、設定します。
* [`ExternalName`](#externalname)タイプのServiceに対するCNAMEレコード
@@ -334,47 +336,47 @@ KubernetesのDNSサーバーは`ExternalName` Serviceにアクセスする唯一
ユーザーのアプリケーションのいくつかの部分において(例えば、frontendsなど)、ユーザーのクラスターの外部にあるIPアドレス上でServiceを公開したい場合があります。
Kubernetesの`ServiceTypes`によって、ユーザーがどのような種類のServiceを使いたいかを指定することが可能です。
Kubernetesの`ServiceTypes`によって、ユーザーがどのような種類のServiceを使いたいかを指定することが可能です。
デフォルトでは`ClusterIP`となります。
`Type`項目の値と、そのふるまいは以下のようになります。
* `ClusterIP`: クラスター内部のIPでServiceを公開する。このタイプではServiceはクラスター内部からのみ疎通性があります。このタイプはデフォルトの`ServiceType`です。
* [`NodePort`](#nodeport): 各NodeのIPにて、静的なポート(`NodePort`)上でServiceを公開します。その`NodePort` のServiceが転送する先の`ClusterIP` Serviceが自動的に作成されます。`<NodeIP>:<NodePort>`にアクセスすることによって`NodePort` Serviceにアクセスできるようになります。
* [`NodePort`](#nodeport): 各NodeのIPにて、静的なポート(`NodePort`)上でServiceを公開します。その`NodePort` のServiceが転送する先の`ClusterIP` Serviceが自動的に作成されます。`<NodeIP>:<NodePort>`にアクセスすることによって`NodePort` Serviceにアクセスできるようになります。
* [`LoadBalancer`](#loadbalancer): クラウドプロバイダーのロードバランサーを使用して、Serviceを外部に公開します。クラスター外部にあるロードバランサーが転送する先の`NodePort`と`ClusterIP` Serviceは自動的に作成されます。
* [`ExternalName`](#externalname): `CNAME`レコードを返すことにより、`externalName`フィールドに指定したコンテンツ(例: `foo.bar.example.com`)とServiceを紐づけます。しかし、いかなる種類のプロキシーも設定されません。
{{< note >}}
`ExternalName`タイプのServiceを利用するためには、CoreDNSのバージョン1.7以上が必要となります。
`ExternalName`タイプのServiceを利用するためには、kube-dnsのバージョン1.7かCoreDNSのバージョン0.0.8以上が必要となります。
{{< /note >}}
また、Serviceを公開するために[Ingress](/docs/concepts/services-networking/ingress/)も利用可能です。IngressはServiceのタイプではありませんが、クラスターに対するエントリーポイントとして動作します。
また、Serviceを公開するために[Ingress](/docs/concepts/services-networking/ingress/)も利用可能です。IngressはServiceのタイプではありませんが、クラスターに対するエントリーポイントとして動作します。
Ingressは同一のIPアドレスにおいて、複数のServiceを公開するように、ユーザーの設定した転送ルールを1つのリソースにまとめることができます。
### NodePort タイプ {#nodeport}
もし`type`フィールドの値を`NodePort`に設定すると、Kubernetesコントロールプレーンは`--service-node-port-range`フラグによって指定されたレンジのポート(デフォルト: 30000-32767)を割り当てます。
各Nodeはそのポート(各Nodeで同じポート番号)への通信をServiceに転送します。
作成したServiceは、`.spec.ports[*].nodePort`フィールド内に割り当てられたポートを記述します。
もし`type`フィールドの値を`NodePort`に設定すると、Kubernetesコントロールプレーンは`--service-node-port-range`フラグによって指定されたレンジのポート(デフォルト: 30000-32767)を割り当てます。
各Nodeはそのポート(各Nodeで同じポート番号)への通信をServiceに転送します。
作成したServiceは、`.spec.ports[*].nodePort`フィールド内に割り当てられたポートを記述します。
もしポートへの通信を転送する特定のIPを指定したい場合、特定のIPブロックをkube-proxyの`--nodeport-address`フラグで指定できます。これはKubernetesv1.10からサポートされています。
このフラグは、コンマ区切りのIPブロックのリスト(例: 10.0.0./8, 192.0.2.0/25)を使用し、kube-proxyがこのNodeに対してローカルとみなすべきIPアドレスの範囲を指定します。
もしポートへの通信を転送する特定のIPを指定したい場合、特定のIPブロックをkube-proxyの`--nodeport-address`フラグで指定できます。これはKubernetes v1.10からサポートされています。
このフラグは、コンマ区切りのIPブロックのリスト(例: 10.0.0./8, 192.0.2.0/25)を使用し、kube-proxyがこのNodeに対してローカルとみなすべきIPアドレスの範囲を指定します。
例えば、`--nodeport-addresses=127.0.0.0/8`というフラグによってkube-proxyを起動した時、kube-proxyはNodePort Serviceのためにループバックインターフェースのみ選択します。`--nodeport-addresses`のデフォルト値は空のリストになります。これはkube-proxyがNodePort Serviceに対して全てのネットワークインターフェースを利用可能とするべきということを意味します(これは以前のKubernetesのバージョンとの互換性があります)。
例えば、`--nodeport-addresses=127.0.0.0/8`というフラグによってkube-proxyを起動した時、kube-proxyはNodePort Serviceのためにループバックインターフェースのみ選択します。`--nodeport-addresses`のデフォルト値は空のリストになります。これはkube-proxyがNodePort Serviceに対して全てのネットワークインターフェースを利用可能とするべきということを意味します(これは以前のKubernetesのバージョンとの互換性があります)。
もしポート番号を指定したい場合、`nodePort`フィールドに値を指定できます。コントロールプレーンは指定したポートを割り当てるか、APIトランザクションが失敗したことを知らせるかのどちらかになります。
これは、ユーザーが自分自身で、ポート番号の衝突に関して気をつける必要があることを意味します。
もしポート番号を指定したい場合、`nodePort`フィールドに値を指定できます。コントロールプレーンは指定したポートを割り当てるか、APIトランザクションが失敗したことを知らせるかのどちらかになります。
これは、ユーザーが自分自身で、ポート番号の衝突に関して気をつける必要があることを意味します。
また、ユーザーは有効なポート番号を指定する必要があり、NodePortの使用において、設定された範囲のポートを指定する必要があります。
NodePortの使用は、Kubernetesによって完全にサポートされていないようなユーザー独自の負荷分散を設定をするための有効な方法や、1つ以上のNodeのIPを直接公開するための方法となりえます。
注意点として、このServiceは`<NodeIP>:spec.ports[*].nodePort`と、`.spec.clusterIP:spec.ports[*].port`として疎通可能です。
注意点として、このServiceは`<NodeIP>:spec.ports[*].nodePort`と、`.spec.clusterIP:spec.ports[*].port`として疎通可能です。
(もしkube-proxyにおいて`--nodeport-addressses`が設定された場合、<NodeIP>はフィルターされたNodeIPとなります。)
### LoadBalancer タイプ {#loadbalancer}
外部のロードバランサーをサポートするクラウドプロバイダー上で、`type`フィールドに`LoadBalancer`を設定すると、Service用にロードバランサーがプロビジョニングされます。
実際のロードバランサーの作成は非同期で行われ、プロビジョンされたバランサーの情報は、Serviceの`.status.loadBalancer`フィールドに記述されます。
外部のロードバランサーをサポートするクラウドプロバイダー上で、`type`フィールドに`LoadBalancer`を設定すると、Service用にロードバランサーがプロビジョニングされます。
実際のロードバランサーの作成は非同期で行われ、プロビジョンされたバランサーの情報は、Serviceの`.status.loadBalancer`フィールドに記述されます。
例えば:
```yaml
@@ -397,9 +399,11 @@ status:
- ip: 192.0.2.127
```
外部のロードバランサーからのトラフィックはバックエンドのPodに直接転送されます。クラウドプロバイダーはどのようにそのリクエストをバランシングするかを決めます。
外部のロードバランサーからのトラフィックはバックエンドのPodに直接転送されます。クラウドプロバイダーはどのようにそのリクエストをバランシングするかを決めます。
いくつかのクラウドプロバイダーにおいて、`loadBalancerIP`の設定をすることができます。このようなケースでは、そのロードバランサーはユーザーが指定した`loadBalancerIP`に対してロードバランサーを作成します。
LoadBalancerタイプのサービスで複数のポートが定義されている場合、すべてのポートが同じプロトコルである必要があり、さらにそのプロトコルは`TCP`、`UDP`、`SCTP`のいずれかである必要があります。
いくつかのクラウドプロバイダーにおいて、`loadBalancerIP`の設定をすることができます。このようなケースでは、そのロードバランサーはユーザーが指定した`loadBalancerIP`に対してロードバランサーを作成します。
もし`loadBalancerIP`フィールドの値が指定されていない場合、そのロードバランサーはエフェメラルなIPアドレスに対して作成されます。もしユーザーが`loadBalancerIP`を指定したが、使っているクラウドプロバイダーがその機能をサポートしていない場合、その`loadBalancerIP`フィールドに設定された値は無視されます。
{{< note >}}
@@ -408,25 +412,25 @@ status:
{{< note >}}
**Azure** において、もしユーザーが指定する`loadBalancerIP`を使用したい場合、最初に静的なパブリックIPアドレスのリソースを作成する必要があります。
このパブリックIPアドレスのリソースは、クラスター内で自動的に作成された他のリソースと同じグループに作られるべきです。
例: `MC_myResourceGroup_myAKSCluster_eastus`
**Azure** において、もしユーザーが指定する`loadBalancerIP`を使用したい場合、最初に静的なパブリックIPアドレスのリソースを作成する必要があります。
このパブリックIPアドレスのリソースは、クラスター内で自動的に作成された他のリソースと同じグループに作られるべきです。
例: `MC_myResourceGroup_myAKSCluster_eastus`
割り当てられたIPアドレスをloadBalancerIPとして指定してください。クラウドプロバイダーの設定ファイルにおいてsecurityGroupNameを更新したことを確認してください。
割り当てられたIPアドレスをloadBalancerIPとして指定してください。クラウドプロバイダーの設定ファイルにおいてsecurityGroupNameを更新したことを確認してください。
`CreatingLoadBalancerFailed`というパーミッションの問題に対するトラブルシューティングの情報は、[Azure Kubernetes Service(AKS)のロードバランサーで静的IPアドレスを使用する](https://docs.microsoft.com/en-us/azure/aks/static-ip) や、[高度なネットワークを使用したAKSクラスターでのCreatingLoadBalancerFailed](https://github.com/Azure/AKS/issues/357)を参照してください。
{{< /note >}}
#### 内部のロードバランサー
複雑な環境において、同一の(仮想)ネットワークアドレスブロック内のServiceからのトラフィックを転送する必要がでてきます。
複雑な環境において、同一の(仮想)ネットワークアドレスブロック内のServiceからのトラフィックを転送する必要がでてきます。
Split-HorizonなDNS環境において、ユーザーは2つのServiceを外部と内部の両方からのトラフィックをエンドポイントに転送させる必要がでてきます。
ユーザーは、Serviceに対して下記のアノテーションを1つ追加することでこれを実現できます。
ユーザーは、Serviceに対して下記のアノテーションを1つ追加することでこれを実現できます。
追加するアノテーションは、ユーザーが使っているクラウドプロバイダーに依存しています。
{{< tabs name="service_tabs" >}}
{{% tab name="Default" %}}
タブを選択してください。
タブを選択してください。
{{% /tab %}}
{{% tab name="GCP" %}}
```yaml
@@ -512,9 +516,9 @@ metadata:
2つ目のアノテーションはPodが利用するプロトコルを指定するものです。HTTPSとSSLの場合、ELBはそのPodが証明書を使って暗号化されたコネクションを介して自分自身のPodを認証すると推測します。
HTTPとHTTPSでは、レイヤー7でのプロキシーを選択します。ELBはユーザーとのコネクションを切断し、リクエストを転送するときにリクエストヘッダーをパースして、`X-Forwardef-For`ヘッダーにユーザーのIPを追加します(Podは接続相手のELBのIPアドレスのみ確認可能です)。
HTTPとHTTPSでは、レイヤー7でのプロキシーを選択します。ELBはユーザーとのコネクションを切断し、リクエストを転送するときにリクエストヘッダーをパースして、`X-Forwarded-For`ヘッダーにユーザーのIPを追加します(Podは接続相手のELBのIPアドレスのみ確認可能です)。
TCPとSSLでは、レイヤー4でのプロキシーを選択します。ELBはヘッダーの値を変更せずにトラフィックを転送します。
TCPとSSLでは、レイヤー4でのプロキシーを選択します。ELBはヘッダーの値を変更せずにトラフィックを転送します。
いくつかのポートがセキュアに保護され、他のポートではセキュアでないような混合した環境において、下記のようにアノテーションを使うことができます。
@@ -535,8 +539,8 @@ Kubernetes v1.9以降のバージョンからは、Serviceのリスナー用にH
aws elb describe-load-balancer-policies --query 'PolicyDescriptions[].PolicyName'
```
ユーザーは"`service.beta.kubernetes.io/aws-load-balancer-ssl-negotiation-policy`"というアノテーションを使用することにより、複数のポリシーの中からどれか1つを指定できます。
例えば:
ユーザーは"`service.beta.kubernetes.io/aws-load-balancer-ssl-negotiation-policy`"というアノテーションを使用することにより、複数のポリシーの中からどれか1つを指定できます。
例えば:
```yaml
metadata:
@@ -547,7 +551,7 @@ aws elb describe-load-balancer-policies --query 'PolicyDescriptions[].PolicyName
#### AWS上でのPROXYプロトコルのサポート
AWS上で稼働するクラスターで[PROXY protocol](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)のサポートを有効にするために、下記のServiceのアノテーションを使用できます。
AWS上で稼働するクラスターで[PROXY protocol](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)のサポートを有効にするために、下記のServiceのアノテーションを使用できます。
```yaml
metadata:
@@ -564,7 +568,7 @@ AWS上でのELB Service用のアクセスログを管理するためにはいく
`service.beta.kubernetes.io/aws-load-balancer-access-log-enabled`というアノテーションはアクセスログを有効にするかを設定できます。
`service.beta.kubernetes.io/aws-load-balancer-access-log-emit-interval`というアノテーションはアクセスログをパブリッシュするためのインターバル(分)を設定できます。
`service.beta.kubernetes.io/aws-load-balancer-access-log-emit-interval`というアノテーションはアクセスログをパブリッシュするためのインターバル(分)を設定できます。
ユーザーはそのインターバルで5分もしくは60分で設定できます。
`service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-name`というアノテーションはロードバランサーのアクセスログが保存されるAmazon S3のバケット名を設定できます。
@@ -578,16 +582,16 @@ AWS上でのELB Service用のアクセスログを管理するためにはいく
service.beta.kubernetes.io/aws-load-balancer-access-log-enabled: "true"
# ロードバランサーのアクセスログが有効かどうか。
service.beta.kubernetes.io/aws-load-balancer-access-log-emit-interval: "60"
# アクセスログをパブリッシュするためのインターバル(分)。ユーザーはそのインターバルで5分もしくは60分で設定できます。
# アクセスログをパブリッシュするためのインターバル(分)。ユーザーはそのインターバルで5分もしくは60分で設定できます。
service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-name: "my-bucket"
# ロードバランサーのアクセスログが保存されるAmazon S3のバケット名。
# ロードバランサーのアクセスログが保存されるAmazon S3のバケット名。
service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix: "my-bucket-prefix/prod"
# ユーザーが作成したAmazon S3バケットの論理的な階層。例えば: `my-bucket-prefix/prod`
```
#### AWSでの接続の中断
古いタイプのELBでの接続の中断は、`service.beta.kubernetes.io/aws-load-balancer-connection-draining-enabled`というアノテーションを`"true"`に設定することで管理できます。
古いタイプのELBでの接続の中断は、`service.beta.kubernetes.io/aws-load-balancer-connection-draining-enabled`というアノテーションを`"true"`に設定することで管理できます。
`service.beta.kubernetes.io/aws-load-balancer-connection-draining-timeout`というアノテーションで、インスタンスを登録解除するまえに既存の接続をオープンにし続けるための最大時間(秒)を指定できます。
```yaml
@@ -600,7 +604,7 @@ AWS上でのELB Service用のアクセスログを管理するためにはいく
#### 他のELBアノテーション
古いタイプのELBを管理するためのアノテーションは他にもあり、下記で紹介します。
古いタイプのELBを管理するためのアノテーションは他にもあり、下記で紹介します。
```yaml
metadata:
@@ -650,18 +654,18 @@ AWSでNetwork Load Balancerを使用するには、値を`nlb`に設定してア
```
{{< note >}}
NLBは特定のインスタンスクラスでのみ稼働します。サポートされているインスタンスタイプを確認するためには、ELBに関する[AWS documentation](http://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-register-targets.html#register-deregister-targets)を参照してください。
NLBは特定のインスタンスクラスでのみ稼働します。サポートされているインスタンスタイプを確認するためには、ELBに関する[AWS documentation](http://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-register-targets.html#register-deregister-targets)を参照してください。
{{< /note >}}
古いタイプのElastic Load Balancersとは異なり、Network Load Balancers (NLBs)はクライアントのIPアドレスをNodeに転送します。
古いタイプのElastic Load Balancersとは異なり、Network Load Balancers (NLBs)はクライアントのIPアドレスをNodeに転送します。
もしServiceの`.spec.externalTrafficPolicy`の値が`Cluster`に設定されていた場合、クライアントのIPアドレスは末端のPodに伝播しません。
`.spec.externalTrafficPolicy`を`Local`に設定することにより、クライアントIPアドレスは末端のPodに伝播します。しかし、これにより、トラフィックの分配が不均等になります。
`.spec.externalTrafficPolicy`を`Local`に設定することにより、クライアントIPアドレスは末端のPodに伝播します。しかし、これにより、トラフィックの分配が不均等になります。
特定のLoadBalancer Serviceに紐づいたPodがないNodeでは、自動的に割り当てられた`.spec.healthCheckNodePort`に対するNLBのターゲットグループのヘルスチェックが失敗し、トラフィックを全く受信しません。
均等なトラフィックの分配を実現するために、DaemonSetの使用や、同一のNodeに配備しないように[Podのanti-affinity](/ja/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity)を設定します。
また、[内部のロードバランサー](/ja/docs/concepts/services-networking/service/#internal-load-balancer)のアノテーションとNLB Serviceを使用できます。
また、[内部のロードバランサー](/ja/docs/concepts/services-networking/service/#internal-load-balancer)のアノテーションとNLB Serviceを使用できます。
NLBの背後にあるインスタンスに対してクライアントのトラフィックを転送するために、Nodeのセキュリティーグループは下記のようなIPルールに従って変更されます。
@@ -671,7 +675,7 @@ NLBの背後にあるインスタンスに対してクライアントのトラ
| クライアントのトラフィック | TCP | NodePort(s) | `.spec.loadBalancerSourceRanges` (デフォルト: `0.0.0.0/0`) | kubernetes.io/rule/nlb/client=\<loadBalancerName\> |
| MTCによるサービスディスカバリー | ICMP | 3,4 | `.spec.loadBalancerSourceRanges` (デフォルト: `0.0.0.0/0`) | kubernetes.io/rule/nlb/mtu=\<loadBalancerName\> |
どのクライアントIPがNLBにアクセス可能かを制限するためには、`loadBalancerSourceRanges`を指定してください。
どのクライアントIPがNLBにアクセス可能かを制限するためには、`loadBalancerSourceRanges`を指定してください。
```yaml
spec:
@@ -680,7 +684,7 @@ spec:
```
{{< note >}}
もし`.spec.loadBalancerSourceRanges`が設定されていない場合、KubernetesはNodeのセキュリティーグループに対して`0.0.0.0/0`からのトラフィックを許可します。
もし`.spec.loadBalancerSourceRanges`が設定されていない場合、KubernetesはNodeのセキュリティーグループに対して`0.0.0.0/0`からのトラフィックを許可します。
もしNodeがパブリックなIPアドレスを持っていた場合、NLBでないトラフィックも修正されたセキュリティーグループ内の全てのインスタンスにアクセス可能になってしまうので注意が必要です。
{{< /note >}}
@@ -719,7 +723,7 @@ spec:
### ExternalName タイプ {#externalname}
ExternalNameタイプのServiceは、ServiceをDNS名とマッピングし、`my-service`や`cassandra`というような従来のラベルセレクターとはマッピングしません。
ExternalNameタイプのServiceは、ServiceをDNS名とマッピングし、`my-service`や`cassandra`というような従来のラベルセレクターとはマッピングしません。
ユーザーはこれらのServiceにおいて`spec.externalName`フィールドの値を指定します。
このServiceの定義では、例えば`prod`というNamespace内の`my-service`というServiceを`my.database.example.com`にマッピングします。
@@ -735,19 +739,19 @@ spec:
externalName: my.database.example.com
```
{{< note >}}
ExternalNameはIpv4のアドレスの文字列のみ受け付けますが、IPアドレスではなく、数字で構成されるDNS名として受け入れます。
IPv4アドレスに似ているExternalNamesはCoreDNSもしくはIngress-Nginxによって名前解決されず、これはExternalNameは正規のDNS名を指定することを目的としているためです。
ExternalNameはIpv4のアドレスの文字列のみ受け付けますが、IPアドレスではなく、数字で構成されるDNS名として受け入れます。
IPv4アドレスに似ているExternalNamesはCoreDNSもしくはIngress-Nginxによって名前解決されず、これはExternalNameは正規のDNS名を指定することを目的としているためです。
IPアドレスをハードコードする場合、[Headless Service](#headless-service)の使用を検討してください。
{{< /note >}}
`my-service.prod.svc.cluster.local`というホストをルックアップするとき、クラスターのDNS Serviceは`CNAME`レコードと`my.database.example.com`という値を返します。
`my-service`へのアクセスは、他のServiceと同じ方法ですが、再接続する際はプロキシーや転送を介して行うよりも、DNSレベルで行われることが決定的に異なる点となります。
後にユーザーが使用しているデータベースをクラスター内に移行することになった後は、Podを起動させ、適切なラベルセレクターやEndpointsを追加し、Serviceの`type`を変更します。
`my-service.prod.svc.cluster.local`というホストをルックアップするとき、クラスターのDNS Serviceは`my.database.example.com`という値をもつ`CNAME`レコードを返します。
`my-service`へのアクセスは、他のServiceと同じ方法ですが、再接続する際はプロキシーや転送を介して行うよりも、DNSレベルで行われることが決定的に異なる点となります。
後にユーザーが使用しているデータベースをクラスター内に移行することになった場合は、Podを起動させ、適切なラベルセレクターやEndpointsを追加し、Serviceの`type`を変更します。
{{< warning >}}
HTTPやHTTPSなどの一般的なプロトコルでExternalNameを使用する際に問題が発生する場合があります。ExternalNameを使用する場合、クラスター内のクライアントが使用するホスト名は、ExternalNameが参照する名前とは異なります。
ホスト名を使用するプロトコルの場合、この違いによりエラーまたは予期しない応答が発生する場合があります。HTTPリクエストには、オリジンサーバーが認識しない`Host:`ヘッダーがあります。TLSサーバーは、クライアントが接続したホスト名に一致する証明書を提供できません。
ホスト名を使用するプロトコルの場合、この違いによりエラーまたは予期しない応答が発生する場合があります。HTTPリクエストがオリジンサーバーが認識しない`Host:`ヘッダーを持っていたなら、TLSサーバーはクライアントが接続したホスト名に一致する証明書を提供できません。
{{< /warning >}}
{{< note >}}
@@ -757,11 +761,11 @@ HTTPやHTTPSなどの一般的なプロトコルでExternalNameを使用する
### External IPs
もし1つ以上のクラスターNodeに転送するexternalIPが複数ある場合、Kubernetes Serviceは`externalIPs`に指定したIPで公開されます。
そのexternalIP(到達先のIPとして扱われます)のServiceのポートからトラフィックがクラスターに入って来る場合、ServiceのEndpointsのどれか1つに対して転送されます。
もし1つ以上のクラスターNodeに転送するexternalIPが複数ある場合、Kubernetes Serviceは`externalIPs`に指定したIPで公開されます。
そのexternalIP(到達先のIPとして扱われます)のServiceのポートからトラフィックがクラスターに入って来る場合、ServiceのEndpointsのどれか1つに対して転送されます。
`externalIPs`はKubernetesによって管理されず、それを管理する責任はクラスターの管理者にあります。
Serviceのspecにおいて、`externalIPs`は他のどの`ServiceTypes`と併用して設定できます。
Serviceのspecにおいて、`externalIPs`は他のどの`ServiceTypes`と併用して設定できます。
下記の例では、"`my-service`"は"`80.11.12.10:80`" (`externalIP:port`)のクライアントからアクセス可能です。
```yaml
@@ -783,14 +787,14 @@ spec:
## Serviceのデメリット
仮想IP用にuserspaceモードのプロキシーを使用すると、小規模もしくは中規模のスケールでうまく稼働できますが、1000以上のServiceがあるようなとても大きなクラスターではうまくスケールしません。
これについては、[Serviceのデザインプロポーザル](http://issue.k8s.io/1107)にてさらなる詳細を確認できます。
仮想IP用にuserspaceモードのプロキシーを使用すると、小規模もしくは中規模のスケールでうまく稼働できますが、1000以上のServiceがあるようなとても大きなクラスターではうまくスケールしません。
これについては、[Serviceのデザインプロポーザル](http://issue.k8s.io/1107)にてさらなる詳細を確認できます。
userspaceモードのプロキシーの使用は、Serviceにアクセスするパケットの送信元IPアドレスが不明瞭になります。
これは、いくつかの種類のネットワークフィルタリング(ファイアウォールによるフィルタリング)を不可能にします。
userspaceモードのプロキシーの使用は、Serviceにアクセスするパケットの送信元IPアドレスが不明瞭になります。
これは、いくつかの種類のネットワークフィルタリング(ファイアウォールによるフィルタリング)を不可能にします。
iptablesプロキシーモードはクラスター内の送信元IPを不明瞭にはしませんが、依然としてロードバランサーやNodePortへ疎通するクライアントに影響があります。
`Type`フィールドはネストされた機能としてデザインされています。 - 各レベルの値は前のレベルに対して追加します。
`Type`フィールドはネストされた機能としてデザインされています。 - 各レベルの値は前のレベルに対して追加します。
これは全てのクラウドプロバイダーにおいて厳密に要求されていません(例: Google Compute Engineは`LoadBalancer`を動作させるために`NodePort`を割り当てる必要はありませんが、AWSではその必要があります)が、現在のAPIでは要求しています。
## 仮想IPの実装について {#the-gory-details-of-virtual-ips}
@@ -799,14 +803,14 @@ iptablesプロキシーモードはクラスター内の送信元IPを不明瞭
### 衝突の回避
Kubernetesの主要な哲学のうちの一つは、ユーザーは、ユーザー自身のアクションによるミスでないものによって、ユーザーのアクションが失敗するような状況に晒されるべきでないことです。
Serviceリソースの設計のでは、これはユーザーの指定したポートが衝突する可能性がある場合は、そのポートのServiceを作らないことを意味します。これは障害を分離することとなります。
Kubernetesの主要な哲学のうちの一つは、ユーザーは、ユーザー自身のアクションによるミスでないものによって、ユーザーのアクションが失敗するような状況に晒されるべきでないことです。
Serviceリソースの設計において、これはユーザーの指定したポートが衝突する可能性がある場合はそのポートのServiceを作らないことを意味します。これは障害を分離することとなります。
Serviceのポート番号を選択できるようにするために、我々はどの2つのServiceでもポートが衝突しないことを保証します。
Kubernetesは各Serviceに、それ自身のIPアドレスを割り当てることで実現しています。
Serviceのポート番号を選択できるようにするために、我々はどの2つのServiceでもポートが衝突しないことを保証します。
Kubernetesは各Serviceに、それ自身のIPアドレスを割り当てることで実現しています。
各Serviceが固有のIPを割り当てられるのを保証するために、内部のアロケーターは、Serviceを作成する前に、etcd内のグローバルの割り当てマップをアトミックに更新します。
そのマップオブジェクトはServiceのIPアドレスの割り当てのためにレジストリー内に存在しなくてはならず、そうでない場合は、Serviceの作成時にIPアドレスが割り当てられなかったことを示すエラーメッセージが表示されます。
各Serviceが固有のIPを割り当てられるのを保証するために、内部のアロケーターは、Serviceを作成する前に、etcd内のグローバルの割り当てマップをアトミックに更新します。
そのマップオブジェクトはServiceのIPアドレスの割り当てのためにレジストリー内に存在しなくてはならず、そうでない場合は、Serviceの作成時にIPアドレスが割り当てられなかったことを示すエラーメッセージが表示されます。
コントロールプレーンにおいて、バックグラウンドのコントローラーはそのマップを作成する責務があります(インメモリーのロックが使われていた古いバージョンのKubernetesのマイグレーションも必要です)。
また、Kubernetesは無効な割り当てがされているかをチェックすることと、現時点でどのServiceにも使用されていない割り当て済みIPアドレスのクリーンアップのためにコントローラーを使用します。
@@ -814,20 +818,20 @@ Kubernetesは各Serviceに、それ自身のIPアドレスを割り当てるこ
### ServiceのIPアドレス {#ips-and-vips}
実際に固定された向き先であるPodのIPアドレスとは異なり、ServiceのIPは実際には単一のホストによって応答されません。
その代わり、kube-proxyは必要な時に透過的にリダイレクトされる_仮想_ IPアドレスを定義するため、iptables(Linuxのパケット処理ロジック)を使用します。
その代わり、kube-proxyは必要な時に透過的にリダイレクトされる_仮想_ IPアドレスを定義するため、iptables(Linuxのパケット処理ロジック)を使用します。
クライアントがVIPに接続する時、そのトラフィックは自動的に適切なEndpointsに転送されます。
Service用の環境変数とDNSは、Serviceの仮想IPアドレス(とポート)の面において、自動的に生成されます。
Service用の環境変数とDNSは、Serviceの仮想IPアドレス(とポート)の面において、自動的に生成されます。
kube-proxyは3つの微妙に異なった動作をするプロキシーモード&mdash; userspace、iptablesとIPVS &mdash; をサポートしています。
#### Userspace
例として、上記で記述されている画像処理のアプリケーションを考えます。
バックエンドのServiceが作成されたとき、KubernetesのMasterは仮想IPを割り当てます。例えば10.0.0.1などです。
そのServiceのポートが1234で、そのServiceはクラスター内の全てのkube-proxyインスタンスによって監視されていると仮定します。
kube-proxyが新しいServiceを見つけた時、kube-proxyは新しいランダムポートをオープンし、その仮想IPアドレスの新しいポートにリダイレクトするようにiptablesを更新し、そのポート上で新しい接続を待ち受けを開始します。
例として、上記で記述されている画像処理のアプリケーションを考えます。
バックエンドのServiceが作成されたとき、KubernetesのMasterは仮想IPを割り当てます。例えば10.0.0.1などです。
そのServiceのポートが1234で、そのServiceはクラスター内の全てのkube-proxyインスタンスによって監視されていると仮定します。
kube-proxyが新しいServiceを見つけた時、kube-proxyは新しいランダムポートをオープンし、その仮想IPアドレスの新しいポートにリダイレクトするようにiptablesを更新し、そのポート上で新しい接続を待ち受けを開始します。
クライアントがServiceの仮想IPアドレスに接続したとき、iptablesルールが有効になり、そのパケットをプロキシー自身のポートにリダイレクトします。
クライアントがServiceの仮想IPアドレスに接続したとき、iptablesルールが有効になり、そのパケットをプロキシー自身のポートにリダイレクトします。
その"Service プロキシー"はバックエンドPodの対象を選択し、クライアントのトラフィックをバックエンドPodに転送します。
これはServiceのオーナーは、衝突のリスクなしに、求めるどのようなポートも選択できることを意味します。
@@ -835,13 +839,13 @@ kube-proxyが新しいServiceを見つけた時、kube-proxyは新しいラン
#### iptables
また画像処理のアプリケーションについて考えます。バックエンドServiceが作成された時、そのKubernetesコントロールプレーンは仮想IPアドレスを割り当てます。例えば10.0.0.1などです。
Serviceのポートが1234で、そのServiceがクラスター内のすべてのkube-proxyインスタンスによって監視されていると仮定します。
また画像処理のアプリケーションについて考えます。バックエンドServiceが作成された時、そのKubernetesコントロールプレーンは仮想IPアドレスを割り当てます。例えば10.0.0.1などです。
Serviceのポートが1234で、そのServiceがクラスター内のすべてのkube-proxyインスタンスによって監視されていると仮定します。
kube-proxyが新しいServiceを見つけた時、kube-proxyは仮想IPから各Serviceのルールにリダイレクトされるような、iptablesルールのセットをインストールします。
Service毎のルールは、トラフィックをバックエンドにリダイレクト(Destination NATを使用)しているEndpoints毎のルールに対してリンクしています。
クライアントがServiceの仮想IPアドレスに対して接続しているとき、そのiptablesルールが有効になります。
バックエンドのPodが選択され(SessionAffinityに基づくか、もしくはランダムで選択される)、パケットはバックエンドにリダイレクトされます。
クライアントがServiceの仮想IPアドレスに対して接続しているとき、そのiptablesルールが有効になります。
バックエンドのPodが選択され(SessionAffinityに基づくか、もしくはランダムで選択される)、パケットはバックエンドにリダイレクトされます。
userspaceモードのプロキシーとは異なり、パケットは決してuserspaceにコピーされず、kube-proxyは仮想IPのために稼働される必要はなく、またNodeでは変更されていないクライアントIPからトラフィックがきます。
このように同じ基本的なフローは、NodePortまたはLoadBalancerを介してトラフィックがきた場合に、実行され、ただクライアントIPは変更されます。
@@ -849,31 +853,25 @@ userspaceモードのプロキシーとは異なり、パケットは決してus
#### IPVS
iptablesの処理は、大規模なクラスターの場合劇的に遅くなります。例としてはServiceが10,000ほどある場合です。
IPVSは負荷分散のために設計され、カーネル内のハッシュテーブルに基づいています。そのためIPVSベースのkube-proxyによって、多数のServiceがある場合でも一貫して高パフォーマンスを実現できます。
IPVSは負荷分散のために設計され、カーネル内のハッシュテーブルに基づいています。そのためIPVSベースのkube-proxyによって、多数のServiceがある場合でも一貫して高パフォーマンスを実現できます。
次第に、IPVSベースのkube-proxyは負荷分散のアルゴリズムはさらに洗練されています(最小接続数、位置ベース、重み付け、永続性など)。
## APIオブジェクト
ServiceはKubernetesのREST APIにおいてトップレベルのリソースです。ユーザーはそのAPIオブジェクトに関して、[Service API object](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#service-v1-core)でさらなる情報を確認できます。
ServiceはKubernetesのREST APIにおいてトップレベルのリソースです。ユーザーはそのAPIオブジェクトに関して、[Service API object](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#service-v1-core)でさらなる情報を確認できます。
## サポートされているプロトコル {#protocol-support}
### TCP
{{< feature-state for_k8s_version="v1.0" state="stable" >}}
ユーザーはどの種類のServiceにおいてもTCPを利用できます。これはデフォルトのネットワークプロトコルです。
### UDP
{{< feature-state for_k8s_version="v1.0" state="stable" >}}
ユーザーは多くのServiceにおいてUDPを利用できます。 type=LoadBalancerのServiceにおいては、UDPのサポートはこの機能を提供しているクラウドプロバイダーに依存しています。
### HTTP
{{< feature-state for_k8s_version="v1.1" state="stable" >}}
もしクラウドプロバイダーがサポートしている場合、ServiceのEndpointsに転送される外部のHTTP/HTTPSでのリバースプロキシーをセットアップするために、LoadBalancerモードでServiceを作成可能です。
{{< note >}}
@@ -882,8 +880,6 @@ ServiceはKubernetesのREST APIにおいてトップレベルのリソースで
### PROXY プロトコル
{{< feature-state for_k8s_version="v1.1" state="stable" >}}
もしクラウドプロバイダーがサポートしている場合(例: [AWS](/docs/concepts/cluster-administration/cloud-providers/#aws))、Kubernetesクラスターの外部のロードバランサーを設定するためにLoadBalancerモードでServiceを利用できます。これは[PROXY protocol](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)がついた接続を転送します。
ロードバランサーは、最初の一連のオクテットを送信します。
@@ -900,7 +896,7 @@ PROXY TCP4 192.0.2.202 10.0.42.7 12345 7\r\n
KubernetseはService、Endpoints、NetworkPolicyとPodの定義においてα版の機能として`protocol`フィールドの値でSCTPをサポートしています。この機能を有効にするために、クラスター管理者はAPI Serverにおいて`SCTPSupport`というFeature Gateを有効にする必要があります。例えば、`--feature-gates=SCTPSupport=true,…`といったように設定します。
そのFeature Gateが有効になった時、ユーザーはService、Endpoints、NetworkPolicyの`protocol`フィールドと、Podの`SCTP`フィールドを設定できます。
そのFeature Gateが有効になった時、ユーザーはService、Endpoints、NetworkPolicyの`protocol`フィールドと、Podの`SCTP`フィールドを設定できます。
Kubernetesは、TCP接続と同様に、SCTPアソシエーションに応じてネットワークをセットアップします。
#### 警告 {#caveat-sctp-overview}
@@ -916,7 +912,7 @@ Kubernetesは、TCP接続と同様に、SCTPアソシエーションに応じて
##### type=LoadBalancer Service について {#caveat-sctp-loadbalancer-service-type}
{{< warning >}}
クラウドプロバイダーのロードバランサーの実装がプロトコルとしてSCTPをサポートしている場合は、`type` がLoadBalancerで` protocol`がSCTPの場合でのみサービスを作成できます。
クラウドプロバイダーのロードバランサーの実装がプロトコルとしてSCTPをサポートしている場合は、`type` がLoadBalancerで` protocol`がSCTPの場合でのみサービスを作成できます。
そうでない場合、Serviceの作成要求はリジェクトされます。現時点でのクラウドのロードバランサーのプロバイダー(Azure、AWS、CloudStack、GCE、OpenStack)は全てSCTPのサポートをしていません。
{{< /warning >}}
@@ -932,22 +928,12 @@ SCTPはWindowsベースのNodeではサポートされていません。
kube-proxyはuserspaceモードにおいてSCTPアソシエーションの管理をサポートしません。
{{< /warning >}}
## Future work
将来的に、Serviceのプロキシーポリシーはシンプルなラウンドロビンのバランシングだけでなく、もっと細かな設定が可能になります。例えば、Masterによって選択されるものや、水平シャーディングされたりするようになります。
我々もまた、いくつかのServiceが"実際の"ロードバランサーを備えることを想定します。その場合、仮想IPは単純にパケットをそのロードバランサーに転送します。
Kubernetesプロジェクトは、L7 (HTTP) Serviceへのサポートをもっと発展させようとしています。
Kubernetesプロジェクトは、現在利用可能なClusterIP、NodePortやLoadBalancerタイプのServiceに対して、より柔軟なIngressのモードを追加する予定です。
## {{% 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/)を参照してください。
* [EndpointSlices](/docs/concepts/services-networking/endpoint-slices/)を参照してください。
content/ja/docs/concepts/storage/dynamic-provisioning.md
+4 -3
View File
@@ -8,7 +8,7 @@ weight: 40
<!-- overview -->
ボリュームの動的プロビジョニングにより、ストレージ用のボリュームをオンデマンドに作成することができます。
動的プロビジョニングなしでは、クラスター管理者はクラウドプロバイダーまたはストレージプロバイダーに対して新規のストレージ用のボリュームと[`PersistentVolume`オブジェクト](/docs/concepts/storage/persistent-volumes/)を作成するように手動で指示しなければなりません。動的プロビジョニングの機能によって、クラスター管理者がストレージを事前にプロビジョンする必要がなくなります。その代わりに、ユーザーによってリクエストされたときに自動でストレージをプロビジョンします。
動的プロビジョニングなしでは、クラスター管理者はクラウドプロバイダーまたはストレージプロバイダーに対して新規のストレージ用のボリュームと[`PersistentVolume`オブジェクト](/ja/docs/concepts/storage/persistent-volumes/)を作成するように手動で指示しなければなりません。動的プロビジョニングの機能によって、クラスター管理者がストレージを事前にプロビジョンする必要がなくなります。その代わりに、ユーザーによってリクエストされたときに自動でストレージをプロビジョンします。
@@ -20,11 +20,12 @@ weight: 40
ボリュームの動的プロビジョニングの実装は`storage.k8s.io`というAPIグループ内の`StorageClass`というAPIオブジェクトに基づいています。クラスター管理者は`StorageClass`オブジェクトを必要に応じていくつでも定義でき、各オブジェクトはボリュームをプロビジョンする*Volumeプラグイン* (別名*プロビジョナー*)と、プロビジョンされるときにプロビジョナーに渡されるパラメータを指定します。
クラスター管理者はクラスター内で複数の種類のストレージ(同一または異なるストレージシステム)を定義し、さらには公開でき、それらのストレージはパラメータのカスタムセットを持ちます。この仕組みにおいて、エンドユーザーはストレージがどのようにプロビジョンされるか心配する必要がなく、それでいて複数のストレージオプションから選択できることを保証します。
StorageClassに関するさらなる情報は[Storage Class](/docs/concepts/storage/persistent-volumes/#storageclasses)を参照ください。
StorageClassに関するさらなる情報は[Storage Class](/docs/concepts/storage/storage-classes/)を参照ください。
## 動的プロビジョニングを有効にする
動的プロビジョニングを有効にするために、クラスター管理者はユーザーのために1つまたはそれ以上のStorageClassを事前に作成する必要があります。StorageClassオブジェクトは、動的プロビジョニングが実行されるときに、どのプロビジョナーが使用されるべきか、またどのようなパラメーターをプロビジョナーに渡すべきか定義します。
動的プロビジョニングを有効にするために、クラスター管理者はユーザーのために1つまたはそれ以上のStorageClassを事前に作成する必要があります。StorageClassオブジェクトは、動的プロビジョニングが実行されるときに、どのプロビジョナーが使用されるべきか、またどのようなパラメーターをプロビジョナーに渡すべきか定義します。StorageClassオブジェクトの名前は、有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。
下記のマニフェストでは標準的な永続化ディスクをプロビジョンする"slow"というStorageClassを作成します。
```yaml
content/ja/docs/concepts/storage/persistent-volumes.md
+28 -7
View File
@@ -54,7 +54,7 @@ APIサーバーのコマンドラインフラグの詳細については[kube-ap
### バインディング
ユーザは、特定のサイズのストレージとアクセスモードを指定した上で`PersistentVolumeClaim`を作成します（動的プロビジョニングの場合は、すでに作られています）。マスター内のコントロールループは、新しく作られるPVCをウォッチして、それにマッチするPVが見つかったときに、それらを紐付けます。PVが新しいPVC用に動的プロビジョニングされた場合、コントロールループは常にPVをそのPVCに紐付けます。そうでない場合、ユーザーは常に少なくとも要求したサイズ以上のボリュームを取得しますが、ボリュームは要求されたサイズを超えている可能性があります。一度紐付けされると、どのように紐付けられたかに関係なく`PersistentVolumeClaim`の紐付けは排他的（決められた特定のPVとしか結びつかない状態）になります。PVCからPVへの紐付けは1対1です。
ユーザは、特定のサイズのストレージとアクセスモードを指定した上でPersistentVolumeClaimを作成します（動的プロビジョニングの場合は、すでに作られています）。マスター内のコントロールループは、新しく作られるPVCをウォッチして、それにマッチするPVが見つかったときに、それらを紐付けます。PVが新しいPVC用に動的プロビジョニングされた場合、コントロールループは常にPVをそのPVCに紐付けます。そうでない場合、ユーザーは常に少なくとも要求したサイズ以上のボリュームを取得しますが、ボリュームは要求されたサイズを超えている可能性があります。一度紐付けされると、どのように紐付けられたかに関係なくPersistentVolumeClaimの紐付けは排他的（決められた特定のPVとしか結びつかない状態）になります。PVCからPVへの紐付けは、PersistentVolumeとPersistentVolumeClaim間の双方向の紐付けであるClaimRefを使用した1対1のマッピングになっています。
一致するボリュームが存在しない場合、クレームはいつまでも紐付けされないままになります。一致するボリュームが利用可能になると、クレームがバインドされます。たとえば、50GiのPVがいくつもプロビジョニングされているクラスターだとしても、100Giを要求するPVCとは一致しません。100GiのPVがクラスターに追加されると、PVCを紐付けできます。
@@ -99,7 +99,7 @@ Labels: type=local
Annotations: <none>
Finalizers: [kubernetes.io/pv-protection]
StorageClass: standard
Status: Available
Status: Terminating
Claim:
Reclaim Policy: Delete
Access Modes: RWO
@@ -131,7 +131,7 @@ Events: <none>
#### リサイクル
{{< warning >}}
`Recycle`再クレームポリシーは廃止されました。代わりに、動的プロビジョニングを使用することをおすすめします。
`Recycle`再クレームポリシーは非推奨になりました。代わりに、動的プロビジョニングを使用することをおすすめします。
{{< /warning >}}
基盤となるボリュームプラグインでサポートされている場合、`Recycle`再クレームポリシーはボリュームに対して基本的な削除(`rm -rf /thevolume/*`)を実行し、新しいクレームに対して再び利用できるようにします。
@@ -260,6 +260,8 @@ EBSの拡張は時間がかかる操作です。また変更は、ボリュー
## 永続ボリューム
各PVには、仕様とボリュームのステータスが含まれているspecとstatusが含まれています。
PersistentVolumeオブジェクトの名前は、有効な
[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。
```yaml
apiVersion: v1
@@ -282,6 +284,11 @@ spec:
server: 172.17.0.2
```
{{< note >}}
クラスター内でPersistentVolumeを使用するには、ボリュームタイプに関連するヘルパープログラムが必要な場合があります。
この例では、PersistentVolumeはNFSタイプで、NFSファイルシステムのマウントをサポートするためにヘルパープログラム`/sbin/mount.nfs`が必要になります。
{{< /note >}}
### 容量
通常、PVには特定のストレージ容量があります。これはPVの`capacity`属性を使用して設定されます。容量によって期待される単位を理解するためには、Kubernetesの[リソースモデル](https://git.k8s.io/community/contributors/design-proposals/scheduling/resources.md)を参照してください。
@@ -400,10 +407,13 @@ PVは[ノードアフィニティ](/docs/reference/generated/kubernetes-api/{{<
CLIにはPVに紐付いているPVCの名前が表示されます。
## 永続ボリューム要求
## 永続ボリューム要求 {#persistentvolumeclaims}
各PVCにはspecとステータスが含まれます。これは、仕様とクレームのステータスです。
PersistentVolumeClaimオブジェクトの名前は、有効な
[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。
```yaml
apiVersion: v1
kind: PersistentVolumeClaim
@@ -438,7 +448,7 @@ Podと同様に、クレームは特定の量のリソースを要求できま
### セレクター
クレームでは、[ラベルセレクター](/docs/concepts/overview/working-with-objects/labels/#label-selectors)を指定して、ボリュームセットをさらにフィルター処理できます。ラベルがセレクターに一致するボリュームのみがクレームにバインドできます。セレクターは2つのフィールドで構成できます。
クレームでは、[ラベルセレクター](/ja/docs/concepts/overview/working-with-objects/labels/#label-selectors)を指定して、ボリュームセットをさらにフィルター処理できます。ラベルがセレクターに一致するボリュームのみがクレームにバインドできます。セレクターは2つのフィールドで構成できます。
* `matchLabels` - ボリュームはこの値のラベルが必要です
* `matchExpressions` - キー、値のリスト、およびキーと値を関連付ける演算子を指定することによって作成された要件のリスト。有効な演算子は、In、NotIn、ExistsおよびDoesNotExistです。
@@ -594,7 +604,7 @@ Podにrawブロックデバイスを追加する場合は、マウントパス
## ボリュームのスナップショットとスナップショットからのボリュームの復元のサポート
{{< feature-state for_k8s_version="v1.12" state="alpha" >}}
{{< feature-state for_k8s_version="v1.17" state="beta" >}}
ボリュームスナップショット機能は、CSIボリュームプラグインのみをサポートするために追加されました。詳細については、[ボリュームのスナップショット](/docs/concepts/storage/volume-snapshots/)を参照してください。
@@ -624,7 +634,7 @@ spec:
{{< feature-state for_k8s_version="v1.16" state="beta" >}}
ボリュームの複製機能は、CSIボリュームプラグインのみをサポートするために追加されました。詳細については、[ボリュームの複製](/docs/concepts/storage/volume-pvc-datasource/)を参照してください。
ボリュームの複製機能は、CSIボリュームプラグインのみをサポートするために追加されました。詳細については、[ボリュームの複製](/ja/docs/concepts/storage/volume-pvc-datasource/)を参照してください。
PVCデータソースからのボリューム複製機能を有効にするには、apiserverおよびcontroller-managerで`VolumeSnapshotDataSource`フィーチャーゲートを有効にします。
@@ -658,4 +668,15 @@ spec:
- ユーザーがストレージクラス名を指定しない場合、`persistentVolumeClaim.storageClassName`フィールドはnilのままにする。これにより、PVはユーザーにクラスターのデフォルトストレージクラスで自動的にプロビジョニングされる。多くのクラスター環境ではデフォルトのストレージクラスがインストールされているが、管理者は独自のデフォルトストレージクラスを作成することができる。
- ツールがPVCを監視し、しばらくしてもバインドされないことをユーザーに表示する。これはクラスターが動的ストレージをサポートしない(この場合ユーザーは対応するPVを作成するべき)、もしくはクラスターがストレージシステムを持っていない(この場合ユーザーはPVCを必要とする設定をデプロイできない)可能性があることを示す。
## {{% heading "whatsnext" %}}
* [Creating a Persistent Volume](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolume)について学ぶ
* [Creating a Persistent Volume Claim](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolumeclaim)について学ぶ
* [Persistent Storage design document](https://git.k8s.io/community/contributors/design-proposals/storage/persistent-storage.md)を読む
### リファレンス
* [PersistentVolume](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolume-v1-core)
* [PersistentVolumeSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumespec-v1-core)
* [PersistentVolumeClaim](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaim-v1-core)
* [PersistentVolumeClaimSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaimspec-v1-core)
content/ja/docs/concepts/storage/volume-pvc-datasource.md
+16 -12
View File
@@ -6,16 +6,9 @@ weight: 30
<!-- overview -->
{{< feature-state for_k8s_version="v1.15" state="alpha" >}}
{{< feature-state for_k8s_version="v1.16" state="beta" >}}
このドキュメントではKubernetesで既存のCSIボリュームの複製についてのコンセプトを説明します。このページを読む前にあらかじめ[ボリューム](/docs/concepts/storage/volumes)についてよく理解していることが望ましいです。
この機能を使用するにはVolumePVCDataSourceのフィーチャーゲートを有効にする必要があります。
```
--feature-gates=VolumePVCDataSource=true
```
@@ -27,14 +20,17 @@ weight: 30
複製は既存のKubernetesボリュームの複製として定義され、標準のボリュームと同じように使用できます。唯一の違いは、プロビジョニング時に「新しい」空のボリュームを作成するのではなく、バックエンドデバイスが指定されたボリュームの正確な複製を作成することです。
複製の実装は、Kubernetes APIの観点からは新しいPVCの作成時に既存のバインドされていないPVCをdataSourceとして指定する機能を追加するだけです。
複製の実装は、Kubernetes APIの観点からは新しいPVCの作成時に既存のPVCをdataSourceとして指定する機能を追加するだけです。ソースPVCはバインドされており、使用可能でなければなりません(使用中ではありません)。
この機能を使用する場合、ユーザーは次のことに注意する必要があります:
* 複製のサポート(`VolumePVCDataSource`)はCSIドライバーのみです。
* 複製のサポートは動的プロビジョニングのみです。
* CSIドライバーはボリューム複製機能を実装している場合としていない場合があります。
* PVCは複製先のPVCと同じ名前空間に存在する場合にのみ複製できます（複製元と複製先は同じ名前空間になければなりません）。
* PVCは複製先のPVCと同じ名前空間に存在する場合にのみ複製できます(複製元と複製先は同じ名前空間になければなりません)。
* 複製は同じストレージクラス内でのみサポートされます。
- 宛先ボリュームは、ソースと同じストレージクラスである必要があります。
- デフォルトのストレージクラスを使用でき、仕様ではstorageClassNameを省略できます。
## プロビジョニング
@@ -48,13 +44,21 @@ metadata:
name: clone-of-pvc-1
namespace: myns
spec:
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
storageClassName: cloning
resources:
requests:
storage: 5Gi
dataSource:
kind: PersistentVolumeClaim
name: pvc-1
```
{{< note >}}
`spec.resources.requests.storage`に容量の値を指定する必要があります。指定する値は、ソースボリュームの容量と同じかそれ以上である必要があります。
{{< /note >}}
このyamlの作成結果は指定された複製元である`pvc-1`と全く同じデータを持つ`clone-of-pvc-1`という名前の新しいPVCです。
## 使い方
content/ja/docs/concepts/storage/volume-snapshot-classes.md
+13 -6
View File
@@ -21,28 +21,35 @@ weight: 30
## VolumeSnapshotClass リソース
各`VolumeSnapshotClass`は`snapshotter`と`parameters`フィールドを含み、それらは、そのクラスに属する`VolumeSnapshot`が動的にプロビジョンされるときに使われます。
各`VolumeSnapshotClass`は`driver`、`deletionPolicy`と`parameters`フィールドを含み、それらは、そのクラスに属する`VolumeSnapshot`が動的にプロビジョンされるときに使われます。
`VolumeSnapshotClass`オブジェクトの名前は重要であり、それはユーザーがどのように特定のクラスをリクエストできるかを示したものです。管理者は初めて`VolumeSnapshotClass`オブジェクトを作成するときに、その名前と他のパラメーターをセットし、そのオブジェクトは一度作成されるとそのあと更新することができません。
管理者は、バインド対象のクラスを1つもリクエストしないようなVolumeSnapshotのために、デフォルトの`VolumeSnapshotClass`を指定することができます。
```yaml
apiVersion: snapshot.storage.k8s.io/v1alpha1
apiVersion: snapshot.storage.k8s.io/v1beta1
kind: VolumeSnapshotClass
metadata:
name: csi-hostpath-snapclass
snapshotter: csi-hostpath
driver: hostpath.csi.k8s.io
deletionPolicy: Delete
parameters:
```
### Snapshotter
### Driver
VolumeSnapshotClassは、VolumeSnapshotをプロビジョンするときに何のCSIボリュームプラグインを使うか決定するための`snapshotter`フィールドを持っています。このフィールドは必須となります。
VolumeSnapshotClassは、VolumeSnapshotをプロビジョンするときに何のCSIボリュームプラグインを使うか決定するための`driver`フィールドを持っています。このフィールドは必須となります。
### DeletionPolicy
VolumeSnapshotClassにはdeletionPolicyがあります。これにより、バインドされている `VolumeSnapshot`オブジェクトが削除されるときに、`VolumeSnapshotContent`がどうなるかを設定することができます。VolumeSnapshotのdeletionPolicyは、`Retain`または`Delete`のいずれかです。このフィールドは指定しなければなりません。
deletionPolicyが`Delete`の場合、元となるストレージスナップショットは `VolumeSnapshotContent`オブジェクトとともに削除されます。deletionPolicyが`Retain`の場合、元となるスナップショットと`VolumeSnapshotContent`の両方が残ります。
## Parameters
VolumeSnapshotClassは、そのクラスに属するVolumeSnapshotを指定するパラメータを持っています。
`snapshotter`に応じて様々なパラメータを使用できます。
`driver`に応じて様々なパラメータを使用できます。
content/ja/docs/concepts/workloads/controllers/cron-jobs.md
+11 -4
View File
@@ -6,14 +6,21 @@ weight: 80
<!-- overview -->
{{< feature-state for_k8s_version="v1.8" state="beta" >}}
_CronJob_ は時刻ベースのスケジュールによって[Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/)を作成します。
_CronJob_ オブジェクトとは _crontab_ (cron table)ファイルでみられる一行のようなものです。
[Cron](https://ja.wikipedia.org/wiki/Cron)形式で記述された指定のスケジュールの基づき、定期的にジョブが実行されます。
{{< note >}}
すべての**CronJob**`スケジュール`: 時刻はジョブが開始されたマスタータイムゾーンに基づいています。
{{< /note >}}
{{< caution >}}
すべての**CronJob**`スケジュール`: 時刻はジョブが開始された{{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}}のタイムゾーンに基づいています。
コントロールプレーンがkube-controller-managerをPodもしくは素のコンテナで実行している場合、CronJobコントローラーのタイムゾーンとして、kube-controller-managerコンテナに設定されたタイムゾーンを使用します。
{{< /caution >}}
CronJobリソースのためのマニフェストを作成する場合、その名前が有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)か確認してください。
名前は52文字を超えることはできません。これはCronJobコントローラーが自動的に、与えられたジョブ名に11文字を追加し、ジョブ名の長さは最大で63文字以内という制約があるためです。
cronジョブを作成し、実行するインストラクション、または、cronジョブ仕様ファイルのサンプルについては、[Running automated tasks with cron jobs](/docs/tasks/job/automated-tasks-with-cron-jobs)をご覧ください。
@@ -27,7 +34,7 @@ cronジョブは一度のスケジュール実行につき、 _おおよそ_ 1
`startingDeadlineSeconds`が大きな値、もしくは設定されていない(デフォルト)、そして、`concurrencyPolicy`を`Allow`に設定している場合には、少なくとも一度、ジョブが実行されることを保証します。
最後にスケジュールされた時刻から現在までの間に、CronJobコントローラーはどれだけスケジュールが間に合わなかったのかをCronJobごとにチェックします。もし、100回以上スケジュールが失敗していると、ジョブは開始されずに、ログにエラーが記録されます。
最後にスケジュールされた時刻から現在までの間に、CronJob{{< glossary_tooltip term_id="controller" text="コントローラー">}}はどれだけスケジュールが間に合わなかったのかをCronJobごとにチェックします。もし、100回以上スケジュールが失敗していると、ジョブは開始されずに、ログにエラーが記録されます。
````
Cannot determine if job needs to be started. Too many missed start time (> 100). Set or decrease .spec.startingDeadlineSeconds or check clock skew.
content/ja/docs/concepts/workloads/controllers/daemonset.md
+9 -5
View File
@@ -12,8 +12,8 @@ _DaemonSet_ は全て(またはいくつか)のNodeが単一のPodのコピー
DaemonSetのいくつかの典型的な使用例は以下の通りです。
- `glusterd`や`ceph`のようなクラスターのストレージデーモンを各Node上で稼働させる。
- `fluentd`や`logstash`のようなログ集計デーモンを各Node上で稼働させる。
- [Prometheus Node Exporter](https://github.com/prometheus/node_exporter)や[Flowmill](https://github.com/Flowmill/flowmill-k8s/)、[Sysdig Agent](https://docs.sysdig.com)、`collectd`、[Dynatrace OneAgent](https://www.dynatrace.com/technologies/kubernetes-monitoring/)、 [AppDynamics Agent](https://docs.appdynamics.com/display/CLOUD/Container+Visibility+with+Kubernetes)、 [Datadog agent](https://docs.datadoghq.com/agent/kubernetes/daemonset_setup/)、 [New Relic agent](https://docs.newrelic.com/docs/integrations/kubernetes-integration/installation/kubernetes-installation-configuration)、Gangliaの`gmond`やInstana agentなどのようなNodeのモニタリングデーモンを各Node上で稼働させる。
- `fluentd`や`filebeat`のようなログ集計デーモンを各Node上で稼働させる。
- [Prometheus Node Exporter](https://github.com/prometheus/node_exporter)や[Flowmill](https://github.com/Flowmill/flowmill-k8s/)、[Sysdig Agent](https://docs.sysdig.com)、`collectd`、[Dynatrace OneAgent](https://www.dynatrace.com/technologies/kubernetes-monitoring/)、 [AppDynamics Agent](https://docs.appdynamics.com/display/CLOUD/Container+Visibility+with+Kubernetes)、 [Datadog agent](https://docs.datadoghq.com/agent/kubernetes/daemonset_setup/)、 [New Relic agent](https://docs.newrelic.com/docs/integrations/kubernetes-integration/installation/kubernetes-installation-configuration)、Gangliaの`gmond`、[Instana Agent](https://www.instana.com/supported-integrations/kubernetes-monitoring/)や[Elastic Metricbeat](https://www.elastic.co/guide/en/beats/metricbeat/current/running-on-kubernetes.html)などのようなNodeのモニタリングデーモンを各Node上で稼働させる。
シンプルなケースとして、各タイプのデーモンにおいて、全てのNodeをカバーする1つのDaemonSetが使用されるケースがあります。
さらに複雑な設定では、単一のタイプのデーモン用ですが、異なるフラグや、異なるハードウェアタイプに対するメモリー、CPUリクエストを要求する複数のDaemonSetを使用するケースもあります。
@@ -32,7 +32,8 @@ DaemonSetのいくつかの典型的な使用例は以下の通りです。
{{< codenew file="controllers/daemonset.yaml" >}}
* YAMLファイルに基づいてDaemonSetを作成します。
YAMLファイルに基づいてDaemonSetを作成します。
```
kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
```
@@ -42,6 +43,9 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
他の全てのKubernetesの設定と同様に、DaemonSetは`apiVersion`、`kind`と`metadata`フィールドが必須となります。
設定ファイルの活用法に関する一般的な情報は、[アプリケーションのデプロイ](/ja/docs/tasks/run-application/run-stateless-application-deployment/)、[コンテナの設定](/ja/docs/tasks/)、[kubectlを用いたオブジェクトの管理](/ja/docs/concepts/overview/working-with-objects/object-management/)といったドキュメントを参照ください。
DaemonSetオブジェクトの名前は、有効な
[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。
また、DaemonSetにおいて[`.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)セクションも必須となります。
### Podテンプレート
@@ -52,7 +56,7 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
Podに対する必須のフィールドに加えて、DaemonSet内のPodテンプレートは適切なラベルを指定しなくてはなりません([Podセレクター](#pod-selector)の項目を参照ください)。
DaemonSet内のPodテンプレートでは、[`RestartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)フィールドを指定せずにデフォルトの`Always`を使用するか、明示的に`Always`を設定するかのどちらかである必要があります。
DaemonSet内のPodテンプレートでは、[`RestartPolicy`](/ja/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)フィールドを指定せずにデフォルトの`Always`を使用するか、明示的に`Always`を設定するかのどちらかである必要があります。
### Podセレクター
@@ -80,7 +84,7 @@ selector](/ja/docs/concepts/configuration/assign-pod-node/)にマッチするPod
## Daemon Podがどのようにスケジューリングされるか
### デフォルトスケジューラーによってスケジューリングされる場合(Kubernetes1.12からデフォルトで有効)
### デフォルトスケジューラーによってスケジューリングされる場合
{{< feature-state state="stable" for-kubernetes-version="1.17" >}}
content/ja/docs/concepts/workloads/controllers/deployment.md
+80 -66
View File
@@ -46,83 +46,97 @@ Deploymentによって作成されたReplicaSetを管理しないでください
* `nginx-deployment`という名前のDeploymentが作成され、`.metadata.name`フィールドで名前を指定します。
* Deploymentは3つのレプリカPodを作成し、`replicas`フィールドによってレプリカ数を指定します。
* `selector`フィールドは、Deploymentが管理するPodのラベルを定義します。このケースにおいて、ユーザーはPodテンプレートにて定義されたラベル(`app: nginx`)を選択します。しかし、PodTemplate自体がそのルールを満たす限り、さらに洗練された方法でセレクターを指定することができます。
{{< note >}}
`matchLabels`フィールドは、キーとバリューのペアのマップとなります。`matchLabels`マップにおいて、{key, value}というペアは、keyというフィールドの値が"key"で、その演算子が"In"で、値の配列が"value"のみ含むような`matchExpressions`の要素と等しいです。
`matchLabels`と`matchExpressions`の両方が設定された場合、条件に一致するには両方とも満たす必要があります。
{{< /note >}}
{{< note >}}
`matchLabels`フィールドは、キーとバリューのペアのマップとなります。`matchLabels`マップにおいて、{key, value}というペアは、keyというフィールドの値が"key"で、その演算子が"In"で、値の配列が"value"のみ含むような`matchExpressions`の要素と等しいです。
`matchLabels`と`matchExpressions`の両方が設定された場合、条件に一致するには両方とも満たす必要があります。
{{< /note >}}
* `template`フィールドは、下記のサブフィールドを持ちます。:
* Podは`labels`フィールドによって指定された`app: nginx`というラベルがつけられる
* PodTemplateの仕様もしくは、`.template.spec`フィールドは、このPodは`nginx`という名前のコンテナーを1つ稼働させ、それは`nginx`というさせ、[Docker Hub](https://hub.docker.com/)にある`nginx`のバージョン1.14.2を使うことを示します
* 1つのコンテナを作成し、`name`フィールドを使って`nginx`という名前をつけます
上記のDeploymentを作成するために、以下に示すステップにしたがってください。
作成を始める前に、ユーザーのKubernetesクラスターが稼働していることを確認してください。
作成を始める前に、ユーザーのKubernetesクラスターが稼働していることを確認してください。
上記のDeploymentを作成するために、以下に示すステップにしたがってください。
1. 下記のコマンドを実行してDeploymentを作成してください。
1. 下記のコマンドを実行してDeploymentを作成してください。
{{< note >}}
実行したコマンドを`kubernetes.io/change-cause`というアノテーションに記録するために`--record`フラグを指定できます。これは将来的な問題の調査のために有効です。例えば、各Deploymentのリビジョンにおいて実行されたコマンドを見るときに便利です。
{{< /note >}}
```shell
kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml
```
2. Deploymentが作成されたことを確認するために、`kubectl get deployment`を実行してください。Deploymentがまだ作成中の場合、コマンドの実行結果は下記のとおりです。
```shell
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx-deployment 3 0 0 0 1s
```
ユーザーのクラスターにおいてDeploymentを調査するとき、下記のフィールドが出力されます。
* `NAME` クラスター内のDeploymentの名前を表示する
* `DESIRED` アプリケーションの理想的な_replicas_ の値を表示する: これはDeploymentを作成したときに定義したもので、これが_理想的な状態_ と呼ばれるものです。
* `CURRENT` 現在稼働中のレプリカ数
* `UP-TO-DATE` 理想的な状態にするために、アップデートが完了したレプリカ数
* `AVAILABLE` ユーザーが利用可能なレプリカ数
* `AGE` アプリケーションが稼働してからの時間
上記のyamlの例だと、`.spec.replicas`フィールドの値によると、理想的なレプリカ数は3です。
3. Deploymentのロールアウトステータスを確認するために、`kubectl rollout status deployment.v1.apps/nginx-deployment`を実行してください。コマンドの実行結果は下記のとおりです。
```shell
Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
deployment.apps/nginx-deployment successfully rolled out
```
4. 数秒後、再度`kubectl get deployments`を実行してください。コマンドの実行結果は下記のとおりです。
```shell
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx-deployment 3 3 3 3 18s
```
Deploymentが3つ全てのレプリカを作成して、全てのレプリカが最新(Podが最新のPodテンプレートを含んでいる)になり、利用可能となっていることを確認してください。
5. Deploymentによって作成されたReplicaSet (`rs`)を確認するには`kubectl get rs`を実行してください。コマンドの実行結果は下記のとおりです。
```shell
NAME DESIRED CURRENT READY AGE
nginx-deployment-75675f5897 3 3 3 18s
```
ReplicaSetの名前は`[Deployment名]-[ランダム文字列]`という形式になることに注意してください。ランダム文字列はランダムに生成され、pod-template-hashをシードとして使用します。
6. 各Podにラベルが自動的に付けられるのを確認するには`kubectl get pods --show-labels`を実行してください。コマンドの実行結果は下記のとおりです。
```shell
NAME READY STATUS RESTARTS AGE LABELS
nginx-deployment-75675f5897-7ci7o 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453
nginx-deployment-75675f5897-kzszj 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453
nginx-deployment-75675f5897-qqcnn 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453
```
作成されたReplicaSetは`nginx`Podを3つ作成することを保証します。
```shell
kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml
```
{{< note >}}
Deploymentに対して適切なセレクターとPodテンプレートのラベルを設定する必要があります(このケースでは`app: nginx`)。ラベルやセレクターを他のコントローラーと重複させないでください(他のDeploymentやStatefulSetを含む)。Kubernetesはユーザがラベルを重複させることを止めないため、複数のコントローラーでセレクターの重複が発生すると、コントローラー間で衝突し予期せぬふるまいをすることになります。
実行したコマンドを`kubernetes.io/change-cause`というアノテーションに記録するために`--record`フラグを指定できます。これは将来的な問題の調査のために有効です。例えば、各Deploymentのリビジョンにおいて実行されたコマンドを見るときに便利です。
{{< /note >}}
2. Deploymentが作成されたことを確認するために、`kubectl get deployment`を実行してください。
Deploymentがまだ作成中の場合、コマンドの実行結果は下記のとおりです。
```shell
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx-deployment 3 0 0 0 1s
```
ユーザーのクラスターにおいてDeploymentを調査するとき、下記のフィールドが出力されます。
* `NAME` クラスター内のDeploymentの名前を表示する
* `DESIRED` アプリケーションの理想的な_replicas_ の値を表示する: これはDeploymentを作成したときに定義したもので、これが_理想的な状態_ と呼ばれるものです。
* `CURRENT` 現在稼働中のレプリカ数
* `UP-TO-DATE` 理想的な状態にするために、アップデートが完了したレプリカ数
* `AVAILABLE` ユーザーが利用可能なレプリカ数
* `AGE` アプリケーションが稼働してからの時間
上記のyamlの例だと、`.spec.replicas`フィールドの値によると、理想的なレプリカ数は3です。
3. Deploymentのロールアウトステータスを確認するために、`kubectl rollout status deployment.v1.apps/nginx-deployment`を実行してください。
コマンドの実行結果は下記のとおりです。
```shell
Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
deployment.apps/nginx-deployment successfully rolled out
```
4. 数秒後、再度`kubectl get deployments`を実行してください。コマンドの実行結果は下記のとおりです。
```shell
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx-deployment 3 3 3 3 18s
```
Deploymentが3つ全てのレプリカを作成して、全てのレプリカが最新(Podが最新のPodテンプレートを含んでいる)になり、利用可能となっていることを確認してください。
5. Deploymentによって作成されたReplicaSet (`rs`)を確認するには`kubectl get rs`を実行してください。コマンドの実行結果は下記のとおりです。
```shell
NAME DESIRED CURRENT READY AGE
nginx-deployment-75675f5897 3 3 3 18s
```
ReplicaSetの出力には次のフィールドが表示されます:
* `NAME`は名前空間内のReplicaSetの名前を一覧表示します。
* `DESIRED`は、アプリケーションの_replicas_の希望数を表示します。これは、Deploymentを作成するときに定義します。これが_desired state_です。
* `CURRENT`は現在実行されているレプリカの数を表示します。
* `READY`は、ユーザーが使用できるアプリケーションのレプリカの数を表示します。
* `AGE`は、アプリケーションが実行されている時間を表示します。
ReplicaSetの名前は`[Deployment名]-[ランダム文字列]`という形式になることに注意してください。ランダム文字列はランダムに生成され、pod-template-hashをシードとして使用します。
6. 各Podにラベルが自動的に付けられるのを確認するには`kubectl get pods --show-labels`を実行してください。コマンドの実行結果は下記のとおりです。
```shell
NAME READY STATUS RESTARTS AGE LABELS
nginx-deployment-75675f5897-7ci7o 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453
nginx-deployment-75675f5897-kzszj 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453
nginx-deployment-75675f5897-qqcnn 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453
```
作成されたReplicaSetは`nginx`Podを3つ作成することを保証します。
{{< note >}}
Deploymentに対して適切なセレクターとPodテンプレートのラベルを設定する必要があります(このケースでは`app: nginx`)。ラベルやセレクターを他のコントローラーと重複させないでください(他のDeploymentやStatefulSetを含む)。Kubernetesはユーザがラベルを重複させることを止めないため、複数のコントローラーでセレクターの重複が発生すると、コントローラー間で衝突し予期せぬふるまいをすることになります。
{{< /note >}}
### pod-template-hashラベル
{{< note >}}
{{< caution >}}
このラベルを変更しないでください。
{{< /note >}}
{{< /caution >}}
`pod-template-hash`ラベルはDeploymentコントローラーによってDeploymentが作成し適用した各ReplicaSetに対して追加されます。
@@ -919,7 +933,7 @@ Deploymentは[`.spec`セクション](https://git.k8s.io/community/contributors/
Podの必須フィールドに加えて、Deployment内のPodテンプレートでは適切なラベルと再起動ポリシーを設定しなくてはなりません。ラベルは他のコントローラーと重複しないようにしてください。ラベルについては、[セレクター](#selector)を参照してください。
[`.spec.template.spec.restartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)が`Always`に等しいときのみ許可されます。これはテンプレートで指定されていない場合のデフォルト値です。
[`.spec.template.spec.restartPolicy`](/ja/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)が`Always`に等しいときのみ許可されます。これはテンプレートで指定されていない場合のデフォルト値です。
### レプリカ数
@@ -927,7 +941,7 @@ Podの必須フィールドに加えて、Deployment内のPodテンプレート
### セレクター {#selector}
`.spec.selector`は必須フィールドで、Deploymentによって対象とされるPodの[ラベルセレクター](/docs/concepts/overview/working-with-objects/labels/)を指定します。
`.spec.selector`は必須フィールドで、Deploymentによって対象とされるPodの[ラベルセレクター](/ja/docs/concepts/overview/working-with-objects/labels/)を指定します。
`.spec.selector`は`.spec.template.metadata.labels`と一致している必要があり、一致しない場合はAPIによって拒否されます。
@@ -973,7 +987,7 @@ Deploymentのテンプレートが`.spec.template`と異なる場合や、`.spec
### minReadySeconds {#min-ready-seconds}
`.spec.minReadySeconds`はオプションのフィールドで、新しく作成されたPodが利用可能となるために、最低どれくらいの秒数コンテナーがクラッシュすることなく稼働し続ければよいかを指定するものです。デフォルトでは0です(Podは作成されるとすぐに利用可能と判断されます)。Podが利用可能と判断された場合についてさらに学ぶために[Container Probes](/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)を参照してください。
`.spec.minReadySeconds`はオプションのフィールドで、新しく作成されたPodが利用可能となるために、最低どれくらいの秒数コンテナーがクラッシュすることなく稼働し続ければよいかを指定するものです。デフォルトでは0です(Podは作成されるとすぐに利用可能と判断されます)。Podが利用可能と判断された場合についてさらに学ぶために[Container Probes](/ja/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)を参照してください。
### rollbackTo
content/ja/docs/concepts/workloads/controllers/garbage-collection.md
+9 -9
View File
@@ -12,7 +12,7 @@ Kubernetesのガベージコレクターの役割は、かつてオーナーが
<!-- body -->
## オーナーとその従属オブジェクト
## オーナーとその従属オブジェクト {#owners-and-dependents}
いくつかのKubernetesオブジェクトは他のオブジェクトのオーナーとなります。例えば、ReplicaSetはPodのセットに対するオーナーです。オーナーによって所有されたオブジェクトは、オーナーオブジェクトの*従属オブジェクト(Dependents)* と呼ばれます。全ての従属オブジェクトは、オーナーオブジェクトを指し示す`metadata.ownerReferences`というフィールドを持ちます。
@@ -33,7 +33,7 @@ kubectl get pods --output=yaml
その出力結果によると、そのPodのオーナーは`my-repset`という名前のReplicaSetです。
```shell
```yaml
apiVersion: v1
kind: Pod
metadata:
@@ -70,7 +70,7 @@ metadata:
一度"削除処理中"状態に遷移すると、そのガベージコレクターはオブジェクトの従属オブジェクトを削除します。一度そのガベージコレクターが全ての”ブロッキングしている”従属オブジェクトを削除すると(`ownerReference.blockOwnerDeletion=true`という値を持つオブジェクト)、それはオーナーのオブジェクトも削除します。
注意点として、"フォアグラウンドのカスケード削除"において、`ownerReference.blockOwnerDeletion`フィールドを持つ従属オブジェクトのみ、そのオーナーオブジェクトの削除をブロックします。
注意点として、"フォアグラウンドのカスケード削除"において、`ownerReference.blockOwnerDeletion=true`フィールドを持つ従属オブジェクトのみ、そのオーナーオブジェクトの削除をブロックします。
Kubernetes1.7では、認証されていない従属オブジェクトがオーナーオブジェクトの削除を遅らせることができないようにするために[アドミッションコントローラー](/docs/reference/access-authn-authz/admission-controllers/#ownerreferencespermissionenforcement)が追加され、それは、オーナーオブジェクトの削除パーミッションに基づいて`blockOwnerDeletion`の値がtrueに設定してユーザーアクセスをコントロールします。
もしオブジェクトの`ownerReferences`フィールドがコントローラー(DeploymentやReplicaSetなど)によってセットされている場合、`blockOwnerDeletion`は自動的にセットされ、ユーザーはこのフィールドを手動で修正する必要はありません。
@@ -92,8 +92,8 @@ Kubernetes1.9において、`apps/v1`というグループバージョンにお
```shell
kubectl proxy --port=8080
curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-repset \
-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Background"}' \
-H "Content-Type: application/json"
-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Background"}' \
-H "Content-Type: application/json"
```
下記のコマンドは従属オブジェクトをフォアグラウンドで削除する例です。
@@ -101,8 +101,8 @@ curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-rep
```shell
kubectl proxy --port=8080
curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-repset \
-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Foreground"}' \
-H "Content-Type: application/json"
-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Foreground"}' \
-H "Content-Type: application/json"
```
下記のコマンドは従属オブジェクトをみなしご状態になった従属オブジェクトの例です。
@@ -110,8 +110,8 @@ curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-rep
```shell
kubectl proxy --port=8080
curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-repset \
-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Orphan"}' \
-H "Content-Type: application/json"
-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Orphan"}' \
-H "Content-Type: application/json"
```
kubectlもまたカスケード削除をサポートしています。
content/ja/docs/concepts/workloads/controllers/replicaset.md
+45 -44
View File
@@ -18,9 +18,9 @@ ReplicaSetの目的は、どのような時でも安定したレプリカPodの
ReplicaSetは、ReplicaSetが対象とするPodをどう特定するかを示すためのセレクターや、稼働させたいPodのレプリカ数、Podテンプレート(理想のレプリカ数の条件を満たすために作成される新しいPodのデータを指定するために用意されるもの)といったフィールドとともに定義されます。ReplicaSetは、指定された理想のレプリカ数にするためにPodの作成と削除を行うことにより、その目的を達成します。ReplicaSetが新しいPodを作成するとき、ReplicaSetはそのPodテンプレートを使用します。
ReplicaSetがそのPod群と連携するためのリンクは、Podの[metadata.ownerReferences](/docs/concepts/workloads/controllers/garbage-collection/#owners-and-dependents)というフィールド(現在のオブジェクトが所有されているリソースを指定する)を介して作成されます。ReplicaSetによって所持された全てのPodは、それらの`ownerReferences`フィールドにReplicaSetを特定する情報を保持します。このリンクを通じて、ReplicaSetは管理しているPodの状態を把握したり、その後の実行計画を立てます。
ReplicaSetがそのPod群と連携するためのリンクは、Podの[metadata.ownerReferences](/ja/docs/concepts/workloads/controllers/garbage-collection/#owners-and-dependents)というフィールド(現在のオブジェクトが所有されているリソースを指定する)を介して作成されます。ReplicaSetによって所持された全てのPodは、それらの`ownerReferences`フィールドにReplicaSetを特定する情報を保持します。このリンクを通じて、ReplicaSetは管理しているPodの状態を把握したり、その後の実行計画を立てます。
ReplicaSetは、そのセレクターを使用することにより、所有するための新しいPodを特定します。もし`ownerReference`フィールドの値を持たないPodか、`ownerReference`フィールドの値がコントローラーでないPodで、そのPodがReplicaSetのセレクターとマッチした場合に、そのPodは即座にそのReplicaSetによって所有されます。
ReplicaSetは、そのセレクターを使用することにより、所有するための新しいPodを特定します。もし`ownerReference`フィールドの値を持たないPodか、`ownerReference`フィールドの値が {{< glossary_tooltip text="コントローラー" term_id="controller" >}}でないPodで、そのPodがReplicaSetのセレクターとマッチした場合に、そのPodは即座にそのReplicaSetによって所有されます。
## ReplicaSetを使うとき
@@ -59,51 +59,48 @@ kubectl describe rs/frontend
```shell
Name: frontend
Namespace: default
Selector: tier=frontend,tier in (frontend)
Selector: tier=frontend
Labels: app=guestbook
tier=frontend
Annotations: <none>
Annotations: kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"apps/v1","kind":"ReplicaSet","metadata":{"annotations":{},"labels":{"app":"guestbook","tier":"frontend"},"name":"frontend",...
Replicas: 3 current / 3 desired
Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed
Pod Template:
Labels: app=guestbook
tier=frontend
Labels: tier=frontend
Containers:
php-redis:
Image: gcr.io/google_samples/gb-frontend:v3
Port: 80/TCP
Requests:
cpu: 100m
memory: 100Mi
Environment:
GET_HOSTS_FROM: dns
Mounts: <none>
Volumes: <none>
Image: gcr.io/google_samples/gb-frontend:v3
Port: <none>
Host Port: <none>
Environment: <none>
Mounts: <none>
Volumes: <none>
Events:
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
1m 1m 1 {replicaset-controller } Normal SuccessfulCreate Created pod: frontend-qhloh
1m 1m 1 {replicaset-controller } Normal SuccessfulCreate Created pod: frontend-dnjpy
1m 1m 1 {replicaset-controller } Normal SuccessfulCreate Created pod: frontend-9si5l
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulCreate 117s replicaset-controller Created pod: frontend-wtsmm
Normal SuccessfulCreate 116s replicaset-controller Created pod: frontend-b2zdv
Normal SuccessfulCreate 116s replicaset-controller Created pod: frontend-vcmts
```
そして最後に、ユーザーはReplicaSetによって作成されたPodもチェックできます。
```shell
kubectl get Pods
kubectl get pods
```
表示されるPodに関する情報は以下のようになります。
```shell
NAME READY STATUS RESTARTS AGE
frontend-9si5l 1/1 Running 0 1m
frontend-dnjpy 1/1 Running 0 1m
frontend-qhloh 1/1 Running 0 1m
NAME READY STATUS RESTARTS AGE
frontend-b2zdv 1/1 Running 0 6m36s
frontend-vcmts 1/1 Running 0 6m36s
frontend-wtsmm 1/1 Running 0 6m36s
```
ユーザーはまた、それらのPodの`ownerReferences`が`frontend`ReplicaSetに設定されていることも確認できます。
これを確認するためには、稼働しているPodの中のどれかのyamlファイルを取得します。
```shell
kubectl get pods frontend-9si5l -o yaml
kubectl get pods frontend-b2zdv -o yaml
```
その表示結果は、以下のようになります。その`frontend`ReplicaSetの情報が`metadata`の`ownerReferences`フィールドにセットされています。
@@ -111,19 +108,19 @@ kubectl get pods frontend-9si5l -o yaml
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: 2019-01-31T17:20:41Z
creationTimestamp: "2020-02-12T07:06:16Z"
generateName: frontend-
labels:
tier: frontend
name: frontend-9si5l
name: frontend-b2zdv
namespace: default
ownerReferences:
- apiVersion: extensions/v1beta1
- apiVersion: apps/v1
blockOwnerDeletion: true
controller: true
kind: ReplicaSet
name: frontend
uid: 892a2330-257c-11e9-aecd-025000000001
uid: f391f6db-bb9b-4c09-ae74-6a1f77f3d5cf
...
```
@@ -148,16 +145,17 @@ kubectl apply -f http://k8s.io/examples/pods/pod-rs.yaml
下記のコマンドでPodを取得できます。
```shell
kubectl get Pods
kubectl get pods
```
その表示結果で、新しいPodがすでに削除済みか、削除中のステータスになっているのを確認できます。
```shell
NAME READY STATUS RESTARTS AGE
frontend-9si5l 1/1 Running 0 1m
frontend-dnjpy 1/1 Running 0 1m
frontend-qhloh 1/1 Running 0 1m
pod2 0/1 Terminating 0 4s
frontend-b2zdv 1/1 Running 0 10m
frontend-vcmts 1/1 Running 0 10m
frontend-wtsmm 1/1 Running 0 10m
pod1 0/1 Terminating 0 1s
pod2 0/1 Terminating 0 1s
```
もしユーザーがそのPodを最初に作成する場合
@@ -173,15 +171,15 @@ kubectl apply -f http://k8s.io/examples/controllers/frontend.yaml
ユーザーはそのReplicaSetが作成したPodを所有し、さらにもともと存在していたPodと今回新たに作成されたPodの数が、理想のレプリカ数になるまでPodを作成するのを確認できます。
ここでまたPodの状態を取得します。
```shell
kubectl get Pods
kubectl get pods
```
取得結果は下記のようになります。
```shell
NAME READY STATUS RESTARTS AGE
frontend-pxj4r 1/1 Running 0 5s
pod1 1/1 Running 0 13s
pod2 1/1 Running 0 13s
frontend-hmmj2 1/1 Running 0 9s
pod1 1/1 Running 0 36s
pod2 1/1 Running 0 36s
```
この方法で、ReplicaSetはテンプレートで指定されたもの以外のPodを所有することができます。
@@ -192,6 +190,9 @@ pod2 1/1 Running 0 13s
ReplicaSetでは、`kind`フィールドの値は`ReplicaSet`です。
Kubernetes1.9において、ReplicaSetは`apps/v1`というAPIバージョンが現在のバージョンで、デフォルトで有効です。`apps/v1beta2`というAPIバージョンは廃止されています。先ほど作成した`frontend.yaml`ファイルの最初の行を参考にしてください。
ReplicaSetオブジェクトの名前は、有効な
[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。
また、ReplicaSetは[`.spec` セクション](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)も必須です。
### Pod テンプレート
@@ -203,7 +204,7 @@ Kubernetes1.9において、ReplicaSetは`apps/v1`というAPIバージョンが
### Pod セレクター
`.spec.selector`フィールドは[ラベルセレクター](/docs/concepts/overview/working-with-objects/labels/)です。
`.spec.selector`フィールドは[ラベルセレクター](/ja/docs/concepts/overview/working-with-objects/labels/)です。
[先ほど](#how-a-replicaset-works)議論したように、ReplicaSetが所有するPodを指定するためにそのラベルが使用されます。
先ほどの`frontend.yaml`の例では、そのセレクターは下記のようになっていました
```shell
@@ -228,13 +229,13 @@ matchLabels:
### ReplicaSetとPodの削除
ReplicaSetとそれが所有する全てのPod削除したいときは、[`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete)コマンドを使ってください。
[ガーベージコレクター](/docs/concepts/workloads/controllers/garbage-collection/)がデフォルトで自動的に全ての依存するPodを削除します。
[ガベージコレクター](/ja/docs/concepts/workloads/controllers/garbage-collection/)がデフォルトで自動的に全ての依存するPodを削除します。
REST APIもしくは`client-go`ライブラリーを使用するとき、ユーザーは`-d`オプションで`propagationPolicy`を`Background`か`Foreground`と指定しなくてはなりません。
例えば下記のように実行します。
```shell
kubectl proxy --port=8080
curl -X DELETE 'localhost:8080/apis/extensions/v1beta1/namespaces/default/replicasets/frontend' \
curl -X DELETE 'localhost:8080/apis/apps/v1/namespaces/default/replicasets/frontend' \
> -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Foreground"}' \
> -H "Content-Type: application/json"
```
@@ -245,7 +246,7 @@ curl -X DELETE 'localhost:8080/apis/extensions/v1beta1/namespaces/default/repli
REST APIもしくは`client-go`ライブラリーを使用するとき、ユーザーは`-d`オプションで`propagationPolicy`を`Orphan`と指定しなくてはなりません。
```shell
kubectl proxy --port=8080
curl -X DELETE 'localhost:8080/apis/extensions/v1beta1/namespaces/default/replicasets/frontend' \
curl -X DELETE 'localhost:8080/apis/apps/v1/namespaces/default/replicasets/frontend' \
> -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Orphan"}' \
> -H "Content-Type: application/json"
```
@@ -309,7 +310,7 @@ PodをPodそれ自身で停止させたいような場合(例えば、バッチ
### ReplicationController
ReplicaSetは[_ReplicationControllers_](/docs/concepts/workloads/controllers/replicationcontroller/)の後継となるものです。
この2つは、ReplicationControllerが[ラベルについてのユーザーガイド](/docs/concepts/overview/working-with-objects/labels/#label-selectors)に書かれているように、集合ベース(set-based)のセレクター要求をサポートしていないことを除いては、同じ目的を果たし、同じようにふるまいます。
この2つは、ReplicationControllerが[ラベルについてのユーザーガイド](/ja/docs/concepts/overview/working-with-objects/labels/#label-selectors)に書かれているように、集合ベース(set-based)のセレクター要求をサポートしていないことを除いては、同じ目的を果たし、同じようにふるまいます。
このように、ReplicaSetはReplicationControllerよりも好まれます。
content/ja/docs/concepts/workloads/controllers/statefulset.md
+14 -18
View File
@@ -9,10 +9,6 @@ weight: 40
StatefulSetはステートフルなアプリケーションを管理するためのワークロードAPIです。
{{< note >}}
StatefulSetはKubernetes1.9において利用可能(GA)です。
{{< /note >}}
{{< glossary_definition term_id="statefulset" length="all" >}}
@@ -28,12 +24,11 @@ StatefulSetは下記の1つ以上の項目を要求するアプリケーショ
* 規則的で自動化されたローリングアップデート
上記において安定とは、Podのスケジュール(または再スケジュール)をまたいでも永続的であることと同義です。
もしアプリケーションが安定したネットワーク識別子と規則的なデプロイや削除、スケーリングを全く要求しない場合、ユーザーはステートレスなレプリカのセットを提供するコントローラーを使ってアプリケーションをデプロイするべきです。
もしアプリケーションが安定したネットワーク識別子と規則的なデプロイや削除、スケーリングを全く要求しない場合、ユーザーはステートレスなレプリカのセットを提供するワークロードを使ってアプリケーションをデプロイするべきです。
[Deployment](/ja/docs/concepts/workloads/controllers/deployment/)や[ReplicaSet](/ja/docs/concepts/workloads/controllers/replicaset/)のようなコントローラーはこのようなステートレスな要求に対して最適です。
## 制限事項
* StatefuleSetはKubernetes1.9より以前のバージョンではβ版のリソースであり、1.5より前のバージョンでは利用できません。
* 提供されたPodのストレージは、要求された`storage class`にもとづいて[PersistentVolume Provisioner](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/README.md)によってプロビジョンされるか、管理者によって事前にプロビジョンされなくてはなりません。
* StatefulSetの削除もしくはスケールダウンをすることにより、StatefulSetに関連したボリュームは削除*されません* 。 これはデータ安全性のためで、関連するStatefulSetのリソース全てを自動的に削除するよりもたいてい有効です。
* StatefulSetは現在、Podのネットワークアイデンティティーに責務をもつために[Headless Service](/ja/docs/concepts/services-networking/service/#headless-service)を要求します。ユーザーはこのServiceを作成する責任があります。
@@ -101,11 +96,13 @@ spec:
* webという名前のStatefulSetは、specで3つのnginxコンテナのレプリカを持ち、そのコンテナはそれぞれ別のPodで稼働するように設定されています。
* volumeClaimTemplatesは、PersistentVolumeプロビジョナーによってプロビジョンされた[PersistentVolume](/docs/concepts/storage/persistent-volumes/)を使って安定したストレージを提供します。
StatefulSetの名前は有効な[名前](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。
## Podセレクター
ユーザーは、StatefulSetの`.spec.template.metadata.labels`のラベルと一致させるため、StatefulSetの`.spec.selector`フィールドをセットしなくてはなりません。Kubernetes1.8以前では、`.spec.selector`フィールドは省略された場合デフォルト値になります。Kubernetes1.8とそれ以降のバージョンでは、ラベルに一致するPodセレクターの指定がない場合はStatefulSetの作成時にバリデーションエラーになります。
## Podアイデンティティー
StatefulSetのPodは、順番を示す番号、安定したネットワークアイデンティティー、安定したストレージからなる一意なアイデンティティーを持ちます。
StatefulSetのPodは、順番を示す番号、安定したネットワークアイデンティティー、安定したストレージからなる一意なアイデンティティーを持ちます。
そのアイデンティティーはどのNode上にスケジュール(もしくは再スケジュール)されるかに関わらず、そのPodに紐付きます。
### 順序インデックス
@@ -116,8 +113,8 @@ N個のレプリカをもったStatefulSetにおいて、StatefulSet内の各Pod
StatefulSet内の各Podは、そのStatefulSet名とPodの順序番号から派生してホストネームが割り当てられます。
作成されたホストネームの形式は`$(StatefulSet名)-$(順序番号)`となります。先ほどの上記の例では、`web-0,web-1,web-2`という3つのPodが作成されます。
StatefulSetは、Podのドメインをコントロールするために[Headless Service](/ja/docs/concepts/services-networking/service/#headless-service)を使うことができます。
このHeadless Serviceによって管理されたドメインは`$(Service名).$(ネームスペース).svc.cluster.local`形式となり、"cluster.local"というのはそのクラスターのドメインとなります。
StatefulSetは、Podのドメインをコントロールするために[Headless Service](/ja/docs/concepts/services-networking/service/#headless-service)を使うことができます。
このHeadless Serviceによって管理されたドメインは`$(Service名).$(ネームスペース).svc.cluster.local`形式となり、"cluster.local"というのはそのクラスターのドメインとなります。
各Podが作成されると、Podは`$(Pod名).$(管理するServiceドメイン名)`に一致するDNSサブドメインを取得し、管理するServiceはStatefulSetの`serviceName`で定義されます。
[制限事項](#制限事項)セクションで言及したように、ユーザーはPodのネットワークアイデンティティーのために[Headless Service](/ja/docs/concepts/services-networking/service/#headless-service)を作成する責任があります。
@@ -131,18 +128,18 @@ Cluster Domain | Service (ns/name) | StatefulSet (ns/name) | StatefulSet Domain
kube.local | foo/nginx | foo/web | nginx.foo.svc.kube.local | web-{0..N-1}.nginx.foo.svc.kube.local | web-{0..N-1} |
{{< note >}}
クラスタードメインは[その他の設定](/docs/concepts/services-networking/dns-pod-service/)がされない限り、`cluster.local`にセットされます。
クラスタードメインは[その他の設定](/ja/docs/concepts/services-networking/dns-pod-service/)がされない限り、`cluster.local`にセットされます。
{{< /note >}}
### 安定したストレージ
Kubernetesは各VolumeClaimTemplateに対して、1つの[PersistentVolume](/docs/concepts/storage/persistent-volumes/)を作成します。上記のnginxの例において、各Podは`my-storage-class`というStorageClassをもち、1Gibのストレージ容量を持った単一のPersistentVolumeを受け取ります。もしStorageClassが指定されていない場合、デフォルトのStorageClassが使用されます。PodがNode上にスケジュール(もしくは再スケジュール)されたとき、その`volumeMounts`はPersistentVolume Claimに関連したPersistentVolumeをマウントします。
Kubernetesは各VolumeClaimTemplateに対して、1つの[PersistentVolume](/docs/concepts/storage/persistent-volumes/)を作成します。上記のnginxの例において、各Podは`my-storage-class`というStorageClassをもち、1Gibのストレージ容量を持った単一のPersistentVolumeを受け取ります。もしStorageClassが指定されていない場合、デフォルトのStorageClassが使用されます。PodがNode上にスケジュール(もしくは再スケジュール)されたとき、その`volumeMounts`はPersistentVolume Claimに関連したPersistentVolumeをマウントします。
注意点として、PodのPersistentVolume Claimと関連したPersistentVolumeは、PodやStatefulSetが削除されたときに削除されません。
削除する場合は手動で行わなければなりません。
### Podのネームラベル
StatefulSetのコントローラーがPodを作成したとき、Podの名前として、`statefulset.kubernetes.io/pod-name`にラベルを追加します。このラベルによってユーザーはServiceにStatefulSet内の指定したPodを割り当てることができます。
StatefulSet {{< glossary_tooltip text="コントローラー" term_id="controller" >}} がPodを作成したとき、Podの名前として、`statefulset.kubernetes.io/pod-name`にラベルを追加します。このラベルによってユーザーはServiceにStatefulSet内の指定したPodを割り当てることができます。
## デプロイとスケーリングの保証
@@ -151,7 +148,7 @@ StatefulSetのコントローラーがPodを作成したとき、Podの名前と
* Podに対してスケーリングオプションが適用される前に、そのPodの前の順番の全てのPodがRunningかつReady状態になっていなくてはなりません。
* Podが停止される前に、そのPodの番号より大きい番号を持つの全てのPodは完全にシャットダウンされていなくてはなりません。
StatefulSetは`pod.Spec.TerminationGracePeriodSeconds`を0に指定すべきではありません。これは不安全で、やらないことを強く推奨します。さらなる説明としては、[StatefulSetのPodの強制削除](/docs/tasks/run-application/force-delete-stateful-set-pod/)を参照してください。
StatefulSetは`pod.Spec.TerminationGracePeriodSeconds`を0に指定すべきではありません。これは不安全で、やらないことを強く推奨します。さらなる説明としては、[StatefulSetのPodの強制削除](/ja/docs/tasks/run-application/force-delete-stateful-set-pod/)を参照してください。
上記の例のnginxが作成されたとき、3つのPodは`web-0`、`web-1`、`web-2`の順番でデプロイされます。`web-1`は`web-0`が[RunningかつReady状態](/docs/user-guide/pod-states/)になるまでは決してデプロイされないのと、同様に`web-2`は`web-1`がRunningかつReady状態にならないとデプロイされません。もし`web-0`が`web-1`がRunningかつReady状態になった後だが、`web-2`が起動する前に失敗した場合、`web-2`は`web-0`の再起動が成功し、RunningかつReady状態にならないと再起動されません。
@@ -176,13 +173,13 @@ Kubernetes1.7とそれ以降のバージョンにおいて、StatefulSetの`.spe
`OnDelete`というアップデートストラテジーは、レガシーな(Kubernetes1.6以前)振る舞いとなります。StatefulSetの`.spec.updateStrategy.type`が`OnDelete`にセットされていたとき、そのStatefulSetコントローラーはStatefulSet内でPodを自動的に更新しません。StatefulSetの`.spec.template`項目の修正を反映した新しいPodの作成をコントローラーに支持するためには、ユーザーは手動でPodを削除しなければなりません。
### RollinUpdate
### RollingUpdate
`RollinUpdate`というアップデートストラテジーは、StatefulSet内のPodに対する自動化されたローリングアップデートの機能を実装します。これは`.spec.updateStrategy`フィールドが未指定の場合のデフォルトのストラテジーです。StatefulSetの`.spec.updateStrategy.type`が`RollingUpdate`にセットされたとき、そのStatefulSetコントローラーは、StatefulSet内のPodを削除し、再作成します。これはPodの停止(Podの番号の降順)と同じ順番で、一度に1つのPodを更新します。コントローラーは、その前のPodの状態がRunningかつReady状態になるまで次のPodの更新を待ちます。
`RollingUpdate`というアップデートストラテジーは、StatefulSet内のPodに対する自動化されたローリングアップデートの機能を実装します。これは`.spec.updateStrategy`フィールドが未指定の場合のデフォルトのストラテジーです。StatefulSetの`.spec.updateStrategy.type`が`RollingUpdate`にセットされたとき、そのStatefulSetコントローラーは、StatefulSet内のPodを削除し、再作成します。これはPodの停止(Podの番号の降順)と同じ順番で、一度に1つのPodを更新します。コントローラーは、その前のPodの状態がRunningかつReady状態になるまで次のPodの更新を待ちます。
#### パーティション
`RollingUpdate`というアップデートストラテジーは、`.spec.updateStrategy.rollingUpdate.partition`を指定することにより、パーティションに分けることができます。もしパーティションが指定されていたとき、そのパーティションの値と等しいか、大きい番号を持つPodが更新されます。パーティションの値より小さい番号を持つPodは更新されず、たとえそれらのPodが削除されたとしても、それらのPodは以前のバージョンで再作成されます。もしStatefulSetの`.spec.updateStrategy.rollingUpdate.partition`が、`.spec.replicas`より大きい場合、`.spec.template`への更新はPodに反映されません。
`RollingUpdate`というアップデートストラテジーは、`.spec.updateStrategy.rollingUpdate.partition`を指定することにより、パーティションに分けることができます。もしパーティションが指定されていたとき、そのパーティションの値と等しいか、大きい番号を持つPodが更新されます。パーティションの値より小さい番号を持つPodは更新されず、たとえそれらのPodが削除されたとしても、それらのPodは以前のバージョンで再作成されます。もしStatefulSetの`.spec.updateStrategy.rollingUpdate.partition`が、`.spec.replicas`より大きい場合、`.spec.template`への更新はPodに反映されません。
多くのケースの場合、ユーザーはパーティションを使う必要はありませんが、もし一部の更新を行う場合や、カナリー版のバージョンをロールアウトする場合や、段階的ロールアウトを行う場合に最適です。
#### 強制ロールバック
@@ -201,6 +198,5 @@ Kubernetes1.7とそれ以降のバージョンにおいて、StatefulSetの`.spe
* [ステートフルなアプリケーションのデプロイ](/docs/tutorials/stateful-application/basic-stateful-set/)の例を参考にしてください。
* [StatefulSetを使ったCassandraのデプロイ](/docs/tutorials/stateful-application/cassandra/)の例を参考にしてください。
* [レプリカを持つステートフルアプリケーションを実行する](/ja/docs/tasks/run-application/run-replicated-stateful-application/)の例を参考にしてください。
content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md
+3 -3
View File
@@ -9,10 +9,10 @@ weight: 65
{{< feature-state for_k8s_version="v1.12" state="alpha" >}}
TTLコントローラーは実行を終えたリソースオブジェクトのライフタイムを制御するためのTTLメカニズムを提供します。
TTLコントローラーは実行を終えたリソースオブジェクトのライフタイムを制御するためのTTL (time to live) メカニズムを提供します。
TTLコントローラーは現在[Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/)のみ扱っていて、将来的にPodやカスタムリソースなど、他のリソースの実行終了を扱えるように拡張される予定です。
α版の免責事項: この機能は現在α版の機能で、[Feature Gate](/docs/reference/command-line-tools-reference/feature-gates/)の`TTLAfterFinished`を有効にすることで使用可能です。
α版の免責事項: この機能は現在α版の機能で、kube-apiserverとkube-controller-managerの[Feature Gate](/docs/reference/command-line-tools-reference/feature-gates/)の`TTLAfterFinished`を有効にすることで使用可能です。
@@ -52,6 +52,6 @@ Kubernetesにおいてタイムスキューを避けるために、全てのNode
[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)
[設計ドキュメント](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0026-ttl-after-finish.md)
content/ja/docs/concepts/workloads/pods/pod-lifecycle.md
+38 -23
View File
@@ -13,7 +13,7 @@ weight: 30
<!-- body -->
## PodのPhase
## PodのPhase {#pod-phase}
Podの`status`項目は[PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core)オブジェクトで、それは`phase`のフィールドがあります。
@@ -33,7 +33,7 @@ Podの各フェーズの値と意味は厳重に守られています。
`Failed` | Pod内のすべてのコンテナが終了し、少なくとも1つのコンテナが異常終了しました。つまり、コンテナはゼロ以外のステータスで終了したか、システムによって終了されました。
`Unknown` | 何らかの理由により、通常はPodのホストとの通信にエラーが発生したために、Podの状態を取得できませんでした。
## Podのconditions
## Podのconditions {#pod-conditions}
PodにはPodStatusがあります。それはPodが成功したかどうかの情報を持つ[PodConditions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podcondition-v1-core)の配列です。
PodCondition配列の各要素には、次の6つのフィールドがあります。
@@ -53,11 +53,10 @@ PodCondition配列の各要素には、次の6つのフィールドがありま
* `PodScheduled`: PodがNodeにスケジュールされました。
* `Ready`: Podはリクエストを処理でき、一致するすべてのサービスの負荷分散プールに追加されます。
* `Initialized`: すべての[init containers](/docs/concepts/workloads/pods/init-containers)が正常に実行されました。
* `Unschedulable`: リソースの枯渇やその他の理由で、Podがスケジュールできない状態です。
* `ContainersReady`: Pod内のすべてのコンテナが準備できた状態です。
## コンテナのProbe
## コンテナのProbe {#container-probes}
[Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core) は [kubelet](/docs/admin/kubelet/) により定期的に実行されるコンテナの診断です。
診断を行うために、kubeletはコンテナに実装された [ハンドラー](https://godoc.org/k8s.io/kubernetes/pkg/api/v1#Handler)を呼びます。
@@ -80,7 +79,7 @@ Handlerには次の3つの種類があります:
* Failure: コンテナの診断が失敗しました。
* Unknown: コンテナの診断が失敗し、取れるアクションがありません。
Kubeletは2種類のProbeを実行中のコンテナで行い、また反応することができます:
Kubeletは3種類のProbeを実行中のコンテナで行い、また反応することができます:
* `livenessProbe`: コンテナが動いているかを示します。
livenessProbe に失敗すると、kubeletはコンテナを殺します、そしてコンテナは[restart policy](#restart-policy)に従います。
@@ -91,7 +90,14 @@ Kubeletは2種類のProbeを実行中のコンテナで行い、また反応す
initial delay前のデフォルトのreadinessProbeの初期値は`Failure`です。
コンテナにreadinessProbeが設定されていない場合、デフォルトの状態は`Success`です。
### livenessProbeとreadinessProbeをいつ使うべきか?
* `startupProbe`: コンテナ内のアプリケーションが起動したかどうかを示します。
startupProbeが設定された場合、完了するまでその他のすべてのProbeは無効になります。
startupProbeに失敗すると、kubeletはコンテナを殺します、そしてコンテナは[restart policy](#restart-policy)に従います。
コンテナにstartupProbeが設定されていない場合、デフォルトの状態は`Success`です。
### livenessProbeをいつ使うべきか? {#when-should-you-use-a-liveness-probe}
{{< feature-state for_k8s_version="v1.0" state="stable" >}}
コンテナ自体に問題が発生した場合や状態が悪くなった際にクラッシュすることができれば
livenessProbeは不要です。この場合kubeletが自動でPodの`restartPolicy`に基づいたアクションを実行します。
@@ -99,6 +105,10 @@ livenessProbeは不要です。この場合kubeletが自動でPodの`restartPoli
Probeに失敗したときにコンテナを殺したり再起動させたりするには、
livenessProbeを設定し`restartPolicy`をAlwaysまたはOnFailureにします。
### readinessProbeをいつ使うべきか? {#when-should-you-use-a-readiness-probe}
{{< feature-state for_k8s_version="v1.0" state="stable" >}}
Probeが成功したときにのみPodにトラフィックを送信したい場合は、readinessProbeを指定します。
この場合readinessProbeはlivenessProbeと同じになる可能性がありますが、
readinessProbeが存在するということは、Podがトラフィックを受けずに開始され、Probe成功が開始した後でトラフィックを受け始めることになります。
@@ -108,19 +118,28 @@ readinessProbeが存在するということは、Podがトラフィックを受
livenessProbeとは異なる、特定のエンドポイントを確認するreadinessProbeを指定することができます。
Podが削除されたときにリクエストを来ないようにするためには必ずしもreadinessProbeが必要というわけではありません。
Podの削除時にはreadinessProbeが存在するかどうかに関係なくPodは自動的に自身をunhealthyにします。
Pod内のコンテナが停止するのを待つ間Podはunhealthyのままです。
Podの削除時にはreadinessProbeが存在するかどうかに関係なくPodは自動的に自身をunreadyにします。
Pod内のコンテナが停止するのを待つ間Podはunreadyのままです。
livenessProbeまたはreadinessProbeを設定する方法の詳細については、
[Configure Liveness and Readiness Probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/)を参照してください
### startupProbeをいつ使うべきか? {#when-should-you-use-a-startup-probe}
## Podとコンテナのステータス
{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
コンテナの起動時間が `initialDelaySeconds + failureThreshold × periodSeconds` よりも長い場合は、livenessProbeと同じエンドポイントをチェックするためにstartupProbeを指定します。
`periodSeconds`のデフォルトは30秒です。
`failureThreshold` は、livenessProbeのデフォルト値を変更せずに、コンテナが起動するのに十分な値に設定します。これによりデッドロックを防ぐことができます。
livenessProbe、readinessProbeまたはstartupProbeを設定する方法の詳細については、
[Configure Liveness, Readiness and Startup Probes](/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)を参照してください。
## Podとコンテナのステータス {#pod-and-container-status}
PodとContainerのステータスについての詳細の情報は、それぞれ[PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core)と
[ContainerStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core)を参照してください。
Podのステータスとして報告される情報は、現在の[ContainerState](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core)に依存しています。
## コンテナのステータス
## コンテナのステータス {#container-states}
PodがスケジューラによってNodeに割り当てられると、
kubeletはコンテナのランタイムを使用してコンテナの作成を開始します。
@@ -137,7 +156,7 @@ Pod内のコンテナごとにStateの項目として表示されます。
...
```
* `Running`: コンテナが問題なく実行されていることを示します。コンテナがRunningに入ると`postStart`フック（もしあれば）が実行されます。この状態にはコンテナが実行中状態に入った時刻も表示されます。
* `Running`: コンテナが問題なく実行されていることを示します。コンテナがRunning状態に入る前に`postStart`フック（もしあれば）が実行されます。この状態にはコンテナが実行中状態に入った時刻も表示されます。
```yaml
...
@@ -146,7 +165,7 @@ Pod内のコンテナごとにStateの項目として表示されます。
...
```
* `Terminated`: コンテナの実行が完了しコンテナの実行が停止したことを示します。コンテナは実行が正常に完了したときまたは何らかの理由で失敗したときにこの状態になります。いずれにせよ理由と終了コード、コンテナの開始時刻と終了時刻が表示されます。コンテナがTerminatedに入る前に`preStop`フックがあればあれば実行されます。
* `Terminated`: コンテナの実行が完了しコンテナの実行が停止したことを示します。コンテナは実行が正常に完了したときまたは何らかの理由で失敗したときにこの状態になります。いずれにせよ理由と終了コード、コンテナの開始時刻と終了時刻が表示されます。コンテナがTerminatedに入る前に`preStop`フックがあれば実行されます。
```yaml
...
@@ -158,7 +177,7 @@ Pod内のコンテナごとにStateの項目として表示されます。
...
```
## PodReadinessGate
## PodReadinessGate {#pod-readiness-gate}
{{< feature-state for_k8s_version="v1.14" state="stable" >}}
@@ -190,7 +209,7 @@ status:
...
```
新しいPod Conditionは、Kubernetesの[label key format](/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set)に準拠している必要があります。
新しいPod Conditionは、Kubernetesの[label key format](/ja/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set)に準拠している必要があります。
`kubectl patch`コマンドはオブジェクトステータスのパッチ適用をまだサポートしていないので、
新しいPod Conditionは[KubeClient libraries](/docs/reference/using-api/client-libraries/)のどれかを使用する必要があります。
@@ -201,18 +220,14 @@ status:
PodのReadinessの評価へのこの変更を容易にするために、新しいPod Conditionである`ContainersReady`が導入され、古いPodの`Ready`条件を取得します。
K8s 1.1ではAlpha機能のため"Pod Ready++" 機能は`PodReadinessGates` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)にて明示的に指定する必要があります。
K8s 1.12ではこの機能はデフォルトで有効になっています。
## RestartPolicy
## RestartPolicy {#restart-policy}
PodSpecには、Always、OnFailure、またはNeverのいずれかの値を持つ`restartPolicy`フィールドがあります。
デフォルト値はAlwaysです。`restartPolicy`は、Pod内のすべてのコンテナに適用されます。
`restartPolicy`は、同じNode上のkubeletによるコンテナの再起動のみを参照します。
kubeletによって再起動される終了したコンテナは、5分後にキャップされた指数バックオフ遅延（10秒、20秒、40秒...）で再起動され、10分間の実行後にリセットされます。[Pods document](/docs/user-guide/pods/#durability-of-pods-or-lack-thereof)に書かれているように、一度NodeにバインドされるとPodは別のポートにバインドされ直すことはありません。
## Podのライフタイム
## Podのライフタイム {#pod-lifetime}
一般にPodは人間またはコントローラーが明示的に削除するまで存在します。
コントロールプレーンは終了状態のPod(SucceededまたはFailedの`phase`を持つ)の数が設定された閾値（kube-controller-manager内の`terminated-pod-gc-threshold`によって定義される）を超えたとき、それらのPodを削除します。
@@ -325,7 +340,7 @@ spec:
* [attaching handlers to Container lifecycle events](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)のハンズオンをやってみる
* [configuring liveness and readiness probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/)のハンズオンをやってみる
* [Configure Liveness, Readiness and Startup Probes](/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)のハンズオンをやってみる
* [Container lifecycle hooks](/docs/concepts/containers/container-lifecycle-hooks/)についてもっと学ぶ
content/ja/docs/concepts/workloads/pods/pod-overview.md
+12 -12
View File
@@ -2,7 +2,7 @@
title: Podについての概観(Pod Overview)
content_type: concept
weight: 10
card:
card:
name: concepts
weight: 60
---
@@ -13,7 +13,7 @@ card:
<!-- body -->
## Podについて理解する
## Podについて理解する {#understanding-pods}
*Pod* は、Kubernetesアプリケーションの基本的な実行単位です。これは、作成またはデプロイするKubernetesオブジェクトモデルの中で最小かつ最も単純な単位です。Podは、{{< glossary_tooltip term_id="cluster" >}}で実行されているプロセスを表します。
@@ -23,19 +23,19 @@ Podは、アプリケーションのコンテナ(いくつかの場合におい
Kubernetesクラスター内でのPodは2つの主な方法で使うことができます。
* **単一のコンテナを稼働させるPod** : いわゆる*「1Pod1コンテナ」* 構成のモデルは、最も一般的なKubernetesのユースケースです。
* **単一のコンテナを稼働させるPod** : いわゆる*「1Pod1コンテナ」* 構成のモデルは、最も一般的なKubernetesのユースケースです。
このケースでは、ユーザーはPodを単一のコンテナのラッパーとして考えることができ、Kubernetesはコンテナを直接扱うというよりは、Podを管理することになります。
* **協調して稼働させる必要がある複数のコンテナを稼働させるPod** : 単一のPodは、リソースを共有する必要があるような、密接に連携した複数の同じ環境にあるコンテナからなるアプリケーションをカプセル化することもできます。 これらの同じ環境にあるコンテナ群は、サービスの結合力の強いユニットを構成することができます。
* **協調して稼働させる必要がある複数のコンテナを稼働させるPod** : 単一のPodは、リソースを共有する必要があるような、密接に連携した複数の同じ環境にあるコンテナからなるアプリケーションをカプセル化することもできます。 これらの同じ環境にあるコンテナ群は、サービスの結合力の強いユニットを構成することができます。
-- 1つのコンテナが、共有されたボリュームからファイルをパブリックな場所に送信し、一方では分割された*サイドカー* コンテナがそれらのファイルを更新します。そのPodはそれらのコンテナとストレージリソースを、単一の管理可能なエンティティとしてまとめます。
[Kubernetes Blog](http://kubernetes.io/blog)にて、Podのユースケースに関するいくつかの追加情報を見ることができます。さらなる情報を得たい場合は、下記のページを参照ください。
[Kubernetes Blog](https://kubernetes.io/blog)にて、Podのユースケースに関するいくつかの追加情報を見ることができます。さらなる情報を得たい場合は、下記のページを参照ください。
* [The Distributed System Toolkit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)
* [The Distributed System Toolkit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)
* [Container Design Patterns](https://kubernetes.io/blog/2016/06/container-design-patterns)
各Podは、与えられたアプリケーションの単一のインスタンスを稼働するためのものです。もしユーザーのアプリケーションを水平にスケールさせたい場合(例: 複数インスタンスを稼働させる)、複数のPodを使うべきです。1つのPodは各インスタンスに対応しています。
Kubernetesにおいて、これは一般的に_レプリケーション_ と呼ばれます。
レプリケーションされたPodは、通常コントローラーと呼ばれる抽象概念によって単一のグループとして作成、管理されます。
Kubernetesにおいて、これは一般的に_レプリケーション_ と呼ばれます。
レプリケーションされたPodは、通常コントローラーと呼ばれる抽象概念によって単一のグループとして作成、管理されます。
さらなる情報に関しては[Podとコントローラー](#pods-and-controllers)を参照して下さい。
### Podがどのように複数のコンテナを管理しているか
@@ -57,7 +57,7 @@ Podは、Podによって構成されたコンテナ群のために2種類の共
#### ストレージ
単一のPodは共有されたストレージ{{< glossary_tooltip term_id="volume" >}}のセットを指定できます。Pod内の全てのコンテナは、その共有されたボリュームにアクセスでき、コンテナ間でデータを共有することを可能にします。ボリュームもまた、もしPod内のコンテナの1つが再起動が必要になった場合に備えて、データを永続化できます。
単一のPodは共有されたストレージ{{< glossary_tooltip term_id="volume" >}}のセットを指定できます。Pod内の全てのコンテナは、その共有されたボリュームにアクセスでき、コンテナ間でデータを共有することを可能にします。ボリュームもまた、もしPod内のコンテナの1つが再起動が必要になった場合に備えて、データを永続化できます。
単一のPod内での共有ストレージをKubernetesがどう実装しているかについてのさらなる情報については、[Volumes](/docs/concepts/storage/volumes/)を参照してください。
## Podを利用する
@@ -69,7 +69,7 @@ Podは、Podによって構成されたコンテナ群のために2種類の共
単一のPod内でのコンテナを再起動することと、そのPodを再起動することを混同しないでください。Podはそれ自体は実行されませんが、コンテナが実行される環境であり、削除されるまで存在し続けます。
{{< /note >}}
Podは、Podそれ自体によって自己修復しません。もし、稼働されていないノード上にPodがスケジュールされた場合や、スケジューリング操作自体が失敗した場合、Podが削除されます。同様に、Podはリソースの欠如や、ノードのメンテナンスによる追い出しがあった場合はそこで停止します。Kubernetesは*コントローラー* と呼ばれる高レベルの抽象概念を使用し、それは比較的使い捨て可能なPodインスタンスの管理を行います。
Podは、Podそれ自体によって自己修復しません。もし、稼働されていないノード上にPodがスケジュールされた場合や、スケジューリング操作自体が失敗した場合、Podが削除されます。同様に、Podはリソースの欠如や、ノードのメンテナンスによる追い出しがあった場合はそこで停止します。Kubernetesは*コントローラー* と呼ばれる高レベルの抽象概念を使用し、それは比較的使い捨て可能なPodインスタンスの管理を行います。
このように、Podを直接使うのは可能ですが、コントローラーを使用したPodを管理する方がより一般的です。KubernetesがPodのスケーリングと修復機能を実現するためにコントローラーをどのように使うかに関する情報は[Podとコントローラー](#pods-and-controllers)を参照してください。
### Podとコントローラー
@@ -88,7 +88,7 @@ Podは、Podそれ自体によって自己修復しません。もし、稼働
Podテンプレートは、[ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/)、 [Job](/docs/concepts/jobs/run-to-completion-finite-workloads/)や、
[DaemonSet](/ja/docs/concepts/workloads/controllers/daemonset/)のような他のオブジェクト内で含まれるPodの仕様となります。
コントローラーは実際のPodを作成するためにPodテンプレートを使用します。
コントローラーは実際のPodを作成するためにPodテンプレートを使用します。
下記のサンプルは、メッセージを表示する単一のコンテナを含んだ、シンプルなPodのマニフェストとなります。
```yaml
@@ -114,6 +114,6 @@ spec:
* [Pod](/ja/docs/concepts/workloads/pods/pod/)について更に学びましょう
* Podの振る舞いに関して学ぶには下記を参照してください
* [Podの停止](/ja/docs/concepts/workloads/pods/pod/#podの終了)
* [Podの停止](/ja/docs/concepts/workloads/pods/pod/#termination-of-pods)
* [Podのライフサイクル](/ja/docs/concepts/workloads/pods/pod-lifecycle/)
content/ja/docs/concepts/workloads/pods/pod.md
+6 -6
View File
@@ -34,7 +34,7 @@ Pod内のアプリケーションからアクセスできる共有ボリュー
[Docker](https://www.docker.com/)の用語でいえば、Podは共有namespaceと共有[ボリューム](/docs/concepts/storage/volumes/)を持つDockerコンテナのグループとしてモデル化されています。
個々のアプリケーションコンテナと同様に、Podは（永続的ではなく）比較的短期間の存在と捉えられます。
[Podのライフサイクル](/docs/concepts/workloads/pods/pod-lifecycle/)で説明しているように、Podが作成されると、一意のID（UID）が割り当てられ、（再起動ポリシーに従って）終了または削除されるまでNodeで実行されるようにスケジュールされます。
[Podのライフサイクル](/ja/docs/concepts/workloads/pods/pod-lifecycle/)で説明しているように、Podが作成されると、一意のID（UID）が割り当てられ、（再起動ポリシーに従って）終了または削除されるまでNodeで実行されるようにスケジュールされます。
Nodeが停止した場合、そのNodeにスケジュールされたPodは、タイムアウト時間の経過後に削除されます。
特定のPod（UIDで定義）は新しいNodeに「再スケジュール」されません。
代わりに、必要に応じて同じ名前で、新しいUIDを持つ同一のPodに置き換えることができます（詳細については[ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/)を参照してください）。
@@ -126,7 +126,7 @@ Podは、以下のことを容易にするためにプリミティブとして
* アプリケーションの可用性を高める。
即ち、計画的な追い出しやイメージのプリフェッチなどの場合に、Podが停止し削除される前に、必ず事前に入れ換えられることを期待する
## Podの終了
## Podの終了 {#termination-of-pods}
Podは、クラスター内のNodeで実行中のプロセスを表すため、不要になったときにそれらのプロセスを正常に終了できるようにすることが重要です（対照的なケースは、KILLシグナルで強制終了され、クリーンアップする機会がない場合）。
ユーザーは削除を要求可能であるべきで、プロセスがいつ終了するかを知ることができなければなりませんが、削除が最終的に完了することも保証できるべきです。
@@ -141,7 +141,7 @@ Podは、クラスター内のNodeで実行中のプロセスを表すため、
1. クライアントのコマンドに表示されたとき、Podは「終了中」と表示される
1. （3と同時に）Kubeletは、2の期間が設定されたためにPodが終了中となったことを認識すると、Podのシャットダウン処理を開始する
1. Pod内のコンテナの1つが[preStopフック](/docs/concepts/containers/container-lifecycle-hooks/#hook-details)を定義している場合は、コンテナの内側で呼び出される。
猶予期間が終了した後も `preStop` フックがまだ実行されている場合は、次に、短い延長された猶予期間（2秒）でステップ2が呼び出される
猶予期間が終了した後も `preStop`フックがまだ実行されている場合は、一度だけ猶予期間を延長して（2秒）、ステップ2が呼び出される。`preStop`フックが完了するまでにより長い時間が必要な場合は、`terminationGracePeriodSeconds`を変更する必要がある。
1. コンテナにTERMシグナルが送信される。Pod内のすべてのコンテナが同時にTERMシグナルを受信するわけではなく、シャットダウンの順序が問題になる場合はそれぞれに `preStop` フックが必要になることがある
1. （3と同時に）Podはサービスを提供するエンドポイントのリストから削除され、ReplicationControllerの実行中のPodの一部とは見なされなくなる。
ゆっくりとシャットダウンするPodは、（サービスプロキシのような）ロードバランサーがローテーションからそれらを削除するので、トラフィックを処理し続けることはできない
@@ -157,14 +157,14 @@ kubectlのバージョン1.5以降では、強制削除を実行するために
### Podの強制削除
Podの強制削除は、クラスターの状態やetcdからPodを直ちに削除することと定義されます。
強制削除が実行されると、apiserverは、Podが実行されていたNode上でPodが停止されたというkubeletからの確認を待ちません。
強制削除が実行されると、API serverは、Podが実行されていたNode上でPodが停止されたというkubeletからの確認を待ちません。
API内のPodは直ちに削除されるため、新しいPodを同じ名前で作成できるようになります。
Node上では、すぐに終了するように設定されるPodは、強制終了される前にわずかな猶予期間が与えられます。
強制削除は、Podによっては潜在的に危険な場合があるため、慎重に実行する必要があります。
StatefulSetのPodについては、[StatefulSetからPodを削除するためのタスクのドキュメント](/docs/tasks/run-application/force-delete-stateful-set-pod/)を参照してください。
StatefulSetのPodについては、[StatefulSetからPodを削除するためのタスクのドキュメント](/ja/docs/tasks/run-application/force-delete-stateful-set-pod/)を参照してください。
## Podコンテナの特権モード
## Podコンテナの特権モード {#privileged-mode-for-pod-containers}
Kubernetes v1.1以降、Pod内のどのコンテナでも、コンテナ仕様の `SecurityContext` の `privileged ` フラグを使用して特権モードを有効にできます。
これは、ネットワークスタックの操作やデバイスへのアクセスなど、Linuxの機能を使用したいコンテナにとって役立ちます。
content/ja/docs/concepts/workloads/pods/podpreset.md
+8 -2
View File
@@ -14,7 +14,7 @@ weight: 50
## PodPresetを理解する
`PodPreset`はPodの作成時に追加のランタイム要求を注入するためのAPIリソースです。
ユーザーはPodPresetを適用する対象のPodを指定するために、[ラベルセレクター](/docs/concepts/overview/working-with-objects/labels/#label-selectors)を使用します。
ユーザーはPodPresetを適用する対象のPodを指定するために、[ラベルセレクター](/ja/docs/concepts/overview/working-with-objects/labels/#label-selectors)を使用します。
PodPresetの使用により、Podテンプレートの作者はPodにおいて、全ての情報を明示的に指定する必要がなくなります。
この方法により、特定のServiceを使っているPodテンプレートの作者は、そのServiceについて全ての詳細を知る必要がなくなります。
@@ -48,7 +48,13 @@ PodPresetによるPodの変更を受け付けたくないようなインスタ
ユーザーのクラスター内でPodPresetを使うためには、クラスター内の以下の項目をご確認ください。
1. `settings.k8s.io/v1alpha1/podpreset`というAPIを有効にします。例えば、これはAPI Serverの `--runtime-config`オプションに`settings.k8s.io/v1alpha1=true`を含むことで可能になります。Minikubeにおいては、クラスターの起動時に`--extra-config=apiserver.runtime-config=settings.k8s.io/v1alpha1=true`をつけることで可能です。
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. `PodPreset`に対する管理コントローラーを有効にします。これを行うための1つの方法として、API Serverの`--enable-admission-plugins`オプションの値に`PodPreset`を含む方法があります。Minikubeにおいては、クラスターの起動時に
```shell
--extra-config=apiserver.enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,PodPreset
```
を追加することで可能になります。
1. ユーザーが使う予定のNamespaceにおいて、`PodPreset`オブジェクトを作成することによりPodPresetを定義します。
content/ja/docs/home/_index.md
+7
View File
@@ -15,6 +15,8 @@ menu:
weight: 20
post: >
<p>チュートリアル、サンプルやドキュメントのリファレンスを使って Kubernetes の利用方法を学んでください。あなたは<a href="/editdocs/" data-auto-burger-exclude>ドキュメントへコントリビュートをする</a>こともできます!</p>
description: >
Kubernetesは、コンテナ化されたアプリケーションの展開、スケーリング、また管理を自動化するためのオープンソースコンテナプラットフォームです。このオープンソースプロジェクトは、Cloud Native Computing Foundationによってホストされています。
overview: >
Kubernetesは、コンテナ化されたアプリケーションの展開、スケーリング、また管理を自動化するためのオープンソースコンテナプラットフォームです。このオープンソースプロジェクトは、Cloud Native Computing Foundationによってホストされています（<a href="https://www.cncf.io/about">CNCF</a>）。
cards:
@@ -38,6 +40,11 @@ cards:
description: "一般的なタスク、そのタスクを短い手順でどのように実行するかを見てみます。"
button: "タスクを見る"
button_path: "/docs/tasks"
- name: training
title: "トレーニング"
description: "Kubernetesの資格を取得して、クラウドネイティブプロジェクトを成功させます！"
button: "トレーニングを見る"
button_path: "/training"
- name: reference
title: "リファレンス情報を調べる"
description: "用語、コマンドラインの構文、APIリソースタイプ、そして構築ツールのドキュメントを見て回ります。"
content/ja/docs/reference/_index.md
+9 -15
View File
@@ -17,12 +17,7 @@ content_type: concept
## APIリファレンス
* [Kubernetes API概要](/docs/reference/using-api/api-overview/) - Kubernetes APIの概要です。
* Kubernetes APIバージョン
* [1.17](/docs/reference/generated/kubernetes-api/v1.17/)
* [1.16](/docs/reference/generated/kubernetes-api/v1.16/)
* [1.15](/docs/reference/generated/kubernetes-api/v1.15/)
* [1.14](/docs/reference/generated/kubernetes-api/v1.14/)
* [1.13](/docs/reference/generated/kubernetes-api/v1.13/)
* [Kubernetes APIリファレンス {{< latest-version >}}](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/)
## APIクライアントライブラリー
@@ -35,18 +30,17 @@ content_type: concept
## CLIリファレンス
* [kubectl](/docs/user-guide/kubectl-overview) - コマンドの実行やKubernetesクラスターの管理に使う主要なCLIツールです。
* [JSONPath](/docs/user-guide/jsonpath/) - kubectlで[JSONPath記法](http://goessner.net/articles/JsonPath/)を使うための構文ガイドです。
* [kubeadm](/docs/admin/kubeadm/) - セキュアなKubernetesクラスターを簡単にプロビジョニングするためのCLIツールです。
* [kubefed](/docs/admin/kubefed/) - 連合型クラスターを管理するのに役立つCLIツールです。
* [kubectl](/docs/reference/kubectl/overview/) - コマンドの実行やKubernetesクラスターの管理に使う主要なCLIツールです。
* [JSONPath](/docs/reference/kubectl/jsonpath/) - kubectlで[JSONPath記法](http://goessner.net/articles/JsonPath/)を使うための構文ガイドです。
* [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) - セキュアなKubernetesクラスターを簡単にプロビジョニングするためのCLIツールです。
## 設定リファレンス
* [kubelet](/docs/admin/kubelet/) - 各ノード上で動作する最も重要なノードエージェントです。kubeletは一通りのPodSpecを受け取り、コンテナーが実行中で正常であることを確認します。
* [kube-apiserver](/docs/admin/kube-apiserver/) - Pod、Service、Replication Controller等、APIオブジェクトのデータを検証・設定するREST APIサーバーです。
* [kube-controller-manager](/docs/admin/kube-controller-manager/) - Kubernetesに同梱された、コアのコントロールループを埋め込むデーモンです。
* [kube-proxy](/docs/admin/kube-proxy/) - 単純なTCP/UDPストリームのフォワーディングや、一連のバックエンド間でTCP/UDPのラウンドロビンでのフォワーディングを実行できます。
* [kube-scheduler](/docs/admin/kube-scheduler/) - 可用性、パフォーマンス、およびキャパシティを管理するスケジューラーです。
* [kubelet](/docs/reference/command-line-tools-reference/kubelet/) - 各ノード上で動作する最も重要なノードエージェントです。kubeletは一通りのPodSpecを受け取り、コンテナーが実行中で正常であることを確認します。
* [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/) - Pod、Service、Replication Controller等、APIオブジェクトのデータを検証・設定するREST APIサーバーです。
* [kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/) - Kubernetesに同梱された、コアのコントロールループを埋め込むデーモンです。
* [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) - 単純なTCP/UDPストリームのフォワーディングや、一連のバックエンド間でTCP/UDPのラウンドロビンでのフォワーディングを実行できます。
* [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/) - 可用性、パフォーマンス、およびキャパシティを管理するスケジューラーです。
## 設計のドキュメント
content/ja/docs/reference/command-line-tools-reference/feature-gates.md
+4 -4
View File
@@ -322,7 +322,7 @@ GAになってからさらなる変更を加えることは現実的ではない
- `CSIPersistentVolume`: [CSI(Container Storage Interface)](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md)互換のボリュームプラグインを通してプロビジョニングされたボリュームの検出とマウントを有効にします。
詳細については[`csi`ボリュームタイプ](/docs/concepts/storage/volumes/#csi)ドキュメントを確認してください。
- `CustomCPUCFSQuotaPeriod`: ノードがCPUCFSQuotaPeriodを変更できるようにします。
- `CustomPodDNS`: `dnsConfig`プロパティを使用したPodのDNS設定のカスタマイズを有効にします。詳細は[PodのDNS構成](/docs/concepts/services-networking/dns-pod-service/#pods-dns-config)で確認できます。
- `CustomPodDNS`: `dnsConfig`プロパティを使用したPodのDNS設定のカスタマイズを有効にします。詳細は[PodのDNS構成](/ja/docs/concepts/services-networking/dns-pod-service/#pods-dns-config)で確認できます。
- `CustomResourceDefaulting`: OpenAPI v3バリデーションスキーマにおいて、デフォルト値のCRDサポートを有効にします。
- `CustomResourcePublishOpenAPI`: CRDのOpenAPI仕様での公開を有効にします。
- `CustomResourceSubresources`: [CustomResourceDefinition](/docs/concepts/api-extension/custom-resources/)から作成されたリソースの`/status`および`/scale`サブリソースを有効にします。
@@ -333,7 +333,7 @@ GAになってからさらなる変更を加えることは現実的ではない
- `DynamicAuditing`: [動的監査](/docs/tasks/debug-application-cluster/audit/#dynamic-backend)を有効にします。
- `DynamicKubeletConfig`: kubeletの動的構成を有効にします。[kubeletの再設定](/docs/tasks/administer-cluster/reconfigure-kubelet/)を参照してください。
- `DynamicProvisioningScheduling`: デフォルトのスケジューラーを拡張してボリュームトポロジーを認識しPVプロビジョニングを処理します。この機能は、v1.12の`VolumeScheduling`機能に完全に置き換えられました。
- `DynamicVolumeProvisioning`(*非推奨*): Podへの永続ボリュームの[動的プロビジョニング](/docs/concepts/storage/dynamic-provisioning/)を有効にします。
- `DynamicVolumeProvisioning`(*非推奨*): Podへの永続ボリュームの[動的プロビジョニング](/ja/docs/concepts/storage/dynamic-provisioning/)を有効にします。
- `EnableAggregatedDiscoveryTimeout` (*非推奨*): 集約されたディスカバリーコールで5秒のタイムアウトを有効にします。
- `EnableEquivalenceClassCache`: Podをスケジュールするときにスケジューラーがノードの同等をキャッシュできるようにします。
- `EphemeralContainers`: 稼働するPodに{{< glossary_tooltip text="ephemeral containers" term_id="ephemeral-container" >}}を追加する機能を有効にします。
@@ -361,7 +361,7 @@ GAになってからさらなる変更を加えることは現実的ではない
- `PersistentLocalVolumes`: Podで`local`ボリュームタイプの使用を有効にします。`local`ボリュームを要求する場合、podアフィニティを指定する必要があります。
- `PodOverhead`: [PodOverhead](/docs/concepts/configuration/pod-overhead/)機能を有効にして、Podのオーバーヘッドを考慮するようにします。
- `PodPriority`: [優先度](/docs/concepts/configuration/pod-priority-preemption/)に基づいてPodの再スケジューリングとプリエンプションを有効にします。
- `PodReadinessGates`: Podのreadinessの評価を拡張するために`PodReadinessGate`フィールドの設定を有効にします。詳細は[Pod readiness gate](/docs/concepts/workloads/pods/pod-lifecycle/#pod-readiness-gate)で確認できます。
- `PodReadinessGates`: Podのreadinessの評価を拡張するために`PodReadinessGate`フィールドの設定を有効にします。詳細は[Pod readiness gate](/ja/docs/concepts/workloads/pods/pod-lifecycle/#pod-readiness-gate)で確認できます。
- `PodShareProcessNamespace`: Podで実行されているコンテナ間で単一のプロセス名前空間を共有するには、Podで`shareProcessNamespace`の設定を有効にします。 詳細については、[Pod内のコンテナ間でプロセス名前空間を共有する](/docs/tasks/configure-pod-container/share-process-namespace/)をご覧ください。
- `ProcMountType`: コンテナのProcMountTypeの制御を有効にします。
- `PVCProtection`: 永続ボリューム要求（PVC）がPodでまだ使用されているときに削除されないようにします。詳細は[ここ](/docs/tasks/administer-cluster/storage-object-in-use-protection/)で確認できます。
@@ -377,7 +377,7 @@ GAになってからさらなる変更を加えることは現実的ではない
- `ServerSideApply`: APIサーバーで[サーバーサイドApply(SSA)](/docs/reference/using-api/api-concepts/#server-side-apply)のパスを有効にします。
- `ServiceLoadBalancerFinalizer`: サービスロードバランサーのファイナライザー保護を有効にします。
- `ServiceNodeExclusion`: クラウドプロバイダーによって作成されたロードバランサーからのノードの除外を有効にします。"`alpha.service-controller.kubernetes.io/exclude-balancer`"キーまたは`node.kubernetes.io/exclude-from-external-load-balancers`でラベル付けされている場合ノードは除外の対象となります。
- `StartupProbe`: kubeletで[startup](/docs/concepts/workloads/pods/pod-lifecycle/#when-should-you-use-a-startup-probe)プローブを有効にします。
- `StartupProbe`: kubeletで[startup](/ja/docs/concepts/workloads/pods/pod-lifecycle/#when-should-you-use-a-startup-probe)プローブを有効にします。
- `StorageObjectInUseProtection`: PersistentVolumeまたはPersistentVolumeClaimオブジェクトがまだ使用されている場合、それらの削除を延期します。
- `StorageVersionHash`: apiserversがディスカバリーでストレージのバージョンハッシュを公開できるようにします。
- `StreamingProxyRedirects`: ストリーミングリクエストのバックエンド(kubelet)からのリダイレクトをインターセプト（およびフォロー）するようAPIサーバーに指示します。ストリーミングリクエストの例には`exec`、`attach`、`port-forward`リクエストが含まれます。
content/ja/docs/reference/glossary/cluster.md
+4 -3
View File
@@ -5,14 +5,15 @@ date: 2019-06-15
full_link:
short_description: >
Kubernetesが管理するコンテナ化されたアプリケーションを実行する、ノードと呼ばれるマシンの集合です。クラスターには、少なくとも1つのワーカーノードと少なくとも1つのマスターノードがあります。
コンテナ化されたアプリケーションを実行する、ノードと呼ばれるワーカーマシンの集合です。すべてのクラスターには少なくとも1つのワーカーノードがあります。
aka:
tags:
- fundamental
- operation
---
Kubernetesが管理するコンテナ化されたアプリケーションを実行する、ノードと呼ばれるマシンの集合です。クラスターには、少なくとも1つのワーカーノードと少なくとも1つのマスターノードがあります。
コンテナ化されたアプリケーションを実行する、{{< glossary_tooltip text="ノード" term_id="node" >}}と呼ばれるワーカーマシンの集合です。すべてのクラスターには少なくとも1つのワーカーノードがあります。
<!--more-->
ワーカーノードは、アプリケーションのコンポーネントであるPodをホストします。マスターノードは、クラスター内のワーカーノードとPodを管理します。複数のマスターノードを使用して、クラスターにフェイルオーバーと高可用性を提供します。
ワーカーノードは、アプリケーションのコンポーネントであるPodをホストします。マスターノードは、クラスター内のワーカーノードとPodを管理します。複数のマスターノードを使用して、クラスターにフェイルオーバーと高可用性を提供します。
ワーカーノードは、アプリケーションワークロードのコンポーネントである{{< glossary_tooltip text="Pod" term_id="pod" >}}をホストします。{{< glossary_tooltip text="コントロールプレーン" term_id="control-plane" >}}は、クラスター内のワーカーノードとPodを管理します。本番環境では、コントロールプレーンは複数のコンピューターを使用し、クラスターは複数のノードを使用し、耐障害性や高可用性を提供します。
content/ja/docs/reference/glossary/container-runtime.md
+4 -4
View File
@@ -2,7 +2,7 @@
title: コンテナランタイム
id: container-runtime
date: 2019-06-05
full_link: /docs/reference/generated/container-runtime
full_link: /ja/docs/setup/production-environment/container-runtimes
short_description: >
コンテナランタイムは、コンテナの実行を担当するソフトウェアです。
@@ -16,7 +16,7 @@ tags:
<!--more-->
Kubernetesは次の複数のコンテナランタイムをサポートします。
[Docker](http://www.docker.com), [containerd](https://containerd.io), [cri-o](https://cri-o.io/),
[rktlet](https://github.com/kubernetes-incubator/rktlet) および全ての
{{< glossary_tooltip term_id="docker">}}、{{< glossary_tooltip term_id="containerd" >}}、{{< glossary_tooltip term_id="cri-o" >}}、
および全ての
[Kubernetes CRI (Container Runtime Interface)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md)
実装。
実装です。
content/ja/docs/reference/glossary/controller.md
+6 -3
View File
@@ -2,7 +2,7 @@
title: Controller
id: controller
date: 2018-04-12
full_link: /docs/admin/kube-controller-manager/
full_link: /docs/concepts/architecture/controller/
short_description: >
クラスターの状態をAPIサーバーから取得、見張る制御ループで、現在の状態を望ましい状態に移行するように更新します。
@@ -11,8 +11,11 @@ tags:
- architecture
- fundamental
---
クラスターの状態を{{< glossary_tooltip text="apiserver" term_id="kube-apiserver" >}}から取得して監視する制御ループで、現在の状態を望ましい状態に移行するように更新します。
Kubernetesにおいて、コントローラーは{{< glossary_tooltip term_id="cluster" text="クラスター" >}}の状態を監視し、必要に応じて変更を加えたり要求したりする制御ループです。それぞれのコントローラーは現在のクラスターの状態を望ましい状態に近づけるように動作します。
<!--more-->
現在Kubernetesに同梱されているコントローラーの例には、レプリケーションコントローラー、エンドポイントコントローラー、名前空間コントローラー、およびサービスアカウントコントローラーがあります。
コントローラーはクラスターの状態を{{< glossary_tooltip term_id="control-plane" text="コントロールプレーン" >}}の一部である{{< glossary_tooltip text="kube-apiserver" term_id="kube-apiserver" >}}から取得します。
コントロールプレーン内部で動くいくつかのコントローラーは、Kubernetesの主要な操作に対する制御ループを提供します。
例えば、Deploymentコントローラー、Daemonsetコントローラー、Namespaceコントローラー、Persistent Volumeコントローラー等は{{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}}の内部で動作します。
content/ja/docs/reference/glossary/kube-apiserver.md
+10 -6
View File
@@ -1,18 +1,22 @@
---
title: kube-apiserver
title: APIサーバー
id: kube-apiserver
date: 2018-04-12
full_link: /docs/reference/generated/kube-apiserver/
short_description: >
Kubernetes APIを外部に提供する、マスター上のコンポーネントです。これがKubernetesコントロールプレーンのフロントエンドになります。
Kubernetes APIを提供するコントロールプレーンのコンポーネントです。
aka:
aka:
- kube-apiserver
tags:
- architecture
- fundamental
---
Kubernetes APIを外部に提供する、マスター上のコンポーネントです。これがKubernetesコントロールプレーンのフロントエンドになります。
APIサーバーは、Kubernetes APIを外部に提供するKubernetes{{< glossary_tooltip text="コントロールプレーン" term_id="control-plane" >}}のコンポーネントです。
APIサーバーはKubernetesコントロールプレーンのフロントエンドになります。
<!--more-->
<!--more-->
このコンポーネントは、水平スケールするように設計されています。つまり追加でインスタンスを足すことでスケール可能です。さらなる情報は、[高可用性クラスターを構築する](/docs/admin/high-availability/)を確認してください。
Kubernetes APIサーバーの主な実装は[kube-apiserver](/docs/reference/generated/kube-apiserver/)です。
kube-apiserverは水平方向にスケールするように設計されています&mdash;つまり、インスタンスを追加することでスケールが可能です。
複数のkube-apiserverインスタンスを実行することで、インスタンス間でトラフィックを分散させることが可能です。
content/ja/docs/reference/glossary/kube-controller-manager.md
+4 -4
View File
@@ -2,17 +2,17 @@
title: kube-controller-manager
id: kube-controller-manager
date: 2018-04-12
full_link: /docs/reference/generated/kube-controller-manager/
full_link: /docs/reference/command-line-tools-reference/kube-controller-manager/
short_description: >
マスター上に存在し、コントローラーを実行するコンポーネントです。
コントロールプレーン上で動作するコンポーネントで、複数のコントローラープロセスを実行します。
aka:
tags:
- architecture
- fundamental
---
マスター上に存在し、{{< glossary_tooltip text="controllers" term_id="controller" >}}を実行するコンポーネントです。
コントロールプレーン上で動作するコンポーネントで、複数の{{< glossary_tooltip text="コントローラー" term_id="controller" >}}プロセスを実行します。
<!--more-->
論理的には、各{{< glossary_tooltip text="controller" term_id="controller" >}}は個別のプロセスですが、複雑になるのを避けるために一つの実行ファイルにまとめてコンパイルされ、単一のプロセスとして動きます。
論理的には、各{{< glossary_tooltip text="コントローラー" term_id="controller" >}}は個別のプロセスですが、複雑さを減らすために一つの実行ファイルにまとめてコンパイルされ、単一のプロセスとして動きます。
content/ja/docs/reference/glossary/kube-proxy.md
+2 -2
View File
@@ -11,10 +11,10 @@ tags:
- fundamental
- networking
---
[kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) はクラスター内の各Nodeで動作しているネットワークプロキシで、Kubernetesの{{< glossary_tooltip term_id="service">}}コンセプトの一部を実装しています。
kube-proxyはクラスター内の各{{< glossary_tooltip text="node" term_id="node" >}}で動作しているネットワークプロキシで、Kubernetesの{{< glossary_tooltip term_id="service">}}コンセプトの一部を実装しています。
<!--more-->
kube-proxyは、Nodeのネットワークルールをメンテナンスします。これらのネットワークルールにより、クラスターの内部または外部のネットワークセッションからPodへのネットワーク通信が可能になります。
[kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/)は、Nodeのネットワークルールをメンテナンスします。これらのネットワークルールにより、クラスターの内部または外部のネットワークセッションからPodへのネットワーク通信が可能になります。
kube-proxyは、オペレーティングシステムにパケットフィルタリング層があり、かつ使用可能な場合、パケットフィルタリング層を使用します。それ以外の場合は自身でトラフィックを転送します。
content/ja/docs/reference/glossary/kube-scheduler.md
+3 -3
View File
@@ -4,14 +4,14 @@ id: kube-scheduler
date: 2018-04-12
full_link: /docs/reference/generated/kube-scheduler/
short_description: >
マスター上で動作するコンポーネントで、新しく作られたPodにノードが割り当てられているか監視し、割り当てられていなかった場合にそのPodを実行するノードを選択します。
コントロールプレーン上で動作するコンポーネントで、新しく作られたPodにノードが割り当てられているか監視し、割り当てられていなかった場合にそのPodを実行するノードを選択します。
aka:
tags:
- architecture
---
マスター上で動作するコンポーネントで、新しく作られたPodにノードが割り当てられているか監視し、割り当てられていなかった場合にそのPodを実行するノードを選択します。
コントロールプレーン上で動作するコンポーネントで、新しく作られた{{< glossary_tooltip term_id="pod" text="Pod" >}}に{{< glossary_tooltip term_id="node" text="ノード" >}}が割り当てられているか監視し、割り当てられていなかった場合にそのPodを実行するノードを選択します。
<!--more-->
スケジューリング決定で考慮される要素には、個々および集団のリソース要件、ハードウェア/ソフトウェア/ポリシーの制約、アフィニティおよびアンチアフィニティの指定、データの局所性、ワークロード間の干渉と有効期限が含まれます。
スケジューリングの決定は、PodあるいはPod群のリソース要求量、ハードウェア/ソフトウェア/ポリシーによる制約、アフィニティおよびアンチアフィニティの指定、データの局所性、ワークロード間の干渉、有効期限などを考慮して行われます。
content/ja/docs/reference/glossary/kubelet.md
+2 -3
View File
@@ -11,8 +11,7 @@ tags:
- fundamental
- core-object
---
クラスター内の各ノードで実行されるエージェントです。各コンテナがPodで実行されていることを保証します。
クラスター内の各{{< glossary_tooltip text="ノード" term_id="node" >}}で実行されるエージェントです。各{{< glossary_tooltip text="コンテナ" term_id="container" >}}が{{< glossary_tooltip text="Pod" term_id="pod" >}}で実行されていることを保証します。
<!--more-->
kubeletは、さまざまなメカニズムを通じて提供されるPodSpecのセットを取得し、それらのPodSpecに記述されているコンテナが正常に実行されている状態に保ちます。kubeletは、Kubernetesが作成したものではないコンテナは管理しません。
kubeletは、さまざまなメカニズムを通じて提供されるPodSpecのセットを取得し、それらのPodSpecに記述されているコンテナが正常に実行されている状態を保証します。kubeletは、Kubernetesが作成したものではないコンテナは管理しません。
content/ja/docs/reference/glossary/name.md
+3 -3
View File
@@ -2,17 +2,17 @@
title: 名前(Name)
id: name
date: 2018-04-12
full_link: /docs/concepts/overview/working-with-objects/names
full_link: /ja/docs/concepts/overview/working-with-objects/names
short_description: >
クライアントから提供され、リソースURL内のオブジェクトを参照する文字列です。例えば`/api/v1/pods/何らかの名前`のようになります。
aka:
aka:
tags:
- fundamental
---
クライアントから提供され、リソースURL内のオブジェクトを参照する文字列です。例えば`/api/v1/pods/何らかの名前`のようになります。
<!--more-->
<!--more-->
同じ種類のオブジェクトは、同じ名前を同時に持つことは出来ません。しかし、オブジェクトを削除することで、旧オブジェクトと同じ名前で新しいオブジェクトを作成できます。
content/ja/docs/reference/glossary/persistent-volume-claim.md
+2 -3
View File
@@ -11,9 +11,8 @@ tags:
- core-object
- storage
---
コンテナ内でボリュームとしてマウントするためにPersistentVolume内で定義されたストレージリソースを要求します。
{{< glossary_tooltip text="コンテナ" term_id="container" >}}内でボリュームとしてマウントするために{{< glossary_tooltip text="PersistentVolume" term_id="persistent-volume" >}}内で定義されたストレージリソースを要求します。
<!--more-->
ストレージサイズ、ストレージへのアクセス制御（読み取り専用、読み取り/書き込み、排他的）、および再利用方法（保持、リサイクル、削除）を指定します。ストレージ自体の詳細はPersistentVolumeの仕様にあります。
ストレージサイズ、ストレージへのアクセス制御（読み取り専用、読み取り/書き込み、排他的）、および再利用方法（保持、リサイクル、削除）を指定します。ストレージ自体の詳細はPersistentVolumeオブジェクトに記載されています。
content/ja/docs/reference/glossary/selector.md
+2 -2
View File
@@ -10,8 +10,8 @@ aka:
tags:
- fundamental
---
ユーザーはラベルに基づいてリソースのリストをフィルタリングできます。
ユーザーは{{< glossary_tooltip text="ラベル" term_id="label" >}}に基づいてリソースのリストをフィルタリングできます。
<!--more-->
セレクターは、リソースのリストを照会して{{< glossary_tooltip text="ラベル" term_id="label" >}}でフィルターするときに適用されます。
セレクターは、リソースのリストを照会してラベルでフィルターするときに適用されます。
content/ja/docs/reference/glossary/sig.md
+1 -1
View File
@@ -15,7 +15,7 @@ tags:
<!--more-->
SIGのメンバーは、アーキテクチャ、API machinery、ドキュメンテーションといった、特定のエリアの改善に共通の関心をもっています。
SIGは[SIGガバナンス](https://github.com/kubernetes/community/blob/master/sig-governance.md)ガイドラインに準拠していなければなりませんが、独自の貢献ポリシーやコミュニケーションのチャンネルを持つことが可能です。
SIGは[ガバナンスガイドライン](https://github.com/kubernetes/community/blob/master/committee-steering/governance/sig-governance.md)に準拠していなければなりませんが、独自の貢献ポリシーやコミュニケーションのチャンネルを持つことが可能です。
さらなる情報は[コミュニティ (kubernetes/community)](https://github.com/kubernetes/community)リポジトリと[SIGとワーキンググループ](https://github.com/kubernetes/community/blob/master/sig-list.md)を参照して下さい。
content/ja/docs/reference/glossary/volume.md
+5 -3
View File
@@ -4,15 +4,17 @@ id: volume
date: 2018-04-12
full_link: /docs/concepts/storage/volumes/
short_description: >
ポッド内のコンテナからアクセス可能なデータを含むディレクトリ。
Pod内のコンテナからアクセス可能なデータを含むディレクトリ。
aka:
tags:
- core-object
- fundamental
---
{{< glossary_tooltip text="ポッド" term_id="pod" >}}内のコンテナからアクセス可能なデータを含むディレクトリ。
{{< glossary_tooltip text="Pod" term_id="pod" >}}内の{{< glossary_tooltip text="コンテナ" term_id="container" >}}からアクセス可能なデータを含むディレクトリ。
<!--more-->
Kubernetesボリュームはボリュームを含む{{< glossary_tooltip text="ポッド" term_id="pod" >}}が存在する限り有効です。そのためボリュームは{{< glossary_tooltip text="ポッド" term_id="pod" >}}内で実行されるすべての{{< glossary_tooltip text="コンテナ" term_id="container" >}}よりも長持ちし、{{< glossary_tooltip text="コンテナ" term_id="container" >}}の再起動後もデータは保持されます。
Kubernetesボリュームはボリュームを含むPodが存在する限り有効です。そのためボリュームはPod内で実行されるすべてのコンテナよりも長持ちし、コンテナの再起動後もデータは保持されます。
詳しくは[ストレージ](https://kubernetes.io/docs/concepts/storage/)をご覧下さい。
content/ja/docs/reference/kubectl/cheatsheet.md
+15 -8
View File
@@ -38,7 +38,7 @@ complete -F __start_kubectl k
```bash
source <(kubectl completion zsh) # 現在のzshシェルでコマンド補完を設定します
echo "if [ $commands[kubectl] ]; then source <(kubectl completion zsh); fi" >> ~/.zshrc # zshシェルでのコマンド補完を永続化するために.zshrcに追記します。
echo "[[ $commands[kubectl] ]] && source <(kubectl completion zsh)" >> ~/.zshrc # zshシェルでのコマンド補完を永続化するために.zshrcに追記します。
```
## Kubectlコンテキストの設定
@@ -84,7 +84,7 @@ kubectl config unset users.foo # ユーザーfooを削除します
## Objectの作成
Kubernetesのマニフェストファイルは、jsonまたはyamlで定義できます。ファイル拡張子として、`.yaml`や`.yml`、`.json`が使えます。
Kubernetesのマニフェストファイルは、JSONまたはYAMLで定義できます。ファイル拡張子として、`.yaml`や`.yml`、`.json`が使えます。
```bash
kubectl apply -f ./my-manifest.yaml # リソースを作成します
@@ -92,7 +92,7 @@ kubectl apply -f ./my1.yaml -f ./my2.yaml # 複数のファイルからリ
kubectl apply -f ./dir # dirディレクトリ内のすべてのマニフェストファイルからリソースを作成します
kubectl apply -f https://git.io/vPieo # urlで公開されているファイルからリソースを作成します
kubectl create deployment nginx --image=nginx # 単一のnginx Deploymentを作成します
kubectl explain pods,svc # PodおよびServiceマニフェストのドキュメントを取得します
kubectl explain pods # Podマニフェストのドキュメントを取得します
# 標準入力から複数のYAMLオブジェクトを作成します
@@ -147,7 +147,6 @@ kubectl get pods -o wide # 現在のネームスペース
kubectl get deployment my-dep # 特定のDeploymentを表示します
kubectl get pods # 現在のネームスペース上にあるすべてのPodのリストを表示します
kubectl get pod my-pod -o yaml # PodのYAMLを表示します
kubectl get pod my-pod -o yaml --export # クラスター固有の情報を除いたPodのマニフェストをYAMLで表示します
# Describeコマンドで詳細な情報を確認します
kubectl describe nodes my-node
@@ -159,8 +158,8 @@ kubectl get services --sort-by=.metadata.name
# Restartカウント順にPodのリストを表示します
kubectl get pods --sort-by='.status.containerStatuses[0].restartCount'
# capacity順にソートしたtestネームスペースに存在するPodのリストを表示します
kubectl get pods -n test --sort-by=.spec.capacity.storage
# capacity順にソートしたPersistentVolumeのリストを表示します
kubectl get pv --sort-by=.spec.capacity.storage
# app=cassandraラベルのついたすべてのPodのversionラベルを表示します
kubectl get pods --selector=app=cassandra -o \
@@ -195,9 +194,16 @@ JSONPATH='{range .items[*]}{@.metadata.name}:{range @.status.conditions[*]}{@.ty
kubectl get pods -o json | jq '.items[].spec.containers[].env[]?.valueFrom.secretKeyRef.name' | grep -v null | sort | uniq
# すべてのPodのInitContainerのコンテナIDのリストを表示します
# initContainerの削除を回避しながら、停止したコンテナを削除するときに役立つでしょう
kubectl get pods --all-namespaces -o jsonpath='{range .items[*].status.initContainerStatuses[*]}{.containerID}{"\n"}{end}' | cut -d/ -f3
# タイムスタンプでソートされたEventのリストを表示します
kubectl get events --sort-by=.metadata.creationTimestamp
# クラスターの現在の状態を、マニフェストが適用された場合のクラスターの状態と比較します。
kubectl diff -f ./my-manifest.yaml
```
## リソースのアップデート
@@ -210,6 +216,7 @@ kubectl rollout history deployment/frontend # frontend Depl
kubectl rollout undo deployment/frontend # 1つ前のDeploymentにロールバックします
kubectl rollout undo deployment/frontend --to-revision=2 # 特定のバージョンにロールバックします
kubectl rollout status -w deployment/frontend # frontend Deploymentのローリングアップデートを状態をwatchします
kubectl rollout restart deployment/frontend # frontend Deployment を再起動します
# これらのコマンドは1.11から廃止されました
@@ -322,7 +329,7 @@ kubectl taint nodes foo dedicated=special-user:NoSchedule
### リソースタイプ
サポートされているすべてのリソースタイプを、それらが[API group](/docs/concepts/overview/kubernetes-api/#api-groups)か[Namespaced](/docs/concepts/overview/working-with-objects/namespaces)、[Kind](/docs/concepts/overview/working-with-objects/kubernetes-objects)に関わらずその短縮名をリストします。
サポートされているすべてのリソースタイプを、それらが[API group](/ja/docs/concepts/overview/kubernetes-api/#api-groups)か[Namespaced](/docs/concepts/overview/working-with-objects/namespaces)、[Kind](/docs/concepts/overview/working-with-objects/kubernetes-objects)に関わらずその短縮名をリストします。
```bash
kubectl api-resources
@@ -341,7 +348,7 @@ kubectl api-resources --api-group=extensions # "extensions" APIグループの
### 出力のフォーマット
特定の形式で端末ウィンドウに詳細を出力するには、サポートされている`kubectl`コマンドに`-o`または`--output`フラグを追加します。
特定の形式で端末ウィンドウに詳細を出力するには、サポートされている`kubectl`コマンドに`-o`(または`--output`)フラグを追加します。
出力フォーマット | 説明
---------------- | -----------
content/ja/docs/setup/_index.md
+2 -61
View File
@@ -37,77 +37,18 @@ Kubernetesについて学んでいる場合、Dockerベースのソリューシ
|コミュニティ |エコシステム |
| ------------ | -------- |
| [Minikube](/ja/docs/setup/learning-environment/minikube/) | [CDK on LXD](https://www.ubuntu.com/kubernetes/docs/install-local) |
| [kind (Kubernetes IN Docker)](https://github.com/kubernetes-sigs/kind) | [Docker Desktop](https://www.docker.com/products/docker-desktop)|
| [kind (Kubernetes IN Docker)](/docs/setup/learning-environment/kind/) | [Docker Desktop](https://www.docker.com/products/docker-desktop)|
| | [Minishift](https://docs.okd.io/latest/minishift/)|
| | [MicroK8s](https://microk8s.io/)|
| | [IBM Cloud Private-CE (Community Edition)](https://github.com/IBM/deploy-ibm-cloud-private) |
| | [IBM Cloud Private-CE (Community Edition) on Linux Containers](https://github.com/HSBawa/icp-ce-on-linux-containers)|
| | [k3s](https://k3s.io)|
| | [Ubuntu on LXD](/docs/getting-started-guides/ubuntu/)|
## 本番環境
本番環境用のソリューションを評価する際には、Kubernetesクラスター(または抽象レイヤ)の運用においてどの部分を自分で管理し、どの部分をプロバイダーに任せるのかを考慮してください。
Kubernetesクラスタにおける抽象レイヤには {{< glossary_tooltip text="アプリケーション" term_id="applications" >}}、 {{< glossary_tooltip text="データプレーン" term_id="data-plane" >}}、 {{< glossary_tooltip text="コントロールプレーン" term_id="control-plane" >}}、 {{< glossary_tooltip text="クラスターインフラ" term_id="cluster-infrastructure" >}}、 {{< glossary_tooltip text="そして、クラスター運用" term_id="cluster-operations" >}}があります。
次の図は、Kubernetesクラスターの抽象レイヤ一覧と、それぞれの抽象レイヤを自分で管理するのか、プロバイダによって管理されているのかを示しています。
本番環境のソリューション![Production environment solutions](/images/docs/KubernetesSolutions.svg)
{{< table caption="Production environment solutions table lists the providers and the solutions." >}}
次の表は、各プロバイダーとそれらが提供するソリューションを一覧にしたものです。
|プロバイダー | マネージド | 即時利用可能 | オンプレDC | カスタム(クラウド) | カスタム(オンプレVM)| カスタム(ベアメタル) |
| --------- | ------ | ------ | ------ | ------ | ------ | ----- |
| [Agile Stacks](https://www.agilestacks.com/products/kubernetes)| | &#x2714; | &#x2714; | | |
| [Alibaba Cloud](https://www.alibabacloud.com/product/kubernetes)| | &#x2714; | | | |
| [Amazon](https://aws.amazon.com) | [Amazon EKS](https://aws.amazon.com/eks/) |[Amazon EC2](https://aws.amazon.com/ec2/) | | | |
| [AppsCode](https://appscode.com/products/pharmer/) | &#x2714; | | | | |
| [APPUiO](https://appuio.ch/)  | &#x2714; | &#x2714; | &#x2714; | | | |
| [Banzai Cloud Pipeline Kubernetes Engine (PKE)](https://banzaicloud.com/products/pke/) | | &#x2714; | | &#x2714; | &#x2714; | &#x2714; |
| [CenturyLink Cloud](https://www.ctl.io/) | | &#x2714; | | | |
| [Cisco Container Platform](https://cisco.com/go/containers) | | | &#x2714; | | |
| [Cloud Foundry Container Runtime (CFCR)](https://docs-cfcr.cfapps.io/) | | | | &#x2714; |&#x2714; |
| [CloudStack](https://cloudstack.apache.org/) | | | | | &#x2714;|
| [Canonical](https://ubuntu.com/kubernetes) | &#x2714; | &#x2714; | &#x2714; | &#x2714; |&#x2714; | &#x2714;
| [Containership](https://containership.io) | &#x2714; |&#x2714; | | | |
| [D2iQ](https://d2iq.com/) | | [Kommander](https://d2iq.com/solutions/ksphere) | [Konvoy](https://d2iq.com/solutions/ksphere/konvoy) | [Konvoy](https://d2iq.com/solutions/ksphere/konvoy) | [Konvoy](https://d2iq.com/solutions/ksphere/konvoy) | [Konvoy](https://d2iq.com/solutions/ksphere/konvoy) |
| [Digital Rebar](https://provision.readthedocs.io/en/tip/README.html) | | | | | | &#x2714;
| [DigitalOcean](https://www.digitalocean.com/products/kubernetes/) | &#x2714; | | | | |
| [Docker Enterprise](https://www.docker.com/products/docker-enterprise) | |&#x2714; | &#x2714; | | | &#x2714;
| [Fedora (Multi Node)](https://kubernetes.io/docs/getting-started-guides/fedora/flannel_multi_node_cluster/)  | | | | | &#x2714; | &#x2714;
| [Fedora (Single Node)](https://kubernetes.io/docs/getting-started-guides/fedora/fedora_manual_config/)  | | | | | | &#x2714;
| [Gardener](https://gardener.cloud/) | &#x2714; | &#x2714; | &#x2714; | &#x2714; | &#x2714; | [Custom Extensions](https://github.com/gardener/gardener/blob/master/docs/extensions/overview.md) |
| [Giant Swarm](https://www.giantswarm.io/) | &#x2714; | &#x2714; | &#x2714; | |
| [Google](https://cloud.google.com/) | [Google Kubernetes Engine (GKE)](https://cloud.google.com/kubernetes-engine/) | [Google Compute Engine (GCE)](https://cloud.google.com/compute/)|[GKE On-Prem](https://cloud.google.com/gke-on-prem/) | | | | | | | |
| [IBM](https://www.ibm.com/in-en/cloud) | [IBM Cloud Kubernetes Service](https://cloud.ibm.com/kubernetes/catalog/cluster)| |[IBM Cloud Private](https://www.ibm.com/in-en/cloud/private) | |
| [Ionos](https://www.ionos.com/enterprise-cloud) | [Ionos Managed Kubernetes](https://www.ionos.com/enterprise-cloud/managed-kubernetes) | [Ionos Enterprise Cloud](https://www.ionos.com/enterprise-cloud) | |
| [Kontena Pharos](https://www.kontena.io/pharos/) | |&#x2714;| &#x2714; | | |
| [KubeOne](https://kubeone.io/) | | &#x2714; | &#x2714; | &#x2714; | &#x2714; | &#x2714; |
| [Kubermatic](https://kubermatic.io/) | &#x2714; | &#x2714; | &#x2714; | &#x2714; | &#x2714; | |
| [KubeSail](https://kubesail.com/) | &#x2714; | | | | |
| [Kubespray](https://kubespray.io/#/) | | | |&#x2714; | &#x2714; | &#x2714; |
| [Kublr](https://kublr.com/) |&#x2714; | &#x2714; |&#x2714; |&#x2714; |&#x2714; |&#x2714; |
| [Microsoft Azure](https://azure.microsoft.com) | [Azure Kubernetes Service (AKS)](https://azure.microsoft.com/en-us/services/kubernetes-service/) | | | | |
| [Mirantis Cloud Platform](https://www.mirantis.com/software/kubernetes/) | | | &#x2714; | | |
| [Nirmata](https://www.nirmata.com/) | | &#x2714; | &#x2714; | | |
| [Nutanix](https://www.nutanix.com/en) | [Nutanix Karbon](https://www.nutanix.com/products/karbon) | [Nutanix Karbon](https://www.nutanix.com/products/karbon) | | | [Nutanix AHV](https://www.nutanix.com/products/acropolis/virtualization) |
| [OpenNebula](https://www.opennebula.org) |[OpenNebula Kubernetes](https://marketplace.opennebula.systems/docs/service/kubernetes.html) | | | | |
| [OpenShift](https://www.openshift.com) |[OpenShift Dedicated](https://www.openshift.com/products/dedicated/) and [OpenShift Online](https://www.openshift.com/products/online/) | | [OpenShift Container Platform](https://www.openshift.com/products/container-platform/) | | [OpenShift Container Platform](https://www.openshift.com/products/container-platform/) |[OpenShift Container Platform](https://www.openshift.com/products/container-platform/)
| [Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE)](https://docs.cloud.oracle.com/iaas/Content/ContEng/Concepts/contengoverview.htm) | &#x2714; | &#x2714; | | | |
| [oVirt](https://www.ovirt.org/) | | | | | &#x2714; |
| [Pivotal](https://pivotal.io/) | | [Enterprise Pivotal Container Service (PKS)](https://pivotal.io/platform/pivotal-container-service) | [Enterprise Pivotal Container Service (PKS)](https://pivotal.io/platform/pivotal-container-service) | | |
| [Platform9](https://platform9.com/) | [Platform9 Managed Kubernetes](https://platform9.com/managed-kubernetes/) | | [Platform9 Managed Kubernetes](https://platform9.com/managed-kubernetes/) | &#x2714; | &#x2714; | &#x2714;
| [Rancher](https://rancher.com/) | | [Rancher 2.x](https://rancher.com/docs/rancher/v2.x/en/) | | [Rancher Kubernetes Engine (RKE)](https://rancher.com/docs/rke/latest/en/) | | [k3s](https://k3s.io/)
| [StackPoint](https://stackpoint.io/)  | &#x2714; | &#x2714; | | | |
| [Supergiant](https://supergiant.io/) | |&#x2714; | | | |
| [SUSE](https://www.suse.com/) | | &#x2714; | | | |
| [SysEleven](https://www.syseleven.io/) | &#x2714; | | | | |
| [Tencent Cloud](https://intl.cloud.tencent.com/) | [Tencent Kubernetes Engine](https://intl.cloud.tencent.com/product/tke) | &#x2714; | &#x2714; | | | &#x2714; |
| [VEXXHOST](https://vexxhost.com/) | &#x2714; | &#x2714; | | | |
| [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; | | | | | |
[Certified Kubernetes](https://github.com/cncf/k8s-conformance/#certified-kubernetes)プロバイダーの一覧については、"[Partners](https://kubernetes.io/partners/#conformance)"を参照してください。
content/ja/docs/setup/best-practices/multiple-zones.md
+1 -1
View File
@@ -184,7 +184,7 @@ kubernetes-minion-wf8i Ready <none> 2m v1.13.0
Create a volume using the dynamic volume creation (only PersistentVolumes are supported for zone affinity):
```json
```bash
kubectl apply -f - <<EOF
{
"apiVersion": "v1",
content/ja/docs/setup/best-practices/node-conformance.md
+1 -1
View File
@@ -82,7 +82,7 @@ sudo docker run -it --rm --privileged --net=host \
k8s.gcr.io/node-test:0.2
```
Node conformance test is a containerized version of [node e2e test](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/devel/e2e-node-tests.md).
Node conformance test is a containerized version of [node e2e test](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/e2e-node-tests.md).
By default, it runs all conformance tests.
Theoretically, you can run any node e2e test if you configure the container and
content/ja/docs/setup/learning-environment/minikube.md
+1 -1
View File
@@ -317,7 +317,7 @@ Minikubeはこのコンテキストを自動的にデフォルトに設定しま
### ダッシュボード
[Kubernetes Dashboard](/docs/tasks/access-application-cluster/web-ui-dashboard/)にアクセスするには、Minikubeを起動してアドレスを取得した後、シェルでこのコマンドを実行してください:
[Kubernetes Dashboard](/ja/docs/tasks/access-application-cluster/web-ui-dashboard/)にアクセスするには、Minikubeを起動してアドレスを取得した後、シェルでこのコマンドを実行してください:
```shell
minikube dashboard
content/ja/docs/setup/production-environment/tools/kubeadm/ha-topology.md
+22 -33
View File
@@ -1,70 +1,59 @@
---
title: Options for Highly Available topology
title: 高可用性トポロジーのためのオプション
content_type: concept
weight: 50
---
<!-- overview -->
This page explains the two options for configuring the topology of your highly available (HA) Kubernetes clusters.
このページでは、高可用性(HA)Kubernetesクラスターのトポロジーを設定するための2つのオプションについて説明します。
You can set up an HA cluster:
HAクラスターは次の方法で設定できます。
- With stacked control plane nodes, where etcd nodes are colocated with control plane nodes
- With external etcd nodes, where etcd runs on separate nodes from the control plane
- 積層コントロールプレーンノードを使用する方法。こちらの場合、etcdノードはコントロールプレーンノードと同じ場所で動作します。
- 外部のetcdノードを使用する方法。こちらの場合、etcdがコントロールプレーンとは分離されたノードで動作します。
You should carefully consider the advantages and disadvantages of each topology before setting up an HA cluster.
HAクラスターをセットアップする前に、各トポロジーの利点と欠点について注意深く考慮する必要があります。
<!-- body -->
## Stacked etcd topology
## 積層etcdトポロジー
A stacked HA cluster is a [topology](https://en.wikipedia.org/wiki/Network_topology) where the distributed
data storage cluster provided by etcd is stacked on top of the cluster formed by the nodes managed by
kubeadm that run control plane components.
積層HAクラスターは、コントロールプレーンのコンポーネントを実行する、kubeadmで管理されたノードで構成されるクラスターの上に、etcdにより提供される分散データストレージクラスターがあるような[トポロジー](https://en.wikipedia.org/wiki/Network_topology)です。
Each control plane node runs an instance of the `kube-apiserver`, `kube-scheduler`, and `kube-controller-manager`.
The `kube-apiserver` is exposed to worker nodes using a load balancer.
各コントロールプレーンノードは、`kube-apiserver`、`kube-scheduler`、および`kube-controller-manager`を実行します。`kube-apiserver` はロードバランサーを用いてワーカーノードに公開されます。
Each control plane node creates a local etcd member and this etcd member communicates only with
the `kube-apiserver` of this node. The same applies to the local `kube-controller-manager`
and `kube-scheduler` instances.
各コントロールプレーンノードはローカルのetcdメンバーを作り、このetcdメンバーはそのノードの`kube-apiserver`とだけ通信します。ローカルの`kube-controller-manager`と`kube-scheduler`のインスタンスも同様です。
This topology couples the control planes and etcd members on the same nodes. It is simpler to set up than a cluster
with external etcd nodes, and simpler to manage for replication.
このトポロジーは、同じノード上のコントロールプレーンとetcdのメンバーを結合します。外部のetcdノードを使用するクラスターよりはセットアップがシンプルで、レプリケーションの管理もシンプルです。
However, a stacked cluster runs the risk of failed coupling. If one node goes down, both an etcd member and a control
plane instance are lost, and redundancy is compromised. You can mitigate this risk by adding more control plane nodes.
しかし、積層クラスターには、結合による故障のリスクがあります。1つのノードがダウンすると、etcdメンバーとコントロールプレーンのインスタンスの両方が失われ、冗長性が損なわれます。より多くのコントロールプレーンノードを追加することで、このリスクは緩和できます。
You should therefore run a minimum of three stacked control plane nodes for an HA cluster.
そのため、HAクラスターのためには、最低でも3台の積層コントロールプレーンノードを実行しなければなりません。
This is the default topology in kubeadm. A local etcd member is created automatically
on control plane nodes when using `kubeadm init` and `kubeadm join --control-plane`.
これがkubeadmのデフォルトのトポロジーです。`kubeadm init`や`kubeadm join --control-place`を実行すると、ローカルのetcdメンバーがコントロールプレーンノード上に自動的に作成されます。
![Stacked etcd topology](/images/kubeadm/kubeadm-ha-topology-stacked-etcd.svg)
![積層etcdトポロジー](/images/kubeadm/kubeadm-ha-topology-stacked-etcd.svg)
## External etcd topology
## 外部のetcdトポロジー
An HA cluster with external etcd is a [topology](https://en.wikipedia.org/wiki/Network_topology) where the distributed data storage cluster provided by etcd is external to the cluster formed by the nodes that run control plane components.
外部のetcdを持つHAクラスターは、コントロールプレーンコンポーネントを実行するノードで構成されるクラスターの外部に、etcdにより提供される分散データストレージクラスターがあるような[トポロジー](https://en.wikipedia.org/wiki/Network_topology)です。
Like the stacked etcd topology, each control plane node in an external etcd topology runs an instance of the `kube-apiserver`, `kube-scheduler`, and `kube-controller-manager`. And the `kube-apiserver` is exposed to worker nodes using a load balancer. However, etcd members run on separate hosts, and each etcd host communicates with the `kube-apiserver` of each control plane node.
積層etcdトポロジーと同様に、外部のetcdトポロジーにおける各コントロールプレーンノードは、`kube-apiserver`、`kube-scheduler`、および`kube-controller-manager`のインスタンスを実行します。そして、`kube-apiserver`は、ロードバランサーを使用してワーカーノードに公開されます。しかし、etcdメンバーは異なるホスト上で動作しており、各etcdホストは各コントロールプレーンノードの`kube-api-server`と通信します。
This topology decouples the control plane and etcd member. It therefore provides an HA setup where
losing a control plane instance or an etcd member has less impact and does not affect
the cluster redundancy as much as the stacked HA topology.
このトポロジーは、コントロールプレーンとetcdメンバーを疎結合にします。そのため、コントロールプレーンインスタンスまたはetcdメンバーを失うことによる影響は少なく、積層HAトポロジーほどクラスターの冗長性に影響しないHAセットアップが実現します。
However, this topology requires twice the number of hosts as the stacked HA topology.
A minimum of three hosts for control plane nodes and three hosts for etcd nodes are required for an HA cluster with this topology.
しかし、このトポロジーでは積層HAトポロジーの2倍の数のホストを必要とします。このトポロジーのHAクラスターのためには、最低でもコントロールプレーンのために3台のホストが、etcdノードのために3台のホストがそれぞれ必要です。
![External etcd topology](/images/kubeadm/kubeadm-ha-topology-external-etcd.svg)
![外部のetcdトポロジー](/images/kubeadm/kubeadm-ha-topology-external-etcd.svg)
## {{% heading "whatsnext" %}}
- [Set up a highly available cluster with kubeadm](/ja/docs/setup/production-environment/tools/kubeadm/high-availability/)
- [kubeadmを使用した高可用性クラスターの作成](/ja/docs/setup/production-environment/tools/kubeadm/high-availability/)
content/ja/docs/setup/production-environment/turnkey/aws.md
+1 -1
View File
@@ -53,7 +53,7 @@ export PATH=<path/to/kubernetes-directory>/platforms/linux/amd64:$PATH
### 例
新しいクラスターを試すには、[簡単なnginxの例](/docs/tasks/run-application/run-stateless-application-deployment/)を参照してください。
新しいクラスターを試すには、[簡単なnginxの例](/ja/docs/tasks/run-application/run-stateless-application-deployment/)を参照してください。
"Guestbook"アプリケーションは、Kubernetesを始めるもう一つのポピュラーな例です: [guestbookの例](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/)
content/ja/docs/setup/production-environment/windows/user-guide-windows-containers.md
+1 -1
View File
@@ -93,7 +93,7 @@ Port mapping is also supported, but for simplicity in this example the container
* Node-to-pod communication across the network, `curl` port 80 of your pod IPs from the Linux master to check for a web server response
* Pod-to-pod communication, ping between pods (and across hosts, if you have more than one Windows node) using docker exec or kubectl exec
* Service-to-pod communication, `curl` the virtual service IP (seen under `kubectl get services`) from the Linux master and from individual pods
* Service discovery, `curl` the service name with the Kubernetes [default DNS suffix](/docs/concepts/services-networking/dns-pod-service/#services)
* Service discovery, `curl` the service name with the Kubernetes [default DNS suffix](/ja/docs/concepts/services-networking/dns-pod-service/#services)
* Inbound connectivity, `curl` the NodePort from the Linux master or machines outside of the cluster
* Outbound connectivity, `curl` external IPs from inside the pod using kubectl exec
content/ja/docs/setup/release/version-skew-policy.md
+2 -2
View File
@@ -16,9 +16,9 @@ Kubernetesのバージョンは**x.y.z**の形式で表現され、**x**はメ
Kubernetesプロジェクトでは、最新の3つのマイナーリリースについてリリースブランチを管理しています。
セキュリティフィックスを含む適用可能な修正は、重大度や実行可能性によってはこれら3つのリリースブランチにバックポートされることもあります。パッチリリースは、定期的または必要に応じてこれらのブランチから分岐されます。[パッチリリースマネージャー](https://github.com/kubernetes/sig-release/blob/master/release-team/role-handbooks/patch-release-manager/README.md#release-timing)がこれを決定しています。パッチリリースマネージャーは[各リリースのリリースチーム](https://github.com/kubernetes/sig-release/tree/master/releases/)のメンバーです。
セキュリティフィックスを含む適用可能な修正は、重大度や実行可能性によってはこれら3つのリリースブランチにバックポートされることもあります。パッチリリースは、[定期的](https://git.k8s.io/sig-release/releases/patch-releases.md#cadence)または必要に応じてこれらのブランチから分岐されます。[リリースマネージャー](https://git.k8s.io/sig-release/release-managers.md)グループがこれを決定しています。
マイナーリリースは約3ヶ月ごとに行われるため、それぞれのリリースブランチは約9ヶ月間メンテナンスされます。
詳細は、Kubernetes[パッチリリース](https://git.k8s.io/sig-release/releases/patch-releases.md)ページを参照してください。
## サポートされるバージョンの差異
content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md
+20 -18
View File
@@ -10,7 +10,7 @@ card:
<!-- overview -->
ここでは、設定ファイルを使って複数のクラスターにアクセスする方法を紹介します。クラスター、ユーザー、contextの情報を一つ以上の設定ファイルにまとめることで、`kubectl config use-context`のコマンドを使ってクラスターを素早く切り替えることができます。
ここでは、設定ファイルを使って複数のクラスターにアクセスする方法を紹介します。クラスター、ユーザー、コンテキストの情報を一つ以上の設定ファイルにまとめることで、`kubectl config use-context`のコマンドを使ってクラスターを素早く切り替えることができます。
{{< note >}}
クラスターへのアクセスを設定するファイルを、*kubeconfig* ファイルと呼ぶことがあります。これは設定ファイルの一般的な呼び方です。`kubeconfig`という名前のファイルが存在するわけではありません。
@@ -27,7 +27,7 @@ card:
<!-- steps -->
## クラスター、ユーザー、contextを設定する
## クラスター、ユーザー、コンテキストを設定する
例として、開発用のクラスターが一つ、実験用のクラスターが一つ、計二つのクラスターが存在する場合を考えます。`development`と呼ばれる開発用のクラスター内では、フロントエンドの開発者は`frontend`というnamespace内で、ストレージの開発者は`storage`というnamespace内で作業をします。`scratch`と呼ばれる実験用のクラスター内では、開発者はデフォルトのnamespaceで作業をするか、状況に応じて追加のnamespaceを作成します。開発用のクラスターは証明書を通しての認証を必要とします。実験用のクラスターはユーザーネームとパスワードを通しての認証を必要とします。
@@ -57,7 +57,7 @@ contexts:
name: exp-scratch
```
設定ファイルには、クラスター、ユーザー、contextの情報が含まれています。上記の`config-demo`設定ファイルには、二つのクラスター、二人のユーザー、三つのcontextの情報が含まれています。
設定ファイルには、クラスター、ユーザー、コンテキストの情報が含まれています。上記の`config-demo`設定ファイルには、二つのクラスター、二人のユーザー、三つのコンテキストの情報が含まれています。
`config-exercise`ディレクトリに移動してください。クラスター情報を設定ファイルに追加するために、以下のコマンドを実行してください:
@@ -74,10 +74,12 @@ kubectl config --kubeconfig=config-demo set-credentials experimenter --username=
```
{{< note >}}
`kubectl config unset users.<name>`を実行すると、ユーザーを削除することができます。
`kubectl --kubeconfig=config-demo config unset users.<name>`を実行すると、ユーザーを削除することができます。
`kubectl --kubeconfig=config-demo config unset clusters.<name>`を実行すると、クラスターを除去することができます。
`kubectl --kubeconfig=config-demo config unset contexts.<name>`を実行すると、コンテキスト情報を除去することができます。
{{< /note >}}
context情報を設定ファイルに追加してください:
コンテキスト情報を設定ファイルに追加してください:
```shell
kubectl config --kubeconfig=config-demo set-context dev-frontend --cluster=development --namespace=frontend --user=developer
@@ -91,7 +93,7 @@ kubectl config --kubeconfig=config-demo set-context exp-scratch --cluster=scratc
kubectl config --kubeconfig=config-demo view
```
出力には、二つのクラスター、二人のユーザー、三つのcontextが表示されます:
出力には、二つのクラスター、二人のユーザー、三つのコンテキストが表示されます:
```shell
apiVersion: v1
@@ -138,23 +140,23 @@ users:
証明書ファイルのパスの代わりにbase64にエンコードされたデータを使用したい場合は、キーに`-data`の接尾辞を加えてください。例えば、`certificate-authority-data`、`client-certificate-data`、`client-key-data`とできます。
それぞれのcontextは、クラスター、ユーザー、namespaceの三つ組からなっています。例えば、`dev-frontend`contextは、`developer`ユーザーの認証情報を使って`development`クラスターの`frontend`namespaceへのアクセスを意味しています。
それぞれのコンテキストは、クラスター、ユーザー、namespaceの三つ組からなっています。例えば、`dev-frontend`は、`developer`ユーザーの認証情報を使って`development`クラスターの`frontend`namespaceへのアクセスを意味しています。
現在のcontextを設定してください:
現在のコンテキストを設定してください:
```shell
kubectl config --kubeconfig=config-demo use-context dev-frontend
```
これ以降実行される`kubectl`コマンドは、`dev-frontend`contextに設定されたクラスターとnamespaceに適用されます。また、`dev-frontend`contextに設定されたユーザーの認証情報を使用します。
これ以降実行される`kubectl`コマンドは、`dev-frontend`に設定されたクラスターとnamespaceに適用されます。また、`dev-frontend`に設定されたユーザーの認証情報を使用します。
現在のcontextの設定情報のみを確認するには、`--minify`フラグを使用してください。
現在のコンテキストの設定情報のみを確認するには、`--minify`フラグを使用してください。
```shell
kubectl config --kubeconfig=config-demo view --minify
```
出力には、`dev-frontend`contextの設定情報が表示されます:
出力には、`dev-frontend`の設定情報が表示されます:
```shell
apiVersion: v1
@@ -181,15 +183,15 @@ users:
今度は、実験用のクラスター内でしばらく作業する場合を考えます。
現在のcontextを`exp-scratch`に切り替えてください:
現在のコンテキストを`exp-scratch`に切り替えてください:
```shell
kubectl config --kubeconfig=config-demo use-context exp-scratch
```
これ以降実行される`kubectl`コマンドは、`scratch`クラスター内のデフォルトnamespaceに適用されます。また、`exp-scratch`contextに設定されたユーザーの認証情報を使用します。
これ以降実行される`kubectl`コマンドは、`scratch`クラスター内のデフォルトnamespaceに適用されます。また、`exp-scratch`に設定されたユーザーの認証情報を使用します。
新しく切り替えた`exp-scratch`contextの設定を確認してください。
新しく切り替えた`exp-scratch`の設定を確認してください。
```shell
kubectl config --kubeconfig=config-demo view --minify
@@ -197,13 +199,13 @@ kubectl config --kubeconfig=config-demo view --minify
最後に、`development`クラスター内の`storage`namespaceでしばらく作業する場合を考えます。
現在のcontextを`dev-storage`に切り替えてください:
現在のコンテキストを`dev-storage`に切り替えてください:
```shell
kubectl config --kubeconfig=config-demo use-context dev-storage
```
新しく切り替えた`dev-storage`contextの設定を確認してください。
新しく切り替えた`dev-storage`の設定を確認してください。
```shell
kubectl config --kubeconfig=config-demo view --minify
@@ -226,7 +228,7 @@ contexts:
name: dev-ramp-up
```
上記の設定ファイルは、`dev-ramp-up`というcontextを表します。
上記の設定ファイルは、`dev-ramp-up`というコンテキストを表します。
## KUBECONFIG環境変数を設定する
@@ -260,7 +262,7 @@ $Env:KUBECONFIG=("config-demo;config-demo-2")
kubectl config view
```
出力には、`KUBECONFIG`環境変数に含まれる全てのファイルの情報がまとめて表示されます。`config-demo-2`ファイルに設定された`dev-ramp-up`contextの情報と、`config-demo`ファイルに設定された三つのcontextの情報がまとめてあることに注目してください:
出力には、`KUBECONFIG`環境変数に含まれる全てのファイルの情報がまとめて表示されます。`config-demo-2`ファイルに設定された`dev-ramp-up`の情報と、`config-demo`に設定された三つのコンテキストの情報がまとめてあることに注目してください:
```shell
contexts:
content/ja/docs/tasks/access-application-cluster/connecting-frontend-backend.md
+5 -5
View File
@@ -36,7 +36,7 @@ weight: 70
<!-- lessoncontent -->
### Deploymentを使用したバックエンドの作成
## Deploymentを使用したバックエンドの作成
バックエンドは、単純な挨拶マイクロサービスです。
バックエンドのDeploymentの構成ファイルは次のとおりです:
@@ -92,7 +92,7 @@ Events:
...
```
### バックエンドServiceオブジェクトの作成
## バックエンドServiceオブジェクトの作成
フロントエンドをバックエンドに接続する鍵は、バックエンドServiceです。
Serviceは、バックエンドマイクロサービスに常に到達できるように、永続的なIPアドレスとDNS名のエントリを作成します。
@@ -112,7 +112,7 @@ kubectl apply -f https://k8s.io/examples/service/access/hello-service.yaml
この時点で、バックエンドのDeploymentが実行され、そちらにトラフィックをルーティングできるServiceがあります。
### フロントエンドの作成
## フロントエンドの作成
バックエンドができたので、バックエンドに接続するフロントエンドを作成できます。
フロントエンドは、バックエンドServiceに指定されたDNS名を使用して、バックエンドワーカーPodに接続します。
@@ -146,7 +146,7 @@ nginxの構成は、[コンテナイメージ](/examples/service/access/Dockerfi
これを行うためのより良い方法は、[ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/)を使用して、構成をより簡単に変更できるようにすることです。
{{< /note >}}
### フロントエンドServiceと対話
## フロントエンドServiceと対話
LoadBalancerタイプのServiceを作成したら、このコマンドを使用して外部IPを見つけることができます:
@@ -171,7 +171,7 @@ frontend LoadBalancer 10.51.252.116 XXX.XXX.XXX.XXX 80/TCP 1m
このIPを使用して、クラスターの外部から`frontend` Serviceとやり取りできるようになりました。
### フロントエンドを介するトラフィック送信
## フロントエンドを介するトラフィック送信
フロントエンドとバックエンドが接続されました。
フロントエンドServiceの外部IPに対してcurlコマンドを使用して、エンドポイントにアクセスできます。
content/ja/docs/tasks/access-application-cluster/service-access-application-cluster.md
+6 -1
View File
@@ -34,9 +34,14 @@ weight: 60
## 2つのPodから成るアプリケーションのServiceを作成
アプリケーションDeploymentの設定ファイルは以下の通りです:
{{< codenew file="service/access/hello-application.yaml" >}}
1. クラスタでHello Worldアプリケーションを稼働させます:
上記のファイルを使用し、アプリケーションのDeploymentを作成します:
```shell
kubectl run hello-world --replicas=2 --labels="run=load-balancer-example" --image=gcr.io/google-samples/node-hello:1.0 --port=8080
kubectl apply -f https://k8s.io/examples/service/access/hello-application.yaml
```
このコマンドは
[Deployment](/ja/docs/concepts/workloads/controllers/deployment/)
content/ja/docs/tasks/access-application-cluster/web-ui-dashboard.md
+167
View File
@@ -0,0 +1,167 @@
---
title: Web UI (Dashboard)
content_template: templates/concept
weight: 10
card:
name: tasks
weight: 30
title: Web UIダッシュボードを使用する
---
{{% capture overview %}}
ダッシュボードは、WebベースのKubernetesユーザーインターフェイスです。ダッシュボードを使用して、コンテナ化されたアプリケーションをKubernetesクラスターにデプロイしたり、コンテナ化されたアプリケーションをトラブルシューティングしたり、クラスターリソースを管理したりすることができます。ダッシュボードを使用して、クラスター上で実行されているアプリケーションの概要を把握したり、個々のKubernetesリソース(Deployments、Jobs、DaemonSetsなど)を作成または修正したりすることができます。たとえば、Deploymentのスケール、ローリングアップデートの開始、Podの再起動、デプロイウィザードを使用した新しいアプリケーションのデプロイなどが可能です。
ダッシュボードでは、クラスター内のKubernetesリソースの状態や、発生した可能性のあるエラーに関する情報も提供されます。
![Kubernetes Dashboard UI](/images/docs/ui-dashboard.png)
{{% /capture %}}
{{% capture body %}}
## ダッシュボードUIのデプロイ
ダッシュボードUIはデフォルトではデプロイされていません。デプロイするには、以下のコマンドを実行します:
```
kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0-beta8/aio/deploy/recommended.yaml
```
## ダッシュボードUIへのアクセス
クラスターデータを保護するために、ダッシュボードはデフォルトで最小限のRBAC構成でデプロイします。現在、ダッシュボードはBearer Tokenによるログインのみをサポートしています。このデモ用のトークンを作成するには、[サンプルユーザーの作成](https://github.com/kubernetes/dashboard/blob/master/docs/user/access-control/creating-sample-user.md)ガイドに従ってください。
{{< warning >}}
チュートリアルで作成されたサンプルユーザーには管理者権限が与えられ、教育目的のみに使用されます。
{{< /warning >}}
### コマンドラインプロキシー
以下のコマンドを実行することで、kubectlコマンドラインツールを使ってダッシュボードにアクセスすることができます:
```
kubectl proxy
```
kubectlは、ダッシュボードを http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/ で利用できるようにします。
UIはコマンドを実行しているマシンから_のみ_ アクセスできます。オプションについては`kubectl proxy --help`を参照してください。
{{< note >}}
Kubeconfigの認証方法は、外部IDプロバイダーやx509証明書ベースの認証には対応していません。
{{< /note >}}
## ウェルカムビュー
空のクラスターでダッシュボードにアクセスすると、ウェルカムページが表示されます。このページには、このドキュメントへのリンクと、最初のアプリケーションをデプロイするためのボタンが含まれています。さらに、クラスターの`kube-system`[名前空間](/docs/tasks/administer-cluster/namespaces/)でデフォルトで実行されているシステムアプリケーション、たとえばダッシュボード自体を見ることができます。
![Kubernetes Dashboard welcome page](/images/docs/ui-dashboard-zerostate.png)
## コンテナ化されたアプリケーションのデプロイ
ダッシュボードを使用すると、簡単なウィザードでコンテナ化されたアプリケーションをDeploymentとオプションのServiceとして作成してデプロイすることができます。アプリケーションの詳細を手動で指定するか、アプリケーションの設定を含むYAMLまたはJSONファイルをアップロードすることができます。
任意のページの右上にある**CREATE**ボタンをクリックして開始します。
### アプリケーションの詳細の指定
デプロイウィザードでは、以下の情報を入力する必要があります:
- **App name** (必須): アプリケーションの名前です。その名前の[label](/ja/docs/concepts/overview/working-with-objects/labels/)は、デプロイされるDeploymentとServiceに追加されます。
アプリケーション名は、選択したKubernetes[名前空間](/docs/tasks/administer-cluster/namespaces/)内で一意である必要があります。小文字で始まり、小文字または数字で終わり、小文字、数字、ダッシュ(-)のみを含む必要があります。文字数は24文字に制限されています。先頭と末尾のスペースは無視されます。
- **Container image** (必須): 任意のレジストリ上の公開Docker[コンテナイメージ](/docs/concepts/containers/images/)、またはプライベートイメージ(一般的にはGoogle Container RegistryやDocker Hub上でホストされている)のURLです。コンテナイメージの指定はコロンで終わらせる必要があります。
- **Number of pods** (必須): アプリケーションをデプロイするPodの数です。値は正の整数である必要があります。
クラスタ全体で必要な数のPodを維持するために、[Deployment](/ja/docs/concepts/workloads/controllers/deployment/)が作成されます。
- **Service** (任意): アプリケーションのいくつかの部分(たとえばフロントエンド)では、[Service](/ja/docs/concepts/services-networking/service/)をクラスター外の外部、おそらくパブリックIPアドレス(外部サービス)に公開したいと思うかもしれません。外部サービスの場合は、そのために1つ以上のポートを開放する必要があるでしょう。詳細は[こちら](/docs/tasks/access-application-cluster/configure-cloud-provider-firewall/)を参照してください。
クラスター内部からしか見えないその他のサービスは、内部サービスと呼ばれます。
サービスの種類にかかわらず、サービスを作成し、コンテナがポート(受信)をリッスンする場合は、2つのポートを指定する必要があります。サービスは、ポート(受信)をコンテナから見たターゲットポートにマッピングして作成されます。このサービスは、デプロイされたPodにルーティングされます。サポートされるプロトコルはTCPとUDPです。このサービスの内部DNS名は、上記のアプリケーション名として指定した値になります。
必要に応じて、**高度なオプション**セクションを展開して、より多くの設定を指定することができます:
- **Description**: ここで入力したテキストは、[アノテーション](/ja/docs/concepts/overview/working-with-with-objects/annotations/)としてDeploymentに追加され、アプリケーションの詳細に表示されます。
- **Labels**: アプリケーションに使用するデフォルトの[ラベル](/ja/docs/concepts/overview/working-with-objects/labels/)は、アプリケーション名とバージョンです。リリース、環境、ティア、パーティション、リリーストラックなど、Deployment、Service(存在する場合)、Podに適用する追加のラベルを指定できます。
例:
```conf
release=1.0
tier=frontend
environment=pod
track=stable
```
- **Namespace**: Kubernetesは、同じ物理クラスターを基盤とする複数の仮想クラスターをサポートしています。これらの仮想クラスタは[名前空間](/docs/tasks/administer-cluster/namespaces/) と呼ばれます。これにより、リソースを論理的に名前のついたグループに分割することができます。
ダッシュボードでは、利用可能なすべての名前空間がドロップダウンリストに表示され、新しい名前空間を作成することができます。名前空間名には、最大63文字の英数字とダッシュ(-)を含めることができますが、大文字を含めることはできません。
名前空間名は数字だけで構成されるべきではありません。名前が10などの数値として設定されている場合、Podはデフォルトの名前空間に配置されます。
名前空間の作成に成功した場合は、デフォルトで選択されます。作成に失敗した場合は、最初の名前空間が選択されます。
- **Image Pull Secret**: 指定されたDockerコンテナイメージが非公開の場合、[pull secret](/docs/concepts/configuration/secret/)の認証情報が必要になる場合があります。
ダッシュボードでは、利用可能なすべてのSecretがドロップダウンリストに表示され、新しいSecretを作成できます。Secret名は DNSドメイン名の構文に従う必要があります。たとえば、`new.image-pull.secret`です。Secretの内容はbase64エンコードされ、[`.dockercfg`](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod)ファイルで指定されている必要があります。Secret名は最大253文字で構成されます。
イメージプルシークレットの作成に成功した場合は、デフォルトで選択されています。作成に失敗した場合は、シークレットは適用されません。
- **CPU requirement (cores)**と**Memory requirement (MiB)**: コンテナの最小[リソース制限](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)を指定することができます。デフォルトでは、PodはCPUとメモリの制限がない状態で実行されます。
- **Run command**と**Run command arguments**: デフォルトでは、コンテナは指定されたDockerイメージのデフォルトの[entrypointコマンド](/docs/tasks/inject-data-application/define-command-argument-container/)を実行します。コマンドのオプションと引数を使ってデフォルトを上書きすることができます。
- **Run as privileged**: この設定は、[特権コンテナ](/ja/docs/concepts/workloads/pods/pod/#privileged-mode-for-pod-containers)内のプロセスが、ホスト上でrootとして実行されているプロセスと同等であるかどうかを決定します。特権コンテナは、ネットワークスタックの操作やデバイスへのアクセスなどの機能を利用できます。
- **Environment variables**: Kubernetesは[環境変数](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)を介してServiceを公開しています。環境変数を作成したり、環境変数の値を使ってコマンドに引数を渡したりすることができます。環境変数の値はServiceを見つけるためにアプリケーションで利用できます。値は`$(VAR_NAME)`構文を使用して他の変数を参照できます。
### YAMLまたはJSONファイルのアップロード
Kubernetesは宣言的な設定をサポートしています。このスタイルでは、すべての設定は Kubernetes [API](/ja/docs/concepts/overview/kubernetes-api/)リソーススキーマを使用してYAMLまたは JSON設定ファイルに格納されます。
デプロイウィザードでアプリケーションの詳細を指定する代わりに、YAMLまたはJSONファイルでアプリケーションを定義し、ダッシュボードを使用してファイルをアップロードできます。
## ダッシュボードの使用
以下のセクションでは、Kubernetes Dashboard UIのビュー、それらが提供するものとその使用方法について説明します。
### ナビゲーション
クラスターにKubernetesオブジェクトが定義されている場合、ダッシュボードではそれらのオブジェクトが初期表示されます。デフォルトでは_default_ 名前空間のオブジェクトのみが表示されますが、これはナビゲーションメニューにある名前空間セレクターで変更できます。
ダッシュボードにはほとんどのKubernetesオブジェクトの種類が表示され、いくつかのメニューカテゴリーにグループ化されています。
#### 管理者の概要
クラスターと名前空間の管理者向けに、ダッシュボードにはノード、名前空間、永続ボリュームが一覧表示され、それらの詳細ビューが用意されています。ノードリストビューには、すべてのノードにわたって集計されたCPUとメモリーのメトリクスが表示されます。詳細ビューには、ノードのメトリクス、仕様、ステータス、割り当てられたリソース、イベント、ノード上で実行されているPodが表示されます。
#### ワークロード
選択した名前空間で実行されているすべてのアプリケーションを表示します。このビューでは、アプリケーションがワークロードの種類(例：Deployment、ReplicaSet、StatefulSetなど)ごとに一覧表示され、各ワークロードの種類を個別に表示することができます。リストには、ReplicaSetの準備ができたPodの数やPodの現在のメモリ使用量など、ワークロードに関する実用的な情報がまとめられています。
ワークロードの詳細ビューには、ステータスや仕様情報、オブジェクト間の表面関係が表示されます。たとえば、ReplicaSetが制御しているPodや、新しいReplicaSet、DeploymentのためのHorizontal Pod Autoscalerなどです。
#### Service
外部の世界にサービスを公開し、クラスター内でサービスを発見できるようにするKubernetesリソースを表示します。そのため、ServiceとIngressのビューには、それらが対象とするPod、クラスター接続の内部エンドポイント、外部ユーザーの外部エンドポイントが表示されます。
#### ストレージ
ストレージビューには、アプリケーションがデータを保存するために使用するPersistentVolumeClaimリソースが表示されます。
#### ConfigMapとSecret
クラスターで実行されているアプリケーションのライブ設定に使用されているすべてのKubernetesリソースを表示します。このビューでは、設定オブジェクトの編集と管理が可能で、デフォルトで非表示になっているSecretを表示します。
#### ログビューアー
Podのリストと詳細ページは、ダッシュボードに組み込まれたログビューアーにリンクしています。このビューアーでは、単一のPodに属するコンテナからログをドリルダウンすることができます。
![Logs viewer](/images/docs/ui-dashboard-logs-view.png)
{{% /capture %}}
{{% capture whatsnext %}}
詳細については[Kubernetes Dashboardプロジェクトページ](https://github.com/kubernetes/dashboard)をご覧ください。
{{% /capture %}}
content/ja/docs/tasks/administer-cluster/developing-cloud-controller-manager.md
+1 -1
View File
@@ -13,7 +13,7 @@ content_type: concept
独自のクラウドコントローラーマネージャーを構築する方法を説明する前に、クラウドコントローラーマネージャーがKubernetesの内部でどのように機能するかに関する背景を知っておくと役立ちます。
クラウドコントローラーマネージャーはGoインターフェースを利用する`kube-controller-manager`のコードで、任意のクラウドの実装をプラグインとして利用できるようになっています。スキャフォールディングと汎用のコントローラー実装の大部分はKubernetesのコアになりますが、[クラウドプロバイダーのインターフェイス](https://github.com/kubernetes/cloud-provider/blob/master/cloud.go#L42-L62)が満たされていれば提供されているクラウドプロバイダーのインターフェイスが実行されるようになります。
実装の詳細をもう少し掘り下げてみましょう。すべてのクラウドコントローラーマネージャーはKubernetesコアからパッケージをインポートします。唯一の違いは、各プロジェクトが利用可能なクラウドプロバイダーの情報(グローバル変数)が更新される場所である[cloudprovider.RegisterCloudProvider](https://github.com/kubernetes/cloud-provider/blob/master/plugins.go#L56-L66)を呼び出すことによって独自のクラウドプロバイダーを登録する点です。
実装の詳細をもう少し掘り下げてみましょう。すべてのクラウドコントローラーマネージャーはKubernetesコアからパッケージをインポートします。唯一の違いは、各プロジェクトが利用可能なクラウドプロバイダーの情報(グローバル変数)が更新される場所である[cloudprovider.RegisterCloudProvider](https://github.com/kubernetes/cloud-provider/blob/6371aabbd7a7726f4b358444cca40def793950c2/plugins.go#L55-L63)を呼び出すことによって独自のクラウドプロバイダーを登録する点です。
content/ja/docs/tasks/configure-pod-container/assign-cpu-resource.md
+1 -1
View File
@@ -216,7 +216,7 @@ kubectl delete namespace cpu-example
### アプリケーション開発者向け
* [コンテナとPodにメモリーリソースを割り当てる](/docs/tasks/configure-pod-container/assign-memory-resource/)
* [コンテナおよびPodへのメモリーリソースの割り当て](/ja/docs/tasks/configure-pod-container/assign-memory-resource/)
* [PodのQuality of Serviceを設定する](/docs/tasks/configure-pod-container/quality-service-pod/)
content/ja/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md
+1 -1
View File
@@ -63,7 +63,7 @@ Pod内で実行されているコンテナでシェルを実行します:
ただし、コンテナのエントリーポイントが呼び出される前にpostStartハンドラーが呼び出されるという保証はありません。postStartハンドラーはコンテナのコードに対して非同期的に実行されますが、postStartハンドラーが完了するまでコンテナのKubernetesによる管理はブロックされます。postStartハンドラーが完了するまで、コンテナのステータスはRUNNINGに設定されません。
Kubernetesはコンテナが終了する直前にpreStopイベントを送信します。
コンテナのKubernetesによる管理は、Podの猶予期間が終了しない限り、preStopハンドラーが完了するまでブロックされます。詳細は[Podの終了](/ja/docs/concepts/workloads/pods/pod/#podの終了)を参照してください。
コンテナのKubernetesによる管理は、Podの猶予期間が終了しない限り、preStopハンドラーが完了するまでブロックされます。詳細は[Podの終了](/ja/docs/concepts/workloads/pods/pod/#termination-of-pods)を参照してください。
{{< note >}}
Kubernetesは、Podが *終了* したときにのみpreStopイベントを送信します。
content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md
+337
View File
@@ -0,0 +1,337 @@
---
title: Liveness Probe、Readiness ProbeおよびStartup Probeを使用する
content_template: templates/task
weight: 110
---
{{% capture overview %}}
このページでは、Liveness Probe、Readiness ProbeおよびStartup Probeの使用方法について説明します。
[kubelet](/docs/admin/kubelet/)は、Liveness Probeを使用して、コンテナをいつ再起動するかを認識します。
例えば、アプリケーション自体は起動しているが、処理を継続することができないデッドロック状態を検知することができます。
このような状態のコンテナを再起動することで、バグがある場合でもアプリケーションの可用性を高めることができます。
kubeletは、Readiness Probeを使用して、コンテナがトラフィックを受け入れられる状態であるかを認識します。
Podが準備ができていると見なされるのは、Pod内の全てのコンテナの準備が整ったときです。
一例として、このシグナルはServiceのバックエンドとして使用されるPodを制御するときに使用されます。
Podの準備ができていない場合、そのPodはServiceのロードバランシングから切り離されます。
kubeletは、Startup Probeを使用して、コンテナアプリケーションの起動が完了したかを認識します。
Startup Probeを使用している場合、Startup Probeが成功するまでは、Liveness Probeと
Readiness Probeによるチェックを無効にし、これらがアプリケーションの起動に干渉しないようにします。
例えば、これを起動が遅いコンテナの起動チェックとして使用することで、起動する前にkubeletによって
強制終了されることを防ぐことができます。
{{% /capture %}}
{{% capture prerequisites %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
{{% /capture %}}
{{% capture steps %}}
## コマンド実行によるLiveness Probeを定義する {#define-a-liveness-command}
長期間実行されているアプリケーションの多くは、再起動されるまで回復できないような異常な状態になることがあります。
Kubernetesはこのような状況を検知し、回復するためのLiveness Probeを提供します。
この演習では、`k8s.gcr.io/busybox`イメージのコンテナを起動するPodを作成します。
Podの構成ファイルは次の通りです。
{{< codenew file="pods/probe/exec-liveness.yaml" >}}
この構成ファイルでは、Podは一つの`Container`を起動します。
`periodSeconds`フィールドは、kubeletがLiveness Probeを5秒おきに行うように指定しています。
`initialDelaySeconds`フィールドは、kubeletが最初のProbeを実行する前に5秒間待機するように指示しています。
Probeの動作としては、kubeletは`cat /tmp/healthy`を対象のコンテナ内で実行します。
このコマンドが成功し、リターンコード0が返ると、kubeletはコンテナが問題なく動いていると判断します。
リターンコードとして0以外の値が返ると、kubeletはコンテナを終了し、再起動を行います。
このコンテナは、起動すると次のコマンドを実行します:
```shell
/bin/sh -c "touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600"
```
コンテナが起動してから初めの30秒間は`/tmp/healthy`ファイルがコンテナ内に存在します。
そのため初めの30秒間は`cat /tmp/healthy`コマンドは成功し、正常なリターンコードが返ります。
その後30秒が経過すると、`cat /tmp/healthy`コマンドは異常なリターンコードを返します。
このPodを起動してください:
```shell
kubectl apply -f https://k8s.io/examples/pods/probe/exec-liveness.yaml
```
30秒間以内に、Podのイベントを確認します。
```shell
kubectl describe pod liveness-exec
```
この出力結果は、Liveness Probeがまだ失敗していないことを示しています。
```
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
24s 24s 1 {default-scheduler } Normal Scheduled Successfully assigned liveness-exec to worker0
23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Pulling pulling image "k8s.gcr.io/busybox"
23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Pulled Successfully pulled image "k8s.gcr.io/busybox"
23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Created Created container with docker id 86849c15382e; Security:[seccomp=unconfined]
23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Started Started container with docker id 86849c15382e
```
35秒後に、Podのイベントをもう一度確認します:
```shell
kubectl describe pod liveness-exec
```
出力結果の最後に、Liveness Probeが失敗していることを示すメッセージが表示されます。これによりコンテナは強制終了し、再作成されました。
```
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
37s 37s 1 {default-scheduler } Normal Scheduled Successfully assigned liveness-exec to worker0
36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Pulling pulling image "k8s.gcr.io/busybox"
36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Pulled Successfully pulled image "k8s.gcr.io/busybox"
36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Created Created container with docker id 86849c15382e; Security:[seccomp=unconfined]
36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Started Started container with docker id 86849c15382e
2s 2s 1 {kubelet worker0} spec.containers{liveness} Warning Unhealthy Liveness probe failed: cat: can't open '/tmp/healthy': No such file or directory
```
さらに30秒後、コンテナが再起動していることを確認します:
```shell
kubectl get pod liveness-exec
```
出力結果から、`RESTARTS`がインクリメントされていることを確認します:
```
NAME READY STATUS RESTARTS AGE
liveness-exec 1/1 Running 1 1m
```
## HTTPリクエストによるLiveness Probeを定義する {#define-a-liveness-http-request}
別の種類のLiveness Probeでは、HTTP GETリクエストを使用します。
次の構成ファイルは、`k8s.gcr.io/liveness`イメージを使用したコンテナを起動するPodを作成します。
{{< codenew file="pods/probe/http-liveness.yaml" >}}
この構成ファイルでは、Podは一つの`Container`を起動します。
`periodSeconds`フィールドは、kubeletがLiveness Probeを3秒おきに行うように指定しています。
`initialDelaySeconds`フィールドは、kubeletが最初のProbeを実行する前に3秒間待機するように指示しています。
Probeの動作としては、kubeletは8080ポートをリッスンしているコンテナ内のサーバーに対してHTTP GETリクエストを送ります。
サーバー内の`/healthz`パスに対するハンドラーが正常なリターンコードを応答した場合、
kubeletはコンテナが問題なく動いていると判断します。
異常なリターンコードを応答すると、kubeletはコンテナを終了し、再起動を行います。
200以上400未満のコードは成功とみなされ、その他のコードは失敗とみなされます。
[server.go](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/test/images/agnhost/liveness/server.go)
にてサーバーのソースコードを確認することができます。
コンテナが生きている初めの10秒間は、`/healthz`ハンドラーが200ステータスを返します。
その後、ハンドラーは500ステータスを返します。
```go
http.HandleFunc("/healthz", func(w http.ResponseWriter, r *http.Request) {
duration := time.Now().Sub(started)
if duration.Seconds() > 10 {
w.WriteHeader(500)
w.Write([]byte(fmt.Sprintf("error: %v", duration.Seconds())))
} else {
w.WriteHeader(200)
w.Write([]byte("ok"))
}
})
```
kubeletは、コンテナが起動してから3秒後からヘルスチェックを行います。
そのため、初めのいくつかのヘルスチェックは成功します。しかし、10秒経過するとヘルスチェックは失敗し、kubeletはコンテナを終了し、再起動します。
HTTPリクエストのチェックによるLiveness Probeを試すには、以下のようにPodを作成します:
```shell
kubectl apply -f https://k8s.io/examples/pods/probe/http-liveness.yaml
```
10秒後、Podのイベントを表示して、Liveness Probeが失敗し、コンテナが再起動されていることを確認します。
```shell
kubectl describe pod liveness-http
```
v1.13以前(v1.13を含む)のリリースにおいては、Podが起動しているノードに環境変数`http_proxy`
(または `HTTP_PROXY`)が設定されている場合、HTTPリクエストのLiveness Probeは設定されたプロキシを使用します。
v1.13より後のリリースにおいては、ローカルHTTPプロキシ環境変数の設定はHTTPリクエストのLiveness Probeに影響しません。
## TCPによるLiveness Probeを定義する {#define-a-tcp-liveness-probe}
3つ目のLiveness ProbeはTCPソケットを使用するタイプです。
この構成においては、kubeletは指定したコンテナのソケットを開くことを試みます。
コネクションが確立できる場合はコンテナを正常とみなし、失敗する場合は異常とみなします。
{{< codenew file="pods/probe/tcp-liveness-readiness.yaml" >}}
見ての通り、TCPによるチェックの構成はHTTPによるチェックと非常に似ています。
この例では、Readiness ProbeとLiveness Probeを両方使用しています。
kubeletは、コンテナが起動してから5秒後に最初のReadiness Probeを開始します。
これは`goproxy`コンテナの8080ポートに対して接続を試みます。
このProbeが成功すると、Podは準備ができていると通知されます。kubeletはこのチェックを10秒ごとに行います。
この構成では、Readiness Probeに加えてLiveness Probeが含まれています。
kubeletは、コンテナが起動してから15秒後に最初のLiveness Probeを実行します。
Readiness Probeと同様に、これは`goproxy`コンテナの8080ポートに対して接続を試みます。
Liveness Probeが失敗した場合、コンテナは再起動されます。
TCPのチェックによるLiveness Probeを試すには、以下のようにPodを作成します:
```shell
kubectl apply -f https://k8s.io/examples/pods/probe/tcp-liveness-readiness.yaml
```
15秒後、Podのイベントを表示し、Liveness Probeが行われていることを確認します:
```shell
kubectl describe pod goproxy
```
## 名前付きポートを使用する {#use-a-named-port}
HTTPまたはTCPによるProbeにおいて、[ContainerPort](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerport-v1-core)
で定義した名前付きポートを使用することができます。
```yaml
ports:
- name: liveness-port
containerPort: 8080
hostPort: 8080
livenessProbe:
httpGet:
path: /healthz
port: liveness-port
```
## Startup Probeを使用して、起動の遅いコンテナを保護する {#define-startup-probes}
場合によっては、最初の初期化において追加の起動時間が必要になるようなレガシーアプリケーションを扱う必要があります。
そのような場合、デッドロックに対する迅速な反応を損なうことなくLiveness Probeのパラメーターを設定することは難しい場合があります。
これに対する解決策の一つは、Liveness Probeと同じ構成のコマンドを用いるか、HTTPまたはTCPによるチェックを使用したStartup Probeをセットアップすることです。
その際、`failureThreshold * periodSeconds`で計算される時間を、起動時間として想定される最も遅いケースをカバーできる十分な長さに設定します。
上記の例は、次のようになります:
```yaml
ports:
- name: liveness-port
containerPort: 8080
hostPort: 8080
livenessProbe:
httpGet:
path: /healthz
port: liveness-port
failureThreshold: 1
periodSeconds: 10
startupProbe:
httpGet:
path: /healthz
port: liveness-port
failureThreshold: 30
periodSeconds: 10
```
Startup Probeにより、アプリケーションは起動が完了するまでに最大5分間の猶予(30 * 10 = 300秒)が与えられます。
Startup Probeに一度成功すると、その後はLiveness Probeが引き継ぎ、コンテナのデッドロックに対して迅速に反応します。
Startup Probeが成功しない場合、コンテナは300秒後に終了し、その後はPodの`restartPolicy`に従います。
## Readiness Probeを定義する {#define-readiness-probes}
アプリケーションは一時的にトラフィックを処理できないことが起こり得ます。
例えば、アプリケーションは起動時に大きなデータまたは構成ファイルを読み込む必要がある場合や、起動後に外部サービスに依存している場合があります。
このような場合、アプリケーション自体を終了させたくはありませんが、このアプリケーションに対してリクエストも送信したくないと思います。
Kubernetesは、これらの状況を検知して緩和するための機能としてReadiness Probeを提供します。
これにより、準備ができていないことを報告するコンテナを含むPodは、KubernetesのServiceを通してトラフィックを受信しないようになります。
{{< note >}}
Readiness Probeは、コンテナの全てのライフサイクルにおいて実行されます。
{{< /note >}}
Readiness ProbeはLiveness Probeと同様に構成します。
唯一の違いは`readinessProbe`フィールドを`livenessProbe`フィールドの代わりに利用することだけです。
```yaml
readinessProbe:
exec:
command:
- cat
- /tmp/healthy
initialDelaySeconds: 5
periodSeconds: 5
```
HTTPおよびTCPによるReadiness Probeの構成もLiveness Probeと同じです。
Readiness ProbeとLiveness Probeは同じコンテナで同時に使用できます。
両方使用することで、準備できていないコンテナへのトラフィックが到達しないようにし、コンテナが失敗したときに再起動することができます。
## Probeの構成 {#configure-probes}
{{< comment >}}
Eventually, some of this section could be moved to a concept topic.
{{< /comment >}}
[Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core) には、
Liveness ProbeおよびReadiness Probeのチェック動作をより正確に制御するために使用できるフィールドがあります:
* `initialDelaySeconds`: コンテナが起動してから、Liveness ProbeまたはReadiness Probeが開始されるまでの秒数。デフォルトは0秒。最小値は0。
* `periodSeconds`: Probeが実行される頻度(秒数)。デフォルトは10秒。最小値は1。
* `timeoutSeconds`: Probeがタイムアウトになるまでの秒数。デフォルトは1秒。最小値は1。
* `successThreshold`: 一度Probeが失敗した後、次のProbeが成功したとみなされるための最小連続成功数。
デフォルトは1。Liveness Probeには1を設定する必要があります。最小値は1。
* `failureThreshold`: Podが開始してProbeが失敗した場合、Kubernetesは`failureThreshold`に設定した回数までProbeを試行します。
Liveness Probeにおいて、試行回数に到達することはコンテナを再起動することを意味します。
Readiness Probeの場合は、Podが準備できていない状態として通知されます。デフォルトは3。最小値は1。
[HTTPによるProbe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#httpgetaction-v1-core)
には、`httpGet`にて設定できる追加のフィールドがあります:
* `host`: 接続先ホスト名。デフォルトはPod IP。おそらくはこのフィールドの代わりに`httpHeaders`内の"Host"を代わりに使用することになります。
* `scheme`: ホストへの接続で使用するスキーマ（HTTP または HTTPS）。デフォルトは HTTP。
* `path`: HTTPサーバーへアクセスする際のパス
* `httpHeaders`: リクエスト内のカスタムヘッダー。HTTPでは重複したヘッダーが許可されています。
* `port`: コンテナにアクセスする際のポートの名前または番号。ポート番号の場合、1から65535の範囲内である必要があります。
HTTPによるProbeの場合、kubeletは指定したパスとポートに対するHTTPリクエストを送ることでチェックを行います。
`httpGet`のオプションである`host`フィールドでアドレスが上書きされない限り、kubeletはPodのIPアドレスに対してProbeを送ります。
`scheme`フィールドに`HTTPS`がセットされている場合、kubeletは証明書の検証を行わずにHTTPSリクエストを送ります。
ほとんどのシナリオにおいては、`host`フィールドを使用する必要はありません。次のシナリオは使用する場合の一例です。
仮にコンテナが127.0.0.1をリッスンしており、かつPodの`hostNetwork`フィールドがtrueだとします。
その場合においては、`httpGet`フィールド内の`host`には127.0.0.1をセットする必要があります。
より一般的なケースにおいてPodが仮想ホストに依存している場合は、おそらく`host`フィールドではなく、`httpHeaders`フィールド内の`Host`ヘッダーを使用する必要があります。
TCPによるProbeの場合、kubeletはPodの中ではなく、ノードに対してコネクションを確立するProbeを実行します。
kubeletはServiceの名前を解決できないため、`host`パラメーター内でServiceの名前を使用することはできません。
{{% /capture %}}
{{% capture whatsnext %}}
* [Container Probes](/ja/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)についてもっと学ぶ
また、次のAPIリファレンスも参考にしてください:
* [Pod](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)
* [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)
* [Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core)
{{% /capture %}}
content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md
+674
View File
@@ -0,0 +1,674 @@
---
title: Podを構成してConfigMapを使用する
content_template: templates/task
weight: 150
card:
name: tasks
weight: 50
---
{{% capture overview %}}
ConfigMapを使用すると、設定をイメージのコンテンツから切り離して、コンテナ化されたアプリケーションの移植性を維持できます。このページでは、ConfigMapを作成し、ConfigMapに保存されているデータを使用してPodを構成する一連の使用例を示します。
{{% /capture %}}
{{% capture prerequisites %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
{{% /capture %}}
{{% capture steps %}}
## ConfigMapを作成する
`kubectl create configmap`または`kustomization.yaml`のConfigMap generatorを使用すると、ConfigMapを作成できます。`kubectl`が`kustomization.yaml`をサポートをしているのは1.14からである点に注意してください。
### kubectl create configmapを使用してConfigMapを作成する
`kubectl create configmap`を使用してConfigMapを[ディレクトリ](#create-configmaps-from-directories)、[ファイル](#create-configmaps-from-files)、または[リテラル値](#create-configmaps-from-literal-values)から作成します:
```shell
kubectl create configmap <map-name> <data-source>
```
\<map-name>の部分はConfigMapに割り当てる名前で、\<data-source>はデータを取得するディレクトリ、ファイル、またはリテラル値です。ConfigMapの名前は有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names/#dns-subdomain-names)である必要があります。
ファイルをベースにConfigMapを作成する場合、\<data-source> のキーはデフォルトでファイル名になり、値はデフォルトでファイルの中身になります。
[`kubectl describe`](/docs/reference/generated/kubectl/kubectl-commands/#describe)または
[`kubectl get`](/docs/reference/generated/kubectl/kubectl-commands/#get)を使用すると、ConfigMapに関する情報を取得できます。
#### ディレクトリからConfigMapを作成する{#create-configmaps-from-directories}
`kubectl create configmap`を使用すると、同一ディレクトリ内にある複数のファイルから1つのConfigMapを作成できます。ディレクトリをベースにConfigMapを作成する場合、kubectlはディレクトリ内でベース名が有効なキーであるファイルを識別し、それらのファイルを新たなConfigMapにパッケージ化します。ディレクトリ内にある通常のファイルでないものは無視されます(例: サブディレクトリ、シンボリックリンク、デバイス、パイプなど)。
例えば:
```shell
# ローカルディレクトリを作成します
mkdir -p configure-pod-container/configmap/
# `configure-pod-container/configmap/`ディレクトリにサンプルファイルをダウンロードします
wget https://kubernetes.io/examples/configmap/game.properties -O configure-pod-container/configmap/game.properties
wget https://kubernetes.io/examples/configmap/ui.properties -O configure-pod-container/configmap/ui.properties
# ConfigMapを作成します
kubectl create configmap game-config --from-file=configure-pod-container/configmap/
```
上記のコマンドは各ファイルをパッケージ化します。この場合、`configure-pod-container/configmap/` ディレクトリの`game.properties` と `ui.properties`をgame-config ConfigMapにパッケージ化します。 以下のコマンドを使用すると、ConfigMapの詳細を表示できます:
```shell
kubectl describe configmaps game-config
```
出力結果は以下のようになります:
```
Name: game-config
Namespace: default
Labels: <none>
Annotations: <none>
Data
====
game.properties:
----
enemies=aliens
lives=3
enemies.cheat=true
enemies.cheat.level=noGoodRotten
secret.code.passphrase=UUDDLRLRBABAS
secret.code.allowed=true
secret.code.lives=30
ui.properties:
----
color.good=purple
color.bad=yellow
allow.textmode=true
how.nice.to.look=fairlyNice
```
`configure-pod-container/configmap/` ディレクトリの`game.properties` と `ui.properties` ファイルはConfigMapの`data`セクションに表示されます。
```shell
kubectl get configmaps game-config -o yaml
```
出力結果は以下のようになります:
```yaml
apiVersion: v1
kind: ConfigMap
metadata:
creationTimestamp: 2016-02-18T18:52:05Z
name: game-config
namespace: default
resourceVersion: "516"
uid: b4952dc3-d670-11e5-8cd0-68f728db1985
data:
game.properties: |
enemies=aliens
lives=3
enemies.cheat=true
enemies.cheat.level=noGoodRotten
secret.code.passphrase=UUDDLRLRBABAS
secret.code.allowed=true
secret.code.lives=30
ui.properties: |
color.good=purple
color.bad=yellow
allow.textmode=true
how.nice.to.look=fairlyNice
```
#### ファイルからConfigMapを作成する{#create-configmaps-from-files}
`kubectl create configmap`を使用して、個別のファイルまたは複数のファイルからConfigMapを作成できます。
例えば、
```shell
kubectl create configmap game-config-2 --from-file=configure-pod-container/configmap/game.properties
```
は、以下のConfigMapを生成します:
```shell
kubectl describe configmaps game-config-2
```
出力結果は以下のようになります:
```
Name: game-config-2
Namespace: default
Labels: <none>
Annotations: <none>
Data
====
game.properties:
----
enemies=aliens
lives=3
enemies.cheat=true
enemies.cheat.level=noGoodRotten
secret.code.passphrase=UUDDLRLRBABAS
secret.code.allowed=true
secret.code.lives=30
```
`--from-file`引数を複数回渡し、ConfigMapを複数のデータソースから作成できます。
```shell
kubectl create configmap game-config-2 --from-file=configure-pod-container/configmap/game.properties --from-file=configure-pod-container/configmap/ui.properties
```
以下のコマンドを使用すると、ConfigMap`game-config-2`の詳細を表示できます:
```shell
kubectl describe configmaps game-config-2
```
出力結果は以下のようになります:
```
Name: game-config-2
Namespace: default
Labels: <none>
Annotations: <none>
Data
====
game.properties:
----
enemies=aliens
lives=3
enemies.cheat=true
enemies.cheat.level=noGoodRotten
secret.code.passphrase=UUDDLRLRBABAS
secret.code.allowed=true
secret.code.lives=30
ui.properties:
----
color.good=purple
color.bad=yellow
allow.textmode=true
how.nice.to.look=fairlyNice
```
`--from-env-file`オプションを利用してConfigMapをenv-fileから作成します。例えば:
```shell
# Env-filesは環境編集のリストを含んでいます。
# 以下のシンタックスルールが適用されます:
# envファイルの各行はVAR=VALの形式である必要がある。
# #で始まる行 (例えばコメント)は無視される。
# 空の行は無視される。
# クオーテーションマークは特別な扱いは処理をしない(例えばConfigMapの値の一部になる).
# `configure-pod-container/configmap/`ディレクトリにサンプルファイルをダウンロードします
wget https://kubernetes.io/examples/configmap/game-env-file.properties -O configure-pod-container/configmap/game-env-file.properties
# env-file `game-env-file.properties`は以下のようになります
cat configure-pod-container/configmap/game-env-file.properties
enemies=aliens
lives=3
allowed="true"
# このコメントと上記の空の行は無視されます
```
```shell
kubectl create configmap game-config-env-file \
--from-env-file=configure-pod-container/configmap/game-env-file.properties
```
は、以下のConfigMapを生成します:
```shell
kubectl get configmap game-config-env-file -o yaml
```
出力結果は以下のようになります:
```yaml
apiVersion: v1
kind: ConfigMap
metadata:
creationTimestamp: 2017-12-27T18:36:28Z
name: game-config-env-file
namespace: default
resourceVersion: "809965"
uid: d9d1ca5b-eb34-11e7-887b-42010a8002b8
data:
allowed: '"true"'
enemies: aliens
lives: "3"
```
{{< caution >}}
`--from-env-file`を複数回渡してConfigMapを複数のデータソースから作成する場合、最後のenv-fileのみが使用されます。
{{< /caution >}}
`--from-env-file`を複数回渡す場合の挙動は以下のように示されます:
```shell
# `configure-pod-container/configmap/`ディレクトリにサンブルファイルをダウンロードします
wget https://kubernetes.io/examples/configmap/ui-env-file.properties -O configure-pod-container/configmap/ui-env-file.properties
# ConfigMapを作成します
kubectl create configmap config-multi-env-files \
--from-env-file=configure-pod-container/configmap/game-env-file.properties \
--from-env-file=configure-pod-container/configmap/ui-env-file.properties
```
は、以下のConfigMapを生成します:
```shell
kubectl get configmap config-multi-env-files -o yaml
```
出力結果は以下のようになります:
```yaml
apiVersion: v1
kind: ConfigMap
metadata:
creationTimestamp: 2017-12-27T18:38:34Z
name: config-multi-env-files
namespace: default
resourceVersion: "810136"
uid: 252c4572-eb35-11e7-887b-42010a8002b8
data:
color: purple
how: fairlyNice
textmode: "true"
```
#### ファイルからConfigMap作成する場合は使用するキーを定義する
`--from-file`引数を使用する場合、ConfigMapの`data` セクションでキーにファイル名以外を定義できます:
```shell
kubectl create configmap game-config-3 --from-file=<my-key-name>=<path-to-file>
```
`<my-key-name>`の部分はConfigMapで使うキー、`<path-to-file>` はキーで表示したいデータソースファイルの場所です。
例えば:
```shell
kubectl create configmap game-config-3 --from-file=game-special-key=configure-pod-container/configmap/game.properties
```
は、以下のConfigMapを生成します:
```
kubectl get configmaps game-config-3 -o yaml
```
出力結果は以下のようになります:
```yaml
apiVersion: v1
kind: ConfigMap
metadata:
creationTimestamp: 2016-02-18T18:54:22Z
name: game-config-3
namespace: default
resourceVersion: "530"
uid: 05f8da22-d671-11e5-8cd0-68f728db1985
data:
game-special-key: |
enemies=aliens
lives=3
enemies.cheat=true
enemies.cheat.level=noGoodRotten
secret.code.passphrase=UUDDLRLRBABAS
secret.code.allowed=true
secret.code.lives=30
```
#### リテラル値からConfigMapを作成する{#create-configmaps-from-literal-values}
`--from-literal`引数を指定して`kubectl create configmap`を使用すると、コマンドラインからリテラル値を定義できます:
```shell
kubectl create configmap special-config --from-literal=special.how=very --from-literal=special.type=charm
```
複数のキーバリューペアを渡せます。CLIに提供された各ペアは、ConfigMapの`data`セクションで別のエントリーとして表示されます。
```shell
kubectl get configmaps special-config -o yaml
```
出力結果は以下のようになります:
```yaml
apiVersion: v1
kind: ConfigMap
metadata:
creationTimestamp: 2016-02-18T19:14:38Z
name: special-config
namespace: default
resourceVersion: "651"
uid: dadce046-d673-11e5-8cd0-68f728db1985
data:
special.how: very
special.type: charm
```
### ジェネレーターからConfigMapを作成する
`kubectl`は`kustomization.yaml`を1.14からサポートしています。
ジェネレーターからConfigMapを作成して適用すると、APIサーバー上でオブジェクトを作成できます。ジェネレーターはディレクトリ内の`kustomization.yaml`で指定する必要があリます。
#### ファイルからConfigMapを生成する
例えば、ファイル`configure-pod-container/configmap/game.properties`からConfigMapを生成するには、
```shell
# ConfigMapGeneratorを含むkustomization.yamlファイルを作成する
cat <<EOF >./kustomization.yaml
configMapGenerator:
- name: game-config-4
files:
- configure-pod-container/configmap/game.properties
EOF
```
ConfigMapを作成するためにkustomizationディレクトリを適用します。
```shell
kubectl apply -k .
configmap/game-config-4-m9dm2f92bt created
```
ConfigMapが作成されたことを以下のようにチェックできます:
```shell
kubectl get configmap
NAME DATA AGE
game-config-4-m9dm2f92bt 1 37s
kubectl describe configmaps/game-config-4-m9dm2f92bt
Name: game-config-4-m9dm2f92bt
Namespace: default
Labels: <none>
Annotations: kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"v1","data":{"game.properties":"enemies=aliens\nlives=3\nenemies.cheat=true\nenemies.cheat.level=noGoodRotten\nsecret.code.p...
Data
====
game.properties:
----
enemies=aliens
lives=3
enemies.cheat=true
enemies.cheat.level=noGoodRotten
secret.code.passphrase=UUDDLRLRBABAS
secret.code.allowed=true
secret.code.lives=30
Events: <none>
```
生成されたConfigMapの名前は、コンテンツをハッシュ化したサフィックスを持つことに注意してください。これにより、コンテンツが変更されるたびに新しいConfigMapが生成されます。
#### ファイルからConfigMapを生成する場合に使用するキーを定義する
ConfigMapジェネレーターで使用するキーはファイルの名前以外を定義できます。
例えば、ファイル`configure-pod-container/configmap/game.properties`からキー`game-special-key`を持つConfigMapを作成する場合
```shell
# ConfigMapGeneratorを含むkustomization.yamlファイルを作成する
cat <<EOF >./kustomization.yaml
configMapGenerator:
- name: game-config-5
files:
- game-special-key=configure-pod-container/configmap/game.properties
EOF
```
kustomizationディレクトリを適用してConfigMapを作成します。
```shell
kubectl apply -k .
configmap/game-config-5-m67dt67794 created
```
#### リテラルからConfigMapを作成する
リテラル`special.type=charm`と`special.how=very`からConfigMapを作成する場合は、
以下のように`kustomization.yaml`のConfigMapジェネレーターで指定できます。
```shell
# ConfigMapGeneratorを含むkustomization.yamlファイルを作成します
cat <<EOF >./kustomization.yaml
configMapGenerator:
- name: special-config-2
literals:
- special.how=very
- special.type=charm
EOF
```
kustomizationディレクトリを適用してConfigMapを作成します。
```shell
kubectl apply -k .
configmap/special-config-2-c92b5mmcf2 created
```
## ConfigMapデータを使用してコンテナ環境変数を定義する
### 単一のConfigMapのデータを使用してコンテナ環境変数を定義する
1. ConfigMapに環境変数をキーバリューペアとして定義します:
```shell
kubectl create configmap special-config --from-literal=special.how=very
```
2. ConfigMapに定義された値`special.how`をPod specificationの環境変数`SPECIAL_LEVEL_KEY`に割り当てます。
{{< codenew file="pods/pod-single-configmap-env-variable.yaml" >}}
Podを作成します:
```shell
kubectl create -f https://kubernetes.io/examples/pods/pod-single-configmap-env-variable.yaml
```
すると、Podの出力結果に環境変数`SPECIAL_LEVEL_KEY=very`が含まれています。
### 複数のConfigMapのデータを使用してコンテナ環境変数を定義する
* 先ほどの例の通り、まずはConfigMapを作成します。
{{< codenew file="configmap/configmaps.yaml" >}}
ConfigMapを作成します:
```shell
kubectl create -f https://kubernetes.io/examples/configmap/configmaps.yaml
```
* Pod specificationの環境変数を定義します
{{< codenew file="pods/pod-multiple-configmap-env-variable.yaml" >}}
Podを作成します:
```shell
kubectl create -f https://kubernetes.io/examples/pods/pod-multiple-configmap-env-variable.yaml
```
すると、Podの出力結果に環境変数`SPECIAL_LEVEL_KEY=very` and `LOG_LEVEL=INFO`が含まれています。
## ConfigMapの全てのキーバリューペアをコンテナ環境変数として構成する
{{< note >}}
この機能はKubernetes v1.6以降で利用可能です。
{{< /note >}}
* 複数のキーバリューペアを含むConfigMapを作成します。
{{< codenew file="configmap/configmap-multikeys.yaml" >}}
ConfigMapを作成します:
```shell
kubectl create -f https://kubernetes.io/examples/configmap/configmap-multikeys.yaml
```
* `envFrom`を利用して全てのConfigMapのデータをコンテナ環境変数として定義します。ConfigMapからのキーがPodの環境変数名になります。
{{< codenew file="pods/pod-configmap-envFrom.yaml" >}}
Podを作成します:
```shell
kubectl create -f https://kubernetes.io/examples/pods/pod-configmap-envFrom.yaml
```
すると、Podの出力結果は環境変数`SPECIAL_LEVEL=very`と`SPECIAL_TYPE=charm`が含まれています。
## PodのコマンドでConfigMapに定義した環境変数を使用する
ConfigMapに環境変数を定義し、Pod specificationの`command` セクションで`$(VAR_NAME)`Kubernetes置換構文を介して使用できます。
例えば以下のPod specificationは
{{< codenew file="pods/pod-configmap-env-var-valueFrom.yaml" >}}
以下コマンドの実行で作成され、
```shell
kubectl create -f https://kubernetes.io/examples/pods/pod-configmap-env-var-valueFrom.yaml
```
`test-container`コンテナで以下の出力結果を表示します:
```shell
very charm
```
## ボリュームにConfigMapデータを追加する
[ファイルからConfigMapを作成する](#create-configmaps-from-files)で説明したように、``--from-file``を使用してConfigMapを作成する場合は、ファイル名がConfigMapの`data`セクションに保存されるキーになり、ファイルのコンテンツがキーの値になります。
このセクションの例は以下に示されているspecial-configと名付けれたConfigMapについて言及したものです。
{{< codenew file="configmap/configmap-multikeys.yaml" >}}
ConfigMapを作成します:
```shell
kubectl create -f https://kubernetes.io/examples/configmap/configmap-multikeys.yaml
```
### ConfigMapに保存されているデータをボリュームに入力する
ConfigMap名をPod specificationの`volumes`セクション配下に追加します。
これによりConfigMapデータが`volumeMounts.mountPath`で指定されたディレクトリに追加されます (このケースでは、`/etc/config`に)。`command`セクションはConfigMapのキーに合致したディレクトリファイルを名前別でリスト表示します。
{{< codenew file="pods/pod-configmap-volume.yaml" >}}
Podを作成します:
```shell
kubectl create -f https://kubernetes.io/examples/pods/pod-configmap-volume.yaml
```
Podが稼働していると、`ls /etc/config/`は以下の出力結果を表示します:
```shell
SPECIAL_LEVEL
SPECIAL_TYPE
```
{{< caution >}}
`/etc/config/`ディレクトリに何かファイルがある場合、それらは削除されます。
{{< /caution >}}
### ConfigMapデータをボリュームの特定のパスに追加する
`path`フィールドを利用して特定のConfigMapのアイテム向けに希望のファイルパスを指定します。
このケースでは`SPECIAL_LEVEL`アイテムが`/etc/config/keys`の`config-volume`ボリュームにマウントされます。
{{< codenew file="pods/pod-configmap-volume-specific-key.yaml" >}}
Podを作成します:
```shell
kubectl create -f https://kubernetes.io/examples/pods/pod-configmap-volume-specific-key.yaml
```
Podが稼働していると、 `cat /etc/config/keys`は以下の出力結果を表示します:
```shell
very
```
{{< caution >}}
先ほどのように、`/etc/config/` ディレクトリのこれまでのファイルは全て削除されます
{{< /caution >}}
### キーを特定のパスとファイルアクセス許可に投影する
キーをファイル単位で特定のパスとアクセス許可に投影できます。[Secret](/docs/concepts/configuration/secret/#using-secrets-as-files-from-a-pod)のユーザーガイドで構文が解説されています。
### マウントされたConfigMapは自動的に更新される
ボリュームで使用されているConfigMapが更新されている場合、投影されているキーも同じく結果的に更新されます。kubeletは定期的な同期ごとにマウントされているConfigMapが更新されているかチェックします。しかし、これはローカルのttlを基にしたキャッシュでConfigMapの現在の値を取得しています。その結果、新しいキーがPodに投影されてからConfigMapに更新されるまでのトータルの遅延はkubeletで、kubeletの同期期間(デフォルトで1分) + ConfigMapキャッシュのttl(デフォルトで1分)の長さになる可能性があります。Podのアノテーションを1つ更新すると即時のリフレッシュをトリガーできます。
{{< note >}}
ConfigMapを[subPath](/docs/concepts/storage/volumes/#using-subpath)ボリュームとして利用するコンテナはConfigMapの更新を受け取りません。
{{< /note >}}
{{% /capture %}}
{{% capture discussion %}}
## ConfigMapとPodsを理解する
ConfigMap APIリソースは構成情報をキーバリューペアとして保存します。データはPodで利用したり、コントローラーなどのシステムコンポーネントに提供できます。ConfigMapは[Secret](/docs/concepts/configuration/secret/)に似ていますが、機密情報を含まない文字列を含まない操作する手段を提供します。ユーザーとシステムコンポーネントはどちらも構成情報をConfigMapに保存できます。
{{< note >}}
ConfigMapはプロパティーファイルを参照するべきであり、置き換えるべきではありません。ConfigMapをLinuxの`/etc`ディレクトリとそのコンテンツのように捉えましょう。例えば、[Kubernetes Volume](/docs/concepts/storage/volumes/)をConfigMapから作成した場合、ConfigMapのデータアイテムはボリューム内で個別のファイルとして表示されます。
{{< /note >}}
ConfigMapの`data`フィールドは構成情報を含みます。下記の例のように、シンプルに個別のプロパティーを`--from-literal`で定義、または複雑に構成ファイルまたはJSON blobsを`--from-file`で定義できます。
```yaml
apiVersion: v1
kind: ConfigMap
metadata:
creationTimestamp: 2016-02-18T19:14:38Z
name: example-config
namespace: default
data:
# --from-literalを使用してシンプルにプロパティーを定義する例
example.property.1: hello
example.property.2: world
# --from-fileを使用して複雑にプロパティーを定義する例
example.property.file: |-
property.1=value-1
property.2=value-2
property.3=value-3
```
### 制限事項
- ConfigMapはPod specificationを参照させる前に作成する必要があります(ConfigMapを"optional"として設定しない限り)。存在しないConfigMapを参照させた場合、Podは起動しません。同様にConfigMapに存在しないキーを参照させた場合も、Podは起動しません。
- ConfigMapで`envFrom`を使用して環境変数を定義した場合、無効と判断されたキーはスキップされます。Podは起動されますが、無効な名前はイベントログに(`InvalidVariableNames`)と記録されます。ログメッセージはスキップされたキーごとにリスト表示されます。例えば:
```shell
kubectl get events
```
出力結果は以下のようになります:
```
LASTSEEN FIRSTSEEN COUNT NAME KIND SUBOBJECT TYPE REASON SOURCE MESSAGE
0s 0s 1 dapi-test-pod Pod Warning InvalidEnvironmentVariableNames {kubelet, 127.0.0.1} Keys [1badkey, 2alsobad] from the EnvFrom configMap default/myconfig were skipped since they are considered invalid environment variable names.
```
- ConfigMapは特定の{{< glossary_tooltip term_id="namespace" >}}に属します。ConfigMapは同じ名前空間に属するPodからのみ参照できます。
- {{< glossary_tooltip text="static pods" term_id="static-pod" >}}はKubeletがサポートしていないため、ConfigMapに使用できません。
{{% /capture %}}
{{% capture whatsnext %}}
* 実践例[Configuring Redis using a ConfigMap](/docs/tutorials/configuration/configure-redis-using-configmap/)を続けて読む。
{{% /capture %}}
content/ja/docs/tasks/configure-pod-container/quality-service-pod.md
+3 -2
View File
@@ -231,9 +231,9 @@ kubectl delete namespace qos-example
### アプリケーション開発者向け
* [コンテナとPodにメモリーリソースを割り当てる](/docs/tasks/configure-pod-container/assign-memory-resource/)
* [コンテナおよびPodへのメモリーリソースの割り当て](/ja/docs/tasks/configure-pod-container/assign-memory-resource/)
* [コンテナとPodにCPUリソースを割り当てる](/docs/tasks/configure-pod-container/assign-cpu-resource/)
* [コンテナとPodにCPUリソースを割り当てる](/ja/docs/tasks/configure-pod-container/assign-cpu-resource/)
### クラスター管理者向け
@@ -251,6 +251,7 @@ kubectl delete namespace qos-example
* [APIオブジェクトのクォータを設定する](/docs/tasks/administer-cluster/quota-api-object/)
* [ノードのトポロジー管理ポリシーを制御する](/docs/tasks/administer-cluster/topology-manager/)
content/ja/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md
+2
View File
@@ -114,6 +114,8 @@ kubectl exec ${POD_NAME} -c ${CONTAINER_NAME} -- ${CMD} ${ARG1} ${ARG2} ... ${AR
kubectl exec cassandra -- cat /var/log/cassandra/system.log
```
クラスターで有効にしていれば、 [エフェメラルコンテナ](/docs/concepts/workloads/pods/ephemeral-containers/) を既存のPodに追加することもできます。 新しい一時的なコンテナを利用して、たとえばPod内の問題の診断のために任意のコマンドを実行することができます。利用できる機能を含む詳細については、 [エフェメラルコンテナ](/docs/concepts/workloads/pods/ephemeral-containers/) のページを参照してください。
これらのアプローチがいずれも機能しない場合、Podが実行されているホストマシンを見つけて、そのホストにSSH接続することができます。
## ReplicationControllerのデバッグ
content/ja/docs/tasks/debug-application-cluster/get-shell-running-container.md
+1 -1
View File
@@ -31,7 +31,7 @@ content_type: task
Podを作成します:
```shell
kubectl create -f https://k8s.io/examples/application/shell-demo.yaml
kubectl apply -f https://k8s.io/examples/application/shell-demo.yaml
```
コンテナが実行中であることを確認します:
content/ja/docs/tasks/inject-data-application/_index.md
+4
View File
@@ -0,0 +1,4 @@
---
title: "アプリケーションへのデータ注入"
weight: 30
---
content/ja/docs/tasks/inject-data-application/define-environment-variable-container.md
+113
View File
@@ -0,0 +1,113 @@
---
title: コンテナの環境変数の定義
content_template: templates/task
weight: 20
---
{{% capture overview %}}
このページでは、Kubernetes Podでコンテナの環境変数を定義する方法を説明します。
{{% /capture %}}
{{% capture prerequisites %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
{{% /capture %}}
{{% capture steps %}}
## コンテナの環境変数を定義する {#define-an-environment-variable-for-a-container}
Podを作成するとき、そのPodで実行するコンテナに環境変数を設定することができます。環境変数を設定するには、設定ファイルに `env` または `envFrom` フィールドを含めます。
この演習では、1つのコンテナを実行するPodを作成します。Podの設定ファイルには、名前 `DEMO_GREETING`、値 `"Hello from the environment"`を持つ環境変数が定義されています。Podの設定ファイルを以下に示します:
{{< codenew file="pods/inject/envars.yaml" >}}
1. YAML設定ファイルに基づいてPodを作成します:
```shell
kubectl apply -f https://k8s.io/examples/pods/inject/envars.yaml
```
1. 実行中のPodを一覧表示します:
```shell
kubectl get pods -l purpose=demonstrate-envars
```
出力は以下のようになります:
```
NAME READY STATUS RESTARTS AGE
envar-demo 1/1 Running 0 9s
```
1. Podで実行しているコンテナのシェルを取得します:
```shell
kubectl exec -it envar-demo -- /bin/bash
```
1. シェルで`printenv`コマンドを実行すると、環境変数の一覧が表示されます。
```shell
root@envar-demo:/# printenv
```
出力は以下のようになります:
```
NODE_VERSION=4.4.2
EXAMPLE_SERVICE_PORT_8080_TCP_ADDR=10.3.245.237
HOSTNAME=envar-demo
...
DEMO_GREETING=Hello from the environment
DEMO_FAREWELL=Such a sweet sorrow
```
1. シェルを終了するには、`exit`と入力します。
{{< note >}}
`env`または`envFrom`フィールドを使用して設定された環境変数は、コンテナイメージで指定された環境変数を上書きします。
{{< /note >}}
## 設定の中で環境変数を使用する {#using-environment-variables-inside-of-your-config}
Podの設定で定義した環境変数は、Podのコンテナに設定したコマンドや引数など、設定の他の場所で使用することができます。以下の設定例では、環境変数`GREETING`、`HONORORIFIC`、`NAME`にそれぞれ `Warm greetings to`、`The Most Honorable`、`Kubernetes`を設定しています。これらの環境変数は、`env-print-demo`コンテナに渡されるCLI引数で使われます。
```yaml
apiVersion: v1
kind: Pod
metadata:
name: print-greeting
spec:
containers:
- name: env-print-demo
image: bash
env:
- name: GREETING
value: "Warm greetings to"
- name: HONORIFIC
value: "The Most Honorable"
- name: NAME
value: "Kubernetes"
command: ["echo"]
args: ["$(GREETING) $(HONORIFIC) $(NAME)"]
```
作成されると、コンテナ上で`echo Warm greetings to The Most Honorable Kubernetes`というコマンドが実行されます。
{{% /capture %}}
{{% capture 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 %}}
content/ja/docs/tasks/run-application/delete-stateful-set.md
+3 -3
View File
@@ -51,7 +51,7 @@ kubectl delete pods -l app=myapp
### 永続ボリューム
StatefulSet内のPodを削除しても、関連付けられているボリュームは削除されません。これは、削除する前にボリュームからデータをコピーする機会があることを保証するためです。Podが[終了状態](/ja/docs/concepts/workloads/pods/pod/#podの終了)になった後にPVCを削除すると、ストレージクラスと再利用ポリシーによっては、背後にある永続ボリュームの削除がトリガーされることがあります。決してクレーム削除後にボリュームにアクセスできると想定しないでください。
StatefulSet内のPodを削除しても、関連付けられているボリュームは削除されません。これは、削除する前にボリュームからデータをコピーする機会があることを保証するためです。Podが[終了状態](/ja/docs/concepts/workloads/pods/pod/#termination-of-pods)になった後にPVCを削除すると、ストレージクラスと再利用ポリシーによっては、背後にある永続ボリュームの削除がトリガーされることがあります。決してクレーム削除後にボリュームにアクセスできると想定しないでください。
{{< note >}}
データを損失する可能性があるため、PVCを削除するときは注意してください。
@@ -73,14 +73,14 @@ kubectl delete pvc -l app=myapp
### StatefulSet Podの強制削除
StatefulSet内の一部のPodが長期間`Terminating`または`Unknown`状態のままになっていることが判明した場合は、手動でapiserverからPodを強制的に削除する必要があります。これは潜在的に危険な作業です。詳細は[StatefulSet Podの強制削除](/docs/tasks/run-application/force-delete-stateful-set-pod/)を参照してください。
StatefulSet内の一部のPodが長期間`Terminating`または`Unknown`状態のままになっていることが判明した場合は、手動でapiserverからPodを強制的に削除する必要があります。これは潜在的に危険な作業です。詳細は[StatefulSet Podの強制削除](/ja/docs/tasks/run-application/force-delete-stateful-set-pod/)を参照してください。
## {{% heading "whatsnext" %}}
[StatefulSet Podの強制削除](/docs/tasks/run-application/force-delete-stateful-set-pod/)の詳細
[StatefulSet Podの強制削除](/ja/docs/tasks/run-application/force-delete-stateful-set-pod/)の詳細
content/ja/docs/tasks/run-application/force-delete-stateful-set-pod.md
+1 -1
View File
@@ -31,7 +31,7 @@ StatefulSetの通常の操作では、StatefulSet Podを強制的に削除する
kubectl delete pods <pod>
```
上記がグレースフルターミネーションにつながるためには、`pod.Spec.TerminationGracePeriodSeconds`に0を指定しては**いけません**。`pod.Spec.TerminationGracePeriodSeconds`を0秒に設定することは安全ではなく、StatefulSet Podには強くお勧めできません。グレースフル削除は安全で、kubeletがapiserverから名前を削除する前に[Podが適切にシャットダウンする](/docs/user-guide/pods/#termination-of-pods)ことを保証します。
上記がグレースフルターミネーションにつながるためには、`pod.Spec.TerminationGracePeriodSeconds`に0を指定しては**いけません**。`pod.Spec.TerminationGracePeriodSeconds`を0秒に設定することは安全ではなく、StatefulSet Podには強くお勧めできません。グレースフル削除は安全で、kubeletがapiserverから名前を削除する前に[Podが適切にシャットダウンする](/ja/docs/concepts/workloads/pods/pod/#termination-of-pods)ことを保証します。
Kubernetes（バージョン1.5以降）は、Nodeにアクセスできないという理由だけでPodを削除しません。到達不能なNodeで実行されているPodは、[タイムアウト](/docs/admin/node/#node-condition)の後に`Terminating`または`Unknown`状態になります。到達不能なNode上のPodをユーザーが適切に削除しようとすると、Podはこれらの状態に入ることもあります。そのような状態のPodをapiserverから削除することができる唯一の方法は以下の通りです:
content/ja/docs/tasks/service-catalog/install-service-catalog-using-helm.md
+1 -1
View File
@@ -19,7 +19,7 @@ content_type: task
* クラウド上のKubernetesクラスター、または{{< glossary_tooltip text="Minikube" term_id="minikube" >}}を使用している場合、クラスターDNSはすでに有効化されています。
* `hack/local-up-cluster.sh`を使用している場合は、環境変数`KUBE_ENABLE_CLUSTER_DNS`が設定されていることを確認し、インストールスクリプトを実行してください。
* [kubectlのインストールおよびセットアップ](/ja/docs/tasks/tools/install-kubectl/)を参考に、v1.7以降のkubectlをインストールし、設定を行ってください。
* v2.7.0以降の[Helm](http://helm.sh/)をインストールしてください。
* v2.7.0以降の[Helm](https://helm.sh/)をインストールしてください。
* [Helm install instructions](https://helm.sh/docs/intro/install/)を参考にしてください。
* 上記のバージョンのHelmをすでにインストールしている場合は、`helm init`を実行し、HelmのサーバーサイドコンポーネントであるTillerをインストールしてください。
content/ja/docs/tasks/tools/install-kubectl.md
+40 -16
View File
@@ -52,7 +52,7 @@ kubectlのバージョンは、クラスターのマイナーバージョンと
4. インストールしたバージョンが最新であることを確認してください:
```
kubectl version
kubectl version --client
```
### ネイティブなパッケージマネージャーを使用してインストールする
@@ -81,21 +81,24 @@ yum install -y kubectl
### 他のパッケージマネージャーを使用してインストールする
{{< tabs name="other_kubectl_install" >}}
{{% tab name="Snap" %}}
Ubuntuまたは[snap](https://snapcraft.io/docs/core/install)パッケージマネージャーをサポートする別のLinuxディストリビューションを使用している場合、kubectlは[snap](https://snapcraft.io/)アプリケーションとして使用できます。
Linuxで[Homebrew](https://docs.brew.sh/Homebrew-on-Linux)パッケージマネージャーを使用している場合は、kubectlを[インストール](https://docs.brew.sh/Homebrew-on-Linux#install)することが可能です。
{{< tabs name="other_kubectl_install" >}}
{{< tab name="Snap" codelang="bash" >}}
sudo snap install kubectl --classic
```shell
snap install kubectl --classic
kubectl version
{{< /tab >}}
{{< tab name="Homebrew" codelang="bash" >}}
```
{{% /tab %}}
{{% tab name="Homebrew" %}}
Linuxで[Homebrew](https://docs.brew.sh/Homebrew-on-Linux)パッケージマネージャーを使用している場合は、kubectlを[インストール](https://docs.brew.sh/Homebrew-on-Linux#install)することが可能です。
```shell
brew install kubectl
kubectl version
{{< /tab >}}
```
{{% /tab %}}
{{< /tabs >}}
## macOSへkubectlをインストールする {#install-kubectl-on-macos}
@@ -130,7 +133,7 @@ kubectl version
4. インストールしたバージョンが最新であることを確認してください:
```
kubectl version
kubectl version --client
```
### Homebrewを使用してmacOSへインストールする
@@ -151,7 +154,7 @@ macOSで[Homebrew](https://brew.sh/)パッケージマネージャーを使用
2. インストールしたバージョンが最新であることを確認してください:
```
kubectl version
kubectl version --client
```
### MacPortsを使用してmacOSへインストールする
@@ -168,7 +171,7 @@ macOSで[MacPorts](https://macports.org/)パッケージマネージャーを使
2. インストールしたバージョンが最新であることを確認してください:
```
kubectl version
kubectl version --client
```
## Windowsへkubectlをインストールする {#install-kubectl-on-windows}
@@ -189,7 +192,7 @@ macOSで[MacPorts](https://macports.org/)パッケージマネージャーを使
3. `kubectl`のバージョンがダウンロードしたものと同じであることを確認してください:
```
kubectl version
kubectl version --client
```
{{< note >}}
[Docker Desktop for Windows](https://docs.docker.com/docker-for-windows/#kubernetes)は、それ自身のバージョンの`kubectl`をPATHに追加します。Docker Desktopをすでにインストールしている場合、Docker Desktopインストーラーによって追加されたPATHの前に追加するか、Docker Desktopの`kubectl`を削除してください。
@@ -213,7 +216,7 @@ Windowsで[Powershell Gallery](https://www.powershellgallery.com/)パッケー
2. インストールしたバージョンが最新であることを確認してください:
```
kubectl version
kubectl version --client
```
{{< note >}}アップデートする際は、手順1に示した2つのコマンドを再実行してください。{{< /note >}}
@@ -236,7 +239,7 @@ Windowsへkubectlをインストールするために、[Chocolatey](https://cho
2. インストールしたバージョンが最新であることを確認してください:
```
kubectl version
kubectl version --client
```
3. ホームディレクトリへ移動してください:
@@ -278,7 +281,7 @@ Google Cloud SDKの一部として、kubectlをインストールすることも
3. インストールしたバージョンが最新であることを確認してください:
```
kubectl version
kubectl version --client
```
## kubectlの設定を検証する
@@ -382,6 +385,27 @@ Bashにおけるkubectlの補完スクリプトは`kubectl completion bash`コ
bash-completionにはv1とv2のバージョンがあり、v1はBash 3.2（macOSのデフォルト）用で、v2はBash 4.1以降向けです。kubectlの補完スクリプトはbash-completionのv1とBash 3.2では正しく**動作しません**。**bash-completion v2**および**Bash 4.1**が必要になります。したがって、macOSで正常にkubectlの補完を使用するには、Bash 4.1以降をインストールする必要があります([*手順*](https://itnext.io/upgrading-bash-on-macos-7138bd1066ba))。以下の手順では、Bash4.1以降（Bashのバージョンが4.1またはそれより新しいことを指します）を使用することを前提とします。
{{< /warning >}}
### bashのアップグレード
ここではBash 4.1以降の使用を前提としています。Bashのバージョンは下記のコマンドで調べることができます。
```shell
echo $BASH_VERSION
```
バージョンが古い場合、Homebrewを使用してインストールもしくはアップグレードできます。
```shell
brew install bash
```
シェルをリロードし、希望するバージョンを使用していることを確認してください。
```shell
echo $BASH_VERSION $SHELL
```
Homebrewは通常、`/usr/local/bin/bash`にインストールします。
### bash-completionをインストールする
content/ja/docs/tasks/tools/install-minikube.md
+58 -5
View File
@@ -76,12 +76,22 @@ kubectlがインストールされていることを確認してください。
• [VirtualBox](https://www.virtualbox.org/wiki/Downloads)
{{< note >}}
minikubeは、VMではなくホストでKubernetesコンポーネントを実行する`--vm-driver=none`オプションもサポートしています。
Minikubeは、VMではなくホストでKubernetesコンポーネントを実行する`--vm-driver=none`オプションもサポートしています。
このドライバーを使用するには、[Docker](https://www.docker.com/products/docker-desktop)とLinux環境が必要ですが、ハイパーバイザーは不要です。
noneドライバーを使用する場合は、[Docker](https://www.docker.com/products/docker-desktop)からdockerのaptインストールを使用することをおすすめします。
dockerのsnapインストールは、minikubeでは機能しません。
{{< /note >}}
Debian系のLinuxで`none`ドライバーを使用する場合は、snapパッケージではなく`.deb`パッケージを使用してDockerをインストールしてください。snapパッケージはMinikubeでは機能しません。
[Docker](https://www.docker.com/products/docker-desktop)から`.deb`パッケージをダウンロードできます。
{{< caution >}}
`none` VMドライバーは、セキュリティとデータ損失の問題を引き起こす可能性があります。
`--vm-driver=none`を使用する前に、詳細について[このドキュメント](https://minikube.sigs.k8s.io/docs/reference/drivers/none/) を参照してください。
{{< /caution >}}
MinikubeはDockerドライバーと似たような`vm-driver=podman`もサポートしています。Podmanを特権ユーザー権限(root user)で実行することは、コンテナがシステム上の利用可能な機能へ完全にアクセスするための最もよい方法です。
{{< caution >}}
`podman` ドライバーは、rootでコンテナを実行する必要があります。これは、通常のユーザーアカウントが、コンテナの実行に必要とされるすべてのOS機能への完全なアクセスを持っていないためです。
{{< /caution >}}
### パッケージを利用したMinikubeのインストール
@@ -106,6 +116,14 @@ sudo mkdir -p /usr/local/bin/
sudo install minikube /usr/local/bin/
```
### Homebrewを利用したMinikubeのインストール
別の選択肢として、Linux [Homebrew](https://docs.brew.sh/Homebrew-on-Linux)を利用してインストールできます。
```shell
brew install minikube
```
{{% /tab %}}
{{% tab name="macOS" %}}
### kubectlのインストール
@@ -185,6 +203,41 @@ WindowsにMinikubeを手動でインストールするには、[`minikube-window
## インストールの確認
ハイパーバイザーとMinikube両方のインストール成功を確認するため、以下のコマンドをローカルKubernetesクラスターを起動するために実行してください:
{{< note >}}
`minikube start`で`--vm-driver`の設定をするため、次の`<driver_name>`の部分では、インストールしたハイパーバイザーの名前を小文字で入力してください。`--vm-driver`値のすべてのリストは、[specifying the VM driver documentation](https://kubernetes.io/docs/setup/learning-environment/minikube/#specifying-the-vm-driver)で確認できます。
{{< /note >}}
```shell
minikube start --vm-driver=<driver_name>
```
`minikube start`が完了した場合、次のコマンドを実行してクラスターの状態を確認します。
```shell
minikube status
```
クラスターが起動していると、`minikube status`の出力はこのようになります。
```
host: Running
kubelet: Running
apiserver: Running
kubeconfig: Configured
```
選択したハイパーバイザーでMinikubeが動作しているか確認した後は、そのままMinikubeを使い続けることもできます。また、クラスターを停止することもできます。クラスターを停止するためには、次を実行してください。
```shell
minikube stop
```
## ローカル状態のクリーンアップ {#cleanup-local-state}
もし以前に　Minikubeをインストールしていたら、以下のコマンドを実行します。
content/ja/docs/tutorials/_index.md
+1 -3
View File
@@ -17,8 +17,6 @@ content_type: concept
* [Kubernetesの基本](/ja/docs/tutorials/kubernetes-basics/)は、Kubernetesのシステムを理解し、基本的な機能を試すのに役立つ、詳細な対話式のチュートリアルです。
* [Scalable Microservices with Kubernetes (Udacity)](https://www.udacity.com/course/scalable-microservices-with-kubernetes--ud615)
* [Introduction to Kubernetes (edX)](https://www.edx.org/course/introduction-kubernetes-linuxfoundationx-lfs158x#)
* [Hello Minikube](/ja/docs/tutorials/hello-minikube/)
@@ -29,7 +27,7 @@ content_type: concept
## ステートレスアプリケーション
* [クラスター内のアプリケーションにアクセスするために外部IPアドレスを公開する](/docs/tutorials/stateless-application/expose-external-ip-address/)
* [クラスター内のアプリケーションにアクセスするために外部IPアドレスを公開する](/ja/docs/tutorials/stateless-application/expose-external-ip-address/)
* [例: Redisを使用したPHPゲストブックアプリケーションのデプロイ](/docs/tutorials/stateless-application/guestbook/)
content/ja/docs/tutorials/configuration/configure-redis-using-configmap.md
+9 -6
View File
@@ -23,9 +23,10 @@ content_type: tutorial
## {{% heading "prerequisites" %}}
* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
* この例は、バージョン1.14以上での動作を確認しています。
* [ConfigMapを使ったコンテナの設定](/docs/tasks/configure-pod-container/configure-pod-configmap/)を読んで理解しておいてください。
* [ConfigMapを使ったコンテナの設定](/ja/docs/tasks/configure-pod-container/configure-pod-configmap/)を読んで理解しておいてください。
@@ -70,7 +71,7 @@ kustomizationディレクトリを反映して、ConfigMapオブジェクトとP
kubectl apply -k .
```
Examine the created objects by
作成されたオブジェクトを確認します
```shell
> kubectl get -k .
NAME DATA AGE
@@ -97,6 +98,11 @@ kubectl exec -it redis redis-cli
2) "allkeys-lru"
```
作成したPodを削除します:
```shell
kubectl delete pod redis
```
## {{% heading "whatsnext" %}}
@@ -104,6 +110,3 @@ kubectl exec -it redis redis-cli
* [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/)について学ぶ
content/ja/docs/tutorials/hello-minikube.md
+48 -41
View File
@@ -15,7 +15,7 @@ card:
<!-- overview -->
このチュートリアルでは、[Minikube](/docs/getting-started-guides/minikube)とKatacodaを使用して、Kubernetes上でシンプルなHello WorldのNode.jsアプリケーションを動かす方法を紹介します。Katacodaはブラウザで無償のKubernetes環境を提供します。
このチュートリアルでは、[Minikube](/ja/docs/setup/learning-environment/minikube)とKatacodaを使用して、Kubernetes上でシンプルなHello WorldのNode.jsアプリケーションを動かす方法を紹介します。Katacodaはブラウザで無償のKubernetes環境を提供します。
{{< note >}}
[Minikubeをローカルにインストール](/ja/docs/tasks/tools/install-minikube/)している場合もこのチュートリアルを進めることが可能です。
@@ -63,7 +63,7 @@ card:
3. Katacoda環境のみ：ターミナルペーン上部の+ボタンをクリックしてから **Select port to view on Host 1** をクリックしてください。
4. Katacoda環境のみ：`30000`を入力し、**Display Port**をクリックしてください。
4. Katacoda環境のみ：`30000`を入力し、**Display Port**をクリックしてください。
## Deploymentの作成
@@ -81,11 +81,11 @@ Kubernetesの[*Pod*](/ja/docs/concepts/workloads/pods/pod/) は、コンテナ
kubectl get deployments
```
出力:
出力は下記のようになります:
```shell
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
hello-node 1 1 1 1 1m
```
NAME READY UP-TO-DATE AVAILABLE AGE
hello-node 1/1 1 1 1m
```
3. Podを確認します:
@@ -93,9 +93,10 @@ Kubernetesの[*Pod*](/ja/docs/concepts/workloads/pods/pod/) は、コンテナ
```shell
kubectl get pods
```
出力:
```shell
出力は下記のようになります:
```
NAME READY STATUS RESTARTS AGE
hello-node-5f76cf6ccf-br9b5 1/1 Running 0 1m
```
@@ -111,19 +112,19 @@ Kubernetesの[*Pod*](/ja/docs/concepts/workloads/pods/pod/) は、コンテナ
```shell
kubectl config view
```
{{< note >}} `kubectl`コマンドの詳細な情報は[kubectl overview](/docs/user-guide/kubectl-overview/)を参照してください。{{< /note >}}
## Serviceの作成
通常、PodはKubernetesクラスタ内部のIPアドレスからのみアクセスすることができます。`hello-node`コンテナをKubernetesの仮想ネットワークの外部からアクセスするためには、Kubernetesの[*Service*](/ja/docs/concepts/services-networking/service/)としてポッドを公開する必要があります。
通常、PodはKubernetesクラスタ内部のIPアドレスからのみアクセスすることができます。`hello-node`コンテナをKubernetesの仮想ネットワークの外部からアクセスするためには、Kubernetesの[*Service*](/ja/docs/concepts/services-networking/service/)としてPodを公開する必要があります。
1. `kubectl expose` コマンドを使用してPodをインターネットに公開します:
```shell
kubectl expose deployment hello-node --type=LoadBalancer --port=8080
```
`--type=LoadBalancer`フラグはServiceをクラスタ外部に公開したいことを示しています。
2. 作成したServiceを確認します:
@@ -132,9 +133,9 @@ Kubernetesの[*Pod*](/ja/docs/concepts/workloads/pods/pod/) は、コンテナ
kubectl get services
```
出力:
出力は下記のようになります:
```shell
```
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
hello-node LoadBalancer 10.108.144.78 <pending> 8080:30369/TCP 21s
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 23m
@@ -151,13 +152,13 @@ Kubernetesの[*Pod*](/ja/docs/concepts/workloads/pods/pod/) は、コンテナ
4. Katacoda環境のみ：ターミナル画面上部の+ボタンをクリックして **Select port to view on Host 1** をクリックしてください。
5. Katacoda環境のみ：`30369`(Service出力に表示されている`8080`の反対側のポートを参照)を入力し、クリックしてください。
5. Katacoda環境のみ：`8080`の反対側のService出力に、5桁のポート番号が表示されます。このポート番号はランダムに生成されるため、ここで使用するポート番号と異なる場合があります。ポート番号テキストボックスに番号を入力し、ポートの表示をクリックしてください。前の例の場合は、`30369`と入力します。
"Hello World"メッセージが表示されるアプリケーションのブラウザウィンドウが開きます。
## アドオンの有効化
Minikubeはビルトインのアドオンがあり、有効化、無効化、あるいはローカルのKubernetes環境に公開することができます。
Minikubeはビルトインの{{< glossary_tooltip text="アドオン" term_id="addons" >}}があり、有効化、無効化、あるいはローカルのKubernetes環境に公開することができます。
1. サポートされているアドオンをリストアップします:
@@ -165,39 +166,41 @@ Minikubeはビルトインのアドオンがあり、有効化、無効化、あ
minikube addons list
```
出力:
出力は下記のようになります:
```shell
```
addon-manager: enabled
coredns: disabled
dashboard: enabled
default-storageclass: enabled
efk: disabled
freshpod: disabled
heapster: disabled
gvisor: disabled
helm-tiller: disabled
ingress: disabled
kube-dns: enabled
ingress-dns: disabled
logviewer: disabled
metrics-server: disabled
nvidia-driver-installer: disabled
nvidia-gpu-device-plugin: disabled
registry: disabled
registry-creds: disabled
storage-provisioner: enabled
storage-provisioner-gluster: disabled
```
2. ここでは例として`heapster`のアドオンを有効化します:
2. ここでは例として`metrics-server`のアドオンを有効化します:
```shell
minikube addons enable heapster
```
出力:
```shell
heapster was successfully enabled
minikube addons enable metrics-server
```
3. 作成されたポッドとサービスを確認します:
出力は下記のようになります:
```
metrics-server was successfully enabled
```
3. 作成されたPodとサービスを確認します:
```shell
kubectl get pod,svc -n kube-system
@@ -205,33 +208,37 @@ Minikubeはビルトインのアドオンがあり、有効化、無効化、あ
出力:
```shell
```
NAME READY STATUS RESTARTS AGE
pod/heapster-9jttx 1/1 Running 0 26s
pod/coredns-5644d7b6d9-mh9ll 1/1 Running 0 34m
pod/coredns-5644d7b6d9-pqd2t 1/1 Running 0 34m
pod/metrics-server-67fb648c5 1/1 Running 0 26s
pod/etcd-minikube 1/1 Running 0 34m
pod/influxdb-grafana-b29w8 2/2 Running 0 26s
pod/kube-addon-manager-minikube 1/1 Running 0 34m
pod/kube-dns-6dcb57bcc8-gv7mw 3/3 Running 0 34m
pod/kubernetes-dashboard-5498ccf677-cgspw 1/1 Running 0 34m
pod/kube-apiserver-minikube 1/1 Running 0 34m
pod/kube-controller-manager-minikube 1/1 Running 0 34m
pod/kube-proxy-rnlps 1/1 Running 0 34m
pod/kube-scheduler-minikube 1/1 Running 0 34m
pod/storage-provisioner 1/1 Running 0 34m
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/heapster ClusterIP 10.96.241.45 <none> 80/TCP 26s
service/metrics-server ClusterIP 10.96.241.45 <none> 80/TCP 26s
service/kube-dns ClusterIP 10.96.0.10 <none> 53/UDP,53/TCP 34m
service/kubernetes-dashboard NodePort 10.109.29.1 <none> 80:30000/TCP 34m
service/monitoring-grafana NodePort 10.99.24.54 <none> 80:30002/TCP 26s
service/monitoring-influxdb ClusterIP 10.111.169.94 <none> 8083/TCP,8086/TCP 26s
```
4. `heapster`を無効化します:
4. `metrics-server`を無効化します:
```shell
minikube addons disable heapster
minikube addons disable metrics-server
```
出力:
出力は下記のようになります:
```shell
heapster was successfully disabled
```
metrics-server was successfully disabled
```
## クリーンアップ
content/ja/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html
+3 -3
View File
@@ -9,7 +9,7 @@ weight: 10
<body>
<link href="/docs/tutorials/kubernetes-basics/public/css/styles.css" rel="stylesheet">
<link href="/docs/tutorials/kubernetes-basics/public/css/styles.css" rel="stylesheet">
<div class="layout" id="top">
@@ -77,14 +77,14 @@ weight: 10
<div class="col-md-4">
<div class="content__box content__box_fill">
<p><i>マスターはクラスターを管理するために、ノードは実行中のアプリケーションをホストするために使用されます。</i></p>
<p><i>マスターは実行中のアプリケーションをホストするために使用されるノードとクラスターを管理します。</i></p>
</div>
</div>
</div>
<div class="row">
<div class="col-md-8">
<p>Kubernetesにアプリケーションをデプロイするときは、マスターにアプリケーションコンテナを起動するように指示します。マスターはコンテナがクラスターのノードで実行されるようにスケジュールします。<b>ノードは、マスターが公開しているKubernetes APIを使用してマスターと通信します。</b>エンドユーザーは、Kubernetes APIを直接使用して対話することもできます。</p>
<p>Kubernetesにアプリケーションをデプロイするときは、マスターにアプリケーションコンテナを起動するように指示します。マスターはコンテナがクラスターのノードで実行されるようにスケジュールします。<b>ノードは、マスターが公開している<a href="/docs/concepts/overview/kubernetes-api/">Kubernetes API</a>を使用してマスターと通信します。</b>エンドユーザーは、Kubernetes APIを直接使用して対話することもできます。</p>
<p>Kubernetesクラスターは、物理マシンまたは仮想マシンのどちらにも配置できます。Kubernetes開発を始めるためにMinikubeを使うことができます。Minikubeは、ローカルマシン上にVMを作成し、1つのノードのみを含む単純なクラスターをデプロイする軽量なKubernetes実装です。Minikubeは、Linux、macOS、およびWindowsシステムで利用可能です。Minikube CLIは、起動、停止、ステータス、削除など、クラスターを操作するための基本的なブートストラップ操作を提供します。ただし、このチュートリアルでは、Minikubeがプリインストールされた状態で提供されているオンラインのターミナルを使用します。</p>
content/ja/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html
+7
View File
@@ -17,6 +17,13 @@ weight: 20
<main class="content katacoda-content">
<div class="row">
<div class="col-md-12">
<p>
Podは、Kubernetesアプリケーションの基本的な実行単位です。各Podは、クラスターで実行されているワークロードの一部を表します。<a href="/ja/docs/concepts/workloads/pods/pod-overview/#understanding-pods">Podの詳細はこちらです。</a>。
</p>
</div>
</div>
<br>
<div class="katacoda">
<div class="katacoda__alert">
content/ja/docs/tutorials/kubernetes-basics/expose/expose-intro.html
+1 -6
View File
@@ -79,13 +79,8 @@ weight: 10
<li>バージョンタグを埋め込む</li>
<li>タグを使用してオブジェクトを分類する</li>
</ul>
</div>
</div>
<div class="col-md-4">
<div class="content__box content__box_fill">
<p><i>kubectlの<br> <code> --expose </code>を使用して、Deploymentの作成と同時にServiceを作成できます。</i></p>
</div>
</div>
</div>
<br>
content/ja/docs/tutorials/kubernetes-basics/update/update-intro.html
+1 -2
View File
@@ -9,8 +9,7 @@ weight: 10
<body>
<link href="/docs/tutorials/kubernetes-basics/public/css/styles.css" rel="stylesheet">
<link href="https://fonts.googleapis.com/css?family=Roboto+Slab:300,400,700" rel="stylesheet">
<link href="/docs/tutorials/kubernetes-basics/public/css/styles.css" rel="stylesheet">
<div class="layout" id="top">
content/ja/examples/configmap/configmap-multikeys.yaml
+8
View File
@@ -0,0 +1,8 @@
apiVersion: v1
kind: ConfigMap
metadata:
name: special-config
namespace: default
data:
SPECIAL_LEVEL: very
SPECIAL_TYPE: charm
content/ja/examples/configmap/configmaps.yaml
+15
View File
@@ -0,0 +1,15 @@
apiVersion: v1
kind: ConfigMap
metadata:
name: special-config
namespace: default
data:
special.how: very
---
apiVersion: v1
kind: ConfigMap
metadata:
name: env-config
namespace: default
data:
log_level: INFO
content/ja/examples/pods/pod-configmap-env-var-valueFrom.yaml
+21
View File
@@ -0,0 +1,21 @@
apiVersion: v1
kind: Pod
metadata:
name: dapi-test-pod
spec:
containers:
- name: test-container
image: k8s.gcr.io/busybox
command: [ "/bin/sh", "-c", "echo $(SPECIAL_LEVEL_KEY) $(SPECIAL_TYPE_KEY)" ]
env:
- name: SPECIAL_LEVEL_KEY
valueFrom:
configMapKeyRef:
name: special-config
key: SPECIAL_LEVEL
- name: SPECIAL_TYPE_KEY
valueFrom:
configMapKeyRef:
name: special-config
key: SPECIAL_TYPE
restartPolicy: Never
content/ja/examples/pods/pod-configmap-envFrom.yaml
+13
View File
@@ -0,0 +1,13 @@
apiVersion: v1
kind: Pod
metadata:
name: dapi-test-pod
spec:
containers:
- name: test-container
image: k8s.gcr.io/busybox
command: [ "/bin/sh", "-c", "env" ]
envFrom:
- configMapRef:
name: special-config
restartPolicy: Never
content/ja/examples/pods/pod-configmap-volume-specific-key.yaml
+20
View File
@@ -0,0 +1,20 @@
apiVersion: v1
kind: Pod
metadata:
name: dapi-test-pod
spec:
containers:
- name: test-container
image: k8s.gcr.io/busybox
command: [ "/bin/sh","-c","cat /etc/config/keys" ]
volumeMounts:
- name: config-volume
mountPath: /etc/config
volumes:
- name: config-volume
configMap:
name: special-config
items:
- key: SPECIAL_LEVEL
path: keys
restartPolicy: Never
content/ja/examples/pods/pod-configmap-volume.yaml
+18
View File
@@ -0,0 +1,18 @@
apiVersion: v1
kind: Pod
metadata:
name: dapi-test-pod
spec:
containers:
- name: test-container
image: k8s.gcr.io/busybox
command: [ "/bin/sh", "-c", "ls /etc/config/" ]
volumeMounts:
- name: config-volume
mountPath: /etc/config
volumes:
- name: config-volume
configMap:
# コンテナに追加するファイルを含むConfigMapの名前を提供する
name: special-config
restartPolicy: Never

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