株式会社LOWWS CTOのスラヴィ・パンタレーブ(Slavi Pantaleev)にインタビューし、 現在携わっているプロジェクトの中で興味深い技術や最新の知見について聞いていくコーナーです。
今回はKubernetesを通じて「コードによるインフラ設計 (Infrastructure as Code)」について話していきます。
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 “Infrastructure as Code” through talking about Kubernetes.
The English article follows the Japanese article.
Kubernetes設定、もっとスマートに
スラヴィ：以前にも話した通り、Kubernetes を設定する際には通常 YAML リソースを使用します。JSON も使えますが、一般的には YAML です。ほとんどの人は YAML リソースを管理しています。
管理方法はいくつかあります。一つの方法は、クラスタ上で直接リソースを設定することです。 つまり、YAML を用意して、kubectl を使ってクラスタに適用するという方法です。 kubectl は Kubernetes を管理し、その API サーバーと通信するためのコマンドラインツールです。 しかし、この方法は少し場当たり的なアプローチになります。 変更をその場で加えることになり、誰がいつ何を変更したのか把握できません。 そのため、アカウンタビリティ（責任の明確化）もトレーサビリティ（追跡性）もありません。
もう一つのアプローチとして GitOps があります。 GitOps とは、ソース管理を活用してリソースを管理する考え方です。 Kubernetes のコンテキストでは、YAML ファイルを用いて Kubernetes のリソースを設定することを指します。 GitOps は Kubernetes 以外にも適用できます。 例えば Terraform を使ってインフラを構築することも可能です。 この方法を用いることで、AWS や Azure などのクラウド上にインフラをセットアップできます。 GitOps のリポジトリを使うことで、Terraform のコードを管理できます。 つまり、GitOps は Kubernetes や YAML に限定されたものではなく、 Git を活用して運用管理を行う手法のことを指します。 「Infrastructure as Code（IaC）」や「Kubernetes をコードとして管理する」ことも含まれます。 本日は Kubernetes における GitOps について話していますが、 Terraform や他の IaC ソリューションについても話すことはできます。
ナオト：Kubernetes 以外にも適用できるのですね。
スラヴィ：そうですね。それについては次回、または別の機会に話すこともできます。 YAML を使うこと自体は有効ですし、Kubernetes を管理するうえで基本的な方法ですが、 YAML にはいくつかの課題があります。
まず、YAML は非常に脆弱です。 許可されていない内容を簡単に定義できてしまいます。 構文上は正しい YAML であっても、Kubernetes に適用すると「このドキュメントの形式は正しくない」と拒否されることがあります。 必要なフィールドが欠けていたり、逆に余計なフィールドが含まれていたりすることが原因です。
また、YAML は単なるテキストファイルです。 定義を拡張する機能は一部存在しますが、本格的なプログラミング言語のようにデータを動的に扱うことはできません。 例えば、他のファイルから値をインポートしたり、URL から値を取得したりして組み合わせることができません。 YAML ファイルはそれぞれが独立したテキストファイルであり、すべての値を手動で記述する必要があります。 そのため、大規模なシステムを管理するには非効率的です。 例えば、Kubernetes にデプロイする際、プロジェクトごとに異なるネームスペースを使用することが一般的です。 チームごとにネームスペースを分けたり、プロジェクトごとに独自のネームスペースを持たせたりすることができます。 このネームスペースを変数として管理したいのですが、YAML ではそれが困難です。
また、データベースの URL やシークレット情報などの機密情報を扱う場合も、 複数の YAML ファイルで同じ値を繰り返し記述するのは非効率です。 それらの値を一元管理し、異なるファイル間で共有できる仕組みが求められます。 最終的には YAML を生成することになりますが、 より効率的かつ重複を避けるために、Qlang や KCL などのツールを活用することが推奨されます。
ナオト：変数を多く利用できるので、より効率的にインフラを設定できるということですね。
Slavi: そうですね。ただし、これらのツールは単なる変数の扱いにとどまりません。 YAML にテンプレート機能を追加するだけなら、簡単なスクリプトを作成することでも解決できます。 例えば、PHP のように「$」記号を使って変数を定義し、それをテンプレートとして扱うことができます。 スクリプトを作成し、テンプレートを用いて YAML ファイルを生成することで、変数の問題を解決できます。
しかし、YAML の課題はそれだけではありません。 すでに述べた通り、YAML は構文的に正しくても Kubernetes には受け入れられないことがあります。 例えば、replicas=3 というフィールドを記述した場合、 これは Deployment や ReplicaSet には使用できますが、Pod には適用できません。 このように、リソースごとに異なるフィールドが存在するため、 誤った場所にフィールドを設定すると Kubernetes に拒否されることがあります。
また、YAML はインデントのズレが原因で意図しない設定になってしまうこともよくあります。 構文的には正しい YAML であっても、Kubernetes にとっては無効な設定になってしまうのです。 Qlang や KCL などのツールは、このような問題を解決するために開発されています。 例えば、Kubernetes の Deployment を作成する場合、 それが replicas フィールドを持つことを理解し、 そのフィールドが適切な場所に配置されているかを検証できます。 このようなツールを使えば、設定の誤りを事前に検出できます。 開発時にエディタでオートコンプリート機能を利用できるため、 設定を記述しながら誤りを修正できます。
もちろん、YAML でも誤りを Kubernetes 側で検出することは可能ですが、 それでは遅すぎる場合があります。 誤った設定を Kubernetes に適用し、エラーメッセージを受け取るよりも、 事前にミスを防げる方がはるかに効率的です。 このような理由から、Qlang や KCL などのツールが役立つのです。
ナオト：つまり、これらの言語を使用することで、システムをデプロイしたり構築したりする前に問題に気づくことができるということですね。
スラヴィ：そうですね。そして、コードの一部を再利用できるのも利点です。 ここからインポートして、そこから値を取得したり、関数を作成したりすることもできます。 それほど強力な言語ではないですが、それでも十分に便利で、小さなブロックを作成し、それらをレゴのように再利用することができます。 開発者にとっては有益で、信頼性も向上します。 ただし、セットアップには手間がかかります。 残念ながら、現時点では、すべてをスムーズに接続して、すぐに機能するようなシステムを見たことがありません。
最近KCLを使用していて、GitOpsリポジトリを整理するために、さまざまなスクリプトや補助プログラムを組み合わせて使わなければなりませんでした。 いくつかのソリューションを見つけましたが、他にも探すことができるかもしれません。 ただ、私が使っていたソリューションの名前を忘れてしまいました。 とはいえ、どれも完璧で洗練されたものではありませんでした。 もし無限に時間があれば、自分でこういったものを作りたいですね。 また手動で作成するのに苦労するのは避けたいので。
将来的にこういったものが発展するかもしれませんね。 Kubernetesについて読んだり、人々のコメントを見たりすると、多くの人がYAMLのスパゲッティコードに悩まされていることが分かります。
これは誰にとっても共通の問題で、多くの人が解決策を求めたり、実際に作ろうとしたりしていますが、現状ではあまり良い状況とは言えません。
ナオト：YAMLファイルは、通常かなり長いコードになるのでしょうか？
スラヴィ：場合によっては長くなることもありますが、通常は100行程度のリソース作成コードになることが多いですね。そして、Kubernetesを扱う際には、さまざまな種類のリソースが関係してきます。 デプロイメントを行うときには、設定が「ConfigMap」と呼ばれる別のリソースから参照されることが一般的です。 場合によっては、複数のConfigMapをこのデプロイメントに組み込むこともあります。 さらに、多くのシークレット（Secrets）も利用することがあります。 このデプロイメントは設定や環境変数をシークレットから取得します。 シークレットもKubernetesのリソースの一つです。 通常、個々のリソースは小さい単位で、それらが互いに接続されている構造になっています。 単一の長大なファイルにすべてを記述するわけではありません。 そのため、より構造化された言語や、高レベルの設定言語を使用すると、これらのファイル間で共通データを参照しやすくなります。 ただし、一般的には複数のファイルが存在し、時には非常に多くのファイルになります。 デプロイメントに関して言えば、デプロイメントリソースのほかに、ConfigMap、シークレット、ネットワークポリシーなども必要になります。
ネットワークポリシーは、このコンポーネントのネットワーク通信の許可や制限を指定するリソースです。 例えば、受信トラフィックや送信トラフィックの制御、許可や禁止される通信の設定を行います。 また、このサービスをインターネットに公開するためのリソースも必要になります。 コンテナをデプロイして実行するだけではなく、Kubernetesに対して「このURLで公開すべき」「SSL証明書を適用すべき」といった指示を与える必要があります。 これを実現するためには、さらに多くのリソースを追加し、設定を行います。 通常はこれらも別々のファイルになります。 もちろん、YAMLには複数のドキュメントをひとつの大きなYAMLファイルにまとめる機能があります。 「—（ハイフン3つ）」で区切ることで、1つのファイル内に10個の異なるYAMLドキュメントを含めることが可能です。
とはいえ、一般的にはリソースごとに個別のファイルを作成する方が一般的です。 そうすることで、検索や編集が容易になります。 ただし、ソフトウェアのインストール用のYAMLファイルでは、すべてのリソースを1つのファイルにまとめることもあります。 こうすることで、単一のYAMLファイルを適用するだけで50以上のリソースを一括インストールできるため、インストールの手間を省くことができます。 しかし、開発には向いていません。 開発時には、すべてを個別のファイルに分けて管理する方が望ましいです。 そうすることで、エディタでそれぞれのファイルを見つけやすく、小さな単位で作業を進めることができます。
Smarter Kubernetes Configuration
Slavi: As we discussed before, to configure Kubernetes, you typically use YAML resources. It could be JSON as well, but typically it’s YAML.
Most people just manage YAML resources.
There are multiple ways you can do it. One way is you directly configure resources on the cluster. So you get some YAML and you push it to the cluster using Cube CTL. The command line tool for managing Kubernetes, for talking to its API server.
This is a little bit of an ad-hoc approach. You’re making changes just like that. You don’t know who is making what change and at what time, and there’s no accountability, there’s no traceability.
The other approach is you use GitOps, which is the idea of using source control to track these resources. In the context of Kubernetes, these are YAML files typically, which configure Kubernetes resources.
GitOps generally also applies to other things. You could set up your infrastructure using Terraform. This way you can set up your infrastructure on AWS or Azure, or any other cloud.
You can do it with a GitOps repository as well. In this Git repository, you’re storing Terraform code. GitOps is not just about Kubernetes and YAML, it’s about the practice of using Git for managing your operations.
Infrastructure as code or configuring Kubernetes as code as well. In this case, we are talking today we’re talking about GitOps in the context of Kubernetes. If you’d like, we can also talk about Terraform or other similar infrastructure as code solutions.
Naoto: It can be other than Kubernetes.
Slavi: It could be a topic for next time or for later.
Using YAML works and that’s unfortunately is the most foundational thing for managing Kubernetes, but YAML is very fragile.
You can easily define something which is not allowed. It could be valid YAML syntax, but once you push it to Kubernetes, it could tell you this is not the document shouldn’t look like this. You’re missing some fields or you have extra fields or, typically it wouldn’t complain about extra fields.
You could produce some YAML which is syntactically correct, but which Kubernetes will reject.
That’s why there is the need to use other and better tools. The second problem with YAML is it’s just a text file.
While there’s the ability to extend certain definitions and stuff like that, it’s not really a real programming language for passing data around or you can’t have one file import something from the other and take a URL from here and get another value from there and combine them to produce something.
Each YAML file is just an independent text file. Everything needs to be hard-coded there.
This is not very efficient for when you want to manage a larger system. You typically have different resources and let’s say you are deploying to Kubernetes and you have a namespace where you are deploying your project.
Each team may get an individual namespace or each project may get an individual namespace. You want to have this as a variable, this namespace value. Then you have 15 different resources.
Let’s say you’re deploying a database, some configuration, and different resources like that. You want each of these to reference this namespace value. You don’t want to hardcode it into each text file individually.
Or you want to get some database URL from somewhere or another sometimes a secret value. A configuration which is sensitive information. You want to manage these variables, these values and you want to pass them around to different files to produce the final result.
In the end, you will still produce YAML, but you will use other tools to help you create it more efficiently, more without repeating yourself.
That’s why we get these other languages, Qlang or KCL.
Naoto: That allows to use many variables and that would be more efficient to set up the infrastructure.
Slavi: Some of these languages not only deal with passing variables.
This part you can probably fix yourself by using YAML and some small templating script. Let’s say you write a small script, you have your YAML and inside it you define something with a variable. Let’s say you are a fan of PHP, you would use a dollar sign to limit where the variable starts.
You could script it and produce YAML files using templates and solve the variable problem. But it’s not just that that these tools are solving.
I already touched on it before, but with YAML, the other problem is you could produce something which is valid YAML as far as syntax goes, but still wouldn’t be accepted by Kubernetes.
Because maybe you use the wrong field for the wrong type of resource. Let’s say maybe you said replicas equals three. This could be used in the specification of a deployment or replica set, but you cannot use it on a pod resource.
You can use it in some places, but not others and each resource has its own fields. Sometimes mistakes could happen. You could use something in the wrong place. With YAML, this is very common and very easy to do it due to indentation. Let’s say you indent things incorrectly, it could still be correct YAML, you just move things around a bit.
But it’s not a valid configuration as far as Kubernetes is concerned. These tools understand the structure that the final result needs to have.
If you’re creating a Kubernetes deployment, it knows it can take a replicas field somewhere in the structure of it, but it cannot take the replicas field in another place or another type of, say, another Kubernetes resource doesn’t get a doesn’t have a replicas field.
It knows about all that and when you’re writing the configuration, it can point out these mistakes.
It can be helpful during development, you can get auto-complete in your source code editor and you know what you’re writing and you know that it’s correct even before you try to push it to Kubernetes.
The mistake will be caught eventually. Even if you’re using YAML and you make a mistake and you push it to Kubernetes, it will usually catch it. Depends on how you where your problem is with the YAML configuration, it would usually catch it. Sometimes not, but it would usually catch it.
But this is too late. This is often times too late. You don’t want to be producing something broken and pushing it to Kubernetes and getting error messages there. You want to know about it while you’re writing it and while you’re producing it.
That’s why these languages, like Qlang or KCL and probably even others that we’re not discussing here, that’s why they shine. They help with all of that.
Naoto: So, using these languages allows us to notice before deploying or building the system.
Slavi: And they allow for reusing parts of the code. You can import something from here and take a value from there and you can even create, like, functions. It’s not a very, very powerful language, but it’s still useful enough that you can build, like, little blocks and reuse them like Lego.
It’s helpful for developers, and it increases reliability.
It takes more effort to set it up. Unfortunately for now, I haven’t seen a very smooth system where you can wire everything together and have it just work.
In my usage of KCL lately, I’ve had to piece it together by myself with different scripts and helper programs around it to organize my GitOps repository.
I saw some solutions and we can probably search for more and or try to find the names because I forgot the name of the solutions I was using, but nothing was really polished and well done.
If I have infinite amount of time, I will probably work on something like this myself, so I don’t have to suffer again trying to create this manually. Maybe this will develop in the future. Because every time I read about Kubernetes and people’s comments about that, it’s dealing with all the YAML spaghetti that people are complaining about.
This is a common problem for everyone and many people are looking for a solution and trying to build a solution, but so far it’s just it’s not a great situation.
Naoto: Is the YAML file typically be really long code?
Slavi: Sometimes it could become long, but usually it’s within maybe 100 lines or something like that, just creating some resource. And typically when you’re dealing with Kubernetes, you have different types of resources. When you’re making a deployment, you’re typically referring to, configuration is coming from another resource called a config map.
Sometimes you would use multiple config maps wired into this deployment. And sometimes you would have a bunch of secrets as well. So this deployment will pull configuration or environment variables from secrets, which is a secret is another Kubernetes resource. You would typically have small resources which are kind of connected together.
It’s not a long single file with all of these things. That’s why probably using a more structured language, more higher-level configuration language helps for referencing common data between these files.
But typically it’s multiple files and sometimes a lot of files. For deployment, you would have this deployment resource. You would have config maps, secrets. Sometimes you would have network policies.
These are another type of resource which specifies who, how the network communication works for this component. Incoming traffic or outgoing traffic, what is allowed and what is forbidden.
And typically you would have other resources which expose this service to the internet. It’s not just deploying and running the container. You want to tell Kubernetes, this should be exposed to this URL and it should have an SSL certificate. You do that with by adding more resources, so more configuration.
Typically this is another file. Of course, YAML has this feature that you can have a large YAML file containing multiple documents, by separating them with dash dash dash. You can have ten different YAML documents inside a single file. So this is also a possibility.
I think typically people use individual resources for each for each file. Each resource goes into its own file, because it’s easy to find it. Sometimes you would see installation files for software, which bundles all of these into a single YAML file.
This gives you an easy way to install. You install one YAML file and there are 50 different resources inside of it. This is a convenient thing for installation. But it’s not a convenient way to develop. Typically you would want all of these in a separate file. So you can find them in your editor and work on them in small pieces.
この記事はインタビューをもとにAIを使用して作成されています。 This article was created using AI based on interviews.