K8S中的API对象_管理操作单元 api对象-优快云博客

本文链接：https://blog.youkuaiyun.com/woshihlf/article/details/145122166

一、API对象

API 对象是 Kubernetes 集群中的管理操作单元。Kubernetes 集群系统每支持一项新功能，引入一项新技术，一定会新引入对应的 API 对象，支持对该功能的管理操作。
每个 API 对象都有 3 大类属性：元数据 metadata、规范 spec 和状态 status。
- 元数据是用来标识 API 对象的，每个对象都至少有 3 个元数据：namespace，name 和 uid；除此以外还有各种各样的标签 labels 用来标识和匹配不同的对象，例如用户可以用标签 env 来标识区分不同的服务部署环境，分别用 env=dev、env=testing、env=production 来标识开发、测试、生产的不同服务。
- 规范描述了用户期望 Kubernetes 集群中的分布式系统达到的理想状态，例如用户可以通过复制控制器 Replication Controller 设置期望的 Pod 副本数为 3；
- status 描述了系统实际当前达到的状态，例如系统当前实际的 Pod 副本数为 2；那么复制控制器当前的程序逻辑就是自动启动新的 Pod，争取达到副本数为 3。
Kubernetes 中所有的配置都是通过 API 对象的 spec 去设置的，也就是用户通过配置系统的理想状态来改变系统，这是 Kubernetes 重要设计理念之一，即所有的操作都是声明式（Declarative）的而不是命令式（Imperative）的。 声明式操作在分布式系统中的好处是稳定，不怕丢操作或运行多次，例如设置副本数为 3 的操作运行多次也还是一个结果，而给副本数加 1 的操作就不是声明式的，运行多次结果就错了。

二、Node

K8S的Master Node具备：请求入口管理（API Server），Worker Node调度（Scheduler），监控和自动调节（Controller），以及存储功能（etcd）；
而 K8S的Worker Node具备：状态和监控收集（Kubelet），网络和负载均衡（Kube-Proxy）、保障容器化运行环境（Container Runtime）、以及定制化功能（Add-Ons）。
node节点
- K8S是属于主从设备模型（Master-Slave架构），即有Master节点负责核心的调度、管理和运维，Slave节点则在执行用户的程序。但是在K8S中，主节点一般被称为Master Node或者Head Node，而从节点则被称为Worker Node或者Node。
- Master Node和Worker Node是分别安装了K8S的Master和Woker组件的实体服务器，每个Node都对应了一台实体服务器（虽然Master Node可以和其中一个Worker Node安装在同一台服务器，但是建议Master Node单独部署），所有Master Node和Worker Node组成了K8S集群，同一个集群可能存在多个Master Node和Worker Node。
Master Node中的组件
- API Server。
  - K8S的请求入口服务。API Server负责接收K8S所有请求（来自UI界面或者CLI命令行工具），然后，API Server根据用户的具体请求，去通知其他组件干活。从图中可以知道，API Server实际可以部署多个实例，以增大请求吞吐。
- Scheduler。
  - **K8S中的调度服务。当用户要部署服务时，Scheduler会选择最合适的Worker Node（服务器）来部署。**从上图可以知道，Scheduler也可以部署多个实例，以增大处理能力。
- Controller Manager。
  - K8S的控制服务。Controller Manager本身就是总称，实际上有很多具体的Controller，Node Controller、Service Controller、Volume Controller等分别负责不同K8S对象。 举个例子，比如用户要求A服务部署2个副本，那么当其中一个服务挂了的时候，Controller会马上调整，让Scheduler再选择一个Worker Node重新部署服务。
- etcd。
  - K8S的存储服务。etcd存储了K8S的关键配置和用户配置，K8S中仅API Server才具备读写权限，其他组件必须通过API Server的接口才能读写数据。
Worker Node中的组件
- Kubelet。
  - Worker Node的监视器，以及与Master Node的通讯器。 Kubelet是Master Node安插在Worker Node上的“眼线”，它会定期向Master Node汇报自己Node上运行的服务的状态，并接受来自Master Node的命令，并执行。
- Kube-Proxy。
  - K8S的网络代理。Kube-Proxy负责Node在K8S的网络通讯、以及对外部网络流量的负载均衡。
- Container Runtime。
  - Worker Node的运行环境。即安装了容器化所需的软件环境确保容器化程序能够跑起来，比如Docker Engine。大白话就是帮忙装好了Docker运行环境。
- Logging Layer。
  - K8S的监控状态收集器。Logging Layer负责采集Node上所有服务的CPU、内存、磁盘、网络等监控项信息。
- Add-Ons。
  - K8S管理运维Worker Node的插件组件。K8S系统提供了Add-On机制，让用户可以扩展更多定制化功能，是很不错的亮点。

三、Pod

Pod 是在 Kubernetes 集群中运行部署应用或服务的最小单元，它是可以支持多容器的。 Pod 的设计理念是支持多个容器在一个 Pod 中共享网络地址和文件系统，可以通过进程间通信和文件共享这种简单高效的方式组合完成服务。Pod 对多容器的支持是 K8 最基础的设计理念。
目前 Kubernetes 中的业务主要可以分为长期伺服型（long-running）、批处理型（batch）、节点后台支撑型（node-daemon）和有状态应用型（stateful application）；分别对应的控制器为 Deployment、Job、DaemonSet 和 StatefulSet。

四、Controller

Replication Controller，RC

RC 是 Kubernetes 集群中最早的保证 Pod 高可用的 API 对象。 通过监控运行中的 Pod 来保证集群中运行指定数目的 Pod 副本。指定的数目可以是多个也可以是 1 个；少于指定数目，RC 就会启动运行新的 Pod 副本；多于指定数目，RC 就会杀死多余的 Pod 副本。
即使在指定数目为 1 的情况下，通过 RC 运行 Pod 也比直接运行 Pod 更明智，因为 RC 也可以发挥它高可用的能力，保证永远有 1 个 Pod 在运行。 RC 是 Kubernetes 较早期的技术概念，只适用于长期伺服型的业务类型，比如控制小机器人提供高可用的 Web 服务。

ReplicaSet，RS

RS 是新一代 RC，提供同样的高可用能力，区别主要在于 RS 后来居上，能支持更多种类的匹配模式。副本集对象一般不单独使用，而是作为 Deployment 的理想状态参数使用。

Deployment

在这里插入图片描述

deployment是一个比 RS 应用模式更广的 API 对象，可以是创建一个新的服务，更新一个新的服务，也可以是滚动升级一个服务。
引入这样子的层级管理制度是为了实现前后两个版本平滑升级、平滑回滚等高级功能。 当更新 Deployment 的 PodTemplateSpec 时，会创建一个新的 ReplicaSet，Deployment 会按照控制的速率将 pod 从旧的 ReplicaSet 移动到新的 ReplicaSet 中。
假如您创建了一个有 5 个niginx:1.7.9replica 的 Deployment，但是当还只有 3 个nginx:1.7.9的 replica 创建出来的时候您就开始更新含有 5 个nginx:1.9.1replica 的 Deployment。在这种情况下，Deployment 会立即杀掉已创建的 3 个nginx:1.7.9的 Pod，并开始创建nginx:1.9.1的 Pod。它不会等到所有的 5 个nginx:1.7.9的 Pod 都创建完成后才开始改变航道。

HPA

在这里插入图片描述

我们已经可以通过手动执行 kubectl scale 命令实现Pod的扩缩容，但是这显然不符合 Kubernetes 的定位目标–自动化和智能化。Kubernetes 期望可以通过监测Pod的使用情况，实现 Pod 数量的自动调整，于是就产生了 HPA 这种控制器。
HPA 可以获取每个 Pod 的利用率，然后和 HPA 中定义的指标进行对比，同时计算出需要伸缩的具体值，最后实现 Pod 的数量的调整。 其实 HPA 和之前的 Deployment 一样，也属于一种 Kubernetes 资源对象，它通过追踪分析目标Pod的负载变化情况，来确定是否需要针对性的调整目标 Pod 的副本数。

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: k8s-hpa
spec:
  minReplicas: 1 # 最小 Pod 数量
  maxReplicas: 10 # 最大 Pod 数量
  targetCPUUtilizationPercentage: 3 # CPU 使用率指标，即 CPU 超过 3%（Pod 的 limit 的 cpu ） 就进行扩容
  scaleTargetRef:  # 指定要控制的Nginx的信息
    apiVersion: apps/v1
    kind: Deployment
    name: nginx-deploy

Job

Job 是 Kubernetes 用来控制批处理型任务的 API 对象。 批处理业务与长期伺服业务的主要区别是批处理业务的运行有头有尾，而长期伺服业务在用户不停止的情况下永远运行。
Job 管理的 Pod 根据用户的设置把任务成功完成就自动退出了。 成功完成的标志根据不同的 spec.completions 策略而不同：单 Pod 型任务有一个 Pod 成功就标志完成；定数成功型任务保证有 N 个任务全部成功；工作队列型任务根据应用确认的全局成功而标志成功。

CronJobCronJob

在这里插入图片描述

其实就是在Job的基础上加上了时间调度，我们可以：在给定的时间点运行一个任务，也可以周期性地在给定时间点运行。这个实际上和我们Linux中的crontab就非常类似了。
一个CronJob对象其实就对应crontab文件中的一行，它根据配置的时间格式周期性地运行一个Job，格式和crontab也是一样的。

DaemonSet

DaemonSet 确保指定的 Pod 在集群中的每个节点上运行一个实例，或者根据你定义的节点选择器在特定的节点上运行。它适用于需要在每个节点上运行的服务，如日志收集器、监控代理等。
长期伺服型和批处理型服务的核心在业务应用，可能有些节点运行多个同类业务的 Pod，有些节点上又没有这类 Pod 运行；而后台支撑型服务的核心关注点在 Kubernetes 集群中的节点（物理机或虚拟机），要保证每个节点上都有一个此类 Pod 运行。节点可能是所有集群节点也可能是通过 nodeSelector 选定的一些特定节点。 典型的后台支撑型服务包括，存储，日志和监控等在每个节点上支持 Kubernetes 集群运行的服务。

StatefulSet

RC主要是控制提供无状态服务的，其所控制的 Pod 的名字是随机设置的，一个 Pod 出故障了就被丢弃掉，在另一个地方重启一个新的 Pod，名字变了。名字和启动在哪儿都不重要，重要的只是 Pod 总数。对于 RC 和 RS 中的 Pod，一般不挂载存储或者挂载共享存储，保存的是所有 Pod 共享的状态。
而 StatefulSet 是用来控制有状态服务， StatefulSet 中的每个 Pod 的名字都是事先确定的，不能更改。对于 StatefulSet 中的 Pod，每个 Pod 挂载自己独立的存储，如果一个 Pod 出现故障，从其他节点启动一个同样名字的 Pod，要挂载上原来 Pod 的存储继续以它的状态提供服务。
适合于 StatefulSet 的业务包括数据库服务 MySQL 和 PostgreSQL，集群化管理服务 ZooKeeper、etcd 等有状态服务。StatefulSet 的另一种典型应用场景是作为一种比普通容器更稳定可靠的模拟虚拟机的机制。
使用 StatefulSet，Pod 仍然可以通过漂移到不同节点提供高可用，而存储也可以通过外挂的存储来提供高可靠性，StatefulSet 做的只是将确定的 Pod 与确定的存储关联起来保证状态的连续性。

五、网络

Service

一个 Pod 只是一个运行服务的实例，随时可能在一个节点上停止，在另一个节点以一个新的 IP 启动一个新的 Pod，因此不能以确定的 IP 和端口号提供服务。要稳定地提供服务需要服务发现和负载均衡能力。
服务发现完成的工作，是针对客户端访问的服务，找到对应的的后端服务实例。在 K8 集群中，客户端需要访问的服务就是 Service 对象。 每个 Service 会对应一个集群内部有效的虚拟 IP，集群内部通过虚拟 IP 访问一个服务。
在 Kubernetes 集群中微服务的负载均衡是由 Kube-proxy 实现的。Kube-proxy 是 Kubernetes 集群内部的负载均衡器。 它是一个分布式代理服务器，在 Kubernetes 的每个节点上都有一个；这一设计体现了它的伸缩性优势，需要访问服务的节点越多，提供负载均衡能力的 Kube-proxy 就越多，高可用节点也随之增多。与之相比，我们平时在服务器端做个反向代理做负载均衡，还要进一步解决反向代理的负载均衡和高可用问题。
Service是K8S服务的核心，屏蔽了服务细节，统一对外暴露服务接口。 举个例子，我们的一个服务A，部署了3个备份，也就是3个Pod；对于用户来说，只需要关注一个Service的入口就可以，而不需要操心究竟应该请求哪一个Pod。优势非常明显：一方面外部用户不需要感知因为Pod上服务的意外崩溃、K8S重新拉起Pod而造成的IP变更，外部用户也不需要感知因升级、变更服务带来的Pod替换而造成的IP变化，另一方面，Service还可以做流量负载均衡。
Service有三种类型，分别是ClusterIP，NodePort和LoadBalance。
- CluterIP类型的Service会提供一个’CLUSTER-IP’和’PORT(S)'，能够允许k8s内部相同namespace下的任何Pod访问。
- NodePort实际是在Pod所在的物理机器上开了一个端口，让外部流量从这个端口先导流到自己的’port’，再导入’targetPort’（也就是Pod的端口）。
- NodePort类型/机制仅仅提供了对k8s集群外访问的方式，很快就会发现这种方法违背了Service流量均衡负载的策略，因为通过Pod所在机器IP访问的流量，只能够导入到该机器上的Pod，其他机器上就不行了。因此就有了LoadBalancer。
- LoadBalancer的做法是在NodePort基础上增加一个EXTERNAL-IP，集群外部调用该IP+自定义的port就能够访问Pod。

Ingress

在这里插入图片描述

Ingress：
- Ingress是管理外部访问应用的规则集，它提供了管理HTTP和HTTPS路由的配置。
- Ingress对象允许你通过定义URL路径和主机名来控制如何将外部请求路由到集群中的Service。
- Ingress通常与Ingress Controller一起工作，Ingress Controller是负责实现Ingress规则的组件。
- 在定义入口和出口策略之前，你必须首先启动被称为 Ingress Controller（入口控制器）的组件。
关系：
- Ingress依赖于Service来完成其工作。当你创建了一个Ingress资源后，它会指定如何将外部流量路由到集群内的Service。
- Ingress作为对外的HTTP和HTTPS流量的入口点，而Service则负责将这些流量转发到后端的Pod。
- Ingress可以为Service提供额外的功能，如SSL终止、名称基的虚拟主机、路径基的路由等。
工作流程：
- 用户通过Ingress Controller暴露的外部地址（如域名或IP）访问集群。
- Ingress Controller检查Ingress资源中定义的规则，以确定请求应该被路由到哪个Service。
- Ingress Controller将请求转发到相应的Service。
- Service接收请求并将其转发到后端的Pod。

六、存储

在这里插入图片描述

Volume

Volume是“卷”，包含各种各样的类型，是基础抽象，他可以是临时的，也可以是持久的。Volume可以简单理解成一个虚空中的存储空间，单单做了Volume的声明。
- emptyDir：Pod 生命周期内临时存储，Pod 删除后数据丢失。
- hostPath：直接使用节点文件系统上的目录，HostPath是一种持久化存储，但是HostPath的内容是存储在节点上，导致只适合读取，不适合分布式场景。
- configMap 和 secret：用于存储配置信息和敏感数据。
- persistentVolumeClaim（PVC）：用户请求的持久化存储资源。
- other types：如 NFS、CephFS 等，用于网络文件系统。
VolumeMount是Pod中的容器中用来描述如何将Volume挂载到Pod内部的容器上的字段。它定义了Volume在容器内的具体挂载路径和访问模式。

PV

**PersistentVolume 是 Kubernetes 中持久化存储的抽象，代表集群中实际存在的存储资源。**PV 是由管理员预先配置的存储资源，支持多种后端存储，如本地磁盘、网络存储（如 NFS、iSCSI、GlusterFS）。

PVC

PersistentVolumeClaim（持久卷声明）是用户对存储资源的请求，它指定了存储的大小、访问模式等要求。 PVC允许用户消耗抽象的存储资源，而不需要关心存储的具体实现细节。当PVC与PV绑定后，PV将专门为该PVC服务，直到PVC被删除。
PV 和 PVC 使得 Kubernetes 集群具备了存储的逻辑抽象能力，使得在配置 Pod 的逻辑里可以忽略对实际后台存储技术的配置，而把这项配置的工作交给 PV 的配置者，即集群的管理者。存储的 PV 和 PVC 的这种关系，跟计算的 Node 和 Pod 的关系是非常类似的；PV 和 Node 是资源的提供者，根据集群的基础设施变化而变化，由 Kubernetes 集群管理员配置；而 PVC 和 Pod 是资源的使用者，根据业务服务的需求变化而变化，有 Kubernetes 集群的使用者即服务的管理员来配置。