研发与运维一体化,见证终极协同奥义

JFrog捷蛙阅读(2181)评论(0)

 

家家有本难念的经,但是痛却总是惊人的相似

场景1:某个软件开发公司里,所有的设计、开发、测试、运维虽然被分配了不同职能与任务,但是他们都有一个统一的称呼——工程师。实际上,他们经常会互相干一些本不属于自身职能范围的工作。公司业务拓展,业务系统功能扩展、需求变更,“996”的日子成功进化成“007”,甚至都不够用。

场景2:某电商APP上线在即,由于系统频繁升级、升级耗时长、上线时间紧、测试不充分,经常出现发布版本错误。结果上线的日子本该轻松一些,却忙得不可开交,还需要调试线上系统的各类诡异的环境问题……

场景3:某软件开发公司的工程师们负责操作系统配置、中间件与业务系统的安装和升级。但是日常系统升级问题不断,即使按照文档部署也经常出问题,软件版本依赖问题、防火墙端口配置、一大堆配置文件修改……稍有遗漏,就会影响系统正常运行。

作为企业开发人员,不可避免会经历软件开发与迭代中的各种问题:

老板要求短时间内完成开发任务,可手边没有可借鉴的开发案例,一时间无从下手。

好不容易完成代码框架搭建,却又在功能迭代过程中面临代码管理混乱问题,新版本代码迟迟无法发布;

新版本终于发布交付,然而客户却反应发布的版本质量低下,安全缺失。

需求发布不清楚,工作流程的不合理,跨部门沟通协同….面对重重困难,迫切期望快速完成开发和发布任务的你,急需提高开发效率,软件质量同时提升项目管理效率一体化平台?

微软与JFrog(杰蛙中国)强强联合,通过GitHub,Azure DevOps与JFrog Artifactory,为软件研发人员提供企业级DevOps新体验!

什么是DevOps?

那么DevOps究竟指的是什么呢?DevOps是生产力/生产过程/产品迭代的结合,以便持续向终端用户输出有价值的服务。旨在降低开发过程中各个交付阶段之间的对接成本,帮助企业快速/高质量/安全地实现产品的迭代及技术的革新。

DevOps可以划分成很多部分,包括沟通协作/任务管理、持续集成/持续部署、代码管理、基础设施即代码、持续监控等。随着时机的成熟,市场的教育普及与工具链的成熟度越来越高,很多企业也实实在在看到了DevOps的价值。有数据显示:采用或部分采用DevOps的公司,发布频率提高了46倍,Bug修复时间提升了440倍,可以提前20%将产品推向市场,出错率减少5倍,收入增加了20%。

强强联合,米其林级体验

Azure DevOps我们在多个场合下提到过,是微软提供的用于帮助开发者实现DevOps文化的工具集合,Azure DevOps 方案与全球开源社区GitHub 的结合将进一步优化未来开发体验。

JFrog Artifactory 作为全球领先的企业级、高可用二进制制品管理仓库,支持绝大部分开发语言,任意维度的元数据检索、跨语言正反向依赖分析,并同时拥有深度递归、支持多活异地灾备。

看到这里,作为企业产品研发中流砥柱的您,可能已经跃跃欲试想要快速了解:这三者的集合究竟能为企业级DevOps平台建设提供哪些特性和优势?现在我们为大家隆重推荐,6月4日微软联合JFrog带来的 《企业级DevOps转型之旅- DevOps实施策略、框架以及案例线上分享沙龙》。详解DevOps方案中的关键技术以及高效工具的应用方法。

届时,微软全球技术黑带专家马平与JFrog 中国首席架构师王青将分别为大家介绍GitHub及软件开发流程,以及如何使用 Artifactory在 Azure DevOps进行安全,高效的版本发布。

报名链接:https://www.bagevent.com/event/6572294

Artifactory中Maven仓库配置优化——提升Virtual仓库下载速度 

JFrog捷蛙阅读(2660)评论(0)

 

问题背景

随着研发团队不断扩大Artifactory中Maven仓库也在逐步增多,包括 local、remote、virtual 仓库,其中往往会涵盖RELEASE和SNAPSHOT包类型仓库,为了对使用客户透明简化用户配置,管理人员会通过创建一个virtual仓库,将所有用到的 local(RELEASE和SNAPSHOT)、remote(RELEASE和SNAPSHOT) 包含到一个virtual 仓库中。这样让客户统一使用 virtual 仓库,虽然最大程度上节约了用户在修改配置的成本,但是也会出现一个致命的问题,拉包速度降低,极端情况下甚至几Byte/秒的速度。

分析原因

上面说了所有仓库组合起来之后,会出现拉包速度降低的问题,那么为什么会出现拉包慢的情况呢?

首先,Maven在解析 SNAPSHOT依赖包时,会在 virtual 仓库中所有的 remote仓库中遍历下载本次依赖包的 maven-metadata.xml 文件,这样做的目的是为了保持与远端仓库的强一致性,因为SNAPSHOT更新迭代较快。

其次,Artifactory 对所有 maven-metadata.xml 进行聚合,并找到 latest 版本返回给客户。

那么,如果一个 virtual 仓库中包含 10 个 remote仓库,则本次通过 gavc 解析一个依赖包需要下载 maven-metadata.xml 10次并进行聚合,相对于一个 virtual 仓库下只有2、3个 remote类型的仓库来说,时间消耗增大了 4~5 倍。这也就是仓库包含的说下载一个包大量的时间都额外消耗在了更新和聚合maven-metadata.xml上。这也就是常见的拉包慢问题的主要原因。

当然拉包慢也不全是这个问题,也有可能是网络或者磁盘速写速度等问题造成的,这个就不在这里过多赘述了。

解决方案

1.    release 和 snapshot 仓库分离:

设置三个virtual repository

(1)第一个 maven-snapshot-virtual include 所有maven-snapshot-local

(2)第二个 maven-release-virtual include 所有maven-release-local

(3)第三个 maven-remote-virtual include 所有remote repository

其中remote virtual 仓库只包含release 类型的远程仓库,如需snapshot,加到第一个virtual仓库中通过Artifactory set me up生成的setting.xml,选择 maven-snapshot-virtual和maven-release-virtual

在生成后的setting.xml,中添加maven-remote-virtual 相关配置,并且disable remote-virtual

2.减少 virtual 中 remote 仓库数量

前面说了拉包慢的原因,是因为下载一个包大量的时间都额外消耗在了更新和聚合maven-metadata.xml上,那么我们降低remote仓库的数量后,可以直接减少下载 maven-metadata.xml次数,降低在下载和聚合时所消耗的时间。

3.  控制SNAPSHOT包的数量

在仓库中配置存储的 SNAPSHOT版本数量(默认存储数量不限),控制在指定数量内。比如配置5个那么在仓库中每个SNAPSHOT版本的包最多只有5个,这样在聚合maven-metadata.xml文件时,聚合文件的运算量也将有所下降,提升聚合所消耗的时间。

4.  定时清理SNAPSHOT包

可以定时清理SNAPSHOT包,减少包的数量,原因与第三点相同,就是减少包的数量,降低聚合的时间,提升拉包效率。

清理方法可以使用AQL进行清理,清理示例如下:

(1)maven-test-local 仓库的 test/version 下有5个 snapshot 包:

(2)编写AQL清理脚本(保留 3 个最新版本【snapshot-v3.jar、snapshot-v4.jar、snapshot-v5.jar】,清除其余 maven-test-local 仓库 test/version 路径下的 snapshot 包):

(3)使用 JFrog CLI 执行清理命令(–quiet:跳过删除确认消息,调试脚本阶段建议去掉此参数):

jfrog rt del –quiet –spec=delete.json

5. 指定依赖解析路径:

如本项目只使用特定路径(com/apache/*)的依赖包,添加多个路径点击“⊕”,仓库参考配置如下:

如本项目使用除了特定路径(com/apache/*)的其他依赖包,添加多个路径点击“⊕”,仓库参考配置如下:

研发与运维一体化,见证终极协同奥义

JFrog捷蛙阅读(2217)评论(0)

家家有本难念的经,但是痛却总是惊人的相似

场景1:某个软件开发公司里,所有的设计、开发、测试、运维虽然被分配了不同职能与任务,但是他们都有一个统一的称呼——工程师。实际上,他们经常会互相干一些本不属于自身职能范围的工作。公司业务拓展,业务系统功能扩展、需求变更,“996”的日子成功进化成“007”,甚至都不够用。

场景2:某电商APP上线在即,由于系统频繁升级、升级耗时长、上线时间紧、测试不充分,经常出现发布版本错误。结果上线的日子本该轻松一些,却忙得不可开交,还需要调试线上系统的各类诡异的环境问题……

场景3:某软件开发公司的工程师们负责操作系统配置、中间件与业务系统的安装和升级。但是日常系统升级问题不断,即使按照文档部署也经常出问题,软件版本依赖问题、防火墙端口配置、一大堆配置文件修改……稍有遗漏,就会影响系统正常运行。

作为企业开发人员,不可避免会经历软件开发与迭代中的各种问题:

老板要求短时间内完成开发任务,可手边没有可借鉴的开发案例,一时间无从下手。

好不容易完成代码框架搭建,却又在功能迭代过程中面临代码管理混乱问题,新版本代码迟迟无法发布;

新版本终于发布交付,然而客户却反应发布的版本质量低下,安全缺失。

需求发布不清楚,工作流程的不合理,跨部门沟通协同….面对重重困难,迫切期望快速完成开发和发布任务的你,急需提高开发效率,软件质量同时提升项目管理效率一体化平台?

微软与JFrog(杰蛙中国)强强联合,通过GitHub,Azure DevOps与JFrog Artifactory,为软件研发人员提供企业级DevOps新体验!

什么是DevOps?

那么DevOps究竟指的是什么呢?DevOps是生产力/生产过程/产品迭代的结合,以便持续向终端用户输出有价值的服务。旨在降低开发过程中各个交付阶段之间的对接成本,帮助企业快速/高质量/安全地实现产品的迭代及技术的革新。

DevOps可以划分成很多部分,包括沟通协作/任务管理、持续集成/持续部署、代码管理、基础设施即代码、持续监控等。随着时机的成熟,市场的教育普及与工具链的成熟度越来越高,很多企业也实实在在看到了DevOps的价值。有数据显示:采用或部分采用DevOps的公司,发布频率提高了46倍,Bug修复时间提升了440倍,可以提前20%将产品推向市场,出错率减少5倍,收入增加了20%。

强强联合,米其林级体验

Azure DevOps我们在多个场合下提到过,是微软提供的用于帮助开发者实现DevOps文化的工具集合,Azure DevOps 方案与全球开源社区GitHub 的结合将进一步优化未来开发体验。

JFrog Artifactory 作为全球领先的企业级、高可用二进制制品管理仓库,支持绝大部分开发语言,任意维度的元数据检索、跨语言正反向依赖分析,并同时拥有深度递归、支持多活异地灾备。

看到这里,作为企业产品研发中流砥柱的您,可能已经跃跃欲试想要快速了解:这三者的集合究竟能为企业级DevOps平台建设提供哪些特性和优势?现在我们为大家隆重推荐,6月4日微软联合JFrog带来的 《企业级DevOps转型之旅- DevOps实施策略、框架以及案例线上分享沙龙》。详解DevOps方案中的关键技术以及高效工具的应用方法。

届时,微软全球技术黑带专家马平与JFrog 中国首席架构师王青将分别为大家介绍GitHub及软件开发流程,以及如何使用 Artifactory在 Azure DevOps进行安全,高效的版本发布。

报名链接:https://www.bagevent.com/event/6572294

【kafaka】在Kubernetes上使用helm部署kafka

Daniel_Ji阅读(12509)评论(0)

1、kafka整体架构

Kafka是由Apache软件基金会开发的一个开源流处理平台,由ScalaJava编写。Kafka是一种高吞吐量的分布式发布订阅消息系统,它可以处理消费者在网站中的所有动作流数据。 这些数据通常是由于吞吐量的要求而通过处理日志和日志聚合来解决。 对于像Hadoop一样的日志数据和离线分析系统,但又要求实时处理的限制,这是一个可行的解决方案。Kafka的目的是通过Hadoop的并行加载机制来统一线上和离线的消息处理,也是为了通过集群来提供实时的消息。

点击此处添加图片说明文字
  • Broker:是Kafka集群中包含的一个或多个服务器,这种服务器被称为broker。
  • Topic:每条发布到Kafka集群的消息都有一个类别,这个类别被称为Topic。(物理上不同Topic的消息分开存储,逻辑上一个Topic的消息虽然保存于一个或多个broker上但用户只需指定消息的Topic即可生产或消费数据而不必关心数据存于何处)
  • Partition:Partition是物理上的概念,每个Topic包含一个或多个Partition.
  • Producer负责发布消息到Kafka broker
  • Consumer:消息消费者,向Kafka broker读取消息的客户端。
  • Consumer Group:每个Consumer属于一个特定的Consumer Group(可为每个Consumer指定group name,若不指定group name则属于默认的group)。

2、部署kafka和zookeeper

1)添加incubator的helm仓库

通过执行下面的命令,添加incubator的helm仓库。


$ helm repo add incubator https://kubernetes-charts-incubator.storage.googleapis.com


2)获取chart

为了修改运行环境的参与,将incubator/kafka下载到本地。


$ helm fetch incubator/kafka –version 0.21.2


将此kafka-0.21.2.tgz解压缩到本地。

3)修改chart中的value.xml文件

通过notepad++等工具,对values.yaml文件进行编辑。以通过NodePort模式对外暴露kafka服务,允许Kubernetes集群外的应用使用kafka服务。

3)修改zookeeper chart中的value.xml文件

通过notepad++等工具,对values.yaml文件进行编辑。以通过NodePort模式对外暴露zookeeper服务,允许Kubernetes集群外的应用使用zookeeper服务。

5)部署kafka到Kubernetes中


$ helm install kafka ./kafka-0.21.2/kafka –set external.enabled=true –set external.type=NodePort –namespace=kube-public


3、验证

3.1 安装kafka客户端

下载kafka_2.11-2.0.0.tgz:


$ wget https://archive.apache.org/dist/kafka/2.0.0/kafka_2.11-2.0.0.tgz


解压缩kafka_2.11-2.0.0.tgz:


$ tar zxvf kafka_2.11-2.0.0.tgz


进入 kafka_2.11-2.0.0目录:


$ cd kafka_2.11-2.0.0/


3.2 验证

3.2.1 客户端验证

通过kubectl get svc命令,获取kafka以NodePort方式对外暴露的端口。


$ kubectl get svc -n kube-public


1)列示kafka中已有的topic


$ ./kafka-topics.sh –zookeeper 10.0.33.173:30648 –list


2)创建新的topic


./kafka-topics.sh –zookeeper 10.0.33.173:30648 –topic topnew002 –create –partitions 3 –replication-factor 1


3)生产消息


./kafka-console-producer.sh –broker-list 10.0.33.173:31091 –topic topnew002


4)消费信息


./kafka-console-consumer.sh –bootstrap-server 10.0.33.173:31091 –topic topnew002 –from-beginning


3.2.2 go验证

在$GOPATH/src目录下创建conn_kafka.go文件,此文件用于向kafka发送信息。

package main

import (
 "github.com/Shopify/sarama"
 "time"
 "log"
 "fmt"
 "os"
)

//定义kafka的地址
var Address = []string{"10.0.33.203:31090","10.0.33.203:31092","10.0.33.203:31093"}

func main() {
 syncProducer(Address)
}

//同步消息模式
func syncProducer(address []string) {
 config := sarama.NewConfig()
 config.Producer.Return.Successes = true
 config.Producer.Timeout = 5 * time.Second
//构建消息生产者
 p, err := sarama.NewSyncProducer(address, config)
 if err != nil {
 log.Printf("sarama.NewSyncProducer err, message=%s \n", err)
 return
 }
 defer p.Close()
//定义topic
 topic := "test2020"
 srcValue := "sync: 这是测试的信息. index=%d"
//通过for循环,发送信息
 for i:=0; i<10; i++ {
 value := fmt.Sprintf(srcValue, i)
 msg := &sarama.ProducerMessage{ 
  Topic:topic, Value:sarama.ByteEncoder(value),
 }
 part, offset, err := p.SendMessage(msg)
 if err != nil {
 log.Printf("send message(%s) err=%s \n", value, err)
 }else {
 fmt.Fprintf(os.Stdout, value + ";发送成功!,partition=%d, offset=%d \n", part, offset)
 }
 time.Sleep(2*time.Second)
 }
}

通过执行下面的命令,运行conn_kafka.go向kafka发送信息。

$ go run conn_kafka.go

4、部署kafka manager

通过执行下面的命令安装kafka manager,安装的命名空间为kube-public。zookeeper的地址为kafka-zookeeper:2181,kafka-zookeeper是在Kubernetes中的服务名称。


$ helm install kafka-manager stable/kafka-manager –set zkHosts=kafka-zookeeper:2181 –namespace=kube-public


5、 基于Prometheus和Grafana进行监控

5.1 部署kafka_exporter

通过helm3部署kafka的指标暴露应用。

helm repo add gkarthiks https://gkarthiks.github.io/helm-charts

helm install kafka-exporter gkarthiks/prometheus-kafka-exporter –set kafkaServer=kafka:9092  –namespace=kube-public

5.2 Prometheus配置

在Prometheus的配置文件(/etc/prometheus/prometheus.yml)的最后面增加下面的内容。


– job_name: ‘redis-ha-exporter’

   static_configs:

   – targets: [‘http://kafka-exporter-prometheus-kafka-exporter.kube-public:9308’]

5.3 Grafana监控

在Grafana中导入kafka-exporter-overview_rev5.json(下载地址:https://grafana.com/grafana/dashboards/7589),通过此DashBoard就能监控kafka运行的相关指标。


作者简介:季向远,本文版权归原作者所有。微博:ik8s​​​​​​​​

【容器云分析】腾讯容器服务(TKE)

Daniel_Ji阅读(8384)评论(0)

0、整体感觉

  • 云原生支持:腾讯云容器服务完全兼容原生 Kubernetes API;
  • 应用支持:目前只支持Linux集群,aspnet的应用可能无法在TKE运行;
  • 易用性:易用性有提升空间,例如服务部署后,外部访问的连接不明显;
  • 存储支持:默认支持的存储插件相对较少;
  • 网络:前期网络设置稍微有点复杂;
  • 容器技术:除了了支持docker以外,还支持containerd,这意味着可以支持docker外的其他容器技术;
  • 支持服务:帮助文档较完善。

1、TKE介绍

腾讯云容器服务(Tencent Kubernetes Engine,TKE)是高度可扩展的高性能容器管理服务,您可以在托管的云服务器实例集群上轻松运行应用程序。使用该服务,您将无需安装、运维、扩展您的集群管理基础设施,只需进行简单的 API 调用,便可启动和停止 Docker 应用程序,查询集群的完整状态,以及使用各种云服务。您可以根据资源需求和可用性要求在集群中安排容器的置放,满足业务或应用程序的特定要求。

腾讯云容器服务基于原生 Kubernetes 提供以容器为核心的解决方案,解决用户开发、测试及运维过程的环境问题、帮助用户降低成本,提高效率。腾讯云容器服务完全兼容原生 Kubernetes API,并扩展了腾讯云的云硬盘、负载均衡等 Kubernetes 插件,同时以腾讯云私有网络为基础,实现了高可靠、高性能的网络方案。

2、总体架构

TKE产品的整体架构如下图所示:

点击此处添加图片说明文字
  • 腾讯云容器服务基于原生 Kubernetes 进行适配和增加, 支持原生 Kubernetes 能力。
  • 提供了腾讯云的 Kubernetes 插件,帮助用户快速在腾讯云上构建 Kubernetes 集群。
  • 腾讯云容器服务在 Kubernetes 上层,提供了集群管理、应用管理、CI/CD 等进阶能力。

3、TKE特性

点击此处添加图片说明文字

4、总体架构

点击此处添加图片说明文字

点击此处添加图片说明文字

点击此处添加图片说明文字

点击此处添加图片说明文字

参考材料:

1)https://cloud.tencent.com/product/tke


作者简介:季向远,本文版权归原作者所有。微博:ik8s​​​​​​​​​​​​

后疫情时期传统企业的云原生之路将走向何方?第二期(2019-2020)云原生实践调研报告发布!

灵雀云阅读(2948)评论(0)

2019年的云原生大放异彩,业内对云原生也有许多定义和预判,比如“云原生技术商业化元年”,“未来将云原生一切”,“上云就上云原生”。因为云原生技术具备容器化、动态调度和快速交付的特点,能够最大化释放云计算生产力的应用设计、开发、交付和管理方式,快速将价值传递给客户。

很多企业希望借助云原生技术快速、高质量地交付数字化服务和软件,并进行可靠的大规模运维,从而实现数字化转型。通过本调研报告您可以了解到传统企业当前IT应用开发现状,云原生技术在企业的应用情况,以及突如其来的疫情给2020年的IT规划所带来的影响,希望能对您企业的IT架构转型和云原生技术采用提供借鉴。

2020云原生调研报告亮点提炼:

1、云原生已成为新常态,容器化需求从行业头部企业下沉到中小规模企业,从领先企业尝鲜变为主流企业必备;

2、52.3%的企业将云原生技术用于生产环境,其中核心业务生产21.7%、边缘业务30.6%,容器落地比例大;

3、中间件、存储、网络、数据库、安全等基础服务纷纷与云原生对齐;

4、中国率先控制住疫情为国内企业在数字化转型方面争取到窗口期,数字化转型在疫情和后疫情时期越发重要。

01 调研数据与调研方法

2020年2-3月,云原生技术实践联盟(CNBPA)联合灵雀云、云原生技术社区正式发起了“2019-2020年(第二期)企业云原生技术实践”调研。2020年在特殊的疫情之下开年,全球经济都受到疫情的负面影响,本次调研就是在这样一个特殊背景时期展开的。这是CNBPA联合灵雀云、云原生技术社区发起的第二次年度云原生调研,也是可观测范围内唯一面向传统企业客户的云原生调研。

调研期间,总计收到了613份有效调研问卷,参与者分别来自金融、制造、能源、医药、电信、政企等不同领域、不同规模的公司,大部分在企业IT/信息化部门担任经理以上职位。本次调研与2018-19年度的首期云原生调研在多个维度上保持了统一和延续性,希望更有针对性地了解国内企业云原生目标、挑战,以及向云原生转移的战略。

今年参与调研的企业中,100-500台服务器规模的占26.5%,500-1000台服务器的21.1%,1000台以上服务器24.5%。这里有意思的是,伴随业务的发展,服务器规模相较去年却有了一定的缩减,这一定程度上是容器化带来的效果。K8s拥有极高的扩展性、自动化和可伸缩性,通过容器化改造,可以最大化地利用服务器资源,按需使用,有效节约服务器成本。同时这一结论也说明,容器化需求开始从行业头部企业下沉到中小规模企业,从领先企业尝鲜变为主流企业必备。

 

受访者中21.4%来自基础架构部门,15.3%来自运维部门,32.7%来自研发部门,10.2%为CIO/CTO等企业的高级IT管理者。

02 2018 VS 2019:
IT应用更新显著加快,支撑压力有增无减

在降本增效的目标下,加快数字化业务发展成为传统企业的必然选择。由于业务场景、用户习惯迅速变化,许多行业数字化业务出现急速增长。数字化业务意味着大刀阔斧的企业敏捷文化,只有借助更加快速、灵活的开发和交付模式,才能满足市场快速变化的需求。

因此,本次参与调研的企业不小的比例拥有相当规模的研发团队,企业自己主导IT软件的研发。研发团队在100人以上的占据51%强,20人以下(23.5%)和20-100人(25.5%)的比例几乎平分秋色。

在IT系统更新方面,每月都要更新、升级的比例达25.5%,每周都要发布的占到了29.6%,3-6个月更新一次的比例下降到16.3%。业务开发迭代都以每月、每周计,需要7*24小时响应,这些给系统开发和运维带来极大挑战。

在IT系统支撑方面,我们给出的几个选项都得到了很高的数据:系统复杂性越来越高占67.3%,应用交付压力大,交付速度无法满足业务需求62.2%,IT研发运维管理复杂占64.3%,IT架构过于陈旧,需要重新规划选项占比31.6%。

这组数据与去年调研相比略有提高,这也说明来自业务层面的巨大压力,需要IT在成本节约、业务敏捷性、客户体验、业务创新等方面都要有所作为,企业应用和IT架构快速做出改变。只有“IT架构过于陈旧”这点出现了较为明显的下降,表明一些企业已开始行动,着手云原生架构升级改造。

03 52.3%的企业将云原生技术用于生产环境,容器落地比例大

21.7%的受访者中将云原生技术(包括容器、DevOps、微服务)已用于核心业务生产,30.6%用于边缘性业务,20.1%用于测试阶段,16.3%尚处于评估阶段,11.3%还没有采用这些前沿的技术。

通过使用容器、Kubernetes、DevOps、微服务等这些年轻且先进的技术,能够大大加快软件开发迭代速度,提升应用架构敏捷度,提高IT资源的弹性和可用性,帮助企业客户加速实现价值。

这一数据也与2019年Gartner的预测非常吻合。Gartner报告曾指出,到2020年,将有50%的传统老旧应用被以云原生化的方式改造,到2022年,将有75%的全球化企业将在生产中使用云原生的容器化应用。

在被调研企业中,有8.2%的企业使用了超过5000个容器,大部分参与调研企业使用容器的数量在500以下(61.2%),500-1000个容器的比例为21.4%,1000-5000个容器为9.2%。越来越多的主流企业落地了容器技术,来支撑越来越丰富,及复杂性不断增长的云原生应用构建。

对于云原生PaaS平台的搭建,26.5%的被调研企业希望自研。一些中大型企业的研发团队具有很强的技术实力,有些甚至是行业内的技术专家,在对新技术有了更多了解之后,希望主导自己企业的IT研发和技术中台建设,因此在积极尝试云原生平台的自建。

但也不尽然。更大比例的企业选择通过和第三方技术厂商合作(35.7%)联合开发来落地云原生技术,自研和第三方厂商合作兼而有之的占37.8%。对于更多中大型企业来说,经过仔细调研会发现云原生技术难度和自研成本很高,大部分企业需要和专业技术厂商合作,共同落地云原生技术,打造技术中台。专业的技术厂商能够提供完善的咨询服务、解决方案和方法论。同时云原生技术的部署也一定程度上伴随着对企业IT文化、流程的变革,也需要技术厂商和企业的配合。

对于大部分传统企业而言,云原生PaaS平台是未来企业业务的核心竞争力的底层支撑,而非核心竞争力本身所在。企业应该将更多的人员、精力和成本投入到与业务相关的研发上,而不是重复造底层基础设施的轮子,造成重复性浪费投资。对于软件开发商、行业解决方案商也是如此。

04 复杂环境推动微服务采用,微服务未来属于Service Mesh

受调研企业中,23.5%的企业是利用微服务架构对遗留应用进行改造。微服务能够将中大型应用化整为零、化繁复为简单。大部分企业都无力承受全面重建技术基础,对现有应用一步步改造,逐步提升速度和敏捷性,进而影响文化、流程层面,不失为微服务落地的稳健做法。

较大的比例(40.8%)是用微服务架构来开发新系统,尤其是数字化业务,新系统开发没有历史包袱,可以轻装上阵。

持谨慎态度,处在评估阶段的比例也不容小觑,占到31.6%。正如我们之前多次强调的,微服务架构本质是以运维的复杂度为代价去换取敏捷性,企业需要斟酌自身业务是否真的有敏捷性需求,去管理运维的复杂度。微服务治理也不仅是Spring Cloud或者Service Mesh,它需要一套完整的基础设施去支撑。

微服务架构的改造要小试牛刀小步快跑,而非对技术基础伤筋动骨,这是出于多种因素的考虑:第一,出于业务稳定性的要求;第二,出于技术探索尝试的同时,降低项目风险的要求;第三,推动企业内部文化、技术,甚至部门架构迭代的过程要求;最后是出于最终总体拥有成本的宏观考虑。

在微服务框架的选择上,实施微服务的企业58.2%选择了Spring Cloud,11.8%选择Service Mesh。

Service Mesh在技术社区中是当前最流行的微服务趋势,作为一项很新的技术,Service Mesh本身还在演进过程中,生产落地仍有挑战。企业的生产级应用都会选择成熟稳定,有大规模落地案例的技术。由于国内Java人员众多,Spring Cloud当下在国内企业仍然占据主流。

不过,从技术发展趋势看,Service Mesh相比Spring Cloud有无法替代的优势,它简化了微服务架构中服务间调用的复杂度。在预期的2年内,Service Mesh会逐渐在国内推广开来,并最终占据主流地位。

05 DevOps正走向成熟,接近85%的企业已经或计划投资上马DevOps

DevOps正在变得成熟,越来越受到青睐。近85%的企业已经或计划投资上马DevOps。其中已经实施的企业占比35.7%,6个月内计划部署的接近20%,6-12个月以内部署的达21.4%,12-24个月以内部署的占8.2%。

DevOps包含几层概念:组织文化的转变、最佳实践,以及将最佳实践用工具去落地。在DevOps的整个流程里涉及到很多类别的工具,对于客户来说,也不存在一个固定的、完全标准的工具组合。打造开放式的DevOps工具链集成与编排平台是一个趋势,通过在平台上集成DevOps工具省去重复的工作量,提高运营效率。

在DevOps工具选型时,众多工具组合中被调研企业认为比较重要的有:GitHub/Gitlab/(74.5%)、Jenkins(52%)、Jira (39.8%)、Confluence(35.7%)、SonarQube(29.6%)、码云(28.6%)、Nexus(28.6%)。在其他选项中,标注Coding的比例非常高。

06 中间件、存储、网络、数据库、安全等纷纷与云原生对齐

主流企业在落地云原生技术时,更加关注完整体系化的云原生解决方案,而非一些单独零散的产品服务。

随着云原生技术的普及,越来越多的应用负载都部署在Kubernetes之上,Kubernetes已成为云原生的基石,用户和云计算之间新的交互界面。数据库、存储、网络、中间件、安全等周边技术、组件都开始跟云原生技术对齐。被调研企业中,基于或准备基于容器、微服务等云原生技术来构建的技术栈中,中间件(如 Elastic,Confluent)占比69.4%,数据库(如NoSQL)占比65.3%,存储(如Ceph)占比50%,安全达33.7%。

其中,企业倾向于采用开源版的占比更高(41.9%),商业版为22.3%,两者都有的占到35.8%。中国企业在以惊人的速度拥抱云原生理念及开源技术。不过,对安全性、可靠性、服务质量有更高要求的企业,倾向于选择商业版。

07 不一样的2020,IT预算保守之下有坚持

在2020年度企业IT部门的工作重点上,受调研者在业务上云(56.1%)、优化现有IT(54.1%),私有云/混合云部署(53.1%)、大数据/AI等新技术采用等方面都获得了一半以上大体相当的得票。另外应用开发的票数也达到了33.7%。云原生、大数据、AI等新技术的潜力,以及未来企业IT全面上云的必然趋势都清晰可见。

除了在技术本身方面的投入,被调研企业也充分认识到了人员技能培训培养的重要性。技术之外,排名靠前的优先事项包括:数字化转型占74.5%,人员技能培训占比68.4%,团队建设56.1%。

 

疫情之下特殊的2020年,大家对IT预算的预估都比较保守,选择IT预算会下降的(36.6%)和增长保持在1%-5%的比例(33.7%)各占1/3强,增长5-10%的比例为19.5%,还有9.2%的企业IT预算不受疫情带来的经济形势的冲击,有10%以上的增长。

08 结论

数字化转型不仅是一个时髦的名词,更是要认真对待的一种变革。在降本增效的核心目标下,企业为了提高生产力,打造更好的客户体验,在不遗余力地深入数字化转型。随着 Kubernetes、 DevOps和微服务技术的全面成熟,云原生技术已经成为企业数字化转型的优先方向。

本次调研展示了当前企业所面临的一些现实,以及主流企业的行动实践。需要注意的是,每家企业在基础设施和应用架构方面都有自身的个性化差异、任务复杂性等挑战。有的企业只关注云原生中的某一项技术,解决某个切肤痛点。有的企业则希望同时考虑完整体系化的解决方案,追求云计算技术生产力的最大化。每家企业的云原生之路都应该是个性化、量身定制,而且循序渐进的。

疫情之下的2020年,中国在付出巨大代价和牺牲的情况下,为世界争取了一到三个月的窗口期。同时,由于对疫情正确而果断的处理,也使得中国相较世界大多数国家拥有了一到三个月(有可能是更长)的提早恢复期,国内企业在数字化转型方面拥有了双倍的时间优势。考虑到疫情对经济的影响可能延续到2021年乃至更久,数字化转型为企业所能带来的竞争力优势,在疫情和后疫情时期都越发显得重要。

不一样的2020,是挑战亦是机遇。在IT预算保守的总体形势下,如何抢占领先身位厚积而薄发,企业决策者们不可不察也!

云原生技术的成熟不仅体现在技术的快速发展,围绕在其周围的生态系统也已日渐完善。中国企业全面采用云原生技术的时机已经到来。赶快行动起来,找准切入点,开启您的云原生之路吧!

附:报告下载地址:http://www.alauda.cn/resource/index.html#hash-2

【微服务架构-istio】Istio整体架构

Daniel_Ji阅读(6631)评论(0)

在使用Kubernetes等云平台时,组织会从中获取到大量的益处。然而,采用这些Kubernetes等云平台可能会给 DevOps 团队带来一下压力。开发人员必须使用微服务以满足应用的可移植性,同时,运维团队也将管理大量和复杂的应用。

Istio出现的目的就是想降低微服务部署的复杂性,以减轻开发团队的压力。它是一个完全开源的服务网格,可以透明地分层到现有的分布式应用程序上。Istio 的多样化功能集能够成功高效地运行分布式的微服务架构,并提供保护、连接、控制和监控微服务的统一方法。

l 连接(Connect):智能控制服务之间调用的流量,能够实现灰度升级、AB 测试和红黑部署等功能

安全(Secure):自动为服务之间的调用提供认证、授权和加密。

控制(Control):应用用户定义的 policy,保证资源在消费者中公平分配。

l 监控(Observe):查看服务运行期间的各种数据,比如日志、监控和 跟踪,以了解服务的运行情况。

1 isito价值

Istio 提供一种简单的方式来为已部署的服务建立网络,该网络具有负载均衡、服务间认证、监控等功能,只需要对服务的代码进行一点或不需要做任何改动。想要让服务支持 Istio,只需要在您的环境中部署一个特殊的 sidecar 代理,使用 Istio 控制平面功能配置和管理代理,拦截微服务之间的所有网络通信:

  • 自动化负载均衡:自动化负载均衡HTTP、gRPC、WebSocket 和 TCP 的流量。
  • 细粒度流量控制:通过丰富的路由规则、重试、故障转移和故障注入,能够对流量行为进行细粒度的控制。
  • 可插入的策略层和配置 API:支持访问控制、速率限制和配额。
  • 指标度量跟踪:对出入集群的所流量(包括入口和出口)进行自动度量指标、日志记录和跟踪。
  • l 安全服务间通信:通过强大的基于身份的验证和授权,在集群中实现安全的服务间通信。

2、istio

Istio 服务网格逻辑上分为 数据平面 (data plane)和 控制平面(control plane) 。

数据平面 由一组以 sidecar 方式部署的智能代理(Envoy)所组成。这些代理可以调节和控制微服务及 Mixer 之间所有的网络通信。

控制平面 负责管理和配置代理来路由流量。此外,控制平面也配置 Mixer 以实施策略和收集遥测数据。

下图显示了构成每个面板的不同组件:

Istio Architecture

2.1 Envoy(代理服务)

Envoy是以 C++ 开发的高性能代理,用于代理服务网格中所有服务的入站和出站流量。Envoy 的许多内置功能被 istio 发扬光大,例如:

  • l 动态服务发现
  • l 负载均衡
  • l TLS 终止
  • l HTTP/2 & gRPC 代理
  • l 熔断器
  • l 健康检查、基于百分比流量拆分的灰度发布
  • l 故障注入
  • l 丰富的度量指标

在Istion中,Envoy 被部署为 sidecar ,和对应服务部署在同一个 Kubernetes pod 中。这允许 Istio 将大量关于流量行为的信号作为属性提取出来,而这些属性又可以在 Mixer 中用于执行策略决策,并发送给监控系统,以提供整个网格行为的信息。

2.2 Mixer(访问控制)

Mixer 是一个平台独立的组件,负责在服务网格上执行访问控制使用策略,并从 Envoy 代理和其他服务中收集遥测数据(telemetry data)。代理提取请求级属性,并发送它们到 Mixer中 进行评估。

Mixer 中包括一个灵活的插件模型,使其能够接入到各种主机环境和基础设施后端,从这些细节中抽象出 Envoy 代理和 Istio 管理的服务。

2.3 Pilot(服务发现)

Pilot 用于为 Envoy sidecar 提供服务发现智能路由(例如 A/B 测试、金丝雀部署等)、流量管理错误处理(超时、重试和熔断)功能。Pilot将控制流量行为的高级路由规则转换为特定于 Envoy 的配置,并在运行时将它们分发给 sidecar。

Pilot 将平台特定的服务发现机制进行抽象化,并将其合成为符合 Envoy 数据平面 API 的任何 sidecar 都可以使用的标准格式。这种松散耦合使得 Istio 能够在多种平台环境下运行(例如,Kubernetes、Consul、Nomad),并能够保持流量管理的相同操作界面。

2.4 Citadel(认证服务)

Citadel 通过内置身份和凭证管理可以提供强大的服务间和最终用户身份验证。可用于升级服务网格中未加密的流量,并为运维人员提供基于服务标识而不是网络控制的强制执行策略的能力。从 0.5 版本开始,Istio 支持基于角色的访问控制,以控制谁可以访问特定的服务。

2.5 Galley

Galley 是 Istio配置验证、获取、处理和分发组件。它负责将其它的Istio 组件与从底层平台(例如 Kubernetes)获取的用户配置细节隔离开来。

3 核心功能特性

Istio在服务网络中统一提供了许多流量管理、安全管理、监控管理、平台支持、以及集成和定制这些关键功能特性。

3.1 流量管理

通过Istio的简单规则配置和流量路由,可以控制服务之间流量。Istio简化了诸如断路器(circuit breaker),超时(timeout)和重试(retry)之类的服务级别属性的配置。并能够轻而易举地实现一些重要的任务,如A / B测试,canary部署,以及具有基于百分比的流量拆分的分阶段部署。

借助对流量的更好可见性和开箱即用的故障恢复功能,无论遇到什么情况,都可以在问题引起问题之前及时发现问题,使呼叫更加可靠,网络也更加强大。

3.2 安全管理

Istio的安全功能使开发人员可以将精力集中在应用程序级别上。Istio提供基础安全通信通道,以及大规模管理服务通信的身份验证,授权和加密。借助Istio,默认情况下可以保护服务通信的安全,从而能够在各种协议和运行时之间一致地实施策略,所有这些操作几乎不需要更改应用程序。

尽管Istio是独立于平台的,但将其与Kubernetes(或基础架构)网络策略配合使用,其好处更大,包括能够在网络和应用程序层保护Pod到Pod或服务到服务的通信的能力。

3.3 监控管理

Istio强大的跟踪,监视和日志记录功能使您可以深入了解服务网格部署。借助Istio的监视功能,可以真正了解服务性能如何影响上游和下游事物。

Istio的Mixer组件负责策略控制和遥测收集。它提供了后端抽象和中介,使Istio的其余部分与各个基础架构后端的实现细节隔离开来,并为操作员提供了对网格和基础架构后端之间所有交互的精细控制。所有这些功能可以更有效地设置,监视和实施服务上的SLO。当然,最重要的可以快速有效地检测和修复问题。

3.4 平台支持

Istio是独立于平台的应用,支持在多种环境中运行,包括Kubernetes和Mesos等的环境。Istio当前支持:

  • l 在Kubernetes上的部署服务;
  • l 在Consul中注册的服务;
  • l 在虚拟机上运行的服务。

3.5 集成和定制

Istio的策略执行组件允许进行扩展和定制,以与现有的ACL,日志记录,监视,配额,审核等解决方案镜像集成。


作者简介:季向远,本文版权归原作者所有。微博:ik8s​​​​

【prometheus性能监控】oracle数据库性能监控(oracledb_exporter)

Daniel_Ji阅读(15493)评论(1)

​​​​1、安装和配置oralcedb_exporter

1.1 使用docker安装oralcedb_exporter

这里以容器的方式提供oracledb_exporter,所使用的镜像为iamseth/oracledb_exporter,以守护进程方式运行此容器。对外暴露9161端口,通过DATA_SOURCE_NAME环境变量指定要监控的oracle数据库。


$ docker run -d –name oracle -p 1521:1521 wnameless/oracle-xe-11g:16.04

$ docker run -d –name oracledb_exporter –link=oracle -p 9161:9161 -e DATA_SOURCE_NAME=system/oracle@oracle/xe iamseth/oracledb_exporter


1.2 查看oracle的指标数据

  • oracledb_exporter_last_scrape_duration_seconds
  • oracledb_exporter_last_scrape_error
  • oracledb_exporter_scrapes_total
  • oracledb_up
  • oracledb_activity_execute_count
  • oracledb_activity_parse_count_total
  • oracledb_activity_user_commits
  • oracledb_activity_user_rollbacks
  • oracledb_sessions_activity
  • oracledb_wait_time_application:
  • oracledb_wait_time_commit
  • oracledb_wait_time_concurrency
  • oracledb_wait_time_configuration
  • oracledb_wait_time_network
  • oracledb_wait_time_other
  • oracledb_wait_time_scheduler
  • oracledb_wait_time_system_io
  • oracledb_wait_time_user_io
  • oracledb_tablespace_bytes
  • oracledb_tablespace_max_bytes
  • oracledb_tablespace_bytes_free:
  • oracledb_process_count:oralce进程数
  • oracledb_resource_current_utilization:
  • oracledb_resource_limit_value:

2、Prometheus监控

2.1 配置Prometheus

在Prometheus的配置文件(Prometheus.yaml)的最后面,添加体下面内容。

# oracle数据库性能监控
– job_name: ‘oracledb’
static_configs:
– targets: [‘10.0.39.203:9161’]

2.2 配置验证

在浏览器的地址栏访问http://{prometheus}/targets,将会看到新配置的oracle。

3 Grafana监控

3.1 配置mysql监控dashboard

下载mysql_exporter的dashboard(mysql-overview_rev5.json),在grafana中导入dashboard:mysql-overview_rev5.json。

​参考材料

​​​​​1)Oracle DB Exporter:https://github.com/iamseth/oracledb_exporter


作者简介:季向远,本文版权归原作者所有。微博:ik8s​​​​

KubeSphere 安装 Orion vGPU 使用 TensorFlow,基于 Kubernetes 运行深度学习训练

KubeSphere阅读(19586)评论(0)

概览

本文将使用开源的 KubeSphere 容器平台,在 Kubernetes 上部署 Orion vGPU 软件 进行深度学习加速,并基于 Orion vGPU 软件使用经典的 Jupyter Notebook 进行模型训练与推理。

若您还不了解 KubeSphere 容器平台,让我们通过这个短视频 Demo 快速了解 KubeSphere 丰富的企业级功能。

 

 

在开始安装 Orion vGPU 和演示深度学习训练之前,先简单了解一下,什么是 vGPU 以及什么是 Orion vGPU

什么是 vGPU

vGPU 又称 虚拟 GPU,早在几年前就由 NVIDIA 推出了这个概念以及相关的产品。vGPU 是通过对数据中心(物理机)的 GPU 进行虚拟化,用户可在多个虚拟机或容器中 共享该数据中心的物理 GPU 资源,有效地提高性能并降低成本。vGPU 使得 GPU 与用户之间的关系不再是一对一,而是 一对多

为什么需要 vGPU

随着 AI 技术的快速发展,越来越多的企业开始将 AI 技术应用到自身业务之中。目前,云端 AI 算力主要由三类 AI 加速器来提供:GPU,FPGA 和 AI ASIC 芯片。这些加速器的优点是性能非常高,缺点是 成本高昂,缺少异构加速管理和调度。大部分企业因无法构建高效的加速器资源池,而不得不独占式地使用这些昂贵的加速器资源,导致 资源利用率低,成本高

以 GPU 为例,通过创新的 vGPU 虚拟化技术,能够帮助用户无需任务修改就能透明地共享和使用数据中心内任何服务器之上的 AI 加速器,不但能够帮助用户提高资源利用率,而且可以 极大便利 AI 应用的部署,构建数据中心级的 AI 加速器资源池

什么是 Orion vGPU

Orion vGPU 软件由 VirtAI Tech 趋动科技 开发,是一个 为云或者数据中心内的 AI 应用、CUDA 应用提供 GPU 资源池化、GPU 虚拟化能力 的系统软件。通过高效的通讯机制连接应用与 GPU 资源池,使得 AI 应用、CUDA 应用可以不受 GPU 物理位置的限制,部署在云或者数据中心内任何一个 物理机、Container 或者 VM 内。

Orion vGPU 软件架构

由于我们将在 KubeSphere 容器平台上部署 Orion vGPU 软件至 Kubernetes,在部署前我们先简单了解一下 Orion vGPU 的软件架构。

Orion Client

Orion Client 为一个运行时环境,模拟了 NVidia CUDA 的运行库环境,为 CUDA 程序提供了 API 接口兼容的全新实现。通过和 Orion 其他功能组件的配合,为 CUDA 应用程序虚拟化了一定数量的虚拟 GPU(Orion vGPU)。由于 Orion Client 模拟了 NVidia CUDA 运行环境,因此 CUDA 应用程序可以透明无修改地直接运行在 Orion vGPU 之上。

Orion Controller

Orion Controller 是一个长期运行的服务程序,其负责整个 GPU 资源池的资源管理。其响应 Orion Client 的 vGPU 请求,并从 GPU 资源池中为 Orion Client 端的 CUDA 应用程序分配并返回 Orion vGPU 资源。该组件可以部署在数据中心任何网络可到达的系统当中,每个资源池部署一个 Orion Controller。资源池的大小取决于 IT 管理的需求,可以是整个数据中心的所有 GPU 作为一个资源池,也可以每个 GPU 服务器作为一个独立的资源池。可以认为它就像一个中介,帮忙沟通 Orion Client 和 Server。

Orion Server

该组件为一个长运行的系统服务,负责 GPU 资源化的后端服务。Orion Server 部署在每一个物理 GPU 服务器上,接管本机内的所有物理 GPU。Orion Server 通过和 Orion Controller 的交互把本机的 GPU 加入到由 Orion Controller 管理维护的 GPU 资源池当中。

当 Orion Client 端应用程序运行时,通过 Orion Controller 的资源调度,建立和 Orion Server 的连接。Orion Server 为其应用程序的所有 CUDA 调用提供一个隔离的运行环境以及真实 GPU 硬件算力。

场景演示

Orion vGPU 的使用包括以下三类场景:

  • 场景一:Docker 容器中使用本地节点 GPU 资源
  • 场景二:KVM 虚拟机中使用本地节点 GPU 资源
  • 场景三:在没有 GPU 的节点上使用远程节点上的 GPU 资源

本文仅对场景一进行演示说明,该场景非常适用于教学及推理场景,后续的文章会对场景三说明如何通过 RDMA 使用远程节点 GPU 资源。

准备 GPU 节点并安装 NVIDIA 驱动和插件

假设您已有 KubeSphere 集群环境,那么可参考 KubeSphere 官方文档扩容一个 GPU 主机作为新的 GPU 节点。本文使用了一台 Ubuntu 18.04 的 GPU 节点通过 KubeSphere 加入了 Kubernetes 集群,并在 GPU 节点安装 NVIDIA 驱动和 NVIDIA Docker 插件,在本文中暂不对该步骤进行详细说明。

安装 Orion vGPU 软件

通过安装 Orion vGPU 软件,容器得以使用 Orion vGPU 资源加速计算。安装完成后,我们将会在容器中运行与测试 TensorFlow 的部分深度学习训练。

如下我们可以使用 KubeSphere 在 Kubernetes 之上容器化部署 Orion vGPU 的三个组件以及它的 Kubernetes Device Plugin。

安装 Orion Controller

在上述已经对 Orion Controller 进行过介绍,它可以部署在集群的任意节点。一般说来,会通过选择器让 Controller 运行在指定的节点上,从而把 Controller 的 IP 地址确定下来。本文为了配置简单,仅安装在了 GPU 物理节点上:

(1)代码克隆到集群中任意主机节点本地。

$ git clone https://github.com/virtaitech/orion

(2)部署 Orion Controller,默认只部署一份 Orion Controller:

$ cd orion/orion-kubernetes-deploy
$ vi deploy-controller.yaml

添加节点选择器,如上图,保存。然后执行如下命令部署 Controller:

$ kubectl create -f deploy-controller.yaml

执行完成后在 KubeSphere 界面的 default 项目中可以看到 Controller 的 Pod:

安装 Orion Kubernetes Device Plugin

Orion Kubernetes device plugin 是符合 Kubernetes device plugin 接口规范的设备扩展插件。配合 Orion GPU 可以无缝地在一个 Kubernetes 集群里添加 Oiron vGPU 资源,从而在部署应用的时候,在容器中使用 Orion vGPU。

如下,修改 deploy-plugin.yaml 文件,添加节点选择器,使 Device Plugin 将以 DaemonSet 安装在物理 GPU 节点上。

$ kubectl create -f deploy-plugin.yaml

执行完成后,等待一段时间,在 KubeSphere 界面的 default 项目中可以看到 deploy-plugin 的 Pod。

安装 Orion Server

Orion Server 将在物理 GPU 节点以 DaemonSet 形式部署,以部署支持 CUDA 10.0 的 Orion Server 为例。

$ vi deploy-server-cuda10.0.yaml

添加节点选择器,使 Orion Server 安装在物理 GPU 节点上。

修改后保存即可执行安装:

kubectl create -f deploy-server-cuda10.0.yaml

执行完之后,等待一段时间,在 KubeSphere 界面的 default 项目中可以看到 orion-server 的 Pod。

安装 Orion Client 应用

Orion Client 将安装在物理 GPU 节点,并且使用一个 Jupyter Notebook 作为 Client 应用来使用 vGPU。在 deploy-client.yaml 中添加标签,并且参考如下修改 args:

  • resource limit: 可以设置应用能使用的 virtaitech.com:gpu 的数目;
  • ORION_GMEM:容器内应用申请的 vGPU 显存大小。

$ kubectl create -f deploy-client.yaml

执行完之后,等待一段时间,default 项目中可以看到 orion-client 的 Pod。

新建一个 deploy-service.yaml 文件用来为 orion-client 创建服务,内容如下:

kind: Service
apiVersion: v1
metadata:
  name: orion-client
  labels:
    app: jupyter
  annotations:
    kubesphere.io/serviceType: statelessservice
spec:
  ports:
    - name: tcp-8888
      protocol: TCP
      port: 8888
      targetPort: 8888
      nodePort: 30110
  selector:
    app: jupyter
  type: NodePort
  externalTrafficPolicy: Cluster

其中 labels 与 deploy-client.yaml 中的 Pod 一致,NodePort 为需要暴露的外网服务 然后执行如下命令创建服务:

kubectl create -f deploy-service.yaml

此时可通过外网访问 Jupyter Notebook。查看 orion-client 的日志拿到 token,即可登录 Jupyter Notebook。

训练一个简单的 CNN 模型

以下将在 Jupyter Notebook 训练一个简单的 CNN 模型实现 mnist 手写数字分类。

  1. 在 Jupyter Notebook 页面点击 new-python3

  1. 将 mnist.txt 文件中的内容拷贝到上面新建的文件中。鼠标放到代码上,点击运行,运行结果如下:

提示:mnist.txt 文件下载地址:https://kubesphere-docs.pek3b.qingstor.com/files/AI/mnist.txt

  1. 训练的过程中,我们可以在宿主机上通过 nvidia-smi 工作监视物理 GPU 的使用情况:

  1. 从图中可以看到,真正使用物理 GPU 的进程是 Orion Server 的服务进程  /usr/bin/oriond,而不是容器中正在执行 TensorFlow 任务的 Python 进程。这表明容器中的应用程序使用的是 Orion vGPU 资源,对物理 GPU 的访问完全由 Orion Server 所接管。

GPU 深度学习训练测试:人脸识别

  1. 在 Jupyter 页面上传 facenet.tar 文件:

提示:facenet 下载地址: https://kubesphere-docs.pek3b.qingstor.com/files/AI/facenet.tar

  1. 进入 orion-client 容器:
$ kubectl exec -it orion-client-td2jl -n default /bin/bash
  1. 安装 Python 依赖包:
$ pip3 install scikit-image==0.10
$ pip3 install numpy==1.16.0
  1. 解压文件 facenet.tar 文件:
$ tar xvf facenet.tar
  1. 在 Jupyer 页面进入 facenet/src,点击 facecomp.ipynb

  1. 打开 facecomp.ipynb 后,鼠标放到代码中,点击运行,在提示输入 model file path 时,输入预训练权重路径 20180408-102900,按下 Enter 键:

  1. 提示输入需要计算的照片时,输入 a1.jpg a2.jpg b1.jpg b2.jpg c1.jpg c2.jpg (这里随机选择了 VGGFace2 数据集中 3 个人共 6 张照片作为示例),按下 Enter 键。

将计算并显示 6 张人脸照片相互之间的距离,同一个人的照片,距离较近。如下图所示:

  1. 训练的过程中,我们可以在宿主机上通过 nvidia-smi 工作监视物理 GPU 的使用情况:

  1. 结论与上一个训练相同,真正使用物理 GPU 的进程是 Orion Server 的服务进程  /usr/bin/oriond,表明容器中的应用程序使用的是 Orion vGPU 资源。

总结

本文通过 Step-by-step 向大家介绍了 vCPU,以及如何使用 KubeSphere 容器平台 在 Kubernetes 之上安装部署 Orion vGPU,并使用官方 TensorFlow 的两个示例进行模型训练与推理,最终演示了 vGPU 的第一个应用场景 Docker 容器中使用本地节点 GPU 资源

充分证明了 vGPU 能够兼容已有的 AI 应用和 CUDA 应用,无需修改已有应用程序。并且,借助 Orion vGPU 对 GPU 资源池的管理和优化,提高了整个云和数据中心 GPU 的利用率和吞吐率。

后续我们将推出第二篇文章并结合示例说明 vGPU 的另一个典型应用场景 如何通过 RDMA 使用远程节点 GPU 资源

参考

关于 KubeSphere

KubeSphere (https://github.com/kubesphere/kubesphere)是在 Kubernetes 之上构建的以应用为中心的开源容器平台,提供全栈的 IT 自动化运维的能力,简化企业的 DevOps 工作流。

KubeSphere 已被 Aqara 智能家居、本来生活、新浪、云智汇、微众银行、VNG Corporation、Radore 等海内外数千家企业采用。KubeSphere 提供了运维友好的向导式操作界面,包括 Kubernetes 资源管理、DevOps (CI/CD)、应用生命周期管理、微服务治理 (Service Mesh)、多租户管理、监控日志、告警通知、存储与网络管理、GPU support 等功能,帮助企业快速构建一个强大和功能丰富的容器云平台

2020 有哪些不容错过的前端技术趋势?

alicloudnative阅读(3831)评论(0)

5.9头图.png

导读:2019 年的大前端热闹非凡,Serverless,Flutter,Vue3.0,桌面应用开发,小程序,WebAssembly 的火爆发展还是超乎我们预期,2020 的大前端又有哪些不容错过的技术趋势呢?

四位技术人不四、杜欢、海波和堂主对 2020 年前端发展趋势进行了展望,同时也阐述 2020 年前端从业者可能将要面临的挑战。

  • 不四  蚂蚁金服高级前端技术专家,语雀产品技术负责人
  • 杜欢 阿里云战略 & 合作部 高级前端技术专家、阿里巴巴经济体前端 Serverless 研发升级项目负责人
  • 海波  网易云音乐前端负责人
  • 堂主  政采云前端负责人

Q1:在 2019 年大前端领域,您印象最深刻或者最重要的一件事情是什么?

不四:随着大前端领域开始进入深水区,越来越多的资源开始往两端倾斜,Low Code 领域解决大量营销活动和中后台的业务场景, Pro Code 领域则通过基建赋能来提升开发者的研发效能,支持更复杂的研发场景。

杜欢:2019 年,云厂商和整个前端开发者社区都在积极推动 Serverless 概念的落地,云 + 端的研发模式雏形初显,大前端的未来充满更多可能。

海波:运营工具体系作为前端容易切入的业务赋能场景,近两年在各个大小厂如雨后春笋般涌现,诸如页面搭建工具以及图片、音视频等素材的合成制作工具等等,其中也有不乏结合视觉、音视频算法以及推荐算法的智能化场景案例。相信 2020 年运营工具在限定场景下的智能化拓展应该会成为一个大家发力的重要赛道,因为传统的拖拖拽拽的生产方式在提效上的天花板是存在的。

堂主:过去一年最深的感受,在于随着业务及终端的多元化,前端也正式进入了深水区,在解决业务问题的同时,更加关注研发效能。在工程技术收益向平台业务收益转变的过程中,前端正在向传统职能范畴的上下游进行拓展和打通,从研发工程化到智能 AI+ 的自动化探索,研发工程链路上的 Low Code 对业务赋能降本的惊人价值;Serverless 理念的认知与实践,前端研发能力的愈加下沉和带来的应用单兵能力,能看到行业在由 Web 前端开发向 Web 应用开发快速前进的趋势。

Q2:2019 年,最超乎您预期的一个前端技术趋势是什么?

不四:我自己的工作重心其实在 Pro Code 和全栈研发领域,但是 19 年过去之后回头来看,Low Code 领域的发展迅速超出我的预期。从最早的通过模块化搭建解决营销活动领域的问题,发展到现在可以通过 Low Code 来解决内部复杂的中后台业务需求,随着智能化和前端的结合、Low Code 和 Pro Code 的结合,尽管还是在探索阶段,但是从趋势来看这可能是给前端提效的一个大方向。

杜欢:前端 Serverless 研发模式在阿里巴巴双十一落地还是让我感觉非常震撼的,虽然还只是迈出的第一步,但这一步的象征意义非常巨大且显性。通过阿里经济体前端 Serverless 研发模式升级实践可以看出未来应用开发的几个特征:

  • 业务开发者不再关心很细节的机器资源申请、运维;
  • 数据源将得到进一步的融合,业务层可以自由编排使用;
  • 前端可以完成整个应用的交付;
  • 流量高峰前后,不用主动规划资源;通过这些研发态的变化,业务可以更低成本更高效的试错。

海波:应该是小程序吧。除了AT(阿里和腾讯)小程序继续收割流量,日活再创新高,2B (百度和字节) 小程序也开始展露头角,甚至 360 还提出了桌面端小程序概念,在边缘场景也想分到一杯羹。「小程序跨端」这个技术议题开始变成刚需,比如 taro 等技术方案变得越来越有市场,技术方案从跨 Web 和 RN 等,演变到需要跨小程序 ABCDEFG… 。不得不说,在为这些小程序疲于奔命的时候,作为普通开发者,我们对于 Web 标准本身的关注正在减弱。不过从纯技术视角看,小程序对于跨端体验优化还是有参考价值的,比如离线包、独立历史栈的多页保活 Webview 以及一些关键视图的混合渲染,切实解决了纯 Web 的体验痛点。另外,W3C 也首次发布了小程序标准化白皮书的内容,偏门变正道也存在可能性。

堂主:2019 年最超出我预期的实际上有两个,其一是 Low Code 能力的发展对人效的提升,由单端到现在的多端;由早期的偏营销展示的轻业务场景到现在的中后台复杂业务场景,乃至业务模型、链路和事件的可支持;由 UI 模块的人肉编码研发到智能化的 UI2Code 生成经过实践。其二是 Serverless 理念的广泛布道和部分厂的垂直化尝试,就像前面问题回答的,前端的能力在下沉,正回归到 Web 工程师的路上,这不论是对业务还是前端自身都是利好。

Q3:2020 年的大前端领域,您认为最值得关注的技术趋势是什么?

不四:随着前端框架和其他基础设施的进一步完善,前端工程师可能更多的需要将关注点放在如何利用这些基础设施来更好的解决业务问题上来。在 Low Code 领域如何让 Low Code 的产物与 Pro Code 结合以解决更复杂的业务,在 Pro Code 领域如何使用云服务、Serverless 等技术为基础,进入更广阔的全栈研发世界,都是值得关注和投入的。

杜欢:从前端行业价值角度上看,我目前还是会认为可以优先关注云端 Serverless 研发模式升级这件事情。随着云底层能力的不断丰富,云厂商平台逐渐提供了越来越强的免架构及免运维能力,使得整个社会开始逐渐具备将经历聚焦到业务思考本身,这会影响到雇主对整个研发体系建设的选择。当雇主有机会让更多研发人员只专注业务逻辑开发时,普遍具备专业的设备端交互逻辑开发且能通过 NodeJS 等语言实现后端业务逻辑开发的大前端行业,将会得到更大的机会,这会是对整个行业带来深远影响的方向,值得大家关注。

海波:Serverless 吧。我们内部虽然也在尝试积极实践 Node BFF ,但如果抛开拓展职能边界这个对内价值,而从最终提效来说,效果可能并不明显, Node 更多的会用在一些非核心链路(比如运营工具、监控平台等)或中后台业务以及相对较成熟的 SSR 等。并且在面对大流量的 C 端场景,也会一些稳定性隐患,大厂可能可以有充足的投入去保障,中小厂就相对没那么幸运了,只能选择在一些小场景反复磨炼。而 Serverless 作为一种科学的开发理念和新的协作分工模式,有可能将一个模块或功能(甚至应用)的 ”端+服务“的开发复杂度缩小到单位人力可承载,贴合前端广且薄的职能特点,从而解决人员基础的问题。

堂主:我认为是 Serverless,基于 Serverless 的研发体系变革和能力进化的普适性和影响深度会超出一些同学的预期。Serverless 对底层资源和运维工作的封装,让前端能更专注于交互逻辑、业务逻辑和数据而非环境本身,在 UI 即函数 + Faas 的事件驱动,Node 能力结合容器及微服务的架构,前端比以往更容易以全栈的姿态贴近业务、服务业务。未来结合 AI 智能生成的加持,Web IDE 对本地环境的抹平和业务开发与平台能力的打通,前端的变革会更加深远。

Q4:您认为对于前端从业者来说,2020 年可能面临的最大挑战是什么?

不四:正所谓能力越大,责任越大。随着前端能使用的“武器”变的更强大,前端要解决的问题也更复杂。然而不论前端如何发展,最终还是要回归到“解决问题”这个本质上。能否利用这些新的“武器”来找到新的业务场景,或者让之前的场景明显提效,可能是接下来大前端开发者需要思考的。

杜欢:上面我更多的在提云端 Serverless 研发模式升级这件事情,实际上除此之外,前端还有很多其他不错的方向,比如智能化、低代码化等等,其中有一些会是帮助前端进一步解放的工具,有一些是帮助前端进一步扩大价值的方法,但是这两者,都对前端提了一个相同的要求:要做一个精通业务的开发者,如果还是像原来那样简单的“切页面”,那可能未来第一批被淘汰的就是这些人。而要成为一个精通业务的开发者,又将会是一个全新的话题,除了技术之外,我们要链接更多,思考更多!

海波:2020 年的挑战我觉得和 2019 年并不会有实质差别,务虚一点说:「如何在业务中探索前端的技术价值体现」,这点我觉得在所有业务前端团队可能都是长久的挑战。

堂主:2020 年前端研发体系的升级不会这么快,诸如 Serverless 也还处于理念到最佳实践的探索阶段。最大的挑战,我认为是在新思想和各方实践的推动下,优势大厂平台和一般小厂之间行业技术从业者的认知代差会进一步扩大,后续几年,初中级从业者的行业红利会逐渐消失。这里还是要强调下,技术的价值在于解决业务问题,不同阶段的业务所需的技术配套是不同的。拥抱业务,不要狭隘的从前端角度看业务,从业务角度去看研发看前端,聚焦各自的业务问题,由场景出发找方案能带来更好的成长。

阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践,做最懂云原生开发者的公众号。”

【docker容器技术】Bridge网络驱动程序

Daniel_Ji阅读(4708)评论(0)

1、默认docker网桥网络

在任何运行Docker引擎的Linux主机上,默认情况下都存在一个名称为bridge的本地Docker网络

。该网络是使用bridge网络驱动程序创建的,该驱动程序实例化出一个名为docker0的Linux网桥。这听起来可能令人困惑。

  • bridge :是docker网络的名称;
  • bridge :是一个docker网络驱动,或模板,基于它能够创建网络;
  • docker0 :是Linux桥接的名称,它是用于实现网络的内核构建块;
  • eth0:为bridge在容器中创建的网卡;
  • veth:网桥和容器虚拟网卡的接口。

在独立的Linux Docker主机上,bridge如果未指定其他网络,则是容器连接的默认网络(Windows上是nat网络类型)。在以下示例中,创建了一个没有网络参数的容器。Docker Engine bridge默认将其连接到网络。在容器内部,eth0是由bridge驱动程序创建容器内部网卡,并由Docker原生IPAM驱动程序指定其地址。

默认的Docker Bridge网络默认的Docker Bridge网络

在这里以创建一个名称为bridge-demo-01的容器为例,说明bridge网络。


$ docker run –rm -it –name bridge-demo-01 busybox /bin/sh


1)查看宿主机中网桥的信息:主机网络的名称空间中存在Linux网桥。显示一个名称为

docker0的网桥。docker0具有一个名称为veth3e520f8,该接口提供从网桥到bridge-demo-01容器eth0网卡的连接。主机对于容器的请求流量通过veth3e520f8接口进入容器。

2)查看宿主机的ip路由:主机路由表显示,外部应用通过宿主机的eno1网卡(ip地址为10.0.33.201)

将流量引导至docker0网桥,并将通过网桥将请求流量引导至容器。

3)查看容器的ip信息:在容器中,通过ip address查看容器网卡的信息。其中,etho的ip地址为172.17.0.7,mac地址为02:42:ac:11:00:07。

4)查看容器的ip路由:容器路由表将流量引导至容器的eth0网卡,进而引导至docker0网桥。来自宿主机的请求,将通过docker0和veth接口进入到容器。默认情况下,bridge从范围172. [17-31] .0.0 / 16或192.168.[0-256] .0 / 20中分配一个子网,该子网不与任何现有主机接口重叠。

2、用户定义的docker网桥网络

除了默认网络之外,用户也可以创建自己的网络。对于用户定义的bridge网络,将在主机上设置一个新的Linux网桥。与默认bridge网络不同,用户定义的网络支持手动IP地址和子网分配。如果未分配,则Docker默认IPAM驱动程序会为其分配私有IP空间中的下一个可用的子网。

用户定义的网桥用户定义的网桥

在用户定义的bridge网络下,创建了两个容器。

  • 创建一个名称为my_bridge子网;
  • 创建一个名称为bridge-demo-002的容器,未显示指定ip地址;
  • 创建一个名称为bridge-demo-003的容器,指定ip地址为10.0.0.254;

$ docker network create -d bridge –subnet 10.0.0.0/24 my_bridge

$ docker run –rm -itd –name bridge-demo-002 –net my_bridge busybox sh

$ docker run –rm -itd –name bridge-demo-003 –net my_bridge –ip 10.0.0.254 busybox sh


在宿主机上通过brctl show命令可以查看所创建的网桥和接口。


作者简介:季向远,本文版权归原作者所有。微博:ik8s​​​​

【docker容器技术】Linux容器架构

Daniel_Ji阅读(5252)评论(0)

1、整体架构

在 Linux 环境中,docker的整体架构

容器管理工具(例如 Docker)是基于一组更精细的容器工具构建的: runccontainerd

Linux 上的 Docker 体系结构Linux 上的 Docker 体系结构

1.1 操作系统(底层技术)

1.1.1 Control Groups:对资源分配和限制

cgroup将限制应用程序使用一组特定的资源。cgroup允许Docker引擎将可用的硬件资源共享给容器,并有选择地实施限制和约束。例如,可以限制特定容器可用的内存。Cgroups 是Linux 内核提供的一种机制,这种机制可以根据需求把一系列系统任务及其子任务整合(或分割)到按资源划分等级的不同组内,从而为系统资源管理提供一个统一的框架。

Cgroups可以限制、记录任务组使用的物理资源(cpu、memory 、io等),主要作用如下:

  • 资源限制:对任务使用的资源总额进行限制
  • 优先级分配:控制任务运行的优先级
  • 资源统计:统计系统资源的使用量
  • 任务控制:对任务执行挂起、恢复等操作

1.1.2 Namespace:对系统资源的封装隔离

Docker使用namespace技术为容器提供隔离,在运行容器时,Docker将会为其创建一个namespace集合。这些namespace为容器提供隔离层,容器的每个方面都在单独的namespace中运行,并且其访问仅限于该namespace。

Namespace是对全局系统资源的一种封装隔离,使得处于不同namespace的进程拥有独立的全局系统资源,改变一个namespace中的系统资源只会影响当前namespace里的进程,对其他namespace

中的进程没有影响。而Docker其实就通过 Linux 的Namespaces对不同的容器实现了资源隔离。

在Linux内核中提供了多种namesapce隔离系统调用,如下所示:

  • pid: 进程隔离(PID: Process ID).
  • net: 隔离网络接 (NET: Networking).
  • ipc: 隔离IPC资源访问 (IPC: InterProcess Communication).
  • mnt: 隔离文件系统挂接点 (MNT: Mount).
  • uts: 隔离内核和版本标识 (UTS: Unix Timesharing System).

1.1.3 Layer Capabilities:

联合文件系统或UnionFS是通过创建层进行操作的文件系统,使其非常轻便且快速。Docker引擎使用UnionFS为容器提供构建模块。Docker引擎可以使用多个UnionFS变体,包括AUFS,btrfs,vfs、overlay、overlay2、zfs、brtfs和DeviceMapper等。

2 控制器

1.2.1 runc:

是一种 Linux 命令行工具,用于根据OCI 容器运行时规范创建和运行容器。runc是容器标准化的产物,为了避免docker垄断容器标准,成立了opencontainers组织,定义了容器,镜像和仓库的标准,runc就是该标准的一个实现,通过runc可以完成容器的启停等操作。

1.2.2 containerd shim

一个容器的启动就是一个进程的启动,而containerd-shim就是容器所在的进程。容器运行的真正载体,一个容器对应一个containerd-shim进程。容器运行时通过调用oci的一个标准实现runc来完成对应容器的启停过程,但是容器的管理都托管于容器的shim进程。

shim主要是作为容器进程的父进程,与containerd解耦,可以实现containerd挂掉的时候容器依然运行;shim的设计允许runc执行后即可退出,runc非常驻内存操作。另外shim用于收集容器状态以及向containerd报告容器状态。shim设计的第二个目的,主要是避免runc运行占用过多的内存,go语言默认的是静态编译,如果一个机器上运行N个容器,就需要占用N*runc消耗内存,shim可以减缓,但是不能完全消除。至于runc为何不使用动态编译的原因,猜测是为了尽可能减少部署的麻烦。

1.2.3 containerd:

containerd是一个守护程序,它管理容器生命周期,从下载容器到容器映像并将其解压缩到容器执行和监督。然而containerd并不直接做此事,而是交给runC来运行container。而Docker Engine则依然需要负责管理image,至于image的运行(container)则交给containerd组件来完成。docker engine的守护进程,接收docker client的请求,完成镜像、容器、容器网络、容器存储、swarm集群的管理。其中容器的管理通过rpc调用containerd进行管理。

containerd是一个工业级别的容器运行时,强调简单,健壮和可移植。它宿主机上容器的完成声明周期,主要提供如下功能:镜像的传输和存储,容器的运行和管理,底层的存储和网络等。containerd被设计成可以集成进入大型系统中,而不是直接被开发或者终端用户使用的。从containerd可以单独作为k8s的容器运行时即可看出。在docker内,实现了dockerd和cotainerd的解耦,可以容器不停,完成dockerd升级操作。需要docker的live-restore配置支持。

4 容器引擎

Docker Engine Components FlowDocker Engine Components Flow

在架构中,Docker Engine是客户端-服务器模式的应用程序:

  • 守护程序:服务器是在宿主机中长期运行的程序,作为容器的守护程序( dockerd 命令)。
  • API接口:REST API,它指定程序可以用来与守护程序进行通信并指示其操作的接口。
  • 客户端:命令行界面(CLI)客户端(docker 命令)。

CLI使用Docker REST API通过脚本或直接CLI命令控制或与Docker守护程序交互。许多其他Docker应用程序都使用基础API和CLI。守护程序负责创建和管理Docker 对象,例如镜像,容器,网络和数据卷。

4.1 libcontainer

Docker引擎将名称空间,控制组和UnionFS组合到一个称为容器格式的封装器中。默认的容器格式为libcontainer。Libcontainer 是Docker中用于容器管理的包,它基于Go语言实现,通过管理namespaces、cgroups、capabilities以及文件系统来进行容器控制。可以使用Libcontainer创建容器,并对容器进行生命周期管理。

4.2 libnetwork

Libnetwork是Docker团队将Docker的网络功能从Docker核心代码中分离出去,形成一个单独的库。 Libnetwork通过插件的形式为Docker提供网络功能。 使得用户可以根据自己的需求实现自己的Driver来提供不同的网络功能。

官方目前计划实现以下Driver:

  1.  Bridge : 这个Driver就是Docker现有网络Bridge模式的实现。
  2.  Null : Driver的空实现,类似于Docker 容器的None模式。
  3.  Overlay : 隧道模式实现多主机通信的方案。

“Libnetwork所要实现的网络模型(网络拓扑结构)基本是这样的: 用户可以创建一个或多个网络(一个网络就是一个网桥或者一个VLAN ),一个容器可以加入一个或多个网络。 同一个网络中容器可以通信,不同网络中的容器隔离。”我觉得这才是将网络从docker分离出去的真正含义,即在创建容器之前,我们可以先创建网络(即创建容器与创建网络是分开的),然后决定让容器加入哪个网络。

4.3 graph

graph driver主要用于管理和维护镜像,包括把镜像从仓库下载下来,到运行时把镜像挂载起来可以被容器访问等,都是graph driver做的。

4.4 plugins

Docker插件是增强Docker引擎功能的进程外扩展。这就表示,插件不会运行在Docker daemon中。你可以随时随地(如果需要可以在另一台主机上)启动你的插件。只需要通过Plugin Discovery通知Docker daemon这儿有一个新的插件可用即可。

4.5 REST Interface

REST API指定程序可以用来与守护程序进行通信并指示其操作的接口。

  • Registry API:提供了与来存储Docker镜像的Docker Registry集成的功能。
  • Docker Hub API:提供了与Docker HUB集成的功能
  • Docker Remote API:提供与Docker守护进程进行集成的功能

作者简介:季向远,本文版权归原作者所有。微博:ik8s​​​​