Kubernetes Pod调度基础（kubernetes）

实验环境依旧是k8s快照，拉取本次实验所需的镜像文件；

然后在master节点上传已经编写好的yaml文件；

然后同步会话，导入镜像；

pod控制器：

标签选择器--》标签：

标签：

在Kubernetes（k8s）中，标签（Labels）是一种非常重要的机制，用于对资源对象（如Pods、Nodes、Services等）进行分类和识别。标签以键值对的形式存在，可以附加到资源对象上，以便进行后续的管理和选择。以下是k8s中标签的定义方式的详细解释：

一、标签的定义

标签（Labels）在Kubernetes中是通过键值对（key=value）的形式来定义的。每个资源对象都可以附加任意数量的标签，而同一个标签也可以被附加到多个资源对象上。这种多对多的关系使得标签成为了一种灵活且强大的资源分类和管理工具。

二、标签的语法规则

• 键（Key）：键的命名需要遵守一定的规则，通常建议以字母或数字开头，后面可以跟字母、数字、下划线（_）、破折号（-）和点（.）。键的长度不能超过63个字符。此外，虽然前缀是可选的，但如果指定了前缀，则前缀必须符合DNS子域名的命名规则。

• 值（Value）：值可以为空，也可以包含字母、数字、下划线（_）、破折号（-）和点（.）。值的长度同样不能超过63个字符。如果值非空，则必须以字母或数字开头和结尾。

标签定义的方式：

基于等式的定义 ：app=nginx

基于键值对的定义方式 ：app： nginx

基于集合的标签定义方式 ：{key：app，operator：In，values：[nginx，apache]}

app：nginx

app：apache

在Kubernetes（k8s）中，选择器（Selector）是一个非常重要的概念，它用于定义一组资源的选取规则。这些资源通常是Pods（容器的实例），但也可以扩展到其他Kubernetes对象，如Services、Deployments等。选择器的主要作用是帮助Kubernetes对资源进行分组和选择，以便进行调度、扩展、滚动更新等操作。

复制控制器（replication controller；RC）：

让你的pod的副本数，保持在你的“预期值”

复制集控制器 (RS)

复制集控制器是复制控制器的升级版；支持基于集合的标签定义方式；

deployment（部署）（无状态集控制器）是RS的管理者。能够管理复制集控制器

滚动更新

修改副本数（扩缩容）

无状态服务：nginx、apache（tomcat）不需要持久化存储数据；没有任何依赖的环境；例如mysql中的主从复制架构就是有状态的服务；

有状态集控制器 （STS）

mysql、redis、kafka、rabbitmq

删除方式：非级联、级联

守护进程集控制器 (DS)

能够在创建pod的时候，在每一个节点上都创建出来一个。不必指定副本数。

自动按照节点的数量来匹配出一个副本数。

即：副本数和node节点数相同；

计划任务控制器

在Kubernetes（简称K8s）中，有状态集（StatefulSet）和无状态集（通常通过Deployment来管理无状态应用）是两种用于部署和管理不同类型应用程序的机制。它们在处理应用程序的状态、存储、网络以及扩展性等方面存在显著差异。以下是关于有状态集和无状态集的主要区别：

一、状态与存储

1. 有状态集（StatefulSet）

1. 无状态集（Deployment）

二、网络与身份

1. 有状态集（StatefulSet）

1. 无状态集（Deployment）

三、扩展性与管理

1. 有状态集（StatefulSet）

1. 无状态集（Deployment）

四、典型应用场景

• 有状态集（StatefulSet）：适用于需要持久化存储和稳定网络标识的应用程序，如数据库、消息队列、Redis等。

• 无状态集（Deployment）：适用于无状态的应用程序，如Web服务器、微服务中的某些组件等。

综上所述，有状态集和无状态集在Kubernetes中扮演着不同的角色，分别适用于不同类型的应用程序。选择哪种机制取决于应用程序的具体需求和特点。

打开一个复制控制器的yaml文件（资源对象清单）进行查看；

apiVersion: v1

# 指定了Kubernetes API的版本，这里是v1，表示使用Kubernetes的核心API版本1。

kind: ReplicationController

# 声明了这个YAML文件定义的资源类型为ReplicationController。

metadata:

name: nginx

# 定义了ReplicationController的元数据，这里指定了它的名称为nginx。

spec:

replicas: 3

# 在spec部分，指定了ReplicationController应该管理的Pod副本数量为3。

selector:

app: nginx

# selector用于选择哪些Pod应该被这个ReplicationController管理。这里通过标签选择器指定了所有带有app=nginx标签的Pod。

template:

metadata:

name: nginx

# 注意：在ReplicationController的Pod模板中指定name通常是不必要的，因为每个Pod的实例都会有自己的唯一名称。

# 这里的name更多是为了示例或文档目的，实际部署时Kubernetes会忽略它。

labels:

app: nginx

# 定义了Pod模板的元数据，包括标签，这些标签用于匹配selector中的选择器。

spec:

containers:

- name: nginx

# 定义了Pod中运行的容器。

image: nginx:1.7.9

# 指定了容器使用的镜像，这里是nginx的1.7.9版本。

ports:

- containerPort: 80

# 定义了容器内部监听的端口，这里是80端口，用于HTTP服务。

然后执行下该文件；

-前是我们手动指定的pod的名字，而-后是每个副本的名称；

现在删除一个查看下；

可以看出，删除完了之后会被再次创建出来一个新的副本；

这就是复制控制器的特点；

利用yaml文件生成的对象，想要删除的时候也要指定该文件；

打开第二个复制集控制器的文件：

复制集控制器是复制控制器的升级版；支持基于集合的标签定义方式；

yaml文件中只要看到template指的就是pod的模版：后面定义的就是pod的参数；

apiVersion: apps/v1 # API版本

kind: ReplicaSet # 资源类型，这里是ReplicaSet

metadata: # 元数据

name: frontend # ReplicaSet的名称

labels: # 标签，用于分类和选择

app: guestbook # 应用标签

tier: frontend # 层级标签

spec: # 规格说明

replicas: 3 # 副本数量

selector: # 选择器，用于匹配Pods

matchLabels: # 基于标签的选择

tier: frontend # 匹配层级为frontend的Pods

template: # Pod模板

metadata: # Pod的元数据

labels: # Pod的标签

app: guestbook

tier: frontend

spec: # Pod的规格说明

containers: # 容器列表

- name: php-redis # 容器名称，但注意这里使用的镜像应该是nginx，可能与容器名不匹配

image: nginx:1.7.9 # 容器镜像，这里应该是PHP-Redis的镜像，但示例中使用了nginx

resources: # 资源请求

requests: # 请求的资源量

cpu: 100m # CPU请求量

memory: 100Mi # 内存请求量

env: # 环境变量

- name: GET_HOSTS_FROM

value: dns # 从DNS获取服务主机信息

# 如果您的集群配置不包括DNS服务，而是想从环境变量中获取服务主机信息，

# 请注释掉上面的'value: dns'行，并取消注释下面的行。

# value: env

ports: # 端口列表

- containerPort: 80 # 容器端口

创建出来并查看：

删除的时候可以指定类型加名称删除；

但是建议和创建的时候方法一样；即：以指定文件去删除；

打开deployment的文件：

apiVersion: apps/v1 # API版本，指明使用的Kubernetes API的版本

kind: Deployment # 资源类型，这里是Deployment

metadata: # 元数据

name: nginx-deployment # Deployment的名称

labels: # 标签，用于标识和选择Deployment

name: nginx-deployment # 标签名称和值

spec: # 规格说明，定义了Deployment的具体参数

replicas: 2 # 副本数量，指明要运行的Pod副本数量

selector: # 选择器，用于选择哪些Pod受当前Deployment管理

matchLabels: # 匹配标签

app: nginx # 需要与Pod模板中的标签相匹配

template: # Pod模板，定义了要创建的Pod的配置

metadata: # Pod的元数据

labels: # Pod的标签

app: nginx # Pod的标签名称和值，用于与选择器中的标签匹配

spec: # Pod的规格说明

containers: # 容器列表，定义了Pod中要运行的容器

- name: nginx # 容器的名称

image: nginx:1.7.9 # 容器使用的镜像及其版本

ports: # 容器端口列表

- name: nginx # 端口名称

containerPort: 80 # 容器监听的端口号

应用：

以简写（deploy）的方式查看:

如何使用deployment的滚动更新特性：

可以查看deployment的描述信息：

看最后event事件信息：

更新的时候会先关闭，然后更新，更新完了之后会再启动起来；

查看滚动更新的历史：

怎么回滚到之前的版本：

因为此次只更新了一次，无法回滚到第一次创建的时候，以及无法回滚到当前的状态；

第一次是1；现在的状态为2；

deployment还能指定副本数，实现扩缩容：

缩容：

打开守护进程集的文件；

apiVersion: apps/v1 # API版本，指定了Kubernetes API的版本

kind: DaemonSet # 资源类型，这里是DaemonSet，用于在每个节点上运行一个Pod副本

metadata: # 元数据

name: pod-controller # DaemonSet的名称

namespace: dev # 命名空间，指定了DaemonSet所在的命名空间

labels: # 标签，用于标识和选择DaemonSet

controller: daemonset # 标签名称和值

spec: # 规格说明，定义了DaemonSet的具体参数

selector: # 选择器，用于选择哪些Pod受当前DaemonSet管理

matchLabels: # 匹配标签

app: nginx-pod # 需要与Pod模板中的标签相匹配

template: # Pod模板，定义了要在每个节点上运行的Pod的配置

metadata: # Pod的元数据

labels: # Pod的标签

app: nginx-pod # Pod的标签名称和值，用于与选择器中的标签匹配

spec: # Pod的规格说明

containers: # 容器列表，定义了Pod中要运行的容器

- name: nginx # 容器的名称

image: nginx:1.7.9 # 容器使用的镜像及其版本

ports: # 容器端口列表

- name: nginx-port # 端口名称

containerPort: 80 # 容器监听的端口号

protocol: TCP # 端口协议，这里是TCP

创建出来：

提示当要用该文件创建的时候，名字为“dev”的命名空间没有创建；

由于文件中指定了命名空间；所以会有这样的提示；

所以要在创建前创建出一个命名空间；

因为守护进程集的特性会在每个工作节点上创建，所以可以进行查看：

打开有状态集控制器的文件；

服务（Service）部分：

apiVersion: v1 # API版本，指定了Kubernetes API的版本

kind: Service # 资源类型，这里是Service，用于定义一组Pod的访问策略

metadata:

name: redis-svc # 服务的名称

spec:

selector: # 选择器，用于选择哪些Pod的IP地址和端口号被此服务代理

app: redis-sts # 标签选择器，与StatefulSet中Pod的标签相匹配

ports: # 端口列表，定义了服务监听的端口和将流量转发到的目标端口

- port: 6379 # 服务监听的端口号

protocol: TCP # 端口协议，这里是TCP

targetPort: 6379 # 目标端口号，即Pod中容器监听的端口号

这个服务定义了一个名为redis-svc的服务，它使用标签选择器app: redis-sts来匹配Pod，并将流量从服务的6379端口转发到匹配的Pod的6379端口。

有状态集（StatefulSet）部分：

apiVersion: apps/v1 # API版本，指定了Kubernetes API的版本

kind: StatefulSet # 资源类型，这里是StatefulSet，用于管理有状态的应用

metadata:

name: redis-sts # StatefulSet的名称

spec:

serviceName: redis-svc # 服务的名称，这个服务必须已经存在，用于Pod的DNS发现

replicas: 2 # 副本数量，指定StatefulSet中Pod的副本数量

selector: # 选择器，用于选择哪些Pod由这个StatefulSet管理

matchLabels:

app: redis-sts # 标签选择器，与Pod模板中的标签相匹配

template: # Pod模板，定义了StatefulSet中每个Pod的配置

metadata:

labels:

app: redis-sts # Pod的标签，用于与StatefulSet选择器的标签相匹配

spec:

containers: # 容器列表，定义了Pod中要运行的容器

- image: redis:5-alpine # 容器使用的镜像及其版本

name: redis # 容器的名称

ports: # 容器端口列表

- containerPort: 6379 # 容器监听的端口号

创建出来，观察它的特性：

有状态集控制器往往带有依赖性，所以启动的时候会有先后顺序的；

例如：mysql的主从架构，肯定是要先启动主再启动从的。

而deployment生成的时候没有顺序性，所以它pod的名字也没有规律。

如何扩展：

再去扩展：

缩容：

也是具有顺序性的缩容；

会先去掉第四个，再去掉第三个。

和其他资源对象不一样的是删除的时候有区别的。

有状态集有两种删除的方式：

先采用非级联的方式删除：

sts没了，但是pod还在。

第一步先非级联的删除有状态集，再删除里面的pod；

要么直接用级联的方式删除；即：删除yaml文件即可；

为了演示，先把它创建出来：

先把pod删除掉；因为控制器已经被删除了，所以不会自动创建出来的。

采用级联的方式删除：

第二种级联方式的删除：

最后一个计划任务控制器：

这个YAML文件定义了一个Kubernetes CronJob资源，用于定期执行一个计划任务。

以下是对这个YAML文件的详细翻译和解释，同时确认apiVersion已经正确设置为batch/v1，适用于Kubernetes 1.21及以上版本。

apiVersion: batch/v1 # 指定API版本为batch/v1，适用于CronJob资源

kind: CronJob # 定义资源的类型为CronJob

metadata:

name: hello # CronJob的名称设置为hello

spec:

schedule: "*/1 * * * *" # Cron作业的执行计划，这里表示每分钟执行一次

jobTemplate: # 定义了作业模板，CronJob将基于这个模板创建作业

spec:

template: # 定义了作业的Pod模板

spec:

containers: # 定义了Pod中的容器列表

- name: hello # 容器的名称

image: busybox:v1 # 容器使用的镜像，这里是busybox的v1版本

args: # 传递给容器内命令的参数列表

- /bin/sh # 容器内要执行的命令是/bin/sh

- -c # -c参数告诉sh执行后面的字符串作为命令

- date; echo Hello from the Kubernetes cluster # 要执行的命令，首先打印当前日期，然后打印一条消息

restartPolicy: OnFailure # 定义了Pod的重启策略，这里是在容器失败时重启

创建出来并查看：

会发现并没有直接被创建出来：

再去查看就有了；

而且状态是已完成的状态；

因为该pod在运行的时候只是让pod里面的容器运行了一条指令，立马就运行完了。

查看该pod的日志；

每分钟会生成一个pod；