首页 文章 精选 留言 我的

精选列表

搜索[K8s],共3939篇文章
优秀的个人博客,低调大师

K8S 行业调研报告出炉:混合云、边缘计算走向主流

本文转自Rancher 2021年3月22日,业界应用最为广泛的企业级Kubernetes管理平台Rancher发布了2020年Kubernetes行业调研报告,研究结果表明,2020年,更多的受访者在混合云环境中使用Kubernetes 运行容器,与此同时,更多的企业将功能和服务部署至边缘,最终进一步推动企业IT现代化的进程。 2019年和2020年,Rancher分别对近1,000名专业人员展开了调查。调查结果表明,Kubernetes在不同行业连续两年保持了90%以上的采用率,而生产环境中的容器采用率从2019年的85%增长至2020年的87%。 SUSE大中华区总裁秦小康表示:“从调研结果可以清晰地看到,用户持续推动容器在混合云和多云环境落地,92%的受访者将容器作为DevOps、IT运维、IT架构、应用程序开发和基础架构转型的关键部分。” Kubernetes和云:真实环境下的真实工具 近1,000名在技术、工程、电信、银行、网络安全和咨询等行业工作的专业人员的反馈,他们主要专注于实现DevOps、IT运维、IT架构、应用程序开发和基础架构转型,92%的受访者选择使用容器来实现这些目标。 进一步调查显示,76%的受访者通过Amazon EKS、Google Kubernetes Engine(GKE)或Microsoft Azure Kubernetes Service(AKS)将Kubernetes作为其云服务。除此之外,他们在71%的时间都在同一环境使用EC2(AWS弹性计算)和GCP(Google云平台)。 另一方面,这些受访者均更倾向于采用Rancher所推出的Kubernetes发行版。36%的受访者将RKE作为其Kubernetes发行版,而32%的受访者使用K3s。受访者指出,在容器快速发展的大前提下,多层级控制和功能是RKE被广泛采用的关键原因。 推动传统IT架构现代化 受访者表示,容器化是推动传统IT现代化的关键路径。49%的受访者通过容器实现传统IT应用程序的现代化,而67%的受访者利用容器设计基于微服务的应用程序。 通过使用Kubernetes,企业可以将使用了数十年的传统IT系统转化为基于微服务的容器应用程序,并通过Kubernetes进行编排。迁移到Kubernetes还可以使开发团队并行工作,从而减少了重复的可能性,简化开发并加速部署。 在混合云环境中,开发团队还可以通过云托管集群完全替代某些本地工作负载,这些集群可以在像Rancher一样的Kubernetes管理平台上运行和管理,进一步实现IT架构现代化的战略。 推动边缘环境生产落地 容器在生产环境中的采用率逐步增长,也覆盖到了应用端。基于此,许多受访者使用容器来为客户提供各种服务,包括应用程序、边缘计算、混合/多云应用程序、内部应用程序、传统应用程序现代化和将传统应用程序迁移上云等。 K3s等体积较小的Kubernetes已经使企业可以更容易地将功能和服务部署至边缘,它赋予了组织从试点项目转向生产环境的能力,并使其能够根据需要进行扩展。2020年,62%的受访者在边缘使用K3s,去年这一比例仅为50%。 随着混合云网络的成熟,客户可以部署面向客户的云原生微服务应用程序,所需的维护量更少,迭代次数更多,并且可以随时间轻松添加新功能。我们完全有理由相信,在面向客户的环境中几乎完全采用由Kubernetes管理的容器的这一趋势将持续发展。 结论 随着公司将他们的网络、应用程序和流程发展成为一个更现代的框架,他们发现无论环境如何,Kubernetes 都可以随之改变。世界各地的组织正在利用 Kubernetes 解决方案来创建一个云原生微服务集群。他们还对单体系统进行现代化,建立强大的云架构,同时无缝管理现有集群。这是向加速和保护应用程序的时代迈进的一步,同时赋予了DevOps和工程团队利用未来“更聪明地工作”而不是“更努力地工作”的能力。 “容器及Kubernetes是混合云时代软件定义基础架构的最佳选择,它们不仅能帮助企业实现传统IT基础架构的容器化改造,还能帮助企业释放混合云的全部价值。”秦小康总结道:“SUSE将凭借强大的开源开放能力,通过结合容器及Kubernetes的可靠性和灵活性推动企业在任意场景进行无限创新,从而推动创新无处不在。” 关注Rancher公众号,回复关键词【2020K8S】即可获取完整版调研报告内容。 调研实施方SUSE Rancher介绍 Rancher是一个开源的企业级Kubernetes管理平台,实现了Kubernetes集群在混合云+本地数据中心的集中部署与管理。Rancher一向因操作体验的直观、极简备受用户青睐,被Forrester评为“2020年多云容器开发平台领导厂商”以及“2018年全球容器管理平台领导厂商”,被Gartner评为“2017年全球最酷的云基础设施供应商”。 目前Rancher在全球拥有超过三亿的核心镜像下载量,并拥有包括中国联通、中国平安、中国人寿、上汽集团、三星、施耐德电气、西门子、育碧游戏、LINE、WWK保险集团、澳电讯公司、德国铁路、厦门航空、新东方等全球著名企业在内的共40000家企业客户。 2020年12月,SUSE完成收购Rancher Labs,Rancher成为了SUSE “创新无处不在(Innovate Everywhere)”企业愿景的关键组成部分。SUSE和Rancher共同为客户提供了无与伦比的自由和所向披靡的创新能力,通过混合云IT基础架构、云原生转型和IT运维解决方案,简化、现代化并加速企业数字化转型,推动创新无处不在。

优秀的个人博客,低调大师

基于 Nebula Operator 的 K8s 自动化部署运维

摘要:Nebula Operator 是 Nebula Graph 在 Kubernetes 系统上的自动化部署运维插件。在本文,你将了解到 Nebula Operator 的特性及它的工作原理。 从 Nebula Graph 的架构谈起 Nebula Graph 是一个高性能的分布式开源图数据库,从架构上可以看出,一个完整的 Nebula Graph 集群由三类服务组成,即 Meta Service, Query Service(Computation Layer)和 Storage Service(Storage Layer)。 每类服务都是一个由多副本组件组成的集群,在 Nebula Operator 中,我们分别称这三类组件为: Metad / Graphd / Storaged。 Metad:主要负责提供和存储图数据库的元数据,并承担集群中调度器的角色,指挥存储扩容和数据迁移,leader 变更等运维操作。 Graphd:主要负责处理 Nebula 查询语言语句(nGQL),每个 Graphd 都运行着一个无状态的查询计算引擎,且彼此间无任何通信关系。计算引擎仅从 Metad 集群中读取元信息,并和 Storaged 集群进行交互。同时,它也负责不同客户端的接入和交互。 Storaged:主要负责 Graph 数据存储。图数据被切分成很多的分片 Partition,相同 ID 的 Partition 组成一个 Raft Group,实现多副本一致性。Nebula Graph 默认的存储引擎是 RocksDB 的 Key-Value 存储。 在了解了 Nebula Graph 核心组件的功能后,我们可以得出一些结论: Nebula Graph 在设计上采用了存储计算分离的架构,组件间分层清晰,职责明确,这意味着各个组件都可以根据自身的业务需求进行独立地弹性扩容、缩容,非常适合部署在 Kubernetes 这类容器编排系统上,充分发挥 Nebula Graph 集群的弹性扩缩能力。 Nebula Graph 是一个较为复杂的分布式系统,它的部署和运维操作需要比较深入的领域知识,这带来了颇高的学习成本和负担。即使是部署运行在 Kubernetes 系统之上,有状态应用的状态管理、异常处理等需求,原生的Kubernetes 控制器也不能很好的满足,导致 Nebula Graph 集群不能发挥出它最大的能力。 因此,为了充分发挥 Nebula Graph 原生具备的弹性扩缩、故障转移等能力,也为了降低对 Nebula Graph 集群的运维管理门槛,我们开发了 Nebula Operator。 Nebula Operator 是 Nebula Graph 在 Kubernetes 系统上的自动化部署运维插件,依托于 Kubernetes 自身优秀的扩展机制,我们把 Nebula Graph 运维领域的知识,以 CRD + Controller 的形式全面注入到 Kubernetes 系统中,让 Nebula Graph 成为真正的云原生图数据库。 为了能够更好的理解 Nebula Operator 的工作原理,让我们先回顾一下什么是 Operator 什么是 Nebula Operator Operator 并不是什么很新的概念,早在 2017 年,就有 CoreOS 公司推出了 Etcd Operator。Operator 的初衷是为了扩展 Kubernetes 功能,以更好的管理有状态应用,这得益于 Kubernetes 的两大核心概念:声明式 API 和控制循环(Control Loop)。 我们可以用一段伪代码来描述这一过程。 在集群中声明对象X的期望状态并创建X for { 实际状态 := 获取集群中对象 X 的实际状态 期望状态 := 获取集群中对象 X 的期望状态 if 实际状态 == 期望状态 { 什么都不做 } else { 执行事先规定好的编排动作,将实际状态调协为期望状态 } } 在 Kubernetes 系统内,每一种内置资源对象,都运行着一个特定的控制循环,将它的实际状态通过事先规定好的编排动作,逐步调整为最终的期望状态。 对于 Kubernetes 系统内不存在的资源类型,我们可以通过添加自定义 API 对象的方式注册。常见的方法是使用 CustomResourceDefinition(CRD)和 Aggregation ApiServer(AA)。Nebula Operator 就使用 CRD 注册了一个 "Nebula Cluster" 资源,和一个 "Advanced Statefulset" 资源。 在注册了上述自定义资源之后,我们就可以通过编写自定义控制器的方式来感知自定义资源的状态变化,并按照我们编写的策略和逻辑去自动地运维 Nebula Graph,让集群的实际状态朝着期望状态趋近。这也是 Nebula Operator 降低用户运维门槛的核心原理。 apiVersion: nebula.com/v1alpha1 kind: NebulaCluster metadata: name: nebulaclusters namespace: default spec: graphd: replicas: 1 baseImage: vesoft/nebula-graphd imageVersion: v2-preview-nightly service: type: NodePort externalTrafficPolicy: Cluster storageClaim: storageClassName: fast-disks metad: replicas: 3 baseImage: vesoft/nebula-metad imageVersion: v2-preview-nightly storageClaim: storageClassName: fast-disks storaged: replicas: 3 baseImage: vesoft/nebula-storaged imageVersion: v2-preview-nightly storageClaim: storageClassName: fast-disks schedulerName: nebula-scheduler imagePullPolicy: Always 我们在这里展示了一个简单的 Nebula Cluster 实例,如果你想要扩展 Storaged 的副本数量至 10,你只需要简单修改 .spec.storaged.replicas 参数为 10,剩下的运维操作则由 Nebula Operator 通过控制循环来完成。 至此,想必你已经对 Nebula Graph 和 Operator 有了一个初步的认知,接下来,让我们来列举目前 Nebula Operator 已经具备了哪些能力,让你能更加深刻的体会到使用 Nebula Operator 带来的一些实际好处。 部署、卸载:我们将一整个 Nebula Graph 集群描述成一个 CRD 注册进 ApiServer 中,用户只需提供对应的 CR 文件,Operator 就能快速拉起或者删除一个对应的 Nebula Graph 集群,简化了用户部署、卸载集群的过程。 扩容、缩容:通过在控制循环中调用 Nebula Graph 原生提供的扩缩容接口,我们为 Nebula Operator 封装实现了扩缩容的逻辑,可以通过 yaml 配置进行简单的扩容,缩容,且保证数据的稳定性。 原地升级:我们在 Kubernetes 原生提供的 StatefulSet 基础上为其扩展了镜像原地替换的能力,它节省了 Pod 调度的耗时,并且在升级时,Pod 的位置、资源都不发生变化,极大提高了升级时集群的稳定性和确定性。 故障迁移:Nebula Operator 会内部调用 Nebula Graph 集群提供的接口,动态的感知服务是否正常运行,一旦发现异常,会自动的去做故障迁移操作,并根据错误类型配有对应的容错机制。 WebHook:一个标准的 Nebula Graph 最少需要三个 Metad 副本,如果用户错误地修改了此参数,可能会导致集群不可用,我们会通过 WebHook 的准入控制来检查一些必要参数是否设置正确,并通过变更控制来强制修改一些错误的声明,使集群始终能够稳定运行。 参考资料 Nebula Graph:https://github.com/vesoft-inc/nebula 作者有话说:Hi,我是刘鑫超,图数据库 Nebula Graph 的研发工程师,如果你对此文有疑问,欢迎来我们的 Nebula Graph 论坛交流下心得~~

优秀的个人博客,低调大师

Rancher开源Fleet:业界首个海量K8S集群管理项目

2020年4月3日,业界应用最为广泛的Kubernetes管理平台创建者Rancher Labs(以下简称Rancher)宣布推出全新开源项目Fleet,致力于为用户提供海量Kubernetes集群的集中管理体验。 Rancher是业界最早实现多云多集群管理的企业级Kubernetes管理平台。早在2016年的Rancher 1.0版本,Rancher就已经提供了用于管理多个集群的中央控制平面。 作为Kubernetes多集群管理的先驱,我们已经亲眼看到了用户如何不断增加所管理集群的数量。 2019年,Rancher推出了一系列轻量级Kubernetes开源项目,包括轻量级的Kubernetes发行版K3s、基于Kubernetes的应用程序部署引擎Rio、业界首个Kubernetes操作系统K3OS。这些项目获得了大量用户的关注,并收获了一致的好评。随着这些项目的成功,用户开始将成千上万的独立Kubernetes集群部署到分支机构、零售商店、石油钻井平台和风力发电厂等边缘位置。 Rancher联合创始人及总架构师Darren Shepherd创建并主导了Fleet项目,他表示:“用户对于在不久的将来管理成千上万甚至是数百万的集群具有极大的兴趣。我们坚信Kubernetes有望成为在多云及异构IT环境中无处不在的企业计算平台,大规模管理Kubernetes集群的需求将持续不断地增长。” Fleet:从“宠物”到“牛群”,满足持续增长的集群规模管理需求 随着Kubernetes集群规模的需求不断增长,用户需要一个可以实现多集群管理的全新体系架构,Fleet展示了多集群管理的未来发展形态。过去,用户将Kubernetes集群当作“宠物”,Fleet的横空出世,将帮助用户从管理“宠物”过渡至管理“牛群”,从而实现海量集群的集中管理。 为了扩大所管理的集群数量,用户无法将过多的注意力和精力集中在管理每一个独立的集群上。正如Kubernetes帮助用户将焦点从单个计算节点转移开来一样,Fleet借鉴了这一思路,帮助用户将焦点从单个集群转移开来。 “根据Kubernetes部署Pod的模型,我们定义了Bundles,并通过Selector将Bundles关联到集群上。但我们不能完全复制Kubernetes Pod部署模型。”Darren Shepherd解释道:“跨集群部署这一想法的独特之处在于,每个集群需要对资源进行不同的配置。” Fleet提供了一种内置机制,可以使用诸如Helm和Kustomize等行业标准工具为每个目标集群定制Bundles。一旦用户在集群之间部署了Bundles,Fleet就会主动监视资源是否已就绪,以及是否被更改过。 在K3s和Rancher上构建 Fleet的可扩展性来自于Rancher Labs为Rancher和K3s的扩展所进行的大量工作和经验累积。虽然K3s的目标是较小的部署,但是K3s的存储技术使Kubernetes可以管理比使用etcd时更大的数据集。除此之外,K3s也为减少Kubernetes控制器中不必要的通信进行了优化。 日前,Rancher正式发布了Rancher 2.4,其GA版本支持2000个集群和10万个节点。 随着Rancher 2.4产品架构的增强,Rancher将在后续版本中提供支持100万个集群的途径。“我们有信心新一代架构将使我们可以管理数百万个集群。我们将继续验证这个架构,并继续进行规模测试,我们也会与社区分享我们的发现。”Darren Shepherd补充道。 “对比起应用程序,我们更倾向于将Fleet部署的单元称为Bundles。”Darren Shepherd强调:“我们不仅可以管理应用程序部署。更为关键的是,我们可以管理所有可以被描述为Kubernetes资源的东西。” 这一趋势与当前的Kubernetes发展趋势不谋而合。随着业界涌现出越来越多的Kubernetes原生工具,这大大扩展了Fleet可以管理的范围。 目前,除了应用程序部署之外,Fleet的主要用例是管理安全工具和安全策略。诸如OPA和Falco等工具,它们都支持原生Kubernetes API,因此Fleet可以确保你的所有集群的一致性和安全性。 不止于此,我们也一直努力增强我们的K3s、K3OS和系统升级控制器(System Update Controller)。这些工具可以使我们用Kubernetes资源文件来管理集群底层和操作系统。 舰队管理:新场景催生新需求 自K3s面世以来,越来越多的用户将其推广及应用到分布的场景中,Rancher研发团队收到了无数K3s社区用户对于海量集群管理的需求。最终,Rancher决定将这一项目命名为Fleet,因为这一单词极佳地体现出了许多用户所描述的用例的精髓。 另一方面,那些在容器领域深耕了数年的用户可能会发现,Fleet同时也是另一个早期容器领域项目的名字。它是由CoreOS团队在早期构建的容器编排系统,目前已经停止维护,不再更新。 “我一直是它的忠实粉丝,将这一项目命名为Fleet也包含了我的私心。”Darren Shepherd解释道:“所以我希望重新使用Fleet这一名字,这是对这个非常出色的容器领域早期项目的致敬。同时,对于推动Kubernetes集群管理的演进,我们感到十分兴奋及万分期待。” 一切开源,立即体验 Fleet依旧秉承Rancher 100%开源的理念,现已发布Alpha版本之前的原型软件Fleet 0.1,您可以在Github上了解及下载体验。 Github地址:https://github.com/rancher/fleet 关于Rancher Labs Rancher Labs由CloudStack之父梁胜创建。旗舰产品Rancher是一个开源的企业级Kubernetes管理平台,实现了Kubernetes集群在混合云+本地数据中心的集中部署与管理。Rancher一向因操作体验的直观、极简备受用户青睐,被Forrester评为2018年全球容器管理平台领导厂商,被Gartner评为2017年全球最酷的云基础设施供应商。 目前Rancher在全球拥有超过三亿的核心镜像下载量,并拥有包括中国人寿、华为、中国平安、兴业银行、民生银行、平安证券、海航科技、厦门航空、上汽集团、海尔、米其林、丰田、本田、中船重工、中联重科、迪斯尼、IBM、Cisco、Nvidia、辉瑞制药、西门子、CCTV、中国联通等全球著名企业在内的共40000家企业客户。

优秀的个人博客,低调大师

Ceph持久化存储为k8s应用提供存储方案(3)

一、CephFs介绍二、CephFS架构三、配置CephFS MDS1、创建一个Ceph文件系统1.1、以kernel client 形式挂载CephFS1.2、以FUSE client 形式挂载CephFS四、MDS主备与主主切换1、配置主主模式2、还原单主MDS 一、CephFs介绍 Ceph File System (CephFS) 是与 POSIX 标准兼容的文件系统, 能够提供对 Ceph 存储集群上的文件访问. Jewel 版本 (10.2.0) 是第一个包含稳定 CephFS 的 Ceph 版本. CephFS 需要至少一个元数据服务器 (Metadata Server - MDS) daemon (ceph-mds) 运行, MDS daemon 管理着与存储在 CephFS 上的文件相关的元数据, 并且协调着对 Ceph 存储系统的访问。 说在前面的话,cephfs其实是为用户提供的一个文件系统,把ceph这个软件把里面的空间,模拟一个文件系统的格式来提供服务,它有posix标准的文件系统的接口能够为ceph集群存储文件,能够提供访问,目前在大多数公司用cephfs也是比较少的,也是由于性能原因,但是也有一些场景也会用到。 对象存储的成本比起普通的文件存储还是较高,需要购买专门的对象存储软件以及大容量硬盘。如果对数据量要求不是海量,只是为了做文件共享的时候,直接用文件存储的形式好了,性价比高。 二、CephFS 架构 底层是核心集群所依赖的, 包括:OSDs (ceph-osd): CephFS 的数据和元数据就存储在 OSDs 上MDS (ceph-mds): Metadata Servers, 管理着 CephFS 的元数据Mons (ceph-mon): Monitors 管理着集群 Map 的主副本 因为这个map里面维护着很多数据的信息索引,所有的数据都要从mons中map里获取去osd里找这个数据,其实获取这个数据的流程大概都是一样的,只不过它存在的是不同的库,不同的map Ceph 存储集群的协议层是 Ceph 原生的 librados 库, 与核心集群交互.CephFS 库层包括 CephFS 库 libcephfs, 工作在 librados 的顶层, 代表着 Ceph文件系统.最上层是能够访问 Ceph文件系统的两类客户端,由于有这个libcephfs这个库,cephfs才能对外提供服务,因为底层是不能提供服务的,都得通过它这个第三方的lib库才能去提供访问, 元数据:文件的名字和属性信息叫元数据,和数据是隔离开的 CephFs的数据是怎么访问的?首先客户端通过RPC协议到达MDS,从MDS获取到元数据的信息,客户端与RADOS获取文件的一个IO操作,那么有了这两份信息,用户就能得到了想要的那份文件,MDS和RADOS之间通过journal metadate,这个Journal是记录文件写入日志的,这个也是存放到OSD当中的,MDS和rados之间也是由交互的,因为所有最终的数据都会存到rados当中 ! 三、配置 CephFS MDS 要使用 CephFS, 至少就需要一个 metadata server 进程。可以手动创建一个 MDS, 也可以使用 ceph-deploy 或者 ceph-ansible 来部署 MDS。 登录到ceph-deploy工作目录执行hostname指定ceph集群的主机名#ceph-deploy mds create $hostname 四、部署Ceph文件系统 部署一个 CephFS, 步骤如下:在一个 Mon 节点上创建 Ceph文件系统.若使用 CephX 认证,需要创建一个访问 CephFS 的客户端 挂载 CephFS 到一个专用的节点.以 kernel client 形式挂载 CephFS以 FUSE client 形式挂载 CephFS 1、创建一个 Ceph 文件系统1、首先要创建两个pool,一个是cephfs-data,一个是cephfs-metadate,分别存储文件数据和文件元数据,这个pg也可以设置小一点,这个根据OSD去配置 #ceph osd pool create cephfs-data 256 256 #ceph osd pool create cephfs-metadata 64 64 查看已经创建成功 [root@cephnode01 my-cluster]# ceph osd lspools 1 .rgw.root 2 default.rgw.control 3 default.rgw.meta 4 default.rgw.log 5 rbd 6 cephfs-data 7 cephfs-metadata 关于ceph的日志,可以在/var/log/ceph下可以查看到相关信息 [root@cephnode01 my-cluster]# tail -f /var/log/ceph/ceph ceph.audit.log ceph.log ceph-mgr.cephnode01.log ceph-osd.0.log ceph-client.rgw.cephnode01.log ceph-mds.cephnode01.log ceph-mon.cephnode01.log ceph-volume.log 注:一般 metadata pool 可以从相对较少的 PGs 启动, 之后可以根据需要增加 PGs. 因为 metadata pool 存储着 CephFS文件的元数据, 为了保证安全, 最好有较多的副本数. 为了能有较低的延迟, 可以考虑将 metadata 存储在 SSDs 上.2、创建一个 CephFS, 名字为 cephfs:需要指定两个创建的pool的名字 #ceph fs new cephfs cephfs-metadata cephfs-data new fs with metadata pool 7 and data pool 6 3、验证至少有一个 MDS 已经进入 Active 状态,也就是活跃另外可以看到两个备用的是cephnode01,和cephnode03 #ceph fs status cephfs cephfs - 0 clients +------+--------+------------+---------------+-------+-------+ | Rank | State | MDS | Activity | dns | inos | +------+--------+------------+---------------+-------+-------+ | 0 | active | cephnode02 | Reqs: 0 /s | 10 | 13 | +------+--------+------------+---------------+-------+-------+ +-----------------+----------+-------+-------+ | Pool | type | used | avail | +-----------------+----------+-------+-------+ | cephfs-metadata | metadata | 1536k | 17.0G | | cephfs-data | data | 0 | 17.0G | +-----------------+----------+-------+-------+ +-------------+ | Standby MDS | +-------------+ | cephnode01 | | cephnode03 | +-------------+ MDS version: ceph version 14.2.7 (3d58626ebeec02d8385a4cefb92c6cbc3a45bfe8) nautilus (stable) 4、在 Monitor 上, 创建一个叫client.cephfs的用户,用于访问CephFs #ceph auth get-or-create client.cephfs mon 'allow r' mds 'allow rw' osd 'allow rw pool=cephfs-data, allow rw pool=cephfs-metadata' 这里会生成一个key,用户需要拿这个key去访问 [client.cephfs] key = AQA5IV5eNCwMGRAAy4dIZ8+ISfBcwZegFTYD6Q== 查看权限列表,有哪些用户创建了权限 [root@cephnode01 my-cluster]# ceph auth list client.cephfs key: AQA5IV5eNCwMGRAAy4dIZ8+ISfBcwZegFTYD6Q== caps: [mds] allow rw caps: [mon] allow r caps: [osd] allow rw pool=cephfs-data, allow rw pool=cephfs-metadata client.rgw.cephnode01 key: AQBOAl5eGVL/HBAAYH93c4wPiBlD7YhuPY0u7Q== caps: [mon] allow rw caps: [osd] allow r 5、验证key是否生效 #ceph auth get client.cephfs 可以看到这个用户是拥有访问cephfs的读写权限的 exported keyring for client.cephfs [client.cephfs] key = AQA5IV5eNCwMGRAAy4dIZ8+ISfBcwZegFTYD6Q== caps mds = "allow rw" caps mon = "allow r" caps osd = "allow rw pool=cephfs-data, allow rw pool=cephfs-metadata" 6、检查CephFs和mds状态 #ceph -s 查看集群已经增加mds配置 cluster: id: 75aade75-8a3a-47d5-ae44-ec3a84394033 health: HEALTH_OK services: mon: 3 daemons, quorum cephnode01,cephnode02,cephnode03 (age 2h) mgr: cephnode01(active, since 2h), standbys: cephnode02, cephnode03 mds: cephfs:1 {0=cephnode02=up:active} 2 up:standby osd: 3 osds: 3 up (since 2h), 3 in (since 2h) rgw: 1 daemon active (cephnode01) data: pools: 7 pools, 96 pgs objects: 263 objects, 29 MiB usage: 3.1 GiB used, 54 GiB / 57 GiB avail pgs: 96 active+clean #ceph mds stat 这里显示1个是active状态,2个备用状态 cephfs:1 {0=cephnode02=up:active} 2 up:standby #ceph fs ls 这里有两个pool name: cephfs, metadata pool: cephfs-metadata, data pools: [cephfs-data ] #ceph fs status 1.1 以 kernel client 形式挂载 CephFS 这里使用其他的机器进行挂载,这里是是以prometheus主机挂载,不过这个在哪挂载都可以,kernel主要联系系统内核,和系统内核进行做相互,用这种方式进行挂载文件系统1、创建挂载目录 cephfs#mkdir /cephfs 2、挂载目录,这里写集群ceph节点的地址,后面跟创建用户访问集群的key #mount -t ceph 192.168.1.10:6789,192.168.1.11:6789,192.168.1.12:6789:/ /cephfs/ -o name=cephfs,secret=AQDHjeddHlktJhAAxDClZh9mvBxRea5EI2xD9w== 3、自动挂载#echo "mon1:6789,mon2:6789,mon3:6789:/ /cephfs ceph name=cephfs,secretfile=/etc/ceph/cephfs.key,_netdev,noatime 0 0" | sudo tee -a /etc/fstab 4、验证是否挂载成功 #stat -f /cephfs 文件:"/cephfs" ID:4f32eedbe607030e 文件名长度:255 类型:ceph 块大小:4194304 基本块大小:4194304 块:总计:4357 空闲:4357 可用:4357 Inodes: 总计:0 空闲:-1 1.2 以 FUSE client 形式挂载 CephFS 1、安装ceph-common,安装好可以使用rbd,ceph相关命令这里还是使用我们的内网yum源来安装这些依赖包 yum -y install epel-release yum install -y ceph-common 2、安装ceph-fuse,ceph的客户端工具,也就是用ceph的方式把这个文件系统挂上yum install -y ceph-fuse 3、将集群的ceph.conf拷贝到客户端 scp root@192.168.1.10:/etc/ceph/ceph.conf /etc/ceph/ chmod 644 /etc/ceph/ceph.conf 4、使用 ceph-fuse 挂载 CephFS如果是在其他主机挂载的话,需要这个使用cephfs的key,这个是刚才我们创建好的直接拿这台服务器上用就可以 [root@prometheus ~]# more /etc/ceph/ceph.client.cephfs.keyring exported keyring for client.cephfs [client.cephfs] key = AQA5IV5eNCwMGRAAy4dIZ8+ISfBcwZegFTYD6Q== caps mds = "allow rw" caps mon = "allow r" caps osd = "allow rw pool=cephfs-data, allow rw pool=cephfs-metadata" #ceph-fuse --keyring /etc/ceph/ceph.client.cephfs.keyring --name client.cephfs -m 192.168.1.10:6789,192.168.1.11:6789,192.168.1.12:6789 /cephfs/ 5、验证 CephFS 已经成功挂载 #df -h ceph-fuse 18G 0 18G 0% /cephfs #stat -f /cephfs 文件:"/cephfs/" ID:0 文件名长度:255 类型:fuseblk 块大小:4194304 基本块大小:4194304 块:总计:4357 空闲:4357 可用:4357 Inodes: 总计:1 空闲:0 6、自动挂载 #echo "none /cephfs fuse.ceph ceph.id=cephfs[,ceph.conf=/etc/ceph/ceph.conf],_netdev,defaults 0 0"| sudo tee -a /etc/fstab 或 #echo "id=cephfs,conf=/etc/ceph/ceph.conf /mnt/ceph2 fuse.ceph _netdev,defaults 0 0"| sudo tee -a /etc/fstab 7、卸载#fusermount -u /cephfs 五、MDS主备与主主切换 1、配置主主模式当cephfs的性能出现在MDS上时,就应该配置多个活动的MDS。通常是多个客户机应用程序并行的执行大量元数据操作,并且它们分别有自己单独的工作目录。这种情况下很适合使用多主MDS模式。 配置MDS多主模式 每个cephfs文件系统都有一个max_mds设置,可以理解为它将控制创建多少个主MDS。注意只有当实际的MDS个数大于或等于max_mds设置的值时,mdx_mds设置才会生效。例如,如果只有一个MDS守护进程在运行,并且max_mds被设置为两个,则不会创建第二个主MDS。 添加设置max_mds 2,也就是成2个activity,1个standby,称为主主备模式 #ceph fs set cephfs max_mds 2 [root@cephnode01 ceph]# ceph fs status cephfs - 1 clients +------+--------+------------+---------------+-------+-------+ | Rank | State | MDS | Activity | dns | inos | +------+--------+------------+---------------+-------+-------+ | 0 | active | cephnode02 | Reqs: 0 /s | 11 | 14 | | 1 | active | cephnode01 | Reqs: 0 /s | 10 | 13 | +------+--------+------------+---------------+-------+-------+ +-----------------+----------+-------+-------+ | Pool | type | used | avail | +-----------------+----------+-------+-------+ | cephfs-metadata | metadata | 2688k | 16.8G | | cephfs-data | data | 521M | 16.8G | +-----------------+----------+-------+-------+ +-------------+ | Standby MDS | +-------------+ | cephnode03 | +-------------+ 也就是当你cephfs用的多的话,数据量大的话,就会出现性能的问题,也就是当配置多个avtive的mds的时候会遇到系统瓶颈,这个时候就需要配置主主模式,把这个数据做一个类似的负载均衡,多主的话也就是这些主会同时提供服务 # 1.3、配置备用MDS即使有多个活动的MDS,如果其中一个MDS出现故障,仍然需要备用守护进程来接管。因此,对于高可用性系统,实际配置max_mds时,最好比系统中MDS的总数少一个。但如果你确信你的MDS不会出现故障,可以通过以下设置来通知ceph不需要备用MDS,否则会出现insufficient standby daemons available告警信息:#ceph fs set <fs> standby_count_wanted 0 2、还原单主MDS 2.1、设置max_mds要是还原的话,直接设置为max_mds 1也就是一个activity两个standby #ceph fs set max_mds 1 [root@cephnode01 ceph]# ceph fs status cephfs - 1 clients ====== +------+--------+------------+---------------+-------+-------+ | Rank | State | MDS | Activity | dns | inos | +------+--------+------------+---------------+-------+-------+ | 0 | active | cephnode02 | Reqs: 0 /s | 11 | 14 | +------+--------+------------+---------------+-------+-------+ +-----------------+----------+-------+-------+ | Pool | type | used | avail | +-----------------+----------+-------+-------+ | cephfs-metadata | metadata | 2688k | 16.8G | | cephfs-data | data | 521M | 16.8G | +-----------------+----------+-------+-------+ +-------------+ | Standby MDS | +-------------+ | cephnode03 | | cephnode01 | +-------------+ 如果想在客户端去执行相关的ceph命令的话,需要安装ceph-common以及ceph-fuse客户端工具将这个ceph.client.admin.keyring以及ceph.conf文件拷到相应的客户端也可以执行ceph命令了 [root@cephnode01 ceph]# scp ceph.client.admin.keyring root@192.168.1.14:/etc/ceph root@192.168.1.14's password: ceph.client.admin.keyring [root@prometheus ceph]# ceph -s cluster: id: 75aade75-8a3a-47d5-ae44-ec3a84394033 health: HEALTH_OK services: mon: 3 daemons, quorum cephnode01,cephnode02,cephnode03 (age 4h) mgr: cephnode01(active, since 4h), standbys: cephnode02, cephnode03 mds: cephfs:2 {0=cephnode02=up:active,1=cephnode03=up:active} 1 up:standby osd: 3 osds: 3 up (since 4h), 3 in (since 4h) rgw: 1 daemon active (cephnode01) data: pools: 7 pools, 96 pgs objects: 345 objects, 203 MiB usage: 3.6 GiB used, 53 GiB / 57 GiB avail pgs: 96 active+clean

优秀的个人博客,低调大师

从零开始入门 K8s | 手把手带你理解 etcd

作者| 曾凡松(逐灵)阿里云容器平台高级技术专家 本文整理自《CNCF x Alibaba 云原生技术公开课》第 16 讲。 更多云原生技术资讯可关注阿里巴巴云原生技术圈。 导读:etcd是用于共享配置和服务发现的分布式、一致性的 KV 存储系统。本文从 etcd 项目发展所经历的几个重要时刻开始,为大家介绍了 etcd 的总体架构及其设计中的基本原理。希望能够帮助大家更好的理解和使用 etcd。 一、etcd 项目的发展历程 etcd 诞生于 CoreOS 公司,它最初是用于解决集群管理系统中 OS 升级的分布式并发控制以及配置文件的存储与分发等问题。基于此,etcd 被设计为提供高可用、强一致的小型 keyvalue 数据存储服务。 项目当前隶属于 CNCF 基金会,被 AWS、Google、Microsoft、Alibaba 等大

资源下载

更多资源
Mario

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长,特征是大鼻子、头戴帽子、身穿背带裤,还留着胡子。与他的双胞胎兄弟路易基一起,长年担任任天堂的招牌角色。

腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题,腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构,目前腾讯云软件源站支持公网访问和内网访问。

Spring

Spring

Spring框架(Spring Framework)是由Rod Johnson于2002年提出的开源Java企业级应用框架,旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念,提供核心容器、应用上下文、数据访问集成等模块,支持整合Hibernate、Struts等第三方框架,其适用范围不仅限于服务器端开发,绝大多数Java应用均可从中受益。

Rocky Linux

Rocky Linux

Rocky Linux(中文名:洛基)是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版,作为CentOS稳定版停止维护后与RHEL(Red Hat Enterprise Linux)完全兼容的开源替代方案,由社区拥有并管理,支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性,采用模块化包装和SELinux安全架构,默认包含GNOME桌面环境及XFS文件系统,支持十年生命周期更新。

用户登录
用户注册