Cornus

日本語

English
简体中文

日本語

English
简体中文

外観

ワークロード間 hub ​

Cornus サーバーは、到達可能なネットワークを共有しないワークロード、たとえばノード間、クラスター間、NAT 内のノート PC を接続するスター型ハブとしても機能します。これは、クライアントのエクスポートを一つの Pod へ中継する接続仲介の仕組みを、登録済みワークロード間の任意の TCP/UDP 通信を中継する仕組みへ一般化したものです。各参加者をスポークと呼びます。スポークは自分が提供するサービスを登録し、ほかのスポークが提供するサービスへ名前で到達します。パブリックインターネット向けの対となる機能 — ワークロードの 1 ポートをほかのワークロードにではなく外部に公開する機能 — については、トンネルを参照してください。

仕組み ​

中継のモデル ​

スポークは各サービスを 2 つのモードのどちらかで登録します。

  • dial-direct — hub が到達できるアドレスとともに登録され、hub が自分で接続します。
  • 配送 — アドレスなしで登録されます。hub は、そのサービスをホストするスポークへ戻るイングレスストリームを開いて到達し、スポーク側が自分のローカルの接続先へつないで両者を連結します。これにより NAT 内やクラスターをまたぐ接続先にも到達できます。hub がそこへの経路を持つ必要はありません。

相手に到達するには、発信側のスポークがサービス名を指定したデータストリームを開きます。hub はそれを検索し、直接なら自分で接続し、配送ならそのサービスを所有するスポーク経由で届けて、双方のバイト列を中継します。TCP と UDP の両方が動きます。中継は単にバイト列をコピーするだけなので、UDP は 2 つの変換点でフレーミングするだけで済みます。これは /udp のポート接尾辞で選択します。トラフィックは app -> caretaker -> hub -> {dial | ingress to spoke} と流れます。

ポリシー ​

アクセスは任意設定の 2 つの行列によって管理され、それぞれ設定された場合にのみ強制されます。1 つは到達の行列 (呼び出し元 ID から許可される呼び出し先サービスへの対応、CORNUS_HUB_POLICY)、もう 1 つは登録の行列 (ID からホストできるサービス名への対応、CORNUS_HUB_REGISTER_POLICY) です。スポークは制御ストリーム上で自分の ID を宣言しますが、mTLS では検証済みクライアント証明書の CommonName が正本の ID として使われます。そのためポリシーは、スポークが偽造できない資格情報に基づきます。ID の確立方法はセキュリティと認証を参照してください。

複数レプリカの実行 ​

ハブは単一レプリカ (既定のメモリ内レジストリ。多くのデプロイメントでは十分) または高可用性と接続数の拡張を目的とする複数レプリカで実行できます。各レプリカは自分に接続しているスポークについて唯一の管理者となるため、レプリカは互いに重ならないレジストリ区画を所有し、その集合が分散型レジストリになります。書き込み競合も CRDT の統合もありません。停止したレプリカの区画全体は消え、スポークはロードバランサー経由で新しい管理者の下へ再接続します。ストアは CORNUS_HUB_REDIS (一つの Redis を共有する二つのレプリカが一つのハブになる)、次に CORNUS_HUB_STORE=kube (Kubernetes API サーバーを Lease 対応レジストリとして使うため外部基盤は不要)、それ以外ではメモリ内の単一レプリカレジストリです。配送の検索が管理者ではないレプリカに着地した場合、認証済み内部エンドポイントを介して管理者へ転送するため、二段階の配送経路になります。

関連項目: cornus hub、サーバー環境変数

CLI から hub にスポークとして参加する ​

cornus hub はどこからでもオーバーレイに参加します。たとえば NAT 内のノート PC からローカルサービスをオーバーレイに提供したり、オーバーレイのサービスに名前で到達したりできます。

sh
cornus hub --identity laptop \
  --register api=127.0.0.1:8080 \
  --reach db=127.0.0.1:5432
  • --register name=host:port はローカルサービスを提供します (このスポークへ中継されるため、NAT 配下のホストも到達可能なままです)。--reach name=listen_ip:port は、その名前のオーバーレイサービスへ転送するローカルリスナーをバインドします。少なくとも一つが必要です。
  • --server は任意で、選択中の接続プロファイルにフォールバックします (明示的な --server が優先)。カスタム CA、mTLS 証明書、insecure-skip-verify などのクライアント TLS の素材を持つプロファイルは、今のところ hub では拒否されます。システムのトラストストアが受け付けるサーバー証明書を使ってください。

関連項目: cornus hub

ワークロード間のサービスをエクスポート・インポートする ​

Kubernetes にデプロイされたワークロードでは、hub への参加を CLI ではなくデプロイスペックの hub: ブロックで宣言します。export はワークロードがホストするサービスを列挙し、import は到達するサービスを列挙します。バックエンドはインポートごとに合成のループバック IP を割り当て、DNS レコードと caretaker のリスナーをそこへ配線します。そのためアプリ内の普通の dial(peer) は合成 IP に解決され、アプリケーションが意識しなくても hub へ流れ込みます。

yaml
name: api
image: localhost:5000/api:v1
hub:
  identity: api                 # policy identity (defaults to the deployment name)
  export:
    - { name: api, port: 8080 }
    - { name: udpecho, port: 9000, protocol: udp, deliver: true }
  import:
    - { name: db, ports: [5432] }
  • サービスが hub から到達可能でない場合は、エクスポートに deliver: true を設定します (hub は Pod へ中継し、Pod が localhost のポートに接続します)。
  • importDynamic はワークロードを動的な検出に切り替えます。静的な import のリストの代わりに、caretaker が hub のカタログ通知を購読し、サービスの出現と消滅に合わせて、カタログに載るすべてのサービスの決定的な合成 IP にリスナーをバインドします。
  • hub: は kubernetes 専用です。

関連項目: デプロイスペック

Released under the Apache-2.0 License.

Copyright © Moriyoshi Koizumi