diff --git a/content/ja/docs/concepts/_index.md b/content/ja/docs/concepts/_index.md index 0f03287083..1e22892eca 100644 --- a/content/ja/docs/concepts/_index.md +++ b/content/ja/docs/concepts/_index.md @@ -19,14 +19,14 @@ Kubernetesを機能させるには、*Kubernetes API オブジェクト* を使 一旦desired state (望ましい状態)を設定すると、Pod Lifecycle Event Generator([PLEG](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/pod-lifecycle-event-generator.md))を使用した*Kubernetes コントロールプレーン*が機能し、クラスターの現在の状態をdesired state (望ましい状態)に一致させます。そのためにKubernetesはさまざまなタスク(たとえば、コンテナの起動または再起動、特定アプリケーションのレプリカ数のスケーリング等)を自動的に実行します。Kubernetesコントロールプレーンは、クラスターで実行されている以下のプロセスで構成されています。 -* **Kubernetes Master** :[kube-apiserver](/docs/admin/kube-apiserver/)、[kube-controller-manager](/docs/admin/kube-controller-manager/)、[kube-scheduler](/docs/admin/kube-scheduler/) の3プロセスの集合です。これらのプロセスはクラスター内の一つのノード上で実行されます。実行ノードはマスターノードとして指定します。 +* **Kubernetes Master**: [kube-apiserver](/docs/admin/kube-apiserver/)、[kube-controller-manager](/docs/admin/kube-controller-manager/)、[kube-scheduler](/docs/admin/kube-scheduler/) の3プロセスの集合です。これらのプロセスはクラスター内の一つのノード上で実行されます。実行ノードはマスターノードとして指定します。 * クラスター内の個々の非マスターノードは、それぞれ2つのプロセスを実行します。 - * **[kubelet](/docs/admin/kubelet/)**, Kubernetes Masterと通信します。 - * **[kube-proxy](/docs/admin/kube-proxy/)**, 各ノードのKubernetesネットワークサービスを反映するネットワークプロキシです。 + * **[kubelet](/docs/admin/kubelet/)**: Kubernetes Masterと通信します。 + * **[kube-proxy](/docs/admin/kube-proxy/)**: 各ノードのKubernetesネットワークサービスを反映するネットワークプロキシです。 -## Kubernetesオブジェクト +## Kubernetesオブジェクト {#kubernetes-objects} -Kubernetesには、デプロイ済みのコンテナ化されたアプリケーションやワークロード、関連するネットワークとディスクリソース、クラスターが何をしているかに関するその他の情報といった、システムの状態を表現する抽象が含まれています。これらの抽象は、Kubernetes APIのオブジェクトによって表現されます。詳細については、[Kubernetesオブジェクトについて知る](/ja/docs/concepts/overview/working-with-objects/kubernetes-objects/)をご覧ください。 +Kubernetesには、デプロイ済みのコンテナ化されたアプリケーションやワークロード、関連するネットワークとディスクリソース、クラスターが何をしているかに関するその他の情報といった、システムの状態を表現する抽象が含まれています。これらの抽象は、Kubernetes APIのオブジェクトによって表現されます。詳細については、[Kubernetesオブジェクトについて知る](/ja/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects)をご覧ください。 基本的なKubernetesのオブジェクトは次のとおりです。 @@ -43,7 +43,7 @@ Kubernetesには、[コントローラー](/docs/concepts/architecture/controlle * [ReplicaSet](/ja/docs/concepts/workloads/controllers/replicaset/) * [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/) -## Kubernetesコントロールプレーン +## Kubernetesコントロールプレーン {#kubernetes-control-plane} Kubernetesマスターや kubeletプロセスといったKubernetesコントロールプレーンのさまざまなパーツは、Kubernetesがクラスターとどのように通信するかを統制します。コントロールプレーンはシステム内のすべてのKubernetesオブジェクトの記録を保持し、それらのオブジェクトの状態を管理するために継続的制御ループを実行します。コントロールプレーンの制御ループは常にクラスターの変更に反応し、システム内のすべてのオブジェクトの実際の状態が、指定した状態に一致するように動作します。 diff --git a/content/ja/docs/concepts/architecture/_index.md b/content/ja/docs/concepts/architecture/_index.md index d81eeab89c..b8906ee100 100644 --- a/content/ja/docs/concepts/architecture/_index.md +++ b/content/ja/docs/concepts/architecture/_index.md @@ -1,4 +1,4 @@ --- -title: "Kubernetesのアーキテクチャ" +title: "クラスターのアーキテクチャ" weight: 30 --- diff --git a/content/ja/docs/concepts/architecture/cloud-controller.md b/content/ja/docs/concepts/architecture/cloud-controller.md index d722ced7a6..8cf85db09b 100644 --- a/content/ja/docs/concepts/architecture/cloud-controller.md +++ b/content/ja/docs/concepts/architecture/cloud-controller.md @@ -1,14 +1,14 @@ --- title: クラウドコントローラーマネージャーとそのコンセプト content_type: concept -weight: 30 +weight: 40 --- -クラウドコントローラマネージャー(CCM)のコンセプト(バイナリと混同しないでください)は、もともとクラウドベンダー固有のソースコードと、Kubernetesのコアソースコードを独立して進化させることが出来るように作られました。クラウドコントローラーマネージャーは、Kubernetesコントローラーマネージャー、APIサーバー、そしてスケジューラーのような他のマスターコンポーネントと並行して動きます。またKubernetesのアドオンとしても動かすことができ、その場合はKubernetes上で動きます。 +クラウドコントローラマネージャー(CCM)のコンセプト(バイナリと混同しないでください)は、もともとクラウドベンダー固有のソースコードと、Kubernetesのコアソースコードを独立して進化させることができるように作られました。クラウドコントローラーマネージャーは、Kubernetesコントローラーマネージャー、APIサーバー、そしてスケジューラーのような他のマスターコンポーネントと並行して動きます。またKubernetesのアドオンとしても動かすことができ、その場合はKubernetes上で動きます。 -クラウドコントローラーマネージャーの設計は「プラグインメカニズム」をベースにしています。そうすることで、新しいクラウドプロバイダーがプラグインを使ってKubernetesと簡単に統合出来るようになります。新しいクラウドプロバイダーに向けてKubernetesのオンボーディングを行ったり、古いモデルを利用しているクラウドプロバイダーに、新しいCCMモデルに移行させるような計画があります。 +クラウドコントローラーマネージャーの設計は「プラグインメカニズム」をベースにしています。そうすることで、新しいクラウドプロバイダーがプラグインを使ってKubernetesと簡単に統合できるようになります。新しいクラウドプロバイダーに向けてKubernetesのオンボーディングを行ったり、古いモデルを利用しているクラウドプロバイダーに、新しいCCMモデルに移行させるような計画があります。 このドキュメントでは、クラウドコントローラーマネージャーの背景にあるコンセプトと、それに関連する機能の詳細について話します。 @@ -52,7 +52,7 @@ CCMは、Kubernetesコントローラーマネージャー(KCM)からいくつ ボリュームコントローラーは、意図的にCCMの一部になっていません。複雑さと、ベンダー固有のボリュームロジックを抽象化するのに費やした労力を考え、CCMの一部に移行しないことが決定されました。 {{< /note >}} -CCMを使ったボリュームをサポートする元の計画は、プラガブルなボリュームをサポートするため、Flexボリュームを使うことでした。しかし、競合しているCSIとして知られている機能が、Flexを置き換える予定です。 +CCMを使ったボリュームをサポートする元の計画は、プラガブルなボリュームをサポートするため、[Flex](/docs/concepts/storage/volumes/#flexVolume)ボリュームを使うことでした。しかし、競合している[CSI](/docs/concepts/storage/volumes/#csi)として知られている機能が、Flexを置き換える予定です。 これらのダイナミクスを考慮し、我々はCSIが利用できるようになるまで、間を取った暫定措置を取ることにしました。 @@ -79,11 +79,11 @@ CCMの大半の機能は、KCMから派生しています。前セクション #### ルートコントローラー -ルートコントローラーは、クラスタ内の異なるノード上で稼働しているコンテナが相互に通信出来るように、クラウド内のルートを適切に設定する責務を持ちます。ルートコントローラーはGoogle Compute Engineのクラスターのみに該当します。 +ルートコントローラーは、クラスタ内の異なるノード上で稼働しているコンテナが相互に通信できるように、クラウド内のルートを適切に設定する責務を持ちます。ルートコントローラーはGoogle Compute Engineのクラスターのみに該当します。 #### サービスコントローラー -サービスコントローラーは、サービスの作成、更新、そして削除イベントの待ち受けに責務を持ちます。Kubernetes内のサービスの現在の状態を、クラウド上のロードバランサー(ELB、Google LB、またOracle Cloud Infrastructure LBなど)に反映するための設定を行います。更に、クラウドロードバランサーのバックエンドが最新の状態になっていることを保証します。 +サービスコントローラーは、サービスの作成、更新、そして削除イベントの待ち受けに責務を持ちます。Kubernetes内のサービスの現在の状態を、クラウド上のロードバランサー(ELB、Google LB、またOracle Cloud Infrastructure LBなど)に反映するための設定を行います。さらに、クラウドロードバランサーのバックエンドが最新の状態になっていることを保証します。 ### 2. Kubelet @@ -93,7 +93,7 @@ CCMの大半の機能は、KCMから派生しています。前セクション ## プラグインメカニズム -クラウドコントローラーマネージャーは、Goのインターフェースを利用してクラウドの実装をプラグイン化出来るようにしています。具体的には、[こちら](https://github.com/kubernetes/cloud-provider/blob/9b77dc1c384685cb732b3025ed5689dd597a5971/cloud.go#L42-L62)で定義されているクラウドプロバイダーインターフェースを利用しています。 +クラウドコントローラーマネージャーは、Goのインターフェースを利用してクラウドの実装をプラグイン化できるようにしています。具体的には、[こちら](https://github.com/kubernetes/cloud-provider/blob/9b77dc1c384685cb732b3025ed5689dd597a5971/cloud.go#L42-L62)で定義されているクラウドプロバイダーインターフェースを利用しています。 上で強調した4つの共有コントローラーの実装、そしていくつかの共有クラウドプロバイダーインターフェースと一部の連携機能は、Kubernetesのコアにとどまります。クラウドプロバイダー特有の実装はコア機能外で構築され、コア機能内で定義されたインターフェースを実装します。 @@ -223,13 +223,18 @@ rules: 下記のクラウドプロバイダーがCCMを実装しています: -* [Digital Ocean](https://github.com/digitalocean/digitalocean-cloud-controller-manager) -* [Oracle](https://github.com/oracle/oci-cloud-controller-manager) -* [Azure](https://github.com/kubernetes/cloud-provider-azure) -* [GCP](https://github.com/kubernetes/cloud-provider-gcp) +* [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) + ## クラスター管理 diff --git a/content/ja/docs/concepts/architecture/controller.md b/content/ja/docs/concepts/architecture/controller.md new file mode 100644 index 0000000000..9fd8f201c5 --- /dev/null +++ b/content/ja/docs/concepts/architecture/controller.md @@ -0,0 +1,90 @@ +--- +title: コントローラー +content_type: concept +weight: 30 +--- + + + +ロボット工学やオートメーションの分野において、 _制御ループ_ とは、あるシステムの状態を制御する終了状態のないループのことです。 + +ここでは、制御ループの一例として、部屋の中にあるサーモスタットを挙げます。 + +あなたが温度を設定すると、それはサーモスタットに *目的の状態(desired state)* を伝えることになります。実際の部屋の温度は *現在の状態* です。サーモスタットは、装置をオンまたはオフにすることによって、現在の状態を目的の状態に近づけるように動作します。 + +{{< glossary_definition term_id="controller" length="short">}} + + + +## コントローラーパターン + +コントローラーは少なくとも1種類のKubernetesのリソースを監視します。これらの[オブジェクト](/ja/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects)には目的の状態を表すspecフィールドがあります。リソースのコントローラーは、現在の状態を目的の状態に近づける責務を持ちます。 + +コントローラーは自分自身でアクションを実行する場合もありますが、Kubernetesではコントローラーが{{< glossary_tooltip text="APIサーバー" term_id="kube-apiserver" >}}に意味のある副作用を持つメッセージを送信することが一般的です。以下では、このような例を見ていきます。 + +{{< comment >}} +ネームスペースコントローラーなどの一部のビルトインのコントローラーは、specのないオブジェクトに対して作用します。簡単のため、このページではそのような詳細な説明は省略します。 +{{< /comment >}} + +### APIサーバー経由でコントロールする + +{{< glossary_tooltip term_id="job" >}}コントローラーはKubernetesのビルトインのコントローラーの一例です。ビルトインのコントローラーは、クラスターのAPIサーバーとやりとりをして状態を管理します。 + +Jobは、1つ以上の{{< glossary_tooltip term_id="pod" >}}を起動して、タスクを実行した後に停止する、Kubernetesのリソースです。 + +(1度[スケジュール](/docs/concepts/scheduling-eviction/)されると、Podオブジェクトはkubeletに対する目的の状態の一部になります。) + +Jobコントローラーが新しいタスクを見つけると、その処理が完了するように、クラスター上のどこかで、一連のNode上のkubeletが正しい数のPodを実行することを保証します。ただし、Jobコントローラーは、自分自身でPodやコンテナを実行することはありません。代わりに、APIサーバーに対してPodの作成や削除を依頼します。{{< glossary_tooltip text="コントロールプレーン" term_id="control-plane" >}}上の他のコンポーネントが(スケジュールして実行するべき新しいPodが存在するという)新しい情報を基に動作することによって、最終的に目的の処理が完了します。 + +新しいJobが作成されたとき、目的の状態は、そのJobが完了することです。JobコントローラーはそのJobに対する現在の状態を目的の状態に近づけるようにします。つまり、そのJobが行ってほしい処理を実行するPodを作成し、Jobが完了に近づくようにします。 + +コントローラーは、コントローラーを設定するオブジェクトも更新します。たとえば、あるJobが完了した場合、Jobコントローラーは、Jobオブジェクトに`Finished`というマークを付けます。 + +(これは、部屋が設定温度になったことを示すために、サーモスタットがランプを消灯するのに少し似ています。) + +### 直接的なコントロール + +Jobとは対照的に、クラスターの外部に変更を加える必要があるコントローラーもあります。 + +たとえば、クラスターに十分な数の{{< glossary_tooltip text="Node" term_id="node" >}}が存在することを保証する制御ループの場合、そのコントローラーは、必要に応じて新しいNodeをセットアップするために、現在のクラスターの外部とやりとりをする必要があります。 + +外部の状態とやりとりをするコントローラーは、目的の状態をAPIサーバーから取得した後、外部のシステムと直接通信し、現在の状態を目的の状態に近づけます。 + +(クラスター内のノードを水平にスケールさせるコントローラーが実際に存在します。詳しくは、[クラスターのオートスケーリング](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling)を読んでください。) + +## 目的の状態 vs 現在の状態 {#desired-vs-current} + +Kubernetesはシステムに対してクラウドネイティブな見方をするため、常に変化し続けるような状態を扱えるように設計されています。 + +処理を実行したり、制御ループが故障を自動的に修正したりしているどの時点でも、クラスターは変化中である可能性があります。つまり、クラスターは決して安定した状態にならない可能性があるということです。 + +コントローラーがクラスターのために実行されていて、有用な変更が行われるのであれば、全体的な状態が安定しているかどうかは問題にはなりません。 + +## 設計 + +設計理念として、Kubernetesは多数のコントローラーを使用しており、各コントローラーはクラスターの状態の特定の側面をそれぞれ管理しています。最もよくあるパターンは、特定の制御ループ(コントローラー)が目的の状態として1種類のリソースを使用し、目的の状態を実現することを管理するために別の種類のリソースを用意するというものです。 + +相互にリンクされた単一のモノリシックな制御ループよりは、複数の単純なコントローラーが存在する方が役に立ちます。コントローラーは故障することがあるため、Kubernetesは故障を許容するように設計されています。 + +たとえば、Jobのコントローラーは、Jobオブジェクト(新しい処理を見つけるため)およびPodオブジェクト(Jobを実行し、処理が完了したか確認するため)を監視します。この場合、なにか別のものがJobを作成し、JobコントローラーはPodを作成します。 + +{{< note >}} +同じ種類のオブジェクトを作成または更新するコントローラーが、複数存在する場合があります。実際には、Kubernetesコントローラーは、自分が制御するリソースに関連するリソースにのみ注意を払うように作られています。 + +たとえば、DeploymentとJobがありますが、これらは両方ともPodを作成するものです。しかし、JobコントローラーはDeploymentが作成したPodを削除することはありません。各コントローラーが2つのPodを区別できる情報({{< glossary_tooltip term_id="label" text="ラベル" >}})が存在するためです。 +{{< /note >}} + +## コントローラーを実行する方法 {#running-controllers} + +Kubernetesには、{{< glossary_tooltip term_id="kube-controller-manager" >}}内部で動作する一組のビルトインのコントローラーが用意されています。これらビルトインのコントローラーは、コアとなる重要な振る舞いを提供します。 + +DeploymentコントローラーとJobコントローラーは、Kubernetes自体の一部として同梱されているコントローラーの例です(それゆえ「ビルトイン」のコントローラーと呼ばれます)。Kubernetesは回復性のあるコントロールプレーンを実行できるようにしているため、ビルトインのコントローラーの一部が故障しても、コントロールプレーンの別の部分が作業を引き継いでくれます。 + +Kubernetesを拡張するためにコントロールプレーンの外で動作するコントローラーもあります。もし望むなら、新しいコントローラーを自分で書くこともできます。自作のコントローラーをPodセットとして動作させたり、Kubernetesの外部で動作させることもできます。どのような動作方法が最も適しているかは、そのコントローラーがどのようなことを行うのかに依存します。 + +## {{% heading "whatsnext" %}} + +* [Kubernetesコントロールプレーン](/ja/docs/concepts/#kubernetes-control-plane)について読む +* 基本的な[Kubernetesオブジェクト](/ja/docs/concepts/#kubernetes-objects)について学ぶ +* [Kubernetes API](/ja/docs/concepts/overview/kubernetes-api/)について学ぶ +* 自分でコントローラーを書きたい場合は、「Kubernetesを拡張する」の[エクステンションパターン](/ja/docs/concepts/extend-kubernetes/extend-cluster/#extension-patterns)を読んでください。 diff --git a/content/ja/docs/concepts/architecture/master-node-communication.md b/content/ja/docs/concepts/architecture/master-node-communication.md index 14f0678a20..e15d1187ad 100644 --- a/content/ja/docs/concepts/architecture/master-node-communication.md +++ b/content/ja/docs/concepts/architecture/master-node-communication.md @@ -6,8 +6,8 @@ weight: 20 -本ドキュメントでは、KubernetesにおけるMaster(実態はAPIサーバー)及びクラスター間のコミュニケーション経路についてまとめます。 -この文書の目的は、信頼できないネットワーク上（またはクラウドプロバイダ上の完全にパブリックなIP上）でクラスタを実行できるように、ユーザーがインストールをカスタマイズしてネットワーク構成を強化できるようにすることです。 +本ドキュメントでは、KubernetesにおけるMaster(実態はAPIサーバー)およびクラスター間のコミュニケーション経路についてまとめます。 +この文書の目的は、信頼できないネットワーク上(またはクラウドプロバイダ上の完全にパブリックなIP上)でクラスタを実行できるように、ユーザーがインストールをカスタマイズしてネットワーク構成を強化できるようにすることです。 @@ -16,8 +16,8 @@ weight: 20 ## クラスターからマスターへの通信 -クラスターからマスターへのすべての通信経路は、APIサーバーで終端します（他のマスターコンポーネントはどれもリモートサービスを公開するように設計されていません）。 -一般的には、1つ以上の形式のクライアント[認証](/docs/reference/access-authn-authz/authentication/)が有効になっている状態で、APIサーバーはセキュアなHTTPSポート（443）でリモート接続をlistenするように構成されています。 +クラスターからマスターへのすべての通信経路は、APIサーバーで終端します(他のマスターコンポーネントはどれもリモートサービスを公開するように設計されていません)。 +一般的には、1つ以上の形式のクライアント[認証](/docs/reference/access-authn-authz/authentication/)が有効になっている状態で、APIサーバーはセキュアなHTTPSポート(443)でリモート接続をlistenするように構成されています。 特に[匿名のリクエスト](/docs/reference/access-authn-authz/authentication/#anonymous-requests)または[サービスアカウントトークン](/docs/reference/access-authn-authz/authentication/#service-account-tokens)が許可されている場合は、1つまたは複数の[認証](/docs/reference/access-authn-authz/authorization/)を有効にする必要があります。 ノードには、有効なクライアント認証情報を使って安全にAPIサーバーに接続できるように、クラスターのパブリックなルート証明書をプロビジョニングする必要があります。 @@ -26,15 +26,15 @@ kubeletのクライアント証明書を自動プロビジョニングする方 APIサーバーに接続したいPodは、サービスアカウントを利用することで接続を安全にすることができます。そうすることで、Podが作成されたときにKubernetesがパブリックなルート証明書と有効なBearer TokenをPodに自動的に挿入します。 -`kubernetes`サービスには（すべてのネームスペースで）、APIサーバー上のHTTPSエンドポイントに（kube-proxy経由で）リダイレクトされる仮想IPアドレスが設定されています。 +`kubernetes`サービスには(すべてのネームスペースで)、APIサーバー上のHTTPSエンドポイントに(kube-proxy経由で)リダイレクトされる仮想IPアドレスが設定されています。 マスターコンポーネントは、セキュアなポートを介してクラスターAPIサーバーとも通信します。 -その結果、クラスター（ノードとそのノードで実行されているPod）からマスターへの接続はデフォルトで保護され、信頼できないネットワークやパブリックネットワークを介して実行できます。 +その結果、クラスター(ノードとそのノードで実行されているPod)からマスターへの接続はデフォルトで保護され、信頼できないネットワークやパブリックネットワークを介して実行できます。 ## マスターからクラスターへの通信 -マスター（APIサーバー）からクラスターへの通信には、2つの主要な通信経路があります。 +マスター(APIサーバー)からクラスターへの通信には、2つの主要な通信経路があります。 1つ目は、APIサーバーからクラスター内の各ノードで実行されるkubeletプロセスへの通信です。 2つ目は、APIサーバーのプロキシ機能を介した、APIサーバーから任意のノード、Pod、またはサービスへのアクセスです。 @@ -43,7 +43,7 @@ APIサーバーに接続したいPodは、サービスアカウントを利用 APIサーバーからkubeletへの接続は以下の目的で使用されます: * Podのログを取得する - * 実行中のPodに（kubectlを通して）接続する + * 実行中のPodに(kubectlを通して)接続する * kubeletのポート転送機能を提供する これらの接続は、kubeletのHTTPSエンドポイントで終了します。 @@ -64,7 +64,7 @@ API URL内のノード、Pod、またはサービス名に`https:`を付ける ### SSHトンネル Kubernetesはマスターからクラスターへの通信経路を保護するためにSSHトンネルをサポートしています。 -この設定では、APIサーバーはクラスター内の各ノード（ポート22でlistenしているsshサーバーに接続）へのSSHトンネルを開始し、トンネルを介してkubelet、ノード、Pod、またはサービス宛てのすべてのトラフィックを渡します。 +この設定では、APIサーバーはクラスター内の各ノード(ポート22でlistenしているsshサーバーに接続)へのSSHトンネルを開始し、トンネルを介してkubelet、ノード、Pod、またはサービス宛てのすべてのトラフィックを渡します。 このトンネルにより、ノードが実行されているネットワークの外部にトラフィックが公開されないようにします。 SSHトンネルは現在非推奨なので、自分がしていることが分からない限り、使用しないでください。この通信チャネルに代わるものが設計されています。 diff --git a/content/ja/docs/concepts/architecture/nodes.md b/content/ja/docs/concepts/architecture/nodes.md index d5631319a7..1c3d47c019 100644 --- a/content/ja/docs/concepts/architecture/nodes.md +++ b/content/ja/docs/concepts/architecture/nodes.md @@ -43,7 +43,6 @@ kubectl describe node <ノード名> | ノードのCondition | 概要 | |----------------|-------------| -| `OutOfDisk` | 新しいPodを追加するために必要なディスク容量が足りない場合に`True`になります。それ以外のときは`False`です。 | | `Ready` | ノードの状態がHealthyでPodを配置可能な場合に`True`になります。ノードの状態に問題があり、Podが配置できない場合に`False`になります。ノードコントローラーが、`node-monitor-grace-period`で設定された時間内(デフォルトでは40秒)に該当ノードと疎通できない場合、`Unknown`になります。 | | `MemoryPressure` | ノードのメモリが圧迫されているときに`True`になります。圧迫とは、メモリの空き容量が少ないことを指します。それ以外のときは`False`です。 | | `PIDPressure` | プロセスが圧迫されているときに`True`になります。圧迫とは、プロセス数が多すぎることを指します。それ以外のときは`False`です。 | @@ -69,18 +68,9 @@ Ready conditionが`pod-eviction-timeout`に設定された時間を超えても` バージョン1.5よりも前のKubernetesでは、ノードコントローラーはAPIサーバーから到達不能なそれらのPodを[強制削除](/ja/docs/concepts/workloads/pods/pod/#podの強制削除)していました。しかしながら、1.5以降では、ノードコントローラーはクラスター内でPodが停止するのを確認するまでは強制的に削除しないようになりました。到達不能なノード上で動いているPodは`Terminating`または`Unknown`のステータスになります。Kubernetesが基盤となるインフラストラクチャーを推定できない場合、クラスター管理者は手動でNodeオブジェクトを削除する必要があります。KubernetesからNodeオブジェクトを削除すると、そのノードで実行されているすべてのPodオブジェクトがAPIサーバーから削除され、それらの名前が解放されます。 -バージョン1.12において、`TaintNodesByCondition`機能がBetaに昇格し、それによってノードのライフサイクルコントローラーがconditionを表した[taint](/docs/concepts/configuration/taint-and-toleration/)を自動的に生成するようになりました。 -同様に、スケジューラーがPodを配置するノードを検討する際、ノードのtaintとPodのtolerationsを見るかわりにconditionを無視するようになりました。 +ノードのライフサイクルコントローラーがconditionを表した[taint](/docs/concepts/configuration/taint-and-toleration/)を自動的に生成します。 -ユーザーは、古いスケジューリングモデルか、新しくてより柔軟なスケジューリングモデルのどちらかを選択できるようになりました。 -上記のtolerationがないPodは古いスケジュールモデルに従ってスケジュールされます。しかし、特定のノードのtaintを許容するPodについては、条件に合ったノードにスケジュールすることができます。 - -{{< caution >}} - -この機能を有効にすると、conditionが観測されてからtaintが作成されるまでの間にわずかな遅延が発生します。 -この遅延は通常1秒未満ですが、正常にスケジュールされているが、kubeletによって配置を拒否されたPodの数が増える可能性があります。 - -{{< /caution >}} +スケジューラーがPodをノードに割り当てる際、ノードのtaintを考慮します。Podが許容するtaintは例外です。 ### CapacityとAllocatable {#capacity} @@ -91,7 +81,7 @@ allocatableブロックは、通常のPodによって消費されるノード上 CapacityとAllocatableについて深く知りたい場合は、ノード上でどのように[コンピュートリソースが予約されるか](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)を読みながら学ぶことができます。 -### Info +### Info {#info} カーネルのバージョン、Kubernetesのバージョン（kubeletおよびkube-proxyのバージョン）、（使用されている場合）Dockerのバージョン、OS名など、ノードに関する一般的な情報です。 この情報はノードからkubeletを通じて取得されます。 @@ -114,6 +104,7 @@ CapacityとAllocatableについて深く知りたい場合は、ノード上で ``` Kubernetesは内部的にNodeオブジェクトを作成し、 `metadata.name`フィールドに基づくヘルスチェックによってノードを検証します。ノードが有効な場合、つまり必要なサービスがすべて実行されている場合は、Podを実行する資格があります。それ以外の場合、該当ノードが有効になるまではいかなるクラスターの活動に対しても無視されます。 +Nodeオブジェクトの名前は有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。 {{< note >}} Kubernetesは無効なノードのためにオブジェクトを保存し、それをチェックし続けます。 @@ -136,9 +127,19 @@ Kubernetesは無効なノードのためにオブジェクトを保存し、そ ノードが到達不能(例えば、ノードがダウンしているなどので理由で、ノードコントローラーがハートビートの受信を停止した場合)になると、ノードコントローラーは、NodeStatusのNodeReady conditionをConditionUnknownに変更する役割があります。その後も該当ノードが到達不能のままであった場合、Graceful Terminationを使って全てのPodを退役させます。デフォルトのタイムアウトは、ConditionUnknownの報告を開始するまで40秒、その後Podの追い出しを開始するまで5分に設定されています。 ノードコントローラーは、`--node-monitor-period`に設定された秒数ごとに各ノードの状態をチェックします。 -バージョン1.13よりも前のKubernetesにおいて、NodeStatusはノードからのハートビートでした。Kubernetes 1.13から、NodeLeaseがアルファ機能として導入されました（Feature Gate `NodeLease`, [KEP-0009](https://github.com/kubernetes/community/blob/master/keps/sig-node/0009-node-heartbeat.md)）。 +#### ハートビート +ハートビートは、Kubernetesノードから送信され、ノードが利用可能か判断するのに役立ちます。 +２つのハートビートがあります：`NodeStatus`の更新と[Lease object](/docs/reference/generated/kubernetes-api/{{< latest-version >}}#lease-v1-coordination-k8s-io)です。 +各ノードは`kube-node-lease`という{{< glossary_tooltip term_id="namespace" text="namespace">}}に関連したLeaseオブジェクトを持ちます。 +Leaseは軽量なリソースで、クラスターのスケールに応じてノードのハートビートにおけるパフォーマンスを改善します。 + +kubeletが`NodeStatus`とLeaseオブジェクトの作成および更新を担当します。 + +- kubeletは、ステータスに変化があったり、設定した間隔の間に更新がない時に`NodeStatus`を更新します。`NodeStatus`更新のデフォルト間隔は５分です。（到達不能の場合のデフォルトタイムアウトである40秒よりもはるかに長いです） +- kubeletは10秒間隔(デフォルトの更新間隔)でLeaseオブジェクトの生成と更新を実施します。Leaseの更新は`NodeStatus`の更新とは独立されて行われます。Leaseの更新が失敗した場合、kubeletは200ミリ秒から始まり7秒を上限とした指数バックオフでリトライします。 + +#### 信頼性 -NodeLeaseが有効になっている場合、各ノードは `kube-node-lease`というNamespaceに関連付けられた`Lease`オブジェクトを持ち、ノードによって定期的に更新されます。NodeStatusとNodeLeaseの両方がノードからのハートビートとして扱われます。NodeLeaseは頻繁に更新されますが、NodeStatusはノードからマスターへの変更があるか、または十分な時間が経過した場合にのみ報告されます（デフォルトは1分で、到達不能の場合のデフォルトタイムアウトである40秒よりも長いです）。NodeLeaseはNodeStatusよりもはるかに軽量であるため、スケーラビリティとパフォーマンスの両方の観点においてノードのハートビートのコストを下げます。 Kubernetes 1.4では、マスターに問題が発生した場合の対処方法を改善するように、ノードコントローラーのロジックをアップデートしています（マスターのネットワークに問題があるため） バージョン1.4以降、ノードコントローラーは、Podの退役について決定する際に、クラスター内のすべてのノードの状態を調べます。 @@ -201,6 +202,11 @@ DaemonSetコントローラーによって作成されたPodはKubernetesスケ これは、再起動の準備中にアプリケーションからアプリケーションが削除されている場合でも、デーモンがマシンに属していることを前提としているためです。 {{< /note >}} +{{< caution >}} +`kubectl cordon`はノードに'unschedulable'としてマークします。それはロードバランサーのターゲットリストからノードを削除するという +サービスコントローラーの副次的な効果をもたらします。これにより、ロードバランサトラフィックの流入をcordonされたノードから効率的に除去する事ができます。 +{{< /caution >}} + ### ノードのキャパシティ ノードのキャパシティ（CPUの数とメモリの量）はNodeオブジェクトの一部です。 @@ -213,6 +219,11 @@ Kubernetesスケジューラーは、ノード上のすべてのPodに十分な Pod以外のプロセス用にリソースを明示的に予約したい場合は、このチュートリアルに従って[Systemデーモン用にリソースを予約](/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved)してください。 +## ノードのトポロジー + +{{< feature-state state="alpha" >}} +`TopologyManager`の[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にすると、 +kubeletはリソースの割当を決定する際にトポロジーのヒントを利用できます。 ## APIオブジェクト @@ -220,3 +231,7 @@ NodeはKubernetesのREST APIにおけるトップレベルのリソースです [Node APIオブジェクト](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core). +## {{% heading "whatsnext" %}} + +* [ノードコンポーネント](/ja/docs/concepts/overview/components/#node-components)について読む。 +* ノードレベルのトポロジーについて読む: [ノードのトポロジー管理ポリシーを制御する](/docs/tasks/administer-cluster/topology-manager/) diff --git a/content/ja/docs/concepts/cluster-administration/cluster-administration-overview.md b/content/ja/docs/concepts/cluster-administration/cluster-administration-overview.md index 49e00df3a0..5d85797649 100644 --- a/content/ja/docs/concepts/cluster-administration/cluster-administration-overview.md +++ b/content/ja/docs/concepts/cluster-administration/cluster-administration-overview.md @@ -16,13 +16,13 @@ Kubernetesクラスターの計画、セットアップ、設定の例を知る ガイドを選択する前に、いくつかの考慮事項を挙げます。 - - ユーザーのコンピューター上でKubernetesを試したいでしょうか、それとも高可用性のあるマルチノードクラスターを構築したいでしょうか? あなたのニーズにあったディストリビューションを選択してください。 + - ユーザーのコンピューター上でKubernetesを試したいでしょうか、それとも高可用性のあるマルチノードクラスターを構築したいでしょうか？あなたのニーズにあったディストリビューションを選択してください。 - **もしあなたが高可用性を求める場合**、 [複数ゾーンにまたがるクラスター](/docs/concepts/cluster-administration/federation/)の設定について学んでください。 - - [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/)のような**ホストされているKubernetesクラスター**を使用するのか、それとも**自分自身でクラスターをホストするのでしょうか**? - - 使用するクラスターは**オンプレミス**なのか、それとも**クラウド (IaaS)**でしょうか? Kubernetesはハイブリッドクラスターを直接サポートしていません。その代わりユーザーは複数のクラスターをセットアップできます。 - - Kubernetesを**"ベアメタル"なハードウェア** 上で稼働させますか? それとも**仮想マシン (VMs)** 上で稼働させますか? + - [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/)のような**ホストされているKubernetesクラスター**を使用するのか、それとも**自分自身でクラスターをホストするのでしょうか**？ + - 使用するクラスターは**オンプレミス**なのか、それとも**クラウド(IaaS)** でしょうか？Kubernetesはハイブリッドクラスターを直接サポートしていません。その代わりユーザーは複数のクラスターをセットアップできます。 + - Kubernetesを **「ベアメタル」なハードウェア**上で稼働させますか？それとも**仮想マシン(VMs)** 上で稼働させますか？ - **もしオンプレミスでKubernetesを構築する場合**、どの[ネットワークモデル](/ja/docs/concepts/cluster-administration/networking/)が最適か検討してください。 - - **ただクラスターを稼働させたいだけ**でしょうか、それとも**Kubernetesプロジェクトのコードの開発**を行いたいでしょうか? もし後者の場合、開発が進行中のディストリビューションを選択してください。いくつかのディストリビューションはバイナリリリースのみ使用していますが、多くの選択肢があります。 + - **ただクラスターを稼働させたいだけ**でしょうか、それとも**Kubernetesプロジェクトのコードの開発**を行いたいでしょうか？もし後者の場合、開発が進行中のディストリビューションを選択してください。いくつかのディストリビューションはバイナリリリースのみ使用していますが、多くの選択肢があります。 - クラスターを稼働させるのに必要な[コンポーネント](/ja/docs/concepts/overview/components/)についてよく理解してください。 注意: 全てのディストリビューションがアクティブにメンテナンスされている訳ではありません。最新バージョンのKubernetesでテストされたディストリビューションを選択してください。 diff --git a/content/ja/docs/concepts/cluster-administration/controller-metrics.md b/content/ja/docs/concepts/cluster-administration/controller-metrics.md deleted file mode 100644 index d77f5bdf44..0000000000 --- a/content/ja/docs/concepts/cluster-administration/controller-metrics.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -title: コントローラーマネージャーの指標 -content_type: concept -weight: 100 ---- - - -コントローラーマネージャーの指標は、コントローラー内部のパフォーマンスについての重要で正確な情報と、クラウドコントローラーの状態についての情報を提供します。 - - - - -## コントローラーマネージャーの指標とは何か - -コントローラーマネージャーの指標は、コントローラー内部のパフォーマンスについての重要で正確な情報と、クラウドコントローラーの状態についての情報を提供します。 -これらの指標にはgo_routineのカウントなどの一般的なGo言語ランタイムの指標と、etcdのリクエストレイテンシまたはCloudprovider（AWS、GCE、OpenStack）APIのレイテンシといったコントローラー固有の指標が含まれていて、クラスターの状態を測定するために利用できます。 - -Kubernetes 1.7からGCE、AWS、Vsphere、OpenStackのストレージ操作の詳細なCloudproviderの指標が利用可能になりました。 -これらの指標は永続的ボリュームの操作状況を監視するために利用できます。 - -たとえば、GCEの場合にはこれらの指標は次のように呼び出されます。 - -``` -cloudprovider_gce_api_request_duration_seconds { request = "instance_list"} -cloudprovider_gce_api_request_duration_seconds { request = "disk_insert"} -cloudprovider_gce_api_request_duration_seconds { request = "disk_delete"} -cloudprovider_gce_api_request_duration_seconds { request = "attach_disk"} -cloudprovider_gce_api_request_duration_seconds { request = "detach_disk"} -cloudprovider_gce_api_request_duration_seconds { request = "list_disk"} -``` - - - -## 設定 - -クラスターではコントローラーマネージャーの指標はコントローラーマネージャーが実行されているホストの`http://localhost:10252/metrics`から取得可能です。 - -この指標は[prometheusフォーマット](https://prometheus.io/docs/instrumenting/exposition_formats/)で出力され人間が読める形式になっています。 - -本番環境ではこれらの指標を定期的に収集し、なんらかの時系列データベースで使用できるようにprometheusやその他の指標のスクレイパーを構成することが推奨されます。 - - diff --git a/content/ja/docs/concepts/cluster-administration/networking.md b/content/ja/docs/concepts/cluster-administration/networking.md index 2ec89adc4d..53b899dc32 100644 --- a/content/ja/docs/concepts/cluster-administration/networking.md +++ b/content/ja/docs/concepts/cluster-administration/networking.md @@ -81,7 +81,7 @@ Details on how the AOS system works can be accessed here: http://www.apstra.com/ [AWS VPC CNI](https://github.com/aws/amazon-vpc-cni-k8s)は、Kubernetesクラスター向けの統合されたAWS Virtual Private Cloud(VPC)ネットワーキングを提供します。このCNIプラグインは、高いスループットと可用性、低遅延、および最小のネットワークジッタを提供します。さらに、ユーザーは、Kubernetesクラスターを構築するための既存のAWS VPCネットワーキングとセキュリティのベストプラクティスを適用できます。これには、ネットワークトラフィックの分離にVPCフローログ、VPCルーティングポリシー、およびセキュリティグループを使用する機能が含まれます。 -このCNIプラグインを使用すると、Kubernetes PodはVPCネットワーク上と同じIPアドレスをPod内に持つことができます。CNIはAWS Elastic Networking Interfaces（ENI）を各Kubernetesノードに割り当て、ノード上のPodに各ENIのセカンダリIP範囲を使用します。このCNIには、Podの起動時間を短縮するためのENIとIPアドレスの事前割り当ての制御が含まれており、最大2,000ノードの大規模クラスターが可能です。 +このCNIプラグインを使用すると、Kubernetes PodはVPCネットワーク上と同じIPアドレスをPod内に持つことができます。CNIはAWS Elastic Networking Interface(ENI)を各Kubernetesノードに割り当て、ノード上のPodに各ENIのセカンダリIP範囲を使用します。このCNIには、Podの起動時間を短縮するためのENIとIPアドレスの事前割り当ての制御が含まれており、最大2,000ノードの大規模クラスターが可能です。 さらに、このCNIは[ネットワークポリシーの適用のためにCalico](https://docs.aws.amazon.com/ja_jp/eks/latest/userguide/calico.html)と一緒に実行できます。AWS VPC CNIプロジェクトは、[GitHubのドキュメント](https://github.com/aws/amazon-vpc-cni-k8s)とともにオープンソースで公開されています。 @@ -89,7 +89,7 @@ Details on how the AOS system works can be accessed here: http://www.apstra.com/ [Azure CNI](https://docs.microsoft.com/en-us/azure/virtual-network/container-networking-overview) is an [open source](https://github.com/Azure/azure-container-networking/blob/master/docs/cni.md) plugin that integrates Kubernetes Pods with an Azure Virtual Network (also known as VNet) providing network performance at par with VMs. Pods can connect to peered VNet and to on-premises over Express Route or site-to-site VPN and are also directly reachable from these networks. Pods can access Azure services, such as storage and SQL, that are protected by Service Endpoints or Private Link. You can use VNet security policies and routing to filter Pod traffic. The plugin assigns VNet IPs to Pods by utilizing a pool of secondary IPs pre-configured on the Network Interface of a Kubernetes node. Azure CNI is available natively in the [Azure Kubernetes Service (AKS)] (https://docs.microsoft.com/en-us/azure/aks/configure-azure-cni). - + ### Big Cloud Fabric from Big Switch Networks @@ -289,4 +289,3 @@ to run, and in both cases, the network provides one IP address per pod - as is s ネットワークモデルの初期設計とその根拠、および将来の計画については、[ネットワーク設計ドキュメント](https://git.k8s.io/community/contributors/design-proposals/network/networking.md)で詳細に説明されています。 - diff --git a/content/ja/docs/concepts/configuration/assign-pod-node.md b/content/ja/docs/concepts/configuration/assign-pod-node.md index 7a6c27a1e5..fc05700e28 100644 --- a/content/ja/docs/concepts/configuration/assign-pod-node.md +++ b/content/ja/docs/concepts/configuration/assign-pod-node.md @@ -7,7 +7,7 @@ weight: 30 -[Pod](/ja/docs/concepts/workloads/pods/pod/)が稼働する[Node](/ja/docs/concepts/architecture/nodes/)を特定のものに指定したり、優先条件を指定して制限することができます。 +{{< glossary_tooltip text="Pod" term_id="pod" >}}が稼働する{{< glossary_tooltip text="Node" term_id="node" >}}を特定のものに指定したり、優先条件を指定して制限することができます。 これを実現するためにはいくつかの方法がありますが、推奨されている方法は[ラベルでの選択](/ja/docs/concepts/overview/working-with-objects/labels/)です。 スケジューラーが最適な配置を選択するため、一般的にはこのような制限は不要です(例えば、複数のPodを別々のNodeへデプロイしたり、Podを配置する際にリソースが不十分なNodeにはデプロイされないことが挙げられます)が、 SSDが搭載されているNodeにPodをデプロイしたり、同じアベイラビリティーゾーン内で通信する異なるサービスのPodを同じNodeにデプロイする等、柔軟な制御が必要なこともあります。 @@ -27,7 +27,7 @@ SSDが搭載されているNodeにPodをデプロイしたり、同じアベイ ### ステップ0: 前提条件 -この例では、KubernetesのPodに関して基本的な知識を有していることと、[Kubernetesクラスターのセットアップ](https://github.com/kubernetes/kubernetes#documentation)がされていることが前提となっています。 +この例では、KubernetesのPodに関して基本的な知識を有していることと、[Kubernetesクラスターのセットアップ](/ja/docs/setup/)がされていることが前提となっています。 ### ステップ1: Nodeへのラベルの付与 @@ -63,17 +63,20 @@ nodeSelectorを以下のように追加します: `kubectl apply -f https://k8s.io/examples/pods/pod-nginx.yaml`により、Podは先ほどラベルを付与したNodeへスケジュールされます。 `kubectl get pods -o wide`で表示される"NODE"の列から、PodがデプロイされているNodeを確認することができます。 -## 補足: ビルトインNodeラベル +## 補足: ビルトインNodeラベル {#built-in-node-labels} 明示的に[付与](#step-one-attach-label-to-the-node)するラベルの他に、事前にNodeへ付与されているものもあります。 以下のようなラベルが該当します。 -* `kubernetes.io/hostname` -* `failure-domain.beta.kubernetes.io/zone` -* `failure-domain.beta.kubernetes.io/region` -* `beta.kubernetes.io/instance-type` -* `kubernetes.io/os` -* `kubernetes.io/arch` +* [`kubernetes.io/hostname`](/docs/reference/kubernetes-api/labels-annotations-taints/#kubernetes-io-hostname) +* [`failure-domain.beta.kubernetes.io/zone`](/docs/reference/kubernetes-api/labels-annotations-taints/#failure-domainbetakubernetesiozone) +* [`failure-domain.beta.kubernetes.io/region`](/docs/reference/kubernetes-api/labels-annotations-taints/#failure-domainbetakubernetesioregion) +* [`topology.kubernetes.io/zone`](/docs/reference/kubernetes-api/labels-annotations-taints/#topologykubernetesiozone) +* [`topology.kubernetes.io/region`](/docs/reference/kubernetes-api/labels-annotations-taints/#topologykubernetesiozone) +* [`beta.kubernetes.io/instance-type`](/docs/reference/kubernetes-api/labels-annotations-taints/#beta-kubernetes-io-instance-type) +* [`node.kubernetes.io/instance-type`](/docs/reference/kubernetes-api/labels-annotations-taints/#nodekubernetesioinstance-type) +* [`kubernetes.io/os`](/docs/reference/kubernetes-api/labels-annotations-taints/#kubernetes-io-os) +* [`kubernetes.io/arch`](/docs/reference/kubernetes-api/labels-annotations-taints/#kubernetes-io-arch) {{< note >}} これらのラベルは、クラウドプロバイダー固有であり、確実なものではありません。 @@ -88,131 +91,127 @@ Nodeにラベルを付与することで、Podは特定のNodeやNodeグルー これは、安全性が損なわれたNodeがkubeletの認証情報をNodeのオブジェクトに設定したり、スケジューラーがそのようなNodeにデプロイすることを防ぎます。 `NodeRestriction`プラグインは、kubeletが`node-restriction.kubernetes.io/`プレフィックスを有するラベルの設定や上書きを防ぎます。 -Nodeの隔離にラベルのプレフィックスを使用するためには、以下の３点を確認してください。 +Nodeの隔離にラベルのプレフィックスを使用するためには、以下のようにします。 -1. NodeRestrictionを使用するため、Kubernetesのバージョンがv1.11以上であること。 -2. [Node authorizer](/docs/reference/access-authn-authz/node/)を使用していることと、[NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)が有効になっていること。 -3. Nodeに`node-restriction.kubernetes.io/` プレフィックスのラベルを付与し、そのラベルがnode selectorに指定されていること。 +1. [Node authorizer](/docs/reference/access-authn-authz/node/)を使用していることと、[NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)が_有効_になっていること。 +2. Nodeに`node-restriction.kubernetes.io/` プレフィックスのラベルを付与し、そのラベルがnode selectorに指定されていること。 例えば、`example.com.node-restriction.kubernetes.io/fips=true` または `example.com.node-restriction.kubernetes.io/pci-dss=true`のようなラベルです。 -## Affinity と Anti-Affinity {#affinity-and-anti-affinity} +## アフィニティとアンチアフィニティ {#affinity-and-anti-affinity} `nodeSelector`はPodの稼働を特定のラベルが付与されたNodeに制限する最も簡単な方法です。 -Affinity/Anti-Affinityでは、より柔軟な指定方法が提供されています。 +アフィニティ/アンチアフィニティでは、より柔軟な指定方法が提供されています。 拡張機能は以下の通りです。 -1. 様々な指定方法がある ("AND条件"に限らない) -2. 必須条件ではなく優先条件を指定でき、条件を満たさない場合でもPodをスケジュールさせることができる -3. Node自体のラベルではなく、Node(または他のトポロジカルドメイン)上で稼働している他のPodのラベルに対して条件を指定することができ、そのPodと同じ、または異なるドメインで稼働させることができる +1. アフィニティ/アンチアフィニティという用語はとても表現豊かです。この用語は論理AND演算で作成された完全一致だけではなく、より多くのマッチングルールを提供します。 +2. 必須条件ではなく優先条件を指定でき、条件を満たさない場合でもPodをスケジュールさせることができます。 +3. Node自体のラベルではなく、Node(または他のトポロジカルドメイン)上で稼働している他のPodのラベルに対して条件を指定することができ、そのPodと同じ、または異なるドメインで稼働させることができます。 -Affinityは"Node Affinity"と"Inter-Pod Affinity/Anti-Affinity"の2種類から成ります。 -Node affinityは`nodeSelector`(前述の2つのメリットがあります)に似ていますが、Inter-Pod Affinity/Anti-Affinityは、上記の3番目の機能に記載している通り、NodeのラベルではなくPodのラベルに対して制限をかけます。 +アフィニティは"Nodeアフィニティ"と"Pod間アフィニティ/アンチアフィニティ"の2種類から成ります。 +Nodeアフィニティは`nodeSelector`(前述の2つのメリットがあります)に似ていますが、Pod間アフィニティ/アンチアフィニティは、上記の3番目の機能に記載している通り、NodeのラベルではなくPodのラベルに対して制限をかけます。 -`nodeSelector`は問題なく使用することができますが、Node affinityは`nodeSelector`で指定できる条件を全て実現できるため、将来的には推奨されなくなります。 +### Nodeアフィニティ -### Node Affinity +Nodeアフィニティは概念的には、NodeのラベルによってPodがどのNodeにスケジュールされるかを制限する`nodeSelector`と同様です。 -Node Affinityはα機能としてKubernetesのv1.2から導入されました。 -Node Affinityは概念的には、NodeのラベルによってPodがどのNodeにスケジュールされるかを制限する`nodeSelector`と同様です。 - -現在は2種類のNode Affinityがあり、`requiredDuringSchedulingIgnoredDuringExecution`と`preferredDuringSchedulingIgnoredDuringExecution`です。 +現在は2種類のNodeアフィニティがあり、`requiredDuringSchedulingIgnoredDuringExecution`と`preferredDuringSchedulingIgnoredDuringExecution`です。 前者はNodeにスケジュールされるPodが条件を満たすことが必須(`nodeSelector`に似ていますが、より柔軟に条件を指定できます)であり、後者は条件を指定できますが保証されるわけではなく、優先的に考慮されます。 "IgnoredDuringExecution"の意味するところは、`nodeSelector`の機能と同様であり、Nodeのラベルが変更され、Podがその条件を満たさなくなった場合でも PodはそのNodeで稼働し続けるということです。 -将来的には、`requiredDuringSchedulingIgnoredDuringExecution`に、PodのNode Affinityに記された必須要件を満たさなくなったNodeからそのPodを退避させることができる機能を備えた`requiredDuringSchedulingRequiredDuringExecution`が提供される予定です。 +将来的には、`requiredDuringSchedulingIgnoredDuringExecution`に、PodのNodeアフィニティに記された必須要件を満たさなくなったNodeからそのPodを退避させることができる機能を備えた`requiredDuringSchedulingRequiredDuringExecution`が提供される予定です。 それぞれの使用例として、 `requiredDuringSchedulingIgnoredDuringExecution` は、"インテルCPUを供えたNode上でPodを稼働させる"、 `preferredDuringSchedulingIgnoredDuringExecution`は、"ゾーンXYZでPodの稼働を試みますが、実現不可能な場合には他の場所で稼働させる" といった方法が挙げられます。 -Node Affinityは、PodSpecの`affinity`フィールドにある`nodeAffinity`フィールドで特定します。 +Nodeアフィニティは、PodSpecの`affinity`フィールドにある`nodeAffinity`フィールドで特定します。 -Node Affinityを使用したPodの例を以下に示します: +Nodeアフィニティを使用したPodの例を以下に示します: {{< codenew file="pods/pod-with-node-affinity.yaml" >}} -このNode Affinityでは、Podはキーが`kubernetes.io/e2e-az-name`、値が`e2e-az1`または`e2e-az2`のラベルが付与されたNodeにしか配置されません。 +このNodeアフィニティでは、Podはキーが`kubernetes.io/e2e-az-name`、値が`e2e-az1`または`e2e-az2`のラベルが付与されたNodeにしか配置されません。 加えて、キーが`another-node-label-key`、値が`another-node-label-value`のラベルが付与されたNodeが優先されます。 この例ではオペレーター`In`が使われています。 -Node Affinityでは、`In`、`NotIn`、`Exists`、`DoesNotExist`、`Gt`、`Lt`のオペレーターが使用できます。 -`NotIn`と`DoesNotExist`はNode Anti-Affinity、またはPodを特定のNodeにスケジュールさせない場合に使われる[Taints](/docs/concepts/configuration/taint-and-toleration/)に使用します。 +Nodeアフィニティでは、`In`、`NotIn`、`Exists`、`DoesNotExist`、`Gt`、`Lt`のオペレーターが使用できます。 +`NotIn`と`DoesNotExist`はNodeアンチアフィニティ、またはPodを特定のNodeにスケジュールさせない場合に使われる[Taints](/docs/concepts/configuration/taint-and-toleration/)に使用します。 `nodeSelector`と`nodeAffinity`の両方を指定した場合、Podは**両方の**条件を満たすNodeにスケジュールされます。 -`nodeAffinity`内で複数の`nodeSelectorTerms`を指定した場合、Podは**いずれかの**`nodeSelectorTerms`を満たしたNodeへスケジュールされます。 +`nodeAffinity`内で複数の`nodeSelectorTerms`を指定した場合、Podは**全ての**`nodeSelectorTerms`を満たしたNodeへスケジュールされます。 -`nodeSelectorTerms`内で複数の`matchExpressions`を指定した場合にはPodは**全ての**`matchExpressions`を満たしたNodeへスケジュールされます。 +`nodeSelectorTerms`内で複数の`matchExpressions`を指定した場合にはPodは**いずれかの**`matchExpressions`を満たしたNodeへスケジュールされます。 PodがスケジュールされたNodeのラベルを削除したり変更しても、Podは削除されません。 -言い換えると、AffinityはPodをスケジュールする際にのみ考慮されます。 +言い換えると、アフィニティはPodをスケジュールする際にのみ考慮されます。 `preferredDuringSchedulingIgnoredDuringExecution`内の`weight`フィールドは、1から100の範囲で指定します。 -全ての必要条件(リソースやRequiredDuringScheduling Affinity等)を満たしたNodeに対して、スケジューラーはそのNodeがMatchExpressionsを満たした場合に、このフィルードの"weight"を加算して合計を計算します。 +全ての必要条件(リソースやRequiredDuringSchedulingアフィニティ等)を満たしたNodeに対して、スケジューラーはそのNodeがMatchExpressionsを満たした場合に、このフィルードの"weight"を加算して合計を計算します。 このスコアがNodeの他の優先機能のスコアと組み合わせれ、最も高いスコアを有したNodeが優先されます。 -### Inter-Pod Affinity/Anti-Affinity +### Pod間アフィニティとアンチアフィニティ -Inter-Pod AffinityとAnti-Affinityは、Nodeのラベルではなく、すでにNodeで稼働しているPodのラベルに従ってPodがスケジュールされるNodeを制限します。 -このポリシーは、"XにてルールYを満たすPodがすでに稼働している場合、このPodもXで稼働させる(Anti-Affinityの場合は稼働させない)"という形式です。 +Pod間アフィニティとアンチアフィニティは、Nodeのラベルではなく、すでにNodeで稼働しているPodのラベルに従ってPodがスケジュールされるNodeを制限します。 +このポリシーは、"XにてルールYを満たすPodがすでに稼働している場合、このPodもXで稼働させる(アンチアフィニティの場合は稼働させない)"という形式です。 Yはnamespaceのリストで指定したLabelSelectorで表されます。 Nodeと異なり、Podはnamespaceで区切られているため(それゆえPodのラベルも暗黙的にnamespaceで区切られます)、Podのラベルを指定するlabel selectorは、どのnamespaceにselectorを適用するかを指定する必要があります。 概念的に、XはNodeや、ラック、クラウドプロバイダゾーン、クラウドプロバイダのリージョン等を表すトポロジードメインです。 -これらを表すためにシステムが使用するNode Labelのキーである`topologyKey`を使うことで、トポロジードメインを指定することができます。 +これらを表すためにシステムが使用するNodeラベルのキーである`topologyKey`を使うことで、トポロジードメインを指定することができます。 先述のセクション[補足: ビルトインNodeラベル](#interlude-built-in-node-labels)にてラベルの例が紹介されています。 {{< note >}} -Inter-Pod AffinityとAnti-Affinityは、大規模なクラスター上で使用する際にスケジューリングを非常に遅くする恐れのある多くの処理を要します。 +Pod間アフィニティとアンチアフィニティは、大規模なクラスター上で使用する際にスケジューリングを非常に遅くする恐れのある多くの処理を要します。 そのため、数百台以上のNodeから成るクラスターでは使用することを推奨されません。 {{< /note >}} {{< note >}} -Pod Anti-Affinityは、Nodeに必ずラベルが付与されている必要があります。 -例えば、クラスターの全てのNodeが、`topologyKey`で指定されたものに合致する適切なラベルが必要になります。 +Podのアンチアフィニティは、Nodeに必ずラベルが付与されている必要があります。 +言い換えると、クラスターの全てのNodeが、`topologyKey`で指定されたものに合致する適切なラベルが必要になります。 それらが付与されていないNodeが存在する場合、意図しない挙動を示すことがあります。 {{< /note >}} -Node Affinityと同様に、Pod AffinityとPod Anti-Affinityにも必須条件と優先条件を示す`requiredDuringSchedulingIgnoredDuringExecution`と`preferredDuringSchedulingIgnoredDuringExecution`があります。 -前述のNode Affinityのセクションを参照してください。 -`requiredDuringSchedulingIgnoredDuringExecution`を指定するAffinityの使用例は、"Service AのPodとService BのPodが密に通信する際、それらを同じゾーンで稼働させる場合"です。 -また、`preferredDuringSchedulingIgnoredDuringExecution`を指定するAnti-Affinityの使用例は、"ゾーンをまたいでPodのサービスを稼働させる場合"(Podの数はゾーンの数よりも多いため、必須条件を指定すると合理的ではありません)です。 +Nodeアフィニティと同様に、PodアフィニティとPodアンチアフィニティにも必須条件と優先条件を示す`requiredDuringSchedulingIgnoredDuringExecution`と`preferredDuringSchedulingIgnoredDuringExecution`があります。 +前述のNodeアフィニティのセクションを参照してください。 +`requiredDuringSchedulingIgnoredDuringExecution`を指定するアフィニティの使用例は、"Service AのPodとService BのPodが密に通信する際、それらを同じゾーンで稼働させる場合"です。 +また、`preferredDuringSchedulingIgnoredDuringExecution`を指定するアンチアフィニティの使用例は、"ゾーンをまたいでPodのサービスを稼働させる場合"(Podの数はゾーンの数よりも多いため、必須条件を指定すると合理的ではありません)です。 -Inter-Pod Affinityは、PodSpecの`affinity`フィールド内に`podAffinity`で指定し、Inter-Pod Anti-Affinityは、`podAntiAffinity`で指定します。 +Pod間アフィニティは、PodSpecの`affinity`フィールド内に`podAffinity`で指定し、Pod間アンチアフィニティは、`podAntiAffinity`で指定します。 -#### Pod Affinityを使用したPodの例 +#### Podアフィニティを使用したPodの例 {{< codenew file="pods/pod-with-pod-affinity.yaml" >}} -このPodのAffifnityは、Pod AffinityとPod Anti-Affinityを1つずつ定義しています。 +このPodのアフィニティは、PodアフィニティとPodアンチアフィニティを1つずつ定義しています。 この例では、`podAffinity`に`requiredDuringSchedulingIgnoredDuringExecution`、`podAntiAffinity`に`preferredDuringSchedulingIgnoredDuringExecution`が設定されています。 -Pod Affinityは、「キーが"security"、値が"S1"のラベルが付与されたPodが少なくとも1つは稼働しているNodeが同じゾーンにあれば、PodはそのNodeにスケジュールされる」という条件を指定しています(より正確には、キーが"security"、値が"S1"のラベルが付与されたPodが稼働しており、キーが`failure-domain.beta.kubernetes.io/zone`、値がVであるNodeが少なくとも1つはある状態で、 +Podアフィニティは、「キーが"security"、値が"S1"のラベルが付与されたPodが少なくとも1つは稼働しているNodeが同じゾーンにあれば、PodはそのNodeにスケジュールされる」という条件を指定しています(より正確には、キーが"security"、値が"S1"のラベルが付与されたPodが稼働しており、キーが`failure-domain.beta.kubernetes.io/zone`、値がVであるNodeが少なくとも1つはある状態で、 Node Nがキー`failure-domain.beta.kubernetes.io/zone`、値Vのラベルを持つ場合に、PodはNode Nで稼働させることができます)。 -Pod Anti-Affinityは、「すでにあるNode上で、キーが"security"、値が"S2"であるPodが稼働している場合に、Podを可能な限りそのNode上で稼働させない」という条件を指定しています +Podアンチアフィニティは、「すでにあるNode上で、キーが"security"、値が"S2"であるPodが稼働している場合に、Podを可能な限りそのNode上で稼働させない」という条件を指定しています (`topologyKey`が`failure-domain.beta.kubernetes.io/zone`であった場合、キーが"security"、値が"S2"であるであるPodが稼働しているゾーンと同じゾーン内のNodeにはスケジュールされなくなります)。 -Pod AffinityとPod Anti-Affinityや、`requiredDuringSchedulingIgnoredDuringExecution`と`preferredDuringSchedulingIgnoredDuringExecution`に関する他の使用例は[デザインドック](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)を参照してください。 +PodアフィニティとPodアンチアフィニティや、`requiredDuringSchedulingIgnoredDuringExecution`と`preferredDuringSchedulingIgnoredDuringExecution`に関する他の使用例は[デザインドック](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)を参照してください。 -Pod AffinityとPod Anti-Affinityで使用できるオペレーターは、`In`、`NotIn`、 `Exists`、 `DoesNotExist`です。 +PodアフィニティとPodアンチアフィニティで使用できるオペレーターは、`In`、`NotIn`、 `Exists`、 `DoesNotExist`です。 原則として、`topologyKey`には任意のラベルとキーが使用できます。 しかし、パフォーマンスやセキュリティの観点から、以下の制約があります: -1. Affinityと、`requiredDuringSchedulingIgnoredDuringExecution`を指定したPod Anti-Affinityでは、`topologyKey`を指定しないことは許可されていません。 -2. `requiredDuringSchedulingIgnoredDuringExecution`を指定したPod Anti-Affinityでは、`kubernetes.io/hostname`の`topologyKey`を制限するため、アドミッションコントローラー`LimitPodHardAntiAffinityTopology`が導入されました。 +1. アフィニティと、`requiredDuringSchedulingIgnoredDuringExecution`を指定したPodアンチアフィニティは、`topologyKey`を指定しないことは許可されていません。 +2. `requiredDuringSchedulingIgnoredDuringExecution`を指定したPodアンチアフィニティでは、`kubernetes.io/hostname`の`topologyKey`を制限するため、アドミッションコントローラー`LimitPodHardAntiAffinityTopology`が導入されました。 トポロジーをカスタマイズする場合には、アドミッションコントローラーを修正または無効化する必要があります。 -3. `preferredDuringSchedulingIgnoredDuringExecution`を指定したPod Anti-Affinityでは、`topologyKey`を指定しなかった場合、"全てのトポロジー"と解釈されます("全てのトポロジー"とは、ここでは`kubernetes.io/hostname`、`failure-domain.beta.kubernetes.io/zone`、`failure-domain.beta.kubernetes.io/region`を合わせたものを意味します)。 +3. `preferredDuringSchedulingIgnoredDuringExecution`を指定したPodアンチアフィニティでは、`topologyKey`を省略することはできません。 4. 上記の場合を除き、`topologyKey` は任意のラベルとキーを指定することができあます。 `labelSelector`と`topologyKey`に加え、`labelSelector`が合致すべき`namespaces`のリストを特定することも可能です(これは`labelSelector`と`topologyKey`を定義することと同等です)。 -省略した場合や空の場合は、AffinityとAnti-Affinityが定義されたPodのnamespaceがデフォルトで設定されます。 +省略した場合や空の場合は、アフィニティとアンチアフィニティが定義されたPodのnamespaceがデフォルトで設定されます。 -`requiredDuringSchedulingIgnoredDuringExecution`が指定されたAffinityとAnti-Affinityでは、`matchExpressions`に記載された全ての条件が満たされるNodeにPodがスケジュールされます。 +`requiredDuringSchedulingIgnoredDuringExecution`が指定されたアフィニティとアンチアフィニティでは、`matchExpressions`に記載された全ての条件が満たされるNodeにPodがスケジュールされます。 #### 実際的なユースケース -Inter-Pod AffinityとAnti-Affinityは、ReplicaSet、StatefulSet、Deploymentなどのより高レベルなコレクションと併せて使用すると更に有用です。 +Pod間アフィニティとアンチアフィニティは、ReplicaSet、StatefulSet、Deploymentなどのより高レベルなコレクションと併せて使用するとさらに有用です。 Workloadが、Node等の定義された同じトポロジーに共存させるよう、簡単に設定できます。 @@ -325,7 +324,7 @@ web-server-1287567482-s330j 1/1 Running 0 7m 10.192.3 ##### 同じNodeに共存させない場合 上記の例では `PodAntiAffinity`を`topologyKey: "kubernetes.io/hostname"`と合わせて指定することで、redisクラスター内の2つのインスタンスが同じホストにデプロイされない場合を扱いました。 -同様の方法で、Anti-Affinityを用いて高可用性を実現したStatefulSetの使用例は[ZooKeeper tutorial](/docs/tutorials/stateful-application/zookeeper/#tolerating-node-failure)を参照してください。 +同様の方法で、アンチアフィニティを用いて高可用性を実現したStatefulSetの使用例は[ZooKeeper tutorial](/docs/tutorials/stateful-application/zookeeper/#tolerating-node-failure)を参照してください。 ## nodeName @@ -338,7 +337,7 @@ web-server-1287567482-s330j 1/1 Running 0 7m 10.192.3 `nodeName`を使用することによる制約は以下の通りです: - その名前のNodeが存在しない場合、Podは起動されす、自動的に削除される場合があります。 -- その名前のNodeにPodを稼働させるためのリソースがない場合、Podの起動は失敗し、理由はOutOfmemoryやOutOfcpuになります。 +- その名前のNodeにPodを稼働させるためのリソースがない場合、Podの起動は失敗し、理由は例えばOutOfmemoryやOutOfcpuになります。 - クラウド上のNodeの名前は予期できず、変更される可能性があります。 `nodeName`を指定したPodの設定ファイルの例を示します: @@ -364,8 +363,9 @@ spec: [Taints](/docs/concepts/configuration/taint-and-toleration/)を使うことで、NodeはPodを追い出すことができます。 -[Node Affinity](https://git.k8s.io/community/contributors/design-proposals/scheduling/nodeaffinity.md)と -[Inter-Pod Affinity/Anti-Affinity](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md) -には、Taintsの要点に関して様々な背景が紹介されています。 - +[Nodeアフィニティ](https://git.k8s.io/community/contributors/design-proposals/scheduling/nodeaffinity.md)と +[Pod間アフィニティ/アンチアフィニティ](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md) +のデザインドキュメントには、これらの機能の追加のバックグラウンドの情報が記載されています。 +一度PodがNodeに割り当たると、kubeletはPodを起動してノード内のリソースを確保します。 +[トポロジーマネージャー](/docs/tasks/administer-cluster/topology-manager/)はNodeレベルのリソース割り当てを決定する際に関与します。 diff --git a/content/ja/docs/concepts/configuration/overview.md b/content/ja/docs/concepts/configuration/overview.md index 791582e11b..2a5dfc4a51 100644 --- a/content/ja/docs/concepts/configuration/overview.md +++ b/content/ja/docs/concepts/configuration/overview.md @@ -27,11 +27,11 @@ weight: 10 - よりよいイントロスペクションのために、オブジェクトの説明をアノテーションに入れましょう。 -## "真っ裸"のPod に対する ReplicaSet、Deployment、およびJob +## "真っ裸"のPod に対する ReplicaSet、Deployment、およびJob {#naked-pods-vs-replicasets-deployments-and-jobs} - 可能な限り、"真っ裸"の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/jobs-run-to-completion/)のほうが適切な場合もあるかもしれません。 ## Service @@ -81,7 +81,7 @@ weight: 10 - `imagePullPolicy: Never`: 常にローカルでイメージを探そうとします。ない場合にもイメージはpullしません。 {{< note >}} -コンテナが常に同じバージョンのイメージを使用するようにするためには、そのコンテナイメージの[ダイジェスト](https://docs.docker.com/engine/reference/commandline/pull/#pull-an-image-by-digest-immutable-identifier)を指定することができます(例:`sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2`)。このダイジェストはイメージの特定のバージョンを一意に識別するため、ダイジェスト値を変更しない限り、Kubernetesによって更新されることはありません。 +コンテナが常に同じバージョンのイメージを使用するようにするためには、そのコンテナイメージの[ダイジェスト](https://docs.docker.com/engine/reference/commandline/pull/#pull-an-image-by-digest-immutable-identifier)を指定することができます。`:`を`@`で置き換えます(例:`image@sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2`)。このダイジェストはイメージの特定のバージョンを一意に識別するため、ダイジェスト値を変更しない限り、Kubernetesによって更新されることはありません。 {{< /note >}} {{< note >}} @@ -89,7 +89,7 @@ weight: 10 {{< /note >}} {{< note >}} -ベースイメージのプロバイダーのキャッシュセマンティクスにより、`imagePullPolicy：Always`もより効率的になります。たとえば、Dockerでは、イメージが既に存在する場合すべてのイメージレイヤーがキャッシュされ、イメージのダウンロードが不要であるため、pullが高速になります。 +ベースイメージのプロバイダーのキャッシュセマンティクスにより、`imagePullPolicy：Always`もより効率的になります。たとえば、Dockerでは、イメージがすでに存在する場合すべてのイメージレイヤーがキャッシュされ、イメージのダウンロードが不要であるため、pullが高速になります。 {{< /note >}} ## kubectlの使い方 diff --git a/content/ja/docs/concepts/containers/container-lifecycle-hooks.md b/content/ja/docs/concepts/containers/container-lifecycle-hooks.md index 627c95b4c0..13ad6f2578 100644 --- a/content/ja/docs/concepts/containers/container-lifecycle-hooks.md +++ b/content/ja/docs/concepts/containers/container-lifecycle-hooks.md @@ -30,7 +30,7 @@ Angularなどのコンポーネントライフサイクルフックを持つ多 `PreStop` -このフックは、liveness probeの失敗、プリエンプション、リソース競合などのAPI要求または管理イベントが原因でコンテナが終了する直前に呼び出されます。コンテナが既に終了状態または完了状態にある場合、preStopフックの呼び出しは失敗します。 +このフックは、liveness probeの失敗、プリエンプション、リソース競合などのAPI要求または管理イベントが原因でコンテナが終了する直前に呼び出されます。コンテナがすでに終了状態または完了状態にある場合、preStopフックの呼び出しは失敗します。 これはブロッキング、つまり同期的であるため、コンテナを削除するための呼び出しを送信する前に完了する必要があります。 ハンドラーにパラメーターは渡されません。 @@ -80,7 +80,7 @@ Angularなどのコンポーネントライフサイクルフックを持つ多 ``` Events: - FirstSeen LastSeen Count From SubobjectPath Type Reason Message + FirstSeen LastSeen Count From SubObjectPath Type Reason Message --------- -------- ----- ---- ------------- -------- ------ ------- 1m 1m 1 {default-scheduler } Normal Scheduled Successfully assigned test-1730497541-cq1d2 to gke-test-cluster-default-pool-a07e5d30-siqd 1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Pulling pulling image "test:1.0" diff --git a/content/ja/docs/concepts/containers/runtime-class.md b/content/ja/docs/concepts/containers/runtime-class.md index 6ea1f1e4e1..bd6cc59c49 100644 --- a/content/ja/docs/concepts/containers/runtime-class.md +++ b/content/ja/docs/concepts/containers/runtime-class.md @@ -26,11 +26,10 @@ RuntimeClassはコンテナランタイムの設定を選択するための機 ### セットアップ -RuntimeClass機能のFeature Gateが有効になっていることを確認してください(デフォルトで有効です)。Feature Gateを有効にする方法については、[Feature -Gates](/docs/reference/command-line-tools-reference/feature-gates/)を参照してください。 -その`RuntimeClass`のFeature GateはApiServerとkubeletのどちらも有効になっていなければなりません。 +RuntimeClass機能のフィーチャーゲートが有効になっていることを確認してください(デフォルトで有効です)。フィーチャーゲートを有効にする方法については、[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を参照してください。 +その`RuntimeClass`のフィーチャーゲートはApiServerとkubeletのどちらも有効になっていなければなりません。 -1. ノード上でCRI実装を設定する。（ランタイムに依存） +1. ノード上でCRI実装を設定する。(ランタイムに依存) 2. 対応するRuntimeClassリソースを作成する。 #### 1. ノード上でCRI実装を設定する。 @@ -39,8 +38,8 @@ RuntimeClassを通じて利用可能な設定はContainer Runtime Interface (CRI ユーザーの環境のCRI実装の設定方法は、対応するドキュメント([下記](#cri-configuration))を参照ください。 {{< note >}} -RuntimeClassは現時点において、クラスター全体で同じ種類のNode設定であることを仮定しています。(これは全てのNodeがコンテナランタイムに関して同じ方法で構成されていることを意味します)。 -設定が異なるNodeに関しては、スケジューリング機能を通じてRuntimeClassとは独立して管理されなくてはなりません。([PodをNodeに割り当てる方法](/ja/docs/concepts/configuration/assign-pod-node/)を参照して下さい)。 +RuntimeClassは、クラスター全体で同じ種類のノード設定であることを仮定しています。(これは全てのノードがコンテナランタイムに関して同じ方法で構成されていることを意味します)。 +設定が異なるノードをサポートするには、[スケジューリング](#scheduling)を参照してください。 {{< /note >}} RuntimeClassの設定は、RuntimeClassによって参照される`ハンドラー`名を持ちます。そのハンドラーは正式なDNS-1123に準拠する形式のラベルでなくてはなりません(英数字 + `-`の文字で構成されます)。 @@ -60,6 +59,9 @@ metadata: handler: myconfiguration # 対応するCRI設定 ``` +RuntimeClassオブジェクトの名前は[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)に従う必要があります。 + + {{< note >}} RuntimeClassの書き込み操作(create/update/patch/delete)はクラスター管理者のみに制限されることを推奨します。 これはたいていデフォルトで有効となっています。さらなる詳細に関しては[Authorization @@ -94,7 +96,7 @@ CRIランタイムのセットアップに関するさらなる詳細は、[CRI Kubernetesのビルトインのdockershim CRIは、ランタイムハンドラーをサポートしていません。 -#### [containerd](https://containerd.io/) +#### {{< glossary_tooltip term_id="containerd" >}} ランタイムハンドラーは、`/etc/containerd/config.toml`にあるcontainerdの設定ファイルにより設定されます。 正しいハンドラーは、その`runtime`セクションで設定されます。 @@ -106,20 +108,49 @@ Kubernetesのビルトインのdockershim CRIは、ランタイムハンドラ containerdの設定に関する詳細なドキュメントは下記を参照してください。 https://github.com/containerd/cri/blob/master/docs/config.md -#### [cri-o](https://cri-o.io/) +#### {{< glossary_tooltip term_id="cri-o" >}} -ランタイムハンドラーは、`/etc/crio/crio.conf`にあるcri-oの設定ファイルにより設定されます。 +ランタイムハンドラーは、`/etc/crio/crio.conf`にあるCRI-Oの設定ファイルにより設定されます。 正しいハンドラーは[crio.runtime -table](https://github.com/kubernetes-sigs/cri-o/blob/master/docs/crio.conf.5.md#crioruntime-table)で設定されます。 +table](https://github.com/cri-o/cri-o/blob/master/docs/crio.conf.5.md#crioruntime-table)で設定されます。 ``` [crio.runtime.runtimes.${HANDLER_NAME}] runtime_path = "${PATH_TO_BINARY}" ``` -cri-oの設定に関する詳細なドキュメントは下記を参照してください。 -https://github.com/kubernetes-sigs/cri-o/blob/master/cmd/crio/config.go +CRI-Oの[設定に関するドキュメント][100]の詳細は下記を参照してください。 +[100]: https://raw.githubusercontent.com/cri-o/cri-o/9f11d1d/docs/crio.conf.5.md + +### スケジューリング {#scheduling} + +{{< feature-state for_k8s_version="v1.16" state="beta" >}} + +Kubernetes 1.16では、RuntimeClassは`scheduling`フィールドを使ったクラスター内での異なる設定をサポートしています。 +このフィールドによって、設定されたRuntimeClassをサポートするノードに対してPodがスケジュールされることを保証できます。 +スケジューリングをサポートするためにはRuntimeClass [アドミッションコントローラー][]を有効にしなければなりません。(1.16ではデフォルトです) + +特定のRuntimeClassをサポートしているノードへPodが配置されることを保証するために、各ノードは`runtimeclass.scheduling.nodeSelector`フィールドによって選択される共通のラベルを持つべきです。 +RuntimeClassのnodeSelectorはアドミッション機能によりPodのnodeSelectorに統合され、効率よくノードを選択します。 +もし設定が衝突した場合は、Pod作成は拒否されるでしょう。 + +もしサポートされているノードが他の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/ + +### Podオーバーヘッド + +{{< feature-state for_k8s_version="v1.16" state="alpha" >}} + +Kubernetes 1.16ではRuntimeClassは[`PodOverhead`](/docs/concepts/configuration/pod-overhead/)機能の一部である、Podが稼働する時に関連するオーバーヘッドを指定することをサポートしています。 +`PodOverhead`を使うためには、PodOverhead[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にしなければなりません。(デフォルトではoffです) + +PodのオーバーヘッドはRuntimeClass内の`Overhead`フィールドによって定義されます。 +このフィールドを使用することで、RuntimeClassを使用して稼働するPodのオーバーヘッドを指定することができ、Kubernetes内部で使用されるオーバーヘッドを確保することができます。 ### RutimeClassをα版からβ版にアップグレードする @@ -140,3 +171,9 @@ RuntimeClassのβ版の機能は、下記の変更点を含みます。 - `runtimeHandler`の指定がないか、もしくは空文字の場合や、ハンドラー名に`.`文字列が使われている場合はα版のRuntimeClassにおいてもはや有効ではありません。正しい形式のハンドラー設定に変更しなくてはなりません(先ほど記載した内容を確認ください)。 +### 参考文献 + +- [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) +- [Podオーバーヘッド](/docs/concepts/configuration/pod-overhead/)のコンセプトを読む +- [PodOverhead機能デザイン](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md) 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 41f96a20ce..c05b35cdbc 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 @@ -1,7 +1,7 @@ --- title: カスタムリソース content_type: concept -weight: 20 +weight: 10 --- @@ -24,7 +24,7 @@ weight: 20 カスタムリソースそれ自身は、単純に構造化データを格納、取り出す機能を提供します。カスタムリソースを *カスタムコントローラー* と組み合わせることで、カスタムリソースは真の _宣言的API_ を提供します。 -[宣言的API](/ja/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetesオブジェクトを理解する)は、リソースのあるべき状態を _宣言_ または指定することを可能にし、Kubernetesオブジェクトの現在の状態を、あるべき状態に同期し続けるように動きます。 +[宣言的API](/ja/docs/concepts/overview/kubernetes-api/)は、リソースのあるべき状態を _宣言_ または指定することを可能にし、Kubernetesオブジェクトの現在の状態を、あるべき状態に同期し続けるように動きます。 コントローラーは、構造化データをユーザーが指定したあるべき状態と解釈し、その状態を管理し続けます。 稼働しているクラスターのライフサイクルとは無関係に、カスタムコントローラーをデプロイ、更新することが可能です。カスタムコントローラーはあらゆるリソースと連携できますが、カスタムリソースと組み合わせると特に効果を発揮します。[オペレーターパターン](https://coreos.com/blog/introducing-operators.html)は、カスタムリソースとカスタムコントローラーの組み合わせです。カスタムコントローラーにより、特定アプリケーションのドメイン知識を、Kubernetes APIの拡張に変換することができます。 @@ -67,7 +67,7 @@ APIが宣言的ではない兆候として、次のものがあります: - APIをオブジェクトとして簡単に表現できない - 停止している処理を処理ID、もしくは処理オブジェクトで表現することを選択している -## ConfigMapとカスタムリソースのどちらを使うべきか? +## ConfigMapとカスタムリソースのどちらを使うべきか？ 下記のいずれかに該当する場合は、ConfigMapを使ってください: @@ -99,7 +99,7 @@ Kubernetesは、クラスターへカスタムリソースを追加する2つの Kubernetesは、さまざまなユーザーのニーズを満たすためにこれら2つのオプションを提供しており、使いやすさや柔軟性が損なわれることはありません。 -アグリゲートAPIは、プロキシーとして機能するプライマリAPIサーバーの背後にある、下位のAPIServerです。このような配置は[APIアグリゲーション](/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) (AA)と呼ばれています。ユーザーにとっては、単にAPIサーバーが拡張されているように見えます。 +アグリゲートAPIは、プロキシーとして機能するプライマリAPIサーバーの背後にある、下位のAPIServerです。このような配置は[APIアグリゲーション](/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)(AA)と呼ばれています。ユーザーにとっては、単にAPIサーバーが拡張されているように見えます。 CRDでは、APIサーバーの追加なしに、ユーザーが新しい種類のリソースを作成できます。CRDを使うには、APIアグリゲーションを理解する必要はありません。 @@ -108,6 +108,7 @@ CRDでは、APIサーバーの追加なしに、ユーザーが新しい種類 ## CustomResourceDefinition [CustomResourceDefinition](/docs/tasks/access-kubernetes-api/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サーバーアグリゲーション)と比べると、柔軟性に欠けます。 @@ -115,7 +116,7 @@ CRDでは、APIサーバーの追加なしに、ユーザーが新しい種類 ## APIサーバーアグリゲーション -通常、Kubernetes APIの各リソースは、RESTリクエストとオブジェクトの永続的なストレージを管理するためのコードが必要です。メインのKubernetes APIサーバーは *Pod* や *Service* のようなビルトインのリソースを処理し、また[CRD](#customresourcedefinition)を通じて、同じ方法でカスタムリソースも管理できます。 +通常、Kubernetes APIの各リソースは、RESTリクエストとオブジェクトの永続的なストレージを管理するためのコードが必要です。メインのKubernetes APIサーバーは *Pod* や *Service* のようなビルトインのリソースを処理し、またカスタムリソースも[CRD](#customresourcedefinition)を通じて同じように管理することができます。 [アグリゲーションレイヤー](/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)は、独自のスタンドアローンAPIサーバーを書き、デプロイすることで、カスタムリソースに特化した実装の提供を可能にします。メインのAPIサーバーが、処理したいカスタムリソースへのリクエストを委譲することで、他のクライアントからも利用できるようにします。 @@ -134,7 +135,7 @@ CRDは、アグリゲートAPIと比べ、簡単に作れます。 | CRD | アグリゲートAPI | | -------------------------- | --------------- | -| プログラミングが不要で、ユーザーはCRDコントローラーとしてどの言語でも選択可能 | Go言語でプログラミングし、バイナリとイメージの作成が必要。ユーザーはCRDコントローラーとしてどの言語でも選択可能 | +| プログラミングが不要で、ユーザーはCRDコントローラーとしてどの言語でも選択可能 | Go言語でプログラミングし、バイナリとイメージの作成が必要 | | 追加のサービスは不要。カスタムリソースはAPIサーバーで処理される | 追加のサービス作成が必要で、障害が発生する可能性がある | | CRDが作成されると、継続的なサポートは無い。バグ修正は通常のKubernetesマスターのアップグレードで行われる | 定期的にアップストリームからバグ修正の取り込み、リビルド、そしてアグリゲートAPIサーバーの更新が必要かもしれない | | 複数バージョンのAPI管理は不要。例えば、あるリソースを操作するクライアントを管理していた場合、APIのアップグレードと一緒に更新される | 複数バージョンのAPIを管理しなければならない。例えば、世界中に共有されている拡張機能を開発している場合 | @@ -146,16 +147,16 @@ 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)によりサポートされている | はい、任意のバリデーションが可能 | -| デフォルト設定 | 上記を参照 | はい、[OpenAPI v3.0 validation](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#defaulting)の`default`キーワード(1.16でベータ)、または[Mutating Webhook](/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook-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) | はい | | カスタムストレージ | 異なる性能のストレージが必要な場合(例えば、キーバリューストアの代わりに時系列データベース)または、セキュリティの分離(例えば、機密情報の暗号化、その他)| いいえ | はい | | カスタムビジネスロジック | オブジェクトが作成、読み込み、更新、また削除されるときに任意のチェック、アクションを実行する| はい、[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) | はい | +| サブリソースの状態 | ユーザーがspecセクションに書き込み、コントローラーがstatusセクションに書き込む際に、より詳細なアクセスコントロールができるようにする。カスタムリソースのデータ変換時にオブジェクトの世代を上げられるようにする(リソース内のspecとstatusでセクションが分離している必要がある) | [はい](/docs/tasks/access-kubernetes-api/extend-api-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/)を参照 | いいえ | はい | | プロトコルバッファ | プロトコルバッファを使用するクライアントをサポートする新しいリソース | いいえ | はい | -| OpenAPIスキーマ | サーバーから動的に取得できる型のOpenAPI(スワッガー)スキーマはあるか、許可されたフィールドのみが設定されるようにすることで、ユーザーはフィールド名のスペルミスから保護されているか、型は強制されているか(言い換えると、「文字列」フィールドに「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/access-kubernetes-api/extend-api-custom-resource-definitions/#validation) スキーマがベース(1.16でGA) | はい | ### 一般的な機能 @@ -174,7 +175,7 @@ CRD、またはアグリゲートAPI、どちらを使ってカスタムリソ | ファイナライザー | 外部リソースの削除が終わるまで、拡張リソースの削除をブロック | | Admission Webhooks | 拡張リソースの作成/更新/削除処理時に、デフォルト値の設定、バリデーションを実施 | | UI/CLI 表示 | kubectl、ダッシュボードで拡張リソースを表示 | -| 未設定 vs 空設定 | クライアントは、フィールドの未設定とゼロ値を区別することができる | +| 未設定 対 空設定 | クライアントは、フィールドの未設定とゼロ値を区別することができる | | クライアントライブラリーの生成 | Kubernetesは、一般的なクライアントライブラリーと、タイプ固有のクライアントライブラリーを生成するツールを提供 | | ラベルとアノテーション | ツールがコアリソースとカスタムリソースの編集方法を知っているオブジェクト間で、共通のメタデータを提供 | @@ -184,7 +185,7 @@ CRD、またはアグリゲートAPI、どちらを使ってカスタムリソ ### サードパーティのコードと新しい障害点 -CRDを作成しても、勝手に新しい障害点が追加されてしまうことはありませんが（たとえば、サードパーティのコードをAPIサーバーで実行することによって）、パッケージ（たとえば、チャート）またはその他のインストールバンドルには、多くの場合、CRDと新しいカスタムリソースのビジネスロジックを実装するサードパーティコードが入ったDeploymentが含まれます。 +CRDを作成しても、勝手に新しい障害点が追加されてしまうことはありませんが(たとえば、サードパーティのコードをAPIサーバーで実行することによって)、パッケージ(たとえば、Chart)またはその他のインストールバンドルには、多くの場合、CRDと新しいカスタムリソースのビジネスロジックを実装するサードパーティコードが入ったDeploymentが含まれます。 アグリゲートAPIサーバーのインストールすると、常に新しいDeploymentが付いてきます。 @@ -220,5 +221,3 @@ 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/)について学ぶ - - diff --git a/content/ja/docs/concepts/extend-kubernetes/extend-cluster.md b/content/ja/docs/concepts/extend-kubernetes/extend-cluster.md index dad9190345..a1a1af7c6b 100644 --- a/content/ja/docs/concepts/extend-kubernetes/extend-cluster.md +++ b/content/ja/docs/concepts/extend-kubernetes/extend-cluster.md @@ -32,7 +32,7 @@ Kubernetesは柔軟な設定が可能で、高い拡張性を持っています ホスティングされたKubernetesサービスやマネージドなKubernetesでは、フラグと設定ファイルが常に変更できるとは限りません。変更可能な場合でも、通常はクラスターの管理者のみが変更できます。また、それらは将来のKubernetesバージョンで変更される可能性があり、設定変更にはプロセスの再起動が必要になるかもしれません。これらの理由により、この方法は他の選択肢が無いときにのみ利用するべきです。 -[ResourceQuota](/docs/concepts/policy/resource-quotas/)、[PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/)、[NetworkPolicy](/docs/concepts/services-networking/network-policies/)、そしてロールベースアクセス制御([RBAC](/docs/reference/access-authn-authz/rbac/))といった *ビルトインポリシーAPI* は、ビルトインのKubernetes APIです。APIは通常、ホスティングされたKubernetesサービスやマネージドなKubernetesで利用されます。これらは宣言的で、Podのような他のKubernetesリソースと同じ慣例に従っています。そのため、新しいクラスターの設定は繰り返し再利用することができ、アプリケーションと同じように管理することが可能です。更に、安定版（stable）を利用している場合、他のKubernetes APIのような[定義済みのサポートポリシー](/docs/reference/deprecation-policy/)を利用することができます。これらの理由により、この方法は、適切な用途の場合、 *設定ファイル* や *フラグ* よりも好まれます。 +[ResourceQuota](/docs/concepts/policy/resource-quotas/)、[PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/)、[NetworkPolicy](/docs/concepts/services-networking/network-policies/)、そしてロールベースアクセス制御([RBAC](/docs/reference/access-authn-authz/rbac/))といった *ビルトインポリシーAPI* は、ビルトインのKubernetes APIです。APIは通常、ホスティングされたKubernetesサービスやマネージドなKubernetesで利用されます。これらは宣言的で、Podのような他のKubernetesリソースと同じ慣例に従っています。そのため、新しいクラスターの設定は繰り返し再利用することができ、アプリケーションと同じように管理することが可能です。さらに、安定版(stable)を利用している場合、他のKubernetes APIのような[定義済みのサポートポリシー](/docs/reference/deprecation-policy/)を利用することができます。これらの理由により、この方法は、適切な用途の場合、 *設定ファイル* や *フラグ* よりも好まれます。 ## エクステンション @@ -42,7 +42,7 @@ Kubernetesは柔軟な設定が可能で、高い拡張性を持っています ほとんどのクラスター管理者は、ホスティングされている、またはディストリビューションとしてのKubernetesを使っているでしょう。 結果として、ほとんどのKubernetesユーザーは既存のエクステンションを使えばよいため、新しいエクステンションを書く必要は無いと言えます。 -## エクステンションパターン +## エクステンションパターン {#extension-patterns} Kubernetesは、クライアントのプログラムを書くことで自動化ができるようにデザインされています。 Kubernetes APIに読み書きをするどのようなプログラムも、役に立つ自動化機能を提供することができます。 @@ -57,8 +57,8 @@ Kubernetes上でうまく動くクライアントプログラムを書くため 呼び出されるサービスは *Webhookバックエンド* と呼ばれます。コントローラーのように、Webhookも障害点を追加します。 Webhookのモデルでは、Kubernetesは外部のサービスを呼び出します。 -*バイナリプラグイン* モデルでは、Kubernetesはバイナリ（プログラム）を実行します。 -バイナリプラグインはkubelet（例、[FlexVolumeプラグイン](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md)、[ネットワークプラグイン](/docs/concepts/cluster-administration/network-plugins/)）、またkubectlで利用されています。 +*バイナリプラグイン* モデルでは、Kubernetesはバイナリ(プログラム)を実行します。 +バイナリプラグインはkubelet(例、[FlexVolumeプラグイン](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md)、[ネットワークプラグイン](/docs/concepts/cluster-administration/network-plugins/))、またkubectlで利用されています。 下図は、それぞれの拡張ポイントが、Kubernetesのコントロールプレーンとどのように関わっているかを示しています。 @@ -103,7 +103,7 @@ Webhookのモデルでは、Kubernetesは外部のサービスを呼び出しま ### ビルトインリソースの変更 -カスタムリソースを追加し、KubernetesAPIを拡張する場合、新たに追加されたリソースは常に新しいAPIグループに分類されます。既存のAPIグループを置き換えたり、変更することはできません。APIを追加することは直接、既存のAPI（例、Pod）の振る舞いに影響を与えることは無いですが、APIアクセスエクステンションの場合、その可能性があります。 +カスタムリソースを追加し、KubernetesAPIを拡張する場合、新たに追加されたリソースは常に新しいAPIグループに分類されます。既存のAPIグループを置き換えたり、変更することはできません。APIを追加することは直接、既存のAPI(例、Pod)の振る舞いに影響を与えることは無いですが、APIアクセスエクステンションの場合、その可能性があります。 ### APIアクセスエクステンション @@ -111,7 +111,7 @@ Webhookのモデルでは、Kubernetesは外部のサービスを呼び出しま これらの各ステップごとに拡張ポイントが用意されています。 -Kubdernetesはいくつかのビルトイン認証方式をサポートしています。それは認証プロキシの後ろに配置することも可能で、認可ヘッダーを通じて（Webhookの）検証のために外部サービスにトークンを送ることもできます。全てのこれらの方法は[認証ドキュメント](/docs/reference/access-authn-authz/authentication/)でカバーされています。 +Kubdernetesはいくつかのビルトイン認証方式をサポートしています。それは認証プロキシの後ろに配置することも可能で、認可ヘッダーを通じて(Webhookの)検証のために外部サービスにトークンを送ることもできます。全てのこれらの方法は[認証ドキュメント](/docs/reference/access-authn-authz/authentication/)でカバーされています。 ### 認証 @@ -138,7 +138,7 @@ Kubernetesはいくつかのビルトイン認証方式と、それらが要件 ### デバイスプラグイン -[デバイスプラグイン](/docs/concepts/cluster-administration/device-plugins/)を通じて、ノードが新たなノードのリソース（CPU、メモリなどのビルトインのものに加え）を見つけることを可能にします。 +[デバイスプラグイン](/docs/concepts/cluster-administration/device-plugins/)を通じて、ノードが新たなノードのリソース(CPU、メモリなどのビルトインのものに加え)を見つけることを可能にします。 ### ネットワークプラグイン @@ -150,7 +150,7 @@ Kubernetesはいくつかのビルトイン認証方式と、それらが要件 これはかなりの大きな作業で、ほとんど全てのKubernetesユーザーはスケジューラーを変更する必要はありません。 -スケジューラは[Webhook](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/scheduler_extender.md)もサポートしており、Webhookバックエンド（スケジューラーエクステンション）を通じてPodを配置するために選択されたノードをフィルタリング、優先度付けすることが可能です。 +スケジューラは[Webhook](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/scheduler_extender.md)もサポートしており、Webhookバックエンド(スケジューラーエクステンション)を通じてPodを配置するために選択されたノードをフィルタリング、優先度付けすることが可能です。 diff --git a/content/ja/docs/concepts/extend-kubernetes/operator.md b/content/ja/docs/concepts/extend-kubernetes/operator.md index 0448510a4f..507463359d 100644 --- a/content/ja/docs/concepts/extend-kubernetes/operator.md +++ b/content/ja/docs/concepts/extend-kubernetes/operator.md @@ -24,7 +24,7 @@ Kubernetes上でワークロードを稼働させている人は、しばしば ## Kubernetesにおけるオペレーター Kubernetesは自動化のために設計されています。追加の作業、設定無しに、Kubernetesのコア機能によって多数のビルトインされた自動化機能が提供されます。 -ワークロードのデプロイ及び稼働を自動化するためにKubernetesを使うことができます。 *更に* Kubernetesがそれをどのように行うかの自動化も可能です。 +ワークロードのデプロイおよび稼働を自動化するためにKubernetesを使うことができます。 *さらに* Kubernetesがそれをどのように行うかの自動化も可能です。 Kubernetesの{{< glossary_tooltip text="コントローラー" term_id="controller" >}}コンセプトは、Kubernetesのソースコードを修正すること無く、クラスターの振る舞いを拡張することを可能にします。 オペレーターはKubernetes APIのクライアントで、[Custom Resource](/docs/concepts/api-extension/custom-resources/)にとっての、コントローラーのように振る舞います。 diff --git a/content/ja/docs/concepts/overview/components.md b/content/ja/docs/concepts/overview/components.md index bdc341d591..c805565665 100644 --- a/content/ja/docs/concepts/overview/components.md +++ b/content/ja/docs/concepts/overview/components.md @@ -9,7 +9,7 @@ card: Kubernetesをデプロイすると、クラスターが展開されます。 -{{< glossary_definition term_id="cluster" length="all" prepend="クラスターは、">}} +{{< glossary_definition term_id="cluster" length="all" prepend="Kubernetesクラスターは、">}} このドキュメントでは、Kubernetesクラスターが機能するために必要となるさまざまなコンポーネントの概要を説明します。 @@ -21,12 +21,11 @@ Kubernetesをデプロイすると、クラスターが展開されます。 -## マスターコンポーネント +## コントロールプレーンコンポーネント -マスターコンポーネントは、クラスターのコントロールプレーンを提供します。 -マスターコンポーネントは、クラスターに関する全体的な決定(スケジューリングなど)を行います。また、クラスターイベントの検出および応答を行います(たとえば、deploymentの`replicas`フィールドが満たされていない場合に、新しい {{< glossary_tooltip text="pod" term_id="pod">}} を起動する等)。 +コントロールプレーンコンポーネントは、クラスターに関する全体的な決定(スケジューリングなど)を行います。また、クラスターイベントの検出および応答を行います(たとえば、deploymentの`replicas`フィールドが満たされていない場合に、新しい {{< glossary_tooltip text="Pod" term_id="pod">}} を起動する等)。 -マスターコンポーネントはクラスター内のどのマシンでも実行できますが、シンプルにするため、セットアップスクリプトは通常、すべてのマスターコンポーネントを同じマシンで起動し、そのマシンではユーザーコンテナを実行しません。 +コントロールプレーンコンポーネントはクラスター内のどのマシンでも実行できますが、シンプルにするため、セットアップスクリプトは通常、すべてのコントロールプレーンコンポーネントを同じマシンで起動し、そのマシンではユーザーコンテナを実行しません。 マルチマスター VMセットアップの例については、[高可用性クラスターの構築](/docs/admin/high-availability/) を参照してください。 ### kube-apiserver @@ -68,7 +67,7 @@ cloud-controller-managerを使用すると、クラウドベンダーのコー * サービスコントローラー：クラウドプロバイダーのロードバランサーの作成、更新、削除を行います。 * ボリュームコントローラー：ボリュームを作成、アタッチ、マウントしたり、クラウドプロバイダーとやり取りしてボリュームを調整したりします。 -## ノードコンポーネント +## ノードコンポーネント {#node-components} ノードコンポーネントはすべてのノードで実行され、稼働中のPodの管理やKubernetesの実行環境を提供します。 diff --git a/content/ja/docs/concepts/overview/kubernetes-api.md b/content/ja/docs/concepts/overview/kubernetes-api.md index 4e21db1633..5d95929bef 100644 --- a/content/ja/docs/concepts/overview/kubernetes-api.md +++ b/content/ja/docs/concepts/overview/kubernetes-api.md @@ -3,7 +3,7 @@ reviewers: title: Kubernetes API content_type: concept weight: 30 -card: +card: name: concepts weight: 30 --- @@ -16,7 +16,7 @@ APIエンドポイント、リソースタイプ、そしてサンプルは[API APIへの外部からのアクセスは、[APIアクセス制御ドキュメント](/docs/reference/access-authn-authz/controlling-access/)に記載されています。 -Kubernetes APIは、システムの宣言的設定スキーマの基礎としても機能します。[kubectl](/docs/reference/kubectl/overview/)コマンドラインツールから、APIオブジェクトを作成、更新、削除、取得することが出来ます。 +Kubernetes APIは、システムの宣言的設定スキーマの基礎としても機能します。[kubectl](/docs/reference/kubectl/overview/)コマンドラインツールから、APIオブジェクトを作成、更新、削除、取得することができます。 また、Kubernetesは、シリアライズされた状態を(現在は[etcd](https://coreos.com/docs/distributed-configuration/getting-started-with-etcd/)に)APIリソースの単位で保存しています。 @@ -30,7 +30,7 @@ Kubernetesそれ自身は複数のコンポーネントから構成されてお 我々の経験上、成功を収めているどのようなシステムも、新しいユースケースへの対応、既存の変更に合わせ、成長し変わっていく必要があります。したがって、Kubernetesにも継続的に変化、成長することを期待しています。一方で、長期間にわたり、既存のクライアントとの互換性を損なわないようにする予定です。一般的に、新しいAPIリソースとリソースフィールドは頻繁に追加されることが予想されます。リソース、フィールドの削除は、[API廃止ポリシー](/docs/reference/using-api/deprecation-policy/)への準拠を必要とします。 -何が互換性のある変更を意味するか、またAPIをどのように変更するかは、[API変更ドキュメント](https://git.k8s.io/community/contributors/devel/api_changes.md)に詳解されています。 +何が互換性のある変更を意味するか、またAPIをどのように変更するかは、[API変更ドキュメント](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md)に詳解されています。 ## OpenAPIとSwaggerの定義 @@ -41,10 +41,10 @@ Kubernetes 1.10から、KubernetesAPIサーバーは`/openapi/v2`のエンドポ ヘッダ | 設定可能な値 ------ | --------------- -Accept | `application/json`, `application/com.github.proto-openapi.spec.v2@v1.0+protobuf` （デフォルトのcontent-typeは、`*/*`に対して`application/json`か、もしくはこのヘッダーを送信しません） -Accept-Encoding | `gzip` （このヘッダーを送信しないことも許容されています） +Accept | `application/json`, `application/com.github.proto-openapi.spec.v2@v1.0+protobuf` (デフォルトのcontent-typeは、`*/*`に対して`application/json`か、もしくはこのヘッダーを送信しません) +Accept-Encoding | `gzip` (このヘッダーを送信しないことも許容されています) -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で削除される予定です。 +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仕様の取得サンプル**: @@ -57,7 +57,7 @@ GET /swagger-2.0.0.pb-v1.gz | GET /openapi/v2 **Accept**: application/com.github 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で削除される予定です。 +このエンドポイントは非推奨となっており、Kubernetes1.14で削除されました。 ## APIバージョニング @@ -67,16 +67,16 @@ APIが、システムリソースと動作について明確かつ一貫した 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`）。 +- アルファレベル(版): + - バージョン名に`alpha`を含みます(例、`v1alpha1`)。 - バグが多いかもしれません。アルファ機能の有効化がバグを顕在化させるかもしれません。デフォルトでは無効となっています。 - アルファ機能のサポートは、いつでも通知無しに取りやめられる可能性があります。 - ソフトウェアリリース後、APIが通知無しに互換性が無い形で変更される可能性があります。 - バグが増えるリスク、また長期サポートが無いことから、短期間のテスト用クラスターでの利用を推奨します。 -- ベータレベル（版）: - - バージョン名に`beta`を含みます（例、`v2beta3`）。 +- ベータレベル(版): + - バージョン名に`beta`を含みます(例、`v2beta3`)。 - コードは十分にテストされています。ベータ機能の有効化は安全だと考えられます。デフォルトで有効化されています。 - 全体的な機能のサポートは取りやめられませんが、詳細は変更される可能性があります。 - オブジェクトのスキーマ、意味はその後のベータ、安定版リリースで互換性が無い形で変更される可能性があります。その場合、次のバージョンへアップデートするための手順を提供します。その手順ではAPIオブジェクトの削除、修正、再作成が必要になるかもしれません。修正のプロセスは多少の検討が必要になるかもしれません。これは、この機能を利用しているアプリケーションでダウンタイムが必要になる可能性があるためです。 @@ -93,24 +93,24 @@ APIグループは、RESTのパスとシリアライズされたオブジェク 現在、いくつかの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`)を使います。サポートされているAPIグループの全リストは、[Kubernetes APIリファレンス](/docs/reference/)を参照してください。 [カスタムリソース](/docs/concepts/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/)を使い、クライアントにシームレスな形で拡張を行います。 -## APIグループの有効化 +## APIグループの有効化、無効化 いくつかのリソースとAPIグループはデフォルトで有効になっています。それらは、APIサーバーの`--runtime-config`設定で、有効化、無効化できます。`--runtime-config`は、カンマ区切りの複数の値を設定可能です。例えば、batch/v1を無効化する場合、`--runtime-config=batch/v1=false`をセットし、batch/v2alpha1を有効化する場合、`--runtime-config=batch/v2alpha1`をセットします。このフラグは、APIサーバーのランタイム設定を表すkey=valueのペアを、カンマ区切りで指定したセットを指定可能です。 -重要: APIグループ、リソースの有効化、無効化は、`--runtime-config`の変更を反映するため、APIサーバーとコントローラーマネージャーの再起動が必要です。 +{{< note >}}APIグループ、リソースの有効化、無効化は、`--runtime-config`の変更を反映するため、APIサーバーとコントローラーマネージャーの再起動が必要です。{{< /note >}} -## APIグループのリソースの有効化 - -DaemonSets、Deployments、HorizontalPodAutoscalers、Ingresses、JobsReplicaSets、そしてReplicaSetsはデフォルトで有効です。 -その他の拡張リソースは、APIサーバーの`--runtime-config`を設定することで有効化できます。`--runtime-config`はカンマ区切りの複数の値を設定可能です。例えば、deploymentsとingressを無効化する場合、`--runtime-config=extensions/v1beta1/deployments=false,extensions/v1beta1/ingresses=false`と設定します。 +## APIグループextensions/v1beta1に含まれる特定のリソースの有効化 +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 >}} diff --git a/content/ja/docs/concepts/overview/what-is-kubernetes.md b/content/ja/docs/concepts/overview/what-is-kubernetes.md index 1b90ef4a3f..5f2f4bbf18 100644 --- a/content/ja/docs/concepts/overview/what-is-kubernetes.md +++ b/content/ja/docs/concepts/overview/what-is-kubernetes.md @@ -1,8 +1,11 @@ --- +reviewers: title: Kubernetesとは何か？ +description: > + Kubernetesは、宣言的な構成管理と自動化を促進し、コンテナ化されたワークロードやサービスを管理するための、ポータブルで拡張性のあるオープンソースのプラットフォームです。Kubernetesは巨大で急速に成長しているエコシステムを備えており、それらのサービス、サポート、ツールは幅広い形で利用可能です。 content_type: concept weight: 10 -card: +card: name: concepts weight: 10 --- @@ -12,94 +15,76 @@ card: -Kubernetesは、宣言的な構成管理と自動化を促進し、コンテナ化されたワークロードやサービスを管理するための、ポータブルで拡張性のあるオープンソースプラットホームです。 +Kubernetesは、宣言的な構成管理と自動化を促進し、コンテナ化されたワークロードやサービスを管理するための、ポータブルで拡張性のあるオープンソースのプラットフォームです。Kubernetesは巨大で急速に成長しているエコシステムを備えており、それらのサービス、サポート、ツールは幅広い形で利用可能です。 -Kubernetesは膨大で、急速に成長しているエコシステムを備えており、それらのサービス、サポート、ツールは幅広い形で利用可能です。 +Kubernetesの名称は、ギリシャ語に由来し、操舵手やパイロットを意味しています。Googleは2014年にKubernetesプロジェクトをオープンソース化しました。Kubernetesは、本番環境で大規模なワークロードを稼働させた[Googleの15年以上の経験](/blog/2015/04/borg-predecessor-to-kubernetes/)と、コミュニティからの最高のアイディアや実践を組み合わせています。 -Googleは2014年にKubernetesプロジェクトをオープンソース化しました。Kubernetesは[Googleが大規模な本番ワークロードを動かしてきた10年半の経験](https://research.google.com/pubs/pub43438.html)と、コミュニティから得られた最善のアイデア、知見に基づいています。 +## 過去を振り返ってみると -## なぜKubernetesが必要で、どんなことができるのか？ +過去を振り返って、Kubernetesがなぜこんなに便利なのかを見てみましょう。 -Kubernetesには多くの機能があります。考えられるものとしては +![Deployment evolution](/images/docs/Container_Evolution.svg) -- コンテナ基盤 -- マイクロサービス基盤 -- ポータブルなクラウド基盤 +**仮想化ができる前の時代におけるデプロイ (Traditional deployment):** 初期の頃は、組織は物理サーバー上にアプリケーションを実行させていました。物理サーバー上でアプリケーションのリソース制限を設定する方法がなかったため、リソースの割当問題が発生していました。例えば、複数のアプリケーションを実行させた場合、ひとつのアプリケーションがリソースの大半を消費してしまうと、他のアプリケーションのパフォーマンスが低下してしまうことがありました。この解決方法は、それぞれのアプリケーションを別々の物理サーバーで動かすことでした。しかし、リソースが十分に活用できなかったため、拡大しませんでした。また組織にとって多くの物理サーバーを維持することは費用がかかりました。 -など、他にもいろいろ +**仮想化を使ったデプロイ (Virtualized deployment):** ひとつの解決方法として、仮想化が導入されました。1台の物理サーバーのCPU上で、複数の仮想マシン(VM)を実行させることができるようになりました。仮想化によりアプリケーションをVM毎に隔離する事ができ、ひとつのアプリケーションの情報が他のアプリケーションから自由にアクセスさせないといったセキュリティレベルを提供することができます。 -Kubernetesは、**コンテナを中心とした**管理基盤です。ユーザーワークロードの代表格であるコンピューティング、ネットワーキング、ストレージインフラストラクチャのオーケストレーションを行います。それによって、Platform as a Service(PaaS)の簡単さの大部分を、Infrastructure as a Service(IaaS)の柔軟さとともに提供し、インフラストラクチャプロバイダの垣根を超えたポータビリティを実現します。 +仮想化により、物理サーバー内のリソース使用率が向上し、アプリケーションの追加や更新が容易になり、ハードウェアコストの削減などスケーラビリティが向上します。仮想化を利用すると、物理リソースのセットを使い捨て可能な仮想マシンのクラスターとして提示することができます。 -## Kubernetesが基盤になるってどういうこと？ +各VMは、仮想ハードウェア上で各自のOSを含んだ全コンポーネントを実行する完全なマシンです。 -Kubernetesが多くの機能を提供すると言いつつも、新しい機能から恩恵を受ける新しいシナリオは常にあります。アプリケーション固有のワークフローを効率化して開発者のスピードを早めることができます。最初は許容できるアドホックなオーケストレーションでも、大規模で堅牢な自動化が必要となることはしばしばあります。これが、Kubernetesがアプリケーションのデプロイ、拡張、および管理を容易にするために、コンポーネントとツールのエコシステムを構築するための基盤としても機能するように設計された理由です。 +**コンテナを使ったデプロイ (Container deployment):** コンテナはVMと似ていますが、アプリケーション間でオペレーティング・システム(OS)を共有できる緩和された分離特性を持っています。そのため、コンテナは軽量だといわれます。VMと同じように、コンテナは各自のファイルシステム、CPU、メモリー、プロセス空間等を持っています。基盤のインフラストラクチャから分離されているため、クラウドやOSディストリビューションを越えて移動することが可能です。 -[ラベル](/ja/docs/concepts/overview/working-with-objects/labels/)を使用すると、ユーザーは自分のリソースを整理できます。[アノテーション](/ja/docs/concepts/overview/working-with-objects/annotations/)を使用すると、ユーザーは自分のワークフローを容易にし、管理ツールが状態をチェックするための簡単な方法を提供するためにカスタムデータを使ってリソースを装飾できるようになります。 +コンテナは、その他にも次のようなメリットを提供するため、人気が高まっています。 -さらに、[Kubernetesコントロールプレーン](/ja/docs/concepts/overview/components/)は、開発者やユーザーが使える[API](/docs/reference/using-api/api-overview/)の上で成り立っています。ユーザーは[スケジューラー](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/devel/scheduler.md)などの独自のコントローラーを、汎用の[コマンドラインツール](/docs/user-guide/kubectl-overview/)で使える[独自のAPI](/docs/concepts/api-extension/custom-resources/)を持たせて作成することができます。 +* アジャイルアプリケーションの作成とデプロイ: VMイメージの利用時と比較して、コンテナイメージ作成の容易さと効率性が向上します。 +* 継続的な開発、インテグレーションとデプロイ: 信頼できる頻繁なコンテナイメージのビルドと、素早く簡単にロールバックすることが可能なデプロイを提供します。(イメージが不変であれば) +* 開発者と運用者の関心を分離: アプリケーションコンテナイメージの作成は、デプロイ時ではなく、ビルド/リリース時に行います。それによって、インフラストラクチャとアプリケーションを分離します。 +* 可観測性はOSレベルの情報とメトリクスだけではなく、アプリケーションの稼働状態やその他の警告も表示します。 +* 開発、テスト、本番環境を越えた環境の一貫性: クラウドで実行させるのと同じようにノートPCでも実行させる事ができます。 +* クラウドとOSディストリビューションの可搬性: Ubuntu、RHEL、CoreOS上でも、オンプレミスも、主要なパブリッククラウドでも、それ以外のどんな環境でも、実行できます。 +* アプリケーション中心の管理: 仮想マシン上でOSを実行するから、論理リソースを使用してOS上でアプリケーションを実行するへと抽象度のレベルを向上させます。 +* 疎結合、分散化、拡張性、柔軟性のあるマイクロサービス: アプリケーションを小さく、同時にデプロイと管理が可能な独立した部品に分割されます。1台の大きな単一目的のマシン上に実行するモノリシックなスタックではありません。 +* リソースの分割: アプリケーションのパフォーマンスが予測可能です。 +* リソースの効率的な利用: 高い効率性と集約性が可能です。 -この[デザイン](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md)によって、他の多くのシステムがKubernetes上で構築できるようになりました。 +## Kubernetesが必要な理由と提供する機能 {#why-you-need-kubernetes-and-what-can-it-do} -## Kubernetesにないこと +コンテナは、アプリケーションを集約して実行する良い方法です。本番環境では、アプリケーションを実行しダウンタイムが発生しないように、コンテナを管理する必要があります。例えば、コンテナがダウンした場合、他のコンテナを起動する必要があります。このような動作がシステムに組込まれていると、管理が簡単になるのではないでしょうか？ -Kubernetesは伝統的な何でも入りのPaaSシステムではありません。Kubernetesはハードウェアレベルではなくコンテナレベルで動作するため、PaaS製品が提供するような、共通のいくつかの一般的に適用可能な機能(デプロイ、拡張、負荷分散、ログ記録、監視など)を提供します。ただし、Kubernetesはモノリシックではなく、これらのデフォルトのソリューションは任意に脱着可能です。Kubernetesは開発者の基盤を構築するための構成要素を提供しますが、重要な場合はユーザーの選択と柔軟性を維持します。 +そこを助けてくれるのがKubernetesです! Kubernetesは分散システムを弾力的に実行するフレームワークを提供してくれます。あなたのアプリケーションのためにスケーリングとフェイルオーバーの面倒を見てくれて、デプロイのパターンなどを提供します。例えば、Kubernetesはシステムにカナリアデプロイを簡単に管理することができます。 + +Kubernetesは以下を提供します。 + +* **サービスディスカバリーと負荷分散** +Kubernetesは、DNS名または独自のIPアドレスを使ってコンテナを公開することができます。コンテナへのトラフィックが多い場合は、Kubernetesは負荷分散し、ネットワークトラフィックを振り分けることができるたため、デプロイが安定します。 +* **ストレージ オーケストレーション** +Kubernetesは、ローカルストレージやパブリッククラウドプロバイダーなど、選択したストレージシステムを自動でマウントすることができます。 +* **自動化されたロールアウトとロールバック** +Kubernetesを使うとデプロイしたコンテナのあるべき状態を記述することができ、制御されたスピードで実際の状態をあるべき状態に変更することができます。例えば、アプリケーションのデプロイのために、新しいコンテナの作成や既存コンテナの削除、新しいコンテナにあらゆるリソースを適用する作業を、Kubernetesで自動化できます。 +* **自動ビンパッキング** +コンテナ化されたタスクを実行するノードのクラスターをKubernetesへ提供します。各コンテナがどれくらいCPUやメモリー(RAM)を必要とするのかをKubernetesに宣言することができます。Kubernetesはコンテナをノードにあわせて調整することができ、リソースを最大限に活用してくれます。 +* **自己修復** +Kubernetesは、処理が失敗したコンテナを再起動し、コンテナを入れ替え、定義したヘルスチェックに応答しないコンテナを強制終了します。処理の準備ができるまでは、クライアントに通知しません。 +* **機密情報と構成管理** +Kubernetesは、パスワードやOAuthトークン、SSHキーのよう機密の情報を保持し、管理することができます。機密情報をデプロイし、コンテナイメージを再作成することなくアプリケーションの構成情報を更新することができます。スタック構成の中で機密情報を晒してしまうこともありません。 + +## Kubernetesにないもの + +Kubernetesは、従来型の全部入りなPaaS(Platform as a Service)のシステムではありません。Kubernetesはハードウェアレベルではなく、コンテナレベルで動作するため、デプロイ、スケーリング、負荷分散、ロギングやモニタリングといったPasSが提供するのと共通の機能をいくつか提供しています。また一方、Kubernetesはモノリシックでなく、標準のソリューションは選択が自由で、追加と削除が容易な構成になっています。Kubernetesは開発プラットフォーム構築のためにビルディングブロックを提供しますが、重要な部分はユーザーの選択と柔軟性を維持しています。 Kubernetesは... -* サポートするアプリケーションの種類を限定しません。Kubernetesはステートレス、ステートフル、およびデータ処理ワークロードなど、非常に多様なワークロードをサポートするように作られています。アプリケーションをコンテナ内で実行できる場合は、Kubernetes上でもうまく動作するはずです。 -* ソースコードのデプロイやアプリケーションのビルドを行いません。継続的インテグレーション、デリバリー、デプロイ(CI/CD)ワークフローは、技術選定がそうであるように、組織の文化や好みによって決まるからです。 -* ミドルウェア(例: message buses)、データ処理フレームワーク(例: Spark)、データベース(例: mysql)、キャッシュ、クラスターストレージシステム(例: Ceph) のような、アプリケーションレベルの機能は組み込みでは提供しません。これらのコンポーネントはKubernetesの上で動作できますし、Open Service Brokerのようなポータブルメカニズムを経由してKubernetes上のアプリケーションからアクセスすることもできます。 -* ロギング、モニタリング、アラーティングソリューションへの指示は行いません。概念実証(PoC)としていくつかのインテグレーション、およびメトリックを収集およびエクスポートするためのメカニズムを提供します。 -* 設定言語/システム(例： jsonnet)を提供も強制もしません。任意の形式の宣言仕様の対象となる可能性がある宣言APIを提供します。 -* 包括的なインフラ構成、保守、管理、またはセルフヒーリングシステムを提供、導入しません。 - -さらに、Kubernetesは単なる *オーケストレーションシステム* ではありません。実際、オーケストレーションは不要です。*オーケストレーション* の技術的定義は、定義されたワークフローの実行です。最初にA、次にB、次にCを実行します。対照的に、Kubernetesは現在の状態を提供された望ましい状態に向かって継続的に推進する一連の独立した構成可能な制御プロセスで構成されます。AからCへのアクセス方法は関係ありません。集中管理も必要ありません。これにより、使いやすく、より強力で、堅牢で、回復力があり、そして拡張性のあるシステムが得られます。 - -## なぜコンテナなのか？ - -なぜコンテナを使うべきかの理由をお探しですか？ - -![なぜコンテナなのか？](/images/docs/why_containers.svg) - -アプリケーションをデプロイするための古い方法は、オペレーティングシステムのパッケージマネージャを使用してアプリケーションをホストにインストールすることでした。これには、アプリケーションの実行ファイル、構成、ライブラリ、ライフサイクルがそれぞれ、またホストOS自身と絡み合うというデメリットがありました。予測可能なロールアウトとロールバックを実現するために、不変の仮想マシンイメージを作成することもできますが、VMは重く、移植性がありません。 - -新しい方法は、ハードウェア仮想化ではなく、オペレーティングシステムレベルの仮想化に基づいてコンテナを展開することです。各コンテナは互いに、そしてホストから隔離されています。また、独自のファイルシステムを持ち、お互いのプロセスを見ることができず、計算リソースの使用量を制限することができます。これはVMよりも構築が簡単で、基盤となるインフラストラクチャとホストのファイルシステムから分離されているため、クラウドやOSのディストリビューション間で移植性があります。 - -コンテナは小さくて速いので、1つのアプリケーションを各コンテナイメージにまとめることができます。この1対1のアプリケーションとイメージの関係により、コンテナの利点が完全に引き出されます。コンテナを使用すると、各アプリケーションを残りのアプリケーションスタックと合成したり、本番インフラストラクチャ環境と結合したりする必要がないため、不変のコンテナイメージをデプロイ時ではなく、ビルド時またはリリース時に作成できます。ビルド/リリース時にコンテナイメージを生成することで、開発から運用に一貫した環境を持ち込むことができます。同様に、コンテナはVMよりもはるかに透過的であるため、監視と管理が容易になります。これは、コンテナのプロセスライフサイクルがコンテナ内のプロセススーパーバイザによって隠されるのではなく、インフラストラクチャによって管理される場合に特に当てはまります。最後に、コンテナごとに1つのアプリケーションを使用すると、コンテナの管理はアプリケーションのデプロイ管理と同等になります。 - -コンテナの利点をまとめると: - -* **アジャイルなアプリケーション作成とデプロイ**: - VMイメージの使用と比べ、コンテナイメージ作成は容易で効率も高いです。 -* **継続的な開発、インテグレーション、デプロイ**: - 迅速で簡単なロールバックで、信頼性の高い頻繁なコンテナイメージのビルドとデプロイを提供します(イメージの不変性にもよります)。 -* **開発と運用の懸念を分離**: - デプロイ時ではなくビルド時またはリリース時にアプリケーションのコンテナイメージを作成することで、アプリケーションをインフラストラクチャから切り離します。 -* **可観測性** - OSレベルの情報や測定基準だけでなく、アプリケーションの正常性やその他のシグナルも明確にします。 -* **開発、テスト、本番環境に跨った環境の一貫性**: - 手元のノートPC上でも、クラウド上と同じように動作します。 -* **クラウドとOSディストリビューションの移植性**: - Ubuntu、RHEL、CoreOS、オンプレミス、Google Kubernetes Engine、その他のどこでも動作します。 -* **アプリケーション中心の管理**: - 仮想ハードウェア上でのOS実行から、論理リソースを使用したOS上でのアプリケーション実行へと、抽象度のレベルを上げます。 -* **疎結合で、分散された、伸縮自在の遊離した[マイクロサービス](https://martinfowler.com/articles/microservices.html)**: - アプリケーションは小さな独立した欠片に分割され、動的に配置および管理できます。1つの大きな単一目的のマシンで実行されるモノリシックなスタックではありません。 -* **リソース分割**: - アプリケーションパフォーマンスが予測可能です。 -* **リソースの効率利用**: - 高効率で高密度です。 - -## Kubernetesってどういう意味？K8sって何？ - -**Kubernetes** という名前はギリシャ語で *操舵手* や *パイロット* という意味があり、*知事* や[サイバネティックス](http://www.etymonline.com/index.php?term=cybernetics)の語源にもなっています。*K8s* は、8文字の「ubernete」を「8」に置き換えた略語です。 - +* サポートするアプリケーションの種類を制限しません。Kubernetesは、スレートレス、ステートフルやデータ処理のワークロードなど、非常に多様なワークロードをサポートすることを目的としています。アプリケーションがコンテナで実行できるのであれば、Kubernetes上で問題なく実行できるはずです。 +* ソースコードのデプロイやアプリケーションのビルドは行いません。継続的なインテグレーション、デリバリー、デプロイ(CI/CD)のワークフローは、技術的な要件だけでなく組織の文化や好みで決められます。 +* ミドルウェア(例:メッセージバス)、データ処理フレームワーク(例:Spark)、データベース(例:MySQL)、キャッシュ、クラスターストレージシステム(例:Ceph)といったアプリケーションレベルの機能を組み込んで提供しません。それらのコンポーネントは、Kubernetes上で実行することもできますし、[Open Service Broker](https://openservicebrokerapi.org/)のようなポータブルメカニズムを経由してKubernetes上で実行されるアプリケーションからアクセスすることも可能です。 +* ロギング、モニタリングやアラートを行うソリューションは指定しません。PoCとしていくつかのインテグレーションとメトリクスを収集し出力するメカニズムを提供します。 +* 構成言語/システム(例:Jsonnet)の提供も指示もしません。任意の形式の宣言型仕様の対象となる可能性のある宣言型APIを提供します。 +* 統合的なマシンの構成、メンテナンス、管理、または自己修復を行うシステムは提供も採用も行いません。 +* さらに、Kubernetesは単なるオーケストレーションシステムではありません。実際には、オーケストレーションの必要性はありません。オーケストレーションの技術的な定義は、「最初にAを実行し、次にB、その次にCを実行」のような定義されたワークフローの実行です。対照的にKubernetesは、現在の状態から提示されたあるべき状態にあわせて継続的に維持するといった、独立していて構成可能な制御プロセスのセットを提供します。AからCへどのように移行するかは問題ではありません。集中管理も必要ありません。これにより、使いやすく、より強力で、堅牢で、弾力性と拡張性があるシステムが実現します。 ## {{% heading "whatsnext" %}} -* [はじめる](/docs/setup/)準備はできましたか？ -* さらなる詳細については、[Kubernetesのドキュメント](/ja/docs/home/)を御覧ください。 - - - +* [Kubernetesのコンポーネント](/ja/docs/concepts/overview/components/)を御覧ください。 +* [はじめる](/ja/docs/setup/)準備はできましたか？ 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 16d1bdd27a..48cbed282a 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 @@ -2,7 +2,7 @@ title: Kubernetesオブジェクトを理解する content_type: concept weight: 10 -card: +card: name: concepts weight: 40 --- @@ -12,31 +12,31 @@ card: -## Kubernetesオブジェクトを理解する +## Kubernetesオブジェクトを理解する {#kubernetes-objects} -*Kubernetesオブジェクト* は、Kubernetes上で永続的なエンティティです。Kubernetesはこれらのエンティティを使い、クラスターの状態を表現します。具体的に言うと、下記のような内容が表現出来ます: +*Kubernetesオブジェクト* は、Kubernetes上で永続的なエンティティです。Kubernetesはこれらのエンティティを使い、クラスターの状態を表現します。具体的に言うと、下記のような内容が表現できます: -* どのようなコンテナ化されたアプリケーションが稼働しているか（またそれらはどのノード上で動いているか） +* どのようなコンテナ化されたアプリケーションが稼働しているか(またそれらはどのノード上で動いているか) * それらのアプリケーションから利用可能なリソース * アプリケーションがどのように振る舞うかのポリシー、例えば再起動、アップグレード、耐障害性ポリシーなど -Kubernetesオブジェクトは"意図の記録"です。一度オブジェクトを作成すると、Kubernetesは常にそのオブジェクトが存在し続けるように動きます。オブジェクトを作成することで、Kubernetesに対し効果的にあなたのクラスターのワークロードがこのようになっていて欲しいと伝えているのです。これが、あなたのクラスターの**望ましい状態**です。 +Kubernetesオブジェクトは「意図の記録」です。一度オブジェクトを作成すると、Kubernetesは常にそのオブジェクトが存在し続けるように動きます。オブジェクトを作成することで、Kubernetesに対し効果的にあなたのクラスターのワークロードがこのようになっていて欲しいと伝えているのです。これが、あなたのクラスターの**望ましい状態**です。 Kubernetesオブジェクトを操作するには、作成、変更、または削除に関わらず[Kubernetes API](/ja/docs/concepts/overview/kubernetes-api/)を使う必要があるでしょう。例えば`kubectl`コマンドラインインターフェースを使った場合、このCLIが処理に必要なKubernetes API命令を、あなたに代わり発行します。あなたのプログラムから[クライアントライブラリ](/docs/reference/using-api/client-libraries/)を利用し、直接Kubernetes APIを利用することも可能です。 -### オブジェクトのspec（仕様）とstatus（状態） +### オブジェクトのspec(仕様)とstatus(状態) ほとんどのKubernetesオブジェクトは、オブジェクトの設定を管理する２つの入れ子になったオブジェクトのフィールドを持っています。それはオブジェクト *`spec`* とオブジェクト *`status`* です。`spec`を持っているオブジェクトに関しては、オブジェクト作成時に`spec`を設定する必要があり、望ましい状態としてオブジェクトに持たせたい特徴を記述する必要があります。 `status` オブジェクトはオブジェクトの *現在の状態* を示し、その情報はKubernetesとそのコンポーネントにより提供、更新されます。Kubernetes{{< glossary_tooltip text="コントロールプレーン" term_id="control-plane" >}}は、あなたから指定された望ましい状態と現在の状態が一致するよう常にかつ積極的に管理をします。 -例えば、KubernetesのDeploymentはクラスター上で稼働するアプリケーションを表現するオブジェクトです。Deploymentを作成するとき、アプリケーションの複製を３つ稼働させるようDeploymentのspecで指定するかもしれません。KubernetesはDeploymentのspecを読み取り、指定されたアプリケーションを３つ起動し、現在の状態がspecに一致するようにします。もしこれらのインスタンスでどれかが落ちた場合（statusが変わる）、Kubernetesはspecと、statusの違いに反応し、修正しようとします。この場合は、落ちたインスタンスの代わりのインスタンスを立ち上げます。 +例えば、KubernetesのDeploymentはクラスター上で稼働するアプリケーションを表現するオブジェクトです。Deploymentを作成するとき、アプリケーションの複製を３つ稼働させるようDeploymentのspecで指定するかもしれません。KubernetesはDeploymentのspecを読み取り、指定されたアプリケーションを３つ起動し、現在の状態がspecに一致するようにします。もしこれらのインスタンスでどれかが落ちた場合(statusが変わる)、Kubernetesはspecと、statusの違いに反応し、修正しようとします。この場合は、落ちたインスタンスの代わりのインスタンスを立ち上げます。 spec、status、metadataに関するさらなる情報は、[Kubernetes API Conventions](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md)をご確認ください。 ### Kubernetesオブジェクトを記述する -Kubernetesでオブジェクトを作成する場合、オブジェクトの基本的な情報（例えば名前）と共に、望ましい状態を記述したオブジェクトのspecを渡さなければいけません。KubernetesAPIを利用しオブジェクトを作成する場合（直接APIを呼ぶか、`kubectl`を利用するかに関わらず）、APIリクエストはそれらの情報をJSON形式でリクエストのBody部に含んでいなければなりません。 +Kubernetesでオブジェクトを作成する場合、オブジェクトの基本的な情報(例えば名前)と共に、望ましい状態を記述したオブジェクトのspecを渡さなければいけません。KubernetesAPIを利用しオブジェクトを作成する場合(直接APIを呼ぶか、`kubectl`を利用するかに関わらず)、APIリクエストはそれらの情報をJSON形式でリクエストのBody部に含んでいなければなりません。 ここで、KubernetesのDeploymentに必要なフィールドとオブジェクトのspecを記載した`.yaml`ファイルの例を示します: @@ -63,7 +63,7 @@ Kubernetesオブジェクトを`.yaml`ファイルに記載して作成する場 * `metadata` - オブジェクトを一意に特定するための情報、文字列の`name`、`UID`、また任意の`namespace`が該当する * `spec` - オブジェクトの望ましい状態 -`spec`の正確なフォーマットは、Kubernetesオブジェクトごとに異なり、オブジェクトごとに特有な入れ子のフィールドを持っています。[Kubernetes API リファレンス](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)が、Kubernetesで作成出来る全てのオブジェクトに関するspecのフォーマットを探すのに役立ちます。 +`spec`の正確なフォーマットは、Kubernetesオブジェクトごとに異なり、オブジェクトごとに特有な入れ子のフィールドを持っています。[Kubernetes API リファレンス](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)が、Kubernetesで作成できる全てのオブジェクトに関するspecのフォーマットを探すのに役立ちます。 例えば、`Pod`オブジェクトに関する`spec`のフォーマットは[PodSpec v1 core](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)を、また`Deployment`オブジェクトに関する`spec`のフォーマットは[DeploymentSpec v1 apps](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deploymentspec-v1-apps)をご確認ください。 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 95442bdf4c..c7ebacf360 100644 --- a/content/ja/docs/concepts/overview/working-with-objects/labels.md +++ b/content/ja/docs/concepts/overview/working-with-objects/labels.md @@ -185,7 +185,7 @@ kubectl get pods -l 'environment in (production),tier in (frontend)' ``` すでに言及したように、*集合ベース* の要件は、*等価ベース* の要件より表現力があります。 -例えば、値に対する_OR_ オペレーターを実装して以下のように書けます。 +例えば、値に対する _OR_ オペレーターを実装して以下のように書けます。 ```shell kubectl get pods -l 'environment in (production, qa)' 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 1286e3c667..1b66e046f1 100644 --- a/content/ja/docs/concepts/overview/working-with-objects/namespaces.md +++ b/content/ja/docs/concepts/overview/working-with-objects/namespaces.md @@ -78,7 +78,7 @@ kubectl config view --minify | grep namespace: ## NamespaceとDNS ユーザーが[Service](/ja/docs/concepts/services-networking/service/)を作成するとき、Serviceは対応する[DNSエントリ](/ja/docs/concepts/services-networking/dns-pod-service/)を作成します。 -このエントリは`..svc.cluster.local`という形式になり,これはもしあるコンテナがただ``を指定していた場合、Namespace内のローカルのServiceに対して名前解決されます。 +このエントリは`..svc.cluster.local`という形式になり、これはもしあるコンテナがただ``を指定していた場合、Namespace内のローカルのServiceに対して名前解決されます。 これはデベロップメント、ステージング、プロダクションといって複数のNamespaceをまたいで同じ設定を使う時に効果的です。 もしユーザーがNamespaceをまたいでアクセスしたい時、 完全修飾ドメイン名(FQDN)を指定する必要があります。 diff --git a/content/ja/docs/concepts/overview/working-with-objects/object-management.md b/content/ja/docs/concepts/overview/working-with-objects/object-management.md index bbf0085cf1..49092c6dea 100644 --- a/content/ja/docs/concepts/overview/working-with-objects/object-management.md +++ b/content/ja/docs/concepts/overview/working-with-objects/object-management.md @@ -63,7 +63,7 @@ kubectl create deployment nginx --image nginx ## 命令型オブジェクト設定 -命令型オブジェクト設定では、kubectlコマンドに処理内容（create、replaceなど）、任意のフラグ、そして最低1つのファイル名を指定します。 +命令型オブジェクト設定では、kubectlコマンドに処理内容(create、replaceなど)、任意のフラグ、そして最低1つのファイル名を指定します。 指定されたファイルは、YAMLまたはJSON形式でオブジェクトの全ての定義情報を含んでいなければいけません。 オブジェクト定義の詳細は、[APIリファレンス](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)を参照してください。 @@ -150,7 +150,7 @@ kubectl apply -R -f configs/ 命令型オブジェクト設定手法に対する長所: - 現行オブジェクトに直接行われた変更が、それらが設定ファイルに反映されていなかったとしても、保持されます -- 宣言型オブジェクト設定は、ディレクトリごとの処理をより良くサポートしており、自動的にオブジェクトごとに操作のタイプ（作成、パッチ、削除）を検出します +- 宣言型オブジェクト設定は、ディレクトリごとの処理をより良くサポートしており、自動的にオブジェクトごとに操作のタイプ(作成、パッチ、削除)を検出します 命令型オブジェクト設定手法に対する短所: @@ -163,9 +163,9 @@ kubectl apply -R -f configs/ - [命令型コマンドを利用したKubernetesオブジェクトの管理](/docs/tasks/manage-kubernetes-objects/imperative-command/) -- [オブジェクト設定（命令型）を利用したKubernetesオブジェクトの管理](/docs/tasks/manage-kubernetes-objects/imperative-config/) -- [オブジェクト設定（宣言型）を利用したKubernetesオブジェクトの管理](/docs/tasks/manage-kubernetes-objects/declarative-config/) -- [Kustomize（宣言型）を利用したKubernetesオブジェクトの管理](/docs/tasks/manage-kubernetes-objects/kustomization/) +- [オブジェクト設定(命令型)を利用したKubernetesオブジェクトの管理](/docs/tasks/manage-kubernetes-objects/imperative-config/) +- [オブジェクト設定(宣言型)を利用したKubernetesオブジェクトの管理](/docs/tasks/manage-kubernetes-objects/declarative-config/) +- [Kustomize(宣言型)を利用したKubernetesオブジェクトの管理](/docs/tasks/manage-kubernetes-objects/kustomization/) - [Kubectlコマンドリファレンス](/docs/reference/generated/kubectl/kubectl-commands/) - [Kubectl Book](https://kubectl.docs.kubernetes.io) - [Kubernetes APIリファレンス](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) diff --git a/content/ja/docs/concepts/scheduling/kube-scheduler.md b/content/ja/docs/concepts/scheduling/kube-scheduler.md index 4e7d14284d..65c6ac6518 100644 --- a/content/ja/docs/concepts/scheduling/kube-scheduler.md +++ b/content/ja/docs/concepts/scheduling/kube-scheduler.md @@ -104,7 +104,7 @@ kube-schedulerは、デフォルトで用意されているスケジューリン - `ImageLocalityPriority`: すでにPodに対するコンテナイメージをローカルにキャッシュしているNodeを優先します。 -- `ServiceSpreadingPriority`: このポリシーの目的は、特定のServiceに対するバックエンドのPodが、それぞれ異なるNodeで実行されるようにすることです。このポリシーではServiceのバックエンドのPodが既に実行されていないNode上にスケジュールするように優先します。これによる結果として、Serviceは単体のNode障害に対してより耐障害性が高まります。 +- `ServiceSpreadingPriority`: このポリシーの目的は、特定のServiceに対するバックエンドのPodが、それぞれ異なるNodeで実行されるようにすることです。このポリシーではServiceのバックエンドのPodがすでに実行されていないNode上にスケジュールするように優先します。これによる結果として、Serviceは単体のNode障害に対してより耐障害性が高まります。 - `CalculateAntiAffinityPriorityMap`: このポリシーは[PodのAnti-Affinity](/ja/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity)の実装に役立ちます。 diff --git a/content/ja/docs/concepts/scheduling/scheduler-perf-tuning.md b/content/ja/docs/concepts/scheduling/scheduler-perf-tuning.md index 2a096295a1..b1fea64038 100644 --- a/content/ja/docs/concepts/scheduling/scheduler-perf-tuning.md +++ b/content/ja/docs/concepts/scheduling/scheduler-perf-tuning.md @@ -10,7 +10,7 @@ weight: 70 [kube-scheduler](/docs/concepts/scheduling/kube-scheduler/#kube-scheduler)はKubernetesのデフォルトのスケジューラーです。クラスター内のノード上にPodを割り当てる責務があります。 -クラスター内に存在するノードで、Podのスケジューリング要求を満たすものはPodに対して_割り当て可能_ なノードと呼ばれます。スケジューラーはPodに対する割り当て可能なノードをみつけ、それらの割り当て可能なノードにスコアをつけます。その中から最も高いスコアのノードを選択し、Podに割り当てるためのいくつかの関数を実行します。スケジューラーは_Binding_ と呼ばれる処理中において、APIサーバーに対して割り当てが決まったノードの情報を通知します。 +クラスター内に存在するノードで、Podのスケジューリング要求を満たすものはPodに対して*割り当て可能*なノードと呼ばれます。スケジューラーはPodに対する割り当て可能なノードをみつけ、それらの割り当て可能なノードにスコアをつけます。その中から最も高いスコアのノードを選択し、Podに割り当てるためのいくつかの関数を実行します。スケジューラーは*Binding*と呼ばれる処理中において、APIサーバーに対して割り当てが決まったノードの情報を通知します。 このページでは、大規模のKubernetesクラスターにおけるパフォーマンス最適化のためのチューニングについて説明します。 @@ -35,11 +35,11 @@ algorithmSource: percentageOfNodesToScore: 50 ``` -{{< note >}} +{{< note >}} 割り当て可能なノードが50未満のクラスターにおいては、割り当て可能なノードの探索を止めるほどノードが多くないため、スケジューラーは全てのノードをチェックします。 {{< /note >}} -**この機能を無効にするためには**、`percentageOfNodesToScore`を100に設定してください。 +**この機能を無効にするためには**、`percentageOfNodesToScore`を100に設定してください。 ### percentageOfNodesToScoreのチューニング diff --git a/content/ja/docs/concepts/scheduling/taint-and-toleration.md b/content/ja/docs/concepts/scheduling/taint-and-toleration.md new file mode 100644 index 0000000000..90930357a8 --- /dev/null +++ b/content/ja/docs/concepts/scheduling/taint-and-toleration.md @@ -0,0 +1,221 @@ +--- +title: TaintとToleration +content_type: concept +weight: 40 +--- + + + +[_Nodeアフィニティ_](/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity)は +{{< glossary_tooltip text="Pod" term_id="pod" >}}の属性であり、ある{{< glossary_tooltip text="Node" term_id="node" >}}群を*引きつけます*（優先条件または必須条件）。反対に _taint_ はNodeがある種のPodを排除できるようにします。 + +_toleration_ はPodに適用され、一致するtaintが付与されたNodeへPodがスケジューリングされることを認めるものです。ただしそのNodeへ必ずスケジューリングされるとは限りません。 + +taintとtolerationは組になって機能し、Podが不適切なNodeへスケジューリングされないことを保証します。taintはNodeに一つまたは複数個付与することができます。これはそのNodeがtaintを許容しないPodを受け入れるべきではないことを示します。 + + + + +## コンセプト + +Nodeにtaintを付与するには[kubectl taint](/docs/reference/generated/kubectl/kubectl-commands#taint)コマンドを使用します。 +例えば、次のコマンドは + +```shell +kubectl taint nodes node1 key=value:NoSchedule +``` + +`node1`にtaintを設定します。このtaintのキーは`key`、値は`value`、taintの効果は`NoSchedule`です。 +これは`node1`にはPodに合致するtolerationがなければスケジューリングされないことを意味します。 + +上記のコマンドで付与したtaintを外すには、下記のコマンドを使います。 +```shell +kubectl taint nodes node1 key:NoSchedule- +``` + +PodのtolerationはPodSpecの中に指定します。下記のtolerationはどちらも、上記の`kubectl taint`コマンドで追加したtaintと合致するため、どちらのtolerationが設定されたPodも`node1`へスケジューリングされることができます。 + +```yaml +tolerations: +- key: "key" + operator: "Equal" + value: "value" + effect: "NoSchedule" +``` + +```yaml +tolerations: +- key: "key" + operator: "Exists" + effect: "NoSchedule" +``` + +tolerationを設定したPodの例を示します。 + +{{< codenew file="pods/pod-with-toleration.yaml" >}} + +`operator`のデフォルトは`Equal`です。 + +tolerationがtaintと合致するのは、`key`と`effect`が同一であり、さらに下記の条件のいずれかを満たす場合です。 + +* `operator`が`Exists`（`value`を指定すべきでない場合） +* `operator`が`Equal`であり、かつ`value`が同一である場合 + +{{< note >}} + +2つ特殊な場合があります。 + +空の`key`と演算子`Exists`は全ての`key`、`value`、`effect`と一致するため、すべてのtaintと合致します。 + +空の`effect`は`key`が一致する全てのeffectと合致します。 + +{{< /note >}} + +上記の例では`effect`に`NoSchedule`を指定しました。代わりに、`effect`に`PreferNoSchedule`を指定することができます。 +これは`NoSchedule`の「ソフトな」バージョンであり、システムはtaintに対応するtolerationが設定されていないPodがNodeへ配置されることを避けようとしますが、必須の条件とはしません。3つ目の`effect`の値として`NoExecute`がありますが、これについては後述します。 + +同一のNodeに複数のtaintを付与することや、同一のPodに複数のtolerationを設定することができます。 +複数のtaintやtolerationが設定されている場合、Kubernetesはフィルタのように扱います。最初はNodeの全てのtaintがある状態から始め、Podが対応するtolerationを持っているtaintは無視され外されていきます。無視されずに残ったtaintが効果を及ぼします。 +具体的には、 + +* effect `NoSchedule`のtaintが無視されず残った場合、KubernetesはそのPodをNodeへスケジューリングしません。 +* effect `NoSchedule`のtaintは残らず、effect `PreferNoSchedule`のtaintは残った場合、KubernetesはそのNodeへのスケジューリングをしないように試みます。 +* effect `NoExecute`のtaintが残った場合、既に稼働中のPodはそのNodeから排除され、まだ稼働していないPodはスケジューリングされないようになります。 + +例として、下記のようなtaintが付与されたNodeを考えます。 + +```shell +kubectl taint nodes node1 key1=value1:NoSchedule +kubectl taint nodes node1 key1=value1:NoExecute +kubectl taint nodes node1 key2=value2:NoSchedule +``` + +Podには2つのtolerationが設定されています。 + +```yaml +tolerations: +- key: "key1" + operator: "Equal" + value: "value1" + effect: "NoSchedule" +- key: "key1" + operator: "Equal" + value: "value1" + effect: "NoExecute" +``` + +この例では、3つ目のtaintと合致するtolerationがないため、PodはNodeへはスケジューリングされません。 +しかし、これらのtaintが追加された時点で、そのNodeでPodが稼働していれば続けて稼働することが可能です。 これは、Podのtolerationと合致しないtaintは3つあるtaintのうちの3つ目のtaintのみであり、それが`NoSchedule`であるためです。 + +一般に、effect `NoExecute`のtaintがNodeに追加されると、合致するtolerationが設定されていないPodは即時にNodeから排除され、合致するtolerationが設定されたPodが排除されることは決してありません。 +しかし、effect`NoExecute`に対するtolerationは`tolerationSeconds`フィールドを任意で指定することができ、これはtaintが追加された後にそのNodeにPodが残る時間を示します。例えば、 + +```yaml +tolerations: +- key: "key1" + operator: "Equal" + value: "value1" + effect: "NoExecute" + tolerationSeconds: 3600 +``` + +この例のPodが稼働中で、対応するtaintがNodeへ追加された場合、PodはそのNodeに3600秒残り、その後排除されます。仮にtaintがそれよりも前に外された場合、Podは排除されません。 + +## ユースケースの例 + +taintとtolerationは、実行されるべきではないNodeからPodを遠ざけたり、排除したりするための柔軟な方法です。いくつかのユースケースを示します。 + +* **専有Node**: あるNode群を特定のユーザーに専有させたい場合、そのNode群へtaintを追加し(`kubectl taint nodes nodename dedicated=groupName:NoSchedule`) 対応するtolerationをPodへ追加します（これを実現する最も容易な方法はカスタム +[アドミッションコントローラー](/docs/reference/access-authn-authz/admission-controllers/)を書くことです）。 +tolerationが設定されたPodはtaintの設定された（専有の）Nodeと、クラスターにあるその他のNodeの使用が認められます。もしPodが必ず専有Node*のみ*を使うようにしたい場合は、taintと同様のラベルをそのNode群に設定し(例: `dedicated=groupName`)、アドミッションコントローラーはNodeアフィニティを使ってPodが`dedicated=groupName`のラベルの付いたNodeへスケジューリングすることが必要であるということも設定する必要があります。 + +* **特殊なハードウェアを備えるNode**: クラスターの中の少数のNodeが特殊なハードウェア（例えばGPU）を備える場合、そのハードウェアを必要としないPodがスケジューリングされないようにして、後でハードウェアを必要とするPodができたときの余裕を確保したいことがあります。 +これは特殊なハードウェアを持つNodeにtaintを追加(例えば `kubectl taint nodes nodename special=true:NoSchedule` または +`kubectl taint nodes nodename special=true:PreferNoSchedule`)して、ハードウェアを使用するPodに対応するtolerationを追加することで可能です。 +専有Nodeのユースケースと同様に、tolerationを容易に適用する方法はカスタム +[アドミッションコントローラー](/docs/reference/access-authn-authz/admission-controllers/)を使うことです。 +例えば、特殊なハードウェアを表すために[拡張リソース](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources) +を使い、ハードウェアを備えるNodeに拡張リソースの名称のtaintを追加して、 +[拡張リソースtoleration](/docs/reference/access-authn-authz/admission-controllers/#extendedresourcetoleration) +アドミッションコントローラーを実行することが推奨されます。Nodeにはtaintが付与されているため、tolerationのないPodはスケジューリングされません。しかし拡張リソースを要求するPodを作成しようとすると、`拡張リソースtoleration` アドミッションコントローラーはPodに自動的に適切なtolerationを設定し、Podはハードウェアを備えるNodeへスケジューリングされます。 +これは特殊なハードウェアを備えたNodeではそれを必要とするPodのみが稼働し、Podに対して手作業でtolerationを追加しなくて済むようにします。 + +* **taintを基にした排除**: Nodeに問題が起きたときにPodごとに排除する設定を行うことができます。次のセクションにて説明します。 + +## taintを基にした排除 + +{{< feature-state for_k8s_version="v1.18" state="stable" >}} + +上述したように、effect `NoExecute`のtaintはNodeで実行中のPodに次のような影響を与えます。 + + * 対応するtolerationのないPodは即座に除外される + * 対応するtolerationがあり、それに`tolerationSeconds`が指定されていないPodは残り続ける + * 対応するtolerationがあり、それに`tolerationSeconds`が指定されているPodは指定された間、残される + +Nodeコントローラーは特定の条件を満たす場合に自動的にtaintを追加します。 +組み込まれているtaintは下記の通りです。 + + * `node.kubernetes.io/not-ready`: Nodeの準備ができていない場合。これはNodeCondition `Ready`が`False`である場合に対応します。 + * `node.kubernetes.io/unreachable`: NodeがNodeコントローラーから到達できない場合。これはNodeCondition`Ready`が`Unknown`の場合に対応します。 + * `node.kubernetes.io/out-of-disk`: Nodeのディスクの空きがない場合。 + * `node.kubernetes.io/memory-pressure`: Nodeのメモリーが不足している場合。 + * `node.kubernetes.io/disk-pressure`: Nodeのディスクが不足している場合。 + * `node.kubernetes.io/network-unavailable`: Nodeのネットワークが利用できない場合。 + * `node.kubernetes.io/unschedulable`: Nodeがスケジューリングできない場合。 + * `node.cloudprovider.kubernetes.io/uninitialized`: kubeletが外部のクラウド事業者により起動されたときに設定されるtaintで、このNodeは利用不可能であることを示します。cloud-controller-managerによるコントローラーがこのNodeを初期化した後にkubeletはこのtaintを外します。 + +Nodeから追い出すときには、Nodeコントローラーまたはkubeletは関連するtaintを`NoExecute`効果の状態で追加します。 +不具合のある状態から通常の状態へ復帰した場合は、kubeletまたはNodeコントローラーは関連するtaintを外すことができます。 + +{{< note >}} +コントロールプレーンは新しいtaintをNodeに加えるレートを制限しています。 +このレート制限は一度に多くのNodeが到達不可能になった場合（例えばネットワークの断絶）に、退役させられるNodeの数を制御します。 +{{< /note >}} + +Podに`tolerationSeconds`を指定することで不具合があるか応答のないNodeに残る時間を指定することができます。 + +例えば、ローカルの状態を多数持つアプリケーションとネットワークが分断された場合を考えます。ネットワークが復旧して、Podを排除しなくて済むことを見込んで、長時間Nodeから排除されないようにしたいこともあるでしょう。 +この場合Podに設定するtolerationは次のようになります。 + +```yaml +tolerations: +- key: "node.kubernetes.io/unreachable" + operator: "Exists" + effect: "NoExecute" + tolerationSeconds: 6000 +``` + +{{< note >}} +Kubernetesはユーザーまたはコントローラーが明示的に指定しない限り、自動的に`node.kubernetes.io/not-ready`と`node.kubernetes.io/unreachable`に対するtolerationを`tolerationSeconds=300`にて設定します。 + +自動的に設定されるtolerationは、taintに対応する問題がNodeで検知されても5分間はそのNodeにPodが残されることを意味します。 +{{< /note >}} + +[DaemonSet](/docs/concepts/workloads/controllers/daemonset/)のPodは次のtaintに対して`NoExecute`のtolerationが`tolerationSeconds`を指定せずに設定されます。 + + * `node.kubernetes.io/unreachable` + * `node.kubernetes.io/not-ready` + +これはDaemonSetのPodはこれらの問題によって排除されないことを保証します。 + +## 条件によるtaintの付与 + +NodeのライフサイクルコントローラーはNodeの状態に応じて`NoSchedule`効果のtaintを付与します。 +スケジューラーはNodeの状態ではなく、taintを確認します。 +Nodeに何がスケジューリングされるかは、そのNodeの状態に影響されないことを保証します。ユーザーは適切なtolerationをPodに付与することで、どの種類のNodeの問題を無視するかを選ぶことができます。 + +DaemonSetのコントローラーは、DaemonSetが中断されるのを防ぐために自動的に次の`NoSchedule`tolerationを全てのDaemonSetに付与します。 + + * `node.kubernetes.io/memory-pressure` + * `node.kubernetes.io/disk-pressure` + * `node.kubernetes.io/out-of-disk` (*重要なPodのみ*) + * `node.kubernetes.io/unschedulable` (1.10またはそれ以降) + * `node.kubernetes.io/network-unavailable` (*ホストネットワークのみ*) + +これらのtolerationを追加することは後方互換性を保証します。DaemonSetに任意のtolerationを加えることもできます。 + + +## {{% heading "whatsnext" %}} + +* [リソース枯渇の対処](/docs/tasks/administer-cluster/out-of-resource/)とどのような設定ができるかについてを読む +* [Podの優先度](/docs/concepts/configuration/pod-priority-preemption/)を読む diff --git a/content/ja/docs/concepts/services-networking/ingress-controllers.md b/content/ja/docs/concepts/services-networking/ingress-controllers.md new file mode 100644 index 0000000000..f19d21ef43 --- /dev/null +++ b/content/ja/docs/concepts/services-networking/ingress-controllers.md @@ -0,0 +1,57 @@ +--- +title: Ingressコントローラー +reviewers: +content_type: concept +weight: 40 +--- + + + +Ingressリソースが動作するためには、クラスターでIngressコントローラーが実行されている必要があります。 + +`kube-controller-manager`バイナリの一部として実行される他のタイプのコントローラーとは異なり、Ingressコントローラーはクラスターで自動的に起動されません。このページを使用して、クラスターに最適なIngressコントローラーの実装を選択してください。 + +プロジェクトとしてのKubernetesは現在、[GCE](https://git.k8s.io/ingress-gce/README.md)と[nginx](https://git.k8s.io/ingress-nginx/README.md)のコントローラーをサポートし、保守しています。 + + + + + +## 追加のコントローラー {#additional-controllers} + +* [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)のサポートと保守を提供しています。 +* [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)を提供しています。 +* [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/)を参照してください。 +* [Istio](https://istio.io/)ベースのIngressコントローラー[Control Ingress Traffic](https://istio.io/docs/tasks/traffic-management/ingress/)。 +* [Kong](https://konghq.com/)は、[Kong Ingress Controller for Kubernetes](https://github.com/Kong/kubernetes-ingress-controller)の[コミュニティ版](https://discuss.konghq.com/c/kubernetes)と[商用版]](https://konghq.com/kong-enterprise/)のサポートと保守を提供しています。 +* [NGINX, Inc.](https://www.nginx.com/)は[NGINX Ingress Controller for Kubernetes](https://www.nginx.com/products/nginx/kubernetes-ingress-controller)のサポートと保守を提供しています。 +* [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/)は、カスタムプロキシーを構築するためのライブラリーとして設計された、Kubernetes Ingressなどのユースケースを含む、サービス構成用のHTTPルーターとリバースプロキシーです。 +* [Traefik](https://github.com/containous/traefik)はフル機能([Let's Encrypt](https://letsencrypt.org), secrets, http2, websocket)のIngressコントローラーで、[Containous](https://containo.us/services)による商用サポートもあります。 + +## 複数のIngressコントローラーの使用 {#using-multiple-ingress-controllers} + +[Ingressコントローラーは、好きな数だけ](https://git.k8s.io/ingress-nginx/docs/user-guide/multiple-ingress.md#multiple-ingress-controllers))クラスターにデプロイすることができます。Ingressを作成する際には、クラスター内に複数のIngressコントローラーが存在する場合にどのIngressコントローラーを使用するかを示すために適切な[`ingress.class`](https://git.k8s.io/ingress-gce/docs/faq/README.md#how-do-i-run-multiple-ingress-controllers-in-the-same-cluster)のアノテーションを指定します。 + +クラスを定義しない場合、クラウドプロバイダーはデフォルトのIngressコントローラーを使用する場合があります。 + +理想的には、すべてのIngressコントローラーはこの仕様を満たすべきですが、いくつかのIngressコントローラーはわずかに異なる動作をします。 + + +{{< note >}} +Ingressコントローラーのドキュメントを確認して、選択する際の注意点を理解してください。 +{{< /note >}} + + + +## {{% heading "whatsnext" %}} + + +* [Ingress](/ja/docs/concepts/services-networking/ingress/)の詳細 +* [Set up Ingress on Minikube with the NGINX Controller](/docs/tasks/access-application-cluster/ingress-minikube) diff --git a/content/ja/docs/concepts/workloads/controllers/cron-jobs.md b/content/ja/docs/concepts/workloads/controllers/cron-jobs.md index acc1ff3722..60e8e68370 100644 --- a/content/ja/docs/concepts/workloads/controllers/cron-jobs.md +++ b/content/ja/docs/concepts/workloads/controllers/cron-jobs.md @@ -46,7 +46,7 @@ Cannot determine if job needs to be started. Too many missed start time (> 100). 例として、CronJobが`08:30:00`を開始時刻として1分ごとに新しいJobをスケジュールするように設定され、`startingDeadlineSeconds`フィールドが設定されていない場合を想定します。CronJobコントローラーが`08:29:00` から`10:21:00`の間にダウンしていた場合、スケジューリングを逃したジョブの数が100を超えているため、ジョブは開始されません。 -このコンセプトを更に掘り下げるために、CronJobが`08:30:00`から1分ごとに新しいJobを作成し、`startingDeadlineSeconds`が200秒に設定されている場合を想定します。CronJobコントローラーが前回の例と同じ期間(`08:29:00` から`10:21:00`まで)にダウンしている場合でも、10:22:00時点でJobはまだ動作しています。このようなことは、過去200秒間(言い換えると、3回の失敗)に何回スケジュールが間に合わなかったをコントローラーが確認するときに発生します。これは最後にスケジュールされた時間から今までのものではありません。 +このコンセプトをさらに掘り下げるために、CronJobが`08:30:00`から1分ごとに新しいJobを作成し、`startingDeadlineSeconds`が200秒に設定されている場合を想定します。CronJobコントローラーが前回の例と同じ期間(`08:29:00` から`10:21:00`まで)にダウンしている場合でも、10:22:00時点でJobはまだ動作しています。このようなことは、過去200秒間(言い換えると、3回の失敗)に何回スケジュールが間に合わなかったをコントローラーが確認するときに発生します。これは最後にスケジュールされた時間から今までのものではありません。 CronJobはスケジュールに一致するJobの作成にのみ関与するのに対して、JobはJobが示すPod管理を担います。 diff --git a/content/ja/docs/concepts/workloads/controllers/deployment.md b/content/ja/docs/concepts/workloads/controllers/deployment.md index 8fae6041e8..f3b210ff4a 100644 --- a/content/ja/docs/concepts/workloads/controllers/deployment.md +++ b/content/ja/docs/concepts/workloads/controllers/deployment.md @@ -3,7 +3,7 @@ title: Deployment feature: title: 自動化されたロールアウトとロールバック description: > - Kubernetesはアプリケーションや設定への変更を段階的に行い、アプリケーションの状態を監視しながら、全てのインスタンスが同時停止しないようにします。更新に問題が起きたとき、Kubernetesは変更のロールバックを行います。進化を続けるDeploymnetのエコシステムを活用してください。 + Kubernetesはアプリケーションや設定への変更を段階的に行い、アプリケーションの状態を監視しながら、全てのインスタンスが同時停止しないようにします。更新に問題が起きたとき、Kubernetesは変更のロールバックを行います。進化を続けるDeploymentのエコシステムを活用してください。 content_type: concept weight: 30 @@ -1001,7 +1001,7 @@ Deploymentのセレクターに一致するラベルを持つPodを直接作成 Deploymentのリビジョン履歴は、Deploymentが管理するReplicaSetに保持されています。 -`.spec.revisionHistoryLimit`はオプションのフィールドで、ロールバック可能な古いReplicaSetの数を指定します。この古いReplicaSetは`etcd`内のリソースを消費し、`kubectl get rs`の出力結果を見にくくします。Deploymentの各リビジョンの設定はReplicaSetに保持されます。このため一度古いReplicaSetが削除されると、そのリビジョンのDeploymentにロールバックすることができなくなります。デフォルトでは10もの古いReplicaSetが保持されます。しかし、この値の最適値は新しいDeploymnetの更新頻度と安定性に依存します。 +`.spec.revisionHistoryLimit`はオプションのフィールドで、ロールバック可能な古いReplicaSetの数を指定します。この古いReplicaSetは`etcd`内のリソースを消費し、`kubectl get rs`の出力結果を見にくくします。Deploymentの各リビジョンの設定はReplicaSetに保持されます。このため一度古いReplicaSetが削除されると、そのリビジョンのDeploymentにロールバックすることができなくなります。デフォルトでは10もの古いReplicaSetが保持されます。しかし、この値の最適値は新しいDeploymentの更新頻度と安定性に依存します。 さらに詳しく言うと、この値を0にすると、0のレプリカを持つ古い全てのReplicaSetが削除されます。このケースでは、リビジョン履歴が完全に削除されているため新しいDeploymentのロールアウトを完了することができません。 diff --git a/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md b/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md index e663d5b9c9..d1b1cc3354 100644 --- a/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md +++ b/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md @@ -29,7 +29,7 @@ TTLコントローラーは、そのリソースが終了したあと指定し TTL秒はいつでもセット可能です。下記はJobの`.spec.ttlSecondsAfterFinished`フィールドのセットに関するいくつかの例です。 * Jobがその終了後にいくつか時間がたった後に自動的にクリーンアップできるように、そのリソースマニフェストにこの値を指定します。 -* この新しい機能を適用させるために、存在していて既に終了したリソースに対してこのフィールドをセットします。 +* この新しい機能を適用させるために、存在していてすでに終了したリソースに対してこのフィールドをセットします。 * リソース作成時に、このフィールドを動的にセットするために、[管理webhookの変更](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)をさせます。クラスター管理者は、終了したリソースに対して、このTTLポリシーを強制するために使うことができます。 * リソースが終了した後に、このフィールドを動的にセットしたり、リソースステータスやラベルなどの値に基づいて異なるTTL値を選択するために、[管理webhookの変更](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)をさせます。 diff --git a/content/ja/docs/concepts/workloads/pods/init-containers.md b/content/ja/docs/concepts/workloads/pods/init-containers.md index 5d285b15d8..3486c55219 100644 --- a/content/ja/docs/concepts/workloads/pods/init-containers.md +++ b/content/ja/docs/concepts/workloads/pods/init-containers.md @@ -8,7 +8,7 @@ weight: 40 このページでは、Initコンテナについて概観します。Initコンテナとは、{{< glossary_tooltip text="Pod" term_id="pod" >}}内でアプリケーションコンテナの前に実行される特別なコンテナです。 Initコンテナにはアプリケーションコンテナのイメージに存在しないセットアップスクリプトやユーティリティーを含めることができます。 -Initコンテナは、Podの仕様のうち`containers`という配列（これがアプリケーションコンテナを示します）と並べて指定します。 +Initコンテナは、Podの仕様のうち`containers`という配列(これがアプリケーションコンテナを示します)と並べて指定します。 ## Initコンテナを理解する {#understanding-init-containers} @@ -202,7 +202,7 @@ myapp-pod 1/1 Running 0 9m このシンプルな例を独自のInitコンテナを作成する際の参考にしてください。[次の項目](#what-s-next)にさらに詳細な使用例に関するリンクがあります。 -## Initコンテナのふるまいに関する詳細 {#Detailed behavior} +## Initコンテナのふるまいに関する詳細 {#detailed-behavior} Podの起動時において、各Initコンテナはネットワークとボリュームが初期化されたのちに順番に起動します。各Initコンテナは次のInitコンテナが起動する前に正常に終了しなくてはなりません。もしあるInitコンテナがランタイムもしくはエラーにより起動失敗した場合、そのPodの`restartPolicy`の値に従ってリトライされます。しかし、もしPodの`restartPolicy`が`Always`に設定されていた場合、Initコンテナの`restartPolicy`は`OnFailure`が適用されます。 @@ -213,7 +213,7 @@ Podは全てのInitコンテナが完了するまで`Ready`状態となりませ Initコンテナの仕様の変更は、コンテナイメージのフィールドのみに制限されています。 Initコンテナのイメージフィールド値を変更すると、そのPodは再起動されます。 -Initコンテナは何度も再起動およびリトライ可能なため、べき等（Idempotent）である必要があります。特に、`EmptyDirs`にファイルを書き込むコードは、書き込み先のファイルがすでに存在している可能性を考慮に入れる必要があります。 +Initコンテナは何度も再起動およびリトライ可能なため、べき等(Idempotent)である必要があります。特に、`EmptyDirs`にファイルを書き込むコードは、書き込み先のファイルがすでに存在している可能性を考慮に入れる必要があります。 Initコンテナはアプリケーションコンテナの全てのフィールドを持っています。しかしKubernetesは、Initコンテナが完了と異なる状態を定義できないため`readinessProbe`が使用されることを禁止しています。これはバリデーションの際に適用されます。 @@ -230,11 +230,11 @@ Initコンテナの順序と実行を考えるとき、リソースの使用に * リソースに対する全てのアプリケーションコンテナのリクエスト／リミットの合計 * リソースに対する有効なinitリクエスト／リミット * スケジューリングは有効なリクエスト／リミットに基づいて実行されます。つまり、InitコンテナはPodの生存中には使用されない初期化用のリソースを確保することができます。 -* Podの*有効なQos（quality of service）ティアー* は、Initコンテナとアプリケーションコンテナで同様です。 +* Podの*有効なQoS(quality of service)ティアー* は、Initコンテナとアプリケーションコンテナで同様です。 クォータとリミットは有効なPodリクエストとリミットに基づいて適用されます。 -Podレベルのコントロールグループ（cgroups）は、スケジューラーと同様に、有効なPodリクエストとリミットに基づいています。 +Podレベルのコントロールグループ(cgroups)は、スケジューラーと同様に、有効なPodリクエストとリミットに基づいています。 ### Podの再起動の理由 {#pod-restart-reasons} @@ -250,4 +250,3 @@ Podレベルのコントロールグループ（cgroups）は、スケジュー * [Initコンテナを含むPodの作成](/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container)方法について学ぶ。 * [Initコンテナのデバッグ](/ja/docs/tasks/debug-application-cluster/debug-init-containers/)を行う方法について学ぶ。 - diff --git a/content/ja/docs/concepts/workloads/pods/pod-overview.md b/content/ja/docs/concepts/workloads/pods/pod-overview.md index 1917d6adf2..76e8f11a62 100644 --- a/content/ja/docs/concepts/workloads/pods/pod-overview.md +++ b/content/ja/docs/concepts/workloads/pods/pod-overview.md @@ -1,5 +1,5 @@ --- -title: Podについての概観(Pod Overview) +title: Podの概観 content_type: concept weight: 10 card: @@ -8,7 +8,7 @@ card: --- -このページでは、Kubernetesのオブジェクトモデルにおいて、デプロイ可能な最小単位のオブジェクトである`Pod`に関して概観します。 +このページでは、Kubernetesのオブジェクトモデルにおいて、デプロイ可能な最小単位のオブジェクトである`Pod`に関して説明します。 @@ -62,7 +62,7 @@ Podは、Podによって構成されたコンテナ群のために2種類の共 ## Podを利用する ユーザーはまれに、Kubenetes内で独立したPodを直接作成する場合があります(シングルトンPodなど)。 -これはPodが比較的、一時的な使い捨てエンティティとしてデザインされているためです。Podが作成された時（ユーザーによって直接的、またはコントローラーによって間接的に作成された場合）、ユーザーのクラスター内の単一の{{< glossary_tooltip term_id="node" >}}上で稼働するようにスケジューリングされます。そのPodはプロセスが停止されたり、Podオブジェクトが削除されたり、Podがリソースの欠如のために*追い出され* たり、ノードが故障するまでノード上に残り続けます。 +これはPodが比較的、一時的な使い捨てエンティティとしてデザインされているためです。Podが作成された時(ユーザーによって直接的、またはコントローラーによって間接的に作成された場合)、ユーザーのクラスター内の単一の{{< glossary_tooltip term_id="node" >}}上で稼働するようにスケジューリングされます。そのPodはプロセスが停止されたり、Podオブジェクトが削除されたり、Podがリソースの欠如のために*追い出され* たり、ノードが故障するまでノード上に残り続けます。 {{< note >}} 単一のPod内でのコンテナを再起動することと、そのPodを再起動することを混同しないでください。Podはそれ自体は実行されませんが、コンテナが実行される環境であり、削除されるまで存在し続けます。 @@ -111,7 +111,7 @@ spec: ## {{% heading "whatsnext" %}} -* [Pod](/ja/docs/concepts/workloads/pods/pod/)について更に学びましょう +* [Pod](/ja/docs/concepts/workloads/pods/pod/)についてさらに学びましょう * Podの振る舞いに関して学ぶには下記を参照してください * [Podの停止](/ja/docs/concepts/workloads/pods/pod/#termination-of-pods) * [Podのライフサイクル](/ja/docs/concepts/workloads/pods/pod-lifecycle/) diff --git a/content/ja/docs/concepts/workloads/pods/pod.md b/content/ja/docs/concepts/workloads/pods/pod.md index e46e5cad9e..fbb003c21b 100644 --- a/content/ja/docs/concepts/workloads/pods/pod.md +++ b/content/ja/docs/concepts/workloads/pods/pod.md @@ -16,7 +16,7 @@ _Pod_ は、Kubernetesで作成および管理できる、デプロイ可能な ## Podとは -_Pod_ は（クジラの小群やエンドウ豆のさやのように）、共有のストレージ/ネットワークを持つ1つ以上のコンテナ（例えばDockerコンテナ）、およびコンテナを実行する方法についての仕様です。Pod内のコンテナ群は常に同じ場所に配置され、協調してスケジューリングされ、共通のコンテキストで実行されます。Podは、アプリケーション固有の「論理ホスト」――やや密に結合した1つ以上のアプリケーション・コンテナを含むもの――をモデル化します。コンテナ以前の世界では、同じ物理または仮想マシン上で実行されることが、同じ論理ホスト上で実行されることを意味するでしょう。 +_Pod_ は(クジラの小群やエンドウ豆のさやのように)、共有のストレージ/ネットワークを持つ1つ以上のコンテナ(例えばDockerコンテナ)、およびコンテナを実行する方法についての仕様です。Pod内のコンテナ群は常に同じ場所に配置され、協調してスケジューリングされ、共通のコンテキストで実行されます。Podは、アプリケーション固有の「論理ホスト」――やや密に結合した1つ以上のアプリケーション・コンテナを含むもの――をモデル化します。コンテナ以前の世界では、同じ物理または仮想マシン上で実行されることが、同じ論理ホスト上で実行されることを意味するでしょう。 Kubernetesは、Dockerだけでなくより多くのコンテナ・ランタイムをサポートしていますが、Dockerは最もよく知られているランタイムであり、Dockerの用語を使ってPodを説明することが可能です。 @@ -24,7 +24,7 @@ Pod内では、Linux namespaceやcgroupなどのDockerコンテナを分離す Podのコンテキスト内で、個々のアプリケーションに更なる分離が適用されることがあります。 Pod内のコンテナはIPアドレスとポートの空間を共有し、 `localhost` を通じてお互いを見つけることができます 。 -また、SystemVセマフォやPOSIX共有メモリなどの標準のプロセス間通信（IPC）を使用して互いに通信することもできます。 +また、SystemVセマフォやPOSIX共有メモリなどの標準のプロセス間通信(IPC)を使用して互いに通信することもできます。 異なるPodのコンテナは異なるIPアドレスを持ち、[特別な設定](/docs/concepts/policy/pod-security-policy/)がなければIPCでは通信できません。 これらのコンテナは通常、Pod IPアドレスを介して互いに通信します。 @@ -33,18 +33,18 @@ 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で実行されるようにスケジュールされます。 +個々のアプリケーションコンテナと同様に、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で定義)は新しいNodeに「再スケジュール」されません。 +代わりに、必要に応じて同じ名前で、新しいUIDを持つ同一のPodに置き換えることができます(詳細については[ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/)を参照してください)。 -ボリュームなど、Podと同じ存続期間を持つものがあると言われる場合、それは（そのUIDを持つ）Podが存在する限り存在することを意味します。 -そのPodが何らかの理由で削除された場合、たとえ同じ代替物が作成されたとしても、関連するもの（例えばボリューム）も同様に破壊されて再作成されます。 +ボリュームなど、Podと同じ存続期間を持つものがあると言われる場合、それは(そのUIDを持つ)Podが存在する限り存在することを意味します。 +そのPodが何らかの理由で削除された場合、たとえ同じ代替物が作成されたとしても、関連するもの(例えばボリューム)も同様に破壊されて再作成されます。 {{< figure src="/images/docs/pod.svg" title="Podの図" width="50%" >}} -*file puller（ファイル取得コンテナ）とWebサーバーを含むマルチコンテナのPod。コンテナ間の共有ストレージとして永続ボリュームを使用している。* +*file puller(ファイル取得コンテナ)とWebサーバーを含むマルチコンテナのPod。コンテナ間の共有ストレージとして永続ボリュームを使用している。* ## Podを用いる動機 @@ -53,13 +53,13 @@ Nodeが停止した場合、そのNodeにスケジュールされたPodは、タ Podは、まとまったサービスの単位を形成する複数の協調プロセスのパターンをモデル化したものです。 構成要素であるアプリケーションの集まりよりも高いレベルの抽象化を提供することによって、アプリケーションのデプロイと管理を単純化します。 Podは、デプロイや水平スケーリング、レプリケーションの単位として機能します。 -Pod内のコンテナに対しては、同じ場所への配置（共同スケジューリング）、命運の共有（つまり停止）、協調レプリケーション、リソース共有や依存関係の管理が自動的に取り扱われます。 +Pod内のコンテナに対しては、同じ場所への配置(共同スケジューリング)、命運の共有(つまり停止)、協調レプリケーション、リソース共有や依存関係の管理が自動的に取り扱われます。 ### リソース共有と通信 Podは、構成要素間でのデータ共有および通信を可能にします。 -Pod内のアプリケーションはすべて同じネットワーク名前空間（同じIPおよびポートスペース）を使用するため、 `localhost` としてお互いを「見つけて」通信できます。 +Pod内のアプリケーションはすべて同じネットワーク名前空間(同じIPおよびポートスペース)を使用するため、 `localhost` としてお互いを「見つけて」通信できます。 このため、Pod内のアプリケーションはそれぞれ使用するポートを調整する必要があります。 各Podは、他の物理コンピュータやPodと自由に通信するためのフラットな共有ネットワーク空間上にIPアドレスを持ちます。 @@ -71,7 +71,7 @@ Podで実行されるアプリケーションコンテナの定義に加えて ## Podの用途 -Podは、垂直に統合されたアプリケーションスタック（例：LAMP）をホストするために使用できます。 +Podは、垂直に統合されたアプリケーションスタック(例:LAMP)をホストするために使用できます。 しかし、Podを使う主な動機は、次のように同じ場所に配置され、共に管理されるヘルパープログラムをサポートすることです。 * コンテンツ管理システム(CMS)、ファイルやデータのローダー、ローカルのキャッシュマネージャーなど @@ -83,11 +83,11 @@ Podは、垂直に統合されたアプリケーションスタック（例：LA 個々のPodは、一般に、同じアプリケーションの複数のインスタンスを実行することを目的としていません。 詳細については、[The Distributed System ToolKit: Patterns for -Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)（分散システムツールキット：複合コンテナのパターン）を参照してください。 +Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)(分散システムツールキット：複合コンテナのパターン)を参照してください。 ## 考えられる代替案 -_単一の（Docker）コンテナで複数のプログラムを実行しないのはなぜですか？_ +_単一の(Docker)コンテナで複数のプログラムを実行しないのはなぜですか？_ 1. 透明性のため。Pod内のコンテナをインフラストラクチャから見えるようにすることで、インフラストラクチャはプロセス管理やリソース監視などのサービスをコンテナに提供できます。 これは、ユーザーに多くの便益を提供します。 @@ -97,13 +97,13 @@ Kubernetesはいつか個々のコンテナのライブアップデートをサ 1. 使いやすさのため。ユーザーは独自のプロセスマネージャーを実行する必要はありません。シグナルや終了コードの伝播などについて心配する必要はありません。 1. 効率のため。インフラストラクチャがより責任を負うため、コンテナはより軽量になります。 -_アフィニティ（結合性、親和性）ベースのコンテナの共同スケジューリングをサポートしないのはなぜですか？_ +_アフィニティ(結合性、親和性)ベースのコンテナの共同スケジューリングをサポートしないのはなぜですか？_ このアプローチによって、コンテナの共同配置は提供されるでしょう。 しかし、リソース共有やIPC、保証された命運の共有、および簡素化された管理といったPodの利点のほとんどは提供されないでしょう。 -## Podの耐久性（またはその欠如） +## Podの耐久性(またはその欠如) {#pod-durability} Podは、耐久性のある存在として扱われることを意図していません。 スケジューリングの失敗や、Nodeの故障には耐えられません。 @@ -128,7 +128,7 @@ Podは、以下のことを容易にするためにプリミティブとして ## Podの終了 {#termination-of-pods} -Podは、クラスター内のNodeで実行中のプロセスを表すため、不要になったときにそれらのプロセスを正常に終了できるようにすることが重要です（対照的なケースは、KILLシグナルで強制終了され、クリーンアップする機会がない場合）。 +Podは、クラスター内のNodeで実行中のプロセスを表すため、不要になったときにそれらのプロセスを正常に終了できるようにすることが重要です(対照的なケースは、KILLシグナルで強制終了され、クリーンアップする機会がない場合)。 ユーザーは削除を要求可能であるべきで、プロセスがいつ終了するかを知ることができなければなりませんが、削除が最終的に完了することも保証できるべきです。 ユーザーがPodの削除を要求すると、システムはPodが強制終了される前に意図された猶予期間を記録し、各コンテナのメインプロセスにTERMシグナルが送信されます。 猶予期間が終了すると、プロセスにKILLシグナルが送信され、PodはAPIサーバーから削除されます。 @@ -136,17 +136,17 @@ Podは、クラスター内のNodeで実行中のプロセスを表すため、 フローの例は下のようになります。 -1. ユーザーがデフォルトの猶予期間（30秒）でPodを削除するコマンドを送信する +1. ユーザーがデフォルトの猶予期間(30秒)でPodを削除するコマンドを送信する 1. APIサーバー内のPodは、猶予期間を越えるとPodが「死んでいる」と見なされるように更新される 1. クライアントのコマンドに表示されたとき、Podは「終了中」と表示される -1. （3と同時に）Kubeletは、2の期間が設定されたためにPodが終了中となったことを認識すると、Podのシャットダウン処理を開始する +1. (3と同時に)Kubeletは、2の期間が設定されたためにPodが終了中となったことを認識すると、Podのシャットダウン処理を開始する 1. Pod内のコンテナの1つが[preStopフック](/docs/concepts/containers/container-lifecycle-hooks/#hook-details)を定義している場合は、コンテナの内側で呼び出される。 - 猶予期間が終了した後も `preStop`フックがまだ実行されている場合は、一度だけ猶予期間を延長して（2秒）、ステップ2が呼び出される。`preStop`フックが完了するまでにより長い時間が必要な場合は、`terminationGracePeriodSeconds`を変更する必要がある。 + 猶予期間が終了した後も `preStop`フックがまだ実行されている場合は、一度だけ猶予期間を延長して(2秒)、ステップ2が呼び出される。`preStop`フックが完了するまでにより長い時間が必要な場合は、`terminationGracePeriodSeconds`を変更する必要がある。 1. コンテナにTERMシグナルが送信される。Pod内のすべてのコンテナが同時にTERMシグナルを受信するわけではなく、シャットダウンの順序が問題になる場合はそれぞれに `preStop` フックが必要になることがある -1. （3と同時に）Podはサービスを提供するエンドポイントのリストから削除され、ReplicationControllerの実行中のPodの一部とは見なされなくなる。 -ゆっくりとシャットダウンするPodは、（サービスプロキシのような）ロードバランサーがローテーションからそれらを削除するので、トラフィックを処理し続けることはできない +1. (3と同時に)Podはサービスを提供するエンドポイントのリストから削除され、ReplicationControllerの実行中のPodの一部とは見なされなくなる。 +ゆっくりとシャットダウンするPodは、(サービスプロキシのような)ロードバランサーがローテーションからそれらを削除するので、トラフィックを処理し続けることはできない 1. 猶予期間が終了すると、Pod内でまだ実行中のプロセスはSIGKILLで強制終了される -1. Kubeletは猶予期間を0（即時削除）に設定することでAPIサーバー上のPodの削除を終了する。 +1. Kubeletは猶予期間を0(即時削除)に設定することでAPIサーバー上のPodの削除を終了する。 PodはAPIから消え、クライアントからは見えなくなる デフォルトでは、すべての削除は30秒以内に正常に行われます。 @@ -186,5 +186,3 @@ spec.containers[0].securityContext.privileged: forbidden '<*>(0xc20b222db0)true' PodはKubernetes REST APIのトップレベルのリソースです。 APIオブジェクトの詳細については、[Pod APIオブジェクト](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)を参照してください 。 - - diff --git a/content/ja/docs/contribute/_index.md b/content/ja/docs/contribute/_index.md index 8491c85dc4..008b575e1a 100644 --- a/content/ja/docs/contribute/_index.md +++ b/content/ja/docs/contribute/_index.md @@ -32,7 +32,7 @@ Kubernetesのドキュメントは、GitHubのリポジトリーにあります ## 貢献するためのベストプラクティス - 明快で意味のあるGitコミットメッセージを書いてください。 -- PRがマージされたときにissueを参照し、自動的にissueをクローズする_Github Special Keywords_を必ず含めるようにしてください。 +- PRがマージされたときにissueを参照し、自動的にissueをクローズする _Github Special Keywords_ を必ず含めるようにしてください。 - タイプミスの修正や、スタイルの変更、文法の変更などのような小さな変更をPRに加える場合は、比較的小さな変更のためにコミットの数が増えすぎないように、コミットはまとめてください。 - あなたがコードを変更をした理由を示し、レビュアーがあなたのPRを理解するのに十分な情報を確保した適切なPR説明を、必ず含めるようにしてください。 - 追加文献 : diff --git a/content/ja/docs/home/_index.md b/content/ja/docs/home/_index.md index fda3c24817..7f8837ce60 100644 --- a/content/ja/docs/home/_index.md +++ b/content/ja/docs/home/_index.md @@ -18,7 +18,7 @@ menu: description: > Kubernetesは、コンテナ化されたアプリケーションの展開、スケーリング、また管理を自動化するためのオープンソースコンテナプラットフォームです。このオープンソースプロジェクトは、Cloud Native Computing Foundationによってホストされています。 overview: > - Kubernetesは、コンテナ化されたアプリケーションの展開、スケーリング、また管理を自動化するためのオープンソースコンテナプラットフォームです。このオープンソースプロジェクトは、Cloud Native Computing Foundationによってホストされています（CNCF）。 + Kubernetesは、コンテナ化されたアプリケーションの展開、スケーリング、また管理を自動化するためのオープンソースコンテナプラットフォームです。このオープンソースプロジェクトは、Cloud Native Computing Foundationによってホストされています(CNCF)。 cards: - name: concepts title: "基本を理解する" @@ -52,7 +52,7 @@ cards: button_path: /docs/reference - name: contribute title: "ドキュメントにコントリビュートする" - description: "プロジェクトに不慣れでも、長い間関わっていたとしても、誰でもコントリビュートすることが出来ます。" + description: "プロジェクトに不慣れでも、長い間関わっていたとしても、誰でもコントリビュートすることができます。" button: "ドキュメントにコントリビュートする" button_path: /docs/contribute - name: download diff --git a/content/ja/docs/home/supported-doc-versions.md b/content/ja/docs/home/supported-doc-versions.md index a4c9ac18ce..0ca6fcee64 100644 --- a/content/ja/docs/home/supported-doc-versions.md +++ b/content/ja/docs/home/supported-doc-versions.md @@ -9,7 +9,7 @@ card: -本ウェブサイトでは、現行版とその直前4バージョンのKubernetesドキュメントを含んでいます。 +本ウェブサイトには、現行版とその直前4バージョンのKubernetesドキュメントがあります。 @@ -17,8 +17,7 @@ card: ## 現行版 -現在のバージョンは -[{{< param "version" >}}](/). +現在のバージョンは[{{< param "version" >}}](/)です。 ## 以前のバージョン diff --git a/content/ja/docs/reference/access-authn-authz/authentication.md b/content/ja/docs/reference/access-authn-authz/authentication.md new file mode 100644 index 0000000000..297bcce9d0 --- /dev/null +++ b/content/ja/docs/reference/access-authn-authz/authentication.md @@ -0,0 +1,711 @@ +--- +title: 認証 +content_type: concept +weight: 10 +--- + + +このページでは、認証の概要について説明します。 + + + +## Kubernetesにおけるユーザー + +すべてのKubernetesクラスターには、2種類のユーザーがあります。Kubernetesによって管理されるサービスアカウントと、通常のユーザーです。 + +通常のユーザーは外部の独立したサービスが管理することを想定しています。秘密鍵を配布する管理者、KeystoneやGoogle Accountsのようなユーザーストア、さらにはユーザー名とパスワードのリストを持つファイルなどです。この点において、_Kubernetesは通常のユーザーアカウントを表すオブジェクトを持ちません。_ APIコールを介して、通常のユーザーをクラスターに追加することはできません。 + +対照的に、サービスアカウントはKubernetes APIによって管理されるユーザーです。サービスアカウントは特定の名前空間にバインドされており、APIサーバーによって自動的に作成されるか、APIコールによって手動で作成されます。サービスアカウントは、`Secrets`として保存された資格情報の集合に紐付けられています。これをPodにマウントすることで、クラスター内のプロセスがKubernetes APIと通信できるようにします。 + +APIリクエストは、通常のユーザーかサービスアカウントに紐付けられているか、[匿名リクエスト](#anonymous-requests)として扱われます。つまり、ワークステーションで`kubectl`を入力する人間のユーザーから、ノード上の`kubelets`やコントロールプレーンのメンバーまで、クラスター内外の全てのプロセスは、APIサーバーへのリクエストを行う際に認証を行うか匿名ユーザーとして扱われる必要があります。 + +## 認証戦略 + +Kubernetesは、クライアント証明書、Bearerトークン、認証プロキシー、HTTP Basic認証を使い、認証プラグインを通してAPIリクエストを認証します。APIサーバーにHTTPリクエストが送信されると、プラグインは以下の属性をリクエストに関連付けようとします。 + +* ユーザー名: エンドユーザーを識別する文字列です。一般的にな値は、`kube-admin`や`jane@example.com`です。 +* UID: エンドユーザーを識別する文字列であり、ユーザー名よりも一貫性と一意性を持たせようとするものです。 +* グループ: 各要素がユーザーの役割を示すような意味を持つ文字列の集合です。`system:masters`や`devops-team`といった値が一般的です。 +* 追加フィールド: 認証者が有用と思われる追加情報を保持する文字列のリストに対する、文字列のマップです。 + +すべての値は認証システムに対して非透過であり、[認可機能](/docs/reference/access-authn-authz/authorization/)が解釈した場合にのみ意味を持ちます。 + + +一度に複数の認証方法を有効にすることができます。通常は、以下のように少なくとも2つの方法を使用するべきです。 + + - サービスアカウント用のサービスアカウントトークン + - ユーザー認証のための、少なくとも1つの他の方法 + +複数の認証モジュールが有効化されている場合、リクエストの認証に成功した最初のモジュールが、評価が簡略化します。APIサーバーは、認証の実行順序を保証しません。 + +`system:authenticated`グループには、すべての認証済みユーザーのグループのリストが含まれます。 + +他の認証プロトコル(LDAP、SAML、Kerberos、X509スキームなど)との統合は、[認証プロキシー](#authenticating-proxy)や[認証Webhook](#webhook-token-authentication)を使用して実施できます。 + + +### X509クライアント証明書 + +クライアント証明書認証は、APIサーバーに`--client-ca-file=SOMEFILE`オプションを渡すことで有効になります。参照されるファイルには、APIサーバーに提示されたクライアント証明書を検証するために使用する1つ以上の認証局が含まれている必要があります。クライアント証明書が提示され、検証された場合、サブジェクトのCommon Nameがリクエストのユーザー名として使用されます。Kubernetes1.4時点では、クライアント証明書は、証明書のOrganizationフィールドを使用して、ユーザーのグループメンバーシップを示すこともできます。あるユーザーに対して複数のグループメンバーシップを含めるには、証明書に複数のOrganizationフィールドを含めます。 + +例えば、証明書署名要求を生成するために、`openssl`コマンドラインツールを使用します。 + +``` bash +openssl req -new -key jbeda.pem -out jbeda-csr.pem -subj "/CN=jbeda/O=app1/O=app2" +``` + +これにより、"app1"と"app2"の2つのグループに属するユーザー名"jbeda"の証明書署名要求が作成されます。 + +クライアント証明書の生成方法については、[証明書の管理](/docs/concepts/cluster-administration/certificates/)を参照してください。 + +### 静的なトークンファイル + +コマンドラインで`--token-auth-file=SOMEFILE`オプションを指定すると、APIサーバーはファイルからBearerトークンを読み込みます。現在のところ、トークンの有効期限は無く、APIサーバーを再起動しない限りトークンのリストを変更することはできません。 + +トークンファイルは、トークン、ユーザー名、ユーザーUIDの少なくとも3つの列を持つcsvファイルで、その後にオプションでグループ名が付きます。 + +{{< note >}} +複数のグループがある場合はダブルクォートで囲む必要があります。 + +```conf +token,user,uid,"group1,group2,group3" +``` +{{< /note >}} + +#### リクエストにBearerトークンを含める {#putting-a-bearer-token-in-a-request} + +HTTPクライアントからBearerトークン認証を利用する場合、APIサーバーは`Bearer THETOKEN`という値を持つ`Authorization`ヘッダーを待ち受けます。Bearerトークンは、HTTPのエンコーディングとクォート機能を利用してHTTPヘッダーの値に入れることができる文字列でなければなりません。例えば、Bearerトークンが`31ada4fd-adec-460c-809a-9e56ceb75269`であれば、HTTPのヘッダを以下のようにします。 + +```http +Authorization: Bearer 31ada4fd-adec-460c-809a-9e56ceb75269 +``` + +### ブートストラップトークン + +{{< feature-state for_k8s_version="v1.18" state="stable" >}} + +新しいクラスタの効率的なブートストラップを可能にするために、Kubernetesには*ブートストラップトークン*と呼ばれる動的に管理されたBearerトークンタイプが含まれています。これらのトークンは、`kube-system`名前空間にSecretsとして格納され、動的に管理したり作成したりすることができます。コントローラーマネージャーには、TokenCleanerコントローラーが含まれており、ブートストラップトークンの有効期限が切れると削除します。 + +トークンの形式は`[a-z0-9]{6}.[a-z0-9]{16}`です。最初のコンポーネントはトークンIDであり、第2のコンポーネントはToken Secretです。以下のように、トークンをHTTPヘッダーに指定します。 + +```http +Authorization: Bearer 781292.db7bc3a58fc5f07e +``` + +APIサーバーの`--enable-bootstrap-token-auth`フラグで、Bootstrap Token Authenticatorを有効にする必要があります。TokenCleanerコントローラーを有効にするには、コントローラーマネージャーの`--controllers`フラグを使います。`--controllers=*,tokencleaner`のようにして行います。クラスターをブートストラップするために`kubeadm`を使用している場合は、`kubeadm`がこれを代行してくれます。 + +認証機能は`system:bootstrap:`という名前で認証します。これは`system:bootstrappers`グループに含まれます。名前とグループは意図的に制限されており、ユーザーがブートストラップ後にこれらのトークンを使わないようにしています。ユーザー名とグループは、クラスタのブートストラップをサポートする適切な認可ポリシーを作成するために使用され、`kubeadm`によって使用されます。 + +ブートストラップトークンの認証機能やコントローラーについての詳細な説明、`kubeadm`でこれらのトークンを管理する方法については、[ブートストラップトークン](/docs/reference/access-authn-authz/bootstrap-tokens/)を参照してください。 + +### 静的なパスワードファイル + +APIサーバーに`--basic-auth-file=SOMEFILE`オプションを渡すことで、Basic認証を有効にすることができます。現在のところ、Basic認証の認証情報は有効期限が無く、APIサーバーを再起動しない限りパスワードを変更することはできません。よりセキュアなモードをさらに使いやすくするための改良が完了するまでの間、現時点では利便性のためにBasic認証がサポートされていることに注意してください。 + +Basic認証ファイルは、トークン、ユーザー名、ユーザーIDの少なくとも3つの列を持つcsvファイルです。 +Kubernetesのバージョン1.6以降では、オプションとしてカンマ区切りのグループ名を含む4列目を指定することができます。複数のグループがある場合は、4列目の値をダブルクォート(")で囲む必要があります。以下の例を参照してください。 + +```conf +password,user,uid,"group1,group2,group3" +``` + +HTTPクライアントからBasic認証を利用する場合、APIサーバーは`Basic BASE64ENCODED(USER:PASSWORD)`の値を持つ`Authorization`ヘッダーを待ち受けます。 + +### サービスアカウントトークン + +サービスアカウントは、自動的に有効化される認証機能で、署名されたBearerトークンを使ってリクエストを検証します。このプラグインは、オプションとして2つのフラグを取ります。 + +* `--service-account-key-file`: Bearerトークンに署名するためのPEMエンコードされた鍵を含むファイルです。指定しない場合は、APIサーバーのTLS秘密鍵が使われます。 +* `--service-account-lookup`: 有効にすると、APIから削除されたトークンは取り消されます。 + +サービスアカウントは通常、APIサーバーによって自動的に作成され、`ServiceAccount`[Admission Controller](/docs/reference/access-authn-authz/admission-controllers/)を介してクラスター内のPodに関連付けられます。Bearerトークンは、Podのよく知られた場所にマウントされ、これによりクラスター内のプロセスがAPIサーバー通信できるようになります。アカウントは`PodSpec`の`serviceAccountName`フィールドを使って、明示的にPodに関連付けることができます。 + +{{< note >}} +自動で行われるため、通常`serviceAccountName`は省略します。 +{{< /note >}} + +```yaml +apiVersion: apps/v1 # このapiVersionは、Kubernetes1.9時点で適切です +kind: Deployment +metadata: + name: nginx-deployment + namespace: default +spec: + replicas: 3 + template: + metadata: + # ... + spec: + serviceAccountName: bob-the-bot + containers: + - name: nginx + image: nginx:1.14.2 +``` + +サービスアカウントのBearerトークンは、クラスター外で使用するために完全に有効であり、Kubernetes APIと通信したい長期的なジョブのアイデンティティを作成するために使用することができます。サービスアカウントを手動で作成するには、単に`kubectl create serviceaccount (NAME)`コマンドを使用します。これにより、現在の名前空間にサービスアカウントと関連するSecretが作成されます。 + + +```bash +kubectl create serviceaccount jenkins +``` + +```none +serviceaccount "jenkins" created +``` + +以下のように、関連するSecretを確認できます。 + +```bash +kubectl get serviceaccounts jenkins -o yaml +``` + +```yaml +apiVersion: v1 +kind: ServiceAccount +metadata: + # ... +secrets: +- name: jenkins-token-1yvwg +``` + +作成されたSecretは、APIサーバーのパブリック認証局と署名されたJSON Web Token(JWT)を保持します。 + +```bash +kubectl get secret jenkins-token-1yvwg -o yaml +``` + +```yaml +apiVersion: v1 +data: + ca.crt: (base64でエンコードされたAPIサーバーの認証局) + namespace: ZGVmYXVsdA== + token: (base64でエンコードされたBearerトークン) +kind: Secret +metadata: + # ... +type: kubernetes.io/service-account-token +``` + +{{< note >}} +Secretは常にbase64でエンコードされるため、これらの値もbase64でエンコードされています。 +{{< /note >}} + +署名されたJWTは、与えられたサービスアカウントとして認証するためのBearerトークンとして使用できます。トークンをリクエストに含める方法については、[リクエストにBearerトークンを含める](#putting-a-bearer-token-in-a-request)を参照してください。通常、これらのSecretはAPIサーバーへのクラスタ内アクセス用にPodにマウントされますが、クラスター外からも使用することができます。 + +サービスアカウントは、ユーザー名`system:serviceaccount:(NAMESPACE):(SERVICEACCOUNT)`で認証され、グループ`system:serviceaccounts`と`system:serviceaccounts:(NAMESPACE)`に割り当てられます。 + +警告: サービスアカウントトークンはSecretに保持されているため、Secretにアクセスできるユーザーは誰でもサービスアカウントとして認証することができます。サービスアカウントに権限を付与したり、Secretの読み取り機能を付与したりする際には注意が必要です。 + +### OpenID Connectトークン +[OpenID Connect](https://openid.net/connect/)は、Azure Active Directory、Salesforce、Googleなど、いくつかのOAuth2プロバイダーでサポートされているOAuth2の一種です。 +このプロトコルのOAuth2の主な拡張機能は、[ID Token](https://openid.net/specs/openid-connect-core-1_0.html#IDToken)と呼ばれる、アクセストークンとアクセストークンと一緒に返される追加フィールドです。 +このトークンは、ユーザーの電子メールなどのよく知られたフィールドを持つJSON Web Token(JWT)であり、サーバーによって署名されています。トークンをリクエストに含める方法については、[リクエストにBearerトークンを含める](#putting-a-bearer-token-in-a-request)を参照してください。 + +![Kubernetes OpenID Connect Flow](/images/docs/admin/k8s_oidc_login.svg) + +1. IDプロバイダーにログインします +2. IDプロバイダーは、`access_token`、`id_token`、`refresh_token`を提供します +3. `kubectl`を使う場合は、`--token`フラグで`id_token`を使うか、`kubeconfig`に直接追加してください +4. `kubectl`は、`id_token`をAuthorizationと呼ばれるヘッダーでAPIサーバーに送ります +5. APIサーバーは、設定で指定された証明書と照合することで、JWT署名が有効であることを確認します +6. `id_token`の有効期限が切れていないことを確認します +7. ユーザーが認可されていることを確認します +8. 認可されると、APIサーバーは`kubectl`にレスポンスを返します +9. `kubectl`はユーザーにフィードバックを提供します + +自分が誰であるかを確認するために必要なデータはすべて`id_token`の中にあるので、KubernetesはIDプロバイダーと通信する必要がありません。すべてのリクエストがステートレスであるモデルでは、これは非常に認証のためのスケーラブルなソリューションを提供します。一方で、以下のようにいくつか課題があります。 + +1. Kubernetesには、認証プロセスを起動するための"Webインターフェース"がありません。クレデンシャルを収集するためのブラウザやインターフェースがないため、まずIDプロバイダに認証を行う必要があります。 +2. `id_token`は、取り消すことができません。これは証明書のようなもので、有効期限が短い(数分のみ)必要があるので、数分ごとに新しいトークンを取得しなければならないのは非常に面倒です。 +3. Kubernetesダッシュボードへの認証において、`kubectl proxy`コマンドや`id_token`を注入するリバースプロキシーを使う以外に、簡単な方法はありません。 + + +#### APIサーバーの設定 + +プラグインを有効にするには、APIサーバーで以下のフラグを設定します。 + +| パラメーター | 説明 | 例 | 必須か | +| --------- | ----------- | ------- | ------- | +| `--oidc-issuer-url` | APIサーバーが公開署名鍵を発見できるようにするプロバイダーのURLです。 `https://`スキームを使用するURLのみが受け入れられます。これは通常、"https://accounts.google.com"や"https://login.salesforce.com"のようにパスを持たないプロバイダのディスカバリーURLです。このURLは、`.well-known/openid-configuration`の下のレベルを指す必要があります。 | ディスカバリーURLが`https://accounts.google.com/.well-known/openid-configuration`である場合、値は`https://accounts.google.com`とします。 | はい | +| `--oidc-client-id` | すべてのトークンが発行されなければならないクライアントIDです。 | kubernetes | はい | +| `--oidc-username-claim` | ユーザー名として使用するJWTのクレームを指定します。デフォルトでは`sub`が使用されますが、これはエンドユーザーの一意の識別子であることが期待されます。管理者はプロバイダーに応じて`email`や`name`などの他のクレームを選択することができます。ただし、他のプラグインとの名前の衝突を防ぐために、`email`以外のクレームには、プレフィックスとして発行者のURLが付けられます。 | sub | いいえ | +| `--oidc-username-prefix` | 既存の名前(`system:`ユーザーなど)との衝突を防ぐために、ユーザー名の前にプレフィックスを付加します。例えば`oidc:`という値は、`oidc:jane.doe`のようなユーザー名を生成します。このフラグが指定されておらず、`--oidc-username-claim`が`email`以外の値である場合、プレフィックスのデフォルトは`(Issuer URL)#`で、`(Issuer URL)`は`--oidc-issuer-url`の値です。すべてのプレフィックスを無効にするためには、`-`という値を使用できます。 | `oidc:` | いいえ | +| `--oidc-groups-claim` | ユーザーのグループとして使用するJWTのクレームです。クレームがある場合は、文字列の配列である必要があります。 | groups | いいえ | +| `--oidc-groups-prefix` | 既存の名前(`system:`グループなど)との衝突を防ぐために、グループ名の前にプレフィックスを付加します。例えば`oidc:`という値は、`oidc:engineering`や`oidc:infra`のようなグループ名を生成します。 | `oidc:` | いいえ | +| `--oidc-required-claim` | IDトークンの中の必須クレームを記述するkey=valueのペアです。設定されている場合、クレームが一致する値でIDトークンに存在することが検証されます。このフラグを繰り返して複数のクレームを指定します。 | `claim=value` | いいえ | +| `--oidc-ca-file` | IDプロバイダーのWeb証明書に署名した認証局の証明書へのパスです。デフォルトはホストのルート認証局が指定されます。 | `/etc/kubernetes/ssl/kc-ca.pem` | いいえ | + +重要なのは、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プロバイダーを実行することもできます。 + +IDプロバイダーがKubernetesと連携するためには、以下のことが必要です。 + +1. すべてではないが、[OpenID Connect Discovery](https://openid.net/specs/openid-connect-discovery-1_0.html）をサポートしていること +2. 廃れていない暗号を用いたTLSで実行されていること +3. 認証局が署名した証明書を持っていること(認証局が商用ではない場合や、自己署名の場合も可) + +上述の要件#3、認証局署名付き証明書を必要とすることについて、注意事項があります。GoogleやMicrosoftなどのクラウドプロバイダーではなく、独自のIDプロバイダーをデプロイする場合は、たとえ自己署名されていても、`CA`フラグが`TRUE`に設定されている証明書によって署名されたIDプロバイダーのWebサーバー証明書を持っていなければなりません。これは、Go言語のTLSクライアント実装が、証明書検証に関する標準に対して非常に厳格であるためです。認証局をお持ちでない場合は、CoreOSチームの[このスクリプト](https://github.com/coreos/dex/blob/1ee5920c54f5926d6468d2607c728b71cfe98092/examples/k8s/gencert.sh)を使用して、シンプルな認証局と署名付きの証明書と鍵のペアを作成することができます。 +または、[この類似のスクリプト](https://raw.githubusercontent.com/TremoloSecurity/openunison-qs-kubernetes/master/src/main/bash/makessl.sh)を使って、より寿命が長く、よりキーサイズの大きいSHA256証明書を生成できます。 + +特定のシステム用のセットアップ手順は、以下を参照してください。 + +- [UAA](https://docs.cloudfoundry.org/concepts/architecture/uaa.html) +- [Dex](https://github.com/dexidp/dex/blob/master/Documentation/kubernetes.md) +- [OpenUnison](https://www.tremolosecurity.com/orchestra-k8s/) + +#### kubectlの使用 + +##### 選択肢1 - OIDC認証機能 + +最初の選択肢は、kubectlの`oidc`認証機能を利用することです。これはすべてのリクエストのBearerトークンとして`id_token`を設定し、有効期限が切れるとトークンを更新します。プロバイダーにログインした後、kubectlを使って`id_token`、`refresh_token`、`client_id`、`client_secret`を追加してプラグインを設定します。 + +リフレッシュトークンのレスポンスの一部として`id_token`を返さないプロバイダーは、このプラグインではサポートされていないので、以下の"選択肢2"を使用してください。 + +```bash +kubectl config set-credentials USER_NAME \ + --auth-provider=oidc \ + --auth-provider-arg=idp-issuer-url=( issuer url ) \ + --auth-provider-arg=client-id=( your client id ) \ + --auth-provider-arg=client-secret=( your client secret ) \ + --auth-provider-arg=refresh-token=( your refresh token ) \ + --auth-provider-arg=idp-certificate-authority=( path to your ca certificate ) \ + --auth-provider-arg=id-token=( your id_token ) +``` + +例として、IDプロバイダーに認証した後に以下のコマンドを実行します。 + +```bash +kubectl config set-credentials mmosley \ + --auth-provider=oidc \ + --auth-provider-arg=idp-issuer-url=https://oidcidp.tremolo.lan:8443/auth/idp/OidcIdP \ + --auth-provider-arg=client-id=kubernetes \ + --auth-provider-arg=client-secret=1db158f6-177d-4d9c-8a8b-d36869918ec5 \ + --auth-provider-arg=refresh-token=q1bKLFOyUiosTfawzA93TzZIDzH2TNa2SMm0zEiPKTUwME6BkEo6Sql5yUWVBSWpKUGphaWpxSVAfekBOZbBhaEW+VlFUeVRGcluyVF5JT4+haZmPsluFoFu5XkpXk5BXqHega4GAXlF+ma+vmYpFcHe5eZR+slBFpZKtQA= \ + --auth-provider-arg=idp-certificate-authority=/root/ca.pem \ + --auth-provider-arg=id-token=eyJraWQiOiJDTj1vaWRjaWRwLnRyZW1vbG8ubGFuLCBPVT1EZW1vLCBPPVRybWVvbG8gU2VjdXJpdHksIEw9QXJsaW5ndG9uLCBTVD1WaXJnaW5pYSwgQz1VUy1DTj1rdWJlLWNhLTEyMDIxNDc5MjEwMzYwNzMyMTUyIiwiYWxnIjoiUlMyNTYifQ.eyJpc3MiOiJodHRwczovL29pZGNpZHAudHJlbW9sby5sYW46ODQ0My9hdXRoL2lkcC9PaWRjSWRQIiwiYXVkIjoia3ViZXJuZXRlcyIsImV4cCI6MTQ4MzU0OTUxMSwianRpIjoiMm96US15TXdFcHV4WDlHZUhQdy1hZyIsImlhdCI6MTQ4MzU0OTQ1MSwibmJmIjoxNDgzNTQ5MzMxLCJzdWIiOiI0YWViMzdiYS1iNjQ1LTQ4ZmQtYWIzMC0xYTAxZWU0MWUyMTgifQ.w6p4J_6qQ1HzTG9nrEOrubxIMb9K5hzcMPxc9IxPx2K4xO9l-oFiUw93daH3m5pluP6K7eOE6txBuRVfEcpJSwlelsOsW8gb8VJcnzMS9EnZpeA0tW_p-mnkFc3VcfyXuhe5R3G7aa5d8uHv70yJ9Y3-UhjiN9EhpMdfPAoEB9fYKKkJRzF7utTTIPGrSaSU6d2pcpfYKaxIwePzEkT4DfcQthoZdy9ucNvvLoi1DIC-UocFD8HLs8LYKEqSxQvOcvnThbObJ9af71EwmuE21fO5KzMW20KtAeget1gnldOosPtz1G5EwvaQ401-RPQzPGMVBld0_zMCAwZttJ4knw +``` + +これは以下のような構成になります。 + +```yaml +users: +- name: mmosley + user: + auth-provider: + config: + client-id: kubernetes + client-secret: 1db158f6-177d-4d9c-8a8b-d36869918ec5 + id-token: eyJraWQiOiJDTj1vaWRjaWRwLnRyZW1vbG8ubGFuLCBPVT1EZW1vLCBPPVRybWVvbG8gU2VjdXJpdHksIEw9QXJsaW5ndG9uLCBTVD1WaXJnaW5pYSwgQz1VUy1DTj1rdWJlLWNhLTEyMDIxNDc5MjEwMzYwNzMyMTUyIiwiYWxnIjoiUlMyNTYifQ.eyJpc3MiOiJodHRwczovL29pZGNpZHAudHJlbW9sby5sYW46ODQ0My9hdXRoL2lkcC9PaWRjSWRQIiwiYXVkIjoia3ViZXJuZXRlcyIsImV4cCI6MTQ4MzU0OTUxMSwianRpIjoiMm96US15TXdFcHV4WDlHZUhQdy1hZyIsImlhdCI6MTQ4MzU0OTQ1MSwibmJmIjoxNDgzNTQ5MzMxLCJzdWIiOiI0YWViMzdiYS1iNjQ1LTQ4ZmQtYWIzMC0xYTAxZWU0MWUyMTgifQ.w6p4J_6qQ1HzTG9nrEOrubxIMb9K5hzcMPxc9IxPx2K4xO9l-oFiUw93daH3m5pluP6K7eOE6txBuRVfEcpJSwlelsOsW8gb8VJcnzMS9EnZpeA0tW_p-mnkFc3VcfyXuhe5R3G7aa5d8uHv70yJ9Y3-UhjiN9EhpMdfPAoEB9fYKKkJRzF7utTTIPGrSaSU6d2pcpfYKaxIwePzEkT4DfcQthoZdy9ucNvvLoi1DIC-UocFD8HLs8LYKEqSxQvOcvnThbObJ9af71EwmuE21fO5KzMW20KtAeget1gnldOosPtz1G5EwvaQ401-RPQzPGMVBld0_zMCAwZttJ4knw + idp-certificate-authority: /root/ca.pem + idp-issuer-url: https://oidcidp.tremolo.lan:8443/auth/idp/OidcIdP + refresh-token: q1bKLFOyUiosTfawzA93TzZIDzH2TNa2SMm0zEiPKTUwME6BkEo6Sql5yUWVBSWpKUGphaWpxSVAfekBOZbBhaEW+VlFUeVRGcluyVF5JT4+haZmPsluFoFu5XkpXk5BXq + name: oidc +``` +`id_token`の有効期限が切れると、`kubectl`は`refresh_token`と`client_secret`を用いて`id_token`の更新しようとします。`refresh_token`と`id_token`の新しい値は、`.kube/config`に格納されます。 + +##### 選択肢2 - `--token`オプションの使用 + +`kubectl`コマンドでは、`--token`オプションを使ってトークンを渡すことができる。以下のように、このオプションに`id_token`をコピーして貼り付けるだけです。 + +```bash +kubectl --token=eyJhbGciOiJSUzI1NiJ9.eyJpc3MiOiJodHRwczovL21sYi50cmVtb2xvLmxhbjo4MDQzL2F1dGgvaWRwL29pZGMiLCJhdWQiOiJrdWJlcm5ldGVzIiwiZXhwIjoxNDc0NTk2NjY5LCJqdGkiOiI2RDUzNXoxUEpFNjJOR3QxaWVyYm9RIiwiaWF0IjoxNDc0NTk2MzY5LCJuYmYiOjE0NzQ1OTYyNDksInN1YiI6Im13aW5kdSIsInVzZXJfcm9sZSI6WyJ1c2VycyIsIm5ldy1uYW1lc3BhY2Utdmlld2VyIl0sImVtYWlsIjoibXdpbmR1QG5vbW9yZWplZGkuY29tIn0.f2As579n9VNoaKzoF-dOQGmXkFKf1FMyNV0-va_B63jn-_n9LGSCca_6IVMP8pO-Zb4KvRqGyTP0r3HkHxYy5c81AnIh8ijarruczl-TK_yF5akjSTHFZD-0gRzlevBDiH8Q79NAr-ky0P4iIXS8lY9Vnjch5MF74Zx0c3alKJHJUnnpjIACByfF2SCaYzbWFMUNat-K1PaUk5-ujMBG7yYnr95xD-63n8CO8teGUAAEMx6zRjzfhnhbzX-ajwZLGwGUBT4WqjMs70-6a7_8gZmLZb2az1cZynkFRj2BaCkVT3A2RrjeEwZEtGXlMqKJ1_I2ulrOVsYx01_yD35-rw get nodes +``` + + +### Webhookトークン認証 {#webhook-token-authentication} + +Webhook認証は、Bearerトークンを検証するためのフックです。 + +* `--authentication-token-webhook-config-file`: リモートのWebhookサービスへのアクセス方法を記述した設定ファイルです +* `--authentication-token-webhook-cache-ttl`: 認証をキャッシュする時間を決定します。デフォルトは2分です + +設定ファイルは、[kubeconfig](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)のファイル形式を使用します。 +ファイル内で、`clusters`はリモートサービスを、`users`はAPIサーバーのWebhookを指します。例えば、以下のようになります。 + +```yaml +# Kubernetes APIのバージョン +apiVersion: v1 +# APIオブジェクトの種類 +kind: Config +# clustersは、リモートサービスを指します。 +clusters: + - name: name-of-remote-authn-service + cluster: + certificate-authority: /path/to/ca.pem # リモートサービスを検証するためのCA + server: https://authn.example.com/authenticate # クエリするリモートサービスのURL。'https'を使用する必要があります。 + +# usersは、APIサーバーのWebhook設定を指します。 +users: + - name: name-of-api-server + user: + client-certificate: /path/to/cert.pem # Webhookプラグインを使うための証明書 + client-key: /path/to/key.pem # 証明書に合致する鍵 + +# kubeconfigファイルにはコンテキストが必要です。APIサーバー用のものを用意してください。 +current-context: webhook +contexts: +- context: + cluster: name-of-remote-authn-service + user: name-of-api-sever + name: webhook +``` + +クライアントが[上記](#putting-a-bearer-token-in-a-request)のようにBearerトークンを使用してAPIサーバーとの認証を試みた場合、認証Webhookはトークンを含むJSONでシリアライズされた`authentication.k8s.io/v1beta1` `TokenReview`オブジェクトをリモートサービスにPOSTします。Kubernetesはそのようなヘッダーが不足しているリクエストを作成しようとはしません。 + +Webhook APIオブジェクトは、他のKubernetes APIオブジェクトと同じように、[Versioning Compatibility Rule](/docs/concepts/overview/kubernetes-api/)に従うことに注意してください。実装者は、ベータオブジェクトで保証される互換性が緩いことに注意し、正しいデシリアライゼーションが使用されるようにリクエストの"apiVersion"フィールドを確認する必要があります。さらにAPIサーバーは、API拡張グループ`authentication.k8s.io/v1beta1`を有効にしなければなりません(`--runtime config=authentication.k8s.io/v1beta1=true`)。 + +POSTボディは、以下の形式になります。 + +```json +{ + "apiVersion": "authentication.k8s.io/v1beta1", + "kind": "TokenReview", + "spec": { + "token": "(Bearerトークン)" + } +} +``` + +リモートサービスはログインの成功を示すために、リクエストの`status`フィールドを埋めることが期待されます。レスポンスボディの`spec`フィールドは無視され、省略することができます。Bearerトークンの検証に成功すると、以下のようにBearerトークンが返されます。 + +```json +{ + "apiVersion": "authentication.k8s.io/v1beta1", + "kind": "TokenReview", + "status": { + "authenticated": true, + "user": { + "username": "janedoe@example.com", + "uid": "42", + "groups": [ + "developers", + "qa" + ], + "extra": { + "extrafield1": [ + "extravalue1", + "extravalue2" + ] + } + } + } +} +``` + +リクエストに失敗した場合は、以下のように返されます。 + +```json +{ + "apiVersion": "authentication.k8s.io/v1beta1", + "kind": "TokenReview", + "status": { + "authenticated": false + } +} +``` + +HTTPステータスコードは、追加のエラーコンテキストを提供するために使うことができます。 + + +### 認証プロキシー {#authenticating-proxy} + +APIサーバーは、`X-Remote-User`のようにリクエストヘッダの値からユーザーを識別するように設定することができます。 +これは、リクエストヘッダの値を設定する認証プロキシーと組み合わせて使用するために設計です。 + +* `--requestheader-username-headers`: 必須であり、大文字小文字を区別しません。ユーザーのIDをチェックするためのヘッダー名を順番に指定します。値を含む最初のヘッダーが、ユーザー名として使われます。 +* `--requestheader-group-headers`: バージョン1.6以降で任意であり、大文字小文字を区別しません。"X-Remote-Group"を推奨します。ユーザーのグループをチェックするためのヘッダー名を順番に指定します。指定されたヘッダーの全ての値が、グループ名として使われます。 +* `--requestheader-extra-headers-prefix` バージョン1.6以降で任意であり、大文字小文字を区別しません。"X-Remote-Extra-"を推奨します。ユーザーに関する追加情報を判断するために検索するヘッダーのプレフィックスです。通常、設定された認可プラグインによって使用されます。指定されたプレフィックスのいずれかで始まるヘッダーは、プレフィックスが削除されます。ヘッダー名の残りの部分は小文字化され[パーセントデコーディング](https://tools.ietf.org/html/rfc3986#section-2.1)されて追加のキーとなり、ヘッダーの値が追加の値となります。 + +{{< note >}} +1.11.3(および1.10.7、1.9.11)よりも前のバージョンでは、追加のキーには[HTTPヘッダーラベルで使用可能な文字](https://tools.ietf.org/html/rfc7230#section-3.2.6)のみを含めることができました。 +{{< /note >}} + +例えば、このような設定を行います。 + +``` +--requestheader-username-headers=X-Remote-User +--requestheader-group-headers=X-Remote-Group +--requestheader-extra-headers-prefix=X-Remote-Extra- +``` + +以下のようなリクエストを考えます。 + +```http +GET / HTTP/1.1 +X-Remote-User: fido +X-Remote-Group: dogs +X-Remote-Group: dachshunds +X-Remote-Extra-Acme.com%2Fproject: some-project +X-Remote-Extra-Scopes: openid +X-Remote-Extra-Scopes: profile +``` + +このリクエストは、このユーザー情報を取得します。 + +```yaml +name: fido +groups: +- dogs +- dachshunds +extra: + acme.com/project: + - some-project + scopes: + - openid + - profile +``` + +ヘッダーのスプーフィングを防ぐため、認証プロキシーはリクエストヘッダーがチェックされる前に、指定された認証局に対する検証のために有効なクライアント証明書をAPIサーバーへ提示する必要があります。 + + +* `--requestheader-client-ca-file`: 必須です。PEMエンコードされた証明書バンドルです。有効なクライアント証明書を提示し、リクエストヘッダーでユーザー名がチェックされる前に、指定されたファイル内の認証局に対して検証する必要があります。 +* `--requestheader-allowed-names`: 任意です。Common Name(CN)の値のリストです。設定されている場合、リクエストヘッダーでユーザー名がチェックされる前に、指定されたリストのCNを持つ有効なクライアント証明書を提示する必要があります。空の場合は、任意のCNが許可されます。 + + +## 匿名リクエスト {#anonymous-requests} + +この機能を有効にすると、他の設定された認証方法で拒否されなかったリクエストは匿名リクエストとして扱われ、 `system:anonymous`というユーザー名と`system:unauthenticated`というグループが与えられます。 + +例えば、トークン認証が設定されており、匿名アクセスが有効になっているサーバー上で、無効なBearerトークンを提供するリクエストは`401 Unauthorized`エラーを受け取ります。Bearerトークンを提供しないリクエストは匿名リクエストとして扱われます。 + +バージョン1.5.1から1.5.xでは、匿名アクセスはデフォルトでは無効になっており、APIサーバーに `--anonymous-auth=true`オプションを渡すことで有効にすることができます。 + +バージョン1.6以降では、`AlwaysAllow`以外の認証モードが使用されている場合、匿名アクセスがデフォルトで有効であり、`--anonymous-auth=false`オプションをAPIサーバーに渡すことで無効にできます。 +1.6以降、ABACおよびRBAC認可機能は、`system:anonymous`ユーザーまたは`system:unauthenticated`グループの明示的な認証を必要とするようになったため、`*`ユーザーまたは`*`グループへのアクセスを許可する従来のポリシールールには匿名ユーザーは含まれません。 + +## ユーザーの偽装 + +ユーザーは偽装ヘッダーを使って別のユーザーとして振る舞うことができます。これにより、リクエストが認証したユーザー情報を手動で上書きすることが可能です。例えば、管理者はこの機能を使って一時的に別のユーザーに偽装、リクエストが拒否されたかどうかを確認することで認可ポリシーをデバッグすることができます。 + +偽装リクエストは最初にリクエスト中のユーザーとして認証を行い、次に偽装ユーザー情報に切り替えます。 + +* ユーザーは、認証情報と偽装ヘッダーを使ってAPIコールを行います。 +* APIサーバーはユーザーを認証します。 +* APIサーバーは、認証されたユーザーが偽装した権限を持っていることを確認します。 +* リクエストされたユーザー情報は、偽装した値に置き換えられます。 +* リクエストが評価され、認可は偽装されたユーザー情報に基づいて実行されます。 + +偽装リクエストを実行する際には、以下のHTTPヘッダを使用することができます。 + +* `Impersonate-User`: ユーザー名を指定します。このユーザーとして振る舞います。 +* `Impersonate-Group`: グループ名を指定します。このグループとして振る舞います。複数回指定して複数のグループを設定することができます。任意であり、"Impersonate-User"が必要です。 +* `Impersonate-Extra-( extra name )`: 追加フィールドをユーザーに関連付けるために使用される動的なヘッダーです。任意であり、"Impersonate-User"が必要です。一貫して保存されるためには、`( extra name )`は小文字である必要があり、[HTTPヘッダーラベルで使用可能な文字](https://tools.ietf.org/html/rfc7230#section-3.2.6)以外の文字は、UTF-8であり、[パーセントエンコーディング](https://tools.ietf.org/html/rfc3986#section-2.1)されている必要があります. + +{{< note >}} +1.11.3(および1.10.7、1.9.11)よりも前のバージョンでは、`( extra name )`には[HTTPヘッダーラベルで使用可能な文字](https://tools.ietf.org/html/rfc7230#section-3.2.6)のみを含めることができました。 +{{< /note >}} + +以下が、ヘッダーの例です。 + +```http +Impersonate-User: jane.doe@example.com +Impersonate-Group: developers +Impersonate-Group: admins +Impersonate-Extra-dn: cn=jane,ou=engineers,dc=example,dc=com +Impersonate-Extra-acme.com%2Fproject: some-project +Impersonate-Extra-scopes: view +Impersonate-Extra-scopes: development +``` + +`kubectl`を使う場合は、`--as`フラグに`Impersonate-User`ヘッダーを、`--as-group`フラグに`Impersonate-Group`ヘッダーを設定します。 + + +```bash +kubectl drain mynode +``` + +```none +Error from server (Forbidden): User "clark" cannot get nodes at the cluster scope. (get nodes mynode) +``` + +`--as`フラグと`--as-group`フラグを設定します。 + +```bash +kubectl drain mynode --as=superman --as-group=system:masters +``` + +```none +node/mynode cordoned +node/mynode drained +``` + +ユーザー、グループ、または追加フィールドを偽装するために、偽装ユーザーは偽装される属性の種類("user"、"group"など)に対して、"偽装した"操作を行う能力を持っている必要があります。RBAC認可プラグインが有効なクラスターの場合、以下のClusterRoleは、ユーザーとグループの偽装ヘッダーを設定するために必要なルールを網羅しています。 + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + name: impersonator +rules: +- apiGroups: [""] + resources: ["users", "groups", "serviceaccounts"] + verbs: ["impersonate"] +``` + +追加フィールドは、"userextras"リソースのサブリソースとして評価されます。ユーザーが追加フィールド"scopes"に偽装ヘッダーを使用できるようにするには、ユーザーに以下のようなロールを付与する必要があります。 + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + name: scopes-impersonator +rules: +# "Impersonate-Extra-scopes"ヘッダーを設定できます。 +- apiGroups: ["authentication.k8s.io"] + resources: ["userextras/scopes"] + verbs: ["impersonate"] +``` + +偽装ヘッダーの値は、リソースが取り得る`resourceNames`の集合を制限することで、管理することもできます。 + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + name: limited-impersonator +rules: +# "jane.doe@example.com"というユーザーを偽装できます。 +- apiGroups: [""] + resources: ["users"] + verbs: ["impersonate"] + resourceNames: ["jane.doe@example.com"] + +# "developers"と"admins"というグループを偽装できます。 +- apiGroups: [""] + resources: ["groups"] + verbs: ["impersonate"] + resourceNames: ["developers","admins"] + +# "view"と"development"を値に持つ"scopes"という追加フィールドを偽装できます。 +- apiGroups: ["authentication.k8s.io"] + resources: ["userextras/scopes"] + verbs: ["impersonate"] + resourceNames: ["view", "development"] +``` + +## client-goクレデンシャルプラグイン + +{{< feature-state for_k8s_version="v1.11" state="beta" >}} + +`k8s.io/client-go`と、それを使用する`kubectl`や`kubelet`のようなツールは、外部コマンドを実行してユーザーの認証情報を受け取ることができます。 + +この機能は`k8s.io/client-go`がネイティブにサポートしていない認証プロトコル(LDAP、Kerberos、OAuth2、SAMLなど)とクライアントサイドで統合するためのものです。プラグインはプロトコル固有のロジックを実装し、使用する不透明なクレデンシャルを返します。ほとんどすべてのクレデンシャルプラグインのユースケースでは、クライアントプラグインが生成するクレデンシャルフォーマットを解釈するために、[Webhookトークン認証](#webhook-token-authentication)をサポートするサーバーサイドコンポーネントが必要です。 + +### 使用例 + +ある組織は、LDAPクレデンシャルをユーザー固有の署名済みトークンと交換する外部サービスを実行すると仮定します。このサービスは、トークンを検証するために[Webhookトークン認証](#webhook-token-authentication)リクエストに応答することもできます。ユーザーはワークステーションにクレデンシャルプラグインをインストールする必要があります。 + +以下のようにして、APIに対して認証を行います。 + +* ユーザーは`kubectl`コマンドを発行します。 +* クレデンシャルプラグインは、LDAPクレデンシャルの入力をユーザーに要求し、クレデンシャルを外部サービスとトークンと交換します。 +* クレデンシャルプラグインはトークンを`client-go`に返します。これはAPIサーバーに対するBearerトークンとして使用されます。 +* APIサーバーは、[Webhookトークン認証](#webhook-token-authentication)を使用して、`TokenReview`を外部サービスに送信します。 +* 外部サービスはトークンの署名を検証し、ユーザーのユーザー名とグループを返します。 + +### 設定 + +クレデンシャルプラグインの設定は、userフィールドの一部として[kubectlの設定ファイル](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)で行います。 + +```yaml +apiVersion: v1 +kind: Config +users: +- name: my-user + user: + exec: + # 実行するコマンドです。必須です。 + command: "example-client-go-exec-plugin" + + # ExecCredentialsリソースをデコードする際に使用するAPIのバージョン。必須です。 + # + # プラグインが返すAPIのバージョンは、ここに記載されているバージョンと一致しなければなりません + # + # 複数のバージョンをサポートするツール(client.authentication.k8s.io/v1alpha1など)と統合するには、 + # 環境変数を設定するか、execプラグインが期待するバージョンを示す引数をツールに渡します。 + apiVersion: "client.authentication.k8s.io/v1beta1" + + # プラグインを実行する際に設定する環境変数です。任意です。 + env: + - name: "FOO" + value: "bar" + + # プラグインを実行する際に渡す引数です。任意です。 + args: + - "arg1" + - "arg2" +clusters: +- name: my-cluster + cluster: + server: "https://172.17.4.100:6443" + certificate-authority: "/etc/kubernetes/ca.pem" +contexts: +- name: my-cluster + context: + cluster: my-cluster + user: my-user +current-context: my-cluster +``` + +相対的なコマンドパスは、設定ファイルのディレクトリーからの相対的なものとして解釈されます。KUBECONFIGが`/home/jane/kubeconfig`に設定されていて、execコマンドが`./bin/example-client-go-exec-plugin`の場合、バイナリー`/home/jane/bin/example-client-go-exec-plugin`が実行されます。 + +```yaml +- name: my-user + user: + exec: + # kubeconfigのディレクトリーへの相対パス + command: "./bin/example-client-go-exec-plugin" + apiVersion: "client.authentication.k8s.io/v1beta1" +``` + +### 入出力フォーマット + +実行されたコマンドは`ExecCredential`オブジェクトを`stdout`に出力します。`k8s.io/client-go`は`status`で返された認証情報を用いて、Kubernetes APIに対して認証を行ういます。 + +対話的なセッションから実行する場合、`stdin`はプラグインに直接公開されます。プラグインは[TTYチェック](https://godoc.org/golang.org/x/crypto/ssh/terminal#IsTerminal)を使って、対話的にユーザーにプロンプトを出すことが適切かどうかを判断する必要があります。 + +Bearerトークンのクレデンシャルを使用するために、プラグインは`ExecCredential`のステータスにトークンを返します。 + +```json +{ + "apiVersion": "client.authentication.k8s.io/v1beta1", + "kind": "ExecCredential", + "status": { + "token": "my-bearer-token" + } +} +``` + +あるいは、PEMエンコードされたクライアント証明書と鍵を返して、TLSクライアント認証を使用することもできます。 +プラグインが後続の呼び出しで異なる証明書と鍵を返すと、`k8s.io/client-go`はサーバーとの既存の接続を閉じて、新しいTLSハンドシェイクを強制します + +指定された場合、`clientKeyData`と`clientCertificateData`両方が存在しなければなりません。 + +`clientCertificateData`には、サーバーに送信するための中間証明書を含めることができます。 + +```json +{ + "apiVersion": "client.authentication.k8s.io/v1beta1", + "kind": "ExecCredential", + "status": { + "clientCertificateData": "-----BEGIN CERTIFICATE-----\n...\n-----END CERTIFICATE-----", + "clientKeyData": "-----BEGIN RSA PRIVATE KEY-----\n...\n-----END RSA PRIVATE KEY-----" + } +} +``` + +オプションで、レスポンスにはRFC3339のタイムスタンプとしてフォーマットされたクレデンシャルの有効期限を含めることができます。有効期限の有無には、以下のような影響あります。 + +- 有効期限が含まれている場合、BearerトークンとTLSクレデンシャルは有効期限に達するまで、またはサーバーがHTTPステータスコード401で応答したとき、またはプロセスが終了するまでキャッシュされます。 +- 有効期限が省略された場合、BearerトークンとTLSクレデンシャルはサーバーがHTTPステータスコード401で応答したとき、またはプロセスが終了するまでキャッシュされます。 + +```json +{ + "apiVersion": "client.authentication.k8s.io/v1beta1", + "kind": "ExecCredential", + "status": { + "token": "my-bearer-token", + "expirationTimestamp": "2018-03-05T17:30:20-08:00" + } +} +``` diff --git a/content/ja/docs/reference/glossary/cncf.md b/content/ja/docs/reference/glossary/cncf.md new file mode 100755 index 0000000000..85e6f60f0a --- /dev/null +++ b/content/ja/docs/reference/glossary/cncf.md @@ -0,0 +1,20 @@ +--- +title: Cloud Native Computing Foundation (CNCF) +id: cncf +date: 2019-05-26 +full_link: https://cncf.io/ +short_description: > + Cloud Native Computing Foundation + +aka: +tags: +- community +--- + Cloud Native Computing Foundation (CNCF)は、持続可能なエコシステムを構築し、マイクロサービスアーキテクチャの一部としてコンテナをオーケストレーションする[プロジェクト](https://www.cncf.io/projects/)を中心としたコミュニティを育成します。 + +KubernetesはCNCFプロジェクトです。 + + + +CNCFは[Linux Foundation](https://www.linuxfoundation.org/)のサブファウンデーションです。 +CNCFの使命は、クラウドネイティブコンピューティングをユビキタスにすることです。 diff --git a/content/ja/docs/reference/glossary/container.md b/content/ja/docs/reference/glossary/container.md index 616405a720..480934867a 100644 --- a/content/ja/docs/reference/glossary/container.md +++ b/content/ja/docs/reference/glossary/container.md @@ -4,14 +4,14 @@ id: container date: 2018-04-12 full_link: /docs/concepts/overview/what-is-kubernetes/#why-containers short_description: > - 軽量でポータブルなソフトウェアとそのすべての依存関係が含まれている実行可能なイメージ + 軽量でポータブルなソフトウェアとそのすべての依存関係が含まれている実行可能なイメージです。 aka: tags: - fundamental - workload --- - 軽量でポータブルなソフトウェアとそのすべての依存関係が含まれている実行可能なイメージ + 軽量でポータブルなソフトウェアとそのすべての依存関係が含まれている実行可能なイメージです。 diff --git a/content/ja/docs/reference/glossary/deployment.md b/content/ja/docs/reference/glossary/deployment.md index d3483b58fb..569cbbd6a1 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オブジェクト。 + 複製されたアプリケーションを管理するAPIオブジェクトです。 aka: tags: @@ -12,7 +12,7 @@ tags: - core-object - workload --- - 複製されたアプリケーションを管理するAPIオブジェクト。 + 複製されたアプリケーションを管理するAPIオブジェクトです。 diff --git a/content/ja/docs/reference/glossary/image.md b/content/ja/docs/reference/glossary/image.md new file mode 100755 index 0000000000..c677808747 --- /dev/null +++ b/content/ja/docs/reference/glossary/image.md @@ -0,0 +1,17 @@ +--- +title: イメージ +id: image +date: 2018-04-12 +full_link: +short_description: > + アプリケーションの実行に必要なソフトウェアのセットを持つ、保存されたコンテナの実体です。 + +aka: +tags: +- fundamental +--- + アプリケーションの実行に必要なソフトウェアのセットを持つ、保存された{{< glossary_tooltip text="コンテナ" term_id="container" >}}の実体です。 + + + +コンテナレジストリに格納し、ローカルシステムにプルして、アプリケーションとして実行できるようにするソフトウェアをパッケージ化する方法です。イメージに含まれているメタデータは、実行する実行可能ファイル、作成者、およびその他の情報を示すことができます。 diff --git a/content/ja/docs/reference/glossary/index.md b/content/ja/docs/reference/glossary/index.md index eb6d2c00fd..1f0da77b5e 100755 --- a/content/ja/docs/reference/glossary/index.md +++ b/content/ja/docs/reference/glossary/index.md @@ -1,5 +1,5 @@ --- -title: Standardized Glossary +title: 標準化用語集 layout: glossary noedit: true default_active_tag: fundamental @@ -7,6 +7,6 @@ weight: 5 card: name: reference weight: 10 - title: Glossary + title: 用語集 --- diff --git a/content/ja/docs/reference/glossary/name.md b/content/ja/docs/reference/glossary/name.md index 48c4ca4db9..214f3d571e 100755 --- a/content/ja/docs/reference/glossary/name.md +++ b/content/ja/docs/reference/glossary/name.md @@ -14,5 +14,5 @@ tags: -同じ種類のオブジェクトは、同じ名前を同時に持つことは出来ません。しかし、オブジェクトを削除することで、旧オブジェクトと同じ名前で新しいオブジェクトを作成できます。 +同じ種類のオブジェクトは、同じ名前を同時に持つことはできません。しかし、オブジェクトを削除することで、旧オブジェクトと同じ名前で新しいオブジェクトを作成できます。 diff --git a/content/ja/docs/reference/glossary/persistent-volume-claim.md b/content/ja/docs/reference/glossary/persistent-volume-claim.md index 7366429a24..021c998def 100644 --- a/content/ja/docs/reference/glossary/persistent-volume-claim.md +++ b/content/ja/docs/reference/glossary/persistent-volume-claim.md @@ -6,13 +6,13 @@ full_link: /docs/concepts/storage/persistent-volumes/ short_description: > コンテナ内でボリュームとしてマウントするためにPersistentVolume内で定義されたストレージリソースを要求します。 -aka: +aka: tags: - core-object - storage --- {{< glossary_tooltip text="コンテナ" term_id="container" >}}内でボリュームとしてマウントするために{{< glossary_tooltip text="PersistentVolume" term_id="persistent-volume" >}}内で定義されたストレージリソースを要求します。 - + -ストレージサイズ、ストレージへのアクセス制御（読み取り専用、読み取り/書き込み、排他的）、および再利用方法（保持、リサイクル、削除）を指定します。ストレージ自体の詳細はPersistentVolumeオブジェクトに記載されています。 +ストレージサイズ、ストレージへのアクセス制御(読み取り専用、読み取り/書き込み、排他的)、および再利用方法（保持、リサイクル、削除）を指定します。ストレージ自体の詳細はPersistentVolumeオブジェクトに記載されています。 diff --git a/content/ja/docs/reference/glossary/service.md b/content/ja/docs/reference/glossary/service.md index 212c3acce1..304e781b53 100755 --- a/content/ja/docs/reference/glossary/service.md +++ b/content/ja/docs/reference/glossary/service.md @@ -11,7 +11,7 @@ tags: - fundamental - core-object --- -{{< glossary_tooltip text="Pods" term_id="pod" >}}の集合で実行されているアプリケーションをネットワークサービスとして公開する抽象的な方法。 +{{< glossary_tooltip text="Pod" term_id="pod" >}}の集合で実行されているアプリケーションをネットワークサービスとして公開する抽象的な方法です。 diff --git a/content/ja/docs/reference/glossary/statefulset.md b/content/ja/docs/reference/glossary/statefulset.md index bcb947367d..1fad77bd62 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: > - Manages the deployment and scaling of a set of Pods, *and provides guarantees about the ordering and uniqueness* of these Pods. + StatefulSetはDeploymentとPodのセットのスケーリングを管理し、それらのPodの *順序と一意性を保証* します。 aka: tags: @@ -14,7 +14,7 @@ tags: - storage --- -StatefulSetはDeploymentと{{< glossary_tooltip text="Pod" term_id="pod" >}}のセットのスケーリングの管理をし、それらのPodの*順序とユニーク性を保証* します。 +StatefulSetはDeploymentと{{< glossary_tooltip text="Pod" term_id="pod" >}}のセットのスケーリングを管理し、それらのPodの*順序と一意性を保証* します。 diff --git a/content/ja/docs/reference/glossary/volume.md b/content/ja/docs/reference/glossary/volume.md index 8ea7702e4c..6a81f84522 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 text="Pod" term_id="pod" >}}内の{{< glossary_tooltip text="コンテナ" term_id="container" >}}からアクセス可能なデータを含むディレクトリ。 + {{< glossary_tooltip text="Pod" term_id="pod" >}}内の{{< glossary_tooltip text="コンテナ" term_id="container" >}}からアクセス可能なデータを含むディレクトリです。 diff --git a/content/ja/docs/reference/kubectl/cheatsheet.md b/content/ja/docs/reference/kubectl/cheatsheet.md index cc1da85b76..d63654bd38 100644 --- a/content/ja/docs/reference/kubectl/cheatsheet.md +++ b/content/ja/docs/reference/kubectl/cheatsheet.md @@ -323,7 +323,7 @@ kubectl cluster-info # Kubernet kubectl cluster-info dump # 現在のクラスター状態を標準出力にダンプします kubectl cluster-info dump --output-directory=/path/to/cluster-state # 現在のクラスター状態を/path/to/cluster-stateにダンプします -# special-userキーとNoScheduleエフェクトを持つTaintが既に存在する場合、その値は指定されたとおりに置き換えられます +# special-userキーとNoScheduleエフェクトを持つTaintがすでに存在する場合、その値は指定されたとおりに置き換えられます kubectl taint nodes foo dedicated=special-user:NoSchedule ``` diff --git a/content/ja/docs/setup/_index.md b/content/ja/docs/setup/_index.md index 8ba1773f75..2d602e9300 100644 --- a/content/ja/docs/setup/_index.md +++ b/content/ja/docs/setup/_index.md @@ -49,6 +49,6 @@ Kubernetesについて学んでいる場合、Dockerベースのソリューシ 本番環境用のソリューションを評価する際には、Kubernetesクラスター(または抽象レイヤ)の運用においてどの部分を自分で管理し、どの部分をプロバイダーに任せるのかを考慮してください。 -[Certified Kubernetes](https://github.com/cncf/k8s-conformance/#certified-kubernetes)プロバイダーの一覧については、"[Partners](https://kubernetes.io/partners/#conformance)"を参照してください。 +[Certified Kubernetes](https://github.com/cncf/k8s-conformance/#certified-kubernetes)プロバイダーの一覧については、「[パートナー](https://kubernetes.io/ja/partners/#conformance)」を参照してください。 diff --git a/content/ja/docs/setup/best-practices/certificates.md b/content/ja/docs/setup/best-practices/certificates.md index ff6fe29dd1..7f67ee7006 100644 --- a/content/ja/docs/setup/best-practices/certificates.md +++ b/content/ja/docs/setup/best-practices/certificates.md @@ -72,7 +72,7 @@ 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][kubeadm]を使用する場合と同様、ロードバランサーのIPおよびDNS名、`kubernetes`、`kubernetes.default`、`kubernetes.default.svc`、`kubernetes.default.svc.cluster`、`kubernetes.default.svc.cluster.local`) `kind`は下記の[x509の鍵用途][usage]のタイプにマッピングされます: @@ -82,7 +82,7 @@ CAの秘密鍵をクラスターにコピーしたくない場合、自身で全 | client | digital signature, key encipherment, client auth | {{< note >}} -上記に挙げられたホスト名（SAN）は、クラスターを動作させるために推奨されるものです。 +上記に挙げられたホスト名(SAN)は、クラスターを動作させるために推奨されるものです。 特別なセットアップが求められる場合、全てのサーバー証明書にSANを追加する事ができます。 {{< /note >}} diff --git a/content/ja/docs/setup/best-practices/multiple-zones.md b/content/ja/docs/setup/best-practices/multiple-zones.md index 577cc42650..3590f6fa8c 100644 --- a/content/ja/docs/setup/best-practices/multiple-zones.md +++ b/content/ja/docs/setup/best-practices/multiple-zones.md @@ -303,7 +303,7 @@ kubectl get nodes --show-labels Create the guestbook-go example, which includes an RC of size 3, running a simple web app: ```shell -find kubernetes/examples/guestbook-go/ -name '*.json' | xargs -I {} kubectl create -f {} +find kubernetes/examples/guestbook-go/ -name '*.json' | xargs -I {} kubectl apply -f {} ``` The pods should be spread across all 3 zones: diff --git a/content/ja/docs/setup/best-practices/node-conformance.md b/content/ja/docs/setup/best-practices/node-conformance.md index 129bd762ba..0db9cb4432 100644 --- a/content/ja/docs/setup/best-practices/node-conformance.md +++ b/content/ja/docs/setup/best-practices/node-conformance.md @@ -7,43 +7,35 @@ weight: 30 ## ノード適合テスト -*Node conformance test* is a containerized test framework that provides a system -verification and functionality test for a node. The test validates whether the -node meets the minimum requirements for Kubernetes; a node that passes the test -is qualified to join a Kubernetes cluster. +*ノード適合テスト* は、システムの検証とノードに対する機能テストを提供するコンテナ型のテストフレームワークです。このテストは、ノードがKubernetesの最小要件を満たしているかどうかを検証するもので、テストに合格したノードはKubernetesクラスタに参加する資格があることになります。 ## 制約 -In Kubernetes version 1.5, node conformance test has the following limitations: +Kubernetesのバージョン1.5ではノード適合テストには以下の制約があります: -* Node conformance test only supports Docker as the container runtime. +* ノード適合テストはコンテナのランタイムとしてDockerのみをサポートします。 ## ノードの前提条件 -To run node conformance test, a node must satisfy the same prerequisites as a -standard Kubernetes node. At a minimum, the node should have the following -daemons installed: +適合テストを実行するにはノードは通常のKubernetesノードと同じ前提条件を満たしている必要があります。 最低でもノードに以下のデーモンがインストールされている必要があります: -* Container Runtime (Docker) +* コンテナランタイム (Docker) * Kubelet ## ノード適合テストの実行 -To run the node conformance test, perform the following steps: +ノード適合テストを実行するには、以下の手順に従います: -1. Point your Kubelet to localhost `--api-servers="http://localhost:8080"`, -because the test framework starts a local master to test Kubelet. There are some -other Kubelet flags you may care: - * `--pod-cidr`: If you are using `kubenet`, you should specify an arbitrary CIDR - to Kubelet, for example `--pod-cidr=10.180.0.0/24`. - * `--cloud-provider`: If you are using `--cloud-provider=gce`, you should - remove the flag to run the test. +1. Kubeletをlocalhostに指定します(`--api-servers="http://localhost:8080"`)、 +このテストフレームワークはKubeletのテストにローカルマスターを起動するため、Kubeletをローカルホストに設定します(`--api-servers="http://localhost:8080"`)。他にも配慮するべきKubeletフラグがいくつかあります: + * `--pod-cidr`: `kubenet`を利用している場合は、Kubeletに任意のCIDR(例: `--pod-cidr=10.180.0.0/24`)を指定する必要があります。 + * `--cloud-provider`: `--cloud-provider=gce`を指定している場合は、テストを実行する前にこのフラグを取り除いてください。 -2. Run the node conformance test with command: +2. 以下のコマンドでノード適合テストを実行します: ```shell -# $CONFIG_DIR is the pod manifest path of your Kubelet. -# $LOG_DIR is the test output path. +# $CONFIG_DIRはKubeletのPodのマニフェストパスです。 +# $LOG_DIRはテスト出力のパスです。 sudo docker run -it --rm --privileged --net=host \ -v /:/rootfs -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \ k8s.gcr.io/node-test:0.2 @@ -51,8 +43,7 @@ sudo docker run -it --rm --privileged --net=host \ ## 他アーキテクチャ向けのノード適合テストの実行 -Kubernetes also provides node conformance test docker images for other -architectures: +Kubernetesは他のアーキテクチャ用のノード適合テストのdockerイメージを提供しています: Arch | Image | --------|:-----------------:| @@ -62,37 +53,30 @@ architectures: ## 選択したテストの実行 -To run specific tests, overwrite the environment variable `FOCUS` with the -regular expression of tests you want to run. +特定のテストを実行するには、環境変数`FOCUS`を実行したいテストの正規表現で上書きします。 ```shell sudo docker run -it --rm --privileged --net=host \ -v /:/rootfs:ro -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \ - -e FOCUS=MirrorPod \ # Only run MirrorPod test + -e FOCUS=MirrorPod \ # MirrorPodテストのみを実行します k8s.gcr.io/node-test:0.2 ``` -To skip specific tests, overwrite the environment variable `SKIP` with the -regular expression of tests you want to skip. +特定のテストをスキップするには、環境変数`SKIP`をスキップしたいテストの正規表現で上書きします。 ```shell sudo docker run -it --rm --privileged --net=host \ -v /:/rootfs:ro -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \ - -e SKIP=MirrorPod \ # Run all conformance tests but skip MirrorPod test + -e SKIP=MirrorPod \ # MirrorPodテスト以外のすべてのノード適合テストを実行します k8s.gcr.io/node-test:0.2 ``` -Node conformance test is a containerized version of [node e2e test](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/e2e-node-tests.md). -By default, it runs all conformance tests. +ノード適合テストは、[node e2e test](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/e2e-node-tests.md)のコンテナ化されたバージョンです。 +デフォルトでは、すべての適合テストが実行されます。 -Theoretically, you can run any node e2e test if you configure the container and -mount required volumes properly. But **it is strongly recommended to only run conformance -test**, because it requires much more complex configuration to run non-conformance test. +理論的には、コンテナを構成し必要なボリュームを適切にマウントすれば、どのノードのe2eテストも実行できます。しかし、不適合テストを実行するためにはより複雑な設定が必要となるため、**適合テストのみを実行することを強く推奨します**。 ## 注意事項 -* The test leaves some docker images on the node, including the node conformance - test image and images of containers used in the functionality - test. -* The test leaves dead containers on the node. These containers are created - during the functionality test. +* このテストでは、ノード適合テストイメージや機能テストで使用されるコンテナのイメージなど、いくつかのdockerイメージがノード上に残ります。 +* このテストでは、ノード上にデッドコンテナが残ります。これらのコンテナは機能テスト中に作成されます。 diff --git a/content/ja/docs/setup/learning-environment/_index.md b/content/ja/docs/setup/learning-environment/_index.md index 051413db61..fad99fb4e8 100644 --- a/content/ja/docs/setup/learning-environment/_index.md +++ b/content/ja/docs/setup/learning-environment/_index.md @@ -1,4 +1,4 @@ --- -title: 環境について学ぶ +title: 学習環境 weight: 20 --- diff --git a/content/ja/docs/setup/learning-environment/minikube.md b/content/ja/docs/setup/learning-environment/minikube.md index 1a28e49261..67b0002946 100644 --- a/content/ja/docs/setup/learning-environment/minikube.md +++ b/content/ja/docs/setup/learning-environment/minikube.md @@ -1,143 +1,257 @@ --- title: Minikubeを使用してローカル環境でKubernetesを動かす +weight: 30 content_type: concept --- + Minikubeはローカル環境でKubernetesを簡単に実行するためのツールです。Kubernetesを試したり日々の開発への使用を検討するユーザー向けに、PC上のVM内でシングルノードのKubernetesクラスタを実行することができます。 - ## Minikubeの機能 -* MinikubeのサポートするKubernetesの機能: - * DNS - * NodePorts - * ConfigMapsとSecrets - * ダッシュボード - * コンテナランタイム: Docker, [rkt](https://github.com/rkt/rkt), [CRI-O](https://cri-o.io/), [containerd](https://github.com/containerd/containerd) - * CNI (Container Network Interface) の有効化 - * Ingress +MinikubeのサポートするKubernetesの機能: + +* DNS +* NodePort +* ConfigMapとSecret +* ダッシュボード +* コンテナランタイム: Docker、[CRI-O](https://cri-o.io/)および[containerd](https://github.com/containerd/containerd) +* CNI (Container Network Interface) の有効化 +* Ingress ## インストール -[Minikubeのインストール](/ja/docs/tasks/tools/install-minikube/) を参照 +[Minikubeのインストール](/ja/docs/tasks/tools/install-minikube/)を参照してください。 ## クイックスタート -これはMinikubeの使い方の簡単なデモです。 -もしVMドライバを変更したい場合は、適切な `--vm-driver=xxx` フラグを `minikube start` に設定してください。Minikubeは以下のドライバをサポートしています。 +これはMinikubeの起動、使用、削除をローカルで実施する簡単なデモです。下記の手順に従って、Minikubeを起動し試してください。 -* virtualbox +1. Minikubeを起動し、クラスターを作成します: + + ```shell + minikube start + ``` + + 出力はこのようになります: + + ``` + Starting local Kubernetes cluster... + Running pre-create checks... + Creating machine... + Starting local Kubernetes cluster... + ``` + + 特定のKubernetesのバージョン、VM、コンテナランタイム上でクラスターを起動するための詳細は、[クラスターの起動](#starting-a-cluster)を参照してください。 + +2. kubectlを使用してクラスターと対話できるようになります。詳細は[クラスターに触れてみよう](#interacting-with-your-cluster)を参照してください。 +単純なHTTPサーバーである`echoserver`という既存のイメージを使用して、Kubernetes Deploymentを作りましょう。そして`--port`を使用して8080番ポートで公開しましょう。 + + ```shell + kubectl create deployment hello-minikube --image=k8s.gcr.io/echoserver:1.10 + ``` + + 出力はこのようになります: + + ``` + deployment.apps/hello-minikube created + ``` + +3. `hello-minikube`Deploymentに接続するために、Serviceとして公開します: + + ```shell + kubectl expose deployment hello-minikube --type=NodePort --port=8080 + ``` + + `--type=NodePort`オプションで、Serviceのタイプを指定します。 + 出力はこのようになります: + + ``` + service/hello-minikube exposed + ``` + +4. `hello-minikube`Podが起動開始されましたが、公開したService経由で接続する前にPodが起動完了になるまで待つ必要があります。 + + Podが稼働しているか確認します: + ```shell + kubectl get pod + ``` + + `STATUS`に`ContainerCreating`と表示されている場合、Podはまだ作成中です: + + ``` + NAME READY STATUS RESTARTS AGE + hello-minikube-3383150820-vctvh 0/1 ContainerCreating 0 3s + ``` + + `STATUS`に`Running`と表示されている場合、Podは稼働中です: + + ``` + NAME READY STATUS RESTARTS AGE + hello-minikube-3383150820-vctvh 1/1 Running 0 13s + ``` + +5. Serviceの詳細を確認するため、公開したServiceのURLを取得します: + + ```shell + minikube service hello-minikube --url + ``` + +6. ローカル環境のクラスターについて詳細を確認するには、出力から得たURLをブラウザー上でコピーアンドペーストしてください。 + + 出力はこのようになります: + + ``` + Hostname: hello-minikube-7c77b68cff-8wdzq + + Pod Information: + -no pod information available- + + Server values: + 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/ + + Request Headers: + accept=*/* + host=192.168.99.100:30674 + user-agent=curl/7.47.0 + + Request Body: + -no body in request- + ``` + + Serviceやクラスターをこれ以上稼働させない場合、削除する事ができます。 + +7. `hello-minikube`Serviceを削除します: + + ```shell + kubectl delete services hello-minikube + ``` + + 出力はこのようになります: + + ``` + service "hello-minikube" deleted + ``` + +8. `hello-minikube`Deploymentを削除します: + + ```shell + kubectl delete deployment hello-minikube + ``` + + 出力はこのようになります: + + ``` + deployment.extensions "hello-minikube" deleted + ``` + +9. ローカル環境のMinikubeクラスターを停止します: + + ```shell + minikube stop + ``` + + 出力はこのようになります: + + ``` + Stopping local Kubernetes cluster... + Stopping "minikube"... + ``` + + 詳細は[クラスターの停止](#stopping-a-cluster)を参照ください。 + +10. ローカルのMinikubeクラスターを削除します: + + ```shell + minikube delete + ``` + + 出力はこのようになります: + + ``` + Deleting "minikube" ... + The "minikube" cluster has been deleted. + ``` + + 詳細は[クラスターの削除](#deleting-a-cluster)を参照ください。 + +## クラスターの管理 + +### クラスターの起動 {#starting-a-cluster} + +`minikube start`コマンドを使用してクラスターを起動することができます。 +このコマンドはシングルノードのKubernetesクラスターを実行する仮想マシンを作成・設定します。 +また、このクラスターと通信する[kubectl](/ja/docs/reference/kubectl/overview/)のインストールも設定します。 + +{{< note >}} +もしWebプロキシーを通している場合、そのプロキシー情報を`minikube start`コマンドに渡す必要があります: + +```shell +https_proxy= minikube start --docker-env http_proxy= --docker-env https_proxy= --docker-env no_proxy=192.168.99.0/24 +``` + +残念なことに、ただ環境変数を設定するだけではうまく動作しません。 + +Minikubeは"minikube"コンテキストも作成し、そのコンテキストをデフォルト設定としてkubectlに設定します。 +あとでコンテキストを切り戻すには、このコマンドを実行してください: `kubectl config use-context minikube` +{{< /note >}} + +#### Kubernetesバージョンの指定 + +`minikube start`コマンドに`--kubernetes-version`文字列を追加することで、 +MinikubeにKubernetesの特定のバージョンを指定することができます。 +例えば、{{< param "fullversion" >}}のバージョンを実行するには以下を実行します: + +``` +minikube start --kubernetes-version {{< param "fullversion" >}} +``` + +#### VMドライバーの指定 + +もしVMドライバーを変更したい場合は、`--vm-driver=`フラグを`minikube start`に設定してください。例えば、コマンドは以下のようになります。 + +```shell +minikube start --vm-driver= +``` + +Minikubeは以下のドライバーをサポートしています: + {{< note >}} +サポートされているドライバーとプラグインのインストールの詳細については[DRIVERS](https://git.k8s.io/minikube/docs/drivers.md)を参照してください。 +{{< /note >}} + +* virtualbox * vmwarefusion * kvm2 ([driver installation](https://minikube.sigs.k8s.io/docs/drivers/#kvm2-driver)) -* kvm ([driver installation](https://minikube.sigs.k8s.io/docs/drivers/#kvm-driver)) * hyperkit ([driver installation](https://minikube.sigs.k8s.io/docs/drivers/#hyperkit-driver)) -* xhyve ([driver installation](https://minikube.sigs.k8s.io/docs/drivers/#xhyve-driver)) (非推奨) * hyperv ([driver installation](https://github.com/kubernetes/minikube/blob/master/docs/drivers.md#hyperv-driver)) -注意: 以下のIPは動的であり、変更される可能性があります。IPは `minikube ip` で取得することができます。 -* none (VMではなくホスト上でKubernetesコンポーネントを起動する。このドライバを使用するにはDocker ([docker install](https://docs.docker.com/install/linux/docker-ce/ubuntu/)) とLinux環境を必要とします) +注意: 以下のIPは動的であり、変更される可能性があります。IPは`minikube ip`で取得することができます。 +* vmware ([driver installation](https://minikube.sigs.k8s.io/docs/reference/drivers/vmware/)) (VMware unified driver) +* none (VMではなくホスト上でKubernetesコンポーネントを起動。このドライバーを使用するには{{< glossary_tooltip term_id="docker" >}}とLinux環境を必要とします) -```shell -minikube start -``` -``` -Starting local Kubernetes cluster... -Running pre-create checks... -Creating machine... -Starting local Kubernetes cluster... -``` -```shell -kubectl create deployment hello-minikube --image=k8s.gcr.io/echoserver:1.10 -``` -``` -deployment.apps/hello-minikube created -``` - -```shell -kubectl expose deployment hello-minikube --type=NodePort --port=8080 -``` -``` -service/hello-minikube exposed -``` -``` -# We have now launched an echoserver pod but we have to wait until the pod is up before curling/accessing it -# via the exposed service. -# To check whether the pod is up and running we can use the following: -kubectl get pod -``` -``` -NAME READY STATUS RESTARTS AGE -hello-minikube-3383150820-vctvh 0/1 ContainerCreating 0 3s -``` -```shell -# We can see that the pod is still being created from the ContainerCreating status -kubectl get pod -``` -``` -NAME READY STATUS RESTARTS AGE -hello-minikube-3383150820-vctvh 1/1 Running 0 13s -``` -```shell -# We can see that the pod is now Running and we will now be able to curl it: -curl $(minikube service hello-minikube --url) -``` -``` - -Hostname: hello-minikube-7c77b68cff-8wdzq - -Pod Information: - -no pod information available- - -Server values: - 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/ - -Request Headers: - accept=*/* - host=192.168.99.100:30674 - user-agent=curl/7.47.0 - -Request Body: - -no body in request- -``` - -```shell -kubectl delete services hello-minikube -``` -``` -service "hello-minikube" deleted -``` - -```shell -kubectl delete deployment hello-minikube -``` -``` -deployment.extensions "hello-minikube" deleted -``` - -```shell -minikube stop -``` -``` -Stopping local Kubernetes cluster... -Stopping "minikube"... -``` +{{< caution >}} +`none`ドライバーを使用する場合、一部のKubernetesのコンポーネントは特権付きのコンテナとして稼働するため、Minikube環境外に副作用をもたらします。 +この副作用から、`none`ドライバーは、個人の作業環境では推奨されません。 +{{< /caution >}} ### コンテナランタイムの代替 +下記のコンテナランタイム上でMinikubeを起動できます。 -#### containerd +{{< tabs name="container_runtimes" >}} +{{% tab name="containerd" %}} [containerd](https://github.com/containerd/containerd) をコンテナランタイムとして使用するには以下を実行してください: @@ -160,10 +274,9 @@ minikube start \ --extra-config=kubelet.image-service-endpoint=unix:///run/containerd/containerd.sock \ --bootstrapper=kubeadm ``` - -#### CRI-O - -[CRI-O](https://github.com/kubernetes-incubator/cri-o) をコンテナランタイムとして使用するには以下を実行してください: +{{% /tab %}} +{{% tab name="CRI-O" %}} +[CRI-O](https://cri-o.io/)をコンテナランタイムとして使用するには以下を実行してください: ```bash minikube start \ @@ -184,47 +297,33 @@ minikube start \ --extra-config=kubelet.image-service-endpoint=/var/run/crio.sock \ --bootstrapper=kubeadm ``` - -#### rktコンテナエンジン - -[rkt](https://github.com/rkt/rkt) をコンテナランタイムとして使用するには以下を実行してください: - -```shell -minikube start \ - --network-plugin=cni \ - --enable-default-cni \ - --container-runtime=rkt -``` - -これはrktとDockerの両方を含んだ代替のMinikubeのISOイメージを使用し、CNIネットワークを有効にします。 - -### ドライバープラグイン - -サポートされているドライバとプラグインのインストールの詳細については [DRIVERS](https://minikube.sigs.k8s.io/docs/drivers/) を参照してください。 +{{% /tab %}} +{{< /tabs >}} ### Dockerデーモンの再利用によるローカルイメージの使用 -Kubernetesの単一のVMを使用する場合、Minikube組み込みのDockerデーモンの再利用がおすすめです。ホストマシン上にDockerレジストリを構築してイメージをプッシュする必要がなく、ローカルでの実験を加速させるMinikubeと同じDockerデーモンの中に構築することができます。ただDockerイメージに'latest'以外のタグを付け、そのタグを使用してイメージをプルしてください。イメージのバージョンを指定しなければ、`Always` のプルイメージポリシーにより `:latest` と仮定され、もしデフォルトのDockerレジストリ(通常はDockerHub)にどのバージョンのDockerイメージもまだ存在しない場合には、`ErrImagePull` になる恐れがあります。 +Kubernetesの単一のVMを使用する場合、Minikube組み込みのDockerデーモンの再利用がおすすめです。ホストマシン上にDockerレジストリを構築してイメージをプッシュする必要がなく、ローカルでの実験を加速させるMinikubeと同じDockerデーモンの中に構築することができます。 -Mac/LinuxのホストでDockerデーモンを操作できるようにするには、shell内で `docker-env command` を使います: +{{< note >}} +Dockerイメージに'latest'以外のタグを付け、そのタグを使用してイメージをプルしてください。イメージのバージョンを指定しなければ`Always`のプルイメージポリシーにより`:latest`と仮定され、もしデフォルトのDockerレジストリ(通常はDockerHub)にどのバージョンのDockerイメージもまだ存在しない場合には、`ErrImagePull`になる恐れがあります。 +{{< /note >}} -```shell -eval $(minikube docker-env) -``` +Mac/LinuxのホストでDockerデーモンを操作できるようにするには、`minikube docker-env`を実行します。 -これにより、MinikubeのVM内のDockerデーモンと通信しているホストのMac/LinuxマシンのコマンドラインでDockerを使用できるようになっているはずです。 +これにより、MinikubeのVM内のDockerデーモンと通信しているホストのMac/LinuxマシンのコマンドラインでDockerを使用できるようになります: ```shell docker ps ``` +{{< note >}} CentOS 7では、Dockerが以下のエラーを出力することがあります: -```shell +``` Could not read CA certificate "/etc/docker/ca.pem": open /etc/docker/ca.pem: no such file or directory ``` -修正方法としては、/etc/sysconfig/docker を更新してMinikube環境の変更が確実に反映されるようにすることです: +修正方法としては、/etc/sysconfig/dockerを更新してMinikube環境の変更が確実に反映されるようにすることです: ```shell < DOCKER_CERT_PATH=/etc/docker @@ -233,37 +332,7 @@ Could not read CA certificate "/etc/docker/ca.pem": open /etc/docker/ca.pem: no > DOCKER_CERT_PATH=/etc/docker > fi ``` - -imagePullPolicy:Alwaysをオフにすることを忘れないでください: さもなければKubernetesはローカルに構築したイメージを使用しません。 - -## クラスターの管理 - -### クラスターの起動 - -`minikube start` コマンドはクラスターを起動することができます。 -このコマンドはシングルノードのKubernetesクラスターを実行する仮想マシンを作成・設定します。 -また、このクラスターと通信する [kubectl](/docs/user-guide/kubectl-overview/) のインストールも設定します。 - -もしWebプロキシーを通している場合、そのプロキシー情報を `minikube start` コマンドに渡す必要があります: - -```shell -https_proxy= minikube start --docker-env http_proxy= --docker-env https_proxy= --docker-env no_proxy=192.168.99.0/24 -``` - -残念なことに、ただ環境変数を設定するだけではうまく動作しません。 - -Minikubeは "minikube" コンテキストも作成し、そのコンテキストをデフォルト設定としてkubectlに設定します。 -あとでコンテキストを切り戻すには、このコマンドを実行してください: `kubectl config use-context minikube` - -#### Kubernetesバージョンの指定 - -`minikube start` コマンドに `--kubernetes-version` 文字列を追加することで、 -MinikubeにKubernetesの特定のバージョンを指定することができます。 -例えば、`v1.7.3` のバージョンを実行するには以下を実行します: - -``` -minikube start --kubernetes-version v1.7.3 -``` +{{< /note >}} ### Kubernetesの設定 @@ -293,16 +362,19 @@ Kubeletの `MaxPods` 設定を5に変更するには、このフラグを渡し `apiserver` の `AuthorizationMode` を `RABC` に設定するには、このフラグを使います: `--extra-config=apiserver.authorization-mode=RBAC`. -### クラスターの停止 +### クラスターの停止 {#stopping-a-cluster} `minikube stop` コマンドを使ってクラスターを停止することができます。 このコマンドはMinikube仮想マシンをシャットダウンしますが、すべてのクラスターの状態とデータを保存します。 クラスターを再起動すると、以前の状態に復元されます。 -### クラスターの削除 +### クラスターの削除 {#deleting-a-cluster} `minikube delete` コマンドを使ってクラスターを削除することができます。 このコマンドはMinikube仮想マシンをシャットダウンして削除します。データや状態は保存されません。 -## クラスターに触れてみよう +### minikubeのアップグレード {#upgrading-minikube} +[minikubeのアップグレード](https://minikube.sigs.k8s.io/docs/start/macos/)を参照してください。 + +## クラスターに触れてみよう {#interacting-with-your-cluster} ### Kubectl @@ -379,7 +451,7 @@ spec: | VirtualBox | Linux | /home | /hosthome | | VirtualBox | macOS | /Users | /Users | | VirtualBox | Windows | C://Users | /c/Users | -| VMware Fusion | macOS | /Users | /Users | +| VMware Fusion | macOS | /Users | /mnt/hgfs/Users | | Xhyve | macOS | /Users | /Users | ## プライベートコンテナレジストリ @@ -417,10 +489,8 @@ export no_proxy=$no_proxy,$(minikube ip) ``` ## 既知の問題 -* クラウドプロバイダーを必要とする機能はMinikubeでは動作しません - * ロードバランサー -* 複数ノードを必要とする機能 - * 高度なスケジューリングポリシー + +複数ノードを必要とする機能はMinikubeでは動作しません。 ## 設計 @@ -440,5 +510,3 @@ Minikubeの詳細については、[proposal](https://git.k8s.io/community/contr ## コミュニティ コントリビューションや質問、コメントは歓迎・奨励されています! Minikubeの開発者は[Slack](https://kubernetes.slack.com)の#minikubeチャンネルにいます(Slackへの招待状は[こちら](http://slack.kubernetes.io/))。[kubernetes-dev Google Groupsメーリングリスト](https://groups.google.com/forum/#!forum/kubernetes-dev)もあります。メーリングリストに投稿する際は件名の最初に "minikube: " をつけてください。 - - diff --git a/content/ja/docs/setup/production-environment/container-runtimes.md b/content/ja/docs/setup/production-environment/container-runtimes.md index a9604a7b59..667726bc64 100644 --- a/content/ja/docs/setup/production-environment/container-runtimes.md +++ b/content/ja/docs/setup/production-environment/container-runtimes.md @@ -25,7 +25,7 @@ Podのコンテナを実行するために、Kubernetesはコンテナランタ ### 適用性 {{< note >}} -このドキュメントはLinuxにCRIをインストールするユーザーの為に書かれています。 +このドキュメントはLinuxにCRIをインストールするユーザーのために書かれています。 他のオペレーティングシステムの場合、プラットフォーム固有のドキュメントを見つけてください。 {{< /note >}} @@ -47,38 +47,46 @@ systemdと一緒に `cgroupfs` を使用するということは、2つの異な kubeletとDockerに `cgroupfs` を使用し、ノード上で実行されている残りのプロセスに `systemd` を使用するように設定されたノードが、 リソース圧迫下で不安定になる場合があります。 -あなたのコンテナランタイムとkubeletにcgroupドライバーとしてsystemdを使用するように設定を変更することはシステムを安定させました。 +コンテナランタイムとkubeletがcgroupドライバーとしてsystemdを使用するように設定を変更することでシステムは安定します。 以下のDocker設定の `native.cgroupdriver=systemd` オプションに注意してください。 +{{< caution >}} +すでにクラスターに組み込まれているノードのcgroupドライバーを変更することは非常におすすめしません。 +kubeletが一方のcgroupドライバーを使用してPodを作成した場合、コンテナランタイムを別のもう一方のcgroupドライバーに変更すると、そのような既存のPodのPodサンドボックスを再作成しようとするとエラーが発生する可能性があります。 +kubeletを再起動しても問題は解決しないでしょう。 +ワークロードからノードを縮退させ、クラスターから削除して再び組み込むことを推奨します。 +{{< /caution >}} + ## Docker それぞれのマシンに対してDockerをインストールします。 -バージョン18.06.2が推奨されていますが、1.11、1.12、1.13、17.03、18.09についても動作が確認されています。 +バージョン19.03.4が推奨されていますが、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" >}} +{{< tab name="Ubuntu 16.04+" codelang="bash" >}} # Docker CEのインストール ## リポジトリをセットアップ -### aptパッケージインデックスを更新 - apt-get update - ### HTTPS越しのリポジトリの使用をaptに許可するために、パッケージをインストール - apt-get update && apt-get install apt-transport-https ca-certificates curl software-properties-common +apt-get update && apt-get install -y \ + apt-transport-https ca-certificates curl software-properties-common gnupg2 ### Docker公式のGPG鍵を追加 - curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add - +curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add - -### dockerのaptリポジトリを追加 - add-apt-repository \ - "deb [arch=amd64] https://download.docker.com/linux/ubuntu \ - $(lsb_release -cs) \ - stable" +### Dockerのaptリポジトリを追加 +add-apt-repository \ + "deb [arch=amd64] https://download.docker.com/linux/ubuntu \ + $(lsb_release -cs) \ + stable" -## docker ceのインストール -apt-get update && apt-get install docker-ce=18.06.2~ce~3-0~ubuntu +## 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) # デーモンをセットアップ cat > /etc/docker/daemon.json <}} +CRI-OのメジャーとマイナーバージョンはKubernetesのメジャーとマイナーバージョンと一致しなければなりません。 +詳細は[CRI-O互換性表](https://github.com/cri-o/cri-o)を参照してください。 +{{< /note >}} + +### 事前準備 ```shell modprobe overlay @@ -164,33 +179,55 @@ sysctl --system ``` {{< tabs name="tab-cri-cri-o-installation" >}} -{{< tab name="Ubuntu 16.04" codelang="bash" >}} +{{< tab name="Debian" codelang="bash" >}} +# 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 - -# 必要なパッケージをインストールし、リポジトリを追加 -apt-get update -apt-get install software-properties-common +# 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 - -add-apt-repository ppa:projectatomic/ppa -apt-get update +# 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 - -# CRI-Oをインストール -apt-get install cri-o-1.11 +# 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のインストール +sudo apt-get install cri-o-1.17 {{< /tab >}} + +{{< tab name="Ubuntu 18.04, 19.04 and 19.10" codelang="bash" >}} +# リポジトリの設定 +. /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 + +# CRI-Oのインストール +sudo apt-get install cri-o-1.17 +{{< /tab >}} + {{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}} +# 必要なパッケージのインストール +yum-config-manager --add-repo=https://cbs.centos.org/repos/paas7-crio-115-release/x86_64/os/ -# 必要なリポジトリを追加 -yum-config-manager --add-repo=https://cbs.centos.org/repos/paas7-crio-311-candidate/x86_64/os/ - -# CRI-Oをインストール -yum install --nogpgcheck cri-o +# CRI-Oのインストール +yum install --nogpgcheck -y cri-o +{{< /tab >}} +{{< tab name="openSUSE Tumbleweed" codelang="bash" >}} +sudo zypper install cri-o {{< /tab >}} {{< /tabs >}} ### CRI-Oの起動 ``` +systemctl daemon-reload systemctl start crio ``` @@ -205,6 +242,11 @@ systemctl start crio ### 必要な設定の追加 ```shell +cat > /etc/modules-load.d/containerd.conf <}} -{{< tab name="Ubuntu 16.04+" codelang="bash" >}} -apt-get install -y libseccomp2 +{{< tab name="Ubuntu 16.04" codelang="bash" >}} +# containerdのインストール +## リポジトリの設定 +### HTTPS越しのリポジトリの使用をaptに許可するために、パッケージをインストール +apt-get update && apt-get install -y apt-transport-https ca-certificates curl software-properties-common + +### Docker公式のGPG鍵を追加 +curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add - + +### Dockerのaptリポジトリの追加 +add-apt-repository \ + "deb [arch=amd64] https://download.docker.com/linux/ubuntu \ + $(lsb_release -cs) \ + stable" + +## containerdのインストール +apt-get update && apt-get install -y containerd.io + +# containerdの設定 +mkdir -p /etc/containerd +containerd config default > /etc/containerd/config.toml + +# containerdの再起動 +systemctl restart containerd {{< /tab >}} {{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}} -yum install -y libseccomp +# containerdのインストール +## リポジトリの設定 +### 必要なパッケージのインストール +yum install -y yum-utils device-mapper-persistent-data lvm2 + +### Dockerのリポジトリの追加 +yum-config-manager \ + --add-repo \ + https://download.docker.com/linux/centos/docker-ce.repo + +## containerdのインストール +yum update -y && yum install -y containerd.io + +# containerdの設定 +mkdir -p /etc/containerd +containerd config default > /etc/containerd/config.toml + +# containerdの再起動 +systemctl restart containerd {{< /tab >}} {{< /tabs >}} -### containerdのインストール +### systemd -[Containerdは定期的にリリース](https://github.com/containerd/containerd/releases)されますが、以下に示すコマンドで利用している値は、この手順が作成された時点での最新のバージョンにしたがって書かれています。より新しいバージョンとダウンロードするファイルのハッシュ値については[こちら](https://storage.googleapis.com/cri-containerd-release)で確認するようにしてください。 - -```shell -# 必要な環境変数をexportします。 -export CONTAINERD_VERSION="1.1.2" -export CONTAINERD_SHA256="d4ed54891e90a5d1a45e3e96464e2e8a4770cd380c21285ef5c9895c40549218" - -# containerdのtarボールをダウンロードします。 -wget https://storage.googleapis.com/cri-containerd-release/cri-containerd-${CONTAINERD_VERSION}.linux-amd64.tar.gz - -# ハッシュ値をチェックします。 -echo "${CONTAINERD_SHA256} cri-containerd-${CONTAINERD_VERSION}.linux-amd64.tar.gz" | sha256sum --check - - -# 解凍して展開します。 -tar --no-overwrite-dir -C / -xzf cri-containerd-${CONTAINERD_VERSION}.linux-amd64.tar.gz - -# containerdを起動します。 -systemctl start containerd -``` +`systemd`のcgroupドライバーを使うには、`/etc/containerd/config.toml`内で`plugins.cri.systemd_cgroup = true`を設定してください。 +kubeadmを使う場合は[kubeletのためのcgroupドライバー](/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#マスターノードのkubeletによって使用されるcgroupドライバーの設定)を手動で設定してください。 ## その他のCRIランタイム: frakti diff --git a/content/ja/docs/setup/production-environment/on-premises-vm/_index.md b/content/ja/docs/setup/production-environment/on-premises-vm/_index.md index a8dcf3523c..6de2892840 100644 --- a/content/ja/docs/setup/production-environment/on-premises-vm/_index.md +++ b/content/ja/docs/setup/production-environment/on-premises-vm/_index.md @@ -1,4 +1,4 @@ --- title: オンプレミスVM -weight: 60 +weight: 40 --- diff --git a/content/ja/docs/setup/production-environment/on-premises-vm/dcos.md b/content/ja/docs/setup/production-environment/on-premises-vm/dcos.md index a41309d23b..d869b2fe90 100644 --- a/content/ja/docs/setup/production-environment/on-premises-vm/dcos.md +++ b/content/ja/docs/setup/production-environment/on-premises-vm/dcos.md @@ -5,7 +5,7 @@ content_type: concept -Mesosphereは[DC/OS](https://mesosphere.com/product/)上にKubernetesを構築する為の簡単な選択肢を提供します。それは +Mesosphereは[DC/OS](https://mesosphere.com/product/)上にKubernetesを構築するための簡単な選択肢を提供します。それは * 純粋なアップストリームのKubernetes * シングルクリッククラスター構築 diff --git a/content/ja/docs/setup/production-environment/tools/kops.md b/content/ja/docs/setup/production-environment/tools/kops.md index e0203ca097..92899a300a 100644 --- a/content/ja/docs/setup/production-environment/tools/kops.md +++ b/content/ja/docs/setup/production-environment/tools/kops.md @@ -1,6 +1,6 @@ --- title: kopsを使ったAWS上でのKubernetesのインストール -content_type: concept +content_type: task weight: 20 --- @@ -9,35 +9,40 @@ weight: 20 This quickstart shows you how to easily install a Kubernetes cluster on AWS. It uses a tool called [`kops`](https://github.com/kubernetes/kops). -kops is an opinionated provisioning system: +kops is an automated provisioning system: * Fully automated installation * Uses DNS to identify clusters * Self-healing: everything runs in Auto-Scaling Groups -* Multiple OS support (Debian, Ubuntu 16.04 supported, CentOS & RHEL, Amazon Linux and CoreOS) - see the [images.md](https://github.com/kubernetes/kops/blob/master/docs/images.md) -* High-Availability support - see the [high_availability.md](https://github.com/kubernetes/kops/blob/master/docs/high_availability.md) +* Multiple OS support (Debian, Ubuntu 16.04 supported, CentOS & RHEL, Amazon Linux and CoreOS) - see the [images.md](https://github.com/kubernetes/kops/blob/master/docs/operations/images.md) +* High-Availability support - see the [high_availability.md](https://github.com/kubernetes/kops/blob/master/docs/operations/high_availability.md) * Can directly provision, or generate terraform manifests - see the [terraform.md](https://github.com/kubernetes/kops/blob/master/docs/terraform.md) -If your opinions differ from these you may prefer to build your own cluster using [kubeadm](/docs/admin/kubeadm/) as -a building block. kops builds on the kubeadm work. + + +## {{% heading "prerequisites" %}} + + +* You must have [kubectl](/docs/tasks/tools/install-kubectl/) installed. + +* You must [install](https://github.com/kubernetes/kops#installing) `kops` on a 64-bit (AMD64 and Intel 64) device architecture. + +* You must have an [AWS account](https://docs.aws.amazon.com/polly/latest/dg/setting-up.html), generate [IAM keys](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html#access-keys-and-secret-access-keys) and [configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html#cli-quick-configuration) them. - + ## クラスタの作成 ### (1/5) kopsのインストール -#### 要件 - -You must have [kubectl](/ja/docs/tasks/tools/install-kubectl/) installed in order for kops to work. - #### インストール Download kops from the [releases page](https://github.com/kubernetes/kops/releases) (it is also easy to build from source): -On macOS: +{{< tabs name="kops_installation" >}} +{{% tab name="macOS" %}} Download the latest release with the command: @@ -45,14 +50,12 @@ Download the latest release with the command: curl -LO https://github.com/kubernetes/kops/releases/download/$(curl -s https://api.github.com/repos/kubernetes/kops/releases/latest | grep tag_name | cut -d '"' -f 4)/kops-darwin-amd64 ``` -To download a specific version, replace the +To download a specific version, replace the following portion of the command with the specific kops version. ```shell $(curl -s https://api.github.com/repos/kubernetes/kops/releases/latest | grep tag_name | cut -d '"' -f 4) ``` -portion of the command with the specific version. - For example, to download kops version v1.15.0 type: ```shell @@ -76,8 +79,8 @@ You can also install kops using [Homebrew](https://brew.sh/). ```shell brew update && brew install kops ``` - -On Linux: +{{% /tab %}} +{{% tab name="Linux" %}} Download the latest release with the command: @@ -85,11 +88,11 @@ Download the latest release with the command: curl -LO https://github.com/kubernetes/kops/releases/download/$(curl -s https://api.github.com/repos/kubernetes/kops/releases/latest | grep tag_name | cut -d '"' -f 4)/kops-linux-amd64 ``` -To download a specific version, replace the +To download a specific version of kops, replace the following portion of the command with the specific kops version. + ```shell $(curl -s https://api.github.com/repos/kubernetes/kops/releases/latest | grep tag_name | cut -d '"' -f 4) ``` -portion of the command with the specific version. For example, to download kops version v1.15.0 type: @@ -115,9 +118,13 @@ You can also install kops using [Homebrew](https://docs.brew.sh/Homebrew-on-Linu brew update && brew install kops ``` +{{% /tab %}} +{{< /tabs >}} + + ### (2/5) クラスタ用のroute53ドメインの作成 -kops uses DNS for discovery, both inside the cluster and so that you can reach the kubernetes API server +kops uses DNS for discovery, both inside the cluster and outside, so that you can reach the kubernetes API server from clients. kops has a strong opinion on the cluster name: it should be a valid DNS name. By doing so you will @@ -174,7 +181,7 @@ the S3 bucket name. ### (4/5) クラスタ設定の構築 -Run "kops create cluster" to create your cluster configuration: +Run `kops create cluster` to create your cluster configuration: `kops create cluster --zones=us-east-1c useast1.dev.example.com` @@ -213,24 +220,20 @@ for production clusters! ### 他のアドオンの参照 -See the [list of add-ons](/docs/concepts/cluster-administration/addons/) to explore other add-ons, including tools for logging, monitoring, network policy, visualization & control of your Kubernetes cluster. +See the [list of add-ons](/docs/concepts/cluster-administration/addons/) to explore other add-ons, including tools for logging, monitoring, network policy, visualization, and control of your Kubernetes cluster. ## クリーンアップ * To delete your cluster: `kops delete cluster useast1.dev.example.com --yes` -## フィードバック - -* Slack Channel: [#kops-users](https://kubernetes.slack.com/messages/kops-users/) -* [GitHub Issues](https://github.com/kubernetes/kops/issues) - ## {{% heading "whatsnext" %}} * Learn more about Kubernetes [concepts](/docs/concepts/) and [`kubectl`](/docs/user-guide/kubectl-overview/). -* Learn about `kops` [advanced usage](https://github.com/kubernetes/kops) -* See the `kops` [docs](https://github.com/kubernetes/kops) section for tutorials, best practices and advanced configuration options. +* Learn more about `kops` [advanced usage](https://kops.sigs.k8s.io/) for tutorials, best practices and advanced configuration options. +* Follow `kops` community discussions on Slack: [community discussions](https://github.com/kubernetes/kops#other-ways-to-communicate-with-the-contributors) +* Contribute to `kops` by addressing or raising an issue [GitHub Issues](https://github.com/kubernetes/kops/issues) diff --git a/content/ja/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md b/content/ja/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md index b4ff9024f6..b2b41f9128 100644 --- a/content/ja/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md +++ b/content/ja/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md @@ -35,7 +35,7 @@ kubeadmの`ClusterConfiguration`オブジェクトはAPIServer、ControllerManag 詳細は[kube-apiserverのリファレンスドキュメント](/docs/reference/command-line-tools-reference/kube-apiserver/)を参照してください。 -Example usage: +使用例: ```yaml apiVersion: kubeadm.k8s.io/v1beta2 kind: ClusterConfiguration @@ -52,7 +52,7 @@ apiServer: 詳細は[kube-controller-managerのリファレンスドキュメント](/docs/reference/command-line-tools-reference/kube-controller-manager/)を参照してください。 -Example usage: +使用例: ```yaml apiVersion: kubeadm.k8s.io/v1beta2 kind: ClusterConfiguration @@ -68,7 +68,7 @@ controllerManager: 詳細は[kube-schedulerのリファレンスドキュメント](/docs/reference/command-line-tools-reference/kube-scheduler/)を参照してください。 -Example usage: +使用例: ```yaml apiVersion: kubeadm.k8s.io/v1beta2 kind: ClusterConfiguration diff --git a/content/ja/docs/setup/production-environment/tools/kubeadm/high-availability.md b/content/ja/docs/setup/production-environment/tools/kubeadm/high-availability.md index b9e82a7838..6b7cb8b610 100644 --- a/content/ja/docs/setup/production-environment/tools/kubeadm/high-availability.md +++ b/content/ja/docs/setup/production-environment/tools/kubeadm/high-availability.md @@ -8,16 +8,14 @@ weight: 60 このページでは、kubeadmを使用して、高可用性クラスターを作成する、2つの異なるアプローチを説明します: -- 積み重なったコントロールプレーンノードを使う方法。こちらのアプローチは、必要なインフラストラクチャーが少ないです。etcdのメンバーと、コントロールプレーンノードは同じ場所に置かれます。 +- 積層コントロールプレーンノードを使う方法。こちらのアプローチは、必要なインフラストラクチャーが少ないです。etcdのメンバーと、コントロールプレーンノードは同じ場所に置かれます。 - 外部のetcdクラスターを使う方法。こちらのアプローチには、より多くのインフラストラクチャーが必要です。コントロールプレーンノードと、etcdのメンバーは分離されます。 -先へ進む前に、どちらのアプローチがアプリケーションの要件と、環境に適合するか、慎重に検討してください。[こちらの比較](/ja/docs/setup/independent/ha-topology/)が、それぞれの利点/欠点について概説しています。 +先へ進む前に、どちらのアプローチがアプリケーションの要件と、環境に適合するか、慎重に検討してください。[こちらの比較](/ja/docs/setup/production-environment/tools/kubeadm/ha-topology/)が、それぞれの利点/欠点について概説しています。 -クラスターではKubernetesのバージョン1.12以降を使用する必要があります。また、kubeadmを使用した高可用性クラスターはまだ実験的な段階であり、将来のバージョンではもっとシンプルになることに注意してください。たとえば、クラスターのアップグレードに際し問題に遭遇するかもしれません。両方のアプローチを試し、kueadmの[issue tracker](https://github.com/kubernetes/kubeadm/issues/new)で我々にフィードバックを提供してくれることを推奨します。 +高可用性クラスターの作成で問題が発生した場合は、kueadmの[issue tracker](https://github.com/kubernetes/kubeadm/issues/new)でフィードバックを提供してください。 -alpha feature gateである`HighAvailability`はv1.12で非推奨となり、v1.13で削除されたことに留意してください。 - -[高可用性クラスターのアップグレード](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-ha-1-13)も参照してください。 +[高可用性クラスターのアップグレード](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)も参照してください。 {{< caution >}} このページはクラウド上でクラスターを構築することには対応していません。ここで説明されているどちらのアプローチも、クラウド上で、LoadBalancerタイプのServiceオブジェクトや、動的なPersistentVolumeを利用して動かすことはできません。 @@ -30,8 +28,8 @@ alpha feature gateである`HighAvailability`はv1.12で非推奨となり、v1. どちらの方法でも、以下のインフラストラクチャーが必要です: -- master用に、[kubeadmの最小要件](/ja/docs/setup/independent/install-kubeadm/#before-you-begin)を満たす3台のマシン -- worker用に、[kubeadmの最小要件](/ja/docs/setup/independent/install-kubeadm/#before-you-begin)を満たす3台のマシン +- master用に、[kubeadmの最小要件](/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#始める前に)を満たす3台のマシン +- worker用に、[kubeadmの最小要件](/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#始める前に)を満たす3台のマシン - クラスター内のすべてのマシン間がフルにネットワーク接続可能であること(パブリック、もしくはプライベートネットワーク) - すべてのマシンにおいて、sudo権限 - あるデバイスから、システム内のすべてのノードに対しSSH接続できること @@ -41,22 +39,11 @@ alpha feature gateである`HighAvailability`はv1.12で非推奨となり、v1. - etcdメンバー用に、追加で3台のマシン -{{< note >}} -以下の例では、CalicoをPodネットワーキングプロバイダーとして使用します。別のネットワーキングプロバイダーを使用する場合、必要に応じてデフォルトの値を変更してください。 -{{< /note >}} - - ## 両手順における最初のステップ -{{< note >}} -コントロールプレーンや、etcdノードでのコマンドはすべてrootとして実行してください。 -{{< /note >}} - -- CalicoなどのいくつかのCNIネットワークプラグインは`192.168.0.0/16`のようなCIDRを必要としますが、Weaveなどは必要としません。[CNIネットワークドキュメント](/ja/docs/setup/independent/create-cluster-kubeadm/#pod-network)を参照してください。PodにCIDRを設定するには、`ClusterConfiguration`の`networking`オブジェクトに`podSubnet: 192.168.0.0/16`フィールドを設定してください。 - ### kube-apiserver用にロードバランサーを作成 {{< note >}} @@ -84,7 +71,181 @@ alpha feature gateである`HighAvailability`はv1.12で非推奨となり、v1. 1. 残りのコントロールプレーンノードを、ロードバランサーのターゲットグループに追加します。 -### SSHの設定 +## 積層コントロールプレーンとetcdノード + +### 最初のコントロールプレーンノードの手順 + +1. 最初のコントロールプレーンノードを初期化します: + + ```sh + sudo kubeadm init --control-plane-endpoint "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT" --upload-certs + ``` + + - `--kubernetes-version`フラグで使用するKubernetesのバージョンを設定できます。kubeadm、kubelet、kubectl、Kubernetesのバージョンを一致させることが推奨されます。 + - `--control-plane-endpoint`フラグは、ロードバランサーのIPアドレスまたはDNS名と、ポートが設定される必要があります。 + - `--upload-certs`フラグは全てのコントロールプレーンノードで共有する必要がある証明書をクラスターにアップロードするために使用されます。代わりに、コントロールプレーンノード間で手動あるいは自動化ツールを使用して証明書をコピーしたい場合は、このフラグを削除し、以下の[証明書の手動配布](#manual-certs)のセクションを参照してください。 + + {{< note >}}`kubeadm init`の`--config`フラグと`--certificate-key`フラグは混在させることはできないため、[kubeadm configuration](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2)を使用する場合は`certificateKey`フィールドを適切な場所に追加する必要があります(`InitConfiguration`と`JoinConfiguration: controlPlane`の配下)。{{< /note >}} + + {{< note >}}CalicoなどのいくつかのCNIネットワークプラグインは`192.168.0.0/16`のようなCIDRを必要としますが、Weaveなどは必要としません。[CNIネットワークドキュメント](/ja/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#pod-network)を参照してください。PodにCIDRを設定するには、`ClusterConfiguration`の`networking`オブジェクトに`podSubnet: 192.168.0.0/16`フィールドを設定してください。{{< /note >}} + + - このような出力がされます: + + ```sh + ... + You can now join any number of control-plane node by running the following command on each as a root: + kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866 --control-plane --certificate-key f8902e114ef118304e561c3ecd4d0b543adc226b7a07f675f56564185ffe0c07 + + Please note that the certificate-key gives access to cluster sensitive data, keep it secret! + As a safeguard, uploaded-certs will be deleted in two hours; If necessary, you can use kubeadm init phase upload-certs to reload certs afterward. + + Then you can join any number of worker nodes by running the following on each as root: + kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866 + ``` + + - この出力をテキストファイルにコピーします。あとで、他のコントロールプレーンノードとワーカーノードをクラスターに参加させる際に必要です。 + + - `--upload-certs`フラグを`kubeadm init`で使用すると、プライマリコントロールプレーンの証明書が暗号化されて、`kubeadm-certs` Secretにアップロードされます。 + + - 証明書を再アップロードして新しい復号キーを生成するには、すでにクラスターに参加しているコントロールプレーンノードで次のコマンドを使用します: + + ```sh + sudo kubeadm init phase upload-certs --upload-certs + ``` + + - また、後で`join`で使用できるように、`init`中にカスタムした`--certificate-key`を指定することもできます。このようなキーを生成するには、次のコマンドを使用します: + + ```sh + kubeadm alpha certs certificate-key + ``` + + {{< note >}} + `kubeadm-certs`のSecretと復号キーは2時間で期限切れとなります。 + {{< /note >}} + + {{< caution >}} + コマンド出力に記載されているように、証明書キーはクラスターの機密データへのアクセスを提供します。秘密にしてください！ + {{< /caution >}} + +1. 使用するCNIプラグインを適用します: + [こちらの手順に従い](/ja/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#pod-network)CNIプロバイダーをインストールします。該当する場合は、kubeadmの設定で指定されたPodのCIDRに対応していることを確認してください。 + + Weave Netを使用する場合の例: + + ```sh + kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')" + ``` + +1. 以下のコマンドを入力し、コンポーネントのPodが起動するのを確認します: + + ```sh + kubectl get pod -n kube-system -w + ``` + +### 残りのコントロールプレーンノードの手順 + +{{< note >}} +kubeadmバージョン1.15以降、複数のコントロールプレーンノードを並行してクラスターに参加させることができます。 +このバージョンの前は、最初のノードの初期化が完了した後でのみ、新しいコントロールプレーンノードを順番にクラスターに参加させる必要があります。 +{{< /note >}} + +追加のコントロールプレーンノード毎に、以下の手順を行います。 + +1. `kubeadm init`を最初のノードで実行した際に取得したjoinコマンドを使って、新しく追加するコントロールプレーンノードで`kubeadm join`を開始します。このようなコマンドになるはずです: + + ```sh + sudo kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866 --control-plane --certificate-key f8902e114ef118304e561c3ecd4d0b543adc226b7a07f675f56564185ffe0c07 + ``` + + - `--control-plane`フラグによって、`kubeadm join`の実行は新しいコントロールプレーンを作成します。 + - `-certificate-key ...`を指定したキーを使って、クラスターの`kubeadm-certs` Secretからダウンロードされたコントロールプレーンの証明書が復号されます。 + +## 外部のetcdノード + +外部のetcdノードを使ったクラスターの設定は、積層etcdの場合と似ていますが、最初にetcdを設定し、kubeadmの設定ファイルにetcdの情報を渡す必要があります。 + +### etcdクラスターの構築 + +1. [こちらの手順](/ja/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/)にしたがって、etcdクラスターを構築してください。 + +1. [こちらの手順](#manual-certs)にしたがって、SSHを構築してください。 + +1. 以下のファイルをクラスター内の任意のetcdノードから最初のコントロールプレーンノードにコピーしてください: + + ```sh + export CONTROL_PLANE="ubuntu@10.0.0.7" + scp /etc/kubernetes/pki/etcd/ca.crt "${CONTROL_PLANE}": + scp /etc/kubernetes/pki/apiserver-etcd-client.crt "${CONTROL_PLANE}": + scp /etc/kubernetes/pki/apiserver-etcd-client.key "${CONTROL_PLANE}": + ``` + + - `CONTROL_PLANE`の値を、最初のコントロールプレーンノードの`user@host`で置き換えます。 + +### 最初のコントロールプレーンノードの構築 + +1. 以下の内容で、`kubeadm-config.yaml`という名前の設定ファイルを作成します: + + apiVersion: kubeadm.k8s.io/v1beta2 + kind: ClusterConfiguration + kubernetesVersion: stable + controlPlaneEndpoint: "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT" + etcd: + external: + endpoints: + - https://ETCD_0_IP:2379 + - https://ETCD_1_IP:2379 + - https://ETCD_2_IP:2379 + caFile: /etc/kubernetes/pki/etcd/ca.crt + certFile: /etc/kubernetes/pki/apiserver-etcd-client.crt + keyFile: /etc/kubernetes/pki/apiserver-etcd-client.key + + {{< note >}} + ここで、積層etcdと外部etcdの違いは、外部etcdの構成では`etcd`の`external`オブジェクトにetcdのエンドポイントが記述された設定ファイルが必要です。積層etcdトポロジーの場合、これは自動で管理されます。 + {{< /note >}} + + - テンプレート内の以下の変数を、クラスターに合わせて適切な値に置き換えます: + + - `LOAD_BALANCER_DNS` + - `LOAD_BALANCER_PORT` + - `ETCD_0_IP` + - `ETCD_1_IP` + - `ETCD_2_IP` + +以下の手順は、積層etcdの構築と同様です。 + +1. `sudo kubeadm init --config kubeadm-config.yaml --upload-certs`をこのノードで実行します。 + +1. 表示されたjoinコマンドを、あとで使うためにテキストファイルに書き込みます。 + +1. 使用するCNIプラグインを適用します。以下はWeave CNIの場合です: + + ```sh + kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')" + ``` + +### 残りのコントロールプレーンノードの手順 + +手順は、積層etcd構築の場合と同じです: + +- 最初のコントロールプレーンノードが完全に初期化されているのを確認します。 +- テキストファイルに保存したjoinコマンドを使って、それぞれのコントロールプレーンノードをクラスターへ参加させます。コントロールプレーンノードは1台ずつクラスターへ参加させるのを推奨します。 +- `--certificate-key`で指定する復号キーは、デフォルトで2時間で期限切れになることを忘れないでください。 + +## コントロールプレーン起動後の共通タスク + +### workerのインストール + +`kubeadm init`コマンドから返されたコマンドを利用して、workerノードをクラスターに参加させることが可能です。 + +```sh +sudo kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866 +``` + +## 証明書の手動配布 {#manual-certs} + +`--upload-certs`フラグを指定して`kubeadm init`を実行しない場合、プライマリコントロールプレーンノードから他のコントロールプレーンノードへ証明書を手動でコピーする必要があります。 + +コピーを行うには多くの方法があります。次の例では`ssh`と`scp`を使用しています。 1台のマシンから全てのノードをコントロールしたいのであれば、SSHが必要です。 @@ -114,61 +275,12 @@ alpha feature gateである`HighAvailability`はv1.12で非推奨となり、v1. sudo -E -s ``` -## 積み重なったコントロールプレーンとetcdノード +1. 全てのノードでSSHを設定したら、`kubeadm init`を実行した後、最初のコントロールノードプレーンノードで次のスクリプトを実行します。このスクリプトは、最初のコントロールプレーンノードから残りのコントロールプレーンノードへ証明書ファイルをコピーします: -### 最初のコントロールプレーンノードの手順 - -1. 最初のコントロールプレーンノードで、`kubeadm-config.yaml`という設定ファイルを作成します: - - apiVersion: kubeadm.k8s.io/v1beta1 - kind: ClusterConfiguration - kubernetesVersion: stable - apiServer: - certSANs: - - "LOAD_BALANCER_DNS" - controlPlaneEndpoint: "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT" - - - `kubernetesVersion`には使用するKubernetesのバージョンを設定します。この例では`stable`を使用しています。 - - `controlPlaneEndpoint` はロードバランサーのアドレスかDNSと、ポートに一致する必要があります。 - - kubeadm、kubelet、kubectlとKubernetesのバージョンを一致させることが推奨されます。 - -1. ノードがきれいな状態であることを確認します: + 次の例の、`CONTROL_PLANE_IPS`を他のコントロールプレーンノードのIPアドレスに置き換えます。 ```sh - sudo kubeadm init --config=kubeadm-config.yaml - ``` - - このような出力がされます: - - ```sh - ... - You can now join any number of machines by running the following on each node - as root: - - kubeadm join 192.168.0.200:6443 --token j04n3m.octy8zely83cy2ts --discovery-token-ca-cert-hash sha256:84938d2a22203a8e56a787ec0c6ddad7bc7dbd52ebabc62fd5f4dbea72b14d1f - ``` - -1. この出力をテキストファイルにコピーします。あとで、他のコントロールプレーンノードをクラスターに参加させる際に必要になります。 - -1. Weave CNIプラグインをapplyします: - - ```sh - kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')" - ``` - -1. 以下のコマンドを入力し、コンポーネントのPodが起動するのを確認します: - - ```sh - kubectl get pod -n kube-system -w - ``` - - - 最初のコントロールプレーンノードが初期化を完了してから、新しいノードを参加させることが推奨されます。 - -1. 証明書ファイルを最初のコントロールプレーンノードから残りのノードにコピーします: - - 以下の例では、`CONTROL_PLANE_IPS`を他のコントロールプレーンノードのIPアドレスで置き換えます。 - ```sh - USER=ubuntu # 変更可能 + USER=ubuntu # 環境に合わせる CONTROL_PLANE_IPS="10.0.0.7 10.0.0.8" for host in ${CONTROL_PLANE_IPS}; do scp /etc/kubernetes/pki/ca.crt "${USER}"@$host: @@ -178,21 +290,19 @@ alpha feature gateである`HighAvailability`はv1.12で非推奨となり、v1. scp /etc/kubernetes/pki/front-proxy-ca.crt "${USER}"@$host: scp /etc/kubernetes/pki/front-proxy-ca.key "${USER}"@$host: scp /etc/kubernetes/pki/etcd/ca.crt "${USER}"@$host:etcd-ca.crt + # 外部のetcdノード使用時はこちらのコマンドを実行 scp /etc/kubernetes/pki/etcd/ca.key "${USER}"@$host:etcd-ca.key - scp /etc/kubernetes/admin.conf "${USER}"@$host: done ``` -{{< caution >}} -上のリストにある証明書だけをコピーしてください。kubeadmが、参加するコントロールプレーンノード用に、残りの証明書と必要なSANの生成を行います。間違って全ての証明書をコピーしてしまったら、必要なSANがないため、追加ノードの作成は失敗するかもしれません。 -{{< /caution >}} + {{< caution >}} + 上のリストにある証明書だけをコピーしてください。kubeadmが、参加するコントロールプレーンノード用に、残りの証明書と必要なSANの生成を行います。間違って全ての証明書をコピーしてしまったら、必要なSANがないため、追加ノードの作成は失敗するかもしれません。 + {{< /caution >}} -### 残りのコントロールプレーンノードの手順 - -1. `scp`を使用する手順で作成したファイルを移動します: +1. 次に、クラスターに参加させる残りの各コントロールプレーンノードで`kubeadm join`を実行する前に次のスクリプトを実行する必要があります。このスクリプトは、前の手順でコピーした証明書をホームディレクトリから`/etc/kubernetes/pki`へ移動します: ```sh - USER=ubuntu # 変更可能 + USER=ubuntu # 環境に合わせる mkdir -p /etc/kubernetes/pki/etcd mv /home/${USER}/ca.crt /etc/kubernetes/pki/ mv /home/${USER}/ca.key /etc/kubernetes/pki/ @@ -201,103 +311,6 @@ alpha feature gateである`HighAvailability`はv1.12で非推奨となり、v1. mv /home/${USER}/front-proxy-ca.crt /etc/kubernetes/pki/ mv /home/${USER}/front-proxy-ca.key /etc/kubernetes/pki/ mv /home/${USER}/etcd-ca.crt /etc/kubernetes/pki/etcd/ca.crt + # 外部のetcdノード使用時はこちらのコマンドを実行 mv /home/${USER}/etcd-ca.key /etc/kubernetes/pki/etcd/ca.key - mv /home/${USER}/admin.conf /etc/kubernetes/admin.conf ``` - - この手順で、`/etc/kubernetes`フォルダーに必要な全てのファイルが書き込まれます。 - -1. `kubeadm init`を最初のノードで実行した際に取得したjoinコマンドを使って、このノードで`kubeadm join`を開始します。このようなコマンドになるはずです: - - ```sh - sudo kubeadm join 192.168.0.200:6443 --token j04n3m.octy8zely83cy2ts --discovery-token-ca-cert-hash sha256:84938d2a22203a8e56a787ec0c6ddad7bc7dbd52ebabc62fd5f4dbea72b14d1f --experimental-control-plane - ``` - - `--experimental-control-plane`フラグが追加されています。このフラグは、コントロールプレーンノードのクラスターへの参加を自動化します。 - -1. 以下のコマンドをタイプし、コンポーネントのPodが起動するのを確認します: - - ```sh - kubectl get pod -n kube-system -w - ``` - -1. これらのステップを、残りのコントロールプレーンノードに対して繰り返します。 - -## 外部のetcdノード - -### etcdクラスターの構築 - -- [こちらの手順](/ja/docs/setup/independent/setup-ha-etcd-with-kubeadm/)にしたがって、etcdクラスターを構築してください。 - -### 最初のコントロールプレーンノードの構築 - -1. 以下のファイルをetcdクラスターのどれかのノードからこのノードへコピーしてください: - - ```sh - export CONTROL_PLANE="ubuntu@10.0.0.7" - +scp /etc/kubernetes/pki/etcd/ca.crt "${CONTROL_PLANE}": - +scp /etc/kubernetes/pki/apiserver-etcd-client.crt "${CONTROL_PLANE}": - +scp /etc/kubernetes/pki/apiserver-etcd-client.key "${CONTROL_PLANE}": - ``` - - - `CONTROL_PLANE`の値を、このマシンの`user@host`で置き換えます。 - -1. 以下の内容で、`kubeadm-config.yaml`という名前の設定ファイルを作成します: - - apiVersion: kubeadm.k8s.io/v1beta1 - kind: ClusterConfiguration - kubernetesVersion: stable - apiServer: - certSANs: - - "LOAD_BALANCER_DNS" - controlPlaneEndpoint: "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT" - etcd: - external: - endpoints: - - https://ETCD_0_IP:2379 - - https://ETCD_1_IP:2379 - - https://ETCD_2_IP:2379 - caFile: /etc/kubernetes/pki/etcd/ca.crt - certFile: /etc/kubernetes/pki/apiserver-etcd-client.crt - keyFile: /etc/kubernetes/pki/apiserver-etcd-client.key - - - ここで、積み重なったetcdと外部etcdの違いは、kubeadmコンフィグの`etcd`に`external`フィールドを使用していることです。積み重なったetcdトポロジーの場合、これは自動で管理されます。 - - - テンプレート内の以下の変数を、クラスターに合わせて適切な値に置き換えます: - - - `LOAD_BALANCER_DNS` - - `LOAD_BALANCER_PORT` - - `ETCD_0_IP` - - `ETCD_1_IP` - - `ETCD_2_IP` - -1. `kubeadm init --config kubeadm-config.yaml`をこのノードで実行します。 - -1. 表示されたjoinコマンドを、あとで使うためにテキストファイルに書き込みます。 - -1. Weave CNIプラグインをapplyします: - - ```sh - kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')" - ``` - -### 残りのコントロールプレーンノードの手順 - -残りのコントロールプレーンノードを参加させるために、[こちらの手順](#残りのコントロールプレーンノードの手順)に従います。ローカルetcdメンバーが作られないことを除いて、積み重なったetcdの構築と同じ手順です。 - -まとめると: - -- 最初のコントロールプレーンノードが完全に初期化されているのを確認します。 -- 証明書を、最初のコントロールプレーンノードから他のコントロールプレーンノードへコピーします。 -- テキストファイルに保存したjoinコマンドに`--experimental-control-plane` フラグを加えたものを使って、それぞれのコントロールプレーンノードを参加させます。 - -## コントロールプレーン起動後の共通タスク - -### Podネットワークのインストール - -Podネットワークをインストールするには、[こちらの手順に従ってください](/ja/docs/setup/independent/create-cluster-kubeadm/#pod-network)。master設定ファイルで提供したPod CIDRのどれかに一致することを確認します。 - -### workerのインストール - -`kubeadm init`コマンドから返されたコマンドを利用して、workerノードをクラスターに参加させることが可能です。workerノードには、`--experimental-control-plane`フラグを追加する必要はありません。 - - diff --git a/content/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md b/content/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md index b03166af12..155ce30fd1 100644 --- a/content/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md +++ b/content/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md @@ -1,7 +1,7 @@ --- title: kubeadmのインストール content_type: task -weight: 20 +weight: 10 card: name: setup weight: 20 @@ -11,13 +11,13 @@ card: + このページでは`kubeadm`コマンドをインストールする方法を示します。このインストール処理実行後にkubeadmを使用してクラスターを作成する方法については、[kubeadmを使用したシングルマスタークラスターの作成](/ja/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/)を参照してください。 ## {{% heading "prerequisites" %}} - * 次のいずれかが動作しているマシンが必要です - Ubuntu 16.04+ - Debian 9+ @@ -48,6 +48,22 @@ card: 複数のネットワークアダプターがあり、Kubernetesコンポーネントにデフォルトで到達できない場合、IPルートを追加して、Kubernetesクラスターのアドレスが適切なアダプターを経由するように設定することをお勧めします。 +## iptablesがブリッジを通過するトラフィックを処理できるようにする + +Linuxノードのiptablesがブリッジを通過するトラフィックを正確に処理する要件として、`net.bridge.bridge-nf-call-iptables`を`sysctl`の設定ファイルで1に設定してください。例えば以下のようにします。 + +```bash +cat < /etc/sysctl.d/k8s.conf +net.bridge.bridge-nf-call-ip6tables = 1 +net.bridge.bridge-nf-call-iptables = 1 +EOF +sysctl --system +``` + +この手順の前に`br_netfilter`モジュールがロードされていることを確認してください。`lsmod | grep br_netfilter`を実行することで確認できます。明示的にロードするには`modprobe br_netfilter`を実行してください。 + +詳細は[ネットワークプラグインの要件](https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#network-plugin-requirements)を参照してください。 + ## iptablesがnftablesバックエンドを使用しないようにする Linuxでは、カーネルのiptablesサブシステムの最新の代替品としてnftablesが利用できます。`iptables`ツールは互換性レイヤーとして機能し、iptablesのように動作しますが、実際にはnftablesを設定します。このnftablesバックエンドは現在のkubeadmパッケージと互換性がありません。(ファイアウォールルールが重複し、`kube-proxy`を破壊するためです。) @@ -55,11 +71,12 @@ Linuxでは、カーネルのiptablesサブシステムの最新の代替品と もしあなたのシステムの`iptables`ツールがnftablesバックエンドを使用している場合、これらの問題を避けるために`iptables`ツールをレガシーモードに切り替える必要があります。これは、少なくともDebian 10(Buster)、Ubuntu 19.04、Fedora 29、およびこれらのディストリビューションの新しいリリースでのデフォルトです。RHEL 8はレガシーモードへの切り替えをサポートしていないため、現在のkubeadmパッケージと互換性がありません。 {{< tabs name="iptables_legacy" >}} -{{% tab name="Debian or Ubuntu" %}} +{{% tab name="DebianまたはUbuntu" %}} ```bash # レガシーバイナリがインストールされていることを確認してください sudo apt-get install -y iptables arptables ebtables +# レガシーバージョンに切り替えてください。 sudo update-alternatives --set iptables /usr/sbin/iptables-legacy sudo update-alternatives --set ip6tables /usr/sbin/ip6tables-legacy sudo update-alternatives --set arptables /usr/sbin/arptables-legacy @@ -75,56 +92,66 @@ update-alternatives --set iptables /usr/sbin/iptables-legacy ## 必須ポートの確認 -### マスターノード +### コントロールプレーンノード | プロトコル | 通信の向き | ポート範囲 | 目的 | 使用者 | |-----------|------------|------------|-------------------------|---------------------------| -| TCP | Inbound | 6443* | Kubernetes API server | All | -| TCP | Inbound | 2379-2380 | etcd server client API | kube-apiserver, etcd | -| TCP | Inbound | 10250 | Kubelet API | Self, Control plane | -| TCP | Inbound | 10251 | kube-scheduler | Self | -| TCP | Inbound | 10252 | kube-controller-manager | Self | +| TCP | Inbound | 6443* | Kubernetes API server | 全て | +| TCP | Inbound | 2379-2380 | etcd server client API | kube-apiserver、etcd | +| TCP | Inbound | 10250 | Kubelet API | 自身、コントロールプレーン | +| TCP | Inbound | 10251 | kube-scheduler | 自身 | +| TCP | Inbound | 10252 | kube-controller-manager | 自身 | ### ワーカーノード -| プロトコル | 通信の向き | ポート範囲 | 目的 | 使用者 | -|-----------|------------|-------------|-------------------------|-------------------------| -| TCP | Inbound | 10250 | Kubelet API | Self, Control plane | -| TCP | Inbound | 30000-32767 | NodePort Services** | All | +| プロトコル | 通信の向き | ポート範囲 | 目的 | 使用者 | +|-----------|------------|-------------|-------------------------|---------------------------| +| TCP | Inbound | 10250 | Kubelet API | 自身、コントロールプレーン | +| TCP | Inbound | 30000-32767 | NodePort Service† | 全て | -** [NodePort Services](/ja/docs/concepts/services-networking/service/)のデフォルトのポートの範囲 +† [NodePort Service](/ja/docs/concepts/services-networking/service/)のデフォルトのポートの範囲 \*の項目は書き換え可能です。そのため、あなたが指定したカスタムポートも開いていることを確認する必要があります。 etcdポートはコントロールプレーンノードに含まれていますが、独自のetcdクラスターを外部またはカスタムポートでホストすることもできます。 -使用するPodネットワークプラグイン（以下を参照）のポートも開く必要があります。これは各Podネットワークプラグインによって異なるため、必要なポートについてはプラグインのドキュメントを参照してください。 +使用するPodネットワークプラグイン(以下を参照)のポートも開く必要があります。これは各Podネットワークプラグインによって異なるため、必要なポートについてはプラグインのドキュメントを参照してください。 ## ランタイムのインストール {#installing-runtime} -v1.6.0以降、KubernetesはデフォルトでCRI(Container Runtime Interface)の使用を有効にしています。 +Podのコンテナを実行するために、Kubernetesは{{< glossary_tooltip term_id="container-runtime" text="コンテナランタイム" >}}を使用します。 -また、v1.14.0以降、kubeadmは既知のドメインソケットのリストをスキャンして、Linuxノード上のコンテナランタイムを自動的に検出しようとします。検出可能なランタイムとソケットパスは、以下の表に記載されています。 +{{< tabs name="container_runtime" >}} +{{% tab name="Linuxノード" %}} -| ランタイム | ドメインソケット | -|------------|----------------------------------| -| Docker | /var/run/docker.sock | -| containerd | /run/containerd/containerd.sock | -| CRI-O | /var/run/crio/crio.sock | +デフォルトでは、Kubernetesは選択されたコンテナランタイムと通信するために{{< glossary_tooltip term_id="cri" text="Container Runtime Interface">}} (CRI)を使用します。 +ランタイムを指定しない場合、kubeadmはよく知られたUnixドメインソケットのリストをスキャンすることで、インストールされたコンテナランタイムの検出を試みます。 +次の表がコンテナランタイムと関連するソケットのパスリストです。 + +{{< table caption = "コンテナランタイムとソケットパス" >}} +| ランタイム | Unixドメインソケットのパス | +|------------|-----------------------------------| +| Docker | `/var/run/docker.sock` | +| containerd | `/run/containerd/containerd.sock` | +| CRI-O | `/var/run/crio/crio.sock` | +{{< /table >}} + +
Dockerとcontainerdの両方が同時に検出された場合、Dockerが優先されます。Docker 18.09にはcontainerdが同梱されており、両方が検出可能であるため、この仕様が必要です。他の2つ以上のランタイムが検出された場合、kubeadmは適切なエラーメッセージで終了します。 -Linux以外のノードでは、デフォルトで使用されるコンテナランタイムはDockerです。 +kubeletは、組み込まれた`dockershim`CRIを通してDockerと連携します。 -もしコンテナランタイムとしてDockerを選択した場合、`kebelet`内に組み込まれた`dockershim` CRIが使用されます。 +詳細は、[コンテナランタイム](/ja/docs/setup/production-environment/container-runtimes/)を参照してください。 +{{% /tab %}} +{{% tab name="その他のOS" %}} +デフォルトでは、kubeadmは{{< glossary_tooltip term_id="docker" >}}をコンテナランタイムとして使用します。 +kubeletは、組み込まれた`dockershim`CRIを通してDockerと連携します。 -その他のCRIに基づくランタイムでは以下を使用します +詳細は、[コンテナランタイム](/ja/docs/setup/production-environment/container-runtimes/)を参照してください。 +{{% /tab %}} +{{< /tabs >}} -- [containerd](https://github.com/containerd/cri) (CRI plugin built into containerd) -- [cri-o](https://cri-o.io/) -- [frakti](https://github.com/kubernetes/frakti) - -詳細は[CRIのインストール](/ja/docs/setup/production-environment/container-runtimes/)を参照してください。 ## kubeadm、kubelet、kubectlのインストール @@ -142,7 +169,7 @@ kubeadmは`kubelet`や`kubectl`をインストールまたは管理**しない** `kubectl`のインストールに関する詳細情報は、[kubectlのインストールおよびセットアップ](/ja/docs/tasks/tools/install-kubectl/)を参照してください。 {{< warning >}} -これらの手順はシステムアップグレードによるすべてのKubernetesパッケージの更新を除きます。これはkubeadmとKubernetesが[アップグレードにおける特別な注意](docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)を必要とするからです。 +これらの手順はシステムアップグレードによるすべてのKubernetesパッケージの更新を除きます。これはkubeadmとKubernetesが[アップグレードにおける特別な注意](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)を必要とするからです。 {{}} バージョン差異(version skew)に関しては下記を参照してください。 @@ -151,7 +178,7 @@ kubeadmは`kubelet`や`kubectl`をインストールまたは管理**しない** * Kubeadm-specific [バージョン互換ポリシー](/ja/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#version-skew-policy) {{< tabs name="k8s_install" >}} -{{% tab name="Ubuntu, Debian or HypriotOS" %}} +{{% tab name="Ubuntu、Debian、またはHypriotOS" %}} ```bash sudo apt-get update && sudo apt-get install -y apt-transport-https curl curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add - @@ -163,7 +190,7 @@ sudo apt-get install -y kubelet kubeadm kubectl sudo apt-mark hold kubelet kubeadm kubectl ``` {{% /tab %}} -{{% tab name="CentOS, RHEL or Fedora" %}} +{{% tab name="CentOS、RHEL、またはFedora" %}} ```bash cat < /etc/yum.repos.d/kubernetes.repo [kubernetes] @@ -175,7 +202,7 @@ repo_gpgcheck=1 gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg EOF -# Set SELinux in permissive mode (effectively disabling it) +# SELinuxをpermissiveモードに設定する(効果的に無効化する) setenforce 0 sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config @@ -186,23 +213,13 @@ systemctl enable --now kubelet **Note:** - - Setting SELinux in permissive mode by running `setenforce 0` and `sed ...` effectively disables it. - This is required to allow containers to access the host filesystem, which is needed by pod networks for example. - You have to do this until SELinux support is improved in the kubelet. - - Some users on RHEL/CentOS 7 have reported issues with traffic being routed incorrectly due to iptables being bypassed. You should ensure - `net.bridge.bridge-nf-call-iptables` is set to 1 in your `sysctl` config, e.g. + - `setenforce 0`および`sed ...`を実行することによりSELinuxをpermissiveモードに設定し、効果的に無効化できます。 + これはコンテナがホストのファイルシステムにアクセスするために必要です。例えば、Podのネットワークに必要とされます。 + kubeletにおけるSELinuxのサポートが改善されるまでは、これを実行しなければなりません。 - ```bash - cat < /etc/sysctl.d/k8s.conf - net.bridge.bridge-nf-call-ip6tables = 1 - net.bridge.bridge-nf-call-iptables = 1 - EOF - sysctl --system - ``` - - Make sure that the `br_netfilter` module is loaded before this step. This can be done by running `lsmod | grep br_netfilter`. To load it explicitly call `modprobe br_netfilter`. {{% /tab %}} {{% tab name="Container Linux" %}} -Install CNI plugins (required for most pod network): +CNIプラグインをインストールする(ほとんどのPodのネットワークに必要です): ```bash CNI_VERSION="v0.8.2" @@ -210,7 +227,7 @@ mkdir -p /opt/cni/bin curl -L "https://github.com/containernetworking/plugins/releases/download/${CNI_VERSION}/cni-plugins-linux-amd64-${CNI_VERSION}.tgz" | tar -C /opt/cni/bin -xz ``` -Install crictl (required for kubeadm / Kubelet Container Runtime Interface (CRI)) +crictlをインストールする (kubeadm / Kubelet Container Runtime Interface (CRI)に必要です) ```bash CRICTL_VERSION="v1.16.0" @@ -218,7 +235,7 @@ mkdir -p /opt/bin curl -L "https://github.com/kubernetes-sigs/cri-tools/releases/download/${CRICTL_VERSION}/crictl-${CRICTL_VERSION}-linux-amd64.tar.gz" | tar -C /opt/bin -xz ``` -Install `kubeadm`, `kubelet`, `kubectl` and add a `kubelet` systemd service: +`kubeadm`、`kubelet`、`kubectl`をインストールし`kubelet`をsystemd serviceに登録します: ```bash RELEASE="$(curl -sSL https://dl.k8s.io/release/stable.txt)" @@ -233,7 +250,7 @@ mkdir -p /etc/systemd/system/kubelet.service.d curl -sSL "https://raw.githubusercontent.com/kubernetes/kubernetes/${RELEASE}/build/debs/10-kubeadm.conf" | sed "s:/usr/bin:/opt/bin:g" > /etc/systemd/system/kubelet.service.d/10-kubeadm.conf ``` -Enable and start `kubelet`: +`kubelet`を有効化し起動します: ```bash systemctl enable --now kubelet @@ -243,7 +260,7 @@ systemctl enable --now kubelet kubeadmが何をすべきか指示するまで、kubeletはクラッシュループで数秒ごとに再起動します。 -## マスターノードのkubeletによって使用されるcgroupドライバーの設定 +## コントロールプレーンノードのkubeletによって使用されるcgroupドライバーの設定 Dockerを使用した場合、kubeadmは自動的にkubelet向けのcgroupドライバーを検出し、それを実行時に`/var/lib/kubelet/kubeadm-flags.env`ファイルに設定します。 @@ -255,7 +272,7 @@ KUBELET_EXTRA_ARGS=--cgroup-driver= このファイルは、kubeletの追加のユーザー定義引数を取得するために、`kubeadm init`および`kubeadm join`によって使用されます。 -CRIのcgroupドライバーが`cgroupfs`でない場合に**のみ**それを行う必要があることに注意してください。なぜなら、これは既にkubeletのデフォルト値であるためです。 +CRIのcgroupドライバーが`cgroupfs`でない場合に**のみ**それを行う必要があることに注意してください。なぜなら、これはすでにkubeletのデフォルト値であるためです。 kubeletをリスタートする方法: @@ -274,5 +291,3 @@ kubeadmで問題が発生した場合は、[トラブルシューティング](/ * [kubeadmを使用したシングルコントロールプレーンクラスターの作成](/ja/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) - - diff --git a/content/ja/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md b/content/ja/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md index 4aa6d44ecb..e061315381 100644 --- a/content/ja/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md +++ b/content/ja/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md @@ -8,21 +8,11 @@ weight: 80 {{< feature-state for_k8s_version="1.11" state="stable" >}} -The lifecycle of the kubeadm CLI tool is decoupled from the -[kubelet](/docs/reference/command-line-tools-reference/kubelet), which is a daemon that runs -on each node within the Kubernetes cluster. The kubeadm CLI tool is executed by the user when Kubernetes is -initialized or upgraded, whereas the kubelet is always running in the background. +kubeadm CLIツールのライフサイクルは、Kubernetesクラスター内の各ノード上で稼働するデーモンである[kubelet](/docs/reference/command-line-tools-reference/kubelet)から分離しています。kubeadm CLIツールはKubernetesを初期化またはアップグレードする際にユーザーによって実行されます。一方で、kubeletは常にバックグラウンドで稼働しています。 -Since the kubelet is a daemon, it needs to be maintained by some kind of a init -system or service manager. When the kubelet is installed using DEBs or RPMs, -systemd is configured to manage the kubelet. You can use a different service -manager instead, but you need to configure it manually. +kubeletはデーモンのため、何らかのinitシステムやサービスマネージャーで管理する必要があります。DEBパッケージやRPMパッケージからkubeletをインストールすると、systemdはkubeletを管理するように設定されます。代わりに別のサービスマネージャーを使用することもできますが、手動で設定する必要があります。 -Some kubelet configuration details need to be the same across all kubelets involved in the cluster, while -other configuration aspects need to be set on a per-kubelet basis, to accommodate the different -characteristics of a given machine, such as OS, storage, and networking. You can manage the configuration -of your kubelets manually, but [kubeadm now provides a `KubeletConfiguration` API type for managing your -kubelet configurations centrally](#configure-kubelets-using-kubeadm). +いくつかのkubeletの設定は、クラスターに含まれる全てのkubeletで同一である必要があります。一方で、特定のマシンの異なる特性(OS、ストレージ、ネットワークなど)に対応するために、kubeletごとに設定が必要なものもあります。手動で設定を管理することも可能ですが、kubeadmは[一元的な設定管理](#configure-kubelets-using-kubeadm)のための`KubeletConfiguration`APIを提供しています。 @@ -30,29 +20,19 @@ kubelet configurations centrally](#configure-kubelets-using-kubeadm). ## Kubeletの設定パターン -The following sections describe patterns to kubelet configuration that are simplified by -using kubeadm, rather than managing the kubelet configuration for each Node manually. +以下のセクションでは、kubeadmを使用したkubeletの設定パターンについて説明します。これは手動で各Nodeの設定を管理するよりも簡易に行うことができます。 -### 各kubeletにクラスターレベルの設定を配布 +### 各kubeletにクラスターレベルの設定を配布 {#propagating-cluster-level-configuration-to-each-kubelet} -You can provide the kubelet with default values to be used by `kubeadm init` and `kubeadm join` -commands. Interesting examples include using a different CRI runtime or setting the default subnet -used by services. +`kubeadm init`および`kubeadm join`コマンドを使用すると、kubeletにデフォルト値を設定することができます。興味深い例として、異なるCRIランタイムを使用したり、Serviceが使用するデフォルトのサブネットを設定したりすることができます。 -If you want your services to use the subnet `10.96.0.0/12` as the default for services, you can pass -the `--service-cidr` parameter to kubeadm: +Serviceが使用するデフォルトのサブネットとして`10.96.0.0/12`を設定する必要がある場合は、`--service-cidr`パラメーターを渡します。 ```bash kubeadm init --service-cidr 10.96.0.0/12 ``` -Virtual IPs for services are now allocated from this subnet. You also need to set the DNS address used -by the kubelet, using the `--cluster-dns` flag. This setting needs to be the same for every kubelet -on every manager and Node in the cluster. The kubelet provides a versioned, structured API object -that can configure most parameters in the kubelet and push out this configuration to each running -kubelet in the cluster. This object is called **the kubelet's ComponentConfig**. -The ComponentConfig allows the user to specify flags such as the cluster DNS IP addresses expressed as -a list of values to a camelCased key, illustrated by the following example: +これによってServiceの仮想IPはこのサブネットから割り当てられるようになりました。また、`--cluster-dns`フラグを使用し、kubeletが用いるDNSアドレスを設定する必要もあります。この設定はクラスター内の全てのマネージャーとNode上で同一である必要があります。kubeletは、**kubeletのComponentConfig**と呼ばれる、バージョン管理と構造化されたAPIオブジェクトを提供します。これはkubelet内のほとんどのパラメーターを設定し、その設定をクラスター内で稼働中の各kubeletへ適用することを可能にします。以下の例のように、キャメルケースのキーに値のリストとしてクラスターDNS IPアドレスなどのフラグを指定することができます。 ```yaml apiVersion: kubelet.config.k8s.io/v1beta1 @@ -61,109 +41,72 @@ clusterDNS: - 10.96.0.10 ``` -For more details on the ComponentConfig have a look at [this section](#configure-kubelets-using-kubeadm). +ComponentConfigの詳細については、[このセクション](#configure-kubelets-using-kubeadm)をご覧ください -### インスタンス固有の設定内容を適用 +### インスタンス固有の設定内容を適用 {#providing-instance-specific-configuration-details} -Some hosts require specific kubelet configurations, due to differences in hardware, operating system, -networking, or other host-specific parameters. The following list provides a few examples. +いくつかのホストでは、ハードウェア、オペレーティングシステム、ネットワーク、その他ホスト固有のパラメータの違いのため、特定のkubeletの設定を必要とします。以下にいくつかの例を示します。 -- The path to the DNS resolution file, as specified by the `--resolv-conf` kubelet - configuration flag, may differ among operating systems, or depending on whether you are using - `systemd-resolved`. If this path is wrong, DNS resolution will fail on the Node whose kubelet - is configured incorrectly. +- DNS解決ファイルへのパスは`--resolv-conf`フラグで指定することができますが、オペレーティングシステムや`systemd-resolved`を使用するかどうかによって異なる場合があります。このパスに誤りがある場合、そのNode上でのDNS解決は失敗します。 +- クラウドプロバイダーを使用していない場合、Node APIオブジェクト`.metadata.name`はデフォルトでマシンのホスト名に設定されます。異なるNode名を指定する必要がある場合には、`--hostname-override`フラグによってこの挙動を書き換えることができます。 +- 現在のところ、kubletはCRIランタイムが使用するcgroupドライバを自動で検知することができませんが、kubeletの稼働を保証するためには、`--cgroup-driver`の値はCRIランタイムが使用するcgroupドライバに一致していなければなりません。 +- クラスターが使用するCRIランタイムによっては、異なるフラグを指定する必要があるかもしれません。例えば、Dockerを使用している場合には、`--network-plugin=cni`のようなフラグを指定する必要があります。外部のランタイムを使用している場合には、`--container-runtime=remote`と指定し、`--container-runtime-endpoint=`のようにCRIエンドポイントを指定する必要があります。 -- The Node API object `.metadata.name` is set to the machine's hostname by default, - unless you are using a cloud provider. You can use the `--hostname-override` flag to override the - default behavior if you need to specify a Node name different from the machine's hostname. +これらのフラグは、systemdなどのサービスマネージャー内のkubeletの設定によって指定することができます。 -- Currently, the kubelet cannot automatically detects the cgroup driver used by the CRI runtime, - but the value of `--cgroup-driver` must match the cgroup driver used by the CRI runtime to ensure - the health of the kubelet. +## kubeadmを使用したkubeletの設定 {#configure-kubelets-using-kubeadm} -- Depending on the CRI runtime your cluster uses, you may need to specify different flags to the kubelet. - For instance, when using Docker, you need to specify flags such as `--network-plugin=cni`, but if you - are using an external runtime, you need to specify `--container-runtime=remote` and specify the CRI - endpoint using the `--container-runtime-path-endpoint=`. +`kubeadm ... --config some-config-file.yaml`のように、カスタムの`KubeletConfiguration`APIオブジェクトを設定ファイルを介して渡すことで、kubeadmによって起動されるkubeletに設定を反映することができます。 -You can specify these flags by configuring an individual kubelet's configuration in your service manager, -such as systemd. +`kubeadm config print init-defaults --component-configs KubeletConfiguration`を実行することによって、この構造体の全てのデフォルト値を確認することができます。 -## kubeadmを使用したkubeletの設定 - -It is possible to configure the kubelet that kubeadm will start if a custom `KubeletConfiguration` -API object is passed with a configuration file like so `kubeadm ... --config some-config-file.yaml`. - -By calling `kubeadm config print init-defaults --component-configs KubeletConfiguration` you can -see all the default values for this structure. - -Also have a look at the [API reference for the -kubelet ComponentConfig](https://godoc.org/k8s.io/kubernetes/pkg/kubelet/apis/config#KubeletConfiguration) -for more information on the individual fields. +また、各フィールドの詳細については、[kubelet ComponentConfigに関するAPIリファレンス](https://godoc.org/k8s.io/kubernetes/pkg/kubelet/apis/config#KubeletConfiguration)を参照してください。 ### `kubeadm init`実行時の流れ -When you call `kubeadm init`, the kubelet configuration is marshalled to disk -at `/var/lib/kubelet/config.yaml`, and also uploaded to a ConfigMap in the cluster. The ConfigMap -is named `kubelet-config-1.X`, where `.X` is the minor version of the Kubernetes version you are -initializing. A kubelet configuration file is also written to `/etc/kubernetes/kubelet.conf` with the -baseline cluster-wide configuration for all kubelets in the cluster. This configuration file -points to the client certificates that allow the kubelet to communicate with the API server. This -addresses the need to -[propagate cluster-level configuration to each kubelet](#propagating-cluster-level-configuration-to-each-kubelet). +`kubeadm init`を実行した場合、kubeletの設定は`/var/lib/kubelet/config.yaml`に格納され、クラスターのConfigMapにもアップロードされます。ConfigMapは`kubelet-config-1.X`という名前で、`.X`は初期化するKubernetesのマイナーバージョンを表します。またこの設定ファイルは、クラスタ内の全てのkubeletのために、クラスター全体設定の基準と共に`/etc/kubernetes/kubelet.conf`にも書き込まれます。この設定ファイルは、kubeletがAPIサーバと通信するためのクライアント証明書を指し示します。これは、[各kubeletにクラスターレベルの設定を配布](#propagating-cluster-level-configuration-to-each-kubelet)することの必要性を示しています。 -To address the second pattern of -[providing instance-specific configuration details](#providing-instance-specific-configuration-details), -kubeadm writes an environment file to `/var/lib/kubelet/kubeadm-flags.env`, which contains a list of -flags to pass to the kubelet when it starts. The flags are presented in the file like this: +二つ目のパターンである、[インスタンス固有の設定内容を適用](#providing-instance-specific-configuration-details)するために、kubeadmは環境ファイルを`/var/lib/kubelet/kubeadm-flags.env`へ書き出します。このファイルは以下のように、kubelet起動時に渡されるフラグのリストを含んでいます。 ```bash KUBELET_KUBEADM_ARGS="--flag1=value1 --flag2=value2 ..." ``` -In addition to the flags used when starting the kubelet, the file also contains dynamic -parameters such as the cgroup driver and whether to use a different CRI runtime socket -(`--cri-socket`). +kubelet起動時に渡されるフラグに加えて、このファイルはcgroupドライバーや異なるCRIランタイムソケットを使用するかどうか(`--cri-socket`)といった動的なパラメータも含みます。 -After marshalling these two files to disk, kubeadm attempts to run the following two -commands, if you are using systemd: +これら二つのファイルがディスク上に格納されると、systemdを使用している場合、kubeadmは以下の二つのコマンドを実行します。 ```bash systemctl daemon-reload && systemctl restart kubelet ``` -If the reload and restart are successful, the normal `kubeadm init` workflow continues. +リロードと再起動に成功すると、通常の`kubeadm init`のワークフローが続きます。 ### `kubeadm join`実行時の流れ -When you run `kubeadm join`, kubeadm uses the Bootstrap Token credential to perform -a TLS bootstrap, which fetches the credential needed to download the -`kubelet-config-1.X` ConfigMap and writes it to `/var/lib/kubelet/config.yaml`. The dynamic -environment file is generated in exactly the same way as `kubeadm init`. +`kubeadm join`を実行した場合、kubeadmはBootstrap Token証明書を使用してTLS bootstrapを行い、ConfigMap`kubelet-config-1.X`をダウンロードするために必要なクレデンシャルを取得し、`/var/lib/kubelet/config.yaml`へ書き込みます。動的な環境ファイルは、`kubeadm init`の場合と全く同様の方法で生成されます。 -Next, `kubeadm` runs the following two commands to load the new configuration into the kubelet: +次に、`kubeadm`は、kubeletに新たな設定を読み込むために、以下の二つのコマンドを実行します。 ```bash systemctl daemon-reload && systemctl restart kubelet ``` -After the kubelet loads the new configuration, kubeadm writes the -`/etc/kubernetes/bootstrap-kubelet.conf` KubeConfig file, which contains a CA certificate and Bootstrap -Token. These are used by the kubelet to perform the TLS Bootstrap and obtain a unique -credential, which is stored in `/etc/kubernetes/kubelet.conf`. When this file is written, the kubelet -has finished performing the TLS Bootstrap. +kubeletが新たな設定を読み込むと、kubeadmは、KubeConfigファイル`/etc/kubernetes/bootstrap-kubelet.conf`を書き込みます。これは、CA証明書とBootstrap Tokenを含みます。これらはkubeletがTLS Bootstrapを行い`/etc/kubernetes/kubelet.conf`に格納されるユニークなクレデンシャルを取得するために使用されます。ファイルが書き込まれると、kubeletはTLS Bootstrapを終了します。 -## kubelet用のsystemdファイル +## kubelet用のsystemdファイル {#the-kubelet-drop-in-file-for-systemd} -The configuration file installed by the kubeadm DEB or RPM package is written to -`/etc/systemd/system/kubelet.service.d/10-kubeadm.conf` and is used by systemd. +`kubeadm`には、systemdがどのようにkubeletを実行するかを指定した設定ファイルが同梱されています。 +kubeadm CLIコマンドは決してこのsystemdファイルには触れないことに注意してください。 + +kubeadmの[DEBパッケージ](https://github.com/kubernetes/kubernetes/blob/master/build/debs/10-kubeadm.conf)または[RPMパッケージ](https://github.com/kubernetes/kubernetes/blob/master/build/rpms/10-kubeadm.conf)によってインストールされたこの設定ファイルは、`/etc/systemd/system/kubelet.service.d/10-kubeadm.conf`に書き込まれ、systemdで使用されます。基本的な`kubelet.service`([RPM用](https://github.com/kubernetes/release/blob/master/cmd/kubepkg/templates/latest/rpm/kubelet/kubelet.service)または、 [DEB用](https://github.com/kubernetes/release/blob/master/cmd/kubepkg/templates/latest/deb/kubelet/lib/systemd/system/kubelet.service))を拡張します。 ```none [Service] Environment="KUBELET_KUBECONFIG_ARGS=--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf" Environment="KUBELET_CONFIG_ARGS=--config=/var/lib/kubelet/config.yaml" -# This is a file that "kubeadm init" and "kubeadm join" generates at runtime, populating +# This is a file that "kubeadm init" and "kubeadm join" generate at runtime, populating the KUBELET_KUBEADM_ARGS variable dynamically EnvironmentFile=-/var/lib/kubelet/kubeadm-flags.env # This is a file that the user can use for overrides of the kubelet args as a last resort. Preferably, @@ -174,26 +117,23 @@ ExecStart= ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_CONFIG_ARGS $KUBELET_KUBEADM_ARGS $KUBELET_EXTRA_ARGS ``` -This file specifies the default locations for all of the files managed by kubeadm for the kubelet. +このファイルは、kubeadmがkubelet用に管理する全ファイルが置かれるデフォルトの場所を指定します。 -- The KubeConfig file to use for the TLS Bootstrap is `/etc/kubernetes/bootstrap-kubelet.conf`, - but it is only used if `/etc/kubernetes/kubelet.conf` does not exist. -- The KubeConfig file with the unique kubelet identity is `/etc/kubernetes/kubelet.conf`. -- The file containing the kubelet's ComponentConfig is `/var/lib/kubelet/config.yaml`. -- The dynamic environment file that contains `KUBELET_KUBEADM_ARGS` is sourced from `/var/lib/kubelet/kubeadm-flags.env`. -- The file that can contain user-specified flag overrides with `KUBELET_EXTRA_ARGS` is sourced from - `/etc/default/kubelet` (for DEBs), or `/etc/sysconfig/kubelet` (for RPMs). `KUBELET_EXTRA_ARGS` - is last in the flag chain and has the highest priority in the event of conflicting settings. +- TLS Bootstrapに使用するKubeConfigファイルは`/etc/kubernetes/bootstrap-kubelet.conf`ですが、`/etc/kubernetes/kubelet.conf`が存在しない場合にのみ使用します。 +- ユニークなkublet識別子を含むKubeConfigファイルは`/etc/kubernetes/kubelet.conf`です。 +- kubeletのComponentConfigを含むファイルは`/var/lib/kubelet/config.yaml`です。 +- `KUBELET_KUBEADM_ARGS`を含む動的な環境ファイルは`/var/lib/kubelet/kubeadm-flags.env`から取得します。 +- `KUBELET_EXTRA_ARGS`によるユーザー定義のフラグの上書きを格納できるファイルは`/etc/default/kubelet`(DEBの場合)、または`/etc/sysconfig/kubelet`(RPMの場合)から取得します。`KUBELET_EXTRA_ARGS`はフラグの連なりの最後に位置し、優先度が最も高いです。 ## Kubernetesバイナリとパッケージの内容 -The DEB and RPM packages shipped with the Kubernetes releases are: +Kubernetesに同梱されるDEB、RPMのパッケージは以下の通りです。 -| Package name | Description | +| パッケージ名 | 説明 | |--------------|-------------| -| `kubeadm` | Installs the `/usr/bin/kubeadm` CLI tool and the [kubelet drop-in file](#the-kubelet-drop-in-file-for-systemd) for the kubelet. | -| `kubelet` | Installs the kubelet binary in `/usr/bin` and CNI binaries in `/opt/cni/bin`. | -| `kubectl` | Installs the `/usr/bin/kubectl` binary. | -| `cri-tools` | Installs the `/usr/bin/crictl` binary from the [cri-tools git repository](https://github.com/kubernetes-incubator/cri-tools). | - +| `kubeadm` | `/usr/bin/kubeadm`CLIツールと、[kubelet用のsystemdファイル](#the-kubelet-drop-in-file-for-systemd)をインストールします。 | +| `kubelet` | kubeletバイナリを`/usr/bin`に、CNIバイナリを`/opt/cni/bin`にインストールします。 | +| `kubectl` | `/usr/bin/kubectl`バイナリをインストールします。 | +| `kubernetes-cni` | 公式のCNIバイナリを`/opt/cni/bin`ディレクトリにインストールします。 | +| `cri-tools` | `/usr/bin/crictl`バイナリを[cri-tools gitリポジトリ](https://github.com/kubernetes-incubator/cri-tools)からインストールします。 | diff --git a/content/ja/docs/setup/production-environment/tools/kubeadm/self-hosting.md b/content/ja/docs/setup/production-environment/tools/kubeadm/self-hosting.md index 08f9efe0b8..a7bee37727 100644 --- a/content/ja/docs/setup/production-environment/tools/kubeadm/self-hosting.md +++ b/content/ja/docs/setup/production-environment/tools/kubeadm/self-hosting.md @@ -8,7 +8,7 @@ weight: 100 ### Self-hosting the Kubernetes control plane {#self-hosting} -As of 1.8, you can experimentally create a _self-hosted_ Kubernetes control +kubeadm allows you to experimentally create a _self-hosted_ Kubernetes control plane. This means that key components such as the API server, controller manager, and scheduler run as [DaemonSet pods](/ja/docs/concepts/workloads/controllers/daemonset/) configured via the Kubernetes API instead of [static pods](/docs/tasks/administer-cluster/static-pod/) diff --git a/content/ja/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md b/content/ja/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md index 90725de1d4..0d73dc2df6 100644 --- a/content/ja/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md +++ b/content/ja/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md @@ -6,6 +6,14 @@ weight: 70 +{{< note >}} +While kubeadm is being used as the management tool for external etcd nodes +in this guide, please note that kubeadm does not plan to support certificate rotation +or upgrades for such nodes. The long term plan is to empower the tool +[etcdadm](https://github.com/kubernetes-sigs/etcdadm) to manage these +aspects. +{{< /note >}} + Kubeadm defaults to running a single member etcd cluster in a static pod managed by the kubelet on the control plane node. This is not a high availability setup as the etcd cluster contains only one member and cannot sustain any members @@ -52,7 +60,8 @@ this example. cat << EOF > /etc/systemd/system/kubelet.service.d/20-etcd-service-manager.conf [Service] ExecStart= - ExecStart=/usr/bin/kubelet --address=127.0.0.1 --pod-manifest-path=/etc/kubernetes/manifests + # Replace "systemd" with the cgroup driver of your container runtime. The default value in the kubelet is "cgroupfs". + ExecStart=/usr/bin/kubelet --address=127.0.0.1 --pod-manifest-path=/etc/kubernetes/manifests --cgroup-driver=systemd Restart=always EOF @@ -81,7 +90,7 @@ this example. HOST=${ETCDHOSTS[$i]} NAME=${NAMES[$i]} cat << EOF > /tmp/${HOST}/kubeadmcfg.yaml - apiVersion: "kubeadm.k8s.io/v1beta1" + apiVersion: "kubeadm.k8s.io/v1beta2" kind: ClusterConfiguration etcd: local: @@ -241,15 +250,17 @@ this example. ```sh docker run --rm -it \ --net host \ - -v /etc/kubernetes:/etc/kubernetes quay.io/coreos/etcd:${ETCD_TAG} etcdctl \ - --cert-file /etc/kubernetes/pki/etcd/peer.crt \ - --key-file /etc/kubernetes/pki/etcd/peer.key \ - --ca-file /etc/kubernetes/pki/etcd/ca.crt \ - --endpoints https://${HOST0}:2379 cluster-health + -v /etc/kubernetes:/etc/kubernetes k8s.gcr.io/etcd:${ETCD_TAG} etcdctl \ + --cert /etc/kubernetes/pki/etcd/peer.crt \ + --key /etc/kubernetes/pki/etcd/peer.key \ + --cacert /etc/kubernetes/pki/etcd/ca.crt \ + --endpoints https://${HOST0}:2379 endpoint health --cluster ... - cluster is healthy + https://[HOST0 IP]:2379 is healthy: successfully committed proposal: took = 16.283339ms + https://[HOST1 IP]:2379 is healthy: successfully committed proposal: took = 19.44402ms + https://[HOST2 IP]:2379 is healthy: successfully committed proposal: took = 35.926451ms ``` - - Set `${ETCD_TAG}` to the version tag of your etcd image. For example `v3.2.24`. + - Set `${ETCD_TAG}` to the version tag of your etcd image. For example `3.4.3-0`. To see the etcd image and tag that kubeadm uses execute `kubeadm config images list --kubernetes-version ${K8S_VERSION}`, where `${K8S_VERSION}` is for example `v1.17.0` - Set `${HOST0}`to the IP address of the host you are testing. diff --git a/content/ja/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md b/content/ja/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md index 669cc3a302..8e9067a4eb 100644 --- a/content/ja/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md +++ b/content/ja/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md @@ -1,7 +1,7 @@ --- title: kubeadmのトラブルシューティング content_type: concept -weight: 90 +weight: 20 --- @@ -152,7 +152,7 @@ Unable to connect to the server: x509: certificate signed by unknown authority ( - Verify that the `$HOME/.kube/config` file contains a valid certificate, and regenerate a certificate if necessary. The certificates in a kubeconfig file - are base64 encoded. The `base64 -d` command can be used to decode the certificate + are base64 encoded. The `base64 --decode` command can be used to decode the certificate and `openssl x509 -text -noout` can be used for viewing the certificate information. - Unset the `KUBECONFIG` environment variable using: @@ -170,6 +170,7 @@ Unable to connect to the server: x509: certificate signed by unknown authority ( ```sh mv $HOME/.kube $HOME/.kube.bak + mkdir $HOME/.kube sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config sudo chown $(id -u):$(id -g) $HOME/.kube/config ``` @@ -197,15 +198,15 @@ Error from server: Get https://10.19.0.41:10250/containerLogs/default/mysql-ddc6 ``` - This may be due to Kubernetes using an IP that can not communicate with other IPs on the seemingly same subnet, possibly by policy of the machine provider. -- Digital Ocean assigns a public IP to `eth0` as well as a private one to be used internally as anchor for their floating IP feature, yet `kubelet` will pick the latter as the node's `InternalIP` instead of the public one. +- DigitalOcean assigns a public IP to `eth0` as well as a private one to be used internally as anchor for their floating IP feature, yet `kubelet` will pick the latter as the node's `InternalIP` instead of the public one. - Use `ip addr show` to check for this scenario instead of `ifconfig` because `ifconfig` will not display the offending alias IP address. Alternatively an API endpoint specific to Digital Ocean allows to query for the anchor IP from the droplet: + Use `ip addr show` to check for this scenario instead of `ifconfig` because `ifconfig` will not display the offending alias IP address. Alternatively an API endpoint specific to DigitalOcean allows to query for the anchor IP from the droplet: ```sh curl http://169.254.169.254/metadata/v1/interfaces/public/0/anchor_ipv4/address ``` - The workaround is to tell `kubelet` which IP to use using `--node-ip`. When using Digital Ocean, it can be the public one (assigned to `eth0`) or the private one (assigned to `eth1`) should you want to use the optional private network. The [`KubeletExtraArgs` section of the kubeadm `NodeRegistrationOptions` structure](https://github.com/kubernetes/kubernetes/blob/release-1.13/cmd/kubeadm/app/apis/kubeadm/v1beta1/types.go) can be used for this. + The workaround is to tell `kubelet` which IP to use using `--node-ip`. When using DigitalOcean, it can be the public one (assigned to `eth0`) or the private one (assigned to `eth1`) should you want to use the optional private network. The [`KubeletExtraArgs` section of the kubeadm `NodeRegistrationOptions` structure](https://github.com/kubernetes/kubernetes/blob/release-1.13/cmd/kubeadm/app/apis/kubeadm/v1beta1/types.go) can be used for this. Then restart `kubelet`: @@ -306,16 +307,56 @@ The tracking issue for this problem is [here](https://github.com/kubernetes/kube *Note: This [issue](https://github.com/kubernetes/kubeadm/issues/1358) only applies to tools that marshal kubeadm types (e.g. to a YAML configuration file). It will be fixed in kubeadm API v1beta2.* -By default, kubeadm applies the `role.kubernetes.io/master:NoSchedule` taint to control-plane nodes. +By default, kubeadm applies the `node-role.kubernetes.io/master:NoSchedule` taint to control-plane nodes. If you prefer kubeadm to not taint the control-plane node, and set `InitConfiguration.NodeRegistration.Taints` to an empty slice, the field will be omitted when marshalling. When the field is omitted, kubeadm applies the default taint. There are at least two workarounds: -1. Use the `role.kubernetes.io/master:PreferNoSchedule` taint instead of an empty slice. [Pods will get scheduled on masters](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/), unless other nodes have capacity. +1. Use the `node-role.kubernetes.io/master:PreferNoSchedule` taint instead of an empty slice. [Pods will get scheduled on masters](/docs/concepts/configuration/taint-and-toleration/), unless other nodes have capacity. 2. Remove the taint after kubeadm init exits: ```bash -kubectl taint nodes NODE_NAME role.kubernetes.io/master:NoSchedule- +kubectl taint nodes NODE_NAME node-role.kubernetes.io/master:NoSchedule- + ``` + +## `/usr` is mounted read-only on nodes {#usr-mounted-read-only} + +On Linux distributions such as Fedora CoreOS, the directory `/usr` is mounted as a read-only filesystem. +For [flex-volume support](https://github.com/kubernetes/community/blob/ab55d85/contributors/devel/sig-storage/flexvolume.md), +Kubernetes components like the kubelet and kube-controller-manager use the default path of +`/usr/libexec/kubernetes/kubelet-plugins/volume/exec/`, yet the flex-volume directory _must be writeable_ +for the feature to work. + +To workaround this issue you can configure the flex-volume directory using the kubeadm +[configuration file](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2). + +On the primary control-plane Node (created using `kubeadm init`) pass the following +file using `--config`: + +```yaml +apiVersion: kubeadm.k8s.io/v1beta2 +kind: InitConfiguration +nodeRegistration: + kubeletExtraArgs: + volume-plugin-dir: "/opt/libexec/kubernetes/kubelet-plugins/volume/exec/" +--- +apiVersion: kubeadm.k8s.io/v1beta2 +kind: ClusterConfiguration +controllerManager: + extraArgs: + flex-volume-plugin-dir: "/opt/libexec/kubernetes/kubelet-plugins/volume/exec/" ``` +On joining Nodes: + +```yaml +apiVersion: kubeadm.k8s.io/v1beta2 +kind: JoinConfiguration +nodeRegistration: + kubeletExtraArgs: + volume-plugin-dir: "/opt/libexec/kubernetes/kubelet-plugins/volume/exec/" +``` + +Alternatively, you can modify `/etc/fstab` to make the `/usr` mount writeable, but please +be advised that this is modifying a design principle of the Linux distribution. diff --git a/content/ja/docs/setup/production-environment/tools/kubespray.md b/content/ja/docs/setup/production-environment/tools/kubespray.md index 921ab0e3d8..6c02ca5374 100644 --- a/content/ja/docs/setup/production-environment/tools/kubespray.md +++ b/content/ja/docs/setup/production-environment/tools/kubespray.md @@ -6,22 +6,22 @@ weight: 30 -This quickstart helps to install a Kubernetes cluster hosted on GCE, Azure, OpenStack, AWS, vSphere, Oracle Cloud Infrastructure (Experimental) or Baremetal with [Kubespray](https://github.com/kubernetes-incubator/kubespray). +This quickstart helps to install a Kubernetes cluster hosted on GCE, Azure, OpenStack, AWS, vSphere, Packet (bare metal), Oracle Cloud Infrastructure (Experimental) or Baremetal with [Kubespray](https://github.com/kubernetes-sigs/kubespray). -Kubespray is a composition of [Ansible](http://docs.ansible.com/) playbooks, [inventory](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/ansible.md), provisioning tools, and domain knowledge for generic OS/Kubernetes clusters configuration management tasks. Kubespray provides: +Kubespray is a composition of [Ansible](http://docs.ansible.com/) playbooks, [inventory](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/ansible.md), provisioning tools, and domain knowledge for generic OS/Kubernetes clusters configuration management tasks. Kubespray provides: * a highly available cluster * composable attributes * support for most popular Linux distributions * Container Linux by CoreOS - * Debian Jessie, Stretch, Wheezy + * Debian Buster, Jessie, Stretch, Wheezy * Ubuntu 16.04, 18.04 - * CentOS/RHEL 7 - * Fedora/CentOS Atomic - * openSUSE Leap 42.3/Tumbleweed + * CentOS/RHEL/Oracle Linux 7 + * Fedora 28 + * openSUSE Leap 15 * continuous integration tests -To choose a tool which best fits your use case, read [this comparison](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/comparisons.md) to [kubeadm](/docs/admin/kubeadm/) and [kops](../kops). +To choose a tool which best fits your use case, read [this comparison](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/comparisons.md) to [kubeadm](/docs/admin/kubeadm/) and [kops](/docs/setup/production-environment/tools/kops/). @@ -31,11 +31,11 @@ To choose a tool which best fits your use case, read [this comparison](https://g ### (1/5) 下地の要件の確認 -Provision servers with the following [requirements](https://github.com/kubernetes-incubator/kubespray#requirements): +Provision servers with the following [requirements](https://github.com/kubernetes-sigs/kubespray#requirements): -* **Ansible v2.5 (or newer) and python-netaddr is installed on the machine that will run Ansible commands** +* **Ansible v2.7.8 and python-netaddr is installed on the machine that will run Ansible commands** * **Jinja 2.9 (or newer) is required to run the Ansible Playbooks** -* The target servers must have **access to the Internet** in order to pull docker images +* The target servers must have access to the Internet in order to pull docker images. Otherwise, additional configuration is required ([See Offline Environment](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/offline-environment.md)) * The target servers are configured to allow **IPv4 forwarding** * **Your ssh key must be copied** to all the servers part of your inventory * The **firewalls are not managed**, you'll need to implement your own rules the way you used to. in order to avoid any issue during deployment you should disable your firewall @@ -44,12 +44,13 @@ Provision servers with the following [requirements](https://github.com/kubernete Kubespray provides the following utilities to help provision your environment: * [Terraform](https://www.terraform.io/) scripts for the following cloud providers: - * [AWS](https://github.com/kubernetes-incubator/kubespray/tree/master/contrib/terraform/aws) - * [OpenStack](https://github.com/kubernetes-incubator/kubespray/tree/master/contrib/terraform/openstack) + * [AWS](https://github.com/kubernetes-sigs/kubespray/tree/master/contrib/terraform/aws) + * [OpenStack](https://github.com/kubernetes-sigs/kubespray/tree/master/contrib/terraform/openstack) + * [Packet](https://github.com/kubernetes-sigs/kubespray/tree/master/contrib/terraform/packet) ### (2/5) インベントリファイルの用意 -After you provision your servers, create an [inventory file for Ansible](http://docs.ansible.com/ansible/intro_inventory.html). You can do this manually or via a dynamic inventory script. For more information, see "[Building your own inventory](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md#building-your-own-inventory)". +After you provision your servers, create an [inventory file for Ansible](http://docs.ansible.com/ansible/intro_inventory.html). You can do this manually or via a dynamic inventory script. For more information, see "[Building your own inventory](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#building-your-own-inventory)". ### (3/5) クラスタ作成の計画 @@ -58,14 +59,14 @@ Kubespray provides the ability to customize many aspects of the deployment: * Choice deployment mode: kubeadm or non-kubeadm * CNI (networking) plugins * DNS configuration -* Choice of control plane: native/binary or containerized with docker or rkt +* Choice of control plane: native/binary or containerized * Component versions * Calico route reflectors * Component runtime options - * docker - * rkt - * cri-o -* Certificate generation methods (**Vault being discontinued**) + * {{< glossary_tooltip term_id="docker" >}} + * {{< glossary_tooltip term_id="containerd" >}} + * {{< glossary_tooltip term_id="cri-o" >}} +* Certificate generation methods Kubespray customizations can be made to a [variable file](http://docs.ansible.com/ansible/playbooks_variables.html). If you are just getting started with Kubespray, consider using the Kubespray defaults to deploy your cluster and explore Kubernetes. @@ -73,18 +74,18 @@ Kubespray customizations can be made to a [variable file](http://docs.ansible.co Next, deploy your cluster: -Cluster deployment using [ansible-playbook](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md#starting-custom-deployment). +Cluster deployment using [ansible-playbook](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#starting-custom-deployment). ```shell ansible-playbook -i your/inventory/inventory.ini cluster.yml -b -v \ --private-key=~/.ssh/private_key ``` -Large deployments (100+ nodes) may require [specific adjustments](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/large-deployments.md) for best results. +Large deployments (100+ nodes) may require [specific adjustments](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/large-deployments.md) for best results. ### (5/5) デプロイの確認 -Kubespray provides a way to verify inter-pod connectivity and DNS resolve with [Netchecker](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/netcheck.md). Netchecker ensures the netchecker-agents pods can resolve DNS requests and ping each over within the default namespace. Those pods mimic similar behavior of the rest of the workloads and serve as cluster health indicators. +Kubespray provides a way to verify inter-pod connectivity and DNS resolve with [Netchecker](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/netcheck.md). Netchecker ensures the netchecker-agents pods can resolve DNS requests and ping each over within the default namespace. Those pods mimic similar behavior of the rest of the workloads and serve as cluster health indicators. ## クラスタの操作 @@ -92,16 +93,16 @@ Kubespray provides additional playbooks to manage your cluster: _scale_ and _upg ### クラスタのスケール -You can add worker nodes from your cluster by running the scale playbook. For more information, see "[Adding nodes](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md#adding-nodes)". -You can remove worker nodes from your cluster by running the remove-node playbook. For more information, see "[Remove nodes](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md#remove-nodes)". +You can add worker nodes from your cluster by running the scale playbook. For more information, see "[Adding nodes](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#adding-nodes)". +You can remove worker nodes from your cluster by running the remove-node playbook. For more information, see "[Remove nodes](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#remove-nodes)". ### クラスタのアップグレード -You can upgrade your cluster by running the upgrade-cluster playbook. For more information, see "[Upgrades](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/upgrades.md)". +You can upgrade your cluster by running the upgrade-cluster playbook. For more information, see "[Upgrades](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/upgrades.md)". ## クリーンアップ -You can reset your nodes and wipe out all components installed with Kubespray via the [reset playbook](https://github.com/kubernetes-incubator/kubespray/blob/master/reset.yml). +You can reset your nodes and wipe out all components installed with Kubespray via the [reset playbook](https://github.com/kubernetes-sigs/kubespray/blob/master/reset.yml). {{< caution >}} When running the reset playbook, be sure not to accidentally target your production cluster! @@ -109,14 +110,13 @@ When running the reset playbook, be sure not to accidentally target your product ## フィードバック -* Slack Channel: [#kubespray](https://kubernetes.slack.com/messages/kubespray/) -* [GitHub Issues](https://github.com/kubernetes-incubator/kubespray/issues) +* Slack Channel: [#kubespray](https://kubernetes.slack.com/messages/kubespray/) (You can get your invite [here](http://slack.k8s.io/)) +* [GitHub Issues](https://github.com/kubernetes-sigs/kubespray/issues) ## {{% heading "whatsnext" %}} -Check out planned work on Kubespray's [roadmap](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/roadmap.md). - +Check out planned work on Kubespray's [roadmap](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/roadmap.md). diff --git a/content/ja/docs/setup/production-environment/turnkey/_index.md b/content/ja/docs/setup/production-environment/turnkey/_index.md index c39cd2a714..6b9dabb7ab 100644 --- a/content/ja/docs/setup/production-environment/turnkey/_index.md +++ b/content/ja/docs/setup/production-environment/turnkey/_index.md @@ -1,4 +1,4 @@ --- title: ターンキークラウドソリューション -weight: 40 +weight: 30 --- diff --git a/content/ja/docs/setup/production-environment/turnkey/alibaba-cloud.md b/content/ja/docs/setup/production-environment/turnkey/alibaba-cloud.md index f8323743cf..4506e9cba0 100644 --- a/content/ja/docs/setup/production-environment/turnkey/alibaba-cloud.md +++ b/content/ja/docs/setup/production-environment/turnkey/alibaba-cloud.md @@ -4,9 +4,9 @@ title: Alibaba CloudでKubernetesを動かす ## Alibaba Cloud Container Service -[Alibaba Cloud Container Service](https://www.alibabacloud.com/product/container-service)はAlibaba Cloud ECSインスタンスのクラスター上でDockerアプリケーションを起動して管理します。著名なオープンソースのコンテナオーケストレーターであるDocker SwarmおよびKubernetesをサポートしています。 +[Alibaba Cloud Container Service](https://www.alibabacloud.com/product/container-service)はAlibaba Cloud ECSインスタンスのクラスター上もしくはサーバーレスの形態でDockerアプリケーションを起動して管理します。著名なオープンソースのコンテナオーケストレーターであるDocker SwarmおよびKubernetesをサポートしています。 -クラスターの構築と管理を簡素化する為に、[Alibaba Cloud Container Serviceの為のKubernetesサポート](https://www.alibabacloud.com/product/kubernetes)を使用します。[Kubernetes walk-through](https://www.alibabacloud.com/help/doc-detail/86737.htm)に従ってすぐに始めることができ、中国語の[Alibaba CloudにおけるKubernetesサポートの為のチュートリアル](https://yq.aliyun.com/teams/11/type_blog-cid_200-page_1)もあります。 +クラスターの構築と管理を簡素化するために、[Alibaba Cloud Container ServiceのためのKubernetesサポート](https://www.alibabacloud.com/product/kubernetes)を使用します。[Kubernetes walk-through](https://www.alibabacloud.com/help/doc-detail/86737.htm)に従ってすぐに始めることができ、中国語の[Alibaba CloudにおけるKubernetesサポートのためのチュートリアル](https://yq.aliyun.com/teams/11/type_blog-cid_200-page_1)もあります。 カスタムバイナリもしくはオープンソースKubernetesを使用する場合は、以下の手順に従って下さい。 @@ -14,4 +14,4 @@ title: Alibaba CloudでKubernetesを動かす [Alibaba Cloudプロバイダーが実装されたKubernetesのソースコード](https://github.com/AliyunContainerService/kubernetes)はオープンソースであり、GitHubから入手可能です。 -さらなる情報は英語の[Kubernetesのクイックデプロイメント - Alibaba CloudのVPC環境](https://www.alibabacloud.com/forum/read-830)および[中国語](https://yq.aliyun.com/articles/66474)をご覧下さい。 +さらなる情報は英語の[Kubernetesのクイックデプロイメント - Alibaba CloudのVPC環境](https://www.alibabacloud.com/forum/read-830)をご覧下さい。 diff --git a/content/ja/docs/setup/production-environment/turnkey/aws.md b/content/ja/docs/setup/production-environment/turnkey/aws.md index ebbb93160d..1fc53a1f28 100644 --- a/content/ja/docs/setup/production-environment/turnkey/aws.md +++ b/content/ja/docs/setup/production-environment/turnkey/aws.md @@ -16,7 +16,7 @@ AWS上でKubernetesクラスターを作成するには、AWSからアクセス ### サポートされているプロダクショングレードのツール -* [conjure-up](/docs/getting-started-guides/ubuntu/)はUbuntu上でネイティブなAWSインテグレーションを用いてKubernetesクラスターを作成するオープンソースのインストーラーです。 +* [conjure-up](https://docs.conjure-up.io/stable/en/cni/k8s-and-aws)はUbuntu上でネイティブなAWSインテグレーションを用いてKubernetesクラスターを作成するオープンソースのインストーラーです。 * [Kubernetes Operations](https://github.com/kubernetes/kops) - プロダクショングレードなKubernetesのインストール、アップグレード、管理が可能です。AWS上のDebian、Ubuntu、CentOS、RHELをサポートしています。 diff --git a/content/ja/docs/setup/production-environment/turnkey/icp.md b/content/ja/docs/setup/production-environment/turnkey/icp.md index 79783a6364..9d1a0a17b3 100644 --- a/content/ja/docs/setup/production-environment/turnkey/icp.md +++ b/content/ja/docs/setup/production-environment/turnkey/icp.md @@ -35,9 +35,9 @@ IBM Cloud Private can also run on the AWS cloud platform by using Terraform. To ## Azure上でのIBM Cloud Private -You can enable Microsoft Azure as a cloud provider for IBM Cloud Private deployment and take advantage of all the IBM Cloud Private features on the Azure public cloud. For more information, see [IBM Cloud Private on Azure](https://www.ibm.com/support/knowledgecenter/SSBS6K_3.1.2/supported_environments/azure_overview.html). +You can enable Microsoft Azure as a cloud provider for IBM Cloud Private deployment and take advantage of all the IBM Cloud Private features on the Azure public cloud. For more information, see [IBM Cloud Private on Azure](https://www.ibm.com/support/knowledgecenter/SSBS6K_3.2.0/supported_environments/azure_overview.html). -## Red Hat OpenShift上でのIBM Cloud Private +## Red Hat OpenShiftを用いたIBM Cloud Private You can deploy IBM certified software containers that are running on IBM Cloud Private onto Red Hat OpenShift. @@ -49,7 +49,7 @@ Integration capabilities: * Integrated core platform services, such as monitoring, metering, and logging * IBM Cloud Private uses the OpenShift image registry -For more information see, [IBM Cloud Private on OpenShift](https://www.ibm.com/support/knowledgecenter/SSBS6K_3.1.2/supported_environments/openshift/overview.html). +For more information see, [IBM Cloud Private on OpenShift](https://www.ibm.com/support/knowledgecenter/SSBS6K_3.2.0/supported_environments/openshift/overview.html). ## VirtualBox上でのIBM Cloud Private diff --git a/content/ja/docs/setup/production-environment/turnkey/stackpoint.md b/content/ja/docs/setup/production-environment/turnkey/stackpoint.md deleted file mode 100644 index 47711bf4d8..0000000000 --- a/content/ja/docs/setup/production-environment/turnkey/stackpoint.md +++ /dev/null @@ -1,187 +0,0 @@ ---- -title: Stackpoint.ioを利用して複数のクラウド上でKubernetesを動かす -content_type: concept ---- - - - -[StackPointCloud](https://stackpoint.io/) is the universal control plane for Kubernetes Anywhere. StackPointCloud allows you to deploy and manage a Kubernetes cluster to the cloud provider of your choice in 3 steps using a web-based interface. - - - - - -## AWS - -To create a Kubernetes cluster on AWS, you will need an Access Key ID and a Secret Access Key from AWS. - -1. Choose a Provider - - a. Log in to [stackpoint.io](https://stackpoint.io) with a GitHub, Google, or Twitter account. - - b. Click **+ADD A CLUSTER NOW**. - - c. Click to select Amazon Web Services (AWS). - -1. Configure Your Provider - - a. Add your Access Key ID and a Secret Access Key from AWS. Select your default StackPointCloud SSH keypair, or click **ADD SSH KEY** to add a new keypair. - - b. Click **SUBMIT** to submit the authorization information. - -1. Configure Your Cluster - - Choose any extra options you may want to include with your cluster, then click **SUBMIT** to create the cluster. - -1. Run the Cluster - - You can monitor the status of your cluster and suspend or delete it from [your stackpoint.io dashboard](https://stackpoint.io/#/clusters). - - For information on using and managing a Kubernetes cluster on AWS, [consult the Kubernetes documentation](/docs/getting-started-guides/aws/). - - -## GCE - -To create a Kubernetes cluster on GCE, you will need the Service Account JSON Data from Google. - -1. Choose a Provider - - a. Log in to [stackpoint.io](https://stackpoint.io) with a GitHub, Google, or Twitter account. - - b. Click **+ADD A CLUSTER NOW**. - - c. Click to select Google Compute Engine (GCE). - -1. Configure Your Provider - - a. Add your Service Account JSON Data from Google. Select your default StackPointCloud SSH keypair, or click **ADD SSH KEY** to add a new keypair. - - b. Click **SUBMIT** to submit the authorization information. - -1. Configure Your Cluster - - Choose any extra options you may want to include with your cluster, then click **SUBMIT** to create the cluster. - -1. Run the Cluster - - You can monitor the status of your cluster and suspend or delete it from [your stackpoint.io dashboard](https://stackpoint.io/#/clusters). - - For information on using and managing a Kubernetes cluster on GCE, [consult the Kubernetes documentation](/docs/getting-started-guides/gce/). - - -## Google Kubernetes Engine - -To create a Kubernetes cluster on Google Kubernetes Engine, you will need the Service Account JSON Data from Google. - -1. Choose a Provider - - a. Log in to [stackpoint.io](https://stackpoint.io) with a GitHub, Google, or Twitter account. - - b. Click **+ADD A CLUSTER NOW**. - - c. Click to select Google Kubernetes Engine. - -1. Configure Your Provider - - a. Add your Service Account JSON Data from Google. Select your default StackPointCloud SSH keypair, or click **ADD SSH KEY** to add a new keypair. - - b. Click **SUBMIT** to submit the authorization information. - -1. Configure Your Cluster - - Choose any extra options you may want to include with your cluster, then click **SUBMIT** to create the cluster. - -1. Run the Cluster - - You can monitor the status of your cluster and suspend or delete it from [your stackpoint.io dashboard](https://stackpoint.io/#/clusters). - - For information on using and managing a Kubernetes cluster on Google Kubernetes Engine, consult [the official documentation](/ja/docs/home/). - - -## DigitalOcean - -To create a Kubernetes cluster on DigitalOcean, you will need a DigitalOcean API Token. - -1. Choose a Provider - - a. Log in to [stackpoint.io](https://stackpoint.io) with a GitHub, Google, or Twitter account. - - b. Click **+ADD A CLUSTER NOW**. - - c. Click to select DigitalOcean. - -1. Configure Your Provider - - a. Add your DigitalOcean API Token. Select your default StackPointCloud SSH keypair, or click **ADD SSH KEY** to add a new keypair. - - b. Click **SUBMIT** to submit the authorization information. - -1. Configure Your Cluster - - Choose any extra options you may want to include with your cluster, then click **SUBMIT** to create the cluster. - -1. Run the Cluster - - You can monitor the status of your cluster and suspend or delete it from [your stackpoint.io dashboard](https://stackpoint.io/#/clusters). - - For information on using and managing a Kubernetes cluster on DigitalOcean, consult [the official documentation](/ja/docs/home/). - - -## Microsoft Azure - -To create a Kubernetes cluster on Microsoft Azure, you will need an Azure Subscription ID, Username/Email, and Password. - -1. Choose a Provider - - a. Log in to [stackpoint.io](https://stackpoint.io) with a GitHub, Google, or Twitter account. - - b. Click **+ADD A CLUSTER NOW**. - - c. Click to select Microsoft Azure. - -1. Configure Your Provider - - a. Add your Azure Subscription ID, Username/Email, and Password. Select your default StackPointCloud SSH keypair, or click **ADD SSH KEY** to add a new keypair. - - b. Click **SUBMIT** to submit the authorization information. - -1. Configure Your Cluster - - Choose any extra options you may want to include with your cluster, then click **SUBMIT** to create the cluster. - -1. Run the Cluster - - You can monitor the status of your cluster and suspend or delete it from [your stackpoint.io dashboard](https://stackpoint.io/#/clusters). - - For information on using and managing a Kubernetes cluster on Azure, [consult the Kubernetes documentation](/docs/getting-started-guides/azure/). - - -## Packet - -To create a Kubernetes cluster on Packet, you will need a Packet API Key. - -1. Choose a Provider - - a. Log in to [stackpoint.io](https://stackpoint.io) with a GitHub, Google, or Twitter account. - - b. Click **+ADD A CLUSTER NOW**. - - c. Click to select Packet. - -1. Configure Your Provider - - a. Add your Packet API Key. Select your default StackPointCloud SSH keypair, or click **ADD SSH KEY** to add a new keypair. - - b. Click **SUBMIT** to submit the authorization information. - -1. Configure Your Cluster - - Choose any extra options you may want to include with your cluster, then click **SUBMIT** to create the cluster. - -1. Run the Cluster - - You can monitor the status of your cluster and suspend or delete it from [your stackpoint.io dashboard](https://stackpoint.io/#/clusters). - - For information on using and managing a Kubernetes cluster on Packet, consult [the official documentation](/ja/docs/home/). - - diff --git a/content/ja/docs/setup/production-environment/windows/flannel-master-kubeclt-get-pods.png b/content/ja/docs/setup/production-environment/windows/flannel-master-kubeclt-get-pods.png deleted file mode 100644 index 73da333fcf..0000000000 Binary files a/content/ja/docs/setup/production-environment/windows/flannel-master-kubeclt-get-pods.png and /dev/null differ diff --git a/content/ja/docs/setup/production-environment/windows/flannel-master-kubectl-get-ds.png b/content/ja/docs/setup/production-environment/windows/flannel-master-kubectl-get-ds.png deleted file mode 100644 index cda9353316..0000000000 Binary files a/content/ja/docs/setup/production-environment/windows/flannel-master-kubectl-get-ds.png and /dev/null differ diff --git a/content/ja/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md b/content/ja/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md index ab0181fd49..c821fca425 100644 --- a/content/ja/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md +++ b/content/ja/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md @@ -1,73 +1,72 @@ --- -title: Intro to Windows support in Kubernetes +title: KubernetesのWindowsサポート概要 content_type: concept weight: 65 --- -Windows applications constitute a large portion of the services and applications that run in many organizations. [Windows containers](https://aka.ms/windowscontainers) provide a modern way to encapsulate processes and package dependencies, making it easier to use DevOps practices and follow cloud native patterns for Windows applications. Kubernetes has become the defacto standard container orchestrator, and the release of Kubernetes 1.14 includes production support for scheduling Windows containers on Windows nodes in a Kubernetes cluster, enabling a vast ecosystem of Windows applications to leverage the power of Kubernetes. Organizations with investments in Windows-based applications and Linux-based applications don't have to look for separate orchestrators to manage their workloads, leading to increased operational efficiencies across their deployments, regardless of operating system. +Windowsアプリケーションは、多くの組織で実行されているサービスやアプリケーションの大部分を占めています。[Windowsコンテナ](https://aka.ms/windowscontainers)は、プロセスとパッケージの依存関係を一つにまとめる最新の方法を提供し、DevOpsプラクティスの使用とWindowsアプリケーションのクラウドネイティブパターンの追求を容易にします。Kubernetesは事実上、標準的なコンテナオーケストレータになりました。Kubernetes 1.14のリリースでは、Kubernetesクラスター内のWindowsノードでWindowsコンテナをスケジューリングする本番環境サポートが含まれたので、Windowsアプリケーションの広大なエコシステムにおいて、Kubernetesを有効的に活用できます。WindowsベースのアプリケーションとLinuxベースのアプリケーションに投資している組織は、ワークロードを管理する個別のオーケストレーターが不要となるため、オペレーティングシステムに関係なくアプリケーション全体の運用効率が向上します。 -## Windows containers in Kubernetes +## KubernetesのWindowsコンテナ -To enable the orchestration of Windows containers in Kubernetes, simply include Windows nodes in your existing Linux cluster. Scheduling Windows containers in [Pods](/ja/docs/concepts/workloads/pods/pod-overview/) on Kubernetes is as simple and easy as scheduling Linux-based containers. +KubernetesでWindowsコンテナのオーケストレーションを有効にする方法は、既存のLinuxクラスターにWindowsノードを含めるだけです。Kubernetesの[Pod](/ja/docs/concepts/workloads/pods/pod-overview/)でWindowsコンテナをスケジュールすることは、Linuxベースのコンテナをスケジュールするのと同じくらいシンプルで簡単です。 -In order to run Windows containers, your Kubernetes cluster must include multiple operating systems, with control plane nodes running Linux and workers running either Windows or Linux depending on your workload needs. Windows Server 2019 is the only Windows operating system supported, enabling [Kubernetes Node](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node) on Windows (including kubelet, [container runtime](https://docs.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/containerd), and kube-proxy). For a detailed explanation of Windows distribution channels see the [Microsoft documentation](https://docs.microsoft.com/en-us/windows-server/get-started-19/servicing-channels-19). +Windowsコンテナを実行するには、Kubernetesクラスターに複数のオペレーティングシステムを含める必要があります。コントロールプレーンノードはLinux、ワーカーノードはワークロードのニーズに応じてWindowsまたはLinuxで実行します。Windows Server 2019は、サポートされている唯一のWindowsオペレーティングシステムであり、Windows (kubelet、[コンテナランタイム](https://docs.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/containerd)、kube-proxyを含む)で[Kubernetesノード](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node)を有効にします。Windowsディストリビューションチャンネルの詳細については、[Microsoftのドキュメント](https://docs.microsoft.com/en-us/windows-server/get-started-19/servicing-channels-19)を参照してください。 {{< note >}} -The Kubernetes control plane, including the [master components](/ja/docs/concepts/overview/components/), continues to run on Linux. There are no plans to have a Windows-only Kubernetes cluster. +[マスターコンポーネント](/ja/docs/concepts/overview/components/)を含むKubernetesコントロールプレーンは、Linuxで実行し続けます。WindowsのみのKubernetesクラスターを導入する計画はありません。 {{< /note >}} - {{< note >}} -In this document, when we talk about Windows containers we mean Windows containers with process isolation. Windows containers with [Hyper-V isolation](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/hyperv-container) is planned for a future release. +このドキュメントでは、Windowsコンテナについて説明する場合、プロセス分離のWindowsコンテナを意味します。[Hyper-V分離](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/hyperv-container)のWindowsコンテナは、将来リリースが計画されています。 {{< /note >}} -## Supported Functionality and Limitations +## サポートされている機能と制限 -### Supported Functionality +### サポートされている機能 -#### Compute +#### コンピュート -From an API and kubectl perspective, Windows containers behave in much the same way as Linux-based containers. However, there are some notable differences in key functionality which are outlined in the limitation section. +APIとkubectlの観点から見ると、WindowsコンテナはLinuxベースのコンテナとほとんど同じように動作します。ただし、制限セクションで概説されている主要な機能には、いくつかの顕著な違いがあります。 -Let's start with the operating system version. Refer to the following table for Windows operating system support in Kubernetes. A single heterogeneous Kubernetes cluster can have both Windows and Linux worker nodes. Windows containers have to be scheduled on Windows nodes and Linux containers on Linux nodes. +オペレーティングシステムのバージョンから始めましょう。KubernetesのWindowsオペレーティングシステムのサポートについては、次の表を参照してください。単一の混成Kubernetesクラスターは、WindowsとLinuxの両方のワーカーノードを持つことができます。WindowsコンテナはWindowsノードで、LinuxコンテナはLinuxノードでスケジュールする必要があります。 -| Kubernetes version | Host OS version (Kubernetes Node) | | | +| Kubernetes バージョン | ホストOS バージョン (Kubernetes ノード) | | | | --- | --- | --- | --- | | | *Windows Server 1709* | *Windows Server 1803* | *Windows Server 1809/Windows Server 2019* | -| *Kubernetes v1.14* | Not Supported | Not Supported| Supported for Windows Server containers Builds 17763.* with Docker EE-basic 18.09 | +| *Kubernetes v1.14* | サポートされていません | サポートされていません| Windows Server containers Builds 17763.* と Docker EE-basic 18.09 がサポートされています | {{< note >}} -We don't expect all Windows customers to update the operating system for their apps frequently. Upgrading your applications is what dictates and necessitates upgrading or introducing new nodes to the cluster. For the customers that chose to upgrade their operating system for containers running on Kubernetes, we will offer guidance and step-by-step instructions when we add support for a new operating system version. This guidance will include recommended upgrade procedures for upgrading user applications together with cluster nodes. Windows nodes adhere to Kubernetes [version-skew policy](/ja/docs/setup/release/version-skew-policy/) (node to control plane versioning) the same way as Linux nodes do today. +すべてのWindowsユーザーがアプリのオペレーティングシステムを頻繁に更新することは望んでいません。アプリケーションのアップグレードは、クラスターに新しいノードをアップグレードまたは導入することを要求する必要があります。Kubernetesで実行されているコンテナのオペレーティングシステムをアップグレードすることを選択したユーザーには、新しいオペレーティングシステムバージョンのサポート追加時に、ガイダンスと段階的な指示を提供します。このガイダンスには、クラスターノードと共にアプリケーションをアップグレードするための推奨アップグレード手順が含まれます。Windowsノードは、現在のLinuxノードと同じように、Kubernetes[バージョンスキューポリシー](/ja/docs/setup/release/version-skew-policy/)(ノードからコントロールプレーンのバージョン管理)に準拠しています。 {{< /note >}} {{< note >}} -The Windows Server Host Operating System is subject to the [Windows Server ](https://www.microsoft.com/en-us/cloud-platform/windows-server-pricing) licensing. The Windows Container images are subject to the [Supplemental License Terms for Windows containers](https://docs.microsoft.com/en-us/virtualization/windowscontainers/images-eula). +Windows Serverホストオペレーティングシステムには、[Windows Server](https://www.microsoft.com/en-us/cloud-platform/windows-server-pricing)ライセンスが適用されます。Windowsコンテナイメージには、[Windowsコンテナの追加ライセンス条項](https://docs.microsoft.com/en-us/virtualization/windowscontainers/images-eula)ライセンスが提供されます。 {{< /note >}} {{< note >}} -Windows containers with process isolation have strict compatibility rules, [where the host OS version must match the container base image OS version](https://docs.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/version-compatibility). Once we support Windows containers with Hyper-V isolation in Kubernetes, the limitation and compatibility rules will change. +プロセス分離のWindowsコンテナには、[ホストOSのバージョンはコンテナのベースイメージのOSバージョンと一致する必要がある](https://docs.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/version-compatibility)という厳格な互換性ルールがあります。KubernetesでHyper-V分離のWindowsコンテナをサポートする際には、制限と互換性ルールが変更されます。 {{< /note >}} -Key Kubernetes elements work the same way in Windows as they do in Linux. In this section, we talk about some of the key workload enablers and how they map to Windows. +Kubernetesの主要な要素は、WindowsでもLinuxと同じように機能します。このセクションでは、主要なワークロードイネーブラーのいくつかと、それらがWindowsにどのようにマップされるかについて説明します。 * [Pods](/ja/docs/concepts/workloads/pods/pod-overview/) - A Pod is the basic building block of Kubernetes–the smallest and simplest unit in the Kubernetes object model that you create or deploy. The following Pod capabilities, properties and events are supported with Windows containers: + Podは、Kubernetesにおける最も基本的な構成要素です。人間が作成またはデプロイするKubernetesオブジェクトモデルの中で最小かつ最もシンプルな単位です。WindowsとLinuxのコンテナを同じPodにデプロイすることはできません。Pod内のすべてのコンテナは、各ノードが特定のプラットフォームとアーキテクチャを表す単一のノードにスケジュールされます。次のPod機能、プロパティ、およびイベントがWindowsコンテナでサポートされています。: - * Single or multiple containers per Pod with process isolation and volume sharing - * Pod status fields - * Readiness and Liveness probes - * postStart & preStop container lifecycle events - * ConfigMap, Secrets: as environment variables or volumes + * プロセス分離とボリューム共有を備えたPodごとの単一または複数のコンテナ + * Podステータスフィールド + * ReadinessとLiveness Probe + * postStartとpreStopコンテナのライフサイクルイベント + * 環境変数またはボリュームとしてのConfigMap、 Secrets * EmptyDir - * Named pipe host mounts - * Resource limits + * 名前付きパイプホストマウント + * リソース制限 * [Controllers](/ja/docs/concepts/workloads/controllers/) - Kubernetes controllers handle the desired state of Pods. The following workload controllers are supported with Windows containers: + Kubernetesコントローラは、Podの望ましい状態を処理します。次のワークロードコントローラーは、Windowsコンテナでサポートされています。: * ReplicaSet * ReplicationController @@ -78,322 +77,340 @@ Key Kubernetes elements work the same way in Windows as they do in Linux. In thi * CronJob * [Services](/ja/docs/concepts/services-networking/service/) - A Kubernetes Service is an abstraction which defines a logical set of Pods and a policy by which to access them - sometimes called a micro-service. You can use services for cross-operating system connectivity. In Windows, services can utilize the following types, properties and capabilities: + Kubernetes Serviceは、Podの論理セットとPodにアクセスするためのポリシーを定義する抽象概念です。マイクロサービスと呼ばれることもあります。オペレーティングシステム間の接続にServiceを使用できます。WindowsでのServiceは、次のタイプ、プロパティと機能を利用できます。: - * Service Environment variables + * サービス環境変数 * NodePort * ClusterIP * LoadBalancer * ExternalName * Headless services -Pods, Controllers and Services are critical elements to managing Windows workloads on Kubernetes. However, on their own they are not enough to enable the proper lifecycle management of Windows workloads in a dynamic cloud native environment. We added support for the following features: +Pod、Controller、Serviceは、KubernetesでWindowsワークロードを管理するための重要な要素です。ただし、それだけでは、動的なクラウドネイティブ環境でWindowsワークロードの適切なライフサイクル管理を可能にするのに十分ではありません。次の機能のサポートを追加しました： -* Pod and container metrics -* Horizontal Pod Autoscaler support +* Podとコンテナのメトリクス +* Horizontal Pod Autoscalerサポート * kubectl Exec -* Resource Quotas -* Scheduler preemption +* リソースクォータ +* Schedulerのプリエンプション -#### Container Runtime +#### コンテナランタイム -Docker EE-basic 18.09 is required on Windows Server 2019 / 1809 nodes for Kubernetes. This works with the dockershim code included in the kubelet. Additional runtimes such as CRI-ContainerD may be supported in later Kubernetes versions. +KubernetesのWindows Server 2019/1809ノードでは、Docker EE-basic 18.09が必要です。これは、kubeletに含まれているdockershimコードで動作します。CRI-ContainerDなどの追加のランタイムは、Kubernetesの以降のバージョンでサポートされる可能性があります。 -#### Storage +#### 永続ストレージ -Kubernetes Volumes enable complex applications with data persistence and Pod volume sharing requirements to be deployed on Kubernetes. Kubernetes on Windows supports the following types of [volumes](/ja/docs/concepts/storage/volumes/): +Kubernetes[ボリューム](/docs/concepts/storage/volumes/)を使用すると、データの永続性とPodボリュームの共有要件を備えた複雑なアプリケーションをKubernetesにデプロイできます。特定のストレージバックエンドまたはプロトコルに関連付けられた永続ボリュームの管理には、ボリュームのプロビジョニング/プロビジョニング解除/サイズ変更、Kubernetesノードへのボリュームのアタッチ/デタッチ、およびデータを永続化する必要があるPod内の個別のコンテナへのボリュームのマウント/マウント解除などのアクションが含まれます。特定のストレージバックエンドまたはプロトコルに対してこれらのボリューム管理アクションを実装するコードは、Kubernetesボリューム[プラグイン](/docs/concepts/storage/volumes/#types-of-volumes)の形式で出荷されます。次の幅広いクラスのKubernetesボリュームプラグインがWindowsでサポートされています。: -* FlexVolume out-of-tree plugin with [SMB and iSCSI](https://github.com/Microsoft/K8s-Storage-Plugins/tree/master/flexvolume/windows) support -* [azureDisk](/ja/docs/concepts/storage/volumes/#azuredisk) -* [azureFile](/ja/docs/concepts/storage/volumes/#azurefile) -* [gcePersistentDisk](/ja/docs/concepts/storage/volumes/#gcepersistentdisk) +##### In-treeボリュームプラグイン +In-treeボリュームプラグインに関連付けられたコードは、コアKubernetesコードベースの一部として提供されます。In-treeボリュームプラグインのデプロイでは、追加のスクリプトをインストールしたり、個別のコンテナ化されたプラグインコンポーネントをデプロイしたりする必要はありません。これらのプラグインは、ストレージバックエンドでのボリュームのプロビジョニング/プロビジョニング解除とサイズ変更、Kubernetesノードへのボリュームのアタッチ/アタッチ解除、Pod内の個々のコンテナーへのボリュームのマウント/マウント解除を処理できます。次のIn-treeプラグインは、Windowsノードをサポートしています。: -#### Networking +* [awsElasticBlockStore](/docs/concepts/storage/volumes/#awselasticblockstore) +* [azureDisk](/docs/concepts/storage/volumes/#azuredisk) +* [azureFile](/docs/concepts/storage/volumes/#azurefile) +* [gcePersistentDisk](/docs/concepts/storage/volumes/#gcepersistentdisk) +* [vsphereVolume](/docs/concepts/storage/volumes/#vspherevolume) -Networking for Windows containers is exposed through [CNI plugins](/ja/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/). Windows containers function similarly to virtual machines in regards to networking. Each container has a virtual network adapter (vNIC) which is connected to a Hyper-V virtual switch (vSwitch). The Host Networking Service (HNS) and the Host Compute Service (HCS) work together to create containers and attach container vNICs to networks. HCS is responsible for the management of containers whereas HNS is responsible for the management of networking resources such as: +##### FlexVolume Plugins +[FlexVolume](/docs/concepts/storage/volumes/#flexVolume)プラグインに関連付けられたコードは、ホストに直接デプロイする必要があるout-of-treeのスクリプトまたはバイナリとして出荷されます。FlexVolumeプラグインは、Kubernetesノードとの間のボリュームのアタッチ/デタッチ、およびPod内の個々のコンテナとの間のボリュームのマウント/マウント解除を処理します。FlexVolumeプラグインに関連付けられた永続ボリュームのプロビジョニング/プロビジョニング解除は、通常FlexVolumeプラグインとは別の外部プロビジョニング担当者を通じて処理できます。次のFlexVolume[プラグイン](https://github.com/Microsoft/K8s-Storage-Plugins/tree/master/flexvolume/windows)は、Powershellスクリプトとしてホストにデプロイされ、Windowsノードをサポートします: -* Virtual networks (including creation of vSwitches) -* Endpoints / vNICs -* Namespaces -* Policies (Packet encapsulations, Load-balancing rules, ACLs, NAT'ing rules, etc.) +* [SMB](https://github.com/microsoft/K8s-Storage-Plugins/tree/master/flexvolume/windows/plugins/microsoft.com~smb.cmd) +* [iSCSI](https://github.com/microsoft/K8s-Storage-Plugins/tree/master/flexvolume/windows/plugins/microsoft.com~iscsi.cmd) -The following service spec types are supported: +##### CSIプラグイン + +{{< feature-state for_k8s_version="v1.16" state="alpha" >}} + +{{< glossary_tooltip text="CSI" term_id="csi" >}}プラグインに関連付けられたコードは、通常、コンテナイメージとして配布され、DaemonSetやStatefulSetなどの標準のKubernetesコンポーネントを使用してデプロイされるout-of-treeのスクリプトおよびバイナリとして出荷されます。CSIプラグインは、ボリュームのプロビジョニング/プロビジョニング解除/サイズ変更、Kubernetesノードへのボリュームのアタッチ/ボリュームからのデタッチ、Pod内の個々のコンテナへのボリュームのマウント/マウント解除、バックアップ/スナップショットとクローニングを使用した永続データのバックアップ/リストアといった、Kubernetesの幅広いボリューム管理アクションを処理します。CSIプラグインは通常、ノードプラグイン（各ノードでDaemonSetとして実行される）とコントローラープラグインで構成されます。 + +CSIノードプラグイン（特に、ブロックデバイスまたは共有ファイルシステムとして公開された永続ボリュームに関連付けられているプラ​​グイン）は、ディスクデバイスのスキャン、ファイルシステムのマウントなど、さまざまな特権操作を実行する必要があります。これらの操作は、ホストオペレーティングシステムごとに異なります。Linuxワーカーノードの場合、コンテナ化されたCSIノードプラグインは通常、特権コンテナとしてデプロイされます。Windowsワーカーノードの場合、コンテナ化されたCSIノードプラグインの特権操作は、[csi-proxy](https://github.com/kubernetes-csi/csi-proxy)を使用してサポートされます。各Windowsノードにプリインストールされている。詳細については、展開するCSIプラグインの展開ガイドを参照してください。 + +#### ネットワーキング + +Windowsコンテナのネットワークは、[CNIプラグイン](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)を通じて公開されます。Windowsコンテナは、ネットワークに関して仮想マシンと同様に機能します。各コンテナには、Hyper-V仮想スイッチ(vSwitch)に接続されている仮想ネットワークアダプター(vNIC)があります。Host Network Service(HNS)とHost Compute Service(HCS)は連携してコンテナを作成し、コンテナvNICをネットワークに接続します。HCSはコンテナの管理を担当するのに対し、HNSは次のようなネットワークリソースの管理を担当します。: + +* 仮想ネットワーク(vSwitchの作成を含む) +* エンドポイント/vNIC +* 名前空間 +* ポリシー(パケットのカプセル化、負荷分散ルール、ACL、NATルールなど) + +次のServiceタイプがサポートされています。: * NodePort * ClusterIP * LoadBalancer * ExternalName -Windows supports five different networking drivers/modes: L2bridge, L2tunnel, Overlay, Transparent, and NAT. In a heterogeneous cluster with Windows and Linux worker nodes, you need to select a networking solution that is compatible on both Windows and Linux. The following out-of-tree plugins are supported on Windows, with recommendations on when to use each CNI: +Windowsは、L2bridge、L2tunnel、Overlay、Transparent、NATの5つの異なるネットワークドライバー/モードをサポートしています。WindowsとLinuxのワーカーノードを持つ異種クラスターでは、WindowsとLinuxの両方で互換性のあるネットワークソリューションを選択する必要があります。以下のツリー外プラグインがWindowsでサポートされており、各CNIをいつ使用するかに関する推奨事項があります。: -| Network Driver | Description | Container Packet Modifications | Network Plugins | Network Plugin Characteristics | +| ネットワークドライバー | 説明 | コンテナパケットの変更 | ネットワークプラグイン | ネットワークプラグインの特性 | | -------------- | ----------- | ------------------------------ | --------------- | ------------------------------ | -| L2bridge | Containers are attached to an external vSwitch. Containers are attached to the underlay network, although the physical network doesn't need to learn the container MACs because they are rewritten on ingress/egress. Inter-container traffic is bridged inside the container host. | MAC is rewritten to host MAC, IP remains the same. | [win-bridge](https://github.com/containernetworking/plugins/tree/master/plugins/main/windows/win-bridge), [Azure-CNI](https://github.com/Azure/azure-container-networking/blob/master/docs/cni.md), Flannel host-gateway uses win-bridge | win-bridge uses L2bridge network mode, connects containers to the underlay of hosts, offering best performance. Requires L2 adjacency between container hosts | -| L2Tunnel | This is a special case of l2bridge, but only used on Azure. All packets are sent to the virtualization host where SDN policy is applied. | MAC rewritten, IP visible on the underlay network | [Azure-CNI](https://github.com/Azure/azure-container-networking/blob/master/docs/cni.md) | Azure-CNI allows integration of containers with Azure vNET, and allows them to leverage the set of capabilities that [Azure Virtual Network provides](https://azure.microsoft.com/en-us/services/virtual-network/). For example, securely connect to Azure services or use Azure NSGs. See [azure-cni for some examples](https://docs.microsoft.com/en-us/azure/aks/concepts-network#azure-cni-advanced-networking) | -| Overlay (Overlay networking for Windows in Kubernetes is in *alpha* stage) | Containers are given a vNIC connected to an external vSwitch. Each overlay network gets its own IP subnet, defined by a custom IP prefix.The overlay network driver uses VXLAN encapsulation. | Encapsulated with an outer header, inner packet remains the same. | [Win-overlay](https://github.com/containernetworking/plugins/tree/master/plugins/main/windows/win-overlay), Flannel VXLAN (uses win-overlay) | win-overlay should be used when virtual container networks are desired to be isolated from underlay of hosts (e.g. for security reasons). Allows for IPs to be re-used for different overlay networks (which have different VNID tags) if you are restricted on IPs in your datacenter. This option may be used when the container hosts are not L2 adjacent but have L3 connectivity | -| Transparent (special use case for [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes)) | Requires an external vSwitch. Containers are attached to an external vSwitch which enables intra-pod communication via logical networks (logical switches and routers). | Packet is encapsulated either via [GENEVE](https://datatracker.ietf.org/doc/draft-gross-geneve/) or [STT](https://datatracker.ietf.org/doc/draft-davie-stt/) tunneling to reach pods which are not on the same host.
Packets are forwarded or dropped via the tunnel metadata information supplied by the ovn network controller.
NAT is done for north-south communication. | [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes) | [Deploy via ansible](https://github.com/openvswitch/ovn-kubernetes/tree/master/contrib). Distributed ACLs can be applied via Kubernetes policies. IPAM support. Load-balancing can be achieved without kube-proxy. NATing is done without using iptables/netsh. | -| NAT (*not used in Kubernetes*) | Containers are given a vNIC connected to an internal vSwitch. DNS/DHCP is provided using an internal component called [WinNAT](https://blogs.technet.microsoft.com/virtualization/2016/05/25/windows-nat-winnat-capabilities-and-limitations/) | MAC and IP is rewritten to host MAC/IP. | [nat](https://github.com/Microsoft/windows-container-networking/tree/master/plugins/nat) | Included here for completeness | +| L2bridge | コンテナは外部のvSwitchに接続されます。コンテナはアンダーレイネットワークに接続されますが、物理ネットワークはコンテナのMACを上り/下りで書き換えるため、MACを学習する必要はありません。コンテナ間トラフィックは、コンテナホスト内でブリッジされます。 | MACはホストのMACに書き換えられ、IPは変わりません。| [win-bridge](https://github.com/containernetworking/plugins/tree/master/plugins/main/windows/win-bridge)、[Azure-CNI](https://github.com/Azure/azure-container-networking/blob/master/docs/cni.md)、Flannelホストゲートウェイは、win-bridgeを使用します。 | win-bridgeはL2bridgeネットワークモードを使用して、コンテナをホストのアンダーレイに接続して、最高のパフォーマンスを提供します。ノード間接続にはユーザー定義ルート(UDR)が必要です。 | +| L2Tunnel | これはl2bridgeの特殊なケースですが、Azureでのみ使用されます。すべてのパケットは、SDNポリシーが適用されている仮想化ホストに送信されます。| MACが書き換えられ、IPがアンダーレイネットワークで表示されます。 | [Azure-CNI](https://github.com/Azure/azure-container-networking/blob/master/docs/cni.md) | Azure-CNIを使用すると、コンテナをAzure vNETと統合し、[Azure Virtual Networkが提供](https://azure.microsoft.com/en-us/services/virtual-network/)する一連の機能を活用できます。たとえば、Azureサービスに安全に接続するか、Azure NSGを使用します。[azure-cniのいくつかの例](https://docs.microsoft.com/en-us/azure/aks/concepts-network#azure-cni-advanced-networking)を参照してください。| +| オーバーレイ(KubernetesのWindows用のオーバーレイネットワークは *アルファ* 段階です) | コンテナには、外部のvSwitchに接続されたvNICが付与されます。各オーバーレイネットワークは、カスタムIPプレフィックスで定義された独自のIPサブネットを取得します。オーバーレイネットワークドライバーは、VXLANを使用してカプセル化します。 | 外部ヘッダーでカプセル化されます。 | [Win-overlay](https://github.com/containernetworking/plugins/tree/master/plugins/main/windows/win-overlay)、Flannel VXLAN (win-overlayを使用) | win-overlayは、仮想コンテナーネットワークをホストのアンダーレイから分離する必要がある場合に使用する必要があります(セキュリティ上の理由など)。データセンター内のIPが制限されている場合に、(異なるVNIDタグを持つ)異なるオーバーレイネットワークでIPを再利用できるようにします。このオプションには、Windows Server 2019で[KB4489899](https://support.microsoft.com/help/4489899)が必要です。| +| 透過的([ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes)の特別な使用例) | 外部のvSwitchが必要です。コンテナは外部のvSwitchに接続され、論理ネットワーク(論理スイッチおよびルーター)を介したPod内通信を可能にします。 | パケットは、[GENEVE](https://datatracker.ietf.org/doc/draft-gross-geneve/)または[STT](https://datatracker.ietf.org/doc/draft-davie-stt/)トンネリングを介してカプセル化され、同じホスト上にないポッドに到達します。パケットは、ovnネットワークコントローラーによって提供されるトンネルメタデータ情報を介して転送またはドロップされます。NATは南北通信のために行われます。 | [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes) | [ansible経由でデプロイ](https://github.com/openvswitch/ovn-kubernetes/tree/master/contrib)します。分散ACLは、Kubernetesポリシーを介して適用できます。 IPAMをサポートします。負荷分散は、kube-proxyなしで実現できます。 NATは、ip​​tables/netshを使用せずに行われます。 | +| NAT(*Kubernetesでは使用されません*) | コンテナには、内部のvSwitchに接続されたvNICが付与されます。DNS/DHCPは、[WinNAT](https://blogs.technet.microsoft.com/virtualization/2016/05/25/windows-nat-winnat-capabilities-and-limitations/)と呼ばれる内部コンポーネントを使用して提供されます。 | MACおよびIPはホストMAC/IPに書き換えられます。 | [nat](https://github.com/Microsoft/windows-container-networking/tree/master/plugins/nat) | 完全を期すためにここに含まれています。 | -As outlined above, the [Flannel](https://github.com/coreos/flannel) CNI [meta plugin](https://github.com/containernetworking/plugins/tree/master/plugins/meta/flannel) is also supported on [Windows](https://github.com/containernetworking/plugins/tree/master/plugins/meta/flannel#windows-support-experimental) via the [VXLAN network backend](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan) (**alpha support** ; delegates to win-overlay) and [host-gateway network backend](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#host-gw) (stable support; delegates to win-bridge). This plugin supports delegating to one of the reference CNI plugins (win-overlay, win-bridge), to work in conjunction with Flannel daemon on Windows (Flanneld) for automatic node subnet lease assignment and HNS network creation. This plugin reads in its own configuration file (net-conf.json), and aggregates it with the environment variables from the FlannelD generated subnet.env file. It then delegates to one of the reference CNI plugins for network plumbing, and sends the correct configuration containing the node-assigned subnet to the IPAM plugin (e.g. host-local). +上で概説したように、[Flannel](https://github.com/coreos/flannel) CNI[メタプラグイン](https://github.com/containernetworking/plugins/tree/master/plugins/meta/flannel)は、[VXLANネットワークバックエンド](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan)(**アルファサポート**、win-overlayへのデリゲート)および[ホストゲートウェイネットワークバックエンド](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#host-gw)(安定したサポート、win-bridgeへのデリゲート)を介して[Windows](https://github.com/containernetworking/plugins/tree/master/plugins/meta/flannel#windows-support-experimental)でもサポートされます。このプラグインは、参照CNIプラグイン(win-overlay、win-bridge)の1つへの委任をサポートし、WindowsのFlannelデーモン(Flanneld)と連携して、ノードのサブネットリースの自動割り当てとHNSネットワークの作成を行います。このプラグインは、独自の構成ファイル(cni.conf)を読み取り、FlannelDで生成されたsubnet.envファイルからの環境変数と統合します。次に、ネットワークプラミング用の参照CNIプラグインの1つに委任し、ノード割り当てサブネットを含む正しい構成をIPAMプラグイン(ホストローカルなど)に送信します。 -For the node, pod, and service objects, the following network flows are supported for TCP/UDP traffic: +Node、Pod、およびServiceオブジェクトの場合、TCP/UDPトラフィックに対して次のネットワークフローがサポートされます。: * Pod -> Pod (IP) * Pod -> Pod (Name) * Pod -> Service (Cluster IP) -* Pod -> Service (PQDN, but only if there are no ".") +* Pod -> Service (PQDN、ただし、「.」がない場合のみ) * Pod -> Service (FQDN) * Pod -> External (IP) * Pod -> External (DNS) * Node -> Pod * Pod -> Node -The following IPAM options are supported on Windows: +Windowsでは、次のIPAMオプションがサポートされています。 -* [Host-local](https://github.com/containernetworking/plugins/tree/master/plugins/ipam/host-local) -* HNS IPAM (Inbox platform IPAM, this is a fallback when no IPAM is set) -* [Azure-vnet-ipam](https://github.com/Azure/azure-container-networking/blob/master/docs/ipam.md) (for azure-cni only) +* [ホストローカル](https://github.com/containernetworking/plugins/tree/master/plugins/ipam/host-local) +* HNS IPAM (受信トレイプラットフォームIPAM、これはIPAMが設定されていない場合のフォールバック) +* [Azure-vnet-ipam](https://github.com/Azure/azure-container-networking/blob/master/docs/ipam.md)(azure-cniのみ) -### Limitations +### 制限 -#### Control Plane +#### コントロールプレーン -Windows is only supported as a worker node in the Kubernetes architecture and component matrix. This means that a Kubernetes cluster must always include Linux master nodes, zero or more Linux worker nodes, and zero or more Windows worker nodes. +Windowsは、Kubernetesアーキテクチャとコンポーネントマトリックスのワーカーノードとしてのみサポートされています。つまり、Kubernetesクラスタには常にLinuxマスターノード、0以上のLinuxワーカーノード、0以上のWindowsワーカーノードが含まれている必要があります。 -#### Compute +#### コンピュート -##### Resource management and process isolation +##### リソース管理とプロセス分離 - Linux cgroups are used as a pod boundary for resource controls in Linux. Containers are created within that boundary for network, process and file system isolation. The cgroups APIs can be used to gather cpu/io/memory stats. In contrast, Windows uses a Job object per container with a system namespace filter to contain all processes in a container and provide logical isolation from the host. There is no way to run a Windows container without the namespace filtering in place. This means that system privileges cannot be asserted in the context of the host, and thus privileged containers are not available on Windows. Containers cannot assume an identity from the host because the Security Account Manager (SAM) is separate. +Linux cgroupsは、Linuxのリソースを制御するPodの境界として使用されます。コンテナは、ネットワーク、プロセス、およびファイルシステムを分離するのために、その境界内に作成されます。cgroups APIを使用して、cpu/io/memoryの統計を収集できます。対照的に、Windowsはシステムネームスペースフィルターを備えたコンテナごとのジョブオブジェクトを使用して、コンテナ内のすべてのプロセスを格納し、ホストからの論理的な分離を提供します。ネームスペースフィルタリングを行わずにWindowsコンテナを実行する方法はありません。これは、ホストの環境ではシステム特権を主張できないため、Windowsでは特権コンテナを使用できないことを意味します。セキュリティアカウントマネージャー(SAM)が独立しているため、コンテナはホストからIDを引き受けることができません。 -##### Operating System Restrictions +##### オペレーティングシステムの制限 -Windows has strict compatibility rules, where the host OS version must match the container base image OS version. Only Windows containers with a container operating system of Windows Server 2019 are supported. Hyper-V isolation of containers, enabling some backward compatibility of Windows container image versions, is planned for a future release. +Windowsには厳密な互換性ルールがあり、ホストOSのバージョンとコンテナのベースイメージOSのバージョンは、一致する必要があります。Windows Server 2019のコンテナオペレーティングシステムを備えたWindowsコンテナのみがサポートされます。Hyper-V分離のコンテナは、Windowsコンテナのイメージバージョンに下位互換性を持たせることは、将来のリリースで計画されています。 -##### Feature Restrictions +##### 機能制限 -* TerminationGracePeriod: not implemented -* Single file mapping: to be implemented with CRI-ContainerD -* Termination message: to be implemented with CRI-ContainerD -* Privileged Containers: not currently supported in Windows containers -* HugePages: not currently supported in Windows containers -* The existing node problem detector is Linux-only and requires privileged containers. In general, we don't expect this to be used on Windows because privileged containers are not supported -* Not all features of shared namespaces are supported (see API section for more details) +* TerminationGracePeriod：実装されていません +* 単一ファイルのマッピング：CRI-ContainerDで実装されます +* 終了メッセージ：CRI-ContainerDで実装されます +* 特権コンテナ：現在Windowsコンテナではサポートされていません +* HugePages：現在Windowsコンテナではサポートされていません +* 既存のノード問題を検出する機能はLinux専用であり、特権コンテナが必要です。一般的に、特権コンテナはサポートされていないため、これがWindowsで使用されることは想定していません。 +* ネームスペース共有については、すべての機能がサポートされているわけではありません（詳細については、APIセクションを参照してください） -##### Memory Reservations and Handling +##### メモリ予約と処理 -Windows does not have an out-of-memory process killer as Linux does. Windows always treats all user-mode memory allocations as virtual, and pagefiles are mandatory. The net effect is that Windows won't reach out of memory conditions the same way Linux does, and processes page to disk instead of being subject to out of memory (OOM) termination. If memory is over-provisioned and all physical memory is exhausted, then paging can slow down performance. +Windowsには、Linuxのようなメモリ不足のプロセスキラーはありません。Windowsは常に全ユーザーモードのメモリ割り当てを仮想として扱い、ページファイルは必須です。正味の効果は、WindowsはLinuxのようなメモリ不足の状態にはならず、メモリ不足（OOM）終了の影響を受ける代わりにページをディスクに処理します。メモリが過剰にプロビジョニングされ、物理メモリのすべてが使い果たされると、ページングによってパフォーマンスが低下する可能性があります。 -Keeping memory usage within reasonable bounds is possible with a two-step process. First, use the kubelet parameters `--kubelet-reserve` and/or `--system-reserve` to account for memory usage on the node (outside of containers). This reduces [NodeAllocatable](/ja/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)). As you deploy workloads, use resource limits (must set only limits or limits must equal requests) on containers. This also subtracts from NodeAllocatable and prevents the scheduler from adding more pods once a node is full. +2ステップのプロセスで、メモリ使用量を妥当な範囲内に保つことが可能です。まず、kubeletパラメータ`--kubelet-reserve`や`--system-reserve`を使用して、ノード（コンテナ外）でのメモリ使用量を明確にします。これにより、[NodeAllocatable](/ja/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable))が削減されます。ワークロードをデプロイするときは、コンテナにリソース制限をかけます（制限のみを設定するか、制限が要求と等しくなければなりません）。これにより、NodeAllocatableも差し引かれ、ノードのリソースがフルな状態になるとSchedulerがPodを追加できなくなります。 -A best practice to avoid over-provisioning is to configure the kubelet with a system reserved memory of at least 2GB to account for Windows, Docker, and Kubernetes processes. +過剰なプロビジョニングを回避するためのベストプラクティスは、Windows、Docker、およびKubernetesのプロセスに対応するために、最低2GBのメモリを予約したシステムでkubeletを構成することです。 -The behavior of the flags behave differently as described below: +フラグの振舞いについては、次のような異なる動作をします。: -* `--kubelet-reserve`, `--system-reserve` , and `--eviction-hard` flags update Node Allocatable -* Eviction by using `--enforce-node-allocable` is not implemented -* Eviction by using `--eviction-hard` and `--eviction-soft` are not implemented -* MemoryPressure Condition is not implemented -* There are no OOM eviction actions taken by the kubelet -* Kubelet running on the windows node does not have memory restrictions. `--kubelet-reserve` and `--system-reserve` do not set limits on kubelet or processes running on the host. This means kubelet or a process on the host could cause memory resource starvation outside the node-allocatable and scheduler +* `--kubelet-reserve`、`--system-reserve`、および`--eviction-hard`フラグはノードの割り当て可能数を更新します +* `--enforce-node-allocable`を使用した排除は実装されていません +* `--eviction-hard`および`--eviction-soft`を使用した排除は実装されていません +* MemoryPressureの制約は実装されていません +* kubeletによって実行されるOOMを排除することはありません +* Windowsノードで実行されているKubeletにはメモリ制限がありません。`--kubelet-reserve`と`--system-reserve`は、ホストで実行されているkubeletまたはプロセスに制限を設定しません。これは、ホスト上のkubeletまたはプロセスが、NodeAllocatableとSchedulerの外でメモリリソース不足を引き起こす可能性があることを意味します。 -#### Storage +#### ストレージ -Windows has a layered filesystem driver to mount container layers and create a copy filesystem based on NTFS. All file paths in the container are resolved only within the context of that container. +Windowsには、コンテナレイヤーをマウントして、NTFSに基づいて複製されたファイルシステムを作るためのレイヤー構造のファイルシステムドライバーがあります。コンテナ内のすべてのファイルパスは、そのコンテナの環境内だけで決められます。 -* Volume mounts can only target a directory in the container, and not an individual file -* Volume mounts cannot project files or directories back to the host filesystem -* Read-only filesystems are not supported because write access is always required for the Windows registry and SAM database. However, read-only volumes are supported -* Volume user-masks and permissions are not available. Because the SAM is not shared between the host & container, there's no mapping between them. All permissions are resolved within the context of the container +* ボリュームマウントは、コンテナ内のディレクトリのみを対象にすることができ、個別のファイルは対象にできません +* ボリュームマウントは、ファイルまたはディレクトリをホストファイルシステムに投影することはできません +* WindowsレジストリとSAMデータベースには常に書き込みアクセスが必要であるため、読み取り専用ファイルシステムはサポートされていません。ただし、読み取り専用ボリュームはサポートされています +* ボリュームのユーザーマスクと権限は使用できません。SAMはホストとコンテナ間で共有されないため、それらの間のマッピングはありません。すべての権限はコンテナの環境内で決められます -As a result, the following storage functionality is not supported on Windows nodes +その結果、次のストレージ機能はWindowsノードではサポートされません。 -* Volume subpath mounts. Only the entire volume can be mounted in a Windows container. -* Subpath volume mounting for Secrets -* Host mount projection -* DefaultMode (due to UID/GID dependency) -* Read-only root filesystem. Mapped volumes still support readOnly -* Block device mapping -* Memory as the storage medium -* CSI plugins which require privileged containers -* File system features like uui/guid, per-user Linux filesystem permissions -* NFS based storage/volume support -* Expanding the mounted volume (resizefs) +* ボリュームサブパスのマウント。Windowsコンテナにマウントできるのはボリューム全体だけです。 +* シークレットのサブパスボリュームのマウント +* ホストマウントプロジェクション +* DefaultMode（UID/GID依存関係による） +* 読み取り専用のルートファイルシステム。マップされたボリュームは引き続き読み取り専用をサポートします +* ブロックデバイスマッピング +* 記憶媒体としてのメモリ +* uui/guid、ユーザーごとのLinuxファイルシステム権限などのファイルシステム機能 +* NFSベースのストレージ/ボリュームのサポート +* マウントされたボリュームの拡張（resizefs） -#### Networking +#### ネットワーキング -Windows Container Networking differs in some important ways from Linux networking. The [Microsoft documentation for Windows Container Networking](https://docs.microsoft.com/en-us/virtualization/windowscontainers/container-networking/architecture) contains additional details and background. +Windowsコンテナネットワーキングは、Linuxネットワーキングとはいくつかの重要な実装方法の違いがあります。[Microsoft documentation for Windows Container Networking](https://docs.microsoft.com/en-us/virtualization/windowscontainers/container-networking/architecture)には、追加の詳細と背景があります。 -The Windows host networking networking service and virtual switch implement namespacing and can create virtual NICs as needed for a pod or container. However, many configurations such as DNS, routes, and metrics are stored in the Windows registry database rather than /etc/... files as they are on Linux. The Windows registry for the container is separate from that of the host, so concepts like mapping /etc/resolv.conf from the host into a container don't have the same effect they would on Linux. These must be configured using Windows APIs run in the context of that container. Therefore CNI implementations need to call the HNS instead of relying on file mappings to pass network details into the pod or container. +Windowsホストネットワーキングサービスと仮想スイッチはネームスペースを実装して、Podまたはコンテナの必要に応じて仮想NICを作成できます。ただし、DNS、ルート、メトリックなどの多くの構成は、Linuxのような/etc/...ファイルではなく、Windowsレジストリデータベースに保存されます。コンテナのWindowsレジストリはホストのレジストリとは別であるため、ホストからコンテナへの/etc/resolv.confのマッピングなどの概念は、Linuxの場合と同じ効果をもたらしません。これらは、そのコンテナの環境で実行されるWindows APIを使用して構成する必要があります。したがって、CNIの実装は、ファイルマッピングに依存する代わりにHNSを呼び出して、ネットワークの詳細をPodまたはコンテナに渡す必要があります。 -The following networking functionality is not supported on Windows nodes +次のネットワーク機能はWindowsノードではサポートされていません -* Host networking mode is not available for Windows pods -* Local NodePort access from the node itself fails (works for other nodes or external clients) -* Accessing service VIPs from nodes will be available with a future release of Windows Server -* Overlay networking support in kube-proxy is an alpha release. In addition, it requires [KB4482887](https://support.microsoft.com/en-us/help/4482887/windows-10-update-kb4482887) to be installed on Windows Server 2019 -* Local Traffic Policy and DSR mode -* Windows containers connected to l2bridge, l2tunnel, or overlay networks do not support communicating over the IPv6 stack. There is outstanding Windows platform work required to enable these network drivers to consume IPv6 addresses and subsequent Kubernetes work in kubelet, kube-proxy, and CNI plugins. -* Outbound communication using the ICMP protocol via the win-overlay, win-bridge, and Azure-CNI plugin. Specifically, the Windows data plane ([VFP](https://www.microsoft.com/en-us/research/project/azure-virtual-filtering-platform/)) doesn't support ICMP packet transpositions. This means: - * ICMP packets directed to destinations within the same network (e.g. pod to pod communication via ping) work as expected and without any limitations - * TCP/UDP packets work as expected and without any limitations - * ICMP packets directed to pass through a remote network (e.g. pod to external internet communication via ping) cannot be transposed and thus will not be routed back to their source - * Since TCP/UDP packets can still be transposed, one can substitute `ping ` with `curl ` to be able to debug connectivity to the outside world. +* ホストネットワーキングモードはWindows Podでは使用できません +* ノード自体からのローカルNodePortアクセスは失敗します（他のノードまたは外部クライアントで機能） +* ノードからのService VIPへのアクセスは、Windows Serverの将来のリリースで利用可能になる予定です +* kube-proxyのオーバーレイネットワーキングサポートはアルファリリースです。さらに、[KB4482887](https://support.microsoft.com/en-us/help/4482887/windows-10-update-kb4482887)がWindows Server 2019にインストールされている必要があります +* ローカルトラフィックポリシーとDSRモード +* l2bridge、l2tunnel、またはオーバーレイネットワークに接続されたWindowsコンテナは、IPv6スタックを介した通信をサポートしていません。これらのネットワークドライバーがIPv6アドレスを使用できるようにするために必要な機能として、優れたWindowsプラットフォームの機能があり、それに続いて、kubelet、kube-proxy、およびCNIプラグインといったKubernetesの機能があります。 +* win-overlay、win-bridge、およびAzure-CNIプラグインを介したICMPプロトコルを使用したアウトバウンド通信。具体的には、Windowsデータプレーン([VFP](https://www.microsoft.com/en-us/research/project/azure-virtual-filtering-platform/))は、ICMPパケットの置き換えをサポートしていません。これの意味は： + * 同じネットワーク内の宛先に向けられたICMPパケット（pingを介したPod間通信など）は期待どおりに機能し、制限はありません + * TCP/UDPパケットは期待どおりに機能し、制限はありません + * リモートネットワーク（Podからping経由の外部インターネット通信など）を通過するように指示されたICMPパケットは置き換えできないため、ソースにルーティングされません。 + * TCP/UDPパケットは引き続き置き換えできるため、`ping `を`curl `に置き換えることで、外部への接続をデバッグできます。 -These features were added in Kubernetes v1.15: +これらの機能はKubernetes v1.15で追加されました。 * `kubectl port-forward` -##### CNI Plugins +##### CNIプラグイン -* Windows reference network plugins win-bridge and win-overlay do not currently implement [CNI spec](https://github.com/containernetworking/cni/blob/master/SPEC.md) v0.4.0 due to missing "CHECK" implementation. -* The Flannel VXLAN CNI has the following limitations on Windows: +* Windowsリファレンスネットワークプラグインのwin-bridgeとwin-overlayは、[CNI仕様](https://github.com/containernetworking/cni/blob/master/SPEC.md)v0.4.0において「CHECK」実装がないため、今のところ実装されていません。 +* Flannel VXLAN CNIについては、Windowsで次の制限があります。: -1. Node-pod connectivity isn't possible by design. It's only possible for local pods with Flannel [PR 1096](https://github.com/coreos/flannel/pull/1096) -2. We are restricted to using VNI 4096 and UDP port 4789. The VNI limitation is being worked on and will be overcome in a future release (open-source flannel changes). See the official [Flannel VXLAN](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan) backend docs for more details on these parameters. +1. Node-podの直接間接続は設計上不可能です。Flannel[PR 1096](https://github.com/coreos/flannel/pull/1096)を使用するローカルPodでのみ可能です +2. VNI 4096とUDPポート4789の使用に制限されています。VNIの制限は現在取り組んでおり、将来のリリースで解決される予定です（オープンソースのflannelの変更）。これらのパラメーターの詳細については、公式の[Flannel VXLAN](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan)バックエンドのドキュメントをご覧ください。 ##### DNS {#dns-limitations} -* ClusterFirstWithHostNet is not supported for DNS. Windows treats all names with a '.' as a FQDN and skips PQDN resolution -* On Linux, you have a DNS suffix list, which is used when trying to resolve PQDNs. On Windows, we only have 1 DNS suffix, which is the DNS suffix associated with that pod's namespace (mydns.svc.cluster.local for example). Windows can resolve FQDNs and services or names resolvable with just that suffix. For example, a pod spawned in the default namespace, will have the DNS suffix **default.svc.cluster.local**. On a Windows pod, you can resolve both **kubernetes.default.svc.cluster.local** and **kubernetes**, but not the in-betweens, like **kubernetes.default** or **kubernetes.default.svc**. +* ClusterFirstWithHostNetは、DNSでサポートされていません。Windowsでは、FQDNとしてすべての名前を「.」で扱い、PQDNでの名前解決はスキップします。 +* Linuxでは、PQDNで名前解決しようとするときに使用するDNSサフィックスリストがあります。Windowsでは、1つのDNSサフィックスしかありません。これは、そのPodのNamespaceに関連付けられているDNSサフィックスです（たとえば、mydns.svc.cluster.local）。Windowsでは、そのサフィックスだけで名前解決可能なFQDNおよびServiceまたはNameでの名前解決ができます。たとえば、defaultのNamespaceで生成されたPodには、DNSサフィックス**default.svc.cluster.local**が付けられます。WindowsのPodでは、**kubernetes.default.svc.cluster.local**と**kubernetes**の両方を名前解決できますが、**kubernetes.default**や**kubernetes.default.svc**のような中間での名前解決はできません。 +* Windowsでは、複数のDNSリゾルバーを使用できます。これらには少し異なる動作が付属しているため、ネームクエリの解決には`Resolve-DNSName`ユーティリティを使用することをお勧めします。 -##### Security +##### セキュリティ -Secrets are written in clear text on the node's volume (as compared to tmpfs/in-memory on linux). This means customers have to do two things +Secretはノードのボリュームに平文テキストで書き込まれます（Linuxのtmpfs/in-memoryの比較として）。これはカスタマーが2つのことを行う必要があります -1. Use file ACLs to secure the secrets file location -2. Use volume-level encryption using [BitLocker](https://docs.microsoft.com/en-us/windows/security/information-protection/bitlocker/bitlocker-how-to-deploy-on-windows-server) +1. ファイルACLを使用してSecretファイルの場所を保護する +2. [BitLocker](https://docs.microsoft.com/en-us/windows/security/information-protection/bitlocker/bitlocker-how-to-deploy-on-windows-server)を使って、ボリュームレベルの暗号化を使用する -[RunAsUser ](/ja/docs/concepts/policy/pod-security-policy/#users-and-groups)is not currently supported on Windows. The workaround is to create local accounts before packaging the container. The RunAsUsername capability may be added in a future release. +[RunAsUser](/docs/concepts/policy/pod-security-policy/#users-and-groups)は、現在Windowsではサポートされていません。回避策は、コンテナをパッケージ化する前にローカルアカウントを作成することです。RunAsUsername機能は、将来のリリースで追加される可能性があります。 -Linux specific pod security context privileges such as SELinux, AppArmor, Seccomp, Capabilities (POSIX Capabilities), and others are not supported. +SELinux、AppArmor、Seccomp、特性（POSIX機能）のような、Linux固有のPodセキュリティ環境の権限はサポートされていません。 -In addition, as mentioned already, privileged containers are not supported on Windows. +さらに、既に述べたように特権付きコンテナは、Windowsにおいてサポートされていません。 #### API -There are no differences in how most of the Kubernetes APIs work for Windows. The subtleties around what's different come down to differences in the OS and container runtime. In certain situations, some properties on workload APIs such as Pod or Container were designed with an assumption that they are implemented on Linux, failing to run on Windows. +ほとんどのKubernetes APIがWindowsでも機能することに違いはありません。そのわずかな違いはOSとコンテナランタイムの違いによるものです。特定の状況では、PodやコンテナなどのワークロードAPIの一部のプロパティが、Linuxで実装されているが、Windowsでは実行できないことを前提に設計されています。 -At a high level, these OS concepts are different: +高いレベルで、これらOSのコンセプトに違いがります。: -* Identity - Linux uses userID (UID) and groupID (GID) which are represented as integer types. User and group names are not canonical - they are just an alias in `/etc/groups` or `/etc/passwd` back to UID+GID. Windows uses a larger binary security identifier (SID) which is stored in the Windows Security Access Manager (SAM) database. This database is not shared between the host and containers, or between containers. -* File permissions - Windows uses an access control list based on SIDs, rather than a bitmask of permissions and UID+GID -* File paths - convention on Windows is to use `\` instead of `/`. The Go IO libraries typically accept both and just make it work, but when you're setting a path or command line that's interpreted inside a container, `\` may be needed. -* Signals - Windows interactive apps handle termination differently, and can implement one or more of these: - * A UI thread handles well-defined messages including WM_CLOSE - * Console apps handle ctrl-c or ctrl-break using a Control Handler - * Services register a Service Control Handler function that can accept SERVICE_CONTROL_STOP control codes +* ID - Linuxでは、Integer型として表されるuserID（UID）とgroupID（GID）を使用します。ユーザー名とグループ名は正規ではありません - それらは、UID+GIDの背後にある`/etc/groups`または`/etc/passwd`の単なるエイリアスです。Windowsは、Windows Security Access Manager（SAM）データベースに格納されているより大きなバイナリセキュリティ識別子（SID）を使用します。このデータベースは、ホストとコンテナ間、またはコンテナ間で共有されません。 +* ファイル権限 - Windowsは、権限とUID+GIDのビットマスクではなく、SIDに基づくアクセス制御リストを使用します +* ファイルパス - Windowsの規則では、`/`ではなく`\`を使用します。Go IOライブラリは通常両方を受け入れ、それを機能させるだけですが、コンテナ内で解釈されるパスまたはコマンドラインを設定する場合、`\`が必要になる場合があります。 +* シグナル - Windowsのインタラクティブなアプリは終了を異なる方法で処理し、次の1つ以上を実装できます。: + * UIスレッドは、WM_CLOSEを含む明確に定義されたメッセージを処理します + * コンソールアプリは、コントロールハンドラーを使用してctrl-cまたはctrl-breakを処理します + * サービスは、SERVICE_CONTROL_STOP制御コードを受け入れることができるサービスコントロールハンドラー関数を登録します。 -Exit Codes follow the same convention where 0 is success, nonzero is failure. The specific error codes may differ across Windows and Linux. However, exit codes passed from the Kubernetes components (kubelet, kube-proxy) are unchanged. +終了コードは、0が成功、0以外が失敗の場合と同じ規則に従います。特定のエラーコードは、WindowsとLinuxで異なる場合があります。ただし、Kubernetesのコンポーネント（kubelet、kube-proxy）から渡される終了コードは変更されていません。 ##### V1.Container -* V1.Container.ResourceRequirements.limits.cpu and V1.Container.ResourceRequirements.limits.memory - Windows doesn't use hard limits for CPU allocations. Instead, a share system is used. The existing fields based on millicores are scaled into relative shares that are followed by the Windows scheduler. [see: kuberuntime/helpers_windows.go](https://github.com/kubernetes/kubernetes/blob/master/pkg/kubelet/kuberuntime/helpers_windows.go), [see: resource controls in Microsoft docs](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/resource-controls) - * Huge pages are not implemented in the Windows container runtime, and are not available. They require [asserting a user privilege](https://docs.microsoft.com/en-us/windows/desktop/Memory/large-page-support) that's not configurable for containers. -* V1.Container.ResourceRequirements.requests.cpu and V1.Container.ResourceRequirements.requests.memory - Requests are subtracted from node available resources, so they can be used to avoid overprovisioning a node. However, they cannot be used to guarantee resources in an overprovisioned node. They should be applied to all containers as a best practice if the operator wants to avoid overprovisioning entirely. -* V1.Container.SecurityContext.allowPrivilegeEscalation - not possible on Windows, none of the capabilities are hooked up -* V1.Container.SecurityContext.Capabilities - POSIX capabilities are not implemented on Windows -* V1.Container.SecurityContext.privileged - Windows doesn't support privileged containers -* V1.Container.SecurityContext.procMount - Windows doesn't have a /proc filesystem -* V1.Container.SecurityContext.readOnlyRootFilesystem - not possible on Windows, write access is required for registry & system processes to run inside the container -* V1.Container.SecurityContext.runAsGroup - not possible on Windows, no GID support -* V1.Container.SecurityContext.runAsNonRoot - Windows does not have a root user. The closest equivalent is ContainerAdministrator which is an identity that doesn't exist on the node. -* V1.Container.SecurityContext.runAsUser - not possible on Windows, no UID support as int. -* V1.Container.SecurityContext.seLinuxOptions - not possible on Windows, no SELinux -* V1.Container.terminationMessagePath - this has some limitations in that Windows doesn't support mapping single files. The default value is /dev/termination-log, which does work because it does not exist on Windows by default. +* V1.Container.ResourceRequirements.limits.cpuおよびV1.Container.ResourceRequirements.limits.memory - Windowsは、CPU割り当てにハード制限を使用しません。代わりに、共有システムが使用されます。ミリコアに基づく既存のフィールドは、Windowsスケジューラーによって追従される相対共有にスケーリングされます。[参照: kuberuntime/helpers_windows.go](https://github.com/kubernetes/kubernetes/blob/master/pkg/kubelet/kuberuntime/helpers_windows.go)、[参照: resource controls in Microsoft docs](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/resource-controls) + * Huge Pagesは、Windowsコンテナランタイムには実装されてないので、使用できません。コンテナに対して設定できない[ユーザー特権を主張](https://docs.microsoft.com/en-us/windows/desktop/Memory/large-page-support)する必要があります。 +* V1.Container.ResourceRequirements.requests.cpuおよびV1.Container.ResourceRequirements.requests.memory - リクエストはノードの利用可能なリソースから差し引かれるので、ノードのオーバープロビジョニングを回避するために使用できます。ただし、過剰にプロビジョニングされたノードのリソースを保証するために使用することはできません。オペレーターが完全にプロビジョニングし過ぎないようにする場合は、ベストプラクティスとしてこれらをすべてのコンテナに適用する必要があります。 +* V1.Container.SecurityContext.allowPrivilegeEscalation - Windowsでは使用できません、接続されている機能はありません +* V1.Container.SecurityContext.Capabilities - POSIX機能はWindowsでは実装されていません +* V1.Container.SecurityContext.privileged - Windowsでは特権コンテナをサポートしていません +* V1.Container.SecurityContext.procMount - Windowsでは/procファイルシステムがありません +* V1.Container.SecurityContext.readOnlyRootFilesystem - Windowsでは使用できません、レジストリおよびシステムプロセスがコンテナ内で実行するには、書き込みアクセスが必要です +* V1.Container.SecurityContext.runAsGroup - Windowsでは使用できません、GIDのサポートもありません +* V1.Container.SecurityContext.runAsNonRoot - Windowsではrootユーザーが存在しません。最も近いものは、ノードに存在しないIDであるContainerAdministratorです。 +* V1.Container.SecurityContext.runAsUser - Windowsでは使用できません。intとしてのUIDはサポートされていません。 +* V1.Container.SecurityContext.seLinuxOptions - Windowsでは使用できません、SELinuxがありません +* V1.Container.terminationMessagePath - これは、Windowsが単一ファイルのマッピングをサポートしないという点でいくつかの制限があります。デフォルト値は/dev/termination-logであり、デフォルトではWindowsに存在しないため動作します。 ##### V1.Pod -* V1.Pod.hostIPC, v1.pod.hostpid - host namespace sharing is not possible on Windows -* V1.Pod.hostNetwork - There is no Windows OS support to share the host network -* V1.Pod.dnsPolicy - ClusterFirstWithHostNet - is not supported because Host Networking is not supported on Windows. -* V1.Pod.podSecurityContext - see V1.PodSecurityContext below -* V1.Pod.shareProcessNamespace - this is a beta feature, and depends on Linux namespaces which are not implemented on Windows. Windows cannot share process namespaces or the container's root filesystem. Only the network can be shared. -* V1.Pod.terminationGracePeriodSeconds - this is not fully implemented in Docker on Windows, see: [reference](https://github.com/moby/moby/issues/25982). The behavior today is that the ENTRYPOINT process is sent CTRL_SHUTDOWN_EVENT, then Windows waits 5 seconds by default, and finally shuts down all processes using the normal Windows shutdown behavior. The 5 second default is actually in the Windows registry [inside the container](https://github.com/moby/moby/issues/25982#issuecomment-426441183), so it can be overridden when the container is built. -* V1.Pod.volumeDevices - this is a beta feature, and is not implemented on Windows. Windows cannot attach raw block devices to pods. -* V1.Pod.volumes - EmptyDir, Secret, ConfigMap, HostPath - all work and have tests in TestGrid - * V1.emptyDirVolumeSource - the Node default medium is disk on Windows. Memory is not supported, as Windows does not have a built-in RAM disk. -* V1.VolumeMount.mountPropagation - mount propagation is not supported on Windows. +* V1.Pod.hostIPC、v1.pod.hostpid - Windowsではホストのネームスペースを共有することはできません +* V1.Pod.hostNetwork - ホストのネットワークを共有するためのWindows OSサポートはありません +* V1.Pod.dnsPolicy - ClusterFirstWithHostNet - Windowsではホストネットワーキングがサポートされていないため、サポートされていません。 +* V1.Pod.podSecurityContext - 以下のV1.PodSecurityContextを参照 +* V1.Pod.shareProcessNamespace - これはベータ版の機能であり、Windowsに実装されていないLinuxのNamespace機能に依存しています。Windowsでは、プロセスのネームスペースまたはコンテナのルートファイルシステムを共有できません。共有できるのはネットワークだけです。 +* V1.Pod.terminationGracePeriodSeconds - これはWindowsのDockerに完全には実装されていません。[リファレンス](https://github.com/moby/moby/issues/25982)を参照してください。今日の動作では、ENTRYPOINTプロセスにCTRL_SHUTDOWN_EVENTが送信され、Windowsではデフォルトで5秒待機し、最後に通常のWindowsシャットダウン動作を使用してすべてのプロセスをシャットダウンします。5秒のデフォルトは、実際にはWindowsレジストリー[コンテナ内](https://github.com/moby/moby/issues/25982#issuecomment-426441183)にあるため、コンテナ作成時にオーバーライドできます。 +* V1.Pod.volumeDevices - これはベータ機能であり、Windowsには実装されていません。Windowsでは、rawブロックデバイスをPodに接続できません。 +* V1.Pod.volumes-EmptyDir、Secret、ConfigMap、HostPath - すべて動作し、TestGridにテストがあります + * V1.emptyDirVolumeSource - ノードのデフォルトのメディアはWindowsのディスクです。Windowsでは、RAMディスクが組み込まれていないため、メモリはサポートされていません。 +* V1.VolumeMount.mountPropagation - mount propagationは、Windowsではサポートされていません。 ##### V1.PodSecurityContext -None of the PodSecurityContext fields work on Windows. They're listed here for reference. +Windowsでは、PodSecurityContextフィールドはどれも機能しません。これらは参照用にここにリストされています。 -* V1.PodSecurityContext.SELinuxOptions - SELinux is not available on Windows -* V1.PodSecurityContext.RunAsUser - provides a UID, not available on Windows -* V1.PodSecurityContext.RunAsGroup - provides a GID, not available on Windows -* V1.PodSecurityContext.RunAsNonRoot - Windows does not have a root user. The closest equivalent is ContainerAdministrator which is an identity that doesn't exist on the node. -* V1.PodSecurityContext.SupplementalGroups - provides GID, not available on Windows -* V1.PodSecurityContext.Sysctls - these are part of the Linux sysctl interface. There's no equivalent on Windows. +* V1.PodSecurityContext.SELinuxOptions - SELinuxは、Windowsでは使用できません +* V1.PodSecurityContext.RunAsUser - UIDを提供しますが、Windowsでは使用できません +* V1.PodSecurityContext.RunAsGroup - GIDを提供しますが、Windowsでは使用できません +* V1.PodSecurityContext.RunAsNonRoot - Windowsにはrootユーザーがありません。最も近いものは、ノードに存在しないIDであるContainerAdministratorです。 +* V1.PodSecurityContext.SupplementalGroups - GIDを提供しますが、Windowsでは使用できません +* V1.PodSecurityContext.Sysctls - これらはLinuxのsysctlインターフェースの一部です。Windowsには同等のものはありません。 -## Getting Help and Troubleshooting {#troubleshooting} +## ヘルプとトラブルシューティングを学ぶ {#troubleshooting} -Your main source of help for troubleshooting your Kubernetes cluster should start with this [section](/ja/docs/tasks/debug-application-cluster/troubleshooting/). Some additional, Windows-specific troubleshooting help is included in this section. Logs are an important element of troubleshooting issues in Kubernetes. Make sure to include them any time you seek troubleshooting assistance from other contributors. Follow the instructions in the SIG-Windows [contributing guide on gathering logs](https://github.com/kubernetes/community/blob/master/sig-windows/CONTRIBUTING.md#gathering-logs). +Kubernetesクラスターのトラブルシューティングの主なヘルプソースは、この[セクション](/docs/tasks/debug-application-cluster/troubleshooting/)から始める必要があります。このセクションには、いくつか追加的な、Windows固有のトラブルシューティングヘルプが含まれています。ログは、Kubernetesにおけるトラブルシューティング問題の重要な要素です。他のコントリビューターからトラブルシューティングの支援を求めるときは、必ずそれらを含めてください。SIG-Windows[ログ収集に関するコントリビュートガイド](https://github.com/kubernetes/community/blob/master/sig-windows/CONTRIBUTING.md#gathering-logs)の指示に従ってください。 -1. How do I know start.ps1 completed successfully? +1. start.ps1が正常に完了したことをどのように確認できますか？ - You should see kubelet, kube-proxy, and (if you chose Flannel as your networking solution) flanneld host-agent processes running on your node, with running logs being displayed in separate PowerShell windows. In addition to this, your Windows node should be listed as "Ready" in your Kubernetes cluster. + ノード上でkubelet、kube-proxy、および（ネットワーキングソリューションとしてFlannelを選択した場合）flanneldホストエージェントプロセスが実行され、実行ログが個別のPowerShellウィンドウに表示されます。これに加えて、WindowsノードがKubernetesクラスターで「Ready」として表示されているはずです。 -1. Can I configure the Kubernetes node processes to run in the background as services? +1. Kubernetesノードのプロセスをサービスとしてバックグラウンドで実行するように構成できますか？ - Kubelet and kube-proxy are already configured to run as native Windows Services, offering resiliency by re-starting the services automatically in the event of failure (for example a process crash). You have two options for configuring these node components as services. + Kubeletとkube-proxyは、ネイティブのWindowsサービスとして実行するように既に構成されています、障害（例えば、プロセスのクラッシュ）が発生した場合にサービスを自動的に再起動することにより、復元性を提供します。これらのノードコンポーネントをサービスとして構成するには、2つのオプションがあります。 - 1. As native Windows Services + 1. ネイティブWindowsサービスとして - Kubelet & kube-proxy can be run as native Windows Services using `sc.exe`. + Kubeletとkube-proxyは、`sc.exe`を使用してネイティブのWindowsサービスとして実行できます。 ```powershell - # Create the services for kubelet and kube-proxy in two separate commands + # 2つの個別のコマンドでkubeletおよびkube-proxyのサービスを作成する sc.exe create binPath= " --service " - # Please note that if the arguments contain spaces, they must be escaped. + # 引数にスペースが含まれている場合は、エスケープする必要があることに注意してください。 sc.exe create kubelet binPath= "C:\kubelet.exe --service --hostname-override 'minion' " - # Start the services + # サービスを開始する Start-Service kubelet Start-Service kube-proxy - # Stop the service + # サービスを停止する Stop-Service kubelet (-Force) Stop-Service kube-proxy (-Force) - # Query the service status + # サービスの状態を問い合わせる Get-Service kubelet Get-Service kube-proxy ``` - 1. Using nssm.exe + 1. nssm.exeの使用 - You can also always use alternative service managers like [nssm.exe](https://nssm.cc/) to run these processes (flanneld, kubelet & kube-proxy) in the background for you. You can use this [sample script](https://github.com/Microsoft/SDN/tree/master/Kubernetes/flannel/register-svc.ps1), leveraging nssm.exe to register kubelet, kube-proxy, and flanneld.exe to run as Windows services in the background. + また、[nssm.exe](https://nssm.cc/)などの代替サービスマネージャーを使用して、これらのプロセス（flanneld、kubelet、kube-proxy）をバックグラウンドで実行することもできます。この[サンプルスクリプト](https://github.com/Microsoft/SDN/tree/master/Kubernetes/flannel/register-svc.ps1)を使用すると、nssm.exeを利用してkubelet、kube-proxy、flanneld.exeを登録し、Windowsサービスとしてバックグラウンドで実行できます。 ```powershell register-svc.ps1 -NetworkMode -ManagementIP -ClusterCIDR -KubeDnsServiceIP -LogDir - # NetworkMode = The network mode l2bridge (flannel host-gw, also the default value) or overlay (flannel vxlan) chosen as a network solution - # ManagementIP = The IP address assigned to the Windows node. You can use ipconfig to find this - # ClusterCIDR = The cluster subnet range. (Default value 10.244.0.0/16) - # KubeDnsServiceIP = The Kubernetes DNS service IP (Default value 10.96.0.10) - # LogDir = The directory where kubelet and kube-proxy logs are redirected into their respective output files (Default value C:\k) + # NetworkMode = ネットワークソリューションとして選択されたネットワークモードl2bridge（flannel host-gw、これもデフォルト値）またはoverlay（flannel vxlan） + # ManagementIP = Windowsノードに割り当てられたIPアドレス。 ipconfigを使用してこれを見つけることができます + # ClusterCIDR = クラスターのサブネット範囲。（デフォルト値 10.244.0.0/16） + # KubeDnsServiceIP = Kubernetes DNSサービスIP（デフォルト値 10.96.0.10） + # LogDir = kubeletおよびkube-proxyログがそれぞれの出力ファイルにリダイレクトされるディレクトリ（デフォルト値 C:\k） ``` - If the above referenced script is not suitable, you can manually configure nssm.exe using the following examples. + 上記のスクリプトが適切でない場合は、次の例を使用してnssm.exeを手動で構成できます。 ```powershell - # Register flanneld.exe + # flanneld.exeを登録する nssm install flanneld C:\flannel\flanneld.exe nssm set flanneld AppParameters --kubeconfig-file=c:\k\config --iface= --ip-masq=1 --kube-subnet-mgr=1 nssm set flanneld AppEnvironmentExtra NODE_NAME= nssm set flanneld AppDirectory C:\flannel nssm start flanneld - # Register kubelet.exe - # Microsoft releases the pause infrastructure container at mcr.microsoft.com/k8s/core/pause:1.2.0 - # For more info search for "pause" in the "Guide for adding Windows Nodes in Kubernetes" + # kubelet.exeを登録 + # マイクロソフトは、mcr.microsoft.com/k8s/core/pause:1.2.0としてポーズインフラストラクチャコンテナをリリース + # 詳細については、「KubernetesにWindowsノードを追加するためのガイド」で「pause」を検索してください nssm install kubelet C:\k\kubelet.exe nssm set kubelet AppParameters --hostname-override= --v=6 --pod-infra-container-image=mcr.microsoft.com/k8s/core/pause:1.2.0 --resolv-conf="" --allow-privileged=true --enable-debugging-handlers --cluster-dns= --cluster-domain=cluster.local --kubeconfig=c:\k\config --hairpin-mode=promiscuous-bridge --image-pull-progress-deadline=20m --cgroups-per-qos=false --log-dir= --logtostderr=false --enforce-node-allocatable="" --network-plugin=cni --cni-bin-dir=c:\k\cni --cni-conf-dir=c:\k\cni\config nssm set kubelet AppDirectory C:\k nssm start kubelet - # Register kube-proxy.exe (l2bridge / host-gw) + # kube-proxy.exeを登録する (l2bridge / host-gw) nssm install kube-proxy C:\k\kube-proxy.exe nssm set kube-proxy AppDirectory c:\k nssm set kube-proxy AppParameters --v=4 --proxy-mode=kernelspace --hostname-override=--kubeconfig=c:\k\config --enable-dsr=false --log-dir= --logtostderr=false @@ -401,7 +418,7 @@ Your main source of help for troubleshooting your Kubernetes cluster should star nssm set kube-proxy DependOnService kubelet nssm start kube-proxy - # Register kube-proxy.exe (overlay / vxlan) + # kube-proxy.exeを登録する (overlay / vxlan) nssm install kube-proxy C:\k\kube-proxy.exe nssm set kube-proxy AppDirectory c:\k nssm set kube-proxy AppParameters --v=4 --proxy-mode=kernelspace --feature-gates="WinOverlay=true" --hostname-override= --kubeconfig=c:\k\config --network-name=vxlan0 --source-vip= --enable-dsr=false --log-dir= --logtostderr=false @@ -410,68 +427,68 @@ Your main source of help for troubleshooting your Kubernetes cluster should star ``` - For initial troubleshooting, you can use the following flags in [nssm.exe](https://nssm.cc/) to redirect stdout and stderr to a output file: + 最初のトラブルシューティングでは、[nssm.exe](https://nssm.cc/)で次のフラグを使用して、stdoutおよびstderrを出力ファイルにリダイレクトできます。: ```powershell nssm set AppStdout C:\k\mysvc.log nssm set AppStderr C:\k\mysvc.log ``` - For additional details, see official [nssm usage](https://nssm.cc/usage) docs. + 詳細については、公式の[nssmの使用法](https://nssm.cc/usage)のドキュメントを参照してください。 -1. My Windows Pods do not have network connectivity +1. Windows Podにネットワーク接続がありません - If you are using virtual machines, ensure that MAC spoofing is enabled on all the VM network adapter(s). + 仮想マシンを使用している場合は、すべてのVMネットワークアダプターでMACスプーフィングが有効になっていることを確認してください。 -1. My Windows Pods cannot ping external resources +1. Windows Podが外部リソースにpingできません - Windows Pods do not have outbound rules programmed for the ICMP protocol today. However, TCP/UDP is supported. When trying to demonstrate connectivity to resources outside of the cluster, please substitute `ping ` with corresponding `curl ` commands. + 現在、Windows Podには、ICMPプロトコル用にプログラムされた送信ルールはありません。ただし、TCP/UDPはサポートされています。クラスター外のリソースへの接続を実証する場合は、`ping `に対応する`curl `コマンドに置き換えてください。 - If you are still facing problems, most likely your network configuration in [cni.conf](https://github.com/Microsoft/SDN/blob/master/Kubernetes/flannel/l2bridge/cni/config/cni.conf) deserves some extra attention. You can always edit this static file. The configuration update will apply to any newly created Kubernetes resources. + それでも問題が解決しない場合は、[cni.conf](https://github.com/Microsoft/SDN/blob/master/Kubernetes/flannel/l2bridge/cni/config/cni.conf)のネットワーク構成に値する可能性があるので、いくつかの特別な注意が必要です。この静的ファイルはいつでも編集できます。構成の更新は、新しく作成されたすべてのKubernetesリソースに適用されます。 - One of the Kubernetes networking requirements (see [Kubernetes model](/ja/docs/concepts/cluster-administration/networking/)) is for cluster communication to occur without NAT internally. To honor this requirement, there is an [ExceptionList](https://github.com/Microsoft/SDN/blob/master/Kubernetes/flannel/l2bridge/cni/config/cni.conf#L20) for all the communication where we do not want outbound NAT to occur. However, this also means that you need to exclude the external IP you are trying to query from the ExceptionList. Only then will the traffic originating from your Windows pods be SNAT'ed correctly to receive a response from the outside world. In this regard, your ExceptionList in `cni.conf` should look as follows: + Kubernetesのネットワーキング要件の1つ(参照[Kubernetesモデル](/ja/docs/concepts/cluster-administration/networking/))は、内部でNATを使用せずにクラスター通信を行うためのものです。この要件を遵守するために、すべての通信に[ExceptionList](https://github.com/Microsoft/SDN/blob/master/Kubernetes/flannel/l2bridge/cni/config/cni.conf#L20)があり、アウトバウンドNATが発生しないようにします。ただし、これは、クエリしようとしている外部IPをExceptionListから除外する必要があることも意味します。そうして初めて、Windows PodからのトラフィックがSNAT処理され、外部からの応答を受信できるようになります。この点で、`cni.conf`のExceptionListは次のようになります。: ```conf "ExceptionList": [ - "10.244.0.0/16", # Cluster subnet - "10.96.0.0/12", # Service subnet - "10.127.130.0/24" # Management (host) subnet + "10.244.0.0/16", # クラスターのサブネット + "10.96.0.0/12", # Serviceのサブネット + "10.127.130.0/24" # 管理 (ホスト) のサブネット ] ``` -1. My Windows node cannot access NodePort service +1. WindowsノードがNodePort Serviceにアクセスできません - Local NodePort access from the node itself fails. This is a known limitation. NodePort access works from other nodes or external clients. + ノード自体からのローカルNodePortアクセスは失敗します。これは既知の制限です。NodePortアクセスは、他のノードまたは外部クライアントから行えます。 -1. vNICs and HNS endpoints of containers are being deleted +1. コンテナのvNICとHNSエンドポイントが削除されています - This issue can be caused when the `hostname-override` parameter is not passed to [kube-proxy](/ja/docs/reference/command-line-tools-reference/kube-proxy/). To resolve it, users need to pass the hostname to kube-proxy as follows: + この問題は、`hostname-override`パラメータが[kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/)に渡されない場合に発生する可能性があります。これを解決するには、ユーザーは次のようにホスト名をkube-proxyに渡す必要があります。: ```powershell C:\k\kube-proxy.exe --hostname-override=$(hostname) ``` -1. With flannel my nodes are having issues after rejoining a cluster +1. flannelを使用すると、クラスターに再参加した後、ノードに問題が発生します - Whenever a previously deleted node is being re-joined to the cluster, flannelD tries to assign a new pod subnet to the node. Users should remove the old pod subnet configuration files in the following paths: + 以前に削除されたノードがクラスターに再参加するときはいつも、flannelDは新しいPodサブネットをノードに割り当てようとします。ユーザーは、次のパスにある古いPodサブネット構成ファイルを削除する必要があります。: ```powershell Remove-Item C:\k\SourceVip.json Remove-Item C:\k\SourceVipRequest.json ``` -1. After launching `start.ps1`, flanneld is stuck in "Waiting for the Network to be created" +1. `start.ps1`を起動した後、flanneldが「ネットワークが作成されるのを待っています」と表示されたままになります - There are numerous reports of this [issue which are being investigated](https://github.com/coreos/flannel/issues/1066); most likely it is a timing issue for when the management IP of the flannel network is set. A workaround is to simply relaunch start.ps1 or relaunch it manually as follows: + この[調査中の問題](https://github.com/coreos/flannel/issues/1066)に関する多数の報告があります。最も可能性が高いのは、flannelネットワークの管理IPが設定されるタイミングの問題です。回避策は、単純にstart.ps1を再起動するか、次のように手動で再起動することです。: ```powershell PS C:> [Environment]::SetEnvironmentVariable("NODE_NAME", "") PS C:> C:\flannel\flanneld.exe --kubeconfig-file=c:\k\config --iface= --ip-masq=1 --kube-subnet-mgr=1 ``` -1. My Windows Pods cannot launch because of missing `/run/flannel/subnet.env` +1. `/run/flannel/subnet.env`がないため、Windows Podを起動できません - This indicates that Flannel didn't launch correctly. You can either try to restart flanneld.exe or you can copy the files over manually from `/run/flannel/subnet.env` on the Kubernetes master to` C:\run\flannel\subnet.env` on the Windows worker node and modify the `FLANNEL_SUBNET` row to a different number. For example, if node subnet 10.244.4.1/24 is desired: + これは、Flannelが正しく起動しなかったことを示しています。 flanneld.exeの再起動を試みるか、Kubernetesマスターの`/run/flannel/subnet.env`からWindowsワーカーノードの`C:\run\flannel\subnet.env`に手動でファイルをコピーすることができます。「FLANNEL_SUBNET」行を別の番号に変更します。たとえば、ノードサブネット10.244.4.1/24が必要な場合は以下となります。: ```env FLANNEL_NETWORK=10.244.0.0/16 @@ -480,77 +497,91 @@ Your main source of help for troubleshooting your Kubernetes cluster should star FLANNEL_IPMASQ=true ``` -1. My Windows node cannot access my services using the service IP +1. WindowsノードがService IPを使用してServiceにアクセスできない - This is a known limitation of the current networking stack on Windows. Windows Pods are able to access the service IP however. + これは、Windows上の現在のネットワークスタックの既知の制限です。ただし、Windows PodはService IPにアクセスできます。 -1. No network adapter is found when starting kubelet +1. kubeletの起動時にネットワークアダプターが見つかりません - The Windows networking stack needs a virtual adapter for Kubernetes networking to work. If the following commands return no results (in an admin shell), virtual network creation — a necessary prerequisite for Kubelet to work — has failed: + WindowsネットワーキングスタックがKubernetesネットワーキングを動かすには、仮想アダプターが必要です。次のコマンドを実行しても結果が返されない場合（管理シェルで）、仮想ネットワークの作成（Kubeletが機能するために必要な前提条件）に失敗したことになります。: ```powershell Get-HnsNetwork | ? Name -ieq "cbr0" Get-NetAdapter | ? Name -Like "vEthernet (Ethernet*" ``` - Often it is worthwhile to modify the [InterfaceName](https://github.com/Microsoft/SDN/blob/master/Kubernetes/flannel/l2bridge/start.ps1#L6) parameter of the start.ps1 script, in cases where the host's network adapter isn't "Ethernet". Otherwise, consult the output of the `start-kubelet.ps1` script to see if there are errors during virtual network creation. + ホストのネットワークアダプターが「イーサネット」ではない場合、多くの場合、start.ps1スクリプトの[InterfaceName](https://github.com/microsoft/SDN/blob/master/Kubernetes/flannel/start.ps1#L6)パラメーターを修正する価値があります。そうでない場合は`start-kubelet.ps1`スクリプトの出力結果を調べて、仮想ネットワークの作成中にエラーがないか確認します。 -1. My Pods are stuck at "Container Creating" or restarting over and over +1. Podが「Container Creating」と表示されたまま動かなくなったり、何度も再起動を繰り返します - Check that your pause image is compatible with your OS version. The [instructions](https://docs.microsoft.com/en-us/virtualization/windowscontainers/kubernetes/deploying-resources) assume that both the OS and the containers are version 1803. If you have a later version of Windows, such as an Insider build, you need to adjust the images accordingly. Please refer to the Microsoft's [Docker repository](https://hub.docker.com/u/microsoft/) for images. Regardless, both the pause image Dockerfile and the sample service expect the image to be tagged as :latest. + PauseイメージがOSバージョンと互換性があることを確認してください。[説明](https://docs.microsoft.com/en-us/virtualization/windowscontainers/kubernetes/deploying-resources)では、OSとコンテナの両方がバージョン1803であると想定しています。それ以降のバージョンのWindowsを使用している場合は、Insiderビルドなどでは、それに応じてイメージを調整する必要があります。イメージについては、Microsoftの[Dockerレジストリ](https://hub.docker.com/u/microsoft/)を参照してください。いずれにしても、PauseイメージのDockerfileとサンプルサービスの両方で、イメージに:latestのタグが付けられていると想定しています。 - Starting with Kubernetes v1.14, Microsoft releases the pause infrastructure container at `mcr.microsoft.com/k8s/core/pause:1.2.0`. For more information search for "pause" in the [Guide for adding Windows Nodes in Kubernetes](../user-guide-windows-nodes). + Kubernetes v1.14以降、MicrosoftはPauseインフラストラクチャコンテナを`mcr.microsoft.com/k8s/core/pause:1.2.0`でリリースしています。詳細については、[KubernetesにWindowsノードを追加するためのガイド](../user-guide-windows-nodes)で「Pause」を検索してください。 -1. DNS resolution is not properly working +1. DNS名前解決が正しく機能していない - Check the DNS limitations for Windows in this [section](#dns-limitations). + この[セクション](#dns-limitations)でDNSの制限を確認してください。 -1. `kubectl port-forward` fails with "unable to do port forwarding: wincat not found" +1. `kubectl port-forward`が「ポート転送を実行できません:wincatが見つかりません」で失敗します - This was implemented in Kubernetes 1.15, and the pause infrastructure container `mcr.microsoft.com/k8s/core/pause:1.2.0`. Be sure to use these versions or newer ones. - If you would like to build your own pause infrastructure container, be sure to include [wincat](https://github.com/kubernetes-sigs/sig-windows-tools/tree/master/cmd/wincat) + これはKubernetes 1.15、およびPauseインフラストラクチャコンテナ`mcr.microsoft.com/k8s/core/pause:1.2.0`で実装されました。必ずこれらのバージョン以降を使用してください。 + 独自のPauseインフラストラクチャコンテナを構築する場合は、必ず[wincat](https://github.com/kubernetes-sigs/sig-windows-tools/tree/master/cmd/wincat)を含めてください。 -### Further investigation +1. Windows Serverノードがプロキシの背後にあるため、Kubernetesのインストールが失敗します -If these steps don't resolve your problem, you can get help running Windows containers on Windows nodes in Kubernetes through: + プロキシの背後にある場合は、次のPowerShell環境変数を定義する必要があります。: + ```PowerShell + [Environment]::SetEnvironmentVariable("HTTP_PROXY", "http://proxy.example.com:80/", [EnvironmentVariableTarget]::Machine) + [Environment]::SetEnvironmentVariable("HTTPS_PROXY", "http://proxy.example.com:443/", [EnvironmentVariableTarget]::Machine) + ``` -* StackOverflow [Windows Server Container](https://stackoverflow.com/questions/tagged/windows-server-container) topic -* Kubernetes Official Forum [discuss.kubernetes.io](https://discuss.kubernetes.io/) +1. `pause`コンテナとは何ですか + + Kubernetes Podでは、インフラストラクチャまたは「pause」コンテナが最初に作成され、コンテナエンドポイントをホストします。インフラストラクチャやワーカーコンテナなど、同じPodに属するコンテナは、共通のネットワークネームスペースとエンドポイント（同じIPとポートスペース）を共有します。Pauseコンテナは、ネットワーク構成を失うことなくクラッシュまたは再起動するワーカーコンテナに対応するために必要です。 + + 「pause」（インフラストラクチャ）イメージは、Microsoft Container Registry（MCR）でホストされています。`docker pull mcr.microsoft.com/k8s/core/pause:1.2.0`を使用してアクセスできます。詳細については、[DOCKERFILE](https://github.com/kubernetes-sigs/sig-windows-tools/tree/master/cmd/wincat)をご覧ください。 + +### さらなる調査 + +これらの手順で問題が解決しない場合は、次の方法で、KubernetesのWindowsノードでWindowsコンテナを実行する際のヘルプを利用できます。: + +* StackOverflow [Windows Server Container](https://stackoverflow.com/questions/tagged/windows-server-container)トピック +* Kubernetesオフィシャルフォーラム [discuss.kubernetes.io](https://discuss.kubernetes.io/) * Kubernetes Slack [#SIG-Windows Channel](https://kubernetes.slack.com/messages/sig-windows) -## Reporting Issues and Feature Requests +## IssueとFeatureリクエストの報告 -If you have what looks like a bug, or you would like to make a feature request, please use the [GitHub issue tracking system](https://github.com/kubernetes/kubernetes/issues). You can open issues on [GitHub](https://github.com/kubernetes/kubernetes/issues/new/choose) and assign them to SIG-Windows. You should first search the list of issues in case it was reported previously and comment with your experience on the issue and add additional logs. SIG-Windows Slack is also a great avenue to get some initial support and troubleshooting ideas prior to creating a ticket. +バグのようなものがある場合、またはFeatureリクエストを行う場合は、[GitHubのIssueシステム](https://github.com/kubernetes/kubernetes/issues)を使用してください。[GitHub](https://github.com/kubernetes/kubernetes/issues/new/choose)でIssueを開いて、SIG-Windowsに割り当てることができます。以前に報告された場合は、まずIssueリストを検索し、Issueについての経験をコメントして、追加のログを加える必要があります。SIG-Windows Slackは、チケットを作成する前に、初期サポートとトラブルシューティングのアイデアを得るための素晴らしい手段でもあります。 -If filing a bug, please include detailed information about how to reproduce the problem, such as: +バグを報告する場合は、問題の再現方法に関する次のような詳細情報を含めてください。: -* Kubernetes version: kubectl version -* Environment details: Cloud provider, OS distro, networking choice and configuration, and Docker version -* Detailed steps to reproduce the problem -* [Relevant logs](https://github.com/kubernetes/community/blob/master/sig-windows/CONTRIBUTING.md#gathering-logs) -* Tag the issue sig/windows by commenting on the issue with `/sig windows` to bring it to a SIG-Windows member's attention +* Kubernetesのバージョン: kubectlのバージョン +* 環境の詳細: クラウドプロバイダー、OSのディストリビューション、選択したネットワーキングと構成、およびDockerのバージョン +* 問題を再現するための詳細な手順 +* [関連するログ](https://github.com/kubernetes/community/blob/master/sig-windows/CONTRIBUTING.md#gathering-logs) +* `/sig windows`でIssueにコメントして、Issueにsig/windowsのタグを付けて、SIG-Windowsメンバーが気付くようにします ## {{% heading "whatsnext" %}} -We have a lot of features in our roadmap. An abbreviated high level list is included below, but we encourage you to view our [roadmap project](https://github.com/orgs/kubernetes/projects/8) and help us make Windows support better by [contributing](https://github.com/kubernetes/community/blob/master/sig-windows/). +ロードマップには多くの機能があります。高レベルの簡略リストを以下に示しますが、[ロードマッププロジェクト](https://github.com/orgs/kubernetes/projects/8)を見て、[貢献すること](https://github.com/kubernetes/community/blob/master/sig-windows/)によってWindowsサポートを改善することをお勧めします。 ### CRI-ContainerD -{{< glossary_tooltip term_id="containerd" >}} is another OCI-compliant runtime that recently graduated as a {{< glossary_tooltip text="CNCF" term_id="cncf" >}} project. It's currently tested on Linux, but 1.3 will bring support for Windows and Hyper-V. [[reference](https://blog.docker.com/2019/02/containerd-graduates-within-the-cncf/)] +{{< glossary_tooltip term_id="containerd" >}}は、最近{{< glossary_tooltip text="CNCF" term_id="cncf" >}}プロジェクトとして卒業した、もう1つのOCI準拠ランタイムです。現在Linuxでテストされていますが、1.3はWindowsとHyper-Vをサポートします。[[リファレンス](https://blog.docker.com/2019/02/containerd-graduates-within-the-cncf/)] -The CRI-ContainerD interface will be able to manage sandboxes based on Hyper-V. This provides a foundation where RuntimeClass could be implemented for new use cases including: +CRI-ContainerDインターフェイスは、Hyper-Vに基づいてサンドボックスを管理できるようになります。これにより、RuntimeClassを次のような新しいユースケースに実装できる基盤が提供されます: -* Hypervisor-based isolation between pods for additional security -* Backwards compatibility allowing a node to run a newer Windows Server version without requiring containers to be rebuilt -* Specific CPU/NUMA settings for a pod -* Memory isolation and reservations +* Pod間のハイパーバイザーベースの分離により、セキュリティを強化 +* 下位互換性により、コンテナの再構築を必要とせずにノードで新しいWindows Serverバージョンを実行 +* Podの特定のCPU/NUMA設定 +* メモリの分離と予約 -### Hyper-V isolation +### Hyper-V分離 -The existing Hyper-V isolation support, an experimental feature as of v1.10, will be deprecated in the future in favor of the CRI-ContainerD and RuntimeClass features mentioned above. To use the current features and create a Hyper-V isolated container, the kubelet should be started with feature gates `HyperVContainer=true` and the Pod should include the annotation `experimental.windows.kubernetes.io/isolation-type=hyperv`. In the experiemental release, this feature is limited to 1 container per Pod. +既存のHyper-V分離サポートは、v1.10の試験的な機能であり、上記のCRI-ContainerD機能とRuntimeClass機能を優先して将来廃止される予定です。現在の機能を使用してHyper-V分離コンテナを作成するには、kubeletのフィーチャーゲートを`HyperVContainer=true`で開始し、Podにアノテーション`experimental.windows.kubernetes.io/isolation-type=hyperv`を含める必要があります。実験的リリースでは、この機能はPodごとに1つのコンテナに制限されています。 ```yaml apiVersion: apps/v1 @@ -576,13 +607,11 @@ spec: - containerPort: 80 ``` -### Deployment with kubeadm and cluster API - -Kubeadm is becoming the de facto standard for users to deploy a Kubernetes cluster. Windows node support in kubeadm will come in a future release. We are also making investments in cluster API to ensure Windows nodes are properly provisioned. - -### A few other key features -* Beta support for Group Managed Service Accounts -* More CNIs -* More Storage Plugins +### kubeadmとクラスターAPIを使用したデプロイ +Kubeadmは、ユーザーがKubernetesクラスターをデプロイするための事実上の標準になりつつあります。kubeadmのWindowsノードのサポートは、将来のリリースで提供予定です。Windowsノードが適切にプロビジョニングされるように、クラスターAPIにも投資しています。 +### その他の主な機能 +* グループ管理サービスアカウントのベータサポート +* その他のCNI +* その他のストレージプラグイン diff --git a/content/ja/docs/setup/production-environment/windows/kubecluster.ps1-install.gif b/content/ja/docs/setup/production-environment/windows/kubecluster.ps1-install.gif new file mode 100644 index 0000000000..e3d94b9b54 Binary files /dev/null and b/content/ja/docs/setup/production-environment/windows/kubecluster.ps1-install.gif differ diff --git a/content/ja/docs/setup/production-environment/windows/kubecluster.ps1-join.gif b/content/ja/docs/setup/production-environment/windows/kubecluster.ps1-join.gif new file mode 100644 index 0000000000..828417d685 Binary files /dev/null and b/content/ja/docs/setup/production-environment/windows/kubecluster.ps1-join.gif differ diff --git a/content/ja/docs/setup/production-environment/windows/kubecluster.ps1-reset.gif b/content/ja/docs/setup/production-environment/windows/kubecluster.ps1-reset.gif new file mode 100644 index 0000000000..e71d40d6df Binary files /dev/null and b/content/ja/docs/setup/production-environment/windows/kubecluster.ps1-reset.gif differ diff --git a/content/ja/docs/setup/production-environment/windows/user-guide-windows-containers.md b/content/ja/docs/setup/production-environment/windows/user-guide-windows-containers.md index 24d61e8bbd..ee1ed7b9f1 100644 --- a/content/ja/docs/setup/production-environment/windows/user-guide-windows-containers.md +++ b/content/ja/docs/setup/production-environment/windows/user-guide-windows-containers.md @@ -27,44 +27,47 @@ Windows applications constitute a large portion of the services and applications To deploy a Windows container on Kubernetes, you must first create an example application. The example YAML file below creates a simple webserver application. Create a service spec named `win-webserver.yaml` with the contents below: ```yaml - apiVersion: v1 - kind: Service - metadata: - name: win-webserver - labels: - app: win-webserver - spec: - ports: - # the port that this service should serve on - - port: 80 - targetPort: 80 - selector: - app: win-webserver - type: NodePort - --- - apiVersion: extensions/v1beta1 - kind: Deployment +apiVersion: v1 +kind: Service +metadata: + name: win-webserver + labels: + app: win-webserver +spec: + ports: + # the port that this service should serve on + - port: 80 + targetPort: 80 + selector: + app: win-webserver + type: NodePort +--- +apiVersion: apps/v1 +kind: Deployment +metadata: + labels: + app: win-webserver + name: win-webserver +spec: + replicas: 2 + selector: + matchLabels: + app: win-webserver + template: metadata: labels: app: win-webserver name: win-webserver spec: - replicas: 2 - template: - metadata: - labels: - app: win-webserver - name: win-webserver - spec: - containers: - - name: windowswebserver - image: mcr.microsoft.com/windows/servercore:ltsc2019 - command: + containers: + - name: windowswebserver + image: mcr.microsoft.com/windows/servercore:ltsc2019 + command: - powershell.exe - -command - - "<#code used from https://gist.github.com/wagnerandrade/5424431#> ; $$listener = New-Object System.Net.HttpListener ; $$listener.Prefixes.Add('http://*:80/') ; $$listener.Start() ; $$callerCounts = @{} ; Write-Host('Listening at http://*:80/') ; while ($$listener.IsListening) { ;$$context = $$listener.GetContext() ;$$requestUrl = $$context.Request.Url ;$$clientIP = $$context.Request.RemoteEndPoint.Address ;$$response = $$context.Response ;Write-Host '' ;Write-Host('> {0}' -f $$requestUrl) ; ;$$count = 1 ;$$k=$$callerCounts.Get_Item($$clientIP) ;if ($$k -ne $$null) { $$count += $$k } ;$$callerCounts.Set_Item($$clientIP, $$count) ;$$ip=(Get-NetAdapter | Get-NetIpAddress); $$header='

Windows Container Web Server

' ;$$callerCountsString='' ;$$callerCounts.Keys | % { $$callerCountsString+='

IP {0} callerCount {1} ' -f $$ip[1].IPAddress,$$callerCounts.Item($$_) } ;$$footer='' ;$$content='{0}{1}{2}' -f $$header,$$callerCountsString,$$footer ;Write-Output $$content ;$$buffer = [System.Text.Encoding]::UTF8.GetBytes($$content) ;$$response.ContentLength64 = $$buffer.Length ;$$response.OutputStream.Write($$buffer, 0, $$buffer.Length) ;$$response.Close() ;$$responseStatus = $$response.StatusCode ;Write-Host('< {0}' -f $$responseStatus) } ; " - nodeSelector: - kubernetes.io/os: windows + - "<#code used from https://gist.github.com/wagnerandrade/5424431#> ; $$listener = New-Object System.Net.HttpListener ; $$listener.Prefixes.Add('http://*:80/') ; $$listener.Start() ; $$callerCounts = @{} ; Write-Host('Listening at http://*:80/') ; while ($$listener.IsListening) { ;$$context = $$listener.GetContext() ;$$requestUrl = $$context.Request.Url ;$$clientIP = $$context.Request.RemoteEndPoint.Address ;$$response = $$context.Response ;Write-Host '' ;Write-Host('> {0}' -f $$requestUrl) ; ;$$count = 1 ;$$k=$$callerCounts.Get_Item($$clientIP) ;if ($$k -ne $$null) { $$count = $$k } ;$$callerCounts.Set_Item($$clientIP, $$count) ;$$ip=(Get-NetAdapter | Get-NetIpAddress); $$header='

Windows Container Web Server

' ;$$callerCountsString='' ;$$callerCounts.Keys | % { $$callerCountsString='

IP {0} callerCount {1} ' -f $$ip[1].IPAddress,$$callerCounts.Item($$_) } ;$$footer='' ;$$content='{0}{1}{2}' -f $$header,$$callerCountsString,$$footer ;Write-Output $$content ;$$buffer = [System.Text.Encoding]::UTF8.GetBytes($$content) ;$$response.ContentLength64 = $$buffer.Length ;$$response.OutputStream.Write($$buffer, 0, $$buffer.Length) ;$$response.Close() ;$$responseStatus = $$response.StatusCode ;Write-Host('< {0}' -f $$responseStatus) } ; " + nodeSelector: + kubernetes.io/os: windows ``` {{< note >}} @@ -101,6 +104,18 @@ Port mapping is also supported, but for simplicity in this example the container Windows container hosts are not able to access the IP of services scheduled on them due to current platform limitations of the Windows networking stack. Only Windows pods are able to access service IPs. {{< /note >}} +## Observability + +### Capturing logs from workloads + +Logs are an important element of observability; they enable users to gain insights into the operational aspect of workloads and are a key ingredient to troubleshooting issues. Because Windows containers and workloads inside Windows containers behave differently from Linux containers, users had a hard time collecting logs, limiting operational visibility. Windows workloads for example are usually configured to log to ETW (Event Tracing for Windows) or push entries to the application event log. [LogMonitor](https://github.com/microsoft/windows-container-tools/tree/master/LogMonitor), an open source tool by Microsoft, is the recommended way to monitor configured log sources inside a Windows container. LogMonitor supports monitoring event logs, ETW providers, and custom application logs, piping them to STDOUT for consumption by `kubectl logs `. + +Follow the instructions in the LogMonitor GitHub page to copy its binaries and configuration files to all your containers and add the necessary entrypoints for LogMonitor to push your logs to STDOUT. + +## Using configurable Container usernames + +Starting with Kubernetes v1.16, Windows containers can be configured to run their entrypoints and processes with different usernames than the image defaults. The way this is achieved is a bit different from the way it is done for Linux containers. Learn more about it [here](/docs/tasks/configure-pod-container/configure-runasusername/). + ## Managing Workload Identity with Group Managed Service Accounts Starting with Kubernetes v1.14, Windows container workloads can be configured to use Group Managed Service Accounts (GMSA). Group Managed Service Accounts are a specific type of Active Directory account that provides automatic password management, simplified service principal name (SPN) management, and the ability to delegate the management to other administrators across multiple servers. Containers configured with a GMSA can access external Active Directory Domain resources while carrying the identity configured with the GMSA. Learn more about configuring and using GMSA for Windows containers [here](/docs/tasks/configure-pod-container/configure-gmsa/). @@ -116,22 +131,114 @@ Users can ensure Windows containers can be scheduled on the appropriate host usi * kubernetes.io/os = [windows|linux] * kubernetes.io/arch = [amd64|arm64|...] -If a Pod specification does not specify a nodeSelector like `"beta.kubernetes.io/os": windows`, it is possible the Pod can be scheduled on any host, Windows or Linux. This can be problematic since a Windows container can only run on Windows and a Linux container can only run on Linux. The best practice is to use a nodeSelector. +If a Pod specification does not specify a nodeSelector like `"kubernetes.io/os": windows`, it is possible the Pod can be scheduled on any host, Windows or Linux. This can be problematic since a Windows container can only run on Windows and a Linux container can only run on Linux. The best practice is to use a nodeSelector. However, we understand that in many cases users have a pre-existing large number of deployments for Linux containers, as well as an ecosystem of off-the-shelf configurations, such as community Helm charts, and programmatic Pod generation cases, such as with Operators. In those situations, you may be hesitant to make the configuration change to add nodeSelectors. The alternative is to use Taints. Because the kubelet can set Taints during registration, it could easily be modified to automatically add a taint when running on Windows only. -For example: `--register-with-taints='os=Win1809:NoSchedule'` +For example: `--register-with-taints='os=windows:NoSchedule'` By adding a taint to all Windows nodes, nothing will be scheduled on them (that includes existing Linux Pods). In order for a Windows Pod to be scheduled on a Windows node, it would need both the nodeSelector to choose Windows, and the appropriate matching toleration. ```yaml nodeSelector: - "beta.kubernetes.io/os": windows + kubernetes.io/os: windows + node.kubernetes.io/windows-build: '10.0.17763' tolerations: - key: "os" operator: "Equal" - value: "Win1809" + value: "windows" effect: "NoSchedule" ``` +### Handling multiple Windows versions in the same cluster +The Windows Server version used by each pod must match that of the node. If you want to use multiple Windows +Server versions in the same cluster, then you should set additional node labels and nodeSelectors. + +Kubernetes 1.17 automatically adds a new label `node.kubernetes.io/windows-build` to simplify this. If you're running an older version, then it's recommended to add this label manually to Windows nodes. + +This label reflects the Windows major, minor, and build number that need to match for compatibility. Here are values used today for each Windows Server version. + +| Product Name | Build Number(s) | +|--------------------------------------|------------------------| +| Windows Server 2019 | 10.0.17763 | +| Windows Server version 1809 | 10.0.17763 | +| Windows Server version 1903 | 10.0.18362 | + + +### Simplifying with RuntimeClass + +[RuntimeClass] can be used to simplify the process of using taints and tolerations. A cluster administrator can create a `RuntimeClass` object which is used to encapsulate these taints and tolerations. + + +1. Save this file to `runtimeClasses.yml`. It includes the appropriate `nodeSelector` for the Windows OS, architecture, and version. + +```yaml +apiVersion: node.k8s.io/v1beta1 +kind: RuntimeClass +metadata: + name: windows-2019 +handler: 'docker' +scheduling: + nodeSelector: + kubernetes.io/os: 'windows' + kubernetes.io/arch: 'amd64' + node.kubernetes.io/windows-build: '10.0.17763' + tolerations: + - effect: NoSchedule + key: os + operator: Equal + value: "windows" +``` + +1. Run `kubectl create -f runtimeClasses.yml` using as a cluster administrator +1. Add `runtimeClassName: windows-2019` as appropriate to Pod specs + +For example: + +```yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + name: iis-2019 + labels: + app: iis-2019 +spec: + replicas: 1 + template: + metadata: + name: iis-2019 + labels: + app: iis-2019 + spec: + runtimeClassName: windows-2019 + containers: + - name: iis + image: mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019 + resources: + limits: + cpu: 1 + memory: 800Mi + requests: + cpu: .1 + memory: 300Mi + ports: + - containerPort: 80 + selector: + matchLabels: + app: iis-2019 +--- +apiVersion: v1 +kind: Service +metadata: + name: iis +spec: + type: LoadBalancer + ports: + - protocol: TCP + port: 80 + selector: + app: iis-2019 +``` + +[RuntimeClass]: https://kubernetes.io/docs/concepts/containers/runtime-class/ \ No newline at end of file diff --git a/content/ja/docs/setup/production-environment/windows/user-guide-windows-nodes.md b/content/ja/docs/setup/production-environment/windows/user-guide-windows-nodes.md index 29035e15d9..6edce770c1 100644 --- a/content/ja/docs/setup/production-environment/windows/user-guide-windows-nodes.md +++ b/content/ja/docs/setup/production-environment/windows/user-guide-windows-nodes.md @@ -91,9 +91,9 @@ Once you have a Linux-based Kubernetes master node you are ready to choose a net 1. In the `net-conf.json` section of your `kube-flannel.yml`, double-check: 1. The cluster subnet (e.g. "10.244.0.0/16") is set as per your IP plan. - * VNI 4096 is set in the backend - * Port 4789 is set in the backend - 2. In the `cni-conf.json` section of your `kube-flannel.yml`, change the network name to `vxlan0`. + * VNI 4096 is set in the backend + * Port 4789 is set in the backend + 1. In the `cni-conf.json` section of your `kube-flannel.yml`, change the network name to `vxlan0`. Your `cni-conf.json` should look as follows: @@ -134,7 +134,18 @@ Once you have a Linux-based Kubernetes master node you are ready to choose a net kubectl get pods --all-namespaces ``` - ![alt_text](../flannel-master-kubeclt-get-pods.png "flannel master kubectl get pods screen capture") + The output looks like as follows: + + ``` + NAMESPACE NAME READY STATUS RESTARTS AGE + kube-system etcd-flannel-master 1/1 Running 0 1m + kube-system kube-apiserver-flannel-master 1/1 Running 0 1m + kube-system kube-controller-manager-flannel-master 1/1 Running 0 1m + kube-system kube-dns-86f4d74b45-hcx8x 3/3 Running 0 12m + kube-system kube-flannel-ds-54954 1/1 Running 0 1m + kube-system kube-proxy-Zjlxz 1/1 Running 0 1m + kube-system kube-scheduler-flannel-master 1/1 Running 0 1m + ``` Verify that the Flannel DaemonSet has the NodeSelector applied. @@ -142,13 +153,20 @@ Once you have a Linux-based Kubernetes master node you are ready to choose a net kubectl get ds -n kube-system ``` - ![alt_text](../flannel-master-kubectl-get-ds.png "flannel master kubectl get ds screen capture") + The output looks like as follows. The NodeSelector `beta.kubernetes.io/os=linux` is applied. + + ``` + NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE + kube-flannel-ds 2 2 2 2 2 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux 21d + kube-proxy 2 2 2 2 2 beta.kubernetes.io/os=linux 26d + ``` #### Join Windows Worker In this section we'll cover configuring a Windows node from scratch to join a cluster on-prem. If your cluster is on a cloud you'll likely want to follow the cloud specific guides in the next section. #### Preparing a Windows Node + {{< note >}} All code snippets in Windows sections are to be run in a PowerShell environment with elevated permissions (Admin). {{< /note >}} @@ -171,9 +189,28 @@ All code snippets in Windows sections are to be run in a PowerShell environment [Environment]::SetEnvironmentVariable("HTTPS_PROXY", "http://proxy.example.com:443/", [EnvironmentVariableTarget]::Machine) ``` - If after reboot you see the following error, you need to restart the docker service manually + After reboot, you can verify that the docker service is ready with the command below. - ![alt_text](../windows-docker-error.png "windows docker error screen capture") + ```PowerShell + docker version + ``` + + If you see error message like the following, you need to start the docker service manually. + + ``` + Client: + Version: 17.06.2-ee-11 + API version: 1.30 + Go version: go1.8.7 + Git commit: 06fc007 + Built: Thu May 17 06:14:39 2018 + OS/Arch: windows / amd64 + error during connect: Get http://%2F%2F.%2Fpipe%2Fdocker_engine/v1.30/version: open //./pipe/docker_engine: The system c + annot find the file specified. In the default daemon configuration on Windows, the docker client must be run elevated to + connect. This error may also indicate that the docker daemon is not running. + ``` + + You can start the docker service manually like below. ```PowerShell Start-Service docker @@ -220,7 +257,13 @@ wget https://raw.githubusercontent.com/Microsoft/SDN/master/Kubernetes/flannel/s {{< /note >}} ```PowerShell -.\start.ps1 -ManagementIP -NetworkMode overlay -ClusterCIDR -ServiceCIDR -KubeDnsServiceIP -LogDir +cd c:\k +.\start.ps1 -ManagementIP ` + -NetworkMode overlay ` + -ClusterCIDR ` + -ServiceCIDR ` + -KubeDnsServiceIP ` + -LogDir ``` | Parameter | Default Value | Notes | @@ -261,4 +304,3 @@ Kubeadm is becoming the de facto standard for users to deploy a Kubernetes clust Now that you've configured a Windows worker in your cluster to run Windows containers you may want to add one or more Linux nodes as well to run Linux containers. You are now ready to schedule Windows containers on your cluster. - diff --git a/content/ja/docs/setup/production-environment/windows/windows-docker-error.png b/content/ja/docs/setup/production-environment/windows/windows-docker-error.png deleted file mode 100644 index d00528c0d4..0000000000 Binary files a/content/ja/docs/setup/production-environment/windows/windows-docker-error.png and /dev/null differ diff --git a/content/ja/docs/setup/release/_index.md b/content/ja/docs/setup/release/_index.md index e930b48a08..8c812f72de 100755 --- a/content/ja/docs/setup/release/_index.md +++ b/content/ja/docs/setup/release/_index.md @@ -1,4 +1,4 @@ --- -title: "リリースノート及びバージョンスキュー" +title: "リリースノートおよびバージョンスキュー" weight: 10 --- diff --git a/content/ja/docs/setup/release/building-from-source.md b/content/ja/docs/setup/release/building-from-source.md deleted file mode 100644 index 21f056ce39..0000000000 --- a/content/ja/docs/setup/release/building-from-source.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: リリースのビルド -content_type: concept -card: - name: download - weight: 20 - title: リリースのビルド ---- - -ソースコードからリリースをビルドすることもできますし、既にビルドされたリリースをダウンロードすることも可能です。Kubernetesを開発する予定が無いのであれば、[リリースノート](/docs/setup/release/notes/)内にて既にビルドされたバージョンを使用することを推奨します。 - -Kubernetes のソースコードは[kubernetes/kubernetes](https://github.com/kubernetes/kubernetes)のリポジトリからダウンロードすることが可能です。 - - - -## ソースからのビルド - -単にソースからリリースをビルドするだけであれば、完全なGOの環境を準備する必要はなく、全てのビルドはDockerコンテナの中で行われます。 - -リリースをビルドすることは簡単です。 - -```shell -git clone https://github.com/kubernetes/kubernetes.git -cd kubernetes -make release -``` - -リリース手段の詳細な情報はkubernetes/kubernetes内の[`build`](http://releases.k8s.io/{{< param "githubbranch" >}}/build/)ディレクトリを参照して下さい。 - - diff --git a/content/ja/docs/setup/release/version-skew-policy.md b/content/ja/docs/setup/release/version-skew-policy.md index 19200d80a6..5c1a18b8ee 100644 --- a/content/ja/docs/setup/release/version-skew-policy.md +++ b/content/ja/docs/setup/release/version-skew-policy.md @@ -5,7 +5,7 @@ weight: 30 --- -このドキュメントでは、さまざまなKubernetesコンポーネント間でサポートされる最大のバージョンの差異（バージョンスキュー）について説明します。特定のクラスターデプロイツールは、バージョンの差異に追加の制限を加える場合があります。 +このドキュメントでは、さまざまなKubernetesコンポーネント間でサポートされる最大のバージョンの差異(バージョンスキュー)について説明します。特定のクラスターデプロイツールは、バージョンの差異に追加の制限を加える場合があります。 @@ -16,9 +16,10 @@ Kubernetesのバージョンは**x.y.z**の形式で表現され、**x**はメ Kubernetesプロジェクトでは、最新の3つのマイナーリリースについてリリースブランチを管理しています。 -セキュリティフィックスを含む適用可能な修正は、重大度や実行可能性によってはこれら3つのリリースブランチにバックポートされることもあります。パッチリリースは、[定期的](https://git.k8s.io/sig-release/releases/patch-releases.md#cadence)または必要に応じてこれらのブランチから分岐されます。[リリースマネージャー](https://git.k8s.io/sig-release/release-managers.md)グループがこれを決定しています。 +セキュリティフィックスを含む適用可能な修正は、重大度や実行可能性によってはこれら3つのリリースブランチにバックポートされることもあります。パッチリリースは、定期的または必要に応じてこれらのブランチから分岐されます。[パッチリリースチーム](https://github.com/kubernetes/sig-release/blob/master/release-engineering/role-handbooks/patch-release-team.md#release-timing)がこれを決定しています。パッチリリースチームは[リリースマネージャー](https://github.com/kubernetes/sig-release/blob/master/release-managers.md)の一部です。 +詳細は、[Kubernetesパッチリリース](https://github.com/kubernetes/sig-release/blob/master/releases/patch-releases.md)ページを参照してください。 -詳細は、Kubernetes[パッチリリース](https://git.k8s.io/sig-release/releases/patch-releases.md)ページを参照してください。 +マイナーリリースは約3ヶ月ごとに行われるため、マイナーリリースのブランチはそれぞれ約9ヶ月保守されます。 ## サポートされるバージョンの差異 @@ -51,7 +52,7 @@ HAクラスター内の`kube-apiserver`間にバージョンの差異がある ### kube-controller-manager、kube-scheduler、およびcloud-controller-manager -`kube-controller-manager`、`kube-scheduler`および`cloud-controller-manager`は、通信する`kube-apiserver`インスタンスよりも新しいバージョンであってはなりません。`kube-apiserver`のマイナーバージョンと一致することが期待されますが、1つ古いマイナーバージョンでも可能です（ライブアップグレードを可能にするため）。 +`kube-controller-manager`、`kube-scheduler`および`cloud-controller-manager`は、通信する`kube-apiserver`インスタンスよりも新しいバージョンであってはなりません。`kube-apiserver`のマイナーバージョンと一致することが期待されますが、1つ古いマイナーバージョンでも可能です(ライブアップグレードを可能にするため)。 例: @@ -59,17 +60,17 @@ HAクラスター内の`kube-apiserver`間にバージョンの差異がある * `kube-controller-manager`、`kube-scheduler`および`cloud-controller-manager`は**1.13**および**1.12**がサポートされます {{< note >}} -HAクラスター内の`kube-apiserver`間にバージョンの差異があり、これらのコンポーネントがクラスター内のいずれかの`kube-apiserver`と通信する場合（たとえばロードバランサーを経由して）、コンポーネントの有効なバージョンは少なくなります。 +HAクラスター内の`kube-apiserver`間にバージョンの差異があり、これらのコンポーネントがクラスター内のいずれかの`kube-apiserver`と通信する場合(たとえばロードバランサーを経由して)、コンポーネントの有効なバージョンは少なくなります。 {{< /note >}} 例: * `kube-apiserver`インスタンスが**1.13**および**1.12**であるとします -* いずれかの`kube-apiserver`インスタンスへ配信するロードバランサーと通信する`kube-controller-manager`、`kube-scheduler`および`cloud-controller-manager`は**1.12**がサポートされます（**1.13**はバージョン**1.12**の`kube-apiserver`よりも新しくなるためサポートされません） +* いずれかの`kube-apiserver`インスタンスへ配信するロードバランサーと通信する`kube-controller-manager`、`kube-scheduler`および`cloud-controller-manager`は**1.12**がサポートされます(**1.13**はバージョン**1.12**の`kube-apiserver`よりも新しくなるためサポートされません) ### kubectl -`kubectl`は`kube-apiserver`の1つ以内のバージョン（古い、または新しいもの）をサポートします。 +`kubectl`は`kube-apiserver`の1つ以内のバージョン(古い、または新しいもの)をサポートします。 例: @@ -83,25 +84,25 @@ HAクラスター内の`kube-apiserver`間にバージョンの差異がある 例: * `kube-apiserver`インスタンスが**1.13**および**1.12**であるとします -* `kubectl`は**1.13**および**1.12**がサポートされます（ほかのバージョンでは、ある`kube-apiserver`コンポーネントからマイナーバージョンが2つ以上離れる可能性があります） +* `kubectl`は**1.13**および**1.12**がサポートされます(ほかのバージョンでは、ある`kube-apiserver`コンポーネントからマイナーバージョンが2つ以上離れる可能性があります) ## サポートされるコンポーネントのアップグレード順序 -コンポーネント間でサポートされるバージョンの差異は、コンポーネントをアップグレードする順序に影響されます。このセクションでは、既存のクラスターをバージョン**1.n**から**1.(n+1)**へ移行するために、コンポーネントをアップグレードする順序を説明します。 +コンポーネント間でサポートされるバージョンの差異は、コンポーネントをアップグレードする順序に影響されます。このセクションでは、既存のクラスターをバージョン**1.n**から**1.(n+1)** へ移行するために、コンポーネントをアップグレードする順序を説明します。 ### kube-apiserver 前提条件: * シングルインスタンスのクラスターにおいて、既存の`kube-apiserver`インスタンスは**1.n**とします -* HAクラスターにおいて、既存の`kube-apiserver`は**1.n**または**1.(n+1)**とします（最新と最古の間で、最大で1つのマイナーバージョンの差異となります） -* サーバーと通信する`kube-controller-manager`、`kube-scheduler`および`cloud-controller-manager`はバージョン**1.n**とします（必ず既存のAPIサーバーのバージョンよりも新しいものでなく、かつ新しいAPIサーバーのバージョンの1つ以内のマイナーバージョンとなります） -* すべてのノードの`kubelet`インスタンスはバージョン**1.n**または**1.(n-1)**とします（必ず既存のAPIサーバーよりも新しいバージョンでなく、かつ新しいAPIサーバーのバージョンの2つ以内のマイナーバージョンとなります） +* HAクラスターにおいて、既存の`kube-apiserver`は**1.n**または**1.(n+1)** とします(最新と最古の間で、最大で1つのマイナーバージョンの差異となります) +* サーバーと通信する`kube-controller-manager`、`kube-scheduler`および`cloud-controller-manager`はバージョン**1.n**とします(必ず既存のAPIサーバーのバージョンよりも新しいものでなく、かつ新しいAPIサーバーのバージョンの1つ以内のマイナーバージョンとなります) +* すべてのノードの`kubelet`インスタンスはバージョン**1.n**または**1.(n-1)** とします(必ず既存のAPIサーバーよりも新しいバージョンでなく、かつ新しいAPIサーバーのバージョンの2つ以内のマイナーバージョンとなります) * 登録されたAdmission webhookは、新しい`kube-apiserver`インスタンスが送信するこれらのデータを扱うことができます: - * `ValidatingWebhookConfiguration`および`MutatingWebhookConfiguration`オブジェクトは、**1.(n+1)**で追加されたRESTリソースの新しいバージョンを含んで更新されます（または、v1.15から利用可能な[`matchPolicy: Equivalent`オプション](/docs/reference/access-authn-authz/extensible-admission-controllers/#matching-requests-matchpolicy)を使用してください） - * Webhookは送信されたRESTリソースの新しいバージョン、および**1.(n+1)**のバージョンで追加された新しいフィールドを扱うことができます + * `ValidatingWebhookConfiguration`および`MutatingWebhookConfiguration`オブジェクトは、**1.(n+1)** で追加されたRESTリソースの新しいバージョンを含んで更新されます(または、v1.15から利用可能な[`matchPolicy: Equivalent`オプション](/docs/reference/access-authn-authz/extensible-admission-controllers/#matching-requests-matchpolicy)を使用してください) + * Webhookは送信されたRESTリソースの新しいバージョン、および**1.(n+1)** のバージョンで追加された新しいフィールドを扱うことができます -`kube-apiserver`を**1.(n+1)**にアップグレードしてください。 +`kube-apiserver`を**1.(n+1)** にアップグレードしてください。 {{< note >}} [非推奨API](/docs/reference/using-api/deprecation-policy/)および[APIの変更ガイドライン](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api_changes.md)のプロジェクトポリシーにおいては、シングルインスタンスの場合でも`kube-apiserver`のアップグレードの際にマイナーバージョンをスキップしてはなりません。 @@ -111,17 +112,17 @@ HAクラスター内の`kube-apiserver`間にバージョンの差異がある 前提条件: -* これらのコンポーネントと通信する`kube-apiserver`インスタンスが**1.(n+1)**であること（これらのコントロールプレーンコンポーネントが、クラスター内の`kube-apiserver`インスタンスと通信できるHAクラスターでは、これらのコンポーネントをアップグレードする前にすべての`kube-apiserver`インスタンスをアップグレードしなければなりません） +* これらのコンポーネントと通信する`kube-apiserver`インスタンスが**1.(n+1)** であること(これらのコントロールプレーンコンポーネントが、クラスター内の`kube-apiserver`インスタンスと通信できるHAクラスターでは、これらのコンポーネントをアップグレードする前にすべての`kube-apiserver`インスタンスをアップグレードしなければなりません) -`kube-controller-manager`、`kube-scheduler`および`cloud-controller-manager`を**1.(n+1)**にアップグレードしてください。 +`kube-controller-manager`、`kube-scheduler`および`cloud-controller-manager`を**1.(n+1)** にアップグレードしてください。 ### kubelet 前提条件: -* `kubelet`と通信する`kube-apiserver`が**1.(n+1)**であること +* `kubelet`と通信する`kube-apiserver`が**1.(n+1)** であること -必要に応じて、`kubelet`インスタンスを**1.(n+1)**にアップグレードしてください（**1.n**や**1.(n-1)**のままにすることもできます）。 +必要に応じて、`kubelet`インスタンスを**1.(n+1)** にアップグレードしてください(**1.n**や**1.(n-1)** のままにすることもできます)。 {{< warning >}} `kube-apiserver`と2つのマイナーバージョンの`kubelet`インスタンスを使用してクラスターを実行させることは推奨されません: 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 new file mode 100644 index 0000000000..3d36d99539 --- /dev/null +++ b/content/ja/docs/tasks/access-application-cluster/list-all-running-container-images.md @@ -0,0 +1,112 @@ +--- +title: クラスターで実行されているすべてのコンテナイメージを一覧表示する +content_type: task +weight: 100 +--- + + + +このページでは、kubectlを使用して、クラスターで実行されているPodのすべてのコンテナイメージを一覧表示する方法を説明します。 + + + +## {{% heading "prerequisites" %}} + + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + + + + + +この演習では、kubectlを使用してクラスターで実行されているすべてのPodを取得し、出力をフォーマットしてそれぞれのコンテナの一覧を取得します。 + +## すべての名前空間のコンテナイメージを一覧表示する {#list-all-container-images-in-all-namespaces} + +- `kubectl get pods --all-namespaces`を使用して、すべての名前空間のPodを取得します +- `-o jsonpath={.. image}`を使用して、コンテナイメージ名のリストのみが含まれるように出力をフォーマットします。これは、返されたjsonの`image`フィールドを再帰的に解析します。 + - jsonpathの使い方については、[jsonpathリファレンス](/docs/user-guide/jsonpath/)を参照してください。 +- `tr`、`sort`、`uniq`などの標準ツールを使用して出力をフォーマットします。 + - `tr`を使用してスペースを改行に置換します。 + - `sort`を使用して結果を並べ替えます。 + - `uniq`を使用してイメージ数を集計します。 + +```sh +kubectl get pods --all-namespaces -o jsonpath="{..image}" |\ +tr -s '[[:space:]]' '\n' |\ +sort |\ +uniq -c +``` + +上記のコマンドは、返されるすべてのアイテムについて、`image`という名前のすべてのフィールドを再帰的に返します。 + +別の方法として、Pod内のimageフィールドへの絶対パスを使用することができます。これにより、フィールド名が繰り返されている場合でも正しいフィールドが取得されます。多くのフィールドは与えられたアイテム内で`name`と呼ばれます: + +```sh +kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}" +``` + +jsonpathは次のように解釈されます: + +- `.items[*]`: 各戻り値 +- `.spec`: 仕様の取得 +- `.containers[*]`: 各コンテナ +- `.image`: イメージの取得 + +{{< note >}} +例えば`kubectl get pod nginx`のように名前を指定して単一のPodを取得する場合、アイテムのリストではなく単一のPodが返されるので、パスの`.items[*]`部分は省略してください。 +{{< /note >}} + +## Podごとにコンテナイメージを一覧表示する {#list-container-images-by-pod} + +`range`を使用して要素を個別に繰り返し処理することにより、フォーマットをさらに制御できます。 + +```sh +kubectl get pods --all-namespaces -o=jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' |\ +sort +``` + +## Podのラベルを使用してコンテナイメージ一覧をフィルタリングする {#list-container-images-filtering-by-pod-namespace} + +特定のラベルに一致するPodのみを対象とするには、-lフラグを使用します。以下は、`app=nginx`に一致するラベルを持つPodのみに一致します。 + +```sh +kubectl get pods --all-namespaces -o=jsonpath="{..image}" -l app=nginx +``` + +## Podの名前空間でコンテナイメージ一覧をフィルタリングする {#list-container-images-filtering-by-pod-namespace} + +特定の名前空間のPodのみを対象とするには、namespaceフラグを使用します。以下は`kube-system`名前空間のPodのみに一致します。 + +```sh +kubectl get pods --namespace kube-system -o jsonpath="{..image}" +``` + +## jsonpathの代わりにgo-templateを使用してコンテナイメージを一覧表示する {#list-container-images-using-a-go-template-instead-of-jsonpath} + +jsonpathの代わりに、kubectlは[go-templates](https://golang.org/pkg/text/template/)を使用した出力のフォーマットをサポートしています: + + +```sh +kubectl get pods --all-namespaces -o go-template --template="{{range .items}}{{range .spec.containers}}{{.image}} {{end}}{{end}}" +``` + + + + + + + + + +## {{% heading "whatsnext" %}} + + +### 参照 + +* [jsonpath](/docs/user-guide/jsonpath/)参照ガイド +* [Go template](https://golang.org/pkg/text/template/)参照ガイド + + + + 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 8b0439ec3a..1fe8e47e7b 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 @@ -23,7 +23,7 @@ weight: 60 ## {{% heading "objectives" %}} -* 2つのHellow Worldアプリケーションを稼働させる。 +* 2つのHello Worldアプリケーションを稼働させる。 * Nodeのポートを公開するServiceオブジェクトを作成する。 * 稼働しているアプリケーションにアクセスするためにServiceオブジェクトを使用する。 diff --git a/content/ja/docs/tasks/access-application-cluster/web-ui-dashboard.md b/content/ja/docs/tasks/access-application-cluster/web-ui-dashboard.md index 99585c4631..8087e5602e 100644 --- a/content/ja/docs/tasks/access-application-cluster/web-ui-dashboard.md +++ b/content/ja/docs/tasks/access-application-cluster/web-ui-dashboard.md @@ -92,12 +92,12 @@ Kubeconfigの認証方法は、外部IDプロバイダーやx509証明書ベー 例: - ```conf -release=1.0 -tier=frontend -environment=pod -track=stable -``` + ```conf + release=1.0 + tier=frontend + environment=pod + track=stable + ``` - **Namespace**: Kubernetesは、同じ物理クラスターを基盤とする複数の仮想クラスターをサポートしています。これらの仮想クラスタは[名前空間](/docs/tasks/administer-cluster/namespaces/) と呼ばれます。これにより、リソースを論理的に名前のついたグループに分割することができます。 diff --git a/content/ja/docs/tasks/administer-cluster/coredns.md b/content/ja/docs/tasks/administer-cluster/coredns.md new file mode 100644 index 0000000000..068832e852 --- /dev/null +++ b/content/ja/docs/tasks/administer-cluster/coredns.md @@ -0,0 +1,79 @@ +--- +title: サービスディスカバリーにCoreDNSを使用する +min-kubernetes-server-version: v1.9 +content_type: task +--- + + +このページでは、CoreDNSのアップグレードプロセスと、kube-dnsの代わりにCoreDNSをインストールする方法を説明します。 + + +## {{% heading "prerequisites" %}} + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + + + + +## CoreDNSについて {#about-coredns} + +[CoreDNS](https://coredns.io)は、KubernetesクラスターDNSとして稼働させることができる柔軟で拡張可能なDNSサーバーです。Kubernetesと同様に、CoreDNSプロジェクトは{{< glossary_tooltip text="CNCF" term_id="cncf" >}}によってホストされています。 + +既存のデプロイでkube-dnsを置き換えるか、クラスターのデプロイとアップグレードを代行してくれるkubeadmのようなツールを使用することで、クラスターでkube-dnsの代わりにCoreDNSを使用することができます。 + + +## CoreDNSのインストール {#installing-coredns} + +kube-dnsの手動デプロイや置き換えについては、[CoreDNS GitHub project](https://github.com/coredns/deployment/tree/master/kubernetes)のドキュメントを参照してください。 + +## CoreDNSへの移行 {#migrating-to-coredns} + +### kubeadmを使用した既存のクラスターのアップグレード {#upgrading-an-existing-cluster-with-kubeadm} + +Kubernetesバージョン1.10以降では、`kube-dns`を使用しているクラスターを`kubeadm`を使用してアップグレードするときに、CoreDNSに移行することもできます。この場合、`kubeadm`は、`kube-dns` ConfigMapをベースにしてCoreDNS設定("Corefile")を生成し、フェデレーション、スタブドメイン、および上流のネームサーバーの設定を保持します。 + +kube-dnsからCoreDNSに移行する場合は、アップグレード時に必ず`CoreDNS`フィーチャーゲートを`true`に設定してください。たとえば、`v1.11.0`のアップグレードは次のようになります: +``` +kubeadm upgrade apply v1.11.0 --feature-gates=CoreDNS=true +``` + +Kubernetesバージョン1.13以降では、`CoreDNS`フィーチャーゲートが削除され、CoreDNSがデフォルトで使用されます。アップグレードしたクラスターでkube-dnsを使用する場合は、[こちら](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase#cmd-phase-addon)のガイドに従ってください。 + +1.11以前のバージョンでは、Corefileはアップグレード中に作成されたものによって**上書き**されます。**カスタマイズしている場合は、既存のConfigMapを保存する必要があります。** 新しいConfigMapが稼働したら、カスタマイズを再適用できます。 + +Kubernetesバージョン1.11以降でCoreDNSを実行している場合、アップグレード中、既存のCorefileは保持されます。 + + +### kubeadmを使用してCoreDNSの代わりにkube-dnsをインストールする {#installing-kube-dns-instead-of-coredns-with-kubeadm} + +{{< note >}} +Kubernetes 1.11では、CoreDNSは一般利用可能(GA)にアップグレードされ、デフォルトでインストールされます。 +{{< /note >}} + +1.13以前のバージョンにkube-dnsをインストールするには、`CoreDNS`フィーチャーゲートの値を`false`に設定します: + +``` +kubeadm init --feature-gates=CoreDNS=false +``` + +バージョン1.13以降の場合は、[こちら](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase#cmd-phase-addon)に記載されているガイドに従ってください。 + +## CoreDNSのアップグレード {#upgrading-coredns} + +CoreDNSはv1.9以降のKubernetesで使用できます。Kubernetesに同梱されているCoreDNSのバージョンと、CoreDNSに加えられた変更は[こちら](https://github.com/coredns/deployment/blob/master/kubernetes/CoreDNS-k8s_version.md)で確認できます。 + +CoreDNSだけをアップグレードしたい場合や、独自のカスタムイメージを使用したい場合は、CoreDNSを手動でアップグレードすることができます。スムーズなアップグレードのために役立つ[ガイドラインとウォークスルー](https://github.com/coredns/deployment/blob/master/kubernetes/Upgrading_CoreDNS.md)が用意されています。 + +## CoreDNSのチューニング {#tuning-coredns} + +リソース使用率が問題になる場合は、CoreDNSの設定を調整すると役立つ場合があります。詳細は、[CoreDNSのスケーリングに関するドキュメント](https://github.com/coredns/deployment/blob/master/kubernetes/Scaling_CoreDNS.md)を参照してください。 + + + +## {{% heading "whatsnext" %}} + + +[CoreDNS](https://coredns.io)は、`Corefile`を変更することで、kube-dnsよりも多くのユースケースをサポートするように設定することができます。詳細は[CoreDNSサイト](https://coredns.io/2017/05/08/custom-dns-entries-for-kubernetes/)を参照してください。 + + + diff --git a/content/ja/docs/tasks/administer-cluster/extended-resource-node.md b/content/ja/docs/tasks/administer-cluster/extended-resource-node.md new file mode 100644 index 0000000000..59156efd89 --- /dev/null +++ b/content/ja/docs/tasks/administer-cluster/extended-resource-node.md @@ -0,0 +1,169 @@ +--- +title: 拡張リソースをNodeにアドバタイズする +content_type: task +--- + + + +このページでは、Nodeに対して拡張リソースを指定する方法を説明します。拡張リソースを利用すると、Kubernetesにとって未知のノードレベルのリソースをクラスター管理者がアドバタイズできるようになります。 + +## {{% heading "prerequisites" %}} + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + + + +## Nodeの名前を取得する + +```shell +kubectl get nodes +``` + +この練習で使いたいNodeを1つ選んでください。 + +## Nodeの1つで新しい拡張リソースをアドバタイズする + +Node上の新しい拡張リソースをアドバタイズするには、HTTPのPATCHリクエストをKubernetes APIサーバーに送ります。たとえば、Nodeの1つに4つのドングルが接続されているとします。以下に、4つのドングルリソースをNodeにアドバタイズするPATCHリクエストの例を示します。 + +```shell +PATCH /api/v1/nodes/<選択したNodeの名前>/status HTTP/1.1 +Accept: application/json +Content-Type: application/json-patch+json +Host: k8s-master:8080 + +[ + { + "op": "add", + "path": "/status/capacity/example.com~1dongle", + "value": "4" + } +] +``` + +Kubernetesは、ドングルとは何かも、ドングルが何に利用できるのかを知る必要もないことに注意してください。上のPATCHリクエストは、ただNodeが4つのドングルと呼ばれるものを持っているとKubernetesに教えているだけです。 + +Kubernetes APIサーバーに簡単にリクエストを送れるように、プロキシーを実行します。 + +```shell +kubectl proxy +``` + +もう1つのコマンドウィンドウを開き、HTTPのPATCHリクエストを送ります。`<選択したNodeの名前>`の部分は、選択したNodeの名前に置き換えてください。 + +```shell +curl --header "Content-Type: application/json-patch+json" \ +--request PATCH \ +--data '[{"op": "add", "path": "/status/capacity/example.com~1dongle", "value": "4"}]' \ +http://localhost:8001/api/v1/nodes/<選択したNodeの名前>/status +``` + +{{< note >}} +上のリクエストにある`~1`は、PATCHのパスにおける`/`という文字をエンコーディングしたものです。JSON-Patch内のoperationのpathはJSON-Pointerとして解釈されます。詳細については、[IETF RFC 6901](https://tools.ietf.org/html/rfc6901)のsection 3を読んでください。 +{{< /note >}} + +出力には、Nodeがキャパシティー4のdongleを持っていることが示されます。 + +``` +"capacity": { + "cpu": "2", + "memory": "2049008Ki", + "example.com/dongle": "4", +``` + +Nodeの説明を確認します。 + +``` +kubectl describe node <選択したNodeの名前> +``` + +出力には、再びdongleリソースが表示されます。 + +```yaml +Capacity: + cpu: 2 + memory: 2049008Ki + example.com/dongle: 4 +``` + +これで、アプリケーション開発者は特定の数のdongleをリクエストするPodを作成できるようになりました。詳しくは、[拡張リソースをコンテナに割り当てる](/docs/tasks/configure-pod-container/extended-resource/)を読んでください。 + +## 議論 + +拡張リソースは、メモリやCPUリソースと同様のものです。たとえば、Nodeが持っている特定の量のメモリやCPUがNode上で動作している他のすべてのコンポーネントと共有されるのと同様に、Nodeが搭載している特定の数のdongleが他のすべてのコンポーネントと共有されます。そして、アプリケーション開発者が特定の量のメモリとCPUをリクエストするPodを作成できるのと同様に、Nodeが搭載している特定の数のdongleをリクエストするPodが作成できます。 + +拡張リソースはKubernetesには詳細を意図的に公開しないため、Kubernetesは拡張リソースの実体をまったく知りません。Kubernetesが知っているのは、Nodeが特定の数の拡張リソースを持っているということだけです。拡張リソースは整数値でアドバタイズしなければなりません。たとえば、Nodeは4つのdongleをアドバタイズできますが、4.5のdongleというのはアドバタイズできません。 + +### Storageの例 + +Nodeに800GiBの特殊なディスクストレージがあるとします。この特殊なストレージの名前、たとえばexample.com/special-storageという名前の拡張リソースが作れます。そして、そのなかの一定のサイズ、たとえば100GiBのチャンクをアドバタイズできます。この場合、Nodeはexample.com/special-storageという種類のキャパシティ8のリソースを持っているとアドバタイズします。 + +```yaml +Capacity: + ... + example.com/special-storage: 8 +``` + +特殊なストレージに任意のサイズのリクエストを許可したい場合、特殊なストレージを1バイトのサイズのチャンクでアドバタイズできます。その場合、example.com/special-storageという種類の800Giのリソースとしてアドバタイズします。 + +```yaml +Capacity: + ... + example.com/special-storage: 800Gi +``` + +すると、コンテナは好きなバイト数の特殊なストレージを最大800Giまでリクエストできるようになります。 + +## クリーンアップ + +以下に、dongleのアドバタイズをNodeから削除するPATCHリクエストを示します。 + +``` +PATCH /api/v1/nodes/<選択したNodeの名前>/status HTTP/1.1 +Accept: application/json +Content-Type: application/json-patch+json +Host: k8s-master:8080 + +[ + { + "op": "remove", + "path": "/status/capacity/example.com~1dongle", + } +] +``` + +Kubernetes APIサーバーに簡単にリクエストを送れるように、プロキシーを実行します。 + +```shell +kubectl proxy +``` + +もう1つのコマンドウィンドウで、HTTPのPATCHリクエストを送ります。`<選択したNodeの名前>`の部分は、選択したNodeの名前に置き換えてください。 + +```shell +curl --header "Content-Type: application/json-patch+json" \ +--request PATCH \ +--data '[{"op": "remove", "path": "/status/capacity/example.com~1dongle"}]' \ +http://localhost:8001/api/v1/nodes/<選択したNodeの名前>/status +``` + +dongleのアドバタイズが削除されたことを検証します。 + +``` +kubectl describe node <選択したNodeの名前> | grep dongle +``` + +(出力には何も表示されないはずです) + +## {{% heading "whatsnext" %}} + +### アプリケーション開発者向け + +* [拡張リソースをコンテナに割り当てる](/ja/docs/tasks/configure-pod-container/extended-resource/) + +### クラスター管理者向け + +* [Namespaceに対してメモリの最小値と最大値の制約を設定する](/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/) +* [Namespaceに対してCPUの最小値と最大値の制約を設定する](/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/) + + + 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 e98cee60d8..9a06821517 100644 --- a/content/ja/docs/tasks/administer-cluster/running-cloud-controller.md +++ b/content/ja/docs/tasks/administer-cluster/running-cloud-controller.md @@ -9,7 +9,7 @@ content_type: concept Kubernetes v1.6では`cloud-controller-manager`という新しいバイナリが導入されました。`cloud-controller-manager`はクラウド固有の制御ループを組み込むデーモンです。これらのクラウド固有の制御ループはもともと`kube-controller-manager`にありました。クラウドプロバイダーはKubernetesプロジェクトとは異なるペースで開発およびリリースされるため、プロバイダー固有のコードを`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のコアから移行することが期待されています。今後のKubernetesのリリースでは、すべてのクラウドコントローラーマネージャーはsigリードまたはクラウドベンダーが管理するKubernetesのコアプロジェクトの外で開発される予定です。 @@ -24,7 +24,7 @@ Kubernetes v1.6では`cloud-controller-manager`という新しいバイナリが * クラウドの認証/認可: クラウドではAPIへのアクセスを許可するためにトークンまたはIAMルールが必要になる場合があります * kubernetesの認証/認可: cloud-controller-managerは、kubernetes apiserverと通信するためにRBACルールの設定を必要とする場合があります -* 高可用性: kube-controller-managerのように、リーダー選出を使用したクラウドコントローラーマネージャーの高可用性のセットアップが必要になる場合があります（デフォルトでオンになっています）。 +* 高可用性: kube-controller-managerのように、リーダー選出を使用したクラウドコントローラーマネージャーの高可用性のセットアップが必要になる場合があります(デフォルトでオンになっています)。 ### cloud-controller-managerを動かす @@ -35,7 +35,7 @@ cloud-controller-managerを正常に実行するにはクラスター構成に クラウドコントローラーマネージャーを使用するようにクラスターを設定するとクラスターの動作がいくつか変わることに注意してください。 -* `--cloud-provider=external`を指定したkubeletは、初期化時に`NoSchedule`の`node.cloudprovider.kubernetes.io/uninitialized`汚染を追加します。これによりノードは作業をスケジュールする前に外部のコントローラーからの2回目の初期化が必要であるとマークされます。クラウドコントローラーマネージャーが使用できない場合クラスター内の新しいノードはスケジュールできないままになることに注意してください。スケジューラーはリージョンやタイプ（高CPU、GPU、高メモリ、スポットインスタンスなど）などのノードに関するクラウド固有の情報を必要とする場合があるためこの汚染は重要です。 +* `--cloud-provider=external`を指定したkubeletは、初期化時に`NoSchedule`の`node.cloudprovider.kubernetes.io/uninitialized`汚染を追加します。これによりノードは作業をスケジュールする前に外部のコントローラーからの2回目の初期化が必要であるとマークされます。クラウドコントローラーマネージャーが使用できない場合クラスター内の新しいノードはスケジュールできないままになることに注意してください。スケジューラーはリージョンやタイプ(高CPU、GPU、高メモリ、スポットインスタンスなど)などのノードに関するクラウド固有の情報を必要とする場合があるためこの汚染は重要です。 * クラスター内のノードに関するクラウド情報はローカルメタデータを使用して取得されなくなりましたが、代わりにノード情報を取得するためのすべてのAPI呼び出しはクラウドコントローラーマネージャーを経由して行われるようになります。これはセキュリティを向上させるためにkubeletでクラウドAPIへのアクセスを制限できることを意味します。大規模なクラスターではクラスター内からクラウドのほとんどすべてのAPI呼び出しを行うため、クラウドコントローラーマネージャーがレートリミットに達するかどうかを検討する必要があります。 v1.8の時点でクラウドコントローラーマネージャーは以下を実装できます。 @@ -69,7 +69,7 @@ Kubernetesのコアリポジトリにないクラウドコントローラーマ ### ボリュームのサポート -ボリュームの統合にはkubeletとの調整も必要になるためクラウドコントローラーマネージャーは`kube-controller-manager`にあるボリュームコントローラーを実装しません。CSI（コンテナストレージインターフェイス）が進化してFlexボリュームプラグインの強力なサポートが追加されるにつれ、クラウドがボリュームと完全に統合できるようクラウドコントローラーマネージャーに必要なサポートが追加されます。Kubernetesリポジトリの外部にあるCSIボリュームプラグインの詳細については[こちら](https://github.com/kubernetes/features/issues/178)をご覧ください。 +ボリュームの統合にはkubeletとの調整も必要になるためクラウドコントローラーマネージャーは`kube-controller-manager`にあるボリュームコントローラーを実装しません。CSI(コンテナストレージインターフェイス)が進化してFlexボリュームプラグインの強力なサポートが追加されるにつれ、クラウドがボリュームと完全に統合できるようクラウドコントローラーマネージャーに必要なサポートが追加されます。Kubernetesリポジトリの外部にあるCSIボリュームプラグインの詳細については[こちら](https://github.com/kubernetes/features/issues/178)をご覧ください。 ### スケーラビリティ @@ -79,7 +79,7 @@ Kubernetesのコアリポジトリにないクラウドコントローラーマ クラウドコントローラーマネージャープロジェクトの目標はKubernetesのコアプロジェクトからクラウドに関する機能の開発を切り離すことです。残念ながら、Kubernetesプロジェクトの多くの面でクラウドプロバイダーの機能がKubernetesプロジェクトに緊密に結びついているという前提があります。そのため、この新しいアーキテクチャを採用するとクラウドプロバイダーの情報を要求する状況が発生する可能性がありますが、クラウドコントローラーマネージャーはクラウドプロバイダーへのリクエストが完了するまでその情報を返すことができない場合があります。 -これの良い例は、KubeletのTLSブートストラップ機能です。現在、TLSブートストラップはKubeletがすべてのアドレスタイプ（プライベート、パブリックなど）をクラウドプロバイダー（またはローカルメタデータサービス）に要求する能力を持っていると仮定していますが、クラウドコントローラーマネージャーは最初に初期化されない限りノードのアドレスタイプを設定できないためapiserverと通信するためにはkubeletにTLS証明書が必要です。 +これの良い例は、KubeletのTLSブートストラップ機能です。現在、TLSブートストラップはKubeletがすべてのアドレスタイプ(プライベート、パブリックなど)をクラウドプロバイダー(またはローカルメタデータサービス)に要求する能力を持っていると仮定していますが、クラウドコントローラーマネージャーは最初に初期化されない限りノードのアドレスタイプを設定できないためapiserverと通信するためにはkubeletにTLS証明書が必要です。 このイニシアチブが成熟するに連れ、今後のリリースでこれらの問題に対処するための変更が行われます。 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 5940705cdd..8091ded576 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 @@ -196,7 +196,7 @@ kubectl delete pod cpu-demo-2 --namespace=cpu-example クラスターで動作するコンテナにCPU要求と制限を設定することで、クラスターのノードで利用可能なCPUリソースを効率的に使用することができます。PodのCPU要求を低く保つことで、Podがスケジュールされやすくなります。CPU要求よりも大きい制限を与えることで、次の2つを実現できます: -* Podは利用可能なCPUリソースを、突発的な活動（バースト）に使用することができます。 +* Podは利用可能なCPUリソースを、突発的な活動(バースト)に使用することができます。 * バースト中のPodのCPUリソース量は、適切な量に制限されます。 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 fb361dfa72..1af80012fc 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 @@ -97,7 +97,7 @@ resources: kubectl top pod memory-demo --namespace=mem-example ``` -この出力では、Podが約162,900,000バイト（約150MiB）のメモリーを使用していることを示しています。Podの100MiBの要求を超えていますが、200MiBの制限には収まっています。 +この出力では、Podが約162,900,000バイト(約150MiB)のメモリーを使用していることを示しています。Podの100MiBの要求を超えていますが、200MiBの制限には収まっています。 ``` NAME CPU(cores) MEMORY(bytes) @@ -278,7 +278,7 @@ kubectl delete pod memory-demo-3 --namespace=mem-example クラスターで動作するコンテナにメモリー要求と制限を設定することで、クラスターのノードで利用可能なメモリーリソースを効率的に使用することができます。Podのメモリー要求を低く保つことで、Podがスケジュールされやすくなります。メモリー要求よりも大きい制限を与えることで、次の2つを実現できます: -* Podは利用可能なメモリーを、突発的な活動（バースト）に使用することができます。 +* Podは利用可能なメモリーを、突発的な活動(バースト)に使用することができます。 * バースト中のPodのメモリー使用量は、適切な量に制限されます。 ## クリーンアップ diff --git a/content/ja/docs/tasks/configure-pod-container/assign-pods-nodes.md b/content/ja/docs/tasks/configure-pod-container/assign-pods-nodes.md new file mode 100644 index 0000000000..e2e4e1d647 --- /dev/null +++ b/content/ja/docs/tasks/configure-pod-container/assign-pods-nodes.md @@ -0,0 +1,93 @@ +--- +title: Podをノードに割り当てる +content_type: task +weight: 120 +--- + + +このページでは、KubernetesのPodをKubernetesクラスター上の特定のノードに割り当てる方法を説明します。 + +## {{% heading "prerequisites" %}} + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + + + +## ラベルをノードに追加する + +1. クラスター内の{{< glossary_tooltip term_id="node" text="ノード" >}}のリストをラベル付きで表示します。 + + ```shell + kubectl get nodes --show-labels + ``` + + 出力は次のようになります。 + + ```shell + NAME STATUS ROLES AGE VERSION LABELS + worker0 Ready 1d v1.13.0 ...,kubernetes.io/hostname=worker0 + worker1 Ready 1d v1.13.0 ...,kubernetes.io/hostname=worker1 + worker2 Ready 1d v1.13.0 ...,kubernetes.io/hostname=worker2 + ``` +1. ノードの1つを選択して、ラベルを追加します。 + + ```shell + kubectl label nodes disktype=ssd + ``` + + ここで、``は選択したノードの名前です。 + +1. 選択したノードに`disktype=ssd`ラベルがあることを確認します。 + + ```shell + kubectl get nodes --show-labels + ``` + + 出力は次のようになります。 + + ```shell + NAME STATUS ROLES AGE VERSION LABELS + worker0 Ready 1d v1.13.0 ...,disktype=ssd,kubernetes.io/hostname=worker0 + worker1 Ready 1d v1.13.0 ...,kubernetes.io/hostname=worker1 + worker2 Ready 1d v1.13.0 ...,kubernetes.io/hostname=worker2 + ``` + + 上の出力を見ると、`worker0`に`disktype=ssd`というラベルがあることがわかります。 + +## 選択したノードにスケジューリングされるPodを作成する + +以下のPodの構成ファイルには、nodeSelectorに`disktype: ssd`を持つPodが書かれています。これにより、Podは`disktype: ssd`というラベルを持っているノードにスケジューリングされるようになります。 + +{{< codenew file="pods/pod-nginx.yaml" >}} + +1. 構成ファイルを使用して、選択したノードにスケジューリングされるPodを作成します。 + + ```shell + kubectl apply -f https://k8s.io/examples/pods/pod-nginx.yaml + ``` + +1. Podが選択したノード上で実行されているをことを確認します。 + + ```shell + kubectl get pods --output=wide + ``` + + 出力は次のようになります。 + + ```shell + NAME READY STATUS RESTARTS AGE IP NODE + nginx 1/1 Running 0 13s 10.200.0.4 worker0 + ``` + +## 特定のノードにスケジューリングされるPodを作成する + +`nodeName`という設定を使用して、Podを特定のノードにスケジューリングすることもできます。 + +{{< codenew file="pods/pod-nginx-specific-node.yaml" >}} + +構成ファイルを使用して、`foo-node`にだけスケジューリングされるPodを作成します。 + +## {{% heading "whatsnext" %}} + +* [ラベルとセレクター](/ja/docs/concepts/overview/working-with-objects/labels/)についてさらに学ぶ。 +* [ノード](/ja/docs/concepts/architecture/nodes/)についてさらに学ぶ。 diff --git a/content/ja/docs/tasks/configure-pod-container/configure-projected-volume-storage.md b/content/ja/docs/tasks/configure-pod-container/configure-projected-volume-storage.md index f8e7341bb2..c67c826c4d 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-projected-volume-storage.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-projected-volume-storage.md @@ -5,7 +5,7 @@ weight: 70 --- -このページでは、[`projected`](/docs/concepts/storage/volumes/#projected)（投影）ボリュームを使用して、既存の複数のボリュームソースを同一ディレクトリ内にマウントする方法を説明します。 +このページでは、[`projected`](/docs/concepts/storage/volumes/#projected)(投影)ボリュームを使用して、既存の複数のボリュームソースを同一ディレクトリ内にマウントする方法を説明します。 現在、`secret`、`configMap`、`downwardAPI`および`serviceAccountToken`ボリュームを投影できます。 {{< note >}} diff --git a/content/ja/docs/tasks/configure-pod-container/configure-volume-storage.md b/content/ja/docs/tasks/configure-pod-container/configure-volume-storage.md index 87fa5d965e..a7bb1a0d65 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-volume-storage.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-volume-storage.md @@ -87,7 +87,7 @@ weight: 50 root@redis:/data/redis# kill ``` - ここで``はRedisプロセスID（PID）です。 + ここで``はRedisプロセスID(PID)です。 1. 元の端末で、Redis Podへの変更を監視します。最終的には、このようなものが表示されます: diff --git a/content/ja/docs/tasks/configure-pod-container/extended-resource.md b/content/ja/docs/tasks/configure-pod-container/extended-resource.md new file mode 100644 index 0000000000..b056fc7389 --- /dev/null +++ b/content/ja/docs/tasks/configure-pod-container/extended-resource.md @@ -0,0 +1,124 @@ +--- +title: 拡張リソースをコンテナに割り当てる +content_type: task +weight: 40 +--- + + + +{{< feature-state state="stable" >}} + +このページでは、拡張リソースをコンテナに割り当てる方法について説明します。 + +## {{% heading "prerequisites" %}} + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +この練習を始める前に、[Nodeに拡張リソースをアドバタイズする](/ja/docs/tasks/administer-cluster/extended-resource-node/)の練習を行ってください。これにより、Nodeの1つがドングルリソースをアドバタイズするように設定されます。 + + + +## 拡張リソースをPodに割り当てる + +拡張リソースをリクエストするには、コンテナのマニフェストに`resources:requests`フィールドを含めます。拡張リソースは、`*.kubernetes.io/`以外の任意のドメインで完全修飾されます。有効な拡張リソース名は、`example.com/foo`という形式になります。ここで、`example.com`はあなたの組織のドメインで、`foo`は記述的なリソース名で置き換えます。 + +1つのコンテナからなるPodの構成ファイルを示します。 + +{{< codenew file="pods/resource/extended-resource-pod.yaml" >}} + +構成ファイルでは、コンテナが3つのdongleをリクエストしていることがわかります。 + +次のコマンドでPodを作成します。 + +```shell +kubectl apply -f https://k8s.io/examples/pods/resource/extended-resource-pod.yaml +``` + +Podが起動したことを確認します。 + +```shell +kubectl get pod extended-resource-demo +``` + +Podの説明を表示します。 + +```shell +kubectl describe pod extended-resource-demo +``` + +dongleのリクエストが表示されます。 + +```yaml +Limits: + example.com/dongle: 3 +Requests: + example.com/dongle: 3 +``` + +## 2つ目のPodの作成を試みる + +以下に、1つのコンテナを持つPodの構成ファイルを示します。コンテナは2つのdongleをリクエストします。 + +{{< codenew file="pods/resource/extended-resource-pod-2.yaml" >}} + +Kubernetesは、2つのdongleのリクエストを満たすことができません。1つ目のPodが、利用可能な4つのdongleのうち3つを使用してしまっているためです。 + +Podを作成してみます。 + +```shell +kubectl apply -f https://k8s.io/examples/pods/resource/extended-resource-pod-2.yaml +``` + +Podの説明を表示します。 + +```shell +kubectl describe pod extended-resource-demo-2 +``` + +出力にはPodがスケジュールできないことが示されます。2つのdongleが利用できるNodeが存在しないためです。 + +``` +Conditions: + Type Status + PodScheduled False +... +Events: + ... + ... Warning FailedScheduling pod (extended-resource-demo-2) failed to fit in any node +fit failure summary on nodes : Insufficient example.com/dongle (1) +``` + +Podのステータスを表示します。 + +```shell +kubectl get pod extended-resource-demo-2 +``` + +出力には、Podは作成されたものの、Nodeにスケジュールされなかったことが示されています。PodはPending状態になっています。 + +```yaml +NAME READY STATUS RESTARTS AGE +extended-resource-demo-2 0/1 Pending 0 6m +``` + +## クリーンアップ + +この練習で作成したPodを削除します。 + +```shell +kubectl delete pod extended-resource-demo +kubectl delete pod extended-resource-demo-2 +``` + +## {{% heading "whatsnext" %}} + +### アプリケーション開発者向け + +* [コンテナおよびPodへのメモリーリソースの割り当て](/ja/docs/tasks/configure-pod-container/assign-memory-resource/) +* [コンテナおよびPodへのCPUリソースの割り当て](/ja/docs/tasks/configure-pod-container/assign-cpu-resource/) + +### クラスター管理者向け + +* [Nodeに拡張リソースをアドバタイズする](/ja/docs/tasks/administer-cluster/extended-resource-node/) + + diff --git a/content/ja/docs/tasks/configure-pod-container/share-process-namespace.md b/content/ja/docs/tasks/configure-pod-container/share-process-namespace.md index 513da2365c..b5fd61777e 100644 --- a/content/ja/docs/tasks/configure-pod-container/share-process-namespace.md +++ b/content/ja/docs/tasks/configure-pod-container/share-process-namespace.md @@ -97,7 +97,7 @@ Podは多くのリソースを共有するため、プロセスの名前空間 ただし、一部のコンテナイメージは他のコンテナから分離されることが期待されるため、これらの違いを理解することが重要です: 1. **コンテナプロセスは PID 1ではなくなります。** - 一部のコンテナイメージは、PID 1なしで起動することを拒否し（たとえば、`systemd`を使用するコンテナ）、`kill -HUP 1`などのコマンドを実行してコンテナプロセスにシグナルを送信します。 + 一部のコンテナイメージは、PID 1なしで起動することを拒否し(たとえば、`systemd`を使用するコンテナ)、`kill -HUP 1`などのコマンドを実行してコンテナプロセスにシグナルを送信します。 共有プロセス名前空間を持つPodでは、`kill -HUP 1`はPodサンドボックスにシグナルを送ります。(上の例では`/pause`) 1. **プロセスはPod内の他のコンテナに表示されます。** diff --git a/content/ja/docs/tasks/debug-application-cluster/debug-init-containers.md b/content/ja/docs/tasks/debug-application-cluster/debug-init-containers.md index 5577881c95..fa5255ca7f 100644 --- a/content/ja/docs/tasks/debug-application-cluster/debug-init-containers.md +++ b/content/ja/docs/tasks/debug-application-cluster/debug-init-containers.md @@ -14,7 +14,7 @@ content_type: task {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -* [Initコンテナ](/ja/docs/concepts/abstractions/init-containers/)の基本を理解しておきましょう。 +* [Initコンテナ](/ja/docs/concepts/workloads/pods/init-containers/)の基本を理解しておきましょう。 * [Initコンテナを設定](/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container/)しておきましょう。 @@ -100,7 +100,7 @@ kubectl logs -c -## Podのステータスを理解する +## Podのステータスを理解する {#understanding-pod-status} `Init：`で始まるPodステータスはInitコンテナの実行ステータスを要約します。以下の表は、Initコンテナのデバッグ中に表示される可能性のあるステータス値の例をいくつか示しています。 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 c4c965458b..a8332cbcfb 100644 --- a/content/ja/docs/tasks/debug-application-cluster/debug-service.md +++ b/content/ja/docs/tasks/debug-application-cluster/debug-service.md @@ -4,9 +4,7 @@ title: Serviceのデバッグ --- -新規にKubernetesをインストールした環境でかなり頻繁に発生する問題は、Serviceが適切に機能しないというものです。 -Deployment（または他のワークロードコントローラー）を通じてPodを実行し、サービスを作成したにもかかわらず、アクセスしようとしても応答がありません。 -何が問題になっているのかを理解するのに、このドキュメントがきっと役立つでしょう。 +新規にKubernetesをインストールした環境でかなり頻繁に発生する問題は、Serviceが適切に機能しないというものです。Deployment(または他のワークロードコントローラー)を通じてPodを実行し、サービスを作成したにもかかわらず、アクセスしようとしても応答がありません。何が問題になっているのかを理解するのに、このドキュメントがきっと役立つでしょう。 @@ -16,8 +14,7 @@ Deployment（または他のワークロードコントローラー）を通じ ## Pod内でコマンドを実行する -ここでの多くのステップでは、クラスターで実行されているPodが見ているものを確認する必要があります。 -これを行う最も簡単な方法は、インタラクティブなalpineのPodを実行することです。 +ここでの多くのステップでは、クラスターで実行されているPodが見ているものを確認する必要があります。これを行う最も簡単な方法は、インタラクティブなalpineのPodを実行することです。 ```none kubectl run -it --rm --restart=Never alpine --image=alpine sh @@ -27,7 +24,7 @@ kubectl run -it --rm --restart=Never alpine --image=alpine sh コマンドプロンプトが表示されない場合は、Enterキーを押してみてください。 {{< /note >}} -使用したい実行中のPodが既にある場合は、以下のようにしてそのPod内でコマンドを実行できます。 +使用したい実行中のPodがすでにある場合は、以下のようにしてそのPod内でコマンドを実行できます。 ```shell kubectl exec -c -- @@ -35,8 +32,7 @@ kubectl exec -c -- ## セットアップ -このドキュメントのウォークスルーのために、いくつかのPodを実行しましょう。 -おそらくあなた自身のServiceをデバッグしているため、あなた自身の詳細に置き換えることもできますし、これに沿って2番目のデータポイントを取得することもできます。 +このドキュメントのウォークスルーのために、いくつかのPodを実行しましょう。おそらくあなた自身のServiceをデバッグしているため、あなた自身の詳細に置き換えることもできますし、これに沿って2番目のデータポイントを取得することもできます。 ```shell kubectl run hostnames --image=k8s.gcr.io/serve_hostname \ @@ -48,7 +44,7 @@ deployment.apps/hostnames created `kubectl`コマンドは作成、変更されたリソースのタイプと名前を出力するため、この後のコマンドで使用することもできます。 -{{< note >}} + これは、次のYAMLでDeploymentを開始した場合と同じです。 ```yaml @@ -72,7 +68,6 @@ spec: ``` "run"ラベルは`kubectl run`によって、Deploymentの名前に自動的にセットされます。 -{{< /note >}} Podが実行されていることを確認できます。 @@ -86,8 +81,7 @@ hostnames-632524106-ly40y 1/1 Running 0 2m hostnames-632524106-tlaok 1/1 Running 0 2m ``` -Podが機能していることも確認できます。 -Pod IP アドレスリストを取得し、直接テストできます。 +Podが機能していることも確認できます。Pod IP アドレスリストを取得し、直接テストできます。 ```shell kubectl get pods -l run=hostnames \ @@ -117,8 +111,7 @@ hostnames-bvc05 hostnames-yp2kp ``` -この時点で期待通りの応答が得られない場合、Podが正常でないか、想定しているポートでリッスンしていない可能性があります。 -なにが起きているかを確認するために`kubectl logs`が役立ちます、Podに直接に入りデバッグする場合は `kubectl exec`が必要になります。 +この時点で期待通りの応答が得られない場合、Podが正常でないか、想定しているポートでリッスンしていない可能性があります。なにが起きているかを確認するために`kubectl logs`が役立ちます。Podに直接に入りデバッグする場合は`kubectl exec`が必要になります。 これまでにすべての計画が完了していると想定すると、Serviceが機能しない理由を調査することができます。 @@ -126,8 +119,7 @@ hostnames-yp2kp 賢明な読者は、Serviceをまだ実際に作成していないことにお気付きかと思いますが、これは意図的です。これは時々忘れられるステップであり、最初に確認すべきことです。 -存在しないServiceにアクセスしようとするとどうなるでしょうか？ -このServiceを名前で利用する別のPodがあると仮定すると、次のような結果が得られます。 +存在しないServiceにアクセスしようとするとどうなるでしょうか？このServiceを名前で利用する別のPodがあると仮定すると、次のような結果が得られます。 ```shell wget -O- hostnames @@ -147,8 +139,7 @@ No resources found. Error from server (NotFound): services "hostnames" not found ``` -Serviceを作成しましょう。 -前と同様に、これはウォークスルー用です。ご自身のServiceの詳細を使用することもできます。 +Serviceを作成しましょう。前と同様に、これはウォークスルー用です。ご自身のServiceの詳細を使用することもできます。 ```shell kubectl expose deployment hostnames --port=80 --target-port=9376 @@ -169,7 +160,6 @@ hostnames ClusterIP 10.0.1.175 80/TCP 5s これで、Serviceが存在することがわかりました。 -{{< note >}} 前と同様に、これは次のようなYAMLでServiceを開始した場合と同じです。 ```yaml @@ -187,14 +177,11 @@ spec: targetPort: 9376 ``` -構成の全範囲をハイライトするため、ここで作成したServiceはPodとは異なるポート番号を使用します。 -多くの実際のServiceでは、これらのポートは同じになる場合があります。 -{{< /note >}} +構成の全範囲をハイライトするため、ここで作成したServiceはPodとは異なるポート番号を使用します。多くの実際のServiceでは、これらのポートは同じになる場合があります。 ## サービスはDNS名によって機能しているか？ -クライアントがサービスを使用する最も一般的な方法の1つは、DNS名を使用することです。 -同じNamespaceのPodから次のコマンドを実行してください。 +クライアントがサービスを使用する最も一般的な方法の1つは、DNS名を使用することです。同じNamespaceのPodから次のコマンドを実行してください。 ```shell nslookup hostnames @@ -219,8 +206,7 @@ Name: hostnames.default Address 1: 10.0.1.175 hostnames.default.svc.cluster.local ``` -これが機能する場合、クロスネームスペース名を使用するようにアプリケーションを調整するか、同じNamespaceでアプリとServiceを実行する必要があります。 -これでも失敗する場合は、完全修飾名を試してください。 +これが機能する場合、クロスネームスペース名を使用するようにアプリケーションを調整するか、同じNamespaceでアプリとServiceを実行する必要があります。これでも失敗する場合は、完全修飾名を試してください。 ```shell nslookup hostnames.default.svc.cluster.local @@ -232,10 +218,7 @@ Name: hostnames.default.svc.cluster.local Address 1: 10.0.1.175 hostnames.default.svc.cluster.local ``` -ここでのサフィックス"default.svc.cluster.local"に注意してください。 -"default"は、操作しているNamespaceです。 -"svc"は、これがServiceであることを示します。 -"cluster.local"はクラスタードメインであり、あなたのクラスターでは異なる場合があります。 +ここでのサフィックス"default.svc.cluster.local"に注意してください。"default"は、操作しているNamespaceです。"svc"は、これがServiceであることを示します。"cluster.local"はクラスタードメインであり、あなたのクラスターでは異なる場合があります。 クラスター内のノードからも試すこともできます。 @@ -254,8 +237,7 @@ Name: hostnames.default.svc.cluster.local Address: 10.0.1.175 ``` -完全修飾名では検索できるのに、相対名ではできない場合、Podの`/etc/resolv.conf`ファイルが正しいことを確認する必要があります。 -Pod内から実行します。 +完全修飾名では検索できるのに、相対名ではできない場合、Podの`/etc/resolv.conf`ファイルが正しいことを確認する必要があります。Pod内から実行します。 ```shell cat /etc/resolv.conf @@ -269,25 +251,15 @@ search default.svc.cluster.local svc.cluster.local cluster.local example.com options ndots:5 ``` -nameserver行はクラスターのDNS Serviceを示さなければなりません。 -これは、`--cluster-dns`フラグで`kubelet`に渡されます。 +nameserver行はクラスターのDNS Serviceを示さなければなりません。これは、`--cluster-dns`フラグで`kubelet`に渡されます。 -`search`行には、`Service`名を見つけるための適切なサフィックスを含める必要があります。 -この場合、ローカルの`Namespace`で`Service`を見つけるためのサフィックス(`default.svc.cluster.local`)、すべての`Namespaces`で`Service`を見つけるためのサフィックス(`svc.cluster.local`)、およびクラスターのサフィックス(`cluster.local`)です。 -インストール方法によっては、その後に追加のレコードがある場合があります(合計6つまで)。 -クラスターのサフィックスは、`--cluster-domain`フラグを使用して`kubelet`に渡されます。 -このドキュメントではそれが"cluster.local"であると仮定していますが、あなたのクラスターでは異なる場合があります。 -その場合は、上記のすべてのコマンドでクラスターのサフィックスを変更する必要があります。 +`search`行には、`Service`名を見つけるための適切なサフィックスを含める必要があります。この場合、ローカルの`Namespace`で`Service`を見つけるためのサフィックス(`default.svc.cluster.local`)、すべての`Namespaces`で`Service`を見つけるためのサフィックス(`svc.cluster.local`)、およびクラスターのサフィックス(`cluster.local`)です。インストール方法によっては、その後に追加のレコードがある場合があります(合計6つまで)。クラスターのサフィックスは、`--cluster-domain`フラグを使用して`kubelet`に渡されます。このドキュメントではそれが"cluster.local"であると仮定していますが、あなたのクラスターでは異なる場合があります。その場合は、上記のすべてのコマンドでクラスターのサフィックスを変更する必要があります。 -`options`行では、DNSクライアントライブラリーが検索パスをまったく考慮しないように`ndots`を十分に高く設定する必要があります。 -Kubernetesはデフォルトでこれを5に設定します。これは、生成されるすべてのDNS名をカバーするのに十分な大きさです。 +`options`行では、DNSクライアントライブラリーが検索パスをまったく考慮しないように`ndots`を十分に高く設定する必要があります。Kubernetesはデフォルトでこれを5に設定します。これは、生成されるすべてのDNS名をカバーするのに十分な大きさです。 -### DNS名で機能するServiceはありますか？ {#does-any-service-exist-in-dns} +### DNS名で機能するServiceはあるか？ {#does-any-service-exist-in-dns} -上記がまだ失敗する場合、DNSルックアップがServiceに対して機能していません。 -一歩離れて、他の何が機能していないかを確認しましょう。 -KubernetesマスターのServiceは常に機能するはずです。 -Pod内から実行します。 +上記がまだ失敗する場合、DNSルックアップがServiceに対して機能していません。一歩離れて、他の何が機能していないかを確認しましょう。KubernetesマスターのServiceは常に機能するはずです。Pod内から実行します。 ```shell nslookup kubernetes.default @@ -300,12 +272,11 @@ Name: kubernetes.default Address 1: 10.0.0.1 kubernetes.default.svc.cluster.local ``` -これが失敗する場合は、このドキュメントの [kube-proxy](#is-the-kube-proxy-working)セクションを参照するか、このドキュメントの先頭に戻って最初からやり直してください。ただし、あなた自身のServiceをデバッグするのではなく 、DNSサービスをデバッグします。 +これが失敗する場合は、このドキュメントの[kube-proxy](#is-the-kube-proxy-working)セクションを参照するか、このドキュメントの先頭に戻って最初からやり直してください。ただし、あなた自身のServiceをデバッグするのではなく、DNSサービスをデバッグします。 ## ServiceはIPでは機能するか？ -DNSサービスが正しく動作できると仮定すると、次にテストするのはIPによってServiceが動作しているかどうかです。 -上述の`kubectl get`で確認できるIPに、クラスター内のPodからアクセスします。 +DNSサービスが正しく動作できると仮定すると、次にテストするのはIPによってServiceが動作しているかどうかです。上述の`kubectl get`で確認できるIPに、クラスター内のPodからアクセスします。 ```shell for i in $(seq 1 3); do @@ -321,13 +292,11 @@ hostnames-bvc05 hostnames-yp2kp ``` -Serviceが機能している場合は、正しい応答が得られるはずです。 -そうでない場合、おかしい可能性のあるものがいくつかあるため、続けましょう。 +Serviceが機能している場合は、正しい応答が得られるはずです。そうでない場合、おかしい可能性のあるものがいくつかあるため、続けましょう。 ## Serviceは正しく定義されているか？ -馬鹿げているように聞こえるかもしれませんが、Serviceが正しく定義されPodのポートとマッチすることを二度、三度と確認すべきです。 -Serviceを読み返して確認しましょう。 +馬鹿げているように聞こえるかもしれませんが、Serviceが正しく定義されPodのポートとマッチすることを二度、三度と確認すべきです。Serviceを読み返して確認しましょう。 ```shell kubectl get service hostnames -o json @@ -377,8 +346,7 @@ kubectl get service hostnames -o json ## ServiceにEndpointsがあるか？ -ここまで来たということは、Serviceは正しく定義され、DNSによって名前解決できることが確認できているでしょう。 -ここでは、実行したPodがServiceによって実際に選択されていることを確認しましょう。 +ここまで来たということは、Serviceは正しく定義され、DNSによって名前解決できることが確認できているでしょう。ここでは、実行したPodがServiceによって実際に選択されていることを確認しましょう。 以前に、Podが実行されていることを確認しました。再確認しましょう。 @@ -395,8 +363,7 @@ hostnames-yp2kp 1/1 Running 0 1h "AGE"列は、これらのPodが約1時間前のものであることを示しており、それらが正常に実行され、クラッシュしていないことを意味します。 -"RESTARTS"列は、これらのポッドが頻繁にクラッシュしたり、再起動されていないことを示しています。 頻繁に再起動すると、断続的な接続性の問題が発生する可能性があります。 -再起動回数が多い場合は、[ポッドをデバッグする](/ja/docs/tasks/debug-application-cluster/debug-pod-replication-controller/#podのデバッグ)を参照してください。 +"RESTARTS"列は、これらのポッドが頻繁にクラッシュしたり、再起動されていないことを示しています。頻繁に再起動すると、断続的な接続性の問題が発生する可能性があります。再起動回数が多い場合は、[ポッドをデバッグする](/ja/docs/tasks/debug-application-cluster/debug-pod-replication-controller/#podのデバッグ)を参照してください。 Kubernetesシステム内には、すべてのServiceのセレクターを評価し、結果をEndpointsオブジェクトに保存するコントロールループがあります。 @@ -407,15 +374,11 @@ 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`値を選択していることを確認する必要があります。よくある間違いは、タイプミスまたは他のエラー、たとえばServiceが`app=hostnames`を選択しているのにDeploymentが`run=hostnames`を指定していることです。 ## Podは機能しているか？ -この時点で、Serviceが存在し、Podを選択していることがわかります。 -このウォークスルーの最初に、Pod自体を確認しました。 -Podが実際に機能していることを確認しましょう。Serviceメカニズムをバイパスして、上記EndpointsにリストされているPodに直接アクセスすることができます。 +この時点で、Serviceが存在し、Podを選択していることがわかります。このウォークスルーの最初に、Pod自体を確認しました。Podが実際に機能していることを確認しましょう。Serviceメカニズムをバイパスして、上記EndpointsにリストされているPodに直接アクセスすることができます。 {{< note >}} これらのコマンドは、Serviceポート(80)ではなく、Podポート(9376)を使用します。 @@ -437,23 +400,17 @@ hostnames-bvc05 hostnames-yp2kp ``` -Endpointsリスト内の各Podは、それぞれの自身のホスト名を返すはずです。 -そうならない(または、あなた自身のPodの正しい振る舞いにならない)場合は、そこで何が起こっているのかを調査する必要があります。 +Endpointsリスト内の各Podは、それぞれの自身のホスト名を返すはずです。そうならない(または、あなた自身のPodの正しい振る舞いにならない)場合は、そこで何が起こっているのかを調査する必要があります。 ## kube-proxyは機能しているか？ {#is-the-kube-proxy-working} -ここに到達したのなら、Serviceは実行され、Endpointsがあり、Podが実際にサービスを提供しています。 -この時点で、Serviceのプロキシーメカニズム全体が疑わしいです。 -ひとつひとつ確認しましょう。 +ここに到達したのなら、Serviceは実行され、Endpointsがあり、Podが実際にサービスを提供しています。この時点で、Serviceのプロキシーメカニズム全体が疑わしいです。ひとつひとつ確認しましょう。 -Serviceのデフォルト実装、およびほとんどのクラスターで使用されるものは、kube-proxyです。 -kube-proxyはそれぞれのノードで実行され、Serviceの抽象化を提供するための小さなメカニズムセットの1つを構成するプログラムです。 -クラスターがkube-proxyを使用しない場合、以下のセクションは適用されず、使用しているServiceの実装を調査する必要があります。 +Serviceのデフォルト実装、およびほとんどのクラスターで使用されるものは、kube-proxyです。kube-proxyはそれぞれのノードで実行され、Serviceの抽象化を提供するための小さなメカニズムセットの1つを構成するプログラムです。クラスターがkube-proxyを使用しない場合、以下のセクションは適用されず、使用しているServiceの実装を調査する必要があります。 ### kube-proxyは実行されているか？ -`kube-proxy`がノード上で実行されていることを確認しましょう。 -ノードで実行されていれば、以下のような結果が得られるはずです。 +`kube-proxy`がノード上で実行されていることを確認しましょう。ノードで実行されていれば、以下のような結果が得られるはずです。 ```shell ps auxw | grep kube-proxy @@ -462,11 +419,7 @@ ps auxw | grep kube-proxy root 4194 0.4 0.1 101864 17696 ? Sl Jul04 25:43 /usr/local/bin/kube-proxy --master=https://kubernetes-master --kubeconfig=/var/lib/kube-proxy/kubeconfig --v=2 ``` -次に、マスターとの接続など、明らかな失敗をしていないことを確認します。 -これを行うには、ログを確認する必要があります。 -ログへのアクセス方法は、ノードのOSに依存します。 -一部のOSでは/var/log/kube-proxy.logのようなファイルですが、他のOSでは`journalctl`を使用してログにアクセスします。 -次のように表示されます。 +次に、マスターとの接続など、明らかな失敗をしていないことを確認します。これを行うには、ログを確認する必要があります。ログへのアクセス方法は、ノードのOSに依存します。一部のOSでは/var/log/kube-proxy.logのようなファイルですが、他のOSでは`journalctl`を使用してログにアクセスします。次のように表示されます。 ```none I1027 22:14:53.995134 5063 server.go:200] Running in resource-only container "/kube-proxy" @@ -483,12 +436,9 @@ I1027 22:14:54.040223 5063 proxier.go:294] Adding new service "kube-system/ku マスターに接続できないことに関するエラーメッセージが表示された場合、ノードの設定とインストール手順をダブルチェックする必要があります。 -`kube-proxy`が正しく実行できない理由の可能性の1つは、必須の`conntrack`バイナリが見つからないことです。 -これは、例えばKubernetesをスクラッチからインストールするなど、クラスターのインストール方法に依存して、一部のLinuxシステムで発生する場合があります。 -これが該当する場合は、`conntrack`パッケージを手動でインストール(例: Ubuntuでは`sudo apt install conntrack`)する必要があり、その後に再試行する必要があります。 +`kube-proxy`が正しく実行できない理由の可能性の1つは、必須の`conntrack`バイナリが見つからないことです。これは、例えばKubernetesをスクラッチからインストールするなど、クラスターのインストール方法に依存して、一部のLinuxシステムで発生する場合があります。これが該当する場合は、`conntrack`パッケージを手動でインストール(例: Ubuntuでは`sudo apt install conntrack`)する必要があり、その後に再試行する必要があります。 -kube-proxyは、いくつかのモードのいずれかで実行できます。 上記のログの`Using iptables Proxier`という行は、kube-proxyが「iptables」モードで実行されていることを示しています。 -最も一般的な他のモードは「ipvs」です。 古い「ユーザースペース」モードは、主にこれらに置き換えられました。 +kube-proxyは、いくつかのモードのいずれかで実行できます。上記のログの`Using iptables Proxier`という行は、kube-proxyが「iptables」モードで実行されていることを示しています。最も一般的な他のモードは「ipvs」です。古い「ユーザースペース」モードは、主にこれらに置き換えられました。 #### Iptables mode @@ -510,9 +460,7 @@ iptables-save | grep hostnames -A KUBE-SVC-NWV5X2332I4OT4T3 -m comment --comment "default/hostnames:" -j KUBE-SEP-57KPRZ3JQVENLNBR ``` -各サービスのポートごとに、 `KUBE-SERVICES`に1つのルールと1つの` KUBE-SVC- `チェーンが必要です。 -Podエンドポイントごとに、その `KUBE-SVC- `に少数のルールがあり、少数のルールが含まれる1つの `KUBE-SEP- `チェーンがあるはずです。 -正確なルールは、正確な構成（NodePortとLoadBalancerを含む）に基づいて異なります。 +各サービスのポートごとに、`KUBE-SERVICES`に1つのルールと1つの` KUBE-SVC- `チェーンが必要です。Podエンドポイントごとに、その`KUBE-SVC- `に少数のルールがあり、少数のルールが含まれる1つの`KUBE-SEP- `チェーンがあるはずです。正確なルールは、正確な構成(NodePortとLoadBalancerを含む)に基づいて異なります。 #### IPVS mode @@ -532,12 +480,9 @@ TCP 10.0.1.175:80 rr ... ``` -各Serviceの各ポートに加えて、NodePort、External IP、およびLoad Balancer IPに対して、kube-proxyは仮想サーバーを作成します。 -Pod endpointごとに、対応する実サーバーが作成されます。 -この例では, サービスhostnames(`10.0.1.175:80`) は3つのendpoints(`10.244.0.5:9376`,`10.244.0.6:9376`, `10.244.0.7:9376`)を持っています。 +各Serviceの各ポートに加えて、NodePort、External IP、およびLoad Balancer IPに対して、kube-proxyは仮想サーバーを作成します。Pod endpointごとに、対応する実サーバーが作成されます。この例では、サービスhostnames(`10.0.1.175:80`)は3つのendpoints(`10.244.0.5:9376`、`10.244.0.6:9376`、`10.244.0.7:9376`)を持っています。 -IPVSプロキシーは、各Serviceアドレス(Cluster IP、External IP、NodePort IP、Load Balancer IPなど)毎の仮想サーバーと、Serviceのエンドポイントが存在する場合に対応する実サーバーを作成します。 -この例では、hostnames Service(`10.0.1.175:80`)は3つのエンドポイント(`10.244.0.5:9376`、`10.244.0.6:9376`、`10.244.0.7:9376`)を持ち、上と似た結果が得られるはずです。 +IPVSプロキシーは、各Serviceアドレス(Cluster IP、External IP、NodePort IP、Load Balancer IPなど)毎の仮想サーバーと、Serviceのエンドポイントが存在する場合に対応する実サーバーを作成します。この例では、hostnames Service(`10.0.1.175:80`)は3つのエンドポイント(`10.244.0.5:9376`、`10.244.0.6:9376`、`10.244.0.7:9376`)を持ち、上と似た結果が得られるはずです。 #### Userspace mode @@ -553,7 +498,7 @@ iptables-save | grep hostnames -A KUBE-PORTALS-HOST -d 10.0.1.175/32 -p tcp -m comment --comment "default/hostnames:default" -m tcp --dport 80 -j DNAT --to-destination 10.240.115.247:48577 ``` -サービスの各ポートには2つのルールが必要です（この例では1つだけ）-「KUBE-PORTALS-CONTAINER」と「KUBE-PORTALS-HOST」です。 +サービスの各ポートには2つのルールが必要です(この例では1つだけ)-「KUBE-PORTALS-CONTAINER」と「KUBE-PORTALS-HOST」です。 「userspace」モードを使用する必要はほとんどないので、ここでこれ以上時間を費やすことはありません。 @@ -568,11 +513,9 @@ curl 10.0.1.175:80 hostnames-0uton ``` -もしこれが失敗し、あなたがuserspaceプロキシーを使用している場合、プロキシーへの直接アクセスを試してみてください。 -もしiptablesプロキシーを使用している場合、このセクションはスキップしてください。 +もしこれが失敗し、あなたがuserspaceプロキシーを使用している場合、プロキシーへの直接アクセスを試してみてください。もしiptablesプロキシーを使用している場合、このセクションはスキップしてください。 -上記の`iptables-save`の出力を振り返り、`kube-proxy`がServiceに使用しているポート番号を抽出します。 -上記の例では"48577"です。このポートに接続してください。 +上記の`iptables-save`の出力を振り返り、`kube-proxy`がServiceに使用しているポート番号を抽出します。上記の例では"48577"です。このポートに接続してください。 ```shell curl localhost:48577 @@ -589,18 +532,13 @@ Setting endpoints for default/hostnames:default to [10.244.0.5:9376 10.244.0.6:9 これらが表示されない場合は、`-v`フラグを4に設定して`kube-proxy`を再起動してから、再度ログを確認してください。 -### エッジケース: PodがService IP経由で自身に到達できない。 {#a-pod-fails-to-reach-itself-via-the-service-ip} +### エッジケース: 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/admin/kubelet/)を公開します。これにより、Serviceのエンドポイントが自身のServiceのVIPにアクセスしようとした場合に、自身への負荷分散を可能にします。`hairpin-mode`フラグは`hairpin-veth`または`promiscuous-bridge`に設定する必要があります。 この問題をトラブルシューティングする一般的な手順は次のとおりです。 -* `hairpin-mode`が`hairpin-veth`または`promiscuous-bridge`に設定されていることを確認します。 -次のような表示がされるはずです。この例では、`hairpin-mode`は`promiscuous-bridge`に設定されています。 +* `hairpin-mode`が`hairpin-veth`または`promiscuous-bridge`に設定されていることを確認します。次のような表示がされるはずです。この例では、`hairpin-mode`は`promiscuous-bridge`に設定されています。 ```shell ps auxw | grep kubelet @@ -609,20 +547,13 @@ ps auxw | grep kubelet root 3392 1.1 0.8 186804 65208 ? Sl 00:51 11:11 /usr/local/bin/kubelet --enable-debugging-handlers=true --config=/etc/kubernetes/manifests --allow-privileged=True --v=4 --cluster-dns=10.0.0.10 --cluster-domain=cluster.local --configure-cbr0=true --cgroup-root=/ --system-cgroups=/system --hairpin-mode=promiscuous-bridge --runtime-cgroups=/docker-daemon --kubelet-cgroups=/kubelet --babysit-daemons=true --max-pods=110 --serialize-image-pulls=false --outofdisk-transition-frequency=0 ``` -* 実際に使われている`hairpin-mode`を確認します。 -これを行うには、kubeletログを確認する必要があります。 -ログへのアクセス方法は、ノードのOSによって異なります。 -一部のOSでは/var/log/kubelet.logなどのファイルですが、他のOSでは`journalctl`を使用してログにアクセスします。 -互換性のために、実際に使われている`hairpin-mode`が`--hairpin-mode`フラグと一致しない場合があることに注意してください。 -kubelet.logにキーワード`hairpin`を含むログ行があるかどうかを確認してください。 -実際に使われている`hairpin-mode`を示す以下のようなログ行があるはずです。 +* 実際に使われている`hairpin-mode`を確認します。これを行うには、kubeletログを確認する必要があります。ログへのアクセス方法は、ノードのOSによって異なります。一部のOSでは/var/log/kubelet.logなどのファイルですが、他のOSでは`journalctl`を使用してログにアクセスします。互換性のために、実際に使われている`hairpin-mode`が`--hairpin-mode`フラグと一致しない場合があることに注意してください。kubelet.logにキーワード`hairpin`を含むログ行があるかどうかを確認してください。実際に使われている`hairpin-mode`を示す以下のようなログ行があるはずです。 ```none I0629 00:51:43.648698 3252 kubelet.go:380] Hairpin mode set to "promiscuous-bridge" ``` -* 実際に使われている`hairpin-mode`が`hairpin-veth`の場合、`Kubelet`にノードの`/sys`で操作する権限があることを確認します。 -すべてが正常に機能している場合、次のようなものが表示されます。 +* 実際に使われている`hairpin-mode`が`hairpin-veth`の場合、`Kubelet`にノードの`/sys`で操作する権限があることを確認します。すべてが正常に機能している場合、次のようなものが表示されます。 ```shell for intf in /sys/devices/virtual/net/cbr0/brif/*; do cat $intf/hairpin_mode; done @@ -634,8 +565,7 @@ for intf in /sys/devices/virtual/net/cbr0/brif/*; do cat $intf/hairpin_mode; don 1 ``` -実際に使われている`hairpin-mode`が`promiscuous-bridge`の場合、`Kubelet`にノード上のLinuxブリッジを操作する権限があることを確認してください。 -`cbr0`ブリッジが使用され適切に構成されている場合、以下が表示されます。 +実際に使われている`hairpin-mode`が`promiscuous-bridge`の場合、`Kubelet`にノード上のLinuxブリッジを操作する権限があることを確認してください。`cbr0`ブリッジが使用され適切に構成されている場合、以下が表示されます。 ```shell ifconfig cbr0 |grep PROMISC @@ -648,15 +578,9 @@ UP BROADCAST RUNNING PROMISC MULTICAST MTU:1460 Metric:1 ## 助けを求める -ここまでたどり着いたということは、とてもおかしなことが起こっています。 -Serviceは実行中で、Endpointsがあり、Podは実際にサービスを提供しています。 -DNSは動作していて、`kube-proxy`も誤動作していないようです。 -それでも、あなたのServiceは機能していません。 -おそらく私たちにお知らせ頂いた方がよいでしょう。調査をお手伝いします！ +ここまでたどり着いたということは、とてもおかしなことが起こっています。Serviceは実行中で、Endpointsがあり、Podは実際にサービスを提供しています。DNSは動作していて、`kube-proxy`も誤動作していないようです。それでも、あなたのServiceは機能していません。おそらく私たちにお知らせ頂いた方がよいでしょう。調査をお手伝いします！ -[Slack](/docs/troubleshooting/#slack)または -[Forum](https://discuss.kubernetes.io)または -[GitHub](https://github.com/kubernetes/kubernetes)でお問い合わせください。 +[Slack](/docs/troubleshooting/#slack)、[Forum](https://discuss.kubernetes.io)または[GitHub](https://github.com/kubernetes/kubernetes)でお問い合わせください。 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 b6825075b8..684fa981c1 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 @@ -47,7 +47,7 @@ kubectl exec -it shell-demo -- /bin/bash ``` {{< note >}} -ダブルダッシュの記号 "--" はコマンドに渡す引数とkubectlの引数を分離します。 +ダブルダッシュの記号 `--` はコマンドに渡す引数とkubectlの引数を分離します。 {{< /note >}} diff --git a/content/ja/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md b/content/ja/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md new file mode 100644 index 0000000000..a6679de198 --- /dev/null +++ b/content/ja/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md @@ -0,0 +1,149 @@ +--- +title: 環境変数によりコンテナにPod情報を共有する +content_type: task +weight: 30 +--- + + + +このページでは、Podが内部で実行しているコンテナに自身の情報を共有する方法を説明します。環境変数ではPodのフィールドとコンテナのフィールドを共有することができます。 + + + + +## {{% heading "prerequisites" %}} + + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + + + + + + +## Downward API {#the-downward-api} + +Podとコンテナのフィールドを実行中のコンテナに共有する方法は2つあります: + +* 環境変数 +* [ボリュームファイル](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/#the-downward-api) + +これら2つの方法を合わせて、Podとコンテナフィールドを共有する方法を*Downward API*と呼びます。 + + +## Podフィールドを環境変数の値として使用する {#use-pod-fields-as-values-for-environment-variables} + +この演習では、1つのコンテナを持つPodを作成します。Podの設定ファイルは次のとおりです: + +{{< codenew file="pods/inject/dapi-envars-pod.yaml" >}} + +設定ファイルには、5つの環境変数があります。`env`フィールドは[EnvVars](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvar-v1-core)の配列です。配列の最初の要素では、環境変数`MY_NODE_NAME`の値をPodの`spec.nodeName`フィールドから取得することを指定します。同様に、他の環境変数もPodのフィールドから名前を取得します。 + +{{< note >}} +この例のフィールドはPodのフィールドです。これらはPod内のコンテナのフィールドではありません。 +{{< /note >}} + +Podを作成します: + +```shell +kubectl apply -f https://k8s.io/examples/pods/inject/dapi-envars-pod.yaml +``` + +Podのコンテナが実行されていることを確認します: + +```shell +kubectl get pods +``` + +コンテナのログを表示します: + +```shell +kubectl logs dapi-envars-fieldref +``` + +出力には、選択した環境変数の値が表示されます: + +``` +minikube +dapi-envars-fieldref +default +172.17.0.4 +default +``` + +これらの値がログにある理由を確認するには、設定ファイルの`command`および`args`フィールドを確認してください。コンテナが起動すると、5つの環境変数の値が標準出力に書き込まれます。これを10秒ごとに繰り返します。 + +次に、Podで実行しているコンテナへのシェルを取得します: + +```shell +kubectl exec -it dapi-envars-fieldref -- sh +``` + +シェルで環境変数を表示します: + +```shell +/# printenv +``` + +出力は、特定の環境変数にPodフィールドの値が割り当てられていることを示しています: + +``` +MY_POD_SERVICE_ACCOUNT=default +... +MY_POD_NAMESPACE=default +MY_POD_IP=172.17.0.4 +... +MY_NODE_NAME=minikube +... +MY_POD_NAME=dapi-envars-fieldref +``` + +## コンテナフィールドを環境変数の値として使用する {#use-container-fields-as-values-for-environment-variables} + +前の演習では、環境変数の値としてPodフィールドを使用しました。次の演習では、環境変数の値としてコンテナフィールドを使用します。これは、1つのコンテナを持つPodの設定ファイルです: + +{{< codenew file="pods/inject/dapi-envars-container.yaml" >}} + +設定ファイルには、4つの環境変数があります。`env`フィールドは[EnvVars](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvar-v1-core)の配列です。配列の最初の要素では、環境変数`MY_CPU_REQUEST`の値を`test-container`という名前のコンテナの`requests.cpu`フィールドから取得することを指定します。同様に、他の環境変数もコンテナのフィールドから値を取得します。 + +Podを作成します: + +```shell +kubectl apply -f https://k8s.io/examples/pods/inject/dapi-envars-container.yaml +``` + +Podのコンテナが実行されていることを確認します: + +```shell +kubectl get pods +``` + +コンテナのログを表示します: + +```shell +kubectl logs dapi-envars-resourcefieldref +``` + +出力には、選択した環境変数の値が表示されます: + +``` +1 +1 +33554432 +67108864 +``` + + + +## {{% heading "whatsnext" %}} + + +* [コンテナの環境変数の定義](/ja/docs/tasks/inject-data-application/define-environment-variable-container/) +* [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core) +* [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core) +* [EnvVar](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvar-v1-core) +* [EnvVarSource](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvarsource-v1-core) +* [ObjectFieldSelector](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#objectfieldselector-v1-core) +* [ResourceFieldSelector](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcefieldselector-v1-core) + + diff --git a/content/ja/docs/tasks/manage-gpus/scheduling-gpus.md b/content/ja/docs/tasks/manage-gpus/scheduling-gpus.md new file mode 100644 index 0000000000..b4a01a7bd7 --- /dev/null +++ b/content/ja/docs/tasks/manage-gpus/scheduling-gpus.md @@ -0,0 +1,184 @@ +--- +content_type: concept +title: GPUのスケジューリング +description: クラスター内のノードのリソースとしてGPUを設定してスケジューリングします +--- + + + +{{< feature-state state="beta" for_k8s_version="v1.10" >}} + +Kubernetesには、複数ノードに搭載されたAMDおよびNVIDIAのGPU(graphical processing unit)を管理するための**実験的な**サポートが含まれています。 + +このページでは、異なるバージョンのKubernetesを横断してGPUを使用する方法と、現時点での制限について説明します。 + + + +## デバイスプラグインを使用する + +Kubernetesでは、GPUなどの特別なハードウェアの機能にPodがアクセスできるようにするために、{{< glossary_tooltip text="デバイスプラグイン" term_id="device-plugin" >}}が実装されています。 + +管理者として、ノード上に対応するハードウェアベンダーのGPUドライバーをインストールして、以下のような対応するGPUベンダーのデバイスプラグインを実行する必要があります。 + +* [AMD](#deploying-amd-gpu-device-plugin) +* [NVIDIA](#deploying-nvidia-gpu-device-plugin) + +上記の条件を満たしていれば、Kubernetesは`amd.com/gpu`または`nvidia.com/gpu`をスケジュール可能なリソースとして公開します。 + +これらのGPUをコンテナから使用するには、`cpu`や`memory`をリクエストするのと同じように`.com/gpu`というリソースをリクエストするだけです。ただし、GPUを使用するときにはリソースのリクエストの指定方法にいくつか制限があります。 + +- GPUは`limits`セクションでのみ指定されることが想定されている。この制限は、次のことを意味します。 + * Kubernetesはデフォルトでlimitの値をrequestの値として使用するため、GPUの`requests`を省略して`limits`を指定できる。 + * GPUを`limits`と`requests`の両方で指定できるが、これら2つの値は等しくなければならない。 + * GPUの`limits`を省略して`requests`だけを指定することはできない。 +- コンテナ(およびPod)はGPUを共有しない。GPUのオーバーコミットは起こらない。 +- 各コンテナは1つ以上のGPUをリクエストできる。1つのGPUの一部だけをリクエストすることはできない。 + +以下に例を示します。 + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: cuda-vector-add +spec: + restartPolicy: OnFailure + containers: + - name: cuda-vector-add + # https://github.com/kubernetes/kubernetes/blob/v1.7.11/test/images/nvidia-cuda/Dockerfile + image: "k8s.gcr.io/cuda-vector-add:v0.1" + resources: + limits: + nvidia.com/gpu: 1 # 1 GPUをリクエストしています +``` + +### AMDのGPUデバイスプラグインをデプロイする {#deploying-amd-gpu-device-plugin} + +[AMD公式のGPUデバイスプラグイン](https://github.com/RadeonOpenCompute/k8s-device-plugin)には以下の要件があります。 + +- Kubernetesのノードに、AMDのGPUのLinuxドライバーがあらかじめインストール済みでなければならない。 + +クラスターが起動して上記の要件が満たされれば、以下のコマンドを実行することでAMDのデバイスプラグインをデプロイできます。 + +```shell +kubectl create -f https://raw.githubusercontent.com/RadeonOpenCompute/k8s-device-plugin/v1.10/k8s-ds-amdgpu-dp.yaml +``` + +このサードパーティーのデバイスプラグインに関する問題は、[RadeonOpenCompute/k8s-device-plugin](https://github.com/RadeonOpenCompute/k8s-device-plugin)で報告できます。 + +### NVIDIAのGPUデバイスプラグインをデプロイする {#deploying-nvidia-gpu-device-plugin} + +現在、NVIDIAのGPU向けのデバイスプラグインの実装は2種類あります。 + +#### NVIDIA公式のGPUデバイスプラグイン + +[NVIDIA公式のGPUデバイスプラグイン](https://github.com/NVIDIA/k8s-device-plugin)には以下の要件があります。 + +- Kubernetesのノードに、NVIDIAのドライバーがあらかじめインストール済みでなければならない。 +- Kubernetesのノードに、[nvidia-docker 2.0](https://github.com/NVIDIA/nvidia-docker)があらかじめインストール済みでなければならない。 +- KubeletはコンテナランタイムにDockerを使用しなければならない。 +- runcの代わりにDockerの[デフォルトランタイム](https://github.com/NVIDIA/k8s-device-plugin#preparing-your-gpu-nodes)として、`nvidia-container-runtime`を設定しなければならない。 +- NVIDIAのドライバーのバージョンが次の条件を満たさなければならない ~= 384.81。 + +クラスターが起動して上記の要件が満たされれば、以下のコマンドを実行することでNVIDIAのデバイスプラグインがデプロイできます。 + +```shell +kubectl create -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/1.0.0-beta4/nvidia-device-plugin.yml +``` + +このサードパーティーのデバイスプラグインに関する問題は、[NVIDIA/k8s-device-plugin](https://github.com/NVIDIA/k8s-device-plugin)で報告できます。 + +#### GCEで使用されるNVIDIAのGPUデバイスプラグイン + +[GCEで使用されるNVIDIAのGPUデバイスプラグイン](https://github.com/GoogleCloudPlatform/container-engine-accelerators/tree/master/cmd/nvidia_gpu)は、nvidia-dockerを必要としないため、KubernetesのContainer Runtime Interface(CRI)と互換性のある任意のコンテナランタイムで動作するはずです。このデバイスプラグインは[Container-Optimized OS](https://cloud.google.com/container-optimized-os/)でテストされていて、1.9以降ではUbuntu向けの実験的なコードも含まれています。 + +以下のコマンドを実行すると、NVIDIAのドライバーとデバイスプラグインをインストールできます。 + +```shell +# NVIDIAドライバーをContainer-Optimized OSにインストールする +kubectl create -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/stable/daemonset.yaml + +# NVIDIAドライバーをUbuntuにインストールする(実験的) +kubectl create -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/stable/nvidia-driver-installer/ubuntu/daemonset.yaml + +# デバイスプラグインをインストールする +kubectl create -f https://raw.githubusercontent.com/kubernetes/kubernetes/release-1.14/cluster/addons/device-plugins/nvidia-gpu/daemonset.yaml +``` + +このサードパーティーのデバイスプラグインの使用やデプロイに関する問題は、[GoogleCloudPlatform/container-engine-accelerators](https://github.com/GoogleCloudPlatform/container-engine-accelerators)で報告できます。 + +Googleは、GKE上でNVIDIAのGPUを使用するための[手順](https://cloud.google.com/kubernetes-engine/docs/how-to/gpus)も公開しています。 + +## 異なる種類のGPUを搭載するクラスター + +クラスター上の別のノードに異なる種類のGPUが搭載されている場合、[NodeラベルとNodeセレクター](/docs/tasks/configure-pod-container/assign-pods-nodes/)を使用することで、Podを適切なノードにスケジューリングできます。 + +以下に例を示します。 + +```shell +# アクセラレーターを搭載したノードにラベルを付けます。 +kubectl label nodes accelerator=nvidia-tesla-k80 +kubectl label nodes accelerator=nvidia-tesla-p100 +``` + +## 自動的なNodeラベルの付加 {#node-labeller} + +AMDのGPUデバイスを使用している場合、[Node Labeller](https://github.com/RadeonOpenCompute/k8s-device-plugin/tree/master/cmd/k8s-node-labeller)をデプロイできます。Node Labellerは{{< glossary_tooltip text="コントローラー" term_id="controller" >}}の1種で、GPUデバイスのプロパティを持つノードに自動的にラベルを付けてくれます。 + +現在は、このコントローラーは以下のプロパティに基づいてラベルを追加できます。 + +* デバイスID(-device-id) +* VRAMのサイズ(-vram) +* SIMDの数(-simd-count) +* Compute Unitの数(-cu-count) +* ファームウェアとフィーチャーのバージョン(-firmware) +* 2文字の頭字語で表されたGPUファミリー(-family) + * SI - Southern Islands + * CI - Sea Islands + * KV - Kaveri + * VI - Volcanic Islands + * CZ - Carrizo + * AI - Arctic Islands + * RV - Raven + +```shell +kubectl describe node cluster-node-23 +``` + +``` + Name: cluster-node-23 + Roles: + Labels: beta.amd.com/gpu.cu-count.64=1 + beta.amd.com/gpu.device-id.6860=1 + beta.amd.com/gpu.family.AI=1 + beta.amd.com/gpu.simd-count.256=1 + beta.amd.com/gpu.vram.16G=1 + beta.kubernetes.io/arch=amd64 + beta.kubernetes.io/os=linux + kubernetes.io/hostname=cluster-node-23 + Annotations: kubeadm.alpha.kubernetes.io/cri-socket: /var/run/dockershim.sock + node.alpha.kubernetes.io/ttl: 0 + … +``` + +Node Labellerを使用すると、GPUの種類をPodのspec内で指定できます。 + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: cuda-vector-add +spec: + restartPolicy: OnFailure + containers: + - name: cuda-vector-add + # https://github.com/kubernetes/kubernetes/blob/v1.7.11/test/images/nvidia-cuda/Dockerfile + image: "k8s.gcr.io/cuda-vector-add:v0.1" + resources: + limits: + nvidia.com/gpu: 1 + nodeSelector: + accelerator: nvidia-tesla-p100 # または nvidia-tesla-k80 など +``` + +これにより、指定した種類のGPUを搭載したノードにPodがスケジューリングされることを保証できます。 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 efa6f5a6ae..7d6830a50f 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 @@ -21,7 +21,7 @@ weight: 70 StatefulSetの通常の操作では、StatefulSet Podを強制的に削除する必要は**まったく**ありません。StatefulSetコントローラーは、StatefulSetのメンバーの作成、スケール、削除を行います。それは序数0からN-1までの指定された数のPodが生きていて準備ができていることを保証しようとします。StatefulSetは、クラスター内で実行されている特定のIDを持つ最大1つのPodがいつでも存在することを保証します。これは、StatefulSetによって提供される*最大1つの*セマンティクスと呼ばれます。 -手動による強制削除は、StatefulSetに固有の最大1つのセマンティクスに違反する可能性があるため、慎重に行う必要があります。StatefulSetを使用して、安定したネットワークIDと安定した記憶域を必要とする分散型およびクラスター型アプリケーションを実行できます。これらのアプリケーションは、固定IDを持つ固定数のメンバーのアンサンブルに依存する構成を持つことがよくあります。同じIDを持つ複数のメンバーを持つことは悲惨なことになり、データの損失につながる可能性があります（例：定足数ベースのシステムでのスプリットブレインシナリオ）。 +手動による強制削除は、StatefulSetに固有の最大1つのセマンティクスに違反する可能性があるため、慎重に行う必要があります。StatefulSetを使用して、安定したネットワークIDと安定した記憶域を必要とする分散型およびクラスター型アプリケーションを実行できます。これらのアプリケーションは、固定IDを持つ固定数のメンバーのアンサンブルに依存する構成を持つことがよくあります。同じIDを持つ複数のメンバーを持つことは悲惨なことになり、データの損失につながる可能性があります(例：定足数ベースのシステムでのスプリットブレインシナリオ)。 ## Podの削除 @@ -33,13 +33,13 @@ 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)ことを保証します。 -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/admin/node/#node-condition)の後に`Terminating`または`Unknown`状態になります。到達不能なNode上のPodをユーザーが適切に削除しようとすると、Podはこれらの状態に入ることもあります。そのような状態のPodをapiserverから削除することができる唯一の方法は以下の通りです: * (ユーザーまたは[Node Controller](/docs/admin/node)によって)Nodeオブジェクトが削除されます。
* 応答していないNodeのkubeletが応答を開始し、Podを終了してapiserverからエントリーを削除します。
* ユーザーによりPodを強制削除します。 -推奨されるベストプラクティスは、1番目または2番目のアプローチを使用することです。Nodeが死んでいることが確認された（例えば、ネットワークから恒久的に切断された、電源が切られたなど）場合、Nodeオブジェクトを削除します。Nodeがネットワークパーティションに苦しんでいる場合は、これを解決するか、解決するのを待ちます。パーティションが回復すると、kubeletはPodの削除を完了し、apiserverでその名前を解放します。 +推奨されるベストプラクティスは、1番目または2番目のアプローチを使用することです。Nodeが死んでいることが確認された(例えば、ネットワークから恒久的に切断された、電源が切られたなど)場合、Nodeオブジェクトを削除します。Nodeがネットワークパーティションに苦しんでいる場合は、これを解決するか、解決するのを待ちます。パーティションが回復すると、kubeletはPodの削除を完了し、apiserverでその名前を解放します。 通常、PodがNode上で実行されなくなるか、管理者によってそのNodeが削除されると、システムは削除を完了します。あなたはPodを強制的に削除することでこれを無効にすることができます。 diff --git a/content/ja/docs/tasks/service-catalog/_index.md b/content/ja/docs/tasks/service-catalog/_index.md new file mode 100755 index 0000000000..a7d91e4ea7 --- /dev/null +++ b/content/ja/docs/tasks/service-catalog/_index.md @@ -0,0 +1,6 @@ +--- +title: "サービスカタログ" +description: サービスカタログ拡張APIをインストールする +weight: 150 +--- + 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 new file mode 100644 index 0000000000..a0211e2a18 --- /dev/null +++ b/content/ja/docs/tasks/service-catalog/install-service-catalog-using-sc.md @@ -0,0 +1,68 @@ +--- +title: SCを使用したサービスカタログのインストール +content_type: task +--- + + +{{< glossary_definition term_id="service-catalog" length="all" prepend="サービスカタログは" >}} + +GCPの[Service Catalog Installer](https://github.com/GoogleCloudPlatform/k8s-service-catalog#installation)ツールを使うと、Kubernetesクラスター上にサービスカタログを簡単にインストール・アンインストールして、Google Cloudのプロジェクトに紐付けることもできます。 + +サービスカタログ自体は、Google Cloudだけではなく、どのような種類のマネージドサービスでも動作します。 + +## {{% heading "prerequisites" %}} + +* [サービスカタログ](/docs/concepts/service-catalog/)の基本概念を理解してください。 +* [Go 1.6+](https://golang.org/dl/)をインストールして、`GOPATH`を設定してください。 +* SSLに関するファイルを生成するために必要な[cfssl](https://github.com/cloudflare/cfssl)ツールをインストールしてください。 +* サービスカタログを使用するには、Kubernetesクラスターのバージョンが1.7以降である必要があります。 +* [kubectlのインストールおよびセットアップ](/ja/docs/tasks/tools/install-kubectl/)を参考に、v1.7以降のkubectlをインストールし、設定を行ってください。 +* サービスカタログをインストールするためには、kubectlのユーザーが*cluster-admin*ロールにバインドされている必要があります。正しくバインドされていることを確認するには、次のコマンドを実行します。 + + kubectl create clusterrolebinding cluster-admin-binding --clusterrole=cluster-admin --user= + + +## ローカル環境に`sc`をインストールする + +インストーラーは、ローカルのコンピューター上で`sc`と呼ばれるCLIツールとして実行します。 + +`go get`を使用してインストールします。 + +```shell +go get github.com/GoogleCloudPlatform/k8s-service-catalog/installer/cmd/sc +``` + +これで、`sc`が`GOPATH/bin`ディレクトリー内にインストールされたはずです。 + +## Kubernetesクラスターにサービスカタログをインストールする + +まず、すべての依存関係がインストールされていることを確認します。次のコマンドを実行してください。 + +```shell +sc check +``` + +チェックが成功したら、次のように表示されるはずです。 + +``` +Dependency check passed. You are good to go. +``` + +次に、バックアップに使用したい`storageclass`を指定して、installコマンドを実行します。 + +```shell +sc install --etcd-backup-storageclass "standard" +``` + +## サービスカタログのアンインストール + +Kubernetesクラスターからサービスカタログをアンインストールしたい場合は、`sc`ツールを使って次のコマンドを実行します。 + +```shell +sc uninstall +``` + +## {{% heading "whatsnext" %}} + +* [サービスブローカーのサンプル](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#sample-service-brokers)を読む。 +* [kubernetes-incubator/service-catalog](https://github.com/kubernetes-incubator/service-catalog)プロジェクトを探索する。 diff --git a/content/ja/docs/tasks/tools/install-kubectl.md b/content/ja/docs/tasks/tools/install-kubectl.md index 7c0d08d9c5..e468404469 100644 --- a/content/ja/docs/tasks/tools/install-kubectl.md +++ b/content/ja/docs/tasks/tools/install-kubectl.md @@ -5,7 +5,7 @@ weight: 10 card: name: tasks weight: 20 - title: Install kubectl + title: kubectlのインストール --- @@ -143,7 +143,7 @@ macOSで[Homebrew](https://brew.sh/)パッケージマネージャーを使用 1. インストールコマンドを実行してください: ``` - brew install kubectl + brew install kubectl ``` または @@ -186,7 +186,7 @@ macOSで[MacPorts](https://macports.org/)パッケージマネージャーを使 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`のバージョンがダウンロードしたものと同じであることを確認してください: @@ -202,7 +202,7 @@ macOSで[MacPorts](https://macports.org/)パッケージマネージャーを使 Windowsで[Powershell Gallery](https://www.powershellgallery.com/)パッケージマネージャーを使用していれば、Powershellでkubectlをインストールおよびアップデートすることもできます。 -1. インストールコマンドを実行してください（必ず`DownloadLocation`を指定してください）: +1. インストールコマンドを実行してください(必ず`DownloadLocation`を指定してください): ``` Install-Script -Name install-kubectl -Scope CurrentUser -Force @@ -301,7 +301,7 @@ URLのレスポンスが表示されている場合は、kubectlはクラスタ The connection to the server was refused - did you specify the right host or port? ``` -たとえば、ラップトップ上（ローカル環境）でKubernetesクラスターを起動するような場合、Minikubeなどのツールを最初にインストールしてから、上記のコマンドを再実行する必要があります。 +たとえば、ラップトップ上(ローカル環境)でKubernetesクラスターを起動するような場合、Minikubeなどのツールを最初にインストールしてから、上記のコマンドを再実行する必要があります。 kubectl cluster-infoがURLレスポンスを返したにもかかわらずクラスターにアクセスできない場合は、次のコマンドで設定が正しいことを確認してください: @@ -315,7 +315,7 @@ kubectl cluster-info dump kubectlはBashおよびZshの自動補完を提供しています。これにより、入力を大幅に削減することができます。 -以下にBash（LinuxとmacOSの違いも含む）およびZshの自動補完の設定手順を示します。 +以下にBash(LinuxとmacOSの違いも含む)およびZshの自動補完の設定手順を示します。 {{< tabs name="kubectl_autocompletion" >}} @@ -325,11 +325,11 @@ kubectlはBashおよびZshの自動補完を提供しています。これによ Bashにおけるkubectlの補完スクリプトは`kubectl completion bash`コマンドで生成できます。シェル内で補完スクリプトをsourceすることでkubectlの自動補完が有効になります。 -ただし、補完スクリプトは[**bash-completion**](https://github.com/scop/bash-completion)に依存しているため、このソフトウェアを最初にインストールしておく必要があります（`type _init_completion`を実行することで、bash-completionがすでにインストールされていることを確認できます）。 +ただし、補完スクリプトは[**bash-completion**](https://github.com/scop/bash-completion)に依存しているため、このソフトウェアを最初にインストールしておく必要があります(`type _init_completion`を実行することで、bash-completionがすでにインストールされていることを確認できます)。 ### bash-completionをインストールする -bash-completionは多くのパッケージマネージャーから提供されています（[こちら](https://github.com/scop/bash-completion#installation)を参照してください）。`apt-get install bash-completion`または`yum install bash-completion`などでインストールできます。 +bash-completionは多くのパッケージマネージャーから提供されています([こちら](https://github.com/scop/bash-completion#installation)を参照してください)。`apt-get install bash-completion`または`yum install bash-completion`などでインストールできます。 上記のコマンドでbash-completionの主要スクリプトである`/usr/share/bash-completion/bash_completion`が作成されます。パッケージマネージャーによっては、このファイルを`~/.bashrc`にて手動でsourceする必要があります。 @@ -382,7 +382,7 @@ Bashにおけるkubectlの補完スクリプトは`kubectl completion bash`コ ただし、補完スクリプトは[**bash-completion**](https://github.com/scop/bash-completion)に依存しているため、事前にインストールする必要があります。 {{< warning>}} -bash-completionにはv1とv2のバージョンがあり、v1はBash 3.2（macOSのデフォルト）用で、v2はBash 4.1以降向けです。kubectlの補完スクリプトはbash-completionのv1とBash 3.2では正しく**動作しません**。**bash-completion v2**および**Bash 4.1**が必要になります。したがって、macOSで正常にkubectlの補完を使用するには、Bash 4.1以降をインストールする必要があります([*手順*](https://itnext.io/upgrading-bash-on-macos-7138bd1066ba))。以下の手順では、Bash4.1以降（Bashのバージョンが4.1またはそれより新しいことを指します）を使用することを前提とします。 +bash-completionにはv1とv2のバージョンがあり、v1はBash 3.2(macOSのデフォルト)用で、v2はBash 4.1以降向けです。kubectlの補完スクリプトはbash-completionのv1とBash 3.2では正しく**動作しません**。**bash-completion v2**および**Bash 4.1**が必要になります。したがって、macOSで正常にkubectlの補完を使用するには、Bash 4.1以降をインストールする必要があります([*手順*](https://itnext.io/upgrading-bash-on-macos-7138bd1066ba))。以下の手順では、Bash4.1以降(Bashのバージョンが4.1またはそれより新しいことを指します)を使用することを前提とします。 {{< /warning >}} ### bashのアップグレード @@ -410,7 +410,7 @@ Homebrewは通常、`/usr/local/bin/bash`にインストールします。 ### bash-completionをインストールする {{< note >}} -前述のとおり、この手順ではBash 4.1以降であることが前提のため、bash-completion v2をインストールすることになります（これとは逆に、Bash 3.2およびbash-completion v1の場合ではkubectlの補完は動作しません）。 +前述のとおり、この手順ではBash 4.1以降であることが前提のため、bash-completion v2をインストールすることになります(これとは逆に、Bash 3.2およびbash-completion v1の場合ではkubectlの補完は動作しません)。 {{< /note >}} `type _init_completion`を実行することで、bash-completionがすでにインストールされていることを確認できます。ない場合は、Homebrewを使用してインストールすることもできます: @@ -452,7 +452,7 @@ export BASH_COMPLETION_COMPAT_DIR="/usr/local/etc/bash_completion.d" echo 'complete -F __start_kubectl k' >>~/.bashrc ``` -- kubectlをHomwbrewでインストールした場合（[前述](#homebrewを使用してmacosへインストールする)のとおり）、kubectlの補完スクリプトはすでに`/usr/local/etc/bash_completion.d/kubectl`に格納されているでしょう。この場合、なにも操作する必要はありません。 +- kubectlをHomwbrewでインストールした場合([前述](#homebrewを使用してmacosへインストールする)のとおり)、kubectlの補完スクリプトはすでに`/usr/local/etc/bash_completion.d/kubectl`に格納されているでしょう。この場合、なにも操作する必要はありません。 {{< note >}} Homebrewでインストールしたbash-completion v2は`BASH_COMPLETION_COMPAT_DIR`ディレクトリ内のすべてのファイルをsourceするため、後者の2つの方法が機能します。 diff --git a/content/ja/docs/tasks/tools/install-minikube.md b/content/ja/docs/tasks/tools/install-minikube.md index 51e6cd8417..30b15718ca 100644 --- a/content/ja/docs/tasks/tools/install-minikube.md +++ b/content/ja/docs/tasks/tools/install-minikube.md @@ -29,7 +29,7 @@ grep -E --color 'vmx|svm' /proc/cpuinfo ``` sysctl -a | grep -E --color 'machdep.cpu.features|VMX' ``` -出力に`VMX`が表示されている場合（色付けされているはずです）、VT-x機能がマシンで有効になっています。 +出力に`VMX`が表示されている場合(色付けされているはずです)、VT-x機能がマシンで有効になっています。 {{% /tab %}} {{% tab name="Windows" %}} diff --git a/content/ja/docs/tutorials/kubernetes-basics/_index.html b/content/ja/docs/tutorials/kubernetes-basics/_index.html index 99174c2b21..3f31b8d5bc 100644 --- a/content/ja/docs/tutorials/kubernetes-basics/_index.html +++ b/content/ja/docs/tutorials/kubernetes-basics/_index.html @@ -39,7 +39,7 @@ card:

-

Kubernetesはどんなことができるの?

+

Kubernetesはどんなことができるの？

モダンなWebサービスでは、ユーザはアプリケーションが24時間365日利用可能であることを期待しており、開発者はそれらのアプリケーションの新しいバージョンを1日に数回デプロイすることを期待しています。コンテナ化は、パッケージソフトウェアがこれらの目標を達成するのを助け、アプリケーションをダウンタイムなしで簡単かつ迅速にリリース、アップデートできるようにします。Kubernetesを使用すると、コンテナ化されたアプリケーションをいつでもどこでも好きなときに実行できるようになり、それらが機能するために必要なリソースとツールを見つけやすくなります。Kubernetesは、コンテナオーケストレーションにおけるGoogleのこれまでの経験と、コミュニティから得られた最善のアイデアを組み合わせて設計された、プロダクションレディなオープンソースプラットフォームです。

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 c9d25cd3fb..9b59db721b 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の詳細はこちらです。

diff --git a/content/ja/docs/tutorials/services/_index.md b/content/ja/docs/tutorials/services/_index.md new file mode 100755 index 0000000000..2a2a0eb7b6 --- /dev/null +++ b/content/ja/docs/tutorials/services/_index.md @@ -0,0 +1,5 @@ +--- +title: "Service" +weight: 70 +--- + diff --git a/content/ja/docs/tutorials/services/source-ip.md b/content/ja/docs/tutorials/services/source-ip.md new file mode 100644 index 0000000000..69c626d532 --- /dev/null +++ b/content/ja/docs/tutorials/services/source-ip.md @@ -0,0 +1,421 @@ +--- +title: 送信元IPを使用する +content_type: tutorial +min-kubernetes-server-version: v1.5 +--- + + + +Kubernetesクラスター内で実行されているアプリケーションは、Serviceという抽象化を経由して、他のアプリケーションや外の世界との発見や通信を行います。このドキュメントでは、異なる種類のServiceに送られたパケットの送信元IPに何が起こるのか、そして必要に応じてこの振る舞いを切り替える方法について説明します。 + +## {{% heading "prerequisites" %}} + +### 用語 + +このドキュメントでは、以下の用語を使用します。 + +{{< comment >}} +If localizing this section, link to the equivalent Wikipedia pages for +the target localization. +{{< /comment >}} + +[NAT](https://ja.wikipedia.org/wiki/%E3%83%8D%E3%83%83%E3%83%88%E3%83%AF%E3%83%BC%E3%82%AF%E3%82%A2%E3%83%89%E3%83%AC%E3%82%B9%E5%A4%89%E6%8F%9B) +: ネットワークアドレス変換(network address translation) + +[送信元NAT](https://en.wikipedia.org/wiki/Network_address_translation#SNAT) +: パケットの送信元のIPを置換します。このページでは、通常ノードのIPアドレスを置換することを意味します。 + +[送信先NAT](https://en.wikipedia.org/wiki/Network_address_translation#DNAT) +: パケットの送信先のIPを置換します。このページでは、通常{{< glossary_tooltip term_id="pod" >}}のIPアドレスを置換することを意味します。 + +[VIP](/ja/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies) +: Kubernetes内のすべての{{< glossary_tooltip text="Service" term_id="service" >}}などに割り当てられる仮想IPアドレス(virtual IP address)です。 + +[kube-proxy](/ja/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies) +: すべてのノード上でServiceのVIPを管理するネットワークデーモンです。 + +### 前提条件 + +{{< include "task-tutorial-prereqs.md" >}} + +以下の例では、HTTPヘッダー経由で受け取ったリクエストの送信元IPをエコーバックする、小さなnginxウェブサーバーを使用します。次のコマンドでウェブサーバーを作成できます。 + +```shell +kubectl create deployment source-ip-app --image=k8s.gcr.io/echoserver:1.4 +``` + +出力は次のようになります。 + +``` +deployment.apps/source-ip-app created +``` + +## {{% heading "objectives" %}} + +* 単純なアプリケーションを様々な種類のService経由で公開する +* それぞれの種類のServiceがどのように送信元IPのNATを扱うかを理解する +* 送信元IPを保持することに関わるトレードオフを理解する + + + +## `Type=ClusterIP`を使用したServiceでの送信元IP + +kube-proxyが[iptablesモード](/ja/docs/concepts/services-networking/service/#proxy-mode-iptables)(デフォルト)で実行されている場合、クラスター内部からClusterIPに送られたパケットに送信元のNATが行われることは決してありません。kube-proxyが実行されているノード上で`http://localhost:10249/proxyMode`にリクエストを送って、kube-proxyのモードを問い合わせてみましょう。 + +```console +kubectl get nodes +``` + +出力は次のようになります。 + +``` +NAME STATUS ROLES AGE VERSION +kubernetes-node-6jst Ready 2h v1.13.0 +kubernetes-node-cx31 Ready 2h v1.13.0 +kubernetes-node-jj1t Ready 2h v1.13.0 +``` + +これらのノードの1つでproxyモードを取得します(kube-proxyはポート10249をlistenしています)。 + +```shell +# このコマンドは、問い合わせを行いたいノード上のシェルで実行してください。 +curl http://localhost:10249/proxyMode +``` + +出力は次のようになります。 + +``` +iptables +``` + +source IPアプリのServiceを作成することで、送信元IPが保持されているかテストできます。 + +```shell +kubectl expose deployment source-ip-app --name=clusterip --port=80 --target-port=8080 +``` + +出力は次のようになります。 + +``` +service/clusterip exposed +``` +```shell +kubectl get svc clusterip +``` + +出力は次のようになります。 + +``` +NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE +clusterip ClusterIP 10.0.170.92 80/TCP 51s +``` + +そして、同じクラスター上のPodから`ClusterIP`にアクセスします。 + +```shell +kubectl run busybox -it --image=busybox --restart=Never --rm +``` + +出力は次のようになります。 + +``` +Waiting for pod default/busybox to be running, status is Pending, pod ready: false +If you don't see a command prompt, try pressing enter. + +``` + +これで、Podの内部でコマンドが実行できます。 + +```shell +# このコマンドは、"kubectl run" のターミナルの内部で実行してください +ip addr +``` +``` +1: lo: mtu 65536 qdisc noqueue + link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 + inet 127.0.0.1/8 scope host lo + valid_lft forever preferred_lft forever + inet6 ::1/128 scope host + valid_lft forever preferred_lft forever +3: eth0: mtu 1460 qdisc noqueue + link/ether 0a:58:0a:f4:03:08 brd ff:ff:ff:ff:ff:ff + inet 10.244.3.8/24 scope global eth0 + valid_lft forever preferred_lft forever + inet6 fe80::188a:84ff:feb0:26a5/64 scope link + valid_lft forever preferred_lft forever +``` + +そして、`wget`を使用してローカルのウェブサーバーに問い合わせます。 + +```shell +# 10.0.170.92 の部分をウェブサーバーのPodのIPv4アドレスに置き換えてください +wget -qO - 10.0.170.92 +``` +``` +CLIENT VALUES: +client_address=10.244.3.8 +command=GET +... +``` + +`client_address`は常にクライアントのPodのIPアドレスになります。これは、クライアントのPodとサーバーのPodが同じノード内にあっても異なるノードにあっても変わりません。 + +## `Type=NodePort`を使用したServiceでの送信元IP + +[`Type=NodePort`](/ja/docs/concepts/services-networking/service/#nodeport)を使用したServiceに送られたパケットは、デフォルトで送信元のNATが行われます。`NodePort` Serviceを作ることでテストできます。 + +```shell +kubectl expose deployment source-ip-app --name=nodeport --port=80 --target-port=8080 --type=NodePort +``` + +出力は次のようになります。 + +``` +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:nodeport`に対してファイアウォールのルールを作成する必要があるかもしれません。それでは、上で割り当てたノードポート経由で、クラスターの外部からServiceにアクセスしてみましょう。 + +```shell +for node in $NODES; do curl -s $node:$NODEPORT | grep -i client_address; done +``` + +出力は次のようになります。 + +``` +client_address=10.180.1.1 +client_address=10.240.0.5 +client_address=10.240.0.3 +``` + +これらは正しいクライアントIPではなく、クラスターのinternal IPであることがわかります。ここでは、次のようなことが起こっています。 + +* クライアントがパケットを`node2:nodePort`に送信する +* `node2`は、パケット内の送信元IPアドレスを自ノードのIPアドレスに置換する(SNAT) +* `node2`は、パケット内の送信先IPアドレスをPodのIPアドレスに置換する +* パケットはnode1にルーティングされ、endpointにルーティングされる +* Podからの応答がnode2にルーティングされて戻ってくる +* Podからの応答がクライアントに送り返される + +図で表すと次のようになります。 + +``` + client + \ ^ + \ \ + v \ + node 1 <--- node 2 + | ^ SNAT + | | ---> + v | + endpoint +``` + +クライアントの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が正しいことを信頼できます。 + +次のようにして`service.spec.externalTrafficPolicy`フィールドを設定します。 + +```shell +kubectl patch svc nodeport -p '{"spec":{"externalTrafficPolicy":"Local"}}' +``` + +出力は次のようになります。 + +``` +service/nodeport patched +``` + +そして、再度テストしてみます。 + +```shell +for node in $NODES; do curl --connect-timeout 1 -s $node:$NODEPORT | grep -i client_address; done +``` + +出力は次のようになります。 + +``` +client_address=198.51.100.79 +``` + +今度は、*正しい*クライアントIPが含まれる応答が1つだけ得られました。これは、エンドポイントのPodが実行されているノードから来たものです。 + +ここでは、次のようなことが起こっています。 + +* クライアントがパケットをエンドポイントが存在しない`node2:nodePort`に送信する +* パケットが損失する +* クライアントがパケットをエンドポイントが*存在する*`node1:nodePort`に送信する +* node1は、正しい送信元IPを持つパケットをエンドポイントにルーティングする + +図で表すと次のようになります。 + +``` + client + ^ / \ + / / \ + / v X + node 1 node 2 + ^ | + | | + | v + endpoint +``` + +## `Type=LoadBalancer`を使用したServiceでの送信元IP + +[`Type=LoadBalancer`](/ja/docs/concepts/services-networking/service/#loadbalancer)を使用したServiceに送られたパケットは、デフォルトでは送信元のNATは行われません。`Ready`状態にあるすべてのスケジュール可能なKubernetesのNodeは、ロードバランサーからのトラフィックを受付可能であるためです。そのため、エンドポイントが存在しないノードにパケットが到達した場合、システムはエンドポイントが*存在する*ノードにパケットをプロシキーします。このとき、(前のセクションで説明したように)パケットの送信元IPがノードのIPに置換されます。 + +ロードバランサー経由でsource-ip-appを公開することで、これをテストできます。 + +```shell +kubectl expose deployment source-ip-app --name=loadbalancer --port=80 --target-port=8080 --type=LoadBalancer +``` + +出力は次のようになります。 + +``` +service/loadbalancer exposed +``` + +ServiceのIPアドレスを表示します。 + +```console +kubectl get svc loadbalancer +``` + +出力は次のようになります。 + +``` +NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE +loadbalancer LoadBalancer 10.0.65.118 203.0.113.140 80/TCP 5m +``` + +次に、Serviceのexternal-ipにリクエストを送信します。 + +```shell +curl 203.0.113.140 +``` + +出力は次のようになります。 + +``` +CLIENT VALUES: +client_address=10.240.0.5 +... +``` + +しかし、Google Kubernetes EngineやGCE上で実行している場合、同じ`service.spec.externalTrafficPolicy`フィールドを`Local`に設定すると、ロードバランサーからのトラフィックを受け付け可能なノードのリストから、Serviceエンドポイントが*存在しない*ノードが強制的に削除されます。この動作は、ヘルスチェックを意図的に失敗させることによって実現されています。 + +図で表すと次のようになります。 + +``` + client + | + lb VIP + / ^ + v / +ヘルスチェック ---> node 1 node 2 <--- ヘルスチェック + 200 <--- ^ | ---> 500 + | V + endpoint +``` + +アノテーションを設定することで動作をテストできます。 + +```shell +kubectl patch svc loadbalancer -p '{"spec":{"externalTrafficPolicy":"Local"}}' +``` + +Kubernetesにより割り当てられた`service.spec.healthCheckNodePort`フィールドをすぐに確認します。 + +```shell +kubectl get svc loadbalancer -o yaml | grep -i healthCheckNodePort +``` + +出力は次のようになります。 + +```yaml + healthCheckNodePort: 32122 +``` + +`service.spec.healthCheckNodePort`フィールドは、`/healthz`でhealth checkを配信しているすべてのノード上のポートを指しています。次のコマンドでテストできます。 + +```shell +kubectl get pod -o wide -l run=source-ip-app +``` + +出力は次のようになります。 + +``` +NAME READY STATUS RESTARTS AGE IP NODE +source-ip-app-826191075-qehz4 1/1 Running 0 20h 10.180.1.136 kubernetes-node-6jst +``` + +`curl`を使用して、さまざまなノード上の`/healthz`エンドポイントからデータを取得します。 + +```shell +# このコマンドは選んだノードのローカル上で実行してください +curl localhost:32122/healthz +``` +``` +1 Service Endpoints found +``` + +ノードが異なると、得られる結果も異なる可能性があります。 + +```shell +# このコマンドは、選んだノード上でローカルに実行してください +curl localhost:32122/healthz +``` +``` +No Service Endpoints Found +``` + +{{< glossary_tooltip text="コントロールプレーン" term_id="control-plane" >}}上で実行中のコントローラーは、クラウドのロードバランサーを割り当てる責任があります。同じコントローラーは、各ノード上のポートやパスを指すHTTPのヘルスチェックも割り当てます。エンドポイントが存在しない2つのノードがヘルスチェックに失敗するまで約10秒待った後、`curl`を使用してロードバランサーのIPv4アドレスに問い合わせます。 + +```shell +curl 203.0.113.140 +``` + +出力は次のようになります。 + +``` +CLIENT VALUES: +client_address=198.51.100.79 +... +``` + +## クロスプラットフォームのサポート + +`Type=LoadBalancer`を使用したServiceで送信元IPを保持する機能を提供しているのは一部のクラウドプロバイダだけです。実行しているクラウドプロバイダによっては、以下のように異なる方法でリクエストを満たす場合があります。 + +1. クライアントとのコネクションをプロキシーが終端し、ノードやエンドポイントとの接続には新しいコネクションが開かれる。このような場合、送信元IPは常にクラウドのロードバランサーのものになり、クライアントのIPにはなりません。 + +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のヘルスチェックを作成することで、上記の機能を活用できます。 + +## {{% heading "cleanup" %}} + +Serviceを削除します。 + +```shell +kubectl delete svc -l run=source-ip-app +``` + +Deployment、ReplicaSet、Podを削除します。 + +```shell +kubectl delete deployment source-ip-app +``` + +## {{% heading "whatsnext" %}} + +* [Service経由でアプリケーションに接続する](/ja/docs/concepts/services-networking/connect-applications-service/)方法についてさらに学ぶ。 +* [External Load Balancerを作成する](/docs/tasks/access-application-cluster/create-external-load-balancer/)方法について学ぶ。 + + diff --git a/content/ja/docs/tutorials/stateful-application/_index.md b/content/ja/docs/tutorials/stateful-application/_index.md new file mode 100755 index 0000000000..421915d42c --- /dev/null +++ b/content/ja/docs/tutorials/stateful-application/_index.md @@ -0,0 +1,5 @@ +--- +title: "ステートフルアプリケーション" +weight: 50 +--- + diff --git a/content/ja/docs/tutorials/stateful-application/basic-stateful-set.md b/content/ja/docs/tutorials/stateful-application/basic-stateful-set.md new file mode 100644 index 0000000000..d8a0acbdf6 --- /dev/null +++ b/content/ja/docs/tutorials/stateful-application/basic-stateful-set.md @@ -0,0 +1,1026 @@ +--- +title: StatefulSetの基本 +content_type: tutorial +weight: 10 +--- + + +このチュートリアルでは、{{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}}を使用したアプリケーションを管理するための基本を説明します。StatefulSetのPodを作成、削除、スケール、そして更新する方法について紹介します。 + +## {{% heading "prerequisites" %}} + +このチュートリアルを始める前に、以下のKubernetesの概念について理解しておく必要があります。 + +* [Pod](/ja/docs/concepts/workloads/pods/) +* [Cluster DNS](/ja/docs/concepts/services-networking/dns-pod-service/) +* [Headless Service](/ja/docs/concepts/services-networking/service/#headless-services) +* [PersistentVolume](/ja/docs/concepts/storage/persistent-volumes/) +* [PersistentVolumeのプロビジョニング](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/) +* [StatefulSet](/ja/docs/concepts/workloads/controllers/statefulset/) +* [kubectl](/docs/reference/kubectl/kubectl/)コマンドラインツール + +{{< note >}} +このチュートリアルでは、クラスターがPersistentVolumeの動的なプロビジョニングが行われるように設定されていることを前提としています。クラスターがそのように設定されていない場合、チュートリアルを始める前に1GiBのボリュームを2つ手動でプロビジョニングする必要があります。 +{{< /note >}} + +## {{% heading "objectives" %}} + +StatefulSetはステートフルアプリケーションや分散システムで使用するために存在します。しかし、Kubernetes上のステートフルアプリケーションや分散システムは、広範で複雑なトピックです。StatefulSetの基本的な機能を示すという目的のため、また、ステートフルアプリケーションを分散システムと混同しないようにするために、ここでは、Statefulsetを使用する単純なウェブアプリケーションのデプロイを行います。 + +このチュートリアルを終えると、以下のことが理解できるようになります。 + +* StatefulSetの作成方法 +* StatefulSetがどのようにPodを管理するのか +* StatefulSetの削除方法 +* StatefulSetのスケール方法 +* StatefulSetが管理するPodの更新方法 + + + +## StatefulSetを作成する {#ordered-pod-creation} + +はじめに、以下の例を使ってStatefulSetを作成しましょう。これは、コンセプトの[StatefulSet](/ja/docs/concepts/workloads/controllers/statefulset/)のページで使ったものと同じような例です。`nginx`という[headless Service](/ja/docs/concepts/services-networking/service/#headless-services)を作成し、`web`というStatefulSet内のPodのIPアドレスを公開します。 + +{{< codenew file="application/web/web.yaml" >}} + +上の例をダウンロードして、`web.yaml`という名前で保存します。 + +ここでは、ターミナルウィンドウを2つ使う必要があります。1つ目のターミナルでは、[`kubectl get`](/ja/docs/reference/generated/kubectl/kubectl-commands/#get)を使って、StatefulSetのPodの作成を監視します。 + +```shell +kubectl get pods -w -l app=nginx +``` + +2つ目のターミナルでは、[`kubectl apply`](/ja/docs/reference/generated/kubectl/kubectl-commands/#apply)を使って、`web.yaml`に定義されたheadless ServiceとStatefulSetを作成します。 + +```shell +kubectl apply -f web.yaml +``` +``` +service/nginx created +statefulset.apps/web created +``` + +上のコマンドを実行すると、2つのPodが作成され、それぞれのPodで[NGINX](https://www.nginx.com)ウェブサーバーが実行されます。`nginx`Serviceを取得してみましょう。 +```shell +kubectl get service nginx +``` +``` +NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE +nginx ClusterIP None 80/TCP 12s +``` +そして、`web`StatefulSetを取得して、2つのリソースの作成が成功したことも確認します。 +```shell +kubectl get statefulset web +``` +``` +NAME DESIRED CURRENT AGE +web 2 1 20s +``` + +### 順序付きPodの作成 + +_n_ 個のレプリカを持つStatefulSetは、Podをデプロイするとき、1つずつ順番に作成し、 _{0..n-1}_ という順序付けを行います。1つ目のターミナルで`kubectl get`コマンドの出力を確認しましょう。最終的に、以下の例のような出力が表示されるはずです。 + +```shell +kubectl get pods -w -l app=nginx +``` +``` +NAME READY STATUS RESTARTS AGE +web-0 0/1 Pending 0 0s +web-0 0/1 Pending 0 0s +web-0 0/1 ContainerCreating 0 0s +web-0 1/1 Running 0 19s +web-1 0/1 Pending 0 0s +web-1 0/1 Pending 0 0s +web-1 0/1 ContainerCreating 0 0s +web-1 1/1 Running 0 18s +``` + +`web-0`Podが _Running_ ([Pod Phase](/ja/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase)を参照)かつ _Ready_ ([Pod Conditions](/ja/docs/concepts/workloads/pods/pod-lifecycle/#pod-conditions)の`type`を参照)の状態になるまでは、`web-1`Podが起動していないことに注目してください。 + +## StatefulSet内のPod + +StatefulSet内のPodは、ユニークな順序インデックスと安定したネットワーク識別子を持ちます。 + +### Podの順序インデックスを確かめる + +StatefulSetのPodを取得します。 + +```shell +kubectl get pods -l app=nginx +``` +``` +NAME READY STATUS RESTARTS AGE +web-0 1/1 Running 0 1m +web-1 1/1 Running 0 1m +``` + +[StatefulSet](/ja/docs/concepts/workloads/controllers/statefulset/)のコンセプトで説明したように、StatefulSet内のPodは安定したユニークな識別子を持ちます。この識別子は、StatefulSet{{< glossary_tooltip term_id="controller" text="コントローラー">}}によって各Podに割り当てられる、ユニークな順序インデックスに基づいて付けられます。Podの名前は、`-<順序インデックス>`という形式です。`web`StatefulSetは2つのレプリカを持つため、`web-0`と`web-1`という2つのPodを作成します。 + +### 安定したネットワーク識別子の使用 + +各Podは、順序インデックスに基づいた安定したホスト名を持ちます。[`kubectl exec`](/ja/docs/reference/generated/kubectl/kubectl-commands/#exec)を使用して、各Pod内で`hostname`コマンドを実行してみましょう。 + +```shell +for i in 0 1; do kubectl exec "web-$i" -- sh -c 'hostname'; done +``` +``` +web-0 +web-1 +``` + +[`kubectl run`](/ja/docs/reference/generated/kubectl/kubectl-commands/#run)を使用して、`dnsutils`パッケージの`nslookup`コマンドを提供するコンテナを実行します。Podのホスト名に対して`nslookup`を実行すると、クラスター内のDNSアドレスが確認できます。 + +```shell +kubectl run -i --tty --image busybox:1.28 dns-test --restart=Never --rm +``` +これにより、新しいシェルが起動します。新しいシェルで、次のコマンドを実行します。 +```shell +# このコマンドは、dns-testコンテナのシェルで実行してください +nslookup web-0.nginx +``` +出力は次のようになります。 +``` +Server: 10.0.0.10 +Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local + +Name: web-0.nginx +Address 1: 10.244.1.6 + +nslookup web-1.nginx +Server: 10.0.0.10 +Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local + +Name: web-1.nginx +Address 1: 10.244.2.6 +``` + +(コンテナのシェルを終了するために、`exit`コマンドを実行してください。) + +headless serviceのCNAMEは、SRVレコードを指しています(1つのレコードがRunningかつReadyのPodに対応します)。SRVレコードは、PodのIPアドレスを含むAレコードを指します。 + +1つ目のターミナルで、StatefulSetのPodを監視します。 + +```shell +kubectl get pod -w -l app=nginx +``` +2つ目のターミナルで、[`kubectl delete`](/ja/docs/reference/generated/kubectl/kubectl-commands/#delete)を使用して、StatefulSetのすべてのPodを削除します。 + +```shell +kubectl delete pod -l app=nginx +``` +``` +pod "web-0" deleted +pod "web-1" deleted +``` + +StatefulSetがPodを再起動して、2つのPodがRunningかつReadyの状態に移行するのを待ちます。 + +```shell +kubectl get pod -w -l app=nginx +``` +``` +NAME READY STATUS RESTARTS AGE +web-0 0/1 ContainerCreating 0 0s +NAME READY STATUS RESTARTS AGE +web-0 1/1 Running 0 2s +web-1 0/1 Pending 0 0s +web-1 0/1 Pending 0 0s +web-1 0/1 ContainerCreating 0 0s +web-1 1/1 Running 0 34s +``` + +`kubectl exec`と`kubectl run`コマンドを使用して、Podのホスト名とクラスター内DNSエントリーを確認します。まず、Podのホスト名を見てみましょう。 + +```shell +for i in 0 1; do kubectl exec web-$i -- sh -c 'hostname'; done +``` +``` +web-0 +web-1 +``` +その後、次のコマンドを実行します。 +``` +kubectl run -i --tty --image busybox:1.28 dns-test --restart=Never --rm /bin/sh +``` +これにより、新しいシェルが起動します。新しいシェルで、次のコマンドを実行します。 +```shell +# このコマンドは、dns-testコンテナのシェルで実行してください +nslookup web-0.nginx +``` +出力は次のようになります。 +``` +Server: 10.0.0.10 +Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local + +Name: web-0.nginx +Address 1: 10.244.1.7 + +nslookup web-1.nginx +Server: 10.0.0.10 +Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local + +Name: web-1.nginx +Address 1: 10.244.2.8 +``` + +(コンテナのシェルを終了するために、`exit`コマンドを実行してください。) + +Podの順序インデックス、ホスト名、SRVレコード、そしてAレコード名は変化していませんが、Podに紐付けられたIPアドレスは変化する可能性があります。このチュートリアルで使用しているクラスターでは、IPアドレスは変わりました。このようなことがあるため、他のアプリケーションがStatefulSet内のPodに接続するときには、IPアドレスで指定しないことが重要です。 + +StatefulSetの有効なメンバーを探して接続する必要がある場合は、headless ServiceのCNAME(`nginx.default.svc.cluster.local`)をクエリしなければなりません。CNAMEに紐付けられたSRVレコードには、StatefulSet内のRunnningかつReadyなPodだけが含まれます。 + +アプリケーションがlivenessとreadinessをテストするコネクションのロジックをすでに実装している場合、PodのSRVレコード(`web-0.nginx.default.svc.cluster.local`、`web-1.nginx.default.svc.cluster.local`)をPodが安定しているものとして使用できます。PodがRunning and Readyな状態に移行すれば、アプリケーションはPodのアドレスを発見できるようになります。 + +### 安定したストレージへの書き込み {#writing-to-stable-storage} + +`web-0`および`web-1`のためのPersistentVolumeClaimを取得しましょう。 + +```shell +kubectl get pvc -l app=nginx +``` +出力は次のようになります。 +``` +NAME STATUS VOLUME CAPACITY ACCESSMODES AGE +www-web-0 Bound pvc-15c268c7-b507-11e6-932f-42010a800002 1Gi RWO 48s +www-web-1 Bound pvc-15c79307-b507-11e6-932f-42010a800002 1Gi RWO 48s +``` + +StatefulSetコントローラーは、2つの{{< glossary_tooltip text="PersistentVolume" term_id="persistent-volume" >}}にバインドされた2つの{{< glossary_tooltip text="PersistentVolumeClaim" term_id="persistent-volume-claim" >}}を作成しています。 + +このチュートリアルで使用しているクラスターでは、PersistentVolumeの動的なプロビジョニングが設定されているため、PersistentVolumeが自動的に作成されてバインドされています。 + +デフォルトでは、NGINXウェブサーバーは`/usr/share/nginx/html/index.html`に置かれたindexファイルを配信します。StatefulSetの`spec`内の`volumeMounts`フィールドによって、`/usr/share/nginx/html`ディレクトリがPersistentVolume上にあることが保証されます。 + +Podのホスト名を`index.html`ファイルに書き込むことで、NGINXウェブサーバーがホスト名を配信することを検証しましょう。 + +```shell +for i in 0 1; do kubectl exec "web-$i" -- sh -c 'echo "$(hostname)" > /usr/share/nginx/html/index.html'; done + +for i in 0 1; do kubectl exec -i -t "web-$i" -- curl http://localhost/; done +``` +``` +web-0 +web-1 +``` + +{{< note >}} +上記のcurlコマンドに対して代わりに**403 Forbidden**というレスポンスが返ってくる場合、`volumeMounts`でマウントしたディレクトリのパーミッションを修正する必要があります(これは、[hostPathボリュームを使用したときに起こるバグ](https://github.com/kubernetes/kubernetes/issues/2630)が原因です)。この問題に対処するには、上の`curl`コマンドを再実行する前に、次のコマンドを実行します。 + +`for i in 0 1; do kubectl exec web-$i -- chmod 755 /usr/share/nginx/html; done` +{{< /note >}} + +1つ目のターミナルで、StatefulSetのPodを監視します。 + +```shell +kubectl get pod -w -l app=nginx +``` + +2つ目のターミナルで、StatefulSetのすべてのPodを削除します。 + +```shell +kubectl delete pod -l app=nginx +``` +``` +pod "web-0" deleted +pod "web-1" deleted +``` +1つ目のターミナルで`kubectl get`コマンドの出力を確認して、すべてのPodがRunningかつReadyの状態に変わるまで待ちます。 + +```shell +kubectl get pod -w -l app=nginx +``` +``` +NAME READY STATUS RESTARTS AGE +web-0 0/1 ContainerCreating 0 0s +NAME READY STATUS RESTARTS AGE +web-0 1/1 Running 0 2s +web-1 0/1 Pending 0 0s +web-1 0/1 Pending 0 0s +web-1 0/1 ContainerCreating 0 0s +web-1 1/1 Running 0 34s +``` + +ウェブサーバーがホスト名を配信し続けていることを確認します。 + +``` +for i in 0 1; do kubectl exec -i -t "web-$i" -- curl http://localhost/; done +``` +``` +web-0 +web-1 +``` + +もし`web-0`および`web-1`が再スケジュールされたとしても、Podは同じホスト名を配信し続けます。これは、PodのPersistentVolumeClaimに紐付けられたPersistentVolumeが、Podの`volumeMounts`に再マウントされるためです。`web-0`と`web-1`がどんなノードにスケジュールされたとしても、PodのPersistentVolumeは適切なマウントポイントにマウントされます。 + +## StatefulSetをスケールする + +StatefulSetのスケールとは、レプリカ数を増減することを意味します。これは、`replicas`フィールドを更新することによって実現できます。StatefulSetのスケールには、[`kubectl scale`](/ja/docs/reference/generated/kubectl/kubectl-commands/#scale)と +[`kubectl patch`](/ja/docs/reference/generated/kubectl/kubectl-commands/#patch)のどちらも使用できます。 + +### スケールアップ + +1つ目のターミナルで、StatefulSet内のPodを監視します。 + +```shell +kubectl get pods -w -l app=nginx +``` + +2つ目のターミナルで、`kubectl scale`を使って、レプリカ数を5にスケールします。 + +```shell +kubectl scale sts web --replicas=5 +``` +``` +statefulset.apps/web scaled +``` + +1つ目のターミナルの`kubectl get`コマンドの出力を確認して、3つの追加のPodがRunningかつReadyの状態に変わるまで待ちます。 + +```shell +kubectl get pods -w -l app=nginx +``` +``` +NAME READY STATUS RESTARTS AGE +web-0 1/1 Running 0 2h +web-1 1/1 Running 0 2h +NAME READY STATUS RESTARTS AGE +web-2 0/1 Pending 0 0s +web-2 0/1 Pending 0 0s +web-2 0/1 ContainerCreating 0 0s +web-2 1/1 Running 0 19s +web-3 0/1 Pending 0 0s +web-3 0/1 Pending 0 0s +web-3 0/1 ContainerCreating 0 0s +web-3 1/1 Running 0 18s +web-4 0/1 Pending 0 0s +web-4 0/1 Pending 0 0s +web-4 0/1 ContainerCreating 0 0s +web-4 1/1 Running 0 19s +``` + +StatefulSetコントローラーはレプリカ数をスケールします。 +[StatefulSetを作成する](#ordered-pod-creation)で説明したように、StatefulSetコントローラーは各Podを順序インデックスに従って1つずつ作成し、次のPodを起動する前に、1つ前のPodがRunningかつReadyの状態になるまで待ちます。 + +### スケールダウン {#scaling-down} + +1つ目のターミナルで、StatefulSetのPodを監視します。 + +```shell +kubectl get pods -w -l app=nginx +``` + +2つ目のターミナルで、`kubectl patch`コマンドを使用して、StatefulSetを3つのレプリカにスケールダウンします。 + +```shell +kubectl patch sts web -p '{"spec":{"replicas":3}}' +``` +``` +statefulset.apps/web patched +``` + +`web-4`および`web-3`がTerminatingの状態になるまで待ちます。 + +```shell +kubectl get pods -w -l app=nginx +``` +``` +NAME READY STATUS RESTARTS AGE +web-0 1/1 Running 0 3h +web-1 1/1 Running 0 3h +web-2 1/1 Running 0 55s +web-3 1/1 Running 0 36s +web-4 0/1 ContainerCreating 0 18s +NAME READY STATUS RESTARTS AGE +web-4 1/1 Running 0 19s +web-4 1/1 Terminating 0 24s +web-4 1/1 Terminating 0 24s +web-3 1/1 Terminating 0 42s +web-3 1/1 Terminating 0 42s +``` + +### 順序付きPodを削除する + +コントローラーは、順序インデックスの逆順に1度に1つのPodを削除し、次のPodを削除する前には、各Podが完全にシャットダウンするまで待機しています。 + +StatefulSetのPersistentVolumeClaimを取得しましょう。 + +```shell +kubectl get pvc -l app=nginx +``` +``` +NAME STATUS VOLUME CAPACITY ACCESSMODES AGE +www-web-0 Bound pvc-15c268c7-b507-11e6-932f-42010a800002 1Gi RWO 13h +www-web-1 Bound pvc-15c79307-b507-11e6-932f-42010a800002 1Gi RWO 13h +www-web-2 Bound pvc-e1125b27-b508-11e6-932f-42010a800002 1Gi RWO 13h +www-web-3 Bound pvc-e1176df6-b508-11e6-932f-42010a800002 1Gi RWO 13h +www-web-4 Bound pvc-e11bb5f8-b508-11e6-932f-42010a800002 1Gi RWO 13h + +``` + +まだ、5つのPersistentVolumeClaimと5つのPersistentVolumeが残っています。[安定したストレージへの書き込み](#writing-to-stable-storage)を読むと、StatefulSetのPodが削除されても、StatefulSetのPodにマウントされたPersistentVolumeは削除されないと書かれています。このことは、StatefulSetのスケールダウンによってPodが削除された場合にも当てはまります。 + +## StatefulSetsを更新する + +Kubernetes 1.7以降では、StatefulSetコントローラーは自動アップデートをサポートしています。使われる戦略は、StatefulSet APIオブジェクトの`spec.updateStrategy`フィールドによって決まります。この機能はコンテナイメージのアップグレード、リソースのrequestsやlimits、ラベル、StatefulSet内のPodのアノテーションの更新時に利用できます。有効なアップデートの戦略は、`RollingUpdate`と`OnDelete`の2種類です。 + +`RollingUpdate`は、StatefulSetのデフォルトのアップデート戦略です。 + +### RollingUpdate + +`RollingUpdate`アップデート戦略は、StatefulSetの保証を尊重しながら、順序インデックスの逆順にStatefulSet内のすべてのPodをアップデートします。 + +`web`StatefulSetにpatchを当てて、`RollingUpdate`アップデート戦略を適用しましょう。 + +```shell +kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate"}}}' +``` +``` +statefulset.apps/web patched +``` + +1つ目のターミナルで、`web`StatefulSetに再度patchを当てて、コンテナイメージを変更します。 + +```shell +kubectl patch statefulset web --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"gcr.io/google_containers/nginx-slim:0.8"}]' +``` +``` +statefulset.apps/web patched +``` + +2つ目のターミナルで、StatefulSet内のPodを監視します。 + +```shell +kubectl get pod -l app=nginx -w +``` +出力は次のようになります。 +``` +NAME READY STATUS RESTARTS AGE +web-0 1/1 Running 0 7m +web-1 1/1 Running 0 7m +web-2 1/1 Running 0 8m +web-2 1/1 Terminating 0 8m +web-2 1/1 Terminating 0 8m +web-2 0/1 Terminating 0 8m +web-2 0/1 Terminating 0 8m +web-2 0/1 Terminating 0 8m +web-2 0/1 Terminating 0 8m +web-2 0/1 Pending 0 0s +web-2 0/1 Pending 0 0s +web-2 0/1 ContainerCreating 0 0s +web-2 1/1 Running 0 19s +web-1 1/1 Terminating 0 8m +web-1 0/1 Terminating 0 8m +web-1 0/1 Terminating 0 8m +web-1 0/1 Terminating 0 8m +web-1 0/1 Pending 0 0s +web-1 0/1 Pending 0 0s +web-1 0/1 ContainerCreating 0 0s +web-1 1/1 Running 0 6s +web-0 1/1 Terminating 0 7m +web-0 1/1 Terminating 0 7m +web-0 0/1 Terminating 0 7m +web-0 0/1 Terminating 0 7m +web-0 0/1 Terminating 0 7m +web-0 0/1 Terminating 0 7m +web-0 0/1 Pending 0 0s +web-0 0/1 Pending 0 0s +web-0 0/1 ContainerCreating 0 0s +web-0 1/1 Running 0 10s +``` + +StatefulSet内のPodは、順序インデックスの逆順に更新されました。StatefulSetコントローラーは各Podを終了させ、次のPodを更新する前に、新しいPodがRunningかつReadyの状態に変わるまで待機します。ここで、StatefulSetコントローラーは順序インデックスの前のPodがRunningかつReadyの状態になるまで次のPodの更新を始めず、現在の状態へのアップデートに失敗したPodがあった場合、そのPodをリストアすることに注意してください。 + +すでにアップデートを受け取ったPodは、アップデートされたバージョンにリストアされます。まだアップデートを受け取っていないPodは、前のバージョンにリストアされます。このような方法により、もし途中で失敗が起こっても、コントローラはアプリケーションが健全な状態を保ち続けられるようにし、更新が一貫したものになるようにします。 + +Podを取得して、コンテナイメージを確認してみましょう。 + +```shell +for p in 0 1 2; do kubectl get pod "web-$p" --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'; echo; done +``` +``` +k8s.gcr.io/nginx-slim:0.8 +k8s.gcr.io/nginx-slim:0.8 +k8s.gcr.io/nginx-slim:0.8 + +``` + +現在、StatefulSet内のすべてのPodは、前のコンテナイメージを実行しています。 + +{{< note >}} +`kubectl rollout status sts/`を使って、StatefulSetへのローリングアップデートの状態を確認することもできます。 +{{< /note >}} + +#### ステージングアップデート {#staging-an-update} + +`RollingUpdate`アップデート戦略に`partition`パラメーターを使用すると、StatefulSetへのアップデートをステージングすることができます。ステージングアップデートを利用すれば、StatefulSet内のすべてのPodを現在のバージョンにしたまま、StatefulSetの`.spec.template`を変更することが可能になります。 + +`web`StatefulSetにpatchを当てて、`updateStrategy`フィールドにpartitionを追加しましょう。 + +```shell +kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate","rollingUpdate":{"partition":3}}}}' +``` +``` +statefulset.apps/web patched +``` + +StatefulSetに再度patchを当てて、コンテナイメージを変更します。 + +```shell +kubectl patch statefulset web --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"k8s.gcr.io/nginx-slim:0.7"}]' +``` +``` +statefulset.apps/web patched +``` + +StatefulSet内のPodを削除します。 + +```shell +kubectl delete pod web-2 +``` +``` +pod "web-2" deleted +``` + +PodがRunningかつReadyになるまで待ちます。 + +```shell +kubectl get pod -l app=nginx -w +``` +``` +NAME READY STATUS RESTARTS AGE +web-0 1/1 Running 0 4m +web-1 1/1 Running 0 4m +web-2 0/1 ContainerCreating 0 11s +web-2 1/1 Running 0 18s +``` + +Podのコンテナイメージを取得します。 + +```shell +kubectl get pod web-2 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}' +``` +``` +k8s.gcr.io/nginx-slim:0.8 +``` + +アップデート戦略が`RollingUpdate`であっても、StatefulSetが元のコンテナを持つPodをリストアしたことがわかります。これは、Podの順序インデックスが`updateStrategy`で指定した`partition`より小さいためです。 + +#### カナリア版をロールアウトする {#rolling-out-a-canary} + +[ステージングアップデート](#staging-an-update)のときに指定した`partition`を小さくすることで、変更をテストするためのカナリア版をロールアウトできます。 + +StatefulSetにpatchを当てて、partitionを小さくします。 + +```shell +kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate","rollingUpdate":{"partition":2}}}}' +``` +``` +statefulset.apps/web patched +``` + +`web-2`がRunningかつReadyの状態になるまで待ちます。 + +```shell +kubectl get pod -l app=nginx -w +``` +``` +NAME READY STATUS RESTARTS AGE +web-0 1/1 Running 0 4m +web-1 1/1 Running 0 4m +web-2 0/1 ContainerCreating 0 11s +web-2 1/1 Running 0 18s +``` + +Podのコンテナを取得します。 + +```shell +kubectl get pod web-2 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}' +``` +``` +k8s.gcr.io/nginx-slim:0.7 + +``` + +`partition`を変更すると、StatefulSetコントローラーはPodを自動的に更新します。Podの順序インデックスが`partition`以上の値であるためです。 + +`web-1`Podを削除します。 + +```shell +kubectl delete pod web-1 +``` +``` +pod "web-1" deleted +``` + +`web-1`PodがRunningかつReadyになるまで待ちます。 + +```shell +kubectl get pod -l app=nginx -w +``` +出力は次のようになります。 +``` +NAME READY STATUS RESTARTS AGE +web-0 1/1 Running 0 6m +web-1 0/1 Terminating 0 6m +web-2 1/1 Running 0 2m +web-1 0/1 Terminating 0 6m +web-1 0/1 Terminating 0 6m +web-1 0/1 Terminating 0 6m +web-1 0/1 Pending 0 0s +web-1 0/1 Pending 0 0s +web-1 0/1 ContainerCreating 0 0s +web-1 1/1 Running 0 18s +``` + +`web-1`Podのコンテナイメージを取得します。 + +```shell +kubectl get pod web-1 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}' +``` +``` +k8s.gcr.io/nginx-slim:0.8 +``` + +Podの順序インデックスがpartitionよりも小さいため、`web-1`は元の設定のコンテナイメージにリストアされました。partitionを指定すると、StatefulSetの`.spec.template`が更新されたときに、順序インデックスがそれ以上の値を持つすべてのPodがアップデートされます。partitionよりも小さな順序インデックスを持つPodが削除されたり終了されたりすると、元の設定のPodにリストアされます。 + +#### フェーズロールアウト + +[カナリア版](#rolling-out-a-canary)をロールアウトするのと同じような方法でパーティションされたローリングアップデートを使用すると、フェーズロールアウト(例: 線形、幾何級数的、指数関数的ロールアウト)を実行できます。フェーズロールアウトを実行するには、コントローラーがアップデートを途中で止めてほしい順序インデックスを`partition`に設定します。 + +現在、partitionは`2`に設定されています。partitionを`0`に設定します。 + +```shell +kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate","rollingUpdate":{"partition":0}}}}' +``` +``` +statefulset.apps/web patched +``` + +StatefulSet内のすべてのPodがRunningかつReadyの状態になるまで待ちます。 + +```shell +kubectl get pod -l app=nginx -w +``` +出力は次のようになります。 +``` +NAME READY STATUS RESTARTS AGE +web-0 1/1 Running 0 3m +web-1 0/1 ContainerCreating 0 11s +web-2 1/1 Running 0 2m +web-1 1/1 Running 0 18s +web-0 1/1 Terminating 0 3m +web-0 1/1 Terminating 0 3m +web-0 0/1 Terminating 0 3m +web-0 0/1 Terminating 0 3m +web-0 0/1 Terminating 0 3m +web-0 0/1 Terminating 0 3m +web-0 0/1 Pending 0 0s +web-0 0/1 Pending 0 0s +web-0 0/1 ContainerCreating 0 0s +web-0 1/1 Running 0 3s +``` + +StatefulSet内のPodのコンテナイメージの詳細を取得します。 + +```shell +for p in 0 1 2; do kubectl get pod "web-$p" --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'; echo; done +``` +``` +k8s.gcr.io/nginx-slim:0.7 +k8s.gcr.io/nginx-slim:0.7 +k8s.gcr.io/nginx-slim:0.7 +``` + +`partition`を`0`に移動することで、StatefulSetがアップデート処理を続けられるようにできます。 + +### OnDelete + +`OnDelete`アップデート戦略は、(1.6以前の)レガシーな動作を実装しています。このアップデート戦略を選択すると、StatefulSetの`.spec.template`フィールドへ変更を加えても、StatefulSetコントローラーが自動的にPodを更新しなくなります。この戦略を選択するには、`.spec.template.updateStrategy.type`に`OnDelete`を設定します。 + +## StatefulSetを削除する + +StatefulSetは、非カスケードな削除とカスケードな削除の両方をサポートしています。非カスケードな削除では、StatefulSetが削除されても、StatefulSet内のPodは削除されません。カスケードな削除では、StatefulSetとPodが一緒に削除されます。 + +### 非カスケードな削除 + +1つ目のターミナルで、StatefulSet内のPodを監視します + +``` +kubectl get pods -w -l app=nginx +``` + +[`kubectl delete`](/ja/docs/reference/generated/kubectl/kubectl-commands/#delete)を使用して、StatefulSetを削除します。このとき、`--cascade=false`パラメーターをコマンドに与えてください。このパラメーターは、Kubernetesに対して、StatefulSetだけを削除して配下のPodは削除しないように指示します。 + +```shell +kubectl delete statefulset web --cascade=false +``` +``` +statefulset.apps "web" deleted +``` + +Podを取得して、ステータスを確認します。 + +```shell +kubectl get pods -l app=nginx +``` +``` +NAME READY STATUS RESTARTS AGE +web-0 1/1 Running 0 6m +web-1 1/1 Running 0 7m +web-2 1/1 Running 0 5m +``` + +`web`が削除されても、すべてのPodはまだRunningかつReadyの状態のままです。`web-0`を削除します。 + +```shell +kubectl delete pod web-0 +``` +``` +pod "web-0" deleted +``` + +StatefulSetのPodを取得します。 + +```shell +kubectl get pods -l app=nginx +``` +``` +NAME READY STATUS RESTARTS AGE +web-1 1/1 Running 0 10m +web-2 1/1 Running 0 7m +``` + +`web`StatefulSetはすでに削除されているため、`web-0`は再起動しません。 + +1つ目のターミナルで、StatefulSetのPodを監視します。 + +```shell +kubectl get pods -w -l app=nginx +``` + +2つ目のターミナルで、StatefulSetを再作成します。もし`nginx`Serviceを削除しなかった場合(この場合は削除するべきではありませんでした)、Serviceがすでに存在することを示すエラーが表示されます。 + +```shell +kubectl apply -f web.yaml +``` +``` +statefulset.apps/web created +service/nginx unchanged +``` + +このエラーは無視してください。このメッセージは、すでに存在する _nginx_ というheadless Serviceを作成しようと試みたということを示しているだけです。 + +1つ目のターミナルで、`kubectl get`コマンドの出力を確認します。 + +```shell +kubectl get pods -w -l app=nginx +``` +``` +NAME READY STATUS RESTARTS AGE +web-1 1/1 Running 0 16m +web-2 1/1 Running 0 2m +NAME READY STATUS RESTARTS AGE +web-0 0/1 Pending 0 0s +web-0 0/1 Pending 0 0s +web-0 0/1 ContainerCreating 0 0s +web-0 1/1 Running 0 18s +web-2 1/1 Terminating 0 3m +web-2 0/1 Terminating 0 3m +web-2 0/1 Terminating 0 3m +web-2 0/1 Terminating 0 3m +``` + + `web`StatefulSetが再作成されると、最初に`web-0`を再実行します。`web-1`はすでにRunningかつReadyの状態であるため、`web-0`がRunningかつReadyの状態に移行すると、StatefulSetは単純にこのPodを選びます。StatefulSetを`replicas`を2にして再作成したため、一度`web-0`が再作成されて、`web-1`がすでにRunningかつReadyの状態であることが判明したら、`web-2`は停止されます。 + +Podのウェブサーバーが配信している`index.html`ファイルのコンテンツをもう一度見てみましょう。 + +```shell +for i in 0 1; do kubectl exec -i -t "web-$i" -- curl http://localhost/; done +``` +``` +web-0 +web-1 +``` + +たとえStatefulSetと`web-0`Podの両方が削除されても、Podは最初に`index.html`ファイルに書き込んだホスト名をまだ配信しています。これは、StatefulSetがPodに紐付けられたPersistentVolumeを削除しないためです。StatefulSetを再作成して`web-0`を再実行すると、元のPersistentVolumeが再マウントされます。 + +### カスケードな削除 + +1つ目のターミナルで、StatefulSet内のPodを監視します。 + +```shell +kubectl get pods -w -l app=nginx +``` + +2つ目のターミナルで、StatefulSetをもう一度削除します。今回は、`--cascade=false`パラメーターを省略します。 + +```shell +kubectl delete statefulset web +``` +``` +statefulset.apps "web" deleted +``` + +1つ目のターミナルで実行している`kubectl get`コマンドの出力を確認し、すべてのPodがTerminatingの状態に変わるまで待ちます。 + +```shell +kubectl get pods -w -l app=nginx +``` +``` +NAME READY STATUS RESTARTS AGE +web-0 1/1 Running 0 11m +web-1 1/1 Running 0 27m +NAME READY STATUS RESTARTS AGE +web-0 1/1 Terminating 0 12m +web-1 1/1 Terminating 0 29m +web-0 0/1 Terminating 0 12m +web-0 0/1 Terminating 0 12m +web-0 0/1 Terminating 0 12m +web-1 0/1 Terminating 0 29m +web-1 0/1 Terminating 0 29m +web-1 0/1 Terminating 0 29m + +``` + +[スケールダウン](#scaling-down)のセクションで見たように、順序インデックスの逆順に従って、Podは一度に1つずつ終了します。StatefulSetコントローラーは、次のPodを終了する前に、前のPodが完全に終了するまで待ちます。 + +{{< note >}} +カスケードな削除ではStatefulSetがPodとともに削除されますが、StatefulSetと紐付けられたheadless Serviceは削除されません。そのため、`nginx`Serviceは手動で削除する必要があります。 +{{< /note >}} + + +```shell +kubectl delete service nginx +``` +``` +service "nginx" deleted +``` + +さらにもう一度、StatefulSetとheadless Serviceを再作成します。 + +```shell +kubectl apply -f web.yaml +``` +``` +service/nginx created +statefulset.apps/web created +``` + +StatefulSet上のすべてのPodがRunningかつReadyの状態に変わったら、Pod上の`index.html`ファイルのコンテンツを取得します。 + +```shell +for i in 0 1; do kubectl exec -i -t "web-$i" -- curl http://localhost/; done +``` +``` +web-0 +web-1 +``` + +StatefulSetを完全に削除して、すべてのPodが削除されたとしても、PersistentVolumeがマウントされたPodが再生成されて、`web-0`と`web-1`はホスト名の配信を続けます。 + +最後に、`web`StatefulSetを削除します。 + +```shell +kubectl delete service nginx +``` +``` +service "nginx" deleted +``` +そして、`nginx`Serviceも削除します。 +```shell +kubectl delete statefulset web +``` +``` +statefulset "web" deleted +``` + +## Pod管理ポリシー + +分散システムによっては、StatefulSetの順序の保証が不必要であったり望ましくない場合もあります。こうしたシステムでは、一意性と同一性だけが求められます。この問題に対処するために、Kubernetes 1.7でStatefulSet APIオブジェクトに`.spec.podManagementPolicy`が導入されました。 + +### OrderedReadyのPod管理 + +`OrderedReady`のPod管理はStatefulSetのデフォルトの設定です。StatefulSetコントローラーに対して、これまでに紹介したような順序の保証を尊重するように指示します。 + +### ParallelのPod管理 + +`Parallel`のPod管理では、StatefulSetコントローラーに対して、PodがRunningかつReadyの状態や完全に停止するまで待たないように指示し、すべてのPodを並列に起動または停止させるようにします。 + +{{< codenew file="application/web/web-parallel.yaml" >}} + +上の例をダウンロードして、`web-parallel.yaml`という名前でファイルに保存してください。 + +このマニフェストは、`.spec.podManagementPolicy`が`Parallel`に設定されている以外は、前にダウンロードした`web`StatefulSetと同一です。 + +1つ目のターミナルで、StatefulSet内のPodを監視します。 + +```shell +kubectl get pod -l app=nginx -w +``` + +2つ目のターミナルで、マニフェスト内のStatefulSetとServiceを作成します。 + +```shell +kubectl apply -f web-parallel.yaml +``` +``` +service/nginx created +statefulset.apps/web created +``` + +1つ目のターミナルで実行した`kubectl get`コマンドの出力を確認します。 + +```shell +kubectl get pod -l app=nginx -w +``` +``` +NAME READY STATUS RESTARTS AGE +web-0 0/1 Pending 0 0s +web-0 0/1 Pending 0 0s +web-1 0/1 Pending 0 0s +web-1 0/1 Pending 0 0s +web-0 0/1 ContainerCreating 0 0s +web-1 0/1 ContainerCreating 0 0s +web-0 1/1 Running 0 10s +web-1 1/1 Running 0 10s +``` + +StatefulSetコントローラーは`web-0`と`web-1`を同時に起動しています。 + +2つ目のターミナルで、StatefulSetをスケールしてみます。 + +```shell +kubectl scale statefulset/web --replicas=4 +``` +``` +statefulset.apps/web scaled +``` + +`kubectl get`コマンドを実行しているターミナルの出力を確認します。 + +``` +web-3 0/1 Pending 0 0s +web-3 0/1 Pending 0 0s +web-3 0/1 Pending 0 7s +web-3 0/1 ContainerCreating 0 7s +web-2 1/1 Running 0 10s +web-3 1/1 Running 0 26s +``` + +StatefulSetが2つのPodを実行し、1つ目のPodがRunningかつReadyの状態になるのを待たずに2つ目のPodを実行しているのがわかります。 + +## {{% heading "cleanup" %}} + +2つのターミナルが開かれているはずなので、クリーンアップの一部として`kubectl`コマンドを実行する準備ができています。 + +```shell +kubectl delete sts web +# stsは、statefulsetの略です。 +``` + +`kubectl get`を監視すると、Podが削除されていく様子を確認できます。 + +```shell +kubectl get pod -l app=nginx -w +``` +``` +web-3 1/1 Terminating 0 9m +web-2 1/1 Terminating 0 9m +web-3 1/1 Terminating 0 9m +web-2 1/1 Terminating 0 9m +web-1 1/1 Terminating 0 44m +web-0 1/1 Terminating 0 44m +web-0 0/1 Terminating 0 44m +web-3 0/1 Terminating 0 9m +web-2 0/1 Terminating 0 9m +web-1 0/1 Terminating 0 44m +web-0 0/1 Terminating 0 44m +web-2 0/1 Terminating 0 9m +web-2 0/1 Terminating 0 9m +web-2 0/1 Terminating 0 9m +web-1 0/1 Terminating 0 44m +web-1 0/1 Terminating 0 44m +web-1 0/1 Terminating 0 44m +web-0 0/1 Terminating 0 44m +web-0 0/1 Terminating 0 44m +web-0 0/1 Terminating 0 44m +web-3 0/1 Terminating 0 9m +web-3 0/1 Terminating 0 9m +web-3 0/1 Terminating 0 9m +``` + +削除の間、StatefulSetはすべてのPodを並列に削除し、順序インデックスが1つ前のPodが停止するのを待つことはありません。 + +`kubectl get`コマンドを実行しているターミナルを閉じて、`nginx`Serviceを削除します。 + +```shell +kubectl delete svc nginx +``` + +{{< note >}} +このチュートリアルで使用したPersistentVolumeのための永続ストレージも削除する必要があります。 + +すべてのストレージが再利用できるようにするために、環境、ストレージの設定、プロビジョニング方法に基づいて必要な手順に従ってください。 +{{< /note >}} 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 new file mode 100644 index 0000000000..7aed33777e --- /dev/null +++ b/content/ja/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md @@ -0,0 +1,241 @@ +--- +title: "例: Persistent Volumeを使用したWordpressとMySQLをデプロイする" +content_type: tutorial +weight: 20 +card: + name: tutorials + weight: 40 + title: "ステートフルの例: Persistent Volumeを使用したWordpress" +--- + + +このチュートリアルでは、WordPressのサイトとMySQLデータベースをMinikubeを使ってデプロイする方法を紹介します。2つのアプリケーションとも、データを保存するためにPersistentVolumeとPersistentVolumeClaimを使用します。 + +[PersistentVolume](/ja/docs/concepts/storage/persistent-volumes/)(PV)とは、管理者が手動でプロビジョニングを行うか、[StorageClass](/docs/concepts/storage/storage-classes)を使ってKubernetesによって動的にプロビジョニングされた、クラスター内のストレージの一部です。[PersistentVolumeClaim](/ja/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)(PVC)は、PVによって満たすことができる、ユーザーによるストレージへのリクエストのことです。PersistentVolumeとPersistentVolumeClaimは、Podのライフサイクルからは独立していて、Podの再起動、Podの再スケジューリング、さらにはPodの削除が行われたとしても、その中のデータは削除されずに残ります。 + +{{< warning >}} +シングルインスタンスのWordPressとMySQLのPodを使用しているため、ここで行うデプロイは本番のユースケースには適しません。WordPressを本番環境にデプロイするときは、[WordPress Helm Chart](https://github.com/kubernetes/charts/tree/master/stable/wordpress)を使用することを検討してください。 +{{< /warning >}} + +{{< note >}} +このチュートリアルで提供されるファイルは、GAとなっているDeployment APIを使用しているため、Kubernetesバージョン1.9以降のためのものになっています。もしこのチュートリアルを古いバージョンのKubernetesで使いたい場合は、APIのバージョンを適切にアップデートするか、このチュートリアルの古いバージョンを参照してください。 +{{< /note >}} + + + +## {{% heading "objectives" %}} + +* PersistentVolumeClaimとPersistentVolumeを作成する +* 以下を含む`kustomization.yaml`を作成する + * Secret generator + * MySQLリソースの設定 + * WordPressリソースの設定 +* kustomizationディレクトリを`kubectl apply -k ./`で適用する +* クリーンアップする + + + +## {{% heading "prerequisites" %}} + + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} +このページで示された例は、`kubectl` 1.14以降で動作します。 + +以下の設定ファイルをダウンロードします。 + +1. [mysql-deployment.yaml](/examples/application/wordpress/mysql-deployment.yaml) + +1. [wordpress-deployment.yaml](/examples/application/wordpress/wordpress-deployment.yaml) + + + + + +## PersistentVolumeClaimとPersistentVolumeを作成する + +MySQLとWordpressはそれぞれ、データを保存するためのPersistentVolumeを必要とします。各PersistentVolumeClaimはデプロイの段階で作成されます。 + +多くのクラスタ環境では、デフォルトのStorageClassがインストールされています。StorageClassがPersistentVolumeClaim中で指定されていなかった場合、クラスターのデフォルトのStorageClassが代わりに使われます。 + +PersistentVolumeClaimが作成されるとき、StorageClassの設定に基づいてPersistentVolumeが動的にプロビジョニングされます。 + +{{< warning >}} +ローカルのクラスターでは、デフォルトのStorageClassには`hostPath`プロビジョナーが使われます。`hostPath`ボリュームは開発およびテストにのみ適しています。`hostPath`ボリュームでは、データはPodがスケジュールされたノード上の`/tmp`内に保存されます。そのため、もしPodが死んだり、クラスター上の他のノードにスケジュールされたり、ノードが再起動すると、データは失われます。 +{{< /warning >}} + +{{< note >}} +`hostPath`プロビジョナーを使用する必要があるクラスターを立ち上げたい場合は、`--enable-hostpath-provisioner`フラグを `controller-manager` コンポーネントで設定する必要があります。 +{{< /note >}} + +{{< note >}} +Google Kubernetes Engine上で動作するKubernetesクラスターを使っている場合は、[このガイド](https://cloud.google.com/kubernetes-engine/docs/tutorials/persistent-disk?hl=ja)に従ってください。 +{{< /note >}} + +## kustomization.yamlを作成する + +### Secret generatorを追加する + +[Secret](/docs/concepts/configuration/secret/)とは、パスワードやキーのような機密性の高いデータ片を保存するためのオブジェクトです。バージョン1.14からは、`kubectl`がkustomizationファイルを使用したKubernetesオブジェクトの管理をサポートしています。`kustomization.yaml`内のgeneratorによってSecretを作成することができます。 + +以下のコマンドを実行して、`kustomization.yaml`の中にSecret generatorを追加します。`YOUR_PASSWORD`の部分を使いたいパスワードに置換してください。 + +```shell +cat <./kustomization.yaml +secretGenerator: +- name: mysql-pass + literals: + - password=YOUR_PASSWORD +EOF +``` + +## MySQLとWordPressのためのリソースの設定を追加する + +以下のマニフェストには、シングルインスタンスのMySQLのDeploymentが書かれています。MySQLコンテナはPersistentVolumeを`/var/lib/mysql`にマウントします。`MYSQL_ROOT_PASSWORD`環境変数には、Secretから得られたデータベースのパスワードが設定されます。 + +{{< codenew file="application/wordpress/mysql-deployment.yaml" >}} + +以下のマニフェストには、シングルインスタンスのWordPressのDeploymentが書かれています。WordPressコンテナはPersistentVolumeをウェブサイトのデータファイルのために`/var/www/html`にマウントします。`WORDPRESS_DB_HOST`環境変数に上で定義したMySQLのServiceの名前を設定すると、WordPressはServiceによってデータベースにアクセスします。`WORDPRESS_DB_PASSWORD`環境変数には、kustomizeが生成したSecretから得たデータベースのパスワードが設定されます。 + + +{{< codenew file="application/wordpress/wordpress-deployment.yaml" >}} + +1. MySQLのDeploymentの設定ファイルをダウンロードします。 + + ```shell + curl -LO https://k8s.io/examples/application/wordpress/mysql-deployment.yaml + ``` + +2. WordPressの設定ファイルをダウンロードします。 + + ```shell + curl -LO https://k8s.io/examples/application/wordpress/wordpress-deployment.yaml + ``` + +3. これらを`kustomization.yaml`ファイルに追加します。 + +```shell +cat <>./kustomization.yaml +resources: + - mysql-deployment.yaml + - wordpress-deployment.yaml +EOF +``` + +## 適用と確認 + +`kustomization.yaml`には、WordPressのサイトとMySQLデータベースのためのすべてのリソースが含まれています。次のコマンドでこのディレクトリを適用できます。 + +```shell +kubectl apply -k ./ +``` + +これで、すべてのオブジェクトが存在していることを確認できます。 + +1. 次のコマンドを実行して、Secretが存在していることを確認します。 + + ```shell + kubectl get secrets + ``` + + 結果は次のようになるはずです。 + + ```shell + NAME TYPE DATA AGE + mysql-pass-c57bb4t7mf Opaque 1 9s + ``` + +1. 次のコマンドを実行して、PersistentVolumeが動的にプロビジョニングされていることを確認します。 + + ```shell + kubectl get pvc + ``` + + {{< note >}} + PVがプロビジョニングされてバインドされるまでに、最大で数分かかる場合があります。 + {{< /note >}} + + 結果は次のようになるはずです。 + + ```shell + NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE + mysql-pv-claim Bound pvc-8cbd7b2e-4044-11e9-b2bb-42010a800002 20Gi RWO standard 77s + wp-pv-claim Bound pvc-8cd0df54-4044-11e9-b2bb-42010a800002 20Gi RWO standard 77s + ``` + +3. 次のコマンドを実行して、Podが実行中であることを確認します。 + + ```shell + kubectl get pods + ``` + + {{< note >}} + PodのStatusが`Running`の状態になる前に、最大で数分かかる場合があります。 + {{< /note >}} + + 結果は次のようになるはずです。 + + ``` + NAME READY STATUS RESTARTS AGE + wordpress-mysql-1894417608-x5dzt 1/1 Running 0 40s + ``` + +4. 次のコマンドを実行して、Serviceが実行中であることを確認します。 + + ```shell + kubectl get services wordpress + ``` + + 結果は次のようになるはずです。 + + ``` + NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE + wordpress ClusterIP 10.0.0.89 80:32406/TCP 4m + ``` + + {{< note >}} + MinikubeではServiceを`NodePort`経由でしか公開できません。EXTERNAL-IPは常にpendingのままになります。 + {{< /note >}} + +5. 次のコマンドを実行して、WordPress ServiceのIPアドレスを取得します。 + + ```shell + minikube service wordpress --url + ``` + + 結果は次のようになるはずです。 + + ``` + http://1.2.3.4:32406 + ``` + +6. IPアドレスをコピーして、ブラウザーで読み込み、サイトを表示しましょう。 + + WordPressによりセットアップされた次のスクリーンショットのようなページが表示されるはずです。 + + ![wordpress-init](https://raw.githubusercontent.com/kubernetes/examples/master/mysql-wordpress-pd/WordPress.png) + +{{< warning >}} +WordPressのインストールをこのページのまま放置してはいけません。もしほかのユーザーがこのページを見つけた場合、その人はインスタンス上にウェブサイトをセットアップして、悪意のあるコンテンツの配信に利用できてしまいます。

ユーザー名とパスワードを決めてWordPressをインストールするか、このインスタンスを削除してください。 +{{< /warning >}} + + + +## {{% heading "cleanup" %}} + + +1. 次のコマンドを実行して、Secret、Deployment、Service、およびPersistentVolumeClaimを削除します。 + + ```shell + kubectl delete -k ./ + ``` + + + +## {{% heading "whatsnext" %}} + + +* [イントロスペクションとデバッグ](/docs/tasks/debug-application-cluster/debug-application-introspection/)についてさらに学ぶ +* [Job](/docs/concepts/workloads/controllers/job/)についてさらに学ぶ +* [Portフォワーディング](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)についてさらに学ぶ +* [コンテナへのシェルを取得する](/ja/docs/tasks/debug-application-cluster/get-shell-running-container/)方法について学ぶ + diff --git a/content/ja/docs/tutorials/stateless-application/guestbook.md b/content/ja/docs/tutorials/stateless-application/guestbook.md new file mode 100644 index 0000000000..e08abdb62c --- /dev/null +++ b/content/ja/docs/tutorials/stateless-application/guestbook.md @@ -0,0 +1,370 @@ +--- +title: "例: Redisを使用したPHPのゲストブックアプリケーションのデプロイ" +content_type: tutorial +weight: 20 +card: + name: tutorials + weight: 30 + title: "ステートレスの例: Redisを使用したPHPのゲストブック" +--- + + +このチュートリアルでは、Kubernetesと[Docker](https://www.docker.com/)を使用した、シンプルなマルチティアのウェブアプリケーションのビルドとデプロイの方法を紹介します。この例は、以下のコンポーネントから構成されています。 + +* ゲストブックのエントリーを保存するための、シングルインスタンスの[Redis](https://redis.io/)マスター +* 読み込みデータ配信用の、複数の[レプリケーションされたRedis](https://redis.io/topics/replication)インスタンス +* 複数のウェブフロントエンドのインスタンス + + + +## {{% heading "objectives" %}} + +* Redisのマスターを起動する。 +* Redisのスレーブを起動する。 +* ゲストブックのフロントエンドを起動する。 +* フロントエンドのServiceを公開して表示を確認する。 +* クリーンアップする。 + + +## {{% heading "prerequisites" %}} + + +{{< include "task-tutorial-prereqs.md" >}} + +{{< version-check >}} + + + + + +## Redisのマスターを起動する + +ゲストブックアプリケーションでは、データを保存するためにRedisを使用します。ゲストブックはRedisのマスターインスタンスにデータを書き込み、複数のRedisのスレーブインスタンスからデータを読み込みます。 + +### RedisのマスターのDeploymentを作成する + +以下のマニフェストファイルは、シングルレプリカのRedisのマスターPodを実行するDeploymentコントローラーを指定しています。 + +{{< codenew file="application/guestbook/redis-master-deployment.yaml" >}} + +1. マニフェストファイルをダウンロードしたディレクトリ内で、ターミナルウィンドウを起動します。 +1. `redis-master-deployment.yaml`ファイルから、RedisのマスターのDeploymentを適用します。 + + ```shell + kubectl apply -f https://k8s.io/examples/application/guestbook/redis-master-deployment.yaml + ``` + +1. Podのリストを問い合わせて、RedisのマスターのPodが実行中になっていることを確認します。 + + ```shell + kubectl get pods + ``` + + 結果は次のようになるはずです。 + + ```shell + NAME READY STATUS RESTARTS AGE + redis-master-1068406935-3lswp 1/1 Running 0 28s + ``` + +1. 次のコマンドを実行して、RedisのマスターのPodからログを表示します。 + + ```shell + kubectl logs -f POD-NAME + ``` + +{{< note >}} +POD-NAMEの部分を実際のPodの名前に書き換えてください。 +{{< /note >}} + +### RedisのマスターのServiceを作成する + +ゲストブックアプリケーションは、データを書き込むためにRedisのマスターと通信する必要があります。そのためには、[Service](/docs/concepts/services-networking/service/)を適用して、トラフィックをRedisのマスターのPodへプロキシーしなければなりません。Serviceは、Podにアクセスするためのポリシーを指定します。 + +{{< codenew file="application/guestbook/redis-master-service.yaml" >}} + +1. 次の`redis-master-service.yaml`から、RedisのマスターのServiceを適用します。 + + ```shell + kubectl apply -f https://k8s.io/examples/application/guestbook/redis-master-service.yaml + ``` + +1. Serviceのリストを問い合わせて、RedisのマスターのServiceが実行中になっていることを確認します。 + + ```shell + kubectl get service + ``` + + The response should be similar to this: + + ```shell + NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE + kubernetes ClusterIP 10.0.0.1 443/TCP 1m + redis-master ClusterIP 10.0.0.151 6379/TCP 8s + ``` + +{{< note >}} +このマニフェストファイルは、`redis-master`という名前のServiceを、前に定義したラベルにマッチする一連のラベル付きで作成します。これにより、ServiceはネットワークトラフィックをRedisのマスターのPodへとルーティングできるようになります。 +{{< /note >}} + + +## Redisのスレーブを起動する + +Redisのマスターは1つのPodですが、レプリカのRedisのスレーブを追加することで、トラフィックの需要を満たすための高い可用性を持たせることができます。 + +### RedisのスレーブのDeploymentを作成する + +Deploymentはマニフェストファイル内に書かれた設定に基づいてスケールします。ここでは、Deploymentオブジェクトは2つのレプリカを指定しています。 + +もし1つもレプリカが実行されていなければ、このDeploymentは2つのレプリカをコンテナクラスター上で起動します。逆に、もしすでに2つ以上のレプリカが実行されていれば、実行中のレプリカが2つになるようにスケールダウンします。 + +{{< codenew file="application/guestbook/redis-slave-deployment.yaml" >}} + +1. `redis-slave-deployment.yaml`ファイルから、RedisのスレーブのDeploymentを適用します。 + + ```shell + kubectl apply -f https://k8s.io/examples/application/guestbook/redis-slave-deployment.yaml + ``` + +1. Podのリストを問い合わせて、RedisのスレーブのPodが実行中になっていることを確認します。 + + ```shell + kubectl get pods + ``` + + 結果は次のようになるはずです。 + + ```shell + NAME READY STATUS RESTARTS AGE + redis-master-1068406935-3lswp 1/1 Running 0 1m + redis-slave-2005841000-fpvqc 0/1 ContainerCreating 0 6s + redis-slave-2005841000-phfv9 0/1 ContainerCreating 0 6s + ``` + +### RedisのスレーブのServiceを作成する + +ゲストブックアプリケーションは、データを読み込むためにRedisのスレーブと通信する必要があります。Redisのスレーブが発見できるようにするためには、Serviceをセットアップする必要があります。Serviceは一連のPodに対する透過的なロードバランシングを提供します。 + +{{< codenew file="application/guestbook/redis-slave-service.yaml" >}} + +1. 次の`redis-slave-service.yaml`ファイルから、RedisのスレーブのServiceを適用します。 + + ```shell + kubectl apply -f https://k8s.io/examples/application/guestbook/redis-slave-service.yaml + ``` + +1. Serviceのリストを問い合わせて、RedisのスレーブのServiceが実行中になっていることを確認します。 + + ```shell + kubectl get services + ``` + + 結果は次のようになるはずです。 + + ``` + NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE + kubernetes ClusterIP 10.0.0.1 443/TCP 2m + redis-master ClusterIP 10.0.0.151 6379/TCP 1m + redis-slave ClusterIP 10.0.0.223 6379/TCP 6s + ``` + +## ゲストブックのフロントエンドをセットアップして公開する + +ゲストブックアプリケーションには、HTTPリクエストをサーブするPHPで書かれたウェブフロントエンドがあります。このアプリケーションは、書き込みリクエストに対しては`redis-master` Serviceに、読み込みリクエストに対しては`redis-slave` Serviceに接続するように設定されています。 + +### ゲストブックのフロントエンドのDeploymentを作成する + +{{< codenew file="application/guestbook/frontend-deployment.yaml" >}} + +1. `frontend-deployment.yaml`ファイルから、フロントエンドのDeploymentを適用します。 + + ```shell + kubectl apply -f https://k8s.io/examples/application/guestbook/frontend-deployment.yaml + ``` + +1. Podのリストを問い合わせて、3つのフロントエンドのレプリカが実行中になっていることを確認します。 + + ```shell + kubectl get pods -l app=guestbook -l tier=frontend + ``` + + 結果は次のようになるはずです。 + + ``` + NAME READY STATUS RESTARTS AGE + frontend-3823415956-dsvc5 1/1 Running 0 54s + frontend-3823415956-k22zn 1/1 Running 0 54s + frontend-3823415956-w9gbt 1/1 Running 0 54s + ``` + +### フロントエンドのServiceを作成する + +適用した`redis-slave`および`redis-master` Serviceは、コンテナクラスター内部からのみアクセス可能です。これは、デフォルトのServiceのtypeが[ClusterIP](/docs/concepts/services-networking/service/#publishing-services---service-types)であるためです。`ClusterIP`は、Serviceが指している一連のPodに対して1つのIPアドレスを提供します。このIPアドレスはクラスター内部からのみアクセスできます。 + +もしゲストの人にゲストブックにアクセスしてほしいのなら、フロントエンドServiceを外部から見えるように設定しなければなりません。そうすれば、クライアントはコンテナクラスターの外部からServiceにリクエストを送れるようになります。Minikubeでは、Serviceを`NodePort`でのみ公開できます。 + +{{< note >}} +一部のクラウドプロバイダーでは、Google Compute EngineやGoogle Kubernetes Engineなど、外部のロードバランサーをサポートしているものがあります。もしクラウドプロバイダーがロードバランサーをサポートしていて、それを使用したい場合は、`type: NodePort`という行を単に削除またはコメントアウトして、`type: LoadBalancer`のコメントアウトを外せば使用できます。 +{{< /note >}} + +{{< codenew file="application/guestbook/frontend-service.yaml" >}} + +1. `frontend-service.yaml`ファイルから、フロントエンドのServiceを提供します。 + + ```shell + kubectl apply -f https://k8s.io/examples/application/guestbook/frontend-service.yaml + ``` + +1. Serviceのリストを問い合わせて、フロントエンドのServiceが実行中であることを確認します。 + + ```shell + kubectl get services + ``` + + 結果は次のようになるはずです。 + + ``` + NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE + frontend NodePort 10.0.0.112 80:31323/TCP 6s + kubernetes ClusterIP 10.0.0.1 443/TCP 4m + redis-master ClusterIP 10.0.0.151 6379/TCP 2m + redis-slave ClusterIP 10.0.0.223 6379/TCP 1m + ``` + +### フロントエンドのServiceを`NodePort`経由で表示する + +このアプリケーションをMinikubeやローカルのクラスターにデプロイした場合、ゲストブックを表示するためのIPアドレスを見つける必要があります。 + +1. 次のコマンドを実行すると、フロントエンドServiceに対するIPアドレスを取得できます。 + + ```shell + minikube service frontend --url + ``` + + 結果は次のようになるはずです。 + + ``` + http://192.168.99.100:31323 + ``` + +1. IPアドレスをコピーして、ブラウザー上でページを読み込み、ゲストブックを表示しましょう。 + +### フロントエンドのServiceを`LoadBalancer`経由で表示する + +もし`frontend-service.yaml`マニフェストを`type: LoadBalancer`でデプロイした場合、ゲストブックを表示するためのIPアドレスを見つける必要があります。 + +1. 次のコマンドを実行すると、フロントエンドServiceに対するIPアドレスを取得できます。 + + ```shell + kubectl get service frontend + ``` + + 結果は次のようになるはずです。 + + ``` + NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE + frontend ClusterIP 10.51.242.136 109.197.92.229 80:32372/TCP 1m + ``` + +1. 外部IPアドレス(EXTERNAL-IP)をコピーして、ブラウザー上でページを読み込み、ゲストブックを表示しましょう。 + +## ウェブフロントエンドをスケールする + +サーバーがDeploymentコントローラーを使用するServiceとして定義されているため、スケールアップやスケールダウンは簡単です。 + +1. 次のコマンドを実行すると、フロントエンドのPodの数をスケールアップできます。 + + ```shell + kubectl scale deployment frontend --replicas=5 + ``` + +1. Podのリストを問い合わせて、実行中のフロントエンドのPodの数を確認します。 + + ```shell + kubectl get pods + ``` + + 結果は次のようになるはずです。 + + ``` + NAME READY STATUS RESTARTS AGE + frontend-3823415956-70qj5 1/1 Running 0 5s + frontend-3823415956-dsvc5 1/1 Running 0 54m + frontend-3823415956-k22zn 1/1 Running 0 54m + frontend-3823415956-w9gbt 1/1 Running 0 54m + frontend-3823415956-x2pld 1/1 Running 0 5s + redis-master-1068406935-3lswp 1/1 Running 0 56m + redis-slave-2005841000-fpvqc 1/1 Running 0 55m + redis-slave-2005841000-phfv9 1/1 Running 0 55m + ``` + +1. 次のコマンドを実行すると、フロントエンドのPodの数をスケールダウンできます。 + + ```shell + kubectl scale deployment frontend --replicas=2 + ``` + +1. Podのリストを問い合わせて、実行中のフロントエンドのPodの数を確認します。 + + ```shell + kubectl get pods + ``` + + 結果は次のようになるはずです。 + + ``` + NAME READY STATUS RESTARTS AGE + frontend-3823415956-k22zn 1/1 Running 0 1h + frontend-3823415956-w9gbt 1/1 Running 0 1h + redis-master-1068406935-3lswp 1/1 Running 0 1h + redis-slave-2005841000-fpvqc 1/1 Running 0 1h + redis-slave-2005841000-phfv9 1/1 Running 0 1h + ``` + + + +## {{% heading "cleanup" %}} + +DeploymentとServiceを削除すると、実行中のPodも削除されます。ラベルを使用すると、複数のリソースを1つのコマンドで削除できます。 + +1. 次のコマンドを実行すると、すべてのPod、Deployment、Serviceが削除されます。 + + ```shell + kubectl delete deployment -l app=redis + kubectl delete service -l app=redis + kubectl delete deployment -l app=guestbook + kubectl delete service -l app=guestbook + ``` + + 結果は次のようになるはずです。 + + ``` + deployment.apps "redis-master" deleted + deployment.apps "redis-slave" deleted + service "redis-master" deleted + service "redis-slave" deleted + deployment.apps "frontend" deleted + service "frontend" deleted + ``` + +1. Podのリストを問い合わせて、実行中のPodが存在しないことを確認します。 + + ```shell + kubectl get pods + ``` + + 結果は次のようになるはずです。 + + ``` + No resources found. + ``` + + + +## {{% heading "whatsnext" %}} + +* ゲストブックアプリケーションに対する[ELKによるロギングとモニタリング](/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk/) +* [Kubernetesの基本](/ja/docs/tutorials/kubernetes-basics/)のインタラクティブチュートリアルを終わらせる +* Kubernetesを使って、[MySQLとWordpressのためにPersistent Volume](/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/#visit-your-new-wordpress-blog)を使用したブログを作成する +* [サービスとアプリケーションの接続](/ja/docs/concepts/services-networking/connect-applications-service/)についてもっと読む +* [リソースの管理](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively)についてもっと読む diff --git a/content/ja/examples/pods/pod-nginx-specific-node.yaml b/content/ja/examples/pods/pod-nginx-specific-node.yaml new file mode 100644 index 0000000000..401814df92 --- /dev/null +++ b/content/ja/examples/pods/pod-nginx-specific-node.yaml @@ -0,0 +1,10 @@ +apiVersion: v1 +kind: Pod +metadata: + name: nginx +spec: + nodeName: foo-node # 特定のノードにPodをスケジューリングする + containers: + - name: nginx + image: nginx + imagePullPolicy: IfNotPresent diff --git a/content/ja/examples/pods/pod-with-toleration.yaml b/content/ja/examples/pods/pod-with-toleration.yaml new file mode 100644 index 0000000000..79f2756a8c --- /dev/null +++ b/content/ja/examples/pods/pod-with-toleration.yaml @@ -0,0 +1,15 @@ +apiVersion: v1 +kind: Pod +metadata: + name: nginx + labels: + env: test +spec: + containers: + - name: nginx + image: nginx + imagePullPolicy: IfNotPresent + tolerations: + - key: "example-key" + operator: "Exists" + effect: "NoSchedule" diff --git a/content/ja/training/_index.html b/content/ja/training/_index.html index 8c92ea7f22..6762f56dec 100644 --- a/content/ja/training/_index.html +++ b/content/ja/training/_index.html @@ -1,7 +1,7 @@ --- title: トレーニング bigheader: Kubernetesのトレーニングと資格 -abstract: トレーニングプログラム、資格、及びパートナーについて。 +abstract: トレーニングプログラム、資格、およびパートナーについて。 layout: basic cid: training class: training @@ -18,7 +18,7 @@ class: training

あなたのクラウドネイティブなキャリアを創る

-

Kubernetesはクラウドネイティブムーブメントの中核を担っています。Linux Foundation及びトレーニングパートナーのトレーニングを受け、認定資格を取得することで、キャリアに投資し、Kubernetesを学び、クラウドネイティブプロジェクトを成功に繋げます。

+

Kubernetesはクラウドネイティブムーブメントの中核を担っています。Linux Foundationおよびトレーニングパートナーのトレーニングを受け、認定資格を取得することで、キャリアに投資し、Kubernetesを学び、クラウドネイティブプロジェクトを成功に繋げます。