1、k8s 部署方式
https://github.com/easzlab/kubeasz
2、在实践中做了哪些调整
2.1 基于alpine基础镜像构建最小容器
https://github.com/gliderlabs/docker-alpine
基于Alpine Linux的超小型Docker镜像，该映像只有5 MB
2.2 在k8s集群中引入内部DNS解析
https://kubernetes.io/zh/docs/tasks/administer
查询首先被发送到 kube-dns 中的 DNS 缓存层。
从缓存层，检查请求的后缀，并根据下面的情况转发到对应的 DNS 上：
具有集群后缀的名字（例如 “.cluster.local”）：请求被发送到 kube-dns。
具有存根域后缀的名字（例如 “.feier.local”）：请求被发送到配置的自定义 DNS 解析器（例如：监听在 1.2.3.4）。
2.3 跨集群镜像同步
https://github.com/goharbor/harbor
在跨集群或多集群部署时，依然采用单镜像仓库，各节点通过公网同时拉取镜像，这对于服务器公网带宽将是个很大的考验，特别是在同时部署多个组件的情况下，由于同时下载镜像节点过多带宽很容易打到上限，导致整个部署时间延长。
Harbor镜像仓库，它具备多项目管理和多租户功能，可以针对项目划分不同权限。
在Harbor中，用户主要分为两类。一类为管理员，另一类为普通用户。两类用户都可以成为项目的成员。而管理员可以对该项目下的用户进行管理。
Harbor目前支持的同步方式：手动，定时，事件驱动。
2.4 镜像对业务镜像层调整
业务组件放在镜像中的一层中，每次更新都需要上传和下载除基础镜像外的所有层（几十兆）
如下图所示：
更改后的镜像层
一般情况下服务组件的lib库很少会改动，在docker镜像中没有发生改变的镜像层其ID是不变的同时会根据镜像层的ID进行存储，在进行上传和下载时如果服务器或本地存在相同的ID则该ID的镜像层不会进行上传或下载。按照这个特性我们把lib库单独放一层；而config配置和jar包每次组件更新在一定程度上会发生变化但它的体积确极小，大概只有几百kb。
经过调整后同样更新1千次版本调整前需要58G左右的空间，而后者只需要500M左右。
2.5 针对docker本身的调整
各个公司对于服务器的操作规范不尽相同，例如：数据存放目录，服务器操作账户，日志存储周期等……
对docker做以下调整：
insecure-registries：增加私有镜像仓库，优先使用本集群仓库
storage-driver：修改存储驱动，默认安装docker时会自动选择适合的驱动类型
log-driver：使用json日志格式，默认已使用json格式
logs-opts：调整容器单个日志大小，最多保留历史日志数量
data-root：修改docker工作目录