Merge upstream work for release-1.19
This commit is contained in:
inductor
@@ -0,0 +1,18 @@
|
||||
---
|
||||
title: クラウドコントローラーマネージャー
|
||||
id: cloud-controller-manager
|
||||
date: 2018-04-12
|
||||
full_link: /ja/docs/concepts/architecture/cloud-controller/
|
||||
short_description: >
|
||||
サードパーティクラウドプロバイダーにKubernetewを結合するコントロールプレーンコンポーネント
|
||||
aka:
|
||||
tags:
|
||||
- core-object
|
||||
- architecture
|
||||
- operation
|
||||
---
|
||||
クラウド特有の制御ロジックを組み込むKubernetesの{{< glossary_tooltip text="control plane" term_id="control-plane" >}}コンポーネントです。クラウドコントロールマネージャーは、クラスターをクラウドプロバイダーAPIをリンクし、クラスタのみで相互作用するコンポーネントからクラウドプラットフォームで相互作用するコンポーネントを分離します。
|
||||
|
||||
<!--more-->
|
||||
|
||||
Kubernetesと下のクラウドインフラストラクチャー間の相互運用ロジックを分離することで、cloud-controller-managerコンポーネントはクラウドプロバイダを主なKubernetesプロジェクトと比較し異なるペースで機能をリリース可能にします。
|
||||
@@ -11,3 +11,15 @@ tags:
|
||||
- fundamental
|
||||
---
|
||||
コンテナのライフサイクルを定義、展開、管理するためのAPIとインターフェイスを公開するコンテナオーケストレーションレイヤーです。
|
||||
|
||||
<!--more-->
|
||||
|
||||
このレイヤーは、次のような多くの異なるコンポーネントから構成されます(しかし、これらに限定はされません)。
|
||||
|
||||
* {{< glossary_tooltip text="etcd" term_id="etcd" >}}
|
||||
* {{< glossary_tooltip text="APIサーバー" term_id="kube-apiserver" >}}
|
||||
* {{< glossary_tooltip text="スケジューラー" term_id="kube-scheduler" >}}
|
||||
* {{< glossary_tooltip text="コントローラーマネージャー" term_id="kube-controller-manager" >}}
|
||||
* {{< glossary_tooltip text="クラウドコントローラーマネージャー" term_id="cloud-controller-manager" >}}
|
||||
|
||||
これらのコンポーネントは従来のオペレーティングシステムサービス(デーモン)もしくはコンテナとして実行できます。これらのコンポーネントを実行するホストは歴史的に{{< glossary_tooltip text="マスター" term_id="master" >}}と呼ばれていました。
|
||||
|
||||
@@ -4,7 +4,7 @@ id: deployment
|
||||
date: 2018-04-12
|
||||
full_link: /ja/docs/concepts/workloads/controllers/deployment/
|
||||
short_description: >
|
||||
複製されたアプリケーションを管理するAPIオブジェクトです。
|
||||
クラスター上の複製されたアプリケーションを管理します。
|
||||
|
||||
aka:
|
||||
tags:
|
||||
@@ -12,8 +12,9 @@ tags:
|
||||
- core-object
|
||||
- workload
|
||||
---
|
||||
複製されたアプリケーションを管理するAPIオブジェクトです。
|
||||
複製されたアプリケーションを管理するAPIオブジェクトで、通常はステートレスなPodを実行します。
|
||||
|
||||
<!--more-->
|
||||
|
||||
各レプリカは{{< glossary_tooltip term_id="pod" >}}で表され、ポッドはクラスターのノード間で分散されます。
|
||||
各レプリカは{{< glossary_tooltip text="Pod" term_id="pod" >}}で表され、Podはクラスターの{{< glossary_tooltip text="ノード" term_id="node" >}}間で分散されます。
|
||||
ローカル状態を要求するワークロードには、{{< glossary_tooltip term_id="StatefulSet" >}}の利用を考えてください。
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
title: APIサーバー
|
||||
id: kube-apiserver
|
||||
date: 2018-04-12
|
||||
full_link: /docs/reference/generated/kube-apiserver/
|
||||
full_link: /docs/concepts/overview/components/#kube-apiserver
|
||||
short_description: >
|
||||
Kubernetes APIを提供するコントロールプレーンのコンポーネントです。
|
||||
|
||||
|
||||
@@ -15,3 +15,4 @@ tags:
|
||||
<!--more-->
|
||||
|
||||
ワーカーノードは、クラスターに応じてVMまたは物理マシンの場合があります。{{< glossary_tooltip text="Pod" term_id="pod" >}}の実行に必要なローカルデーモンまたはサービスがあり、コントロールプレーンによって管理されます。ノード上のデーモンには、{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}、{{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}、および{{< glossary_tooltip term_id="docker" >}}などの{{< glossary_tooltip text="CRI" term_id="cri" >}}を実装するコンテナランタイムが含まれます。
|
||||
Kubernetesの初期バージョンでは、ノードは"Minion"と呼ばれていました。
|
||||
|
||||
@@ -14,4 +14,4 @@ tags:
|
||||
|
||||
<!--more-->
|
||||
|
||||
プラットフォーム開発者は、特に自身のアプリケーションのために、例えば[カスタムリソース](/docs/concepts/api-extension/custom-resources/)や[集約レイヤーを使ったKubernetes APIの拡張](/docs/concepts/api-extension/apiserver-aggregation/)を用いて、Kubernetesに機能を追加ことがあるかもしれません。一部のプラットフォーム開発者はまた{{< glossary_tooltip text="コントリビューター" term_id="contributor" >}}として、エクステンションを開発しKubernetesのコミュニティに貢献しています。他の方々は、クローズドソースな商用もしくは、サイト固有なエクステンションを開発しています。
|
||||
プラットフォーム開発者は、特に自身のアプリケーションのために、例えば[カスタムリソース](/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources/)や[集約レイヤーを使ったKubernetes APIの拡張](/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)を用いて、Kubernetesに機能を追加ことがあるかもしれません。一部のプラットフォーム開発者はまた{{< glossary_tooltip text="コントリビューター" term_id="contributor" >}}として、エクステンションを開発しKubernetesのコミュニティに貢献しています。他の方々は、クローズドソースな商用もしくは、サイト固有なエクステンションを開発しています。
|
||||
|
||||
@@ -4,7 +4,7 @@ id: statefulset
|
||||
date: 2018-04-12
|
||||
full_link: /ja/docs/concepts/workloads/controllers/statefulset/
|
||||
short_description: >
|
||||
StatefulSetはDeploymentとPodのセットのスケーリングを管理し、それらのPodの *順序と一意性を保証* します。
|
||||
StatefulSetはDeploymentとPodのセットのスケーリングを管理し、永続化ストレージと各Podの永続的な識別子を備えています。
|
||||
|
||||
aka:
|
||||
tags:
|
||||
@@ -20,5 +20,4 @@ StatefulSetはDeploymentと{{< glossary_tooltip text="Pod" term_id="pod" >}}の
|
||||
|
||||
{{< glossary_tooltip term_id="deployment" >}}のように、StatefulSetは指定したコンテナのspecに基づいてPodを管理します。Deploymentとは異なり、StatefulSetは各Podにおいて管理が大変な同一性を維持します。これらのPodは同一のspecから作成されますが、それらは交換可能ではなく、リスケジュール処理をまたいで維持される永続的な識別子を持ちます。
|
||||
|
||||
StatefulSetは他のコントローラーと同様のパターンで動作します。ユーザーはStatefulSet*オブジェクト* の理想的な状態を定義し、StatefulSet*コントローラー* は現在の状態から、理想状態になるために必要なアップデートを行います。
|
||||
|
||||
ワークロードに永続性を持たせるためにストレージボリュームを使いたい場合は、解決策の1つとしてStatefulSetが利用できます。StatefulSet内の個々のPodは障害の影響を受けやすいですが、永続化したPodの識別子は既存のボリュームと障害によって置換された新しいPodの紐付けを簡単にします。
|
||||
|
||||
@@ -4,17 +4,17 @@ id: volume
|
||||
date: 2018-04-12
|
||||
full_link: /docs/concepts/storage/volumes/
|
||||
short_description: >
|
||||
Pod内のコンテナからアクセス可能なデータを含むディレクトリです。
|
||||
データを格納するディレクトリで、Pod内のコンテナからアクセス可能です。
|
||||
|
||||
aka:
|
||||
aka:
|
||||
tags:
|
||||
- core-object
|
||||
- fundamental
|
||||
---
|
||||
{{< glossary_tooltip text="Pod" term_id="pod" >}}内の{{< glossary_tooltip text="コンテナ" term_id="container" >}}からアクセス可能なデータを含むディレクトリです。
|
||||
データを格納するディレクトリで、{{< glossary_tooltip text="Pod" term_id="pod" >}}内の{{< glossary_tooltip text="コンテナ" term_id="container" >}}からアクセス可能です。
|
||||
|
||||
<!--more-->
|
||||
<!--more-->
|
||||
|
||||
Kubernetesボリュームはボリュームを含むPodが存在する限り有効です。そのためボリュームはPod内で実行されるすべてのコンテナよりも長持ちし、コンテナの再起動後もデータは保持されます。
|
||||
Kubernetesボリュームはボリュームを含んだPodが存在する限り有効です。そのため、ボリュームはPod内で実行されるどのコンテナよりも長く存在し、コンテナが再起動してもボリューム内のデータは維持されます。
|
||||
|
||||
詳しくは[ストレージ](https://kubernetes.io/docs/concepts/storage/)をご覧下さい。
|
||||
詳しくは[ストレージ](/ja/docs/concepts/storage/)をご覧ください。
|
||||
|
||||
Reference in New Issue
Block a user