DevOps与K8S基础概念

一、服务编排

传统应用编排：早期实现安装应用程序部署，运维工具：Ansible(应用编排工具)

容器时代：以往我们管理的对象是直接部署在操作系统环境中的应用程序，而有了Docker之后，我们的应用程序被容器化，各种应用程序被封装在容器中执行，容器化提供的接口跟早期传统意义上应用程序的访问控制和管理接口不同，Docker时代就是新式的，面向容器的编排工具的实现

• 在容器化时代，通过传统运维方式去管理服务几乎是不能完成的任务；必须要用容器编排工具来实现

1. Docker compose：更适合单机编排，只能面向一个docker主机进行编排
2. Docker swarm：能够将多个docker主机整合为同一平台之下的管理机制的一个集群工具，能将多个docker主机提供的计算资源整合在一起，整合为一个资源池，随后docker compose再去编排时只需要面向swarm整合出来的这一个资源池进行编排就行，而无论底层到底是什么样的docker主机或有多少台docker主机；Docker如何成为Docker swarm中的一个docker主机？docker machine
3. Docker machine：能够将一个主机迅速初始化为一个能够满足加入到docker swarm集群中的先决条件，从而成为docker swarm中的一份子；
4. mesos：IDC的操作系统，能够将一个IDC中的提供的所有硬件计算资源统一调度和分配，但是它所面向的上层接口不是容器接口，而只是资源分配工具，不能够直接托管运行容器，如果要实现去管理容器，还需要提供一个可以面向容器的框架，maeathon
5. kubernetes：K8S在容器编排领域占领了80%以上的份额

二、DevOps

早期瀑布开发到敏捷开发；早期的单体架构到分层架构再到现在的微服务架构

计划—>架构设计—>开发—>构建—>测试[通过]—>运维—>发布上线

常见的部署方式：蓝绿部署、灰度发布、金丝雀发布

容器技术的出现，使DevOps在落地上完全实现了可能，持续部署成为现实。

DevOps并不一定要依托在容器之上，但恰恰是容器技术的出现使得DevOps得以迅速流行，而恰恰又是DevOps的迅速流行使得容器编排成为了一款重要的底层基础工具。

编排工具自身并不能提供DevOps环境，只有在掌握了容器编排工具之后，再把DevOps这种思想或者文化构建于、落地于容器编排平台之上。

DevOps并不是一种技术，它是一种文化、是一种运动、是一种趋势；简单来说就是讲以往手动去实现或者去解决的问题，通过用工具化的方式去自动化的实现解决，从而使Dev和Ops之间可以协同工作。

开发提交代码至仓库后然后可以直接触发代码构建，构建完之后再被自动化测试工具进行各种测试，测试没有问题，然后交付给运维；如果测试有问题，将对应的代码直接打回给对应的开发人员，然后修复提交再进行构建测试，直到测试通过。

测试完成后将对应的包传到某个可以运维直接拿到构建好的包的地方，这就是持续交付；

测试完后的包直接可以发布到线上环境，这就是持续部署。传统方式是无法在异构的平台上进行持续部署的，不同的环境下构建打包方式不同，而有了容器技术后，不在关注程序跑在什么样的平台，不管是win环境还是linux，mac都可以直接跑起来，只要该系统中运行了容器引擎。

• 将一个应用拆解为多个微小的服务来提供服务
• 现在的很多微服务架构都是构建在容器之上，因为利用容器本身的特性和优势把对应的容器技术和微服务结合起来之后迅速的实现一个落地的方案

三、kubernetes

中文翻译：舵手；主要由谷歌的几位工程师所创立，在2014年首次对外宣布；kubernetes的开发深受谷歌内部的Borg系统的影响，Borg是谷歌内部使用了多年的容器编排工具

• kubernetes 1.0版本发布时间：2015年7月；以一年4个版本进行迭代发布
• 项目地址：https://github.com/kubernetes/kubernetes
• 2017年10月，docker宣布在他们的平台之上同时支持swarm和k8s容器编排工具

1. 自动装箱：基于资源依赖以及最大约束能够自动完成容器的部署，且不影响其容器的可用性
2. 自我修复：自愈能力，一旦容器出现问题，它可以在一秒钟重新启动一个新的起来(前提：镜像是已经下载至本地并且程序本身初始化快)
3. 水平扩展：自动实现水平扩展，当容器资源不够时，可以实现不断向上扩展(只要容器所在物理资源足够)
4. 服务发现：自动实现服务发现
5. 负载均衡
6. 自动发布和回滚
7. 秘钥和配置管理
   1. 早期非云原生的应用程序不是面向云原生而开发的，所以应用程序需要读取配置文件来获取配置；而面向云原生开发的应用程序是基于环境变量来获取配置，所以直接更改环境变量的值，那么容器中的应用在重新启动的时候则直接自动拥有了你所传递的环境变量的配置级别；传统的非云原生的容器应用程序如果想要实现读取配置文件，则需要通过写脚本进行定义然后传参的方式输入到容器应用的配置文件中。
   2. 配置中心：当镜像启动为容器时，只需要让镜像去加载外部配置中心当中的配置信息，即可完成配置；让应用程序加载配置信息时不是通过配置文件的方式去获取；我们完全可以将配置信息存储在一台服务器上，应用程序启动时不是通过配置文件来加载配置信息，而是通过服务器上所提供的配置信息直接获取，不再本地加载配置，而是通过一个第三方的服务器去加载自己的配置，通过网络先获取到，获取到之后在启动；这样的好处是配置的集中化，以后更改配置文件只需要改配置中心的配置就可以了
8. 存储编排：把存储卷实现动态供给，根据容器需求创建实现满足其容器的存储卷
9. 任务的批处理运行

集群模型：常用的两种模型

1. 没有中心节点的(P2P)，每个节点都能直接接收用户请求，能路由请求的模型；
2. 有中心节点的(中心节点另外名词：名称节点)，例如MySQL的主从复制，有一个节点是主节点那么其他的节点都与这个主节点进行同步，还有比如HDFS这种文件存储系统

K8S属于有中心节点的架构系统，Master-Nodes(worker)模型

Master：创建启动容器的请求交给maser，master中有一个调度器去分析各node节点现有的可用资源状态，找一个最佳适配运行用户所请求容器的节点，有该node本地的docker容器引擎把这个容器启动起来。

Node：运行容器，启动容器时，先检查本地是否存在对应的镜像，如果没有则去镜像仓库进行下载，然后在启动。

• 接收请求只能是kubernetes cluster，远程访问我们一般是通过一个套接字向外提供服务，而文章来源(Source)：https://www.dqzboy.com套接字向外提供服务一般都是API接口，所以我们客户端访问要么编程访问，要么有专门编好的客户端程序访问，比如通过MySQL Client访问MySQL Server的3306端口。

K8S集群：组合多台主机的计算资源整合为一个大的资源池并统一对外提供计算、存储等能力的集群；多台主机上都安装上kubernetes程序，并通过这个程序进行协同工作；把多个主机当一个主机来使用，让多台主机在这个程序级别上实现通信从而完成彼此间的协调；

API Server：负责接收请求，解析请求，处理请求。

Scheduler：负责去观测每个Node之上总共可用的计算CPU、RAM和存储资源，并根据用户所请求创建的这个容器所需的资源量来判断哪个Node节点最合适。

• 两级调度：K8S提供了一个2级调度的方式来实现资源的调度；第一步先做预选，评估每个节点到底有多少个是符合这个容器运行需求的；第二步优选，从选出来的里面选择最优的那个节点。
• 注：如果某个node节点宕机了，那么该node节点上的pod也会没了，这时就会通过k8s的自愈能力去另外的node节点启动相应的pod

Controller-Manager：负责维护集群的状态

kubelet：执行调度器传的请求去执行命令；kubelet并不去进行创建容器

Docker：容器引擎，运行Pod中的容器运行

kube-proxy：负责为Service提供cluster内部的服务发现和负责均衡

• K8S上最小的调度逻辑单元；
• 特点：将多个容器联合起来加入到同一个网络名称空间中。
• 一个Pod中可以运行多个容器，多个容器共享同一个底层的网络名称空间(Net\UAT文章来源(Source)：浅时光博客\Mount)；
• 同一个Pod中的各容器还共享第二种资源，存储卷；存储卷不属于容器，而是属于Pod。
• 一般一个Pod内只放一个容器，除非容器之间有特别紧密的关系需要放置在同一个Pod中，如果放在同一个Pod中，那么其中一个容器为主容器，其他为辅助这个主容器内的应用文章来源(Source)：https://www.dqzboy.com程序完成更多的功能。
• 多个Pod运行在一个集群中，如何管理？如何让某个控制器只管理部分Pod？
  • 肯定不能以Pod名称来识别(不是唯一固定的标识)；可以在Pod之上附加一些元数据，用标签(Label：kev=value)来识别Pod。可通过标签选择器selector进行过滤。

自我管理，创建以后需要提交给Api Server，由Api Server接收以后借助于调度器(Scheduler)将其调度给指定的Node节点，由Node启动此Pod；如果此Pod中的容器出现故障，需要重启容器，那么由kubelet来完成；但是如果是节点故障，这个Pod也会随即消失了，没法实现全局进行调度。

正是由于控制器机制的使用和引入，使得在kubernetes的集群设计中Pod完全可以叫做有生命周期的对象；而后由调度器将其调度至集群中的某节点运行。

• ReplicationController：副本控制器
  • 当我们启动一个Pod时，如果这个Pod不够了，那么我们可以在启动一个副本；而后控制器专门控制着同一类Pod对象的各种副本，一旦副本数量少了，它会自动添加一个副本补够；多了则剔除。
  • 该控制器可以实现滚动更新，自动控制实现；同时也支持回滚。
• ReplicaSet：副本集控制器
• Deployment：无状态副本集
• StatefulSet：有状态副本集
• DaemonSet：每个Node上运行一个副本，而不是随意运行
• Job：作业
• Ctonjob：周期性任务计划作业

每一种控制器，都是用来实现某一种特定的应用管理的。