基于Kubernetes的私有云实战

⾼川
P1
 为什么要建设私有云 01

公司当前技术现状 02

私有云建设⽅案 03

私有云建设收益 04

遇到的问题 05

⽬ 录 未来规划 06
为什么要做私有云？
 公司规模扩⼤⾯临的常态问题

• ⾼速增⻓的业务和低下的资源利⽤率
• 需要⾼效的扩缩容和部署效率
• 复杂的业务场景带来了层出不穷的异构机型
• ⾼昂的机房成本投⼊
公司当前的技术现状
微服务现状

•服务数量暴涨
•资源需求暴涨
•部署效率急需提高
•研发期望独占资源
服务治理现状

•Homebrew microservice
•配置手工管理
•L7划分不清，耦合业务逻辑
•SDK能发现grpc发现不了http
部署环境现状

•复杂的环境管理和大量的AB服
务产生了复杂的部署系统

•AB服务是中短期资源消耗型服
务，要求交付快释放快
上云前的现状

•大量物理机部署
•技术栈单一，90%为golang
•最多时有200个AB服务，均单独部署
•研发有在机器上调试的需求
私有云建设⽅案
Kubernetes提供了什么

•Pods
•Services
•DNS
•ConfigMaps
 整体思路

• 容器能不能做无状态的“物理机”来用？不用它的服

务发现，不用它的负载均衡，不用它的配置中心。

（这些我们都有了）

“当然可以”
 技术方案

• 容器方案

• 网络方案

• 集群方案

• 服务发现方案

• 平台方案
容器方案

•Supervisord
•Syslog
•Sshd
•业务二进制
•配置文件
容器方案

•Supervisord守护其它进程
•通过ssh登陆
•集成大量工具
•使用方式与物理机无异
 问题：上容器有多大性能损失？

没有频繁的磁盘访问的应用容器和本地进程无异，网络为主要开消
想要的网络方案

•全网能够互通
•简单能掌控
•后续能定制
•尽量减少链路时延
 琳琅满目的网络方案

•Flannel
•Calico
•Cilium
•Kube-Router
•Macvlan
•… (剩余几十个)
 方案一：Flannel网络方案

基础网络IP可达就可用，适用性高，有一定网络延迟
 方案二：Calico网络方案

基于BGP做动态路由发现的网络模型，需要基础网络支持BGP，架构复杂
 方案三：Macvlan网络方案

Macvlan是Linux操作系统内核提供的网络虚拟化方案之一
它可以为一张物理网卡设置多个mac地址
Macvlan Wins！

•几乎是业界最快网络模型
•网络延迟几乎与物理机一致
•简单的设计，易掌控
 集群方案

一个超大集群还是多个中小集群？
集群方案

•超级部署屏蔽K8S的各类资源
•一个部署调度到多个集群
•业务可自定调度策略
•达到机架、机房、集群级容灾
服务发现方案

•K8S自带的服务发现不可用
•基于Pod事件的服务发现
•现状妥协导致服务发现链路变长
集群失败了

•没有办法操作K8S？
•基于假事件的重新调度
•灾难场景可迁移至备份集群
部署平台

•研发平台支持混合部署
•研发直接容器扩容完成迁移
•研发精确控制发版速度
•支持容器回滚到物理机
容器平台

•平台化的多集群管理
•清晰简单的运维操作
•灾难场景一健迁移
 研发最关心的问题

•上容器性能有多大损失？ •Macvlan基本和物理机一样
•容器集群稳定性多高？ •多集群方案挂一个集群业务无感
•业务需要做哪些适配？ •基本不用修改
•日志、监控、登陆、调试怎么用？ •和老方式保持一至
•上容器我有什么收益？ •极速发版，快速扩容，自动伸缩
私有云建设收益
上云成果
遇到的问题
问题⼀：上容器后时延变⼤了
 问题⼀：上容器后时延变⼤了

• GOMAXPROCS默认会根据CPU数创建调度线程
• 容器内看到的是宿住机的CP
• Go不是NUMA友好的

 解决⽅案⼀：Lxcfs

• 通⽤⽅案，适合任何语⾔
• 重新mount部署proc⽬录mock机器信息
• 守护进程失败会导致当前运⾏的容器⽆法获取
正确proc信息，需要重新注⼊
解决⽅案⼆：修改GOMAXPROCS

• Golang专⽤解决⽅案
• import _ "go.uber.org/automaxprocs"
2C1G的容器在96核宿主机测试结果
问题⼆：K8S宿主机负载不均衡
K8S调度问题：NP-Hard BinPacking Problem
K8S的调度原理
 K8S的调度原理

调度器调度⼀个 Pod 的过程分为两个阶段：调度周期 和 绑定周期

调度周期
• 选择符合条件的Node （硬性选择）
• 给Node打分 （软性选择）
绑定周期
• 向binding接⼝发送Post请求，把结果告诉k8s
 基于CPU实时使⽤率的调度器

score=(1 - cpu_used_seconds / cpu_total ) * Maxscore

借助Scheduling Framework可以实现⾃定义的调度器
未来规划
垂涎已久的架构

ServiceMesh
实际案例
踩坑之旅？

欢迎⼀起交流😊
谢谢聆听！