Kubernetes中的DaemonSets和ReplicaSets:管理和控制Pod的部署

news/2024/11/27 15:31:32/

Kubernetes是一个流行的容器编排平台,用于管理和编排容器化应用程序。在Kubernetes中,DaemonSets和ReplicaSets是两个重要的概念,用于管理和控制Pod的部署。

摘要

DaemonSets:

DaemonSet确保在Kubernetes集群的每个节点上都运行一个特定的Pod副本。它主要用于运行系统守护程序或其他基础设施相关的服务,这些服务应该在每个节点上存在。DaemonSets具有以下关键特性:

  1. 创建并维护一定数量的Pod副本,每个节点一个,以确保在整个集群中均匀分布。
  2. 当向集群中添加一个新节点时,DaemonSet会自动在该节点上添加一个与其规范匹配的Pod。
  3. 如果从集群中删除了一个节点,相应的Pod也会自动终止。

使用DaemonSets,我们可以方便地在集群中运行后台任务,而不需要手动干预。

ReplicaSets:

ReplicaSets负责始终维持一定数量的Pod副本在运行。它是现在已被废弃的Replication Controllers的下一代版本。ReplicaSets具有以下关键特性:

  1. 确保始终运行指定数量的相同Pod副本,以支持高可用性和容错性。
  2. 定义Pod的期望状态,并持续与实际状态进行协调。
  3. 如果由于节点故障或手动终止导致Pod数量低于期望数量,ReplicaSet会自动创建新的Pod以恢复期望数量。
  4. 同样地,如果Pod数量超过期望数量,ReplicaSet会终止多余的Pod以达到期望状态。

使用ReplicaSets,我们可以轻松地部署需要可扩展性和容错性的应用程序,以确保所需数量的副本一直可用。

Simply out

DaemonSets:

DaemonSet ensures that a specific replica of a pod is running on every node in the Kubernetes cluster. It is primarily used for running system daemons or other infrastructure-related services that should exist on every node. DaemonSets have the following key features:

  1. Creates and maintains a specified number of pod replicas, one per node, to ensure even distribution throughout the cluster.
  2. Automatically adds a matching pod on a new node added to the cluster.
  3. Automatically terminates the corresponding pod if a node is removed from the cluster.

With DaemonSets, we can conveniently run background tasks across the cluster without manual intervention.

ReplicaSets:

ReplicaSets are responsible for ensuring a specified number of pod replicas are always running. They are the next-generation version of the now deprecated Replication Controllers. ReplicaSets have the following key features:

  1. Ensures a specified number of identical pod replicas are always running to support high availability and fault tolerance.
  2. Defines the desired state of pods and continuously coordinates with the actual state.
  3. Automatically creates new pods to recover the desired number if the pod count falls below the expected number due to node failures or manual termination.
  4. Similarly, terminates excess pods to achieve the desired state if the pod count exceeds the expected number.

Using ReplicaSets, we can easily deploy applications that require scalability and fault tolerance, ensuring the desired number of replicas are always available.

Summary:

DaemonSets and ReplicaSets are two key components in Kubernetes for managing pod deployment. While DaemonSets are useful for running background tasks on each node, ReplicaSets are more commonly used for deploying applications that require scalability and fault tolerance, ensuring the desired number of replicas are always available.

On the other hand

In the vast expanse of the galaxy, two factions, the DaemonSets and the ReplicaSets, battled for control over the deployment and management of their pod armies. Each faction possessed unique strengths, their own army of skilled warriors, and an unyielding desire to conquer the unknown.

In the heart of the DaemonSets’ base, the central command was a technological marvel known as “The Hive.” Within The Hive, Daemons resided, powerful entities capable of controlling and orchestrating the deployment of pods throughout the galaxy. These Daemons were relentless and autonomous, ensuring the presence of their pods on every planet they invaded. They were the driving force behind the DaemonSets’ domination.

On the other side of the galaxy, nestled deep within a fortress called “The Factory,” the ReplicaSets diligently manufactured their armies. The Factory was a marvel of efficiency, a place where Replicas were spawned under the watchful eyes of Controllers. These Controllers meticulously maintained steady replicas of pods throughout the galaxy, ensuring resilience and scalability for their faction.

The DaemonSets’ Daemons were cunning and agile, infiltrating planets, laying foundations, and silently deploying pods behind enemy lines. They were like phantoms, leaving no trace of their presence. The enemy was often caught off guard, never knowing when the tide would turn against them.

The ReplicaSets’ Controllers were strategic and calculated. They formed their replicas in massive numbers, overwhelming the enemy forces with sheer numbers. If a pod fell in battle, the Controllers swiftly replaced it, reinforcing the front lines with a continuous stream of replicas.

As the battle raged on, new challenges emerged. Planets were categorized as “Critical”, “Staging”, or “Monitoring”. The DaemonSets aimed to dominate the critical planets, establishing a stronghold in these key locations. Their Daemons invoked dark arts, monitoring and controlling every aspect of the battle. The ReplicaSets, on the other hand, prioritized staging planets, preparing their massive armies for future conquests. It was a constant seesaw of power, as the DaemonSets sought dominance in the critical and the ReplicaSets seized control over the staging.

However, neither faction could ignore the importance of the monitoring planets. These planets acted as the eyes and ears for both the DaemonSets and the ReplicaSets. Each faction deployed their pods on these planets to collect vital information, identify weak spots, and evaluate their strategies. Without these planets, the battle would be fought blindly.

The war between DaemonSets and ReplicaSets continued unabated, with each faction striving for the upper hand. Their armies of pods clashed on countless planets, leaving trails of destruction in their wake. The balance of power shifted constantly, as new advancements in technology allowed for more precise control and enhanced automation.

One thing was certain: the battle for the galaxy would never cease. The DaemonSets and ReplicaSets were locked in an eternal struggle, their thirst for dominance unquenchable. The fate of the galaxy hung in the balance, as the war driven by these powerful Kubernetes forces shaped the destiny of civilizations far and wide.


http://www.ppmy.cn/news/1078834.html

相关文章

原型链中:为什么Function.proto==Function.prototype?

背景: 在 JavaScript 中,每个函数(包括构造函数)都是一个对象,而对象都有一个 __proto__ 属性,指向它们的原型。当你创建一个函数时,JavaScript 引擎会自动为该函数创建一个原型对象,并将其关联…

Python数据分析:从导入数据到生成报告的全面指南

随着数据科学和人工智能的迅速发展,Python 已经成为了最受欢迎的数据分析语言之一。Python 具有简单易学、灵活性强、可扩展性高等优点,使其在数据分析领域具有广泛的应用。本文将介绍 Python 数据分析的基本步骤,帮助你了解如何使用 Python …

Compose学习 - remember、mutableStateOf的使用

一、需求 在显示界面中,数据变动,界面刷新是非常常见的操作,所以使用compose该如何实现呢? 二、remember、mutableStateOf的使用 我们可以借助标题的两个概念 remember、mutableStateOf来完成。这里先不写定义,定义…

CPSC上月召回案例(2023年7月)

每年的夏末秋初为美国产品热销节日(感恩节、万圣节、黑五)的备货期,卖家在大量备货的同时,务必保障自身产品通过相关安全测试,以免造成不必要的损失! 以下是五祥列举出的上月被CPSC召回产品,作…

使用kafka还在依赖Zookeeper,kraft模式了解下

Kafka的Kraft模式 概述 ​ Kafka是一种高吞吐量的分布式发布订阅消息系统,它可以处理消费者在网站中的所有动作流数据。其核心组件包含Producer、Broker、Consumer,以及依赖的Zookeeper集群。其中Zookeeper集群是Kafka用来负责集群元数据的管理、控制器…

Centos8 运行cx_oracle DPI-1047: Cannot locate a 64-bit Oracle Client library异常解决

情况描述: cx_Oracle 在centos 7版本上运行正常,迁移到Centos8后发现有如下报错:Error:DPI-1047: Cannot locate a 64-bit Oracle Client library: "libclntsh.so: cannot open shared object file: No such file or directory".…

PG 锁冲突案例

背景 用户反馈环境中 update 语句无法正常执行, 执行会卡住 定位分析 采用德哥经典锁冲突 SQL ,查看了下, 结果如下 Pid: 39521 …