2018-02-05
问题发现
#
最近测试环境Kubernetes集群的两台主机重启后，发现这两台主机上(CentOS 7.3)的Pod无法删除。
发现这个问题的经过如下：
某个服务的自动发布触发后，监控系统告警有Pod处于Terminated状态，具体去查看发现前面重启过的两台主机上因为服务发布需要被删掉的Pod一直处于Terminated: ExitCode状态。因为是测试环境，开始没有特别关注，而是直接使用kubectl delete pod <podname> --namespace=<namspacer> --grace-period=0 --force尝试将有问题Pod强制删除，结果强制删除不起作用。马上觉得问题可能没有那么简单，于是分别登录到这两台主机上通过docker ps -a查看对应docker容器的状态，发现这两个Pod的docker容器处于Dead状态。使用docker rm <container id>，提示Device is Busy，无法删除。
...2017-12-29
本文将总结一下我们目前使用Prometheus对Kubernetes集群监控的实践。
我们选择Prometheus作为监控系统主要在以下各层面实现监控：
- 基础设施层：监控各个主机服务器资源(包括Kubernetes的Node和非Kubernetes的Node)，如CPU,内存,网络吞吐和带宽占用,磁盘I/O和磁盘使用等指标。
- 中间件层：监控独立部署于Kubernetes集群之外的中间件，例如：MySQL、Redis、RabbitMQ、ElasticSearch、Nginx等。
- Kubernetes集群：监控Kubernetes集群本身的关键指标
- Kubernetes集群上部署的应用：监控部署在Kubernetes集群上的应用
1.基础设施层和中间件层的监控
#
其中基础设施层监控指标的拉取肯定是来在Prometheus的node_exporter，因为我们要监控的服务器节点既包含Kubernetes节点又包含其他部署独立中间件的节点，
所以我们并没有将node_exporter以daemonset的形式部署到k8s上，而是使用ansible将node_exporter以二进制的形式部署到所有要监控的服务器上。
而负责从node_exporter拉取指标的Prometheus也是用ansible独立部署在Kubernetes集群外部的。Prometheus的配置文件prometheus.yml使用ansible的j2模板生成。
...2017-12-21
目前我们的一个产品共有4套环境:dev环境、test环境、staging环境、production环境。
其中dev, test, staging环境在一个Kubernetes集群上以不同namespace部署，production环境部署在另一个Kubernetes集群上。这个产品总共有14个微服务组成，对应gitlab中14个代码库，Kubernetes的deployment yaml文件也保存在代码库，为每个服务的每套环境以环境名创建了一个目录，里面是yaml文件，yaml文件的内容使用sed实现了简单的模板功能。14个服务*4套环境总共56个yaml文件，比较原始。
...2017-12-16
Kubernetes 1.9已经发布，这是2017年第4个版本，也是2017年最后一个版本。以下两个链接是官方对本此更新的介绍：
其中比较关键的特性是Apps Workloads API进入GA阶段，升级到了稳定版。
Workloads API GA
#
apps/v1 Workloads API进入GA阶段，升级到了稳定版本并且默认启用。
Apps Workloads API包含DaemonSet, Deployment, ReplicaSet和StatefulSet，是k8s上运行长时运行的无状态服务和有状态服务的基础。
...2017-12-16
Kubernetes 1.9已经发布，可以开始考虑将团队线上环境的Kubernetes集群从1.7升级到1.8了。
本文记录了在测试环境中的演练过程。
准备
#
当前Kubernetes 1.8的小版本是1.8.5。
在升级之前一定要多读几遍官方的升级须知Kubernetes 1.8 - Action Required Before Upgrading。其中和我们相关的：
...2017-12-16
kubeadm是Kubernetes官方提供的用于快速安装Kubernetes集群的工具，伴随Kubernetes每个版本的发布都会同步更新，kubeadm会对集群配置方面的一些实践做调整，通过实验kubeadm可以学习到Kubernetes官方在集群配置上一些新的最佳实践。
...2017-12-06
前面我们使用Jaeger的all in one docker镜像和Jaeger的HotROD示例应用简单试用了一下，
并对Jaeger的基本概念和组成做了初步了解。接下来该为了在生产环境中部署Jaeger做下一步的试验了。
本篇我们将尝试再Kubernetes集群上部署Jaeger，并使用我们已经存在的Elasticsearch集群作为数据存储。
...2017-12-06
之前我们已经将Jaeger部署到了Kubernetes上，并且对Jaeger官方的示例应用HotROD进行了分布式跟踪。
我们使用Elasticsearch作为Jaeger的后端存储。借助Jaeger我们可以很容易的进行微服务架构应用的服务链调用追踪，进一步实现应用的性能分析和延迟优化。
...2017-10-19
滚动升级时一种平滑过渡的升级方式，采用的是逐步替换的策略从而保证服务的稳定性，在升级时如果发现问题可以及时回滚、调整问题，尽量让问题不会扩大。我们经常使用Kubernetes的两种资源对象Deployment和DaemonSet的滚动升级，本篇来看一下StatefulSet的滚动升级。
...2017-10-13
最近正在制定将团队生产环境的Kubernetes集群从1.6升级1.7的计划。
Kubernetes 1.8已经发布，所以准备考虑从1.6到1.7的升级。
准备
#
当前1.7的最新版本是1.7.8。在做准备之前需要仔细读一遍官方的Kubernetes 1.7 - Action Required Before Upgrading。
使用ansible升级k8s的核心组件
#
目前我们总共有两个高可用的Kubernetes集群，分别是测试环境和生产环境，版本都是1.6.10。
这两套环境的Kubernetes集群都是基于ansible自动部署，在1.6.x的每个小版本的升级也都是使用ansible完成。
...