准备

1、执行ceph -s确认存储集群状态，保证为健康状态。

[root@ceph001 ~]# ceph -s
  cluster:
    id:     d00c744a-17f6-4768-95de-1243202557f2
    health: HEALTH_OK

  services:
    mon: 3 daemons, quorum ceph001,ceph002,ceph003 (age 41m)
    mgr: ceph001(active, since 43m), standbys: ceph003
    mds: cephfs:1 {0=ceoh002=up:active} 2 up:standby
    osd: 6 osds: 6 up (since 3m), 6 in (since 3m)
    rgw: 3 daemons active (ceph001, ceph002, ceph003)

  task status:

  data:
    pools:   10 pools, 96 pgs
    objects: 803 objects, 2.1 GiB
    usage:   13 GiB used, 62 GiB / 75 GiB avail
    pgs:     96 active+clean

2、执行ceph osd tree ,记录变更前的结构。以及存储池pool及其他信息。

ceph 在同一个集群配置多个zone，但不同 zone 之间的 rgw 不复制，这种情形应该可以适应多租户环境，因为希望每个租户之间的数据是相互独立的，具体配置可以参考 https://access.redhat.com/documentation/en-us/red_hat_ceph_storage/3/html-single/object_gateway_guide_for_red_hat_enterprise_linux/index#configuring-multiple-zones-without-replication-rgw

环境

• 源 ceph 集群（192.168.5.203:20003）
• 基于源集群创建一个新的 rgw 端点(192.168.5.128:7480)，用于将数据同步到另一个 S3提供者
• S3 目标（192.168.4.13:7480）

操作步骤

准备存储池

之前的文章已经介绍过ingress，这里说明怎么部署新版的ingress

版本说明

inrress-nginx版本为1.4.0，k8s版本为1.23.6，具体版本匹配参考 https://github.com/kubernetes/ingress-nginx。

Ingress简介

service的作用

1. 对集群内部，它不断跟踪pod的变化，更新endpoint中对应pod的对象，提供了ip不断变化的pod的服务发现机制
2. 对集群外部，他类似负载均衡器，可以在集群内外部对pod进行访问

外部访问k8s集群内的服务

• NodePort: 测试环境使用还行，当有几十上百的服务在集群中运行时，NodePort的端口管理就是个灾难
• LoadBalancer: 受限于云平台，且通常在云平台部署LoadBalancer还需要额外的费用
• Ingress: 可以简单理解为service的service，它其实就是一组基于域名和URL路径，把用户的请求转发到一个或多个service的规则

Ingress组成

ingress

1. ingress是一个API对象，通过yaml文件来配置，ingress对象的作用是定义请求如何转发到service的规则，可以理解为配置模板
2. ingress通过http或https暴露集群内部service，给service提供外部URL、负载均衡、SSL/TLs能力以及基于域名的反向代理。ingress要依靠ingress-controller来具体实现以上功能

ingress-controller

1. ingress-controller是具体实现反向代理及负载均衡的程序，对ingress定义的规则进行解析，根据配置的规则来实现请求转发
2. ingress -controller并不是k8s自带的组件，实际上ingress-controller只是一个统称，用户可以选择不同的ingress-controller实现，目前，由k8s维护的ingress-controller只有google云的ccz与ingress-nginx两个，其他还有很多第三方维护的ingres-controller，具体可以参考官方文档。但是不管哪一种ingress-controller，实现的机制都大同小异，只是在具体配置上有差异
   3.一般来说，ingress-controller的形式都是一个pod,里面跑着daemon程序和反向代理程序。daemon负责不断监控集群的变化，根据ingress对象生成配置并应用新配置到反向代理，比如ingress -nginx就是动态生成nginx配置，动态更新upstream，并在需要的时候reload程序应用新配置。为了方便，后面的例子都以k8s官方维护的ingress-nginx为例

Ingress工作原理

1. ingress-controller通过和 kubernetes APIServer 交互，动态的去感知集群中ingress规则变化
2. 然后读取它，按照自定义的规则，规则就是写明了哪个域名对应哪个service，生成一段nginx配置
3. 再写到nginx-ingress-controller的pod里，这个ingress-controller的pod里运行着一个nginx服务，控制器会把生成的nginx配置写入/etc/nginx.conf文件中
4. 然后reload一下使配置生效。以此达到域名区分配置和动态更新的作用

ingress暴露服务的方式

Deployment+LoadBalancer模式的Service

如果要把ingress部署在公有云，那用这种方式比较合适。用Deployment部署ingress-controller，创建一个type为 LoadBalancer的 service关联这组pod。大部分公有云，都会为 LoadBalancer的 service自动创建一个负载均衡器，通常还绑定了公网地址。只要把域名解析指向该地址，就实现了集群服务的对外暴露

Reference

• 附录2、ceph安装配置介绍与主机优化
• [ ceph ] CEPH 部署完整版（CentOS 7 + luminous）
• 03 分布式存储ceph之crush规则配置
• 动态设置bucket_index_max_shards参数
• 实弹军演-基于Ceph对象存储的实战兵法
• 从传统运维到云运维演进历程之软件定义存储（一）
• 从传统运维到云运维演进历程之软件定义存储（三）上
• 从传统运维到云运维演进历程之软件定义存储（三）下
• 从传统运维到云运维演进历程之软件定义存储（五）上
• 从传统运维到云运维演进历程之软件定义存储（五）中
• 从传统运维到云运维演进历程之软件定义存储（五）下
• Ceph-RGW多活机制
• BlueStore-先进的用户态文件系统《一》
• Ceph之对象存储网关RADOS Gateway(RGW)

07 分布式存储ceph运维操作

01 分布式存储Ceph理论篇