コンテンツにスキップ

「Kubernetes」の版間の差分

出典: フリー百科事典『ウィキペディア（Wikipedia）』
履歴の双方向閲覧
← 古い編集新しい編集 →
削除された内容 追加された内容
ビジュアルウィキテキスト
m →‎出典: 参照エラー
タグ: 差し戻し済み コメントアウト
65行目: 65行目:


=== ノード ===
=== ノード ===
ノード（ワーカーまたはMinionとも呼ばれる）は、コンテナ（ワークロード）が実際にデプロイされるマシンである。クラスタ内のすべてのノードはcontainerdなどのコンテナ[[ランタイムシステム|ランタイム]]を実行する必要があり、コンテナのネットワーク設定のためにマスターと通信を行う、以下に説明するようなコンポーネントも実行する。
ノード（ワーカーまたはMinionとも呼ばれる）は、コンテナ（ワークロード）が実際にデプロイされるマシンである。クラスタ内のすべてのノードはcontainerdなどのコンテナ[[ランタイムシステム|ランタイム]]を実行する必要<ref>{{Cite web |title=Container Runtimes |url=https://kubernetes.io/docs/setup/production-environment/container-runtimes/ |website=Kubernetes |access-date=2023-02-13 |language=en}}</ref>があり、コンテナのネットワーク設定のためにマスターと通信を行う、以下に説明するようなコンポーネントも実行する。


* '''Kubelet'''は、各ノードの実行状態に対する責務を担い、ノード内のすべてのコンテナが健全な状態であることを保証する。コントロールプレーンの指示を受けて、アプリケーションコンテナ群をスタート、ストップ、管理し、ポッドとして組織する<ref name="do-intro3" /><ref>{{Cite web |url=http://kamalmarhubi.com/blog/2015/08/27/what-even-is-a-kubelet/ |title=What [..] is a Kubelet? |access-date=2015-11-02 |last=Marhubi |first=Kamal |date=2015-08-27 |website= |publisher=kamalmarhubi.com |archiveurl=https://web.archive.org/web/20151113064016/http://kamalmarhubi.com/blog/2015/08/27/what-even-is-a-kubelet/ |archivedate=2015-11-13 |deadurl=no |df=}}</ref>。Kubeletはポッドの状態を監視し、指定された状態から逸脱していることを検出すると、ポッドを同じノードに自動的に再デプロイする。ノードの状態は数秒ごとにハートビートメッセージとしてマスターに送信される。プライマリがノードの障害を検知するとすぐに、Replication Controllerがこの状態を確認し、他の健全な状態にあるノードでポッドを新たに起動する<ref>{{Cite web |title=Kubernetes Security {{!}} Issues and Best Practices {{!}} Snyk |url=https://snyk.io/learn/kubernetes-security/ |access-date=2021-05-16 |website=snyk.io |date=26 July 2020 |language=en-US}}</ref>。
* '''Kubelet'''は、各ノードの実行状態に対する責務を担い、ノード内のすべてのコンテナが健全な状態であることを保証する。コントロールプレーンの指示を受けて、アプリケーションコンテナ群をスタート、ストップ、管理し、ポッドとして組織する<ref name="do-intro3" /><ref>{{Cite web |url=http://kamalmarhubi.com/blog/2015/08/27/what-even-is-a-kubelet/ |title=What [..] is a Kubelet? |access-date=2015-11-02 |last=Marhubi |first=Kamal |date=2015-08-27 |website= |publisher=kamalmarhubi.com |archiveurl=https://web.archive.org/web/20151113064016/http://kamalmarhubi.com/blog/2015/08/27/what-even-is-a-kubelet/ |archivedate=2015-11-13 |deadurl=no |df=}}</ref>。Kubeletはポッドの状態を監視し、指定された状態から逸脱していることを検出すると、ポッドを同じノードに自動的に再デプロイする。ノードの状態は数秒ごとにハートビートメッセージとしてマスターに送信される。プライマリがノードの障害を検知するとすぐに、Replication Controllerがこの状態を確認し、他の健全な状態にあるノードでポッドを新たに起動する<ref>{{Cite web |title=Kubernetes Security {{!}} Issues and Best Practices {{!}} Snyk |url=https://snyk.io/learn/kubernetes-security/ |access-date=2021-05-16 |website=snyk.io |date=26 July 2020 |language=en-US}}</ref>。

2023年2月13日 (月) 20:48時点における版

Kubernetes
作者 Google
開発元 Cloud Native Computing Foundation
初版 2014年6月7日 (10年前) (2014-06-07)[1]
リポジトリ https://github.com/kubernetes/kubernetes
プログラミング
言語		 Go
サポート状況 開発中
種別 クラスター管理ソフトウェア・コンテナオーケストレーション
ライセンス Apache License 2.0
公式サイト kubernetes.io
テンプレートを表示

Kubernetes（クバネティス[2]/クバネテス/クーべネティス[3][4]、K8sと略記される[5]）は、ソフトウェアのデプロイ、スケーリング、および管理を自動化するためのオープンソースのコンテナオーケストレーションシステムである[6][7]。元々はGoogleによって設計されたが、現在はCloud Native Computing Foundationによってメンテナンスされている。

Kubernetesという名前は、ギリシャ語に由来し、舵取りや操縦士を意味する。Kubernetesは、「K」と「s」の間の8文字を数えて、K8sと略されることが多い[8]。

Kubernetesは、containerd、CRI-Oと連携して動作する[9]。大規模なクラウドネイティブワークロードの実行と管理に適しているため、データセンターでの採用が広がっている。このプラットフォームには、独立系ソフトウェアベンダーによる複数のディストリビューションと、主要なパブリッククラウドベンダーによるクラウドホスティングサービスがある。

歴史

Google Cloud SummitでのGoogle Container Engineに関するトーク

“Kubernetes”（希: κυβερνήτης、koo-ber-nay'-tace[10][11]、クベルネテス）は、ギリシャ語で航海長または水先案内人を意味し、サイバネティクス（人工頭脳学）の語源でもある[12]。Kubernetesは、当初Joe Beda、Brendan Burns、Craig McLuckieの3人によって開発が始まり[13]、すぐにBrian GrantやTim Hockinなど、他のGoogleのエンジニアも参加するようになり、2014年中ごろにGoogleから初めて発表された[14]。

Kubernetesの開発や設計はGoogleのBorgシステムから強い影響を受けており[15][16]、Borgのトップコントリビュータの多くが開発に参加している。Google内でのKubernetesのもともとのコードネームはProject Sevenであり、スター・トレックのキャラクターで、優しいBorgである、セブン・オブ・ナインの名前に由来する[17]。Kubernetesのロゴの輪にある7つのスポークは、このコードネームに由来している。C++で書かれたBorg[18]とは異なり、KubernetesのソースコードはGo言語である。

Kubernetes v1.0は2015年7月21日にリリースされた[19]。Kubernetes v1.0のリリースと同時に、GoogleはLinux Foundationと共同でCloud Native Computing Foundation（CNCF）を設立し、Kubernetesを種となる技術として提供した。2016年2月[20]、Kubernetes用のパッケージマネージャ「Helm」がリリースされた[21][22]。

GoogleはすでにマネージドKubernetesサービスを提供しており、Red Hatは2014年のKubernetesプロジェクト発足時から、OpenShiftの一部としてKubernetesをサポートしていた。2017年、主要な競合他社がKubernetesに結集し、ネイティブサポートを追加すると発表した。

2018年3月6日には、KubernetesプロジェクトはGitHubにおけるコミット数で第9位に到達し、コントリビューター数とissue数では、Linuxカーネルプロジェクトに次いで第2位となった[28]。

バージョン1.18まで、KubernetesはN-2サポートポリシーに従っており、最新の3つのマイナーバージョンにセキュリティアップデートとバグフィックスが提供されることになっていた[29]。バージョン1.19から、KubernetesはN-3サポートポリシーに従いる[30]。当初は「Dockershim」を介してDockerランタイムと専ら連動していた[31]が、2020年11月から2022年4月まで、KubernetesはShimを非推奨とし、Containerdを介してコンテナと直接連動するか、DockerをCRI (Container Runtime Interface) に準拠するランタイムに置き換えることにした[32][33][34]。2022年5月のv1.24のリリースで、「Dockershim」は完全に削除された[35]。

コンセプト

Kubernetesのアーキテクチャ図

Kubernetesは、いくつかのビルディングブロック（"primitives"）を定義している。このビルディングブロックのおかげで、アプリケーションのデプロイ、メンテナンス、スケールのメカニズムを、CPU、メモリ[36]、あるいはカスタムの指標[37]に基づいて正しく提供することが可能になっている。Kubernetesは、さまざまなワークロードに対応できるよう、疎結合かつ拡張可能なシステムとなっている。この拡張性の大部分は、Kubernete上で動作する拡張機能やコンテナだけでなく内部コンポーネントによっても使用されているKubernetes APIにより提供されている[38]。Kubernetesでは、コンピューティングとストレージのリソースを制御するため、リソースを以下のような「オブジェクト」として定義している。

Kubernetesは、プライマリ・レプリカアーキテクチャで構成される。Kubernetesのコンポーネントは、各ノードを管理するものと、コントロールプレーンの一部である2つに分けられる[39][40]。

コントロールプレーン

Kubernetesのマスターは、クラスターのメインとなるコントロールユニットである。ワークロードとシステム全体に渡る直接的な通信を管理する。Kubernetesコントロールプレーンは複数のさまざまなコンポーネントから構成されている。各コンポーネントは独立したプロセスとして実行され、1つのマスターノードでも、高可用クラスタ（英語版）をサポートするために複数のマスターノードで実行することも可能である[41]。各種コンポーネントには、次のようなものがある。

  • etcd[42]は、CoreOS（英語版）により開発された、永続的な軽量な分散キーバリューストアである。クラスタの設定データを確実に保存し、任意の時点でのクラスタ全体の状態を保存する。etcdは、ネットワーク部分のイベントにおいて、可用性（Availability）よりも一貫性（Consistency）を重視するシステムである（CAP定理を参照）。この一貫性は、サービスを正しくスケジューリングし、運用するために非常に重要である。
  • API serverはキーとなるコンポーネントであり、HTTP上のJSONを利用したKubernetes APIのサーバーである。Kubernetesに対する内部および外部向けのインターフェイスの両方を提供する[43][44]。API serverはRESTリクエストの処理と検証を行い、etcd（英語版）に保存されたAPIオブジェクトの状態を更新する。したがって、Kubernetes APIを利用することで、クライアントはワーカーノード全体に渡るワークロードとコンテナの設定を行うことが可能になる[45]。
  • schedulerはプラガブルなコンポーネントで、未スケジュールのポッド（schedulerが管理する基本エンティティ）をどのノードで実行するのかを、リソースの可用性に基づいて選択する役割を担う。schedulerは各ノード上でのリソースの使用量をトラッキングし、ワークロードが利用可能なリソースを超過しないことを保証する。この目的を達成するためには、schedulerは、リソースの要求量、リソースの可用性、その他のユーザーが提供する制約、そして、サービス品質、親和性・非親和性の要件、データの局所性などのポリシーのディレクティブを知っている必要がある。本質的には、schedulerの役割は、リソースの「供給」をワークロードの「需要」に合わせることであると言える[46]。
  • controllerは、実際のクラスタの状態を期待されるクラスタの状態と一致するように駆動するループである[47]。これは、ポッド群を管理することで行われる。コントローラの1つには、replication controller（レプリケーションコントローラー）がある。このコントローラーは、ポッドのレプリカ数をクラスタ全体で指定した数になるようにレプリケーションとスケーリングを操作する。また、管理しているノードに障害が発生した場合には、代替のポッドの生成の操作も実行する[47]。Kubernetesシステムの一部である他のコントローラの1つには、DaemonSet Controller（デーモンセットコントローラー）がある。これは、1台のマシンでポッドが必ず1つのみ実行されるようにする。Job Controller（ジョブコントローラー）は、たとえばバッチジョブの一部として、ポッドをジョブが完了するまで実行させる[48]。コントローラーが管理するポッド群は、コントローラーの定義の一部である、ラベルセレクターを利用して特定する[49]。
  • Controller manager（コントローラーマネージャー）は、DaemonSet ControllerやReplication ControllerなどのKubernetesのコアとなるコントローラーを実行するプロセスである。コントローラーは、APIサーバーと通信することで、管理対象のリソース（ポッド、サービスエンドポイントなど）の作成、更新、削除を実行する[44]。

ノード

ノード（ワーカーまたはMinionとも呼ばれる）は、コンテナ（ワークロード）が実際にデプロイされるマシンである。クラスタ内のすべてのノードはcontainerdなどのコンテナランタイムを実行する必要[50]があり、コンテナのネットワーク設定のためにマスターと通信を行う、以下に説明するようなコンポーネントも実行する。

  • Kubeletは、各ノードの実行状態に対する責務を担い、ノード内のすべてのコンテナが健全な状態であることを保証する。コントロールプレーンの指示を受けて、アプリケーションコンテナ群をスタート、ストップ、管理し、ポッドとして組織する[43][51]。Kubeletはポッドの状態を監視し、指定された状態から逸脱していることを検出すると、ポッドを同じノードに自動的に再デプロイする。ノードの状態は数秒ごとにハートビートメッセージとしてマスターに送信される。プライマリがノードの障害を検知するとすぐに、Replication Controllerがこの状態を確認し、他の健全な状態にあるノードでポッドを新たに起動する[52]。
  • Kube-proxyはネットワークプロキシおよびロードバランサーの実装であり、サービスの抽象化やその他のネットワーク操作をサポートする[43]。トラフィックのルーティングを、受信したリクエストのIPアドレスとポート番号を元に、適切なコンテナにルーティングする責務を担う。
  • containerはポッドの中に置かれる。containerは最も低レベルなマイクロサービスであり、実行中のアプリケーション、ライブラリ、およびその依存関係が格納される。containerは外部IPアドレスを割り当てて世界に対して公開することもできる。Kubernetesは最初のバージョン以来Dockerコンテナをサポートしており、2016年7月には、rktコンテナエンジンが追加された[53]。

ネームスペース

Kubernetesは、リソースのパーティショニング機能を提供し、ネームスペース（名前空間）と呼ばれる重複のない部分に分割する[54]。多数のチームやプロジェクトに渡る多数のユーザーの利用を想定している。これにより、開発、テスト、本番などの環境さえ完全に分離することができる。

ポッド

Kubernetesでは、スケジューリングの基本となる単位はポッド[55]で、同一ノードに同居することが保証されている1つ以上のコンテナで構成されている[56]。Kubernetesの各ポッドには、クラスタ内で一意のIPアドレスが割り当てられ、アプリケーションは競合のリスクなしにポートを使用できるようになる[57]。ポッド内では、すべてのコンテナが互いを参照できる。

1つのポッドは、ローカルディスクのディレクトリあるいはネットワークディスクとして、1つのボリュームを定義し、ポッド内のコンテナに対して公開することができる[58]。ポッドの管理は、Kubernetes APIで手動で行ったり、コントローラに管理を委譲したりすることができる[38]。また、定義したボリュームは、ConfigMaps（設定の内容を、コンテナからファイルシステム上で参照可能にする機能）やSecrets（リモートのリソースに安全にアクセスするために必要な証明書を、認証されたコンテナのみでファイルシステム上で参照可能にする機能）など、Kubernetesのいくつかの機能の基礎となっている。

DaemonSets

通常、Kubernetes SchedulerはPodを実行する場所を決定する。しかし、いくつかのユースケースでは、クラスタ内のすべてのノードでPodを実行する必要がある場合がある。これは、ログ収集、イングレスコントローラー、ストレージサービスなどのユースケースで有用である。DaemonSetsは、このようなPodのスケジューリングを実装している[59]。

ReplicaSets

ReplicaSetの目的は、任意の時点で実行されているレプリカポッドのセットを安定的に維持することである。そのため、指定された数の同一Podの可用性を保証するために使用されることがよくある[60]。

また、ReplicaSet[61]は、Kubernetesに特定のPodについて宣言されたインスタンスの数を維持させるためのグループ化メカニズムであるとも言える。ReplicaSetの定義ではセレクタを使用し、その評価によって関連するすべてのPodを特定することになる。

サービス

Kubernetesクラスタ内で、サービスがPodネットワークと通信する方法を簡略的に表した図

Kubernetesサービスはいくつかのポッドの集まりであり、1ティアまたはマルチティアのアプリケーションと協調して動作する。サービスを構成する複数のポッドは、ラベルセレクターを用いて定義される[38]。Kubernetesはサービスディスカバリーの手段として、環境変数を用いるモードと、Kubernetes DNSを用いるモードの2種類の方法を提供している[62]。サービスディスカバリは、静的なIPアドレスとDNS名を各サービスに束縛させ、そのIPアドレスのネットワークコネクションに対して、セレクターにマッチしたポッド間でラウンドロビン方式でのロードバランシングを行う（セレクターを用いるのは、障害によりポッドがあるマシンから別のマシンに移動したとしても動作するようにするためである）[63]。デフォルトでは、サービスはクラスタの内部にのみ公開されている（たとえば、バックエンド用のポッドは、ロードバランシングされた複数のフロントエンド用ポッドからのリクエストに対して、1つのサービスとしてグループ化されているかもしれない）が、サービスはクラスターの外部に公開することもできる（たとえば、外部のクライアントがフロントエンド用ポッドにアクセスする場合など）[64]。

ボリューム

Kubernetesコンテナ内のファイルシステムは、デフォルトでは一時ストレージを提供する。つまり、コンテナを再起動すると内部のデータが削除されてしまうため、重要なアプリケーションで利用するには制限がある。Kubernetesボリュームは永続的なストレージを提供するため、コンテナが再起動しても、ポッドが生存している間はデータが削除されない。このストレージは、同じポッド内のコンテナ同士で共有ディスク空間としても利用可能である。ボリュームは、ポッドの設定ファイル上で定義したコンテナ内の特定のマウントポイントとしてマウントされ、それ以外のボリュームにマウントしたり、他のボリュームとリンクすることができないようになっている。ただし、同じボリュームでも、異なるコンテナであれば、ファイルシステムツリー上の別の場所にマウントすることは可能である。

ConfigMapsとsecrets

アプリケーションの共通の課題は、設定情報をどこに保存し、管理するかを決めることである。その中には、シークレットデータを含むものもある。コンフィグレーションデータは、個々のプロパティのような細かいものから、コンフィグレーションファイル全体やJSON/XMLドキュメントのような粗い粒度の情報まで、何でもあり得る。Kubernetesはこのニーズに対応するために、密接に関連する2つのメカニズムを提供する。「configmaps」と「secrets」で、どちらもアプリケーションのビルドを必要とせずに設定を変更できるようになっている。コンフィグマップとシークレットのデータは、デプロイメントを通じてこれらのオブジェクトがバインドされているアプリケーションのすべてのシングルインスタンスで利用できるようになる。シークレットおよび/またはコンフィグマップは、そのノード上のポッドがそれを必要とする場合にのみ、ノードに送信される。Kubernetes はそれをそのノード上のメモリに保持する。シークレットまたはコンフィグマップに依存するポッドが削除されると、バインドされたすべてのシークレットとコンフィグマップのインメモリコピーも削除される。データは、a）環境変数として（ポッドの起動時にKubernetesによって作成される）、またはb）ポッド内からのみ見えるコンテナファイルシステムで利用できる、という2つの方法のいずれかによってポッドからアクセス可能である。

データ自体は、誰もログインアクセスできない高度にセキュアなマシンであるマスターに保存される。シークレットとコンフィグマップの最大の違いは、シークレットのデータの内容がbase64エンコードされていることである。最近のKubernetesのバージョンでは、暗号化も使用できるようにサポートが導入されている。シークレットは、証明書、イメージレジストリと連携するための認証情報、パスワード、sshキーなどのデータを保存するためによく使用される。

StatefulSets

ステートレス・アプリケーションのスケーリングは、実行中のポッドを追加するだけで済む。ステートフルなワークロードは、ポッドを再起動しても状態を保持する必要があるため、より困難である。アプリケーションをスケールアップまたはスケールダウンする場合、状態を再分配する必要があるかもしれない。データベースは、ステートフルなワークロードの一例である。高可用性モードで実行する場合、多くのデータベースには、プライマリインスタンスとセカンダリインスタンスという概念が備わっている。この場合、インスタンスの順序という概念が重要になる。Apache Kafkaのようなアプリケーションは、データをブローカーに分散させる。この場合、インスタンスの一意性という概念が重要になる。

StatefulSets[65]は、Podのインスタンス間で一意性と順序付けのプロパティを強制するコントローラ（上記参照）であり、ステートフルなアプリケーションを実行するために使用することができる。

レプリケーションコントローラとデプロイメント

ReplicaSetは必要なPodのインスタンス数を宣言し、Replication Controllerは稼働中の健全なPodの数がReplicaSetで宣言された（セレクタの評価により決定された）数と一致するようシステムを管理する。

デプロイメントはReplicaSetの上位の管理機構である。Replication Controller が ReplicaSet のスケールを管理するのに対し、ReplicaSet に発生すること（更新をロールアウトする必要があるか、ロールバックする必要があるかなど）は、デプロイメントによって管理される。デプロイメントがスケールアップまたはスケールダウンすると、ReplicaSetの宣言が変更されることになり、この宣言状態の変更はレプリケーションコントローラによって管理される。

ラベルとセレクター

Kubernetesは、ポッドやノードなどのシステム上のあらゆるAPIオブジェクトに対して、クライアント（ユーザーや内部のコンポーネント）が「ラベル」と呼ばれるキーバリューペアを付加できるようにしている。それに対応して、「ラベルセレクター」はラベルに対してクエリーを実行し、一致するオブジェクトに解決する[38]。あるサービスを定義すると、サービスルーターやロードバランサーがトラフィックをルーティングするポッドインスタンスを選択するために使用する、ラベルセレクターを定義できるようになる。したがって、単にポッドのラベルやサービスのラベルセレクターを変更するだけで、どのポッドにトラフィックを送るかを制御することが可能になる。この方法により、ブルー・グリーンデプロイ（英語版）やABテストなど、さまざまなデプロイパタンを利用できる。このようなサービスが使用するリソースを動的にコントロールする機能のおかげで、インフラ内での疎結合が実現されている。

たとえば、あるアプリケーションのpodsがシステムtier（たとえば、front-end、back-endなどの値を持つ）とrelease_track（canaryやproductionなど）というラベルを持つとき、back-endかつcanaryであるノード全てを指定するには、以下のようなラベルセレクターが使える[66]。

tier=back-end AND release_track=canary

ラベルと同様に、フィールドセレクターもKubernetesの任意のリソースを選択可能にするものである。ラベルとは異なり、選択は、ユーザーが定義したカテゴリではなく、リソースに予め付与される属性の値に基づいて行われる。metadata.nameやmetadata.namespaceは、すべてのKubernetesオブジェクトに存在するフィールドセレクターである。使用される他のセレクターは、オブジェクトやリソースのタイプによって異なる。

アドオン

アドオンは、クラスタ内で他のアプリケーションと同じ方法で実行される。すなわち、同じようにポッドとサービスとして実装されるが、Kubernetesクラスタの機能を実装しているという点に違いがある。ポッド群は、DeploymentsやReplicationControllersなどによって管理されることもある。多数のアドオンが存在し、その数は増え続けている。以下に、重要なアドオンの種類の一部を挙げる。

  • DNS: すべてのKubernetesクラスタはクラスタDNSを保つ必要があり、これは必須の機能となっている。クラスタDNSはDNSサーバーの一種で、自分の環境内にある他のDNSサーバーに加えて、KubernetesサービスのDNSレコードを保持する。Kubernetesが起動したコンテナには、DNSの検索対象サーバーとして、このDNSサーバーが自動的に追加される。
  • ウェブUI: これは一般の目的に使用されるKubernetesクラスタに対するウェブベースのUIである。クラスタ上で実行中のアプリケーションやクラスタ自体の管理やトラブルシューティングに利用できる。
  • コンテナのリソースモニター: 信頼性の高いアプリケーションランタイムを提供し、ワークロードに応じてスケールアップ・ダウンを可能にするためには、継続的かつ実際的なワークロード性能のモニタリングが必要とされる。コンテナのリソースモニターを使用すれば、中央のデータベースにコンテナのメトリクスを記録することができ、また、このデータを閲覧するためのUIも提供される。cAdvisorは、スレーブノード上のコンポーネントの1つであり、一部の指標の計測機能はすでに提供している。完全な指標パイプラインを提供するものとしては、Prometheusなどがあり、これを利用することで、ほとんどのモニタリング要求が満たされる。
  • コンテナコスト監視: Kubernetesのコスト監視アプリは、ポッド、ノード、ネームスペース、ラベルごとにコストを分解することができる。追跡すべき3つの重要なメトリクスは、日々のクラウド費用、プロビジョニングおよび要求されたCPUあたりのコスト、過去のコスト配分である[67]。
  • クラスタレベルでのロギング: ログは独立したストレージに格納され、ノード・ポッド・コンテナとは異なる独立のライフサイクルを持つ。そうでなければ、ノードやポッドの障害によりイベントデータが失われてしまう可能性がある。こうした機能はクラスタレベルロギングと呼ばれ、コンテナのログを中央のログストアに格納し、検索・閲覧インターフェイスを提供する責務を持つ。Kubernetes自体がログデータを保存するネイティブのストレージ手段を提供しているが、多数存在する既存のログサービスをKubernetesクラスタに統合するためのアドオンも存在する。

ストレージ

コンテナは、ソフトウェアをポータブルにするための方法として登場した。コンテナには、サービスを実行するために必要なすべてのパッケージが含まれている。提供されるファイルシステムによって、コンテナは非常にポータブルになり、開発で使用するのが容易になる。コンテナを開発環境からテスト環境、あるいは本番環境に移行する際、設定を全く、あるいは比較的わずかしか変更することなく移行することができる。

歴史的にKubernetesはステートレスなサービスにのみ適していた。しかし、多くのアプリケーションはデータベースを持ち、永続性を必要とするため、Kubernetesのための永続的ストレージの作成につながった。コンテナ用の永続的ストレージの実装は、Kubernetesの管理者、DevOps、クラウドのエンジニアの最重要課題の1つである。コンテナは刹那的かもしれないが、そのデータはそうでないものが増えているため、コンテナの終了やハードウェアの故障に備えて、データの生存を保証する必要がある。Kubernetesやコンテナ型アプリケーションでコンテナを展開する場合、企業はしばしば永続的なストレージが必要であることに気付く。データベースやルートイメージ、コンテナで使用するその他のデータ用に、高速で信頼性の高いストレージを提供する必要があるのである。

Cloud Native Computing Foundation (CNCF)は、Kubernetes Persistent Storageに関する情報を公開しており、コンテナ接続型ストレージのパターンを定義するブログもある。このパターンは、Kubernetes自体をストレージシステムまたはサービスのコンポーネントとして使用するものと考えることができる[68]。

これらのアプローチやその他のアプローチの相対的な人気についての詳細は、CNCFの景観調査でも確認でき、2019年秋の時点で最も評価されているプロジェクトは、MayaDataのOpenEBSとストレージオーケストレーションプロジェクトのRookの2つであることが示されている[69]。

Container Attached Storageは、Kubernetesが注目されるにつれて登場したデータストレージの一種である。Container Attached Storageのアプローチまたはパターンは、特定の機能をKubernetes自体に依存しながら、Kubernetes上で動作するワークロードに主にブロック、ファイル、オブジェクト、インターフェイスを提供するものである[70]。

Container Attached Storageの一般的な特性として、カスタムリソース定義などのKubernetesの拡張機能の使用や、そうでなければストレージやデータ管理のために別途開発・デプロイされるであろう機能にKubernetes自体を使用することが挙げられる。カスタムリソース定義やKubernetes自体によって提供される機能の例としては、Kubernetes自体によって提供される再試行ロジックや、通常カスタムリソース定義を介して提供される、利用可能なストレージメディアとボリュームのインベントリの作成と保守がある[71][72]。

コンテナ・ストレージ・インターフェース（CSI）

Kubernetesバージョン1.9では、コンテナ・ストレージ・インターフェース（CSI）の最初のアルファリリースが導入された[73]。以前は、ストレージボリュームのプラグインがKubernetesのディストリビューションに含まれていた。標準化されたCSIを作成することで、外部ストレージシステムとのインターフェースに必要なコードは、Kubernetesのコアコードベースから切り離された。ちょうど1年後、KubernetesでCSI機能が一般に利用可能になった（GA）[74]。

API

Kubernetesのコントロールプレーンの重要なコンポーネントはAPI Serverで、クラスタの他の部分だけでなく、エンドユーザーや外部のコンポーネントからも呼び出せるHTTP APIを公開している。このAPIはREST APIであり、宣言的な性質を持っている。APIリソースには2種類ある。Kubernetes APIのAPIリソースの大半はオブジェクトである。これらはポッドやネームスペースのようなクラスタ上の概念の具体的なインスタンスを表する。少数のAPIリソースタイプは「仮想」である。これらはオブジェクトではなくオペレーションを表し、例えば "subjectaccessreviews "リソースを使ったパーミッションチェックのようなものである。オブジェクトに対応するAPIリソースは、クラスタ内でオブジェクトの一意な識別子で表現される。仮想リソースは一意な識別子を持たない。

オペレーター

Kubernetesはカスタムリソースを使用して拡張することができる。これらのAPIリソースは、標準のKubernetesに含まれないオブジェクトを表する。これらのリソースは、動的な登録によって実行中のクラスターに現れたり消えたりすることができる。クラスタ管理者は、クラスタから独立してカスタムリソースを更新することができる。

カスタムコントローラーは、別の拡張メカニズムである。これらはカスタムリソースと相互作用し、Kubernetes自体の設計方法に沿ったカスタムリソースのライフサイクル管理を可能にする真の宣言型APIを実現する。カスタムリソースとカスタムコントローラーの組み合わせは、しばしば(Kubernetes) オペレーターと呼ばれることがある。オペレーターの主なユースケースは、サービスまたはサービスのセットを管理している人間のオペレーターの目的を捉え、自動化を使用して実装することであり、この自動化をサポートする宣言的なAPIを備えている。特定のアプリケーションやサービスを管理する人間のオペレーターは、システムがどのように動作すべきか、どのように展開するか、問題が発生した場合にどのように対応するかについて深い知識を持っている。オペレーターが解決する問題の例としては、アプリケーションの状態のバックアップの取得と復元、データベーススキーマや追加の構成設定などの関連する変更と一緒にアプリケーションコードのアップグレードを処理することなどがある。

クラスタAPI

Kubernetesクラスタをプログラム的に作成、設定、管理するためのAPIを定義するために、同じAPI設計原則が使用されている。これはクラスタAPIと呼ばれる。このAPIで具現化されたキーコンセプトは、Infrastructure as Softwareの使用、つまりKubernetesクラスタインフラストラクチャはそれ自体がリソース/オブジェクトであり、他のKubernetesリソースと同様に管理できるという考え方である。同様に、クラスタを構成するマシンもKubernetesのリソースとして扱われる。APIは、コアAPIとプロバイダ実装の2つで構成されている。プロバイダ実装は、Kubernetesがクラウドプロバイダのサービスやリソースとうまく統合された形でクラスタAPIを提供するための、クラウドプロバイダ固有の機能で構成されている。

利用

Kubernetesは、マイクロサービスベースの実装をホストする方法として一般的に利用される。なぜなら、Kubernetesとそれに関連するツールのエコシステムは、あらゆるマイクロサービスアーキテクチャの主要な懸念に対処するために必要なすべての機能を提供するからである。オープンソース、商用、マネージドという3つの形態で提供されている。オープンソースのディストリビューションには、オリジナルのKubernetes、Amazon EKS-D、Red Hat OpenShift、VMware Tanzu、Mirantis Kubernetes Engine、およびD2iQ Kubernetes Platformが含まれる。マネージドでは、GKE、Oracle Container Engine for Kubernetes、Amazon Elastic Kubernetes Service、IBM Kubernetes Service、Platform9 Managed Kubernetesなどがある[75]。

ディストリビューション

さまざまなベンダーがKubernetesベースのプラットフォームや、KubernetesをデプロイするIaaS（Infrastructure as a Service）を提供している[76][77]。

これらには以下のようなものがある。

  • Alibaba Cloud ACK (Alibaba Cloud Container Service for Kubernetes)
  • Amazon EKS (Elastic Kubernetes Service)
  • Canonical MicroK8s and Charmed Kubernetes
  • DigitalOcean managed Kubernetes Service
  • Google GKE (Google Kubernetes Engine)
  • IBM Cloud Kubernetes Services
  • Microsoft AKS (Azure Kubernetes Services)
  • Mirantis K0s
  • Oracle Container Engine for Kubernetes
  • Rafay Kubernetes Operations Platform
  • Red Hat OpenShift
  • SUSE Rancher, Rancher Kubernetes Engine (RKE)
  • VMware Tanzu

出典

[脚注の使い方]
  1. ^ “First GitHub commit for Kubernetes”. github.com (2014年6月7日). 2017年3月1日時点のオリジナルよりアーカイブ。2018年6月5日閲覧。
  2. ^ “入門Kubernetes（クバネティス）”. オーム社. 2019年2月28日閲覧。
  3. ^ Tenable (2017-07-20), How Do You Pronounce Kubernetes? And What Is It?, https://www.youtube.com/watch?v=uMA7qqXIXBk 2018年5月26日閲覧。 
  4. ^ 阿久津良和 (2017年10月25日). “MS、KubernetesをサポートするAzure Container Serviceの改善を発表”. マイナビニュース. 2018年1月24日閲覧。
  5. ^ “What is Kubernetes?”. Kubernetes. 2017年3月31日閲覧。
  6. ^ “kubernetes/kubernetes” (英語). GitHub. 2017年4月21日時点のオリジナルよりアーカイブ。2017年3月28日閲覧。
  7. ^ “What is Kubernetes?”. Kubernetes. 2017年3月31日閲覧。
  8. ^ “Overview Kubernetes” (英語). Kubernetes. 2023年1月8日時点のオリジナルよりアーカイブ。2022年1月4日閲覧。
  9. ^ “Container runtimes” (英語). Kubernetes. 2021年11月14日閲覧。
  10. ^ “What is the correct pronunciation of Kubernetes in English?”. kubernetes/kubernetes:Issues. GitHub. 2018年2月5日閲覧。
  11. ^ “Kubernetes - New Testament Greek Lexicon - New American Standard”. New Testament Greek Lexicon. JupiterImages Co.. 2018年2月5日閲覧。
  12. ^ “What is Kubernetes?”. Kubernetes. 2017年3月31日閲覧。
  13. ^ “Google Made Its Secret Blueprint Public to Boost Its Cloud” (英語). 2016年7月1日時点のオリジナルよりアーカイブ。2016年6月27日閲覧。
  14. ^ “Google Open Sources Its Secret Weapon in Cloud Computing”. Wired. 2015年9月10日時点のオリジナルよりアーカイブ。2015年9月24日閲覧。
  15. ^ Abhishek Verma; Luis Pedrosa; Madhukar R. Korupolu; David Oppenheimer; Eric Tune; John Wilkes (April 21–24, 2015). “Large-scale cluster management at Google with Borg”. Proceedings of the European Conference on Computer Systems (EuroSys). オリジナルの2017-07-27時点におけるアーカイブ。. https://research.google.com/pubs/pub43438.html. 
  16. ^ “Borg, Omega, and Kubernetes - ACM Queue”. queue.acm.org. 2016年7月9日時点のオリジナルよりアーカイブ。2016年6月27日閲覧。
  17. ^ “Early Stage Startup Heptio Aims to Make Kubernetes Friendly”. http://www.eweek.com/cloud/early-stage-startup-heptio-aims-to-make-kubernetes-friendly.html 2016年12月6日閲覧。 
  18. ^ Abhishek Verma; Luis Pedrosa; Madhukar R. Korupolu; David Oppenheimer; Eric Tune; John Wilkes (April 21–24, 2015). “Large-scale cluster management at Google with Borg”. Proceedings of the European Conference on Computer Systems (EuroSys). オリジナルの2017-07-27時点におけるアーカイブ。. https://web.archive.org/web/20170727090712/https://research.google.com/pubs/pub43438.html. 
  19. ^ “As Kubernetes Hits 1.0, Google Donates Technology To Newly Formed Cloud Native Computing Foundation”. TechCrunch. 2015年9月23日時点のオリジナルよりアーカイブ。2015年9月24日閲覧。
  20. ^ “Release v1.0: Merge pull request #277 from jackgr/master · helm/helm” (英語). GitHub. 2021年5月16日閲覧。
  21. ^ “Helm (package manager) - wikieduonline”. www.wikieduonline.com. 2021年5月16日閲覧。
  22. ^ “Helm” (英語). helm.sh. 2021年5月16日閲覧。
  23. ^ “VMware and Pivotal Launch Pivotal Container Service (PKS) and Collaborate with Google Cloud to Bring Kubernetes to Enterprise Customers” (2017年8月29日). 2022年8月6日閲覧。
  24. ^ Lardinois, Frederic (2017年9月6日). “Mesosphere adds Kubernetes support to its data center operating system”. 2022年8月6日閲覧。
  25. ^ “Docker Announces Enhancements to the Docker Platform to Simplify and Advance the Management of Kubernetes for Enterprise IT” (2017年10月17日). 2020年9月26日時点のオリジナルよりアーカイブ。 Template:Cite webの呼び出しエラー：引数 accessdate は必須です。
  26. ^ Monroy, Gabe (2017年10月24日). “Introducing AKS (managed Kubernetes) and Azure Container Registry improvements”. 2022年8月6日閲覧。
  27. ^ “Introducing Amazon Elastic Container Service for Kubernetes (Preview)” (2017年11月29日). 2022年8月6日閲覧。
  28. ^ Conway, Sarah. “Kubernetes Is First CNCF Project To Graduate” (html) (英語). Cloud Native Computing Foundation. 2018年10月29日時点のオリジナルよりアーカイブ。2018年12月3日閲覧。 “Compared to the 1.5 million projects on GitHub, Kubernetes is No. 9 for commits and No. 2 for authors/issues, second only to Linux.”
  29. ^ “Kubernetes version and version skew support policy”. Kubernetes. 2020年3月3日閲覧。
  30. ^ “Kubernetes 1.19 Release Announcement > Increase Kubernetes support window to one year”. Kubernetes (2020年8月26日). 2020年8月28日閲覧。
  31. ^ “Kubernetes v1.12: Introducing RuntimeClass”. kubernetes.io (2018年10月10日). Template:Cite webの呼び出しエラー：引数 accessdate は必須です。
  32. ^ “Don't Panic: Kubernetes and Docker” (英語). Kubernetes Blog (2020年12月2日). 2020年12月22日閲覧。
  33. ^ “Introducing Container Runtime Interface (CRI) in Kubernetes” (英語). Kubernetes (2016年12月19日). 2021年5月16日閲覧。
  34. ^ “kubernetes/community” (英語). GitHub. 2021年5月16日閲覧。
  35. ^ “Updated: Dockershim Removal FAQ”. Kubernetes Blog (2022年2月17日). Template:Cite webの呼び出しエラー：引数 accessdate は必須です。
  36. ^ “Autoscaling based on CPU/Memory in Kubernetes—Part II”. Powerupcloud Tech Blog. Medium (2017年4月13日). 2018年12月27日閲覧。
  37. ^ “Configure Kubernetes Autoscaling With Custom Metrics”. Bitnami. BitRock (2018年11月15日). 2018年12月27日閲覧。
  38. ^ a b c d “An Introduction to Kubernetes”. DigitalOcean. 2015年10月1日時点のオリジナルよりアーカイブ。2015年9月24日閲覧。
  39. ^ “An Introduction to Kubernetes”. DigitalOcean. 2015年10月1日時点のオリジナルよりアーカイブ。2015年9月24日閲覧。
  40. ^ “Kubernetes Infrastructure”. OpenShift Community Documentation. OpenShift. 2015年7月6日時点のオリジナルよりアーカイブ。2015年9月24日閲覧。
  41. ^ “Kubernetes Infrastructure”. OpenShift Community Documentation. OpenShift. 2015年7月6日時点のオリジナルよりアーカイブ。2015年9月24日閲覧。
  42. ^ Container Linux by CoreOS: Cluster infrastructure
  43. ^ a b c “An Introduction to Kubernetes”. DigitalOcean. 2015年10月1日時点のオリジナルよりアーカイブ。2015年9月24日閲覧。
  44. ^ a b Marhubi, Kamal (2015年9月26日). “Kubernetes from the ground up: API server”. kamalmarhubi.com. 2015年10月29日時点のオリジナルよりアーカイブ。2015年11月2日閲覧。
  45. ^ Ellingwood, Justin (2018年5月2日). “An Introduction to Kubernetes” (英語). DigitalOcean. 2018年7月5日時点のオリジナルよりアーカイブ。2018年7月20日閲覧。 “One of the most important master services is an API server. This is the main management point of the entire cluster as it allows a user to configure Kubernetes' workloads and organizational units. It is also responsible for making sure that the etcd store and the service details of deployed containers are in agreement. It acts as the bridge between various components to maintain cluster health and disseminate information and commands.”
  46. ^ “The Three Pillars of Kubernetes Container Orchestration - Rancher Labs”. rancher.com (2017年5月18日). 2017年6月24日時点のオリジナルよりアーカイブ。2017年5月22日閲覧。
  47. ^ a b “Overview of a Replication Controller”. Documentation. CoreOS. 2015年9月22日時点のオリジナルよりアーカイブ。2015年11月2日閲覧。
  48. ^ Sanders, Jake (2015年10月2日). “Kubernetes: Exciting Experimental Features”. Livewyer. 2015年10月20日時点のオリジナルよりアーカイブ。2015年11月2日閲覧。
  49. ^ “Intro: Docker and Kubernetes training - Day 2”. Red Hat (2015年10月20日). 2015年10月29日時点のオリジナルよりアーカイブ。2015年11月2日閲覧。
  50. ^ “Container Runtimes” (英語). Kubernetes. 2023年2月13日閲覧。
  51. ^ Marhubi, Kamal (2015年8月27日). “What [.. is a Kubelet?]”. kamalmarhubi.com. 2015年11月13日時点のオリジナルよりアーカイブ。2015年11月2日閲覧。
  52. ^ “Kubernetes Security | Issues and Best Practices | Snyk” (英語). snyk.io (2020年7月26日). 2021年5月16日閲覧。
  53. ^ https://kubernetes.io/blog/2016/07/rktnetes-brings-rkt-container-engine-to-kubernetes/
  54. ^ “Namespaces”. kubernetes.io. Template:Cite webの呼び出しエラー：引数 accessdate は必須です。
  55. ^ “Pods”. kubernetes.io. Template:Cite webの呼び出しエラー：引数 accessdate は必須です。
  56. ^ “An Introduction to Kubernetes”. DigitalOcean. 2015年10月1日時点のオリジナルよりアーカイブ。2015年9月24日閲覧。
  57. ^ Langemak, Jon (2015年2月11日). “Kubernetes 101 – Networking”. Das Blinken Lichten. 2015年10月25日時点のオリジナルよりアーカイブ。2015年11月2日閲覧。
  58. ^ Strachan, James (2015年5月21日). “Kubernetes for Developers”. Medium (publishing platform). 2015年9月7日時点のオリジナルよりアーカイブ。2015年11月2日閲覧。
  59. ^ “DaemonSet”. kubernetes.io. Template:Cite webの呼び出しエラー：引数 accessdate は必須です。
  60. ^ “ReplicaSet” (英語). kubernetes.io. 2020年3月3日閲覧。
  61. ^ “Deployments, ReplicaSets, and pods”. IBM. Template:Cite webの呼び出しエラー：引数 accessdate は必須です。
  62. ^ https://kubernetes.io/docs/concepts/services-networking/service/#discovering-services
  63. ^ Langemak, Jon (2015年2月11日). “Kubernetes 101 – Networking”. Das Blinken Lichten. 2015年10月25日時点のオリジナルよりアーカイブ。2015年11月2日閲覧。
  64. ^ Langemak, Jon (2015年2月15日). “Kubernetes 101 – External Access Into The Cluster”. Das Blinken Lichten. 2015年10月26日時点のオリジナルよりアーカイブ。2015年11月2日閲覧。
  65. ^ “StatefulSets”. kubernetes.io. 2023年2月4日閲覧。
  66. ^ “Intro: Docker and Kubernetes training - Day 2”. Red Hat (2015年10月20日). 2015年10月29日時点のオリジナルよりアーカイブ。2015年11月2日閲覧。
  67. ^ “Plug-and-Play Cloud Cost Monitoring for Kubernetes” (英語). CAST AI (2022年6月20日). 2022年12月14日閲覧。
  68. ^ “Container Attached Storage: A primer” (英語). Cloud Native Computing Foundation (2018年4月19日). 2021年5月16日閲覧。
  69. ^ “CNCF SURVEY 2019”. cncf.io. Template:Cite webの呼び出しエラー：引数 accessdate は必須です。
  70. ^ “Container Attached Storage: A primer” (英語). Cloud Native Computing Foundation (2018年4月19日). 2020年10月9日閲覧。
  71. ^ “Container Attached Storage | SNIA”. www.snia.org. 2020年10月9日閲覧。
  72. ^ “Cloud Native Application Checklist: Cloud Native Storage” (英語). www.replex.io. 2020年10月9日閲覧。
  73. ^ “Introducing Container Storage Interface (CSI) Alpha for Kubernetes”. kubernetes.io (2018年1月10日). Template:Cite webの呼び出しエラー：引数 accessdate は必須です。
  74. ^ “Container Storage Interface (CSI) for Kubernetes GA”. kubernetes.io (2019年1月15日). Template:Cite webの呼び出しエラー：引数 accessdate は必須です。
  75. ^ “5 Cloud Native Trends to Watch out for in 2022” (英語). The New Stack (2022年1月3日). 2022年2月3日閲覧。
  76. ^ “The 7 Most Popular Kubernetes Distributions” (英語). 2021年12月28日閲覧。
  77. ^ MSV, Janakiram. “Why Kubernetes Developer Ecosystem Needs A PaaS” (英語). Forbes. 2021年5月16日閲覧。

外部リンク

「https://ja.wikipedia.org/w/index.php?title=Kubernetes&oldid=93857129」から取得