Docker+k8s コンテナ クラウドの構築における 10 のよくある問題点

クラウド コンピューティング、DevOps、マイクロサービス アプリケーション アーキテクチャの発展により、コンテナ クラウドは IT の主要なインフラストラクチャ プラットフォームの 1 つになりました。 Docker に代表されるコンテナ技術は、現在効果的なアプリケーション配信モデルの 1 つです。 Kubernetes に代表されるコンテナ オーケストレーション テクノロジーは、人気の高いアプリケーション デプロイメント ソリューションです。クラウド プラットフォーム インフラストラクチャ、DevOps エンジニアリング システム、マイクロサービス アプリケーション アーキテクチャは、IT テクノロジ変革の基盤です。そして、コンテナ クラウドはこの基盤の基礎となります。

[[321597]]

以下の質問は、Docker + K8S コンテナ クラウドの構築中に解決する必要がある最も頻繁に尋ねられる難しい問題です。コミュニティ交流活動から、多くのコミュニティメンバーが回答を共有しました。編集：gavin_zhang

1. 企業はネイティブ Docker を選択すべきでしょうか、それともファット コンテナーやリッチ コンテナーなどのカスタマイズされた Docker を選択すべきでしょうか?

[問題の説明] Docker は、コンテナ化を実行する際に企業が好むコンテナ テクノロジです。しかし、実際のネイティブ Docker の利用、特に従来の仮想マシンの運用保守からコンテナ化された運用保守への移行においては、以下のような問題が発生することがあります。

1. ssh経由でコンテナにログインする方法は、仮想マシンにログインするのと同じように、ssh経由で管理できます。

2. 一般ユーザー向け、コンテナから外部にファイルをコピーする方法

3. スケジュールされたタスクは通常、仮想マシンで構成されます。コンテナにそれらを実装するにはどうすればよいでしょうか?

4. 通常、仮想マシンにはさまざまなエージェントがインストールされます。コンテナにインストールするにはどうすればいいですか?

企業がネイティブ Docker を直接採用する場合、上記の問題はさらに困難になります。したがって、企業がコンテナ技術を選択する場合、仮想マシンの運用および保守モデルとの互換性を最大限に高めるために、実際のニーズに合わせて Docker をカスタマイズする必要があるのでしょうか?

@銀行の技術マネージャー:

ネイティブを使用するか、カスタマイズを使用するかは、企業の強みによって異なります。ほとんどの企業はネイティブのものには手を出さず、この点に人材を費やすことを望んでいません。多くの企業は、運用や保守の問題に対処するなど、アプリケーションを変革することでコンテナ化ソリューションに適応しています。

4つの質問:

1. Docker exec がコンテナに入ることができます。 k8sやocpの場合は対応するAPIもあります

2. 便利なコピー方法: 最初のコンテナ内のアプリケーションによって生成されたファイル ディレクトリがローカルにマウントされます。 2 番目は、docker cp などの対応するコマンドを使用します。あなたが言ったことは、いくつかの単純なシナリオに限定されていないかもしれません。実際、上記の2つだけでなく、いくつかの方法があります。

3. Crontabスケジュールタスクはコンテナでも使用可能

4. まずエージェントの機能を明確にする必要があります。 k8s または ocp を使用すると、ポッドが言いたいことを完了できます。 Docker のみを使用する場合は、機能要件に応じて実行する方法があるはずです。

@gavin_zhang 株式会社銀行のシステムアーキテクト:

1. Docker execは要件を満たすことができる

2. 最も直接的な方法は、ローカルディスクに吊るしてコンテナに保存することです

3. Dockerタスクを定期的に実行するようにスケジュールすることを検討する

4. これらのエージェントは何に使用されますか? Docker インスタンスは、本来は 1 回限りの実行中の不変のインスタンスです。従来の仮想マシンの運用エージェントはコンテナの設計思想に適合していません。

カスタマイズに関する最大の問題は、現在テクノロジーが非常に急速に進歩していることです。一度カスタマイズすると、いくつかのバージョンに固定され、その後のアップグレードとメンテナンスの作業負荷が非常に大きくなります。

2. コンテナ クラウド プラットフォームの主流テクノロジと成熟した製品の選択、および関連する標準と仕様の策定方法に関する議論。

【問題の説明】コンテナプラットフォームを導入する際には、まず現在主流となっているコンテナプラットフォーム技術と成熟した製品を理解した上で、関連する標準や仕様を策定する必要があります。詳細は以下の通りです。

• 現在主流のコンテナ プラットフォームである openshift3、openshift4、Rancher、Boyun と他の国内コンテナ メーカーの違いを知りたいです。コンテナ プラットフォームを選択するには?これらの製品の機能と性能を比較します。
• 資本コストに加えて、コンテナプラットフォームの将来的な利用や運用・保守をどのように考えていくべきでしょうか？現時点では、コンテナプラットフォームの自社開発能力は存在しない。運用・保守担当者には具体的にどのような能力が必要ですか?運用・保守は開発とどのように連携するのでしょうか?運用・保守要員への投資規模をどのように見積もればよいのでしょうか?
• コンテナ プラットフォームの初期実装中に、どのような計画を立てる必要があり、どのような落とし穴を避けるべきでしょうか。

多くの同僚がこの質問に対する詳細な回答を共有しています。私たちはそれを記事にまとめて、少し前に読者に公開しました。以下のタイトルをクリックして確認してください。

3. 金融マルチセキュリティドメイン環境における Kubenetes のアーキテクチャ計画上の問題は何ですか?

[問題の説明] 金融業界のネットワーク アーキテクチャには、複数のセキュリティ ドメイン設計が存在します。 Kubernetes のマルチセキュリティ ドメイン ネットワーク分離の場合、各セキュリティ ドメインは k8s クラスターのセットをデプロイしますか?実稼働環境の k8s クラスターにおける calico のネットワーク制御戦略のベスト プラクティスは何ですか?

@nameless クラウド コンピューティング会社のテクニカル ディレクター:

理論的には、各セキュリティ ドメインのネットワークは分離されています。 k8s クラスターがデプロイされている場合、すべてのノードとマスターノードが接続され、ノードもデフォルトで接続されます。同じコンテナ管理プラットフォームを使用して、各セキュリティ ドメインに k8s クラスターのセットをデプロイできます。これは k8s マルチクラスター管理です。

Calico は、k8s のネットワーク プラグインの 1 つです。 flannel や ovs などのさまざまなネットワーク プラグインもあります。実稼働環境で使用するネットワーク プラグインは、独自のビジネス ニーズに応じて選択する必要があります。

@銀行の技術マネージャー:

実際のところ、それほど複雑である必要はありません。たとえば、k8s クラスターは、インターネット領域、中間ビジネス領域、コアビジネス領域に分割できます。 2 つのノードをインターネットに、2 つを中間ビジネスに、2 つをコアビジネスに使用できます。たとえば、マスターノードはすべて OA エリア内にあります。マスターがネットワーク上の 6 つのノードと通信できる限り、ノードが相互にアクセスする必要はありません。 1 つのクラスターでも十分です。

Calico はクラスター内外のアクセスの問題を解決できますが、クラスターにアクセスする必要がある外部ノードの数が増えると、運用および保守コストが非常に高くなります。イングレスと同様のソリューションを使用できます。

4. コンテナ クラウド プラットフォームを構築するときにネットワークを選択するにはどうすればよいですか? SDN ネットワークを選択する場合、SDN ネットワーク実装ソリューションをどのように選択すればよいでしょうか?

[問題の説明] コンテナネットワークを選択するにはどうすればよいでしょうか?コンテナ クラウド プラットフォームのネットワークは、常に技術的な問題となってきました。 SDN ネットワークを使用するか、アンダーレイ ネットワークにブリッジするべきでしょうか? SDN ネットワークを使用する場合、多数の SDN ネットワーク実装ソリューションからどのように選択すればよいのでしょうか?

@liufengyi インターネット銀行のソフトウェア アーキテクト:

アプリケーション変革のコストを大幅に削減し、企業の元のネットワークに基づいて実行できるように、企業全体のネットワークをフラット化して相互接続することを優先する必要があります。コンテナ アプリケーションが比較的独立したサービスである場合は、オーバーレイを検討できます。規模が大きくない場合は、オープンソースのネットワーク コンポーネントを検討することもできます。

@金融企業のシステムエンジニア：

calico、bgp、ingress、nginxなどはすべてOKです

1. Calico はクラスター内のネットワークとクラスター外のネットワークを接続します。ただし、クラスター外部からクラスター内のノードにアクセスが増えると、運用と保守の難易度が増します。

2. BGPは内部ルーティングプロトコルを設定する必要があり、パフォーマンスの低下を引き起こします。

3. Ingress と nginx は似ています。これら 2 つのコンポーネントを使用して、外部アプリケーションをクラスターにロードします。

4. ホストネットワーク方式

5. ノードポート方式

…

どのように選択するかは、独自のITアーキテクチャと規制要件によって異なります。

@zhuqibs ソフトウェア開発エンジニア:

SDN かアンダーレイかに関してですが、自分で構築するのであれば、絶対に SDN を選択しないでしょう。それはコストの問題です、兄弟たち！昨年、シスコは当社のために ACI を構築したいと考えていましたが、スイッチのコストは 10,000 元以上でした。銀行にお金がたくさんあれば問題ないが、中小企業は資金が不足しており、疫病の影響で銀行を選ぶのが難しくなっている。

VMware の NST-G も使用しましたが、これにはバグがあります。このPKSには毎月「期間」があります。毎回、ネットワーク ストレージが完全にブロックされ、IO が基本的に遅くなります。メーカーは半年以上もの間、問題解決のために人を派遣し、スイッチも交換しましたが、問題は解決しませんでした。その結果、彼らは私たちに3台のサーバーを補償し、それらをすべて通常のvcentorに置き換えました。

SDN は素晴らしいように聞こえますが、現実は非常に厳しいものです。もちろん、お金があり、試行錯誤して新しい技術を追求する意欲があれば、問題はありません。たとえば、Alibaba Cloud や Tencent Cloud などのパブリック クラウドは、ギャップを埋めるための資金と人材を備えているため、基本的に SDN に対応しています。

したがって、ほとんどの企業では、Underlay と Kubernetes 独自の California、Fannel、または Cattle のみが必要であり、通常は問題はありません。唯一の問題は、ネットワーク上にハード的な分離がなく、カスタマイズされたものもないことですが、パブリック クラウドを使用できます。自分たちで建てるには多額の費用がかかります。

@xiaoping378 テクノロジー企業のシステムアーキテクト:

1. コンテナ クラウド プラットフォームの構築について話しているため、ネットワーク インフラストラクチャがすでに存在している必要があり、データ センター レベルの SDN ソリューションは考慮されません。既存のネットワーク構築の成果を基に構築することのみを検討してください。

2. 商業的な解決策について迷信的にならないでください。オープンソースであろうと商用ソリューションであろうと、誰もが k8s の CNI インターフェースに準拠する必要があります。ネットワーク速度制限、グループ セキュリティ戦略など、コンテナ ネットワーク ソリューションにあまり多くの機能を配置することはお勧めしません。

3. ホスト層は通常、第 2 層にアクセス可能であることを保証できることを考慮します。最も簡単な解決策はフランネルです。現在、Flannel は、vxlan モードで DR ネットワークを有効にすることをサポートするように開発されています。簡単に言えば、同じサブネット内で hostgw が使用され、ホスト マシンはネイキッド ネットワークに近いパフォーマンスを持つソフト ルーターとして機能します。サブネットが崩壊した場合は、vxlan が使用されます。パフォーマンスとスケーラビリティの両方を考慮します。さらに、フランネルは現在、大規模コンテナ クラウドにおけるルーティング テーブルや ARP の過剰使用の問題の最適化に注力しており、拡張されたホストごとにルーティング項目、FDB 項目、ARP 項目がそれぞれ 1 つだけ追加されることを実現しています。

4. コンテナ ネットワークの分離とセキュリティ ポリシーを考慮する場合 (実際には必要ありません。ネットワークの分離については、プロジェクト レベルでスケジュール ポリシーを設定して物理的な分離を実現できます)、Calico と Flannel を組み合わせた Canal ネットワーク ソリューションを検討できます。

@Garyy 保険システムエンジニア:

コンテナ ネットワークを構築するためのアイデア:

コンテナ ネットワーキングの開発は、現在、2 つの競争になっています。この 2 つは、実際には Google、CoreOS、Kuberenetes が主導する Docker の CNM と CNI を指します。まず、CNM と CNI はネットワーク実装ではなく、ネットワーク仕様とネットワーク システムであることを明確にする必要があります。 R&D の観点から見ると、それらは単なるインターフェースの集まりです。下層にフランネルを使用するか、カリコを使用するかは関係ありません。 CNM と CNI が重視しているのは、ネットワーク管理の問題です。

ネットワーク需要調査の結果、業務部門が主に以下の点を懸念していることがわかりました。1. コンテナ ネットワークと物理ネットワークの接続。 2. 早ければ早いほど良い。 3. 変更は少ないほど良い。 4. リスクポイントを可能な限り少なくする。

コンテナのネットワーク ソリューションは、プロトコル スタック レベル、トラバーサル形式、分離モードの 3 つの形式に大別できます。

プロトコル スタック レイヤー: レイヤー 2 は比較的理解しやすく、従来のコンピュータ ルームや仮想化シナリオでよく使用されます。これはブリッジング ARP+MAC 学習に基づいており、最大の欠点はブロードキャストです。第 2 層のブロードキャストによってノードの規模が制限されるため、第 3 層 (純粋なルーティング転送) プロトコル スタックの第 3 層は、一般的に BGP に基づいており、コンピューター ルーム全体のルーティング状態を自律的に学習します。その最大の利点は IP の浸透性であり、つまり、この IP に基づくネットワークであれば、このネットワークを通過できるということです。明らかに、その規模は非常に有利であり、優れたスケーラビリティを備えています。しかし、実際の展開プロセスでは、企業のネットワークが主に制御されます。たとえば、一部の企業ネットワークでは、セキュリティ上の理由から開発者が BGP を使用することを許可していなかったり、企業ネットワーク自体が BGP ではなかったりします。この場合、制限があります。レイヤー 2 とレイヤー 3 を組み合わせたプロトコル スタックの利点は、純粋なレイヤー 2 のスケーラビリティの問題と純粋なレイヤー 3 のさまざまな制限を解決できることです。特にクラウド VPC シナリオでは、VPC のノード間レイヤー 3 転送機能を利用できます。

クロッシングフォーム：実際の展開環境に密接に関係します。交差フォームには、アンダーレイとオーバーレイの 2 種類があります。

アンダーレイ: 適切に制御されたネットワーク シナリオでは、通常、アンダーレイを使用します。ベアメタルであろうと仮想マシンであろうと、ネットワーク全体が制御可能であれば、コンテナネットワークは直接通過できると簡単に理解できます。これはアンダーレイです。

オーバーレイ: オーバーレイはクラウド シナリオでは一般的です。オーバーレイの下には制御された VPC ネットワークがあります。 VPC の管轄外の IP または MAC が表示された場合、VPC はこの IP/MAC の通過を許可しません。このような場合は、Overlay メソッドを使用してこれを実行できます。

オーバーレイ ネットワークは物理ネットワークを仮想化し、リソースをプールするもので、クラウド ネットワーク統合を実現するための鍵となります。このアプローチでは、オーバーレイ ネットワークと SDN テクノロジーを組み合わせ、SDN コントローラーをオーバーレイ ネットワーク コントロール プレーンのコントローラーとして使用することで、ネットワークとコンピューティング コンポーネントの統合が容易になり、ネットワークをクラウド プラットフォーム サービスに変換する場合の理想的な選択肢となります。

分離方法: 分離方法は通常、VLAN と VXLAN に分けられます。

VLAN: VLAN はコンピュータ室で広く使用されていますが、実際には問題があります。つまり、入居者総数は制限されます。ご存知のとおり、VLAN の数には制限があります。

VXLAN: VXLAN は現在、より主流の分離方法です。スケーラブルで大規模であり、より優れた IP トラバーサル方式に基づいているためです。

@Steven99 ソフトウェア アーキテクト:

個人的にはコンテナネットワークの選択は重要なポイントではないと思います。実際、どのタイプのネットワークが使用されるかに関係なく、エンドユーザーに対して透過的である必要があるため、ネットワーク モデルにこだわる必要はありません。

考慮すべき重要なポイントとしては、セキュリティ、安定性、使いやすさなどが挙げられます。当社では Calico ネットワークを使用していますが、多くの問題が見つかったため、交換を検討しています。オープンソース製品では、常に多くの追加作業、テストと検証、段階的な最適化が必要になります。実際に使用してみなければ、どちらがより適しているかを判断するのは困難です。使用しているうちに徐々にニーズが明らかになるかもしれません。

特に生産ビジネスにおいては、コンテナセキュリティとコンテナネットワークセキュリティが重要なポイントとなるかもしれません。サービスの数が一定量に達すると、予期しない問題が多く発生します。もちろん、実際にやってみないと選ぶのは難しいので、まずは使ってみてもいいでしょう。頻繁に使用することで、自分が何を望んでいるのかが徐々にわかってきます。

5. コンテナの東西ネットワークのセキュリティについてはどう考えていますか?

@zhuqibs Mcd ソフトウェア開発エンジニア:

東西トラフィックの制御はサービスメッシュの制御範囲内であり、istio で実現できますが、istio は現時点では不完全であるため、使用が困難です。 Kong や Traefik に代表される API ゲートウェイの使用をお勧めします。 Kong は nginx をベースにしており、コンテナ内の各ポッドにデプロイしてポッド間のトラフィックを制御できます。

@nameless クラウド コンピューティング会社のテクニカル ディレクター:

East-West トラフィックとは、同じホスト上のコンテナ間のアクセスを指します。同じホスト上のポッドはデフォルトで相互運用可能です。

上位レベルの論理制御、つまり業務に応じて異なる論理クラスターを分割し、関連する業務を同じ論理クラスターに配置するようにすることで、セキュリティリスクを軽減できると考えています。

6. コンテナ内のアプリケーションの問題をトラブルシューティングする方法について議論しますか?

[問題の説明] コンテナ外のアプリケーションがコンテナ内のアプリケーションにアクセスしたり、コンテナ内のアプリケーションがコンテナ外のアプリケーションにアクセスしたりする際に、コンテナ内のスタック情報を取得し、分析用にパケットをキャプチャし、IP アドレスに基づいてアクセス リンクを追跡するにはどうすればよいでしょうか。

@zhuqibs Mcd ソフトウェア開発エンジニア:

コンポーネントの監視の観点から、SkyWalking を使用してリンク上の API 呼び出しのポート情報を追跡できます。市販の APM コンポーネントを使用する場合は、Cisco と Tingyun のどちらも優れた製品を提供しています。

マイクロサービス アーキテクチャでは、各ポッドはサービスです。 Kong コンポーネントは各アプリケーション ポッドに追加されます。各 Kong コンポーネントは、トラフィック監視データを Prometheus に入力できます。このように、リンク監視ソフトウェアの機能を置き換えることは不便ではありません。もちろん、それは「部分的」なだけです。 Skywalking と APM は他の種類のデータも取得できます。

@liufengyi インターネット銀行のソフトウェア アーキテクト:

障害検出とトラブルシューティングのために APM を統合しました。コンテナがどのホスト上にあるかを照会し、指定された仮想ネットワーク カード上のコンテナのネットワーク パケットをキャプチャできます。

@gavin_zhang 株式会社銀行のシステムアーキテクト:

アプリケーションフレームワークにダンプ機能を追加することでスタック情報をダンプし、ログの形式でログシステムに出力することができます。

アプリケーションの完全なリンクを実現するために、ソリューションには Spring Cloud Sleuth などが含まれています。

7. コンテナ クラウド プラットフォームの全体的な計画: コンピューティング リソース、ストレージ、ネットワークの選択を含みますか?

【問題の説明】コンピューティングリソース、ストレージ、ネットワークの選択を含む、コンテナクラウドプラットフォームの全体的な計画を知りたい。マイクロサービスをコンテナ クラウド プラットフォームに移行する予定です。

@nameless クラウド コンピューティング会社のテクニカル ディレクター:

個人的な意見:

1. まず、コンテナ クラウド プラットフォームを構築する目的を決定し、コンテナ上で実行する業務、おおよそのリソース要件、クラスター サイズの大きさなどを計画します。

2. コンテナ プラットフォームの選択。基本的には k8s なので、問題はありません。

3. コンピューティング リソース: 基本的に、コンピューティング リソースとしてベア メタルまたは仮想マシンが使用されます。どちらのソリューションにも、それぞれ長所と短所があります。すでに IaaS プラットフォームをお持ちの場合は、仮想マシンを使用できます。 IaaS プラットフォームがない場合は、ベアメタルを直接使用することもできます。

4. ネットワーク リソース: ビジネス コンテナーを変換する必要があるかどうかを検討する必要があります。また、将来的にはコンテナプラットフォームへの業務移行プロセスも検討します。たとえば、マイクロサービス ビジネスをコンテナ プラットフォームに移行する場合、最初に一部のマイクロサービスを移行するべきでしょうか、それともマイクロサービス全体を移行するべきでしょうか。一部のマイクロサービスを移行した後、コンテナにインストールされているマイクロサービスとコンテナにインストールされていないマイクロサービス間のネットワーク通信など。

5. ストレージ リソース: コンテナーがステートフル ビジネスかステートレス ビジネスか、またビジネスがパフォーマンスに与える影響を考慮し、適切なストレージ リソースを選択します。

まとめると、運用保守チームの運用保守能力や開発とのつながりなども考慮する必要があります。

8. コンテナ クラウド プラットフォームを使用してシステム開発およびテスト機能を向上させるにはどうすればよいでしょうか?

【問題の説明】 同社は現在、springcloud マイクロサービス システムを選択しています。開発およびテストのプロセス中に、コンテナ クラウド プラットフォームを使用してシステム開発およびテスト機能を向上させるにはどうすればよいでしょうか。どのような機能を改善できますか?

より良い実践方法や注意すべき重要なポイントはありますか?たとえば、共通サービス (登録センターなど) を最初に構築する必要がありますか? テスト クラウド用の共通サービス セットを開発する必要がありますか? Maven プライベート ウェアハウス管理、基本的なイメージ管理など。

@gavin_zhang 株式会社銀行のシステムアーキテクト:

テストでは、コンテナ プラットフォームの継続的デリバリー機能を使用して、テスト バージョン サイクルと環境の準備時間を短縮できます。プラットフォームの柔軟なルーティング機能を使用して、複数バージョンの互換性テストを実行します。

より良い実践パスと注意すべき重要なポイント:

1. 共通サービスはプラットフォームサービスに組み込むことをお勧めします。ただし、テストと開発に同じ実行インスタンスを使用することはお勧めしません。

2. プライベート イメージ リポジトリを確立し、基本的なイメージ ホワイトリストを作成します。

3. イメージのバージョン管理を行い、コンテナと git タグを使用してインスタンスとイメージ、イメージとソースコード間の対応を実現します。

9. 重要な銀行業務シナリオでローリングアップデートに k8s を使用するにはどうすればよいでしょうか?

@銀行の技術マネージャー:

この質問には多くの詳細が含まれており、ビジネス シナリオによって異なります。消費などの強力な一貫性トランザクション ビジネスは、アプリケーション自体によって保証される必要があり、トランザクションが失敗した場合にはロールバックできる必要があります。バージョン アップグレードのロールバックには、エレガントなシャットダウンが必要です。一部のチャネル トランザクションは中間転送のみを実行し、通常は直接アップグレードおよびロールバックできます。

アップグレードのロールバック操作は、主にアプリケーションが依存するイメージ バージョンを置き換えることによって実行されます。 k8s のアップグレード ロールバックは、新しいバージョンのイメージまたは古いバージョンのイメージを使用して新しいポッドをプルアップし、古いポッドをオフラインにして、この操作を順番に完了し、ビジネスの正常な動作を確保することです。

@gavin_zhang 株式会社銀行のシステムアーキテクト:

プラットフォーム: K8s トラフィック分散と組み合わせて、カナリアリリースメカニズムを実装し、洗練されたトラフィック制御を通じてビジネスのローリングアップデートを実現します。アプリケーション: アプリケーションは合理的な設計になっている必要があります。計画時には適切な設計が必要です。アプリケーションのリリース範囲を最小限に抑えるために、アプリケーションは結合度を低くして合理的に分割する必要があります。最も重要なことは、特に会計データに影響する問題のロールバックをどのように実装するかです。データの色分けやゼロタイム テーブルを使用して、アプリケーションを可能な限り追跡可能にします。

@rangeryu Ant 金融プロダクトマネージャー:

この質問への回答は、大規模なリリースを行う際に Ant が重視する変更管理と併せて考えることができます。

グレースケールリリースやカナリアリリースにネイティブデプロイメントを使用する場合、デフォルトでは Pod の変更やトラフィック管理の制御が不十分であり、ロスレスリリースやオンデマンドプロセス制御を実現することはできません。そこで、PaaS 製品レベルでカスタマイズを行い、Kubernetes レベルでカスタム リソースを拡張しました。目標は、クラウドネイティブ シナリオでリリース プロセス全体をきめ細かく制御し、技術リスク管理の 3 つの原則に沿って、大規模なクラスター リリース、グレースケール、ロールバックをよりエレガントにすることです。

実際の運用環境では、コンテナへの大規模な変更には、各ステップが期待どおりであり、検証に合格していることを確認するために、より多くの側面からのビジネス監視と観察が伴います。アプリケーション インスタンス レベルでのこのような洗練された制御により、運用と保守にタイムリーなブレーキとロールバックの機会が提供され、オンライン アプリケーション リリースの重要な安全ロープとなります。

簡単に言えば、Ant 内のすべての変更は、「グレー表示可能、監視可能、緊急時に対応可能」という要件を満たす必要があります。インフラストラクチャがクラウド ネイティブに完全に移行したとき、Kubernetes に基づいて多くの拡張機能と追加が行われました。金融ビジネス シナリオでは、実際の製品レベルから、次のことを行う必要があります。

1. 基礎となるトポロジーを認識する

2. グループ/ベータ/バッチリリース

3. エレガントなトラフィック除去

10. コンテナ クラウドの高可用性の問題は何ですか?高可用性を実現するには、コンテナ クラウド内に複数の独立した Kubernetes クラスターが必要です。障害分離を実現するために、基盤となるネットワークとインフラストラクチャをどのように展開すればよいでしょうか?アプリケーションはどのようにして複数のクラスター間でフェイルオーバーを実現できますか?

@銀行の技術マネージャー:

k8s アプリケーションの高可用性機能はすべて k8s 自体によって実現されます。クラスター間で単一のアプリケーションの高可用性を実現する必要がある場合は、コンテナ クラウド プラットフォームとパブリック イメージ リポジトリ上のアプリケーションの状態を監視するように高度にカスタマイズする必要があります。

@gavin_zhang 株式会社銀行のシステムアーキテクト:

現在の実装ソリューションの 1 つは、アプリケーション層を使用してクラスタ間高可用性ソリューションを提供し、Euraka や Zookeeper などのクラスタ間管理センターを使用してアプリケーション間のクラスタ間呼び出しを実装することです。サービス メッシュが実装されている場合は、サービス メッシュ レイヤーで実装することを検討できます。