Kubernetesは、アプリケーションのデプロイメント、管理、スケーリングを自動化する、オープンソースのコンテナ・オーケストレーション・プラットフォームです。 Kubernetesが、どのようにコスト効率に優れたクラウドネイティブ開発を実現するかご覧ください。
Kubernetes(別称「k8s」、「kube」)は、 コンテナ化されたアプリケーション
のデプロイメント、管理、スケーリングをスケジューリングして自動化するための コンテナ・オーケストレーション・プラットフォーム です。Kubernetesは当初、Googleのエンジニアらによって開発され、2014 年にオープンソース化されました。 Google内部で使用された コンテナ・ オーケストレーション ・プラットフォーム 「Borg」の後継にあたります。 Kubernetesは 「操舵手」 または 「パイロット」を意味するギリシャ語です。そのため、 Kubernetesのロゴ には舵が描かれています(リンクはibm.comの外にあります)。
今日、Kubernetesと、より広範なコンテナ・ エコシステム は、最新のクラウド・インフラストラクチャーとアプリケーションのための基本的な構成要素として、 仮想マシン (VM)に匹敵する、汎用コンピューティングのプラットフォームと エコシステム へと成長を遂げつつあります。 この エコシステム のおかげで、組織は クラウドネイティブ の開発を取り囲む複数のインフラストラクチャーやオーペレーションに関連するタスクや問題に対処する生産性の高い Platform-as-a-Service (PaaS) を配信でき、開発チームがコーディングとイノベーションだけに注力できます。
次の動画では、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は、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:二者択一の関係でないもの」をご覧ください。
詳細はこちら
今日では、組織に数百あるいは数千のコンテナがあることも珍しくありません。コンテナが急増するにつれ、運用チームでは、コンテナのデプロイメント、ネットワーキング、拡張性、可用性をスケジュールし自動化する必要がありました。 それにともない、コンテナ・オーケストレーション市場が登場しました。
初期には、他のコンテナ・オーケストレーション・オプション( 特に、Docker SwarmとApache Mesos)が牽引役を務めましたが、Kubernetesは瞬く間に最も広く採用されるようになりました(実際のところ、一時期、オープンソース・ソフトウェア史上で最も急成長したプロジェクトでした)。
多岐にわたる 機能性、成長し続ける オープン・ソース のサポート・ツールの エコシステム 、 クラウド・サービス ・プロバイダーをサポートし、 移植性 があることを理由に、開発者たちは、Kubernetesを選び続けています。 Amazon Web Services (AWS)、Google Cloud、IBM Cloud、Microsoft Azureなど世界を牽引するすべてのパブリック・ クラウド・プロバイダー は、 管理が徹底した Kubernetes サービスを提供しています。
コンテナ・オーケストレーションの詳細については、「コンテナ・オーケストレーションの説明」動画(08:59)をご覧ください。
Kubernetesは以下に挙げるようなアプリケーションの ライフサイクル中のコンテナ関連のタスクをスケジュールし、 自動化 します。
ここまで読んできたなら、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アーキテクチャーのビルディング・ブロックです。 クラスターは ノードで構成され、各ノードは単一の 計算 ホスト(仮想マシンまたは物理マシン)を表します。
各クラスターは、クラスターのコントロール・プランとして機能する マスター・ノード と、コンテナ化された アプリケーションをデプロイ、実行、管理する 複数の ワーカー・ノード で構成されています。 マスター・ノードは、開発者が設定したデプロイメント要件と使用可能なコンピュート能力に基づいて、コンテナをいつどこにデプロイするのかを 自動化する スケジューラー・サービスを実行します。 各ワーカー・ノードには、 Docker などのコンテナの管理に使用されるツールと、マスター・ノードからの命令を受信して実行する Kubelet というソフトウェア・エージェントが含まれています。
開発者は、 Kuvernetes API と直接通信する kubectlという コマンドライン インターフェース(cli)を使用してクラウター運用を管理します。
Kubernetesクラスターについて深くしるためには、「Kuvernetesクラスター:迅速で制御されたクラウド・アプリ配信のためのアーキテクチャ」」というこのブログ記事を参照してください。
ポッドは、同じコンピュート・リソースと同じネットワークを共有するコンテナのグループです。 それらは、Kubernetes内で拡張性の単位でもあります。ポッド内のコンテナが、取り扱い可能量よりも渋滞してきたら、Kuberenetesはクラスター内の他のノードにポッドを複製します。 このため、リソースを共有する必要があるコンテナのみが含まれるように、ポッドをコンパクトにすることをお勧めします。
デプロイメントは、コンテナ化されたアプリケーションの作成と状態を制御し、それを実行し続けます。 また、クラスター上で実行されるポッドのレプリカの数を指定します。 ポッドに障害が発生した場合、デプロイメントによって新しいポッドが作成されます。
Kubernetesのデプロイの詳細については、「Kubernetesのデプロイ:迅速な開始」をご覧ください。
IBM Cloud Paks
Kubernetesは、ポッドをデプロイおよび拡大できますが、ポッド間の経路を管理または自動化することはできず、ポッド間の接続を監視、保護、デバッグするツールも提供しません。 クラスター内のコンテナ数が増えるにつれて、それらコンテナ間を結ぶことができるパスの数は飛躍的に増化します(例えば、2つのコンテナに存在し得る接続は2つですが、10個のポッドではそれが90個になります)。これにより、構成と管理が非常に困難になるおそれがあります。
Kubernetesクラスターのオープンソースのサービス・メッシュ・レイヤーであるIstioを入力してください。 各Kubernetesクラスターに対し、Istioは、サイドカー・コンテナを追加します。基本的にこれをプログラマーや管理者が意識することはありません。このサイドカー・コンテナが、他のコンテナ間の対話を構成、監視、管理します。
Istioを使用すると、コンテナ間の接続を構成する単一のポリシーを設定することができ、それぞれの接続を個別に構成する必要がありません。 これにより、コンテナ間の接続をより簡単にデバッグできるようになります。
また、Istioにはダッシュボードが用意されており、DevOpsチームや管理者はダッシュボードを使用して、コンテナ間の接続について、レイテンシー、サービス時間に関するエラー、その他の特性を監視できます。 さらに、Istioにはセキュリティー(具体的には、権限のないユーザーがコンテナ間の サービス呼び出しをスプーフィングできないようにするID管理)と、認証、許可、および監査(AAA)の機能が組み込まれています。これらを使用して、セキュリティーの専門家はクラスターを監視することができます。
Istioの詳細や動画、使用例については、記事「Istioとは」をご覧ください。
Knative(ケイネイティブ)は、Kubernetes上で稼働するオープンソース・プラットフォームです。クラウドネイティブな開発のために、以下の2つに分類される重要なメリットをもたらします。
サーバーレス・コンピューティングは、クラウドネイティブ・アプリケーションの効率とコスト効果を高めるコードをデプロイする比較的新しい方法です。 要求の待機中にアイドル状態になっている進行中のインスタンス・コードをデプロイする代わりに、サーバーレスは 必要に応じてコードを起動し(需要の変動に応じてスケールアップまたはスケールダウンさせます)、コードが使用されなくなったら終了させます。 サーバーレスでは、コードが実際に実行された時間に対してのみ課金されるので、コンピューティング容量と電力を節約し、コストを削減できます。
Knativeでは、開発者がコンテナを1度作成すれば、そのコンテナをソフトウェア・サービスまたはサーバーレス機能として実行できます。 Knativeは開発者に対して透過的なものです。Knativeは詳細をバックグラウンドで取り扱い、開発者はコードに焦点を当てられます。
開発者にとって、コードのコンテナ化は多くの反復ステップを要する作業となります。また、コンテナのオーケストレーションには、数多くの構成とスクリプト作成の作業(構成ファイルの生成、依存関係のインストール、ロギングとトレースの管理、継続的なインテグレーション/継続的なデプロイメント(CI/CD)スクリプトの記述)も必要となります。
Knativeは、以下の3つのコンポーネントによる自動化によって、これらのタスクをより簡単にします。
「Knaive:基本ガイド」を読むと、Knativeの詳細を学べます。
Kubernetesは、オープンソース・プロジェクトの歴史で最も急速な成長を遂げたものの1つであり、この成長はいまも加速しています。 Kubernetesを採用する開発者と企業の間で、採用件数は急増し続けています。 注目すべきデータ・ポイントをいくつか示します。
Kubernetes を使い始める準備ができている場合やKubernetesおよびKubernetesエコシステム・ツールを使用してスキルの構築を検討している場合は、以下のチュートリアルのいずれかをお試しください。
コンテナーは アプリケーションの最新化 と ITインフラストラクチャー最適化に適しています。 KubernetesやオープンソースのKubernetesエコシステム内の他のツールで構築され、IBM Cloudのコンテナー・サービスは クラウドネイティブ アプリケーション開発や、プライベート・クラウド、 パブリック・クラウド 、 オンプレミス のITインフラストラクチャにある優れた機能や関数を統合するオープン・ハイブリッド・クラウド・アプローチへのパスを促進して加速させることができます。
次のステップに進みます:
すぐに開始するために、 IBM Cloudアカウントのための サインアップ をします。
信頼性のあるさまざまなクラウドで、アプリケーションを安全に構築、モダナイズ、管理します。
オープンなハイブリッドクラウド戦略を採用すると、ベンダーの囲い込みなしにあらゆる場所でワークロードを構築して管理できます。
オープンで柔軟性のあるセキュアなオンプレミスのインフラストラクチャー・ソリューションを活用してハイブリッドクラウド戦略を引き出します。
可用性の高いフルマネージドのクラスターをクリックするだけで展開します。
ビジネスや研究の問題解決に役立つデータの洞察を明らかにします。
完全管理されたコンテナー・ランタイムでコンテナー、アプリケーション・コードまたはバッチ・ジョブを実行します。