CKA 認定の要点: K8s ネットワーク戦略の要点をマスターする

CKA 認定の要点: K8s ネットワーク戦略の要点をマスターする

ネットワーク ポリシーは、ポッド間のネットワーク通信ルールを定義および制御するために使用される 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]を参照してください。

 apiVersion:networking.k8s.io/v1 kind:NetworkPolicy metadata: name:test-network-policy namespace:default#策略应用在那个名称空间,就说对那个命名空间的pod做限制(目标) spec: podSelector:#选择匹配哪些标签的pod,选择一组pod做网络策略,写{}表示该命名空间下pod matchLabels: role:db policyTypes: -Ingress#入网,谁访问pod(即谁访问default名称空间下有role=db标签的pod) -Egress#出网,role=db的pod可以访问谁ingress: -from: -ipBlock: cidr:172.17.0.0/16 except: -172.17.1.0/24 -namespaceSelector: matchLabels: project:myproject -podSelector: matchLabels: role:frontend ports: -protocol:TCP port:6379 egress: -to: -ipBlock: cidr:10.0.0.0/24 ports: -protocol:TCP port:5978

3. 応用シナリオ

これは、ポッドのイングレスおよびエグレス トラフィックを制限し、ポッド レベルおよび名前空間レベルのネットワーク アクセス制御を提供するために使用される kuebenetes リソースです。

  • アプリケーション間のアクセス制御。たとえば、プロジェクト A はプロジェクト B のポッドにアクセスできません。
  • 開発環境の名前空間はテスト環境の名前空間ポッドにアクセスできません
  • ポッドが外部に公開されている場合、ポッドホワイトリストが必要です
  • マルチテナントネットワーク環境の分離

4. ネットワークアクセス制御のケース

ケース1

名前空間内のすべてのポッドの受信トラフィックと送信トラフィックを拒否します。

 apiVersion:networking.k8s.io/v1 kind:NetworkPolicy metadata: name:deny-all namespace:test spec: podSelector:{}#匹配本命名空间所有pod policyTypes: -Ingress -Egress

上記のネットワーク ポリシーは、すべてのポッドがテスト名前空間に出入りすることを禁止します。

ネットワーク ポリシーが作成されていない場合、テスト名前空間内の Pod は次のように外部ネットワークにアクセスできます。

テスト

すべてのネットワークを拒否するポリシーを適用すると、テスト名前空間内のコンテナは外部ネットワークにアクセスできなくなります。

テスト

外部ポッドは相互にアクセスできません。ここでは、テストとして nginx コンテナがテスト名前空間で起動されます。

テスト

ケース2

他の名前空間のポッドへのアクセスを拒否します。

実稼働環境では、同じ名前空間で実行されているポッドが相互にアクセスし、他の名前空間がその名前空間内のすべてのポッドへのアクセスを拒否される必要がある場合があります。

 apiVersion:networking.k8s.io/v1 kind:NetworkPolicy metadata: name:deny-ingress namespace:test spec: podSelector:{}#test下的所有pod policyTypes: -Ingress ingress: -from: -podSelector:{}#匹配本命名空间所有pod

ここではシミュレーションに 2 つの名前空間が使用されます。1 つは開発環境 dev で、もう 1 つは実稼働環境 pro です。現在、本番環境の pro の下にあるすべての Pod が dev 開発環境内のすべての Pod にアクセスできないという要件があります。

まず2つの名前空間を作成する

名前空間の作成

2 つの名前空間で 3 つのテスト ポッドを起動します。

ポッドのステータスを確認します。

ポッドステータス

ネットワーク ポリシーが設定されていない場合、pro 名前空間のポッドは次のように dev 名前空間のポッドと通信できます。

ポッドのテスト

次のようにネットワーク ポリシーを作成します。

 root@k8s-master:/home/yaml# cat deny-ingress.yaml apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-ingress namespace: pro spec: podSelector: {} #test下的所有pod policyTypes: - Ingress ingress: - from: - podSelector: {} #匹配本命名空间所有pod root@k8s-master:/home/yaml# kubectl apply -f deny-ingress.yaml networkpolicy.networking.k8s.io/deny-ingress created

検証結果は次のとおりです。dev 名前空間のポッドは pro 名前空間のすべてのポッドにアクセスできませんが、dev 名前空間のポッドは互いにアクセスできます。

結果を確認する

ケース3

他の名前空間のポッドが指定されたアプリケーションにアクセスできるようにします。ここで、ポッド ラベル app=web を使用して、他の名前空間が pro 名前空間内の指定されたポッドにアクセスできるようにする必要があります。まず、次のように pro-web ポッドにラベルを追加します。

 root@k8s-master:/home/yaml# kubectl label pods pro-web app=web -n pro pod/pro-web labeled root@k8s-master:/home/yaml# kubectl get pod -n pro --show-labels NAME READY STATUS RESTARTS AGE LABELS pro-busybox 1/1 Running 0 16m run=pro-busybox pro-db 1/1 Running 0 27m run=pro-db pro-web 1/1 Running 0 36m app=web,run=pro-web

ネットワーク ポリシーを作成します。ネットワークポリシーの内容は次のとおりです。作成する前に、以前にテストしたネットワーク テストを削除します。

 apiVersion:networking.k8s.io/v1 kind:NetworkPolicy metadata: name:allow-all-nmespace namespace:pro spec: podSelector: matchLabels: app:web#pro名称空间下的有app=web的标签policyTypes: -Ingress ingress: -from: -namespaceSelector:{}#匹配所有命名空间的pod
 root@k8s-master:/home/yaml# kubectl delete -f deny-ingress.yaml networkpolicy.networking.k8s.io "deny-ingress" deleted root@k8s-master:/home/yaml# kubectl apply -f allow-all-namespace.yml networkpolicy.networking.k8s.io/allow-all-nmespace created

つまり、すべての名前空間のポッドは、pro 名前空間の app=web を持つポッドにアクセスできますが、これは K8s のデフォルトと同じであり、意味がありません。しかし、ケース 1 と組み合わせると、一方はアクセス可能で、もう一方はアクセス不可能になる可能性があります。このルールのみは、次のように K8S のデフォルトと同じです。

ケース 1 と組み合わせると、名前空間内のすべてのポッドのイングレス トラフィックとエグレス トラフィックを拒否するルールは次のようになります。

 root@k8s-master:/home/yaml# cat deny-all.yml apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-all namespace: pro spec: podSelector: {} #匹配本命名空间所有pod policyTypes: - Ingress - Egress root@k8s-master:/home/yaml# kubectl apply -f deny-all.yml networkpolicy.networking.k8s.io/deny-all created root@k8s-master:/home/yaml# kubectl exec dev-busybox -n dev ping 10.244.36.72 kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead. ^C root@k8s-master:/home/yaml# kubectl exec dev-busybox -n dev ping 10.244.36.69 kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead. PING 10.244.36.69 (10.244.36.69): 56 data bytes 64 bytes from 10.244.36.69: seq=0 ttl=63 time=0.372 ms 64 bytes from 10.244.36.69: seq=1 ttl=63 time=0.369 ms

CKAの実際の質問

(1)質問1:

本当の質問

k8s クラスター環境を切り替えます: kubectl config use-context hk8s

タスク:

既存の名前空間内部に allow-port-from-namespace という新しい NetworkPolicy を作成します。

新しい NetworkPolicy によって、名前空間 internal 内の Pod が名前空間 internal 内の Pod のポート 9000 に接続できることを確認します。

新しい NetworkPolicy をさらに確実にします。

  • ポート9000でリッスンしていないポッドへのアクセスを禁止する
  • 名前空間内部にないポッドからのアクセスを許可しない
kubectlconfiguse-contexthk8s # 编写一个yaml 文件,注意先输入":set paste",防止复制时yaml 文件空格错序apiVersion:networking.k8s.io/v1 kind:NetworkPolicy metadata: name:allow-port-from-namespace namespace:internal spec: podSelector:{} policyTypes: -Ingress ingress: -from: -podSelector:{} ports: -protocol:TCP port:9000 # 创建网络策略资源kubectlapply-fnetworkpolicy.yaml

(2)質問2

[候補@ノード-1] $ kubectl config use-context hk8s

タスク:

既存の名前空間 my-app に allow-port-from-namespace という新しい NetworkPolicy を作成します。

新しい NetworkPolicy によって、名前空間 echo 内の Pod が名前空間 my-app 内の Pod のポート 9000 に接続できることを確認します。

新しい NetworkPolicy をさらに確実にします。

  • ポート9000でリッスンしていないポッドへのアクセスを禁止する
  • 名前空間エコーに含まれないポッドからのアクセスを許可しない
kubectlconfiguse-contexthk8s # 编写一个yaml 文件,注意先输入":set paste",防止复制时yaml 文件空格错序apiVersion:networking.k8s.io/v1 kind:NetworkPolicy metadata: name:allow-port-from-namespace namespace:my-app spec: podSelector:{} policyTypes: -Ingress ingress: -from: -namespaceSelector: matchLables: app:echo ports: -protocol:TCP port:9000 # 创建网络策略资源kubectlapply-fnetworkpolicy.yaml

参考文献:

[1]ネットワークポリシー: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.29/#networkpolicy-v1-networking-k8s-io

<<:  Volcano Engine パブリック クラウド シティ共有カンファレンスが成都にやって来て、一緒にクラウドに乗るよう皆さんを招待します。

>>:  NodeSelector から NodeAffinity へ: Kubernetes ノード アフィニティの進化を探る

推薦する

SEOとユーザーエクスペリエンスは密接に関係している

一般的に、SEO とユーザー エクスペリエンスは相互に補完し合います。優れた SEO は、Web サ...

Nutanixのレポートによると、企業はマルチクラウド運用の一貫性を確保するためにハイブリッドクラウドソリューションを必要としている

Nutanix は最近、ハイブリッド クラウドを導入する際に世界中の企業が直面する主な課題と機会を分...

共同購入ウェブサイトは変化を求めている:マーケティングを放棄し、モバイル端末の市場シェアを獲得するための技術に注力

Manzuo.com の黒字化のニュースが出たちょうどその頃、24quan が無期限に営業を停止した...

新しいサイトが含まれない要因と解決策

多くのウェブマスターは、この厄介な問題に遭遇します。なぜ私の新しいサイトはいつも含まれないのでしょう...

RivenCloud: 50% オフ、日本 VPS、大阪/東京、Netflix

Riven Cloudは、米国と香港に登録された新しい会社です。主にVPS事業を展開しており、日本の...

WaveCom が VPS プロバイダー TorqHost を買収

大切な Torqhost のお客様へ。11 月 19 日に、WaveCom LTD と TORQho...

客室乗務員が「代理購入」の罪で有罪判決を受け控訴

「代理購入」で有罪判決を受けた客室乗務員が控訴 王若静/ビジネスデイリー記者アオ・シャンフェイ制作元...

注: Digitaloceanの利用規約が更新され、以前に支払われた金額が変更されました

プロモーションクレジット5.8 2013 年 3 月 6 日現在、プロモーション クレジットの交換は...

人気イベントをオンラインプロモーションに活用する方法

優れた SEO 担当者になりたいのであれば、物事に対する強い感受性と分析力、特にホットな出来事に対す...

V.PS の東京、日本パフォーマンス KVM VPS の簡単なレビュー (高速/高性能/バックアップ付き/トラフィックが使い果たされてもダウンタイムなし)

v.ps 本日、日本の東京データセンターにある「パフォーマンス KVM VPS」を使用しました。これ...

ソフト記事プロモーション:どんなタイトルがすぐに注目を集められるのか?

ソフトテキストプロモーションが効果的かどうかを判断する基準は、消費者の注目を集めることができるかどう...

Baidu による関連性のない静的検索結果ページへの処罰についての考察

「百度のウェブ検索不正対策チームは最近、一部のウェブサイトが人気キーワードを巡り、大量のオンサイト検...

百度鉄馬、網易ブログなど52のウェブサイトがギャングや暴力への関与の疑いで捜査中

新華網、北京、6月5日(記者:屈静)記者が5日、国家新聞出版広電総局から得た情報によると、Sina....

Vultrはどうですか? Vultr UK ロンドンデータセンター評価データ共有

Vultrはどうですか? Vultrはまだ使えますか? Vultr を一度も使用したことがない、また...