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 ノード アフィニティの進化を探る

推薦する

2020年上半期の我が国のクラウドコンピューティングの発展に向けた5つのキーワード

現在、「クラウド化」は企業開発におけるトレンドや考え方として徐々に定着しつつあります。クラウド コン...

マッシュルーム VPS: 韓国のデータセンター/BGP 回線/30% 割引/KVM/100M 帯域幅

Mushroom Host moguhost は、OpenStack クラウド アーキテクチャを採用...

映画会社はインターネットマーケティングモデルを利用して興行収入の主な魅力となっている

マーケティングについての基本的な理解についてお話しいただけますか。あるいは、マーケティングのような一...

gcorelabs: 専用サーバーが 40% オフ、オプションのデータセンターが 26 か所、月額 69 ユーロから、香港/日本/韓国/シンガポール/米国など。

ルクセンブルクの大手サーバープロバイダー gcorelabs は現在、すべてのコンピュータールームを...

フォーラム署名をマーケティングプロモーションに巧みに活用する

外部リンクを作成する友人の多くは、フォーラムで外部リンクを宣伝することを好みます。アンカー テキスト...

Alibaba Cloud がクラウドベースの「スーパーコンピューティング センター」E-HPC を開始

9月12日、アリババクラウドのエラスティック高性能コンピューティングプラットフォームE-HPCが招待...

クラウド コンピューティングは製造業にどのように役立ちますか?

クラウド コンピューティングは世界中の産業に革命をもたらしましたが、製造業も例外ではありません。テク...

ブログマーケティングを利用して病院ネットワークへのトラフィックを誘導する方法

医療分野で働く人なら誰でも、医療ウェブサイトが大量生産されており、それが「盲目的な」ユーザーエクスペ...

SaaS がクラウド サービスを再定義、企業は今後どこに向かうべきか?

SaaS エンタープライズ ソフトウェアは現在、エンタープライズ ソフトウェア全体に占める割合は比較...

ブルークラウドCEOウェンダ・ケ氏との独占インタビュー:経営とはバランスの芸術

『CHO 最高人事責任者のビジネスと管理レビュー』(以下、「CHO」)は、Zhaopin.com が...

Amazon Web Services、新たな分析サービス Amazon Clean Rooms を開始

アマゾン ウェブ サービスは、2022 年 12 月 9 日に開催された2022 re:Invent...

ビッグニュース: Azure SQL Database マネージドインスタンスが中国でリリースされます

[51CTO.com からのオリジナル記事] 最近、Microsoft は今年最も重要なクラウド サ...

企業がクラウドへの移行から真のROIを得る方法

クラウドへの移行には多大なコストもかかり、企業が求めている価値を実際に得るためには、ワークロードの一...

dedipathはどうですか?ニューヨークデータセンターのVPSのレビュー

dedipathはどうですか? Dedipath New York Data Centerはどうです...