Brains


Algorithm、Machine Learning、Search、cloud computing
on kubernetes, Docker, container

CRI & runc 介绍

kubernetes CRI kubernetes是一个容器编排系统,可以便捷的部署容器,它同时支持Docker和Rocket两种容器类型。然而不管是Docker还是Rocket都需要通过内部、不太稳定的接口直接集成到kubelet的源码中,这样的集成过程需要开发者十分熟悉kubelet内部原理,同时维护起来也非常麻烦。在kubernetes1.5版本中,提供了一个清晰定义的抽象层消除了这些障碍,开发者可以专注于构建他们的容器运行时,这个抽象层称作Container Runtime Interface(CRI)接口,下面介绍一下CRI这个概念。 CRI CRI是一个插件接口,这个接口的引入使得kubelet不用重新编译的情况下管理多种容器类型。CRI主要由gRPC API和protocol buffers组成,它的架构图如下所示: kubelet与容器运行时(或者是CRI shim)之间的通信是借助gRPC框架通过unix套接字完成的,kubelet作为client,CRI shim作为server来实现。对于docker容器而言,dockershim是kubelet的CRI shim,它负责与kubelet的gRPC客户端进行通信。 CRI shim的gRPC API主要包括Image Service和Runtime Service两部分,其中Image Service主要用来拉取、检查和删除镜像文件,而Runtime Service主要用来管理Pod和container的整个生命周期。 kubernetes拉起Docker的过程 在kubernetes中,是由kubelet组件来完成启动Docker容器的过程。
Read More
on deployment, strategy

容器编排服务变更策略调研

容器编排服务变更策略调研 本文调研目前流行的三款容器编排平台的服务变更策略,包括kubernetes、swarm、nomad。 其中它们的版本信息如下: 下面分别介绍一下这些平台的服务变更策略。 kubernetes 在Kubernetes中,是由deployment控制器来控制服务变更的过程,它目前提供了两种服务变更策略,分别是: Recreate RollingUpdate 下面分别介绍一下这两种服务变更策略。 Recreate Recreate这种服务变更策略非常简单粗暴,要把deployment关联的现存Pod全部杀掉之后,才能进行升级。 RollingUpdate RollingUpdate是滚动更新的意思,可以通过这种策略来精确的控制服务变更的过程。在deployment中有两个字段是与服务变更的过程有关,分别是Max Unavailable和Max Surge,下面分别介绍一下这两个字段的含义。 Max Unavailable .spec.strategy.rollingUpdate.maxUnavailable是一个可选的字段,用来表明在升级过程中Pod的最大不可用数目,如果超过这个数目的话,deployment便不会销毁旧的实例,停止更新的过程。 这个值可以是一个绝对数值,也可以是一个百分比,默认值是25%。有一点需要注意的是,当.spec.strategy.rollingUpdate.maxSurge为0时,.spec.strategy.rollingUpdate.maxUnavailable不能为0。
Read More
on Linux, Namespace, Kernel

Linux Namespace简介

Linux Namespace简介 Linux Namespace提供了一种内核级别隔离系统资源的方法,通过将系统的全局资源放在不同的Namespace中,来实现资源隔离的目的。不同Namespace的程序,可以享有一份独立的系统资源。目前Linux中提供了六类系统资源的隔离机制,分别是: Mount: 隔离文件系统挂载点 UTS: 隔离主机名和域名信息 IPC: 隔离进程间通信 PID: 隔离进程的ID Network: 隔离网络资源 User: 隔离用户和用户组的ID 下面简单的介绍一下这些Namespace的使用和功能。 Namespace的使用 涉及到Namespace的操作接口包括clone()、setns()、unshare()以及还有/proc下的部分文件。为了使用特定的Namespace,在使用这些接口的时候需要指定以下一个或多个参数: CLONE_NEWNS: 用于指定Mount Namespace CLONE_NEWUTS: 用于指定UTS Namespace CLONE_NEWIPC: 用于指定IPC Namespace CLONE_NEWPID: 用于指定PID Namespace CLONE_NEWNET: 用于指定Network
Read More
on Linux, Memory, Study

内存寻址之段页存储机制分析

背景 学习操作系统这门课的时候,曾不止一次的接触到操作系统的段页式管理机制,但当是都是浅尝辄止,不知道操作系统为啥要有这个机制。如今时间过去很久,关于这个机制的背后的原理和实现机制,早已忘记很久了。。最近在看操作系统方面的知识,借此把自己的理解记录一下。 要理解段页式管理机制的发展历程,还得从早期的处理器的寻址方式说起。 内存寻址方式的发展历程 首先简单的介绍下内存寻址的概念,现代计算机是基于冯.诺依曼的体系结构,这个体系结构是以存储为中心的,也就是说所有的运算的前提都是先从内存中取得数据,所以内存寻址技术从某种程度上代表了计算机技术。 直接寻址 在处理器发展的早期阶段,Intel 公司推出了第一款8位的处理器--8080,它的内存寻址的方式简单粗暴,程序都是通过硬编码的形式绝对定位到内存地址。这种情况下的程序都有明显的缺点:可控性弱、难以重定位、难以维护等。 分段 很快在 Intel 推出的另一款处理器 8086 中,它可以寻址空间达到 1M,即地址线扩展到了 20 位,由于当时制造20位的寄存器比较困难,为了能在 16 位的寄存器的基础上寻址 20 位的地址空间,引入了一个重要的概念——段,段的地址存放在寄存器中,换句话说把
Read More
on Docker, HA, registry

基于kubernetes的Docker Registry的高可用部署

写在前面 在kubernetes集群中运维生成环境的服务已经长达半年多时间,我们遇到了很多问题,也踩到了很多坑,其中因为 Docker Registry 的故障而导致的不可用事件还是挺多的,这些问题常常被用户埋怨。 Docker Registry 作为镜像仓库、数据中心,在整个服务发布流程中是异常关键的一环。由于之前初期我们搭建的 Docker Registry 是通过 docker run 跑在单机的方式,这种情况下不仅有单点问题,还面临着磁盘损坏和镜像丢失的危险性。 后来为了提高平台的稳定性和可靠性,也为了我的毕业论文,特地的花时间来调研 Docker Registry 的部署和设计方案,这个方案不仅采纳了开源社区和其他公司的部署策略,同时也结合了本公司内部的基础上而设计的一套高可用的 Docker Registry 方案。 调研初期 在2017年3月份时候有幸参加了 ebay 公司举办了亿贝TechDay活动,在这次公开技术分享中,我不仅见识了由DaoCloud技术合伙人孙宏亮大神所分享的Docker安全思考,也同时领略了其他公司关于kubernetes、关于docker、关于registry的思考和尝试。 携程、京东的 Docker Registry 的部署过程中,都用到了一个harbor的开源镜像管理软件,这是我第一次接触这个项目。
Read More

虚拟化学习小组分享之——Borg论文解读

背景简介 组里目前支持了一个非常重要的业务,为了支持业务快速的扩展,更好的进行产品维护,决定成立一个虚拟化学习小组。主要宗旨就是为了提升大家对虚拟化、资源管理这方面知识的理解,共同调研生产环境下关于资源虚拟化方面的主流解决方案 Borg论文解读 先贴上原文的地址:http://static.googleusercontent.com/media/research.google.com/en//pubs/archive/43438.pdf 这里先做一下论文的简要梳理,然后对比一下开源平台kubernetes Borg简介 Borg是什么呢?它是Google公司的大规模分布式的集群管理系统,负责管理、调度、运行和监控公司绝大部分的应用程序和框架包括Gmail、Google Docs、Web Search这样的应用程序,也包含一些底层的框架Map Reduce计算框架、GFS分布式的存储系统、Big Table。主要是解决了这么几个问题 隐藏了资源管理和故障处理细节,使其用户可以专注应用开发 支持应用程序做到高可用和高可靠 提升了资源利用率,有效的降低了成本 整体框架 整体来看,Borg是一个典型的分布式平台架构,每个节点部署一个代理(
Read More