# クラスターのアーキテクチャ

> Kubernetesの背後にあるアーキテクチャのコンセプト。

---

LLMS index: [llms.txt](/llms.txt)

---

Kubernetesクラスターは、コントロールプレーンと、コンテナ化されたアプリケーションを実行するワーカーマシン群(ノードと呼ばれます)で構成されます。
各クラスターには、Podを実行するために少なくとも1つのワーカーノードが必要です。

ワーカーノードは、アプリケーションのワークロードを構成するPodをホストします。
コントロールプレーンは、クラスター内のワーカーノードとPodを管理します。
本番環境では、コントロールプレーンは通常複数のコンピューターにまたがって実行され、クラスターは通常複数のノードを実行することで、耐障害性と高可用性を提供します。

このドキュメントでは、完全に機能するKubernetesクラスターに必要なさまざまなコンポーネントの概要を説明します。



<figure class="diagram-large ">
    <img src="/images/docs/kubernetes-cluster-architecture.svg"
         alt="コントロールプレーン(kube-apiserver、etcd、kube-controller-manager、kube-scheduler)と複数のノード。各ノードではkubeletとkube-proxyが実行されています。"/> <figcaption>
            <p>図1. Kubernetesクラスターのコンポーネント。</p>
        </figcaption>
</figure>

<details><summary>このアーキテクチャについて</summary><div class="details-inner">
    <p>図1は、Kubernetesクラスターのリファレンスアーキテクチャの一例を示しています。
コンポーネントの実際の配置は、具体的なクラスターの構成や要件によって異なる場合があります。</p>
<p>この図では、各ノードで<a href="#kube-proxy"><code>kube-proxy</code></a>コンポーネントが実行されています。
<a class='glossary-tooltip' title='Podの集合で実行されているアプリケーションをネットワークサービスとして公開する方法。' data-bs-toggle='tooltip' data-bs-placement='top' href='/ja/docs/concepts/services-networking/service/' target='_blank' aria-label='Service'>Service</a> APIと関連する動作をクラスターネットワーク上で利用可能にするためには、各ノードにネットワークプロキシコンポーネントが必要です。
ただし、一部のネットワークプラグインは、独自のサードパーティ製プロキシ実装を提供しています。
そのようなネットワークプラグインを使用する場合、ノードで<code>kube-proxy</code>を実行する必要はありません。</p>

  </div>
</details>


## コントロールプレーンコンポーネント {#control-plane-components}

コントロールプレーンのコンポーネントは、クラスターに関する全体的な判断(たとえばスケジューリングなど)を行うほか、クラスターのイベントの検知と対応(たとえば、Deploymentの`<a class='glossary-tooltip' title='ReplicaはPodのコピーであり、同一インスタンスを維持することで、可用性、スケーラビリティ、耐障害性を保証します。' data-bs-toggle='tooltip' data-bs-placement='top' href='/ja/docs/reference/glossary/?all=true#term-replica' target='_blank' aria-label='replicas'>replicas</a>`フィールドが満たされていない場合に新しい<a class='glossary-tooltip' title='一番小さく一番シンプルな Kubernetes のオブジェクト。Pod とはクラスターで動作しているいくつかのコンテナのまとまりです。' data-bs-toggle='tooltip' data-bs-placement='top' href='/ja/docs/concepts/workloads/pods/' target='_blank' aria-label='Pod'>Pod</a>を起動するなど)を行います。

コントロールプレーンコンポーネントは、クラスター内の任意のマシンで実行できます。
ただし、単純化のため、セットアップスクリプトは通常すべてのコントロールプレーンコンポーネントを同じマシン上で起動し、そのマシンではユーザーのコンテナを実行しません。
複数のマシンにまたがって実行されるコントロールプレーンのセットアップ例については、[kubeadmを使用した高可用性クラスターの作成](/docs/setup/production-environment/tools/kubeadm/high-availability/)を参照してください。

### kube-apiserver

<p>APIサーバーは、Kubernetes APIを外部に提供するKubernetes<a class='glossary-tooltip' title='コンテナのライフサイクルを定義、展開、管理するためのAPIとインターフェースを公開するコンテナオーケストレーションレイヤーです。' data-bs-toggle='tooltip' data-bs-placement='top' href='/ja/docs/reference/glossary/?all=true#term-control-plane' target='_blank' aria-label='コントロールプレーン'>コントロールプレーン</a>のコンポーネントです。
APIサーバーはKubernetesコントロールプレーンのフロントエンドになります。</p>
<p>Kubernetes APIサーバーの主な実装は<a href="/docs/reference/generated/kube-apiserver/">kube-apiserver</a>です。
kube-apiserverは水平方向にスケールするように設計されています—つまり、インスタンスを追加することでスケールが可能です。
複数のkube-apiserverインスタンスを実行することで、インスタンス間でトラフィックを分散させることが可能です。</p>

### etcd

<p>一貫性、高可用性を持ったキーバリューストアで、Kubernetesの全てのクラスター情報の保存場所として利用されています。</p>
<p>etcdをKubernetesのデータストアとして使用する場合、必ずデータの<a href="/ja/docs/tasks/administer-cluster/configure-upgrade-etcd/#backing-up-an-etcd-cluster">バックアップ</a>プランを作成して下さい。</p>
<p>公式<a href="https://etcd.io/docs/">ドキュメント</a>でetcdに関する詳細な情報を見つけることができます。</p>

### kube-scheduler

<p>コントロールプレーン上で動作するコンポーネントで、新しく作られた<a class='glossary-tooltip' title='一番小さく一番シンプルな Kubernetes のオブジェクト。Pod とはクラスターで動作しているいくつかのコンテナのまとまりです。' data-bs-toggle='tooltip' data-bs-placement='top' href='/ja/docs/concepts/workloads/pods/' target='_blank' aria-label='Pod'>Pod</a>に<a class='glossary-tooltip' title='ノードはKubernetesのワーカーマシンです。' data-bs-toggle='tooltip' data-bs-placement='top' href='/ja/docs/concepts/architecture/nodes/' target='_blank' aria-label='ノード'>ノード</a>が割り当てられているか監視し、割り当てられていなかった場合にそのPodを実行するノードを選択します。</p>
<p>スケジューリングの決定は、PodあるいはPod群のリソース要求量、ハードウェア/ソフトウェア/ポリシーによる制約、アフィニティおよびアンチアフィニティの指定、データの局所性、ワークロード間の干渉、有効期限などを考慮して行われます。</p>

### kube-controller-manager

<p>コントロールプレーン上で動作するコンポーネントで、複数の<a class='glossary-tooltip' title='クラスターの状態をAPIサーバーから取得、見張る制御ループで、現在の状態を望ましい状態に移行するように更新します。' data-bs-toggle='tooltip' data-bs-placement='top' href='/ja/docs/concepts/architecture/controller/' target='_blank' aria-label='コントローラー'>コントローラー</a>プロセスを実行します。</p>
<p>論理的には、各<a class='glossary-tooltip' title='クラスターの状態をAPIサーバーから取得、見張る制御ループで、現在の状態を望ましい状態に移行するように更新します。' data-bs-toggle='tooltip' data-bs-placement='top' href='/ja/docs/concepts/architecture/controller/' target='_blank' aria-label='コントローラー'>コントローラー</a>は個別のプロセスですが、複雑さを減らすために一つの実行ファイルにまとめてコンパイルされ、単一のプロセスとして動きます。</p>

コントローラーにはさまざまな種類があります。
いくつか例を挙げます:

- Nodeコントローラー: ノードがダウンした際に、それを検知して対応する役割を担います。
- Jobコントローラー: 一度限りのタスクを表すJobオブジェクトを監視し、それらのタスクを完了まで実行するためのPodを作成します。
- EndpointSliceコントローラー: (ServiceとPodの間のリンクを提供するために)EndpointSliceオブジェクトを作成します。
- ServiceAccountコントローラー: 新しい名前空間に対してデフォルトのServiceAccountを作成します。

上記はすべてを網羅したリストではありません。

### cloud-controller-manager

クラウド特有の制御ロジックを組み込むKubernetesの<a class='glossary-tooltip' title='コンテナのライフサイクルを定義、展開、管理するためのAPIとインターフェースを公開するコンテナオーケストレーションレイヤーです。' data-bs-toggle='tooltip' data-bs-placement='top' href='/ja/docs/reference/glossary/?all=true#term-control-plane' target='_blank' aria-label='コントロールプレーン'>コントロールプレーン</a>コンポーネントです。
クラウドコントロールマネージャーは、クラスターをクラウドプロバイダーAPIとリンクし、クラスターのみで相互作用するコンポーネントからクラウドプラットフォームで相互作用するコンポーネントを分離します。

cloud-controller-managerは、利用しているクラウドプロバイダーに固有のコントローラーのみを実行します。
オンプレミス環境でKubernetesを実行している場合や、自分のPC内の学習環境で実行している場合、クラスターにcloud-controller-managerは存在しません。

kube-controller-managerと同様に、cloud-controller-managerは、論理的に独立した複数の制御ループを、単一のプロセスとして実行する1つのバイナリにまとめています。
パフォーマンスの向上や障害への耐性を高めるために、水平方向にスケール(複数のコピーを実行)できます。

次のコントローラーは、クラウドプロバイダーに依存する可能性があります。

- Nodeコントローラー: ノードが応答を停止した後、そのノードがクラウド上で削除されたかどうかを判断するためにクラウドプロバイダーを確認します。
- Routeコントローラー: 基盤となるクラウドインフラ内でルートを設定します。
- Serviceコントローラー: クラウドプロバイダーのロードバランサーの作成、更新、削除を行います。

---

## Nodeコンポーネント {#node-components}

ノードコンポーネントはすべてのノード上で実行され、実行中のPodの維持やKubernetesの実行環境の提供を行います。

### kubelet

<p>クラスター内の各<a class='glossary-tooltip' title='ノードはKubernetesのワーカーマシンです。' data-bs-toggle='tooltip' data-bs-placement='top' href='/ja/docs/concepts/architecture/nodes/' target='_blank' aria-label='ノード'>ノード</a>上で実行されるエージェント。
<a class='glossary-tooltip' title='ソフトウェアとそのすべての依存関係を含む、軽量でポータブルな実行可能イメージです。' data-bs-toggle='tooltip' data-bs-placement='top' href='/ja/docs/concepts/containers/' target='_blank' aria-label='コンテナ'>コンテナ</a>が<a class='glossary-tooltip' title='一番小さく一番シンプルな Kubernetes のオブジェクト。Pod とはクラスターで動作しているいくつかのコンテナのまとまりです。' data-bs-toggle='tooltip' data-bs-placement='top' href='/ja/docs/concepts/workloads/pods/' target='_blank' aria-label='Pod'>Pod</a>内で実行されていることを保証します。</p>
<p><a href="/docs/reference/command-line-tools-reference/kubelet/">kubelet</a>は、さまざまなメカニズムを通じて提供される一連のPodSpecを受け取り、そのPodSpecに記述されたコンテナが実行され、正常であることを保証します。
kubeletは、Kubernetesによって作成されていないコンテナを管理しません。</p>

### kube-proxy(オプション) {#kube-proxy}

<p>kube-proxyはクラスター内の各<a class='glossary-tooltip' title='ノードはKubernetesのワーカーマシンです。' data-bs-toggle='tooltip' data-bs-placement='top' href='/ja/docs/concepts/architecture/nodes/' target='_blank' aria-label='node'>node</a>で動作しているネットワークプロキシで、Kubernetesの<a class='glossary-tooltip' title='Podの集合で実行されているアプリケーションをネットワークサービスとして公開する方法。' data-bs-toggle='tooltip' data-bs-placement='top' href='/ja/docs/concepts/services-networking/service/' target='_blank' aria-label='Service'>Service</a>コンセプトの一部を実装しています。</p>
<p><a href="/docs/reference/command-line-tools-reference/kube-proxy/">kube-proxy</a>は、Nodeのネットワークルールをメンテナンスします。これらのネットワークルールにより、クラスターの内部または外部のネットワークセッションからPodへのネットワーク通信が可能になります。</p>
<p>kube-proxyは、オペレーティングシステムにパケットフィルタリング層があり、かつ使用可能な場合、パケットフィルタリング層を使用します。それ以外の場合は自身でトラフィックを転送します。</p>
Serviceに対するパケット転送を自身で実装し、kube-proxyと同等の動作を提供する[ネットワークプラグイン](#network-plugins)を使用している場合、クラスター内のノードでkube-proxyを実行する必要はありません。

### コンテナランタイム {#container-runtime}

<p>Kubernetesがコンテナを効果的に実行するために不可欠なコンポーネントです。
Kubernetes環境においてコンテナの実行とライフサイクルの管理を担います。</p>
<p>Kubernetesは<a class='glossary-tooltip' title='シンプルさ、堅牢性、移植性を重視したコンテナランタイムです。' data-bs-toggle='tooltip' data-bs-placement='top' href='https://containerd.io/docs/' target='_blank' aria-label='containerd'>containerd</a>、<a class='glossary-tooltip' title='Kubernetesに特化した軽量コンテナランタイム' data-bs-toggle='tooltip' data-bs-placement='top' href='https://cri-o.io/#what-is-cri-o' target='_blank' aria-label='CRI-O'>CRI-O</a>などのコンテナランタイムと、<a href="https://github.com/kubernetes/community/blob/main/contributors/devel/sig-node/container-runtime-interface.md">Kubernetes CRI (Container Runtime Interface)</a>のすべての実装をサポートします。</p>

## アドオン {#addons}

アドオンは、Kubernetesのリソース(<a class='glossary-tooltip' title='Podのコピーがクラスター内の一連のNodeに渡って実行されることを保証します。' data-bs-toggle='tooltip' data-bs-placement='top' href='/ja/docs/concepts/workloads/controllers/daemonset' target='_blank' aria-label='DaemonSet'>DaemonSet</a>や<a class='glossary-tooltip' title='クラスター上の複製されたアプリケーションを管理します。' data-bs-toggle='tooltip' data-bs-placement='top' href='/ja/docs/concepts/workloads/controllers/deployment/' target='_blank' aria-label='Deployment'>Deployment</a>など)を使用してクラスターの機能を実装します。
これらはクラスターレベルの機能を提供するため、アドオンの名前空間に属するリソースは`kube-system`名前空間に配置されます。

いくつかのアドオンについて以下で説明します。
利用可能なアドオンのより詳細な一覧については、[アドオン](/docs/concepts/cluster-administration/addons/)を参照してください。

### DNS

他のアドオンは厳密には必須ではありませんが、多くの例がクラスターDNSに依存しているため、すべてのKubernetesクラスターは[クラスターDNS](/docs/concepts/services-networking/dns-pod-service/)を備えるべきです。

クラスターDNSは、環境内にある他のDNSサーバーに加えて稼働するDNSサーバーであり、KubernetesのService用のDNSレコードを提供します。

Kubernetesによって起動されたコンテナは、自動的にこのDNSサーバーをDNS検索に含めます。

### Web UI(Dashboard) {#web-ui-dashboard}

[Dashboard](/docs/tasks/access-application-cluster/web-ui-dashboard/)は、Kubernetesクラスターのための汎用的なWebベースのUIです。
ユーザーはこれを使って、クラスター内で稼働しているアプリケーションやクラスター自体の管理やトラブルシューティングを行えます。

### コンテナリソースの監視 {#container-resource-monitoring}

[コンテナリソースの監視](/docs/tasks/debug/debug-cluster/resource-usage-monitoring/)は、コンテナに関する一般的な時系列メトリクスを中央のデータベースに記録し、そのデータを閲覧するためのUIを提供します。

### クラスターレベルのロギング {#cluster-level-logging}

[クラスターレベルのロギング](/docs/concepts/cluster-administration/logging/)の仕組みは、コンテナのログを検索・閲覧用のインターフェースを備えた中央のログストアに保存する役割を担います。

### ネットワークプラグイン {#network-plugins}

[ネットワークプラグイン](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins)は、Container Network Interface(CNI)仕様を実装するソフトウェアコンポーネントです。
PodへのIPアドレスの割り当てや、クラスター内でPod同士が通信できるようにする役割を担います。

## アーキテクチャのバリエーション {#architecture-variations}

Kubernetesの中核となるコンポーネントは一貫していますが、それらがデプロイされ管理される方法はさまざまです。
これらのバリエーションを理解することは、特定の運用上のニーズを満たすKubernetesクラスターを設計し維持するうえで非常に重要です。

### コントロールプレーンのデプロイオプション {#control-plane-deployment-options}

コントロールプレーンコンポーネントは、いくつかの方法でデプロイできます。

従来のデプロイ
: コントロールプレーンコンポーネントは専用のマシンやVM上で直接実行され、多くの場合systemdのサービスとして管理されます。

static Pod
: コントロールプレーンコンポーネントはstatic Podとしてデプロイされ、特定のノード上のkubeletによって管理されます。
  これはkubeadmのようなツールで使われる一般的なアプローチです。

セルフホスト
: コントロールプレーンはKubernetesクラスター自体の内部でPodとして実行され、DeploymentやStatefulSet、その他のKubernetesのプリミティブによって管理されます。

マネージドKubernetesサービス
: クラウドプロバイダーは多くの場合コントロールプレーンを抽象化し、そのコンポーネントを自身のサービス提供の一部として管理します。

### ワークロード配置に関する考慮事項 {#workload-placement-considerations}

コントロールプレーンコンポーネントを含むワークロードの配置は、クラスターのサイズ、パフォーマンス要件、運用ポリシーによって異なる場合があります:

- より小規模なクラスターや開発用のクラスターでは、コントロールプレーンコンポーネントとユーザーのワークロードが同じノード上で実行されることがあります。
- より大規模な本番クラスターでは、多くの場合特定のノードをコントロールプレーンコンポーネント専用にし、ユーザーのワークロードから分離します。
- 一部の組織では、重要なアドオンや監視ツールをコントロールプレーンのノード上で実行します。

### クラスター管理ツール {#cluster-management-tools}

kubeadm、kops、Kubesprayといったツールは、クラスターのデプロイと管理に対してそれぞれ異なるアプローチを提供しており、コンポーネントの配置や管理の方法もそれぞれ独自のものです。

### カスタマイズと拡張性 {#customization-and-extensibility}

Kubernetesのアーキテクチャは、大幅なカスタマイズを可能にします。

- カスタムスケジューラーをデプロイして、デフォルトのKubernetesスケジューラーと並行して動作させたり、完全に置き換えたりできます。
- APIサーバーは、CustomResourceDefinitionやAPIアグリゲーションによって拡張できます。
- クラウドプロバイダーは、cloud-controller-managerを使用してKubernetesと深く統合できます。

Kubernetesのアーキテクチャの柔軟性により、組織は運用の複雑さ、パフォーマンス、管理のオーバーヘッドといった要素のバランスを取りながら、クラスターを特定のニーズに合わせて調整できます。

## 次の項目

以下についてさらに学べます。

- [ノード](/docs/concepts/architecture/nodes/)とコントロールプレーンとの[通信](/docs/concepts/architecture/control-plane-node-communication/)。
- Kubernetesの[コントローラー](/docs/concepts/architecture/controller/)。
- クラスターオブジェクトの[ガベージコレクション](/docs/concepts/architecture/garbage-collection/)。
- Kubernetesのデフォルトスケジューラーである[kube-scheduler](/docs/concepts/scheduling-eviction/kube-scheduler/)。
- etcdの公式[ドキュメント](https://etcd.io/docs/)。
- Kubernetesにおけるいくつかの[コンテナランタイム](/docs/setup/production-environment/container-runtimes/)。
- [cloud-controller-manager](/docs/concepts/architecture/cloud-controller/)を使用したクラウドプロバイダーとの統合。
- [kubectl](/docs/reference/generated/kubectl/kubectl-commands)コマンド。

---

Section pages:

- [ノード](/ja/docs/concepts/architecture/nodes/)
- [ノードとコントロールプレーン間の通信](/ja/docs/concepts/architecture/control-plane-node-communication/)
- [リース](/ja/docs/concepts/architecture/leases/)
- [コントローラー](/ja/docs/concepts/architecture/controller/)
- [クラウドコントローラーマネージャー](/ja/docs/concepts/architecture/cloud-controller/)
- [cgroup v2について](/ja/docs/concepts/architecture/cgroups/)
- [Kubernetesの自己修復機能](/ja/docs/concepts/architecture/self-healing/)
- [コンテナランタイムインターフェース(CRI)](/ja/docs/concepts/architecture/cri/)
- [ガベージコレクション](/ja/docs/concepts/architecture/garbage-collection/)
- [Mixed Version Proxy](/ja/docs/concepts/architecture/mixed-version-proxy/)