DNS介绍

介绍

kubernets的所有资源.包括Service,Pod都有生命周期,会频繁的销毁和创建.这些资源的IP地址也会随之动态变化.所以Kubernetes使用DNS实现通过资源名解析IP地址.

DNS服务器

Kubernetes集群安装了默认的Core-dns组件(通过Pod方式运行).以及kube-dns的service.

1
2
3
4
5
6
7

[root@k8s-master ~]$kubectl get pods -n kube-system | grep dns
coredns-7f9c544f75-9sh28                   1/1     Running   2          324d
coredns-7f9c544f75-jgmqq                   1/1     Running   2          324d

#下方这个10.96.0.10就是kubernetes集群的内部DNS服务器
[root@k8s-master ~]$kubectl get svc -n kube-system | grep dns
kube-dns         ClusterIP   10.96.0.10     <none>        53/UDP,53/TCP,9153/TCP   324d

Kong实现限流

介绍

近期发现公司某个业务对外的openapi接口的/merchantapi路径异常调用非常频繁.公司的第三方商户需要通过这个路径来调用ERP接口,但是经常发生被恶意刷接口的情况,导致公司的业务服务器资源使用率飙升,面临很大的宕机风险和隐患.

目前外部客户端访问公司业务仍然是阿里云SLB—–Nginx—php-fpm的架构.由于Nginx的限流能力并不出色,特别是针对具体path路径的限流.所以,引入了Kong api网关

Rate Limiting限流插件介绍

Rate Limiting是Kong社区版就已经自带的官方流量控制插件.详细信息可以参考Kong官网介绍. https://docs.konghq.com/hub/kong-inc/rate-limiting/

它可以针对consumer ,credential ,ip ,service,path,header 等多种维度来进行限流.流量控制的精准度也有多种方式可以参考,比如可以做到秒级,分钟级,小时级等限流控制.

响应客户端头部信息

当启用这个插件后.Kong会响应客户端一些额外的头部信息,告诉客户端限流信息.例如下面是Kong响应给客户端的header信息,告诉客户端当前的限流策略是10r/s

1
2
3
4
5
6
7

RateLimit-Limit: 10
RateLimit-Remaining: 0
RateLimit-Reset: 1

X-Kong-Response-Latency: 1
X-RateLimit-Limit-Second: 10
X-RateLimit-Remaining-Second: 0

如果客户端的访问请求超过限流的阈值,Kong会返回status429的状态码以及下面的错误信息

1

{ "message": "API rate limit exceeded" }

Kong自定义配置Nginx

介绍

Kong是基于Nginx实现代理转发.官方的 nginx.conf 配置文件过于简单.如果需要优化nginx的性能,就需要修改默认的nginx配置文件,或者重新自定义一个nginx配置文件.

具体方法可以参考官方文档: https://docs.konghq.com/2.2.x/configuration/#environment-variables

下面介绍2种方式自定义nginx的配置

通过环境变量注入

Kong服务启动时会每次都新建一个新的nginx配置文件.可以通过将nginx指令注入到 kong.conf 配置文件中从而配置到这个新的nginx配置文件

Prometheus Alertmanager 告警路由

介绍

公司目前Prometheus监控了IDC数据中心的主机,中间,站点等,同时也监控了阿里云线上的rabbitmq,mysql,kong(所有资源都是ECS自己搭建的,非阿里云的saas服务)

prometheus使用了第三方的钉钉监控插件(prometheus-webhook-dingtalk),github地址: https://github.com/timonwong/prometheus-webhook-dingtalk

Prometheus通过alertmanager将告警信息发送到钉钉机器人

告警路由

我们需要将阿里云的线上中间件监控告警发送到阿里云的钉钉群.IDC资源的监控告警发送到IDC的钉钉群,不同的钉钉群面对的人群也不同.方便监控告警信息的分类和管理.

幸好,alertmanager天生支持告警路由的功能,将不同的告警信息发送给不同的receiver接收人

alertmanager概念介绍

Prometheus本身并不提供告警功能,所有告警信息都是发送给Alertmanager处理.Alertmanager接收到告警信息后负责将它们分组,抑制,静默,然后路由到相关接收者.

Grouping分组

分组功能将多个同一类型的告警合并一起后发送,这在某个服务发生故障从而影响其他几十,上百个相关依赖性的服务时非常有用,可以有效避免告警信息轰炸.例如当网络出现问题时,可能该网络下的数百个服务都出现访问故障,结果数以百计的告警被发送给Alertmanager.此时Alertmanager将同类型的服务合并到一起仅仅使用单条告警通知发送给接收者

1.2 生产与消费简单实例

创建topic

kafka提供了许多实用的脚本工具,存放在$KAFKA_HOME的bin目录下.其中与主题相关的就是kafka-topic.sh脚本.例如.下面创建一个分区数为4,副本为3的主题topic-demon

1
2
3

./kafka-topics.sh --zookeeper localhost:2181 --create --topic topic-demo --replication-factor 3 --partitions 4

Created topic "topic-demo".

--zoopkeer 指定kafka连接的zookeeper服务地址
--topic 指定一个topic主题
--replication-factor 指定副本因子数量
--partition 指定分区数量
--create 表示创建

2.1 Kafka副本

副本介绍

Kafka为分区引入了副本(Replica)机制.通过增加副本数量提升容灾能力.一个Topic主题可以有多个分区,一个分区又可以有多个副本.这多个副本中，只有一个是leader，而其他的都是follower副本。仅有leader副本可以对外提供服务。所以副本之间是一主多从的关系,而且每个副本中保存的相同的消息.(严格来说,同一时刻副本之间的消息并非能一定完全同步)

多个follower副本通常存放在和leader副本不同的broker中。通过这样的机制实现了高可用，当某台机器挂掉后，其他follower副本也能迅速”转正“，开始对外提供服务。

1.1 基本概念介绍

kafka特性

• 消息系统: Kafka和传统的消息中间件都具备流量削峰,缓冲,异步通信,扩展性等.另外,Kafka还提供了大多数消息中间件难以实现的消息顺序保障及回溯消费的功能
• 存储系统: 消息持久化到存盘,可以实现永久存储
• 流式处理平台: Kafka提供了流式处理类库

4.1.1 创建主题

4.1.1.1 自动创建主题以及分区副本

在之前的笔记中提到了创建主题的一个简单示例.kafka提供 kafka-topics.sh 脚本来创建主题.下面这个示例创建了一个 topic-test 的主题,包含4个分区和2个副本.

1
2
3

/opt/kafka/bin/kafka-topics.sh --zookeeper localhost:2181 --create --topic topic-test --replication-factor 2 --partitions 4

Created topic "topic-test".

分区创建完成后,会在kafka的 log.dirs 或者 log.dir 的目录下创建相应的主题分区.下面是在其中一台Broker节点的信息展示:

1
2
3

[hadoop@bi-dev152 ~]$ ls /opt/logs/kafka/ | grep "topic-test"
topic-test-0
topic-test-2

可以看到152节点中创建了2个文件夹 topic-test-0 和 topic-test-2,对应主题 topic-test的2个分区编号为0和2的分区，命名方式可以概括为 <topic>-<partition> .严谨地说,其实这类文件夹对应的不是分区,分区同主题一样是一个逻辑的概念而没有物理上的存在.并且这里我们也只是看到了2个分区,而我们创建的是4个分区,其余2个分区被分配到了153和154节点中，参考如下:

1
2
3
4
5
6
7
8
9
10
11

#153节点
[hadoop@bi-dev153 ~]$ ls /opt/logs/kafka/ | grep "topic-test"
topic-test-0
topic-test-1
topic-test-3

#154节点
[hadoop@bi-dev154 ~]$ ls /opt/logs/kafka/ | grep "topic-test"
topic-test-1
topic-test-2
topic-test-3

三个broker节点一共创建了8个文件夹,这个数字8实质上是分区数4与副本因子2的乘积.每个副本(或者更确切地说应该是日志,副本与日志一一对应)才真正对应 了一个命名形式.

3.1 消费者与消费组

1.消费者和消费组介绍

消费者( Consumer)负责订阅Kafka中的主题( Topic)，并且从订阅的主题上拉取消息.与其他一些消息中间件不同的是:在 Kafka的消费理念中还有一层消费组( Consumer Group)的概念，每个消费者都有一个对应的消费组。当消息发布到主题后，只会被投递给订阅它的每个消费组中的一个消费者 。

以下图为例,某个主题中共有 4 个分区( Partition) : PO、 Pl、 P2、 P3。 有两个消费组 A和 B 都订阅了这个主题，消费组 A 中有 4 个消费者 (CO、 Cl、 C2 和 C3)，消费组 B 中有 2个消费者 CC4 和 CS) 。按照 Kafka默认的规则，最后的分配结果是消费组 A 中的每一个消费 者分配到1个分区，消费组 B 中的每一个消费者分配到 2个分区，两个消费组之间互不影响。每个消费者只能消费所分配到的分区中的消息。换言之 每一个分区只能被一个消费组中的一个消费者所消费.

4.2.1 优选副本的选举

4.2.1.1 什么是优先副本

分区使用多副本机制来提升可靠性,但是只有leader副本对外提供读写服务.而follower副本只负责在内部进行消息的同步.如果一个分区的leader副本不可用,那么就意味着整个分区变得不可用.此时就需要从剩余的follower副本中挑选一个新的leader副本继续对外提供服务.

broker节点中的Leader副本个数决定了这个节点负载的高低

在创建主题的时候,主题的分区和副本会尽可能的均匀分布在kafka集群的各个broker节点.对应的Leader副本的分配也比较均匀.例如下面的 topic-demo 主题:

1
2
3
4
5
6
7

[hadoop@bi-dev152 ~]$ kafka-topics.sh --zookeeper localhost:2181 --describe --topic topic-demo
Topic:topic-demo    PartitionCount:4    ReplicationFactor:3 Configs:
    Topic: topic-demo   Partition: 0    Leader: 152 Replicas: 152,153,154   Isr: 152,153,154
    Topic: topic-demo   Partition: 1    Leader: 153 Replicas: 153,154,152   Isr: 152,153,154
    Topic: topic-demo   Partition: 2    Leader: 154 Replicas: 154,152,153   Isr: 152,153,154
    Topic: topic-demo   Partition: 3    Leader: 152 Replicas: 152,154,153   Isr: 152,153,154
[hadoop@bi-dev152 ~]$