为了能高效的训练机器学习模型,最近在调研kubeflow结合kubernetes实现模型的多机多卡分布式训练，在部署kubeflow环境时，用到了kube-dns这个组件，便准备深入的了解下kube-dns的安装及原理。

NVIDIA于2016年开始设计NVIDIA-Docker已便于容器使用NVIDIA GPUs。 第一代nvidia-docker1.0实现了对docker client的封装，并在容器启动时，将必要的GPU device和libraries挂载到容器中。但是这种设计的方式高度的与docker运行时耦合，缺乏灵活性。存在的缺陷具体如下:

现在公司线上所有的k8s集群对GPU资源的使用都是nvidia-docker 1.0(历史遗留问题)。并且还专门写了篇文章记录是如何使用的GPU Container on Kubernetes。但是现在的kubernetes1.9推荐使用device plugin的方式来对接外部厂商的资源。这样所有的厂商的资源就不要kubernetes去特定的支持，而是各服务厂商只要按照kubernetes提供的device plugin实现自己的一套就可以了。今天就针对nvidia-docker2.0 进行了下测试。在此做下记录。

对于搞云计算的同学，对容器技术大家应该都不会陌生,容器的资源限制使用的底层技术是cgroups并且容器的隔离使用的是Linux Namespace机制。之前的文章简单的介绍了Linux cgroups。通过本篇文章来给大家介绍下Linux Namespace的机制。

上篇文章介绍了deployment controller的基本原理及功能，kube-controller-manager之Deployment Controller源码解析。并了解了deployment, replicaset和pod三者之间的关系。这篇文章就重点对replicaset controller的源码进行深入的分析下。

kubernetes从1.2版本增加了一个新的资源对象deployment,并且deployment资源对象是使用频率最高的一个资源对象之一。因此很有必要对deployment controller的机制有所了解。

在机器学习，深度学习中，使用GPU加快对模型的训练是不可避免的。由于公司的搜索实验室和人工智能研究院都想使用容器服务平台已容器的方式部署他们的服务，前提就是需要kubernetes对GPU支持。值得高兴的是kubernetes从1.6版本就已经支持了对GPU的支持(只支持单容器单卡)，并且kubernetes团队在1.9版本支持了多容器多卡及对GPU监控指标的暴露。

背景

公司的一些团队想将他们的服务已容器的方式进行快速部署交付。对于一些简单的单体应用，直接通过公司的负载均衡就可以了。但是如果想要将多个小的应用(如:人脸检测，图片检测等)最终归类为一个大的应用来对外提供服务的话，就需要网关来做这件事情。基于该背景，我们调研了下比较流行的微服务网关(Kong)。

在部署etcd集群时，建议使用基数个etcd实例，这样至少可以保证集群有(N-1)/2个实例是可以正常提供服务的。但是如果超过了(N-1)/2个实例故障。就需要使用备份的etcd数据对集群进行容灾恢复。

在我们生产环境部署的etcd集群是5节点，3个节点是本地sata盘，2个节点是ceph盘。本想使用这种方式为数据做HA的。但是由于ceph磁盘的IO很高(至少10ms以上)，经常导致集群不稳定(IO满导致机器假死,etcd实例还存活，但是网络不通)。所以后期直接全部切换到本地sata盘。

说起容器监控，首先会想到通过Cadvisor, Docker stats等多种方式获取容器的监控数据，并同时会想到容器通过Cgroups实现对容器中的资源进行限制。但是这些数据来自哪里，并且如何计算的？答案是Cgroups。最近在写docker容器监控组件，在深入Cadvisor和Docker stats源码发现数据都来源于Cgroups。了解之余，并对Cgroups做下笔记。