#云原生##容器# #kubernetes##实践#

引子

kubernetes的资源对象是kubernetes体系中的重要组成部分，简单理解就是生成的kubernetes的系统应用，用来调度、编排我们的业务应用。是我们的业务应用与kubernetes的kube-controller组件，如：apiserver、kube-controller、kube-scheduler等之间的中间层，起到承上启下的作用。

将kubernetes的资源对象简单的分类为以下几种资源对象：

类别

名称

资源对象

Pod、ReplicaSet、ReplicationController、Deployment、StatefulSet、DaemonSet、Job、CronJob、HorizontalPodAutoscaling、Node、Namespace、Service、Ingress、Label、CustomResourceDefinition

存储对象

Volume、PersistentVolume、Secret、ConfigMap

策略对象

SecurityContext、ResourceQuota、LimitRange

身份对象

ServiceAccount、Role、ClusterRole

学习kubernetes的资源对象对入门kubernetes是十分重要的，但kubernetes的资源对象比较多，概念繁杂，容易让人困惑。

**单单从理论出发，也容易让人无法留下较深的印象，**故本系列直接从各种小练习出发，以练促学，在实践中加深对kubernetes资源对象的理解。同时也在实践找那个插入响应的理论讲解，理论与实践相辅相成，相辅促进。

关于kubernetes的简单入门，以及搭建一个简单的kubernetes集群，百度或者其他资讯平台都有很好的教程。关注作者，私信留言（kubernetes）直接赠送。

存储

存储1. 创建含有初始化容器的pod，满足如下要求。1)  pod名为pod1，镜像为nginx。2)  创建一个名字为v1的卷，这个卷的数据不能永久存储数据。3)  初始化容器名字为initc1，镜像使用busybox，挂载此卷v1到目录/data。4)  在初始化容器里，创建文件/data/aa.txt。5)  普通容器名字为c1，镜像为nginx。6)  把卷v1挂载到/data里。7)  当次pod运行起来之后，在pod1的c1容器里，查看是不是存在/data/aa.txt。

apiVersion: v1kind: Podmetadata:  creationTimestamp: null  labels:    run: pod1  name: pod1spec:  terminationGracePeriodSeconds: 0 #terminationGracePeriodSeconds 可以定义优雅关闭的宽限期，即在收到停止请求后，有多少时间来进行资源释放或者做其它操作，如果到了最大时间还没有停止，会被强制结束。默认值：30。  volumes:  - name: v1    emptyDir: {}#只写一个位置对应的容器的位置，物理机上随便找一个位置，删除后物理机上的数据也会消失  containers:  - name: initc1    image: busybox    imagePullPolicy: IfNotPresent    command: ["sh","-c","touch /data/aa.txt && sleep 1000"]    volumeMounts:    - name: v1      mountPath: /data  - name: c1    image: nginx    imagePullPolicy: IfNotPresent    volumeMounts:    - name: v1      mountPath: /data      #readOnly: false    resources: {}#resources可以用于限制容器对资源的使用，具体设置如下  dnsPolicy: ClusterFirst#dns策略，ClusterFirst 表示集群 DNS 优先  restartPolicy: Alwaysstatus: {}###############################################################测试在pod1的c1容器里，查看是不是存在/data/aa.txt[root@vms31 10-test]# kubectl exec -it pod1 -c c1 -- ls /dataaa.txt requests未设置时，默认与limits相同。limits未设置时，默认值与集群配置相关。可以使用requests来设置各容器需要的最小资源limits用于限制运行时容器占用的资源，用来限制容器的最大CPU、内存的使用率。当容器申请内存超过limits时会被终止，并根据重启策略进行重启。.    resources:      limits:        cpu: "1"        memory: 2048Mi      requests:        cpu: "0.6"        memory: 1024Mi 

2. 创建一个持久性存储，满足如下要求。1)  持久性存储的名字为pv10。2)  容量大小设置为2G。3)  访问模式为ReadWriteOnce。4)  存储类型为hostPath，对应目录/pv10。5)  storageClassName设置为cka。

apiVersion: v1kind: PersistentVolumemetadata:  name: pv10spec:  capacity:    storage: 2Gi  volumeMode: Filesystem  accessModes:    - ReadWriteOnce  persistentVolumeReclaimPolicy: Retain #持久卷回收策略，Retain就是保留，还有”Recycle” 和 “Delete”  storageClassName: cka #  hostPath: #hostPath存储删除容器，物理机上的文件还会保存,但不会同步到重建的pod上    path: /data     ###############################################################################PersistentVolumes 可以有多种回收策略，包括 “Retain”、”Recycle” 和 “Delete”。对于动态配置的 PersistentVolumes 来说，默认回收策略为 “Delete”。这表示当用户删除对应的 PersistentVolumeClaim 时，动态配置的 volume 将被自动删除。如果 volume 包含重要数据时，这种自动行为可能是不合适的。那种情况下，更适合使用 “Retain” 策略。使用 “Retain” 时，如果用户删除 PersistentVolumeClaim，对应的 PersistentVolume 不会被删除。相反，它将变为 Released 状态，表示所有的数据可以被手动恢复。###############################################################################PV是对底层网络共享存储的抽象，将共享存储定义为一种“资源”，比如Node也是容器应用可以消费的资源。PV由管理员创建和配置，与共享存储的具体实现直接相关。PVC则是用户对存储资源的一个“申请”，就像Pod消费Node资源一样，PVC能够消费PV资源。PVC可以申请特定的存储空间和访问模式。StorageClass，用于标记存储资源的特性和性能，管理员可以将存储资源定义为某种类别，正如存储设备对于自身的配置描述（Profile）。根据StorageClass的描述可以直观的得知各种存储资源的特性，就可以根据应用对存储资源的需求去申请存储资源了。存储卷可以按需创建。 

3. 创建pvc，满足如下要求。1)  名字为pvc10。2)  让此pvc和pv10进行关联。3)  所在命名空间为default。

apiVersion: v1kind: PersistentVolumeClaimmetadata:  name: pvc10spec:  accessModes:    - ReadWriteOnce  volumeMode: Filesystem  resources:    requests:      storage: 1Gi #pvc的容量和pv的大小是否要求一致，我觉得是不需要的  storageClassName: cka 

4. 创建pod，满足如下要求。1)  名字为pod-pvc。2)  创建名字为v1的卷，让其使用pvc10作为后端存储。3)  容器所使用的镜像为nginx。4)  把卷v1挂载到/data目录。

apiVersion: v1kind: Podmetadata:  creationTimestamp: null  labels:    run: pod-pvc  name: pod-pvcspec:  nodeName: vm3  terminationGracePeriodSeconds: 0  volumes:  - name: v1    persistentVolumeClaim:        claimName: pvc10        containers:  - image: nginx    name: pod-pvc    imagePullPolicy: IfNotPresent    volumeMounts:    - name: v1      mountPath: /data    dnsPolicy: ClusterFirst  restartPolicy: Alwaysstatus: {}

Secret创建含有初始化容器的pod，满足如下要求：

1.创建secret，名字为s1，键值对为name1/tom1 1）创建一个名字为nginx的pod，镜像为nginx。 2.）此pod里定义一个名字为MYENV的变量，此变量的值为s1里name1对应的值。 3）当pod运行起来之后，进入pod里查看变量MYENV的值。

[root@vms31 10-test]# kubectl create secret --helpCreate a secret using specified subcommand.Available Commands:  docker-registry 创建一个给 Docker registry 使用的 secret  generic         从本地 file, directory 或者 literal value 创建一个 secret  tls             创建一个 TLS secretUsage:  kubectl create secret [flags] [options]Use "kubectl <command> --help" for more information about a given command.Use "kubectl options" for a list of global command-line options (applies to all commands).[root@vms31 10-test]# kubectl create secret generic s1 --from-literal=name1=tom1 #generic子命令可以通过本地文件、目录或者literal(键值对) [root@vms31 10-test]# kubectl nginx --image=nginx --image-pull-policy=IfNotPresent --dry-run=client -o yaml > test.yaml

修改生成的yaml文件

apiVersion: v1kind: Podmetadata:  creationTimestamp: null  labels:    run: nginx  name: nginxspec:  terminationGracePeriodSeconds: 0  containers:  - env:    - name: MYENV      valueFrom:        secretKeyRef:          name: s1          key: name1    image: nginx    imagePullPolicy: IfNotPresent    name: nginx    resources: {}  dnsPolicy: ClusterFirst  restartPolicy: Alwaysstatus: {}

验证容器内的变量值

[root@vms31 10-test]# kubectl get podsNAME    READY   STATUS    RESTARTS   AGEnginx   1/1     Running   0          2m49s[root@vms31 10-test]# [root@vms31 10-test]# [root@vms31 10-test]# kubectl exec -it nginx -- bashroot@nginx:/# echo $MYENVtom1

2.创建configmap，名字cm1，键值对为name2/tom2

1）创建一个名字为nginx2的pod，镜像为nginx。

2）此pod里把cm1挂载到/also/data目录里。

创建configmap并生成yaml文件

[root@vms31 10-test]# kubectl create cm cm1 --from-literal=name2=tom2configmap/cm1 created[root@vms31 10-test]# [root@vms31 10-test]# [root@vms31 10-test]# kubectl run nginx2 --image=nginx --image-pull-policy=IfNotPresent --dry-run=client -o yaml > test2.yaml

配置的yaml文件

apiVersion: v1kind: Podmetadata:  creationTimestamp: null  labels:    run: nginx2  name: nginx2spec:  volumes:  - name: v1    configMap:      name: cm1  containers:  - image: nginx    imagePullPolicy: IfNotPresent    name: nginx2    resources: {}    volumeMounts:    - name: v1      mountPath: /also/data  dnsPolicy: ClusterFirst  restartPolicy: Alwaysstatus: {}

验证pod的configmap

[root@vms31 10-test]# kubectl exec -it nginx2 -- cat /also/data/name2tom2[root@vms31 10-test]#

deploy1.创建一个deployment，满足如下要求：

1）名字为web1，镜像为nginx:1.9。

2）比web1要有2个副本。

3）pod的标签为app-name=web1。

deploy的yaml文件

apiVersion: apps/v1kind: Deploymentmetadata:  creationTimestamp: null  labels:    app: web1  name: web1spec:  replicas: 2  selector:    matchLabels:      app: web1  strategy: {}  template:    metadata:      creationTimestamp: null      labels:        app: web1    spec:      containers:      - image: nginx:1.9        name: nginx        resources: {}status: {}

可以看到通过deploy创建的pod是在deploy和pod上都能查找到的，但删除的时候是要删除deploy，删除pod会再次自动创建的。

设置的标签可以看到deploy上有。pod上是没有的

2.更新此deployment，把maxSurge和maxUnavailable的值都设置为1。

服务在滚动更新时，deployment控制器的目的是：给旧版本(old_rs)副本数减少至0、给新版本(new_rs)副本数量增至期望值(replicas)。大家在使用时，通常容易忽视控制速率的特性，以下是kubernetes提供的两个参数：

maxUnavailable：和期望ready的副本数比，不可用副本数最大比例（或最大值），这个值越小，越能保证服务稳定，更新越平滑；maxSurge：和期望ready的副本数比，超过期望副本数最大比例（或最大值），这个值调的越大，副本更新速度越快。

通过kubectl edit deployments.apps web1来修改不太靠谱，修改原来的yaml文件再次生成，如果成功显示是deployment.apps/web1 configured，标明是修改生成的

[root@vms31 10-test]# kubectl apply -f deploy.yaml deployment.apps/web1 configured[root@vms31 10-test]# [root@vms31 10-test]# [root@vms31 10-test]# kubectl get deployments.apps NAME   READY   UP-TO-DATE   AVAILABLE   AGEweb1   2/2     2            2           18h[root@vms31 10-test]# [root@vms31 10-test]# [root@vms31 10-test]# kubectl get podsNAME                    READY   STATUS    RESTARTS   AGEweb1-6f8f6976b5-t4j7l   1/1     Running   1          18hweb1-6f8f6976b5-vc8pl   1/1     Running   1          17h[root@vms31 10-test]# [root@vms31 10-test]# [root@vms31 10-test]# cat deploy.yaml apiVersion: apps/v1kind: Deploymentmetadata:  creationTimestamp: null  labels:    app: web1  name: web1spec:  replicas: 2  selector:    matchLabels:      app: web1  strategy: #修改的是标红    type: RollingUpdate    rollingUpdate:      maxSurge: 1      maxUnavailable: 1  template:    metadata:      creationTimestamp: null      labels:        app: web1    spec:      containers:      - image: nginx:1.9        name: nginx        resources: {}status: {}

修改之后edit deploy发现更新策略写在下图位置

3.修改此deployment的副本数为6。

[root@vms31 10-test]# kubectl scale deployment web1 --replicas=6deployment.apps/web1 scaled[root@vms31 10-test]# kubectl get deployments.apps NAME   READY   UP-TO-DATE   AVAILABLE   AGEweb1   5/6     6            5           18h[root@vms31 10-test]# [root@vms31 10-test]# [root@vms31 10-test]# kubectl get podsNAME                    READY   STATUS              RESTARTS   AGEweb1-6f8f6976b5-2d8r4   0/1     ContainerCreating   0          29sweb1-6f8f6976b5-bxbkj   1/1     Running             0          29sweb1-6f8f6976b5-jprw9   1/1     Running             0          29sweb1-6f8f6976b5-t4j7l   1/1     Running             1          18hweb1-6f8f6976b5-t9drk   1/1     Running             0          29sweb1-6f8f6976b5-vc8pl   1/1     Running             1          17h 

4.更新此deployment，让其使用镜像nginx，并记录此次更新。

[root@vms31 10-test]# kubectl get deployments.apps -o wide#可以看到此时nginx版本为1.9NAME   READY   UP-TO-DATE   AVAILABLE   AGE   CONTAINERS   IMAGES      SELECTORweb1   6/6     6            6           18h   nginx        nginx:1.9   app=web1[root@vms31 10-test]# [root@vms31 10-test]# [root@vms31 10-test]# kubectl set image deploy web1 nginx=nginx --record#更新操作命令deployment.apps/web1 image updated[root@vms31 10-test]# [root@vms31 10-test]# [root@vms31 10-test]# kubectl get deployments.apps -o wide#此时nginx版本发生了变化NAME   READY   UP-TO-DATE   AVAILABLE   AGE   CONTAINERS   IMAGES   SELECTORweb1   6/6     6            6           18h   nginx        nginx    app=web1[root@vms31 10-test]# kubectl rollout history deployment web1#可以查询到更新的版本deployment.apps/web1 REVISION  CHANGE-CAUSE1         <none>2         kubectl set image deploy web1 nginx=nginx --record=true

kubectl rollout对资源进行管理可用资源包括：deploymentsdaemonsets子命令history（查看历史版本）pause（暂停资源）resume（恢复暂停资源）status（查看资源状态）undo（回滚版本）

5.回滚此次更新至升级之前的镜像版本nginx:1.9。

[root@vms31 10-test]# kubectl get deployments.apps -o wideNAME   READY   UP-TO-DATE   AVAILABLE   AGE   CONTAINERS   IMAGES   SELECTORweb1   6/6     6            6           18h   nginx        nginx    app=web1[root@vms31 10-test]# kubectl rollout history deployment web1deployment.apps/web1 REVISION  CHANGE-CAUSE1         <none>2         kubectl set image deploy web1 nginx=nginx --record=true[root@vms31 10-test]# kubectl rollout undo deployment web1 --to-revision=1#把deploy回滚的命令，版本根据前面查到的deployment.apps/web1 rolled back[root@vms31 10-test]# [root@vms31 10-test]# [root@vms31 10-test]# #kubectl rollout undo deployment web1#这个命令是回滚到上一个版本 [root@vms31 10-test]# [root@vms31 10-test]# kubectl get deployments.apps NAME   READY   UP-TO-DATE   AVAILABLE   AGEweb1   6/6     6            6           18h[root@vms31 10-test]# [root@vms31 10-test]# kubectl get deployments.apps -o wide#nginx版本又回到了1.9NAME   READY   UP-TO-DATE   AVAILABLE   AGE   CONTAINERS   IMAGES      SELECTORweb1   6/6     6            6           18h   nginx        nginx:1.9   app=web1[root@vms31 10-test]# [root@vms31 10-test]# [root@vms31 10-test]# kubectl rollout history deployment web1 deployment.apps/web1 REVISION  CHANGE-CAUSE2         kubectl set image deploy web1 nginx=nginx --record=true3         <none>

6.删除此deployment。

kubectl delete deployments.apps web1 --force

Daemon Set1.创建一个daemonset，满足如下要求：

1）名字为ds-test1。 2）使用的镜像为nginx。

daemon set的yaml文件

apiVersion: apps/v1kind: DaemonSetmetadata:  creationTimestamp: null  labels:    app: ds-test1  name: ds-test1spec:  selector:    matchLabels:      app: ds-test1  template:    metadata:      creationTimestamp: null      labels:        app: ds-test1    spec:      containers:      - image: nginx        name: nginx        resources: {}

daemonset创建成功后查询daemonset

[root@vms31 10-test]# kubectl get daemonsets.apps -o wideNAME       DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE     CONTAINERS   IMAGES   SELECTORds-test1   2         2         2       2            2           <none>          2m45s   nginx        nginx    app=ds-test1[root@vms31 10-test]# kubectl get pods -o wideNAME             READY   STATUS    RESTARTS   AGE     IP              NODE    NOMINATED NODE   READINESS GATESds-test1-bzhct   1/1     Running   0          2m46s   10.244.252.17   vms33   <none>           <none>ds-test1-zb9c8   1/1     Running   0          2m46s   10.244.29.99    vms32   <none>           <none>

2.解释，此daemonset为什么没有在master创建pod。

因为master节点设置了误点（Taints）

查看所有节点是否设置了污点

kubectl describenodes |grep -E "Taints|Name"

[root@vms31 10-test]# kubectl describe nodes | grep -E "Taints|Name"#-E表示可以使用正则表达式，该表达式表示Taints或NameName:               vms31Taints:             node-role.kubernetes.io/master:NoSchedule  Namespace                   Name                             CPU Requests  CPU Limits  Memory Requests  Memory Limits  AGEName:               vms32Taints:             <none>  Namespace                   Name                                        CPU Requests  CPU Limits  Memory Requests  Memory Limits  AGEName:               vms33Taints:             <none>  Namespace                   Name                              CPU Requests  CPU Limits  Memory Requests  Memory Limits  AGE

设置和取消污点

kubectl taint node [node] key=value[effect]

其中[effect] 可取值: [ NoSchedule | PreferNoSchedule | NoExecute ]

NoSchedule: 一定不能被调度PreferNoSchedule: 尽量不要调度NoExecute: 不仅不会调度, 还会驱逐Node上已有的Pod

[root@vms31 10-test]# kubectl get nodesNAME    STATUS   ROLES                  AGE   VERSIONvms31   Ready    control-plane,master   97d   v1.20.1vms32   Ready    node1                  97d   v1.20.1vms33   Ready    node2                  97d   v1.20.1[root@vms31 10-test]# [root@vms31 10-test]# [root@vms31 10-test]# kubectl taint node vms32 node-role.kubernetes.io/worker1=:NoSchedulenode/vms32 tainted[root@vms31 10-test]# [root@vms31 10-test]# kubectl describe nodes | grep -E "Taints|Name"Name:               vms31Taints:             node-role.kubernetes.io/master:NoSchedule  Namespace                   Name                             CPU Requests  CPU Limits  Memory Requests  Memory Limits  AGEName:               vms32Taints:             node-role.kubernetes.io/worker1:NoSchedule  Namespace                   Name                                        CPU Requests  CPU Limits  Memory Requests  Memory Limits  AGEName:               vms33Taints:             <none>  Namespace                   Name                              CPU Requests  CPU Limits  Memory Requests  Memory Limits  AGE    删除污点[root@vms31 10-test]# kubectl taint node vms32 node-role.kubernetes.io/worker1-node/vms32 untainted[root@vms31 10-test]# kubectl describe nodes | grep -E "Taints|Name"Name:               vms31Taints:             node-role.kubernetes.io/master:NoSchedule  Namespace                   Name                             CPU Requests  CPU Limits  Memory Requests  Memory Limits  AGEName:               vms32Taints:             <none>  Namespace                   Name                                        CPU Requests  CPU Limits  Memory Requests  Memory Limits  AGEName:               vms33Taints:             <none>  Namespace                   Name                              CPU Requests  CPU Limits  Memory Requests  Memory Limits  AGE

3.创建一个daemonset，

满足如下要求：

1）名字为ds-test2。 2）使用的镜像为nginx。 3）此daemonset所创建的pod只在含有标签为disktype=ssd的worker上运行。 4.）删除这两个daemonset。

先给一个节点设置对应标签

[root@vms31 10-test]# kubectl get nodes --show-labels | grep vm32[root@vms31 10-test]# kubectl get nodes --show-labels | grep vms32vms32   Ready    node1                  97d   v1.20.1   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,disktype=ssd,kubernetes.io/arch=amd64,kubernetes.io/hostname=vms32,kubernetes.io/os=linux,node-role.kubernetes.io/node1=

daemonset的yaml

apiVersion: apps/v1kind: DaemonSetmetadata:  creationTimestamp: null  labels:    app: ds-test2  name: ds-test2spec:  selector:    matchLabels:      app: ds-test2  template:    metadata:      creationTimestamp: null      labels:        app: ds-test2    spec:      nodeSelector:        disktype: ssd      containers:      - image: nginx        name: nginx        resources: {}

运行后可以查到只在对应标签的node上运行

[root@vms31 10-test]# kubectl get daemonsets.apps NAME       DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGEds-test2   1         1         0       1            0           disktype=ssd    7s[root@vms31 10-test]# [root@vms31 10-test]# [root@vms31 10-test]# kubectl get pods -o wideNAME             READY   STATUS              RESTARTS   AGE   IP       NODE    NOMINATED NODE   READINESS GATESds-test2-4zjfc   0/1     ContainerCreating   0          23s   <none>   vms32   <none>           <none>

后续继续更新有关云原生及kubernetes的干货文章，欢迎点赞关注，多多分享。