阿辉的博客

系统 网络 集群 数据库 分布式云计算等 研究

Api Gateway和服务网格的对比

来自 阿辉 in Api Gateway, 0 comments

在服务网络出来之前，就已经有很多各式各样的Api Gateway了。他们之间有什么不同呢？

1. Api Gateway架构

Api Gateway有很多，现阶段做的比较好的有ambassador和kong。还有一些其它的，目前看来这两个用的人比较多。
– Ambassador架构：

  • Kong架构：

从流量转发的角度来看，Api Gateway主要做的事是外部到内部的流量转发，也就是通常所说的南北流量。基于kubernetes的架构内来说，其主要是实现ingress的功能。

应用内部之间的流量（东西流量）并不是它关注的重点，虽然部分上也可以实现，但是相关功能并不多。

2. API Gateway解决了什么问题？

API Gateway主要是解决了API管理的问题。

根据Wikipedia的定义：API管理的过程包括创建和发布Web API、执行调用策略、访问控制、订阅管理、收集和分析调用统计以及报告性能。

根据以上定义，API Gateway主要的功能如下：
– api的创建和发布，比如说api的自动注册
– 访问控制和调用策略（流控等），谁能访问？API被调用时，怎么确保安全和稳定的访问？
– 订阅管理，哪些人可以访问我的API
– 调用性能分析及信息收集等

（更多…）

traefik 重写配置

来自 阿辉 in kubernetes, 0 comments

traefik ingress同样可以配置URL的重写：

  • traefik 1.x配置方法

下面是一个完整例子：

 apiVersion: extensions/v1beta1
  kind: Ingress
  metadata:
    annotations:
      kubernetes.io/ingress.class: traefik
      traefik.ingress.kubernetes.io/request-modifier: 'ReplacePathRegex: ^/api3/(.*)
        /api/$1'
    creationTimestamp: "2020-03-09T03:27:40Z"
    generation: 2
    labels:
      app: public-fe-zhan-operation-node-qa
    name: public-fe-zhan-operation-node-qa-7091-2-ingress
    namespace: public-fe-node-qa
    resourceVersion: "2310342"
    selfLink: /apis/extensions/v1beta1/namespaces/public-fe-node-qa/ingresses/public-fe-zhan-operation-node-qa-7091-2-ingress
    uid: ee6f6696-61b5-11ea-a82f-52540088db9a
  spec:
    rules:
    - host: www.xxxx.com
      http:
        paths:
        - backend:
            serviceName: public-fe-zhan-operation-node-qa
            servicePort: 7091
          path: /api3

参考文档：
https://s0docs0traefik0io.icopy.site/v1.7/basics/#path-matcher-usage-guidelines

https://docs.traefik.io/v1.7/basics/#rules-order

（更多…）

nginx的add_header及proxy_set_header命令需注意的地方

来自 阿辉 in web server, 0 comments

nginx的add_header及proxy_set_header命令有三个地方可以配置，分别是http,server,location。我们一般对其优先级的理解是location->server->http。

这没有错，但是这个优先级是指令级别的（不包括指令后面的参数），也就是说：假设在http和server内都有add_header,那么只有server内的生效，忽略http内的add_header，而不管在这两个地方配置新增的header是不是一样。

proxy_set_header也是一样的效果。所以个人推测有很多nginx指令可能都是这样的规则。

另个在同一级别也有坑，对于add_header，如果同一个域名的两个不同location加了不同的add_header，那么只有最后一个location内的生效。这个我没有亲测，详细的可以看下面的参考链接。

（更多…）

使用prometheus监控k8s集群

来自 阿辉 in prometheus, 云计算, 0 comments

1. Prometheus 简介

以下是网上看到的简介：

Prometheus 是一套开源的系统监控报警框架。它启发于 Google 的 borgmon 监控系统，由工作在 SoundCloud 的 google 前员工在 2012 年创建，作为社区开源项目进行开发，并于 2015 年正式发布。2016 年，Prometheus 正式加入 Cloud Native Computing Foundation，成为受欢迎度仅次于 Kubernetes 的项目。

作为新一代的监控框架，Prometheus 具有以下特点：

  • 强大的多维度数据模型：
  • 时间序列数据通过 metric 名和键值对来区分。
  • 所有的 metrics 都可以设置任意的多维标签。
  • 数据模型更随意，不需要刻意设置为以点分隔的字符串。
  • 可以对数据模型进行聚合，切割和切片操作。
  • 支持双精度浮点类型，标签可以设为全 unicode。
  • 灵活而强大的查询语句（PromQL）：在同一个查询语句，可以对多个 metrics 进行乘法、加法、连接、取分数位等操作。
  • 易于管理： Prometheus server 是一个单独的二进制文件，可直接在本地工作，不依赖于分布式存储。
  • 高效：平均每个采样点仅占 3.5 bytes，且一个 Prometheus server 可以处理数百万的 metrics。
  • 使用 pull 模式采集时间序列数据，这样不仅有利于本机测试而且可以避免有问题的服务器推送坏的 metrics。
  • 可以采用 push gateway 的方式把时间序列数据推送至 Prometheus server 端。
  • 可以通过服务发现或者静态配置去获取监控的 targets。
  • 有多种可视化图形界面。
  • 易于伸缩。
    需要指出的是，由于数据采集可能会有丢失，所以 Prometheus 不适用对采集数据要 100% 准确的情形。但如果用于记录时间序列数据，Prometheus 具有很大的查询优势，此外，Prometheus 适用于微服务的体系架构。

（更多…）

elasticsearch重启恢复延迟的相关参数

来自 阿辉 in Database, 0 comments

下面这个参数是elasticsearch延迟分配的超时时间,不让集群认为节点失效而发起均衡。重启节点前可以加这个配置，减少平衡：

curl -XPUT 'http://127.0.0.1:9200/_all/_settings' -H 'Content-Type: application/json' -d '
{
  "settings": {
    "index.unassigned.node_left.delayed_timeout": "5m"
  }
}'

另外还有3个参数：

gateway.recover_after_nodes: 8
gateway.expected_nodes: 10
gateway.recover_after_time: 5m

这意味着 Elasticsearch 会采取如下操作：
– 等待集群至少存在 8 个节点
– 等待 5 分钟，或者10 个节点上线后，才进行数据恢复，这取决于哪个条件先达到。

这三个设置可以在集群重启的时候避免过多的分片交换。这可能会让数据恢复从数个小时缩短为几秒钟。

注意：这些配置只能设置在 config/elasticsearch.yml 文件中或者是在命令行里（它们不能动态更新）它们只在整个集群重启的时候有实质性作用。

参考：这将阻止 Elasticsearch 在存在至少 8 个节点（数据节点或者 master 节点）之前进行数据恢复。 这个值的设定取决于个人喜好：整个集群提供服务之前你希望有多少个节点在线？这种情况下，我们设置为 8，这意味着至少要有 8 个节点，该集群才可用。

从kafka导入导出数据

来自 阿辉 in MQ, 0 comments

导入：
/usr/local/kafka/bin/kafka-console-producer.sh --broker-list 10.16.252.48:9092,10.16.252.49:9092,10.16.252.50:9092 --topic k8s_log_pl_old < /data/k8s_log_pl.txt

导出：
/usr/local/kafka/bin/kafka-console-consumer.sh --zookeeper 10.16.252.48:2181,10.16.252.49:2181,10.16.252.50:2181 --topic k8s_log_pl --from-beginning > /data/k8s_log_pl.txt &

kafka增加分区：
./kafka-topics.sh --alter --zookeeper 10.16.252.48:2181,10.16.252.49:2181,10.16.252.50:2181 --topic k8scs1_log_online --partitions 24

vim 关闭自动注释

来自 阿辉 in Shell, 0 comments

在centOS 6和7上，vim默认开启了自动注释，当我们想复制一段文本，而这个文本内其中一行带有#号时，从这一行开始，下面就会每一行都多一个#号，非常的不方便。

可以用以下命令将其关闭：
:set fo-=r
再度开启的命令为：
:set fo=r

PS:
关闭自动缩进（这个对C/C++代码好像无效）
:set noautoindent
关闭C语言缩进：
:set nocindent
再 Shift + Insert

恢复:

:set autoindent
:set cindent

启动生效请修改vimrc文件

参考：https://vim.fandom.com/wiki/Disable_automatic_comment_insertion

kafka 0.9.0.1 安装配置及简单压测

来自 阿辉 in MQ, 0 comments

1. 简介

Kafka专为分布式高吞吐量系统而设计。 作为一个更传统的消息代理的替代品。 与其他消息传递系统相比，Kafka具有更好的吞吐量，内置分区，复制和固有的容错能力，这使得它非常适合大规模消息处理应用程序。

在实际使用中，kafka的不同版本协议也不完全一致，不是向下兼容的，使用时需特别注意，我这里使用的是0.9.0.1的版本。

2. 服务器配置

本次安装的服务器为物理机3台:
CPU：双Intel(R) Xeon(R) Silver 4110 CPU @ 2.10GHz
内存：128G配置
10块SAS HDD 1T盘做raid10，挂载到/data1。

主机名 IP 备注
sh-saas-k8s-kafka-online-01 10.16.252.33 zookeeper,kafka
sh-saas-k8s-kafka-online-02 10.16.252.39 zookeeper,kafka
sh-saas-k8s-kafka-online-03 10.16.252.40 zookeeper,kafka

2. kafka安装及配置

kafka需要用到zookeeper，所以我们需要先安装zookeeper。kafka及zookeeper都需要是JAVA语言开发，需要使用JDK，推荐1.8版本。

（更多…）

在kubernetes 上部署ceph Rook测试

来自 阿辉 in kubernetes, 1 comment

1. 部署rook

下载：

mkdir rook
cd rook/

wget https://raw.githubusercontent.com/rook/rook/release-1.0/cluster/examples/kubernetes/ceph/common.yaml
wget https://raw.githubusercontent.com/rook/rook/release-1.0/cluster/examples/kubernetes/ceph/cluster.yaml
wget https://raw.githubusercontent.com/rook/rook/release-1.0/cluster/examples/kubernetes/ceph/operator.yaml

修改配置：

vim cluster.yaml
apiVersion: ceph.rook.io/v1
kind: CephCluster
metadata:
  name: rook-ceph
  namespace: rook-ceph
spec:
  cephVersion:
    image: ceph/ceph:v13 #ceph版本
    allowUnsupported: false
  dataDirHostPath: /data/ceph/rook  #存储的目录
  mon:
    count: 3
    allowMultiplePerNode: false
  dashboard:
    enabled: true
  network:
    hostNetwork: false
  rbdMirroring:
    workers: 0
  annotations:
  resources:
    useAllNodes: true
    useAllDevices: true
    deviceFilter:
    location:
    config:
    directories:
    - path: /data/ceph/rook

部署：

kubectl create -f common.yaml
kubectl create -f operator.yaml
kubectl create -f cluster.yaml

（更多…）

ActiveMQ 配置为每个队列一个kahaDB

来自 阿辉 in MQ, 0 comments

ActiveMQ 使用KahaDB存储时，默认的配置是所有队列都存在一个KahaDB内。使用久了会发现一个问题，就是DB文件越来越大，几十上百G。主要原因是当队列内只要有一条消息没有被消费掉，那么ActiveMQ是不会清理KahaDB的文件的。

为此，我们可以加一个过滤器，配置成每个队列一个KahaDB，来缓解这个问题，配置如下：

        <persistenceAdapter>
           <mKahaDB directory="${activemq.data}/kahadb">
            <filteredPersistenceAdapters>
                  <!-- kahaDB per destinations -->
              <filteredKahaDB perDestination="true">
                <persistenceAdapter>
                    <kahaDB ignoreMissingJournalfiles="true"  checkForCorruptJournalFiles="true"  checksumJournalFiles="true" />
                </persistenceAdapter>
              </filteredKahaDB>
             </filteredPersistenceAdapters>
           </mKahaDB>
        </persistenceAdapter>

（更多…）