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

resolve conflict

Browse Source
This commit is contained in:
inductor
2020-06-15 02:59:15 +09:00
parent c9472ad4b6 ce768c84b7
commit 298382169c
2451 changed files with 127381 additions and 564546 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/ja/docs/concepts/_index.md
+8 -7
View File
@@ -1,17 +1,17 @@
---
title: コンセプト
main_menu: true
content_template: templates/concept
content_type: concept
weight: 40
---
{{% capture overview %}}
<!-- overview -->
本セクションは、Kubernetesシステムの各パートと、{{< glossary_tooltip text="クラスター" term_id="cluster" length="all" >}}を表現するためにKubernetesが使用する抽象概念について学習し、Kubernetesの仕組みをより深く理解するのに役立ちます。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## 概要
@@ -59,12 +59,13 @@ Kubernetesのマスターは、クラスターの望ましい状態を維持す
クラスターのノードは、アプリケーションとクラウドワークフローを実行するマシン(VM、物理サーバーなど)です。Kubernetesのマスターは各ノードを制御します。運用者自身がノードと直接対話することはほとんどありません。
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
コンセプトページを追加したい場合は、
[ページテンプレートの使用](/docs/home/contribute/page-templates/)
のコンセプトページタイプとコンセプトテンプレートに関する情報を確認してください。
{{% /capture %}}
content/ja/docs/concepts/architecture/cloud-controller.md
+5 -5
View File
@@ -1,10 +1,10 @@
---
title: クラウドコントローラーマネージャーとそのコンセプト
content_template: templates/concept
content_type: concept
weight: 30
---
{{% capture overview %}}
<!-- overview -->
クラウドコントローラマネージャー(CCM)のコンセプト(バイナリと混同しないでください)は、もともとクラウドベンダー固有のソースコードと、Kubernetesのコアソースコードを独立して進化させることが出来るように作られました。クラウドコントローラーマネージャーは、Kubernetesコントローラーマネージャー、APIサーバー、そしてスケジューラーのような他のマスターコンポーネントと並行して動きます。またKubernetesのアドオンとしても動かすことができ、その場合はKubernetes上で動きます。
@@ -16,10 +16,10 @@ weight: 30
![Pre CCM Kube Arch](/images/docs/pre-ccm-arch.png)
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## 設計
@@ -235,4 +235,4 @@ rules:
CCMを設定、動かすための完全な手順は[こちら](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager)で提供されています。
{{% /capture %}}
content/ja/docs/concepts/architecture/master-node-communication.md
+5 -5
View File
@@ -1,18 +1,18 @@
---
title: マスターとノード間の通信
content_template: templates/concept
content_type: concept
weight: 20
---
{{% capture overview %}}
<!-- overview -->
本ドキュメントでは、KubernetesにおけるMaster(実態はAPIサーバー)及びクラスター間のコミュニケーション経路についてまとめます。
この文書の目的は、信頼できないネットワーク上（またはクラウドプロバイダ上の完全にパブリックなIP上）でクラスタを実行できるように、ユーザーがインストールをカスタマイズしてネットワーク構成を強化できるようにすることです。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## クラスターからマスターへの通信
@@ -69,4 +69,4 @@ Kubernetesはマスターからクラスターへの通信経路を保護する
SSHトンネルは現在非推奨なので、自分がしていることが分からない限り、使用しないでください。この通信チャネルに代わるものが設計されています。
{{% /capture %}}
content/ja/docs/concepts/architecture/nodes.md
+5 -5
View File
@@ -1,17 +1,17 @@
---
title: ノード
content_template: templates/concept
content_type: concept
weight: 10
---
{{% capture overview %}}
<!-- overview -->
ノードは、以前には `ミニオン` としても知られていた、Kubernetesにおけるワーカーマシンです。1つのノードはクラスターの性質にもよりますが、1つのVMまたは物理的なマシンです。各ノードには[Pod](/ja/docs/concepts/workloads/pods/pod/)を動かすために必要なサービスが含まれており、マスターコンポーネントによって管理されています。ノード上のサービスには[コンテナランタイム](/ja/docs/concepts/overview/components/#container-runtime)、kubelet、kube-proxyが含まれています。詳細については、設計ドキュメントの[Kubernetes Node](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node)セクションをご覧ください。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## ノードのステータス
@@ -219,4 +219,4 @@ Pod以外のプロセス用にリソースを明示的に予約したい場合
NodeはKubernetesのREST APIにおけるトップレベルのリソースです。APIオブジェクトに関する詳細は以下の記事にてご覧いただけます:
[Node APIオブジェクト](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core).
{{% /capture %}}
content/ja/docs/concepts/cluster-administration/cluster-administration-overview.md
+5 -5
View File
@@ -1,15 +1,15 @@
---
reviewers:
title: クラスター管理の概要
content_template: templates/concept
content_type: concept
weight: 10
---
{{% capture overview %}}
<!-- overview -->
このページはKubernetesクラスターの作成や管理者向けの内容です。Kubernetesのコア[コンセプト](/ja/docs/concepts/)についてある程度精通していることを前提とします。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## クラスターのプランニング
Kubernetesクラスターの計画、セットアップ、設定の例を知るには[設定](/ja/docs/setup/)のガイドを参照してください。この記事で列挙されているソリューションは*ディストリビューション* と呼ばれます。
@@ -64,6 +64,6 @@ Kubernetesクラスターの計画、セットアップ、設定の例を知る
* [クラスターアクティビィのロギングと監視](/docs/concepts/cluster-administration/logging/)では、Kubernetesにおけるロギングがどのように行われ、どう実装されているかについて解説します。
{{% /capture %}}
content/ja/docs/concepts/cluster-administration/controller-metrics.md
+5 -5
View File
@@ -1,15 +1,15 @@
---
title: コントローラーマネージャーの指標
content_template: templates/concept
content_type: concept
weight: 100
---
{{% capture overview %}}
<!-- overview -->
コントローラーマネージャーの指標は、コントローラー内部のパフォーマンスについての重要で正確な情報と、クラウドコントローラーの状態についての情報を提供します。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## コントローラーマネージャーの指標とは何か
コントローラーマネージャーの指標は、コントローラー内部のパフォーマンスについての重要で正確な情報と、クラウドコントローラーの状態についての情報を提供します。
@@ -39,4 +39,4 @@ cloudprovider_gce_api_request_duration_seconds { request = "list_disk"}
本番環境ではこれらの指標を定期的に収集し、なんらかの時系列データベースで使用できるようにprometheusやその他の指標のスクレイパーを構成することが推奨されます。
{{% /capture %}}
content/ja/docs/concepts/cluster-administration/networking.md
+8 -7
View File
@@ -1,10 +1,10 @@
---
title: クラスターのネットワーク
content_template: templates/concept
content_type: concept
weight: 50
---
{{% capture overview %}}
<!-- overview -->
ネットワークはKubernetesにおける中心的な部分ですが、どのように動作するかを正確に理解することは難解な場合もあります。
Kubernetesには、4つの異なる対応すべきネットワークの問題があります:
@@ -14,10 +14,10 @@ Kubernetesには、4つの異なる対応すべきネットワークの問題が
3. Podからサービスへの通信：これは[Service](/ja/docs/concepts/services-networking/service/)でカバーされています。
4. 外部からサービスへの通信：これは[Service](/ja/docs/concepts/services-networking/service/)でカバーされています。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
Kubernetesは、言ってしまえばアプリケーション間でマシンを共有するためのものです。通常、マシンを共有するには、2つのアプリケーションが同じポートを使用しないようにする必要があります。
複数の開発者間でポートを調整することは、大規模に行うことは非常に難しく、ユーザーが制御できないクラスターレベルの問題に見合うことがあります。
@@ -282,10 +282,11 @@ Weave Net runs as a [CNI plug-in](https://www.weave.works/docs/net/latest/cni-pl
or stand-alone. In either version, it doesn't require any configuration or extra code
to run, and in both cases, the network provides one IP address per pod - as is standard for Kubernetes.
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
ネットワークモデルの初期設計とその根拠、および将来の計画については、[ネットワーク設計ドキュメント](https://git.k8s.io/community/contributors/design-proposals/network/networking.md)で詳細に説明されています。
{{% /capture %}}
content/ja/docs/concepts/configuration/assign-pod-node.md
+8 -7
View File
@@ -1,20 +1,20 @@
---
title: Node上へのPodのスケジューリング
content_template: templates/concept
content_type: concept
weight: 30
---
{{% capture overview %}}
<!-- overview -->
[Pod](/ja/docs/concepts/workloads/pods/pod/)が稼働する[Node](/ja/docs/concepts/architecture/nodes/)を特定のものに指定したり、優先条件を指定して制限することができます。
これを実現するためにはいくつかの方法がありますが、推奨されている方法は[ラベルでの選択](/ja/docs/concepts/overview/working-with-objects/labels/)です。
スケジューラーが最適な配置を選択するため、一般的にはこのような制限は不要です(例えば、複数のPodを別々のNodeへデプロイしたり、Podを配置する際にリソースが不十分なNodeにはデプロイされないことが挙げられます)が、
SSDが搭載されているNodeにPodをデプロイしたり、同じアベイラビリティーゾーン内で通信する異なるサービスのPodを同じNodeにデプロイする等、柔軟な制御が必要なこともあります。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## nodeSelector
@@ -357,9 +357,10 @@ spec:
上記のPodはkube-01という名前のNodeで稼働します。
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
[Taints](/docs/concepts/configuration/taint-and-toleration/)を使うことで、NodeはPodを追い出すことができます。
@@ -367,4 +368,4 @@ spec:
[Inter-Pod Affinity/Anti-Affinity](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)
には、Taintsの要点に関して様々な背景が紹介されています。
{{% /capture %}}
content/ja/docs/concepts/configuration/overview.md
+5 -5
View File
@@ -1,16 +1,16 @@
---
title: 設定のベストプラクティス
content_template: templates/concept
content_type: concept
weight: 10
---
{{% capture overview %}}
<!-- overview -->
このドキュメントでは、ユーザーガイド、入門マニュアル、および例を通して紹介されている設定のベストプラクティスを中心に説明します。
このドキュメントは生ものです。このリストには載っていないが他の人に役立つかもしれない何かについて考えている場合、IssueまたはPRを遠慮なく作成してください。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## 一般的な設定のTips
- 構成を定義する際には、最新の安定したAPIバージョンを指定してください。
@@ -98,6 +98,6 @@ weight: 10
- `get`や`delete`を行う際は、特定のオブジェクト名を指定するのではなくラベルセレクターを使いましょう。[ラベルセレクター](/ja/docs/concepts/overview/working-with-objects/labels/#label-selectors)と[ラベルの効果的な使い方](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively)のセクションを参照してください。
{{% /capture %}}
content/ja/docs/concepts/containers/container-environment.md
+8 -7
View File
@@ -1,17 +1,17 @@
---
title: コンテナ環境
content_template: templates/concept
content_type: concept
weight: 20
---
{{% capture overview %}}
<!-- overview -->
このページでは、コンテナ環境で利用可能なリソースについて説明します。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## コンテナ環境
@@ -45,11 +45,12 @@ FOO_SERVICE_PORT=<サービスが実行されているポート>
サービスは専用のIPアドレスを持ち、[DNSアドオン](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/)が有効の場合、DNSを介してコンテナで利用可能です。
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* [コンテナライフサイクルフック](/docs/concepts/containers/container-lifecycle-hooks/)の詳細
* [コンテナライフサイクルイベントへのハンドラー紐付け](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)のハンズオン
{{% /capture %}}
content/ja/docs/concepts/containers/container-lifecycle-hooks.md
+8 -7
View File
@@ -1,17 +1,17 @@
---
title: コンテナライフサイクルフック
content_template: templates/concept
content_type: concept
weight: 30
---
{{% capture overview %}}
<!-- overview -->
このページでは、kubeletにより管理されるコンテナがコンテナライフサイクルフックフレームワークを使用して、管理ライフサイクル中にイベントによって引き起こされたコードを実行する方法について説明します。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## 概要
@@ -93,12 +93,13 @@ Events:
1m 22s 2 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Warning FailedPostStartHook
```
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* [コンテナ環境](/ja/docs/concepts/containers/container-environment/)の詳細
* [コンテナライフサイクルイベントへのハンドラー紐付け](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)のハンズオン
{{% /capture %}}
content/ja/docs/concepts/containers/runtime-class.md
+5 -5
View File
@@ -1,11 +1,11 @@
---
reviewers:
title: ランタイムクラス(Runtime Class)
content_template: templates/concept
content_type: concept
weight: 20
---
{{% capture overview %}}
<!-- overview -->
{{< feature-state for_k8s_version="v1.14" state="beta" >}}
@@ -15,10 +15,10 @@ weight: 20
RuntimeClassはKubernetes1.14のβ版アップグレードにおいて*破壊的な* 変更を含んでいます。もしユーザーがKubernetes1.14以前のバージョンを使っていた場合、[RuntimeClassのα版からβ版へのアップグレード](#upgrading-runtimeclass-from-alpha-to-beta)を参照してください。
{{< /warning >}}
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## RuntimeClassについて
@@ -139,4 +139,4 @@ RuntimeClassのβ版の機能は、下記の変更点を含みます。
```
- `runtimeHandler`の指定がないか、もしくは空文字の場合や、ハンドラー名に`.`文字列が使われている場合はα版のRuntimeClassにおいてもはや有効ではありません。正しい形式のハンドラー設定に変更しなくてはなりません(先ほど記載した内容を確認ください)。
{{% /capture %}}
content/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md
+8 -7
View File
@@ -1,18 +1,18 @@
---
title: アグリゲーションレイヤーを使ったKubernetes APIの拡張
content_template: templates/concept
content_type: concept
weight: 20
---
{{% capture overview %}}
<!-- overview -->
アグリゲーションレイヤーを使用すると、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" >}}に新しい種類のオブジェクトを認識させる方法です。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## アグリゲーションレイヤー
@@ -27,14 +27,15 @@ kube-apiserverとの間を5秒以内に往復するためには、ディスカ
拡張APIサーバーがそのレイテンシ要件を達成できない場合は、その要件を満たすように変更することを検討してください。また、kube-apiserverで`EnableAggregatedDiscoveryTimeout=false` [フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を設定することで、タイムアウト制限を無効にすることができます。この非推奨のフィーチャーゲートは将来のリリースで削除される予定です。
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* アグリゲーターをあなたの環境で動かすには、まず[アグリゲーションレイヤーを設定](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/)します
* そして、アグリゲーションレイヤーと一緒に動作させるために[extension api-serverをセットアップ](/docs/tasks/access-kubernetes-api/setup-extension-api-server/)します
* また、[Custom Resource Definitionを使いKubernetes APIを拡張する](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/)方法を学んで下さい
* [APIService](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#apiservice-v1-apiregistration-k8s-io)の仕様をお読み下さい
{{% /capture %}}
content/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources.md
+8 -7
View File
@@ -1,16 +1,16 @@
---
title: カスタムリソース
content_template: templates/concept
content_type: concept
weight: 20
---
{{% capture overview %}}
<!-- overview -->
*カスタムリソース* はKubernetes APIの拡張です。このページでは、いつKubernetesのクラスターにカスタムリソースを追加するべきなのか、そしていつスタンドアローンのサービスを利用するべきなのかを議論します。カスタムリソースを追加する2つの方法と、それらの選択方法について説明します。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## カスタムリソース
@@ -213,11 +213,12 @@ Kubernetesの[クライアントライブラリー](/docs/reference/using-api/cl
- 自作のRESTクライアント
- [Kubernetesクライアント生成ツール](https://github.com/kubernetes/code-generator)を使い生成したクライアント(生成は高度な作業ですが、一部のプロジェクトは、CRDまたはAAとともにクライアントを提供する場合があります)
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* [Kubernetes APIをアグリゲーションレイヤーで拡張する方法](/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)について学ぶ
* [Kubernetes APIをCustomResourceDefinitionで拡張する方法](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/)について学ぶ
{{% /capture %}}
content/ja/docs/concepts/extend-kubernetes/extend-cluster.md
+8 -7
View File
@@ -1,10 +1,10 @@
---
title: Kubernetesクラスターの拡張
content_template: templates/concept
content_type: concept
weight: 10
---
{{% capture overview %}}
<!-- overview -->
Kubernetesは柔軟な設定が可能で、高い拡張性を持っています。
結果として、Kubernetesのプロジェクトソースコードをフォークしたり、パッチを当てて利用することは滅多にありません。
@@ -13,9 +13,9 @@ Kubernetesは柔軟な設定が可能で、高い拡張性を持っています
管理しているKubernetesクラスターを、動作環境の要件にどのように適合させるべきかを理解したい{{< glossary_tooltip text="クラスター管理者" term_id="cluster-operator" >}}を対象にしています。
将来の {{< glossary_tooltip text="プラットフォーム開発者" term_id="platform-developer" >}} 、またはKubernetesプロジェクトの{{< glossary_tooltip text="コントリビューター" term_id="contributor" >}}にとっても、どのような拡張のポイントやパターンが存在するのか、また、それぞれのトレードオフや制限事項を学ぶための導入として役立つでしょう。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## 概要
@@ -152,9 +152,10 @@ Kubernetesはいくつかのビルトイン認証方式と、それらが要件
スケジューラは[Webhook](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/scheduler_extender.md)もサポートしており、Webhookバックエンド（スケジューラーエクステンション）を通じてPodを配置するために選択されたノードをフィルタリング、優先度付けすることが可能です。
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* [カスタムリソース](/docs/concepts/api-extension/custom-resources/)についてより深く学ぶ
* [動的Admission control](/docs/reference/access-authn-authz/extensible-admission-controllers/)について学ぶ
@@ -164,4 +165,4 @@ Kubernetesはいくつかのビルトイン認証方式と、それらが要件
* [kubectlプラグイン](/docs/tasks/extend-kubectl/kubectl-plugins/)について学ぶ
* [オペレーターパターン](/docs/concepts/extend-kubernetes/operator/)について学ぶ
{{% /capture %}}
content/ja/docs/concepts/extend-kubernetes/operator.md
+8 -7
View File
@@ -1,17 +1,17 @@
---
title: オペレーターパターン
content_template: templates/concept
content_type: concept
weight: 30
---
{{% capture overview %}}
<!-- overview -->
オペレーターはサードパーティのアプリケーション、コンポーネントを管理するためのリソースを活用する、Kubernetesへのソフトウェア拡張です。
オペレーターは、特に[制御ループ](/docs/concepts/#kubernetes-control-plane)のようなKubernetesが持つ仕組みに準拠しています。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## モチベーション
@@ -79,9 +79,10 @@ kubectl edit SampleDB/example-database # 手動でいくつかの設定を変更
オペレーター（すなわち、コントローラー）はどの言語/ランタイムでも実装でき、[Kubernetes APIのクライアント](/docs/reference/using-api/client-libraries/)として機能させることができます。
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* [Custom Resources](/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources/)をより深く学びます
* ユースケースに合わせた、既製のオペレーターを[OperatorHub.io](https://operatorhub.io/)から見つけます
@@ -94,4 +95,4 @@ kubectl edit SampleDB/example-database # 手動でいくつかの設定を変更
* オペレーターパターンを紹介している[CoreOSオリジナル記事](https://coreos.com/blog/introducing-operators.html)を読みます
* Google Cloudが出したオペレーター作成のベストプラクティス[記事](https://cloud.google.com/blog/products/containers-kubernetes/best-practices-for-building-kubernetes-operators-and-stateful-apps)を読みます
{{% /capture %}}
content/ja/docs/concepts/overview/components.md
+8 -7
View File
@@ -1,13 +1,13 @@
---
title: Kubernetesのコンポーネント
content_template: templates/concept
content_type: concept
weight: 20
card:
name: concepts
weight: 20
---
{{% capture overview %}}
<!-- overview -->
Kubernetesをデプロイすると、クラスターが展開されます。
{{< glossary_definition term_id="cluster" length="all" prepend="クラスターは、">}}
@@ -17,9 +17,9 @@ Kubernetesをデプロイすると、クラスターが展開されます。
![Kubernetesのコンポーネント](/images/docs/components-of-kubernetes.png)
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## マスターコンポーネント
@@ -112,10 +112,11 @@ Kubernetesによって開始されたコンテナは、DNS検索にこのDNSサ
[クラスターレベルログ](/docs/concepts/cluster-administration/logging/)メカニズムは、コンテナのログを、検索／参照インターフェイスを備えた中央ログストアに保存します。
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* [ノード](/ja/docs/concepts/architecture/nodes/)について学ぶ
* [コントローラー](/docs/concepts/architecture/controller/)について学ぶ
* [kube-scheduler](/ja/docs/concepts/scheduling/kube-scheduler/)について学ぶ
* etcdの公式 [ドキュメント](https://etcd.io/docs/)を読む
{{% /capture %}}
content/ja/docs/concepts/overview/kubernetes-api.md
+5 -5
View File
@@ -1,14 +1,14 @@
---
reviewers:
title: Kubernetes API
content_template: templates/concept
content_type: concept
weight: 30
card:
name: concepts
weight: 30
---
{{% capture overview %}}
<!-- overview -->
全般的なAPIの規則は、[API規則ドキュメント](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md)に記載されています。
@@ -22,9 +22,9 @@ Kubernetes APIは、システムの宣言的設定スキーマの基礎として
Kubernetesそれ自身は複数のコンポーネントから構成されており、APIを介して連携しています。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## APIの変更
@@ -113,4 +113,4 @@ APIグループは、RESTのパスとシリアライズされたオブジェク
DaemonSets、Deployments、HorizontalPodAutoscalers、Ingresses、JobsReplicaSets、そしてReplicaSetsはデフォルトで有効です。
その他の拡張リソースは、APIサーバーの`--runtime-config`を設定することで有効化できます。`--runtime-config`はカンマ区切りの複数の値を設定可能です。例えば、deploymentsとingressを無効化する場合、`--runtime-config=extensions/v1beta1/deployments=false,extensions/v1beta1/ingresses=false`と設定します。
{{% /capture %}}
content/ja/docs/concepts/overview/what-is-kubernetes.md
+8 -7
View File
@@ -1,17 +1,17 @@
---
title: Kubernetesとは何か？
content_template: templates/concept
content_type: concept
weight: 10
card:
name: concepts
weight: 10
---
{{% capture overview %}}
<!-- overview -->
このページでは、Kubernetesの概要について説明します。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
Kubernetesは、宣言的な構成管理と自動化を促進し、コンテナ化されたワークロードやサービスを管理するための、ポータブルで拡張性のあるオープンソースプラットホームです。
Kubernetesは膨大で、急速に成長しているエコシステムを備えており、それらのサービス、サポート、ツールは幅広い形で利用可能です。
@@ -94,11 +94,12 @@ Kubernetesは...
**Kubernetes** という名前はギリシャ語で *操舵手* や *パイロット* という意味があり、*知事* や[サイバネティックス](http://www.etymonline.com/index.php?term=cybernetics)の語源にもなっています。*K8s* は、8文字の「ubernete」を「8」に置き換えた略語です。
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* [はじめる](/docs/setup/)準備はできましたか？
* さらなる詳細については、[Kubernetesのドキュメント](/ja/docs/home/)を御覧ください。
{{% /capture %}}
content/ja/docs/concepts/overview/working-with-objects/annotations.md
+14 -16
View File
@@ -1,20 +1,20 @@
---
title: アノテーション(Annotations)
content_template: templates/concept
content_type: concept
weight: 50
---
{{% capture overview %}}
<!-- overview -->
ユーザーは、識別用途でない任意のメタデータをオブジェクトに割り当てるためにアノテーションを使用できます。ツールやライブラリなどのクライアントは、このメタデータを取得できます。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## オブジェクトにメタデータを割り当てる
ユーザーは、Kubernetesオブジェクトに対してラベルやアノテーションの両方またはどちらか一方を割り当てることができます。
ラベルはオブジェクトの選択や、特定の条件を満たしたオブジェクトの集合を探すことに使うことができます。
それと対照的に、アノテーションはオブジェクトを識別、または選択するために使用されません。
アノテーション内のメタデータは大小様々で、構造化されているものや、そうでないものも設定でき、ラベルでは許可されていない文字も含むことができます。
ラベルはオブジェクトの選択や、特定の条件を満たしたオブジェクトの集合を探すことに使うことができます。
それと対照的に、アノテーションはオブジェクトを識別、または選択するために使用されません。
アノテーション内のメタデータは大小様々で、構造化されているものや、そうでないものも設定でき、ラベルでは許可されていない文字も含むことができます。
アノテーションは、ラベルと同様に、キーとバリューのマップとなります。
@@ -49,15 +49,15 @@ weight: 50
## 構文と文字セット
_アノテーション_ はキーとバリューのペアです。有効なアノテーションのキーの形式は2つのセグメントがあります。
プレフィックス(オプション)と名前で、それらはスラッシュ`/`で区切られます。
名前セグメントは必須で、63文字以下である必要があり、文字列の最初と最後は英数字(`[a-z0-9A-Z]`)と、文字列の間にダッシュ(`-`)、アンダースコア(`_`)、ドット(`.`)を使うことができます。
_アノテーション_ はキーとバリューのペアです。有効なアノテーションのキーの形式は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の構成ファイルは次のとおりです:
@@ -76,9 +76,7 @@ spec:
- containerPort: 80
```
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
[ラベルとセレクター](/ja/docs/concepts/overview/working-with-objects/labels/)について学習してください。
{{% /capture %}}
content/ja/docs/concepts/overview/working-with-objects/common-labels.md
+7 -8
View File
@@ -1,15 +1,15 @@
---
title: 推奨ラベル(Recommended Labels)
content_template: templates/concept
content_type: concept
---
{{% capture overview %}}
<!-- overview -->
ユーザーはkubectlやダッシュボード以外に、多くのツールでKubernetesオブジェクトの管理と可視化ができます。共通のラベルセットにより、全てのツールにおいて解釈可能な共通のマナーに沿ってオブジェクトを表現することで、ツールの相互運用を可能にします。
ツール化に対するサポートに加えて、推奨ラベルはクエリ可能な方法でアプリケーションを表現します。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
メタデータは、_アプリケーション_ のコンセプトを中心に構成されています。KubernetesはPaaS(Platform as a Service)でなく、アプリケーションの公式な概念を持たず、またそれを強制することはありません。
そのかわり、アプリケーションは、非公式で、メタデータによって表現されています。単一のアプリケーションが有する項目に対する定義は厳密に決められていません。
@@ -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のために使われます。
@@ -153,4 +153,3 @@ metadata:
MySQLの`StatefulSet`と`Service`により、MySQLとWordPressに関するより広範な情報が含まれていることに気づくでしょう。
{{% /capture %}}
content/ja/docs/concepts/overview/working-with-objects/kubernetes-objects.md
+8 -7
View File
@@ -1,17 +1,17 @@
---
title: Kubernetesオブジェクトを理解する
content_template: templates/concept
content_type: concept
weight: 10
card:
name: concepts
weight: 40
---
{{% capture overview %}}
<!-- overview -->
このページでは、KubernetesオブジェクトがKubernetes APIでどのように表現されているか、またそれらを`.yaml`フォーマットでどのように表現するかを説明します。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Kubernetesオブジェクトを理解する
*Kubernetesオブジェクト* は、Kubernetes上で永続的なエンティティです。Kubernetesはこれらのエンティティを使い、クラスターの状態を表現します。具体的に言うと、下記のような内容が表現出来ます:
@@ -66,13 +66,14 @@ Kubernetesオブジェクトを`.yaml`ファイルに記載して作成する場
`spec`の正確なフォーマットは、Kubernetesオブジェクトごとに異なり、オブジェクトごとに特有な入れ子のフィールドを持っています。[Kubernetes API リファレンス](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)が、Kubernetesで作成出来る全てのオブジェクトに関するspecのフォーマットを探すのに役立ちます。
例えば、`Pod`オブジェクトに関する`spec`のフォーマットは[PodSpec v1 core](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)を、また`Deployment`オブジェクトに関する`spec`のフォーマットは[DeploymentSpec v1 apps](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deploymentspec-v1-apps)をご確認ください。
{{% /capture %}}
{{% capture whatsnext %}}
## {{% 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/)を学びましょう。
{{% /capture %}}
content/ja/docs/concepts/overview/working-with-objects/labels.md
+5 -5
View File
@@ -1,10 +1,10 @@
---
title: ラベル(Labels)とセレクター(Selectors)
content_template: templates/concept
content_type: concept
weight: 40
---
{{% capture overview %}}
<!-- overview -->
_ラベル(Labels)_ はPodなどのオブジェクトに割り当てられたキーとバリューのペアです。
ラベルはユーザーに関連した意味のあるオブジェクトの属性を指定するために使われることを目的としています。しかしKubernetesのコアシステムに対して直接的にその意味を暗示するものではありません。
@@ -22,10 +22,10 @@ _ラベル(Labels)_ はPodなどのオブジェクトに割り当てられたキ
ラベルは効率的な検索・閲覧を可能にし、UIやCLI上での利用に最適です。
識別用途でない情報は、[アノテーション](/ja/docs/concepts/overview/working-with-objects/annotations/)を用いて記録されるべきです。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## ラベルを使う動機
@@ -240,4 +240,4 @@ selector:
ラベルを選択するための1つのユースケースはPodがスケジュールできるNodeのセットを制限することです。
さらなる情報に関しては、[Node選定](/ja/docs/concepts/configuration/assign-pod-node/) のドキュメントを参照してください。
{{% /capture %}}
content/ja/docs/concepts/overview/working-with-objects/names.md
+5 -7
View File
@@ -1,11 +1,11 @@
---
reviewers:
title: オブジェクトの名前とID
content_template: templates/concept
content_type: concept
weight: 20
---
{{% capture overview %}}
<!-- overview -->
クラスター内の各オブジェクトには、そのタイプのリソースに固有の[_名前_](#names)があります。すべてのKubernetesオブジェクトには、クラスター全体で一意の[_UID_](#uids)もあります。
@@ -13,9 +13,9 @@ weight: 20
ユーザーが一意ではない属性を付与するために、Kubernetesは[ラベル](/ja/docs/concepts/overview/working-with-objects/labels/)と[アノテーション](/ja/docs/concepts/overview/working-with-objects/annotations/)を提供しています。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## 名前 {#names}
@@ -74,8 +74,6 @@ spec:
Kubernetes UIDは、UUIDのことを指します。
UUIDは、ISO/IEC 9834-8およびITU-T X.667として標準化されています。
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* Kubernetesの[ラベル](/ja/docs/concepts/overview/working-with-objects/labels/)についてお読みください。
* [Kubernetesの識別子と名前](https://git.k8s.io/community/contributors/design-proposals/architecture/identifiers.md)デザインドキュメントをご覧ください。
{{% /capture %}}
content/ja/docs/concepts/overview/working-with-objects/namespaces.md
+27 -30
View File
@@ -1,41 +1,41 @@
---
title: Namespace(名前空間)
content_template: templates/concept
content_type: concept
weight: 30
---
{{% capture overview %}}
<!-- overview -->
Kubernetesは、同一の物理クラスター上で複数の仮想クラスターの動作をサポートします。
この仮想クラスターをNamespaceと呼びます。
{{% /capture %}}
Kubernetesは、同一の物理クラスター上で複数の仮想クラスターの動作をサポートします。
この仮想クラスターをNamespaceと呼びます。
{{% capture body %}}
<!-- body -->
## 複数のNamespaceを使う時
Namespaceは、複数のチーム・プロジェクトにまたがる多くのユーザーがいる環境での使用を目的としています。
Namespaceは、複数のチーム・プロジェクトにまたがる多くのユーザーがいる環境での使用を目的としています。
数人から数十人しかユーザーのいないクラスターに対して、あなたはNamespaceを作成したり、考える必要は全くありません。
Kubernetesが提供するNamespaceの機能が必要となった時に、Namespaceの使用を始めてください。
Kubernetesが提供する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内でリソースを区別するためには[ラベル](/ja/docs/concepts/overview/working-with-objects/labels/)を使用してください。
同じアプリケーションの異なるバージョンなど、少し違うリソースをただ分割するだけに、複数のNamespaceを使う必要はありません。
同一のNamespace内でリソースを区別するためには[ラベル](/ja/docs/concepts/overview/working-with-objects/labels/)を使用してください。
## Namespaceを利用する
Namespaceの作成と削除方法は[Namespaceの管理ガイドドキュメント](/docs/tasks/administer-cluster/namespaces/)に記載されています。
Namespaceの作成と削除方法は[Namespaceの管理ガイドドキュメント](/docs/tasks/administer-cluster/namespaces/)に記載されています。
### Namespaceの表示
ユーザーは、以下の方法で単一クラスター内の現在のNamespaceの一覧を表示できます。
ユーザーは、以下の方法で単一クラスター内の現在のNamespaceの一覧を表示できます。
```shell
kubectl get namespace
@@ -49,9 +49,9 @@ 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の設定
@@ -67,7 +67,7 @@ kubectl get pods --namespace=<insert-namespace-name-here>
### Namespace設定の永続化
ユーザーはあるコンテキストのその後のコマンドで使うために、コンテキスト内で永続的にNamespaceを保存できます。
ユーザーはあるコンテキストのその後のコマンドで使うために、コンテキスト内で永続的にNamespaceを保存できます。
```shell
kubectl config set-context --current --namespace=<insert-namespace-name-here>
@@ -77,18 +77,18 @@ kubectl config view --minify | grep namespace:
## NamespaceとDNS
ユーザーが[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)を指定する必要があります。
ユーザーが[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](/ja/docs/concepts/architecture/nodes/)やPersistentVolumeのような低レベルのリソースはどのNamespaceにも属していません。
ほとんどのKubernetesリソース(例えば、Pod、Service、ReplicationControllerなど)はいくつかのNamespaceにあります。
しかしNamespaceのリソースそれ自体は単一のNamespace内にありません。
そして[Node](/ja/docs/concepts/architecture/nodes/)やPersistentVolumeのような低レベルのリソースはどのNamespaceにも属していません。
どのKubernetesリソースがNamespaceに属しているか、属していないかを見るためには、以下のコマンドで確認できます。
どのKubernetesリソースがNamespaceに属しているか、属していないかを見るためには、以下のコマンドで確認できます。
```shell
# Namespaceに属しているもの
@@ -98,10 +98,7 @@ kubectl api-resources --namespaced=true
kubectl api-resources --namespaced=false
```
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* [新しいNamespaceの作成](/docs/tasks/administer-cluster/namespaces/#creating-a-new-namespace)について学習してください。
* [Namespaceの削除](/docs/tasks/administer-cluster/namespaces/#deleting-a-namespace)について学習してください。
{{% /capture %}}
content/ja/docs/concepts/overview/working-with-objects/object-management.md
+8 -7
View File
@@ -1,16 +1,16 @@
---
title: Kubernetesオブジェクト管理
content_template: templates/concept
content_type: concept
weight: 15
---
{{% capture overview %}}
<!-- overview -->
`kubectl`コマンドラインツールは、Kubernetesオブジェクトを作成、管理するためにいくつかの異なる方法をサポートしています。
このドキュメントでは、それらの異なるアプローチごとの概要を提供します。
Kubectlを使ったオブジェクト管理の詳細は、[Kubectl book](https://kubectl.docs.kubernetes.io)を参照してください。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## 管理手法
@@ -157,9 +157,10 @@ kubectl apply -R -f configs/
- 宣言型オブジェクト設定は、デバッグ、そして想定外の結果が出たときに理解するのが困難です
- 差分を利用した一部のみの更新は、複雑なマージ、パッチの操作が必要です
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
- [命令型コマンドを利用したKubernetesオブジェクトの管理](/docs/tasks/manage-kubernetes-objects/imperative-command/)
- [オブジェクト設定（命令型）を利用したKubernetesオブジェクトの管理](/docs/tasks/manage-kubernetes-objects/imperative-config/)
@@ -169,4 +170,4 @@ kubectl apply -R -f configs/
- [Kubectl Book](https://kubectl.docs.kubernetes.io)
- [Kubernetes APIリファレンス](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
{{% /capture %}}
content/ja/docs/concepts/scheduling/kube-scheduler.md
+14 -14
View File
@@ -1,16 +1,16 @@
---
title: Kubernetesのスケジューラー
content_template: templates/concept
content_type: concept
weight: 60
---
{{% capture overview %}}
<!-- overview -->
Kubernetesにおいて、_スケジューリング_ とは、{{< glossary_tooltip term_id="kubelet" >}}が{{< glossary_tooltip text="Pod" term_id="pod" >}}を稼働させるために{{< glossary_tooltip text="Node" term_id="node" >}}に割り当てることを意味します。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## スケジューリングの概要{#scheduling}
@@ -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を指定しているかをチェックします。
@@ -110,12 +110,12 @@ kube-schedulerは、デフォルトで用意されているスケジューリン
- `EqualPriorityMap`: 全てのNodeに対して等しい重みを与えます。
{{% /capture %}}
{{% capture whatsnext %}}
## {{% 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/)を参照してください。
* [複数のスケジューラーの設定](/docs/tasks/administer-cluster/configure-multiple-schedulers/)について学んでください。
* [トポロジーの管理ポリシー](/docs/tasks/administer-cluster/topology-manager/)について学んでください。
* [Podのオーバーヘッド](/docs/concepts/configuration/pod-overhead/)について学んでください。
{{% /capture %}}
content/ja/docs/concepts/scheduling/scheduler-perf-tuning.md
+5 -5
View File
@@ -1,10 +1,10 @@
---
title: スケジューラーのパフォーマンスチューニング
content_template: templates/concept
content_type: concept
weight: 70
---
{{% capture overview %}}
<!-- overview -->
{{< feature-state for_k8s_version="1.14" state="beta" >}}
@@ -14,9 +14,9 @@ weight: 70
このページでは、大規模のKubernetesクラスターにおけるパフォーマンス最適化のためのチューニングについて説明します。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## スコア付けするノードの割合
@@ -71,4 +71,4 @@ Node 1, Node 5, Node 2, Node 6, Node 3, Node 4
全てのノードのチェックを終えたら、1番目のノードに戻ってチェックをします。
{{% /capture %}}
content/ja/docs/concepts/services-networking/connect-applications-service.md
+8 -7
View File
@@ -1,11 +1,11 @@
---
title: サービスとアプリケーションの接続
content_template: templates/concept
content_type: concept
weight: 30
---
{{% capture overview %}}
<!-- overview -->
## コンテナを接続するためのKubernetesモデル
@@ -25,9 +25,9 @@ Kubernetesでは、どのホストで稼働するかに関わらず、Podが他
このガイドでは、シンプルなnginxサーバーを使用して概念実証を示します。
同じ原則が、より完全な[Jenkins CIアプリケーション](https://kubernetes.io/blog/2015/07/strong-simple-ssl-for-kubernetes)で具体化されています。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Podをクラスターに公開する
@@ -423,12 +423,13 @@ LoadBalancer Ingress: a320587ffd19711e5a37606cf4a74574-1142138393.us-east-1.el
...
```
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* 詳細: [Serviceを利用したクラスター内のアプリケーションへのアクセス](/ja/docs/tasks/access-application-cluster/service-access-application-cluster/)
* 詳細: [Serviceを使用してフロントエンドをバックエンドに接続する](/ja/docs/tasks/access-application-cluster/connecting-frontend-backend/)
* 詳細: [Creating an External Load Balancer](/docs/tasks/access-application-cluster/create-external-load-balancer/)
{{% /capture %}}
content/ja/docs/concepts/services-networking/dns-pod-service.md
+8 -7
View File
@@ -1,14 +1,14 @@
---
reviewers:
title: ServiceとPodに対するDNS
content_template: templates/concept
content_type: concept
weight: 20
---
{{% capture overview %}}
<!-- overview -->
このページではKubernetesによるDNSサポートについて概観します。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## イントロダクション
@@ -185,13 +185,14 @@ PodのDNS設定と"`None`"というDNSポリシーの利用可能なバージョ
| 1.10 | β版 (デフォルトで有効)|
| 1.9 | α版 |
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
DNS設定の管理方法に関しては、[DNS Serviceの設定](/docs/tasks/administer-cluster/dns-custom-nameservers/)
を確認してください。
{{% /capture %}}
content/ja/docs/concepts/services-networking/ingress.md
+6 -7
View File
@@ -1,15 +1,15 @@
---
title: Ingress
content_template: templates/concept
content_type: concept
weight: 40
---
{{% capture overview %}}
<!-- overview -->
{{< feature-state for_k8s_version="v1.1" state="beta" >}}
{{< glossary_definition term_id="ingress" length="all" >}}
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## 用語
@@ -387,10 +387,9 @@ Ingressリソースを直接含まない複数の方法でサービスを公開
* [Service.Type=LoadBalancer](/ja/docs/concepts/services-networking/service/#loadbalancer)
* [Service.Type=NodePort](/ja/docs/concepts/services-networking/service/#nodeport)
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* [Ingress 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)
{{% /capture %}}
content/ja/docs/concepts/services-networking/service.md
+122 -121
View File
@@ -5,21 +5,21 @@ feature:
description: >
Kubernetesでは、なじみのないサービスディスカバリーのメカニズムを使用するためにユーザーがアプリケーションの修正をする必要はありません。KubernetesはPodにそれぞれのIPアドレス割り振りや、Podのセットに対する単一のDNS名を提供したり、それらのPodのセットに対する負荷分散が可能です。
content_template: templates/concept
content_type: concept
weight: 10
---
{{% capture overview %}}
<!-- overview -->
{{< glossary_definition term_id="service" length="short" >}}
Kubernetesでは、なじみのないサービスディスカバリーのメカニズムを使用するためにユーザーがアプリケーションの修正をする必要はありません。
Kubernetesでは、なじみのないサービスディスカバリーのメカニズムを使用するためにユーザーがアプリケーションの修正をする必要はありません。
KubernetesはPodにそれぞれのIPアドレス割り振りや、Podのセットに対する単一のDNS名を提供したり、それらのPodのセットに対する負荷分散が可能です。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Serviceを利用する動機
@@ -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リソース {#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,7 +45,7 @@ Serviceによる抽象化は、クライアントからバックエンドのPod
アプリケーション内でサービスディスカバリーのためにKubernetes APIが使える場合、ユーザーはエンドポイントを{{< glossary_tooltip text="API Server" term_id="kube-apiserver" >}}に問い合わせることができ、またService内のPodのセットが変更された時はいつでも更新されたエンドポイントの情報を取得できます。
非ネイティブなアプリケーションのために、KubernetesはアプリケーションとバックエンドPodの間で、ネットワークポートやロードバランサーを配置する方法を提供します。
非ネイティブなアプリケーションのために、KubernetesはアプリケーションとバックエンドPodの間で、ネットワークポートやロードバランサーを配置する方法を提供します。
## Serviceの定義
@@ -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
@@ -149,7 +149,7 @@ Kubernetesクラスターの各Nodeは`kube-proxy`を稼働させています。
### なぜ、DNSラウンドロビンを使わないのでしょうか。
ここで湧き上がる質問として、なぜKubernetesは内部のトラフィックをバックエンドへ転送するためにプロキシーに頼るのでしょうか。
ここで湧き上がる質問として、なぜKubernetesは内部のトラフィックをバックエンドへ転送するためにプロキシーに頼るのでしょうか。
他のアプローチはどうなのでしょうか。例えば、複数のAバリュー(もしくはIPv6用にAAAAバリューなど)をもつDNSレコードを設定し、ラウンドロビン方式で名前を解決することは可能でしょうか。
Serviceにおいてプロキシーを使う理由はいくつかあります。
@@ -160,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を選択します。
@@ -173,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](/ja/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)
@@ -193,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`: 最低コネクション数(オープンされているコネクション数がもっとも小さいもの)
@@ -213,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 >}}
@@ -224,9 +224,9 @@ kube-proxyはIPVSモードで起動する場合、IPVSカーネルモジュー
特定のクライアントからのコネクションが、毎回同一の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で複数のポートを使用するとき、どのポートかを明確にするために、複数のポート全てに対して名前をつける必要があります。
例えば:
@@ -257,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です。
@@ -287,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 >}}
@@ -297,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にアクセスする唯一の方法です。
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が定義されたラベルセレクターを持っているかどうかに依存します。
### ラベルセレクターの利用
@@ -326,7 +326,7 @@ KubernetesのDNSサーバーは`ExternalName` Serviceにアクセスする唯一
### ラベルセレクターなしの場合
ラベルセレクターを定義しないHeadless Serviceにおいては、Endpointsコントローラーは`Endpoints`レコードを作成しません。
ラベルセレクターを定義しないHeadless Serviceにおいては、Endpointsコントローラーは`Endpoints`レコードを作成しません。
しかしDNSのシステムは下記の2つ両方を探索し、設定します。
* [`ExternalName`](#externalname)タイプのServiceに対するCNAMEレコード
@@ -336,13 +336,13 @@ 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を紐づけます。しかし、いかなる種類のプロキシーも設定されません。
@@ -350,33 +350,33 @@ Kubernetesの`ServiceTypes`によって、ユーザーがどのような種類
`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`フラグで指定できます。これはKubernetes v1.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
@@ -399,11 +399,11 @@ status:
- ip: 192.0.2.127
```
外部のロードバランサーからのトラフィックはバックエンドのPodに直接転送されます。クラウドプロバイダーはどのようにそのリクエストをバランシングするかを決めます。
外部のロードバランサーからのトラフィックはバックエンドのPodに直接転送されます。クラウドプロバイダーはどのようにそのリクエストをバランシングするかを決めます。
LoadBalancerタイプのサービスで複数のポートが定義されている場合、すべてのポートが同じプロトコルである必要があり、さらにそのプロトコルは`TCP`、`UDP`、`SCTP`のいずれかである必要があります。
いくつかのクラウドプロバイダーにおいて、`loadBalancerIP`の設定をすることができます。このようなケースでは、そのロードバランサーはユーザーが指定した`loadBalancerIP`に対してロードバランサーを作成します。
いくつかのクラウドプロバイダーにおいて、`loadBalancerIP`の設定をすることができます。このようなケースでは、そのロードバランサーはユーザーが指定した`loadBalancerIP`に対してロードバランサーを作成します。
もし`loadBalancerIP`フィールドの値が指定されていない場合、そのロードバランサーはエフェメラルなIPアドレスに対して作成されます。もしユーザーが`loadBalancerIP`を指定したが、使っているクラウドプロバイダーがその機能をサポートしていない場合、その`loadBalancerIP`フィールドに設定された値は無視されます。
{{< note >}}
@@ -412,25 +412,25 @@ LoadBalancerタイプのサービスで複数のポートが定義されてい
{{< 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
@@ -518,7 +518,7 @@ metadata:
HTTPとHTTPSでは、レイヤー7でのプロキシーを選択します。ELBはユーザーとのコネクションを切断し、リクエストを転送するときにリクエストヘッダーをパースして、`X-Forwarded-For`ヘッダーにユーザーのIPを追加します(Podは接続相手のELBのIPアドレスのみ確認可能です)。
TCPとSSLでは、レイヤー4でのプロキシーを選択します。ELBはヘッダーの値を変更せずにトラフィックを転送します。
TCPとSSLでは、レイヤー4でのプロキシーを選択します。ELBはヘッダーの値を変更せずにトラフィックを転送します。
いくつかのポートがセキュアに保護され、他のポートではセキュアでないような混合した環境において、下記のようにアノテーションを使うことができます。
@@ -539,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:
@@ -551,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:
@@ -568,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のバケット名を設定できます。
@@ -582,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
@@ -604,7 +604,7 @@ AWS上でのELB Service用のアクセスログを管理するためにはいく
#### 他のELBアノテーション
古いタイプのELBを管理するためのアノテーションは他にもあり、下記で紹介します。
古いタイプのELBを管理するためのアノテーションは他にもあり、下記で紹介します。
```yaml
metadata:
@@ -654,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ルールに従って変更されます。
@@ -675,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:
@@ -684,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 >}}
@@ -723,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`にマッピングします。
@@ -739,13 +739,13 @@ 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は`my.database.example.com`という値をもつ`CNAME`レコードを返します。
`my-service`へのアクセスは、他のServiceと同じ方法ですが、再接続する際はプロキシーや転送を介して行うよりも、DNSレベルで行われることが決定的に異なる点となります。
`my-service.prod.svc.cluster.local`というホストをルックアップするとき、クラスターのDNS Serviceは`my.database.example.com`という値をもつ`CNAME`レコードを返します。
`my-service`へのアクセスは、他のServiceと同じ方法ですが、再接続する際はプロキシーや転送を介して行うよりも、DNSレベルで行われることが決定的に異なる点となります。
後にユーザーが使用しているデータベースをクラスター内に移行することになった場合は、Podを起動させ、適切なラベルセレクターやEndpointsを追加し、Serviceの`type`を変更します。
{{< warning >}}
@@ -761,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
@@ -787,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}
@@ -803,14 +803,14 @@ iptablesプロキシーモードはクラスター内の送信元IPを不明瞭
### 衝突の回避
Kubernetesの主要な哲学のうちの一つは、ユーザーは、ユーザー自身のアクションによるミスでないものによって、ユーザーのアクションが失敗するような状況に晒されるべきでないことです。
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アドレスのクリーンアップのためにコントローラーを使用します。
@@ -818,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のオーナーは、衝突のリスクなしに、求めるどのようなポートも選択できることを意味します。
@@ -839,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は変更されます。
@@ -853,12 +853,12 @@ 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}
@@ -896,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}
@@ -912,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 >}}
@@ -928,12 +928,13 @@ SCTPはWindowsベースのNodeではサポートされていません。
kube-proxyはuserspaceモードにおいてSCTPアソシエーションの管理をサポートしません。
{{< /warning >}}
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/)を参照してください。
* [Ingress](/docs/concepts/services-networking/ingress/)を参照してください。
* [EndpointSlices](/docs/concepts/services-networking/endpoint-slices/)を参照してください。
{{% /capture %}}
content/ja/docs/concepts/storage/dynamic-provisioning.md
+5 -5
View File
@@ -1,19 +1,19 @@
---
reviewers:
title: ボリュームの動的プロビジョニング(Dynamic Volume Provisioning)
content_template: templates/concept
content_type: concept
weight: 40
---
{{% capture overview %}}
<!-- overview -->
ボリュームの動的プロビジョニングにより、ストレージ用のボリュームをオンデマンドに作成することができます。
動的プロビジョニングなしでは、クラスター管理者はクラウドプロバイダーまたはストレージプロバイダーに対して新規のストレージ用のボリュームと[`PersistentVolume`オブジェクト](/ja/docs/concepts/storage/persistent-volumes/)を作成するように手動で指示しなければなりません。動的プロビジョニングの機能によって、クラスター管理者がストレージを事前にプロビジョンする必要がなくなります。その代わりに、ユーザーによってリクエストされたときに自動でストレージをプロビジョンします。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## バックグラウンド
@@ -88,4 +88,4 @@ spec:
[マルチゾーン](/docs/setup/multiple-zones)クラスター内では、Podは単一のリージョン内のゾーンをまたいでしか稼働できません。シングルゾーンのStorageバックエンドはPodがスケジュールされるゾーン内でプロビジョンされる必要があります。これは[Volume割り当てモード](/docs/concepts/storage/storage-classes/#volume-binding-mode)を設定することにより可能となります。
{{% /capture %}}
content/ja/docs/concepts/storage/persistent-volumes.md
+5 -7
View File
@@ -5,18 +5,18 @@ feature:
description: >
ローカルストレージや<a href="https://cloud.google.com/storage/">GCP</a>、<a href="https://aws.amazon.com/products/storage/">AWS</a>などのパブリッククラウドプロバイダー、もしくはNFS、iSCSI、Gluster、Ceph、Cinder、Flockerのようなネットワークストレージシステムの中から選択されたものを自動的にマウントします。
content_template: templates/concept
content_type: concept
weight: 20
---
{{% capture overview %}}
<!-- overview -->
このドキュメントではKubernetesの`PersistentVolume`について説明します。[ボリューム](/docs/concepts/storage/volumes/)を一読することをおすすめします。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## 概要
@@ -668,8 +668,7 @@ spec:
- ユーザーがストレージクラス名を指定しない場合、`persistentVolumeClaim.storageClassName`フィールドはnilのままにする。これにより、PVはユーザーにクラスターのデフォルトストレージクラスで自動的にプロビジョニングされる。多くのクラスター環境ではデフォルトのストレージクラスがインストールされているが、管理者は独自のデフォルトストレージクラスを作成することができる。
- ツールがPVCを監視し、しばらくしてもバインドされないことをユーザーに表示する。これはクラスターが動的ストレージをサポートしない(この場合ユーザーは対応するPVを作成するべき)、もしくはクラスターがストレージシステムを持っていない(この場合ユーザーはPVCを必要とする設定をデプロイできない)可能性があることを示す。
{{% /capture %}}
{{% capture whatsnext %}}
## {{% 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)について学ぶ
@@ -681,4 +680,3 @@ spec:
* [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)
{{% /capture %}}
content/ja/docs/concepts/storage/volume-pvc-datasource.md
+5 -5
View File
@@ -1,18 +1,18 @@
---
title: CSI Volume Cloning
content_template: templates/concept
content_type: concept
weight: 30
---
{{% capture overview %}}
<!-- overview -->
{{< feature-state for_k8s_version="v1.16" state="beta" >}}
このドキュメントではKubernetesで既存のCSIボリュームの複製についてのコンセプトを説明します。このページを読む前にあらかじめ[ボリューム](/docs/concepts/storage/volumes)についてよく理解していることが望ましいです。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## イントロダクション
@@ -65,4 +65,4 @@ spec:
新しいPVCが使用可能になると、複製されたPVCは他のPVCと同じように利用されます。またこの時点で新しく作成されたPVCは独立したオブジェクトであることが期待されます。元のdataSource PVCを考慮せず個別に利用、複製、スナップショット、削除できます。これはまた複製元が新しく作成された複製にリンクされておらず、新しく作成された複製に影響を与えずに変更または削除できることを意味します。
{{% /capture %}}
content/ja/docs/concepts/storage/volume-snapshot-classes.md
+5 -5
View File
@@ -1,19 +1,19 @@
---
reviewers:
title: VolumeSnapshotClass
content_template: templates/concept
content_type: concept
weight: 30
---
{{% capture overview %}}
<!-- overview -->
このドキュメントでは、Kubernetesにおける`VolumeSnapshotClass`のコンセプトについて説明します。
関連する項目として、[Volumeのスナップショット](/docs/concepts/storage/volume-snapshots/)と[ストレージクラス](/docs/concepts/storage/storage-classes)も参照してください。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## イントロダクション
@@ -52,4 +52,4 @@ deletionPolicyが`Delete`の場合、元となるストレージスナップシ
VolumeSnapshotClassは、そのクラスに属するVolumeSnapshotを指定するパラメータを持っています。
`driver`に応じて様々なパラメータを使用できます。
{{% /capture %}}
content/ja/docs/concepts/workloads/controllers/cron-jobs.md
+5 -5
View File
@@ -1,10 +1,10 @@
---
title: CronJob
content_template: templates/concept
content_type: concept
weight: 80
---
{{% capture overview %}}
<!-- overview -->
{{< feature-state for_k8s_version="v1.8" state="beta" >}}
@@ -24,9 +24,9 @@ CronJobリソースのためのマニフェストを作成する場合、その
cronジョブを作成し、実行するインストラクション、または、cronジョブ仕様ファイルのサンプルについては、[Running automated tasks with cron jobs](/docs/tasks/job/automated-tasks-with-cron-jobs)をご覧ください。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## CronJobの制限
@@ -50,4 +50,4 @@ Cannot determine if job needs to be started. Too many missed start time (> 100).
CronJobはスケジュールに一致するJobの作成にのみ関与するのに対して、JobはJobが示すPod管理を担います。
{{% /capture %}}
content/ja/docs/concepts/workloads/controllers/daemonset.md
+5 -5
View File
@@ -1,11 +1,11 @@
---
reviewers:
title: DaemonSet
content_template: templates/concept
content_type: concept
weight: 50
---
{{% capture overview %}}
<!-- overview -->
_DaemonSet_ は全て(またはいくつか)のNodeが単一のPodのコピーを稼働させることを保証します。Nodeがクラスターに追加されるとき、PodがNode上に追加されます。Nodeがクラスターから削除されたとき、それらのPodはガーベージコレクターにより除去されます。DaemonSetの削除により、DaemonSetが作成したPodもクリーンアップします。
@@ -18,10 +18,10 @@ DaemonSetのいくつかの典型的な使用例は以下の通りです。
シンプルなケースとして、各タイプのデーモンにおいて、全てのNodeをカバーする1つのDaemonSetが使用されるケースがあります。
さらに複雑な設定では、単一のタイプのデーモン用ですが、異なるフラグや、異なるハードウェアタイプに対するメモリー、CPUリクエストを要求する複数のDaemonSetを使用するケースもあります。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## DaemonSet Specの記述
@@ -168,4 +168,4 @@ DaemonSetは、Podの作成し、そのPodが停止されることのないプ
フロントエンドのようなServiceのように、どのホスト上にPodが稼働するか制御するよりも、レプリカ数をスケールアップまたはスケールダウンしたりローリングアップデートする方が重要であるような、状態をもたないServiceに対してDeploymentを使ってください。
Podのコピーが全てまたは特定のホスト上で常に稼働していることが重要な場合や、他のPodの前に起動させる必要があるときにDaemonSetを使ってください。
{{% /capture %}}
content/ja/docs/concepts/workloads/controllers/deployment.md
+5 -5
View File
@@ -5,11 +5,11 @@ feature:
description: >
Kubernetesはアプリケーションや設定への変更を段階的に行い、アプリケーションの状態を監視しながら、全てのインスタンスが同時停止しないようにします。更新に問題が起きたとき、Kubernetesは変更のロールバックを行います。進化を続けるDeploymnetのエコシステムを活用してください。
content_template: templates/concept
content_type: concept
weight: 30
---
{{% capture overview %}}
<!-- overview -->
_Deployment_ は[Pod](/ja/docs/concepts/workloads/pods/pod/)と[ReplicaSet](/ja/docs/concepts/workloads/controllers/replicaset/)の宣言的なアップデート機能を提供します。
@@ -19,10 +19,10 @@ _Deployment_ は[Pod](/ja/docs/concepts/workloads/pods/pod/)と[ReplicaSet](/ja/
Deploymentによって作成されたReplicaSetを管理しないでください。ユーザーのユースケースが下記の項目をカバーできていない場合はメインのKubernetesリポジトリーにイシューを作成することを検討してください。
{{< /note >}}
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## ユースケース
@@ -1015,4 +1015,4 @@ Deploymentのリビジョン履歴は、Deploymentが管理するReplicaSetに
[`kubectl rolling-update`](/docs/reference/generated/kubectl/kubectl-commands#rolling-update)によって、同様の形式でPodとReplicationControllerを更新できます。しかしDeploymentの使用が推奨されます。なぜならDeploymentの作成は宣言的であり、ローリングアップデートが更新された後に過去のリビジョンにロールバックできるなど、いくつかの追加機能があるためです。
{{% /capture %}}
content/ja/docs/concepts/workloads/controllers/garbage-collection.md
+8 -7
View File
@@ -1,16 +1,16 @@
---
title: ガベージコレクション
content_template: templates/concept
content_type: concept
weight: 60
---
{{% capture overview %}}
<!-- overview -->
Kubernetesのガベージコレクターの役割は、かつてオーナーがいたが、現時点でもはやオーナーがいないようなオブジェクトの削除を行うことです。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## オーナーとその従属オブジェクト {#owners-and-dependents}
@@ -134,16 +134,17 @@ Kubernetes1.7以前では、Deploymentに対するカスケード削除におい
[#26120](https://github.com/kubernetes/kubernetes/issues/26120)にてイシューがトラックされています。
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
[Design Doc 1](https://git.k8s.io/community/contributors/design-proposals/api-machinery/garbage-collection.md)
[Design Doc 2](https://git.k8s.io/community/contributors/design-proposals/api-machinery/synchronous-garbage-collection.md)
{{% /capture %}}
content/ja/docs/concepts/workloads/controllers/replicaset.md
+5 -5
View File
@@ -1,18 +1,18 @@
---
reviewers:
title: ReplicaSet
content_template: templates/concept
content_type: concept
weight: 10
---
{{% capture overview %}}
<!-- overview -->
ReplicaSetの目的は、どのような時でも安定したレプリカPodのセットを維持することです。これは、理想的なレプリカ数のPodが利用可能であることを保証するものとして使用されます。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## ReplicaSetがどのように動くか
@@ -313,4 +313,4 @@ ReplicaSetは[_ReplicationControllers_](/docs/concepts/workloads/controllers/rep
この2つは、ReplicationControllerが[ラベルについてのユーザーガイド](/ja/docs/concepts/overview/working-with-objects/labels/#label-selectors)に書かれているように、集合ベース(set-based)のセレクター要求をサポートしていないことを除いては、同じ目的を果たし、同じようにふるまいます。
このように、ReplicaSetはReplicationControllerよりも好まれます。
{{% /capture %}}
content/ja/docs/concepts/workloads/controllers/statefulset.md
+15 -14
View File
@@ -1,18 +1,18 @@
---
reviewers:
title: StatefulSet
content_template: templates/concept
content_type: concept
weight: 40
---
{{% capture overview %}}
<!-- overview -->
StatefulSetはステートフルなアプリケーションを管理するためのワークロードAPIです。
{{< glossary_definition term_id="statefulset" length="all" >}}
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## StatefulSetの使用
@@ -102,7 +102,7 @@ StatefulSetの名前は有効な[名前](/ja/docs/concepts/overview/working-with
ユーザーは、StatefulSetの`.spec.template.metadata.labels`のラベルと一致させるため、StatefulSetの`.spec.selector`フィールドをセットしなくてはなりません。Kubernetes1.8以前では、`.spec.selector`フィールドは省略された場合デフォルト値になります。Kubernetes1.8とそれ以降のバージョンでは、ラベルに一致するPodセレクターの指定がない場合はStatefulSetの作成時にバリデーションエラーになります。
## Podアイデンティティー
StatefulSetのPodは、順番を示す番号、安定したネットワークアイデンティティー、安定したストレージからなる一意なアイデンティティーを持ちます。
StatefulSetのPodは、順番を示す番号、安定したネットワークアイデンティティー、安定したストレージからなる一意なアイデンティティーを持ちます。
そのアイデンティティーはどのNode上にスケジュール(もしくは再スケジュール)されるかに関わらず、そのPodに紐付きます。
### 順序インデックス
@@ -113,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)を作成する責任があります。
@@ -133,7 +133,7 @@ Cluster Domain | Service (ns/name) | StatefulSet (ns/name) | StatefulSet Domain
### 安定したストレージ
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が削除されたときに削除されません。
削除する場合は手動で行わなければなりません。
@@ -161,8 +161,9 @@ Kubernetes1.7とそれ以降のバージョンでは、StatefulSetは`.spec.podM
`OrderedReady`なPod管理はStatefulSetにおいてデフォルトです。これは[デプロイとスケーリングの保証](#deployment-and-scaling-guarantees)に記載されている項目の振る舞いを実装します。
#### 並行なPod管理Parallel Pod Management
`並行`なPod管理は、StatefulSetコントローラーに対して、他のPodが起動や停止される前にそのPodが完全に起動し準備完了になるか停止するのを待つことなく、Podが並行に起動もしくは停止するように指示します。
#### 並行なPod管理
`Parallel`なPod管理は、StatefulSetコントローラーに対して、他のPodが起動や停止される前にそのPodが完全に起動し準備完了になるか停止するのを待つことなく、Podが並行に起動もしくは停止するように指示します。
## アップデートストラテジー
@@ -178,7 +179,7 @@ Kubernetes1.7とそれ以降のバージョンにおいて、StatefulSetの`.spe
#### パーティション
`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に反映されません。
多くのケースの場合、ユーザーはパーティションを使う必要はありませんが、もし一部の更新を行う場合や、カナリー版のバージョンをロールアウトする場合や、段階的ロールアウトを行う場合に最適です。
#### 強制ロールバック
@@ -191,11 +192,11 @@ Kubernetes1.7とそれ以降のバージョンにおいて、StatefulSetの`.spe
そのテンプレートを戻したあと、ユーザーはまたStatefulSetが異常状態で稼働しようとしていたPodをすべて削除する必要があります。StatefulSetはその戻されたテンプレートを使ってPodの再作成を始めます。
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* [ステートフルなアプリケーションのデプロイ](/docs/tutorials/stateful-application/basic-stateful-set/)の例を参考にしてください。
* [StatefulSetを使ったCassandraのデプロイ](/docs/tutorials/stateful-application/cassandra/)の例を参考にしてください。
* [レプリカを持つステートフルアプリケーションを実行する](/ja/docs/tasks/run-application/run-replicated-stateful-application/)の例を参考にしてください。
{{% /capture %}}
content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md
+8 -7
View File
@@ -1,11 +1,11 @@
---
reviewers:
title: 終了したリソースのためのTTLコントローラー(TTL Controller for Finished Resources)
content_template: templates/concept
content_type: concept
weight: 65
---
{{% capture overview %}}
<!-- overview -->
{{< feature-state for_k8s_version="v1.12" state="alpha" >}}
@@ -14,12 +14,12 @@ TTLコントローラーは現在[Job](/docs/concepts/workloads/controllers/jobs
α版の免責事項: この機能は現在α版の機能で、kube-apiserverとkube-controller-managerの[Feature Gate](/docs/reference/command-line-tools-reference/feature-gates/)の`TTLAfterFinished`を有効にすることで使用可能です。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## TTLコントローラー
@@ -45,12 +45,13 @@ TTLコントローラーが、TTL値が期限切れかそうでないかを決
Kubernetesにおいてタイムスキューを避けるために、全てのNode上でNTPの稼働を必須とします([#6159](https://github.com/kubernetes/kubernetes/issues/6159#issuecomment-93844058)を参照してください)。クロックは常に正しいものではありませんが、Node間におけるその差はとても小さいものとなります。TTLに0でない値をセットするときにこのリスクに対して注意してください。
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
[Jobの自動クリーンアップ](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically)
[設計ドキュメント](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0026-ttl-after-finish.md)
{{% /capture %}}
content/ja/docs/concepts/workloads/pods/init-containers.md
+3 -4
View File
@@ -1,6 +1,6 @@
---
title: Initコンテナ
content_template: templates/concept
content_type: concept
weight: 40
---
@@ -11,7 +11,7 @@ Initコンテナにはアプリケーションコンテナのイメージに存
Initコンテナは、Podの仕様のうち`containers`という配列（これがアプリケーションコンテナを示します）と並べて指定します。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Initコンテナを理解する {#understanding-init-containers}
単一の{{< glossary_tooltip text="Pod" term_id="pod" >}}は、Pod内にアプリケーションを実行している複数のコンテナを持つことができますが、同様に、アプリケーションコンテナが起動する前に実行されるInitコンテナも1つ以上持つことができます。
@@ -245,11 +245,10 @@ Podレベルのコントロールグループ（cgroups）は、スケジュー
* そのPodのインフラストラクチャーコンテナが再起動された場合。これはあまり起きるものでなく、Nodeに対するルート権限を持ったユーザーにより行われることがあります。
* `restartPolicy`が`Always`と設定されているPod内の全てのコンテナが停止され、再起動が行われた場合。およびガーベージコレクションによりInitコンテナの完了記録が失われた場合。
{{% /capture %}}
{{% capture whatsnext %}}
* [Initコンテナを含むPodの作成](/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container)方法について学ぶ。
* [Initコンテナのデバッグ](/ja/docs/tasks/debug-application-cluster/debug-init-containers/)を行う方法について学ぶ。
{{% /capture %}}
content/ja/docs/concepts/workloads/pods/pod-lifecycle.md
+8 -7
View File
@@ -1,17 +1,17 @@
---
title: Podのライフサイクル
content_template: templates/concept
content_type: concept
weight: 30
---
{{% capture overview %}}
<!-- overview -->
このページではPodのライフサイクルについて説明します。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## PodのPhase {#pod-phase}
@@ -332,10 +332,11 @@ spec:
* NodeコントローラがPodの`phase`をFailedにします。
* Podがコントローラで作成されていた場合は、別の場所で再作成されます。
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* [attaching handlers to Container lifecycle events](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)のハンズオンをやってみる
@@ -343,4 +344,4 @@ spec:
* [Container lifecycle hooks](/docs/concepts/containers/container-lifecycle-hooks/)についてもっと学ぶ
{{% /capture %}}
content/ja/docs/concepts/workloads/pods/pod-overview.md
+17 -17
View File
@@ -1,18 +1,17 @@
---
title: Podについての概観(Pod Overview)
content_template: templates/concept
content_type: concept
weight: 10
card:
card:
name: concepts
weight: 60
---
{{% capture overview %}}
<!-- overview -->
このページでは、Kubernetesのオブジェクトモデルにおいて、デプロイ可能な最小単位のオブジェクトである`Pod`に関して概観します。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Podについて理解する {#understanding-pods}
*Pod* は、Kubernetesアプリケーションの基本的な実行単位です。これは、作成またはデプロイするKubernetesオブジェクトモデルの中で最小かつ最も単純な単位です。Podは、{{< glossary_tooltip term_id="cluster" >}}で実行されているプロセスを表します。
@@ -23,19 +22,19 @@ Podは、アプリケーションのコンテナ(いくつかの場合におい
Kubernetesクラスター内でのPodは2つの主な方法で使うことができます。
* **単一のコンテナを稼働させるPod** : いわゆる*「1Pod1コンテナ」* 構成のモデルは、最も一般的なKubernetesのユースケースです。
* **単一のコンテナを稼働させるPod** : いわゆる*「1Pod1コンテナ」* 構成のモデルは、最も一般的なKubernetesのユースケースです。
このケースでは、ユーザーはPodを単一のコンテナのラッパーとして考えることができ、Kubernetesはコンテナを直接扱うというよりは、Podを管理することになります。
* **協調して稼働させる必要がある複数のコンテナを稼働させるPod** : 単一のPodは、リソースを共有する必要があるような、密接に連携した複数の同じ環境にあるコンテナからなるアプリケーションをカプセル化することもできます。 これらの同じ環境にあるコンテナ群は、サービスの結合力の強いユニットを構成することができます。
* **協調して稼働させる必要がある複数のコンテナを稼働させるPod** : 単一のPodは、リソースを共有する必要があるような、密接に連携した複数の同じ環境にあるコンテナからなるアプリケーションをカプセル化することもできます。 これらの同じ環境にあるコンテナ群は、サービスの結合力の強いユニットを構成することができます。
-- 1つのコンテナが、共有されたボリュームからファイルをパブリックな場所に送信し、一方では分割された*サイドカー* コンテナがそれらのファイルを更新します。そのPodはそれらのコンテナとストレージリソースを、単一の管理可能なエンティティとしてまとめます。
[Kubernetes Blog](https://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 +56,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 +68,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 +87,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
@@ -108,11 +107,12 @@ spec:
全てのレプリカの現在の理想的な状態を指定するというよりも、Podテンプレートはクッキーの抜き型のようなものです。一度クッキーがカットされると、そのクッキーは抜き型から離れて関係が無くなります。そこにはいわゆる”量子もつれ”といったものはありません。テンプレートに対するその後の変更や新しいテンプレートへの切り替えは、すでに作成されたPod上には直接的な影響はありません。
同様に、ReplicationControllerによって作成されたPodは、変更後に直接更新されます。これはPodとの意図的な違いとなり、そのPodに属する全てのコンテナの現在の理想的な状態を指定します。このアプローチは根本的にシステムのセマンティクスを単純化し、機能の柔軟性を高めます。
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* [Pod](/ja/docs/concepts/workloads/pods/pod/)について更に学びましょう
* Podの振る舞いに関して学ぶには下記を参照してください
* [Podの停止](/ja/docs/concepts/workloads/pods/pod/#termination-of-pods)
* [Podのライフサイクル](/ja/docs/concepts/workloads/pods/pod-lifecycle/)
{{% /capture %}}
content/ja/docs/concepts/workloads/pods/pod.md
+5 -5
View File
@@ -1,18 +1,18 @@
---
reviewers:
title: Pod
content_template: templates/concept
content_type: concept
weight: 20
---
{{% capture overview %}}
<!-- overview -->
_Pod_ は、Kubernetesで作成および管理できる、デプロイ可能な最小のコンピューティング単位です。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Podとは
@@ -187,4 +187,4 @@ spec.containers[0].securityContext.privileged: forbidden '<*>(0xc20b222db0)true'
PodはKubernetes REST APIのトップレベルのリソースです。
APIオブジェクトの詳細については、[Pod APIオブジェクト](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)を参照してください 。
{{% /capture %}}
content/ja/docs/concepts/workloads/pods/podpreset.md
+8 -7
View File
@@ -1,16 +1,16 @@
---
reviewers:
title: Pod Preset
content_template: templates/concept
content_type: concept
weight: 50
---
{{% capture overview %}}
<!-- overview -->
このページではPodPresetについて概観します。PodPresetは、Podの作成時にそのPodに対して、Secret、Volume、VolumeMountや環境変数など、特定の情報を注入するためのオブジェクトです。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## PodPresetを理解する
`PodPreset`はPodの作成時に追加のランタイム要求を注入するためのAPIリソースです。
@@ -57,10 +57,11 @@ PodPresetによるPodの変更を受け付けたくないようなインスタ
を追加することで可能になります。
1. ユーザーが使う予定のNamespaceにおいて、`PodPreset`オブジェクトを作成することによりPodPresetを定義します。
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* [PodPresetを使ったPodへのデータの注入](/docs/tasks/inject-data-application/podpreset/)
{{% /capture %}}
content/ja/docs/contribute/_index.md
+5 -7
View File
@@ -1,19 +1,19 @@
---
content_template: templates/concept
content_type: concept
title: Kubernetesのドキュメントに貢献する
linktitle: 貢献
main_menu: true
weight: 80
---
{{% capture overview %}}
<!-- overview -->
ドキュメントやウェブサイトに貢献したい方、ご協力お待ちしています。
はじめての方、久しぶりの方、開発者でもエンドユーザでも、はたまたタイポを見逃せない方でもどなたでも貢献可能です。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## はじめに
@@ -36,7 +36,7 @@ Kubernetesのドキュメントは、GitHubのリポジトリーにあります
- PRがマージされたときにissueを参照し、自動的にissueをクローズする_Github Special Keywords_を必ず含めるようにしてください。
- タイプミスの修正や、スタイルの変更、文法の変更などのような小さな変更をPRに加える場合は、比較的小さな変更のためにコミットの数が増えすぎないように、コミットはまとめてください。
- あなたがコードを変更をした理由を示し、レビュアーがあなたのPRを理解するのに十分な情報を確保した適切なPR説明を、必ず含めるようにしてください。
- 追加文献 :
- 追加文献 :
- [chris.beams.io/posts/git-commit/](https://chris.beams.io/posts/git-commit/)
- [github.com/blog/1506-closing-issues-via-pull-requests ](https://github.com/blog/1506-closing-issues-via-pull-requests )
- [davidwalsh.name/squash-commits-git ](https://davidwalsh.name/squash-commits-git )
@@ -46,13 +46,11 @@ Kubernetesのドキュメントは、GitHubのリポジトリーにあります
- TwitterやStack Overflowといったオンラインフォーラムを通してKubernetesコミュニティに貢献したい方、または各地のミートアップやイベントについて知りたい方は[Kubernetes community site](/community/)へ。
- 機能開発に貢献したい方は、まずはじめに[Kubernetesコントリビューターチートシート](https://github.com/kubernetes/community/blob/master/contributors/guide/contributor-cheatsheet/README-ja.md)を読んでください。
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
- ドキュメントへの貢献の基本について、さらに知りたい場合は、[貢献の開始](/docs/contribute/start/)を参照してください。
- 変更を提案をする際は、[Kubernetesドキュメンテーションスタイルガイド](/docs/contribute/style/style-guide/)に従ってください。
- SIG Docsについて、さらに知りたい場合は、[SIG Docsへの参加](/docs/contribute/participating/)を参照してください。
- Kubernetesドキュメントのローカライズについて、さらに知りたい場合は、[Kubernetesドキュメントのローカライズ](/docs/contribute/localization/)を参照してください。
{{% /capture %}}
content/ja/docs/home/supported-doc-versions.md
+5 -5
View File
@@ -1,19 +1,19 @@
---
title: Kubernetesドキュメントがサポートしているバージョン
content_template: templates/concept
content_type: concept
card:
name: about
weight: 10
title: ドキュメントがサポートしているバージョン
---
{{% capture overview %}}
<!-- overview -->
本ウェブサイトでは、現行版とその直前4バージョンのKubernetesドキュメントを含んでいます。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## 現行版
@@ -24,6 +24,6 @@ card:
{{< versions-other >}}
{{% /capture %}}
content/ja/docs/reference/_index.md
+5 -5
View File
@@ -3,16 +3,16 @@ title: リファレンス
linkTitle: "リファレンス"
main_menu: true
weight: 70
content_template: templates/concept
content_type: concept
---
{{% capture overview %}}
<!-- overview -->
本セクションには、Kubernetesのドキュメントのリファレンスが含まれています。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## APIリファレンス
@@ -46,4 +46,4 @@ content_template: templates/concept
Kubernetesの機能に関する設計ドキュメントのアーカイブです。[Kubernetesアーキテクチャ](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md) と[Kubernetesデザイン概要](https://git.k8s.io/community/contributors/design-proposals)から読み始めると良いでしょう。
{{% /capture %}}
content/ja/docs/reference/command-line-tools-reference/feature-gates.md
+8 -7
View File
@@ -1,16 +1,16 @@
---
title: フィーチャーゲート
weight: 10
content_template: templates/concept
content_type: concept
---
{{% capture overview %}}
<!-- overview -->
このページでは管理者がそれぞれのKubernetesコンポーネントで指定できるさまざまなフィーチャーゲートの概要について説明しています。
各機能におけるステージの説明については、[機能のステージ](#feature-stages)を参照してください。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## 概要
フィーチャーゲートはアルファ機能または実験的機能を記述するkey=valueのペアのセットです。管理者は各コンポーネントで`--feature-gates`コマンドラインフラグを使用することで機能をオンまたはオフにできます。
@@ -398,7 +398,8 @@ GAになってからさらなる変更を加えることは現実的ではない
- `WinDSR`: kube-proxyがWindows用のDSRロードバランサーを作成できるようにします。
- `WinOverlay`: kube-proxyをWindowsのオーバーレイモードで実行できるようにします。
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* Kubernetesの[非推奨ポリシー](/docs/reference/using-api/deprecation-policy/)では、機能とコンポーネントを削除するためのプロジェクトのアプローチを説明しています。
{{% /capture %}}
content/ja/docs/reference/glossary/ingress.md
+1 -1
View File
@@ -2,7 +2,7 @@
title: Ingress
id: ingress
date: 2018-04-12
full_link: /docs/ja/concepts/services-networking/ingress/
full_link: /ja/docs/concepts/services-networking/ingress/
short_description: >
クラスター内のServiceに対する外部からのアクセス(主にHTTP)を管理するAPIオブジェクトです。
content/ja/docs/reference/kubectl/cheatsheet.md
+8 -7
View File
@@ -1,20 +1,20 @@
---
title: kubectlチートシート
content_template: templates/concept
content_type: concept
card:
name: reference
weight: 30
---
{{% capture overview %}}
<!-- overview -->
[Kubectl概要](/docs/reference/kubectl/overview/)と[JsonPathガイド](/docs/reference/kubectl/jsonpath)も合わせてご覧ください。
このページは`kubectl`コマンドの概要です。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
# kubectl - チートシート
@@ -376,9 +376,10 @@ kubectlのログレベルは、レベルを表す整数が後に続く`-v`また
`--v=8` | HTTPリクエストのコンテンツを表示します
`--v=9` | HTTPリクエストのコンテンツをtruncationなしで表示します
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* kubectlについてより深く学びたい方は[kubectl概要](/docs/reference/kubectl/overview/)をご覧ください。
@@ -388,4 +389,4 @@ kubectlのログレベルは、レベルを表す整数が後に続く`-v`また
* コミュニティ版[kubectlチートシート](https://github.com/dennyzhang/cheatsheet-kubernetes-A4)もご覧ください。
{{% /capture %}}
content/ja/docs/setup/_index.md
+5 -5
View File
@@ -3,7 +3,7 @@ no_issue: true
title: はじめに
main_menu: true
weight: 20
content_template: templates/concept
content_type: concept
card:
name: setup
weight: 20
@@ -14,7 +14,7 @@ card:
title: 本番環境
---
{{% capture overview %}}
<!-- overview -->
このセクションではKubernetesをセットアップして動かすための複数のやり方について説明します。
@@ -24,9 +24,9 @@ Kubernetesクラスタはローカルマシン、クラウド、オンプレの
簡潔に言えば、学習用としても、本番環境用としてもKubernetesクラスターを作成することができます。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## 環境について学ぶ
@@ -51,4 +51,4 @@ Kubernetesについて学んでいる場合、Dockerベースのソリューシ
[Certified Kubernetes](https://github.com/cncf/k8s-conformance/#certified-kubernetes)プロバイダーの一覧については、"[Partners](https://kubernetes.io/partners/#conformance)"を参照してください。
{{% /capture %}}
content/ja/docs/setup/best-practices/certificates.md
+5 -5
View File
@@ -1,19 +1,19 @@
---
title: PKI証明書とその要件
content_template: templates/concept
content_type: concept
weight: 40
---
{{% capture overview %}}
<!-- overview -->
Kubernetesでは、TLS認証のためにPKI証明書が必要です。
[kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/)でKubernetesをインストールする場合、必要な証明書は自動で生成されます。
自身で証明書を作成することも可能です。例えば、秘密鍵をAPIサーバーに保持しないことで、管理をよりセキュアにする場合が挙げられます。
本ページでは、クラスターに必要な証明書について説明します。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## クラスタではどのように証明書が使われているのか
@@ -161,4 +161,4 @@ KUBECONFIG=<filename> kubectl config use-context default-system
[kubeadm]: /docs/reference/setup-tools/kubeadm/kubeadm/
[proxy]: /docs/tasks/access-kubernetes-api/configure-aggregation-layer/
{{% /capture %}}
content/ja/docs/setup/best-practices/multiple-zones.md
+5 -5
View File
@@ -1,16 +1,16 @@
---
title: 複数のゾーンで動かす
weight: 10
content_template: templates/concept
content_type: concept
---
{{% capture overview %}}
<!-- overview -->
This page describes how to run a cluster in multiple zones.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## 始めに
@@ -397,4 +397,4 @@ KUBERNETES_PROVIDER=aws KUBE_USE_EXISTING_MASTER=true KUBE_AWS_ZONE=us-west-2b k
KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2a kubernetes/cluster/kube-down.sh
```
{{% /capture %}}
content/ja/docs/setup/learning-environment/minikube.md
+5 -5
View File
@@ -1,15 +1,15 @@
---
title: Minikubeを使用してローカル環境でKubernetesを動かす
content_template: templates/concept
content_type: concept
---
{{% capture overview %}}
<!-- overview -->
Minikubeはローカル環境でKubernetesを簡単に実行するためのツールです。Kubernetesを試したり日々の開発への使用を検討するユーザー向けに、PC上のVM内でシングルノードのKubernetesクラスタを実行することができます。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Minikubeの機能
@@ -441,4 +441,4 @@ Minikubeの詳細については、[proposal](https://git.k8s.io/community/contr
コントリビューションや質問、コメントは歓迎・奨励されています! Minikubeの開発者は[Slack](https://kubernetes.slack.com)の#minikubeチャンネルにいます(Slackへの招待状は[こちら](http://slack.kubernetes.io/))。[kubernetes-dev Google Groupsメーリングリスト](https://groups.google.com/forum/#!forum/kubernetes-dev)もあります。メーリングリストに投稿する際は件名の最初に "minikube: " をつけてください。
{{% /capture %}}
content/ja/docs/setup/production-environment/container-runtimes.md
+5 -5
View File
@@ -1,16 +1,16 @@
---
title: CRIのインストール
content_template: templates/concept
content_type: concept
weight: 10
---
{{% capture overview %}}
<!-- overview -->
{{< feature-state for_k8s_version="v1.6" state="stable" >}}
Podのコンテナを実行するために、Kubernetesはコンテナランタイムを使用します。
様々なランタイムのインストール手順は次のとおりです。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
{{< caution >}}
@@ -253,4 +253,4 @@ systemctl start containerd
詳細については[Fraktiのクイックスタートガイド](https://github.com/kubernetes/frakti#quickstart)を参照してください。
{{% /capture %}}
content/ja/docs/setup/production-environment/on-premises-vm/cloudstack.md
+5 -5
View File
@@ -1,9 +1,9 @@
---
title: Cloudstack
content_template: templates/concept
content_type: concept
---
{{% capture overview %}}
<!-- overview -->
[CloudStack](https://cloudstack.apache.org/) is a software to build public and private clouds based on hardware virtualization principles (traditional IaaS). To deploy Kubernetes on CloudStack there are several possibilities depending on the Cloud being used and what images are made available. CloudStack also has a vagrant plugin available, hence Vagrant could be used to deploy Kubernetes either using the existing shell provisioner or using new Salt based recipes.
@@ -11,9 +11,9 @@ content_template: templates/concept
This guide uses a single [Ansible playbook](https://github.com/apachecloudstack/k8s), which is completely automated and can deploy Kubernetes on a CloudStack based Cloud using CoreOS images. The playbook, creates an ssh key pair, creates a security group and associated rules and finally starts coreOS instances configured via cloud-init.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## 前提条件
@@ -115,4 +115,4 @@ IaaS Provider | Config. Mgmt | OS | Networking | Docs
-------------------- | ------------ | ------ | ---------- | --------------------------------------------- | ---------| ----------------------------
CloudStack | Ansible | CoreOS | flannel | [docs](/docs/setup/production-environment/on-premises-vm/cloudstack/) | | Community ([@Guiques](https://github.com/ltupin/))
{{% /capture %}}
content/ja/docs/setup/production-environment/on-premises-vm/dcos.md
+5 -5
View File
@@ -1,9 +1,9 @@
---
title: DC/OS上のKubernetes
content_template: templates/concept
content_type: concept
---
{{% capture overview %}}
<!-- overview -->
Mesosphereは[DC/OS](https://mesosphere.com/product/)上にKubernetesを構築する為の簡単な選択肢を提供します。それは
@@ -14,12 +14,12 @@ Mesosphereは[DC/OS](https://mesosphere.com/product/)上にKubernetesを構築
です。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## 公式Mesosphereガイド
DC/OS入門の正規のソースは[クイックスタートリポジトリ](https://github.com/mesosphere/dcos-kubernetes-quickstart)にあります。
{{% /capture %}}
content/ja/docs/setup/production-environment/on-premises-vm/ovirt.md
+5 -5
View File
@@ -1,15 +1,15 @@
---
title: oVirt
content_template: templates/concept
content_type: concept
---
{{% capture overview %}}
<!-- overview -->
oVirt is a virtual datacenter manager that delivers powerful management of multiple virtual machines on multiple hosts. Using KVM and libvirt, oVirt can be installed on Fedora, CentOS, or Red Hat Enterprise Linux hosts to set up and manage your virtual data center.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## oVirtクラウドプロバイダーによる構築
@@ -65,4 +65,4 @@ IaaS Provider | Config. Mgmt | OS | Networking | Docs
-------------------- | ------------ | ------ | ---------- | --------------------------------------------- | ---------| ----------------------------
oVirt | | | | [docs](/docs/setup/production-environment/on-premises-vm/ovirt/) | | Community ([@simon3z](https://github.com/simon3z))
{{% /capture %}}
content/ja/docs/setup/production-environment/tools/kops.md
+8 -7
View File
@@ -1,10 +1,10 @@
---
title: kopsを使ったAWS上でのKubernetesのインストール
content_template: templates/concept
content_type: concept
weight: 20
---
{{% capture overview %}}
<!-- overview -->
This quickstart shows you how to easily install a Kubernetes cluster on AWS.
It uses a tool called [`kops`](https://github.com/kubernetes/kops).
@@ -21,9 +21,9 @@ kops is an opinionated provisioning system:
If your opinions differ from these you may prefer to build your own cluster using [kubeadm](/docs/admin/kubeadm/) as
a building block. kops builds on the kubeadm work.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## クラスタの作成
@@ -224,12 +224,13 @@ See the [list of add-ons](/docs/concepts/cluster-administration/addons/) to expl
* Slack Channel: [#kops-users](https://kubernetes.slack.com/messages/kops-users/)
* [GitHub Issues](https://github.com/kubernetes/kops/issues)
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* Learn more about Kubernetes [concepts](/docs/concepts/) and [`kubectl`](/docs/user-guide/kubectl-overview/).
* Learn about `kops` [advanced usage](https://github.com/kubernetes/kops)
* See the `kops` [docs](https://github.com/kubernetes/kops) section for tutorials, best practices and advanced configuration options.
{{% /capture %}}
content/ja/docs/setup/production-environment/tools/krib.md
-101
View File
@@ -1,101 +0,0 @@
---
title: KRIBを使用してDigital Rebar Provision (DRP)と共にKubernetesをインストールする
krib-version: 2.4
author: Rob Hirschfeld (zehicle)
weight: 20
---
## 概要
This guide helps to install a Kubernetes cluster hosted on bare metal with [Digital Rebar Provision](https://github.com/digitalrebar/provision) using only its Content packages and *kubeadm*.
Digital Rebar Provision (DRP) is an integrated Golang DHCP, bare metal provisioning (PXE/iPXE) and workflow automation platform. While [DRP can be used to invoke](https://provision.readthedocs.io/en/tip/doc/integrations/ansible.html) [kubespray](/ja/docs/setup/custom-cloud/kubespray), it also offers a self-contained Kubernetes installation known as [KRIB (Kubernetes Rebar Integrated Bootstrap)](https://github.com/digitalrebar/provision-content/tree/master/krib).
{{< note >}}
KRIB is not a _stand-alone_ installer: Digital Rebar templates drive a standard *[kubeadm](/docs/admin/kubeadm/)* configuration that manages the Kubernetes installation with the [Digital Rebar cluster pattern](https://provision.readthedocs.io/en/tip/doc/arch/cluster.html#rs-cluster-pattern) to elect leaders _without external supervision_.
{{< /note >}}
KRIB features:
* zero-touch, self-configuring cluster without pre-configuration or inventory
* very fast, no-ssh required automation
* bare metal, on-premises focused platform
* highly available cluster options (including splitting etcd from the controllers)
* dynamic generation of a TLS infrastructure
* composable attributes and automatic detection of hardware by profile
* options for persistent, immutable and image-based deployments
* support for Ubuntu 18.04, CentOS/RHEL 7, CoreOS, RancherOS and others
## クラスターの作成
Review [Digital Rebar documentation](https://provision.readthedocs.io/en/tip/README.html) for details about installing the platform.
The Digital Rebar Provision Golang binary should be installed on a Linux-like system with 16 GB of RAM or larger (Packet.net Tiny and Rasberry Pi are also acceptable).
### (1/5) サーバーの発見
Following the [Digital Rebar installation](https://provision.readthedocs.io/en/tip/doc/quickstart.html), allow one or more servers to boot through the _Sledgehammer_ discovery process to register with the API. This will automatically install the Digital Rebar runner and to allow for next steps.
### (2/5) KRIBと証明書プラグインのインストール
Upload the KRIB Content bundle (or build from [source](https://github.com/digitalrebar/provision-content/tree/master/krib)) and the Cert Plugin for your DRP platform. Both are freely available via the [RackN UX](https://portal.rackn.io) or using the upload from catalog feature of the DRPCLI (shown below).
```
drpcli plugin_providers upload certs from catalog:certs-stable
drpcli contents upload catalog:krib-stable
```
### (3/5) クラスター構築の開始
{{< note >}}
KRIB documentation is dynamically generated from the source and will be more up to date than this guide.
{{< /note >}}
Following the [KRIB documentation](https://provision.readthedocs.io/en/tip/doc/content-packages/krib.html), create a Profile for your cluster and assign your target servers into the cluster Profile. The Profile must set `krib\cluster-name` and `etcd\cluster-name` Params to be the name of the Profile. Cluster configuration choices can be made by adding additional Params to the Profile; however, safe defaults are provided for all Params.
Once all target servers are assigned to the cluster Profile, start a KRIB installation Workflow by assigning one of the included Workflows to all cluster servers. For example, selecting `krib-live-cluster` will perform an immutable deployment into the Sledgehammer discovery operating system. You may use one of the pre-created read-only Workflows or choose to build your own custom variation.
For basic installs, no further action is required. Advanced users may choose to assign the controllers, etcd servers or other configuration values in the relevant Params.
### (4/5) クラスター構築を監視
Digital Rebar Provision provides detailed logging and live updates during the installation process. Workflow events are available via a websocket connection or monitoring the Jobs list.
During the installation, KRIB writes cluster configuration data back into the cluster Profile.
### (5/5) クラスターへのアクセス
The cluster is available for access via *kubectl* once the `krib/cluster-admin-conf` Param has been set. This Param contains the `kubeconfig` information necessary to access the cluster.
For example, if you named the cluster Profile `krib` then the following commands would allow you to connect to the installed cluster from your local terminal.
::
drpcli profiles get krib params krib/cluster-admin-conf > admin.conf
export KUBECONFIG=admin.conf
kubectl get nodes
The installation continues after the `krib/cluster-admin-conf` is set to install the Kubernetes UI and Helm. You may interact with the cluster as soon as the `admin.conf` file is available.
## クラスター操作
KRIB provides additional Workflows to manage your cluster. Please see the [KRIB documentation](https://provision.readthedocs.io/en/tip/doc/content-packages/krib.html) for an updated list of advanced cluster operations.
### クラスターのスケール
You can add servers into your cluster by adding the cluster Profile to the server and running the appropriate Workflow.
### クラスターのクリーンアップ(開発者向け)
You can reset your cluster and wipe out all configuration and TLS certificates using the `krib-reset-cluster` Workflow on any of the servers in the cluster.
{{< caution >}}
When running the reset Workflow, be sure not to accidentally target your production cluster!
{{< /caution >}}
## フィードバック
* Slack Channel: [#community](https://rackn.slack.com/messages/community/)
* [GitHub Issues](https://github.com/digitalrebar/provision/issues)
content/ja/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md
+5 -5
View File
@@ -1,10 +1,10 @@
---
title: kubeadmを使ったコントロールプレーンの設定のカスタマイズ
content_template: templates/concept
content_type: concept
weight: 40
---
{{% capture overview %}}
<!-- overview -->
{{< feature-state for_k8s_version="1.12" state="stable" >}}
@@ -27,9 +27,9 @@ kubeadmの`ClusterConfiguration`オブジェクトはAPIServer、ControllerManag
`kubeadm config print init-defaults`を実行し、選択したファイルに出力を保存することで、デフォルト値で`ClusterConfiguration`オブジェクトを生成できます。
{{< /note >}}
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## APIServerフラグ
@@ -80,4 +80,4 @@ scheduler:
kubeconfig: /home/johndoe/kubeconfig.yaml
```
{{% /capture %}}
content/ja/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md
+5 -7
View File
@@ -1,10 +1,10 @@
---
title: kubeadmを使用したシングルコントロールプレーンクラスターの作成
content_template: templates/task
content_type: task
weight: 30
---
{{% capture overview %}}
<!-- overview -->
<img src="https://raw.githubusercontent.com/kubernetes/kubeadm/master/logos/stacked/color/kubeadm-stacked-color.png" align="right" width="150px">`kubeadm`ツールは、ベストプラクティスに準拠した実用最小限のKubernetesクラスターをブートストラップする手助けをします。実際、`kubeadm`を使用すれば、[Kubernetes Conformance tests](https://kubernetes.io/blog/2017/10/software-conformance-certification)に通るクラスターをセットアップすることができます。`kubeadm`は、[ブートストラップトークン](/docs/reference/access-authn-authz/bootstrap-tokens/)やクラスターのアップグレードなどのその他のクラスターのライフサイクルの機能もサポートします。
@@ -16,9 +16,7 @@ weight: 30
`kubeadm`は、ラップトップ、クラウドのサーバー群、Raspberry Piなどの様々なマシンにインストールして使えます。クラウドとオンプレミスのどちらにデプロイする場合でも、`kubeadm`はAnsibleやTerraformなどのプロビジョニングシステムに統合できます。
{{% /capture %}}
{{% capture prerequisites %}}
## {{% heading "prerequisites" %}}
このガイドを進めるには、以下の環境が必要です。
@@ -37,9 +35,9 @@ kubeadmツールの全体の機能の状態は、一般利用可能(GA)です。
`kubeadm alpha`以下のすべてのコマンドは、定義通り、アルファレベルでサポートされています。
{{< /note >}}
{{% /capture %}}
{{% capture steps %}}
<!-- steps -->
## 目的
content/ja/docs/setup/production-environment/tools/kubeadm/ha-topology.md
+8 -7
View File
@@ -1,10 +1,10 @@
---
title: 高可用性トポロジーのためのオプション
content_template: templates/concept
content_type: concept
weight: 50
---
{{% capture overview %}}
<!-- overview -->
このページでは、高可用性(HA)Kubernetesクラスターのトポロジーを設定するための2つのオプションについて説明します。
@@ -15,9 +15,9 @@ HAクラスターは次の方法で設定できます。
HAクラスターをセットアップする前に、各トポロジーの利点と欠点について注意深く考慮する必要があります。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## 積層etcdトポロジー
@@ -49,10 +49,11 @@ HAクラスターをセットアップする前に、各トポロジーの利点
![外部のetcdトポロジー](/images/kubeadm/kubeadm-ha-topology-external-etcd.svg)
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
- [kubeadmを使用した高可用性クラスターの作成](/ja/docs/setup/production-environment/tools/kubeadm/high-availability/)
{{% /capture %}}
content/ja/docs/setup/production-environment/tools/kubeadm/high-availability.md
+8 -7
View File
@@ -1,10 +1,10 @@
---
title: kubeadmを使用した高可用性クラスターの作成
content_template: templates/task
content_type: task
weight: 60
---
{{% capture overview %}}
<!-- overview -->
このページでは、kubeadmを使用して、高可用性クラスターを作成する、2つの異なるアプローチを説明します:
@@ -23,9 +23,10 @@ alpha feature gateである`HighAvailability`はv1.12で非推奨となり、v1.
このページはクラウド上でクラスターを構築することには対応していません。ここで説明されているどちらのアプローチも、クラウド上で、LoadBalancerタイプのServiceオブジェクトや、動的なPersistentVolumeを利用して動かすことはできません。
{{< /caution >}}
{{% /capture %}}
{{% capture prerequisites %}}
## {{% heading "prerequisites" %}}
どちらの方法でも、以下のインフラストラクチャーが必要です:
@@ -44,9 +45,9 @@ alpha feature gateである`HighAvailability`はv1.12で非推奨となり、v1.
以下の例では、CalicoをPodネットワーキングプロバイダーとして使用します。別のネットワーキングプロバイダーを使用する場合、必要に応じてデフォルトの値を変更してください。
{{< /note >}}
{{% /capture %}}
{{% capture steps %}}
<!-- steps -->
## 両手順における最初のステップ
@@ -299,4 +300,4 @@ Podネットワークをインストールするには、[こちらの手順に
`kubeadm init`コマンドから返されたコマンドを利用して、workerノードをクラスターに参加させることが可能です。workerノードには、`--experimental-control-plane`フラグを追加する必要はありません。
{{% /capture %}}
content/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md
+10 -8
View File
@@ -1,6 +1,6 @@
---
title: kubeadmのインストール
content_template: templates/task
content_type: task
weight: 20
card:
name: setup
@@ -8,14 +8,15 @@ card:
title: kubeadmセットアップツールのインストール
---
{{% capture overview %}}
<!-- overview -->
<img src="https://raw.githubusercontent.com/kubernetes/kubeadm/master/logos/stacked/color/kubeadm-stacked-color.png" align="right" width="150px">
このページでは`kubeadm`コマンドをインストールする方法を示します。このインストール処理実行後にkubeadmを使用してクラスターを作成する方法については、[kubeadmを使用したシングルマスタークラスターの作成](/ja/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/)を参照してください。
{{% /capture %}}
{{% capture prerequisites %}}
## {{% heading "prerequisites" %}}
* 次のいずれかが動作しているマシンが必要です
- Ubuntu 16.04+
@@ -32,9 +33,9 @@ card:
* マシン内の特定のポートが開いていること。詳細は[ここ](#必須ポートの確認)を参照してください。
* Swapがオフであること。kubeletが正常に動作するためにはswapは**必ず**オフでなければなりません。
{{% /capture %}}
{{% capture steps %}}
<!-- steps -->
## MACアドレスとproduct_uuidが全てのノードでユニークであることの検証
@@ -269,8 +270,9 @@ CRI-Oやcontainerdといった他のコンテナランタイムのcgroup driver
kubeadmで問題が発生した場合は、[トラブルシューティング](/ja/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/)を参照してください。
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* [kubeadmを使用したシングルコントロールプレーンクラスターの作成](/ja/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/)
{{% /capture %}}
content/ja/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md
+5 -5
View File
@@ -1,10 +1,10 @@
---
title: kubeadmを使用したクラスター内の各kubeletの設定
content_template: templates/concept
content_type: concept
weight: 80
---
{{% capture overview %}}
<!-- overview -->
{{< feature-state for_k8s_version="1.11" state="stable" >}}
@@ -24,9 +24,9 @@ characteristics of a given machine, such as OS, storage, and networking. You can
of your kubelets manually, but [kubeadm now provides a `KubeletConfiguration` API type for managing your
kubelet configurations centrally](#configure-kubelets-using-kubeadm).
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Kubeletの設定パターン
@@ -197,4 +197,4 @@ The DEB and RPM packages shipped with the Kubernetes releases are:
| `kubernetes-cni` | Installs the official CNI binaries into the `/opt/cni/bin` directory. |
| `cri-tools` | Installs the `/usr/bin/crictl` binary from the [cri-tools git repository](https://github.com/kubernetes-incubator/cri-tools). |
{{% /capture %}}
content/ja/docs/setup/production-environment/tools/kubeadm/self-hosting.md
+5 -5
View File
@@ -1,10 +1,10 @@
---
title: Configuring your kubernetes cluster to self-host the control plane
content_template: templates/concept
content_type: concept
weight: 100
---
{{% capture overview %}}
<!-- overview -->
### Self-hosting the Kubernetes control plane {#self-hosting}
@@ -17,9 +17,9 @@ configured in the kubelet via static files.
To create a self-hosted cluster see the
[kubeadm alpha selfhosting pivot](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/#cmd-selfhosting) command.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
#### Caveats
@@ -65,4 +65,4 @@ In summary, `kubeadm alpha selfhosting` works as follows:
1. When the original static control plane stops, the new self-hosted control
plane is able to bind to listening ports and become active.
{{% /capture %}}
content/ja/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md
+11 -9
View File
@@ -1,10 +1,10 @@
---
title: kubeadmを使用した高可用性etcdクラスターの作成
content_template: templates/task
content_type: task
weight: 70
---
{{% capture overview %}}
<!-- overview -->
Kubeadm defaults to running a single member etcd cluster in a static pod managed
by the kubelet on the control plane node. This is not a high availability setup
@@ -13,9 +13,10 @@ becoming unavailable. This task walks through the process of creating a high
availability etcd cluster of three members that can be used as an external etcd
when using kubeadm to set up a kubernetes cluster.
{{% /capture %}}
{{% capture prerequisites %}}
## {{% heading "prerequisites" %}}
* Three hosts that can talk to each other over ports 2379 and 2380. This
document assumes these default ports. However, they are configurable through
@@ -26,9 +27,9 @@ when using kubeadm to set up a kubernetes cluster.
[toolbox]: /docs/setup/production-environment/tools/kubeadm/install-kubeadm/
{{% /capture %}}
{{% capture steps %}}
<!-- steps -->
## クラスターの構築
@@ -251,14 +252,15 @@ this example.
- Set `${ETCD_TAG}` to the version tag of your etcd image. For example `v3.2.24`.
- Set `${HOST0}`to the IP address of the host you are testing.
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
Once you have a working 3 member etcd cluster, you can continue setting up a
highly available control plane using the [external etcd method with
kubeadm](/ja/docs/setup/production-environment/tools/kubeadm/high-availability/).
{{% /capture %}}
content/ja/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md
+5 -5
View File
@@ -1,10 +1,10 @@
---
title: kubeadmのトラブルシューティング
content_template: templates/concept
content_type: concept
weight: 90
---
{{% capture overview %}}
<!-- overview -->
As with any program, you might run into an error installing or running kubeadm.
This page lists some common failure scenarios and have provided steps that can help you understand and fix the problem.
@@ -18,9 +18,9 @@ If your problem is not listed below, please follow the following steps:
- If you are unsure about how kubeadm works, you can ask on [Slack](http://slack.k8s.io/) in #kubeadm, or open a question on [StackOverflow](https://stackoverflow.com/questions/tagged/kubernetes). Please include
relevant tags like `#kubernetes` and `#kubeadm` so folks can help you.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## インストール中に`ebtables`もしくは他の似たような実行プログラムが見つからない
@@ -318,4 +318,4 @@ There are at least two workarounds:
```bash
kubectl taint nodes NODE_NAME role.kubernetes.io/master:NoSchedule-
```
{{% /capture %}}
content/ja/docs/setup/production-environment/tools/kubespray.md
+8 -7
View File
@@ -1,10 +1,10 @@
---
title: kubesprayを使ったオンプレミス/クラウドプロバイダへのKubernetesのインストール
content_template: templates/concept
content_type: concept
weight: 30
---
{{% capture overview %}}
<!-- overview -->
This quickstart helps to install a Kubernetes cluster hosted on GCE, Azure, OpenStack, AWS, vSphere, Oracle Cloud Infrastructure (Experimental) or Baremetal with [Kubespray](https://github.com/kubernetes-incubator/kubespray).
@@ -23,9 +23,9 @@ Kubespray is a composition of [Ansible](http://docs.ansible.com/) playbooks, [in
To choose a tool which best fits your use case, read [this comparison](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/comparisons.md) to [kubeadm](/docs/admin/kubeadm/) and [kops](../kops).
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## クラスタの作成
@@ -112,10 +112,11 @@ When running the reset playbook, be sure not to accidentally target your product
* Slack Channel: [#kubespray](https://kubernetes.slack.com/messages/kubespray/)
* [GitHub Issues](https://github.com/kubernetes-incubator/kubespray/issues)
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
Check out planned work on Kubespray's [roadmap](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/roadmap.md).
{{% /capture %}}
content/ja/docs/setup/production-environment/turnkey/aws.md
+8 -7
View File
@@ -1,15 +1,16 @@
---
title: AWS EC2上でKubernetesを動かす
content_template: templates/task
content_type: task
---
{{% capture overview %}}
<!-- overview -->
このページでは、AWS上でKubernetesクラスターをインストールする方法について説明します。
{{% /capture %}}
{{% capture prerequisites %}}
## {{% heading "prerequisites" %}}
AWS上でKubernetesクラスターを作成するには、AWSからアクセスキーIDおよびシークレットアクセスキーを入手する必要があります。
@@ -25,9 +26,9 @@ AWS上でKubernetesクラスターを作成するには、AWSからアクセス
* [KubeOne](https://github.com/kubermatic/kubeone)は可用性の高いKubernetesクラスターを作成、アップグレード、管理するための、オープンソースのライフサイクル管理ツールです。
{{% /capture %}}
{{% capture steps %}}
<!-- steps -->
## クラスターの始まり
@@ -84,4 +85,4 @@ AWS | KubeOne | Ubuntu, CoreOS, CentOS | canal, weave
Kubernetesクラスターの利用と管理に関する詳細は、[Kubernetesドキュメント](/ja/docs/)を参照してください。
{{% /capture %}}
content/ja/docs/setup/production-environment/turnkey/gce.md
+8 -7
View File
@@ -1,15 +1,16 @@
---
title: Google Compute Engine上でKubernetesを動かす
content_template: templates/task
content_type: task
---
{{% capture overview %}}
<!-- overview -->
The example below creates a Kubernetes cluster with 3 worker node Virtual Machines and a master Virtual Machine (i.e. 4 VMs in your cluster). This cluster is set up and controlled from your workstation (or wherever you find convenient).
{{% /capture %}}
{{% capture prerequisites %}}
## {{% heading "prerequisites" %}}
If you want a simplified getting started experience and GUI for managing clusters, please consider trying [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) for hosted cluster installation and management.
@@ -31,9 +32,9 @@ If you want to use custom binaries or pure open source Kubernetes, please contin
1. Make sure you can start up a GCE VM from the command line. At least make sure you can do the [Create an instance](https://cloud.google.com/compute/docs/instances/#startinstancegcloud) part of the GCE Quickstart.
1. Make sure you can SSH into the VM without interactive prompts. See the [Log in to the instance](https://cloud.google.com/compute/docs/instances/#sshing) part of the GCE Quickstart.
{{% /capture %}}
{{% capture steps %}}
<!-- steps -->
## クラスターの起動
@@ -220,4 +221,4 @@ GCE | Saltstack | Debian | GCE | [docs](/ja/docs/set
Please see the [Kubernetes docs](/ja/docs/) for more details on administering
and using a Kubernetes cluster.
{{% /capture %}}
content/ja/docs/setup/production-environment/turnkey/stackpoint.md
+5 -5
View File
@@ -1,15 +1,15 @@
---
title: Stackpoint.ioを利用して複数のクラウド上でKubernetesを動かす
content_template: templates/concept
content_type: concept
---
{{% capture overview %}}
<!-- overview -->
[StackPointCloud](https://stackpoint.io/) is the universal control plane for Kubernetes Anywhere. StackPointCloud allows you to deploy and manage a Kubernetes cluster to the cloud provider of your choice in 3 steps using a web-based interface.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## AWS
@@ -184,4 +184,4 @@ To create a Kubernetes cluster on Packet, you will need a Packet API Key.
For information on using and managing a Kubernetes cluster on Packet, consult [the official documentation](/ja/docs/home/).
{{% /capture %}}
content/ja/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md
+8 -7
View File
@@ -1,16 +1,16 @@
---
title: Intro to Windows support in Kubernetes
content_template: templates/concept
content_type: concept
weight: 65
---
{{% capture overview %}}
<!-- overview -->
Windows applications constitute a large portion of the services and applications that run in many organizations. [Windows containers](https://aka.ms/windowscontainers) provide a modern way to encapsulate processes and package dependencies, making it easier to use DevOps practices and follow cloud native patterns for Windows applications. Kubernetes has become the defacto standard container orchestrator, and the release of Kubernetes 1.14 includes production support for scheduling Windows containers on Windows nodes in a Kubernetes cluster, enabling a vast ecosystem of Windows applications to leverage the power of Kubernetes. Organizations with investments in Windows-based applications and Linux-based applications don't have to look for separate orchestrators to manage their workloads, leading to increased operational efficiencies across their deployments, regardless of operating system.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Windows containers in Kubernetes
@@ -530,9 +530,10 @@ If filing a bug, please include detailed information about how to reproduce the
* [Relevant logs](https://github.com/kubernetes/community/blob/master/sig-windows/CONTRIBUTING.md#gathering-logs)
* Tag the issue sig/windows by commenting on the issue with `/sig windows` to bring it to a SIG-Windows member's attention
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
We have a lot of features in our roadmap. An abbreviated high level list is included below, but we encourage you to view our [roadmap project](https://github.com/orgs/kubernetes/projects/8) and help us make Windows support better by [contributing](https://github.com/kubernetes/community/blob/master/sig-windows/).
@@ -584,4 +585,4 @@ Kubeadm is becoming the de facto standard for users to deploy a Kubernetes clust
* More CNIs
* More Storage Plugins
{{% /capture %}}
content/ja/docs/setup/production-environment/windows/user-guide-windows-containers.md
+8 -8
View File
@@ -1,16 +1,16 @@
---
title: Guide for scheduling Windows containers in Kubernetes
content_template: templates/concept
content_type: concept
weight: 75
---
{{% capture overview %}}
<!-- overview -->
Windows applications constitute a large portion of the services and applications that run in many organizations. This guide walks you through the steps to configure and deploy a Windows container in Kubernetes.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Objectives
@@ -64,7 +64,7 @@ To deploy a Windows container on Kubernetes, you must first create an example ap
- -command
- "<#code used from https://gist.github.com/wagnerandrade/5424431#> ; $$listener = New-Object System.Net.HttpListener ; $$listener.Prefixes.Add('http://*:80/') ; $$listener.Start() ; $$callerCounts = @{} ; Write-Host('Listening at http://*:80/') ; while ($$listener.IsListening) { ;$$context = $$listener.GetContext() ;$$requestUrl = $$context.Request.Url ;$$clientIP = $$context.Request.RemoteEndPoint.Address ;$$response = $$context.Response ;Write-Host '' ;Write-Host('> {0}' -f $$requestUrl) ; ;$$count = 1 ;$$k=$$callerCounts.Get_Item($$clientIP) ;if ($$k -ne $$null) { $$count += $$k } ;$$callerCounts.Set_Item($$clientIP, $$count) ;$$ip=(Get-NetAdapter | Get-NetIpAddress); $$header='<html><body><H1>Windows Container Web Server</H1>' ;$$callerCountsString='' ;$$callerCounts.Keys | % { $$callerCountsString+='<p>IP {0} callerCount {1} ' -f $$ip[1].IPAddress,$$callerCounts.Item($$_) } ;$$footer='</body></html>' ;$$content='{0}{1}{2}' -f $$header,$$callerCountsString,$$footer ;Write-Output $$content ;$$buffer = [System.Text.Encoding]::UTF8.GetBytes($$content) ;$$response.ContentLength64 = $$buffer.Length ;$$response.OutputStream.Write($$buffer, 0, $$buffer.Length) ;$$response.Close() ;$$responseStatus = $$response.StatusCode ;Write-Host('< {0}' -f $$responseStatus) } ; "
nodeSelector:
beta.kubernetes.io/os: windows
kubernetes.io/os: windows
```
{{< note >}}
@@ -113,8 +113,8 @@ Users today need to use some combination of taints and node selectors in order t
Users can ensure Windows containers can be scheduled on the appropriate host using Taints and Tolerations. All Kubernetes nodes today have the following default labels:
* beta.kubernetes.io/os = [windows|linux]
* beta.kubernetes.io/arch = [amd64|arm64|...]
* kubernetes.io/os = [windows|linux]
* kubernetes.io/arch = [amd64|arm64|...]
If a Pod specification does not specify a nodeSelector like `"beta.kubernetes.io/os": windows`, it is possible the Pod can be scheduled on any host, Windows or Linux. This can be problematic since a Windows container can only run on Windows and a Linux container can only run on Linux. The best practice is to use a nodeSelector.
@@ -134,4 +134,4 @@ tolerations:
effect: "NoSchedule"
```
{{% /capture %}}
content/ja/docs/setup/production-environment/windows/user-guide-windows-nodes.md
+5 -5
View File
@@ -1,19 +1,19 @@
---
title: Guide for adding Windows Nodes in Kubernetes
content_template: templates/concept
content_type: concept
weight: 70
---
{{% capture overview %}}
<!-- overview -->
The Kubernetes platform can now be used to run both Linux and Windows containers. One or more Windows nodes can be registered to a cluster. This guide shows how to:
* Register a Windows node to the cluster
* Configure networking so pods on Linux and Windows can communicate
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Before you begin
@@ -261,4 +261,4 @@ Kubeadm is becoming the de facto standard for users to deploy a Kubernetes clust
Now that you've configured a Windows worker in your cluster to run Windows containers you may want to add one or more Linux nodes as well to run Linux containers. You are now ready to schedule Windows containers on your cluster.
{{% /capture %}}
content/ja/docs/setup/release/building-from-source.md
+5 -5
View File
@@ -1,18 +1,18 @@
---
title: リリースのビルド
content_template: templates/concept
content_type: concept
card:
name: download
weight: 20
title: リリースのビルド
---
{{% capture overview %}}
<!-- overview -->
ソースコードからリリースをビルドすることもできますし、既にビルドされたリリースをダウンロードすることも可能です。Kubernetesを開発する予定が無いのであれば、[リリースノート](/docs/setup/release/notes/)内にて既にビルドされたバージョンを使用することを推奨します。
Kubernetes のソースコードは[kubernetes/kubernetes](https://github.com/kubernetes/kubernetes)のリポジトリからダウンロードすることが可能です。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## ソースからのビルド
単にソースからリリースをビルドするだけであれば、完全なGOの環境を準備する必要はなく、全てのビルドはDockerコンテナの中で行われます。
@@ -27,4 +27,4 @@ make release
リリース手段の詳細な情報はkubernetes/kubernetes内の[`build`](http://releases.k8s.io/{{< param "githubbranch" >}}/build/)ディレクトリを参照して下さい。
{{% /capture %}}
content/ja/docs/setup/release/version-skew-policy.md
+4 -4
View File
@@ -1,14 +1,14 @@
---
title: Kubernetesバージョンとバージョンスキューサポートポリシー
content_template: templates/concept
content_type: concept
weight: 30
---
{{% capture overview %}}
<!-- overview -->
このドキュメントでは、さまざまなKubernetesコンポーネント間でサポートされる最大のバージョンの差異（バージョンスキュー）について説明します。特定のクラスターデプロイツールは、バージョンの差異に追加の制限を加える場合があります。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## サポートされるバージョン {#supported-versions}
content/ja/docs/tasks/_index.md
+8 -7
View File
@@ -2,19 +2,19 @@
title: タスク
main_menu: true
weight: 50
content_template: templates/concept
content_type: concept
---
{{< toc >}}
{{% capture overview %}}
<!-- overview -->
Kubernetesドキュメントのこのセクションには、個々のタスクの実行方法を示すページが含まれています。
タスクページは、通常、短い手順を実行することにより、1つのことを行う方法を示します。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Web UI (ダッシュボード)
@@ -76,10 +76,11 @@ StatefulSetのスケーリング、削除、デバッグなど、ステートフ
クラスター内のスケジュール可能なリソースとしてHuge Pageを構成およびスケジュールします。
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
タスクページを作成する場合は、[ドキュメントのPull Requestの作成](/docs/home/contribute/create-pull-request/)を参照してください。
{{% /capture %}}
content/ja/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md
+13 -11
View File
@@ -1,25 +1,26 @@
---
title: 共有ボリュームを使用して同じPod内のコンテナ間で通信する
content_template: templates/task
content_type: task
weight: 110
---
{{% capture overview %}}
<!-- overview -->
このページでは、ボリュームを使用して、同じPodで実行されている2つのコンテナ間で通信する方法を示します。
コンテナ間で[プロセス名前空間を共有する](/ja/docs/tasks/configure-pod-container/share-process-namespace/)ことにより、プロセスが通信できるようにする方法も参照してください。
{{% /capture %}}
{{% capture prerequisites %}}
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
{{% /capture %}}
{{% capture steps %}}
<!-- steps -->
## 2つのコンテナを実行するPodの作成
@@ -105,10 +106,10 @@ debianコンテナがnginxルートディレクトリに`index.html`ファイル
Hello from the debian container
{{% /capture %}}
{{% capture discussion %}}
<!-- discussion -->
## 議論
@@ -121,10 +122,11 @@ Podが複数のコンテナを持つことができる主な理由は、プラ
この演習のボリュームは、コンテナがポッドの寿命中に通信する方法を提供します。
Podを削除して再作成すると、共有ボリュームに保存されているデータはすべて失われます。
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* [複合コンテナのパターン](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)の詳細
@@ -138,7 +140,7 @@ Podを削除して再作成すると、共有ボリュームに保存されて
* [Pod](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)を参照
{{% /capture %}}
content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md
+10 -9
View File
@@ -1,6 +1,6 @@
---
title: 複数のクラスターへのアクセスを設定する
content_template: templates/task
content_type: task
weight: 30
card:
name: tasks
@@ -8,7 +8,7 @@ card:
---
{{% capture overview %}}
<!-- overview -->
ここでは、設定ファイルを使って複数のクラスターにアクセスする方法を紹介します。クラスター、ユーザー、コンテキストの情報を一つ以上の設定ファイルにまとめることで、`kubectl config use-context`のコマンドを使ってクラスターを素早く切り替えることができます。
@@ -16,15 +16,16 @@ card:
クラスターへのアクセスを設定するファイルを、*kubeconfig* ファイルと呼ぶことがあります。これは設定ファイルの一般的な呼び方です。`kubeconfig`という名前のファイルが存在するわけではありません。
{{< /note >}}
{{% /capture %}}
{{% capture prerequisites %}}
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
{{% /capture %}}
{{% capture steps %}}
<!-- steps -->
## クラスター、ユーザー、コンテキストを設定する
@@ -327,11 +328,11 @@ Windows PowerShell
$Env:KUBECONFIG=$ENV:KUBECONFIG_SAVED
```
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* [kubeconfigファイルを使ってクラスターへのアクセスを管理する](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
* [kubectl config](/docs/reference/generated/kubectl/kubectl-commands#config)
{{% /capture %}}
content/ja/docs/tasks/access-application-cluster/connecting-frontend-backend.md
+14 -11
View File
@@ -1,38 +1,40 @@
---
title: Serviceを使用してフロントエンドをバックエンドに接続する
content_template: templates/tutorial
content_type: tutorial
weight: 70
---
{{% capture overview %}}
<!-- overview -->
このタスクでは、フロントエンドとバックエンドのマイクロサービスを作成する方法を示します。
バックエンドのマイクロサービスは挨拶です。
フロントエンドとバックエンドは、Kubernetes {{< glossary_tooltip term_id="service" >}}オブジェクトを使用して接続されます。
{{% /capture %}}
{{% capture objectives %}}
## {{% heading "objectives" %}}
* {{< glossary_tooltip term_id="deployment" >}}オブジェクトを使用してマイクロサービスを作成および実行します。
* フロントエンドを経由してトラフィックをバックエンドにルーティングします。
* Serviceオブジェクトを使用して、フロントエンドアプリケーションをバックエンドアプリケーションに接続します。
{{% /capture %}}
{{% capture prerequisites %}}
## {{% heading "prerequisites" %}}
* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
* このタスクでは[Serviceで外部ロードバランサー](/docs/tasks/access-application-cluster/create-external-load-balancer/)を使用しますが、外部ロードバランサーの使用がサポートされている環境である必要があります。
ご使用の環境がこれをサポートしていない場合は、代わりにタイプ[NodePort](/ja/docs/concepts/services-networking/service/#nodeport)のServiceを使用できます。
{{% /capture %}}
{{% capture lessoncontent %}}
<!-- lessoncontent -->
## Deploymentを使用したバックエンドの作成
@@ -184,14 +186,15 @@ curl http://${EXTERNAL_IP} # これを前に見たEXTERNAL-IPに置き換えま
{"message":"Hello"}
```
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* [Service](/ja/docs/concepts/services-networking/service/)の詳細
* [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/)の詳細
{{% /capture %}}
content/ja/docs/tasks/access-application-cluster/service-access-application-cluster.md
+17 -13
View File
@@ -1,34 +1,36 @@
---
title: Serviceを利用したクラスター内のアプリケーションへのアクセス
content_template: templates/tutorial
content_type: tutorial
weight: 60
---
{{% capture overview %}}
<!-- overview -->
ここでは、クラスター内で稼働しているアプリケーションに外部からアクセスするために、KubernetesのServiceオブジェクトを作成する方法を紹介します。
例として、2つのインスタンスから成るアプリケーションへのロードバランシングを扱います。
{{% /capture %}}
{{% capture prerequisites %}}
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
{{% /capture %}}
{{% capture objectives %}}
## {{% heading "objectives" %}}
* 2つのHellow Worldアプリケーションを稼働させる。
* Nodeのポートを公開するServiceオブジェクトを作成する。
* 稼働しているアプリケーションにアクセスするためにServiceオブジェクトを使用する。
{{% /capture %}}
{{% capture lessoncontent %}}
<!-- lessoncontent -->
## 2つのPodから成るアプリケーションのServiceを作成
@@ -123,10 +125,11 @@ weight: 60
[service configuration file](/ja/docs/concepts/services-networking/service/)
を使用してServiceを作成することもできます。
{{% /capture %}}
{{% capture cleanup %}}
## {{% heading "cleanup" %}}
Serviceを削除するには、以下のコマンドを実行します:
@@ -136,12 +139,13 @@ Hello Worldアプリケーションが稼働しているDeployment、ReplicaSet
kubectl delete deployment hello-world
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
詳細は
[serviceを利用してアプリケーションと接続する](/docs/concepts/services-networking/connect-applications-service/)
を確認してください。
{{% /capture %}}
content/ja/docs/tasks/administer-cluster/developing-cloud-controller-manager.md
+5 -5
View File
@@ -1,9 +1,9 @@
---
title: クラウドコントローラーマネージャーの開発
content_template: templates/concept
content_type: concept
---
{{% capture overview %}}
<!-- overview -->
{{< feature-state for_k8s_version="v1.11" state="beta" >}}
今後のリリースで、クラウドコントローラーマネージャーはKubernetesを任意のクラウドと統合するための良い方法となります。これによりクラウドプロバイダーはKubernetesのコアリリースサイクルから独立して機能を開発できるようになります。
@@ -15,10 +15,10 @@ content_template: templates/concept
実装の詳細をもう少し掘り下げてみましょう。すべてのクラウドコントローラーマネージャーはKubernetesコアからパッケージをインポートします。唯一の違いは、各プロジェクトが利用可能なクラウドプロバイダーの情報(グローバル変数)が更新される場所である[cloudprovider.RegisterCloudProvider](https://github.com/kubernetes/cloud-provider/blob/6371aabbd7a7726f4b358444cca40def793950c2/plugins.go#L55-L63)を呼び出すことによって独自のクラウドプロバイダーを登録する点です。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## 開発
@@ -36,4 +36,4 @@ Kubernetesには登録されていない独自のクラウドプロバイダー
Kubernetesに登録されているクラウドプロバイダーであれば、[Daemonset](https://kubernetes.io/examples/admin/cloud/ccm-example.yaml) を使ってあなたのクラスターで動かすことができます。詳細については[Kubernetesクラウドコントローラーマネージャードキュメント](/docs/tasks/administer-cluster/running-cloud-controller/)を参照してください。
{{% /capture %}}
content/ja/docs/tasks/administer-cluster/enabling-endpointslices.md
+10 -8
View File
@@ -1,18 +1,19 @@
---
title: EndpointSliceの有効化
content_template: templates/task
content_type: task
---
{{% capture overview %}}
<!-- overview -->
このページはKubernetesのEndpointSliceの有効化の概要を説明します。
{{% /capture %}}
{{% capture prerequisites %}}
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
{{% /capture %}}
{{% capture steps %}}
<!-- steps -->
## 概要
@@ -36,9 +37,10 @@ EndpointSliceコントローラーはクラスター内にEndpointSliceを作成
クラスター内でEndpointSliceを完全に有効にすると、各Endpointsリソースに対応するEndpointSliceリソースが表示されます。既存のEndpointsの機能をサポートすることに加えて、EndpointSliceはトポロジーなどの新しい情報を含める必要があります。これらにより、クラスター内のネットワークエンドポイントのスケーラビリティと拡張性が大きく向上します。
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* [EndpointSlice](/docs/concepts/services-networking/endpoint-slices/)を参照してください。
* [サービスとアプリケーションの接続](/ja/docs/concepts/services-networking/connect-applications-service/)を参照してください。
{{% /capture %}}
content/ja/docs/tasks/administer-cluster/running-cloud-controller.md
+5 -5
View File
@@ -1,9 +1,9 @@
---
title: Kubernetesクラウドコントローラーマネージャー
content_template: templates/concept
content_type: concept
---
{{% capture overview %}}
<!-- overview -->
{{< feature-state state="beta" >}}
@@ -11,10 +11,10 @@ Kubernetes v1.6では`cloud-controller-manager`という新しいバイナリが
`cloud-controller-manager`は、[cloudprovider.Interface](https://github.com/kubernetes/cloud-provider/blob/master/cloud.go)を満たす任意のクラウドプロバイダーと接続できます。下位互換性のためにKubernetesのコアプロジェクトで提供される[cloud-controller-manager](https://github.com/kubernetes/kubernetes/tree/master/cmd/cloud-controller-manager)は`kube-controller-manager`と同じクラウドライブラリを使用します。Kubernetesのコアリポジトリで既にサポートされているクラウドプロバイダーは、Kubernetesリポジトリにあるcloud-controller-managerを使用してKubernetesのコアから移行することが期待されています。今後のKubernetesのリリースでは、すべてのクラウドコントローラーマネージャーはsigリードまたはクラウドベンダーが管理するKubernetesのコアプロジェクトの外で開発される予定です。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## 運用
@@ -87,4 +87,4 @@ Kubernetesのコアリポジトリにないクラウドコントローラーマ
独自のクラウドコントローラーマネージャーを構築および開発するには[クラウドコントローラーマネージャーの開発](/docs/tasks/administer-cluster/developing-cloud-controller-manager.md)のドキュメントを参照してください。
{{% /capture %}}
content/ja/docs/tasks/configure-pod-container/assign-cpu-resource.md
+11 -9
View File
@@ -1,17 +1,18 @@
---
title: コンテナおよびPodへのCPUリソースの割り当て
content_template: templates/task
content_type: task
weight: 20
---
{{% capture overview %}}
<!-- overview -->
このページでは、CPUの *request* と *limit* をコンテナに割り当てる方法について示します。コンテナは設定された制限を超えてCPUを使用することはできません。システムにCPUの空き時間がある場合、コンテナには要求されたCPUを割り当てられます。
{{% /capture %}}
{{% capture prerequisites %}}
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
@@ -38,10 +39,10 @@ NAME
v1beta1.metrics.k8s.io
```
{{% /capture %}}
{{% capture steps %}}
<!-- steps -->
## namespaceの作成
@@ -207,9 +208,10 @@ namespaceを削除してください:
kubectl delete namespace cpu-example
```
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
### アプリケーション開発者向け
@@ -234,4 +236,4 @@ kubectl delete namespace cpu-example
* [APIオブジェクトのクォータを設定する](/docs/tasks/administer-cluster/quota-api-object/)
{{% /capture %}}
content/ja/docs/tasks/configure-pod-container/assign-memory-resource.md
+11 -9
View File
@@ -1,17 +1,18 @@
---
title: コンテナおよびPodへのメモリーリソースの割り当て
content_template: templates/task
content_type: task
weight: 10
---
{{% capture overview %}}
<!-- overview -->
このページでは、メモリーの *要求* と *制限* をコンテナに割り当てる方法について示します。コンテナは要求されたメモリーを確保することを保証しますが、その制限を超えるメモリーの使用は許可されません。
{{% /capture %}}
{{% capture prerequisites %}}
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
@@ -38,9 +39,9 @@ NAME
v1beta1.metrics.k8s.io
```
{{% /capture %}}
{{% capture steps %}}
<!-- steps -->
## namespaceの作成
@@ -288,9 +289,10 @@ namespaceを削除してください。これにより、今回のタスクで
kubectl delete namespace mem-example
```
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
### アプリケーション開発者向け
@@ -314,7 +316,7 @@ kubectl delete namespace mem-example
* [APIオブジェクトのクォータを設定する](/docs/tasks/administer-cluster/quota-api-object/)
{{% /capture %}}
content/ja/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md
+13 -11
View File
@@ -1,24 +1,25 @@
---
title: コンテナライフサイクルイベントへのハンドラー紐付け
content_template: templates/task
content_type: task
weight: 140
---
{{% capture overview %}}
<!-- overview -->
このページでは、コンテナのライフサイクルイベントにハンドラーを紐付けする方法を説明します。KubernetesはpostStartとpreStopイベントをサポートしています。Kubernetesはコンテナの起動直後にpostStartイベントを送信し、コンテナの終了直前にpreStopイベントを送信します。
{{% /capture %}}
{{% capture prerequisites %}}
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
{{% /capture %}}
{{% capture steps %}}
<!-- steps -->
## postStartハンドラーとpreStopハンドラーを定義する
@@ -50,11 +51,11 @@ Pod内で実行されているコンテナでシェルを実行します:
Hello from the postStart handler
{{% /capture %}}
{{% capture discussion %}}
<!-- discussion -->
## 議論
@@ -70,10 +71,11 @@ Kubernetesは、Podが *終了* したときにのみpreStopイベントを送
この制限は[issue #55087](https://github.com/kubernetes/kubernetes/issues/55807)で追跡されています。
{{< /note >}}
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* [コンテナライフサイクルフック](/ja/docs/concepts/containers/container-lifecycle-hooks/)の詳細
* [Podのライフサイクル](/ja/docs/concepts/workloads/pods/pod-lifecycle/)の詳細
@@ -85,6 +87,6 @@ Kubernetesは、Podが *終了* したときにのみpreStopイベントを送
* [コンテナ](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)
* [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)の`terminationGracePeriodSeconds`
{{% /capture %}}
content/ja/docs/tasks/configure-pod-container/configure-projected-volume-storage.md
+11 -9
View File
@@ -1,23 +1,24 @@
---
title: ストレージにProjectedボリュームを使用するようPodを設定する
content_template: templates/task
content_type: task
weight: 70
---
{{% capture overview %}}
<!-- overview -->
このページでは、[`projected`](/docs/concepts/storage/volumes/#projected)（投影）ボリュームを使用して、既存の複数のボリュームソースを同一ディレクトリ内にマウントする方法を説明します。
現在、`secret`、`configMap`、`downwardAPI`および`serviceAccountToken`ボリュームを投影できます。
{{< note >}}
`serviceAccountToken`はボリュームタイプではありません。
{{< /note >}}
{{% /capture %}}
{{% capture prerequisites %}}
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
{{% /capture %}}
{{% capture steps %}}
<!-- steps -->
## ProjectedボリュームをPodに設定する
この課題では、ローカルファイルからユーザーネームおよびパスワードの{{< glossary_tooltip text="Secret" term_id="secret" >}}を作成します。
@@ -73,9 +74,10 @@ kubectl delete pod test-projected-volume
kubectl delete secret user pass
```
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* [`projected`](/docs/concepts/storage/volumes/#projected)ボリュームについてさらに学ぶ
* [all-in-oneボリューム](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/node/all-in-one-volume.md)のデザインドキュメントを読む
{{% /capture %}}
content/ja/docs/tasks/configure-pod-container/configure-volume-storage.md
+11 -9
View File
@@ -1,10 +1,10 @@
---
title: ストレージにボリュームを使用するPodを構成する
content_template: templates/task
content_type: task
weight: 50
---
{{% capture overview %}}
<!-- overview -->
このページでは、ストレージにボリュームを使用するPodを構成する方法を示します。
@@ -13,15 +13,16 @@ weight: 50
コンテナに依存しない、より一貫したストレージを実現するには、[ボリューム](/docs/concepts/storage/volumes/)を使用できます。
これは、キーバリューストア(Redisなど)やデータベースなどのステートフルアプリケーションにとって特に重要です。
{{% /capture %}}
{{% capture prerequisites %}}
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
{{% /capture %}}
{{% capture steps %}}
<!-- steps -->
## Podのボリュームを構成する
@@ -120,9 +121,10 @@ weight: 50
kubectl delete pod redis
```
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* [Volume](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volume-v1-core)参照
@@ -130,6 +132,6 @@ weight: 50
* `emptyDir`によって提供されるローカルディスクストレージに加えて、Kubernetesは、GCEのPDやEC2のEBSなど、さまざまなネットワーク接続ストレージソリューションをサポートします。これらは、重要なデータに好ましく、ノード上のデバイスのマウントやアンマウントなどの詳細を処理します。詳細は[ボリューム](/docs/concepts/storage/volumes/)を参照してください。
{{% /capture %}}
content/ja/docs/tasks/configure-pod-container/quality-service-pod.md
+10 -9
View File
@@ -1,25 +1,26 @@
---
title: PodにQuality of Serviceを設定する
content_template: templates/task
content_type: task
weight: 30
---
{{% capture overview %}}
<!-- overview -->
このページでは、特定のQuality of Service (QoS)クラスをPodに割り当てるための設定方法を示します。Kubernetesは、Podのスケジューリングおよび退役を決定するためにQoSクラスを用います。
{{% /capture %}}
{{% capture prerequisites %}}
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
{{% /capture %}}
{{% capture steps %}}
<!-- steps -->
## QoSクラス
@@ -222,9 +223,10 @@ namespaceを削除してください:
kubectl delete namespace qos-example
```
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
### アプリケーション開発者向け
@@ -250,7 +252,6 @@ kubectl delete namespace qos-example
* [APIオブジェクトのクォータを設定する](/docs/tasks/administer-cluster/quota-api-object/)
* [ノードのトポロジー管理ポリシーを制御する](/docs/tasks/administer-cluster/topology-manager/)
{{% /capture %}}
content/ja/docs/tasks/configure-pod-container/share-process-namespace.md
+10 -9
View File
@@ -1,11 +1,11 @@
---
title: Pod内のコンテナ間でプロセス名前空間を共有する
min-kubernetes-server-version: v1.10
content_template: templates/task
content_type: task
weight: 160
---
{{% capture overview %}}
<!-- overview -->
{{< feature-state state="stable" for_k8s_version="v1.17" >}}
@@ -14,15 +14,16 @@ weight: 160
この機能を使用して、ログハンドラーサイドカーコンテナなどの協調コンテナを構成したり、シェルなどのデバッグユーティリティを含まないコンテナイメージをトラブルシューティングしたりできます。
{{% /capture %}}
{{% capture prerequisites %}}
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
{{% /capture %}}
{{% capture steps %}}
<!-- steps -->
## Podを構成する
@@ -86,9 +87,9 @@ events {
worker_connections 1024;
```
{{% /capture %}}
{{% capture discussion %}}
<!-- discussion -->
## プロセス名前空間の共有について理解する
@@ -106,6 +107,6 @@ Podは多くのリソースを共有するため、プロセスの名前空間
1. **コンテナファイルシステムは、`/proc/$pid/root`リンクを介してPod内の他のコンテナに表示されます。**
これによりデバッグが容易になりますが、ファイルシステム内の秘密情報はファイルシステムのアクセス許可によってのみ保護されることも意味します。
{{% /capture %}}
content/ja/docs/tasks/debug-application-cluster/debug-init-containers.md
+10 -9
View File
@@ -1,24 +1,25 @@
---
title: Initコンテナのデバッグ
content_template: templates/task
content_type: task
---
{{% capture overview %}}
<!-- overview -->
このページでは、Initコンテナの実行に関連する問題を調査する方法を説明します。以下のコマンドラインの例では、Podを`<pod-name>`、Initコンテナを`<init-container-1>`および`<init-container-2>`として参照しています。
{{% /capture %}}
{{% capture prerequisites %}}
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
* [Initコンテナ](/ja/docs/concepts/abstractions/init-containers/)の基本を理解しておきましょう。
* [Initコンテナを設定](/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container/)しておきましょう。
{{% /capture %}}
{{% capture steps %}}
<!-- steps -->
## Initコンテナのステータスを確認する
@@ -95,9 +96,9 @@ kubectl logs <pod-name> -c <init-container-2>
シェルスクリプトを実行するInitコンテナは、実行時にコマンドを出力します。たとえば、スクリプトの始めに`set -x`を実行することでBashで同じことができます。
{{% /capture %}}
{{% capture discussion %}}
<!-- discussion -->
## Podのステータスを理解する
@@ -111,7 +112,7 @@ kubectl logs <pod-name> -c <init-container-2>
`Pending` | PodはまだInitコンテナの実行を開始していません。
`PodInitializing` or `Running` | PodはすでにInitコンテナの実行を終了しています。
{{% /capture %}}
content/ja/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md
+8 -7
View File
@@ -1,23 +1,24 @@
---
title: PodとReplicationControllerのデバッグ
content_template: templates/task
content_type: task
---
{{% capture overview %}}
<!-- overview -->
このページでは、PodとReplicationControllerをデバッグする方法を説明します。
{{% /capture %}}
{{% capture prerequisites %}}
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
* [Pod](/ja/docs/concepts/workloads/pods/pod/)と[Podのライフサイクル](/ja/docs/concepts/workloads/pods/pod-lifecycle/)の基本を理解している必要があります。
{{% /capture %}}
{{% capture steps %}}
<!-- steps -->
## Podのデバッグ
@@ -124,4 +125,4 @@ Podを作成できない場合は、[上述の手順](#Podのデバッグ)を参
`kubectl describe rc ${CONTROLLER_NAME}`を使用して、レプリケーションコントローラーに関連するイベントを調べることもできます。
{{% /capture %}}
content/ja/docs/tasks/debug-application-cluster/debug-service.md
+8 -7
View File
@@ -1,18 +1,18 @@
---
content_template: templates/concept
content_type: concept
title: Serviceのデバッグ
---
{{% capture overview %}}
<!-- overview -->
新規にKubernetesをインストールした環境でかなり頻繁に発生する問題は、Serviceが適切に機能しないというものです。
Deployment（または他のワークロードコントローラー）を通じてPodを実行し、サービスを作成したにもかかわらず、アクセスしようとしても応答がありません。
何が問題になっているのかを理解するのに、このドキュメントがきっと役立つでしょう。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Pod内でコマンドを実行する
@@ -658,10 +658,11 @@ DNSは動作していて、`kube-proxy`も誤動作していないようです
[Forum](https://discuss.kubernetes.io)または
[GitHub](https://github.com/kubernetes/kubernetes)でお問い合わせください。
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
詳細については、[トラブルシューティングドキュメント](/docs/troubleshooting/)をご覧ください。
{{% /capture %}}

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