在k8s当中支持两种声明资源的方式：
1、 yaml格式：主要用于和管理资源对象
2、 json格式：主要用于在API接口之间进行消息传递
声明式管理方法(yaml)文件
1、 适合对资源的修改操作
2、 声明式管理依赖于yaml文件，所有的内容都在yaml文件当中。
3、 编辑好的yaml文件还是要靠陈述式命令发布到k8s集群当中。
分别有三种方式：
create
#只能创建，不能更新。从指定的yaml文件中读取配置。创建服务。不能更新服务。
apply -f
#既可以创建资源对象，也可以更新资源对象。如果yaml文件更改了，apply可以直接更新资源对象。（使用最多）
delete -f
#删除yaml文件中声明的资源对象。例如deployment、pod、service如何生成yaml文件
1、 手动创建
2、 根据已有的资源直接生成
kubectl get deployments.apps nginx -o yaml > /opt/test.yaml
#基于已有资源直接创建yaml文件
kubectl apply -f test.yaml
#执行yaml文件
#只能运行一次。
#运行成功后如果还需要修改需要基于最新的deployment再创建yaml文件
kubectl apply -f test.yaml --force
#强制执行yaml文件
#如果不想使用最新的deployment再创建yaml文件可以使用--force强制执行
只要是基于yaml文件创建的的都可以导出
kubectl get svc nginx-service -o yaml > /opt/service.yaml
#基于已有的yaml文件生成基于yaml文件创建的pod也都可以导出
kubectl get pod nginx-6fdbccbdbb-7lkzn -o yaml > /opt/service.yaml
#基于已有的yaml文件生成常见的yaml类型
1、 deployment的yaml文件格式用于部署还有daemonset和statefulser
2、 service的yaml文件用于暴露服务端口
3、 不基于控制器的pod的yaml文件
deployment的yaml文件格式
kubectl explain deployment
#查看deployment详细信息
#只有deployment的API-VERSION版本是apps/v1vim nginx1.yaml
#创建yaml文件apiVersion: apps/v1
#声明api版本的标签
kind: Deployment
#定义资源的类型、角色或者是控制器.例如:service/pod/deployment/job/ingress/daemonset/statefulset
metadata:name: nginx1
#定义创建资源名称namespace: zyg
#定义命名空间labels:bqb: nginx1
#定义标签名称
#定义创建资源的元数据信息。例如:资源名称以及资源对象部署的命名空间也可以在这里声明、标签等等信息
spec:
#定义deployment资源需要的参数和属性replicas: 3
#定义副本数selector:
#定义标签选择器。属于哪个标签。满足哪个标签的资源定义副本数为3matchLabels:bqb: nginx1
#选择匹配的标签需要和上面定义的标签完全对应template:
#定义业务的模板。如果定义了多个副本，那么所有的副本属性都会按照模板的配置进行匹配。副本使用的配置是>哪些。metadata:labels:bqb: nginx1
#定义了pod的副本都使用元数据的标签和属性来进行匹配spec:containers:- name: nginximage: nginx:1.10ports:- containerPort: 80
#声明容器的相关参数。包括：容器的命名/容器的版本/容器的暴露端口号。
#虽然这里指定了暴露端口号是80，nginx镜像默认端口就是80.
#即使定义了别的端口，也不会改变容器的默认端口。
#如果不是默认端口，则需要在这里声明端口号
# ports:
# - containerPort: 80
service的yaml文件
kubectl explain service
#查看service详细信息vim nginx-service.yaml#定义API版本：
apiVersion: v1
kind: Service
metadata:name: nginx-servicenamespace: zyglabels:bqb: nginx1
#元数据信息包括：service的名称，所属的命名空间。以及要匹配的deployment的标签。要和之前的保持一致
spec:type: NodePortports:- port: 80
#定义service内部暴露的端口targetPort: 80
#定义容器对外暴露的端口nodePort: 30000
#定义外部端口如果有需要可以直接定义selector:bqb: nginx1
#这里的标签是为了匹配所有的标签都是bqb: nginx1的pod的后端提供服务kubectl apply -f nginx-service.yaml
kubectl get svc -n zyg
pod的yaml文件
kubectl explain pod
#查看pod详细信息vim nginx-pod.yaml#定义pod的apiVersion
apiVersion: v1
#定义资源的类型
kind: Pod
#定义元数据信息，pod的名称/所属的命名空间/标签等信息
metadata:name: centos1namespace: zyg
#定义运行在哪个命名空间
spec:restartPolicy: Never
#pod内的容器如果启动失败或者有问题时的重启策略
#Always：永不重启/Never：从不重启/Onfailure：只有异常退出才会重启。状态码非0则重启.如果状态码是0则不重启
#restartPolicy：是容器的重启策略。
#如果资源类型定义为deployment这个容器的重启策略只能是Always。不写默认是Alwayscontainers:- name: centosimage: centos:7kubectl apply -f nginx-pod.yaml
kubectl get pods -n zygrestartPolicy的三种状态码
pod内的容器如果启动失败或者有问题时的重启策略
Always：一直重启
Never：从不重启
Onfailure：只有异常退出才会重启。状态码非0则重启.如果状态码是0则不重启
command和args
command、args定义容器运行的命令参数。类似于docker中的CMD和entrypoint
command、arges只能存在一个。args可以给command传参
containers:- name: centosimage: centos:7command: ["echo"]args: ["hello,world!"]
#启动时候默认执行的命令
#args可以给command传参类似于(CMD和entrypoint)
#如果在yaml文件中定义了输出内容，就会覆盖掉原来容器内部的标准输出command和args都会覆盖原容器的标准输出(CMD和entrypoint)
args的写法
例如：
写法1：
containers:- name: centosimage: centos:7args: - /bin/bash
#默认执行的shell- -c
#表示命令行- while true; do sleep 3600; done
#执行的命令，多个命令需要用分号隔开写法2：containers:- name: centosimage: centos:7args: ["/bin/bash", "-c", "touch /opt/123.txt; echo 123 > /opt/123.txt; sleep 3600"]
#在一行定义多个内容需要用逗号隔开。多个命令需要用分号隔开
#执行多个命令必须要加"/bin/bash", "-c"
#-c：表示输出命令的格式kubectl exec -it centos1 -n zyg -- cat /opt/123.txt
#使用--可以直接在容器外部查看容器内部的信息command写法
写法1：containers:- name: centosimage: centos:7command: ["/bin/bash", "-c", "touch /opt/123.txt; echo 123 > /opt/123.txt; sleep 3600"]
#在一行定义多个内容需要用逗号隔开。多个命令需要用分号隔开
#执行多个命令必须要加"/bin/bash", "-c"写法2：containers:- name: centosimage: centos:7command: ["/usr/bin/test", "-e", "/etc/passwd"]
#这样的格式只能执行单个命令。需要加上绝对路径command和args的总结
同一个yaml文件内command和args只能存在一个表示容器启动时的命令
除非需要传参的时候command和args可以同时出现
无论是args或者是command都会覆盖CMD和entrypoint标准输出
建议写在一行提高可读性
总结
1、 三种发布方式
蓝绿发布、灰度发布(目前最常用)、滚动发布(基于deployment默认的发布模式)
灰度发布(目前最常用)：基于deployment的滚动发布，使用了暂停的机制。pause(暂停)/resume(继续)。只有所有升级完毕之后才可以回滚
2、 三种yaml文件类型
1、 deployment的yaml文件格式用于部署还有daemonset和statefulser
2、 service的yaml文件用于暴露服务端口
3、 不基于控制器的pod的yaml文件
yaml文件内的模板模块：
deployment类型
apiVersion模块：apps/v1。只有deployment是apps/v1
kind模块：所有的类型都是由kind声明
在kind之后生成
kind之后的第一个字母需要大写
metadata模块：这一部分中namespace(命名空间)需要已经存在，否则不会自动创建。需要手动创建。
spec模块：定义副本数、标签选择器等信息
template模块：定义了业务模板需要和之前的标签保持一致
spec模块：这里的spec属于业务模板模块。这里定义的是容器的信息。定义容器名称，定义镜像版本。也可以指定容器的暴露端口。
但是需要注意。如果容器的默认端口没有修改。yaml文件中定义暴露端口不会生效。所以如果是默认的服务可以不加定义端口
service类型
apiVersion模块：v1
spec模块：中port是service的暴露端口，targetPort是容器的暴露端口。
tpye模块：的类型
pod类型
apiVersion模块：v1
spec模块：这一模块中的 restartPolicy定义pod内的容器如果启动失败或者有问题时的重启策略 Always：一直重启
Never模块：从不重启
Onfailure：只有异常退出才会重启。状态码非0则重启.如果状态码是0则不重启
restartPolicy：是容器的重启策略。
如果资源类型定义为deployment这个容器的重启策略只能是Always。不写默认是Always
command和args
同一个yaml文件内command和args只能存在一个表示容器启动时的命令，不要同时出现
除非需要传参的时候可以同时出现
无论是args或者是command都会覆盖CMD和entrypoint标准输出
建议写在一行提高可读性
