十年网站开发经验 + 多家企业客户 + 靠谱的建站团队
量身定制 + 运营维护+专业推广+无忧售后,网站问题一站解决
将系统微服务化后采用dubbo框架开发部署解决模块之间内部调用关系。Dubbo框架中生产者组件会自动启动一个服务端口,在DCOS平台采用弹性伸缩过程中需要考虑服务组件端口冲突和跨容器访问网络问题。于是引入calico网络方案来解决dubbo框架服务调用问题。
成都创新互联主打移动网站、成都网站建设、做网站、网站改版、网络推广、网站维护、域名注册、等互联网信息服务,为各行业提供服务。在技术实力的保障下,我们为客户承诺稳定,放心的服务,根据网站的内容与功能再决定采用什么样的设计。最后,要实现符合网站需求的内容、功能与设计,我们还会规划稳定安全的技术方案做保障。
Calico是一个纯3层的数据中心网络方案,而且无缝集成像OpenStack这种IaaS云架构,能够提供可控的VM、容器、裸机之间的IP通信。
Calico的原理是通过修改每个主机节点上的iptables和路由表规则,实现容器间数据路由和访问控制,并通过Etcd协调节点配置信息的。因此Calico服务本身和许多分布式服务一样,需要运行在集群的每一个节点上。
常见的CNI网络插件包含以下几种:
Flannel:为Kubernetes提供叠加网络的网络插件,基于TUN/TAP隧道技术,使用UDP封装IP报文进行创建叠 加网络,借助etcd维护网络的分配情况,缺点:无法支持网络策略访问控制。
Calico:基于BGP的三层网络插件,也支持网络策略进而实现网络的访问控制;它在每台主机上都运行一个虚拟路由,利用Linux内核转发网络数据包,并借助iptables实现防火墙功能。实际上Calico最后的实现就是将每台主机都变成了一台路由器,将各个网络进行连接起来,实现跨主机通信的功能。
Canal:由Flannel和Calico联合发布的一个统一网络插件,提供CNI网络插件,并支持网络策略实现。
其他的还包括Weave Net、Contiv、OpenContrail、Romana、NSX-T、kube-router等等。而Flannel和Calico是目前最流行的选择方案。
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: deny-all-egress
namespace: cs1
#应用于cs1 名称空间,不写名称空间对default应用
spec:
podSelector: {}
ingress:
egress:
#定义出站规则,这里没有写任何策略,表示全部拒绝。
policyTypes:
- Egress
- Ingress
#这里面有Egress就表示要定义出站规则,不写Egress就是默认通行,Ingress是入站原理一样
#建议大家把两个都写上去 然后使用"podSelector:" 来控制是否能通行
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-all-egress
namespace: cs1
spec:
podSelector: {}
ingress:
- {}
#这样表示"ingress"方向的全部允许通行
egress:
- {}
#这样表示"egress"方向的全部允许通行
policyTypes:
- Egress
- Ingress
这个网络策略只对名称空间起效,宿主机依然可以访问
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: deny-all
namespace: default
#只作用于 default 名称空间
spec:
podSelector:
#匹配pod 范围 如果匹配该名称空间的所有POD 输入"{}" 即可
matchLabels:
access: "true"
#匹配POD中有 access=true的标签
policyTypes:
- Ingress
- Egress
ingress:
egress:
#上图每个cs容器的IP
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: deny-all
spec:
podSelector: {}
policyTypes:
- Egress
- Ingress
ingress:
egress:
- to:
#注意:egress用to,ingress用from
- ipBlock:
cidr: 192.168.0.0/16
#放行192.168.0.0/16网络
except:
- 192.168.94.134/32
#但不包括这个ip
exec进入pod 能看见ping192.168.94.134 这个IP是不通的
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: namespace-allow
namespace: default
spec:
policyTypes: ["Ingress"]
podSelector: {}
ingress:
- from:
- namespaceSelector:
matchLabels:
name: cs1
#表示只有打了"name=cs1"的名称空间才允许进
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: namespace-allow
namespace: default
spec:
policyTypes: ["Ingress","Egress"]
podSelector: {}
ingress:
- from:
- namespaceSelector:
matchExpressions:
- key: name
operator: In
values: ["cs1","cs2"]
#中括号里面的可以 与default名称空间 ingress通信
#表示,名称空间有标签name=cs1,name=cs2 的 可以与default名称空间通信
7基于pod label
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: namespace-allow
namespace: default
spec:
policyTypes: ["Ingress"]
podSelector: {}
ingress:
- from:
- podSelector:
matchLabels:
access: "true"
#允许pod 便签有 access=true的通行
#基于pod label 实验没成功不知道啥问题