株式会社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 advantages and disadvantages of using Kubernetes.
The English article follows the Japanese article.
Kubernetesの特徴：メリット・デメリット
ナオト： Docker Compose を使っていると、依存関係やライブラリの問題が時々発生するんですよね。バックエンドやフロントエンドのコードのデバッグとは勝手が違います。このあたりのインフラの問題について、Slaviさんはどうお考えですか？ また、どう対処されていますか？
スラヴィ：なるほど、具体的にどのような問題に遭遇されているかにもよりますね。一般的には、古いソフトウェアや JavaScript 周りで依存関係の問題をよく目にします。JavaScript は変化が速いですからね。先月作ったプロジェクトが、もうビルドできないなんてこともありえます。コンテナの良いところは、バージョンを固定できる点です。
ただ、皆さんそうしているわけではないようです。「MySQL の最新バージョンを使っています」と言う方がいます。今日時点での最新は MariaDB のバージョン 11 かもしれません。でも、5 年後にはバージョン 25 になっているかもしれません。コンテナ定義に latest と書いてしまうと、それが変わってしまう。これはよくある間違いです。Ubuntu の最新バージョンを使ってコンテナをビルドし、何かの最新版をインストールする、といったことをしてしまう。それは避けるべきです。「Ubuntu 22.04 を使います」と宣言し、特定のバージョンをインストールすべきです。
もちろん、5 年後にそのコンテナイメージが存在するという保証はありません。しかし、latest を使うほど大きな変化はありません。この latest を使うやり方が原因で、コンポーネントが動かなくなるのを何度も見てきました。以前は動いていたものが、動かなくなるんです。プロフェッショナルな開発現場では、コンテナイメージは固定された成果物として扱われることが多いです。それをそのまま使う。latest が別のものになってしまうので、ビルドし直したりはしません。
セキュリティの観点からは、バージョンを固定するのは逆効果になりえます。latest を使って常に再ビルドしていれば、最新のアップデートを取り込めます。しかし、Ubuntu 22.04.0 と指定してしまうと、いつかセキュリティの問題が発生します。バージョン番号を上げない限り、セキュリティアップデートは適用されません。つまり、バージョン固定は、セキュリティチームにとっては問題になりうるわけです。
とはいえ、バージョンを固定すること自体は良い考えです。そして、固定したバージョンを適切に更新する方法もあります。Renovate をご存知ですか？ ソフトウェアの依存関係を更新してくれるツールです。Git リポジトリを自動的にスキャンし、何を使っているかを判断して、それらを更新できます。Node.js のプロジェクトなら、package.json ファイルを見つけて、バージョンを上げてくれます。Docker ファイルを見れば、そのバージョンへの更新を提案してくれます。非常に魔法のようです。設定なしで動くことも多いです。この製品サービスを有効にするだけで、SaaS として無料で利用できます。
ナオト： それは便利そうですね。
スラヴィ：ええ、便利ですが、時々煩わしいこともあります。
ナオト： 想像できます。
スラヴィ：頻繁にソフトウェアのアップデートをプッシュしてくるので、マージして、テストして、再ビルドしなければなりません。頻繁すぎるアップデートは、厄介なこともあります。バージョン固定には、バージョンが古くなってしまうという問題がありますが、それには別の解決策、つまり依存関係を更新するツールがあるということです。
これはよくある問題です。Kubernetes 特有の問題ではありませんが、Kubernetes でよく見かけます。Kubernetes は従来とは異なるシステムであり、独自の問題と解決策を持ち始めています。従来の開発で慣れ親しんだものとは異なるソフトウェアを使うことになります。時にはそれが問題を引き起こします。そこで Kubernetes 特有の解決策が登場し、それを導入するとうまくいく。しかし、また別の問題が発生し、次々と解決策を追加していくうちに、最終的には非常に複雑になってしまいます。
もし、もっとシンプルな、昔ながらのデプロイモデルを使っていれば、そのような苦労はないでしょう。しかし、ある程度の規模を超えると、Kubernetes に移行したくなります。Kubernetes が問題を解決してくれるからです。しかし、Kubernetes は同時に多くの問題も引き起こすので、誰かがそれらも解決しなければなりません。これは非常に難しいことです。
ナオト： なるほど。
スラヴィ：そういえば、デバッグの話をされていましたね。Kubernetes でのデバッグについて知りたいということでした。
ナオト： ええ。
スラヴィ：Kubernetes でのデバッグは Docker Compose と似ています。異なるサービスがありますね。Kubernetes では、通常、コンテナに対して exec コマンドを実行できます。これがデバッグの一つの方法です。コンテナ内でターミナルを起動し、状況を確認できます。環境を調べたり、環境変数を確認したり、ファイルシステムを変更したりできます。
もう一つは、より多くのツールを使うことです。kubectl コマンドを使ってログを確認したり、専用のログシステムを構築したりできます。Kubernetes を扱う場合、通常は集中ログシステムが必要になります。何百台ものマシンがあり、コンテナがどこで実行されているかわからないからです。あるマシンに SSH で入ってログを確認する、というわけにはいきません。ログはあちこちに散らばっているので、集中ログが必要になります。Grafana Loki などが代表的です。これはログ収集の一般的なソリューションです。そして、promtail のような他のソフトウェアを使って、ログを収集し、Loki データベースシステムに送信します。そして、ツールを使ってこれらのログを集中管理された場所で確認します。ログは、さまざまな仮想マシンや物理マシンから収集され、一箇所に集められます。
デバッグと監視については、さまざまなポイントがあります。もしネットワークを使っているなら、Kubernetes のネットワークプラグインによっては、可観測性の機能があるかもしれません。私はよく、コンテナ間の通信の問題に遭遇します。特に、ネットワークポリシーを設定して通信を制限している場合に。時には制限しすぎてしまうことがあります。そうなると、なぜこのコンテナが別のコンテナと通信できないのか、なぜインターネットに接続できないのかをデバッグする必要があります。
Kubernetes のコンテナネットワークプラグインの中には、可観測性の機能を備えているものがあります。例えば、Cilium には Hubble があり、これは Cilium スタック内のネットワークトラフィックの可観測性プラットフォームです。これは Docker Compose を使っている場合には発生しない、別の種類の問題です。Docker Compose では、同じネットワーク上のすべてのものが互いに通信できます。追加の制限はありません。もしソフトウェアをマシン自体に直接デプロイしている場合、すべてが localhost 上で実行されます。何かが近くにあるのに、それに到達できない、といった問題は発生しません。この問題を解決するには、追加のツールやポリシーが必要になります。
Kubernetes は従来とは異なる世界であり、はるかに複雑になりえます。しかし、それには利点もあります。ソフトウェアに制限を設け、「私の WordPress は API サーバーと通信できない」といった設定をすることです。これには大きなメリットがあります。セキュリティが向上するのです。
通常、もし同じネットワーク、同じ Docker Compose に配置すると、すべてが相互に通信できます。そして、1 つのサービスが侵害されると、他のすべてがそれに巻き込まれる可能性があります。しかし、ネットワークポリシーを使えば、分離を実現できます。これは大きなセキュリティ上の改善です。しかし、その結果、問題が発生し、何が起こっているのかをデバッグする必要が出てくることもあります。
ナオト： なるほど、よくわかりました。
Kubernetes advantages/disadvantages
Naoto: I use Docker Compose, and sometimes there are dependency or library problems. It’s different from debugging backend or frontend code. What are your thoughts, and how do you deal with these infrastructure problems?
Slavi: I’m not sure what kind of problems you’re hitting. Typically, I see dependency problems in older software or in JavaScript, where everything moves fast. You can have trouble building a project from last month. The beauty of containers is you can fix versions.
Not everybody does that. People say, “I’m using the latest version of mySQL.” Latest today means version 11 of MariaDB. In five years, it would have moved to version 25. If you put latest inside your container definition, it’s going to change. It’s a common mispractice. They build containers using Ubuntu’s latest version and install the latest of something. You shouldn’t do that. You should say, “I’m using Ubuntu 2204,” and install specific versions.
This is no guarantee that in five years, this container image will exist, but it’s not such a big moving target that using the latest is. I’ve seen components fail because of this practice. Something that used to work doesn’t work anymore. In professional development, people are more often dealing with container images which are a fixed artifact. You just use that. You don’t try to build it because the latest will be something else.
From a security perspective, pinning your versions is counterproductive. If you’re using the latest and rebuilding all the time, you’re getting the latest updates. If you say Ubuntu 2204.0, at some point, it will have a security issue. Unless you bump that version number, you’re not going to get security updates. One solution is causing a problem for your security team.
But pinning versions is a good idea. There’s a good way to keep these versions updated. Have you heard of Renovate? It’s a tool to update your software dependencies. It scans your Git repository automatically and determines what you’re using and can update those things. If it’s a Node.js project, it will find its package JSON file and bump versions there. If it sees a Docker file, it will suggest updates to those versions. It’s very magical. It often works without configuration. You can enable this product service; it’s available as a SAS service that you can use for free.
Naoto: Sounds nice.
Slavi: It is nice and sometimes annoying.
Naoto: I can imagine.
Slavi: Because it pushes the software updates frequently, and you have to merge them, test, and rebuild. Too frequent updates could be a pain. One problem has a solution, which is pinning versions, and after you start pinning versions, you get to the problem of these versions getting outdated. There’s another solution that updates these dependencies.
That’s a common problem. It’s not Kubernetes-specific, but I see it in Kubernetes a lot. It’s a different system, and it starts to have its own unique problems and solutions. You’re getting software that is different from what you’re used to in traditional development. Sometimes this has problems. There comes some Kubernetes-specific solution, and you plug that in, and it works. But then you have some other problem, and you pile more and more solutions, and in the end, it all becomes very complex.
If you use some simple old deployment model, you wouldn’t have that pain, but once you grow past a certain size, you want to move to Kubernetes because it solves some problems. But it brings so many other problems, and someone needs to be solving those as well. It’s a very difficult thing.
Naoto: I see.
Slavi: You were talking about debugging. You wanted to know about the debugging story in Kubernetes.
Naoto: Yeah.
Slavi: It’s similar to Docker Compose. You have different services. In Kubernetes, you can typically also exec into containers. That’s one way of debugging things. You could get a terminal inside the container and check how things are there. You can inspect the environment, see the environment variables, or try to modify the file system.
The other is you’re using more and more tools. You can check logs using cube CTL, or you could have a dedicated system for logging. When you are dealing with Kubernetes, you would typically want a system for centralized logging because you have hundreds of machines, and you don’t know where your container is running. You cannot just SSH into one machine and get the logs there. The logs are everywhere, so the need comes for centralized logging. This is typically something like Grafana Loki. It’s a popular solution for logging. And using other software like prom tail, which gets the logs and sends them to the Loki database system. You would use tools to look at these logs in a centralized place. The logs could be pulled from many different virtual machines or physical machines, and you get them all in one place.
There are many different points about how to debug and observe. If you’re using networking, depending on your networking plugin for Kubernetes, there may be observability features there. I often encounter issues with communication between containers, especially if I set up some network policies to restrict communication. Sometimes you get things overly restricted. You have to debug why this container cannot talk to this other container or why it doesn’t have internet connectivity.
Some container networking plugins for Kubernetes have observability features. Cilium, for example, has Hubble, an observability platform for the networking traffic inside the Cilium stack. This is another problem you wouldn’t have if you were using Docker Compose because everything can talk to everything else on the same network. There are no additional restrictions. If you are deploying software directly on the machine itself, everything is running on localhost. You don’t have this problem where something is forbidden from talking to something nearby, but it can’t reach it. You need these additional tools and policies to solve this problem.
It’s a different world, and it can be a much more complex one. But there’s a benefit to that, to put restrictions on your software and to say, my WordPress cannot talk to my API server. There’s a huge benefit to doing that. It improves security.
Typically, if you put them in the same network on the same Docker Compose, everything can talk to everything else, and if one service is compromised, everything else can come down with it. But with network policies, you can create isolation, which is a big security improvement. But then you sometimes have trouble, and you need to debug what’s going on.
Naoto: I see.
この記事はインタビューをもとにAIを使用して作成されています。 This article was created using AI based on interviews.