株式会社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によるシステムの管理手法
スラヴィ：他にも話せる内容はいろいろありますね。
ナオト：例えば？
スラヴィ：アップデートとロールバックですね。アプリケーションをデプロイする際に、以前のバージョンに戻したい場合がありますよね。それを解決するのも一つの役割です。
もう一つは、リソースの軽量化です。これは従来の仮想マシンと比較したときの大きなメリットです。
以前は、異なるアプリケーションを動かしたい場合、それぞれに仮想マシンを用意する必要がありました。プロバイダーから事前に用意された仮想マシンを取得して、そこにアプリケーションを入れる形ですね。例えば、MySQLのセットアップ済みサーバーや、カスタムアプリケーション向けの仮想マシンパッケージなどです。
しかし、仮想マシンはサイズが大きく、ディスク全体を持ち運ぶ必要があります。独立性は高いですが、その分オーバーヘッドも多くなります。
一方で、Kubernetesやコンテナ技術を使えば、より小規模な単位で管理できます。仮想マシン全体ではなく、ZIPパッケージのような感覚ですね。
このモデルと比較すると、コンテナの運用には多くのメリットがあります。ただ、セキュリティの課題もあります。同じサーバー上で複数のアプリケーションを動かすと、それらが干渉する可能性があります。コンテナは同じLinuxカーネルを共有しているため、一つのコンテナが脆弱性のあるソフトウェアを実行し、それがカーネルまで影響を及ぼすと、同じマシン上の他のコンテナにも影響を与える可能性があります。
これが、仮想マシンとの大きな違いです。仮想マシンは独立性が高く、例えばWordPressとMySQLデータベースを完全に分離できます。セキュリティ面では仮想マシンのほうが優れていますが、その分リソースの負荷が大きくなります。
コンテナは軽量で、一台のマシンで数千ものコンテナを同時に稼働させることも可能です。
とはいえ、完全な隔離を実現するために、コンテナごとに小さな仮想マシンを用意するハイブリッドな手法もあります。ただし、これはコストがかかるため、特定のセキュリティが求められる用途でのみ採用されることが多いですね。
ナオト：この技術は、特定の企業以外にも販売できると思いますか？
スラヴィ：そうですね。その企業も、より多くの顧客に提供することを検討していると思います。
Kubernetesの運用経験を積めば、さらに多くの顧客に対してホスティングサービスを提供できるようになります。
ある企業はKubernetesのセルフホスト環境を求めていましたが、多くの企業はAWS、Google Cloud、DigitalOceanのようなマネージドKubernetes環境を利用しています。これらのサービスでは、数回クリックするだけでKubernetesクラスタを構築できます。
しかし、その企業やその顧客は、プライバシーの観点から、もしくは自社がクラウドプロバイダーであるため、自前のインフラでKubernetesクラスタを運用したいと考えていました。Kubernetesをゼロからセットアップするのは複雑で、マシン同士が安全に通信できるようにする必要があります。
適切にクラスタを構築すれば、コンテナをシームレスに移動できますが、管理には時間と手間がかかります。
単純にKubernetesをデプロイしただけでは、高可用性を実現するのは難しいです。そのためには、適切な冗長化や設定が不可欠です。
まずはKubernetesクラスタの構築に注力し、その上でアプリケーションの管理サービスを提供する形になります。
Kubernetesは拡張性が高く、サーバー間の通信レイヤーもプラグインとして実装されているため、異なる暗号化方式や通信手法を採用することもできます。
デフォルトでは、サーバー間の通信が暗号化されていないKubernetesのインストール方法もありますが、異なるプラグインを使うことで暗号化を有効にすることができます。こうした設定や拡張機能の管理は大変なので、Kubernetesの運用はフルタイムの仕事になるほどです。
クラスタのセットアップだけでなく、アプリケーションの管理も重要です。開発者にはクラスタ全体の管理権限を与えず、特定のプロジェクトのみアクセスできるようにする必要があります。
また、サーバー上に直接ソフトウェアをインストールすることを防ぐ仕組みも必要です。大規模な企業では、UIを通じてソフトウェアを手動でインストールするのは非効率的ですし、誰が何をデプロイしたのか管理しづらくなります。そのために、GitOpsが登場しました。
ナオト：GitOpsとは何ですか？
スラヴィ：GitOpsでは、デプロイメントの設定をGitリポジトリに保存し、構成ファイルとして記述します。
例えば、「WordPressを特定のプロジェクトのネームスペースにデプロイする」「使用するバージョンや設定を指定する」といった内容をテキストファイルに書いておきます。
手動でデプロイするのではなく、Kubernetesクラスタがそのファイルを読み取り、変更を適用します。
もし、他の開発者が翌日WordPressのバージョンを変更したとしても、その変更はGitの履歴に残るため、誰が何を変更したのかを正確に把握できます。
この仕組みにより、管理の透明性と追跡性を確保できます。
ナオト：ファイルは一つだけですか？
スラヴィ：いいえ、通常は複数のファイルで管理します。多くの場合、YAML形式を使いますが、ほかにもQLangなどの選択肢があります。
YAMLはシンプルですが、複数のアプリケーションをデプロイする場合、共通の設定が必要になります。例えば、データベースのホスト名を複数の場所で使いたい場合などですね。YAMLだけでは不十分なこともあり、HCLのような構造化された言語を使うと管理しやすくなります。
また、YAMLは自由度が高い分、ミスが発生しやすいという問題もあります。例えば、小さなスペルミスがあっただけでファイルが無効になり、Kubernetesがエラーを返すこともあります。より厳密な構文チェックができる言語を使うことで、こうした問題を防ぐことができます。
そのため、最近はGitOpsのリポジトリをYAMLからHCLに移行しました。
Kubernetesの技術領域は非常に広く、多くの企業が注目しています。ただし、最終的にはコストがかかるため、大企業向けのソリューションになることが多いですね。
ナオト：なるほど、新しい視点ですね。
How to manage systems with Kubernetes
Slavi: There are more points that we can talk about.
Naoto: For example?
Slavi: Updates and rollbacks. When you’re deploying applications, sometimes you want to restore the previous version. That’s another problem it solves.
Another one is lightweight resource usage. It’s the first advantage listed, comparing it to traditional virtual machines. Previously, if you wanted to run different applications, you’d have a virtual machine for each one. You could get pre-packaged virtual machines from a provider and run them. For example, a MySQL prepared server or a virtual machine package for a custom application.
Virtual machines are large, requiring you to ship the whole disk. They are independent but have a lot of overhead. With Kubernetes and containers, you operate on a smaller scale, working with zip packages rather than entire machines.
Compared to this model, running containers has many benefits. Security is a concern—running multiple applications on the same server can lead to interference. Containers share the same Linux kernel. If one container runs an insecure version of software and it escalates to the kernel, it can breach security and affect all other containers on the same machine.
This is a security problem compared to virtual machines, which provide much better isolation. A virtual machine keeps your WordPress separate from your MySQL database and other services. Virtual machines offer better security but come with more overhead. Containers are lightweight, allowing thousands to run on the same machine without issue.
There are hybrid approaches where each container runs in a very small virtual machine for isolation. This isn’t commonly done because it’s expensive, but for certain security-sensitive applications, it’s necessary.
Naoto: Do you think we can sell this technology to other clients besides a certain company?
Slavi: I guess so. The company is also considering selling it to many customers.
After gaining experience with Kubernetes, we can host more people on Kubernetes. A certain company wanted to self-host Kubernetes. Many people use hosted Kubernetes environments managed by AWS, Google Cloud, or DigitalOcean. These allow you to set up a cluster with a few clicks.
However, the company and their customer wanted their own self-hosted Kubernetes cluster on their infrastructure, likely due to privacy concerns or because they are a cloud provider themselves. Setting up Kubernetes from scratch is more complicated, requiring machines to communicate securely.
If the cluster is properly built, containers move around seamlessly, but you need to invest time in management. A simple Kubernetes deployment won’t be highly available. To achieve that, duplication and proper configuration are necessary.
First, we focus on creating the Kubernetes cluster. Then, we provide a service for organizing applications on top of Kubernetes. Kubernetes is highly extensible. The communication layer between servers is a plugin, meaning different encryption or communication methods can be used.
By default, some installations don’t encrypt communication between servers. Switching to a different plugin can enable encryption. There are many add-ons and configurations, making it a full-time job to manage Kubernetes clusters.
Beyond setup, organizing applications is crucial. Developers don’t get full access to the cluster but only specific projects. A system must be in place for this.
Another key aspect is preventing direct server installations. Manually installing software, even through a UI, is inefficient in larger companies. It’s hard to track who deployed what. That’s why GitOps exists—operations using Git.
Naoto: What does GitOps do?
Slavi: In GitOps, deployments are described in configuration files stored in a Git repository. For example, a text file might specify deploying WordPress to a project namespace with its version and configurations. Instead of deploying manually, the Kubernetes cluster reads these files and applies changes.
If another developer changes the WordPress version tomorrow, that change is recorded in Git history, showing who modified what. This approach ensures accountability and tracking.
Naoto: Just one file?
Slavi: No, many files, usually in YAML format. Other options exist, like QLang.
YAML is simple, but when deploying multiple applications, variables are needed—like a database hostname used in multiple places. YAML alone isn’t enough. More structured languages like HCL help manage these configurations.
Another issue with YAML is its openness. A small typo can create an invalid file without clear errors, causing Kubernetes to reject it. A stricter configuration language prevents such mistakes.
That’s why I recently switched our GitOps repository from plain YAML to HCL. There are many technologies involved, and we can discuss them in detail.
Naoto: Sounds new.
Slavi: Kubernetes is a vast area, and many enterprises focus on it. It tends to suit larger companies because, in the end, it’s costly.
この記事はインタビューをもとにAIを使用して作成されています。 This article was created using AI based on interviews.