Kubernetes & Docker 实施中你会遇到的问题

Kubernetes & Docker 实施中你会遇到的问题

在项目中实施容器技术，你可以遇到下列问题。
真的需要容器吗？
技术人员强上容器的问题？
使用容器技术会遇到哪些问题？
如何解决遇到的问题？

真的需要容器吗？

请仔细思考以下几个问题

• 非用不可的理由是什么？仅仅是趋势吗？
• 容器能为企业带来哪些价值？能降本增效？
• 目前团队对容器技术掌握程度？包括架构师，开发人员，测试人员，运维人员
• 技术转型的成本有多高？是否需要停服升级？
• 人力成本呢？是否要为此招聘新的员工？
• 转到容器后故障降低了吗？转型失败有回撤方案吗？
• 从产品角度解决了用户的哪些痛点？用户体验改善了吗？

镜像会遇到的问题

目前docker 镜像，没有统一标准，体现在以下几个方面。

镜像使用的OS发行版不统一

在使用过程中会遇到过各种版本的 OS。包括 alpine, debian, ubuntu, centos, oraclelinux, redhat 等等……

经过裁剪的 OS 面目全非，不完整

即使是镜像采用 CentOS 母版，很多镜像制作者会给操作系统减肥。经过优化后，已经不是官方版本，在使用过程中你会遇到各种麻烦。例如调试的时候需要 curl,wget,telnet,nslookup 等工具在镜像中没有。甚至 ps, top, free, find, netstat, ifconfig 命令都没有。

很多容器都不带 iptables 所以，即使带有iptables 在容器中修改规则也很麻烦。

安装位置不统一

传统OS 以 CentOS为例，有严格的安装规范，例如:

通常安装位置是

• /etc/example 配置文件
• /bin/sbin 二进制文件
• /var/lib/example 数据文件
• /var/log/example 日志文件
• /var/run/example PID 文件
• /etc/sysconfig/example 启动参数文件
• /etc/system.d/example 启动脚本

或者被安装在

• /usr/local/etc 配置文件
• /usr/local/bin 可执行文件
• /usr/local/share 文档

最后一种是独立安装在：

/usr/local/example

容器镜像那可是五花八门，没有统一标准，如果不看 Dockerfile 根本不知道作者将文件安装到了哪里。

常常存储目录被放置在根目录。例如 /data

时区遇到的问题

很多外国人制作的镜像，根本没有考虑国际化问题，包括时区，日期格式等等。

例如监控系统 Prometheus 和 Alertmanager 默认是 UTC 时区，由于镜像制作并不规范，无论你怎么修改，你都无法将时区改为 CST，最终你只能自己制作镜像。

Linux 系统也存在BUG

在我的20年职业生涯中是遇到过 Linux 系统有BUG的，还向 Redhat 提交过 BUG。如果你采用的镜像有BUG，你想过怎么去debug 吗？

容器会遇到的问题

程序启动的区别

在Linux是一般是采用守护进程方式启动。启动后进入后台，启动采用 systemd 。

容器中启动通常是直接运行，这样的运行方式，相当于你在linux的Shell 终端直接运行一样，是在前台运行，随时 CTRL + C 或者关闭终端窗口，程序就会退出。容器采用这种方式启动，就是为了让 docker 管理容器，docker 能够感知到容器的当前状态，如果程序退出，docker 将会重新启动这个容器。

守护进程方式需要记录 pid 即父进程ID，用于后面管理该进程，例如可以实现 HUP 信号处理。也就是 reload 操作，不用退出当前程序实现配置文件刷新。处理 HUP 信号，无需关闭 Socker 端口，也不会关闭线程或进程，用户体验更好。

容器是直接运行（前