运维就是要无所不懂,无所不知。
大家好,我是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
后问题,除了上面这些,又增加了:
k8s
安全
如果k8s
使用的是托管,那么所有的数据经过 apiserver
时,均会被记录。apiserver
需被重点保护,或者所有数据流经过类似 kms
加密后使用。但同步会增加业务的开发成本和使用习惯Dockerfile
或者 docker commit
等如果流程不规范,存在较大**"内鬼"**安全隐患。如上。
解决方案如下,但不一定每家公司都有能力落地,或者有能力实施:
k8s RBAC权限管理
k8s阿里云审记
数据加密传输
主要的坑有如下:
namespace
过多,管理混乱namespace
命名混乱,无法辨识yaml
命名混乱,存放混乱对应的方案如下文
pod
数量做规划pod
映射出来/naspath/[data|log|config|sharedata]/namespace/NodeName_PODName/
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
管理资源限制
常见的坑:
对应的解决方案:
FROM python:3.6.12-slim
LABEL maintainer="mail.com"
LABEL project="project-name"
ENV MODULE_NAME="orangutan.server"
# copy contents of project into docker
COPY ./code/ /app/
WORKDIR /app
RUN pip install --upgrade pip \
&& pip install poetry \
&& poetry config virtualenvs.create false \
&& poetry install
COPY ./sources.list /etc/apt/
#RUN mv /var/lib/dpkg/info /var/lib/dpkg/info_bak \
RUN rm -rf /var/lib/dpkg/info \
# && mkdir /var/lib/dpkg/info/ \
&& mkdir -p /var/lib/dpkg/info \
&& apt-get update \
&& apt-get -f install \
&& apt-get update \
&& apt-get install -y dialog \
&& apt-get install -y libreoffice xfonts-wqy \
&& apt-get clean
CMD ["uvicorn", "main:contract", "--host", "0.0.0.0", "--port", "80"]
常见的坑:
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存储。
无影响。具体请参考我以前写的这篇文章
肯定有朋友会问,我们什么时候使用 lstio 或 serverless 的更高级方案。
目前来看,k8s 的容器化技术满足了我们现有的需要。云原生或者网络服务,我们会去技术尝鲜,有需求会考虑。
好了,扯了这么多,终于可以扯回到题目了。大白话告诉你到底用不用学习这该死的k8s容器化?
真的是灵魂三问啊!
我写过的文章里,已经重复讲过很多次。
K8s 不是一个开源软件,而是提供整套的运维架构方案解决。即k8s的角色其实是运维架构师。你懂了吗?
那么什么时候用的到架构呢?架构是个很大的词。这也意味着,小规模的应用,基本可以考虑使用k8s
。但如果公司技术文化很前沿,那是一次使用k8s
的良机,值得把握。
但如果公司比较传统,业务排期很紧张,又没有自上而下的资源支持。不建议单个部门独挑大梁,k8s
改变的不仅仅是运维的运维习惯,开发,测试,工具等等,所有的技术部门任何一个部门出差,你都会死的很难堪。希望我讲明白了。
不跟风,不排斥。
最近阿里拆中台的事情,恐怕你也是知道的。一台鸡毛阿里最多难受下,小公司可能命就没了。
这个问题其实挺难回答的。
用老话讲,真的是 “难者不会,会者不难”。但平心而论,我确实放弃过挺多次。。。但过了那道门槛,后面会发现。k8s
实在太厉害了。
人体的本能就是喜欢舒适区,本能会排斥新事物。但请听我一句建议:既然选择了远方,便只顾风雨兼程。你还记得来时的路吗?
不要再骗自己了。最大的不变就是拥抱变化。
运维行业的未来只有行业专家岗和技术专家岗。单纯的业务岗只会慢慢轮为职能操作岗。至于管理岗,价值会越来越依赖公司的规模,纯管理的中低层会越来越难。这次疫情只是提前映射了未来的行情状况,看看你身边的那些失业的朋友,你会明白一点点。
K8s 是一款伟大的产品,尽情去拥抱他吧!
参考: https://www.liukui.tech/2019/01/15/Kubernetes-Promethues%E7%9B%91%E6%8E%A7/ 《容器安全最佳实践》 感谢 google 的 k8s 工程师