在Kubernetes上使用CephFS作为文件存储
1.PV ReadWriteMany的需求 最近一个正在开发的服务对PersistentVolume的Access Mode有ReadWriteMany的需求。 PersistentVolume持久化卷(即PV)是Kubernetes对存储的抽象,PV可以是网络存储,不属于任何Node,但可以在每个Node上访问。PV有以下三种访问模式(Access Mode):
1.PV ReadWriteMany的需求 最近一个正在开发的服务对PersistentVolume的Access Mode有ReadWriteMany的需求。 PersistentVolume持久化卷(即PV)是Kubernetes对存储的抽象,PV可以是网络存储,不属于任何Node,但可以在每个Node上访问。PV有以下三种访问模式(Access Mode):
Kubernetes 1.10已经发布,这是2018年第1个版本。以下两个链接是官方对本此更新的介绍: Kubernetes 1.10: Stabilizing Storage, Security, and Networking 1.10 Release Notes 其中比较关键的特性是提高了存储、安全、网络三大特性的稳定性,在安装时可以将DNS服务切换为CoreDNS(当前处于Beta阶段)。另外容器存储接口(CSI)和本地持久化卷(Persistent Local Volumes)进入到了beta阶段。
kubeadm是Kubernetes官方提供的用于快速安装Kubernetes集群的工具,伴随Kubernetes每个版本的发布都会同步更新,kubeadm会对集群配置方面的一些实践做调整,通过实验kubeadm可以学习到Kubernetes官方在集群配置上一些新的最佳实践。
问题发现 最近测试环境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,无法删除。
本文将总结一下我们目前使用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模板生成。
目前我们的一个产品共有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文件,比较原始。
Kubernetes 1.9已经发布,这是2017年第4个版本,也是2017年最后一个版本。以下两个链接是官方对本此更新的介绍: Kubernetes 1.9: Apps Workloads GA and Expanded Ecosystem 1.9 Release Notes 其中比较关键的特性是Apps Workloads API进入GA阶段,升级到了稳定版。 Workloads API GA apps/v1 Workloads API进入GA阶段,升级到了稳定版本并且默认启用。 Apps Workloads API包含DaemonSet, Deployment, ReplicaSet和StatefulSet,是k8s上运行长时运行的无状态服务和有状态服务的基础。
Kubernetes 1.9已经发布,可以开始考虑将团队线上环境的Kubernetes集群从1.7升级到1.8了。 本文记录了在测试环境中的演练过程。 准备 当前Kubernetes 1.8的小版本是1.8.5。 在升级之前一定要多读几遍官方的升级须知Kubernetes 1.8 - Action Required Before Upgrading。其中和我们相关的:
kubeadm是Kubernetes官方提供的用于快速安装Kubernetes集群的工具,伴随Kubernetes每个版本的发布都会同步更新,kubeadm会对集群配置方面的一些实践做调整,通过实验kubeadm可以学习到Kubernetes官方在集群配置上一些新的最佳实践。
前面我们使用Jaeger的all in one docker镜像和Jaeger的HotROD示例应用简单试用了一下, 并对Jaeger的基本概念和组成做了初步了解。接下来该为了在生产环境中部署Jaeger做下一步的试验了。 本篇我们将尝试再Kubernetes集群上部署Jaeger,并使用我们已经存在的Elasticsearch集群作为数据存储。