• 【云原生】kubernetes学习之资源(对象)控制器概述---概念和实战(五)


    一,kubernetes内的资源(或者称之为对象)

    首先,应该是思考一个问题,为什么kubernetes里要引入资源(对象)这个概念?

    Kubernetes 中的所有内容都被抽象为“资源”,如 Pod、Service、Node 等都是资源。“对象”就是“资源”的实例,是持久化的实体。如某
    个具体的 Pod、某个具体的 Node。Kubernetes 使用这些实体去表现整个集群的状态。
    对象的创建、删除、修改都是通过 “Kubernetes API”,也就是 “Api Server” 组件提供的 API 接口,这些是 RESTful 风格的 Api,与 k8s
    的“万物皆对象”理念相符。命令行工具 “kubectl”,实际上也是调用的 kubernetes api。
    K8s 中的资源类别有很多种,kubectl 可以通过配置文件来创建这些 “对象”,配置文件更像是描述对象“属性”的文件,配置文件格式可以
    是 “JSON” 或 “YAML”,常用 “YAML”

    那么,以下这些资源或者称之为对象的东西在kubernetes内是由哪个服务提供的呢?kube-apiserver这个服务提供的。

    常见资源类型及API

    • 资源对象:Pods(po)、ReplicaSets(rs)、ReplicationControllers(rc)、Deployment、StatefulSet、DaemonSet(ds)、Job、CronJob(cj),HorizontalPodAutoscaling、Node、Namespace(ns)、Services(svc)、Ingress(ing)、Label、CustomResourceDefinition,nodes(no)
    • 存储对象:Volume、PersistentVolume(pv)、PersistentVolumeClaim(pvc)、Secret、ConfigMap(cm),componentstatuses(cs)
    • 策略对象:SecurityContext.ResourceQuota、LimitRange
    • 身份对象:ServiceAccounts(sa)、Role、ClusterRole,clusterrolebindings
    • 以上是资源以及它们的缩写,例如,kubectl get no 等于kubectl get nodes
    • 对象是用来完成某些任务的,是持久的,是有目的性的,因此 kubernetes 创建每个对象后,将持续地工作以确保对象存在(例如pod)。当
      然,kubernetes 并不只是维持对象的存在这么简单,kubernetes 还管理着对象的属性。

    查询kubernetes内有哪些资源呢?通过命令 kubectl  api-resources 即可看到。

    1. [root@master ~]# k api-resources
    2. NAME SHORTNAMES APIGROUP NAMESPACED KIND
    3. bindings true Binding
    4. componentstatuses cs false ComponentStatus
    5. configmaps cm true ConfigMap
    6. endpoints ep true Endpoints
    7. events ev true Event
    8. limitranges limits true LimitRange
    9. namespaces ns false Namespace
    10. 。。。。。略略略

    例如,一个最为简单的资源清单文件,使用了namespace这个资源(kind后面就是资源名称),执行这个文件将会创建一个名字叫ns-elk的namespace:

    1. [root@master ~]# cat 00-ns.yaml
    2. apiVersion: v1
    3. kind: Namespace
    4. metadata:
    5. name: ns-elk

     

    kubernetes的学习基本也是围绕着上面查询出来的各种各样的资源来展开的,那如何使用这些资源又是一个难点,因此,kubernetes又提出了一个概念---控制器。

    二,

    控制器

    kubernetes的基础服务kube-controller-manager内建了很多controller(控制器),这些相当于一个状态机,用来控制pod的具体状态和行为。kube-controller-manager 由一系列的控制器组成(并不完整,常用的控制器):

    Replication Controller
    Node Controller
    CronJob Controller
    Daemon Controller
    Deployment Controller
    Endpoint Controller
    Garbage Collector
    Namespace Controller
    Job Controller
    Pod AutoScaler
    RelicaSet
    Service Controller
    ServiceAccount Controller
    StatefulSet Controller
    Volume Controller
    Resource quota Controller

     

    非常常用的控制器有这些:

    • 确保预期的Pod副本数量---ReplicationController 和 ReplicaSet
    • 无状态应用部署----Deployment Controller
    • 有状态应用部署----StatefulSet Controller
    • 确保所有的node运行同一个pod----Daemonset Controller
    • 一次性任务和定时任务-----CronJob Controller和Job Controller

    1,ReplicationController 和 ReplicaSet

    ReplicationController用来确保容器应用的副本数始终保持在用户定义的副本数,即如果有容器异常退出,会自动创建新的Pod来替代;而如果异常多出来的容器也会自动回收,Replication Controller简称RC。

    在新版本的Kubernetes中建议使用ReplicaSet来取代ReplicationController。ReplicaSet跟ReplicationController没有本质的不同,只是名字不一样,并且ReplicaSet支持集合式的selector。Replication Set简称RS。

    虽然ReplicaSet可以独立使用,但一般还是建议使用 Deployment 来自动管理ReplicaSet,这样就无需担心跟其他机制的不兼容问题(比如ReplicaSet不支持rolling-update但Deployment支持)。

    下面是一个安装nginx的示例,使用的是ReplicationController这个控制器:

    1. [root@master ~]# cat demo-replica.yaml
    2. apiVersion: v1
    3. kind: ReplicationController
    4. metadata:
    5. name: nginx
    6. spec:
    7. replicas: 3
    8. selector:
    9. app: nginx
    10. template:
    11. metadata:
    12. name: nginx
    13. labels:
    14. app: nginx
    15. spec:
    16. containers:
    17. - name: nginx
    18. image: nginx
    19. ports:
    20. - containerPort: 80

    查询pods如下:

    1. [root@master ~]# k get po -A -o wide
    2. NAMESPACE NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
    3. default nginx-7mfzc 1/1 Running 0 40m 10.244.1.9 slave1
    4. default nginx-8djp7 1/1 Running 0 40m 10.244.1.10 slave1
    5. default nginx-s5xgq 1/1 Running 0 40m 10.244.2.10 slave2

    删除任意一个nginx 的pod,由于是多副本部署,将会自动重新拉起一个新的pod以保持规定的pod数目。

    如果想要彻底删除相关pod,需要先查询出rc的名称,然后删除rc就可以了。

    1. [root@master ~]# k get rc -A
    2. NAMESPACE NAME DESIRED CURRENT READY AGE
    3. default nginx 3 3 3 47s
    4. k delete rc nginx

    下面仍然是一个安装nginx的示例,使用的是Replicationset这个控制器,nginx的版本是指定为1.20.2:

    1. [root@master ~]# cat demo-replica.yaml
    2. apiVersion: apps/v1
    3. kind: ReplicaSet
    4. metadata:
    5. name: nginx-test
    6. labels:
    7. app: myapp
    8. spec:
    9. replicas: 3
    10. selector:
    11. matchLabels:
    12. app: myapp
    13. template:
    14. metadata:
    15. name: nginx
    16. labels:
    17. app: myapp
    18. spec:
    19. containers:
    20. - name: nginx
    21. image: nginx:1.20.2
    22. ports:
    23. - containerPort: 80

    这里需要注意一点,和ReplicationController不同的,Replicationset是在app组下,因此,apiVersion: apps/v1,选择器使用的是matchLabels,别的基本都是一样的。当然,删除也是一样的。只是查询的时候是rs不是rc了,也就是这个了:kuberctl get rs -A

    Replication Controller和ReplicaSet的创建删除和Pod并无太大区别,Replication Controller目前几乎已经不在生产环境中使用,ReplicaSet也很少单独被使用,都是使用更高级的资源Deployment、DaemonSet、StatefulSet进行管理Pod。

    2,Deployment Controller

    Deployment 主要是用于部署无状态的服务,这也是最常用的控制器。一般用于管理维护企业内部无状态的微服务,比如configserver、zuul、springboot。他可以管理多个副本的Pod实现无缝迁移、自动扩容缩容、自动灾难恢复、一键回滚等功能。

    Deployment Controller的主要作用:

    • 发布应用
    • 升级应用
    • 回退应用
    • 扩缩容

    它和上面的rc和rs相比较,多了升级,回退,扩缩容的功能。

    首先一个示例,还是部署nginx,这次版本更改为1.18,部署在test这个namespace内,副本数量是1(这个叫test的namespace要先建立哦):

    1. [root@master ~]# cat web01.yaml
    2. apiVersion: apps/v1
    3. kind: Deployment
    4. metadata:
    5. creationTimestamp: null
    6. namespace: test
    7. labels:
    8. app: web01
    9. name: web01
    10. spec:
    11. replicas: 1
    12. selector:
    13. matchLabels:
    14. app: web01
    15. strategy: {}
    16. template:
    17. metadata:
    18. creationTimestamp: null
    19. labels:
    20. app: web01
    21. spec:
    22. containers:
    23. - image: nginx:1.18
    24. imagePullPolicy: IfNotPresent
    25. name: nginx
    26. resources: {}
    27. status: {}

    deployment controller控制器并不直接管理pod,而是通过管理replicaset来间接管理pod,即:deployment管理replicaset,replicaset管理pod。

    1. [root@master ~]# k get rs -A
    2. NAMESPACE NAME DESIRED CURRENT READY AGE
    3. kube-system coredns-6c76c8bb89 2 2 2 71d
    4. kube-system nfs-client-provisioner-6fc484bd4f 1 1 1 26h
    5. test web01-5464b576c5 1 1 1 12m
    6. [root@master ~]# k get deploy -A
    7. NAMESPACE NAME READY UP-TO-DATE AVAILABLE AGE
    8. kube-system coredns 2/2 2 2 71d
    9. kube-system nfs-client-provisioner 1/1 1 1 26h
    10. test web01 1/1 1 1 25m

    因此,我们可以看到的是,get rs和get deploy 是一样结果,但deploy有一个 UP-TO-DATE,并且名称也不一样。但是看到的pod是一致的哦。

    水平扩展---将web01这个部署扩展到三个副本:

    1. [root@master ~]# k scale deploy web01 --replicas=3 -n test
    2. deployment.apps/web01 scaled

    水平扩展后,可以看到,slave1节点多了两个nginx的pod。

    1. [root@master ~]# k get po -n test -o wide
    2. NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
    3. web01-859c876457-d5978 1/1 Running 0 2m56s 10.244.1.23 slave1
    4. web01-859c876457-j7hd5 1/1 Running 0 3m35s 10.244.2.20 slave2
    5. web01-859c876457-mbt7p 1/1 Running 0 2m56s 10.244.1.24 slave1

    当然,扩缩容以及发布等等还有很多的地方可写,比如,蓝灰发布,hpa自动扩缩容等等,内容太多,以后单独一文写吧。 

     

    3,StatefulSet Controller

    StatefulSet Controller主要是用于部署有状态的服务有状态的pod与无状态的pod不一样的是,有状态的pod有时候需要通过其主机名来定位,而无状态的不需要,因为无状态的pod每个都是一样的,随机选一个就行,但对于有状态的来说,每一个pod都不一样,通常希望操作的是特定的某一个。

    statefulset适用于需要以下特点的应用:
    (1)稳定的网络标志(主机名):Pod重新调度后其PodName和HostName不变;
    (2)稳定的持久化存储:基于PVC,Pod重新调度后仍能访问到相同的持久化数据;
    (3)稳定的创建与扩容次序:有序创建或扩容,从序号小到大的顺序对pod进行创建(即从0到N-1),且在下一个Pod创建运行之前,所有之前的Pod必须都是Running和Ready状态;
    (4)稳定的删除与缩容次序:有序删除或缩容,从序号大到小的顺序对pod进行删除(即从N-1到0),且在下一个Pod终止与删除之前,所有之前的Pod必须都已经被删除;
    (5)稳定的滚动更新次序:从序号大到小的顺序对pod进行更新(即从N-1到0),先删除后创建,且需等待当前序号的pod再次创建完成且状态为Ready时才能进行下一个pod的更新处理。

    示例,nginx使用volume挂载保存首页状态,具体代码如下:

    sc是这个:

    1. [root@master ~]# k get sc -A
    2. NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE
    3. managed-nfs-storage fuseim.pri/ifs Delete Immediate true 28h

    service和StatefulSet一起编写。 

    1. apiVersion: v1
    2. kind: Service
    3. metadata:
    4. name: nginx
    5. labels:
    6. app: nginx
    7. spec:
    8. ports:
    9. - port: 80
    10. name: web
    11. clusterIP: None
    12. selector:
    13. app: nginx
    14. ---
    15. apiVersion: apps/v1
    16. kind: StatefulSet
    17. metadata:
    18. labels:
    19. app: sts-nginx
    20. name: web
    21. spec:
    22. selector:
    23. matchLabels:
    24. app: nginx
    25. serviceName: "nginx"
    26. replicas: 2
    27. template:
    28. metadata:
    29. labels:
    30. app: nginx
    31. spec:
    32. containers:
    33. - name: nginx
    34. image: nginx:1.18
    35. imagePullPolicy: IfNotPresent
    36. ports:
    37. - containerPort: 80
    38. name: web
    39. volumeMounts:
    40. - name: www
    41. mountPath: /usr/share/nginx/html
    42. volumeClaimTemplates:
    43. - metadata:
    44. name: www
    45. spec:
    46. accessModes: ["ReadWriteOnce"] # ["ReadWriteOnce","ReadWriteMany"]
    47. storageClassName: managed-nfs-storage
    48. resources:
    49. requests:
    50. storage: 1Gi

    查看pv,pvc和pod的名称以及状态。 

    1. [root@master ~]# k get pvc -A
    2. NAMESPACE NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
    3. default test-claim Bound pvc-39177650-a78e-46d4-899c-7c1f52108280 1Mi RWX managed-nfs-storage 28h
    4. default www-web-0 Bound pvc-ffd14bef-e852-4955-840d-6d3c84d3c3d8 1Gi RWO managed-nfs-storage 19m
    5. default www-web-1 Bound pvc-5fd485a8-9e7b-470f-816f-d674cb5d7648 1Gi RWO managed-nfs-storage 19m
    6. [root@master ~]# k get pv -A
    7. NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
    8. pvc-39177650-a78e-46d4-899c-7c1f52108280 1Mi RWX Delete Bound default/test-claim managed-nfs-storage 28h
    9. pvc-5fd485a8-9e7b-470f-816f-d674cb5d7648 1Gi RWO Delete Bound default/www-web-1 managed-nfs-storage 19m
    10. pvc-ffd14bef-e852-4955-840d-6d3c84d3c3d8 1Gi RWO Delete Bound default/www-web-0 managed-nfs-storage 19m
    11. [root@master ~]# k get po -A |grep web
    12. default web-0 1/1 Running 0 21m
    13. default web-1 1/1 Running 0 21m

    由以上输出可以看到statefulset的命名规则和删除规则:

    statefulset pod的命名规则、pod创建与删除
    如果创建一个名称为web、replicas为3的statefulset对象,则其pod名称分别为web-0、web-1、web-2。

    statefulset pod的创建按0 - n的顺序创建,且在创建下一个pod之前,需要等待前一个pod创建完成并处于ready状态。

    同样拿上面的例子来说明,在web statefulset创建后,2 个 Pod 将按顺序创建 web-0,web-1。在 web-0 处于 ready 状态之前,web-1 将不会被创建。直到 web-0 再次回到ready状态。

    statefulset滚动更新或缩容过程中pod的删除按n - 0的顺序删除,且在删除下一个pod之前,需要等待前一个pod删除完成。

    另外,当statefulset.Spec.VolumeClaimTemplates中定义了pod所需的pvc时,statefulset controller在创建pod时,会同时创建对应的pvc出来,但删除pod时,不会做对应pvc的删除操作,这些pvc需要人工额外做删除操作。
     

    4,Daemonset Controller

    • DaemonSet:服务守护进程,它的主要作用是在Kubernetes集群的所有节点中运行我们部署的守护进程,相当于在集群节点上分别部署Pod副本,如果有新节点加入集群,Daemonset会自动的在该节点上运行我们需要部署的Pod副本,相反如果有节点退出集群,Daemonset也会移除掉部署在旧节点的Pod副本。
    • DaemonSet的主要特征:

    这个 Pod 运行在 Kubernetes 集群里的每一个节点(Node)上;

    每个节点上只会运行一个这样的 Pod 实例;

    如果新的节点加入 Kubernetes 集群后,该 Pod 会自动地在新节点上被创建出来;

    而当旧节点被删除后,它上面的 Pod 也相应地会被回收掉。

    • DaemonSet常用场景:

    网络插件的 Agent 组件,如(Flannel,Calico)需要运行在每一个节点上,用来处理这个节点上的容器网络;
    存储插件的 Agent 组件,如(Ceph,Glusterfs)需要运行在每一个节点上,用来在这个节点上挂载F远程存储目录;
    监控系统的数据收集组件,如(Prometheus Node Exporter,Cadvisor)需要运行在每一个节点上,负责这个节点上的监控信息搜集。
    日志系统的数据收集组件,如(Fluent,Logstash)需要运行在每一个节点上,负责这个节点上的日志信息搜集。

    下面是一个示例,该示例将会在每个node内创建一个nginx-1.9.9版本的pod,除了master节点:

    1. [root@master ~]# cat ds-test.yaml
    2. apiVersion: apps/v1
    3. kind: DaemonSet # 类型为DaeminSet
    4. metadata:
    5. name: deamonset-example
    6. labels:
    7. app: daemonset
    8. spec:
    9. selector:
    10. matchLabels:
    11. name: deamonset-example # 当前这个 daemenset 只管理标签 name=deamonset-example的pod
    12. template:
    13. metadata:
    14. labels:
    15. name: deamonset-example # 设置标签 匹配上文
    16. spec:
    17. containers:
    18. - name: daemonset-example
    19. image: nginx:1.9.9

    5,CronJob Controller和Job Controller

    Job Controller
    简单示例一个,比如,打印π值到2000位,代码如下:

    1. [root@master ~]# cat job-test
    2. apiVersion: batch/v1
    3. kind: Job
    4. metadata:
    5. name: pi
    6. spec:
    7. completions: 3
    8. template:
    9. spec:
    10. containers:
    11. - name: pi
    12. image: registry.cn-beijing.aliyuncs.com/google_registry/perl:5.26
    13. command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
    14. restartPolicy: Never
    15. backoffLimit: 4

    执行这个文件:

    k apply -f job-test.yaml

    查看pod状态:

    1. [root@master ~]# k get po -A |grep pi
    2. default pi-5zzr7 0/1 Completed 0 32m
    3. default pi-nhgqg 0/1 Completed 0 35m
    4. default pi-slf4k 0/1 Completed 0 32m

    查看日志,证明这个job完成了:

    1. [root@master ~]# k logs pi-slf4k
    2. 3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679821480865132823066470938446095505822317253594081284811174502841027019385211055596446229489549303819644288109756659334461284756482337867831652712019091456485669234603486104543266482133936072602491412737245870066063155881748815209209628292540917153643678925903600113305305488204665213841469519415116094330572703657595919530921861173819326117931051185480744623799627495673518857527248912279381830119491298336733624406566430860213949463952247371907021798609437027705392171762931767523846748184676694051320005681271452635608277857713427577896091736371787214684409012249534301465495853710507922796892589235420199561121290219608640344181598136297747713099605187072113499999983729780499510597317328160963185950244594553469083026425223082533446850352619311881710100031378387528865875332083814206171776691473035982534904287554687311595628638823537875937519577818577805321712268066130019278766111959092164201989380952572010654858632788659361533818279682303019520353018529689957736225994138912497217752834791315155748572424541506959508295331168617278558890750983817546374649393192550604009277016711390098488240128583616035637076601047101819429555961989467678374494482553797747268471040475346462080466842590694912933136770289891521047521620569660240580381501935112533824300355876402474964732639141992726042699227967823547816360093417216412199245863150302861829745557067498385054945885869269956909272107975093029553211653449872027559602364806654991198818347977535663698074265425278625518184175746728909777727938000816470600161452491921732172147723501414419735685481613611573525521334757418494684385233239073941433345477624168625189835694855620992192221842725502542568876717904946016534668049886272327917860857843838279679766814541009538837863609506800642251252051173929848960841284886269456042419652850222106611863067442786220391949450471237137869609563643719172874677646575739624138908658326459958133904780275898

    其中有一个参数可以自动清理:

    activeDeadlineSeconds: 10

    这个表示该job运行成功10秒后,自动删除pod,那么,如果是需要看一下log的job,以确认job完成无误的话,这个参数是不可以带的哦。

    CronJob Controller

    示例:启动一个pod,打印容器内时间并打印hello world,代码如下:

    1. [root@master ~]# cat cronjob.yaml
    2. apiVersion: batch/v1beta1
    3. kind: CronJob
    4. metadata:
    5. name: hello
    6. spec:
    7. schedule: "*/1 * * * *"
    8. jobTemplate:
    9. spec:
    10. template:
    11. spec:
    12. containers:
    13. - name: hello
    14. image: busybox
    15. args:
    16. - /bin/sh
    17. - -c
    18. - date; echo "Hello world"
    19. restartPolicy: OnFailure

    可以看到,每一分钟启动一个pod 

    1. [root@master ~]# k get po -A |grep hello
    2. default hello-1661256840-zbz77 0/1 Completed 0 2m19s
    3. default hello-1661256900-cjvsk 0/1 Completed 0 78s
    4. default hello-1661256960-pbmmr 0/1 Completed 0 18s

    查看日志:

    1. [root@master ~]# k logs hello-1661256840-zbz77
    2. Tue Aug 23 12:14:06 UTC 2022
    3. Hello world

    删除该任务:

    1. [root@master ~]# k get cronjob -A
    2. NAMESPACE NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE
    3. default hello */1 * * * * False 1 12s 6m42s
    4. [root@master ~]# k delete cronjob hello
    5. cronjob.batch "hello" deleted

  • 相关阅读:
    云计算要学习哪些技术?
    C程序设计内容与例题讲解 -- 第四章--选择结构程序设计第二部分(第五版)谭浩强
    Kotlin 开发Android app(六):Kotlin 中的空判断 问号和感叹号
    SQL Server进阶知识
    HDFS总结
    Chrome添加扩展程序
    scala中reqiure和assert的区别
    复习中的一些疑点细节
    异地办公也能畅快、无限制远程访问公司内网的解决方案
    CAD机械零件平面绘制练习七、CAD镜像命令高阶绘图练习
  • 原文地址:https://blog.csdn.net/alwaysbefine/article/details/126475257