Posts
k8s部署EFK
· ☕ 1 分钟 · ✍️ starifly
本文介绍了如何在k8s中部署efk

ceph硬件布置参考
· ☕ 1 分钟 · ✍️ starifly

1、网络拓扑参考

2、设备位置图参考

3、服务器配置信息及运行服务统计

一般来说,内存越多越好。

对于一个中等规模的集群,监视/管理器节点可以使用64GB;对于具有数百个osd的大型集群,128GB是一个合理的目标。


ceph故障域
· ☕ 5 分钟 · ✍️ starifly

准备

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在不复制rgw的情况下配置多个区域
· ☕ 1 分钟 · ✍️ starifly

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 rgw同步
· ☕ 2 分钟 · ✍️ starifly

环境

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

操作步骤

准备存储池


k8s ingress
· ☕ 6 分钟 · ✍️ starifly

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自动创建一个负载均衡器,通常还绑定了公网地址。只要把域名解析指向该地址,就实现了集群服务的对外暴露



点击屏幕右上角的 ···
在弹出的窗口中选择 在浏览器中打开