IBM Cloud Kubernetes Service について

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 の概念と用語を学習する方法を紹介します。

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