污点通常情况下是作用在worker节点上，其可以影响Pod的调度。

污点的语法格式如下:

key[=value]:effect

配置污点容忍，则容器可以调度到具有该污点的节点

tolerations:

若key不定义，则表示匹配所有的key值。

key: school

value: oldboyedu

operator表示key和value之间的关系，有效值为: Exists(存在),Equal(等于).默认值为"Equal"

若operator的值为Exists，value的值必须为空，表示只要存在school这个KEY，默认匹配所有的值。

operator: Equal

key: node-role.kubernetes.io/master

operator: Exists

注意，effect若不配置，则默认匹配所有的污点类型

若指定，则有效值为: NoSchedule,PreferNoSchedule,NoExecute

effect: NoSchedule

containers:

name: linux82-web

image: k8s151.oldboyedu.com:5000/oldboyedu-web/nginx:1.20.1

[root@k8s151.oldboyedu.com deploy]#

亲和性(affinity)概述

节点亲和性(nodeAffinity):

用于控制Pod调度到哪些worker节点上，以及不能部署在哪些机器上。

Pod亲和性(podAffinity):

Pod可以和哪些Pod部署在同一个拓扑域。

Pod反亲和性(podAntiAffinity):

Pod可以和哪些Pod部署在不同一个拓扑域。

节点亲和性(nodeAffinity)

(1)worker节点打标签

kubectl label nodes k8s151.oldboyedu.com school=oldboyedu

kubectl label nodes k8s152.oldboyedu.com school=yitiantian

kubectl label nodes k8s151.oldboyedu.com class=linux82

kubectl label nodes k8s152.oldboyedu.com class=jiaoshi05

kubectl get no --show-labels

(2)创建资源清单

cat > 05-pods-nodeAffinity.yaml <<'EOF'

apiVersion: extensions/v1beta1

kind: Deployment

metadata:

labels:

school: oldboyedue

spec:

replicas: 10

template:

metadata:

labels:

apps: web

spec:

容忍污点

tolerations:

operator: Exists

亲和性

affinity:

节点亲和性

nodeAffinity:

硬限制，必须满足的条件

requiredDuringSchedulingIgnoredDuringExecution:

定义节点选择器列表

nodeSelectorTerms:

基于节点的标签进行关联

matchExpressions:
key: class

operator: NotIn

values:

linux82
jiaoshi05

软限制，不一定要满足，但会优先满足，相当于提高了调度的优先级

preferredDuringSchedulingIgnoredDuringExecution:

配置权重

weight: 10

偏向性

preference:

基于节点的标签进行关联

matchExpressions:

表示节点的标签名称

key: school

关联关系，表示key和values的关系

In

包含，要求values字段不能为空。

NotIn

不包含，要求values字段不能为空。

Exists

存在，要求values字段必须为空。

DoesNotExist

不存在，要求values字段必须为空。

Gt

大于，要求values字段必须是一个单一的元素，且值将被解释为整数。

Lt

小于，要求values字段必须是一个单一的元素，且值将被解释为整数。

operator: In

定义标签的值

values:

"oldboyedu"
"yitiantian"
"laonanhai"

containers:

name: linux82-web

image: k8s151.oldboyedu.com:5000/oldboyedu-web/nginx:1.20.1

EOF

Pod亲和性(podAffinity):

cat > 06-pods-podAffinity.yaml <<'EOF'

apiVersion: extensions/v1beta1

kind: Deployment

metadata:

spec:

replicas: 20

selector:

matchLabels:

apps: oldboyedu-web

template:

metadata:

labels:

apps: oldboyedu-web

spec:

tolerations:

operator: Exists

affinity:

定义Pod的亲和性

podAffinity:

定义硬限制

requiredDuringSchedulingIgnoredDuringExecution:

指定的拓扑域为"kubernetes.io/hostname"时:

就会发现所有的Pod被调度到同一个节点的现象，这是因为所有的node节点key其values值不同导致的。

指定的拓扑域为"beta.kubernetes.io/os"时:

就会发现所有的Pod被调度到不同的节点，这是因为所有的node节点的key其values值相同。

- topologyKey: kubernetes.io/hostname

topologyKey: beta.kubernetes.io/os

值得注意的是，如果有的节点没有school这个key，在K8S 1.15.12版本中测试发现，有可能会调度到没有school的KEY节点哟!

- topologyKey: school

注意，上面的topologyKey拓扑域并不能立刻确定Pod应该调度到哪个节点，

因为可能选择较多(即节点的key相同value不相同的情况)，所以需要借助pod的标签选择器进行再次确认!

labelSelector:

matchExpressions:

此处的KEY并非是node的标签，而是pods的标签哟~

key: apps

注意，如果Pod出现了key值相同，但value不相同的标签，这个时候不建议使用Exists

而是建设设置白名单，即采用"operator: In"的方式进行匹配，当然此时values不能为空。

operator: Exists

containers:

name: linux82-web

image: k8s151.oldboyedu.com:5000/oldboyedu-web/nginx:1.20.1

EOF

Pod反亲和性(podAntiAffinity):

cat > 07-podAntiAffinity <<'EOF'

apiVersion: extensions/v1beta1

kind: Deployment

metadata:

spec:

replicas: 10

selector:

matchLabels:

apps: oldboyedu-web

template:

metadata:

labels:

apps: oldboyedu-web

spec:

tolerations:

operator: Exists

affinity:

定义Pod的反亲和性

podAntiAffinity:

requiredDuringSchedulingIgnoredDuringExecution:

topologyKey: kubernetes.io/hostname

labelSelector:

matchExpressions:

key: apps

values:

oldboyedu-web

operator: In

containers:

name: linux82-web

image: k8s151.oldboyedu.com:5000/oldboyedu-web/nginx:1.20.1

EOF

节点选择器nodeSelector:

1.节点打标签

kubectl label nodes --all --overwrite school=oldboyedu

kubectl label nodes k8s152.oldboyedu.com school-

2.创建资源清单

cat > 08-pods-nodeSelector.yaml <<'EOF'

apiVersion: extensions/v1beta1

kind: Deployment

metadata:

spec:

replicas: 10

selector:

matchLabels:

apps: oldboyedu-web

template:

metadata:

labels:

apps: oldboyedu-web

spec:

tolerations:

operator: Exists

将Pod调度到包含特定标签的节点

nodeSelector:

school: oldboyedu

containers:

name: ds-web-linux82

image: k8s151.oldboyedu.com:5000/oldboyedu-web/nginx:1.20.1

EOF

Job概述:

一次性任务，Pod完成作业后并不重启容器。其重启策略为"restartPolicy: Never"

Job控制器参考案例：

cat > 01-job.yaml <<EOF

apiVersion: batch/v1

kind: Job

metadata:

spec:

template:

spec:

containers:

name: pi

image: perl:5.34

它计算π到2000个位置并打印出来。大约需要10秒才能完成。

command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]

command:

"/bin/sh"
"-c"
"for ((i=0;i<3600;i++)); do echo $i > /dev/stdout; sleep 1 ;done"

注意，此处的重启策略表示容器退出时是否重新创建，但手动杀死容器，发现依旧会自动拉起，这是CM组件保证了这个特性。

restartPolicy: Never

指定标记此作业失败之前的重试次数。官方文档说默认值为6次，但实际测试为7次。

此处我指定为2次，表示容器启动失败时，会尝试重新启动新的Pod次数为2.

backoffLimit: 2

EOF

CronJob概述:

周期性任务，CronJob底层逻辑是周期性创建Job控制器来实现周期性任务的。

CronJob控制器参考案例:

cat > cronjob.yaml <<'EOF'

apiVersion: batch/v1beta1

kind: CronJob

metadata:

spec:

定义调度格式，参考链接：https://en.wikipedia.org/wiki/Cron

┌───────────── 分钟 (0 - 59)

│ ┌───────────── 小时 (0 - 23)

│ │ ┌───────────── 月的某天 (1 - 31)

│ │ │ ┌───────────── 月份 (1 - 12)

│ │ │ │ ┌───────────── 周的某天 (0 - 6)（周日到周一；在某些系统上，7 也是星期日）

│ │ │ │ │ 或者是 sun，mon，tue，web，thu，fri，sat

│ │ │ │ │

* * * * *

schedule: "* * * * *"

jobTemplate:

spec:

template:

spec:

containers:

name: hello

image: k8s151.oldboyedu.com:5000/oldboyedu-linux/busybox:1.28

imagePullPolicy: IfNotPresent

command:

/bin/sh
-c
date; echo Hello from the oldboyedu linux82 Kubernetes cluster

restartPolicy: OnFailure

EOF

DaemonSet概述：

DaemonSet确保全部worker节点上运行一个Pod的副本，换句话说，在不考虑污点的情况下，保证每个worker节点有且只有一个Pod副本。

DaemonSet的一些典型用法：

(1)在每个节点上运行集群守护进程(flannel等)

(2)在每个节点上运行日志收集守护进程(flume，filebeat，fluentd等)

(3)在每个节点上运行监控守护进程（zabbix agent，node_exportor等）

温馨提示:

(1)当有新节点加入集群时，也会为新节点新增一个Pod;

(2)当有节点从集群移除时，这些Pod也会被回收;

(3)删除DaemonSet将会删除它创建的所有Pod;

(4)如果节点被打了污点的话，且DaemonSet中未定义污点容忍，则Pod并不会被调度到该节点上;("flannel案例")

DaemonSet参考案例:

cat > 01-ds-nginx.yaml <<EOF

kind: DaemonSet

apiVersion: extensions/v1beta1

metadata:

spec:

selector:

matchLabels:

school: oldboyedu

template:

metadata:

labels:

school: oldboyedu

spec:

tolerations:

operator: Exists

containers:

name: linux82-web

image: k8s151.oldboyedu.com:5000/oldboyedu-web/nginx:1.20.1

EOF

StatefulSets概述:

以Nginx的为例，当任意一个Nginx挂掉，其处理的逻辑是相同的，即仅需重新创建一个Pod副本即可，这类服务我们称之为无状态服务。

以MySQL主从同步为例，master，slave两个库任意一个库挂掉，其处理逻辑是不相同的，这类服务我们称之为有状态服务。

有状态服务面临的难题:

(1)启动/停止顺序;

(2)pod实例的数据是独立存储;

(3)需要固定的IP地址或者主机名;

StatefulSet一般用于有状态服务，StatefulSets对于需要满足以下一个或多个需求的应用程序很有价值。

(1)稳定唯一的网络标识符。

(2)稳定独立持久的存储。

(4)有序优雅的部署和缩放。

(5)有序自动的滚动更新。

稳定的网络标识:

其本质对应的是一个service资源，只不过这个service没有定义VIP，我们称之为headless service，即"无头服务"。

通过"headless service"来维护Pod的网络身份，会为每个Pod分配一个数字编号并且按照编号顺序部署。

综上所述，无头服务（"headless service"）要求满足以下两点:

(1)将svc资源的clusterIP字段设置None，即"clusterIP: None";

(2)将sts资源的serviceName字段声明为无头服务的名称;

独享存储:

Statefulset的存储卷使用VolumeClaimTemplate创建，称为"存储卷申请模板"。

当sts资源使用VolumeClaimTemplate创建一个PVC时，同样也会为每个Pod分配并创建唯一的pvc编号，每个pvc绑定对应pv，从而保证每个Pod都有独立的存储。

StatefulSets控制器-网络唯一标识之headless：

(1)编写资源清单

cat > 01-statefulset-headless-network.yaml <<'EOF'

apiVersion: v1

kind: Service

metadata:

spec:

ports:

port: 80

将clusterIP字段设置为None表示为一个无头服务(headless services)，即svc将不会分配VIP。

clusterIP: None

selector:

app: nginx

apiVersion: apps/v1

kind: StatefulSet

metadata:

spec:

selector:

matchLabels:

app: nginx

声明无头服务

serviceName: linux82-headless

replicas: 3

template:

metadata:

labels:

app: nginx

spec:

containers:

name: nginx

image: k8s151.oldboyedu.com:5000/oldboyedu-web/nginx:1.20.1

ports:

containerPort: 80

EOF

(2)使用响应式API创建测试Pod

kubectl run -it dns-test --rm --image=k8s151.oldboyedu.com:5000/oldboyedu-linux/alpine -- sh

for i in `seq 0 2`;do ping linux82-web-${i}.linux82-headless.default.svc.cluster.local -c 3;done

StatefulSets控制器-独享存储

(1)编写资源清单

cat > 02-statefulset-headless-volumeClaimTemplates.yaml <<'EOF'

apiVersion: v1

kind: Service

metadata:

spec:

ports:

port: 80

将clusterIP字段设置为None表示为一个无头服务，即svc将不会分配VIP。

clusterIP: None

selector:

app: nginx

apiVersion: apps/v1

kind: StatefulSet

metadata:

spec:

selector:

matchLabels:

app: nginx

声明无头服务

serviceName: linux82-headless

replicas: 3

卷申请模板，会为每个Pod去创建唯一的pvc并与之关联哟!

volumeClaimTemplates:

metadata:

spec:

accessModes: [ "ReadWriteOnce" ]

声明咱们自定义的动态存储类，即sc资源。

storageClassName: "linux82-sc"

resources:

requests:

storage: 2Gi

template:

metadata:

labels:

app: nginx

spec:

containers:

name: nginx

image: nginx:1.20.1

ports:

containerPort: 80

volumeMounts:

name: data

mountPath: /usr/share/nginx/html

apiVersion: v1

kind: Service

metadata:

spec:

selector:

app: nginx

ports:

port: 80

targetPort: 80

EOF

(2)连接到Pod逐个修改nginx首页文件

kubectl exec -it linux81-web-0 -- bash

echo AAAAAAAAAAAA > /usr/share/nginx/html/index.html

kubectl exec -it linux81-web-1 -- bash

echo BBBBBBBBBBBB > /usr/share/nginx/html/index.html

kubectl exec -it linux81-web-2 -- bash

echo CCCCCCCCCCCC > /usr/share/nginx/html/index.html

(3)测试SVC访问

vim /etc/resolv.conf # 不修改宿主机的配置文件的话，可以直接启动pod进行测试即可。

nameserver 10.254.0.10

curl oldboyedu-linux81-sts.default.svc.cluster.local

持久卷Persistent Volume(简称"PV"):

(1)编写PV资源清单

cat > manual-pv.yaml <<'EOF'

apiVersion: v1

kind: PersistentVolume

metadata:

labels:

school: oldboyedu

spec:

声明PV的访问模式，常用的有"ReadWriteOnce","ReadOnlyMany"和"ReadWriteMany":

ReadWriteOnce:(简称:"RWO")

只允许单个worker节点读写存储卷，但是该节点的多个Pod是可以同时访问该存储卷的。

ReadOnlyMany:(简称:"ROX")

允许多个worker节点进行只读存储卷。

ReadWriteMany:(简称:"RWX")

允许多个worker节点进行读写存储卷。

ReadWriteOncePod:(简称:"RWOP")

该卷可以通过单个Pod以读写方式装入。

如果您想确保整个集群中只有一个pod可以读取或写入PVC，请使用ReadWriteOncePod访问模式。

这仅适用于CSI卷和Kubernetes版本1.22+。

accessModes:

ReadWriteMany

声明存储卷的类型为nfs

nfs:

path: /oldboyedu/data/kubernetes/pv/linux82/pv001

server: 10.0.0.151

指定存储卷的回收策略，常用的有"Retain"和"Delete"

Retain:

"保留回收"策略允许手动回收资源。

删除PersistentVolumeClaim时，PersistentVolume仍然存在，并且该卷被视为"已释放"。

在管理员手动回收资源之前，使用该策略其他Pod将无法直接使用。

Delete:

对于支持删除回收策略的卷插件，k8s将删除pv及其对应的数据卷数据。

Recycle:

对于"回收利用"策略官方已弃用。相反，推荐的方法是使用动态资源调配。

如果基础卷插件支持，回收回收策略将对卷执行基本清理（rm -rf /thevolume/*），并使其再次可用于新的声明。

persistentVolumeReclaimPolicy: Retain

声明存储的容量

capacity:

storage: 2Gi

apiVersion: v1

kind: PersistentVolume

metadata:

labels:

school: oldboyedu

spec:

accessModes:

ReadWriteMany

nfs:

path: /oldboyedu/data/kubernetes/pv/linux82/pv002

server: 10.0.0.151

persistentVolumeReclaimPolicy: Retain

capacity:

storage: 5Gi

apiVersion: v1

kind: PersistentVolume

metadata:

labels:

school: oldboyedu

spec:

accessModes:

ReadWriteMany

nfs:

path: /oldboyedu/data/kubernetes/pv/linux82/pv003

server: 10.0.0.151

persistentVolumeReclaimPolicy: Retain

capacity:

storage: 10Gi

EOF

(2)创建pv

kubectl apply -f manual-pv.yaml

(3)查看pv资源

kubectl get pv

NAME :

pv的名称

CAPACITY :

pv的容量

ACCESS MODES:

pv的访问模式

RECLAIM POLICY:

pv的回收策略。

STATUS :

pv的状态。

CLAIM:

pv被哪个pvc使用。

STORAGECLASS

sc的名称。

REASON

pv出错时的原因。

AGE

创建的时间。

(4)创建PVC对应的nfs挂载路径（如下图所示）

mkdir -pv /oldboyedu/data/kubernetes/pv/linux82/pv00{1..3}

ll -R /oldboyedu/data/kubernetes/pv/linux81

参考链接:

https://kubernetes.io/docs/concepts/storage/persistent-volumes/#access-modes

https://kubernetes.io/docs/concepts/storage/persistent-volumes/#reclaiming

持久卷声明Persistent Volume Claim(简称"PVC")

(1)编写pvc的资源清单

cat > manual-pvc.yaml <<'EOF'

apiVersion: v1

kind: PersistentVolumeClaim

metadata:

spec:

声明资源的访问模式

accessModes:

ReadWriteMany

声明资源的使用量

resources:

limits:

storage: 4Gi

requests:

storage: 3Gi

EOF

(2)创建资源

kubectl apply -f manual-pvc.yaml

(3)查看pvc资源

kubectl get pvc

Pod引用PVC：

cat > 09-pvc.yaml <<EOF

apiVersion: extensions/v1beta1

kind: Deployment

metadata:

spec:

replicas: 5

selector:

matchLabels:

apps: oldboyedu-web

template:

metadata:

labels:

apps: oldboyedu-web

spec:

volumes:

name: myweb

声明NFS存储卷

nfs:

server: 10.0.0.201

path: /oldboyedu/data/kubernetes

声明PVC

persistentVolumeClaim:

claimName: oldboyedu-linux82-pvc

tolerations:

operator: Exists

containers:

name: linux82-web

image: k8s151.oldboyedu.com:5000/oldboyedu-web/nginx:1.20.1

volumeMounts:

name: myweb

mountPath: /usr/share/nginx/html

EOF

删除pvc验证pv的回收策略:

Retain:

"保留回收"策略允许手动回收资源,删除pvc时，pv仍然存在，并且该卷被视为"已释放(Released)"。

在管理员手动回收资源之前，使用该策略其他Pod将无法直接使用。

温馨提示:

(1)在k8s1.15.12版本测试时，删除pvc发现nfs存储卷的数据并不会被删除，pv也不会被删除;

Delete:

对于支持删除回收策略的卷插件，k8s将删除pv及其对应的数据卷数据。建议使用动态存储类(sc)实现，才能看到效果哟！

对于AWS EBS, GCE PD, Azure Disk, or OpenStack Cinder等存储卷会被删除。

温馨提示:

(1)在k8s1.15.12版本测试时，在不使用sc时，则删除pvc发现nfs存储卷的数据并不会被删除；

(2)在k8s1.15.12版本测试时，在使用sc后，可以看到删除效果哟;

Recycle:

对于"回收利用"策略官方已弃用。相反，推荐的方法是使用动态资源调配。

如果基础卷插件支持，回收回收策略将对卷执行基本清理（rm -rf /thevolume/*），并使其再次可用于新的声明。

温馨提示，在k8s1.15.12版本测试时，删除pvc发现nfs存储卷的数据被删除。

临时更改pv的回收策略:

kubectl patch pv oldboyedu-linux82-pv02 -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'

参考链接:

https://kubernetes.io/docs/tasks/administer-cluster/change-pv-reclaim-policy/

温馨提示:

基于命令行的方式修改配置，基本上都是临时修改，当资源被删除后，重新创建时依旧会根据资源清单的配置创建哟。

部署nfs动态存储类:

(1)k8s组件原生并不支持NFS动态存储

https://kubernetes.io/docs/concepts/storage/storage-classes/#provisioner

(2)NFS不提供内部配置器实现动态存储，但可以使用外部配置器。

git clone https://gitee.com/yinzhengjie/k8s-external-storage.git

(3)修改配置文件

cd k8s-external-storage/nfs-client/deploy

vim deployment.yaml

...

spec:

...

template:

...

spec:

...

containers:

name: nfs-client-provisioner

...

env:

name: PROVISIONER_NAME

value: fuseim.pri/ifs

指定NFS服务器地址

name: NFS_SERVER

value: 10.0.0.201

指定NFS的共享路径

name: NFS_PATH

value: /oldboyedu/data/kubernetes/sc

volumes:

name: nfs-client-root

配置NFS共享

nfs:

server: 10.0.0.201

path: /oldboyedu/data/kubernetes/sc

(4)nfs服务器端创建sc需要共享路径

mkdir -pv /oldboyedu/data/kubernetes/sc

(5)创建动态存储类

kubectl apply -f class.yaml && kubectl get sc

(6)创建授权角色

kubectl apply -f rbac.yaml

(7)部署nfs动态存储配置器

kubectl apply -f deployment.yaml

(8)查看是否部署成功（如下图所示）

kubectl get sc,po

温馨提示:

生产环境建议设置回收策略为保留（Retain）。

cat > class.yaml <<'EOF'

apiVersion: storage.k8s.io/v1

kind: StorageClass

metadata:

provisioner: fuseim.pri/ifs # or choose another name, must match deployment's env PROVISIONER_NAME'

provisioner: oldboyedu/linux

parameters:

注意哈，仅对"reclaimPolicy: Delete"时生效，如果回收策略是"reclaimPolicy: Retain"，则无视此参数!

如果设置为false，删除数据后，不会在存储卷路径创建"archived-*"前缀的目录哟!

archiveOnDelete: "false"

如果设置为true，删除数据后，会在存储卷路径创建"archived-*"前缀的目录哟

archiveOnDelete: "true"

声明PV回收策略，默认值为Delete

reclaimPolicy: Retain

EOF

今日内容回顾:

污点

影响POD调度。

污点容忍 ***

当一个pod能够容忍一个worker节点的所有污点。

亲和性: ***
节点亲和性
Pod亲和性
Pod的反亲和性
节点选择器
一波控制器来袭:
Job:

一次性任务。失败时可以指定重试次数。

CronJob:

周期性任务。底层调用的是Job。

DaemonSet : *****

每个节点都只能运行一个pod副本。

StatefulSet:

适合用状态服务的部署。

rc:
rs:
Deployment: ***** CAK ---> 75%+

部署微服务.

pv ***

绑定后端的真是存储设备。

pvc *****

绑定pv。

sc *****

自动创建pv。

今日作业:

(1)晚上课堂的所有练习并完善思维导图;

(2)将"jasonyin2020/oldboyedu-games:v0.3"镜像使用deployment组件部署，要求如下:

使用cm资源配置nginx配置文件
使用svc暴露服务
使用sc存储网站的代码
要求将该镜像传输到harbor的私有仓库，要求用户名为:"linux82"，密码为:"oldboyEDU@2022"，需要使用secret资源
要求所有节点打污点"school=oldboyedu"
要求上述所有资源清单使用单独的文件，然后再合并为一个资源清单。
要求浏览器访问任意worker节点的[80-90]端口时能够访问到11个游戏哟

扩展作业:

(1)调研isito服务的基础使用;

关于版本支持:

https://istio.io/latest/docs/releases/supported-releases/

k8s day06

配置污点容忍，则容器可以调度到具有该污点的节点

若key不定义，则表示匹配所有的key值。

operator表示key和value之间的关系，有效值为: Exists(存在),Equal(等于).默认值为"Equal"

若operator的值为Exists，value的值必须为空，表示只要存在school这个KEY，默认匹配所有的值。

注意，effect若不配置，则默认匹配所有的污点类型

若指定，则有效值为: NoSchedule,PreferNoSchedule,NoExecute

容忍污点

亲和性

节点亲和性

硬限制，必须满足的条件

定义节点选择器列表

基于节点的标签进行关联

软限制，不一定要满足，但会优先满足，相当于提高了调度的优先级

配置权重

偏向性

基于节点的标签进行关联

表示节点的标签名称

关联关系，表示key和values的关系

In

包含，要求values字段不能为空。

NotIn

不包含，要求values字段不能为空。

Exists

存在，要求values字段必须为空。

DoesNotExist

不存在，要求values字段必须为空。

Gt

大于，要求values字段必须是一个单一的元素，且值将被解释为整数。

Lt

小于，要求values字段必须是一个单一的元素，且值将被解释为整数。

定义标签的值

定义Pod的亲和性

定义硬限制

指定的拓扑域为"kubernetes.io/hostname"时:

就会发现所有的Pod被调度到同一个节点的现象，这是因为所有的node节点key其values值不同导致的。

指定的拓扑域为"beta.kubernetes.io/os"时:

就会发现所有的Pod被调度到不同的节点，这是因为所有的node节点的key其values值相同。

- topologyKey: kubernetes.io/hostname

值得注意的是，如果有的节点没有school这个key，在K8S 1.15.12版本中测试发现，有可能会调度到没有school的KEY节点哟!

- topologyKey: school

注意，上面的topologyKey拓扑域并不能立刻确定Pod应该调度到哪个节点，

因为可能选择较多(即节点的key相同value不相同的情况)，所以需要借助pod的标签选择器进行再次确认!

此处的KEY并非是node的标签，而是pods的标签哟~

注意，如果Pod出现了key值相同，但value不相同的标签，这个时候不建议使用Exists

而是建设设置白名单，即采用"operator: In"的方式进行匹配，当然此时values不能为空。

定义Pod的反亲和性

将Pod调度到包含特定标签的节点

它计算π到2000个位置并打印出来。大约需要10秒才能完成。

command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]

注意，此处的重启策略表示容器退出时是否重新创建，但手动杀死容器，发现依旧会自动拉起，这是CM组件保证了这个特性。

指定标记此作业失败之前的重试次数。官方文档说默认值为6次，但实际测试为7次。

此处我指定为2次，表示容器启动失败时，会尝试重新启动新的Pod次数为2.

定义调度格式，参考链接：https://en.wikipedia.org/wiki/Cron

┌───────────── 分钟 (0 - 59)

│ ┌───────────── 小时 (0 - 23)

│ │ ┌───────────── 月的某天 (1 - 31)

│ │ │ ┌───────────── 月份 (1 - 12)

│ │ │ │ ┌───────────── 周的某天 (0 - 6)（周日到周一；在某些系统上，7 也是星期日）

│ │ │ │ │ 或者是 sun，mon，tue，web，thu，fri，sat

│ │ │ │ │

│ │ │ │ │

* * * * *

将clusterIP字段设置为None表示为一个无头服务(headless services)，即svc将不会分配VIP。

声明无头服务

kubectl run -it dns-test --rm --image=k8s151.oldboyedu.com:5000/oldboyedu-linux/alpine -- sh

for i in `seq 0 2`;do ping linux82-web-${i}.linux82-headless.default.svc.cluster.local -c 3;done

将clusterIP字段设置为None表示为一个无头服务，即svc将不会分配VIP。

声明无头服务

卷申请模板，会为每个Pod去创建唯一的pvc并与之关联哟!

声明咱们自定义的动态存储类，即sc资源。

kubectl exec -it linux81-web-0 -- bash

kubectl exec -it linux81-web-1 -- bash

kubectl exec -it linux81-web-2 -- bash

vim /etc/resolv.conf # 不修改宿主机的配置文件的话，可以直接启动pod进行测试即可。

curl oldboyedu-linux81-sts.default.svc.cluster.local

声明PV的访问模式，常用的有"ReadWriteOnce","ReadOnlyMany"和"ReadWriteMany":

ReadWriteOnce:(简称:"RWO")

只允许单个worker节点读写存储卷，但是该节点的多个Pod是可以同时访问该存储卷的。

ReadOnlyMany:(简称:"ROX")