前回の記事↓
今回は #2 ということで、Kubernetesの核となるコンセプトについて簡単に書いていこうと思います。
コンテナAPI
クラウドリソースを扱っているエンジニアなら嫌というほど聞くでしょう。
"可用性" や "スケーラブル"
どんなサービスも信頼性が高いことが求められているように思います。
システムに障害があったとしても、全体に影響しないように設計し、
24365(24時間365日)安定した稼働が求められているように思います。
また、システムのメンテナンスにおいても、これまで深夜の時間帯にサーバーのダウンタイムを設け、
その間にメンテナンス作業を行う。
基本的にサービスは世界中の人が使用しているということであれば、
そのようなメンテナンス作業を設けることはユーザーにとって、あまり都合の良いことではないかもしれません。
これからk8sの核となるコンセプトについて、3つ見ていこうと思います。
イミュータブル (immutability)
immutabilityの単語の意味は、"変化することができない性質" です。
プログラミング(IT)においても同様な意味で使用されることが多いですね。
変更不可のような意味合いを持つでしょうか。
本技術書では、
変更が積み重ねられることはない O'Reilly Japan - 入門 Kubernetes
というような訳され方をしています。
これまでコンピュータとソフトはミュータブルなインフラとして扱われてきたようです。
aptコマンドなどがその例でしょう。
古いものの上に新しいものがコピーされるようなことです。
一方イミュータブルは、一度作成された成果物は、ユーザの更新があっても成果物は変更されないということです。
k8s的にいうと、新しいイメージを置き換えるということになります。
宣言的 (declarative configuration)
続いて、宣言的について。
宣言的の対象的な命令的設定です。
この考え方は、上記のイミュータブルとミュータブルの考え方と同じような関係になります。
命令的設定は、命令の実行によって状態が定義されます。
これに対し、宣言的設定は、望ましい状態を宣言することになります。
このように、イミュータブルと宣言的設定はk8s的考え方として、重要だと思います。
状態を定義することで、変更や間違いに気づくことができ、
命令的設定では難しいソースの管理やコードレビューが適用できます。
間違いが起こった際も、ヴァージョン管理している宣言的状態を戻せばOKでしょう。
命令的設定は、ロールバックの手順も予め準備しなければなりません。
自己回復 (online self-healing system)
k8sは宣言的設定を行ったあと、その状態に一致するよう継続して動きます。
k8sは自己回復することで、オペレータの責任を軽減し、復旧作業をも簡単にさせます。
この3つのコンセプトは、サービスや組織(チーム)のスケールにも対応できることを示しているでしょう。
この後の記事で理解を深めていこうと思いますが、
分離アーキテクチャを重視されているk8sは、組織にとって、誰がどの領域を面倒を見ればよいかより分かりやすくしてくれているように思います。
本書では、上記3つのコンセプトが、
下記3つを提供するためにデザインされたものだと記載されています。
- ベロシティ (Velocity)
- 効率性 (Efficiency)
- 敏捷性 (Agility)
これで、アプリをデプロイする理由がなんとなく理解できたように思います。
続きは、デプロイ方法やk8sの中身に触れていきたいと思います。
前回の記事↓
