当今容器技术被广泛关注，已经有越来越多的企业开始或者已经采用容器技术来构建自己的云基础设施，在用容器设计新的应用微服务架构或如何改造现有的应用时，应该考虑哪些因素和相关特性，是企业在实施容器平台时必须要考虑的。


6、容器应用的监控方案如何设计？


在虚拟机运维的时代，Nagios和Zabbix等都是十分经典的性能监控软件。但在容器时代，这些曾经耳熟能详的软件，大多不能提供方便的容器化服务的监控体验，社区对开发这类插件和数据收集客户端也并不积极。相反的许多新生的开源监控项目则将对容器的支持放到了关键特性的位置，可以说容器的应用界定了一个全新的监控软件时代，一代新人换旧人。


在这些新生的监控工具中，有三种比较流行且成熟的具体方案，分别是cAdvisor、cAdvisor + InfluxDB + Grafana和Prometheus。其中基于InfluxDB的方案是一个多种开源组件的组合方案，而基于Prometheus的方案作为一种整体解决方案，它本身对容器信息的收集能力以及图表展示能力相比其他专用开源组件较弱，通常在实际实施的时候依然会将它组合为cAdvisor + Prometheus或cAdvisor + Prometheus + Grafana的方式来使用，但它多维度的数据模型，可方便的进行数据过滤和聚合。


说到容器应用的监控设计，在这里要注意监控是分层的，具体可以分为系统层面、应用层面和服务层面，每个层面都有自己的监控重点。


对于系统层面，主要是针对资源使用情况、网络连通性、节点健康情况的监控，传统的监控系统在这方面已经非常完备，我们直接可以利用传统的监控系统对容器平台的宿主机进行系统层面的监控，对接监控大屏幕等。宿主机上单个容器本身的性能和资源使用情况，则对于外部资源监控意义不大，也没有多大必要传送到外部的传统监控。


对于应用层面，容器平台本身通常都带有类似K8S的replication control这样的机制保持某个服务运行实例数量的能力，所以通常情况下容器平台都能保证应用和应用下每个微服务的运行正常。关于应用层面的健康监控，还是需要来对接传统的监控系统，进行适当的告警输出，比如当遇到应用逻辑错误而导致启动反复失败、或资源不足导致启动总是不成功等问题时，容器平台本身的replication control机制就不能解决问题了。这种情况就需要我们把应用的故障信息传递到外部监控，并根据问题的严重情况进行不同等级的告警通知等，由相关的应用人员介入来解决问题，比如升级补丁或回退等。


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


7、容器云的多租户和权限如何设计?


多租户，顾名思义，就是很多人来租用容器云平台的资源来实现自己的应用托管运维需求。这里面主要涉及多租户、资源管理与分配、安全权限管理，下面说下这三个问题。


（1）租户的问题

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


（2）资源管理与分配

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


（3）安全权限管理

多租户的安全权限设计，这涉及到容器云平台整体的权限控制架构，最好是实现一个权限中心，由权限中心来实现对容器云各组件及各功能的动态控制，以适应灵活的不同的场景需求。具体来说就是：1、 组织结构的实现可采用层次结构，无论多少层多少级，只标注其父结点ID，树型结构遍历可以获得所有的结点，这也是我们下面权限访问控制实现的基础。2、角色定义，就需要基于用户及用户组织结构，权限和容器云提供给租户的功能列表来实现，可以采用Oracle 数据库的用户角色权限定义方式来定义。比如容器云平台初始化时可以预定义角色，比如租户管理员角色、应用管理员角色等。根据定义的角色权限展示不同用户视图。


把权限访问控制提取出来实现一个统一的权限中心组件，是因为整个容器云平台、各个组件都面临着权限访问控制需求。从云计算的理念来说，松耦合、插件式的组件或模块设计更灵活和适用快速变化的需求；对一个客户来说，一个组件可能需要也可能不需要，每个组件都可以以插拔的方式来控制，根据客户需求来部署相应的组件，实现相应的权限访问控制，将会更灵活和便利。


8、容器与OpenStack和Kubernetes集成的能力


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


最后一个问题就是高可用和跨区部署。容器云需要考虑平台自身的高可用，实现多可用区多数据中心部署。容器上的应用高可用需要结合应用架构来实现。目前微服务架构是最适合云基础设施的应用架构之一。微服务应用通过服务注册发现，全局配置管理，熔断，服务追踪等容错设计，保证应用的高可用。弹性扩容，增加微服务运行的实例数量，配合负载均衡策略的使用，减少因压力过大而导致运行实例宕机的情况。


总结：


容器技术在企业的落地，不是一蹴而就的，是一个渐进和价值普及的过程。技术的更迭方式可以是潜移默化的和平演变，亦或是轰轰烈烈的武装革命，容器技术应该归属于前者。我们可以看到，容器化技术已经成为计算模型演化的一个开端，可以预见在更高效和轻量化的平台实践之后，容器还将为整个IT领域注入更多新鲜和活力，在未来生存和壮大下去，成为引领潮流的决定性力量！