Kubernetesの基礎から実際に使ってわかったメリット・デメリットまで解説

こんにちは。シニアITコンサルタントの茨木です。
社内の勉強会でKubernetesを取り上げたので、その内容（＋勉強会以降に補足した情報）をここで紹介します。

すでにゴリゴリとKubernetesを触っているエンジニア向けの勉強会ではないので、概念的な話や、Kubernetesがどういう案件に向いているかという話が中心です。
Kubernetesの利用を検討している方はぜひご覧ください。

Kubernetes（K8s）とは？

正式名称はKubernetesで、操舵手やパイロットを意味するギリシャ語が語源だそうです。

読み方に迷う人が多いと思います。日本人にとっては、ギリシャ語由来の名称を英語圏の発音を経て日本語化するという複雑な流れを経ているので、いろいろな解釈があり、クバネティス / クバネテス / クーベネティスなどの読み方をされています。
またKubernetes はK8sとの略称が用いられることも多く、この場合ケーエイツとも読みます。

カタカナ表記の場合クバネティスとされることが多そうですが、あえてカタカナに置き換える必要もないので、書く場合はKubernetes（K8s）が一般的です。

ここからが本題です。

Kubernetesとは何をするものか？

Kubernetesを簡単に表現するとこうなります。

簡単に…と書きましたが「コンテナ化」がわからないと、この時点でまったく意味がわからなくなるので、次にコンテナとは何かを説明します。

そもそもコンテナって何？

IT用語の「コンテナ」とは、容器、入れ物などを表す英語「container」に由来する技術で、おそらく多くの人がイメージする貨物輸送用のあの入れ物のように「大量のモノ（データ）を、早く、低コストで、簡単に、事故なく運搬する」ために用いられます。

システムにおけるコンテナとは何かを簡単に表現するとこうなります。

もう少し具体的に説明するために、従来の方法とコンテナの何が違うのか、進化の歴史も簡単に紹介します。

かなり昔
昔は物理サーバー上でアプリケーションを実行させていました。ひとつのサーバー上で複数のアプリケーションを実行させた場合、多くのリソースを消費するアプリケーションがあると、他のアプリケーションのパフォーマンスが低下してしまいます。それぞれのアプリケーションを別々の物理サーバーで動かせばこの問題は解決できますが、その維持には多くのコストがかかります。

ちょっと昔（従来の仮想化技術）
1台の物理サーバー上で、複数の仮想マシン(VM)を実行させる仮想化技術が生まれ、サーバーのリソースを効率的に使用できるようになりました（複数のアプリケーションを実行させた場合のパフォーマンスを心配しなくてよくなった）。
各VMは、「仮想ハードウェア」上で「各自の仮想OS」を持つため、仮想ではありますがそれぞれが「完全なマシン」として動きます。

コンテナを使った仮想化技術
「ちょっと昔」のVMと似ていますが、コンテナは「各自のOS 」を持たず、アプリケーション間でOSを共有する仮想化技術です。仮想環境内でOSを動かす必要がないため、VMと比較してコンテナは軽量だといわれます。
そして最初に書いたようにコンテナはアプリケーションを動作させるのに必要なものが１つにまとめられているので、扱いがとても簡単になります。

コンテナのメリット

• 環境構築に要する時間の削減
  事前にコンテナイメージを作っておけば、イメージを動かすだけですぐに環境を作ることができます。
• 本番運用における、環境要因によるトラブルの減少
  開発環境と本番環境が異なるハードウェアでも、同じイメージを使えば同じ動作をします。
• 障害時の復旧が早い
  保存したイメージから新しいコンテナを作ればすぐに復旧できます。

コンテナは「アプリケーションが安定して稼働する仮装環境を、高速かつ簡単に構築できる」技術だといえます。
そのため、「DevOps」や「マイクロサービス」など、システム開発のトレンドとなっている（多くの仮装環境を必要とする）技術・手法と相性が良く、コンテナも活用される機会がどんどん拡大しています。

なお、最近コンテナと呼ばれているものはほとんどがDockerという仮想化技術がベースとなっていて、これがデファクトスタンダードです。Dockerとは、docker社が開発している技術のひとつで、オープンソースソフトウェアとして公開されていています。

Kubernetesのメリットとは？

ここで再びKubernetesの話に戻ります。
先にKubernetesは「コンテナ化されたアプリケーションを合理的に運用するためのもの」と書きましたが、Kubernetesは何の役に立つのでしょうか？

コンテナ技術はそれ単体だと次のようなことの効率的な管理ができない（めんどくさい）という問題があります。

• 冗長化
• CPU、メモリの割当
• ストレージの割当
• ネットワークの設定（セキュリティ、ロードバランス）
• アプリケーションのスケール
• アプリケーションを無停止で更新する

この問題を解決するために「コンテナを管理するツール（コンテナオーケストレーションツール）」が欲しくなります。
そこで登場するのがKubernetesです!

Kubernetesで実現できることの例

• アプリケーションを無停止で更新できる
  新しいアプリを立ち上げてネットワークの向き先を変えて古いアプリを終了する一連の動作をKubernetesが簡単にやってくれます。
• アプリケーションを自動で復旧する
  Kubernetesがヘルスチェックしてくれて、コンテナが停止していたら自動で復活させてくれます。
• CPUやメモリの割当設定が簡単になる
  CPUやメモリやストレージの割当、ロードバランサーやネットワークの設定など、アプリケーションの実行に必要な基盤情報の設定がアプリケーション単位で可能です。
• 低稼働率のサーバーをなくす
  Kubernetesが複数のサーバーにアプリケーションを自動で割り振ってくれます。自分で細かく設定することもできますが、何も考えなくてもいい感じに仕上がります。

コンテナオーケストレーションツールはKubernetes以外にもいろいろありますが、Kubernetesはオープンソースソフトウェア（OSS）のため、特定の企業に支配されない（ベンダーロックされない）というのもひとつの特長です。
（KubernetesはもともとGoogleが開発した技術ですが、現在はOSSとして公開されています。後述しますが、ベンダーロックを避けるためにOSSにこだわるのかどうかはKubernetesを採用するかどうかの判断に大きな影響があると思います）

実際にKubernetesを使って感じたデメリット

Kubernetesのメリットはさまざまなところで紹介されています。検索すれば公式情報をはじめとして、より詳しい技術的な解説も簡単に見つかるでしょう。

一方で、「実際に使ってみてここが難しかった」という具体的な話はまだ公開情報が潤沢ではないかもしれないので、ここからはKubernetesを実プロジェクトで導入した経験があるエンジニアの感想として「いざ使ってみると結構ツライところもあるよね」という話を書きたいと思います。

ここがツライ①運用上必要なサーバーの台数が多くなる

Kubernetesのクラスター（コンテナ化されたアプリケーションを実行するためのセット）は複雑で、構造を簡単に示すと下図のようになります。

KubernetesのアーキテクチャはMasterとWorkerで構成されます。上図のように、Masterで全体のコントロールをする。Workerで実際のコンテナが動く。というかたちでサーバーを分ける必要があるのです。
（実はMasterとWorkerは兼業できるのですが、少なくとも本番環境ではMasterとWorkerは兼業しない方がいいです。兼業するとWorkerでの障害発生が、Masterに影響して何もできなくなる可能性があります。）

冗長性を考慮するとMasterは最低3台のサーバーが必要です。また、Workerの方も普通に考えて最低2台サーバー構成になるはずです（1台でも構築できますが、１台でいいのならそもそもKubernetesを使う必要性がうすいです）。

つまり、現実的な構成だとサーバーが最低でも5台必要になります。

ちなみに、クラウドベンダーが提供している「マネージドKubernetes」を使えば、サーバーのことはあまり気にしなくても大丈夫なのですが…。

主要クラウドベンダーの提供するマネージドKubernetesの例

• Amazon Web Services（AWS）のAmazon Elastic Container Service for Kubernetes（Amazon EKS）
• Google Cloud Platform（GCP）のGoogle Kubernetes Engine（GKE）
• IBM CloudのIBM Cloud Kubernetes Service（IKS）
• Microsoft AzureのAzure Kubernetes Service（AKS）

マネージドKubernetesを使う＝結局ベンダー依存になる。ということで、特定の企業に依存しない（ベンダーロックがない）というKubernetesのメリットが薄れてしまいます。
そうすると、場合によってはAWS独自のコンテナマネジメントサービス「Amazon Elastic Container Service（Amazon ECS）」など、専用のサービスの方がKubernetesよりも扱いやすい可能性があります。

ここがツライ②ストレージの扱いで苦労する

そもそもコンテナはあまりストレージを扱うのに適していないと言われているのですが…。

Kubernetesは、複数個のコンテナをいろんなサーバーに自動でスケールしてくれます。そのため保存するコンテナの外にデータを置こうとすると、データが一箇所にまとまらずいろんなサーバーに飛び散ってしまいます。これを解決するためには、何らかの外部のファイルシステムが必要になります。
外部のファイルシステムはKubernetesとは別のものなので、冗長性や可用性もまた別途考える必要があります。

なるべく次のような構成にしないと、本当に苦労します。

• コンテナはステートレスな設計にする（ファイルを保持しない！）
• DBはKubernetes上に構築するよりも、マネージドサービスを使う。

ここがツライ③拡張性が高すぎる！

Kubernetesは拡張性が高いので「頑張れば」大抵のことはできます。しかし、逆に言うと選択肢が多すぎて、自分の目的を果たすために一体何をやればいいのか判断に困ることがあります。
例えば、前項のストレージを扱うプラグインが、公式ページで紹介されているだけでもこれだけあります（2020年８月現在）。

• AWS Elastic Block Store
• AzureFile
• AzureDisk
• CephFS
• Cinder
• FC
• FlexVolume
• Flocker
• GCEPersistentDisk
• Glusterfs
• iSCSI
• Quobyte
• NFS
• RBD
• VsphereVolume
• PortworxVolume
• ScaleIO
• StorageOS
• Local

この中からどれを使えばいいのか調べるのはかなり大変です。
ただし、前述のマネージドKubernetes、例えばAmazon EKSを使っている場合はデフォルトでAmazon Elastic Block Store (Amazon EBS)を使ってくれるので、「何を選ぶべきか」ということであまり悩まなくて済みます。

ここがツライ④学習コストが高い！

前述の通り、Kubernetesはやれることが多いため、覚えないといけないことも多いです。
学習コストはかなり高いといえます。

ここがツライ⑤更新が早すぎる！

Kubernetesは3ヶ月に1回アップデートされます。1年前の記事に書いてあるコードをコピーして使ってみたら動かないというような問題が普通に発生します。そのためKubernetes利用者は常に知識をアップデートすることが必要になります。（ただでさえ学習コストが高いのに！）

また、AWSの提供しているマネージドKubernetes「Amazon EKS」の場合、最新3バージョンしか動かないので、最長でも9ヶ月に1回はバージョンアップの対応が必要です（3ヶ月に1回のアップデート3回分）。

そしてバージョンアップによって機能が変わり、古いコードが動かなくなるのはよくあることです。

直近の2020/08/26にリリースされた新バージョンの1.19ではサポートが1年に延長されたので今後多少は改善されそうですが、それでもわずか1年です。

ここがツライ⑥ユーザー管理が大変

Kubernetesは、クラスター（コンテナ化されたアプリケーションを実行するためのセット）を作る際にKubernetesのユーザー毎に権限を与えられます。しかし、ユーザーを一覧したり、追加したりする、いわゆる「ユーザー管理」的なことが非常に大変です。そのため、（そう頻繁ではないかもしれませんが）Kubernetesのユーザーを管理することが必要になる場合、かなり手間がかかります。

ちなみに、Amazon EKS の場合はAWS Identity and Access Management (IAM)と連携することで、ユーザー管理が容易になり、この点は気にならないと思います。

まとめ：Kubernetesを使う理由・使わない理由

Kubernetesの基礎からメリット・デメリットまで解説しましたが、いかがでしたでしょうか。
メリットはいろいろなところで調べられるので、この記事では実際にKubernetesを使って感じたデメリットを多めに紹介してみました。

しかし、「だからKubernetesはダメだ！」と言いたいわけではありません。

たとえばCI/CDに取り組みたい場合、Kubernetes用のCI/CDツールはいろいろ用意されていますし、Kubernetesユーザーは増え続けているため、これからも発展が期待できるといえます。
「CI/CDのためにKubernetesを使ってみたい」というように、目的に対してKubernetesの機能が適しているのならデメリットよりメリットの方が大きくなるでしょう。

「流行っているからKubernetesでやってみよう」という動機ではじめるのはお勧めしませんが、コンテナを導入した場合、コンテナ管理ツールの候補としてKubernetesを検討対象に入れるのは当然だといえます。
その際には、Kubernetesに固執せずメリット・デメリットを把握した上で、他の選択肢もしっかり調べてから決めるといいのではないか。というのが私の意見です。

実際、NCDCが取り組んだプロジェクトでも、はじめに「Kubernetesでやりたい」というご相談をいただいていたけれども、導入に向けていろいろ検証した結果、他の技術が採用されたというケースがあります。
（もちろんKubernetesを採用したケースもあります）

最後に、私の考える「Kubernetesを使う理由・使わない理由」を整理したいと思います。

Kubernetesを使う理由

簡単にいうと「それなりに大規模なサービスで継続的な開発が実施されている」場合は、Kubernetesを検討しても良いと思います。大規模システム、もしくは1つの大きなシステム基盤上に複数のシステムを作っていて、保守要員が社内に常駐しているようなものですね。
もちろん、Kubernetesを入れるということは、できるだけ自動化して保守にかかる人手を排除するという方針はあると思いますが、前述した通り、なんだかんだとKubernetesの世話で人手が必要になるので、そうした際にきちんと対応できる技術力・体制があることが重要だと思います。

具体例を挙げると、それなりの規模のシステムをマイクロサービスで構築していて「マイクロサービス化まではできたけど、これからの運用で管理が大変そうだな…」と考えているようなケースではKubernetesがとても魅力的に見えると思います。

また、どんなシステムや組織に適しているかという観点を離れて個人的な視点から意見をいうと、Kubernetesは拡張性が高く、いろいろな人が付随するサービスを作っているので、「次々と新しいことができるようになるのではないか」というエンジニア的な面白さはあります。

Kubernetesを使わない理由

「拡張性が高くて面白そう」な一方で、実際のシステムに載せると考えると、前述したようにKubernetesを使うと継続的な学習やバージョンアップが必要になるのは大きなデメリットです。
最低でも数ヶ月単位での手入れが必要なので、あまり保守を気にしない「作って終わり」のシステムの場合は、わざわざKubernetesを使う必要はないといえます。

また、Kubernetesのみでいろいろやろうとするとかなり大変なので、他のマネージドサービスと組み合わせて効率よく使う必要があります。そうすると外部のマネージドサービスに引っ張られるので、「特定の企業に支配されない」というKubernetesの利点のひとつ（OSSの利点）が薄れてしまいます。
だったら、「AWSでAmazon ECSを使おう」というようにその環境に特化したコンテナ管理の仕組みを入れる方が使い勝手が良くないか？と思います。

Kubernetes の相談はぜひNCDCへ

NCDCではここで取り上げたコンテナやKubernetes、またはマイクロサービス、サーバレス などの新しい技術を導入したい企業に、アーキテクチャコンサルティングや、リファレンス実装、技術コンサルティングなどのサービスを提供しています。

この記事に書いたような、経験に基づく実践的なコンサルティングを提供しますので、やってみたいけれども難しそうで導入を悩んでいるという方は、ぜひお問い合わせください。