1、前言
第一次接触Kubernetes是在2016年，再一次浏览博文的时候，那是我第一次听到Kubernetes这个名词，也是第一次认识了k8s这么一个东西。后来在慢慢了解它的时候，被它天生高可用、负载均衡、弹性计算、自动扩容缩容和全自动容灾机制的设计理念吸引，于是自己便踏入了k8s这条不归路，在调研学习的过程中，开始不断填坑、挖坑再填坑，周而复始。
2017年，公司还在使用裸Docker部署一些无状态的应用，随着越来越多的Docker实例，发生故障时，人工填坑的方式，让我们实在头疼，有时候大半夜正在做着美梦的时候，被一个电话铃喊起来处理着由于宿主机宕机或者网络不可达引起的各类问题。这种惨绝人寰的处理方式更是让我们头疼难忍。虽然后来引用了Swarm和Compose，但随着业务的不断增多，已经越来越来满足不了我们的应用场景，然后就想着把所有Docker应用迁移到Kubernetes中去管理。
2017年6月30日，k8s发布1.7版本，2017年10月，Docker拥抱Kubernetes，也是我们正式开始使用Kubernetes的开始。但事情并没有我们想象中的那么简单，k8s的设计太多复杂，概念实在是太多，搭建过程更是让人吐血，当时可参考的文章又是少之又少。在经过一个多月的研究与不断回血之后，终于在k8s集群中部署了我们的第一个应用。虽然整个过程中踩了无数坑，遇到了无数个难题，但从始至终没有放弃，最终实现一整套的流程设计，从开发提交代码至Git，到最后成功部署到k8s集群中，彻底释放了双手。遇到集群中的宿主机宕机的时候，不用再去人工去处理，这一切k8s都帮你默默的处理了...
2、Kubernetes带来的变革
对于开发人员
由于公司业务多，开发环境、测试环境、预生产环境和生产环境都是隔离的，而且除了生产环境，为了节省成本，其他环境是没有日志收集的，在没有用k8s的时候，查看线下测试的日志，需要开发或者测试人员，找到对应的机器，在找到对应的容器，然后才能查看日志，在用了k8s之后，开发和测试可以直接在k8s的dashboard到对应的namespace，即可定位到业务的容器，然后可以直接通过控制台查看到对应的日志，大大降低了操作时间。
把应用部署到k8s之后，代码的发布、回滚，以及蓝绿发布、金丝雀发布等都变得特别简单，不仅加快了业务代码迭代的速度，而且全程无需人工干预。目前我们使用jenkins、gitrunner进行发版或者回滚等，从开发环境到测试环境，到最后的生产环境，完全遵守一次构建，多集群、多环境部署，通过不同的启动参数、不同的环境变量、不同的配置文件实现区分不同的环境。目前已经实现Python、Java、PHP、NodeJS、Go、.NET Core等多种语言的一键式发版、一键式回滚，大大提高了开发人员的开发效率。
在使用服务网格后，开发人员在开发应用的过程中，不用再关心代码的网络部分，这些功能都被服务网格实现，让开发人员可以只关心代码逻辑部分，即可实现网络部分的功能，比如：断流、分流、路由、负载均衡、限速和触发故障等功能。
测试过程中，可能同时多套环境，当然也会需要再创建一套测试环境，之前测试环境的创建，需要找运维或者自行手工搭建。在迁移至k8s集群后，只需要在jenkins上点点鼠标即可在k8s集群上创建一套新的测试环境。
对于运维人员
如果你是一名运维人员，可能经常因为一些重复、繁琐的工作感觉厌倦。比如：这个需要一套新的测试环境，那个需要一套新的测试环境，之前可能需要装系统、装依赖环境、开通权限等等。而如今，可以直接用镜像直接部署一套新的测试环境，甚至全程无需自己干预，开发人员通过jenkins或者自动化运维平台即可一键式创建，大大降低了运维成本。
一开始，公司业务故障，可能是因为基础环境不一致、依赖不一致、端口冲突等等问题，现在实现镜像部署，所有的依赖、基础都是一样的，大大减少了因为这类基础问题引发的故障。也有可能公司业务是由于服务器宕机、网络等问题，造成服务不可用，此类情况均需要运维人员及时去修复，而如今，可能在你收到告警信息的时候，k8s已经帮你恢复了。
在没有使用k8s时，业务应用的扩容和缩容，都需要人工去处理，从采购服务器、上架、到部署依赖环境，不仅需要大量的人力物力，而且非常容易在中间过程出现问题，又要花费大量的时间去查找问题。成功上架后，还需要在前端反代端添加或该服务器，而如今，可以利用k8s的弹性计算，一键式进行扩容和缩容，不仅大大提高了运维效率，而且还节省了不少的服务器资源，提高了资源利用率。
对于反代配置方面，比如可能你并不会，或者对nginx的配置规则并不熟悉，一些高级的功能你也不会实现，而如今，利用k8s的ingress即可简单的实现那些负责的逻辑。并且也不会在遇到nginx少加一个斜杠和多加一个斜杠的问题。
对于负载均衡方面，之前负载均衡可能是Nginx、LVS、HAProxy、F5等，云上可能是云服务商提供的不在均衡机制。每次添加删除节点时，都需要手动去配置前端负载均衡，手动去匹配后端节点，而如今，使用k8s内部的service可以动态发现实现自动管理节点，并且支持自动扩容缩容。之前遇到高峰流量时，经常服务器性能不够，需要临时加服务器面对高峰流量，而如今对于高性能k8s集群，无需管理，自动扩容。
对于高可用方面，k8s天生的高可用功能，彻底释放了双手，无需再去创建各类高可用工具、检测检查脚本。k8s支持进程级别的健康检查，如发现接口超时或者返回值不正确，会自动处理该问题。
对于中间件搭建方面，根据定义好的deploy文件，可以实现秒级搭建各类中间件高可用集群，如Redis、RabbitMQ、Zookeeper等，并且大大减少了出错的概率。
对于应用端口方面，传统行业中，一个服务器可能跑了很多进程，每个进程都有一个端口，需要人为的去配置端口，并且还需要考虑端口冲突的问题，如果有防火墙的话，还需要配置防火墙，在k8s中，端口统一管理，统一配置，每个应用的端口都可设置成一样的，之后通过service进行负载均衡。
无论是对于开发人员、测试人员还是运维人员，k8s的诞生，不仅减少了工作的复杂性，还减少了各种成本。上述带来的变革只是其中比较小的一部分，更多优点只有用了才能体会到。
3、Kubernetes带来的挑战
首先是对于k8s的学习本身就是很难的，概念太多，无从入手，可能学习了一个月也无法入门，甚至连集群也搭建不出来，使人望而却步。并且k8s对运维的技术能力要求比较高，已经不仅仅局限于传统运维，有时候你可能要修改业务代码等。并且需要掌握的知识也需要很多，你可能需要掌握公司所有使用到的代码，比如代码是如何进行编译的、如何正确发布、如何修改代码配置文件等，这对于运维人员，也是一种挑战。Kubernetes之所以被叫做k8s，业界有两种说法，通俗的说法是k和s之间有8个字母，另一种比较说法是k8s集群至少需要搭建8遍才能搭建成功。当然，在实际使用时，可能不止8遍。k8s的诞生，把运维从传统转变到了DevOps方向，需要面临的问题会更多，需要面临的新技术也有很多，但是当你掌握到了k8s的核心使用，就会受益终身。
对于开发人员来说，对开发方式也有一些变化。从k8s的诞生到如火如荼，慢慢的k8s变成了一种标准，开发再进行代码开发时需要遵循Docker和k8s规范，严格遵守一次构建，多次部署原则，所有的配置都通过参数、变量或者k8s配置管理注入。并且对应用，要求是无状态的，因为Docker每次重启都会以最干净的基础启动。无论公司有没有进行业务容器化，遵循Docker和k8s规范都将成为未来的趋势，2019年7月，某公司因为代码不能和k8s兼容，导致一年亏损38亿美元...
4、这是重点
在这些年踩了无数坑以后，也领悟到了每个技术人员学习k8s的痛点在哪里，首先是k8s概念不清楚就开始放肆的把应用部署到k8s集群中，产生的问题无从入手去解决，其次是k8s集群无论如何也搭建不出来，集群扩容也难以下手，然后是持续集成持续部署方面无从下手等等问题，想要搭建一整套k8s集群不仅仅局限于k8s集群的搭建。还需要对构建、发版、测试、部署流程化，也需要将GitLab、GitRunner、Jenkins、Harbor、Kubernetes等联系起来。这都是每个使用k8s会遇到的问题。
来一波猝不及防的广告~
其实上述列出了1234项主要是为了介绍一本即将上市的Kubernetes实战技术书籍，这本书可以带你避免在使用k8s的过程遇到的各类坑。
这本书不仅能帮你快速搭建一整套集群，也会帮你解决在使用过程中遇到的各类问题，对于使用过程中的每个坑，大部分都已经帮你填上，让你少走很多弯路，少掉不少头发，让你能够快速走进k8s的正途。这本书适用于大部分企业，可以快速构建公司的k8s平台，并且容器化各类中间件、业务应用代码，如Java、NodeJS等。同样也介绍了SpringCloud各类组件的容器化。
本书以实战为主线，深入浅出地介绍了Kubernetes在企业生产中的应用。全书共6章，主要内容包括：第1章讲解Kubernetes的高可用安装，分为kubeadm和二进制安装方式。第2章介绍了Docker和Kubernetes常用的理论基础。第3章主要讲解Kubernetes的常见应用的容器化。第4章主要介绍持续集成和持续部署，包括Jenkins最新的功能Pipeline的使用，从Pipeline的语法到项目实操，传统Java和Spring Cloud应用的容器化以及自动化构建部署。第5章主要讲解了Kubernetes的Nginx Ingress的安装和常用配置。第6章讲解了备受关注的Server Mesh。