Kubernetes Network Policy

简介: Kubernetes Network Policy

Network Policy介绍

Network Policy介绍

  • 网络策略(NetworkPolicy)是一种关于 Pod 间及与其他Network Endpoints间所允许的通信规则的规范。
  • NetworkPolicy 资源使用 标签 选择 Pod,并定义选定 Pod 所允许的通信规则。
  • 网络策略通过网络插件来实现。要使用网络策略,用户必须使用支持 NetworkPolicy 的网络解决方案。
  • 默认情况下,Pod间是非隔离的,它们接受任何来源的流量。
  • Pod 可以通过相关的网络策略进行隔离。一旦命名空间中有网络策略选择了特定的 Pod,该 Pod 会拒绝网络策略所不允许的连接。(命名空间下其他未被网络策略所选择的 Pod 会继续接收所有的流量)
  • 网络策略不会冲突,它们是附加的。如果任何一个或多个策略选择了一个 Pod, 则该 Pod 受限于这些策略的 ingress/egress 规则的并集。因此策略的顺序并不会影响策略的结果。

Network Policy 简单例子

首先分别在两个namespace创建pod:

apiVersion: v1
kind: Namespace
metadata:
  name: network-policy-1
---
apiVersion: v1
kind: Namespace
metadata:
  name: network-policy-2
---
apiVersion: v1
kind: Pod
metadata:
  name: busybox-1
  namespace: network-policy-1
  labels:
      name: busybox-1
spec:
    containers:
        - name: busybox
          image: busybox:1.28
          command: ['sh','-c','sleep 3600']
          imagePullPolicy: IfNotPresent
---
apiVersion: v1
kind: Pod
metadata:
  name: busybox-2
  namespace: network-policy-2
  labels:
      name: busybox-2
spec:
    containers:
        - name: busybox
          image: busybox:1.28
          command: ['sh','-c','sleep 3600']
          imagePullPolicy: IfNotPresent

未部署NetworkPolicy之前,两个不同namespace的pod是可以相互通信的。

busybox-2   1/1     Running   0          23s   10.244.139.253   k8s-calico-node02   <none>           <none>
❯ kubectl get pod -n network-policy-1 -o wide
NAME        READY   STATUS    RESTARTS   AGE   IP              NODE                NOMINATED NODE   READINESS GATES
busybox-1   1/1     Running   0          26s   10.244.195.91   k8s-calico-master   <none>           <none>
#刚开始busybox-1和busybox-2是可以互相访问的
❯ kubectl exec -n network-policy-1 busybox-1 -- ping 10.244.139.253
PING 10.244.139.253 (10.244.139.253): 56 data bytes
64 bytes from 10.244.139.253: seq=0 ttl=62 time=1.220 ms
64 bytes from 10.244.139.253: seq=1 ttl=62 time=1.079 ms
64 bytes from 10.244.139.253: seq=2 ttl=62 time=1.093 ms
64 bytes from 10.244.139.253: seq=3 ttl=62 time=1.044 ms
❯ kubectl exec -n network-policy-2 busybox-2 -- ping 10.244.195.91
PING 10.244.195.91 (10.244.195.91): 56 data bytes
64 bytes from 10.244.195.91: seq=0 ttl=62 time=0.998 ms
64 bytes from 10.244.195.91: seq=1 ttl=62 time=1.230 ms

默认拒绝所有入口流量

部署一条NetworkPolicy,作用在namespace为network-policy-1的pod上,禁止入访流量:

---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: network-policy-1 #networkPolicy配置在busybox-1的namespace,不允许外部流量主动访问
spec:
  podSelector: {}
  #policyType写了Ingress,在Ingress里没写内容,表示拒绝所有ingress流量
  policyTypes:
  - Ingress
#busybox-1可以访问busybox-2
❯ kubectl exec -n network-policy-1 busybox-1 -- ping 10.244.139.253
PING 10.244.139.253 (10.244.139.253): 56 data bytes
64 bytes from 10.244.139.253: seq=0 ttl=62 time=2.895 ms
64 bytes from 10.244.139.253: seq=1 ttl=62 time=0.605 ms
#busybox-2无法访问busybox-1
❯ kubectl exec -n network-policy-2 busybox-2 -- ping 10.244.195.91
^C

默认允许所有入口流量

在前面那条NetworkPolicy不删除的同时,添加一条允许所有入访流量的networkPolicy,流量最终会允许。可以看到只要流量能够匹配到一条满足放行的NetworkPolicy,则流量就会被放行。

---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-all-ingress
  namespace: network-policy-1
spec:
  podSelector: {}
  #policyType写了Ingress,在ingress写了{},表示放行所有ingress流量
  ingress:
  - {}
  policyTypes:
  - Ingress
#两条networkPolicy同时存在
❯ kubectl get -n network-policy-1  networkpolicies.networking.k8s.io
NAME                   POD-SELECTOR   AGE
allow-all-ingress      <none>         27s
default-deny-ingress   <none>         94s
#busybox-2重新可以访问busybox-1了
❯ kubectl exec -n network-policy-2 busybox-2 -- ping 10.244.195.91
PING 10.244.195.91 (10.244.195.91): 56 data bytes
64 bytes from 10.244.195.91: seq=0 ttl=62 time=1.057 ms
64 bytes from 10.244.195.91: seq=1 ttl=62 time=0.872 ms

Network Policy 综合例子

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: network-policy-cidr
  namespace: network-policy-1
spec:
  podSelector:
    matchLabels:
      name: centos-1  #只有pod的label为name=centos-1的pod才会收到下面的policy的约束
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
           project: centos-2
    - podSelector:
         matchLabels:
            name: centos-2
    - ipBlock:
        cidr: 10.244.0.0/16 #只允许源是10.244.0.0/16的网段来访问
        except:
        - 10.244.195.0/24  #源是10.244.195.0/24的网段不允许来访问
    ports:
      - protocol: TCP
        port: 80  #只有80端口允许被访问

查看生成的具体规则

❯ kubectl describe -n network-policy-1 networkpolicies.
Name:         network-policy-cidr
Namespace:    network-policy-1
Created on:   2020-05-19 21:01:49 +0800 CST
Labels:       <none>
Annotations:  kubectl.kubernetes.io/last-applied-configuration:
                {"apiVersion":"networking.k8s.io/v1","kind":"NetworkPolicy","metadata":{"annotations":{},"name":"network-policy-cidr","namespace":"network...
Spec:
  PodSelector:     name=centos-1
  Allowing ingress traffic:
    To Port: 80/TCP
    From:
      NamespaceSelector: project=centos-2
    From:
      PodSelector: name=centos-2
    From:
      IPBlock:
        CIDR: 10.244.0.0/16
        Except: 10.244.195.0/24

现在尝试在不同条件下(namespace label,pod label,pod ip地址)去访问名为centos-1的pod,以下表格为整理出的不同条件下的访问结果:(这里的策略是或的关系,只要满足一个就放行)

以下黑色字体加粗的为不满足要求的条件:

namespace label pod label pod CIDR 访问centos1的80端口 ping
project=centos-2 name=centos-2 10.244.139.0/24 可以 不可以
project=centos-2 name=centos-2 10.244.195.0/24 可以 不可以
project=centos-2 10.244.139.0/24 可以 不可以
name=centos-2 10.244.139.0/24 可以 不可以
10.244.139.0/24 可以 不可以
name=centos-2 10.244.195.0/24 可以 不可以
project=centos-2 10.244.195.0/24 可以 不可以
10.244.195.0/24 不可以 不可以

Network Policy 与和或的关系

这个策略表示放行namespace label为project=centos2这个命名空间中的pod,或者pod label为name=centos2的pod:

ingress:
  - from:
    - namespaceSelector:
        matchLabels:
           project: centos-2
    - podSelector:
         matchLabels:
            name: centos-2

注意观察,podSelector前面没有-,此时namespaceSelector和podSelector是与的关系,表示放行的是在namespace label为project=centos2这个命名空间中,并且pod的label为name=centos2的pod。

ingress:
  - from:
    - namespaceSelector:
        matchLabels:
           project: centos-2
      podSelector:
         matchLabels:
            name: centos-2

NetworkPolicy可视化展示

通过https://orca.tufin.io/netpol/ 网站上可以对networkPolicy做可视化展示:

ingress:image.pngegress:image.png

相关实践学习
深入解析Docker容器化技术
Docker是一个开源的应用容器引擎,让开发者可以打包他们的应用以及依赖包到一个可移植的容器中,然后发布到任何流行的Linux机器上,也可以实现虚拟化,容器是完全使用沙箱机制,相互之间不会有任何接口。Docker是世界领先的软件容器平台。开发人员利用Docker可以消除协作编码时“在我的机器上可正常工作”的问题。运维人员利用Docker可以在隔离容器中并行运行和管理应用,获得更好的计算密度。企业利用Docker可以构建敏捷的软件交付管道,以更快的速度、更高的安全性和可靠的信誉为Linux和Windows Server应用发布新功能。 在本套课程中,我们将全面的讲解Docker技术栈,从环境安装到容器、镜像操作以及生产环境如何部署开发的微服务应用。本课程由黑马程序员提供。 &nbsp; &nbsp; 相关的阿里云产品:容器服务 ACK 容器服务 Kubernetes 版(简称 ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情: https://www.aliyun.com/product/kubernetes
目录
相关文章
|
Kubernetes 安全 API
Kubernetes系统安全-授权策略(authorization policy)
文章主要介绍了Kubernetes系统中的授权策略,包括授权模块的概述、RBAC授权模块的详细说明以及如何创建和管理角色(Role)和集群角色(ClusterRole)。
221 0
Kubernetes系统安全-授权策略(authorization policy)
|
Kubernetes 开发工具 容器
【kubernetes】解决k8s1.28.4:NotReady message:Network plugin returns error: cni plugin not initia...
【kubernetes】解决k8s1.28.4:NotReady message:Network plugin returns error: cni plugin not initia...
2149 0
|
存储 Kubernetes Linux
From Docker to Kubernetes(二)- Docker Network
From Docker to Kubernetes(二)- Docker Network
From Docker to Kubernetes(二)- Docker Network
|
Kubernetes 容器 Perl
k8s基础网络Cluster Network模型
k8s基础网络Cluster Network模型
307 0
k8s基础网络Cluster Network模型
|
canal Kubernetes 网络协议
Kubernetes必备知识: Network Policy
网络策略(Network Policy )是 Kubernetes 的一种资源。Network Policy 通过 Label 选择 Pod,并指定其他 Pod 或外界如何与这些 Pod 通信。 Pod的网络流量包含流入(Ingress)和流出(Egress)两种方向。默认情况下,所有 Pod 是非隔离的,即任何来源的网络流量都能够访问 Pod,没有任何限制。当为 Pod 定义了 Network Policy,只有 Policy 允许的流量才能访问 Pod。
781 0
Kubernetes必备知识: Network Policy
|
4月前
|
人工智能 算法 调度
阿里云ACK托管集群Pro版共享GPU调度操作指南
本文介绍在阿里云ACK托管集群Pro版中,如何通过共享GPU调度实现显存与算力的精细化分配,涵盖前提条件、使用限制、节点池配置及任务部署全流程,提升GPU资源利用率,适用于AI训练与推理场景。
431 1
|
4月前
|
弹性计算 监控 调度
ACK One 注册集群云端节点池升级:IDC 集群一键接入云端 GPU 算力,接入效率提升 80%
ACK One注册集群节点池实现“一键接入”,免去手动编写脚本与GPU驱动安装,支持自动扩缩容与多场景调度,大幅提升K8s集群管理效率。
303 89
|
9月前
|
资源调度 Kubernetes 调度
从单集群到多集群的快速无损转型:ACK One 多集群应用分发
ACK One 的多集群应用分发,可以最小成本地结合您已有的单集群 CD 系统,无需对原先应用资源 YAML 进行修改,即可快速构建成多集群的 CD 系统,并同时获得强大的多集群资源调度和分发的能力。
449 9
|
9月前
|
资源调度 Kubernetes 调度
从单集群到多集群的快速无损转型:ACK One 多集群应用分发
本文介绍如何利用阿里云的分布式云容器平台ACK One的多集群应用分发功能,结合云效CD能力,快速将单集群CD系统升级为多集群CD系统。通过增加分发策略(PropagationPolicy)和差异化策略(OverridePolicy),并修改单集群kubeconfig为舰队kubeconfig,可实现无损改造。该方案具备多地域多集群智能资源调度、重调度及故障迁移等能力,帮助用户提升业务效率与可靠性。
|
11月前
|
存储 Kubernetes 监控
K8s集群实战:使用kubeadm和kuboard部署Kubernetes集群
总之,使用kubeadm和kuboard部署K8s集群就像回归童年一样,简单又有趣。不要忘记,技术是为人服务的,用K8s集群操控云端资源,我们不过是想在复杂的世界找寻简单。尽管部署过程可能遇到困难,但朝着简化复杂的目标,我们就能找到意义和乐趣。希望你也能利用这些工具,找到你的乐趣,满足你的需求。
1018 33