コンテナを効率的に運用・管理する標準ツール「Kubernetes」とは

2023年11月24日(金)
田中 智明
第7回の今回は、コンテナの効率的な運用・管理を実現する標準ツールとなっている「Kubernetes」について解説します。

はじめに

コンテナを単一のマシンで使用するならDockerは良い選択と言えます。開発環境を簡単に構築・破棄できるので、一時的なテスト環境を用意したり、コンテナの冪等性を利用して他の環境で発生した障害を手元の環境でも再現したりできるためです。また、これらの環境は並列で動かすことができ、今使っている環境を止めることなく他の環境を実行できます。

Dockerを使用すると開発効率が上がることは前回で説明しました。では運用面はどうでしょうか。プロダクション環境ではコンテナの運用が最も重要です。そこで今回は、効率的にコンテナを運用管理できる「Kubernetes」について解説します。

Kubernetesとは

Kubernetesはコンテナを効率的に管理するための「コンテナオーケストレーションツール」です。オーケストレーションツールとは、ソフトウェアにより運用管理を自動化するためのツールです。コンテナオーケストレーションツールを使用することで、複数のサーバーにデプロイされた複数のコンテナを運用し管理できます。

KubernetesはGoogleの社員により開発が開始されました。Google社内で使用されていた「Borg」と呼ばれるクラスタマネージャと、その後継モデルである「Omega」の設計を引き継ぎ、そこにGoogleが日々行っているデプロイから学んだすべてのことを組み込んでいるとされています。

以下のリンクはKubernetesがどのように生れたのか詳細に綴られています。

⚫︎Google から世界へ : Kubernetes 誕生の物語
https://cloudplatform-jp.googleblog.com/2016/08/google-kubernetes.html

以下のリンクでもKubernetesがどのように生れたのかが語られていますが、こちらは動画です。全編英語で見づらいという方は、日本語字幕をつけることをおすすめします。

Kubernetes: The Documentary [PART 1]
https://www.youtube.com/watch?v=BE77h7dmoQU

Kubernetes: The Documentary [PART 2]
https://www.youtube.com/watch?v=318elIq37PE

Kubernetesはオープンソースソフトウェア(以下、OSS)として公開されているため誰でも無料で使用できます。また、バグなどを発見した場合は誰でもフィードバックを送信し貢献できます。

デファクトスタンダード

コンテナオーケストレーションツールはいくつか存在しますが、現在はKubernetesがデファクトスタンダードとなっています。デファクトスタンダードとなった背景には、コミュニティの成長や主要なクラウドプロバイダーの対応などが考えられます。

コミュニティ

元々はGoogleを中心としたOSSのプロジェクトでしたが、現在ではCloud Native Computing Foundation(CNCF)という組織によってホストされています。CNCFには著名な開発者や大手クラウドプロバイダーなど多くのエンジニアや企業が参加しており、現在は8,012もの企業、77,115ものコントリビューターがKubernetesの開発に参加しています。

Kubernetes プロジェクト ジャーニー レポート
https://www.cncf.io/reports/kubernetes-project-journey-report-jp/

クラウド

主要なクラウドプロバイダーはKubernetesをマネージドサービスとして提供しています。Google Cloudであれば「GKE」、Azureは「AKS」、AWSは「EKS」など、マネージドKubernetesを提供することでKubernetesを簡単に構築し使用しやすくなりました。どれか1つはサービス名を耳にしたことがあるのではないでしょうか。Kubernetesの管理をクラウドに任せられるようになったお陰で、Kubernetesの管理に自信のなかったユーザーも積極的にKubernetesを使用できるようになりました。

Kubernetesの基礎知識

Kubernetesを理解するには、Kubernetes特有の用語や仕組みを理解しておく必要があります。ただし、Kubernetesの全容を把握するにはあまりにも巨大であるため、ここでは使用するにあたって困らない程度の、最低限の用語と仕組みについて説明します。

kubectl

Kubernetesを操作するためのコマンドラインツールです。kubectlによってアプリケーションのデプロイやリソースの管理、ログの表示などを行います。

マニフェスト

Kubernetesにオブジェクトを作成するためのYAMLフォーマットで記述された指示書です。Kubernetesオブジェクトはコンテナをどのように稼動させるか、必要なリソース、どのように振る舞うか、再起動が必要なのか、などの望ましい状態を記録します。マニフェストにこれらの情報を記述しkubectlを通じてKubernetesに伝えます。

ポッド

「ポッド」(Pod)は1つアプリケーションを表わす単位です。ポッドには1つ以上のコンテナが含まれます。1つのアプリケーションと表現したのは、アプリケーションが必ずしも1つのコンテナで実装されているわけではないからです。いくつかのコンテナを組み合わせて1つのアプリケーションとなる場合には、1つのPodに必要なだけコンテナを含めます。

ノード

「ノード」(Node)はポッドをホストするサーバーです。「ワーカーノード」と呼ばれています。Kubernetesクラスターには1台以上のノードが必要です。ノードでは実行されているポッドの状態を監視し、必要に応じてコントロールプレーンに状態を通知します。また、クラスター内部または外部からのトラフィックを目的のコンテナに転送する処理もノード内で行われています。

コントロールプレーン

「コントロールプレーン」(Control Plane)は、Kubernetesの頭脳にあたるプロセスです。コントロールプレーンを実行しているサーバー群を「マスターノード」と呼びます。ワーカーノードとポッドを管理し、クラスターに関する決定やクラスターイベントの検知および応答をします。例えばポッドの新規作成を検知すると、どのノードで実行するとリソースが効率良く消費されるかなどの計算を行い、デプロイ先のノードを決定してポッドの作成を指示します。コントロールプレーンでもポッドをホストできますが、構成をシンプルにするためコントロールプレーンにはコントロールプレーンのプロセスのみを実行している環境が多く見受けられます。

なぜKubernetesが必要なのか

単一のマシンでいくつかのコンテナを実行するだけならDockerの機能で十分でしょう。しかし、プロダクション環境では耐障害性や高可用性が求められます。複数のサーバーに複数のコンテナをデプロイし冗長化された構成を構築するのが一般的です。

運用面ではどうでしょうか。複数のサーバーにデプロイされたコンテナを管理し、必要に応じてロールアウトやロールバックをします。それぞれのコンテナには監視や負荷分散の設定が必要です。また、コンテナは高速に起動できるのがメリットであるため、これらの作業を高速に行なわなければコンテナのメリットを生かせません。

耐障害性や高可用性を満すためには複雑な仕組みを構築し、運用管理できる知識と経験が必要になることでしょう。また、この仕組みを24時間365日監視し管理できる人員も必要になってきます。なかなかに厳しい条件です。そこで近年ではこれらの監視や管理を自動化するソフトウェアに注目が集っています。それがKubernetesです。

以降で、Kubernetesが提供する機能を説明していきます。

サービスディスカバリー

KubernetesはコンテナにDNS名を付与することでコンテナを公開します。コンテナはデプロイする度にIPアドレスが変化する可能性がありますが、DNS名でアクセスすることでコンテナのIPアドレスが変化したとして以前と同じようにアクセスできます。また、コンテナを冗長化している場合にはDNSに複数のIPアドレスを登録することでDNSラウンドロビンを使用し、負荷分散しながら目的のコンテナに到達できます。KubernetesはDNSへIPアドレスを自動で登録します。

自動のロールアウトとロールバック

コンテナの望ましい状態をKubernetesに通知することで、Kubernetesはその状態となるようにコンテナを調整します。例えば、コンテナを複数実行するようKubernetesに通知しておけば、想定する台数と差が出た場合には想定台数となるように実行と停止を自動で行います。

デプロイ先ノードの決定

Kubernetesはそれぞれのノードの空きリソースとコンテナの要求リソースから、どのノードにコンテナを配置すると最小の台数でリソースを最大限活用できるかを自動で計算します。

自動修復

処理が失敗したコンテナの再起動または入れ替えを自動で行います。ヘルスチェックに応答しないコンテナを強制終了します。コンテナが正常稼動し処理の準備が整うまでクライアントからのリクエストをルーティングしません。

機密情報の管理

Kubernetesは機密情報を保持し管理できます。パスワードやトークンなどの機密情報をコンテナイメージに保存することなく、コンテナからKubernetesに保存されている機密情報にアクセスできます。機密情報がコンテナから切り離されていることで、コンテナを再作成せずに機密情報のみ更新できます。

Kubernetesのメリット・デメリット

Kubernetesは便利なツールですが、機能が豊富で自由度が高く、それぞれの機能を使いこなすには学習コストがかかります。Kubernetesを検討中という方であれば、機能を把握するよりメリット・デメリットを把握しておく方が良いでしょう。

メリット

・コスト
サーバー台数を削減できる可能性があります。Kubernetesは空きリソースのあるノードを積極的に使用します。空きリソースのあるノードにポッドを詰め込むことでノードの稼働率を上げます。つまり、少ないノードで最大限ポッドをやりくりできるため、結果的にサーバー台数を削減できます。

コンテナ管理コストを削減できる可能性があります。Kubernetesはコンテナの運用を自動で行います。従来のアプリケーション運用であれば、それぞれのサーバーや仮想マシンを監視し、問題が起きれば人の手で修復していました。24時間365日無停止で動かすのならそれだけ人員も必要になります。

・移植性
KubernetesはOSSツールであるため、ベンダーロックインされにくい傾向にあります。例えば、オンプレミスのKubernetesからAWS EKSに移植する場合、同じKubernetesのバージョンであればマニフェストを修正することなく適用できる可能性があります。クラウド間の移植でも同様です。もし問題になるとすればクラウドの機能を使って実装している部分や、クラウドごとにサポートしているバージョンが違い一致させられないときなどです。

デメリット

・サーバー台数の増加
メリットの説明で「Kubernetesはサーバー台数を削減できる可能性がある」と説明したばかりですが、耐障害性や高可用性を考慮した構成を取った場合、サーバー台数が増加する可能性があります。

例えば、3つのアベイラビリティゾーンで運用することを考えてみましょう。アベイラビリティゾーンの障害を考慮してコントロールプレーンとノードをそれぞれ3つのアベイラビリティゾーンに置きます。これだけですでに6台のサーバーが必要になってしまいます。物理マシンや仮想マシンならアプリケーションを動作させるサーバーだけあればアプリケーションを動かすことができますが、Kubernetesはコントロールプレーンの分も多くサーバーが必要になってしまいます。

・頻繁なアップデート・アップデート方法
Kubernetesは平均して4ヶ月に1回、年3回ほど新しいマイナーバージョンがリリースされます。サポート期間はリリースから12ヶ月間です。高頻度にマイナーバージョンがリリースされるため、積極的に新しい機能を使いたい人にはメリットですが、その都度学習が必要となるため学習コストが非常に高いとも言えます。

Kubernetesは複数のバージョンを飛ばしてアップデートすることはできません。1回にアップデートできるバージョンは現在使用中のバージョンから1つ上のマイナーバージョンのみです。例えば、1.26から1.28へアップデートする場合は1.26 → 1.27 → 1.28のように1つずつアップデートしていく必要があります。離れたバージョンにアップデートしたい場合はメンテナンス期間が長くなります。

おわりに

Kubernetesはコンテナの運用を自動化し、今まで人手で行われていた作業の大半を削減してくれます。非常に強力で便利な反面、すべての機能を使いこなすには相当な学習が必要となるでしょう。また、小規模なアプリケーションではオーバースペックとなりがちで、別のツールやサービスを検討する方が良い可能性もあります。

例えば、AWS ECSのようにコンテナをホストするだけのSaaSの利用を検討しても良いでしょう。Kuberneteに拘らずアプリケーションの規模に応じて使い分けをすると良いでしょう。

日本仮想化技術株式会社
ソーシャルゲーム業界で10年間インフラエンジニアとして活動し、現在は日本仮想化技術でOpsエンジニアを担当。DevOps支援サービス「かんたんDevOps」では仕組み作りや導入支援、技術調査などを行っている。

連載バックナンバー

設計/手法/テスト技術解説
第25回

AWSの監視サービス「CloudWatch」でサーバー監視を試してみよう

2024/8/9
本連載も今回で最終回となります。今回は、AWSの監視サービス「CloudWatch」を使って、簡単なサーバー監視を試してみましょう。
設計/手法/テスト技術解説
第24回

CI環境を構築して「ESLint」で静的解析を実行してみよう

2024/7/26
実践編第8回の今回は、「Dev Containers」でCI環境を構築し、静的解析ツール「ESLint」で静的解析を実行するまでの流れを解説します。
設計/手法/テスト技術解説
第23回

テストコードを書いて「GitHub Actions」でCIを実行してみよう

2024/7/12
実践編第7回の今回は、Webフロントエンド開発を例に、テストコードを書いて「GitHub Actions」でCIを実行するまでの流れを解説します。

Think ITメルマガ会員登録受付中

Think ITでは、技術情報が詰まったメールマガジン「Think IT Weekly」の配信サービスを提供しています。メルマガ会員登録を済ませれば、メルマガだけでなく、さまざまな限定特典を入手できるようになります。

Think ITメルマガ会員のサービス内容を見る

他にもこの記事が読まれています