「k8s」や「kube」としても知られるKubernetesは、コンテナ化されたアプリケーションの導入、管理、スケーリングをスケジュール設定および自動化するためのコンテナ・オーケストレーション・プラットフォームです。
KubernetesはGoogleのエンジニアによって開発された後、2014年にオープンソース化されました。Google内部で使用されているコンテナ・オーケストレーション・プラットフォームであるBorgの子孫です。Kubernetesはギリシャ語で舵取りや水先案内人を意味しており、Kubernetesのロゴには舵が描かれています(リンクはibm.comの外部)。
今日、Kubernetesとその広範なコンテナ・エコシステムは、最新のクラウド・インフラストラクチャーとアプリケーションの基本的な構成要素として、仮想マシン(VM)に匹敵する(凌駕しないまでも)汎用コンピューティング・プラットフォームとエコシステムに成熟しつつあります。このエコシステムにより、企業は生産性の高いサービス型プラットフォーム(Paas:Platform-as-a-Service)を提供することができ、クラウドネイティブ開発にまつわるインフラや運用関連の複数のタスクや問題に対処することで、開発チームはコーディングとイノベーションのみに集中することができます。
次の動画では、Kubernetesの基本についてわかりやすく紹介しています。
アプリケーションのパフォーマンスを確保しながら、市場投入までの時間を短縮したいプラットフォームおよびDevOpsエンジニア向け
コンテナは 軽量で実行可能なアプリケーション・コンポーネントであり、アプリケーション・ソース・コードと、そのコードをあらゆる環境で実行するために必要なすべてのオペレーティング・システム(OS)ライブラリや依存関係を組み合わせています。
コンテナは、プロセスを分離し、プロセスがアクセスできるCPU、メモリ、ディスクの容量を制御することにより、複数のアプリケーションがOSの単一インスタンスを共有できるようにするオペレーティング・システム(OS)の仮想化の形態を利用します。コンテナは 仮想マシン(VM)よりも小さく、リソース効率が高く、移植性が高いため、最新のクラウドネイティブ・アプリケーションの事実上のコンピュート・ユニットとなっています。
最近のIBM調査では、ユーザーは、コンテナと関連技術の導入によってもたらされるいくつかの具体的な技術的およびビジネス上の利点を報告しています。
コンテナは、ITインフラストラクチャーの自動化と抽象化の継続における最新のポイントとして理解した方が簡単か、より役に立つかもしれません。
従来のインフラストラクチャーでは、アプリケーションは物理サーバー上で実行され、取得できるすべてのリソースを取得します。そのため、1 台のサーバーで複数のアプリケーションを実行し、他のアプリケーションを犠牲にしてリソースを浪費しないことを祈るか、アプリケーションごとに1台のサーバーを専用にするかという選択肢が残されますが、これではリソースが無駄になり、拡張性がありません。
仮想マシン(VM)は、実際のコンピューター・ハードウェアから抽象化されたサーバーであり、1台の物理サーバーで複数のVMを実行したり、複数の物理サーバーにまたがる単一のVMを実行したりすることができます。各VMは独自のOSインスタンスを実行し、各アプリケーションを独自のVMに分離して、基盤となる同じ物理ハードウェア上で実行されているアプリケーションが相互に影響し合う可能性を減らすことができます。VMはリソースを有効に活用し、従来のインフラストラクチャーよりもはるかに簡単に拡張でき、コスト効率が高くなります。また、アプリケーションを実行する必要がなくなったら、VMを停止するだけで済みます。
VMの詳細については、「仮想マシンとは」を参照してください。
コンテナはこの抽象化をより高いレベルに引き上げます。具体的には、基盤となる仮想化ハードウェアを共有することに加えて、基盤となる仮想化OSカーネルも共有します。コンテナは、VMと同じ分離性、拡張性、使い捨て機能を提供しますが、独自のOSインスタンスのペイロードを伝送しないため、VMよりも軽量です(つまり、使用するスペースが少なくなります)。リソース効率が高く、より少ないOSインスタンス、より少ないマシン(仮想および物理) でより多くのアプリケーションを実行できます。コンテナは、デスクトップ、データセンター、クラウド環境間でより簡単に移植できます。また、アジャイルやDevOpsの開発プラクティスにも適しています。
「コンテナとは」では、コンテナとコンテナ化について詳しく説明しています。また、ブログ記事「コンテナとVM:その違いとは」では、両者の違いについて完全な概要を示します。
Dockerは、Linux®コンテナの作成と実行に利用される最も人気の高いツールです。コンテナの初期形態は(FreeBSD JailsやAIX Workload Partitionsのような技術で)数十年前に導入されましたが、2013年にDockerが開発者向けに、クラウドに適した新たな実装でコンテナを一般に提供したことで、コンテナは民主化されました。
Dockerはオープンソース・プロジェクトとして始まりましたが、現在では Docker Inc.も指します。Dockerは、オープンソース・プロジェクトに基づいて構築された商用コンテナ・ツールキット(そして、その改善をオープンソース・コミュニティに還元する)を製造する会社です。
Dockerは従来のLinuxコンテナ(LXC)テクノロジーに基づいて構築されていますが、Linuxカーネル・プロセスのよりきめ細かい仮想化を実現し、開発者がコンテナを容易に構築、デプロイ、管理、保護できる機能を追加しています。
今日、代替コンテナ・プラットフォーム(Open Container Initiative(OCI)、CoreOS、Canonical(Ubuntu)のLXDなど)が存在する一方で、Dockerは非常に広く好まれているため、事実上コンテナの代名詞となっており、Kubernetesのような補完的なテクノロジーと競合すると誤解されることもあります(以下の動画「Kubernetes vs, Docker: It's Not an Either/Or Question」を参照)。
コンテナが急増するにつれて(今日では、1つの組織が数百から数千のコンテナを持つこともあります)、運用チームはコンテナのデプロイ、ネットワーキング、拡張性、可用性をスケジュール設定して自動化する必要が出てきました。コンテナ・オーケストレーション市場はこのように生まれました。
Docker SwarmやApache Mesosに代表される他のコンテナ・オーケストレーション・オプションが早い時期から一定の人気を得ていた一方で、Kubernetesはすぐに最も広く採用されるようになりました(実際、一時はオープンソース・ソフトウェアの歴史の中で最も急速に成長したプロジェクトでした)。
機能の幅広さ、オープンソース・サポート・ツールの広大な、成長し続けるエコシステム、クラウド・サービス・プロバイダー間のサポートと移植性により、開発者はKubernetesを過去も現在も選び続けています。Amazon Web Services(AWS)、Google Cloud、IBM Cloud、Microsoft Azureなど、すべての主要パブリッククラウド・プロバイダーは、フルマネージドのKubernetes サービスを提供しています。
Kubernetesは、アプリケーションのライフサイクル全体を通じて、次のようなコンテナ関連のタスクをスケジュール設定し、自動化します。
ここまで読んだ方は、KubernetesがDocker Swarmの代替品である一方で、(根強い一般的な誤解に反して)Docker自体の代替品や競合製品ではないことをすでに理解していると思います。
実際、Dockerを熱心に採用し、大規模なDockerベースのコンテナ・デプロイメントを作成している場合、Kubernetesオーケストレーションは、これらのワークロードを管理するための論理的な次のステップです。
詳細については、「Kubernetes vs. Docker: It's Not an Both/Or Question」を参照してください。
Kubernetesアーキテクチャーの主なコンポーネントには次のものがあります。
クラスタは、Kubernetesアーキテクチャーの構成要素です。クラスタはノードで構成されており、各ノードは単一のコンピューティング・ホスト(仮想マシンまたは物理マシン)を表します。
各クラスタは、クラスタの制御プランとして機能するマスター・ノードと、コンテナ化されたアプリケーションをデプロイ、実行、管理する複数のワーカー・ノードで構成されます。マスター ノードは、開発者が設定したデプロイメント要件と利用可能なコンピューティング容量に基づいて、コンテナがいつどこにデプロイされるかを自動化するスケジューラー サービスを実行します。各ワーカー・ノードには、コンテナの管理に使用されるツール(Dockerなど)と、マスター・ノードからの命令を受信して実行するKubeletと呼ばれるソフトウェア・エージェントが含まれています。
開発者は、Kubernetes APIと直接通信するコマンドライン・インターフェース(cli)であるkubectlを使用してクラスタ 操作を管理します。
Kubernetesクラスタについてさらに詳しく知りたい場合は、「Kubernetes Clusters: Architecture for Rapid, Controlled Cloud App Delivery」をお読みください。
ポッドは、同じコンピューティング・リソースと同じネットワークを共有するコンテナのグループです。これらは、Kubernetesの拡張性の単位でもあります。ポッド内のコンテナが、処理できる量を超えるトラフィックを取得している場合、Kubernetesはそのポッドをクラスタ内の他のノードに複製します。このため、リソースを共有する必要があるコンテナのみが含まれるようにポッドをコンパクトに保つことをお勧めします。
デプロイメントにより、コンテナ化されたアプリケーションの作成と状態が制御され、実行が維持されます。デプロイメントにより、クラスタ上で稼働すべきポッドのレプリカの数が特定されます。あるポッドが機能を停止すると、デプロイメントによって新しいポッドが作成されます。
Kubernetesのデプロイメントの詳細については、「Kubernetes Deployments: Get Started Fast」を参照してください。
Kubernetesはポッドをデプロイおよびスケーリングできますが、ポッド間のルーティングを管理または自動化することはできず、これらの接続を監視、保護、またはデバッグするためのツールも提供していません。クラスタ内のコンテナ数が増えるにつれて、コンテナ間で可能な接続パスの数は指数関数的に増加し(たとえば、2つのコンテナには2つの接続の可能性があるが、10個のポッドには90の接続の可能性がある)、構成と管理の悪夢が生じかねません。
そこで登場したのが、Kubernetesクラスタ用のオープンソースサービス・メッシュ・レイヤー、Istioです。Istioは、各Kubernetesクラスタに、他のコンテナ間の相互作用を構成、監視、管理するサイドカーコンテナ(基本的にプログラマーと管理者には見えません)を追加します。
Istioでは、コンテナ間の接続を構成する単一のポリシーを設定するため、各接続を個別に構成する必要はありません。そのため、コンテナ間の接続のデバッグが容易になります。
Istioは、DevOpsチームや管理者が遅延、サービス開始時間のエラー、コンテナ間の接続のその他の特性を監視するために使用できるダッシュボードも提供します。また、セキュリティ、特に、権限のないユーザーによるコンテナ間のサービス呼び出しのなりすましを防ぐID管理と、セキュリティ専門家がクラスタの監視に使用できる認証、認可、監査(AAA)機能が組み込まれています。
Knative(「ケイネイティブ」と発音)は、Kubernetesの上に位置するオープンソース・プラットフォームで、クラウドネイティブ開発に2つの重要なクラスの利点を提供します。
サーバーレス・コンピューティングは、クラウドネイティブ・アプリケーションの効率性と費用対効果を高める、比較的新しいコードのデプロイ方法です。サーバーレスは、リクエストを待っている間、アイドル状態のコードの進行中のインスタンスをデプロイする代わりに、必要に応じてコードを起動し、需要の変動に応じてスケールアップまたはスケールダウンし、使用していないときはコードを停止します。サーバーレスでは、コードを実際に実行するときにのみ料金を支払うため、コンピューティング能力と電力の無駄が防止され、コストが削減されます。
Knativeを使用すると、開発者はコンテナを一度構築した後、ソフトウェア・サービスやサーバーレス機能として実行できます。開発者にとってはこれはすべて透過的に行われます。Knativeがバックグラウンドで詳細を処理するため、開発者はコードに集中できます。
開発者にとって、コードのコンテナ化には多くの反復ステップが必要であり、コンテナのオーケストレーションには多くの設定とスクリプト(設定ファイルの生成、依存関係のインストール、ロギングとトレーシングの管理、継続的な統合/継続的なデプロイメント (CI/CD)スクリプトの記述など)が必要です。
Knative は、次の3つのコンポーネントでこれらのタスクを自動化して、容易に実行できるようにします。
ビルド:Knative のビルド・コンポーネントは、ソースコードをクラウドネイティブのコンテナまたは関数に自動的に変換します。具体的には、リポジトリからコードを取得し、必要な依存関係をインストールし、コンテナ・イメージを構築して、他の開発者が使用できるようにコンテナ・レジストリに配置します。開発者は、Knativeがコンポーネントを見つけられるように、これらのコンポーネントの場所を指定する必要がありますが、それが完了すると、Knativeはビルドを自動化します。
Serve:Serveコンポーネントはコンテナをスケーラブルなサービスとして実行します。数千のコンテナ・インスタンスまでスケールアップすることも、ゼロにスケールダウンすることもできます(ゼロへのスケーリングといいます)。さらにServeには、コンテナを本番環境にプッシュするたびにコンテナのバージョン(スナップショットと呼ばれる)を保存し、それらのバージョンを同時に実行できる設定と、さまざまな量のトラフィックをこれらのバージョンに向けることができるサービス・ルーティングという、2つの非常に便利な機能があります。これらの機能を組み合わせて使用すると、コンテナのロールアウトを段階的に進めたり、コンテナ化されたアプリケーションをグローバルな生産に導入する前にカナリア・テストを段階的に実行したりできます。
イベント:イベントを使用すると、指定したイベントでコンテナベースのサービスまたは関数をトリガーできます。これは、Knativeのサーバーレス機能に特に不可欠です。必要に応じて関数を起動するようにシステムに指示する必要があります。イベントにより、チームはイベントの種類に関心を示すことができます。また、イベントはイベント・プロデューサーに自動的に接続し、イベントをコンテナにルーティングするため、これらの接続をプログラミングする必要がなくなります。
Kubernetesは史上最も急速に成長しているオープンソース・プロジェクトの1つであり、その成長は加速しています。開発者や彼らを雇用する企業の間で、採用が急増し続けています。注目に値するいくつかのデータポイントを示します。
Kubernetesの使用を開始したい場合、またはKubernetesおよびKubernetesエコシステム・ツールに関する既存のスキルを強化したい場合は、次のチュートリアルのいずれかをお試しください。
Red Hat OpenShift on IBM Cloudは、エンタープライズ・ワークロードをKubernetesクラスターにコンテナ化してデプロイするための高速かつ安全な方法を開発者に提供します。
ツールチェーン、データベース、AI などの共通のクラウド・サービス・セットを使用して、あらゆるクラウド・ベンダーのオンプレミス、エッジコンピューティング、パブリッククラウド環境にわたってアプリを一貫してデプロイして実行できます。
フルマネージドのサーバーレス・プラットフォームである IBM Cloud Code Engine を使用すると、フルマネージドのコンテナー・ランタイム上でコンテナー、アプリケーション・コード、またはバッチ・ジョブを実行できます。
IBM の新しい調査では、コンテナーと Kubernetes の導入の勢いが急速に高まっていることが文書化されています。
コンテナは、どこからでもワークロードを構築および管理できるようにするハイブリッドクラウド戦略の一部です。
サーバーレスは、サーバー管理が不要で、使用していないクラウド・インフラストラクチャーに対する料金を支払わずに、開発者がコードを構築および実行できるクラウド・アプリケーションの開発および実行モデルです。
KubernetesでYAMLファイルがどのように使用されているか例を見てみましょう。