Kubernetesとは？詳しく解説します

TOP
コラム
Kubernetesとは？詳しく解説

概要

ここでは、Kubernetesについて説明させていただきます。
Kubernetesは開発者がアプリケーションを自己修復環境に簡単にデプロイできるようにするコンテナーオーケストレーションツールです。もともとGoogleによって開発され、現在はCloud Native Computing Foundationによって管理されているオープンソースシステムです。 Kubernetesは、コンテナー化されたアプリケーションのデプロイ、スケーリング、および管理の自動化に役立つコンテナーオーケストレーションシステムとして機能します。

Kubernetesの主な目的は、ホストのクラスター間で分散アプリケーションを管理するためのプラットフォームを提供することです。また、サービスディスカバリ、負荷分散、エンドツーエンドのアプリケーション監視、コンテナとクラスタ内のホストマシンのヘルスチェックなどの機能も提供します。
以上がKubernetesの説明とさせていただきます。

機能

Kubernetesの機能についていくつか説明させていただきます。
Kubernetesはアプリケーションを構成するコンテナーを論理ユニットにグループ化して、管理と検出を容易にします。Kubernetesは、Googleでの実稼働ワークロードを実行してきた経験に基づいて構築されており、コミュニティからの最善のアイデアと実践が組み合わされています。機能を詳しく解説させていただきます。

ロールアウト

機能の一点目が自動化されたロールアウトとロールバックです。
Kubernetesはアプリケーションの正常性を監視しつつ、すべてのインスタンスが同時に強制終了されないようにしながらアプリケーションまたはその構成への変更を段階的にロールアウトします。何か問題が発生した場合、Kubernetesが変更をロールバックすることが可能です。

検出と負荷分散

機能の二点目がサービスの検出と負荷分散です。
慣れないサービス検出メカニズムを使用するようにアプリケーションを変更する必要はありません。 KubernetesはPodに独自のIPアドレスと一連のPodの単一のDNS名を与え、Pod間で負荷を分散できます。アプリケーションでサービス検出にKubernetes APIを使用できるケースでAPIサーバーエンドポイントの場合、サービス内の一連のポッドが変更されるたびに更新されます。非ネイティブアプリケーションの場合、Kubernetesは、アプリケーションとバックエンドPodの間にネットワークポートまたはロードバランサーを配置する方法を提供します。

ストレージ

機能の三点目がストレージのオーケストレーションです。
Kubernetesはローカルストレージ、 GCPやAWSなどのパブリッククラウドプロバイダー、または NFS、iSCSI、Gluster、Ceph、Cinder、Flockerなどのネットワークストレージシステムから選択したストレージシステムを自動的にマウントします。
PersistentVolumeサブシステムは、ストレージの消費方法からストレージの提供方法の詳細を抽象化するAPIをユーザーおよび管理者に提供します。これを行うために、Persistent VolumeとPersistent Volume Claimという2つの新しいAPIリソースを導入し提供しております。

Persistent Volumeは、管理者によってプロビジョニングされた、またはStorage Classesを使用して動的にプロビジョニングされたクラスター内のストレージの一部です。ノードがクラスタリソースであるように、これはクラスタ内のリソースとして機能します。PVはVolumesのようなボリュームプラグインですが、PVを使用する個々のPodから独立したライフサイクルを持っています。このAPIオブジェクトは、NFS、iSCSI、またはクラウドプロバイダー固有のストレージシステムなど、ストレージの実装の詳細をキャプチャします。
Persistent Volume Claimは、ユーザーによるストレージの要求です。 Podはノードリソースを消費し、PVCはPVリソースを消費します。 Podは、特定のレベルのリソース (CPU とメモリ) を要求でき、特定のサイズとアクセスモードも要求できます。たとえば、Read Write Once、Read Only Many、Read Write Manyをマウントできます。

構成管理

三点目がシークレットと構成の管理となります。
Persistent Volume Claimはイメージを再構築することやスタック構成でシークレットを公開することなく、シークレットとアプリケーション構成をデプロイおよび更新します。これらはパスワード、トークン、キーなどの少量の機密データを含むオブジェクトです。このような情報はPod仕様またはコンテナーイメージであり、シークレットを使用するとアプリケーションコードに機密データを含める必要がなくなります。また、それを使用するPodとは別に作成できるため、Podの作成、表示、編集のワークフロー中にシークレットが公開されるリスクが少なくなります。クラスターで実行されるKubernetesとアプリケーションは機密データを不揮発性ストレージに書き込まないようにするなど、シークレットを使用して追加の予防措置を講じることもできます。

バッチ

四点目がバッチとなります。
サービスに加えて、KubernetesはバッチおよびCIワークロードを管理し、必要に応じて失敗したコンテナーを置き換えることができます。 Jobは1つ以上のPodを作成し、指定された数のPodが正常に終了するまでPodの実行を再試行し続けます。正常に完了すると、Jobは正常な完了を追跡します。指定された数の成功した完了に達するとタスクが完了します。削除すると、Jobが作成したPodがクリーンアップされます。一時停止すると、再び再開されるまでアクティブなPodが削除されます。

リソース

五点目がリソースです。
可用性を犠牲にすることなく、リソース要件やその他の制約に基づいてコンテナーを自動的に配置します。これらは重要なワークロードとベストエフォート型のワークロードを組み合わせて使用率を高め、さらに多くのリソースを節約します。Podとコンテナーのリソース管理を指定するとPod、オプションで各リソースの量を指定でき、最も一般的なリソースは、CPUとメモリ (RAM) などです。
また、Pod内のコンテナのリソースリクエストを指定すると、スケジューラーを利用してPodを配置するノードを決定します。コンテナーのリソース制限を指定すると、kubeletはこれらの制限を適用し、実行中のコンテナーが設定した制限を超えてそのリソースを使用できないようにします。kubeletはそのシステムリソースのリクエスト量をそのコンテナーが使用するために予約します。

リソースの種類についても簡単に紹介させていただきます。 CPUとメモリはそれぞれリソースタイプであり、これには基本単位があります。CPUは計算処理を表し、Kubernetes CPUの単位で指定されます。メモリはバイト単位で指定します。Linuxワークロードの場合、ヒュージページリソースを指定できます。ヒュージページは、ノードカーネルがデフォルトのページサイズよりもはるかに大きなメモリブロックを割り当てるLinux固有の機能です。

水平スケーリング

六点目が水平スケーリングです。
水平方向のスケーリングとは、増加した負荷への対応として、より多くのデプロイを行うことです。例えば、Kubernetesの場合、ワークロードのために既に実行されているPodにより多くのリソース (メモリや CPU など) を割り当てることを意味する垂直スケーリングとは異なります。 Kubernetesでは、Horizontal Pod Autoscalerがワークロードリソース、需要に合わせてワークロードを自動的にスケーリングすることを目的としています。 Horizontal Pod Autoscalerは、Kubernetes APIリソースおよびコントローラリソースのおけるコントローラーの動作を決定します。 Kubernetes内で実行される水平ポッド自動スケーリングコントローラーコントロールプレーンは、平均CPU使用率、平均メモリ使用率、または指定したその他のカスタムメトリックなどの観測されたメトリックと一致するように、ターゲット (展開など) の目的のスケールを定期的に調整します。
この水平スケーリングにより簡単なコマンド、UI、またはCPU使用率に基づいて自動的にアプリケーションをスケールアップおよびスケールダウンします。

自己修復

七点目が自己修正です。
失敗したコンテナーを再起動し、ノードが停止したときにコンテナーを置き換えて再スケジュールします。また、ユーザー定義のヘルスチェックに応答しないコンテナーを強制終了し、サービスを提供する準備が整うまでコンテナーをクライアントに通知しません。これらを実現する主要コーポネントであるReplication Controllerについても簡単に説明させていただきます。

Replication Controllerは、指定された数のPodレプリカが常に実行されていることを保証します。つまり、Replication Controllerは、PodまたはPodの同種のセットが常に稼働し、利用可能であることを確認するために機能します。
Podが多すぎる場合、Replication Controllerは余分なPodを終了し、逆に少なすぎる場合、Replication Controllerはより多くのPodを開始します。このように手動で作成されたPodとは異なり、Replication Controllerによって維持されたPodは、障害が発生した場合、削除された場合、または終了した場合に自動的に置き換えられます。これらはカーネルアップグレードなどの中断を伴うメンテナンス後にノードで再作成されます。そのため、アプリケーションで必要なPodが1つだけの場合でも、Replication Controllerを使用する必要があります。Replication Controllerはプロセススーパーバイザーに似ていますが、1つのノードで個々のプロセスを監視する代わりに、Replication Controllerは複数のノードにまたがる複数のPodを監視します。

設計

八点目が設計です。
拡張性を考慮した設計を行う点も特徴で、アップストリームのソースコードを変更せずに、Kubernetesクラスターに機能を追加することができます。Kubernetesは高度な構成と拡張が可能である点が大きな特徴です。その結果、Kubernetesプロジェクトコードのフォークやパッチの提出が必要になることはほとんどありません。カスタマイズのアプローチは、フラグ、ローカル構成ファイル、またはAPIリソースの変更のみを含む構成に大きく分けることができます。
拡張機能には、追加のプログラムまたはサービスの実行が含まれます。拡張機能は、拡張してKubernetesと深く統合するソフトウェアコンポーネントで、これらは新しいタイプと新しい種類のハードウェアをサポートするようにそれを適応させます。 Kubernetesのホストされたインスタンスまたは分散インスタンスを使用します。これらのクラスターには、拡張機能がプリインストールされています。その結果、ほとんどのKubernetesユーザーは拡張機能をインストールする必要がなくなります。

Kubernetesは、クライアントプログラムを作成することによって自動化されるように設計されています。また、Kubernetes APIに対して読み取りおよび書き込みを行うプログラムは、便利な自動化を提供できます。 自動化はクラスター上またはクラスター外で実行できるので、これによって可用性が高く、堅牢な自動化を作成できます。自動化は通常、ホストされたクラスターや管理されたインストールを含む、任意のKubernetesクラスターで機能します。

Kubernetesのコーポネントについて

Kubernetesのコーポネントについて簡単に説明させていただきます。
Kubernetesをデプロイすると、クラスターが作成されます。 Kubernetesクラスターは一連のワーカーマシンで構成されます。ノード、コンテナ化されたアプリケーションを実行します。すべてのクラスターには、少なくとも1つのワーカーノードから構成されております。ワーカーノードはアプリケーションワークロードのコンポーネントです。
コントロールプレーンクラスター内のワーカーノードとPodを管理します。コントロールプレーンは複数のコンピューターで実行され、クラスターは通常複数のノードで実行され、フォールトトレランスと高可用性を提供します。個々のコーポネントについても説明させていただきます。

コントロールプレーン

コントロールプレーンのコンポーネントは、クラスターに関するグローバルな決定 (スケジューリングなど) を行うだけでなく、クラスターイベントの検出と応答 (新しいサーバーの起動など) も行います。
コントロールプレーンコンポーネントは、クラスター内の任意のマシンで実行できます。ただし、セットアップスクリプトは通常、すべてのコントロールプレーンコンポーネントを同じマシン上で開始し、このマシン上でユーザーコンテナーを実行しません。

APIサーバー

APIサーバーはKubernetesの主要なコンポーネントで、これらはコントロールプレーンKubernetes APIを公開する機能をもちます。また、APIサーバーは、Kubernetesコントロールプレーンのフロントエンドとして機能します。
Kubernetes APIサーバーの主な実装はkube-apiserverです。kube-apiserverは、水平方向にスケーリングするように設計されています。これにより、多くのインスタンスをデプロイすることでスケーリングします。 kube-apiserverの複数のインスタンスを実行し、それらのインスタンス間でトラフィックを分散できます。

スケジューラ―

新しく作成されたものを監視するコントロールプレーンコンポーネントは、ポッド割り当てなしノード、実行するノードを選択することができます。
スケジューリングの決定で考慮される要因には、個別および集合的なリソース要件、ハードウェア/ソフトウェア/ポリシーの制約、アフィニティおよび非アフィニティの仕様、データの局所性、ワークロード間の干渉、期限などがあります。

コントローラーマネージャー

コントローラーマネージャーについて説明させていただきます。
それぞれコントローラーは別のプロセスですが、複雑さを軽減するために、すべて単一のバイナリにコンパイルされ、単一のプロセスで実行されます。これらのコントローラーのタイプについても紹介させていただきます。

ノードコントローラーはノードがダウンしたときの通知と応答を担当します。
ジョブコントローラーはタスクを表すJob オブジェクトを監視し、Podを作成してそれらのタスクを完了まで実行します。
エンドポイントコントローラーはエンドポイントオブジェクトを設定します。サービスアカウントとトークンコントローラーは新しい名前空間の既定のアカウントとAPIアクセストークンを作成します。

クラウドコントローラー

クラウドコントローラーについて説明させていただきます。
これらはKubernetesコントロールプレーンクラウド固有の制御ロジックを埋め込むコンポーネントです。クラウドコントローラーマネージャーを使用すると、クラスターをクラウドプロバイダーのAPIにリンクし、そのクラウドプラットフォームと対話するコンポーネントをクラスターのみと対話するコンポーネントから分離できます。
これらはクラウドプロバイダーに固有のコントローラーのみを実行します。オンプレミスでKubernetesを実行している場合、または自分のPC内の学習環境でKubernetesを実行している場合、クラスターにはクラウドコントローラーマネージャーがありません。これらは、論理的に独立したいくつかの制御ループを単一のプロセスとして実行する単一のバイナリに結合します。水平方向にスケーリング (複数のコピーを実行) して、パフォーマンスを向上させたり、障害を許容したりすることができます。

コントローラーはクラウドプロバイダーの依存関係を持つことができますので、簡単にその機能と依存関係について説明させていただきます。
ノードコントローラーはクラウドプロバイダーをチェックして、ノードが応答を停止した後にクラウドでノードが削除されたかどうかを判断します。
ルートコントローラーは基盤となるクラウドインフラストラクチャでルートを設定します。
サービスコントローラーはクラウドプロバイダーのロードバランサーの作成、更新、および削除を行います。

API

Kubernetes APIについての説明と関連する知識について説明させていただきます。
REST APIは、Kubernetesにおいて非常に重要です。 コンポーネント間のすべての操作と通信、および外部ユーザーコマンドは、APIサーバーが処理するREST API呼び出しによって実行され、Kubernetesプラットフォーム内のすべてがAPIオブジェクトとして扱われ、APIに対応するエントリがあります。また、Kubernetes APIリファレンスには、Kubernetesバージョン v1.25のAPIがリストされています。ここから、さらに詳しく解説させていただきます。

アクセス制御

ユーザーは、クライアントライブラリを使用するか、RESTリクエストを作成してKubernetes APIにアクセスします。
人間のユーザーとKubernetesサービスアカウントの両方にAPIアクセスを許可できます。リクエストがAPIに到達するといくつかの段階を経ます。デフォルトでは、Kubernetes APIサーバーはTLSで保護された最初の非localhostネットワークインターフェイスのポート6443でリッスンします。TLSが確立されると、HTTP要求は認証ステップに移動します。
クラスター作成スクリプトまたはクラスター管理者は、1つ以上のAuthenticatorモジュールを実行するようにAPIサーバーを構成します。

アドミッションコントロール

認証と許可を経て重要な点がアドミッションコントロールです。
アドミッションコントロールモジュールは、要求を変更または拒否できるソフトウェアモジュールです。 Authorizationモジュールで使用できる属性に加えて、Admission Controlモジュールは、作成中または変更中のオブジェクトのコンテンツにアクセスできます。
受付コントローラーは、オブジェクトを作成、変更、削除、または接続 (プロキシ) する要求に作用します。アドミッションコントローラーは、オブジェクトを読み取るだけの要求には対応しません。複数の受付コントローラーが構成されている場合は、順番に呼び出されます。認証および認可モジュールとは異なり、アドミッションコントローラモジュールが拒否するとリクエストはすぐに拒否されます。
オブジェクトを拒否するだけでなく、アドミッションコントローラーはフィールドに複雑なデフォルトを設定することもできます。要求がすべてのアドミッションコントローラーを通過すると、対応するAPIオブジェクトの検証ルーチンを使用して検証され、オブジェクトストアに書き込まれます。

バージョン管理

バージョン管理について説明させていただきます。
JSONとProtobufのシリアル化スキーマは、スキーマの変更に関して同じガイドラインに従います。また、APIのバージョン管理とソフトウェアのバージョン管理は、間接的に関連しています。 APIのバージョンが異なると安定性とサポートのレベルも異なりますが、各レベルの概要は次のとおりとなっています。

まず、アルファのレベルについて説明します。
バージョン名にはalphaが含まれます。ソフトウェアにはバグが含まれている場合があり、機能を有効にするとバグが発生する可能性があります。これらの機能はデフォルトで無効になっている場合があります。機能のサポートは、予告なしにいつでも中止される場合があります。 APIは、今後のソフトウェアリリースで予告なしに互換性のない方法で変更される場合があります。 このソフトウェアはバグのリスクが高く、長期的なサポートがないため、短期間のテストクラスターでのみ使用することが推奨されております。
次に、ベータのレベルについて説明します。
バージョン名にはbetaが含まれます。ソフトウェアは十分にテストされており、機能を有効にすることは安全と見なされます。機能はデフォルトで有効になっています。詳細は変更される可能性がありますが、機能のサポートが中止されることはありません。オブジェクトのスキーマおよび/またはセマンティクスは、後続のベータ版または安定版リリースで互換性のない方法で変更される可能性があります。
この場合、移行手順が提供されます。スキーマの変更には、API オブジェクトの削除、編集、および再作成が必要になる場合があります。編集プロセスは単純ではなく、移行には機能に依存するアプリケーションのダウンタイムが必要になる場合があります。
このソフトウェアは、本番環境での使用は推奨されていません。その後のリリースでは、互換性のない変更が導入される可能性があります。個別にアップグレードできる複数のクラスターがある場合は、この制限を緩和できる場合があります。機能の安定したバージョンは、その後の多くのバージョンのリリースされたソフトウェアに表示されます。

まとめ

いかがでしたでしょうか？ Kubernetesについて説明させていただきましたので、参考にしていただけましたら幸いです。