皮皮网

1.k8s要学多久
2.NodeJS 服务 Docker 镜像极致优化指北

k8s要学多久

       学习Kubernetes的基础知识并不困难，特别是如果你已经有半个月的Docker使用经验。主要挑战在于封装镜像时需要考虑挂载、拆分和启动检测等问题。

       安装Kubernetes本身就是一个复杂的过程。前期的copilot源码泄露安装尝试包括自动化安装、手动安装、脚本自动化安装、Ansible安装和离线安装，这耗费了我大约一个月的时间。随后，我遇到了一些环境和网络问题，jdk架构源码导致pod一直重启，这个问题持续了大约两个月。我尝试更换为实体机，问题有所缓解，但最终估计还是网络不稳定导致。

       学习kubectl命令和Kubernetes的基本组件（如pod、svc、deployment、daemonset、statefulset、headlessService、idea 源码调试rc、kube-proxy、rbac等）也是需要花费时间的。我花了大约一个月时间来理解这些组件的原理，尤其是新版本的rbac权限问题。Kubernetes的复杂性主要在于其体系架构，一旦理解了架构，就理解了大部分的内容。

       在对开源工程domeos进行研究后，我使用了两个月时间来调研该开源工程的源码，以及它自带的android 源码设计一些小米open-falcon监控插件、webssh等插件。这些研究涉及使用Springboot开发，连接Kubernetes环境，部署和监控基本应用。

       为了调优日志和监控，我又花费了一个多月的时间来调研一些开源产品，如efk日志插件、Prometheus与heaspter监控组件、habor镜像仓库等。

       最后，我开始使用Helm这一编排工具，macd源码优化根据Hadoop的过程改造公司的一个mpp产品，并实现一键式部署。这同样花费了一个多月的时间。在这一过程中，我还研究了Hadoop的扩容、亲和性、带状态应用部署等问题，以及数据删除问题。

NodeJS 服务 Docker 镜像极致优化指北

       在开发一个腾讯文档全品类通用的 HTML 动态服务时，为了方便各品类接入的生成与部署，考虑使用 Docker 的方式来固定服务内容，统一进行制品版本的管理。以下是在服务 Docker 化过程中积累的优化经验。

       通常初学者会这样编写项目的 Dockerfile，构建，打包，上传一气呵成，但镜像状态显示，一个简单的 node web 服务体积居然达到了惊人的 1.3 个 G。首先，镜像体积过大必然会对镜像的拉取和更新速度造成影响，集成体验会变差。其次，项目上线后，同时在线的测试环境实例可能成千上万，这样的容器内存占用成本对于任何一个项目都是无法接受的。

       发现问题后，我开始研究 Docker 的优化方案，准备给我的镜像动手术了。

       对代码本身体积进行优化，避免使用 tsc 打包生成 es5 后就直接运行，而是使用 Webpack + babel 降级并压缩 Typescript 源码。梳理 npm 包的 dependencies 与 devDependencies 依赖，去除不是必要存在于运行时的依赖，方便生产环境使用 npm install --production 安装依赖。

       减小依赖的操作系统的大小，考虑尽可能去除 Linux 下不需要的各类工具库，选取更轻量级的 Linux 发行版系统，如 node:-alpine。

       利用 Docker 的分级构建特性，首先在完整版镜像下进行依赖安装，之后运行生产环境，使用 alpine 版本作为基础镜像，编译完成后的源码通过 --from 参数获取到处于 build 任务内的文件。

       在保证速度的前提下，考虑构建体积优化，优先保证构建时间，其次在不影响时间的情况下，尽可能的缩小构建缓存体积。

       避免使用进程守护，利用 Docker 本身和基于 Docker 的编排程序提供崩溃重启和日志记录功能，无需使用额外应用实现。

       日志持久化存储，通过 Docker Manager Volume 将数据写到宿主物理机器上，或者利用云日志服务托管，如腾讯云 CLS。

       选择 Kubernetes 的 Deployment 或 StatefulSet 控制器，Deployment 用于部署无状态服务，StatefulSet 用于部署有状态服务。

       镜像优化后的结果是镜像体积达到了 倍左右的优化效果，最终被压缩到 M 以内。优化不仅仅体现在体积数据上，更在于架构设计层面上的转变，将服务面向容器化云服务。