微博 彭涛 微博Kubernetes实践经验分享

CodeWarrior

2019/07/08 发布于 编程 分类

GIAC2019 

文字内容
1. 微博Kubernetes实践经验分享 彭涛 新浪微博 架构师
3. 一 、大纲 1. 微博做Kubernetes的整体背景 2. 在推进Kubernetes落地遇到的坑 3. 展望和总结
4. 二 、背景 • 微博是如何应对挑战的-架构的演进 • 微博当前架构下遇到的问题 • 整体的解决思路
5. 二 、微博基础架构的演进 服务化 Docker 容器化 DCP 混合云 • 降低应用变更复杂度 • 解耦服务之间的依赖 • 屏蔽业务的差异性 • 隔离服务的环境依赖 • 最小成本解决峰值流 量应对
6. 二 、微博当前架构下遇到的问题(某女星结婚的流量视图) • • • IAAS层的扩容计划是最少6分钟以上(三分钟系统自检+三分钟业 务容器启动+创建机器排队+获取IP后变更负载均衡…) 流量涨幅约50%,而且在4分钟内达到顶峰 IAAS层扩容不能解决该问题,只能降级+扩容并行完成………
7. 二 、微博当前架构下遇到的问题
8. 二 、整体的解决思路(利用闲散资源完成扩容) 模块化 容器 精细 调度 资源池化
9. 三 、微博容器管理平台整体架构
10. 四 、如何基于Kubernetes来解决问题 • • • • 基础建设之网络、计算、存储资源池化 精细化调度和IP预分配 In-place rolling update的滚动发布 模块化容器的思维
11. 四 、资源池化 存储 资源池 计算 网络
12. 四 、基础建设之网络遇到的问题 内网网络 公有云网络 虚拟IP会被防火墙拦截 Node IP=192.168.1.1 Mac=##:##:##:## eth0 eth0 Vlan=100 Node IP=192.168.1.1 Mac=##:##:##:## 防火墙 Pod IP=10.0.0.1 Mac=FF:FF:FF:FF'>FF:FF:FF:FF Pod IP=10.0.0.1 Mac=FF:FF:FF:FF'>FF:FF:FF:FF
13. 四 、公有云网络方案选型 需求 隧道类 BGP类 性能 损耗10%~20% 没有损耗 支持公有云 支持 不支持 结论 不使用 不使用 弹性网卡+CNI-Host-Device
14. 四 、公有云网络方案 弹性网卡负责虚拟出 Host-Device 负责把虚拟网卡 多块带可用IP的虚拟网卡 插入到容器里面 Node eth0 Node Pod eth1 Pod eth1 Pod eth2 Pod eth2 Pod eth3 Pod eth3 eth0
15. 四 、内网网络方案选型 需求 隧道类 BGP类 性能 损耗10%~20% 会使用IPTables做 ACL, 容易丢包 结论 不使用 需要做二次开发后 使用 Vlan+MacVlan
16. 四 、内网网络方案 Node Pod MacVlan Pod MacVlan eth0.1 CIDR=10.145.0..0/24 Pod MacVlan 网卡子接口 eth0.2 物理机IP eth0 上联交换机 开启trunk模式
17. 四 、内网BGP方案 BGP peer AS-A Calico Rtr ToR Switch Ethernet switch BGP peer Node1 As-A Calico Rtr BGP peer Node2 As-A Calico Rtr BGP peer 核心交换 ToR Switch AS-B Calico Rtr Ethernet switch BGP peer BGP peer Node3 Node4 As-B As-B Calico Calico Rtr Rtr
18. 四 、基础建设之存储遇到的问题 Node Pod PV/PVC Pod PV/PVC Pod PV/PVC 存储 不提供有配额限制的本地静态存储
19. 四 、静态存储方案 Node Pod Pod Pod PV/PVC PV/PVC PV/PVC block device block device block device 存储 通过块设备实现本地静态存储
20. 四 、基础建设之计算遇到的问题 Node Pod Pod Pod memory memory memory swap 计算 没有限制Pod访问物理机swap
21. 四 、基础建设之计算遇到的问题 Node Pod Pod Pod memory memory memory swap 计算 Kubernetes通过cgroups实现的内存限制,可以加以修改
22. 四 、资源池化的总结和归纳 在不增加成本的情况下通过Kubernetes提供了资源核心服务池30%~50%算力的计 算资源
23. 四 、Kubernetes的调度存在哪些问题 调度策略筛选维度少 无法给出库存 Pod Node Node Only 1 Can Create Pod memory Pod CPU Pod Pod CPU memory 100Mb Bandwidth < 30Mb
24. 四 、微博容器平台调度架构 接口层 初筛层 优选层 部署层 IP锁定接口 (申请库存接口) C/GPU初筛 IP释放接口 (释放库存接口) 带宽初筛 硬盘初筛 内存初筛 IDC优选 服务池优选 部署方式
25. 四 、微博容器精细化调度 接口层 物理机 计算密集型 初筛 G/CPU初筛 优选 部署策略 服务优选 A机房 内存初筛 调度策略 硬盘初筛 物理机 存储型 B机房 IDC优选 带宽初筛 输出锁定IP
26. 四 、微博容器精细化调度和IP预分配的优势 需求 IAAS层弹性扩容 微博容器平台扩容 耗时 1分钟创建机器+3 分钟开机+3分钟服 务启动完成+30秒7 层负载变更= 6分30秒 只需要3分钟 应对峰值流量有 6分多钟的窗口期 耗时只有 IAAS方案的一半 结论
27. 四 、Kubernetes滚动发布有什么问题 不支持原地升级 IP无法固定 Node A Pod With new Tag Node IP=10.0.0.1 Pod Pod IP=10.0.0.2 Pod With new Tag Node B Pod IP=10.0.0.2
28. 四 、Kubernetes滚动发布有什么问题 7层频繁变更 Node Pod With new Tag Pod With new Tag Pod With new Tag 性能抖动 微博负载均衡
29. 四 、微博容器平台支持In-place rolling update Pod With new Tag Node Label=10.0.0.1,10.0.0.2,10.0.0.3 调度 IP=10.0.0.1 Kubelet Pod IP=10.0.0.2 定制CNI NodeSelect= 10.0.0.2
30. 四 、In-place rolling update的优劣 需求 In-place rolling update Kubernetes原生 服务是否有损 有损(步长数) 无损 变更负载均衡次数 0 副本数/步长 本地日志存储 不影响 有影响 结论 微博采用这种 不采用
31. 四 、新业务容器整合难度大 端口冲突 Service Mesh 容器 日志处理方式不兼容 Node 服务池A Pod 域名解析 定时任务 日志压缩 数据推送 Node 服务池B 程 序 保 活 Pod 域名解析 定时任务 日志压缩 数据推送 程 序 保 活
32. 四 、在容器时代的运维应该是什么样的? 1. 模块化 2. 微型化 3. 即插即用 4. 通过共享存储来工作 5. 通过共享网络来通信 6. 具有自运维能力
33. 四 、利用Kubernetes的Pause模型整合容器完成日志推 送 Node Pod 输出到日志 业务容器 离线数据存储 输出到特定端口 Kafka 静态存储 监听文件 运维容器 网络协议栈 Pause 容器 监控 平台 监听端口 业务方消费 业务方消费
34. 四 、利用KubernetesPause模型ServiceMesh容器接入 Node Pod 输出到日志 业务容器 静态存储 监听文件 运维容器 输出到特定端口 网络协议栈 Pause 容器 监听端口 监听业务容器端口 Service Mesh 容器 增加isOk.sh脚本用 于Kubernetes调用 输出日志到 静态存储
35. 四 、不要使用系统的crontab去在容器里面定时任务 Node 服务池A 各种 异常 Pod Tool 容器 日志压缩 业务容器 域名解析 数据推送 Crontab /etc/init
36. 五 、总结 • • 后续的演进 QA
37. 五 、后续的演进 • 向云原生的方式改进我们的服务 DevOps CI/CD 基础设施即代码 提升发布效 率 屏蔽设备规 格差异 降低混部容 器的管理成 降低基础组 本 件整合门槛 DevOps 微服务 基础设施即代码 容器化
38. 五 、后续的演进 • CI/CD
39. 五 、后续的演进 • 人工智能的灰度发布生成指标指导自动化扩容
40. 欢迎关注msup微信公众账号 关注大会微信公共账号,及时了解大会动态、 日程及每日更新的案例! 关注公众号获得 更多案例实践