Kubernetes-Native Tunneling: CRDとOperatorによる自動Ingress

クラウドネイティブ開発者は命令型CLIバイナリを実行しません。宣言型のYAMLを書きます。プライベート、エッジ、またはローカルクラスターへの外部アクセスを手動のリバースプロキシで管理するのは、プラットフォームエンジニアリングのワークフローにおいてアンチパターンです。Webhook Relay Kubernetes OperatorやTailscaleのKubernetes Operatorのようなツールは、標準のKubernetes Custom Resource Definitions（CRDs）とネイティブのIngress APIを通じて、外部ネットワークアクセスを完全に管理できます。トンネルをGitOps管理のリソースとして扱うことで、プラットフォームチームは内部サービスを安全に公開し、インバウンドWebhookルーティングを自動化し、エッジクラスターのIngressをCLIプロセスに触れることなく管理できます。

宣言型エコシステムにおける命令型トンネルの問題点

ローカルまたはプライベートインフラに依存する開発者は、従来ngrokやlocaltunnel、SSHリバースプロキシなどのツールを使ってサービスをインターネットに公開してきました。迅速なデバッグには効果的ですが、本質的に命令型です：ターミナルを開き、コマンドを実行し、動かし続ける必要があります。

Kubernetesではこれがすぐに破綻します。Kubernetesは宣言型の状態マシンです — ノードがダウンしたり、Podが退役したり、クラスターがスケールしたりすると、命令型のトンネルはリコンシリエーションループと関係がありません。オーケストレーターはトンネルの状態を把握せず、その健全性を監視できず、再作成する仕組みもありません。

静的IPやファイアウォールルール、クラウドのLoadBalancerをすべてのマイクロサービスやWebhook受信者にプロビジョニングするのはコストと運用負荷が高く、とくにオンプレミス、エッジ/IoTネットワーク、ローカル開発クラスターではパブリックIPが利用できません。これらのケースでは、トンネルをバージョン管理された継続的にリコンシリエーションされるKubernetesオブジェクトとして扱うパターンが有効です。これはDeploymentやConfigMapと同じ管理方法です。

Operator駆動型ネットワーキングへの移行

Kubernetes Operatorパターンは、Custom Resourcesを監視し、クラスターの状態を宣言内容に一致させるカスタムコントローラーです。ネットワーキングに適用すると、クラスター内で動作し、特定のCRDを監視し、開発者がGitに新しいCRをコミットすると、外部のトンネルサービスと認証し、永続的で安全なアウトバウンド接続を開きます。アウトバウンドからの接続なので、インバウンドのファイアウォールポートを開けたり、NATトラバーサルを設定したり、公開Ingressコントローラーを動かす必要はありません。

これにより、プラットフォームチームには3つの大きな利点があります：

• 状態のリコンシリエーション — トンネルが切断された場合、オペレーターは現在の状態とCRの望ましい状態が一致しないことを検知し、接続を再構築します。
• インバウンド露出なし — クラスターはインバウンドポートを開きません。オペレーターは認証されたアウトバウンドゲートウェイです。
• GitOps互換性 — トンネル設定はGitにあり、アプリマニフェストと並列して管理されるため、ArgoCDやFluxのようなツールでアプリと公開ルートを同時にデプロイできます。

Webhook Relay Kubernetes Operator：WebhookとAPIトラフィックのルーティング

GitHubやStripe、SlackからのWebhookをプライベートクラスター内で受信するには、一般的にはパブリックAPIゲートウェイを立ち上げ、企業のファイアウォールに穴を開ける必要があります。Webhook Relay Kubernetes Operatorは、これをパブリックIPやロードバランサーなしで解決し、WebhookやAPIリクエストの受信とルーティングに特化しています。オンプレミス設定、K3sエッジ展開、IoTが対象です。

インストールはHelm経由で行い、オペレーターはインストール時にアクセスキーとシークレットでクラスター全体を設定します（CRごとではありません）：

helm repo add webhookrelay https://charts.webhookrelay.com
helm repo update

export RELAY_KEY=*****-****-****-****-*********
export RELAY_SECRET=**********

helm upgrade --install webhookrelay-operator --namespace=default webhookrelay/webhookrelay-operator \
  --set credentials.key=$RELAY_KEY --set credentials.secret=$RELAY_SECRET

オペレーターが動作開始すると、WebhookRelayForward CRが公開エンドポイントと転送先を記述します。入力（公開エンドポイント）と出力（内部転送先）の両方が必要です。入力だけのCRはトラフィックを送る先がありません：

# cr.yaml
apiVersion: forward.webhookrelay.com/v1
kind: WebhookRelayForward
metadata:
  name: stripe-webhook-forwarder
  namespace: payment-services
spec:
  buckets:
    - name: k8s-operator
      inputs:
        - name: public-endpoint
          description: "Stripe Webhook Receiver"
          responseBody: "OK"
          responseStatusCode: 200
      outputs:
        - name: webhook-receiver
          destination: http://destination:5050/webhooks

kubectl apply -f cr.yaml

オペレーターはバケットをプロビジョンし、公開エンドポイントを開き、一致するトラフィックを宛先サービスにルーティングします。CRを削除（kubectl delete -f cr.yaml）すると、ルーティングも解除されます。Kubernetesのイベントを発行し、CRのステータスも更新するため、kubectl describe webhookrelayforwardでライブの配信状態が確認できます。

範囲について正確に言えば、このオペレーターはWebhook/APIの転送に特化しています。Webhook Relayは別の製品 — Webhook Relay Ingress Controller（relay ingress init、デプロイメントマニフェストはgithub.com/webrelay/ingress） — を提供し、GrafanaやPrometheusのようなサービス全体を*.webrelay.ioサブドメイン経由の標準Ingressリソースで公開する双方向トンネルをサポートします。これらはインストール方法や問題解決が異なり、WebhookオペレーターのCRDはWebアプリ全体をプロキシしません。

新しい追加情報として、AIエージェントをインフラに組み込むチーム向けに、Webhook RelayはMCPサーバー（https://my.webhookrelay.com/v1/mcp）を公開しています。これにより、エージェントはバケットや入力/出力の一覧取得、Webhook配信ログや統計の検査、シンセティックテストWebhookの送信が可能です。これにより、「なぜこのGitHub webhookがクラスターに届かなかったのか」のデバッグに役立ちます。

KubeSailのギャップと今日の代替

KubeSailは、数年間、「標準のKubernetes Ingressリソースを監視し、TLS付きのパブリックサブドメインを自動的にプロビジョンする」例として最もよく引用されてきました。これはホームラボやベアメタルクラスター向けです。ただし、KubeSailは2025年9月にサービスを終了しました。同社のページでは、「6年間の運営の後、ホスティングサービスの運営を停止する決定をしました」と明記されています。創業者は明示的にTailscale FunnelやCloudflare Tunnelへの移行を推奨しています。現在の記事やドラフトでKubeSailのオペレーターを紹介しているものは、既に廃止された製品について述べていることになります。

良いニュースは、KubeSailが普及させたパターンは生きており、むしろ成熟しています。それがTailscale Kubernetes Operatorです。

Tailscale Kubernetes Operator

OAuthクライアント資格情報を使ったHelm経由のインストールで、クラスターのワークロードをプライベートtailnetに公開し、必要に応じてパブリックインターネットにも公開できます。これは、標準のIngressリソースを監視することで実現します。一般的なケースでは、カスタムのベンダー固有の種類は不要です。

# ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app
  namespace: dev
  annotations:
    tailscale.com/funnel: "true"
spec:
  defaultBackend:
    service:
      name: my-app
      port:
        number: 80
  ingressClassName: tailscale
  tls:
    - hosts:
        - my-app

kubectl apply -f ingress.yaml
kubectl get ingress my-app -n dev   # 付与されたホスト名を監視

ingressClassName: tailscaleを設定すると、オペレーターはIngressの所有権を取得します。新しいTailscaleノードをプロビジョンし、MagicDNS名のTLS証明書を発行し、トラフィックをバックエンドServiceにプロキシします。クラスター側のファイアウォールルールは不要です。デフォルトのままでは、tailnet内の他のデバイスからのみアクセス可能です。tailscale.com/funnel: "true"アノテーションを追加すると、インターネットからも公開でき、これはKubeSailの自動公開に近い動作です。

本番環境向けには、ProxyGroupカスタムリソースを使って複数のIngressプロキシレプリカを運用し、ルートの耐障害性を確保できます。Tailscaleのドキュメントでは、ArgoCDを使ったマルチクラスター展開もサポート例として挙げられています。Ingressを削除すれば、対応するTailscaleノードも削除され、CRDの保証通りに「孤立した接続」がなくなります。

自ホスティングオプション：PangolinのNewt Helmチャート

同じアウトバウンドのみのパターンを完全にセルフホストしたいチーム向けに、Pangolinは自己ホスト型のWireGuardベースのリバースプロキシ（TLS終端用Traefik、WireGuard側のGerbil、プライベートネットワークからダイヤルアウトする軽量コネクタのNewt）を提供し、公式のNewt Helmチャートを公開しています。これは、従来のDocker Composeインストールとは異なり、バージョン1.4.0（Newtアプリバージョン1.12.3対応）で、最小Kubernetesバージョン1.30をサポートします。名前空間や接続資格情報のSecretからの読み込みも可能です。

ローカルMinikubeのワークロードを公開する

Minikubeはラップトップ上で単一ノードクラスターを動かす標準的な方法です。ただし、OAuthコールバックやサードパーティWebhook、外部API連携をテストするのはこれまで面倒でした。

従来の方法は:

1. kubectl expose + minikube service — DeploymentをNodePortで公開し、minikube service <name>でブラウザを開きます。Dockerドライバー（macOSやWindowsのDocker Desktop）では、minikube serviceはホストからminikubeノードへのSSHトンネルを開き、直接NodePortにアクセスしません。これはkic.ServiceTunnelがSSH経由で動作しているためです。
2. Ingressアドオン（minikube addons enable ingress）とminikube tunnel — LoadBalancerタイプのサービスを公開します。minikube tunnelはフォアグラウンドで動作し続け、Ctrl-Cで停止します。これらはリモートチームや外部Webhookに対してスケールしません。

Tailscaleオペレーターは標準のIngress APIだけを気にしているため、Minikubeでも他のクラスターと同じように動作します。Helmでオペレーターをインストールし、前述のingress.yamlを適用します（ingressClassName: tailscaleも含む）：

minikube start
helm install tailscale-operator tailscale/tailscale-operator \
  --namespace=tailscale --create-namespace \
  --set-string oauth.clientId=<CLIENT_ID> \
  --set-string oauth.clientSecret=<CLIENT_SECRET>

kubectl apply -f ingress.yaml   # 同じマニフェスト、ファンネルアノテーション付き

これにより、GitHubやGoogle OAuthからコールバックを受け取れる実際の公開HTTPS URLが得られます。これは、Minikube上のワークロードから直接提供され、minikube tunnelのデタッチや/etc/hostsの手動編集は不要です。Ingressを削除すれば、ノードと証明書も同様に削除され、テスト後に公開エンドポイントが残りません。

GitOps連携と継続的デリバリー

CRD/オペレーター方式は、インフラとアプリケーションの状態をGitが唯一の情報源とするGitOpsワークフローに適しています。従来は、CI/CDパイプラインがアプリコードをデプロイし、その後手動でリバースプロキシやトンネルを設定していました。これにより、バージョン管理と実行環境の間にドリフトが生じていました。

CRDや標準のIngressオブジェクトとして定義されたトンネル設定は、DeploymentやService、ConfigMapと並列のYAMLファイルです：

1. 開発者が新しいマイクロサービスとWebhookRelayForward CR（またはTailscaleアノテーション付きIngress）をGitにプッシュ
2. ArgoCDやFluxがコミットを検知し、クラスター状態を同期。マイクロサービスとルーティングオブジェクトを適用
3. 関連するオペレーターが新しいオブジェクトを取得し、外部サービスと連携してルートを確立
4. サービスは公開またはtailnet内からアクセス可能に。人手によるプロキシ設定不要

クラスターをゼロから再構築しても、ArgoCDはリポジトリを再適用し、オペレーターは既存のオブジェクトからルートを再プロビジョンします。これは、Tailscaleが自社のオペレーターで文書化しているマルチクラスターArgoCDパターンと一致します。

アーキテクチャのセキュリティメリット

ポートフォワーディングやクラウドロードバランサーから、オペレーター管理のアウトバウンドトンネルに移行することで、クラスターのセキュリティ姿勢が大幅に強化されます。アウトバウンド接続のため、ファイアウォールやセキュリティグループのインバウンドポートを開く必要はありません。クラスターはインターネットから見えず、ポートスキャンやDDoS攻撃も防げます。

標準のKubernetes RBACは、これらのCRDやIngressリソースに適用されます。クラスター管理者は、特定の名前空間だけにトンネルCRDやIngressの作成を許可するロールバインディングを設定可能です。これにより、devやstagingは公開エンドポイントを自己管理でき、productionはより厳格な監査を経由します。これは特定のオペレーターの機能ではなく、一般的な名前空間スコープのRBACの適用です。

TLS終端と認証はエッジで行われ、トラフィックがクラスターに到達する前に暗号化・認証済みです。

今後の展望

開発者はCLIの命令型トンネルやNATルールの手動管理から、アプリケーションロジックとDeploymentマニフェストを書く方向へ向かいます。WebhookやAPIのルーティングには、Webhook Relay Operatorが引き続き有効です。一般的なIngressには、Tailscale Kubernetes Operatorが標準のIngress APIを使った推奨の選択肢です。PangolinのNewt Helmチャートは、サードパーティのエッジネットワークを経由しないセルフホスト型の代替です。これらはすべて、CRDやアノテーション付き標準オブジェクトを継続的にリコンシリエーションし、削除時にきれいに破棄し、Gitベースのパイプラインでデプロイ可能な点で共通しています。

---

ファクトチェックと改訂履歴

• KubeSailは廃止済み（大きな訂正）。元のドラフトの「KubeSail Reverse Proxy」セクションは、稼働中のホスティングサービスについて現在形で書かれていました。KubeSailの公式サイトは、2025年9月にサービス停止を告知しています。創業者はTailscale FunnelやCloudflare Tunnelへの移行を推奨しています。これに基づき、該当セクションを完全書き換え、現在も維持されているTailscale Kubernetes Operatorに焦点を当てました。PangolinのNewt Helmチャートも新たに追加しています。
• WebhookRelayForward例CRは不完全で、架空のフィールドを含んでいました。元のYAMLにはsecretRefName: whr-credentialsがありましたが、これはCRDスキーマに存在しません（資格情報はHelmの--set credentials.key/secretで提供され、Secretはクラスター全体に作成されます）。また、outputsブロックも欠落していました。これをWebhookRelayの公式ドキュメントに合わせて修正し、必要なoutputsとresponseStatusCodeを追加しました。
• スコープの明確化：Webhook Relayは、Webhookフォワーディング用のOperator（WebhookRelayForward CRD）と、一般的な双方向サービストンネル用のIngressコントローラー（relay ingress init）の2つの製品を提供します。これらの範囲を明示しました。
• 新たに検証済みの詳細：Webhook RelayのMCPサーバー（https://my.webhookrelay.com/v1/mcp）は、AIエージェントによるバケット/入力/出力/ログ管理に関係し、ブログのMCP/AIエージェントトンネリングの内容に関連します。
• MinikubeのSSHトンネルについて確認済み：minikube serviceはSSHトンネルを開くことを確認し、macOS/WindowsのDocker Desktopでは特に重要です。
• 架空のLocalTunnel例を実在のマニフェストに置き換え：ingressClassName: tailscaleとtailscale.com/funnel: "true"アノテーションを付与した標準的なKubernetes Ingressを使用し、Tailscaleの公式ドキュメントから取得しました。
• RBACと本番運用の記述を調整：これはOperator固有の機能ではなく、Kubernetesの名前空間スコープRBACの適用範囲です。
• その他の記述は検証済み：Operatorパターンの説明、GitOps/ArgoCDのリコンシリエーション、Helmコマンドは最新の情報に基づき、軽微な修正のみ行いました。