SpiderPool - クラウドネイティブコンテナネットワーク IPAM プラグイン

SpiderPool は、コンテナネットワークのランディング実践の蓄積から派生した、「Daocloud Daoke」のオープンソースネイティブコンテナネットワーク IPAM プラグイン( github: https://github.com/spidernet-io/spiderpool) です。主にアンダーレイ CNI を使用してコンテナを実装するために使用されます。クラウドプラットフォームは IP を細かく管理し、割り当てます。

SpiderPool
誕生の背景

従来のアプリケーションのクラウドネイティブ化

まず、製造、教育、エネルギー、その他の企業などの一部の伝統的な業界では、従来のアプリケーションは通常、クラウドに直接アップロードされます。これらのアプリケーションはマイクロサービス化されておらず、依然として特定の固定 IP を介してアクセスする必要があり、厳格なファイアウォール制御など、そのような IP の強力な管理と制御が必要です。したがって、このようなシナリオの要件を満たすには、より柔軟で効率的な IP 管理機能が必要です。

第 2 に、従来のアプリケーションマイクロサービスのプロセスでは、ユーザーは一部のアプリケーションを徐々にコンテナ化し、一部のコンテナ化されたアプリケーションでは、クラスター内外の相互接続を実現するために外部アクセス IP を提供する必要があります。 IP アドレス.IP。

さらに、外部アクセス IP の強力な管理および制御要件に基づいて、お客様の実装実践では、アンダーレイ CNI を通じて割り当てられた IP を従来の物理サブネットに接続する必要があり、外部サービスを直接提供する計画を立てており、セキュリティを考慮しています。コンテナネットワークの場合、ファイアウォールにインストールする必要があり、使用する IP を設定して解放する必要があり、全体的な IP 管理プロセスと仕様は長く複雑です。また、アンダーレイ CNI の IP リソースは 比較的希少であるため、アンダーレイ IP の強力な割り当てと制御を実行する必要があり、 IP アドレスの解放と割り当てに失敗した場合は、リソースの無駄を防ぐために適切なタイミングでリサイクルする必要があります。。

クラウドネイティブのコンテナネットワークは次の課題に直面していることがわかります。

固定 IP と外部 IP に対する強い需要と、柔軟で効率的な IPAM メカニズムに対する強い需要があります。

02 アンダーレイ CNI
とオーバーレイ CNI の特性

SpiderPool IPAM プラグインを紹介する前に、アンダーレイ CNI とオーバーレイ CNI の違いを比較してみましょう。

アンダーレイ CNI IP 管理機能

1. ポッドは、NAT 変換なしで物理ネットワーク計画に接続され、クラスターの外部と直接通信します。

2. 使用する IP はファイアウォール経由で開く必要があり、強力な制御が必要で、固定ポッド IP が必要です。

3. アンダーレイ CNI の IP リソースは限られているため、クラスター内外での IP 競合の問題が浮き彫りになり、IP のリサイクルが間に合わないと、新しいポッドの起動に失敗します。

オーバーレイ CNI IP 管理機能

1. Pod Subnet は独自に計画されており、Pod とクラスター間の外部通信は NAT で処理する必要があり、ノード IP のみが外部に公開され、Pod IP は外部に公開される必要はありません。

2. オーバーレイ CNI IP アドレスの数が十分であり、各ノードが独立して CIDR ブロックを計画します。

3. ファイアウォールは Pod IP を認識できないため、外部へのアクセスを提供する際のセキュリティリスクがなく、強力な IP リソースの管理と制御のためにファイアウォールを開く必要もありません。ポッド IP の要件。

4. オーバーレイ IP アドレスの割り当てでは、アンダーレイネットワーク内の競合を無視でき、漏洩した IP の再利用の問題はほとんど影響しません。

比較すると、オーバーレイ CNI は IP 管理の要件が弱く、リソースが豊富であるため、クラスター内で IP の競合が発生しても、重大な結果を引き起こすことはありません。

アンダー レイ CNI ネットワークソリューション、IPAM または弱い IP 管理機能 (SRI-OV、Macvlan、IPVLAN、OVS-CNI など) が欠如している CNI ソリューションで、強力な IP 管理や IP などの上記の複雑なシナリオに直面した場合競合管理その場合、できることは何もありません。

SpiderPool は、上記のシナリオ要件を満たすことに特化したオープンソース CNI IPAM プロジェクトです。SpiderPool と Underlay CNI を組み合わせて、クラウド上で生産できるクラウドネイティブネットワークソリューションを作成します。「DaoCloud」によって開始された最新の DCE 5.0 が商用化されましたSpiderPool、アンダーレイ CNI (Macvlan、SRI-OV など) の IPAM ソリューションとして。

03 SpiderPool
関数

上記の背景を踏まえ、SpiderPool は主に以下の課題に基づいて設計されています。

1. アンダーレイ CNI と組み合わせて外部アクセス IP を提供し、アプリケーションの負荷を満たし、外部アクセス機能を提供します。

2. サブネット管理、IP 管理、物理層ファイアウォールのセキュリティ管理と制御を含む、強力な IP 管理と制御機能を提供します。

3. IP 固定機能。ビジネスアプリケーションが再起動されると、ビジネスアプリケーションに割り当てられた IP は引き続き予約されます。

4. IP 競合対策 (IP 割り当ておよび IP 回復メカニズムの強化)。

SpiderPool 機能リスト

特徴

IP プールのノードアフィニティ

シーン

ノードが異なれば、利用可能なサブネットも異なる場合があります。例:

1. 同じデータセンター内で、クラスターに接続されたノードは異なるサブネットに属します。

2. 単一クラスター内で、ノードは異なるデータセンターにまたがります。

上記のシナリオでは、同じアプリケーションの異なるコピーが異なるノードにスケジュールされている場合、異なるサブネットアンダーレイ IP アドレスを割り当てる必要があります。

プラン

IP プール CR には、IP プールを実現するためのノードラベルセレクターを設定するために使用される、nodeAffinity フィールドがあります。

ノードとのアフィニティ。ポッドがノードにスケジュールされている場合、IPAM プラグインはアフィニティ IP プールから IP アドレスを割り当てることができます。

IP プールの作成例:

apiVersion: spiderpool.spidernet.io/v1kind: SpiderIPPoolmetadata:  name: master-ipv4-ippoolspec:  ipVersion: 4  subnet: 172.18.41.0/24  ips:    - 172.18.41.40-172.18.41.42  nodeAffinity:  #创建 IP Pool 时，添加节点亲和性    matchExpressions:      - {key: node-role.kubernetes.io/beijing, operator: Exists}

IPプールのアプリケーション・アフィニティ

シーン

厳しく規制されたネットワークシナリオでは、ファイアウォールのリリースポリシーに一致するように、すべての Pod に固定 IP アドレス範囲の IP アドレスをローテーションで割り当てることができます。

プラン

SpiderPool IP プールの IP コレクションは大きくても小さくてもよいため、IP プールの podAffinity の設定と組み合わせることで、同じグループまたは複数のアプリケーショングループのアフィニティバインディングを実現できます。これにより、IP 管理方法の統一性が確保されるだけでなく、しかし、「アプリケーションの拡張」と「IP アドレスの拡張」も分離され、アプリケーションが使用する IP の範囲も固定されます。

例

apiVersion: spiderpool.spidernet.io/v1kind: SpiderIPPoolmetadata:  name: master-ipv4-ippoolspec:  ipVersion: 4  subnet: 172.18.41.0/24  ips:    - 172.18.41.40-172.18.41.42  podAffinity: # 创建 IP Pool 时增加 Pod 亲和性    matchExpressions:      - {key: app-dao2048, operator: Exists}

IP プールの名前空間アフィニティ

シーン

IP プールは、同じまたは複数のネームスペースの下でアプリケーションのアフィニティを実現し、無関係な NS を持つアプリケーションを拒否できます。

プラン

IPプールのnamespaceAffinityを設定することで、同一または複数のテナントのアフィニティを実現し、条件を満たすアプリケーションにIPプールからIPアドレスを割り当てることができます。

例

apiVersion: spiderpool.spidernet.io/v1kind: SpiderIPPoolmetadata:  name: master-ipv4-ippoolspec:  ipVersion: 4  subnet: 172.18.41.0/24  ips:    - 172.18.41.40-172.18.41.42  namespaceAffinity:  # 创建 SpiderPool 时增加 Namespace 亲和性    matchExpressions:      - {key: ns-spider, operator: Exists}

複数のIPプールのバックアップ

シーン

IP プール内の IP アドレスがすべて割り当てられ、サブネット内の IP がすべて使い果たされると、容量拡張時に関連アプリケーションが失敗するため、複数のスタンバイ IP プールを設定できます。

プラン

解決策 1: 既存の IP プールにさらに IP アドレスリソースを拡張します。

解決策 2: 複数の IP プールをアプリケーションにバインドする現在の IP プールの IP アドレスが不足すると、IPAM プラグインは後部の IP プールから IP アドレスを割り当てようとします。

例

annotations:  ipam.spidernet.io/ippool: |-    {
   
         "interface": "eth0",      "ipv4": ["default-ipv4-ippool", "backup-ipv4-ippool"]  #创建 工作负载时，指定多个 IP Pool    }

固定IPプールの自動割り当て

シーン

インフラストラクチャ管理者は、使用可能な IP アドレスを提供することだけを望んでおり、「固定 IP 範囲」で IP プールを作成することを心配したくないのに対し、アプリケーション管理者は IP アドレスの値には関心がなく、単に IP アドレスを取得することだけを望んでいます。指定された数の IP アドレス。したがって、責任を分割すると、両方の当事者が最も単純なクラスター操作のみを実行することになります。したがって、「固定 IP 範囲」IP プールの作成は、どちらの当事者も引き受けたくない作業負荷となっています。

さらに、ワークロードが固定 IP をすべて使い切ってローリングリリースを実行すると、IP が残っていないため、新しいポッドは起動できません。

プラン

現時点では、Spiderpool はアプリケーションの IP プールを自動的かつ動的に作成し、IP プールをバインドし、IP プールを再利用することができます。これにより、2 つの部門の担当者の責任の分離が解決されるだけでなく、「固定 IP 範囲」の運用も簡素化されます。 IP アドレスの管理コストを大幅に削減します。

さらに、固定 IP の枯渇によりローリングリリースが失敗するシナリオのために、Spiderpool は固定 IP 機能に基づいて Elastic IP の数を提供します。ワークロード (Deployment、ReplicaSet、DaemonSet、StatefulSet、Job、CronJob に限定) を作成するときに、 )、その PodTemplateSpec.アプリケーションが正常にリリースされるように、アノテーションで特定の数の Elastic IP を指定します。

例

annotations:  ipam.spidernet.io/subnet: '{"ipv4": ["subnet-demo-v4"], "ipv6": ["subnet-demo-v6"]}'  ipam.spidernet.io/ippool-ip-number: "+2" # 当为 “+2”时为弹性 IP ，当 输入为“2”时为指定固定 IP 数量  ipam.spidernet.io/ippool-reclaim: "true"

Statefulset 固定 IP

シーン

デプロイメントコントローラーとステートフルセットコントローラーには、固定 IP アドレスに対する異なる要件があります。

1. Statefulset の場合、Pod レプリカの再起動の前後で Pod 名は同じままである必要がありますが、Pod UUID は変更され、ステートフルであるため、アプリケーション管理者は、再起動の前後で Pod に同じ IP が割り当てられることを望んでいます。

2. デプロイメントでは、ポッドのコピーが再起動される前後でポッド名とポッド UUID が変更されるため、ステートレスになります。したがって、古いポッドと新しいポッドで同じ IP を使用する必要はありません。デプロイメント内のすべてのコピーが同じ IP を使用するようにするため、IP は特定の IP 範囲内で固定されます。

プラン

Spiderpool は、Statefulset Pod が再起動および再構築のシナリオで同じ IP アドレスを引き続き取得できるようにします。

注: Statefulset を「縮小」から「拡張」に変更するプロセスでは、新しく拡張された Pod が以前に縮小された Pod の IP アドレスを取得できるという保証はありません。

IP プールの作成例:

apiVersion: apps/v1kind: StatefulSetmetadata:  name: demo-sts  namespace: defaultspec:  serviceName: "demo-sts-svc"  replicas: 1  selector:    matchLabels:      app: demo-sts  template:    metadata:      labels:        app: demo-sts    spec:      containers:        - image: busybox          imagePullPolicy: IfNotPresent          name: demo-sts          command: ["/bin/sh", "-c", "trap : TERM INT; sleep infinity & wait"]

複数の NIC を備えたポッド

シーン

Multus プロジェクトを通じて、複数の CNI ネットワークカードをポッドに挿入でき、異なる IP プールを使用するには異なるネットワークカードを割り当てる必要があるため、異なるサブネットの下で IP アドレスを割り当て、インターフェイスのデフォルトルートを柔軟に指定できます。。

プラン

Multus の NetworkAttachmentDefinition 構成と組み合わせることができ、複数の CNI 構成セットを異なる IP プールで構成できます。

kind: NetworkAttachmentDefinitionspec:  config: |    '{ "ipam": { "default_ipv4_ippool": ["ippool1"], "type": "spiderpool" } .... }'

Pod Annotaiton と組み合わせて、異なる IP プールの IP アドレスを各ネットワークカードに割り当てることができます。

ipam.spidernet.io/ippools: |-  [{
   
         "interface": "eth0", "ipv4": ["v4-ippool1"],  "ipv6": ["v6-ippool1"], "cleangateway": true   },{
   
         "interface": "eth1", "ipv4": ["v4-ippool2"], "ipv6": ["v6-ippool2"], "cleangateway": false  }]

IP リークの回避

チャレンジ

実際には、Macvlan やその他の CNI が直接使用されている場合、いくつかの同時実行性の高いシナリオでは、Docker によってコンテナー用に作成されたネットワーク名前空間が、コンテナーの停止後にカーネルによって正しくリサイクルされない可能性が非常に高くなります。 IP データの混乱、IP の再分類、誤分類、競合、その他の異常現象を引き起こします。ただし、Macvlan などの CNI は IPAM リサイクル機能が比較的弱いため、サービスポッド IP の競合が発生し、サービスアプリケーションにアクセスできなくなります。さらに、ネットワーク名前空間漏洩の問題は、特定と再現が難しく、発生原因は多岐にわたり、根本原因から解決することができないことが分かりました。

ポッドの障害、再起動、再構築などのシナリオでは、古いポッドコピーの IP アドレスが適時に IP プールにリサイクルされるかどうかが、新しいポッドコピーの起動の成功または失敗に影響します。IPAM コンポーネントの観点から見ると、IP リソースが一部の「ゾンビポッド」によって占有され、その結果、使用可能な IP が減少します。

オーバーレイ IPAM シナリオでは、CIDR 範囲が広いため、この問題は顕著ではありません。アンダーレイシナリオでは、IP リソースが制限されており、一部のアプリケーションでは固定の IP アドレス範囲が必要です。この問題は、アプリケーションの正常な動作に影響します。

プラン

SpiderPool は、上記のシナリオ要件を満たし、上記の IP 競合を回避することに特化したオープンソース CNI IPAM プロジェクトです。SpiderPool とアンダーレイ CNI を組み合わせることで、イベントベースの定期的なデュアルリカバリメカニズムにより、最初のリリース時に IP リソースが「無駄に」なります。 IP プール。

予約済みIP

シーン

IP アドレスがクラスター外で使用されていることが明らかな場合、IP の競合を避けるために、既存の IP プールインスタンスから IP アドレスを見つけて削除するのは、時間と労力がかかる作業になる可能性があります。さらに、ネットワーク管理者は、この IP アドレスがストックまたは将来のすべての IP プールリソースに割り当てられないことを望んでいます。

プラン

ReservedIP CR では、クラスターで使用しない IP アドレスを設定できます。したがって、IP アドレスが IP プールオブジェクトに含まれている場合でも、IPAM プラグインはこれらの IP アドレスをポッドに割り当てません。 ReservedIP の IP アドレスは次のとおりです。

1. IP アドレスがクラスター外部のホストによって使用されていることを明確にします。

2. その IP アドレスがサブネット IP、ブロードキャスト IP などのネットワーク通信に使用できないことは明らかです。

例

apiVersion: spiderpool.spidernet.io/v1kind: SpiderReservedIPmetadata:  name: test-ipv4-reservedipspec:  ipVersion: 4  ips:   # 预留 IP 段    - 172.18.42.41-172.18.42.49

カスタムルート

ルーティングを適用およびカスタマイズするには、さまざまな方法があります。優先順位は低から高 (アプリケーションルーティング --> IP プール)。IP プール CR では、次を指定できます。

1. デフォルトルートとサブネットルート

kind: spiderippoolspec:    gateway: 172.16.0.1    routes: [ {“dst”: “192.168.0.0/16”, “gw”: “172.16.0.2”} ]

2. アプリケーションレベルのルーティング:

#在 Pod Annotaiton 中ipam.spidernet.io/routes : [{“dst”: “192.168.0.0/16”, “gw”: “172.16.0.2”}]

04 SpiderPool
CR デザイン

SpiderPool は CRD (CustomResourceDefinitions) を使用してサブネットや IP プールなどのリソースを定義します。Spider Subnet と Spider IP Pool CRD の 2 層ストレージ設計を通じて、IP プール CR は IP アドレスセットを定義します。サブネット内の異なる IP アドレスは個別に保存されます。異なる IP プールインスタンスでは、必要に応じて IP プールセットを拡張または縮小できます。さらに、SpiderPool は IP プールインスタンス内のアドレスを検証し、IP アドレスが重複していないことを確認します。

IP プールの CR 設計は、IP アドレスの希少性に完全に基づいており、アプリケーションおよび名前空間内の異なる IP プールのバインドを実現して IP リソースの分離を実現し、IP リソース共有のシナリオにも対応します。

1. SpiderSubnet オブジェクト:サブネットは IPv4/IPv6 サブネットに対応し、サブネットの下で使用可能なすべての IP アドレスを格納します。

2. SpiderIPPool オブジェクト: 1 つの Spider Subnet オブジェクトの下に複数の SpiderIPPool インスタンスが存在することができ、SpiderIPPool オブジェクトは、それが属する SpiderSubnet の利用可能な IP アドレスコレクションの一部を格納します。ポッドは、Spider IP プールオブジェクトから割り当てられた IP アドレスを使用します。

関連する CRD リソース

1. Spidersubnets.spiderpool.spidernet.io は、IP サブネットインスタンスの保存と定義に使用され、サブネットの下で利用可能なすべての IP コレクションを保存し、IP プール内の IP は IP サブネットから取得されます。

合理性を確認する: Webhook メカニズムは、管理者が SpiderSubnet オブジェクトを作成および変更するときに、それがストック Spider Subnet オブジェクトのサブネットと重複しないことを保証し、その中のすべてのフィールドの値が規則に準拠していることを保証します。仕様。

管理対象 SubnetIPPool データをリアルタイムで更新します。subnetIPPool Informer は、管理対象 SpiderSubnet オブジェクト内のデータをリアルタイムで更新します。

オブジェクトの削除の処理: SpiderSubnet オブジェクトが削除されると、ファイナライザーは、管理されているすべての SpiderIPPool 内の IP がビジネスポッドによって解放されることを確認し、その後 SpiderSubnet オブジェクトが実際に削除され、IP リークと競合が回避されます。

ステータス表示:ステータスフィールドの使用状況情報を表示します。

apiVersion: spiderpool.spidernet.io/v1kind: SpiderSubnetmetadata:  finalizers:  - spiderpool.spidernet.io  name: default-v4-subnetspec:  ipVersion: 4  subnet: 172.19.0.0/16  ips:  - 172.19.40.2-172.19.40.254  excludeIPs:xxxx  gateway: xxxx  routes: xxxx  vlan: 0status:  totalIPCount: 253  allocatedIPCount: 253  controlledIPPools:    default-v4-ippool:      ips:      - 172.19.40.2-172.19.40.254

2. Spiderippools.spiderpool.spidernet.io は、 サブネットの下に利用可能な IP コレクションの一部を保存します。各 IP プールで使用可能な IP は CR インスタンスで定義されます。

合理性を確認する: SpiderIPPool オブジェクトを作成および変更するとき、Webhook メカニズムはそのすべてのフィールドの値が仕様に準拠していることを保証し、SpiderIPPool オブジェクト間の IP の重複を許可しません。

サブネットの所有権を保証する: SpiderIPPool の spec.subnet フィールドがストック SpiderSubnet オブジェクトに対応していることを確認し、spec.ips 内の使用可能な IP アドレスが、それが属する SpderSubnet オブジェクト内のアイドル IP アドレスであることを確認します。

オブジェクトの削除の処理:ファイナライザーは SpiderIPPool オブジェクトの削除をインターセプトします。SpiderIPPool オブジェクト内のすべての IP が関連するビジネス Pod によって解放された後でのみ、他の SpiderIPPool オブジェクトの同時作成と IP の重複の発生を回避するために、SpiderIPPool インスタンスは削除されます。SpiderIPPool オブジェクトが Deleting 状態にある場合、IPAM は新しい POD に対する Spiderippool オブジェクトからの IP アドレスの割り当てを停止しますが、既存の Pod が IP を解放することは許可します。

ステータス表示: [ステータス] フィールドのステータス情報をリアルタイムで更新します。

apiVersion: spiderpool.spidernet.io/v1kind: SpiderIPPoolmetadata:  name: default-v4-ippool  finalizers:  - spiderpool.spidernet.iospec:  disable: false  ipVersion: 4  subnet: 172.19.0.0/16  ips:  - 172.19.40.2-172.19.40.254  excludeIPs: 172.19.40.254  gateway: 172.19.40.1  namespaceAffinity: xxxxx  nodeAffinity: xxxxx  podAffinity: xxxxx  routes: xxxx  vlan: 0status:  allocatedIPCount: 4  allocatedIPs:    172.19.40.21:      containerID: ****      pod: coredns-6d4b75cb6d-627xr      namespace: kube-system      interface: eth0      node: spider-control-plane      ownerControllerName: coredns-6d4b75cb6d      ownerControllerType: ReplicaSet  totalIPCount: 253

3. Spiderendpoints.spiderpool.spidernet.io は 、ポッドの現在および過去に割り当てられた IP 情報を記録します。

status.current フィールドには、ポッドの現在の最新の IP 割り当てが保存されます。このフィールドには、ポッドのマルチ NIC シナリオをサポートするためにすべての NIC の IP 割り当てを保存できます。

status.history フィールドには、すべての履歴 IP 割り当てが保存され、Spiderippool オブジェクトの IP GC リサイクルに使用できます。

ownerReferences の設計により、このオブジェクトのリサイクルメカニズムが保証されます。

ファイナライザーは、オブジェクトに保存されている情報が誤って失われないように設計されています。

apiVersion: spiderpool.spidernet.io/v1kind: SpiderEndpointmetadata:  finalizers: [“spiderpool.spidernet.io”]  name: test-pod-788d579c4-6r2w7  namespace: default  ownerReferences:  - apiVersion: v1    kind: Pod    name: test-pod-788d579c4-6r2w7    uid: ca1263c8-c4ed-402c-b25a-ad3f822605f9status:  ownerControllerName: test-pod-788d579c4  ownerControllerType: ReplicaSet  current:    containerID: ******    creationTime: "2022-10-20T09:10:45Z"    node: spider-worker    ips:    - interface: eth0      ipv4: 172.19.40.47/16      ipv4Pool: default-v4-ippool      ipv6: fc00:f853:ccd:e793:f::3c/64      ipv6Pool: default-v6-ippool      vlan: 0    - interface: net1      ipv4: 172.19.40.167/16      ipv4Pool: default-v4-ippool      ipv6: fc00:f853:ccd:e793:f::c5/64      ipv6Pool: default-v6-ippool      vlan: 0  history: *******

4. Spiderreservedips.spiderpool.spidernet.ioは、予約が必要な IP を保存するために使用され、一度予約されると、IP を Pod に割り当てることはできません。

04 SpiderPoolの
今後の展望

SpiderPool のコア機能は基本的に完成しており、Macvlan /SRI-OV などのアンダーレイ CNI の組み合わせに基づいてテストおよび実装され、Multus およびオーバーレイ CNI (Calico、Cilium) と組み合わせて、マルチネットワークでの IP 割り当てと管理を実現します。カードシナリオ。次のステージでは、SpiderPool は引き続きさまざまな利用シーンの充実とログの改善を進め、段階的に機能の安定期に入ります。

クラウドネイティブテクノロジーの愛好家は、ダウンロードして使用したり、コミュニティのディスカッションや貢献に参加したりすることを歓迎します。

SpiderPool 公式コミュニティ:

https://github.com/spidernet-io/spiderpool