背景2019当時、私の会社には 2 つの Java アプリケーションしかなく、両方とも単一の Tomcat Servlet コンテナ上で実行されていました。 当時はローカルデバッグをどのように行っていましたか？開発者は自分のコンピュータにMySQLとTomcatをインストールし、独自にデバッグを実行していました。バックエンド開発者は互いに干渉することなく自由に変更でき、アプリ開発者はバックエンドのラップトップに直接接続してデバッグを実行できるという利点がありました。デプロイメントは基本的に間に合わせのチームで行われ、開発者が手動でJARファイルをコンパイルしてクラウドサーバーにアップロードしていました。これは基本的な構成で、作業はこなせましたが、それだけでした。 2020 2020年までに、当社はCentOSサーバーを購入し、MySQLとTomcatをインストールし、キャッシュにはRedis、メッセージキューにはRabbitMQを使用し、独立したテスト環境を構築しました。また、アプリケーションのパッケージ化とデプロイを自動化するためにJenkinsを導入し、これは大きな進歩でした。少なくとも、アプリケーションを自分でパッケージ化する必要がなくなったのです。 では、現時点でローカルでデバッグするにはどうすればよいでしょうか？少なくとも、MySQLを自分のコンピュータにインストールする必要はなくなりました。その後、フレームワークがSpringMVCとStruts2からSpring Bootに変更され、外部のTomcatも削除できるようになりました。バックエンド開発者は、Spring Bootをローカルで実行する際に、サーバーのMySQLに直接接続してデバッグできます。また、アプリはバックエンド開発者のラップトップに接続する必要がなくなり、比較的安定したデバッグ環境が提供されます。ただし、異なるバックエンド間でデータベース構造を更新する場合、他のバックエンドへの影響を避けるために互換性を維持する必要があります。 2021事業の拡大に伴い、バックエンドフレームワークはSpring BootからSpring Cloudスイートへと進化し、アプリケーション実行環境はLinux上で直接実行されていたものからDockerイメージを介したデプロイへと移行しました。また、様々なミドルウェアもDockerイメージを採用しました。製品ラインの増加に伴い、単一の開発ブランチではニーズを満たせなくなったため、新たなバックエンドコードブランチが作成され、開発・テスト環境も追加されました。 この段階では、アプリ側のローカルデバッグはそれほど変わりません。唯一の違いは、異なるバックエンド環境に接続するために異なるドメインを使用する点です。しかし、バックエンド開発者にとっては話は別です。ローカルデバッグを行うたびに、EurekaインスタンスとConfig Serverをコンピューター上で実行する必要があります。デバッグ対象のマイクロサービスに多くの依存関係がある場合は、大量のメモリが不可欠です。 2022事業量は拡大を続け、製品チームのメンバー数も増え、需要は山のように積み重なっていきました。2つのブランチではもはや十分ではなく、3つ目のブランチが作成されましたが、それでも十分ではありませんでした。新しいブランチのランタイム環境が追加されるたびに、バックエンド開発チームも、多数の環境とサードパーティプラットフォームのコールバックを構成する必要があり、苦労しました。動的なスケーリングを可能にするために、Spring Cloudエコシステムは進化を続け、ZuulゲートウェイとEurekaを放棄してSpring Cloud Kubernetesを採用し、ランタイム環境をKubernetesに完全に統合しました。この間、同社は開発とテスト用に別のサーバーを購入し、メモリ、CPU、ディスク容量がいっぱいになりました。 Kubernetes（K8S）の登場により、バックエンド開発者のローカルコンピュータはLinuxサーバー上の様々なミドルウェアに自由に接続できなくなりました。新しいブランチ環境の各PODには新しいIPアドレスが割り当てられ、従来のようにバックエンド接続用に特定のミドルウェアポートを開くことはできなくなりました。各環境を個別に設定することは、運用エンジニアにとって非常に時間のかかる作業です。そこで、本日ご紹介するkt-connectツールが役立ちます。このツールを使用することで、バックエンド開発者のローカルコンピュータは、様々なブランチ環境内のすべてのサービス、つまりK8S名前空間内のすべてのサービスへのアクセスをプロキシ化し、デバッグが必要なサービスのみを起動することで、CPUとメモリの使用量を大幅に削減できます。 選択ローカルデバッグのために K8S 環境にアクセスするためのプロキシを選択するためのツールがオンラインでいくつか利用可能です。 1. ポート転送前述のように、Ingress、NodePort、LoadBalancerなどのツールを使用してトラフィックを特定のポートに転送すると、運用・保守担当者の作業負荷が増加し、ブランチ環境の自動作成と再利用が容易になりません。これは、少数のポートを公開する必要があるシナリオにのみ適しています。 2. VPN Kubernetesの各名前空間にVPNサービスを実行するPODを設置することで、バックエンド開発用ラップトップはVPNクライアントを介して指定された名前空間に接続し、クラスター内の様々なサービスに正常にアクセスして解決できるため、基本的に日常的な要件を満たすことができます。ただし、各名前空間でそれぞれ独自のVPNサービスが実行されていることが欠点です。 3. テレプレゼンス検索中にこのプロキシツールを発見しました。中国語と英語の技術記事のほぼ90%で、このツールの使用が推奨されています。これは非常に強力で、VPNのプロキシ機能（名前空間内のすべてのサービスへのアクセスを許可する機能）だけでなく、特定のサービスからローカルマシンへのトラフィックをブロックするルールを指定する機能も備えています。つまり、ローカルマシンは外部サービスを提供する通常のPOD（ポータブルプロバイダー）としても機能するということです。基本的な設計原理は次のとおりです。 研究開発に使用するローカルコンピュータで次のコマンドを実行します。 テレプレゼンス helm インストール--kubeconfig .kubeconfig Kubernetesクラスターに「ambassador」という名前空間が自動的に作成され、トラフィック管理用のトラフィックマネージャーポッドがデプロイされます。ローカル開発用ラップトップでは、2つのデーモンサービスが起動します。1つは「ルートデーモン」と呼ばれ、双方向プロキシチャネルを確立し、ローカルコンピューターとKubernetesクラスター間のトラフィックを管理するために使用されます。もう1つは「ユーザーデーモン」と呼ばれ、Traffic Managerとの通信、ブロックルールの設定、ログイン後のAmbassador Cloudとの通信を担当します。 インターセプトルールを設定すると、インターセプト対象のPODにトラフィックエージェントがインストールされます。公式ドキュメントによると、これはKubernetesクラスターのサイドカーモードに似ています。PODに注入されたトラフィックをインターセプトし、すべてのトラフィックはトラフィックマネージャーを経由して再ルーティングされます。
強力な機能を備えているものの、現在のバージョン2.5では、ブロッキング機能やURLプレビュー機能を使用するには、商用クラウドプラットフォームであるAmbassador Cloudへの登録とログインが必要です（注：オンラインの技術記事ではなぜこのことに触れられていないのか分かりませんが、テスト中はクラウドプラットフォームへのログインが必要でした）。さらに、ブロッキングルールの設定はクラウドプラットフォームのウェブページから行う必要があります。ネットワーク要件に加え、セキュリティとデータ漏洩の潜在的なリスクも許容できないため、このツールの使用を断念せざるを得ませんでした。 もう一つの欠点として、旧バージョンの使用後に自動作成されたネームスペースやポッド、インターセプトエージェント（Telepresenceのアンインストール）をクリーンアップする機能がなくなったことが挙げられます。バージョン2.5では、この機能はコマンドパラメータから完全に削除されました。つまり、使用後に環境をクリーンな状態に保ちたい場合、運用・保守担当者にクリーンアップを依頼する必要があり、非常に面倒で、強迫性障害の患者にとっては頭が痛くなるほどです。 4. ktコネクト幸いなことに、オープンソース コミュニティは、Telepresence に似た kt-connect と呼ばれる別のツールを見つけました。
私たちが使用しているバージョンはv0.3.6です（ちなみに、Kubernetesのバージョンは1.24です）。インターネット接続やアカウントログインは不要です。また、コマンド実行後にはデフォルトで自動クリーンアップされます。これはAlibabaのツールで、別のKPIオープンソースプロジェクトかどうかは分かりませんが、少なくとも今のところはこのツールには非常に満足しています。 原理Telepresenceに似ていますが、Telepresenceとは異なり、kt-connectは指定された接続の名前空間内に単一の自己使用ポッドを作成し、kt-connect-shadowイメージをデプロイします。Telepresenceと比較して、kt-connectはより洗練され拡張されたモードを提供し、4つの主要なモードに分かれています。 1. 接続モードktctl.exe 接続--kubeconfig .kubeconfig --namespace feature-N --debug このモードでは、kt-connect は VPN のように動作し、ローカル コンピューターが接続された名前空間内のすべてのサービスにアクセスできるようになりますが、クラスター内の他のサービスには統合されず、他のサービスからのトラフィックはローカル コンピューターに転送されません。 注1：Telepresenceと同様に、すべてのkt-connectコマンドには--kubeconfigを含める必要があります。これは、KubernetesクラスターのAPIサーバーに正しく接続するための十分な権限と機能を確保するためです。多くの記事ではこの点についてほとんど触れられていません。Kubernetesクラスターの権限が制限されている場合、または開発チームと同じネットワーク上にない場合は、運用チームから提供された十分な権限を持つkubeconfigファイルを使用して接続する必要があります。 注2: ポート転送の設定に失敗しました local:28344 - > pod kt-connect-shadow-gseak:53 error = "接続のアップグレードエラー: リクエストの送信エラー: Post " ": dial tcp 10.0.8.101:8443: connectex: 到達不可能なホストへのソケット操作が試行されました。" , 上記のエラーが発生した場合、kt-connect のルーティングバグの可能性があります。ローカルコンピュータのルーティングと API サーバーへの新規追加ルートが競合している可能性があります。パラメータ `--excludeIps 10.0.8.101/32` を追加すると問題が解決するはずです。ネットワークセグメントの競合が多い場合は、例えば `--excludeIps 10.0.8.0/24` を使用してネットワークセグメントの範囲を拡張することができます。詳細は issue-302 をご覧ください。
ktctl.exe 接続--kubeconfig .kubeconfig --namespace feature-N --excludeIps 10 .0.8.101/32 --debug 2. 交換モードktctl.exe exchange serviceA --kubeconfig .kubeconfig --namespace feature-N --expose 12001 --debug このモードは、指定されたサービスへのすべてのトラフィックを傍受し、開発用コンピュータのポートに転送するTelepresenceのインターセプトモードに似ています。このモードを使用すると、環境内のアクセス要求を直接デバッグできます。 具体的な原則としては、サービス内のポッドを serviceA-kt-exchange という名前のポッドに置き換えることです。 注1：Exchangeモードのトラフィックは単方向であり、ローカルコンピュータから開始されたリクエストはプロキシされません。Kubernetesクラスターとローカル開発コンピュータが同じネットワークセグメント上にない場合は、別のコマンドラインを開いてConnectモードを実行し、ローカルサービスがKubernetesクラスター内の他のサービスに接続できるようにする必要があります。詳細はissue-216をご覧ください。
注2：Exchangeモードでは、トラフィックはインターセプトサービスによって転送されます。クラスターリクエストがポッドに直接解決されるなど、サービスを経由しない場合、インターセプトが失敗する可能性があります（Meshモードでも同様です）。そのため、問題が発生した場合は、Kubernetesクラスター内のルーティング状況を運用チームに確認することを忘れないでください。 3. メッシュモードkctl.exe メッシュ サービスA --kubeconfig .kubeconfig --namespace feature-N --expose 12001 --debug コマンドを実行すると、出力ログに次のようなテキストが表示されます。 午後2時30分INF ヘッダー「VERSION: xxxxx」でサービスにアクセスできるようになりました このモードでは、ローカルコンピューター上のサービスとKubernetesクラスター内の同じサービスが同時にリクエストに応答します。ただし、指定されたHTTPリクエストヘッダーVERSION: xxxxを持つリクエストのみがローカルコンピューターに転送されます。Exchangeモードと比較して、これにより他のサービスは正常に動作し続けることができ、開発者はローカルデバッグを実行できます。VERSIONヘッダーの値は毎回動的に生成されます。この値を固定するには、--versionMarkパラメータを使用して指定します。例えば、値をtest-versionに固定するには、コマンドは以下のようになります。 kctl.exe メッシュ サービスA --kubeconfig .kubeconfig --namespace feature-N --expose 12001 --debug --versionMarkテスト バージョン 具体的な手順は、serviceA の Pod を、リクエストヘッダーに基づいてトラフィックのプロキシと転送を行う serviceA-kt-router のルートイメージに置き換えることです。さらに、通常オンラインで実行されている serviceA である serviceA-kt-stuntman サービスが生成されます。また、ローカルコンピュータへのトラフィックのプロキシを行う serviceA-kt-mesh-xxxxx サービスも生成されます。 4. プレビューモードkctl.exe プレビュー serviceB --kubeconfig .kubeconfig --namespace feature-N --expose 12001 Kubernetes クラスターで実行中のサービスを必要とする Exchange モードや Mesh モードとは異なり、プレビュー モードでは、ローカル コンピューターで実行されているプログラムをまったく新しいサービスとして Kubernetes クラスターにデプロイできるため、新しいサービスの開発、デバッグ、プレビューに非常に便利です。 |
