Edge Define: To Extend

Kubernetes 生态越来越成熟，围绕 k8s 做产品或者平台的开发，有时为了快速验证或者做 demo 免不了需要在本地设备上搭建 k8s 集群，而且目前大家使用的设备普遍差不多 8 核 16G 内存的配置，通过 VirtualBox 基本可以创建 1-2 台 2C4G 的虚拟机出来，做为本地临时 k8s 集群也足够了。 今天就总结一下，如何从创建 VirtualBox 虚拟机开始，到通过 kubeadm 搭建本地 k8s 集群，希望对准备上手的同学们有所帮助。 注： 部分步骤需要科学上网，解放社会主义生产力。 VirtualBox 虚拟机创建 下载 CentOS 镜像 这里我们使用 CentOS 7，安装镜像下载地址：https://www.centos.org/download/ 点击 «DVD ISO» 并选择喜欢的镜像下载链接就好。 vm 创建 VirtualBox 通过界面创建 vm 过程非常简单，只需要点击“新建”，填写名称，下一步，设置内存大小，下一步，点击“创建” 即可。 vm 启动前配置 启动虚拟机前，有三个地方需要在“设置”里配置下： 虚拟 CPU 的个数 网络，推荐配置两个网卡，一块 Host-Only 用于组本地局域网，一般情况下 IP 固定；另一块桥接网络（Bridged）或者 NAT，用来连接网络，包括局域网及公网，优先尝试桥接网络，如果发现不能分配到 IP 或者网络功能不正常，停掉配置成 NAT； 加载安装镜像，选择上面下载好的 CentOS 7 ISO 镜像文件

熟悉 docker 及 kubectl 的同学们，很大概率使用过 -it 的交互方式，效果是通过一个可交互的伪终端来实现对目标容器的控制。 今天介绍一下，如何通过 Python 程序实现类似 kubectl exec -it 的 Kubernetes 容器控制程序。 基本原理 在开始控制 Kubernetes 容器之前，我们首先要了解下伪终端或 pty 的基本概念及原理。 pty 定义 The pty module defines operations for handling the pseudo-terminal concept: starting another process and being able to write to and read from its controlling terminal programmatically. 伪终端就是通过 fork 一个新的进程，并能够通过程序控制从原始控制终端中读取或是写入数据。 新进程的写入 stdin 会重定向到原生终端的写入 stdin，新进程的输出 stdout 及 stderr 读取自于原始控制终端的 stdout 及 stderr。 读取和写入部分看起来特别像是管道的概念，但是不同的就是原始进程是一个 termial，除输入和输出外， 还有窗口大小控制、termial mode(raw, cbreak) 还包括 alternative buffer mode（vim 使用的）这些终端独有的特性。

Tensorflow 分布式训练的各种玩儿法 - 蹭 1.8 的热度 Tensorflow 1.8 发布了！ 保持着差不多一个月一个版本，够可以的！ 完整 Release Note 请移步 Github。 抛开 Tensorflow Lite 不说，我特别关心的是这一条： Can now pass tf.contrib.distribute.MirroredStrategy() to tf.estimator.RunConfig() to run an Estimator model on multiple GPUs on one machine 解读下：TF 高层（high level） API Estimator 通过 MirroredStrategy() 支持单机多卡分布式了（In-graph replication, all-reduce synchronous）。 我们有理由相信，后面应该会有更多的分布式策略被支持，多节点，异步，模型并行等。 而我们的目标呢，在某些场景下基于目前的机房建设肯定是多机多卡才够劲儿。 所以，今天就简单总结下，我了解的 Tensorflow 分布式训练的各种玩儿法，以及接下来会继续跟进的几个方向。 1. 经典 ps & worker 模式 假定大家对 Tensorflow 的一些基本概念及架构已经有所了解，在开始介绍经典模式之前， 只简单介绍下分布式涉及到的一些重点概念及策略对比： 模型并行 vs 数据并行 模型并行：模型的各个部分并行于多个计算设备上；适应场景大模型，单个设备容不下；或者模型本身有比较好的并行性；

Git Project branching & releasing model In short, use tag to track every releases and use branch to keep developing parallelized. Two main branches During the project development lifecycle, there will be two branches that are almost always there and be used often. Also, they carry all the release tags. master( or develop) branch We consider origin/master to be the main branch where the source code of HEAD always reflects a state with the latest delivered development changes for the next release.

背景 Alluxio 简介 Alluxio（之前名为Tachyon）是世界上第一个以内存为中心的虚拟的分布式存储系统。它统一了数据访问的方式，为上层计算框架和底层存储系统构建了桥梁。 应用只需要连接Alluxio即可访问存储在底层任意存储系统中的数据。此外，Alluxio的以内存为中心的架构使得数据的访问速度能比现有常规方案快几个数量级。 Alluxio 架构及组件 核心组件： Master： 主从，有高可用配置方案 Worker：Alluxio的Worker负责管理分配给Alluxio的本地资源。这些资源可以是本地内存，SDD或者硬盘，其可以由用户配置。 Alluxio的Worker以块的形式存储数据，并通过读或创建数据块的方式处理来自Client读写数据的请求。但Worker只负责这些数据块上的数据；文件到块的实际映 射只会存储在Master上。 Client：与Alluxio服务端交互的入口。它为用户暴露了一组文件系统API。Client通过发起与Master 的通信来执行元数据操作，并且通过与Worker通信来读取Alluxio上的数据或者向Alluxio上写数据。 关键功能： 灵活的文件API： Alluxio的本地API类似于java.io.File类，提供了 InputStream和OutputStream的接口和对内存映射I/O的高效支持。我们推荐使用这套API以获得Alluxio的最好性能。 另外，Alluxio提供兼容Hadoop的文件系统接口，Hadoop MapReduce和Spark可以使用Alluxio代替HDFS。 层次化存储：通过分层存储，Alluxio不仅可以管理内存，也可以管理SSD 和HDD,能够让更大的数据集存储在Alluxio上。数据在不同层之间自动被管理，保证热数据在更快的存储层上。自定义策 略可以方便地加入Alluxio，而且pin的概念允许用户直接控制数据的存放位置。 统一命名空间： Alluxio通过挂载功能在不同的存储系统之间实 现高效的数据管理。并且，透明命名在持久化这些对象到底层存储系统时可以保留这些对象的文件名和目录层次结构。 关键配置： alluxio.user.file.readtype.default CACHE_PROMOTE Default read type when creating Alluxio files. Valid options are CACHE_PROMOTE (move data to highest tier if already in Alluxio storage, write data into highest tier of local Alluxio if data needs to be read from under storage), CACHE (write data into highest tier of local Alluxio if data needs to be read from under storage), NO_CACHE (no data interaction with Alluxio, if the read is from Alluxio data migration or eviction will not occur).

摘要 距离上次聊 Calico 已经过去快半年的时间了，数人云也一直在努力将容器网络方案应用到企业客户的环境中，Calico v2.0 也马上就要发布了，这次跟大家一起感受下新版. 需要说明下，本人跟 Calico 没有任何直接关系，也只是个»吃瓜群众»，做为使用者，想跟大家聊聊心得而已。 这次分享的内容主要包括： 简单总结下作为使用者我看到的 Calico 的变化，包括组件，文档和 calicoctl ； Demo 一些简单的例子，会和 MacVLAN 做一下对比说明原理； 最后总结下适合 Calico 的使用场景； Calico 简介回顾 首先，还是简单的回顾下 Calico 的架构和关键组件，方便大家理解。 Calico 架构 Calico 是一个三层的数据中心网络方案，而且方便集成 OpenStack 这种 IaaS 云架构，能够提供高效可控的 VM、容器、裸机之间的通信。 结合上面这张图，我们来过一遍 Calico 的核心组件： Felix，Calico agent，跑在每台需要运行 workload 的节点上，主要负责配置路由及 ACLs 等信息来确保 endpoint 的连通状态； etcd，分布式键值存储，主要负责网络元数据一致性，确保 Calico 网络状态的准确性； BGP Client(BIRD), 主要负责把 Felix 写入 kernel 的路由信息分发到当前 Calico 网络，确保 workload 间的通信的有效性； BGP Route Reflector(BIRD), 大规模部署时使用，摒弃所有节点互联的 mesh 模式，通过一个或者多个 BGP Route Reflector 来完成集中式的路由分发； 通过将整个互联网的可扩展 IP 网络原则压缩到数据中心级别，Calico 在每一个计算节点利用 Linux kernel 实现了一个高效的 vRouter 来负责数据转发 而每个 vRouter 通过 BGP 协议负责把自己上运行的 workload 的路由信息像整个 Calico 网络内传播 － 小规模部署可以直接互联，大规模下可通过指定的 BGP route reflector 来完成。

摘要 随着容器的火热发展，数人云 越来越多的客户对容器网络特性要求也开始越来越高，比如： 一容器一IP 多主机容器互联 网络隔离 ACL 对接 SDN 等等 这次主要跟大家聊聊 Docker 的网络方案，首先是现有容器网络方案介绍， 接下来重点讲解 Calico 的特性及技术点，作为引申和对比再介绍下 Contiv 的特性, 最后给出对比测试结果。 现有的主要 Docker 网络方案 首先简单介绍下现有的容器网络方案，网上也看了好多对比，大家之前都是基于实现方式来分1， 隧道方案 通过隧道, 或者说 overlay network 的方式： Weave，UDP 广播，本机建立新的 BR，通过 PCAP 互通。 Open vSwitch(OVS)，基于 VxLAN 和 GRE 协议，但是性能方面损失比较严重。 Flannel，UDP 广播，VxLan。 隧道方案在 IaaS 层的网络中应用也比较多，大家共识是随着节点规模的增长复杂度会提升， 而且出了网络问题跟踪起来比较麻烦，大规模集群情况下这是需要考虑的一个点。 路由方案 还有另外一类方式是通过路由来实现，比较典型的代表有： Calico，基于 BGP 协议的路由方案，支持很细致的 ACL 控制，对混合云亲和度比较高。 Macvlan，从逻辑和 Kernel 层来看隔离性和性能最优的方案，基于二层隔离，所以需要二层路由器支持，大多数云服务商不支持，所以混合云上比较难以实现。 路由方案一般是从 3 层或者 2 层实现隔离和跨主机容器互通的，出了问题也很容易排查。 我觉得 Docker 1.