apiVersion
查看可用的apiversion命令：kubectl api-versions
k8s官方将apiversion分成了三个大类型，alpha、beta、stable。
Alpha: 未经充分测试，可能存在bug，功能可能随时调整或删除。
Beta: 经过充分测试，功能细节可能会在未来进行修改。
Stable: 稳定版本，将会得到持续支持。
常用apiversion:
v1： Kubernetes API的稳定版本，包含很多核心对象：pod、service等。
apps/v1： 包含一些通用的应用层的api组合，如：Deployments, RollingUpdates, ReplicaSets, Daemonset。
batch/v1： 包含与批处理和类似作业的任务相关的对象，如：job、cronjob。
autoscaling/v1： 允许根据不同的资源使用指标自动调整容器。
添加apiVersion库：
vim /etc/kubernetes/manifests/kube-apiserver.yaml
在yaml文件中command指令下添加:
- --runtime-config=batch/v2alpha1=true
然后重启kubelet服务，重新识别api yaml文件内容即可。
systemctl restart kubelet
kubectl api-versions
===========================================
Job资源对象:
服务类的Pod容器：RC、RS、DS、Deployment（Pod内运行的服务，要持续运行）
工作类的Pod容器：Job--->执行一次，或者批量执行处理程序，完成之后退出容器。
特殊说明：
spec.template格式同Pod
restartPolicy仅支持Never或onFailure
单个Pod时，默认Pod成功运行后Job即结束
.spec.completions标志Job结束需要成功运行的Pod个数，默认为1
.spec.parallelism标志并行运行的Pod的个数，默认为1
.spec.activeDeadlineSeconds标志失败Pod的重试最大时间，超时间不会继续重试
举例：
运行job，计算2000位的圆周率
---yaml kind: Job apiVersion: batch/v1 metadata: name: pi spec: template: metadata: name: pi spec: containers: - name: pi image: perl imagePullPolicy: IfNotPresent command: ["perl","-Mbignum=bpi","-wle","print bpi(2000)"] restartPolicy: Never
查看容器日志结果：
kubectl logs -f pi-j5j4n
运行job，发送简单信息
---yaml kind: Job apiVersion: batch/v1 metadata: name: test-job spec: template: metadata: name: test-job spec: containers: - name: hello image: busybox imagePullPolicy: IfNotPresent command: ["echo","hello k8s job!"] restartPolicy: Never
注意，如果容器内执行任务有误，会根据容器的重启策略操作容器，不过这里的容器重启策略只能是： Never和 OnFailure。
提高Job的执行效率:
我们可以在Job.spec字段下加上**parallelism**选项。表示同时运行多少个Pod执行任务。
我们可以在Job.spec字段下加上**completions**选项。表示总共需要完成Pod的数量。
举例将上述Job任务进行更改。提示，更改Job任务的时候，需要先将原来的Job资源对象删除
PS:
---yaml kind: Job apiVersion: batch/v1 metadata: name: test-job1 spec: parallelism: 2 completions: 8 template: metadata: name: test-job spec: containers: - name: hello image: busybox imagePullPolicy: IfNotPresent command: ["echo","hello k8s job!"] restartPolicy: Never
Job的作用，与我们之前接触过的at有些类似，在k8s集群中，如果需要用到运行一次性工作任务的需
求，那么，就可以考虑使用Job资源对象。
工作类资源对象不仅只有一个Job，还有一个和crontab十分相像的cronJob.
------------------------------------
CronJob
管理基于时间的Job,即：
在给定时间点只运行一次
周期性地在给定时间点运行
典型用法：
在给定的时间点调度Job运行
创建周期性运行的Job，例如：数据库备份、发送邮件
CronJob Spec
.spec.schedule:调度，必需字段，指定任务运行周期
.spec.jobTemplate:Job模板，必需字段，指定需要运行的任务，格式同job
.spec.startingDeadlineSeconds:启动Job的期限（秒级别），该字段是可选的。如果因为任何原因
而错过了被调度的时间，那么错过执行时间的job将被认为是失败的。如果没有指定，则没有期限。
.sec.concurrencyPolicy: 并发策略，该字段也是可选的。它指定了如何处理CronJob创建的Job的并发执行。
只允许指定下面策略中的一种：
Allow (默认)：允许并发job
Forbid: 禁止并发运行，如果前一个还没有完成，则直接跳过下一个
Replace: 取消当前正在运行的job，用一个新的来替换
.spec.suspend: 挂起，该字段也是可选的，如果设置为true,后续所有执行都会被挂起，它对开始执行的job
不起作用。默认值为false。
.spec.successfulJobsHistoryLimit和.spec.failedJobsHistoryLimit: 历史限制，可选字段，它们指定了可
以保留多少完成和失败的job。默认设置为3和1，如果值为0，相关类型的job完成后不被保留。
---yaml kind: CronJob apiVersion: batch/v1beta1 metadata: name: hello spec: schedule: "*/1 * * * *" jobTemplate: spec: template: spec: containers: - name: hello image: busybox imagePullPolicy: IfNotPresent command: ["echo","hello cronjob!"] restartPolicy: OnFailure 此时查看Pod的状态，会发现，每分钟都会运行一个新的Pod来执行命令规定的任务。 K8s存储
Volume: 数据卷
kubernetes Pod中多个容器访问的共享目录。volume被定义在pod上，被这个pod的多个容器
挂载到相同或不同的路径下。volume的生命周期与pod的生命周期相同，pod内的容器停止和
重启时一般不会影响volume中的数据。所以一般volume被用于持久化pod产生的数据。
volume类型：
emptyDir hostPath gcePersistentDisk awsElasticBlockStore nfs iscsi flocker glusterfs rbd cephfs gitRepo secret persistentVolumeClaim downwardAPI azureFileVolume azureDisk vsphereVolume Quobyte -----------------------------------------
emptyDir:
emptyDir的生命周期与所属的pod相同。
pod删除时，其emptyDir中的数据也会被删除。
emptyDir类型的volume在pod分配到node上时被创建，kubernetes会在node上自动分配一个目录，因此无需指定宿主机node上对应的目录文件。
emptyDir Volume主要用于某些应用程序无需永久保存的临时目录，多个容器的共享目录等。
注：一般用于容器数据卷共享，不能做持久化数据存储。
//写一个emptyDir.yaml的文件。
---yaml kind: Pod apiVersion: v1 metadata: name: producer-consumer spec: containers: - name: producer image: busybox imagePullPolicy: IfNotPresent volumeMounts: - mountPath: /producer_dir name: shared-volume args: - /bin/sh - -c - echo "hello world" > /producer_dir/hello.txt ; sleep 30000 - name: consumer image: busybox imagePullPolicy: IfNotPresent volumeMounts: - mountPath: /consumer_dir name: shared-volume args: - /bin/sh - -c - cat /consumer_dir/hello.txt ;sleep 30000 volumes: - name: shared-volume emptyDir: {}
总结：
根据上述yaml文件分析，volumes是指k8s的存储方案.容器内volumeMounts使用的是volumes内定义的存储，所以现在可以理解为,volumes定义的dockerHost上的目录或文件，分别挂载到了producer(/producer_dir)和consumer(/consumer_dir)这个两个容器的对应目录。那么安装这个方法，我们可以判断出，在consumer这个容器的/consumer_dir目录下，应该也会有一个hello.txt的文件。
//验证，查看conumer容器的日志。
[root@master volume]# kubectl logs producer-consumer consumer
hello world
//查看一个Pod运行在了那个Node节点上
[root@master volume]# kubectl get pod -o wide
//到对应Node节点上查看该容器的详细信息（Mounts）
[root@node01 ~]# docker inspect 413d5dbd0239 ... "Mounts": [ { "Type": "bind", "Source": "/var/lib/kubelet/pods/82a382ce-78aa-48f1-933b-685ce2ba7a3d/volumes/kubernetes.io~empty-dir/shared-volume", "Destination": "/producer_dir", "Mode": "", "RW": true, "Propagation": "rprivate" },
PS: 查看到该容器的Mounts字段，等于是运行docker容器的时候使用这么一条命令：
docker run -v /producer_dir busybox
emptyDir的使用场景：如果Pod的被删除，那么数据也会被删除，不具备持久化。Pod内的容器，需要
共享数据卷的时候，使用的临时数据卷。
-----------------------------------------
HostPath
hostPath卷将主机节点的文件系统中的文件或目录挂载到集群中。
相对于emtpyDir来说，hostPath就等于运行容器是使用的命令：
docker run -v /host/path:/container/path
除了path属性之外，用户还可以指定type：
空 空字符串（默认），挂载hostPath卷之前不会执行任何检查
DirectoryOrCreate 如果指定的位置没有目录，将创建空目录，权限755，与kubelet具有相同的所有权
Directory 指定的位置必须存在目录
FileOrCreate 如果指定的位置没有文件，将创建空文件，权限644，与kubelet具有相同的所有权
File 指定的位置必须存在文件
Socket 指定的位置必须存在Unix套接字
CharDevice 指定的位置必须存在字符设备
BlockDevice 指定的路径下必须存在块设备
//这里没有创建新的yaml文件，直接将emptyDir.yaml文件的volumes字段更改为:hostPath. [root@node01 volume]# ... volumes: - name: shared-volume hostPath: path: "/data/hostPath" type: DirectoryOrCreate
注：对比emptyDIR，hostPath具有持久性：即容器删除，数据卷还在
=================================
PV、PVC
PV: Persistent(持久的、稳固的)Volume
由管理员设置的存储，是集群的一部分，就像node节点一样，PV也是集群的资源。PV是volume之类的卷插件，但独立于使用PV的pod的生命周期。此api对象包含存储实现的细节，即nfs、iscsi、ceph或云存储等。
是k8s集群的外部存储系统，一般是设定好的存储空间（文件系统中的一个目录）。
PVC: PersistentvolumeClaim(声明、申请)
是用户存储的请求，它与pod相似。pod消耗节点资源，PVC消耗PV资源。pod可以请求特定级别的资源（CPU和内存）。声明可以请求特定的大小和访问模式（只读/读写）。
如果应用需要用到持久化的时候，可以直接向PV申请空间。
基于NFS服务来创建的PV：
//3台节点都安装nfs-工具包和rpc-bind服务。
[root@master ~]# yum install nfs-utils rpcbind -y
//这里准备将NFS服务部署在master节点上，需要在master节点上提前规划好共享的目录
[root@master ~]# mkdir /nfsdata [root@master ~]# vim /etc/exports /nfsdata *(rw,sync,no_root_squash) [root@master ~]# systemctl start rpcbind [root@master ~]# systemctl enable rpcbind [root@master ~]# systemctl start nfs-server [root@master ~]# systemctl enable nfs-server [root@master ~]# showmount -e
//创建pv1.yaml文件
---yaml kind: PersistentVolume apiVersion: v1 metadata: name: pv1 spec: capacity: storage: 1Gi accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Recycle storageClassName: nfs nfs: path: /nfsdata server: 192.168.8.10
PV所支持的访问模式：
ReadWriteOnce： PV能以read-write的模式mount到单个节点。（命令模式：RWO）
ReadOnlyMany: PV能以read-only 的模式mount到多个节点。(命令模式：ROX)
ReadWriteMany: PV能以read-write的模式Mount到多个节点。（命令模式：RWX）
PV状态：
Available(可用)：一块空闲资源还没有被任何声明绑定
Bound(绑定)：卷已经被声明绑定
Released(已释放)：声明被删除，但是资源还未被集群重新声明
Failed（失败）：该卷的自动回收失败
PV空间的回收策略：persistentVolumeReclaimPolicy
Recycle: 回收，会清除数据，自动回收（最新k8s版本已不支持）。
Retain: 保留，需要手动清理回收。
Delete: 删除，关联的存储资产（AWS EBS,GCE PD,Azure Disk和Openstack Cinder卷）将被删除
注：只有nfs和hostPath支持回收策略，AWS EBS,GCE PD,Azure Disk和Cinder支持删除策略
关于pv所支持的访问模式的理解：
读写方面： 如果是可以读写的，则认为，Pod可以在挂载的路径下，执行读写操作。如果是只读的，那么Pod就只能够读取PV共享目录下的数据了。
节点方面：所谓挂载到单个或者多个节点，指的是Kuberntes的工作节点（node节点）
验证结果（不完全正确）：
1）kubernetes官方表示，ReadOnly是以只读的方式挂载，但实际的验证结果仍需要在挂载时指定其挂
载类型为ReadOnly: true，才可以实现只读。
2）这里所说的挂载至单节点或多节点，和官方描述不一致。具体实现方法，有待进一步验证。
官网描述: https://kubernetes.io/docs/concepts/storage/persistent-volumes/#access-modes
重要提醒！
每个卷只能同一时刻只能以一种访问模式挂载，即使该卷能够支持 多种访问模式。例如，一个 GCEPersistentDisk 卷可以被某节点以 ReadWriteOnce 模式挂载，或者被多个节点以ReadOnlyMany 模式挂载，但不可以同时以两种模式挂载。
//创建一个PVC，向刚才的PV申请使用空间，注意，这里PV与PVC的绑定，通过storageClassName和accessModes这两个字段共同决定。
---yaml kind: PersistentVolumeClaim apiVersion: v1 metadata: name: pvc1 spec: accessModes: - ReadWriteOnce storageClassName: nfs resources: requests: storage: 1Gi
总结：
1. 当系统中的pv被绑定之后，就不会被其他的PVC绑定了。
2. 如果系统中有多个能够满足pvc要求的pv，那么，系统会自动选择一个符合pvc申请空间大小的PV，进行绑定，尽量不浪费存储空间。
//创建一个Pod，来使用上述PVC。
kind: Pod apiVersion: v1 metadata: name: pod1 spec: containers: - name: pod1 image: busybox imagePullPolicy: IfNotPresent args: - /bin/sh - -c - sleep 30000 volumeMounts: - mountPath: "/data" name: mydata volumes: - name: mydata persistentVolumeClaim: claimName: pvc1 =======================================
PV的空间回收
当回收策略为recycle
[root@master ~]# kubectl get pv,pvc
// 验证dockerhost上PV上存放的数据
[root@master ~]# ls /nfsdata/
test.txt
//删除Pd资源，PVC
[root@master ~]# kubectl delete pod pod1 pod "pod1" deleted [root@master ~]# kubectl delete pvc pvc1 persistentvolumeclaim "pvc1" deleted
//查看PV的过程,Released（释放）--->Available（可用）。
[root@master ~]# kubectl get pv
//验证，数据依然被删除
[root@master ~]# ls /nfsdata
无数据
PS: 在释放空间的过程中，其实K8S生成了一个新的Pod，由这个Pod执行删除数据的操作。
-------------------------------------
当回收策略为： Retain
...
persistentVolumeReclaimPolicy: Retain //更改回收策略为保留
//重新运行pvc1,pod资源，然后在Pod内，创建对应的资源，再尝试删除PVC，和Pod，验证PV目录
下，数据是否还会存在？
[root@master ~]# kubectl apply -f pvc1.yaml [root@master ~]# kubectl apply -f pod.yaml [root@master ~]# kubectl exec pod1 touch /data/test.txt [root@master ~]# ls /nfsdata/ test.txt
//再次删除Pod，PVC，验证PV目录下存放的数据
[root@master ~]# kubectl delete pod pod1 [root@master ~]# kubectl delete pvc pvc1 [root@master ~]# ls /nfsdata/ test.txt
//修复状态released为 Available
[root@master ~]# kubectl edit pv pv1
删除 claimRef: 字段
claimRef: apiVersion: v1 kind: PersistentVolumeClaim name: pvc1 namespace: default resourceVersion: "111021" uid: d7ef17f9-ad63-4907-a277-0e172496e1ec ================================================
PV，PVC的运用
现在部署一个MySQL服务，并且将MySQL的数据进行持久化存储。
1、创建PV，PVC
vim mysql-pv.yaml kind: PersistentVolume apiVersion: v1 metadata: name: mysql-pv spec: accessModes: - ReadWriteOnce capacity: storage: 1Gi persistentVolumeReclaimPolicy: Retain storageClassName: nfs nfs: path: /nfsdata/mysql-pv server: 192.168.8.10 vim mysql-pvc.yaml kind: PersistentVolumeClaim apiVersion: v1 metadata: name: mysql-pvc spec: accessModes: - ReadWriteOnce storageClassName: nfs resources: requests: storage: 1Gi [root@master MySQL]# mkdir /nfsdata/mysql-pv [root@master MySQL]# kubectl apply -f mysql-pv.yaml [root@master MySQL]# kubectl apply -f mysql-pvc.yaml [root@master MySQL]# kubectl get pv,pvc
2、部署MySQL
vim mysql.yaml kind: Deployment apiVersion: apps/v1 metadata: name: mysql spec: selector: matchLabels: app: mysql template: metadata: labels: app: mysql spec: containers: - name: mysql image: mysql:5.7 imagePullPolicy: IfNotPresent env: - name: MYSQL_ROOT_PASSWORD value: 123.com volumeMounts: - name: mysql-storage mountPath: /var/lib/mysql volumes: - name: mysql-storage persistentVolumeClaim: claimName: mysql-pvc --- kind: Service apiVersion: v1 metadata: name: mysql spec: type: NodePort selector: app: mysql ports: - port: 3306 targetPort: 3306 nodePort: 31306
3、在MySQL数据库中添加数据
[root@master ~]# kubectl exec -it mysql-6fccccd487-5q2dt -- mysql -uroot -p123.com mysql> SHOW DATABASES; //查看当前的库。 mysql> CREATE DATABASE TEST; //创建test库。 mysql> USE TEST; //选择使用test库。 mysql> CREATE TABLE my_id(id int(4)); //创建my_id表 mysql> INSERT my_id values (9527); //往my_id表中，插入数据。 mysql> SELECT * FROM my_id; //查看my_id表中所有数据
4、模拟MySQ服务器节点故障
k8s集群会生产一个新的Pod，验证这个Pod内是否有之前数据。
//先查看运行MySQL服务的Pod，在哪个节点，然后将该节点挂起，我们知道k8s肯定会在另外一个节点重新生成一个Pod
[root@master ~]# kubectl get pod -o wide
//新生成Pod后，同样进入Pod验证数据是否会会存在，
[root@master MySQL]# kubectl exec -it mysql-5d86c64fc9-p7hv6 -- mysql -u root -p123.com mysql> show databases; mysql> use TEST; mysql> show tables; mysql> select * from my_id;
