k8s-使用Network Policies实现网络隔离
一、需求
Kubernetes 的命名空间主要用于组织和隔离资源,但默认情况下,不同命名空间中的 Pod 之间是可以相互通信的。为了实现更严格的网络隔离,同一套k8s需要根据不同的命名空间进行网络环境隔离,例如开发(dev01)测试(test01)环境。Network Policies 是 Kubernetes 提供的一种机制,用于控制 Pod 间的网络流量。你可以为每个命名空间定义 Network Policies 来限制 Pod 之间的通信。
二、相关解释
- spec.PodSelector
它是pod选择器,基于标签选择与Network Policy处于同一namespace下的pod,如果pod被选中,则对其应用Network Policy中定义的规则。此为可选字段,当没有此字段时,表示选中所有pod。
- spec.PolicyTypes
Network Policy定义的规则可以分成两种,一种是入pod的Ingress规则,一种是出pod的Egress规则。本字段可以看作是一个开关,如果其中包含Ingress,则Ingress部分定义的规则生效,如果是Egress则Egress部分定义的规则生效,如果都包含则全部生效。当然此字段也可选,如果没有指定的话,则默认Ingress生效,如果Egress部分有定义的话,Egress才生效。怎么理解这句话,下文会提到,没有明确定义Ingress、Egress部分,它也是一种规则,默认规则而非没有规则。
- spec.ingress与spec.egress
spec.ingress
和 spec.egress
字段分别用于定义允许进入 Pod 的流量规则和允许离开 Pod 的流量规则。下面详细解释这两个字段的结构和包含的子项。
spec.ingress
结构
spec:
ingress:
- from:
- podSelector:
matchLabels: {} # 选择具有特定标签的 Pod
- namespaceSelector:
matchLabels: {} # 选择具有特定标签的命名空间
- ipBlock:
cidr: 0.0.0.0/0 # CIDR 地址范围
except:
- 10.0.0.0/8 # 排除的 CIDR 地址范围
- ports:
- protocol: TCP # 协议类型
port: 80 # 具体端口
endPort: 8080 # 如果是端口范围,则需要指定结束端口
spec.egress
结构
spec:
egress:
- to:
- podSelector:
matchLabels: {} # 选择具有特定标签的 Pod
- namespaceSelector:
matchLabels: {} # 选择具有特定标签的命名空间
- ipBlock:
cidr: 0.0.0.0/0 # CIDR 地址范围
except:
- 10.0.0.0/8 # 排除的 CIDR 地址范围
- ports:
- protocol: TCP # 协议类型
port: 80 # 具体端口
endPort: 8080 # 如果是端口范围,则需要指定结束端口
示例
假设你有一个 NetworkPolicy,它允许 Pod 接收来自 CIDR 地址范围 192.168.1.0/24
的流量,并允许 Pod 发送流量到 CIDR 地址范围 10.0.0.0/8
,同时只允许通过 TCP 协议的端口 80 和 443 进行通信。
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-traffic
namespace: my-namespace
spec:
podSelector: {}
ingress:
- from:
- ipBlock:
cidr: 192.168.1.0/24
- ports:
- protocol: TCP
port: 80
- protocol: TCP
port: 443
egress:
- to:
- ipBlock:
cidr: 10.0.0.0/8
- ports:
- protocol: TCP
port: 80
- protocol: TCP
port: 443
policyTypes:
- Ingress
- Egress
注意事项
- 适用性: 该 NetworkPolicy 适用于
my-namespace
命名空间中的所有 Pod。 - 流量控制: 控制了 Ingress 和 Egress 流量。
- CIDR 地址范围:
192.168.1.0/24
和10.0.0.0/8
通常用于私有网络。 - 端口控制: 只允许通过 TCP 协议的端口 80 和 443 进行通信。
三、测试规划
1、创建命名空间
2、创建pod和nodeport
3、应用策略之前测试
4、创建网络策略1-pod隔离
5、创建网络策略2-命名空间隔离
6、创建网络策略3-业务命名空间隔离
四、具体实施
1、创建命名空间
创建测试使用的3个命名空间sub1,sub2,sub3。
如果后面的网络策略使用到namespaceSelector,在创建命名空间时需要带label,也可在需要时手动添加label。
kubectl create ns sub1 --labels ns=sub1
kubectl create ns sub2 --labels ns=sub2
kubectl create ns sub3 --labels ns=sub2
如果使用的是私有仓库,注意ns要创建docker-secret。
kubectl create secret docker-registry my-registry-secret --docker-server=DOCKER_REGISTRY_SERVER --docker-username=DOCKER_USER --docker-password=DOCKER_PASSWORD -n namespace
2、创建pod和nodeport
2.1、sub1创建sub1-pod1和sub1-pod1-nodeport,sub1-pod2;
2.2、sub2创建sub2-pod1和sub2-pod1-nodeport,sub2-pod2;
2.3、sub3创建sub3-pod1;
apiVersion: apps/v1
kind: Deployment
metadata:
name: sub1-pod1
namespace: sub1
spec:
selector:
matchLabels:
app: sub1pod1
replicas: 1
template:
metadata:
labels:
app: sub1pod1
spec:
containers:
- name: my-test01-01
image: swr.cn-east-3.myhuaweicloud.com/k8s-imgs/account-platform-admin:dev01-084e7d9
imagePullPolicy: IfNotPresent
imagePullSecrets:
- name: default-secret
imagePullSecrets:
- name: swr-secret --- apiVersion: v1
kind: Service
metadata:
name: sub1-pod1-nodeport
namespace: sub1
spec:
type: NodePort
selector:
app: sub1pod1
ports:
- protocol: TCP
port: 80
targetPort: 8103
nodePort: 32700 --- apiVersion: apps/v1
kind: Deployment
metadata:
name: sub1-pod2
namespace: sub1
spec:
selector:
matchLabels:
app: sub1pod2
replicas: 1
template:
metadata:
labels:
app: sub1pod2
spec:
containers:
- name: my-test01-02
image: swr.cn-east-3.myhuaweicloud.com/k8s-imgs/account-platform-admin:dev01-084e7d9
imagePullPolicy: IfNotPresent
imagePullSecrets:
- name: default-secret
imagePullSecrets:
- name: swr-secret --- apiVersion: apps/v1
kind: Deployment
metadata:
name: sub2-pod1
namespace: sub2
spec:
selector:
matchLabels:
app: sub2pod1
replicas: 1
template:
metadata:
labels:
app: sub2pod1
spec:
containers:
- name: my-test02-01
image: swr.cn-east-3.myhuaweicloud.com/k8s-imgs/account-platform-admin:dev01-084e7d9
imagePullPolicy: IfNotPresent
imagePullSecrets:
- name: default-secret
imagePullSecrets:
- name: swr-secret
--- apiVersion: v1
kind: Service
metadata:
name: sub2-pod1-nodeport
namespace: sub2
spec:
type: NodePort
selector:
app: sub2pod1
ports:
- protocol: TCP
port: 80
targetPort: 8103
nodePort: 32701 --- apiVersion: apps/v1
kind: Deployment
metadata:
name: sub2-pod2
namespace: sub2
spec:
selector:
matchLabels:
app: sub2pod2
replicas: 1
template:
metadata:
labels:
app: sub2pod2
spec:
containers:
- name: my-test02-02
image: swr.cn-east-3.myhuaweicloud.com/k8s-imgs/account-platform-admin:dev01-084e7d9
imagePullPolicy: IfNotPresent
imagePullSecrets:
- name: default-secret
imagePullSecrets:
- name: swr-secret --- apiVersion: apps/v1
kind: Deployment
metadata:
name: sub3-pod1
namespace: sub3
spec:
selector:
matchLabels:
app: sub3pod1
replicas: 1
template:
metadata:
labels:
app: sub3pod1
spec:
containers:
- name: my-test03-01
image: swr.cn-east-3.myhuaweicloud.com/k8s-imgs/account-platform-admin:dev01-084e7d9
imagePullPolicy: IfNotPresent
imagePullSecrets:
- name: default-secret
imagePullSecrets:
- name: swr-secret
查看创建的资源
3、应用策略之前测试
在应用网络策略之前测试各pod之间、pod和外网之间是否可以通信。
sub1-pod1 ping sub1-pod2、sub2-pod1、sub3-pod1、qq.com
外部节点ping sub1-pod1-nodeport、sub2-pod1-nodeport
取k8s集群任一节点ip 10.34.106.14
总结:通过以上测试证明未加网络策略之前pod之间,pod外网之间都是互通的。
4、创建网络策略1-pod隔离
策略描述:在sub1中创建策略,使sub1中pod之间无法通信且和其他命名空间pod也无法通信,只能进出外网。
测试流程:
4.1、sub1-pod1、sub1-pod2、sub2-pod1三者之间互ping不通;
4.2、sub1-pod1、sub1-pod2可以ping通外网(包含域名),外网也能和sub1-pod1-nodeport通信;
本k8s集群pod cidr为:10.243.0.0/16
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: pod-policy
namespace: sub1
spec:
podSelector: {}
ingress:
- from:
- ipBlock:
cidr: 0.0.0.0/0
except:
- 10.243.0.0/16
egress:
- to:
- ipBlock:
cidr: 0.0.0.0/0
except:
- 10.243.0.0/16
policyTypes:
- Egress
- Ingress
解释:
podSelector
:{}
表示选择命名空间中的所有 Pod。ingress
: 定义了进入命名空间的流量控制规则。from
: 表示允许来自哪些来源的流量。ipBlock
: 表示允许来自除了10.243.0.0/16
CIDR 地址范围之外的所有 IP 地址的流量。
egress
: 定义了离开命名空间的流量控制规则。to
: 表示允许流向哪些目的地的流量。ipBlock
: 表示允许流向除了10.243.0.0/16
CIDR 地址范围之外的所有 IP 地址的流量。
policyTypes
: 指定 NetworkPolicy 控制的流量类型,这里包括Ingress
和Egress
。
效果:
- Ingress: 允许所有来源的流量,除了 CIDR 地址范围
10.243.0.0/16
。 - Egress: 允许流向所有目的地的流量,除了 CIDR 地址范围
10.243.0.0/16
。
测试:
创建策略
sub1-pod1 ping sub1-pod2和sub2-pod1 (不通)
sub2-pod1 ping sub1-pod1和sub1-pod2(不通)
sub1-pod1 ping 外网ip(通)
sub1-pod1 ping 域名(不通)-- 因为域名解析服务dns在kube-system空间,而sub1屏蔽了所有空间,下面示例可解决。
外部访问sub1-pod1-nodeport(通)
取k8s集群任一节点ip 10.34.106.14
5、创建网络策略2-命名空间隔离
策略描述:在sub2中创建策略,使sub2中pod之间可以通信但和其他命名空间pod无法通信,也能进出外网。
测试流程:
5.1、sub2-pod1和sub2-pod2之间互ping可通;
5.2、sub2-pod1、sub2-pod2和sub3-pod1之间互ping不通;
5.3、sub2-pod1、sub2-pod2可以ping通外网(包含域名),外网也能和sub2-pod1-nodeport通信;
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: sub2
namespace: sub2
spec:
podSelector: {}
egress:
- to:
- ipBlock:
cidr: 0.0.0.0/0
except:
- 10.243.0.0/16
- namespaceSelector: # 如果不想给命名空间加label,可以换成 - podSelector: {} # 允许来自同一命名空间中的所有 Pod 的流量
matchLabels:
ns: sub2
ingress:
- from:
- ipBlock:
cidr: 0.0.0.0/0
except:
- 10.243.0.0/16
- namespaceSelector: # 如果不想给命名空间加label,可以换成 - podSelector: {} # 允许来自同一命名空间中的所有 Pod 的流量
matchLabels:
ns: sub2
policyTypes:
- Egress
- Ingress
解释
podSelector
:{}
表示选择命名空间中的所有 Pod。ingress
: 定义了进入命名空间的流量控制规则。from
: 表示允许来自哪些来源的流量。ipBlock
: 表示允许来自除了10.243.0.0/16
CIDR 地址范围之外的所有 IP 地址的流量。namespaceSelector
: 表示允许来自具有标签ns=sub2
的命名空间中的 Pod 的流量。from
字段中的podSelector: {}
表示允许来自同一命名空间中的所有 Pod 的流量。
egress
: 定义了离开命名空间的流量控制规则。to
: 表示允许流向哪些目的地的流量。ipBlock
: 表示允许流向除了10.243.0.0/16
CIDR 地址范围之外的所有 IP 地址的流量。namespaceSelector
: 表示允许流向具有标签ns=sub2
的命名空间中的 Pod 的流量。- to字段中的
podSelector: {}
表示允许流向同一命名空间中的所有 Pod 的流量。
policyTypes
: 指定 NetworkPolicy 控制的流量类型,这里包括Ingress
和Egress
。
效果
- Ingress: 允许所有来源的流量,除了 CIDR 地址范围
10.243.0.0/16
和来自其他命名空间的流量,如果使用namespaceSelector则允许进入命名空间具有标签ns=sub2中的pod,如果使用
。podSelector: {}
表示允许来自同一命名空间中的所有 Pod 的流量 - Egress: 允许流向所有目的地的流量,除了 CIDR 地址范围
10.243.0.0/16
和流向其他命名空间的流量,如果使用namespaceSelector则允许流向命名空间具有标签ns=sub2中的pod,
如果使用
。podSelector: {}
表示允许流向同一命名空间中的所有 Pod 的流量
测试
创建策略
sub2-pod1 ping sub2-pod2(通)
sub2-pod1 ping sub3-pod1(不通)
sub3-pod1 ping sub2-pod1、sub2-pod2(不通)
sub2-pod1 ping 外网ip(通)
sub2-pod1 ping 域名(不通)-- 因为域名解析服务dns在kube-system空间,而sub1屏蔽了所有空间,下面示例可解决。
外部 访问sub2-pod1-nodeport(通)
取k8s集群任一节点ip 10.34.106.14
6、创建网络策略3-业务命名空间隔离
实际应用中某些命名空间中的pod可能和其他命名空间中的pod有调用关系,还可能用到一些系统命名空间中的服务(如DNS服务),所以不能将某个命名空间完全和其他所有命名空间隔离,只需要将确定没有业务调用的命名空间隔离。
策略描述:更新第5步sub2中创建的策略,使sub2中的pod除了不能和sub3中的pod通信外,和其他所有地址都可通信。
测试流程:
6.1、sub2-pod1和sub2-pod2互ping可通;
6.2、sub2-pod1和kube-system命名空间中的coredns-pod之间互ping可通;
6.3、sub2-pod1和sub3-pod1互ping不通;
6.4、sub2-pod1可以ping通外网(域名),外网也能和sub2-pod1-nodeport通信;
由于没有直接阻止具有某个label的命名空间配置,所有只能间接通过放行具有某些labels的命名空间以达到阻止的目的。
label设置比较灵活,可根据实际情况配置,有一下几种方式可供参考:
1、可以将放行的所有命名空间配置一个统一的label,这样只需要在配置中放行具有这个label的命名空间即可;
2、也可给每个命名空间配置一个label,这样需要在配置中放行各个不同label的命名空间;
3、可以将通用的系统命名空间设置一个统一的label,给业务命名空间配置不同的label;
本例采用第2种,给所有需要放行的命名空间配置不同的label;
命名空间加label
kubectl label ns kube-system ns=kube-system
kubectl label ns kuboard ns=kuboard
kubectl label ns kube-public ns=kube-public
网络隔离配置
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: ns-policy-2
namespace: sub2
spec:
podSelector: {}
ingress:
- from:
- podSelector: {}
- ipBlock:
cidr: 0.0.0.0/0
except:
- 10.243.0.0/16
- from:
- namespaceSelector:
matchLabels:
ns: kube-system
- from:
- namespaceSelector:
matchLabels:
ns: kuboard
- from:
- namespaceSelector:
matchLabels:
ns: kube-public
egress:
- to:
- podSelector: {}
- ipBlock:
cidr: 0.0.0.0/0
except:
- 10.243.0.0/16
- to:
- namespaceSelector:
matchLabels:
ns: kube-system
- to:
- namespaceSelector:
matchLabels:
ns: kuboard
- to:
- namespaceSelector:
matchLabels:
ns: kube-public
policyTypes:
- Egress
- Ingress
解释
podSelector
:{}
表示选择命名空间中的所有 Pod。policyTypes
:Ingress
和Egress
表示同时控制进入和离开命名空间的流量。ingress
:from
字段中的podSelector: {}
表示允许来自同一命名空间中的所有 Pod 的流量;ipBlock
表示允许来自除了 Kubernetes 内部网络 CIDR 地址范围10.243.0.0/16
之外的所有 IP 地址的流量。egress
:to
字段中的podSelector: {}
表示允许流向同一命名空间中的所有 Pod 的流量;ipBlock
表示允许流向除了 Kubernetes 内部网络 CIDR 地址范围10.243.0.0/16
之外的所有 IP 地址的流量。from
和to
: 使用namespaceSelector
允许放行具有标签ns=kube-system、ns=kuboardns、ns=kube-public
的命名空间中的 Pod 的流量,间接阻止了其他命名空间的流量。
测试
创建策略
sub2-pod1 ping sub2-pod2(通)
sub2-pod1 ping kube-system命名空间中的coredns-pod(通)
sub2-pod1 ping sub3-pod1(不通)
sub2-pod1可以ping通外网、域名(通)
外部 访问sub2-pod1-nodeport(通)
取k8s集群任一节点ip 10.34.106.14
k8s-使用Network Policies实现网络隔离的更多相关文章
- 【Kubernetes】K8S 网络隔离 方案
参考资料: K8S-网络隔离参考 OpenContrail is an open source network virtualization platform for the cloud. – Kub ...
- K8S(03)核心插件-Flannel网络插件
系列文章说明 本系列文章,可以基本算是 老男孩2019年王硕的K8S周末班课程 笔记,根据视频来看本笔记最好,否则有些地方会看不明白 需要视频可以联系我 K8S核心网络插件Flannel 目录 系列文 ...
- eBPF Cilium实战(1) - 基于团队的网络隔离
在 Rainbond 集群中,每个团队对应于底层 Kubernetes 的一个 Namespace ,由于之前使用的底层网络无法进行 Namespace 级别的网络管理,所以在 Rainbond 同一 ...
- 第 8 章 容器网络 - 057 - macvlan 网络隔离和连通
macvlan 网络隔离和连通 验证 macvlan 之间的连通性. bbox1 能 ping 通 bbox3,bbox2 能 ping 通 bbox4. 即:同一 macvlan 网络能通信. bb ...
- 036.集群网络-K8S网络模型及Linux基础网络
一 Kubernetes网络模型概述 1.1 Kubernetes网络模型 Kubernetes网络模型设计的一个基础原则是:每个Pod都拥有一个独立的IP地址,并假定所有Pod都在一个可以直接连通的 ...
- Docker-Bridge Network 03 自定义网络
本节介绍自定义bridge network的自定义网络. 1.前言2.创建自定义网络2.1 创建网络2.2 指定网段创建网络3.创建容器3.1 指定网络创建容器3.2 指定IP创建容器4.通信4.1 ...
- docker学习之network:初识网络配置
起因 我的开发环境需要一个python代码运行环境.reids服务和mysql服务. 由于以前,我的开发环境是mac,而CI和线上运行环境是centos,偶尔会出项本地单元测试跑不过,而CI可以过.这 ...
- routing decisions based on paths, network policies, or rule-sets configured by a network administrator
https://en.wikipedia.org/wiki/Border_Gateway_Protocol Border Gateway Protocol (BGP) is a standardize ...
- NFS - Network File System网络文件系统
NFS(Network File System/网络文件系统): 设置Linux系统之间的文件共享(Linux与Windows中间文件共享采用SAMBA服务): NFS只是一种文件系统,本身没有传输功 ...
- k8s pod的4种网络模式最佳实战(externalIPs )
[k8s]k8s pod的4种网络模式最佳实战(externalIPs ) hostPort相当于docker run -p 8081:8080,不用创建svc,因此端口只在容器运行的vm ...
随机推荐
- 合并STM32 iap的hex文件合并为一个hex文件
--- title: 合并STM32 iap的hex文件合并为一个hex文件 date: 2020-06-15 04:32:26 categories: tags: - iap - stm32 --- ...
- Docker 快速学习手册及相关笔记 附带一些问题解决方案
参考与前言 Docker 官方教程 [英文]:https://docs.docker.com/get-started/ Windows Docker 安装 | 菜鸟教程 (runoob.com) Do ...
- OpenStack 下 CentOS6.X 镜像网络初始化失败问题排查
问题表现 在我的 OpenStack 集群上迁移了一批老旧的镜像(从其他三方云平台过来的)发现这批镜像在使用 ConfigDrive 的方式注入配置初始化时无法对非首张网卡镜像初始化(后经过测试非 C ...
- OpenBMB × Hugging Face × THUNLP,联袂献上经典大模型课
这个夏天,THUNLP 携手 Hugging Face 和 OpenBMB,推出 大模型公开课第二季.在大模型公开课第二季中,将有全球知名开源社区 OpenBMB X Hugging Face 梦幻联 ...
- ELK之Elastic-Search 整理(一):基础理论 与 DSL语法 及 Java操作ES
基础理论和DSL语法 准备工作 什么是ElasticSearch?它和Lucene以及solr的关系是什么? 这些是自己的知识获取能力,自行百度百科 下载ElasticSearch的window版 l ...
- joig2022_e 题解
设计 \(f_i\) 表示以第 \(i\) 个数结尾的选择的最大值. 有 \(f_i = f_j + a_i\)(\(type_i \not = type_j\)). 发现可以选择的种类其实构成两段连 ...
- 记一次win10 python -m http.server 启动后无法访问的经历
前言 最近需要在win10上使用python创建一个http文件服务(默认端口 8000),结果执行了 python3 -m http.server -b 0.0.0.0 后,发现服务跑起来了,但浏览 ...
- 要想业务中台建得快,最好用Service Mesh来带
中国企业数字化转型进入深水区,业务中台及下一代微服务Service Mesh(服务网格)被越来越多的人关注,本文结合网易轻舟微服务Service Mesh实践,解析业务中台为什么需要Service M ...
- yolov5 损失函数代码详解
前言 模型的损失计算包括3个方面,分别是: 定位损失 分类损失 置信度损失 损失的计算公式如下: 损失计算的代码流程也是按照这三大块来计算的.本篇主要讲解yolov5中损失计算的实现,包括损失的逻辑实 ...
- 记一次 redis 事件注册不当导致的内存泄露
线上的程序跑着跑着内存越来越大,并且没有下降的趋势,重启一下程序也只能短暂恢复.通过 htop 命令再按一下 M 键按内存占用大小排个序,程序会占好几个G.那好,让我们来分析一下. 收集dump 通过 ...