微信号:david-share

介绍:乐于分享,才有进步.

Kubernetes vs Openshift, 谁的网络更安全?

2018-04-14 00:00 魏新宇

前言


本文仅代表作者魏新宇的个人观点;在书写过程中,笔者与同事郭跃军进行了技术讨论,大有裨益,在此表示感谢!


一、K8S vs OCP, 网络端口访问方式


我在上一篇文章《深度理解:Openshift端口方式全解析》中,分享了Openshift的网络端口访问方式:其中提到了:Hostport、Nodeport、Hostnetwork、router。

深度理解:Openshift端口方式全解析


而K8S有三种被外部访问方式:NodePort,LoadBalancer 和 Ingress。


我们先开看看OCP和K8S在网络访问方面的异同。



二、OCP的Service IP和K8S的Cluster IP


OCP中的service IP,对应的是K8S的 ClusterIP;无论是Service IP和ClusterIP,都无法被外部直接访问。


而Openshift的Nodeport和K8S的Nodeport是十分类似的;

Nodeport在OCP指的是:将service ip和端口,映射到OCP集群所有node的node ip和指定的端口号(通常是大端口:30000-32767)。




OCP:

在Openshift中,我们知道每个pod有一个IP,通常网段是10.开头的;同时OCP中还有service ip。而nodeport指的是:将service ip和端口,映射到OCP集群所有node的node ip和指定的端口号(通常是大端口:30000-32767)。


为什么将service ip和OCP中所有node做映射?

因为service ip在OCP中是跨node的。


我们看一个service的yaml配置文件,这是一个mysql的service:

这个配置的含义是,采用nodeport的方式,将mysql server的IP和node ip映射,serivce的源端口是3306,映射到node的端口是30306(大端口)。


这样配置完毕以后,外部要访问pod,访问的是nodeip:30306。然后访问请求通过iptables的NAT将nodeip和端口转化为:service ip和3306端口,最终请求通过service负载均衡到pod。



K8S:Nodeport在K8S的定义如下,从描述看,与OCP的nodeport相同:

NodePort: Exposes the service on each Node’s IP at a static port (the NodePort). A ClusterIP service, to which the NodePort service will route, is automatically created. You’ll be able to contact the NodePort service, from outside the cluster, by requesting <NodeIP>:<NodePort>.




在K8S中,还有一个概念:kube-proxy。为service增加proxy,是为了service在集群,被通过API方式访问:

$ kubectl proxy --port=8080

然后可以通过这种方式在内部访问服务:

http://localhost:8080/api/v1/proxy/namespaces/default/services/my-internal-service:http/


kube-proxy目前支持三种模式: userspace、iptable、IPVS


k8s的最开始版本使用的userspace模式,所有的客户端请求svc,都需要先经过iptables,然后在经过kube-proxy到pod,性能很差。


所以在后期版本中K8S增加了iptables方式,在iptables方式下,客户端请求svc会直接经过iptabls转发到pod,而不需要再经过kube-proxy,提高了性能。

但是kube-proxy的缺点是仅支持轮询的负载方式,而且一样存在iptables规则过多导致的性能(iptables是自上而下的匹配,一旦规则多会很慢)。所以目前社区在研究IPVS方式。与iptables类似, ipvs也基于 netfilter 。但ipvs使用哈希表作为底层数据结构,并在内核空间工作,因此IPVS重定向交通速度更快,具有更好的性能。

IPVS支持如下负载均衡策略:

rr: round-robinlc: least connection

dh: destination hashing

sh: source hashing

sed: shortest expected delay

nq: never queue



目前,Openshift安装的时候,模式使用Proxy-mode: iptable模式,也可以修改为Proxy-mode: userspace模式,但没这个必要(因为userspace模式已废弃)。

目前Proxy-mode: ipvs由于在K8S 1.10目前是beta版本,因此在OCP中还没有支持。在K8S正式发布IPVS功能后,相信OCP会同步支持。



三、OCP的router和K8S的Ingress


OCP的router和K8S的Ingress是十分类似的,router和Ingress都是对外暴露http/https类域名。



OCP:


outer本质上,一个router是以hostnetwork方式运行在一个node上的容器化hproxy,它的pod ip就是所在node的ip,对外暴露的端口就是:80、443、1936。


客户端访问某一个应用,如在浏览器中输入http://productpage-istio-system.apps.example.com,首先外部DNS将这个域名解析成router所在node的IP,即:192.168.137.102。



然后,请求到达router所在的node以后,会查询到对应的route信息,查到route对应的service的名称:httpd。此时,通过查询etcd,获取到service和相关的信息。将请求通过service负载均衡发给后端的pod。




K8S:

区别是,OCP用的是容器化的haproxy做router;K8S默认用GCE/Nginx做这件事。



查看ingress的配置:


我们看一下router的dc,我们可以看到,router的安全策略更多一些。



四、K8S的Loadbalance模式


LoadBalancer是K8S借助于cloud provider提供的LoadBalancer,实现被外部网络访问。


LoadBalancer: Exposes the service externally using a cloud provider’s load balancer. NodePort and ClusterIP services, to which the external load balancer will route, are automatically created.


Service的Loadbalancer指定以后,Loadbalancer会将各类访问请求转发到service,HTTP,TCP,UDP,Websocket,gRPC 或其它任意种类。Loadbalancer将会被cloud provider分配一个IP地址。


我们来看一个service的yaml文件,其中制定了loadbalancer:



五、Openshift的路由安全

上面内容已经提到,OCP使用router方式对外暴露80/443/1936端口,为web类应用提供对外访问。


那么,路由的安全如何保证呢?


默认情况,我们expose server,会生成一个域名,这个域名的端口是80:

浏览器访问:


OCP提供三种路由安全策略:Edge Termination(边界终止)、Pass-through Termination(直通终止)、Re-encryption Termination(重加密终止)



Edge Termination(边界终止)的模式,是将安全证书加密到路由上。


Pass-through Termination(直通终止)。这种模式,安全加密不设置在路由上,而是设置在pod中通过证书加密。


Re-encryption Termination(重加密终止),这种模式指的是pod和路由上同时加密,但使用不同的证书。


无论使用哪种方式,创建安全路由以后,应用FQDN的80端口将不能被访问。


我们通过实验进行验证。


我们先生成一个key并进行签名:



然后将旧的路由删掉:

创建新的边界路由:

创建好以后,再度通过80端口方式,失败:

通过443访问,出现安全提示:

添加证书后,可以访问:



六、结论


Kubernetes vs Openshift,谁的网络更安全?


实际上,由于OCP是基于K8S,并且红帽写了大量的K8S代码(2017年K8S代码贡献量第一),因此OCP的网络架构和K8S可以说系出同源。


由于OCP是面向企业级的解决方案,因此会增加更多的安全方面的策略,Openshift的安全加固策略多达70项,如下文:


Openshift容器云安全加固措施70项


不仅仅是网络,Openshift还在其他几个方面做了安全加固:


企业级容器云安全,你需要考虑的九个方面!



参考资料:

  1. https://kubernetes.io/docs/concepts/services-networking/service/#proxy-mode-ipvs

  2. https://docs.openshift.org/latest/rest_api/examples.html

  3. https://medium.com/google-cloud/kubernetes-nodeport-vs-loadbalancer-vs-ingress-when-should-i-use-what-922f010849e0


魏新宇

"大魏分享"运营者、红帽资深解决方案架构师

专注开源云计算、容器及自动化运维在金融行业的推广

拥有红帽RHCE/RHCA、VMware VCP-DCV、VCP-DT、VCP-Network、VCP-Cloud、ITIL V3、Cobit5、C-STAR、AIX、HPUX等相关认证。


文章打赏随意(转发和赞赏都是对作者原创的鼓励):


更多精彩内容,欢迎继续关注大魏分享:


 
大卫分享 更多文章 Ansible Tower标准化管理案例 深度理解:Openshift端口方式全解析 Openshift3.7完整安装手册+容器化Harbor Ansible Tower的安装与基本功能测试 容器编排界的“三皇会战”,Kubernetes的奥斯特里茨!
猜您喜欢 半路学编程,可以成为大牛吗? duang~六个诀窍,让你的电脑店更赚钱! 媲美人类有何不可?深度解读微软新AI翻译系统四大秘技 cSphere希云Docker实训营,第三期火热来袭 当这个年龄的你还在玩王者荣耀时,这群人已经当上了黑客