加入收藏 | 设为首页 | 会员中心 | 我要投稿 辽源站长网 (https://www.0437zz.com/)- 云专线、云连接、智能数据、边缘计算、数据安全!
当前位置: 首页 > 站长百科 > 正文

孙杰:“容器技术在企业落地的探索和实践”

发布时间:2018-03-31 20:06:42 所属栏目:站长百科 来源:站长网
导读:近年来,云计算开源技术逐渐成为云计算发展的重要支撑和导向,改变了以往的信息技术进化模式,引领软件技术标准的发展和创新,深刻影响着整个信息技术产业的发展格局。为进一步探索我国云计算开源技术发展模式,加速云计算与各行业的深度融合,更好地发挥

在容器日志收集的时候,要注意以下两点:1、避免写日志冲突。最简单的方式就是让容器在运行时挂载外部共享存储卷当做应用的日志目录,这样应用的日志会被实时写入外部共享存储以备后续处理。这种方式需要我们做好控制,不同的容器不能挂载同一个外部卷,否则就会出现写日志冲突的问题,容器迁移的时候还需要重新挂卷。2、不可忽视日志标准化。当我们采用容器来运行微服务架构应用,一个业务调用往往需要经过多个微服务的调用链,整个业务处理过程的日志记录分散在不同的微服务日志中,这对通过日志进行问题诊断带来了很大的不便。通过标准化日志,例如带上唯一的 ID 信息等,可以实现把同一个业务在不同微服务中的处理过程给关联起来。通过标准化的应用日志,我们可以对交易率、成功率、响应时间等关键业务指标进行统一关联分析,作为问题预警、诊断分析、容量扩缩的科学依据。

第6个问题容器的监控怎么做。在虚拟机运维的时代,Nagios 和 Zabbix 等都是十分经典的性能监控软件。但在容器时代,这些曾经耳熟能详的软件,大多不能提供方便的容器化服务的监控体验,社区对开发这类插件和数据收集客户端也并不积极。相反的是许多新生的开源监控项目将对容器的支持放到了关键特性的位置,一代新人换旧人,可以说容器的应用界定了一个全新的监控软件时代。在这些新生的监控工具中,有三种比较流行且成熟的具体方案,分别是 cAdvisor、cAdvisor + InfluxDB + Grafana 和 Prometheus.其中基于 InfluxDB 的方案是一个多种开源组件的组合方案,而基于 Prometheus 的方案是作为一种整体解决方案。它本身对容器信息的收集能力以及图表展示能力相比其他专用开源组件较弱,通常在实际实施的时候依然会将它组合为 cAdvisor + Prometheus 或 cAdvisor + Prometheus+ Grafana 的方式来使用,但它多维度的数据模型,可方便的进行数据过滤和聚合。说到容器应用的监控设计,在这里要注意监控是分层的,具体可以分为系统层面、应用层面和服务层面,每个层面都有自己的监控重点。1、系统层面,主要是针对资源使用情况、网络连通性、节点健康情况的监控。传统的监控系统在这方面已经非常完备,我们直接可以利用传统的监控系统对容器平台的宿主机进行系统层面的监控,对接监控大屏幕等。宿主机上单个容器本身的性能和资源使用情况,对于外部资源监控意义不大,也没有多大必要传送到外部的传统监控。2、应用层面。容器平台本身通常都带有类似 K8S 的 replication control 这样的机制保持某个服务运行实例数量的能力,所以通常情况下容器平台都能保证应用和应用下每个微服务的运行正常。关于应用层面的健康监控,还是需要来对接传统的监控系统,进行适当的告警输出,比如当遇到应用逻辑错误而导致启动反复失败或资源不足,导致启动总是不成功等问题时,容器平台本身的 replication control 机制就不能解决问题了。这种情况就需要我们把应用的故障信息传递到外部监控,并根据问题的严重情况进行不同等级的告警通知等,由相关的应用人员介入来解决问题,比如升级补丁或回退等。

3、服务层面。服务层面则是监控应用提供的服务是否运行正常。例如某个提供 Web 服务的应用,在一些时候虽然应用和应用中微服务的运行实例数量正常,但它的 Web 服务已经失去响应,或者返回的是错误的状态,这种情况在多数容器平台中是无法监测到的。传统的方式是通过打探针 Agent 方式,但在容器环境下,这种方式不一定可行,这就需要我们丰富容器故障的监测手段或者自己编写服务访问+检测逻辑来判断,并把检测出现的问题上报到外部监控,在监控中设立相应的告警策略和告警等级。

第七就是容器的多租户和权限设计,在这里面其实容器这块处理的还不是特别好。比如给一个容器分配了200兆内存,你看到的实际上是物理机的64G内存,而不是真正你分给容器的这个内存。多租户,顾名思义,就是很多人来租用容器云平台的资源来实现自己的应用托管运维需求。这里面主要涉及多租户、资源管理与分配、安全权限管理这三个问题。

1、多租户的问题。从多租户的角度考虑,租户租用容器云平台的资源来托管、开发、部署运维自己的应用、服务。容器云平台需要提供、维护保障租户能正常使用这些资源,同时给租户托管的应用提供服务注册、服务发现、服务配置、日志、监控、预警告警、弹性伸缩、负载均衡、安全等能力。我们要明白的是租户只是租用这些能力,它并不运维这些能力。租户关注的是托管的应用和服务,它需要做的是利用平台提供的这些能力来无缝的运维他们的应用和服务。一句话来总结:租户只是使用/租用资源,容器云平台管理运维这些资源。租户侧重于对自己的应用或服务进行运维。资源由租户申请,容器云平台来分配管理资源。

2、资源管理与分配。这部分功能建议统一由运维团队或者系统团队负责,应用系统上云前一般会进行压测,有个容量估算的过程。通过容量估算和趋势分析,系统人员可以规划大致的资源池给相关应用,一般可以通过划分底层资源池实现。如果用 K8S,可以在计算节点上通过 lables 进行规划,另外还需要在编排文件上设置好最小资源和最大资源,让应用可以弹性扩容。

3、安全权限管理。多租户的安全权限设计涉及到容器云平台整体的权限控制架构,最好是实现一个权限中心,由权限中心来实现对容器云各组件及各功能的动态控制,以适应灵活的不同的场景需求。

第八就是容器与 OpenStack 和 Kubernetes 集成的能力。在开源云计算技术蓬勃发展的这几年中,OpenStack、Kubernetes、Container 无疑成为了改变云计算格局的三项关键技术。但是这三者之间在技术上仍然存在一个空白:容器运行时强安全隔离的同时保持精简尺寸以及轻量级,以及如何能够很容易与 OpenStack 和 Kubernetes 两大平台集成从而获取多租户以及统一网络和统一存储等诸多好处,这个空白阻碍了用户从中获取更大价值。为了解决这一问题,OpenStack 基金会在今年 12 月 5 日的 KubeCon 峰会上发布了一项新的开源项目,Kata Containers.Kata 可以使用户同时拥有虚拟机的安全和容器技术的迅速和易管理性。项目可以屏蔽硬件差异并且和 OCIspeciaification、Kubernetes 容器运行时标准兼容,在支持标准镜像格式的同时具有强隔离、轻量级以及快速启动能力。无疑 Kata 项目的发起为 OpenStack、Kubernetes 和 Container 更好的融合提供了有力的支撑,并为用户从中收益铺平了道路。期待容器真正辉煌时代的降临,但未来的道路,依然任重道远!

(编辑:辽源站长网)

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

推荐文章
    热点阅读