大白话告诉你到底用不用学习这该死的k8s容器化【V2】

‍大家好，我们使用k8s已经有一段时间了，早些时间这篇文章的思想和技巧在使用的过程中也逐步被深度验证，主要是经验和坑，包括团队协作、技术落地、公有云的坑，自动化工具、CICD先后等。我觉得有必要更新2.0版本。

变更的地方，我使用的红字标识，约2000字，主要集中在文章偏后面的部分。敬请审阅

目录

• 1.1、 初识 Docker
• 1.2、 再识 Docker
• 3.1、 安全经验分享
  • 3.1.1、零信任管理
  • 3.1.2、精细管理访问控制
  • 3.1.3、 POD通信网络管理
  • 3.1.4、日志审记
  • 3.1.5、 数据安全
• 3.2、 规范经验分享
  • 3.2.1、 namespace
  • 3.2.2、 存储
  • 3.2.3、yaml
• 3.4、 镜像经验分享
• 3.5、 流程经验分享
• 3.5、 监控经验分享
• 3.7、 存储经验分享
• 6.1、 k8s 什么时候合适使用？
• 6.2、 K8s 到底难不难？
• 6.3、 K8s 到底用不用学？

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

大家好，我是stanley「史丹利」。今天大家分享最近集团 AllIn容器化 的工作心得。我的分享目录列表如文章开头。

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

1、 容器化背景介绍

1.1、 初识 Docker

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

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

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

彼时，docker 还是一个小啰啰，还在为活着而战，每天都是生死一线。彼时 docker 还不叫 moby docker项目改名为moby。

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

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

1.2、 再识 Docker

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

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

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

随后就是为期不到2个月的紧张筹备。而此时，我们还有很多东西没有开始：

1. 云平台选型
2. 架构迁移方案
3. 网络及混合云共存方案
4. 零k8s线上经验
5. 技术及人员储备严重不足

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

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

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

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

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

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

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

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

上云前架构简图2

大致提几点：

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

作为第一批容器化的项目，我们挑选的标准也比较简单：

1. 非核心业务系统
2. 技术栈尽可能简单
3. 新业务
4. 业务尽可能有代表性，如：和周边接口有着丰富的调用关系

容器化后，我们的规划的初期架构如下：

上云后架构

提炼几个关键点：

• 按功能分区
• VPC, 防火墙，POD 不同级别的隔离均有
• 上网需求和非上网需求没有使用proxy的方式，而是使用 vpc 的方式隔离
• k8s的svc 使用 clusterip 的模式, cluster 使用 阿里云自有的 SLB 分流并实现全模块高可用。

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

3、 经验分享

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

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

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

我们第一期容器化规划了11个项目。这次还是有一些内容可以和大家分享下，主从从如下几个方面。

• 安全经验分享
• 规范经验分享
• 网络经验分享
• 镜像经验分享
• 流程经验分享
• 监控经验分享
• 存储经验分享

下面一一为大家介绍

3.1、 安全经验分享

容器化之前，进程通信主要有：

• 跨主机网络通信
• 同主机进程间通信

安全主要关注：

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

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

apiserver的安全攻击

改用 k8s 后问题，除了上面这些，又增加了：

• 数据落地 数据是金融公司的命脉，落地到阿里云的存储上，公司并不放心。或者并不符合安全规范

//针对所有数据做加密处理，仔细核算elk+kafka和sls的成本比对年，选择使用SLS作为BI数据分析和日志展示入口 。OSS代替自建机房的NAS和磁带。

成本核算详况如下：

方案架构图如下：

针对SLS和OSS使用下来的坑有：

1. sls投递到oss非常不方便，尤其新业务要无缝投递日志时，难度谁用谁知道，碰上紧急项目，非常难受
2. 历史日志投递，默认无法获取sls生成有_meta表头，只能投递content字段。_meta需要针对logstore手动指定，无法自动化。
3. 历史日志投递会有成本 double的问题，或者自研脚本，使用Dataworks方式
4. 投递成功和失败，投递任务不会有监控和告警途径

当然了，这些问题，阿里云在9月份会有sls冷冻方案代替。可以期待

• 安全最小化原则 原来的网络权限最小化原则端到端并不适用，公有云把整体网络拉平后，pod和node,及slb共用一个网段和ip资源。最小化原则只能在api接口和RBAC做。

如果业务原来点对点开放权限，或白名单，业务改造成本不小

• k8s安全 如果k8s 使用的是托管，那么所有的数据经过 apiserver 时，均会被记录。apiserver 需被重点保护，或者所有数据流经过类似 kms 加密后使用。但同步会增加业务的开发成本和使用习惯
• 镜像安全 安全团队并不一定具备精深容器化能力。Dockerfile或者 docker commit 等如果流程不规范，存在较大"内鬼"安全隐患。

目前多为业务运维自治。核心攻尖人员做不同类型的基础镜像，做好模板后，其它业务参考套用。

如上。

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

3.1.1、零信任管理

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

3.1.2、精细管理访问控制

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

k8s RBAC权限管理

3.1.3、 POD通信网络管理

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

1. 禁止不需要访问公网的Pods出网流量

但阿里云或公有云可能都存在的问题是：一条数据链路不同即进又出ingress或slb. 会被视为非法流量被丢弃。这个问题很难发现，且避开也有一定团队管理难度。

3.1.4、日志审记

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

k8s阿里云审记

3.1.5、 数据安全

• 全链路传输加密 系统组件，服务之间的全链路数据传输加密，敏感数据落盘加密
• 密钥管理：密钥的保护和轮转 DEK（数据加密密钥）和KEK（密钥加密密钥）隔离

数据加密传输

3.2、 规范经验分享

主要的坑有如下：

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

对应的方案如下文

3.2.1、 namespace

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

//实际执行起来仍然有难度，最终落地到平台化才是银弹。

// yaml存放也始终没有得到很好的解决，每个人风格习惯不同。自研运维平台不成熟的话，因为只能管理部分yaml，所以只会导致yaml管理更难。命名和目录名，及模板有变更需要整体变更的时候，会暴露出很多问题。我们遇到的问题：

1. 批量替换模板导致出错；
2. base yaml和架构融合的过程中，需要频繁变更

3.2.2、 存储

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

//实际执行遇到问题会有：

1. sls的CRD并不如预期简单，经常会因和deploy.yaml配合不够，很难排查到日志录入失败的原因

2. 多pod，需要开发改代码日志输出方式，成本巨大。后来只能妥协，本地不再映射nfs，仅pod临时保存日志。缺点很明显

3.2.3、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 管理

//前期实际执行过程做的并不好，后期强制统一模板后，有所改善。

资源限制

3.4、 镜像经验分享

//实际执行过程中并不复杂，甚至已经完全忽略大小的问题，可用安全即可，原因有如下：

1. base镜像前期k8s过程中，时间和经验不足，能完成已经不错了，后期还有很多版本迭代，同步影响已经上线的base镜像。体验很差
2. 开发运维初期k8s的使用习惯变化 ，碰撞非常严重。经常需要在pod中排查问题。但最小化的pod压根没有类似telnet, ping,curl,dig工具。
3. 虽然可以使用 busyboxtool 等类似工具，但实际效果很差。因为不能证明业务pod没有问题...存在严重的信任危机

常见的坑：

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

对应的解决方案：

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

常见的坑：

• 为了进度牺牲流程和品控
• 代码开发不在容器中进行
• 开发不会写Dockerfile
• CICD平台无法使用

对应的解决方案：

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

CICD方案

3.5、 监控经验分享

常见的坑：

• 原有的方案zabbix或cat需改造升级，新旧平台迁移难度大
• 原有短信、微信、电话告警接入全作废

解决方案

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

k8s的prometheus解决方案

3.7、 存储经验分享

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

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

• NAS

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

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

缺点：稍贵，但可接入

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

• 高效云盘

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

优缺点：自己体会

• Anyshare

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

• OSS

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

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

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

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

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

张磊推荐的日志收集方案

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

//到目前为止，sls的体验非常不错，基于sls我们还做的日志增量和大小的同环比告警。而我们本地的日志系统，想完成这样的事情，几乎不可能。唯一的难点是，需要抚平开发使用sls的习惯问题。

4、 k8s不支持docker后对我们的影响

无影响。具体请参考我以前写的这篇文章

5、 未来

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

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

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

好了，扯了这么多，终于可以扯回到题目了。大白话告诉你到底用不用学习这该死的k8s容器化？

• k8s 什么时候合适使用？
• K8s 到底难不难？
• K8s 到底用不用学？

真的是灵魂三问啊！

6.1、 k8s 什么时候合适使用？

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

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

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

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

不跟风，不排斥。

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

6.2、 K8s 到底难不难？

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

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

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

6.3、 K8s 到底用不用学？

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

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

说到这里，我给大家整理了一些学习资料，其中涵盖面试题、公开课视频、电子书等等，全都可以免费领取。具体如下：

大咖公开课视频

技术大咖为你详解云原生趋势，并带你全面理解云原生技术体系。

• 《Kubernetes 为何成为大厂标配？》
• 《1小时带你全面理解云原生技术体系》
• 《如何构建“正确”的云平台存储系统？》
• 《未来架构之从 Service Mesh 迈向云原生》

云原生电子迷你书

• 云原生时代容器云的技术发展趋势报告
• 云原生应用的构建之路
• 云原生的技术探索与落地实践
• ……

大厂面试题汇总附详细解析（以下为部分题目）

面试题除了面试时用，还可以带你了解大厂会关注工程师哪些技术点，为你提供一个学习的方向。

1. Kubernetes 常见面试题汇总

• 简述 Kubernetes 和 Docker 的关系
• 简述 Kubernetes 中什么是 Minikube、Kubectl、Kubelet
• 简述 Kubernetes 如何实现集群管理
• 简述 Kubernetes 集群相关组件
• 简述 Kubernetes Replica Set 和 Replication Controller 之间有什么区别
• 简述 Kubernetes Pod 的 LivenessProbe 探针的常见方式
• ……

2. DevOps & CI/CD 常见面试题汇总

• DevOps 术语和定义
• 实施 DevOps 的原因
• 如何有效实施 DevOps
• 如何有效实施 CI/CD
• 每种术语之间的差异

3. Docker 常见面试题汇总

• 如何退出一个镜像的bash，而不终止它
• 如何查看镜像支持的环境变量
• 如何控制容器占用系统资源（CPU，内存）的份额
• Docker 与 LXC（Linux Container）有何不同
• Docker 容器创建后，删除了 /var/run/netns 目录下的网络名字空间文件，可以手动恢复它
• ……