Kubernetesとは？いま注目を集める理由とその機能

本記事は「What Is Kubernetes? An Introduction to the Wildly Popular Container Orchestration Platform」の抄訳です。

※ 6月16日（火）にKubernetes とは何か？という基本から、モニタリング精度を高めるための5ステップを解説するセミナーもありますので、ぜひご参加ください。

コンテナベースのマイクロサービスアーキテクチャは、開発・運用チームがソフトウェアをテスト、デプロイする方法を大きく変えました。

コンテナは、アプリケーションのスケーリングとデプロイを容易にすることで開発の短サイクル化や運用の効率化などの実現をサポートしていますが、全く新しいインフラストラクチャを構築することによる複雑性の増加など、新たな課題も生み出しています。

企業やサービス規模の大小に関わらず、日々何千ものコンテナインスタンスがデプロイされ、複雑さが増し続けるなか、どのようにこれらを管理すれば良いのでしょうか？

そこでKubernetesが登場しました。

KubernetesはもともとGoogleによって開発されたオープンソースのコンテナオーケストレーションプラットフォームで、コンテナ化されたアプリケーションのデプロイ、スケーリング、管理を自動化するように設計されています。実際、Kubernetesは既にコンテナオーケストレーションのデファクトスタンダードとしての地位を確立しており、Google、AWS、Microsoft、IBM、Intel、Cisco、Red Hatなどの主要企業が支援するCloud Native Computing Foundation (CNCF)の重要プロジェクトでもあります。

Kubernetesは、マイクロサービスアーキテクチャにおけるアプリケーションのデプロイと運用を簡単にしてくれます。これは、ホストグループの上に抽象化レイヤーを作成することで実現しており、開発チームはアプリケーションをデプロイしてKubernetesに次のような管理をさせることができます：

• アプリケーションやチームによるリソース消費の制御
• ホストインフラへのアプリケーション負荷の均等分散
• アプリケーションの異なるインスタンス間でのリクエストの自動ロードバランシング
• アプリケーション再起動防止のためのリソース制限と消費状況のモニタリング、自動停止
• アプリケーションのホスト先移動（ホストのリソース不足時やダウン時）
• 利用可能な追加リソースの自動活用（新しいホストのクラスタ追加時）
• カナリアリリースとロールバック

こちらの記事でもKubernetesで可能なことを紹介しています（英語）：Docker vs. Kubernetes: It’s Not About One or the Other

なぜKubernetesが注目されるのか？

より多くの組織がコンテナを利用したマイクロサービスやクラウドネイティブアーキテクチャに移行するのにあわせて、強力で実績のあるプラットフォームを求め、Kubernetesを選択するようになりました。Kubernetesが選ばれるのには、主に4つの理由があると考えられます。

1. 迅速なリソース配分の強化

Kubernetesは開発チームのためにハードウェア層の抽象化を行うセルフサービス型のPlatform-as-a-Service (PaaS)を提供することができるため、開発チームは、必要なリソースを迅速かつ効率的にリクエストできます。大きな負荷を処理するためにより多くのリソースが必要な場合でも、すべてのチームで共有されているインフラストラクチャから素早くリソースを入手することができます。

Kubernetes周辺で開発されたHelmなどのツールを活用することで、プロビジョニングして実行するだけで、パッケージ化、デプロイ、テストを自動化することができます。（詳細は後述）アプリケーションを実行するために都度新たなマシンを要求する必要がなくなります。

2. コストパフォーマンス

Kubernetesとコンテナは、ハイパーバイザーやVMよりもはるかに優れたリソース利用を可能にします。コンテナは非常に軽量なので、実行に必要なCPUやメモリリソースが少なく済みます。

3. クラウドに依存しない

KubernetesはAmazon Web Services（AWS）、Microsoft Azure、Google Cloud Platform（GCP）で動作しますが、オンプレミスでも動作させることができます。アプリケーションを再設計したり、インフラストラクチャを完全に見直したりすることなく、ワークロードを移動させることができ、プラットフォーム上での標準化とベンダーロックインを回避することができます。

実際、Kublr、Cloud Foundry、Rancherなどの企業は、Kubernetesクラスタをオンプレミスでもクラウドプロバイダでも、好きなようにデプロイして管理できるツールを提供しています。

4. クラウドプロバイダーによるKubernetes管理代行

先に述べたように、Kubernetesは現在、コンテナオーケストレーションツールのデファクトスタンダードとなっています。そのため、主要なクラウドプロバイダーがKubernetes-as-a-Serviceを多数提供しています。Amazon EKS、Google Cloud Kubernetes Engine、Azure Kubernetes Service (AKS)、Red Hat Openshift、IBM Cloud Kubernetes ServiceのすべてがKubernetesプラットフォームの管理機能を提供しているので、ユーザーはアプリケーションの開発、提供することに注力することができます。

Kubernetesの機能

Kubernetesを構成する主要素はクラスタです。クラスタは多数の仮想マシンや物理マシンで構成されており、それぞれがマスターまたはノードとして特殊な機能を果たします。各ノードは1つ以上のコンテナ(アプリケーションを格納したもの)のグループをホストし、マスターはコンテナの作成や破棄のタイミングをノードと共有します。同時に、新しいコンテナの配置に基づいてトラフィックを再ルーティングする方法をノードに伝えます。

次の図は、一般的なKubernetesクラスタの構成を表しています。

マスター（Master）

Kubernetesマスターは、管理者や他のユーザーがコンテナのスケジューリングやデプロイを管理するためのアクセスポイント(またはコントロールプレーン)です。クラスタには常に少なくとも1つのマスターが存在しますが、クラスタのレプリケーションパターンによっては1つ以上のマスターが存在する場合もあります。

マスターはクラスタ全体の状態と設定データを永続的で分散型のキーバリューデータストアであるectdに保存します。各ノードは ectd にアクセスすることができ、実行中のコンテナの構成を維持する方法を学習します。ectdはKubernetesマスター上で実行することも、スタンドアロン構成で実行することもできます。

マスターは、コントロールプレーンへのメインアクセスポイントであるkube-apiserverを介してクラスタの残りの部分と通信します。例えば、kube-apiserver は、etcd の設定がクラスタ内に配置されたコンテナの設定と一致していることをチェックします。

kube-controller-manager は、Kubernetes API サーバーを介してクラスタの状態を管理する制御ループを処理します。デプロイメント、レプリカ、およびノードは、このサービスによって処理されるコントロールを持っています。例えば、ノードコントローラは、ノードの登録とライフサイクルを通しての健全性の監視を担当します。

クラスタ内のノードのワークロードは、kube-chedulerによって追跡・管理されます。このサービスは、ノードの容量とリソースを追跡し、その可用性に基づいてノードに作業を割り当てます。

cloud-controller-managerはKubernetesで実行されているサービスで、「クラウドに依存しない 」状態を維持するのに役立ちます。cloud-controller-managerは、クラウドプロバイダのAPIやツール(ストレージボリュームやロードバランサなど)と、Kubernetes内の表現手段との間の抽象化レイヤーとして機能します。

ノード（Nodes）

Kubernetesクラスタ内のすべてのノードには、コンテナランタイムを設定する必要があり、一般的にはDockerが用いられます。コンテナランタイムは、Kubernetesによってクラスタ内のノードにデプロイされるコンテナを起動して管理します。使用しているアプリケーション(Webサーバー、データベース、APIサーバーなど)はコンテナ内で実行されます。

各Kubernetesノードはkubeletと呼ばれるエージェントプロセスを実行しており、コントロールプレーンからの指示に基づいてアプリケーションコンテナの起動、停止、メンテナンスなど、ノードの状態を管理する役割を担っています。キューブレットは、実行しているノード、ポッド、コンテナからパフォーマンスと健全性の情報を収集し、その情報をコントロールプレーンと共有してスケジューリングの決定に役立てます。

kube-proxyは、クラスタ内のノード上で動作するネットワークプロキシです。また、ノード上で動作するサービスのロードバランサーとしても機能します。

基本的なスケジューリングユニットはポッド（Pod）で、同じホストマシン上でリソースを共有できる1つ以上のコンテナで構成されています。各ポッドにはクラスタ内で一意のIPアドレスが割り当てられ、アプリケーションがポートを競合することなく使用できるようにします。

Pod Specと呼ばれるYAMLまたはJSONオブジェクトを使って、ポッド内のコンテナの状態を記述します。これらのオブジェクトは、APIサーバーを介してkubeletに渡されます。

ポッドでは、ローカルディスクやネットワークディスクなどの1つまたは複数のボリューム（Volumes）を定義し、それらをポッド内のコンテナに公開することができます。例えば、あるコンテナがコンテンツをダウンロードし、別のコンテナがそのコンテンツを別の場所にアップロードするときにボリュームを使用することができます。

ポッド内のコンテナは一時的なものであることが多いため、Kubernetesはサービス（Service）と呼ばれる一種のロードバランサーを提供し、ポッドのグループへのリクエスト送信を簡素化しています。サービスは、ラベル（Labels）に基づいて選択されたポッドの論理的なセットを対象とします（以下で説明します）。デフォルトでは、サービスはクラスタ内からのみアクセスできますが、クラスタ外からリクエストを受信させたい場合は、サービスへのパブリックアクセスを有効にすることもできます。

デプロイメントとレプリカ（Deploymentsとreplicas）

デプロイメント（Deployments）はYAMLオブジェクトで、各ポッドにおけるポッド数とレプリカ（Replicas）と呼ばれるコンテナインスタンス数を定義します。デプロイメントオブジェクトの一部であるレプリカセット（ReplicaSet）を使って、クラスタ内で実行させたいレプリカの数を定義します。例えば、あるポッドを実行しているノードが停止した場合、レプリカセットは別の利用可能なノードで別のポッドがスケジュールされるようにします。

DaemonSetは、指定したノードに特定のデーモン（ポッド内の）をデプロイして実行します。DaemonSetは、ポッドにサービスやメンテナンスを提供するために最もよく使用されます。例えば、New Relic Infrastructure がクラスタ内のすべてのノードに配置された Infrastructure エージェントを取得する際にこのDaemonSetを用いています。

ネームスペース・名前空間（Namespaces）

ネームスペースを使用すると、物理クラスタの上に仮想クラスタを作成することができます。ネームスペースは、複数のチームやプロジェクトにまたがる複数のユーザーがいる環境での使用を想定しており、クラスタリソースを論理的に分離し、割り当てます。

ラベル（Labels）

ラベル（Labels）とは、Kubernetesのポッドやその他のオブジェクトに割り当てることができるキーと値のペアのことです。ラベルを使用すると、Kubernetesのオペレータはオブジェクトのサブセットを整理して選択することができます。例えば、Kubernetesオブジェクトを監視するときに、ラベルを使用すると、最も興味のある情報まで素早くドリルダウンすることができます。

ステートフルセットと永続ボリューム（Stateful sets と persistent storage volumes）

ステートフルセット（Stateful sets）を使用すると、ポッドを他のノードに移動させたり、ポッド間のネットワーキングを維持したり、ポッド間でデータを永続化したりする必要がある場合に備えて、ポッドに一意の ID を割り当てることができます。

永続ボリューム（Persistent storage volumes）も同様に、クラスタのストレージリソースを提供し、ポッドが展開されたときにアクセスを要求できるようにします。

その他の便利機能

Kubernetes DNS

Kubernetesは、ポッド間でDNSベースのサービスディスカバリーを行うためにこの仕組みを提供しています。この DNS サーバーは、インフラストラクチャで使用する他の DNS サーバーに加えて動作します。

クラスタレベルのログ

ログツールを持っている場合は、Kubernetesと統合して、クラスタ内のアプリケーションログやシステムログを抽出して保存し、標準出力や標準エラーに書き出すことができます。クラスタレベルのログを使用したい場合、Kubernetesはログ保存機能を提供していないので、独自のログ保存ソリューションを用意する必要があります。

Helm: Kubernetesアプリケーションの管理

Helmは、CNCFによって管理されているKubernetes用のアプリケーションパッケージ管理レジストリです。Helmの「チャート」は、ダウンロードしてデプロイし、Kubernetes環境ですぐに使用できるソフトウェアアプリケーションリソースです。2018年のCNCFの調査によると、回答者の68%がKubernetesアプリケーションのパッケージ管理ツールとしてHelmが好ましいと回答しています。Helmチャートは、DevOpsチームがKubernetesでアプリケーションを管理する際に、より迅速にスピードアップするのに役立ちます。

KubernetesとIstio

Kubernetesで実行されるようなマイクロサービスアーキテクチャでは、サービスメッシュは、サービスインスタンスが互いに通信できるようにするためのインフラストラクチャ層です。またサービスメッシュは、サービスディスカバリー、ロードバランシング、データ暗号化、認証と認可などの重要なアクションをサービスインスタンスがどのように実行するかを設定することもできます。Istioはそのようなサービスメッシュの1つであり、GoogleやIBMによれば、これらのサービスメッシュはますます不可分のものになってきていることを示唆しています。

例えば、IBM Cloudチームは、Kubernetesを大規模にデプロイする際に遭遇した制御、可視性、セキュリティの問題に対処するためにIstioを使用しています。具体的には以下のようなメリットを享受しています：

• サービスの連携、トラフィックのコントロール
• 柔軟な認証・認可ポリシーによるマイクロサービス間の安全な通信
• 本番環境のサービスを管理するためのコントロールポイント
• New Relic のIstioアダプタを介したサービス監視（Kubernetesがすでに収集しているアプリケーションデータと並行して、マイクロサービスのパフォーマンスデータを監視できます）

Kubernetes導入の課題

Kubernetesは数年で急速に成長、普及してきましたが、採用における課題もいくつか存在します。ここではその4つの主な課題について触れたいと思います。

1. 技術革新がもたらす混乱

開発者がKubernetesのようなオープンソース技術を好む理由の1つは、イノベーションの速さにあります。しかし、イノベーションが多すぎることが問題になることもあり、特にコアとなるKubernetesのコードベースがユーザーが追いつけないほど速く変わってしまうと混乱を招きます。プラットフォームやマネージドサービスプロバイダの数が増えるほど、状況を理解するのは難しくなります。

2. ビジネスチーム・ITチーム間との意見の不一致

予算が現状維持のためにしか配分されていない場合、Kubernetes導入のための実験を行うことは難しいかもしれません。さらに企業のITチームはリスクやを嫌うことが多く、新たな挑戦に賛同してくれないかもしれません。

3.Kubernetes活用のためのスキルセット不足

コンテナの採用のために開発者やIT運用担当者が学習や業務の再編成をしたのはほんの数年前のことであり、今度はコンテナオーケストレーションに対応しなければならなくなりました。Kubernetesの採用を希望する企業は、コーディングできる専門家を雇う必要があり、また新たな運用管理の方法、アプリケーションアーキテクチャ、ストレージ、データワークフローを理解する必要があります。

4. 困難なKubernetesの管理

Kubernetes Failure Stories GitHubを見てみると、DNSの停止から「分散システムのカスケード障害」まで、Kubernetesの失敗談を探し出したらキリがありません。便利な機能も多数備えていますが、それと同時に管理の難しさもあることが伺えます。

Kubernetes導入・活用をサポートするNew Relic

自社環境で何が起こっているかを理解するには、コンテナ内を含むすべてのレイヤーを見る必要があります。これは、全体的な監視、アプリケーション中心の監視、インフラ中心の監視を意味します。Kubernetesでアプリケーションのパフォーマンスを監視することは重要ですが、DockerとKubernetesインフラストラクチャの可視性も必要です。

New RelicのKubernetes cluster explorerは、New Relic Infrastructureの一部であり、このニーズに対応しています。Kubernetesのホスト上での連携機能を利用して、バックエンドとフロントエンドのアプリケーションとクラスタ内のホストを詳細にモニタリングすることができます。

Kubernetes cluster explorerを使用することで、アプリケーションをホストするすべてのKubernetesエンティティ（ノード、ネームスペース、デプロイメント、レプリカセット、ポッド、コンテナのメタデータ）の完全な可視性と問題発生時のアラートを手にすることができます。

この連携機能は、プロバイダーが提供するサービスでも利用できます。例えば、Red Hat OpenShiftを使用しているチームは、New Relic APMのデータとOpenShiftのデータをリンクすることができます。このステップでは、クラスタ内で実行されているアプリケーションのパフォーマンスを詳細にモニタリングすることができます。

アプリケーションをリンクした後、cluster explorerの図形のいずれかをクリックすると、クラスタ内のポッドが表示され、そのポッドの詳細ビューが表示されます。そこから、そのポッドで実行されているアプリケーションのパフォーマンスを分析することができます。

New Relic の分散トレース機能から、そのポッドで実行されているアプリケーションの分散トレースを調べることもできます。分散トレースで個々のスパンをクリックすると、そのアプリケーションに関連するKubernetes属性を素早く確認することができます。例えば、個々のスパンがどのポッド、クラスタ、デプロイメントに属しているかを知ることができます。

Kubernetesの能力を最大限に引き出すために、New Relicを活用することは非常に有用です。New Relicを用いてKubernetes環境でコンテナを監視する方法については、New Relicのドキュメントを参照ください。

Kubernetesセミナーも絶賛参加募集中です！

6月16日（火）にKubernetes とは何か？という基本から、モニタリング精度を高めるための5ステップまで、デモをまじえながら解説するセミナーもありますので、ぜひご参加ください。