Kubernetes anti-patterns: Let’s do GitOps, not CIOps!
Kubernete のアンチパターン： CIOpsじゃなくて、GitOpsを使いましょう！
TL;DR
前回GitOpsシリーズの続き、gitopsのアンチパターンを紹介します。
Kubernetesのデプロイ・オートメーションについて私たちが顧客と話をすると、アンチパターンを実装している人でも完全にアンチパターンを理解できている人はほとんどいないということに気づきます。実際Kubernetes CI/CDのチュートリアルの大部分はまさにこのアンチパターンについて解説されています。
このアンチパターンをとは何でしょうか？
CIシステムがビルドとテストを走らせるとき、アンチパターンは、Kubernetesへの直接のデプロイにフォローされます。これがどのように行われるかという点においての精巧さのレベルというのは変わってくると思います。もちろん、ほとんどのタイム・デプロイはかなり複雑なパイプラインの最終ステージにおいて実行されます。
また実装の詳細も変わります。kubectl set imageを使う方もいれば、一方でhelm upgrade, ksonnet applyや社内のテンプレート・ソリューションを使う方もいます。何を使っているかということは関係がありませんが、結局、そのメソッドは全くうまく機能していないのです。それでは今からその理由を説明します。
私たちはこれを“CIOps”と呼んでいます。これについては様々な課題もあるので、この投稿の中でお話したいと思います。それでは、例をあげますのでそれを見てください。
CIOps — an example
ホストされたCIプロダクト（Travis CI や CircleCI などが人気ですね）を使っていて、CIからKubernetesへアプリをデプロイしたいと思っている人はいるはずですよね。
CIからKubernetesへアプリをデプロイするためには、CIアクセスをKubernetes APIへ送信する必要があります。ただ、まず最初にこの作業はセキュリティ面でのリスクが生じるということを知っておいてください。詳しくはこちら（私たちの以前のブログ）をご覧いただけると分かりやすいと思います。またこの作業には、それぞれのCIジョブが適切なクラスターにデプロイするために、正確にコンフィグされているということをしっかりと確認することが必要です。そしてそれは最新のクレデンシャルを保持しています。それらが、そのクレデンシャルをリフレッシュするときや、新しいクラスターを立ち上げるときはいつもですが、マルチプルCIジョブの再コンフィグは容易な作業とは言えません。多くのアプリがそれぞれに独立してデプロイされる時は特に難しくなります。またそれらが、例えば所定のアプリ専用のシングルのネームスペースのようなものへのアクセスを制限しようとします。しかしそのようなクレデンシャルは他のものに比べて管理するのがより難しいのです。というのも、Kubernetesクレデンシャルを制限されたスコープで管理してくれるツールがないし、所定のCIプロダクトをコンフィグしてくれるツールもないからです。
How does “CIOps” compare to GitOps?
ここに典型的な“CIOps”デプロイのパイプラインの構図を示しています。それは、デベロッパーとCIシステムの両方がコンテナ・レジストリ―と同じようにクラスターへのフル・アクセスできるパイプラインです。はっきりとした境界がありません。
Typical “CIOps” pipeline
そしてこれは普通の GitOps modelがあるパイプラインの構図です。境界があって、クラスターの中を走るオペレーターによって設定されています。またクラスターの状態を維持する専有権を持っています。全てがsource of truth（信頼できる情報源）になるコンフィグ・Git・レポジトリがベースになっています。
場合によっては、コンフィグ・レポジトリがコード・レポジトリと同じになるということもあります。しかし、より複雑なアプリのためにコンフィグ・レポジトリとコード・レポジトリを分けておくことをおすすめします。コンフィグ・レポジトリの中で複製されない限り、どの変化もコンフィグ・レポジトリを通過すべきだし、クラスターに対しての場当たり的な対処もなされないでしょう。
Common GitOps pipeline
そして、これはWeave Cloudバージョンのパイプラインの構図です。最新のコンテナ・イメージ・タグがコンフィグ・レポジトリの中のワークロード設定に伝達されたということを確認するエキストラ・オペレーターがあるということに注目してください。そして、それに関連したポリシーも存在します。残りのパイプラインは上のものと同じです。GitOpsモデルはとても簡単にマルチプル（多様な）クラスターへ広がっていきます。
In-cluster “CIOps”
Kubernetes クラスターの中へ直接CIシステムをデプロイするのも一般的な方法です。（ときどきクラスター全体、またネームスペースごとのベース上でデプロイすることもあります）
このモデルは前述のセキュリティに関する問題を回避することができます。コンフィグの問題についても考える必要はなくなります。しかし、他の別の問題が生じてきます。例えば、ビルドを走らせるため、またビルドのログ・ストレージを管理するために十分なリソースが必要になるということです。また自分で選んだCIに依存しているデータサービスを走らせる必要が出てきます。
マルチプル・クラスターがあると、このアプローチではイメージはそれぞれのクラスターの中で個々に作られるということになります。そして、そのイメージは100％同じものにはなりません。コンテナ・イメージのアイデアを損ねてしまうのです。ここで絶対に確認しておかなければならないのは、ビルドが本当に再構築できるかとどうかです。ただしこの作業は簡単なものではありません。
Deployment doesn’t go well — another CIOps example
ではこういう場合を考えてみましょう。１つのCIジョブがデプロイをアップデートしても、そのアップデートが思うようにうまくいかなかったというケースです。どのバージョンにロールバックすればよいのか、どうすれば分かるのでしょうか。おそらく、ビルド・ログを通してトレースすればよいはずです。
Kubernetesアサインはワークロードするためにリビジョンします（すなわちデプロイ）。しかし、それらはすべての種類のオブジェクトに供給されません。ワークロード・リビジョン、またその他の関連のあるオブジェクト（例えばConfigMap や Service）、またデプロイしようとしているアプリコードのバージョンなどの計画を立てるためには、まだまだこれだけでは不十分です。すべてのクラスターのAPIレベル・スナップショットを作ってみてもいいかもしれません。しかし、スナップショットを作ってもその変化そのものについてリレートするとなった場合、何の役にもたちません。すべてのクラスターの変化をGitを通して扱う方が断然簡単です。またそうする方が直接変化をリレートすることができるようになります。
Orangesys.ioでは、kuberneteの運用、DevOps、監視の手伝いをさせていただいています。ぜひ私たちにおまかせください。
