「Kubernetes」はコンテナ化されたアプリケーションを管理するためのポータブルなオープンソースコンテナオーケストレーションシステムまたはプラットフォームを指す言葉です。
Kubernetes (略して K8s または「クバ」) を理解するには、まずコンテナオーケストレーションについて理解することが重要です。 コンテナアーキテクチャでは 1 つのアプリケーションを構成するさまざまなサービスをパッケージ化された個別のコンテナに分解し、このコンテナを物理または仮想マシンのクラスターに展開します。 コンテナアーキテクチャの台頭によって、コンテナオーケストレーションのニーズも高まっています。 コンテナオーケストレーションはこうしたコンテナの展開、スケーリング、ネットワーク、可用性の管理と自動化を行うツールです。
Kubernetes はコンテナプロセスの組織化と展開の管理と自動化を行うコンテナオーケストレーションシステムです。 Kubernetes は Google で始まり、2014 年にオープンソースになりました。 それ以来、Kubernetes は誰でも使用でき、その使い方にもほとんど制限はありません。
Kubernetes が多くの企業に人気のツールになっているのは、それがもたらすメリットのためです。 Kubernetes には 3 つのメリットがあります。
自動化はビジネスプロセスにとってますます不可欠な要素になっています。 自動化するプロセスが増えるにつれて効率と生産性が高まり、従業員はより重要なタスクに集中できるようになります。 Kubernetes は企業がコンテナアーキテクチャに対して日常業務を自動化できるようにし、時間を最大限に効率的な方法で使えるようにします。 自動化オペレーションによりヒューマンエラーが起こる可能性もなくなるため、正確性も向上します。 自動化オペレーションは強力なツールです。
開発者の時間は貴重です。 企業にとってメリットがあるのは、ツールが優先度の低いタスクを処理し、開発者が最も重要なタスクに集中できる状態です。 Kubernetes によるインフラストラクチャの抽象化では、Kubernetes がコンピューティング、ネットワーキング、ストレージを管理します。 Kubernetes がこれらのタスクとアーキテクチャを管理するため、開発者はアプリケーション自体に集中できます。
Kubernetes は開発者のために健全性チェックを実行して各コンテナが正常に動作していることを確認します。 システムは停止や不具合が生じているコンテナを再起動させることもできます。 コンテナの健全性の管理は重要ですが、Kubernetes はユーザーが使用できるのは万全の機能で稼働しているサービスのみという状態も確保します。 問題が起きているサービスは Kubernetes がリセットするまでユーザーの目には触れません。
Kubernetes は多くの開発者にとっておなじみのアーキテクチャのさまざまな要素を使用しますが、Kubernetes 独自のものも多数あります。 Kubernetes でよく使用する知っておくべき用語をご紹介します。
Kubernetes 組織の最高レベルがクラスターです。 クラスターは Kubernetes を実行しているマシンとそのマシンに管理されているすべてのコンテナのグループです。 Kubernetes では、クラスターにはマスターがいます。マスターとはクラスター内の他のすべてのマシンをコントロールするマシンです。 一度に 1 つのマスターだけがスケジューラーとコントローラーマネージャーを実行できます。
各 Kubernetes クラスターには次の組織レベルであるノードが含まれます。 ノードは物理マシンである場合と VM である場合があります。 Kubernetes はノード内のアプリケーションの展開を処理します。このアプリケーション上で何が実行されているかは問いません。
ノード内にはポッドがあります。 ノードがポッドを実行します。 ポッドは Kubernetes 内で作成され管理される最も基本的なオブジェクトです。 各ポッドは Kubernetes で実行されるアプリケーションの 1 インスタンスを表し、1 つ以上のコンテナを有します。 ポッド内で、Kubernetes はコンテナ内のすべてのプロセスを開始、停止、複製します。 ポッドによって、ユーザーにはコンテナではなくアプリケーション自体のみが表示されます。
ユーザー要求に応じて、ポッドはノード内で作成/破棄されます。 ポッドの管理は複雑なため、Kubernetes はコントローラーを使用してポッドの作成、スピンアウト、破壊を行います。
Kubernetes サービスによってバックエンドポッドに常に変更を加えることができ、フロントエンドはそれを追跡することなくユーザーエクスペリエンスの提供を続けることができます。 サービスはポッドのグループがネットワーク経由でどのようにアクセスできるかを表します。 ポッドへのアクセス方法をコントロールすることで、バックエンドでポッドが作成/破棄される場合でも、アプリケーションはユーザーに対して一貫性を保つことができます。
ポリシーはポッドがシステム内でできることとできないことを指定します。 Kubernetes ポリシーはポッドが占有できる CPU、メモリ、ディスク容量を制限し、過剰使用を防ぎます。 ポリシー内の制限はその対象によって異なります。 メモリについては、ポリシーは絶対値を使用します (例：100 MB)。 CPU については相対値を使用します (例：50 %)。
Kubernetes をセットアップして機能させることは重要なタスクです。 開発者がセットアップした後は、クラスターに外部からアクセスする必要があります。 そのためのツールがいくつかありますが、最も柔軟性が高いのは Ingress です。 Ingress はクラスターへの HTTP 経由の外部アクセスを管理する API です。 Ingress のセットアップは複雑かもしれませんが、一度設定してしまえばクラスターのサービスに外部からアクセスするシンプルで堅牢な方法を提供します。
他の Kubernetes コンポーネントをすべて設定した後は、それらを漏れなく管理する方法が重要になります。 Kubernetes ダッシュボードは Web ベース UI で、開発者はこれを使用してすべてのクラスターリソースのトラブルシューティングと管理ができます。 ダッシュボードは別途インストールする必要があります (自動インストールされません) が、その後のセットアップと利用は簡単です。
企業が保有する情報のなかには機密保持が必要なものがあります。 Kubernetes には、機密情報のためにセキュリティのレイヤーを追加する機能があります。 Kubernetes Secret は特殊なタイプのコンテナで、アクセスを制限して Kubernetes にそのデータが機密であることを学習させます。
Secret は必要に応じてクラスター内のポッドがアクセス可能になりますが、それ以外のセキュリティリスクが高まるようなあらゆる可視性からは保護されます。 基本的に Secret はどのユーザーが情報にアクセスするかを制限しません。 その代わりに、アプリケーションには機能するために必要なデータのみを提供し、そのデータへの無制限アクセスは提供しません。
kubectl はクラスター内の運用を管理するコマンドラインインターフェイスです。 この CLI は Kubernetes API と通信します。 kubectl を使用するには次のような標準化構文があります：kubectl [command] [TYPE] [NAME] [flags]
小型端末で Kubernetes にアクセスする必要があるユーザーのために Minikube があります。 Minikube は Kubernetes をノート PC やその他のローカルマシンで実行するユーザー向けのオープンソースツールです。 Minikube は Kubernetes のサイズと複雑性を縮小してシングルノードクラスターにします。 Minikube は開発者だけでなく IT 担当者や経営幹部が使い慣れたデバイスから強力な Kubernetes 機能を利用できるようにします。 Minikube は kubectl をインストールした状態で使用すると最も機能を発揮します。
Kubernetes は主にアプリケーションを作成、管理、展開するために設計されています。 Kubernetes はどのように機能するのでしょうか。 開発者が Kubernetes をセットアップし、クラスターを定義してノードを作成します。 設定が終わると Kubernetes は必要に応じてポッドの作成と削除を行い、アプリケーションがユーザーにとって適切な動作を続けられるようにします。 Kubernetes にアクセスして管理するには、開発者はローカルマシンからのアクセスには Minikube を、外部アクセスには Ingress を、他のツールへのアクセスにはダッシュボードを使用します。
Kubernetes によって企業は何ができるのでしょうか。 Kubernetes の導入によって、次のような主要目標を達成できるようになります。
- 複数のホスト間でのコンテナのオーケストレーション
- アプリケーションの拡張
- アプリケーションの健全性チェック
- 展開のコントロールと自動化
- プロセス実行のためのストレージの管理と追加
- エンタープライズアプリケーションを実行するためのハードウェア容量の最大化
- 場所を選ばないアプリケーションの展開
- 開発速度の向上
Kubernetes とともに取り上げられることの多いプロジェクトが他にいくつかあります。 それぞれ独自のプロジェクトとして、開発者向けに異なるタスクを実行できます。 こうした他のプロジェクトは Kubernetes と混同されたり、ライバルとして位置付けられたりします。 ところがこれらのプロジェクトは実は Kubernetes と相性が良いのです。
Docker は Kubernetes より前から存在し、むしろ Kubernetes の誕生に貢献しています。 Docker は開発者がアプリケーションを実行するために必要なものを「ボックス」に区別できるツールです。このボックスは保存して必要な時に開くことができます。 Docker はコンテナを作成する方法のひとつです。 ただしアプリケーションが「ボックス」に保存されると、そのコンテナを管理して適切なものが保存され開かれていることを確認するための方法が必要になります。
そのために Kubernetes は作成されました。 Kubernetes は Docker が作成するようなコンテナアプリケーションを整理して管理するツールとして設計されました。 Kubernetes はコンテナを適切なスポットに誘導するよう設計されているため、ギリシャ語で「キャプテン」を意味する名前が付けられているのです。
Kubernetes と Docker はライバルではありません。 Kubernetes は Docker ありでもなしでも使用できます。これは両者がコンテナベースのアプリケーションの管理でそれぞれ独自の役割を果たしているからです。 ただし両者は同時に使用して強力なインパクトをもたらすこともできます。 Kubernetes は Docker を使用し、コンテナベースのアプリケーションを展開して管理することができます。
Mesos も Kubernetes とともに取り上げられることの多いプロジェクトです。 Mesos は Google Borg に対応するために作成された Apache プロジェクトです。 Mesos もコンテナオーケストレーションサービスを提供しますが、コンテナ化されたコンポーネントと同時にコンテナ化されていないコンポーネントも実行できるプログラムとして設計されています。 対象が幅広いため、Kubernetes を含む多数のプログラムを Mesos 内で実行できます。
Kubernetes の導入は一般に、会社のアプリケーション環境をクラウドへ移行する、または新しいアプリケーションとサービスを展開してさらに「クラウドネイティブ」にするための大型プログラムの一部です。 ServiceNow はこのトランスフォーメーションを支援する複数の結び付きがあり、変更管理、可観測性、クラウド管理など貴社に適切な Kubernetes アプローチを発見できるようサポートします。
Kubernetes の導入は DevOps などの最新の開発プラクティスと密接な関連があります。 規制の対象となる大組織は、クラウド内におけるアップデートのためリリースプロセスの一環としてガバナンスにも注力する必要があります。 しかしコンテナベースのアーキテクチャでは、多様な異種コンポーネントやコードデリバリの速度と移り変わりのしやすい性質など複雑性も増します。
ServiceNow で管理されている作業とサービスを開発プロセスとつなげることで、自動化された変更管理、エンドツーエンド KPI、フロー測定基準インサイト、監査を可能にします。 また DevOps Config という ITSM Pro の固有コンポーネントが、Kubernetes の実装によって貴社にメリットをもたらすクラウドでのサービス提供の一部として発生する幅広い構成アクティビティに特に強みを持つコントロールとインサイトを追加します。
Kubernetes はアプリケーションの機能と企業がコンテナベースのアプリケーションを管理する方法を改善します。 ところが、正常に運用するために必要な可観測性を得るには、組織はいくつかの課題に直面します。 ServiceNow クラウド可観測性は、組織の Kubernetes 実装を容易にするプロセスと構成に対する可観測性とインサイトを提供します。
組織がクラウドの利用を増やすには、クラウド管理を導入することが重要です。 ServiceNow の IT Operations Management はこれを実現しながら Kubernetes も実装します。
ITOM の詳細と、組織が Kubernetes を実装してアプリケーションの管理に活用する方法についてご覧ください。