基于SaaS的人工智能培训将改变游戏规则

不同于虚拟化技术要完整虚拟化一台计算机，容器技术更像是操作系统层面的虚拟化，它只需要虚拟出一个操作系统环境。

LXC技术就是这种方案的一个典型代表，全称是LinuX Container，通过Linux内核的Cgroups技术和namespace技术的支撑，隔离操作系统文件、网络等资源，在原生操作系统上隔离出一个单独的空间，将应用程序置于其中运行，这个空间的形态上类似于一个容器将应用程序包含在其中，故取名容器技术。

举个不是太恰当的比喻，一套原来是三居室的房子，被二房东拿来改造成三个一居室的套间，每个一居室套间里面都配备了卫生间和厨房，对于住在里面的人来说就是一套完整的住房。

如今各个大厂火爆的Docker技术底层原理与LXC并不本质区别，甚至在早期Docker就是直接基于LXC的高层次封装。Docker在LXC的基础上更进一步，将执行执行环境中的各个组件和依赖打包封装成独立的对象，更便于移植和部署。

容器技术的好处是轻量，所有隔离空间的程序代码指令不需要翻译转换，就可以直接在CPU上执行，大家底层都是同一个操作系统，通过软件层面上的逻辑隔离形成一个个单独的空间。

容器技术的缺点是安全性不如虚拟化技术高，毕竟软件层面的隔离比起硬件层面的隔离要弱得多。隔离环境系统和外面的主机共用的是同一个操作系统内核，一旦利用内核漏洞发起攻击，程序突破容器限制，实现逃逸，危及宿主计算机，安全也就不复存在。

超轻虚拟化 firecracker

虚拟完整的计算机隔离性好但太过笨重，简单的容器技术又因为太过轻量纯粹靠软件隔离不够安全，有没有一个折中的方案同时兼具两者的优点，实现既轻量又安全呢?

近年来，一种超轻虚拟化的思想开始流行开来，亚马逊推出的firecracker就是一个典型的代表。


 

.1 日志采集

• 一种方式将各个容器的日志都写入宿主机的磁盘，容器挂载宿主机本地Volume,采用Agent(Filebeat或Fluentd )采集这个部署在宿主机上所有容器转存的日志，发送到远端ES集群进行加工处理;
• 另一种是对于业务组(或者说Pod)采集容器内部日志，系统/业务日志可以存储在独立的Volume中，可以采用Sidecar模式独立部署日志采集容器，来对进行日志采集，对于DaemonSet和Sidecar这两种日志采集模式，大家可以根据实际需要选择部署;
• 通过部署在每个Node上的Agent进行日志采集，Agent会把数据汇集到Logstash Server集群，再由Logstash加工清洗完成后发送到Kafka集群，再将数据存储到Elasticsearch，后期可通过Grafana或者Kibana做展现，这也是比较主流的一个做法。

6.2 日志场景

主要需要采集的各种日志分为以下场景：

1.主机系统内核日志采集：

• 一方面是主机系统内核日志，主机内核日志可以协助开发/运维进行一些常见的问题分析诊断，如：Linux Kernel Panic涉及的(Attempted to kill the idle task，Attempted to kill init，killing interrupt handler)其它致命异常，这些情况要求导致其发生的程序或任务关闭，通常异常可能是任何意想不到的情况;
• 另一方面是各种Driver 驱动异常，比如：Driver内核对象出现异常或者说使用GPU的一些场景，各种硬件的驱动异常可能是比较常见的错误;
• 再就是文件系统异常，一些特定场景(如：虚机化，特定文件格式)，实际上是会经常出现问题的。在这些出现问题后，开发者是没有太好的办法来去进行监控和诊断的。这一部分，其实是可以主机内核日志里面来查看到一些异常。

2.组件日志采集：

K8S集群中各种组件是集群非常重要的部份，既有内部组件也有外部的如：API Server, Controller-man-ger，Kubelet , ECTD等， 它们会产生大量日志可用于各种错误分析和性能优化，也能帮助用户很好分析K8S集群各个组件资源使用情况分析，异常情况分析;还有各种第三方插件的日志(尤其是一些厂商贡献的网络插件或算法)，也是优化分析的重点;

3.业务日志采集：

业务日志分析也是优化的很重要的环节，业务系统自身的特性(如：web类，微服务类，API 接口类，基础组件类)都需要日志来分析，结合后面的资源预测和业务部署章节能否更好把握业务特性，创建合理的发布配置和Pod配置，根据日志分析业务访问量，活动周期，业务峰值，调用关系等优化整个过程。

（编辑：新余站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!