kubernetes基础知识

互联网发展如火如荼，逐步从单机时代、虚拟机时代进入云原生时代。这一切的转变都源自于服务架构模式的转变。服务架构模式演变过程如下所述。
1）集中式/单体应用架构：
当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。
前后端都在一个包里，所有的业务模块都耦合在一个项目里，大多数都是模块之间的调用，开发和部署都在一起；
单个模块有更新，所有模块一起启停，而且对高并发、大数据处理能力比较弱；
缺点：
代码耦合，开发维护困难；
无法针对不同模块进行针对性优化；
无法水平扩展；
单点容错率低，并发能力差；
2）垂直拆分
当访问量逐渐增大，单一应用无法满足需求，此时为了应对更高的并发和业务需求，我们根据业务功能对系统进行拆分；
优点：
系统拆分实现了流量分担，解决了并发问题;
可以针对不同模块进行优化;
方便水平扩展，负载均衡，容错率提高;
系统间相互独立;
缺点：
服务之间相互调用，如果某个服务的端口或者ip地址发生改变，调用的系统得手动改变；
搭建集群之后，实现负载均衡比较复杂；

3）分布式架构
当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。
此时，用于提高业务复用及整合的分布式调用是关键。
将一个大的系统拆分成多个子系统;
优点：
将基础服务进行了抽取，系统间相互调用，提高了代码复用和开发效率；
缺点：
系统间耦合度变高，调用关系错综复杂，难以维护;
搭建集群之后，负载均衡比较难实现;

4）面向服务架构（SOA,service oriented architecture）：
基于分布式架构演变来的，俗称服务化，可以理解为面向于业务逻辑开发层。
将共同的业务逻辑进行拆分、拆分成独立一个项目进行部署，没有视图层。服务概念可以理解为接口。将应用中相近的功能模块聚合到一起，以服务的形式提供出去，服务于服务之间通过接口进行通信，其是面向服务的；

5）微服务架构：
缺点：K8S要求较高，出现问题排查难度大。
微服务架构基于SOA架构演变来的。
单体应用拆分成多个互不相干的小应用，每个小应用称为微服务。
服务与服务之间通过轻量级的通信机制（通常是基于http、RESTful Api）互相协作、配合；
每个服务都是围绕具体的目的/业务进行构建，并运行在独立的进程中，可独立部署，可以用不同的编程语言编写，并使用不同的数据存储技术。

服务架构模式的转变从而推动应用服务部署方式的进步，其过程如下所述。
1）物理机原生部署：单台物理机安装OS→部署依赖环境→安装应用程序→重复以上步骤在其他物理机部署服务→调试→试生产→生产运营；
缺点：小时级别部署、硬件资源利用率低、成本投入大、物理机硬件限制软件平台、应用迁移复杂、扩展比较困难（纵向扩展受限）；
2）虚拟机部署：物理机虚拟化（分2种形式）→虚拟机安装OS及环境→部署应用→调试→试生产→生产运营；
优点：硬件资源池化使得硬件利用率提高、物理资源层面的隔离、不受硬件平台限制、扩展容易、方便对接云化、可将依赖环境的OS打包成一个镜像模板；
缺点：十分钟级别部署、系统消耗资源高（虚拟化及虚拟机操作系统占用资源）；
3）容器化部署：物理机或虚拟机安装OS→从仓库拉取并运行服务镜像→调试→试生产→生产运营；
优点：秒级部署，APP层面的隔离、保证开发、测试、部署、调试、生产、运维的环境高度一致，统资源消耗低，简化配置、提升开发效率；
缺点：容器多时，管理比较困难；应用不能完全隔离；
4）容器云部署：
优点：K8S等工具实现容器编排及自动化运维；
缺点：K8S要求较高，出现问题排查难度大。

云原生时代，要求我们掌握云计算及容器相关技能。

容器技术，确保开发、测试、生产环境高度一致，使得开发、测试、运维的交流更加高效，加速自动化运维、DevOPS的发展。集群化的生产要求，引进了容器编排工具。
容器编排：对数量较多的容器进行创建、管理、调度、运维。

K8S：一个分布式集群的容器编排工具,现已称为容器编排的事实标准。

K8s历史背景：使用go语言对谷歌容器的资源管理器borg进行翻写后开发出k8s,以确保其主导地位。

K8s优点：
1）轻量级---采用go语言开发，耗用资源少，但功能强大。go语言被视为与C语言一样执行效率高的解释型语言。
2）开源，弹性伸缩；
3）高效的负载均衡：IPVS;
4）自动化运维，如：部署、扩缩容、恢复容器、更新；
5）提供高可用架构；
6）提供程序级检查方法，如livenessProbe;docker及传统方法需要使用很多脚本才能实现；
7）svc实现容器端口映射，不再暴露宿主机端口至外网；
8）效率高，20min可干完以前2d的工作量；

K8S版本介绍：
每年发布3个版本，小版本≥5的K8S适用于生产环境；
K8S在1.20版本废弃dockershim插件（该插件被K8S用于兼容docker),将在1.23版本废弃docker（docker不符合CRI，估计会自行调整），但仍支持dockerfile创建的镜像。
K8S从1.16版本开始增加startupProbe,与livenessProbe,readinessProbe形成3种探针。

K8S高可用架构
包含对象：Worker Nodes,Master Nodes,load balancer,Etcd cluster、registry、client。
client---客户端，部署UI、CLI的终端；
Master---控制节点，因污点存在而不会被调度任务；由于该节点需要绑定IP及端口、生成证书等，故master的硬件资源应该预留充分（3个16C64G的master能支持500～1000个node），避免后期进行扩容；
node---工作节点；
etcd cluster---键值数据库集群，资源一定要预留充足。
registry---本地及远程仓库，存储镜像的服务器；