大家好,我们使用k8s已经有一段时间了,早些时间这篇文章的思想和技巧在使用的过程中也逐步被深度验证,主要是经验和坑,包括团队协作、技术落地、公有云的坑,自动化工具、CICD先后等。我觉得有必要更新2.0版本。
变更的地方,我使用的红字标识,约2000字,主要集中在文章偏后面的部分。敬请审阅
目录
大家好,我是stanley「史丹利」。今天大家分享最近集团 AllIn容器化
的工作心得。我的分享目录列表如文章开头。
虽然大家都是技术出身,但我依然会用尽可能用大白话来描述 k8s
和容器化,尽可能不带代码。因为在上云的过程中,我发现,即使是有技术背景的同学,也并非所有人能很好的掌握 k8s
和容器化。
个人其实接受容器化的时间算比较早的。大概2014年就已经接触,并有心在公司业务中实践。
工作时间比较长的朋友可能知道,那个时间节点,商业公司EXSI
早已经一统江湖,一家独大。而开源界的 KVM
和 XEN
的半虚拟化之争刚刚结束,做为 REDHAT
亲儿子的 KVM
也逐渐独步青云。在开源领域独领风骚。
XEN
终究成为历史,成为过往,虽然生的早,但亲爹不行,又没有干爹,只能暗然退场。从此,江湖再无XEN
的身影。
彼时,docker
还是一个小啰啰,还在为活着而战,每天都是生死一线。彼时 docker
还不叫 moby
docker项目改名为moby。
我当时供职的公司也不例外,使用 KVM
管理着公司的所有应用和服务。就着对新技术的尝试,我**“大「盲」胆「目」”** 的将 KVM
的技术栈全线改为 Docker
,但仅仅一周不到,就发现严重的问题,发现团队人员的技术储备远远不够,且 Docker
当时还有诸多问题,其次该技术栈仅运维单团队模块掌握还远远不够。必须是自上而下的贯彻实施,才有可能完成。
考量再三,当时立刻下架所有容器化技术。转回 KVM
技术栈。现在想想,当时真的是 Too Young Too Simple
.
再之后大概有4年没有再接触 Docker
技术。一方面是创业项目和 Docker
无关,再者是后来供职的公司或是创业阶段不合适,或是对新技术比较排斥。
时间一晃,2019年底,我们有幸再次接触容器化技术。期间因为集团高层的频繁变动,容器化规划也一再被搁浅,个人因为一些原因也有离开的想法。幸运的是,2020年中,ALLIN
的技术战略终于被抬上桌面,且作为集团层面技术战略执行。每个团队都有容器化 KPI
考核。
这简直就是 冷宫坐尽,柳暗花明 ,机会不一定是争取来的,也可能是等出来的。真的是剩者为王呀!
随后就是为期不到2个月的紧张筹备。而此时,我们还有很多东西没有开始:
其中,第5条最为致命,因为需要和时间赛跑。k8s的技术人员,也就我和另外一个技术同学,且经验都严重欠缺。
但容器化这样的天时、地利、人和的机会,错过就不可能再有第二次,所以大家都很拼。
这当然少不了,上层老板的资源倾斜,以及团队内其它同学主动承担日常工作,还有其它团队同学的大力支持和大开便利之门。才得以让整个项目在最后一刻压点上线。
好的,到此,感谢大家听完我唠叨完背景。下面为大家介绍技术性内容,可能比较枯燥,但请谅解且相信,我已经努力大白化了。
前面有提到,因为高层的频繁变动。所以技术战略一直在变,上云,下云,再上云,再下云。。。。。
不要以为这是故事,如果是故事,也是真的故事。。。就发生在我们身上。
在 ALLIN
容器化的前一刻,我们的部分业务正在筹备下云。。。其它业务也像待宰的羔羊,怒气值爆满,但也只能是被屠宰的命。所以,我们架构比较乱。希望,你能懂。。我梳理了上云前部分业务的架构。是如下这样的:
上云前架构简图2
大致提几点:
作为第一批容器化的项目,我们挑选的标准也比较简单:
容器化后,我们的规划的初期架构如下:
上云后架构
提炼几个关键点:
k8s
的svc
使用 clusterip
的模式, cluster
使用 阿里云自有的 SLB
分流并实现全模块高可用。具体上云过程太过细节,这里不一一介绍,必然是问题多多,但总体比我们想像的要容易且顺利。这里分享一些实践经验。
大家知道,k8s
提供的是解决方案,而且是各个技术细分领域的成套解决方案,比如:存储解决方案,日志收集解决方案,高可用解决方案,分布式解决方案、CICD解决方案、横纵向解决方案等等。
这意味着,你单纯对k8s
技术掌握的深浅只能决定你的熟练程度,而并非架构和项目解决能力。也意味着,除非从物理硬件、到系统底层、到网络架构、到 AP
应用、到 HA
,HP
你都有实践应用,才能在一时间做出正确的决策。
这也意味着,第一次容器化上云,如果没有额外的技术支持。很容易踩坑。
我们第一期容器化规划了11个项目。这次还是有一些内容可以和大家分享下,主从从如下几个方面。
下面一一为大家介绍
容器化之前,进程通信主要有:
安全主要关注:
IDC
环境及流量安全等使用K8S
后,因为 IP
不固定,安全的管控带来了一些不便利。但对于非金融行业的传统互联网公司,如果不需要精细管控进出口流量,其实容器化,还是提供了很好的便利。如针对 apiserver
的安全攻击
apiserver的安全攻击
改用 k8s
后问题,除了上面这些,又增加了:
//针对所有数据做加密处理,仔细核算elk+kafka和sls的成本比对年,选择使用SLS作为BI数据分析和日志展示入口 。OSS代替自建机房的NAS和磁带。
成本核算详况如下:
方案架构图如下:
针对SLS和OSS使用下来的坑有:
当然了,这些问题,阿里云在9月份会有sls冷冻方案代替。可以期待
如果业务原来点对点开放权限,或白名单,业务改造成本不小
k8s
安全
如果k8s
使用的是托管,那么所有的数据经过 apiserver
时,均会被记录。apiserver
需被重点保护,或者所有数据流经过类似 kms
加密后使用。但同步会增加业务的开发成本和使用习惯Dockerfile
或者 docker commit
等如果流程不规范,存在较大"内鬼"安全隐患。目前多为业务运维自治。核心攻尖人员做不同类型的基础镜像,做好模板后,其它业务参考套用。
如上。
解决方案如下,但不一定每家公司都有能力落地,或者有能力实施:
k8s RBAC权限管理
但阿里云或公有云可能都存在的问题是:一条数据链路不同即进又出ingress或slb. 会被视为非法流量被丢弃。这个问题很难发现,且避开也有一定团队管理难度。
k8s阿里云审记
数据加密传输
主要的坑有如下:
namespace
过多,管理混乱namespace
命名混乱,无法辨识yaml
命名混乱,存放混乱对应的方案如下文
pod
数量做规划//实际执行起来仍然有难度,最终落地到平台化才是银弹。
// yaml存放也始终没有得到很好的解决,每个人风格习惯不同。自研运维平台不成熟的话,因为只能管理部分yaml,所以只会导致yaml管理更难。命名和目录名,及模板有变更需要整体变更的时候,会暴露出很多问题。我们遇到的问题:
pod
映射出来/naspath/[data|log|config|sharedata]/namespace/NodeName_PODName/
//实际执行遇到问题会有:
1. sls的CRD并不如预期简单,经常会因和deploy.yaml配合不够,很难排查到日志录入失败的原因
2. 多pod,需要开发改代码日志输出方式,成本巨大。后来只能妥协,本地不再映射nfs,仅pod临时保存日志。缺点很明显
nodeport
,防止端口冲突/usr/local/k8s/projectName/{00-namespace.yaml,01-pv.yaml,02-pvc.yaml,03-svc.yaml,04-configmap.yaml,05-deployment.yaml,06-ingress.yaml}
yaml
需统一 gitlab
管理//前期实际执行过程做的并不好,后期强制统一模板后,有所改善。
资源限制
//实际执行过程中并不复杂,甚至已经完全忽略大小的问题,可用安全即可,原因有如下:
常见的坑:
对应的解决方案:
常见的坑:
Dockerfile
CICD
平台无法使用对应的解决方案:
Dockerfile
,后期开发写,运维优化审核CICD
。CICD方案
常见的坑:
zabbix
或cat
需改造升级,新旧平台迁移难度大解决方案
Triger
失效没有捷径, 只能重建k8s的prometheus解决方案
k8s
支持的存储类型非常多,几乎覆盖市面常见存储类型:awsElasticBlockStore,CephFS, EBS,azureDisk,cephfs,emptyDir,configmap等等,这里不赘述,详见官方。
使用哪种,具体参考业务类型,以阿里云为例,我们通常使用3种方案结合:
主要针对分布式存储场景的业务。比如日志,配置文件(阿里的技术工程师建议直接打到pod里面),svn, gitlab, db的数据存放。等对分布式数据有要求的业务场景。
优点:简单好用。横向、纵向几乎无限扩展。数据管理极为方便
缺点:稍贵,但可接入
建议:大部分场景直接使用NAS。
原来打算使用高效云盘,后来仔细盘算后,结合考虑人员技术门槛,数据存放规范等等场景,维护成本太大,且成本和NAS
相比,可接受。所以没有使用高效云盘,all in NAS
优缺点:自己体会
Anyshare
是老旧业务使用的华为一款共享存储方案。后面会逐步使用 NAS
或 OSS
代替
阿里云技术工程师力荐的日志及数据收集工具。
早期的日志解决方案是:app -> SLS -> 时序数据库 -> ELK 和 OSS
但考虑到金融行业的日志数据太重要,纯数据流的收集方式不安全。所以PASS了。使用了 数据流 + 本地双重写的方式
阿里推荐的sls日志收集架构
因为涉及到的改造太大,同时因为单纯的流日志处理有日志丢失的隐患。所以我们优化了日志收集架构,使用的是张磊推荐的日志收集方案。
张磊推荐的日志收集方案
而且,在其方案的基础上。我们对存储方式做了进一步优化,使用分布式NAS存储。
//到目前为止,sls的体验非常不错,基于sls我们还做的日志增量和大小的同环比告警。而我们本地的日志系统,想完成这样的事情,几乎不可能。唯一的难点是,需要抚平开发使用sls的习惯问题。
无影响。具体请参考我以前写的这篇文章
肯定有朋友会问,我们什么时候使用 lstio 或 serverless 的更高级方案。
目前来看,k8s 的容器化技术满足了我们现有的需要。云原生或者网络服务,我们会去技术尝鲜,有需求会考虑。
好了,扯了这么多,终于可以扯回到题目了。大白话告诉你到底用不用学习这该死的k8s容器化?
真的是灵魂三问啊!
我写过的文章里,已经重复讲过很多次。
K8s 不是一个开源软件,而是提供整套的运维架构方案解决。即k8s的角色其实是运维架构师。你懂了吗?
那么什么时候用的到架构呢?架构是个很大的词。这也意味着,小规模的应用,基本可以考虑使用k8s
。但如果公司技术文化很前沿,那是一次使用k8s
的良机,值得把握。
但如果公司比较传统,业务排期很紧张,又没有自上而下的资源支持。不建议单个部门独挑大梁,k8s
改变的不仅仅是运维的运维习惯,开发,测试,工具等等,所有的技术部门任何一个部门出差,你都会死的很难堪。希望我讲明白了。
不跟风,不排斥。
最近阿里拆中台的事情,恐怕你也是知道的。一台鸡毛阿里最多难受下,小公司可能命就没了。
这个问题其实挺难回答的。
用老话讲,真的是 “难者不会,会者不难”。但平心而论,我确实放弃过挺多次。。。但过了那道门槛,后面会发现。k8s
实在太厉害了。
人体的本能就是喜欢舒适区,本能会排斥新事物。但请听我一句建议:既然选择了远方,便只顾风雨兼程。你还记得来时的路吗?
不要再骗自己了。最大的不变就是拥抱变化。
运维行业的未来只有行业专家岗和技术专家岗。单纯的业务岗只会慢慢轮为职能操作岗。至于管理岗,价值会越来越依赖公司的规模,纯管理的中低层会越来越难。这次疫情只是提前映射了未来的行情状况,看看你身边的那些失业的朋友,你会明白一点点。
说到这里,我给大家整理了一些学习资料,其中涵盖面试题、公开课视频、电子书等等,全都可以免费领取。具体如下:
大咖公开课视频
技术大咖为你详解云原生趋势,并带你全面理解云原生技术体系。
云原生电子迷你书
大厂面试题汇总附详细解析(以下为部分题目)
面试题除了面试时用,还可以带你了解大厂会关注工程师哪些技术点,为你提供一个学习的方向。
1. Kubernetes 常见面试题汇总
2. DevOps & CI/CD 常见面试题汇总
3. Docker 常见面试题汇总