現在運用中の Kubernetes Cluster は、Multi Cluster を Support するためにALB で受けたのち、Nord Port に流されたトラフィックはセレクタによって Service Router という、各 Kubernetes Service へ Proxy するための Nginx がいる。
この Config が中央集権的な管理になっており、server directive ごとに区切られるとはいえ、かなりデカい Config になっており、なかなか心理的にもいじりづらくなってきている。
これはもともとさらに前段のインターネットフェイシングなトラフィックを受ける Reverse Proxy(Nginx) の中にあった Config のうち、Service 固有の Routing をいじりやすくするように移したという背景がある。これはこれで、Reverse Proxy よりはいじりやすくなったが、今度は次のステップとして各 Service ごとに Config や Deploy を分離したいと考えている。
加えて、Traffic を Percentage-Based で Canary Release(Progressive Delivery) をやりたいと考えており、そのためにも必ず Traffic を受ける Service Router がいては邪魔なのだ。
そこで選択肢として、慣れている Nginx であり、かつ現在導入中の Rollouts との相性、あるいは将来の選択肢としての Flagger との相性を考えて Nginx Ingress Controller を検討している。
というわけでドキュメントを読んでいく。
AWS の場合。
NLB が Ingress Resource としてできるようだ。
しかしこれだと External ALB から NLB に Weighted Load Balancing できないので困ったな。
で、まぁこのドキュメントだと正直 NLB で受けたあとどういうルーティングで各サービスにいくのかがよーわからんので、Nginx 公式のこっちをみてみた。
なるほど Nginx の設定に対応する Virtual Service と Virtual Server Route があるんだね。
つまり、この yaml で表現されるような単純な Routing は代替できて、生の Nginx を書かないといけないような場合は、各サービスごとに Nginx なりを持って好きにしてくれ、という感じになるわけだ。
user -> NLB(Ingress) -> nginx -> service
こういう流れで、Nginx Ingress Controller は与えられた yaml にしたがって各サービスごとの Nginx Deployment を生成して、Configmap の設定を読み込ませるということだ。
Argo Rollout と連携して、canary=weight の値を nginx ingress に持たせておけば、rollout controller が nginx の config をいじって routing 先の service を weighted でいじるのだろうか。ちょっといまだにピンときてない。や、多分特定の割合で特別な Header を NLB でつけるようにして、それをみて Nginx が振り分けるようにする気がする。
ただこの場合、Ingress を通る全部のトラフィックが対象になる気がする。Service ごとにできるんだろうか。やっぱ動かさないとなんともだな。
おわりに
というわけでシンプルに routing するだけなら Nginx Ingress Controller で実現できそうだが、Progressive Delivery をやる上で Flagger なり Argo Rollout なりと連携していく部分はちょっとまだ見えてないので動かして学んでいきたい。
あと、Cluster 自体も Canary Switching したいので AWS で Nginx Ingress をいれた状態でどう実現するかの案も考えていきたい。
追記
split っていう設定があるので、これで Stable と Canary のService へ Canary できそう。
Rollout Controller は多分これを Strategy にしたがっていじるんだろうな。
