tailscale namespace にインストールされているものとします。設定にあたっては、次の 2 つのプラットフォームの動作を考慮する必要があります。
- Tailscale オペレーターを通じてクラスター内の Service を公開すると、tailnet デバイスからその Service に接続できるようになります。一方、Pod から tailnet デバイスへの外向き接続には、Tailscale のクラスター外向き通信機能が必要です。
- サンドボックスの外向き通信ルールは、デフォルトですべて拒否するベースラインの上に許可のみを追加する方式で、
EgressRule(any=True)はクラスター内部のアドレスを対象外とします。そのため、Tailscale プロキシなどのクラスター内の送信先には、selectorルールまたはtenantルールを使用しなければアクセスできません。
前提条件
installStatusがREADYのマネージドサンドボックスランナーを備えた CKS クラスター。独自のコンピューティングリソースを使用するを参照してください。- そのクラスターに Tailscale Kubernetes Operator がインストールされ、tailnet ポリシーファイルが CKS 向けに設定されていること。Tailscale Kubernetes Operator をデプロイするを参照してください。
- 接続先の tailnet デバイスの MagicDNS 名(例:
db-host.[TAILNET-NAME].ts.net)と、サービスがリッスンしているポート。 - このセレクターの外向き通信ルールを許可するランナーのポリシー。
anyエンタイトルメントはセレクターには適用されないため、allowed_egressが空でないポリシーには、形式が一致するselectorエンタイトルメントが必要です。具体的には、namespace_labelsも設定されていること、そのラベルがサンドボックスで宣言されたラベルのサブセットであること、ポートフィルターが TCP ポート 8080 を含んでいることが条件です。SelectorBlockを参照してください。 - CKS への配置用の認証情報が設定済みの
cwsandboxPython SDK と、curlおよびgetentがインストールされたサンドボックスイメージ。 defaultnamespace で Service を作成または更新し、オペレーターの namespace で Pod を一覧表示できるkubectlのアクセス権。- 外向き通信プロキシから対象デバイスおよびアプリケーションポートへの接続を許可する tailnet ポリシー。
Tailscale の外向き通信用 Service を作成する
tailnet デバイスの MagicDNS 名をアノテーションに指定したExternalName Service を作成します。オペレーターは自身の namespace にプロキシ Pod とヘッドレス Service を作成し、ExternalName Service がそのヘッドレス Service を指すように設定します。以下の例では、リンク先のインストールガイドと同じく tailscale を使用しています。オペレーターを別の namespace にインストールした場合は、以下のコマンドと namespace_labels を適宜変更してください。
[TAILNET-FQDN] をデバイスの MagicDNS 名に置き換えてください。この例では Service を default に作成し、その完全修飾 DNS 名を使用することで、他の namespace にあるサンドボックスからも接続できるようにしています。また、ポート 8080 で /health エンドポイントを公開する HTTP サービスを想定しています。ポートとパスはご利用のサービスに合わせて調整してください。
tailnet-egress.yaml
internal-api.default.svc.cluster.local:8080 に接続します。短縮名 internal-api:8080 は、Service と同じ namespace 内からしか使用できません。クラスターで cluster.local 以外の DNS 接尾辞を使用している場合は、例に含まれる接尾辞をその値に置き換えてください。
オペレーターがプロキシ Pod を作成したことを確認します。
サンドボックスにプロキシへの外向き通信を許可する
EgressRule で、ラベルを使用してプロキシ Pod を選択します。このルールには、次の両方のラベルセットが必要です。
pod_labelsは、オペレーターが付与するtailscale.com/parent-resourceラベルとtailscale.com/parent-resource-nsラベルを使用して、プロキシをその背後にある Service によって識別します。別の namespace にある同名の Service 用プロキシにもルールが一致してしまわないよう、namespace ラベルも含めてください。namespace_labelsはtailscalenamespace を選択します。これを指定しない場合、ルールはサンドボックス自身の namespace にのみ適用され、別の namespace にあるプロキシには到達できません。
ports には、サービスがリッスンしているポートと同じポートを設定します。[RUNNER-ID] は、Service を作成したクラスター上のランナーの ID に置き換えてください。runner_ids を指定しない場合、CKS の配置では組織内の対象となる任意のランナーが使用される可能性があり、プロキシが存在しないクラスター上のランナーが選ばれることもあります。
ProxyGroup は共有のプロキシ Pod を使用してポートを再マッピングするため、このモードではこのルールだけでは設定として不十分です。詳しくは、Tailscale の高可用性外向き通信ガイドを参照してください。
ランナーのポリシーが dns_egress 制約で DNS の外向き通信を拒否していない限り、クラスター DNS には引き続き到達できます。そのため、追加のルールがなくても、サンドボックスは Service 名を解決できます。
接続を検証する
この例では、HTTP レスポンスのヘッダーと本文に加え、curl のエラーがあればそれも出力します。ステータス 200 を返すヘルスチェック用エンドポイントであれば、HTTP/1.1 200 OK のようなステータス行に続いて、サービスの健全性を示すレスポンスが表示されます。401 や 404 などの HTTP エラーが返された場合は、HTTP サーバー自体は応答しています。アプリケーションの認証設定またはリクエストしたパスを確認してください。
タイムアウトや接続エラーは、サンドボックスとプロキシの間、プロキシと tailnet デバイスの間、またはアプリケーション側で発生する可能性があります。DNS と HTTP のやり取りを個別に確認するには、ランナー ID を指定して次の診断例を実行してください。
トラブルシューティング
関連ページ
- Tailscale Kubernetes Operator をデプロイする: CKS 上でオペレーターをデプロイして設定します。
- ネットワークルール:
EgressRuleとSelectorBlockの完全なリファレンスです。 - ポリシーリファレンス: 宣言する外向き通信ルールは、ここで定義されるポリシーのエンタイトルメントの範囲内に収める必要があります。
- 公開エンドポイント: サンドボックス内のサービスに公開アドレスを割り当てます。