Kubernetes

menu icon

Kubernetes

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

Kubernetesとは

Kubernetes(別称「k8s」、「kube」)は、コンテナ化されたアプリケーションのデプロイメント、管理、スケーリングをスケジューリングして自動化するためのコンテナ・オーケストレーション・プラットフォームです。

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

今日、Kubernetesと、より広範なコンテナ・エコシステムは、最新のクラウドのインフラストラクチャーとアプリケーションのための基本的な構成要素として、仮想マシン(VM)に匹敵する、汎用コンピューティングのプラットフォームとエコシステムへと成長を遂げています。 このエコシステムを活用することで、組織では、生産性の高いPlatform as a Service(PaaS)の実現が可能となっています。PaaSは、クラウドネイティブ開発を取り巻く、インフラストラクチャーと運用に関連したさまざまなタスクや問題に対処します。これにより、開発チームはコーディングとイノベーションのみに集中できるようになります。     

次の動画では、Sai VennamがKubernetesの基礎を説明します(10:59)。

コンテナとは

まず、その定義を確認しましょう。 コンテナとは、アプリケーション・コードがライブラリーや依存関係と一緒にパッケージ化された、ソフトウェアの実行可能単位です。デスクトップ、従来のIT、クラウド上の、どこでも実行できるように、共通の方法でパッケージ化されます。

コンテナは、オペレーティング・システム(OS)の仮想化を提供することで、プロセスを分離し、各プロセスがアクセスできるCPU、メモリー、ディスクの量を制御して、複数のアプリケーションがOSを共有できるようにします。

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

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

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

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

VMについて詳しくは、「仮想マシン: 基本ガイド」をご覧ください。

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

コンテナ: 基本ガイド」には、コンテナとコンテナ化に関する詳細な説明が記載されています。そしてブログ記事「コンテナとVMの違い(Containers vs. VMs: What's the difference?)」では、両者の相違点がすべて概説されています。

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によるコンテナ・オーケストレーション

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

他のコンテナ・オーケストレーションの選択肢(特にDocker SwarmとApache Mesos)は初めのころはある程度のけん引力を得たものの、Kubernetesがすぐに最も広く採用されるようになっていきました(実際、ある時点では、オープンソース・ソフトウェアの歴史の中で最も急速に成長したプロジェクトとなりました)。

Kubernetesは、その機能の幅広さ、オープンソースをサポートするツールの広大かつ成長し続けるエコシステム、そして主要なクラウド・プロバイダー全体におけるサポートとポータビリティーによって、開発者に選ばれ続けています(現在、フルマネージドのKubernetesサービスを提供するクラウド・プロバイダーもあります)。

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

Kubernetesでは何ができるのか

Kubernetesは、以下のタスクや他のコンテナ関連タスクをスケジュールし、自動化します。

  • デプロイメント: 指定された数のコンテナを指定のホストにデプロイし、それらのコンテナを適切な状態で稼働し続けます。
  • ロールアウト: ロールアウトはデプロイメントに加える変更です。Kubernetesにより、ロールアウトの開始、一時停止、再開、またはロールバックが可能です。
  • サービスの検出: Kubernetesは、DNS名またはIPアドレスを使用して、コンテナを自動的にインターネットまたは他のコンテナに公開できます。
  • ストレージのプロビジョニング: 必要に応じてコンテナ用に永続的なローカル・ストレージまたはクラウド・ストレージをマウントするようにKubernetesを設定します。
  • ロード・バランシングとスケーリング: コンテナへのトラフィックが急増すると、Kubernetesはロード・バランシングとスケーリングを使用してトラフィックをネットワーク全体に分散し、安定性を維持します。
  • 高可用性に向けた自己修復: コンテナに障害が発生すると、Kubernetesはそのコンテナを自動的に再起動または置換できます。ヘルス・チェック要件を満たさないコンテナを停止することも可能です。

Kubernetesと Docker

ここまでお読みいただければ、Kubernetesは、Docker Swarmの代替手段であるが、(いまだによくある誤解とは逆に)Docker自体の代替または競合相手ではないことをすでにご理解いただけていることでしょう。

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

Kubernetesアーキテクチャー

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

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

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

各クラスターは、コンテナ化されたアプリケーションのデプロイ、実行、管理を行う複数のワーカー・ノードと、ワーカー・ノードの制御とモニタリングを行う1つのマスター・ノードで構成されます。

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

Kubernetesのクラスターについて詳しくは、ブログ「Kubernetesクラスター: 迅速かつ制御されたクラウド・アプリケーション・デリバリーのためのアーキテクチャー」をご覧ください。

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

ポッドは、同じコンピュート・リソースと同じネットワークを共有するコンテナのグループです。ポッドはまた、Kubernetesでの拡張性を示す単位でもあります。 あるポッド内のコンテナに送信されるトラフィックが、そのコンテナで処理できる量を超えている場合、Kubernetesはそのポッドをクラスター内の他のノードに複製します。 このため、リソースを共有する必要があるコンテナのみが含まれるように、ポッドをコンパクトにすることをお勧めします。

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

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

Kubernetesアーキテクチャーの要素をより詳しく理解するには、自分のペースで受講できるこちらのオンライン・コース「Kubernetes 101」をご利用ください。

また、ブログ「Kubernetesアーキテクチャー: コンテナ・ソリューションへの4つのアプローチ」にも、詳しい説明が記載されています。

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はコンテナの開発とオーケストレーションを簡素化する

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

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

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

Knativeについて詳しくは、「Knative:基本ガイド」をご覧ください。

GitHubのKubernetesリポジトリーへのコミット数など、Kubernetesの人気を実証するいくつかのデータ

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

  • この執筆時点で、GitHub上のKubernetesリポジトリーに対して行われたコミットの数は86,200を超えています(IBM外部へのリンク)。そのうち、過去4カ月の間に6,000近い数のコミットが行われています。また、プロジェクトに対するアクティブなコントリビューターの数は2,300を超えています。 Cloud Native Computing Foundation(IBM外部へのリンク)によると、Kubernetes関連のリポジトリー(KubernetesダッシュボードやKubernetes MiniKubeを含む)全体で、148,000超のコミットがあったということです。
  • 1,500社を超える企業が、自社の実動ソフトウェア・スタックにKubernetesを使用しています。 これには、AirBnB、Bose、CapitalOne、Intuit、Nordstrom、Philips、Reddit、Slack、Spotify、Tinder、そして、もちろんIBMなど、世界的に有名な企業が含まれます。 さまざまな採用事例をご覧ください(IBM外部へのリンク)。
  • Container Journal誌(IBM外部へのリンク)に取り上げられている、2019年7月に実施された調査では、過去6カ月間でKubernetesの採用が51%増加したことが明らかになっています。
  • KubeCon + CloudNative Con North America 2019(IBM外部へのリンク)会議には、12,000人を超える参加者が集まり、記録的な参加者数であった前年からさらに3,000人超の増加となりました。
  • ZipRecruiter社(IBM外部へのリンク)によると、Kubernetes関連の職業の平均年俸 (北アメリカ)は144,628米ドルです。この記事の執筆時点で、21,000を超える Kubernetes関連の職がLinkedIn(IBM外部へのリンク)に掲載されています。

Kubernetesのチュートリアル

Kubernetesを使い始める準備ができている場合、またはKubernetesやKubernetesエコシステムのツールを使用してスキルの構築を検討している場合は、以下のチュートリアルのいずれかをお試しください。

KubernetesとIBM Cloud

コンテナ・オーケストレーションのマネージド・ソリューションであるIBM® Cloud Kubernetes Serviceは、IBM固有の機能を追加しながら、コンピュート・ホストのクラスター内でコンテナ化されたアプリケーションのデプロイメント、操作、スケーリング、モニターを自動化します。 これにより、アプリケーションの迅速なデリバリーを実現するとともに、ブロックチェーンIBM® Watsonなどの高度なサービスへのバインドも可能となります。

マネージドKubernetesサービスがお客様のクラウド・ジャーニーにどのように役立つかについては、動画「マネージドKubernetesの利点」をご覧ください(03:14)。

Red Hat® OpenShift® on IBM Cloudは、IBMクラウド・プラットフォーム上でフルマネージドのOpenShiftクラスターを提供する包括的なサービスです。(OpenShiftは、Red Hat Enterprise Linux上で動作する、企業向けのKubernetesプラットフォームです。)

OpenShiftの詳細については、新しいレポート「Forrester Wave:Multicloud Container Development Platforms」(PDF、415KB)をお読みください。

開始するには、IBMidを登録し、IBM Cloudのアカウントを作成してください。