「KnativeとIngress Gateway」メモ

techbookfest.org

Knative

• Serving
  • Revision
  • Configuration
  • Route
  • Service(Kubernetes の Service とは違う)
• Eventing
  • Sources
  • Broker

この時点ではよくわかんないけど、Kubernetes の上に Gateway 層(Istio とか他) がいて、その上に Knative がいるようだ。

Gateway

• Ingress は L7 Load Balancer
  • Type LoadBalancer Service や
  • Type NodePort Service もクラスタ外に公開するが

Knative が利用する Gateway というのは Envoy とかでよく説明される Front Proxy - North / South traffic のこと。この手段がいくつかある。

• Ambassador
• Contour
• Gloo
• Kourier
• Istio

いずれも Envoy を Proxy に利用している。

その代表として Istio の説明。

Istio

結局イマイチ Knative いれるのになんで Istio(Gateway?)がいるのかがよくわかってない。

Typo をみつけたけど PR 投げられない。

3.5 Istio のコンポーネント つぎは主要なコンポーネントのインストールです。ここでは Helm を使って kubectl で apply する YAML ファイルを生成して apply います。

Istio で gateway つくって、それを外部から Knative に流すためにいるんかな。そのために Istio はヘビーじゃない？と思うが。

Ambassador

基本的に north-south トラフィック を制御するためのプロダクトです。east-west トラフィックの制御は Istio、Consul、 Linkerd とのインテグレーションを提供しています。

ほーん

.... よくわからんかった

Contour

おぉ、これは試そうと思ってたやつ。

Ingress を HTTTPProxy というカスタムリソースで表現するらしい。

Kourier

Knative 用の Ingress らしい。

Gloo

エンタープライズ版の API Gateway

ほう

おわりに

うちは Type LoadBalancer Service で AWS の LB で受けて、Node Port で受けて中にある Nginx に流してそこから各 Service に Proxy するというアーキテクチャをとっている。

いわゆるここの Front Proxy が将来どうなるか。Ingress を使う、Envoy を使う可能性は十分あると思う。

例えばこの Front の部分で path base routing なり header みてどうなり、percent base で canary をやるなりするなら Service Mesh があったほうが多分楽なのかなあ。

それとも Canary とかはその先の、Istio だったら Virtual Service 層でできるのかな、多分。

いずれにしろ、今は Service Mesh Control Plane は決着がついてない状況なので、Solution Base で、最小の構成で試して価値を出しつつ、学んでいきたいと思う。

Knative はどうなんだろうなあ、今のところ Layer 増えるジャンっていうイメージしかもってなくて、それでどんだけ幸せになれるかピンときてないです。Platform やる側だからかな。