【云原生】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 即可看到。

[root@master ~]# k api-resources
NAME                              SHORTNAMES   APIGROUP                       NAMESPACED   KIND
bindings                                                                      true         Binding
componentstatuses                 cs                                          false        ComponentStatus
configmaps                        cm                                          true         ConfigMap
endpoints                         ep                                          true         Endpoints
events                            ev                                          true         Event
limitranges                       limits                                      true         LimitRange
namespaces                        ns                                          false        Namespace
。。。。。略略略

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

[root@master ~]# cat 00-ns.yaml 
apiVersion: v1
kind: Namespace
metadata:
  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这个控制器：

[root@master ~]# cat demo-replica.yaml 
apiVersion: v1
kind: ReplicationController
metadata:
  name: nginx
spec:
  replicas: 3
  selector:
    app: nginx
  template:
    metadata:
      name: nginx
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80

查询pods如下：

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

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

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

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

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

[root@master ~]# cat demo-replica.yaml 
apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: nginx-test
  labels:
    app: myapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      name: nginx
      labels:
        app: myapp
    spec:
      containers:
      - name: nginx
        image: nginx:1.20.2
        ports:
        - 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要先建立哦）：

[root@master ~]# cat web01.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  namespace: test
  labels:
    app: web01
  name: web01
spec:
  replicas: 1
  selector:
    matchLabels:
      app: web01
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: web01
    spec:
      containers:
      - image: nginx:1.18
        imagePullPolicy: IfNotPresent
        name: nginx
        resources: {}
status: {}

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

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

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

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

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

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

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

当然，扩缩容以及发布等等还有很多的地方可写，比如，蓝灰发布，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是这个：

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

service和StatefulSet一起编写。

apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
     app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  labels:
    app: sts-nginx
  name: web
spec:
  selector:
    matchLabels:
      app: nginx
  serviceName: "nginx"
  replicas: 2
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.18
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes: ["ReadWriteOnce"]  # ["ReadWriteOnce","ReadWriteMany"]
      storageClassName: managed-nfs-storage
      resources:
        requests:
          storage: 1Gi

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

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

[root@master ~]# cat ds-test.yaml 
apiVersion: apps/v1
kind: DaemonSet # 类型为DaeminSet
metadata:
  name: deamonset-example
  labels:
    app: daemonset
spec:
  selector:
    matchLabels:
      name: deamonset-example  # 当前这个 daemenset 只管理标签 name=deamonset-example的pod
  template:
    metadata:
      labels:
        name: deamonset-example  # 设置标签 匹配上文
    spec:
      containers:
      - name: daemonset-example
        image: nginx:1.9.9

5，CronJob Controller和Job Controller

Job Controller

简单示例一个，比如，打印π值到2000位，代码如下：

[root@master ~]# cat job-test
apiVersion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  completions: 3
  template:
      spec:
        containers:
        - name: pi
          image: registry.cn-beijing.aliyuncs.com/google_registry/perl:5.26
          command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
        restartPolicy: Never
  backoffLimit: 4

执行这个文件：

k apply -f job-test.yaml

查看pod状态：

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

查看日志，证明这个job完成了：

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

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

activeDeadlineSeconds: 10

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

CronJob Controller

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

[root@master ~]# cat cronjob.yaml 
apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "*/1 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busybox
            args:
            - /bin/sh
            - -c
            - date; echo "Hello world"
          restartPolicy: OnFailure

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

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

查看日志：

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

删除该任务：

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

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

热门文章

最新文章

相关课程

相关电子书

相关实验场景

推荐镜像