k8s中所有的内容都抽象为资源， 资源实例化之后，叫做对象。
一、对象类型介绍：
工作负载型资源对象（workload）：POD，ReplicaSet，Deployment，StatefulSet，DaemonSet，Job，Cronjob ...
服务发现及均衡资源对象：Service，Ingress ...
配置与存储资源对象：Volume(存储卷)，CSI(容器存储接口,可以扩展各种各样的第三方存储卷)，ConfigMap，Secret，DownwardAPI
集群级资源：Namespace，Node，Role，ClusterRole，RoleBinding，ClusterRoleBinding
元数据型资源：HPA，PodTemplate，LimitRange
二、资源清单
1、查看资源清单：
kubectl get pod name -o yaml
2、资源清单简介：
Apiserver仅接收JSON格式的资源定义（一般使用yaml格式提供配置清单apiserver可自动将其转为json格式，而后再提交），大部分资源的配置清单都由五个一级字段组成：
- apiVersion: group/apiversion
如果没有给定group名称，那么默认为croe，可以使用kubectl api-versions 获取当前k8s版本上所有的apiVersion版本信息(每个版本可能不同)
查看：
kubectl api-versions
kind：资源类别
metadata：资源元数据
name：（metadata中的name字段在同一类型中必须是唯一的）
namespace：命名空间
labels：标签（键值数据）
annotations：资源注解spec：资源期望的状态
status：当前状态，该字段由k8s集群维护，用户不能对其进行修改。
其中spec重点介绍一下：
spec.containers.name ： pod的名称，必须字段，名称唯一且对象创建后不可以被修改
spec.containers.image ：镜像仓库的路径/镜像的名称( 镜像的标签 )
spec.containers.image.imagePullPolicy ：镜像下载策略( Always：总是去仓库下载；Never：从不去仓库下载；IfNotPresent：如果本地没有就
去仓库下载。默认是"IfNotPresent" 但是，如果镜像的标签是latest，则总会是"Always，并且对象一旦被创建，这个字段不允许被改变）
spec.containers.ports：容器公开的端口列表。在这里公开端口可以为系统提供关于容器使用的网络连接的额外信息，但主要是提供信息。在这
里不指定端口不会阻止该端口被公开。任何监听容器内默认的“0.0.0.0”地址的端口都可以从网络访问
spec.containers.ports.containerPort：暴露的端口，此端口仅是额外的信息，对端口是否被暴露没有影响
spec.containers.ports.hostPort：主机上公开的端口
spec.containers.ports.protocol：端口的协议
spec.containers.ports.hostIP：指定要绑定的主机
spec.containers.command：运行的程序，类似于docker中的entrypiont,并且这里的命令不会运行在shell中，如果没有这个字段docker镜像会
运行自己entrypiont中的指令
spec.containers.args：向docker镜像中传递参数 如果定义了这个字段，docker镜像中cmd命令不会被执行，如果引用变量使
用$(VAR_NAME)格式引用，如果想使用命令引用的的方式，需要使用$$(VAR_NAME)方式来引用
spec.containers.volumeMounts.mountPath：可以被容器挂载的存储卷的路径，路径不能包含':' 符号
spec.containers.volumeMounts.subPath：可以被容器挂载的存储卷的路径，并且不会覆盖挂载点中的文件
spec.containers.volumeMounts.readOnly：是否只读，默认为false
spec.containers.resources.limits：资源限制
spec.containers.resources.limits.cpu ：CPU 上限， 可以短暂超过， 容器也不会被停止
spec.containers.resources.limits.memory：内存上限， 不可以超过； 如果超过， 容器可能会被终止或调度到其他资源充足的机器上
spec.containers.resources.requests：资源需求
spec.containers.resources.requests.cpu：CPU 请求， 也是调度 CPU 资源的依据， 可以超过
spec.containers.resources.requests.memory：内存请求， 也是调度内存资源的依据， 可以超过； 但如果超过， 容器可能会在 Node
内存不足时清理。
spec.nodeSelector：指定对象的调度节点,节点必须存在。
spec.restartPolicy：容器的重启策略。有三种Always(只要退出就重启)，OnFailure(状态为错误时重启)，Never(从不重启)，kubelet重新启动的已退出容器将以指数退避延迟（10秒，20秒，40秒......）重新启动，上限为五分钟，并在成功执行十分钟后重置
3、创建资源配置清单：
通过资源配置清单创建POD
kubectl create -f /test-list/lyq-pod-test.yaml
获取pod信息：
对与配置清单创建的POD我们可以这样进行删除
kubectl delete -f /test-list/lyq-pod-test.yaml
4、错误处理
有时创建的Pod可能会出现问题：
这时，我们可以使用 kubectl logs name，来查询问题原因
如果我们需要进入pod进行排错，我们可以使用(比如进入nginx)
kubectl exec -it lyq-pod-test -c nginx -- bin/sh
三、POD标签
我们可以使用命令给Pod资源打上标签，方便使用：Kubectl label pods pod名字 标签
如：
kubectl label pods lyq-pod release=canary
通过标签我们可以是实现对POD资源的查询：
1、kubectl get pods -l release=canary 查询release标签等于canary的Pod
2、kubectl get pods -l release,app 查询有release标签和app标签的Pod
3、kubectl get pods -l “release in (canary,beta,alpha)” 查询release标签等于"canary"或"beta"或"alpha"的Pod
4、kubectl get pods -l “release notin (canary,beta,alpha)” 查询release标签不为"canary"或"beta"或"alpha"的Pod
四、POD的生命周期中的重要行为及常见状态
Pod的生命周期中主要有以下两个比较重要的行为：
1、使用初始化容器完成初始化
2、容器探测（liveness：探测容器是否处于存活状态；readiness：探测容器中程序是否能正常提供服务）
探针的类型主要分为以下两种：
1、存活性探针：针对liveness
2、就绪性探针：针对readiness
存活性探针：
apiVersion: v1
kind: Pod
metadata:
name: liveness-httpget-pod
spec:
containers:
- name: liveness-httpget-pod
image: ikubernetes/myapp:v1
imagePullPolicy: IfNotPresent
livenessProbe:
httpGet:
port: 80
path: /index.html
initialDelaySeconds: 2
periodSeconds: 5
就绪性探针：
apiVersion: v1
kind: Pod
metadata:
name: readiness-httpget-pod
spec:
containers:
- name: readiness-httpget-pod
image: ikubernetes/myapp:v1
imagePullPolicy: IfNotPresent
readinessProbe:
httpGet:
port: 80
path: /index.html
initialDelaySeconds: 2
periodSeconds: 5
常见的POD状态：
Pending： 挂起（POD已创建但是没有适合运行的节点）
Running：运行中
Failed：失败
参考资料：
《每天5分钟玩转Kubernetes》
《黑马k8s集群技术》
