大白话告诉你到底用不用学习这该死的k8s容器化
- 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个月的紧张筹备。而此时，我们还有很多东西没有开始：
- 云平台选型
- 架构迁移方案
- 网络及混合云共存方案
- 零k8s线上经验
- 技术及人员储备严重不足
其中，第5条最为致命，因为需要和时间赛跑。k8s的技术人员，也就我和另外一个技术同学，且经验都严重欠缺。
但容器化这样的天时、地利、人和的机会，错过就不可能再有第二次，所以大家都很拼。
这当然少不了，上层老板的资源倾斜，以及团队内其它同学主动承担日常工作，还有其它团队同学的大力支持和大开便利之门。才得以让整个项目在最后一刻压点上线。
好的，到此，感谢大家听完我唠叨完背景。下面为大家介绍技术性内容，可能比较枯燥，但请谅解且相信，我已经努力大白化了。
2、 公司现有架构和上云后的架构
前面有提到，因为高层的频繁变动。所以技术战略一直在变，上云，下云，再上云，再下云。。。。。
不要以为这是故事，如果是故事，也是真的故事。。。就发生在我们身上。
在 ALLIN 容器化的前一刻，我们的部分业务正在筹备下云。。。其它业务也像待宰的羔羊，怒气值爆满，但也只能是被屠宰的命。所以，我们架构比较乱。希望，你能懂。。我梳理了上云前部分业务的架构。是如下这样的：
上云前架构简图2
大致提几点：
- 混合云架构，专线打通
- 经过几轮调整后的中台战略，各业务之间的相互调用还相对规范了那么一点。。
- 信安在金融行业的特殊地位，在公司有着“太子军”的特权。
作为第一批容器化的项目，我们挑选的标准也比较简单：
- 非核心业务系统
- 技术栈尽可能简单
- 新业务
- 业务尽可能有代表性，如：和周边接口有着丰富的调用关系
容器化后，我们的规划的初期架构如下：
上云后架构
提炼几个关键点：
- 按功能分区
- 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 后问题，除了上面这些，又增加了：
- 数据落地 数据是金融公司的命脉，落地到阿里云的存储上，公司并不放心。或者并不符合安全规范
- 安全最小化原则 原来的网络权限最小化原则端到端并不适用，现在需要段到段
k8s安全 如果k8s使用的是托管，那么所有的数据经过apiserver时，均会被记录。apiserver需被重点保护，或者所有数据流经过类似kms加密后使用。但同步会增加业务的开发成本和使用习惯- 镜像安全
安全团队并不一定具备精深容器化能力。
Dockerfile或者docker commit等如果流程不规范，存在较大**"内鬼"**安全隐患。
如上。
解决方案如下，但不一定每家公司都有能力落地，或者有能力实施：
3.1.1、零信任管理
- 零信任安全模型下没有绝对的安全域
- 在暴露的服务前设置尽可能多的防护层，实现纵深防御
- 权限配置和凭证下发遵循权限最小化原则
- 最小化攻击面
3.1.2、精细管理访问控制
- 在云资源控制平面，遵循权限最小化原则合理分配云账号的资源访问权限
- 在K8s集群数据平面，根据业务场景，通过Namespace实现人员/应用/部门之间的逻辑隔离
- 使用RBAC进行资源模型维度的细粒度访问控制及时吊销或轮转可能泄露的访问凭证
k8s RBAC权限管理
3.1.3、 POD通信网络管理
- 控制容器入网流量
- 限定容器允许监听的指定协议，端口和服务标签等
- 限定除LB和Ingress关联的服务外不允许外网IP访问
- 限定容器只允许其服务消费者访问
- 控制容器出网流量
- 禁止不需要访问公网的Pods出网流量
3.1.4、日志审记
- 基础设施日志 云平台资源操作审计，云服务账号操作审计等；
- Kubernetes集群日志 集群control-plane组件日志，control-plane组件审计日志（secrets审计，apiserver非法访问，exec进入容器等操作审计）
- 系统运维日志 主机层应用操作和运维审计
- 应用日志 容器内应用进程日志
k8s阿里云审记
3.1.5、 数据安全
- 全链路传输加密 系统组件，服务之间的全链路数据传输加密，敏感数据落盘加密
- 密钥管理：密钥的保护和轮转 DEK（数据加密密钥）和KEK（密钥加密密钥）隔离
数据加密传输
3.2、 规范经验分享
主要的坑有如下：
namespace过多,管理混乱namespace命名混乱，无法辨识yaml命名混乱，存放混乱- 日志存储及收集优劣不清，无法选择最佳方案
对应的方案如下文
3.2.1、 namespace
- 按系统
pod数量做规划 - namespace命名需流程规范化，运维有一票否决权
- 命名需要有明确特征。如工作类(tools), 存储类(store),数据库类(db)
3.2.2、 存储
- 日志存放必须从
pod映射出来 - 日志禁止打印标准输出
- 日志建议存储两类: 本地 + 网络(sidecar+elk)
- 日志统一存放目录摆放规范:
/naspath/[data|log|config|sharedata]/namespace/NodeName_PODName/
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、 镜像经验分享
常见的坑：
- 权限太大，任何人可推送
- 不做定期清理，导致仓库太大，存储压力过大
- 镜像命名规范不成熟
- 镜像层数过多
- 镜像过大
对应的解决方案：
- 各系统服务镜像统一存放在集团镜像仓库中
- 如需要开通权限可联系应用运维负责人
- 镜像的命名规则如下：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"]
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存储。
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 到底用不用学？
不要再骗自己了。最大的不变就是拥抱变化。
运维行业的未来只有行业专家岗和技术专家岗。单纯的业务岗只会慢慢轮为职能操作岗。至于管理岗，价值会越来越依赖公司的规模，纯管理的中低层会越来越难。这次疫情只是提前映射了未来的行情状况，看看你身边的那些失业的朋友，你会明白一点点。
K8s 是一款伟大的产品，尽情去拥抱他吧！
参考： https://www.liukui.tech/2019/01/15/Kubernetes-Promethues%E7%9B%91%E6%8E%A7/ 《容器安全最佳实践》 感谢 google 的 k8s 工程师