使用Docker+Kubernetes的正确姿势

Docker技术源于虚拟化,因此一般人都会把Docker容器和虚拟机相提并论,认为容器只不过是在性能损耗上有优势。对于虚拟机,我们一般就把它当作物理机来使用,而对于容器,也可以这么做,但却不是个好的方式,较好的方式是把容器看作一个进程,每个容器运行一个应用进程。我们在宿主机上使用Docker提供的各种命令,可以查看到Docker容器的诸多状态,就像在Linux系统上使用ps命令看进程信息类似,而对于虚拟机,从宿主机上使用命令很难做到这一点。从这个角度来看,也可以得出应该每个容器运行一个进程,而不应该把容器当作虚拟机来看待的结论。最近在看《Kubernetes in action》,里面也提到了一个容器运行多个应用进程带来的一些问题,比如管理容器里面那些进程的任务就交给了我们自己,并且容器输出到stdout的log也会混乱,难以区分哪部分log是哪个进程输出的。所以一个容器应该只运行一个应用进程,这个进程可能会生成其他子进程,但主进程只有这一个,这样对这个进程的生命周期管理就变成了对Docker容器生命周期的管理。

之前学习Kubernetes的时候,也理解不透Pod这个概念的真正目的,只知道一个Pod可以包含多个Container,Pod不能跨Node节点运行。《Kubernetes in action》这本书给了一个清晰的解释,Kubernetes里边Pod是作为一个最小可扩展单元的,当你把2个Container放进同一个Pod里面时,这两个Container要不同时扩展,要不都不扩展,而且这2个Container没办法运行在不同的机器上,因为Pod不能跨机器运行。因此一般来说,一个Pod只包含一个Container,除非有些紧密耦合的Container,才会考虑放到同一个Pod里,这些Container在扩展和收缩上都是一致的。比如对于前端服务和后台数据库服务,应该如何部署,书上给了这么一张图:

这样一来,Frontend pod和Backend pod可以运行在不同的机器上,可以各自扩展而不相互影响。

Service在Kubernetes中可以看作一个包含Pod的集群,一个Service可以包含多个Pod,对Service的请求可以负载均衡到其承载的某个Pod中去。Service和Pod更详细的关系描述可参看官方文档,这里有篇文章也解释的挺不错:

Kubernetes中的PodIP、ClusterIP和外部IP

发表评论

电子邮件地址不会被公开。