Kubernetesの概要

Kubernetesが機能するために必要な基本コンポーネントの1つは、グローバルに利用可能な構成ストアです。 CoreOSのチームによって開発されたetcd projectは、複数のノードにまたがるように構成できる軽量の分散型Key-Valueストアです。

Kubernetesはetcdを使用して、クラスター内の各ノードからアクセスできる構成データを格納します。 これは、サービスの検出に使用でき、コンポーネントが最新の情報に基づいて自身を構成または再構成するのに役立ちます。 また、リーダー選出や分散ロックなどの機能により、クラスターの状態を維持するのにも役立ちます。 単純なHTTP / JSON APIを提供することにより、値を設定または取得するためのインターフェースは非常に簡単です。

コントロールプレーン内の他のほとんどのコンポーネントと同様に、etcdは、単一のマスターサーバー上で構成することも、実稼働シナリオでは複数のマシンに分散させることもできます。 唯一の要件は、各Kubernetesマシンからネットワークにアクセスできることです。

最も重要なマスターサービスの1つはAPIサーバーです。 これは、ユーザーがKubernetesのワークロードと組織単位を構成できるため、クラスター全体の主要な管理ポイントです。 また、etcdストアとデプロイされたコンテナーのサービスの詳細が一致していることを確認する責任もあります。 さまざまなコンポーネント間のブリッジとして機能し、クラスターの正常性を維持し、情報とコマンドを広めます。

APIサーバーはRESTfulインターフェースを実装します。つまり、多くの異なるツールやライブラリが簡単に通信できます。 ローカルコンピューターからKubernetesクラスターと対話するデフォルトの方法として、kubectlというクライアントを使用できます。

コントローラーマネージャーは、多くの責任を持つ一般的なサービスです。 主に、クラスターの状態を調整し、ワークロードのライフサイクルを管理し、日常的なタスクを実行するさまざまなコントローラーを管理します。 たとえば、レプリケーションコントローラーは、ポッドに定義されたレプリカ（同一のコピー）の数がクラスターに現在デプロイされている数と一致することを保証します。 これらの操作の詳細はetcdに書き込まれ、コントローラーマネージャーはAPIサーバーを介して変更を監視します。

変更が見られると、コントローラーは新しい情報を読み取り、目的の状態を満たす手順を実行します。 これには、アプリケーションの拡大または縮小、エンドポイントの調整などが含まれます。

実際にクラスター内の特定のノードにワークロードを割り当てるプロセスは、スケジューラーです。 このサービスは、ワークロードの動作要件を読み取り、現在のインフラストラクチャ環境を分析し、受け入れ可能なノードに作業を配置します。

スケジューラは、各ホストで利用可能な容量を追跡し、利用可能なリソースを超えてワークロードがスケジュールされないようにする責任があります。 スケジューラは、各サーバーの既存のワークロードに既に割り当てられているリソースだけでなく、総容量も知っている必要があります。

Kubernetesはさまざまな環境に展開でき、さまざまなインフラストラクチャプロバイダーと対話して、クラスター内のリソースの状態を把握および管理できます。 Kubernetesは、アタッチ可能なストレージやロードバランサーなどのリソースの一般的な表現で動作しますが、これらを不均一なクラウドプロバイダーが提供する実際のリソースにマッピングする方法が必要です。

クラウドコントローラーマネージャーは、Kubernetesがさまざまな機能、機能、APIを備えたプロバイダーと相互作用しながら、比較的一般的な構造を内部的に維持できるようにする接着剤として機能します。 これにより、Kubernetesは、クラウドプロバイダーから収集した情報に従って状態情報を更新し、システムでの変更が必要に応じてクラウドリソースを調整し、クラスターに送信された作業要件を満たすために追加のクラウドサービスを作成および使用できます。

各ノードに必要な最初のコンポーネントは、コンテナランタイムです。 通常、この要件はDockerをインストールして実行することで満たされますが、rktやruncなどの代替手段も利用できます。

コンテナランタイムは、比較的孤立しているが軽量のオペレーティング環境にカプセル化されたアプリケーション、コンテナの起動と管理を担当します。 クラスター上の各作業単位は、基本レベルで、デプロイする必要がある1つ以上のコンテナーとして実装されます。 各ノードのコンテナーランタイムは、クラスターに送信されたワークロードで定義されたコンテナーを最終的に実行するコンポーネントです。

クラスターグループとの各ノードの主な連絡先は、kubeletと呼ばれる小さなサービスです。 このサービスは、コントロールプレーンサービスとの間で情報を中継するだけでなく、etcdストアと対話して、構成の詳細を読み取ったり、新しい値を書き込んだりします。

kubeletサービスは、マスターコンポーネントと通信して、クラスターに対して認証を行い、コマンドを受信して​​機能します。 作業は、ワークロードと操作パラメーターを定義するmanifestの形式で受信されます。 次に、kubeletプロセスは、ノードサーバー上の作業の状態を維持する責任を負います。 コンテナランタイムを制御して、必要に応じてコンテナを起動または破棄します。

個々のホストサブネットを管理し、他のコンポーネントでサービスを利用できるようにするために、kube-proxyと呼ばれる小さなプロキシサービスが各ノードサーバーで実行されます。 このプロセスは、リクエストを正しいコンテナに転送し、プリミティブなロードバランシングを実行できます。一般的に、ネットワーク環境が予測可能でアクセス可能であることを確認しますが、必要に応じて隔離します。

podは、Kubernetesが処理する最も基本的な単位です。 コンテナ自体はホストに割り当てられていません。 代わりに、1つ以上の密結合されたコンテナがポッドと呼ばれるオブジェクトにカプセル化されます。

ポッドは通常、単一のアプリケーションとして制御する必要がある1つ以上のコンテナを表します。 ポッドは、密接に連携して動作し、ライフサイクルを共有するコンテナで構成されており、常に同じノードでスケジュールする必要があります。 それらは完全にユニットとして管理され、環境、ボリューム、およびIPスペースを共有します。 コンテナ化された実装にもかかわらず、一般にポッドを単一のモノリシックアプリケーションと見なして、クラスターがポッドのリソースとスケジューリングをどのように管理するかを最適に概念化する必要があります。

通常、ポッドは、ワークロードの一般的な目的を満たすメインコンテナーと、オプションで密接に関連するタスクを促進するヘルパーコンテナーで構成されます。 これらは、独自のコンテナで実行および管理されることで恩恵を受けるプログラムですが、メインアプリケーションと密接に結びついています。 たとえば、ポッドには、プライマリアプリケーションサーバーを実行する1つのコンテナと、外部リポジトリで変更が検出されたときにファイルを共有ファイルシステムにプルするヘルパーコンテナがある場合があります。 タスクに適した他の高レベルのオブジェクトがあるので、水平スケーリングは通常ポッドレベルでは推奨されません。

通常、ユーザーはポッドを自分で管理するべきではありません。アプリケーションで一般的に必要とされる機能の一部（高度なライフサイクル管理やスケーリングなど）を提供しないためです。 代わりに、ポッドまたはポッドテンプレートを基本コンポーネントとして使用し、追加機能を実装する高レベルのオブジェクトを使用することをお勧めします。

多くの場合、1つのポッドではなくKubernetesで作業する場合、代わりに同一の複製されたポッドのグループを管理します。 これらはポッドテンプレートから作成され、レプリケーションコントローラーおよびレプリケーションセットと呼ばれるコントローラーによって水平方向にスケーリングできます。

replication controllerは、実行中のコピーの数を増減することにより、ポッドの同一のレプリカを水平方向にスケーリングするためのポッドテンプレートと制御パラメーターを定義するオブジェクトです。 これは、負荷を分散し、Kubernetes内でネイティブに可用性を向上させる簡単な方法です。 複製コントローラーは、ポッド定義に非常に類似したテンプレートが複製コントローラー構成内に組み込まれているため、必要に応じて新しいポッドを作成する方法を知っています。

レプリケーションコントローラーは、クラスターに展開されたポッドの数がその構成内のポッドの数と一致することを保証する責任があります。 ポッドまたは基盤となるホストに障害が発生した場合、コントローラーは新しいポッドを開始して補正します。 コントローラーの構成内のレプリカの数が変更された場合、コントローラーは目的の数に一致するようにコンテナーを起動または強制終了します。 レプリケーションコントローラーは、ローリングアップデートを実行して、ポッドのセットを1つずつ新しいバージョンにロールオーバーし、アプリケーションの可用性への影響を最小限に抑えることができます。

Replication setsは、レプリケーションコントローラーの設計を反復したものであり、コントローラーが管理対象のポッドを識別する方法に柔軟性があります。 レプリケーションセットは、レプリカ選択機能が優れているため、レプリケーションコントローラーを置き換え始めていますが、ローリングアップデートを実行して、バックエンドをレプリケーションコントローラーのように新しいバージョンに切り替えることはできません。 代わりに、複製セットは、その機能を提供する追加のより高いレベルのユニットの内部で使用されることを意図しています。

ポッドと同様に、レプリケーションコントローラーとレプリケーションセットの両方が、直接作業するユニットになることはめったにありません。 水平スケーリングと信頼性の保証を追加するためにポッドの設計に基づいて構築されていますが、より複雑なオブジェクトに見られるきめ細かいライフサイクル管理機能の一部が欠けています。

Deploymentsは、直接作成および管理する最も一般的なワークロードの1つです。 展開では、複製セットをビルディングブロックとして使用し、柔軟なライフサイクル管理機能をミックスに追加します。

レプリケーションセットで構築された展開は、レプリケーションコントローラが提供する機能を複製するように見える場合がありますが、展開はローリング更新の実装に存在する多くの問題点を解決します。 レプリケーションコントローラーを使用してアプリケーションを更新する場合、ユーザーは現在のコントローラーを置き換える新しいレプリケーションコントローラーの計画を提出する必要があります。 レプリケーションコントローラーを使用する場合、履歴の追跡、更新中のネットワーク障害からの回復、悪い変更のロールバックなどのタスクは困難であるか、ユーザーの責任に任されます。

デプロイメントは、複製されたポッドのライフサイクル管理を容易にするために設計された高レベルのオブジェクトです。 構成を変更することで展開を簡単に変更でき、Kubernetesはレプリカセットを調整し、異なるアプリケーションバージョン間の移行を管理し、オプションでイベント履歴と元に戻す機能を自動的に維持します。 これらの機能のために、デプロイメントはおそらく最も頻繁に使用するKubernetesオブジェクトのタイプになります。

Stateful setsは、順序付けと一意性の保証を提供する特殊なポッドコントローラーです。 主に、展開の順序、永続的なデータ、または安定したネットワークに関連する特別な要件がある場合、これらを使用してよりきめ細かな制御を行います。 たとえば、ステートフルセットは、多くの場合、新しいノードにスケジュール変更されても同じボリュームへのアクセスが必要なデータベースなどのデータ指向アプリケーションに関連付けられます。

ステートフルセットは、ポッドを別のノードに移動する必要がある場合でも保持される各ポッドに一意の番号ベースの名前を作成することにより、安定したネットワーク識別子を提供します。 同様に、再スケジュールが必要な場合は、永続ストレージボリュームをポッドで転送できます。 偶発的なデータ損失を防ぐため、ポッドが削除された後でもボリュームは保持されます。

スケールを展開または調整する場合、ステートフルセットは、名前の番号付き識別子に従って操作を実行します。 これにより、実行順序の予測可能性と制御が向上し、場合によっては役立ちます。

Daemon setsは、クラスター内の各ノード（または指定されている場合はサブセット）でポッドのコピーを実行する、別の特殊な形式のポッドコントローラーです。 これは、メンテナンスを実行し、ノード自体にサービスを提供するのに役立つポッドを展開するときに最もよく役立ちます。

たとえば、ログの収集と転送、メトリックの集約、ノード自体の機能を向上させるサービスの実行は、デーモンセットの一般的な候補です。 デーモンセットは多くの場合基本的なサービスを提供し、フリート全体で必要となるため、他のコントローラーが特定のホストにポッドを割り当てることを防ぐポッドスケジューリング制限をバイパスできます。 一例として、その固有の責任により、マスターサーバーは通常のポッドスケジューリングでは使用できないように設定されることがよくありますが、デーモンセットにはポッドごとに制限をオーバーライドして、重要なサービスが実行されていることを確認する機能があります。

これまで説明してきたワークロードはすべて、長期にわたるサービスのようなライフサイクルを想定しています。 Kubernetesは、jobsと呼ばれるワークロードを使用して、よりタスクベースのワークフローを提供します。このワークフローでは、実行中のコンテナーは、作業が完了するとしばらくすると正常に終了することが期待されます。 ジョブは、継続的なサービスを実行する代わりに1回限りの処理またはバッチ処理を実行する必要がある場合に役立ちます。

ジョブの構築はcron jobsです。 スケジュールに従ってスクリプトを実行するLinuxおよびUnixライクなシステム上の従来のcronデーモンと同様に、Kubernetesのcronジョブは、スケジューリングコンポーネントを使用してジョブを実行するためのインターフェイスを提供します。 Cronジョブを使用して、将来または定期的に定期的に実行するジョブをスケジュールできます。 Kubernetesのcronジョブは基本的に、単一のオペレーティングシステムの代わりにクラスターをプラットフォームとして使用する、古典的なcron動作の再実装です。

これまで、従来のUnixのような意味で「サービス」という用語を使用してきました。多くの場合、ネットワークに接続され、要求に応答できる長時間実行されるプロセスを示します。 ただし、Kubernetesでは、serviceは、基本的な内部ロードバランサーおよびポッドのアンバサダーとして機能するコンポーネントです。 サービスは、同じ機能を実行するポッドの論理コレクションをグループ化して、単一のエンティティとして提示します。

これにより、特定のタイプのすべてのバックエンドコンテナーを追跡およびルーティングできるサービスを展開できます。 内部消費者は、サービスが提供する安定したエンドポイントについてのみ知る必要があります。 一方、サービスの抽象化により、必要に応じてバックエンドワークユニットをスケールアウトまたは置換できます。 サービスのIPアドレスは、ルーティング先のポッドの変更に関係なく安定しています。 サービスを展開することで、発見しやすくなり、コンテナ設計を簡素化できます。

1つ以上のポッドへのアクセスを別のアプリケーションまたは外部コンシューマーに提供する必要があるときはいつでも、サービスを構成する必要があります。 たとえば、インターネットからアクセスできるWebサーバーを実行するポッドのセットがある場合、サービスは必要な抽象化を提供します。 同様に、Webサーバーがデータを保存および取得する必要がある場合は、データベースポッドへのアクセスを許可するように内部サービスを構成する必要があります。

デフォルトでは、サービスは内部でルーティング可能なIPアドレスを使用してのみ使用できますが、いくつかの戦略の1つを選択することにより、クラスターの外部で使用可能にすることができます。 NodePort構成は、各ノードの外部ネットワークインターフェイスで静的ポートを開くことによって機能します。 外部ポートへのトラフィックは、内部クラスターIPサービスを使用して適切なポッドに自動的にルーティングされます。

または、LoadBalancerサービスタイプは、クラウドプロバイダーのKubernetesロードバランサー統合を使用してサービスにルーティングする外部ロードバランサーを作成します。 クラウドコントローラーマネージャーは、適切なリソースを作成し、内部サービスのサービスアドレスを使用して構成します。

コンテナの再起動間で信頼性の高いデータ共有とその可用性の保証は、多くのコンテナ化された環境での課題です。 多くの場合、コンテナランタイムは、コンテナの有効期間を超えて持続するストレージをコンテナにアタッチするメカニズムを提供しますが、通常、実装には柔軟性がありません。

これに対処するために、Kubernetesは独自のvolumes抽象化を使用して、ポッド内のすべてのコンテナーでデータを共有し、ポッドが終了するまでデータを利用できるようにします。 つまり、密結合されたポッドは、複雑な外部メカニズムなしでファイルを簡単に共有できます。 ポッド内のコンテナの障害は、共有ファイルへのアクセスには影響しません。 ポッドが終了すると、共有ボリュームは破棄されるため、真に永続的なデータには適したソリューションではありません。

Persistent volumesは、ポッドのライフサイクルに関係しない、より堅牢なストレージを抽象化するためのメカニズムです。 代わりに、管理者がクラスターのストレージリソースを構成し、ユーザーが実行中のポッドを要求および要求できるようにします。 永続的なボリュームでポッドが完了すると、ボリュームのレクラメーションポリシーにより、データとともに手動で削除または削除されるまでボリュームを保持するかどうかが決定されます。 永続データを使用して、ノードベースの障害から保護し、ローカルで使用可能なストレージよりも多くのストレージを割り当てることができます。

Kubernetesは、他の概念に関連しているが他の概念の外にある組織の抽象化はラベル付けです。 Kubernetesのlabelは、Kubernetesオブジェクトにアタッチして、グループの一部としてマークすることができるセマンティックタグです。 これらは、管理またはルーティングのために異なるインスタンスをターゲットにするときに選択できます。 たとえば、コントローラーベースの各オブジェクトはラベルを使用して、操作対象のポッドを識別します。 サービスはラベルを使用して、リクエストをルーティングするバックエンドポッドを理解します。

ラベルは単純なキーと値のペアとして与えられます。 各ユニットは複数のラベルを持つことができますが、各ユニットはキーごとに1つのエントリしか持つことができません。 通常、「名前」キーは汎用識別子として使用されますが、開発段階、公開アクセシビリティ、アプリケーションバージョンなどの他の基準によってオブジェクトをさらに分類できます。

Annotationsは、任意のKey-Value情報をオブジェクトに添付できる同様のメカニズムです。 ポッドを選択基準に一致させるのに役立つ意味情報にはラベルを使用する必要がありますが、注釈はより自由形式であり、構造化されていないデータを含めることができます。 一般に、注釈は、オブジェクトに豊富なメタデータを追加する方法であり、選択の目的には役立ちません。