今天分享最近集团 All In 容器化 的工作心得。
虽然大家都是技术出身，但我依然会用尽可能用大白话来描述 Kubernetes 和容器化，尽可能不带代码。因为在上云的过程中，我发现，即使是有技术背景的同学，也并非所有人能很好的掌握 Kubernetes 和容器化。
个人其实接受容器化的时间算比较早的。大概 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 年中，ALL IN 的技术战略终于被抬上桌面，且作为集团层面技术战略执行。每个团队都有容器化 KPI 考核。
这简直就是冷宫坐尽，柳暗花明 ，机会不一定是争取来的，也可能是等出来的。真的是剩者为王呀！
随后就是为期不到 2 个月的紧张筹备。而此时，我们还有很多东西没有开始：
-
云平台选型
-
架构迁移方案
-
网络及混合云共存方案
-
零 Kubernetes 线上经验
-
技术及人员储备严重不足
其中，第 5 条最为致命，因为需要和时间赛跑。Kubernetes 的技术人员，也就我和另外一个技术同学，且经验都严重欠缺。
但容器化这样的天时、地利、人和的机会，错过就不可能再有第二次，所以大家都很拼。
这当然少不了，上层老板的资源倾斜，以及团队内其它同学主动承担日常工作，还有其它团队同学的大力支持和大开便利之门。才得以让整个项目在最后一刻压点上线。
好的，到此，感谢大家听完我唠叨完背景。下面为大家介绍技术性内容，可能比较枯燥，但请谅解且相信，我已经努力大白化了。
前面有提到，因为高层的频繁变动。所以技术战略一直在变，上云，下云，再上云，再下云……
不要以为这是故事，如果是故事，也是真的故事……就发生在我们身上。
在 ALL IN 容器化的前一刻，我们的部分业务正在筹备下云……其它业务也像待宰的羔羊，怒气值爆满，但也只能是被屠宰的命。所以，我们架构比较乱。希望，你能懂……我梳理了上云前部分业务的架构。是如下这样的：
作为第一批容器化的项目，我们挑选的标准也比较简单：
具体上云过程太过细节，这里不一一介绍，必然是问题多多，但总体比我们想像的要容易且顺利。这里分享一些实践经验。
大家知道，Kubernetes 提供的是解决方案，而且是各个技术细分领域的成套解决方案，比如：存储解决方案，日志收集解决方案，高可用解决方案，分布式解决方案、CI/CD解决方案、横纵向解决方案等等。
这意味着，你单纯对 Kubernetes 技术掌握的深浅只能决定你的熟练程度，而并非架构和项目解决能力。也意味着，除非从物理硬件、到系统底层、到网络架构、到 AP 应用、到 HA，HP 你都有实践应用，才能在一时间做出正确的决策。
这也意味着，第一次容器化上云，如果没有额外的技术支持。很容易踩坑。
我们第一期容器化规划了 11 个项目。这次还是有一些内容可以和大家分享下，主要从如下几个方面：
-
安全经验分享
-
规范经验分享
-
网络经验分享
-
镜像经验分享
-
流程经验分享
-
监控经验分享
-
存储经验分享
-
代码安全规范
-
开源软件网络高危漏洞
-
防止内鬼
-
IDC 环境及流量安全等
使用 Kubernetes 后，因为 IP 不固定，安全的管控带来了一些不便利。但对于非金融行业的传统互联网公司，如果不需要精细管控进出口流量，其实容器化，还是提供了很好的便利。如针对 apiserver 的安全攻击。
改用 Kubernetes 后，问题除了上面这些，又增加了：
-
数据落地，数据是金融公司的命脉，落地到阿里云的存储上，公司并不放心，或者并不符合安全规范。
-
安全最小化原则，原来的网络权限最小化原则端到端并不适用，现在需要段到段。
-
Kubernetes 安全，如果 Kubernetes 使用的是托管，那么所有的数据经过 apiserver 时，均会被记录。apiserver 需被重点保护，或者所有数据流经过类似 kms 加密后使用。但同步会增加业务的开发成本和使用习惯。
-
镜像安全，安全团队并不一定具备精深容器化能力。Dockerfile 或者 docker commit 等如果流程不规范，存在较大"内鬼"安全隐患。
解决方案如下，但不一定每家公司都有能力落地，或者有能力实施：
-
零信任安全模型下没有绝对的安全域
-
在暴露的服务前设置尽可能多的防护层，实现纵深防御
-
权限配置和凭证下发遵循权限最小化原则
-
最小化攻击面
-
在云资源控制平面，遵循权限最小化原则合理分配云账号的资源访问权限
-
在Kubernetes集群数据平面，根据业务场景，通过 Namespace 实现人员/应用/部门之间的逻辑隔离
-
使用 RBAC 进行资源模型维度的细粒度访问控制及时吊销或轮转可能泄露的访问凭证
-
namespace 过多，管理混乱
-
namespace 命名混乱，无法辨识
-
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 管理
-
权限太大，任何人可推送
-
不做定期清理，导致仓库太大，存储压力过大
-
镜像命名规范不成熟
-
镜像层数过多
-
镜像过大
-
各系统服务镜像统一存放在集团镜像仓库中
-
如需要开通权限可联系应用运维负责人
-
镜像的命名规则如下：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。
Kubernetes 的 Prometheus 解决方案
Kubernetes 支持的存储类型非常多，几乎覆盖市面常见存储类型：awsElasticBlockStore，CephFS， EBS，azureDisk，emptyDir，ConfigMap 等等，这里不赘述，详见官方。
使用哪种，具体参考业务类型，以阿里云为例，我们通常使用 3 种方案结合：
主要针对分布式存储场景的业务。比如日志，配置文件（阿里的技术工程师建议直接打到 Pod 里面），SVN，GitLab，db 的数据存放。等对分布式数据有要求的业务场景。
优点：简单好用。横向、纵向几乎无限扩展。数据管理极为方便
