Kubernetes 是一个开源的容器编排和管理平台，它可以帮助开发者轻松地部署、扩展和管理分布式应用程序。在 Kubernetes 中，可以使用 StatefulSet 来部署 MongoDB 分片集群和副本集。本文将介绍如何使用 Kubernetes 部署 MongoDB 集群。
本实验使用StatefulSet部署MongoDB集群，同时每个MongoDB实例使用glusterfs实现永久存储。从而部署无单点故障、高可用、可动态扩展的MongoDB集群。
kubernetes 集群不会为你处理数据的存储，我们可以为数据库挂载一个磁盘来确保数据的安全。
这里与K8S不同的是这里没有SidecarPlus，但是多了Replica Sets，Replication Controllers，Daemon Sets
（1）每个节点都有固定的身份ID，通过这个ID，集群中的成员可以相互发现并通信。 （2）集群的规模是比较固定的，集群规模不能随意变动。 （3）集群中的每个节点都是有状态的，通常会持久化数据到永久存储中。 （4）如果磁盘损坏，则集群里的某个节点无法正常运行，集群功能受损。
StreamNative 郑重宣布开源 Function Mesh。Function Mesh 是为事件流应用程序构建的无服务框架，为在 Kubernetes 上运行的复杂事件流任务管理 Pulsar Functions 和 Pulsar I/O connector，增强应用程序的事件流功能。
https://blog.csdn.net/hguisu/category_9999400.html
📷 众所周知, Kubernetes(K8S)更适合运行无状态应用, 但是除了无状态应用. 我们还会有很多其他应用类型, 如: 有状态应用, 批处理, 监控代理(每台主机上都得跑), 更复杂的应用(如
在过去的几年间，社区意识到在容器中运行有状态工作负载的价值，而且像 Kubernetes 这样的编排器引入了必要的特性。
无状态应用在 Kubernetes 中的使用非常方便，但是对于一些有状态应用部署还是相对较麻烦，虽然也有单独的 StatefulSets 资源对象来处理有状态应用，但是毕竟不具有通用性，有状态应用的编排和具体的应用息息相关，比如 MongoDB、ElasticSearch、Redis、Zookeeper 等应用。我们这里不再对 StatefulSets 的具体使用展开介绍了，将通过部署一个可扩展的 MongoDB 集群为例进行说明。
本文对 Kubernetes 中的三种重要控制器——Deployment、ReplicaSet 和 StatefulSet 进行了深入剖析，探讨了它们的功能和适用场景。Deployment 控制器作为最常用的控制器之一，提供了声明式更新机制和滚动更新策略，适用于无状态应用的部署和管理。ReplicaSet 控制器主要用于管理 Pod 的副本数量，适合固定副本数的应用部署和简单的水平扩展。StatefulSet 控制器则在部署有状态应用方面发挥着重要作用，提供了稳定的网络标识和持久化存储，适用于数据库和分布式系统等有状态应用的部署。结合最佳实践和注意事项，本文强调了根据应用需求选择合适的控制器的重要性，以确保在实际应用中能够充分发挥控制器的优势。
这些operator基本上都是用来部署、管理、维护一些基础服务的。在验证这些operator的过程中，也顺便研究了下如何写Kubernetes Operator，这里记录一下。
线上kubernetes集群从创建sts到创建pod需要时间很长，分钟级别，但是调度却很快。偶尔还会出现导致kube-odin任务失败（超过300s）的情况
StatefulSet是Kubernetes中一种有状态应用程序的控制器，用于管理一组有序的、命名的Pod。相比于Deployment，StatefulSet更适用于有状态应用程序的场景，因为它可以确保Pod的有序启动和删除，以及Pod的唯一标识符的稳定性。
StatefulSet和Deployment的区别 “Deployment用于部署无状态服务，StatefulSet用来部署有状态服务”。 具体的，什么场景需要使用StatefulSet呢？官方给出的建议是，如果你部署的应用满足以下一个或多个部署需求，则建议使用StatefulSet。 稳定的、唯一的网络标识。 稳定的、持久的存储。 有序的、优雅的部署和伸缩。 有序的、优雅的删除和停止。 有序的、自动的滚动更新。 稳定的主要是针对Pod发生re-schedule后仍然要保持之前的网络标识和持久化存储。这里
本教程描述了如何在 Kubernetes 上运行 Apache Cassandra。 数据库 Cassandra 需要永久性存储提供数据持久性（应用状态）。 在此示例中，自定义 Cassandra seed provider 使数据库在接入 Cassandra 集群时能够发现新的 Cassandra 实例。
下面是一个简单的StatefulSet示例，用于创建一个包含3个nginx Pod的有状态应用程序：
首先，StatefulSet 的控制器直接管理的是 Pod。这是因为，StatefulSet 里的不同 Pod 实例，不再像 ReplicaSet 中那样都是完全一样的，而是有了细微区别的。比如，每个 Pod 的 hostname、名字等都是不同的、携带了编号的。而 StatefulSet 区分这些实例的方式，就是通过在 Pod 的名字里加上事先约定好的编号。
完整系列k8s系列(1)-腾讯云CVM手动部署K8S_Dashboard安装1k8s系列(1)-腾讯云CVM手动部署K8S_Dashboard安装2k8s系列(2)-Servicek8s系列(3)-StatefulSet的MongoDB实战k8s系列(4)-MongoDB数据持久化k8s系列(5)-Configmap和Secretk8s系列(6)-Helmk8s系列(7)-命名空间k8s系列(8)-Ingressk8s系列(9)-容忍、污点、亲和介绍在腾讯云上新建集群，以及负载均衡，并通过Ingress访问
我们将为搜索工程师介绍在Kubernetes（k8s）上运行Solr的基础知识。 具体来说，我们涵盖以下主题：
StatefulSet是Kubernetes中的一种有状态应用管理机制，它允许用户在集群中运行有状态应用程序，并对其进行有效的管理。StatefulSet能够确保有状态应用程序具有唯一的网络标识符、稳定的持久化存储和有序的部署、更新和删除。在StatefulSet中，有两种删除方式：级联删除和非级联删除。
作为一个后端工程师，因为负责的大部分项目都是Web服务这类的“无状态应用”，在平时工作中接触到的最常用的Kubernetes控制器是Deployment，但是Deployment只适合于编排“无状态应用”，它会假设一个应用的所有 Pod是完全一样的，互相之间也没有顺序依赖，也无所谓运行在哪台宿主机上。正因为每个Pod都一样，在需要的时候可以水平扩/缩，增加和删除Pod。
Replication Controller（复制控制器，RC）和ReplicaSet（复制集，RS）是两种简单部署Pod的方式。在生产环境中，主要使用更高级的Deployment等方式进行Pod的管理和部署。
作者： Ravi Gudimetla (Apple)、Filip Křepinský (Red Hat)、Maciej Szulik (Red Hat)
--- #创建k8s集群权限开始 kind: Role apiVersion: rbac.authorization.k8s.io/v1 metadata: name: mongo-read namespace: zhaohao-test rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "watch", "list"] --- kind: RoleBinding apiVersion: rbac.authorizatio
StatefulSet 用来管理某 Pod 集合的部署和扩缩， 并为这些 Pod 提供持久存储和持久标识符。和 Deployment 类似， StatefulSet 管理基于相同容器规约的一组 Pod。但和 Deployment 不同的是， StatefulSet 为它们的每个 Pod 维护了一个有粘性的 ID。这些 Pod 是基于相同的规约来创建的， 但是不能相互替换：无论怎么调度，每个 Pod 都有一个永久不变的 ID。
本文描述了两个特性，即用于 StatefulSet 的 minReadySeconds 以及用于 DaemonSet 的 maxSurge， 很高兴宣布这两个特性在 Kubernetes 1.25 进入稳定阶段。
使用Kubernetes来调度无状态的应用非常简单，那Kubernetes如何来管理调度有状态的应用呢？Kubernetes中提供了一个StatefulSet控制器来管理有状态的应用，本文就介绍StatefulSet的应用，解决以下几个问题：
当新手刚学习k8s时候，会被各种的IP 和port 搞晕，其实它们都与k8s service的访问有密切关系，梳理它们之间的差异可以更好了解k8s的服务访问机制。
在Kubernetes中，StatefulSet是一种用于部署有状态应用程序的控制器。与Deployment不同，StatefulSet为每个Pod分配一个唯一的标识符，并按照一定的顺序启动和删除Pod。这使得StatefulSet非常适合部署需要持久化存储和有序网络标识符的应用程序，如数据库、消息队列等。在使用StatefulSet时，我们可以使用Headless Service来为Pod提供服务发现，确保Pod的唯一性和可靠性。接下来我们将介绍StatefulSet的扩容和缩容。
Deployment并不能满足所有的应用场景，因为它默认对应用做了一个简化假设处理，认为一个应用的所有Pod是完全一样的，但往往在实际应用中，多个实例相互间是存在依赖关系的，比如：主从关系，主备关系，实例与数据之间的关系等。
yapi项目 https://github.com/YMFE/yapi/tags 镜像 https://hub.docker.com/r/jayfong/yapi 创建资源清单 vim yapi.yaml apiVersion: v1 kind: Namespace metadata: name: yapi --- apiVersion: v1 kind: Service metadata: name: mongo namespace: yapi labels: app: mongo
PS：StatefulSet 主要了解它的使用场景，还有概念和使用方法，名字唯一性的特点。在实际中不可能单独使用他。
您是否害怕将集群升级到更新的 Kubernetes 版本？有几个原因可能会促使您升级。也许您想要执行以下操作之一：
本文将带你了解k8s中的StatefulSet控制器，将通过实验的方式来说明StatefulSet的用法和配置，让你快速能够将StatefulSet类型的服务用到你的k8s集群中。
在 Kubernetes 项目中，pkg/controller目录下的子目录通常包含控制器相关的代码和逻辑。控制器是 Kubernetes 中用于管理资源的核心组件之一。它们负责监控资源的状态，并确保其符合所定义的期望状态。下面是对这些子目录的一些常见作用的解释：
statefulset 旨在与有状态的应用及分布式系统一起使用，statefulset 中的每个 pod 拥有一个唯一的身份标识，并且所有 pod 名都是按照 {0..N-1} 的顺序进行编号。本文会主要分析 statefulset controller 的设计与实现，在分析源码前先介绍一下 statefulset 的基本使用。
基于centos7.9，docker-ce-20.10.18，kubelet-1.22.3-0
Kubernetes最初源于谷歌内部的Borg，提供了面向应用的容器集群部署和管理系统。Kubernetes的目标旨在消除编排物理/虚拟计算，网络和存储基础设施的负担，并使应用程序运营商和开发人员完全将重点放在以容器为中心的原语上进行自助运营。Kubernetes 也提供稳定、兼容的基础（平台），用于构建定制化的workflows 和更高级的自动化任务。 Kubernetes 具备完善的集群管理能力，包括多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和服务发现机制、内建负载均衡器、故障发现和自我修复能力、服务滚动升级和在线扩容、可扩展的资源自动调度机制、多粒度的资源配额管理能力。 Kubernetes 还提供完善的管理工具，涵盖开发、部署测试、运维监控等各个环节。
实例之间的不等关系以及实例对外数据有依赖关系的应用，就被称为"有状态应用"。 所谓实例之间的不等关系即对分布式应用来说，各实例，各应用之间往往有比较大的依赖关系，比如某个应用必须先于其他应用启动，否则其他应用将不能启动等。 对外数据有依赖关系的应用，最显著的就是数据库应用，对于数据库应用，我们是需要持久化保存其数据的，如果是无状态应用，在数据库重启数据和应用就失去了联系，这显然是违背我们的初衷，不能投入生产的。
我们在《Kubernetes工作负载管理》中主要介绍了无状态应用的管理，当时也有提到有状态应用，但是由于那时候还没有解释数据如何持久化就没有做深度的介绍，而在这章，我们会着重介绍如何进行有状态应用的管理。
入门Kubernetes目前两周时间，对k8s有了一个基础模糊的认识，了解它之后就会觉得这是一门真正高端的技术。
可以看到与deployment不同，statefulset中的每个pod都分配到了独立的pv，且重启pod后存储对应关系不变
上一篇简单介绍了一下k8s是什么以及如何使用kubeadm快捷安装，今儿来聊一下k8s的几个基础概念及术语。k8s中的资源都可以使用yaml文件进行描述。（文章内容来源于《kubernetes权威指南 第四版》）
在Kubernetes中，Deployment资源对象通常用于管理无状态应用程序，例如Web服务器。但是，对于有状态应用程序，例如数据库，需要一些特殊的考虑。这是因为有状态应用程序需要保持它们的标识和状态，以便它们可以在重启或迁移后正确运行。
下面的清单包含Headless Service,Service,PodDisruptionBudget和StatefulSet。
定义：在Kubernetes中，不可达节点被称为分区节点partitioned node，为了了解操作方法，让我们创建一个分区节点方案并了解其行为。
上一篇文章中，我们详细介绍了 Kubernetes 中的作业副本控制器 Deployment：
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
