搜狗BizCloud基于Kubernetes的私有云实践

  categories:资料  tags:,   author:
【编者的话】随着搜狗业务的快速增长,需要更有效地控制成本,提升研发效率,我们基于Docker和Kubernetes构建了一站式私有云管理平台——BizCloud,此平台涵盖服务管理、弹性伸缩、灰度发布、自动运维、持续集成等功能。本文将简要介绍BizCloud的设计思路、架构及服务发现、授权、灰度发布等核心功能的实现。

BizCloud简介

我们基础环境非常复杂,目前有多个版本操作系统共存,应用也常常存在着多个版本同时测试或部署,在多版本并行测试过程中,经常出现环境借用的情况,因操作系统和基础软件不一致的问题,会出现线下测试没问题,但上线后出问题;其次,线上的实体机在业务低峰时使用率较低,存在较大的提升空间;服务上下线也涉及到一系列机器的申请回收流程,需要手工执行,系统的弹性伸缩能力不足。这种种问题都是我们设计私有云的原因,也就是要做到保持环境一致、提升资源利用率,并提升弹性计算能力。

为了解决上述问题,我们使用目前非常流行的容器技术Docker和容器编排工具Kubernetes,研发了商业云平台BizCloud。但Docker和Kubernenets只提供了一个基础功能:容器运行和容器编排,如何能快速地学会使用,并为大家所接受才是关键。

在自研BizCloud过程中,一个重点就是要对接、打通现存的系统和流程,尽量保持用户操作习惯,服务在容器化的过程中,尽可能不需要调整,这样系统才易于推广落地;另一方面,我们要支持服务一键自动部署(QA特别需要这样的功能),服务出现故障后,如系统宕机或服务挂掉后,服务能自动迁移,而且我们需要支持灰度发布,尽量实现运维的自动化。

商业平台系统的整体架构如下图所示。共分为三层,IaaS层、PaaS层、SaaS层:在IaaS层,我们使用Docker+Kubernetes封装了部门的基础资源,提供容器化服务;PaaS层提供了很多基础服务和基础框架,并且也实现了一些自动化工具,包括刚才提到过的统一服务管理中心,统一配置中心,项目管理系统、SOA服务框架等,贯穿了应用开发、测试、运维整个生命周期的一体化平台,其中的红色部分,包括服务管理、编译中心、商业云平台都是为BizCloud而新开发的模块;第三层SaaS主要是一些商业平台业务系统。本文的分享也主要集中在PaaS层的研发实践上。

关键功能解析

对于一个服务而言,不管是部署还是故障迁移,都有很重要的两个功能:在服务启动之前,要申请服务所需资源的权限,如数据库权限,开通iptables等,也就是服务授权;而服务启动之后,要暴露服务给使用方,现在服务部署到某个机器上了,需要将请求发送到这台机器上,这个过程是服务发现。以往这两个工作主要是人工执行,在BizCloud中,这两个过程需要自动化执行。

自动化执行这个过程需要解决3个问题:1) when,什么时候执行;2)who,谁来执行;3)how,怎么执行。为实现服务版本的平滑过渡,BizCloud也提供了灰度发布功能,以降低上线风险;灰度发布不是一个独立的系统,但和系统的架构是紧密相连的。下面我们分别介绍服务发现,服务授权和灰度发布的实现要点。

服务发现

首先是when,即服务发现和服务授权的发起时间,我们知道在Kubernetes服务里,服务状态的变化和Pod的变化是紧密相连的,因此,我们引入了一个模块k8s-monitor,用来监控并判断发起动作。

k8s-monitor是BizCloud的监控器,其主要功能是监控Kubernetes集群中的Pods的状态事件:ADD、MODIFY、DELETE,监控到事件后,k8s-monitor计算是否需要进行服务发现或服务授权等相关处理,如果需要,则通知下游系统进行处理。除了常规的事件监控之外,k8s-monitor还会定期与服务管理模块同步数据,清理服务管理模块上可能存在的脏数据。

使用k8s-monitor这样一个单独的模块,好处是显而易见的:将相关权限集中管理起来,避免云平台入侵应用,如果没有这样一个模块,每个应用都需要增加自己的的服务授权和服务发现的功能,对模块入侵较大;其次,这个模块非常容易扩展,其他服务也可以订阅这个模块的数据,实现自己的处理逻辑。

通常一个典型的服务都有两层:一个用户接入层,通常是用Nginx接入用户流量,Nginx将流量分发到后面的Web服务器上;第二层SOA层,这里Web服务通过SOA调用后端服务,后端服务也可继续调用其他服务,最终将用户请求返回。在做服务发现时,需要完成这两种类型的服务发现。

首先,对于接入层,如图所示,如果Pod1因故障挂掉,Kubernetes重新调度了PodN之后,k8s-monitor监控到(至少)2个事件:Pod1 DEL,PodN ADD,k8s-monitor将事件通知到服务管理中心。Nginx会实时从服务管理中心获取服务对应关系,动态加载Nginx配置,将已经挂掉的Pod1从Nginx中摘除,新增加的PodN暴露给外部。

而SOA服务的角色分为两种,一种是consumer,一种是provider。consumer和provider之间的负载均衡、白名单控制是通过SOA的注册中心来统一管理。像图里展示的,如果Pod1因故障挂掉,Kubernetes重新调度了PodN之后,k8s-monitor将监控到的事件Pod1 DEL,PodN ADD通知到SOA注册中心,SOA注册中心会将对应的变化更新到ZK上,ZK会触发事件通知服务的consumer获取最新的服务provider。

授权

由于商业平台的特殊性,对权限控制非常严格,权限控制的重要性在于:1)防止测试流量打到线上; 2)防止恶意访问等。以前模式往往是人工检验进行授权,但在云平台上,这种方式不再适用,Kubernetes也没有直接提供授权的功能,而且授权是和系统架构紧密相关的。

为满足BizCloud的需求,对服务授权进行了改造,当时改造面临了一些挑战:首先服务依赖关系从何获取;其次,容器可能随时启动、销毁,服务IP会随容器变动;再次,我们需要同时支持DB授权、IP白名单授权、SOA等不同粒度的授权。

服务授权的发起仍然依赖于k8s-monitor,与服务发现类似,k8s-monitor将监控到的事件Pod1 DEL,PodN ADD,包括一些其他服务基本信息、IP等通知到授权模块,授权模块开始执行授权工作。

刚才说明了授权的时间,但具体给谁来授权呢?如下图所示,每一个服务都有自己的服务配置信息,这里展示一个服务,该服务依赖了很多资源,包Redis、数据库(1个主库、2个从库)等资源。将这些配置文件上传到配置中心后,配置中心会将这些配置解析,然后根据这些依赖关系计算出依赖图,如右图所示。新启动的服务可以从配置中心获取自己的资源依赖关系,要申请的资源。

对于不同类型的授权,我们有不同的处理方式,每种授权对应的粒度也不同:1)DB授权,授权信息包括ip+port+user,通过数据库执行机来执行,将授权信息写入数据库权限表;2)SOA授权,这里授权信息包括服务实例+ip+port,该类授权通过SOA注册中心执行,最终生成服务访问白名单;3)iptable授权,授权信息包括ip+port,这类授权通过salt-stack执行,最终会写入系统的iptables文件。

灰度发布

我们的灰度发布的周期一般比较长,为了保证灰度的一致性,我们会将上下游依赖的服务分组,一个正常组,一个灰度组。在具体执行时,我们会多建一个灰度的Deployment,这样每个服务有2组Deployment,一个正常Deployment、一个灰度Deployment,然后根据灰度比例动态调节正常Deployment和灰度Deployment的实例数,从而实现灰度发布。在流量接入方面,我们已经实现了基于用户ID的灰度,在BizCloud上,我们的灰度分流仍然基于用户ID。

灰度发布时的服务发现同样包括接入层和SOA层两部分:对于接入层,我们使用了OpenResty,并引入了ngx_dynamic_upstream模块,这样可以通过HTTP API方式动态调整服务的Upstream;在SOA层的灰度发布中,我们对consumer-provider划分为了可以动态更新的两个组:正常组和灰度组,k8s-monitor将变更发送到SOA注册中心后,SOA注册中心还是通过ZK通知Consumer取最新的provider分组,从而实现灰度分流。

配套工具

为了更方便地使用BizCloud,我们提供了多个配套工具。

WebShell

首先是WebShell。通过WebShell,我们可以从Web浏览器以类似SSH的方式登录并操作Docker容器,方便开发运维等查看、调试系统。

9.png

Webshell主要有3个组件:1)Web浏览器负责界面呈现;2)Docker Controller是Docker容器应用的控制中心,作为桥梁,负责消息的转发;3)Docker

阅读全文

Kubernetes存储机制的实现

  categories:资料  tags:,   author:

由于容器的使用寿命短,当迁移的应用程序从开发到生产环境时候,开发人员面临着巨大的挑战。当容器挂掉或崩溃时,任何与之相关的数据都会丢失。为了解决这个问题引发的数据丢失,我们需要将数据存储持久化磁盘(PD),也可以称为卷。数据可以通过容器中断事件被写入一个容器外的持久化磁盘。当与POD一起工作时,持久卷呈现出一个重要的优点——在一个通用应用程序堆栈和POD中存在的数据可以被多个容器共享。

在讨论实现持久化存储的不同方式之前,重要的是要了解持久卷的特性。第一个特征是持久化卷的容量。使用持久化卷时候要指定它的容量。截至发稿,容量是唯一一个可以被设置的属性,但是有规划使其他属性如IOPS和吞吐量可以被制定/设置。持久化卷的第二个特性是访问模式。不同类型的持久化存储解决方案有不同的访问方式。访问模式readwriteonce,readonlymany,和readwritemany。

在第一种访问模式中,仅支持单一节点对卷进行读写操作。在第二种访问模式中,支持多个节点读操作和单一节点写操作。在第三种访问模式中,支持多个节点同时进行读写操作。当使用命令行接口时,访问模式是相同的。然而,必须要注意的一个关键点就是:即使一个卷支持多种访问模式但是在同一时间只能使用其中一种。供应商提供的完整版放完模式列表可以从Kubernetes的如下地址获取:https://kubernetes.io/docs/user-guide/persistent-volumes/

Kubernetes对持久化卷的支持比原生的Docker更好。在Kubernetes,卷与PODS是绑定的,他们生命周期的起止也是一致的。PODS的优势在于支持多个不同类型的卷同时关联。在下面文章中,将讨论可以被关联到PODS的卷类型。

临时磁盘是一种非常简洁方法来实现在容器崩溃时候进行持久化操作。临时磁盘使用空目录的磁盘实现。在使用内存中运行node来实现以提高性能这种场景下,存储可以使用临时磁盘来实现。需要着重提醒的是,虽然临时磁盘提供了数据持久化功能,但是当PODs被移除时候仍然会发生数据丢失。还应该注意的是重启时候任何内存中的数据将会丢失。临时存储对于存储被发送其他容器临时进程数据的一个合理解决方案。实施临时磁盘是通过指定一个YAML文件完成。一个YAML文件举例如下。

apiVersion:  v1

kind:     Pod

metadata:

name:   test-gcespec:

containers:

-     image:  nginx:latest

ports:

-     containerPort:   80

name:   test-gce

volumeMounts:
阅读全文

使用Kubernetes-Jenkins实现CI/CD

  categories:资料  tags:,   author:

Author: Ramit Surana DevOps Zone
DevOps Zone让你成为Sonatype Nexus的合作伙伴,Nexus套件能帮助你扩展DevOps交付过程,持续的将组件智能的集成到开发工具中,包括:Eclipse, IntelliJ, Jenkins, Bamboo, SonarQube等等,请看演示

关于持续集成和持续发布,Martin Fowler给出了最好的定义:

“持续集成是一种软件开发实践,团队成员可以频繁的集成他们的工作,通常每个人一天至少一次集成甚至多次集成。每次集成都通过自动化构建和测试进行验证,以尽快检测集成错误。许多团队发现,这种方法可以显著减少集成的问题,并允许团队更加快速的开发。”

简介

本文将讨论和探索两个令人惊奇和相当有趣的技术。一个是Jenkins,一个流行的持续集成/发布的工具,另一个是Kubernetes,一个流行的容器编排引擎。另外一个惊喜,我们发现了Fabric8——一个酷炫的微服务平台。现在,让我们开始吧!

警告:在下文的几个步骤中,你的服务器可能会中途挂起几次,请选择配置高的PC。

方法论

有很多方法,可以让我们实现CI/CD,在本文中,我们重点介绍Kubneretes-Jenkins插件和Fabric8。

总体架构

在开始我们的工作之前,让我们花一点时间分析开始使用Jenkins使用Kubernetes容器所需的工作流。Kubernetes对于开发者来说是一个惊人的开源容器编排引擎。Kubernetes是由Google发起的,这使Kubernetes在使用多个开源容器项目方面有一个惊人的优势。默认情况下,Docker更受Kubernetes的使用者支持和青睐。使用Docker容器的工作流程如下图所示:

20170320212433

与使用rkt容器(rktnetes)类似,如下图:

20170320212443

目前,Jenkins还没有支持RKT容器的插件,但我认为工作流在其实现后也将保持不变。

Kubernetes-Jenkins插件

在你的主机上安装Kubernetes

在主机上安装Kubernetes是一个容易的任务。如果你想在本地机器上试用它,我建议你试试Minikube,这里有快速安装指南:

  1. 确认你的kubectl已经安装完成,参考文档
  2. 确认已经下载完依赖的组件,参考先决条件
  3. 下载、安装Minikube

Carlossg在使用Jenkins和Kubernetes的方面做了惊人的工作,他为Jenkins创建了一个特棒Kubernetes插件,使用这个插件,你可以很容易地直接使用Kubernetes。此外,还为用户提供了更容易的配置选项,他已经构建了一个包含Kubernetes插件的Jenkins镜像,镜像可以在Docker Hub上找到。在接下来的步骤中,我们将从Docker Hub上获取此镜像,并创建一个卷/var/jenkins/_home用于存储Jenkins的数据。

存在一个问题

虽然我们正在做我们计划做的一切,我们仍然会遇到一个问题。 你会注意到,每当你要关闭它后,重新启动你的Jenkins容器,所有的数据都会丢失。 无论你做了什么,例如创建作业,安装插件等等,都会丢失。 这是容器的常见问题之一。 让我们更深入地讨论它。

关于数据容器的一个词

阅读全文

Kubernetes集群中的网络

  categories:资料  tags:,   author:

本文从一个服务的不同访问方式入手,分析了Kubernetes集群中的网络组成,也给出了一个简单可行的网络性能评估方案。

本文适合对虚拟网桥、iptables以及Kubernetes的相关概念有了解的读者。

另外Service-Pod流量转发时提到”iptables转发”,严格说措辞不准确,因为iptables仅负责用数据库维护了Kernel中Netfilter的hook,这样表述是为了便于理解。

另外,本文也希望为以下几个问题找出明确的答案:

  • Service-Pod之间转发流量时,kube-proxy是否承担流量转发?kube-proxy的转发机制是怎么样的?
  • Service-Pod之间(Service对应多个Pod时)的负载均衡的实现原理是怎么样的?是用kube-proxy来做负载均衡吗?

Kubernetes网络组成分析

从不同访问方式的数据流上看,一个Kubernetes集群的网络可以划分为2部分:

  • Kubernetes网络模型实现:如Overlay Network(第三方实现中有Flannel,Contiv等)
  • 集群IP(Cluster IP),用以集群内服务发现,DNS解析等

本节中的试验集群使用Flannel搭建Overlay Network,其他的解决方案没有本质区别。

为了说明Kubernetes集群网络,下面来部署一个Nginx服务,同时部署了2个Pod:

$ kubectl create -f https://raw.githubusercontent.com/yangyuqian/k8s-the-hard-way/master/assets/nginx.yaml

deployment "nginx-deployment" created
service "nginx-service" created

可以直接在主机上用Pod的IP来访问对应的Pod:

$ kubectl get pod --selector="app=nginx" -
阅读全文

swarm与kubernetes的对比

  categories:资料  tags:,   author:

前言:docker swarm 与kubernetes都是集群管理工具,一个是docker原生自带,一个是谷歌项目下的容器编排工具,那么到底他们到底有什么有缺点呢?

kubernetes:

kubernetes,是Google多年大规模容器管理技术的开源版本,是众多厂商推崇的docker管理优秀之作,随着越来越多的厂商不停地贡献代码,kubernetes功能也愈发完善

swarm:

Swarm是Docker公司在2014年12月初发布的一套用来管理Docker集群的较为简单的工具,由于Swarm使用标准的Docker API接口作为其前端访问入口,所以各种形式的Docker Client(dockerclient in go, docker_py, docker等)都可以直接与Swarm通信。随着Swarm0.2发布,swarm增加了新的策略来调度集群中的容器方式,使得在可用的节点上传播它们,以及支持更多的Docker命令以及集群驱动。

swarm结构图

示例

那么到底是docker亲儿子swarm管理上更胜一筹还是Google的kubernetes管理更加受人们青睐,下面是本人总结的对比详情。

swarm与kubernetes

swarm优点:

1 架构简单,部署运维成本较低

docker swarm 集群模式由于原生态集成到docker-engine中,所以首先学习成本低,对于使用docker-engine 1.12版本及以上可以平滑过渡,service服务可以满足动态增减容器个数,同时具备自身的负载均衡,swarm管理者多台设定保证了机器在出错后有一个良好的容灾机制

2 启动速度快

swarm集群只会有两层交互,容器启动是毫秒级

swarm劣势:

1 无法提供更精细的管理

swarm API兼容docker API,所以使得swarm无法提供集群的更加精细的管理

2 网络问题

在网络方面,默认docker容器是通过桥接与NAT和主机外网络通信,这样就出现2个问题,一个是因为是NAT,外部主机无法主动访问到容器内(除了端口映射),另外默认桥接IP是一样的,这样会出现不同主机的容器有相同的IP的情况。这样两容器更加不能通信。同时网络性能方面,有人测试经过桥接的网络性能只有主机网络性能的70%。当然以上问题可以通过其他工具解决,比如用 Flannel 或者 OVS网桥

3

阅读全文

一张图读懂Kubernetes监控与日志

  categories:资料  tags:,   author:

12月2日,时速云应邀参加了清华毛豆网主办的K8S主题技术沙龙,售前工程师赵宇就《Kubernetes监控与日志》做了主题分享。

为了解救懒癌晚期患者,以下是小编为大家整理的分享内容,已将精华浓缩在一张图上~

Tips: 关注时速云公众号(tenxcloud2),回复 “1207”即可下载现场PPT。

也可以直接在 https://www.kubernetes.org.cn//文档下载

 

20161208175645

 

本次分享重点分为两大块:监控和日志。

监控又分资源监控和服务监控两部分。

  • Kubernetes的资源监控主要由kubelet,heapster和storage backends(如Influxdb)构成。Heapster可以在集群范围获取metrics和事件数据。它可以以pod的方式运行在集群中,也可以单独运行。kubelet 从cAdvisor获取数据,heapster组织数据和推送数据到后端存储InfluxDB。cAdvisor不但可以统计节点上每个容器的资源情况,还提供整个节点的资源使用情况。
  • 服务监控则介绍了Kubernetes提供对Pod、容器运行状况的监控,通过RC保持运行数量;Container Probes提供HTTP、TCP的健康监控,保证应用的正常运行。

关于日志,赵宇给大家推荐了开源的日志收集工具Fluentd,因为它具有接口统一、复杂度低、插件丰富、可扩展性高等特性 ;另外还有开源的、实时的分布式搜索和分析引擎。

Elasticsearch可以用于分布式存储以及分布式搜索,可以处理PB级别数据,同时也具备
Restful API、集群编排/单机 + 持久化存储 on kubernetes等特性。

 

来源: https://www.kubernetes.org.cn/993.html

 … 阅读全文

Kubernetes集群中的高性能网络策略

  categories:资料  tags:,   author:

自从7月份发布Kubernetes 1.3以来,用户已经能够在其集群中定义和实施网络策略。这些策略是防火墙规则,用于指定允许流入和流出的数据类型。如果需要,Kubernetes可以阻止所有未明确允许的流量。本文针对K8s的网络策略进行介绍并对网络性能进行测试。

网络策略

K8s的网络策略应用于通过常用标签标识的pod组。然后,可以使用标签来模拟传统的分段网络,这些网络通常用于在多层应用程序中隔离层:例如,您可以通过特定的“段”标签来标识前端和后端pod。策略控制这些段之间的流量,甚至控制来自外部源的流量。

分段流量

这对于应用程序开发人员意味着什么?最后,Kubernetes获得了提供 [深度防御](https://en.wikipedia.org/wiki/Defense_in_depth_(computing)) 的必要能力。流量可以分段,应用程序的不同部分可以独立保护。例如,您可以通过特定的网络策略非常轻松地保护每个服务:由服务器后的[Replication Controller](http://kubernetes.io/docs/user-guide/replication-controller/)标识的所有窗格都已由特定标签标识。因此,您可以使用同一标签将策略应用于这些pod。

长期以来,深度防御被建议作为[最佳实践](http://blog.kubernetes.io/2016/08/security-best-practices-kubernetes-deployment.html)。在AWS和OpenStack上,通过将安全组应用于VM,可以轻松实现应用程序的不同部分或层之间的这种隔离。

然而,在网络策略之前,这种对容器的隔离是不可能的。VXLAN覆盖可以提供简单的网络隔离,但是应用程序开发人员需要对流量访问pod进行更细粒度的控制。从这个简单的例子可以看出,Kubernetes网络策略可以根据源和源头,协议和端口来管理流量。

apiVersion: extensions/v1beta1
 kind: NetworkPolicy
 metadata:
 name: pol1
 spec:
 podSelector:
 matchLabels:
 role: backend
 ingress:
 - from:
 - podSelector
阅读全文

将Hypernetes整合至Kubernetes带来安全性与多租户机制

  categories:资料  tags:,   author:

尽管很多开发者与安全专家乐于强调Linux容器所拥有的明确边界,但大多数用户仍然希望进一步提升其隔离性水平,特别是在多租户运行环境当中。遗憾的是,目前这部分用户仍不得不将容器运行在虚拟机当中,有些甚至采取了容器与虚拟机一对一的包装方式。

这种作法直接影响到了云原生应用的诸多固有优势:包装在容器外面的虚拟机拖慢了服务的启动速度,带来更多的内存消耗,集群的资源利用率也无法得到有的效保证。

在今天的文章中,我们将介绍HyperContainer这种基于虚拟化技术的容器实现,了解它如何契合于Kubernetes的设计理念并帮助用户直接为使用者提供一套虚拟化技术加持的容器——而不是将它们打包进虚拟机当中。

HyperContainer

HyperContainer是一款基于虚拟化技术的容器方案,它允许大家利用现有标准虚拟化管理程序(包括KVM与Xen等)来启动Docker镜像。作为开源项目,HyperContainer由一套名为runV的OCI标准容器运行时和一个名为hyperd的守护程序共同构成。HyperContainer的设计思路非常明确:它要将虚拟化与容器两项技术的优势结合起来。

其实,我们可以将所有容器都看作由两大部分组成(Kubernetes正是这么设计的)。第一部分称为容器运行时,这里HyperContainer利用虚拟化技术(而非namespaces与cgroups)实现隔离与资源限制。另一部分称为应用数据,HyperContainer使用的是Docker镜像。因此在HyperContainer当中,虚拟化技术能够构建出完全隔离的沙箱环境和独立的用户kernel(这也意味着’top’指令及/proc文件系统在Hyper容器中都是正常工作的)。但从开发者的角度来看,其使用感受及可移植性则与标准容器保持一致。

HyperContainer原生支持Pod

HyperContainer的有趣之处在于,它不仅能够为多租户环境(例如公有云)带来理想的安全保障,同时也能够很好地契合Kubernetes的设计理念。

Kubernetes当中最为重要的概念就是Pod,而Pod的设计思想则源自Google公司著名的Borg系统对真实世界工作负载进行抽象得出的结论(见Borg论文8.1节),即在大多数情况下用户都希望能够将多个紧密协作的容器打包称为一个原子的调度单元来进行管理。当使用Linux容器时,Kubernetes Pod负责将多个容器打包并封装成为一个逻辑组。而在HyperContainer当中,虚拟机则被用来充当这组容器的天然边界,从而使得Pod能够则作为HyperContainer的顶级对象:

20161013162310

HyperContainer将多个轻量化应用容器打包成一个Pod,并在Pod级别来暴露容器操作的接口。在Pod当中,一个名为HyperKernel的极小Linux内核会被启动。而这个HyperKernel责由HyperStart这个轻量的Init服务来负责构建,HyperStart会作为PID 1的进程存在并创建Pod本体、设置Mount namespace、根据载入的镜像启动各应用。

这套模式能够与Kubernetes十分顺畅地对接。一旦将HyperContainer与Kubernetes相结合,就构成了我们在标题中提到的“Hypernetes”项目。

Hypernetes

Kubernetes的一个最大优势在于它是目前唯一支持多容器运行时的编排管理框架,这意味着用户不会被锁定在单一的容器技术提供商上。在这里我们很高兴地宣布,我们已经与Kubernetes团队达成合作关系,共同将HyperContainter整合至Kubernetes主干当中。这些合作工作包括了:

  1. 容器运行时优化与重构
  2. 新的客户端-服务器模式运行时接口
  3. 集成containerd并支持runV

尽管HyperContainer并非基于Linux容器技术堆栈所构建,但OCI标准和Kubernetes的多运行时架构使得这一整合过程非常顺利。

在另一方面,为了在多租户环境下运行HyperContainer,我们还创建了一款新的Kubernetes网络插件,并对现有的存储插件做了修改。由于Hypernetes直接使用虚拟机来作为Pod,它能够直接利用现有的成熟IaaS层技术来提供多租户网络及持久化卷存储。目前Hypernetes实现方案采用了标准的OpenStack组件。

接下来,我们将进一步探讨具体实现细节。

身份验证与授权

在Hypernetes当中,我们选择了Keystone来管理不同租户并在管理操作流程中执行身份验证任务。由于Keystone源自OpenStack生态系统,因此它能够同Hypernetes中使用的网络与存储插件进行无缝协作。

多租户网络模型

对于多租户容器集群,每位租户都拥有与其他租户完全隔离的自有网络环境。在Hypernetes中,每位租户亦拥有自己的Network。相较于利用OpenStack配置网络的复杂作法,Hypernetes只需要创建一个Network对象即可,具体如下:

apiVersion: v1
kind: Network
metadata:
name: net1
spec:
tenantID
阅读全文

Kubernetes在企业级架构中的实践分享

  categories:资料  tags:,   author:

本文是9月24日时速云技术沙龙大连站的演讲干货分享,内容源自时速云联合创始人兼技术总监杨乐的现场演讲录音整理。
以下为主要内容:

演讲提纲

20161009173141

1、Docker与容器技术

20161009173201

Docker跟VM的区别:VM每次起一个实例,实际上包括三层,整个操作系统、中间层内部以及其他应用,全部都包括从OS kernel到应用态的全部,容器技术把kernel层共享给所有的实例。

容器实例仅仅是应用态各不相同,而底层的操作系统内核是共享的,这样就带来一个好处: 所有运行的应用,都是进程粒度,轻量级,采用Namespace、Cgroup等隔离技术,同时 Docker所定义的标准镜像模式,让我们可以对容器和镜像进行非常快速的迁移。

Docker容器可以 build once、run anywhere,一次构建,可以随意运行。

2、Kubernetes架构及特性

20161009173207

Kubernetes是容器集群编排系统。例如10台机器都装了Docker,我们可以用Kubernetes把这些机器都编排起来,统一成一个集群来处理。

这种生产系统已经是生产级别的了,kubernetes最早的技术理念是源于谷歌的borg系统,而这种borg系统已经在谷歌内部稳定运行很多年了。

Kubernetes是2014年6月开源的,采用Golang的语言开发,每一个组件互相之间使用的是Master API的方式,Kubernetes的架构模式是用Master-slave模式,并且支持多种的联机网络,支持多种的分布式的存储架构。

Master的核心组件是API server,对外提供REST API服务接口。kubernetes所有的信息都存储在ETCD. Scheduler是kubernetes的调度器,用于调度集群的主机资源。Controller用于管理节点注册以及容器的副本个数等控制功能。

在Node上的核心组件是kubelet,它是任务的执行者,它会跟apiserver进行交互,获取资源调度信息。 kubelet会根据资源和任务的信息和调度状态与Docker去交互,调用Docker的API, 创建,删除与管理容器,而kube-Proxy可以根据从API里获取的信息以及整体的Pod架构状态组成虚拟NAT网络。

20161009173215

Pod 是Kubernetes可调度的最小单元,一个Pod里面可以有多个容器,容器与容器之间可以用Local host的方式去沟通,共享网络共享存储,也就是实现在pod内的资源共享。

Replication Controller  是Pod的一个控制,可以控制Pod副本和状态,就可以做手动的弹性伸缩.也可以利用hpa去通过CPU,或者是内存, 设定阈值去弹性伸缩。label是对Pod或其他的资源像Node, Service打标签,通过标签使不同层次的组件发生联系。可以用一个选择器把想要的资源选择出来,然后对他们进行操作。

Service  定义了服务虚拟IP与容器实例间的影射关系,同时定义了服务暴露给用户的方式。

Daemon Set  可以给每一个节点去分发应用容器,并以守护进程的方式运行,比如希望在每个节点上有一个组件,这个组件可以监控我的节点的健康状态,可以用Daemon set的方式来部署运行。

Config 阅读全文

Flannel是如何工作的 

  categories:资料  tags:,   author:

概述

最近我们的TaaS平台遇到很多的网络问题,事实证明“contiv + ovs + vlan”的方案并不适合TaaS这种大规模高并发的场景,填不完的坑,当然DevOps场景下是没什么问题的。时间紧迫,只能使用“Flannel + host-gw”这个简单、稳定的网络方案搭建一个小规模的集群来作为紧急备选方案。趁这个机会,也学习一下前两年因性能差,广为诟病而一直不敢碰的Flannel如今是怎么个样子。经过春节半个月的稳定测试、压力测试证明确实很稳定。当然,calico(bgp)才是我们后续的主要网络方案。

Flannel支持多种Backend协议,但是不支持运行时修改Backend。官方推荐使用以下Backend:

  • VXLAN,性能损耗大概在20~30%;
  • host-gw, 性能损耗大概10%,要求Host之间二层直连,因此只适用于小集群;
  • UDP, 建议只用于debug,因为性能烂到家了,如果网卡支持 enable udp offload,直接由网卡进行拆包解包,性能还是很棒的。
  • AliVPC。

实验性的Backend,不建议上生产:

  • Alloc
  • AWS VPC
  • GCE
  • IPIP
  • IPSec

Flannel的配置

Flannel在官方配置可以在https://github.com/coreos/flannel/blob/master/Documentation/configuration.md找到,但是注意文档中的配置不是最新的,是不完整的。

通过命令行配置

目前最新版的Flannel v0.10.0的命令行配置及说明如下:

Usage: /opt/bin/flanneld [OPTION]...
  -etcd-cafile string
    	SSL Certificate Authority file used 
阅读全文


快乐成长 每天进步一点点      京ICP备18032580号-1