株式会社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の将来性
ナオト：Kubernetesは将来的にもっと普及すると思いますか？
スラヴィ：はい、そう思います。サーバー上でアプリケーションを動かし、設定ファイルを手作業で編集するという旧来のモデルは、こういったより良い解決策―つまりコンテナを動かす方法―に取って代わられる可能性が高いです。
ナオト：良いですね。でももちろん、誰もがKubernetesを必要としているわけではないですよね？
スラヴィ：はい、そうです。小規模なお客様の場合、Kubernetesクラスタを運用するためには最低でも3台か4台のマシンが必要で、それはかなりのオーバーヘッドになります。もし小さなブログや小規模なアプリケーションしか運用しないのであれば、ホスティングするだけで4台ものサーバーの費用を払いたくはないですよね。
ナオト：もちろんです。
スラヴィ：ですから、他の選択肢もあります。例えば、Google Cloud Runのようなものでコンテナを動かすことも可能です。これはサービスで、Cloud Runと呼ばれています。Googleが提供する便利なサービスで、コンテナを簡単に動かすことができます。
ただし、Cloud Runは少しベンダーロックインの側面があります。これはGoogle Cloudの提供するサービスの一部ですので、一度使い始めると簡単には移行できません。ただ、コンテナで動かしているので、別の場所にデプロイすることは可能ですが、多少の労力が必要になります。
Cloud Runの良い点は、ただ単にコンテナを動かすことだけに特化しているところです。どこで動かすのか、どのサーバーで動かすのか、クラスタを構築するのか、複数のサーバーの費用を払うのかといったことを考える必要がありません。一部のサービスでは、スケールダウンをゼロにまで行える機能もあり、もしトラフィックがなければコンテナを破棄して料金が発生しなくなります。Google Cloud Runにそのような機能があるかはわかりませんが、そういったサービスもあります。
ですから、小規模なお客様―小規模な企業―はこのようなものを利用することができます。ウェブサイトを動かすためだけに、4台以上のマシンで構成されたフルのKubernetesクラスタの費用を払う必要はありません。
ナオト：分かりました。では、ひとつ質問させてください。もしあるクライアントがいつかKubernetesを使いたいとした場合、そのシステムを保有している間、内部で何らかの維持費用をかけてシステムを管理しなければならないのでしょうか？
スラヴィ：はい。
ナオト：では、どうやって切り替えるのですか？
スラヴィ：まず最初の問題として、場合によってはクライアントのアプリケーションがKubernetes上で動作するように設計されていないことがあります。
もしアプリケーションがコンテナ上で動かないのであれば、まずそのステップ―つまりコンテナとしてパッケージ化する―を行う必要があります。最初はDocker Composeでいくつかの異なるコンテナをまとめて動かすという方法もあるかもしれません。
これが最初のステップです。アプリケーションをコンテナ上で動作させるのです。そして必ずしもLinuxである必要はありません。
コンテナは従来Linuxベースですが、その前はSolarisなどの、アプリケーションを隔離するためのjailなどの仕組みを持ったオペレーティングシステムから始まった歴史があります。Linuxで大幅に良くなったと言えるでしょう。
しかし、今ではWindowsにもコンテナがあります。ある時点で、MicrosoftはDockerに対してWindowsコンテナ技術の開発に多額の資金を寄付しました。
スラヴィ：今ではWindows Nano Serverという、コンテナを動かすための小規模なWindows OSがあると思います。もし.NETアプリケーションやMicrosoftの技術で構築されたものがあれば、Windowsコンテナで動かすことができます。
ただし問題は、WindowsコンテナはWindowsサーバーが必要になるという点です。
KubernetesクラスタにWindowsサーバーを組み込むことは可能です。例えば、Kubernetesのセットアップで10台のLinuxサーバーと5台のWindowsサーバーを持たせると、WindowsコンテナはWindowsサーバー上で動作することになります。
ナオト：でも、それは複雑で面倒そうですね。
スラヴィ：はい。ですから、Kubernetesに移行する最初のステップは、アプリケーションをコンテナとしてパッケージ化し、最初はDocker Composeで動かしてみるということです。
Docker Composeで動かすか、単純なDockerコンテナとして動かすかすると、Kubernetesへの移行が容易になります。
また、「12-Factor App」という方法論もあります。これについては調べるか、AIに聞いてみると良いでしょう。
スラヴィ：12-Factor Appのアプローチは、主にアプリケーションを再利用可能に、コンテナとしてパッケージ化し、クラウド環境で動作するようにする方法について語っています。
これは12のルールがあり、設定の扱い方、ファイルの保存方法、アプリケーションの構造化の仕方などについて記述されています。
ひとつの課題は共有ストレージです。例えば、PHPで書かれたアプリケーションとPythonで書かれたアプリケーションという、2つの異なるアプリケーションが、ファイルシステム上で同じディレクトリを共有しているとします。
これら2つのアプリケーションを異なるサーバー上のコンテナとして動かす場合、そのフォルダをどのように共有するかが問題になります。
これは問題となります。一般的な解決策は、AWS S3のようなオブジェクトストレージやその他の代替手段を用いることです。
つまり、共有ディレクトリに書き込むのではなく、中央集権的なオブジェクトストレージシステムに書き込むのです。
現代のアプリケーションはすでにこの点を考慮して作られているので、Kubernetesに移行するのはそれほど大きなステップではありません。しかし、やはり時間がかかります。
ナオト：そして、あなたの質問は、企業はシステムを維持するために誰かを必要とするのか、ということですね？
スラヴィ：はい。自前でKubernetesをホスティングする場合は、確実に誰かがそのシステムを維持する必要があります。しかし、多くの人はKubernetesを自前でホスティングすべきではありません。
むしろ、Google Cloud Kubernetes、AWS、またはDigitalOceanのようなマネージドKubernetesサービスを利用すべきです。
例えばDigitalOceanの場合、マシンの費用を支払うだけで、彼らがKubernetesクラスタの運用を手伝ってくれます。
ナオト：つまり、最初の費用はクラスタのセットアップにかかるということですか？
スラヴィ：はい。でも、一度クラスタを手に入れたとしても、次の問題は「どのようにしてアプリケーションをデプロイするか」です。
今度はYAML形式の設定ファイルを作成し、その中にアプリケーションの内容を記述する必要があります。
以前は、1つのDocker Composeファイルに5つのサービスが記述されていたかもしれませんが、Kubernetesでは5つの異なる設定ファイルが必要になります。
また、ネットワークポリシーも定義しなければなりません。たとえば、
「私のPHPアプリケーションはMySQLと通信できるが、Pythonアプリケーションは他の何とも通信できない」 というように設定します。 このようなルールを定義するために、さらに設定ファイルを書かなければなりません。
たとえDigitalOcean Kubernetesを利用しても、このすべての設定は自分で行う必要があります。
ナオト：つまり、DigitalOceanがクラスタを運用していても、自分で全ての設定をしなければならないということですか？
スラヴィ：その通りです。GitOpsの設定や、ベストプラクティスの定義、HCLやYAMLでの設定ファイルの作成などを、誰かが準備して正しく行われるようにサポートする必要があります。一度設定が整えば、開発者が引き継いでアップデートをプッシュできるようになります。
ナオト：ああ。つまり、ある企業はクラスタの初期セットアップに多くの費用をかけ、そのリスクを負っているということですね。もし我々がミスをするとクラスタが壊れてしまうが、Google Cloudを使えば、何か問題が起こればGoogleが対応してくれるということですか？
スラヴィ：その通りです。Google Cloud Kubernetesを利用すれば、何か障害が発生した場合はGoogleが修復するので、ユーザーはただ利用するだけで済みます。
しかし、企業側としては、より低レベルな部分を全て自分たちで管理するため、コントロールは取れるものの、複雑さも増します。
ナオト：なるほど。でも、セットアップが完了した後も、どこでも同じ問題―アプリケーションの運用方法、リソースの共有方法、チームの分離方法―が残るということですね。
スラヴィ：はい。なのでたとえば、100台のマシンを持つクラスタがあるとして、それをどのように共有し、どのように各チームが自分のプロジェクトにしか取り組まないようにし、どのように互いに隔離するかということを考える必要があります。どんな状況でも、こういった問題は必ず発生します。
ナオト：はい、とても興味深いですね。最近は、日本の企業で予算を確保できるところが減っているため、以前のようなプロジェクトを獲得するのが難しくなっています。また、このような新しい技術を扱える人が日本には少ないので、これは良い機会になると思います。
スラヴィ：そのメリットは、顧客が大企業でリソースが豊富なことです。彼らは私たちの費用をカバーできるし、場合によってはそれ以上も支払ってくれるかもしれません。
ナオト：ですから、Kubernetesについて書くことは非常に意義深いですね。これから毎月、あなたが行っていることについて書き続け、あなたの時間を支払える新しいクライアントが見つかることを期待しましょう。時間が経つにつれて、さらに上達していくと思います。
スラヴィ：現在、ある会社でKubernetesを扱い始めてから約1年ですが、まだ学ぶべきことはたくさんあります。まるで始まったばかりのような気がして、ワクワクすると同時に怖さも感じます。理解できていないことが多く、ミスも簡単に起こりうるのです。従来のデプロイメントとは全く異なる大規模なシステムなので、これに到達できるプログラマーは少なくなります。天才でなくても大丈夫ですが、Kubernetesに特化し、学習、実験、失敗、そして新しいクラスタの構築に多くの時間を費やす必要があります。
ナオト：それは、もしかすると高収入の分野になるということですか？
スラヴィ：そう思います。こういったことをやっている人は他にあまり見かけません。Googleシートの質問の一つに「あなたの職業は何ですか？」とありましたが、正直なところ、もう分からなくなっています。以前はプログラマーとして主にコードの開発をしていましたし、チームであるプログラムに取り組んでいたときは少し管理もしていました。しかし、今ではある会社での私の仕事の大部分がサーバー構築に集中しています。
スラヴィ：以前はAnsibleによる自動化で多くの経験を積んできました。例えば、MatrixチャットサーバーをホスティングするためのMatrixプレイブックはAnsibleで書かれています。Ansibleは個々のマシンを構築する、いわゆる古いやり方で、仮想マシンを自動化でセットアップするものです。しかし、弊社ではKubernetesに切り替えたため、現在は主にKubernetesクラスタ上でGitOpsの設定を書いたり、プロセスの自動化を行ったりしています。また、人気の認証システムであるKeycloakを用いたシングルサインオンの設定を行い、Terraform（現在はOpenTofuと呼ばれています）で自動化しています。自動化が多くなってきました。
スラヴィ：そのため、私の職業は現在、DevOps、つまりDeveloper Operationsと呼ばれるのが最も適しているかもしれません。以前はシステム管理と呼ばれていましたが、今ではプログラミングの要素が大きく、設定をコードで記述し、変数を用い、スクリプトを組み合わせる必要があります。だからこそ新しい呼称が生まれ続けるのです。私は今、DevOpsエンジニアと呼ばれている状態ですが、時々コードを書くこともあります。両方の世界に精通するという、二重のチャレンジです。
ナオト：予想以上に多くのことを話してくれましたね。今後も、この会話を一回のセッションで全部話し尽くさないように、続けていけるといいですね。
Future of Kubernetes
Naoto: Do you think Kubernetes is going to be more popular in the future?
Slavi: Yeah, I think so. The old model of just running applications on servers and editing configuration files by hand is more likely to disappear in favor of better solutions like this—running containers.
Naoto: Good. But of course, not everyone needs Kubernetes, I guess?
Slavi: Mhm. Smaller customers… So, to run a Kubernetes cluster, you need at least three or four machines, and that’s a lot of overhead. If you have a small blog or a small application, you don’t want to be paying for four different servers just to host it.
Naoto: Of course.
Slavi: So, there are other alternatives. You can still run containers with something like Google Cloud Run. It’s a service—Cloud Run. It’s a nice service by Google that lets you run containers easily.
But Cloud Run is a bit of vendor lock-in—it’s part of Google Cloud’s offering. If you get started with it, you can’t easily move around, but since you’re running a container, you can deploy it somewhere else. It will just take some effort.
The good thing about Cloud Run is it just lets you run a container, and that’s it. You don’t have to think about where, which server, setting up a cluster, or paying for multiple servers. Some services even allow scaling down to zero, meaning if no traffic is coming, it destroys the container, and you’re not paying anything. I don’t know if Google Cloud Run has such a feature, but some services do.
So, smaller customers—smaller companies—can use something like this. They don’t need to pay for a full Kubernetes cluster, running four or more machines, just to run a website.
Naoto: Okay. Let me ask you one question. If some client wants to use Kubernetes at some point, do they have to maintain the system with some cost internally while they have the system?
Slavi: Yeah.
Naoto: How do they switch?
Slavi: The first problem is that sometimes their applications are not designed to run in Kubernetes.
If your application doesn’t run in containers, you first need to make that step—package it as a container. Maybe you can run it in Docker Compose in the beginning—a few different containers together.
That’s the first step: make your application run in a container. And it doesn’t have to be Linux.
Containers are traditionally Linux-based, but before that, the history of containers goes back to Solaris or other operating systems like that, which had jails and other ways to separate applications. It got much better with Linux, I guess.
But Windows also has containers now. At some point, Microsoft donated a lot of money to Docker to develop Windows container technology.
Slavi: I think now there’s something called Windows Nano Server, a small Windows OS for running containers. If you have a .NET application or something built with Microsoft technology, you can run it in a Windows container.
But the problem is that Windows containers require Windows servers.
You can put a Windows server in your Kubernetes cluster. So, your Kubernetes setup can have, for example, 10 Linux servers and 5 Windows servers, and the Windows containers will run on the Windows servers.
Naoto: Sounds complicated and troublesome, though.
Slavi: Yes. So, the first step for someone moving to Kubernetes is to package their application as a container and maybe run it in Docker Compose first.
After you run it in Docker Compose—or even just regular Docker containers—it becomes easier to move to Kubernetes.
There’s something called the 12-Factor App methodology. You can search for it or ask AI about it.
Slavi: So, the 12-Factor App approach mostly talks about how to make your application reusable, packaged as a container, and suitable for running in a cloud environment.
It has 12 rules—things like how to handle configurations, store files, and structure applications.
One challenge is shared storage. Let’s say you have two different applications—one written in PHP and one in Python—and they share a directory on the file system.
When you run these two applications in containers on different servers, how do they share this folder?
This becomes a problem. The usual solution is object storage, like AWS S3 or other alternatives.
So instead of writing to a shared directory, they write to a centralized object storage system.
Modern applications are already written with this in mind, so switching to Kubernetes isn’t as big of a step. But it takes time.
Naoto: And your question is: does the company need someone to maintain the system?
Slavi: Yes. If they are self-hosting Kubernetes, they definitely need someone to maintain it. But, most people shouldn’t be self-hosting Kubernetes.
Instead, they should use a managed Kubernetes service like Google Cloud Kubernetes, AWS, or DigitalOcean.
With DigitalOcean, for example, you just pay for the machines, and they help you run the Kubernetes cluster.
Naoto: So, the first cost is setting up the cluster?
Slavi: Yeah. But once you have a cluster, even from DigitalOcean, your next problem is how do you deploy applications?
Now you need to create YAML configuration files and describe your applications in these files.
Before, you had a single Docker Compose file with five services. Now, you need five different configuration files in Kubernetes.
You also have to define network policies. For example, you might say:
“My PHP application can talk to MySQL, but my Python application cannot talk to anything else.” So, you write more configuration files to define these rules.
Even if you use DigitalOcean Kubernetes, you still need to do all this setup manually.
Naoto: So, even though DigitalOcean is running the cluster, you still have to configure everything yourself?
Slavi: Exactly. You still have to set up GitOps, define best practices, and write your configuration in HCL or YAML.
Someone needs to prepare all this and help ensure it’s done properly. Once it’s set up, developers can take over and push updates.
Naoto: Oh. So, a certain company is paying more for the initial setup of the cluster and taking the risk that if we mess up, the cluster breaks. But with Google Cloud, if something goes wrong, they fix it?
Slavi: Exactly. If you use Google Cloud Kubernetes, and something fails, it’s Google’s problem to fix. You just use it.
But for the company, we are doing everything more low-level—we have more control but also more complexity.
Naoto: I see. But after setup, we still have the same problem everywhere—how to run applications, how to share resources, and how to isolate teams.
Slavi: Yes. So, maybe you have a cluster with 100 machines, how to share it and how to make each team only work on their own project and how to isolate them from one another. You’ll have these problems regardless of everything.
Naoto: Yes, it’s very interesting. These days it’s harder to get projects like we used to because fewer Japanese companies have the budget, and they can’t find anyone in Japan who can do this. So, this is going to be a good opportunity.
Slavi: The advantage is that these customers are larger companies with more resources. They can cover our costs—and perhaps even more.
Naoto: That makes writing about Kubernetes very meaningful. Let’s keep doing this every month—write about what you’re doing—and hopefully find a new client who can afford your time. You’ll only get better with time.
Slavi: Right now, I have about one year of experience with Kubernetes at a certain company, but there’s still so much to learn. It feels like I’m just getting started; it’s both exciting and intimidating. There’s so much I don’t understand, and mistakes are easy to make. It’s a large system—completely different from traditional deployment—which means fewer programmers reach this level. It takes time; you don’t have to be a genius, but you must focus on Kubernetes as your specialty, spending lots of time learning, experimenting, making mistakes, and building new clusters.
Naoto: So maybe it’s a higher-paying field?
Slavi: I think so. I don’t know anyone else doing this. One of your questions on the Google Sheet was “What is your profession?” and honestly, I don’t know anymore. I used to be just a programmer—mostly developing code, with a bit of management when we worked on Super Navi with the team. But now, most of my work at a certain company focuses on building servers.
Slavi: I used to work a lot with Ansible automation—for instance, my Matrix playbook for hosting a Matrix chat server is written in Ansible. I have extensive experience with it. However, Ansible focuses on building individual machines, which is the old way: automating virtual machine setup on a per-machine basis. Now, with our company’s switch to Kubernetes, I mainly work on Kubernetes clusters, writing GitOps configurations and automating processes. We’re also setting up single sign-on with Keycloak—a popular authentication system—and automating it with Terraform (now called OpenTofu). There’s a lot of automation involved.
Slavi: Perhaps my profession is now best described as DevOps—Developer Operations. Previously, this would have been called System Administration, but now there’s much more programming involved. You write configurations in code, use variables, and tie them together with plenty of scripting. That’s why the name changed, and why new job titles keep emerging. I’d say I’m now a DevOps Engineer, though I still write code sometimes. It’s a double challenge, needing to be proficient in both worlds.
Naoto: Wow, you covered a lot more than we expected. I hope we can continue this conversation in the future without exhausting everything in one session.
この記事はインタビューをもとにAIを使用して作成されています。 This article was created using AI based on interviews.