拥抱 K8S 系列 -06-K8S 如何解决 docker 部署的问题

我们在前文提到基于docker带来如下四个问题, 那么面对这些问题, kubernetes是如何解决的呢?



第一个: 代码应用扩容带来的问题

前文提到应用在扩容和缩容的时候, 需要手动修改前端代理nginx的配置, 从而实现流量转发的效果, 如下图所示



为了方便大家理解K8S里面概念, 但是我想把架构稍微再做一点点调整, 在nginx和tomcat之间增加一个LVS, 它仅负责四层流量转发

• 可能会有读者想, 增加这个LVS有点多余, nginx代理tomcat即可

• 大家先把这个问题缓一下, 实际工作中大概率不会有人部署架构. 但是我说了, 只是方便大家理解K8S里面的概念. 而且这么实现部署架构, 功能上是完全可行的.

• 这么改造架构以后, 对于nginx来说, 后端就固定为LVS了, tomcat的扩容和缩容与nginx没有任何关系了.

• 接下来就要好好说说这个LVS了. 这个LVS可不是普通的LVS, 而是一个smart-LVS. 它smart的地方就在于能自动探测后端有多少个tomcat应用, 并自动进行关联和转发流量, 如下图扩容的两个新-tomcat, 只要启动成功就会被LVS关联上 .

• 这样就解决了代码应用扩容和缩容带来的需要人工修改配置的问题了吧, 扩容和缩容非常方便了, 不是吗?

• 这时候读者你可能会怀疑? 真有这么好的东西吗? 是有的, 它就是K8S里面的 service. 后端的每个应用会打上一个标签, service会根据指定标签的应用并与之关联, 如下图所示:

或许, 读者会对这个service的实现原理很好奇, 不要着急, 这么深入的原理, 以后再讨论吧. 现在你只需要把service当作一个智能LVS就可以了.



第二个: 端口冲突的问题

不同的docker应用对应宿主机上的映射的端口必须不同, 所以kubernetes通常并不使用这种端口映射方案. 而是采用iptables的方式. kubernetes会给每个service在宿主机上分配一个虚拟网卡和固定ip地址, 每个网卡会桥接到指定标签的容器, 然后添加iptables规则--把某个service的流量转到指定的虚拟网卡, 从而流量进入指定的docker应用. 由于iptables规则是工作在内核层的, 所以不会占用操作系统的端口, 从而没有端口冲突的问题.



第三个: 应用关联的问题

kubernetes内部存在名称空间(namespace)的概念, 所有的应用都必须属于某个名称空间. 可以建立一个名称空间, 包含某个系统相关联的全部应用, 从而实现应用关联的效果. 这个名称空间有点类似文件夹, 把相关联的应用装起来, 如下图所示. 需要特别说明的一点是, 一个名称空间内部相关联的应用可以分布在不同的kubernetes集群的各个节点上的.



第四个: 服务器负载的问题

kubernetes会实时监控每台宿主机上的硬件资源, 对于负载高的宿主机将不再调度docker应用到上面运行, 甚至驱逐节点上资源消耗大的应用到空闲的服务器, 这些对k8s来说这个太小儿科了. 除此之外, k8s还有更加复杂的调度docker容器的策略, 以后有机会再详谈.



至此, docker部署代码带来的四个问题算是得到解决了吧