Kubernetes
黒と青の背景
Kubernetesとは

Kubernetesは、アプリケーションのデプロイメント、管理、スケーリングを自動化する、オープンソースのコンテナ・オーケストレーション・プラットフォームです。 Kubernetesが、どのようにコスト効率に優れたクラウドネイティブ開発を実現するかご覧ください。

Kubernetes(別称「k8s」、「kube」)は、 コンテナ化されたアプリケーション

のデプロイメント、管理、スケーリングをスケジューリングして自動化するための コンテナ・オーケストレーション・プラットフォーム です。

Kubernetesは当初、Googleのエンジニアらによって開発され、2014 年にオープンソース化されました。 Google内部で使用された コンテナ・ オーケストレーション ・プラットフォーム 「Borg」の後継にあたります。 Kubernetesは 「操舵手」 または 「パイロット」を意味するギリシャ語です。そのため、 Kubernetesのロゴ  には舵が描かれています(リンクはibm.comの外にあります)。

今日、Kubernetesと、より広範なコンテナ・ エコシステム は、最新のクラウド・インフラストラクチャーとアプリケーションのための基本的な構成要素として、 仮想マシン (VM)に匹敵する、汎用コンピューティングのプラットフォームと エコシステム へと成長を遂げつつあります。 この エコシステム のおかげで、組織は クラウドネイティブ の開発を取り囲む複数のインフラストラクチャーやオーペレーションに関連するタスクや問題に対処する生産性の高い Platform-as-a-Service (PaaS) を配信でき、開発チームがコーディングとイノベーションだけに注力できます。     

次の動画では、Kubernetesに関する基本的なことを紹介しています。

エンタープライズ内のコンテナ-新しいIBMリサーチ・ドキュメント、波のように押し寄せるコンテナの勢い、Kubernetesの採用

ebookを読む(PDF、1.4 MB)


コンテナとは

コンテナ はアプリケーション・ソース・コーロをあらゆる環境でコードを実行するのに必要なすべての オペレーティング・システム (OS)ライブラリーや 依存関係 と組み合わせる、軽量で実行可能なアプリーション・コンポーネントです。

コンテナは、 オペレーティング・システム (OS) 仮想化を提供することで、 プロセスを分離し、各プロセスがアクセスできる  CPU、メモリー、ディスクの量を制御して、複数のアプリケーションがOSの単一インスタンスを共有できるようにします。 コンテナは 仮想マシン (VM)よりも小さく、リソース効率がよく、持ち運びしやすいものなので、現代の クラウドネイティブ ・アプリケーション の 事実上の コンピューティング ・ユニットとなりました。

最近のIBMの調査  (PDF、1.4MB) では、ユーザーはコンテナやそれに関連するテクノロジーを採用したことに結果として、技術面およびビジネス面でいくつかの特定のメリットを享受したと報告しています。 

コンテナ、仮想マシン、従来型インフラストラクチャーの対比

コンテナをITインフラストラクチャーの自動化および抽象化の一連の流れの最新形として理解するほうが、わかりやすいかもしれません。

従来のインフラストラクチャーでは、アプリケーションは物理サーバー上で稼働し、取得可能なすべてのリソースを排他的に使用します。 この場合、1 つのアプリケーションが他のアプリケーションの分までリソースを占有することがないようにと願いながら単一サーバー上で複数のアプリケーションを実行することを選ぶか、リソースの無駄と拡張性の欠如をふまえた上でアプリケーションごとに専用サーバーを割り当てることを選ぶかの、いずれかとなります。

仮想マシン(VM)は、実際のコンピューター・ハードウェアを抽象化したサーバーであり、これにより、ユーザーは単一の物理サーバー上にある複数の VM または複数の物理サーバーをまたがる単一の VM を実行できるようになります。 各VMはそれぞれ固有のOSインスタンスを実行しており、各アプリケーションをそれぞれ固有のVM内に分離できるため、基盤となる同じ物理ハードウェアで実行されているアプリケーション同士が相互に影響し合う可能性が低下します。 VMはリソースをより有効に使用するため、従来のインフラストラクチャーと比べて、規模の拡大がはるかに容易で、コスト効率も高まります。 また、VM は廃棄可能です。アプリケーションを実行する必要がなくなったら、VMを削除すればよいのです。

VM に関するその他の情報については、「仮想マシン:基本ガイド」を参照してください。

コンテナは、この抽象化をより高いレベルに引き上げたものです。具体的には、基礎となる仮想化ハードウェアを共有するだけでなく、基礎となる仮想化された OS カーネルも共有します。 コンテナは、VMと同様に、分離機能、拡張性、廃棄可能性を備えていますが、自身のOSインスタンスのペイロードを維持しないため、VMよりも軽量です(つまり、占有スペースが少なくなります)。 また、コンテナはより優れたリソース効率を実現します。つまり、より多くのアプリケーションをより少ないマシン(仮想マシンと物理マシン)で実行することができ、OSインスタンスの数も少なくてすみます。 コンテナは、デスクトップ、データセンター、クラウド環境の間で、より簡単に移植できます。 また、アジャイルおよび DevOps プラクティスに最適です。

コンテナ: 基本ガイド」では、コンテナとコンテナ化についての説明を網羅しています。 また、「コンテナとVM: その違い」というブログ記事では、違いを列挙してあります。

Dockerとは

Dockerは、Linux®コンテナを作成して実行するために頻繁に利用されているツールです。 コンテナの初期の形式は、数十年前から(FreeBSD JailsやAIX Workload Partitionsなどの技術で)導入されていましたが、2013年に、開発者にとって使いやすく、クラウドで利用しやすい、Dockerの新たな実装が公開されたことで、コンテナは一般に普及していきます。

Dockerはもとはオープンソース・プロジェクトでしたが、今日ではDockerの開発元の会社であるDocker Inc.のことも指します。Dockerとは、オープンソース・プロジェクトを基に構築されている商用のコンテナ・ツールキットです(そして、その改良は、オープンソース・コミュニティーに還元されています)。

Dockerは、従来のLinuxコンテナ(LXC)テクノロジーに基づいて構築されていますが、Linuxカーネル・プロセスのきめの細かい仮想化を可能にするとともに、コンテナの作成、デプロイ、管理、保護をより簡単にする機能を開発者に提供します。

今日、Dockerの代替コンテナ・プラットフォーム(Open Container Initiative(OCI)、CoreOS、Canonical(Ubuntu)LXDなど)は存在するものの、事実上、コンテナと言えばDockerを指すと言っても過言ではないほど、Dockerは非常に広く採用されています。また、Kubernetesなどの無料の技術と誤解されることもあります。詳細は、以下にあるビデオ「KubernetesとDocker:二者択一の関係でないもの」をご覧ください。

Kubernetesを使って統合されたハイブリッド・クラウドとコンテナのための柔軟で回復力のある、安全なITは、ベンダー・ロックインなしに、あらゆる場所からワークロードを構築、管理できるようにするオープン・ハイブリッド・クラウド戦略の一部です。

詳細はこちら


Kubernetesによるコンテナ・オーケストレーション

今日では、組織に数百あるいは数千のコンテナがあることも珍しくありません。コンテナが急増するにつれ、運用チームでは、コンテナのデプロイメント、ネットワーキング、拡張性、可用性をスケジュールし自動化する必要がありました。 それにともない、コンテナ・オーケストレーション市場が登場しました。

初期には、他のコンテナ・オーケストレーション・オプション( 特に、Docker SwarmとApache Mesos)が牽引役を務めましたが、Kubernetesは瞬く間に最も広く採用されるようになりました(実際のところ、一時期、オープンソース・ソフトウェア史上で最も急成長したプロジェクトでした)。

多岐にわたる 機能性、成長し続ける オープン・ソース のサポート・ツールの エコシステム 、 クラウド・サービス ・プロバイダーをサポートし、 移植性 があることを理由に、開発者たちは、Kubernetesを選び続けています。  Amazon Web Services (AWS)、Google Cloud、IBM Cloud、Microsoft Azureなど世界を牽引するすべてのパブリック・ クラウド・プロバイダー は、  管理が徹底した Kubernetes サービスを提供しています。

コンテナ・オーケストレーションの詳細については、「コンテナ・オーケストレーションの説明」動画(08:59)をご覧ください。

Kubernetesでは何ができるのか

Kubernetesは以下に挙げるようなアプリケーションの ライフサイクル中のコンテナ関連のタスクをスケジュールし、 自動化 します。

  • デプロイ: 指定された数のコンテナを指定のホストにデプロイし、それらのコンテナを適切な状態で稼働し続けます。
  • ロールアウト: ロールアウトはデプロイメントに加える変更です。 Kubernetesにより、ロールアウトの開始、一時停止、再開、またはロールバックが可能です。
  • サービスディスカバリー: Kubernetesは DNS 名 または IPアドレスを使用して、コンテナをインターネットまたは他のコンテナに自動で公開できます。
  • ストレージ ・プロビジョニング: 必要に応じてコンテナ用の永続的なローカル・ストレージまたはクラウド・ストレージをマウントするようにKubernetesを設定します。
  • ロード・バランシング:  CPU 使用率または任意の 測定基準に基づき、Kubernetesの ロード・バランシング は、ネットワーク中にワークロードを配信し、パフォーマンスと安定性を維持できます。 
  • 自動スケーリング: トラフィックの急増時にKubernetsの 自動スケーリング は必要に応じて新しいクラスターを展開し、追加のワークロードを取り扱えます。
  •  高可用性 のための自己修復 :コンテナに障害が発生したとき、Kubernetsは ダウンタイムを防ぐために、自動で再開または置換できます。 ヘルス・チェックの要件を満たさないコンテナを削除することもできます。

KubernetesとDocker

ここまで読んできたなら、KubernetesはDocker Swarmに代わるものであるにも関わらず、(よく誤解されがちなこととは違い、)Docker自身に代わるものまたは匹敵するものでないことはすでにご理解いただけたでしょう。

それどころか、Dockerを積極的に採用してDockerベースの大規模なコンテナ・デプロイメントを作成している場合、Kubernetesオーケストレーションは、これらのワークロードを管理するための次のステップとして合理的なものです。 詳細は「KubernetesとDoker:二者択一でないもの」をご覧ください。

注目の製品

Red Hat OpenShift on IBM Cloud

IBM Cloud Satellite

IBM Cloud Code Engine

IBM Cloud Kubernetes Service


Kubernetesアーキテクチャー

Kubernetesアーキテクチャーの主要コンポーネントには、以下のものがあります。

クラスターとノード(コンピュート)

クラスター は、Kubernetesアーキテクチャーのビルディング・ブロックです。 クラスターは ノードで構成され、各ノードは単一の 計算 ホスト(仮想マシンまたは物理マシン)を表します。

各クラスターは、クラスターのコントロール・プランとして機能する マスター・ノード と、コンテナ化された アプリケーションをデプロイ、実行、管理する 複数の ワーカー・ノード で構成されています。 マスター・ノードは、開発者が設定したデプロイメント要件と使用可能なコンピュート能力に基づいて、コンテナをいつどこにデプロイするのかを 自動化する スケジューラー・サービスを実行します。 各ワーカー・ノードには、 Docker などのコンテナの管理に使用されるツールと、マスター・ノードからの命令を受信して実行する Kubelet というソフトウェア・エージェントが含まれています。

開発者は、 Kuvernetes API と直接通信する kubectlという コマンドライン インターフェース(cli)を使用してクラウター運用を管理します。

 Kubernetesクラスターについて深くしるためには、「Kuvernetesクラスター:迅速で制御されたクラウド・アプリ配信のためのアーキテクチャ」」というこのブログ記事を参照してください。

ポッドとデプロイメント(ソフトウェア)

ポッドは、同じコンピュート・リソースと同じネットワークを共有するコンテナのグループです。 それらは、Kubernetes内で拡張性の単位でもあります。ポッド内のコンテナが、取り扱い可能量よりも渋滞してきたら、Kuberenetesはクラスター内の他のノードにポッドを複製します。 このため、リソースを共有する必要があるコンテナのみが含まれるように、ポッドをコンパクトにすることをお勧めします。

デプロイメントは、コンテナ化されたアプリケーションの作成と状態を制御し、それを実行し続けます。 また、クラスター上で実行されるポッドのレプリカの数を指定します。 ポッドに障害が発生した場合、デプロイメントによって新しいポッドが作成されます。

Kubernetesのデプロイの詳細については、「Kubernetesのデプロイ:迅速な開始」をご覧ください。

関連リンク

IBM Cloud Paks


Istioサービス・メッシュ

Kubernetesは、ポッドをデプロイおよび拡大できますが、ポッド間の経路を管理または自動化することはできず、ポッド間の接続を監視、保護、デバッグするツールも提供しません。 クラスター内のコンテナ数が増えるにつれて、それらコンテナ間を結ぶことができるパスの数は飛躍的に増化します(例えば、2つのコンテナに存在し得る接続は2つですが、10個のポッドではそれが90個になります)。これにより、構成と管理が非常に困難になるおそれがあります。

Kubernetesクラスターのオープンソースのサービス・メッシュ・レイヤーであるIstioを入力してください。 各Kubernetesクラスターに対し、Istioは、サイドカー・コンテナを追加します。基本的にこれをプログラマーや管理者が意識することはありません。このサイドカー・コンテナが、他のコンテナ間の対話を構成、監視、管理します。

Istioを使用すると、コンテナ間の接続を構成する単一のポリシーを設定することができ、それぞれの接続を個別に構成する必要がありません。 これにより、コンテナ間の接続をより簡単にデバッグできるようになります。

また、Istioにはダッシュボードが用意されており、DevOpsチームや管理者はダッシュボードを使用して、コンテナ間の接続について、レイテンシー、サービス時間に関するエラー、その他の特性を監視できます。 さらに、Istioにはセキュリティー(具体的には、権限のないユーザーがコンテナ間の サービス呼び出しをスプーフィングできないようにするID管理)と、認証、許可、および監査(AAA)の機能が組み込まれています。これらを使用して、セキュリティーの専門家はクラスターを監視することができます。

Istioの詳細や動画、使用例については、記事「Istioとは」をご覧ください。


Knativeとサーバーレス・コンピューティング

Knative(ケイネイティブ)は、Kubernetes上で稼働するオープンソース・プラットフォームです。クラウドネイティブな開発のために、以下の2つに分類される重要なメリットをもたらします。

Knativeはサーバーレス・コンピューティングへの移行を容易にする

サーバーレス・コンピューティングは、クラウドネイティブ・アプリケーションの効率とコスト効果を高めるコードをデプロイする比較的新しい方法です。 要求の待機中にアイドル状態になっている進行中のインスタンス・コードをデプロイする代わりに、サーバーレスは 必要に応じてコードを起動し(需要の変動に応じてスケールアップまたはスケールダウンさせます)、コードが使用されなくなったら終了させます。 サーバーレスでは、コードが実際に実行された時間に対してのみ課金されるので、コンピューティング容量と電力を節約し、コストを削減できます。

Knativeでは、開発者がコンテナを1度作成すれば、そのコンテナをソフトウェア・サービスまたはサーバーレス機能として実行できます。 Knativeは開発者に対して透過的なものです。Knativeは詳細をバックグラウンドで取り扱い、開発者はコードに焦点を当てられます。

Knativeはコンテナの開発とオーケストレーションを簡素化する

開発者にとって、コードのコンテナ化は多くの反復ステップを要する作業となります。また、コンテナのオーケストレーションには、数多くの構成とスクリプト作成の作業(構成ファイルの生成、依存関係のインストール、ロギングとトレースの管理、継続的なインテグレーション継続的なデプロイメント(CI/CD)スクリプトの記述)も必要となります。

Knativeは、以下の3つのコンポーネントによる自動化によって、これらのタスクをより簡単にします。

  • ビルド: Knativeのビルド・コンポーネントは、 ソースコード を自動的にクラウドネイティブなコンテナまたは関数に変換します。 具体的には、リポジトリーからコードをプルし、必要な 依存関係をインストールして、 コンテナ・イメージをビルドしたうえで、他の開発者が使用できるようにそれをコンテナ・レジストリーに配置します。 Knativeがコンポーネントを検出できるようにするために、開発者はコンポーネントの場所を指定する必要がありますが、一度指定すると、Knativeはビルドを 自動的に 行います。
  • サーブ: サーブ・コンポーネントは拡張可能なサービスとしてコンテナを実行します。サーブ・コンポーネントは 数千 ものコンテナ・インスタンスに拡大したり、0まで縮小( ゼロに基準化と呼ばれています)したりできます。 さらに、サーブには2つの非常に便利な機能があります。 構成はコンテナを実働へと押し出す度にコンテナのバージョンを保存し、( スナップショットと呼ばれています)それらのバージョンを同時に実行できるようにします。 サービス ルーティングは、異なる量のトラフィックをこれらのバージョンへ伝えることを可能とします。 これらの機能を組み合わせて使用すると、コンテナのロールアウトを段階的に実行したり、 コンテナ化されたアプリケーション のカナリア・テストをステージングしたりしてから、コンテナをグローバルな運用に配置できます。
  • イベント: イベントにより、指定されたイベントがコンテナ・ベースのサービスまたは関数をトリガーするようにできます。 これは、特にKnativeの サーバーレス 機能にとって不可欠なものです。ある機能が必要になった場合に、その機能を起動するようシステムに指示する必要があります。 イベントにより、チームは特定のイベント・タイプに対して「興味」を示すことができます。そうすると、イベントがイベント・プロデューサーに自動的に接続してイベントをコンテナにルーティングするので、これらの接続をプログラムする必要がなくなります。

Knaive:基本ガイド」を読むと、Knativeの詳細を学べます。


Kubernetes GitHub のコミットと人気を実証するさらなる証拠

Kubernetesは、オープンソース・プロジェクトの歴史で最も急速な成長を遂げたものの1つであり、この成長はいまも加速しています。 Kubernetesを採用する開発者と企業の間で、採用件数は急増し続けています。 注目すべきデータ・ポイントをいくつか示します。

  • これを書いている時点で、過去18か月で34,000件近くのコミットが増え、120,190件を超えるコミットが GitHub上の Kubernetesレポジトリー (ibm.comへのリンク)上に作成されました。また、プロジェクトへアクティブなコントリビューターは、3,100を超えます  Cloud Native Computing Foundation (CNCF) によりと、すべてのKubernetes関連リポジトリ(Kubernetes DashboardとKubernetes MiniKubeを含む)全体で148,000件を超えるコミットが存在しています。 すべての統計は ここ (ibm.com外へのリンク)を参照してください。
  • 2,000社を超える企業が、自社の実動ソフトウェア・スタックにKubernetesを使用しています。 これには、AirBnB社、Ancestry社、Bose社、CapitalOne社、Intuit社、Nordstrom社、Philips社、Reddit社、Slack社、Spotify社、Tinder社、そして、もちろんIBMなど、世界的に有名な企業が含まれます。 これらとその他の採用事例をお読みください。(ibm.com 外へのリンク)
  • Container Journalで引用された2021年の 調査(ibm.com外へのリンク)によると新型コロナウイルスのパンデミックの最中に、IT専門家の68%はよりKubernetesを使うようになったことが分かりました。
  • ZipRecruiter(ibm.com外へのリンク)によると、Kubernetes関連の職業の平均年俸 (北アメリカ)は147,732米ドルです。 この記事を書いている現時点で、57,000 件を超えるKubernetes関連のポジションがLinkedIn(ibm.com外へのリンク)にリストされていますが、たった18か月前にリストされていたのは21,000件でした。

KubernetesとIBM Cloud

コンテナーは アプリケーションの最新化 と ITインフラストラクチャー最適化に適しています。  KubernetesやオープンソースのKubernetesエコシステム内の他のツールで構築され、IBM Cloudのコンテナー・サービスは クラウドネイティブ アプリケーション開発や、プライベート・クラウド、 パブリック・クラウド 、 オンプレミス のITインフラストラクチャにある優れた機能や関数を統合するオープン・ハイブリッド・クラウド・アプローチへのパスを促進して加速させることができます。

次のステップに進みます:

  •  IBM Cloud上の Red Hat OpenShiftを使用してシングル・クリックをすることで、 一元化されたアプリケーション のための可用性が高く、完全管理されたKubernetesクラスターをデプロイする方法を学びましょう。
  •  IBM Cloud Satelliteを使って、 コンテナ化されたアプリケーション をあらゆるベンダーの オンプレミス、エッジ・コンピューティング、 パブリック・クラウド 環境全体で絶えずデプロイ、管理します。
  •  IBM Code Engineを使って、 コンテナー・イメージ、バッジ・ジョブまたはソース・コードをサーバーレス・ワークロードとして実行します。サイジング、 デプロイ、ネットワーキング、スケーリングは必要とされません。
  • IBM Cloud Kubernetes Serviceを使用するネイティブKubernetesエクスペリエンスで、安全で可用性の高いアプリケーションをデプロイします。

すぐに開始するために、 IBM Cloudアカウントのための サインアップ をします。


関連ソリューション

アプリケーション・モダナイゼーション・ソリューション

信頼性のあるさまざまなクラウドで、アプリケーションを安全に構築、モダナイズ、管理します。


ハイブリッド・インフラストラクチャー・ソリューション

オープンなハイブリッドクラウド戦略を採用すると、ベンダーの囲い込みなしにあらゆる場所でワークロードを構築して管理できます。


ハイブリッドクラウド・ソリューション

オープンで柔軟性のあるセキュアなオンプレミスのインフラストラクチャー・ソリューションを活用してハイブリッドクラウド戦略を引き出します。


Red Hat OpenShift

可用性の高いフルマネージドのクラスターをクリックするだけで展開します。


Cloud Satelliteソリューション

ビジネスや研究の問題解決に役立つデータの洞察を明らかにします。


Code Engineソリューション

完全管理されたコンテナー・ランタイムでコンテナー、アプリケーション・コードまたはバッチ・ジョブを実行します。