成长之路
//在大多数业务场景下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阶段。
//最近在将项目上使用的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.
//到目前为止Kubernetes对基于cpu使用率的水平pod自动伸缩支持比较良好，但根据自定义metrics的HPA支持并不完善，并且使用起来也不方便。
下面介绍一个基于Prometheus和Alertmanager实现Kubernetes Pod 自动伸缩的方案，该方案支持任意自定义metrics。思路比较简单：由Prometheus负责收集需要的性能指标（如：当前链接的并发数，当前cpu的使用率等），根据定义好的告警规则生成告警事件，然后将告警事件传递给Alertmanager，由alertmanager触发webhook来实现最终的pod伸缩功能。
//Prometheus是一个开源的监控系统，时间序列数据库。Prometheus一个很重要的方面，它是拥有一个多维的数据模型，并且有相应的查询语言。altermanager用来处理告警信息，与prometheus是分开的两个组件。目前官方已不再维护Promdash,前端绘图采用grafana。
//测试第一篇文章