Kubernetes とは何ですか?

Kubernetes は、コンテナー化されたワークロードやサービスを複数のホストにわたって管理するためのオープンソース・プラットフォームです。手作業による介入をまったく、あるいはほとんど必要とせずに、コンテナー化アプリのデプロイ、自動化、モニター、スケーリングを行える管理ツールを備えています。

オープンソースプロジェクト「 Kubernetes 」は、コンテナ化されたインフラストラクチャの運用と本番環境のワークロード、オープンソースへの貢献、そして Docker のコンテナ管理ツールを組み合わせたものです。 Kubernetes のインフラストラクチャは、コンテナを管理するための、隔離され安全なアプリケーションプラットフォームを提供します。このプラットフォームは、移植性が高く、拡張性があり、フェイルオーバーが発生した場合でも自己修復機能を備えています。 詳しくは、 Kubernetesとは何ですか?を参照してください。

Kubernetes の主要な概念について、以下の図で説明します。

アカウント

アカウントとは、ご使用の IBM Cloud アカウントを指します。

クラスター、ワーカー・プール、およびワーカー・ノード

Kubernetes クラスターは、マスターと、ワーカー・ノードと呼ばれる 1 つ以上のコンピュート・ホストで構成されます。 ワーカー・ノードは、同じフレーバー (つまり、CPU、メモリー、オペレーティング・システム、接続ディスク、その他のプロパティーからなるプロファイル) のワーカー・プールに編成されます。 ワーカー・ノードは、Kubernetes の Node リソースに対応するもので、Kubernetes マスターによって管理されます。このマスターは、クラスター内のすべての Kubernetes リソースを一元的に制御および監視します。 したがって、コンテナー化アプリのリソースをデプロイする際、これらのリソースをどのワーカー・ノードにデプロイするかは、Kubernetes マスターがデプロイメント要件とクラスターで使用可能な容量を考慮して決定します。 Kubernetes リソースには、サービス、デプロイメント、ポッドが含まれます。

名前空間

Kubernetes 名前空間は、クラスターを複数のチームで共有する場合などに、クラスター・リソースを別々の領域に分割し、それぞれの領域に対してアプリをデプロイしたりアクセスを制限したりできるようにするための手段です。 例えば、お客様のために構成されたシステム・リソースは、kube-system や ibm-system といった別々の名前空間で保持されます。 Kubernetes リソースの作成時に名前空間を指定しない場合、リソースは default 名前空間に自動的に作成されます。

サービス

サービスとは、ポッドのセットをグループ化し、各ポッドの実際のプライベート IP アドレスを公開せずにそれらのポッドへのネットワーク接続を提供する Kubernetes リソースのことです。 サービスを使用することにより、アプリをクラスター内または公開インターネットで使用可能にできます。

デプロイメント

デプロイメントとは、アプリの実行に必要なその他のリソースや機能 (サービス、永続ストレージ、アノテーションなど) に関する情報を指定できる Kubernetes リソースです。 構成 YAML ファイルでデプロイメントを文書化し、それをクラスターに適用します。 Kubernetes マスターがリソースを構成し、使用可能な容量を持つワーカー・ノード上のポッドにコンテナーをデプロイします。

ローリング更新中に追加するポッドの数や、一度に使用不可にできるポッドの数など、アプリの更新戦略を定義します。 ローリング更新の実行時には、デプロイメントによって、更新が動作しているかどうかが確認され、障害が検出されるとロールアウトが停止されます。

デプロイメントは、ポッドを管理するために使用できるワークロード・コントローラーの、1 つのタイプにすぎません。 オプションの選択について詳しくは、どのようなタイプの Kubernetes オブジェクトをアプリ用に作成できますか? を参照してください。 デプロイに関する詳細については、『 Kubernetes 』のドキュメントを参照してください。

ポッド

クラスターにデプロイされたすべてのコンテナー化アプリは、ポッドと呼ばれる Kubernetes リソースによってデプロイ、実行、および管理されます。 ポッドは Kubernetes クラスター内のデプロイ可能な小さいユニットを表し、単一のユニットとして処理される必要があるコンテナーをグループ化するために使用します。 通常、各コンテナーは独自のポッドにデプロイされます。 ただしアプリでは、コンテナーとその他のヘルパー・コンテナーを 1 つのポッドにデプロイすることによって、同じプライベート IP アドレスを使用してそれらのコンテナーをアドレス指定できるようにする必要がある場合もあります。

アプリ

アプリとは、完全に機能する 1 つのアプリ全体を指す場合もありますし、アプリのコンポーネントを指す場合もあります。 アプリのコンポーネントは、別々のポッドまたは別々のワーカー・ノードにデプロイできます。 詳しくは、アプリ・デプロイメントの計画および Kubernetes ネイティブ・アプリの開発を参照してください。

詳細については Kubernetes、 ドキュメント Kubernetes を参照してください。

コンテナーとは

コンテナーとは、アプリケーションのコード、構成、依存関係をひとまとめにしてパッケージ化し、リソースを隔離したプロセスとして、コンピュート・サーバーで実行できるようにするための標準的な手段です。 IBM Cloud でアプリを実行するには、まずアプリをコンテナ化し、コンテナイメージを作成してコンテナレジストリに保存する必要があります。

以下の用語を復習し、概念に慣れましょう。

コンテナー

コンテナとは、アプリとその依存関係をすべてまとめてパッケージ化したもので、これにより、アプリを環境間で移動させても、変更を加えることなく実行することができます。 仮想マシンとは異なり、コンテナーはデバイス、そのオペレーティング・システム、および基礎となるハードウェアを仮想化しません。 アプリのコード、ランタイム、システム・ツール、ライブラリー、設定値のみがコンテナー内にパッケージ化されます。 コンテナは、コンピュートホスト上で独立したプロセスとして実行され、ホストのオペレーティングシステムとそのハードウェアリソースを共有します。 このため、コンテナーは仮想マシンより軽量で移植しやすく、効率的です。

画像

コンテナ・イメージは、コンテナを実行するためのファイル、構成設定、ライブラリを含むパッケージである。 イメージはDockerfileと呼ばれるテキストファイルから構築される。 Dockerfileは、どのようにイメージを構築し、どのアーティファクトをそれに含めるかを定義する。 コンテナに含まれる成果物は、アプリのコード、構成設定、依存関係で構成される。

レジストリ―

イメージ・レジストリーはコンテナー・イメージを格納、取得、共有する場所です。 レジストリは、誰でもアクセスできる公開型と、限られたユーザーグループのみがアクセスできる非公開型のいずれかになります。 エンタープライズアプリケーションに関しては、 IBM Cloud のようなプライベートレジストリを使用して、イメージが権限のないユーザーによって使用されるのを防ぎましょう。

IBM Cloud Kubernetes Service では、どのようなコンピューティングホストインフラストラクチャが提供されていますか？

IBM Cloud® Kubernetes Serviceを使用すると、以下のプロバイダーのインフラストラクチャーを使用してクラスターを作成できます。 1 つのクラスター内のワーカー・ノードはすべて、同じプロバイダーからのものでなければなりません。

このサービスを利用するメリットは何ですか？

コンテナー・プラットフォーム・プロバイダーの選択

• コンテナー・プラットフォーム・オーケストレーターとしてインストールされた Red Hat OpenShift またはコミュニティー Kubernetes を使用して、クラスターをデプロイできます。
• 会社に適した開発者エクスペリエンスを選択するか、Red Hat OpenShift クラスターとコミュニティー Kubernetes クラスターの両方でワークロードを実行できます。
• IBM Cloud コンソールから Kubernetes ダッシュボードまたは Red Hat OpenShift Web コンソールへの組み込み統合。
• Red Hat OpenShift のすべての IBM Cloud クラスターまたはコミュニティー Kubernetes クラスターの単一のビューと管理のエクスペリエンス。

コンピュート、ネットワーク、およびストレージそれぞれのインフラストラクチャーを分離する、単一テナントの Kubernetes クラスター

• 組織の要件に適合する、カスタマイズされた独自のインフラストラクチャーを作成できる。
• インフラプロバイダーの中から選択してください。
• IBM Cloud インフラストラクチャーによって提供されるリソースを使用して、機密保護機能のある専用の Kubernetes マスター、ワーカー・ノード、仮想ネットワーク、そしてストレージをプロビジョンできる。
• クラスターを使用可能にしておくために IBM によって継続的にモニターされて更新される、完全に管理された Kubernetes マスターを利用できる。
• データ、GPU、AI などのコンピュートを集中的に使用するワークロードの場合は、ベアメタル・サーバーを使用してワーカー・ノードをプロビジョンできる。
• 統合されたセキュアなボリューム・サービスによって、永続データを保管し、Kubernetes ポッド間でデータを共有し、必要に応じてデータを復元することができる。
• すべてのネイティブ Kubernetes API をフルサポートすることによる利点。

高可用性を高めるマルチゾーン・クラスター

• ワーカー・プールを使用して、同じフレーバー (CPU、メモリー、仮想または物理) のワーカー・ノードを容易に管理する。
• 選択したマルチゾーンにノードを均等に分散させ、アプリのアンチアフィニティー・ポッド・デプロイメントを使用して、ゾーン障害から保護する。
• 別のクラスタにリソースを重複して維持する代わりに、マルチゾーン・クラスタを利用することで、コストを削減できます。
• クラスターの各ゾーンに自動的にセットアップされるマルチゾーン・ロード・バランサー (MZLB) を使用するアプリの自動ロード・バランシングによる利点。

高可用性のマスター

• クラスターの作成時に自動的にプロビジョンされる高可用性マスターによって、クラスターのダウン時間 (マスターの更新時など) が削減される。
• マルチゾーンクラスタ内の各ゾーンにマスターを分散配置し、ゾーン障害からクラスタを保護してください。

Vulnerability Advisorを使用したイメージ・セキュリティーのコンプライアンス

• セキュリティが確保された Docker のプライベートイメージレジストリに独自のリポジトリを設定し、組織内のすべてのユーザーがイメージを保存・共有できるようにします。
• プライベート IBM Cloud レジストリー内のイメージを自動スキャンすることによる利点。
• イメージ内で使用されるオペレーティング・システムに固有の推奨を確認して、潜在的な脆弱性を修正できる。

クラスターの正常性に関する継続的なモニター

• クラスター・ダッシュボードを使用して、クラスター、ワーカー・ノード、およびコンテナーのデプロイメントの正常性を素早く参照して管理できる。
• IBM Cloud® Monitoring を使用して詳細な使用状況メトリクスを確認し、ワークロードの需要に応じてクラスターを迅速に拡張できます。
• IBM Cloud Logsを使用してロギング情報を参照して、クラスター・アクティビティーの詳細を確認できる。

アプリにパブリック・アクセスできるよう安全に公開する

• インターネットからクラスター内のサービスにアクセスする方法を、パブリック IP アドレス、IBM 提供の経路、独自のカスタム・ドメインの中から選択できる。

IBM Cloud サービスの統合

• IBM Cloud API、Blockchain、データ・サービス、モノのインターネットなどの Watson サービスを統合してアプリに付加的な機能を追加する。

Red Hat OpenShift クラスターと Kubernetes クラスターの比較

Red Hat OpenShift on IBM Cloud と IBM Cloud Kubernetes Service クラスターはどちらも、企業のワークロード向けに調整された実稼働対応のコンテナー・プラットフォームです。 以下の表では、ユースケースに最適なコンテナプラットフォームを選ぶ際に参考となる、いくつかの共通する特徴を比較・対照しています。

関連リソース

Kubernetes の概念と用語を学習する方法を紹介します。

• この コースを修了して、 Kubernetes と IBM Cloud Kubernetes Service がどのように連携して動作するかを学びましょう。