在生产环境使用K8S已经有一段时间了，从刚开始连概念都不知道，到最后有一整套集成发布、调度的系统上线，中间有比较多的经历，有的问题网上搜索一下就有答案，有的比较抓狂，需要各种摸索，诸多问题总结如下:

1: 为什么选用k8s

   使用k8s相对于以前有比较大的变更，不紧紧是发布，连部署都已经变更，我们有着500+机器的集群，说大不大，说小不小，使用k8s并不是为了赶时髦，而的确是碰到了一些实际问题,而k8s是当前比较完善的解决方案

部署层面: 原先使用的是jenkins发布,权限不好控制，每次发布、回滚需要打包，特别是回滚，特别慢

资源浪费,比如申请个4核8G的机器，部署1到2个项目，剩下的资源是浪费的

无法做到无损和动态扩容，原有的通过HAproxy挂在前面的方式，在部署需要扩容的时候，需要人力参与

2:  k8s 集群怎么部署

  k8s的部署相对来说比较复杂,庆幸的是，我们在选型的时候，k8s已经到了1.12.2了，kubeadm比较成熟,所以我们采用手动安装etcd+ kubeadm安装的方式来部署集群，具体： https://github.com/ylzyqt/kubernetes-integration

3:  通用的发布方案   

    开发人员提交代码，系统自动进行打包,push镜像到镜像仓库,抛弃了jenkins

    需要建设"发布系统" 用来作为k8s apiserver的前置

4: 碰到的一些问题

 被Minerd挖矿程序植入 

  比较尴尬的是，如果采用带有公网的机器来部署k8s集群，并且使用了kube-proxy的方式，绑定在0.0.0.0网卡上的场景，极为容易被植入此类挖矿程序，解决方法是，apiserver或者kube-proxy只开启在内网地址上。

deployment多副本日志存储的问题

  k8s中日志有多种处理方案，但是比较常见的还是，先输出到node机器目录，然后再使用脚本统一.

  deployment可以设置多副本，当2个pod被调度到同一台机器上的时候，会向同一个日志文件进行输出，当流量比较大的时候，一是性能问题，二是日志揉杂在一起，无法区分，解决方法是，将日志文件的命名加入环境变量${HOSTNAME}，这样每个pod输出的日志文件，都是带有pod的名称的。

怎么做灰度发布

 常见的部署模式如下，但是有个问题，如果想灰度部署一个新版本，但是又不想把老版本都更新，发现无法实现，对于k8s来说，同一个deployment下面的镜像只有一份：

于是采取下面的方式，通过多创建一个 deployment的方式，来发布一个新的版本做灰度,只要标签设置成一样的，统一能够完成新创建pod来引入流量，但是pod版本与当前版本不同

使用flannel 网络部署k8s的时候，注意pod的网络地址

10.244.0.0/16 的flannel网络最多支持256个节点，如果你需要更大的集群，那么需要修改此处官方推荐的子网掩码的设定

比如: 10.244.0.0/12 接口，这样大概是可以支持4000多台机器的集群，通常运维能力不是很充足的情况下，并不建议把集群做的这么大。

迁移k8s步骤

对于已经在线上正常服务的项目，如下，原先ha的配置，指向的是a,b机器的10038端口

步骤1: 部署新的服务，比如service的nodeport设置为 30038，并验证新的服务部署成功

步骤2: 将haproxy的配置，改为指向node1,node2的30038端口，这样原先使用haproxy域名的服务可以正常使用

步骤3: 当调用方迁入k8s的时候，将域名改为 k8s的服务名，这样抛弃haproxy

为什么不用k8s 自带的dashboard，反而自己搞个 发布系统?

k8s的确自带了一个dashboard，而且比较漂亮，但是也有很多问题

权限比较复杂，rbac那一套的确够喝一壶的

比较鸡肋，对于不懂k8s的人来说，不敢用，对于懂的人来说，不愿意去用

k8s的使用不紧紧是部署，还有创建资源，这一套如果都交给运维自己来做,运维要哭了，得把一些功能集成起来，通过按钮简单的创建,如下为某个namespace下项目的截图,以供参考:

docker 镜像仓库需要账号密码怎么办?

一般自建的docker镜像仓库都有账号密码，没有账号密码,k8s无法拉取镜像

解决方案:

default的namespace新建secret,里面存储docker镜像仓库的账号密码

之后再新建namespace的时候，通过发布系统来做，发布系统，创建namespace，自动创建secret

通过发布系统创建项目的时候，自动关联secret 即可解决