http://container-solutions.com/kubernetes-deployment-strategiesで説明されている青/緑のデプロイパターンは、kubernetesまたはhelmではネイティブでサポートされていません。 それがどこかに属していた場合、それはヘルムまたはkubernetesでしょうか？ ヘルムメンテナは青/緑のプルリクエストを受け入れる可能性がありますか？
burnettk
全てのコメント3件
これは実際には、サービスメッシュが非常にうまく処理できるものです。 アプリケーションに着信するトラフィックのフローを制御するため、段階的なロールインとロールアウトを処理できるため、アプリケーションの青/緑のデプロイメントを実行する必要がある場合は、
Helmは、従来のパッケージマネージャーの意味でより機能し、チャートをあるバージョンから次のバージョンに優雅にアップグレードします（ポッドの活性/準備プローブと展開更新戦略のおかげで）、 apt upgradeようなものを期待する方法とよく似ていますapt upgrade 。 青/緑の展開は、パッケージマネージャースタイルのアップグレードワークフローとは大きく異なります。 青/緑はツールチェーンの上位レベルにあります。これは、これらの展開に関するユースケースでは、ステップイン/ステップアウトポリシー、段階的なトラフィックの移行、およびロールバックが必要なためです。 そのため、青/緑の展開はHelmの範囲外であると判断しましたが、Helmをカバーの下で利用するツール（またはistioのような並列のもの）は、そのユースケースを処理できる可能性が高いです。
詳細については、次のスレッド/ブログ投稿の説明を参照してください。
- https://github.com/kubernetes/kubernetes/issues/33462
- http://dougbtv.com/nfvpe/2017/06/05/istio-deploy/
お役に立てれば！
bacongobbler
2018年02月16日
回答どおりに終了しますが、b / gの展開についてさらに質問がある場合は、再度開いてください。 ありがとう！
bacongobbler
2018年02月20日
@bacongobblerあなたがどこから来たのかはわかりますが、istioは私たちが望むものを実装するための低レベルの方法だと思います。 私が言いたいのは、（少なくとも私にとっては）サーバー全体の展開をヘルムチャートで説明しているということです。 チャートをあるバージョンから次のバージョンに変更すると、ヘルムファイルを読み取り、すべての変更をデプロイするヘルム。 今では、チャートで説明されている下位レベルのコンポーネントとインターフェイスすることでこれを実行しますが、それでも、kubectlやその他のコマンドを直接実行して変更を加えているわけではありません。 さらに、そうすることは間違っていると思います。なぜなら、世界の状態が1つのツールの領域内になく、これらのツールが連携しないとエラーが発生するからです。 それとも私は何かが足りないのですか？
ofersadgat
2018年04月09日
関連する問題
naveensrinivasan
·
3コメント
dkirrane
·
3コメント
macknight
·
3コメント
mikhno-s
·
3コメント
robsonpeixoto
·
3コメント
最も参考になるコメント
@bacongobblerあなたがどこから来たのかはわかりますが、istioは私たちが望むものを実装するための低レベルの方法だと思います。 私が言いたいのは、（少なくとも私にとっては）サーバー全体の展開をヘルムチャートで説明しているということです。 チャートをあるバージョンから次のバージョンに変更すると、ヘルムファイルを読み取り、すべての変更をデプロイするヘルム。 今では、チャートで説明されている下位レベルのコンポーネントとインターフェイスすることでこれを実行しますが、それでも、kubectlやその他のコマンドを直接実行して変更を加えているわけではありません。 さらに、そうすることは間違っていると思います。なぜなら、世界の状態が1つのツールの領域内になく、これらのツールが連携しないとエラーが発生するからです。 それとも私は何かが足りないのですか？