企业应用向容器迁移和微服务改造实践

「K8s 技术落地实践」成都站，QingCloud 研发团队分享了我们在企业应用向容器迁移和微服务改造实践、KubeSphere 的多租户监控实践、Network Policy 最佳实践等内容上的经验和解决方案，小编在这里为大家做了总结梳理，让我们共同回顾一下本次分享的技术内容。PPT 资料已经打包好，扫码或点击文末原文链接即可下载?

K8s 技术落地实践资料下载

一、企业应用向容器迁移和微服务改造实践

SPEAKER：张仁宇

介绍：容器化是云原生的第一步。将现有应用迁移成微服务架构的现代化应用，不应该通过从头重写代码方式实现，相反，应该通过逐步迁移的方式。有三种策略可以考虑：将新功能以微服务方式实现；将表现层与业务数据访问层分离；将现存模块抽取变成微服务。随着时间推移，微服务数量会增加，开发团队的弹性和效率将会大大增加。

为什么需要做容器化

• 在容器运行时上进行隔离能够减少物理虚拟操作系统这一层抽象，减少资源的消耗

  
  

• 容器化能够保证运行环境一致，真正做到 Build Once, Run Everywhere，解决了应用交付的问题

• 容器的创建和启动速度非常快，能够实现快速创建快速销毁，从而支持快速迭代，减少了维护和开发成本

为什么要做微服务

• 微服务能够解决软件复杂度增长带来的问题，实现模块之间的松耦合。

• 微服务能够解决应用不同模块不同层次的扩展性需求。

• 微服务能够解决单体应用可靠性差的问题。

• 微服务能够实现应用中不同模块采用不同语言进行开发、独立部署、独立测试，不需要考虑技术栈带来的影响。

如何做容器和微服务的改造

“微服务改造的方法论“要点如下：

• 避免大规模重写代码

• 不要在坑里挖坑，避免在单体应用中增加代码

• 分离前端和后端

• 抽出服务，可以使用 Sidecar 模式

首先，做容器化，狭义的解释，容器化就是上 K8s 的过程，把业务部署在 K8s 上。

第二，需要做 CI/CD、DevOps，积极拥抱 DevOps 文化，做到自动化、自动化运维、配置管理和测试。

第三，实现服务网格，也就是现在所说的代码无侵入的微服务解决方案。

二、K8S 监控实践：Prometheus，多租户与多集群

SPEAKER：霍秉杰

介绍：Prometheus 逐渐成为云原生领域监控事实上的标准。本次演讲将结合 Prometheus 讲述 K8s 监控的技术选型、架构、调优、持久化存储及 KubeSphere 的多租户监控实践

背景及介绍

监控系统是整个企业 IT 架构中的重中之重，小到故障排查、问题定位，大到业务预测、运营管理，都离不开稳定可靠的监控系统。在云原生时代，传统的监控方案已难以满足一些监控场景，比如跨主机资源对象的持续数据收集和监控。

为了解决这些痛点，Prometheus 项目应运而生。Prometheus 是云原生领域最受认可的时间序列监控解决方案，在 2016 年加入 CNCF 基金会后，成为继 K8s 后第二个毕业项目。Prometheus 已经成为云原生监控领域的事实标准。

相比于传统的监控，Prometheus 有以下几个优势：

• 高效存储引擎

Prometheus 把用户关心的监控场景以时序数据的形式进行采集、存储和处理到时序数据库。相比关系数据库，监控数据存储在基于时间序列的数据库内，便于对已有数据进行新的聚合，在高并发的情况下，读写性能是远高过传统的关系型数据库的

Prometheus 2.0 版本重构了底层时序存储引擎。目前，单个 Prometheus 服务器可以做到每秒存储百万条指标数据，同时占用磁盘空间也很小。（Prometheus 会将所有采集到的样本数据以时间序列(time-series)的方式保存在内存数据库中，并且定时保存到硬盘上）

• 强大的查询能力：PromQL

Prometheus 有独立的 PromQL 查询语言，另外还提供了很多内置的基于时间的处理函数，降低数据聚合的难度。

• 面向服务的架构

Prometheus 采用拉模型收集时序数据，数据拉取行为是由服务端来决定的。服务端可以通过某种服务发现机制来自动发现监控对象。而对于推模型的监控系统，客户端需要负责在服务端上进行注册及监控数据推送，这在微服务架构里实现起来比较难的。当大量客户端向服务端主动推送数据时，服务端的压力较大。

• 与 K8s 天然集成 

K8s 本身的指标也是以 Prometheus 格式暴露出来的。

• 逐步完善的生态

OpenMetrics：Prometheus 的数据格式逐渐成为一种标准。OpenMetrics 正在从 Prometheus 的数据格式中分离出来，逐渐成为监控数据格式的国际标准

Thanos：支持数据存储的可伸缩，弥补 Prometheus 数据持久化方面的不足Prometheus

Prometheus Operator：简化 Prometheus 配置管理

也许我们现在看这些 feature 觉得理所当然，但是当时 Prometheus 发布的时候，是非常吸引人的。

Prometheus 的架构

Prometheus 如何工作？我们能用 Prometheus 做些什么？

首先，用户编写客户端程序，为需要监控的服务生成相应的指标并暴露给 Prometheus 服务器。Prometheus 通过 HTTP 协议周期性抓取被监控组件的状态，任意组件只要提供对应 /metrics 接口就可以接入监控。不需要任何其他的集成过程，这样做非常适合做虚拟化环境监控系统。

对于不适合自己编写客户端程序的场景，比如第三方应用监控、物理节点监控、K8s 集群监控，Prometheus 提供了 exporter 来暴露第三方应用指标，比如 mysql exporter。还有我们使用比较多 node exporter 和 kube-state-metrics exporter，这些都是 Prometheus 官方在维护。

Prometheus 把监控数据存储在本地的时序数据库中，缺少数据副本，这是 Prometheus 在数据持久化方面做的不足的地方。这是因为 Prometheus 开发团队聚焦核心，只开发单节点的 Prometheus。但 Prometheus 也提供 remote_write 的方式，支持将数据存储到其他时序数据库中。比较常见的持久化方案有：Cortex、InfluxDB、Thanos

Prometheus 支持通过 Kubernetes、静态文本、Consul、DNS 等多种服务发现方式来指定抓取目标的监控数据。最后，用户编写 PromQL 语句查询数据并进行可视化。

Prometheus 在 K8s 部署的架构图

这张图是我们在 K8s 容器平台上部署 Prometheus 的架构。左下角 Prometheus 可以从 Kubernetes 集群的各个组件中采集监控数据，比如 kubelet 中自带的 cadvisor 提供的容器相关指标数据，API Server 提供 QPS 数据等。

上面两个 Prometheus 副本提供 HA 的能力，以负载均衡的方式对外提供 API。数据可视化界面和告警模块会用到Prometheus 提供的监控 API，中间的 Prometheus Operator，提供自动化管理和配置 Prometheus。

我们来看一下 Prometheus 的数据模型：

Prometheus 采用的是时序数据模型 time-series，时序数据是按照时间戳序列存放。每一条时间序列由指标名称 metric name 和一组标签 labelset 命名。对于相同的度量名称，通过不同标签列表的结合, 会形成特定的度量维度实例。这里是实时采集 node exporter 指标的一个例子，自增 counter 类型的指标，反应节点各 CPU 不同模式下的运行时间。

总结来说，time-series 中的每一行数据称为一个 sample ，sample 由以下三部分组成：

• 指标(metric) ：metric name 和描述当前样本特征的 labelset

• 时间戳(timestamp)：一个精确到毫秒的时间戳。

• 样本值(value)：一个 float64 的浮点型数据表示当前样本的值。 4

Prometheus 配置管理

Prometheus 配置管理是很麻烦的，需要手动。Prometheus 配置分两种：

• 不可变的启动参数

包括最大连接数、数据存储路径、数据最大保留时长。对 Prometheus 不可变参数进行升级，我们需要手动移除已经运行的 Pod 实例，从而让 Kubernetes 可以使用最新的配置文件创建 Prometheus。

• Prometheus 采集参数配置 

包括监控对象的列表、recording rules 等。修改这类配置需要在修改后，手动调用 reload 接口。

对于较少 Prometheus 实例，可以手动修改配置。如果实例的数量更多时，通过手动的方式部署和升级 Prometheus 过程繁琐并且效率低下。我们可以使用 Prometheus Operator 以声明式配置的方式实现自动化配置管理。   

上图是 Prometheus Operator 官方提供的架构图，其中 Operator 是最核心的部分，作为一个控制器，它会持续观察 Prometheus、ServiceMonitor、以及 PrometheusRules 3 个 CRD 资源对象，并维持 Prometheus Server 的状态。

其中创建的 Prometheus 这个 CRD 是作为 Prometheus Server 存在，而 ServiceMonitor 负责定位 exporter，exporter 前面我们已经学习了，是专门用来提供 metrics 数据接口的 客户端程序，Prometheus 通过 ServiceMonitor 提供的 监控对象列表去 pull 数据的，这样我们要在集群中监控什么数据，就变成了直接去操作 Kubernetes 集群的 CRD 资源对象，方便了很多。

我们也在为 Prometheus 开源社区作贡献。

三、Network Policy 最佳实践

SPEAKER：赖正一

介绍：在应用转向容器化、微服务之后，传统的网络安全策略渐渐无法再满足需求。本次演讲将会讲述 K8s 上 Network Policy 的用法、原理及 KubeSphere 会如何给用户带来 Network Policy 的最佳实践。

什么是 NetworkPolicy

NetworkPolicy 就是云原生语境下的防火墙，控制 Pod 的入口、出口流量。

NetworkPolicy 由以下三个部分组成：匹配哪些 Pod，入口流量的规则——表示谁被允许访问这些 Pod，出口流量的规则表示这些 Pod 被允许访问谁。

支持 NetworkPolicy 的常见 CNI 插件，包括 Calico，Cilium，Kube-router，Romana，Weave Net。

NetworkPolicy 如何运行

K8s 使用 Label Selector 机制选择 Pod 资源，一些基础规则如下：

• 如果 Pod 没有被 NetworkPolicy 匹配到，那么它的流量是被允许的。

• 如果 Pod 被 NetworkPolicy 匹配到，但是没有出口/入口规则被匹配到，那么它的出口/入口流量是被禁止的。

• 只能指定规则来允许流量通行，而不能直接禁止流量通行。

• NetworkPolicy 中的 Rule 之间的匹配逻辑是 OR

• NetworkPolicy 默认的作用域是 Pod 所在的 Namespace

NetworkPolicy 的最佳实践

一、创建一条 default-deny-all 规则

• 禁止 Namespace 内所有的出口和入口流量

• 针对对需要的应用或者 Namespace 或者外网启用白名单

二、熟悉 NetworkPolicy 的书写语法

• 网络策略:
  

• pod选择器, 表示当前网络策略应用在哪些pod上, "选择器语法"

  
  

• 入口策略组, 表示允许匹配到入口策略的pod访问被上面的pod选择器选中的pod, 匹配逻辑为or

  
  

• 出口策略组, 表示允许匹配到出口策略的pod被上面pod选择器选中的pod所访问, 匹配逻辑为or

• 选择器语法:

• 匹配label, key-value形式, 匹配逻辑为and

  
  

• 匹配表达式, 匹配逻辑为and

• 网络策略规则语法

三、查看网络连通性

• 使用 kubectl describe networkpolicies 查看

• 在被禁止和被允许的 Pod 上测试

• 测试外部网络

• 入口：是否允许外部 LB 访问

• 出口：是否允许访问外部网络

  
  

测试其他 Namespace 和 Port

点击阅读原文，一键下载资料。

延续 CIC 2019“云无界 数未来”主题，CIC 2019 青云QingCloud 全国巡展将于 10 月 11 日正式开启。此次巡展将覆盖 10 个重点城市，致力于分享行业领袖与专家智囊的实战经验与思想洞见，构建并展现多元的生态合作与联合解决方案。点击上方小程序立即报名?

- FIN -

关注公众号：拾黑（shiheibook）了解更多

[广告]赞助链接：

四季很好，只要有你，文娱排行榜：https://www.yaopaiming.com/
让资讯触达的更精准有趣：https://www.0xu.cn/