基于k8s的容器云平台运维实践.docx
- 文档编号:4594694
- 上传时间:2022-12-07
- 格式:DOCX
- 页数:18
- 大小:2.94MB
基于k8s的容器云平台运维实践.docx
《基于k8s的容器云平台运维实践.docx》由会员分享,可在线阅读,更多相关《基于k8s的容器云平台运维实践.docx(18页珍藏版)》请在冰豆网上搜索。
基于k8s的容器云平台运维实践
基于k8s的容器云平台运维实践
前言
容器云平台主要是基于k8s的技术。
将从以下六个方面介绍容器云的实践过程,分别是基本介绍、k8s集群、容器网络、外部访问4/7层负载均衡、监控/告警/日志、业务发布/镜像/多机房。
1、基本介绍
云平台的定位是私有云平台,主要是用于支撑在线业务,用以替换传统的虚拟化方式。
目前现状是2017年完成全国三个数据中心的建设,年内完成90%业务的迁移。
以小团队紧跟k8s社区步伐,快速迭代、低成本试错的方式来构建我们的平台。
同时,针对一些我们遇到的问题,做一些局部创新,在保证系统核心的随社区稳定升级的前提下,解决好非功能性问题。
2、k8s集群
对于k8s集群构建,将从k8s的单一镜像、k8s集群master、minion三个方面分别展开介绍。
2.1单一镜像
k8s 集群的安装部署是利用单一镜像 +dockerrun 实现一键安装。
为此将所有k8s相关的描述文件、脚本和二进制全部打包成镜像,目的是实现集群的快速部署和升级。
2.2Master
为了能够实现自动加载,k8s集群核心组件使用了StaticPod方式。
在自动修复方面,kubeletprobe 可以实现 Pod 的自检,配置了自动重启。
如果需要对核心组件进行升级,指定统一镜像的版本号即可实现核心组件升级更新。
controllermanager和scheduler服务在三台物理机实现集群master高可用。
APIServer 的高可用既可以通过负载均衡方式实现,也能通过 DNS 方式实现。
集群 controllermananger重启可能会出现 Node 状态不同步的问题,因此对于核心组件状态,需要配置告警并及时检查有无异常状态。
2.3minion
硬件方面并没有固定的配置,尽量利用现有的资源。
在我们的集群中,常见 minion 的配置是 24核CPU(withht)、128GB内存以及千兆网卡。
k8s集群中minion作为计算节点,其上主要是各种业务的容器和Systempods。
对于minion节点做了三个方面参数的优化,中断相关、TCPbacklog和swap。
minion节点操作系统使用的是centos7,dockerstorage使用的devicemapperdriver,日志基本写到外挂的EmptyDirvolume,docker存储使用得很少。
我们为 EmptyDirVolume 专门开辟了普通分区,没有使用 lvm,因为日志量不好预估,遭遇过因为 lvmmetadata 的事故。
使用 DeviceMapper 还遭遇过 kernelissue,因此需要更新内核。
默认内核是3.10版本,长期维护的内核版本的是我们需要的。
而且考虑到要对某些内核模块做 hacking,4.0及以上变化较大,hackingtcp_v4_syn_recv_sock存在问题,所以我们最终选择了自行编译 3.16内核。
考虑到和 CMDB 的结合,minion节点打上了 Label,例如标记它的功能是什么,物理位置信息,机柜等。
这些信息对于 Pod 调度非常重要。
包括 Pod 的 Node 亲和性,Pod 亲和性和反亲和性。
3、容器网络
容器网络的方面我们采用的是calico的方案。
主机通过BGP直接和核心路由设备对接,这里也可以用RouteReflector替代。
控制层面走BGP,数据层面走三层路由。
网络封包会经过主机的 netfilter框架,最后经由主机 forwardchain进入容器,默认都会被 conntrack。
部署方面,Calico 通过k8s的Daemonset方式,部署非常方便
优化主要是针对conntrack,建议尽量使用 headlessservice,少产生 iptablesrule。
同时,对conntrack用量进行监控。
容错方面,容器会主动去 ping 交换机,确保网络的连通性。
当calico出现问题的时候,容器是不会加入服务的,由此来保证服务的可靠性。
对于我们系统,绝大部分流量来自外部LVS,其可信任度高,默认的方式会产生大量的conntrack记录,所以应当把 LVS过来的流量直接给 bypassconntrack。
经过生产实践效果验证,nomesh模式的稳定性要优于 mesh 模式。
异常处理主要分为POD 主动检测网络和calico的整体健康监控告警。
4、外部访问4/7层负载均衡
我们做的是对外服务,大部分流量都是从外部打进来的,终端用户都是外部的客户,所以针对外部的访问做了4层和7层的负载均衡。
我们做的是对外服务,大部分流量都是从外部打进来的,终端用户都是外部的客户,所以针对外部的访问做了4层和7层的负载均衡。
4.14层负载均衡
在4层接入上采用了是阿里开源的 FullnatLVS方案,看中了它运维方便、水平扩展性好。
工作在4层的LVS服务既可以支持TCP同时也支持 UDP,流量从client端经过LVS做 Fullnat 后到达minion,应答直接路由回对应的LVS。
对于4层负载均衡的配置,是通过自动化方式来实现的,无需人工配置,可以自动在路由设备宣告 vip,并生成对应的 ECMP 路由。
LVS的 VirtualServer 配置也是自动生成的,VirtualServer 到 EndPointip 的自动映射。
我们对 LVS 控制程序做了改造,暴露了一些指标,包括网络和应用服务相关的数据,并以此实现了 Grafana 可视化和监控告警。
一方面是对LVS整体流量异常告警,另一方面realserver(Pod)做高延迟异常检测告警。
4.27层负载均衡
七层负载均衡采用的是POD里面跑nginx+ingresscontroller,它的定位是业务专属的反向代理,能够实现自动扩缩容,面向的 upstream 主要是 Jetty 业务容器。
由于四层负载均衡采用的是FullnatLVS,真正的终端ip地址已经被隐藏起来了,需要从TCPoption中获取。
realserver默认取到的是LVS的localip地址,需要使用TOA模块来获取终端ip。
开源版本的 TOA 一直没有升级,为此我们将其移植到 3.16,对于大多数业务来说,客户端 ip 地址是不可或缺的。
在把nginx容器化之后,踩了一些坑,其中一个是延迟过高。
从access.log看,upstream的RT时间长达几秒,而直接访问upstreamPod服务又是很快的,说明是nginx的问题。
经分析后发现配置不合理,nginx容器化之后缺少对worker数量和亲和性的优化。
按照默认配置,一台24核CPU的机器上,对于一个业务的 nginx,自动配置为 24个 worker 进程,而 cpulimit 往往只设置成 5、6个核,worker 没有 cpu 资源导致高延迟。
同时,调整worker 进程的亲和性,防止压力堆积在前几个核上。
Nginx动态缩容需考虑柔性,比如某业务原来有3个Nginx容器,现在要缩成2个,被停掉这个Nginx容器需要做一些优雅退出的准备工作,否则可能导致服务整体响应延迟陡增。
这个POD一开始就从LB上被摘掉了,我们利用Pod的prestophook,等待并优雅退出。
扩容时,需要考虑启动时间和热身问题。
有的业务可能需要几秒或几十秒,要有充足的初始化时间,否则,请求过去就会失败。
如果 ProbeTimeout 设置得比较小,会导致 Pod 被强制重启或者摘除,导致整体服务的雪崩。
在实际运行过程中,应根据监控情况对 CPUrequest 和 Hpa 配置持续优化。
5、监控/告警/日志
监控采用的是prometheus,开箱即用的整体方案。
部署方面是在k8s上部署成 Daemonsets 或者 Deployment,针对其特点会调度到特定的机型,通过类型拆分成几种map来方便管理。
监控指标包括两个方面,一个是硬指标,例如,从nginx获取当前业务的qps、httpcode分布、当前整个业务的资源消耗情况以及后端的jetty消耗情况。
另一方面是业务的软指标,指的是内部指标,主要包括jvm的指标,内部的logger相关,如 error 计数器。
日志的处理是收集到elasticsearch处理的。
ES的部署和prometheus类似也是POD的方式。
部署ES的datanode、master和client需要关注线程数据和CPUlimit的匹配问题。
日志收集容器试过使用 fluentd进行收集,与业务容器共享一个存储,发现有日志滞后和资源消耗高的问题。
用filebeat容器替代fluentd之后,资源占用率很小,消耗不到0.1核、内存不到 100M 就可以实现比较好的日志传输效果。
6、业务发布/镜像/多机房
业务发布考虑到效率和交互性,需要给用户提供一个交互界面,能够生成 k8s的资源描述文件,并能执行具体的 Action,如创建/更新/删除。
实现上是通过 jsonschema的方式来描述所有参数,默认值+结合用户输入最终生成 k8s 的资源描述文件。
利用ansible调用kubectl来实现自动化部署。
实现了部署进度,发布历史管理,模板化部署。
对于多集群管理,ansible通过切换不同 k8s 集群的 context,发布业务到不同机房。
对于镜像的选择我们的原则就是够小、够用,为了保证兼容性我们加入glibc支持。
Docker其实推荐只跑一个进程,但很多业务都是需要多个进程配合的,S6用于应对这种场景,作为进程和服务的管理器来实现一些比较复杂的功能。
总的来说,这是一套低成本的私有云实现方案,核心部分持续享受到 k8s 的红利,可以集中力量解决 4/7 层负载均衡及一些非功能性问题。
同时,利用k8s核心系统的能力,快速构建外部支撑系统,如监控、告警、日志、发布系统等,在很大程度上提高了效率和可维护性。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 基于 k8s 容器 平台 实践
![提示](https://static.bdocx.com/images/bang_tan.gif)