ofo容器pass架构分享

一、我们先要了解一下,为什么企业需要一个paas平台?或者可以说paas到底能做什么?

1.1 我们先来了解一下paas到底是什么?

PaaS是Platform-as-a-Service的缩写,意思是平台即服务,
首先,在了解Paas之前需要知道什么是云计算,云计算是指基于互联网网络,通过虚拟化(xen OpenStack)统一管理和调度计算,国内厂商如:阿里云/aws/ucloud/等等
目前云计算三大类:

1.基础设施即服务(IaaS)
2.平台即服务(PaaS)
3.软件即服务(SaaS)

1.2企业为什么需要一个PaaS?

平台即服务(PaaS)
PaaS提供应用服务引擎,将软件研发测试和运维的平台作为一种服务提供,应用程序接口,开发人员基于这些服务构建业务应用。从运维和开发角度来说,这意味着无需运维搭建环境,开发也不会因为不同平台兼容性方面遇到困扰。

 

二、ofo for PaaS(kubernetes)平台介绍

2.1 平台简介

  1. 提供多种应用发布方式和持续交付能力并支持微服务架构。
  2. 平台自身组件支持实时横向扩展,一键式应用快速部署。
  3. PaaS简化了集群管理,监控、日常运维操作简化
  4. 整合了CI/CD/以及云厂商的虚拟化、存储、网络和安全
  5. 业务高峰自动扩缩容,根据应用的负载情况,动态加载应用实例;
  6. kubernetes HPA pod根据配置阀值自动扩缩容,node节点cpu配置阀值,集成各个云厂商api,自动扩容node节点。
  7. 保证公司业务1分钟内自动恢复。全年故障率降低。
  8. 更高的资源利用率 node节点单机性能最大化
  9. 节省服务器成本百分之40-60。

2.2 Dashboard

  • 显示当前集群
  • 节点状态
  • 节点监控
  • 组件状态
  • POD、namespace等等

2.3 应用服务

  • pod管理
  • service管理

2.4 定时任务

  • kubernetes 、cronjob管理

2.5 配置中心

  • configmap管理

2.6 CI/CD

  • DevOps 持续交付
  • 配合 Jenkins 自动完成从代码提交到应用部署的 DevOps
  • 实现从代码变更到代码构建,镜像构建和应用部署的全流程自动化,持续反馈
  • 每次集成或交付,都会第一时间将结果实时反馈

2.7 资源审计监控

  • PAAS平台操作审计
  • Webshell操作审计
  • 资源利用率Dashboard
  • 容器资源使用报表

2.8 高级功能

  • 特权容器:容器性能优化,问题诊断strace
  • 主机网络:使用宿主机网络环境
  • 初始化容器:性能优化,容器内最小权限
  • 创建网络服务:对集群内(外)提供网络服务
  • 容器Webshell:登录容器,问题诊断

 

三、生产环境高并发线上业务容器化

我们在生产环境下运维kubernetes 已经有一段时间了,我们7*24 全天候 为每一个业务保驾护航ofo容器云 (简称Ruly)我们底层基于某云容器基础服务,以及自建机房IDC、通过调用云平台API以及RO模板快速创建管理docker实例。

  1. 我们team在高并发业务场景下做了哪些优化
  2. 容器化后比之前性能要好,同配置下延迟更低、故障恢复时间更快,服务成本降低
  3. 分享个线上case 我们team在高并发业务场景下做了哪些优化 3.1 优化:基础篇性能测试 

我们team在高并发业务场景下做了哪些优化

  3.1 优化:基础篇性能测试

选择比较适合的实例规格或机器型号. 云服务器需支持多队列网卡

 

 

 

3.2 系统层面优化

操作系统优化:支持大并发,单集群2000节点
K8s&容器层面优化:支持大并发,基础镜像制作优化等等
Principle:最小权限,优先跑满容器资源限制
docker宿主目录直接跑在默认/var/lib/docker下 长期跑下来会导致系统盘异常。导致down机等。因此我们做了一下调整,自定义镜像(lvm) 增加可扩展性

3.3 内核参优化
docker进程异常Dead状态 at centos 7.4 
* 增加fs.may_detach_mounts

 

总结:我们做了大量业务压测,以及云平台slb 、ecs idc 机器做了大量的性能调优,对业务的优化,配合开发同学做了大量的debug 才使得我们业务能在容器稳定的运行

3.4 容器化后比之前性能要好,同配置下延迟更低、故障恢复时间更快,服务成本降低
容器vs传统部署模式 (最后两个0.98ms 和0.96ms 为容器

 

3.5 分享个线上case

在某某天一个凌晨4点,突然接到短信报警,此时大家都在深睡,早上八点起床后发现收到了两条报警,一条是磁盘80%的告警,一条是磁盘恢复的报警,我们可以想象一下哈,如果你业务部署到了服务器,将会发生什么,4-8点完全可以吧机器磁盘空间写满,导致业务异常。机器oom 为什么容器会自动恢复呢。原因和简单,kubernetes自带有异常的pod自动驱逐,当磁盘空间大于百分之80 他会判定这个pod是有问题的。

解释:
本地磁盘是一个 BestEffort 资源,kubelet 会在 DiskPressure 的情况下,kubelet 会按照 QoS 进行评估。如果 Kubelet 判定缺乏 inode 资源,就会通过驱逐最低 QoS 的 Pod 的方式来回收 inodes。如果 kubelet 判定缺乏磁盘空间,就会通过在相同 QoS 的 Pods 中,选择消耗最多磁盘空间的 Pod 进行驱逐。

四、kubernetes之生产环境etcd高可用、备份、监控等

 

4.1 要说到kubernetes,就一定要聊聊etcd ,他存储了于整个kubernetes的信息

etcd是一个高可用的键值存储系统,主要用于共享配置和服务发现。etcd是由CoreOS开发并维护的,灵感来自于 ZooKeeper 和 Doozer,它使用Go语言编写,并通过Raft一致性算法处理日志复制以保证强一致性。
etcd可以用于配置共享和服务发现。

 

4.2 etcd主要分为四个部分:

HTTP Server:用于处理用户发送的API请求以及其他etcd节点的同步与心跳信息请求

Store:存储,用于处理etcd支持的各类功能的事务,包括数据索引,节点状态变更,事件处理与执行等。它是etcd对用于提供的大多数API功能的具体实现

Raft: Raft强一致算法的具体实现,是etcd的核心

WAL: Write Ahead Log(日志先行),WAL是一种实现事务日志的标准方法。etcd通过WAL进行持久化存储,所有的数据在提交之前都会事先记录日志 a. Snapshot: 防止数据过多而进行的状态快照 b. Entry: 存储的具体的日志内容

 

4.3 etcd中的术语:

  • Raft: etcd所采用的保证分布式系统强一致的算法
  • Node: 一个Raft状态机实例
  • Member: 一个etcd实例,管理一个Node,可以为客户端请求提供服务
  • Cluster: 多个Member构成的可以协同工作的etcd集群
  • Peer: 同一个集群中,其他Member的称呼
  • Client: 向etcd集群发送HTTP请求的客户端
  • WAL: 预写日志,是etcd用于持久化存储的日志格式
  • Snapshot: etcd防止WAL文件过多而设置的快照,存储etcd数据状态
  • Proxy: etcd的一种模式,可以为etcd提供反向代理服务
  • Leader: Raft算法中通过竞选而产生的处理所有数据提交的节点
  • Follower: Raft算法中竞选失败的节点,作为从属节点,为算法提供强一致性保证
  • Candidate: Follower超过一定时间接收不到Leader节点的心跳的时候,会转变为Candidate(候选者)开始Leader竞选
  • Term: 某个节点称为Leader到下一次竞选开始的时间周期,称为Term(任界,任期)
  • Index: 数据项编号, Raft中通过Term和Index来定位数据

4.4 Raft 状态机

Raft集群中的每个节点都处于一种基于角色的状态机中。具体来说,Raft定义了节点的三种角色: Follower、Candidate和Leader。

  • Leader(领导者): Leader节点在集群中有且仅能有一个,它负责向所有的Follower节点同步日志数据
  • Follower(跟随者): Follower节点从Leader节点获取日志,提供数据查询功能,并将所有修改请求转发给Leader节点
  • Candidate(候选者): 当集群中的Leader节点不存在或者失联之后,其他Follower节点转换为Candidate,然后开始新的Leader节点选举

这三种角色状态之间的转换,如下图:

 

一个 Raft 集群包含若干个服务器节点;通常是 5 个,这允许整个系统容忍 2 个节点的失效。在任何时刻,每一个服务器节点都处于这三个状态之一:领导人、跟随者或者候选人。在通常情况下,系统中只有一个领导人并且其他的节点全部都是跟随者。跟随者都是被动的:他们不会发送任何请求,只是简单的响应来自领导者或者候选人的请求。领导人处理所有的客户端请求(如果一个客户端和跟随者联系,那么跟随者会把请求重定向给领导人)

每次成功选举,新的Leader的Term(任届)值都会比之前的Leader增加1。当集群中由于网络或者其他原因出现分裂后又重新合并的时候,集群中可能会出现多于一个的Leader节点。此时,Term值更高的节点才会成为真正的Leader。

4.5 etcd client

主要包含以下几个功能:

  • Cluster:向集群里增加etcd服务端节点之类,属于管理员操作。
  • KV:我们主要使用的功能,即操作K-V。
  • Lease:租约相关操作,比如申请一个TTL=10秒的租约。
  • Watcher:观察订阅,从而监听最新的数据变化。
  • Auth:管理etcd的用户和权限,属于管理员操作。
  • Maintenance:维护etcd,比如主动迁移etcd的leader节点,属于管理员操作

4.6.etcd 运维、与备份

 

  • 安装就不在这里详细介绍了。简单介绍下日常运维以及备份

一、查看集群中的节点
ETCDCTL_API=3 etcdctl --endpoints=https://xxx.xx.xx.xx --cacert=ca.pem --cert=etcd-client.pem --key=etcd-client-key.pem --write-out=table member list

二、添加节点

使用etcdctl member add node-name --peer-urls="https://xxx:2380"添加节点,生成变量。

1.准备新机器, 将上一步生成的配置文件变量,写到新节点,尤其是集群状态为existing。(目标节点的数据目录要清空)

2.生成用于集群节点通信的SSL证书

3.生成用于客户端和节点通信的证书

4.启动并检查

三、生产环境建议

建议采取多台etcd集群至5台,保证多个节点挂掉不会影响使用

四、etcd 备份

配合 cronjob nfs 或 云共享储存 建议分钟级别保留

4.7. etcd 监控

推荐promtheus + grafana 可自定义promtheus etcd 报警规则,或grafana alert 插件报警 等等

 

参考 https://coreos.com/etcd/docs/latest/op-guide/monitoring.html

五、容器基础监控、业务监控

监控是整个运维环节,乃⾄至整个产品⽣生命周期中最重要的⼀环、事前及时预警发现故障、事后提供数据追查定位问题,分析业务指标等等坚持业务指标采集是代码的⼀部分原则不不动摇,提⾼高指标覆盖率监控⽅方式和指标要标准化。

5.1. 定制容器基础监控规则、规范。比如cpu阀值、内存阀值、磁盘阀值等等、高峰期 robot自动巡检 报告
5.2. 监控选型:promtheus 、zabbix 等等

  • Promtheus 负责监控整个集群 配合grafana
  • 业务监控:监控pod cpu mem 使用率 等等
  • zabbix:负责文本类监控,如message 监控 kubernetes pod list 是否 running状态、以及pod扩缩容监控

5.3.报警规则,怎么才能让避免垃圾报警。避免狼来了的故事
所有报警规则promtheus 或 zabbix 需根据kubernetes Kubelet 监控资源消耗规则匹配,特别注意要和kubernetes一些自动恢复规则最好匹配,尽量低于kubernetes规则,要比kubernetes早发现,自研告警信息管理平台,
在一个平台中接收所有监控系统的告警,让运维人员集中处理系统异常事件,避免多平台切换,提升运维效率。 promtheus、Zabbix等主流监控平台的告警自动整合进来 ,使用时间序列规则,将大量重复的告警事件压缩为一条有真正意义的告警。而后通过属性关联、 机器学习等算法把相关的告警合并起来,安排一线运维负责7x24小时应急值守, 快速接收告警进行初步预判,二线研发团队负责告警升级的分析和根源定位,建议使用钉钉,短信报警

一个kubernetes 集群的 dashborad 基本信息

 

指定pod cpu mem 监控

 

5.4 pod自动扩容提醒 和异常pod(crashloopbackoff)报警(钉钉报警)

 

5.5 业务监控 、pod cpu 内存 监控 高峰期自动钉钉发送 无人值守

 

六、kubernetes趟过的坑

6.1 案例一

异常:
authentication.k8s.io:0xc820374f50] is already registered
kubectl throwing group is already registered error
原因:
kubectl版本与Kubernetes版本不一致导致的
解决:
选择相应的kubectl版本重新安装

 

6.2 案例二
异常:
kubelet: E0529 17:40:11.741095 14358 fs.go:418] Stat fs failed. Error: no such file or directory

原因:由于安装docker时宿主目录被软链 overlayfs清理container不完整导致的

解决:
安装kubernetes集群时 docker需要配置好宿主目录 不要软链

 

6.3案例三

异常:svc ip 变化 导致无法访问,1.9.4之前的惊天大BUG

原因:一个或者多个 Kubernetes service 对应的 Kubernetes endpoints 消失几分钟或者更长时间,kubectl get ep --all-namespaces” 不断查询,可以观察到一些 AGE 在分钟级别的 endpoints 总是忽然消失,endpoints不稳定,导致service无法变化

解决:升级kubernetes至1.9.3或更高 1.9.2的bug

 

6.4 案例四
异常:做线上cordon节点的时候 服务不可以用,导致某云slb 无法转发到节点的容器业务服务

原因:一般设置cordon的之后就会drain做排水调度,在ServiceController里面确实会将unschedulable的节点从service上移除,这个是目前kubernetes的机制

解决:做cordon操作时选择在业务低峰期,比如凌晨操作,分批操作不要一下子全部cordon

七、trouble shooting for linux

常用技巧

• 通过系统级别的方法先查看整体系统负载情况,再快速定位具体模块问题
• top / iotop / iftop等查看CPU负载,io负载,网卡负载总体情况
• ps / lsof查看(连接句柄)进程当前关联的句柄(进程)
• strace抓一段时间可疑进程的系统调用情况
lsof
• 枚举进程打开的句柄(文件、sockets)
• 查看某一文件或连接(TCP/UDP端口)所关联的进程
• 查看flock文件锁&线程锁交叉导致的死锁(W)
• lsof
• lsof -nPp 
• lsof -nPI@192.168.xx.x:22
• lsof /var/lib/mysql/mysql.sock
ss

• 查看TCP/UDP sockets状态
• ss -an | grep LISTEN
• netstat -s
• EST, CLOSE-WAIT, TIME-WAIT, SYN_RECV
• 发送TCP RST可以避免进入TIME-WAIT状态
Tcpdump
• 网络抓包,网络故障分析
• tcpdump -vv -i eth0 port xx -X -s 0
• tcpdump -vv -s 0 -i eth0 port xx -w /tmp/xx.pcap





转载于:https://www.cnblogs.com/baishuchao/p/9108144.html

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值