一，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
