Notice: Constant WP_DEBUG already defined in /var/www/html/wordpress/wp-content/plugins/changyan/sohuchangyan.php on line 12

Notice: Constant WP_DEBUG_LOG already defined in /var/www/html/wordpress/wp-content/plugins/changyan/sohuchangyan.php on line 13

Notice: Constant WP_DEBUG_DISPLAY already defined in /var/www/html/wordpress/wp-content/plugins/changyan/sohuchangyan.php on line 14
kubernetes 实战【zoues.com】 – zoues

LOADING

Follow me

kubernetes 实战【zoues.com】
五月 1, 2017|DockerPaaS

kubernetes 实战【zoues.com】

kubernetes 实战【zoues.com】


Docker容器算是目前最火的云计算产品了,因为它解决了很多运维和开发上的痛点问题。

比如抹平了开发和生产的环境区别,甚至可以做到在生产环境使用RHEL,而开发使用Ubuntu,也能平滑部署。

kubernetes 实战


kubernetes 容器平台分析


Docker容器算是目前最火的云计算产品了,因为它解决了很多运维和开发上的痛点问题。

比如抹平了开发和生产的环境区别,甚至可以做到在生产环境使用RHEL,而开发使用Ubuntu,也能平滑部署。

但是想要真正地将其投放到生产环境中,实际上还有很多问题亟待解决。而kubernetes就是这样一个Best Practise。


生产环境容器化的需求


脱离了业务环境的架构都是耍流氓,想要将容器真正落地,就需要真正分析其需求,这里就整理了一下容器化平台的需求。

  • 存储

  • 网络

  • 容器编排和服务发现

  • 负载均衡

  • 日志收集

  • 认证授权

  • 资源配额

  • 分布式服务

可以看到,真正想要部署一个容器平台实际上需要解决的问题是十分繁多的,Docker只是解决了最根本的容器分发和运行,但是kubernetes却解决了上面的大部分问题,这里就一一讲述一下。

存储

容器都是无状态的,很容易就被杀死,然后重新启动,因此存储是重中之重。

Docker自身提供了名为数据卷的存储方案,但是实际上没什么用,因为它支持的最好的就是本地存储,挂在本地路径,这样的强依赖是不可能做到生产环境的分布式服务的,除非每一台容器节点都持有一份同样的文件存储,但是这样会大大地消耗存储空间,而且Docker在文件权限管理等方面也有很多问题。

kubernetes提出的方案是通过持久化存储链,实际上就是做了个抽象层插件,各方可以开发自己的插件用于支持各类存储工具,目前已经支持ceph、glusterfs等主流的分布式文件系统了,但是这些分布式文件系统在部署上都很麻烦,甚至有性能的损失,因此使用nas作为存储是最便捷性能最好的。

网络

网络也是容器平台的重点问题,因为不可能依靠一个容器提供所有的服务,比如一个容器提供了数据库和web服务,而且这样也不利于解耦,因此容器之间需要通过网络通信。

用过Docker自身网络的都知道,Docker实际上是通过网桥来实现容器之间网络通信的,默认设置是无法做到跨节点网络,但是可以通过设置flannel产生一个SDN,然后Docker使用此网络作为容器的网络,这样便能做到跨界点通信。

kubernetes则定义了一套CNI标准,只要符合这套标准就能让kubernetes使用SDN,而目前来说已经有很多软件定义网络实现了这套协议,比如flannel、weave,不过目前而言最好用的还是flannel。

容器编排和服务发现

容器之间存在依赖必然需要编排功能,这也是kubernetes重点解决的问题。

在容器编排上,kubernetes有pod、controller概念,pod可以认为是抽象的容器,它有可变的ip,并且容易被杀死重启。

controller则是控制pod运作的控制器,replication controller、deployment、statefulsets、daemon sets,各有各的用法,比如deployment能够做到水平伸缩。

在服务发现上面,kubernetes有pod、service概念,看到这里相信大家都会有疑问,pod ip 可变总不能每次都要手动改程序或者配置才能访问吧。

实际上kubernetes提供的service就是用来解决这个问题的,service是一套虚拟的ip,service通过selector选择器挑选出自己身后的pod,这样就能做到提供稳固的ip接口,其他容器无需关心数据库的ip,只需要关心数据库这个service就可以。

service本身的ip则不是通过SDN产生的,而是通过iptables导流,将其导入到实际的pod中,但是这样子依旧存在一个问题,就是service的ip同样需要提前知道,这时候就需要服务发现出马了。

kubernetes自身提供了一套简单好用的DNS发现机制,kube-dns将service注册到dns中,通过dns就能解析得到service对应的ip。

负载均衡

负载均衡实际上就是需要一个前端负载均衡器,将流量统一导入到不同的容器中,kubernetes的方案是通过ingress定义规则,然后根据规则产生模板配置,就比如nginx作为负载均衡器,产生配置后reload就能生效。

但是目前官方提供的ingress controller容器镜像存在着一个问题,当ingress定义一个TCP/UDP四层负载均衡转发的时候,nginx容器则必须修改容器部署,因为需要绑定主机端口。

因此目前最好的方案还是通过云服务器提供商的负载均衡器,比如GCE、AWS提供的负载均衡器。

日志收集

日志收集实际上不光是收集容器通过标准输出标准错误产生的日志,还需要收集容器运行时信息,比如内存、cpu占用等信息,这里不细讲了,因为无论是Docker还是kubernetes都提供了收集方案,不过kubernetes更加灵活好用,并且收集的信息更全面,连容器节点的信息都能收集。

认证授权

kuberentes有几大组件apiserver、controller manager、scheduler、proxy、kubelet,所有的组件都通过apiserver通信和管理,因此需要通过认证和授权来防止非法操作。

在这上面kubernetes提供了很多方案,比如 basic auth、bearar token、keystone等,但是真正能投入生产环境使用的,只有OpenID Connector,不知道这种认证授权的可以自行谷歌。

更糟的是,官方甚至没有提供部署方案,需要自行研发OpenID Connector服务器并且部署下去。CoreOS倒是开源了一套dex系统,但是这玩意实际上也不靠谱,照样需要研发力量的支持,从这上面就决定了kubernetes高门槛的准入标准。

资源配额

kubernetes资源配额方案非常丰富,无论是存储配额还是内存甚至是cpu限额,都可以通过yaml文件定义。

分布式服务

分布式服务是大规模运行容器平台的关键,因为容器平台必然是部署在多节点上的,而kubernetes天生就是为分布式部署开发的,apiserver、controller manager、scheduler实际上就是主节点,而proxy和kubelet则是每个slave节点都需要的。

不过目前主流的做法包括kubeadm半自动部署方案都是让主节点通过kubelet在容器中运行apiserver等东西。


总结

想要在生产环境大规模应用容器化技术,看似开源了产品,但是kubernetes本质上是一个半成品,甚至连自动化部署方案都不成熟,并且需要研发力量的支持才能真正运行起来。

以笔者个人的意见来说,kubernetes实际上并非是一个面向企业终端用户的产品,而是一个面向云计算厂商的半成品,它真正的用法应当是云计算公司提供自动化节点部署方案。

云计算平台提供SDN 、负载均衡和分布式存储,甚至可能的话,让云计算厂商提供一套管理控制web界面,并且做好认证授权系统。

kube-dashboard这个官方提供的web ui界面实际上功能是全了,但是认证授权功能的缺失则导致普通用户很难部署使用,或者说kube-dashboard本来就不是为了普通用户部署而开发的,而是为了提供给厂商做二次开发准备。

kube-dashboard则是负责定义web管理界面应该有哪些功能。

文章来源:

https://www.warmbloom.com/kubernete-in-action/?utm_source=tuicool&utm_medium=referral

文中图片来自网络

no comments
Share