拥抱 K8S 系列 -05- 基于 docker 部署面临的问题

假设公司分配了三台服务器分别用来部署代理应用, 代码应用和数据库应用(MySQL), 如果基于docker部署, 最后部署的结果可能如下所示:



代理应用服务器可以安装各个版本nginx或者haproxy等

/data/
├── nginx
    ├── nginx-1.12
    ├── nginx-1.14
    └── nginx-1.16



代码应用服务器可以部署各种类型的代码语言

/data/
├── node
│   ├── node-10.1-app1
│   └── node-12.1-app2
├── php
│   ├── php-5.6-5601-app3
│   ├── php-5.6-5602-app4
│   └── php-7.2-7201-app5
├── tomcat
    ├── tomcat7-7080-app6
    ├── tomcat8-8080-app7
    └── tomcat8-9080-app8



数据库服务器也能安装各个版本数据库

/data/
├── mysql
    ├── mysql-5.6-3306-app1
    ├── mysql-5.6-3307-app2
    ├── mysql-5.6-3308-app3
    ├── mysql-5.7-4306-app4
    ├── mysql-5.7-4307-app5
    └── mysql-5.7-4308-app6



即使各个应用部署得这么井井有条了, 那么依然还需要考虑以下问题

• 端口冲突问题

虽然一台服务器基于docker可以部署多种应用, 但是docker应用端口映射宿主机上的端口是不能相同的, 举例：

# 我们启动两个MySQL
# 第一个 mysql:5.6容器使用 宿主机的3306 映射 容器的3306
# 第二个 mysql:5.6容器使用 宿主机的3307 映射 容器的3306
docker run -d -p 3306:3306 -e MYSQL_ROOT_PASSWORD=mysqlpassword mysql:5.6
docker run -d -p 3307:3306 -e MYSQL_ROOT_PASSWORD=mysqlpassword mysql:5.6



1. 容器内部应用都使用3306端口，但宿主机使用端口必须不相同，否则会因为端口冲突导致容器启动失败

2. 问题来了，当服务器上启动的容器越来越多，宿主机端口管理会变成一个问题，比如

3. 一个监听8080端口docker应用，现在需要扩容到多台服务器上

4. 有些宿主机的8080端口没被占用，允许使用，但是有些宿主机的8080却被占用了，需要更改端口

5. 最终部署出来的结果是 同一个应用在宿主机上监听不同端口

6. 如果多个应用都存在同一应用端口不一致的情况，将给运维标准化管理带来巨大的麻烦



• 应用关联问题

1. 入口nginx的某个域名代理哪个代码应用?

2. 这些代码应用又分布在那台服务器?

3. 代码应用又连接了哪个数据库?

4. 这个应用访问链路的问题会随着应用部署增多越来越复杂, 尤其是应用越来越多而且端口还不一致的时候

5. 还有, 这些关联信息要记录到什么地方? 信息记录到这些地方后, 又如何做到实时更新? --几乎不太可能



• 代码应用扩容带来的问题

1. 如果一个代码应用需要扩容, 那么究竟要扩容到哪台服务器上?

2. 扩容后还需要手动修改前端nginx的配置吧. 那缩容的时候, 也要修改nginx配置. 这项操作不仅机械, 而且也容易出错.

3. 如果这种扩容缩容的操作越来越频繁的时候, 势必会增加第二个问题--应用关联的复杂度和架构更新不及时.

4. 随着公司业务增长, 可能会划分出 nodejs使用的服务器, php使用的服务器, tomcat使用的服务器, 这时候也要进行应用迁移吧? 迁移后, 应用访问链路又发生变化了, 这些信息依然依赖人工去维护.



• 服务器负载

1. 一台服务器随着部署应用的增加, 负载也势必会增加.

2. 在新增加应用时, 还要先人工评估一下服务器剩余资源能否满足应用需求吧?

3. 如果服务器数量变多了, 就意味着评估服务器资源的工作量也越来越大了.

4. 甚至评估还需要考虑当前的宿主机的业务在未来一段时间内是否会迎来业务高峰

5. 万一评估出现偏差, 又会导致运维事故.



虽然docker解决了一些服务器运维的问题--应用迁移性&资源复用性, 但也带来了一些问题. 这些问题的解决方案就是--Kubernetes.