Fork me on GitHub

Kubernetes的DaemonSet(下篇)

用Daemon Pod来进行通信

使用Pod来再DaemonSet中通信的手段有:

  • 推的方式:在DaemonSet中的Pod会被配置成发送更新到如状态数据库这样的服务。这些都没有客户端。

  • IP+端口方式:DaemonSet中的Pod可以使用主机端口。因此通过node的IP就可以访问。客户端知道了node的IP,就可以用实现约定配置好的端口进行通信了。

  • DNS方式:用同样的Pod选择器创建一个headless service,可以通过DNS使用终端资源或者获取数据的方式来探测DaemonSets。

  • 服务方式:用同样的Pod选择器来创建一个服务,使用这个服务来与任意一个node的后台进程通信。

 

更新一个DaemonSet

node标签一旦被改变,DaemonSet会迅速的添加Pod到最新匹配的node上,并且从最新不匹配的node上删除Pod。

修改DaemonSet创建的Pod是可以修改的。但是Pod不允许所有的字段都被更新。而且,DaemonSet控制器会使用原来的模板进行下一次的node创建。

DaemonSet也是可以删除的。如果用kubectl指定了--cascade=false,那Pod就会留在node上。可以用一个不同的模板创建一个新的DaemonSet。当有匹配的标签出现时,可以用不同模板生成的新的DaemonSet来识别出所有已经存在的Pods。如果Pod模板不匹配,则不会修改或者删除Pod。

在Kuberntes版本1.6或以后,可以使用DaemonSet的滚动更新。

 

DaemonSet的可选项

初始化脚本

直接在node上运行守护进程肯定是可以的(比如使用init,upstartd或者systemd方式来启动)。但是如果使用DaemonSet会有很多好处。

  • 像管理应用一样监控和管理守护进程。

  • 与应用使用相同的配置语言和工具(如Pod templates,Kubectl)

  • 在container里使用资源限制运行守护进程增强了守护线程和app容器的隔离性。然而,这个也可以通过在container而不是pod里运行daemon进程完成。

裸Pod

直接指定node来创建Pod是可以实现的。但是DaemonSet可以自动替换由于任何原因被删除的或者停止的Pod,以防止node挂了或者其他类型的node维护,比如kernel升级。

静态Pod

通过在被Kubelet监听的目录下创建文件的方式生成Pod是可以实现的,它们被称为静态Pod。不像DaemonSet,静态Pod不能被kubectl或者其他K9s API客户端管理。静态Pod不依赖apiserver。一般是集群启动时候用到的。在后续的版本中,静态Pod可能被废弃。

Deployment

DaemonSet与Deployment的相同点是他们都用于创建Pod,这些Pod是不期望被意外停止的。

使用Deployment可以管理无状态服务,如前端服务,它需要扩容和缩容指定的副本数,还可以滚动升级。而使用DaemonSet最重要的是产生一个Pod一直运行在指定的或者全部的宿主机上,或者是需要比其他的Pod先启动的场景。

 

相关阅读

 

《两地书》--K8s基础知识

Kubernetes的污点和容忍(上篇)

Kubernetes的污点和容忍(下篇)

Kubernetes的DaemonSet(上篇)

 

 

作者简介

作者是一个有美国硅谷、日本东京工作经验,十二年坚持一线写代码的程序媛。坚持原创文章。欢迎技术交流!


posted @ 2019-03-29 00:07 编程一生 阅读(...) 评论(...) 编辑 收藏