一、前言前端
第一次接触Kubernetes是在2016年,再一次浏览博文的时候,那是我第一次听到Kubernetes这个名词,也是第一次认识了k8s这么一个东西。后来在慢慢了解它的时候,被它天生高可用、负载均衡、弹性计算、自动扩容缩容和全自动容灾机制的设计理念吸引,因而本身便踏入了k8s这条不归路,在调研学习的过程当中,开始不断填坑、挖坑再填坑,周而复始。nginx
2017年,公司还在使用裸Docker部署一些无状态的应用,随着愈来愈多的Docker实例,发生故障时,人工填坑的方式,让咱们实在头疼,有时候大半夜正在作着好梦的时候,被一个电话铃喊起来处理着因为宿主机宕机或者网络不可达引发的各种问题。这种惨绝人寰的处理方式更是让咱们头疼难忍。虽而后来引用了Swarm和Compose,但随着业务的不断增多,已经愈来愈来知足不了咱们的应用场景,而后就想着把全部Docker应用迁移到Kubernetes中去管理。git
2017年6月30日,k8s发布1.7版本,2017年10月,Docker拥抱Kubernetes,也是咱们正式开始使用Kubernetes的开始。但事情并无咱们想象中的那么简单,k8s的设计太多复杂,概念实在是太多,搭建过程更是让人吐血,当时可参考的文章又是少之又少。在通过一个多月的研究与不断回血以后,终于在k8s集群中部署了咱们的第一个应用。虽然整个过程当中踩了无数坑,遇到了无数个难题,但从始至终没有放弃,最终实现一整套的流程设计,从开发提交代码至Git,到最后成功部署到k8s集群中,完全释放了双手。遇到集群中的宿主机宕机的时候,不用再去人工去处理,这一切k8s都帮你默默的处理了...后端
二、Kubernetes带来的变革服务器
对于开发人员网络
因为公司业务多,开发环境、测试环境、预生产环境和生产环境都是隔离的,并且除了生产环境,为了节省成本,其余环境是没有日志收集的,在没有用k8s的时候,查看线下测试的日志,须要开发或者测试人员,找到对应的机器,在找到对应的容器,而后才能查看日志,在用了k8s以后,开发和测试能够直接在k8s的dashboard到对应的namespace,便可定位到业务的容器,而后能够直接经过控制台查看到对应的日志,大大下降了操做时间。负载均衡
把应用部署到k8s以后,代码的发布、回滚,以及蓝绿发布、金丝雀发布等都变得特别简单,不只加快了业务代码迭代的速度,并且全程无需人工干预。目前咱们使用jenkins、gitrunner进行发版或者回滚等,从开发环境到测试环境,到最后的生产环境,彻底遵照一次构建,多集群、多环境部署,经过不一样的启动参数、不一样的环境变量、不一样的配置文件实现区分不一样的环境。目前已经实现Python、Java、PHP、NodeJS、Go、.NET Core等多种语言的一键式发版、一键式回滚,大大提升了开发人员的开发效率。运维
在使用服务网格后,开发人员在开发应用的过程当中,不用再关心代码的网络部分,这些功能都被服务网格实现,让开发人员能够只关心代码逻辑部分,便可实现网络部分的功能,好比:断流、分流、路由、负载均衡、限速和触发故障等功能。ide
测试过程当中,可能同时多套环境,固然也会须要再建立一套测试环境,以前测试环境的建立,须要找运维或者自行手工搭建。在迁移至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的诞生,不只减小了工做的复杂性,还减小了各类成本。上述带来的变革只是其中比较小的一部分,更多优势只有用了才能体会到。
三、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亿美圆...
四、这是重点
在这些年踩了无数坑之后,也领悟到了每一个技术人员学习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。