制作実務：K8S民営化配信に基づくこれらの問題に注意する

プロジェクトのプライベート展開に k8s を使用すると、多くの問題が発生します。ここでは著者がよく遭遇する問題と注意すべき点をいくつか挙げます。

リソース依存の問題

プライベートに展開する場合、システムは次のような多くの外部リソースとサービスに依存することになります。

• サーバーリソース
• 外部サービス
• ネットワーク関連リソース

1. サーバーリソースの申請

お客様から提供された業務データや自社システム内のマイクロサービス数などをもとに、事前にサーバーリソース構成リストを整理し、リソースを申請しておく必要があります。

例：

2. 外部サービス

ビジネスニーズに基づいて、プロジェクトの配信に影響を与えないように事前に適用する必要がある SMS サービス、マップ API、公式アカウント、ミニプログラムなどの依存する外部サービスのリストを整理します。

3. ネットワーク関連リソース

• SSL証明書。システムが外部ネットワークに公開されている場合は、SSL 証明書が必要です。ドメイン名の数に制限のないワイルドカード証明書を申請することをお勧めします。下の図に示すように、feishu.cn の下の 2 番目のレベルのドメイン名に属している限り、この証明書を使用できます。

SSL証明書

• パブリックネットワークポート 443/80 の登録。ミニプログラムなど一部のアプリケーションはこれらのポートに依存せざるを得ず、事前に登録する必要があり、サイクルも比較的長くなります。

ロードバランサーの選択

k8sが使用されない場合は、次の図のように、SLBとフロントエンドリソースの展開にNginxがよく使用されます。

k8s を使用した後、Nginx の機能が大幅に弱体化しました。たとえば、転送ルールは Ingress で構成でき、フロントエンド リソースも k8s にデプロイされます。

Nginx は、フロントエンド リクエストを Ingress に転送するなど、SLB としてのみ機能します。その機能は非常にシンプルです。パブリッククラウド、プライベートクラウドを問わず、メーカーがSLBを提供するため、Nginxレイヤーは必要ありません。メーカーが提供する SLB は、リクエストを Ingress に直接転送できます。

SSL証明書のマウント

メーカー提供のSLBを使用すると、k8sのIngressにSSL証明書をマウントする必要はありません。 SLBを直接マウントできます。次の図に示すように、ロードバランサーを通過するリクエストは証明書が削除され、httpに変換されます。

システムオープン戦略概要

ビジネスニーズに応じて、システムネットワークオープンポリシーリストを事前に整理し、次の図に示すように、システムAのイントラネットアクセスやシステムBのエクストラネットアクセスなどの設定のために関係者に渡します。

製品ブランチとイメージ管理

1. 支店管理

プライベート展開のため、一部の要件はパーソナライズされており、これらの要件は一般的なバージョン ブランチと互換性がありません。したがって、コード ブランチと区別する必要があります。たとえば、プロジェクトにはプロジェクトに対応するブランチがあり、一般ブランチには一般ブランチがあります。要件の機能が一般的な要件である場合は、一般ブランチで変更し、テスト後にプロジェクト ブランチにマージすることをお勧めします。実際、どの方法を使用する場合でも、互換性とトレーサビリティが保証される必要があります。

2. 画像タグ管理

画像タグはコードタグにリンクする必要があります。たとえば、コード タグが realse-1.0.0 の場合、イメージ タグもこの名前にすることをお勧めします。こうすることで、問題が発生した場合、画像タグに基づいて対応するコードをすぐに見つけることができます。