博士

やあ、ロボ子。今日はngrok Kubernetes Operatorの話じゃ。

ロボ子

ngrok Kubernetes Operatorですか。Kubernetesへのingressを容易にするもの、と記事にありますね。

博士

そうじゃ。Kubernetes OperatorとTraffic Policy engineが、Kubernetesサービスのingress管理を助けてくれるらしいぞ。

ロボ子

ingress管理、ですか。具体的にはどういうことでしょう？

博士

OperatorがIngressやGateway APIの実装をngrokリソースに変換するんじゃ。ルーティング、認証、変換をngrokのネットワーク上で実行してくれる。

ロボ子

なるほど。Kubernetesバインディングで、クラスタ内でのみアクセス可能なエンドポイントも作れるんですね。

博士

そうそう。v1.0に向けて、GRPCRouteのサポートとか、Kubernetesバインドエンドポイントの改善とか、色々予定されているみたいじゃ。

ロボ子

EdgesとModulesは廃止予定なんですね。v0.18.0以降では、Operatorが自動的にEdgesをエンドポイントに変換する、と。

博士

Gateway APIを使っているなら、GatewayClassをngrokにポイントするように編集すれば、すぐにngrok Kubernetes Operatorが使えるぞ。

ロボ子

Traffic PolicyをGatewayやRouteリソースに追加することで、Gateway APIよりも柔軟な対応が可能になるんですね。

博士

その通り！ Kubernetes Operatorは、CloudEndpointとAgentEndpointのカスタムリソースに自動的に変換してくれる。

ロボ子

Kubernetesバインドエンドポイントを使うと、サービスをクラスタに接続したり、クラスタをクラスタに接続したりできるんですね。便利そうです。

博士

v0.18.0には、Gateway API実装でのTCPRouteとTLSRouteのサポートも含まれているらしいぞ。どんどん進化しておるの。

ロボ子

v0.17.0以降、Operatorはデフォルトでエンドポイントのみを作成するようになったんですね。

博士

ふむ。つまり、ngrok Kubernetes Operatorを使えば、Kubernetesのingress管理が楽になる、というわけじゃな。

ロボ子

はい、博士。理解しました。ところで博士、ngrokって、なんだか美味しそうな名前ですよね。

博士

確かに！ ロボ子、今度ngrok味のクッキーでも作ってみるかの？ きっと、トンネルみたいに甘くて深い味わいじゃぞ！