二、k8s项目的生命周期
项目的生命周期
创建-----------》发布-----------》更新--------》回滚----------》删除
kubectl create deployment nginx1 --image=nginx:1.22 --replicas=3
基于deployment控制器创建pod
控制器的名称是nginx1
pod使用的镜像:nginx:1.22
--replicas=3 pod的数量有多少 3个
基于控制器创建的pod，删除pod相当于是重启，pod的数量是不会变化的。
删除控制器，才会删除pod
pod端口映射 expose
kubectl expose 暴露出来的是service的类型，可以供内网访问的一个方式。
--port=80 集群对外服务的端口
--target-port=80 容器端口
service类型*
service一旦和控制器的标签关联之后，会自动的发现该控制器pod的变化，自动的获取pod的数量和ip地址的变化。
service既可以关联一个控制器，也可以关联多个控制器，也可以关联pod。
pod是不断变化的，service的不变的。所有必须要有一个中间的状态。
service的类型：
ClusterIP:当设置控制器的暴露端口时，不指定type，默认就是ClusterIP，service的默认类型。
访问这个ip可以直接访问pod，但是外部的请求是不能直接到达的。仅限于集群内部的通信。
NodePort:需要在创建的时候指定端口类型 --type=NodePort，一旦设定NodePort，会在每个节点上都开放一个端口，每个节点上的端口都是相同的，NodePort的端口号的范围30000-32767
LoadBalancer:这个地址一般是云平台服务商提供的地址，仅限于公有云服务平台上设置的service.
可以通过这个地址直接访问，实现负载均衡。
ExternalName:不能提供负载均衡的服务，service映射到集群外的域名，不涉及后端的pod负载均衡化。
修改配置文件
pod的镜像更新：
kubectl set 更新应用资源
修改pod的镜像文件：
kubectl set image deployment nginx1 nginx=nginx:1.15
deployment的更新方式是滚动更新，也更新其中一部分，然后更新所有
回滚：用于，命令行控制。
可以回滚到上一次，也可以隔代
kubectl rollout history deployment nginx
kubectl rollout undo deployment nginx --to-revision=1
显示操作的步骤 数字越大，离最后一次操作越近
项目的发布方式：
蓝绿发布：把应用服务器分为蓝组和绿组
要先升级蓝组，先把蓝组从负载均衡中移除出去，绿组继续为用户提供服务。
升级蓝组，蓝组升级完毕之后，加入到负载均衡当中，把绿组移除，再升级绿组
完成之后，再把绿组加入到负载均衡当中去。
特定：
1、如果升级有问题，影响范围比较大
2、发布策略简单
3、用户无感知，平滑过渡
早期成本是比较高的，现在有了负载均衡之后，成本也降低了。
金丝雀发布：
在升级的时候，先升级一小部分，然后暂停整个升级，一部分是新的，另一大部分还是旧的。
筛选出一小部分用户在新的版本上应用，观察，如果没有问题再把剩余的部分全部更新到新版本。
特点：
1、一旦出现问题，影响范围很小，调整和修复也很快
2、充分评估了版本的性能，稳定，出问题的话对用户的体验影响也很小。
3、用户无感知，平滑过度。
取消暂停
滚动更新：k8s的deployment的默认更新方式
声明式------->yaml文件
直接创建pod 可以直接删除
命令行 
生成一个yaml文件
查看接口和资源对象类型
yaml文件
运行命令
删除 直接删除文件
创建命名空间
kubectl create namespace 空间名称
创建depoyment yaml文件
创建service yaml文件
可以将两个文件放入同一文件中执行
映射
直接和宿主机映射 在从节点访问（不推荐）
只能访问对应节点 （DaemonSet模式）
重启策略
deployment创建的yaml文件的重启策略不能是never只能是always
重启策略
传参
多个命令必须要使用/bin/bash -c ,多个命令要用；隔开
command和agrs在一个yaml文件中，非传参的情况下，只能存在一个，表示容器的启动命令，会覆盖原容器的启动命令
重点
yaml文件
pod
deployment/daemonset
service
ingress
基础三大文件
hostPort:直接占用宿主机的接口
command和args 传参
容器的重启策略：
控制创建的只能是always