应用究竟如何在Kubernetes进行部署和编排,以及数据持久化


最近公司要把一套系统从openstack迁移到docker平台下,老板嫌弃openstack太臃肿。
经过几天调研和试验,产生了好几个疑惑。
应用场景:我们的应用由apache+mysql构成,初步设计为一个pod中跑两个容器,其中一个跑apache,另一个跑mysql。

(1)这样的设计方式是否合理,曾经设想过设计两个pod,一个pod里跑apache,另一个跑mysql,哪种方式更符合k8s最佳实践?

(2)mysql数据持久化的问题:尝试使用hostPath方式挂载本地目录到mysql容器中实现数据持久化,经了解还有emptyDir方式,还有flocker方式等。谁能解释下hostPath和emptyDir方式的区别?或者有好的链接文章共享一下呗,比如k8s中flocker怎么配置。

(3)replication controller的问题:controller配置文件中设置replica数量为2,按照一个pod中跑两个容器的设计,此设置将会同时保持两个pod运行(pod-A和pod-B)。通过cluster-ip访问该service时,会发现时而被路由到pod-A上的apache,时而被路由到pod-B上的apache。这是什么意思呢?为何service充当了负载均衡器的角色?(按我的理解,不知道对不对:replica机制是在pod-A挂掉后,才会用pod-B的)

(4)当replica为2时,将运行两个mysql server,但是他们使用的是(2)中所述的同一个本地数据目录。首先,这导致了mysql的InnoDB引擎必须换为MyISAM引擎,因为前者不支持两个mysql server用同一个数据目录;其次,由于(3)中所述的service提供的类似LB的功能,导致访问apache时会不时报错,提示数据库PDOException(网站用php写的)

总之,上述问题可能是由于设计不当导致的,也许是低级错误,但是这方面最佳实践的资料相当少。。。希望大家帮帮忙。第一次问问题,真的希望大家一起讨论。

部署简图.png
已邀请:

用心阁

赞同来自: henryrao


(1)不合理,一个pod跑web,一个pod跑db,因为web可以独立于db伸缩

(2)持久化的问题推荐使用网络存储,比如ceph,glusterfs等,没有条件可以用hostPath和NFS,前者无法处理pod的迁移,后者性能不够好

(3)pod是短命的,service是长久的,你不能认为宿主机就一定会存在一个pod的实例,并依赖它。 Kubernetes的服务就是对Pod进行负载均衡,并在很多情况下实现服务可用,比如主机故障,比如滚动升级,比如伸缩

(4)你在一台虚拟机上跑两个mysql进程,共享一个数据文件目录也不行啊,在一个节点上跑多个mysql实例也没有意义,应该按照mysql的集群机制,或做主备,或做分片。

beyondblog - 标准90后有为青年

赞同来自:


持久化不要持久化到本地 可以考虑用网络文件系统来持久化

官方已经提供了方案

aws gce 都可以 也可以自己搭建一些开源的 例如 gluster

可以参考这个链接

http://kubernetes.io/docs/user-guide/volumes/

另外 service 不相当于 Load Balancing 这部分的工作应该是 kube-proxy来处理

henryrao - 一個月內拿下k8s

赞同来自:


我目前是通过glusterfs来做网路磁盘

参考这里

方圆小生

赞同来自:


您好,你目前的问题和我们公司的有类似的地方。
第一个问题,我们的理解是,只把Apache放到pod里面,可以启动若干个,mysql还是使用传统的方式,并不使用Docker。

第二个问题,我们任然认为mysql放到容器里面目前不适合我们的需求。

第三个问题,service是用于服务发现的,从节点上的一个组件叫做kube-proxy负责代理和负载均衡,采用轮询算法,也就是一个一个的使用后端的pod。

要回复问题请先登录注册