这节课大家跟随博哥爱运维来会会deployment这个怪物
K8s会通过各种Controller来管理Pod的生命周期，为了满足不同的业务场景，K8s开发了Deployment、ReplicaSet、DaemonSet、StatefuleSet、Job、cronJob等多种Controller，这里我们首先来学习下最常用的Deployment，这是我们生产中用的最多的一个controller，适合用来发布无状态应用.
我们先来运行一个Deployment实例：
在K8s新版本开始，对服务api进行了比较大的梳理，明确了各个api的具体职责，而不像以前旧版本那样混为一谈查看创建结果kubectlgetrskubectlgetpodkubectlgetpodNAMEREADYSTATUSRESTARTSAGEnginx-f89759699-26fzd1/1Running098skubectlscaledeploymentnginx--replicas=2/nginxscaledkubectlgetpodNAMEREADYSTATUSRESTARTSAGEnginx-f89759699-26fzd1/1Running0112snginx-f89759699-9s4dw0/1ContainerCreating02skubectlgetpod-owideNAMEREADYSTATUSRESTARTSAGEIPNODENOMINATEDNODEREADINESSGATESnginx-f89759699-26fzd1/1/1我们先看看目前nginx是哪个版本，随便输入一个错误的uri，页面就会打印出nginx的版本号了/1htmlheadtitle404NotFound/title/headbodycenterh1404NotFound/h1/centerhrcenternginx/1.19.4/center/body/html注意命令最后面的`--record`参数，这个在生产中作为资源创建更新用来回滚的重要标记，强烈建议在生产中操作时都加上这个参数观察下pod的信息，可以看到旧nginx的2个pod逐渐被新的pod一个一个的替换掉我们再看下nginx的rs，可以看到现在有两个了看下现在nginx的描述信息，我们来详细分析下这个过程注意这里，这个就是用来控制rs新旧版本迭代更新的一个频率，滚动更新的副本总数最大值(以2的基数为例)：2+2*25%=2.5--3，可用副本数最大值(默认值两个都是25%)：2-2*25%=1.5--2Events:TypeReasonAgeFromMessage-------------------------NormalScalingReplicaSet21mdeployment-controllerScaledupreplicasetnginx-89fc8d79dto1上面完成就释放掉一个旧版本的NormalScalingReplicaSet20mdeployment-controllerScaledupreplicasetnginx-89fc8d79dto2释放掉最后1个旧的pod还记得我们上面提到的--record参数嘛，这里它就会发挥很重要的作用了/1htmlheadtitle404NotFound/title/headbodybgcolor="white"centerh1404NotFound/h1/centerhrcenternginx/1.9.9/center/body/htmlkubectlsetimagedeployments/nginxnginx=nginx:1.19.5--/1htmlheadtitle404NotFound/title/headbodycenterh1404NotFound/h1/centerhrcenternginx/1.19.5/center/body/html首先通过命令查看当前历史版本情况，只有接了`--record`参数的命令操作才会有详细的记录，这就是为什么在生产中操作一定得加上的原因了根据历史发布版本前面的阿拉伯数字序号来选择回滚版本，这里我们回到上个版本号，也就是选择2，执行命令如下：等一会pod更新完成后，看下结果已经回滚完成了，怎么样，在K8s操作就是这么简单：可以看到现在最新版本号是4了，具体版本看操作的命令显示是1.9.9,并且先前回滚过的版本号2已经没有了，因为它已经变成4了这条命令是不是很眼熟，对了，这就是上面创建deployment的命令，我们在后面加上`--dry-run-oyaml`,--dry-run代表这条命令不会实际在K8s执行，-oyaml是会将试运行结果以yaml的格式打印出来，这样我们就能轻松获得yaml配置了---apiVersion是当前配置格式的版本kind:Deployment---metadata是该资源的元数据，name是必需的元数据项creationTimestamp:nulllabels:app:nginxname:nginxspec:---replicas指明副本数量，默认为1selector:matchLabels:app:nginxstrategy:{}template:---metadata定义Pod的元数据，至少要定义一个label。label的key和value可以任意指定creationTimestamp:nulllabels:app:nginxspec:在K8s上命令行删除一个资源直接用delete参数可以看到关联的rs副本集也被自动清空了相关的pod也没了kubectlcreatedeploymentnginx--image=我们注意到执行上面命令时会有一条告警提示--dry-runisdeprecatedandcanbereplacedwith--dry-run=client.,虽然并不影响我们生成正常的yaml配置，但如果看着不爽可以按命令提示将--dry-run换成--dry-run=client开始创建，我们后面这类基于yaml文件来创建资源的命令统一都用apply了查看创建的资源，这个有个小技巧，同时查看多个资源可以用,分隔，这样一条命令就可以查看多个资源了#kubectlgetdeployment,rs,/nginx2/222116/nginx-f89759699222116sNAMEREADYSTATUSRESTARTSAGEpod/nginx-f89759699-bzwd21/1Running0116spod/nginx-f89759699-qlc8q1/1Running0116s基于这两种资源创建的方式作个总结：
基于命令的方式：1.简单直观快捷，上手快。2.适合临时测试或实验。基于配置文件的方式：1.配置文件描述了What，即应用最终要达到的状态。2.配置文件提供了创建资源的模板，能够重复部署。3.可以像管理代码一样管理部署。4.适合正式的、跨环境的、规模化部署。5.这种方式要求熟悉配置文件的语法，有一定难度。
deployment小怪战斗（作业）
试着用命令行和yaml配置这两种方式，来创建redis的deployment服务，同时可以将pod后面的作业再复习下
