Kubernetesとは？ 

Kubernetesには、ユーザーに役立つさまざまな機能があります。主な機能には以下のものがあります。

• 自動ビンパッキング
• IPv4/IPv6デュアルスタック
• バッチ実行
• ロードバランサー
• スケジューラー
• サービスディスカバリー

ほかにも、アプリケーションの健全性チェックとデプロイに悪影響のある変更の取り消し、任意のストレージシステムのマウント、アプリケーションのスケーリング、自己修復(ユーザーの指定に基づく、応答しないコンテナの置換または終了、障害が発生したコンテナの自動スケーリング、再起動、または再スケジュール)など、さまざまな自動化機能があります。

コンテナは、アプリケーション本体とその実行に必要なすべてのコンポーネントをひとまとめにしたソフトウェア単位です。コンテナにまとめることで、アプリケーションの可搬性を向上できます。その仕組みを理解するには、まず、空の箱を想像してください。この箱(コンテナ)に、アプリケーションのコード、システムツール、設定ファイル、その他アプリケーションの実行に必要な依存コンポーネントをすべて詰め込んでから、別の場所(ローカルマシン、パブリッククラウド、オンプレミスのデータセンターなど)に箱を持っていき、中身を取り出します(つまり「デプロイ」します)。

アプリケーションを独立させてインフラから抽象化する点で、コンテナは仮想マシン(VM)と似ています。ただし、コンテナの方がVMよりもサイズが小さく、必要なリソースも少なくて済みます。このように可搬性が高く軽量であり、必要に応じて起動/停止が簡単にできるため、特定のサービスだけをすばやく変更して再デプロイするマイクロサービスのようなアプローチを簡単に実装できます。コンテナを使用しない場合は、アプリケーション全体の再起動が必要になるため、コードリリースに時間がかかり、生産性が低下するだけでなく、変更時のミスがシステム全体のエラーにつながる可能性もあります。

コンテナ環境には以下のメリットがあります。

• 一貫性：アプリケーションのすべての依存コンポーネントをコンテナに含めることができるため、開発者は、デプロイ先の環境の違いを気にすることなく、機能の開発に集中できます。
• 柔軟性：コンテナは可搬性が非常に高く、Windows、Mac、またはLinuxなどのオープンソースOSはもちろん、クラウドサービスや、物理サーバー、仮想サーバーなど、さまざまな環境で動作します。社内だけでなく外部の環境にも柔軟に対応するため、異なるベンダーのサービスへの移行が容易で、ベンダーロックインを回避できます。
• ダウンタイムの削減：コンテナ化したアプリケーションを複数用意して、物理サーバーと仮想マシン、クラウドとオンプレミスなど、異なる環境に分散配備することで、システムのフォールトトレランスを向上できます。
• 拡張性：サイズが数ギガバイトになることもあるVMとは異なり、コンテナは通常、数メガバイトで済みます。そのため、1つのOS上で多数のコンテナを実行することも可能で、VMよりも効率的に拡張できます。 
• スピード：コンテナは軽量で、起動は1秒以内に完了します。また、使用するサーバーリソースが少ないため、動作も高速です。さらに、短期間で開発できるため、生産性が向上し、市場投入までの時間を短縮できます。
  

Kubernetesは、他のコンテナオーケストレーションツールと同様に、コンテナのネットワーキング、スケーリング、スケジューリング、デプロイを容易にします。特に、数千、数万、数億という単位のコンテナを実行する大規模環境では欠かせない存在と言えます。継続的インテグレーション/継続的デリバリー(CI/CD)など、DevOpsのベストプラクティスを総合的に実践している場合、Kubernetesを使用することで、同じアプリケーションを異なる環境で実行することや、マイクロサービスをより簡単に実装することができ、アプリケーション開発の俊敏性を向上できます。Kubernetesはよく「宣言的」と言われます。これは、ユーザーがシステムの動作に関するパラメーターを宣言するだけで、Kubernetesによって、そのパラメーターを満たす具体的な調整が自動的に行われることを意味します。

コンテナオーケストレーションツールとして、Kubernetesでは以下のようなタスクを自動化および管理できます。

• コンテナのデプロイ
• コンテナの可用性維持
• リソースの割り当て
• 健全性の監視
• ロードバランシング
• コンテナ操作のセキュリティ確保
• ホストのリソースや健全性に基づくコンテナのサイズや場所の調整

Kubernetesを使用するメリットは、コンテナを使用するメリットとほぼ同じです。Kubernetesは可搬性が高く、ハイブリッド、クラウド、オンプレミス、マルチクラウドのいずれの環境にも柔軟に対応します。コンテナに障害が発生したりノードが停止したりしても、自己修復機能により、該当するコンテナやノードが自動的に置換または再スケジュールされます。また、企業によっては最も重要となる拡張性もあり、組織のニーズに応じて数十単位から数億単位のコンテナを実行できます。さらに、Kubernetesのコミュニティは非常に活発で、さまざまな業界でKubernetesを最大限に活用するために役立つ幅広いツールが提供されています。

Kubernetesの使用にはデメリットもいくつかあります。非常に複雑な環境を管理できる一方で、Kubernetes独自の開発ワークフローに不慣れな開発者にとっては難易度が上がる可能性があります。また、マイクロサービスを含むコンテナ環境では、多数のコンポーネントが連携するため、監視、セキュリティ確保、トラブルシューティングが難しくなる可能性もあります。

Kubernetesは、コンピューティング環境にコンテナを使用する組織であれば、eコマースから、金融、ヘルスケア、テクノロジーまで、業種を問わずメリットをもたらします。

Kubernetesは特に、以下の目的に役立ちます。

• クラウドプラットフォームへの移行(アマゾン ウェブ サービス(AWS)、Google Cloud、Microsoft Azureなど)
• プラットフォームの拡張
• 機械学習やIoTデバイスの導入
• マイクロサービスベースアプリケーションの管理の効率化

たとえば、Ancestry.comは、一般消費者向けとして世界最大規模のDNA検査サービスを提供するWebサイトです。数十億件の履歴レコードを管理し、数百万人の有料会員にサービスを提供するこのWebサイトでは、一時期、アーキテクチャが複雑化し、管理性と俊敏性が低下しました。この課題に対応するため、開発チームはクラウドネイティブインフラへの移行に乗り出し、コンテナオーケストレーションプラットフォームとして、当時はまだ新しかったKubernetesを導入しました。クラウドへの移行とコンテナ化、そしてKubernetesによるコンテナオーケストレーションにより、生産性が向上し、場合によっては50分かかっていたコードのデプロイを1分以内に短縮できました。この時間節約の効果は、開発チームに大きな価値をもたらしています。

Kubernetes Podは、コンテナをスケジュールするための最も基本的な単位です。1つまたは複数のコンテナで構成され、Pod内のコンテナは、1つのユニットとして同じノードにデプロイされ、リソース(ネットワーク、IPアドレス、ホスト名など)を共有し、相互に通信します。Podに多数のコンテナを含め、まとめてスケーリングすることもできますが、通常は、効率を最適化するために、1つのPodに入れるコンテナは必要最小限に抑えます。Podには、アプリケーションコンテナだけでなく、エフェメラルコンテナ(アプリケーションの調査に使用する短命のコンテナで、クラスターによっては利用できません)や、Initコンテナ(アプリケーションコンテナの起動前に実行され、完了するコンテナ)も含めることができます。Pod自体もエフェメラル(短命)と言えます。Podはそもそも、永続的に実行することを目的としておらず、一度削除するか障害で停止すると、元に戻すことはできません(ただし、Kubernetesの自己修復機能により、障害が発生したノードのPodは別のノードに移動されることがあります)。Podの設定や、その実行に関する仕様は、YAMLまたはJSONファイルで定義できます。

Kubernetesには、Podのほかにも覚えておくと役立つアーキテクチャ上のコンポーネントがあります。

• ノード：Podとその他必要なすべての要素を実行する物理マシンまたは仮想マシンを指します。実行中のノードが障害で停止すると、クラスターによって、ユーザーが指定した仕様に従ってコンテナが自動的に調整されます。 
• クラスター：複数のノードをまとめた単位を指します。クラスター内のノードはコントロールプレーンによって管理されます。 
• Kubelet：ノード内で動作し、コンテナの起動と停止を担うほか、設定情報を含むYAMLやJSONファイルでユーザーが指定した仕様に従ってPod内のコンテナが実行されるようにするエージェントです。
  

Kubernetes Podはさまざまな方法で使用できますが、主な使い方は次の2つです。

• シングルコンテナPod：1つのコンテナのみを含むPodで、Kubernetesでは最も一般的な使い方です。前述の箱の例で言うと、シングルコンテナPodは、1つの箱をラッピングするようなもので、最も簡単かつ効率的です。 
• マルチコンテナPod：複数のコンテナが互いに通信し、リソースを共有する必要がある場合は、1つのPodに複数のコンテナを含めることができます。マルチコンテナPodを作成する必要があるのは、やや高度なユースケースです。たとえば、メインのアプリケーションとともに、データプッシュやプロキシなどのヘルパーアプリケーションを実行する必要がある場合などです。これらのアプリケーションのコンテナと、リソースを共有するその他の関連コンテナを、1つのPodにまとめることができますただし、これは複数の箱を1つにまとめてラッピングするようなものなので、シングルコンテナPodよりも難易度が高く、Kubernetesでのオーケストレーションも複雑になります。 

通常は、Podを手動で作成する必要はありません。ワークロードリソースにPodのライフサイクル管理を任せることができます。ワークロードリソースを使用すれば、ノードに障害が発生したときの置換用Podも自動的に作成されます。

また、コンテナのランタイムで可能な場合は、特権モードを有効にすることで、OSの管理権限をコンテナに与えることもできます。

DockerとKubernetesについて考えるべきは、どちらを選ぶかではなく、2つをどのように組み合わせて使用するかです。この2つのプラットフォームは異なる機能を提供します。Dockerは、コンテナを作成してデプロイするためのオープンソースのコンテナ化プラットフォームであり、Kubernetesは、コンテナオーケストレーションプラットフォームです。2013年に登場したDockerは今日、デフォルトのコンテナファイル形式であり、コンテナの代名詞ともいうべき存在です。LinuxとWindowsの両方と互換性があり、オンプレミスとクラウドのどちらでも実行できます。

コンテナを作成して実行するDockerと、コントローラーマネージャーとしてそれらのコンテナをスケジュール、スケーリング、移動するKubernetesは、相性が抜群です。Dockerを使ってコンテナを作成および実行し、コンテナイメージを保存してから、Kubernetesでコントロールプレーンからそれらのコンテナとそのリソースをオーケストレーションするという流れで、2つを連携できます。DockerとKubernetesを組み合わせることで、プロセスを効率化し、拡張性の高いアプリケーションの開発を容易にして、クラウドネイティブアーキテクチャやマイクロサービスをより効率的に構築できます。

Kubernetesには、Dashboardと呼ばれるWebベースのユーザーインターフェイスが用意されています。Dashboardでは以下のタスクを実行できます。

• コンテナ化アプリケーションのトラブルシューティング
• クラスターリソースの管理
• Kubernetes固有のリソースの変更(Job、DaemonSetsなど)
• ウィザードによるクラスターへのコンテナ化アプリケーションのデプロイ
• クラスター内のアプリケーションの状況確認

Dashboardでは、表示を切り替えて、システムのさまざまな面について状況を確認できます。特定のPod内のコンテナで生成されたすべてのログ、アプリケーションでデータの保存に使用されているリソースの量、特定のNamespaceで実行されているすべてのアプリケーション(ワークロードの種類別)、管理者向けの概要と、ノード、Namespace、永続ボリュームを調査するための詳細オプションなどが表示されます。

アプリケーションをクラスターにデプロイしたら、監視することが重要です。Kubernetesには統合的な監視ソリューションはありませんが、クラスターの特性に関するデータが提供されるため、そこからリソースの使用状況やアプリケーションのパフォーマンスを把握できます。新しいクラスターを監視するときは、リソースメトリクスとフルメトリクスの2種類のメトリクスパイプラインを使用できます。リソースメトリクスパイプラインでは、個々のコンテナの統計が報告され、クラスターコンポーネントに関する情報は限られます。フルメトリクスパイプラインでは、その名のとおり、リソースメトリクスよりも幅広いメトリクスが提供されます。

Kubernetes環境をより詳細に可視化したい場合は、専用の監視ソリューションを利用します。多くのベンダーがKubernetes監視用のツールを提供しているので、予算とニーズに合ったソリューションを選択できます。

コンテナを導入することを決めたら、さっそくKubernetesも導入しましょう。インストールタイプの選択では、利用可能なリソース、セキュリティニーズ、必要なメンテナンスレベルなど、いくつかの考慮事項があるので、事前に調べておきます。Kubernetesの基礎を学びたい場合は、KubernetesのWebサイトで詳細なドキュメントを参照できるほか、ユーザーと協力者によるKubernetesコミュニティで幅広い情報を手に入れることができます。さらに、Kubernetesを本番環境で使用する場合は、チュートリアルを見ながら自身で管理する以外に、認定Kubernetesプロバイダーにサポートを依頼する方法もあります。

2020年初めの時点で企業の間でクラウド移行はすでに始まっていましたが、新型コロナウイルスの感染拡大によってその動きが急激に加速しました。今後、クラウドネイティブ環境が標準になるにつれて、それを支えるコンテナなどのインフラの需要も拡大するでしょう。Forrester社の予測では、2021年末までに開発者の30%がコンテナを使用するようになる見込みです。さらに、俊敏性の向上を後押しするマイクロサービスの需要も増えています。こうした状況や、Kubernetes向けに簡単に利用できるソリューションが大手クラウドベンダーから続々と提供されている点から、Kubernetesに今投資することは将来への地盤固めになると言ってよいでしょう。一方、Kubernetes自体も、企業での活用がさらに進むにつれて、イノベーションを繰り返していくはずです。

近年の混乱は私たちに俊敏性の大切さを教えてくれました。業界全体がコンテナ、サーバーレスインフラ、マイクロサービスへと向かう中、企業は、DevOps文化に求められるスピードとクラウドドリブンの現実に直面し、信頼性と拡張性の高いアプリケーションを顧客に提供する必要性を改めて実感しています。Kubernetesは、導入当初は習得にある程度時間がかかるかもしれませんが、その柔軟性と潜在性の高さが、効率、俊敏性、競争力の向上を後押しすることは間違いありません。IT環境のアーキテクチャ、そして組織の未来を考えるとき、導入するツールが本当に開発者の助けになるか、Kubernetesのようなコンテナオーケストレーションプラットフォームが組織に必要ではないかを、常に検討することが大切です。