Kubernetesネットワークポリシーを深く理解する
6704 ワード
テキストリンク:https://juejin.im/post/5977dad55188254c394344a2
【編集者の話】マイクロサービス、クラウドの原生に向かって歩み始めると、従来の静的で比較的簡単なサイバーセキュリティ戦略は骨が折れるようになります.KubernetesのNetwork Policy特性はこの問題を解決するために来ている.発売直後の1.7バージョンでは、この特性もGAに補正されている.Network Policyが何なのか、私たちのために何ができるのか、どのように実現されているのかを見てみましょう.
【3日間脳を燃やすDockerベースのCI/CD実戦訓練キャンプ|北京駅】今回の訓練はDockerベースのCI/CD実戦をめぐって展開され、具体的な内容は以下の通りである:持続的な統合と持続的な交付(CI/CD)の概要;持続的な統合システムの紹介;クライアントとサービス側のCI/CD実践;開発プロセスにCI、CDを導入する.GitlabとCI、CDツール;Gitlab CI、Droneの使用、実践経験を共有します.
CNI
Kubernetesはネットワークを抽象化した.ネットワークに対するニーズを外部のコンポーネント、すなわちCNI driverに渡します.
Podのネットワークは、次の3つの要件を満たす必要があります.すべてのPod間はNATなしで に通じる.ホストとPodの間でNATを必要とせずに を相互接続する Pod自省IPアドレスとその外部に見られるアドレスが一致する CNIはネットワークの実現を詳細に定義した.CNIの実装は3つに分けることができる. 3層ルーティング実装 Overlay を実現層交換 を実現する.
現在よく使われているCNI実装は,Flannel,Calico,Weaveである.FlannelはVXLan Overlayによってホスト間Podネットワークを実現し,Calicoは完全に3層のルートによってホスト間コンテナネットワークを実現し,WeaveもOverlayの実現である.
Network Policyとは
ビジネスロジックの複雑化、マイクロサービスの流行に伴い、ますます多くのクラウドサービスプラットフォームが大量のモジュール間のネットワーク呼び出しを必要としている.
従来の単一の外部ファイアウォール、またはアプリケーションに従って階層化されたファイアウォールの方法では、ニーズを満たすことができません.大きなクラスタでは、各モジュール、ビジネスロジック層、または各職能チーム間のネットワークポリシーの需要がますます高まっています.
Kubernetesは1.3でNetwork Policyという機能を導入してこの問題を解決した.これらのPolicyにより、同じCluster内でネットワークの分離が可能になります.つまり、必要なPodの間にファイアウォールを架けます.各マイクロサービス間の動的ファイアウォールとして簡単に理解できる.これを分布式ファイアウォールと呼ぶ人もいます.
すべてのネットワークドライバがこの機能をサポートしているわけではありません.例えば皆さんがよく知っているように、流行しているFlannelはまだNetwork Policyのサポートに参加していません.CalicoとWeaveはそれぞれNPC(network policy controller)を実現した.FlannelはNetwork Policyをサポートしていませんが.しかし、Flannelを使用してネットワークスキームを提供し、CalicoまたはWeaveのNPCコンポーネントを使用して共同で完了することができる.CanalはFlannelとCalico NPCを組み合わせたスキームを提供した.
DEMO
次に、Calicoをベースに、demoを作ってみましょう.
ここで私はKubernetesの簡単なクラスタを構築しました:1つのmasterと2つのminionしかありません.まずCalicoを導入します.ここで注意したいのは、demoが最新のKubernetes APIであるため、Kubernetes 1.7とCalico 2.3を使用する必要があります.また、CalicoはKubernetes Datastoreのモードにしか構成できません.このモードでは、ネットワーク状態に対するCalicoの制御は、Kubernetes APIによって行われる.もう1つのモードはetcdクラスタを通過することである.そのパターンはまだ最新のAPIをサポートしていない.Kubernetes Datastoreという方法は、KDD-Kubernetes datastore driverとも呼ばれることがあります.
KDDモードのCalicoインストールを行う場合は、以下の点に注意してください. IPAMはhost-local を使用する controller managerによりCIDR を割り当てる.
詳細はクリックしてください:docs.projectcalico.org/v2.3/gettin…
Calicoを構成したら、Network Policyを実際に操作する簡単なdemoを見てみましょう.
簡単にするためにdefault namespaceを直接使用します.既存の環境では、次のコマンドを独立したnamespaceで実行できます.
namespaceの作成このコマンド:
BusyBoxのPodを使用して、
次は制限に参加します.私たちのやり方は、すべてのPodへのアクセスを制限してから、ホワイトリストを作成することです.kubectl applyの下のYAMLファイルはすべてのアクセスを制限することができます:
もう一度前のBusyBoxで訪問してみましょう:
このNetwork Policyは、ラベルrun:accessで選択したPodがラベルrun:nginxのPod、つまり私たちdemoが開始したときに作成したNginxのPodにアクセスできることを意味します.これらのlabelは、kubectl runコマンドによって自動的に追加されます.
次に、
1.7以前のNetwork Policyに触れたことがあるなら、ここのAPIが少し違うことに気づくかもしれません.Kubernetes 1.7はNetwork PolicyをGAに正式に昇格させた.
正式なAPIと以前のAPIの違いは以下の通りです. Annotationを使用してdefault-denyなどのルールを表現することはなくなりました API versionはextension/beta 1からnetworkingにアップグレードした.k8s.io/v1
インプリメンテーション
Calicoの実装はiptablesに基づいている.各chainの先端には、packetがCalicoで定義されたルールを優先するように、Calicoにカスタムchainが挿入されています.いずれかのminionでiptables-save-cを実行すると、これらのルールを確認できます.kube-proxyとCalicoはいずれも大量のiptable規則を定義していることがわかる.
ここには詳細がたくさんあります.私たちはこれらの点に注目する必要があります.
Calicoはconntrackを用いて最適化した.すなわち,1つの接続が確立されると,その後のpacketは直接通過を許可される.たとえば、cali-pi-xxxxという
もう一つの微細な違いは、Weaveが-m conntrackではなく-m stateを使用していることです.conntrackは比較的新しい文法ですが、実際に使用している機能は同じです.Weaveにインストールされているiptables rulesの例をいくつか示します:
Q:CalicoとWeaveどちらがPolicy処理性能が優れていますか?
A:両者のiptablesレベルでの実現原理は同じです.すべて-mstateとipsetの最適化を使って、性能の差は大きくありません.
Q:CalicoはKubernetesと結合してどのようにマルチテナントを実現しますか.例えば、ネット隔離などですか.
A:namespaceで隔離することも考えられます.Network Policyがない場合はもちろん相互接続です.しかし、KubernetesのNetwork PolicyはnamespaceSelectorをサポートしており、簡単にできます.
Q:Weave、Calico、Flannel比較、適用シーンとメリットとデメリットは何ですか.Flannel outですか.
A:それぞれの市場があります:-)Flannelは比較的簡単で、リソースの消費も小さくなります.Flannelはoutとは言えません.Cannelの登場はFlannelとCalicoを統合した.
Q:NPCはiptablesで実現しなければなりませんか?場合によっては、Pod出向トラフィックはホストプロトコルスタックによっては使用されません.この場合、NPCはどのように実現されますか?
A:Calico,Weave,RomanaのNPCはいずれもiptablesで実現されている.Podegressはホストプロトコルスタックを通過しなくてもnetfilterを通過します.
テキストリンク
【編集者の話】マイクロサービス、クラウドの原生に向かって歩み始めると、従来の静的で比較的簡単なサイバーセキュリティ戦略は骨が折れるようになります.KubernetesのNetwork Policy特性はこの問題を解決するために来ている.発売直後の1.7バージョンでは、この特性もGAに補正されている.Network Policyが何なのか、私たちのために何ができるのか、どのように実現されているのかを見てみましょう.
【3日間脳を燃やすDockerベースのCI/CD実戦訓練キャンプ|北京駅】今回の訓練はDockerベースのCI/CD実戦をめぐって展開され、具体的な内容は以下の通りである:持続的な統合と持続的な交付(CI/CD)の概要;持続的な統合システムの紹介;クライアントとサービス側のCI/CD実践;開発プロセスにCI、CDを導入する.GitlabとCI、CDツール;Gitlab CI、Droneの使用、実践経験を共有します.
CNI
Kubernetesはネットワークを抽象化した.ネットワークに対するニーズを外部のコンポーネント、すなわちCNI driverに渡します.
Podのネットワークは、次の3つの要件を満たす必要があります.
現在よく使われているCNI実装は,Flannel,Calico,Weaveである.FlannelはVXLan Overlayによってホスト間Podネットワークを実現し,Calicoは完全に3層のルートによってホスト間コンテナネットワークを実現し,WeaveもOverlayの実現である.
Network Policyとは
ビジネスロジックの複雑化、マイクロサービスの流行に伴い、ますます多くのクラウドサービスプラットフォームが大量のモジュール間のネットワーク呼び出しを必要としている.
従来の単一の外部ファイアウォール、またはアプリケーションに従って階層化されたファイアウォールの方法では、ニーズを満たすことができません.大きなクラスタでは、各モジュール、ビジネスロジック層、または各職能チーム間のネットワークポリシーの需要がますます高まっています.
Kubernetesは1.3でNetwork Policyという機能を導入してこの問題を解決した.これらのPolicyにより、同じCluster内でネットワークの分離が可能になります.つまり、必要なPodの間にファイアウォールを架けます.各マイクロサービス間の動的ファイアウォールとして簡単に理解できる.これを分布式ファイアウォールと呼ぶ人もいます.
すべてのネットワークドライバがこの機能をサポートしているわけではありません.例えば皆さんがよく知っているように、流行しているFlannelはまだNetwork Policyのサポートに参加していません.CalicoとWeaveはそれぞれNPC(network policy controller)を実現した.FlannelはNetwork Policyをサポートしていませんが.しかし、Flannelを使用してネットワークスキームを提供し、CalicoまたはWeaveのNPCコンポーネントを使用して共同で完了することができる.CanalはFlannelとCalico NPCを組み合わせたスキームを提供した.
DEMO
次に、Calicoをベースに、demoを作ってみましょう.
ここで私はKubernetesの簡単なクラスタを構築しました:1つのmasterと2つのminionしかありません.まずCalicoを導入します.ここで注意したいのは、demoが最新のKubernetes APIであるため、Kubernetes 1.7とCalico 2.3を使用する必要があります.また、CalicoはKubernetes Datastoreのモードにしか構成できません.このモードでは、ネットワーク状態に対するCalicoの制御は、Kubernetes APIによって行われる.もう1つのモードはetcdクラスタを通過することである.そのパターンはまだ最新のAPIをサポートしていない.Kubernetes Datastoreという方法は、KDD-Kubernetes datastore driverとも呼ばれることがあります.
KDDモードのCalicoインストールを行う場合は、以下の点に注意してください.
詳細はクリックしてください:docs.projectcalico.org/v2.3/gettin…
Calicoを構成したら、Network Policyを実際に操作する簡単なdemoを見てみましょう.
簡単にするためにdefault namespaceを直接使用します.既存の環境では、次のコマンドを独立したnamespaceで実行できます.
namespaceの作成このコマンド:
kubectl create ns np-demoを使用して、簡単なnginx deploymentを実行し、80ポートでサービスを暴露します.kubectl run nginx --replicas=2 --image=nginx deployment "nginx" created kubectl expose deploy nginx --port=80 service "nginx" exposedはまだ制限されていないので、KubernetesのデフォルトはすべてのPodがオープンです.BusyBoxのPodを使用して、
kubectl run busy --rm -ti --image busybox /bin/sh If you don't see a command prompt, try pressing enter. / # wget -q nginx -O - | head -4のWgetコマンドがBusyBoxというPodで実行されていることを確認します.-qと-O -の組み合わせにより、このコマンドはコマンドラインでnginxのデフォルトのトップページを出力し、検証が成功したことを示します.Ctl-Dで容器を終了します.次は制限に参加します.私たちのやり方は、すべてのPodへのアクセスを制限してから、ホワイトリストを作成することです.kubectl applyの下のYAMLファイルはすべてのアクセスを制限することができます:
kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: default-deny spec: podSelector:空のpodSelectorを提供していることに注意してください.もう一度前のBusyBoxで訪問してみましょう:
kubectl run busy --rm -ti --image busybox /bin/sh / # wget -q --timeout=5 nginx -O -これで5秒のタイムアウトを設定しました.アクセスが拒否されたため、確かにタイムアウトします.wget: download timed outはい、私たちの最初のNetwork Policyは有効になりました.しかし、すべてのPodへのアクセスを制限することは明らかに意味がない.次はホワイトリストを作成します.applyの下のYAMLファイル:``kind:NetworkPolicy apiVersion:networking.k8s.io/v1 metadata: name: access-nginx spec: podSelector: matchLabels: run: nginx ingress: - from:
- podSelector:
matchLabels:
run: access```このNetwork Policyは、ラベルrun:accessで選択したPodがラベルrun:nginxのPod、つまり私たちdemoが開始したときに作成したNginxのPodにアクセスできることを意味します.これらのlabelは、kubectl runコマンドによって自動的に追加されます.
次に、
kubectl run access --rm -ti --image busybox /bin/sh wget -q nginx -O -に正常にアクセスできるかどうかを試してみましょう.私たちは依然としてよく知っているNginxのデフォルトのトップページを見ることができます.上記のselectorに一致しないPodを実行するとアクセスできません.これは興味のある学生に自分で帰って検証します.1.7以前のNetwork Policyに触れたことがあるなら、ここのAPIが少し違うことに気づくかもしれません.Kubernetes 1.7はNetwork PolicyをGAに正式に昇格させた.
正式なAPIと以前のAPIの違いは以下の通りです.
インプリメンテーション
Calicoの実装はiptablesに基づいている.各chainの先端には、packetがCalicoで定義されたルールを優先するように、Calicoにカスタムchainが挿入されています.いずれかのminionでiptables-save-cを実行すると、これらのルールを確認できます.kube-proxyとCalicoはいずれも大量のiptable規則を定義していることがわかる.
ここには詳細がたくさんあります.私たちはこれらの点に注目する必要があります.
Calicoはconntrackを用いて最適化した.すなわち,1つの接続が確立されると,その後のpacketは直接通過を許可される.たとえば、cali-pi-xxxxという
-A cali-fw-cali7af3f94d3a1 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A cali-fw-cali7af3f94d3a1 -m conntrack --ctstate INVALID -j DROPのルールはNetwork Policy Ingressを担当しています.多くのPolicyを定義すると、個別に定義されたルールがパフォーマンスを低下させることが考えられます.ここでCalicoはiptablesのipset特性を利用している.1つのruleがhashテーブルを介して複数のアドレスをマッチングできるようにする.`-A cali-pi-_G7e-YAvXRsfDoqGDf36 -m set --match-set cali4-s:2I5R46OBA_TBIUlpH0dCd_n src -j MARK --set-xmark 0x1000000/0x1000000 -A cali-pi-_G7e-YAvXRsfDoqGDf36 -m mark --mark 0x1000000/0x1000000 -j RETURN Weaveの実装も同様である.下部にはiptablesとnetfilterが使用されています.Weaveもカスタムchainを作成しました.しかし、一つはOverlayであり、一つはルーティングであるため、ルールは少し違います.もう一つの微細な違いは、Weaveが-m conntrackではなく-m stateを使用していることです.conntrackは比較的新しい文法ですが、実際に使用している機能は同じです.Weaveにインストールされているiptables rulesの例をいくつか示します:
FORWARD chain: -o weave -j WEAVE-NPC -o weave -j DROP WEAVE_NPC chain: -m state --state RELATED,ESTABLISHED -j ACCEPT -m state --state NEW -j WEAVE-NPC-DEFAULT -m state --state NEW -j WEAVE-NPC-INGRESS -m set --match-set weave-v/q_G.;Q?uK]BuDs2 dst -j ACCEPT -m set --match-set weave-k?Z;25^M}|1s7P3|H dst -j ACCEPGoQ&A Q:CalicoとWeaveどちらがPolicy処理性能が優れていますか?
A:両者のiptablesレベルでの実現原理は同じです.すべて-mstateとipsetの最適化を使って、性能の差は大きくありません.
Q:CalicoはKubernetesと結合してどのようにマルチテナントを実現しますか.例えば、ネット隔離などですか.
A:namespaceで隔離することも考えられます.Network Policyがない場合はもちろん相互接続です.しかし、KubernetesのNetwork PolicyはnamespaceSelectorをサポートしており、簡単にできます.
Q:Weave、Calico、Flannel比較、適用シーンとメリットとデメリットは何ですか.Flannel outですか.
A:それぞれの市場があります:-)Flannelは比較的簡単で、リソースの消費も小さくなります.Flannelはoutとは言えません.Cannelの登場はFlannelとCalicoを統合した.
Q:NPCはiptablesで実現しなければなりませんか?場合によっては、Pod出向トラフィックはホストプロトコルスタックによっては使用されません.この場合、NPCはどのように実現されますか?
A:Calico,Weave,RomanaのNPCはいずれもiptablesで実現されている.Podegressはホストプロトコルスタックを通過しなくてもnetfilterを通過します.
テキストリンク