株式会社LOWWS CTOのスラヴィ・パンタレーブ(Slavi Pantaleev)にインタビューし、 現在携わっているプロジェクトの中で興味深い技術や最新の知見について聞いていくコーナーです。
今回はKubernetesというサーバーインフラを柔軟に管理するシステムについて聞きました。
This is an interview with Slavi Pantaleev, CTO of LOWWS Inc., where we explore interesting technologies and the latest insights from his current projects.
In this session, we discussed Kubernetes, a system that enables flexible server infrastructure management.
The English article follows the Japanese article.
Kubernetesとは？
スラヴィ： 「もともとGoogleが開発したものの、実際にはGoogle内部ではKubernetesを使っていない。GoogleにはBorgという独自のシステムがあって、Kubernetesよりもはるかに優れていて、長年社内で使われている。」少なくとも、僕が聞いた話やネット上の情報ではそうですね。Googleはこんな感じでコンテナを管理しているわけです 今では、ほとんどのアプリケーションがコンテナとしてパッケージ化されていて、どこでも動かせるようになっています。シンプルに言うと、コンテナって一種のパッケージ形式みたいなものですね。ZIPファイルみたいに、アプリケーションと設定をまとめてパッケージ化して、別のコンピュータに移して実行できるんです。コンテナはアプリケーションをまとめて、いろんなサーバーで動かせる便利な方法なんです。いいところは、僕のPCで動くものが、あなたのPCでもほぼ同じように動くっていう点ですね。
Googleは長年にわたって、インフラ全体で大量のコンテナを動かしてきました。それに伴って、それらを管理するシステムを作り上げたんです。ただ単にコンテナを動かすだけなら簡単で、仮想マシン上にコンテナを起動すればいい。でも、何百、何千ものサーバーがある場合、「どこで動かす？」「他のコンテナはどうやってアクセスする？」「マシンが壊れたら、そのコンテナはどうなる？」といった課題が出てきます。だから、コンテナを別のマシンに移す仕組みが必要になります。
さらに、どんなアプリケーションを動かしているかも重要ですよね。小さいものか、大きいものか？どのマシンが最適か？コンテナのパッケージングだけじゃなく、リソースの割り当ても考えないといけません。CPU負荷の高いものもあれば、大量のメモリを使うものもある。Googleは、マシンがダウンしたときに自動でコンテナを移動させる仕組みを作りました。ネットワーク上の他のコンテナも、新しく移動したコンテナをちゃんと認識できるんです。そして、数千ものコンテナを動かすとなると、セキュリティの問題も出てきます。どのコンテナが通信できるのか、制限をかけることも重要ですね。
Googleは長年Borgを運用してきましたが、それをもとにオープンソース版としてKubernetesを開発しました。なぜかというと、Google Cloudはクラウド市場への参入が遅れたからです。AWSはすでに市場をリードし、最大のクラウドプロバイダーになっていました。Googleは競争力のあるサービスを作る必要があったわけです。最初の頃、AWSはサーバーを手動でセットアップする必要がありましたが、後にEC2などのサービスが登場し、さらにマネージドサービスも増えました。その後、サーバーレスコンピューティングが主流になり、ユーザーはアプリケーションコードを提供するだけで、AWS側がすべてを処理するようになりました。
AWSは独自のエコシステムを作り上げ、Googleがクラウドサービスを展開するには、それに対抗できるソリューションが必要でした。そこでKubernetesが登場したわけです。Kubernetesはアプリケーションを管理するための統一プラットフォームとして設計されました。今では、Kubernetesはクラウド間の壁を取り払う存在とされています。以前はAWSのサービスにロックインされて、他のプロバイダーに移るのが大変でした。でも、Kubernetesを採用するクラウドプロバイダーが増えたことで、移行がしやすくなったんです。さらに、Kubernetesはセルフホストも可能なので、柔軟性と独立性が確保できます。
今や、コンテナはアプリケーションをパッケージ化する標準的な方法になっていて、Kubernetesはそれを運用する強力なツールです。ネットワークポリシーの設定（どのコンテナがどこと通信できるか）、セキュリティ機能など、いろいろな機能が備わっています。Kubernetesは大規模なシステムですが、自己修復機能があって、コンテナがクラッシュしたら自動で再起動したり移動したりします。また、サービスディスカバリーやロードバランシングの機能もあり、コンテナ間の通信をスムーズにし、トラフィックの暗号化も実現できます。
Kubernetesは今や不可欠な技術になっていて、主要なクラウドプロバイダーはどこもKubernetesのホスト型サービスを提供しています。すぐに使い始めることができるし、必要に応じてセルフホストすることも可能です。まだまだ語るべきことはたくさんありますが、大まかに言うとこんな感じですね。
ナオト： なるほど、めちゃくちゃ面白いですね。
スラヴィ： そうですね、少しでも参考になれば嬉しいです。ちょっと混乱させちゃってませんよね？
ナオト： いやいや、大丈夫です。たとえ全部は理解できなくても、知ってることは全部教えてください。きっと役に立つので。
スラヴィ： じゃあ、こう思うかもしれませんよね。「コンテナを1台のマシンで動かせばいいんじゃない？ 普通のサーバーを用意して、そこにコンテナを動かせばいいだけでしょ？」って。
スラヴィ： それ、実は悪くない方法です。最初のうちはシンプルで分かりやすい。でも、Kubernetesの考え方って、「サーバーを特別扱いしない」ことが基本なんですよ。サーバーって、いつか絶対に壊れますよね？ だから交換できる前提で運用しないといけないんです。
たとえば、1台のサーバーにWordPressのコンテナを動かしてたとします。それで問題なく動いてたとしても、もしそのサーバーのハードディスクが壊れたり、メモリにトラブルが起きたらどうなるか？ 仮想マシンなら多少リスクは減りますけど、OSがクラッシュしたり、アップグレードで不具合が出たりしたら、結局そこにあるサービスは全部落ちちゃいますよね。
それに、1台だけで運用すると、いわゆる「単一障害点」になってしまって、どこか1カ所でも問題が起きたら全滅してしまう。アクセスが増えて負荷がかかると、サーバーが耐えきれなくなることもあります。たとえ小規模でも、OSやアプリをアップデートするたびにダウンタイムが発生するのはリスクですよね。だから、大規模なシステムやビジネス向けの運用には向いてないんです。
じゃあどうするかというと、同じアプリを複数のマシンで動かして、コンテナを柔軟に移動できるようにするのが理想なんです。たとえば、WordPressとデータベースを別々のコンテナで動かしてたとして、それが違うマシン上にあったとしても、ちゃんと通信できるようにしないといけない。さらに、セキュリティを考えたら、通信を暗号化する必要も出てきますよね。
ここで問題になってくるのが、「じゃあ、10台のサーバーにコンテナをどう配置するの？」「コンテナを別のマシンに移動させるには？」「サービス同士はどうやってお互いを見つけるの？」みたいなことです。たとえば、MySQLがマシン#3にあって、WordPressがマシン#10にあるとしたら、どうやってお互いを認識して通信するのか？
Kubernetesなしだと、こういう問題を全部手作業で解決しないといけません。でも、Googleがコミュニティと一緒に作ったKubernetesを使えば、こういう課題を全部まとめて解決できるんです。
とはいえ、Kubernetesってすごく奥が深くて、今までのアプリの運用とは全然違う考え方をしないといけません。もし自前でKubernetesを運用しようとすると、かなり大変です。Kubernetesのクラスタ管理って、それだけでフルタイムの仕事になるぐらい手間がかかるし、専門知識も必要だし、常に監視してないといけません。
僕もこれまでにある企業とそのクライアント向けにKubernetesを5つくらい構築してきました。中にはテスト用に作って、最終的には使わなかったものもあります。試行錯誤の連続で、トラブルシューティングにもめちゃくちゃ時間を使いました。Kubernetesを自前で運用するのって、本当に大変なんです。しかも、スケールアップすると専任の管理者が必要になります。
でも、一度環境が整えば、開発者にとってはめちゃくちゃ便利になります。たとえば、「MySQLとつながるWordPressのインスタンスを10個用意したい」ってリクエストがあったら、Kubernetesが自動的にうまく配置して、ちゃんと通信できるようにしてくれるんです。
ただし、問題はその「Kubernetesのインフラ自体をどう管理するか」ってところなんですよね。これがまた別の大きな課題なんです。
What is Kubernetes?
Slavi: So, it says, originally developed by Google and, internally, Google actually doesn’t use Kubernetes. They have their own service called Borg, which is much, much better, and they have been building it and using it for a long time internally. At least that’s what I’ve heard and what’s posted online. So they have such a system for running containers.
Nowadays, most applications are packaged as a container, which allows you to run them anywhere. A container is kind of a packaging format, if you want to put it simply. Sometimes I see it compared to a ZIP file—you take your application and configuration, package it up, and now you can transfer it to another computer and use it there. Containers are a great way to package applications and run them on different servers. The good thing is, what you run on your computer is essentially the same thing I run on mine, so it’s very homogeneous.
Google has been running many containers across their infrastructure for years. They built a system for managing these containers across all their servers. It’s not just about running the container—the simplest thing is taking a container and running it on your virtual machine. But when you have hundreds or thousands of servers, the question becomes: where do you run it? How do other containers reach it? If a machine dies, what happens to the container? It needs to be transferred to another machine.
Additionally, it’s important to consider the type of application running—is it a small one or a large one? Which machine can host it? It’s not just about packaging, but also about resource allocation. Some applications are CPU-intensive, others require more RAM. Google developed a system for running and relocating containers automatically when a machine fails. Other containers in the network can discover these new ones. When running thousands of containers, security is also a concern—you need to limit which containers can communicate and apply restrictions.
Google has had this system, Borg, for a long time, and they developed something similar but open-source called Kubernetes. Why? One reason is that Google Cloud was late to the cloud services market. AWS had a head start, becoming the largest and first cloud provider. Google needed to develop something competitive. AWS initially required users to manually set up servers or use services like EC2, and later introduced managed services. Over time, serverless computing became popular, allowing users to provide only their application code while AWS handled the rest.
AWS created a walled garden of services, and Google, in launching its cloud, needed a competing solution. Kubernetes became that solution—a unified platform for managing applications. Today, Kubernetes is seen as the great cloud equalizer. Previously, users were locked into AWS services and had to adapt when switching providers. Now, with Kubernetes, which is embraced by many cloud providers, migration is easier. Kubernetes can also be self-hosted, offering additional flexibility and independence.
Containers are now the standard for packaging applications, and Kubernetes provides a robust way to run them. It includes network policies, defining which containers can communicate, security features, and much more. Kubernetes is large, but it handles self-healing—containers restart or move automatically. It offers service discovery and load balancing, ensuring seamless communication between containers and encrypted traffic.
Kubernetes has become essential because all major cloud providers offer hosted Kubernetes solutions. Users can start quickly, and if needed, they can self-host for added control. There’s much more we could discuss, but this is the general picture.
Naoto: Oh wow, very interesting.
Slavi: Yeah, I hope I didn’t confuse you too much, did I?
Naoto: No, no. Even if we don’t understand everything, please tell us everything you know—it’s useful.
Slavi: So, you might be wondering, why not just run my container on a single machine? Get a normal server and run the container there.
Slavi: That’s actually a good way to start. In the beginning, it’s simple and easy. But the premise of Kubernetes is that you shouldn’t treat your servers as special snowflakes. They should be replaceable because, in reality, they will fail at some point.
If you run a single server and host your container there—say, running WordPress—it works fine. But what happens when your server experiences a hard disk failure or memory issues? Virtual machines reduce some of these risks since they abstract away the hardware layer, and cloud providers handle many failures seamlessly. However, operating systems can still crash, and an upgrade could break your server, making all services on it unavailable.
A single-server approach is a single point of failure, and it’s very likely to fail or become overloaded, especially as traffic increases. Even with low traffic, it’s risky because upgrading the OS or applications means downtime. This is why it’s not an appropriate deployment method for enterprises or larger-scale applications.
To ensure uptime, you need multiple machines running the same application and containers that can be moved dynamically between them. For example, if you run a database and a WordPress blog in separate containers, they need to communicate—even if they are on different machines. Sometimes, you also need encrypted communication for security reasons.
Managing multiple machines leads to questions like: How do I run my containers across ten servers? How do I move them between machines? How do they discover where other services are running? If my MySQL database is on machine #3 and WordPress is on machine #10, how do they find and talk to each other?
Without Kubernetes, you would have to solve all of these problems manually. Or, you could use Kubernetes, which Google has developed with the community to solve these issues—and many more.
Kubernetes is complex and introduces a whole new way of hosting and managing applications. If you self-host Kubernetes, be prepared for significant challenges. Managing Kubernetes clusters can be a full-time job, requiring expertise and constant monitoring.
During my work self-hosting Kubernetes for one of our customers, I have built about five clusters—some for testing, which we later discarded. We spent a lot of time experimenting and troubleshooting, and self-hosting Kubernetes comes with plenty of challenges. Once you scale up, you’ll need a dedicated person managing the cluster.
However, after setup, it becomes incredibly easy for developers to deploy applications. For example, they can request ten WordPress instances connected to a MySQL database, and Kubernetes ensures seamless communication between them.
The challenge is managing the Kubernetes infrastructure itself. That’s a problem in its own right.
この記事はインタビューをもとにAIを使用して作成されています。 This article was created using AI based on interviews.