なぜKubernetesはすべてを変えるのか


(この記事は、CloudBees社 Blog 「Why Kubernetes Changes Everything!」2018年4月17日 Robert Davies 投稿の翻訳記事です。)

はじめに

Dockerが2013年にオープンソースにリリースされたとき、成功するかどうかは確実ではありませんでした。5年経った今、ほとんどの企業が、アプリケーションをパッケージングするのに便利な標準的手段として、コンテナを使用しています。コンテナは、アプリケーションの実行に必要なすべての依存関係、構成、およびシステムツールを含む軽量なスタンドアロンの実行可能ファイルで、LinuxでもWindowsでも実行できます。これにより、開発とデプロイメントに一貫性が生まれました。コンテナが非常に重要なのはそのためです。開発プラットフォームでパッケージ化されたアプリケーションをビルドし、パブリッククラウドなど、コンテナをサポートするどんな場所にも展開できます。

しかし、複数のアプリケーション(マイクロサービスなど)をデプロイするようになり、アプリケーションの検出、回復、デプロイメント、自動スケーリング、セキュリティなどを一貫して行う手段が必要になってくると、コンテナだけでは不十分であり、コンテナ群を管理するオーケストレーションレイヤーが必要になります。2017年中頃まで、コンテナオーケストレーションの分野では多くの標準が競合している状況でしたが、現在は2014年中頃にGoogleによって開発されたKubernetesが圧倒的に優勢です。Redmonkによれば、Fortune 100企業のKubernetesの採用率はすでに54%に達しており、Kubernetesは競争力のあるプラットフォームプレーヤーやパブリッククラウドプレイヤーに採用されているため、コンテナオーケストレーションのデファクトスタンダードになっています。これによってすべてが変わります。今や、アプリケーションをパッケージ化するための標準的な方法と、それをデプロイする標準的なオーケストレーションが揃ったのです。これは、アプリケーション開発者やソフトウェアベンダーにとって、非常に大きな恩恵です。なぜなら、GoogleのGKE、MicrosoftのAzure、AmazonのAKS、IBM CloudからKubesprayなどのオンプレミスソリューションに至るまで、さまざまなベンダー間での真の移植性がもたらされるからです。新しいユーザーに無料のクレジットを提供している多くのパブリッククラウドプロバイダーに加えて、ローカル開発のためのMinikubeなど、Kubernetesの利用を開始する際の選択肢はたくさんあります。Jenkins Xプロジェクトという素晴らしいプロジェクトもあります。Jenkins XはJenkinsサーバーをベースとした継続的デリバリーシステムを完全にサポートし、まったくの初心者でもすぐにクラウドネイティブソフトウェアの実行と開発を行うことができます。

Kubernetesとは

Kubernetesは、コンテナを統一的に管理する方法を提供します。その目的は、どこにアプリケーションの実行をスケジュールするか、どうやってアプリケーションを探すか、どうやって実行状態を保証するか、自動スケーリング、デプロイメントなどの決定に伴う複雑さをなくすことです。一部のより高度な実装では、Kubernetesクラスターそのものを、そこで実行されているアプリケーションごと自動スケーリングすることが可能です。


図1:Kubernetesアーキテクチャ

 

Kubernetesでは、クラスターは1つまたはそれ以上のサーバーノードにデプロイされ、一部の実装ではノード自体も自動スケーリングされます。

Kubernetesは、アプリケーションの検出と負荷分散、リソース管理およびスケジューリング機能を備えています。デプロイメントの基本単位はポッドと呼ばれます。ポッドは同じライフサイクルを共有し、同じノードにデプロイされる1つまたはそれ以上のコンテナです。通常、ほとんどのポッドにはコンテナが1つだけ含まれますが、ポッドという抽象化された単位には柔軟性があり、連携するサービスを一緒に配置することもできます。

Kubernetesクラスターは、クラスターの内部または外部からのサービス要求を制御するAPIサーバーで構成されたコントロールプレーンによって管理され、アクセスコントロールとサービスの場所を決定します。コントロールプレーンのetcdコンポーネントは、クラスターに関するすべてのメタ情報を保持する可用性の高いキー/バリューストアです。

Kubernetesでアプリケーションを実行するには、アプリケーションのタイプと、最初にいくつのアプリケーション レプリカを実行状態にするかを記述したマニフェストファイル(YAMLファイル)を指定します。その後、Kubernetesは指定された状態(いくつのインスタンスを実行するか)を維持します。多くの場合、アプリケーションはサービスの背後で負荷分散されます。アプリケーションの前に仮想IPサービスがあり、複数のアプリケーションポッドに要求の負荷を分散します。ポッドは停止や再作成、あるいはスケーリング(自動スケーリングが使用されている場合)される可能性があるため、アプリケーションの前にサービスを置くことで、要求に対して緩衝レベルを設け、アプリケーションの停止を防ぐ堅牢なソリューションを提供できます。

Kubernetesはロールベースのアクセス制御を提供しており、クラスタ管理者はKubernetes APIを通じてロールを動的に定義し、アクセスポリシーを適用できます。

アプリケーション開発者は、 カスタムリソース定義で Kubernetesを拡張することもできます。たとえば、アプリケーション固有のメタデータをキー/バリューのペアとしてKubernetesクラスター自体に堅牢かつ容易に格納するといったユースケースが考えられます。

まとめ

誕生から4年近く経った(そして最近v1.10がリリースされた)今、Kubernetesはクラウド上のコンテナデプロイメントのデファクトスタンダードであり、クラウドに革新をもたらすまったく新しい道を拓きます。Kubernetesコミュニティ自体は、Kubernetesプラットフォームをより成熟させ、エンタープライズ機能を強化することに重点を置くいっぽうで、アプリケーション開発者は、アプリケーションをコンテナに展開する方法の1つに集中し、Kubernetes環境でアプリケーションが実行されることを前程として開発できます。さらに、アプリケーションとその依存関係をパッケージ化するHelmなど、より広いKubernetesエコシステムを活用できます。Kubernetesはクラウド環境に標準化をもたらし、クラウドベンダーの囲いを取り払うだけでなく、開発プロセス全体をシンプルにします。コストとアプリケーションインフラに関する要件をリアルタイムで勘案して、異なるクラウドプロバイダーにデプロイするなど、Kubernetesの利点を活用する組織もすでに現れています。アプリケーション開発者にとって次の大きな課題は、継続デリバリーによってKubernetes環境を活用する方法です。これについては今後、別の記事で説明します。