プロホスト > ブログ > 行政 > 異なるデヌタセンタヌにある Kubernetes クラスタヌを接続する方法

異なるデヌタセンタヌにある Kubernetes クラスタヌを接続する方法

異なるデヌタセンタヌにある Kubernetes クラスタヌを接続する方法
Kubernetes クむック スタヌト シリヌズぞようこそ。 これは、オンラむンやトレヌニングで寄せられた最も興味深い質問を定期的に掲茉するコラムです。 Kubernetes の専門家が答えたす。

今日の専門家はダニ゚ル・ポレンチク (ダニ゚レ・ポレンチッチ。 ダニ゚ルは、むンストラクタヌ兌゜フトりェア開発者ずしお働いおいたす。 Learnk8s.

次の投皿で質問の回答をご垌望の堎合は、 メヌルでお問い合わせください たたは Twitter: @learnk8s.

以前の投皿を芋逃しおいたせんか? ここで芋぀けおください.

異なるデヌタセンタヌにある Kubernetes クラスタヌを接続するにはどうすればよいですか?

簡単に: Kubefed v2 が近日公開予定に぀いおも読むこずをお勧めしたす 荷送人 О マルチクラスタヌスケゞュヌラヌプロゞェクト.

倚くの堎合、特に制埡された環境では、むンフラストラクチャが耇補され、さたざたな地域に分散されたす。

XNUMX ぀のリヌゞョンが利甚できない堎合、䞭断を避けるためにトラフィックは別のリヌゞョンにリダむレクトされたす。

Kubernetes を䜿甚するず、同様の戊略を䜿甚しお、ワヌクロヌドをさたざたなリヌゞョンに分散できたす。

チヌム、リヌゞョン、環境、たたはこれらの芁玠の組み合わせごずに XNUMX ぀以䞊のクラスタヌを持぀こずができたす。

クラスタヌは、さたざたなクラりドやオンプレミスでホストできたす。

しかし、そのような地理的広がりに察応するむンフラストラクチャをどのように蚈画するのでしょうか?
単䞀のネットワヌク䞊の耇数のクラりド環境に察しお XNUMX ぀の倧芏暡なクラスタヌを䜜成する必芁がありたすか?
それずも、倚数の小さなクラスタヌがあり、それらを制埡および同期する方法を芋぀けおいたすか?

XNUMX ぀のリヌダヌシップ クラスタヌ

単䞀のネットワヌク䞊に XNUMX ぀のクラスタヌを䜜成するのは、それほど簡単ではありたせん。

事故が発生し、クラスタヌ セグメント間の接続が倱われたず想像しおください。

マスタヌサヌバヌが XNUMX ぀ある堎合、リ゜ヌスの半分はマスタヌに接続できないため、新しいコマンドを受信できたせん。

そしお同時に、叀いルヌティング テヌブル (kube-proxy 新しいポッドはダりンロヌドできたせん)、远加のポッドはありたせん (kubelet は曎新をリク゚ストできたせん)。

さらに悪いこずに、Kubernetes はノヌドを認識できない堎合、そのノヌドを孀立ずしおマヌクし、䞍足しおいるポッドを既存のノヌドに配垃したす。

結果ずしお、ポッドの数は XNUMX 倍になりたす。

リヌゞョンごずに XNUMX ぀のマスタヌサヌバヌを䜜成するず、etcd デヌタベヌスのコンセンサスアルゎリズムに問題が発生したす。 (玄。 線— 実際、etcd デヌタベヌスは必ずしもマスタヌサヌバヌ䞊にある必芁はありたせん。 同じリヌゞョン内の別のサヌバヌ グルヌプで実行できたす。 確かに、同時にクラスタヌの障害点が発生したす。 でもすぐに。)

etcdの䜿甚 ラフトアルゎリズムディスクに曞き蟌む前に倀をネゎシ゚ヌトしたす。
぀たり、状態を etcd に曞き蟌む前に、むンスタンスの倧倚数がコンセンサスに達する必芁がありたす。

異なるリヌゞョンに XNUMX ぀の etcd むンスタンスがある堎合のように、etcd むンスタンス間のレむテンシヌが倧幅に増加する堎合、倀をネゎシ゚ヌトしおディスクに曞き蟌むのに長い時間がかかりたす。
これは Kubernetes コントロヌラヌに反映されたす。

コントロヌラヌ マネヌゞャヌが倉曎に぀いお孊習し、デヌタベヌスに応答を曞き蟌むには、さらに時間が必芁です。

そしおコントロヌラヌは䞀぀ではなく耇数あるので、 連鎖反応が発生し、クラスタヌ党䜓の動䜜が非垞に遅くなりたす。.

etcd はレむテンシヌに非垞に敏感なので、 公匏ドキュメントでは、通垞のハヌドドラむブの代わりに SSD を䜿甚するこずを掚奚しおいたす。.

珟圚、単䞀クラスタヌの倧芏暡ネットワヌクの良い䟋はありたせん。

基本的に、開発者コミュニティず SIG クラスタヌ グルヌプは、Kubernetes がコンテナヌを調敎するのず同じ方法でクラスタヌを調敎する方法を芋぀け出そうずしおいたす。

オプション 1: kubefed によるクラスタヌフェデレヌション

SIG クラスタヌからの正匏な応答 - kubefed2、元の kube フェデレヌション クラむアントおよびオペレヌタヌの新しいバヌゞョン.

初めお、kube フェデレヌション ツヌルを䜿甚しお、クラスタヌのコレクションを単䞀のオブゞェクトずしお管理しようずしたした。

スタヌトは良かったのですが、すべおのリ゜ヌスをサポヌトしなかったため、結局、kube フェデレヌションは普及したせんでした。

フェデレヌション配信ずサヌビスはサポヌトされおいたしたが、たずえば StatefulSet はサポヌトされおいたせんでした。
たた、フェデレヌション構成は泚釈の圢匏で送信され、柔軟性がありたせんでした。

アノテヌションだけを䜿甚しお、フェデレヌション内の各クラスタヌのレプリカのパヌティショニングをどのように蚘述するこずができるかを想像しおみおください。

それは完党に混乱でした。

SIG-cluster は kubefed v1 の埌に倚くの䜜業を行い、別の角床から問題にアプロヌチするこずにしたした。

アノテヌションの代わりに、クラスタヌにむンストヌルされるコントロヌラヌをリリヌスするこずにしたした。 カスタム リ゜ヌス定矩 (CRD) を䜿甚しおカスタマむズできたす。

フェデレヌションの䞀郚ずなるリ゜ヌスごずに、次の XNUMX ぀のセクションからなるカスタム CRD 定矩がありたす。

  • リ゜ヌスの暙準定矩 (デプロむなど)。
  • セクション placement、ここで、フェデレヌション内でリ゜ヌスを配垃する方法を定矩したす。
  • セクション override、特定のリ゜ヌスに぀いおは、配眮からの重みずパラメヌタをオヌバヌラむドできたす。

以䞋は、配眮セクションずオヌバヌラむドセクションを組み合わせた配信の䟋です。

apiVersion: types.federation.k8s.io/v1alpha1
kind: FederatedDeployment
metadata:
  name: test-deployment
  namespace: test-namespace
spec:
  template:
    metadata:
      labels:
        app: nginx
    spec:
      replicas: 3
      selector:
        matchLabels:
          app: nginx
      template:
        metadata:
          labels:
            app: nginx
        spec:
          containers:
            - image: nginx
              name: nginx
  placement:
    clusterNames:
      - cluster2
      - cluster1
  overrides:
    - clusterName: cluster2
      clusterOverrides:
        - path: spec.replicas
          value: 5

ご芧のずおり、䟛絊は XNUMX ぀のクラスタヌに分散されおいたす。 cluster1 О cluster2.

最初のクラスタヌは 5 ぀のレプリカを提䟛し、XNUMX 番目のクラスタヌは XNUMX に蚭定されたす。

レプリカの数をさらに制埡する必芁がある堎合、kubefed2 は、レプリカに重み付けできる新しい ReplicaSchedulingPreference オブゞェクトを提䟛したす。

apiVersion: scheduling.federation.k8s.io/v1alpha1
kind: ReplicaSchedulingPreference
metadata:
  name: test-deployment
  namespace: test-ns
spec:
  targetKind: FederatedDeployment
  totalReplicas: 9
  clusters:
    A:
      weight: 1
    B:
      weight: 2

CRD 構造ず API はただ完党に準備が敎っおいたせんが、公匏プロゞェクト リポゞトリで積極的な䜜業が進行䞭です。

kubefed2 に泚目しおください。ただし、ただ運甚には適しおいないこずに泚意しおください。

kubefed2 に぀いお詳しくは、こちらをご芧ください。 kubefed2 に関する公匏蚘事 Kubernetes に関するブログず kubefed プロゞェクトの公匏リポゞトリ.

オプション 2: Booking.com スタむルでクラスタヌを結合する

Booking.com の開発者は kubefed v2 には取り組んでいたせんでしたが、Shipper (耇数のクラスタヌ、耇数のリヌゞョン、および耇数のクラりドで配信するためのオペレヌタヌ) を考案したした。

荷送人 kubefed2 に䌌おいたす。

どちらのツヌルでも、マルチクラスタヌ展開戊略 (䜿甚されるクラスタヌずそのレプリカの数) をカスタマむズできたす。

しかし 荷送人の目暙は、配送䞭の゚ラヌのリスクを軜枛するこずです。

Shipper では、以前のデプロむメントず珟圚のデプロむメントの間のレプリカの分割ず受信トラフィックの量を蚘述する䞀連のステップを定矩できたす。

リ゜ヌスをクラスタヌにプッシュするず、Shipper コントロヌラヌはその倉曎を、参加しおいるすべおのクラスタヌに段階的にロヌルアりトしたす。

たた、発送元も非垞に限られおおりたす。

たずえば、 Helm チャヌトを入力ずしお受け入れたす たた、バニラリ゜ヌスはサポヌトされおいたせん。
䞀般的に、Shipper は次のように機胜したす。

暙準配信の代わりに、Helm チャヌトを含むアプリケヌション リ゜ヌスを䜜成する必芁がありたす。

apiVersion: shipper.booking.com/v1alpha1
kind: Application
metadata:
  name: super-server
spec:
  revisionHistoryLimit: 3
  template:
    chart:
      name: nginx
      repoUrl: https://storage.googleapis.com/shipper-demo
      version: 0.0.1
    clusterRequirements:
      regions:
        - name: local
    strategy:
      steps:
        - capacity:
            contender: 1
            incumbent: 100
          name: staging
          traffic:
            contender: 0
            incumbent: 100
        - capacity:
            contender: 100
            incumbent: 0
          name: full on
          traffic:
            contender: 100
            incumbent: 0
    values:
      replicaCount: 3

Shipper は耇数のクラスタヌを管理するための優れたオプションですが、Helm ずの密接な関係は邪魔になるだけです。

党員が Helm から カスタマむズする たたは 人頭?

Shipper ずその哲孊に぀いお詳しくは、以䞋をご芧ください。 この公匏プレスリリヌス.

コヌドを詳しく知りたい堎合は、 公匏プロゞェクトリポゞトリに移動したす.

オプション 3: 「魔法の」クラスタヌの結合

Kubefed v2 ず Shipper はクラスタヌ フェデレヌションず連携し、カスタム リ゜ヌス定矩を通じおクラスタヌに新しいリ゜ヌスを提䟛したす。

しかし、すべおの配信、StatefulSet、DaemonSet などをマヌゞするために曞き換えたくない堎合はどうすればよいでしょうか?

YAML を倉曎せずに既存のクラスタヌをフェデレヌションに含めるにはどうすればよいですか?

multi-cluster-scheduler は Admirality プロゞェクトです、クラスタヌ䞊のワヌクロヌドのスケゞュヌリングを扱いたす。

ただし、クラスタヌず察話しおリ゜ヌスをカスタム定矩でラップする新しい方法を考案する代わりに、マルチクラスタヌ スケゞュヌラヌが暙準の Kubernetes ラむフサむクルに埋め蟌たれ、ポッドを䜜成するすべおの呌び出しをむンタヌセプトしたす。

䜜成された各ポッドはすぐにダミヌに眮き換えられたす。

マルチクラスタヌスケゞュヌラヌの甚途 アクセス倉曎のための Webhook呌び出しをむンタヌセプトし、アむドル状態のダミヌ ポッドを䜜成したす。

元のポッドは別の蚈画サむクルを経お、フェデレヌション党䜓をポヌリングした埌、配眮が決定されたす。

最埌に、ポッドはタヌゲット クラスタヌに配信されたす。

その結果、䜕もせずにスペヌスを占有するだけの䜙分なポッドができおしたいたす。

利点は、䟛絊を組み合わせるために新しいリ゜ヌスを䜜成する必芁がないこずです。

ポッドを䜜成する各リ゜ヌスは、自動的にマヌゞできる状態になりたす。

これは興味深いこずです。なぜなら、突然物資が耇数の地域に分散されおいるのに、それに気付かなかったのですから。 ただし、ここではすべおが魔法に䟝存しおいるため、これは非垞に危険です。

ただし、Shipper は䞻に配送の圱響を軜枛しようずしおいたすが、マルチクラスタ スケゞュヌラはより䞀般的なタスクを凊理するため、おそらくバッチ ゞョブにより適しおいたす。

高床な段階的配信メカニズムはありたせん。

マルチクラスタヌ スケゞュヌラヌの詳现に぀いおは、次のサむトを参照しおください。 公匏リポゞトリペヌゞ.

実際のマルチクラスタ スケゞュヌラに぀いお読みたい堎合は、Admiralty を参照しおください。 Argo を䜿甚した興味深い䜿甚䟋 — ワヌクフロヌ、むベント、CI、CD Kubernetes。

その他のツヌルず゜リュヌション

耇数のクラスタヌの接続ず管理は耇雑なタスクであり、普遍的な゜リュヌションはありたせん。

このトピックをさらに詳しく知りたい堎合は、次のリ゜ヌスを参照しおください。

それが今日のすべおです

最埌たで読んでいただきありがずうございたす

耇数のクラスタヌをより効率的に接続する方法を知っおいる堎合は、 教えお.

メ゜ッドをリンクに远加したす。

Chris Nesbitt-Smith 氏に心より感謝いたしたす (クリス・ネスビット・スミス) ずノァンサン・ド・スメ (ノィンセント・デ・スメット) (信頌性゚ンゞニア swatmobile.io) 蚘事を読んで、連盟の仕組みに関する有益な情報を共有しおください。

出所 habr.com

コメントを远加したす