【K8S系列】深入解析无状态服务

 

目录

序言

1. 无服务介绍

1.1 优点

1.2 使用场景

1.3 资源类型

1.4 总结

2 使用介绍

2.1 Deployment

使用场景：

2.2 ReplicaSet

使用场景

2.3 pod

Pod 资源定义示例

2.4 service

创建一个Deployment：

创建一个Service：

总结：

2.5 ingress

安装Ingress控制器

创建Ingress规则

 应用Ingress规则

访问服务

总结：

2.6 configMap

3 总结

使用场景总结

 ReplicaSet 和 Deployment区别总结：

---

序言

所有幸运和巧合的事，要么是上天注定，要么是一个人偷偷的在努力。

文章标记颜色说明：

• 黄色：重要标题
• 红色：用来标记结论
• 绿色：用来标记一级论点
• 蓝色：用来标记二级论点

Kubernetes (k8s) 是一个容器编排平台，允许在容器中运行应用程序和服务。今天学习一下无状态服务。

1. 无服务介绍

无状态服务是一种不需要保存任何数据状态的服务，也不需要维护任何会话信息的服务。

这些服务通常被设计为可扩展和高可用性的，因为它们可以在任何时间点部署或删除，而不会对应用程序的可用性产生影响。

1.1 优点

无状态服务的优点包括：

1. 可扩展性：由于无状态服务不需要维护状态信息，因此它们可以轻松地水平扩展，以应对高流量和负载情况。

2. 高可用性：无状态服务可以通过多个副本来提高可用性，并且它们可以在任何时间点部署或删除，而不会影响应用程序的可用性。

3. 简单性：由于无状态服务不需要维护状态信息，因此它们通常比有状态服务更简单、更容易维护。

1.2 使用场景

以下是一些无状态服务的使用场景详细介绍：

1. 网络应用程序：无状态服务非常适合网络应用程序，例如Web服务器、API服务器、负载均衡器等。这些应用程序可以通过多个副本来提高可用性，并且它们可以通过水平扩展来处理更多的请求。

2. 批处理作业：无状态服务也可以用于批处理作业，例如数据处理、日志分析、图像处理等。这些作业可以在任何时间点启动或停止，并且可以在多个节点上并行运行以提高效率。

3. 队列服务：无状态服务还可以用于队列服务，例如消息队列、任务队列等。这些服务可以将消息或任务发送到队列中，并由多个工作者节点消费它们，以提高处理效率。

1.3 资源类型

在Kubernetes中，无状态服务资源类型主要包括以下几种：

1. Deployment：Deployment是一种用于创建可扩展的无状态服务的资源类型。它允许定义副本数，并使用Rolling Update策略来升级服务，从而保持服务的可用性。

2. ReplicaSet：ReplicaSet是Deployment的底层实现，用于确保在任何时间点都有指定数量的Pod副本在运行。当Pod崩溃或者被删除时，ReplicaSet会自动创建新的Pod副本，以确保所需的Pod副本数不变。

3. Pod：Pod是Kubernetes中最小的可部署单元，用于运行一个或多个容器。通常，每个Pod只运行一个容器，但在某些情况下，可能需要在同一个Pod中运行多个容器。

4. Service：Service是一种用于将多个Pod打包在一起并提供访问它们的统一入口的资源类型。Service可以使用Cluster IP、NodePort或者LoadBalancer等不同类型的服务来暴露Pod。

5. Ingress ：Ingress 是一种 k8s 资源类型，用于将集群内部的 HTTP 和 HTTPS 流量路由到 Service 上。Ingress 可以根据域名或 URL 路径将流量转发到不同的 Service 上，并支持 SSL/TLS 终止和负载均衡等功能。

6. ConfigMap：ConfigMap 是一种 k8s 资源类型，用于将配置信息注入到无状态服务中。ConfigMap 可以存储键值对和配置文件等信息，并将它们作为环境变量、命令行参数或配置文件挂载到 Pod 中。

Ingress 和 Service、ConfigMap 一样，都是 Kubernetes 中的资源对象，它们都是抽象的概念，不包含任何具体的状态信息。Ingress 只是定义了一组规则，而 Service 则定义了如何暴露一个或多个 Pod，以便可以从集群内部或外部访问它们。因此，Ingress 和 Service 都可以看作是无状态的 Kubernetes 资源对象。

总之，使用Kubernetes中的无状态服务资源类型，可以更轻松地管理和扩展无状态服务，并提高其可用性和可靠性。

1.4 总结

无状态服务并不适用于所有的应用程序。一些应用程序可能需要维护会话信息、状态信息或持久化数据，这就需要使用有状态服务。

因此，在设计应用程序时，需要考虑应用程序的特定要求，以确定应该使用无状态服务还是有状态服务。 

2 使用介绍

2.1 Deployment

Deployment资源控制器将用户定义的Deployment对象转换为实际运行的Pods，并确保Pods的状态与用户定义的状态一致。如果某个Pod因为某些原因被删除了，Deployment控制器会启动一个新的Pod，以确保在任何时候都有指定数量的Pods在运行。

Deployment 是 Kubernetes 中一种常用的资源类型，用于定义一组可扩展的 Pod，并确保它们按照所需的副本数在集群中运行。

Deployment 可以：

• 确保应用程序在集群中始终以所需的副本数运行。
• 自动升级应用程序，以便部署新的版本。
• 自动回滚到以前的版本，以便应对故障情况。
• 通过滚动升级、重启或暂停来更新部署。

下面是一个使用 Deployment 创建一个可扩展的 nginx 服务的示例：

apiVersion: apps/v1
kind: Deployment #资源类型
metadata:name: nginx-deployment
spec:replicas: 3selector:matchLabels:app: nginxtemplate:metadata:labels:app: nginxspec:containers:- name: nginximage: nginx:latestports:- containerPort: 80

该示例使用了 Deployment 资源来创建一个名为 nginx-deployment 的部署。该部署将创建 3 个副本，并使用 label 选择器来识别与该部署关联的 Pod。

该示例的 Pod 使用了 nginx:latest 镜像，并且暴露了容器端口 80。

要部署该示例，将 YAML 文件保存为 nginx-deployment.yaml 并运行以下命令：

kubectl apply -f nginx-deployment.yaml

该命令将在集群中创建一个名为 nginx-deployment 的 Deployment，并自动创建与其相关的 3 个 Pod。

要更新部署的镜像，可以通过编辑 YAML 文件并运行以下命令来轻松更新：

kubectl apply -f nginx-deployment.yaml

Kubernetes 将自动将更新部署，并逐步将所有 Pod 升级到新版本。

总结一下，Deployment 资源是 Kubernetes 中一个非常有用的资源类型，它使得容器化应用程序的部署和管理变得更加容易和可靠。

使用场景：

1. 应用程序部署：使用 Kubernetes Deployment 可以轻松地部署您的应用程序，并确保它们始终以所需的方式运行。您可以定义应用程序的副本数、容器映像、存储和网络设置等。

2. 应用程序升级和回滚：使用 Kubernetes Deployment 可以轻松地升级和回滚您的应用程序。您可以定义应用程序的新版本，并控制升级的速率和流程。如果需要回滚，则可以通过简单的命令将应用程序回退到旧版本。

3. 水平扩展：使用 Kubernetes Deployment 可以根据负载自动扩展应用程序。您可以定义水平扩展规则，并让 Kubernetes 自动扩展您的应用程序。

4. 服务发现和负载均衡：使用 Kubernetes Deployment 可以轻松地为您的应用程序定义服务发现和负载均衡规则。Kubernetes 可以自动将流量路由到正确的副本集，并确保它们始终处于健康状态。

5. 多环境部署：使用 Kubernetes Deployment 可以轻松地在不同的环境（如开发、测试和生产）之间部署应用程序。您可以使用不同的配置文件和策略来定义不同的部署规则，从而确保您的应用程序在不同的环境中始终以所需的方式运行。

2.2 ReplicaSet

Kubernetes的ReplicaSet（副本集）是一种控制器（Controller），用于确保Pod的副本数始终保持在指定的数量。如果发现副本数低于预期，则ReplicaSet将自动创建新的Pod。相反，如果副本数多于预期，则会删除多余的Pod。

以下是一个ReplicaSet的示例定义：

文件名：example-rs.yaml

apiVersion: apps/v1
kind: ReplicaSet #资源类型
metadata:name: example-rs
spec:replicas: 3selector:matchLabels:app: exampletemplate:metadata:labels:app: examplespec:containers:- name: exampleimage: nginx:latest

逐行解释这个示例：

• apiVersion: apps/v1：表示使用API版本v1的apps组。
• kind: ReplicaSet：表示我们定义的是ReplicaSet对象。
• metadata：包含ReplicaSet的元数据，如名称、标签和注释。
• name: example-rs：指定ReplicaSet的名称。
• spec：定义了ReplicaSet的规范，包括副本数、选择器和Pod模板。
• replicas: 3：指定我们要运行的Pod副本数为3个。
• selector：指定要选择的Pod标签。
• matchLabels：指定匹配的标签，与模板中的标签相同。
• template：定义了要创建的Pod模板。
• metadata：定义了Pod元数据，如标签。
• labels：指定Pod标签，与选择器中的标签相同。
• spec：指定了Pod的规范，如容器和容器映像。
• containers：定义了Pod中的容器。
• name: example：定义了容器的名称。
• image: nginx:latest：定义了容器映像。

创建这个ReplicaSet：

kubectl apply -f example-rs.yaml

这将创建一个名为example-rs的ReplicaSet，并确保有3个标记为app=example的Pod在运行。如果Pod数目低于3个，则ReplicaSet将自动创建新的Pod。

如果要更新ReplicaSet，可以更新Pod模板的定义，并使用以下命令执行滚动更新：

kubectl apply -f example-rs.yaml

这将创建新的Pod，以替换旧的Pod，直到达到指定的副本数。这个过程被称为滚动更新。

要删除ReplicaSet及其所有Pod，可以使用以下命令：

kubectl delete rs example-rs

这个命令，删除名为example-rs的ReplicaSet及其所有Pod。

使用场景

ReplicaSet的主要使用场景包括：

1. 扩展应用程序：通过创建多个Pod副本并在它们之间负载均衡，可以轻松地扩展应用程序的能力。

2. 确保高可用性：当一个Pod副本出现故障时，ReplicaSet会自动创建一个新的Pod副本来替代它，从而确保应用程序的高可用性。

3. 管理滚动升级：通过在ReplicaSet中定义新版本的Pod模板，可以实现滚动升级应用程序，从而最小化应用程序的停机时间。

4. 确保资源利用率：通过控制Pod副本的数量，可以确保在负载轻的情况下不会浪费资源，同时在负载高峰期间有足够的资源可供使用。

2.3 pod

在 K8s 中，有两种主要类型的 Pod 资源：

1. Pod 资源定义：这是用于定义 Pod 规格的 YAML 或 JSON 文件。它描述了 Pod 的容器及其相关配置、网络、存储等信息。

2. Pod 运行时实例：这是由 Pod 资源定义创建的实际运行时实例。在运行时，K8s 负责管理 Pod 实例的生命周期、容器的运行状态以及网络和存储资源的分配。

Pod 资源定义示例

下面是一个 Pod 资源定义的示例：

apiVersion: v1
kind: Pod #资源类型
metadata:name: my-pod
spec:containers:- name: my-containerimage: nginxports:- containerPort: 80

2.4 service

Kubernetes (K8s) Service是一种用于提供网络访问的抽象机制，用于将一组Pods公开为单个网络服务。服务提供了一个虚拟IP地址和一个DNS名称，允许客户端通过这些标识符访问Kubernetes集群中的应用程序。服务还允许负载平衡和自动容错，以确保即使在一个或多个Pod失败时，服务仍然可用。

在Kubernetes中，Service对象是一个Kubernetes API对象，可以使用Kubernetes API或kubectl命令行工具创建、管理和删除它们。

创建一个Service对象时，需要指定一个标签选择器，用于确定要将哪些Pods作为后端。Service还可以使用不同的负载平衡算法（如轮询或IP哈希）将请求路由到后端Pods。

下面是一个简单的Kubernetes Service示例：

创建一个Deployment：

apiVersion: apps/v1
kind: Deployment #资源类型
metadata:name: nginx-deployment
spec:selector:matchLabels:app: nginxreplicas: 3template:metadata:labels:app: nginxspec:containers:- name: nginximage: nginx:latestports:- containerPort: 80

创建一个Service：

apiVersion: v1
kind: Service #资源类型
metadata:name: nginx-service
spec:selector:app: nginxtype: ClusterIPports:- name: httpport: 80targetPort: 80

这个示例创建了一个名为nginx-deployment的Deployment，它运行3个Nginx Pod。

接下来，它创建了一个名为nginx-service的Service，使用selector指定将后端Pods选择器设置为app: nginx。

该Service使用默认的ClusterIP类型，并将所有传入流量路由到80端口。

在这个示例中，targetPort被设置为80，因为后端Pods也在80端口上监听。

总结：

此时，可以通过Kubernetes集群内部的虚拟IP地址和DNS名称访问Nginx服务。

例如，在Kubernetes集群中的Pod中，可以使用nginx-service名称来访问该服务。

注意：上述示例仅供参考，具体实现可能因Kubernetes版本和配置而异。请参阅Kubernetes文档以获取更多详细信息和最佳实践建议。 

2.5 ingress

Kubernetes Ingress是一个API对象，它允许管理在集群内的HTTP和HTTPS路由。Ingress充当负载均衡器，将流量路由到集群内的服务。它还可以提供TLS终止和基于名称的虚拟主机。

在Kubernetes中，Ingress控制器是一个运行Ingress规则的实体。许多不同的Ingress控制器可用，如Nginx，Traefik，Istio等，它们具有不同的功能和优缺点。

以下是使用Kubernetes Ingress的示例：

安装Ingress控制器

不同的Ingress控制器安装方式可能不同，这里以Nginx为例：

kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/static/provider/cloud/deploy.yaml

创建Ingress规则

创建一个Ingress对象以定义路由规则。以下示例将指定所有来自/example路径的HTTP请求将被路由到名为example-service的服务上：

apiVersion: networking.k8s.io/v1
kind: Ingress #资源类型
metadata:name: example-ingressannotations:nginx.ingress.kubernetes.io/rewrite-target: /
spec:rules:- http:paths:- path: /examplepathType: Prefixbackend:service:name: example-serviceport:number: 80

 应用Ingress规则

使用以下命令将Ingress规则应用于Kubernetes集群：

kubectl apply -f example-ingress.yaml

访问服务

可以使用Ingress规则定义的路由访问服务。

http://ip地址/example

总结：

使用Kubernetes Ingress可以轻松地为集群内的服务设置路由规则，并将流量分发到相应的服务上。

同时，Ingress控制器的选择对性能和功能等方面也有一定影响，需要根据具体情况选择合适的控制器。 

2.6 configMap

Kubernetes (k8s) 的 ConfigMap 是一种用于存储非敏感配置数据的 Kubernetes 对象。ConfigMap 可以包含键值对、文件或者纯文本数据，并可以在容器中通过环境变量、命令行参数或者挂载路径的方式使用。

以下是一个 k8s ConfigMap 的示例 YAML 文件：

apiVersion: v1
kind: ConfigMap #资源类型
metadata:name: my-configmap
data:CONFIG_VAR1: value1CONFIG_VAR2: value2CONFIG_FILE: |-This is the content of a file in the ConfigMap.It can be accessed in a container as a volume.

上面的示例定义了一个名为 my-configmap 的 ConfigMap 对象，其中包含三个键值对：CONFIG_VAR1、CONFIG_VAR2 和 CONFIG_FILE。CONFIG_FILE 中包含了一些纯文本数据，可以在容器中以挂载的方式访问。

下面是一个使用 ConfigMap 的示例 YAML 文件：

apiVersion: v1
kind: Pod #资源类型为pod
metadata:name: my-pod
spec:containers:- name: my-containerimage: nginxenv:- name: VAR1valueFrom:configMapKeyRef:name: my-configmapkey: CONFIG_VAR1- name: VAR2valueFrom:configMapKeyRef:name: my-configmapkey: CONFIG_VAR2volumeMounts:- name: config-volumemountPath: /etc/configreadOnly: truevolumes:- name: config-volumeconfigMap:name: my-configmap

上面的示例定义了一个名为 my-pod 的 Pod 对象，其中包含一个名为 my-container 的容器。

该容器使用了 my-configmap 中的 CONFIG_VAR1 和 CONFIG_VAR2 值，并将 my-configmap 中的 CONFIG_FILE 文件挂载到容器的 /etc/config 目录下。

总的来说，ConfigMap 是一种非常有用的 Kubernetes 对象，可以用于存储配置数据，并将其传递到容器中，以便在运行时使用。

3 总结

使用场景总结

以下是一些适合使用无状态服务的业务场景：

1. Web 应用程序：Web 应用程序通常是无状态的，它们的行为仅取决于用户的请求和输入。无状态服务可以帮助您轻松地扩展 Web 应用程序并提高其可靠性。

2. 批处理作业：批处理作业通常是独立的任务，它们的执行不需要存储状态信息。无状态服务可以帮助您快速地运行大规模的批处理作业。

3. 计算密集型应用程序：计算密集型应用程序通常需要大量的计算资源来处理数据。无状态服务可以帮助您快速地扩展应用程序以处理更多的计算任务。

4. 微服务架构：在微服务架构中，服务通常被设计为无状态的。这是因为无状态服务可以更容易地扩展，并且更容易实现高可用性和负载均衡。

5. 媒体流服务：媒体流服务通常是无状态的，因为它们不需要存储状态信息。无状态服务可以帮助您快速地扩展媒体流服务以处理更多的请求。

 ReplicaSet 和 Deployment区别总结：

Kubernetes (k8s) ReplicaSet 和 Deployment 是两个常用的 Kubernetes 资源对象，它们都用于管理 Pod 的创建、扩展、缩减和更新。

Deployment 和 ReplicaSet 的使用场景：

• Deployment：Deployment 资源对象用于管理应用的版本更新。当您需要发布新版本的应用程序时，可以使用 Deployment 对象来创建一个新的 ReplicaSet，然后 Kubernetes 会逐步将 Pod 的数量从旧版本的 ReplicaSet 逐渐缩减到新版本的 ReplicaSet。如果发生故障，Deployment 会自动回滚至上一个可用版本。
• ReplicaSet：ReplicaSet 资源对象用于管理 Pod 的数量。如果您需要扩展或缩减 Pod 的数量，可以使用 ReplicaSet 对象来定义所需的副本数，并让 Kubernetes 自动创建或删除 Pod，以达到您定义的副本数。

Deployment 和 ReplicaSet 的区别：

• Deployment 是 ReplicaSet 的上层控制器，它在 ReplicaSet 的基础上增加了更多的更新、回滚和版本管理的功能，因此 Deployment 更适合用于应用程序版本的管理。
• ReplicaSet 负责确保 Pod 的数量达到指定的副本数，但是它不会关心 Pod 的版本号。因此 ReplicaSet 更适合用于控制相同版本的 Pod 的数量，以确保可用性和容错性。