摘要:中暴露服务访问自己实现了一个,它本质上是包装了,在真正创建负载均衡器上它会调用来创建自身的。
Kubernetes概述
最近的一年,kubernetes的发展如此闪耀,正被越来越多的公司采纳用于生产环境的实践。同时,我们可以在最著名的开发者问答社区StackOverflow上看到k8s的问题数量的增长曲线(2015.5-2016.5),开发者是用脚投票的,从这一点看也无疑证明了k8s的火爆程度。
k8s来源于Google生产环境的实践,社区活跃度很高,在github上的Star数17k+,30k+commits,同时由Google主导CNCF基金会也在强力运作k8s的社区发展,也就在几个月前OpenStack社区宣布全面拥抱k8s,这也宣布了全球第大的开源IAAS云社区已经选择k8s作为容器的唯一解决方案。
谈到k8s,无论怎样的议题怎样的开始,我们都先介绍一个k8s整体架构(如下图所示):
etcd 作为配置中心和存储服务,保存了所有组件的定义以及状态,k8s的多个组件之间的互相交互也主要通过etcd;
kube-apiserver 提供和外部交互的接口,提供安全机制,大多数接口都是直接读写etcd中的数据;
kube-scheduler 调度器,主要干一件事情,监听etcd中的pod目录变更,然后通过调度算法分配node,最后调用apiserver的bind接口将分配的node和pod进行关联;
kube-controller-manager 承担了master的主要功能,比如和CloudProvider(IaaS)交互,管理node,pod,replication,service,namespace等。
基本机制是监听etcd /registry/events下对应的事件,进行处理;kubelet 主要包含容器管理,镜像管理,Volume管理等;kube-proxy 主要用于实现k8s的service机制。提供一部分SDN功能以及集群内部的智能LoadBalancer。
本文分享的内容主要是在minion节点上的pod和service上,pod是k8s应用的具体实例抽象,而service便是这些抽象的集合。
ClusterIP & NodePort & Loadbalancer回到本文的主题,在k8s中暴露Service访问(无论内部还是外部),都要经过kube-proxy,比如下图中我们定义一个Service,便可以通过访问Service的80端口转发到Pod的9376端口上。
kube-proxy在转发时主要有两种模式Userspace和Iptables。如下图,左侧是Userspace模式,也是kube-proxy默认的方式,所有的转发都是通过kube-proxy软件实现的;右侧是Iptables模式,所有转发都是通过Iptables内核模块实现,而kube-proxy只负责生成相应的Iptables规则。从效率上看,Iptables会更高一些,但是需要Iptables version >=1.4.11,Iptables模式在k8s1.2版本放出,是否开启使用还需要具体斟酌。
从Service本身看,有三种方式来暴露访问:
ClusterIP:使用集群内的私有ip —— 这是默认值
NodePort:除了使用cluster ip外,也将service的port映射到每个node的一个指定内部port上,映射的每个node的内部port都一样。
LoadBalancer:使用一个ClusterIP & NodePort,但是会向cloud provider申请映射到service本身的负载均衡。
LoadBalancer Provider主要有aws、azure、openstack、gce等云平台提供。相关实现可以在k8s的源码中看到,如下图所示:
IngressIngress也是k8s中多带带定义的对象(如下图所示),它的作用就是实现对外暴露访问的负载均衡,那么它和Service本身LoadBalancer有哪些区别呢?Ingress支持L4、L7负载均衡,LoadBalancer设计上只支持L4;Ingress基于Pod部署,并将Pod网络设置成external network;Ingress controller支持Nginx、Haproxy、GCE-L7,能够满足企业内部使用。
在实际使用时,Ingress的架构如下图所示:
但是在实际使用中,pod可能会产生漂移,由于Ingress Controller也是基于Pod部署,这样Ingress对外的IP会发生变化。在企业内部都会在防火墙上给Service的访问IP设定规则,而IP变动对这一机制是致命的,因为企业不可能经常手动修改防火墙规则。
那么我们就需要一个VIP功能,同时也要能保证Ingress的HA。我们可以考虑在Ingress Controller基础上增加一个keepalived,可以利用keepalived+haproxy的机制来完成VIP的功能。要实现这一机制,可以参考并改动k8s社区中的contrib-keepalived-vip机制。
除了以上介绍的暴露服务机制,还有Hpcloud-service-loadbalancer ,它实现了支持keepalived+nginx、F5、OpenStack Lbaas这些方式,并且支持L4 & L7负载均衡,但是与k8s社区本身的发展机制并不兼容,所以一直没有被合并到社区中。另外还有 Contrib-service-loadbalancer ,这个是社区内部正在发展的,它的想法更远大,考虑会支持Cross-namespace、 Cross-cluster这种级别的负载均衡,同时也是设计了插件机制,目前支持Haproxy,同样也支持L4 & L7负载均衡。
Rancher K8s中暴露服务访问Rancher自己实现了一个rancher-ingress-controller,它本质上是包装了k8s-ingress-controller,在真正创建负载均衡器上它会调用Rancher Cattle API来创建Rancher自身的LB。
相关代码也是开源的,https://github.com/rancher/lb...,lb-controller在启动时候会指定provider为rancher,对应的实现也可在package provider/rancher中看到。
创建Ingress后,也可在Rancher UI上展现出来。
创建过程,可以看我录制这段视频教程,http://v.youku.com/v_show/id_...
文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。
转载请注明本文地址:https://www.ucloud.cn/yun/28003.html
摘要:中暴露服务访问自己实现了一个,它本质上是包装了,在真正创建负载均衡器上它会调用来创建自身的。 Kubernetes概述 最近的一年,kubernetes的发展如此闪耀,正被越来越多的公司采纳用于生产环境的实践。同时,我们可以在最著名的开发者问答社区StackOverflow上看到k8s的问题数量的增长曲线(2015.5-2016.5),开发者是用脚投票的,从这一点看也无疑证明了k8s的...
摘要:通过暴露是社区的一个开源项目,你可以通过来部署更新应用排查应用故障以及管理集群资源。执行以下命令安装,使用的镜像已经去掉了的证书限制。不支持的版本范围。通过ULB暴露Kubernetes DashboardDashboard是Kubernetes社区的一个Web开源项目,你可以通过Dashboard来部署更新应用、排查应用故障以及管理Kubernetes集群资源。另外,Dashboard还提...
摘要:本文将介绍通过强身份验证如何确保企业的集群免受外部攻击。服务器虽然面向公开,但是受到证书身份验证的保护。年年底被爆出的首个严重安全漏洞,就是由联合创始人及首席架构师发现的。 毋庸置疑,K8s已经成为云容器编排系统的标准,但是,如果缺乏K8s环境相关的安全问题认识的话,会致使各种组件暴露在网络集群内外的攻击之下。本文将介绍通过强身份验证如何确保企业的K8s集群免受外部攻击。 showIm...
摘要:部署只是一种规则,控制器组件会将这一规则应用于实际负载均衡器中。原因是功能仅允许将端口用于路由,负载均衡器和则可作为全局启动。负载均衡的限制提供了功能丰富的负载均衡器支持详细介绍在此。截至目前,我们暂时无法使用工具将负载均衡器配置从转换为。 如果您的应用程序是面向大量用户、会吸引大量流量,那么一个不变的目标一定是在高效满足用户需求的同时、不让用户感知到任何类似于服务器繁忙!的情况。这一...
阅读 1186·2021-11-22 12:05
阅读 1319·2021-09-29 09:35
阅读 617·2019-08-30 15:55
阅读 3110·2019-08-30 14:12
阅读 938·2019-08-30 14:11
阅读 2863·2019-08-30 13:10
阅读 2389·2019-08-29 16:33
阅读 3312·2019-08-29 11:02