有容云

Kubernetes安装环境 Centos7.1系统的机器3台 Master：192.168.0.120 Nodes：192.168.0.106, 192.168.0.107 ===== Master ===== 1 在Master上安装kubernetes etcd flannel yum install kubernetes etcd flannel -y 2 修改配置文件/etc/kubernetes/controller-manager #指定key文件，key文件可以通过命令生成：openssl genrsa -out /etc/kubernetes/service.key 2048 KUBE_CONTROLLER_MANAGER_ARGS=" --service_account_private_key_file=/etc/kubernetes/service.key " 3 修改配置文件/etc/kubernetes/apiserver # The address on the local server to listen to. 设为全部监听 KUBE_API_ADDRESS=" --address=0.0.0.0 " # Comma separated list of nodes in the etcd cluster . 指定etcd节点的地址 KUBE_ETCD

资源分配理念看已有调度器 在资源调度器中，资源分配理念：拍卖、预算或抢占，往往是混合运用。资源分配理念，折射出了资源调度器所在的生态系统或者说周边配合系统的成熟度、运行习惯。例如，Google从最早的广告拍卖机制起，拍卖的理念在Google内部就形成了一种经验、选择的爱好或者内部的默契，那么资源竞拍被分配出来的结果，大家很容易达成一致、理解。而国内企业，往往是预算驱动，周边系统的运行习惯，更趋向预算、采购，谁预算谁使用。这种环境下，资源被谁使用基本可以预见，成本也是比较容易找到归属者。在拍卖机制下资源抢占，初始分配是不大会发生，只有在运行时发生资源不够用的时候出现，低优先级的任务被Kill。在预算机制下，资源分配初期、运行时过程中，都会发生抢占。不同哪种分配背后共同追求的资源流动性是一致的。拍卖的另外一种好处是便于资源流动起来，不仅是资源利用率提升，更是资源投入产出比的最大化。而预算往往是一次性的，重点业务资源优先保障，使得适应性、灵活性、激励业务效率提升变得不如拍卖。 不同策略落地在架构、数据、API层面有着非常多的共同之处。从中不难发现Borg是始祖，后来的Mesos、Omega、Kubernetes、Zeus等都延续着Borg的某些重要特征，而又随技术发展，引入新的特征。针对每个系统的具体分析，可以参照Google

编者注： 本文根据有容云技术实施团队原创分享内容整理。对Docker技术感兴趣、或对本文中细节需继续探讨的朋友，欢迎加入我们参与讨论！ 特别鸣谢中生代技术群分享支持。 注：本期分享由张朝潞原创，有容云整理发布，转载请注明出处 作者介绍： 张朝潞，有容云（Yourun Cloud）平台存储架构师。曾工作于UIT，华三，腾讯，专注分布式存储的研究和开发，对云计算存储解决方案方面有很深的技术造诣和行业理解。 本次交流将与大家分享Docker Volume plugin相关的内容。今日主题是窥探Docker中的Volume plugin内幕。 因为应用数据对安全，可用性，共享，性能等方面的要求和Root Image的要求完全不一样，所以Docker并不推荐采用Root Image的存储方式来存储应用数据，而是采用了Volume这样一个独立的数据访问接口。 应用通过Volume去访问相关的数据，Volume的实现和CoW的分层文件系统完全独立，通过Volume plugin机制可轻易驱动外部存储。 下面我们就围绕Volume Plugin Introduction、Container and Volume、Docker Volume Plugin、自定义Volume Plugin四个方面来展开。 一. Volume Plugin Introduction 通过Volume机制

前言：本文由John Patterson 、 Chris Lunsford写于2016年4月20日，译者 有容云 向波，转载请注明出处。 在本系列文章的第一部分，我们搭建了基本的构建和部署流水线（pipeline）。容器不再是靠登陆服务器，然后输入记忆中的Docker命令来部署。镜像的构建也已经由Jenkins服务器实现了自动化。我们将 Docker 命令写成Bash脚本，保存在Git中，实现了版本追踪。应该说，我们对原有流程做了很大的改进。但是，仍然有一些痛点我们需要关注，在本文中，我们将看一下如何使用Docker Compose和Ansible来优化持续部署工作。 阅读前文请点击： 有容云:实战总结之利用Docker、Docker Compose &Rancher构建持续部署 为了部署一个容器镜像，运维工程师需要登录到服务器中，在shell 中执行含有Docker命令的脚本。这太土了，同时还需要运维等待命令执行完毕。这种模式对整个团队没有任何益处。（作为一个工程师，有多少次你需要盯着本来可以自动化完成的任务？）另外，大多数情况下，运维人员从笔记本上发起的SSH会话中执行命令，部署过程也没有实现可视化记录和日志保留。 如果你还记得，我们的部署脚本应该是如下的样子： 我们已经做到了从Docker run命令中抽象了一层，工程师不需要知道每个镜像成功运行所需要的具体参数

这篇文章希望能够帮助读者深入理解Docker的命令，还有容器（container）和镜像（image）之间的区别，并深入探讨容器和运行中的容器之间的区别。 当我对Docker技术还是一知半解的时候，我发现理解Docker的命令非常困难。于是，我花了几周的时间来学习Docker的工作原理，更确切地说，是关于Docker统一文件系统（the union file system）的知识，然后回过头来再看Docker的命令，一切变得顺理成章，简单极了。 题外话： 就我个人而言，掌握一门技术并合理使用它的最好办法就是深入理解这项技术背后的工作原理。通常情况下，一项新技术的诞生常常会伴随着媒体的大肆宣传和炒作，这使得用户很难看清技术的本质。更确切地说，新技术总是会发明一些新的术语或者隐喻词来帮助宣传，这在初期是非常有帮助的，但是这给技术的原理蒙上了一层砂纸，不利于用户在后期掌握技术的真谛。 Git就是一个很好的例子。我之前不能够很好的使用Git，于是我花了一段时间去学习Git的原理，直到这时，我才真正明白了Git的用法。我坚信只有真正理解Git内部原理的人才能够掌握这个工具。 Image Definition 镜像（Image） 就是一堆只读层（read-only layer）的统一视角，也许这个定义有些难以理解，下面的这张图能够帮助读者理解镜像的定义。 从左边我们看到了多个只读层