ネットワーク ポリシーは、ポッド間のネットワーク通信ルールを定義および制御するために使用される Kubernetes のリソース オブジェクトです。これにより、Kubernetes クラスターで詳細なネットワーク ルールを定義して、どの Pod が相互に通信できるか、どのトラフィックが許可または禁止されるかを制御できます。ネットワーク ポリシーは、きめ細かいネットワーク アクセス制御を実装する方法を提供し、管理者と開発者がクラスター内のネットワーク通信が特定のセキュリティとポリシーの要件を満たしていることを確認できるようにします。 1. 2種類のポッド分離ポッドには 2 種類の分離があります。
それらは、どの接続を作成できるかに関係します。ここでの「隔離」は絶対的なものではなく、「ある程度の制限がある」という意味です。また、「非孤立方向」とは、その方向に制限がないことを意味します。これら 2 種類の分離 (または分離の欠如) は独立したステートメントであり、どちらも 1 つの Pod から別の Pod への接続に関連しています。 デフォルトでは、Pod の出力は非分離であり、すべての送信接続が許可されます。いずれかの NetworkPolicy が Pod を選択し、その policyTypes に Egress が含まれている場合、Pod は出力分離されており、そのようなポリシーは Pod の出力に適用されると言われます。 Pod の出力が分離されている場合、Pod から許可される接続は、出力 Pod に適用される NetworkPolicy の出力リストによって許可される接続のみになります。これらの出力リストの効果は付加的です。 デフォルトでは、Pod はイングレスに対して分離されていないため、すべての受信接続が許可されます。いずれかの NetworkPolicy が Pod を選択し、その policyTypes に Ingress が含まれている場合、Pod は Ingress から分離され、このポリシーは Pod の Ingress に適用されることになります。 Pod のイングレスが分離されている場合、Pod に許可される接続は、Pod のノードからの接続と、イングレス Pod に適用される NetworkPolicy のイングレス リストによって許可される接続のみになります。これらの入力リストの効果は付加的です。 ネットワーク ポリシーは追加的であるため、競合は発生しません。ポリシーがポッドの特定の方向のトラフィックに適用される場合、その方向でポッドに許可される接続は、適用可能なネットワーク ポリシーによって許可されるセットになります。したがって、評価の順序は戦略の結果に影響しません。ソース Pod から宛先 Pod への接続を許可するには、ソース Pod の出力ポリシーと宛先 Pod の入力ポリシーの両方で接続を許可する必要があります。どちらか一方が接続を許可しない場合、接続の確立は失敗します。 2. NetworkPolicy設定の詳細な説明以下は NetworkPolicy の例です。リソースの完全な定義についてはNetworkPolicy[1]を参照してください。 3. 応用シナリオこれは、ポッドのイングレスおよびエグレス トラフィックを制限し、ポッド レベルおよび名前空間レベルのネットワーク アクセス制御を提供するために使用される kuebenetes リソースです。
4. ネットワークアクセス制御のケースケース1名前空間内のすべてのポッドの受信トラフィックと送信トラフィックを拒否します。 上記のネットワーク ポリシーは、すべてのポッドがテスト名前空間に出入りすることを禁止します。 ネットワーク ポリシーが作成されていない場合、テスト名前空間内の Pod は次のように外部ネットワークにアクセスできます。 テスト すべてのネットワークを拒否するポリシーを適用すると、テスト名前空間内のコンテナは外部ネットワークにアクセスできなくなります。 テスト 外部ポッドは相互にアクセスできません。ここでは、テストとして nginx コンテナがテスト名前空間で起動されます。 テスト ケース2他の名前空間のポッドへのアクセスを拒否します。 実稼働環境では、同じ名前空間で実行されているポッドが相互にアクセスし、他の名前空間がその名前空間内のすべてのポッドへのアクセスを拒否される必要がある場合があります。 ここではシミュレーションに 2 つの名前空間が使用されます。1 つは開発環境 dev で、もう 1 つは実稼働環境 pro です。現在、本番環境の pro の下にあるすべての Pod が dev 開発環境内のすべての Pod にアクセスできないという要件があります。 まず2つの名前空間を作成する 名前空間の作成 2 つの名前空間で 3 つのテスト ポッドを起動します。 ポッドのステータスを確認します。 ポッドステータス ネットワーク ポリシーが設定されていない場合、pro 名前空間のポッドは次のように dev 名前空間のポッドと通信できます。 ポッドのテスト 次のようにネットワーク ポリシーを作成します。 検証結果は次のとおりです。dev 名前空間のポッドは pro 名前空間のすべてのポッドにアクセスできませんが、dev 名前空間のポッドは互いにアクセスできます。 結果を確認する ケース3他の名前空間のポッドが指定されたアプリケーションにアクセスできるようにします。ここで、ポッド ラベル app=web を使用して、他の名前空間が pro 名前空間内の指定されたポッドにアクセスできるようにする必要があります。まず、次のように pro-web ポッドにラベルを追加します。 ネットワーク ポリシーを作成します。ネットワークポリシーの内容は次のとおりです。作成する前に、以前にテストしたネットワーク テストを削除します。 つまり、すべての名前空間のポッドは、pro 名前空間の app=web を持つポッドにアクセスできますが、これは K8s のデフォルトと同じであり、意味がありません。しかし、ケース 1 と組み合わせると、一方はアクセス可能で、もう一方はアクセス不可能になる可能性があります。このルールのみは、次のように K8S のデフォルトと同じです。 ケース 1 と組み合わせると、名前空間内のすべてのポッドのイングレス トラフィックとエグレス トラフィックを拒否するルールは次のようになります。 CKAの実際の質問(1)質問1: 本当の質問 k8s クラスター環境を切り替えます: kubectl config use-context hk8s タスク: 既存の名前空間内部に allow-port-from-namespace という新しい NetworkPolicy を作成します。 新しい NetworkPolicy によって、名前空間 internal 内の Pod が名前空間 internal 内の Pod のポート 9000 に接続できることを確認します。 新しい NetworkPolicy をさらに確実にします。
(2)質問2 [候補@ノード-1] $ kubectl config use-context hk8s タスク: 既存の名前空間 my-app に allow-port-from-namespace という新しい NetworkPolicy を作成します。 新しい NetworkPolicy によって、名前空間 echo 内の Pod が名前空間 my-app 内の Pod のポート 9000 に接続できることを確認します。 新しい NetworkPolicy をさらに確実にします。
参考文献: [1]ネットワークポリシー: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.29/#networkpolicy-v1-networking-k8s-io |
<<: Volcano Engine パブリック クラウド シティ共有カンファレンスが成都にやって来て、一緒にクラウドに乗るよう皆さんを招待します。
>>: NodeSelector から NodeAffinity へ: Kubernetes ノード アフィニティの進化を探る
現在、「クラウド化」は企業開発におけるトレンドや考え方として徐々に定着しつつあります。クラウド コン...
Mushroom Host moguhost は、OpenStack クラウド アーキテクチャを採用...
マーケティングについての基本的な理解についてお話しいただけますか。あるいは、マーケティングのような一...
ルクセンブルクの大手サーバープロバイダー gcorelabs は現在、すべてのコンピュータールームを...
外部リンクを作成する友人の多くは、フォーラムで外部リンクを宣伝することを好みます。アンカー テキスト...
9月12日、アリババクラウドのエラスティック高性能コンピューティングプラットフォームE-HPCが招待...
クラウド コンピューティングは世界中の産業に革命をもたらしましたが、製造業も例外ではありません。テク...
IDC Review Network (idcps.com) は3月20日に次のように報じた。海外ド...
医療分野で働く人なら誰でも、医療ウェブサイトが大量生産されており、それが「盲目的な」ユーザーエクスペ...
SaaS エンタープライズ ソフトウェアは現在、エンタープライズ ソフトウェア全体に占める割合は比較...
『CHO 最高人事責任者のビジネスと管理レビュー』(以下、「CHO」)は、Zhaopin.com が...
アマゾン ウェブ サービスは、2022 年 12 月 9 日に開催された2022 re:Invent...
[51CTO.com からのオリジナル記事] 最近、Microsoft は今年最も重要なクラウド サ...
クラウドへの移行には多大なコストもかかり、企業が求めている価値を実際に得るためには、ワークロードの一...
dedipathはどうですか? Dedipath New York Data Centerはどうです...