web-dev-qa-db-ja.com

マラソンコンテナはHaproxyと負荷分散され、領事はランダムな503リクエストを返します

現在、アーキテクチャは次のように構成されています。

  • 192.168.1.10、192.168.1.11、192.168.1.12-マラソンと領事サーバーを備えたmesosマスター
  • 192.168.1.21、192.168.1.22、192.168.1.23-領事エージェントを持つ3つのmesosスレーブ

すべてのマシンは次の構成です。

  • dNSサーバーとしての独自のIPアドレス
  • Haproxy.cfgの自動生成のためのconsul-templateを使用したHAPROXY
  • 別のマシンから解決するときにDNSに172.1.0.1アドレスを持つサービスを回避するために、実行中のDockerコンテナーをホストIPアドレスで登録するためのconsul-mesos

私が現在抱えている問題は、ブリッジモードのサービスでDockerコンテナを起動すると、アドレスがDNSによって適切に解決されることです（luigi.service.consulがある場合は、問題なく実行されます） 、しかしCURL -L http://luigi.service.consul/を実行しようとすると、ランダムな503 error codesがあり、アドレスが解決される場合と解決されない場合があります。

これを調査する方法はありますか？

/etc/resolv.confを確認しましたが、ホストIPアドレスをDNS IPとして使用する必要がある場合、DNSアドレスが古いDNS IPアドレス（8.8.8.8）に変更されていることが時々わかります。領事館長の住所を使用しますか？

Tcpflowのデバッグを試みましたが、応答が503の場合、サービスの解決に失敗しているように、しばらく待っているようなものです。

networkingdomain-name-systemload-balancinghaproxyapache-mesos
1
badc0re

Dockerイメージをフェッチし、コンテナーを開始して、最後にリクエストの処理を開始するには、しばらく時間がかかります。理想的には、新しいインスタンスの準備ができるまでにHAProxyをリロードする必要があります。ただし、古いインスタンスへのアクティブな接続がまだ存在する可能性があります。この問題の調査を開始すると、解決策がすでに存在していることがわかります。M。Fowlerが説明しているように、これは 青緑色の展開 と呼ばれます。

ゼロダウンタイムを目指す場合、簡単な解決策はありません。 Yelpのエンジニアは、iptablesにルールを追加して、HAProxyを 真のゼロダウンタイム でリロードする方法を説明しています。

最近 青緑の展開スキーム が marathon-lb にマージされました（Yelpのiptablesトリックを含む）。 consul-mesos現在これをサポートしていません。

1
Tombart