k8s day06

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

污点的语法格式如下:
   key[=value]:effect

相关字段说明:
   key:
       字母或数字开头，可以包含字母、数字、连字符(-)、点(.)和下划线(_)，最多253个字符。
       也可以以DNS子域前缀和单个"/"开头

   value:
       该值是可选的。如果给定，它必须以字母或数字开头，可以包含字母、数字、连字符、点和下划线，最多63个字符。

   effect:[ɪˈfekt]
       effect必须是NoSchedule、PreferNoSchedule或NoExecute。
NoSchedule: [noʊ,ˈskedʒuːl]
该节点不再接收新的Pod调度，但不会驱赶已经调度到该节点的Pod。
PreferNoSchedule: [prɪˈfɜːr,noʊ,ˈskedʒuː]
该节点可以接受调度，但会尽可能将Pod调度到其他节点，换句话说，让该节点的调度优先级降低啦。
NoExecute:[ˈnoʊ,eksɪkjuːt]
   该节点不再接收新的Pod调度，与此同时，会立刻驱逐已经调度到该节点的Pod。


实战案例:
   (1)查看污点(taints[teɪnts])
kubectl describe nodes | grep Taints

(2)打污点
kubectl taint node k8s153.oldboyedu.com school=oldboyedu:PreferNoSchedule
kubectl taint node k8s153.oldboyedu.com school=oldboyedu:NoSchedule
kubectl taint node k8s153.oldboyedu.com school=oldboyedu:NoExecute

(3)取消污点
kubectl taint node k8s153.oldboyedu.com school-
kubectl taint node k8s153.oldboyedu.com school=oldboyedu:NoSchedule-
kubectl taint node k8s153.oldboyedu.com school=oldboyedu:NoExecute-

污点容忍（toleration[ˌtɑːləˈreɪʃn]）:
   所谓的污点容忍，就是允许Pod调度到存在污点的节点。


实战案例:
   1.所有节点创建污点
kubectl taint node k8s151.oldboyedu.com school=oldboyedu:NoSchedule
kubectl taint node k8s152.oldboyedu.com school=oldboyedu:PreferNoSchedule
kubectl taint node k8s153.oldboyedu.com school=oldboyedu:NoExecute

2.容忍污点
[root@k8s151.oldboyedu.com deploy]# cat 04-deploy-taints.yaml
kind: Deployment
apiVersion: extensions/v1beta1
metadata:
name: oldboyedu-linux82-deploy-nginx-taints-001
spec:
replicas: 3
selector:
matchLabels:
school: oldboyedu
template:
metadata:
name: linux82-web
labels:
school: oldboyedu
spec:
# 配置污点容忍，则容器可以调度到具有该污点的节点
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:
name: oldboyedu-linux82-affinity-nodeaffinity
labels:
school: oldboyedue
spec:
replicas: 10
template:
metadata:
name: linux82-web
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:
name: oldboyedu-linux82-affinity-podaffinity
spec:
replicas: 20
selector:
matchLabels:
apps: oldboyedu-web
template:
metadata:
name: linux82-web
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:
name: oldboyedu-linux82-affinity-podantiaffinity
spec:
replicas: 10
selector:
matchLabels:
apps: oldboyedu-web
template:
metadata:
name: linux82-web
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:
name: oldboyedu-linux82-affinity-podantiaffinity
spec:
replicas: 10
selector:
matchLabels:
apps: oldboyedu-web
template:
metadata:
name: linux82-web
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:
name: oldboyedu-linux82-pi
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:
name: oldboyedu-hello
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:
name: oldboyedu-linux82-ds-nginx
spec:
selector:
matchLabels:
school: oldboyedu
template:
metadata:
name: linux82-web
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:
name: linux82-headless
spec:
ports:
- port: 80
name: web
# 将clusterIP字段设置为None表示为一个无头服务(headless services)，即svc将不会分配VIP。
clusterIP: None
selector:
app: nginx

---

apiVersion: apps/v1
kind: StatefulSet
metadata:
name: linux82-web
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:
name: linux82-headless
spec:
ports:
- port: 80
name: web
# 将clusterIP字段设置为None表示为一个无头服务，即svc将不会分配VIP。
clusterIP: None
selector:
app: nginx

---

apiVersion: apps/v1
kind: StatefulSet
metadata:
name: linux82-web
spec:
selector:
matchLabels:
app: nginx
# 声明无头服务
serviceName: linux82-headless
replicas: 3
# 卷申请模板，会为每个Pod去创建唯一的pvc并与之关联哟!
volumeClaimTemplates:
- metadata:
name: data
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:
name: oldboyedu-linux82-sts
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:
name: oldboyedu-linux82-pv01
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:
name: oldboyedu-linux82-pv02
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:
name: oldboyedu-linux82-pv03
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:
name: oldboyedu-linux82-pvc
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:
name: oldboyedu-linux82-deploy
spec:
replicas: 5
selector:
matchLabels:
apps: oldboyedu-web
template:
metadata:
name: oldboyedu-linux82-pvc
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:
name: managed-nfs-storage
# 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/