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診断依頼であり、SEO診断サービスを提供する企業や個人...

最適なデスクトップ サービス ソリューションを選択する方法

[[428052]]感染症の流行により、在宅勤務は一部の従業員にとっては選択肢ではなくなり、今では主...

ホストハッチ香港はどうですか? Hosthatch 香港 VPS シンプルレビュー

Hosthatch は香港に香港 VPS サービスを展開しています。デフォルトの帯域幅は 10Gbp...

SEOクエイク

SEOquake は、主要な SEO メトリックのほか、SEO 監査などの便利なツールも提供する無料...

Hang Seng ElectronicsのXu Xinpeng氏へのインタビュー:軽量の独自クラウドは、企業がデジタル変革と情報イノベーションという2つの課題を克服するのに役立ちます

現在、金融機関のITインフラは、情報システム運用の中核基盤として、デジタル変革と情報技術変革という二...

79の新しい消費者ブランドマーケティングのヒント

一挙に成功を達成することは、認知において高い地位を占めることである01新しい消費者ブランドは、新しい...

「Dianshi Interactive」ウェブサイトが処罰されたかどうかの簡単な分析

この記事を読む前に、まずはDianshi Interactiveについて学びましょう。Dianshi...

ギャップはどこにあるのでしょうか?中国とアメリカのクラウドコンピューティングベンダー間の競争を技術と市場の観点から見る

ZTE事件以来、米中貿易戦争が激化するなか、「チョークポイント」という言葉が頻繁に聞かれるようになっ...

どのような状況でブラックハット手法がランキング向上に利用できるのか

今日、青島SEOは注文を受けました。クライアントとの電話中、クライアントはウェブサイトのランキングを...

草の根ウェブマスターがあなたの質問に答えます: SEOはそれほど神秘的ではありません

ウェブサイトの運営とプロモーションの過程で、SEO最適化は欠かせない手段であるため、近年、多くのウェ...

頼れる人がいないので、損失を補うために全力を尽くし、百度中毒になることを拒否します

6月中旬から下旬にかけて始まった「百度地震」は、現在も継続中だ。百度の「低品質サイト対策が効果を発揮...

自動車保険のコンプライアンス要件が再度強化されました。 Pingjia Insurance SaaS プラットフォームがディーラーの問題を解決

最近、中国銀行保険監督管理委員会は「保険仲介業者の情報技術業務の監督管理に関する規則」(以下、「規則...

ランディングページのKPIを評価するためのSEO戦略を深める

マーケティングウェブサイトの構築では、SEO戦略を深めるためにランディングページを作成する計画を立て...

ソーシャルQ&AプラットフォームBeeplが正式にリリース

北京時間1月17日、海外メディアの報道によると、3か月間の社内テストを経て、ソーシャル質疑応答プラッ...