From d1faa62d4198a88e929754bb6e3f22dc91e699f6 Mon Sep 17 00:00:00 2001 From: keita mochizuki <37737691+mochizuki875@users.noreply.github.com> Date: Sun, 16 Aug 2020 00:28:06 +0900 Subject: [PATCH 001/252] Fix -apiserver-advertise-address Fix --apiserver-advertize-address= to --apiserver-advertise-address=. --- .../tools/kubeadm/create-cluster-kubeadm.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md b/content/ja/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md index c0156a4e6f..9c096a6698 100644 --- a/content/ja/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md +++ b/content/ja/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md @@ -63,7 +63,7 @@ kubeadmツールの全体の機能の状態は、一般利用可能(GA)です。 1. (推奨)シングルコントロールプレーンの`kubeadm`クラスターを高可用性クラスターにアップグレードする予定がある場合、`--control-plane-endpoint`を指定して、すべてのコントロールプレーンノードとエンドポイントを共有する必要があります。エンドポイントにはDNSネームやロードバランサーのIPアドレスが使用できます。 1. Podネットワークアドオンを選んで、`kubeadm init`に引数を渡す必要があるかどうか確認してください。選んだサードパーティーのプロバイダーによっては、`--pod-network-cidr`をプロバイダー固有の値に設定する必要がある場合があります。詳しくは、[Podネットワークアドオンのインストール](#pod-network)を参照してください。 1. (オプション)バージョン1.14から、`kubeadm`はよく知られたドメインソケットのパスリストを用いて、Linux上のコンテナランタイムの検出を試みます。異なるコンテナランタイムを使用する場合やプロビジョニングするノードに2つ以上のランタイムがインストールされている場合、`kubeadm init`に`--cri-socket`引数を指定してください。詳しくは、[ランタイムのインストール](/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#installing-runtime)を読んでください。 -1. (オプション)明示的に指定しない限り、`kubeadm`はデフォルトゲートウェイに関連付けられたネットワークインターフェイスを使用して、この特定のコントロールプレーンノードのAPIサーバーのadvertise addressを設定します。異なるネットワークインターフェイスを使用するには、`kubeadm init`に`--apiserver-advertize-address=`引数を指定してください。IPv6アドレスを使用するIPv6 Kubernetesクラスターをデプロイするには、たとえば`--apiserver-advertise-address=fd00::101`のように、IPv6アドレスを指定する必要があります。 +1. (オプション)明示的に指定しない限り、`kubeadm`はデフォルトゲートウェイに関連付けられたネットワークインターフェイスを使用して、この特定のコントロールプレーンノードのAPIサーバーのadvertise addressを設定します。異なるネットワークインターフェイスを使用するには、`kubeadm init`に`--apiserver-advertise-address=`引数を指定してください。IPv6アドレスを使用するIPv6 Kubernetesクラスターをデプロイするには、たとえば`--apiserver-advertise-address=fd00::101`のように、IPv6アドレスを指定する必要があります。 1. (オプション)`kubeadm init`を実行する前に`kubeadm config images pull`を実行して、gcr.ioコンテナイメージレジストリに接続できるかどうかを確認します。 コントロールプレーンノードを初期化するには、次のコマンドを実行します。 From dd02880d0cbbb25f39657964d680c98767289862 Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Wed, 19 Aug 2020 06:06:16 +0900 Subject: [PATCH 002/252] Update tasks/tools/_index.md from en/ directory. --- content/ja/docs/tasks/tools/_index.md | 37 +++++++++++++++++++++++++++ 1 file changed, 37 insertions(+) diff --git a/content/ja/docs/tasks/tools/_index.md b/content/ja/docs/tasks/tools/_index.md index bad7d8bef2..a1f15115eb 100755 --- a/content/ja/docs/tasks/tools/_index.md +++ b/content/ja/docs/tasks/tools/_index.md @@ -1,4 +1,41 @@ --- title: "ツールのインストール" +description: Set up Kubernetes tools on your computer. weight: 10 +no_list: true --- + +## kubectl + +The Kubernetes command-line tool, `kubectl`, allows you to run commands against +Kubernetes clusters. You can use kubectl to deploy applications, inspect and manage +cluster resources, and view logs. + +See [Install and Set Up kubectl](/docs/tasks/tools/install-kubectl/) for information about how to +download and install `kubectl` and set it up for accessing your cluster. + +You can also read the [`kubectl` reference documentation](/docs/reference/kubectl/). + +## Minikube + +[Minikube](https://minikube.sigs.k8s.io/) is a tool that lets you run +Kubernetes locally. Minikube runs a single-node Kubernetes cluster on your personal +computer (including Windows, macOS and Linux PCs) so that you can try out Kubernetes, +or for daily development work. + +You can follow the official [Get Started!](https://minikube.sigs.k8s.io/docs/start/) +guide, or read [Install Minikube](/docs/tasks/tools/install-minikube/) if your focus +is on getting the tool installed. + +Once you have Minikube working, you can use it to +[run a sample application](/docs/tutorials/hello-minikube/). + +## kind + +Like Minikube, [kind](https://kind.sigs.k8s.io/docs/) lets you run Kubernetes on +your local compute. Unlike Minikuke, kind only works with a single container runtime: +it requires that you have [Docker](https://docs.docker.com/get-docker/) installed +and configured. + +[Quick Start](https://kind.sigs.k8s.io/docs/user/quick-start/) shows you what you +need to do to get up and running with kind. From 211acbe51907b2e2645ffd2cd50815af4557a727 Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Wed, 19 Aug 2020 07:51:54 +0900 Subject: [PATCH 003/252] Translate tasks/tools into Japanese. --- content/ja/docs/tasks/tools/_index.md | 31 ++++++++------------------- 1 file changed, 9 insertions(+), 22 deletions(-) diff --git a/content/ja/docs/tasks/tools/_index.md b/content/ja/docs/tasks/tools/_index.md index a1f15115eb..ac97313bb8 100755 --- a/content/ja/docs/tasks/tools/_index.md +++ b/content/ja/docs/tasks/tools/_index.md @@ -1,41 +1,28 @@ --- title: "ツールのインストール" -description: Set up Kubernetes tools on your computer. +description: Kubernetesのツールをローカルのコンピュータ上にセットアップします。 weight: 10 no_list: true --- ## kubectl -The Kubernetes command-line tool, `kubectl`, allows you to run commands against -Kubernetes clusters. You can use kubectl to deploy applications, inspect and manage -cluster resources, and view logs. +Kubernetesのコマンドラインツール`kubectl`を使用すると、Kubernetesクラスターに対してコマンドを実行できるようになります。kubectlは、アプリケーションのデプロイ、クラスターリソースの調査と管理、ログの表示などに使用できます。 -See [Install and Set Up kubectl](/docs/tasks/tools/install-kubectl/) for information about how to -download and install `kubectl` and set it up for accessing your cluster. +`kubectl`のダウンロードとインストールを行い、クラスターへのアクセスをセットアップする方法については、[kubectlのインストールおよびセットアップ](/ja/docs/tasks/tools/install-kubectl/)を参照してください。 -You can also read the [`kubectl` reference documentation](/docs/reference/kubectl/). +また、[`kubectl`リファレンスドキュメント](/ja/docs/reference/kubectl/)も参照できます。 ## Minikube -[Minikube](https://minikube.sigs.k8s.io/) is a tool that lets you run -Kubernetes locally. Minikube runs a single-node Kubernetes cluster on your personal -computer (including Windows, macOS and Linux PCs) so that you can try out Kubernetes, -or for daily development work. +[Minikube](https://minikube.sigs.k8s.io/)は、Kubernetesをローカルで実行するツールです。MinikubeはシングルノードのKubernetesクラスターをパーソナルコンピューター上(Windows、macOS、Linux PCを含む)で実行することで、Kubernetesを試したり、日常的な開発作業のために利用できます。 -You can follow the official [Get Started!](https://minikube.sigs.k8s.io/docs/start/) -guide, or read [Install Minikube](/docs/tasks/tools/install-minikube/) if your focus -is on getting the tool installed. +ツールのインストールについて知りたい場合は、公式の[Get Started!](https://minikube.sigs.k8s.io/docs/start/)のガイドに従うか、[Minikubeのインストール](/ja/docs/tasks/tools/install-minikube/)を読んでください。 -Once you have Minikube working, you can use it to -[run a sample application](/docs/tutorials/hello-minikube/). +Minikubeが起動したら、[サンプルアプリケーションの実行](/ja/docs/tutorials/hello-minikube/)を試すことができます。 ## kind -Like Minikube, [kind](https://kind.sigs.k8s.io/docs/) lets you run Kubernetes on -your local compute. Unlike Minikuke, kind only works with a single container runtime: -it requires that you have [Docker](https://docs.docker.com/get-docker/) installed -and configured. +Minikubeと同じように、[kind](https://kind.sigs.k8s.io/docs/)もローカルコンピューター上でKubernetesを実行するツールです。Minikubeとは違い、kindは1種類のコンテナランタイム上でしか動作しません。実行には[Docker](https://docs.docker.com/get-docker/)のインストールと設定が必要です。 -[Quick Start](https://kind.sigs.k8s.io/docs/user/quick-start/) shows you what you -need to do to get up and running with kind. +[Quick Start](https://kind.sigs.k8s.io/docs/user/quick-start/)に、kindの起動に必要な手順が説明されています。 From 2efdc532097d2bece1e2c02fd75e6bce586277d3 Mon Sep 17 00:00:00 2001 From: Jin Hase Date: Thu, 20 Aug 2020 20:11:28 +0900 Subject: [PATCH 004/252] Update Japanese localization on concepts/containers/runtime-class.md --- .../docs/concepts/containers/runtime-class.md | 60 ++++++------------- 1 file changed, 18 insertions(+), 42 deletions(-) diff --git a/content/ja/docs/concepts/containers/runtime-class.md b/content/ja/docs/concepts/containers/runtime-class.md index bd6cc59c49..c902cd704c 100644 --- a/content/ja/docs/concepts/containers/runtime-class.md +++ b/content/ja/docs/concepts/containers/runtime-class.md @@ -11,20 +11,18 @@ weight: 20 このページではRuntimeClassリソースと、runtimeセクションのメカニズムについて説明します。 -{{< warning >}} -RuntimeClassはKubernetes1.14のβ版アップグレードにおいて*破壊的な* 変更を含んでいます。もしユーザーがKubernetes1.14以前のバージョンを使っていた場合、[RuntimeClassのα版からβ版へのアップグレード](#upgrading-runtimeclass-from-alpha-to-beta)を参照してください。 -{{< /warning >}} - - +RuntimeClassはコンテナランタイムの設定を選択するための機能です。そのコンテナランタイム設定はPodのコンテナを稼働させるために使われます。 -## RuntimeClassについて +## RuntimeClassを使う動機 -RuntimeClassはコンテナランタイムの設定を選択するための機能です。そのコンテナランタイム設定はPodのコンテナを稼働させるために使われます。 +異なるPodに異なるRuntimeClassを設定することで、パフォーマンスとセキュリティのバランスをとることができます。例えば、ワークロードの一部に高レベルの情報セキュリティ保証が必要な場合、ハードウェア仮想化を使用するコンテナランタイムで実行されるようにそれらのPodをスケジュールすることを選択できます。その後、追加のオーバーヘッドを犠牲にして、代替ランタイムをさらに分離することでメリットが得られます。 -### セットアップ +RuntimeClassを使用して、コンテナランタイムは同じで設定が異なるPodを実行することもできます。 + +## セットアップ RuntimeClass機能のフィーチャーゲートが有効になっていることを確認してください(デフォルトで有効です)。フィーチャーゲートを有効にする方法については、[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を参照してください。 その`RuntimeClass`のフィーチャーゲートはApiServerとkubeletのどちらも有効になっていなければなりません。 @@ -32,7 +30,7 @@ RuntimeClass機能のフィーチャーゲートが有効になっているこ 1. ノード上でCRI実装を設定する。(ランタイムに依存) 2. 対応するRuntimeClassリソースを作成する。 -#### 1. ノード上でCRI実装を設定する。 +### 1. ノード上でCRI実装を設定する。 RuntimeClassを通じて利用可能な設定はContainer Runtime Interface (CRI)の実装依存となります。 ユーザーの環境のCRI実装の設定方法は、対応するドキュメント([下記](#cri-configuration))を参照ください。 @@ -44,7 +42,7 @@ RuntimeClassは、クラスター全体で同じ種類のノード設定であ RuntimeClassの設定は、RuntimeClassによって参照される`ハンドラー`名を持ちます。そのハンドラーは正式なDNS-1123に準拠する形式のラベルでなくてはなりません(英数字 + `-`の文字で構成されます)。 -#### 2. 対応するRuntimeClassリソースを作成する +### 2. 対応するRuntimeClassリソースを作成する ステップ1にて設定する各項目は、関連する`ハンドラー` 名を持ちます。それはどの設定かを指定するものです。各ハンドラーにおいて、対応するRuntimeClassオブジェクトが作成されます。 @@ -68,7 +66,7 @@ RuntimeClassの書き込み操作(create/update/patch/delete)はクラスター Overview](/docs/reference/access-authn-authz/authorization/)を参照してください。 {{< /note >}} -### 使用例 +## 使用例 一度RuntimeClassがクラスターに対して設定されると、それを使用するのは非常に簡単です。PodSpecの`runtimeClassName`を指定してください。 例えば @@ -119,17 +117,15 @@ table](https://github.com/cri-o/cri-o/blob/master/docs/crio.conf.5.md#crioruntim runtime_path = "${PATH_TO_BINARY}" ``` -CRI-Oの[設定に関するドキュメント][100]の詳細は下記を参照してください。 +CRI-Oの[設定に関するドキュメント](https://raw.githubusercontent.com/cri-o/cri-o/9f11d1d/docs/crio.conf.5.md)の詳細は下記を参照してください。 -[100]: https://raw.githubusercontent.com/cri-o/cri-o/9f11d1d/docs/crio.conf.5.md - -### スケジューリング {#scheduling} +## スケジューリング {#scheduling} {{< feature-state for_k8s_version="v1.16" state="beta" >}} Kubernetes 1.16では、RuntimeClassは`scheduling`フィールドを使ったクラスター内での異なる設定をサポートしています。 このフィールドによって、設定されたRuntimeClassをサポートするノードに対してPodがスケジュールされることを保証できます。 -スケジューリングをサポートするためにはRuntimeClass [アドミッションコントローラー][]を有効にしなければなりません。(1.16ではデフォルトです) +スケジューリングをサポートするためにはRuntimeClass [アドミッションコントローラー](/docs/reference/access-authn-authz/admission-controllers/#runtimeclass)を有効にしなければなりません。(1.16ではデフォルトです) 特定のRuntimeClassをサポートしているノードへPodが配置されることを保証するために、各ノードは`runtimeclass.scheduling.nodeSelector`フィールドによって選択される共通のラベルを持つべきです。 RuntimeClassのnodeSelectorはアドミッション機能によりPodのnodeSelectorに統合され、効率よくノードを選択します。 @@ -138,40 +134,20 @@ RuntimeClassのnodeSelectorはアドミッション機能によりPodのnodeSele もしサポートされているノードが他のRuntimeClassのPodが稼働しないようにtaint付与されていた場合、RuntimeClassに対して`tolerations`を付与することができます。 `nodeSelector`と同様に、tolerationsはPodのtolerationsにアドミッション機能によって統合され、効率よく許容されたノードを選択します。 -ノードの選択とtolerationsについての詳細は[ノード上へのPodのスケジューリング](/ja/docs/concepts/configuration/assign-pod-node/)を参照してください。 - -[アドミッションコントローラー]: /docs/reference/access-authn-authz/admission-controllers/ +ノードの選択とtolerationsについての詳細は[ノード上へのPodのスケジューリング](/docs/concepts/scheduling-eviction/assign-pod-node/)を参照してください。 ### Podオーバーヘッド -{{< feature-state for_k8s_version="v1.16" state="alpha" >}} +{{< feature-state for_k8s_version="v1.18" state="beta" >}} -Kubernetes 1.16ではRuntimeClassは[`PodOverhead`](/docs/concepts/configuration/pod-overhead/)機能の一部である、Podが稼働する時に関連するオーバーヘッドを指定することをサポートしています。 -`PodOverhead`を使うためには、PodOverhead[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にしなければなりません。(デフォルトではoffです) +Podが稼働する時に関連する_オーバーヘッド_リソースを指定できます。オーバーヘッドを宣言すると、クラスター(スケジューラーを含む)がPodとリソースに関する決定を行うときにオーバーヘッドを考慮することができます。 +Podオーバーヘッドを使うためには、PodOverhead[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にしなければなりません。(デフォルトではonです) -PodのオーバーヘッドはRuntimeClass内の`Overhead`フィールドによって定義されます。 +PodのオーバーヘッドはRuntimeClass内の`overhead`フィールドによって定義されます。 このフィールドを使用することで、RuntimeClassを使用して稼働するPodのオーバーヘッドを指定することができ、Kubernetes内部で使用されるオーバーヘッドを確保することができます。 -### RutimeClassをα版からβ版にアップグレードする -RuntimeClassのβ版の機能は、下記の変更点を含みます。 - -- `node.k8s.io`APIグループと`runtimeclasses.node.k8s.io`リソースはCustomResourceDefinitionからビルトインAPIへとマイグレーションされました。 -- `spec`はRuntimeClassの定義内にインライン化されました(RuntimeClassSpecはすでにありません)。 -- `runtimeHandler`フィールドは`handler`にリネームされました。 -- `handler`フィールドは、全てのAPIバージョンにおいて必須となりました。これはα版のAPIでの`runtimeHandler`フィールドもまた必須であることを意味します。 -- `handler`フィールドは正しいDNSラベルの形式である必要があり([RFC 1123](https://tools.ietf.org/html/rfc1123))、これは`.`文字はもはや含むことができないことを意味します(全てのバージョンにおいて)。有効なハンドラー名は、次の正規表現に従います。`^[a-z0-9]([-a-z0-9]*[a-z0-9])?$` - -**Action Required:** 次のアクションはRuntimeClassのα版からβ版へのアップグレードにおいて対応が必須です。 - -- RuntimeClassリソースはKubernetes v1.14にアップグレードされた*後に* 再作成されなくてはなりません。そして`runtimeclasses.node.k8s.io`というCRDは手動で削除されるべきです。 - ``` - kubectl delete customresourcedefinitions.apiextensions.k8s.io runtimeclasses.node.k8s.io - ``` -- `runtimeHandler`の指定がないか、もしくは空文字の場合や、ハンドラー名に`.`文字列が使われている場合はα版のRuntimeClassにおいてもはや有効ではありません。正しい形式のハンドラー設定に変更しなくてはなりません(先ほど記載した内容を確認ください)。 - - -### 参考文献 +## {{% heading "次の項目" %}} - [RuntimeClassデザイン](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class.md) - [RuntimeClassスケジューリングデザイン](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class-scheduling.md) From b90563f347647985101af05751a9e44aaaf68994 Mon Sep 17 00:00:00 2001 From: Jin Hase Date: Fri, 21 Aug 2020 09:45:26 +0900 Subject: [PATCH 005/252] Update content/ja/docs/concepts/containers/runtime-class.md Co-authored-by: makocchi --- content/ja/docs/concepts/containers/runtime-class.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/containers/runtime-class.md b/content/ja/docs/concepts/containers/runtime-class.md index c902cd704c..c170e7fced 100644 --- a/content/ja/docs/concepts/containers/runtime-class.md +++ b/content/ja/docs/concepts/containers/runtime-class.md @@ -147,7 +147,7 @@ PodのオーバーヘッドはRuntimeClass内の`overhead`フィールドによ このフィールドを使用することで、RuntimeClassを使用して稼働するPodのオーバーヘッドを指定することができ、Kubernetes内部で使用されるオーバーヘッドを確保することができます。 -## {{% heading "次の項目" %}} +## {{% heading "whatsnext" %}} - [RuntimeClassデザイン](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class.md) - [RuntimeClassスケジューリングデザイン](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class-scheduling.md) From 0a75fa0baef51c4fa75b27e8fa04a2b73fef3385 Mon Sep 17 00:00:00 2001 From: Jin Hase Date: Fri, 21 Aug 2020 13:02:31 +0900 Subject: [PATCH 006/252] Update content/ja/docs/concepts/containers/runtime-class.md Co-authored-by: Naoki Oketani --- content/ja/docs/concepts/containers/runtime-class.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/containers/runtime-class.md b/content/ja/docs/concepts/containers/runtime-class.md index c170e7fced..c16b522af9 100644 --- a/content/ja/docs/concepts/containers/runtime-class.md +++ b/content/ja/docs/concepts/containers/runtime-class.md @@ -30,7 +30,7 @@ RuntimeClass機能のフィーチャーゲートが有効になっているこ 1. ノード上でCRI実装を設定する。(ランタイムに依存) 2. 対応するRuntimeClassリソースを作成する。 -### 1. ノード上でCRI実装を設定する。 +### 1. ノード上でCRI実装を設定する RuntimeClassを通じて利用可能な設定はContainer Runtime Interface (CRI)の実装依存となります。 ユーザーの環境のCRI実装の設定方法は、対応するドキュメント([下記](#cri-configuration))を参照ください。 From 9731c566a8ff6199d24416b7168f6cc7300d2bf1 Mon Sep 17 00:00:00 2001 From: Jin Hase Date: Fri, 21 Aug 2020 13:02:42 +0900 Subject: [PATCH 007/252] Update content/ja/docs/concepts/containers/runtime-class.md Co-authored-by: Naoki Oketani --- content/ja/docs/concepts/containers/runtime-class.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/containers/runtime-class.md b/content/ja/docs/concepts/containers/runtime-class.md index c16b522af9..395a520eb5 100644 --- a/content/ja/docs/concepts/containers/runtime-class.md +++ b/content/ja/docs/concepts/containers/runtime-class.md @@ -117,7 +117,7 @@ table](https://github.com/cri-o/cri-o/blob/master/docs/crio.conf.5.md#crioruntim runtime_path = "${PATH_TO_BINARY}" ``` -CRI-Oの[設定に関するドキュメント](https://raw.githubusercontent.com/cri-o/cri-o/9f11d1d/docs/crio.conf.5.md)の詳細は下記を参照してください。 +詳細はCRI-Oの[設定に関するドキュメント](https://raw.githubusercontent.com/cri-o/cri-o/9f11d1d/docs/crio.conf.5.md)を参照してください。 ## スケジューリング {#scheduling} From cd625d0a520fcec0548d6f3622b4f72c3b758394 Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Tue, 25 Aug 2020 22:06:31 +0900 Subject: [PATCH 008/252] Update run-replicated-stateful-application.md --- .../run-application/run-replicated-stateful-application.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/tasks/run-application/run-replicated-stateful-application.md b/content/ja/docs/tasks/run-application/run-replicated-stateful-application.md index d76e60f5c3..3fb8a88efd 100644 --- a/content/ja/docs/tasks/run-application/run-replicated-stateful-application.md +++ b/content/ja/docs/tasks/run-application/run-replicated-stateful-application.md @@ -23,7 +23,7 @@ weight: 30 * {{< include "default-storage-class-prereqs.md" >}} * このチュートリアルは、あなたが[PersistentVolume](/docs/concepts/storage/persistent-volumes/) と[StatefulSet](/ja/docs/concepts/workloads/controllers/statefulset/)、 - さらには[Pod](/ja/docs/concepts/workloads/pods/pod/)、 + さらには[Pod](/ja/docs/concepts/workloads/pods/)、 [Service](/ja/docs/concepts/services-networking/service/)、 [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/)などの 他のコアな概念に精通していることを前提としています。 @@ -264,7 +264,7 @@ Podを強制的にReadyではない状態にする間、上記の`SELECT @@serve ### Readiness Probeを壊す `mysql`コンテナに対する -[readiness probe](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/#define-readiness-probes) +[readiness probe](/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-readiness-probes) は、`mysql -h 127.0.0.1 -e 'SELECT 1'`コマンドを実行することで、サーバーが起動していてクエリーが実行できることを確認します。 このreadiness probeを失敗させる1つの方法は、そのコマンドを壊すことです。 From 1b30cc320b5225f23f5db52d2178810f0c2bd00d Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Tue, 25 Aug 2020 22:10:50 +0900 Subject: [PATCH 009/252] Update run-replicated-stateful-application.md --- .../run-application/run-replicated-stateful-application.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/run-application/run-replicated-stateful-application.md b/content/ja/docs/tasks/run-application/run-replicated-stateful-application.md index 3fb8a88efd..4d21a034b7 100644 --- a/content/ja/docs/tasks/run-application/run-replicated-stateful-application.md +++ b/content/ja/docs/tasks/run-application/run-replicated-stateful-application.md @@ -25,7 +25,7 @@ weight: 30 と[StatefulSet](/ja/docs/concepts/workloads/controllers/statefulset/)、 さらには[Pod](/ja/docs/concepts/workloads/pods/)、 [Service](/ja/docs/concepts/services-networking/service/)、 - [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/)などの + [ConfigMap](/ja/docs/tasks/configure-pod-container/configure-pod-configmap/)などの 他のコアな概念に精通していることを前提としています。 * MySQLに関する知識は記事の理解に役立ちますが、 このチュートリアルは他のシステムにも役立つ一般的なパターンを提示することを目的としています。 From dd216b3ffc4ab15352fa4d54011416e48cc09a71 Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Tue, 25 Aug 2020 22:13:15 +0900 Subject: [PATCH 010/252] Update run-replicated-stateful-application.md --- .../run-application/run-replicated-stateful-application.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/run-application/run-replicated-stateful-application.md b/content/ja/docs/tasks/run-application/run-replicated-stateful-application.md index 4d21a034b7..18b4dda5bb 100644 --- a/content/ja/docs/tasks/run-application/run-replicated-stateful-application.md +++ b/content/ja/docs/tasks/run-application/run-replicated-stateful-application.md @@ -21,7 +21,7 @@ weight: 30 * {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} * {{< include "default-storage-class-prereqs.md" >}} -* このチュートリアルは、あなたが[PersistentVolume](/docs/concepts/storage/persistent-volumes/) +* このチュートリアルは、あなたが[PersistentVolume](/ja/docs/concepts/storage/persistent-volumes/) と[StatefulSet](/ja/docs/concepts/workloads/controllers/statefulset/)、 さらには[Pod](/ja/docs/concepts/workloads/pods/)、 [Service](/ja/docs/concepts/services-networking/service/)、 From 916881f70f4b8210108d6534bbff7a7b8b3365cc Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Thu, 27 Aug 2020 12:51:04 +0900 Subject: [PATCH 011/252] update ja communicate-containers-same-pod-shared-volume.md --- .../communicate-containers-same-pod-shared-volume.md | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/content/ja/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md b/content/ja/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md index fa5cc9f976..c5a2e88c01 100644 --- a/content/ja/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md +++ b/content/ja/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md @@ -6,7 +6,7 @@ weight: 110 -このページでは、ボリュームを使用して、同じPodで実行されている2つのコンテナ間で通信する方法を示します。 +このページでは、ボリュームを使用して、同じPodで実行されている2つのコンテナ間で通信する方法を示します。 コンテナ間で[プロセス名前空間を共有する](/ja/docs/tasks/configure-pod-container/share-process-namespace/)ことにより、プロセスが通信できるようにする方法も参照してください。 @@ -100,12 +100,15 @@ nginxコンテナへのシェルを取得します: debianコンテナがnginxルートディレクトリに`index.html`ファイルを作成したことを思い出してください。 `curl`を使用して、GETリクエストをnginxサーバーに送信します: - root@two-containers:/# curl localhost +``` +root@two-containers:/# curl localhost +``` 出力は、nginxがdebianコンテナによって書かれたWebページを提供することを示しています: - Hello from the debian container - +``` +Hello from the debian container +``` From 821aeb70ba4d7b4db8c3c06ea940d807ce941d39 Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Thu, 27 Aug 2020 12:54:28 +0900 Subject: [PATCH 012/252] update ja communicate-containers-same-pod-shared-volume.md --- .../communicate-containers-same-pod-shared-volume.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md b/content/ja/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md index c5a2e88c01..8a0d37d28e 100644 --- a/content/ja/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md +++ b/content/ja/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md @@ -6,7 +6,7 @@ weight: 110 -このページでは、ボリュームを使用して、同じPodで実行されている2つのコンテナ間で通信する方法を示します。 +このページでは、ボリュームを使用して、同じPodで実行されている2つのコンテナ間で通信する方法を示します。 コンテナ間で[プロセス名前空間を共有する](/ja/docs/tasks/configure-pod-container/share-process-namespace/)ことにより、プロセスが通信できるようにする方法も参照してください。 From 469e3ba973314f9abd50cb5064c9ad0a6441c207 Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Thu, 27 Aug 2020 17:53:56 +0900 Subject: [PATCH 013/252] Update garbage-collection.md --- .../docs/concepts/workloads/controllers/garbage-collection.md | 3 --- 1 file changed, 3 deletions(-) diff --git a/content/ja/docs/concepts/workloads/controllers/garbage-collection.md b/content/ja/docs/concepts/workloads/controllers/garbage-collection.md index 264984bae7..3a1e630d20 100644 --- a/content/ja/docs/concepts/workloads/controllers/garbage-collection.md +++ b/content/ja/docs/concepts/workloads/controllers/garbage-collection.md @@ -83,9 +83,6 @@ Kubernetes1.7では、認証されていない従属オブジェクトがオー カスケード削除ポリシーを制御するためには、オブジェクトをいつ設定するか`deleteOptions`引数上の`propagationPolicy`フィールドに設定してください。設定可能な値は`Orphan`、`Foreground`、もしくは`Background`のどれかです。 -Kubernetes1.9以前では多くのコントローラーにおけるデフォルトのガベージコレクションポリシーは`orphan`でした。 -この対象のコントローラーはReplicationController、ReplicaSet、StatefulSet、DaemonSetとDeploymentを含みます。`extensions/v1beta1`、`apps/v1beta1`、`apps/v1beta2`のグループバージョンに含まれるオブジェクト種においては、もしユーザーがガベージコレクションに他の値を設定しない限り、デフォルトで従属オブジェクトはみなしご(orphaned)になります。 -Kubernetes1.9において、`apps/v1`というグループバージョンにおいて、従属オブジェクトはデフォルトで削除されます。 下記のコマンドは従属オブジェクトをバックグラウンドで削除する例です。 From 2de0c23a1fee634b99a061a44c1d59ecf904a55e Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Thu, 27 Aug 2020 14:52:18 +0900 Subject: [PATCH 014/252] Update install-service-catalog-using-helm.md --- .../tasks/service-catalog/install-service-catalog-using-helm.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/service-catalog/install-service-catalog-using-helm.md b/content/ja/docs/tasks/service-catalog/install-service-catalog-using-helm.md index bd9bc35465..eced279efc 100644 --- a/content/ja/docs/tasks/service-catalog/install-service-catalog-using-helm.md +++ b/content/ja/docs/tasks/service-catalog/install-service-catalog-using-helm.md @@ -13,7 +13,7 @@ content_type: task ## {{% heading "prerequisites" %}} -* [サービスカタログ](/docs/concepts/service-catalog/)の基本概念を理解してください。 +* [サービスカタログ](/docs/concepts/extend-kubernetes/service-catalog/)の基本概念を理解してください。 * サービスカタログを使用するには、Kubernetesクラスターのバージョンが1.7以降である必要があります。 * KubernetesクラスターのクラスターDNSを有効化する必要があります。 * クラウド上のKubernetesクラスター、または{{< glossary_tooltip text="Minikube" term_id="minikube" >}}を使用している場合、クラスターDNSはすでに有効化されています。 From 8c762dc6a6909b8aaf1171252587ca3bbe4fdc27 Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Thu, 27 Aug 2020 18:22:51 +0900 Subject: [PATCH 015/252] Update replicaset.md --- .../ja/docs/concepts/workloads/controllers/replicaset.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/ja/docs/concepts/workloads/controllers/replicaset.md b/content/ja/docs/concepts/workloads/controllers/replicaset.md index f554ffb55c..9f8ccfc377 100644 --- a/content/ja/docs/concepts/workloads/controllers/replicaset.md +++ b/content/ja/docs/concepts/workloads/controllers/replicaset.md @@ -2,7 +2,7 @@ reviewers: title: ReplicaSet content_type: concept -weight: 10 +weight: 20 --- @@ -207,9 +207,9 @@ ReplicaSetオブジェクトの名前は、有効な `.spec.selector`フィールドは[ラベルセレクター](/ja/docs/concepts/overview/working-with-objects/labels/)です。 [先ほど](#how-a-replicaset-works)議論したように、ReplicaSetが所有するPodを指定するためにそのラベルが使用されます。 先ほどの`frontend.yaml`の例では、そのセレクターは下記のようになっていました -```shell +```yaml matchLabels: - tier: frontend + tier: frontend ``` そのReplicaSetにおいて、`.spec.template.metadata.labels`フィールドの値は`spec.selector`と一致しなくてはならず、一致しない場合はAPIによって拒否されます。 @@ -281,7 +281,7 @@ kubectl apply -f https://k8s.io/examples/controllers/hpa-rs.yaml 同様のことを行うための代替案として、`kubectl autoscale`コマンドも使用できます。(こちらの方がより簡単です。) ```shell -kubectl autoscale rs frontend --max=10 +kubectl autoscale rs frontend --max=10 --min=3 --cpu-percent=50 ``` ## ReplicaSetの代替案 From 26a8a1ce637bd74bceadc75c8b3a9fa24e040a29 Mon Sep 17 00:00:00 2001 From: Jin Hase Date: Thu, 27 Aug 2020 19:53:55 +0900 Subject: [PATCH 016/252] Update Japanese localization on tasks/inject-data-application/define-environment-variable-container.md --- .../define-environment-variable-container.md | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/content/ja/docs/tasks/inject-data-application/define-environment-variable-container.md b/content/ja/docs/tasks/inject-data-application/define-environment-variable-container.md index 3457783864..2427603f35 100644 --- a/content/ja/docs/tasks/inject-data-application/define-environment-variable-container.md +++ b/content/ja/docs/tasks/inject-data-application/define-environment-variable-container.md @@ -22,11 +22,11 @@ weight: 20 Podを作成するとき、そのPodで実行するコンテナに環境変数を設定することができます。環境変数を設定するには、設定ファイルに `env` または `envFrom` フィールドを含めます。 -この演習では、1つのコンテナを実行するPodを作成します。Podの設定ファイルには、名前 `DEMO_GREETING`、値 `"Hello from the environment"`を持つ環境変数が定義されています。Podの設定ファイルを以下に示します: +この演習では、1つのコンテナを実行するPodを作成します。Podの設定ファイルには、名前 `DEMO_GREETING`、値 `"Hello from the environment"`を持つ環境変数が定義されています。Podの設定マニフェストを以下に示します: {{< codenew file="pods/inject/envars.yaml" >}} -1. YAML設定ファイルに基づいてPodを作成します: +1. マニフェストに基づいてPodを作成します: ```shell kubectl apply -f https://k8s.io/examples/pods/inject/envars.yaml @@ -54,7 +54,8 @@ Podを作成するとき、そのPodで実行するコンテナに環境変数 1. シェルで`printenv`コマンドを実行すると、環境変数の一覧が表示されます。 ```shell - root@envar-demo:/# printenv + # コンテナ内のシェルで以下のコマンドを実行します + printenv ``` 出力は以下のようになります: @@ -74,6 +75,10 @@ Podを作成するとき、そのPodで実行するコンテナに環境変数 `env`または`envFrom`フィールドを使用して設定された環境変数は、コンテナイメージで指定された環境変数を上書きします。 {{< /note >}} +{{< note >}} +環境変数は相互に参照でき、循環して使用可能です。使用する前に順序に注意してください。 +{{< /note >}} + ## 設定の中で環境変数を使用する {#using-environment-variables-inside-of-your-config} Podの設定で定義した環境変数は、Podのコンテナに設定したコマンドや引数など、設定の他の場所で使用することができます。以下の設定例では、環境変数`GREETING`、`HONORORIFIC`、`NAME`にそれぞれ `Warm greetings to`、`The Most Honorable`、`Kubernetes`を設定しています。これらの環境変数は、`env-print-demo`コンテナに渡されるCLI引数で使われます。 From ac62dadf5b123e9df89f35b6bd1c492f05ee0687 Mon Sep 17 00:00:00 2001 From: tkms0106 <23391543+tkms0106@users.noreply.github.com> Date: Tue, 25 Aug 2020 18:49:54 +0900 Subject: [PATCH 017/252] Update content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md to follow v1.18 of the original (English) text --- .../configure-liveness-readiness-startup-probes.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md index bd5ec92082..68929ec5bb 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md @@ -8,7 +8,7 @@ weight: 110 このページでは、Liveness Probe、Readiness ProbeおよびStartup Probeの使用方法について説明します。 -[kubelet](/docs/admin/kubelet/)は、Liveness Probeを使用して、コンテナをいつ再起動するかを認識します。 +[kubelet](/docs/reference/command-line-tools-reference/kubelet/)は、Liveness Probeを使用して、コンテナをいつ再起動するかを認識します。 例えば、アプリケーション自体は起動しているが、処理を継続することができないデッドロック状態を検知することができます。 このような状態のコンテナを再起動することで、バグがある場合でもアプリケーションの可用性を高めることができます。 @@ -296,7 +296,7 @@ Liveness ProbeおよびReadiness Probeのチェック動作をより正確に制 * `timeoutSeconds`: Probeがタイムアウトになるまでの秒数。デフォルトは1秒。最小値は1。 * `successThreshold`: 一度Probeが失敗した後、次のProbeが成功したとみなされるための最小連続成功数。 デフォルトは1。Liveness Probeには1を設定する必要があります。最小値は1。 -* `failureThreshold`: Podが開始してProbeが失敗した場合、Kubernetesは`failureThreshold`に設定した回数までProbeを試行します。 +* `failureThreshold`: Probeが失敗した場合、Kubernetesは`failureThreshold`に設定した回数までProbeを試行します。 Liveness Probeにおいて、試行回数に到達することはコンテナを再起動することを意味します。 Readiness Probeの場合は、Podが準備できていない状態として通知されます。デフォルトは3。最小値は1。 From 1b0b3099018a4c4216ac1a89458ec02036eda3c7 Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Tue, 25 Aug 2020 21:27:52 +0900 Subject: [PATCH 018/252] Update run-stateless-application-deployment.md --- .../run-application/run-stateless-application-deployment.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/run-application/run-stateless-application-deployment.md b/content/ja/docs/tasks/run-application/run-stateless-application-deployment.md index 88a35b7d84..963df78524 100644 --- a/content/ja/docs/tasks/run-application/run-stateless-application-deployment.md +++ b/content/ja/docs/tasks/run-application/run-stateless-application-deployment.md @@ -96,7 +96,7 @@ Kubernetes Deploymentオブジェクトを作成することでアプリケー ## Deploymentの更新 -新しいYAMLファイルを適用してDeploymentを更新できます。このYAMLファイルは、Deploymentを更新してnginx 1.8を使用するように指定しています。 +新しいYAMLファイルを適用してDeploymentを更新できます。このYAMLファイルは、Deploymentを更新してnginx 1.16.1を使用するように指定しています。 {{< codenew file="application/deployment-update.yaml" >}} From 5fc11ca307d69e8d62ecb016ecc92276f2476bc2 Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Wed, 26 Aug 2020 20:01:25 +0900 Subject: [PATCH 019/252] Update install-service-catalog-using-sc.md --- .../tasks/service-catalog/install-service-catalog-using-sc.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/service-catalog/install-service-catalog-using-sc.md b/content/ja/docs/tasks/service-catalog/install-service-catalog-using-sc.md index a0211e2a18..86b4e589e6 100644 --- a/content/ja/docs/tasks/service-catalog/install-service-catalog-using-sc.md +++ b/content/ja/docs/tasks/service-catalog/install-service-catalog-using-sc.md @@ -12,7 +12,7 @@ GCPの[Service Catalog Installer](https://github.com/GoogleCloudPlatform/k8s-ser ## {{% heading "prerequisites" %}} -* [サービスカタログ](/docs/concepts/service-catalog/)の基本概念を理解してください。 +* [サービスカタログ](/docs/concepts/extend-kubernetes/service-catalog/)の基本概念を理解してください。 * [Go 1.6+](https://golang.org/dl/)をインストールして、`GOPATH`を設定してください。 * SSLに関するファイルを生成するために必要な[cfssl](https://github.com/cloudflare/cfssl)ツールをインストールしてください。 * サービスカタログを使用するには、Kubernetesクラスターのバージョンが1.7以降である必要があります。 From fcee7bcc7f7115a842f93c1fd37d246e93b3149a Mon Sep 17 00:00:00 2001 From: Jin Hase Date: Thu, 27 Aug 2020 20:42:11 +0900 Subject: [PATCH 020/252] Update Japanese localization on tasks/run-application/_index.md --- content/ja/docs/tasks/run-application/_index.md | 1 + 1 file changed, 1 insertion(+) diff --git a/content/ja/docs/tasks/run-application/_index.md b/content/ja/docs/tasks/run-application/_index.md index c00f88f4bb..17d2339e7e 100755 --- a/content/ja/docs/tasks/run-application/_index.md +++ b/content/ja/docs/tasks/run-application/_index.md @@ -1,5 +1,6 @@ --- title: "アプリケーションの実行" +description: ステートレスアプリケーションとステートフルアプリケーションの両方を実行および管理します。 weight: 40 --- From a0e8cf7913d05169174f69041ce7b0174c6b070d Mon Sep 17 00:00:00 2001 From: Jin Hase Date: Thu, 27 Aug 2020 19:22:13 +0900 Subject: [PATCH 021/252] Update Japanese localization on tasks/inject-data-application/_index.md --- content/ja/docs/tasks/inject-data-application/_index.md | 1 + 1 file changed, 1 insertion(+) diff --git a/content/ja/docs/tasks/inject-data-application/_index.md b/content/ja/docs/tasks/inject-data-application/_index.md index 52c5ca5128..a28c380a26 100644 --- a/content/ja/docs/tasks/inject-data-application/_index.md +++ b/content/ja/docs/tasks/inject-data-application/_index.md @@ -1,4 +1,5 @@ --- title: "アプリケーションへのデータ注入" +description: ワークロードを実行するPodの構成とその他のデータを指定します。 weight: 30 --- From 4343035a9195d020d54fd184b726e64196f86964 Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Fri, 28 Aug 2020 22:06:05 +0900 Subject: [PATCH 022/252] Update quality-service-pod.md --- .../configure-pod-container/quality-service-pod.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/content/ja/docs/tasks/configure-pod-container/quality-service-pod.md b/content/ja/docs/tasks/configure-pod-container/quality-service-pod.md index 010af1dc64..012921d2bf 100644 --- a/content/ja/docs/tasks/configure-pod-container/quality-service-pod.md +++ b/content/ja/docs/tasks/configure-pod-container/quality-service-pod.md @@ -241,17 +241,17 @@ kubectl delete namespace qos-example ### クラスター管理者向け -* [Namespaceにメモリー要求および制限のデフォルト値を設定する](/docs/tasks/administer-cluster/memory-default-namespace/) +* [Namespaceにメモリー要求および制限のデフォルト値を設定する](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/) -* [NamespaceにCPU要求および制限のデフォルト値を設定する](/docs/tasks/administer-cluster/cpu-default-namespace/) +* [NamespaceにCPU要求および制限のデフォルト値を設定する](/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/) -* [Namespaceに最小および最大メモリー量の制約を設定する](/docs/tasks/administer-cluster/memory-constraint-namespace/) +* [Namespaceに最小および最大メモリー量の制約を設定する](/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/) -* [Namespaceに最小および最大のCPU使用量の制約を設定する](/docs/tasks/administer-cluster/cpu-constraint-namespace/) +* [Namespaceに最小および最大のCPU使用量の制約を設定する](/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/) -* [NamespaceにメモリーおよびCPUのクォータを設定する](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/) +* [NamespaceにメモリーおよびCPUのクォータを設定する](/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/) -* [NamespaceにPodのクォータを設定する](/docs/tasks/administer-cluster/quota-pod-namespace/) +* [NamespaceにPodのクォータを設定する](/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace/) * [APIオブジェクトのクォータを設定する](/docs/tasks/administer-cluster/quota-api-object/) From 045cf0cc246a99c43fc560f254c82d9e9a95ae6e Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Tue, 25 Aug 2020 12:10:16 +0900 Subject: [PATCH 023/252] update controller.md --- content/ja/docs/concepts/architecture/controller.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/content/ja/docs/concepts/architecture/controller.md b/content/ja/docs/concepts/architecture/controller.md index 0a13635fe8..9a01c2d485 100644 --- a/content/ja/docs/concepts/architecture/controller.md +++ b/content/ja/docs/concepts/architecture/controller.md @@ -62,12 +62,10 @@ Kubernetesはシステムに対してクラウドネイティブな見方をす ## 設計 -設計理念として、Kubernetesは多数のコントローラーを使用しており、各コントローラーはクラスターの状態の特定の側面をそれぞれ管理しています。最もよくあるパターンは、特定の制御ループ(コントローラー)が目的の状態として1種類のリソースを使用し、目的の状態を実現することを管理するために別の種類のリソースを用意するというものです。 +設計理念として、Kubernetesは多数のコントローラーを使用しており、各コントローラーはクラスターの状態の特定の側面をそれぞれ管理しています。最もよくあるパターンは、特定の制御ループ(コントローラー)が目的の状態として1種類のリソースを使用し、目的の状態を実現することを管理するために別の種類のリソースを用意するというものです。 たとえば、Jobのコントローラーは、Jobオブジェクト(新しい処理を見つけるため)およびPodオブジェクト(Jobを実行し、処理が完了したか確認するため)を監視します。この場合、なにか別のものがJobを作成し、JobコントローラーはPodを作成します。 相互にリンクされた単一のモノリシックな制御ループよりは、複数の単純なコントローラーが存在する方が役に立ちます。コントローラーは故障することがあるため、Kubernetesは故障を許容するように設計されています。 -たとえば、Jobのコントローラーは、Jobオブジェクト(新しい処理を見つけるため)およびPodオブジェクト(Jobを実行し、処理が完了したか確認するため)を監視します。この場合、なにか別のものがJobを作成し、JobコントローラーはPodを作成します。 - {{< note >}} 同じ種類のオブジェクトを作成または更新するコントローラーが、複数存在する場合があります。実際には、Kubernetesコントローラーは、自分が制御するリソースに関連するリソースにのみ注意を払うように作られています。 @@ -88,3 +86,4 @@ Kubernetesを拡張するためにコントロールプレーンの外で動作 * 基本的な[Kubernetesオブジェクト](/ja/docs/concepts/#kubernetes-objects)について学ぶ * [Kubernetes API](/ja/docs/concepts/overview/kubernetes-api/)について学ぶ * 自分でコントローラーを書きたい場合は、「Kubernetesを拡張する」の[エクステンションパターン](/ja/docs/concepts/extend-kubernetes/extend-cluster/#extension-patterns)を読んでください。 + From ab82c697f491c070ac585a6af276598567aa63a8 Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Tue, 25 Aug 2020 17:10:24 +0900 Subject: [PATCH 024/252] delete unnecessary space --- content/ja/docs/concepts/architecture/controller.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/architecture/controller.md b/content/ja/docs/concepts/architecture/controller.md index 9a01c2d485..c2f71c9029 100644 --- a/content/ja/docs/concepts/architecture/controller.md +++ b/content/ja/docs/concepts/architecture/controller.md @@ -62,7 +62,7 @@ Kubernetesはシステムに対してクラウドネイティブな見方をす ## 設計 -設計理念として、Kubernetesは多数のコントローラーを使用しており、各コントローラーはクラスターの状態の特定の側面をそれぞれ管理しています。最もよくあるパターンは、特定の制御ループ(コントローラー)が目的の状態として1種類のリソースを使用し、目的の状態を実現することを管理するために別の種類のリソースを用意するというものです。 たとえば、Jobのコントローラーは、Jobオブジェクト(新しい処理を見つけるため)およびPodオブジェクト(Jobを実行し、処理が完了したか確認するため)を監視します。この場合、なにか別のものがJobを作成し、JobコントローラーはPodを作成します。 +設計理念として、Kubernetesは多数のコントローラーを使用しており、各コントローラーはクラスターの状態の特定の側面をそれぞれ管理しています。最もよくあるパターンは、特定の制御ループ(コントローラー)が目的の状態として1種類のリソースを使用し、目的の状態を実現することを管理するために別の種類のリソースを用意するというものです。たとえば、Jobのコントローラーは、Jobオブジェクト(新しい処理を見つけるため)およびPodオブジェクト(Jobを実行し、処理が完了したか確認するため)を監視します。この場合、なにか別のものがJobを作成し、JobコントローラーはPodを作成します。 相互にリンクされた単一のモノリシックな制御ループよりは、複数の単純なコントローラーが存在する方が役に立ちます。コントローラーは故障することがあるため、Kubernetesは故障を許容するように設計されています。 From 7f5c052bf829cf7f0223eca94ca4416a4dc7b5fd Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Tue, 25 Aug 2020 00:03:02 +0900 Subject: [PATCH 025/252] Update debug-stateful-set.md --- .../docs/tasks/debug-application-cluster/debug-stateful-set.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/debug-stateful-set.md b/content/ja/docs/tasks/debug-application-cluster/debug-stateful-set.md index 2f42f38cc2..d0fffb6b95 100644 --- a/content/ja/docs/tasks/debug-application-cluster/debug-stateful-set.md +++ b/content/ja/docs/tasks/debug-application-cluster/debug-stateful-set.md @@ -27,7 +27,7 @@ StatefulSetに属し、ラベル`app=myapp`が設定されているすべてのP kubectl get pods -l app=myapp ``` -Podが長期間`Unknown`または`Terminating`の状態になっていることがわかった場合は、それらを処理する方法について[StatefulSet Podsの削除](/docs/tasks/manage-stateful-set/delete-pods/)タスクを参照してください。 +Podが長期間`Unknown`または`Terminating`の状態になっていることがわかった場合は、それらを処理する方法について[StatefulSet Podsの削除](/docs/tasks/run-application/delete-stateful-set/)タスクを参照してください。 [Podのデバッグ](/docs/tasks/debug-application-cluster/debug-pod-replication-controller/)ガイドを使用して、StatefulSet内の個々のPodをデバッグできます。 From acea56b17ae2e283ea54a9d3be4b58274f72a29b Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Sat, 29 Aug 2020 19:37:59 +0900 Subject: [PATCH 026/252] Update content/ja/docs/tasks/debug-application-cluster/debug-stateful-set.md Co-authored-by: inductor(Kohei) --- .../docs/tasks/debug-application-cluster/debug-stateful-set.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/debug-stateful-set.md b/content/ja/docs/tasks/debug-application-cluster/debug-stateful-set.md index d0fffb6b95..0cafaa28e5 100644 --- a/content/ja/docs/tasks/debug-application-cluster/debug-stateful-set.md +++ b/content/ja/docs/tasks/debug-application-cluster/debug-stateful-set.md @@ -27,7 +27,7 @@ StatefulSetに属し、ラベル`app=myapp`が設定されているすべてのP kubectl get pods -l app=myapp ``` -Podが長期間`Unknown`または`Terminating`の状態になっていることがわかった場合は、それらを処理する方法について[StatefulSet Podsの削除](/docs/tasks/run-application/delete-stateful-set/)タスクを参照してください。 +Podが長期間`Unknown`または`Terminating`の状態になっていることがわかった場合は、それらを処理する方法について[StatefulSet Podの強制削除](/ja/docs/tasks/run-application/delete-stateful-set/)タスクを参照してください。 [Podのデバッグ](/docs/tasks/debug-application-cluster/debug-pod-replication-controller/)ガイドを使用して、StatefulSet内の個々のPodをデバッグできます。 @@ -39,4 +39,3 @@ Podが長期間`Unknown`または`Terminating`の状態になっていること - From ae2fedaf19041f4db5d5607cc7176b9834ef8362 Mon Sep 17 00:00:00 2001 From: hideUW Date: Sun, 23 Aug 2020 21:42:39 -0700 Subject: [PATCH 027/252] Update the document to follow v1.18. --- .../get-shell-running-container.md | 63 +++++++++++-------- 1 file changed, 36 insertions(+), 27 deletions(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/get-shell-running-container.md b/content/ja/docs/tasks/debug-application-cluster/get-shell-running-container.md index 684fa981c1..60ac92f614 100644 --- a/content/ja/docs/tasks/debug-application-cluster/get-shell-running-container.md +++ b/content/ja/docs/tasks/debug-application-cluster/get-shell-running-container.md @@ -43,7 +43,7 @@ kubectl get pod shell-demo 実行中のコンテナへのシェルを取得します: ```shell -kubectl exec -it shell-demo -- /bin/bash +kubectl exec --stdin --tty shell-demo -- /bin/bash ``` {{< note >}} @@ -54,23 +54,25 @@ kubectl exec -it shell-demo -- /bin/bash シェル内で、ルートディレクトリーのファイル一覧を表示します: ```shell -root@shell-demo:/# ls / +# このコマンドをコンテナ内で実行します +ls / ``` シェル内で、他のコマンドを試しましょう。以下がいくつかの例です: ```shell -root@shell-demo:/# ls / -root@shell-demo:/# cat /proc/mounts -root@shell-demo:/# cat /proc/1/maps -root@shell-demo:/# apt-get update -root@shell-demo:/# apt-get install -y tcpdump -root@shell-demo:/# tcpdump -root@shell-demo:/# apt-get install -y lsof -root@shell-demo:/# lsof -root@shell-demo:/# apt-get install -y procps -root@shell-demo:/# ps aux -root@shell-demo:/# ps aux | grep nginx +# これらのサンプルコマンドをコンテナ内で実行することができます +ls / +cat /proc/mounts +cat /proc/1/maps +apt-get update +apt-get install -y tcpdump +tcpdump +apt-get install -y lsof +lsof +apt-get install -y procps +ps aux +ps aux | grep nginx ``` ## nginxのルートページへの書き込み @@ -81,25 +83,31 @@ Podの設定ファイルを再度確認します。Podは`emptyDir`ボリュー シェル内で、`/usr/share/nginx/html`ディレクトリに`index.html`を作成します。 ```shell -root@shell-demo:/# echo Hello shell demo > /usr/share/nginx/html/index.html +# このコマンドをコンテナ内で実行します +echo 'Hello shell demo' > /usr/share/nginx/html/index.html ``` シェル内で、nginxサーバーにGETリクエストを送信します: ```shell -root@shell-demo:/# apt-get update -root@shell-demo:/# apt-get install curl -root@shell-demo:/# curl localhost +# これらのコマンドをコンテナ内のシェルで実行します +apt-get update +apt-get install curl +curl http://localhost/ ``` 出力に`index.html`ファイルに書き込んだ文字列が表示されます: -```shell +``` Hello shell demo ``` シェルを終了する場合、`exit`を入力します。 +```shell +exit # コンテナ内のシェルを終了する +``` + ## コンテナ内での各コマンドの実行 シェルではない通常のコマンドウインドウ内で、実行中のコンテナの環境変数の一覧を表示します: @@ -111,9 +119,9 @@ kubectl exec shell-demo env 他のコマンドを試します。以下がいくつかの例です: ```shell -kubectl exec shell-demo ps aux -kubectl exec shell-demo ls / -kubectl exec shell-demo cat /proc/1/mounts +kubectl exec shell-demo -- ps aux +kubectl exec shell-demo -- ls / +kubectl exec shell-demo -- cat /proc/1/mounts ``` @@ -123,20 +131,21 @@ kubectl exec shell-demo cat /proc/1/mounts ## Podが1つ以上のコンテナを持つ場合にシェルを開く Podが1つ以上のコンテナを持つ場合、`--container`か`-c`を使用して、`kubectl exec`コマンド内でコンテナを指定します。 -例えば、my-podという名前のPodがあり、そのPodがmain-appとhelper-appという2つのコンテナを持つとします。 -以下のコマンドはmain-appのコンテナへのシェルを開きます。 +例えば、my-podという名前のPodがあり、そのPodが _main-app_ と _helper-app_ という2つのコンテナを持つとします。 +以下のコマンドは _main-app_ のコンテナへのシェルを開きます。 ```shell -kubectl exec -it my-pod --container main-app -- /bin/bash +kubectl exec -i -t my-pod --container main-app -- /bin/bash ``` - - +{{< note >}} +ショートオプションの `-i` と `-t` は、ロングオプションの `--stdin` と `--tty` と同様です。 +{{< /note >}} ## {{% heading "whatsnext" %}} -* [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec) +* [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec)について読む。 From cc4ba71849a1fbe87e405191ded781ad6b4f0896 Mon Sep 17 00:00:00 2001 From: hide Date: Sun, 23 Aug 2020 21:55:01 -0700 Subject: [PATCH 028/252] Update content/ja/docs/tasks/debug-application-cluster/get-shell-running-container.md Co-authored-by: Naoki Oketani --- .../debug-application-cluster/get-shell-running-container.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/get-shell-running-container.md b/content/ja/docs/tasks/debug-application-cluster/get-shell-running-container.md index 60ac92f614..585916da42 100644 --- a/content/ja/docs/tasks/debug-application-cluster/get-shell-running-container.md +++ b/content/ja/docs/tasks/debug-application-cluster/get-shell-running-container.md @@ -139,7 +139,7 @@ kubectl exec -i -t my-pod --container main-app -- /bin/bash ``` {{< note >}} -ショートオプションの `-i` と `-t` は、ロングオプションの `--stdin` と `--tty` と同様です。 +ショートオプションの`-i`と`-t`は、ロングオプションの`--stdin`と`--tty`と同様です。 {{< /note >}} ## {{% heading "whatsnext" %}} @@ -150,4 +150,3 @@ kubectl exec -i -t my-pod --container main-app -- /bin/bash - From d083d397506fccdde3454cdb8fd6fdd979ceb810 Mon Sep 17 00:00:00 2001 From: hide Date: Sun, 30 Aug 2020 13:44:19 -0700 Subject: [PATCH 029/252] Update content/ja/docs/tasks/debug-application-cluster/get-shell-running-container.md Co-authored-by: inductor(Kohei) --- .../debug-application-cluster/get-shell-running-container.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/get-shell-running-container.md b/content/ja/docs/tasks/debug-application-cluster/get-shell-running-container.md index 585916da42..bada044869 100644 --- a/content/ja/docs/tasks/debug-application-cluster/get-shell-running-container.md +++ b/content/ja/docs/tasks/debug-application-cluster/get-shell-running-container.md @@ -145,8 +145,7 @@ kubectl exec -i -t my-pod --container main-app -- /bin/bash ## {{% heading "whatsnext" %}} -* [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec)について読む。 - +* [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec)について読む From a144437c21b110b28ffca3e181034d592943a0ad Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Wed, 26 Aug 2020 12:23:17 +0900 Subject: [PATCH 030/252] update ja/doc networking --- .../cluster-administration/networking.md | 33 +++++++++++-------- 1 file changed, 19 insertions(+), 14 deletions(-) diff --git a/content/ja/docs/concepts/cluster-administration/networking.md b/content/ja/docs/concepts/cluster-administration/networking.md index 53b899dc32..fa0fe884ff 100644 --- a/content/ja/docs/concepts/cluster-administration/networking.md +++ b/content/ja/docs/concepts/cluster-administration/networking.md @@ -9,7 +9,7 @@ weight: 50 ネットワークはKubernetesにおける中心的な部分ですが、どのように動作するかを正確に理解することは難解な場合もあります。 Kubernetesには、4つの異なる対応すべきネットワークの問題があります: -1. 高度に結合されたコンテナ間の通信: これは、[Pod](/ja/docs/concepts/workloads/pods/pod/)および`localhost`通信によって解決されます。 +1. 高度に結合されたコンテナ間の通信: これは、{{< glossary_tooltip text="Pods" term_id="pod" >}}および`localhost`通信によって解決されます。 2. Pod間の通信: 本ドキュメントの主な焦点です。 3. Podからサービスへの通信：これは[Service](/ja/docs/concepts/services-networking/service/)でカバーされています。 4. 外部からサービスへの通信：これは[Service](/ja/docs/concepts/services-networking/service/)でカバーされています。 @@ -67,7 +67,7 @@ Thanks to the "programmable" characteristic of Open vSwitch, Antrea is able to i ### AOS from Apstra -[AOS](http://www.apstra.com/products/aos/) is an Intent-Based Networking system that creates and manages complex datacenter environments from a simple integrated platform. AOS leverages a highly scalable distributed design to eliminate network outages while minimizing costs. +[AOS](https://www.apstra.com/products/aos/) is an Intent-Based Networking system that creates and manages complex datacenter environments from a simple integrated platform. AOS leverages a highly scalable distributed design to eliminate network outages while minimizing costs. The AOS Reference Design currently supports Layer-3 connected hosts that eliminate legacy Layer-2 switching problems. These Layer-3 hosts can be Linux servers (Debian, Ubuntu, CentOS) that create BGP neighbor relationships directly with the top of rack switches (TORs). AOS automates the routing adjacencies and then provides fine grained control over the route health injections (RHI) that are common in a Kubernetes deployment. @@ -75,7 +75,7 @@ AOS has a rich set of REST API endpoints that enable Kubernetes to quickly chang AOS supports the use of common vendor equipment from manufacturers including Cisco, Arista, Dell, Mellanox, HPE, and a large number of white-box systems and open network operating systems like Microsoft SONiC, Dell OPX, and Cumulus Linux. -Details on how the AOS system works can be accessed here: http://www.apstra.com/products/how-it-works/ +Details on how the AOS system works can be accessed here: https://www.apstra.com/products/how-it-works/ ### AWS VPC CNI for Kubernetes @@ -97,7 +97,7 @@ Azure CNI is available natively in the [Azure Kubernetes Service (AKS)] (https:/ With the help of the Big Cloud Fabric's virtual pod multi-tenant architecture, container orchestration systems such as Kubernetes, RedHat OpenShift, Mesosphere DC/OS & Docker Swarm will be natively integrated alongside with VM orchestration systems such as VMware, OpenStack & Nutanix. Customers will be able to securely inter-connect any number of these clusters and enable inter-tenant communication between them if needed. -BCF was recognized by Gartner as a visionary in the latest [Magic Quadrant](http://go.bigswitch.com/17GatedDocuments-MagicQuadrantforDataCenterNetworking_Reg.html). One of the BCF Kubernetes on-premises deployments (which includes Kubernetes, DC/OS & VMware running on multiple DCs across different geographic regions) is also referenced [here](https://portworx.com/architects-corner-kubernetes-satya-komala-nio/). +BCF was recognized by Gartner as a visionary in the latest [Magic Quadrant](https://go.bigswitch.com/17GatedDocuments-MagicQuadrantforDataCenterNetworking_Reg.html). One of the BCF Kubernetes on-premises deployments (which includes Kubernetes, DC/OS & VMware running on multiple DCs across different geographic regions) is also referenced [here](https://portworx.com/architects-corner-kubernetes-satya-komala-nio/). ### Cilium @@ -109,7 +109,7 @@ addressing, and it can be used in combination with other CNI plugins. ### CNI-Genie from Huawei -[CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) is a CNI plugin that enables Kubernetes to [simultaneously have access to different implementations](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-cni-plugins/README.md#what-cni-genie-feature-1-multiple-cni-plugins-enables) of the [Kubernetes network model](https://github.com/kubernetes/website/blob/master/content/en/docs/concepts/cluster-administration/networking.md#the-kubernetes-network-model) in runtime. This includes any implementation that runs as a [CNI plugin](https://github.com/containernetworking/cni#3rd-party-plugins), such as [Flannel](https://github.com/coreos/flannel#flannel), [Calico](http://docs.projectcalico.org/), [Romana](http://romana.io), [Weave-net](https://www.weave.works/products/weave-net/). +[CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) is a CNI plugin that enables Kubernetes to [simultaneously have access to different implementations](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-cni-plugins/README.md#what-cni-genie-feature-1-multiple-cni-plugins-enables) of the [Kubernetes network model](/ja/docs/concepts/cluster-administration/networking/#kubernetesのネットワークモデル) in runtime. This includes any implementation that runs as a [CNI plugin](https://github.com/containernetworking/cni#3rd-party-plugins), such as [Flannel](https://github.com/coreos/flannel#flannel), [Calico](http://docs.projectcalico.org/), [Romana](http://romana.io), [Weave-net](https://www.weave.works/products/weave-net/). CNI-Genie also supports [assigning multiple IP addresses to a pod](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-ips/README.md#feature-2-extension-cni-genie-multiple-ip-addresses-per-pod), each from a different CNI plugin. @@ -131,11 +131,11 @@ network complexity required to deploy Kubernetes at scale within AWS. ### Contiv -[Contiv](https://github.com/contiv/netplugin) provides configurable networking (native l3 using BGP, overlay using vxlan, classic l2, or Cisco-SDN/ACI) for various use cases. [Contiv](http://contiv.io) is all open sourced. +[Contiv](https://github.com/contiv/netplugin) provides configurable networking (native l3 using BGP, overlay using vxlan, classic l2, or Cisco-SDN/ACI) for various use cases. [Contiv](https://contiv.io) is all open sourced. ### Contrail / Tungsten Fabric -[Contrail](http://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/), based on [Tungsten Fabric](https://tungsten.io), is a truly open, multi-cloud network virtualization and policy management platform. Contrail and Tungsten Fabric are integrated with various orchestration systems such as Kubernetes, OpenShift, OpenStack and Mesos, and provide different isolation modes for virtual machines, containers/pods and bare metal workloads. +[Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/), based on [Tungsten Fabric](https://tungsten.io), is a truly open, multi-cloud network virtualization and policy management platform. Contrail and Tungsten Fabric are integrated with various orchestration systems such as Kubernetes, OpenShift, OpenStack and Mesos, and provide different isolation modes for virtual machines, containers/pods and bare metal workloads. ### DANM @@ -216,7 +216,7 @@ traffic to the internet. ### Kube-router -[Kube-router](https://github.com/cloudnativelabs/kube-router) is a purpose-built networking solution for Kubernetes that aims to provide high performance and operational simplicity. Kube-router provides a Linux [LVS/IPVS](http://www.linuxvirtualserver.org/software/ipvs.html)-based service proxy, a Linux kernel forwarding-based pod-to-pod networking solution with no overlays, and iptables/ipset-based network policy enforcer. +[Kube-router](https://github.com/cloudnativelabs/kube-router) is a purpose-built networking solution for Kubernetes that aims to provide high performance and operational simplicity. Kube-router provides a Linux [LVS/IPVS](https://www.linuxvirtualserver.org/software/ipvs.html)-based service proxy, a Linux kernel forwarding-based pod-to-pod networking solution with no overlays, and iptables/ipset-based network policy enforcer. ### L2 networks and linux bridging @@ -226,8 +226,8 @@ Note that these instructions have only been tried very casually - it seems to work, but has not been thoroughly tested. If you use this technique and perfect the process, please let us know. -Follow the "With Linux Bridge devices" section of [this very nice -tutorial](http://blog.oddbit.com/2014/08/11/four-ways-to-connect-a-docker/) from +Follow the "With Linux Bridge devices" section of +[this very nice tutorial](http://blog.oddbit.com/2014/08/11/four-ways-to-connect-a-docker/) from Lars Kellogg-Stedman. ### Multus (a Multi Network plugin) @@ -236,6 +236,10 @@ Lars Kellogg-Stedman. Multus supports all [reference plugins](https://github.com/containernetworking/plugins) (eg. [Flannel](https://github.com/containernetworking/plugins/tree/master/plugins/meta/flannel), [DHCP](https://github.com/containernetworking/plugins/tree/master/plugins/ipam/dhcp), [Macvlan](https://github.com/containernetworking/plugins/tree/master/plugins/main/macvlan)) that implement the CNI specification and 3rd party plugins (eg. [Calico](https://github.com/projectcalico/cni-plugin), [Weave](https://github.com/weaveworks/weave), [Cilium](https://github.com/cilium/cilium), [Contiv](https://github.com/contiv/netplugin)). In addition to it, Multus supports [SRIOV](https://github.com/hustcat/sriov-cni), [DPDK](https://github.com/Intel-Corp/sriov-cni), [OVS-DPDK & VPP](https://github.com/intel/vhost-user-net-plugin) workloads in Kubernetes with both cloud native and NFV based applications in Kubernetes. +### OVN4NFV-K8s-Plugin (OVN based CNI controller & plugin) + +[OVN4NFV-K8S-Plugin](https://github.com/opnfv/ovn4nfv-k8s-plugin) is OVN based CNI controller plugin to provide cloud native based Service function chaining(SFC), Multiple OVN overlay networking, dynamic subnet creation, dynamic creation of virtual networks, VLAN Provider network, Direct provider network and pluggable with other Multi-network plugins, ideal for edge based cloud native workloads in Multi-cluster networking + ### NSX-T [VMware NSX-T](https://docs.vmware.com/en/VMware-NSX-T/index.html) is a network virtualization and security platform. NSX-T can provide network virtualization for a multi-cloud and multi-hypervisor environment and is focused on emerging application frameworks and architectures that have heterogeneous endpoints and technology stacks. In addition to vSphere hypervisors, these environments include other hypervisors such as KVM, containers, and bare metal. @@ -244,7 +248,7 @@ Multus supports all [reference plugins](https://github.com/containernetworking/p ### Nuage Networks VCS (Virtualized Cloud Services) -[Nuage](http://www.nuagenetworks.net) provides a highly scalable policy-based Software-Defined Networking (SDN) platform. Nuage uses the open source Open vSwitch for the data plane along with a feature rich SDN Controller built on open standards. +[Nuage](https://www.nuagenetworks.net) provides a highly scalable policy-based Software-Defined Networking (SDN) platform. Nuage uses the open source Open vSwitch for the data plane along with a feature rich SDN Controller built on open standards. The Nuage platform uses overlays to provide seamless policy-based networking between Kubernetes Pods and non-Kubernetes environments (VMs and bare metal servers). Nuage's policy abstraction model is designed with applications in mind and makes it easy to declare fine-grained policies for applications.The platform's real-time analytics engine enables visibility and security monitoring for Kubernetes applications. @@ -264,7 +268,7 @@ at [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes). ### Project Calico -[Project Calico](http://docs.projectcalico.org/) is an open source container networking provider and network policy engine. +[Project Calico](https://docs.projectcalico.org/) is an open source container networking provider and network policy engine. Calico provides a highly scalable networking and network policy solution for connecting Kubernetes pods based on the same IP networking principles as the internet, for both Linux (open source) and Windows (proprietary - available from [Tigera](https://www.tigera.io/essentials/)). Calico can be deployed without encapsulation or overlays to provide high-performance, high-scale data center networking. Calico also provides fine-grained, intent based network security policy for Kubernetes pods via its distributed firewall. @@ -272,7 +276,7 @@ Calico can also be run in policy enforcement mode in conjunction with other netw ### Romana -[Romana](http://romana.io) is an open source network and security automation solution that lets you deploy Kubernetes without an overlay network. Romana supports Kubernetes [Network Policy](/docs/concepts/services-networking/network-policies/) to provide isolation across network namespaces. +[Romana](https://romana.io) is an open source network and security automation solution that lets you deploy Kubernetes without an overlay network. Romana supports Kubernetes [Network Policy](/docs/concepts/services-networking/network-policies/) to provide isolation across network namespaces. ### Weave Net from Weaveworks @@ -287,5 +291,6 @@ to run, and in both cases, the network provides one IP address per pod - as is s ## {{% heading "whatsnext" %}} -ネットワークモデルの初期設計とその根拠、および将来の計画については、[ネットワーク設計ドキュメント](https://git.k8s.io/community/contributors/design-proposals/network/networking.md)で詳細に説明されています。 +ネットワークモデルの初期設計とその根拠、および将来の計画については、 +[ネットワーク設計ドキュメント](https://git.k8s.io/community/contributors/design-proposals/network/networking.md)で詳細に説明されています。 From b73acdfa6ac613d51b1ef8d3757bba1276a0a2bd Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Thu, 27 Aug 2020 17:17:25 +0900 Subject: [PATCH 031/252] fix newline --- content/ja/docs/concepts/cluster-administration/networking.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/cluster-administration/networking.md b/content/ja/docs/concepts/cluster-administration/networking.md index fa0fe884ff..1ceaae40aa 100644 --- a/content/ja/docs/concepts/cluster-administration/networking.md +++ b/content/ja/docs/concepts/cluster-administration/networking.md @@ -291,6 +291,5 @@ to run, and in both cases, the network provides one IP address per pod - as is s ## {{% heading "whatsnext" %}} -ネットワークモデルの初期設計とその根拠、および将来の計画については、 -[ネットワーク設計ドキュメント](https://git.k8s.io/community/contributors/design-proposals/network/networking.md)で詳細に説明されています。 +ネットワークモデルの初期設計とその根拠、および将来の計画については、[ネットワーク設計ドキュメント](https://git.k8s.io/community/contributors/design-proposals/network/networking.md)で詳細に説明されています。 From cb7ad7d3adec85610fec646b1d571d0832a7c4da Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Mon, 31 Aug 2020 12:14:23 +0900 Subject: [PATCH 032/252] update word and link --- .../ja/docs/concepts/cluster-administration/networking.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/ja/docs/concepts/cluster-administration/networking.md b/content/ja/docs/concepts/cluster-administration/networking.md index 1ceaae40aa..05af3690d1 100644 --- a/content/ja/docs/concepts/cluster-administration/networking.md +++ b/content/ja/docs/concepts/cluster-administration/networking.md @@ -9,7 +9,7 @@ weight: 50 ネットワークはKubernetesにおける中心的な部分ですが、どのように動作するかを正確に理解することは難解な場合もあります。 Kubernetesには、4つの異なる対応すべきネットワークの問題があります: -1. 高度に結合されたコンテナ間の通信: これは、{{< glossary_tooltip text="Pods" term_id="pod" >}}および`localhost`通信によって解決されます。 +1. 高度に結合されたコンテナ間の通信: これは、{{< glossary_tooltip text="Pod" term_id="pod" >}}および`localhost`通信によって解決されます。 2. Pod間の通信: 本ドキュメントの主な焦点です。 3. Podからサービスへの通信：これは[Service](/ja/docs/concepts/services-networking/service/)でカバーされています。 4. 外部からサービスへの通信：これは[Service](/ja/docs/concepts/services-networking/service/)でカバーされています。 @@ -24,7 +24,7 @@ Kubernetesは、言ってしまえばアプリケーション間でマシンを 動的ポート割り当てはシステムに多くの複雑さをもたらします。すべてのアプリケーションはパラメータとしてポートを管理する必要があり、APIサーバーにて動的なポート番号を設定値として注入する方法が必要となり、各サービスはお互いにお互いを見つける方法が必要です。Kubernetesはこれに対処するのではなく、別のアプローチを取ります。 -## Kubernetesのネットワークモデル +## Kubernetesのネットワークモデル {#the-kubernetes-network-model} すべての`Pod`は独自のIPアドレスを持ちます。これは、`Pod`間のリンクを明示的に作成する必要がなく、コンテナポートをホストポートにマッピングする必要がほとんどないことを意味します。こうすることで、ポート割り当て、名前解決、サービスディスカバリー、負荷分散、アプリケーション設定、および移行の観点から、`Pod`をVMまたは物理ホストと同様に扱うことができる、クリーンで後方互換性のあるモデルを生み出しています。 @@ -109,7 +109,7 @@ addressing, and it can be used in combination with other CNI plugins. ### CNI-Genie from Huawei -[CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) is a CNI plugin that enables Kubernetes to [simultaneously have access to different implementations](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-cni-plugins/README.md#what-cni-genie-feature-1-multiple-cni-plugins-enables) of the [Kubernetes network model](/ja/docs/concepts/cluster-administration/networking/#kubernetesのネットワークモデル) in runtime. This includes any implementation that runs as a [CNI plugin](https://github.com/containernetworking/cni#3rd-party-plugins), such as [Flannel](https://github.com/coreos/flannel#flannel), [Calico](http://docs.projectcalico.org/), [Romana](http://romana.io), [Weave-net](https://www.weave.works/products/weave-net/). +[CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) is a CNI plugin that enables Kubernetes to [simultaneously have access to different implementations](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-cni-plugins/README.md#what-cni-genie-feature-1-multiple-cni-plugins-enables) of the [Kubernetes network model](/ja/docs/concepts/cluster-administration/networking/#the-kubernetes-network-model) in runtime. This includes any implementation that runs as a [CNI plugin](https://github.com/containernetworking/cni#3rd-party-plugins), such as [Flannel](https://github.com/coreos/flannel#flannel), [Calico](http://docs.projectcalico.org/), [Romana](http://romana.io), [Weave-net](https://www.weave.works/products/weave-net/). CNI-Genie also supports [assigning multiple IP addresses to a pod](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-ips/README.md#feature-2-extension-cni-genie-multiple-ip-addresses-per-pod), each from a different CNI plugin. From aa0cbfe61fc03fbc79a31d362d94f62b8cb8fd5c Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Sun, 30 Aug 2020 01:07:16 +0900 Subject: [PATCH 033/252] Update debug-pod-replication-controller.md --- .../debug-pod-replication-controller.md | 37 ++----------------- 1 file changed, 4 insertions(+), 33 deletions(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md b/content/ja/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md index fc17886ebe..e47fdd5470 100644 --- a/content/ja/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md +++ b/content/ja/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md @@ -47,9 +47,9 @@ Podをスケジュールできない理由に関するスケジューラーか クラスター内のCPUまたはメモリーの供給を使い果たした可能性があります。 この場合、いくつかのことを試すことができます。 -* クラスターに[ノードを追加します](/docs/admin/cluster-management/#resizing-a-cluster)。 +* クラスターに[ノードを追加します](/docs/tasks/administer-cluster/cluster-management/#resizing-a-cluster)。 -* [不要なPodを終了](/docs/user-guide/pods/single-container/#deleting_a_pod)して、 +* [不要なPodを終了](docs/concepts/workloads/pods/#pod-termination)して、 `Pending`状態のPodのための空きリソースを作ります。 * Podがノードよりも大きくないことを確認します。 @@ -86,37 +86,8 @@ Podが`Waiting`状態となる最も一般的な原因は、イメージをプ ### Podがクラッシュする、あるいはUnhealthy状態 -最初に、現在のコンテナのログを確認して下さい。 - -```shell -kubectl logs ${POD_NAME} ${CONTAINER_NAME} -``` - -以前にコンテナがクラッシュした場合、次のコマンドで以前のコンテナのクラッシュログにアクセスできます。 - -```shell -kubectl logs --previous ${POD_NAME} ${CONTAINER_NAME} -``` - -別の方法として、`exec`を使用してそのコンテナ内でコマンドを実行できます。 - -```shell -kubectl exec ${POD_NAME} -c ${CONTAINER_NAME} -- ${CMD} ${ARG1} ${ARG2} ... ${ARGN} -``` - -{{< note >}} -`-c ${CONTAINER_NAME}`はオプションです。単一のコンテナのみを含むPodの場合は省略できます。 -{{< /note >}} - -例えば、実行中のCassandra Podのログを確認するには、次のコマンドを実行します。 - -```shell -kubectl exec cassandra -- cat /var/log/cassandra/system.log -``` - -クラスターで有効にしていれば、 [エフェメラルコンテナ](/docs/concepts/workloads/pods/ephemeral-containers/) を既存のPodに追加することもできます。 新しい一時的なコンテナを利用して、たとえばPod内の問題の診断のために任意のコマンドを実行することができます。利用できる機能を含む詳細については、 [エフェメラルコンテナ](/docs/concepts/workloads/pods/ephemeral-containers/) のページを参照してください。 - -これらのアプローチがいずれも機能しない場合、Podが実行されているホストマシンを見つけて、そのホストにSSH接続することができます。 +Podがスケジュールされると、[Debug Running Pods]( ++/docs/tasks/debug-application-cluster/debug-running-pod/)に説明されている方法がデバッグに使用可能です。 ## ReplicationControllerのデバッグ From a74f06a0fe691641dcc17a923c9282e4470e0eb5 Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Sun, 30 Aug 2020 01:16:03 +0900 Subject: [PATCH 034/252] Update debug-pod-replication-controller.md --- .../debug-pod-replication-controller.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md b/content/ja/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md index e47fdd5470..570134b84d 100644 --- a/content/ja/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md +++ b/content/ja/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md @@ -49,7 +49,7 @@ Podをスケジュールできない理由に関するスケジューラーか * クラスターに[ノードを追加します](/docs/tasks/administer-cluster/cluster-management/#resizing-a-cluster)。 -* [不要なPodを終了](docs/concepts/workloads/pods/#pod-termination)して、 +* [不要なPodを終了](/docs/concepts/workloads/pods/#pod-termination)して、 `Pending`状態のPodのための空きリソースを作ります。 * Podがノードよりも大きくないことを確認します。 @@ -86,8 +86,7 @@ Podが`Waiting`状態となる最も一般的な原因は、イメージをプ ### Podがクラッシュする、あるいはUnhealthy状態 -Podがスケジュールされると、[Debug Running Pods]( -+/docs/tasks/debug-application-cluster/debug-running-pod/)に説明されている方法がデバッグに使用可能です。 +Podがスケジュールされると、[動作中のPodをデバッグする](/docs/tasks/debug-application-cluster/debug-running-pod/)に説明されている方法がデバッグに使用可能です。 ## ReplicationControllerのデバッグ From 87c0bcadcdb69e500253007e05c9a3512d095e4e Mon Sep 17 00:00:00 2001 From: opeco17 Date: Tue, 25 Aug 2020 00:43:25 +0900 Subject: [PATCH 035/252] fix 24484 --- .../debug-service.md | 65 +++++++++++-------- 1 file changed, 37 insertions(+), 28 deletions(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/debug-service.md b/content/ja/docs/tasks/debug-application-cluster/debug-service.md index a8332cbcfb..3cdf42ca87 100644 --- a/content/ja/docs/tasks/debug-application-cluster/debug-service.md +++ b/content/ja/docs/tasks/debug-application-cluster/debug-service.md @@ -34,9 +34,9 @@ kubectl exec -c -- このドキュメントのウォークスルーのために、いくつかのPodを実行しましょう。おそらくあなた自身のServiceをデバッグしているため、あなた自身の詳細に置き換えることもできますし、これに沿って2番目のデータポイントを取得することもできます。 + ```shell -kubectl run hostnames --image=k8s.gcr.io/serve_hostname \ - --replicas=3 +kubectl create deployment hostnames --image=k8s.gcr.io/serve_hostname ``` ```none deployment.apps/hostnames created @@ -45,6 +45,15 @@ deployment.apps/hostnames created `kubectl`コマンドは作成、変更されたリソースのタイプと名前を出力するため、この後のコマンドで使用することもできます。 +Deplymentを3つのreplicaにスケールさせてみましょう。 + +```shell +kubectl scale deployment hostnames --replicas=3 +``` +```none +deployment.apps/hostnames scaled +``` + これは、次のYAMLでDeploymentを開始した場合と同じです。 ```yaml @@ -52,27 +61,29 @@ apiVersion: apps/v1 kind: Deployment metadata: name: hostnames + labels: + app: hostnames spec: selector: matchLabels: - run: hostnames + app: hostnames replicas: 3 template: metadata: labels: - run: hostnames + app: hostnames spec: containers: - name: hostnames image: k8s.gcr.io/serve_hostname ``` -"run"ラベルは`kubectl run`によって、Deploymentの名前に自動的にセットされます。 +"app"ラベルは`kubectl create deployment`によって、Deploymentの名前に自動的にセットされます。 Podが実行されていることを確認できます。 ```shell -kubectl get pods -l run=hostnames +kubectl get pods -l app=hostnames ``` ```none NAME READY STATUS RESTARTS AGE @@ -84,7 +95,7 @@ hostnames-632524106-tlaok 1/1 Running 0 2m Podが機能していることも確認できます。Pod IP アドレスリストを取得し、直接テストできます。 ```shell -kubectl get pods -l run=hostnames \ +kubectl get pods -l app=hostnames \ -o go-template='{{range .items}}{{.status.podIP}}{{"\n"}}{{end}}' ``` ```none @@ -106,9 +117,9 @@ done 次のように表示されます。 ``` -hostnames-0uton -hostnames-bvc05 -hostnames-yp2kp +hostnames-632524106-bbpiw +hostnames-632524106-ly40y +hostnames-632524106-tlaok ``` この時点で期待通りの応答が得られない場合、Podが正常でないか、想定しているポートでリッスンしていない可能性があります。なにが起きているかを確認するために`kubectl logs`が役立ちます。Podに直接に入りデバッグする場合は`kubectl exec`が必要になります。 @@ -312,7 +323,7 @@ kubectl get service hostnames -o json "resourceVersion": "347189", "creationTimestamp": "2015-07-07T15:24:29Z", "labels": { - "run": "hostnames" + "app": "hostnames" } }, "spec": { @@ -326,7 +337,7 @@ kubectl get service hostnames -o json } ], "selector": { - "run": "hostnames" + "app": "hostnames" }, "clusterIP": "10.0.1.175", "type": "ClusterIP", @@ -351,15 +362,15 @@ kubectl get service hostnames -o json 以前に、Podが実行されていることを確認しました。再確認しましょう。 ```shell -kubectl get pods -l run=hostnames +kubectl get pods -l app=hostnames ``` ```none NAME READY STATUS RESTARTS AGE -hostnames-0uton 1/1 Running 0 1h -hostnames-bvc05 1/1 Running 0 1h -hostnames-yp2kp 1/1 Running 0 1h +hostnames-632524106-bbpiw 1/1 Running 0 1h +hostnames-632524106-ly40y 1/1 Running 0 1h +hostnames-632524106-tlaok 1/1 Running 0 1h ``` -`-l run=hostnames`引数はラベルセレクターで、ちょうど私たちの`Service`に定義されているものと同じです。 +`-l app=hostnames`引数はラベルセレクターで、ちょうど私たちの`Service`に定義されているものと同じです。 "AGE"列は、これらのPodが約1時間前のものであることを示しており、それらが正常に実行され、クラッシュしていないことを意味します。 @@ -374,7 +385,7 @@ NAME ENDPOINTS hostnames 10.244.0.5:9376,10.244.0.6:9376,10.244.0.7:9376 ``` -これにより、EndpointsコントローラーがServiceの正しいPodを見つけていることを確認できます。`ENDPOINTS`列が``の場合、Serviceの`spec.selector`フィールドが実際にPodの`metadata.labels`値を選択していることを確認する必要があります。よくある間違いは、タイプミスまたは他のエラー、たとえばServiceが`app=hostnames`を選択しているのにDeploymentが`run=hostnames`を指定していることです。 +これにより、EndpointsコントローラーがServiceの正しいPodを見つけていることを確認できます。`ENDPOINTS`列が``の場合、Serviceの`spec.selector`フィールドが実際にPodの`metadata.labels`値を選択していることを確認する必要があります。よくある間違いは、1.18以前のバージョンのように、Serviceが`app=hostnames`を選択しているのに、Deploymentが`run=hostnames`を指定しているなど、タイプミスやその他のエラーがあることや、`kubectl run`によってDeploymentを作成することです。 ## Podは機能しているか？ @@ -395,9 +406,9 @@ done 次のように表示されます。 ``` -hostnames-0uton -hostnames-bvc05 -hostnames-yp2kp +hostnames-632524106-bbpiw +hostnames-632524106-ly40y +hostnames-632524106-tlaok ``` Endpointsリスト内の各Podは、それぞれの自身のホスト名を返すはずです。そうならない(または、あなた自身のPodの正しい振る舞いにならない)場合は、そこで何が起こっているのかを調査する必要があります。 @@ -510,7 +521,7 @@ iptables-save | grep hostnames curl 10.0.1.175:80 ``` ```none -hostnames-0uton +hostnames-632524106-bbpiw ``` もしこれが失敗し、あなたがuserspaceプロキシーを使用している場合、プロキシーへの直接アクセスを試してみてください。もしiptablesプロキシーを使用している場合、このセクションはスキップしてください。 @@ -521,7 +532,7 @@ hostnames-0uton curl localhost:48577 ``` ```none -hostnames-yp2kp +hostnames-632524106-tlaok ``` もしまだ失敗する場合は、`kube-proxy`ログで次のような特定の行を探してください。 @@ -534,7 +545,7 @@ Setting endpoints for default/hostnames:default to [10.244.0.5:9376 10.244.0.6:9 ### エッジケース: PodがService IP経由で自身に到達できない {#a-pod-fails-to-reach-itself-via-the-service-ip} -これはありそうに聞こえないかもしれませんが、実際には起こり、動作するはずです。これはネットワークが"hairpin"トラフィック用に適切に設定されていない場合、通常は`kube-proxy`が`iptables`モードで実行され、Podがブリッジネットワークに接続されている場合に発生します。`Kubelet`は`hairpin-mode`[フラグ](/docs/admin/kubelet/)を公開します。これにより、Serviceのエンドポイントが自身のServiceのVIPにアクセスしようとした場合に、自身への負荷分散を可能にします。`hairpin-mode`フラグは`hairpin-veth`または`promiscuous-bridge`に設定する必要があります。 +これはありそうに聞こえないかもしれませんが、実際には起こり、動作するはずです。これはネットワークが"hairpin"トラフィック用に適切に設定されていない場合、通常は`kube-proxy`が`iptables`モードで実行され、Podがブリッジネットワークに接続されている場合に発生します。`Kubelet`は`hairpin-mode`[フラグ](/docs/reference/command-line-tools-reference/kubelet/)を公開します。これにより、Serviceのエンドポイントが自身のServiceのVIPにアクセスしようとした場合に、自身への負荷分散を可能にします。`hairpin-mode`フラグは`hairpin-veth`または`promiscuous-bridge`に設定する必要があります。 この問題をトラブルシューティングする一般的な手順は次のとおりです。 @@ -580,13 +591,11 @@ UP BROADCAST RUNNING PROMISC MULTICAST MTU:1460 Metric:1 ここまでたどり着いたということは、とてもおかしなことが起こっています。Serviceは実行中で、Endpointsがあり、Podは実際にサービスを提供しています。DNSは動作していて、`kube-proxy`も誤動作していないようです。それでも、あなたのServiceは機能していません。おそらく私たちにお知らせ頂いた方がよいでしょう。調査をお手伝いします！ -[Slack](/docs/troubleshooting/#slack)、[Forum](https://discuss.kubernetes.io)または[GitHub](https://github.com/kubernetes/kubernetes)でお問い合わせください。 +[Slack](/docs/tasks/debug-application-cluster/troubleshooting/#slack)、[Forum](https://discuss.kubernetes.io)または[GitHub](https://github.com/kubernetes/kubernetes)でお問い合わせください。 ## {{% heading "whatsnext" %}} -詳細については、[トラブルシューティングドキュメント](/docs/troubleshooting/)をご覧ください。 - - +詳細については、[トラブルシューティングドキュメント](/docs/tasks/debug-application-cluster/troubleshooting/)をご覧ください。 From 212076bc4573035fd6bcb60edbcc31ee779450d3 Mon Sep 17 00:00:00 2001 From: opeco17 <46510874+opeco17@users.noreply.github.com> Date: Sat, 29 Aug 2020 23:28:46 +0900 Subject: [PATCH 036/252] Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-authored-by: Naoki Oketani --- .../ja/docs/tasks/debug-application-cluster/debug-service.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/debug-service.md b/content/ja/docs/tasks/debug-application-cluster/debug-service.md index 3cdf42ca87..e5a00ebcde 100644 --- a/content/ja/docs/tasks/debug-application-cluster/debug-service.md +++ b/content/ja/docs/tasks/debug-application-cluster/debug-service.md @@ -45,7 +45,7 @@ deployment.apps/hostnames created `kubectl`コマンドは作成、変更されたリソースのタイプと名前を出力するため、この後のコマンドで使用することもできます。 -Deplymentを3つのreplicaにスケールさせてみましょう。 +Deploymentを3つのレプリカにスケールさせてみましょう。 ```shell kubectl scale deployment hostnames --replicas=3 From b487ca44a39ce76872495476881ff1a40993b8ff Mon Sep 17 00:00:00 2001 From: opeco17 <46510874+opeco17@users.noreply.github.com> Date: Sat, 29 Aug 2020 23:30:43 +0900 Subject: [PATCH 037/252] Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-authored-by: Naoki Oketani --- .../ja/docs/tasks/debug-application-cluster/debug-service.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/debug-service.md b/content/ja/docs/tasks/debug-application-cluster/debug-service.md index e5a00ebcde..5daefb2f59 100644 --- a/content/ja/docs/tasks/debug-application-cluster/debug-service.md +++ b/content/ja/docs/tasks/debug-application-cluster/debug-service.md @@ -385,7 +385,7 @@ NAME ENDPOINTS hostnames 10.244.0.5:9376,10.244.0.6:9376,10.244.0.7:9376 ``` -これにより、EndpointsコントローラーがServiceの正しいPodを見つけていることを確認できます。`ENDPOINTS`列が``の場合、Serviceの`spec.selector`フィールドが実際にPodの`metadata.labels`値を選択していることを確認する必要があります。よくある間違いは、1.18以前のバージョンのように、Serviceが`app=hostnames`を選択しているのに、Deploymentが`run=hostnames`を指定しているなど、タイプミスやその他のエラーがあることや、`kubectl run`によってDeploymentを作成することです。 +これにより、EndpointsコントローラーがServiceの正しいPodを見つけていることを確認できます。`ENDPOINTS`列が``の場合、Serviceの`spec.selector`フィールドが実際にPodの`metadata.labels`値を選択していることを確認する必要があります。よくある間違いは、タイプミスやその他のエラー、たとえばDeployment作成にも`kubectl run`が使われた1.18以前のバージョンのように、Serviceが`app=hostnames`を選択しているのにDeploymentが`run=hostnames`を指定していることです。 ## Podは機能しているか？ From d3db4e1e86e427e822a3685b6e81fc261e87bfc1 Mon Sep 17 00:00:00 2001 From: arisgi Date: Thu, 27 Aug 2020 00:56:37 +0900 Subject: [PATCH 038/252] Translate "Determine the Reason for Pod Failure" --- .../debug-application-cluster/determine-reason-pod-failure.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/content/ja/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md b/content/ja/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md index 7ec722caa6..fdddb859ce 100644 --- a/content/ja/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md +++ b/content/ja/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md @@ -67,6 +67,8 @@ content_type: task Kubernetesは、コンテナの`terminationMessagePath`フィールドで指定されている終了メッセージファイルから終了メッセージを取得します。デフォルト値は`/dev/termination-log`です。このフィールドをカスタマイズすることで、Kubernetesに別のファイルを使うように指示できます。Kubernetesは指定されたファイルの内容を使用して、成功と失敗の両方についてコンテナのステータスメッセージを入力します。 +終了メッセージはアサーションエラーメッセージのように、最終状態を簡潔に示します。kubeletは4096バイトより長いメッセージは切り詰めます。全コンテナの合計メッセージの長さの上限は12キビバイトです。デフォルトの終了メッセージのパスは`/dev/termination-log`です。Pod起動後に終了メッセージのパスを設定することはできません。 + 次の例では、コンテナはKubernetesが取得するために終了メッセージを`/tmp/my-log`に書き込みます: ```yaml From 3bc4bafda7628dd1c6216b92a298bbac976f6d75 Mon Sep 17 00:00:00 2001 From: Takuya Niita Date: Sat, 29 Aug 2020 14:06:04 +0900 Subject: [PATCH 039/252] modify #23451 --- content/ja/docs/concepts/workloads/pods/init-containers.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/ja/docs/concepts/workloads/pods/init-containers.md b/content/ja/docs/concepts/workloads/pods/init-containers.md index 3486c55219..fab17dddc1 100644 --- a/content/ja/docs/concepts/workloads/pods/init-containers.md +++ b/content/ja/docs/concepts/workloads/pods/init-containers.md @@ -29,7 +29,7 @@ Initコンテナのステータスは、`.status.initContainerStatuses`フィー Initコンテナは、リソースリミット、ボリューム、セキュリティ設定などのアプリケーションコンテナの全てのフィールドと機能をサポートしています。しかし、Initコンテナに対するリソースリクエストやリソースリミットの扱いは異なります。[リソース](#resources)にて説明します。 -また、InitコンテナはそのPodの準備ができる前に完了しなくてはならないため、`readinessProbe`をサポートしていません。 +また、InitコンテナはそのPodの準備ができる前に完了しなくてはならないため、`readinessProbe`、`livenessProbe`、`readinessProbe`および`startupProbe`をサポートしていません。 複数のInitコンテナを単一のPodに対して指定した場合、KubeletはそれらのInitコンテナを1つずつ順番に実行します。各Initコンテナは、次のInitコンテナが稼働する前に正常終了しなくてはなりません。全てのInitコンテナの実行が完了すると、KubeletはPodのアプリケーションコンテナを初期化し、通常通り実行します。 @@ -200,11 +200,11 @@ NAME READY STATUS RESTARTS AGE myapp-pod 1/1 Running 0 9m ``` -このシンプルな例を独自のInitコンテナを作成する際の参考にしてください。[次の項目](#what-s-next)にさらに詳細な使用例に関するリンクがあります。 +このシンプルな例を独自のInitコンテナを作成する際の参考にしてください。[次の項目](#whats-next)にさらに詳細な使用例に関するリンクがあります。 ## Initコンテナのふるまいに関する詳細 {#detailed-behavior} -Podの起動時において、各Initコンテナはネットワークとボリュームが初期化されたのちに順番に起動します。各Initコンテナは次のInitコンテナが起動する前に正常に終了しなくてはなりません。もしあるInitコンテナがランタイムもしくはエラーにより起動失敗した場合、そのPodの`restartPolicy`の値に従ってリトライされます。しかし、もしPodの`restartPolicy`が`Always`に設定されていた場合、Initコンテナの`restartPolicy`は`OnFailure`が適用されます。 +Podの起動時、各Initコンテナが起動状態となるまで、kubeletはネットワーキングおよびストレージを利用可能な状態にしません。また、kubeletはPodのspecに定義された順番に従って各Initコンテナを起動します。各Initコンテナは次のInitコンテナが起動する前に正常に終了しなくてはなりません。もしあるInitコンテナがランタイムもしくはエラーにより起動失敗した場合、そのPodの`restartPolicy`の値に従ってリトライされます。しかし、もしPodの`restartPolicy`が`Always`に設定されていた場合、Initコンテナの`restartPolicy`は`OnFailure`が適用されます。 Podは全てのInitコンテナが完了するまで`Ready`状態となりません。Initコンテナ上のポートはServiceによって集約されません。初期化中のPodのステータスは`Pending`となりますが、`Initialized`という値はtrueとなります。 From e6691df38092d884116ecf4d5b353fe1e4a80319 Mon Sep 17 00:00:00 2001 From: Takuya Niita Date: Sat, 29 Aug 2020 14:10:03 +0900 Subject: [PATCH 040/252] modify #23451 --- content/ja/docs/concepts/workloads/pods/init-containers.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/workloads/pods/init-containers.md b/content/ja/docs/concepts/workloads/pods/init-containers.md index fab17dddc1..7ab97eac5d 100644 --- a/content/ja/docs/concepts/workloads/pods/init-containers.md +++ b/content/ja/docs/concepts/workloads/pods/init-containers.md @@ -204,7 +204,7 @@ myapp-pod 1/1 Running 0 9m ## Initコンテナのふるまいに関する詳細 {#detailed-behavior} -Podの起動時、各Initコンテナが起動状態となるまで、kubeletはネットワーキングおよびストレージを利用可能な状態にしません。また、kubeletはPodのspecに定義された順番に従って各Initコンテナを起動します。各Initコンテナは次のInitコンテナが起動する前に正常に終了しなくてはなりません。もしあるInitコンテナがランタイムもしくはエラーにより起動失敗した場合、そのPodの`restartPolicy`の値に従ってリトライされます。しかし、もしPodの`restartPolicy`が`Always`に設定されていた場合、Initコンテナの`restartPolicy`は`OnFailure`が適用されます。 +Podの起動時は各Initコンテナが起動状態となるまで、kubeletはネットワーキングおよびストレージを利用可能な状態にしません。また、kubeletはPodのspecに定義された順番に従って各Initコンテナを起動します。各Initコンテナは次のInitコンテナが起動する前に正常に終了しなくてはなりません。もしあるInitコンテナがランタイムもしくはエラーにより起動失敗した場合、そのPodの`restartPolicy`の値に従ってリトライされます。しかし、もしPodの`restartPolicy`が`Always`に設定されていた場合、Initコンテナの`restartPolicy`は`OnFailure`が適用されます。 Podは全てのInitコンテナが完了するまで`Ready`状態となりません。Initコンテナ上のポートはServiceによって集約されません。初期化中のPodのステータスは`Pending`となりますが、`Initialized`という値はtrueとなります。 From 731b0da4f71221feed834d92207f0ae35069694d Mon Sep 17 00:00:00 2001 From: Takuya Niita Date: Sat, 29 Aug 2020 23:34:39 +0900 Subject: [PATCH 041/252] modify #23451 --- content/ja/docs/concepts/workloads/pods/init-containers.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/workloads/pods/init-containers.md b/content/ja/docs/concepts/workloads/pods/init-containers.md index 7ab97eac5d..2a13f84022 100644 --- a/content/ja/docs/concepts/workloads/pods/init-containers.md +++ b/content/ja/docs/concepts/workloads/pods/init-containers.md @@ -29,7 +29,7 @@ Initコンテナのステータスは、`.status.initContainerStatuses`フィー Initコンテナは、リソースリミット、ボリューム、セキュリティ設定などのアプリケーションコンテナの全てのフィールドと機能をサポートしています。しかし、Initコンテナに対するリソースリクエストやリソースリミットの扱いは異なります。[リソース](#resources)にて説明します。 -また、InitコンテナはそのPodの準備ができる前に完了しなくてはならないため、`readinessProbe`、`livenessProbe`、`readinessProbe`および`startupProbe`をサポートしていません。 +また、InitコンテナはそのPodの準備ができる前に完了しなくてはならないため、`lifecycle`、`livenessProbe`、`readinessProbe`および`startupProbe`をサポートしていません。 複数のInitコンテナを単一のPodに対して指定した場合、KubeletはそれらのInitコンテナを1つずつ順番に実行します。各Initコンテナは、次のInitコンテナが稼働する前に正常終了しなくてはなりません。全てのInitコンテナの実行が完了すると、KubeletはPodのアプリケーションコンテナを初期化し、通常通り実行します。 From 60c7c21151073124dedc77e7cb63a81acdc3847c Mon Sep 17 00:00:00 2001 From: Takuya Niita Date: Sat, 29 Aug 2020 23:53:34 +0900 Subject: [PATCH 042/252] modify #23451 --- content/ja/docs/concepts/workloads/pods/init-containers.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/workloads/pods/init-containers.md b/content/ja/docs/concepts/workloads/pods/init-containers.md index 2a13f84022..5e7baf0665 100644 --- a/content/ja/docs/concepts/workloads/pods/init-containers.md +++ b/content/ja/docs/concepts/workloads/pods/init-containers.md @@ -204,7 +204,7 @@ myapp-pod 1/1 Running 0 9m ## Initコンテナのふるまいに関する詳細 {#detailed-behavior} -Podの起動時は各Initコンテナが起動状態となるまで、kubeletはネットワーキングおよびストレージを利用可能な状態にしません。また、kubeletはPodのspecに定義された順番に従って各Initコンテナを起動します。各Initコンテナは次のInitコンテナが起動する前に正常に終了しなくてはなりません。もしあるInitコンテナがランタイムもしくはエラーにより起動失敗した場合、そのPodの`restartPolicy`の値に従ってリトライされます。しかし、もしPodの`restartPolicy`が`Always`に設定されていた場合、Initコンテナの`restartPolicy`は`OnFailure`が適用されます。 +Podの起動時は各Initコンテナが起動状態となるまで、kubeletはネットワーキングおよびストレージを利用可能な状態にしません。また、kubeletはPodのspecに定義された順番に従ってPodのInitコンテナを起動します。各Initコンテナは次のInitコンテナが起動する前に正常に終了しなくてはなりません。もしあるInitコンテナがランタイムもしくはエラーにより起動失敗した場合、そのPodの`restartPolicy`の値に従ってリトライされます。しかし、もしPodの`restartPolicy`が`Always`に設定されていた場合、Initコンテナの`restartPolicy`は`OnFailure`が適用されます。 Podは全てのInitコンテナが完了するまで`Ready`状態となりません。Initコンテナ上のポートはServiceによって集約されません。初期化中のPodのステータスは`Pending`となりますが、`Initialized`という値はtrueとなります。 From 495415c3f3a1b1fc2a639fbfa4738c623d6f8d1a Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Mon, 31 Aug 2020 17:52:13 +0900 Subject: [PATCH 043/252] Update configure-pod-configmap.md --- .../configure-pod-container/configure-pod-configmap.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md index 4666e6c7f2..7bcacd13a4 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md @@ -577,6 +577,10 @@ SPECIAL_TYPE `/etc/config/`ディレクトリに何かファイルがある場合、それらは削除されます。 {{< /caution >}} +{{< note >}} +テキストデータはUTF-8文字エンコーディングを使用しているファイルとして公開されます。他の文字エンコーディングを使用する場合は、バイナリデータを使用してください。 +{{< /note >}} + ### ConfigMapデータをボリュームの特定のパスに追加する `path`フィールドを利用して特定のConfigMapのアイテム向けに希望のファイルパスを指定します。 @@ -665,5 +669,5 @@ data: ## {{% heading "whatsnext" %}} -* 実践例[Configuring Redis using a ConfigMap](/docs/tutorials/configuration/configure-redis-using-configmap/)を続けて読む。 +* 実践例[ConfigMapを使ったRedisの設定](/ja/docs/tutorials/configuration/configure-redis-using-configmap/)を続けて読む。 From 3d0034f42ccbbf3fd641a1d70ab2c50d2cdbacdf Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Wed, 2 Sep 2020 02:52:26 +0900 Subject: [PATCH 044/252] Update attach-handler-lifecycle-event.md --- .../configure-pod-container/attach-handler-lifecycle-event.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md b/content/ja/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md index 1c875edc1f..1aa194a745 100644 --- a/content/ja/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md +++ b/content/ja/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md @@ -63,7 +63,7 @@ Pod内で実行されているコンテナでシェルを実行します: ただし、コンテナのエントリーポイントが呼び出される前にpostStartハンドラーが呼び出されるという保証はありません。postStartハンドラーはコンテナのコードに対して非同期的に実行されますが、postStartハンドラーが完了するまでコンテナのKubernetesによる管理はブロックされます。postStartハンドラーが完了するまで、コンテナのステータスはRUNNINGに設定されません。 Kubernetesはコンテナが終了する直前にpreStopイベントを送信します。 -コンテナのKubernetesによる管理は、Podの猶予期間が終了しない限り、preStopハンドラーが完了するまでブロックされます。詳細は[Podの終了](/ja/docs/concepts/workloads/pods/pod/#termination-of-pods)を参照してください。 +コンテナのKubernetesによる管理は、Podの猶予期間が終了しない限り、preStopハンドラーが完了するまでブロックされます。詳細は[Podのライフサイクル](/ja/docs/concepts/workloads/pods/pod-lifecycle/)を参照してください。 {{< note >}} Kubernetesは、Podが *終了* したときにのみpreStopイベントを送信します。 From b82b1ff73c20c97f69e8f800ef24a1d94dbb59ad Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Mon, 31 Aug 2020 12:48:43 +0900 Subject: [PATCH 045/252] update ja/docs/tasks/access-application-cluster/connecting-frontend-backend.md --- .../connecting-frontend-backend.md | 17 ++++++++++++++--- 1 file changed, 14 insertions(+), 3 deletions(-) diff --git a/content/ja/docs/tasks/access-application-cluster/connecting-frontend-backend.md b/content/ja/docs/tasks/access-application-cluster/connecting-frontend-backend.md index dbe76f3267..b58ba00914 100644 --- a/content/ja/docs/tasks/access-application-cluster/connecting-frontend-backend.md +++ b/content/ja/docs/tasks/access-application-cluster/connecting-frontend-backend.md @@ -26,10 +26,10 @@ weight: 70 ## {{% heading "prerequisites" %}} -* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} +{{< 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を使用できます。 +このタスクでは[Serviceで外部ロードバランサー](/docs/tasks/access-application-cluster/create-external-load-balancer/)を使用しますが、外部ロードバランサーの使用がサポートされている環境である必要があります。 +ご使用の環境がこれをサポートしていない場合は、代わりにタイプ[NodePort](/ja/docs/concepts/services-networking/service/#nodeport)のServiceを使用できます。 @@ -186,8 +186,19 @@ curl http://${EXTERNAL_IP} # これを前に見たEXTERNAL-IPに置き換えま {"message":"Hello"} ``` +## {{% heading "cleanup" %}} +Serviceを削除するために、このコマンドを入力してください： +```shell +kubectl delete services frontend hello +``` + +バックエンドとして動作しているDeploymentとReplicaSetとPodとフロントエンドアプリケーションを削除するために、このコマンドを入力してください： + +```shell +kubectl delete deployment frontend hello +``` ## {{% heading "whatsnext" %}} From 61d24d77875406e9d913d3e05140464ba480c08a Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Mon, 31 Aug 2020 12:55:23 +0900 Subject: [PATCH 046/252] update ja/docs/tasks/access-application-cluster/connecting-frontend-backend.md --- .../access-application-cluster/connecting-frontend-backend.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/access-application-cluster/connecting-frontend-backend.md b/content/ja/docs/tasks/access-application-cluster/connecting-frontend-backend.md index b58ba00914..e8af3d5f7a 100644 --- a/content/ja/docs/tasks/access-application-cluster/connecting-frontend-backend.md +++ b/content/ja/docs/tasks/access-application-cluster/connecting-frontend-backend.md @@ -194,7 +194,7 @@ Serviceを削除するために、このコマンドを入力してください kubectl delete services frontend hello ``` -バックエンドとして動作しているDeploymentとReplicaSetとPodとフロントエンドアプリケーションを削除するために、このコマンドを入力してください： +バックエンドとフロントエンドアプリケーションを実行しているDeploymentとReplicaSetとPodを削除するために、このコマンドを入力してください： ```shell kubectl delete deployment frontend hello From e1bcc4fff9822528597b9338606bda3e3a2ed8b4 Mon Sep 17 00:00:00 2001 From: yu-kasuya Date: Wed, 2 Sep 2020 18:49:36 +0900 Subject: [PATCH 047/252] Apply suggestions from code review Co-authored-by: inductor(Kohei) --- .../access-application-cluster/connecting-frontend-backend.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/ja/docs/tasks/access-application-cluster/connecting-frontend-backend.md b/content/ja/docs/tasks/access-application-cluster/connecting-frontend-backend.md index e8af3d5f7a..a1d167c441 100644 --- a/content/ja/docs/tasks/access-application-cluster/connecting-frontend-backend.md +++ b/content/ja/docs/tasks/access-application-cluster/connecting-frontend-backend.md @@ -188,7 +188,7 @@ curl http://${EXTERNAL_IP} # これを前に見たEXTERNAL-IPに置き換えま ## {{% heading "cleanup" %}} -Serviceを削除するために、このコマンドを入力してください： +Serviceを削除するには、このコマンドを入力してください： ```shell kubectl delete services frontend hello @@ -208,4 +208,3 @@ kubectl delete deployment frontend hello - From 9dfe0f044ef4101b1ee4efc181f28fbe95443288 Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Tue, 1 Sep 2020 12:28:00 +0900 Subject: [PATCH 048/252] updateja/docs/tasks/access-application-cluster/service-access-application-cluster.md --- .../service-access-application-cluster.md | 9 ++------- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/content/ja/docs/tasks/access-application-cluster/service-access-application-cluster.md b/content/ja/docs/tasks/access-application-cluster/service-access-application-cluster.md index 1fe8e47e7b..ccca616285 100644 --- a/content/ja/docs/tasks/access-application-cluster/service-access-application-cluster.md +++ b/content/ja/docs/tasks/access-application-cluster/service-access-application-cluster.md @@ -43,13 +43,8 @@ weight: 60 ```shell kubectl apply -f https://k8s.io/examples/service/access/hello-application.yaml ``` - このコマンドは - [Deployment](/ja/docs/concepts/workloads/controllers/deployment/) - オブジェクトとそれに紐付く - [ReplicaSet](/ja/docs/concepts/workloads/controllers/replicaset/) - オブジェクトを作成します。ReplicaSetは、Hello Worldアプリケーションが稼働している2つの - [Pod](/ja/docs/concepts/workloads/pods/pod/) - から構成されます。 + このコマンドは{{< glossary_tooltip text="Deployment" term_id="deployment" >}}オブジェクトとそれに紐付く{{< glossary_tooltip term_id="replica-set" text="ReplicaSet" >}}オブジェクトを作成します。 + ReplicaSetは、Hello Worldアプリケーションが稼働している2つの{{< glossary_tooltip text="Pod" term_id="pod" >}}から構成されます。 1. Deploymentの情報を表示します: ```shell From b7e031c621746c0d230d11f8468f27e7b1904800 Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Wed, 2 Sep 2020 19:01:37 +0900 Subject: [PATCH 049/252] delete newline --- .../service-access-application-cluster.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/ja/docs/tasks/access-application-cluster/service-access-application-cluster.md b/content/ja/docs/tasks/access-application-cluster/service-access-application-cluster.md index ccca616285..d566f09566 100644 --- a/content/ja/docs/tasks/access-application-cluster/service-access-application-cluster.md +++ b/content/ja/docs/tasks/access-application-cluster/service-access-application-cluster.md @@ -43,8 +43,7 @@ weight: 60 ```shell kubectl apply -f https://k8s.io/examples/service/access/hello-application.yaml ``` - このコマンドは{{< glossary_tooltip text="Deployment" term_id="deployment" >}}オブジェクトとそれに紐付く{{< glossary_tooltip term_id="replica-set" text="ReplicaSet" >}}オブジェクトを作成します。 - ReplicaSetは、Hello Worldアプリケーションが稼働している2つの{{< glossary_tooltip text="Pod" term_id="pod" >}}から構成されます。 + このコマンドは{{< glossary_tooltip text="Deployment" term_id="deployment" >}}オブジェクトとそれに紐付く{{< glossary_tooltip term_id="replica-set" text="ReplicaSet" >}}オブジェクトを作成します。ReplicaSetは、Hello Worldアプリケーションが稼働している2つの{{< glossary_tooltip text="Pod" term_id="pod" >}}から構成されます。 1. Deploymentの情報を表示します: ```shell From 1bcce822a1fd64488a2047336d7aae6cc4b36c40 Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Sat, 29 Aug 2020 23:01:56 +0900 Subject: [PATCH 050/252] Update delete-stateful-set.md --- content/ja/docs/tasks/run-application/delete-stateful-set.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/run-application/delete-stateful-set.md b/content/ja/docs/tasks/run-application/delete-stateful-set.md index 42f22c1b74..659dabec17 100644 --- a/content/ja/docs/tasks/run-application/delete-stateful-set.md +++ b/content/ja/docs/tasks/run-application/delete-stateful-set.md @@ -51,7 +51,7 @@ kubectl delete pods -l app=myapp ### 永続ボリューム -StatefulSet内のPodを削除しても、関連付けられているボリュームは削除されません。これは、削除する前にボリュームからデータをコピーする機会があることを保証するためです。Podが[終了状態](/ja/docs/concepts/workloads/pods/pod/#termination-of-pods)になった後にPVCを削除すると、ストレージクラスと再利用ポリシーによっては、背後にある永続ボリュームの削除がトリガーされることがあります。決してクレーム削除後にボリュームにアクセスできると想定しないでください。 +StatefulSet内のPodを削除しても、関連付けられているボリュームは削除されません。これは、削除する前にボリュームからデータをコピーする機会があることを保証するためです。Podが終了した後にPVCを削除すると、ストレージクラスと再利用ポリシーによっては、背後にある永続ボリュームの削除がトリガーされることがあります。決してクレーム削除後にボリュームにアクセスできると想定しないでください。 {{< note >}} データを損失する可能性があるため、PVCを削除するときは注意してください。 From eca608559e2f0dbbb7410b7a6d5cfedaa97ea270 Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Thu, 3 Sep 2020 00:11:10 +0900 Subject: [PATCH 051/252] Update _index.md --- content/ja/docs/tutorials/_index.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/content/ja/docs/tutorials/_index.md b/content/ja/docs/tutorials/_index.md index 3d82984243..1c1d55300a 100644 --- a/content/ja/docs/tutorials/_index.md +++ b/content/ja/docs/tutorials/_index.md @@ -1,6 +1,7 @@ --- title: チュートリアル main_menu: true +no_list: true weight: 60 content_type: concept --- @@ -54,6 +55,6 @@ content_type: concept ## {{% heading "whatsnext" %}} -チュートリアルを書きたい場合は、[ページテンプレートの使用](/docs/contribute/style/page-templates/)を参照し、チュートリアルのページタイプとチュートリアルテンプレートについてご確認ください。 +チュートリアルのページタイプについての情報は、[Content Page Types](/docs/contribute/style/page-content-types/)を参照してください。 From 4d361be2b089eb67634e19dbf92aca240ff39ab4 Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Thu, 3 Sep 2020 11:56:35 +0900 Subject: [PATCH 052/252] Update ja/docs/tutorials/kubernetes-basics/scale/scale-intro.html --- .../ja/docs/tutorials/kubernetes-basics/scale/scale-intro.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tutorials/kubernetes-basics/scale/scale-intro.html b/content/ja/docs/tutorials/kubernetes-basics/scale/scale-intro.html index 602fd843e5..343894e58c 100644 --- a/content/ja/docs/tutorials/kubernetes-basics/scale/scale-intro.html +++ b/content/ja/docs/tutorials/kubernetes-basics/scale/scale-intro.html @@ -40,7 +40,7 @@ weight: 10
-

kubectl runコマンドの--replicasパラメーターを使用することで、最初から複数のインスタンスを含むDeploymentを作成できます。

+

kubectl create deploymentコマンドの--replicasパラメーターを使用することで、最初から複数のインスタンスを含むDeploymentを作成できます。

From eda77a06a3331c871a8119695f68c6a4c06b7e91 Mon Sep 17 00:00:00 2001 From: Naoki Oketani Date: Sun, 30 Aug 2020 19:20:21 +0900 Subject: [PATCH 053/252] modify link title --- .../docs/tasks/debug-application-cluster/debug-stateful-set.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/debug-stateful-set.md b/content/ja/docs/tasks/debug-application-cluster/debug-stateful-set.md index 0cafaa28e5..7c8e6eeec8 100644 --- a/content/ja/docs/tasks/debug-application-cluster/debug-stateful-set.md +++ b/content/ja/docs/tasks/debug-application-cluster/debug-stateful-set.md @@ -27,7 +27,7 @@ StatefulSetに属し、ラベル`app=myapp`が設定されているすべてのP kubectl get pods -l app=myapp ``` -Podが長期間`Unknown`または`Terminating`の状態になっていることがわかった場合は、それらを処理する方法について[StatefulSet Podの強制削除](/ja/docs/tasks/run-application/delete-stateful-set/)タスクを参照してください。 +Podが長期間`Unknown`または`Terminating`の状態になっていることがわかった場合は、それらを処理する方法について[StatefulSetの削除](/ja/docs/tasks/run-application/delete-stateful-set/)タスクを参照してください。 [Podのデバッグ](/docs/tasks/debug-application-cluster/debug-pod-replication-controller/)ガイドを使用して、StatefulSet内の個々のPodをデバッグできます。 From 8c348075d23ff7f0df4288dac3d161febd4386ae Mon Sep 17 00:00:00 2001 From: zettaittenani Date: Thu, 3 Sep 2020 18:53:48 +0900 Subject: [PATCH 054/252] Fix ingress.md's links for ingress controller --- .../concepts/services-networking/ingress.md | 17 ++++++++--------- 1 file changed, 8 insertions(+), 9 deletions(-) diff --git a/content/ja/docs/concepts/services-networking/ingress.md b/content/ja/docs/concepts/services-networking/ingress.md index 26feb3076c..a2e39554c9 100644 --- a/content/ja/docs/concepts/services-networking/ingress.md +++ b/content/ja/docs/concepts/services-networking/ingress.md @@ -33,15 +33,15 @@ weight: 40 [ Services ] ``` -IngressはServiceに対して、外部疎通できるURL、負荷分散トラフィック、SSL/TLS終端の機能や、名前ベースの仮想ホスティングを提供するように設定できます。[Ingressコントローラー](/docs/concepts/services-networking/ingress-controllers)は通常はロードバランサーを使用してIngressの機能を実現しますが、エッジルーターや、追加のフロントエンドを構成してトラフィックの処理を支援することもできます。 +IngressはServiceに対して、外部疎通できるURL、負荷分散トラフィック、SSL/TLS終端の機能や、名前ベースの仮想ホスティングを提供するように設定できます。[Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers)は通常はロードバランサーを使用してIngressの機能を実現しますが、エッジルーターや、追加のフロントエンドを構成してトラフィックの処理を支援することもできます。 Ingressは任意のポートやプロトコルを公開しません。HTTPやHTTPS以外のServiceをインターネットに公開する場合、[Service.Type=NodePort](/ja/docs/concepts/services-networking/service/#nodeport)や[Service.Type=LoadBalancer](/ja/docs/concepts/services-networking/service/#loadbalancer)のServiceタイプを一般的には使用します。 ## Ingressを使用する上での前提条件 -Ingressを提供するためには[Ingressコントローラー](/docs/concepts/services-networking/ingress-controllers)が必要です。Ingressリソースを作成するのみでは何の効果もありません。 +Ingressを提供するためには[Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers)が必要です。Ingressリソースを作成するのみでは何の効果もありません。 -[ingress-nginx](https://kubernetes.github.io/ingress-nginx/deploy/)のようなIngressコントローラーのデプロイが必要な場合があります。いくつかの[Ingressコントローラー](/docs/concepts/services-networking/ingress-controllers)の中から選択してください。 +[ingress-nginx](https://kubernetes.github.io/ingress-nginx/deploy/)のようなIngressコントローラーのデプロイが必要な場合があります。いくつかの[Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers)の中から選択してください。 理想的には、全てのIngressコントローラーはリファレンスの仕様を満たすはずです。しかし実際には、各Ingressコントローラーは微妙に異なる動作をします。 @@ -70,7 +70,7 @@ spec: servicePort: 80 ``` -他の全てのKubernetesリソースと同様に、Ingressには`apiVersion`、`kind`や`metadata`フィールドが必要です。Ingressオブジェクトの名前は、有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。設定ファイルに関する一般的な情報は、[アプリケーションのデプロイ](/ja/docs/tasks/run-application/run-stateless-application-deployment/)、[コンテナの設定](/docs/tasks/configure-pod-container/configure-pod-configmap/)、[リソースの管理](/docs/concepts/cluster-administration/manage-deployment/)を参照してください。Ingressでは、Ingressコントローラーに依存しているいくつかのオプションの設定をするためにアノテーションを一般的に使用します。例としては、[rewrite-targetアノテーション](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md)などがあります。[Ingressコントローラー](/docs/concepts/services-networking/ingress-controllers)の種類が異なれば、サポートするアノテーションも異なります。サポートされているアノテーションについて学ぶためには、使用するIngressコントローラーのドキュメントを確認してください。 +他の全てのKubernetesリソースと同様に、Ingressには`apiVersion`、`kind`や`metadata`フィールドが必要です。Ingressオブジェクトの名前は、有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。設定ファイルに関する一般的な情報は、[アプリケーションのデプロイ](/ja/docs/tasks/run-application/run-stateless-application-deployment/)、[コンテナの設定](/docs/tasks/configure-pod-container/configure-pod-configmap/)、[リソースの管理](/docs/concepts/cluster-administration/manage-deployment/)を参照してください。Ingressでは、Ingressコントローラーに依存しているいくつかのオプションの設定をするためにアノテーションを一般的に使用します。例としては、[rewrite-targetアノテーション](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md)などがあります。[Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers)の種類が異なれば、サポートするアノテーションも異なります。サポートされているアノテーションについて学ぶためには、使用するIngressコントローラーのドキュメントを確認してください。 Ingress [Spec](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)は、ロードバランサーやプロキシーサーバーを設定するために必要な全ての情報を持っています。最も重要なものとして、外部からくる全てのリクエストに対して一致したルールのリストを含みます。IngressリソースはHTTPトラフィックに対してのルールのみサポートしています。 @@ -86,7 +86,7 @@ Ingressコントローラーでは、デフォルトのバックエンドが設 ### デフォルトのバックエンド -ルールが設定されていないIngressは、全てのトラフィックをデフォルトのバックエンドに転送します。このデフォルトのバックエンドは、[Ingressコントローラー](/docs/concepts/services-networking/ingress-controllers)のオプション設定であり、Ingressリソースでは指定されていません。 +ルールが設定されていないIngressは、全てのトラフィックをデフォルトのバックエンドに転送します。このデフォルトのバックエンドは、[Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers)のオプション設定であり、Ingressリソースでは指定されていません。 IngressオブジェクトでHTTPリクエストが1つもホスト名とパスの条件に一致しない時、そのトラフィックはデフォルトのバックエンドに転送されます。 @@ -176,7 +176,7 @@ IngressコントローラーはService(`service1`、`service2`)が存在する 構築が完了すると、ADDRESSフィールドでロードバランサーのアドレスを確認できます。 {{< note >}} -使用する[Ingressコントローラー](/docs/concepts/services-networking/ingress-controllers)に依存しますが、default-http-backend[Service](/ja/docs/concepts/services-networking/service/)の作成が必要な場合があります。 +使用する[Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers)に依存しますが、default-http-backend[Service](/ja/docs/concepts/services-networking/service/)の作成が必要な場合があります。 {{< /note >}} ### 名前ベースのバーチャルホスティング @@ -374,7 +374,7 @@ Events: ## アベイラビリティーゾーンをまたいだ障害について -障害のあるドメインをまたいでトラフィックを分散する手法は、クラウドプロバイダーによって異なります。詳細に関して、[Ingress コントローラー](/docs/concepts/services-networking/ingress-controllers)のドキュメントを参照してください。複数のクラスターにおいてIngressをデプロイする方法の詳細に関しては[Kubernetes Cluster Federationのドキュメント](https://github.com/kubernetes-sigs/federation-v2)を参照してください。 +障害のあるドメインをまたいでトラフィックを分散する手法は、クラウドプロバイダーによって異なります。詳細に関して、[Ingress コントローラー](/ja/docs/concepts/services-networking/ingress-controllers)のドキュメントを参照してください。複数のクラスターにおいてIngressをデプロイする方法の詳細に関しては[Kubernetes Cluster Federationのドキュメント](https://github.com/kubernetes-sigs/federation-v2)を参照してください。 ## 将来追加予定の内容 @@ -390,6 +390,5 @@ Ingressリソースを直接含まない複数の方法でサービスを公開 ## {{% heading "whatsnext" %}} * [Ingress API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io)について学ぶ -* [Ingressコントローラー](/docs/concepts/services-networking/ingress-controllers/)について学ぶ +* [Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers/)について学ぶ * [MinikubeとNGINXコントローラーでIngressのセットアップを行う](/docs/tasks/access-application-cluster/ingress-minikube) - From 3dde44206e4b28ebe8a3c13de4d921c8b26af413 Mon Sep 17 00:00:00 2001 From: tkms0106 <23391543+tkms0106@users.noreply.github.com> Date: Sun, 30 Aug 2020 17:02:26 +0900 Subject: [PATCH 055/252] Update japanese list-all-running-container-images.md to follow v1.18 of the original (English) text --- .../list-all-running-container-images.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/content/ja/docs/tasks/access-application-cluster/list-all-running-container-images.md b/content/ja/docs/tasks/access-application-cluster/list-all-running-container-images.md index 3d36d99539..b20a1d77d0 100644 --- a/content/ja/docs/tasks/access-application-cluster/list-all-running-container-images.md +++ b/content/ja/docs/tasks/access-application-cluster/list-all-running-container-images.md @@ -25,13 +25,13 @@ weight: 100 - `kubectl get pods --all-namespaces`を使用して、すべての名前空間のPodを取得します - `-o jsonpath={.. image}`を使用して、コンテナイメージ名のリストのみが含まれるように出力をフォーマットします。これは、返されたjsonの`image`フィールドを再帰的に解析します。 - - jsonpathの使い方については、[jsonpathリファレンス](/docs/user-guide/jsonpath/)を参照してください。 + - jsonpathの使い方については、[jsonpathリファレンス](/docs/reference/kubectl/jsonpath/)を参照してください。 - `tr`、`sort`、`uniq`などの標準ツールを使用して出力をフォーマットします。 - `tr`を使用してスペースを改行に置換します。 - `sort`を使用して結果を並べ替えます。 - `uniq`を使用してイメージ数を集計します。 -```sh +```shell kubectl get pods --all-namespaces -o jsonpath="{..image}" |\ tr -s '[[:space:]]' '\n' |\ sort |\ @@ -42,7 +42,7 @@ uniq -c 別の方法として、Pod内のimageフィールドへの絶対パスを使用することができます。これにより、フィールド名が繰り返されている場合でも正しいフィールドが取得されます。多くのフィールドは与えられたアイテム内で`name`と呼ばれます: -```sh +```shell kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}" ``` @@ -61,7 +61,7 @@ jsonpathは次のように解釈されます: `range`を使用して要素を個別に繰り返し処理することにより、フォーマットをさらに制御できます。 -```sh +```shell kubectl get pods --all-namespaces -o=jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' |\ sort ``` @@ -70,7 +70,7 @@ sort 特定のラベルに一致するPodのみを対象とするには、-lフラグを使用します。以下は、`app=nginx`に一致するラベルを持つPodのみに一致します。 -```sh +```shell kubectl get pods --all-namespaces -o=jsonpath="{..image}" -l app=nginx ``` @@ -78,7 +78,7 @@ kubectl get pods --all-namespaces -o=jsonpath="{..image}" -l app=nginx 特定の名前空間のPodのみを対象とするには、namespaceフラグを使用します。以下は`kube-system`名前空間のPodのみに一致します。 -```sh +```shell kubectl get pods --namespace kube-system -o jsonpath="{..image}" ``` @@ -87,7 +87,7 @@ kubectl get pods --namespace kube-system -o jsonpath="{..image}" jsonpathの代わりに、kubectlは[go-templates](https://golang.org/pkg/text/template/)を使用した出力のフォーマットをサポートしています: -```sh +```shell kubectl get pods --all-namespaces -o go-template --template="{{range .items}}{{range .spec.containers}}{{.image}} {{end}}{{end}}" ``` @@ -104,7 +104,7 @@ kubectl get pods --all-namespaces -o go-template --template="{{range .items}}{{r ### 参照 -* [jsonpath](/docs/user-guide/jsonpath/)参照ガイド +* [jsonpath](/docs/reference/kubectl/jsonpath/)参照ガイド * [Go template](https://golang.org/pkg/text/template/)参照ガイド From b03e68d000474dd887cbc5c93beaaadc91d29314 Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Thu, 3 Sep 2020 12:21:25 +0900 Subject: [PATCH 056/252] Update ja/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html --- .../tutorials/kubernetes-basics/deploy-app/deploy-intro.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html b/content/ja/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html index 8bb7a2e6c8..d0b22024b4 100644 --- a/content/ja/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html +++ b/content/ja/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html @@ -28,7 +28,7 @@ weight: 10

Kubernetes Deployments

- 実行中のKubernetesクラスターを入手すると、その上にコンテナ化アプリケーションをデプロイすることができます。そのためには、KubernetesのDeployment の設定を作成します。DeploymentはKubernetesにあなたのアプリケーションのインスタンスを作成し、更新する方法を指示します。Deploymentを作成すると、Kubernetesマスターは指定されたアプリケーションインスタンスをクラスター内の個々のノードにスケジュールします。 + 実行中のKubernetesクラスターを入手すると、その上にコンテナ化アプリケーションをデプロイすることができます。そのためには、KubernetesのDeployment の設定を作成します。DeploymentはKubernetesにあなたのアプリケーションのインスタンスを作成し、更新する方法を指示します。Deploymentを作成すると、KubernetesマスターはDeployment内に含まれるアプリケーションインスタンスをクラスター内の個々のノードで実行するようにスケジュールします。

アプリケーションインスタンスが作成されると、Kubernetes Deploymentコントローラーは、それらのインスタンスを継続的に監視します。インスタンスをホストしているノードが停止、削除された場合、Deploymentコントローラーはそのインスタンスをクラスター内の別のノード上のインスタンスと置き換えます。これは、マシンの故障やメンテナンスに対処するためのセルフヒーリングの仕組みを提供しています。

@@ -72,7 +72,7 @@ weight: 10

Kubernetesのコマンドラインインターフェイスであるkubectlを使用して、Deploymentを作成、管理できます。kubectlはKubernetes APIを使用してクラスターと対話します。このモジュールでは、Kubernetesクラスターでアプリケーションを実行するDeploymentを作成するために必要な、最も一般的なkubectlコマンドについて学びます。

-

Deploymentを作成するときは、アプリケーションのコンテナイメージと実行するレプリカの数を指定する必要があります。Deploymentを更新することで、あとでその情報を変更できます。チュートリアルのモジュール5と6では、Deploymentをどのようにスケール、更新できるかについて説明します。

+

Deploymentを作成するときは、アプリケーションのコンテナイメージと実行するレプリカの数を指定する必要があります。Deploymentを更新することで、あとでその情報を変更できます。チュートリアルのモジュール5と6では、Deploymentをどのようにスケール、更新できるかについて説明します。

From e7c156a4ffd5fa638bd6e0e1cdbbb603f01d37e8 Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Thu, 3 Sep 2020 12:08:51 +0900 Subject: [PATCH 057/252] Update ja/docs/tutorials/kubernetes-basics/expose/expose-intro.html --- .../docs/tutorials/kubernetes-basics/expose/expose-intro.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tutorials/kubernetes-basics/expose/expose-intro.html b/content/ja/docs/tutorials/kubernetes-basics/expose/expose-intro.html index ea39fbd94e..3111e67396 100644 --- a/content/ja/docs/tutorials/kubernetes-basics/expose/expose-intro.html +++ b/content/ja/docs/tutorials/kubernetes-basics/expose/expose-intro.html @@ -28,7 +28,7 @@ weight: 10

Kubernetes Serviceの概要

-

Kubernetes Podの寿命は永続的ではありません。実際、Podにはライフサイクルがあります。ワーカーのノードが停止すると、そのノードで実行されているPodも失われます。そうなると、ReplicaSetは、新しいPodを作成してアプリケーションを実行し続けるために、クラスターを動的に目的の状態に戻すことができます。別の例として、3つのレプリカを持つ画像処理バックエンドを考えます。それらのレプリカは交換可能です。フロントエンドシステムはバックエンドのレプリカを気にしたり、Podが失われて再作成されたとしても配慮すべきではありません。ただし、Kubernetesクラスター内の各Podは、同じノード上のPodであっても一意のIPアドレスを持っているため、アプリケーションが機能し続けるように、Pod間の変更を自動的に調整する方法が必要です。

+

Kubernetes Podの寿命は永続的ではありません。実際、Podにはライフサイクルがあります。ワーカーのノードが停止すると、そのノードで実行されているPodも失われます。そうなると、ReplicaSetは、新しいPodを作成してアプリケーションを実行し続けるために、クラスターを動的に目的の状態に戻すことができます。別の例として、3つのレプリカを持つ画像処理バックエンドを考えます。それらのレプリカは交換可能です。フロントエンドシステムはバックエンドのレプリカを気にしたり、Podが失われて再作成されたとしても配慮すべきではありません。ただし、Kubernetesクラスター内の各Podは、同じノード上のPodであっても一意のIPアドレスを持っているため、アプリケーションが機能し続けるように、Pod間の変更を自動的に調整する方法が必要です。

KubernetesのServiceは、Podの論理セットと、それらにアクセスするためのポリシーを定義する抽象概念です。Serviceによって、依存Pod間の疎結合が可能になります。Serviceは、すべてのKubernetesオブジェクトのように、YAML(推奨)またはJSONを使って定義されます。Serviceが対象とするPodのセットは通常、LabelSelectorによって決定されます(なぜ仕様にセレクタを含めずにServiceが必要になるのかについては下記を参照してください)。

From a17f9d843be7e9224df41be5f8b43677e77f4078 Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Wed, 2 Sep 2020 12:12:28 +0900 Subject: [PATCH 058/252] Update ja/docs/tutorials/services/source-ip.md --- .../ja/docs/tutorials/services/source-ip.md | 67 +++++++++---------- 1 file changed, 31 insertions(+), 36 deletions(-) diff --git a/content/ja/docs/tutorials/services/source-ip.md b/content/ja/docs/tutorials/services/source-ip.md index 69c626d532..05a54152a3 100644 --- a/content/ja/docs/tutorials/services/source-ip.md +++ b/content/ja/docs/tutorials/services/source-ip.md @@ -148,7 +148,7 @@ ip addr そして、`wget`を使用してローカルのウェブサーバーに問い合わせます。 ```shell -# 10.0.170.92 の部分をウェブサーバーのPodのIPv4アドレスに置き換えてください +# "10.0.170.92" の部分をService名が"clusterip"のIPv4アドレスに置き換えてください wget -qO - 10.0.170.92 ``` ``` @@ -176,7 +176,7 @@ service/nodeport exposed ```shell NODEPORT=$(kubectl get -o jsonpath="{.spec.ports[0].nodePort}" services nodeport) -NODES=$(kubectl get nodes -o jsonpath='{ $.items[*].status.addresses[?(@.type=="ExternalIP")].address }') +NODES=$(kubectl get nodes -o jsonpath='{ $.items[*].status.addresses[?(@.type=="InternalIP")].address }') ``` クラウドプロバイダーで実行する場合、上に示した`nodes:nodeport`に対してファイアウォールのルールを作成する必要があるかもしれません。それでは、上で割り当てたノードポート経由で、クラスターの外部からServiceにアクセスしてみましょう。 @@ -204,17 +204,19 @@ client_address=10.240.0.3 図で表すと次のようになります。 -``` - client - \ ^ - \ \ - v \ - node 1 <--- node 2 - | ^ SNAT - | | ---> - v | - endpoint -``` +{{< mermaid >}} +graph LR; + client(client)-->node2[Node 2]; + node2-->client; + node2-. SNAT .->node1[Node 1]; + node1-. SNAT .->node2; + node1-->endpoint(Endpoint); + + classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000; + classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff; + class node1,node2,endpoint k8s; + class client plain; +{{}} クライアントのIPが失われることを回避するために、Kubernetesには[クライアントの送信元IPを保持する](/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip)機能があります。`service.spec.externalTrafficPolicy`の値を`Local`に設定すると、kube-proxyはローカルに存在するエンドポイントへのプロキシーリクエストだけをプロキシーし、他のノードへはトラフィックを転送しなくなります。このアプローチでは、オリジナルの送信元IPアドレスが保持されます。ローカルにエンドポイントが存在しない場合には、そのノードに送信されたパケットは損失します。そのため、エンドポイントに到達するパケットに適用する可能性のあるパケット処理ルールでは、送信元IPが正しいことを信頼できます。 @@ -253,17 +255,20 @@ client_address=198.51.100.79 図で表すと次のようになります。 -``` - client - ^ / \ - / / \ - / v X - node 1 node 2 - ^ | - | | - | v - endpoint -``` +{{< mermaid >}} +graph TD; + client --> node1[Node 1]; + client(client) --x node2[Node 2]; + node1 --> endpoint(endpoint); + endpoint --> node1; + + classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000; + classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff; + class node1,node2,endpoint k8s; + class client plain; +{{}} + + ## `Type=LoadBalancer`を使用したServiceでの送信元IP @@ -312,17 +317,7 @@ client_address=10.240.0.5 図で表すと次のようになります。 -``` - client - | - lb VIP - / ^ - v / -ヘルスチェック ---> node 1 node 2 <--- ヘルスチェック - 200 <--- ^ | ---> 500 - | V - endpoint -``` +![Source IP with externalTrafficPolicy](/images/docs/sourceip-externaltrafficpolicy.svg) アノテーションを設定することで動作をテストできます。 @@ -397,7 +392,7 @@ client_address=198.51.100.79 2. クライアントからロードバランサーのVIPに送信されたリクエストが、中間のプロキシーではなく、クライアントの送信元IPとともにノードまで到達するようなパケット転送が使用される。 -1つめのカテゴリーのロードバランサーの場合、真のクライアントIPと通信するために、 HTTPの[Forwarded](https://tools.ietf.org/html/rfc7239#section-5.2)ヘッダーや[X-FORWARDED-FOR](https://ja.wikipedia.org/wiki/X-Forwarded-For)ヘッダー、[proxy protocol](http://www.haproxy.org/download/1.5/doc/proxy-protocol.txt)などの、ロードバランサーとバックエンドの間で合意されたプロトコルを使用する必要があります。2つ目のカテゴリーのロードバランサーの場合、Serviceの`service.spec.healthCheckNodePort`フィールドに保存されたポートを指すHTTPのヘルスチェックを作成することで、上記の機能を活用できます。 +1つめのカテゴリーのロードバランサーの場合、真のクライアントIPと通信するために、 HTTPの[Forwarded](https://tools.ietf.org/html/rfc7239#section-5.2)ヘッダーや[X-FORWARDED-FOR](https://ja.wikipedia.org/wiki/X-Forwarded-For)ヘッダー、[proxy protocol](https://www.haproxy.org/download/1.5/doc/proxy-protocol.txt)などの、ロードバランサーとバックエンドの間で合意されたプロトコルを使用する必要があります。2つ目のカテゴリーのロードバランサーの場合、Serviceの`service.spec.healthCheckNodePort`フィールドに保存されたポートを指すHTTPのヘルスチェックを作成することで、上記の機能を活用できます。 ## {{% heading "cleanup" %}} From f9469f99d219d5fe56c47b24cff6a6313c24252f Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Tue, 1 Sep 2020 00:36:36 +0900 Subject: [PATCH 059/252] Update resource-quotas.md --- content/ja/docs/concepts/policy/resource-quotas.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/ja/docs/concepts/policy/resource-quotas.md b/content/ja/docs/concepts/policy/resource-quotas.md index c6b2ff51e8..d504e217fc 100644 --- a/content/ja/docs/concepts/policy/resource-quotas.md +++ b/content/ja/docs/concepts/policy/resource-quotas.md @@ -23,7 +23,7 @@ weight: 10 - 管理者は各名前空間で1つの`ResourceQuota`を作成します。 - ユーザーが名前空間内でリソース(Pod、Serviceなど)を作成し、クォータシステムが`ResourceQuota`によって定義されたハードリソースリミットを超えないことを保証するために、リソースの使用量をトラッキングします。 - リソースの作成や更新がクォータの制約に違反しているとき、そのリクエストはHTTPステータスコード`403 FORBIDDEN`で失敗し、違反した制約を説明するメッセージが表示されます。 -- `cpu`や`memory`といったコンピューターリソースに対するクォータが名前空間内で有効になっているとき、ユーザーはそれらの値に対する`requests`や`limits`を設定する必要があります。設定しないとクォータシステムがPodの作成を拒否します。 ヒント: コンピュートリソースの要求を設定しないPodに対してデフォルト値を強制するために、`LimitRanger`アドミッションコントローラーを使用してください。この問題を解決する例は[walkthrough](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/)で参照できます。 +- `cpu`や`memory`といったコンピューターリソースに対するクォータが名前空間内で有効になっているとき、ユーザーはそれらの値に対する`requests`や`limits`を設定する必要があります。設定しないとクォータシステムがPodの作成を拒否します。 ヒント: コンピュートリソースの要求を設定しないPodに対してデフォルト値を強制するために、`LimitRanger`アドミッションコントローラーを使用してください。この問題を解決する例は[walkthrough](/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)で参照できます。 `ResourceQuota`のオブジェクト名は、有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります. @@ -58,7 +58,7 @@ weight: 10 ### 拡張リソースのためのリソースクォータ -上記で取り上げたリソースに加えて、Kubernetes v1.10において、[拡張リソース](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources)のためのリソースクォータのサポートが追加されました。 +上記で取り上げたリソースに加えて、Kubernetes v1.10において、[拡張リソース](/docs/concepts/configuration/manage-resources-containers/#extended-resources)のためのリソースクォータのサポートが追加されました。 拡張リソースに対するオーバーコミットが禁止されているのと同様に、リソースクォータで拡張リソース用に`requests`と`limits`の両方を指定しても意味がありません。現在、拡張リソースに対しては`requests.`というプレフィックスのついたクォータアイテムのみ設定できます。 @@ -163,7 +163,7 @@ Kubernetes v1.9より前のバージョンでは、限定されたリソース ### PriorityClass毎のリソースクォータ -{{< feature-state for_k8s_version="1.12" state="beta" >}} +{{< feature-state for_k8s_version="v1.12" state="beta" >}} Podは特定の[優先度](/docs/concepts/configuration/pod-priority-preemption/#pod-priority)で作成されます。リソースクォータのSpec内にある`scopeSelector`フィールドを使用して、Podの優先度に基づいてPodのシステムリソースの消費をコントロールできます。 @@ -451,7 +451,7 @@ kubectl create quota test --hard=count/deployments.extensions=2,count/replicaset ``` ```shell -kubectl run nginx --image=nginx --replicas=2 --namespace=myspace +kubectl create deployment nginx --image=nginx --namespace=myspace ``` ```shell From 011fab911e2c224c430fc57823e7de60fcad3519 Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Tue, 1 Sep 2020 00:40:56 +0900 Subject: [PATCH 060/252] Update resource-quotas.md --- content/ja/docs/concepts/policy/resource-quotas.md | 1 + 1 file changed, 1 insertion(+) diff --git a/content/ja/docs/concepts/policy/resource-quotas.md b/content/ja/docs/concepts/policy/resource-quotas.md index d504e217fc..a58131646c 100644 --- a/content/ja/docs/concepts/policy/resource-quotas.md +++ b/content/ja/docs/concepts/policy/resource-quotas.md @@ -452,6 +452,7 @@ kubectl create quota test --hard=count/deployments.extensions=2,count/replicaset ```shell kubectl create deployment nginx --image=nginx --namespace=myspace +kubectl scale deployment nginx --replicas=2 --namespace=myspace ``` ```shell From 44552a817d69ee2db490114d23295207b0b9ce3d Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Thu, 3 Sep 2020 20:22:25 +0900 Subject: [PATCH 061/252] Update resource-quotas.md --- content/ja/docs/concepts/policy/resource-quotas.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/policy/resource-quotas.md b/content/ja/docs/concepts/policy/resource-quotas.md index a58131646c..e7368a8f94 100644 --- a/content/ja/docs/concepts/policy/resource-quotas.md +++ b/content/ja/docs/concepts/policy/resource-quotas.md @@ -550,5 +550,5 @@ plugins: ## {{% heading "whatsnext" %}} -さらなる情報は[クォータの design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md)を参照してください。 +- さらなる情報は[クォータの design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md)を参照してください。 From c9ed105f44b8d5ebc5a7514d85217fe25fb6f387 Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Fri, 4 Sep 2020 07:50:32 +0900 Subject: [PATCH 062/252] Update node-conformance.md --- content/ja/docs/setup/best-practices/node-conformance.md | 1 - 1 file changed, 1 deletion(-) diff --git a/content/ja/docs/setup/best-practices/node-conformance.md b/content/ja/docs/setup/best-practices/node-conformance.md index 0db9cb4432..355dfdf366 100644 --- a/content/ja/docs/setup/best-practices/node-conformance.md +++ b/content/ja/docs/setup/best-practices/node-conformance.md @@ -3,7 +3,6 @@ title: ノードのセットアップの検証 weight: 30 --- -{{< toc >}} ## ノード適合テスト From 624d15cdc45cc2614620ff4d92e84589cfa29cd6 Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Fri, 28 Aug 2020 12:52:49 +0900 Subject: [PATCH 063/252] Updata content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md --- .../configure-access-multiple-clusters.md | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md b/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md index 2dc61d16a9..28fe1fdeaa 100644 --- a/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md +++ b/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md @@ -21,7 +21,9 @@ card: ## {{% heading "prerequisites" %}} -{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} +{{< include "task-tutorial-prereqs.md" >}} + +{{< glossary_tooltip text="kubectl" term_id="kubectl" >}}がインストールされているか確認するため、`kubectl version --client`を実行してください。kubectlのバージョンは、クラスタのAPIサーバの[1つ以内のバージョン](/ja/docs/setup/release/version-skew-policy/#kubectl)である必要があります。 @@ -306,7 +308,7 @@ export KUBECONFIG=$KUBECONFIG:$HOME/.kube/config ``` ### Windows Powershell ```shell -$Env:KUBECONFIG=($Env:KUBECONFIG;$HOME/.kube/config) +$Env:KUBECONFIG="$Env:KUBECONFIG;$HOME/.kube/config" ``` `KUBECONFIG`環境変数内のファイルからまとめられた設定情報を確認してください。`config-exercise`ディレクトリ内から、以下のコマンドを実行してください: @@ -319,11 +321,11 @@ kubectl config view `KUBECONFIG`環境変数を元に戻してください。例えば: -Linux: +### Linux: ```shell export KUBECONFIG=$KUBECONFIG_SAVED ``` -Windows PowerShell +### Windows PowerShell ```shell $Env:KUBECONFIG=$ENV:KUBECONFIG_SAVED ``` From 3cbdf975301f67a8e6d3b9ab65d697fd21b620a0 Mon Sep 17 00:00:00 2001 From: yu-kasuya Date: Mon, 31 Aug 2020 12:19:40 +0900 Subject: [PATCH 064/252] Apply suggestions from code review Co-authored-by: Keita Akutsu --- .../configure-access-multiple-clusters.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md b/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md index 28fe1fdeaa..072fc36cf2 100644 --- a/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md +++ b/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md @@ -23,7 +23,7 @@ card: {{< include "task-tutorial-prereqs.md" >}} -{{< glossary_tooltip text="kubectl" term_id="kubectl" >}}がインストールされているか確認するため、`kubectl version --client`を実行してください。kubectlのバージョンは、クラスタのAPIサーバの[1つ以内のバージョン](/ja/docs/setup/release/version-skew-policy/#kubectl)である必要があります。 +{{< glossary_tooltip text="kubectl" term_id="kubectl" >}}がインストールされているか確認するため、`kubectl version --client`を実行してください。kubectlのバージョンは、クラスタのAPIサーバの[1つのマイナーバージョン内](/ja/docs/setup/release/version-skew-policy/#kubectl)にある必要があります。 @@ -337,4 +337,3 @@ $Env:KUBECONFIG=$ENV:KUBECONFIG_SAVED * [kubeconfigファイルを使ってクラスターへのアクセスを管理する](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) * [kubectl config](/docs/reference/generated/kubectl/kubectl-commands#config) - From 5848086102d46989b67d44557e7cb07815c33f84 Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Fri, 4 Sep 2020 11:56:57 +0900 Subject: [PATCH 065/252] fix some words --- .../configure-access-multiple-clusters.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md b/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md index 072fc36cf2..c85ef1f401 100644 --- a/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md +++ b/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md @@ -23,7 +23,7 @@ card: {{< include "task-tutorial-prereqs.md" >}} -{{< glossary_tooltip text="kubectl" term_id="kubectl" >}}がインストールされているか確認するため、`kubectl version --client`を実行してください。kubectlのバージョンは、クラスタのAPIサーバの[1つのマイナーバージョン内](/ja/docs/setup/release/version-skew-policy/#kubectl)にある必要があります。 +{{< glossary_tooltip text="kubectl" term_id="kubectl" >}}がインストールされているか確認するため、`kubectl version --client`を実行してください。kubectlのバージョンは、クラスターのAPIサーバの[1つのマイナーバージョン内](/ja/docs/setup/release/version-skew-policy/#kubectl)である必要があります。 From 7b627c522913132c3f6be8ab7fa97784d9df4309 Mon Sep 17 00:00:00 2001 From: yu-kasuya Date: Fri, 4 Sep 2020 19:27:02 +0900 Subject: [PATCH 066/252] Apply suggestions from code review Co-authored-by: Naoki Oketani --- .../configure-access-multiple-clusters.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md b/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md index c85ef1f401..b2ebc16d18 100644 --- a/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md +++ b/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md @@ -23,7 +23,7 @@ card: {{< include "task-tutorial-prereqs.md" >}} -{{< glossary_tooltip text="kubectl" term_id="kubectl" >}}がインストールされているか確認するため、`kubectl version --client`を実行してください。kubectlのバージョンは、クラスターのAPIサーバの[1つのマイナーバージョン内](/ja/docs/setup/release/version-skew-policy/#kubectl)である必要があります。 +{{< glossary_tooltip text="kubectl" term_id="kubectl" >}}がインストールされているか確認するため、`kubectl version --client`を実行してください。kubectlのバージョンは、クラスターのAPIサーバーの[1つのマイナーバージョン内](/ja/docs/setup/release/version-skew-policy/#kubectl)である必要があります。 From edb89f7f8f8baa14e34a4af3dd9f48948f5d0b93 Mon Sep 17 00:00:00 2001 From: Tadaki Sakai Date: Fri, 4 Sep 2020 22:53:54 +0900 Subject: [PATCH 067/252] Fix typo in Ja concepts/overview/what-is-kubernetes.md Fixed typo for word "stateless". --- content/ja/docs/concepts/overview/what-is-kubernetes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/overview/what-is-kubernetes.md b/content/ja/docs/concepts/overview/what-is-kubernetes.md index 5f2f4bbf18..aeaca7940e 100644 --- a/content/ja/docs/concepts/overview/what-is-kubernetes.md +++ b/content/ja/docs/concepts/overview/what-is-kubernetes.md @@ -75,7 +75,7 @@ Kubernetesは、従来型の全部入りなPaaS(Platform as a Service)のシス Kubernetesは... -* サポートするアプリケーションの種類を制限しません。Kubernetesは、スレートレス、ステートフルやデータ処理のワークロードなど、非常に多様なワークロードをサポートすることを目的としています。アプリケーションがコンテナで実行できるのであれば、Kubernetes上で問題なく実行できるはずです。 +* サポートするアプリケーションの種類を制限しません。Kubernetesは、ステートレス、ステートフルやデータ処理のワークロードなど、非常に多様なワークロードをサポートすることを目的としています。アプリケーションがコンテナで実行できるのであれば、Kubernetes上で問題なく実行できるはずです。 * ソースコードのデプロイやアプリケーションのビルドは行いません。継続的なインテグレーション、デリバリー、デプロイ(CI/CD)のワークフローは、技術的な要件だけでなく組織の文化や好みで決められます。 * ミドルウェア(例:メッセージバス)、データ処理フレームワーク(例:Spark)、データベース(例:MySQL)、キャッシュ、クラスターストレージシステム(例:Ceph)といったアプリケーションレベルの機能を組み込んで提供しません。それらのコンポーネントは、Kubernetes上で実行することもできますし、[Open Service Broker](https://openservicebrokerapi.org/)のようなポータブルメカニズムを経由してKubernetes上で実行されるアプリケーションからアクセスすることも可能です。 * ロギング、モニタリングやアラートを行うソリューションは指定しません。PoCとしていくつかのインテグレーションとメトリクスを収集し出力するメカニズムを提供します。 From 64813947bd964c2063b7410ac66a5e44827761b2 Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Fri, 4 Sep 2020 12:01:27 +0900 Subject: [PATCH 068/252] Update ja/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html --- .../kubernetes-basics/deploy-app/deploy-interactive.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html b/content/ja/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html index 4af01cc759..71e04ef76b 100644 --- a/content/ja/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html +++ b/content/ja/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html @@ -20,7 +20,7 @@ weight: 20

- Podは、Kubernetesアプリケーションの基本的な実行単位です。各Podは、クラスターで実行されているワークロードの一部を表します。Podの詳細はこちらです。 + Podは、Kubernetesアプリケーションの基本的な実行単位です。各Podは、クラスターで実行されているワークロードの一部を表します。Podの詳細はこちらです。

From cb0f2a951944d983a507b5b6317018045d314c4b Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Sat, 5 Sep 2020 02:04:03 +0900 Subject: [PATCH 069/252] Update certificates.md --- .../ja/docs/setup/best-practices/certificates.md | 16 +++++++--------- 1 file changed, 7 insertions(+), 9 deletions(-) diff --git a/content/ja/docs/setup/best-practices/certificates.md b/content/ja/docs/setup/best-practices/certificates.md index 7f67ee7006..7fbf4bf8b8 100644 --- a/content/ja/docs/setup/best-practices/certificates.md +++ b/content/ja/docs/setup/best-practices/certificates.md @@ -26,10 +26,10 @@ Kubernetesは下記の用途でPKIを必要とします： * APIサーバーがetcdと通信するためのクライアント証明書 * controller managerがAPIサーバーと通信するためのクライアント証明書およびkubeconfig * スケジューラーがAPIサーバーと通信するためのクライアント証明書およびkubeconfig -* [front-proxy][proxy]用のクライアント証明書およびサーバー証明書 +* [front-proxy](/docs/tasks/extend-kubernetes/configure-aggregation-layer/)用のクライアント証明書およびサーバー証明書 {{< note >}} -`front-proxy`証明書は、[Kubernetes APIの拡張](/docs/tasks/access-kubernetes-api/setup-extension-api-server/)をサポートするためにkube-proxyを実行する場合のみ必要です。 +`front-proxy`証明書は、[Kubernetes APIの拡張](/docs/tasks/extend-kubernetes/setup-extension-api-server/)をサポートするためにkube-proxyを実行する場合のみ必要です。 {{< /note >}} さらに、etcdはクライアントおよびピア間の認証に相互TLS通信を実装しています。 @@ -52,7 +52,7 @@ kubeadmで証明書を生成したくない場合は、下記の方法のいず |------------------------|---------------------------|----------------------------------| | ca.crt,key | kubernetes-ca | Kubernetes全体の認証局　　　 | | etcd/ca.crt,key | etcd-ca | etcd用　　　　　　　　　　　　　　 | -| front-proxy-ca.crt,key | kubernetes-front-proxy-ca | [front-end proxy][proxy]用　　　 | +| front-proxy-ca.crt,key | kubernetes-front-proxy-ca | [front-end proxy](/docs/tasks/extend-kubernetes/configure-aggregation-layer/)用　　　 | 上記の認証局に加えて、サービスアカウント管理用に公開鍵/秘密鍵のペア(`sa.key`と`sa.pub`)を取得する事が必要です。 @@ -72,9 +72,9 @@ CAの秘密鍵をクラスターにコピーしたくない場合、自身で全 | kube-apiserver-kubelet-client | kubernetes-ca | system:masters | client | | | front-proxy-client | kubernetes-front-proxy-ca | | client | | -[1]: クラスターに接続するIPおよびDNS名( [kubeadm][kubeadm]を使用する場合と同様、ロードバランサーのIPおよびDNS名、`kubernetes`、`kubernetes.default`、`kubernetes.default.svc`、`kubernetes.default.svc.cluster`、`kubernetes.default.svc.cluster.local`) +[1]: クラスターに接続するIPおよびDNS名( [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/)を使用する場合と同様、ロードバランサーのIPおよびDNS名、`kubernetes`、`kubernetes.default`、`kubernetes.default.svc`、`kubernetes.default.svc.cluster`、`kubernetes.default.svc.cluster.local`) -`kind`は下記の[x509の鍵用途][usage]のタイプにマッピングされます: +`kind`は下記の[x509の鍵用途](https://godoc.org/k8s.io/api/certificates/v1beta1#KeyUsage)のタイプにマッピングされます: | 種類 | 鍵の用途 　　　 | |--------|---------------------------------------------------------------------------------| @@ -96,7 +96,8 @@ kubeadm利用者のみ： ### 証明書のパス -証明書は推奨パスに配置するべきです([kubeadm][kubeadm]を使用する場合と同様)。パスは場所に関係なく与えられた引数で特定されます。 +証明書は推奨パスに配置するべきです([kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/)を使用する場合と同様)。 +パスは場所に関係なく与えられた引数で特定されます。 | デフォルトCN | 鍵の推奨パス 　　　　　　 | 証明書の推奨パス 　　　　　 | コマンド | 鍵を指定する引数 | 証明書を指定する引数 | |------------------------------|------------------------------|-----------------------------|----------------|------------------------------|-------------------------------------------| @@ -157,8 +158,5 @@ KUBECONFIG= kubectl config use-context default-system | controller-manager.conf | kube-controller-manager | `manifests/kube-controller-manager.yaml`のマニフェストファイルに追記する必要があります。 | | scheduler.conf | kube-scheduler | `manifests/kube-scheduler.yaml`のマニフェストファイルに追記する必要があります。 | -[usage]: https://godoc.org/k8s.io/api/certificates/v1beta1#KeyUsage -[kubeadm]: /docs/reference/setup-tools/kubeadm/kubeadm/ -[proxy]: /docs/tasks/access-kubernetes-api/configure-aggregation-layer/ From 24dcb7b206cb6cfa28b537084c198f0de4bfe282 Mon Sep 17 00:00:00 2001 From: Tadaki Sakai Date: Mon, 7 Sep 2020 07:05:04 +0900 Subject: [PATCH 070/252] fix diagonal line mark up of "replication" --- content/ja/docs/concepts/workloads/pods/pod-overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/workloads/pods/pod-overview.md b/content/ja/docs/concepts/workloads/pods/pod-overview.md index 76e8f11a62..4d286fdbcf 100644 --- a/content/ja/docs/concepts/workloads/pods/pod-overview.md +++ b/content/ja/docs/concepts/workloads/pods/pod-overview.md @@ -33,7 +33,7 @@ Kubernetesクラスター内でのPodは2つの主な方法で使うことがで * [Container Design Patterns](https://kubernetes.io/blog/2016/06/container-design-patterns) 各Podは、与えられたアプリケーションの単一のインスタンスを稼働するためのものです。もしユーザーのアプリケーションを水平にスケールさせたい場合(例: 複数インスタンスを稼働させる)、複数のPodを使うべきです。1つのPodは各インスタンスに対応しています。 -Kubernetesにおいて、これは一般的に_レプリケーション_ と呼ばれます。 +Kubernetesにおいて、これは一般的に _レプリケーション_ と呼ばれます。 レプリケーションされたPodは、通常コントローラーと呼ばれる抽象概念によって単一のグループとして作成、管理されます。 さらなる情報に関しては[Podとコントローラー](#pods-and-controllers)を参照して下さい。 From 60ba9f697db66821e6e2d85c083a14a1a269954f Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Fri, 4 Sep 2020 12:08:30 +0900 Subject: [PATCH 071/252] Update ja/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html --- .../kubernetes-basics/create-cluster/cluster-interactive.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html b/content/ja/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html index 8f260a0831..ae52322786 100644 --- a/content/ja/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html +++ b/content/ja/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html @@ -19,7 +19,7 @@ weight: 20
- ターミナルを使うには、PCまたはタブレットをお使いください + ターミナルを使うにはスクリーンが狭い場合は、PCまたはタブレットをお使いください
From 58cb155fd89e0ef55ff2452673c917140602d6ab Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Sun, 6 Sep 2020 22:53:17 +0900 Subject: [PATCH 072/252] Update _index.md --- content/ja/docs/setup/_index.md | 20 ++++---------------- 1 file changed, 4 insertions(+), 16 deletions(-) diff --git a/content/ja/docs/setup/_index.md b/content/ja/docs/setup/_index.md index 2d602e9300..4b6e930170 100644 --- a/content/ja/docs/setup/_index.md +++ b/content/ja/docs/setup/_index.md @@ -17,12 +17,11 @@ card: このセクションではKubernetesをセットアップして動かすための複数のやり方について説明します。 +Kubernetesをインストールする際には、メンテナンスの容易さ、セキュリティ、制御、利用可能なリソース、クラスターの運用及び管理に必要な専門知識に基づいてインストレーションタイプを選んでください。 -各Kubernetesソリューションはそれぞれ、メンテナンス性、セキュリティ、管理、利用可能なリソース、クラスターの運用に専門知識が必要など、異なる要件があります。 -Kubernetesクラスタはローカルマシン、クラウド、オンプレのデータセンターにデプロイすることもできますし、マネージドのKubernetesクラスターを選択することもできます。複数のクラウドプロバイダーやベアメタルの環境に跨ったカスタムソリューションを選ぶことも可能です。 +Kubernetesクラスタはローカルマシン、クラウド、オンプレのデータセンターにデプロイすることもできますし、マネージドのKubernetesクラスターを選択することもできます。複数のクラウドプロバイダーやベアメタルの環境に跨ったカスタムソリューションもあります。 -簡潔に言えば、学習用としても、本番環境用としてもKubernetesクラスターを作成することができます。 @@ -30,25 +29,14 @@ Kubernetesクラスタはローカルマシン、クラウド、オンプレの ## 環境について学ぶ -Kubernetesについて学んでいる場合、Dockerベースのソリューションを使いましょう。これらはKubernetesコミュニティにサポートされていたり、あるいはKubernetesクラスターをローカル環境にセットアップするエコシステムを持っていたりします。 +Kubernetesについて学んでいる場合、Kubernetesコミュニティにサポートされているツールや、Kubernetesクラスターをローカルマシンにセットアップするエコシステム内のツールを使いましょう。 -{{< table caption="Local machine solutions table that lists the tools supported by the community and the ecosystem to deploy Kubernetes." >}} - -|コミュニティ |エコシステム | -| ------------ | -------- | -| [Minikube](/ja/docs/setup/learning-environment/minikube/) | [CDK on LXD](https://www.ubuntu.com/kubernetes/docs/install-local) | -| [kind (Kubernetes IN Docker)](/docs/setup/learning-environment/kind/) | [Docker Desktop](https://www.docker.com/products/docker-desktop)| -| | [Minishift](https://docs.okd.io/latest/minishift/)| -| | [MicroK8s](https://microk8s.io/)| -| | [IBM Cloud Private-CE (Community Edition)](https://github.com/IBM/deploy-ibm-cloud-private) | -| | [IBM Cloud Private-CE (Community Edition) on Linux Containers](https://github.com/HSBawa/icp-ce-on-linux-containers)| -| | [k3s](https://k3s.io)| ## 本番環境 本番環境用のソリューションを評価する際には、Kubernetesクラスター(または抽象レイヤ)の運用においてどの部分を自分で管理し、どの部分をプロバイダーに任せるのかを考慮してください。 -[Certified Kubernetes](https://github.com/cncf/k8s-conformance/#certified-kubernetes)プロバイダーの一覧については、「[パートナー](https://kubernetes.io/ja/partners/#conformance)」を参照してください。 +[Certified Kubernetes](https://github.com/cncf/k8s-conformance/#certified-kubernetes)プロバイダーの一覧については、「[Kubernetes パートナー](https://kubernetes.io/ja/partners/#conformance)」を参照してください。 From a59c29be1a8cb70144c00cb187e3dce10b021dd5 Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Sun, 6 Sep 2020 23:20:18 +0900 Subject: [PATCH 073/252] Update _index.md --- content/ja/docs/setup/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/setup/_index.md b/content/ja/docs/setup/_index.md index 4b6e930170..6f7153f445 100644 --- a/content/ja/docs/setup/_index.md +++ b/content/ja/docs/setup/_index.md @@ -37,6 +37,6 @@ Kubernetesについて学んでいる場合、Kubernetesコミュニティにサ 本番環境用のソリューションを評価する際には、Kubernetesクラスター(または抽象レイヤ)の運用においてどの部分を自分で管理し、どの部分をプロバイダーに任せるのかを考慮してください。 -[Certified Kubernetes](https://github.com/cncf/k8s-conformance/#certified-kubernetes)プロバイダーの一覧については、「[Kubernetes パートナー](https://kubernetes.io/ja/partners/#conformance)」を参照してください。 +[Certified Kubernetes](https://github.com/cncf/k8s-conformance/#certified-kubernetes)プロバイダーの一覧については、[Kubernetes パートナー](https://kubernetes.io/ja/partners/#conformance)を参照してください。 From 2cc1ced9d5657cfa34848d61a1b69da51459272c Mon Sep 17 00:00:00 2001 From: Jin Hase Date: Mon, 31 Aug 2020 15:44:21 +0900 Subject: [PATCH 074/252] Update Japanese localization on concepts/workloads/controllers/daemonset.md --- .../workloads/controllers/daemonset.md | 50 ++++++++----------- 1 file changed, 22 insertions(+), 28 deletions(-) diff --git a/content/ja/docs/concepts/workloads/controllers/daemonset.md b/content/ja/docs/concepts/workloads/controllers/daemonset.md index a985ccf2fa..d6df9e2f83 100644 --- a/content/ja/docs/concepts/workloads/controllers/daemonset.md +++ b/content/ja/docs/concepts/workloads/controllers/daemonset.md @@ -2,7 +2,7 @@ reviewers: title: DaemonSet content_type: concept -weight: 50 +weight: 40 --- @@ -11,12 +11,11 @@ _DaemonSet_ は全て(またはいくつか)のNodeが単一のPodのコピー DaemonSetのいくつかの典型的な使用例は以下の通りです。 -- `glusterd`や`ceph`のようなクラスターのストレージデーモンを各Node上で稼働させる。 -- `fluentd`や`filebeat`のようなログ集計デーモンを各Node上で稼働させる。 -- [Prometheus Node Exporter](https://github.com/prometheus/node_exporter)や[Flowmill](https://github.com/Flowmill/flowmill-k8s/)、[Sysdig Agent](https://docs.sysdig.com)、`collectd`、[Dynatrace OneAgent](https://www.dynatrace.com/technologies/kubernetes-monitoring/)、 [AppDynamics Agent](https://docs.appdynamics.com/display/CLOUD/Container+Visibility+with+Kubernetes)、 [Datadog agent](https://docs.datadoghq.com/agent/kubernetes/daemonset_setup/)、 [New Relic agent](https://docs.newrelic.com/docs/integrations/kubernetes-integration/installation/kubernetes-installation-configuration)、Gangliaの`gmond`、[Instana Agent](https://www.instana.com/supported-integrations/kubernetes-monitoring/)や[Elastic Metricbeat](https://www.elastic.co/guide/en/beats/metricbeat/current/running-on-kubernetes.html)などのようなNodeのモニタリングデーモンを各Node上で稼働させる。 +- クラスターのストレージデーモンを全てのNode上で稼働させる。 +- ログ集計デーモンを全てのNode上で稼働させる。 +- Nodeのモニタリングデーモンを全てのNode上で稼働させる。 -シンプルなケースとして、各タイプのデーモンにおいて、全てのNodeをカバーする1つのDaemonSetが使用されるケースがあります。 -さらに複雑な設定では、単一のタイプのデーモン用ですが、異なるフラグや、異なるハードウェアタイプに対するメモリー、CPUリクエストを要求する複数のDaemonSetを使用するケースもあります。 +シンプルなケースとして、各タイプのデーモンにおいて、全てのNodeをカバーする1つのDaemonSetが使用されるケースがあります。さらに複雑な設定では、単一のタイプのデーモン用ですが、異なるフラグや、異なるハードウェアタイプに対するメモリー、CPUリクエストを要求する複数のDaemonSetを使用するケースもあります。 @@ -27,8 +26,7 @@ DaemonSetのいくつかの典型的な使用例は以下の通りです。 ### DaemonSetの作成 -ユーザーはYAMLファイル内でDaemonSetの設定を記述することができます。 -例えば、下記の`daemonset.yaml`ファイルでは`fluentd-elasticsearch`というDockerイメージを稼働させるDaemonSetの設定を記述します。 +ユーザーはYAMLファイル内でDaemonSetの設定を記述することができます。例えば、下記の`daemonset.yaml`ファイルでは`fluentd-elasticsearch`というDockerイメージを稼働させるDaemonSetの設定を記述します。 {{< codenew file="controllers/daemonset.yaml" >}} @@ -40,8 +38,7 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml ### 必須のフィールド -他の全てのKubernetesの設定と同様に、DaemonSetは`apiVersion`、`kind`と`metadata`フィールドが必須となります。 -設定ファイルの活用法に関する一般的な情報は、[アプリケーションのデプロイ](/ja/docs/tasks/run-application/run-stateless-application-deployment/)、[コンテナの設定](/ja/docs/tasks/)、[kubectlを用いたオブジェクトの管理](/ja/docs/concepts/overview/working-with-objects/object-management/)といったドキュメントを参照ください。 +他の全てのKubernetesの設定と同様に、DaemonSetは`apiVersion`、`kind`と`metadata`フィールドが必須となります。設定ファイルの活用法に関する一般的な情報は、[ステートレスアプリケーションの稼働](/ja/docs/tasks/run-application/run-stateless-application-deployment/)、[コンテナの設定](/ja/docs/tasks/)、[kubectlを用いたオブジェクトの管理](/ja/docs/concepts/overview/working-with-objects/object-management/)といったドキュメントを参照ください。 DaemonSetオブジェクトの名前は、有効な [DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。 @@ -52,7 +49,7 @@ DaemonSetオブジェクトの名前は、有効な `.spec.template`は`.spec`内での必須のフィールドの1つです。 -`.spec.template`は[Podテンプレート](/ja/docs/concepts/workloads/pods/pod-overview/#podテンプレート)となります。これはフィールドがネストされていて、`apiVersion`や`kind`をもたないことを除いては、[Pod](/ja/docs/concepts/workloads/pods/pod/)のテンプレートと同じスキーマとなります。 +`.spec.template`は[Podテンプレート](/ja/docs/concepts/workloads/pods/#podテンプレート)となります。これはフィールドがネストされていて、`apiVersion`や`kind`をもたないことを除いては、{{< glossary_tooltip text="Pod" term_id="pod" >}}のテンプレートと同じスキーマとなります。 Podに対する必須のフィールドに加えて、DaemonSet内のPodテンプレートは適切なラベルを指定しなくてはなりません([Podセレクター](#pod-selector)の項目を参照ください)。 @@ -60,7 +57,7 @@ DaemonSet内のPodテンプレートでは、[`RestartPolicy`](/ja/docs/concepts ### Podセレクター -`.spec.selector`フィールドはPodセレクターとなります。これは[Job](/docs/concepts/jobs/run-to-completion-finite-workloads/)の`.spec.selector`と同じものです。 +`.spec.selector`フィールドはPodセレクターとなります。これは[Job](/docs/concepts/workloads/controllers/job/)の`.spec.selector`と同じものです。 Kubernetes1.8のように、ユーザーは`.spec.template`のラベルにマッチするPodセレクターを指定しなくてはいけません。Podセレクターは、値を空のままにしてもデフォルト設定にならなくなりました。セレクターのデフォルト化は`kubectl apply`と互換性はありません。また、一度DaemonSetが作成されると、その`.spec.selector`は変更不可能になります。Podセレクターの変更は、意図しないPodの孤立を引き起こし、ユーザーにとってやっかいなものとなります。 @@ -75,11 +72,10 @@ Kubernetes1.8のように、ユーザーは`.spec.template`のラベルにマッ また、ユーザーは通常、別のDaemonSetやReplicaSetなどの別のワークロードリソースを使用する場合であっても直接であっても、このセレクターマッチするラベルを持つPodを作成すべきではありません。さもないと、DaemonSet {{}}は、それらのPodが作成されたものとみなすためです。Kubernetesはこれを行うことを止めません。ユーザーがこれを行いたい1つのケースとしては、テスト用にノード上に異なる値を持つPodを手動で作成するような場合があります。 -### 特定のいくつかのNode上のみにPodを稼働させる +### 選択したNode上でPodを稼働させる もしユーザーが`.spec.template.spec.nodeSelector`を指定したとき、DaemonSetコントローラーは、その[node -selector](/ja/docs/concepts/configuration/assign-pod-node/)にマッチするPodをNode上に作成します。 -同様に、もし`.spec.template.spec.affinity`を指定したとき、DaemonSetコントローラーは[node affinity](/ja/docs/concepts/configuration/assign-pod-node/)マッチするPodをNode上に作成します。 +selector](/docs/concepts/scheduling-eviction/assign-pod-node/)にマッチするPodをNode上に作成します。同様に、もし`.spec.template.spec.affinity`を指定したとき、DaemonSetコントローラーは[node affinity](/docs/concepts/scheduling-eviction/assign-pod-node/)マッチするPodをNode上に作成します。 もしユーザーがどちらも指定しないとき、DaemonSetコントローラーは全てのNode上にPodを作成します。 ## Daemon Podがどのようにスケジューリングされるか @@ -94,7 +90,7 @@ DaemonSetは全ての利用可能なNodeが単一のPodのコピーを稼働さ * 矛盾するPodのふるまい: スケジューリングされるのを待っている通常のPodは、作成されているが`Pending`状態となりますが、DaemonSetのPodは`Pending`状態で作成されません。これはユーザーにとって困惑するものです。 * [Podプリエンプション(Pod preemption)](/docs/concepts/configuration/pod-priority-preemption/)はデフォルトスケジューラーによってハンドルされます。もしプリエンプションが有効な場合、そのDaemonSetコントローラーはPodの優先順位とプリエンプションを考慮することなくスケジューリングの判断を行います。 -`ScheduleDaemonSetPods`は、DaemonSetのPodに対して`NodeAffinity`項目を追加することにより、DaemonSetコントローラーの代わりにデフォルトスケジューラーを使ってDaemonSetのスケジュールを可能にします。その際に、デフォルトスケジューラーはPodをターゲットのホストにバインドします。もしDaemonSetのNodeAffinityが存在するとき、それは新しいものに置き換えられます。DaemonSetコントローラーはDaemonSetのPodの作成や修正を行うときのみそれらの操作を実施します。そしてDaemonSetの`.spec.template`フィールドに対しては何も変更が加えられません。 +`ScheduleDaemonSetPods`は、DaemonSetのPodに対して`NodeAffinity`項目を追加することにより、DaemonSetコントローラーの代わりにデフォルトスケジューラーを使ってDaemonSetのスケジュールを可能にします。その際に、デフォルトスケジューラーはPodをターゲットのホストにバインドします。もしDaemonSetのNodeAffinityが存在するとき、それは新しいものに置き換えられます(ターゲットホストを選択する前に、元のNodeAffinityが考慮されます)。DaemonSetコントローラーはDaemonSetのPodの作成や修正を行うときのみそれらの操作を実施します。そしてDaemonSetの`.spec.template`フィールドに対しては何も変更が加えられません。 ```yaml nodeAffinity: @@ -111,17 +107,16 @@ nodeAffinity: ### TaintsとTolerations -DaemonSetのPodは[TaintsとTolerations](/docs/concepts/configuration/taint-and-toleration)の設定を尊重します。 -下記のTolerationsは、関連する機能によって自動的にDaemonSetのPodに追加されます。 +DaemonSetのPodは[TaintsとTolerations](/docs/concepts/scheduling-eviction/taint-and-toleration/)の設定を尊重します。下記のTolerationsは、関連する機能によって自動的にDaemonSetのPodに追加されます。 -| Toleration Key | Effect | Version | Description | -| ---------------------------------------- | ---------- | ------- | ------------------------------------------------------------ | -| `node.kubernetes.io/not-ready` | NoExecute | 1.13+ | DaemonSetのPodはネットワーク分割のようなNodeの問題が発生したときに除外されません。| -| `node.kubernetes.io/unreachable` | NoExecute | 1.13+ | DaemonSetのPodはネットワーク分割のようなNodeの問題が発生したときに除外されません。| -| `node.kubernetes.io/disk-pressure` | NoSchedule | 1.8+ | | -| `node.kubernetes.io/memory-pressure` | NoSchedule | 1.8+ | | -| `node.kubernetes.io/unschedulable` | NoSchedule | 1.12+ | DaemonSetのPodはデフォルトスケジューラーによってスケジュール不可能な属性を許容(tolerate)します。 | -| `node.kubernetes.io/network-unavailable` | NoSchedule | 1.12+ | ホストネットワークを使うDaemonSetのPodはデフォルトスケジューラーによってネットワーク利用不可能な属性を許容(tolerate)します。 +| Toleration Key | Effect | Version | Description | +| ---------------------------------------- | ---------- | ------- | ----------- | +| `node.kubernetes.io/not-ready` | NoExecute | 1.13+ | DaemonSetのPodはネットワーク分割のようなNodeの問題が発生したときに除外されません。| +| `node.kubernetes.io/unreachable` | NoExecute | 1.13+ | DaemonSetのPodはネットワーク分割のようなNodeの問題が発生したときに除外されません。| +| `node.kubernetes.io/disk-pressure` | NoSchedule | 1.8+ | | +| `node.kubernetes.io/memory-pressure` | NoSchedule | 1.8+ | | +| `node.kubernetes.io/unschedulable` | NoSchedule | 1.12+ | DaemonSetのPodはデフォルトスケジューラーによってスケジュール不可能な属性を許容(tolerate)します。 | +| `node.kubernetes.io/network-unavailable` | NoSchedule | 1.12+ | ホストネットワークを使うDaemonSetのPodはデフォルトスケジューラーによってネットワーク利用不可能な属性を許容(tolerate)します。 | ## Daemon Podとのコミュニケーション @@ -158,8 +153,7 @@ Node上で直接起動することにより(例: `init`、`upstartd`、`systemd` ### 静的Pod Pods -Kubeletによって監視されているディレクトリに対してファイルを書き込むことによって、Podを作成することが可能です。これは[静的Pod](/docs/concepts/cluster-administration/static-pod/)と呼ばれます。 -DaemonSetと違い、静的Podはkubectlや他のKubernetes APIクライアントで管理できません。静的PodはApiServerに依存しておらず、クラスターの自立起動時に最適です。また、静的Podは将来的には廃止される予定です。 +Kubeletによって監視されているディレクトリに対してファイルを書き込むことによって、Podを作成することが可能です。これは[静的Pod](/docs/tasks/configure-pod-container/static-pod/)と呼ばれます。DaemonSetと違い、静的Podはkubectlや他のKubernetes APIクライアントで管理できません。静的PodはApiServerに依存しておらず、クラスターの自立起動時に最適です。また、静的Podは将来的には廃止される予定です。 ### Deployment From 372bcd7b72b4b15e8e4f663d4ab05f97556612dc Mon Sep 17 00:00:00 2001 From: Jin Hase Date: Tue, 8 Sep 2020 12:49:41 +0900 Subject: [PATCH 075/252] Update content/ja/docs/concepts/workloads/controllers/daemonset.md Co-authored-by: Naoki Oketani --- content/ja/docs/concepts/workloads/controllers/daemonset.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/workloads/controllers/daemonset.md b/content/ja/docs/concepts/workloads/controllers/daemonset.md index d6df9e2f83..7787871650 100644 --- a/content/ja/docs/concepts/workloads/controllers/daemonset.md +++ b/content/ja/docs/concepts/workloads/controllers/daemonset.md @@ -49,7 +49,7 @@ DaemonSetオブジェクトの名前は、有効な `.spec.template`は`.spec`内での必須のフィールドの1つです。 -`.spec.template`は[Podテンプレート](/ja/docs/concepts/workloads/pods/#podテンプレート)となります。これはフィールドがネストされていて、`apiVersion`や`kind`をもたないことを除いては、{{< glossary_tooltip text="Pod" term_id="pod" >}}のテンプレートと同じスキーマとなります。 +`.spec.template`は[Podテンプレート](/docs/concepts/workloads/pods/#pod-templates)となります。これはフィールドがネストされていて、`apiVersion`や`kind`をもたないことを除いては、{{< glossary_tooltip text="Pod" term_id="pod" >}}のテンプレートと同じスキーマとなります。 Podに対する必須のフィールドに加えて、DaemonSet内のPodテンプレートは適切なラベルを指定しなくてはなりません([Podセレクター](#pod-selector)の項目を参照ください)。 @@ -162,4 +162,3 @@ DaemonSetは、Podの作成し、そのPodが停止されることのないプ フロントエンドのようなServiceのように、どのホスト上にPodが稼働するか制御するよりも、レプリカ数をスケールアップまたはスケールダウンしたりローリングアップデートする方が重要であるような、状態をもたないServiceに対してDeploymentを使ってください。 Podのコピーが全てまたは特定のホスト上で常に稼働していることが重要な場合や、他のPodの前に起動させる必要があるときにDaemonSetを使ってください。 - From 427a7e8782752cc682d26b21c64524cb8be910cf Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Mon, 7 Sep 2020 13:03:48 +0900 Subject: [PATCH 076/252] Update ja/docs/reference/glossary/control-plane.md --- content/ja/docs/reference/glossary/control-plane.md | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/content/ja/docs/reference/glossary/control-plane.md b/content/ja/docs/reference/glossary/control-plane.md index 1153d68db8..b1d30ae76c 100644 --- a/content/ja/docs/reference/glossary/control-plane.md +++ b/content/ja/docs/reference/glossary/control-plane.md @@ -11,3 +11,15 @@ tags: - fundamental --- コンテナのライフサイクルを定義、展開、管理するためのAPIとインターフェイスを公開するコンテナオーケストレーションレイヤーです。 + + + + このレイヤーは、次のような多くの異なるコンポーネントから構成されます。（しかし、これらに限定はされません） + + * {{< glossary_tooltip text="etcd" term_id="etcd" >}} + * {{< glossary_tooltip text="API Server" term_id="kube-apiserver" >}} + * {{< glossary_tooltip text="Scheduler" term_id="kube-scheduler" >}} + * {{< glossary_tooltip text="Controller Manager" term_id="kube-controller-manager" >}} + * {{< glossary_tooltip text="Cloud Controller Manager" term_id="cloud-controller-manager" >}} + + これらのコンポーネントは従来のオペレーティングシステムサービス（デーモン）もしくはコンテナとして実行できます。これらのコンポーネントを実行するホストは歴史的に{{< glossary_tooltip text="マスター" term_id="master" >}}と呼ばれていました。 From 4e87c9e701a46d477829b68bcfd3fdbc42eb01cf Mon Sep 17 00:00:00 2001 From: yu-kasuya Date: Wed, 9 Sep 2020 12:03:22 +0900 Subject: [PATCH 077/252] Apply suggestions from code review Co-authored-by: Naoki Oketani --- content/ja/docs/reference/glossary/control-plane.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/reference/glossary/control-plane.md b/content/ja/docs/reference/glossary/control-plane.md index b1d30ae76c..46796ef8d0 100644 --- a/content/ja/docs/reference/glossary/control-plane.md +++ b/content/ja/docs/reference/glossary/control-plane.md @@ -14,7 +14,7 @@ tags: - このレイヤーは、次のような多くの異なるコンポーネントから構成されます。（しかし、これらに限定はされません） + このレイヤーは、次のような多くの異なるコンポーネントから構成されます(しかし、これらに限定はされません)。 * {{< glossary_tooltip text="etcd" term_id="etcd" >}} * {{< glossary_tooltip text="API Server" term_id="kube-apiserver" >}} @@ -22,4 +22,4 @@ tags: * {{< glossary_tooltip text="Controller Manager" term_id="kube-controller-manager" >}} * {{< glossary_tooltip text="Cloud Controller Manager" term_id="cloud-controller-manager" >}} - これらのコンポーネントは従来のオペレーティングシステムサービス（デーモン）もしくはコンテナとして実行できます。これらのコンポーネントを実行するホストは歴史的に{{< glossary_tooltip text="マスター" term_id="master" >}}と呼ばれていました。 + これらのコンポーネントは従来のオペレーティングシステムサービス(デーモン)もしくはコンテナとして実行できます。これらのコンポーネントを実行するホストは歴史的に{{< glossary_tooltip text="マスター" term_id="master" >}}と呼ばれていました。 From 530a85cbe2c22ec5f5dce2c6896e1372075b328d Mon Sep 17 00:00:00 2001 From: yu-kasuya Date: Wed, 9 Sep 2020 12:51:19 +0900 Subject: [PATCH 078/252] Apply suggestions from code review Co-authored-by: Naoki Oketani --- content/ja/docs/reference/glossary/control-plane.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/ja/docs/reference/glossary/control-plane.md b/content/ja/docs/reference/glossary/control-plane.md index 46796ef8d0..00fd3ab3e3 100644 --- a/content/ja/docs/reference/glossary/control-plane.md +++ b/content/ja/docs/reference/glossary/control-plane.md @@ -17,9 +17,9 @@ tags: このレイヤーは、次のような多くの異なるコンポーネントから構成されます(しかし、これらに限定はされません)。 * {{< glossary_tooltip text="etcd" term_id="etcd" >}} - * {{< glossary_tooltip text="API Server" term_id="kube-apiserver" >}} - * {{< glossary_tooltip text="Scheduler" term_id="kube-scheduler" >}} - * {{< glossary_tooltip text="Controller Manager" term_id="kube-controller-manager" >}} - * {{< glossary_tooltip text="Cloud Controller Manager" term_id="cloud-controller-manager" >}} + * {{< glossary_tooltip text="APIサーバー" term_id="kube-apiserver" >}} + * {{< glossary_tooltip text="スケジューラー" term_id="kube-scheduler" >}} + * {{< glossary_tooltip text="コントローラーマネージャー" term_id="kube-controller-manager" >}} + * {{< glossary_tooltip text="クラウドコントローラーマネージャー" term_id="cloud-controller-manager" >}} これらのコンポーネントは従来のオペレーティングシステムサービス(デーモン)もしくはコンテナとして実行できます。これらのコンポーネントを実行するホストは歴史的に{{< glossary_tooltip text="マスター" term_id="master" >}}と呼ばれていました。 From 7df4ce95e0daa2da028599ea0c02021c37851da2 Mon Sep 17 00:00:00 2001 From: Jin Hase Date: Mon, 31 Aug 2020 22:42:51 +0900 Subject: [PATCH 079/252] Update Japanese localization on tasks/administer-cluster/running-cloud-controller.md --- .../running-cloud-controller.md | 25 +++++++------------ 1 file changed, 9 insertions(+), 16 deletions(-) diff --git a/content/ja/docs/tasks/administer-cluster/running-cloud-controller.md b/content/ja/docs/tasks/administer-cluster/running-cloud-controller.md index 9a06821517..3ef031b252 100644 --- a/content/ja/docs/tasks/administer-cluster/running-cloud-controller.md +++ b/content/ja/docs/tasks/administer-cluster/running-cloud-controller.md @@ -1,15 +1,15 @@ --- -title: Kubernetesクラウドコントローラーマネージャー +title: クラウドコントローラーマネージャー運用 content_type: concept --- -{{< feature-state state="beta" >}} +{{< feature-state state="beta" for_k8s_version="v1.11" >}} -Kubernetes v1.6では`cloud-controller-manager`という新しいバイナリが導入されました。`cloud-controller-manager`はクラウド固有の制御ループを組み込むデーモンです。これらのクラウド固有の制御ループはもともと`kube-controller-manager`にありました。クラウドプロバイダーはKubernetesプロジェクトとは異なるペースで開発およびリリースされるため、プロバイダー固有のコードを`cloud-controller-manager`バイナリに抽象化することでクラウドベンダーはKubernetesのコアのコードとは独立して開発が可能となりました。 +クラウドプロバイダーはKubernetesプロジェクトとは異なるペースで開発およびリリースされるため、プロバイダー固有のコードを{{< glossary_tooltip text="`cloud-controller-manager`" term_id="cloud-controller-manager" >}}バイナリに抽象化することでクラウドベンダーはKubernetesのコアのコードとは独立して開発が可能となりました。 -`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のコアプロジェクトの外で開発される予定です。 +`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のコアから移行することが期待されています。 @@ -38,7 +38,7 @@ cloud-controller-managerを正常に実行するにはクラスター構成に * `--cloud-provider=external`を指定したkubeletは、初期化時に`NoSchedule`の`node.cloudprovider.kubernetes.io/uninitialized`汚染を追加します。これによりノードは作業をスケジュールする前に外部のコントローラーからの2回目の初期化が必要であるとマークされます。クラウドコントローラーマネージャーが使用できない場合クラスター内の新しいノードはスケジュールできないままになることに注意してください。スケジューラーはリージョンやタイプ(高CPU、GPU、高メモリ、スポットインスタンスなど)などのノードに関するクラウド固有の情報を必要とする場合があるためこの汚染は重要です。 * クラスター内のノードに関するクラウド情報はローカルメタデータを使用して取得されなくなりましたが、代わりにノード情報を取得するためのすべてのAPI呼び出しはクラウドコントローラーマネージャーを経由して行われるようになります。これはセキュリティを向上させるためにkubeletでクラウドAPIへのアクセスを制限できることを意味します。大規模なクラスターではクラスター内からクラウドのほとんどすべてのAPI呼び出しを行うため、クラウドコントローラーマネージャーがレートリミットに達するかどうかを検討する必要があります。 -v1.8の時点でクラウドコントローラーマネージャーは以下を実装できます。 +クラウドコントローラーマネージャーは以下を実装できます。 * ノードコントローラー - クラウドAPIを使用してkubernetesノードを更新し、クラウドで削除されたkubernetesノードを削除します。 * サービスコントローラー - タイプLoadBalancerのサービスに対応してクラウド上のロードバランサーを操作します。 @@ -52,12 +52,6 @@ v1.8の時点でクラウドコントローラーマネージャーは以下を Kubernetesのコアリポジトリにないクラウドコントローラーマネージャーの場合、クラウドベンダーまたはsigリードが管理するリポジトリでプロジェクトを見つけることができます。 -* [DigitalOcean](https://github.com/digitalocean/digitalocean-cloud-controller-manager) -* [keepalived](https://github.com/munnerz/keepalived-cloud-provider) -* [Oracle Cloud Infrastructure](https://github.com/oracle/oci-cloud-controller-manager) -* [Rancher](https://github.com/rancher/rancher-cloud-controller-manager) - - すでにKubernetesのコアリポジトリにあるプロバイダーの場合、クラスター内でデーモンセットとしてKubernetesリポジトリ内部のクラウドコントローラーマネージャーを実行できます。以下をガイドラインとして使用してください。 {{< codenew file="admin/cloud/ccm-example.yaml" >}} @@ -73,18 +67,17 @@ Kubernetesのコアリポジトリにないクラウドコントローラーマ ### スケーラビリティ -クラウドプロバイダーの以前のアーキテクチャではローカルメタデータサービスを使用して自身のノード情報を取得するkubeletに依存していました。新しいアーキテクチャではクラウドコントローラーマネージャーがすべてのノードの情報を取得します。非常に大きなクラスターの場合、リソース要件やAPIレートリミットなどのボトルネックの可能性を考慮する必要があります。 +cloud-controller-managerは、クラウドプロバイダーのAPIにクエリを送信して、すべてのノードの情報を取得します。非常に大きなクラスターの場合、リソース要件やAPIレートリミットなどのボトルネックの可能性を考慮する必要があります。 ### 鶏と卵 クラウドコントローラーマネージャープロジェクトの目標はKubernetesのコアプロジェクトからクラウドに関する機能の開発を切り離すことです。残念ながら、Kubernetesプロジェクトの多くの面でクラウドプロバイダーの機能がKubernetesプロジェクトに緊密に結びついているという前提があります。そのため、この新しいアーキテクチャを採用するとクラウドプロバイダーの情報を要求する状況が発生する可能性がありますが、クラウドコントローラーマネージャーはクラウドプロバイダーへのリクエストが完了するまでその情報を返すことができない場合があります。 -これの良い例は、KubeletのTLSブートストラップ機能です。現在、TLSブートストラップはKubeletがすべてのアドレスタイプ(プライベート、パブリックなど)をクラウドプロバイダー(またはローカルメタデータサービス)に要求する能力を持っていると仮定していますが、クラウドコントローラーマネージャーは最初に初期化されない限りノードのアドレスタイプを設定できないためapiserverと通信するためにはkubeletにTLS証明書が必要です。 +これの良い例は、KubeletのTLSブートストラップ機能です。TLSブートストラップはKubeletがすべてのアドレスタイプ(プライベート、パブリックなど)をクラウドプロバイダー(またはローカルメタデータサービス)に要求する能力を持っていると仮定していますが、クラウドコントローラーマネージャーは最初に初期化されない限りノードのアドレスタイプを設定できないためapiserverと通信するためにはkubeletにTLS証明書が必要です。 このイニシアチブが成熟するに連れ、今後のリリースでこれらの問題に対処するための変更が行われます。 -## 独自のクラウドコントローラマネージャーを開発する - -独自のクラウドコントローラーマネージャーを構築および開発するには[クラウドコントローラーマネージャーの開発](/docs/tasks/administer-cluster/developing-cloud-controller-manager.md)のドキュメントを参照してください。 +## {{% heading "whatsnext" %}} +独自のクラウドコントローラーマネージャーを構築および開発するには[クラウドコントローラーマネージャーの開発](/docs/tasks/administer-cluster/developing-cloud-controller-manager.md)を参照してください。 From f7517161e33e0be78cf0a4b120e19c84ac1a0e4a Mon Sep 17 00:00:00 2001 From: Jin Hase Date: Tue, 8 Sep 2020 12:45:37 +0900 Subject: [PATCH 080/252] Update content/ja/docs/tasks/administer-cluster/running-cloud-controller.md Co-authored-by: inductor(Kohei) --- .../docs/tasks/administer-cluster/running-cloud-controller.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/ja/docs/tasks/administer-cluster/running-cloud-controller.md b/content/ja/docs/tasks/administer-cluster/running-cloud-controller.md index 3ef031b252..a32b6acc86 100644 --- a/content/ja/docs/tasks/administer-cluster/running-cloud-controller.md +++ b/content/ja/docs/tasks/administer-cluster/running-cloud-controller.md @@ -1,5 +1,5 @@ --- -title: クラウドコントローラーマネージャー運用 +title: クラウドコントローラーマネージャーの運用管理 content_type: concept --- @@ -80,4 +80,3 @@ cloud-controller-managerは、クラウドプロバイダーのAPIにクエリ ## {{% heading "whatsnext" %}} 独自のクラウドコントローラーマネージャーを構築および開発するには[クラウドコントローラーマネージャーの開発](/docs/tasks/administer-cluster/developing-cloud-controller-manager.md)を参照してください。 - From a2e11b741fb615afe47c77ae04307aa07f0ea849 Mon Sep 17 00:00:00 2001 From: Jin Hase Date: Tue, 8 Sep 2020 12:46:16 +0900 Subject: [PATCH 081/252] Update content/ja/docs/tasks/administer-cluster/running-cloud-controller.md Co-authored-by: nasa9084 --- .../docs/tasks/administer-cluster/running-cloud-controller.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/administer-cluster/running-cloud-controller.md b/content/ja/docs/tasks/administer-cluster/running-cloud-controller.md index a32b6acc86..04dfd62f8b 100644 --- a/content/ja/docs/tasks/administer-cluster/running-cloud-controller.md +++ b/content/ja/docs/tasks/administer-cluster/running-cloud-controller.md @@ -67,7 +67,7 @@ Kubernetesのコアリポジトリにないクラウドコントローラーマ ### スケーラビリティ -cloud-controller-managerは、クラウドプロバイダーのAPIにクエリを送信して、すべてのノードの情報を取得します。非常に大きなクラスターの場合、リソース要件やAPIレートリミットなどのボトルネックの可能性を考慮する必要があります。 +cloud-controller-managerは、クラウドプロバイダーのAPIにクエリーを送信して、すべてのノードの情報を取得します。非常に大きなクラスターの場合、リソース要件やAPIレートリミットなどのボトルネックの可能性を考慮する必要があります。 ### 鶏と卵 From 320648440e2af578f3e60c071da4bd98e40bc0a5 Mon Sep 17 00:00:00 2001 From: Jin Hase Date: Fri, 11 Sep 2020 17:33:58 +0900 Subject: [PATCH 082/252] Update Japanese localization on tutorials/stateful-application/mysql-wordpress-persistent-volume.md --- .../stateful-application/mysql-wordpress-persistent-volume.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md b/content/ja/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md index 7aed33777e..5e7b77443d 100644 --- a/content/ja/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md +++ b/content/ja/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md @@ -188,8 +188,8 @@ kubectl apply -k ./ 結果は次のようになるはずです。 ``` - NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE - wordpress ClusterIP 10.0.0.89 80:32406/TCP 4m + NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE + wordpress LoadBalancer 10.0.0.89 80:32406/TCP 4m ``` {{< note >}} From e5e8415840199a3a5844f9388b2c07f266e1b71a Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Sat, 12 Sep 2020 20:14:14 +0900 Subject: [PATCH 083/252] update links --- .../api-extension/apiserver-aggregation.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md b/content/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md index 3a14aab62c..50593a61b8 100644 --- a/content/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md +++ b/content/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md @@ -32,9 +32,9 @@ kube-apiserverとの間を5秒以内に往復するためには、ディスカ ## {{% 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/)方法を学んで下さい +* アグリゲーターをあなたの環境で動かすには、まず[アグリゲーションレイヤーを設定](/docs/tasks/extend-kubernetes/configure-aggregation-layer/)します +* そして、アグリゲーションレイヤーと一緒に動作させるために[extension api-serverをセットアップ](/docs/tasks/extend-kubernetes/setup-extension-api-server/)します +* また、[Custom Resource Definitionを使いKubernetes APIを拡張する](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)方法を学んで下さい * [APIService](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#apiservice-v1-apiregistration-k8s-io)の仕様をお読み下さい From 32a72991f75945dcf177c3ef3929f2fe38c80069 Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Thu, 10 Sep 2020 22:39:07 +0900 Subject: [PATCH 084/252] Make docs/tasks/configure-pod-container/_index.md follow v1.18 of the original text --- content/ja/docs/tasks/configure-pod-container/_index.md | 1 + 1 file changed, 1 insertion(+) diff --git a/content/ja/docs/tasks/configure-pod-container/_index.md b/content/ja/docs/tasks/configure-pod-container/_index.md index 94b5079fa8..324a19b22b 100755 --- a/content/ja/docs/tasks/configure-pod-container/_index.md +++ b/content/ja/docs/tasks/configure-pod-container/_index.md @@ -1,5 +1,6 @@ --- title: "Podとコンテナの設定" +description: Podとコンテナの一般的な設定のタスクを行います。 weight: 20 --- From 4a50a07a3fb2f83159d47b3f345ab5ef6f3b1b9e Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Thu, 10 Sep 2020 22:28:01 +0900 Subject: [PATCH 085/252] Make docs/tasks/access-application-cluster/_index.md follow v1.18 of the original text --- content/ja/docs/tasks/access-application-cluster/_index.md | 1 + 1 file changed, 1 insertion(+) diff --git a/content/ja/docs/tasks/access-application-cluster/_index.md b/content/ja/docs/tasks/access-application-cluster/_index.md index dda8899f73..dc48e62246 100755 --- a/content/ja/docs/tasks/access-application-cluster/_index.md +++ b/content/ja/docs/tasks/access-application-cluster/_index.md @@ -1,4 +1,5 @@ --- title: "クラスター内アプリケーションへのアクセス" +description: クラスター内アプリケーションへアクセスできるようにするために、ロードバランシングやポートフォワーディングの設定、ファイアウォールやDNS設定のセットアップを行います。 weight: 60 --- From fd31e94f02aa268cf7a6b44dfee196eabc1adb5f Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Tue, 8 Sep 2020 19:10:05 +0900 Subject: [PATCH 086/252] translated what-is-kubernetes.md --- content/ja/docs/concepts/overview/what-is-kubernetes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/overview/what-is-kubernetes.md b/content/ja/docs/concepts/overview/what-is-kubernetes.md index aeaca7940e..d1b792c0da 100644 --- a/content/ja/docs/concepts/overview/what-is-kubernetes.md +++ b/content/ja/docs/concepts/overview/what-is-kubernetes.md @@ -71,7 +71,7 @@ Kubernetesは、パスワードやOAuthトークン、SSHキーのよう機密 ## Kubernetesにないもの -Kubernetesは、従来型の全部入りなPaaS(Platform as a Service)のシステムではありません。Kubernetesはハードウェアレベルではなく、コンテナレベルで動作するため、デプロイ、スケーリング、負荷分散、ロギングやモニタリングといったPasSが提供するのと共通の機能をいくつか提供しています。また一方、Kubernetesはモノリシックでなく、標準のソリューションは選択が自由で、追加と削除が容易な構成になっています。Kubernetesは開発プラットフォーム構築のためにビルディングブロックを提供しますが、重要な部分はユーザーの選択と柔軟性を維持しています。 +Kubernetesは、従来型の全部入りなPaaS(Platform as a Service)のシステムではありません。Kubernetesはハードウェアレベルではなく、コンテナレベルで動作するため、デプロイ、スケーリング、負荷分散といったPaaSが提供するのと共通の機能をいくつか提供し、またユーザーはロギングやモニタリング及びアラートを行うソリューションを統合できます。また一方、Kubernetesはモノリシックでなく、標準のソリューションは選択が自由で、追加と削除が容易な構成になっています。Kubernetesは開発プラットフォーム構築のためにビルディングブロックを提供しますが、重要な部分はユーザーの選択と柔軟性を維持しています。 Kubernetesは... From 866fe31acb3b19a4af7e2ca73b80a01cc0b40ab2 Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Thu, 10 Sep 2020 22:17:49 +0900 Subject: [PATCH 087/252] Make docs/tasks/_index.md follow v1.18 of the original text --- content/ja/docs/tasks/_index.md | 78 +-------------------------------- 1 file changed, 2 insertions(+), 76 deletions(-) diff --git a/content/ja/docs/tasks/_index.md b/content/ja/docs/tasks/_index.md index 758500260b..6352ae67b1 100644 --- a/content/ja/docs/tasks/_index.md +++ b/content/ja/docs/tasks/_index.md @@ -5,82 +5,8 @@ weight: 50 content_type: concept --- -{{< toc >}} - -Kubernetesドキュメントのこのセクションには、個々のタスクの実行方法を示すページが含まれています。 -タスクページは、通常、短い手順を実行することにより、1つのことを行う方法を示します。 - - - - - -## Web UI (ダッシュボード) - -ダッシュボードWeb UIを展開してアクセスし、Kubernetesクラスター内のコンテナ化されたアプリケーションの管理と監視に役立てます。 - -## kubectlコマンドラインツールの使用 - -Kubernetesクラスターを直接管理するために使用される`kubectl`コマンドラインツールをインストールしてセットアップします。 - -## Podとコンテナの設定 - -Podとコンテナの一般的な設定タスクを実行します。 - -## アプリケーションの実行 - -ローリングアップデート、Podへの情報の注入、水平Podオートスケーリングなど、一般的なアプリケーション管理タスクを実行します。 - -## ジョブの実行 - -並列処理を使用してジョブを実行します。 - -## クラスター内のアプリケーションへのアクセス - -クラスター内のアプリケーションにアクセスするために、負荷分散、ポート転送を設定するか、ファイアウォールまたはDNSの設定をセットアップします。 - -## 監視、ログ、デバッグ - -クラスタのトラブルシューティングまたはコンテナ化されたアプリケーションのデバッグのために、監視とログを設定します。 - -## Kubernetes APIへのアクセス - -Kubernetes APIに直接アクセスするためのさまざまな方法を学びます。 - -## TLSの使用 - -クラスタールート認証局(CA)を信頼して使用するようにアプリケーションを設定します。 - -## クラスターの管理 - -クラスターを管理するための一般的なタスクを学びます。 - -## フェデレーションの管理 - -クラスタフェデレーションのコンポーネントを設定します。 - -## ステートフルなアプリケーションの管理 - -StatefulSetのスケーリング、削除、デバッグなど、ステートフルなアプリケーションを管理するための一般的なタスクを実行します。 - -## クラスターデーモン - -ローリングアップデートの実行など、DaemonSetを管理するための一般的なタスクを実行します。 - -## GPUの管理 - -クラスター内のノードがリソースとして使用するNVIDIA GPUを設定およびスケジュールします。 - -## Huge Pageの管理 - -クラスター内のスケジュール可能なリソースとしてHuge Pageを構成およびスケジュールします。 - - - -## {{% heading "whatsnext" %}} - - -タスクページを作成する場合は、[ドキュメントのPull Requestの作成](/docs/home/contribute/create-pull-request/)を参照してください。 - +Kubernetesドキュメントのこのセクションには、個々のタスクの実行方法を示すページが含まれています。タスクページは、通常、短い手順を実行することにより、1つのことを行う方法を示します。 +タスクページを作成したい場合は、[ドキュメントのPull Requestの作成](/docs/home/contribute/create-pull-request/)を参照してください。 From 037e108865fe2089fd4a1483780b8799074164ee Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Sun, 13 Sep 2020 19:17:05 +0900 Subject: [PATCH 088/252] Update the link Co-authored-by: Naoki Oketani --- content/ja/docs/tasks/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/_index.md b/content/ja/docs/tasks/_index.md index 6352ae67b1..b90950aea8 100644 --- a/content/ja/docs/tasks/_index.md +++ b/content/ja/docs/tasks/_index.md @@ -9,4 +9,4 @@ content_type: concept Kubernetesドキュメントのこのセクションには、個々のタスクの実行方法を示すページが含まれています。タスクページは、通常、短い手順を実行することにより、1つのことを行う方法を示します。 -タスクページを作成したい場合は、[ドキュメントのPull Requestの作成](/docs/home/contribute/create-pull-request/)を参照してください。 +タスクページを作成したい場合は、[ドキュメントのPull Requestの作成](/docs/contribute/new-content/open-a-pr/)を参照してください。 From 65612f2c68e9f4d605c29cc52235e5d06ad9ad11 Mon Sep 17 00:00:00 2001 From: Takaaki Fujii Date: Tue, 1 Sep 2020 00:17:07 +0900 Subject: [PATCH 089/252] finish translate --- content/ja/docs/concepts/containers/_index.md | 31 ++++++++++++++++++- 1 file changed, 30 insertions(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/containers/_index.md b/content/ja/docs/concepts/containers/_index.md index 3e1c30f9b8..af34967521 100755 --- a/content/ja/docs/concepts/containers/_index.md +++ b/content/ja/docs/concepts/containers/_index.md @@ -1,4 +1,33 @@ --- -title: "コンテナ" +title: コンテナ weight: 40 +description: アプリケーションと依存関係のあるランタイムを一緒にパッケージ化するための技術 +reviewers: +content_type: concept +no_list: true --- + + + +実行するそれぞれのコンテナは繰り返し使用可能で、依存関係を含めた形式で規格化されていることは、どこで実行しても同じ動作が得られることを意味しています。 + +コンテナは基盤となるホストインフラからアプリケーションを切り離します。これにより、さまざまなクラウドやOS環境下でのデプロイが容易になります。 + + + + + + +## コンテナイメージ +[コンテナイメージ](/docs/concepts/containers/images/)はすぐに実行可能なソフトウェアパッケージで、アプリケーションの実行に必要なものをすべて含んています。コードと必要なランタイム、アプリケーションとシステムのライブラリ、そして必須な設定項目のデフォルト値を含みます。 + +設計上、コンテナは不変で、既に実行中のコンテナのコードを変更することはできません。コンテナ化されたアプリケーションがあり変更したい場合は、変更を含んだ新しいコンテナをビルドし、コンテナを再作成して、更新されたイメージから起動する必要があります。 + +## コンテナランタイム + +{{< glossary_definition term_id="container-runtime" length="all" >}} + +## {{% heading "whatsnext" %}} + +* [コンテナイメージ](/docs/concepts/containers/images/)についてお読みください。 +* [Pod](/ja/docs/concepts/workloads/pods/)についてお読みください。 From f2dd2b515ec6a68bd1ea816866043d5c963c58c6 Mon Sep 17 00:00:00 2001 From: takaf04 Date: Tue, 8 Sep 2020 23:42:07 +0900 Subject: [PATCH 090/252] Update content/ja/docs/concepts/containers/_index.md Co-authored-by: Keita Akutsu --- content/ja/docs/concepts/containers/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/containers/_index.md b/content/ja/docs/concepts/containers/_index.md index af34967521..f64bad4796 100755 --- a/content/ja/docs/concepts/containers/_index.md +++ b/content/ja/docs/concepts/containers/_index.md @@ -1,7 +1,7 @@ --- title: コンテナ weight: 40 -description: アプリケーションと依存関係のあるランタイムを一緒にパッケージ化するための技術 +description: アプリケーションとランタイムの依存関係を一緒にパッケージ化するための技術 reviewers: content_type: concept no_list: true From 7dd5550b0656f9a3c5625528f9ee7361af8f6e49 Mon Sep 17 00:00:00 2001 From: takaf04 Date: Wed, 9 Sep 2020 23:32:30 +0900 Subject: [PATCH 091/252] Update content/ja/docs/concepts/containers/_index.md Co-authored-by: inductor(Kohei) --- content/ja/docs/concepts/containers/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/containers/_index.md b/content/ja/docs/concepts/containers/_index.md index f64bad4796..5b10416c0f 100755 --- a/content/ja/docs/concepts/containers/_index.md +++ b/content/ja/docs/concepts/containers/_index.md @@ -9,7 +9,7 @@ no_list: true -実行するそれぞれのコンテナは繰り返し使用可能で、依存関係を含めた形式で規格化されていることは、どこで実行しても同じ動作が得られることを意味しています。 +実行するそれぞれのコンテナは繰り返し使用可能です。依存関係を含めて標準化されており、どこで実行しても同じ動作が得られることを意味しています。 コンテナは基盤となるホストインフラからアプリケーションを切り離します。これにより、さまざまなクラウドやOS環境下でのデプロイが容易になります。 From 744e475fff71fede4152419c632c8efb3f613e19 Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Wed, 9 Sep 2020 20:08:32 +0900 Subject: [PATCH 092/252] translated common-labels.md --- .../concepts/overview/working-with-objects/common-labels.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/overview/working-with-objects/common-labels.md b/content/ja/docs/concepts/overview/working-with-objects/common-labels.md index 9212de948e..ee7e88eccd 100644 --- a/content/ja/docs/concepts/overview/working-with-objects/common-labels.md +++ b/content/ja/docs/concepts/overview/working-with-objects/common-labels.md @@ -26,7 +26,7 @@ content_type: concept | キー | 説明 | 例 | 型 | | ----------------------------------- | --------------------- | -------- | ---- | | `app.kubernetes.io/name` | アプリケーション名 | `mysql` | 文字列 | -| `app.kubernetes.io/instance` | アプリケーションのインスタンスを特定するための固有名 | `wordpress-abcxzy` | 文字列 | +| `app.kubernetes.io/instance` | アプリケーションのインスタンスを特定するための固有名 | `mysql-abcxzy` | 文字列 | | `app.kubernetes.io/version` | アプリケーションの現在のバージョン (例: セマンティックバージョン、リビジョンのハッシュなど) | `5.7.21` | 文字列 | | `app.kubernetes.io/component` | アーキテクチャ内のコンポーネント | `database` | 文字列 | | `app.kubernetes.io/part-of` | このアプリケーションによって構成される上位レベルのアプリケーション | `wordpress` | 文字列 | @@ -40,7 +40,7 @@ kind: StatefulSet metadata: labels: app.kubernetes.io/name: mysql - app.kubernetes.io/instance: wordpress-abcxzy + app.kubernetes.io/instance: mysql-abcxzy app.kubernetes.io/version: "5.7.21" app.kubernetes.io/component: database app.kubernetes.io/part-of: wordpress From 1bafdfee0344f645c227057a0808f9de33de109f Mon Sep 17 00:00:00 2001 From: arisgi Date: Sun, 13 Sep 2020 23:54:17 +0900 Subject: [PATCH 093/252] Translate docs/concepts/configuration/overview.md into Japanese --- content/ja/docs/concepts/configuration/overview.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/ja/docs/concepts/configuration/overview.md b/content/ja/docs/concepts/configuration/overview.md index 2a5dfc4a51..14304bbc71 100644 --- a/content/ja/docs/concepts/configuration/overview.md +++ b/content/ja/docs/concepts/configuration/overview.md @@ -31,7 +31,7 @@ weight: 10 - 可能な限り、"真っ裸"のPod([ReplicaSet](/ja/docs/concepts/workloads/controllers/replicaset/)や[Deployment](/ja/docs/concepts/workloads/controllers/deployment/)にバインドされていないPod)は使わないでください。Nodeに障害が発生した場合、これらのPodは再スケジュールされません。 - 明示的に[`restartPolicy: Never`](/ja/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)を使いたいシーンを除いて、DeploymentはPodを直接作成するよりもほとんど常に望ましい方法です。Deploymentには、希望する数のPodが常に使用可能であることを確認するためにReplicaSetを作成したり、Podを置き換えるための戦略(RollingUpdateなど)を指定したりできます。[Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/)のほうが適切な場合もあるかもしれません。 + 明示的に[`restartPolicy: Never`](/ja/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)を使いたいシーンを除いて、DeploymentはPodを直接作成するよりもほとんど常に望ましい方法です。Deploymentには、希望する数のPodが常に使用可能であることを確認するためにReplicaSetを作成したり、Podを置き換えるための戦略(RollingUpdateなど)を指定したりできます。[Job](/docs/concepts/workloads/controllers/job/)のほうが適切な場合もあるかもしれません。 ## Service @@ -68,11 +68,11 @@ weight: 10 ## コンテナイメージ -[imagePullPolicy](/docs/concepts/containers/images/#updating-images)とイメージのタグは、[kubelet](/docs/admin/kubelet/)が特定のイメージをpullしようとしたときに作用します。 +[imagePullPolicy](/docs/concepts/containers/images/#updating-images)とイメージのタグは、[kubelet](/docs/reference/command-line-tools-reference/kubelet/)が特定のイメージをpullしようとしたときに作用します。 - `imagePullPolicy: IfNotPresent`: ローカルでイメージが見つからない場合にのみイメージをpullします。 -- `imagePullPolicy: Always`: Podの起動時に常にイメージをpullします。 +- `imagePullPolicy: Always`: kubeletがコンテナを起動する度に、kubeletはコンテナイメージレジストリに問い合わせて、イメージのダイジェストの名前解決を行います。もし、kubeletが同じダイジェストのコンテナイメージをローカルにキャッシュしていたら、kubeletはそのキャッシュされたイメージを利用します。そうでなければ、kubeletは解決されたダイジェストのイメージをダウンロードし、そのイメージを利用してコンテナを起動します。 - `imagePullPolicy` のタグが省略されていて、利用してるイメージのタグが`:latest`の場合や省略されている場合、`Always`が適用されます。 @@ -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)のセクションを参照してください。 - +- 単一コンテナのDeploymentやServiceを素早く作成するなら、`kubectl create deployment` や `kubectl expose` を使いましょう。一例として、[Serviceを利用したクラスター内のアプリケーションへのアクセス](/docs/tasks/access-application-cluster/service-access-application-cluster/)を参照してください。 From a59e157940e900d99ddd08af70859b72010f6d7f Mon Sep 17 00:00:00 2001 From: arisgi Date: Mon, 14 Sep 2020 01:02:09 +0900 Subject: [PATCH 094/252] Remove unnecessary spaces --- content/ja/docs/concepts/configuration/overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/configuration/overview.md b/content/ja/docs/concepts/configuration/overview.md index 14304bbc71..5f2fd15120 100644 --- a/content/ja/docs/concepts/configuration/overview.md +++ b/content/ja/docs/concepts/configuration/overview.md @@ -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)のセクションを参照してください。 -- 単一コンテナのDeploymentやServiceを素早く作成するなら、`kubectl create deployment` や `kubectl expose` を使いましょう。一例として、[Serviceを利用したクラスター内のアプリケーションへのアクセス](/docs/tasks/access-application-cluster/service-access-application-cluster/)を参照してください。 +- 単一コンテナのDeploymentやServiceを素早く作成するなら、`kubectl create deployment`や`kubectl expose`を使いましょう。一例として、[Serviceを利用したクラスター内のアプリケーションへのアクセス](/docs/tasks/access-application-cluster/service-access-application-cluster/)を参照してください。 From ae96a7aca9b2e8300d287bcd8333b8c129e75766 Mon Sep 17 00:00:00 2001 From: Jin Hase Date: Fri, 21 Aug 2020 11:38:20 +0900 Subject: [PATCH 095/252] Update Japanese localization on concepts/containers/container-lifecycle-hooks.md --- .../ja/docs/concepts/containers/container-lifecycle-hooks.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/containers/container-lifecycle-hooks.md b/content/ja/docs/concepts/containers/container-lifecycle-hooks.md index 13ad6f2578..9f1a94af45 100644 --- a/content/ja/docs/concepts/containers/container-lifecycle-hooks.md +++ b/content/ja/docs/concepts/containers/container-lifecycle-hooks.md @@ -34,7 +34,7 @@ Angularなどのコンポーネントライフサイクルフックを持つ多 これはブロッキング、つまり同期的であるため、コンテナを削除するための呼び出しを送信する前に完了する必要があります。 ハンドラーにパラメーターは渡されません。 -終了動作の詳細な説明は、[Termination of Pods](/ja/docs/concepts/workloads/pods/pod/#termination-of-pods)にあります。 +終了動作の詳細な説明は、[Termination of Pods](/ja/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)にあります。 ### フックハンドラーの実装 From 9297d8dbaa40196e23979bed2097f54897e2e78f Mon Sep 17 00:00:00 2001 From: Jin Hase Date: Tue, 8 Sep 2020 10:31:28 +0900 Subject: [PATCH 096/252] Update content/ja/docs/concepts/containers/container-lifecycle-hooks.md Co-authored-by: Naoki Oketani --- .../ja/docs/concepts/containers/container-lifecycle-hooks.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/containers/container-lifecycle-hooks.md b/content/ja/docs/concepts/containers/container-lifecycle-hooks.md index 9f1a94af45..ba94bd6fab 100644 --- a/content/ja/docs/concepts/containers/container-lifecycle-hooks.md +++ b/content/ja/docs/concepts/containers/container-lifecycle-hooks.md @@ -34,7 +34,7 @@ Angularなどのコンポーネントライフサイクルフックを持つ多 これはブロッキング、つまり同期的であるため、コンテナを削除するための呼び出しを送信する前に完了する必要があります。 ハンドラーにパラメーターは渡されません。 -終了動作の詳細な説明は、[Termination of Pods](/ja/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)にあります。 +終了動作の詳細な説明は、[Termination of Pods](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)にあります。 ### フックハンドラーの実装 @@ -102,4 +102,3 @@ Events: * [コンテナライフサイクルイベントへのハンドラー紐付け](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)のハンズオン - From e21280f19e5b98d6b7324800c174bea8fb8feb21 Mon Sep 17 00:00:00 2001 From: hikkie3110 <3110hikaru326@gmail.com> Date: Mon, 7 Sep 2020 13:20:56 +0900 Subject: [PATCH 097/252] update nodes.md for v1.18 --- .../ja/docs/concepts/architecture/nodes.md | 207 +++++++++++------- 1 file changed, 124 insertions(+), 83 deletions(-) diff --git a/content/ja/docs/concepts/architecture/nodes.md b/content/ja/docs/concepts/architecture/nodes.md index 1c3d47c019..c2f74f9566 100644 --- a/content/ja/docs/concepts/architecture/nodes.md +++ b/content/ja/docs/concepts/architecture/nodes.md @@ -6,27 +6,107 @@ weight: 10 -ノードは、以前には `ミニオン` としても知られていた、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)セクションをご覧ください。 - - +Kubernetesはコンテナをノード上で実行されるPodに配置することで、ワークロードを実行します。 +ノードはクラスターによりますが、1つのVMまたは物理的なマシンです。 +各ノードは{{< glossary_tooltip text="Pod" term_id="pod" >}}やそれを制御する{{< glossary_tooltip text="コントロールプレーン" term_id="control-plane" >}}を実行するのに必要なサービスを含んでいます。 +通常、1つのクラスターで複数のノードを持ちます。学習用途やリソースの制限がある環境では、1ノードかもしれません。 +1つのノード上の[コンポーネント](/ja/docs/concepts/overview/components/#node-components)には、{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}、{{< glossary_tooltip text="コンテナランタイム" term_id="container-runtime" >}}、{{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}が含まれます。 +## 管理 {#management} + +ノードを{{< glossary_tooltip text="APIサーバー" term_id="kube-apiserver" >}}に加えるには2つの方法があります: + +1. ノード上のkubeletが、コントロールプレーンに自己登録する。 +2. あなた、もしくは他のユーザーが手動でNodeオブジェクトを追加する。 + +Nodeオブジェクトの作成、もしくはノード上のkubeketによる自己登録の後、コントロールプレーンはNodeオブジェクトが有効かチェックします。例えば、下記のjsonマニフェストでノードを作成してみましょう。 + +```json +{ + "kind": "Node", + "apiVersion": "v1", + "metadata": { + "name": "10.240.79.157", + "labels": { + "name": "my-first-k8s-node" + } + } +} +``` + +Kubernetesは内部的にNodeオブジェクトを作成します。 APIサーバーに登録したkubeletがノードの`metadata.name`フィールドが一致しているか検証します。ノードが有効な場合、つまり必要なサービスがすべて実行されている場合は、Podを実行する資格があります。それ以外の場合、該当ノードが有効になるまではいかなるクラスターの活動に対しても無視されます。 + +{{< note >}} +Kubernetesは無効なNodeのオブジェクトを保持し、それが有効になるまで検証を続けます。 + +ヘルスチェックを止めるためには、あなた、もしくは{{< glossary_tooltip term_id="controller" text="コントローラー">}}が明示的にNodeを削除する必要があります。 +{{< /note >}} + +Nodeオブジェクトの名前は有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。 + +### ノードの自己登録 {#self-registration-of-nodes} + +kubeletのフラグ `--register-node`がtrue（デフォルト）のとき、kubeletは自分自身をAPIサーバーに登録しようとします。これはほとんどのディストリビューションで使用されている推奨パターンです。 + +自己登録については、kubeletは以下のオプションを伴って起動されます: + + - `--kubeconfig` - 自分自身をAPIサーバーに対して認証するための資格情報へのパス + - `--cloud-provider` - 自身に関するメタデータを読むために{{< glossary_tooltip text="クラウドプロバイダー" term_id="cloud-provider" >}}と会話する方法 + - `--register-node` - 自身をAPIサーバーに自動的に登録 + - `--register-with-taints` - 与えられた{{< glossary_tooltip text="taint" term_id="taint" >}}のリストでノードを登録します (カンマ区切りの `=:`)。 + + `register-node`がfalseの場合、このオプションは機能しません + - `--node-ip` - ノードのIPアドレス + - `--node-labels` - ノードをクラスターに登録するときに追加する{{< glossary_tooltip text="Label" term_id="label" >}}（[NodeRestriction許可プラグイン](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)によって適用されるラベルの制限を参照） + - `--node-status-update-frequency` - kubeletがノードのステータスをマスターにPOSTする頻度の指定 + +[ノード認証モード](/docs/reference/access-authn-authz/node/)および[NodeRestriction許可プラグイン](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)が有効になっている場合、kubeletは自分自身のノードリソースを作成/変更することのみ許可されています。 + +### 手動によるノード管理 {#manual-node-administration} + +クラスター管理者は{{< glossary_tooltip text="kubectl" term_id="kubectl" >}}を使用してNodeオブジェクトを作成および変更できます。 + +管理者が手動でNodeオブジェクトを作成したい場合は、kubeletフラグ `--register-node = false`を設定してください。 + +管理者は`--register-node`の設定に関係なくNodeオブジェクトを変更することができます。 +変更には、ノードにラベルを設定し、それをunschedulableとしてマークすることが含まれます。 + +ノード上のラベルは、スケジューリングを制御するためにPod上のノードセレクタと組み合わせて使用できます。 +例えば、Podをノードのサブセットでのみ実行する資格があるように制限します。 + +ノードをunschedulableとしてマークすると、新しいPodがそのノードにスケジュールされるのを防ぎますが、ノード上の既存のPodには影響しません。 +これは、ノードの再起動などの前の準備ステップとして役立ちます。 + +ノードにスケジュール不可能のマークを付けるには、次のコマンドを実行します: + +```shell +kubectl cordon $ノード名 +``` + +{{< note >}} +{{< glossary_tooltip term_id="daemonset" >}}によって作成されたPodはノード上のunschedulable属性を考慮しません。 +これは、再起動の準備中にアプリケーションからアプリケーションが削除されている場合でも、デーモンセットがマシンに属していることを前提としているためです。 +{{< /note >}} + ## ノードのステータス -ノードのステータスには以下のような情報が含まれます: +ノードのステータスは以下の情報を含みます: * [Addresses](#addresses) * [Conditions](#condition) * [CapacityとAllocatable](#capacity) * [Info](#info) -ノードのステータスや、ノードに関するその他の詳細は、下記のコマンドを使うことで表示できます: +`kubectl`を使用し、ノードのステータスや詳細を確認できます: + ```shell -kubectl describe node <ノード名> +kubectl describe node <ノード名をここに挿入> ``` -各セクションについては、下記で説明します。 + +出力情報の各箇所について、以下で説明します。 ### Addresses @@ -41,15 +121,22 @@ kubectl describe node <ノード名> `conditions`フィールドは全ての`Running`なノードのステータスを表します。例として、以下のような状態を含みます: -| ノードのCondition | 概要 | -|----------------|-------------| -| `Ready` | ノードの状態がHealthyでPodを配置可能な場合に`True`になります。ノードの状態に問題があり、Podが配置できない場合に`False`になります。ノードコントローラーが、`node-monitor-grace-period`で設定された時間内(デフォルトでは40秒)に該当ノードと疎通できない場合、`Unknown`になります。 | -| `MemoryPressure` | ノードのメモリが圧迫されているときに`True`になります。圧迫とは、メモリの空き容量が少ないことを指します。それ以外のときは`False`です。 | -| `PIDPressure` | プロセスが圧迫されているときに`True`になります。圧迫とは、プロセス数が多すぎることを指します。それ以外のときは`False`です。 | -| `DiskPressure` | ノードのディスク容量が圧迫されているときに`True`になります。圧迫とは、ディスクの空き容量が少ないことを指します。それ以外のときは`False`です。 | -| `NetworkUnavailable` | ノードのネットワークが適切に設定されていない場合に`True`になります。それ以外のときは`False`です。 | +{{< table caption = "ノードのConditionと、各condition適用時の概要" >}} +| ノードのCondition | 概要 | +|----------------------|-------------| +| `Ready` | ノードの状態がHealthyでPodを配置可能な場合に`True`になります。ノードの状態に問題があり、Podが配置できない場合に`False`になります。ノードコントローラーが、`node-monitor-grace-period`で設定された時間内(デフォルトでは40秒)に該当ノードと疎通できない場合、`Unknown`になります。 | +| `DiskPressure` | ノードのディスク容量が圧迫されているときに`True`になります。圧迫とは、ディスクの空き容量が少ないことを指します。それ以外のときは`False`です。 | +| `MemoryPressure` | ノードのメモリが圧迫されているときに`True`になります。圧迫とは、メモリの空き容量が少ないことを指します。それ以外のときは`False`です。 | +| `PIDPressure` | プロセスが圧迫されているときに`True`になります。圧迫とは、プロセス数が多すぎることを指します。それ以外のときは`False`です。 | +| `NetworkUnavailable` | ノードのネットワークが適切に設定されていない場合に`True`になります。それ以外のときは`False`です。 | +{{< /table >}} -ノードのConditionはJSONオブジェクトで表現されます。例えば、正常なノードの場合は以下のようなレスポンスが表示されます。 +{{< note >}} +コマンドラインを使用してcordonされたNodeを表示する場合、Conditionは`SchedulingDisabled`を含みます。 +`SchedulingDisabled`はKubernetesのAPIにおけるConditionではありません;その代わり、cordonされたノードはUnschedulableとしてマークされます。 +{{< /note >}} + +ノードのConditionはJSONオブジェクトで表現されます。例えば、正常なノードの場合は以下のような構造体が表示されます。 ```json "conditions": [ @@ -64,14 +151,15 @@ kubectl describe node <ノード名> ] ``` -Ready conditionが`pod-eviction-timeout`に設定された時間を超えても`Unknown`や`False`のままになっている場合、[kube-controller-manager](/docs/admin/kube-controller-manager/)に引数が渡され、該当ノード上にあるPodはノードコントローラーによって削除がスケジュールされます。デフォルトの退役のタイムアウトの時間は**5分**です。ノードが到達不能ないくつかの場合においては、APIサーバーが該当ノードのkubeletと疎通できない状態になっています。その場合、APIサーバーがkubeletと再び通信を確立するまでの間、Podの削除を行うことはできません。削除がスケジュールされるまでの間、削除対象のPodたちは切り離されたノードの上で稼働を続けることになります。 +Ready conditionが`pod-eviction-timeout`({{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}}に渡された引数)に設定された時間を超えても`Unknown`や`False`のままになっている場合、該当ノード上にあるPodはノードコントローラーによって削除がスケジュールされます。デフォルトの退役のタイムアウトの時間は**5分**です。ノードが到達不能ないくつかの場合においては、APIサーバーが該当ノードのkubeletと疎通できない状態になっています。その場合、APIサーバーがkubeletと再び通信を確立するまでの間、Podの削除を行うことはできません。削除がスケジュールされるまでの間、削除対象のPodは切り離されたノードの上で稼働を続けることになります。 -バージョン1.5よりも前のKubernetesでは、ノードコントローラーはAPIサーバーから到達不能なそれらのPodを[強制削除](/ja/docs/concepts/workloads/pods/pod/#podの強制削除)していました。しかしながら、1.5以降では、ノードコントローラーはクラスター内でPodが停止するのを確認するまでは強制的に削除しないようになりました。到達不能なノード上で動いているPodは`Terminating`または`Unknown`のステータスになります。Kubernetesが基盤となるインフラストラクチャーを推定できない場合、クラスター管理者は手動でNodeオブジェクトを削除する必要があります。KubernetesからNodeオブジェクトを削除すると、そのノードで実行されているすべてのPodオブジェクトがAPIサーバーから削除され、それらの名前が解放されます。 - -ノードのライフサイクルコントローラーがconditionを表した[taint](/docs/concepts/configuration/taint-and-toleration/)を自動的に生成します。 +ノードコントローラーはクラスター内でPodが停止するのを確認するまでは強制的に削除しないようになりました。到達不能なノード上で動いているPodは`Terminating`または`Unknown`のステータスになります。Kubernetesが基盤となるインフラストラクチャーを推定できない場合、クラスター管理者は手動でNodeオブジェクトを削除する必要があります。KubernetesからNodeオブジェクトを削除すると、そのノードで実行されているすべてのPodオブジェクトがAPIサーバーから削除され、それらの名前が解放されます。 +ノードのライフサイクルコントローラーがconditionを表した[taint](/ja/docs/concepts/scheduling-eviction/taint-and-toleration/)を自動的に生成します。 スケジューラーがPodをノードに割り当てる際、ノードのtaintを考慮します。Podが許容するtaintは例外です。 +詳細は[条件によるtaintの付与](/ja/docs/concepts/scheduling-eviction/taint-and-toleration/#taint-nodes-by-condition)を参照してください。 + ### CapacityとAllocatable {#capacity} ノードで利用可能なリソース（CPU、メモリ、およびノードでスケジュールできる最大Pod数）について説明します。 @@ -115,7 +203,7 @@ Kubernetesは無効なノードのためにオブジェクトを保存し、そ ### ノードコントローラー -ノードコントローラーは、ノードのさまざまな側面を管理するKubernetesのマスターコンポーネントです。 +ノード{{< glossary_tooltip text="コントローラー" term_id="controller" >}}は、ノードのさまざまな側面を管理するKubernetesのコントロールプレーンコンポーネントです。 ノードコントローラーは、ノードの存続期間中に複数の役割を果たします。1つ目は、ノードが登録されたときにCIDRブロックをノードに割り当てることです（CIDR割り当てがオンになっている場合）。 @@ -140,10 +228,6 @@ kubeletが`NodeStatus`とLeaseオブジェクトの作成および更新を担 #### 信頼性 - -Kubernetes 1.4では、マスターに問題が発生した場合の対処方法を改善するように、ノードコントローラーのロジックをアップデートしています（マスターのネットワークに問題があるため） -バージョン1.4以降、ノードコントローラーは、Podの退役について決定する際に、クラスター内のすべてのノードの状態を調べます。 - ほとんどの場合、排除の速度は1秒あたり`--node-eviction-rate`に設定された数値（デフォルトは秒間0.1）です。つまり、10秒間に1つ以上のPodをノードから追い出すことはありません。 特定のアベイラビリティーゾーン内のノードのステータスが異常になると、ノード排除の挙動が変わります。ノードコントローラーは、ゾーン内のノードの何%が異常（NodeReady条件がConditionUnknownまたはConditionFalseである）であるかを同時に確認します。 @@ -156,51 +240,8 @@ Kubernetes 1.4では、マスターに問題が発生した場合の対処方法 コーナーケースは、すべてのゾーンが完全にUnhealthyである（すなわち、クラスタ内にHealthyなノードがない）場合です。 このような場合、ノードコントローラーはマスター接続に問題があると見なし、接続が回復するまですべての退役を停止します。 -Kubernetes 1.6以降では、ノードコントローラーは、Podがtaintを許容しない場合、 `NoExecute`のtaintを持つノード上で実行されているPodを排除する責務もあります。 -さらに、デフォルトで無効になっているアルファ機能として、ノードコントローラーはノードに到達できない、または準備ができていないなどのノードの問題に対応するtaintを追加する責務があります。 -`NoExecute`のtaint及び上述のアルファ機能に関する詳細は、[こちらのドキュメント](/docs/concepts/configuration/taint-and-toleration/)をご覧ください。 - -バージョン1.8以降、ノードコントローラーに対してノードの状態を表すtaintを作成する責務を持たせることができます。これはバージョン1.8のアルファ機能です。 - -### ノードの自己登録 - -kubeletのフラグ `--register-node`がtrue（デフォルト）のとき、kubeletは自分自身をAPIサーバーに登録しようとします。これはほとんどのディストリビューションで使用されている推奨パターンです。 - -自己登録については、kubeletは以下のオプションを伴って起動されます: - - - `--kubeconfig` - 自分自身をAPIサーバーに対して認証するための資格情報へのパス - - `--cloud-provider` - 自身に関するメタデータを読むためにクラウドプロバイダーと会話する方法 - - `--register-node` - 自身をAPIサーバーに自動的に登録 - - `--register-with-taints` - 与えられたtaintのリストでノードを登録します (カンマ区切りの `=:`). `register-node`がfalseの場合、このオプションは機能しません - - `--node-ip` - ノードのIPアドレス - - `--node-labels` - ノードをクラスターに登録するときに追加するラベル（1.13以降の[NodeRestriction許可プラグイン](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)によって適用されるラベルの制限を参照） - - `--node-status-update-frequency` - kubeletがノードのステータスをマスターにPOSTする頻度の指定 - -[ノード認証モード](/docs/reference/access-authn-authz/node/)および[NodeRestriction許可プラグイン](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)が有効になっている場合、kubeletは自分自身のノードリソースを作成/変更することのみ許可されています。 - -#### 手動によるノード管理 {#manual-node-administration} - -クラスター管理者はNodeオブジェクトを作成および変更できます。 - -管理者が手動でNodeオブジェクトを作成したい場合は、kubeletフラグ `--register-node = false`を設定してください。 - -管理者は`--register-node`の設定に関係なくNodeリソースを変更することができます。 -変更には、ノードにラベルを設定し、それをunschedulableとしてマークすることが含まれます。 - -ノード上のラベルは、スケジューリングを制御するためにPod上のノードセレクタと組み合わせて使用できます。 -例えば、Podをノードのサブセットでのみ実行する資格があるように制限します。 - -ノードをunschedulableとしてマークすると、新しいPodがそのノードにスケジュールされるのを防ぎますが、ノード上の既存のPodには影響しません。 -これは、ノードの再起動などの前の準備ステップとして役立ちます。たとえば、ノードにスケジュール不可能のマークを付けるには、次のコマンドを実行します: - -```shell -kubectl cordon $ノード名 -``` - -{{< note >}} -DaemonSetコントローラーによって作成されたPodはKubernetesスケジューラーをバイパスし、ノード上のunschedulable属性を考慮しません。 -これは、再起動の準備中にアプリケーションからアプリケーションが削除されている場合でも、デーモンがマシンに属していることを前提としているためです。 -{{< /note >}} +ノードコントローラーは、Podがtaintを許容しない場合、 `NoExecute`のtaintを持つノード上で実行されているPodを排除する責務もあります。 +さらに、デフォルトで無効になっているアルファ機能として、ノードコントローラーはノードに到達できない、または準備ができていないなどのノードの問題に対応する{{< glossary_tooltip text="taint" term_id="taint" >}}を追加する責務があります。これはスケジューラーが、問題のあるノードにPodを配置しない事を意味しています。 {{< caution >}} `kubectl cordon`はノードに'unschedulable'としてマークします。それはロードバランサーのターゲットリストからノードを削除するという @@ -209,29 +250,29 @@ DaemonSetコントローラーによって作成されたPodはKubernetesスケ ### ノードのキャパシティ -ノードのキャパシティ（CPUの数とメモリの量）はNodeオブジェクトの一部です。 -通常、ノードは自分自身を登録し、Nodeオブジェクトを作成するときにキャパシティを報告します。 +Nodeオブジェクトはノードのリソースキャパシティ（CPUの数とメモリの量）を監視します。 +[自己登録](#self-registration-of-nodes)したノードは、Nodeオブジェクトを作成するときにキャパシティを報告します。 [手動によるノード管理](#manual-node-administration)を実行している場合は、ノードを追加するときにキャパシティを設定する必要があります。 -Kubernetesスケジューラーは、ノード上のすべてのPodに十分なリソースがあることを確認します。 +Kubernetes{{< glossary_tooltip text="スケジューラー" term_id="kube-scheduler" >}}は、ノード上のすべてのPodに十分なリソースがあることを確認します。 ノード上のコンテナが要求するリソースの合計がノードキャパシティ以下であることを確認します。 -これは、kubeletによって開始されたすべてのコンテナを含みますが、[コンテナランタイム](/ja/docs/concepts/overview/components/#container-runtime)によって直接開始されたコンテナやコンテナの外で実行されているプロセスは含みません。 +これは、kubeletによって管理されたすべてのコンテナを含みますが、コンテナランタイムによって直接開始されたコンテナやkubeletの制御外で実行されているプロセスは含みません。 -Pod以外のプロセス用にリソースを明示的に予約したい場合は、このチュートリアルに従って[Systemデーモン用にリソースを予約](/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved)してください。 +{{< note >}} +Pod以外のプロセス用にリソースを明示的に予約したい場合は、[Systemデーモン用にリソースを予約](/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved)を参照してください。 +{{< /note >}} ## ノードのトポロジー -{{< feature-state state="alpha" >}} +{{< feature-state state="alpha" for_k8s_version="v1.16" >}} `TopologyManager`の[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にすると、 kubeletはリソースの割当を決定する際にトポロジーのヒントを利用できます。 - -## APIオブジェクト - -NodeはKubernetesのREST APIにおけるトップレベルのリソースです。APIオブジェクトに関する詳細は以下の記事にてご覧いただけます: -[Node APIオブジェクト](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core). - +詳細は、[ノードのトポロジー管理ポリシーを制御する](/docs/tasks/administer-cluster/topology-manager/)を参照してください。 ## {{% heading "whatsnext" %}} -* [ノードコンポーネント](/ja/docs/concepts/overview/components/#node-components)について読む。 -* ノードレベルのトポロジーについて読む: [ノードのトポロジー管理ポリシーを制御する](/docs/tasks/administer-cluster/topology-manager/) +* [ノードコンポーネント](/ja/docs/concepts/overview/components/#node-components)について学習する。 +* [Node APIオブジェクト](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core)について読む。 +* アーキテクチャ設計文書の[Node](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node)という章を読む。 +* [TaintとToleration](/ja/docs/concepts/scheduling-eviction/taint-and-toleration/)について読む。 +* [クラスターのオートスケール](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling)について読む。 From cbba4077b29f1adaf808dd51ac11cd4231a10af7 Mon Sep 17 00:00:00 2001 From: hikkie3110 <3110hikaru326@gmail.com> Date: Tue, 8 Sep 2020 23:08:10 +0900 Subject: [PATCH 098/252] update nodes.md for v1.18 --- content/ja/docs/concepts/architecture/nodes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/architecture/nodes.md b/content/ja/docs/concepts/architecture/nodes.md index c2f74f9566..72879fa525 100644 --- a/content/ja/docs/concepts/architecture/nodes.md +++ b/content/ja/docs/concepts/architecture/nodes.md @@ -6,7 +6,7 @@ weight: 10 -Kubernetesはコンテナをノード上で実行されるPodに配置することで、ワークロードを実行します。 +Kubernetesはコンテナを_Node_上で実行されるPodに配置することで、ワークロードを実行します。 ノードはクラスターによりますが、1つのVMまたは物理的なマシンです。 各ノードは{{< glossary_tooltip text="Pod" term_id="pod" >}}やそれを制御する{{< glossary_tooltip text="コントロールプレーン" term_id="control-plane" >}}を実行するのに必要なサービスを含んでいます。 From bfeee745f3d632d6a600abcb82d97941c9f03274 Mon Sep 17 00:00:00 2001 From: hikkie3110 <3110hikaru326@gmail.com> Date: Tue, 8 Sep 2020 23:12:32 +0900 Subject: [PATCH 099/252] Update content/ja/docs/concepts/architecture/nodes.md Co-authored-by: Keita Akutsu --- content/ja/docs/concepts/architecture/nodes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/architecture/nodes.md b/content/ja/docs/concepts/architecture/nodes.md index 72879fa525..05793ebde8 100644 --- a/content/ja/docs/concepts/architecture/nodes.md +++ b/content/ja/docs/concepts/architecture/nodes.md @@ -88,7 +88,7 @@ kubectl cordon $ノード名 {{< note >}} {{< glossary_tooltip term_id="daemonset" >}}によって作成されたPodはノード上のunschedulable属性を考慮しません。 -これは、再起動の準備中にアプリケーションからアプリケーションが削除されている場合でも、デーモンセットがマシンに属していることを前提としているためです。 +これは、再起動の準備中にアプリケーションからアプリケーションが削除されている場合でも、DaemonSetがマシンに属していることを前提としているためです。 {{< /note >}} ## ノードのステータス From 1641b7e34c50b11fe80ec16a43c231c7c0b5615d Mon Sep 17 00:00:00 2001 From: Tadaki Sakai Date: Sat, 5 Sep 2020 22:12:29 +0900 Subject: [PATCH 100/252] fix translation for "such as" MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit In the context, "Development, Staging and Production" is example, so I think "といった" is appropriate. --- .../docs/concepts/overview/working-with-objects/namespaces.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/overview/working-with-objects/namespaces.md b/content/ja/docs/concepts/overview/working-with-objects/namespaces.md index 1b66e046f1..12de8e10df 100644 --- a/content/ja/docs/concepts/overview/working-with-objects/namespaces.md +++ b/content/ja/docs/concepts/overview/working-with-objects/namespaces.md @@ -79,7 +79,7 @@ kubectl config view --minify | grep namespace: ユーザーが[Service](/ja/docs/concepts/services-networking/service/)を作成するとき、Serviceは対応する[DNSエントリ](/ja/docs/concepts/services-networking/dns-pod-service/)を作成します。 このエントリは`..svc.cluster.local`という形式になり、これはもしあるコンテナがただ``を指定していた場合、Namespace内のローカルのServiceに対して名前解決されます。 -これはデベロップメント、ステージング、プロダクションといって複数のNamespaceをまたいで同じ設定を使う時に効果的です。 +これはデベロップメント、ステージング、プロダクションといった複数のNamespaceをまたいで同じ設定を使う時に効果的です。 もしユーザーがNamespaceをまたいでアクセスしたい時、 完全修飾ドメイン名(FQDN)を指定する必要があります。 ## すべてのオブジェクトはNamespaceに属しているとは限らない From 067dc0603962850a97f89066dcf0a2f484b45147 Mon Sep 17 00:00:00 2001 From: Tadaki Sakai Date: Tue, 8 Sep 2020 21:15:05 +0900 Subject: [PATCH 101/252] fix mark up in Ja concepts/workloads/controllers/deployment.md --- .../ja/docs/concepts/workloads/controllers/deployment.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/ja/docs/concepts/workloads/controllers/deployment.md b/content/ja/docs/concepts/workloads/controllers/deployment.md index 6b4fe79264..6f0f481add 100644 --- a/content/ja/docs/concepts/workloads/controllers/deployment.md +++ b/content/ja/docs/concepts/workloads/controllers/deployment.md @@ -13,7 +13,7 @@ weight: 30 _Deployment_ は[Pod](/ja/docs/concepts/workloads/pods/pod/)と[ReplicaSet](/ja/docs/concepts/workloads/controllers/replicaset/)の宣言的なアップデート機能を提供します。 -Deploymentにおいて_理想的な状態_ を記述すると、Deployment{{< glossary_tooltip text="コントローラー" term_id="controller" >}}は指定された頻度で現在の状態を理想的な状態に変更します。Deploymentを定義することによって、新しいReplicaSetを作成したり、既存のDeploymentを削除して新しいDeploymentで全てのリソースを適用できます。 +Deploymentにおいて _理想的な状態_ を記述すると、Deployment{{< glossary_tooltip text="コントローラー" term_id="controller" >}}は指定された頻度で現在の状態を理想的な状態に変更します。Deploymentを定義することによって、新しいReplicaSetを作成したり、既存のDeploymentを削除して新しいDeploymentで全てのリソースを適用できます。 {{< note >}} Deploymentによって作成されたReplicaSetを管理しないでください。ご自身のユースケースが以下の項目に含まれない場合、メインのKubernetesリポジトリーにIssueを作成することを検討してください。 @@ -110,7 +110,7 @@ Deploymentによって作成されたReplicaSetを管理しないでください ReplicaSetの出力には次のフィールドが表示されます: * `NAME`は、名前空間内にあるReplicaSetの名前の一覧です。 - * `DESIRED`は、アプリケーションの理想的な_レプリカ_ の値です。これはDeploymentを作成したときに定義したもので、これが_理想的な状態_ と呼ばれるものです。 + * `DESIRED`は、アプリケーションの理想的な _レプリカ_ の値です。これはDeploymentを作成したときに定義したもので、これが _理想的な状態_ と呼ばれるものです。 * `CURRENT`は現在実行されているレプリカの数です。 * `READY`は、ユーザーが使用できるアプリケーションのレプリカの数です。 * `AGE`は、アプリケーションが稼働してからの時間です。 @@ -756,7 +756,7 @@ Deploymentは、そのライフサイクルの間に様々な状態に遷移し ### Deploymentの更新処理 {#progressing-deployment} -以下のタスクが実行中のとき、KubernetesはDeploymentの状態を_progressing_ にします。 +以下のタスクが実行中のとき、KubernetesはDeploymentの状態を _進行中_ にします。 * Deploymentが新しいReplicaSetを作成します。 * Deploymentが新しいReplicaSetをスケールアップさせています。 @@ -767,7 +767,7 @@ Deploymentは、そのライフサイクルの間に様々な状態に遷移し ### Deploymentの更新処理の完了 {#complete-deployment} -Deploymentが以下の状態になったとき、KubernetesはDeploymentのステータスを_complete_ にします。 +Deploymentが以下の状態になったとき、KubernetesはDeploymentのステータスを _完了_ にします。 * Deploymentの全てのレプリカが、指定された最新のバージョンに更新されます。これは指定した更新処理が完了したことを意味します。 * Deploymentの全てのレプリカが利用可能になります。 From db611d74af7e2e81d751059ea50caef8b07ac35d Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Thu, 10 Sep 2020 22:33:52 +0900 Subject: [PATCH 102/252] Make docs/tasks/administer-cluster/_index.md follow v1.18 of the original text --- content/ja/docs/tasks/administer-cluster/_index.md | 1 + 1 file changed, 1 insertion(+) diff --git a/content/ja/docs/tasks/administer-cluster/_index.md b/content/ja/docs/tasks/administer-cluster/_index.md index 0f075ca038..b7a34be8db 100755 --- a/content/ja/docs/tasks/administer-cluster/_index.md +++ b/content/ja/docs/tasks/administer-cluster/_index.md @@ -1,4 +1,5 @@ --- title: "クラスターの管理" +description: クラスターの管理のための一般的なタスクについて学びます。 weight: 20 --- From 4a40397bc365350a2e5bc5f95874531e059be5b2 Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Fri, 28 Aug 2020 21:27:49 +0900 Subject: [PATCH 103/252] Update ttlafterfinished.md --- .../concepts/workloads/controllers/ttlafterfinished.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md b/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md index d1b1cc3354..ca68ddcac0 100644 --- a/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md +++ b/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md @@ -2,7 +2,7 @@ reviewers: title: 終了したリソースのためのTTLコントローラー(TTL Controller for Finished Resources) content_type: concept -weight: 65 +weight: 70 --- @@ -10,7 +10,7 @@ weight: 65 {{< feature-state for_k8s_version="v1.12" state="alpha" >}} TTLコントローラーは実行を終えたリソースオブジェクトのライフタイムを制御するためのTTL (time to live) メカニズムを提供します。 -TTLコントローラーは現在[Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/)のみ扱っていて、将来的にPodやカスタムリソースなど、他のリソースの実行終了を扱えるように拡張される予定です。 +TTLコントローラーは現在{{< glossary_tooltip text="Jobs" term_id="job" >}}のみ扱っていて、将来的にPodやカスタムリソースなど、他のリソースの実行終了を扱えるように拡張される予定です。 α版の免責事項: この機能は現在α版の機能で、kube-apiserverとkube-controller-managerの[Feature Gate](/docs/reference/command-line-tools-reference/feature-gates/)の`TTLAfterFinished`を有効にすることで使用可能です。 @@ -23,7 +23,7 @@ TTLコントローラーは現在[Job](/docs/concepts/workloads/controllers/jobs ## TTLコントローラー -TTLコントローラーは現在Jobに対してのみサポートされています。クラスターオペレーターはこの[例](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically)のように、Jobの`.spec.ttlSecondsAfterFinished`フィールドを指定することにより、終了したJob(`完了した`もしくは`失敗した`)を自動的に削除するためにこの機能を使うことができます。 +TTLコントローラーは現在Jobに対してのみサポートされています。クラスターオペレーターはこの[例](/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically)のように、Jobの`.spec.ttlSecondsAfterFinished`フィールドを指定することにより、終了したJob(`完了した`もしくは`失敗した`)を自動的に削除するためにこの機能を使うことができます。 TTLコントローラーは、そのリソースが終了したあと指定したTTLの秒数後に削除できるか推定します。言い換えると、そのTTLが期限切れになると、TTLコントローラーがリソースをクリーンアップするときに、そのリソースに紐づく従属オブジェクトも一緒に連続で削除します。注意点として、リソースが削除されるとき、ファイナライザーのようなライフサイクルに関する保証は尊重されます。 TTL秒はいつでもセット可能です。下記はJobの`.spec.ttlSecondsAfterFinished`フィールドのセットに関するいくつかの例です。 @@ -50,7 +50,7 @@ Kubernetesにおいてタイムスキューを避けるために、全てのNode ## {{% heading "whatsnext" %}} -[Jobの自動クリーンアップ](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically) +[Jobの自動クリーンアップ](/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically) [設計ドキュメント](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0026-ttl-after-finish.md) From 023b0dd9687678a3bd0230ca7fc0fbcfbeb93059 Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Sat, 29 Aug 2020 00:27:09 +0900 Subject: [PATCH 104/252] Update ttlafterfinished.md --- .../docs/concepts/workloads/controllers/ttlafterfinished.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md b/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md index ca68ddcac0..1715f2cf91 100644 --- a/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md +++ b/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md @@ -23,7 +23,7 @@ TTLコントローラーは現在{{< glossary_tooltip text="Jobs" term_id="job" ## TTLコントローラー -TTLコントローラーは現在Jobに対してのみサポートされています。クラスターオペレーターはこの[例](/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically)のように、Jobの`.spec.ttlSecondsAfterFinished`フィールドを指定することにより、終了したJob(`完了した`もしくは`失敗した`)を自動的に削除するためにこの機能を使うことができます。 +TTLコントローラーは現在Jobに対してのみサポートされています。クラスターオペレーターはこの[例](/ja/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically)のように、Jobの`.spec.ttlSecondsAfterFinished`フィールドを指定することにより、終了したJob(`完了した`もしくは`失敗した`)を自動的に削除するためにこの機能を使うことができます。 TTLコントローラーは、そのリソースが終了したあと指定したTTLの秒数後に削除できるか推定します。言い換えると、そのTTLが期限切れになると、TTLコントローラーがリソースをクリーンアップするときに、そのリソースに紐づく従属オブジェクトも一緒に連続で削除します。注意点として、リソースが削除されるとき、ファイナライザーのようなライフサイクルに関する保証は尊重されます。 TTL秒はいつでもセット可能です。下記はJobの`.spec.ttlSecondsAfterFinished`フィールドのセットに関するいくつかの例です。 @@ -50,7 +50,7 @@ Kubernetesにおいてタイムスキューを避けるために、全てのNode ## {{% heading "whatsnext" %}} -[Jobの自動クリーンアップ](/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically) +[Jobの自動クリーンアップ](/ja/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically) [設計ドキュメント](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0026-ttl-after-finish.md) From 239cf338d747d0a1ac40ae1716f8eb3aa27298e0 Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Sat, 29 Aug 2020 10:17:44 +0900 Subject: [PATCH 105/252] Update ttlafterfinished.md --- .../docs/concepts/workloads/controllers/ttlafterfinished.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md b/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md index 1715f2cf91..daa98ebc01 100644 --- a/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md +++ b/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md @@ -23,7 +23,7 @@ TTLコントローラーは現在{{< glossary_tooltip text="Jobs" term_id="job" ## TTLコントローラー -TTLコントローラーは現在Jobに対してのみサポートされています。クラスターオペレーターはこの[例](/ja/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically)のように、Jobの`.spec.ttlSecondsAfterFinished`フィールドを指定することにより、終了したJob(`完了した`もしくは`失敗した`)を自動的に削除するためにこの機能を使うことができます。 +TTLコントローラーは現在Jobに対してのみサポートされています。クラスターオペレーターはこの[例](/ja/docs/concepts/workloads/controllers/job/#終了したjobの自動クリーンアップ)のように、Jobの`.spec.ttlSecondsAfterFinished`フィールドを指定することにより、終了したJob(`完了した`もしくは`失敗した`)を自動的に削除するためにこの機能を使うことができます。 TTLコントローラーは、そのリソースが終了したあと指定したTTLの秒数後に削除できるか推定します。言い換えると、そのTTLが期限切れになると、TTLコントローラーがリソースをクリーンアップするときに、そのリソースに紐づく従属オブジェクトも一緒に連続で削除します。注意点として、リソースが削除されるとき、ファイナライザーのようなライフサイクルに関する保証は尊重されます。 TTL秒はいつでもセット可能です。下記はJobの`.spec.ttlSecondsAfterFinished`フィールドのセットに関するいくつかの例です。 @@ -50,7 +50,7 @@ Kubernetesにおいてタイムスキューを避けるために、全てのNode ## {{% heading "whatsnext" %}} -[Jobの自動クリーンアップ](/ja/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically) +[Jobの自動クリーンアップ](/ja/docs/concepts/workloads/controllers/job/#終了したjobの自動クリーンアップ) [設計ドキュメント](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0026-ttl-after-finish.md) From 949260c0e455d4ed757b7f15ea333babfec9099f Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Sun, 30 Aug 2020 00:08:24 +0900 Subject: [PATCH 106/252] Update ttlafterfinished.md --- .../docs/concepts/workloads/controllers/ttlafterfinished.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md b/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md index daa98ebc01..01af87c553 100644 --- a/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md +++ b/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md @@ -23,7 +23,7 @@ TTLコントローラーは現在{{< glossary_tooltip text="Jobs" term_id="job" ## TTLコントローラー -TTLコントローラーは現在Jobに対してのみサポートされています。クラスターオペレーターはこの[例](/ja/docs/concepts/workloads/controllers/job/#終了したjobの自動クリーンアップ)のように、Jobの`.spec.ttlSecondsAfterFinished`フィールドを指定することにより、終了したJob(`完了した`もしくは`失敗した`)を自動的に削除するためにこの機能を使うことができます。 +TTLコントローラーは現在Jobに対してのみサポートされています。クラスターオペレーターはこの[例](/#終了したjobの自動クリーンアップ)のように、Jobの`.spec.ttlSecondsAfterFinished`フィールドを指定することにより、終了したJob(`完了した`もしくは`失敗した`)を自動的に削除するためにこの機能を使うことができます。 TTLコントローラーは、そのリソースが終了したあと指定したTTLの秒数後に削除できるか推定します。言い換えると、そのTTLが期限切れになると、TTLコントローラーがリソースをクリーンアップするときに、そのリソースに紐づく従属オブジェクトも一緒に連続で削除します。注意点として、リソースが削除されるとき、ファイナライザーのようなライフサイクルに関する保証は尊重されます。 TTL秒はいつでもセット可能です。下記はJobの`.spec.ttlSecondsAfterFinished`フィールドのセットに関するいくつかの例です。 @@ -50,7 +50,7 @@ Kubernetesにおいてタイムスキューを避けるために、全てのNode ## {{% heading "whatsnext" %}} -[Jobの自動クリーンアップ](/ja/docs/concepts/workloads/controllers/job/#終了したjobの自動クリーンアップ) +[Jobの自動クリーンアップ](/#終了したjobの自動クリーンアップ) [設計ドキュメント](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0026-ttl-after-finish.md) From 0377d7ba37cc8d939fedd283fcf20bde997f774c Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Sun, 30 Aug 2020 00:32:11 +0900 Subject: [PATCH 107/252] fixed hashtag link --- .../docs/concepts/workloads/controllers/ttlafterfinished.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md b/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md index 01af87c553..0c7c233fcd 100644 --- a/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md +++ b/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md @@ -23,7 +23,7 @@ TTLコントローラーは現在{{< glossary_tooltip text="Jobs" term_id="job" ## TTLコントローラー -TTLコントローラーは現在Jobに対してのみサポートされています。クラスターオペレーターはこの[例](/#終了したjobの自動クリーンアップ)のように、Jobの`.spec.ttlSecondsAfterFinished`フィールドを指定することにより、終了したJob(`完了した`もしくは`失敗した`)を自動的に削除するためにこの機能を使うことができます。 +TTLコントローラーは現在Jobに対してのみサポートされています。クラスターオペレーターはこの[例](#終了したjobの自動クリーンアップ)のように、Jobの`.spec.ttlSecondsAfterFinished`フィールドを指定することにより、終了したJob(`完了した`もしくは`失敗した`)を自動的に削除するためにこの機能を使うことができます。 TTLコントローラーは、そのリソースが終了したあと指定したTTLの秒数後に削除できるか推定します。言い換えると、そのTTLが期限切れになると、TTLコントローラーがリソースをクリーンアップするときに、そのリソースに紐づく従属オブジェクトも一緒に連続で削除します。注意点として、リソースが削除されるとき、ファイナライザーのようなライフサイクルに関する保証は尊重されます。 TTL秒はいつでもセット可能です。下記はJobの`.spec.ttlSecondsAfterFinished`フィールドのセットに関するいくつかの例です。 @@ -50,7 +50,7 @@ Kubernetesにおいてタイムスキューを避けるために、全てのNode ## {{% heading "whatsnext" %}} -[Jobの自動クリーンアップ](/#終了したjobの自動クリーンアップ) +[Jobの自動クリーンアップ](#終了したjobの自動クリーンアップ) [設計ドキュメント](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0026-ttl-after-finish.md) From 536d49174a2cbd19f234d29d82fd1a2e15992840 Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Sun, 30 Aug 2020 13:13:48 +0900 Subject: [PATCH 108/252] fixed link --- content/ja/docs/concepts/workloads/controllers/job.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md index 386eb1dd5c..9bc827f5c4 100644 --- a/content/ja/docs/concepts/workloads/controllers/job.md +++ b/content/ja/docs/concepts/workloads/controllers/job.md @@ -230,7 +230,7 @@ Job内のJobの仕様と[Podテンプレートの仕様](/ja/docs/concepts/workl `restartPolicy`はPodに適用され、Job自体には適用されないことに注意してください。Jobのステータスが`type: Failed`になると、Jobの自動再起動は行われません。 つまり、 `.spec.activeDeadlineSeconds`と`.spec.backoffLimit`でアクティブ化されるJob終了のメカニズムは、手作業での介入が必要になるような永続的なJobの失敗を引き起こします。 -## 終了したJobの自動クリーンアップ +## 終了したJobの自動クリーンアップ {#clean-up-finished-jobs-automatically} 終了したJobは、通常、もう必要ありません。それらをシステム内に保持すると、APIサーバーに負担がかかります。[CronJobs](/ja/docs/concepts/workloads/controllers/cron-jobs/)などの上位レベルのコントローラーによってJobが直接管理されている場合、指定された容量ベースのクリーンアップポリシーに基づいて、JobをCronJobsでクリーンアップできます。 From cd78bc4b070b36ad215477c411ed9b3e77185655 Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Sun, 30 Aug 2020 13:14:17 +0900 Subject: [PATCH 109/252] Revert "fixed link" This reverts commit 175f6974b86b7b5b11711402b5e4f66d8f6b6264. --- .../concepts/workloads/controllers/job.md | 387 ------------------ 1 file changed, 387 deletions(-) delete mode 100644 content/ja/docs/concepts/workloads/controllers/job.md diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md deleted file mode 100644 index 9bc827f5c4..0000000000 --- a/content/ja/docs/concepts/workloads/controllers/job.md +++ /dev/null @@ -1,387 +0,0 @@ ---- -title: Job -content_type: concept -feature: - title: バッチ実行 - description: > - Kubernetesはサービスに加えて、バッチやCIのワークロードを管理し、必要に応じて失敗したコンテナを置き換えることができます。 -weight: 60 ---- - - - -Jobは1つ以上のPodを作成し、指定された数のPodが正常に終了することを保証します。 -JobはPodの正常終了を追跡します。正常終了が指定された回数に達すると、そのタスク(つまりJob)は完了します。Jobを削除すると、そのJobが作成したPodがクリーンアップされます。 - -簡単な例としては、1つのPodを確実に実行して完了させるために、1つのJobオブジェクトを作成することです。 -ノードのハードウェア障害やノードの再起動などにより最初のPodが失敗したり削除されたりした場合、Jobオブジェクトは新たなPodを立ち上げます。 - -また、Jobを使用して複数のPodを並行して実行することもできます。 - - - - - - -## Jobの実行例 - -ここでは、Jobの設定例を示します。πの値を2000桁目まで計算して出力します。 -完了までに10秒程度かかります。 - -{{< codenew file="controllers/job.yaml" >}} - -このコマンドで例を実行できます。 - -```shell -kubectl apply -f https://kubernetes.io/examples/controllers/job.yaml -``` -``` -job.batch/pi created -``` - -Jobのステータスは、`kubectl`を用いて確認します。 - -```shell -kubectl describe jobs/pi -``` -``` -Name: pi -Namespace: default -Selector: controller-uid=c9948307-e56d-4b5d-8302-ae2d7b7da67c -Labels: controller-uid=c9948307-e56d-4b5d-8302-ae2d7b7da67c - job-name=pi -Annotations: kubectl.kubernetes.io/last-applied-configuration: - {"apiVersion":"batch/v1","kind":"Job","metadata":{"annotations":{},"name":"pi","namespace":"default"},"spec":{"backoffLimit":4,"template":... -Parallelism: 1 -Completions: 1 -Start Time: Mon, 02 Dec 2019 15:20:11 +0200 -Completed At: Mon, 02 Dec 2019 15:21:16 +0200 -Duration: 65s -Pods Statuses: 0 Running / 1 Succeeded / 0 Failed -Pod Template: - Labels: controller-uid=c9948307-e56d-4b5d-8302-ae2d7b7da67c - job-name=pi - Containers: - pi: - Image: perl - Port: - Host Port: - Command: - perl - -Mbignum=bpi - -wle - print bpi(2000) - Environment: - Mounts: - Volumes: -Events: - Type Reason Age From Message - ---- ------ ---- ---- ------- - Normal SuccessfulCreate 14m job-controller Created pod: pi-5rwd7 -``` - -Jobの完了したPodを表示するには、`kubectl get pods`を使います。 - -あるJobに属するすべてのPodの一覧を機械可読な形式で出力するには、次のようなコマンドを使います。 - -```shell -pods=$(kubectl get pods --selector=job-name=pi --output=jsonpath='{.items[*].metadata.name}') -echo $pods -``` -``` -pi-5rwd7 -``` - -ここでのセレクターは、Jobのセレクターと同じです。`--output=jsonpath`オプションは、返されたリストの各Podから名前だけを取得する式を指定します。 - - -いずれかのPodの標準出力を表示します。 - -```shell -kubectl logs $pods -``` -出力例は以下の通りです。 -```shell -3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679821480865132823066470938446095505822317253594081284811174502841027019385211055596446229489549303819644288109756659334461284756482337867831652712019091456485669234603486104543266482133936072602491412737245870066063155881748815209209628292540917153643678925903600113305305488204665213841469519415116094330572703657595919530921861173819326117931051185480744623799627495673518857527248912279381830119491298336733624406566430860213949463952247371907021798609437027705392171762931767523846748184676694051320005681271452635608277857713427577896091736371787214684409012249534301465495853710507922796892589235420199561121290219608640344181598136297747713099605187072113499999983729780499510597317328160963185950244594553469083026425223082533446850352619311881710100031378387528865875332083814206171776691473035982534904287554687311595628638823537875937519577818577805321712268066130019278766111959092164201989380952572010654858632788659361533818279682303019520353018529689957736225994138912497217752834791315155748572424541506959508295331168617278558890750983817546374649393192550604009277016711390098488240128583616035637076601047101819429555961989467678374494482553797747268471040475346462080466842590694912933136770289891521047521620569660240580381501935112533824300355876402474964732639141992726042699227967823547816360093417216412199245863150302861829745557067498385054945885869269956909272107975093029553211653449872027559602364806654991198818347977535663698074265425278625518184175746728909777727938000816470600161452491921732172147723501414419735685481613611573525521334757418494684385233239073941433345477624168625189835694855620992192221842725502542568876717904946016534668049886272327917860857843838279679766814541009538837863609506800642251252051173929848960841284886269456042419652850222106611863067442786220391949450471237137869609563643719172874677646575739624138908658326459958133904780275901 -``` - -## Jobの仕様の作成 - -他のすべてのKubernetesの設定と同様に、Jobには`apiVersion`、`kind`、および`metadata`フィールドが必要です。 -その名前は有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。 - -Jobには[`.spec`セクション](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)も必要です。 - -### Podテンプレート - -`.spec.template`は、`.spec`の唯一の必須フィールドです。 - -`.spec.template`は[Podテンプレート](/ja/docs/concepts/workloads/pods/#pod-templates)です。 -ネストされており、`apiVersion`や`kind`ないことを除けば、{{< glossary_tooltip text="Pod" term_id="pod" >}}とまったく同じスキーマを持ちます。 - -Podの必須フィールドに加えて、JobのPodテンプレートでは、適切なラベル([Podセレクター](#pod-selector)参照)と適切な再起動ポリシーを指定しなければなりません。 - -`Never`または`OnFailure`と等しい[`RestartPolicy`](/ja/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)のみが許可されます。 - -### Podセレクター {#pod-selector} - -`.spec.selector`フィールドはオプションです。ほとんどの場合、指定すべきではありません。 -セクション「[独自のPodセレクターの指定](#specifying-your-own-pod-selector)」を参照してください。 - - -### Jobの並列実行 {#parallel-jobs} - -Jobとして実行するのに適したタスクは、大きく分けて3つあります。 - -1. 非並列Job - - 通常は、Podが失敗しない限り、1つのPodのみが起動されます。 - - そのPodが正常に終了するとすぐにJobが完了します。 -2. *固定の完了数*を持つ並列Job - - `.spec.completions`に、0以外の正の値を指定します。 - - Jobはタスク全体を表し、1から`.spec.completions`の範囲内の各値に対して、1つの成功したPodがあれば完了です。 - - **まだ実装されていません**が、各Podには、1から`.spec.completions`の範囲内で異なるインデックスが渡されます。 -3. *ワークキュー*を持つ並列Job - - `.spec.completions`は指定しません。デフォルトは`.spec.parallelism`です。 - - Podは、それぞれが何を処理するか決定するために、 Pod間または外部サービス間で調整する必要があります。例えば、あるPodはワークキューから最大N個のアイテムのバッチを取得します。 - - 各Podはすべてのピアが完了したかどうか、つまりJob全体が完了したかどうかを、独立して判断できます。 - - Jobの _任意の_ Podが正常終了すると、新しいPodは作成されません。 - - 少なくとも1つのPodが正常終了し、すべてのPodが終了すると、Jobは正常に完了します。 - - Podが正常終了した後は、他のPodがこのタスクの処理を行ったり、出力を書き込んだりしてはなりません。それらはすべて終了する必要があります。 - -_非並列_ Jobの場合、`.spec.completions`と`.spec.parallelism`の両方を未設定のままにすることができます。両方が設定されていない場合、どちらもデフォルトで1になります。 - -_ワークキュー_ を持つJobの場合、`.spec.completions`を未設定のままにし、`.spec.parallelism`を非負整数にする必要があります。 - - -様々な種類のJobを利用する方法の詳細については、セクション「[Jobのパターン](#job-patterns)」をご覧ください。 - -#### 並列処理の制御 - -並列処理数(`.spec.parallelism`)については、任意の非負整数を設定できます。 -指定しない場合、デフォルトで1になります。 -0を指定した場合、並列処理数が増えるまで、Jobは実質的に一時停止されます。 - -以下に挙げる様々な理由から、実際の並列処理数(任意の時点で実行されるPodの数)が、要求された数より多い場合と少ない場合があります。 - -- _固定完了数_ を持つJobの場合、並行して実行されるPodの実際の数は、残りの完了数を超えることはありません。`.spec.parallelism`の大きい値は事実上無視されます。 -- _ワークキュー_ を持つJobの場合、Podが成功しても新しいPodは開始されません。ただし、残りのPodは完了できます。 -- Jobコントローラー({{< glossary_tooltip term_id="controller" >}})が反応する時間がない場合も考えられます。 -- Jobコントローラーが何らかの理由(`ResourceQuota`がない、権限がないなど)でPodの作成に失敗した場合、要求された数よりも少ないPod数になる可能性があります。 -- Jobコントローラーは、同じJob内で以前のPodが過剰に失敗したために、新しいPodの作成を調整する場合があります。 -- Podをグレースフルにシャットダウンした場合、停止までに時間がかかります。 - -## Podおよびコンテナの障害の処理 - -Pod内のコンテナは、その中のプロセスが0以外の終了コードで終了した、またはメモリー制限を超えたためにコンテナが強制終了されたなど、さまざまな理由で失敗する可能性があります。これが発生し、`.spec.template.spec.restartPolicy = "OnFailure"`であ場合、Podはノードに残りますが、コンテナは再実行されます。したがって、プログラムはローカルで再起動するケースを処理するか、`.spec.template.spec.restartPolicy = "Never"`を指定する必要があります。 -`restartPolicy`の詳細な情報は、[Podのライフサイクル](/ja/docs/concepts/workloads/pods/pod-lifecycle/#example-states)を参照してください。 - -さまざまな理由で、Pod全体が失敗することもあります。例えば、Podが(ノードのアップグレード、再起動、削除などにより)ノードから切り離された場合や、Podのコンテナが失敗して`.spec.template.spec.restartPolicy = "Never"`が設定されている場合などです。Podが失敗した場合、Jobコントローラーは新しいPodを開始します。つまり、アプリケーションは新しいPodで再起動されたケースを処理する必要があります。特に、前の実行によって発生した一時ファイル、ロック、不完全な出力などに対する処理が必要です。 - -たとえ`.spec.parallelism = 1`、`.spec.completions = 1`、`.spec.template.spec.restartPolicy = "Never"`を指定しても、同じプログラムが2回起動される場合があることに注意してください。 - -`.spec.parallelism`と`.spec.completions`の両方を1より大きい値に指定した場合は、複数のPodが同時に実行される可能性があります。したがって、Podは同時実行性にも対応する必要があります。 - -### Pod Backoff Failure Policy - -構成の論理エラーなどが原因で、ある程度の再試行後にJobを失敗させたい場合があります。 -そのためには、`.spec.backoffLimit`を設定して、Jobが失敗したと見なすまでの再試行回数を指定します。デフォルトでは6に設定されています。 -失敗したPodは、6分を上限とする指数バックオフ遅延(10秒、20秒、40秒...)に従って、Jobコントローラーにより再作成されます。 -JobのPodが削除されるか、Jobの他のPodがその時間に失敗することなく成功すると、バックオフカウントがリセットされます。 - -{{< note >}} -Jobに`restartPolicy = "OnFailure"`がある場合、Jobのバックオフ制限に達すると、Jobを実行しているコンテナが終了することに注意してください。これにより、Jobの実行可能ファイルのデバッグがより困難になる可能性があります。Jobのデバッグするまたはロギングシステムを使用する場合は、`restartPolicy = "Never"`を設定して、失敗したJobからの出力が誤って失われないようにすることをお勧めします。 -{{< /note >}} - -## Jobの終了とクリーンアップ - -Jobが完了すると、Podは作成されなくなりますが、Podの削除も行われません。それらを保持しておくと、完了したPodのログを表示して、エラー、警告、またはその他の診断の出力を確認できます。 -Jobオブジェクトは完了後も残るため、ステータスを表示できます。ステータスを確認した後、古いJobを削除するのはユーザーの責任です。`kubectl`(例えば`kubectl delete jobs/pi`や`kubectl delete -f ./job.yaml`)を用いてJobを削除してください。`kubectl`でJobを削除すると、Jobが作成したすべてのPodも削除されます。 - -デフォルトでは、Podが失敗する(`restartPolicy=Never`)かコンテナがエラーで終了する(`restartPolicy=OnFailure`)場合を除き、Jobは中断されずに実行されます。その時点でJobは上記の`.spec.backoffLimit`に従います。`.spec.backoffLimit`に達すると、Jobは失敗としてマークされ、実行中のPodはすべて終了されます。 - -Jobを終了する別の方法は、アクティブな期限を設定することです。 -これを行うには、Jobの`.spec.activeDeadlineSeconds`フィールドを秒数に設定します -`activeDeadlineSeconds`は、作成されたPodの数に関係なく、Jobの期間に適用されます。 -Jobが`activeDeadlineSeconds`に到達すると、実行中のすべてのPodが終了し、Jobのステータスは`type: Failed`および`reason: DeadlineExceeded`となります。 - -Jobの`.spec.activeDeadlineSeconds`は、`.spec.backoffLimit`よりも優先されることに注意してください。したがって、1つ以上の失敗したPodを再試行しているJobは、`backoffLimit`にまだ達していない場合でも、`activeDeadlineSeconds`で指定された制限時間に達すると、追加のPodをデプロイしません。 - -以下に例を挙げます。 - -```yaml -apiVersion: batch/v1 -kind: Job -metadata: - name: pi-with-timeout -spec: - backoffLimit: 5 - activeDeadlineSeconds: 100 - template: - spec: - containers: - - name: pi - image: perl - command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"] - restartPolicy: Never -``` - -Job内のJobの仕様と[Podテンプレートの仕様](/ja/docs/concepts/workloads/pods/init-containers/#detailed-behavior)の両方に`activeDeadlineSeconds`フィールドがあることに注意してください。このフィールドが適切なレベルに設定されていることを確認してください。 - -`restartPolicy`はPodに適用され、Job自体には適用されないことに注意してください。Jobのステータスが`type: Failed`になると、Jobの自動再起動は行われません。 -つまり、 `.spec.activeDeadlineSeconds`と`.spec.backoffLimit`でアクティブ化されるJob終了のメカニズムは、手作業での介入が必要になるような永続的なJobの失敗を引き起こします。 - -## 終了したJobの自動クリーンアップ {#clean-up-finished-jobs-automatically} - -終了したJobは、通常、もう必要ありません。それらをシステム内に保持すると、APIサーバーに負担がかかります。[CronJobs](/ja/docs/concepts/workloads/controllers/cron-jobs/)などの上位レベルのコントローラーによってJobが直接管理されている場合、指定された容量ベースのクリーンアップポリシーに基づいて、JobをCronJobsでクリーンアップできます。 - -### 終了したJobのTTLメカニズム - -{{< feature-state for_k8s_version="v1.12" state="alpha" >}} - -完了したJob(`Complete`または`Failed`)を自動的にクリーンアップする別の方法は、[TTLコントローラー](/ja/docs/concepts/workloads/controllers/ttlafterfinished/)が提供するTTLメカニズムを使用して、完了したリソースを指定することです。Jobの`.spec.ttlSecondsAfterFinished`フィールドに指定します。 - -TTLコントローラーがJobをクリーンアップすると、Jobが連鎖的に削除されます。つまり、Podなどの依存オブジェクトがJobとともに削除されます。Jobが削除されるとき、ファイナライザーなどのライフサイクル保証が優先されることに注意してください。 - -例は以下の通りです。 - -```yaml -apiVersion: batch/v1 -kind: Job -metadata: - name: pi-with-ttl -spec: - ttlSecondsAfterFinished: 100 - template: - spec: - containers: - - name: pi - image: perl - command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"] - restartPolicy: Never -``` - -Job`pi-with-ttl`は、Jobが終了してから`100`秒後に自動的に削除される。 - -フィールドが`0`に設定されている場合は、Jobは終了後すぐに自動的に削除されます。フィールドが設定されていない場合は、このJobは終了後にTTLコントローラーによってクリーンアップされません。 - -このTTLメカニズムはアルファ版であり、`TTLAfterFinished`フィーチャーゲートであることに注意してください。詳細は[TTLコントローラー](/ja/docs/concepts/workloads/controllers/ttlafterfinished/)のドキュメントを参照してください。 - -## Jobのパターン {#job-patterns} - -Jobオブジェクトは、Podの信頼性の高い並列実行をサポートするために使用できます。Jobオブジェクトは、科学的コンピューティングで一般的に見られるような、密接に通信する並列プロセスをサポートするようには設計されていません。しかし、独立しているが関連性のある*ワークアイテム*の集合の並列処理はサポートしています。 - -例えば送信する電子メール、レンダリングするフレーム、トランスコードするファイル、スキャンするNoSQLデータベースのキーの範囲などです。 - -複雑なシステムでは、複数の異なるワークアイテムの集合があるかもしれません。ここでは、ユーザーがまとめて管理したい作業項目の1つの集合(バッチJob)を考えています。 - -並列計算にはいくつかのパターンがあり、それぞれ長所と短所があります。 -トレードオフは以下の通りです。 - -- 各ワークアイテムに1つのJobオブジェクトを使用する場合と、すべてのワークアイテムに1つのJobオブジェクトを使用する場合を比較すると、後者の方がワークアイテムの数が多い場合に適しています。前者では、ユーザーとシステムが大量のJobオブジェクトを管理するためのオーバーヘッドが発生します。 -- 作成されたPodの数がワークアイテムの数に等しい場合と、各Podが複数のワークアイテムを処理する場合を比較すると、前者の方が一般的に既存のコードやコンテナへの変更が少ないです。後者は上記の項目と同様の理由で、大量のワークアイテムを処理するのに適しています。 -- いくつかのアプローチでは、ワークキューを使用します。これはキューサービスを実行している必要があり、既存のプログラムやコンテナを変更してワークキューを使用するようにする必要があります。他のアプローチは、既存のコンテナ化されたアプリケーションに適応するのがさらに容易です。 - -ここでは、上記のトレードオフに対応するものを、2から4列目にまとめています。 -パターン名は、例とより詳細な説明へのリンクでもあります。 - -| パターン名 | 単一のJobオブジェクト | ワークアイテムよりPodが少ないか？ | アプリをそのまま使用するか？ | Kube 1.1で動作するか？ | -| ----------------------------------------------------------------------------------------------- |:-----------------:|:---------------------------:|:-------------------:|:-------------------:| -| [Jobテンプレートを拡張する](/ja/docs/tasks/job/parallel-processing-expansion/) | | | ✓ | ✓ | -| [ワークアイテムごとにPodでキューを作成する](/ja/docs/tasks/job/coarse-parallel-processing-work-queue/) | ✓ | | 場合による | ✓ | -| [Pod数が可変であるキューを作成する](/ja/docs/tasks/job/fine-parallel-processing-work-queue/) | ✓ | ✓ | | ✓ | -| 単一のJob静的な処理を割り当てる | ✓ | | ✓ | | - -完了数を`.spec.completions`で指定すると、Jobコントローラーが作成した各Podは同じ[`spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)を持ちます。つまり、あるタスクを実行するすべてのPodは、同じコマンドラインと同じイメージ、同じボリューム、そして(ほぼ)同じ環境変数を持ちます。これらのパターンは、Podが異なる処理を行うように配置するための様々な方法です。 - -以下の表では、パターンごとに必要な`.spec.parallelism`と`.spec.completions`の設定を示します。 -ここで、`W`はワークアイテム数とします。 - -| パターン名 | `.spec.completions` | `.spec.parallelism` | -| ----------------------------------------------------------------------------------------------- |:-------------------:|:--------------------:| -| [Jobテンプレートを拡張する](/ja/docs/tasks/job/parallel-processing-expansion/) | 1 | 1とする必要あり | -| [ワークアイテムごとにPodでキューを作成する](/ja/docs/tasks/job/coarse-parallel-processing-work-queue/) | W | 任意 | -| [Pod数が可変であるキューを作成する](/ja/docs/tasks/job/fine-parallel-processing-work-queue/) | 1 | 任意 | -| 単一のJob静的な処理を割り当てる | W | 任意 | - - -## 高度な使用方法 - -### 独自のPodセレクターを指定する {#specifying-your-own-pod-selector} - -通常、Jobオブジェクトを作成する際には`.spec.selector`を指定しません。 -システムのデフォルトのロジックで、Jobの作成時にこのフィールドを追加します。 -セレクターの値は、他のJobと重複しないように選択されます。 - -しかし、場合によっては、この自動的に設定されるセレクターを上書きする必要があるかもしれません。 -これを行うには、Jobの`.spec.selector`を指定します。 - -これを行う際には十分に注意が必要です。もし指定したラベルセレクターが、そのJobのPodに対して固有でなく、無関係なPodにマッチする場合、無関係なJobのPodが削除されたり、このJobが他のPodを完了したものとしてカウントしたり、一方または両方のJobがPodの作成や完了まで実行を拒否することがあります。 -もし固有でないセレクターを選択した場合は、他のコントローラー(例えばレプリケーションコントローラーなど)やそのPodも予測不能な動作をする可能性があります。Kubernetesは`.spec.selector`を指定する際のミスを防ぐことはできません。 - -ここでは、この機能を使いたくなるようなケースの例をご紹介します。 -`old`というJobがすでに実行されているとします。既存のPodを実行し続けたいが、作成した残りのPodには別のPodテンプレートを使用し、Jobには新しい名前を付けたいとします。 -これらのフィールドは更新が不可能であるため、Jobを更新することはできません。 -そのため、`kubectl delete jobs/old --cascade=false`を使って、`old`というJobを削除し、一方で _そのPodは実行したまま_ にします。 -削除する前に、どのセレクターを使っているかメモしておきます。 - -``` -kubectl get job old -o yaml -``` -``` -kind: Job -metadata: - name: old - ... -spec: - selector: - matchLabels: - controller-uid: a8f3d00d-c6d2-11e5-9f87-42010af00002 - ... -``` -次に`new`という名前の新しいJobを作成し、同じセレクターを明示的に指定します。 -既存のPodには`controller-uid=a8f3d00d-c6d2-11e5-9f87-42010af00002`というラベルが付いているので、それらも同様にJob`new`で制御されます。 - -システムが自動的に生成するセレクターを使用していないので、新しいJobでは`manualSelector: true`を指定する必要があります。 - -``` -kind: Job -metadata: - name: new - ... -spec: - manualSelector: true - selector: - matchLabels: - controller-uid: a8f3d00d-c6d2-11e5-9f87-42010af00002 - ... -``` - -新しいJob自体は`a8f3d00d-c6d2-11e5-9f87-42010af00002`とは異なるuidを持つでしょう。 -`manualSelector: true`を設定すると、あなたが何をしているかを知っていることをシステムに伝え、この不一致を許容するようにします。 - -## 代替案 - -### ベアPod - -Podが実行されているノードが再起動したり障害が発生したりすると、Podは終了し、再起動されません。しかし、Jobは終了したPodを置き換えるために新しいPodを作成します。 -このため、アプリケーションが単一のPodしか必要としない場合でも、ベアPodではなくJobを使用することをお勧めします。 - -### レプリケーションコントローラー - -Jobは[レプリケーションコントローラー](/ja/docs/user-guide/replication-controller)を補完するものです。 -レプリケーションコントローラーは終了が予想されないPod(例えばWebサーバー)を管理し、Jobは終了が予想されるPod(例えばバッチタスク)を管理します。 - -[Podのライフサイクル](/ja/docs/concepts/workloads/pods/pod-lifecycle/)で説明したように、`Job`は`RestartPolicy`が`OnFailure`または`Never`と等しいPodに対して*のみ*適切です。 -(注意: `RestartPolicy`が設定されていない場合、デフォルト値は`Always`です。) - -### 単一のJobでコントローラーPodを起動 - -もう一つのパターンは、単一のJobでPodを作成し、そのPodが他のPodを作成し、それらのPodに対するカスタムコントローラーのように動作するというものです。これは最も柔軟性がありますが、始めるのがやや複雑で、Kubernetesとの統合性が低いかもしれません。 - -このパターンの例として、Podを起動してスクリプトを実行するJobがSparkマスターコントローラー([Sparkの例](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/spark/README.md)を参照)を起動し、Sparkドライバーを実行してからクリーンアップするというものがあります。 - -このアプローチの利点は、全体的なプロセスがJobオブジェクトが完了する保証を得ながらも、どのようなPodが作成され、どのように作業が割り当てられるかを完全に制御できることです。 - -## Cron Job {#cron-jobs} - -Unixのツールである`cron`と同様に、指定した日時に実行されるJobを作成するために、[`CronJob`](/ja/docs/concepts/workloads/controllers/cron-jobs/)を使用することができます。 From 2135d79e7c2a5a370d3558c29de14bfb4454d600 Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Sun, 30 Aug 2020 13:15:01 +0900 Subject: [PATCH 110/252] fixed link --- .../docs/concepts/workloads/controllers/ttlafterfinished.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md b/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md index 0c7c233fcd..1715f2cf91 100644 --- a/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md +++ b/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md @@ -23,7 +23,7 @@ TTLコントローラーは現在{{< glossary_tooltip text="Jobs" term_id="job" ## TTLコントローラー -TTLコントローラーは現在Jobに対してのみサポートされています。クラスターオペレーターはこの[例](#終了したjobの自動クリーンアップ)のように、Jobの`.spec.ttlSecondsAfterFinished`フィールドを指定することにより、終了したJob(`完了した`もしくは`失敗した`)を自動的に削除するためにこの機能を使うことができます。 +TTLコントローラーは現在Jobに対してのみサポートされています。クラスターオペレーターはこの[例](/ja/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically)のように、Jobの`.spec.ttlSecondsAfterFinished`フィールドを指定することにより、終了したJob(`完了した`もしくは`失敗した`)を自動的に削除するためにこの機能を使うことができます。 TTLコントローラーは、そのリソースが終了したあと指定したTTLの秒数後に削除できるか推定します。言い換えると、そのTTLが期限切れになると、TTLコントローラーがリソースをクリーンアップするときに、そのリソースに紐づく従属オブジェクトも一緒に連続で削除します。注意点として、リソースが削除されるとき、ファイナライザーのようなライフサイクルに関する保証は尊重されます。 TTL秒はいつでもセット可能です。下記はJobの`.spec.ttlSecondsAfterFinished`フィールドのセットに関するいくつかの例です。 @@ -50,7 +50,7 @@ Kubernetesにおいてタイムスキューを避けるために、全てのNode ## {{% heading "whatsnext" %}} -[Jobの自動クリーンアップ](#終了したjobの自動クリーンアップ) +[Jobの自動クリーンアップ](/ja/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically) [設計ドキュメント](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0026-ttl-after-finish.md) From 6c1601c26e326579365c7941ab0e80288971e316 Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Sun, 30 Aug 2020 13:18:06 +0900 Subject: [PATCH 111/252] pulled job.md from master and added english heading title --- .../concepts/workloads/controllers/job.md | 387 ++++++++++++++++++ 1 file changed, 387 insertions(+) create mode 100644 content/ja/docs/concepts/workloads/controllers/job.md diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md new file mode 100644 index 0000000000..9bc827f5c4 --- /dev/null +++ b/content/ja/docs/concepts/workloads/controllers/job.md @@ -0,0 +1,387 @@ +--- +title: Job +content_type: concept +feature: + title: バッチ実行 + description: > + Kubernetesはサービスに加えて、バッチやCIのワークロードを管理し、必要に応じて失敗したコンテナを置き換えることができます。 +weight: 60 +--- + + + +Jobは1つ以上のPodを作成し、指定された数のPodが正常に終了することを保証します。 +JobはPodの正常終了を追跡します。正常終了が指定された回数に達すると、そのタスク(つまりJob)は完了します。Jobを削除すると、そのJobが作成したPodがクリーンアップされます。 + +簡単な例としては、1つのPodを確実に実行して完了させるために、1つのJobオブジェクトを作成することです。 +ノードのハードウェア障害やノードの再起動などにより最初のPodが失敗したり削除されたりした場合、Jobオブジェクトは新たなPodを立ち上げます。 + +また、Jobを使用して複数のPodを並行して実行することもできます。 + + + + + + +## Jobの実行例 + +ここでは、Jobの設定例を示します。πの値を2000桁目まで計算して出力します。 +完了までに10秒程度かかります。 + +{{< codenew file="controllers/job.yaml" >}} + +このコマンドで例を実行できます。 + +```shell +kubectl apply -f https://kubernetes.io/examples/controllers/job.yaml +``` +``` +job.batch/pi created +``` + +Jobのステータスは、`kubectl`を用いて確認します。 + +```shell +kubectl describe jobs/pi +``` +``` +Name: pi +Namespace: default +Selector: controller-uid=c9948307-e56d-4b5d-8302-ae2d7b7da67c +Labels: controller-uid=c9948307-e56d-4b5d-8302-ae2d7b7da67c + job-name=pi +Annotations: kubectl.kubernetes.io/last-applied-configuration: + {"apiVersion":"batch/v1","kind":"Job","metadata":{"annotations":{},"name":"pi","namespace":"default"},"spec":{"backoffLimit":4,"template":... +Parallelism: 1 +Completions: 1 +Start Time: Mon, 02 Dec 2019 15:20:11 +0200 +Completed At: Mon, 02 Dec 2019 15:21:16 +0200 +Duration: 65s +Pods Statuses: 0 Running / 1 Succeeded / 0 Failed +Pod Template: + Labels: controller-uid=c9948307-e56d-4b5d-8302-ae2d7b7da67c + job-name=pi + Containers: + pi: + Image: perl + Port: + Host Port: + Command: + perl + -Mbignum=bpi + -wle + print bpi(2000) + Environment: + Mounts: + Volumes: +Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal SuccessfulCreate 14m job-controller Created pod: pi-5rwd7 +``` + +Jobの完了したPodを表示するには、`kubectl get pods`を使います。 + +あるJobに属するすべてのPodの一覧を機械可読な形式で出力するには、次のようなコマンドを使います。 + +```shell +pods=$(kubectl get pods --selector=job-name=pi --output=jsonpath='{.items[*].metadata.name}') +echo $pods +``` +``` +pi-5rwd7 +``` + +ここでのセレクターは、Jobのセレクターと同じです。`--output=jsonpath`オプションは、返されたリストの各Podから名前だけを取得する式を指定します。 + + +いずれかのPodの標準出力を表示します。 + +```shell +kubectl logs $pods +``` +出力例は以下の通りです。 +```shell +3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679821480865132823066470938446095505822317253594081284811174502841027019385211055596446229489549303819644288109756659334461284756482337867831652712019091456485669234603486104543266482133936072602491412737245870066063155881748815209209628292540917153643678925903600113305305488204665213841469519415116094330572703657595919530921861173819326117931051185480744623799627495673518857527248912279381830119491298336733624406566430860213949463952247371907021798609437027705392171762931767523846748184676694051320005681271452635608277857713427577896091736371787214684409012249534301465495853710507922796892589235420199561121290219608640344181598136297747713099605187072113499999983729780499510597317328160963185950244594553469083026425223082533446850352619311881710100031378387528865875332083814206171776691473035982534904287554687311595628638823537875937519577818577805321712268066130019278766111959092164201989380952572010654858632788659361533818279682303019520353018529689957736225994138912497217752834791315155748572424541506959508295331168617278558890750983817546374649393192550604009277016711390098488240128583616035637076601047101819429555961989467678374494482553797747268471040475346462080466842590694912933136770289891521047521620569660240580381501935112533824300355876402474964732639141992726042699227967823547816360093417216412199245863150302861829745557067498385054945885869269956909272107975093029553211653449872027559602364806654991198818347977535663698074265425278625518184175746728909777727938000816470600161452491921732172147723501414419735685481613611573525521334757418494684385233239073941433345477624168625189835694855620992192221842725502542568876717904946016534668049886272327917860857843838279679766814541009538837863609506800642251252051173929848960841284886269456042419652850222106611863067442786220391949450471237137869609563643719172874677646575739624138908658326459958133904780275901 +``` + +## Jobの仕様の作成 + +他のすべてのKubernetesの設定と同様に、Jobには`apiVersion`、`kind`、および`metadata`フィールドが必要です。 +その名前は有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。 + +Jobには[`.spec`セクション](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)も必要です。 + +### Podテンプレート + +`.spec.template`は、`.spec`の唯一の必須フィールドです。 + +`.spec.template`は[Podテンプレート](/ja/docs/concepts/workloads/pods/#pod-templates)です。 +ネストされており、`apiVersion`や`kind`ないことを除けば、{{< glossary_tooltip text="Pod" term_id="pod" >}}とまったく同じスキーマを持ちます。 + +Podの必須フィールドに加えて、JobのPodテンプレートでは、適切なラベル([Podセレクター](#pod-selector)参照)と適切な再起動ポリシーを指定しなければなりません。 + +`Never`または`OnFailure`と等しい[`RestartPolicy`](/ja/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)のみが許可されます。 + +### Podセレクター {#pod-selector} + +`.spec.selector`フィールドはオプションです。ほとんどの場合、指定すべきではありません。 +セクション「[独自のPodセレクターの指定](#specifying-your-own-pod-selector)」を参照してください。 + + +### Jobの並列実行 {#parallel-jobs} + +Jobとして実行するのに適したタスクは、大きく分けて3つあります。 + +1. 非並列Job + - 通常は、Podが失敗しない限り、1つのPodのみが起動されます。 + - そのPodが正常に終了するとすぐにJobが完了します。 +2. *固定の完了数*を持つ並列Job + - `.spec.completions`に、0以外の正の値を指定します。 + - Jobはタスク全体を表し、1から`.spec.completions`の範囲内の各値に対して、1つの成功したPodがあれば完了です。 + - **まだ実装されていません**が、各Podには、1から`.spec.completions`の範囲内で異なるインデックスが渡されます。 +3. *ワークキュー*を持つ並列Job + - `.spec.completions`は指定しません。デフォルトは`.spec.parallelism`です。 + - Podは、それぞれが何を処理するか決定するために、 Pod間または外部サービス間で調整する必要があります。例えば、あるPodはワークキューから最大N個のアイテムのバッチを取得します。 + - 各Podはすべてのピアが完了したかどうか、つまりJob全体が完了したかどうかを、独立して判断できます。 + - Jobの _任意の_ Podが正常終了すると、新しいPodは作成されません。 + - 少なくとも1つのPodが正常終了し、すべてのPodが終了すると、Jobは正常に完了します。 + - Podが正常終了した後は、他のPodがこのタスクの処理を行ったり、出力を書き込んだりしてはなりません。それらはすべて終了する必要があります。 + +_非並列_ Jobの場合、`.spec.completions`と`.spec.parallelism`の両方を未設定のままにすることができます。両方が設定されていない場合、どちらもデフォルトで1になります。 + +_ワークキュー_ を持つJobの場合、`.spec.completions`を未設定のままにし、`.spec.parallelism`を非負整数にする必要があります。 + + +様々な種類のJobを利用する方法の詳細については、セクション「[Jobのパターン](#job-patterns)」をご覧ください。 + +#### 並列処理の制御 + +並列処理数(`.spec.parallelism`)については、任意の非負整数を設定できます。 +指定しない場合、デフォルトで1になります。 +0を指定した場合、並列処理数が増えるまで、Jobは実質的に一時停止されます。 + +以下に挙げる様々な理由から、実際の並列処理数(任意の時点で実行されるPodの数)が、要求された数より多い場合と少ない場合があります。 + +- _固定完了数_ を持つJobの場合、並行して実行されるPodの実際の数は、残りの完了数を超えることはありません。`.spec.parallelism`の大きい値は事実上無視されます。 +- _ワークキュー_ を持つJobの場合、Podが成功しても新しいPodは開始されません。ただし、残りのPodは完了できます。 +- Jobコントローラー({{< glossary_tooltip term_id="controller" >}})が反応する時間がない場合も考えられます。 +- Jobコントローラーが何らかの理由(`ResourceQuota`がない、権限がないなど)でPodの作成に失敗した場合、要求された数よりも少ないPod数になる可能性があります。 +- Jobコントローラーは、同じJob内で以前のPodが過剰に失敗したために、新しいPodの作成を調整する場合があります。 +- Podをグレースフルにシャットダウンした場合、停止までに時間がかかります。 + +## Podおよびコンテナの障害の処理 + +Pod内のコンテナは、その中のプロセスが0以外の終了コードで終了した、またはメモリー制限を超えたためにコンテナが強制終了されたなど、さまざまな理由で失敗する可能性があります。これが発生し、`.spec.template.spec.restartPolicy = "OnFailure"`であ場合、Podはノードに残りますが、コンテナは再実行されます。したがって、プログラムはローカルで再起動するケースを処理するか、`.spec.template.spec.restartPolicy = "Never"`を指定する必要があります。 +`restartPolicy`の詳細な情報は、[Podのライフサイクル](/ja/docs/concepts/workloads/pods/pod-lifecycle/#example-states)を参照してください。 + +さまざまな理由で、Pod全体が失敗することもあります。例えば、Podが(ノードのアップグレード、再起動、削除などにより)ノードから切り離された場合や、Podのコンテナが失敗して`.spec.template.spec.restartPolicy = "Never"`が設定されている場合などです。Podが失敗した場合、Jobコントローラーは新しいPodを開始します。つまり、アプリケーションは新しいPodで再起動されたケースを処理する必要があります。特に、前の実行によって発生した一時ファイル、ロック、不完全な出力などに対する処理が必要です。 + +たとえ`.spec.parallelism = 1`、`.spec.completions = 1`、`.spec.template.spec.restartPolicy = "Never"`を指定しても、同じプログラムが2回起動される場合があることに注意してください。 + +`.spec.parallelism`と`.spec.completions`の両方を1より大きい値に指定した場合は、複数のPodが同時に実行される可能性があります。したがって、Podは同時実行性にも対応する必要があります。 + +### Pod Backoff Failure Policy + +構成の論理エラーなどが原因で、ある程度の再試行後にJobを失敗させたい場合があります。 +そのためには、`.spec.backoffLimit`を設定して、Jobが失敗したと見なすまでの再試行回数を指定します。デフォルトでは6に設定されています。 +失敗したPodは、6分を上限とする指数バックオフ遅延(10秒、20秒、40秒...)に従って、Jobコントローラーにより再作成されます。 +JobのPodが削除されるか、Jobの他のPodがその時間に失敗することなく成功すると、バックオフカウントがリセットされます。 + +{{< note >}} +Jobに`restartPolicy = "OnFailure"`がある場合、Jobのバックオフ制限に達すると、Jobを実行しているコンテナが終了することに注意してください。これにより、Jobの実行可能ファイルのデバッグがより困難になる可能性があります。Jobのデバッグするまたはロギングシステムを使用する場合は、`restartPolicy = "Never"`を設定して、失敗したJobからの出力が誤って失われないようにすることをお勧めします。 +{{< /note >}} + +## Jobの終了とクリーンアップ + +Jobが完了すると、Podは作成されなくなりますが、Podの削除も行われません。それらを保持しておくと、完了したPodのログを表示して、エラー、警告、またはその他の診断の出力を確認できます。 +Jobオブジェクトは完了後も残るため、ステータスを表示できます。ステータスを確認した後、古いJobを削除するのはユーザーの責任です。`kubectl`(例えば`kubectl delete jobs/pi`や`kubectl delete -f ./job.yaml`)を用いてJobを削除してください。`kubectl`でJobを削除すると、Jobが作成したすべてのPodも削除されます。 + +デフォルトでは、Podが失敗する(`restartPolicy=Never`)かコンテナがエラーで終了する(`restartPolicy=OnFailure`)場合を除き、Jobは中断されずに実行されます。その時点でJobは上記の`.spec.backoffLimit`に従います。`.spec.backoffLimit`に達すると、Jobは失敗としてマークされ、実行中のPodはすべて終了されます。 + +Jobを終了する別の方法は、アクティブな期限を設定することです。 +これを行うには、Jobの`.spec.activeDeadlineSeconds`フィールドを秒数に設定します +`activeDeadlineSeconds`は、作成されたPodの数に関係なく、Jobの期間に適用されます。 +Jobが`activeDeadlineSeconds`に到達すると、実行中のすべてのPodが終了し、Jobのステータスは`type: Failed`および`reason: DeadlineExceeded`となります。 + +Jobの`.spec.activeDeadlineSeconds`は、`.spec.backoffLimit`よりも優先されることに注意してください。したがって、1つ以上の失敗したPodを再試行しているJobは、`backoffLimit`にまだ達していない場合でも、`activeDeadlineSeconds`で指定された制限時間に達すると、追加のPodをデプロイしません。 + +以下に例を挙げます。 + +```yaml +apiVersion: batch/v1 +kind: Job +metadata: + name: pi-with-timeout +spec: + backoffLimit: 5 + activeDeadlineSeconds: 100 + template: + spec: + containers: + - name: pi + image: perl + command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"] + restartPolicy: Never +``` + +Job内のJobの仕様と[Podテンプレートの仕様](/ja/docs/concepts/workloads/pods/init-containers/#detailed-behavior)の両方に`activeDeadlineSeconds`フィールドがあることに注意してください。このフィールドが適切なレベルに設定されていることを確認してください。 + +`restartPolicy`はPodに適用され、Job自体には適用されないことに注意してください。Jobのステータスが`type: Failed`になると、Jobの自動再起動は行われません。 +つまり、 `.spec.activeDeadlineSeconds`と`.spec.backoffLimit`でアクティブ化されるJob終了のメカニズムは、手作業での介入が必要になるような永続的なJobの失敗を引き起こします。 + +## 終了したJobの自動クリーンアップ {#clean-up-finished-jobs-automatically} + +終了したJobは、通常、もう必要ありません。それらをシステム内に保持すると、APIサーバーに負担がかかります。[CronJobs](/ja/docs/concepts/workloads/controllers/cron-jobs/)などの上位レベルのコントローラーによってJobが直接管理されている場合、指定された容量ベースのクリーンアップポリシーに基づいて、JobをCronJobsでクリーンアップできます。 + +### 終了したJobのTTLメカニズム + +{{< feature-state for_k8s_version="v1.12" state="alpha" >}} + +完了したJob(`Complete`または`Failed`)を自動的にクリーンアップする別の方法は、[TTLコントローラー](/ja/docs/concepts/workloads/controllers/ttlafterfinished/)が提供するTTLメカニズムを使用して、完了したリソースを指定することです。Jobの`.spec.ttlSecondsAfterFinished`フィールドに指定します。 + +TTLコントローラーがJobをクリーンアップすると、Jobが連鎖的に削除されます。つまり、Podなどの依存オブジェクトがJobとともに削除されます。Jobが削除されるとき、ファイナライザーなどのライフサイクル保証が優先されることに注意してください。 + +例は以下の通りです。 + +```yaml +apiVersion: batch/v1 +kind: Job +metadata: + name: pi-with-ttl +spec: + ttlSecondsAfterFinished: 100 + template: + spec: + containers: + - name: pi + image: perl + command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"] + restartPolicy: Never +``` + +Job`pi-with-ttl`は、Jobが終了してから`100`秒後に自動的に削除される。 + +フィールドが`0`に設定されている場合は、Jobは終了後すぐに自動的に削除されます。フィールドが設定されていない場合は、このJobは終了後にTTLコントローラーによってクリーンアップされません。 + +このTTLメカニズムはアルファ版であり、`TTLAfterFinished`フィーチャーゲートであることに注意してください。詳細は[TTLコントローラー](/ja/docs/concepts/workloads/controllers/ttlafterfinished/)のドキュメントを参照してください。 + +## Jobのパターン {#job-patterns} + +Jobオブジェクトは、Podの信頼性の高い並列実行をサポートするために使用できます。Jobオブジェクトは、科学的コンピューティングで一般的に見られるような、密接に通信する並列プロセスをサポートするようには設計されていません。しかし、独立しているが関連性のある*ワークアイテム*の集合の並列処理はサポートしています。 + +例えば送信する電子メール、レンダリングするフレーム、トランスコードするファイル、スキャンするNoSQLデータベースのキーの範囲などです。 + +複雑なシステムでは、複数の異なるワークアイテムの集合があるかもしれません。ここでは、ユーザーがまとめて管理したい作業項目の1つの集合(バッチJob)を考えています。 + +並列計算にはいくつかのパターンがあり、それぞれ長所と短所があります。 +トレードオフは以下の通りです。 + +- 各ワークアイテムに1つのJobオブジェクトを使用する場合と、すべてのワークアイテムに1つのJobオブジェクトを使用する場合を比較すると、後者の方がワークアイテムの数が多い場合に適しています。前者では、ユーザーとシステムが大量のJobオブジェクトを管理するためのオーバーヘッドが発生します。 +- 作成されたPodの数がワークアイテムの数に等しい場合と、各Podが複数のワークアイテムを処理する場合を比較すると、前者の方が一般的に既存のコードやコンテナへの変更が少ないです。後者は上記の項目と同様の理由で、大量のワークアイテムを処理するのに適しています。 +- いくつかのアプローチでは、ワークキューを使用します。これはキューサービスを実行している必要があり、既存のプログラムやコンテナを変更してワークキューを使用するようにする必要があります。他のアプローチは、既存のコンテナ化されたアプリケーションに適応するのがさらに容易です。 + +ここでは、上記のトレードオフに対応するものを、2から4列目にまとめています。 +パターン名は、例とより詳細な説明へのリンクでもあります。 + +| パターン名 | 単一のJobオブジェクト | ワークアイテムよりPodが少ないか？ | アプリをそのまま使用するか？ | Kube 1.1で動作するか？ | +| ----------------------------------------------------------------------------------------------- |:-----------------:|:---------------------------:|:-------------------:|:-------------------:| +| [Jobテンプレートを拡張する](/ja/docs/tasks/job/parallel-processing-expansion/) | | | ✓ | ✓ | +| [ワークアイテムごとにPodでキューを作成する](/ja/docs/tasks/job/coarse-parallel-processing-work-queue/) | ✓ | | 場合による | ✓ | +| [Pod数が可変であるキューを作成する](/ja/docs/tasks/job/fine-parallel-processing-work-queue/) | ✓ | ✓ | | ✓ | +| 単一のJob静的な処理を割り当てる | ✓ | | ✓ | | + +完了数を`.spec.completions`で指定すると、Jobコントローラーが作成した各Podは同じ[`spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)を持ちます。つまり、あるタスクを実行するすべてのPodは、同じコマンドラインと同じイメージ、同じボリューム、そして(ほぼ)同じ環境変数を持ちます。これらのパターンは、Podが異なる処理を行うように配置するための様々な方法です。 + +以下の表では、パターンごとに必要な`.spec.parallelism`と`.spec.completions`の設定を示します。 +ここで、`W`はワークアイテム数とします。 + +| パターン名 | `.spec.completions` | `.spec.parallelism` | +| ----------------------------------------------------------------------------------------------- |:-------------------:|:--------------------:| +| [Jobテンプレートを拡張する](/ja/docs/tasks/job/parallel-processing-expansion/) | 1 | 1とする必要あり | +| [ワークアイテムごとにPodでキューを作成する](/ja/docs/tasks/job/coarse-parallel-processing-work-queue/) | W | 任意 | +| [Pod数が可変であるキューを作成する](/ja/docs/tasks/job/fine-parallel-processing-work-queue/) | 1 | 任意 | +| 単一のJob静的な処理を割り当てる | W | 任意 | + + +## 高度な使用方法 + +### 独自のPodセレクターを指定する {#specifying-your-own-pod-selector} + +通常、Jobオブジェクトを作成する際には`.spec.selector`を指定しません。 +システムのデフォルトのロジックで、Jobの作成時にこのフィールドを追加します。 +セレクターの値は、他のJobと重複しないように選択されます。 + +しかし、場合によっては、この自動的に設定されるセレクターを上書きする必要があるかもしれません。 +これを行うには、Jobの`.spec.selector`を指定します。 + +これを行う際には十分に注意が必要です。もし指定したラベルセレクターが、そのJobのPodに対して固有でなく、無関係なPodにマッチする場合、無関係なJobのPodが削除されたり、このJobが他のPodを完了したものとしてカウントしたり、一方または両方のJobがPodの作成や完了まで実行を拒否することがあります。 +もし固有でないセレクターを選択した場合は、他のコントローラー(例えばレプリケーションコントローラーなど)やそのPodも予測不能な動作をする可能性があります。Kubernetesは`.spec.selector`を指定する際のミスを防ぐことはできません。 + +ここでは、この機能を使いたくなるようなケースの例をご紹介します。 +`old`というJobがすでに実行されているとします。既存のPodを実行し続けたいが、作成した残りのPodには別のPodテンプレートを使用し、Jobには新しい名前を付けたいとします。 +これらのフィールドは更新が不可能であるため、Jobを更新することはできません。 +そのため、`kubectl delete jobs/old --cascade=false`を使って、`old`というJobを削除し、一方で _そのPodは実行したまま_ にします。 +削除する前に、どのセレクターを使っているかメモしておきます。 + +``` +kubectl get job old -o yaml +``` +``` +kind: Job +metadata: + name: old + ... +spec: + selector: + matchLabels: + controller-uid: a8f3d00d-c6d2-11e5-9f87-42010af00002 + ... +``` +次に`new`という名前の新しいJobを作成し、同じセレクターを明示的に指定します。 +既存のPodには`controller-uid=a8f3d00d-c6d2-11e5-9f87-42010af00002`というラベルが付いているので、それらも同様にJob`new`で制御されます。 + +システムが自動的に生成するセレクターを使用していないので、新しいJobでは`manualSelector: true`を指定する必要があります。 + +``` +kind: Job +metadata: + name: new + ... +spec: + manualSelector: true + selector: + matchLabels: + controller-uid: a8f3d00d-c6d2-11e5-9f87-42010af00002 + ... +``` + +新しいJob自体は`a8f3d00d-c6d2-11e5-9f87-42010af00002`とは異なるuidを持つでしょう。 +`manualSelector: true`を設定すると、あなたが何をしているかを知っていることをシステムに伝え、この不一致を許容するようにします。 + +## 代替案 + +### ベアPod + +Podが実行されているノードが再起動したり障害が発生したりすると、Podは終了し、再起動されません。しかし、Jobは終了したPodを置き換えるために新しいPodを作成します。 +このため、アプリケーションが単一のPodしか必要としない場合でも、ベアPodではなくJobを使用することをお勧めします。 + +### レプリケーションコントローラー + +Jobは[レプリケーションコントローラー](/ja/docs/user-guide/replication-controller)を補完するものです。 +レプリケーションコントローラーは終了が予想されないPod(例えばWebサーバー)を管理し、Jobは終了が予想されるPod(例えばバッチタスク)を管理します。 + +[Podのライフサイクル](/ja/docs/concepts/workloads/pods/pod-lifecycle/)で説明したように、`Job`は`RestartPolicy`が`OnFailure`または`Never`と等しいPodに対して*のみ*適切です。 +(注意: `RestartPolicy`が設定されていない場合、デフォルト値は`Always`です。) + +### 単一のJobでコントローラーPodを起動 + +もう一つのパターンは、単一のJobでPodを作成し、そのPodが他のPodを作成し、それらのPodに対するカスタムコントローラーのように動作するというものです。これは最も柔軟性がありますが、始めるのがやや複雑で、Kubernetesとの統合性が低いかもしれません。 + +このパターンの例として、Podを起動してスクリプトを実行するJobがSparkマスターコントローラー([Sparkの例](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/spark/README.md)を参照)を起動し、Sparkドライバーを実行してからクリーンアップするというものがあります。 + +このアプローチの利点は、全体的なプロセスがJobオブジェクトが完了する保証を得ながらも、どのようなPodが作成され、どのように作業が割り当てられるかを完全に制御できることです。 + +## Cron Job {#cron-jobs} + +Unixのツールである`cron`と同様に、指定した日時に実行されるJobを作成するために、[`CronJob`](/ja/docs/concepts/workloads/controllers/cron-jobs/)を使用することができます。 From 3f20b116b1e61b09b1de9b82527082af97a9ac1f Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Sun, 30 Aug 2020 13:49:27 +0900 Subject: [PATCH 112/252] Revert "pulled job.md from master and added english heading title" This reverts commit 1756223848ce5a10ce8a2d90df6a5fd8e90cc61b. --- .../concepts/workloads/controllers/job.md | 387 ------------------ 1 file changed, 387 deletions(-) delete mode 100644 content/ja/docs/concepts/workloads/controllers/job.md diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md deleted file mode 100644 index 9bc827f5c4..0000000000 --- a/content/ja/docs/concepts/workloads/controllers/job.md +++ /dev/null @@ -1,387 +0,0 @@ ---- -title: Job -content_type: concept -feature: - title: バッチ実行 - description: > - Kubernetesはサービスに加えて、バッチやCIのワークロードを管理し、必要に応じて失敗したコンテナを置き換えることができます。 -weight: 60 ---- - - - -Jobは1つ以上のPodを作成し、指定された数のPodが正常に終了することを保証します。 -JobはPodの正常終了を追跡します。正常終了が指定された回数に達すると、そのタスク(つまりJob)は完了します。Jobを削除すると、そのJobが作成したPodがクリーンアップされます。 - -簡単な例としては、1つのPodを確実に実行して完了させるために、1つのJobオブジェクトを作成することです。 -ノードのハードウェア障害やノードの再起動などにより最初のPodが失敗したり削除されたりした場合、Jobオブジェクトは新たなPodを立ち上げます。 - -また、Jobを使用して複数のPodを並行して実行することもできます。 - - - - - - -## Jobの実行例 - -ここでは、Jobの設定例を示します。πの値を2000桁目まで計算して出力します。 -完了までに10秒程度かかります。 - -{{< codenew file="controllers/job.yaml" >}} - -このコマンドで例を実行できます。 - -```shell -kubectl apply -f https://kubernetes.io/examples/controllers/job.yaml -``` -``` -job.batch/pi created -``` - -Jobのステータスは、`kubectl`を用いて確認します。 - -```shell -kubectl describe jobs/pi -``` -``` -Name: pi -Namespace: default -Selector: controller-uid=c9948307-e56d-4b5d-8302-ae2d7b7da67c -Labels: controller-uid=c9948307-e56d-4b5d-8302-ae2d7b7da67c - job-name=pi -Annotations: kubectl.kubernetes.io/last-applied-configuration: - {"apiVersion":"batch/v1","kind":"Job","metadata":{"annotations":{},"name":"pi","namespace":"default"},"spec":{"backoffLimit":4,"template":... -Parallelism: 1 -Completions: 1 -Start Time: Mon, 02 Dec 2019 15:20:11 +0200 -Completed At: Mon, 02 Dec 2019 15:21:16 +0200 -Duration: 65s -Pods Statuses: 0 Running / 1 Succeeded / 0 Failed -Pod Template: - Labels: controller-uid=c9948307-e56d-4b5d-8302-ae2d7b7da67c - job-name=pi - Containers: - pi: - Image: perl - Port: - Host Port: - Command: - perl - -Mbignum=bpi - -wle - print bpi(2000) - Environment: - Mounts: - Volumes: -Events: - Type Reason Age From Message - ---- ------ ---- ---- ------- - Normal SuccessfulCreate 14m job-controller Created pod: pi-5rwd7 -``` - -Jobの完了したPodを表示するには、`kubectl get pods`を使います。 - -あるJobに属するすべてのPodの一覧を機械可読な形式で出力するには、次のようなコマンドを使います。 - -```shell -pods=$(kubectl get pods --selector=job-name=pi --output=jsonpath='{.items[*].metadata.name}') -echo $pods -``` -``` -pi-5rwd7 -``` - -ここでのセレクターは、Jobのセレクターと同じです。`--output=jsonpath`オプションは、返されたリストの各Podから名前だけを取得する式を指定します。 - - -いずれかのPodの標準出力を表示します。 - -```shell -kubectl logs $pods -``` -出力例は以下の通りです。 -```shell -3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679821480865132823066470938446095505822317253594081284811174502841027019385211055596446229489549303819644288109756659334461284756482337867831652712019091456485669234603486104543266482133936072602491412737245870066063155881748815209209628292540917153643678925903600113305305488204665213841469519415116094330572703657595919530921861173819326117931051185480744623799627495673518857527248912279381830119491298336733624406566430860213949463952247371907021798609437027705392171762931767523846748184676694051320005681271452635608277857713427577896091736371787214684409012249534301465495853710507922796892589235420199561121290219608640344181598136297747713099605187072113499999983729780499510597317328160963185950244594553469083026425223082533446850352619311881710100031378387528865875332083814206171776691473035982534904287554687311595628638823537875937519577818577805321712268066130019278766111959092164201989380952572010654858632788659361533818279682303019520353018529689957736225994138912497217752834791315155748572424541506959508295331168617278558890750983817546374649393192550604009277016711390098488240128583616035637076601047101819429555961989467678374494482553797747268471040475346462080466842590694912933136770289891521047521620569660240580381501935112533824300355876402474964732639141992726042699227967823547816360093417216412199245863150302861829745557067498385054945885869269956909272107975093029553211653449872027559602364806654991198818347977535663698074265425278625518184175746728909777727938000816470600161452491921732172147723501414419735685481613611573525521334757418494684385233239073941433345477624168625189835694855620992192221842725502542568876717904946016534668049886272327917860857843838279679766814541009538837863609506800642251252051173929848960841284886269456042419652850222106611863067442786220391949450471237137869609563643719172874677646575739624138908658326459958133904780275901 -``` - -## Jobの仕様の作成 - -他のすべてのKubernetesの設定と同様に、Jobには`apiVersion`、`kind`、および`metadata`フィールドが必要です。 -その名前は有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。 - -Jobには[`.spec`セクション](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)も必要です。 - -### Podテンプレート - -`.spec.template`は、`.spec`の唯一の必須フィールドです。 - -`.spec.template`は[Podテンプレート](/ja/docs/concepts/workloads/pods/#pod-templates)です。 -ネストされており、`apiVersion`や`kind`ないことを除けば、{{< glossary_tooltip text="Pod" term_id="pod" >}}とまったく同じスキーマを持ちます。 - -Podの必須フィールドに加えて、JobのPodテンプレートでは、適切なラベル([Podセレクター](#pod-selector)参照)と適切な再起動ポリシーを指定しなければなりません。 - -`Never`または`OnFailure`と等しい[`RestartPolicy`](/ja/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)のみが許可されます。 - -### Podセレクター {#pod-selector} - -`.spec.selector`フィールドはオプションです。ほとんどの場合、指定すべきではありません。 -セクション「[独自のPodセレクターの指定](#specifying-your-own-pod-selector)」を参照してください。 - - -### Jobの並列実行 {#parallel-jobs} - -Jobとして実行するのに適したタスクは、大きく分けて3つあります。 - -1. 非並列Job - - 通常は、Podが失敗しない限り、1つのPodのみが起動されます。 - - そのPodが正常に終了するとすぐにJobが完了します。 -2. *固定の完了数*を持つ並列Job - - `.spec.completions`に、0以外の正の値を指定します。 - - Jobはタスク全体を表し、1から`.spec.completions`の範囲内の各値に対して、1つの成功したPodがあれば完了です。 - - **まだ実装されていません**が、各Podには、1から`.spec.completions`の範囲内で異なるインデックスが渡されます。 -3. *ワークキュー*を持つ並列Job - - `.spec.completions`は指定しません。デフォルトは`.spec.parallelism`です。 - - Podは、それぞれが何を処理するか決定するために、 Pod間または外部サービス間で調整する必要があります。例えば、あるPodはワークキューから最大N個のアイテムのバッチを取得します。 - - 各Podはすべてのピアが完了したかどうか、つまりJob全体が完了したかどうかを、独立して判断できます。 - - Jobの _任意の_ Podが正常終了すると、新しいPodは作成されません。 - - 少なくとも1つのPodが正常終了し、すべてのPodが終了すると、Jobは正常に完了します。 - - Podが正常終了した後は、他のPodがこのタスクの処理を行ったり、出力を書き込んだりしてはなりません。それらはすべて終了する必要があります。 - -_非並列_ Jobの場合、`.spec.completions`と`.spec.parallelism`の両方を未設定のままにすることができます。両方が設定されていない場合、どちらもデフォルトで1になります。 - -_ワークキュー_ を持つJobの場合、`.spec.completions`を未設定のままにし、`.spec.parallelism`を非負整数にする必要があります。 - - -様々な種類のJobを利用する方法の詳細については、セクション「[Jobのパターン](#job-patterns)」をご覧ください。 - -#### 並列処理の制御 - -並列処理数(`.spec.parallelism`)については、任意の非負整数を設定できます。 -指定しない場合、デフォルトで1になります。 -0を指定した場合、並列処理数が増えるまで、Jobは実質的に一時停止されます。 - -以下に挙げる様々な理由から、実際の並列処理数(任意の時点で実行されるPodの数)が、要求された数より多い場合と少ない場合があります。 - -- _固定完了数_ を持つJobの場合、並行して実行されるPodの実際の数は、残りの完了数を超えることはありません。`.spec.parallelism`の大きい値は事実上無視されます。 -- _ワークキュー_ を持つJobの場合、Podが成功しても新しいPodは開始されません。ただし、残りのPodは完了できます。 -- Jobコントローラー({{< glossary_tooltip term_id="controller" >}})が反応する時間がない場合も考えられます。 -- Jobコントローラーが何らかの理由(`ResourceQuota`がない、権限がないなど)でPodの作成に失敗した場合、要求された数よりも少ないPod数になる可能性があります。 -- Jobコントローラーは、同じJob内で以前のPodが過剰に失敗したために、新しいPodの作成を調整する場合があります。 -- Podをグレースフルにシャットダウンした場合、停止までに時間がかかります。 - -## Podおよびコンテナの障害の処理 - -Pod内のコンテナは、その中のプロセスが0以外の終了コードで終了した、またはメモリー制限を超えたためにコンテナが強制終了されたなど、さまざまな理由で失敗する可能性があります。これが発生し、`.spec.template.spec.restartPolicy = "OnFailure"`であ場合、Podはノードに残りますが、コンテナは再実行されます。したがって、プログラムはローカルで再起動するケースを処理するか、`.spec.template.spec.restartPolicy = "Never"`を指定する必要があります。 -`restartPolicy`の詳細な情報は、[Podのライフサイクル](/ja/docs/concepts/workloads/pods/pod-lifecycle/#example-states)を参照してください。 - -さまざまな理由で、Pod全体が失敗することもあります。例えば、Podが(ノードのアップグレード、再起動、削除などにより)ノードから切り離された場合や、Podのコンテナが失敗して`.spec.template.spec.restartPolicy = "Never"`が設定されている場合などです。Podが失敗した場合、Jobコントローラーは新しいPodを開始します。つまり、アプリケーションは新しいPodで再起動されたケースを処理する必要があります。特に、前の実行によって発生した一時ファイル、ロック、不完全な出力などに対する処理が必要です。 - -たとえ`.spec.parallelism = 1`、`.spec.completions = 1`、`.spec.template.spec.restartPolicy = "Never"`を指定しても、同じプログラムが2回起動される場合があることに注意してください。 - -`.spec.parallelism`と`.spec.completions`の両方を1より大きい値に指定した場合は、複数のPodが同時に実行される可能性があります。したがって、Podは同時実行性にも対応する必要があります。 - -### Pod Backoff Failure Policy - -構成の論理エラーなどが原因で、ある程度の再試行後にJobを失敗させたい場合があります。 -そのためには、`.spec.backoffLimit`を設定して、Jobが失敗したと見なすまでの再試行回数を指定します。デフォルトでは6に設定されています。 -失敗したPodは、6分を上限とする指数バックオフ遅延(10秒、20秒、40秒...)に従って、Jobコントローラーにより再作成されます。 -JobのPodが削除されるか、Jobの他のPodがその時間に失敗することなく成功すると、バックオフカウントがリセットされます。 - -{{< note >}} -Jobに`restartPolicy = "OnFailure"`がある場合、Jobのバックオフ制限に達すると、Jobを実行しているコンテナが終了することに注意してください。これにより、Jobの実行可能ファイルのデバッグがより困難になる可能性があります。Jobのデバッグするまたはロギングシステムを使用する場合は、`restartPolicy = "Never"`を設定して、失敗したJobからの出力が誤って失われないようにすることをお勧めします。 -{{< /note >}} - -## Jobの終了とクリーンアップ - -Jobが完了すると、Podは作成されなくなりますが、Podの削除も行われません。それらを保持しておくと、完了したPodのログを表示して、エラー、警告、またはその他の診断の出力を確認できます。 -Jobオブジェクトは完了後も残るため、ステータスを表示できます。ステータスを確認した後、古いJobを削除するのはユーザーの責任です。`kubectl`(例えば`kubectl delete jobs/pi`や`kubectl delete -f ./job.yaml`)を用いてJobを削除してください。`kubectl`でJobを削除すると、Jobが作成したすべてのPodも削除されます。 - -デフォルトでは、Podが失敗する(`restartPolicy=Never`)かコンテナがエラーで終了する(`restartPolicy=OnFailure`)場合を除き、Jobは中断されずに実行されます。その時点でJobは上記の`.spec.backoffLimit`に従います。`.spec.backoffLimit`に達すると、Jobは失敗としてマークされ、実行中のPodはすべて終了されます。 - -Jobを終了する別の方法は、アクティブな期限を設定することです。 -これを行うには、Jobの`.spec.activeDeadlineSeconds`フィールドを秒数に設定します -`activeDeadlineSeconds`は、作成されたPodの数に関係なく、Jobの期間に適用されます。 -Jobが`activeDeadlineSeconds`に到達すると、実行中のすべてのPodが終了し、Jobのステータスは`type: Failed`および`reason: DeadlineExceeded`となります。 - -Jobの`.spec.activeDeadlineSeconds`は、`.spec.backoffLimit`よりも優先されることに注意してください。したがって、1つ以上の失敗したPodを再試行しているJobは、`backoffLimit`にまだ達していない場合でも、`activeDeadlineSeconds`で指定された制限時間に達すると、追加のPodをデプロイしません。 - -以下に例を挙げます。 - -```yaml -apiVersion: batch/v1 -kind: Job -metadata: - name: pi-with-timeout -spec: - backoffLimit: 5 - activeDeadlineSeconds: 100 - template: - spec: - containers: - - name: pi - image: perl - command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"] - restartPolicy: Never -``` - -Job内のJobの仕様と[Podテンプレートの仕様](/ja/docs/concepts/workloads/pods/init-containers/#detailed-behavior)の両方に`activeDeadlineSeconds`フィールドがあることに注意してください。このフィールドが適切なレベルに設定されていることを確認してください。 - -`restartPolicy`はPodに適用され、Job自体には適用されないことに注意してください。Jobのステータスが`type: Failed`になると、Jobの自動再起動は行われません。 -つまり、 `.spec.activeDeadlineSeconds`と`.spec.backoffLimit`でアクティブ化されるJob終了のメカニズムは、手作業での介入が必要になるような永続的なJobの失敗を引き起こします。 - -## 終了したJobの自動クリーンアップ {#clean-up-finished-jobs-automatically} - -終了したJobは、通常、もう必要ありません。それらをシステム内に保持すると、APIサーバーに負担がかかります。[CronJobs](/ja/docs/concepts/workloads/controllers/cron-jobs/)などの上位レベルのコントローラーによってJobが直接管理されている場合、指定された容量ベースのクリーンアップポリシーに基づいて、JobをCronJobsでクリーンアップできます。 - -### 終了したJobのTTLメカニズム - -{{< feature-state for_k8s_version="v1.12" state="alpha" >}} - -完了したJob(`Complete`または`Failed`)を自動的にクリーンアップする別の方法は、[TTLコントローラー](/ja/docs/concepts/workloads/controllers/ttlafterfinished/)が提供するTTLメカニズムを使用して、完了したリソースを指定することです。Jobの`.spec.ttlSecondsAfterFinished`フィールドに指定します。 - -TTLコントローラーがJobをクリーンアップすると、Jobが連鎖的に削除されます。つまり、Podなどの依存オブジェクトがJobとともに削除されます。Jobが削除されるとき、ファイナライザーなどのライフサイクル保証が優先されることに注意してください。 - -例は以下の通りです。 - -```yaml -apiVersion: batch/v1 -kind: Job -metadata: - name: pi-with-ttl -spec: - ttlSecondsAfterFinished: 100 - template: - spec: - containers: - - name: pi - image: perl - command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"] - restartPolicy: Never -``` - -Job`pi-with-ttl`は、Jobが終了してから`100`秒後に自動的に削除される。 - -フィールドが`0`に設定されている場合は、Jobは終了後すぐに自動的に削除されます。フィールドが設定されていない場合は、このJobは終了後にTTLコントローラーによってクリーンアップされません。 - -このTTLメカニズムはアルファ版であり、`TTLAfterFinished`フィーチャーゲートであることに注意してください。詳細は[TTLコントローラー](/ja/docs/concepts/workloads/controllers/ttlafterfinished/)のドキュメントを参照してください。 - -## Jobのパターン {#job-patterns} - -Jobオブジェクトは、Podの信頼性の高い並列実行をサポートするために使用できます。Jobオブジェクトは、科学的コンピューティングで一般的に見られるような、密接に通信する並列プロセスをサポートするようには設計されていません。しかし、独立しているが関連性のある*ワークアイテム*の集合の並列処理はサポートしています。 - -例えば送信する電子メール、レンダリングするフレーム、トランスコードするファイル、スキャンするNoSQLデータベースのキーの範囲などです。 - -複雑なシステムでは、複数の異なるワークアイテムの集合があるかもしれません。ここでは、ユーザーがまとめて管理したい作業項目の1つの集合(バッチJob)を考えています。 - -並列計算にはいくつかのパターンがあり、それぞれ長所と短所があります。 -トレードオフは以下の通りです。 - -- 各ワークアイテムに1つのJobオブジェクトを使用する場合と、すべてのワークアイテムに1つのJobオブジェクトを使用する場合を比較すると、後者の方がワークアイテムの数が多い場合に適しています。前者では、ユーザーとシステムが大量のJobオブジェクトを管理するためのオーバーヘッドが発生します。 -- 作成されたPodの数がワークアイテムの数に等しい場合と、各Podが複数のワークアイテムを処理する場合を比較すると、前者の方が一般的に既存のコードやコンテナへの変更が少ないです。後者は上記の項目と同様の理由で、大量のワークアイテムを処理するのに適しています。 -- いくつかのアプローチでは、ワークキューを使用します。これはキューサービスを実行している必要があり、既存のプログラムやコンテナを変更してワークキューを使用するようにする必要があります。他のアプローチは、既存のコンテナ化されたアプリケーションに適応するのがさらに容易です。 - -ここでは、上記のトレードオフに対応するものを、2から4列目にまとめています。 -パターン名は、例とより詳細な説明へのリンクでもあります。 - -| パターン名 | 単一のJobオブジェクト | ワークアイテムよりPodが少ないか？ | アプリをそのまま使用するか？ | Kube 1.1で動作するか？ | -| ----------------------------------------------------------------------------------------------- |:-----------------:|:---------------------------:|:-------------------:|:-------------------:| -| [Jobテンプレートを拡張する](/ja/docs/tasks/job/parallel-processing-expansion/) | | | ✓ | ✓ | -| [ワークアイテムごとにPodでキューを作成する](/ja/docs/tasks/job/coarse-parallel-processing-work-queue/) | ✓ | | 場合による | ✓ | -| [Pod数が可変であるキューを作成する](/ja/docs/tasks/job/fine-parallel-processing-work-queue/) | ✓ | ✓ | | ✓ | -| 単一のJob静的な処理を割り当てる | ✓ | | ✓ | | - -完了数を`.spec.completions`で指定すると、Jobコントローラーが作成した各Podは同じ[`spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)を持ちます。つまり、あるタスクを実行するすべてのPodは、同じコマンドラインと同じイメージ、同じボリューム、そして(ほぼ)同じ環境変数を持ちます。これらのパターンは、Podが異なる処理を行うように配置するための様々な方法です。 - -以下の表では、パターンごとに必要な`.spec.parallelism`と`.spec.completions`の設定を示します。 -ここで、`W`はワークアイテム数とします。 - -| パターン名 | `.spec.completions` | `.spec.parallelism` | -| ----------------------------------------------------------------------------------------------- |:-------------------:|:--------------------:| -| [Jobテンプレートを拡張する](/ja/docs/tasks/job/parallel-processing-expansion/) | 1 | 1とする必要あり | -| [ワークアイテムごとにPodでキューを作成する](/ja/docs/tasks/job/coarse-parallel-processing-work-queue/) | W | 任意 | -| [Pod数が可変であるキューを作成する](/ja/docs/tasks/job/fine-parallel-processing-work-queue/) | 1 | 任意 | -| 単一のJob静的な処理を割り当てる | W | 任意 | - - -## 高度な使用方法 - -### 独自のPodセレクターを指定する {#specifying-your-own-pod-selector} - -通常、Jobオブジェクトを作成する際には`.spec.selector`を指定しません。 -システムのデフォルトのロジックで、Jobの作成時にこのフィールドを追加します。 -セレクターの値は、他のJobと重複しないように選択されます。 - -しかし、場合によっては、この自動的に設定されるセレクターを上書きする必要があるかもしれません。 -これを行うには、Jobの`.spec.selector`を指定します。 - -これを行う際には十分に注意が必要です。もし指定したラベルセレクターが、そのJobのPodに対して固有でなく、無関係なPodにマッチする場合、無関係なJobのPodが削除されたり、このJobが他のPodを完了したものとしてカウントしたり、一方または両方のJobがPodの作成や完了まで実行を拒否することがあります。 -もし固有でないセレクターを選択した場合は、他のコントローラー(例えばレプリケーションコントローラーなど)やそのPodも予測不能な動作をする可能性があります。Kubernetesは`.spec.selector`を指定する際のミスを防ぐことはできません。 - -ここでは、この機能を使いたくなるようなケースの例をご紹介します。 -`old`というJobがすでに実行されているとします。既存のPodを実行し続けたいが、作成した残りのPodには別のPodテンプレートを使用し、Jobには新しい名前を付けたいとします。 -これらのフィールドは更新が不可能であるため、Jobを更新することはできません。 -そのため、`kubectl delete jobs/old --cascade=false`を使って、`old`というJobを削除し、一方で _そのPodは実行したまま_ にします。 -削除する前に、どのセレクターを使っているかメモしておきます。 - -``` -kubectl get job old -o yaml -``` -``` -kind: Job -metadata: - name: old - ... -spec: - selector: - matchLabels: - controller-uid: a8f3d00d-c6d2-11e5-9f87-42010af00002 - ... -``` -次に`new`という名前の新しいJobを作成し、同じセレクターを明示的に指定します。 -既存のPodには`controller-uid=a8f3d00d-c6d2-11e5-9f87-42010af00002`というラベルが付いているので、それらも同様にJob`new`で制御されます。 - -システムが自動的に生成するセレクターを使用していないので、新しいJobでは`manualSelector: true`を指定する必要があります。 - -``` -kind: Job -metadata: - name: new - ... -spec: - manualSelector: true - selector: - matchLabels: - controller-uid: a8f3d00d-c6d2-11e5-9f87-42010af00002 - ... -``` - -新しいJob自体は`a8f3d00d-c6d2-11e5-9f87-42010af00002`とは異なるuidを持つでしょう。 -`manualSelector: true`を設定すると、あなたが何をしているかを知っていることをシステムに伝え、この不一致を許容するようにします。 - -## 代替案 - -### ベアPod - -Podが実行されているノードが再起動したり障害が発生したりすると、Podは終了し、再起動されません。しかし、Jobは終了したPodを置き換えるために新しいPodを作成します。 -このため、アプリケーションが単一のPodしか必要としない場合でも、ベアPodではなくJobを使用することをお勧めします。 - -### レプリケーションコントローラー - -Jobは[レプリケーションコントローラー](/ja/docs/user-guide/replication-controller)を補完するものです。 -レプリケーションコントローラーは終了が予想されないPod(例えばWebサーバー)を管理し、Jobは終了が予想されるPod(例えばバッチタスク)を管理します。 - -[Podのライフサイクル](/ja/docs/concepts/workloads/pods/pod-lifecycle/)で説明したように、`Job`は`RestartPolicy`が`OnFailure`または`Never`と等しいPodに対して*のみ*適切です。 -(注意: `RestartPolicy`が設定されていない場合、デフォルト値は`Always`です。) - -### 単一のJobでコントローラーPodを起動 - -もう一つのパターンは、単一のJobでPodを作成し、そのPodが他のPodを作成し、それらのPodに対するカスタムコントローラーのように動作するというものです。これは最も柔軟性がありますが、始めるのがやや複雑で、Kubernetesとの統合性が低いかもしれません。 - -このパターンの例として、Podを起動してスクリプトを実行するJobがSparkマスターコントローラー([Sparkの例](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/spark/README.md)を参照)を起動し、Sparkドライバーを実行してからクリーンアップするというものがあります。 - -このアプローチの利点は、全体的なプロセスがJobオブジェクトが完了する保証を得ながらも、どのようなPodが作成され、どのように作業が割り当てられるかを完全に制御できることです。 - -## Cron Job {#cron-jobs} - -Unixのツールである`cron`と同様に、指定した日時に実行されるJobを作成するために、[`CronJob`](/ja/docs/concepts/workloads/controllers/cron-jobs/)を使用することができます。 From bf8386f235cf8dbd2499654cb8c24d13ddf90da7 Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Mon, 31 Aug 2020 12:44:17 +0900 Subject: [PATCH 113/252] Apply suggestions from code review Co-authored-by: Naoki Oketani --- .../docs/concepts/workloads/controllers/ttlafterfinished.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md b/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md index 1715f2cf91..d57586f905 100644 --- a/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md +++ b/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md @@ -10,7 +10,7 @@ weight: 70 {{< feature-state for_k8s_version="v1.12" state="alpha" >}} TTLコントローラーは実行を終えたリソースオブジェクトのライフタイムを制御するためのTTL (time to live) メカニズムを提供します。 -TTLコントローラーは現在{{< glossary_tooltip text="Jobs" term_id="job" >}}のみ扱っていて、将来的にPodやカスタムリソースなど、他のリソースの実行終了を扱えるように拡張される予定です。 +TTLコントローラーは現在{{< glossary_tooltip text="Job" term_id="job" >}}のみ扱っていて、将来的にPodやカスタムリソースなど、他のリソースの実行終了を扱えるように拡張される予定です。 α版の免責事項: この機能は現在α版の機能で、kube-apiserverとkube-controller-managerの[Feature Gate](/docs/reference/command-line-tools-reference/feature-gates/)の`TTLAfterFinished`を有効にすることで使用可能です。 @@ -50,8 +50,7 @@ Kubernetesにおいてタイムスキューを避けるために、全てのNode ## {{% heading "whatsnext" %}} -[Jobの自動クリーンアップ](/ja/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically) +* [Jobの自動クリーンアップ](/ja/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically) [設計ドキュメント](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0026-ttl-after-finish.md) - From 6622978b23ef02e210627daf15301ba388aea3be Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Mon, 14 Sep 2020 19:53:37 +0900 Subject: [PATCH 114/252] Apply suggestions from code review Co-authored-by: Naoki Oketani --- .../ja/docs/concepts/workloads/controllers/ttlafterfinished.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md b/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md index d57586f905..f863cb4e92 100644 --- a/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md +++ b/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md @@ -52,5 +52,4 @@ Kubernetesにおいてタイムスキューを避けるために、全てのNode * [Jobの自動クリーンアップ](/ja/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically) -[設計ドキュメント](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0026-ttl-after-finish.md) - +* [設計ドキュメント](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0026-ttl-after-finish.md) From d285d43f76ab7f345d31cfee07ea333246a280de Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Mon, 14 Sep 2020 14:44:47 +0900 Subject: [PATCH 115/252] Update kubernetes-objects.md --- .../overview/working-with-objects/kubernetes-objects.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/overview/working-with-objects/kubernetes-objects.md b/content/ja/docs/concepts/overview/working-with-objects/kubernetes-objects.md index 48cbed282a..9b3eeb7332 100644 --- a/content/ja/docs/concepts/overview/working-with-objects/kubernetes-objects.md +++ b/content/ja/docs/concepts/overview/working-with-objects/kubernetes-objects.md @@ -28,7 +28,7 @@ Kubernetesオブジェクトを操作するには、作成、変更、または ほとんどのKubernetesオブジェクトは、オブジェクトの設定を管理する２つの入れ子になったオブジェクトのフィールドを持っています。それはオブジェクト *`spec`* とオブジェクト *`status`* です。`spec`を持っているオブジェクトに関しては、オブジェクト作成時に`spec`を設定する必要があり、望ましい状態としてオブジェクトに持たせたい特徴を記述する必要があります。 -`status` オブジェクトはオブジェクトの *現在の状態* を示し、その情報はKubernetesとそのコンポーネントにより提供、更新されます。Kubernetes{{< glossary_tooltip text="コントロールプレーン" term_id="control-plane" >}}は、あなたから指定された望ましい状態と現在の状態が一致するよう常にかつ積極的に管理をします。 +`status` オブジェクトはオブジェクトの *現在の状態* を示し、その情報はKubernetesシステムとそのコンポーネントにより提供、更新されます。Kubernetes{{< glossary_tooltip text="コントロールプレーン" term_id="control-plane" >}}は、あなたから指定された望ましい状態と現在の状態が一致するよう常にかつ積極的に管理をします。 例えば、KubernetesのDeploymentはクラスター上で稼働するアプリケーションを表現するオブジェクトです。Deploymentを作成するとき、アプリケーションの複製を３つ稼働させるようDeploymentのspecで指定するかもしれません。KubernetesはDeploymentのspecを読み取り、指定されたアプリケーションを３つ起動し、現在の状態がspecに一致するようにします。もしこれらのインスタンスでどれかが落ちた場合(statusが変わる)、Kubernetesはspecと、statusの違いに反応し、修正しようとします。この場合は、落ちたインスタンスの代わりのインスタンスを立ち上げます。 @@ -73,7 +73,7 @@ Kubernetesオブジェクトを`.yaml`ファイルに記載して作成する場 * [Kubernetes API overview](/docs/reference/using-api/api-overview/)はこのページでは取り上げていない他のAPIについて説明します。 -* 最も重要、かつ基本的なKubernetesオブジェクト群を学びましょう、例えば、[Pod](/ja/docs/concepts/workloads/pods/pod-overview/)です。 +* 最も重要、かつ基本的なKubernetesオブジェクト群を学びましょう、例えば、[Pod](/ja/docs/concepts/workloads/pods/)です。 * Kubernetesの[コントローラー](/docs/concepts/architecture/controller/)を学びましょう。 From e6f33dd3e624f6540a8ef8dccef77a09b5ac7481 Mon Sep 17 00:00:00 2001 From: Jin Hase Date: Fri, 11 Sep 2020 18:28:10 +0900 Subject: [PATCH 116/252] Update Japanese localization on concepts/storage/volume-pvc-datasource.md --- content/ja/docs/concepts/storage/volume-pvc-datasource.md | 1 + 1 file changed, 1 insertion(+) diff --git a/content/ja/docs/concepts/storage/volume-pvc-datasource.md b/content/ja/docs/concepts/storage/volume-pvc-datasource.md index 32e3cfb1b0..7b07e66d5b 100644 --- a/content/ja/docs/concepts/storage/volume-pvc-datasource.md +++ b/content/ja/docs/concepts/storage/volume-pvc-datasource.md @@ -31,6 +31,7 @@ weight: 30 * 複製は同じストレージクラス内でのみサポートされます。 - 宛先ボリュームは、ソースと同じストレージクラスである必要があります。 - デフォルトのストレージクラスを使用でき、仕様ではstorageClassNameを省略できます。 +* 複製は同じVolumeMode設定を使用する2つのボリューム間でのみ実行できます(ブロックモードのボリュームを要求する場合、ソースもブロックモードである必要があります)。 ## プロビジョニング From f0c7c540fd531b0830fcb25158ecad063da8723e Mon Sep 17 00:00:00 2001 From: Jin Hase Date: Mon, 14 Sep 2020 10:52:00 +0900 Subject: [PATCH 117/252] Update volume-pvc-datasource.md --- content/ja/docs/concepts/storage/volume-pvc-datasource.md | 1 - 1 file changed, 1 deletion(-) diff --git a/content/ja/docs/concepts/storage/volume-pvc-datasource.md b/content/ja/docs/concepts/storage/volume-pvc-datasource.md index 7b07e66d5b..fc1b7ae4b9 100644 --- a/content/ja/docs/concepts/storage/volume-pvc-datasource.md +++ b/content/ja/docs/concepts/storage/volume-pvc-datasource.md @@ -6,7 +6,6 @@ weight: 30 -{{< feature-state for_k8s_version="v1.16" state="beta" >}} このドキュメントではKubernetesで既存のCSIボリュームの複製についてのコンセプトを説明します。このページを読む前にあらかじめ[ボリューム](/docs/concepts/storage/volumes)についてよく理解していることが望ましいです。 From a61c14b165a97d3976f2958fd71503ffbfd8bfb4 Mon Sep 17 00:00:00 2001 From: Takaaki Fujii Date: Sun, 6 Sep 2020 15:35:39 +0900 Subject: [PATCH 118/252] finished translate --- content/ja/docs/reference/glossary/volume.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/content/ja/docs/reference/glossary/volume.md b/content/ja/docs/reference/glossary/volume.md index 6a81f84522..071f8b3aa6 100644 --- a/content/ja/docs/reference/glossary/volume.md +++ b/content/ja/docs/reference/glossary/volume.md @@ -4,17 +4,17 @@ id: volume date: 2018-04-12 full_link: /docs/concepts/storage/volumes/ short_description: > - Pod内のコンテナからアクセス可能なデータを含むディレクトリです。 + データを格納するディレクトリで、Pod内のコンテナが利用可能です。 -aka: +aka: tags: - core-object - fundamental --- - {{< glossary_tooltip text="Pod" term_id="pod" >}}内の{{< glossary_tooltip text="コンテナ" term_id="container" >}}からアクセス可能なデータを含むディレクトリです。 + データを格納するディレクトリで、{{< glossary_tooltip term_id="pod" >}}内の{{< glossary_tooltip text="コンテナ" term_id="container" >}}が利用可能です。 - + -Kubernetesボリュームはボリュームを含むPodが存在する限り有効です。そのためボリュームはPod内で実行されるすべてのコンテナよりも長持ちし、コンテナの再起動後もデータは保持されます。 +Kubernetesボリュームはボリュームを含んだPodが存在する限り有効です。そのため、ボリュームはPod内で実行されるどのコンテナよりも長く存在し、コンテナが再起動してもボリューム内のデータは維持されます。 -詳しくは[ストレージ](https://kubernetes.io/docs/concepts/storage/)をご覧下さい。 +詳しくは[ストレージ](/ja/docs/concepts/storage/)をご覧ください。 From 2c2947187b41f971a72a1ea36b6df1ec582237af Mon Sep 17 00:00:00 2001 From: Takaaki Fujii Date: Sun, 6 Sep 2020 18:17:09 +0900 Subject: [PATCH 119/252] fixed short description --- content/ja/docs/reference/glossary/volume.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/reference/glossary/volume.md b/content/ja/docs/reference/glossary/volume.md index 071f8b3aa6..b9cab01761 100644 --- a/content/ja/docs/reference/glossary/volume.md +++ b/content/ja/docs/reference/glossary/volume.md @@ -4,14 +4,14 @@ id: volume date: 2018-04-12 full_link: /docs/concepts/storage/volumes/ short_description: > - データを格納するディレクトリで、Pod内のコンテナが利用可能です。 + データを格納するディレクトリで、Pod内のコンテナからアクセス可能です。 aka: tags: - core-object - fundamental --- - データを格納するディレクトリで、{{< glossary_tooltip term_id="pod" >}}内の{{< glossary_tooltip text="コンテナ" term_id="container" >}}が利用可能です。 + データを格納するディレクトリで、{{< glossary_tooltip term_id="pod" >}}内の{{< glossary_tooltip text="コンテナ" term_id="container" >}}からアクセス可能です。 From 8ae641909189eb0ba8477789156a389304100f30 Mon Sep 17 00:00:00 2001 From: takaf04 Date: Sun, 6 Sep 2020 20:14:42 +0900 Subject: [PATCH 120/252] Update content/ja/docs/reference/glossary/volume.md Co-authored-by: Naoki Oketani --- content/ja/docs/reference/glossary/volume.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/reference/glossary/volume.md b/content/ja/docs/reference/glossary/volume.md index b9cab01761..b7021ad4e4 100644 --- a/content/ja/docs/reference/glossary/volume.md +++ b/content/ja/docs/reference/glossary/volume.md @@ -11,7 +11,7 @@ tags: - core-object - fundamental --- - データを格納するディレクトリで、{{< glossary_tooltip term_id="pod" >}}内の{{< glossary_tooltip text="コンテナ" term_id="container" >}}からアクセス可能です。 + データを格納するディレクトリで、{{< glossary_tooltip text="Pod" term_id="pod" >}}内の{{< glossary_tooltip text="コンテナ" term_id="container" >}}からアクセス可能です。 From 817e3bfe9bcedeab1f3a78ffb7fc37e4f8ae0f2f Mon Sep 17 00:00:00 2001 From: tkms0106 <23391543+tkms0106@users.noreply.github.com> Date: Mon, 14 Sep 2020 19:21:02 +0900 Subject: [PATCH 121/252] Update japanese ingress-controllers.md to follow v1.18 of the original (English) text --- .../docs/concepts/services-networking/ingress-controllers.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/services-networking/ingress-controllers.md b/content/ja/docs/concepts/services-networking/ingress-controllers.md index f19d21ef43..f1af46c3a2 100644 --- a/content/ja/docs/concepts/services-networking/ingress-controllers.md +++ b/content/ja/docs/concepts/services-networking/ingress-controllers.md @@ -21,11 +21,11 @@ Ingressリソースが動作するためには、クラスターでIngressコン * [AKS Application Gateway Ingress Controller](https://github.com/Azure/application-gateway-kubernetes-ingress)は[Azure Application Gateway](https://docs.microsoft.com/azure/application-gateway/overview)を利用して[AKSクラスター](https://docs.microsoft.com/azure/aks/kubernetes-walkthrough-portal)でIngressを実行可能にするIngressコントローラーです。 * [Ambassador](https://www.getambassador.io/) API Gatewayは[Envoy](https://www.envoyproxy.io)ベースのIngressコントローラーで、[Datawire](https://www.datawire.io/)による[コミュニティ版](https://www.getambassador.io/docs)または[商用版](https://www.getambassador.io/pro/)のサポートがあります。 -* [AppsCode Inc.](https://appscode.com)では、最も広く使用されている[HAProxy](http://www.haproxy.org/)ベースのIngressコントローラーである[Voyager](https://appscode.com/products/voyager)のサポートと保守を提供しています。 +* [AppsCode Inc.](https://appscode.com)では、最も広く使用されている[HAProxy](https://www.haproxy.org/)ベースのIngressコントローラーである[Voyager](https://appscode.com/products/voyager)のサポートと保守を提供しています。 * [AWS ALB Ingress Controller](https://github.com/kubernetes-sigs/aws-alb-ingress-controller)は[AWS Application Load Balancer](https://aws.amazon.com/elasticloadbalancing/)を使用したIngressを有効にします。 * [Contour](https://projectcontour.io/)は、VMwareが提供し、サポートしている[Envoy](https://www.envoyproxy.io/)ベースのIngressコントローラーです。 * Citrixは、[ベアメタル](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment/baremetal)と[クラウド](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment)のデプロイ用に、ハードウェア(MPX）、仮想化(VPX)、[フリーコンテナ化(CPX) ADC](https://www.citrix.com/products/citrix-adc/cpx-express.html)用の[Ingressコントローラー](https://github.com/citrix/citrix-k8s-ingress-controller)を提供しています。 -* F5 Networksは[F5 BIG-IP Controller for Kubernetes](http://clouddocs.f5.com/products/connectors/k8s-bigip-ctlr/latest)の[サポートと保守](https://support.f5.com/csp/article/K86859508)を提供しています。 +* F5 Networksは[F5 BIG-IP Container Ingress Services for Kubernetes](https://clouddocs.f5.com/containers/latest/userguide/kubernetes/)の[サポートと保守](https://support.f5.com/csp/article/K86859508)を提供しています。 * [Gloo](https://gloo.solo.io)は[Envoy](https://www.envoyproxy.io)をベースにしたオープンソースのIngressコントローラーで、[solo.io](https://www.solo.io)からのエンタープライズサポートでAPI Gateway機能を提供しています。 * [HAProxy Ingress](https://haproxy-ingress.github.io)は、HAProxy用の高度にカスタマイズ可能なコミュニティ主導のIngressコントローラーです。 * [HAProxy Technologies](https://www.haproxy.com/)は[HAProxy Ingress Controller for Kubernetes](https://github.com/haproxytech/kubernetes-ingress)のサポートと保守を提供しています。[公式ドキュメント](https://www.haproxy.com/documentation/hapee/1-9r1/traffic-management/kubernetes-ingress-controller/)を参照してください。 From 899e02aeb738b4dbedf486d7a0eff09398d74008 Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Fri, 11 Sep 2020 12:54:22 +0900 Subject: [PATCH 122/252] Update ja/docs/tasks/administer-cluster/enabling-endpointslices.md --- .../tasks/administer-cluster/enabling-endpointslices.md | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/content/ja/docs/tasks/administer-cluster/enabling-endpointslices.md b/content/ja/docs/tasks/administer-cluster/enabling-endpointslices.md index ddab0bb95d..43fc0e72ba 100644 --- a/content/ja/docs/tasks/administer-cluster/enabling-endpointslices.md +++ b/content/ja/docs/tasks/administer-cluster/enabling-endpointslices.md @@ -27,15 +27,13 @@ EndpointSliceは、KubernetesのEndpointsに対してスケーラブルで拡張 EndpointSliceは、最終的には既存のEndpointsを置き換える可能性がありますが、多くのKubernetesコンポーネントはまだ既存のEndpointsに依存しています。現時点ではEndpointSliceを有効化することは、Endpointsの置き換えではなく、クラスター内のEndpointsへの追加とみなされる必要があります。 {{< /note >}} -EndpointSliceはベータ版の機能とみなされますが、デフォルトではAPIのみが有効です。kube-proxyによるEndpointSliceコントローラーとEndpointSliceの使用は、デフォルトでは有効になっていません。 +EndpoitSliceはベータ版の機能です。APIとEndpointSlice{{< glossary_tooltip text="コントローラー" term_id="controller" >}}はデフォルトで有効です。{{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}はデフォルトでEndpointを使用します、EndpointSliceではありません。 -EndpointSliceコントローラーはクラスター内にEndpointSliceを作成し、管理します。これは、{{< glossary_tooltip text="kube-apiserver" term_id="kube-apiserver" >}}と{{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}}の`EndpointSlice`の[フィーチャーゲート](/docs/reference/command-line-tools-reference/feature-gates/)で有効にできます(`--feature-gates=EndpointSlice=true`)。 - -スケーラビリティ向上のため、{{}}でフィーチャーゲートを有効にして、Endpointsの代わりにEndpointSliceをデータソースとして使用することもできます。 +スケーラビリティと性能向上のため、kube-proxy上で`EndpointSliceProxying`[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にできます。この変更はデータソースをEndpointSliceに移します、これはkube-proxyとKubernetesAPI間のトラフィックの量を削減します。 ## EndpointSliceの使用 -クラスター内でEndpointSliceを完全に有効にすると、各Endpointsリソースに対応するEndpointSliceリソースが表示されます。既存のEndpointsの機能をサポートすることに加えて、EndpointSliceはトポロジーなどの新しい情報を含める必要があります。これらにより、クラスター内のネットワークエンドポイントのスケーラビリティと拡張性が大きく向上します。 +クラスター内でEndpointSliceを完全に有効にすると、各Endpointsリソースに対応するEndpointSliceリソースが表示されます。既存のEndpointsの機能をサポートすることに加えて、EndpointSliceはトポロジーなどの新しい情報を含みます。これらにより、クラスター内のネットワークエンドポイントのスケーラビリティと拡張性が大きく向上します。 ## {{% heading "whatsnext" %}} From a1142f69ed44bd11005163adb10cebc1b948291e Mon Sep 17 00:00:00 2001 From: yu-kasuya Date: Tue, 15 Sep 2020 12:15:54 +0900 Subject: [PATCH 123/252] Apply suggestions from code review Co-authored-by: Naoki Oketani --- .../docs/tasks/administer-cluster/enabling-endpointslices.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/ja/docs/tasks/administer-cluster/enabling-endpointslices.md b/content/ja/docs/tasks/administer-cluster/enabling-endpointslices.md index 43fc0e72ba..99b70226c9 100644 --- a/content/ja/docs/tasks/administer-cluster/enabling-endpointslices.md +++ b/content/ja/docs/tasks/administer-cluster/enabling-endpointslices.md @@ -27,7 +27,7 @@ EndpointSliceは、KubernetesのEndpointsに対してスケーラブルで拡張 EndpointSliceは、最終的には既存のEndpointsを置き換える可能性がありますが、多くのKubernetesコンポーネントはまだ既存のEndpointsに依存しています。現時点ではEndpointSliceを有効化することは、Endpointsの置き換えではなく、クラスター内のEndpointsへの追加とみなされる必要があります。 {{< /note >}} -EndpoitSliceはベータ版の機能です。APIとEndpointSlice{{< glossary_tooltip text="コントローラー" term_id="controller" >}}はデフォルトで有効です。{{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}はデフォルトでEndpointを使用します、EndpointSliceではありません。 +EndpoitSliceはベータ版の機能です。APIとEndpointSlice{{< glossary_tooltip text="コントローラー" term_id="controller" >}}はデフォルトで有効です。{{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}はデフォルトでEndpointSliceではなくEndpointsを使用します。 スケーラビリティと性能向上のため、kube-proxy上で`EndpointSliceProxying`[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にできます。この変更はデータソースをEndpointSliceに移します、これはkube-proxyとKubernetesAPI間のトラフィックの量を削減します。 @@ -41,4 +41,3 @@ EndpoitSliceはベータ版の機能です。APIとEndpointSlice{{< glossary_too * [EndpointSlice](/docs/concepts/services-networking/endpoint-slices/)を参照してください。 * [サービスとアプリケーションの接続](/ja/docs/concepts/services-networking/connect-applications-service/)を参照してください。 - From ad90db2cf50cd620eccf9e496083945bf025d811 Mon Sep 17 00:00:00 2001 From: yu-kasuya Date: Tue, 15 Sep 2020 12:16:33 +0900 Subject: [PATCH 124/252] Apply suggestions from code review Co-authored-by: Naoki Oketani --- .../docs/tasks/administer-cluster/enabling-endpointslices.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/ja/docs/tasks/administer-cluster/enabling-endpointslices.md b/content/ja/docs/tasks/administer-cluster/enabling-endpointslices.md index 99b70226c9..0718205ded 100644 --- a/content/ja/docs/tasks/administer-cluster/enabling-endpointslices.md +++ b/content/ja/docs/tasks/administer-cluster/enabling-endpointslices.md @@ -29,7 +29,7 @@ EndpointSliceは、最終的には既存のEndpointsを置き換える可能性 EndpoitSliceはベータ版の機能です。APIとEndpointSlice{{< glossary_tooltip text="コントローラー" term_id="controller" >}}はデフォルトで有効です。{{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}はデフォルトでEndpointSliceではなくEndpointsを使用します。 -スケーラビリティと性能向上のため、kube-proxy上で`EndpointSliceProxying`[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にできます。この変更はデータソースをEndpointSliceに移します、これはkube-proxyとKubernetesAPI間のトラフィックの量を削減します。 +スケーラビリティと性能向上のため、kube-proxy上で`EndpointSliceProxying`[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にできます。この変更はデータソースをEndpointSliceに移します、これはkube-proxyとKubernetes API間のトラフィックの量を削減します。 ## EndpointSliceの使用 @@ -40,4 +40,3 @@ EndpoitSliceはベータ版の機能です。APIとEndpointSlice{{< glossary_too * [EndpointSlice](/docs/concepts/services-networking/endpoint-slices/)を参照してください。 * [サービスとアプリケーションの接続](/ja/docs/concepts/services-networking/connect-applications-service/)を参照してください。 - From 40e06dcd41518b18710eba2924e9d0639553ec82 Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Wed, 16 Sep 2020 12:19:29 +0900 Subject: [PATCH 125/252] Update ja/docs/tasks/configure-pod-container/assign-memory-resource.md --- .../assign-memory-resource.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/content/ja/docs/tasks/configure-pod-container/assign-memory-resource.md b/content/ja/docs/tasks/configure-pod-container/assign-memory-resource.md index 1af80012fc..944ce4b715 100644 --- a/content/ja/docs/tasks/configure-pod-container/assign-memory-resource.md +++ b/content/ja/docs/tasks/configure-pod-container/assign-memory-resource.md @@ -302,17 +302,17 @@ kubectl delete namespace mem-example ### クラスター管理者向け -* [Namespaceにメモリー要求および制限のデフォルト値を設定する](/docs/tasks/administer-cluster/memory-default-namespace/) +* [Namespaceにメモリー要求および制限のデフォルト値を設定する](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/) -* [NamespaceにCPU要求および制限のデフォルト値を設定する](/docs/tasks/administer-cluster/cpu-default-namespace/) +* [NamespaceにCPU要求および制限のデフォルト値を設定する](/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/) -* [Namespaceに最小および最大メモリー量の制約を設定する](/docs/tasks/administer-cluster/memory-constraint-namespace/) +* [Namespaceに最小および最大メモリー量の制約を設定する](/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/) -* [Namespaceに最小および最大のCPU使用量の制約を設定する](/docs/tasks/administer-cluster/cpu-constraint-namespace/) +* [Namespaceに最小および最大のCPU使用量の制約を設定する](/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/) -* [NamespaceにメモリーおよびCPUのクォータを設定する](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/) +* [NamespaceにメモリーおよびCPUのクォータを設定する](/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/) -* [NamespaceにPodのクォータを設定する](/docs/tasks/administer-cluster/quota-pod-namespace/) +* [NamespaceにPodのクォータを設定する](/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace/) * [APIオブジェクトのクォータを設定する](/docs/tasks/administer-cluster/quota-api-object/) From a27aef9dc8c67611d6631c042c0bb169932bd4ce Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Thu, 10 Sep 2020 22:44:15 +0900 Subject: [PATCH 126/252] Make docs/tasks/debug-application-cluster/_index.md follow v1.18 of the original text --- content/ja/docs/tasks/debug-application-cluster/_index.md | 1 + 1 file changed, 1 insertion(+) diff --git a/content/ja/docs/tasks/debug-application-cluster/_index.md b/content/ja/docs/tasks/debug-application-cluster/_index.md index cbf41f43ff..cb2159a111 100755 --- a/content/ja/docs/tasks/debug-application-cluster/_index.md +++ b/content/ja/docs/tasks/debug-application-cluster/_index.md @@ -1,4 +1,5 @@ --- title: "監視、ログ、デバッグ" +description: クラスターのトラブルシューティングや、コンテナ化したアプリケーションのデバッグのために、監視とロギングをセットアップします。 weight: 80 --- From 8220b4a1c00d25824dd286979e875d65b526c490 Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Mon, 14 Sep 2020 22:51:38 +0900 Subject: [PATCH 127/252] Update _index.md --- content/ja/docs/tasks/debug-application-cluster/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/_index.md b/content/ja/docs/tasks/debug-application-cluster/_index.md index cb2159a111..bc8639bb94 100755 --- a/content/ja/docs/tasks/debug-application-cluster/_index.md +++ b/content/ja/docs/tasks/debug-application-cluster/_index.md @@ -1,5 +1,5 @@ --- title: "監視、ログ、デバッグ" -description: クラスターのトラブルシューティングや、コンテナ化したアプリケーションのデバッグのために、監視とロギングをセットアップします。 +description: クラスターのトラブルシューティングや、コンテナ化したアプリケーションのデバッグのために、監視とログをセットアップします。 weight: 80 --- From 1c7fbc904044ce86d21ba0a08a7a64dc14187052 Mon Sep 17 00:00:00 2001 From: pururaj1908 Date: Thu, 10 Sep 2020 04:56:29 -0400 Subject: [PATCH 128/252] Updated ja minikube.md to follow v1.18 changes --- content/ja/docs/tasks/tools/install-minikube.md | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/content/ja/docs/tasks/tools/install-minikube.md b/content/ja/docs/tasks/tools/install-minikube.md index 30b15718ca..6b2a23d7b1 100644 --- a/content/ja/docs/tasks/tools/install-minikube.md +++ b/content/ja/docs/tasks/tools/install-minikube.md @@ -76,7 +76,7 @@ kubectlがインストールされていることを確認してください。 • [VirtualBox](https://www.virtualbox.org/wiki/Downloads) -Minikubeは、VMではなくホストでKubernetesコンポーネントを実行する`--vm-driver=none`オプションもサポートしています。 +Minikubeは、VMではなくホストでKubernetesコンポーネントを実行する`--driver=none`オプションもサポートしています。 このドライバーを使用するには、[Docker](https://www.docker.com/products/docker-desktop)とLinux環境が必要ですが、ハイパーバイザーは不要です。 Debian系のLinuxで`none`ドライバーを使用する場合は、snapパッケージではなく`.deb`パッケージを使用してDockerをインストールしてください。snapパッケージはMinikubeでは機能しません。 @@ -84,7 +84,7 @@ Debian系のLinuxで`none`ドライバーを使用する場合は、snapパッ {{< caution >}} `none` VMドライバーは、セキュリティとデータ損失の問題を引き起こす可能性があります。 -`--vm-driver=none`を使用する前に、詳細について[このドキュメント](https://minikube.sigs.k8s.io/docs/reference/drivers/none/) を参照してください。 +`--driver=none`を使用する前に、詳細について[このドキュメント](https://minikube.sigs.k8s.io/docs/reference/drivers/none/) を参照してください。 {{< /caution >}} MinikubeはDockerドライバーと似たような`vm-driver=podman`もサポートしています。Podmanを特権ユーザー権限(root user)で実行することは、コンテナがシステム上の利用可能な機能へ完全にアクセスするための最もよい方法です。 @@ -209,12 +209,16 @@ WindowsにMinikubeを手動でインストールするには、[`minikube-window {{< note >}} -`minikube start`で`--vm-driver`の設定をするため、次の``の部分では、インストールしたハイパーバイザーの名前を小文字で入力してください。`--vm-driver`値のすべてのリストは、[specifying the VM driver documentation](https://kubernetes.io/docs/setup/learning-environment/minikube/#specifying-the-vm-driver)で確認できます。 +`minikube start`で`--driver`の設定をするため、次の``の部分では、インストールしたハイパーバイザーの名前を小文字で入力してください。`--driver`値のすべてのリストは、[specifying the VM driver documentation](/docs/setup/learning-environment/minikube/#specifying-the-vm-driver)で確認できます。 {{< /note >}} +{{< caution >}} +KVMを使用する場合、Debianおよび他の一部のシステムでのlibvirtのデフォルトのQEMU URIは`qemu：///session`であるのに対し、MinikubeのデフォルトのQEMU URIは`qemu：///system`であることに注意してください。これがあなたのシステムに当てはまる場合、`--kvm-qemu-uri qemu:///session`を`minikube start`に渡す必要があります。 +{{< /caution >}} + ```shell -minikube start --vm-driver= +minikube start --driver= ``` `minikube start`が完了した場合、次のコマンドを実行してクラスターの状態を確認します。 From e70daec5a20f465bab57e476ec7dc37997f8c0d3 Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Wed, 9 Sep 2020 12:14:59 +0900 Subject: [PATCH 129/252] Update ja/docs/reference/glossary/node.md --- content/ja/docs/reference/glossary/node.md | 1 + 1 file changed, 1 insertion(+) diff --git a/content/ja/docs/reference/glossary/node.md b/content/ja/docs/reference/glossary/node.md index 0eb8976c1b..153b856243 100755 --- a/content/ja/docs/reference/glossary/node.md +++ b/content/ja/docs/reference/glossary/node.md @@ -15,3 +15,4 @@ tags: ワーカーノードは、クラスターに応じてVMまたは物理マシンの場合があります。{{< glossary_tooltip text="Pod" term_id="pod" >}}の実行に必要なローカルデーモンまたはサービスがあり、コントロールプレーンによって管理されます。ノード上のデーモンには、{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}、{{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}、および{{< glossary_tooltip term_id="docker" >}}などの{{< glossary_tooltip text="CRI" term_id="cri" >}}を実装するコンテナランタイムが含まれます。 +Kubernetesの初期バージョンでは、ノードは"Minion"と呼ばれていました。 From 80c360ecfbb25173581b567ddb3566b27fd33115 Mon Sep 17 00:00:00 2001 From: Jin Hase Date: Thu, 27 Aug 2020 21:52:03 +0900 Subject: [PATCH 130/252] Update Japanese localization on concepts/workloads/pods/podpreset.md follow --- .../docs/concepts/workloads/pods/podpreset.md | 57 +++++++++---------- 1 file changed, 27 insertions(+), 30 deletions(-) diff --git a/content/ja/docs/concepts/workloads/pods/podpreset.md b/content/ja/docs/concepts/workloads/pods/podpreset.md index 42faf6bf0c..76b089fea8 100644 --- a/content/ja/docs/concepts/workloads/pods/podpreset.md +++ b/content/ja/docs/concepts/workloads/pods/podpreset.md @@ -1,30 +1,41 @@ --- reviewers: -title: Pod Preset +title: Pod Presets content_type: concept weight: 50 --- -このページではPodPresetについて概観します。PodPresetは、Podの作成時にそのPodに対して、Secret、Volume、VolumeMountや環境変数など、特定の情報を注入するためのオブジェクトです。 +{{< feature-state for_k8s_version="v1.6" state="alpha" >}} +このページではPodPresetについて概観します。PodPresetは、Podの作成時にそのPodに対して、Secret、Volume、VolumeMountや環境変数など、特定の情報を注入するためのオブジェクトです。 ## PodPresetを理解する -`PodPreset`はPodの作成時に追加のランタイム要求を注入するためのAPIリソースです。 -ユーザーはPodPresetを適用する対象のPodを指定するために、[ラベルセレクター](/ja/docs/concepts/overview/working-with-objects/labels/#label-selectors)を使用します。 +`PodPreset`はPodの作成時に追加のランタイム要求を注入するためのAPIリソースです。ユーザーはPodPresetを適用する対象のPodを指定するために、[ラベルセレクター](/ja/docs/concepts/overview/working-with-objects/labels/#label-selectors)を使用します。 -PodPresetの使用により、Podテンプレートの作者はPodにおいて、全ての情報を明示的に指定する必要がなくなります。 -この方法により、特定のServiceを使っているPodテンプレートの作者は、そのServiceについて全ての詳細を知る必要がなくなります。 +PodPresetの使用により、Podテンプレートの作者はPodにおいて、全ての情報を明示的に指定する必要がなくなります。この方法により、特定のServiceを使っているPodテンプレートの作者は、そのServiceについて全ての詳細を知る必要がなくなります。 -PodPresetの内部についてのさらなる情報は、[PodPresetのデザインプロポーザル](https://git.k8s.io/community/contributors/design-proposals/service-catalog/pod-preset.md)を参照してください。 + +## クラスターでPodPresetを有効にする {#enable-pod-preset} + +ユーザーのクラスター内でPodPresetを使うためには、クラスター内の以下の項目をご確認ください。 + +1. `settings.k8s.io/v1alpha1/podpreset`というAPIを有効にします。例えば、これはAPI Serverの `--runtime-config`オプションに`settings.k8s.io/v1alpha1=true`を含むことで可能になります。Minikubeにおいては、クラスターの起動時に`--extra-config=apiserver.runtime-config=settings.k8s.io/v1alpha1=true`をつけることで可能です。 +1. `PodPreset`に対する管理コントローラーを有効にします。これを行うための1つの方法として、API Serverの`--enable-admission-plugins`オプションの値に`PodPreset`を含む方法があります。例えば、Minikubeにおいては、クラスターの起動時に + + ```shell + --extra-config=apiserver.enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,PodPreset + ``` + + を追加することで可能になります。 ## PodPresetはどのように動くか -Kubernetesは`PodPreset`に対する管理用コントローラーを提供し、これが有効になっている時、コントローラーはリクエストされたPod作成要求に対してPodPresetを適用します。 -Pod作成要求が発生した時、Kubernetesシステムは下記の処理を行います。 + +Kubernetesは`PodPreset`に対する管理用コントローラーを提供し、これが有効になっている時、コントローラーはリクエストされたPod作成要求に対してPodPresetを適用します。Pod作成要求が発生した時、Kubernetesシステムは下記の処理を行います。 1. 使用可能な全ての`PodPreset`を取得する。 1. それらの`PodPreset`のラベルセレクターが、作成されたPod上のラベルと一致するかチェックする。 @@ -32,36 +43,22 @@ Pod作成要求が発生した時、Kubernetesシステムは下記の処理を 1. エラーが起きた時、そのPod上でマージエラーが起きたことを説明するイベントをスローし、`PodPreset`からリソースを1つも注入されていないPodを作成します。 1. `PodPreset`によって修正されたことを示すために、マージ後の修正されたPodにアノテーションをつけます。そのアノテーションは`podpreset.admission.kubernetes.io/podpreset-: "<リソースのバージョン>"`という形式になります。 -各Podは0以上のPodPresetにマッチすることができます。そして各`PodPreset`は0以上のPodに適用されます。単一の`PodPreset`が1以上のPodに適用された時、KubernetesはそのPodのSpecを修正します。`Env`、`EnvFrom`、`VolumeMounts`への変更があると、KubernetesはそのPod内の全てのコンテナのSpecを修正します。`Volume`への変更があった場合、KubernetesはそのPodのSpecを修正します。 +各Podは0以上のPodPresetにマッチすることができます。そして各PodPresetは0以上のPodに適用されます。単一のPodPresetが1以上のPodに適用された時、KubernetesはそのPodのSpecを修正します。`env`、`envFrom`、`volumeMounts`への変更があると、KubernetesはそのPod内の全てのコンテナのSpecを修正します。`volumes`への変更があった場合、KubernetesはそのPodのSpecを修正します。 {{< note >}} -単一のPodPresetは必要に応じてPodのSpec内の`.spec.containers`を修正することができます。PodPresetからのリソース定義は`initContainers`フィールドに対して1つも適用されません。 +単一のPodPresetは必要に応じてPodのspec内の以下のフィールドを修正することができます。 +- `.spec.containers`フィールド +- `.spec.initContainers`フィールド {{< /note >}} ### 特定のPodに対するPodPresetを無効にする -PodPresetによるPodの変更を受け付けたくないようなインスタンスがある場合があります。このようなケースでは、ユーザーはそのPodのSpec内に次のような形式のアノテーションを追加できます。 +PodPresetによるPodの変更を受け付けたくないようなインスタンスがある場合があります。このようなケースでは、ユーザーはそのPodの`.spec`内に次のような形式のアノテーションを追加できます。 `podpreset.admission.kubernetes.io/exclude: "true"` -## PodPresetを有効にする - -ユーザーのクラスター内でPodPresetを使うためには、クラスター内の以下の項目をご確認ください。 - -1. `settings.k8s.io/v1alpha1/podpreset`というAPIを有効にします。例えば、これはAPI Serverの `--runtime-config`オプションに`settings.k8s.io/v1alpha1=true`を含むことで可能になります。Minikubeにおいては、クラスターの起動時に`--extra-config=apiserver.runtime-config=settings.k8s.io/v1alpha1=true`をつけることで可能です。 -1. `PodPreset`に対する管理コントローラーを有効にします。これを行うための1つの方法として、API Serverの`--enable-admission-plugins`オプションの値に`PodPreset`を含む方法があります。Minikubeにおいては、クラスターの起動時に - - ```shell - --extra-config=apiserver.enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,PodPreset - ``` - - を追加することで可能になります。 -1. ユーザーが使う予定のNamespaceにおいて、`PodPreset`オブジェクトを作成することによりPodPresetを定義します。 - - ## {{% heading "whatsnext" %}} +[PodPresetを使ったPodへのデータの注入](/docs/tasks/inject-data-application/podpreset/) -* [PodPresetを使ったPodへのデータの注入](/docs/tasks/inject-data-application/podpreset/) - - +PodPresetの内部についてのさらなる情報は、[PodPresetのデザインプロポーザル](https://git.k8s.io/community/contributors/design-proposals/service-catalog/pod-preset.md)を参照してください。 From 78a96c28185f1b28e5c6f382efb8ee913f2ea781 Mon Sep 17 00:00:00 2001 From: Jin Hase Date: Mon, 31 Aug 2020 09:49:54 +0900 Subject: [PATCH 131/252] Update podpreset.md --- content/ja/docs/concepts/workloads/pods/podpreset.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/workloads/pods/podpreset.md b/content/ja/docs/concepts/workloads/pods/podpreset.md index 76b089fea8..da0862be08 100644 --- a/content/ja/docs/concepts/workloads/pods/podpreset.md +++ b/content/ja/docs/concepts/workloads/pods/podpreset.md @@ -1,6 +1,6 @@ --- reviewers: -title: Pod Presets +title: Pod Preset content_type: concept weight: 50 --- From 1a1ac8f4f4151b8d6e6820294dac8841165b9f27 Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Fri, 11 Sep 2020 12:21:09 +0900 Subject: [PATCH 132/252] Update ja/docs/tasks/administer-cluster/coredns.md --- content/ja/docs/tasks/administer-cluster/coredns.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/content/ja/docs/tasks/administer-cluster/coredns.md b/content/ja/docs/tasks/administer-cluster/coredns.md index 068832e852..2c6dd0bd7f 100644 --- a/content/ja/docs/tasks/administer-cluster/coredns.md +++ b/content/ja/docs/tasks/administer-cluster/coredns.md @@ -50,6 +50,10 @@ Kubernetesバージョン1.11以降でCoreDNSを実行している場合、ア Kubernetes 1.11では、CoreDNSは一般利用可能(GA)にアップグレードされ、デフォルトでインストールされます。 {{< /note >}} +{{< warning >}} +Kubernetes 1.18では、kubeadmでのkube-dns使用は非推奨となり、将来のバージョンではは削除されます。 +{{< /warning >}} + 1.13以前のバージョンにkube-dnsをインストールするには、`CoreDNS`フィーチャーゲートの値を`false`に設定します: ``` From c22eee0090265a9a1f1e6eb702a83a35142bde4c Mon Sep 17 00:00:00 2001 From: yu-kasuya Date: Tue, 15 Sep 2020 11:58:31 +0900 Subject: [PATCH 133/252] Apply suggestions from code review Co-authored-by: Keita Akutsu --- content/ja/docs/tasks/administer-cluster/coredns.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/ja/docs/tasks/administer-cluster/coredns.md b/content/ja/docs/tasks/administer-cluster/coredns.md index 2c6dd0bd7f..a2c05085f1 100644 --- a/content/ja/docs/tasks/administer-cluster/coredns.md +++ b/content/ja/docs/tasks/administer-cluster/coredns.md @@ -51,7 +51,7 @@ Kubernetes 1.11では、CoreDNSは一般利用可能(GA)にアップグレード {{< /note >}} {{< warning >}} -Kubernetes 1.18では、kubeadmでのkube-dns使用は非推奨となり、将来のバージョンではは削除されます。 +Kubernetes 1.18では、kubeadmでのkube-dns使用は非推奨となり、将来のバージョンでは削除されます。 {{< /warning >}} 1.13以前のバージョンにkube-dnsをインストールするには、`CoreDNS`フィーチャーゲートの値を`false`に設定します: @@ -80,4 +80,3 @@ CoreDNSだけをアップグレードしたい場合や、独自のカスタム [CoreDNS](https://coredns.io)は、`Corefile`を変更することで、kube-dnsよりも多くのユースケースをサポートするように設定することができます。詳細は[CoreDNSサイト](https://coredns.io/2017/05/08/custom-dns-entries-for-kubernetes/)を参照してください。 - From 57e4e1eaabdb469b7752959b73edbc05c1a7b666 Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Tue, 8 Sep 2020 12:30:40 +0900 Subject: [PATCH 134/252] Update ja/docs/reference/glossary/deployment.md --- content/ja/docs/reference/glossary/deployment.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/content/ja/docs/reference/glossary/deployment.md b/content/ja/docs/reference/glossary/deployment.md index 569cbbd6a1..e552ab9a7a 100755 --- a/content/ja/docs/reference/glossary/deployment.md +++ b/content/ja/docs/reference/glossary/deployment.md @@ -4,7 +4,7 @@ id: deployment date: 2018-04-12 full_link: /ja/docs/concepts/workloads/controllers/deployment/ short_description: > - 複製されたアプリケーションを管理するAPIオブジェクトです。 + クラスター上の複製されたアプリケーションを管理します。 aka: tags: @@ -12,8 +12,9 @@ tags: - core-object - workload --- - 複製されたアプリケーションを管理するAPIオブジェクトです。 + 複製されたアプリケーションを管理するAPIオブジェクトです、通常はローカル状態を持たないPodを実行します。 -各レプリカは{{< glossary_tooltip term_id="pod" >}}で表され、ポッドはクラスターのノード間で分散されます。 +各レプリカは{{< glossary_tooltip term_id="pod" >}}で表され、ポッドはクラスターの{{< glossary_tooltip text="ノード" term_id="node" >}}間で分散されます。 +ローカル状態を要求するワークロードには、{{< glossary_tooltip term_id="StatefulSet" >}}の利用を考えてください。 From 2d4db22652a44b0c2053251316a61f4e143d48db Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Tue, 15 Sep 2020 12:08:10 +0900 Subject: [PATCH 135/252] update word for stateless --- content/ja/docs/reference/glossary/deployment.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/reference/glossary/deployment.md b/content/ja/docs/reference/glossary/deployment.md index e552ab9a7a..757df66cba 100755 --- a/content/ja/docs/reference/glossary/deployment.md +++ b/content/ja/docs/reference/glossary/deployment.md @@ -12,7 +12,7 @@ tags: - core-object - workload --- - 複製されたアプリケーションを管理するAPIオブジェクトです、通常はローカル状態を持たないPodを実行します。 + 複製されたアプリケーションを管理するAPIオブジェクトです、通常はステートレスなPodを実行します。 From d95d0c1f1b4d03201174204e9762948078f681aa Mon Sep 17 00:00:00 2001 From: yu-kasuya Date: Wed, 16 Sep 2020 15:05:01 +0900 Subject: [PATCH 136/252] Apply suggestions from code review Co-authored-by: Naoki Oketani --- content/ja/docs/reference/glossary/deployment.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/reference/glossary/deployment.md b/content/ja/docs/reference/glossary/deployment.md index 757df66cba..7c9f090102 100755 --- a/content/ja/docs/reference/glossary/deployment.md +++ b/content/ja/docs/reference/glossary/deployment.md @@ -12,9 +12,9 @@ tags: - core-object - workload --- - 複製されたアプリケーションを管理するAPIオブジェクトです、通常はステートレスなPodを実行します。 + 複製されたアプリケーションを管理するAPIオブジェクトで、通常はステートレスなPodを実行します。 -各レプリカは{{< glossary_tooltip term_id="pod" >}}で表され、ポッドはクラスターの{{< glossary_tooltip text="ノード" term_id="node" >}}間で分散されます。 +各レプリカは{{< glossary_tooltip text="Pod" term_id="pod" >}}で表され、Podはクラスターの{{< glossary_tooltip text="ノード" term_id="node" >}}間で分散されます。 ローカル状態を要求するワークロードには、{{< glossary_tooltip term_id="StatefulSet" >}}の利用を考えてください。 From 9244f9e4aa8fe790e6fa2d30729cffb2ffd5f7b2 Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Fri, 21 Aug 2020 15:29:14 +0900 Subject: [PATCH 137/252] translate cloud-controller.md --- .../concepts/architecture/cloud-controller.md | 140 ++++++------------ .../glossary/cloud-controller-manager.md | 18 +++ 2 files changed, 61 insertions(+), 97 deletions(-) create mode 100755 content/ja/docs/reference/glossary/cloud-controller-manager.md diff --git a/content/ja/docs/concepts/architecture/cloud-controller.md b/content/ja/docs/concepts/architecture/cloud-controller.md index 8cf85db09b..0bff2a504e 100644 --- a/content/ja/docs/concepts/architecture/cloud-controller.md +++ b/content/ja/docs/concepts/architecture/cloud-controller.md @@ -1,21 +1,18 @@ --- -title: クラウドコントローラーマネージャーとそのコンセプト +title: クラウドコントローラーマネージャー content_type: concept weight: 40 --- -クラウドコントローラマネージャー(CCM)のコンセプト(バイナリと混同しないでください)は、もともとクラウドベンダー固有のソースコードと、Kubernetesのコアソースコードを独立して進化させることができるように作られました。クラウドコントローラーマネージャーは、Kubernetesコントローラーマネージャー、APIサーバー、そしてスケジューラーのような他のマスターコンポーネントと並行して動きます。またKubernetesのアドオンとしても動かすことができ、その場合はKubernetes上で動きます。 +{{< feature-state state="beta" for_k8s_version="v1.11" >}} -クラウドコントローラーマネージャーの設計は「プラグインメカニズム」をベースにしています。そうすることで、新しいクラウドプロバイダーがプラグインを使ってKubernetesと簡単に統合できるようになります。新しいクラウドプロバイダーに向けてKubernetesのオンボーディングを行ったり、古いモデルを利用しているクラウドプロバイダーに、新しいCCMモデルに移行させるような計画があります。 +クラウドインフラストラクチャ技術により、パブリック、プライベート、ハイブリッドクラウド上でKubernetesを動かすことができます。Kubernetesは、コンポーネント間の密なつながりが不要な自動化されたAPI駆動インフラストラクチャーであると考えられています。 -このドキュメントでは、クラウドコントローラーマネージャーの背景にあるコンセプトと、それに関連する機能の詳細について話します。 - -これが、クラウドコントローラーマネージャーを除いた、Kubernetesクラスターのアーキテクチャ図です。 - -![Pre CCM Kube Arch](/images/docs/pre-ccm-arch.png) +{{< glossary_definition term_id="cloud-controller-manager" length="all" prepend="cloud-controller-managerは">}} +cloud-controller-managerは、プラグインメカニズムを用い、異なるクラウドプロバイダーに対してそれぞれのプラットフォームとKubernetesの結合を可能にする構成になっています。 @@ -23,91 +20,49 @@ weight: 40 ## 設計 -上で示した図で分かるように、Kubernetesとクラウドプロバイダーはいくつかの異なるコンポーネントを通じて連携します: +![Kubernetes components](/images/docs/components-of-kubernetes.png) -* Kubelet -* Kubernetesコントローラーマネージャー -* Kubernetes APIサーバー +クラウドコントローラーマネージャーは、複製されたプロセスのセットとしてコントロールプレーンで実行されます。（通常、Pod内のコンテナとなります）各cloud-controller-managerは、シングルプロセスで複数の{{< glossary_tooltip text="controllers" term_id="controller" >}}を実装します。 -CCMは、前述した3つのコンポーネントのクラウド依存のロジックを統合し、クラウドとの単一の連携ポイントとなります。CCMを利用した新しいアーキテクチャは下記のようになります: - -![CCM Kube Arch](/images/docs/post-ccm-arch.png) - -## CCMのコンポーネント - -CCMは、Kubernetesコントローラーマネージャー(KCM)からいくつかの機能群を切り離し、別のプロセスとして動かします。具体的には、KCMに含まれるクラウド依存のコントローラーを分離します。KCMは、下記に示すクラウド依存のコントローラーループを持っています: - - * ノードコントローラー - * ボリュームコントローラー - * ルートコントローラー - * サービスコントローラー - -バージョン1.9では、CCMは前述のリスト内の下記コントローラーを動かします: - -* ノードコントローラー -* ルートコントローラー -* サービスコントローラー {{< note >}} -ボリュームコントローラーは、意図的にCCMの一部になっていません。複雑さと、ベンダー固有のボリュームロジックを抽象化するのに費やした労力を考え、CCMの一部に移行しないことが決定されました。 +コントロールプレーンの一部ではなく、Kubernetesの{{< glossary_tooltip text="addon" term_id="addons" >}}としてクラウドコントローラーマネージャーを実行することもできます。 {{< /note >}} -CCMを使ったボリュームをサポートする元の計画は、プラガブルなボリュームをサポートするため、[Flex](/docs/concepts/storage/volumes/#flexVolume)ボリュームを使うことでした。しかし、競合している[CSI](/docs/concepts/storage/volumes/#csi)として知られている機能が、Flexを置き換える予定です。 +## クラウドコントローラーマネージャーの機能 {#functions-of-the-ccm} -これらのダイナミクスを考慮し、我々はCSIが利用できるようになるまで、間を取った暫定措置を取ることにしました。 - -## CCMの機能群 - -CCMは、クラウドに依存しているKubernetesのコンポーネントから機能を継承しています。このセクションはそれらのコンポーネントをベースに構造化されています。 - -### 1. Kubernetesコントローラーマネージャー - -CCMの大半の機能は、KCMから派生しています。前セクションで説明したとおり、CCMは下記のコントロールループを動かします: - -* ノードコントローラー -* ルートコントローラー -* サービスコントローラー +クラウドコントローラーマネージャーのコントローラーは以下を含んでいます。 #### ノードコントローラー -ノードコントローラーは、クラウドプロバイダーからクラスター内で稼働しているノードの情報を取得し、初期化する責務を持ちます。ノードコントローラーは下記に示す機能を実行します: +ノードコントローラーは、クラウドインフラストラクチャーで新しいサーバーが作成された際に、{{< glossary_tooltip text="Node" term_id="node" >}}オブジェクトを作成する責務を持ちます。ノードコントローラーは、クラウドプロバイダーのテナント内で動作しているホストの情報を取得します。ノードコントローラーは下記に示す機能を実行します: -1. ノードをクラウド特有のゾーン/リージョンラベルで初期化する -2. ノードをクラウド特有のインスタンス詳細情報(例、タイプ、サイズ)で初期化する -3. ノードのネットワークアドレスとホスト名を取得する -4. ノードが応答しなくなった場合、ノードがクラウドから削除されているかを確認する。クラウドからノードが削除されていた場合、KubernetesからNodeオブジェクトを削除する +1. Nodeオブジェクトを、コントローラーがクラウドプロバイダーAPIを通じて見つけた各サーバーで初期化する +2. Nodeオブジェクトに、ノードがデプロイされているリージョンや利用可能なリソース（CPU、メモリなど）のようなクラウド特有な情報を注釈付けやラベル付けをする +3. ノードのホスト名とネットワークアドレスを取得する +4. ノードの正常性を検証する。ノードが応答しなくなった場合、クラウドプロバイダーのAPIを利用しサーバーがdeactivated / deleted / terminatedであるかを確認する。クラウドからノードが削除されていた場合、KubernetesクラスターからNodeオブジェクトを削除する + +いくつかのクラウドプロバイダーは、これをノードコントローラーと分離ノードライフサイクルコントローラーに分けて実装しています。 #### ルートコントローラー -ルートコントローラーは、クラスタ内の異なるノード上で稼働しているコンテナが相互に通信できるように、クラウド内のルートを適切に設定する責務を持ちます。ルートコントローラーはGoogle Compute Engineのクラスターのみに該当します。 +ルートコントローラーは、クラスタ内の異なるノード上で稼働しているコンテナが相互に通信できるように、クラウド内のルートを適切に設定する責務を持ちます。 + +クラウドプロバイダーによっては、ルートコントローラーはPodネットワークのIPアドレスのブロックを割り当てることもあります。 #### サービスコントローラー -サービスコントローラーは、サービスの作成、更新、そして削除イベントの待ち受けに責務を持ちます。Kubernetes内のサービスの現在の状態を、クラウド上のロードバランサー(ELB、Google LB、またOracle Cloud Infrastructure LBなど)に反映するための設定を行います。さらに、クラウドロードバランサーのバックエンドが最新の状態になっていることを保証します。 - -### 2. Kubelet - -ノードコントローラーは、kubeletのクラウドに依存した機能も含んでいます。CCMの登場以前、kubeletはIPアドレス、リージョン/ゾーンラベル、そしてインスタンスタイプ情報のような、クラウド特有の情報を元にノードを初期化する責務を持っていました。CCMが登場したことで、この初期化操作がkubeletからCCMに移行されました。 - -この新しいモデルでは、kubeletはクラウド特有の情報無しでノードを初期化します。しかし、新しく作成されたノードにtaintを付けて、CCMがクラウド特有の情報でノードを初期化するまで、コンテナがスケジュールされないようにします。その後、taintを削除します。 - -## プラグインメカニズム - -クラウドコントローラーマネージャーは、Goのインターフェースを利用してクラウドの実装をプラグイン化できるようにしています。具体的には、[こちら](https://github.com/kubernetes/cloud-provider/blob/9b77dc1c384685cb732b3025ed5689dd597a5971/cloud.go#L42-L62)で定義されているクラウドプロバイダーインターフェースを利用しています。 - -上で強調した4つの共有コントローラーの実装、そしていくつかの共有クラウドプロバイダーインターフェースと一部の連携機能は、Kubernetesのコアにとどまります。クラウドプロバイダー特有の実装はコア機能外で構築され、コア機能内で定義されたインターフェースを実装します。 - -プラグインを開発するためのさらなる情報は、[クラウドコントローラーマネージャーを開発する](/docs/tasks/administer-cluster/developing-cloud-controller-manager/)を参照してください。 +{{< glossary_tooltip text="Services" term_id="service" >}}は、マネージドロードバランサー、IPアドレスネットワークパケットフィルタや対象のヘルスチェックのようなクラウドインフラストラクチャーコンポーネントのインテグレーションを行います。サービスコントローラーは、ロードバランサーや他のインフラストラクチャーコンポーネントを必要とするServiceリソースを宣言する際にそれらのコンポーネントを設定するため、クラウドプロバイダーのAPIと対話します。 ## 認可 -このセクションでは、CCMが操作を行うために様々なAPIオブジェクトに必要な権限を分類します。 +このセクションでは、クラウドコントローラーマネージャーが操作を行うために様々なAPIオブジェクトに必要な権限を分類します。 -### ノードコントローラー +### ノードコントローラー {#authorization-node-controller} -ノードコントローラーはNodeオブジェクトのみに対して働きます。Nodeオブジェクトに対して、get、list、create、update、patch、watch、そしてdeleteの全権限が必要です。 +ノードコントローラーはNodeオブジェクトのみに対して働きます。Nodeオブジェクトに対して、readとmodifyの全権限が必要です。 -v1/Node: +`v1/Node`: - Get - List @@ -117,23 +72,23 @@ v1/Node: - Watch - Delete -### ルートコントローラー +### ルートコントローラー {#authorization-route-controller} ルートコントローラーは、Nodeオブジェクトの作成を待ち受け、ルートを適切に設定します。Nodeオブジェクトについて、get権限が必要です。 -v1/Node: +`v1/Node`: - Get -### サービスコントローラー +### サービスコントローラー {#authorization-service-controller} -サービスコントローラーは、Serviceオブジェクトの作成、更新、削除イベントを待ち受け、その後、サービスのエンドポイントを適切に設定します。 +サービスコントローラーは、Serviceオブジェクトの作成、更新、削除イベントを待ち受け、その後、サービスのEndpointを適切に設定します。 サービスにアクセスするため、list、watchの権限が必要です。サービスを更新するため、patch、updateの権限が必要です。 -サービスのエンドポイントを設定するため、create、list、get、watchそしてupdateの権限が必要です。 +サービスのEndpointリソースを設定するため、create、list、get、watchそしてupdateの権限が必要です。 -v1/Service: +`v1/Service`: - List - Get @@ -141,21 +96,21 @@ v1/Service: - Patch - Update -### その他 +### その他 {#authorization-miscellaneous} -CCMコア機能の実装は、イベントのcreate権限と、セキュアな処理を保証するため、ServiceAccountのcreate権限が必要です。 +クラウドコントローラーマネージャーのコア機能の実装は、Eventオブジェクトのcreate権限と、セキュアな処理を保証するため、ServiceAccountのcreate権限が必要です。 -v1/Event: +`v1/Event`: - Create - Patch - Update -v1/ServiceAccount: +`v1/ServiceAccount`: - Create -CCMのRBAC ClusterRoleはこのようになります: +クラウドコントローラーマネージャーの{{< glossary_tooltip term_id="rbac" text="RBAC" >}} ClusterRoleはこのようになります: ```yaml apiVersion: rbac.authorization.k8s.io/v1 @@ -219,25 +174,16 @@ rules: - update ``` -## ベンダー実装 -下記のクラウドプロバイダーがCCMを実装しています: +## {{% heading "whatsnext" %}} -* [Alibaba Cloud](https://github.com/kubernetes/cloud-provider-alibaba-cloud) -* [AWS](https://github.com/kubernetes/cloud-provider-aws) -* [Azure](https://github.com/kubernetes/cloud-provider-azure) -* [BaiduCloud](https://github.com/baidu/cloud-provider-baiducloud) -* [DigitalOcean](https://github.com/digitalocean/digitalocean-cloud-controller-manager) -* [GCP](https://github.com/kubernetes/cloud-provider-gcp) -* [Hetzner](https://github.com/hetznercloud/hcloud-cloud-controller-manager) -* [Linode](https://github.com/linode/linode-cloud-controller-manager) -* [OpenStack](https://github.com/kubernetes/cloud-provider-openstack) -* [Oracle](https://github.com/oracle/oci-cloud-controller-manager) -* [TencentCloud](https://github.com/TencentCloud/tencentcloud-cloud-controller-manager) +[Cloud Controller Manager Administration](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager) +はクラウドコントラーマネージャーの実行と管理を説明しています。 +どのようにあなた自身のクラウドコントローラーマネージャーが実装されるのか、もしくは既存プロジェクトの拡張について知りたいですか？ -## クラスター管理 - -CCMを設定、動かすための完全な手順は[こちら](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager)で提供されています。 +クラウドコントローラーマネージェーは、いかなるクラウドからもプラグインとしての実装を許可するためにGoインターフェースを使います。具体的には、 [kubernetes/cloud-provider](https://github.com/kubernetes/cloud-provider)の [`cloud.go`](https://github.com/kubernetes/cloud-provider/blob/release-1.17/cloud.go#L42-L62)で定義されている`CloudProvider`を使います。 +本ドキュメントでハイライトした共有コントローラー（Node、Route、Service）の実装と共有クラウドプロバイダーインターフェースに沿ったいくつかの足場は、Kubernetesコアの一部です。クラウドプロバイダに特化した実装は、Kubernetesのコアの外部として、また`CloudProvider`インターフェースを実装します。 +プラグイン開発ついての詳細な情報は、[Developing Cloud Controller Manager](/docs/tasks/administer-cluster/developing-cloud-controller-manager/)を見てください。 diff --git a/content/ja/docs/reference/glossary/cloud-controller-manager.md b/content/ja/docs/reference/glossary/cloud-controller-manager.md new file mode 100755 index 0000000000..6e9c9104da --- /dev/null +++ b/content/ja/docs/reference/glossary/cloud-controller-manager.md @@ -0,0 +1,18 @@ +--- +title: クラウドコントローラーマネージャー +id: cloud-controller-manager +date: 2018-04-12 +full_link: /ja/docs/concepts/architecture/cloud-controller/ +short_description: > + サードパーティクラウドプロバイダーにKubernetewを結合するコントロールプレーンコンポーネント +aka: +tags: +- core-object +- architecture +- operation +--- + クラウド特有の制御ロジックを組み込むKubernetesの{{< glossary_tooltip text="control plane" term_id="control-plane" >}}コンポーネントです。クラウドコントロールマネージャーは、クラスターをクラウドプロバイダーAPIをリンクし、クラスタのみで相互作用するコンポーネントからクラウドプラットフォームで相互作用するコンポーネントを分離します。 + + + +Kubernetesと下のクラウドインフラストラクチャー間の相互運用ロジックを分離することで、cloud-controller-managerコンポーネントはクラウドプロバイダを主なKubernetesプロジェクトと比較し異なるペースで機能をリリース可能にします。 From 26d4a99925741005207e280c1df7c3d462cbc663 Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Mon, 24 Aug 2020 11:58:42 +0900 Subject: [PATCH 138/252] fix commented words --- content/ja/docs/concepts/architecture/cloud-controller.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/architecture/cloud-controller.md b/content/ja/docs/concepts/architecture/cloud-controller.md index 0bff2a504e..e3803a2a0c 100644 --- a/content/ja/docs/concepts/architecture/cloud-controller.md +++ b/content/ja/docs/concepts/architecture/cloud-controller.md @@ -8,7 +8,7 @@ weight: 40 {{< feature-state state="beta" for_k8s_version="v1.11" >}} -クラウドインフラストラクチャ技術により、パブリック、プライベート、ハイブリッドクラウド上でKubernetesを動かすことができます。Kubernetesは、コンポーネント間の密なつながりが不要な自動化されたAPI駆動インフラストラクチャーであると考えられています。 +クラウドインフラストラクチャー技術により、パブリック、プライベート、ハイブリッドクラウド上でKubernetesを動かすことができます。Kubernetesは、コンポーネント間の密なつながりが不要な自動化されたAPI駆動インフラストラクチャーであると考えられています。 {{< glossary_definition term_id="cloud-controller-manager" length="all" prepend="cloud-controller-managerは">}} @@ -20,7 +20,7 @@ cloud-controller-managerは、プラグインメカニズムを用い、異な ## 設計 -![Kubernetes components](/images/docs/components-of-kubernetes.png) +![Kubernetesのコンポーネント](/images/docs/components-of-kubernetes.png) クラウドコントローラーマネージャーは、複製されたプロセスのセットとしてコントロールプレーンで実行されます。（通常、Pod内のコンテナとなります）各cloud-controller-managerは、シングルプロセスで複数の{{< glossary_tooltip text="controllers" term_id="controller" >}}を実装します。 From a1d78a3b866ef615513f4fc8f89884cd3a65defc Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Tue, 25 Aug 2020 17:07:13 +0900 Subject: [PATCH 139/252] fix some commented words --- content/ja/docs/concepts/architecture/cloud-controller.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/ja/docs/concepts/architecture/cloud-controller.md b/content/ja/docs/concepts/architecture/cloud-controller.md index e3803a2a0c..41761554ee 100644 --- a/content/ja/docs/concepts/architecture/cloud-controller.md +++ b/content/ja/docs/concepts/architecture/cloud-controller.md @@ -12,7 +12,7 @@ weight: 40 {{< glossary_definition term_id="cloud-controller-manager" length="all" prepend="cloud-controller-managerは">}} -cloud-controller-managerは、プラグインメカニズムを用い、異なるクラウドプロバイダーに対してそれぞれのプラットフォームとKubernetesの結合を可能にする構成になっています。 +cloud-controller-managerは、プラグイン機構を用い、異なるクラウドプロバイダーに対してそれぞれのプラットフォームとKubernetesの結合を可能にする構成になっています。 @@ -22,7 +22,7 @@ cloud-controller-managerは、プラグインメカニズムを用い、異な ![Kubernetesのコンポーネント](/images/docs/components-of-kubernetes.png) -クラウドコントローラーマネージャーは、複製されたプロセスのセットとしてコントロールプレーンで実行されます。（通常、Pod内のコンテナとなります）各cloud-controller-managerは、シングルプロセスで複数の{{< glossary_tooltip text="controllers" term_id="controller" >}}を実装します。 +クラウドコントローラーマネージャーは、複製されたプロセスの集合としてコントロールプレーンで実行されます。（通常、Pod内のコンテナとなります）各cloud-controller-managerは、シングルプロセスで複数の{{< glossary_tooltip text="controllers" term_id="controller" >}}を実装します。 {{< note >}} @@ -182,7 +182,7 @@ rules: どのようにあなた自身のクラウドコントローラーマネージャーが実装されるのか、もしくは既存プロジェクトの拡張について知りたいですか？ -クラウドコントローラーマネージェーは、いかなるクラウドからもプラグインとしての実装を許可するためにGoインターフェースを使います。具体的には、 [kubernetes/cloud-provider](https://github.com/kubernetes/cloud-provider)の [`cloud.go`](https://github.com/kubernetes/cloud-provider/blob/release-1.17/cloud.go#L42-L62)で定義されている`CloudProvider`を使います。 +クラウドコントローラーマネージャーは、いかなるクラウドからもプラグインとしての実装を許可するためにGoインターフェースを使います。具体的には、 [kubernetes/cloud-provider](https://github.com/kubernetes/cloud-provider)の [`cloud.go`](https://github.com/kubernetes/cloud-provider/blob/release-1.17/cloud.go#L42-L62)で定義されている`CloudProvider`を使います。 本ドキュメントでハイライトした共有コントローラー（Node、Route、Service）の実装と共有クラウドプロバイダーインターフェースに沿ったいくつかの足場は、Kubernetesコアの一部です。クラウドプロバイダに特化した実装は、Kubernetesのコアの外部として、また`CloudProvider`インターフェースを実装します。 From 57e3ee6069f9ca71d1d1f054b1ede27a9b824588 Mon Sep 17 00:00:00 2001 From: yu-kasuya Date: Thu, 17 Sep 2020 12:55:44 +0900 Subject: [PATCH 140/252] Apply suggestions from code review Co-authored-by: Keita Akutsu --- content/ja/docs/concepts/architecture/cloud-controller.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/architecture/cloud-controller.md b/content/ja/docs/concepts/architecture/cloud-controller.md index 41761554ee..8cdd5f21c0 100644 --- a/content/ja/docs/concepts/architecture/cloud-controller.md +++ b/content/ja/docs/concepts/architecture/cloud-controller.md @@ -8,7 +8,7 @@ weight: 40 {{< feature-state state="beta" for_k8s_version="v1.11" >}} -クラウドインフラストラクチャー技術により、パブリック、プライベート、ハイブリッドクラウド上でKubernetesを動かすことができます。Kubernetesは、コンポーネント間の密なつながりが不要な自動化されたAPI駆動インフラストラクチャーであると考えられています。 +クラウドインフラストラクチャー技術により、パブリック、プライベート、ハイブリッドクラウド上でKubernetesを動かすことができます。Kubernetesは、コンポーネント間の密なつながりが不要な自動化されたAPI駆動インフラストラクチャーを信条としています。 {{< glossary_definition term_id="cloud-controller-manager" length="all" prepend="cloud-controller-managerは">}} @@ -42,7 +42,7 @@ cloud-controller-managerは、プラグイン機構を用い、異なるクラ 3. ノードのホスト名とネットワークアドレスを取得する 4. ノードの正常性を検証する。ノードが応答しなくなった場合、クラウドプロバイダーのAPIを利用しサーバーがdeactivated / deleted / terminatedであるかを確認する。クラウドからノードが削除されていた場合、KubernetesクラスターからNodeオブジェクトを削除する -いくつかのクラウドプロバイダーは、これをノードコントローラーと分離ノードライフサイクルコントローラーに分けて実装しています。 +いくつかのクラウドプロバイダーは、これをノードコントローラーと個別のノードライフサイクルコントローラーに分けて実装しています。 #### ルートコントローラー From 77c4cf3dc2d330b72c54aaf31a25326da29c6afc Mon Sep 17 00:00:00 2001 From: yu-kasuya Date: Thu, 17 Sep 2020 15:53:15 +0900 Subject: [PATCH 141/252] Apply suggestions from code review Co-authored-by: inductor(Kohei) --- content/ja/docs/concepts/architecture/cloud-controller.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/architecture/cloud-controller.md b/content/ja/docs/concepts/architecture/cloud-controller.md index 8cdd5f21c0..cf86ec011b 100644 --- a/content/ja/docs/concepts/architecture/cloud-controller.md +++ b/content/ja/docs/concepts/architecture/cloud-controller.md @@ -182,7 +182,7 @@ rules: どのようにあなた自身のクラウドコントローラーマネージャーが実装されるのか、もしくは既存プロジェクトの拡張について知りたいですか？ -クラウドコントローラーマネージャーは、いかなるクラウドからもプラグインとしての実装を許可するためにGoインターフェースを使います。具体的には、 [kubernetes/cloud-provider](https://github.com/kubernetes/cloud-provider)の [`cloud.go`](https://github.com/kubernetes/cloud-provider/blob/release-1.17/cloud.go#L42-L62)で定義されている`CloudProvider`を使います。 +クラウドコントローラーマネージャーは、いかなるクラウドからもプラグインとしての実装を許可するためにGoインターフェースを使います。具体的には、[kubernetes/cloud-provider](https://github.com/kubernetes/cloud-provider)の [`cloud.go`](https://github.com/kubernetes/cloud-provider/blob/release-1.17/cloud.go#L42-L62)で定義されている`CloudProvider`を使います。 本ドキュメントでハイライトした共有コントローラー（Node、Route、Service）の実装と共有クラウドプロバイダーインターフェースに沿ったいくつかの足場は、Kubernetesコアの一部です。クラウドプロバイダに特化した実装は、Kubernetesのコアの外部として、また`CloudProvider`インターフェースを実装します。 From ff29a34608d8840b9596ae6b2aa63b1aa0457f9d Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Thu, 10 Sep 2020 19:13:57 +0900 Subject: [PATCH 142/252] translate components.md --- content/ja/docs/concepts/overview/components.md | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/content/ja/docs/concepts/overview/components.md b/content/ja/docs/concepts/overview/components.md index a70f3d2e97..78d868581d 100644 --- a/content/ja/docs/concepts/overview/components.md +++ b/content/ja/docs/concepts/overview/components.md @@ -1,6 +1,8 @@ --- title: Kubernetesのコンポーネント content_type: concept +description: > + Kubernetesクラスターはコントロールプレーンやノードと呼ばれるマシン群といったコンポーネントからなります。 weight: 20 card: name: concepts @@ -53,18 +55,17 @@ Kubernetesをデプロイすると、クラスターが展開されます。 ### cloud-controller-manager -[cloud-controller-manager](/docs/tasks/administer-cluster/running-cloud-controller/) は、基盤であるクラウドプロバイダーと対話するコントローラーを実行します。 -cloud-controller-managerバイナリは、Kubernetesリリース1.6で導入された機能です。 +{{< glossary_definition term_id="cloud-controller-manager" length="short" >}} -cloud-controller-managerは、クラウドプロバイダー固有のコントローラーループのみを実行します。これらのコントローラーループはkube-controller-managerで無効にする必要があります。 kube-controller-managerの起動時に `--cloud-provider` フラグを `external` に設定することで、コントローラーループを無効にできます。 +cloud-controller-managerは、クラウドプロバイダー固有のコントローラーのみを実行します。 +KubernetesをオンプレミスあるいはPC内での学習環境で動かす際には、クラスターにcloud container managerはありません。 -cloud-controller-managerを使用すると、クラウドベンダーのコードとKubernetesコードを互いに独立して進化させることができます。以前のリリースでは、コアKubernetesコードは、機能的にクラウドプロバイダー固有のコードに依存していました。将来のリリースでは、クラウドベンダーに固有のコードはクラウドベンダー自身で管理し、Kubernetesの実行中にcloud-controller-managerにリンクする必要があります。 +kube-controller-managerを使用すると、cloud-controller-managerは複数の論理的に独立したコントロールループをシングルバイナリにまとめ、これが一つのプロセスとして動作します。 -次のコントローラーには、クラウドプロバイダーへの依存関係があります。 +次のコントローラーには、クラウドプロバイダーへの依存関係を持つ可能性があります。 * ノードコントローラー：ノードが応答を停止した後、クラウドで削除されたかどうかを判断するため、クラウドプロバイダーをチェックします。 * ルーティングコントローラー：基盤であるクラウドインフラでルーティングを設定します。 - * サービスコントローラー：クラウドプロバイダーのロードバランサーの作成、更新、削除を行います。 * ボリュームコントローラー：ボリュームを作成、アタッチ、マウントしたり、クラウドプロバイダーとやり取りしてボリュームを調整したりします。 ## ノードコンポーネント {#node-components} From 6f905f2a581c837254fd5eeefcdcd3a6ad53763f Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Thu, 17 Sep 2020 20:27:29 +0900 Subject: [PATCH 143/252] apply suggestions --- "content/ja/docs/concepts/overview/\\" | 121 ++++++++++++++++++ .../ja/docs/concepts/overview/components.md | 5 +- 2 files changed, 123 insertions(+), 3 deletions(-) create mode 100644 "content/ja/docs/concepts/overview/\\" diff --git "a/content/ja/docs/concepts/overview/\\" "b/content/ja/docs/concepts/overview/\\" new file mode 100644 index 0000000000..dbea76db1d --- /dev/null +++ "b/content/ja/docs/concepts/overview/\\" @@ -0,0 +1,121 @@ +--- +title: Kubernetesのコンポーネント +content_type: concept +description: > + Kubernetesクラスターはコントロールプレーンやノードと呼ばれるマシン群といったコンポーネントからなります。 +weight: 20 +card: + name: concepts + weight: 20 +--- + + +Kubernetesをデプロイすると、クラスターが展開されます。 +{{< glossary_definition term_id="cluster" length="all" prepend="Kubernetesクラスターは、">}} + +このドキュメントでは、Kubernetesクラスターが機能するために必要となるさまざまなコンポーネントの概要を説明します。 + +すべてのコンポーネントが結び付けられたKubernetesクラスターの図を次に示します。 + +![Kubernetesのコンポーネント](/images/docs/components-of-kubernetes.png) + + + + + +## コントロールプレーンコンポーネント + +コントロールプレーンコンポーネントは、クラスターに関する全体的な決定(スケジューリングなど)を行います。また、クラスターイベントの検出および応答を行います(たとえば、deploymentの`replicas`フィールドが満たされていない場合に、新しい {{< glossary_tooltip text="Pod" term_id="pod">}} を起動する等)。 + +コントロールプレーンコンポーネントはクラスター内のどのマシンでも実行できますが、シンプルにするため、セットアップスクリプトは通常、すべてのコントロールプレーンコンポーネントを同じマシンで起動し、そのマシンではユーザーコンテナを実行しません。 +マルチマスター VMセットアップの例については、[高可用性クラスターの構築](/docs/admin/high-availability/) を参照してください。 + +### kube-apiserver + +{{< glossary_definition term_id="kube-apiserver" length="all" >}} + +### etcd + +{{< glossary_definition term_id="etcd" length="all" >}} + +### kube-scheduler + +{{< glossary_definition term_id="kube-scheduler" length="all" >}} + +### kube-controller-manager + +{{< glossary_definition term_id="kube-controller-manager" length="all" >}} + +コントローラーには以下が含まれます。 + + * ノードコントローラー：ノードがダウンした場合の通知と対応を担当します。 + * レプリケーションコントローラー：システム内の全レプリケーションコントローラーオブジェクトについて、Podの数を正しく保つ役割を持ちます。 + * エンドポイントコントローラー：エンドポイントオブジェクトを注入します(つまり、ServiceとPodを紐付けます)。 + * サービスアカウントとトークンコントローラー：新規の名前空間に対して、デフォルトアカウントとAPIアクセストークンを作成します。 + +### cloud-controller-manager + +{{< glossary_definition term_id="cloud-controller-manager" length="short" >}} + +cloud-controller-managerは、クラウドプロバイダー固有のコントローラーのみを実行します。 +KubernetesをオンプレミスあるいはPC内での学習環境で動かす際には、クラスターにcloud container managerはありません。 + +kube-controller-managerを使用すると、cloud-controller-managerは複数の論理的に独立したコントロールループをシングルバイナリにまとめ、これが一つのプロセスとして動作します。パフォーマンスを向上させるあるいは障害に耐えるために水平方向にスケールする(一つ以上のコピーを動かす)ことができます。 + +次のコントローラーには、クラウドプロバイダーへの依存関係を持つ可能性があります。 + + * ノードコントローラー：ノードが応答を停止した後、クラウドで削除されたかどうかを判断するため、クラウドプロバイダーをチェックします。 + * ルーティングコントローラー：基盤であるクラウドインフラでルーティングを設定します。 + * サービスコントローラー：クラウドプロバイダーのロードバランサーの作成、更新、削除を行います。 +## ノードコンポーネント {#node-components} + +ノードコンポーネントはすべてのノードで実行され、稼働中のPodの管理やKubernetesの実行環境を提供します。 + +### kubelet + +{{< glossary_definition term_id="kubelet" length="all" >}} + +### kube-proxy + +{{< glossary_definition term_id="kube-proxy" length="all" >}} + +### コンテナランタイム {#container-runtime} + +{{< glossary_definition term_id="container-runtime" length="all" >}} + +## アドオン + +アドオンはクラスター機能を実装するためにKubernetesリソース({{< glossary_tooltip term_id="daemonset" >}}、{{< glossary_tooltip term_id="deployment" >}}など)を使用します。 +アドオンはクラスターレベルの機能を提供しているため、アドオンのリソースで名前空間が必要なものは`kube-system`名前空間に属します。 + +いくつかのアドオンについて以下で説明します。より多くの利用可能なアドオンのリストは、[アドオン](/docs/concepts/cluster-administration/addons/) をご覧ください。 + +### DNS + +クラスターDNS以外のアドオンは必須ではありませんが、すべてのKubernetesクラスターは[クラスターDNS](/ja/docs/concepts/services-networking/dns-pod-service/)を持つべきです。多くの使用例がクラスターDNSを前提としています。 + +クラスターDNSは、環境内の他のDNSサーバーに加えて、KubernetesサービスのDNSレコードを提供するDNSサーバーです。 + +Kubernetesによって開始されたコンテナは、DNS検索にこのDNSサーバーを自動的に含めます。 + + +### Web UI (ダッシュボード) + +[ダッシュボード](/ja/docs/tasks/access-application-cluster/web-ui-dashboard/)は、Kubernetesクラスター用の汎用WebベースUIです。これによりユーザーはクラスターおよびクラスター内で実行されているアプリケーションについて、管理およびトラブルシューティングを行うことができます。 + +### コンテナリソース監視 + +[コンテナリソース監視](/docs/tasks/debug-application-cluster/resource-usage-monitoring/)は、コンテナに関する一般的な時系列メトリックを中央データベースに記録します。また、そのデータを閲覧するためのUIを提供します。 + +### クラスターレベルログ + +[クラスターレベルログ](/docs/concepts/cluster-administration/logging/)メカニズムは、コンテナのログを、検索／参照インターフェイスを備えた中央ログストアに保存します。 + + +## {{% heading "whatsnext" %}} + +* [ノード](/ja/docs/concepts/architecture/nodes/)について学ぶ +* [コントローラー](/docs/concepts/architecture/controller/)について学ぶ +* [kube-scheduler](/ja/docs/concepts/scheduling-eviction/kube-scheduler/)について学ぶ +* etcdの公式 [ドキュメント](https://etcd.io/docs/)を読む + diff --git a/content/ja/docs/concepts/overview/components.md b/content/ja/docs/concepts/overview/components.md index 78d868581d..dbea76db1d 100644 --- a/content/ja/docs/concepts/overview/components.md +++ b/content/ja/docs/concepts/overview/components.md @@ -60,14 +60,13 @@ Kubernetesをデプロイすると、クラスターが展開されます。 cloud-controller-managerは、クラウドプロバイダー固有のコントローラーのみを実行します。 KubernetesをオンプレミスあるいはPC内での学習環境で動かす際には、クラスターにcloud container managerはありません。 -kube-controller-managerを使用すると、cloud-controller-managerは複数の論理的に独立したコントロールループをシングルバイナリにまとめ、これが一つのプロセスとして動作します。 +kube-controller-managerを使用すると、cloud-controller-managerは複数の論理的に独立したコントロールループをシングルバイナリにまとめ、これが一つのプロセスとして動作します。パフォーマンスを向上させるあるいは障害に耐えるために水平方向にスケールする(一つ以上のコピーを動かす)ことができます。 次のコントローラーには、クラウドプロバイダーへの依存関係を持つ可能性があります。 * ノードコントローラー：ノードが応答を停止した後、クラウドで削除されたかどうかを判断するため、クラウドプロバイダーをチェックします。 * ルーティングコントローラー：基盤であるクラウドインフラでルーティングを設定します。 - * ボリュームコントローラー：ボリュームを作成、アタッチ、マウントしたり、クラウドプロバイダーとやり取りしてボリュームを調整したりします。 - + * サービスコントローラー：クラウドプロバイダーのロードバランサーの作成、更新、削除を行います。 ## ノードコンポーネント {#node-components} ノードコンポーネントはすべてのノードで実行され、稼働中のPodの管理やKubernetesの実行環境を提供します。 From ff381e1444e2b1e437ed216e25885edc36793053 Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Mon, 14 Sep 2020 14:34:53 +0900 Subject: [PATCH 144/252] Update field-selectors.md --- .../overview/working-with-objects/field-selectors.md | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/content/ja/docs/concepts/overview/working-with-objects/field-selectors.md b/content/ja/docs/concepts/overview/working-with-objects/field-selectors.md index ddf947212d..38415d294c 100644 --- a/content/ja/docs/concepts/overview/working-with-objects/field-selectors.md +++ b/content/ja/docs/concepts/overview/working-with-objects/field-selectors.md @@ -17,12 +17,7 @@ kubectl get pods --field-selector status.phase=Running ``` {{< note >}} -フィールドセレクターは本質的にリソースの _フィルター_ となります。デフォルトでは、セレクター/フィルターが指定されていない場合は、全てのタイプのリソースが取得されます。これは、下記の2つの`kubectl`クエリが同じであることを意味します。 - -```shell -kubectl get pods -kubectl get pods --field-selector "" -``` +フィールドセレクターは本質的にリソースの _フィルター_ となります。デフォルトでは、セレクター/フィルターが指定されていない場合は、全てのタイプのリソースが取得されます。これは、以下の2つの`kubectl`クエリ`kubectl get pods`と`kubectl get pods --field-selector ""`が同じであることを意味します。 {{< /note >}} ## サポートされているフィールド From a045acfe9435590f6580e0953c0de44fe73a6478 Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Tue, 15 Sep 2020 23:21:41 +0900 Subject: [PATCH 145/252] apply a suggestion from review --- .../concepts/overview/working-with-objects/field-selectors.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/overview/working-with-objects/field-selectors.md b/content/ja/docs/concepts/overview/working-with-objects/field-selectors.md index 38415d294c..78930a469a 100644 --- a/content/ja/docs/concepts/overview/working-with-objects/field-selectors.md +++ b/content/ja/docs/concepts/overview/working-with-objects/field-selectors.md @@ -17,7 +17,7 @@ kubectl get pods --field-selector status.phase=Running ``` {{< note >}} -フィールドセレクターは本質的にリソースの _フィルター_ となります。デフォルトでは、セレクター/フィルターが指定されていない場合は、全てのタイプのリソースが取得されます。これは、以下の2つの`kubectl`クエリ`kubectl get pods`と`kubectl get pods --field-selector ""`が同じであることを意味します。 +フィールドセレクターは本質的にリソースの _フィルター_ となります。デフォルトでは、セレクター/フィルターが指定されていない場合は、全てのタイプのリソースが取得されます。これは、`kubectl`クエリの`kubectl get pods`と`kubectl get pods --field-selector ""`が同じであることを意味します。 {{< /note >}} ## サポートされているフィールド From d98ea890c20e2a04e2ca5be0d4ddce764afb0918 Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Wed, 9 Sep 2020 12:45:05 +0900 Subject: [PATCH 146/252] Update ja/docs/reference/glossary/platform-developer.md --- content/ja/docs/reference/glossary/platform-developer.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/reference/glossary/platform-developer.md b/content/ja/docs/reference/glossary/platform-developer.md index e5526cedf8..2c1452a5d9 100755 --- a/content/ja/docs/reference/glossary/platform-developer.md +++ b/content/ja/docs/reference/glossary/platform-developer.md @@ -14,4 +14,4 @@ tags: -プラットフォーム開発者は、特に自身のアプリケーションのために、例えば[カスタムリソース](/docs/concepts/api-extension/custom-resources/)や[集約レイヤーを使ったKubernetes APIの拡張](/docs/concepts/api-extension/apiserver-aggregation/)を用いて、Kubernetesに機能を追加ことがあるかもしれません。一部のプラットフォーム開発者はまた{{< glossary_tooltip text="コントリビューター" term_id="contributor" >}}として、エクステンションを開発しKubernetesのコミュニティに貢献しています。他の方々は、クローズドソースな商用もしくは、サイト固有なエクステンションを開発しています。 +プラットフォーム開発者は、特に自身のアプリケーションのために、例えば[カスタムリソース](/ja/docs/concepts/extend-Kubernetes/api-extension/custom-resources/)や[集約レイヤーを使ったKubernetes APIの拡張](/ja/docs/concepts/extend-Kubernetes/api-extension/apiserver-aggregation/)を用いて、Kubernetesに機能を追加ことがあるかもしれません。一部のプラットフォーム開発者はまた{{< glossary_tooltip text="コントリビューター" term_id="contributor" >}}として、エクステンションを開発しKubernetesのコミュニティに貢献しています。他の方々は、クローズドソースな商用もしくは、サイト固有なエクステンションを開発しています。 From db9eb1d2157b9569c18d88b6f08c1ae25825ed05 Mon Sep 17 00:00:00 2001 From: yu-kasuya Date: Tue, 15 Sep 2020 12:13:50 +0900 Subject: [PATCH 147/252] Apply suggestions from code review Co-authored-by: inductor(Kohei) --- content/ja/docs/reference/glossary/platform-developer.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/reference/glossary/platform-developer.md b/content/ja/docs/reference/glossary/platform-developer.md index 2c1452a5d9..be1e695184 100755 --- a/content/ja/docs/reference/glossary/platform-developer.md +++ b/content/ja/docs/reference/glossary/platform-developer.md @@ -14,4 +14,4 @@ tags: -プラットフォーム開発者は、特に自身のアプリケーションのために、例えば[カスタムリソース](/ja/docs/concepts/extend-Kubernetes/api-extension/custom-resources/)や[集約レイヤーを使ったKubernetes APIの拡張](/ja/docs/concepts/extend-Kubernetes/api-extension/apiserver-aggregation/)を用いて、Kubernetesに機能を追加ことがあるかもしれません。一部のプラットフォーム開発者はまた{{< glossary_tooltip text="コントリビューター" term_id="contributor" >}}として、エクステンションを開発しKubernetesのコミュニティに貢献しています。他の方々は、クローズドソースな商用もしくは、サイト固有なエクステンションを開発しています。 +プラットフォーム開発者は、特に自身のアプリケーションのために、例えば[カスタムリソース](/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources/)や[集約レイヤーを使ったKubernetes APIの拡張](/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)を用いて、Kubernetesに機能を追加ことがあるかもしれません。一部のプラットフォーム開発者はまた{{< glossary_tooltip text="コントリビューター" term_id="contributor" >}}として、エクステンションを開発しKubernetesのコミュニティに貢献しています。他の方々は、クローズドソースな商用もしくは、サイト固有なエクステンションを開発しています。 From dc35c7053045dcd5326c8cb53f02535bbea1d746 Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Thu, 10 Sep 2020 12:41:36 +0900 Subject: [PATCH 148/252] Update ja/docs/reference/glossary/statefulset.md --- content/ja/docs/reference/glossary/statefulset.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/content/ja/docs/reference/glossary/statefulset.md b/content/ja/docs/reference/glossary/statefulset.md index 1fad77bd62..d631bb7628 100755 --- a/content/ja/docs/reference/glossary/statefulset.md +++ b/content/ja/docs/reference/glossary/statefulset.md @@ -4,7 +4,7 @@ id: statefulset date: 2018-04-12 full_link: /ja/docs/concepts/workloads/controllers/statefulset/ short_description: > - StatefulSetはDeploymentとPodのセットのスケーリングを管理し、それらのPodの *順序と一意性を保証* します。 + StatefulSetはDeploymentとPodのセットのスケーリングを管理します、永続化ストレージと各Podの永続的な識別子を備えています。 aka: tags: @@ -20,5 +20,4 @@ StatefulSetはDeploymentと{{< glossary_tooltip text="Pod" term_id="pod" >}}の {{< glossary_tooltip term_id="deployment" >}}のように、StatefulSetは指定したコンテナのspecに基づいてPodを管理します。Deploymentとは異なり、StatefulSetは各Podにおいて管理が大変な同一性を維持します。これらのPodは同一のspecから作成されますが、それらは交換可能ではなく、リスケジュール処理をまたいで維持される永続的な識別子を持ちます。 -StatefulSetは他のコントローラーと同様のパターンで動作します。ユーザーはStatefulSet*オブジェクト* の理想的な状態を定義し、StatefulSet*コントローラー* は現在の状態から、理想状態になるために必要なアップデートを行います。 - +ワークロードに永続性を持たせるためにストレージボリュームを使いたい場合は、解決策の1つとしてStatefulSetが利用できます。StatefulSet内の個々のPodは障害の影響を受けやすいですが、永続化したPodの識別子は既存のボリュームと障害によって置換された新しいPodの紐付けを簡単にします。 From 594ffa7cc3dfa5148b00fc72764d9ba8213b0dff Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Tue, 15 Sep 2020 12:12:27 +0900 Subject: [PATCH 149/252] update some words following comment --- content/ja/docs/reference/glossary/statefulset.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/reference/glossary/statefulset.md b/content/ja/docs/reference/glossary/statefulset.md index d631bb7628..eb78c21fe3 100755 --- a/content/ja/docs/reference/glossary/statefulset.md +++ b/content/ja/docs/reference/glossary/statefulset.md @@ -4,7 +4,7 @@ id: statefulset date: 2018-04-12 full_link: /ja/docs/concepts/workloads/controllers/statefulset/ short_description: > - StatefulSetはDeploymentとPodのセットのスケーリングを管理します、永続化ストレージと各Podの永続的な識別子を備えています。 + StatefulSetはDeploymentとPodのセットのスケーリングを管理し、永続化ストレージと各Podの永続的な識別子を備えています。 aka: tags: From c7c7461d9468c8b30e9ed2800096072cc27eaa91 Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Tue, 15 Sep 2020 12:53:27 +0900 Subject: [PATCH 150/252] Update ja/docs/tasks/configure-pod-container/assign-cpu-resource.md --- .../assign-cpu-resource.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/content/ja/docs/tasks/configure-pod-container/assign-cpu-resource.md b/content/ja/docs/tasks/configure-pod-container/assign-cpu-resource.md index 8091ded576..3d0f2bb9a2 100644 --- a/content/ja/docs/tasks/configure-pod-container/assign-cpu-resource.md +++ b/content/ja/docs/tasks/configure-pod-container/assign-cpu-resource.md @@ -16,7 +16,7 @@ weight: 20 {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -クラスターの各ノードには、少なくとも1つ以上のCPUが必要になります。 +タスク例を実行するには、クラスターに少なくとも利用可能な1 CPUが必要です。 このページのいくつかの手順では、クラスターにて[metrics-server](https://github.com/kubernetes-incubator/metrics-server)サービスを実行する必要があります。すでにmetrics-serverが動作している場合、これらの手順をスキップできます。 @@ -106,7 +106,7 @@ cpu-demo 974m `-cpu "2"`を設定することで、コンテナが2 CPU利用しようとすることを思い出してください。しかしながら、コンテナは約1 CPUしか使用することができません。コンテナが制限よりも多くのCPUリソースを利用しようとしているため、コンテナのCPUの利用が抑制されています。 {{< note >}} -CPUの使用量が1.0未満である理由の可能性して、ノードに利用可能なCPUリソースが十分にないことが挙げられます。この練習における必要条件として、各ノードに少なくとも1 CPUが必要であることを思い出してください。1 CPUのノード上でコンテナを実行させる場合、指定したコンテナのCPU制限にかかわらず、コンテナは1 CPU以上使用することはできません。 +CPUの使用量が1.0未満である理由の可能性して、ノードに利用可能なCPUリソースが十分にないことが挙げられます。この練習における必要条件として、クラスターに少なくとも利用可能な1 CPUが必要であることを思い出してください。1 CPUのノード上でコンテナを実行させる場合、指定したコンテナのCPU制限にかかわらず、コンテナは1 CPU以上使用することはできません。 {{< /note >}} ## CPUの単位 @@ -222,17 +222,17 @@ kubectl delete namespace cpu-example ### クラスター管理者向け -* [Namespaceにメモリー要求および制限のデフォルト値を設定する](/docs/tasks/administer-cluster/memory-default-namespace/) +* [Namespaceにメモリー要求および制限のデフォルト値を設定する](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/) -* [NamespaceにCPU要求および制限のデフォルト値を設定する](/docs/tasks/administer-cluster/cpu-default-namespace/) +* [NamespaceにCPU要求および制限のデフォルト値を設定する](/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/) -* [Namespaceに最小および最大メモリー量の制約を設定する](/docs/tasks/administer-cluster/memory-constraint-namespace/) +* [Namespaceに最小および最大メモリー量の制約を設定する](/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/) -* [Namespaceに最小および最大のCPU使用量の制約を設定する](/docs/tasks/administer-cluster/cpu-constraint-namespace/) +* [Namespaceに最小および最大のCPU使用量の制約を設定する](/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/) -* [NamespaceにメモリーおよびCPUのクォータを設定する](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/) +* [NamespaceにメモリーおよびCPUのクォータを設定する](/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/) -* [NamespaceにPodのクォータを設定する](/docs/tasks/administer-cluster/quota-pod-namespace/) +* [NamespaceにPodのクォータを設定する](/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace/) * [APIオブジェクトのクォータを設定する](/docs/tasks/administer-cluster/quota-api-object/) From 746fa8c1f7c766466a0cb0f7893f0303e581ff3a Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Wed, 16 Sep 2020 15:01:29 +0900 Subject: [PATCH 151/252] delete some lines --- .../docs/tasks/configure-pod-container/assign-cpu-resource.md | 3 --- 1 file changed, 3 deletions(-) diff --git a/content/ja/docs/tasks/configure-pod-container/assign-cpu-resource.md b/content/ja/docs/tasks/configure-pod-container/assign-cpu-resource.md index 3d0f2bb9a2..1be44e3a75 100644 --- a/content/ja/docs/tasks/configure-pod-container/assign-cpu-resource.md +++ b/content/ja/docs/tasks/configure-pod-container/assign-cpu-resource.md @@ -152,9 +152,6 @@ kubectl get pod cpu-demo-2 --namespace=cpu-example この出力では、Podのステータスが待機中であることを示しています。つまり、Podがどのノードに対しても実行するようスケジュールされておらず、いつまでも待機状態のままであることを表しています: -```shell -kubectl get pod cpu-demo-2 --namespace=cpu-example -``` ``` NAME READY STATUS RESTARTS AGE cpu-demo-2 0/1 Pending 0 7m From dcc613eaf18d9e5de980a0ff45dd74f2d53aa976 Mon Sep 17 00:00:00 2001 From: daisuke0131 Date: Thu, 17 Sep 2020 00:35:16 +0900 Subject: [PATCH 152/252] Update namespaces.md --- .../overview/working-with-objects/namespaces.md | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/content/ja/docs/concepts/overview/working-with-objects/namespaces.md b/content/ja/docs/concepts/overview/working-with-objects/namespaces.md index 12de8e10df..f9ebbabffd 100644 --- a/content/ja/docs/concepts/overview/working-with-objects/namespaces.md +++ b/content/ja/docs/concepts/overview/working-with-objects/namespaces.md @@ -33,6 +33,10 @@ Kubernetesの将来的なバージョンにおいて、同一のNamespace内の Namespaceの作成と削除方法は[Namespaceの管理ガイドドキュメント](/docs/tasks/administer-cluster/namespaces/)に記載されています。 +{{< note >}} +　　プレフィックス`kube-`を持つNamespaceは、KubernetesシステムのNamespaceとして予約されているため利用は避けてください。 +{{< /note >}} + ### Namespaceの表示 ユーザーは、以下の方法で単一クラスター内の現在のNamespaceの一覧を表示できます。 @@ -41,18 +45,20 @@ Namespaceの作成と削除方法は[Namespaceの管理ガイドドキュメン kubectl get namespace ``` ``` -NAME STATUS AGE -default Active 1d -kube-system Active 1d -kube-public Active 1d +NAME STATUS AGE +default Active 1d +kube-node-lease Active 1d +kube-system Active 1d +kube-public Active 1d ``` -Kubernetesの起動時には3つの初期Namespaceが作成されています。 +Kubernetesの起動時には4つの初期Namespaceが作成されています。 * `default` 他にNamespaceを持っていないオブジェクトのためのデフォルトNamespace * `kube-system` Kubernetesシステムによって作成されたオブジェクトのためのNamespace * `kube-public` このNamespaceは自動的に作成され、全てのユーザーから読み取り可能です。(認証されていないユーザーも含みます。) このNamespaceは、リソースをクラスター全体を通じてパブリックに表示・読み取り可能にするため、ほとんどクラスターによって使用される用途で予約されます。 このNamespaceのパブリックな側面は単なる慣例であり、要件ではありません。 + * `kube-node-lease` クラスターのスケールに応じたノードハートビートのパフォーマンスを向上させる各ノードに関連したLeaseオブジェクトのためのNamespace。 ### Namespaceの設定 From ff8a1a5fe82768548458f99abc30c9844645ddfd Mon Sep 17 00:00:00 2001 From: Naoki Oketani Date: Thu, 17 Sep 2020 19:27:10 +0900 Subject: [PATCH 153/252] modify zenkaku colon to hankaku colon --- content/ja/docs/tasks/tools/install-minikube.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/tools/install-minikube.md b/content/ja/docs/tasks/tools/install-minikube.md index 6b2a23d7b1..730145740c 100644 --- a/content/ja/docs/tasks/tools/install-minikube.md +++ b/content/ja/docs/tasks/tools/install-minikube.md @@ -214,7 +214,7 @@ WindowsにMinikubeを手動でインストールするには、[`minikube-window {{< /note >}} {{< caution >}} -KVMを使用する場合、Debianおよび他の一部のシステムでのlibvirtのデフォルトのQEMU URIは`qemu：///session`であるのに対し、MinikubeのデフォルトのQEMU URIは`qemu：///system`であることに注意してください。これがあなたのシステムに当てはまる場合、`--kvm-qemu-uri qemu:///session`を`minikube start`に渡す必要があります。 +KVMを使用する場合、Debianおよび他の一部のシステムでのlibvirtのデフォルトのQEMU URIは`qemu:///session`であるのに対し、MinikubeのデフォルトのQEMU URIは`qemu:///system`であることに注意してください。これがあなたのシステムに当てはまる場合、`--kvm-qemu-uri qemu:///session`を`minikube start`に渡す必要があります。 {{< /caution >}} ```shell From aa8e3e5af9db762c5ffddb6212be781ad2bdb1de Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Thu, 17 Sep 2020 21:40:34 +0900 Subject: [PATCH 154/252] Update container-runtimes.md --- .../container-runtimes.md | 164 +++++++++++++----- 1 file changed, 123 insertions(+), 41 deletions(-) diff --git a/content/ja/docs/setup/production-environment/container-runtimes.md b/content/ja/docs/setup/production-environment/container-runtimes.md index 667726bc64..372523091a 100644 --- a/content/ja/docs/setup/production-environment/container-runtimes.md +++ b/content/ja/docs/setup/production-environment/container-runtimes.md @@ -18,8 +18,7 @@ Podのコンテナを実行するために、Kubernetesはコンテナランタ 悪意のあるコンテナがこの脆弱性を利用してruncのバイナリを上書きし、 コンテナホストシステム上で任意のコマンドを実行する可能性があります。 -この問題の更なる情報は以下のリンクを参照してください。 -[cve-2019-5736 : runc vulnerability](https://access.redhat.com/security/cve/cve-2019-5736) +この問題の更なる情報は[CVE-2019-5736](https://access.redhat.com/security/cve/cve-2019-5736)を参照してください。 {{< /caution >}} ### 適用性 @@ -60,34 +59,44 @@ kubeletを再起動しても問題は解決しないでしょう。 ## Docker それぞれのマシンに対してDockerをインストールします。 -バージョン19.03.4が推奨されていますが、1.13.1、17.03、17.06、17.09、18.06、18.09についても動作が確認されています。 +バージョン19.03.11が推奨されていますが、1.13.1、17.03、17.06、17.09、18.06、18.09についても動作が確認されています。 Kubernetesのリリースノートにある、Dockerの動作確認済み最新バージョンについてもご確認ください。 システムへDockerをインストールするには、次のコマンドを実行します。 {{< tabs name="tab-cri-docker-installation" >}} -{{< tab name="Ubuntu 16.04+" codelang="bash" >}} -# Docker CEのインストール +{{% tab name="Ubuntu 16.04+" %}} + +```shell +# (Install Docker CE) ## リポジトリをセットアップ ### HTTPS越しのリポジトリの使用をaptに許可するために、パッケージをインストール apt-get update && apt-get install -y \ apt-transport-https ca-certificates curl software-properties-common gnupg2 +``` -### Docker公式のGPG鍵を追加 +```shell +# Docker公式のGPG鍵を追加: curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add - +``` -### Dockerのaptリポジトリを追加 +```shell +# Dockerのaptレポジトリを追加: add-apt-repository \ "deb [arch=amd64] https://download.docker.com/linux/ubuntu \ $(lsb_release -cs) \ stable" +``` -## Docker CEのインストール +```shell +# Docker CEのインストール apt-get update && apt-get install -y \ - containerd.io=1.2.10-3 \ - docker-ce=5:19.03.4~3-0~ubuntu-$(lsb_release -cs) \ - docker-ce-cli=5:19.03.4~3-0~ubuntu-$(lsb_release -cs) +containerd.io=1.2.13-2 \ +docker-ce=5:19.03.11~3-0~ubuntu-$(lsb_release -cs) \ +docker-ce-cli=5:19.03.11~3-0~ubuntu-$(lsb_release -cs) +``` +```shell # デーモンをセットアップ cat > /etc/docker/daemon.json < /etc/docker/daemon.json <}} -{{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}} +``` +{{% /tab %}} +{{% tab name="CentOS/RHEL 7.4+" %}} -# Docker CEのインストール +```shell +# (Docker CEのインストール) ## リポジトリをセットアップ ### 必要なパッケージのインストール yum install -y yum-utils device-mapper-persistent-data lvm2 +``` +```shell ### Dockerリポジトリの追加 yum-config-manager --add-repo \ https://download.docker.com/linux/centos/docker-ce.repo +``` +```shell ## Docker CEのインストール yum update -y && yum install -y \ - containerd.io-1.2.10 \ - docker-ce-19.03.4 \ - docker-ce-cli-19.03.4 + containerd.io-1.2.13 \ + docker-ce-19.03.11 \ + docker-ce-cli-19.03.11 +``` +```shell ## /etc/docker ディレクトリを作成 mkdir /etc/docker +``` +```shell # デーモンをセットアップ cat > /etc/docker/daemon.json < /etc/docker/daemon.json <}} +``` +{{% /tab %}} {{< /tabs >}} +ブート時にDockerサービスを開始させたい場合は、以下のコマンドを入力してください: + +```shell +sudo systemctl enable docker +``` + 詳細については、[Dockerの公式インストールガイド](https://docs.docker.com/engine/installation/)を参照してください。 ## CRI-O @@ -179,54 +213,78 @@ sysctl --system ``` {{< tabs name="tab-cri-cri-o-installation" >}} -{{< tab name="Debian" codelang="bash" >}} +{{% tab name="Debian" %}} + +```shell # Debian Unstable/Sid echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_Unstable/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_Unstable/Release.key -O- | sudo apt-key add - +``` +```shell # Debian Testing echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_Testing/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_Testing/Release.key -O- | sudo apt-key add - - +``` +```shell # Debian 10 echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_10/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_10/Release.key -O- | sudo apt-key add - +``` +```shell # Raspbian 10 echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Raspbian_10/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Raspbian_10/Release.key -O- | sudo apt-key add - +``` -# CRI-Oのインストール +それでは、CRI-Oをインストールします: +```shell sudo apt-get install cri-o-1.17 -{{< /tab >}} +``` +{{% /tab %}} -{{< tab name="Ubuntu 18.04, 19.04 and 19.10" codelang="bash" >}} -# リポジトリの設定 +{{% tab name="Ubuntu 18.04, 19.04 and 19.10" %}} + +```shell +# パッケージレポジトリを設定する . /etc/os-release sudo sh -c "echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/x${NAME}_${VERSION_ID}/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list" wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/x${NAME}_${VERSION_ID}/Release.key -O- | sudo apt-key add - sudo apt-get update +``` +```shell # CRI-Oのインストール sudo apt-get install cri-o-1.17 -{{< /tab >}} +``` +{{% /tab %}} -{{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}} +{{% tab name="CentOS/RHEL 7.4+" %}} + +```shell # 必要なパッケージのインストール -yum-config-manager --add-repo=https://cbs.centos.org/repos/paas7-crio-115-release/x86_64/os/ +curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable.repo https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/CentOS_7/devel:kubic:libcontainers:stable.repo +curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable:cri-o:{{< skew latestVersion >}}.repo https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:{{< skew latestVersion >}}/CentOS_7/devel:kubic:libcontainers:stable:cri-o:{{< skew latestVersion >}}.repo +``` +```shell # CRI-Oのインストール -yum install --nogpgcheck -y cri-o -{{< /tab >}} +yum install -y cri-o +``` +{{% /tab %}} -{{< tab name="openSUSE Tumbleweed" codelang="bash" >}} +{{% tab name="openSUSE Tumbleweed" %}} + +```shell sudo zypper install cri-o -{{< /tab >}} +``` +{{% /tab %}} {{< /tabs >}} ### CRI-Oの起動 -``` +```shell systemctl daemon-reload systemctl start crio ``` @@ -264,51 +322,75 @@ sysctl --system {{< tabs name="tab-cri-containerd-installation" >}} {{< tab name="Ubuntu 16.04" codelang="bash" >}} -# containerdのインストール + +```shell +# (containerdのインストール) ## リポジトリの設定 ### HTTPS越しのリポジトリの使用をaptに許可するために、パッケージをインストール apt-get update && apt-get install -y apt-transport-https ca-certificates curl software-properties-common +``` -### Docker公式のGPG鍵を追加 +```shell +## Docker公式のGPG鍵を追加 curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add - +``` -### Dockerのaptリポジトリの追加 +``` +## Dockerのaptリポジトリの追加 add-apt-repository \ "deb [arch=amd64] https://download.docker.com/linux/ubuntu \ $(lsb_release -cs) \ stable" +``` +```shell ## containerdのインストール apt-get update && apt-get install -y containerd.io +``` +```shell # containerdの設定 mkdir -p /etc/containerd containerd config default > /etc/containerd/config.toml +``` +```shell # containerdの再起動 systemctl restart containerd -{{< /tab >}} -{{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}} -# containerdのインストール +``` +{{% /tab %}} +{{% tab name="CentOS/RHEL 7.4+" %}} + +```shell +# (containerdのインストール) ## リポジトリの設定 ### 必要なパッケージのインストール yum install -y yum-utils device-mapper-persistent-data lvm2 +``` -### Dockerのリポジトリの追加 +```shell +## Dockerのリポジトリの追加 yum-config-manager \ --add-repo \ https://download.docker.com/linux/centos/docker-ce.repo +``` +```shell ## containerdのインストール yum update -y && yum install -y containerd.io +``` -# containerdの設定 +```shell +## containerdの設定 mkdir -p /etc/containerd containerd config default > /etc/containerd/config.toml +``` +```shell # containerdの再起動 systemctl restart containerd -{{< /tab >}} +``` +{{% /tab %}} {{< /tabs >}} ### systemd From 5753e47564d08d5059b435d96b35390d0cf29260 Mon Sep 17 00:00:00 2001 From: inductor Date: Mon, 14 Sep 2020 13:54:03 +0900 Subject: [PATCH 155/252] update feature gaet --- .../feature-gates.md | 95 +++++++++++++------ 1 file changed, 67 insertions(+), 28 deletions(-) diff --git a/content/ja/docs/reference/command-line-tools-reference/feature-gates.md b/content/ja/docs/reference/command-line-tools-reference/feature-gates.md index 4c2da51da6..28fc42d0ca 100644 --- a/content/ja/docs/reference/command-line-tools-reference/feature-gates.md +++ b/content/ja/docs/reference/command-line-tools-reference/feature-gates.md @@ -35,23 +35,18 @@ content_type: concept | 機能名 | デフォルト値 | ステージ | 導入開始バージョン | 最終利用可能バージョン | |---------|---------|-------|-------|-------| +| `AnyVolumeDataSource` | `false` | Alpha | 1.18 | | | `APIListChunking` | `false` | Alpha | 1.8 | 1.8 | | `APIListChunking` | `true` | Beta | 1.9 | | | `APIPriorityAndFairness` | `false` | Alpha | 1.17 | | | `APIResponseCompression` | `false` | Alpha | 1.7 | | | `AppArmor` | `true` | Beta | 1.4 | | | `BalanceAttachedNodeVolumes` | `false` | Alpha | 1.11 | | -| `BlockVolume` | `false` | Alpha | 1.9 | 1.12 | -| `BlockVolume` | `true` | Beta | 1.13 | - | | `BoundServiceAccountTokenVolume` | `false` | Alpha | 1.13 | | | `CPUManager` | `false` | Alpha | 1.8 | 1.9 | | `CPUManager` | `true` | Beta | 1.10 | | | `CRIContainerLogRotation` | `false` | Alpha | 1.10 | 1.10 | | `CRIContainerLogRotation` | `true` | Beta| 1.11 | | -| `CSIBlockVolume` | `false` | Alpha | 1.11 | 1.13 | -| `CSIBlockVolume` | `true` | Beta | 1.14 | | -| `CSIDriverRegistry` | `false` | Alpha | 1.12 | 1.13 | -| `CSIDriverRegistry` | `true` | Beta | 1.14 | | | `CSIInlineVolume` | `false` | Alpha | 1.15 | 1.15 | | `CSIInlineVolume` | `true` | Beta | 1.16 | - | | `CSIMigration` | `false` | Alpha | 1.14 | 1.16 | @@ -68,6 +63,7 @@ content_type: concept | `CSIMigrationGCEComplete` | `false` | Alpha | 1.17 | | | `CSIMigrationOpenStack` | `false` | Alpha | 1.14 | | | `CSIMigrationOpenStackComplete` | `false` | Alpha | 1.17 | | +| `ConfigurableFSGroupPolicy` | `false` | Alpha | 1.18 | | | `CustomCPUCFSQuotaPeriod` | `false` | Alpha | 1.12 | | | `CustomResourceDefaulting` | `false` | Alpha| 1.15 | 1.15 | | `CustomResourceDefaulting` | `true` | Beta | 1.16 | | @@ -80,6 +76,8 @@ content_type: concept | `DynamicKubeletConfig` | `true` | Beta | 1.11 | | | `EndpointSlice` | `false` | Alpha | 1.16 | 1.16 | | `EndpointSlice` | `false` | Beta | 1.17 | | +| `EndpointSlice` | `true` | Beta | 1.18 | | +| `EndpointSliceProxying` | `false` | Alpha | 1.18 | | | `EphemeralContainers` | `false` | Alpha | 1.16 | | | `ExpandCSIVolumes` | `false` | Alpha | 1.14 | 1.15 | | `ExpandCSIVolumes` | `true` | Beta | 1.16 | | @@ -88,9 +86,12 @@ content_type: concept | `ExpandPersistentVolumes` | `false` | Alpha | 1.8 | 1.10 | | `ExpandPersistentVolumes` | `true` | Beta | 1.11 | | | `ExperimentalHostUserNamespaceDefaulting` | `false` | Beta | 1.5 | | -| `EvenPodsSpread` | `false` | Alpha | 1.16 | | +| `EvenPodsSpread` | `false` | Alpha | 1.16 | 1.17 | +| `EvenPodsSpread` | `true` | Beta | 1.18 | | | `HPAScaleToZero` | `false` | Alpha | 1.16 | | +| `HugePageStorageMediumSize` | `false` | Alpha | 1.18 | | | `HyperVContainer` | `false` | Alpha | 1.10 | | +| `ImmutableEphemeralVolumes` | `false` | Alpha | 1.18 | | | `KubeletPodResources` | `false` | Alpha | 1.13 | 1.14 | | `KubeletPodResources` | `true` | Beta | 1.15 | | | `LegacyNodeRoleBehavior` | `true` | Alpha | 1.16 | | @@ -100,6 +101,8 @@ content_type: concept | `MountContainers` | `false` | Alpha | 1.9 | | | `NodeDisruptionExclusion` | `false` | Alpha | 1.16 | | | `NonPreemptingPriority` | `false` | Alpha | 1.15 | | +| `PodDisruptionBudget` | `false` | Alpha | 1.3 | 1.4 | +| `PodDisruptionBudget` | `true` | Beta | 1.5 | | | `PodOverhead` | `false` | Alpha | 1.16 | - | | `ProcMountType` | `false` | Alpha | 1.12 | | | `QOSReserved` | `false` | Alpha | 1.11 | | @@ -114,8 +117,12 @@ content_type: concept | `SCTPSupport` | `false` | Alpha | 1.12 | | | `ServerSideApply` | `false` | Alpha | 1.14 | 1.15 | | `ServerSideApply` | `true` | Beta | 1.16 | | +| `ServiceAccountIssuerDiscovery` | `false` | Alpha | 1.18 | | +| `ServiceAppProtocol` | `false` | Alpha | 1.18 | | | `ServiceNodeExclusion` | `false` | Alpha | 1.8 | | -| `StartupProbe` | `true` | Beta | 1.17 | | +| `ServiceTopology` | `false` | Alpha | 1.17 | | +| `StartupProbe` | `false` | Alpha | 1.16 | 1.17 | +| `StartupProbe` | `true` | Beta | 1.18 | | | `StorageVersionHash` | `false` | Alpha | 1.14 | 1.14 | | `StorageVersionHash` | `true` | Beta | 1.15 | | | `StreamingProxyRedirects` | `false` | Beta | 1.5 | 1.5 | @@ -125,8 +132,6 @@ content_type: concept | `SupportPodPidsLimit` | `false` | Alpha | 1.10 | 1.13 | | `SupportPodPidsLimit` | `true` | Beta | 1.14 | | | `Sysctls` | `true` | Beta | 1.11 | | -| `TaintBasedEvictions` | `false` | Alpha | 1.6 | 1.12 | -| `TaintBasedEvictions` | `true` | Beta | 1.13 | | | `TokenRequest` | `false` | Alpha | 1.10 | 1.11 | | `TokenRequest` | `true` | Beta | 1.12 | | | `TokenRequestProjection` | `false` | Alpha | 1.11 | 1.11 | @@ -160,6 +165,15 @@ content_type: concept | `AffinityInAnnotations` | - | Deprecated | 1.8 | - | | `AllowExtTrafficLocalEndpoints` | `false` | Beta | 1.4 | 1.6 | | `AllowExtTrafficLocalEndpoints` | `true` | GA | 1.7 | - | +| `BlockVolume` | `false` | Alpha | 1.9 | 1.12 | +| `BlockVolume` | `true` | Beta | 1.13 | 1.17 | +| `BlockVolume` | `true` | GA | 1.18 | - | +| `CSIBlockVolume` | `false` | Alpha | 1.11 | 1.13 | +| `CSIBlockVolume` | `true` | Beta | 1.14 | 1.17 | +| `CSIBlockVolume` | `true` | GA | 1.18 | - | +| `CSIDriverRegistry` | `false` | Alpha | 1.12 | 1.13 | +| `CSIDriverRegistry` | `true` | Beta | 1.14 | 1.17 | +| `CSIDriverRegistry` | `true` | GA | 1.18 | | | `CSINodeInfo` | `false` | Alpha | 1.12 | 1.13 | | `CSINodeInfo` | `true` | Beta | 1.14 | 1.16 | | `CSINodeInfo` | `true` | GA | 1.17 | | @@ -240,9 +254,18 @@ content_type: concept | `SupportIPVSProxyMode` | `false` | Beta | 1.9 | 1.9 | | `SupportIPVSProxyMode` | `true` | Beta | 1.10 | 1.10 | | `SupportIPVSProxyMode` | `true` | GA | 1.11 | - | +| `TaintBasedEvictions` | `false` | Alpha | 1.6 | 1.12 | +| `TaintBasedEvictions` | `true` | Beta | 1.13 | 1.17 | +| `TaintBasedEvictions` | `true` | GA | 1.18 | - | | `TaintNodesByCondition` | `false` | Alpha | 1.8 | 1.11 | | `TaintNodesByCondition` | `true` | Beta | 1.12 | 1.16 | | `TaintNodesByCondition` | `true` | GA | 1.17 | - | +| `VolumePVCDataSource` | `false` | Alpha | 1.15 | 1.15 | +| `VolumePVCDataSource` | `true` | Beta | 1.16 | 1.17 | +| `VolumePVCDataSource` | `true` | GA | 1.18 | - | +| `VolumeScheduling` | `false` | Alpha | 1.9 | 1.9 | +| `VolumeScheduling` | `true` | Beta | 1.10 | 1.12 | +| `VolumeScheduling` | `true` | GA | 1.13 | - | | `VolumeScheduling` | `false` | Alpha | 1.9 | 1.9 | | `VolumeScheduling` | `true` | Beta | 1.10 | 1.12 | | `VolumeScheduling` | `true` | GA | 1.13 | - | @@ -253,6 +276,12 @@ content_type: concept | `WatchBookmark` | `false` | Alpha | 1.15 | 1.15 | | `WatchBookmark` | `true` | Beta | 1.16 | 1.16 | | `WatchBookmark` | `true` | GA | 1.17 | - | +| `WindowsGMSA` | `false` | Alpha | 1.14 | 1.15 | +| `WindowsGMSA` | `true` | Beta | 1.16 | 1.17 | +| `WindowsGMSA` | `true` | GA | 1.18 | - | +| `WindowsRunAsUserName` | `false` | Alpha | 1.16 | 1.16 | +| `WindowsRunAsUserName` | `true` | Beta | 1.17 | 1.17 | +| `WindowsRunAsUserName` | `true` | GA | 1.18 | - | {{< /table >}} ## 機能を使用する @@ -292,7 +321,8 @@ GAになってからさらなる変更を加えることは現実的ではない - `Accelerators`: DockerでのNvidia GPUのサポートを有効にします。 - `AdvancedAuditing`: [高度な監査機能](/docs/tasks/debug-application-cluster/audit/#advanced-audit)を有効にします。 -- `AffinityInAnnotations`(*非推奨*): [Podのアフィニティまたはアンチアフィニティ](/ja/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity)を有効にします。 +- `AffinityInAnnotations`(*非推奨*): [Podのアフィニティまたはアンチアフィニティ](/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)を有効にします。 +- `AnyVolumeDataSource`: {{< glossary_tooltip text="PVC" term_id="persistent-volume-claim" >}}の`DataSource`としてカスタムリソースの使用を有効にします。 - `AllowExtTrafficLocalEndpoints`: サービスが外部へのリクエストをノードのローカルエンドポイントにルーティングできるようにします。 - `APIListChunking`: APIクライアントがAPIサーバーからチャンク単位で（`LIST`や`GET`の）リソースを取得できるようにします。 `APIPriorityAndFairness`: 各サーバーで優先順位付けと公平性を備えた要求の並行性を管理できるようにします(`RequestManagement`から名前が変更されました)。 @@ -302,6 +332,7 @@ GAになってからさらなる変更を加えることは現実的ではない - `BalanceAttachedNodeVolumes`: スケジューリング中にバランスのとれたリソース割り当てを考慮するノードのボリュームカウントを含めます。判断を行う際に、CPU、メモリー使用率、およびボリュームカウントが近いノードがスケジューラーによって優先されます。 - `BlockVolume`: PodでRawブロックデバイスの定義と使用を有効にします。詳細は[Rawブロックボリュームのサポート](/docs/concepts/storage/persistent-volumes/#raw-block-volume-support)で確認できます。 - `BoundServiceAccountTokenVolume`: ServiceAccountTokenVolumeProjectionによって構成される計画ボリュームを使用するにはServiceAccountボリュームを移行します。詳細は[Service Account Token Volumes](https://git.k8s.io/community/contributors/design-proposals/storage/svcacct-token-volume-source.md)で確認できます。 +- `ConfigurableFSGroupPolicy`: Podにボリュームをマウントするときに、ユーザーがfsGroupsのボリューム権限変更ポリシーを設定できるようにします。詳細については、[Podのボリューム権限と所有権変更ポリシーの設定](/docs/tasks/configure-pod-container/security-context/#configure-volume-permission-and-ownership-change-policy-for-pods)をご覧ください。 - `CPUManager`: コンテナレベルのCPUアフィニティサポートを有効します。[CPUマネジメントポリシー](/docs/tasks/administer-cluster/cpu-management-policies/)を見てください。 - `CRIContainerLogRotation`: criコンテナランタイムのコンテナログローテーションを有効にします。 - `CSIBlockVolume`: 外部CSIボリュームドライバーを有効にしてブロックストレージをサポートします。詳細は[`csi`Rawブロックボリュームのサポート](/docs/concepts/storage/volumes/#csi-raw-block-volume-support)で確認できます。 @@ -309,7 +340,7 @@ GAになってからさらなる変更を加えることは現実的ではない - `CSIInlineVolume`: PodのCSIインラインボリュームサポートを有効にします。 - `CSIMigration`: シムと変換ロジックを有効にしてボリューム操作をKubernetesリポジトリー内のプラグインから対応した事前インストール済みのCSIプラグインにルーティングします。 - `CSIMigrationAWS`: シムと変換ロジックを有効にしてボリューム操作をKubernetesリポジトリー内のAWS-EBSプラグインからEBS CSIプラグインにルーティングします。ノードにEBS CSIプラグインがインストールおよび設定されていない場合、ツリー内のEBSプラグインへのフォールバックをサポートします。CSIMigration機能フラグを有効にする必要があります。 -- `CSIMigrationAWSComplete`: EBSツリー内プラグインのkubeletおよびボリュームコントローラーへの登録を停止し、シムと変換ロジックを有効にして、AWS-EBSツリー内プラグインからEBS CSIプラグインにボリューム操作をルーティングします。 CSIMigrationおよびCSIMigrationAWS機能フラグを有効にし、クラスター内のすべてのノードにEBS CSIプラグインをインストールおよび設定する必要があります。 +- `CSIMigrationAWSComplete`: EBSツリー内プラグインのkubeletおよびボリュームコントローラーへの登録を停止し、シムと変換ロジックを有効にして、AWS-EBSツリー内プラグインからEBS CSIプラグインにボリューム操作をルーティングしますCSIMigrationおよびCSIMigrationAWS機能フラグを有効にし、クラスター内のすべてのノードにEBS CSIプラグインをインストールおよび設定する必要があります。 - `CSIMigrationAzureDisk`: シムと変換ロジックを有効にしてボリューム操作をKubernetesリポジトリー内のAzure-DiskプラグインからAzure Disk CSIプラグインにルーティングします。ノードにAzureDisk CSIプラグインがインストールおよび設定されていない場合、ツリー内のAzureDiskプラグインへのフォールバックをサポートします。CSIMigration機能フラグを有効にする必要があります。 - `CSIMigrationAzureDiskComplete`: Azure-Diskツリー内プラグインのkubeletおよびボリュームコントローラーへの登録を停止し、シムと変換ロジックを有効にして、Azure-Diskツリー内プラグインからAzureDisk CSIプラグインにボリューム操作をルーティングします。CSIMigrationおよびCSIMigrationAzureDisk機能フラグを有効にし、クラスター内のすべてのノードにAzureDisk CSIプラグインをインストールおよび設定する必要があります。 - `CSIMigrationAzureFile`: シムと変換ロジックを有効にしてボリューム操作をKubernetesリポジトリー内のAzure-FileプラグインからAzure File CSIプラグインにルーティングします。ノードにAzureFile CSIプラグインがインストールおよび設定されていない場合、ツリー内のAzureFileプラグインへのフォールバックをサポートします。CSIMigration機能フラグを有効にする必要があります。 @@ -325,9 +356,9 @@ GAになってからさらなる変更を加えることは現実的ではない - `CustomPodDNS`: `dnsConfig`プロパティを使用したPodのDNS設定のカスタマイズを有効にします。詳細は[PodのDNS構成](/ja/docs/concepts/services-networking/dns-pod-service/#pods-dns-config)で確認できます。 - `CustomResourceDefaulting`: OpenAPI v3バリデーションスキーマにおいて、デフォルト値のCRDサポートを有効にします。 - `CustomResourcePublishOpenAPI`: CRDのOpenAPI仕様での公開を有効にします。 -- `CustomResourceSubresources`: [CustomResourceDefinition](/docs/concepts/api-extension/custom-resources/)から作成されたリソースの`/status`および`/scale`サブリソースを有効にします。 -- `CustomResourceValidation`: [CustomResourceDefinition](/docs/concepts/api-extension/custom-resources/)から作成されたリソースのスキーマによる検証を有効にします。 -- `CustomResourceWebhookConversion`: [CustomResourceDefinition](/docs/concepts/api-extension/custom-resources/)から作成されたリソースのWebhookベースの変換を有効にします。 +- `CustomResourceSubresources`: [CustomResourceDefinition](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)から作成されたリソースの`/status`および`/scale`サブリソースを有効にします。 +- `CustomResourceValidation`: [CustomResourceDefinition](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)から作成されたリソースのスキーマによる検証を有効にします。 +- `CustomResourceWebhookConversion`: [CustomResourceDefinition](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)から作成されたリソースのWebhookベースの変換を有効にします。 - `DevicePlugins`: [device-plugins](/docs/concepts/cluster-administration/device-plugins/)によるノードでのリソースプロビジョニングを有効にします。 - `DryRun`: サーバーサイドでの[dry run](/docs/reference/using-api/api-concepts/#dry-run)リクエストを有効にします。 - `DynamicAuditing`: [動的監査](/docs/tasks/debug-application-cluster/audit/#dynamic-backend)を有効にします。 @@ -340,29 +371,33 @@ GAになってからさらなる変更を加えることは現実的ではない - `EvenPodsSpread`: Podをトポロジードメイン全体で均等にスケジュールできるようにします。[Even Pods Spread](/docs/concepts/configuration/even-pods-spread)をご覧ください。 - `ExpandInUsePersistentVolumes`: 使用中のPVCのボリューム拡張を有効にします。[使用中のPersistentVolumeClaimのサイズ変更](/docs/concepts/storage/persistent-volumes/#resizing-an-in-use-persistentvolumeclaim)を参照してください。 - `ExpandPersistentVolumes`: 永続ボリュームの拡張を有効にします。[永続ボリューム要求の拡張](/docs/concepts/storage/persistent-volumes/#expanding-persistent-volumes-claims)を参照してください。 -- `ExperimentalCriticalPodAnnotation`: [スケジューリングが保証されるよう](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/)に特定のpodへの *クリティカル* の注釈を加える設定を有効にします。 +- `ExperimentalCriticalPodAnnotation`: [スケジューリングが保証されるよう](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/)に特定のPodへの *クリティカル* の注釈を加える設定を有効にします。 - `ExperimentalHostUserNamespaceDefaultingGate`: ホストするデフォルトのユーザー名前空間を有効にします。これは他のホストの名前空間やホストのマウントを使用しているコンテナ、特権を持つコンテナ、または名前空間のない特定の機能（たとえば`MKNODE`、`SYS_MODULE`など）を使用しているコンテナ用です。これはDockerデーモンでユーザー名前空間の再マッピングが有効になっている場合にのみ有効にすべきです。 -- `EndpointSlice`: よりスケーラブルで拡張可能なネットワークエンドポイントのエンドポイントスライスを有効にします。対応するAPIとコントローラーを有効にする必要があります。[Enabling Endpoint Slices](/docs/tasks/administer-cluster/enabling-endpointslices/)をご覧ください。 +- `EndpointSlice`: よりスケーラブルで拡張可能なネットワークエンドポイントのエンドポイントスライスを有効にします。[Enabling Endpoint Slices](/docs/tasks/administer-cluster/enabling-endpointslices/)をご覧ください。 +- `EndpointSliceProxying`: このフィーチャーゲートを有効にすると、kube-proxyはエンドポイントの代わりにエンドポイントスライスをプライマリデータソースとして使用し、スケーラビリティとパフォーマンスの向上を実現します。[Enabling Endpoint Slices](/docs/tasks/administer-cluster/enabling-endpointslices/).をご覧ください。 - `GCERegionalPersistentDisk`: GCEでリージョナルPD機能を有効にします。 - `HugePages`: 事前に割り当てられた[huge pages](/docs/tasks/manage-hugepages/scheduling-hugepages/)の割り当てと消費を有効にします。 +- `HugePageStorageMediumSize`: 事前に割り当てられた複数のサイズの[huge pages](/docs/tasks/manage-hugepages/scheduling-hugepages/)のサポートを有効にします。 - `HyperVContainer`: Windowsコンテナの[Hyper-Vによる分離](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/hyperv-container)を有効にします。 - `HPAScaleToZero`: カスタムメトリクスまたは外部メトリクスを使用するときに、`HorizontalPodAutoscaler`リソースの`minReplicas`を0に設定できるようにします。 +- `ImmutableEphemeralVolumes`: 安全性とパフォーマンスを向上させるために、個々のSecretとConfigMapが不変となるように指定できるようにします。 - `KubeletConfigFile`: 設定ファイルを使用して指定されたファイルからのkubelet設定の読み込みを有効にします。詳細は[設定ファイルによるkubeletパラメーターの設定](/docs/tasks/administer-cluster/kubelet-config-file/)で確認できます。 - `KubeletPluginsWatcher`: 調査ベースのプラグイン監視ユーティリティを有効にしてkubeletが[CSIボリュームドライバー](/docs/concepts/storage/volumes/#csi)などのプラグインを検出できるようにします。 -- `KubeletPodResources`: kubeletのpodのリソースgrpcエンドポイントを有効にします。詳細は[デバイスモニタリングのサポート](https://git.k8s.io/community/keps/sig-node/compute-device-assignment.md)で確認できます。 +- `KubeletPodResources`: kubeletのPodのリソースgrpcエンドポイントを有効にします。詳細は[デバイスモニタリングのサポート](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/compute-device-assignment.md)で確認できます。 - `LegacyNodeRoleBehavior`: 無効にすると、サービスロードバランサーの従来の動作とノードの中断により機能固有のラベルが優先され、`node-role.kubernetes.io/master`ラベルが無視されます。 -- `LocalStorageCapacityIsolation`: [ローカルの一時ストレージ](/docs/concepts/configuration/manage-compute-resources-container/)の消費を有効にして、[emptyDirボリューム](/docs/concepts/storage/volumes/#emptydir)の`sizeLimit`プロパティも有効にします。 -- `LocalStorageCapacityIsolationFSQuotaMonitoring`: `LocalStorageCapacityIsolation`が[ローカルの一時ストレージ](/docs/concepts/configuration/manage-compute-resources-container/)で有効になっていて、[emptyDirボリューム](/docs/concepts/storage/volumes/#emptydir)のbacking filesystemがプロジェクトクォータをサポートし有効になっている場合、プロジェクトクォータを使用して、パフォーマンスと精度を向上させるために、ファイルシステムへのアクセスではなく[emptyDirボリューム](/docs/concepts/storage/volumes/#emptydir)ストレージ消費を監視します。 +- `LocalStorageCapacityIsolation`: [ローカルの一時ストレージ](/docs/concepts/configuration/manage-resources-containers/)の消費を有効にして、[emptyDirボリューム](/docs/concepts/storage/volumes/#emptydir)の`sizeLimit`プロパティも有効にします。 +- `LocalStorageCapacityIsolationFSQuotaMonitoring`: `LocalStorageCapacityIsolation`が[ローカルの一時ストレージ](/docs/concepts/configuration/manage-resources-containers/)で有効になっていて、[emptyDirボリューム](/docs/concepts/storage/volumes/#emptydir)のbacking filesystemがプロジェクトクォータをサポートし有効になっている場合、プロジェクトクォータを使用して、パフォーマンスと精度を向上させるために、ファイルシステムへのアクセスではなく[emptyDirボリューム](/docs/concepts/storage/volumes/#emptydir)ストレージ消費を監視します。 - `MountContainers`: ホスト上のユーティリティコンテナをボリュームマウンターとして使用できるようにします。 -- `MountPropagation`: あるコンテナによってマウントされたボリュームを他のコンテナまたはpodに共有できるようにします。詳細は[マウントの伝播](/docs/concepts/storage/volumes/#mount-propagation)で確認できます。 +- `MountPropagation`: あるコンテナによってマウントされたボリュームを他のコンテナまたはPodに共有できるようにします。詳細は[マウントの伝播](/docs/concepts/storage/volumes/#mount-propagation)で確認できます。 - `NodeDisruptionExclusion`: ノードラベル`node.kubernetes.io/exclude-disruption`の使用を有効にします。これにより、ゾーン障害時にノードが退避するのを防ぎます。 - `NodeLease`: 新しいLease APIを有効にしてノードヘルスシグナルとして使用できるノードのハートビートをレポートします。 - `NonPreemptingPriority`: PriorityClassとPodのNonPreemptingオプションを有効にします。 -- `PersistentLocalVolumes`: Podで`local`ボリュームタイプの使用を有効にします。`local`ボリュームを要求する場合、podアフィニティを指定する必要があります。 +- `PersistentLocalVolumes`: Podで`local`ボリュームタイプの使用を有効にします。`local`ボリュームを要求する場合、Podアフィニティを指定する必要があります。 - `PodOverhead`: [PodOverhead](/docs/concepts/configuration/pod-overhead/)機能を有効にして、Podのオーバーヘッドを考慮するようにします。 +- `PodDisruptionBudget`: [PodDisruptionBudget](/docs/tasks/run-application/configure-pdb/)機能を有効にします。 - `PodPriority`: [優先度](/docs/concepts/configuration/pod-priority-preemption/)に基づいてPodの再スケジューリングとプリエンプションを有効にします。 - `PodReadinessGates`: Podのreadinessの評価を拡張するために`PodReadinessGate`フィールドの設定を有効にします。詳細は[Pod readiness gate](/ja/docs/concepts/workloads/pods/pod-lifecycle/#pod-readiness-gate)で確認できます。 -- `PodShareProcessNamespace`: Podで実行されているコンテナ間で単一のプロセス名前空間を共有するには、Podで`shareProcessNamespace`の設定を有効にします。 詳細については、[Pod内のコンテナ間でプロセス名前空間を共有する](/docs/tasks/configure-pod-container/share-process-namespace/)をご覧ください。 +- `PodShareProcessNamespace`: Podで実行されているコンテナ間で単一のプロセス名前空間を共有するには、Podで`shareProcessNamespace`の設定を有効にします詳細については、[Pod内のコンテナ間でプロセス名前空間を共有する](/docs/tasks/configure-pod-container/share-process-namespace/)をご覧ください。 - `ProcMountType`: コンテナのProcMountTypeの制御を有効にします。 - `PVCProtection`: 永続ボリューム要求（PVC）がPodでまだ使用されているときに削除されないようにします。詳細は[ここ](/docs/tasks/administer-cluster/storage-object-in-use-protection/)で確認できます。 - `QOSReserved`: QoSレベルでのリソース予約を許可して、低いQoSレベルのポッドが高いQoSレベルで要求されたリソースにバーストするのを防ぎます（現時点ではメモリのみ）。 @@ -375,26 +410,30 @@ GAになってからさらなる変更を加えることは現実的ではない - `ScheduleDaemonSetPods`: DaemonSetのPodをDaemonSetコントローラーではなく、デフォルトのスケジューラーによってスケジュールされるようにします。 - `SCTPSupport`: `Service`、`Endpoints`、`NetworkPolicy`、`Pod`の定義で`protocol`の値としてSCTPを使用できるようにします - `ServerSideApply`: APIサーバーで[サーバーサイドApply(SSA)](/docs/reference/using-api/api-concepts/#server-side-apply)のパスを有効にします。 +- `ServiceAccountIssuerDiscovery`: APIサーバーにてサービスアカウント発行者のOIDC検出エンドポイント（発行者とJWKS URL）を有効にします。詳細については、[Podのサービスアカウント設定](/docs/tasks/configure-pod-container/configure-service-account/#service-account-issuer-discovery)をご覧ください。 +- `ServiceAppProtocol`: サービスとエンドポイントで`AppProtocol`フィールドを有効にします。 - `ServiceLoadBalancerFinalizer`: サービスロードバランサーのファイナライザー保護を有効にします。 - `ServiceNodeExclusion`: クラウドプロバイダーによって作成されたロードバランサーからのノードの除外を有効にします。"`alpha.service-controller.kubernetes.io/exclude-balancer`"キーまたは`node.kubernetes.io/exclude-from-external-load-balancers`でラベル付けされている場合ノードは除外の対象となります。 +- `ServiceTopology`: クラスタのノードトポロジーに基づいてトラフィックをルーティングするサービスを有効にします。詳細については、[Serviceトポロジー](/ja/docs/concepts/services-networking/service-topology/)を参照してください。 - `StartupProbe`: kubeletで[startup](/ja/docs/concepts/workloads/pods/pod-lifecycle/#when-should-you-use-a-startup-probe)プローブを有効にします。 - `StorageObjectInUseProtection`: PersistentVolumeまたはPersistentVolumeClaimオブジェクトがまだ使用されている場合、それらの削除を延期します。 - `StorageVersionHash`: apiserversがディスカバリーでストレージのバージョンハッシュを公開できるようにします。 - `StreamingProxyRedirects`: ストリーミングリクエストのバックエンド(kubelet)からのリダイレクトをインターセプト（およびフォロー）するようAPIサーバーに指示します。ストリーミングリクエストの例には`exec`、`attach`、`port-forward`リクエストが含まれます。 - `SupportIPVSProxyMode`: IPVSを使用したクラスター内サービスの負荷分散の提供を有効にします。詳細は[サービスプロキシー](/ja/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies)で確認できます。 - `SupportPodPidsLimit`: PodのPID制限のサポートを有効にします。 -- `Sysctls`: 各podに設定できる名前空間付きのカーネルパラメーター(sysctl)のサポートを有効にします。詳細は[sysctls](/docs/tasks/administer-cluster/sysctl-cluster/)で確認できます。 -- `TaintBasedEvictions`: ノードの汚染とpodの許容に基づいてノードからpodを排除できるようにします。。詳細は[汚染と許容](/docs/concepts/configuration/taint-and-toleration/)で確認できます。 -- `TaintNodesByCondition`: [ノードの条件](/ja/docs/concepts/architecture/nodes/#condition)に基づいてノードの自動汚染を有効にします。 +- `Sysctls`: 各Podに設定できる名前空間付きのカーネルパラメーター(sysctl)のサポートを有効にします。詳細は[sysctls](/docs/tasks/administer-cluster/sysctl-cluster/)で確認できます。 +- `TaintBasedEvictions`: ノードのTaintとPodのTolerationに基づいてノードからPodを排除できるようにします。。詳細は[TaintとToleration](/docs/concepts/scheduling-eviction/taint-and-toleration/)で確認できます。 +- `TaintNodesByCondition`: [ノードの条件](/ja/docs/concepts/architecture/nodes/#condition)に基づいてノードの自動Taintを有効にします。 - `TokenRequest`: サービスアカウントリソースで`TokenRequest`エンドポイントを有効にします。 -- `TokenRequestProjection`: [Projectedボリューム](/docs/concepts/storage/volumes/#projected)を使用したpodへのサービスアカウントのトークンの注入を有効にします。 +- `TokenRequestProjection`: [Projectedボリューム](/docs/concepts/storage/volumes/#projected)を使用したPodへのサービスアカウントのトークンの注入を有効にします。 - `TTLAfterFinished`: [TTLコントローラー](/docs/concepts/workloads/controllers/ttlafterfinished/)が実行終了後にリソースをクリーンアップできるようにします。 - `VolumePVCDataSource`: 既存のPVCをデータソースとして指定するサポートを有効にします。 - `VolumeScheduling`: ボリュームトポロジー対応のスケジューリングを有効にし、PersistentVolumeClaim（PVC）バインディングにスケジューリングの決定を認識させます。また`PersistentLocalVolumes`フィーチャーゲートと一緒に使用すると[`local`](/docs/concepts/storage/volumes/#local)ボリュームタイプの使用が可能になります。 - `VolumeSnapshotDataSource`: ボリュームスナップショットのデータソースサポートを有効にします。 - `VolumeSubpathEnvExpansion`: 環境変数を`subPath`に展開するための`subPathExpr`フィールドを有効にします。 - `WatchBookmark`: ブックマークイベントの監視サポートを有効にします。 -- `WindowsGMSA`: GMSA資格仕様をpodからコンテナランタイムに渡せるようにします。 +- `WindowsGMSA`: GMSA資格仕様をPodからコンテナランタイムに渡せるようにします。 +- `WindowsRunAsUserName`: デフォルト以外のユーザーでWindowsコンテナアプリケーションを実行するためのサポートを有効にします。詳細については、[RunAsUserNameの設定](/docs/tasks/configure-pod-container/configure-runasusername)を参照してください。 - `WinDSR`: kube-proxyがWindows用のDSRロードバランサーを作成できるようにします。 - `WinOverlay`: kube-proxyをWindowsのオーバーレイモードで実行できるようにします。 From 2f2ebae42766c33135a5ebcafe24f20b1f525946 Mon Sep 17 00:00:00 2001 From: "inductor(Kohei)" Date: Tue, 15 Sep 2020 01:55:35 +0900 Subject: [PATCH 156/252] Update content/ja/docs/reference/command-line-tools-reference/feature-gates.md --- .../reference/command-line-tools-reference/feature-gates.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/ja/docs/reference/command-line-tools-reference/feature-gates.md b/content/ja/docs/reference/command-line-tools-reference/feature-gates.md index 28fc42d0ca..e01de4d5f9 100644 --- a/content/ja/docs/reference/command-line-tools-reference/feature-gates.md +++ b/content/ja/docs/reference/command-line-tools-reference/feature-gates.md @@ -397,7 +397,7 @@ GAになってからさらなる変更を加えることは現実的ではない - `PodDisruptionBudget`: [PodDisruptionBudget](/docs/tasks/run-application/configure-pdb/)機能を有効にします。 - `PodPriority`: [優先度](/docs/concepts/configuration/pod-priority-preemption/)に基づいてPodの再スケジューリングとプリエンプションを有効にします。 - `PodReadinessGates`: Podのreadinessの評価を拡張するために`PodReadinessGate`フィールドの設定を有効にします。詳細は[Pod readiness gate](/ja/docs/concepts/workloads/pods/pod-lifecycle/#pod-readiness-gate)で確認できます。 -- `PodShareProcessNamespace`: Podで実行されているコンテナ間で単一のプロセス名前空間を共有するには、Podで`shareProcessNamespace`の設定を有効にします詳細については、[Pod内のコンテナ間でプロセス名前空間を共有する](/docs/tasks/configure-pod-container/share-process-namespace/)をご覧ください。 +- `PodShareProcessNamespace`: Podで実行されているコンテナ間で単一のプロセス名前空間を共有するには、Podで`shareProcessNamespace`の設定を有効にします。詳細については、[Pod内のコンテナ間でプロセス名前空間を共有する](/docs/tasks/configure-pod-container/share-process-namespace/)をご覧ください。 - `ProcMountType`: コンテナのProcMountTypeの制御を有効にします。 - `PVCProtection`: 永続ボリューム要求（PVC）がPodでまだ使用されているときに削除されないようにします。詳細は[ここ](/docs/tasks/administer-cluster/storage-object-in-use-protection/)で確認できます。 - `QOSReserved`: QoSレベルでのリソース予約を許可して、低いQoSレベルのポッドが高いQoSレベルで要求されたリソースにバーストするのを防ぎます（現時点ではメモリのみ）。 @@ -441,4 +441,3 @@ GAになってからさらなる変更を加えることは現実的ではない ## {{% heading "whatsnext" %}} * Kubernetesの[非推奨ポリシー](/docs/reference/using-api/deprecation-policy/)では、機能とコンポーネントを削除するためのプロジェクトのアプローチを説明しています。 - From c2658dfc74f3282d778d0442fa515858e566e4a4 Mon Sep 17 00:00:00 2001 From: "inductor(Kohei)" Date: Tue, 15 Sep 2020 01:56:39 +0900 Subject: [PATCH 157/252] Update content/ja/docs/reference/command-line-tools-reference/feature-gates.md --- .../reference/command-line-tools-reference/feature-gates.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/reference/command-line-tools-reference/feature-gates.md b/content/ja/docs/reference/command-line-tools-reference/feature-gates.md index e01de4d5f9..819f269611 100644 --- a/content/ja/docs/reference/command-line-tools-reference/feature-gates.md +++ b/content/ja/docs/reference/command-line-tools-reference/feature-gates.md @@ -340,7 +340,7 @@ GAになってからさらなる変更を加えることは現実的ではない - `CSIInlineVolume`: PodのCSIインラインボリュームサポートを有効にします。 - `CSIMigration`: シムと変換ロジックを有効にしてボリューム操作をKubernetesリポジトリー内のプラグインから対応した事前インストール済みのCSIプラグインにルーティングします。 - `CSIMigrationAWS`: シムと変換ロジックを有効にしてボリューム操作をKubernetesリポジトリー内のAWS-EBSプラグインからEBS CSIプラグインにルーティングします。ノードにEBS CSIプラグインがインストールおよび設定されていない場合、ツリー内のEBSプラグインへのフォールバックをサポートします。CSIMigration機能フラグを有効にする必要があります。 -- `CSIMigrationAWSComplete`: EBSツリー内プラグインのkubeletおよびボリュームコントローラーへの登録を停止し、シムと変換ロジックを有効にして、AWS-EBSツリー内プラグインからEBS CSIプラグインにボリューム操作をルーティングしますCSIMigrationおよびCSIMigrationAWS機能フラグを有効にし、クラスター内のすべてのノードにEBS CSIプラグインをインストールおよび設定する必要があります。 +- `CSIMigrationAWSComplete`: EBSツリー内プラグインのkubeletおよびボリュームコントローラーへの登録を停止し、シムと変換ロジックを有効にして、AWS-EBSツリー内プラグインからEBS CSIプラグインにボリューム操作をルーティングします。CSIMigrationおよびCSIMigrationAWS機能フラグを有効にし、クラスター内のすべてのノードにEBS CSIプラグインをインストールおよび設定する必要があります。 - `CSIMigrationAzureDisk`: シムと変換ロジックを有効にしてボリューム操作をKubernetesリポジトリー内のAzure-DiskプラグインからAzure Disk CSIプラグインにルーティングします。ノードにAzureDisk CSIプラグインがインストールおよび設定されていない場合、ツリー内のAzureDiskプラグインへのフォールバックをサポートします。CSIMigration機能フラグを有効にする必要があります。 - `CSIMigrationAzureDiskComplete`: Azure-Diskツリー内プラグインのkubeletおよびボリュームコントローラーへの登録を停止し、シムと変換ロジックを有効にして、Azure-Diskツリー内プラグインからAzureDisk CSIプラグインにボリューム操作をルーティングします。CSIMigrationおよびCSIMigrationAzureDisk機能フラグを有効にし、クラスター内のすべてのノードにAzureDisk CSIプラグインをインストールおよび設定する必要があります。 - `CSIMigrationAzureFile`: シムと変換ロジックを有効にしてボリューム操作をKubernetesリポジトリー内のAzure-FileプラグインからAzure File CSIプラグインにルーティングします。ノードにAzureFile CSIプラグインがインストールおよび設定されていない場合、ツリー内のAzureFileプラグインへのフォールバックをサポートします。CSIMigration機能フラグを有効にする必要があります。 From 06213569774e83d9a82d866f232d963ff417fbab Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Thu, 17 Sep 2020 12:49:38 +0900 Subject: [PATCH 158/252] Update ja/docs/concepts/workloads/controllers/cron-jobs.md --- .../workloads/controllers/cron-jobs.md | 22 ++++++++++++++++--- 1 file changed, 19 insertions(+), 3 deletions(-) diff --git a/content/ja/docs/concepts/workloads/controllers/cron-jobs.md b/content/ja/docs/concepts/workloads/controllers/cron-jobs.md index 60e8e68370..5351fe8133 100644 --- a/content/ja/docs/concepts/workloads/controllers/cron-jobs.md +++ b/content/ja/docs/concepts/workloads/controllers/cron-jobs.md @@ -8,7 +8,7 @@ weight: 80 {{< feature-state for_k8s_version="v1.8" state="beta" >}} -_CronJob_ は時刻ベースのスケジュールによって[Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/)を作成します。 +_CronJob_ は繰り返しのスケジュールによって{{< glossary_tooltip term_id="job" text="Job" >}}を作成します。 _CronJob_ オブジェクトとは _crontab_ (cron table)ファイルでみられる一行のようなものです。 [Cron](https://ja.wikipedia.org/wiki/Cron)形式で記述された指定のスケジュールの基づき、定期的にジョブが実行されます。 @@ -22,13 +22,25 @@ _CronJob_ オブジェクトとは _crontab_ (cron table)ファイルでみら CronJobリソースのためのマニフェストを作成する場合、その名前が有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)か確認してください。 名前は52文字を超えることはできません。これはCronJobコントローラーが自動的に、与えられたジョブ名に11文字を追加し、ジョブ名の長さは最大で63文字以内という制約があるためです。 -cronジョブを作成し、実行するインストラクション、または、cronジョブ仕様ファイルのサンプルについては、[Running automated tasks with cron jobs](/docs/tasks/job/automated-tasks-with-cron-jobs)をご覧ください。 -## CronJobの制限 +## CronJob + +CronJobは、バックアップの実行やメール送信のような定期的であったり頻発するタスクの作成に役立ちます。 +CronJobは、クラスターがアイドル状態になりそうなときにJobをスケジューリングするような特定時における個々のタスクをスケジュールすることもできます。 + +### 例 + +このCronJobマニフェスト例は、毎分ごとに現在の時刻とhelloメッセージを表示します。 + +{{< codenew file="application/job/cronjob.yaml" >}} + +([Running Automated Tasks with a CronJob](/docs/tasks/job/automated-tasks-with-cron-jobs/)ではこの例をより詳しく説明しています。). + +## CronJobの制限 {#cron-job-limitations} cronジョブは一度のスケジュール実行につき、 _おおよそ_ 1つのジョブオブジェクトを作成します。ここで _おおよそ_ と言っているのは、ある状況下では2つのジョブが作成される、もしくは1つも作成されない場合があるためです。通常、このようなことが起こらないようになっていますが、完全に防ぐことはできません。したがって、ジョブは _冪等_ であるべきです。 @@ -50,4 +62,8 @@ Cannot determine if job needs to be started. Too many missed start time (> 100). CronJobはスケジュールに一致するJobの作成にのみ関与するのに対して、JobはJobが示すPod管理を担います。 +## {{% heading "whatsnext" %}} +[Cron表現形式](https://en.wikipedia.org/wiki/Cron)では、CronJobの`schedule`フィールドのフォーマットを説明しています。 + +cronジョブの作成や動作の説明、CronJobマニフェストの例については、[Running automated tasks with cron jobs](/docs/tasks/job/automated-tasks-with-cron-jobs)を見てください。 From 3c8bd09da5064a5c4dc3b1ebd699a1765972342b Mon Sep 17 00:00:00 2001 From: yu-kasuya Date: Fri, 18 Sep 2020 11:47:29 +0900 Subject: [PATCH 159/252] Apply suggestions from code review Co-authored-by: bells17 --- content/ja/docs/concepts/workloads/controllers/cron-jobs.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/workloads/controllers/cron-jobs.md b/content/ja/docs/concepts/workloads/controllers/cron-jobs.md index 5351fe8133..20c465c3a7 100644 --- a/content/ja/docs/concepts/workloads/controllers/cron-jobs.md +++ b/content/ja/docs/concepts/workloads/controllers/cron-jobs.md @@ -30,7 +30,7 @@ CronJobリソースのためのマニフェストを作成する場合、その ## CronJob CronJobは、バックアップの実行やメール送信のような定期的であったり頻発するタスクの作成に役立ちます。 -CronJobは、クラスターがアイドル状態になりそうなときにJobをスケジューリングするような特定時における個々のタスクをスケジュールすることもできます。 +CronJobは、クラスターがアイドル状態になりそうなときにJobをスケジューリングするようなど、特定の時間に個々のタスクをスケジュールすることもできます。 ### 例 From 5b6c6a8e65c26e0e3944204a14f2aaebc4b70783 Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Fri, 18 Sep 2020 11:56:28 +0900 Subject: [PATCH 160/252] fix some word --- content/ja/docs/concepts/workloads/controllers/cron-jobs.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/workloads/controllers/cron-jobs.md b/content/ja/docs/concepts/workloads/controllers/cron-jobs.md index 20c465c3a7..5f820a187a 100644 --- a/content/ja/docs/concepts/workloads/controllers/cron-jobs.md +++ b/content/ja/docs/concepts/workloads/controllers/cron-jobs.md @@ -30,7 +30,7 @@ CronJobリソースのためのマニフェストを作成する場合、その ## CronJob CronJobは、バックアップの実行やメール送信のような定期的であったり頻発するタスクの作成に役立ちます。 -CronJobは、クラスターがアイドル状態になりそうなときにJobをスケジューリングするようなど、特定の時間に個々のタスクをスケジュールすることもできます。 +CronJobは、クラスターがアイドル状態になりそうなときにJobをスケジューリングするなど、特定の時間に個々のタスクをスケジュールすることもできます。 ### 例 From 8fbf98518ca83eb4eeff5c4a920e79f3ce69e844 Mon Sep 17 00:00:00 2001 From: yoichiro0217 Date: Thu, 10 Sep 2020 18:05:03 +0900 Subject: [PATCH 161/252] =?UTF-8?q?issue-23614=E3=81=AE=E6=97=A5=E6=9C=AC?= =?UTF-8?q?=E8=AA=9E=E7=BF=BB=E8=A8=B3?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../docs/concepts/overview/kubernetes-api.md | 119 +++++++++++------- 1 file changed, 72 insertions(+), 47 deletions(-) diff --git a/content/ja/docs/concepts/overview/kubernetes-api.md b/content/ja/docs/concepts/overview/kubernetes-api.md index 5d95929bef..764fae9d0b 100644 --- a/content/ja/docs/concepts/overview/kubernetes-api.md +++ b/content/ja/docs/concepts/overview/kubernetes-api.md @@ -3,6 +3,9 @@ reviewers: title: Kubernetes API content_type: concept weight: 30 +description: > + Kubernetes APIを使用すると、Kubernetes内のオブジェクトの状態をクエリで操作できます。 + Kubernetesのコントロールプレーンの中核は、APIサーバーとそれが公開するHTTP APIです。ユーザー、クラスターのさまざまな部分、および外部コンポーネントはすべて、APIサーバーを介して互いに通信します。 card: name: concepts weight: 30 @@ -10,64 +13,78 @@ card: -全般的なAPIの規則は、[API規則ドキュメント](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md)に記載されています。 - -APIエンドポイント、リソースタイプ、そしてサンプルは[APIリファレンス](/docs/reference)に記載されています。 - -APIへの外部からのアクセスは、[APIアクセス制御ドキュメント](/docs/reference/access-authn-authz/controlling-access/)に記載されています。 - -Kubernetes APIは、システムの宣言的設定スキーマの基礎としても機能します。[kubectl](/docs/reference/kubectl/overview/)コマンドラインツールから、APIオブジェクトを作成、更新、削除、取得することができます。 - -また、Kubernetesは、シリアライズされた状態を(現在は[etcd](https://coreos.com/docs/distributed-configuration/getting-started-with-etcd/)に)APIリソースの単位で保存しています。 - -Kubernetesそれ自身は複数のコンポーネントから構成されており、APIを介して連携しています。 +Kubernetesの中核である' {{< glossary_tooltip text="control plane" term_id="control-plane" >}}は{{< glossary_tooltip text="API server" term_id="kube-apiserver" >}} です。 +APIサーバーは、エンドユーザー、クラスターのさまざまな部分、および外部コンポーネントが相互に通信できるようにするHTTP APIを公開します。 +Kubernetes APIを使用すると、Kubernetes API内のオブジェクトの状態をクエリで操作できます（例：Pod、Namespace、ConfigMap、Events）。 +APIエンドポイント、リソースタイプ、サンプルについては[APIリファレンス](/docs/reference/kubernetes-api/)で説明しています。 ## APIの変更 -我々の経験上、成功を収めているどのようなシステムも、新しいユースケースへの対応、既存の変更に合わせ、成長し変わっていく必要があります。したがって、Kubernetesにも継続的に変化、成長することを期待しています。一方で、長期間にわたり、既存のクライアントとの互換性を損なわないようにする予定です。一般的に、新しいAPIリソースとリソースフィールドは頻繁に追加されることが予想されます。リソース、フィールドの削除は、[API廃止ポリシー](/docs/reference/using-api/deprecation-policy/)への準拠を必要とします。 +成功を収めているシステムはすべて、新しいユースケースの出現や既存の変化に応じて成長し、変化する必要があります。 +したがって、Kubernetesには、Kubernetes APIを継続的に変更および拡張できる設計機能があります。 +Kubernetesプロジェクトは、既存のクライアントとの互換性を破壊しないこと、およびその互換性を一定期間維持して、他のプロジェクトが適応する機会を提供することを目的としています。 -何が互換性のある変更を意味するか、またAPIをどのように変更するかは、[API変更ドキュメント](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md)に詳解されています。 +基本的に、新しいAPIリソースと新しいリソースフィールドは追加することができます。 +リソースまたはフィールドを削除するには、次のポリシーに従ってください。[API非推奨ポリシー](/docs/reference/using-api/deprecation-policy/). -## OpenAPIとSwaggerの定義 +互換性のある変更の構成要素とAPIの変更方法については、[API変更](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme)で詳しく説明しています。 -完全なAPIの詳細は、[OpenAPI](https://www.openapis.org/)に記載されています。 -Kubernetes 1.10から、KubernetesAPIサーバーは`/openapi/v2`のエンドポイントを通じて、OpenAPI仕様を提供しています。 -リクエストフォーマットは、HTTPヘッダーを下記のように設定することで指定されます: +**OpenAPI 仕様 {#api-specification} -ヘッダ | 設定可能な値 ------- | --------------- -Accept | `application/json`, `application/com.github.proto-openapi.spec.v2@v1.0+protobuf` (デフォルトのcontent-typeは、`*/*`に対して`application/json`か、もしくはこのヘッダーを送信しません) -Accept-Encoding | `gzip` (このヘッダーを送信しないことも許容されています) +Kubernetes APIサーバーは、`/openapi/v2`エンドポイントを介してOpenAPI仕様を提供します。 +次のように要求ヘッダーを使用して、応答フォーマットを要求できます。 -1.14より前のバージョンでは、フォーマット分離エンドポイント(`/swagger.json`, `/swagger-2.0.0.json`, `/swagger-2.0.0.pb-v1`, `/swagger-2.0.0.pb-v1.gz`)が、OpenAPI仕様を違うフォーマットで提供しています。これらのエンドポイントは非推奨となっており、Kubernetes1.14で削除されました。 -**OpenAPI仕様の取得サンプル**: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
HeaderPossible valuesNotes
Accept-Encodinggzipこのヘッダーを使わないことも可能
Acceptapplication/com.github.proto-openapi.spec.v2@v1.0+protobuf主にクラスター内での使用
application/jsonデフォルト
*application/jsonを提供
OpenAPI v2クエリの有効なリクエストヘッダー値
-1.10より前 | Kubernetes1.10以降 ------------ | ----------------------------- -GET /swagger.json | GET /openapi/v2 **Accept**: application/json -GET /swagger-2.0.0.pb-v1 | GET /openapi/v2 **Accept**: application/com.github.proto-openapi.spec.v2@v1.0+protobuf -GET /swagger-2.0.0.pb-v1.gz | GET /openapi/v2 **Accept**: application/com.github.proto-openapi.spec.v2@v1.0+protobuf **Accept-Encoding**: gzip Kubernetesは、他の手段として主にクラスター間の連携用途向けのAPIに、Protocol buffersをベースにしたシリアライズフォーマットを実装しており、そのフォーマットの概要は[デザイン提案](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md)に記載されています。また各スキーマのIDFファイルは、APIオブジェクトを定義しているGoパッケージ内に配置されています。 -また、1.14より前のバージョンのKubernetesAPIサーバーでは、[Swagger v1.2](http://swagger.io/)をベースにしたKubernetes仕様を、`/swaggerapi`で公開しています。 -このエンドポイントは非推奨となっており、Kubernetes1.14で削除されました。 - ## APIバージョニング -フィールドの削除やリソース表現の再構成を簡単に行えるようにするため、Kubernetesは複数のAPIバージョンをサポートしており、`/api/v1`や`/apis/extensions/v1beta1`のように、それぞれ異なるAPIのパスが割り当てられています。 +フィールドの削除やリソース表現の再構成を簡単に行えるようにするため、Kubernetesは複数のAPIバージョンをサポートしており、`/api/v1`や`/apis/rbac.authorization.k8s.io/v1alpha1`のように、それぞれ異なるAPIのパスが割り当てられています。 -APIが、システムリソースと動作について明確かつ一貫したビューを提供し、サポート終了、実験的なAPIへのアクセス制御を有効にするために、リソースまたはフィールドレベルではなく、APIレベルでバージョンを付けることを選択しました。JSONとProtocol Buffersのシリアライズスキーマも、スキーマ変更に関して同じガイドラインに従います。ここから以下の説明は、双方のフォーマットをカバーしています。 +APIが、システムリソースと動作について明確かつ一貫したビューを提供し、サポート終了、実験的なAPIへのアクセス制御を有効にするために、リソースまたはフィールドレベルではなく、APIレベルでバージョンが行われます。 + +JSONとProtocol Buffersのシリアライズスキーマも、スキーマ変更に関して同じガイドラインに従います。ここから以下の説明は、双方のフォーマットをカバーしています。 APIとソフトウエアのバージョニングは、間接的にしか関連していないことに注意してください。[APIとリリースバージョニング提案](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md)で、APIとソフトウェアのバージョニングの関連について記載しています。 -異なるバージョンのAPIでは、安定性やサポートのレベルも変わります。各レベルの詳細な条件は、[API変更ドキュメント](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions)に記載されています。下記に簡潔にまとめます: +異なるバージョンのAPIでは、安定性やサポートのレベルも変わります。各レベルの詳細な条件は、[API変更](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions)に記載されています。下記に簡潔にまとめます: - アルファレベル(版): - バージョン名に`alpha`を含みます(例、`v1alpha1`)。 @@ -88,29 +105,37 @@ APIとソフトウエアのバージョニングは、間接的にしか関連 ## APIグループ {#api-groups} -KubernetesAPIの拡張を簡易に行えるようにするため、[*APIグループ*](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md)を実装しました。 +APIの拡張を簡易に行えるようにするため、Kubernetesは[*APIグループ*](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md)を実装しました。 APIグループは、RESTのパスとシリアライズされたオブジェクトの`apiVersion`フィールドで指定されます。 -現在、いくつかのAPIグループが利用されています: +クラスターにはいくつかのAPIグループがあります: -1. *core* グループ(たびたび、*legacy group* と呼ばれます)は、`/api/v1`というRESTのパスで、`apiVersion: v1`を使います。 +1. *core* グループ(*legacy group* とも呼ばれます)は、`/api/v1`というRESTのパスで、`apiVersion: v1`を使います。 -1. 名前付きのグループは、`/apis/$GROUP_NAME/$VERSION`というRESTのパスで、`apiVersion: $GROUP_NAME/$VERSION`(例、`apiVersion: batch/v1`)を使います。サポートされているAPIグループの全リストは、[Kubernetes APIリファレンス](/docs/reference/)を参照してください。 +1. 名前付きのグループは、`/apis/$GROUP_NAME/$VERSION`というRESTのパスで、`apiVersion: $GROUP_NAME/$VERSION`(例、`apiVersion: batch/v1`)を使います。Kubernetesの[APIリファレンス](/docs/reference/kubernetes-api/)にすべての使用可能なAPIグループのリストがあります。 -[カスタムリソース](/docs/concepts/api-extension/custom-resources/)でAPIを拡張するために、2つの方法がサポートされています: +[カスタムリソース](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)でAPIを拡張するために、2つの方法があります: -1. [カスタムリソース定義](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/)は、とても基本的なCRUDが必要なユーザー向けです。 -1. 独自のAPIサーバーを実装可能な、フルセットのKubernetes APIが必要なユーザーは、[アグリゲーター](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/)を使い、クライアントにシームレスな形で拡張を行います。 +1. [カスタムリソース定義](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)は、APIサーバーが選択したリソースAPIを提供する方法を宣言的に定義できます。 +1. [独自の拡張APIサーバーを実装](/docs/tasks/extend-kubernetes/setup-extension-api-server/)し、[アグリゲーター](/docs/tasks/extend-kubernetes/configure-aggregation-layer/)を使用してクライアントに対してシームレスにすることもできます。 ## APIグループの有効化、無効化 -いくつかのリソースとAPIグループはデフォルトで有効になっています。それらは、APIサーバーの`--runtime-config`設定で、有効化、無効化できます。`--runtime-config`は、カンマ区切りの複数の値を設定可能です。例えば、batch/v1を無効化する場合、`--runtime-config=batch/v1=false`をセットし、batch/v2alpha1を有効化する場合、`--runtime-config=batch/v2alpha1`をセットします。このフラグは、APIサーバーのランタイム設定を表すkey=valueのペアを、カンマ区切りで指定したセットを指定可能です。 +いくつかのリソースとAPIグループはデフォルトで有効になっています。それらは、kube-apiserverのコマンドラインオプションとしてAPIサーバーの`--runtime-config`設定で、有効化、無効化できます。 -{{< note >}}APIグループ、リソースの有効化、無効化は、`--runtime-config`の変更を反映するため、APIサーバーとコントローラーマネージャーの再起動が必要です。{{< /note >}} +`--runtime-config`は、カンマ区切りの複数の値を設定可能です。例えば、batch/v1を無効化する場合、`--runtime-config=batch/v1=false`をセットし、batch/v2alpha1を有効化する場合、`--runtime-config=batch/v2alpha1`をセットします。このフラグは、APIサーバーのランタイム設定を表すkey=valueのペアを、カンマ区切りで指定したセットを指定可能です。 -## APIグループextensions/v1beta1に含まれる特定のリソースの有効化 +{{< note >}}APIグループ、リソースの有効化、無効化は、`--runtime-config`の変更を反映するため、kube-apiserverとkube-controller-managerの再起動が必要です。{{< /note >}} -APIグループ`extensions/v1beta1`に含まれるDaemonSets、Deployments、StatefulSet、NetworkPolicies、PodSecurityPolicies、ReplicaSetsはデフォルトで無効にされています。 -例えば、deploymentとdaemonsetを有効にするには、`--runtime-config=extensions/v1beta1/deployments=true,extensions/v1beta1/daemonsets=true`と設定します。 +## 永続性 -{{< note >}}リソースを個別に有効化、無効化することは歴史的な理由によりAPIグループ`extensions/v1beta1`に含まれるリソースに限りサポートされています。{{< /note >}} +KubernetesはAPIリソースの観点からシリアル化された状態を{{< glossary_tooltip term_id="etcd" >}}に書き込むことで保存します。 + + +## {{% heading "whatsnext" %}} + +[APIアクセスの制御](/docs/reference/access-authn-authz/controlling-access/)は、クラスターがAPIアクセスの認証と承認を管理する方法を説明しています。 + +全体的なAPI規則は、[API規則](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#api-conventions)の資料で説明されています。 + +APIエンドポイント、リソースタイプ、サンプルについては、[APIリファレンス](/docs/reference/kubernetes-api/)をご覧ください。 From 8f0e8074b6cb50953b38084b19ae110801fb18d9 Mon Sep 17 00:00:00 2001 From: yoichiro0217 Date: Sat, 12 Sep 2020 09:44:57 +0900 Subject: [PATCH 162/252] =?UTF-8?q?issue-23614=E3=81=AE=E6=97=A5=E6=9C=AC?= =?UTF-8?q?=E8=AA=9E=E7=BF=BB=E8=A8=B3=20=E3=82=B3=E3=83=A1=E3=83=B3?= =?UTF-8?q?=E3=83=88=E5=AF=BE=E5=BF=9C?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- content/ja/docs/concepts/overview/kubernetes-api.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/overview/kubernetes-api.md b/content/ja/docs/concepts/overview/kubernetes-api.md index 764fae9d0b..188d463df8 100644 --- a/content/ja/docs/concepts/overview/kubernetes-api.md +++ b/content/ja/docs/concepts/overview/kubernetes-api.md @@ -13,7 +13,7 @@ card: -Kubernetesの中核である' {{< glossary_tooltip text="control plane" term_id="control-plane" >}}は{{< glossary_tooltip text="API server" term_id="kube-apiserver" >}} です。 +Kubernetesの中核である {{< glossary_tooltip text="control plane" term_id="control-plane" >}}は{{< glossary_tooltip text="API server" term_id="kube-apiserver" >}} です。 APIサーバーは、エンドユーザー、クラスターのさまざまな部分、および外部コンポーネントが相互に通信できるようにするHTTP APIを公開します。 Kubernetes APIを使用すると、Kubernetes API内のオブジェクトの状態をクエリで操作できます（例：Pod、Namespace、ConfigMap、Events）。 @@ -34,7 +34,7 @@ Kubernetesプロジェクトは、既存のクライアントとの互換性を 互換性のある変更の構成要素とAPIの変更方法については、[API変更](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme)で詳しく説明しています。 -**OpenAPI 仕様 {#api-specification} +## OpenAPI 仕様 {#api-specification} Kubernetes APIサーバーは、`/openapi/v2`エンドポイントを介してOpenAPI仕様を提供します。 次のように要求ヘッダーを使用して、応答フォーマットを要求できます。 From fd3dcc27774b02fcd2b20728b22861d3fda3561f Mon Sep 17 00:00:00 2001 From: yoichiro0217 Date: Fri, 18 Sep 2020 17:55:43 +0900 Subject: [PATCH 163/252] =?UTF-8?q?=E3=82=B3=E3=83=A1=E3=83=B3=E3=83=88?= =?UTF-8?q?=E5=AF=BE=E5=BF=9C?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- content/ja/docs/concepts/overview/kubernetes-api.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/content/ja/docs/concepts/overview/kubernetes-api.md b/content/ja/docs/concepts/overview/kubernetes-api.md index 188d463df8..251f671b6d 100644 --- a/content/ja/docs/concepts/overview/kubernetes-api.md +++ b/content/ja/docs/concepts/overview/kubernetes-api.md @@ -29,13 +29,15 @@ APIエンドポイント、リソースタイプ、サンプルについては[A Kubernetesプロジェクトは、既存のクライアントとの互換性を破壊しないこと、およびその互換性を一定期間維持して、他のプロジェクトが適応する機会を提供することを目的としています。 基本的に、新しいAPIリソースと新しいリソースフィールドは追加することができます。 -リソースまたはフィールドを削除するには、次のポリシーに従ってください。[API非推奨ポリシー](/docs/reference/using-api/deprecation-policy/). +リソースまたはフィールドを削除するには、[API非推奨ポリシー](/docs/reference/using-api/deprecation-policy/)に従ってください。 -互換性のある変更の構成要素とAPIの変更方法については、[API変更](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme)で詳しく説明しています。 +互換性のある変更の構成要素とAPIの変更方法については、[APIの変更](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme)で詳しく説明しています。 ## OpenAPI 仕様 {#api-specification} +完全なAPIの詳細は、[OpenAPI](https://www.openapis.org/)を使用して文書化されています。 + Kubernetes APIサーバーは、`/openapi/v2`エンドポイントを介してOpenAPI仕様を提供します。 次のように要求ヘッダーを使用して、応答フォーマットを要求できます。 @@ -84,7 +86,7 @@ JSONとProtocol Buffersのシリアライズスキーマも、スキーマ変更 APIとソフトウエアのバージョニングは、間接的にしか関連していないことに注意してください。[APIとリリースバージョニング提案](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md)で、APIとソフトウェアのバージョニングの関連について記載しています。 -異なるバージョンのAPIでは、安定性やサポートのレベルも変わります。各レベルの詳細な条件は、[API変更](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions)に記載されています。下記に簡潔にまとめます: +異なるバージョンのAPIでは、安定性やサポートのレベルも変わります。各レベルの詳細な条件は、[APIの変更](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions)に記載されています。下記に簡潔にまとめます: - アルファレベル(版): - バージョン名に`alpha`を含みます(例、`v1alpha1`)。 From 088c4dc011ee9e9c4ce5b1b974b98049f86d7f71 Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Fri, 18 Sep 2020 12:15:36 +0900 Subject: [PATCH 164/252] Update ja/docs/concepts/services-networking/connect-applications-service.md --- .../services-networking/connect-applications-service.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/content/ja/docs/concepts/services-networking/connect-applications-service.md b/content/ja/docs/concepts/services-networking/connect-applications-service.md index 0d61ce938c..423b114096 100644 --- a/content/ja/docs/concepts/services-networking/connect-applications-service.md +++ b/content/ja/docs/concepts/services-networking/connect-applications-service.md @@ -23,7 +23,6 @@ Kubernetesでは、どのホストで稼働するかに関わらず、Podが他 このドキュメントの残りの部分では、このようなネットワークモデルで信頼できるサービスを実行する方法について詳しく説明します。 このガイドでは、シンプルなnginxサーバーを使用して概念実証を示します。 -同じ原則が、より完全な[Jenkins CIアプリケーション](https://kubernetes.io/blog/2015/07/strong-simple-ssl-for-kubernetes)で具体化されています。 @@ -140,7 +139,7 @@ Service IPは完全に仮想的なもので、ホスト側のネットワーク ## Serviceにアクセスする Kubernetesは、環境変数とDNSの2つの主要なService検索モードをサポートしています。 -前者はそのまま使用でき、後者は[CoreDNSクラスタアドオン](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/coredns)を必要とします。 +前者はそのまま使用でき、後者は[CoreDNSクラスタアドオン](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/coredns)を必要とします。 {{< note >}} サービス環境変数が望ましくない場合(予想されるプログラム変数と衝突する可能性がある、処理する変数が多すぎる、DNSのみを使用するなど)、[Pod仕様](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)で`enableServiceLinks`フラグを`false`に設定することでこのモードを無効にできます。 {{< /note >}} @@ -400,8 +399,8 @@ kubectl edit svc my-nginx kubectl get svc my-nginx ``` ``` -NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE -my-nginx ClusterIP 10.0.162.149 162.222.184.144 80/TCP,81/TCP,82/TCP 21s +NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE +my-nginx LoadBalancer 10.0.162.149 xx.xxx.xxx.xxx 8080:30163/TCP 21s ``` ``` curl https:// -k From 7a6f50df4dc1f320d8d72b45b71956202d692615 Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Fri, 18 Sep 2020 13:21:39 +0900 Subject: [PATCH 165/252] Update ja/docs/concepts/services-networking/dns-pod-service.md --- .../services-networking/dns-pod-service.md | 20 ++++++++++++++++--- 1 file changed, 17 insertions(+), 3 deletions(-) diff --git a/content/ja/docs/concepts/services-networking/dns-pod-service.md b/content/ja/docs/concepts/services-networking/dns-pod-service.md index 7e65022304..4375928a45 100644 --- a/content/ja/docs/concepts/services-networking/dns-pod-service.md +++ b/content/ja/docs/concepts/services-networking/dns-pod-service.md @@ -42,6 +42,20 @@ Headless Serviceに対しては、このSRVレコードは複数の結果を返 ## Pod +### A/AAAAレコード + +一般的にPodは下記のDNS解決となります。 + +`pod-ip-address.my-namespace.pod.cluster-domain.example` + +例えば、`default`ネームスペースのpodのIPアドレスが172.17.0.3で、クラスターのドメイン名が`cluster.local`の場合、PodのDNS名は以下になります。 + +`172-17-0-3.default.pod.cluster.local` + +DeploymentかDaemonSetに作成され、Serviceに公開されるどのPodも以下のDNS解決が利用できます。 + +`pod-ip-address.deployment-name.my-namespace.svc.cluster-domain.example` + ### Podのhostnameとsubdomainフィールド 現在、Podが作成されたとき、そのPodのホスト名はPodの`metadata.name`フィールドの値となります。 @@ -113,9 +127,9 @@ A(AAAA)レコードはPodの名前に対して作成されないため、`hostna DNSポリシーはPod毎に設定できます。現在のKubernetesでは次のようなPod固有のDNSポリシーをサポートしています。これらのポリシーはPod Specの`dnsPolicy`フィールドで指定されます。 - "`Default`": そのPodはPodが稼働しているNodeから名前解決の設定を継承します。詳細に関しては、[関連する議論](/docs/tasks/administer-cluster/dns-custom-nameservers/#inheriting-dns-from-the-node)を参照してください。 -- "`ClusterFirst`": "`www.kubernetes.io`"のようなクラスタードメインのサフィックスにマッチしないようなDNSクエリーは、Nodeから継承された上流のネームサーバーにフォワーディングされます。クラスター管理者は、追加のstubドメインと上流のDNSサーバーを設定できます。 +- "`ClusterFirst`": "`www.kubernetes.io`"のようなクラスタードメインのサフィックスにマッチしないようなDNSクエリーは、Nodeから継承された上流のネームサーバーにフォワーディングされます。クラスター管理者は、追加のstubドメインと上流のDNSサーバーを設定できます。このような場合におけるDNSクエリー処理の詳細に関しては、[関連する議論](/docs/tasks/administer-cluster/dns-custom-nameservers/#effects-on-pods)を参照してください。 - "`ClusterFirstWithHostNet`": hostNetworkによって稼働しているPodに対しては、ユーザーは明示的にDNSポリシーを"`ClusterFirstWithHostNet`"とセットするべきです。 -- "`None`": この設定では、Kubernetesの環境からDNS設定を無視することができます。全てのDNS設定は、Pod Spec内の`dnsConfig`フィールドを指定して提供することになっています。下記のセクションの[Pod's DNS config](#pod-s-dns-config)を参照ください。 +- "`None`": この設定では、Kubernetesの環境からDNS設定を無視することができます。全てのDNS設定は、Pod Spec内の`dnsConfig`フィールドを指定して提供することになっています。下記のセクションの[Pod's DNS config](#pod-dns-config)を参照ください。 {{< note >}} "Default"は、デフォルトのDNSポリシーではありません。もし`dnsPolicy`が明示的に指定されていない場合、"ClusterFirst"が使用されます。 @@ -142,7 +156,7 @@ spec: dnsPolicy: ClusterFirstWithHostNet ``` -### PodのDNS設定 {#pods-dns-config} +### PodのDNS設定 {#pod-dns-config} PodのDNS設定は、ユーザーがPodに対してそのDNS設定上でさらに制御するための手段を提供します。 From 890c2121010383705bd0c0ea096ac7a9d203ea63 Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Sun, 13 Sep 2020 22:00:59 +0900 Subject: [PATCH 166/252] Translated multiple-zones.md --- .../setup/best-practices/multiple-zones.md | 163 ++++++------------ 1 file changed, 55 insertions(+), 108 deletions(-) diff --git a/content/ja/docs/setup/best-practices/multiple-zones.md b/content/ja/docs/setup/best-practices/multiple-zones.md index 3590f6fa8c..41b24cb29f 100644 --- a/content/ja/docs/setup/best-practices/multiple-zones.md +++ b/content/ja/docs/setup/best-practices/multiple-zones.md @@ -14,93 +14,50 @@ This page describes how to run a cluster in multiple zones. ## 始めに -Kubernetes 1.2 adds support for running a single cluster in multiple failure zones -(GCE calls them simply "zones", AWS calls them "availability zones", here we'll refer to them as "zones"). -This is a lightweight version of a broader Cluster Federation feature (previously referred to by the affectionate -nickname ["Ubernetes"](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/multicluster/federation.md)). -Full Cluster Federation allows combining separate -Kubernetes clusters running in different regions or cloud providers -(or on-premises data centers). However, many -users simply want to run a more available Kubernetes cluster in multiple zones -of their single cloud provider, and this is what the multizone support in 1.2 allows -(this previously went by the nickname "Ubernetes Lite"). +Kubernetes 1.2は複数のゾーンにおいて単一のクラスターを運用するサポートを追加しました(GCEでは単純に"ゾーン"，AWSは"アベイラビリティゾーン"と呼びますが、ここでは"ゾーン"とします)。 +これは、より範囲の広いCluster Federationの軽量バージョンです(以前は["Ubernetes"](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/multicluster/federation.md)の愛称で言及されていました)。 +完全なCluster Federationでは、異なるリージョンやクラウドプロバイダー(あるいはオンプレミスデータセンター)内の独立したKubernetesクラスターをまとめることが可能になります。しかしながら、多くのユーザーは単に１つのクラウドプロバイダーの複数のゾーンでより可用性の高いKubernetesクラスターを運用したいと考えており、バージョン1.2におけるマルチゾーンサポート(以前は"Ubernetes Lite"の愛称で使用されていました)ではこれが可能になります。 -Multizone support is deliberately limited: a single Kubernetes cluster can run -in multiple zones, but only within the same region (and cloud provider). Only -GCE and AWS are currently supported automatically (though it is easy to -add similar support for other clouds or even bare metal, by simply arranging -for the appropriate labels to be added to nodes and volumes). +マルチゾーンサポートは故意に限定されています: １つのKubernetesクラスターは複数のゾーンで運用することができますが、同じリージョン(あるいはクラウドプロバイダー)のみです。現在はGCEとAWSのみが自動的にサポートされています(他のクラウドプロバイダーやベアメタル環境においても、単にノードやボリュームに追加する適切なラベルを用意して同様のサポートを追加することは容易ではありますが)。 ## 機能性 -When nodes are started, the kubelet automatically adds labels to them with -zone information. +ノードが開始された時、kubeletは自動的にそれらにゾーン情報を付したラベルを追加します。 -Kubernetes will automatically spread the pods in a replication controller -or service across nodes in a single-zone cluster (to reduce the impact of -failures.) With multiple-zone clusters, this spreading behavior is -extended across zones (to reduce the impact of zone failures.) (This is -achieved via `SelectorSpreadPriority`). This is a best-effort -placement, and so if the zones in your cluster are heterogeneous -(e.g. different numbers of nodes, different types of nodes, or -different pod resource requirements), this might prevent perfectly -even spreading of your pods across zones. If desired, you can use -homogeneous zones (same number and types of nodes) to reduce the -probability of unequal spreading. +Kubernetesはレプリケーションコントローラーやサービス内のPodをシングルゾーンクラスターにおけるノードにデプロイします(障害の影響を減らすため)。マルチゾーンクラスターでは、このデプロイの挙動はゾーンを跨いで拡張されます(障害の影響を減らすため)(これは`SelectorSpreadPriority`によって可能になります)。これはベストエフォートな配置であり、つまりもしクラスターのゾーンが異種である(例:異なる数のノード，異なるタイプのノードや異なるPodのリソース要件)場合、これはゾーンを跨いだPodのデプロイを完璧に防ぐことができます。必要であれば、同種のゾーン(同一の数及びタイプのノード)を利用して不平等なデプロイの可能性を減らすことができます。 -When persistent volumes are created, the `PersistentVolumeLabel` -admission controller automatically adds zone labels to them. The scheduler (via the -`VolumeZonePredicate` predicate) will then ensure that pods that claim a -given volume are only placed into the same zone as that volume, as volumes -cannot be attached across zones. +永続ボリュームが作成されると、`PersistentVolumeLabel`アドミッションコントローラーがそれらにゾーンラベルを付与します。スケジューラーは`VolumeZonePredicate`を通じて与えられたボリュームを請求するPodがそのボリュームと同じゾーンにのみ配置されることを保証します、これはボリュームはゾーンを跨いでアタッチすることができないためです。 ## 制限 -There are some important limitations of the multizone support: +マルチゾーンサポートにはいくつか重要な制限があります: -* We assume that the different zones are located close to each other in the -network, so we don't perform any zone-aware routing. In particular, traffic -that goes via services might cross zones (even if some pods backing that service -exist in the same zone as the client), and this may incur additional latency and cost. +* 異なるゾーンはネットワーク内においてお互いに近接して位置していることが想定されているため、いかなるzone-aware routingも行われません。特に、トラフィックはゾーンを跨いだサービスを通じて行き来するため(サービスをサポートするいくつかのPodがクライアントと同じゾーンに存在していても)、これは追加のレイテンシやコストを生むかもしれません。 -* Volume zone-affinity will only work with a `PersistentVolume`, and will not -work if you directly specify an EBS volume in the pod spec (for example). +* Volume zone-affinityは`PersistentVolume`と共に動作し、例えばPodのスペックにおいてEBSボリュームを直接指定しても動作しません。 -* Clusters cannot span clouds or regions (this functionality will require full -federation support). +* クラスターはクラウドやリージョンを跨げません(この機能はフルフェデレーションサポートが必要です)。 -* Although your nodes are in multiple zones, kube-up currently builds -a single master node by default. While services are highly -available and can tolerate the loss of a zone, the control plane is -located in a single zone. Users that want a highly available control -plane should follow the [high availability](/docs/admin/high-availability) instructions. +*ノードは複数のゾーンに存在しますが、kube-upは現在デフォルトではシングルマスターノードでビルドします。サービスは高可用性でありゾーンの障害に耐えることができますが、コントロールプレーンは単一のゾーンに位置します。高可用性コントロールプレーンを必要とするユーザーは[高可用性](/ja/docs/setup/production-environment/tools/kubeadm/high-availability/)の説明を参照してください。 ### ボリュームの制限 -The following limitations are addressed with [topology-aware volume binding](/docs/concepts/storage/storage-classes/#volume-binding-mode). -* StatefulSet volume zone spreading when using dynamic provisioning is currently not compatible with - pod affinity or anti-affinity policies. +以下の制限は[topology-aware volume binding](/docs/concepts/storage/storage-classes/#volume-binding-mode)に記載されています。 -* If the name of the StatefulSet contains dashes ("-"), volume zone spreading - may not provide a uniform distribution of storage across zones. +* 動的なプロビジョニングを使用する際のStatefulSetボリュームゾーンのデプロイは、現在Podのアフィニティあるいはアンチアフィニティと互換性がありません。 -* When specifying multiple PVCs in a Deployment or Pod spec, the StorageClass - needs to be configured for a specific single zone, or the PVs need to be - statically provisioned in a specific zone. Another workaround is to use a - StatefulSet, which will ensure that all the volumes for a replica are - provisioned in the same zone. +* StatefulSetの名前がダッシュ("-")を含む場合、ボリュームゾーンのデプロイはゾーンを跨いだストレージの均一な分配を提供ない可能性があります。 + +* DeploymentやPodのスペックにおいて複数のPVCを指定すると、StorageClassは特定の１つのゾーンに割り当てる必要があります、あるいはPVは特定のゾーンに静的にプロビジョンされる必要があります。もう一つの解決方法として、StatefulSetを使用すると、レプリカに対する全てのボリュームが同じゾーンにプロビジョンされます。 ## 全体の流れ -We're now going to walk through setting up and using a multi-zone -cluster on both GCE & AWS. To do so, you bring up a full cluster -(specifying `MULTIZONE=true`), and then you add nodes in additional zones -by running `kube-up` again (specifying `KUBE_USE_EXISTING_MASTER=true`). +GCEとAWSの両方にマルチゾーンのクラスターをセットアップし使用する手順について説明します。そのために、フルクラスターを用意し(`MULTIZONE=true`と指定する)、`kube-up`を再び実行して追加のゾーンにノードを追加します(`KUBE_USE_EXISTING_MASTER=true`と指定する)。 ### クラスターの立ち上げ -Create the cluster as normal, but pass MULTIZONE to tell the cluster to manage multiple zones; creating nodes in us-central1-a. +通常と同様にクラスターを作成します、しかし複数のゾーンを管理するためにMULTIZONEをクラスターに設定します。ノードをus-central1-aに作成します。 GCE: @@ -114,21 +71,20 @@ AWS: curl -sS https://get.k8s.io | MULTIZONE=true KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2a NUM_NODES=3 bash ``` -This step brings up a cluster as normal, still running in a single zone -(but `MULTIZONE=true` has enabled multi-zone capabilities). +このステップは通常と同様にクラスターを立ち上げ、１つのゾーンで動作しています(しかし、`MULTIZONE=true`によりマルチゾーン能力は有効になっています)。 + ### ノードはラベルが付与される -View the nodes; you can see that they are labeled with zone information. -They are all in `us-central1-a` (GCE) or `us-west-2a` (AWS) so far. The -labels are `failure-domain.beta.kubernetes.io/region` for the region, -and `failure-domain.beta.kubernetes.io/zone` for the zone: +ノードを見てください。それらがゾーン情報と共にラベルされているのが分かります。 +それら全ては今のところ`us-central1-a` (GCE)あるいは`us-west-2a` (AWS)にあります。ラベルは`failure-domain.beta.kubernetes.io/region`がリージョンに、`failure-domain.beta.kubernetes.io/zone`はゾーンに付けられています: + ```shell kubectl get nodes --show-labels ``` -The output is similar to this: +結果は以下のようになります: ```shell NAME STATUS ROLES AGE VERSION LABELS @@ -140,11 +96,8 @@ kubernetes-minion-a12q Ready 6m v1.13.0 ### 2つ目のゾーンにさらにノードを追加 -Let's add another set of nodes to the existing cluster, reusing the -existing master, running in a different zone (us-central1-b or us-west-2b). -We run kube-up again, but by specifying `KUBE_USE_EXISTING_MASTER=true` -kube-up will not create a new master, but will reuse one that was previously -created instead. +それでは、現存のマスターを再利用して現存のクラスターにもう１つのノードのセットを追加しましょう。 +kube-upを再び実行します．しかし`KUBE_USE_EXISTING_MASTER=true`を指定することでkube-upは新しいマスターを作成せず、代わりに以前作成したものを再利用します。 GCE: @@ -152,22 +105,21 @@ GCE: KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=gce KUBE_GCE_ZONE=us-central1-b NUM_NODES=3 kubernetes/cluster/kube-up.sh ``` -On AWS we also need to specify the network CIDR for the additional -subnet, along with the master internal IP address: + +AWSではマスターの内部IPアドレスに加えて追加のサブネット用のネットワークCIDRを指定する必要があります: ```shell KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2b NUM_NODES=3 KUBE_SUBNET_CIDR=172.20.1.0/24 MASTER_INTERNAL_IP=172.20.0.9 kubernetes/cluster/kube-up.sh ``` -View the nodes again; 3 more nodes should have launched and be tagged -in us-central1-b: +ノードをもう１度見てください。更なる3つのノードがus-central1-bに起動し、タグ付けられているはずです: ```shell kubectl get nodes --show-labels ``` -The output is similar to this: +結果は以下のようになります: ```shell NAME STATUS ROLES AGE VERSION LABELS @@ -182,7 +134,7 @@ kubernetes-minion-wf8i Ready 2m v1.13.0 ### ボリュームのアフィニティ -Create a volume using the dynamic volume creation (only PersistentVolumes are supported for zone affinity): +動的ボリュームを使用してボリュームを作成します(PersistentVolumeのみがゾーンアフィニティに対してサポートされています): ```bash kubectl apply -f - <}} -For version 1.3+ Kubernetes will distribute dynamic PV claims across -the configured zones. For version 1.2, dynamic persistent volumes were -always created in the zone of the cluster master -(here us-central1-a / us-west-2a); that issue +バージョン1.3以降のKubernetesは設定したゾーンを跨いでPVクレームを分配します。 +バージョン1.2では動的永続ボリュームは常にクラスターのマスターがあるゾーンに作成されます。 +(ここではus-central1-a / us-west-2a); このイシューは ([#23330](https://github.com/kubernetes/kubernetes/issues/23330)) -was addressed in 1.3+. +にバージョン1.3以降で記載されています。 {{< /note >}} -Now let's validate that Kubernetes automatically labeled the zone & region the PV was created in. +それでは、KubernetesがPVが作成されたゾーン及びリージョンを自動的にラベルしているか確認しましょう。 ```shell kubectl get pv --show-labels ``` -The output is similar to this: +結果は以下のようになります: ```shell NAME CAPACITY ACCESSMODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE LABELS pv-gce-mj4gm 5Gi RWO Retain Bound default/claim1 manual 46s failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a ``` -So now we will create a pod that uses the persistent volume claim. -Because GCE PDs / AWS EBS volumes cannot be attached across zones, -this means that this pod can only be created in the same zone as the volume: +では永続ボリュームクレームを使用するPodを作成します。 +GCE PD / AWS EBSボリュームはゾーンを跨いでアタッチできないため、これはこのPodがボリュームと同じゾーンにのみ作成されることを意味します: ```yaml kubectl apply -f - < 3m v1.13.0 beta.kuberne ``` -Load-balancers span all zones in a cluster; the guestbook-go example -includes an example load-balanced service: +ロードバランサーはクラスター内の全てのゾーンにデプロイされています; guestbook-goの例は負荷分散サービスのサンプルを含みます: ```shell kubectl describe service guestbook | grep LoadBalancer.Ingress ``` -The output is similar to this: +結果は以下のようになります: ```shell LoadBalancer Ingress: 130.211.126.21 ``` -Set the above IP: +IPの上に設定します: ```shell export IP=130.211.126.21 ``` -Explore with curl via IP: +IPをcurlを通じて探索します: ```shell curl -s http://${IP}:3000/env | grep HOSTNAME ``` -The output is similar to this: +結果は以下のようになります: ```shell "HOSTNAME": "guestbook-44sep", ``` -Again, explore multiple times: +再び、複数回探索します: ```shell (for i in `seq 20`; do curl -s http://${IP}:3000/env | grep HOSTNAME; done) | sort | uniq ``` -The output is similar to this: +結果は以下のようになります: ```shell "HOSTNAME": "guestbook-44sep", @@ -375,11 +322,11 @@ The output is similar to this: "HOSTNAME": "guestbook-ppm40", ``` -The load balancer correctly targets all the pods, even though they are in multiple zones. +ロードバランサーは、たとえPodが複数のゾーンに存在していても、全てのPodをターゲットします。 ### クラスターの停止 -When you're done, clean up: +終了したら、クリーンアップします: GCE: From 7878c052d63e64486afb727f5364bbd005012252 Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Mon, 14 Sep 2020 14:14:35 +0900 Subject: [PATCH 167/252] Apply suggestions from code review Co-authored-by: Keita Akutsu --- content/ja/docs/setup/best-practices/multiple-zones.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/content/ja/docs/setup/best-practices/multiple-zones.md b/content/ja/docs/setup/best-practices/multiple-zones.md index 41b24cb29f..5d5ba2e2f2 100644 --- a/content/ja/docs/setup/best-practices/multiple-zones.md +++ b/content/ja/docs/setup/best-practices/multiple-zones.md @@ -39,7 +39,7 @@ Kubernetesはレプリケーションコントローラーやサービス内のP * クラスターはクラウドやリージョンを跨げません(この機能はフルフェデレーションサポートが必要です)。 -*ノードは複数のゾーンに存在しますが、kube-upは現在デフォルトではシングルマスターノードでビルドします。サービスは高可用性でありゾーンの障害に耐えることができますが、コントロールプレーンは単一のゾーンに位置します。高可用性コントロールプレーンを必要とするユーザーは[高可用性](/ja/docs/setup/production-environment/tools/kubeadm/high-availability/)の説明を参照してください。 +*ノードは複数のゾーンに存在しますが、kube-upは現在デフォルトではシングルマスターノードでビルドします。サービスは高可用性でありゾーンの障害に耐えることができますが、コントロールプレーンは単一のゾーンに配置されます。高可用性コントロールプレーンを必要とするユーザーは[高可用性](/ja/docs/setup/production-environment/tools/kubeadm/high-availability/)の説明を参照してください。 ### ボリュームの制限 @@ -47,7 +47,7 @@ Kubernetesはレプリケーションコントローラーやサービス内のP * 動的なプロビジョニングを使用する際のStatefulSetボリュームゾーンのデプロイは、現在Podのアフィニティあるいはアンチアフィニティと互換性がありません。 -* StatefulSetの名前がダッシュ("-")を含む場合、ボリュームゾーンのデプロイはゾーンを跨いだストレージの均一な分配を提供ない可能性があります。 +* StatefulSetの名前がダッシュ("-")を含む場合、ボリュームゾーンのデプロイはゾーンを跨いだストレージの均一な分配を提供しない可能性があります。 * DeploymentやPodのスペックにおいて複数のPVCを指定すると、StorageClassは特定の１つのゾーンに割り当てる必要があります、あるいはPVは特定のゾーンに静的にプロビジョンされる必要があります。もう一つの解決方法として、StatefulSetを使用すると、レプリカに対する全てのボリュームが同じゾーンにプロビジョンされます。 @@ -96,7 +96,7 @@ kubernetes-minion-a12q Ready 6m v1.13.0 ### 2つ目のゾーンにさらにノードを追加 -それでは、現存のマスターを再利用して現存のクラスターにもう１つのノードのセットを追加しましょう。 +それでは、現存のマスターを再利用し、現存のクラスターの異なるゾーン(us-central1-bかus-west-2b)にもう１つのノードのセットを追加しましょう。 kube-upを再び実行します．しかし`KUBE_USE_EXISTING_MASTER=true`を指定することでkube-upは新しいマスターを作成せず、代わりに以前作成したものを再利用します。 GCE: @@ -344,4 +344,3 @@ 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 ``` - From db5302c78be6284a788e1893d55b619e0bfe429f Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Thu, 17 Sep 2020 20:51:20 +0900 Subject: [PATCH 168/252] replace zenkaku numbers with hankaku numbers --- .../setup/best-practices/multiple-zones.md | 20 +++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/content/ja/docs/setup/best-practices/multiple-zones.md b/content/ja/docs/setup/best-practices/multiple-zones.md index 5d5ba2e2f2..3f3eebd9e4 100644 --- a/content/ja/docs/setup/best-practices/multiple-zones.md +++ b/content/ja/docs/setup/best-practices/multiple-zones.md @@ -16,9 +16,9 @@ This page describes how to run a cluster in multiple zones. Kubernetes 1.2は複数のゾーンにおいて単一のクラスターを運用するサポートを追加しました(GCEでは単純に"ゾーン"，AWSは"アベイラビリティゾーン"と呼びますが、ここでは"ゾーン"とします)。 これは、より範囲の広いCluster Federationの軽量バージョンです(以前は["Ubernetes"](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/multicluster/federation.md)の愛称で言及されていました)。 -完全なCluster Federationでは、異なるリージョンやクラウドプロバイダー(あるいはオンプレミスデータセンター)内の独立したKubernetesクラスターをまとめることが可能になります。しかしながら、多くのユーザーは単に１つのクラウドプロバイダーの複数のゾーンでより可用性の高いKubernetesクラスターを運用したいと考えており、バージョン1.2におけるマルチゾーンサポート(以前は"Ubernetes Lite"の愛称で使用されていました)ではこれが可能になります。 +完全なCluster Federationでは、異なるリージョンやクラウドプロバイダー(あるいはオンプレミスデータセンター)内の独立したKubernetesクラスターをまとめることが可能になります。しかしながら、多くのユーザーは単に1つのクラウドプロバイダーの複数のゾーンでより可用性の高いKubernetesクラスターを運用したいと考えており、バージョン1.2におけるマルチゾーンサポート(以前は"Ubernetes Lite"の愛称で使用されていました)ではこれが可能になります。 -マルチゾーンサポートは故意に限定されています: １つのKubernetesクラスターは複数のゾーンで運用することができますが、同じリージョン(あるいはクラウドプロバイダー)のみです。現在はGCEとAWSのみが自動的にサポートされています(他のクラウドプロバイダーやベアメタル環境においても、単にノードやボリュームに追加する適切なラベルを用意して同様のサポートを追加することは容易ではありますが)。 +マルチゾーンサポートは故意に限定されています: 1つのKubernetesクラスターは複数のゾーンで運用することができますが、同じリージョン(あるいはクラウドプロバイダー)のみです。現在はGCEとAWSのみが自動的にサポートされています(他のクラウドプロバイダーやベアメタル環境においても、単にノードやボリュームに追加する適切なラベルを用意して同様のサポートを追加することは容易ではありますが)。 ## 機能性 @@ -49,7 +49,7 @@ Kubernetesはレプリケーションコントローラーやサービス内のP * StatefulSetの名前がダッシュ("-")を含む場合、ボリュームゾーンのデプロイはゾーンを跨いだストレージの均一な分配を提供しない可能性があります。 -* DeploymentやPodのスペックにおいて複数のPVCを指定すると、StorageClassは特定の１つのゾーンに割り当てる必要があります、あるいはPVは特定のゾーンに静的にプロビジョンされる必要があります。もう一つの解決方法として、StatefulSetを使用すると、レプリカに対する全てのボリュームが同じゾーンにプロビジョンされます。 +* DeploymentやPodのスペックにおいて複数のPVCを指定すると、StorageClassは特定の1つのゾーンに割り当てる必要があります、あるいはPVは特定のゾーンに静的にプロビジョンされる必要があります。もう一つの解決方法として、StatefulSetを使用すると、レプリカに対する全てのボリュームが同じゾーンにプロビジョンされます。 ## 全体の流れ @@ -71,7 +71,7 @@ AWS: curl -sS https://get.k8s.io | MULTIZONE=true KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2a NUM_NODES=3 bash ``` -このステップは通常と同様にクラスターを立ち上げ、１つのゾーンで動作しています(しかし、`MULTIZONE=true`によりマルチゾーン能力は有効になっています)。 +このステップは通常と同様にクラスターを立ち上げ、1つのゾーンで動作しています(しかし、`MULTIZONE=true`によりマルチゾーン能力は有効になっています)。 ### ノードはラベルが付与される @@ -96,7 +96,7 @@ kubernetes-minion-a12q Ready 6m v1.13.0 ### 2つ目のゾーンにさらにノードを追加 -それでは、現存のマスターを再利用し、現存のクラスターの異なるゾーン(us-central1-bかus-west-2b)にもう１つのノードのセットを追加しましょう。 +それでは、現存のマスターを再利用し、現存のクラスターの異なるゾーン(us-central1-bかus-west-2b)にもう1つのノードのセットを追加しましょう。 kube-upを再び実行します．しかし`KUBE_USE_EXISTING_MASTER=true`を指定することでkube-upは新しいマスターを作成せず、代わりに以前作成したものを再利用します。 GCE: @@ -113,7 +113,7 @@ KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=aws KUBE_AWS_ZO ``` -ノードをもう１度見てください。更なる3つのノードがus-central1-bに起動し、タグ付けられているはずです: +ノードをもう1度見てください。更なる3つのノードがus-central1-bに起動し、タグ付けられているはずです: ```shell kubectl get nodes --show-labels @@ -228,7 +228,7 @@ kubernetes-minion-9vlv Ready 22m v1.6.0+fff5156 beta.kubernetes.io/in ### Podがゾーンをまたがって配置される -レプリケーションコントローラーやサービス内のPodは自動的にゾーンに跨いでデプロイされます。まず、３つ目のゾーンに更なるノードを立ち上げましょう: +レプリケーションコントローラーやサービス内のPodは自動的にゾーンに跨いでデプロイされます。まず、3つ目のゾーンに更なるノードを立ち上げましょう: GCE: @@ -242,19 +242,19 @@ AWS: KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2c NUM_NODES=3 KUBE_SUBNET_CIDR=172.20.2.0/24 MASTER_INTERNAL_IP=172.20.0.9 kubernetes/cluster/kube-up.sh ``` -３つのゾーンにノードがあることを確認します: +3つのゾーンにノードがあることを確認します: ```shell kubectl get nodes --show-labels ``` -シンプルなWebアプリケーションを動作する、３つのRCを持つguestbook-goの例を作成します: +シンプルなWebアプリケーションを動作する、3つのRCを持つguestbook-goの例を作成します: ```shell find kubernetes/examples/guestbook-go/ -name '*.json' | xargs -I {} kubectl apply -f {} ``` -Podは３つの全てのゾーンにデプロイされているはずです: +Podは3つの全てのゾーンにデプロイされているはずです: ```shell kubectl describe pod -l app=guestbook | grep Node From b040c5a673594184049418d80c6d9cfcc0df060d Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Sat, 19 Sep 2020 20:51:59 +0900 Subject: [PATCH 169/252] apply a suggestion from review --- content/ja/docs/setup/best-practices/multiple-zones.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/setup/best-practices/multiple-zones.md b/content/ja/docs/setup/best-practices/multiple-zones.md index 3f3eebd9e4..3281230498 100644 --- a/content/ja/docs/setup/best-practices/multiple-zones.md +++ b/content/ja/docs/setup/best-practices/multiple-zones.md @@ -14,7 +14,7 @@ This page describes how to run a cluster in multiple zones. ## 始めに -Kubernetes 1.2は複数のゾーンにおいて単一のクラスターを運用するサポートを追加しました(GCEでは単純に"ゾーン"，AWSは"アベイラビリティゾーン"と呼びますが、ここでは"ゾーン"とします)。 +Kubernetes 1.2より、複数のゾーンにおいて単一のクラスターを運用するサポートが追加されました(GCEでは単純に"ゾーン"，AWSは"アベイラビリティゾーン"と呼びますが、ここでは"ゾーン"とします)。 これは、より範囲の広いCluster Federationの軽量バージョンです(以前は["Ubernetes"](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/multicluster/federation.md)の愛称で言及されていました)。 完全なCluster Federationでは、異なるリージョンやクラウドプロバイダー(あるいはオンプレミスデータセンター)内の独立したKubernetesクラスターをまとめることが可能になります。しかしながら、多くのユーザーは単に1つのクラウドプロバイダーの複数のゾーンでより可用性の高いKubernetesクラスターを運用したいと考えており、バージョン1.2におけるマルチゾーンサポート(以前は"Ubernetes Lite"の愛称で使用されていました)ではこれが可能になります。 From 28a3b3028d5e3dfa6d7ff48040b2d3f2e9c37b2e Mon Sep 17 00:00:00 2001 From: inductor Date: Sat, 19 Sep 2020 12:25:35 +0900 Subject: [PATCH 170/252] delete unnecessary file --- "content/ja/docs/concepts/overview/\\" | 121 ------------------------- 1 file changed, 121 deletions(-) delete mode 100644 "content/ja/docs/concepts/overview/\\" diff --git "a/content/ja/docs/concepts/overview/\\" "b/content/ja/docs/concepts/overview/\\" deleted file mode 100644 index dbea76db1d..0000000000 --- "a/content/ja/docs/concepts/overview/\\" +++ /dev/null @@ -1,121 +0,0 @@ ---- -title: Kubernetesのコンポーネント -content_type: concept -description: > - Kubernetesクラスターはコントロールプレーンやノードと呼ばれるマシン群といったコンポーネントからなります。 -weight: 20 -card: - name: concepts - weight: 20 ---- - - -Kubernetesをデプロイすると、クラスターが展開されます。 -{{< glossary_definition term_id="cluster" length="all" prepend="Kubernetesクラスターは、">}} - -このドキュメントでは、Kubernetesクラスターが機能するために必要となるさまざまなコンポーネントの概要を説明します。 - -すべてのコンポーネントが結び付けられたKubernetesクラスターの図を次に示します。 - -![Kubernetesのコンポーネント](/images/docs/components-of-kubernetes.png) - - - - - -## コントロールプレーンコンポーネント - -コントロールプレーンコンポーネントは、クラスターに関する全体的な決定(スケジューリングなど)を行います。また、クラスターイベントの検出および応答を行います(たとえば、deploymentの`replicas`フィールドが満たされていない場合に、新しい {{< glossary_tooltip text="Pod" term_id="pod">}} を起動する等)。 - -コントロールプレーンコンポーネントはクラスター内のどのマシンでも実行できますが、シンプルにするため、セットアップスクリプトは通常、すべてのコントロールプレーンコンポーネントを同じマシンで起動し、そのマシンではユーザーコンテナを実行しません。 -マルチマスター VMセットアップの例については、[高可用性クラスターの構築](/docs/admin/high-availability/) を参照してください。 - -### kube-apiserver - -{{< glossary_definition term_id="kube-apiserver" length="all" >}} - -### etcd - -{{< glossary_definition term_id="etcd" length="all" >}} - -### kube-scheduler - -{{< glossary_definition term_id="kube-scheduler" length="all" >}} - -### kube-controller-manager - -{{< glossary_definition term_id="kube-controller-manager" length="all" >}} - -コントローラーには以下が含まれます。 - - * ノードコントローラー：ノードがダウンした場合の通知と対応を担当します。 - * レプリケーションコントローラー：システム内の全レプリケーションコントローラーオブジェクトについて、Podの数を正しく保つ役割を持ちます。 - * エンドポイントコントローラー：エンドポイントオブジェクトを注入します(つまり、ServiceとPodを紐付けます)。 - * サービスアカウントとトークンコントローラー：新規の名前空間に対して、デフォルトアカウントとAPIアクセストークンを作成します。 - -### cloud-controller-manager - -{{< glossary_definition term_id="cloud-controller-manager" length="short" >}} - -cloud-controller-managerは、クラウドプロバイダー固有のコントローラーのみを実行します。 -KubernetesをオンプレミスあるいはPC内での学習環境で動かす際には、クラスターにcloud container managerはありません。 - -kube-controller-managerを使用すると、cloud-controller-managerは複数の論理的に独立したコントロールループをシングルバイナリにまとめ、これが一つのプロセスとして動作します。パフォーマンスを向上させるあるいは障害に耐えるために水平方向にスケールする(一つ以上のコピーを動かす)ことができます。 - -次のコントローラーには、クラウドプロバイダーへの依存関係を持つ可能性があります。 - - * ノードコントローラー：ノードが応答を停止した後、クラウドで削除されたかどうかを判断するため、クラウドプロバイダーをチェックします。 - * ルーティングコントローラー：基盤であるクラウドインフラでルーティングを設定します。 - * サービスコントローラー：クラウドプロバイダーのロードバランサーの作成、更新、削除を行います。 -## ノードコンポーネント {#node-components} - -ノードコンポーネントはすべてのノードで実行され、稼働中のPodの管理やKubernetesの実行環境を提供します。 - -### kubelet - -{{< glossary_definition term_id="kubelet" length="all" >}} - -### kube-proxy - -{{< glossary_definition term_id="kube-proxy" length="all" >}} - -### コンテナランタイム {#container-runtime} - -{{< glossary_definition term_id="container-runtime" length="all" >}} - -## アドオン - -アドオンはクラスター機能を実装するためにKubernetesリソース({{< glossary_tooltip term_id="daemonset" >}}、{{< glossary_tooltip term_id="deployment" >}}など)を使用します。 -アドオンはクラスターレベルの機能を提供しているため、アドオンのリソースで名前空間が必要なものは`kube-system`名前空間に属します。 - -いくつかのアドオンについて以下で説明します。より多くの利用可能なアドオンのリストは、[アドオン](/docs/concepts/cluster-administration/addons/) をご覧ください。 - -### DNS - -クラスターDNS以外のアドオンは必須ではありませんが、すべてのKubernetesクラスターは[クラスターDNS](/ja/docs/concepts/services-networking/dns-pod-service/)を持つべきです。多くの使用例がクラスターDNSを前提としています。 - -クラスターDNSは、環境内の他のDNSサーバーに加えて、KubernetesサービスのDNSレコードを提供するDNSサーバーです。 - -Kubernetesによって開始されたコンテナは、DNS検索にこのDNSサーバーを自動的に含めます。 - - -### Web UI (ダッシュボード) - -[ダッシュボード](/ja/docs/tasks/access-application-cluster/web-ui-dashboard/)は、Kubernetesクラスター用の汎用WebベースUIです。これによりユーザーはクラスターおよびクラスター内で実行されているアプリケーションについて、管理およびトラブルシューティングを行うことができます。 - -### コンテナリソース監視 - -[コンテナリソース監視](/docs/tasks/debug-application-cluster/resource-usage-monitoring/)は、コンテナに関する一般的な時系列メトリックを中央データベースに記録します。また、そのデータを閲覧するためのUIを提供します。 - -### クラスターレベルログ - -[クラスターレベルログ](/docs/concepts/cluster-administration/logging/)メカニズムは、コンテナのログを、検索／参照インターフェイスを備えた中央ログストアに保存します。 - - -## {{% heading "whatsnext" %}} - -* [ノード](/ja/docs/concepts/architecture/nodes/)について学ぶ -* [コントローラー](/docs/concepts/architecture/controller/)について学ぶ -* [kube-scheduler](/ja/docs/concepts/scheduling-eviction/kube-scheduler/)について学ぶ -* etcdの公式 [ドキュメント](https://etcd.io/docs/)を読む - From 352a93c79767c4b01547ebface31c00184fdefa8 Mon Sep 17 00:00:00 2001 From: Akito Kobayashi Date: Tue, 8 Sep 2020 00:49:45 +0900 Subject: [PATCH 171/252] Make docs/concepts/workloads/controllers/statefulset.md follow v1.18 of the original text --- .../concepts/workloads/controllers/statefulset.md | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/workloads/controllers/statefulset.md b/content/ja/docs/concepts/workloads/controllers/statefulset.md index a3b0aae707..f5625f023f 100644 --- a/content/ja/docs/concepts/workloads/controllers/statefulset.md +++ b/content/ja/docs/concepts/workloads/controllers/statefulset.md @@ -2,7 +2,7 @@ reviewers: title: StatefulSet content_type: concept -weight: 40 +weight: 30 --- @@ -117,6 +117,15 @@ StatefulSetは、Podのドメインをコントロールするために[Headless このHeadless Serviceによって管理されたドメインは`$(Service名).$(ネームスペース).svc.cluster.local`形式となり、"cluster.local"というのはそのクラスターのドメインとなります。 各Podが作成されると、Podは`$(Pod名).$(管理するServiceドメイン名)`に一致するDNSサブドメインを取得し、管理するServiceはStatefulSetの`serviceName`で定義されます。 +クラスタでのDNSの設定方法によっては、新たに起動されたPodのDNS名をすぐに検索できない場合があります。 +この動作は、クラスター内の他のクライアントが、Podが作成される前にそのPodのホスト名に対するクエリをすでに送信していた場合に発生する可能性があります。 +(DNSでは通常)ネガティブキャッシュは、Podの起動後でも、少なくとも数秒間、以前に失敗したルックアップの結果が記憶され、再利用されることを意味します。 + +Podが作成された後、速やかにPodを検出する必要がある場合は、いくつかのオプションがあります。 + +- DNSルックアップに依存するのではなく、Kubernetes APIに直接(例えばwatchを使って)問い合わせる。 +- Kubernetes DNS プロバイダのキャッシュ時間を短縮する(これは現在30秒キャッシュされるようになっているCoreDNSのConfigMapを編集することを意味しています。)。 + [制限事項](#制限事項)セクションで言及したように、ユーザーはPodのネットワークアイデンティティーのために[Headless Service](/ja/docs/concepts/services-networking/service/#headless-service)を作成する責任があります。 ここで、クラスタードメイン、Service名、StatefulSet名の選択と、それらがStatefulSetのPodのDNS名にどう影響するかの例をあげます。 @@ -150,7 +159,7 @@ StatefulSet {{< glossary_tooltip text="コントローラー" term_id="controlle StatefulSetは`pod.Spec.TerminationGracePeriodSeconds`を0に指定すべきではありません。これは不安全で、やらないことを強く推奨します。さらなる説明としては、[StatefulSetのPodの強制削除](/ja/docs/tasks/run-application/force-delete-stateful-set-pod/)を参照してください。 -上記の例のnginxが作成されたとき、3つのPodは`web-0`、`web-1`、`web-2`の順番でデプロイされます。`web-1`は`web-0`が[RunningかつReady状態](/docs/user-guide/pod-states/)になるまでは決してデプロイされないのと、同様に`web-2`は`web-1`がRunningかつReady状態にならないとデプロイされません。もし`web-0`が`web-1`がRunningかつReady状態になった後だが、`web-2`が起動する前に失敗した場合、`web-2`は`web-0`の再起動が成功し、RunningかつReady状態にならないと再起動されません。 +上記の例のnginxが作成されたとき、3つのPodは`web-0`、`web-1`、`web-2`の順番でデプロイされます。`web-1`は`web-0`が[RunningかつReady状態](/docs/concepts/workloads/pods/pod-lifecycle/)になるまでは決してデプロイされないのと、同様に`web-2`は`web-1`がRunningかつReady状態にならないとデプロイされません。もし`web-0`が`web-1`がRunningかつReady状態になった後だが、`web-2`が起動する前に失敗した場合、`web-2`は`web-0`の再起動が成功し、RunningかつReady状態にならないと再起動されません。 もしユーザーが`replicas=1`といったようにStatefulSetにパッチをあてることにより、デプロイされたものをスケールすることになった場合、`web-2`は最初に停止されます。`web-1`は`web-2`が完全にシャットダウンされ削除されるまでは、停止されません。もし`web-0`が、`web-2`が完全に停止され削除された後だが、`web-1`の停止の前に失敗した場合、`web-1`は`web-0`がRunningかつReady状態になるまでは停止されません。 From f942cd3e9a43cd01001c53713f65871bb245727d Mon Sep 17 00:00:00 2001 From: akitok Date: Fri, 18 Sep 2020 14:15:30 +0900 Subject: [PATCH 172/252] Update content/ja/docs/concepts/workloads/controllers/statefulset.md Co-authored-by: nasa9084 --- content/ja/docs/concepts/workloads/controllers/statefulset.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/workloads/controllers/statefulset.md b/content/ja/docs/concepts/workloads/controllers/statefulset.md index f5625f023f..5aea1ed9b9 100644 --- a/content/ja/docs/concepts/workloads/controllers/statefulset.md +++ b/content/ja/docs/concepts/workloads/controllers/statefulset.md @@ -117,7 +117,7 @@ StatefulSetは、Podのドメインをコントロールするために[Headless このHeadless Serviceによって管理されたドメインは`$(Service名).$(ネームスペース).svc.cluster.local`形式となり、"cluster.local"というのはそのクラスターのドメインとなります。 各Podが作成されると、Podは`$(Pod名).$(管理するServiceドメイン名)`に一致するDNSサブドメインを取得し、管理するServiceはStatefulSetの`serviceName`で定義されます。 -クラスタでのDNSの設定方法によっては、新たに起動されたPodのDNS名をすぐに検索できない場合があります。 +クラスターでのDNSの設定方法によっては、新たに起動されたPodのDNS名をすぐに検索できない場合があります。 この動作は、クラスター内の他のクライアントが、Podが作成される前にそのPodのホスト名に対するクエリをすでに送信していた場合に発生する可能性があります。 (DNSでは通常)ネガティブキャッシュは、Podの起動後でも、少なくとも数秒間、以前に失敗したルックアップの結果が記憶され、再利用されることを意味します。 @@ -208,4 +208,3 @@ Kubernetes1.7とそれ以降のバージョンにおいて、StatefulSetの`.spe * [ステートフルなアプリケーションのデプロイ](/docs/tutorials/stateful-application/basic-stateful-set/)の例を参考にしてください。 * [StatefulSetを使ったCassandraのデプロイ](/docs/tutorials/stateful-application/cassandra/)の例を参考にしてください。 * [レプリカを持つステートフルアプリケーションを実行する](/ja/docs/tasks/run-application/run-replicated-stateful-application/)の例を参考にしてください。 - From 618080d5d9f8c58c84bd3a8495375c22cecb56ad Mon Sep 17 00:00:00 2001 From: akitok Date: Fri, 18 Sep 2020 14:15:46 +0900 Subject: [PATCH 173/252] Update content/ja/docs/concepts/workloads/controllers/statefulset.md Co-authored-by: nasa9084 --- content/ja/docs/concepts/workloads/controllers/statefulset.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/workloads/controllers/statefulset.md b/content/ja/docs/concepts/workloads/controllers/statefulset.md index 5aea1ed9b9..94096b0144 100644 --- a/content/ja/docs/concepts/workloads/controllers/statefulset.md +++ b/content/ja/docs/concepts/workloads/controllers/statefulset.md @@ -118,7 +118,7 @@ StatefulSetは、Podのドメインをコントロールするために[Headless 各Podが作成されると、Podは`$(Pod名).$(管理するServiceドメイン名)`に一致するDNSサブドメインを取得し、管理するServiceはStatefulSetの`serviceName`で定義されます。 クラスターでのDNSの設定方法によっては、新たに起動されたPodのDNS名をすぐに検索できない場合があります。 -この動作は、クラスター内の他のクライアントが、Podが作成される前にそのPodのホスト名に対するクエリをすでに送信していた場合に発生する可能性があります。 +この動作は、クラスター内の他のクライアントが、Podが作成される前にそのPodのホスト名に対するクエリーをすでに送信していた場合に発生する可能性があります。 (DNSでは通常)ネガティブキャッシュは、Podの起動後でも、少なくとも数秒間、以前に失敗したルックアップの結果が記憶され、再利用されることを意味します。 Podが作成された後、速やかにPodを検出する必要がある場合は、いくつかのオプションがあります。 From 8da1f7fc97bd8524ffa3a9c9de415d46302b4ecc Mon Sep 17 00:00:00 2001 From: akitok Date: Fri, 18 Sep 2020 14:16:01 +0900 Subject: [PATCH 174/252] Update content/ja/docs/concepts/workloads/controllers/statefulset.md Co-authored-by: nasa9084 --- content/ja/docs/concepts/workloads/controllers/statefulset.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/workloads/controllers/statefulset.md b/content/ja/docs/concepts/workloads/controllers/statefulset.md index 94096b0144..08d11dbf50 100644 --- a/content/ja/docs/concepts/workloads/controllers/statefulset.md +++ b/content/ja/docs/concepts/workloads/controllers/statefulset.md @@ -124,7 +124,7 @@ StatefulSetは、Podのドメインをコントロールするために[Headless Podが作成された後、速やかにPodを検出する必要がある場合は、いくつかのオプションがあります。 - DNSルックアップに依存するのではなく、Kubernetes APIに直接(例えばwatchを使って)問い合わせる。 -- Kubernetes DNS プロバイダのキャッシュ時間を短縮する(これは現在30秒キャッシュされるようになっているCoreDNSのConfigMapを編集することを意味しています。)。 +- Kubernetes DNS プロバイダーのキャッシュ時間を短縮する(これは現在30秒キャッシュされるようになっているCoreDNSのConfigMapを編集することを意味しています。)。 [制限事項](#制限事項)セクションで言及したように、ユーザーはPodのネットワークアイデンティティーのために[Headless Service](/ja/docs/concepts/services-networking/service/#headless-service)を作成する責任があります。 From 9a91829a867d0cfdf3f210a15d088351ff22ae3f Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Fri, 4 Sep 2020 12:33:39 +0900 Subject: [PATCH 175/252] Update ja/docs/tutorials/hello-minikube.md --- content/ja/docs/tutorials/hello-minikube.md | 20 ++++++++++++-------- 1 file changed, 12 insertions(+), 8 deletions(-) diff --git a/content/ja/docs/tutorials/hello-minikube.md b/content/ja/docs/tutorials/hello-minikube.md index 98a9286503..08d6a169b3 100644 --- a/content/ja/docs/tutorials/hello-minikube.md +++ b/content/ja/docs/tutorials/hello-minikube.md @@ -7,7 +7,7 @@ menu: title: "Get Started" weight: 10 post: > -

手を動かす準備はできていますか？本チュートリアルでは、Node.jsを使った簡単な"Hello World"を実行するKubernetesクラスタをビルドします。

+

手を動かす準備はできていますか？本チュートリアルでは、サンプルアプリケーションを実行するKubernetesクラスタをビルドします。

card: name: tutorials weight: 10 @@ -15,7 +15,7 @@ card: -このチュートリアルでは、[Minikube](/ja/docs/setup/learning-environment/minikube)とKatacodaを使用して、Kubernetes上でシンプルなHello WorldのNode.jsアプリケーションを動かす方法を紹介します。Katacodaはブラウザで無償のKubernetes環境を提供します。 +このチュートリアルでは、[Minikube](/ja/docs/setup/learning-environment/minikube)とKatacodaを使用して、Kubernetes上でサンプルアプリケーションを動かす方法を紹介します。Katacodaはブラウザで無償のKubernetes環境を提供します。 {{< note >}} [Minikubeをローカルにインストール](/ja/docs/tasks/tools/install-minikube/)している場合もこのチュートリアルを進めることが可能です。 @@ -26,7 +26,7 @@ card: ## {{% heading "objectives" %}} -* Minikubeへのhello worldアプリケーションのデプロイ +* Minikubeへのサンプルアプリケーションのデプロイ * アプリケーションの実行 * アプリケーションログの確認 @@ -35,7 +35,7 @@ card: ## {{% heading "prerequisites" %}} -このチュートリアルは下記のファイルからビルドされるコンテナーイメージを提供します: +このチュートリアルはNGINXを利用してすべての要求をエコーバックするコンテナーイメージを提供します。 {{< codenew language="js" file="minikube/server.js" >}} @@ -53,7 +53,9 @@ card: {{< kat-button >}} - {{< note >}}Minikubeをローカルにインストール済みの場合は、`minikube start`を実行してください。{{< /note >}} +{{< note >}} + Minikubeをローカルにインストール済みの場合は、`minikube start`を実行してください。 +{{< /note >}} 2. ブラウザーでKubernetesダッシュボードを開いてください: @@ -67,7 +69,7 @@ card: ## Deploymentの作成 -Kubernetesの[*Pod*](/ja/docs/concepts/workloads/pods/pod/) は、コンテナの管理やネットワーキングの目的でまとめられた、1つ以上のコンテナのグループです。このチュートリアルのPodがもつコンテナは1つのみです。Kubernetesの [*Deployment*](/ja/docs/concepts/workloads/controllers/deployment/) はPodの状態を確認し、Podのコンテナが停止した場合には再起動します。DeploymentはPodの作成やスケールを管理するために推奨される方法(手段)です。 +Kubernetesの[*Pod*](/ja/docs/concepts/workloads/pods/) は、コンテナの管理やネットワーキングの目的でまとめられた、1つ以上のコンテナのグループです。このチュートリアルのPodがもつコンテナは1つのみです。Kubernetesの [*Deployment*](/ja/docs/concepts/workloads/controllers/deployment/) はPodの状態を確認し、Podのコンテナが停止した場合には再起動します。DeploymentはPodの作成やスケールを管理するために推奨される方法(手段)です。 1. `kubectl create` コマンドを使用してPodを管理するDeploymentを作成してください。Podは提供されたDockerイメージを元にコンテナを実行します。 @@ -113,7 +115,9 @@ Kubernetesの[*Pod*](/ja/docs/concepts/workloads/pods/pod/) は、コンテナ kubectl config view ``` - {{< note >}} `kubectl`コマンドの詳細な情報は[kubectl overview](/docs/user-guide/kubectl-overview/)を参照してください。{{< /note >}} +{{< note >}} + `kubectl`コマンドの詳細な情報は[kubectl overview](/docs/user-guide/kubectl-overview/)を参照してください。 +{{< /note >}} ## Serviceの作成 @@ -154,7 +158,7 @@ Kubernetesの[*Pod*](/ja/docs/concepts/workloads/pods/pod/) は、コンテナ 5. Katacoda環境のみ：`8080`の反対側のService出力に、5桁のポート番号が表示されます。このポート番号はランダムに生成されるため、ここで使用するポート番号と異なる場合があります。ポート番号テキストボックスに番号を入力し、ポートの表示をクリックしてください。前の例の場合は、`30369`と入力します。 - "Hello World"メッセージが表示されるアプリケーションのブラウザウィンドウが開きます。 + アプリケーションとその応答が表示されるブラウザウィンドウが開きます。 ## アドオンの有効化 From 8ca15fb3e75f868095b960334731f473e370f925 Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Fri, 4 Sep 2020 12:38:52 +0900 Subject: [PATCH 176/252] Update ja/docs/tutorials/hello-minikube.md --- content/ja/docs/tutorials/hello-minikube.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tutorials/hello-minikube.md b/content/ja/docs/tutorials/hello-minikube.md index 08d6a169b3..0802fda7ed 100644 --- a/content/ja/docs/tutorials/hello-minikube.md +++ b/content/ja/docs/tutorials/hello-minikube.md @@ -116,7 +116,7 @@ Kubernetesの[*Pod*](/ja/docs/concepts/workloads/pods/) は、コンテナの管 ``` {{< note >}} - `kubectl`コマンドの詳細な情報は[kubectl overview](/docs/user-guide/kubectl-overview/)を参照してください。 +`kubectl`コマンドの詳細な情報は[kubectl overview](/docs/user-guide/kubectl-overview/)を参照してください。 {{< /note >}} ## Serviceの作成 From fa4854c55e903034620bca4f3a186adbc930c548 Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Mon, 7 Sep 2020 12:21:35 +0900 Subject: [PATCH 177/252] Update ja/docs/tutorials/hello-minikube.md --- content/ja/docs/tutorials/hello-minikube.md | 18 +++++++----------- 1 file changed, 7 insertions(+), 11 deletions(-) diff --git a/content/ja/docs/tutorials/hello-minikube.md b/content/ja/docs/tutorials/hello-minikube.md index 0802fda7ed..311967974f 100644 --- a/content/ja/docs/tutorials/hello-minikube.md +++ b/content/ja/docs/tutorials/hello-minikube.md @@ -7,7 +7,7 @@ menu: title: "Get Started" weight: 10 post: > -

手を動かす準備はできていますか？本チュートリアルでは、サンプルアプリケーションを実行するKubernetesクラスタをビルドします。

+

手を動かす準備はできていますか？本チュートリアルでは、サンプルアプリケーションを実行するKubernetesクラスターをビルドします。

card: name: tutorials weight: 10 @@ -37,17 +37,13 @@ card: このチュートリアルはNGINXを利用してすべての要求をエコーバックするコンテナーイメージを提供します。 -{{< codenew language="js" file="minikube/server.js" >}} -{{< codenew language="conf" file="minikube/Dockerfile" >}} - -`docker build`コマンドについての詳細な情報は、[Dockerのドキュメント](https://docs.docker.com/engine/reference/commandline/build/)を参照してください。 -## Minikubeクラスタの作成 +## Minikubeクラスターの作成 1. **Launch Terminal** をクリックしてください @@ -103,7 +99,7 @@ Kubernetesの[*Pod*](/ja/docs/concepts/workloads/pods/) は、コンテナの管 hello-node-5f76cf6ccf-br9b5 1/1 Running 0 1m ``` -4. クラスタイベントを確認します: +4. クラスターイベントを確認します: ```shell kubectl get events @@ -116,12 +112,12 @@ Kubernetesの[*Pod*](/ja/docs/concepts/workloads/pods/) は、コンテナの管 ``` {{< note >}} -`kubectl`コマンドの詳細な情報は[kubectl overview](/docs/user-guide/kubectl-overview/)を参照してください。 +`kubectl`コマンドの詳細な情報は[kubectl overview](/ja/docs/reference/kubectl/overview/)を参照してください。 {{< /note >}} ## Serviceの作成 -通常、PodはKubernetesクラスタ内部のIPアドレスからのみアクセスすることができます。`hello-node`コンテナをKubernetesの仮想ネットワークの外部からアクセスするためには、Kubernetesの[*Service*](/ja/docs/concepts/services-networking/service/)としてPodを公開する必要があります。 +通常、PodはKubernetesクラスター内部のIPアドレスからのみアクセスすることができます。`hello-node`コンテナをKubernetesの仮想ネットワークの外部からアクセスするためには、Kubernetesの[*Service*](/ja/docs/concepts/services-networking/service/)としてPodを公開する必要があります。 1. `kubectl expose` コマンドを使用してPodをインターネットに公開します: @@ -129,7 +125,7 @@ Kubernetesの[*Pod*](/ja/docs/concepts/workloads/pods/) は、コンテナの管 kubectl expose deployment hello-node --type=LoadBalancer --port=8080 ``` - `--type=LoadBalancer`フラグはServiceをクラスタ外部に公開したいことを示しています。 + `--type=LoadBalancer`フラグはServiceをクラスター外部に公開したいことを示しています。 2. 作成したServiceを確認します: @@ -247,7 +243,7 @@ Minikubeはビルトインの{{< glossary_tooltip text="アドオン" term_id="a ## クリーンアップ -クラスタに作成したリソースをクリーンアップします: +クラスターに作成したリソースをクリーンアップします: ```shell kubectl delete service hello-node From b403d06cc8f6eec2924ee38366b96b332deb3fb4 Mon Sep 17 00:00:00 2001 From: yu-kasuya Date: Mon, 7 Sep 2020 13:28:54 +0900 Subject: [PATCH 178/252] Apply suggestions from code review Co-authored-by: Naoki Oketani --- content/ja/docs/tutorials/hello-minikube.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/ja/docs/tutorials/hello-minikube.md b/content/ja/docs/tutorials/hello-minikube.md index 311967974f..f8b5864f7a 100644 --- a/content/ja/docs/tutorials/hello-minikube.md +++ b/content/ja/docs/tutorials/hello-minikube.md @@ -35,7 +35,7 @@ card: ## {{% heading "prerequisites" %}} -このチュートリアルはNGINXを利用してすべての要求をエコーバックするコンテナーイメージを提供します。 +このチュートリアルはNGINXを利用してすべての要求をエコーバックするコンテナイメージを提供します。 @@ -271,4 +271,3 @@ minikube delete * [アプリケーションのデプロイ](/ja/docs/tasks/run-application/run-stateless-application-deployment/)について学ぶ. * [Serviceオブジェクト](/ja/docs/concepts/services-networking/service/)について学ぶ. - From 83558be8ad79e81300358120ea4a87b4adc83cca Mon Sep 17 00:00:00 2001 From: yu-kasuya Date: Tue, 15 Sep 2020 12:09:56 +0900 Subject: [PATCH 179/252] Apply suggestions from code review Co-authored-by: nasa9084 --- content/ja/docs/tutorials/hello-minikube.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/ja/docs/tutorials/hello-minikube.md b/content/ja/docs/tutorials/hello-minikube.md index f8b5864f7a..530e53ffd5 100644 --- a/content/ja/docs/tutorials/hello-minikube.md +++ b/content/ja/docs/tutorials/hello-minikube.md @@ -154,7 +154,7 @@ Kubernetesの[*Pod*](/ja/docs/concepts/workloads/pods/) は、コンテナの管 5. Katacoda環境のみ：`8080`の反対側のService出力に、5桁のポート番号が表示されます。このポート番号はランダムに生成されるため、ここで使用するポート番号と異なる場合があります。ポート番号テキストボックスに番号を入力し、ポートの表示をクリックしてください。前の例の場合は、`30369`と入力します。 - アプリケーションとその応答が表示されるブラウザウィンドウが開きます。 + アプリケーションとその応答が表示されるブラウザーウィンドウが開きます。 ## アドオンの有効化 @@ -270,4 +270,3 @@ minikube delete * [Deploymentオブジェクト](/ja/docs/concepts/workloads/controllers/deployment/)について学ぶ. * [アプリケーションのデプロイ](/ja/docs/tasks/run-application/run-stateless-application-deployment/)について学ぶ. * [Serviceオブジェクト](/ja/docs/concepts/services-networking/service/)について学ぶ. - From 3256091cdd05117cdf5c003663ed76b9b3a127af Mon Sep 17 00:00:00 2001 From: Soichiro KAWAMURA Date: Tue, 22 Sep 2020 21:52:51 +0900 Subject: [PATCH 180/252] follow 1.18 ingress.md --- .../concepts/services-networking/ingress.md | 76 ++++++++++++++++--- 1 file changed, 66 insertions(+), 10 deletions(-) diff --git a/content/ja/docs/concepts/services-networking/ingress.md b/content/ja/docs/concepts/services-networking/ingress.md index a2e39554c9..76bb234f7e 100644 --- a/content/ja/docs/concepts/services-networking/ingress.md +++ b/content/ja/docs/concepts/services-networking/ingress.md @@ -65,6 +65,7 @@ spec: - http: paths: - path: /testpath + pathType: Prefix backend: serviceName: test servicePort: 80 @@ -72,7 +73,7 @@ spec: 他の全てのKubernetesリソースと同様に、Ingressには`apiVersion`、`kind`や`metadata`フィールドが必要です。Ingressオブジェクトの名前は、有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。設定ファイルに関する一般的な情報は、[アプリケーションのデプロイ](/ja/docs/tasks/run-application/run-stateless-application-deployment/)、[コンテナの設定](/docs/tasks/configure-pod-container/configure-pod-configmap/)、[リソースの管理](/docs/concepts/cluster-administration/manage-deployment/)を参照してください。Ingressでは、Ingressコントローラーに依存しているいくつかのオプションの設定をするためにアノテーションを一般的に使用します。例としては、[rewrite-targetアノテーション](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md)などがあります。[Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers)の種類が異なれば、サポートするアノテーションも異なります。サポートされているアノテーションについて学ぶためには、使用するIngressコントローラーのドキュメントを確認してください。 -Ingress [Spec](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)は、ロードバランサーやプロキシーサーバーを設定するために必要な全ての情報を持っています。最も重要なものとして、外部からくる全てのリクエストに対して一致したルールのリストを含みます。IngressリソースはHTTPトラフィックに対してのルールのみサポートしています。 +Ingress [Spec](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)は、ロードバランサーやプロキシーサーバーを設定するために必要な全ての情報を持っています。最も重要なものとして、外部からくる全てのリクエストに対して一致したルールのリストを含みます。IngressリソースはHTTP(S)トラフィックに対してのルールのみサポートしています。 ### Ingressのルール @@ -90,6 +91,61 @@ Ingressコントローラーでは、デフォルトのバックエンドが設 IngressオブジェクトでHTTPリクエストが1つもホスト名とパスの条件に一致しない時、そのトラフィックはデフォルトのバックエンドに転送されます。 +### パスのタイプ + +Ingressのそれぞれのパスは対応するパスのタイプを持ちます。サポートされているパスのタイプは3種類あります。 + +* _`ImplementationSpecific`_ (デフォルト): このパスタイプでは、パスとの一致はIngressClassに依存します。Ingressの実装はこれを独立した`pathType`と扱うことも、`Prefix`や`Exact`と同一のパスタイプと扱うこともできます。 + +* _`Exact`_: 大文字小文字を区別して完全に一致するURLパスと一致します。 + +* _`Prefix`_: `/`で分割されたURLと前方一致で一致します。大文字小文字は区別され、パスの要素対要素で比較されます。パス要素は`/`で分割されたパスの中のラベルのリストを参照します。リクエストがパス _p_ に一致するのは、Ingressのパス _p_ がリクエストパス _p_ と要素単位で前方一致する場合です。 + + {{< note >}} + パスの最後の要素がリクエストパスの最後の要素の部分文字列である場合、これは一致しません（例えば、`/foo/bar`は`/foo/bar/baz`と一致しますが、`/foo/barbaz`とは一致しません）。 + {{< /note >}} + +#### 複数のパスとの一致 + +リクエストがIngressの複数のパスと一致することがあります。そのような場合は、最も長くパスが一致したものが優先されます。2つのパスが同等に一致した場合は、完全一致が前方一致よりも優先されます。 + +## Ingress Class + +Ingressは異なったコントローラーで実装されうるため、しばしば異なった設定を必要とします。 +IngressClassリソースは、この種別のIngressを実装すべきコントローラーの名称を含む追加の設定情報を含みます。各IngressはIngressClassリソースへの参照によって種別を指定すべきです。 + +```yaml +apiVersion: networking.k8s.io/v1beta1 +kind: IngressClass +metadata: + name: external-lb +spec: + controller: example.com/ingress-controller + parameters: + apiGroup: k8s.example.com/v1alpha + kind: IngressParameters + name: external-lb +``` + +IngressClassリソースは任意のパラメータフィールドを含むことができます。これは追加の設定情報を参照するために利用することができます。 + +### 非推奨のアノテーション + +Kubernetes 1.18でIngressClassリソースと`ingressClassName`フィールドが追加される前は、Ingressの種別はIngressの`kubernetes.io/ingress.class`アノテーションにより指定されていました。 +このアノテーションは正式に定義されたことはありませんが、Ingressコントローラーに広くサポートされています。 + +Ingressの新しい`ingressClassName`フィールドはこのアノテーションを置き換えるものですが、完全に等価ではありません。 +アノテーションは一般にIngressを実装すべきIngressのコントローラーの名称を示していましたが、フィールドはIngressClassリソースを示しており、これはIngressのコントローラーの名称を含む追加のIngressの設定情報を持ちます。 + +### デフォルトのIngress Class + +特定のIngressClassをクラスターでのデフォルトとすることができます。 +IngressClassリソースの`ingressclass.kubernetes.io/is-default-class`アノテーションを`true`に設定すると、`ingressClassName`フィールドが指定されないIngressにはこのデフォルトIngressClassが割り当てられるようになります。 + +{{< caution >}} +複数のIngressClassをクラスターのデフォルトに設定すると、アドミッションコントローラーは`ingressClassName`が指定されていないIngressオブジェクトの作成を防ぐようになります。クラスターのデフォルトのIngressClassを1つ以下にすることで、これを解消することができます。 +{{< /caution >}} + ## Ingressのタイプ ### 単一ServiceのIngress @@ -268,16 +324,16 @@ metadata: spec: tls: - hosts: - - sslexample.foo.com + - sslexample.foo.com secretName: testsecret-tls rules: - - host: sslexample.foo.com - http: - paths: - - path: / - backend: - serviceName: service1 - servicePort: 80 + - host: sslexample.foo.com + http: + paths: + - path: / + backend: + serviceName: service1 + servicePort: 80 ``` {{< note >}} @@ -288,7 +344,7 @@ spec: Ingressコントローラーは、負荷分散アルゴリズムやバックエンドの重みスキームなど、すべてのIngressに適用されるいくつかの負荷分散ポリシーの設定とともにブートストラップされます。発展した負荷分散のコンセプト(例: セッションの永続化、動的重み付けなど)はIngressによってサポートされていません。代わりに、それらの機能はService用のロードバランサーを介して利用できます。 -Ingressによってヘルスチェックの機能が直接に公開されていない場合でも、Kubernetesにおいて、同等の機能を提供する[Readiness Probe](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/)のようなコンセプトが存在することは注目に値します。コントローラーがどのようにヘルスチェックを行うかについては、コントローラーのドキュメントを参照してください([nginx](https://git.k8s.io/ingress-nginx/README.md)、[GCE](https://git.k8s.io/ingress-gce/README.md#health-checks))。 +Ingressによってヘルスチェックの機能が直接に公開されていない場合でも、Kubernetesにおいて、同等の機能を提供する[Readiness Probe](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)のようなコンセプトが存在することは注目に値します。コントローラーがどのようにヘルスチェックを行うかについては、コントローラーのドキュメントを参照してください([nginx](https://git.k8s.io/ingress-nginx/README.md)、[GCE](https://git.k8s.io/ingress-gce/README.md#health-checks))。 ## Ingressの更新 From e749fe5cb20ab279cac32c6b2bc3ea690879a4e0 Mon Sep 17 00:00:00 2001 From: Soichiro KAWAMURA Date: Sun, 6 Sep 2020 21:34:42 +0900 Subject: [PATCH 181/252] install-kubectl.md (ja): follow v1.18 --- .../ja/docs/tasks/tools/install-kubectl.md | 154 +++++++++--------- 1 file changed, 81 insertions(+), 73 deletions(-) diff --git a/content/ja/docs/tasks/tools/install-kubectl.md b/content/ja/docs/tasks/tools/install-kubectl.md index e468404469..937d34e95d 100644 --- a/content/ja/docs/tasks/tools/install-kubectl.md +++ b/content/ja/docs/tasks/tools/install-kubectl.md @@ -9,7 +9,7 @@ card: --- -Kubernetesのコマンドラインツールである[kubectl](/docs/user-guide/kubectl/)を使用して、Kubernetesクラスターに対してコマンドを実行することができます。kubectlによってアプリケーションのデプロイや、クラスターのリソース管理および検査を行うことができます。kubectlの操作に関する完全なリストは、[Overview of kubectl](/docs/reference/kubectl/overview/)を参照してください。 +Kubernetesのコマンドラインツールである[kubectl](/ja/docs/reference/kubectl/overview/)を使用して、Kubernetesクラスターに対してコマンドを実行することができます。kubectlによってアプリケーションのデプロイや、クラスターのリソース管理、検査およびログの表示を行うことができます。kubectlの操作に関する完全なリストは、[kubectlの概要](/ja/docs/reference/kubectl/overview/)を参照してください。 ## {{% heading "prerequisites" %}} @@ -26,7 +26,7 @@ kubectlのバージョンは、クラスターのマイナーバージョンと 1. 次のコマンドにより、最新リリースをダウンロードしてください: ``` - curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl + curl -LO "https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl" ``` 特定のバージョンをダウンロードする場合、コマンドの`$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)`の部分を特定のバージョンに書き換えてください。 @@ -59,7 +59,7 @@ kubectlのバージョンは、クラスターのマイナーバージョンと {{< tabs name="kubectl_install" >}} {{< tab name="Ubuntu、DebianまたはHypriotOS" codelang="bash" >}} -sudo apt-get update && sudo apt-get install -y apt-transport-https +sudo apt-get update && sudo apt-get install -y apt-transport-https gnupg2 curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add - echo "deb https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee -a /etc/apt/sources.list.d/kubernetes.list sudo apt-get update @@ -88,7 +88,7 @@ Ubuntuまたは[snap](https://snapcraft.io/docs/core/install)パッケージマ ```shell snap install kubectl --classic -kubectl version +kubectl version --client ``` {{% /tab %}} {{% tab name="Homebrew" %}} @@ -96,7 +96,7 @@ Linuxで[Homebrew](https://docs.brew.sh/Homebrew-on-Linux)パッケージマネ ```shell brew install kubectl -kubectl version +kubectl version --client ``` {{% /tab %}} {{< /tabs >}} @@ -107,7 +107,7 @@ kubectl version 1. 最新リリースをダウンロードしてください: - ``` + ```bash curl -LO "https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/darwin/amd64/kubectl" ``` @@ -115,24 +115,24 @@ kubectl version たとえば、macOSへ{{< param "fullversion" >}}のバージョンをダウンロードするには、次のコマンドを入力します: - ``` + ```bash curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/darwin/amd64/kubectl ``` 2. kubectlバイナリを実行可能にしてください。 - ``` + ```bash chmod +x ./kubectl ``` 3. バイナリをPATHの中に移動させてください。 - ``` + ```bash sudo mv ./kubectl /usr/local/bin/kubectl ``` 4. インストールしたバージョンが最新であることを確認してください: - ``` + ```bash kubectl version --client ``` @@ -142,18 +142,18 @@ macOSで[Homebrew](https://brew.sh/)パッケージマネージャーを使用 1. インストールコマンドを実行してください: - ``` + ```bash brew install kubectl ``` または - ``` + ```bash brew install kubernetes-cli ``` 2. インストールしたバージョンが最新であることを確認してください: - ``` + ```bash kubectl version --client ``` @@ -163,14 +163,14 @@ macOSで[MacPorts](https://macports.org/)パッケージマネージャーを使 1. インストールコマンドを実行してください: - ``` + ```bash sudo port selfupdate sudo port install kubectl ``` 2. インストールしたバージョンが最新であることを確認してください: - ``` + ```bash kubectl version --client ``` @@ -182,7 +182,7 @@ macOSで[MacPorts](https://macports.org/)パッケージマネージャーを使 または、`curl`をインストールされていれば、次のコマンドも使用できます: - ``` + ```bash curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe ``` @@ -191,7 +191,7 @@ macOSで[MacPorts](https://macports.org/)パッケージマネージャーを使 2. バイナリをPATHに追加します 3. `kubectl`のバージョンがダウンロードしたものと同じであることを確認してください: - ``` + ```bash kubectl version --client ``` {{< note >}} @@ -204,68 +204,76 @@ Windowsで[Powershell Gallery](https://www.powershellgallery.com/)パッケー 1. インストールコマンドを実行してください(必ず`DownloadLocation`を指定してください): - ``` - Install-Script -Name install-kubectl -Scope CurrentUser -Force + ```powershell + Install-Script -Name 'install-kubectl' -Scope CurrentUser -Force install-kubectl.ps1 [-DownloadLocation ] ``` - {{< note >}}`DownloadLocation`を指定しない場合、`kubectl`はユーザのTempディレクトリにインストールされます。{{< /note >}} + {{< note >}} + `DownloadLocation`を指定しない場合、`kubectl`はユーザのTempディレクトリにインストールされます。 + {{< /note >}} インストーラーは`$HOME/.kube`を作成し、設定ファイルを作成します。 2. インストールしたバージョンが最新であることを確認してください: - ``` + ```powershell kubectl version --client ``` - {{< note >}}アップデートする際は、手順1に示した2つのコマンドを再実行してください。{{< /note >}} + {{< note >}} + アップデートする際は、手順1に示した2つのコマンドを再実行してください。 + {{< /note >}} ### ChocolateyまたはScoopを使用してWindowsへインストールする -Windowsへkubectlをインストールするために、[Chocolatey](https://chocolatey.org)パッケージマネージャーや[Scoop](https://scoop.sh)コマンドラインインストーラーを使用することもできます。 -{{< tabs name="kubectl_win_install" >}} -{{% tab name="choco" %}} +1. Windowsへkubectlをインストールするために、[Chocolatey](https://chocolatey.org)パッケージマネージャーや[Scoop](https://scoop.sh)コマンドラインインストーラーを使用することもできます。 + {{< tabs name="kubectl_win_install" >}} + {{% tab name="choco" %}} + ```powershell choco install kubernetes-cli - -{{% /tab %}} -{{% tab name="scoop" %}} - + ``` + {{% /tab %}} + {{% tab name="scoop" %}} + ```powershell scoop install kubectl - -{{% /tab %}} -{{< /tabs >}} + ``` + {{% /tab %}} + {{< /tabs >}} 2. インストールしたバージョンが最新であることを確認してください: - ``` + ```powershell kubectl version --client ``` 3. ホームディレクトリへ移動してください: - ``` - cd %USERPROFILE% + ```powershell + # cmd.exeを使用している場合は cd %USERPROFILE% を実行してください。 + cd ~ ``` 4. `.kube`ディレクトリを作成してください: - ``` + ```powershell mkdir .kube ``` 5. 作成した`.kube`ディレクトリへ移動してください: - ``` + ```powershell cd .kube ``` 6. リモートのKubernetesクラスターを使うために、kubectlを設定してください: - ``` + ```powershell New-Item config -type file ``` - {{< note >}}Notepadなどの選択したテキストエディターから設定ファイルを編集してください。{{< /note >}} +{{< note >}} +Notepadなどの選択したテキストエディターから設定ファイルを編集してください。 +{{< /note >}} ## Google Cloud SDKの一部としてダウンロードする @@ -274,19 +282,19 @@ Google Cloud SDKの一部として、kubectlをインストールすることも 1. [Google Cloud SDK](https://cloud.google.com/sdk/)をインストールしてください。 2. `kubectl`のインストールコマンドを実行してください: - ``` + ```shell gcloud components install kubectl ``` 3. インストールしたバージョンが最新であることを確認してください: - ``` + ```shell kubectl version --client ``` ## kubectlの設定を検証する -kubectlがKubernetesクラスターを探索し接続するために、[kubeconfigファイル](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)が必要になります。これは、[kube-up.sh](https://github.com/kubernetes/kubernetes/blob/master/cluster/kube-up.sh)によりクラスターを作成した際や、Minikubeクラスターを正常にデプロイした際に自動生成されます。デフォルトでは、kubectlの設定は`~/.kube/config`に格納されています。 +kubectlがKubernetesクラスターを探索し接続するために、[kubeconfigファイル](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)が必要になります。これは、[kube-up.sh](https://github.com/kubernetes/kubernetes/blob/master/cluster/kube-up.sh)によりクラスターを作成した際や、Minikubeクラスターを正常にデプロイした際に自動生成されます。デフォルトでは、kubectlの設定は`~/.kube/config`に格納されています。 クラスターの状態を取得し、kubectlが適切に設定されていることを確認してください: @@ -297,7 +305,7 @@ URLのレスポンスが表示されている場合は、kubectlはクラスタ 以下のようなメッセージが表示されている場合は、kubectlは正しく設定されていないか、Kubernetesクラスターに接続できていません。 -```shell +``` The connection to the server was refused - did you specify the right host or port? ``` @@ -335,7 +343,7 @@ bash-completionは多くのパッケージマネージャーから提供され これを調べるには、シェルをリロードしてから`type _init_completion`を実行してください。コマンドが成功していればすでに設定済みです。そうでなければ、`~/.bashrc`に以下を追記してください: -```shell +```bash source /usr/share/bash-completion/bash_completion ``` @@ -347,21 +355,21 @@ source /usr/share/bash-completion/bash_completion - 補完スクリプトを`~/.bashrc`内でsourceしてください: - ```shell + ```bash echo 'source <(kubectl completion bash)' >>~/.bashrc ``` - 補完スクリプトを`/etc/bash_completion.d`ディレクトリに追加してください: - ```shell + ```bash kubectl completion bash >/etc/bash_completion.d/kubectl ``` - kubectlにエイリアスを張っている場合は、以下のようにシェルの補完を拡張して使うことができます: - ```shell - echo 'alias k=kubectl' >>~/.bashrc - echo 'complete -F __start_kubectl k' >>~/.bashrc - ``` +```bash +echo 'alias k=kubectl' >>~/.bashrc +echo 'complete -F __start_kubectl k' >>~/.bashrc +``` {{< note >}} bash-completionは`/etc/bash_completion.d`内のすべての補完スクリプトをsourceします。 @@ -389,19 +397,19 @@ bash-completionにはv1とv2のバージョンがあり、v1はBash 3.2(macOSの ここではBash 4.1以降の使用を前提としています。Bashのバージョンは下記のコマンドで調べることができます。 -```shell +```bash echo $BASH_VERSION ``` バージョンが古い場合、Homebrewを使用してインストールもしくはアップグレードできます。 -```shell +```bash brew install bash ``` シェルをリロードし、希望するバージョンを使用していることを確認してください。 -```shell +```bash echo $BASH_VERSION $SHELL ``` @@ -415,13 +423,13 @@ Homebrewは通常、`/usr/local/bin/bash`にインストールします。 `type _init_completion`を実行することで、bash-completionがすでにインストールされていることを確認できます。ない場合は、Homebrewを使用してインストールすることもできます: -```shell +```bash brew install bash-completion@2 ``` -このコマンドの出力で示されたように、`~/.bashrc`に以下を追記してください: +このコマンドの出力で示されたように、`~/.bash_profile`に以下を追記してください: -```shell +```bash export BASH_COMPLETION_COMPAT_DIR="/usr/local/etc/bash_completion.d" [[ -r "/usr/local/etc/profile.d/bash_completion.sh" ]] && . "/usr/local/etc/profile.d/bash_completion.sh" ``` @@ -433,30 +441,30 @@ export BASH_COMPLETION_COMPAT_DIR="/usr/local/etc/bash_completion.d" すべてのシェルセッションにてkubectlの補完スクリプトをsourceできるようにしなければなりません。これを行うには複数の方法があります: -- 補完スクリプトを`~/.bashrc`内でsourceする: +- 補完スクリプトを`~/.bash_profile`内でsourceする: - ```shell - echo 'source <(kubectl completion bash)' >>~/.bashrc + ```bash + echo 'source <(kubectl completion bash)' >>~/.bash_profile ``` - 補完スクリプトを`/usr/local/etc/bash_completion.d`ディレクトリに追加する: - ```shell + ```bash kubectl completion bash >/usr/local/etc/bash_completion.d/kubectl ``` - kubectlにエイリアスを張っている場合は、以下のようにシェルの補完を拡張して使うことができます: - ```shell - echo 'alias k=kubectl' >>~/.bashrc - echo 'complete -F __start_kubectl k' >>~/.bashrc + ```bash + echo 'alias k=kubectl' >>~/.bash_profile + echo 'complete -F __start_kubectl k' >>~/.bash_profile ``` - kubectlをHomwbrewでインストールした場合([前述](#homebrewを使用してmacosへインストールする)のとおり)、kubectlの補完スクリプトはすでに`/usr/local/etc/bash_completion.d/kubectl`に格納されているでしょう。この場合、なにも操作する必要はありません。 -{{< note >}} -Homebrewでインストールしたbash-completion v2は`BASH_COMPLETION_COMPAT_DIR`ディレクトリ内のすべてのファイルをsourceするため、後者の2つの方法が機能します。 -{{< /note >}} + {{< note >}} + Homebrewでインストールしたbash-completion v2は`BASH_COMPLETION_COMPAT_DIR`ディレクトリ内のすべてのファイルをsourceするため、後者の2つの方法が機能します。 + {{< /note >}} どの場合でも、シェルをリロードしたあとに、kubectlの自動補完が機能するはずです。 {{% /tab %}} @@ -465,15 +473,15 @@ Homebrewでインストールしたbash-completion v2は`BASH_COMPLETION_COMPAT_ Zshにおけるkubectlの補完スクリプトは`kubectl completion zsh`コマンドで生成できます。シェル内で補完スクリプトをsourceすることでkubectlの自動補完が有効になります。 -すべてのシェルセッションで使用するには、`~/.bashrc`に以下を追記してください: +すべてのシェルセッションで使用するには、`~/.zshrc`に以下を追記してください: -```shell +```zsh source <(kubectl completion zsh) ``` kubectlにエイリアスを張っている場合は、以下のようにシェルの補完を拡張して使うことができます: -```shell +```zsh echo 'alias k=kubectl' >>~/.zshrc echo 'complete -F __start_kubectl k' >>~/.zshrc ``` @@ -482,7 +490,7 @@ echo 'complete -F __start_kubectl k' >>~/.zshrc `complete:13: command not found: compdef`のようなエラーが出力された場合は、以下を`~/.zshrc`の先頭に追記してください: -```shell +```zsh autoload -Uz compinit compinit ``` @@ -494,8 +502,8 @@ compinit ## {{% heading "whatsnext" %}} * [Minikubeをインストールする](/ja/docs/tasks/tools/install-minikube/) -* クラスターの作成に関する詳細を[スタートガイド](/docs/setup/)で確認する -* [アプリケーションを起動して公開する方法を学ぶ](/docs/tasks/access-application-cluster/service-access-application-cluster/) -* あなたが作成していないクラスターにアクセスする必要がある場合は、[クラスターアクセスドキュメントの共有](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)を参照してください +* クラスターの作成に関する詳細を[スタートガイド](/ja/docs/setup/)で確認する +* [アプリケーションを起動して公開する方法を学ぶ](/ja/docs/tasks/access-application-cluster/service-access-application-cluster/) +* あなたが作成していないクラスターにアクセスする必要がある場合は、[クラスターアクセスドキュメントの共有](/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)を参照してください * [kubectlリファレンスドキュメント](/docs/reference/kubectl/kubectl/)を参照する From fbb8d5950dc943d830a9f49b76c73e4439818c8c Mon Sep 17 00:00:00 2001 From: Soichiro KAWAMURA Date: Wed, 16 Sep 2020 03:01:30 +0900 Subject: [PATCH 182/252] align indents under ordered lists --- .../ja/docs/tasks/tools/install-kubectl.md | 216 +++++++++--------- 1 file changed, 108 insertions(+), 108 deletions(-) diff --git a/content/ja/docs/tasks/tools/install-kubectl.md b/content/ja/docs/tasks/tools/install-kubectl.md index 937d34e95d..2ab3ca50f7 100644 --- a/content/ja/docs/tasks/tools/install-kubectl.md +++ b/content/ja/docs/tasks/tools/install-kubectl.md @@ -107,34 +107,34 @@ kubectl version --client 1. 最新リリースをダウンロードしてください: - ```bash - curl -LO "https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/darwin/amd64/kubectl" - ``` + ```bash + curl -LO "https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/darwin/amd64/kubectl" + ``` - 特定のバージョンをダウンロードする場合、コマンドの`$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)`の部分を特定のバージョンに書き換えてください。 + 特定のバージョンをダウンロードする場合、コマンドの`$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)`の部分を特定のバージョンに書き換えてください。 - たとえば、macOSへ{{< param "fullversion" >}}のバージョンをダウンロードするには、次のコマンドを入力します: + たとえば、macOSへ{{< param "fullversion" >}}のバージョンをダウンロードするには、次のコマンドを入力します: - ```bash + ```bash curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/darwin/amd64/kubectl - ``` + ``` 2. kubectlバイナリを実行可能にしてください。 - ```bash - chmod +x ./kubectl - ``` + ```bash + chmod +x ./kubectl + ``` 3. バイナリをPATHの中に移動させてください。 - ```bash - sudo mv ./kubectl /usr/local/bin/kubectl - ``` + ```bash + sudo mv ./kubectl /usr/local/bin/kubectl + ``` 4. インストールしたバージョンが最新であることを確認してください: - ```bash - kubectl version --client - ``` + ```bash + kubectl version --client + ``` ### Homebrewを使用してmacOSへインストールする @@ -142,20 +142,20 @@ macOSで[Homebrew](https://brew.sh/)パッケージマネージャーを使用 1. インストールコマンドを実行してください: - ```bash - brew install kubectl - ``` - または + ```bash + brew install kubectl + ``` + または - ```bash - brew install kubernetes-cli - ``` + ```bash + brew install kubernetes-cli + ``` 2. インストールしたバージョンが最新であることを確認してください: - ```bash - kubectl version --client - ``` + ```bash + kubectl version --client + ``` ### MacPortsを使用してmacOSへインストールする @@ -163,16 +163,16 @@ macOSで[MacPorts](https://macports.org/)パッケージマネージャーを使 1. インストールコマンドを実行してください: - ```bash - sudo port selfupdate - sudo port install kubectl - ``` + ```bash + sudo port selfupdate + sudo port install kubectl + ``` 2. インストールしたバージョンが最新であることを確認してください: - ```bash - kubectl version --client - ``` + ```bash + kubectl version --client + ``` ## Windowsへkubectlをインストールする {#install-kubectl-on-windows} @@ -180,20 +180,20 @@ macOSで[MacPorts](https://macports.org/)パッケージマネージャーを使 1. [こちらのリンク](https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe)から、最新リリースである{{< param "fullversion" >}}をダウンロードしてください。 - または、`curl`をインストールされていれば、次のコマンドも使用できます: + または、`curl`をインストールされていれば、次のコマンドも使用できます: ```bash - curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe - ``` + curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe + ``` - 最新の安定版を入手する際は(たとえばスクリプトで使用する場合)、[https://storage.googleapis.com/kubernetes-release/release/stable.txt](https://storage.googleapis.com/kubernetes-release/release/stable.txt)を参照してください。 + 最新の安定版を入手する際は(たとえばスクリプトで使用する場合)、[https://storage.googleapis.com/kubernetes-release/release/stable.txt](https://storage.googleapis.com/kubernetes-release/release/stable.txt)を参照してください。 2. バイナリをPATHに追加します 3. `kubectl`のバージョンがダウンロードしたものと同じであることを確認してください: - ```bash - kubectl version --client - ``` + ```bash + kubectl version --client + ``` {{< note >}} [Docker Desktop for Windows](https://docs.docker.com/docker-for-windows/#kubernetes)は、それ自身のバージョンの`kubectl`をPATHに追加します。Docker Desktopをすでにインストールしている場合、Docker Desktopインストーラーによって追加されたPATHの前に追加するか、Docker Desktopの`kubectl`を削除してください。 {{< /note >}} @@ -204,72 +204,73 @@ Windowsで[Powershell Gallery](https://www.powershellgallery.com/)パッケー 1. インストールコマンドを実行してください(必ず`DownloadLocation`を指定してください): - ```powershell - Install-Script -Name 'install-kubectl' -Scope CurrentUser -Force - install-kubectl.ps1 [-DownloadLocation ] - ``` + ```powershell + Install-Script -Name 'install-kubectl' -Scope CurrentUser -Force + install-kubectl.ps1 [-DownloadLocation ] + ``` - {{< note >}} - `DownloadLocation`を指定しない場合、`kubectl`はユーザのTempディレクトリにインストールされます。 - {{< /note >}} + {{< note >}} + `DownloadLocation`を指定しない場合、`kubectl`はユーザのTempディレクトリにインストールされます。 + {{< /note >}} - インストーラーは`$HOME/.kube`を作成し、設定ファイルを作成します。 + インストーラーは`$HOME/.kube`を作成し、設定ファイルを作成します。 2. インストールしたバージョンが最新であることを確認してください: - ```powershell - kubectl version --client - ``` + ```powershell + kubectl version --client + ``` - {{< note >}} - アップデートする際は、手順1に示した2つのコマンドを再実行してください。 - {{< /note >}} +{{< note >}} +アップデートする際は、手順1に示した2つのコマンドを再実行してください。 +{{< /note >}} ### ChocolateyまたはScoopを使用してWindowsへインストールする 1. Windowsへkubectlをインストールするために、[Chocolatey](https://chocolatey.org)パッケージマネージャーや[Scoop](https://scoop.sh)コマンドラインインストーラーを使用することもできます。 - {{< tabs name="kubectl_win_install" >}} - {{% tab name="choco" %}} - ```powershell - choco install kubernetes-cli - ``` - {{% /tab %}} - {{% tab name="scoop" %}} - ```powershell - scoop install kubectl - ``` - {{% /tab %}} - {{< /tabs >}} + {{< tabs name="kubectl_win_install" >}} + {{% tab name="choco" %}} + ```powershell + choco install kubernetes-cli + ``` + {{% /tab %}} + {{% tab name="scoop" %}} + ```powershell + scoop install kubectl + ``` + {{% /tab %}} + {{< /tabs >}} + 2. インストールしたバージョンが最新であることを確認してください: - ```powershell - kubectl version --client - ``` + ```powershell + kubectl version --client + ``` 3. ホームディレクトリへ移動してください: - ```powershell - # cmd.exeを使用している場合は cd %USERPROFILE% を実行してください。 - cd ~ - ``` + ```powershell + # cmd.exeを使用している場合は cd %USERPROFILE% を実行してください。 + cd ~ + ``` 4. `.kube`ディレクトリを作成してください: - ```powershell - mkdir .kube - ``` + ```powershell + mkdir .kube + ``` 5. 作成した`.kube`ディレクトリへ移動してください: - ```powershell - cd .kube - ``` + ```powershell + cd .kube + ``` 6. リモートのKubernetesクラスターを使うために、kubectlを設定してください: - ```powershell - New-Item config -type file - ``` + ```powershell + New-Item config -type file + ``` {{< note >}} Notepadなどの選択したテキストエディターから設定ファイルを編集してください。 @@ -282,15 +283,15 @@ Google Cloud SDKの一部として、kubectlをインストールすることも 1. [Google Cloud SDK](https://cloud.google.com/sdk/)をインストールしてください。 2. `kubectl`のインストールコマンドを実行してください: - ```shell - gcloud components install kubectl - ``` + ```shell + gcloud components install kubectl + ``` 3. インストールしたバージョンが最新であることを確認してください: - ```shell - kubectl version --client - ``` + ```shell + kubectl version --client + ``` ## kubectlの設定を検証する @@ -355,15 +356,15 @@ source /usr/share/bash-completion/bash_completion - 補完スクリプトを`~/.bashrc`内でsourceしてください: - ```bash - echo 'source <(kubectl completion bash)' >>~/.bashrc - ``` + ```bash + echo 'source <(kubectl completion bash)' >>~/.bashrc + ``` - 補完スクリプトを`/etc/bash_completion.d`ディレクトリに追加してください: - ```bash - kubectl completion bash >/etc/bash_completion.d/kubectl - ``` + ```bash + kubectl completion bash >/etc/bash_completion.d/kubectl + ``` - kubectlにエイリアスを張っている場合は、以下のようにシェルの補完を拡張して使うことができます: ```bash @@ -443,28 +444,28 @@ export BASH_COMPLETION_COMPAT_DIR="/usr/local/etc/bash_completion.d" - 補完スクリプトを`~/.bash_profile`内でsourceする: - ```bash - echo 'source <(kubectl completion bash)' >>~/.bash_profile - ``` + ```bash + echo 'source <(kubectl completion bash)' >>~/.bash_profile + ``` - 補完スクリプトを`/usr/local/etc/bash_completion.d`ディレクトリに追加する: - ```bash - kubectl completion bash >/usr/local/etc/bash_completion.d/kubectl - ``` + ```bash + kubectl completion bash >/usr/local/etc/bash_completion.d/kubectl + ``` - kubectlにエイリアスを張っている場合は、以下のようにシェルの補完を拡張して使うことができます: - ```bash - echo 'alias k=kubectl' >>~/.bash_profile - echo 'complete -F __start_kubectl k' >>~/.bash_profile - ``` + ```bash + echo 'alias k=kubectl' >>~/.bash_profile + echo 'complete -F __start_kubectl k' >>~/.bash_profile + ``` - kubectlをHomwbrewでインストールした場合([前述](#homebrewを使用してmacosへインストールする)のとおり)、kubectlの補完スクリプトはすでに`/usr/local/etc/bash_completion.d/kubectl`に格納されているでしょう。この場合、なにも操作する必要はありません。 - {{< note >}} - Homebrewでインストールしたbash-completion v2は`BASH_COMPLETION_COMPAT_DIR`ディレクトリ内のすべてのファイルをsourceするため、後者の2つの方法が機能します。 - {{< /note >}} + {{< note >}} + Homebrewでインストールしたbash-completion v2は`BASH_COMPLETION_COMPAT_DIR`ディレクトリ内のすべてのファイルをsourceするため、後者の2つの方法が機能します。 + {{< /note >}} どの場合でも、シェルをリロードしたあとに、kubectlの自動補完が機能するはずです。 {{% /tab %}} @@ -506,4 +507,3 @@ compinit * [アプリケーションを起動して公開する方法を学ぶ](/ja/docs/tasks/access-application-cluster/service-access-application-cluster/) * あなたが作成していないクラスターにアクセスする必要がある場合は、[クラスターアクセスドキュメントの共有](/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)を参照してください * [kubectlリファレンスドキュメント](/docs/reference/kubectl/kubectl/)を参照する - From b8e399b2066d54d10793dc04d5760375ec58269b Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Tue, 22 Sep 2020 23:49:14 +0900 Subject: [PATCH 183/252] Update custom-resources.md --- .../api-extension/custom-resources.md | 34 +++++++++---------- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/content/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources.md b/content/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources.md index c05b35cdbc..42ac7a3604 100644 --- a/content/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources.md +++ b/content/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources.md @@ -18,7 +18,7 @@ weight: 10 *カスタムリソース* は、Kubernetes APIの拡張で、デフォルトのKubernetesインストールでは、必ずしも利用できるとは限りません。つまりそれは、特定のKubernetesインストールのカスタマイズを表します。しかし、今現在、多数のKubernetesのコア機能は、カスタムリソースを用いて作られており、Kubernetesをモジュール化しています。 -カスタムリソースは、稼働しているクラスターに動的に登録され、現れたり、消えたりし、クラスター管理者はクラスター自体とは無関係にカスタムリソースを更新できます。一度、カスタムリソースがインストールされると、ユーザーは[kubectl](/docs/user-guide/kubectl-overview/)を使い、ビルトインのリソースである *Pods* と同じように、オブジェクトを作成、アクセスすることが可能です。 +カスタムリソースは、稼働しているクラスターに動的に登録され、現れたり、消えたりし、クラスター管理者はクラスター自体とは無関係にカスタムリソースを更新できます。一度、カスタムリソースがインストールされると、ユーザーは[kubectl](/docs/reference/kubectl/overview/)を使い、ビルトインのリソースである *Pods* と同じように、オブジェクトを作成、アクセスすることが可能です。 ## カスタムコントローラー @@ -31,7 +31,7 @@ weight: 10 ## カスタムリソースをクラスターに追加するべきか？ -新しいAPIを作る場合、[APIをKubernetesクラスターAPIにアグリゲート(集約)する](/ja/docs/concepts/api-extension/apiserver-aggregation/)か、もしくはAPIをスタンドアローンで動かすかを検討します。 +新しいAPIを作る場合、[APIをKubernetesクラスターAPIにアグリゲート(集約)する](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)か、もしくはAPIをスタンドアローンで動かすかを検討します。 | APIアグリゲーションを使う場合: | スタンドアローンAPIを使う場合: | | ------------------------------ | ---------------------------- | @@ -60,7 +60,7 @@ APIが宣言的ではない兆候として、次のものがあります: - クライアントから"これを実行"と命令がきて、完了の返答を同期的に受け取る - クライアントから"これを実行"と命令がきて、処理IDを取得する。そして処理が完了したかどうかを、処理IDを利用して別途問い合わせる - リモートプロシージャコール(RPC)という言葉が飛び交っている - - 直接、大量のデータを格納している(例、1オブジェクトあたり数kBより大きい、または数千オブジェクトより多い) + - 直接、大量のデータを格納している; 例えば、1オブジェクトあたり数kBより大きい、または数千オブジェクトより多い - 高帯域アクセス(持続的に毎秒数十リクエスト)が必要 - エンドユーザーのデータ(画像、PII、その他)を格納している、またはアプリケーションが処理する大量のデータを格納している - オブジェクトに対する処理が、CRUDではない @@ -84,7 +84,7 @@ APIが宣言的ではない兆候として、次のものがあります: 下記のほとんどに該当する場合、カスタムリソース(CRD、またはアグリゲートAPI)を使ってください: * 新しいリソースを作成、更新するために、Kubernetesのクライアントライブラリー、CLIを使いたい -* kubectlのトップレベルサポートが欲しい(例、`kubectl get my-object object-name`) +* kubectlのトップレベルサポートが欲しい; 例えば、`kubectl get my-object object-name` * 新しい自動化の仕組みを作り、新しいオブジェクトの更新をウォッチしたい、その更新を契機に他のオブジェクトのCRUDを実行したい、またはその逆を行いたい * オブジェクトの更新を取り扱う、自動化の仕組みを書きたい * `.spec`、`.status`、`.metadata`というような、Kubernetes APIの慣習を使いたい @@ -107,7 +107,7 @@ CRDでは、APIサーバーの追加なしに、ユーザーが新しい種類 ## CustomResourceDefinition -[CustomResourceDefinition](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/)APIリソースは、カスタムリソースを定義します。CRDオブジェクトを定義することで、指定した名前、スキーマで新しいカスタムリソースが作成されます。Kubernetes APIは、作成したカスタムリソースのストレージを提供、および処理します。 +[CustomResourceDefinition](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)APIリソースは、カスタムリソースを定義します。CRDオブジェクトを定義することで、指定した名前、スキーマで新しいカスタムリソースが作成されます。Kubernetes APIは、作成したカスタムリソースのストレージを提供、および処理します。 CRDオブジェクトの名前は[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names/#dns-subdomain-names)に従わなければなりません。 これはカスタムリソースを処理するために、独自のAPIサーバーを書くことから解放してくれますが、一般的な性質として[APIサーバーアグリゲーション](#APIサーバーアグリゲーション)と比べると、柔軟性に欠けます。 @@ -136,7 +136,7 @@ CRDは、アグリゲートAPIと比べ、簡単に作れます。 | CRD | アグリゲートAPI | | -------------------------- | --------------- | | プログラミングが不要で、ユーザーはCRDコントローラーとしてどの言語でも選択可能 | Go言語でプログラミングし、バイナリとイメージの作成が必要 | -| 追加のサービスは不要。カスタムリソースはAPIサーバーで処理される | 追加のサービス作成が必要で、障害が発生する可能性がある | +| 追加のサービスは不要。CRDはAPIサーバーで処理される | 追加のサービス作成が必要で、障害が発生する可能性がある | | CRDが作成されると、継続的なサポートは無い。バグ修正は通常のKubernetesマスターのアップグレードで行われる | 定期的にアップストリームからバグ修正の取り込み、リビルド、そしてアグリゲートAPIサーバーの更新が必要かもしれない | | 複数バージョンのAPI管理は不要。例えば、あるリソースを操作するクライアントを管理していた場合、APIのアップグレードと一緒に更新される | 複数バージョンのAPIを管理しなければならない。例えば、世界中に共有されている拡張機能を開発している場合 | @@ -146,17 +146,17 @@ CRDは、アグリゲートAPIと比べ、簡単に作れます。 | 機能 | 詳細 | CRD | アグリゲートAPI | | ---- | ---- | --- | --------------- | -| バリデーション | エラーを予防し、クライアントと無関係にAPIを発達させることができるようになる。これらの機能は多数のクライアントがおり、同時に全てを更新できないときに最も効果を発揮する | はい、ほとんどのバリデーションは[OpenAPI v3.0 validation](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation)で、CRDに指定できる。その他のバリデーションは[Webhookのバリデーション](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook-alpha-in-1-8-beta-in-1-9)によりサポートされている | はい、任意のバリデーションが可能 | +| バリデーション | エラーを予防し、クライアントと無関係にAPIを発達させることができるようになる。これらの機能は多数のクライアントがおり、同時に全てを更新できないときに最も効果を発揮する | はい、ほとんどのバリデーションは[OpenAPI v3.0 validation](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation)で、CRDに指定できる。その他のバリデーションは[Webhookのバリデーション](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook-alpha-in-1-8-beta-in-1-9)によりサポートされている | はい、任意のバリデーションが可能 | | デフォルト設定 | 上記を参照 | はい、[OpenAPI v3.0 validation](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#defaulting)の`default`キーワード(1.17でGA)、または[Mutating Webhook](/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook)を通じて可能 (ただし、この方法は古いオブジェクトをetcdから読み込む場合には動きません) | はい | -| 複数バージョニング | 同じオブジェクトを、違うAPIバージョンで利用可能にする。フィールドの名前を変更するなどのAPIの変更を簡単に行うのに役立つ。クライアントのバージョンを管理する場合、重要性は下がる | [はい](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning) | はい | +| 複数バージョニング | 同じオブジェクトを、違うAPIバージョンで利用可能にする。フィールドの名前を変更するなどのAPIの変更を簡単に行うのに役立つ。クライアントのバージョンを管理する場合、重要性は下がる | [はい](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning) | はい | | カスタムストレージ | 異なる性能のストレージが必要な場合(例えば、キーバリューストアの代わりに時系列データベース)または、セキュリティの分離(例えば、機密情報の暗号化、その他)| いいえ | はい | | カスタムビジネスロジック | オブジェクトが作成、読み込み、更新、また削除されるときに任意のチェック、アクションを実行する| はい、[Webhooks](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)を利用 | はい | -| サブリソースのスケール | HorizontalPodAutoscalerやPodDisruptionBudgetなどのシステムが、新しいリソースと連携できるようにする | [はい](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#scale-subresource) | はい | -| サブリソースの状態 | ユーザーがspecセクションに書き込み、コントローラーがstatusセクションに書き込む際に、より詳細なアクセスコントロールができるようにする。カスタムリソースのデータ変換時にオブジェクトの世代を上げられるようにする(リソース内のspecとstatusでセクションが分離している必要がある) | [はい](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#status-subresource) | はい | +| サブリソースのスケール | HorizontalPodAutoscalerやPodDisruptionBudgetなどのシステムが、新しいリソースと連携できるようにする | [はい](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource) | はい | +| サブリソースの状態 | ユーザーがspecセクションに書き込み、コントローラーがstatusセクションに書き込む際に、より詳細なアクセスコントロールができるようにする。カスタムリソースのデータ変換時にオブジェクトの世代を上げられるようにする(リソース内のspecとstatusでセクションが分離している必要がある) | [はい](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#status-subresource) | はい | | その他のサブリソース | "logs"や"exec"のような、CRUD以外の処理の追加 | いいえ | はい | -| strategic-merge-patch |`Content-Type: application/strategic-merge-patch+json`で、PATCHをサポートする新しいエンドポイント。ローカル、サーバー、どちらでも更新されうるオブジェクトに有用。さらなる情報は["APIオブジェクトをkubectl patchで決まった場所で更新"](/docs/tasks/run-application/update-api-object-kubectl-patch/)を参照 | いいえ | はい | +| strategic-merge-patch |`Content-Type: application/strategic-merge-patch+json`で、PATCHをサポートする新しいエンドポイント。ローカル、サーバー、どちらでも更新されうるオブジェクトに有用。さらなる情報は["APIオブジェクトをkubectl patchで決まった場所で更新"](/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/)を参照 | いいえ | はい | | プロトコルバッファ | プロトコルバッファを使用するクライアントをサポートする新しいリソース | いいえ | はい | -| OpenAPIスキーマ | サーバーから動的に取得できる型のOpenAPI(Swagger)スキーマはあるか、許可されたフィールドのみが設定されるようにすることで、ユーザーはフィールド名のスペルミスから保護されているか、型は強制されているか(言い換えると、「文字列」フィールドに「int」を入れさせない) | はい、[OpenAPI v3.0 validation](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation) スキーマがベース(1.16でGA) | はい | +| OpenAPIスキーマ | サーバーから動的に取得できる型のOpenAPI(Swagger)スキーマはあるか、許可されたフィールドのみが設定されるようにすることで、ユーザーはフィールド名のスペルミスから保護されているか、型は強制されているか(言い換えると、「文字列」フィールドに「int」を入れさせない) | はい、[OpenAPI v3.0 validation](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation) スキーマがベース(1.16でGA) | はい | ### 一般的な機能 @@ -166,12 +166,12 @@ CRD、またはアグリゲートAPI、どちらを使ってカスタムリソ | ---- | -------------- | | CRUD | 新しいエンドポイントが、HTTP、`kubectl`を通じて、基本的なCRUD処理をサポート | | Watch | 新しいエンドポイントが、HTTPを通じて、KubernetesのWatch処理をサポート | -| Discovery | kubectlやダッシュボードのようなクライアントが、自動的にリソースの一覧表示、個別表示、フィールドの編集処理を提供 | +| Discovery | `kubectl`やダッシュボードのようなクライアントが、自動的にリソースの一覧表示、個別表示、フィールドの編集処理を提供 | | json-patch | 新しいエンドポイントが`Content-Type: application/json-patch+json`を用いたPATCHをサポート | | merge-patch | 新しいエンドポイントが`Content-Type: application/merge-patch+json`を用いたPATCHをサポート | | HTTPS | 新しいエンドポイントがHTTPSを利用 | | ビルトイン認証 | 拡張機能へのアクセスに認証のため、コアAPIサーバー(アグリゲーションレイヤー)を利用 | -| ビルトイン認可 | 拡張機能へのアクセスにコアAPIサーバーで使われている認可メカニズムを再利用(例、RBAC) | +| ビルトイン認可 | 拡張機能へのアクセスにコアAPIサーバーで使われている認可メカニズムを再利用; 例えば、RBAC) | | ファイナライザー | 外部リソースの削除が終わるまで、拡張リソースの削除をブロック | | Admission Webhooks | 拡張リソースの作成/更新/削除処理時に、デフォルト値の設定、バリデーションを実施 | | UI/CLI 表示 | kubectl、ダッシュボードで拡張リソースを表示 | @@ -205,11 +205,11 @@ CRDでは、APIサーバーのビルトインリソースと同じ認証、認 ## カスタムリソースへのアクセス -Kubernetesの[クライアントライブラリー](/docs/reference/using-api/client-libraries/)を使い、カスタムリソースにアクセスすることが可能です。全てのクライアントライブラリーがカスタムリソースをサポートしているわけでは無いですが、GoとPythonのライブラリーはサポートしています。 +Kubernetesの[クライアントライブラリー](/docs/reference/using-api/client-libraries/)を使い、カスタムリソースにアクセスすることが可能です。全てのクライアントライブラリーがカスタムリソースをサポートしているわけでは無いですが、_Go_と_Python_のライブラリーはサポートしています。 カスタムリソースは、下記のような方法で操作できます: -- kubectl +- `kubectl` - kubernetesの動的クライアント - 自作のRESTクライアント - [Kubernetesクライアント生成ツール](https://github.com/kubernetes/code-generator)を使い生成したクライアント(生成は高度な作業ですが、一部のプロジェクトは、CRDまたはAAとともにクライアントを提供する場合があります) @@ -220,4 +220,4 @@ Kubernetesの[クライアントライブラリー](/docs/reference/using-api/cl * [Kubernetes APIをアグリゲーションレイヤーで拡張する方法](/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)について学ぶ -* [Kubernetes APIをCustomResourceDefinitionで拡張する方法](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/)について学ぶ +* [Kubernetes APIをCustomResourceDefinitionで拡張する方法](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)について学ぶ From 53121cbed33964e2203ebc033890e7789fdc9dec Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Wed, 23 Sep 2020 01:15:53 +0900 Subject: [PATCH 184/252] apply suggestions --- .../api-extension/custom-resources.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/content/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources.md b/content/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources.md index 42ac7a3604..a35dbd4b91 100644 --- a/content/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources.md +++ b/content/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources.md @@ -18,7 +18,7 @@ weight: 10 *カスタムリソース* は、Kubernetes APIの拡張で、デフォルトのKubernetesインストールでは、必ずしも利用できるとは限りません。つまりそれは、特定のKubernetesインストールのカスタマイズを表します。しかし、今現在、多数のKubernetesのコア機能は、カスタムリソースを用いて作られており、Kubernetesをモジュール化しています。 -カスタムリソースは、稼働しているクラスターに動的に登録され、現れたり、消えたりし、クラスター管理者はクラスター自体とは無関係にカスタムリソースを更新できます。一度、カスタムリソースがインストールされると、ユーザーは[kubectl](/docs/reference/kubectl/overview/)を使い、ビルトインのリソースである *Pods* と同じように、オブジェクトを作成、アクセスすることが可能です。 +カスタムリソースは、稼働しているクラスターに動的に登録され、現れたり、消えたりし、クラスター管理者はクラスター自体とは無関係にカスタムリソースを更新できます。一度、カスタムリソースがインストールされると、ユーザーは[kubectl](/ja/docs/reference/kubectl/overview/)を使い、ビルトインのリソースである *Pods* と同じように、オブジェクトを作成、アクセスすることが可能です。 ## カスタムコントローラー @@ -31,7 +31,7 @@ weight: 10 ## カスタムリソースをクラスターに追加するべきか？ -新しいAPIを作る場合、[APIをKubernetesクラスターAPIにアグリゲート(集約)する](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)か、もしくはAPIをスタンドアローンで動かすかを検討します。 +新しいAPIを作る場合、[APIをKubernetesクラスターAPIにアグリゲート(集約)する](/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)か、もしくはAPIをスタンドアローンで動かすかを検討します。 | APIアグリゲーションを使う場合: | スタンドアローンAPIを使う場合: | | ------------------------------ | ---------------------------- | @@ -60,7 +60,7 @@ APIが宣言的ではない兆候として、次のものがあります: - クライアントから"これを実行"と命令がきて、完了の返答を同期的に受け取る - クライアントから"これを実行"と命令がきて、処理IDを取得する。そして処理が完了したかどうかを、処理IDを利用して別途問い合わせる - リモートプロシージャコール(RPC)という言葉が飛び交っている - - 直接、大量のデータを格納している; 例えば、1オブジェクトあたり数kBより大きい、または数千オブジェクトより多い + - 直接、大量のデータを格納している(例、1オブジェクトあたり数kBより大きい、または数千オブジェクトより多い) - 高帯域アクセス(持続的に毎秒数十リクエスト)が必要 - エンドユーザーのデータ(画像、PII、その他)を格納している、またはアプリケーションが処理する大量のデータを格納している - オブジェクトに対する処理が、CRUDではない @@ -78,13 +78,13 @@ APIが宣言的ではない兆候として、次のものがあります: * ファイルが更新されたときに、Deploymentなどを介してローリングアップデートを行いたい {{< note >}} -センシティブなデータには、ConfigMapに類似していますがよりセキュアな[secret](/docs/concepts/configuration/secret/)を使ってください +センシティブなデータには、ConfigMapに類似していますがよりセキュアな[secret](/ja/docs/concepts/configuration/secret/)を使ってください {{< /note >}} 下記のほとんどに該当する場合、カスタムリソース(CRD、またはアグリゲートAPI)を使ってください: * 新しいリソースを作成、更新するために、Kubernetesのクライアントライブラリー、CLIを使いたい -* kubectlのトップレベルサポートが欲しい; 例えば、`kubectl get my-object object-name` +* kubectlのトップレベルサポートが欲しい(例、`kubectl get my-object object-name`) * 新しい自動化の仕組みを作り、新しいオブジェクトの更新をウォッチしたい、その更新を契機に他のオブジェクトのCRUDを実行したい、またはその逆を行いたい * オブジェクトの更新を取り扱う、自動化の仕組みを書きたい * `.spec`、`.status`、`.metadata`というような、Kubernetes APIの慣習を使いたい @@ -205,7 +205,7 @@ CRDでは、APIサーバーのビルトインリソースと同じ認証、認 ## カスタムリソースへのアクセス -Kubernetesの[クライアントライブラリー](/docs/reference/using-api/client-libraries/)を使い、カスタムリソースにアクセスすることが可能です。全てのクライアントライブラリーがカスタムリソースをサポートしているわけでは無いですが、_Go_と_Python_のライブラリーはサポートしています。 +Kubernetesの[クライアントライブラリー](/docs/reference/using-api/client-libraries/)を使い、カスタムリソースにアクセスすることが可能です。全てのクライアントライブラリーがカスタムリソースをサポートしているわけでは無いですが、_Go_ と _Python_ のライブラリーはサポートしています。 カスタムリソースは、下記のような方法で操作できます: From cfb164ca3a0e706b20036b7c7b23f9a34222202b Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Wed, 23 Sep 2020 01:33:26 +0900 Subject: [PATCH 185/252] apply suggestions --- .../extend-kubernetes/api-extension/custom-resources.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources.md b/content/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources.md index a35dbd4b91..3616f568c1 100644 --- a/content/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources.md +++ b/content/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources.md @@ -171,7 +171,7 @@ CRD、またはアグリゲートAPI、どちらを使ってカスタムリソ | merge-patch | 新しいエンドポイントが`Content-Type: application/merge-patch+json`を用いたPATCHをサポート | | HTTPS | 新しいエンドポイントがHTTPSを利用 | | ビルトイン認証 | 拡張機能へのアクセスに認証のため、コアAPIサーバー(アグリゲーションレイヤー)を利用 | -| ビルトイン認可 | 拡張機能へのアクセスにコアAPIサーバーで使われている認可メカニズムを再利用; 例えば、RBAC) | +| ビルトイン認可 | 拡張機能へのアクセスにコアAPIサーバーで使われている認可メカニズムを再利用(例、RBAC) | | ファイナライザー | 外部リソースの削除が終わるまで、拡張リソースの削除をブロック | | Admission Webhooks | 拡張リソースの作成/更新/削除処理時に、デフォルト値の設定、バリデーションを実施 | | UI/CLI 表示 | kubectl、ダッシュボードで拡張リソースを表示 | From f3ee0dd2a7f027ecd852d1193dc59ac48054aeb6 Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Wed, 23 Sep 2020 12:34:58 +0900 Subject: [PATCH 186/252] Update ja/docs/tutorials/stateless-application/expose-external-ip-address.md --- .../stateless-application/expose-external-ip-address.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tutorials/stateless-application/expose-external-ip-address.md b/content/ja/docs/tutorials/stateless-application/expose-external-ip-address.md index c4b76e1e3f..ca4eb8c439 100644 --- a/content/ja/docs/tutorials/stateless-application/expose-external-ip-address.md +++ b/content/ja/docs/tutorials/stateless-application/expose-external-ip-address.md @@ -46,7 +46,7 @@ kubectl apply -f https://k8s.io/examples/service/load-balancer-example.yaml ``` -上記のコマンドにより、[Deployment](/ja/docs/concepts/workloads/controllers/deployment/)オブジェクトを作成し、[ReplicaSet](/ja/docs/concepts/workloads/controllers/replicaset/)オブジェクトを関連づけます。ReplicaSetには5つの[Pod](/ja/docs/concepts/workloads/pods/pod/)があり、それぞれHello Worldアプリケーションが起動しています。 +上記のコマンドにより、 {{< glossary_tooltip text="Deployment" term_id="deployment" >}}オブジェクトを作成し、{{< glossary_tooltip term_id="replica-set" text="ReplicaSet" >}}オブジェクトを関連づけます。ReplicaSetには5つの{{< glossary_tooltip text="Pod" term_id="pod" >}}があり、それぞれHello Worldアプリケーションが起動しています。 1. Deploymentに関する情報を表示します: From 79afbcf5cc0758b77ec5d8966a067a05ec2215a4 Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Wed, 23 Sep 2020 12:38:30 +0900 Subject: [PATCH 187/252] Update ja/docs/tutorials/stateless-application/expose-external-ip-address.md --- .../stateless-application/expose-external-ip-address.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tutorials/stateless-application/expose-external-ip-address.md b/content/ja/docs/tutorials/stateless-application/expose-external-ip-address.md index ca4eb8c439..2dad39cfa9 100644 --- a/content/ja/docs/tutorials/stateless-application/expose-external-ip-address.md +++ b/content/ja/docs/tutorials/stateless-application/expose-external-ip-address.md @@ -46,7 +46,7 @@ kubectl apply -f https://k8s.io/examples/service/load-balancer-example.yaml ``` -上記のコマンドにより、 {{< glossary_tooltip text="Deployment" term_id="deployment" >}}オブジェクトを作成し、{{< glossary_tooltip term_id="replica-set" text="ReplicaSet" >}}オブジェクトを関連づけます。ReplicaSetには5つの{{< glossary_tooltip text="Pod" term_id="pod" >}}があり、それぞれHello Worldアプリケーションが起動しています。 +上記のコマンドにより、 {{< glossary_tooltip text="Deployment" term_id="deployment" >}}を作成し、{{< glossary_tooltip term_id="replica-set" text="ReplicaSet" >}}を関連づけます。ReplicaSetには5つの{{< glossary_tooltip text="Pod" term_id="pod" >}}があり、それぞれHello Worldアプリケーションが起動しています。 1. Deploymentに関する情報を表示します: From e32bf8f038adcc25916ab6e8e4df3329b25893dd Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Wed, 23 Sep 2020 00:04:28 +0900 Subject: [PATCH 188/252] Update operator.md --- content/ja/docs/concepts/extend-kubernetes/operator.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/extend-kubernetes/operator.md b/content/ja/docs/concepts/extend-kubernetes/operator.md index 507463359d..e8eb71b47c 100644 --- a/content/ja/docs/concepts/extend-kubernetes/operator.md +++ b/content/ja/docs/concepts/extend-kubernetes/operator.md @@ -6,7 +6,7 @@ weight: 30 -オペレーターはサードパーティのアプリケーション、コンポーネントを管理するためのリソースを活用する、Kubernetesへのソフトウェア拡張です。 +オペレーターは[カスタムリソース](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)を使用するKubernetesへのソフトウェア拡張です。 オペレーターは、特に[制御ループ](/docs/concepts/#kubernetes-control-plane)のようなKubernetesが持つ仕組みに準拠しています。 @@ -75,7 +75,7 @@ kubectl edit SampleDB/example-database # 手動でいくつかの設定を変更 ## 自分でオペレーターを書く {#writing-operator} 必要な振る舞いを実装したオペレーターがエコシステム内に無い場合、自分で作成することができます。 -[次の項目](#what-s-next)で、自分でクラウドネイティブオペレーターを作るときに利用できるライブラリやツールのリンクを見つけることができます。 +[次の項目](#whats-next)で、自分でクラウドネイティブオペレーターを作るときに利用できるライブラリやツールのリンクを見つけることができます。 オペレーター（すなわち、コントローラー）はどの言語/ランタイムでも実装でき、[Kubernetes APIのクライアント](/docs/reference/using-api/client-libraries/)として機能させることができます。 From 8e231bd99f7d84f87bb50c60e3fcc2ad93c61812 Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Wed, 23 Sep 2020 01:02:12 +0900 Subject: [PATCH 189/252] apply suggestions --- content/ja/docs/concepts/extend-kubernetes/operator.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/extend-kubernetes/operator.md b/content/ja/docs/concepts/extend-kubernetes/operator.md index e8eb71b47c..894b300b3c 100644 --- a/content/ja/docs/concepts/extend-kubernetes/operator.md +++ b/content/ja/docs/concepts/extend-kubernetes/operator.md @@ -6,8 +6,8 @@ weight: 30 -オペレーターは[カスタムリソース](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)を使用するKubernetesへのソフトウェア拡張です。 -オペレーターは、特に[制御ループ](/docs/concepts/#kubernetes-control-plane)のようなKubernetesが持つ仕組みに準拠しています。 +オペレーターは[カスタムリソース](/ja//docs/concepts/extend-kubernetes/api-extension/custom-resources/)を使用するKubernetesへのソフトウェア拡張です。 +オペレーターは、特に[制御ループ](/ja/docs/concepts/#kubernetes-control-plane)のようなKubernetesが持つ仕組みに準拠しています。 From 1b5fd47397de370c40a5159aa7580acc73c8383e Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Thu, 24 Sep 2020 19:45:41 +0900 Subject: [PATCH 190/252] Update content/ja/docs/concepts/extend-kubernetes/operator.md Co-authored-by: nasa9084 --- content/ja/docs/concepts/extend-kubernetes/operator.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/extend-kubernetes/operator.md b/content/ja/docs/concepts/extend-kubernetes/operator.md index 894b300b3c..e9ac2054e8 100644 --- a/content/ja/docs/concepts/extend-kubernetes/operator.md +++ b/content/ja/docs/concepts/extend-kubernetes/operator.md @@ -6,7 +6,7 @@ weight: 30 -オペレーターは[カスタムリソース](/ja//docs/concepts/extend-kubernetes/api-extension/custom-resources/)を使用するKubernetesへのソフトウェア拡張です。 +オペレーターは[カスタムリソース](/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources/)を使用するKubernetesへのソフトウェア拡張です。 オペレーターは、特に[制御ループ](/ja/docs/concepts/#kubernetes-control-plane)のようなKubernetesが持つ仕組みに準拠しています。 @@ -95,4 +95,3 @@ 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)を読みます - From f25b316b44962de280c24c130bc896651cb43705 Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Fri, 25 Sep 2020 13:10:43 +0900 Subject: [PATCH 191/252] Update ja/docs/reference/_index.md --- content/ja/docs/reference/_index.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/reference/_index.md b/content/ja/docs/reference/_index.md index a417966012..4276875967 100644 --- a/content/ja/docs/reference/_index.md +++ b/content/ja/docs/reference/_index.md @@ -31,16 +31,18 @@ content_type: concept ## CLIリファレンス * [kubectl](/docs/reference/kubectl/overview/) - コマンドの実行やKubernetesクラスターの管理に使う主要なCLIツールです。 - * [JSONPath](/docs/reference/kubectl/jsonpath/) - kubectlで[JSONPath記法](http://goessner.net/articles/JsonPath/)を使うための構文ガイドです。 + * [JSONPath](/docs/reference/kubectl/jsonpath/) - kubectlで[JSONPath記法](https://goessner.net/articles/JsonPath/)を使うための構文ガイドです。 * [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) - セキュアなKubernetesクラスターを簡単にプロビジョニングするためのCLIツールです。 -## 設定リファレンス +## コンポーネントリファレンス * [kubelet](/docs/reference/command-line-tools-reference/kubelet/) - 各ノード上で動作する最も重要なノードエージェントです。kubeletは一通りのPodSpecを受け取り、コンテナーが実行中で正常であることを確認します。 * [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/) - Pod、Service、Replication Controller等、APIオブジェクトのデータを検証・設定するREST APIサーバーです。 * [kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/) - Kubernetesに同梱された、コアのコントロールループを埋め込むデーモンです。 * [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) - 単純なTCP/UDPストリームのフォワーディングや、一連のバックエンド間でTCP/UDPのラウンドロビンでのフォワーディングを実行できます。 * [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/) - 可用性、パフォーマンス、およびキャパシティを管理するスケジューラーです。 + * [kube-schedulerポリシー](/docs/reference/scheduling/policies) + * [kube-schedulerプロファイル](/docs/reference/scheduling/profiles) ## 設計のドキュメント From c2ee0d9eb1b0500c45f0ffd388067bfcceb65806 Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Fri, 25 Sep 2020 12:43:07 +0900 Subject: [PATCH 192/252] Update ja/docs/concepts/services-networking/_index.md --- content/ja/docs/concepts/services-networking/_index.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/content/ja/docs/concepts/services-networking/_index.md b/content/ja/docs/concepts/services-networking/_index.md index 3a33830f2f..4089dc17cf 100755 --- a/content/ja/docs/concepts/services-networking/_index.md +++ b/content/ja/docs/concepts/services-networking/_index.md @@ -1,4 +1,12 @@ --- title: "Service、負荷分散とネットワーキング" weight: 60 +description: > + Kubernetesにおけるネットワーキングの概念とリソース。 --- + +Kubernetesのネットワーキングは4つの懸念事項に対処します。 +- Pod内のコンテナは、ネットワーキングを利用してループバック経由の通信を行います。 +- クラスターネットワーキングは、異なるPod間の通信を提供します。 +- Serviceリソースは、Pod内で動作しているアプリケーションへクラスターの外部から到達可能なように露出を許可します。 +- Serviceを利用して、クラスタ内部のみで使用するServiceの公開も可能です。 From 54b79a5406578e872223775cc93dfa628fafa0b2 Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Wed, 23 Sep 2020 12:55:23 +0900 Subject: [PATCH 193/252] Update ja/docs/setup/best-practices/cluster-large.md --- .../setup/best-practices/cluster-large.md | 27 ++++++++----------- 1 file changed, 11 insertions(+), 16 deletions(-) diff --git a/content/ja/docs/setup/best-practices/cluster-large.md b/content/ja/docs/setup/best-practices/cluster-large.md index 438a692fbf..5eda7e4a89 100644 --- a/content/ja/docs/setup/best-practices/cluster-large.md +++ b/content/ja/docs/setup/best-practices/cluster-large.md @@ -12,15 +12,12 @@ At {{< param "version" >}}, Kubernetes supports clusters with up to 5000 nodes. * No more than 300000 total containers * No more than 100 pods per node -
- -{{< toc >}} ## 構築 A cluster is a set of nodes (physical or virtual machines) running Kubernetes agents, managed by a "master" (the cluster-level control plane). -Normally the number of nodes in a cluster is controlled by the value `NUM_NODES` in the platform-specific `config-default.sh` file (for example, see [GCE's `config-default.sh`](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/gce/config-default.sh)). +Normally the number of nodes in a cluster is controlled by the value `NUM_NODES` in the platform-specific `config-default.sh` file (for example, see [GCE's `config-default.sh`](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/gce/config-default.sh)). Simply changing that value to something very large, however, may cause the setup script to fail for many cloud providers. A GCE deployment, for example, will run in to quota issues and fail to bring the cluster up. @@ -80,7 +77,7 @@ On AWS, master node sizes are currently set at cluster startup time and do not c ### アドオンのリソース -To prevent memory leaks or other resource issues in [cluster addons](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons) from consuming all the resources available on a node, Kubernetes sets resource limits on addon containers to limit the CPU and Memory resources they can consume (See PR [#10653](http://pr.k8s.io/10653/files) and [#10778](http://pr.k8s.io/10778/files)). +To prevent memory leaks or other resource issues in [cluster addons](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons) from consuming all the resources available on a node, Kubernetes sets resource limits on addon containers to limit the CPU and Memory resources they can consume (See PR [#10653](httpis://pr.k8s.io/10653/files) and [#10778](http://pr.k8s.io/10778/files)). For example: @@ -94,28 +91,26 @@ For example: memory: 200Mi ``` -Except for Heapster, these limits are static and are based on data we collected from addons running on 4-node clusters (see [#10335](http://issue.k8s.io/10335#issuecomment-117861225)). The addons consume a lot more resources when running on large deployment clusters (see [#5880](http://issue.k8s.io/5880#issuecomment-113984085)). So, if a large cluster is deployed without adjusting these values, the addons may continuously get killed because they keep hitting the limits. +Except for Heapster, these limits are static and are based on data we collected from addons running on 4-node clusters (see [#10335](https://issue.k8s.io/10335#issuecomment-117861225)). The addons consume a lot more resources when running on large deployment clusters (see [#5880](http://issue.k8s.io/5880#issuecomment-113984085)). So, if a large cluster is deployed without adjusting these values, the addons may continuously get killed because they keep hitting the limits. To avoid running into cluster addon resource issues, when creating a cluster with many nodes, consider the following: * Scale memory and CPU limits for each of the following addons, if used, as you scale up the size of cluster (there is one replica of each handling the entire cluster so memory and CPU usage tends to grow proportionally with size/load on cluster): - * [InfluxDB and Grafana](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/cluster-monitoring/influxdb/influxdb-grafana-controller.yaml) - * [kubedns, dnsmasq, and sidecar](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/kube-dns/kube-dns.yaml.in) - * [Kibana](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/kibana-deployment.yaml) + * [InfluxDB and Grafana](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/cluster-monitoring/influxdb/influxdb-grafana-controller.yaml) + * [kubedns, dnsmasq, and sidecar](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/kube-dns/kube-dns.yaml.in) + * [Kibana](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/kibana-deployment.yaml) * Scale number of replicas for the following addons, if used, along with the size of cluster (there are multiple replicas of each so increasing replicas should help handle increased load, but, since load per replica also increases slightly, also consider increasing CPU/memory limits): - * [elasticsearch](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/es-statefulset.yaml) + * [elasticsearch](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/es-statefulset.yaml) * Increase memory and CPU limits slightly for each of the following addons, if used, along with the size of cluster (there is one replica per node but CPU/memory usage increases slightly along with cluster load/size as well): - * [FluentD with ElasticSearch Plugin](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/fluentd-es-ds.yaml) - * [FluentD with GCP Plugin](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-gcp/fluentd-gcp-ds.yaml) + * [FluentD with ElasticSearch Plugin](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/fluentd-es-ds.yaml) + * [FluentD with GCP Plugin](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-gcp/fluentd-gcp-ds.yaml) Heapster's resource limits are set dynamically based on the initial size of your cluster (see [#16185](http://issue.k8s.io/16185) and [#22940](http://issue.k8s.io/22940)). If you find that Heapster is running out of resources, you should adjust the formulas that compute heapster memory request (see those PRs for details). -For directions on how to detect if addon containers are hitting resource limits, see the [Troubleshooting section of Compute Resources](/docs/concepts/configuration/manage-compute-resources-container/#troubleshooting). - -In the [future](http://issue.k8s.io/13048), we anticipate to set all cluster addon resource limits based on cluster size, and to dynamically adjust them if you grow or shrink your cluster. -We welcome PRs that implement those features. +For directions on how to detect if addon containers are hitting resource limits, see the +[Troubleshooting section of Compute Resources](/docs/concepts/configuration/manage-resources-containers/#troubleshooting). ### 少数のノードの起動の失敗を許容する From bea5c0ed6122a3141ff097246409d0f989df8cda Mon Sep 17 00:00:00 2001 From: yu-kasuya Date: Mon, 28 Sep 2020 12:03:35 +0900 Subject: [PATCH 194/252] Apply suggestions from code review Co-authored-by: nasa9084 --- content/ja/docs/setup/best-practices/cluster-large.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/setup/best-practices/cluster-large.md b/content/ja/docs/setup/best-practices/cluster-large.md index 5eda7e4a89..bc59b1b8ee 100644 --- a/content/ja/docs/setup/best-practices/cluster-large.md +++ b/content/ja/docs/setup/best-practices/cluster-large.md @@ -77,7 +77,7 @@ On AWS, master node sizes are currently set at cluster startup time and do not c ### アドオンのリソース -To prevent memory leaks or other resource issues in [cluster addons](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons) from consuming all the resources available on a node, Kubernetes sets resource limits on addon containers to limit the CPU and Memory resources they can consume (See PR [#10653](httpis://pr.k8s.io/10653/files) and [#10778](http://pr.k8s.io/10778/files)). +To prevent memory leaks or other resource issues in [cluster addons](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons) from consuming all the resources available on a node, Kubernetes sets resource limits on addon containers to limit the CPU and Memory resources they can consume (See PR [#10653](https://pr.k8s.io/10653/files) and [#10778](https://pr.k8s.io/10778/files)). For example: From 3f0d8ecde252491171552c0440d96506045c8224 Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Thu, 24 Sep 2020 13:04:19 +0900 Subject: [PATCH 195/252] Update ja/docs/tasks/run-application/force-delete-stateful-set-pod.md --- .../run-application/force-delete-stateful-set-pod.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/content/ja/docs/tasks/run-application/force-delete-stateful-set-pod.md b/content/ja/docs/tasks/run-application/force-delete-stateful-set-pod.md index 7d6830a50f..83f7b52c85 100644 --- a/content/ja/docs/tasks/run-application/force-delete-stateful-set-pod.md +++ b/content/ja/docs/tasks/run-application/force-delete-stateful-set-pod.md @@ -31,13 +31,13 @@ StatefulSetの通常の操作では、StatefulSet Podを強制的に削除する kubectl delete pods ``` -上記がグレースフルターミネーションにつながるためには、`pod.Spec.TerminationGracePeriodSeconds`に0を指定しては**いけません**。`pod.Spec.TerminationGracePeriodSeconds`を0秒に設定することは安全ではなく、StatefulSet Podには強くお勧めできません。グレースフル削除は安全で、kubeletがapiserverから名前を削除する前に[Podが適切にシャットダウンする](/ja/docs/concepts/workloads/pods/pod/#termination-of-pods)ことを保証します。 +上記がグレースフルターミネーションにつながるためには、`pod.Spec.TerminationGracePeriodSeconds`に0を指定しては**いけません**。`pod.Spec.TerminationGracePeriodSeconds`を0秒に設定することは安全ではなく、StatefulSet Podには強くお勧めできません。グレースフル削除は安全で、kubeletがapiserverから名前を削除する前にPodが[適切にシャットダウンする](/ja/docs/concepts/workloads/pods/pod-lifecycle/#termination-of-pods)ことを保証します。 -Kubernetes(バージョン1.5以降)は、Nodeにアクセスできないという理由だけでPodを削除しません。到達不能なNodeで実行されているPodは、[タイムアウト](/docs/admin/node/#node-condition)の後に`Terminating`または`Unknown`状態になります。到達不能なNode上のPodをユーザーが適切に削除しようとすると、Podはこれらの状態に入ることもあります。そのような状態のPodをapiserverから削除することができる唯一の方法は以下の通りです: +Kubernetes(バージョン1.5以降)は、Nodeにアクセスできないという理由だけでPodを削除しません。到達不能なNodeで実行されているPodは、[タイムアウト](/docs/concepts/architecture/nodes/#node-condition)の後に`Terminating`または`Unknown`状態になります。到達不能なNode上のPodをユーザーが適切に削除しようとすると、Podはこれらの状態に入ることもあります。そのような状態のPodをapiserverから削除することができる唯一の方法は以下の通りです: - * (ユーザーまたは[Node Controller](/docs/admin/node)によって)Nodeオブジェクトが削除されます。
- * 応答していないNodeのkubeletが応答を開始し、Podを終了してapiserverからエントリーを削除します。
- * ユーザーによりPodを強制削除します。 +* (ユーザーまたは[Node Controller](/ja/docs/concepts/architecture/nodes/)によって)Nodeオブジェクトが削除されます。 +* 応答していないNodeのkubeletが応答を開始し、Podを終了してapiserverからエントリーを削除します。 +* ユーザーによりPodを強制削除します。 推奨されるベストプラクティスは、1番目または2番目のアプローチを使用することです。Nodeが死んでいることが確認された(例えば、ネットワークから恒久的に切断された、電源が切られたなど)場合、Nodeオブジェクトを削除します。Nodeがネットワークパーティションに苦しんでいる場合は、これを解決するか、解決するのを待ちます。パーティションが回復すると、kubeletはPodの削除を完了し、apiserverでその名前を解放します。 From 1965e44ac9e98833b2e133dee2c8ae9851eec8f2 Mon Sep 17 00:00:00 2001 From: ShotaKitazawa Date: Mon, 28 Sep 2020 14:42:27 +0900 Subject: [PATCH 196/252] fix typo --- content/ja/docs/concepts/workloads/controllers/statefulset.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/workloads/controllers/statefulset.md b/content/ja/docs/concepts/workloads/controllers/statefulset.md index 08d11dbf50..1fa4c5c767 100644 --- a/content/ja/docs/concepts/workloads/controllers/statefulset.md +++ b/content/ja/docs/concepts/workloads/controllers/statefulset.md @@ -176,7 +176,7 @@ Kubernetes1.7とそれ以降のバージョンでは、StatefulSetは`.spec.podM ## アップデートストラテジー -Kubernetes1.7とそれ以降のバージョンにおいて、StatefulSetの`.spec.updateStarategy`フィールドで、コンテナの自動のローリングアップデートの設定やラベル、リソースのリクエストとリミットや、StatefulSet内のPodのアノテーションを指定できます。 +Kubernetes1.7とそれ以降のバージョンにおいて、StatefulSetの`.spec.updateStrategy`フィールドで、コンテナの自動のローリングアップデートの設定やラベル、リソースのリクエストとリミットや、StatefulSet内のPodのアノテーションを指定できます。 ### OnDelete From 6acafe23b851a7e0a6864961e0a5eab5319c9be2 Mon Sep 17 00:00:00 2001 From: Jin Hase Date: Thu, 10 Sep 2020 17:20:00 +0900 Subject: [PATCH 197/252] Update Japanese localization on concepts/workloads/pods/pod-lifecycle.md --- .../concepts/workloads/pods/pod-lifecycle.md | 424 ++++++++---------- 1 file changed, 179 insertions(+), 245 deletions(-) diff --git a/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md b/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md index 1cf9df1580..aeaa355722 100644 --- a/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md @@ -6,186 +6,110 @@ weight: 30 -このページではPodのライフサイクルについて説明します。 +このページではPodのライフサイクルについて説明します。Podは定義されたライフサイクルに従い `Pending`[フェーズ](#pod-phase)から始まり、少なくとも1つのプライマリコンテナが正常に開始した場合は`Running`を経由し、次に失敗により終了したコンテナの有無に応じて、`Succeeded`または`Failed`フェーズを経由します。 +Podの実行中、kubeletはコンテナを再起動して、ある種の障害を処理できます。Pod内で、Kubernetesはさまざまなコンテナの[ステータス](#container-states)を追跡して、対処します。 +Kubernetes APIでは、Podには仕様と実際のステータスの両方があります。Podオブジェクトのステータスは、[PodのCondition](#pod-conditions)のセットで構成されます。[カスタムのReadiness情報](#pod-readiness-gate)をPodのConditionデータに挿入することもできます。 + +Podはその生存期間に1回だけ[スケジューリング](/docs/concepts/scheduling-eviction/)されます。PodがNodeにスケジュール(割り当て)されると、Podは停止または[終了](#pod-termination)するまでそのNode上で実行されます。 -## PodのPhase {#pod-phase} +## Podのライフタイム + +個々のアプリケーションコンテナと同様に、Podは(永続的ではなく)比較的短期間の存在と捉えられます。Podが作成されると、一意のID([UID](ja/docs/concepts/overview/working-with-objects/names/#uids))が割り当てられ、(再起動ポリシーに従って)終了または削除されるまでNodeで実行されるようにスケジュールされます。 +{{< glossary_tooltip term_id="node" >}}が停止した場合、そのNodeにスケジュールされたPodは、タイムアウト時間の経過後に[削除](#pod-garbage-collection)されます。 + +Pod自体は、自己修復しません。Podが{{< glossary_tooltip text="node" term_id="node" >}}にスケジュールされ、その後に失敗、またはスケジュール操作自体が失敗した場合、Podは削除されます。同様に、リソースの不足またはNodeのメンテナンスによりポッドはNodeから立ち退きます。Kubernetesは、比較的使い捨てのPodインスタンスの管理作業を処理する、{{< glossary_tooltip term_id="controller" text="controller" >}}と呼ばれる上位レベルの抽象化を使用します。 + +特定のPod(UIDで定義)は新しいNodeに`再スケジュール`されません。代わりに、必要に応じて同じ名前で、新しいUIDを持つ同一のPodに置き換えることができます。 + +{{< glossary_tooltip term_id="volume" text="volume" >}}など、Podと同じ存続期間を持つものがあると言われる場合、それは(そのUIDを持つ)Podが存在する限り存在することを意味します。そのPodが何らかの理由で削除された場合、たとえ同じ代替物が作成されたとしても、関連するもの(例えばボリューム)も同様に破壊されて再作成されます。 + +{{< figure src="/images/docs/pod.svg" title="Podの図" width="50%" >}} + +file puller(ファイル取得コンテナ)とWebサーバーを含むマルチコンテナのPod。コンテナ間の共有ストレージとして永続ボリュームを使用しています。 + + +## Podのフェーズ {#pod-phase} Podの`status`項目は[PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core)オブジェクトで、それは`phase`のフィールドがあります。 -Podのフェーズは、そのPodがライフサイクルのどの状態にあるかを、簡単かつ高レベルにまとめたものです。 -このフェーズはコンテナやPodの状態を包括的にまとめることを目的としたものではなく、また包括的なステートマシンでもありません。 +Podのフェーズは、そのPodがライフサイクルのどの状態にあるかを、簡単かつ高レベルにまとめたものです。このフェーズはコンテナやPodの状態を包括的にまとめることを目的としたものではなく、また包括的なステートマシンでもありません。 -Podの各フェーズの値と意味は厳重に守られています。 -ここに記載されているもの以外に`phase`の値は存在しないと思ってください。 +Podの各フェーズの値と意味は厳重に守られています。ここに記載されているもの以外に`phase`の値は存在しないと思ってください。 これらが`phase`の取りうる値です。 値 | 概要 :-----|:----------- -`Pending` | PodがKubernetesシステムによって承認されましたが、1つ以上のコンテナイメージが作成されていません。これには、スケジュールされるまでの時間と、ネットワーク経由でイメージをダウンロードするための時間などが含まれます。これには時間がかかることがあります。 +`Pending` | PodがKubernetesクラスターによって承認されましたが、1つ以上のコンテナがセットアップされて稼働する準備ができていません。これには、スケジュールされるまでの時間と、ネットワーク経由でイメージをダウンロードするための時間などが含まれます。 `Running` | PodがNodeにバインドされ、すべてのコンテナが作成されました。少なくとも1つのコンテナがまだ実行されているか、開始または再起動中です。 `Succeeded` |Pod内のすべてのコンテナが正常に終了し、再起動されません。 `Failed` | Pod内のすべてのコンテナが終了し、少なくとも1つのコンテナが異常終了しました。つまり、コンテナはゼロ以外のステータスで終了したか、システムによって終了されました。 -`Unknown` | 何らかの理由により、通常はPodのホストとの通信にエラーが発生したために、Podの状態を取得できませんでした。 +`Unknown` | 何らかの理由によりPodの状態を取得できませんでした。このフェーズは通常はPodのホストとの通信エラーにより発生します。 -## Podのconditions {#pod-conditions} - -PodにはPodStatusがあります。それはPodが成功したかどうかの情報を持つ[PodConditions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podcondition-v1-core)の配列です。 -PodCondition配列の各要素には、次の6つのフィールドがあります。 - -* `lastProbeTime` は、Pod Conditionが最後に確認されたときのタイムスタンプが表示されます。 - -* `lastTransitionTime` は、最後にPodのステータスの遷移があった際のタイムスタンプが表示されます。 - -* `message` は、ステータスの遷移に関する詳細を示す人間向けのメッセージです。 - -* `reason` は、最後の状態遷移の理由を示す、一意のキャメルケースでの単語です。 - -* `status` は`True`と`False`、`Unknown`のうちのどれかです。 - -* `type` 次の値を取る文字列です。 - - * `PodScheduled`: PodがNodeにスケジュールされました。 - * `Ready`: Podはリクエストを処理でき、一致するすべてのサービスの負荷分散プールに追加されます。 - * `Initialized`: すべての[Initコンテナ](/docs/concepts/workloads/pods/init-containers)が正常に実行されました。 - * `ContainersReady`: Pod内のすべてのコンテナが準備できた状態です。 - - -## コンテナのProbe {#container-probes} - -[Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core) は [kubelet](/docs/admin/kubelet/) により定期的に実行されるコンテナの診断です。 -診断を行うために、kubeletはコンテナに実装された [ハンドラー](https://godoc.org/k8s.io/kubernetes/pkg/api/v1#Handler)を呼びます。 -Handlerには次の3つの種類があります: - -* [ExecAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#execaction-v1-core): - コンテナ内で特定のコマンドを実行します。コマンドがステータス0で終了した場合に診断を成功と見まします。 - -* [TCPSocketAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#tcpsocketaction-v1-core): - コンテナのIPの特定のポートにTCPチェックを行います。 - そのポートが空いていれば診断を成功とみなします。 - -* [HTTPGetAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#httpgetaction-v1-core): - コンテナのIPの特定のポートとパスに対して、HTTP GETのリクエストを送信します。 - レスポンスのステータスコードが200以上400未満の際に診断を成功とみなします。 - -各Probe 次の3つのうちの一つの結果を持ちます: - -* Success: コンテナの診断が成功しました。 -* Failure: コンテナの診断が失敗しました。 -* Unknown: コンテナの診断が失敗し、取れるアクションがありません。 - -Kubeletは3種類のProbeを実行中のコンテナで行い、また反応することができます: - -* `livenessProbe`: コンテナが動いているかを示します。 - livenessProbe に失敗すると、kubeletはコンテナを殺します、そしてコンテナは[restart policy](#restart-policy)に従います。 - コンテナにlivenessProbeが設定されていない場合、デフォルトの状態は`Success`です。 - -* `readinessProbe`: コンテナがServiceのリクエストを受けることができるかを示します。 - readinessProbeに失敗すると、エンドポイントコントローラーにより、ServiceからそのPodのIPアドレスが削除されます。 - initial delay前のデフォルトのreadinessProbeの初期値は`Failure`です。 - コンテナにreadinessProbeが設定されていない場合、デフォルトの状態は`Success`です。 - -* `startupProbe`: コンテナ内のアプリケーションが起動したかどうかを示します。 - startupProbeが設定された場合、完了するまでその他のすべてのProbeは無効になります。 - startupProbeに失敗すると、kubeletはコンテナを殺します、そしてコンテナは[restart policy](#restart-policy)に従います。 - コンテナにstartupProbeが設定されていない場合、デフォルトの状態は`Success`です。 - -### livenessProbeをいつ使うべきか? {#when-should-you-use-a-liveness-probe} - -{{< feature-state for_k8s_version="v1.0" state="stable" >}} - -コンテナ自体に問題が発生した場合や状態が悪くなった際にクラッシュすることができれば -livenessProbeは不要です。この場合kubeletが自動でPodの`restartPolicy`に基づいたアクションを実行します。 - -Probeに失敗したときにコンテナを殺したり再起動させたりするには、 -livenessProbeを設定し`restartPolicy`をAlwaysまたはOnFailureにします。 - -### readinessProbeをいつ使うべきか? {#when-should-you-use-a-readiness-probe} - -{{< feature-state for_k8s_version="v1.0" state="stable" >}} - -Probeが成功したときにのみPodにトラフィックを送信したい場合は、readinessProbeを指定します。 -この場合readinessProbeはlivenessProbeと同じになる可能性がありますが、 -readinessProbeが存在するということは、Podがトラフィックを受けずに開始され、Probe成功が開始した後でトラフィックを受け始めることになります。 -コンテナが起動時に大きなデータ、構成ファイル、またはマイグレーションを読み込む必要がある場合は、readinessProbeを指定します。 - -コンテナがメンテナンスのために停止できるようにするには、 -livenessProbeとは異なる、特定のエンドポイントを確認するreadinessProbeを指定することができます。 - -Podが削除されたときにリクエストを来ないようにするためには必ずしもreadinessProbeが必要というわけではありません。 -Podの削除時にはreadinessProbeが存在するかどうかに関係なくPodは自動的に自身をunreadyにします。 -Pod内のコンテナが停止するのを待つ間Podはunreadyのままです。 - -### startupProbeをいつ使うべきか? {#when-should-you-use-a-startup-probe} - -{{< feature-state for_k8s_version="v1.16" state="alpha" >}} - -コンテナの起動時間が `initialDelaySeconds + failureThreshold × periodSeconds` よりも長い場合は、livenessProbeと同じエンドポイントをチェックするためにstartupProbeを指定します。 -`periodSeconds`のデフォルトは30秒です。 - -`failureThreshold` は、livenessProbeのデフォルト値を変更せずに、コンテナが起動するのに十分な値に設定します。これによりデッドロックを防ぐことができます。 - -livenessProbe、readinessProbeまたはstartupProbeを設定する方法の詳細については、 -[Configure Liveness, Readiness and Startup Probes](/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)を参照してください。 - -## Podとコンテナのステータス {#pod-and-container-status} - -PodとContainerのステータスについての詳細の情報は、それぞれ[PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core)と -[ContainerStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core)を参照してください。 -Podのステータスとして報告される情報は、現在の[ContainerState](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core)に依存しています。 +Nodeが停止するか、クラスタの残りの部分から切断された場合、Kubernetesは失われたNode上のすべてのPodの`Phase`をFailedに設定するためのポリシーを適用します。 ## コンテナのステータス {#container-states} -PodがスケジューラによってNodeに割り当てられると、 -kubeletはコンテナのランタイムを使用してコンテナの作成を開始します。 -コンテナの状態はWaiting、RunningまたはTerminatedの3ついずれかです。 -コンテナの状態を確認するには`kubectl describe pod [POD_NAME]`のコマンドを使用します。 -Pod内のコンテナごとにStateの項目として表示されます。 +Pod全体の[Phase](#pod-phase)と同様に、KubernetesはPod内の各コンテナの状態を追跡します。[container lifecycle hooks](/docs/concepts/containers/container-lifecycle-hooks/)を使用して、コンテナのライフサイクルの特定のポイントで実行するイベントをトリガーできます。 -* `Waiting`: コンテナのデフォルトの状態。コンテナがRunningまたはTerminatedのいずれの状態でもない場合コンテナはWaitingの状態になります。Waiting状態のコンテナは引き続きイメージを取得したりSecretsを適用したりするなど必要な操作を実行します。この状態に加えてメッセージに関する情報と状態に関する理由が表示されます。 +Podが{{< glossary_tooltip text="scheduler" term_id="kube-scheduler" >}}によってNodeに割り当てられると、kubeletは{{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}を使用してコンテナの作成を開始します。コンテナの状態は`Waiting`、`Running`または`Terminated`の3ついずれかです。 - ```yaml - ... - State: Waiting - Reason: ErrImagePull - ... - ``` +Podのコンテナの状態を確認するには`kubectl describe pod [POD_NAME]`のコマンドを使用します。Pod内のコンテナごとにStateの項目として表示されます。 -* `Running`: コンテナが問題なく実行されていることを示します。コンテナがRunning状態に入る前に`postStart`フック（もしあれば）が実行されます。この状態にはコンテナが実行中状態に入った時刻も表示されます。 +各状態の意味は次のとおりです。 - ```yaml - ... - State: Running - Started: Wed, 30 Jan 2019 16:46:38 +0530 - ... - ``` +### `Waiting` {#container-state-waiting} -* `Terminated`: コンテナの実行が完了しコンテナの実行が停止したことを示します。コンテナは実行が正常に完了したときまたは何らかの理由で失敗したときにこの状態になります。いずれにせよ理由と終了コード、コンテナの開始時刻と終了時刻が表示されます。コンテナがTerminatedに入る前に`preStop`フックがあれば実行されます。 +コンテナが`Running`または`Terminated`のいずれの状態でもない場合コンテナは`Waiting`の状態になります。Waiting状態のコンテナは引き続きコンテナイメージレジストリからイメージを取得したり{{< glossary_tooltip text="Secret" term_id="secret" >}}を適用したりするなど必要な操作を実行します。`Waiting`状態のコンテナを持つPodに対して`kubectl`コマンドを使用すると、そのコンテナが`Waiting`の状態である理由の要約が表示されます。 - ```yaml - ... - State: Terminated - Reason: Completed - Exit Code: 0 - Started: Wed, 30 Jan 2019 11:45:26 +0530 - Finished: Wed, 30 Jan 2019 11:45:26 +0530 - ... - ``` +### `Running` {#container-state-running} -## PodReadinessGate {#pod-readiness-gate} +`Running`状態はコンテナが問題なく実行されていることを示します。コンテナがRunning状態に入る前に`postStart`フック（もしあれば）が実行されます。`Running`状態のコンテナを持つPodに対して`kubectl`コマンドを使用すると、そのコンテナが`Running`状態になった時刻が表示されます。 + +### `Terminated` {#container-state-terminated} + +`Terminated`状態のコンテナは実行されて、完了したときまたは何らかの理由で失敗したことを示します。`Terminated`状態のコンテナを持つPodに対して`kubectl`コマンドを使用すると、いずれにせよ理由と終了コード、コンテナの開始時刻と終了時刻が表示されます。 + +コンテナがTerminatedに入る前に`preStop`フックがあれば実行されます。 + +## コンテナの再起動ポリシー {#restart-policy} + +Podの`spec`には、Always、OnFailure、またはNeverのいずれかの値を持つ`restartPolicy`フィールドがあります。デフォルト値はAlwaysです。 + +`restartPolicy`は、Pod内のすべてのコンテナに適用されます。`restartPolicy`は、同じNode上のkubeletによるコンテナの再起動のみを参照します。Pod内のコンテナが終了した後、kubeletは5分を上限とする指数バックオフ遅延（10秒、20秒、40秒...）でコンテナを再起動します。コンテナが10分間問題なく実行されると、kubeletはコンテナ―の再起動バックオフタイマーをリセットします。 + +## PodのCondition {#pod-conditions} + +PodにはPodStatusがあります。それはPodが成功したかどうかの情報を持つ[PodConditions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podcondition-v1-core)の配列です。 + +* `PodScheduled`: PodがNodeにスケジュールされました。 +* `ContainersReady`: Pod内のすべてのコンテナが準備できた状態です。 +* `Initialized`: すべての[Initコンテナ](/docs/concepts/workloads/pods/init-containers)が正常に実行されました。 +* `Ready`: Podはリクエストを処理でき、一致するすべてのサービスの負荷分散プールに追加されます。 + +フィールド名 | 内容 +:--------------------|:----------- +`type` | このPodの状態の名前です。 +`status` | その状態が適用可能かどうか示します。可能な値は"`True`"と"`False`"、"`Unknown`"のうちのいずれかです。 +`lastProbeTime` | Pod Conditionが最後に確認されたときのタイムスタンプが表示されます。 +`lastTransitionTime` | 最後にPodのステータスの遷移があった際のタイムスタンプが表示されます。 +`reason` | 最後の状態遷移の理由を示す、機械可読のアッパーキャメルケースのテキストです。 +`message` | ステータスの遷移に関する詳細を示す人間向けのメッセージです。 + +## PodのReadiness {#pod-readiness-gate} {{< feature-state for_k8s_version="v1.14" state="stable" >}} -追加のフィードバックやシグナルを`PodStatus`に注入できるようにしてPodのReadinessに拡張性を持たせるため、 -Kubernetes 1.11 では[Pod ready++](https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/0007-pod-ready%2B%2B.md)という機能が導入されました。 -`PodSpec`の新しいフィールド`ReadinessGate`を使用して、PodのRedinessを評価する追加の状態を指定できます。 -KubernetesがPodのstatus.conditionsフィールドでそのような状態を発見できない場合、 -ステータスはデフォルトで`False`になります。以下はその例です。 +追加のフィードバックやシグナルをPodStatus:_Pod readiness_に注入できるようにします。これを使用するには、Podの`spec`で`readinessGates`を設定して、kubeletがPodのReadinessを評価する追加の状態のリストを指定します。 + +ReadinessゲートはPodの`status.conditions`フィールドの現在の状態によって決まります。Kubernetesが`Podのstatus.conditions`フィールドでそのような状態を発見できない場合、ステータスはデフォルトで`False`になります。 + +以下はその例です。 ```yaml Kind: Pod @@ -209,130 +133,140 @@ status: ... ``` -新しいPod Conditionは、Kubernetesの[label key format](/ja/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set)に準拠している必要があります。 -`kubectl patch`コマンドはオブジェクトステータスのパッチ適用をまだサポートしていないので、 -新しいPod Conditionは[KubeClient libraries](/docs/reference/using-api/client-libraries/)のどれかを使用する必要があります。 +PodのConditionは、Kubernetesの[label key format](/ja/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set)に準拠している必要があります。 -新しいPod Conditionが導入されるとPodは次の両方の条件に当てはまる場合**のみ**準備できていると評価されます: +### PodのReadinessの状態 {#pod-readiness-status} + +`kubectl patch`コマンドはオブジェクトステータスのパッチ適用をまだサポートしていません。Podにこれらの`status.conditions`を設定するには、アプリケーションと{{< glossary_tooltip term_id="operator-pattern" text="operators">}}は`PATCH`アクションを使用する必要があります。[Kubernetes client library](/docs/reference/using-api/client-libraries/)を使用して、PodのReadinessのためにカスタムのPodのConditionを設定するコードを記述できます。 + +カスタムのPodのConditionが導入されるとPodは次の両方の条件に当てはまる場合**のみ**準備できていると評価されます: * Pod内のすべてのコンテナが準備完了している。 * `ReadinessGates`で指定された条件が全て`True`である。 -PodのReadinessの評価へのこの変更を容易にするために、新しいPod Conditionである`ContainersReady`が導入され、古いPodの`Ready`条件を取得します。 +Podのコンテナは準備完了ですが、少なくとも1つのカスタムのConditionが欠落しているか「False」の場合、kubeletはPodの[Condition](#pod-condition)を`ContainersReady`に設定します。 -## RestartPolicy {#restart-policy} +## コンテナのProbe {#container-probes} -PodSpecには、Always、OnFailure、またはNeverのいずれかの値を持つ`restartPolicy`フィールドがあります。 -デフォルト値はAlwaysです。`restartPolicy`は、Pod内のすべてのコンテナに適用されます。 -`restartPolicy`は、同じNode上のkubeletによるコンテナの再起動のみを参照します。 -kubeletによって再起動される終了したコンテナは、5分後にキャップされた指数バックオフ遅延（10秒、20秒、40秒...）で再起動され、10分間の実行後にリセットされます。[Pods document](/docs/user-guide/pods/#durability-of-pods-or-lack-thereof)に書かれているように、一度NodeにバインドされるとPodは別のポートにバインドされ直すことはありません。 +[Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core) は [kubelet](/docs/admin/kubelet/) により定期的に実行されるコンテナの診断です。診断を行うために、kubeletはコンテナに実装された [ハンドラー](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#handler-v1-core)を呼びます。Handlerには次の3つの種類があります: -## Podのライフタイム {#pod-lifetime} +* [ExecAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#execaction-v1-core): + コンテナ内で特定のコマンドを実行します。コマンドがステータス0で終了した場合に診断を成功と見まします。 -一般にPodは人間またはコントローラーが明示的に削除するまで存在します。 -コントロールプレーンは終了状態のPod(SucceededまたはFailedの`phase`を持つ)の数が設定された閾値（kube-controller-manager内の`terminated-pod-gc-threshold`によって定義される）を超えたとき、それらのPodを削除します。 -これはPodが作成されて時間とともに終了するため、リソースリークを避けます。 +* [TCPSocketAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#tcpsocketaction-v1-core): + PodのIPの特定のポートにTCPチェックを行います。 + そのポートが空いていれば診断を成功とみなします。 -次の3種類のコントローラがあります。 +* [HTTPGetAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#httpgetaction-v1-core): + PodのIPの特定のポートとパスに対して、HTTP GETのリクエストを送信します。 + レスポンスのステータスコードが200以上400未満の際に診断を成功とみなします。 -- バッチ計算などのように終了が予想されるPodに対しては、[Job](/docs/concepts/jobs/run-to-completion-finite-workloads/)を使用します。 - Jobは`restartPolicy`がOnFailureまたはNeverになるPodに対してのみ適切です。 +各Probe 次の3つのうちの一つの結果を持ちます: -- 停止することを期待しないPod（たとえばWebサーバーなど）には、[ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/)、[ReplicaSet](/ja/docs/concepts/workloads/controllers/replicaset/)、または[Deployment](/ja/docs/concepts/workloads/controllers/deployment/)を使用します。ReplicationControllerは`restartPolicy`がAlwaysのPodに対してのみ適切です。 +* `Success`: コンテナの診断が成功しました。 +* `Failure`: コンテナの診断が失敗しました。 +* `Unknown`: コンテナの診断が失敗し、取れるアクションがありません。 -- マシン固有のシステムサービスを提供するため、マシンごとに1つずつ実行する必要があるPodには[DaemonSet](/ja/docs/concepts/workloads/controllers/daemonset/)を使用します。 +Kubeletは3種類のProbeを実行中のコンテナで行い、また反応することができます: -3種類のコントローラにはすべてPodTemplateが含まれます。 -Podを自分で直接作成するのではなく適切なコントローラを作成してPodを作成させることをおすすめします。 -これはPod単独ではマシンの障害に対して回復力がないためです。コントローラにはこの機能があります。 +* `livenessProbe`: コンテナが動いているかを示します。 + livenessProbe に失敗すると、kubeletはコンテナを殺します、そしてコンテナは[restart policy](#restart-policy)に従います。 + コンテナにlivenessProbeが設定されていない場合、デフォルトの状態は`Success`です。 -Nodeが停止したりクラスタの他のNodeから切断された場合、 -Kubernetesは失われたノード上のすべてのPodの`phase`をFailedに設定するためのポリシーを適用します。 +* `readinessProbe`: コンテナがリクエスト応答する準備ができているかを示します。 + readinessProbeに失敗すると、エンドポイントコントローラーにより、ServiceからそのPodのIPアドレスが削除されます。 + initial delay前のデフォルトのreadinessProbeの初期値は`Failure`です。 + コンテナにreadinessProbeが設定されていない場合、デフォルトの状態は`Success`です。 -## 例 +* `startupProbe`: コンテナ内のアプリケーションが起動したかどうかを示します。 + startupProbeが設定された場合、完了するまでその他のすべてのProbeは無効になります。 + startupProbeに失敗すると、kubeletはコンテナを殺します、そしてコンテナは[restart policy](#restart-policy)に従います。 + コンテナにstartupProbeが設定されていない場合、デフォルトの状態は`Success`です。 -### 高度なliveness probeの例 +livenessProbe、readinessProbeまたはstartupProbeを設定する方法の詳細については、[Liveness Probe、Readiness ProbeおよびStartup Probeを使用する](/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)を参照してください。 -Liveness Probeはkubeletによって実行されるため、 -すべてのリクエストはkubeletネットワークのnamespaceで行われます。 +### livenessProbeをいつ使うべきか? {#when-should-you-use-a-liveness-probe} -```yaml -apiVersion: v1 -kind: Pod -metadata: - labels: - test: liveness - name: liveness-http -spec: - containers: - - args: - - /server - image: k8s.gcr.io/liveness - livenessProbe: - httpGet: - # "host" が定義されていない場合、"PodIP"が使用されます - # host: my-host - # "scheme"が定義されていない場合、HTTPスキームが使用されます。"HTTP"と"HTTPS"のみ - # scheme: HTTPS - path: /healthz - port: 8080 - httpHeaders: - - name: X-Custom-Header - value: Awesome - initialDelaySeconds: 15 - timeoutSeconds: 1 - name: liveness -``` +{{< feature-state for_k8s_version="v1.0" state="stable" >}} -### statesの例 +コンテナ自体に問題が発生した場合や状態が悪くなった際にクラッシュすることができればlivenessProbeは不要です. +この場合kubeletが自動でPodの`restartPolicy`に基づいたアクションを実行します。 - * Podが実行中でそのPodには1つのコンテナがあります。コンテナは正常終了しました。 - * 完了のイベントを記録します。 - * `restartPolicy`が、 - * Always: コンテナを再起動します。Podの`phase`はRunningのままです。 - * OnFailure: Podの`phase`はSucceededになります。 - * Never: Podの`phase`はSucceededになります。 +Probeに失敗したときにコンテナを殺したり再起動させたりするには、livenessProbeを設定し`restartPolicy`をAlwaysまたはOnFailureにします。 - * Podが実行中でそのPodには1つのコンテナがあります。コンテナは失敗終了しました。 - * 失敗イベントを記録します。 - * `restartPolicy`が、 - * Always: コンテナを再起動します。Podの`phase`はRunningのままです。 - * OnFailure: コンテナを再起動します。Podの`phase`はRunningのままです。 - * Never: Podの`phase`はFailedになります。 +### readinessProbeをいつ使うべきか? {#when-should-you-use-a-readiness-probe} - * Podが実行中で、その中には2つのコンテナがあります。コンテナ1は失敗終了しました。 - * 失敗イベントを記録します。 - * `restartPolicy`が、 - * Always: コンテナを再起動します。Podの`phase`はRunningのままです。 - * OnFailure: コンテナを再起動します。Podの`phase`はRunningのままです。 - * Never: コンテナを再起動しません。Podの`phase`はRunningのままです。 - * コンテナ1が死んでいてコンテナ2は動いている場合 - * 失敗イベントを記録します。 - * `restartPolicy`が、 - * Always: コンテナを再起動します。Podの`phase`はRunningのままです。 - * OnFailure: コンテナを再起動します。Podの`phase`はRunningのままです。 - * Never: Podの`phase`はFailedになります。 +{{< feature-state for_k8s_version="v1.0" state="stable" >}} - * Podが実行中でそのPodには1つのコンテナがあります。コンテナはメモリーを使い果たしました。 - * コンテナは失敗で終了します。 - * OOMイベントを記録します。 - * `restartPolicy`が、 - * Always: コンテナを再起動します。Podの`phase`はRunningのままです。 - * OnFailure: コンテナを再起動します。Podの`phase`はRunningのままです。 - * Never: 失敗イベントを記録します。Podの`phase`はFailedになります。 +Probeが成功したときにのみPodにトラフィックを送信したい場合は、readinessProbeを指定します。 +この場合readinessProbeはlivenessProbeと同じになる可能性がありますが、readinessProbeが存在するということは、Podがトラフィックを受けずに開始され、Probe成功が開始した後でトラフィックを受け始めることになります。コンテナが起動時に大きなデータ、構成ファイル、またはマイグレーションを読み込む必要がある場合は、readinessProbeを指定します。 - * Podが実行中ですがディスクは死んでいます。 - * すべてのコンテナを殺します。 - * 適切なイベントを記録します。 - * Podの`phase`はFailedになります。 - * Podがコントローラで作成されていた場合は、別の場所で再作成されます。 +コンテナがメンテナンスのために停止できるようにするには、livenessProbeとは異なる、特定のエンドポイントを確認するreadinessProbeを指定することができます。 - * Podが実行中ですがNodeが切り離されました。 - * Nodeコントローラがタイムアウトを待ちます。 - * NodeコントローラがPodの`phase`をFailedにします。 - * Podがコントローラで作成されていた場合は、別の場所で再作成されます。 +{{< note >}} +Podが削除されたときにリクエストを来ないようにするためには必ずしもreadinessProbeが必要というわけではありません。Podの削除時にはreadinessProbeが存在するかどうかに関係なくPodは自動的に自身をunreadyにします。Pod内のコンテナが停止するのを待つ間Podはunreadyのままです。 +{{< /note >}} + +### startupProbeをいつ使うべきか? {#when-should-you-use-a-startup-probe} + +{{< feature-state for_k8s_version="v1.16" state="alpha" >}} + +startupProbeは、サービスの開始に時間がかかるコンテナを持つポッドに役立ちます。livenessProbeの間隔を長く設定するのではなく、コンテナの起動時に別のProbeを構成して、livenessProbeの間隔よりも長い時間を許可できます。 +i +コンテナの起動時間が、`initialDelaySeconds + failureThreshold x periodSeconds`よりも長い場合は、livenessProbeと同じエンドポイントをチェックするためにstartupProbeを指定します。`periodSeconds`のデフォルトは30秒です。次に、`failureThreshold`をlivenessProbeのデフォルト値を変更せずにコンテナが起動できるように、十分に高い値を設定します。これによりデッドロックを防ぐことができます。 + +## Podの終了 {#pod-termination} + +Podは、クラスター内のNodeで実行中のプロセスを表すため、不要になったときにそれらのプロセスを正常に終了できるようにすることが重要です(対照的なケースは、KILLシグナルで強制終了され、クリーンアップする機会がない場合)。 + +ユーザーは削除を要求可能であるべきで、プロセスがいつ終了するかを知ることができなければなりませんが、削除が最終的に完了することも保証できるべきです。ユーザーがPodの削除を要求すると、システムはPodが強制終了される前に意図された猶予期間を記録および追跡します。強制削除までの猶予期間がある場合、{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}正常な終了を試みます。 + +通常、コンテナランタイムは各コンテナのメインプロセスにTERMシグナルを送信します。猶予期間が終了すると、プロセスにKILLシグナルが送信され、Podは{{< glossary_tooltip text="API Server" term_id="kube-apiserver" >}}から削除されます。プロセスの終了を待っている間にkubeletかコンテナランタイムの管理サービスが再起動されると、クラスターは元の猶予期間を含めて、最初からリトライされます。 + +フローの例は下のようになります。 + +1. ユーザーがデフォルトの猶予期間(30秒)でPodを削除するために`kubectl`コマンドを送信する。 +1. API server内のPodは、猶予期間を越えるとPodが「死んでいる」と見なされるように更新される。 + 削除中のPodに対して`kubectl describe`コマンドを使用すると、Podは「終了中」と表示される。 + Podが実行されているNode上で、Podが終了しているとマークされている(正常な終了期間が設定されている)とkubeletが認識するとすぐに、kubeletはローカルでPodの終了プロセスを開始します。 + 1. Pod内のコンテナの1つが`preStop`[フック](/docs/concepts/containers/container-lifecycle-hooks/#hook-details)を定義している場合は、コンテナの内側で呼び出される。猶予期間が終了した後も `preStop`フックがまだ実行されている場合は、一度だけ猶予期間を延長される(2秒)。 + {{< note >}} + `preStop`フックが完了するまでにより長い時間が必要な場合は、`terminationGracePeriodSeconds`を変更する必要があります。 + {{< /note >}} + 1. kubeletはコンテナランタイムをトリガーして、コンテナ内のプロセス番号1にTERMシグナルを送信する。 + {{< note >}} + Pod内のすべてのコンテナが同時にTERMシグナルを受信するわけではなく、シャットダウンの順序が問題になる場合はそれぞれに`preStop`フックを使用して同期することを検討する。 + {{< /note >}} +1. kubeletが正常な終了を開始すると同時に、コントロールプレーンは、終了中のPodをEndpoints(および有効な場合はEndpointSlice)オブジェクトから削除します。これらのオブジェクトは、{{< glossary_tooltip text="selector" term_id="selector" >}}が設定された{{< glossary_tooltip term_id="service" text="Service" >}}を表します。{{< glossary_tooltip text="ReplicaSets" term_id="replica-set" >}}とその他のワークロードリソースは、終了中のPodを有効なサービス中のReplicaSetとして扱いません。ゆっくりと終了するPodは、(サービスプロキシのような)ロードバランサーが終了猶予期間が_始まる_とエンドポイントからそれらのPodを削除するので、トラフィックを継続して処理できません。 +1. 猶予期間が終了すると、kubeletは強制削除を開始する。コンテナランタイムは、Pod内でまだ実行中のプロセスに`SIGKILL`を送信する。kubeletは、コンテナランタイムが非表示の`pause`コンテナを使用している場合、そのコンテナをクリーンアップします。 +1. kubeletは猶予期間を0(即時削除)に設定することでAPI server上のPodの削除を終了する。 +1. API serverはPodのAPIオブジェクトを削除し、クライアントからは見えなくなります。 +### Podの強制削除 {#pod-termination-forced} + +{{< caution >}} +強制削除は、Podによっては潜在的に危険な場合があるため、慎重に実行する必要があります。 +{{< /caution >}} + +デフォルトでは、すべての削除は30秒以内に正常に行われます。`kubectl delete` コマンドは、ユーザーがデフォルト値を上書きして独自の値を指定できるようにする `--grace-period=` オプションをサポートします。 + +`--grace-period`を`0`に設定した場合、PodはAPI serverから即座に強制的に削除されます。PodがNode上でまだ実行されている場合、その強制削除によりkubeletがトリガーされ、すぐにクリーンアップが開始されます。 + +{{< note >}} +強制削除を実行するために `--grace-period=0` と共に `--force` というフラグを追加で指定する必要があります。 +{{< /note >}} + +強制削除が実行されると、API serverは、Podが実行されていたNode上でPodが停止されたというkubeletからの確認を待ちません。API内のPodは直ちに削除されるため、新しいPodを同じ名前で作成できるようになります。Node上では、すぐに終了するように設定されるPodは、強制終了される前にわずかな猶予期間が与えられます。 + +StatefulSetのPodについては、[StatefulSetからPodを削除するためのタスクのドキュメント](/ja/docs/tasks/run-application/force-delete-stateful-set-pod/)を参照してください。 + + +### 失敗したPodのガベージコレクション {#pod-garbage-collection} + +失敗したPodは人間または{{< glossary_tooltip term_id="controller" text="controller" >}}が明示的に削除するまで存在します。 + +コントロールプレーンは終了状態のPod(SucceededまたはFailedの`phase`を持つ)の数が設定された閾値(kube-controller-manager内の`terminated-pod-gc-threshold`によって定義される)を超えたとき、それらのPodを削除します。これはPodが作成されて時間とともに終了するため、リソースリークを避けます。 ## {{% heading "whatsnext" %}} @@ -344,4 +278,4 @@ spec: * [Container lifecycle hooks](/docs/concepts/containers/container-lifecycle-hooks/)についてもっと学ぶ - +* APIのPod/コンテナステータスの詳細情報は[PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core)および[ContainerStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core)を参照してください From f180a79342fa3ab9dd4c9a14908d510d6333e423 Mon Sep 17 00:00:00 2001 From: Jin Hase Date: Thu, 10 Sep 2020 17:22:41 +0900 Subject: [PATCH 198/252] Delete Japanese doc concepts/workloads/pods/pod.md --- .../ja/docs/concepts/workloads/pods/pod.md | 188 ------------------ 1 file changed, 188 deletions(-) delete mode 100644 content/ja/docs/concepts/workloads/pods/pod.md diff --git a/content/ja/docs/concepts/workloads/pods/pod.md b/content/ja/docs/concepts/workloads/pods/pod.md deleted file mode 100644 index fbb003c21b..0000000000 --- a/content/ja/docs/concepts/workloads/pods/pod.md +++ /dev/null @@ -1,188 +0,0 @@ ---- -reviewers: -title: Pod -content_type: concept -weight: 20 ---- - - - -_Pod_ は、Kubernetesで作成および管理できる、デプロイ可能な最小のコンピューティング単位です。 - - - - - - -## Podとは - -_Pod_ は(クジラの小群やエンドウ豆のさやのように)、共有のストレージ/ネットワークを持つ1つ以上のコンテナ(例えばDockerコンテナ)、およびコンテナを実行する方法についての仕様です。Pod内のコンテナ群は常に同じ場所に配置され、協調してスケジューリングされ、共通のコンテキストで実行されます。Podは、アプリケーション固有の「論理ホスト」――やや密に結合した1つ以上のアプリケーション・コンテナを含むもの――をモデル化します。コンテナ以前の世界では、同じ物理または仮想マシン上で実行されることが、同じ論理ホスト上で実行されることを意味するでしょう。 - -Kubernetesは、Dockerだけでなくより多くのコンテナ・ランタイムをサポートしていますが、Dockerは最もよく知られているランタイムであり、Dockerの用語を使ってPodを説明することが可能です。 - -Pod内では、Linux namespaceやcgroupなどのDockerコンテナを分離する一連の要素と同じものがコンテキストとして共有されます。 -Podのコンテキスト内で、個々のアプリケーションに更なる分離が適用されることがあります。 - -Pod内のコンテナはIPアドレスとポートの空間を共有し、 `localhost` を通じてお互いを見つけることができます 。 -また、SystemVセマフォやPOSIX共有メモリなどの標準のプロセス間通信(IPC)を使用して互いに通信することもできます。 -異なるPodのコンテナは異なるIPアドレスを持ち、[特別な設定](/docs/concepts/policy/pod-security-policy/)がなければIPCでは通信できません。 -これらのコンテナは通常、Pod IPアドレスを介して互いに通信します。 - -Pod内のアプリケーションからアクセスできる共有ボリュームを、Podの一部として定義できます。 -このボリュームは個々のアプリケーションのファイルシステムにマウント可能です。 - -[Docker](https://www.docker.com/)の用語でいえば、Podは共有namespaceと共有[ボリューム](/docs/concepts/storage/volumes/)を持つDockerコンテナのグループとしてモデル化されています。 - -個々のアプリケーションコンテナと同様に、Podは(永続的ではなく)比較的短期間の存在と捉えられます。 -[Podのライフサイクル](/ja/docs/concepts/workloads/pods/pod-lifecycle/)で説明しているように、Podが作成されると、一意のID(UID)が割り当てられ、(再起動ポリシーに従って)終了または削除されるまでNodeで実行されるようにスケジュールされます。 -Nodeが停止した場合、そのNodeにスケジュールされたPodは、タイムアウト時間の経過後に削除されます。 -特定のPod(UIDで定義)は新しいNodeに「再スケジュール」されません。 -代わりに、必要に応じて同じ名前で、新しいUIDを持つ同一のPodに置き換えることができます(詳細については[ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/)を参照してください)。 - -ボリュームなど、Podと同じ存続期間を持つものがあると言われる場合、それは(そのUIDを持つ)Podが存在する限り存在することを意味します。 -そのPodが何らかの理由で削除された場合、たとえ同じ代替物が作成されたとしても、関連するもの(例えばボリューム)も同様に破壊されて再作成されます。 - -{{< figure src="/images/docs/pod.svg" title="Podの図" width="50%" >}} - -*file puller(ファイル取得コンテナ)とWebサーバーを含むマルチコンテナのPod。コンテナ間の共有ストレージとして永続ボリュームを使用している。* - -## Podを用いる動機 - -### 管理 - -Podは、まとまったサービスの単位を形成する複数の協調プロセスのパターンをモデル化したものです。 -構成要素であるアプリケーションの集まりよりも高いレベルの抽象化を提供することによって、アプリケーションのデプロイと管理を単純化します。 -Podは、デプロイや水平スケーリング、レプリケーションの単位として機能します。 -Pod内のコンテナに対しては、同じ場所への配置(共同スケジューリング)、命運の共有(つまり停止)、協調レプリケーション、リソース共有や依存関係の管理が自動的に取り扱われます。 - -### リソース共有と通信 - -Podは、構成要素間でのデータ共有および通信を可能にします。 - -Pod内のアプリケーションはすべて同じネットワーク名前空間(同じIPおよびポートスペース)を使用するため、 `localhost` としてお互いを「見つけて」通信できます。 -このため、Pod内のアプリケーションはそれぞれ使用するポートを調整する必要があります。 -各Podは、他の物理コンピュータやPodと自由に通信するためのフラットな共有ネットワーク空間上にIPアドレスを持ちます。 - -Pod内のアプリケーションコンテナのホスト名には、Podの名前が設定されます。 -詳細は[クラスターネットワーク](/docs/concepts/cluster-administration/networking/)をご覧ください。 - -Podで実行されるアプリケーションコンテナの定義に加えて、Podによって共有ストレージであるボリュームを複数設定することも可能です。 -ボリュームを使用すると、データはコンテナの再起動後も存続し、Pod内のアプリケーション間で共有できます。 - -## Podの用途 - -Podは、垂直に統合されたアプリケーションスタック(例:LAMP)をホストするために使用できます。 -しかし、Podを使う主な動機は、次のように同じ場所に配置され、共に管理されるヘルパープログラムをサポートすることです。 - -* コンテンツ管理システム(CMS)、ファイルやデータのローダー、ローカルのキャッシュマネージャーなど -* ログとチェックポイントのバックアップ、圧縮、ローテーション、スナップショットなど -* データの変更を監視するもの、ログをtailするもの、ロギングおよび監視の補助プログラム、イベントを発行するものなど -* プロキシ、ブリッジ、およびアダプタ -* コントローラー、マネージャー、コンフィギュレーター、およびアップデーター - -個々のPodは、一般に、同じアプリケーションの複数のインスタンスを実行することを目的としていません。 - -詳細については、[The Distributed System ToolKit: Patterns for -Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)(分散システムツールキット：複合コンテナのパターン)を参照してください。 - -## 考えられる代替案 - -_単一の(Docker)コンテナで複数のプログラムを実行しないのはなぜですか？_ - -1. 透明性のため。Pod内のコンテナをインフラストラクチャから見えるようにすることで、インフラストラクチャはプロセス管理やリソース監視などのサービスをコンテナに提供できます。 -これは、ユーザーに多くの便益を提供します。 -1. ソフトウェアの依存関係を減らすため。 -個々のコンテナは、独立してバージョン管理、再構築、および再デプロイできます。 -Kubernetesはいつか個々のコンテナのライブアップデートをサポートするかもしれません。 -1. 使いやすさのため。ユーザーは独自のプロセスマネージャーを実行する必要はありません。シグナルや終了コードの伝播などについて心配する必要はありません。 -1. 効率のため。インフラストラクチャがより責任を負うため、コンテナはより軽量になります。 - -_アフィニティ(結合性、親和性)ベースのコンテナの共同スケジューリングをサポートしないのはなぜですか？_ - -このアプローチによって、コンテナの共同配置は提供されるでしょう。 -しかし、リソース共有やIPC、保証された命運の共有、および簡素化された管理といったPodの利点のほとんどは提供されないでしょう。 - - -## Podの耐久性(またはその欠如) {#pod-durability} - -Podは、耐久性のある存在として扱われることを意図していません。 -スケジューリングの失敗や、Nodeの故障には耐えられません。 -リソースの不足やNodeのメンテナンスといった場合に、追い出されて停止することもあり得ます。 - -一般に、ユーザーはPodを直接作成する必要はありません。 -ほとんどの場合、対象がシングルトンであったとしても、[Deployments](/ja/docs/concepts/workloads/controllers/deployment/)などのコントローラーを使用するべきです。 -コントローラーは、レプリケーションとロールアウト管理だけでなく、クラスターレベルの自己修復機能も提供します。 -[StatefulSet](/ja/docs/concepts/workloads/controllers/statefulset.md)ようなコントローラーもステートフルなPodをサポートします。 - -主要なユーザー向けのプリミティブとして集合APIを使用することは、[Borg](https://research.google.com/pubs/pub43438.html)、 [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html)、[Aurora](http://aurora.apache.org/documentation/latest/reference/configuration/#job-schema)、[Tupperware](http://www.slideshare.net/Docker/aravindnarayanan-facebook140613153626phpapp02-37588997)などのクラスタースケジューリングシステムで比較的一般的です。 - -Podは、以下のことを容易にするためにプリミティブとして公開されています。 - -* スケジューラーとコントローラーをプラガブルにする -* コントローラーAPIを介して「プロキシ」の必要なしに、Podレベルの操作をサポートする -* ブートストラップなどのために、コントローラーの寿命からPodの寿命を切り離す -* コントローラーとサービスを分離する――エンドポイントコントローラーはPodのみを監視する -* Kubeletレベルの機能とクラスターレベルの機能をきれいに組み合わせる――Kubeletは事実上「Podコントローラー」となる -* アプリケーションの可用性を高める。 -即ち、計画的な追い出しやイメージのプリフェッチなどの場合に、Podが停止し削除される前に、必ず事前に入れ換えられることを期待する - -## Podの終了 {#termination-of-pods} - -Podは、クラスター内のNodeで実行中のプロセスを表すため、不要になったときにそれらのプロセスを正常に終了できるようにすることが重要です(対照的なケースは、KILLシグナルで強制終了され、クリーンアップする機会がない場合)。 -ユーザーは削除を要求可能であるべきで、プロセスがいつ終了するかを知ることができなければなりませんが、削除が最終的に完了することも保証できるべきです。 -ユーザーがPodの削除を要求すると、システムはPodが強制終了される前に意図された猶予期間を記録し、各コンテナのメインプロセスにTERMシグナルが送信されます。 -猶予期間が終了すると、プロセスにKILLシグナルが送信され、PodはAPIサーバーから削除されます。 -プロセスの終了を待っている間にKubeletかコンテナマネージャーが再起動されると、終了処理は猶予期間の後にリトライされます。 - -フローの例は下のようになります。 - -1. ユーザーがデフォルトの猶予期間(30秒)でPodを削除するコマンドを送信する -1. APIサーバー内のPodは、猶予期間を越えるとPodが「死んでいる」と見なされるように更新される -1. クライアントのコマンドに表示されたとき、Podは「終了中」と表示される -1. (3と同時に)Kubeletは、2の期間が設定されたためにPodが終了中となったことを認識すると、Podのシャットダウン処理を開始する - 1. Pod内のコンテナの1つが[preStopフック](/docs/concepts/containers/container-lifecycle-hooks/#hook-details)を定義している場合は、コンテナの内側で呼び出される。 - 猶予期間が終了した後も `preStop`フックがまだ実行されている場合は、一度だけ猶予期間を延長して(2秒)、ステップ2が呼び出される。`preStop`フックが完了するまでにより長い時間が必要な場合は、`terminationGracePeriodSeconds`を変更する必要がある。 - 1. コンテナにTERMシグナルが送信される。Pod内のすべてのコンテナが同時にTERMシグナルを受信するわけではなく、シャットダウンの順序が問題になる場合はそれぞれに `preStop` フックが必要になることがある -1. (3と同時に)Podはサービスを提供するエンドポイントのリストから削除され、ReplicationControllerの実行中のPodの一部とは見なされなくなる。 -ゆっくりとシャットダウンするPodは、(サービスプロキシのような)ロードバランサーがローテーションからそれらを削除するので、トラフィックを処理し続けることはできない -1. 猶予期間が終了すると、Pod内でまだ実行中のプロセスはSIGKILLで強制終了される -1. Kubeletは猶予期間を0(即時削除)に設定することでAPIサーバー上のPodの削除を終了する。 -PodはAPIから消え、クライアントからは見えなくなる - -デフォルトでは、すべての削除は30秒以内に正常に行われます。 -`kubectl delete` コマンドは、ユーザーがデフォルト値を上書きして独自の値を指定できるようにする `--grace-period=` オプションをサポートします。 -値 `0` はPodを[強制的に削除](/ja/docs/concepts/workloads/pods/pod/#podの強制削除)します。 -kubectlのバージョン1.5以降では、強制削除を実行するために `--grace-period=0` と共に `--force` というフラグを追加で指定する必要があります。 - -### Podの強制削除 - -Podの強制削除は、クラスターの状態やetcdからPodを直ちに削除することと定義されます。 -強制削除が実行されると、API serverは、Podが実行されていたNode上でPodが停止されたというkubeletからの確認を待ちません。 -API内のPodは直ちに削除されるため、新しいPodを同じ名前で作成できるようになります。 -Node上では、すぐに終了するように設定されるPodは、強制終了される前にわずかな猶予期間が与えられます。 - -強制削除は、Podによっては潜在的に危険な場合があるため、慎重に実行する必要があります。 -StatefulSetのPodについては、[StatefulSetからPodを削除するためのタスクのドキュメント](/ja/docs/tasks/run-application/force-delete-stateful-set-pod/)を参照してください。 - -## Podコンテナの特権モード {#privileged-mode-for-pod-containers} - -Kubernetes v1.1以降、Pod内のどのコンテナでも、コンテナ仕様の `SecurityContext` の `privileged ` フラグを使用して特権モードを有効にできます。 -これは、ネットワークスタックの操作やデバイスへのアクセスなど、Linuxの機能を使用したいコンテナにとって役立ちます。 -コンテナ内のプロセスは、コンテナ外のプロセスで利用できるものとほぼ同じ特権を獲得します。 -特権モードでは、ネットワークプラグインとボリュームプラグインを別々のPodとして作成する方が簡単なはずです。それらをkubeletにコンパイルする必要はありません。 - -マスターがKubernetes v1.1以降を実行しており、Nodeがv1.1より前のバージョンを実行している場合、新しい特権付きのPodはAPIサーバーに受け入れられますが、起動されません。 -それらは保留状態になります。 -ユーザーが `kubectl describe pod FooPodName` を実行すると、Podが保留状態になっている理由を確認できます。 -describeコマンド出力のイベントテーブルには、次のように表示されます。 -`Error validating pod "FooPodName"."FooPodNamespace" from api, ignoring: spec.containers[0].securityContext.privileged: forbidden '<*>(0xc2089d3248)true'` - -マスターがv1.1より前のバージョンを実行している場合、特権を持つPodは作成できません。 -ユーザーが特権付きのコンテナを含むPodを作成しようとすると、次のエラーを受け取ります。 -`The Pod "FooPodName" is invalid. -spec.containers[0].securityContext.privileged: forbidden '<*>(0xc20b222db0)true'` - -## APIオブジェクト - -PodはKubernetes REST APIのトップレベルのリソースです。 -APIオブジェクトの詳細については、[Pod APIオブジェクト](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)を参照してください 。 From 52a6943fee14453de588710cd54241ddc20a0d35 Mon Sep 17 00:00:00 2001 From: Jin Hase Date: Thu, 10 Sep 2020 17:40:46 +0900 Subject: [PATCH 199/252] Update pod-lifecycle.md --- content/ja/docs/concepts/workloads/pods/pod-lifecycle.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md b/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md index aeaa355722..84b4397990 100644 --- a/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md @@ -24,13 +24,13 @@ Podはその生存期間に1回だけ[スケジューリング](/docs/concepts/s Pod自体は、自己修復しません。Podが{{< glossary_tooltip text="node" term_id="node" >}}にスケジュールされ、その後に失敗、またはスケジュール操作自体が失敗した場合、Podは削除されます。同様に、リソースの不足またはNodeのメンテナンスによりポッドはNodeから立ち退きます。Kubernetesは、比較的使い捨てのPodインスタンスの管理作業を処理する、{{< glossary_tooltip term_id="controller" text="controller" >}}と呼ばれる上位レベルの抽象化を使用します。 -特定のPod(UIDで定義)は新しいNodeに`再スケジュール`されません。代わりに、必要に応じて同じ名前で、新しいUIDを持つ同一のPodに置き換えることができます。 +特定のPod(UIDで定義)は新しいNodeに"再スケジュール"されません。代わりに、必要に応じて同じ名前で、新しいUIDを持つ同一のPodに置き換えることができます。 {{< glossary_tooltip term_id="volume" text="volume" >}}など、Podと同じ存続期間を持つものがあると言われる場合、それは(そのUIDを持つ)Podが存在する限り存在することを意味します。そのPodが何らかの理由で削除された場合、たとえ同じ代替物が作成されたとしても、関連するもの(例えばボリューム)も同様に破壊されて再作成されます。 {{< figure src="/images/docs/pod.svg" title="Podの図" width="50%" >}} -file puller(ファイル取得コンテナ)とWebサーバーを含むマルチコンテナのPod。コンテナ間の共有ストレージとして永続ボリュームを使用しています。 +*file puller(ファイル取得コンテナ)とWebサーバーを含むマルチコンテナのPod。コンテナ間の共有ストレージとして永続ボリュームを使用しています。* ## Podのフェーズ {#pod-phase} From 295ca64c4093aca8b49ae30d8ecea35311d20695 Mon Sep 17 00:00:00 2001 From: Jin Hase Date: Mon, 28 Sep 2020 11:18:43 +0900 Subject: [PATCH 200/252] Update content/ja/docs/concepts/workloads/pods/pod-lifecycle.md Co-authored-by: nasa9084 --- content/ja/docs/concepts/workloads/pods/pod-lifecycle.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md b/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md index 84b4397990..a9b9260337 100644 --- a/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md @@ -6,7 +6,7 @@ weight: 30 -このページではPodのライフサイクルについて説明します。Podは定義されたライフサイクルに従い `Pending`[フェーズ](#pod-phase)から始まり、少なくとも1つのプライマリコンテナが正常に開始した場合は`Running`を経由し、次に失敗により終了したコンテナの有無に応じて、`Succeeded`または`Failed`フェーズを経由します。 +このページではPodのライフサイクルについて説明します。Podは定義されたライフサイクルに従い `Pending`[フェーズ](#pod-phase)から始まり、少なくとも1つのプライマリーコンテナが正常に開始した場合は`Running`を経由し、次に失敗により終了したコンテナの有無に応じて、`Succeeded`または`Failed`フェーズを経由します。 Podの実行中、kubeletはコンテナを再起動して、ある種の障害を処理できます。Pod内で、Kubernetesはさまざまなコンテナの[ステータス](#container-states)を追跡して、対処します。 From 522318eff1630fa7009e5d0cf1ac5215b21e2dea Mon Sep 17 00:00:00 2001 From: Jin Hase Date: Mon, 28 Sep 2020 11:26:19 +0900 Subject: [PATCH 201/252] Update content/ja/docs/concepts/workloads/pods/pod-lifecycle.md Co-authored-by: nasa9084 --- content/ja/docs/concepts/workloads/pods/pod-lifecycle.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md b/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md index a9b9260337..76c4906cfd 100644 --- a/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md @@ -55,7 +55,7 @@ Nodeが停止するか、クラスタの残りの部分から切断された場 ## コンテナのステータス {#container-states} -Pod全体の[Phase](#pod-phase)と同様に、KubernetesはPod内の各コンテナの状態を追跡します。[container lifecycle hooks](/docs/concepts/containers/container-lifecycle-hooks/)を使用して、コンテナのライフサイクルの特定のポイントで実行するイベントをトリガーできます。 +Pod全体の[フェーズ](#pod-phase)と同様に、KubernetesはPod内の各コンテナの状態を追跡します。[container lifecycle hooks](/docs/concepts/containers/container-lifecycle-hooks/)を使用して、コンテナのライフサイクルの特定のポイントで実行するイベントをトリガーできます。 Podが{{< glossary_tooltip text="scheduler" term_id="kube-scheduler" >}}によってNodeに割り当てられると、kubeletは{{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}を使用してコンテナの作成を開始します。コンテナの状態は`Waiting`、`Running`または`Terminated`の3ついずれかです。 From af207cb0f9acf11a59da1c352008b60316d28059 Mon Sep 17 00:00:00 2001 From: Jin Hase Date: Mon, 28 Sep 2020 11:26:40 +0900 Subject: [PATCH 202/252] Update content/ja/docs/concepts/workloads/pods/pod-lifecycle.md Co-authored-by: nasa9084 --- content/ja/docs/concepts/workloads/pods/pod-lifecycle.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md b/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md index 76c4906cfd..31ad35510e 100644 --- a/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md @@ -81,7 +81,7 @@ Podのコンテナの状態を確認するには`kubectl describe pod [POD_NAME] Podの`spec`には、Always、OnFailure、またはNeverのいずれかの値を持つ`restartPolicy`フィールドがあります。デフォルト値はAlwaysです。 -`restartPolicy`は、Pod内のすべてのコンテナに適用されます。`restartPolicy`は、同じNode上のkubeletによるコンテナの再起動のみを参照します。Pod内のコンテナが終了した後、kubeletは5分を上限とする指数バックオフ遅延（10秒、20秒、40秒...）でコンテナを再起動します。コンテナが10分間問題なく実行されると、kubeletはコンテナ―の再起動バックオフタイマーをリセットします。 +`restartPolicy`は、Pod内のすべてのコンテナに適用されます。`restartPolicy`は、同じNode上のkubeletによるコンテナの再起動のみを参照します。Pod内のコンテナが終了した後、kubeletは5分を上限とする指数バックオフ遅延（10秒、20秒、40秒...）でコンテナを再起動します。コンテナが10分間問題なく実行されると、kubeletはコンテナの再起動バックオフタイマーをリセットします。 ## PodのCondition {#pod-conditions} From d95ed85a50631ec7462e4ac5e6fedd8825844b83 Mon Sep 17 00:00:00 2001 From: Jin Hase Date: Mon, 28 Sep 2020 11:29:35 +0900 Subject: [PATCH 203/252] Update content/ja/docs/concepts/workloads/pods/pod-lifecycle.md Co-authored-by: nasa9084 --- content/ja/docs/concepts/workloads/pods/pod-lifecycle.md | 1 - 1 file changed, 1 deletion(-) diff --git a/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md b/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md index 31ad35510e..83b050a7ea 100644 --- a/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md @@ -212,7 +212,6 @@ Podが削除されたときにリクエストを来ないようにするため {{< feature-state for_k8s_version="v1.16" state="alpha" >}} startupProbeは、サービスの開始に時間がかかるコンテナを持つポッドに役立ちます。livenessProbeの間隔を長く設定するのではなく、コンテナの起動時に別のProbeを構成して、livenessProbeの間隔よりも長い時間を許可できます。 -i コンテナの起動時間が、`initialDelaySeconds + failureThreshold x periodSeconds`よりも長い場合は、livenessProbeと同じエンドポイントをチェックするためにstartupProbeを指定します。`periodSeconds`のデフォルトは30秒です。次に、`failureThreshold`をlivenessProbeのデフォルト値を変更せずにコンテナが起動できるように、十分に高い値を設定します。これによりデッドロックを防ぐことができます。 ## Podの終了 {#pod-termination} From 3b2f0ad46d9f89ca5b4c5d79b3fe52ec2bc66f0d Mon Sep 17 00:00:00 2001 From: Jin Hase Date: Mon, 28 Sep 2020 11:29:54 +0900 Subject: [PATCH 204/252] Update content/ja/docs/concepts/workloads/pods/pod-lifecycle.md Co-authored-by: nasa9084 --- content/ja/docs/concepts/workloads/pods/pod-lifecycle.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md b/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md index 83b050a7ea..2df01fdf26 100644 --- a/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md @@ -236,7 +236,7 @@ Podは、クラスター内のNodeで実行中のプロセスを表すため、 {{< note >}} Pod内のすべてのコンテナが同時にTERMシグナルを受信するわけではなく、シャットダウンの順序が問題になる場合はそれぞれに`preStop`フックを使用して同期することを検討する。 {{< /note >}} -1. kubeletが正常な終了を開始すると同時に、コントロールプレーンは、終了中のPodをEndpoints(および有効な場合はEndpointSlice)オブジェクトから削除します。これらのオブジェクトは、{{< glossary_tooltip text="selector" term_id="selector" >}}が設定された{{< glossary_tooltip term_id="service" text="Service" >}}を表します。{{< glossary_tooltip text="ReplicaSets" term_id="replica-set" >}}とその他のワークロードリソースは、終了中のPodを有効なサービス中のReplicaSetとして扱いません。ゆっくりと終了するPodは、(サービスプロキシのような)ロードバランサーが終了猶予期間が_始まる_とエンドポイントからそれらのPodを削除するので、トラフィックを継続して処理できません。 +1. kubeletが正常な終了を開始すると同時に、コントロールプレーンは、終了中のPodをEndpoints(および有効な場合はEndpointSlice)オブジェクトから削除します。これらのオブジェクトは、{{< glossary_tooltip text="selector" term_id="selector" >}}が設定された{{< glossary_tooltip term_id="service" text="Service" >}}を表します。{{< glossary_tooltip text="ReplicaSets" term_id="replica-set" >}}とその他のワークロードリソースは、終了中のPodを有効なサービス中のReplicaSetとして扱いません。ゆっくりと終了するPodは、(サービスプロキシーのような)ロードバランサーが終了猶予期間が_始まる_とエンドポイントからそれらのPodを削除するので、トラフィックを継続して処理できません。 1. 猶予期間が終了すると、kubeletは強制削除を開始する。コンテナランタイムは、Pod内でまだ実行中のプロセスに`SIGKILL`を送信する。kubeletは、コンテナランタイムが非表示の`pause`コンテナを使用している場合、そのコンテナをクリーンアップします。 1. kubeletは猶予期間を0(即時削除)に設定することでAPI server上のPodの削除を終了する。 1. API serverはPodのAPIオブジェクトを削除し、クライアントからは見えなくなります。 From e99ade3e49f8351acb3520a8143dfc7c2379a45e Mon Sep 17 00:00:00 2001 From: Jin Hase Date: Mon, 28 Sep 2020 11:37:04 +0900 Subject: [PATCH 205/252] Update content/ja/docs/concepts/workloads/pods/pod-lifecycle.md Co-authored-by: nasa9084 --- content/ja/docs/concepts/workloads/pods/pod-lifecycle.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md b/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md index 2df01fdf26..8afc01295d 100644 --- a/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md @@ -148,7 +148,7 @@ Podのコンテナは準備完了ですが、少なくとも1つのカスタム ## コンテナのProbe {#container-probes} -[Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core) は [kubelet](/docs/admin/kubelet/) により定期的に実行されるコンテナの診断です。診断を行うために、kubeletはコンテナに実装された [ハンドラー](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#handler-v1-core)を呼びます。Handlerには次の3つの種類があります: +[Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core) は [kubelet](/docs/admin/kubelet/) により定期的に実行されるコンテナの診断です。診断を行うために、kubeletはコンテナに実装された [Handler](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#handler-v1-core)を呼びます。Handlerには次の3つの種類があります: * [ExecAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#execaction-v1-core): コンテナ内で特定のコマンドを実行します。コマンドがステータス0で終了した場合に診断を成功と見まします。 From cc05498b41247fb18ef287a1d460f10b2efa952a Mon Sep 17 00:00:00 2001 From: tkms0106 <23391543+tkms0106@users.noreply.github.com> Date: Fri, 18 Sep 2020 22:31:58 +0900 Subject: [PATCH 206/252] Update japanese services-networking/service.md to follow v1.18 of the original (English) text --- .../concepts/services-networking/service.md | 55 ++++++++++++++++--- 1 file changed, 47 insertions(+), 8 deletions(-) diff --git a/content/ja/docs/concepts/services-networking/service.md b/content/ja/docs/concepts/services-networking/service.md index e23ab9312f..be66c08c3f 100644 --- a/content/ja/docs/concepts/services-networking/service.md +++ b/content/ja/docs/concepts/services-networking/service.md @@ -143,6 +143,14 @@ ExternalName Serviceはセレクターの代わりにDNS名を使用する特殊 エンドポイントスライスは、[エンドポイントスライスのドキュメント](/docs/concepts/services-networking/endpoint-slices/)にて詳しく説明されている追加の属性と機能を提供します。 +### アプリケーションプロトコル + +{{< feature-state for_k8s_version="v1.18" state="alpha" >}} + +AppProtocolフィールドは、各Serviceのポートで使用されるアプリケーションプロトコルを指定する方法を提供します。 + +アルファ機能のため、このフィールドはデフォルトで有効化されていません。このフィールドを使用するには、 `ServiceAppProtocol` という[Feature gate](/docs/reference/command-line-tools-reference/feature-gates/)を有効化してください。 + ## 仮想IPとサービスプロキシー {#virtual-ips-and-service-proxies} Kubernetesクラスターの各Nodeは`kube-proxy`を稼働させています。`kube-proxy`は[`ExternalName`](#externalname)タイプ以外の`Service`用に仮想IPを実装する責務があります。 @@ -272,7 +280,7 @@ Kubernetesは、Serviceオブジェクトを見つけ出すために2つの主 PodがNode上で稼働するとき、kubeletはアクティブな各Serviceに対して、環境変数のセットを追加します。 これは[Docker links互換性](https://docs.docker.com/userguide/dockerlinks/)のある変数( -[makeLinkVariables関数](http://releases.k8s.io/{{< param "githubbranch" >}}/pkg/kubelet/envvars/envvars.go#L72)を確認してください)や、より簡単な`{SVCNAME}_SERVICE_HOST`や、`{SVCNAME}_SERVICE_PORT`変数をサポートします。この変数名で使われるService名は大文字に変換され、`-`は`_`に変換されます。 +[makeLinkVariables関数](https://releases.k8s.io/{{< param "githubbranch" >}}/pkg/kubelet/envvars/envvars.go#L72)を確認してください)や、より簡単な`{SVCNAME}_SERVICE_HOST`や、`{SVCNAME}_SERVICE_PORT`変数をサポートします。この変数名で使われるService名は大文字に変換され、`-`は`_`に変換されます。 例えば、TCPポート6379番を公開していて、さらにclusterIPが10.0.0.11に割り当てられている`"redis-master"`というServiceは、下記のような環境変数を生成します。 @@ -373,6 +381,26 @@ NodePortの使用は、Kubernetesによって完全にサポートされてい 注意点として、このServiceは`:spec.ports[*].nodePort`と、`.spec.clusterIP:spec.ports[*].port`として疎通可能です。 (もしkube-proxyにおいて`--nodeport-addressses`が設定された場合、はフィルターされたNodeIPとなります。) +例えば: + +```yaml +apiVersion: v1 +kind: Service +metadata: + name: my-service +spec: + type: NodePort + selector: + app: MyApp + ports: + # デフォルトでは利便性のため、 `targetPort` は `port` と同じ値にセットされます。 + - port: 80 + targetPort: 80 + # 省略可能なフィールド + # デフォルトでは利便性のため、Kubernetesコントロールプレーンはある範囲から1つポートを割り当てます（デフォルトの範囲：30000-32767） + nodePort: 30007 +``` + ### LoadBalancer タイプ {#loadbalancer} 外部のロードバランサーをサポートするクラウドプロバイダー上で、`type`フィールドに`LoadBalancer`を設定すると、Service用にロードバランサーがプロビジョニングされます。 @@ -461,6 +489,17 @@ metadata: service.beta.kubernetes.io/azure-load-balancer-internal: "true" [...] ``` +{{% /tab %}} +{{% tab name="IBM Cloud" %}} +```yaml +[...] +metadata: + name: my-service + annotations: + service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "private" +[...] +``` + {{% /tab %}} {{% tab name="OpenStack" %}} ```yaml @@ -532,7 +571,7 @@ TCPとSSLでは、レイヤー4でのプロキシーを選択します。ELBは 上記の例では、もしServiceが`80`、`443`、`8443`と3つのポートを含んでいる場合、`443`と`8443`はSSL証明書を使いますが、`80`では単純にHTTPでのプロキシーとなります。 -Kubernetes v1.9以降のバージョンからは、Serviceのリスナー用にHTTPSやSSLと[事前定義されたAWS SSLポリシー](http://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-policy-table.html)を使用できます。 +Kubernetes v1.9以降のバージョンからは、Serviceのリスナー用にHTTPSやSSLと[事前定義されたAWS SSLポリシー](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-policy-table.html)を使用できます。 どのポリシーが使用できるかを確認するために、`aws`コマンドラインツールを使用できます。 ```bash @@ -654,7 +693,7 @@ 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](https://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に転送します。 @@ -663,7 +702,7 @@ NLBは特定のインスタンスクラスでのみ稼働します。サポー `.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)を設定します。 +均等なトラフィックの分配を実現するために、DaemonSetの使用や、同一のNodeに配備しないように[Podのanti-affinity](/ja/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)を設定します。 また、[内部のロードバランサー](/ja/docs/concepts/services-networking/service/#internal-load-balancer)のアノテーションとNLB Serviceを使用できます。 @@ -785,10 +824,10 @@ spec: - 80.11.12.10 ``` -## Serviceのデメリット +## Serviceの欠点 仮想IP用にuserspaceモードのプロキシーを使用すると、小規模もしくは中規模のスケールでうまく稼働できますが、1000以上のServiceがあるようなとても大きなクラスターではうまくスケールしません。 -これについては、[Serviceのデザインプロポーザル](http://issue.k8s.io/1107)にてさらなる詳細を確認できます。 +これについては、[Serviceのデザインプロポーザル](https://github.com/kubernetes/kubernetes/issues/1107)にてさらなる詳細を確認できます。 userspaceモードのプロキシーの使用は、Serviceにアクセスするパケットの送信元IPアドレスが不明瞭になります。 これは、いくつかの種類のネットワークフィルタリング(ファイアウォールによるフィルタリング)を不可能にします。 @@ -812,8 +851,8 @@ Kubernetesは各Serviceに、それ自身のIPアドレスを割り当てるこ 各Serviceが固有のIPを割り当てられるのを保証するために、内部のアロケーターは、Serviceを作成する前に、etcd内のグローバルの割り当てマップをアトミックに更新します。 そのマップオブジェクトはServiceのIPアドレスの割り当てのためにレジストリー内に存在しなくてはならず、そうでない場合は、Serviceの作成時にIPアドレスが割り当てられなかったことを示すエラーメッセージが表示されます。 -コントロールプレーンにおいて、バックグラウンドのコントローラーはそのマップを作成する責務があります(インメモリーのロックが使われていた古いバージョンのKubernetesのマイグレーションも必要です)。 -また、Kubernetesは無効な割り当てがされているかをチェックすることと、現時点でどのServiceにも使用されていない割り当て済みIPアドレスのクリーンアップのためにコントローラーを使用します。 +コントロールプレーンにおいて、バックグラウンドのコントローラーはそのマップを作成する責務があります(インメモリーのロックが使われていた古いバージョンのKubernetesからのマイグレーションをサポートすることも必要です)。 +また、Kubernetesは（例えば、管理者の介入によって）無効な割り当てがされているかをチェックすることと、現時点でどのServiceにも使用されていない割り当て済みIPアドレスのクリーンアップのためにコントローラーを使用します。 ### ServiceのIPアドレス {#ips-and-vips} From bc1520e71c629043a5fb34cd690da9518a0fdbda Mon Sep 17 00:00:00 2001 From: Takumi Sue <23391543+tkms0106@users.noreply.github.com> Date: Thu, 24 Sep 2020 16:43:39 +0900 Subject: [PATCH 207/252] =?UTF-8?q?Translate=20"feature=20gate"=20into=20"?= =?UTF-8?q?=E3=83=95=E3=82=A3=E3=83=BC=E3=83=81=E3=83=A3=E3=83=BC=E3=82=B2?= =?UTF-8?q?=E3=83=BC=E3=83=88"?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit and update link to japanese version Co-authored-by: makocchi --- content/ja/docs/concepts/services-networking/service.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/services-networking/service.md b/content/ja/docs/concepts/services-networking/service.md index be66c08c3f..799613419c 100644 --- a/content/ja/docs/concepts/services-networking/service.md +++ b/content/ja/docs/concepts/services-networking/service.md @@ -149,7 +149,7 @@ ExternalName Serviceはセレクターの代わりにDNS名を使用する特殊 AppProtocolフィールドは、各Serviceのポートで使用されるアプリケーションプロトコルを指定する方法を提供します。 -アルファ機能のため、このフィールドはデフォルトで有効化されていません。このフィールドを使用するには、 `ServiceAppProtocol` という[Feature gate](/docs/reference/command-line-tools-reference/feature-gates/)を有効化してください。 +アルファ機能のため、このフィールドはデフォルトで有効化されていません。このフィールドを使用するには、 `ServiceAppProtocol` という[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効化してください。 ## 仮想IPとサービスプロキシー {#virtual-ips-and-service-proxies} @@ -976,4 +976,3 @@ kube-proxyはuserspaceモードにおいてSCTPアソシエーションの管理 * [Ingress](/docs/concepts/services-networking/ingress/)を参照してください。 * [EndpointSlices](/docs/concepts/services-networking/endpoint-slices/)を参照してください。 - From 51a2280038ec1bfcac14a0d1814a57a86dd46ffb Mon Sep 17 00:00:00 2001 From: tkms0106 <23391543+tkms0106@users.noreply.github.com> Date: Thu, 24 Sep 2020 16:47:08 +0900 Subject: [PATCH 208/252] =?UTF-8?q?Replace=20"feature=20gate"=20for=20"?= =?UTF-8?q?=E3=83=95=E3=82=A3=E3=83=BC=E3=83=81=E3=83=A3=E3=83=BC=E3=82=B2?= =?UTF-8?q?=E3=83=BC=E3=83=88"?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- content/ja/docs/concepts/services-networking/service.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/services-networking/service.md b/content/ja/docs/concepts/services-networking/service.md index 799613419c..9e05423995 100644 --- a/content/ja/docs/concepts/services-networking/service.md +++ b/content/ja/docs/concepts/services-networking/service.md @@ -933,9 +933,9 @@ PROXY TCP4 192.0.2.202 10.0.42.7 12345 7\r\n {{< feature-state for_k8s_version="v1.12" state="alpha" >}} -KubernetesはService、Endpoints、NetworkPolicyとPodの定義においてα版の機能として`protocol`フィールドの値でSCTPをサポートしています。この機能を有効にするために、クラスター管理者はAPI Serverにおいて`SCTPSupport`というFeature Gateを有効にする必要があります。例えば、`--feature-gates=SCTPSupport=true,…`といったように設定します。 +KubernetesはService、Endpoints、NetworkPolicyとPodの定義においてα版の機能として`protocol`フィールドの値でSCTPをサポートしています。この機能を有効にするために、クラスター管理者はAPI Serverにおいて`SCTPSupport`というフィーチャーゲートを有効にする必要があります。例えば、`--feature-gates=SCTPSupport=true,…`といったように設定します。 -そのFeature Gateが有効になった時、ユーザーはService、Endpoints、NetworkPolicyの`protocol`フィールドと、Podの`SCTP`フィールドを設定できます。 +そのフィーチャーゲートが有効になった時、ユーザーはService、Endpoints、NetworkPolicyの`protocol`フィールドと、Podの`SCTP`フィールドを設定できます。 Kubernetesは、TCP接続と同様に、SCTPアソシエーションに応じてネットワークをセットアップします。 #### 警告 {#caveat-sctp-overview} From 2befbab8526aad66cdd4b1f6421338d64c9feaf5 Mon Sep 17 00:00:00 2001 From: Takumi Sue <23391543+tkms0106@users.noreply.github.com> Date: Thu, 24 Sep 2020 18:56:43 +0900 Subject: [PATCH 209/252] Improve translation Co-authored-by: nasa9084 --- content/ja/docs/concepts/services-networking/service.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/services-networking/service.md b/content/ja/docs/concepts/services-networking/service.md index 9e05423995..bf3b04f35d 100644 --- a/content/ja/docs/concepts/services-networking/service.md +++ b/content/ja/docs/concepts/services-networking/service.md @@ -397,7 +397,7 @@ spec: - port: 80 targetPort: 80 # 省略可能なフィールド - # デフォルトでは利便性のため、Kubernetesコントロールプレーンはある範囲から1つポートを割り当てます（デフォルトの範囲：30000-32767） + # デフォルトでは利便性のため、Kubernetesコントロールプレーンはある範囲から1つポートを割り当てます(デフォルト値の範囲：30000-32767) nodePort: 30007 ``` @@ -975,4 +975,3 @@ kube-proxyはuserspaceモードにおいてSCTPアソシエーションの管理 * [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/)を参照してください。 * [Ingress](/docs/concepts/services-networking/ingress/)を参照してください。 * [EndpointSlices](/docs/concepts/services-networking/endpoint-slices/)を参照してください。 - From 25c09c5f9b2318ac1654a174119eafc988617e5c Mon Sep 17 00:00:00 2001 From: Takumi Sue <23391543+tkms0106@users.noreply.github.com> Date: Thu, 24 Sep 2020 19:04:57 +0900 Subject: [PATCH 210/252] Replace em brackets for en brackets to follow the style guide Co-authored-by: nasa9084 --- content/ja/docs/concepts/services-networking/service.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/services-networking/service.md b/content/ja/docs/concepts/services-networking/service.md index bf3b04f35d..b75ecf18f5 100644 --- a/content/ja/docs/concepts/services-networking/service.md +++ b/content/ja/docs/concepts/services-networking/service.md @@ -852,7 +852,7 @@ Kubernetesは各Serviceに、それ自身のIPアドレスを割り当てるこ そのマップオブジェクトはServiceのIPアドレスの割り当てのためにレジストリー内に存在しなくてはならず、そうでない場合は、Serviceの作成時にIPアドレスが割り当てられなかったことを示すエラーメッセージが表示されます。 コントロールプレーンにおいて、バックグラウンドのコントローラーはそのマップを作成する責務があります(インメモリーのロックが使われていた古いバージョンのKubernetesからのマイグレーションをサポートすることも必要です)。 -また、Kubernetesは（例えば、管理者の介入によって）無効な割り当てがされているかをチェックすることと、現時点でどのServiceにも使用されていない割り当て済みIPアドレスのクリーンアップのためにコントローラーを使用します。 +また、Kubernetesは(例えば、管理者の介入によって)無効な割り当てがされているかをチェックすることと、現時点でどのServiceにも使用されていない割り当て済みIPアドレスのクリーンアップのためにコントローラーを使用します。 ### ServiceのIPアドレス {#ips-and-vips} From 0f2e89919c5ab0bbe59501c6f41a6423ce8d261a Mon Sep 17 00:00:00 2001 From: tkms0106 <23391543+tkms0106@users.noreply.github.com> Date: Thu, 24 Sep 2020 19:12:28 +0900 Subject: [PATCH 211/252] Replace em characters for en characters to follow the style guide --- content/ja/docs/concepts/services-networking/service.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/ja/docs/concepts/services-networking/service.md b/content/ja/docs/concepts/services-networking/service.md index b75ecf18f5..2b3d6b26e0 100644 --- a/content/ja/docs/concepts/services-networking/service.md +++ b/content/ja/docs/concepts/services-networking/service.md @@ -397,7 +397,7 @@ spec: - port: 80 targetPort: 80 # 省略可能なフィールド - # デフォルトでは利便性のため、Kubernetesコントロールプレーンはある範囲から1つポートを割り当てます(デフォルト値の範囲：30000-32767) + # デフォルトでは利便性のため、Kubernetesコントロールプレーンはある範囲から1つポートを割り当てます(デフォルト値の範囲:30000-32767) nodePort: 30007 ``` @@ -728,7 +728,7 @@ spec: {{< /note >}} -#### Tencent Kubernetes Engine（TKE）におけるその他のCLBアノテーション +#### Tencent Kubernetes Engine(TKE)におけるその他のCLBアノテーション 以下に示すように、TKEでCloud Load Balancerを管理するためのその他のアノテーションがあります。 @@ -739,7 +739,7 @@ spec: # 指定したノードでロードバランサーをバインドします service.kubernetes.io/qcloud-loadbalancer-backends-label: key in (value1, value2) # 既存のロードバランサーのID - service.kubernetes.io/tke-existed-lbid：lb-6swtxxxx + service.kubernetes.io/tke-existed-lbid:lb-6swtxxxx # ロードバランサー(LB)のカスタムパラメーターは、LBタイプの変更をまだサポートしていません service.kubernetes.io/service.extensiveParameters: "" @@ -753,7 +753,7 @@ spec: # パブリックネットワーク帯域幅の課金方法を指定します # 有効な値: TRAFFIC_POSTPAID_BY_HOUR(bill-by-traffic)およびBANDWIDTH_POSTPAID_BY_HOUR(bill-by-bandwidth) service.kubernetes.io/qcloud-loadbalancer-internet-charge-type: xxxxxx - # 帯域幅の値を指定します(値の範囲：[1-2000] Mbps)。 + # 帯域幅の値を指定します(値の範囲:[1-2000] Mbps)。 service.kubernetes.io/qcloud-loadbalancer-internet-max-bandwidth-out: "10" # この注釈が設定されている場合、ロードバランサーはポッドが実行されているノードのみを登録します # そうでない場合、すべてのノードが登録されます From fda183e5229c1a040aaf4c8cb2f7a8f46595978a Mon Sep 17 00:00:00 2001 From: tkms0106 <23391543+tkms0106@users.noreply.github.com> Date: Mon, 28 Sep 2020 20:14:06 +0900 Subject: [PATCH 212/252] Fix broken link not translated into Japanese yet --- content/ja/docs/concepts/services-networking/service.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/services-networking/service.md b/content/ja/docs/concepts/services-networking/service.md index 2b3d6b26e0..e865a91712 100644 --- a/content/ja/docs/concepts/services-networking/service.md +++ b/content/ja/docs/concepts/services-networking/service.md @@ -702,7 +702,7 @@ NLBは特定のインスタンスクラスでのみ稼働します。サポー `.spec.externalTrafficPolicy`を`Local`に設定することにより、クライアントIPアドレスは末端のPodに伝播します。しかし、これにより、トラフィックの分配が不均等になります。 特定のLoadBalancer Serviceに紐づいたPodがないNodeでは、自動的に割り当てられた`.spec.healthCheckNodePort`に対するNLBのターゲットグループのヘルスチェックが失敗し、トラフィックを全く受信しません。 -均等なトラフィックの分配を実現するために、DaemonSetの使用や、同一のNodeに配備しないように[Podのanti-affinity](/ja/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)を設定します。 +均等なトラフィックの分配を実現するために、DaemonSetの使用や、同一のNodeに配備しないように[Podのanti-affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)を設定します。 また、[内部のロードバランサー](/ja/docs/concepts/services-networking/service/#internal-load-balancer)のアノテーションとNLB Serviceを使用できます。 From 0e2d918ba8eb0fe11cc7112e313a943688095dbe Mon Sep 17 00:00:00 2001 From: hikkie3110 <3110hikaru326@gmail.com> Date: Tue, 29 Sep 2020 13:17:48 +0900 Subject: [PATCH 213/252] update minikube.md for v1.18 --- .../setup/learning-environment/minikube.md | 67 +++++++++++-------- 1 file changed, 40 insertions(+), 27 deletions(-) diff --git a/content/ja/docs/setup/learning-environment/minikube.md b/content/ja/docs/setup/learning-environment/minikube.md index 67b0002946..54a0411132 100644 --- a/content/ja/docs/setup/learning-environment/minikube.md +++ b/content/ja/docs/setup/learning-environment/minikube.md @@ -50,7 +50,8 @@ MinikubeのサポートするKubernetesの機能: 特定のKubernetesのバージョン、VM、コンテナランタイム上でクラスターを起動するための詳細は、[クラスターの起動](#starting-a-cluster)を参照してください。 2. kubectlを使用してクラスターと対話できるようになります。詳細は[クラスターに触れてみよう](#interacting-with-your-cluster)を参照してください。 -単純なHTTPサーバーである`echoserver`という既存のイメージを使用して、Kubernetes Deploymentを作りましょう。そして`--port`を使用して8080番ポートで公開しましょう。 + + 単純なHTTPサーバーである`echoserver`という既存のイメージを使用して、Kubernetes Deploymentを作りましょう。そして`--port`を使用して8080番ポートで公開しましょう。 ```shell kubectl create deployment hello-minikube --image=k8s.gcr.io/echoserver:1.10 @@ -69,6 +70,7 @@ MinikubeのサポートするKubernetesの機能: ``` `--type=NodePort`オプションで、Serviceのタイプを指定します。 + 出力はこのようになります: ``` @@ -78,6 +80,7 @@ MinikubeのサポートするKubernetesの機能: 4. `hello-minikube`Podが起動開始されましたが、公開したService経由で接続する前にPodが起動完了になるまで待つ必要があります。 Podが稼働しているか確認します: + ```shell kubectl get pod ``` @@ -110,19 +113,19 @@ MinikubeのサポートするKubernetesの機能: Hostname: hello-minikube-7c77b68cff-8wdzq Pod Information: - -no pod information available- + -no pod information available- Server values: - server_version=nginx: 1.13.3 - lua: 10008 + server_version=nginx: 1.13.3 - lua: 10008 Request Information: - client_address=172.17.0.1 - method=GET - real path=/ - query= - request_version=1.1 - request_scheme=http - request_uri=http://192.168.99.100:8080/ + client_address=172.17.0.1 + method=GET + real path=/ + query= + request_version=1.1 + request_scheme=http + request_uri=http://192.168.99.100:8080/ Request Headers: accept=*/* @@ -168,8 +171,8 @@ MinikubeのサポートするKubernetesの機能: 出力はこのようになります: ``` - Stopping local Kubernetes cluster... Stopping "minikube"... + "minikube" stopped. ``` 詳細は[クラスターの停止](#stopping-a-cluster)を参照ください。 @@ -222,24 +225,27 @@ minikube start --kubernetes-version {{< param "fullversion" >}} #### VMドライバーの指定 -もしVMドライバーを変更したい場合は、`--vm-driver=`フラグを`minikube start`に設定してください。例えば、コマンドは以下のようになります。 +もしVMドライバーを変更したい場合は、`--driver=`フラグを`minikube start`に設定してください。例えば、コマンドは以下のようになります。 ```shell -minikube start --vm-driver= +minikube start --driver= ``` Minikubeは以下のドライバーをサポートしています: {{< note >}} -サポートされているドライバーとプラグインのインストールの詳細については[DRIVERS](https://git.k8s.io/minikube/docs/drivers.md)を参照してください。 +サポートされているドライバーとプラグインのインストールの詳細については[DRIVERS](https://minikube.sigs.k8s.io/docs/reference/drivers/)を参照してください。 {{< /note >}} -* virtualbox +* docker ([driver installation](https://minikube.sigs.k8s.io/docs/drivers/docker/)) +* virtualbox ([driver installation](https://minikube.sigs.k8s.io/docs/drivers/virtualbox/)) +* podman ([driver installation](https://minikube.sigs.k8s.io/docs/drivers/podman/)) (実験的) * vmwarefusion -* kvm2 ([driver installation](https://minikube.sigs.k8s.io/docs/drivers/#kvm2-driver)) -* hyperkit ([driver installation](https://minikube.sigs.k8s.io/docs/drivers/#hyperkit-driver)) -* hyperv ([driver installation](https://github.com/kubernetes/minikube/blob/master/docs/drivers.md#hyperv-driver)) +* kvm2 ([driver installation](https://minikube.sigs.k8s.io/docs/reference/drivers/kvm2/)) +* hyperkit ([driver installation](https://minikube.sigs.k8s.io/docs/reference/drivers/hyperkit/)) +* hyperv ([driver installation](https://minikube.sigs.k8s.io/docs/reference/drivers/hyperv/)) 注意: 以下のIPは動的であり、変更される可能性があります。IPは`minikube ip`で取得することができます。 * vmware ([driver installation](https://minikube.sigs.k8s.io/docs/reference/drivers/vmware/)) (VMware unified driver) +* parallels ([driver installation](https://minikube.sigs.k8s.io/docs/reference/drivers/parallels/)) * none (VMではなくホスト上でKubernetesコンポーネントを起動。このドライバーを使用するには{{< glossary_tooltip term_id="docker" >}}とLinux環境を必要とします) {{< caution >}} @@ -372,7 +378,12 @@ Kubeletの `MaxPods` 設定を5に変更するには、このフラグを渡し このコマンドはMinikube仮想マシンをシャットダウンして削除します。データや状態は保存されません。 ### minikubeのアップグレード {#upgrading-minikube} -[minikubeのアップグレード](https://minikube.sigs.k8s.io/docs/start/macos/)を参照してください。 +macOSを使用し[Brew Package Manager](https://brew.sh/)がインストールされている場合、以下を実行します: + +```shell +brew update +brew upgrade minikube +``` ## クラスターに触れてみよう {#interacting-with-your-cluster} @@ -383,9 +394,11 @@ Kubeletの `MaxPods` 設定を5に変更するには、このフラグを渡し Minikubeはこのコンテキストを自動的にデフォルトに設定しますが、将来的に設定を切り戻す場合には次のコマンドを実行してください: -`kubectl config use-context minikube`, +`kubectl config use-context minikube` -もしくは各コマンドにコンテキストを次のように渡します: `kubectl get pods --context=minikube` +もしくは各コマンドにコンテキストを次のように渡します: + + `kubectl get pods --context=minikube` ### ダッシュボード @@ -500,13 +513,13 @@ Minikubeの詳細については、[proposal](https://git.k8s.io/community/contr ## 追加リンク集 -* **目標と非目標**: Minikubeプロジェクトの目標と非目標については、[ロードマップ](https://git.k8s.io/minikube/docs/contributors/roadmap.md)を参照してください。 -* **開発ガイド**: プルリクエストを送る方法の概要については、[CONTRIBUTING.md](https://git.k8s.io/minikube/CONTRIBUTING.md)を参照してください。 -* **Minikubeのビルド**: Minikubeをソースからビルド/テストする方法については、[ビルドガイド](https://git.k8s.io/minikube/docs/contributors/build_guide.md)を参照してください。 -* **新しい依存性の追加**: Minikubeに新しい依存性を追加する方法については、[依存性追加ガイド](https://git.k8s.io/minikube/docs/contributors/adding_a_dependency.md)を参照してください。 -* **新しいアドオンの追加**: Minikubeに新しいアドオンを追加する方法については、[アドオン追加ガイド](https://git.k8s.io/minikube/docs/contributors/adding_an_addon.md)を参照してください。 +* **目標と非目標**: Minikubeプロジェクトの目標と非目標については、[ロードマップ](https://minikube.sigs.k8s.io/docs/contrib/roadmap/)を参照してください。 +* **開発ガイド**: プルリクエストを送る方法の概要については、[コントリビュートする](https://minikube.sigs.k8s.io/docs/contrib/)を参照してください。 +* **Minikubeのビルド**: Minikubeをソースからビルド/テストする方法については、[ビルドガイド](https://minikube.sigs.k8s.io/docs/contrib/building/)を参照してください。 +* **新しい依存性の追加**: Minikubeに新しい依存性を追加する方法については、[依存性追加ガイド](https://minikube.sigs.k8s.io/docs/contrib/drivers/)を参照してください。 +* **新しいアドオンの追加**: Minikubeに新しいアドオンを追加する方法については、[アドオン追加ガイド](https://minikube.sigs.k8s.io/docs/contrib/addons/)を参照してください。 * **MicroK8s**: 仮想マシンを実行したくないLinuxユーザーは代わりに[MicroK8s](https://microk8s.io/)を検討してみてください。 ## コミュニティ -コントリビューションや質問、コメントは歓迎・奨励されています! 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: " をつけてください。 +コントリビューションや質問、コメントは歓迎・奨励されています! 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: " をつけてください。 From a7ee415e9b1b86e2e75182d3733a71f3213d5abc Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Mon, 28 Sep 2020 13:37:05 +0900 Subject: [PATCH 214/252] Update ja/docs/tasks/administer-cluster/developing-cloud-controller-manager.md --- .../developing-cloud-controller-manager.md | 29 ++++++++----------- 1 file changed, 12 insertions(+), 17 deletions(-) diff --git a/content/ja/docs/tasks/administer-cluster/developing-cloud-controller-manager.md b/content/ja/docs/tasks/administer-cluster/developing-cloud-controller-manager.md index 5d1614ffa4..d2534086a9 100644 --- a/content/ja/docs/tasks/administer-cluster/developing-cloud-controller-manager.md +++ b/content/ja/docs/tasks/administer-cluster/developing-cloud-controller-manager.md @@ -5,35 +5,30 @@ content_type: concept -{{< feature-state for_k8s_version="v1.11" state="beta" >}} -今後のリリースで、クラウドコントローラーマネージャーはKubernetesを任意のクラウドと統合するための良い方法となります。これによりクラウドプロバイダーはKubernetesのコアリリースサイクルから独立して機能を開発できるようになります。 - -{{< feature-state for_k8s_version="1.8" state="alpha" >}} - -独自のクラウドコントローラーマネージャーを構築する方法を説明する前に、クラウドコントローラーマネージャーがKubernetesの内部でどのように機能するかに関する背景を知っておくと役立ちます。 -クラウドコントローラーマネージャーはGoインターフェースを利用する`kube-controller-manager`のコードで、任意のクラウドの実装をプラグインとして利用できるようになっています。スキャフォールディングと汎用のコントローラー実装の大部分はKubernetesのコアになりますが、[クラウドプロバイダーのインターフェイス](https://github.com/kubernetes/cloud-provider/blob/master/cloud.go#L42-L62)が満たされていれば提供されているクラウドプロバイダーのインターフェイスが実行されるようになります。 - -実装の詳細をもう少し掘り下げてみましょう。すべてのクラウドコントローラーマネージャーはKubernetesコアからパッケージをインポートします。唯一の違いは、各プロジェクトが利用可能なクラウドプロバイダーの情報(グローバル変数)が更新される場所である[cloudprovider.RegisterCloudProvider](https://github.com/kubernetes/cloud-provider/blob/6371aabbd7a7726f4b358444cca40def793950c2/plugins.go#L55-L63)を呼び出すことによって独自のクラウドプロバイダーを登録する点です。 - - - +{{< glossary_definition term_id="cloud-controller-manager" length="all" prepend="cloud-controller-managerは">}} +## 背景 + +クラウドプロバイダーはKubernetesプロジェクトとは異なる速度で開発しリリースすることから、プロバイダー特有なコードを`cloud-controller-manager`バイナリから抽象化することで、クラウドベンダーはコアKubernetesコードから独立して発展することができます。 + +Kubernetesプロジェクトは、(クラウドプロバイダーの)独自実装を組み込めるGoインターフェースを備えたcloud-controller-managerのスケルトンコードを提供しています。これは、クラウドプロバイダーがKubernetesコアからパッケージをインポートすることでcloud-controller-managerを実装できることを意味します。各クラウドプロバイダーは、利用可能なクラウドプロバイダーのグローバル変数を更新するために`cloudprovider.RegisterCloudProvider`を呼び出して利用可能なクラウドプロバイダーのグローバル変数を更新し、独自のコードを登録します。 + ## 開発 ### Kubernetesには登録されていない独自クラウドプロバイダー -Kubernetesには登録されていない独自のクラウドプロバイダーのクラウドコントローラーマネージャーを構築するには、次の3つのステップに従ってください。 +Kubernetesには登録されていない独自のクラウドプロバイダーのクラウドコントローラーマネージャーを構築するには、 1. [cloudprovider.Interface](https://github.com/kubernetes/cloud-provider/blob/master/cloud.go)を満たす go パッケージを実装します。 -2. Kubernetesのコアにある[cloud-controller-managerのmain.go](https://github.com/kubernetes/kubernetes/blob/master/cmd/cloud-controller-manager/controller-manager.go)をあなたのmain.goのテンプレートとして利用します。上で述べたように、唯一の違いはインポートされるクラウドパッケージのみです。 -3. クラウドパッケージを `main.go` にインポートし、パッケージに [cloudprovider.RegisterCloudProvider](https://github.com/kubernetes/cloud-provider/blob/master/plugins.go) を実行するための `init` ブロックがあることを確認します。 +2. Kubernetesのコアにある[cloud-controller-managerの`main.go`](https://github.com/kubernetes/kubernetes/blob/master/cmd/cloud-controller-manager/controller-manager.go)をあなたの`main.go`のテンプレートとして利用します。上で述べたように、唯一の違いはインポートされるクラウドパッケージのみです。 +3. クラウドパッケージを `main.go` にインポートし、パッケージに [`cloudprovider.RegisterCloudProvider`](https://github.com/kubernetes/cloud-provider/blob/master/plugins.go) を実行するための `init` ブロックがあることを確認します。 -既存の独自クラウドプロバイダーの実装例を利用すると役立つでしょう。独自クラウドプロバイダーの実装例のリストは[こちら](/docs/tasks/administer-cluster/running-cloud-controller.md#examples)にあります。 +多くのクラウドプロバイダーはオープンソースとしてコントローラーマネージャーのコードを公開しています。新たにcloud-controller-managerをスクラッチから開発する際には、既存のKubernetesには登録されていない独自クラウドプロバイダーのコントローラーマネージャーを開始地点とすることができます。 ### Kubernetesに登録されているクラウドプロバイダー -Kubernetesに登録されているクラウドプロバイダーであれば、[Daemonset](https://kubernetes.io/examples/admin/cloud/ccm-example.yaml) を使ってあなたのクラスターで動かすことができます。詳細については[Kubernetesクラウドコントローラーマネージャードキュメント](/docs/tasks/administer-cluster/running-cloud-controller/)を参照してください。 +Kubernetesに登録されているクラウドプロバイダーであれば、{{< glossary_tooltip term_id="daemonset" >}}を使ってあなたのクラスターで動かすことができます。詳細については[Kubernetesクラウドコントローラーマネージャー](/ja/docs/tasks/administer-cluster/running-cloud-controller/)を参照してください。 From a7712d814b2c5d6f03c1f2d87328c3a31da65953 Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Mon, 28 Sep 2020 13:41:25 +0900 Subject: [PATCH 215/252] Update ja/docs/tasks/administer-cluster/developing-cloud-controller-manager.md --- .../administer-cluster/developing-cloud-controller-manager.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/administer-cluster/developing-cloud-controller-manager.md b/content/ja/docs/tasks/administer-cluster/developing-cloud-controller-manager.md index d2534086a9..5d816eed32 100644 --- a/content/ja/docs/tasks/administer-cluster/developing-cloud-controller-manager.md +++ b/content/ja/docs/tasks/administer-cluster/developing-cloud-controller-manager.md @@ -13,7 +13,7 @@ content_type: concept クラウドプロバイダーはKubernetesプロジェクトとは異なる速度で開発しリリースすることから、プロバイダー特有なコードを`cloud-controller-manager`バイナリから抽象化することで、クラウドベンダーはコアKubernetesコードから独立して発展することができます。 -Kubernetesプロジェクトは、(クラウドプロバイダーの)独自実装を組み込めるGoインターフェースを備えたcloud-controller-managerのスケルトンコードを提供しています。これは、クラウドプロバイダーがKubernetesコアからパッケージをインポートすることでcloud-controller-managerを実装できることを意味します。各クラウドプロバイダーは、利用可能なクラウドプロバイダーのグローバル変数を更新するために`cloudprovider.RegisterCloudProvider`を呼び出して利用可能なクラウドプロバイダーのグローバル変数を更新し、独自のコードを登録します。 +Kubernetesプロジェクトは、(クラウドプロバイダーの)独自実装を組み込めるGoインターフェースを備えたcloud-controller-managerのスケルトンコードを提供しています。これは、クラウドプロバイダーがKubernetesコアからパッケージをインポートすることでcloud-controller-managerを実装できることを意味します。各クラウドプロバイダーは、利用可能なクラウドプロバイダーのグローバル変数を更新するために`cloudprovider.RegisterCloudProvider`を呼び出し、独自のコードを登録します。 ## 開発 From 32aa2ece0d1dd73ed5311fc88579372a796fbf59 Mon Sep 17 00:00:00 2001 From: yu-kasuya Date: Tue, 29 Sep 2020 11:47:21 +0900 Subject: [PATCH 216/252] Apply suggestions from code review Co-authored-by: nasa9084 --- .../administer-cluster/developing-cloud-controller-manager.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/ja/docs/tasks/administer-cluster/developing-cloud-controller-manager.md b/content/ja/docs/tasks/administer-cluster/developing-cloud-controller-manager.md index 5d816eed32..36e28ea455 100644 --- a/content/ja/docs/tasks/administer-cluster/developing-cloud-controller-manager.md +++ b/content/ja/docs/tasks/administer-cluster/developing-cloud-controller-manager.md @@ -13,7 +13,7 @@ content_type: concept クラウドプロバイダーはKubernetesプロジェクトとは異なる速度で開発しリリースすることから、プロバイダー特有なコードを`cloud-controller-manager`バイナリから抽象化することで、クラウドベンダーはコアKubernetesコードから独立して発展することができます。 -Kubernetesプロジェクトは、(クラウドプロバイダーの)独自実装を組み込めるGoインターフェースを備えたcloud-controller-managerのスケルトンコードを提供しています。これは、クラウドプロバイダーがKubernetesコアからパッケージをインポートすることでcloud-controller-managerを実装できることを意味します。各クラウドプロバイダーは、利用可能なクラウドプロバイダーのグローバル変数を更新するために`cloudprovider.RegisterCloudProvider`を呼び出し、独自のコードを登録します。 +Kubernetesプロジェクトは、(クラウドプロバイダーの)独自実装を組み込めるGoインターフェースを備えたcloud-controller-managerのスケルトンコードを提供しています。これは、クラウドプロバイダーがKubernetesコアからパッケージをインポートすることでcloud-controller-managerを実装できることを意味します。各クラウドプロバイダーは利用可能なクラウドプロバイダーのグローバル変数を更新するために`cloudprovider.RegisterCloudProvider`を呼び出し、独自のコードを登録します。 ## 開発 @@ -31,4 +31,3 @@ Kubernetesには登録されていない独自のクラウドプロバイダー Kubernetesに登録されているクラウドプロバイダーであれば、{{< glossary_tooltip term_id="daemonset" >}}を使ってあなたのクラスターで動かすことができます。詳細については[Kubernetesクラウドコントローラーマネージャー](/ja/docs/tasks/administer-cluster/running-cloud-controller/)を参照してください。 - From 73e75c7325f9bad53b8986285282d4b5d052ab0a Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Thu, 24 Sep 2020 12:35:42 +0900 Subject: [PATCH 217/252] Update ja/docs/concepts/overview/working-with-objects/labels.md --- .../docs/concepts/overview/working-with-objects/labels.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/ja/docs/concepts/overview/working-with-objects/labels.md b/content/ja/docs/concepts/overview/working-with-objects/labels.md index c7ebacf360..a262dafcda 100644 --- a/content/ja/docs/concepts/overview/working-with-objects/labels.md +++ b/content/ja/docs/concepts/overview/working-with-objects/labels.md @@ -81,7 +81,7 @@ spec: ## ラベルセレクター {#label-selectors} -[名前とUID](/docs/user-guide/identifiers)とは異なり、ラベルはユニーク性を提供しません。通常、多くのオブジェクトが同じラベルを保持することを想定します。 +[名前とUID](/ja/docs/concepts/overview/working-with-objects/names/)とは異なり、ラベルはユニーク性を提供しません。通常、多くのオブジェクトが同じラベルを保持することを想定します。 *ラベルセレクター* を介して、クライアントとユーザーはオブジェクトのセットを指定できます。ラベルセレクターはKubernetesにおいてコアなグルーピング機能となります。 @@ -222,7 +222,7 @@ selector: #### *集合ベース* の要件指定をサポートするリソース -[`Job`](/docs/concepts/workloads/controllers/jobs-run-to-completion/)や[`Deployment`](/ja/docs/concepts/workloads/controllers/deployment/)、[`ReplicaSet`](/ja/docs/concepts/workloads/controllers/replicaset/)や[`DaemonSet`](/ja/docs/concepts/workloads/controllers/daemonset/)などの比較的新しいリソースは、*集合ベース* での要件指定もサポートしています。 +[`Job`](/docs/concepts/workloads/controllers/job/)や[`Deployment`](/ja/docs/concepts/workloads/controllers/deployment/)、[`ReplicaSet`](/ja/docs/concepts/workloads/controllers/replicaset/)や[`DaemonSet`](/ja/docs/concepts/workloads/controllers/daemonset/)などの比較的新しいリソースは、*集合ベース* での要件指定もサポートしています。 ```yaml selector: matchLabels: @@ -238,6 +238,6 @@ selector: #### Nodeのセットを選択する ラベルを選択するための1つのユースケースはPodがスケジュールできるNodeのセットを制限することです。 -さらなる情報に関しては、[Node選定](/ja/docs/concepts/configuration/assign-pod-node/) のドキュメントを参照してください。 +さらなる情報に関しては、[Node選定](/docs/concepts/scheduling-eviction/assign-pod-node/) のドキュメントを参照してください。 From 384bb3de92a1e8b6a07819cbae83e49785d554c7 Mon Sep 17 00:00:00 2001 From: Takaaki Fujii Date: Sat, 19 Sep 2020 17:48:58 +0900 Subject: [PATCH 218/252] translated kubectl overview.md --- content/ja/docs/reference/kubectl/overview.md | 116 +++++++++++------- 1 file changed, 71 insertions(+), 45 deletions(-) diff --git a/content/ja/docs/reference/kubectl/overview.md b/content/ja/docs/reference/kubectl/overview.md index c45e055b41..c291da9e44 100644 --- a/content/ja/docs/reference/kubectl/overview.md +++ b/content/ja/docs/reference/kubectl/overview.md @@ -1,4 +1,5 @@ --- +reviewers: title: kubectlの概要 content_type: concept weight: 20 @@ -8,9 +9,9 @@ card: --- -`kubectl`は、Kubernetesクラスターを制御するためのコマンドラインツールです。`kubectl`は、`$HOME/.kube`ディレクトリにある`config`という名前のファイルを探します。他の[kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)ファイルは、`KUBECONFIG`環境変数を設定するか、[`--kubeconfig`](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)フラグを設定することで指定できます。 +`kubectl`コマンドラインツールを使うと、Kubernetesクラスターを制御できます。環境設定のために、`kubectl`は、`$HOME/.kube`ディレクトリにある`config`という名前のファイルを探します。他の[kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)ファイルは、`KUBECONFIG`環境変数を設定するか、[`--kubeconfig`](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)フラグを設定することで指定できます。 +この概要では、`kubectl`の構文を扱い、コマンド操作を説明し、一般的な例を示します。サポートされているすべてのフラグやサブコマンドを含め、各コマンドの詳細については、[kubectl](/docs/reference/generated/kubectl/kubectl-commands/)リファレンスドキュメントを参照してください。インストール方法については、[kubectlのインストールおよびセットアップ](/ja/docs/tasks/tools/install-kubectl/)をご覧ください。 -この概要では、`kubectl`の構文を扱い、コマンド操作を説明し、一般的な例を示します。サポートされているすべてのフラグやサブコマンドを含め、各コマンドの詳細については、[kubectl](/docs/reference/generated/kubectl/kubectl-commands/)リファレンスドキュメントを参照してください。インストール方法については、[kubectlのインストールおよびセットアップ](/ja/docs/tasks/kubectl/install/)をご覧ください。 @@ -29,11 +30,11 @@ kubectl [command] [TYPE] [NAME] [flags] * `TYPE`: [リソースタイプ](#resource-types)を指定します。リソースタイプは大文字と小文字を区別せず、単数形や複数形、省略形を指定できます。例えば、以下のコマンドは同じ出力を生成します。 - ```shell - kubectl get pod pod1 - kubectl get pods pod1 - kubectl get po pod1 - ``` + ```shell + kubectl get pod pod1 + kubectl get pods pod1 + kubectl get po pod1 + ``` * `NAME`: リソースの名前を指定します。名前は大文字と小文字を区別します。`kubectl get pods`のように名前が省略された場合は、すべてのリソースの詳細が表示されます。 @@ -49,7 +50,7 @@ kubectl [command] [TYPE] [NAME] [flags] * リソースを1つ以上のファイルで指定する場合は、`-f file1 -f file2 -f file<#>`とします。 - * 特に設定ファイルについては、YAMLの方がより使いやすいため、[JSONではなくYAMLを使用してください](/docs/concepts/configuration/overview/#general-configuration-tips)。
+ * 特に設定ファイルについては、YAMLの方がより使いやすいため、[JSONではなくYAMLを使用してください](/ja/docs/concepts/configuration/overview/#一般的な設定のtips)。
例: `kubectl get pod -f ./pod.yaml` * `flags`: オプションのフラグを指定します。例えば、`-s`または`--server`フラグを使って、Kubernetes APIサーバーのアドレスやポートを指定できます。
@@ -64,41 +65,59 @@ kubectl [command] [TYPE] [NAME] [flags] 以下の表に、`kubectl`のすべての操作の簡単な説明と一般的な構文を示します。 -操作 | 構文 | 説明 +操作                 | 構文 | 説明 -------------------- | -------------------- | -------------------- +`alpha`| `kubectl alpha SUBCOMMAND [flags]` | アルファ機能に該当する利用可能なコマンドを一覧表示します。これらの機能は、デフォルトではKubernetesクラスターで有効になっていません。 `annotate` | kubectl annotate (-f FILENAME | TYPE NAME | TYPE/NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags] | 1つ以上のリソースのアノテーションを、追加または更新します。 -`api-versions` | `kubectl api-versions [flags]` | 利用可能なAPIバージョンを表示します。 +`api-resources` | `kubectl api-resources [flags]` | 利用可能なAPIリソースを一覧表示します。 +`api-versions` | `kubectl api-versions [flags]` | 利用可能なAPIバージョンを一覧表示します。 `apply` | `kubectl apply -f FILENAME [flags]`| ファイルまたは標準出力から、リソースの設定変更を適用します。 `attach` | `kubectl attach POD -c CONTAINER [-i] [-t] [flags]` | 実行中のコンテナにアタッチして、出力ストリームを表示するか、コンテナ(標準入力)と対話します。 +`auth` | `kubectl auth [flags] [options]` | 認可を検査します。 `autoscale` | kubectl autoscale (-f FILENAME | TYPE NAME | TYPE/NAME) [--min=MINPODS] --max=MAXPODS [--cpu-percent=CPU] [flags] | ReplicationControllerで管理されているPodのセットを、自動的にスケールします。 +`certificate` | `kubectl certificate SUBCOMMAND [options]` | 証明書のリソースを変更します。 `cluster-info` | `kubectl cluster-info [flags]` | クラスター内のマスターとサービスに関するエンドポイント情報を表示します。 +`completion` | `kubectl completion SHELL [options]` | 指定されたシェル(bashまたはzsh)のシェル補完コードを出力します。 `config` | `kubectl config SUBCOMMAND [flags]` | kubeconfigファイルを変更します。詳細は、個々のサブコマンドを参照してください。 +`convert` | `kubectl convert -f FILENAME [options]` | 異なるAPIバージョン間で設定ファイルを変換します。YAMLとJSONに対応しています。 +`cordon` | `kubectl cordon NODE [options]` | Nodeをスケジュール不可に設定します。 +`cp` | `kubectl cp [options]` | コンテナとの間でファイルやディレクトリをコピーします。 `create` | `kubectl create -f FILENAME [flags]` | ファイルまたは標準出力から、1つ以上のリソースを作成します。 `delete` | kubectl delete (-f FILENAME | TYPE [NAME | /NAME | -l label | --all]) [flags] | ファイル、標準出力、またはラベルセレクター、リソースセレクター、リソースを指定して、リソースを削除します。 `describe` | kubectl describe (-f FILENAME | TYPE [NAME_PREFIX | /NAME | -l label]) [flags] | 1つ以上のリソースの詳細な状態を表示します。 `diff` | `kubectl diff -f FILENAME [flags]`| ファイルまたは標準出力と、現在の設定との差分を表示します。 +`drain` | `kubectl drain NODE [options]` | メンテナンスの準備のためにNodeをdrainします。 `edit` | kubectl edit (-f FILENAME | TYPE NAME | TYPE/NAME) [flags] | デファルトのエディタを使い、サーバー上の1つ以上のリソースリソースの定義を編集し、更新します。 `exec` | `kubectl exec POD [-c CONTAINER] [-i] [-t] [flags] [-- COMMAND [args...]]` | Pod内のコンテナに対して、コマンドを実行します。 `explain` | `kubectl explain [--recursive=false] [flags]` | 様々なリソースのドキュメントを取得します。例えば、Pod、Node、Serviceなどです。 `expose` | kubectl expose (-f FILENAME | TYPE NAME | TYPE/NAME) [--port=port] [--protocol=TCP|UDP] [--target-port=number-or-name] [--name=name] [--external-ip=external-ip-of-service] [--type=type] [flags] | ReplicationController、Service、Podを、新しいKubernetesサービスとして公開します。 `get` | kubectl get (-f FILENAME | TYPE [NAME | /NAME | -l label]) [--watch] [--sort-by=FIELD] [[-o | --output]=OUTPUT_FORMAT] [flags] | 1つ以上のリソースを表示します。 +`kustomize` | `kubectl kustomize [flags] [options]` | kustomization.yamlファイル内の指示から生成されたAPIリソースのセットを一覧表示します。引数はファイルを含むディレクトリのPath，またはリポジトリルートに対して同じ場所を示すパスサフィックス付きのgitリポジトリのURLを指定しなければなりません。 `label` | kubectl label (-f FILENAME | TYPE NAME | TYPE/NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags] | 1つ以上のリソースのラベルを、追加または更新します。 `logs` | `kubectl logs POD [-c CONTAINER] [--follow] [flags]` | Pod内のコンテナのログを表示します。 +`options` | `kubectl options` | すべてのコマンドに適用されるグローバルコマンドラインオプションを一覧表示します。 `patch` | kubectl patch (-f FILENAME | TYPE NAME | TYPE/NAME) --patch PATCH [flags] | Strategic Merge Patchの処理を使用して、リソースの1つ以上のフィールドを更新します。 -`port-forward` | `kubectl port-forward POD [LOCAL_PORT:]REMOTE_PORT [...[LOCAL_PORT_N:]REMOTE_PORT_N] [flags]` | 1つ以上のリーカルポートを、Podに転送します。 +`plugin` | `kubectl plugin [flags] [options]` | プラグインと対話するためのユーティリティを提供します。 +`port-forward` | `kubectl port-forward POD [LOCAL_PORT:]REMOTE_PORT [...[LOCAL_PORT_N:]REMOTE_PORT_N] [flags]` | 1つ以上のローカルポートを、Podに転送します。 `proxy` | `kubectl proxy [--port=PORT] [--www=static-dir] [--www-prefix=prefix] [--api-prefix=prefix] [flags]` | Kubernetes APIサーバーへのプロキシーを実行します。 `replace` | `kubectl replace -f FILENAME` | ファイルや標準出力から、リソースを置き換えます。 -`run` | `kubectl run NAME --image=image [--env="key=value"] [--port=port] [--replicas=replicas] [--dry-run=server|client|none] [--overrides=inline-json] [flags]` | 指定したイメージを、クラスタ上で実行します。 -`scale` | kubectl scale (-f FILENAME | TYPE NAME | TYPE/NAME) --replicas=COUNT [--resource-version=version] [--current-replicas=count] [flags] | していしたReplicationControllerのサイズを更新します。 +`rollout` | `kubectl rollout SUBCOMMAND [options]` | リソースのロールアウトを管理します。有効なリソースには、Deployment、DaemonSetとStatefulSetが含まれます。 +`run` | kubectl run NAME --image=image [--env="key=value"] [--port=port] [--dry-run=server|client|none] [--overrides=inline-json] [flags] | 指定したイメージを、クラスタ上で実行します。 +`scale` | kubectl scale (-f FILENAME | TYPE NAME | TYPE/NAME) --replicas=COUNT [--resource-version=version] [--current-replicas=count] [flags] | 指定したReplicationControllerのサイズを更新します。 +`set` | `kubectl set SUBCOMMAND [options]` | アプリケーションリソースを設定します。 +`taint` | `kubectl taint NODE NAME KEY_1=VAL_1:TAINT_EFFECT_1 ... KEY_N=VAL_N:TAINT_EFFECT_N [options]` | 1つ以上のNodeのtaintを更新します。 +`top` | `kubectl top [flags] [options]` | リソース(CPU/メモリー/ストレージ)の使用量を表示します。 +`uncordon` | `kubectl uncordon NODE [options]` | Nodeをスケジュール可に設定します。 `version` | `kubectl version [--client] [flags]` | クライアントとサーバーで実行中のKubernetesのバージョンを表示します。 +`wait` | kubectl wait ([-f FILENAME] | resource.group/resource.name | resource.group [(-l label | --all)]) [--for=delete|--for condition=available] [options] | 実験中の機能: 1つ以上のリソースが特定の状態になるまで待ちます。 -コマンド操作の詳細については、[kubectl](/docs/user-guide/kubectl/)リファレンスドキュメントを参照してください。 +コマンド操作について詳しく知りたい場合は、[kubectl](/docs/reference/kubectl/kubectl/)リファレンスドキュメントを参照してください。 ## リソースタイプ {#resource-types} 以下の表に、サポートされているすべてのリソースと、省略されたエイリアスの一覧を示します。 -(この出力は`kubectl api-resources`から取得でき、Kubernetes 1.13.3時点で正確です。) +(この出力は`kubectl api-resources`から取得でき、Kubernetes 1.13.3時点で正確でした。) | リソース名 | 短縮名 | APIグループ | 名前空間に属するか | リソースの種類 | |---|---|---|---|---| @@ -154,7 +173,7 @@ kubectl [command] [TYPE] [NAME] [flags] ## 出力オプション -ある特定のコマンドの出力に対してフォーマットやソートを行う方法については、以下の節を参照してください。どのコマンドが様々な出力オプションをサポートしているかについては、[kubectl](/docs/user-guide/kubectl/)リファレンスドキュメントをご覧ください。 +ある特定のコマンドの出力に対してフォーマットやソートを行う方法については、以下の節を参照してください。どのコマンドが様々な出力オプションをサポートしているかについては、[kubectl](/docs/reference/kubectl/kubectl/)リファレンスドキュメントをご覧ください。 ### 出力のフォーマット @@ -187,13 +206,12 @@ kubectl [command] [TYPE] [NAME] -o kubectl get pod web-pod-13je7 -o yaml ``` -各コマンドでサポートされている出力フォーマットの詳細については、[kubectl](/docs/user-guide/kubectl/)リファレンスドキュメントを参照してください。 +各コマンドでサポートされている出力フォーマットの詳細については、[kubectl](/docs/reference/kubectl/kubectl/)リファレンスドキュメントを参照してください。 #### カスタムカラム {#custom-columns} カスタムカラムを定義して、必要な詳細のみをテーブルに出力するには、`custom-columns`オプションを使います。カスタムカラムをインラインで定義するか、`-o custom-columns=`または`-o custom-columns-file=`のようにテンプレートファイルを使用するかを選択できます。 - ##### 例 インラインで定義する例は、以下の通りです。 @@ -214,10 +232,9 @@ kubectl get pods -o custom-columns-file=template.txt NAME RSRC metadata.name metadata.resourceVersion ``` - どちらのコマンドを実行した場合でも、以下の結果を得ます。 -```shell +``` NAME RSRC submit-queue 610995 ``` @@ -228,22 +245,21 @@ submit-queue 610995 つまり、与えられた任意のリソースについて、サーバーはそのリソースに関連する列や行を返し、クライアントが表示できるようにします。 これにより、サーバーが表示の詳細をカプセル化することで、同一クラスターに対して使用されているクライアント間で、一貫した人間が読みやすい出力が可能です。 -この機能は、`kubectl`1.11以降ではデフォルトで有効になっています。無効にするには、`kubectl get`コマンドに`--server-print=false`フラグを追加します。 +この機能は、デフォルトで有効になっています。無効にするには、`kubectl get`コマンドに`--server-print=false`フラグを追加します。 ##### 例 Podの状態に関する情報を表示するには、以下のようなコマンドを使用します。 - ```shell kubectl get pods --server-print=false ``` 以下のように出力されます。 -```shell -NAME READY STATUS RESTARTS AGE -pod-name 1/1 Running 0 1m +``` +NAME AGE +pod-name 1m ``` ### オブジェクトリストのソート @@ -314,6 +330,7 @@ kubectl describe pods/ # ReplicationController が管理しているすべてのPodの詳細を表示します。 # ReplicationControllerによって作成された任意のPodには、ReplicationControllerの名前がプレフィックスとして付与されます。 +kubectl describe pods # すべてのPodの詳細を表示します。 kubectl describe pods @@ -329,8 +346,8 @@ kubectl describe pods # pod.yamlファイルで指定されたタイプと名前を用いて、Podを削除します。 kubectl delete -f pod.yaml -# name=というラベルを持つPodとServiceをすべて削除します。 -kubectl delete pods,services -l name= +# '='というラベルを持つPodとServiceをすべて削除します。 +kubectl delete pods,services -l = # 初期化されていないPodを含む、すべてのPodを削除します。 kubectl delete pods --all @@ -340,14 +357,13 @@ kubectl delete pods --all ```shell # Pod から、'date'を実行している時の出力を取得します。デフォルトでは、最初のコンテナから出力されます。 -kubectl exec date +kubectl exec -- date # Pod のコンテナ から、'date'を実行している時の出力を取得します。 -kubectl exec -c date +kubectl exec -c -- date # インタラクティブな TTY を取得し、Pod から/bin/bashを実行します。デフォルトでは、最初のコンテナから出力されます。 -Get an interactive TTY and run /bin/bash from pod . By default, output is from the first container. -kubectl exec -ti /bin/bash +kubectl exec -ti -- /bin/bash ``` `kubectl logs` - Pod内のコンテナのログを表示します。 @@ -378,16 +394,20 @@ cat service.yaml | kubectl diff -f - # 任意の言語でシンプルなプラグインを作成し、生成される実行可能なファイルに # プレフィックス"kubectl-"で始まる名前を付けます。 cat ./kubectl-hello -#!/bin/bash +``` +```shell +#!/bin/sh # このプラグインは、"hello world"という単語を表示します。 echo "hello world" - -# プラグインを書いたら、実行可能にします。 -sudo chmod +x ./kubectl-hello +``` +プラグインを書いたら、実行可能にします。 +```bash +chmod a+x ./kubectl-hello # さらに、PATH内の場所に移動させます。 sudo mv ./kubectl-hello /usr/local/bin +sudo chown root:root /usr/local/bin # これでkubectlプラグインを作成し、"インストール"できました。 # 通常のコマンドのようにkubectlから呼び出すことで、プラグインを使用できます。 @@ -398,14 +418,16 @@ hello world ``` ```shell -# 単純にPATHから削除することで、プラグインを"アンインストール"できます。 +# 配置したPATHのフォルダから削除することで、プラグインを"アンインストール"できます。 sudo rm /usr/local/bin/kubectl-hello ``` -`kubectl`で利用可能なプラグインをすべて表示するには、以下のように`kubectl plugin list`サブコマンドを使用します。 +`kubectl`で利用可能なプラグインをすべて表示するには、`kubectl plugin list`サブコマンドを使用してください。 + ```shell kubectl plugin list ``` +出力は以下のようになります。 ``` The following kubectl-compatible plugins are available: @@ -413,9 +435,10 @@ The following kubectl-compatible plugins are available: /usr/local/bin/kubectl-foo /usr/local/bin/kubectl-bar ``` + +`kubectl plugin list`コマンドは、実行不可能なプラグインや、他のプラグインの影に隠れてしまっているプラグインなどについて、警告することもできます。例えば、以下のようになります。 ```shell -# このコマンドで、実行不可能なプラグインや、他のプラグインの影に隠れてしまっているプラグインなどについて、警告することもできます。 -sudo chmod -x /usr/local/bin/kubectl-foo +sudo chmod -x /usr/local/bin/kubectl-foo # 実行権限を削除します。 kubectl plugin list ``` ``` @@ -433,14 +456,19 @@ error: one plugin warning was found ```shell cat ./kubectl-whoami +``` +次の例では、下記の内容を含んだ`kubectl-whoami`が既に作成済であることを前提としています。 +The next few examples assume that you already made `kubectl-whoami` have +the following contents: +```shell #!/bin/bash # このプラグインは、`kubectl config`コマンドを使って # 現在選択されているコンテキストに基づいて、現在のユーザーに関する情報を提供します。 -kubectl config view --template='{{ range .contexts }}{{ if eq .name "'$(kubectl config current-context)'" }}Current user: {{ .context.user }}{{ end }}{{ end }}' +kubectl config view --template='{{ range .contexts }}{{ if eq .name "'$(kubectl config current-context)'" }}Current user: {{ printf "%s\n" .context.user }}{{ end }}{{ end }}' ``` -上記のプラグインを実行すると、以下のように、KUBECONFIGファイルの中で現在選択されているユーザーを含む出力が得られます。 +上記のコマンドを実行すると、KUBECONFIGファイル内のカレントコンテキストのユーザーを含んだ出力を得られます。 ```shell # ファイルを実行可能にします。 @@ -453,10 +481,8 @@ kubectl whoami Current user: plugins-user ``` -プラグインについてより詳しく知りたい場合は、[example cli plugin](https://github.com/kubernetes/sample-cli-plugin)をご覧ください。 - - ## {{% heading "whatsnext" %}} -[kubectl](/docs/reference/generated/kubectl/kubectl-commands/)を使い始めてください。 +* [kubectl](/docs/reference/generated/kubectl/kubectl-commands/)を使い始めてください。 +* プラグインについてより詳しく知りたい場合は, [example cli plugin](https://github.com/kubernetes/sample-cli-plugin)を御覧ください。 From 07ec30894b927cca7cb1e2e97569ecff1245a1a4 Mon Sep 17 00:00:00 2001 From: Takaaki Fujii Date: Sat, 26 Sep 2020 00:12:08 +0900 Subject: [PATCH 219/252] deleted reviewers --- content/ja/docs/reference/kubectl/overview.md | 1 - 1 file changed, 1 deletion(-) diff --git a/content/ja/docs/reference/kubectl/overview.md b/content/ja/docs/reference/kubectl/overview.md index c291da9e44..71ce1844ec 100644 --- a/content/ja/docs/reference/kubectl/overview.md +++ b/content/ja/docs/reference/kubectl/overview.md @@ -1,5 +1,4 @@ --- -reviewers: title: kubectlの概要 content_type: concept weight: 20 From 7617c96d531e52b4cd2fe9af73d721f8beec1b00 Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Tue, 29 Sep 2020 13:00:12 +0900 Subject: [PATCH 220/252] Update ja/docs/reference/access-authn-authz/authentication.md --- .../reference/access-authn-authz/authentication.md | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/content/ja/docs/reference/access-authn-authz/authentication.md b/content/ja/docs/reference/access-authn-authz/authentication.md index 297bcce9d0..1c7e0bb1d1 100644 --- a/content/ja/docs/reference/access-authn-authz/authentication.md +++ b/content/ja/docs/reference/access-authn-authz/authentication.md @@ -13,7 +13,15 @@ weight: 10 すべてのKubernetesクラスターには、2種類のユーザーがあります。Kubernetesによって管理されるサービスアカウントと、通常のユーザーです。 -通常のユーザーは外部の独立したサービスが管理することを想定しています。秘密鍵を配布する管理者、KeystoneやGoogle Accountsのようなユーザーストア、さらにはユーザー名とパスワードのリストを持つファイルなどです。この点において、_Kubernetesは通常のユーザーアカウントを表すオブジェクトを持ちません。_ APIコールを介して、通常のユーザーをクラスターに追加することはできません。 +クラスターと独立したサービスは通常のユーザーを以下の方法で管理することを想定しています。 + +- 秘密鍵を配布する管理者 +- KyestoneやGoogle Accountsのようなユーザーストア +- ユーザー名とパスワードのリストを持つファイル + +これを考慮すると、 _Kubernetesは通常のユーザーアカウントを表すオブジェクトを持ちません。_ APIコールを介して、通常のユーザーをクラスターに追加することはできません。 + +APIコールを介して通常のユーザーを追加できませんが、クラスターの認証局(CA)に署名された有効な証明書で表すユーザーは認証済みと判断されます。この構成では、Kubernetesは証明書の‘subject’内にある一般的な名前フィールド(e.g., “/CN=bob”)からユーザー名を特定します。そこから、ロールベースアクセス制御(RBAC)サブシステムは、ユーザーがあるリソースにおける特定の操作を実行するために認証済みかどうか特定します。詳細は、 [証明書要求](/docs/reference/access-authn-authz/certificate-signing-requests/#normal-user)内の通常のユーザーの題目を参照してください。 対照的に、サービスアカウントはKubernetes APIによって管理されるユーザーです。サービスアカウントは特定の名前空間にバインドされており、APIサーバーによって自動的に作成されるか、APIコールによって手動で作成されます。サービスアカウントは、`Secrets`として保存された資格情報の集合に紐付けられています。これをPodにマウントすることで、クラスター内のプロセスがKubernetes APIと通信できるようにします。 @@ -236,7 +244,7 @@ Secretは常にbase64でエンコードされるため、これらの値もbase6 重要なのは、APIサーバーはOAuth2クライアントではなく、ある単一の発行者を信頼するようにしか設定できないことです。これにより、サードパーティーに発行されたクレデンシャルを信頼せずに、Googleのようなパブリックプロバイダーを使用することができます。複数のOAuthクライアントを利用したい管理者は、`azp`クレームをサポートしているプロバイダや、あるクライアントが別のクライアントに代わってトークンを発行できるような仕組みを検討する必要があります。 -KubernetesはOpenID Connect IDプロバイダーを提供していません。既存のパブリックなOpenID Connect IDプロバイダー(Googleや[その他](http://connect2id.com/products/nimbus-oauth-openid-connect-sdk/openid-connect-providers)など)を使用できます。もしくは、CoreOS [dex](https://github.com/coreos/dex)、[Keycloak](https://github.com/keycloak/keycloak)、CloudFoundry[UAA](https://github.com/cloudfoundry/uaa)、Tremolo Securityの[OpenUnison](https://github.com/tremolosecurity/openunison)など、独自のIDプロバイダーを実行することもできます。 +KubernetesはOpenID Connect IDプロバイダーを提供していません。既存のパブリックなOpenID Connect IDプロバイダー(Googleや[その他](https://connect2id.com/products/nimbus-oauth-openid-connect-sdk/openid-connect-providers)など)を使用できます。もしくは、CoreOS [dex](https://github.com/coreos/dex)、[Keycloak](https://github.com/keycloak/keycloak)、CloudFoundry[UAA](https://github.com/cloudfoundry/uaa)、Tremolo Securityの[OpenUnison](https://github.com/tremolosecurity/openunison)など、独自のIDプロバイダーを実行することもできます。 IDプロバイダーがKubernetesと連携するためには、以下のことが必要です。 @@ -319,7 +327,7 @@ Webhook認証は、Bearerトークンを検証するためのフックです。 * `--authentication-token-webhook-config-file`: リモートのWebhookサービスへのアクセス方法を記述した設定ファイルです * `--authentication-token-webhook-cache-ttl`: 認証をキャッシュする時間を決定します。デフォルトは2分です -設定ファイルは、[kubeconfig](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)のファイル形式を使用します。 +設定ファイルは、[kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)のファイル形式を使用します。 ファイル内で、`clusters`はリモートサービスを、`users`はAPIサーバーのWebhookを指します。例えば、以下のようになります。 ```yaml From be90e20b411055c38def426a6bfcc44bac77e3ee Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Thu, 1 Oct 2020 09:34:29 +0900 Subject: [PATCH 221/252] Update ja/docs/reference/access-authn-authz/authentication.md --- content/ja/docs/reference/access-authn-authz/authentication.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/reference/access-authn-authz/authentication.md b/content/ja/docs/reference/access-authn-authz/authentication.md index 1c7e0bb1d1..5e6b47054d 100644 --- a/content/ja/docs/reference/access-authn-authz/authentication.md +++ b/content/ja/docs/reference/access-authn-authz/authentication.md @@ -16,7 +16,7 @@ weight: 10 クラスターと独立したサービスは通常のユーザーを以下の方法で管理することを想定しています。 - 秘密鍵を配布する管理者 -- KyestoneやGoogle Accountsのようなユーザーストア +- KeystoneやGoogle Accountsのようなユーザーストア - ユーザー名とパスワードのリストを持つファイル これを考慮すると、 _Kubernetesは通常のユーザーアカウントを表すオブジェクトを持ちません。_ APIコールを介して、通常のユーザーをクラスターに追加することはできません。 From efe076f908b7cee279b8a048316898a41e797b94 Mon Sep 17 00:00:00 2001 From: yu-kasuya Date: Fri, 2 Oct 2020 10:03:13 +0900 Subject: [PATCH 222/252] Apply suggestions from code review Co-authored-by: nasa9084 --- .../ja/docs/reference/access-authn-authz/authentication.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/reference/access-authn-authz/authentication.md b/content/ja/docs/reference/access-authn-authz/authentication.md index 5e6b47054d..98cafd2735 100644 --- a/content/ja/docs/reference/access-authn-authz/authentication.md +++ b/content/ja/docs/reference/access-authn-authz/authentication.md @@ -13,7 +13,7 @@ weight: 10 すべてのKubernetesクラスターには、2種類のユーザーがあります。Kubernetesによって管理されるサービスアカウントと、通常のユーザーです。 -クラスターと独立したサービスは通常のユーザーを以下の方法で管理することを想定しています。 +クラスターから独立したサービスは通常のユーザーを以下の方法で管理することを想定されています。 - 秘密鍵を配布する管理者 - KeystoneやGoogle Accountsのようなユーザーストア @@ -21,7 +21,7 @@ weight: 10 これを考慮すると、 _Kubernetesは通常のユーザーアカウントを表すオブジェクトを持ちません。_ APIコールを介して、通常のユーザーをクラスターに追加することはできません。 -APIコールを介して通常のユーザーを追加できませんが、クラスターの認証局(CA)に署名された有効な証明書で表すユーザーは認証済みと判断されます。この構成では、Kubernetesは証明書の‘subject’内にある一般的な名前フィールド(e.g., “/CN=bob”)からユーザー名を特定します。そこから、ロールベースアクセス制御(RBAC)サブシステムは、ユーザーがあるリソースにおける特定の操作を実行するために認証済みかどうか特定します。詳細は、 [証明書要求](/docs/reference/access-authn-authz/certificate-signing-requests/#normal-user)内の通常のユーザーの題目を参照してください。 +APIコールを介して通常のユーザーを追加できませんが、クラスターの認証局(CA)に署名された有効な証明書で表すユーザーは認証済みと判断されます。この構成では、Kubernetesは証明書の‘subject’内にある一般的な名前フィールド(例えば、“/CN=bob”)からユーザー名を特定します。そこから、ロールベースアクセス制御(RBAC)サブシステムは、ユーザーがあるリソースにおける特定の操作を実行するために認証済みかどうか特定します。詳細は、 [証明書要求](/docs/reference/access-authn-authz/certificate-signing-requests/#normal-user)内の通常のユーザーの題目を参照してください。 対照的に、サービスアカウントはKubernetes APIによって管理されるユーザーです。サービスアカウントは特定の名前空間にバインドされており、APIサーバーによって自動的に作成されるか、APIコールによって手動で作成されます。サービスアカウントは、`Secrets`として保存された資格情報の集合に紐付けられています。これをPodにマウントすることで、クラスター内のプロセスがKubernetes APIと通信できるようにします。 From 55393e833f9cae25683109037f4ebcd4bf659a84 Mon Sep 17 00:00:00 2001 From: hikkie3110 <3110hikaru326@gmail.com> Date: Tue, 29 Sep 2020 21:36:35 +0900 Subject: [PATCH 223/252] update cassandra.md for v1.18 --- .../stateful-application/cassandra.md | 48 +++++++++++-------- 1 file changed, 28 insertions(+), 20 deletions(-) diff --git a/content/ja/docs/tutorials/stateful-application/cassandra.md b/content/ja/docs/tutorials/stateful-application/cassandra.md index 32b215e62d..23b2d0967e 100644 --- a/content/ja/docs/tutorials/stateful-application/cassandra.md +++ b/content/ja/docs/tutorials/stateful-application/cassandra.md @@ -5,14 +5,18 @@ weight: 30 --- -このチュートリアルでは、[Apache Cassandra](http://cassandra.apache.org/)をKubernetes上で実行する方法を紹介します。データベースの一種であるCassandraには、データの耐久性(アプリケーションの*状態*)を提供するために永続ストレージが必要です。この例では、カスタムのCassandraのseed providerにより、Cassandraクラスターに参加した新しいCassandraインスタンスを検出できるようにします。 +このチュートリアルでは、[Apache Cassandra](http://cassandra.apache.org/)をKubernetes上で実行する方法を紹介します。 +データベースの一種であるCassandraには、データの耐久性(アプリケーションの_状態_)を提供するために永続ストレージが必要です。 +この例では、カスタムのCassandraのseed providerにより、Cassandraクラスターに参加した新しいCassandraインスタンスを検出できるようにします。 -*StatefulSet*を利用すると、ステートフルなアプリケーションをKubernetesクラスターにデプロイするのが簡単になります。このチュートリアルで使われている機能のより詳しい情報は、[StatefulSet](/ja/docs/concepts/workloads/controllers/statefulset/)を参照してください。 +*StatefulSet*を利用すると、ステートフルなアプリケーションをKubernetesクラスターにデプロイするのが簡単になります。 +このチュートリアルで使われている機能のより詳しい情報は、[StatefulSet](/ja/docs/concepts/workloads/controllers/statefulset/)を参照してください。 {{< note >}} -CassandraとKubernetesは、ともにクラスターのメンバーを表すために*ノード*という用語を使用しています。このチュートリアルでは、StatefulSetに属するPodはCassandraのノードであり、Cassandraクラスター(*ring*と呼ばれます)のメンバーでもあります。これらのPodがKubernetesクラスター内で実行されるとき、Kubernetesのコントロールプレーンは、PodをKubernetesの{{< glossary_tooltip text="Node" term_id="node" >}}上にスケジュールします。 +CassandraとKubernetesは、ともにクラスターのメンバーを表すために_ノード_という用語を使用しています。このチュートリアルでは、StatefulSetに属するPodはCassandraのノードであり、Cassandraクラスター(_ring_と呼ばれます)のメンバーでもあります。これらのPodがKubernetesクラスター内で実行されるとき、Kubernetesのコントロールプレーンは、PodをKubernetesの{{< glossary_tooltip text="Node" term_id="node" >}}上にスケジュールします。 -Cassandraノードが開始すると、*シードリスト*を使ってring上の他のノードの検出が始まります。このチュートリアルでは、Kubernetesクラスター内に現れた新しいCassandra Podを検出するカスタムのCassandraのseed providerをデプロイします。 +Cassandraノードが開始すると、_シードリスト_を使ってring上の他のノードの検出が始まります。 +このチュートリアルでは、Kubernetesクラスター内に現れた新しいCassandra Podを検出するカスタムのCassandraのseed providerをデプロイします。 {{< /note >}} @@ -34,7 +38,8 @@ Cassandraノードが開始すると、*シードリスト*を使ってring上 ### Minikubeのセットアップに関する追加の設定手順 {{< caution >}} -[Minikube](/ja/docs/getting-started-guides/minikube/)は、デフォルトでは1024MiBのメモリと1CPUに設定されます。デフォルトのリソース設定で起動したMinikubeでは、このチュートリアルの実行中にリソース不足のエラーが発生してしまいます。このエラーを回避するためにはMinikubeを次の設定で起動してください。 +[Minikube](/ja/docs/getting-started-guides/minikube/)は、デフォルトでは1024MiBのメモリと1CPUに設定されます。 +デフォルトのリソース設定で起動したMinikubeでは、このチュートリアルの実行中にリソース不足のエラーが発生してしまいます。このエラーを回避するためにはMinikubeを次の設定で起動してください: ```shell minikube start --memory 5120 --cpus=4 @@ -48,7 +53,7 @@ minikube start --memory 5120 --cpus=4 Kubernetesでは、{{< glossary_tooltip text="Service" term_id="service" >}}は同じタスクを実行する{{< glossary_tooltip text="Pod" term_id="pod" >}}の集合を表します。 -以下のServiceは、Cassandra Podとクラスター内のクライアント間のDNSルックアップに使われます。 +以下のServiceは、Cassandra Podとクラスター内のクライアント間のDNSルックアップに使われます: {{< codenew file="application/cassandra/cassandra-service.yaml" >}} @@ -82,12 +87,13 @@ cassandra ClusterIP None 9042/TCP 45s 以下に示すStatefulSetマニフェストは、3つのPodからなるCassandra ringを作成します。 {{< note >}} -この例ではMinikubeのデフォルトのプロビジョナーを使用しています。クラウドを使用している場合、StatefulSetを更新してください。 +この例ではMinikubeのデフォルトのプロビジョナーを使用しています。 +クラウドを使用している場合、StatefulSetを更新してください。 {{< /note >}} {{< codenew file="application/cassandra/cassandra-statefulset.yaml" >}} -`cassandra-statefulset.yaml`ファイルから、CassandraのStatefulSetを作成します。 +`cassandra-statefulset.yaml`ファイルから、CassandraのStatefulSetを作成します: ```shell # cassandra-statefulset.yaml を編集せずにapplyできる場合は、このコマンドを使用してください @@ -110,7 +116,7 @@ kubectl apply -f cassandra-statefulset.yaml kubectl get statefulset cassandra ``` - 結果は次のようになるはずです。 + 結果は次のようになるはずです: ``` NAME DESIRED CURRENT AGE @@ -125,7 +131,7 @@ kubectl apply -f cassandra-statefulset.yaml kubectl get pods -l="app=cassandra" ``` - 結果は次のようになるはずです。 + 結果は次のようになるはずです: ```shell NAME READY STATUS RESTARTS AGE @@ -133,7 +139,7 @@ kubectl apply -f cassandra-statefulset.yaml cassandra-1 0/1 ContainerCreating 0 8s ``` - 3つすべてのPodのデプロイには数分かかる場合があります。デプロイが完了すると、同じコマンドは次のような結果を返します。 + 3つすべてのPodのデプロイには数分かかる場合があります。デプロイが完了すると、同じコマンドは次のような結果を返します: ``` NAME READY STATUS RESTARTS AGE @@ -148,7 +154,7 @@ kubectl apply -f cassandra-statefulset.yaml kubectl exec -it cassandra-0 -- nodetool status ``` - 結果は次のようになるはずです。 + 結果は次のようになるはずです: ``` Datacenter: DC1-K8Demo @@ -171,7 +177,8 @@ kubectl apply -f cassandra-statefulset.yaml kubectl edit statefulset cassandra ``` - このコマンドを実行すると、ターミナルでエディタが起動します。変更が必要な行は`replicas`フィールドです。以下の例は、StatefulSetファイルの抜粋です。 + このコマンドを実行すると、ターミナルでエディタが起動します。変更が必要な行は`replicas`フィールドです。 + 以下の例は、StatefulSetファイルの抜粋です: ```yaml # Please edit the object below. Lines beginning with a '#' will be ignored, @@ -197,13 +204,13 @@ kubectl apply -f cassandra-statefulset.yaml これで、StatefulSetが4つのPodを実行するようにスケールされました。 -1. CassandraのStatefulSetを取得して、変更を確かめます。 +1. CassandraのStatefulSetを取得して、変更を確かめます: ```shell kubectl get statefulset cassandra ``` - 結果は次のようになるはずです。 + 結果は次のようになるはずです: ``` NAME DESIRED CURRENT AGE @@ -214,13 +221,14 @@ kubectl apply -f cassandra-statefulset.yaml ## {{% heading "cleanup" %}} -StatefulSetを削除したりスケールダウンしても、StatefulSetに関係するボリュームは削除されません。StatefulSetに関連するすべてのリソースを自動的に破棄するよりも、データの方がより貴重であるため、安全のためにこのような設定になっています。 +StatefulSetを削除したりスケールダウンしても、StatefulSetに関係するボリュームは削除されません。 +StatefulSetに関連するすべてのリソースを自動的に破棄するよりも、データの方がより貴重であるため、安全のためにこのような設定になっています。 {{< warning >}} ストレージクラスやreclaimポリシーによっては、*PersistentVolumeClaim*を削除すると、関連するボリュームも削除される可能性があります。PersistentVolumeClaimの削除後にもデータにアクセスできるとは決して想定しないでください。 {{< /warning >}} -1. 次のコマンドを実行して(単一のコマンドにまとめています)、CassandraのStatefulSetに含まれるすべてのリソースを削除します。 +1. 次のコマンドを実行して(単一のコマンドにまとめています)、CassandraのStatefulSetに含まれるすべてのリソースを削除します: ```shell grace=$(kubectl get pod cassandra-0 -o=jsonpath='{.spec.terminationGracePeriodSeconds}') \ @@ -230,7 +238,7 @@ StatefulSetを削除したりスケールダウンしても、StatefulSetに関 && kubectl delete persistentvolumeclaim -l app=cassandra ``` -1. 次のコマンドを実行して、CassandraをセットアップしたServiceを削除します。 +1. 次のコマンドを実行して、CassandraをセットアップしたServiceを削除します: ```shell kubectl delete service -l app=cassandra @@ -240,7 +248,8 @@ StatefulSetを削除したりスケールダウンしても、StatefulSetに関 このチュートリアルのPodでは、Googleの[コンテナレジストリ](https://cloud.google.com/container-registry/docs/)の[`gcr.io/google-samples/cassandra:v13`](https://github.com/kubernetes/examples/blob/master/cassandra/image/Dockerfile)イメージを使用しました。このDockerイメージは[debian-base](https://github.com/kubernetes/kubernetes/tree/master/build/debian-base)をベースにしており、OpenJDK 8が含まれています。 -このイメージには、Apache Debianリポジトリの標準のCassandraインストールが含まれます。環境変数を利用すると、`cassandra.yaml`に挿入された値を変更できます。 +このイメージには、Apache Debianリポジトリの標準のCassandraインストールが含まれます。 +環境変数を利用すると、`cassandra.yaml`に挿入された値を変更できます。 | 環境変数 | デフォルト値 | | ------------------------ |:---------------: | @@ -258,4 +267,3 @@ StatefulSetを削除したりスケールダウンしても、StatefulSetに関 * カスタムの[Seed Providerの設定](https://git.k8s.io/examples/cassandra/java/README.md)についてもっと学ぶ。 - From ace9f7b0ed92648bc13054f90c954de5e0c257fd Mon Sep 17 00:00:00 2001 From: hikkie3110 <3110hikaru326@gmail.com> Date: Thu, 8 Oct 2020 10:49:34 +0900 Subject: [PATCH 224/252] update cassandra.md for v1.18 --- content/ja/docs/tutorials/stateful-application/cassandra.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/ja/docs/tutorials/stateful-application/cassandra.md b/content/ja/docs/tutorials/stateful-application/cassandra.md index 23b2d0967e..c5f8ed3986 100644 --- a/content/ja/docs/tutorials/stateful-application/cassandra.md +++ b/content/ja/docs/tutorials/stateful-application/cassandra.md @@ -6,16 +6,16 @@ weight: 30 このチュートリアルでは、[Apache Cassandra](http://cassandra.apache.org/)をKubernetes上で実行する方法を紹介します。 -データベースの一種であるCassandraには、データの耐久性(アプリケーションの_状態_)を提供するために永続ストレージが必要です。 +データベースの一種であるCassandraには、データの耐久性(アプリケーションの _状態_)を提供するために永続ストレージが必要です。 この例では、カスタムのCassandraのseed providerにより、Cassandraクラスターに参加した新しいCassandraインスタンスを検出できるようにします。 *StatefulSet*を利用すると、ステートフルなアプリケーションをKubernetesクラスターにデプロイするのが簡単になります。 このチュートリアルで使われている機能のより詳しい情報は、[StatefulSet](/ja/docs/concepts/workloads/controllers/statefulset/)を参照してください。 {{< note >}} -CassandraとKubernetesは、ともにクラスターのメンバーを表すために_ノード_という用語を使用しています。このチュートリアルでは、StatefulSetに属するPodはCassandraのノードであり、Cassandraクラスター(_ring_と呼ばれます)のメンバーでもあります。これらのPodがKubernetesクラスター内で実行されるとき、Kubernetesのコントロールプレーンは、PodをKubernetesの{{< glossary_tooltip text="Node" term_id="node" >}}上にスケジュールします。 +CassandraとKubernetesは、ともにクラスターのメンバーを表すために _ノード_ という用語を使用しています。このチュートリアルでは、StatefulSetに属するPodはCassandraのノードであり、Cassandraクラスター( _ring_ と呼ばれます)のメンバーでもあります。これらのPodがKubernetesクラスター内で実行されるとき、Kubernetesのコントロールプレーンは、PodをKubernetesの{{< glossary_tooltip text="Node" term_id="node" >}}上にスケジュールします。 -Cassandraノードが開始すると、_シードリスト_を使ってring上の他のノードの検出が始まります。 +Cassandraノードが開始すると、 _シードリスト_ を使ってring上の他のノードの検出が始まります。 このチュートリアルでは、Kubernetesクラスター内に現れた新しいCassandra Podを検出するカスタムのCassandraのseed providerをデプロイします。 {{< /note >}} From c85942837b2da18383bef425821bcccfaa03c66c Mon Sep 17 00:00:00 2001 From: Takaaki Fujii Date: Tue, 6 Oct 2020 00:10:50 +0900 Subject: [PATCH 225/252] finished translating cheartsheet.md --- .../ja/docs/reference/kubectl/cheatsheet.md | 67 +++++++++++++------ 1 file changed, 45 insertions(+), 22 deletions(-) diff --git a/content/ja/docs/reference/kubectl/cheatsheet.md b/content/ja/docs/reference/kubectl/cheatsheet.md index 1ebe1deea6..2cb17247c5 100644 --- a/content/ja/docs/reference/kubectl/cheatsheet.md +++ b/content/ja/docs/reference/kubectl/cheatsheet.md @@ -8,7 +8,7 @@ card: -[Kubectl概要](/docs/reference/kubectl/overview/)と[JsonPathガイド](/docs/reference/kubectl/jsonpath)も合わせてご覧ください。 +[Kubectl概要](/ja/docs/reference/kubectl/overview/)と[JsonPathガイド](/docs/reference/kubectl/jsonpath)も合わせてご覧ください。 このページは`kubectl`コマンドの概要です。 @@ -37,14 +37,14 @@ complete -F __start_kubectl k ### ZSH ```bash -source <(kubectl completion zsh) # 現在のzshシェルでコマンド補完を設定します +source <(kubectl completion zsh) # 現在のzshシェルにコマンド補完を設定します echo "[[ $commands[kubectl] ]] && source <(kubectl completion zsh)" >> ~/.zshrc # zshシェルでのコマンド補完を永続化するために.zshrcに追記します。 ``` ## Kubectlコンテキストの設定 `kubectl`がどのKubernetesクラスターと通信するかを設定します。 -設定ファイル詳細については[kubeconfigを使用した複数クラスターとの認証](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)をご覧ください。 +設定ファイル詳細については[kubeconfigを使用した複数クラスターとの認証](/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)をご覧ください。 ```bash kubectl config view # マージされたkubeconfigの設定を表示します。 @@ -63,7 +63,7 @@ kubectl config get-contexts # コンテキストのリ kubectl config current-context # 現在のコンテキストを表示します kubectl config use-context my-cluster-name # デフォルトのコンテキストをmy-cluster-nameに設定します -# basic認証をサポートする新たなクラスターをkubeconfigに追加します +# basic認証をサポートする新たなユーザーをkubeconfigに追加します kubectl config set-credentials kubeuser/foo.kubernetes.com --username=kubeuser --password=kubepassword # 現在のコンテキストでkubectlのサブコマンドのネームスペースを永続的に変更します @@ -152,7 +152,7 @@ kubectl get pod my-pod -o yaml # PodのYAMLを表示します kubectl describe nodes my-node kubectl describe pods my-pod -# 名前順にソートしたリストを表示します +# 名前順にソートしたServiceのリストを表示します kubectl get services --sort-by=.metadata.name # Restartカウント順にPodのリストを表示します @@ -165,33 +165,33 @@ kubectl get pv --sort-by=.spec.capacity.storage kubectl get pods --selector=app=cassandra -o \ jsonpath='{.items[*].metadata.labels.version}' +# 'ca.crt'のようなピリオドが含まれるキーの値を取得します +kubectl get configmap myconfig \ + -o jsonpath='{.data.ca\.crt}' + # すべてのワーカーノードを取得します（セレクターを使用して、 # 「node-role.kubernetes.io/master」という名前のラベルを持つ結果を除外します） kubectl get node --selector='!node-role.kubernetes.io/master' -# 現在のネームスペースでrunning状態のPodをリストを表示します +# 現在のネームスペースでrunning状態のPodのリストを表示します kubectl get pods --field-selector=status.phase=Running -# すべてのノードのExternal IPをリストを表示します +# すべてのノードのExternal IPのリストを表示します kubectl get nodes -o jsonpath='{.items[*].status.addresses[?(@.type=="ExternalIP")].address}' # 特定のRCに属するPodの名前のリストを表示します # `jq`コマンドは複雑なjsonpathを変換する場合に便利であり、https://stedolan.github.io/jq/で見つけることが可能です - sel=${$(kubectl get rc my-rc --output=json | jq -j '.spec.selector | to_entries | .[] | "\(.key)=\(.value),"')%?} echo $(kubectl get pods --selector=$sel --output=jsonpath={.items..metadata.name}) # すべてのPod(またはラベル付けをサポートする他のKubernetesオブジェクト)のラベルのリストを表示します - kubectl get pods --show-labels # どのノードがready状態か確認します - JSONPATH='{range .items[*]}{@.metadata.name}:{range @.status.conditions[*]}{@.type}={@.status};{end}{end}' \ && kubectl get nodes -o jsonpath="$JSONPATH" | grep "Ready=True" # Podで現在使用中のSecretをすべて表示します - kubectl get pods -o json | jq '.items[].spec.containers[].env[]?.valueFrom.secretKeyRef.name' | grep -v null | sort | uniq # すべてのPodのInitContainerのコンテナIDのリストを表示します @@ -199,15 +199,25 @@ kubectl get pods -o json | jq '.items[].spec.containers[].env[]?.valueFrom.secre kubectl get pods --all-namespaces -o jsonpath='{range .items[*].status.initContainerStatuses[*]}{.containerID}{"\n"}{end}' | cut -d/ -f3 # タイムスタンプでソートされたEventのリストを表示します - kubectl get events --sort-by=.metadata.creationTimestamp # クラスターの現在の状態を、マニフェストが適用された場合のクラスターの状態と比較します。 kubectl diff -f ./my-manifest.yaml + +# Nodeから返されるすべてのキーをピリオド区切りの階層表記で生成します。 +# 複雑にネストされたJSON構造をもつキーを指定したい時に便利です +kubectl get nodes -o json | jq -c 'path(..)|[.[]|tostring]|join(".")' + +# Pod等から返されるすべてのキーをピリオド区切り階層表記で生成します。 +kubectl get pods -o json | jq -c 'path(..)|[.[]|tostring]|join(".")' ``` ## リソースのアップデート +<<<<<<< HEAD +======= + +>>>>>>> 8d357bf1e (finished translating cheartsheet.md) ```bash kubectl set image deployment/frontend www=image:v2 # frontend Deploymentのwwwコンテナイメージをv2にローリングアップデートします kubectl rollout history deployment/frontend # frontend Deploymentの改訂履歴を確認します @@ -253,7 +263,6 @@ kubectl patch sa default --type='json' -p='[{"op": "add", "path": "/secrets/1", ``` ## リソースの編集 - 任意のエディターでAPIリソースを編集します。 ```bash @@ -294,10 +303,10 @@ kubectl logs -f my-pod # Podのログをストリ kubectl logs -f my-pod -c my-container # 複数のコンテナがあるPodで、特定のコンテナのログをストリームで確認します(標準出力) kubectl logs -f -l name=myLabel --all-containers # name-myLabelラベルを持つすべてのコンテナのログをストリームで確認します(標準出力) kubectl run -i --tty busybox --image=busybox -- sh # Podをインタラクティブシェルとして実行します -kubectl run nginx --image=nginx --restart=Never -n +kubectl run nginx --image=nginx -n mynamespace # 特定のネームスペースでnginx Podを実行します -kubectl run nginx --image=nginx --restart=Never # nginx Podを実行し、マニフェストファイルををpod.yamlという名前で書き込みます ---dry-run -o yaml > pod.yaml +kkubectl run nginx --image=nginx # nginx Podを実行し、マニフェストファイルをpod.yamlという名前で書き込みます +--dry-run=client -o yaml > pod.yaml kubectl attach my-pod -i # 実行中のコンテナに接続します kubectl port-forward my-pod 5000:6000 # ローカルマシンのポート5000を、my-podのポート6000に転送します kubectl exec my-pod -- ls / # 既存のPodでコマンドを実行(単一コンテナの場合) @@ -308,9 +317,9 @@ kubectl top pod POD_NAME --containers # 特定のPodとそのコ ## ノードおよびクラスターとの対話処理 ```bash -kubectl cordon my-node # my-nodeにスケーリングされないように設定します +kubectl cordon my-node # my-nodeをスケーリングされないように設定します kubectl drain my-node # メンテナンスの準備としてmy-nodeで動作中のPodを空にします -kubectl uncordon my-node # my-nodeにスケーリングされるように設定します +kubectl uncordon my-node # my-nodeをスケーリングされるように設定します kubectl top node my-node # 特定のノードのメトリクスを表示します kubectl cluster-info # Kubernetesクラスターのマスターとサービスのアドレスを表示します kubectl cluster-info dump # 現在のクラスター状態を標準出力にダンプします @@ -322,7 +331,7 @@ kubectl taint nodes foo dedicated=special-user:NoSchedule ### リソースタイプ -サポートされているすべてのリソースタイプを、それらが[API group](/ja/docs/concepts/overview/kubernetes-api/#api-groups)か[Namespaced](/docs/concepts/overview/working-with-objects/namespaces)、[Kind](/docs/concepts/overview/working-with-objects/kubernetes-objects)に関わらずその短縮名をリストします。 +サポートされているすべてのリソースタイプを、それらが[API group](/ja/docs/concepts/overview/kubernetes-api/#api-groups)か[Namespaced](/ja/docs/concepts/overview/working-with-objects/namespaces)、[Kind](/ja/docs/concepts/overview/working-with-objects/kubernetes-objects)に関わらずその短縮名をリストします。 ```bash kubectl api-resources @@ -345,7 +354,7 @@ kubectl api-resources --api-group=extensions # "extensions" APIグループの 出力フォーマット | 説明 ---------------- | ----------- -`-o=custom-columns=` | カスタムカラムを使用してコンマ区切りのテーブルを表示します +`-o=custom-columns=` | コンマ区切りされたカスタムカラムのリストを指定してテーブルを表示します `-o=custom-columns-file=` | ``ファイル内のカスタムカラムテンプレートを使用してテーブルを表示します `-o=json` | JSON形式のAPIオブジェクトを出力します `-o=jsonpath=