本「マスターKubernetes。 コンテナアーキテクチャのオーケストレーション "

こんにちは、habrozhiteli！ 最近、Kubernetesバージョン1.10に関する本を出版しました。 投稿の抜粋「Kubernetesのネットワークソリューション」



ネットワーキングは広範なトピックです。 デバイス、ハース、およびコンテナを使用してネットワークを構成する方法は多数あります。 Kubernetesはこれに限定しません。 このプラットフォームで規定されているのは、炉床用のフラットアドレススペースを備えた高レベルのネットワークモデルです。 このスペース内で、さまざまな機能とさまざまな環境に対応した多くの優れたソリューションを実装できます。 このセクションでは、それらのいくつかを見て、それらがKubernetesネットワークモデルにどのように適合するかを理解しようとします。

ハードウェアクラスターでのブリッジの作成

最も単純な環境は、通常のL2レベルの物理ネットワークであるベアメタルクラスターです。 コンテナをこのようなネットワークに接続するには、標準のLinuxブリッジを使用できます。 これは、brctl、ip addr、ip route、ip link、nsenterなどの低レベルLinuxネットワークコマンドの経験を必要とするかなり骨の折れる手順です。次のガイドを読むことで、このソリューションの実装を開始できます。blog.oddbit.com/

2014/08/11 / four-ways-to-connect-a-docker /（Linux Bridgeデバイスを使用するセクションを探してください）。

Contiv

Contivは汎用ネットワークアドオンです。 CNIを介してコンテナを接続するように設計されており、Docker（直接）、Mesos、Docker Swarm、および当然のことながらKubernetesで使用できます。 Contivはネットワークポリシーを扱い、Kubernetesの同様のオブジェクトを部分的に複製します。 以下は、このネットワークアドオンの機能の一部です。

• libnetworkでのCNMおよびCNI仕様のサポート。
• セキュリティと予測可能なアプリケーション展開を提供する機能豊富なポリシーエンジン。
• クラス最高のコンテナパフォーマンス。
• マルチテナンシー、分離、および重複するサブネット。
• IPAM統合とサービス検出。
• 物理トポロジの幅広い選択：
  
  
  
  a）レイヤー2プロトコル（VLAN）。
  
  b）レイヤー3プロトコル（BGP）。
  
  c）オーバーレイネットワーク。
  
  d）Cisco SDN（ACI）;
• IPv6サポート。
• スケーラブルなポリシーとルートの割り当て。
• 以下を含むアプリケーションテンプレートとの統合：
  
  
  
  a）Docker-compose;
  
  b）Kubernetes展開マネージャー。
  
  c）「東-西」タイプ（東-西）のマイクロサービスのバランサーに組み込まれたサービスの負荷分散。
  
  d）ストレージ、アクセス制御（etcd / consulなど）、ネットワーク伝送および管理中のトラフィックの分離。

Contivには多くの機能があります。 このツールはさまざまなタスクを実装し、さまざまなプラットフォームをサポートしているため、Kubernetesにとって最適なツールかどうかはわかりません。

vswitchを開く

Open vSwitchは、仮想（ソフトウェア）スイッチを作成するための成熟したソリューションであり、市場の多くの主要なプレーヤーによってサポートされています。 Open Virtualization Network（OVN）システムを使用すると、さまざまな仮想ネットワークトポロジを構築できます。 彼女はKubernetes用の特別なアドオンを持っていますが、設定するのは非常に困難です（ github.com/openvswitch/ovn-kubernetesマニュアルを参照）。 リネンCNIアドオンの機能は少ないですが、その構成ははるかに簡単です： github.com/John-Lin/linen-cni リネンCNI構造を図に示します。 10.6。









Open vSwitchは、物理サーバー、VM、およびポッド/コンテナーを単一の論理ネットワークに統合できます。 このシステムは、オーバーレイモードと物理モードの両方をサポートしています。



主な機能の一部を次に示します。

• トランクポートとパブリックポートを備えた標準802.1Q VLANモデル。
• 上位レベルスイッチ用のLACPを使用した、または使用しないNICバインディング
• NetFlow、sFlow®およびミラーリングにより、視認性が向上しました。
• QoS構成（サービス品質）とポリシー。
• Geneve、GRE、VXLAN、STT、およびLISPをトンネリングします。
• 802.1agのブレークコントロール。
• OpenFlow 1.0と多数のアドオン。
• CおよびPythonのバインディングを使用して構成を保存するためのトランザクションデータベース。
• Linuxカーネルモジュールを使用した高性能なリダイレクト。

Nuage Networks VCS

Virtualized Cloud Services（VCS）はNuageの製品です。Nuageは、ソフトウェア定義ネットワーク（Software-Defined Networking、SDN）を構築するための拡張性の高いポリシーベースのプラットフォームです。 これは、オープンシステムOpen vSwitch（データリダイレクト用）とオープンスタンダードに基づいて構築された多機能SDNコントローラーに基づくエンタープライズレベルのソリューションです。



Nuageプラットフォームは、Kubernetesポッドとサードパーティ環境（仮想およびハードウェア）を透過的なオーバーレイネットワークに結合し、さまざまなアプリケーションの詳細なポリシーを記述することができます。 リアルタイム分析エンジンにより、Kubernetesアプリケーションの可視性とセキュリティを監視できます。



さらに、すべてのVCSコンポーネントをコンテナとしてインストールできます。 特定のハードウェア要件はありません。

運河

Canalは、CalicoとFlannelの2つのオープンソースプロジェクトを組み合わせたものです。 したがって、名前。 CoreOSチームによって開発されたFlannelプロジェクトは、コンテナのネットワーク機能を扱い、Calicoはネットワークポリシーを担当します。 当初、それらは互いに別々に開発されましたが、ユーザーはそれらを一緒に使用したいと考えていました。 Canalオープンソースプロジェクトは、CalicoとFlannelを個別のCNIアドオンとしてインストールするための展開テンプレートです。 Calicoの創設者によって作成されたTigeraは、両方のプロジェクトをサポートし、さらに緊密な統合を計画していましたが、Kubernetesのアプリケーション間のセキュアネットワーキングのための独自のソリューションをリリースして以来、統合ソリューションを開発するのではなく、FlannelとCalicoの構成と統合を簡素化することに重点が移りました。 図 10.7は、Canalシステムの現在のステータスと、KubernetesやMesosなどのオーケストレーションプラットフォームとの関係を示しています。









Kubernetesと統合する場合、Canalはetcdに直接アクセスせず、Kubernetes APIサーバーにアクセスすることに注意してください。

フランネル

フランネルは、コンテナランタイムを操作するための仮想ネットワークを各ノードに提供する仮想ネットワークです。 各ノードで、flaneldエージェントが起動され、etcdクラスターに保存されている予約済みアドレススペースに基づいてサブネットを上げます。 コンテナと、一般的にはノード間のパケット交換は、いくつかのサーバーのいずれかによって行われます。 ほとんどの場合、サーバーはデフォルトでポート8285を介してトラフィックをトンネリングするTUNデバイスでUDPを使用します（ファイアウォールで開くことを忘れないでください）。



図 10.8では、フランネルネットワークのさまざまなコンポーネント、それが作成する仮想ネットワークデバイス、およびdocker0ブリッジを介したノードおよびハースとの通信方法について詳しく説明しています。 ここでは、UDPパケットをカプセル化するプロセスと、ノード間のパケットの移動も確認できます。









他のネットワークテクノロジーがサポートされています。

• vxlan-カーネル内でVXLANを使用してパケットをカプセル化します。
• host-gw-リモートサーバーのIPアドレスを介してサブネットへのIPルートを作成します。 これには、Flannelを実行しているサーバー間の2番目のネットワーク層での直接接続が必要であることに注意してください。
• aws-vpc — Amazon VPCルーティングテーブルにIPルートを作成します
• gce-Google Compute Engineネットワーク上にIPルートを作成します
• alloc-サブネットの割り当てのみを実行し、パケットのリダイレクトは実行しません。
• ali-vpc-Alicloud VPCルーティングテーブルにIPルートを作成します。

キャリコプロジェクト

Calicoは、コンテナとネットワークセキュリティ間のネットワークのための完全なソリューションです。 すべての主要なオーケストレーションプラットフォームおよびランタイムと統合できます。

• Kubernetes（CNIのアドオン）;
• Mesos（CNIのアドオン）;
• Docker（libneworkのアドオン）;
• OpenStack（Neutronのアドオン）。

Calicoは、すべての機能を保持しながら、ローカルまたはパブリッククラウドに展開することもできます。 ネットワークポリシーの適用は負荷に依存する可能性があり、これにより正確なトラフィック制御が提供され、パケットが常に目的の宛先に到達することが保証されます。 Calicoは、オーケストレーションプラットフォームからネットワークポリシーを自動的にインポートできます。 実際、彼はKubernetesでネットワークポリシーを実装する責任があります。

ロマーナ

Romanaは、コンテナ間のネットワーク化のための最新のソリューションです。 もともとはクラウドで使用するために設計されており、IPアドレスを管理する標準的な方法に依存して、3番目のネットワーク層で動作します。 Romanaでは、Linuxベースのサーバーを使用してゲートウェイとルートを作成することにより、ネットワーク全体を分離できます。 3番目のネットワーク層での作業には、カプセル化は必要ありません。 ネットワークポリシーは、分散ファイアウォールの形ですべてのエンドポイントおよびサービスに適用されます。 Romanaは、仮想オーバーレイネットワークを構成する必要がなくなるため、異なるクラウドプラットフォーム間のオンプレミスおよびハイブリッド展開を容易にします。



Romanaに最近登場した仮想IPアドレスにより、ローカルユーザーは、外部アドレスとサービスの仕様を使用して、第2レベルのローカルネットワークのサービスへのアクセスを開くことができます。



Romana開発者は、彼らのアプローチがパフォーマンスを大幅に改善すると主張しています。 図 図10.9は、VXLANカプセル化の拒否とともに、多くのオーバーヘッドを取り除く方法を示しています。

織りネット

Weave Netプロジェクトの主な機能は、使いやすさと構成の欠如です。 VXLANカプセル化を使用し、各ノードにマイクロDNSをインストールします。 開発者として、高度な抽象化に対処します。 コンテナに名前を付けると、Weave Netで標準ポートに接続し、適切なサービスを有効にできます。 これは、既存のアプリケーションをマイクロサービスおよびコンテナ化プラットフォームに移行するのに役立ちます。 Weave Netは、KubernetesおよびMesosと連携するためのCNIアドオンを提供します。 Kubernetes 1.4以降、Weave Netとの統合は、DaemonSetをデプロイする単一のコマンドで実現できます。

kubectl apply -f https://git.io/weave-kube
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

各ノードにあるWeave Netポッドは、他のポッドインスタンスをWeaveネットワークに接続する役割を果たします。 Weave Netは、ネットワークポリシーを使用してAPIをサポートし、完全で簡単な構成ソリューションを提供します。

ネットワークポリシーの効果的な使用

Kubernetesネットワークポリシーは、特定のポッドと名前空間に向けられたトラフィックを制御するように設計されています。 Kubernetesでよくあるように、展開された数百のマイクロサービスを管理する場合、囲炉裏間のネットワークが前面に出てきます。 このメカニズムはセキュリティに間接的にのみ関連していることを理解することが重要です。 攻撃者が内部ネットワークに侵入できる場合、ネットワークポリシーに準拠し、他の炉との無料通信を許可する炉の独自のインスタンスを作成できる可能性が高くなります。 前のセクションでは、Kubernetesのさまざまなネットワークソリューションについて、ネットワークインターフェイスに焦点を当てて説明しました。 ここでは、これらのソリューションの上に実装されたネットワークポリシーに焦点を当てますが、両方のコンポーネントは密接に相互接続されています。

Kubernetesのネットワークポリシーアーキテクチャ

ネットワークポリシーは、炉床のサブセットが相互に、および他のネットワークエンドポイントと相互作用する方法を決定します。 NetworkPolicyリソースは、ラベルを使用して囲炉裏を選択し、選択された囲炉裏インスタンスにトラフィックを誘導する許可ルールのリストを定義します（特定のネームスペースの分離ポリシーで既に許可されているものに加えて）。



»本の詳細については、出版社のウェブサイトをご覧ください

» コンテンツ

» 抜粋



Kuvrozhitelのクーポンの20％割引-Kubernetes



本の紙版が支払われると、電子版の本が電子メールで送信されます。



PS：本のコストの7％が新しいコンピューター本の翻訳に費やされます 。印刷会社に渡された本のリストはこちらです。