大白话告诉你到底用不用学习这该死的Kubernetes容器化


运维就是要无所不懂,无所不知。

今天分享最近集团 All In 容器化 的工作心得。

虽然大家都是技术出身,但我依然会用尽可能用大白话来描述 Kubernetes 和容器化,尽可能不带代码。因为在上云的过程中,我发现,即使是有技术背景的同学,也并非所有人能很好的掌握 Kubernetes 和容器化。

容器化背景介绍

初识 Docker

个人其实接受容器化的时间算比较早的。大概 2014 年就已经接触,并有心在公司业务中实践。

工作时间比较长的朋友可能知道,那个时间节点,商业公司 EXSI 早已经一统江湖,一家独大。而开源界的 KVMXEN 的半虚拟化之争刚刚结束,做为 RedHat 亲儿子的 KVM 也逐渐独步青云。在开源领域独领风骚。

XEN 终究成为历史,成为过往,虽然生的早,但亲爹不行,又没有干爹,只能暗然退场。从此,江湖再无 XEN 的身影。

彼时,Docker 还是一个小啰啰,还在为活着而战,每天都是生死一线。彼时 Docker 还不叫 Moby(Docker 项目改名为 Moby)。

我当时供职的公司也不例外,使用 KVM 管理着公司的所有应用和服务。就着对新技术的尝试,我“大「盲」胆「目」”的将 KVM 的技术栈全线改为 Docker,但仅仅一周不到,就发现严重的问题,发现团队人员的技术储备远远不够, Docker 当时还有诸多问题,其次该技术栈仅运维单团队模块掌握还远远不够。必须是自上而下的贯彻实施,才有可能完成。

考量再三,当时立刻下架所有容器化技术。转回 KVM 技术栈。现在想想,当时真的是 Too Young Too Simple

再识 Docker

再之后大概有 4 年没有再接触 Docker 技术。一方面是创业项目和 Docker 无关,再者是后来供职的公司或是创业阶段不合适,或是对新技术比较排斥。

时间一晃,2019 年底,我们有幸再次接触容器化技术。期间因为集团高层的频繁变动,容器化规划也一再被搁浅,个人因为一些原因也有离开的想法。幸运的是,2020 年中,ALL IN 的技术战略终于被抬上桌面,且作为集团层面技术战略执行。每个团队都有容器化 KPI 考核。

这简直就是冷宫坐尽,柳暗花明 ,机会不一定是争取来的,也可能是等出来的。真的是剩者为王呀!

随后就是为期不到 2 个月的紧张筹备。而此时,我们还有很多东西没有开始:
  1. 云平台选型
  2. 架构迁移方案
  3. 网络及混合云共存方案
  4. 零 Kubernetes 线上经验
  5. 技术及人员储备严重不足


其中,第 5 条最为致命,因为需要和时间赛跑。Kubernetes 的技术人员,也就我和另外一个技术同学,且经验都严重欠缺。

但容器化这样的天时、地利、人和的机会,错过就不可能再有第二次,所以大家都很拼。

这当然少不了,上层老板的资源倾斜,以及团队内其它同学主动承担日常工作,还有其它团队同学的大力支持和大开便利之门。才得以让整个项目在最后一刻压点上线。

好的,到此,感谢大家听完我唠叨完背景。下面为大家介绍技术性内容,可能比较枯燥,但请谅解且相信,我已经努力大白化了。

公司现有架构和上云后的架构

前面有提到,因为高层的频繁变动。所以技术战略一直在变,上云,下云,再上云,再下云……

不要以为这是故事,如果是故事,也是真的故事……就发生在我们身上。

ALL IN 容器化的前一刻,我们的部分业务正在筹备下云……其它业务也像待宰的羔羊,怒气值爆满,但也只能是被屠宰的命。所以,我们架构比较乱。希望,你能懂……我梳理了上云前部分业务的架构。是如下这样的:
1.png

上云前架构简图 2

大致提几点:
  1. 混合云架构,专线打通
  2. 经过几轮调整后的中台战略,各业务之间的相互调用还相对规范了那么一点。
  3. 信安在金融行业的特殊地位,在公司有着“太子军”的特权。


作为第一批容器化的项目,我们挑选的标准也比较简单:
  1. 非核心业务系统
  2. 技术栈尽可能简单
  3. 新业务
  4. 业务尽可能有代表性,如:和周边接口有着丰富的调用关系


容器化后,我们的规划的初期架构如下:
2.png

上云后架构

提炼几个关键点:
  • 按功能分区
  • VPC,防火墙,Pod 不同级别的隔离均有
  • 上网需求和非上网需求没有使用 Proxy 的方式,而是使用 VPC 的方式隔离
  • Kubernetessvc 使用 ClusterIP 的模式,Cluster 使用阿里云自有的 SLB 分流并实现全模块高可用。


具体上云过程太过细节,这里不一一介绍,必然是问题多多,但总体比我们想像的要容易且顺利。这里分享一些实践经验。

经验分享

大家知道,Kubernetes 提供的是解决方案,而且是各个技术细分领域的成套解决方案,比如:存储解决方案,日志收集解决方案,高可用解决方案,分布式解决方案、CI/CD解决方案、横纵向解决方案等等。

这意味着,你单纯对 Kubernetes 技术掌握的深浅只能决定你的熟练程度,而并非架构和项目解决能力。也意味着,除非从物理硬件、到系统底层、到网络架构、到 AP 应用、到 HAHP 你都有实践应用,才能在一时间做出正确的决策。

这也意味着,第一次容器化上云,如果没有额外的技术支持。很容易踩坑。

我们第一期容器化规划了 11 个项目。这次还是有一些内容可以和大家分享下,主要从如下几个方面:
  • 安全经验分享
  • 规范经验分享
  • 网络经验分享
  • 镜像经验分享
  • 流程经验分享
  • 监控经验分享
  • 存储经验分享


下面一一为大家介绍。

安全经验分享

容器化之前,进程通信主要有:
  • 跨主机网络通信
  • 同主机进程间通信


安全主要关注:
  • 代码安全规范
  • 开源软件网络高危漏洞
  • 防止内鬼
  • IDC 环境及流量安全等


使用 Kubernetes 后,因为 IP 不固定,安全的管控带来了一些不便利。但对于非金融行业的传统互联网公司,如果不需要精细管控进出口流量,其实容器化,还是提供了很好的便利。如针对 apiserver 的安全攻击。
3.png

apiserver 的安全攻击

改用 Kubernetes 后,问题除了上面这些,又增加了:
  • 数据落地,数据是金融公司的命脉,落地到阿里云的存储上,公司并不放心,或者并不符合安全规范。
  • 安全最小化原则,原来的网络权限最小化原则端到端并不适用,现在需要段到段。
  • Kubernetes 安全,如果 Kubernetes 使用的是托管,那么所有的数据经过 apiserver 时,均会被记录。apiserver 需被重点保护,或者所有数据流经过类似 kms 加密后使用。但同步会增加业务的开发成本和使用习惯。
  • 镜像安全,安全团队并不一定具备精深容器化能力。Dockerfile 或者 docker commit 等如果流程不规范,存在较大"内鬼"安全隐患。


如上。

解决方案如下,但不一定每家公司都有能力落地,或者有能力实施:

零信任管理
  • 零信任安全模型下没有绝对的安全域
  • 在暴露的服务前设置尽可能多的防护层,实现纵深防御
  • 权限配置和凭证下发遵循权限最小化原则
  • 最小化攻击面


精细管理访问控制
  • 在云资源控制平面,遵循权限最小化原则合理分配云账号的资源访问权限
  • 在Kubernetes集群数据平面,根据业务场景,通过 Namespace 实现人员/应用/部门之间的逻辑隔离
  • 使用 RBAC 进行资源模型维度的细粒度访问控制及时吊销或轮转可能泄露的访问凭证


4.png

Kubernetes RBAC 权限管理

Pod 通信网络管理

控制容器入网流量:
  1. 限定容器允许监听的指定协议,端口和服务标签等
  2. 限定除 LB 和 Ingress 关联的服务外不允许外网 IP 访问
  3. 限定容器只允许其服务消费者访问


控制容器出网流量:
  1. 禁止不需要访问公网的Pods出网流量


日志审记
  • 基础设施日志,云平台资源操作审计,云服务账号操作审计等;
  • Kubernetes 集群日志,集群 control-plane 组件日志,control-plane 组件审计日志(secrets 审计,apiserver 非法访问,exec 进入容器等操作审计);
  • 系统运维日志,主机层应用操作和运维审计;
  • 应用日志,容器内应用进程日志。


5.png

Kubernetes 阿里云审记

数据安全
  • 全链路传输加密,系统组件,服务之间的全链路数据传输加密,敏感数据落盘加密
  • 密钥管理:密钥的保护和轮转 DEK(数据加密密钥)和 KEK(密钥加密密钥)隔离


6.png

数据加密传输

规范经验分享

主要的坑有如下:
  1. namespace 过多,管理混乱
  2. namespace 命名混乱,无法辨识
  3. yaml 命名混乱,存放混乱
  4. 日志存储及收集优劣不清,无法选择最佳方案


对应的方案如下文:

namespace
  • 按系统 Pod 数量做规划
  • namespace 命名需流程规范化,运维有一票否决权
  • 命名需要有明确特征。如工作类(tools),存储类(store),数据库类(db)


存储
  • 日志存放必须Pod 映射出来
  • 日志禁止打印标准输出
  • 日志建议存储两类:本地 + 网络(sidecar+ELK)
  • 日志统一存放目录摆放规范:/naspath/[data|log|config|sharedata]/namespace/NodeName_PODName/


yaml
  • 禁止手动映射 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 管理


7.png

资源限制

镜像经验分享

常见的坑:
  • 权限太大,任何人可推送
  • 不做定期清理,导致仓库太大,存储压力过大
  • 镜像命名规范不成熟
  • 镜像层数过多
  • 镜像过大


对应的解决方案:
  • 各系统服务镜像统一存放在集团镜像仓库中
  • 如需要开通权限可联系应用运维负责人
  • 镜像的命名规则如下:harbor.company.com/项目名称/服务名称
  • 强制定期清理
  • 使用轻量化的基础镜像,e.g. distroless镜像
  • 不要构建过大或层数过多的镜像
  • 删除基础镜像中的包管理或网络工具
  • 删除文件属性修改工具(chmod,chown)
  • 不要轻易部署公共仓库的镜像
  • 不要使用 root 用户启动镜像
  • 可以使用 Ephemeral 临时容器 debug(Alpha as of 1.16)
  • 伪代码如下:


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
  • CI/CD平台无法使用


对应的解决方案:
  • 事先规划项目,引入 PM 管理制度,每日站会。实时同步问题及进度
  • 自上而下引入容器化技术,争取足够资源
  • 事先提供成熟可靠的容器化环境,供开发使用。
  • 事先约定好各方职责及工作内容。普及容器化基础和运营理念
  • 前期运维和开发共同编写 Dockerfile,后期开发写,运维优化审核
  • 考虑到时间和技术成本,前期不建议纯自研的 CI/CD


8.png

CI、CD方案

监控经验分享

常见的坑:
  • 原有的方案 ZabbixCAT需改造升级,新旧平台迁移难度大
  • 原有短信、微信、电话告警接入全作废


解决方案:
  • 新旧环境分离,网络互通,逐步迁移
  • 尽可能使用云平台成套解决方案,退而求其次方案:Grafana + Prometheus + cAdvisor + Datadog(暂时未接入)
  • Triger 失效没有捷径, 只能重建


9.jpg

Kubernetes 的 Prometheus 解决方案

存储经验分享

Kubernetes 支持的存储类型非常多,几乎覆盖市面常见存储类型:awsElasticBlockStore,CephFS, EBS,azureDisk,emptyDir,ConfigMap 等等,这里不赘述,详见官方。

使用哪种,具体参考业务类型,以阿里云为例,我们通常使用 3 种方案结合:

NAS

主要针对分布式存储场景的业务。比如日志,配置文件(阿里的技术工程师建议直接打到 Pod 里面),SVN,GitLab,db 的数据存放。等对分布式数据有要求的业务场景。

优点:简单好用。横向、纵向几乎无限扩展。数据管理极为方便

缺点:稍贵,但可接入

建议:大部分场景直接使用NAS。

高效云盘

原来打算使用高效云盘,后来仔细盘算后,结合考虑人员技术门槛,数据存放规范等等场景,维护成本太大,且成本和 NAS 相比,可接受。所以没有使用高效云盘,all in NAS

优缺点:自己体会

Anyshare

Anyshare 是老旧业务使用的华为一款共享存储方案。后面会逐步使用 NASOSS 代替。

OSS

阿里云技术工程师力荐的日志及数据收集工具。

早期的日志解决方案是:app -> SLS -> 时序数据库 -> ELK 和 OSS

但考虑到金融行业的日志数据太重要,纯数据流的收集方式不安全。所以 PASS 了。使用了数据流 + 本地双重写的方式。
10.png

阿里推荐的 sls 日志收集架构

因为涉及到的改造太大,同时因为单纯的流日志处理有日志丢失的隐患。所以我们优化了日志收集架构,使用的是张磊推荐的日志收集方案。
11.jpg

张磊推荐的日志收集方案

而且,在其方案的基础上。我们对存储方式做了进一步优化,使用分布式 NAS 存储。

未来

肯定有朋友会问,我们什么时候使用 lstio 或 Serverless 的更高级方案。

目前来看,Kubernetes 的容器化技术满足了我们现有的需要。云原生或者网络服务,我们会去技术尝鲜,有需求会考虑。

其它更重要的一些人生建议

好了,扯了这么多,终于可以扯回到题目了。大白话告诉你到底用不用学习这该死的 Kubernetes 容器化?
  • Kubernetes 什么时候合适使用?
  • Kubernetes 到底难不难?
  • Kubernetes 到底用不用学?


真的是灵魂三问啊!

Kubernetes 什么时候合适使用?

我写过的文章里,已经重复讲过很多次。

Kubernetes 不是一个开源软件,而是提供整套的运维架构方案解决。即 Kubernetes 的角色其实是运维架构师。你懂了吗?

那么什么时候用的到架构呢?架构是个很大的词。这也意味着,小规模的应用,基本可以考虑使用 Kubernetes。但如果公司技术文化很前沿,那是一次使用 Kubernetes 的良机,值得把握。

但如果公司比较传统,业务排期很紧张,又没有自上而下的资源支持。不建议单个部门独挑大梁,Kubernetes 改变的不仅仅是运维的运维习惯,开发,测试,工具等等,所有的技术部门任何一个部门出差错,你都会死的很难堪。希望我讲明白了。

不跟风,不排斥。

最近阿里拆中台的事情,恐怕你也是知道的。一台鸡毛阿里最多难受下,小公司可能命就没了。

Kubernetes 到底难不难?

这个问题其实挺难回答的。

用老话讲,真的是“难者不会,会者不难”。但平心而论,我确实放弃过挺多次……但过了那道门槛,后面会发现。Kubernetes 实在太厉害了。

人体的本能就是喜欢舒适区,本能会排斥新事物。但请听我一句建议:既然选择了远方,便只顾风雨兼程。你还记得来时的路吗?

Kubernetes 到底用不用学?

不要再骗自己了。最大的不变就是拥抱变化。

运维行业的未来只有行业专家岗和技术专家岗。单纯的业务岗只会慢慢轮为职能操作岗。至于管理岗,价值会越来越依赖公司的规模,纯管理的中低层会越来越难。这次疫情只是提前映射了未来的行情状况,看看你身边的那些失业的朋友,你会明白一点点。

Kubernetes 是一款伟大的产品,尽情去拥抱他吧!

参考:


原文链接:https://mp.weixin.qq.com/s/zArZJvbVeUhUayLbIDK9FA

0 个评论

要回复文章请先登录注册