k8s 知识- 模块化方式认识Statefulset和Deployment.

本文提供了一份详细的教程，指导开发者如何在RK3588的Buildroot环境中添加和编译自己的C/C++程序（CMake项目）。从环境准备、项目结构搭建到Buildroot包描述文件创建，再到系统集成与调试技巧，教程涵盖了全流程操作步骤和常见问题解决方案，帮助开发者高效完成本地模块的单独编译和系统配置。

一、StatefulSet与Deployment对比 前面提到的Deployment（RC、Deployment、DaemonSet都是常见的无状态服务）用于部署无状态应用，而StatefulSet（有状态的集合）则是用于部署有状态的应用。 无状态应用的特点： 1.可以认为所有Pod都是一样的； 2.Pod的启动没有顺序要求； 3.不用考虑Pod在哪个node运行； 4.可以进行随意的伸缩即扩展。 有状态应用的特点： 1.无状态应用不需要考虑的，有状态都需要考虑； 2.每个Pod独立，保持Pod启动顺

k8s 1.25学习

访问方式： Compare Deployment & StatefulSet 类型 特性 Deployment StatefulSet 是否暴露到外网 可以 一般不 请求面向的对象 serviceName 指定pod的域名 灵活性 只能通过service/serviceIp访问到k8...

1、稳定的、唯一的网络标识符： StatefulSet为每个Pod副本提供一个持久的网络标识符。3、有序的部署、扩展和删除： StatefulSet中的Pods是根据顺序部署和删除的，这对于需要严格顺序部署的有状态服务（如数据库）来说非常重要。2、稳定的、持久的存储： StatefulSet可以确保每个Pod副本与特定的持久卷绑定，即使Pod重新部署到其他节点，这种存储也会保持不变。4、有序的、优雅的滚动更新： StatefulSet支持基于定义好的策略进行有序的滚动更新。

是两种管理 Pod 的控制器，它们的主要区别在于。在 Kubernetes 中，

本篇是基于k8s-v1.15.0版本。 1、介绍 RC、Deployment、DaemonSet都是面向无状态的服务，它们所管理的Pod的IP、名字，启停顺序等都是随机的，而StatefulSet是什么？顾名思义，有状态的集合，管理所有有状态的服务，比如MySQL、MongoDB集群等。 StatefulSet本质上是Deployment的一种变体，在v1.9版本中已成为GA版本，它为了解决有状态服务的问题，它所管理的Pod拥有固定的Pod名称，启停顺序，在StatefulSet中，Pod名字称为网络标识

一、简介 一般情况下，我们并不直接创建 Pod，而是通过 Deployment 来创建 Pod，由 Deployment 来负责创建、更新、维护其所管理的所有 Pods。 ReplicationSet（RS）和ReplicationController（RC）区别 这里就需要说一下ReplicationSet（RS）和ReplicationController（RC），RS是在RC基础上发展来的，在新版的Kubernetes中，已经将RC替换为RS 了，它们两者没有本质的区别，都是用于Pod副本数量的

在K8s中，Deployment将Pod部署成无状态的应用程序，它只关心Pod的数量、Pod更新方式、使用的镜像和资源限制等。由于是无状态的管理方式，因此Deployment中没有角色和顺序的概念，换句话说：Deployment中没有状态。通过使用Deployment，可以让开发人员上线部署Pod、设置Pod的副本、实现Pod的升级与回滚。通过在yaml文件中描述Deployment的目标是什么，Deployment控制器就会自动完成对Pod和Replica Set的管理。

2019独角兽企业重金招聘Python工程师标准>>> ...

前言 经过前面几篇文章的实战案例，相信我们对k8s是如何部署应用也有了一定的了解。虽然部署的模板并不一定是最优的，但是基本上能解决大多数应用的部署问题。本文会着重讲解一下前几篇文章用到的Kubernetes 对象。 常用对象详解 当创建 Kubernetes 对象时，必须提供对象的规约，用来描述该对象的期望状态，以及关于对象的一些基本信息（例如名称）。 当使用 Kubernetes API 创建对象时（或者直接创建，或者基于kubectl），API 请求必须在请求体中包含 JSON 格式的信息。 大多数

文章目录一、 控制器1.1 Pod与控制器之间的关系1.2 Deployment特点：应用场景：web服务测试1.2 SatefulSet官方文档特点应用场景：数据库常规service和无头服务区别测试配置dns服务，使用yaml文件创建1.3 有状态与无状态的区别1.4 DaemonSet1.5 Job官方文档测试1.6 CronJob官方文档测试 一、 控制器 控制器：又称之为工作负载，分别包含以下类型控制器 Deployment,适合无状态的服务部署 StatefulSet,适合有状态的服务部署 D

与 Deployment 不同，StatefulSet 确保每个 Pod 都具有稳定、唯一的标识，维护持久存储，并保证有序、优雅的部署和扩缩容。Pod 是 Kubernetes 中最小的可部署单元，它封装了一个或多个容器、存储资源、一个唯一的网络 IP 以及管理容器如何运行的选项。，其中单个 Pod 是可互换的，并且没有与其绑定的唯一标识或持久状态。想想 Web 服务器、REST API 或消息队列消费者——如果一个 Pod 宕机，另一个相同的 Pod 可以取代它，而不会影响应用程序的功能。

Deployment 适合场景 无状态的应用 特点 1.pod之间没有顺序 2.所有pod共享存储 3.pod名字包含随机数字 4.service都有ClusterIP,可以负载均衡 StatefulSet 适合场景 有状态的应用 特点 1.部署、扩展、更新、删除都要有顺序 2.每个pod都有自己存储，所以都用volumeClaimTemplates，为每个pod都生成一个自己的存储，保存自己的状态 3.pod名字始终是固定的 4.service没有ClusterIP，是headle

如果你的应用程序是无状态的，并且你希望快速、简单地部署和管理它，那么 Deployment 可能是一个更好的选择。如果你的应用程序是有状态的，并且你需要维护 Pod 的状态、网络标识和持久化存储，那么 StatefulSet 可能更适合你。当然，在实际应用中，你可能会遇到更复杂的情况，需要结合使用 Deployment 和 StatefulSet，甚至其他 Kubernetes 资源，以满足你的需求。

它们之间的主要区别在于它们处理Pod的方式和适用的应用程序类型。主要用于部署有状态应用程序，这些应用程序的实例需要保持一定的状态和顺序，如数据库、消息队列等。适用于有状态应用程序，它提供了稳定的网络标识和独立存储卷，以及有序的Pod创建和删除。适用于无状态应用程序，它可以快速扩展和更新，而不需要保持Pod之间的状态和顺序。主要用于部署无状态应用程序，这些应用程序的实例之间是相互独立的，可以相互替换。中的Pod具有稳定的网络标识，方便应用程序实例之间的通信。使用有状态存储卷，每个Pod都有自己的独立存储卷。

无状态与有状态的应用： 无状态应用： 应用的所有 Pod，是完全一样的。所以，它们互相之间没有顺序，也无所谓运行在哪台宿主机上。 有状态的应用：分布式应用，它的多个实例之间，往往有依赖关系，比如：主从关系、主备关系。 还有就是数据存储类应用，它的多个实例，往往都会在本地磁盘上保存一份数据。而这些实例一旦被杀掉，即便重建出来，实例与数据之间的对应关系也已经丢失，从而导致应用失败。 k8s有了新的控制器：StatefulSet 应用状态被抽象为两类： 1拓扑状态 应用的多个实例之间不是完全对等的关系。这

适用于需要快速扩展、无状态的服务，即使 Pod 在不同的节点上重启或被重新调度，也不会影响应用的正常运行。StatefulSet 中的每个 Pod 都有一个固定的标识（包括一个稳定的网络标识）。适用于有状态的应用程序，提供稳定的网络标识、持久化存储，以及对启动和终止顺序有严格要求的场景。在扩展或缩减时，Pod 的数量增加或减少，不保证特定 Pod 的身份和顺序。即使 Pod 被删除或重新调度，新的 Pod 也会保留相同的标识和名称。来控制更新时的最大不可用 Pod 数量和同时创建的额外 Pod 数量。

一 有状态和无状态理解 之前的博客我们学习了 'Deployment 和 ReplicaSet' 两种'资源对象'的使用 在实际使用的过程中,'Deployment 并不能编排'所有类型的应用,对'无状态服务编排'是非常容易的,但是对于'有状态服务'就无能为力了 那么问题来了：什么是'有状态'服务？什么是'无状态'服务 有状态 我们常见的 'WEB 应用',是通过 'Session' 来保持用户的'登录状态'的 1）如果我们将 Session '持久化到节点上',那么该应用就是一个..