之前写过一篇文章对cgroup v1进行了介绍，但是由于当前k8s使用cephfs进行数据存储，当多租户使用时，需要对IO进行限制，当前cgroup v1由于memcg与blkio没有协作，导致buffer io的throttle一直没有实现。并且cgroup v1在内核的实现一直比较混乱，其中主要的原因在于，cgroup为了提供灵活性，允许进程可以属于多个hierarchy的不同的group。但实际上，多个hierarchy并没有太大的用处，因为控制器(controller)只能属于一个hierarchy。 所以在实际使用中，通常是每个hierarchy一个控制器。

使用Prometheus对容器服务监控数据的采集及存储，并采用alertmanager进行告警通知，但是随着业务的不断增长，业务对告警的需求十分强烈，基于Prometheus已规则文件的方式下发告警规则，并基于Alertmanager实现告警通知的方式，不算特别灵活。所以想通过其它的告警框架实现对容器的告警。

This time I will be looking at the metrics at the container level. These are the metrics as reported by cAdvisor.

kubernetes 1.8之前如果想要收集k8s集群中关于容器，pod以及kubernetes event相关的监控数据，最好的方案是使用官方提供的heapster,但是1.8之后，该版本被社区给废弃了，取而代替是的社区新孵化的项目metrics-server。本篇文章记录下metrics-server的基本功能，及社区对该服务的定位。

使用kubeflow结合kubernetes进行大规模分布式训练时，由于AI场景下对任务的调度需要: all or nothing, multi-tenant task queue, task priority, preemption,gpu affinity等条件，但是kubernetes默认的调度器对这些条件还没有完全的支持，幸运的是kubernetes社区孵化了一个适合训练的调度器kube-batch。

Tensorflow是Google在2015年11月开源的机器学习框架，来源了Google内部的深度学习框架DistBelief。由于其良好的架构，分布式架构支持以简单易用，自开源以来得到广泛的关注。

MXnet:是灵活且高效的深度学习库。

问题描述

今天一台kubernetes计算节点状态显示异常(NotReady)。首先登陆到计算节点查看Kubelet和Docker进行状态,显示都没有问题。

InfoQ记者张婵于10月30日采访整理

背景

360 在做容器化平台之前，有一个基于小米开源的 Open-Falcon 进行二次开发的老监控系 (Wonder)，这个系统承揽了公司所有的物理机和虚拟机的监控任务。随着容器技术的普及，以容器的方式在创建应用时，由于 Kubernetes 容器编排系统部署的服务具有弹性扩容的特性，而老的监控系统无法感知这些动态创建的服务，已经不适合容器化的场景，所以 360 团队就搭建了一套可以支持服务发现的新监控系统。

Kubeflow是Google推出的基于kubernetes环境下的机器学习组件，通过Kubeflow可以实现对TFJob等资源类型定义，可以像部署应用一样完成在TFJob分布式训练模型的过程。最初的设计是将Kubernetes和Tensorflow结合实现对Tensorflow分布式训练的支持。但是仅仅实现对Tensorflow的支持还是远远不够的，Kubeflow社区又陆续对各种深度学习框架进行支持,例如:MXNet, Caffee, PyTorch等。使得机器学习算法同学只需关心算法实现，而后续的模型训练和服务上线都交给平台来做,解放算法同学使其专做自己擅长的事儿。