Kubernetes中的高级调度策略

在大多数业务场景下Kubernetes的默认调度策略都工作得很好,如 :在将一个Pod调度到节点之前,会首选确保改节点有足够的资源(如内存),并且它会试图平衡所有节点资源的使用率。

但是有时候我们会试图控制Pod的调度方式,比如:我们希望一些pod只会被调度到特定硬件的节点上,或者我们希望将通信比较频繁的service(被这些service选择到的pod)被调度到一个节点或者一个机房到节点上,又或者我们希望能指定一组节点提供给特定的用户的业务来使用。总结起来,也就是说我们希望我们能更清楚的知道应用在Kubernetes集群上到底是如何被调度或者部署的。所以从Kubernetes1.6开始,给我们提供了四种高级调度策略:node affinity/anti-affinity, taints and tolerations, pod affinity/anti-affinity, custom schedulers,这些特性在Kubernetes1.6中处于beta阶段。

Continue reading “Kubernetes中的高级调度策略”

Kubernetes mirror pod & static pod

最近在将项目上使用的Kubernetes从1.5.3升级到了1.6.2,性能能正如官方描述的那样的,提升了不少,整个升级过程还算顺利。我们的kubernetes组件启动模式是这样的,kubelet是systemd的方式启动,交由操作系统的systemd进程来管理,kube-apiserver、kube-proxy、kube-controller-manager、kube-scheduler都是以static pod启动,交由kubelet进程管理。也就是说在kubernetes master节点也会启动一个kubelet进程。关于服务发现,我们使用的是CoreDNS,直接以一个Deployment的方式启动,并对应启动一个service,kubelet的启动参数--cluster_dns指定该service的IP即可,具体的操作可以查看CoreDNS官方blog.

Continue reading “Kubernetes mirror pod & static pod”

基于Prometheus,Alermanager实现Kubernetes自动伸缩

到目前为止Kubernetes对基于cpu使用率的水平pod自动伸缩支持比较良好,但根据自定义metrics的HPA支持并不完善,并且使用起来也不方便。

下面介绍一个基于Prometheus和Alertmanager实现Kubernetes Pod 自动伸缩的方案,该方案支持任意自定义metrics。思路比较简单:由Prometheus负责收集需要的性能指标(如:当前链接的并发数,当前cpu的使用率等),根据定义好的告警规则生成告警事件,然后将告警事件传递给Alertmanager,由alertmanager触发webhook来实现最终的pod伸缩功能。

Continue reading “基于Prometheus,Alermanager实现Kubernetes自动伸缩”