他のタイプのサービスと区別するために、おそらくサービスの名前をlbserviceなどに変更する必要があることに注意してください。

この一環として、コアapiserverからサービスオブジェクトを削除し、HAProxyやnginxなどの他のロードバランサーの使用を容易にします。

サービスの論理定義（クエリやグローバル名）を複数の方法で使用/特殊化できれば便利です-インフラストラクチャを介してインストールされた単純なロードバランサーとして、nginxのようなより機能的な完全なロードバランサーとしてまたは、インフラストラクチャによって提供されるhaproxyは、インテグレータがポーリング/待機できるクエリ可能なエンドポイントとして（GET / services / foo-> {endpoints：[{host、port}、...]}）、またはホストが利用できる情報として提供されますローカルロードバランサーを公開します。 明らかに、これらは複数の異なるユースケースである可能性があり、それ自体が独自のリソースに分割されますが、メカニズムとは異なるインテント（lbの下で統合）を指定する柔軟性があると、幅広い要求を満たすのが容易になります。

@smarterclayton私は機構と方針の分離に同意します。

必要なプリミティブ：

1. ラベルセレクターによって識別されたセットをポーリング/監視する機能。 まだ問題が提起されているかどうかわからない。
2. ポッドIPアドレスを照会する機能（＃385）。

これは、他の名前付け/検出メカニズムやロードバランサーで構成するのに十分です。 次に、コアの上に、一般的なパターンを単純なAPIでバンドルする高レベルのレイヤーを構築できます。

@ bgrant0607によって記述された2つのプリミティブは、この問題を開いたままにしておく価値がありますか？ または、提出できるより具体的な問題はありますか？

動物園の飼育係は解決されていないと思います。各コンテナに一意の識別子が必要だからです。 これは、3つの個別のレプリケーションコントローラー（インスタンスごとに1つ）またはレプリケーションコントローラーのモードで実行できると思います。

ブライアンが指摘するように、サービス設計については議論に値すると思います。 現在、インフラストラクチャの抽象化（ローカルプロキシ）と公開のメカニズム（すべてのコンテナの環境変数）をラベルクエリで結合しています。 L7ホスト/パスを取得し、それらをラベルクエリにバランスさせ、http（s）やWebソケットなどのプロトコルをサポートするエッジプロキシにも同様に有効なユースケースがあります。 さらに、サービスには、クラスター全体で共有される60kのバックエンド（割り当てられたIPの量）というハードスケールの制限があります。 そのホスト上のコンテナが必要とするサービスのみをプロキシするミニオンでローカルプロキシを実行できる必要があります。また、コンテナが外部ポートについて知る必要がないようにする必要があります。 必要に応じて、このディスカッションを＃494に移動できます。

マスタースレーブ複製データベース、固定サイズのピアグループ（etcd、zookeeperなど）を使用したKey-Valueストアなど、固定複製を使用したシングルトンサービスおよび非自動スケーリングサービスの問題への取り組み。

固定レプリケーションの場合は、予測可能な配列のような動作が必要です。 仲間はお互いを発見し、個別に対処できる必要があります。 これらのサービスには通常、独自のクライアントライブラリやプロトコルがあるため、インスタンスを個別にアドレス指定できるようにする以外に、クライアントが接続する必要があるインスタンスを決定する問題を解決する必要はありません。

提案：Cardinalサービスと呼ばれる新しいフレーバーのサービスを作成する必要があります。これは1つではなくN個のIPアドレスをマップします。 カーディナルサービスは、これらのIPアドレスをラベルセレクターのターゲットとなるN個のインスタンスに安定して割り当てます（つまり、指定されたN個のインスタンスだけでなく、多くのターゲットが存在する場合もあります）。 DNS（＃1261、＃146）を取得すると、提供されたプレフィックスに基づいて予測可能なDNS名が割り当てられ、接尾辞は0からN-1になります。 割り当ては、対象のポッドの注釈またはラベルに記録できます。

これにより、標準のアプリケーション構成メカニズムで使用できる安定した名前とIPアドレスを提供しながら、ポッドとレプリケーションコントローラーのIDからの役割の割り当ての分離が維持されます。

さまざまなタイプの負荷分散に関する議論の一部は、サービスv2の設計で行われました：＃1107。

マスター選挙のために別の問題を提出します。

/ cc @smarterclayton @thockin

割り当ては、いくつかの環境パラメーター化メカニズムを介してポッドに引き継がれる必要があります（ほぼ確実に）。

etcdの例では、次を作成します。

• レプリケーションコントローラーのカーディナリティ1：1ポッド、安定したストレージボリュームAを指す
• レプリケーションコントローラーのカーディナリティ2：1ポッド、安定したストレージボリュームBを指す
• レプリケーションコントローラーのカーディナリティ3：1ポッド、安定したストレージボリュームCを指す
• ポッドを指すカーディナルサービス「etcd」

ポッド2が停止すると、レプリケーションコントローラー2はそのコピーを作成し、ボリュームBに再接続します。カーディナルサービス 'etcd'は、そのポッドが新しいことを認識しますが、カーディナリティ2（保存されたデータから取得）である必要があることをどのように認識しますか。ボリュームB）？

3つのレプリケーションコントローラーではなく、シャーディングコントローラーを使用してみませんか。
決定を下すときに「kubernetes.io/ShardIndex」のようなラベルを調べます。 もしも
3方向のシャーディングが必要な場合は、インデックスが0、1、2の3つのポッドが作成されます。
これは以前に撃墜されましたが、それが引き起こした問題を再現することはできません
私の頭。

これが比較的である場合、ユーザーにその負担をかけることは間違っているように思われます
一般的なシナリオ。

特定のポッドの公称IPが次の理由で変更されるかどうかが重要だと思いますか
セット内の無関係な変更？ 例えば：

時間0では、ポッド（A、B、C）がIPを使用して基本的なサービスを構成します。
それぞれ10.0.0。{1-3}

時間1で、ポッドBをホストするノードが停止します

時間2で、Bを駆動するレプリケーションコントローラーが新しいポッドDを作成します

時間3で、カーディナルサービスはIPが10.0.0の（A、C、D）に変更されます。{1-3}
それぞれ

注意：ポッドCの「安定したIP」は、セット時に10.0.0.3から10.0.0.2に変更されました
メンバーシップが変更されました。 これはランニングに悪いことをするだろうと思います
接続。

これを回避するには、順序値を指定する必要があります
サービスの外、または何か他の賢い。 多分それは大丈夫です、しかしそれは
人々がそれに対処しなければならない場合、壊れやすく、間違えやすいようです。

10:17の木、2014年10月2日には、クレイトン・コールマン[email protected]
書きました：

割り当ては、いくつかを介してポッドに持ち越される必要があります
環境パラメータ化メカニズム（ほぼ確実に）。

etcdの例では、次を作成します。

• レプリケーションコントローラーのカーディナリティ1：1ポッド、安定したポインティング
  ストレージボリュームA
• レプリケーションコントローラーのカーディナリティ2：1ポッド、安定したポインティング
  ストレージボリュームB
• レプリケーションコントローラーのカーディナリティ3：1ポッド、安定したポインティング
  ストレージボリュームC
• ポッドを指すカーディナルサービス「etcd」

ポッド2が停止すると、レプリケーションコントローラー2はポッドの新しいコピーを作成し、
ボリュームBに再接続します。カーディナルサービス 'etcd'は、そのポッドが
新しいですが、カーディナリティ2（
ボリュームB）に保存されているデータ？

このメールに直接返信するか、GitHubで表示してください
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -57663926
。

シャーディングコントローラーは理にかなっており、カーディナルサービスのコンテキストではおそらくより便利だと思います。

メンバーシップに基づくIPの変更は恐ろしいことだと思いますし、多くの退化したエッジケースを考えることができます。 ただし、カーディナリティがポッドと一緒に保存されている場合、決定はそれほど難しくありません。

まず第一に、私はこれがシャーディングについてであるとは意図していませんでした-それは＃1064です。 シャーディングの議論をそこに移しましょう。 シャーディングに類似のメカニズムを使用しようとする多くのケースを見てきましたが、シャーディングを実装するための最良の方法ではないと結論付けました。

次に、N個のレプリケーションコントローラーを実行する必要はないというのが私の意図です。 必要な数はデプロイメントの詳細（カナリア、複数のリリーストラック、ローリングアップデートなど）によって異なりますが、使用できるのは1つだけです。

第三に、これが永続的なデータ提案（＃1515）とどのように相互作用するかを検討する必要があることに同意します- @ erictune 。

第四に、私たちはおそらくアイデンティティをポッドに反映する必要があることに同意します。 ＃386に従って、理想的には、標準のメカニズムを使用して、IPとDNSの名前の割り当てをポッドに表示します。 Linuxでは通常IPとホストのエイリアスはどのように表示されますか？

第5に、ラベルまたは注釈を介してポッドに割り当てを記録することにより、割り当ての安定性を確保することを提案しました。

第6に、レプリケーションコントローラーを「シャーディングコントローラー」に置き換える際の問題は、イメージ/環境管理から役割の割り当てを切り離したいということです。 レプリケーションコントローラーが後者を提供していると思います（https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment-57678564を参照）。

耐久性のあるデータの場合、＃1515によると：

1. 耐久性のあるポッドの場合、この提案はうまくいきます。 耐久性のあるポッドの割り当ては安定しています。
2. 個別のデータオブジェクトの場合、カーディナルサービスは、データオブジェクトの役割の割り当ても管理する必要があり、ポッドがデータと照合されるまで、ポッドへの役割の割り当てを延期します。 これは簡単だと思います。

/ cc @erictune

会話をしやすくしようとしていたと思いますが、うまくいったかどうかはわかりません。

Re：シャーディング-「明確なアイデンティティを持つレプリカのセット」は基本的にシャーディングではありませんか？

Re：1つのレプリケーションコントローラー-現在、インデックスを割り当てるレプリケーションコントローラーはありません。 私たちはそれを望んでいないと思いますか？

Re：ポッドに独自のIDを伝える-サービスはポッド上のクリーンなレイヤーです。 差し迫ったポッドについてサービスに通知して、存在する前にIPを割り当てることができるようにするのは面倒です。 IDはポッドの一部である必要があると思います。たとえば、ShardIndexラベルなどです。 それをポッドに（どういうわけか）反映することができ、サービスはそれをIPの割り当てに使用できます。 Cardinalサービスにそれ自体を実行させると、ポッドは割り当てられた時点ですでに開始されています。 GCEのVMの場合と同じように、ポッドごとのメタデータを作成することもできますが、それはより大きな提案です。

いいえ、シャーディングには、安定した明確なIDを提供する必要も十分でもありません。 詳細については、＃1064を参照してください。

いいえ、レプリケーションコントローラーにインデックスを割り当てたくありません。 私は意図的に枢機卿のサービスが代わりにそれをすることを提案しました。

はい、役割（インデックス）が割り当てられる前にポッドが存在する（そして潜在的に開始される）ことを期待しています。 それは意図的なものでした。 また、割り当てを取り消すことができる必要があります。

考えられるIDアプローチ：コンテナーに非永続的なIPエイリアスを作成し、DNS実装で逆引きDNSルックアップを提供します。

ただし、多くのユースケースでは、IDをポッドコンテナに組み込むことが不可欠ではないと思います。 アプリケーションが自己登録を使用している場合は、おそらくこのメカニズムさえ必要ありません。

サービスマネージャーがそれ以外の状態を維持することをいとわない場合
現在は、以前に作成されたマッピングを思い出すことができます
そしてそれらを尊重しようとします。

20:59の木、2014年10月2日には、bgrant0607 [email protected]は書きました：

考えられるIDアプローチ：で非永続的なIPエイリアスを作成します
コンテナを作成し、DNS実装で逆引きDNSルックアップを提供します。

ただし、ポッドコンテナにIDを配管することは
多くのユースケースに不可欠です。 アプリケーションが使用している場合
自己登録、それはおそらくこのメカニズムさえ必要としません。

このメールに直接返信するか、GitHubで表示してください
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -57749083
。

再。 マッピングを覚えているので、同意します。https： //github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment-57679787を参照して

しかし、それがあなたが返信したコメントにどのように関連しているかはわかりません。

GitHubとメールは混同しません。 ごめん

木曜、午前9時39分PMに2014年10月2日、上bgrant0607 [email protected]は書きました：

再。 マッピングを覚えて、私は同意します-＃260（コメント）を参照してください
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -57679787
。

しかし、それがあなたが返信したコメントにどのように関連しているかはわかりません。

このメールに直接返信するか、GitHubで表示してください
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -57750769
。

ティムは「名目」を提案しましたが、私はこれがより適切であることに同意します。

http://www.mathsisfun.com/definitions/nominal-number.html
http://www.mathsisfun.com/definitions/cardinal-number.html
http://www.mathsisfun.com/definitions/ordinal-number.html

私も名目が好きです。 ユーザーに説明するのは嫌いですが、構成で作成されたものに使用されることがよくあります（つまり、名目上のmongodbレプリカセットはレプリケーションコントローラー、名目上のサービス、ボリュームになるため、すでに多少複雑です）。

- - - オリジナルメッセージ - - -

ティムは「名目」を提案しましたが、私はこれがより適切であることに同意します。

http://www.mathsisfun.com/definitions/nominal-number.html
http://www.mathsisfun.com/definitions/cardinal-number.html
http://www.mathsisfun.com/definitions/ordinal-number.html

---

このメールに直接返信するか、GitHubで表示してください。
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -59438307

私が見る2つの問題：

1. 役割の割り当てには、少なくともポッドごとの環境変数またはボリューム設定の設定が含まれます（つまり、最初のポッドはボリュームaを取得する必要があり、削除された場合、その交換には同じボリュームが必要です）
2. 名目上のサービスのポッドが単一のreplコントローラーからのものである場合、テンプレートは作成後、ポッドがバインドされる前に変更する必要があります。

これは、役割の割り当てが、ワークフローステップとしてapiserverとスケジューラの間にあるコントローラーであることを意味しているようです。 また、役割が割り当てられていないテンプレートが必ずしも意味をなさないように、テンプレートの何らかの形式の変換またはオーバーライドを意味します。

シャードコントローラーは、より複雑な役割の割り当てのためだけに、この問題の変形のように見えます。

インスタンスごとに1つのサービスでzookeeperを実行する例： http ：

だから私はこれが古くからのスレッドであることを知っています、しかしそれは私の近くでそして私の大切なトピックにぶつかります;-)

システムが非NATの「公称サービス」のレコードをskydnsにプッシュし、そのサービスを使用するポッドへのENVインジェクションとして名前を使用できる場合、他の制限はありますか？

クォーラム内のすべての要素が他の要素を使用するZKの場合、少し奇妙に見えるかもしれません。例：
zk1の使用：zk2、zk3
zk2は次を使用します：zk1、zk3
zk3の使用：zk1、zk2

しかし、理論的には正しく機能するはずですか？ 名目上のサービスの逆レコードを追加できる場合。

@ bgrant0607何か足りないのですか？

他のアプリケーションが提供するサービス全体を使用したい場合は、少し奇妙になります。 （https://github.com/GoogleCloudPlatform/kubernetes/issues/1542）

@timothysc提案する内容は、zk1、zk2、およびzk3がサービスである場合、少なくとも一度はマルチポートサービスがサポートされると機能します。

ええ、でもここには醜いものがあります。

実行中のポッドは、どのサービスがポッドの「前」にあるかを知りません。 例：サービスを提供
1つのバックエンドインスタンスの場合、サービスへのアクセスに使用されるVIPは
バックエンド（サービスを知ることによってその情報を求めない限り）
名前）。 名目上のサービス（N）では、N個のバックエンドとN個のVIP（および
おそらくN個のDNS名またはN個のアドレス名）ですが、バックエンドは引き続き
自分のVIPを知らない。 彼らはDNS名のプールを観察するかもしれませんが、
どちらが自分自身であるかを（調査せずに）知りません。 これはあなたのZKになります
VIPを使用するのが難しい場合（現在、VIPも監視可能にプロキシされています）。

代替案：

1）1つのサービス（N）を設定し、各インスタンスにすべてのVIPの自己調査を依頼します

2）N個のservice（1）インスタンスを設定し、ラベルとコマンドラインフラグを使用して
手動でインデックスを割り当て、各ZKバックエンドに（事前に）DNS名を知らせます
お互いのZKバックエンド

3）ラベルセレクターに対してDNSを実行し、DNS名をZKレプリカセットに割り当てます。
クライアントがDNSを正しく使用することを願っています

4）kubernetesエンドポイントを同期する各ZKと一緒にkube2zkブリッジを実行します->
ZK構成

5）より多くのVIPまたはインデックスを割り当てるための代替方法を設計する
replcation-コントローラー中心よりもサービス中心。 ブレンダンと私
しばらく前にここでいくつかのアイデアをブレインストーミングしましたが、フォローする時間がありませんでした
その上に。

逆引きDNSについては、その役割がわかりませんか？ 私は反対していません
それをサポートします（つまり、 @ bketelsenにサポートを依頼します:)しかし、私はそれを考えていません
ここに適用されます。 トラフィックがサービスIPから「送信」されることはありません。

ティム

20:56時土、2015年3月7日には、ブライアン・グラント[email protected]
書きました：

@timothyschttps ：//github.com/timothyscあなたが提案するものは
zk1、zk2、およびzk3はサービスであり、少なくとも1回はマルチポートサービスが
サポートされています。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77733331
。

（5）この提案のように聞こえます。

私は5の大ファンです-自分の役割がステップ1であることを知っているポッド、DNSを識別できる一意のポッド、またはエンドポイントを使用して他のIPを取得し、それに反応するポッドは2つです。 安定したロールIDでエンドポイントのポッドIPを検索できるのは3番目です。

2015年3月8日には、午前11時06分AMで、ティムHockinの[email protected]は書きました：

ええ、でもここには醜いものがあります。

実行中のポッドは、どのサービスがポッドの「前」にあるかを知りません。 例：サービスを提供
1つのバックエンドインスタンスの場合、サービスへのアクセスに使用されるVIPは
バックエンド（サービスを知ることによってその情報を求めない限り）
名前）。 名目上のサービス（N）では、N個のバックエンドとN個のVIP（および
おそらくN個のDNS名またはN個のアドレス名）ですが、バックエンドは引き続き
自分のVIPを知らない。 彼らはDNS名のプールを観察するかもしれませんが、
どちらが自分自身であるかを（調査せずに）知りません。 これはあなたのZKになります
VIPを使用するのが難しい場合（現在、VIPも監視可能にプロキシされています）。

代替案：

1）1つのサービス（N）を設定し、各インスタンスにすべてのVIPの自己調査を依頼します

2）N個のservice（1）インスタンスを設定し、ラベルとコマンドラインフラグを使用して
手動でインデックスを割り当て、各ZKバックエンドに（事前に）DNS名を知らせます
お互いのZKバックエンド

3）ラベルセレクターに対してDNSを実行し、DNS名をZKレプリカセットに割り当てます。
クライアントがDNSを正しく使用することを願っています

4）kubernetesエンドポイントを同期する各ZKと一緒にkube2zkブリッジを実行します->
ZK構成

5）より多くのVIPまたはインデックスを割り当てるための代替方法を設計する
replcation-コントローラー中心よりもサービス中心。 ブレンダンと私
しばらく前にここでいくつかのアイデアをブレインストーミングしましたが、フォローする時間がありませんでした
その上に。

逆引きDNSについては、その役割がわかりませんか？ 私は反対していません
それをサポートします（つまり、 @ bketelsenにサポートを依頼します:)しかし、私はそれを考えていません
ここに適用されます。 トラフィックがサービスIPから「送信」されることはありません。

ティム

20:56時土、2015年3月7日には、ブライアン・グラント[email protected]
書きました：

@timothyschttps ：//github.com/timothyscあなたが提案するものは
zk1、zk2、およびzk3はサービスであり、少なくとも1回はマルチポートサービスが
サポートされています。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77733331
。

—
このメールに直接返信するか、GitHubで表示してください。

それでは、このアイデアをもう少し書くために少し時間を割く必要があります。

10:25の日、2015年3月8日には、クレイトン・コールマン[email protected]
書きました：

私は5の大ファンです-彼らの役割がステップ1であることを知っているポッド、ポッド
一意のDNSを使用して、エンドポイントを識別したり、エンドポイントを使用して他のIPを取得したりする
それに反応するのは2つです。 エンドポイントでポッドIPを検索できるようにする
安定したロールIDは3番目になります。

2015年3月8日には、11：06 AMで、ティムHockin [email protected]
書きました：

ええ、でもここには醜いものがあります。

実行中のポッドは、どのサービスがポッドの「前」にあるかを知りません。 たとえば、
サービス
1つのバックエンドインスタンスの場合、サービスへのアクセスに使用されるVIPは不明です
沿って
バックエンド（サービスを知ることによってその情報を求めない限り）
名前）。 名目上のサービス（N）では、N個のバックエンドとN個のVIPがあります
（と
おそらくN個のDNS名またはN個のアドレス名）ですが、バックエンドは
まだ
自分のVIPを知らない。 彼らはDNS名のプールを観察するかもしれませんが、
どちらが自分自身であるかを（調査せずに）知りません。 これはあなたのZKになります
VIPを使用するのが難しい場合（現在、VIPも監視可能にプロキシされています）。

代替案：

1）1つのサービス（N）を設定し、各インスタンスにすべてのVIPの自己調査を依頼します

2）N個のservice（1）インスタンスを設定し、ラベルとコマンドラインフラグを使用して
手動でインデックスを割り当て、各ZKバックエンドにDNSを（事前に）認識させます
名前
お互いのZKバックエンド

3）ラベルセレクターに対してDNSを実行し、DNS名をZKレプリカセットに割り当てます。
クライアントがDNSを正しく使用することを願っています

4）kubernetesエンドポイントを同期する各ZKと一緒にkube2zkブリッジを実行します
->
ZK構成

5）より多くのVIPまたはインデックスを割り当てるための代替方法を設計する
replcation-コントローラー中心よりもサービス中心。 ブレンダンと私
しばらく前にここでいくつかのアイデアをブレインストーミングしましたが、
従う
その上に。

逆引きDNSについては、その役割がわかりませんか？ 私は反対していません
それをサポートします（つまり、 @ bketelsenにサポートを依頼します:)しかし、私はそれを考えていません
ここに適用されます。 トラフィックがサービスIPから「送信」されることはありません。

ティム

20:56時土、2015年3月7日には、ブライアン・グラント[email protected]
書きました：

@timothyschttps ：//github.com/timothyscあなたが提案したものはうまくいくでしょう
もしも
zk1、zk2、およびzk3はサービスであり、少なくとも1回はマルチポートサービスが
サポートされています。

—
このメールに直接返信するか、GitHubで表示してください
<<
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment-77733331>

。

—
このメールに直接返信するか、GitHubで表示してください。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77762731
。

@thockin re：逆引きDNS、手を振ってそれを要件と考えましょう。

ZKは、他の多くの分散システムと同様に、それなしでは機能しなくなります。

作成する各ポッドに一意のラベル（members =＃）を適用し、最大N個のレプリカのシーケンスを作成しようとするRCと、「member」ラベルの値ごとにAおよびCNAME名を作成するヘッドレスサービス（＃ .service.namespace.local）、ルートはこれらすべてのservice.namespace.local->ラウンドロビン-> 1.service.namespace.local、2.service.namespace.localはローカルのようです。

これらの個々のDNSラベルには厳密なポッドIPを使用できます。 それぞれに偽のIPを作成するとコストがかかり、コンテナは独自のIPを誰かに送信できなくなります。

- - - オリジナルメッセージ - - -

@thockin re：逆引きDNS、手を振って考えてみましょう
要件。

ZKは、他の多くの分散システムと同様に、それなしでは機能しなくなります。

---

このメールに直接返信するか、GitHubで表示してください。
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77883369

@timothysc re：逆引きDNS-逆引きDNSとは何ですか？ ソースIP
接続？ それはどれも久部では機能しません。 サービスを介した接続は
プロキシされるため、source-ipはそもそも機能しません（修正される可能性があります）。

私はZKを知りません-彼らが逆に何を得ようとしているのか説明できますか
DNS？ それは非常に壊れやすい仮定のようです。

2015年3月9日月曜日午前9時5分、ティモシーセントクレア[email protected]
書きました：

@thockin https://github.com/thockin re：逆引きDNS、手を振ってみましょう
私たちの手はそれを要件と考えています。

ZKは、他の多くの分散システムと同様に、それなしでは機能しなくなります。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77883369
。

私の経験（そしておそらくTimの経験）は、今日のクラスター化されたソフトウェアの大部分が次のことを期待していることだと思います。

• 各ノードには安定したIDがあります
• そのIDはDNS名です
• 基盤となるIDのIPは安定している必要はありません
• ノードは、安定したID（DNS）またはパブリックIPのいずれかによって他のノードに対して自身を識別することを期待しています。
• 一部のクラスター化されたソフトウェアは、クライアントが到達するノードのIPが、クラスター内の他のユーザーにアナウンスできるIPと一致し、そのIPが到達可能であることを期待します。

- - - オリジナルメッセージ - - -

@timothysc re：逆引きDNS-逆引きDNSとは何ですか？ ソースIP
接続？ それはどれも久部では機能しません。 サービスを介した接続は
プロキシされるため、source-ipはそもそも機能しません（修正される可能性があります）。

私はZKを知りません-彼らが逆に何を得ようとしているのか説明できますか
DNS？ それは非常に壊れやすい仮定のようです。

2015年3月9日月曜日午前9時5分、ティモシーセントクレア[email protected]
書きました：

@thockin https://github.com/thockin re：逆引きDNS、手を振ってみましょう
私たちの手はそれを要件と考えています。

ZKは、他の多くの分散システムと同様に、それなしでは機能しなくなります。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77883369
。

---

このメールに直接返信するか、GitHubで表示してください。
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78063150

2015年3月9日月曜日12:49 PM、Clayton Coleman
[email protected]は次のように書いています：

作成する各ポッドに一意のラベル（members =＃）を適用し、最大でシーケンスを作成しようとするRC
N個のレプリカ、および「member」の値ごとにA名とCNAME名を作成したヘッドレスサービス
label（＃。service.namespace.local）、ここでルートはそれらすべてのservice.namespace.local-> roundを提供しました
robin-> 1.service.namespace.local、2.service.namespace.localはローカルのようです。

ブレンダンと私が跳ね回っていたという考えは基本的にプールでした
トークンの、おそらくRCの一部、おそらくそうではない、RCの各要素
割り当てられます。 そのトークンが与えられると、他のものを割り当てることができます

• VIP、PD、一般的なインデックスなど。ポッドが
  死ぬと、トークンはプールに戻され、そのポッドが交換されると
  そのトークンは再利用されます。

問題は、「任意のトークン」をどのように変換するかを検討することです。
何か意味のあるもの。

これらの個々のDNSラベルには厳密なポッドIPを使用できます。 それぞれに偽のIPを作成するとコストがかかり、コンテナは独自のIPを誰かに送信できなくなります。

私は試していませんが、名目上のサービスに完全なSNATを実行させることができると思います
およびDNATは1：1であるため。 これは安定する方法です
移行可能なIPのないポッドごとのIP。

- - - オリジナルメッセージ - - -

@thockin re：逆引きDNS、手を振って考えてみましょう
要件。

ZKは、他の多くの分散システムと同様に、それなしでは機能しなくなります。

---

このメールに直接返信するか、GitHubで表示してください。
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77883369

—
このメールに直接返信するか、GitHubで表示してください。

上流に泳ぐのは私から遠く離れています-十分なアプリが本当にDNSを期待している場合
このように機能させると、このように機能させることができます。

スケッチ：

レプリケーションコントローラーRを作成すると、DNS名「$ R.rc」が作成されます。
そのRCの「下」にあるポッドIPのプール。 各ポッドPはDNS名を取得します
「$ P。$ R.rc」。 でもPってなに？ 単純なインデックスかもしれませんが、
社内で激しく噛んだ。 GenerateNameのようなランダムな文字列である可能性があります。
ただし、ポッドの停止/再起動後も存続する必要があります（おそらく、ポッドのホスト名は
マッチ？）。

7:59の火、2015年3月10日には、クレイトン・コールマン[email protected]
書きました：

私の経験（そしておそらくティムの経験）は、クラスター化されたものの大部分が
今日のソフトウェアは次のことを期待しています。

• 各ノードには安定したIDがあります
• そのIDはDNS名です
• 基盤となるIDのIPは安定している必要はありません
• ノードは、安定したノードのいずれかによって、他のノードに対して自身を識別することを期待しています。
  ID（DNS）またはそのパブリックIP
• 一部のクラスター化されたソフトウェアは、クライアントのノードのIPを想定しています
  IPに一致するように到達すると、他の人に自分自身をアナウンスできます。
  クラスターとそのIPに到達可能にするため。

- - - オリジナルメッセージ - - -

@timothysc re：逆引きDNS-逆引きDNSとは何ですか？ ソースIP
接続？ それはどれも久部では機能しません。 サービスを介した接続は
プロキシされるため、source-ipはそもそも機能しません（修正される可能性があります）。

私はZKを知りません-彼らが逆に何を得ようとしているのか説明できますか
DNS？ それは非常に壊れやすい仮定のようです。

2015年3月9日月曜日午前9時5分、ティモシーセントクレア<
[email protected]>
書きました：

@thockin https://github.com/thockin re：逆引きDNS、手を振ってみましょう
私たちの手はそれを要件と考えています。

ZKは、他の多くの分散システムと同様に、それなしでは機能しなくなります。

—
このメールに直接返信するか、GitHubで表示してください
<<
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77883369

。

---

このメールに直接返信するか、GitHubで表示してください。

https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78063150

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78071406
。

私はDNSがRCではなく名目上のサービスに接続されているようなものです。

内部的に単純なインデックスの問題点は何でしたか？ P> 5000？

- - - オリジナルメッセージ - - -

上流に泳ぐのは私から遠く離れています-十分なアプリが本当にDNSを期待している場合
このように機能させると、このように機能させることができます。

スケッチ：

レプリケーションコントローラーRを作成すると、DNS名「$ R.rc」が作成されます。
そのRCの「下」にあるポッドIPのプール。 各ポッドPはDNS名を取得します
「$ P。$ R.rc」。 でもPってなに？ 単純なインデックスかもしれませんが、
社内で激しく噛んだ。 GenerateNameのようなランダムな文字列である可能性があります。
ただし、ポッドの停止/再起動後も存続する必要があります（おそらく、ポッドのホスト名は
マッチ？）。

7:59の火、2015年3月10日には、クレイトン・コールマン[email protected]
書きました：

私の経験（そしておそらくティムの経験）は、クラスター化されたものの大部分が
今日のソフトウェアは次のことを期待しています。

• 各ノードには安定したIDがあります
• そのIDはDNS名です
• 基盤となるIDのIPは安定している必要はありません
• ノードは、安定したノードのいずれかによって、他のノードに対して自身を識別することを期待しています。
  ID（DNS）またはそのパブリックIP
• 一部のクラスター化されたソフトウェアは、クライアントのノードのIPを想定しています
  IPに一致するように到達すると、他の人に自分自身をアナウンスできます。
  クラスターとそのIPに到達可能にするため。

- - - オリジナルメッセージ - - -

@timothysc re：逆引きDNS-逆引きDNSとは何ですか？ ソースIP
接続？ それはどれも久部では機能しません。 サービスを介した接続は
プロキシされるため、source-ipはそもそも機能しません（修正される可能性があります）。

私はZKを知りません-彼らが逆に何を得ようとしているのか説明できますか
DNS？ それは非常に壊れやすい仮定のようです。

2015年3月9日月曜日午前9時5分、ティモシーセントクレア<
[email protected]>
書きました：

@thockin https://github.com/thockin re：逆引きDNS、手を振ってみましょう
私たちの手はそれを要件と考えています。

ZKは、他の多くの分散システムと同様に、それなしでは機能しなくなります。

—
このメールに直接返信するか、GitHubで表示してください
<<
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77883369

。

---

このメールに直接返信するか、GitHubで表示してください。

https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78063150

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78071406
。

---

このメールに直接返信するか、GitHubで表示してください。
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78080138

特別なケーシングの1：1VIPに+1。 それはよくあることだと思います。

DNSマッピングを動的に変更することについてはまだ心配です。 私はそれを必要としないアプローチを好みます。

代替案を評価する際に留意すべき点は、古いものと新しいものを同時に共存させるには、最終的に同じ役割を持つ2つのポッドが必要になると100％確信しているということです。 したがって、この役割は、オブジェクト名や、ポッドの作成時に一意であり、石に設定されている必要がある他の何かに関連付けることはできません。

ロール割り当てメカニズムをレプリケーションコントローラーに結び付けると、ローリングアップデートやカナリアなどがほぼ除外されます。可能であれば、それを避けたいと思います。

@smarterclayton単純なインデックスは、規模が原因で問題にはなりません。 モデルによるものです。 数分前の私のコメントをご覧ください。 ポッドやRCのIDに関係なく動的に割り当てることができる場合は、単純なインデックスが最適です。

問題の1つがシステム指向の仮定であるとすると、Linuxがここで私たちのためにできることはありますか？ たとえば、サービスVIPのコンテナにIPエイリアスなどを作成できますか？

やあみんな、

私は今週ずっと外出しています。 これは本当に楽しい会話ですが、それは必要です
手元にあるよりも多くの時間。 座って実際に話し合って幸せです
来週の時間。

3時56分PMの火、2015年3月10日には、ブライアン・グラント[email protected]
書きました：

問題の1つがシステム指向の仮定であることを考えると、そこにあります
Linuxがここで私たちのために何かできることはありますか？ たとえば、IPを作成できますか
サービスVIPのコンテナ内のエイリアスなど？

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78166544
。

私は次の2日間ポケットから出ています-来週はそうです。

2015年3月10日には、11：33 PMで、ティムHockinの[email protected]は書きました：

やあみんな、

私は今週ずっと外出しています。 これは本当に楽しい会話ですが、それは必要です
手元にあるよりも多くの時間。 座って実際に話し合って幸せです
来週の時間。

3時56分PMの火、2015年3月10日には、ブライアン・グラント[email protected]
書きました：

問題の1つがシステム指向の仮定であることを考えると、そこにあります
Linuxがここで私たちのために何かできることはありますか？ たとえば、IPを作成できますか
サービスVIPのコンテナ内のエイリアスなど？

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78166544
。

—
このメールに直接返信するか、GitHubで表示してください。

来週は+1、おそらくたまり場。

関連するトピックがポップアップするため、このスレッドを再度突く（https://github.com/GoogleCloudPlatform/kubernetes/issues/4825#issuecomment-76193417、https://github.com/GoogleCloudPlatform/kubernetes/issues/175#issuecomment-84423902 、https：//github.com/GoogleCloudPlatform/kubernetes/issues/1607#issuecomment-88177147、＃6393）。

1. ネットワークID（DNS名やIPアドレス）を個々のポッドに割り当てるにはどうすればよいですか？シングルトンまたは公称セットの一部である可能性がありますか？
2. ポッド内のコンテナにIDをどのように伝えますか？

ハングアウトをスケジュールする必要がありますか、それとも毎週のコミュニティハングアウトを使用する必要がありますか？

また、 https：//github.com/openshift/mongodb/pull/14は、メンバーシップセットの初期化の一般的なパターンのプロトタイプを作成し始めています（コンテナー、ライブラリー、または...）

@danmcp @mfojtik

- - - オリジナルメッセージ - - -

関連するトピックがポップアップするため、このスレッドをもう一度突く
（ https://github.com/GoogleCloudPlatform/kubernetes/issues/4825#issuecomment -76193417、
https://github.com/GoogleCloudPlatform/kubernetes/issues/175#issuecomment -84423902、
https://github.com/GoogleCloudPlatform/kubernetes/issues/1607#issuecomment -88177147、

6393）。

1. ネットワークID（DNS名やIPアドレス）をに割り当てるにはどうすればよいですか？
   シングルトンまたは名目上のセットの一部である可能性がある個々のポッド？
2. ポッド内のコンテナにIDをどのように伝えますか？

ハングアウトをスケジュールする必要がありますか、それとも毎週のコミュニティハングアウトを使用する必要がありますか？

---

このメールに直接返信するか、GitHubで表示してください。
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -91041442

IIUC、そのパズルの1つは、マスター選挙＃1542です。

ええ、私たちはそれについて話し合いました。 独自の選択メンバーシップを実行できるほとんどのクラスターにとって最も重要です（Kubeエンドポイントからメンバーシップを検出し、クラスターに適用します）が、それにアプローチする方法は常に異なります。 たとえば、カサンドラは基本的にメンバーシップの外部の真実の源として久部を使用しているので、それはSEPであり、それはリーダーシップの選挙を容易にします。 メンバーの遅れによっては、メンバーシップがフラップした場合にパーティションが作成される可能性があると思います。

mongoの場合、各メンバーに連絡して、既存のクラスターに参加させるか、新しいクラスターを形成する必要があります。 複数のクラスターが存在する場合、それらを悪化させたくはありません。

サービスIPをコンテナに通信する問題は、外部IPをVMに通信するのと同様であることに注意してください： //cloud.google.com/compute/docs/networking。 GCEは外部アドレスを内部アドレスとの間で変換し、外部アドレスはメタデータサーバーhttp://169.254.169.254/computeMetadata/v1/instance/network-interfaces/0/access-configs/0/external-ip介して通信されます。 AWSも同様です： http://169.254.169.254/latest/meta-data/public-ipv4 。

@smarterclayton mongoプロトタイプPRを更新しました： https ：

現在、replicaSetを初期化するワンショットポッドを使用しています

再。 このメカニズムをレプリケーション/シャードコントローラーに結び付ける：

DNS名をレプリケーションコントローラーやポッドオブジェクト名に試行すると、インプレース更新モデルが強制されます。 まったく異なる種類の「インプレース」ローリングアップデートを実装する必要がありますが、1つのコントローラーで同時に複数のテンプレートをサポートする必要があります。 また、ある種の更新（新しいホストへの移動を含む）を実行するには、ポッドを削除してから同じ名前で再作成する必要があることも意味します。これにより、新しいホストを追加するアプローチと比較して、ダウンタイムが増加します。古いものを取り除く前にポッド。

トークンプールのアイデアは素晴らしいですね。 RCから切り離す必要があると思います。

これを追加する場合は、これを上位レベルのコントローラーに結合できます。 ＃1743および/または＃503についてさらにコメントします。

これは、＃1743で提案されているDeploymentControllerと実際に結合するべきではありません。 複数の独立したリリーストラックのシナリオや、提案された名前交換ローリングアップデートなど、別のメカニズムでロールアウトを制御したい場合には機能しません。 同様の理由で、DNS名をpod / RC / DCオブジェクト名に関連付けません。

これで、ある種のサービス、または完全に独立したコントローラーに戻ります。 おそらく、エンドポイントコントローラーはサービスエンドポイントにインデックスを割り当てることができますか？ エンドポイント自体は、このデータを記録するのに十分な信頼性のある場所ですか？ 失われた場合、すべてのポッドのインデックスが再作成されます。

ポッド内のコンテナーまでのIDの通信を容易にするために（＃2316で説明されているenv。var。substitutionを介してなど）、サブリソースを介して、役割が割り当て/割り当て解除されたときにポッドにフィールドを設定すると便利です。 これにより、耐久性の問題にも対処できます。

名目上のインスタンス用にDNSスキーマのスペースを予約する必要があります-＃6666。

https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78071406に従って、ポッドIPを使用し、公称インスタンスのDNSを再マッピングすることを試みることができることを購入できました。

また、これを2月の1.0マイルストーンから削除しました（ただし、roadmap.mdではありません）が、＃6393の説明では、追加し直す可能性があることを示しています。

@thockinによる
http://en.wikipedia.org/wiki/Reverse_DNS_lookup

ええ、標準の名前ツールを使用すると、「私は誰ですか」が本当に簡単になります。

2015年4月10日には、午前8時11分PMで、ブライアン・グラントの[email protected]は書きました：

@thockinによる
http://en.wikipedia.org/wiki/Reverse_DNS_lookup

—
このメールに直接返信するか、GitHubで表示してください。

/購読

ここでの要件を理解できているかどうかはわかりません。

サービスとポッドの間には、固有のN対Mの関係があります。
システムの設計。 逆引きDNSのようなものは、一般的に
単一の応答：ポッドのIPを指定して、正規名を取得します。 書かれたすべてのドキュメント
DNSについては「複数のリバースレコードを返さないでください」と言っています。 ポッドは
Nサービスでは、この単一の応答は実際にはサービスに関連することはできません。 我々
正規名への逆ルックアップを実行してから、その名前でTXTルックアップを実行できます。
「あなたが受けているサービス」の名前ですが、それを維持するのは難しく、
とにかく本質的にカスタムプロトコル。

私がRCに名目上の何かを付けることを考えた理由はそれが
より具体的な関係。 しかし、それは均等ではありません。 ポッドは次の方法で作成できます
1つのRCが孤立し、別のRCに採用され、それによって破壊されました。 または
手動で破壊

ですから、数を制限する以外に、これで何をしたいのかわかりません
サービスのポッドは「下」にある可能性があり、それはひどい音に聞こえます。

行動要件は何ですか？ 私たちは何を達成しようとしています。 我々
DNSおよびヘッドレスサービスで単純なセットセマンティクスを提供できます。 それですか
十分な？ そうでない場合、なぜですか？

極端に進んで、SNAT / DNATポッドにiptablesルールを設定することができます
彼ら全員がVIPでお互いを見るようにサービス。 たとえば、ポッドのセットが与えられます
（P1、P2、P3）彼らはVIP（V1、V2、V3）を取得します。 P1からV2へのトラフィックは
V1などから来ているように見えます。クライアントはV {1,2,3}にアクセスします。 しかし、何
問題は本当に解決しますか？ 安定したIPを提供しますが、これは
ヘッドレスサービス全体の一般的な問題？

2015年4月21日火曜日午後2時17分、David Oppenheimer < [email protected]

書きました：

/購読

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -94945744
。

目標は非常に具体的でした。 実際のクラスター化されたシステムには、ノード障害が発生した場合でも継続することが期待される「ID」を持つメンバーがあります。 そのIDは永続ディスクまたは「名前」に付加されている可能性がありますが、他のシステムのIDの名前は変更できません。

たとえば、飼育係はノードごとのIDを持っています。 そのIDは、クラスターメンバーシップで安定している必要があります。2つのポッドがhost1であると見なす可能性がありますが、host1がなくなると、host435で置き換えることはできません。 ある場所から別の場所に移動するそのポッド用に再利用された永続ディスクがある場合がありますが、移動する場合、ポッドはそのIDを定義できる必要があります。 しかし、その＃を割り当てる方法が必要です。

私が名目上のサービスについて考える方法は、完全に柔軟な数百のユースケースではなく、常に小さな（3/5/7）メンバーシップで既存のソフトウェアを有効にすることだと思います。 おそらく、そのユースケースをこの議論から分割する必要があります。

2015年4月22日には、午前1時59 AMで、ティムHockinの[email protected]は書きました：

ここでの要件を理解できているかどうかはわかりません。

サービスとポッドの間には、固有のN対Mの関係があります。
システムの設計。 逆引きDNSのようなものは、一般的に
単一の応答：ポッドのIPを指定して、正規名を取得します。 書かれたすべてのドキュメント
DNSについては「複数のリバースレコードを返さないでください」と言っています。 ポッドは
Nサービスでは、この単一の応答は実際にはサービスに関連することはできません。 我々
正規名への逆ルックアップを実行してから、その名前でTXTルックアップを実行できます。
「あなたが受けているサービス」の名前ですが、それを維持するのは難しく、
とにかく本質的にカスタムプロトコル。

私がRCに名目上の何かを付けることを考えた理由はそれが
より具体的な関係。 しかし、それは均等ではありません。 ポッドは次の方法で作成できます
1つのRCが孤立し、別のRCに採用され、それによって破壊されました。 または
手動で破壊

ですから、数を制限する以外に、これで何をしたいのかわかりません
サービスのポッドは「下」にある可能性があり、それはひどい音に聞こえます。

行動要件は何ですか？ 私たちは何を達成しようとしています。 我々
DNSおよびヘッドレスサービスで単純なセットセマンティクスを提供できます。 それですか
十分な？ そうでない場合、なぜですか？

極端に進んで、SNAT / DNATポッドにiptablesルールを設定することができます
彼ら全員がVIPでお互いを見るようにサービス。 たとえば、ポッドのセットが与えられます
（P1、P2、P3）彼らはVIP（V1、V2、V3）を取得します。 P1からV2へのトラフィックは
V1などから来ているように見えます。クライアントはV {1,2,3}にアクセスします。 しかし、何
問題は本当に解決しますか？ 安定したIPを提供しますが、これは
ヘッドレスサービス全体の一般的な問題？

2015年4月21日火曜日午後2時17分、David Oppenheimer < [email protected]

書きました：

/購読

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -94945744
。

—
このメールに直接返信するか、GitHubで表示してください。

ある種のコントローラは、ポッドの一部のフィールドを動的に設定/設定解除できます。 ポッドやRCIDと混同することはできません。 ネットワークIDをポッドまたはRCIDに結び付けることは完全に壊れています。

通常のサービスやヘッドレスサービスで逆引きDNSルックアップを機能させようとはしません。また、ポッドごとに最大1つの公称サービスを課すのは不合理ではないと思います。他の種類のサービスを制限する必要はまったくありません。 。

長期的にはプッシュしたいDNSの制限がいくつかあります（キャッシュの無効化、長いポーリングのサポートなど）。 複数のPTRレコードは、おそらくそのリストに追加された単なる別の項目です。

もう1つの方法は、名目上のサービスの各ポッドにサービスIPを割り当てて、発生する問題を解決できることです。

- - - オリジナルメッセージ - - -

ある種のコントローラは、ポッドの一部のフィールドを動的に設定/設定解除できます。 これ
ポッドやRCIDと混同することはできません。 ネットワークIDを結び付ける
ポッドまたはRCIDへの接続は完全に壊れています。

通常またはヘッドレスで逆引きDNSルックアップを機能させようとはしません
サービス、および私はそれが名目上の最大1つを課すことは不合理ではないと思います
ポッドごとのサービス-他のタイプのサービスを制限する必要はありません
全て。

長期的にはプッシュしたいDNSの制限がいくつかあります
（キャッシュの無効化、長いポーリングのサポートなど）。 複数のPTRレコード
おそらく、そのリストに追加された別のアイテムです。

もう1つの方法は、サービスIPを各ポッドに提供できることです。
名目上のサービスを提供し、発生する問題を解決します。

これらのサービスの多くは、所有しているIP（名前）が接続先のIPに解決されることを期待しています。したがって、172.1.1.1でXに接続すると、Xは172.1.1.1と見なします。 それはすべてのソフトウェアではありませんが、一部のソフトウェアです。 通常はDNS名ですが、これはIPがその下で変更される可能性があることを意味します。

---

このメールに直接返信するか、GitHubで表示してください。
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -95266421

これは私にとってまだ少し抽象的なものだと思います。

実際のクラスター化されたシステムには、「アイデンティティ」を持つメンバーがあります。
ノード障害が発生した場合でも継続することが期待されます。 そのアイデンティティ
永続ディスクまたは「名前」に接続されている可能性がありますが、名前は
他のシステムに識別して変更することはできません。

これは必須ではありません。 非常に曖昧なので、実装できません。

たとえば、飼育係はノードごとのIDを持っています。 そのアイデンティティは残っている必要があります
クラスタメンバーシップで安定

アイデンティティとは何ですか？ IPアドレス？ ソフトウェアに渡される文字列フラグ？
およびenvvar？ zkプロセスはどのようにして自身のアイデンティティが何であるかを学習しますか？

ある種のコントローラは、ポッドの一部のフィールドを動的に設定/設定解除できます

これにより、これらのポッドが再起動しますが、それでも応答しません
どのフィールド、どの値、およびポッドに伝えるロジックについての質問ですか？

アノテーションをコマンドラインフラグに展開するようなものを見ることができました
（env varsと話し合っているように）またはenvvarsだけに。 例えば
コントローラは注釈を書き込みます["zookeeper.com/index"]= 9、変換します
$ .metatdata ["zookeeper.com/index"]をZK_INDEX環境に追加します。 しかし、私はこれを作っています
上に、私は正確に飼育係（または
何でも）必要。

最大1つの名目上のサービスを課すことは不合理ではないと思います
ポッドごと

そのような制限を実施するのは難しいと思います。 システムはそうです
これらの制限を課すことはより悪いかもしれないという緩く結合された非同期
問題を解決するだけです。

名目上のサービスの各ポッドにサービスIPを与えることができます

これが私たちが始めたところですが...

これらのサービスの多くは、それらが持っているIP（それらの名前）を期待しています
接続するIPに解決されます-したがって、172.1.1.1でXに接続する場合、
次に、Xは172.1.1を考えます。

サービスIPは、次のようなより詳細な処理を行わない限り、これを満たしません。
SNAT / DNATで言及しました。 そしてそれでも本当の欠点があります。

私は首の痛みになろうとはしていません、それは私たちがほとんど持っていないということだけです
1.0までの準備期間であり、ここには十分に明確なものはありません。
概念実証でさえ、適切に実装することははるかに少ないです。

私は私たちが体験したいことを正確に特定しようとしているので、私は見ることができます
実装できるもの。 DNSへの繰り返しの参照を考えると、私は保持しています
ここで何が起こっているのかがわかるまで、DNSのやり直しをオフにします。

午前10時12分AMで水曜日、2015年4月22日には、クレイトン・コールマン[email protected]
書きました：

- - - オリジナルメッセージ - - -

ある種のコントローラーは、いくつかのフィールドを動的に設定/設定解除できます
ポッド。 これ
ポッドやRCIDと混同することはできません。 ネットワークを結ぶ
身元
ポッドまたはRCIDへの接続は完全に壊れています。

通常またはヘッドレスで逆引きDNSルックアップを機能させようとはしません
サービス、そして私は最大1つを課すことは不合理ではないと思います
名目
ポッドごとのサービス-他のタイプのサービスを制限する必要はありません
全て。

長い間プッシュしたいDNSの制限がいくつかあります
走る
（キャッシュの無効化、長いポーリングのサポートなど）。 複数のPTR
記録
おそらく、そのリストに追加された別のアイテムです。

もう1つの方法は、サービスIPを各ポッドに提供できることです。
名目上のサービスを提供し、発生する問題を解決します。

これらのサービスの多くは、所有しているIP（名前）が解決されることを期待しています。
それらが接続するIPに-したがって、172.1.1.1でXに接続する場合、X
その172.1.1.1を考えています。 それはすべてのソフトウェアではありませんが、一部のソフトウェアです。 通常は
ただし、DNS名は、IPがその下で変更される可能性があることを意味します。

---

このメールに直接返信するか、GitHubで表示してください。

https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -95266421

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -95267902
。

マルチポートの例のほとんどは、クラスター化されたシステムです。 例えば：
ZK ：構成ファイル内の解決可能なホスト名またはIPアドレス、およびファイル内の「id」（つまり、インデックス：1、2、3、...）

また、いくつかのDBを調べる必要があります。

私たちが何をしても、すべてがうまくいくわけではありません。 スイートスポットを見つける必要があります。

- - - オリジナルメッセージ - - -

これは私にとってまだ少し抽象的なものだと思います。

実際のクラスター化されたシステムには、「アイデンティティ」を持つメンバーがあります。
ノード障害が発生した場合でも継続することが期待されます。 そのアイデンティティ
永続ディスクまたは「名前」に接続されている可能性がありますが、名前は
他のシステムに識別して変更することはできません。

これは必須ではありません。 非常に曖昧なので、実装できません。

たとえば、飼育係はノードごとのIDを持っています。 そのアイデンティティは残っている必要があります
クラスタメンバーシップで安定

アイデンティティとは何ですか？ IPアドレス？ ソフトウェアに渡される文字列フラグ？
およびenvvar？ zkプロセスはどのようにして自身のアイデンティティが何であるかを学習しますか？

ある種のコントローラは、ポッドの一部のフィールドを動的に設定/設定解除できます

これにより、これらのポッドが再起動しますが、それでも応答しません
どのフィールド、どの値、およびポッドに伝えるロジックについての質問ですか？

アノテーションをコマンドラインフラグに展開するようなものを見ることができました
（env varsと話し合っているように）またはenvvarsだけに。 例えば
コントローラは注釈を書き込みます["zookeeper.com/index"]= 9、変換します
$ .metatdata ["zookeeper.com/index"]をZK_INDEX環境に追加します。 しかし、私はこれを作っています
上に、私は正確に飼育係（または
何でも）必要。

最大1つの名目上のサービスを課すことは不合理ではないと思います
ポッドごと

そのような制限を実施するのは難しいと思います。 システムはそうです
これらの制限を課すことはより悪いかもしれないという緩く結合された非同期
問題を解決するだけです。

名目上のサービスの各ポッドにサービスIPを与えることができます

これが私たちが始めたところですが...

これらのサービスの多くは、それらが持っているIP（それらの名前）を期待しています
接続するIPに解決されます-したがって、172.1.1.1でXに接続する場合、
次に、Xは172.1.1を考えます。

サービスIPは、次のようなより詳細な処理を行わない限り、これを満たしません。
SNAT / DNATで言及しました。 そしてそれでも本当の欠点があります。

私は首の痛みになろうとはしていません、それは私たちがほとんど持っていないということだけです
1.0までの準備期間であり、ここには十分に明確なものはありません。
概念実証でさえ、適切に実装することははるかに少ないです。

私は私たちが体験したいことを正確に特定しようとしているので、私は見ることができます
実装できるもの。 DNSへの繰り返しの参照を考えると、私は保持しています
ここで何が起こっているのかがわかるまで、DNSのやり直しをオフにします。

それは賢明だと思います。私たちは、既知の例のセットを解決するために特に時間を割く必要があります。 具体的な例（MongoDBレプリカセット、Zookeeper、Mysqlマスター/スレーブ）と、kube / examplesの既存の例に活用できる3つの方法があります。 おそらく、アイテムをハッシュ化し、解決できない問題に限界を設定し、残っているものを特定するための作業セッションです。

シャードID番号を割り当てるバッチジョブにも使用できるため、この機能の名前を変更することをお勧めします。

バッチジョブの要件は多少異なるので、それを分けておきたいと思います。

zookeeperの例： https ：

名目上のサービスishのニーズの例https://github.com/GoogleCloudPlatform/kubernetes/blob/master/examples/rethinkdb/image/run.sh#L26

なぜここで方向性がまだはっきりしていないのか、特にGoogle社員からは少し混乱しています。 Googleは長年Borgの下でステートフルサービスを実行しており、このタイプのワークロードに何が必要かは非常に明確です。

• 現在のポッドが表す「シャード」（同一ではないレプリカ）のセットの1つである安定した識別子（ボーグでは、これは「タスク番号」-単純な整数です）。 この識別子は、ポッドの再スケジュール/再起動全体で一定である必要があります。
• おそらく何らかの方法で安定した識別子を使用して、すべての「ピア」シャードを列挙して連絡する方法（borgでは、これはタスク番号とともにぽっちゃりしたプレフィックスです）

..これで完了です。

注：リソースの除外が各シャードにとって重要である場合、障害/再起動中にポッドの有効期間が重複する可能性が常にあるため、アプリケーションは独自の分散ロックを実行する必要があります（おそらくシャード識別子に基づくetcdロックを使用します）。 潜在的なエキゾチックな機能拡張は、冗長性/負荷のために、各シャード内に複数の同一のレプリカを許可することです。

これは、シャードごとに一意のサービス/ポートを作成し、レプリカでレプリケーションコントローラーを実行することで今すぐ偽造でき

これをkubernetesに実装する自然な方法は次のとおりです。

• ポッドは、独自のシャードインデックス（整数）とシャードの総数を提供する追加の環境変数を取得します（または、下位APIを介して通信しますか？）。
• ReplicationControllersは「シャード」カウント（デフォルト：1）を取得し、「レプリカ」は「各シャード内のレプリカ」（デフォルト：1）を意味するように再解釈されます。 レプリカのセットを縮小するときは、（シャードインデックスを連続させるために）最後から強制終了する必要があります。 「シャード」を変更するには、制御されたポッドをローリングリスタートして「合計シャード」環境変数を更新する必要があることに注意してください（すぐに発生することは望ましくありません）。
• サービスは、連続する範囲のポートを通常のセレクターと暗黙の「シャードインデックス」セレクターにマップする同様の「シャード」カウントを取得します。
• ポッドは、SERVICE_PORT（またはいくつかの新しいenv var？）+シャードインデックスオフセットを使用して、他のシャードを見つけることができます。

shards = 1の場合、上記は現在の動作に正常に低下することに注意してください。

私は一般的にこれに同意します（そしてあなたが言うように、それはボーグでの時間のテストに役立ちました）が、シャードごとに複数のレプリカの「エキゾチックな機能拡張」を使用することはお勧めしません（おそらく、移行のカバー）。

先に述べたように、これは静的な作業割り当てを使用してバッチジョブをサポートするために必要なことと密接に関連しています（ここでは「タイプ1」と呼んでいます：https：//github.com/GoogleCloudPlatform/kubernetes/issues/1624#issuecomment -97622142）

RCを変更した（または何か新しいものを追加した）場合に調整する必要がある他の機能は、展開がどのように適合するか、具体的には次のとおりです。

次のローリングアップデートを行うにはどうすればよいですか。

1. 通常のRC
2. PerNodeController
3. シャーディングされたRC
4. バッチジョブ？

単純なRCに対してのみ機能するデプロイメントにはいくつかの問題があると思うので、それぞれにストローマンができるまでデプロイメントの実装を保留することをお勧めします。

- - - オリジナルメッセージ - - -

私は一般的にこれに同意します（そしてあなたが言うように、それは時の試練に役立ちました
ボーグで）、「エキゾチックな機能を使用しないことをお勧めしますが
シャードごとの複数のレプリカの拡張」（おそらく何かが必要ですが
移行の裏でそのように）。

先に述べたように、これは私たちがしなければならないことと密接に関連しています
静的な作業割り当て（私が「タイプ1」と呼んでいたもの）を使用したバッチジョブをサポートする
ここ：
https://github.com/GoogleCloudPlatform/kubernetes/issues/1624#issuecomment-97622142
）。

---

このメールに直接返信するか、GitHubで表示してください。
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -101918080

インスタンスごとに1つのサービス、RC、永続ボリュームクレームを作成するなど、複数の回避策があるため、1.0ではこれ（および自動生成された永続ボリュームクレーム）を優先しないことを選択しました。

ボーグで静的に割り当てられたタスクインデックスは非常に広く使用されていますが、いくつかの欠点があることを学び、過去数年にわたって代替案の開発に時間を費やしてきました。 問題の多くは、インデックスがタスク自体のライフサイクルとアイデンティティに関連しているという事実から生じています。 これにより、多くの展開戦略、移行、動的タスク管理、およびその他の多くのシナリオを実装することが困難になります。 その他の複雑さは、展開前のタスクごとにインデックスごとの構成を静的に生成することに起因します。これは、インデックス値ごとに1つのRCを生成することと同じです。 彼らが本当にしたいのであれば、それは誰かがするのは簡単でしょう。 ラベルは、セット全体を破棄するために引き続き使用できます。

ノード/デーモンコントローラーごと：良い点。 密に割り当てられたインデックスは、その場合の悪いモデルです。 たとえば、ノードが完全になくなるとどうしますか？ インデックスはまばらになります。 サポートしないことをお勧めします。

バッチジョブ：＃1624で説明したように、現在実行中のポッドではなく、完了に基づいてインデックスを割り当てたいと思います。

上で説明したように、インデックスの割り当てでは、永続的なボリュームクレームなどの関連するストレージを考慮する必要があります。IDはネットワークID（DNS名やIPアドレス）とストレージに由来します。

割り当ては、単一のレプリケーションコントローラーで駆動することはできません。 これは単に機能しません。 レプリケーションコントローラーは永続的なエンティティではなく、カナリア、ローリングアップデート、複数のリリーストラック、複数のクラスターなど、サービスごとに複数のRCが存在すると予想されます。提案されたDeploymentオブジェクト（＃1743）でさえ適切なスコープを持っていません。

割り当てには3つの選択肢があります。

1. 割り当てを特別な種類のサービスに関連付けます。 サービスには正確に適切な範囲があります。 （最終的には地域サービスも必要になります。）これは、通常のサービスとヘッドレスサービスのハイブリッドのようなものです。 それは私が最初にこのメカニズムを提案したときに私が想像したものです。 割り当てはエンドポイントに記録されます。 エンドポイントやヘッドレスのようなDNSは、すべてのピアを列挙するための明白な方法です。
2. Serviceに似ていますが、名目上のサービス専用の新しいタイプのオブジェクトを作成します。 また、割り当てを記録するために新しいオブジェクトが必要になる可能性があります。 これにより、APIサーフェス、IMOが不必要に拡張されます。
3. 「プッシュ」ではなく「プル」。 ポッドは、ノードの制約（セレクター）または提案されている非アフィニティメカニズムの1つ（https://github.com/GoogleCloudPlatform/kubernetes/issues/4301#issuecomment-74355529）がある場合でも、明示的なコントローラーなしでホストにスケジュールされます。 これもサービスVIPの割り当てに似ています。 名目上のサービスについても同様のことができます。 ポッド（またはポッドテンプレート）は、インデックスの割り当て元のインデックスプールを指定します。 一般的なサービスとは異なり、ポッドに異なるプールから複数のインデックスを割り当てる必要はありません。 割り当てはポッド仕様に記録されます。
4. 長所：ユーザーにとってよりシンプルです。 別のオブジェクトは必要ありません。 ユーザーによる割り当てを許可します。
5. 短所：他の種類のサービスとは異なります。

PVCの割り当てでは、理想的には同じモデルを使用します。

ポッド移行＃3949がどのように調整されるかを検討することも価値があります。 コンテナの状態を転送するには、交換するポッドを削除する前に、交換用ポッドを作成する必要があります。 これにより、プルモデルが少し問題になる可能性があります。 とにかく、割り当てメカニズムは移行を意識する必要があります。

その他の考慮事項：

1. インデックス/ IDをピアに伝達する方法。 DNSは明白な答えです。
2. インデックス/ IDをポッド内のコンテナに伝達する方法。 環境変数、逆引きDNS、...割り当てられたインデックスは動的に変更されませんが、ポッドがまだ存在している間にDNSバインディングが変更される可能性があります。 アプリケーションが他の環境で動作することをすでに期待しているメカニズムを選択したいと思います。より広範なAPIの議論（＃386）と同様に、アプリケーションをKubernetes固有の環境変数に結合したくはありませんが、新しいEnvVarSource env var置換（＃7936）はそれを回避するのに役立ちます。

私はあなたが言ったことのいくつかに同意しませんが、1.0以降までこの議論を続けるのを待ちましょう。

この古いスレッドを復活させて質問をします。 レプリケーションコントローラーの命名ポリシーに関心はありますか？ 具体的には、上記のように名目上の名前を付けます。このレプリケーションコントローラによって制御されるすべてのポッドには、0001、0002などの番号付きのサフィックスが付いています。

ユースケースの例は、ドメイン名でこれらのポッドのセットを指すnginxロードバランサーです。 したがって、ポッドが出入りするときに、ドメイン名は常にxxx-0001からxxx-000Nに固定されることが期待されます。

@ravigaddeこの問題に関する私の最後のコメントを読んでください： https ：

RabbitMQコンテナをセットアップしようとしているときに、この問題が発生しました。 Rabbitの永続性はホスト名に依存するため、ホスト名が可変であるということは、コンテナーの再起動時にMnesiaデータベースが失われることを意味します。

image config（ホスト名とRabbit）、ENV変数、およびDownwardAPIを使用して修正しようとしました。 問題を解決するために何も取得できませんでした-Rabbitは生成されたポッド名を引き続き取得します。 @mikedaneseの提案に従って、レプリケーションコントローラーの使用から一時的に解決します。

私が正しく理解していれば、 celerey-rabbitの例のrabbitmqポッド（レプリケーションコントローラーで作成）は、データが永続ディスクに保存されている場合でも、ポッドの障害に関するデータを失います。 rabbitmq docから：

RabbitMQは、システムの現在のホスト名を使用してデータベースディレクトリに名前を付けます。 ホスト名が変更されると、新しい空のデータベースが作成されます。 データの損失を回避するには、固定された解決可能なホスト名を設定することが重要です。

現在、これに対する適切な解決策はありませんが、移行可能な永続ディスクを使用してポッド（rcにバインドされていない）を作成できます。特定の障害の場合、ポッドであるという警告を手動で再スケジュールする必要があります。 これが、ホスト名を静的に保つために私が考えることができる唯一の方法です。

または、起動時にホスト名ディレクトリを安定した場所にシンボリックリンクします

2015年7月11日には、17:26で、マイクDaneseの[email protected]は書きました：

私が正しく理解していれば、rabbitmqポッド（レプリケーションで作成）
コントローラー）クレレウサギで
https://github.com/GoogleCloudPlatform/kubernetes/tree/master/examples/celery-rabbitmq
例では、データがに保存されている場合でも、ポッドの障害に関するデータが失われます
永続ディスク。 rabbitmq docから：

RabbitMQは、データベースディレクトリに現在のホスト名を使用して名前を付けます。
システム。 ホスト名が変更されると、新しい空のデータベースが作成されます。 避けるために
データの損失固定された解決可能なホスト名を設定することが重要です。

現在、これに対する適切な解決策はありませんが、ポッドを作成することはできます（
移行可能な永続ディスクを使用してrcにバインドされています。注意点はポッドです
特定の障害の場合は、手動でスケジュールを変更する必要があります。 それは
ホスト名を静的に保つために私が考えることができる唯一の方法。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -120662490
。

これは、ホスト名をポッド名から派生させてはならない理由の例です-＃4825

これにちょっとしたキックを与えるには：

解決する必要のあるいくつかの基本的な問題があります。

1. 一部のコンポーネントは、ディスク上のストレージに関連付けられているポッドごとに一意のIDを持っている必要があります
   
   
   
   1. さらなる問題として、それらのいくつか（場合によってはzookeeper）は、ホスト名が解決可能で一致する必要があります
   
   
2. スケールアウトされた一部のコンポーネントは、ポッドごとに異なる永続ストレージを備えている必要があります（ポッドは、ポッドごとに異なるPVCを指し、IDに関連付けられています）
   
   
   
   1. これらのボリュームは、スケールアップ時にオンデマンドで作成する必要がある場合があります
   
   
   2. これらのボリュームは、プールから再利用する必要があり、再作成しない必要がある場合があります
   
   
3. 一部のコンポーネントは、数万のインスタンスにスケールアウトする場合があり、割り当てられた個々のIDの追跡が実用的ではなくなります。
   
   
   
   1. 名目上の用途の大部分は、おそらくポッドの2〜7インスタンスの間です（最新のスケーラブルDB、ほとんどのシャーディングされたマルチマスターセットアップ）
   
   
4. 一部のコンポーネントは、独自のマスター選択を実装する必要はありませんが、IDの1つを任意にすることでプラットフォームに管理させます（ID 1がマスターになります）
5. これらの問題を解決する場合でも、ユーザーはポッドへの変更を（デプロイメントを介して）ロールアウトし、IDが保持または再割り当てされるようにする必要があります。

これらは必ずしもすべて同じソリューションで解決する必要はありません。 たとえば、小規模なクラスターID（2〜7）と大規模なクラスターID（> 7）には大きな違いがあると思います。 たとえば、大規模なケースでは、そのソフトウェアはギャップにあまり関心がないか、既存のコンセンサス/メンバーシッププロトコルを持っています。 小さなケースでは、ソフトウェアはIDを確立するためにより多くの支援を必要とします。 これらをクラウドネイティブ（> 7）ソフトウェアと既存クラスター（2-7）ソフトウェアに分けます。

1a、1b、2aに同意します。 2bは別の問題のように聞こえますが、おそらくソリューションは同じパターンを再利用できます。

スケール（3）は主に、クラウドネイティブとそうでないものの違いに同意しますが、インスタンスごとに1つのサービスとRCの回避策が適切でないことを示していると思います。

マスター選挙（4）は個別に対処できます。

（5）にも同意します。

この時点で、ほとんどの設計要件は明確だと思います。

残りの設計の質問：

I. VIPを割り当てるか、IPの変更を許可しますか？ VIPは現在システムを介して検出できないため、これに密接に関連しているのは、コンテナがLinuxを介して独自のIPを検出できる必要があるかどうかです。 IPを検出できる必要があると思いますが、ポッドIP（＃12595）と同様に、下位APIを使用できます。 （ポッドIPを使用するために）IPの変更を許可することは、DNS TTLとキャッシングの「バグ」のために、IPの変更率に制限があることを意味します。 ある時点で、ポッドIPを移行可能にする予定ですが（＃3949）、IPの変更が永遠に続くわけではありません。

II。 プッシュ（ポッドへ）とプル（ポッドから）。 サービスとRCは意図的にポッドに緩く結合されているため、どちらも「プッシュ」モデルを使用します。 名目上のサービスは、より本質的にポッドIDに関連付けられます（ただし、永続的ではありません。ポッドは交換可能である必要があります）。 その結果、プッシュモデルのモチベーションが低下します。 スケジューリングやespなどの他の割り当ての場合。 永続ボリュームへの永続ボリュームクレームなどの排他的バインディングは、リクエスト/ ackモデル（別名「プル」）を使用します。 それは現在、私が名目上のサービスに好むモデルです。

（I）について意見はありますか？

マスター選挙は＃1542であり、HA実装の一部として議論されています（例：＃12884）。

プッシュとプルの意味がわかりません。

私はこの問題のほとんどを読み直しました、そして私は単一ではないと確信しています
解決。 ブリッジを構築するには、一連の機能が必要になります
これらの種類のアプリ。

私は、ポッドが実行されると、実際にはできないという公理から始めています
実行中のポッドを変更します。 これにはいくつかの例外があります（例：仮想
ファイルシステムの内容）が重要と思われるもの（env vars、IP、
ホスト名）あなたはあなたが始めたものは何でも行き詰まります。

私はまた、間の緩い結合という主張から始めています
サービスとポッドは残り、私たちが話していることは実際には
サービス。 ポッドは、どのサービスがポッドの前にあるかを実際には知りません。 変更した場合
つまり、それはもはやサービスではありません。

私はただ意識の流れをして、何が悪臭を放っていないかを見るつもりです。

アイデア1：ThingPoolsとパッチ。

新しいAPIオブジェクトまたはのプールを定義できるものを定義します
もの。 何ですか？ Thingは、文字列（またはJSONブロブ）であり、
列挙型があります。 あなたは物事とそれらの物事のプールを作成することができます
使用するのはあなたです。 タイプには、VUID（ホスト名）、文字列、VIPが含まれます。

操作を作成するために渡すことができる新しいAPI構造を定義します-
パッチ。 パッチは、存在するオブジェクトにパッチを適用する方法についての説明です。
作成した。 パッチオプションの1つは、「ThingPoolからの割り当て」です。

これらをまとめるには：

ThingPoolを定義します{meatadata.name：my-quorum-hostnames、type：VUID、
自動生成：5、} // 5つの有効なVUIDのプールを作成します

RCを定義する{レプリカ：5 ...}

RCの作成（POST）でも、パッチを送信します：{what：
"podTemplate.spec.containers [*]。metadata.VUID"、プール： "my-quorum-hostnames"
}

POST操作はパッチをRCに適用します-1つのVUIDを割り当てます
ThingPoolからのコンテナごと。 ポッドが強制終了されて再作成されるたびに、
VUIDはプールに返され、次に起動するポッドがそれを取得します。

これを使用して、文字列のプール（ "0"から "99"）を生成し、固定することができます
それらをenv変数に入れます。 これを使用して、VIPのプールを割り当て、
次に、それらのVIPをポッドに割り当てます（新機能になります-耐久性のあるポッド
IP-これがどのように拡張されるかわからない:)あなたはのプールを生成することができます
PersistentVolumeClaimは、各ポッドが使用するクレームボリュームに名前を付けてパッチを適用します。

このアイデアは多くの点で不完全ですが、私はそれが最もよく捉えていると思います
ポッドのセットを完全に定義することなく、ポッドのセットのアイデア。

アイデア2：ポッドのセットを定義します。 サービスのふりをしないでください。 近いです
ボルグジョブに。 RCのようなものですが、ポッドに通常性を割り当てます。
コントロール-シャード番号。 VUIDのプールを制御します（ただし、必要ありません
ホスト名はユーザーが設定できるものにします、うーん...）。

もっとアイデアがあると思いましたが、そうではありません。 私は抽象化と格闘しています
と実装-私たちができない抽象化を定義することは無意味です
埋め込む。 名目上のVIPは素晴らしいように聞こえますが、それは
iptablesの制限。 一連のポッドに一連の安定したホスト名を提供する
のセットのためのストレージのセットで、最も重要なことのようです
尾が熱いポッド。

19:28で火、2015年8月18日には、ブライアン・グラント[email protected]
書きました：

1a、1b、2aに同意します。 2bは別の問題のように聞こえますが
おそらく、ソリューションは同じパターンを再利用できます。

スケール（3）は、主に1つのサービスの回避策と
インスタンスあたりのRCは適切ではありませんが、
クラウドネイティブvs.

マスター選挙（4）は個別に対処できます。

（5）にも同意します。

この時点で、ほとんどの設計要件は明確だと思います。

残りの設計の質問：

I. VIPを割り当てるか、IPの変更を許可しますか？ これに密接に関係しているのは
コンテナは、Linuxを介して独自のIPを検出できる必要があります。
VIPは現在、システムを介して検出できないためです。 私は彼らがそうすると思います
IPを検出できる必要がありますが、次のように下位APIを使用できます。
ポッドIPを使用（＃12595 https://github.com/kubernetes/kubernetes/pull/12595）。
（ポッドIPを使用するために）IPの変更を許可することは、レートの制限を意味します
DNSTTLとキャッシングの「バグ」によるIPの変更。 ある時点で、
ただし、ポッドIPを移行可能にする予定です（＃3949
https://github.com/kubernetes/kubernetes/issues/3949）、IPを変更する
永遠ではないでしょう。

II。 プッシュ（ポッドへ）とプル（ポッドから）。 サービスとRCは
ポッドに意図的に緩く結合されているため、両方とも「プッシュ」を使用します
モデル。 名目上のサービスは、より本質的にポッドIDに関連付けられます
（永続的ではありませんが、ポッドは交換可能である必要があります）。 その結果、私は見る
プッシュモデルのモチベーションが低くなります。 割り当ての他のケース、
スケジューリング、および特に。 永続ボリュームクレームなどの排他的バインディング
永続ボリューム、リクエスト/ ackモデル、別名「プル」を使用します。 それは現在です
私が名目上のサービスに好むモデル。

（I）について意見はありますか？

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -132423385
。

あなたが考えているように、私はおそらく本当にマスター選挙を意味していませんでした-それ以上
インスタンスのセットを初期化する必要がある機能を構築する場合
（明示的に調整せずに）それが
クラスタをブートストラップするには、通常、他のポッドとの「1」の会話で十分です。 アン
例は、レプリカセットを開始する必要があるmongodbです-ポッドの場合
彼らが「2」または「3」の印心者であると思うなら、あなたはあなたが
分割を開始します。 しかし、「1」は毎回安全に開始でき、その後
他のメンバー（彼らが使用できる永続的な状態を持っている）を追加してみてください
それらがすでにクラスターの一部であるかどうかを判別します）。 に応じて
IDサービスによって提供される保証は実際には得られない可能性があります
成功したクラスターですが、外部に別のポッドを作成する必要はありません
サービスを初期化します（それもひどいことではありませんが）。

午後11時59分火曜、2015年8月18日には、ブライアン・グラント[email protected]
書きました：

マスター選挙は＃1542です
https://github.com/kubernetes/kubernetes/issues/1542 、
HA実装の一部として説明されています（例：＃12884
https://github.com/kubernetes/kubernetes/pull/12884）。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -132439272
。

クレイトンコールマン| OpenShiftのリードエンジニア

@smarterclayton名目上のサービスの問題は別として、説明しているようにブートストラップするのは安全ではありません。 「1」が新しいマシンで再起動され、既存のノードに到達できない場合は、再ブートストラップされ、2つのmongodbが信頼できると主張します。 ブートストラップが完了した後にブートストラップする機能を削除するには、ジョブ定義を変更する必要があります。

@thockinがほのめかしているかもしれないので、ここではいくつかの類似しているが異なる機能を不必要に混同していると思います。k8sレベルで厳密に必要な以上のものを含めています。

上記の2つのまったく異なるユースケースがあります。信頼できる情報源によって異なります。

_Prescriptive：_ "N個のシャードを実行したいのですが、それより多いまたは少ない場合は、変更を加えてNに戻します。"
_説明：_「利用可能なすべてのシャードを自動検出し、それらが出入りするときに何らかの方法で見つけさせたい。」

これらは異なっているので、異なって説明する必要があると思います（ただし、実際に実行されているポッドと同様のメタデータを表示する場合があります）。

ディスカッションには、リソースフェンシングとシングルアクセス保証も組み込まれています。 Afaics、これをk8s内で実行する必要がある唯一のケースは、リモート永続ボリュームをマウントすることです（fsマウントはコンテナーの外部で実行する必要があるため）。これは、基盤となるリモートボリュームサービスがない場合、etcdロックを介して非常に簡単に実行できます。すでに内部でフェンシングを提供しています。 他のすべてのケースは、分散ロックサービスを使用して（または内部でロックを提供するサービスにアクセスして）、ユーザージョブ自体で処理できます。 ジョブに独自のロックを実行するように依頼すると、あらゆる種類のパターン（固定割り当て、日和見割り当て、「ホットスペア」など）と到達不能/回復戦略（ハードフェイル、最後の既知の続行など）が開かれます。

一般的なリソースフェンシング機能リクエストをこのバグから移動することをお勧めします（k8s自体が関与することなく、k8sでさまざまな分散ロックサービスを実行するためのレシピを提供するだけでフェンシングを実装します）。

念のために言っておきますが、1つのVIPの背後には_たくさんの_ポートがあります。 基盤となるネットワークでは大規模にIPを移行するのは難しいように思われるため、IPを移行したくないことに同意します。また、障害/リカバリエッジの場合にネットワークが一時的な重複を処理するのは厄介です。 ただし、非常に大規模なジョブの場合でも、各シャードメンバーに一意のサービスポートを割り当て、各ポッドインスタンスにプロキシデータを割り当てることは非常に可能だと思います。 （この提案は、プロキシがまだk8sで行きたい方向であると想定しています-私はこの領域に関する最近の議論に追いついていない）

プッシュとは、サービスやコントローラーなどの別のリソースが、ラベルセレクターを介してポッドのセットを監視し、それらに「もの」（解決可能なDNS名、VIP、PVC）を付与することを意味しました。

プルとは、ポッドが「モノ」の割り当てを明示的に要求し、それが/ bindingなどを介してそれにバインドされることを意味しました。

実行中のポッドの変更について：作成後にポッドを変更することは、実行中のコンテナーでポッドを変更することとは異なります。 スケジューラーは非同期を実行します。 たとえば、初期化。 PodIPも遅れて割り当てられます。 より一般的には＃3585で説明されています。

これが本当に「サービス」であるかどうかについて：

• ポッドのセット全体に物事を割り当てる必要があります
• モノ（DNS名など）は、ポッドのリソース名に本質的に関連付けられてはなりません
• あるポッドから別のポッドに移動できる必要があります
• ポッドは、割り当てられたもの（特に、DNS名とVIP）を「知る」（または下位APIを介して見つけることができる）必要があります。
• サポートする必要があるのは、解決可能なDNSです。
• VIPが必要かどうかは、私の1つの未解決の質問でした。 VIPを使わなくても大丈夫です。
• 理想的ではありませんが、ユーザーは、DNSやエンドポイントを介したピア検出のためにセット全体を対象とする2番目のヘッドレスサービスを作成できます。

アイデア（1）、ThingPools + Patchesは興味深いアイデアです。 私はそれを「プル」アプローチとして説明します。 ThingPoolは悪くはありませんが、パッチが使いにくいのではないかと心配しています。システム内のパッチからセマンティック情報をリバースエンジニアリングして、ストレージライフサイクルなどで許容できる動作を提供したくありません。 dよりドメイン固有のものを好む。 また、DNS名とPVCの独立したThingPoolは、同じ割り当てが必要なため、機能しません。

アイデア（2）を「プッシュ」アプローチとして説明します。 RCとデプロイメントの作業を複製したくないので、別のポッドコントローラーを導入するべきではありません。 アサイナは大丈夫ですが、必要以上に緩く結合されており、割り当ての処理方法の前例と一致しません。

再。 env varsへの情報の詰め込み：これはJobにも出てきました。 情報をアノテーションに詰め込み、特定のアノテーションをリクエストできるように下位APIを拡張したいと思います。 ユーザーが必要な情報のみを要求し、env変数名を選択できるようにしたいです。

再。 インスタンスごとに異なるポートを割り当てる：これは多くのレガシーアプリでは機能せず、システム設計との互換性もありません。

再。 規範的：Nを実行し続けることは、ReplicationControllerが行うことです。

再。 記述的：それはすでに存在するヘッドレスサービスです。

再。 ロック：はい、それが進行中のリースAPIです。

ストレージのプロビジョニングについては、＃6773（プッシュ）と＃12450（プル）で説明しています。

今では手遅れですが、少し寝てからなんとかして提案をする時間を作ってみます。

簡単な観察：ヘッドレスサービスはVIPを割り当てません

割り当て/割り当てをDNS公開から切り離すことができます。 現時点で割り当て/割り当てがどのように行われるかを無視すると、ホスト名を表すポッドのフィールドから名前を取得する、特別な種類のヘッドレスサービスを使用できます。

そして、耐久性のあるローカルストレージの問題が関連しています：＃7562、＃1515、＃598

私は主に他のPRレビューを行うので、より迅速な更新：

サービスを使用する利点の1つは、ポッドに要求されたホスト名がグローバルに一意であることを保証する必要がないことです。これは、サービスがDNSに公開された名前をスコープするためです。

再。 割り当て/割り当て：ReplicationController、Deployment、Daemonなどにテンプレートタイプを追加することは避けたいです。また、ストレージと名前をポッド間と同じくらい簡単にコントローラー間で移行できるようにしたいです（ユーザーが望む場合）。

2015年8月19日午前1時4分、AngusLeesの[email protected]は次のように書いています。

@smarterclaytonhttps ：//github.com/smarterclaytonそれは脇白です
名目上のサービスの問題ですが、ブートストラップするのは安全ではありません
記述。 「1」が新しいマシンで再起動され、たまたまできない場合
既存のノードに到達するために、それは再ブートストラップします、そして今あなたは2つを持っています
mongodbが権威を持っていると主張しています。 あなたは仕事を変える必要があります
ブートストラップ後にブートストラップする機能を削除する定義は
完了。

その場合、重複する可能性は完全にありますが、ほとんどの場合
ロック付きの永続ストレージについて話しているので、ブロックする場合
とにかく、gce / AWSがあなたのフェンスを解放し、あなたが接続できるようになるまで。 そう
ブートストラップで可用性を犠牲にしますが、必ずしも実行時に犠牲にする必要はありません
（フェンスのないストレージを使用している場合を除きます。その場合、これはそうではないことに同意します
安全な）

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -132448150
。

2015年8月19日午前1時35分、AngusLeesの[email protected]は次のように書いています。

@thockin https://github.com/thockinがほのめかしているかもしれないので、私は思う
ここでは、いくつかの類似しているが異なる機能を不必要に混同しています

• そして、k8sレベルで厳密に必要な以上のものを含めています。

上記の2つのまったく異なるユースケースがあります-ソースによって異なります
真実の：

_Prescriptive：_ "N個のシャードを実行したいのですが、多かれ少なかれ存在する場合
それよりも、変更を加えてNに戻します。」
_Descriptive：_ "利用可能なすべてのシャードを自動検出したいのですが、
彼らが行き来するときに、どういうわけか調べさせてください。」

これらは異なっているので、異なって説明する必要があると思います（ただし

実際に実行されているポッドと同様のメタデータを表示する場合があります）。

ディスカッションには、リソースフェンシングとシングルアクセスも組み込まれています
保証します。 Afaics、これをk8s以内に実行する必要がある_only_ケース
（afaics）はリモートボリュームをマウントしています-fsマウントを実行する必要があるため
コンテナの外。 他のすべてのケースは、ユーザージョブで処理できます
分散ロックサービスを使用して（または
内部でロックを提供します）。 ジョブに独自のロックを実行するように依頼すると、
あらゆる種類のパターン（固定割り当て、日和見割り当て、「ホット」
スペア」など）および到達不能/回復戦略（ハードフェイル、
前回の既知の続行など）。

一般的なリソースフェンシング機能を移動することをお勧めします-これからリクエストしてください
バグ（そして、実行するためのレシピを提供するだけでフェンシングを実装します
k8sでのさまざまな分散ロックサービス
k8s自体）。

特定のタイプの実行を目的から切り離すことはできないと思います
ソフトウェアアウト-設計は名目上のサービスを示していますが、私たちのユースケースは
説明はIDとディスクの再利用です。 私は同意します、フェンシングはの財産です
ボリューム-しかし、ボリュームの取得をの特定のプロパティに結び付ける
ポッドインスタンスはそうではありません。

念のために言っておきますが、1つのVIPの背後には_たくさんの_ポートがあります。 同意します
基盤となるネットワークでは難しいと思われるため、IPを移行したくない
大規模で、ネットワークが一時的な重複を処理するのは厄介です
障害/リカバリエッジの場合。 しかし、私はそれがかなり実現可能だと思います
各シャードメンバーに一意のサービスポートを割り当て、それぞれにプロキシデータを割り当てます
ポッドインスタンス-非常に大規模なジョブの場合でも。 （この提案は、
プロキシはまだk8sで行きたい方向です-私は追いついていない
この分野に関する最近の議論で）

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -132451774
。

@thockinのThingPool + Patchesのアイデアに少しひねりを加えました：

テンプレート：リソース+パラメーターおよび置換のリスト。 インスピレーションについては、 https：//github.com/openshift/origin/blob/master/pkg/template/api/types.goを参照して

TemplatePool。 基本的にThingPool。 レプリカ数ではなく、オンデマンドでテンプレートの高密度にインデックス付けされたインスタンスを生成します。

楽しみ/一貫性のために：v2 ReplicationControllerは、ポッドだけでなく、任意のテンプレートを複製できます。 ref＃170（一種）。 すべての割り当てがポッドレプリケーションによって駆動される場合は、おそらく必要ありません。

主な代替案は、ホスト名とPVCプールに焦点を当てた、よりドメイン固有のものですが、それぞれに個別のプールは機能しません。 単一のプールは、ホスト名のタプルと（場合によっては複数の）PVCを割り当てることができる必要があります。 TemplatePoolの利点の1つは、誰かがそれを使用してレプリカごとに1つのサービス（おそらく外部）を割り当て、現在のZookeeperの回避策を自動化できることです。 誰かがポッドを使って1対1で同様に複製したいと思う他のリソースがあるかどうかはわかりませんが、APIの成長率を考えると、そうなることはないと思います。

@smarterclayton参考までに、インラインコメントを使用してメールで返信すると、Gmailと

ええ、Gmail + github + iPhoneに何か問題があります。

2時24分PMの木、2015年8月20日には、ブライアン・グラント[email protected]
書きました：

@smarterclayton https://github.com/smarterclaytonFYI返信するとき
インラインコメント付きの電子メールを介して、あなたの応答は両方とも読めません
Gmailとgithubで。 Gmailでは改行はなく、githubではそこにあります
引用符の接頭辞がないので、あなたの応答は、
引用されているテキスト。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -133108803
。

クレイトンコールマン| OpenShiftのリードエンジニア

今日は簡単なチャットをしました。いくつかのハイライトがあります。

アプリの3つのクラスについて話しました：

• ステートレスWebアプリであるアプリ（RCでのみ機能します）
• 外部マスターを使用し、既存の一貫性を備えた巨大なスケールのアプリ
  コンセンサスを処理するためのプロトコル（Cassandra、Infiniband）
• Mongodb、rethinkdb、voltなどの小さなクラスター化されたステートフルソフトウェア、
  zookeeper、riak、redisクラスター、これらはうまく機能するためにいくつかのパターンが必要です
  
  
  
  • 一意のID（通常）
  
  
  • 再利用されるインスタンスごとの一意の永続ボリューム（通常）
  
  
  • 安定したIPアドレスまたはDNS名（通常）-DNS名は通常
    
    安定したIPアドレスの代用
  
  
  • 安定したホスト名（まれに）
  
  

今日、あなたはNを持つことによってユニークなアイデンティティと永続的なボリュームを解決することができます
レプリケーションコントローラー、Nサービスの安定したIPアドレス。 私たちそうしたい
これらのユースケースの一部では、NRCとサービスを必要としません。

ティムとブライアンの提案について、順不同で話しました。

• TemplatePoolは、レプリケーターが
  クラスタ全体でオブジェクトを作成する権限があり、知っている必要があります
  すべてのAPIエンドポイントがあります。
  
  
  
  • テンプレートエンドポイントをインスタンス化することもできますが、それでも
    
    権限委任の問題を解決します（サービスアカウントを使用しますか？）
  
  
  • オブジェクトの検索と権限の制限は長期的なものです
  
  
• 私たちが話し合った「ポッドアイデンティティ」、別名vuidフィールド-議論がなされた
  そして、それがグローバルにユニークである必要はなく、ただ
  ポッドがそれを使用することを期待するドメイン内で一意。
  
  
  
  • 架空のインデックスアサイナ（スパースまたはデンス）がその値を設定できます
    
    作成後、kubeletはポッドが起動するまで待機できます。
    
    アイデンティティ（彼らが1つを待っていることを示す必要があるかもしれません）
  
  
  • 密なインデックスは一般的に単純なものに役立ちますが、これは
    
    作成後に作成され、kubeletから切り離されます。
    
    代入アルゴリズムの種類（高密度数値、コンシステントハッシュリング、
    
    ランダムなど）
  
  
• ポッドでの単純なテンプレート作成は開始するのに適した場所のようですが、必要なのは
  既存のツールチェーンと一貫性を保つために、
  完全に壊す
  
  
  
  • IDフィールドを使用して、他のフィールドをテンプレート化します
  
  
• ユーザーが自分で設定できるポッド仕様にホスト名フィールドを追加し、
  アイデンティティでパラメータ化する
• ヘッドレスサービスがエンドポイントのDNSクエリに応答できるようにする
  ID（エンドポイントコントローラーにポッドからのIDを具体化させる
  エンドポイントに）ある程度の安定性を保証します
• どういうわけか、永続的なボリュームクレームをパラメータ化するか、次のように変更することができます
  プールから描画します（またはプールコントローラーに、ごとに1つのボリュームがあることを確認します
  アイデンティティ、またはアイデンティティコントローラにプールから描画させる）、考える必要があります
• 環境/下向きのAPIを簡単に変換できるツールが必要
  構成ファイル（直交しますが、より簡単なはずです）
• パターンに関するまだいくつかの懸念

2015年8月20日木曜日午後3時34分、Clayton Coleman
書きました：

ええ、Gmail + github + iPhoneに何か問題があります。

2時24分PMの木、2015年8月20日には、ブライアン・グラント[email protected]
書きました：

@smarterclayton https://github.com/smarterclaytonFYI返信するとき
インラインコメント付きの電子メールを介して、あなたの応答は両方とも読めません
Gmailとgithubで。 Gmailでは改行はなく、githubではそこにあります
引用符の接頭辞がないので、あなたの応答は、
引用されているテキスト。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -133108803
。

クレイトンコールマン| OpenShiftのリードエンジニア

クレイトンコールマン| OpenShiftのリードエンジニア

もう1つの問題：名目上のサービスのメンバーのTLS証明書

一般的なサービスのTLS証明書も良いことです（署名済み
要求に応じて、クラスタCAによって自動的に）。

17:19の木、2015年8月20日には、ブライアン・グラントの[email protected]は書きました：

もう1つの問題：名目上のサービスのメンバーのTLS証明書

—
このメールに直接返信するか、GitHubで表示してください。

クレイトンコールマン| OpenShiftのリードエンジニア

はい：＃11725

再：

• ユーザーが自分で設定できるポッド仕様にホスト名フィールドを追加し、
  アイデンティティでパラメータ化する
• ヘッドレスサービスがエンドポイントのDNSクエリに応答できるようにする
  ID（エンドポイントコントローラーにポッドからのIDを具体化させる
  エンドポイントに）ある程度の安定性を保証します

コンテナーによって表示されるホスト名が他のコンテナーによって解決可能になるように、DNSはポッド仕様に設定されたホスト名（その機能を追加するとIDによってパラメーター化される可能性があります）を使用してサポートされる必要があることに同意したと思います。

サブドメインを設定するには、明示的または暗黙的に、どのサービスがサブドメインをターゲットにしているかをポッドに通知する必要があります。 明示的なデメリットは、より多くの構成の接着剤/テンプレートが必要になることです。 暗黙的の不利な点は、システム内の緩い結合で私たちが抱える課題になりやすいことです。作成順序の競合と不整合、1対1の施行の難しさなどです。私は明示的に傾いています。 相互参照スコープの改善に取り組む必要があります。

何かのようなもの：

Hostname string
Subdomain string

PodSpecのHostNetworkの上。

サブドメインが適切なタイプのサービスのDNSと一致した場合にのみ、ホスト名ベースのDNSを配信します。 2つを1つのフィールドにスムージングすることもできます。

そのために問題＃4825を再利用し、誰かに取り組んでもらう必要があると思います。 それは他のものよりはるかに具体的で作業が少ないです。

どういうわけか、永続的なボリュームクレームをパラメータ化するか、次のように変更することができます
プールから描画します（またはプールコントローラーに、ごとに1つのボリュームがあることを確認します
アイデンティティ、またはアイデンティティコントローラにプールから描画させる）、考える必要があります

私がここで役立つと思うクレームについての2つのこと：

1. バインディングを1：1から1：Nに変更します
   
   
   
   1. バインディング参照としてのpvc.Spec.VolumeNameからpvc.Spec.VolumeNames []
   
   
2. pvc.Spec.Singeltonブール値は、共有のためにクレームを1回だけバインドする必要があるか、またはクレームを何度もバインドできるようにするかを示します。

RCは、必要に応じて新しいボリュームにバインドできます。 バインダーでこれを処理する方法を理解します。

それでも、正しい音量を適切なポッドに一致させることが重要です。

IDとボリューム名のマップが必要になります。

15:17時金、2015年8月21日には、マークTuransky [email protected]
書きました：

どういうわけか、永続的なボリュームクレームをパラメータ化するか、次のように変更することができます
プールから描画します（またはプールコントローラーに、ごとに1つのボリュームがあることを確認します
アイデンティティ、またはアイデンティティコントローラにプールから描画させる）、考える必要があります

私がここで役立つと思うクレームについての2つのこと：

1. バインディングを1：1から1：Nに変更します
   
   
   
   1. バインディングとしてのpvc.Spec.VolumeNameからpvc.Spec.VolumeNames []
      
      リファレンス
   
   
2. クレームをバインドする必要があるかどうかを示すpvc.Spec.Singeltonブール値
   共有するために1回だけ、またはクレームを何度もバインドできるようにします。

RCは、必要に応じて新しいボリュームにバインドできます。 私はこれを処理する方法を理解するだろう
バインダーで。

それでも、正しい音量を適切なポッドに一致させることが重要です。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -133535336
。

クレイトンコールマン| OpenShiftのリードエンジニア

0:56で金、2015年8月21日には、ブライアン・グラントの[email protected]は書きました：

サブドメインを設定するには、どのサービスがサブドメインをターゲットにしているかをポッドに通知する必要があります。
明示的または暗黙的に。 明示的の欠点は、より多くを必要とすることです
構成接着剤/テンプレート。 暗黙の欠点は、次のようになることです。
システム内の緩い結合で私たちが抱える課題になりがちです：作成-
注文の競争と矛盾、1対1の執行の難しさなど。私は傾く
明示的に。 相互参照スコープの改善に取り組む必要があります。

明確にしましょう-サブドメインを設定しないと、ユーザーに提供させることはできません
独自のホスト名。 サブドメインを設定する場合は、
ユニークな方法-十分（DNSスペースでは、現在、
名前空間）。 サブドメインをサービスの名前にすることは
十分にユニークです。

DNS（単一のTLD）の制限のいくつかを考えると、これは
現実的には、ユーザーに2つのDNS_LABELフィールド（ホスト名）を与えることを意味します
と名目上のセット。 具体的な例：

pod.spec.metadata.name: my-pod-1bd3
pod.spec.metadata.namespace: my-app
pod.spec.identity.name: foo
pod.spec.identity.surname: bar

これにより、ポッドが次のように表示されます。

$ hostname
foo

$hostname -f
foo.bar.my-app.nom.cluster.local

foo.bar.my-app.nom.cluster.local DNSサービングAおよびPTRレコード

これは現在のDNS構造よりも1レベル深いですが、私は
現在のndots = 5がこれをカバーしています。 あるいは、次のように言うこともできます
名前空間は名前空間であり、ユーザーに戻して一意の名前空間を割り当てます
名前空間内のホスト名。 DNSの結果は次のようになります
foo.my-app.pod.cluster.localこれはサービスを反映しています。 私たちもできた
オプションのホスト名フィールドをサービスに追加して、それらをより類似させます。

サブドメインがホスト名ベースのDNSと一致する場合にのみ、ホスト名ベースのDNSを配信します
適切なタイプのサービス。 2つを1つのフィールドにスムージングすることもできます。

これの私の最も嫌いな部分は、ポッドが「私は一部です
of Service'bar '"（上記の例）。前もって。アプリオリ。

滑りやすい坂道は、一般的にこれを許可しないのはなぜですか？ それは
今日は仮定できないことの束を単純化する（
緩い結合の）実際には単一のポッドが表示されることはめったにありませんが
複数のサービスの背後にあります。 すべてのポッドが0または1未満だった場合
サービス、システムはもっとシンプルになりますか？

そのために問題＃4825を再利用し、誰かに取り組んでもらう必要があると思います。 それは他のものよりはるかに具体的で作業が少ないです。

それは確かにすぐに始めることができるものですが、（それらのために
自宅でフォロー）ポッドを実装するためのメカニズムにすぎません
IDのセットを管理するポリシーではなく、ID。

15:17時金、2015年8月21日には、マークTuranskyの[email protected]は書きました：

私がここで役立つと思うクレームについての2つのこと：

1. バインディングを1：1から1：Nに変更します

これが私が始めたところですが...

2015年8月21日金曜日12:38 PM、Clayton Coleman
[email protected]は次のように書いています：

IDとボリューム名のマップが必要になります。

うん。 これは実際にはテンプレートの問題であることが判明しています。
問題を「ポッドテンプレート」と考えるかどうか
フィールドには、「置換タプル」で埋められるプレースホルダーがあります
実行時にプールから描画されるか、完全に洗練されたポッドと見なされます
プールから引き出された「置換タプル」で「パッチされた」スペック
実行時-それらは同形であり、同様に不快です。

それでも、これは私たちが解決する必要のある大きな問題の1つだと思います。
これらのストローマンの提案を作成し始める必要がありますか？

ポッドが2つまたは3つのサービスを受けている例がいくつかあります。
1つは暴露用、もう1つは暴露試験用です。

IDに関しては、デーモンコントローラーによって作成された各ポッドには、ノードIDとコントローラーIDから派生したIDが割り当てられている必要があります。 これは、IDが明らかであり（ホストyのポッドxがID f（y）を持っている）、デーモンの責任の一部である場合があります。

@smarterclaytonなので、ここでの一般的な（ただし普遍的ではない）必要性は、グループメンバーの安定した順序付きリストを維持することです。 IDがポッドがスケジュールされているノードに関連付けられている場合、これはどのように機能しますか？

デーモンコントローラ_only_は、ポッドが存在するノードのコンテキストでIDを持っています
それでも僕らは走ります。 レプリケーションコントローラーとサービスは異なります。 デーモン
コントローラは、「各ノードでこれらのいずれかが実行されている必要があります」と言います。 三
ポッドが持つことができるIDは、そのノード以外にはありません。

1:13で金、2015年9月11日には、アンガスリーズ[email protected]
書きました：

@smarterclayton https://github.com/smarterclaytonとても一般的です（しかし、そうではありません
ユニバーサル）ここで必要なのは、グループの安定した順序付きリストを維持することです
メンバー。 それは、アイデンティティがに結び付けられるべきではないことを意味すると思います
ポッドがたまたまスケジュールされているノード。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -139453809
。

クレイトンコールマン| OpenShiftのリードエンジニア

@smarterclaytonああ、この問題は明らかに元の機能要求以上のものに変化しました-私はここで構築しようとしていたものに迷っているので、ノイズを追加し続けるのではなく、元に戻します...

申し訳ありませんが、ポイントが関連していないことを意味するものではありませんでした。 課題は、セットを定義し、それをポッドに伝播する必要があることです。 ポッドがセットのメンバーシップに反応する必要があります（セットのポッドIDと一致するボリュームXをマウントします）。 未解決の質問があります-ポッドは同時に2つのセットのメンバーであり、どちらかで一意のIDを持つことができますか？

デーモンコントローラーによって実行されるポッドのIDが「明らか」である場合があります（デーモンコントローラーは一連のノードで動作し、RCは一連のポッドで動作します）。

アイデンティティの要件の1つは、セット内で一意であることです。 ポッド名とポッド名の生成を活用して、その一意性を確保できますか？ たとえば、RCはランダムな名前を生成します。 RCは、選択したポッドのセットに基づいて、決定論的な方法でポッドの名前を生成できますか？

ラベルa = bのポッドを選択するRCについて考えてみます。 作成する次のポッドを計算するには、ポッドをフェッチしてカウントに減らす必要があります。 それを一意の名前セットに減らした後、RCがそのセット内の名前生成パターンに従おうとした場合はどうなりますか？ オーバーラップしないが、サービスラベルにポッドを作成した2つのRCは、一意の名前を生成できません（名前を争う可能性がありますが、それは暗黙的です）。 名前は削除後に再利用できます

次に、ポッド内の永続ボリュームは、ポッド名に基づいてPVCを使用できます。 PVCプーラーは、観察されたRCのプールに対して十分なクレームがあることを確認できます。 デーモンコントローラーは、ノード名に対して決定論的な名前を選択できます。 いくつかのパターンに基づいて、サービス内のポッド名にDNS名をワイヤリングすることもできます。

これは、ポッドに個別のIDフィールドを追加するよりも倹約的です。 これは、ポッドがまだペットではないことを意味しますが、その名前はペットである可能性があります（これは不合理なステートメントではありません）。 同じポッドプロセスの2つのインスタンスがクラスター上で同時に実行されるのを防ぐことはできませんが、その名前が現在1つの場所でのみ使用されていることを保証することはできます。

上記の「観察された名前のプール」を意味します。 エンドポイントDNSはhashpodname.ept.service.namespace.svc.cluster.localになります。 エンドポイントにはすでにポッド名があるので、何も追加する必要はありません。

https://github.com/kubernetes/contrib/tree/master/service-loadbalancerに関連しており、次の反復の可能性としてこの問題の解決を提案しています

ここでDaemonSetについて説明するのはなぜですか？ それは＃12893、IMOによって解決されました。

@smarterclaytonポッド名からIDをhttps ：

1つの可能性は、必要に応じて@smarterclaytonが記述した方法で名前を生成できるRCオプションと、オプションの設定方法に応じて使用できる機能の個別のセットを用意することです。 したがって、このオプションを有効にすると、「タスクインデックス」アプローチでは実装が難しいものは利用できなくなりますが、ここで説明する機能は利用できます。 逆に、デフォルトの動作（オプションが無効）では、これらの他の機能は提供されますが、ここで説明する機能は提供されません。

ボーグのタスクインデックスの抽象化のようなものの有用性は、_特定のユースケースで_出続けているようで、オプションとして提供できない理由は私にはわかりません。

DaemonSet分散ファイルシステムストレージのケースを解決するとは思わない
（Gluster）各ホストが再参加するために一貫したIDを持っている必要がある場合
クラスター。 もっと掘り下げますが、まだ何かが必要かもしれないと思います
＃260のニーズ-再接続した場合にホスト名が十分かどうかはわかりません
新しいインスタンス上のホストディスク。 たぶん私はDaemonSetが何であるか理解していませんでした
提供され、＃12893が配信されましたが、それは問題ではないと思います。
ディスクを再利用したいシステムホスト。

0:22の水、2015年9月16日には、ブライアン・グラント[email protected]
書きました：

@smarterclaytonhttps ：//github.com/smarterclayton再訪しないで
ポッド名からIDを取得することも、RCを使用してIDを割り当てることもできません。
これらのアプローチの問題はここで議論されました：＃260（コメント）
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -102107352

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -140623023
。

クレイトンコールマン| OpenShiftのリードエンジニア

具体的な例として、etcdクラスターを想像してみてください。 7つのインスタンスと7つのインスタンスがあります
ボリューム。 （議論のために）名前と巻などが欲しいd-1
etcd-7からetcd-pvc-1からetc-pvc-7まで。

ローリングデプロイメントでは、MaxUnavailableが90％（または同等）、MaxSurgeが0％です。 これ
古いRCを縮小し、新しいRCを拡大します。 古いRCを優雅に
etcd-5を削除します。 それは即座に効果的なRCセットから抜け出します。 新しい
RCはetcd-5を作成しようとします（設定されたギャップの観察による）。 それは受け取ります
「AlreadyExistsException」。 これをバックオフおよび再キューとして扱います。 一度
etcd-5は本当になくなっており、続行することができます。 etcd-5の準備ができたら、DC
次のステップに進みます。

別の方法（ポッドに設定されたID）の場合、古いRCは縮小されます。 A
新しいポッドは新しい名前で即座に作成されます。 新しいポッドを起動できません
どのPVCをマウントするかを判断するためにIDを設定する必要があるためです
音量。 Kubeletで待機ループに入ります。 IDコントローラー
一部のラベルセレクタセットを監視し、IDなどを監視します-5はそうではありません
割り当てられます。 アイデンティティetcd-5を新しいポッドに設定します。 kubeletは観察します
その変更により、マウントするPVCを特定し、ポッドを起動します
（ボリュームが他のノードから切り離されていると仮定します）。

構造的に、これらは非常に似ています。 後者では、開始のオーバーラップが可能です。
どちらもPVCをマッピングする必要があります。

2015年9月16日水曜日午前0時39分、Clayton Coleman
書きました：

DaemonSet分散ファイルシステムストレージのケースを解決するとは思わない
（Gluster）各ホストが再参加するために一貫したIDを持っている必要がある場合
クラスター。 もっと掘り下げますが、まだ何かが必要かもしれないと思います
＃260のニーズ-再接続した場合にホスト名が十分かどうかはわかりません
新しいインスタンス上のホストディスク。 たぶん私はDaemonSetが何であるか理解していませんでした
提供され、＃12893が配信されましたが、それは問題ではないと思います。
ディスクを再利用したいシステムホスト。

0:22の水、2015年9月16日には、ブライアン・グラント[email protected]
書きました：

@smarterclaytonhttps ：//github.com/smarterclayton再訪しないで
ポッド名からIDを取得することも、RCを使用してIDを割り当てることもできません。
これらのアプローチの問題はここで議論されました：＃260（コメント）
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -102107352

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -140623023
。

クレイトンコールマン| OpenShiftのリードエンジニア

クレイトンコールマン| OpenShiftのリードエンジニア

私にとってこの問題を難しくしているのは、名前の安定した一意のプールを生成したり、PDのプールを使用したりしていないことです。 問題は、両方を同時に実行することです。 そして、それを拡張すると、仕様内のほぼすべての識別子をこのようにプールできないのはなぜですか？

パックされたインデックスの問題を私が知っている限り（ほとんどは中古）、それらは住みやすいかもしれないと思います（特に、Davidが提案し、他の機能と相互に排他的にする場合）。 しかしまた、私がそれを煮込むほど、いくつかのモロンがアップスレッドに投稿したパッチのアイデアを嫌うことは少なくなります。

この問題は長引いており、分析の麻痺が発生しているのではないかと思います。

他のプーリングのユースケースの例がもっとあればいいのにと思います。 Glusterだと思った
異なるでしょうが、それは上の別の変種です
cassandra / etcd / mongo / zookeeper "ボリュームを再利用したいので、
私が前に誰だと言ったか覚えておいてください」。
最初のNポッドコーディネーターと次のMワーカーを作成したい）例
活用する。

0:46の水、2015年9月16日には、ティムHockin [email protected]
書きました：

この問題を難しくしているのは、私にとって、安定したものを生成していないことです
名前の一意のプールまたはPDのプールを使用します。 問題は両方を行うことです
同時に。 そして、あなたがそれを拡張するならば、なぜほとんど何もできない
仕様の識別子はこのようにプールされますか？

私が知っている限り（ほとんどは中古）、パックされたインデックスの問題です。
彼らは住みやすいかもしれないと思います（特にDavidが提案し、
それらは他の機能と相互に排他的です）。 でもまた、煮込むほど
それは、私がパッチのアイデアを嫌うことが少ないほど、いくつかのmoronがアップスレッドに投稿しました。

この問題は長引いており、分析が行われているのではないかと思います。
麻痺。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -140625746
。

クレイトンコールマン| OpenShiftのリードエンジニア

DaemonSet：

12893は、ホストネットワークを使用するときに、ポッドのホスト名をノードのホスト名に設定します。これは、DaemonSetに使用するのに完全に合理的です。そうしないと、とにかくhostPortが使用されるためです。

また、DaemonSetをノードコントローラーと統合して、暗黙の無期限の許し＃1574を提供し、一般にノードに対してスケジューリングを有効にする前に「スケジューリング」を有効にすることを目的としています。 暗黙の優先順位付けも合理的かもしれません。

クラスタストレージシステムの場合、ストレージシステムによってのみhostPathを介してアクセスされる各ホストに追加のディスクをプロビジョニングすることを想像できます。これらのディスクはDockerやemptyDirによって使用されません。

IDに関しては、ここでの提案に問題はありません： https ：

この問題は、主に十分な優先順位の欠如、IMOが原因で長引いています。

クレイトンをリフするには（または、同じことを言うだけで、面倒です）：

$ kubectl create -f -
kind: IdentityPool
apiVersion: v1
metadata:
  name: my-etcd-idents
  namespace: default
spec:
  identities:
    - etcd-0
    - etcd-1
    - etcd-2
^D

$ kubectl create -f -
kind: VolumePool
apiVersion: v1
metadata:
  name: my-etcd-volumes
  namespace: default
spec:
  volumes:
      - etcd-disk-0
      - etcd-disk-1
      - etcd-disk-2
^D

$ kubectl create -f -
kind: Replicationcontroller
apiVersion: v1
metadata:
  name: my-etcd-rc
  namespace: default
spec:
  selector:
    job: etcd
  identityPoolName: my-etcd-idents
  podTemplate:
    containers:
        - name: etcd
          image: coreos/etcd:2.0
          volumeMounts:
              - name: data
                path: /data
    volumes:
        - name: data
          identity:
              volumePoolName: my-etcd-volumes
^D

これは、RC（または何か）がこれがIDセットであることを認識し、identityPoolからインデックスを割り当て、そのIDをポッド名に割り当ててから、内部を覗いて他のID中心のフィールドが設定されているかどうかを確認することを意味します-IDこの場合のボリューム。

完全に一般的ではありませんが（ランダムフィールドをプールすることはできません）、必要に応じてID対応オプションを追加できます。

気に入ったスペックを決めれば、早く完成するのではないかと思います。

スペックを書くだけでも時間がかかります。

IdentityPool / VolumePoolに関しては、かなり前に、複数のプールが機能しないことをすでに決定しました。

1.1のコード完了期限は金曜日です。 今これをしないでください。

関連もあります：＃170。 それはポッドテンプレートを分割することを提案しましたが、テンプレートスキーム（パッチよりも強く好む）を選択する場合は、それらを一緒に検討する必要があります。

私は少なくともv1.2候補にデザインを載せました。

申し訳ありませんが、スケッチでは明確ではありませんでした-RC（またはIC？）には次の概念があります
プライマリプールまたはインデックス。 ポッドにICでインデックスが割り当てられると、
indexは、すべてのプール中心のフィールドにインデックスを付けるために使用されます。

テンプレートを分割する場合、RCは分割できないと仮定します
テンプレートを変更します。 それは少しトリッキーです。

今週は話をやめて大丈夫です。 それはちょうど私の中に飛び込んだ
受信トレイと私はこのアイデアを噛んでいました...

22:09で火、2015年9月15日には、ブライアン・グラント[email protected]
書きました：

スペックを書くだけでも時間がかかります。

IdentityPool / VolumePoolに関しては、私たちはすでに長い間決定しました
以前は、複数のプールは機能しません。

1.1のコード完了期限は金曜日です。 今これをしないでください。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -140627868
。

ええ、私たちの側で議論を引き起こしたものがありました。
お客様の問題は、リリースプロセスがなくなるのを待ちます。

1:14の水、2015年9月16日には、ティムHockin [email protected]
書きました：

申し訳ありませんが、スケッチでは明確ではありませんでした-RC（またはIC？）には次の概念があります
プライマリプールまたはインデックス。 ポッドにICでインデックスが割り当てられると、
indexは、すべてのプール中心のフィールドにインデックスを付けるために使用されます。

テンプレートを分割する場合、RCは分割できないと仮定します
テンプレートを変更します。 それは少しトリッキーです。

今週は話をやめて大丈夫です。 それはちょうど私の中に飛び込んだ
受信トレイと私はこのアイデアを噛んでいました...

22:09で火、2015年9月15日には、ブライアン・グラント[email protected]
書きました：

スペックを書くだけでも時間がかかります。

IdentityPool / VolumePoolに関しては、私たちはすでに長い間決定しました
以前は、複数のプールは機能しません。

1.1のコード完了期限は金曜日です。 これをしないでください
今？

—
このメールに直接返信するか、GitHubで表示してください
<<
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -140627868

。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -140628241
。

クレイトンコールマン| OpenShiftのリードエンジニア

議論はすべてIP番号とポッドに関するものですが、Mongo＆Zookeeperでの私の経験では、IPは無関係のままである必要があります（ペットになることはありません）。 このボリュームは他の「ボリューム」のIP番号を記録するため、永続的な_volume_には呼び数が必要です。 そのボリュームをマウントするポッドが何であれ、記録されたIP番号を何らかの方法で使用できるはずです。 ボリュームはペットです...

ボリュームに対して時間的に一定であり、ボリュームをマウントするポッドに割り当てられたDNS名は、私が思うに長い道のりを歩むでしょう。

MongoとZKでアンサンブルのメンバーシップを変更するには、実行するために常にカスタムコードが必要であり、他のほとんどのアンサンブルでも同じであると思います。 したがって、Replication Controllerは間違った名前です。これらのペットには、より多くのMemberShipコントローラーが必要です。 メンバーシップコントローラーは、初期設定を処理してから、アンサンブルへの増分変更を処理し、最後にそれを強制終了できる必要があります。

マウントされたボリュームに基づく一定のDNS名と、カスタムコードでアンサンブルメンバーシップを処理できる可能性がある場合、これらのタイプのシステムを処理できるようになるはずです。

はい、ポッドIPは短期間のハックです。

この提案が進むのは、DNSとボリュームの両方を超えるものです。
結合を維持するために活用できます。 懸念されるのは、DNS名を定義するボリュームです
すでに確立したカップリングの逆であり、
ポッド仕様の他の部分にそのより高い概念を活用させたい
（アイデンティティ）環境のダウンワードAPIのように。 それは適応する
異なるアンサンブルソフトウェアへの識別が容易になります（
タイプ）。

アンサンブル以外のユースケースがないことを確認する必要があります
ここで重複し（提案されたものを聞いたことがありません）、次に
最小限かつ適切であると感じる具体的な提案。 ティムは持っていると思う
最近ここに要約しました。

2015年9月23日午前11時33分、PeterKriensの[email protected]は次のように書いています。

議論はすべてIP番号とポッドについてですが、私の経験では
Mongo＆ZookeeperのIPポッドは無関係のままにする必要があります（ペットにならないでください）。
このボリュームは記録するため、永続的な_volume_には呼び数が必要です
他の「ボリューム」のIP番号。 そのボリュームをマウントするポッドは何でも
その記録されたIP番号をなんとかして使用できるはずです。 ボリュームは
ペット..。

ボリュームに対して時間的に一定であり、ポッドに割り当てられているDNS名
ボリュームをマウントすることは私が思うに長い道のりを来るでしょう。

Mongo＆ZKのアンサンブルメンバーシップの変更には、常にカスタムが必要です
実行するコードは、他のほとんどのアンサンブルでも同じであると思います。 そう
レプリケーションコントローラーの名前が間違っています。これらのペットにはさらにメンバーが必要です
船のコントローラー。 メンバーシップコントローラーは、
初期設定、アンサンブルへの段階的な変更、そして最後に
それを殺します。

マウントされたボリュームに基づいて一定のDNS名が与えられ、
アンサンブルメンバーシップをカスタムコードで処理すると、次のことが可能になります。
私が思うに、これらのタイプのシステムを処理します。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -142640825
。

/ ping

https://hub.docker.com/r/elevy/zookeeper/で、既存の機能を使用してKubernetesでZKクラスターを設定する例を見つけることができ

@smarterclayton @thockin

数日前にオフィスに自転車で行ったときの考え：

最初に説明したように、私は現在、これをPetSetコントローラー、または人々がそのように考えたい場合はShardSetコントローラーとして考えています： //github.com/kubernetes/kubernetes/issues/260# issuecomment- 57671926。

私たちが対処しようとしているのは、類似したペットがN匹いる場合ですが、それでもペットであり、代替可能ではありません。

これをReplicationControllerに結び付けることは、一部にはReplicationControllerにテンプレートが1つしかないため、まだ機能しないと思います。 PetSet / ShardSetは、DeploymentやDaemonSetのように、より高レベルの抽象化である必要があります。 PetSetは、インスタンスごとに1つのPodTemplateオブジェクトを生成する可能性があります。

DeploymentAPIを再利用できるとは思いません。 特に、現在kubectlとDeploymentにあるローリングアップデートのロールアウト戦略は、この場合は機能しません。 ほとんどのペットはおそらく更新の再作成を望んでおり、ローリング更新が必要な場合は、シャード数を超えるサージを処理できず、更新の順序に注意を払うことになります。

私はこのアイデアが好きですが、ボトムアップのID割り当てが機能するとは思いません。 割り当てられたIDをプールに戻すことと、新しいIDを割り当てることによる、競合状態が多すぎます。 JobでRabbitMQの使用を検討しているときに、 @ erictuneが遭遇した問題とよく似ています。

コントローラーとIDプール、またはコントローラーとサービスなど、複数の場所でPetSetのスケールを表現したくないのは、スケーリングが難しい/厄介になるためです。

この場合、汎用テンプレートは必要ないと思います。 関連するストレージと予測可能で耐久性のあるネットワークIDを使用してポッドをスタンプする必要があります。 ボーグでは大まかな同等物で十分です。 したがって、私は＃12450に沿ったものに強く傾いていますが、ポッド自体ではなくポッドテンプレートに傾いています。 おそらく、podTemplateに加えてpersistentVolumeClaimTemplatesの配列です。 とにかくそれらを非推奨にしたいので、私はすべてのクラウドプロバイダー固有のボリュームソースの代わりに派手なものを追加したくありません。 PVCに追加の要件やセレクターを追加するだけで十分です。 また、ある時点で永続ボリュームを何らかの方法でプロビジョニングできる必要があります。

最終的にはローカルストレージについて何かをする必要がありますが、それは分離可能だと思います。

次に、上記のホスト名とヘッドレスサービスの変更をここで行います。
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -133318903

現在提案に取り組んでおり、まもなくドラフトが作成されます。

提案はhttps://github.com/kubernetes/kubernetes/pull/18016にあります

...では、PetSetはどこにありますか？

Kubernetes上にHAデータベースソリューションを構築しています。 一部の、特にシングルマスターデータベースでは、特定のポッドからのイベントに基づいて特定のポッドにマップするエンドポイントを備えたサービスが必要です。 例えば：

1. サービス「postgres」はラウンドロビンをReplicaSet内のすべてのポッドにマップしますが、サービス「postgres-master」は1つのポッドにのみマップします。
2. マスターポッドが死にます。
3. フェイルオーバーが発生します。 フェイルオーバーの一環として、新しいマスターはAPIを介してKube-masterを更新し、postgres-masterサービスを「取得」します。
4. これを行うと、postgres-masterへの以前の接続はすべて終了します。

@jberkus PetSetsを有効にするための最初のアルファコードがマージされたか、マージが保留されています。 私のチームの@ingvagabundは、PetSetを利用した例をまとめて、何がうまく機能し、何がまだ改善が必要かを確認し始めます。 まとめてテストしたい特定のユースケースがある場合は、彼に連絡することをお勧めします。

@ncdc v1.3ではこれのためにすべてが行われていますか？ 提案が統合されておらず、これを参照している他のPRがしばらくないため、不明です。

@bprashanth ^

私たちはe2esを上陸させ、例に取り組み続けています。 アルファ版です
今、しかし提案はアルファフィードバックの最初のラウンドを取るつもりです
マージする前に。

2016年5月19日午前10時25分、ブランドンフィリップス[email protected]
書きました：

@ncdc https://github.com/ncdcこれはv1.3ですべて実行されていますか？ です
提案が統合されておらず、他のPRがないため、不明確
しばらくこれを参照します。

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示してください
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -220340104

このためのドキュメントはどこにありますか？ データベースフェイルオーバーのユースケースについてテストしたいと思います。

ああ、私たちに必要なのはpostgresの専門家です:)

例については、 https：//github.com/kubernetes/contrib/pull/921を参照して@philips）。 私はまだドキュメントを書いていませんが、1.3の最後の数週間に向けて書きます（金曜日にコードが完成してからリリースするまでまだ5週間です）。

かなり一般的であるため、postgresを使用してフェイルオーバーを自動化してみてください。 現在のところ、それは私が望むほど簡単ではないことを認めます。おそらく番犬が必要です。 @jberkusどのパターンがそれを簡単にするかについてのフィードバックを聞きたいです。

今日のペットセットを簡単に確認すると、ネットワークにマウントされたボリュームと一致する一貫したネットワークID（DNS、ホスト名）と注文保証が提供されます。 したがって、 replicas: 3でペットセットを作成すると、次のようになります。
管理サービス：*。galear.default.svc.cluster.local
mysql-0-volume0
mysql-1-volume1：0が実行され準備が整うまで開始されません
mysql-2-volume2：0まで開始せず、1は準備ができています

ポッドは、管理サービスの下に挿入されたSRVレコードを検索することにより、サービス検出にDNSを使用できます。 これが、この単純なポッドの機能です： https ：

ボリュームは動的プロビジョニングツール（https://github.com/kubernetes/kubernetes/blob/release-1.2/examples/experimental/persistent-volume-provisioning/README.md）によってプロビジョニングされるため、ボリュームがない場合はクラスタで実行されているが、プロトタイプを作成したい場合は、単にemptyDirを使用できます。 「data-gravity」（https://github.com/kubernetes/kubernetes/issues/7562）のケースはまだ機能していませんが、最終的には機能します。

現在、initコンテナを介して、ピアのリストを含む「開始時」の通知を配信する方が簡単であることを付け加えておきます。 「変更時」の通知も必要であることは明らかです。 現在、クラスターメンバーシップの変更に気付くには、カスタムpid1を使用する必要があります。 共有されたpid名前空間は、サイドカーを使用できるため、これを簡単にする可能性があります。これも、正しく機能する必要があるものです。

私はウォッチドッグを持っています、それは私が望むよりも複雑なサービスフェイルオーバーです。 テストします、ありがとう！

etcdもサポートする必要があるので、将来的にはたくさんのテストがあるかもしれません。

@ncdcこのためのアルファコードのステータスは何ですか？ テスト/実装を開始したいのですが。 ここですぐにcassandraクラスターをデプロイする必要があります。 私は既存のコードベースでそれを行うことができますが、ペットセットのものをテストするのはいいことです。

HEADからビルドすれば入手できます

@bprashanthはメインリポジトリにマージされましたか？ まことにありがとうございます。 しましょう。

https://github.com/kubernetes/contrib/tree/master/pets

注釈文字列にyamlを埋め込みますか？ oof、ouch :(。ありがとう、カサンドラセットの作成を調査します。

それはjsonです。 これは、GAオブジェクト（ポッド内のinitコンテナー）に追加されたアルファ機能です。
@chrislovecnmはCassandraに取り組んでおり、彼を待ちたいだけかもしれません。

@paralinは私が取り組んでいるものです。 今すぐドキュメントを作成してk8sリポジトリに取り込む時間はありませんが、それは長期的な計画です。 https://github.com/k8s-for-greeks/gpmr/tree/master/pet-race-devops/k8s/cassandraローカルでHEADで作業しています。

デモの最新のC *イメージはうまく機能します。

より多くのドキュメントのために未解決の問題があります。 ウインクウインク、ナッジ@bprashanth

etcdクラスターを使用したPetSetsの例[1]。

[1] https://github.com/kubernetes/contrib/pull/1295

レビューが終了したら、必ず提案ドキュメントで設計の質問をキャプチャしてください

2016年6月30日には、1：25 AMで、月Chaloupkaの[email protected]は書きました：

etcdクラスターを使用したPetSetsの例[1]。

[1] kubernetes / contrib＃1295
https://github.com/kubernetes/contrib/pull/1295

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -229594658、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe/ABG_pwVgiaLvRKbtcJG9wzMEZcCNgae8ks5qQ32PgaJpZM4CIC6g
。

ペットセットのドキュメントはhttps://github.com/kubernetes/kubernetes.github.io/blob/release-1.3/docs/user-guide/petset.mdとhttps://github.com/kubernetes/kubernetes.githubです。 io / tree / release-1.3 / docs / user-guide / petset / bootstrapping 、この問題を閉じて、誰かが反対しない限り、ペットセットをベータ版に移行することに対処する新しい問題を開く予定です。

https://github.com/kubernetes/kubernetes/issues/28718