DevOps の話を追っていると、コンテナと Kubernetes が当たり前の前提として出てきます。
CI/CD も GitOps もデプロイ戦略も、動かす先がコンテナであることを説明抜きで置いています。
ところが、コンテナが何を解決し、Kubernetes が何を肩代わりしているのかを言葉にしようとすると、意外とあいまいでした。
2 つの役割を分けて押さえると、DevOps の仕組みがなぜこの 2 つを土台にしているのかにも説明がつきます。
コンテナはアプリと依存をまとめた隔離されたプロセス
Docker のドキュメントは、コンテナを「アプリの構成要素ごとに隔離されたプロセス」と説明しています。
実行に必要なものを自分の中に持ち、ホストに入っているソフトに頼らないので、開発マシンでもデータセンターでもクラウドでも同じように動きます。
説明の元は What is a container?（Docker Docs） です。
仮想マシンとの違いは、OS のカーネルを自分で持つかどうかにあります。
仮想マシンはカーネルやドライバまで含む OS を丸ごと動かしますが、コンテナは同じホストのカーネルを共有するため、同じ資源でより多くのアプリを載せられます。
コンテナの元になるのが、コンテナイメージです。
イメージは実行に必要なファイル・ライブラリ・設定をまとめたパッケージで、一度作ると変更できず、ファイルの変更を重ねた層でできています。
イメージの考え方は What is an image?（Docker Docs） にまとまっています。
イメージの形式や実行の仕方は、Open Container Initiative が業界の標準として仕様にしています。
なぜ DevOps の土台になったのか
DevOps が目指すのは、変更を小さく速く、安全に本番へ届け続けることです。
コンテナはその流れの中で、「どこで動かしても同じもの」を受け渡す単位になりました。
CI で一度ビルドしたイメージをテスト環境にも本番にもそのまま運べるので、「手元では動いた」というずれが入り込む余地が小さくなります。
イメージは変更できないので、直したいときは新しいイメージを作って入れ替えることになります。
動いているサーバーを直すのではなく、作り直して置き換える運用は、IaC や GitOps と同じ考え方の上に乗っています。
インフラをコードで管理する考え方は、別の記事で扱いました。
Kubernetes は宣言した状態に寄せ続ける仕組み
コンテナが 1 つなら手で起動すれば済みますが、数十、数百になると、どのマシンで動かすか、落ちたらどうするかを誰かが見る必要が出てきます。
その役を担うのが Kubernetes です。
公式ドキュメントは、コンテナ化されたワークロードとサービスを管理し、宣言的な設定と自動化を支えるオープンソースのプラットフォームだと説明しています。
Google が 15 年以上かけて本番のワークロードを大規模に動かしてきた経験がもとになっていて、2014 年にオープンソース化されました。
概要は Kubernetes の公式ドキュメントの「Overview」で読めます。
仕組みの中心にあるのは、望ましい状態と今の状態を比べ続けるコントロールループです。
ドキュメントは、これを部屋のサーモスタットにたとえています。
設定した温度が望ましい状態、実際の室温が今の状態で、サーモスタットは機器を入れたり切ったりして室温を設定に近づけます。
Kubernetes のコントローラーも同じように、クラスタを見張り、望ましい状態との差を埋める操作を止まらずに繰り返します。
たとえの原文は公式ドキュメントの「Controllers」のページです。
たとえば Deployment に「Pod を 3 つ動かす」と書いておけば、1 つが落ちてもコントローラーが新しい Pod を作り直します。
apiVersion: apps/v1
kind: Deployment
metadata:
name: web
spec:
replicas: 3 # 望ましい状態は「Pod を 3 つ」
# selector と template の labels は省略
template:
spec:
containers:
- name: web
image: example/web:1.4.0 # CI でビルドしたイメージ公式ドキュメントが挙げる機能は、サービスディスカバリーと負荷分散、自動のロールアウトとロールバック、自己修復、シークレットと設定の管理などです。
新旧の Pod を少しずつ入れ替えるローリングアップデートも、この仕組みの上で動いています。
落とし穴は入れれば楽になると思うこと
Kubernetes の公式ドキュメント自身が、Kubernetes は従来型の全部入りの PaaS ではないと書いています。
ソースコードをデプロイしたり、アプリをビルドしたりはしないとも明記されています。
ビルドのパイプラインや監視、ログの集め方は、自分たちで組み合わせて用意する前提です。
クラスタそのもののバージョンアップや、セキュリティの手当ても運用の仕事として残ります。
コンテナが数個で、落ちても手で上げ直せる規模なら、クラスタを持たずにコンテナを動かせるマネージドサービスも選択肢に入ります。
もう一つの落とし穴は、イメージの中身を誰も見ていない状態です。
変更できないイメージは、作った時点の古いライブラリも一緒に固めてしまうので、定期的に作り直す段取りが要ります。
最後に
コンテナは「どこでも同じに動く単位」を作り、Kubernetes はその単位を「宣言した状態」に寄せ続けます。
前者が受け渡しのずれを減らし、後者が運用の手作業を減らすという分担で見ると、CI/CD や GitOps がこの 2 つを前提にしている理由が分かります。
私も DevOps を学んでいる途中なので、次はイメージを作り直す段取りを CI にどう組み込むかを調べてみます。
以上です。
コメントを残す