2019年润物细无声-在行业务的容器化改革之路.pdf

1、GOP S 全 球 运 维 大 会 2019上 海 站GOP S 全 球 运 维 大 会 2019上 海 站润物细无声在行业务的容器化改造之路GOP S 全 球 运 维 大 会 2019上 海 站GOP S 全 球 运 维 大 会 2019上 海 站目录背景1容器化必须解决的问题2策略3过程4收益5GOP S 全 球 运 维 大 会 2019上 海 站GOP S 全 球 运 维 大 会 2019上 海 站微服务是个古老的话题，框架发展至今已经有很大的相似性，比如Eureka，Consul，Nacos，主要是在前两个中间选择，对Nacos了解不多。最后选择了Consul，这个选择对容器化也比较友

2、好。GOP S 全 球 运 维 大 会 2019上 海 站每一个运维团队都应该有一套CMDB，而且只有一套。我对CMDB的理解是：对运维范围内的关注对象的数据刻画，是运维自动化的基础。在这个工具的选择上，建议是要么找一个有足够定制空间的产品，要么定制，但最好的做法还是自己实现一套。自己实现可以对我们关心的运维领域的对象作更精确的建模，也允许我们在改进部署形态和管理方式时更自由。在不同的时期，我们对运维领域的对象模型是有区别的。GOP S 全 球 运 维 大 会 2019上 海 站GOP S 全 球 运 维 大 会 2019上 海 站发布物管理部署方式管理部署结果确认回滚和例外处理代码包+配置+

3、数据库脚本系统自检接口+监控数据启动停止脚本+前置检查部署前快照采集发布平台的作用GOP S 全 球 运 维 大 会 2019上 海 站目录背景1容器化必须解决的问题2策略3过程4收益5GOP S 全 球 运 维 大 会 2019上 海 站GOP S 全 球 运 维 大 会 2019上 海 站XGOP S 全 球 运 维 大 会 2019上 海 站GOP S 全 球 运 维 大 会 2019上 海 站calico的设计方提供了ipip和BGP两种通信模式，在节点不多的情况下使用ipip方式，但ipip方式的性能开销是O(N2)，要在规模大起来之前切换到BGP模式GOP S 全 球 运 维 大

4、会 2019上 海 站内层协议只要是IP协议族的就可以，图中是ICMP协议，TCP协议可以再向下展开一层主流的包分析工具对IPIP协议是友好的，可以识别内层协议和写过滤表达式。使用自己实现的工具分析网络流量时候需要关注有无IPIP协议的区别。GOP S 全 球 运 维 大 会 2019上 海 站微服务访问方式NATIPIPGOP S 全 球 运 维 大 会 2019上 海 站GOP S 全 球 运 维 大 会 2019上 海 站GOP S 全 球 运 维 大 会 2019上 海 站GOP S 全 球 运 维 大 会 2019上 海 站 容器本身特性Log-Pilot破解之道采集目标多同时支持s

5、tdout和容器内文件日志采集弹性伸缩性支持声明式日志配置 现有采集工具缺陷缺乏动态配置能力自动感知（发现）机制日志采集重复或丢失自动checkpoint及句柄保持机制未明确标记日志源自动日志数据打标资源消耗大采用 node 方式进行部署GOP S 全 球 运 维 大 会 2019上 海 站K8s_pod：容器所属的pod名称K8s_pod_namespace：容器所属的namespace名称K8s_node_name：容器所在的node节点名称K8s_container_name：容器名称自动采集了日志源的各种信息日志还是一样的日志GOP S 全 球 运 维 大 会 2019上 海 站GOP

6、 S 全 球 运 维 大 会 2019上 海 站GOP S 全 球 运 维 大 会 2019上 海 站需要克服的主要差异：【1】容器化后除了node/master以外都是非永久对象，监控采集数据不再有历史数据关联【2】（Prometheus的）时序数据库TSDB对采集和绘图友好，对问题调查和分析并不友好【3】AlterManager没有报警历史数据留存策略：A：AlertManager后接报警分发系统（自研），由分发系统做数据留存【3】B：对TSDB数据作数据转置写入RDBMS【1，2，3】【计划中】AlertMa