YP小站

ETCD存储满了如何处理?

2022-10-30T11:59:40.000Z

一、前言

当运行 ETCD 日志报 Erro: mvcc database space exceeded 时，说明ETCD存储不足了（默认ETCD存储是2G），配额会触发告警，然后 Etcd 系统将进入操作受限的维护模式。

通过下面命令可以查看ETCD存储使用情况：

1	$ ETCDCTL_API=3 etcdctl --endpoints="http://127.0.0.1:2379" --write-out=table endpoint status

二、临时解决方案

PS: 压缩前做好快照备份，命令 etcdctl snapshot save backup.db

通过 ETCD 数据压缩来临时解决问题，具体如下操作

# 获取当前版本
$ rev=$(ETCDCTL_API=3 etcdctl --endpoints=http://127.0.0.1:2379 endpoint status --write-out="json" | egrep -o '"revision":[0-9]*' | egrep -o '[0-9].*')

# 压缩所有旧版本
$ ETCDCTL_API=3 etcdctl --endpoints=http://127.0.0.1:2379 compact $rev

# 整理多余的空间
$ ETCDCTL_API=3 etcdctl --endpoints=http://127.0.0.1:2379 defrag

# 取消告警信息
$ ETCDCTL_API=3 etcdctl --endpoints=http://127.0.0.1:2379 alarm disarm

# 测试是否能成功写入
$ ETCDCTL_API=3 etcdctl --endpoints=http://127.0.0.1:2379 put testkey 123

OK

# 再次查看ETCD存储使用情况
$ ETCDCTL_API=3 etcdctl --endpoints="http://127.0.0.1:2379" --write-out=table endpoint status

三、最终解决方案

在 ETCD 启动命令中添加下面两个参数：

# 表示每隔一个小时自动压缩一次
--auto-compaction-retention=1
# 磁盘空间调整为 8G，官方建议最大 8G（单位是字节）
--quota-backend-bytes=8388608000

四、最佳实践

大家有没有使用过 Kuboard（Kubernetes 多集群管理界面，官网地址：https://kuboard.cn），如果有使用过的同学可能会遇到ETCD存储不足的问题，因为官网提供的docker镜像中，ETCD启动参数并没有添加 --auto-compaction-retention 和 --quota-backend-bytes 参数。

修改官网 Kuboard docker镜像 /entrypoint.sh 启动脚本

生成 Dockerfile 文件：

# 编辑 Dockerfile
$ vim Dockerfile

FROM eipwork/kuboard:v3.5.0.3

COPY ./entrypoint.sh /entrypoint.sh

# 构建镜像
$ docker build -t eipwork/kuboard-modify:v3.5.0.3 . -f Dockerfile

启动 Kuboard，并查看进程如下：

五、参考文档

https://etcd.io/docs/v3.4/op-guide/maintenance/

业务日志告警如何做?

2022-10-23T12:43:15.000Z

一、前言

随着 Kubernetes 使用越来越广泛，日志集中收集、展示、告警等都需要考虑的事情。Kubernetes 日志收集方案一般有下面几种：

1、日志收集组件以 Daemonset 形式运行在 Kubernetes Node 中，业务容器日志目录统一挂载到Node节点指定的目录，日志收集组件读取对应的目录。
2、日志收集组件以 Daemonset 形式运行在 Kubernetes Node 中，收集业务容器标准输出stdout和stderr日志。
3、日志收集组件以 Sidecar 形式和业务容器运行在一个pod中，把业务日志目录挂载出来，让同一个Pod中日志收集容器能读取到。

日志收集到集中日志平台，但是另一个问题来了，应该如何对业务日志告警？

下面是一个 Kubernetes 日志收集架构图，比较开源的解决方案。

二、日志格式

下面例举两个日志例子，一个是 Nginx 访问日志，另一个是 Java 业务日志格式

1、nginx 访问日志格式

{
  "@timestamp": "2022-10-20T11:47:05+08:00",
  "servername": "www.example.com",
  "remote_addr": "172.20.199.10",
  "referer": "-",
  "request_method": "GET",
  "request_uri": "/",
  "server_protocol": "HTTP/1.1",
  "request_time": "0.000",
  "status": 200,
  "bytes": 577,
  "useragent": "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.162 Safari/537.36",
  "x_forwarded": "172.18.25.11, 100.122.43.140",
  "upstr_addr": "172.20.199.20:8080",
  "upstr_host": "-",
  "ups_resp_time": "0.01"
}

2、java 业务日志格式

{
  "@timestamp": "2022-10-20T19:14:26.875+08:00",
  "level": "INFO",
  "appName": "test-service",
  "requestId": "",
  "remoteIp": "",
  "traceId": "",
  "spanId": "",
  "parent": "",
  "thread": "XNIO-1 task-14",
  "class": "c.c.common.security.util.SecurityUtil",
  "line": "118",
  "message": "没有登录",
  "stack_trace": "java.lang.ClassCastException: null\n"
}

三、告警要求

1、Nginx 访问日志，1分钟内，需要把 Http 状态码是 404、429、499、5xx 大于10条就告警
2、java 业务日志格式，1分钟内，日志级别(level)是 ERROR 并且总数大于10条就告警
3、通过 钉钉机器人 或者 飞书机器人 告警

四、如何根据日志告警？

本文日志存储在 Elasticsearch 中

本文使用 ElastAlert 服务来实现告警，简单介绍下 ElastAlert 是什么？

ElastAlert 是一个简单的框架，用于从检索Elasticsearch中的数据异常，尖峰等来实现告警。

它通过将Elasticsearch与两种类型的组件（规则类型和警报）结合使用。定期查询Elasticsearch，并将数据传递到规则类型，该规则类型确定找到任何匹配项。发生匹配时，它会发出一个或多个警报，这些警报根据不同的类型采取相应的措施。

ElastAlert由一组规则配置，每个规则定义一个查询，一个规则类型和一组警报。

ElastAlert 特性

架构简单，定制灵活
支持多种匹配规则（频率、阈值、数据变化、黑白名单、变化率等）
支持多种警报类型（邮件、HTTP POST、自定义脚本等，默认不支持钉钉机器人、飞书机器人等）
匹配项汇总报警，重复警报抑制，报警失败重试和过期
可用性强，状态信息保存到Elasticsearch的索引中
过程的调试和审计等

ElastAlert 可用性

ElastAlert 将其状态保存到 Elasticsearch，启动后，将恢复之前停止的状态
如果 Elasticsearch 没有响应，ElastAlert 将等到恢复后才继续
抛出错误的警报可能会在一段时间内自动重试

ElastAlert 部署

项目地址：https://github.com/bitsensor/elastalert.git，官方提供 docker 镜像，但并不是很好用，这里作者重新构建一个docker镜像。

ElastAlert 告警监控展示

1、钉钉机器人告警展示

2、飞书机器人告警展示

构建 elastalert 镜像

# 下载 ElastAlert 代码
$ git clone https://github.com/bitsensor/elastalert.git
$ cd elastalert

# 创建 Dockerfile，ElastAlert 默认不支持 钉钉机器人、飞书机器人，这里需要扩展下
$ vim Dockerfile

FROM python:3.6-alpine as pyea

ENV ELASTALERT_VERSION=v0.2.4
ENV ELASTALERT_URL=https://github.com/Yelp/elastalert/archive/$ELASTALERT_VERSION.zip
ENV ELASTALERT_HOME /opt/elastalert

WORKDIR /opt

RUN sed -i 's/dl-cdn.alpinelinux.org/mirrors.aliyun.com/g' /etc/apk/repositories && \
    apk add --update --no-cache ca-certificates openssl-dev openssl libffi-dev gcc musl-dev wget && \
    apk add --update --no-cache curl tzdata make libmagic nodejs npm && \
    apk add --update --no-cache tzdata && \
    cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtime && \
    echo "Asia/Shanghai" > /etc/timezone && \
    wget -O elastalert.zip "${ELASTALERT_URL}" && \
    unzip elastalert.zip && \
    rm elastalert.zip && \
    mv e* "${ELASTALERT_HOME}"

ENV TZ Asia/Shanghai

WORKDIR "${ELASTALERT_HOME}"

RUN mkdir ~/.pip && \
    echo '[global]' >> ~/.pip/pip.conf && \
    echo 'index-url = https://pypi.tuna.tsinghua.edu.cn/simple' >> ~/.pip/pip.conf && \
    /usr/local/bin/python3 -m pip install --upgrade pip && \
    pip3 install cryptography==3.3.2 && \
    sed -i 's/jira>=1.0.10,<1.0.15/jira>=2.0.0/g' setup.py && \
    python3 setup.py install && \
    pip3 install "setuptools==46.1.3" && \
    pip3 install pyOpenSSL==16.2.0 && \
    sed -i 's/jira>=1.0.10,<1.0.15/jira>=2.0.0/g' requirements.txt && \
    pip3 install -r requirements.txt

RUN cd /opt && \
    wget https://github.com/xuyaoqiang/elastalert-dingtalk-plugin/archive/master.zip && \
    unzip master.zip && \
    rm -f master.zip && \
    cd elastalert-dingtalk-plugin-master && \
    cp -r elastalert_modules /opt/elastalert/ 

COPY . /opt/elastalert-server

WORKDIR /opt/elastalert-server

RUN sed -i '1i process.env.TZ = "Asia/Shanghai";' index.js && \
    npm --registry https://registry.npm.taobao.org install --production --quiet

COPY config/elastalert.yaml /opt/elastalert/config.yaml
COPY config/elastalert-test.yaml /opt/elastalert/config-test.yaml
COPY config/config.json config/config.json
COPY rule_templates/ /opt/elastalert/rule_templates
COPY elastalert_modules/ /opt/elastalert/elastalert_modules

RUN mkdir -p /opt/elastalert/rules/ /opt/elastalert/server_data/tests/ && \
    cd /opt/elastalert/elastalert_modules && \
    wget https://raw.githubusercontent.com/gpYang/elastalert-feishu-plugin/main/elastalert_modules/feishu_alert.py

EXPOSE 3030
ENTRYPOINT ["npm", "start"]

# 构建 ElastAlert 镜像
$ docker build -t yangpeng2468/elastalert:v0.2.4 . -f Dockerfile

上传到 dockerhub 个人仓库中，提供给大家下载

1	$ docker push yangpeng2468/elastalert:v0.2.4

配置 ElastAlert 并启动

1、首先创建 config.json 配置文件

# 创建配置文件目录
$ mkdir -p /data/elastalert/config /data/elastalert/rules /data/elastalert/rule_templates

$ vim config/config.json

{
  "appName": "elastalert-server",
  "port": 3030,
  "wsport": 3333,
  "elastalertPath": "/opt/elastalert",
  "verbose": false,
  "es_debug": false,
  "debug": false,
  "rulesPath": {
    "relative": true,
    "path": "/rules"
  },
  "templatesPath": {
    "relative": true,
    "path": "/rule_templates"
  },
  "es_host": "xx.xx.xx.xx", # es 地址
  "es_port": 9200,
  "writeback_index": "elastalert_status"
}

2、创建 elastalert.yaml 配置文件

$ vim config/elastalert.yaml

# The elasticsearch hostname for metadata writeback
# Note that every rule can have its own elasticsearch host
es_host: xx.xx.xx.xx # es 地址

# The elasticsearch port
es_port: 9200

# ElastAlert从中加载规则配置文件的位置 
rules_folder: rules

# ElastAlert多久查询一次Elasticsearch的时间 
run_every:
  minutes: 10

# 用来设置请求里时间字段的范围，默认是15分钟 
buffer_time:
  minutes: 10

# Option basic-auth username and password for elasticsearch
es_username: elastic 
es_password: xxx # es 密码

# 是ElastAlert将在其中存储数据的索引的名称 
writeback_index: elastalert_status

# 别名
writeback_alias: elastalert_alerts

# 失败警报的重试窗口 
alert_time_limit:
  days: 2

3、创建 nginx 访问日志报警文件

$ vim rules/nginx.yaml

#rule name 必须是独一的，不然会报错，这个定义完成之后，会成为报警的标题
name: nginx-access-alert

#配置的是frequency，需要两个条件满足，在相同 query_key条件下，timeframe 范围内有num_events个被过滤出来的异常
type: frequency

#指定index，支持正则匹配同时如果嫌麻烦直接* 也可
index: nginx-*-prod-%Y-%m-%d  
use_strftime_index: true

#时间触发的次数
num_events: 10

#和num_events参数关联，也就是说1分钟内出现10次会报警
timeframe:
  minutes: 1

#同一规则的两次警报之间的最短时间。在此时间内发生的任何警报都将被丢弃。默认值为一分钟。
realert:
  minutes: 3

#防止同一条规则在一段时间内发出两次警报
#realert:
#  days: 1

# query_key 用来防止基于某个字段的重复项
realert:
  minutes: 10
query_key: servername

#用来拼配告警规则，elasticsearch 的query语句，支持 AND&OR等
filter:
- query:
    query_string: 
      query: "status: [500 TO 599] OR status: 429 OR status: 404"

#只需要的字段 https://elastalert.readthedocs.io/en/latest/ruletypes.html#include
include: ["servername", "request_method", "request_uri", "remote_addr", "@timestamp", "status", "request_time", "ups_resp_time", "x_forwarded", "upstr_addr"]

#告警方式，钉钉 和 飞书 告警，可以只选择一种就行
alert:
- "elastalert_modules.dingtalk_alert.DingTalkAlerter"
- "elastalert_modules.feishu_alert.FeishuAlert"

# 钉钉机器人接口地址
dingtalk_webhook: "https://oapi.dingtalk.com/robot/send?access_token=xxx"
dingtalk_msgtype: "text"
alert_subject: "Nginx访问日志异常"
alert_text_type: alert_text_only
alert_text: |
 【告警主题】 Nginx访问日志异常
 【告警条件】 异常访问日志1分钟内大于10次
 【告警时间(UTC)】 {}
 【告警域名】 {}
 【状态码】 {}
 【请求URL】 {}
 【请求协议】 {}
 【客户端IP】 {}
 【响应时间】 {}
 【后端响应时间】 {}
 【后端请求主机】 {}
 【异常状态码数量】 {}
alert_text_args:
 - "@timestamp"
 - servername
 - status
 - request_uri
 - request_method
 - x_forwarded
 - request_time
 - ups_resp_time
 - upstr_addr
 - num_hits

# 飞书机器人接口地址
feishualert_url: "https://open.feishu.cn/open-apis/bot/v2/hook/"

# 飞书机器人id
feishualert_botid:
  "xxx"

# 告警标题
feishualert_title:
  "Nginx访问日志异常"

# 这个时间段内的匹配将不告警，适用于某些时间段请求低谷避免误报警
feishualert_skip:
  start: "00:00:00"
  end: "00:01:00"

# 告警内容
# 使用{}可匹配matches
feishualert_body:
  "
  【告警主题】:  {feishualert_title}\n
  【告警条件】:  异常访问日志1分钟内大于10次\n
  【告警时间】:  {feishualert_time}\n
  【告警域名】:  {servername}\n
  【状态码】:  {status}\n
  【请求URL】:  {request_uri}\n
  【请求协议】:  {request_method}\n
  【客户端IP】:  {x_forwarded}\n
  【响应时间】:  {request_time}\n
  【后端响应时间】:  {ups_resp_time}\n
  【后端请求主机】:  {upstr_addr}\n
  【异常状态码数量】:  {num_hits}
  "

4、创建 java 业务日志报警文件

$ vim rules/java.yaml

#rule name 必须是独一的，不然会报错，这个定义完成之后，会成为报警的标题
name: java-prod-alert

#配置的是frequency，需要两个条件满足，在相同 query_key条件下，timeframe 范围内有num_events个被过滤出来的异常
type: frequency

#指定index，支持正则匹配同时如果嫌麻烦直接* 也可
index: java-*-prod-%Y-%m-%d
use_strftime_index: true

#时间触发的次数
num_events: 10

#和num_events参数关联，也就是说1分钟内出现10次会报警
timeframe:
  minutes: 1

#同一规则的两次警报之间的最短时间。在此时间内发生的任何警报都将被丢弃。默认值为一分钟。
realert:
  minutes: 3

#防止同一条规则在一段时间内发出两次警报
#realert:
#  days: 1

# query_key 用来防止基于某个字段的重复项
realert:
  minutes: 15
query_key: applicationName

#用来拼配告警规则，elasticsearch 的query语句，支持 AND&OR等
filter:
- query:
    query_string: 
      query: "level: ERROR"

#只需要的字段 https://elastalert.readthedocs.io/en/latest/ruletypes.html#include
include: ["applicationName", "level", "@timestamp", "_index"]

#告警方式，钉钉 和 飞书 告警，可以只选择一种就行
alert:
- "elastalert_modules.dingtalk_alert.DingTalkAlerter"
- "elastalert_modules.feishu_alert.FeishuAlert"

# 钉钉机器人接口地址
dingtalk_webhook: "https://oapi.dingtalk.com/robot/send?access_token=xxx"
dingtalk_msgtype: "text"
alert_subject: "java业务日志异常"
alert_text_type: alert_text_only
alert_text: |
 【告警主题】 java业务日志异常
 【告警条件】 异常业务日志1分钟内大于10次
 【告警时间(UTC)】 {}
 【告警业务名称】 {}
 【告警业务索引】 {}
 【告警日志级别】 {}
 【错误日志数量】 {}
alert_text_args:
 - "@timestamp"
 - applicationName
 - _index
 - level
 - num_hits


# 飞书机器人接口地址
feishualert_url: "https://open.feishu.cn/open-apis/bot/v2/hook/"

# 飞书机器人id
feishualert_botid:
  "xxx"

# 告警标题
feishualert_title:
  "toB业务日志异常"

# 这个时间段内的匹配将不告警，适用于某些时间段请求低谷避免误报警
feishualert_skip:
  start: "00:00:00"
  end: "00:01:00"

# 告警内容
# 使用{}可匹配matches
feishualert_body:
  "
  【告警主题】:  {feishualert_title}\n
  【告警条件】:  异常业务日志1分钟内大于10次\n
  【告警时间】:  {feishualert_time}\n
  【告警业务名称】:  {applicationName}\n
  【警业务索引】:  {_index}\n
  【告警日志级别】:  {level}\n
  【错误日志数量】:  {num_hits}
  "

5、创建 ElastAlert 镜像启动脚本

$ cd /data/elastalert
$ vim run.sh

docker run -d --restart always -p 3030:3030 -p 3333:3333 \
    --name elastalert \
    --hostname elastalert \
    -v /data/elastalert/config/elastalert.yaml:/opt/elastalert/config.yaml \
    -v /data/elastalert/config/elastalert-test.yaml:/opt/elastalert/config-test.yaml \
    -v /data/elastalert/config/config.json:/opt/elastalert-server/config/config.json \
    -v /data/elastalert/rules:/opt/elastalert/rules \
    -v /data/elastalert/rule_templates:/opt/elastalert/rule_templates \
    yangpeng2468/elastalert:v0.2.4

# 启动
$ sh run.sh

五、参考文档

详解Nginx proxy_pass 使用

2022-03-27T11:30:17.000Z

前言

日常不管是研发还是运维，都多少会使用Nginx服务，很多情况Nginx用于反向代理，那就离不开使用proxy_pass，有些同学会对 proxy_pass 转发代理时 后面url加 /、后面url没有 /、后面url添加其它路由等场景，不能很明白其中的意思，下面来聊聊这些分别代表什么意思。

详解

客户端请求 URL https://172.16.1.1/hello/world.html

第一种场景后面url加 /

1
2
3

location /hello/ {
    proxy_pass http://127.0.0.1/;
}

结果：代理到URL：http://127.0.0.1/world.html

第二种场景后面url没有 /

1
2
3

location /hello/ {
    proxy_pass http://127.0.0.1;
}

结果：代理到URL：http://127.0.0.1/hello/world.html

第三种场景后面url添加其它路由，并且最后添加 /

1
2
3

location /hello/ {
    proxy_pass http://127.0.0.1/test/;
}

结果：代理到URL：http://127.0.0.1/test/world.html

第四种场景后面url添加其它路由，但最后没有添加 /

1
2
3

location /hello/ {
    proxy_pass http://127.0.0.1/test;
}

结果：代理到URL：http://127.0.0.1/testworld.html

Docker与Containerd使用区别

2022-03-20T10:55:05.000Z

前言

Kubernetes 在 1.24 版本里弃用并移除 docker shim，这导致 1.24 版本开始不在支持 docker 运行时。大部分用户会选择使用 Containerd 做为Kubernetes运行时。

PS: docker-ce 底层就是 Containerd

使用 Containerd 时，kubelet 不需要通过 docker shim 调用，直接通过 Container Runtime Interface (CRI) 与容器运行时交互。减少调用层，并且也减少很多bug产生。

下面来讲讲 docker 与 Containerd 使用有那些方面不同。

Docker 和 Containerd 常用命令比较

镜像相关操作	Docker	Containerd
显示本地镜像列表	docker images	crictl images
下载镜像	docker pull	crictl pull
上传镜像	docker push	无
删除本地镜像	docker rmi	crictl rmi
查看镜像详情	docker inspect IMAGE-ID	crictl inspect IMAGE-ID

容器相关操作	Docker	Containerd
显示容器列表	docker ps	crictl ps
创建容器	docker create	crictl create
启动容器	docker start	crictl start
停止容器	docker stop	crictl stop
删除容器	docker rm	crictl rm
查看容器详情	docker inspect	crictl inspect
attach	docker attach	crictl attach
exec	docker exec	crictl exec
logs	docker logs	crictl logs
stats	docker stats	crictl stats

Pods相关操作	Docker	Containerd
显示POD列表	无	crictl pods
查看POD详情	无	crictl inspectp
运行POD	无	crictl runp
停止POD	无	crictl stopp

容器日志和相关参数配置差异

功能	Docker	Containerd
存储路径	如果 Docker 作为 K8S 容器运行时，容器日志的落盘将由 docker 来完成，保存在类似`/var/lib/docker/containers/$CONTAINERID` 目录下。Kubelet 会在 `/var/log/pods 和 /var/log/containers` 下面建立软链接，指向 `/var/lib/docker/containers/$CONTAINERID` 该目录下的容器日志文件。	如果 Containerd 作为 K8S 容器运行时，容器日志的落盘由 Kubelet 来完成，保存至 `/var/log/pods/$CONTAINER_NAME` 目录下，同时在 `/var/log/containers` 目录下创建软链接，指向日志文件。
配置参数	在 docker 配置文件中指定：`"log-driver": "json-file", "log-opts": {"max-size": "100m","max-file": "5"}`	`方法一`：在 kubelet 参数中指定：`--container-log-max-files=5 --container-log-max-size="100Mi"` ；`方法二`：在 KubeletConfiguration 中指定：`"containerLogMaxSize": "100Mi", "containerLogMaxFiles": 5`
容器日志保存到数据盘	把数据盘挂载到 “data-root”（缺省是 `/var/lib/docker`）即可。	创建一个软链接 `/var/log/pods` 指向数据盘挂载点下的某个目录或者通过挂载目录，把 `/var/log/pods` 目录挂载到数据盘上。

CNI 网络

功能	Docker	Containerd
谁负责调用 CNI	Kubelet 内部的 docker-shim	Containerd 内置的 cri-plugin（containerd 1.1 以后）
如何配置 CNI	Kubelet 参数 `--cni-bin-dir` 和 `--cni-conf-dir`	Containerd 配置文件（toml）： `[plugins.cri.cni]` `bin_dir = "/opt/cni/bin"` `conf_dir = "/etc/cni/net.d"`

参考链接

https://cloud.tencent.com/document/product/457/35747

docker exec 失败问题排查之旅

2022-01-09T04:28:56.000Z

前言

锄禾日当午，值班好辛苦；

汗滴禾下土，一查一下午。

问题描述

今天，在值班排查线上问题的过程中，发现系统日志一直在刷docker异常日志：

1
2
3

May 12 09:08:40 HOSTNAME dockerd[4085]: time="2021-05-12T09:08:40.642410594+08:00" level=error msg="stream copy error: reading from a closed fifo"
May 12 09:08:40 HOSTNAME dockerd[4085]: time="2021-05-12T09:08:40.642418571+08:00" level=error msg="stream copy error: reading from a closed fifo"
May 12 09:08:40 HOSTNAME dockerd[4085]: time="2021-05-12T09:08:40.663754355+08:00" level=error msg="Error running exec 110deb1c1b2a2d2671d7368bd02bfc18a968e4712a3c771dedf0b362820e73cb in container: OCI runtime exec failed: exec failed: container_linux.go:348: starting container process caused \"read init-p: connection reset by peer\": unknown"

从系统风险性上来看，异常日志出现的原因需要排查清楚，并摸清是否会对业务产生影响。

下文简单介绍问题排查的流程，以及产生的原因。

问题排查

现在我们唯一掌握的信息，只有系统日志告知dockerd执行exec失败。

在具体的问题分析之前，我们再来回顾一下docker的工作原理与调用链路：

可见，docker的调用链路非常长，涉及组件也较多。因此，我们的排查路径主要分为如下两步：

确定引起失败的组件
确定组件失败的原因

定位组件

熟悉docker的用户能够一眼定位引起问题的组件。但是，我们还是按照常规的排查流程走一遍：

// 1. 定位问题容器
# sudo docker ps | grep -v pause | grep -v NAMES | awk '{print $1}' | xargs -ti sudo docker exec {} sleep 1
sudo docker exec aa1e331ec24f sleep 1
OCI runtime exec failed: exec failed: container_linux.go:348: starting container process caused "read init-p: connection reset by peer": unknown


// 2. 排除docker嫌疑
# docker-containerd-ctr -a /var/run/docker/containerd/docker-containerd.sock -n moby t exec --exec-id stupig1 aa1e331ec24f621ab3152ebe94f1e533734164af86c9df0f551eab2b1967ec4e sleep 1
ctr: OCI runtime exec failed: exec failed: container_linux.go:348: starting container process caused "read init-p: connection reset by peer": unknown


// 3. 排除containerd与containerd-shim嫌疑
# docker-runc --root /var/run/docker/runtime-runc/moby/ exec aa1e331ec24f621ab3152ebe94f1e533734164af86c9df0f551eab2b1967ec4e sleep
runtime/cgo: pthread_create failed: Resource temporarily unavailable
SIGABRT: abort
PC=0x6b657e m=0 sigcode=18446744073709551610

goroutine 0 [idle]:
runtime: unknown pc 0x6b657e
stack: frame={sp:0x7ffd30f0d218, fp:0x0} stack=[0x7ffd2ab0e738,0x7ffd30f0d760)
00007ffd30f0d118:  0000000000000002  00007ffd30f7f184
00007ffd30f0d128:  000000000069c31c  00007ffd30f0d1a8
00007ffd30f0d138:  000000000045814e <runtime.callCgoMmap+62>  00007ffd30f0d140
00007ffd30f0d148:  00007ffd30f0d190  0000000000411a88 <runtime.persistentalloc1+456>
00007ffd30f0d158:  0000000000bf6dd0  0000000000000000
00007ffd30f0d168:  0000000000010000  0000000000000008
00007ffd30f0d178:  0000000000bf6dd8  0000000000bf7ca0
00007ffd30f0d188:  00007fdcbb4b7000  00007ffd30f0d1c8
00007ffd30f0d198:  0000000000451205 <runtime.persistentalloc.func1+69>  0000000000000000
00007ffd30f0d1a8:  0000000000000000  0000000000c1c080
00007ffd30f0d1b8:  00007fdcbb4b7000  00007ffd30f0d1e0
00007ffd30f0d1c8:  00007ffd30f0d210  00007ffd30f0d220
00007ffd30f0d1d8:  0000000000000000  00000000000000f1
00007ffd30f0d1e8:  0000000000000011  0000000000000000
00007ffd30f0d1f8:  000000000069c31c  0000000000c1c080
00007ffd30f0d208:  000000000045814e <runtime.callCgoMmap+62>  00007ffd30f0d210
00007ffd30f0d218: <00007ffd30f0d268  fffffffe7fffffff
00007ffd30f0d228:  ffffffffffffffff  ffffffffffffffff
00007ffd30f0d238:  ffffffffffffffff  ffffffffffffffff
00007ffd30f0d248:  ffffffffffffffff  ffffffffffffffff
00007ffd30f0d258:  ffffffffffffffff  ffffffffffffffff
00007ffd30f0d268:  ffffffffffffffff  ffffffffffffffff
00007ffd30f0d278:  ffffffffffffffff  ffffffffffffffff
00007ffd30f0d288:  ffffffffffffffff  ffffffffffffffff
00007ffd30f0d298:  ffffffffffffffff  0000000000000000
00007ffd30f0d2a8:  00000000006b68ba  0000000000000020
00007ffd30f0d2b8:  0000000000000000  0000000000000000
00007ffd30f0d2c8:  0000000000000000  0000000000000000
00007ffd30f0d2d8:  0000000000000000  0000000000000000
00007ffd30f0d2e8:  0000000000000000  0000000000000000
00007ffd30f0d2f8:  0000000000000000  0000000000000000
00007ffd30f0d308:  0000000000000000  0000000000000000
runtime: unknown pc 0x6b657e
stack: frame={sp:0x7ffd30f0d218, fp:0x0} stack=[0x7ffd2ab0e738,0x7ffd30f0d760)
00007ffd30f0d118:  0000000000000002  00007ffd30f7f184
00007ffd30f0d128:  000000000069c31c  00007ffd30f0d1a8
00007ffd30f0d138:  000000000045814e <runtime.callCgoMmap+62>  00007ffd30f0d140
00007ffd30f0d148:  00007ffd30f0d190  0000000000411a88 <runtime.persistentalloc1+456>
00007ffd30f0d158:  0000000000bf6dd0  0000000000000000
00007ffd30f0d168:  0000000000010000  0000000000000008
00007ffd30f0d178:  0000000000bf6dd8  0000000000bf7ca0
00007ffd30f0d188:  00007fdcbb4b7000  00007ffd30f0d1c8
00007ffd30f0d198:  0000000000451205 <runtime.persistentalloc.func1+69>  0000000000000000
00007ffd30f0d1a8:  0000000000000000  0000000000c1c080
00007ffd30f0d1b8:  00007fdcbb4b7000  00007ffd30f0d1e0
00007ffd30f0d1c8:  00007ffd30f0d210  00007ffd30f0d220
00007ffd30f0d1d8:  0000000000000000  00000000000000f1
00007ffd30f0d1e8:  0000000000000011  0000000000000000
00007ffd30f0d1f8:  000000000069c31c  0000000000c1c080
00007ffd30f0d208:  000000000045814e <runtime.callCgoMmap+62>  00007ffd30f0d210
00007ffd30f0d218: <00007ffd30f0d268  fffffffe7fffffff
00007ffd30f0d228:  ffffffffffffffff  ffffffffffffffff
00007ffd30f0d238:  ffffffffffffffff  ffffffffffffffff
00007ffd30f0d248:  ffffffffffffffff  ffffffffffffffff
00007ffd30f0d258:  ffffffffffffffff  ffffffffffffffff
00007ffd30f0d268:  ffffffffffffffff  ffffffffffffffff
00007ffd30f0d278:  ffffffffffffffff  ffffffffffffffff
00007ffd30f0d288:  ffffffffffffffff  ffffffffffffffff
00007ffd30f0d298:  ffffffffffffffff  0000000000000000
00007ffd30f0d2a8:  00000000006b68ba  0000000000000020
00007ffd30f0d2b8:  0000000000000000  0000000000000000
00007ffd30f0d2c8:  0000000000000000  0000000000000000
00007ffd30f0d2d8:  0000000000000000  0000000000000000
00007ffd30f0d2e8:  0000000000000000  0000000000000000
00007ffd30f0d2f8:  0000000000000000  0000000000000000
00007ffd30f0d308:  0000000000000000  0000000000000000

goroutine 1 [running]:
runtime.systemstack_switch()
	/usr/local/go/src/runtime/asm_amd64.s:363 fp=0xc4200fe788 sp=0xc4200fe780 pc=0x454120
runtime.main()
	/usr/local/go/src/runtime/proc.go:128 +0x63 fp=0xc4200fe7e0 sp=0xc4200fe788 pc=0x42bb83
runtime.goexit()
	/usr/local/go/src/runtime/asm_amd64.s:2361 +0x1 fp=0xc4200fe7e8 sp=0xc4200fe7e0 pc=0x456c91

rax    0x0
rbx    0xbe2978
rcx    0x6b657e
rdx    0x0
rdi    0x2
rsi    0x7ffd30f0d1a0
rbp    0x8347ce
rsp    0x7ffd30f0d218
r8     0x0
r9     0x6
r10    0x8
r11    0x246
r12    0x2bedc30
r13    0xf1
r14    0x11
r15    0x0
rip    0x6b657e
rflags 0x246
cs     0x33
fs     0x0
gs     0x0
exec failed: container_linux.go:348: starting container process caused "read init-p: connection reset by peer"

由上可知，异常是runc返回的。

定位原因

定位异常组件的同时，runc还给了我们一个惊喜：提供了详细的异常日志。

异常日志表明：runc exec失败的原因是因为 Resource temporarily unavailable，比较典型的资源不足问题。而常见的资源不足类型主要包含（ulimit -a）：

线程数达到限制
文件数达到限制
内存达到限制

因此，我们需要进一步排查业务容器的监控，以定位不足的资源类型。

上图展示了业务容器的线程数监控。所有容器的线程数都已经达到1w，而弹性云默认限制容器的线程数上限就是1w，设定该上限的原因，也是为了避免单容器线程泄漏而耗尽宿主机的线程资源。

1
2
3

# cat /sys/fs/cgroup/pids/kubepods/burstable/pod64a6c0e7-830c-11eb-86d6-b8cef604db88/aa1e331ec24f621ab3152ebe94f1e533734164af86c9df0f551eab2b1967ec4e/pids.max

10000

至此，问题的原因已定位清楚，对，就是这么简单。

runc梳理

虽然，我们已经定位了异常日志的成因，但是，对于runc的具体工作机制，一直只有一个模糊的概念。

趁此机会，我们以runc exec为例，梳理runc的工作流程。

runc exec首先启动子进程runc init
runc init负责初始化容器namespace
- runc init利用C语言的constructor特性，实现在go代码启动之前，设置容器namespace
- C代码nsexec执行两次clone，共三个线程：父进程，子进程，孙进程，完成对容器namespace的初始化
- 父进程与子进程完成初始化任务后退出，此时，孙进程已经在容器namespace内，孙进程开始执行go代码初始化，并等待接收runc exec发送配置
runc exec将孙进程添加到容器cgroup
runc exec发送配置给孙进程，配置主要包含：exec的具体命令与参数等
孙进程调用system.Execv执行用户命令

注意：

步骤2.c与步骤3是并发执行的
runc exec与runc init通信基于socket pair对（init-p和init-c）

runc exec过程中各进程的交互流程，以及namespace与cgroup的初始化参见下图：

综合我们对runc exec执行流程的梳理，以及runc exec返回的错误信息，我们基本定位到了runc exec返回错误的代码：

func (p *setnsProcess) start() (err error) {
   defer p.parentPipe.Close()
   err = p.cmd.Start()
   p.childPipe.Close()
   if err != nil {
      return newSystemErrorWithCause(err, "starting setns process")
   }
   if p.bootstrapData != nil {
      if _, err := io.Copy(p.parentPipe, p.bootstrapData); err != nil {       // clone标志位，ns配置
         return newSystemErrorWithCause(err, "copying bootstrap data to pipe")
      }
   }
   if err = p.execSetns(); err != nil {
      return newSystemErrorWithCause(err, "executing setns process")
   }
   if len(p.cgroupPaths) > 0 {
      if err := cgroups.EnterPid(p.cgroupPaths, p.pid()); err != nil {        // 这里将runc init添加到容器cgroup中
         return newSystemErrorWithCausef(err, "adding pid %d to cgroups", p.pid())
      }
   }
   if err := utils.WriteJSON(p.parentPipe, p.config); err != nil {            // 发送配置：命令、环境变量等
      return newSystemErrorWithCause(err, "writing config to pipe")
   }

   ierr := parseSync(p.parentPipe, func(sync *syncT) error {                  // 这里返回 read init-p: connection reset by peer
      switch sync.Type {
      case procReady:
         // This shouldn't happen.
         panic("unexpected procReady in setns")
      case procHooks:
         // This shouldn't happen.
         panic("unexpected procHooks in setns")
      default:
         return newSystemError(fmt.Errorf("invalid JSON payload from child"))
      }
   })
   if ierr != nil {
      p.wait()
      return ierr
   }
   return nil
}

现在，问题的成因与代码分析已全部完成。

Reference

作者：plpan

原文出处：https://plpan.github.io/docker-exec-%E5%A4%B1%E8%B4%A5%E9%97%AE%E9%A2%98%E6%8E%92%E6%9F%A5%E4%B9%8B%E6%97%85/

阿里云ACK多个Service绑定单个SLB实践

2021-12-08T03:59:26.000Z

阿里云ACK是什么

阿里云容器服务Kubernetes版（Alibaba Cloud Container Service for Kubernetes，简称容器服务ACK）是全球首批通过Kubernetes一致性认证的服务平台，提供高性能的容器应用管理服务，支持企业级Kubernetes容器化应用的生命周期管理，让您轻松高效地在云端运行Kubernetes容器化应用。

Service几种暴露方式

Kubernetes Service 支持下面一些暴露方式：

NodePort：通过每个节点上的 IP 和静态端口（NodePort）暴露服务。 NodePort 服务会路由到自动创建的 ClusterIP 服务。通过请求 <节点 IP>:<节点端口>，你可以从集群的外部访问一个 NodePort 服务。
hostNetwork: true：Pod中运行的应用程序可以直接看到pod启动主机网络接口。
hostPort：是直接将容器端口与所调度节点上的端口路由，这样用户就可以通过宿主机IP加端口来访问Pod。
LoadBalancer：使用云提供商的负载均衡器向外部暴露服务。外部负载均衡器可以将流量路由到自动创建的 NodePort 服务和 ClusterIP 服务上。
ExternalName：通过返回 CNAME 和对应值，可以将服务映射到 externalName 字段的内容（例如，foo.bar.example.com）。无需创建任何类型代理。
Ingress：是自kubernetes1.1版本后引入的资源类型。必须要部署Ingress controller才能创建Ingress资源，Ingress controller是以一种插件的形式提供。Ingress controller 是部署在Kubernetes之上的Docker容器。它的Docker镜像包含一个像nginx或HAProxy的负载均衡器和一个控制器守护进程。控制器守护程序从Kubernetes接收所需的Ingress配置。它会生成一个nginx或HAProxy配置文件，并重新启动负载平衡器进程以使更改生效。换句话说，Ingress controller是由Kubernetes管理的负载均衡器。

需求

使用阿里云ACK容器服务时，我们Service默认就支持缓存LoadBalancer，大家有可能第一种念想，每个Service绑定一个SLB，这样会不会太浪费SLB。也可以通过Ingress来实现外部用户访问K8S集群内部。

Ingress是可以实现，但如果我们业务中有很多不是80或者443端口访问的，并且还在一个域名，比如下面：

www.example.com:8888
www.example.com:8080
www.example.com:8081

这种一般不推荐使用Ingress来实现，因为这样Ingress会开放很多端口，以后不便于维护。

那有没有在SLB充分利用前提下，实现上面的需求。方法当然有的，阿里云ACK支持多个Service绑定一个SLB多个端口。

多个Service绑定一个SLB多个端口用法

PS: 前提条件：需要提前在SLB控制台创建SLB，SLB需要和K8S在同一个VPC网络下

Service声明TCP协议

apiVersion: v1
kind: Service
metadata:
  annotations:
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-force-override-listeners: "true"
    # 仅支持TCP和UDP协议。如需设置连接优雅中断，以下两项Annotation必选
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-connection-drain: "on"
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-connection-drain-timeout: "30"
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-delete-protection: "on"
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-modification-protection: "ConsoleProtection"
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-id: "slb-id"
    # ACK是Terway网络模式下，通过annotation：service.beta.kubernetes.io/backend-type："eni"将Pod直接挂载到SLB后端，提升网络转发性能。
    service.beta.kubernetes.io/backend-type: "eni"
  name: nginx
spec:
  externalTrafficPolicy: Cluster
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: nginx
  type: LoadBalancer

Service声明使用https协议

apiVersion: v1
kind: Service
metadata:
  annotations:
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-protocol-port: "https:8888"
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-flag: "on"
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-type: "http"
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-uri: "/health"
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-healthy-threshold: "4"
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-unhealthy-threshold: "4"
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-timeout: "10"
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-interval: "3"
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-cert-id: "证书id"
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-force-override-listeners: "true"
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-delete-protection: "on"
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-modification-protection: "ConsoleProtection"
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-id: "slb-id"
    # ACK是Terway网络模式下，通过annotation：service.beta.kubernetes.io/backend-type："eni"将Pod直接挂载到SLB后端，提升网络转发性能。
    service.beta.kubernetes.io/backend-type: eni
  name: nginx
spec:
  externalTrafficPolicy: Cluster
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: nginx
  type: LoadBalancer

Service声明使用http协议

apiVersion: v1
kind: Service
metadata:
  annotations:
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-protocol-port: "http:8080"
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-flag: "on"
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-type: "http"
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-uri: "/health"
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-healthy-threshold: "4"
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-unhealthy-threshold: "4"
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-timeout: "10"
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-interval: "3"
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-force-override-listeners: "true"
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-delete-protection: "on"
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-modification-protection: "ConsoleProtection"
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-id: "slb-id"
    # ACK是Terway网络模式下，通过annotation：service.beta.kubernetes.io/backend-type："eni"将Pod直接挂载到SLB后端，提升网络转发性能。
    service.beta.kubernetes.io/backend-type: eni
  name: nginx
  namespace: default
spec:
  externalTrafficPolicy: Cluster
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:b
    run: nginx
  type: LoadBalancer

参考链接

K8S部署分布式调度任务Airflow

2021-11-28T07:46:43.000Z

一、部署要求

Apache Airflow 已通过以下测试：

	Main version (dev)	Stable version (2.1.4)
Python	3.6, 3.7, 3.8, 3.9	3.6, 3.7, 3.8, 3.9
Kubernetes	1.20, 1.19, 1.18	1.20, 1.19, 1.18
PostgreSQL	9.6, 10, 11, 12, 13	9.6, 10, 11, 12, 13
MySQL	5.7, 8	5.7, 8
SQLite	3.15.0+	3.15.0+
MSSQL(Experimental)	2017,2019

注意: MySQL 5.x 版本不能或有运行多个调度程序的限制——请参阅调度程序文档。MariaDB 未经过测试/推荐。

注意: SQLite 用于 Airflow 测试。不要在生产中使用它。我们建议使用最新的 SQLite 稳定版本进行本地开发。

PS：本文部署 Airflow 稳定版 2.1.4，Kubernetes使用1.20.x版本，PostgreSQL使用12.x，使用Helm Charts部署。

二、生成Helm Charts配置

PS：使用 helm 3 版本部署

# 创建kubernetes airflow 命名空间
$ kubectl create namespace airflow

# 添加 airflow charts 仓库源
$ helm repo add apache-airflow https://airflow.apache.org

# 更新 aiarflow 源
$ helm repo update

# 查看 airflow charts 所有版本（这里选择部署charts 1.2.0，也就是airflow 2.1.4）
$ helm search repo apache-airflow/airflow -l

NAME                  	CHART VERSION	APP VERSION	DESCRIPTION
apache-airflow/airflow	1.3.0        	2.2.1      	The official Helm chart to deploy Apache Airflo...
apache-airflow/airflow	1.2.0        	2.1.4      	The official Helm chart to deploy Apache Airflo...
apache-airflow/airflow	1.1.0        	2.1.2      	The official Helm chart to deploy Apache Airflo...
apache-airflow/airflow	1.0.0        	2.0.2      	Helm chart to deploy Apache Airflow, a platform...

# 导出 airflow charts values.yaml 文件
$ helm show values apache-airflow/airflow --version 1.2.0 > airflow_1.2.4_values.yaml

三、修改airflow配置

3.1 配置持续存储 StorageClass

PS: 使用阿里云NAS极速存储

# 编辑 StorageClass 文件
$ vim alicloud-nas-airflow-test.yaml

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: alicloud-nas-airflow-test
mountOptions:
  - nolock,tcp,noresvport
  - vers=3
parameters:
  volumeAs: subpath
  server: "xxxxx.cn-beijing.extreme.nas.aliyuncs.com:/share/airflow/"
provisioner: nasplugin.csi.alibabacloud.com
reclaimPolicy: Retain

# 应用到K8S中
$ kubectl apply -f alicloud-nas-airflow-test.yaml

3.2 配置 airflow Dags 存储仓库 gitSshKey

# 编辑 airflow-ssh-secret.yaml 文件，首先需要把shh公钥添加到git项目仓库中
$ vim airflow-ssh-secret.yaml

apiVersion: v1
kind: Secret
metadata:
  name: airflow-ssh-secret
  namespace: airflow
data:
  # key needs to be gitSshKey
  gitSshKey: "ssh私钥，base64"

# 应用到K8S中
$ kubectl apply -f airflow-ssh-secret.yaml

3.3 Docker 部署 PostgreSQL 12

# 创建 postgresql 存储目录
$ mkdir /data/postgresql_data

# 创建启动文件 
$ vim docker-compose.yaml

version: "3"

services:
  airflow-postgres:
    image: postgres:12
    restart: always
    container_name: airflow-postgres
    environment:
      TZ: Asia/Shanghai
      POSTGRES_USER: airflow
      POSTGRES_PASSWORD: Airflow123
    volumes:
      - /data/postgresql_data:/var/lib/postgresql/data
    ports:
      - "5432:5432"

# 启动 postgresql docker
$ docker-compose up -d

3.4 修改 airflow_1.2.4_values.yaml 配置

PS：本文 airflow_1.2.4_values.yaml 配置文件需要三个pvc，服务分别是 redis、worker(只部署1个worker，可以部署多个worker)、dags

因配置文件太长，不具体贴出，具体内容请参考下面链接：

https://github.com/yangpeng14/DevOps/blob/master/config_dir/airflow_1.2.4_values.yaml

四、部署 Airfolw

# 第一次部署 Airflow
$ helm install airflow apache-airflow/airflow --namespace airflow --version 1.2.0 -f airflow_1.2.4_values.yaml

# 以后如果要修改airflow配置，请使用下面命令
$ helm upgrade --install airflow apache-airflow/airflow --namespace airflow --version 1.2.0 -f airflow_1.2.4_values.yaml

五、配置 Airflow Ingress Nginx 访问入口

# 生成 ingress nginx 配置文件
$ vim airflow-ingress.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: airflow
  namespace: airflow
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/ssl-redirect: "false"
    nginx.ingress.kubernetes.io/proxy-connect-timeout: "60"
    nginx.ingress.kubernetes.io/proxy-read-timeout: "60"
    nginx.ingress.kubernetes.io/proxy-send-timeout: "60"
spec:
  rules:
  - host: "airflow.example.com"
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: airflow-webserver
            port:
              number: 8080

# 应用到K8S中
$ kubectl apply -f airflow-ingress.yaml

六、参考链接

Ingress Nginx传递用户真实IP问题

2021-10-30T05:38:11.000Z

背景

业务应用经常有需要用到用户真实ip的场景，比如：异地登录的风险预警、访问用户分布统计等功能等。当有这种需求的时候，在业务上容器过程中，如果用到ingress就要注意配置了。通常，用户ip的传递依靠的是X-Forwarded-*参数。但是默认情况下，ingress是没有开启的。

ingress的文档 https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration 还比较详细，这里介绍一下用到的3个参数：

注：在文档顶栏的搜索框搜索forward字样就可以找到这3个参数

1. use-forwarded-headers

如果Nginx在其他7层代理或负载均衡后面，当期望Nginx将X-Forwarded-*的头信息传递给后端服务时，则需要将此参数设为true
如果设为false（默认为false），Nginx会忽略掉X-Forwarded-*的头信息。false设置适用于Nginx直接对外或前面只有3层负载均衡的场景

由于ingress的主配置是从configmap中获取的，更新参数则需要修改名为nginx-configuration的configmap的配置：在data配置块下添加use-forwarded-headers: "true"

修改后，ingress nginx会自动加载更新nginx.conf主配置文件。下图为更新前后配置文件变化对比：

注：左边为开启use-forwarded-headers后ingress nginx主配置文件，右边为开启前

2. forwarded-for-header

用来设置识别客户端来源真实ip的字段，默认是X-Forwarded-For。如果想修改为自定义的字段名，则可以在configmap的data配置块下添加：forwarded-for-header: "THE_NAME_YOU_WANT"。通常情况下，我们使用默认的字段名就满足需求，所以不用对这个字段进行额外配置。

3. compute-full-forwarded-for

如果只是开启了use-forwarded-headers: "true"的话，会发现还是没能获取到客户端来源的真实ip，原因是当前X-Forwarded-For变量是从remote_addr获取的值，每次取到的都是最近一层代理的ip。为了解决这个问题，就要配置compute-full-forwarded-for字段了，即在configmap的data配置块添加：compute-full-forwarded-for: "true"。其作用就是，将客户端用户访问所经过的代理ip按逗号连接的列表形式记录下来。

待ingress nginx加载configmap并更新主配置文件后，对比更新前后变化如下：

注：左边是未开启compute-full-forwarded-for配置的ingress nginx主配置文件，右边是开启了的

举例说明

如果从客户端ip0发起一个HTTP请求到达服务器之前，经过了三个代理proxy1、proxy2、proxy3，对应的ip分别为ip1、ip2、ip3，那么服务端最后得到的X-Forwarded-For值为：ip0,ip1,ip2。列表中并没有ip3，ip3可以在服务端通过remote_addr来获得。这样应用程序通过获取X-Forwarded-For字段的第一个ip，就可以得到客户端用户真实ip了。

注意项

值得注意的是，并不是所有的场景都能通过X-Forwarded-For来获取用户正式ip。
比如，当服务器前端使用了CDN的时候，X-Forwarded-For方式获取到的可能就是CDN的来源ip了，
这种情况，可以根CDN厂商约定一个字段名来记录用户真实ip，然后代理将这个字段逐层传递，最后到服务端。

作者：felix_yujing

原文链接：https://blog.csdn.net/felix_yujing/article/details/106616962

Kubectl 高亮输出

2021-10-13T11:58:28.000Z

kubecolor 带有色彩输出

获取 kubernetes node 节点信息

显示 kubernetes pods 详细信息

更换背影颜色主题

从上面来看，带有色彩输出比没有带色彩输出看的更舒服些。

Kubecolor 如何运行？

kubecolor 为 kubectl 命令输出着色，不执行任何其他操作。kubecolor 在内部调用 kubectl command 并尝试对输出进行着色。

Kubecolor 安装

二进制文件安装

打开 https://github.com/dty1er/kubecolor/releases 页面，下载相应的二进制文件，下载文件后，把文件放到 /usr/local/bin 目录下，并把文件添加执行权限。

Mac 安装

1	$ brew install dty1er/tap/kubecolor

Kubecolor 用法

如果习惯使用 kubectl，可以把 kubecolor 命令做一个 kubectl 别名。具体在 .bash_profile 文件中配置，下面是具体配置。kubecolor 使用和 kubectl 命令方法一样。

1	alias kubectl="kubecolor"

当 kubecolor 输出 tty 不是标准输出时，它会自动禁用着色。例如，如果您正在运行 kubecolor get pods > result.txt 或 kubecolor get pods | grep xxx，则输出将传递到文件或其它命令，因此不会着色。在这种情况下，您可以通过传递 --force-colors 标志来强制 kubecolor 进行着色。

项目地址：https://github.com/dty1er/kubecolor

参考链接

https://github.com/dty1er/kubecolor

聊聊TPS、QPS、CPS概念和区别.md

2021-07-29T03:46:01.000Z

TPS 概念

TPS：是TransactionsPerSecond的缩写，也就是事务数/秒。它是软件测试结果的测量单位。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数。

QPS 概念

QPS：Queries Per Second意思是每秒查询率，是一台服务器每秒能够相应的查询次数，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。

CPS 概念

CPS：Connection Per Second意思是每秒新建连接数，定义了新建连接的速率。当新建连接的速率超过规格定义的每秒新建连接数时，新建连接请求将被丢弃。

TPS 与 QPS 区别

TPS 即每秒处理事务数，包括以下部分：

1、用户请求服务器
2、服务器自己的内部处理
3、服务器返回给用户

这三个过程，每秒能够完成N个这三个过程，TPS也就是N。

QPS 基本类似于TPS，但是不同的是，对于一个页面的一次访问，形成一个TPS。但一次页面请求，可能产生多次对服务器的请求，服务器对这些请求，就可计入QPS之中。

例如：访问一个页面会请求服务器3次，一次访问，产生一个“T”，产生3个“Q”。

QPS 计算公式

每秒查询率QPS是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准，在因特网上，作为域名系统服务器的机器的性能经常用每秒查询率来衡量。

原理：每天80%的访问集中在20%的时间里，这20%时间叫做峰值时间
公式：( 总PV数 80% ) / ( 每天秒数 20% ) = 峰值时间每秒请求数(QPS)
机器：峰值时间每秒QPS / 单台机器的QPS = 需要的机器

问：每天300w PV 的在单台机器上，这台机器需要多少QPS？

答：( 3000000 0.8 ) / (86400 0.2 ) = 139 (QPS)

问：如果一台机器的QPS是58，需要几台机器来支持？

答：139 / 58 = 3

系统吞吐量

一个系统的吞度量（承压能力）与request对CPU的消耗、外部接口、IO等等紧密关联。单个reqeust 对CPU消耗越高，外部系统接口、IO影响速度越慢，系统吞吐能力越低，反之越高。

系统吞吐量几个重要参数：QPS（TPS）、并发数、响应时间

QPS（TPS）：每秒钟request/事务数量
并发数：系统同时处理的request/事务数
响应时间：一般取平均响应时间

理解了上面三个要素的意义之后，就能推算出它们之间的关系：

QPS（TPS）= 并发数/平均响应时间或者并发数 = QPS*平均响应时间

参考链接

K8S Configmap和Secret热更新之Reloader

2021-07-24T04:16:01.000Z

一背景

1.1 配置中心问题

在云原生中配置中心，例如：Configmap和Secret对象，虽然可以进行直接更新资源对象

对于引用这些有些不变的配置是可以打包到镜像中的，那可变的配置呢？
信息泄漏，很容易引发安全风险，尤其是一些敏感信息，比如密码、密钥等。
每次配置更新后，都要重新打包一次，升级应用。镜像版本过多，也给镜像管理和镜像中心存储带来很大的负担。
定制化太严重，可扩展能力差，且不容易复用。

1.2 使用方式

Configmap或Secret使用有两种方式，一种是env系统变量赋值，一种是volume挂载赋值，env写入系统的configmap是不会热更新的，而volume写入的方式支持热更新！

对于env环境的，必须要滚动更新pod才能生效，也就是删除老的pod，重新使用镜像拉起新pod加载环境变量才能生效。
对于volume的方式，虽然内容变了，但是需要我们的应用直接监控configmap的变动，或者一直去更新环境变量才能在这种情况下达到热更新的目的。

应用不支持热更新，可以在业务容器中启动一个sidercar容器，监控configmap的变动，更新配置文件，或者也滚动更新pod达到更新配置的效果。

二解决方案

ConfigMap 和 Secret 是 Kubernetes 常用的保存配置数据的对象，你可以根据需要选择合适的对象存储数据。通过 Volume 方式挂载到 Pod 内的，kubelet 都会定期进行更新。但是通过环境变量注入到容器中，这样无法感知到 ConfigMap 或 Secret 的内容更新。

目前如何让 Pod 内的业务感知到 ConfigMap 或 Secret 的变化，还是一个待解决的问题。但是我们还是有一些 Workaround 的。

如果业务自身支持 reload 配置的话，比如nginx -s reload，可以通过 inotify 感知到文件更新，或者直接定期进行 reload（这里可以配合我们的 readinessProbe 一起使用）。

如果我们的业务没有这个能力，考虑到不可变基础设施的思想，我们是不是可以采用滚动升级的方式进行？没错，这是一个非常好的方法。目前有个开源工具Reloader，它就是采用这种方式，通过 watch ConfigMap 和 Secret，一旦发现对象更新，就自动触发对 Deployment 或 StatefulSet 等工作负载对象进行滚动升级。

三 reloader简介

3.1 reloader简介

Reloader 可以观察 ConfigMap 和 Secret 中的变化，并通过相关的 deploymentconfiggs、 deploymentconfiggs、 deploymonset 和 statefulset 对 Pods 进行滚动升级。

3.2 reloader安装

helm安装

1
2
3

$ helm repo add stakater https://stakater.github.io/stakater-charts
$ helm repo update
$ helm install stakater/reloader

Kustomize

1	$ kubectl apply -k https://github.com/stakater/Reloader/deployments/kubernetes

资源清单安装

$ kubectl apply -f https://raw.githubusercontent.com/stakater/Reloader/master/deployments/kubernetes/reloader.yaml

clusterrole.rbac.authorization.k8s.io/reloader-reloader-role created
clusterrolebinding.rbac.authorization.k8s.io/reloader-reloader-role-binding created
deployment.apps/reloader-reloader created
serviceaccount/reloader-reloader created


NAME                                     READY   STATUS    RESTARTS   AGE
pod/reloader-reloader-66d46d5885-nx64t   1/1     Running   0          15s

NAME                                READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/reloader-reloader   1/1     1            1           16s

NAME                                           DESIRED   CURRENT   READY   AGE
replicaset.apps/reloader-reloader-66d46d5885   1         1         1       16s

reloader 能够配置忽略cm或者secrets资源，可以通过配置在reader deploy中的spec.template.spec.containers.args，如果两个都忽略，那就缩小deploy为0，或者不部署reoader。

Args	Description
--resources-to-ignore=configMaps	To ignore configMaps
--resources-to-ignore=secrets	To ignore secrets

3.3 配置

3.3.1 自动更新

reloader.stakater.com/search 和 reloader.stakater.com/auto 并不在一起工作。如果你在你的部署上有一个 reloader.stakater.com/auto : “true”的注释，该资源对象引用的所有configmap或这secret的改变都会重启该资源，不管他们是否有 reloader.stakater.com/match : “true”的注释。

kind: Deployment
metadata:
  annotations:
    reloader.stakater.com/auto: "true"
spec:
  template: metadata:

3.3.2 制定更新

指定一个特定的configmap或者secret，只有在我们指定的配置图或秘密被改变时才会触发滚动升级，这样，它不会触发滚动升级所有配置图或秘密在部署，后台登录或状态设置中使用。

一个制定deployment资源对象，在引用的configmap或者secret种，只有reloader.stakater.com/match: "true"为true才会出发更新，为false或者不进行标记，该资源对象都不会监视配置的变化而重启。

kind: Deployment
metadata:
  annotations:
    reloader.stakater.com/search: "true"
spec:
  template:

cm配置

kind: ConfigMap
metadata:
  annotations:
    reloader.stakater.com/match: "true"
data:
  key: value

3.3.3 指定cm

如果一个deployment挂载有多个cm或者的场景下，我们只希望更新特定一个cm后，deploy发生滚动更新，更新其他的cm，deploy不更新，这种场景可以将cm在deploy中指定为单个或着列表实现。

例如：一个deploy有挂载nginx-cm1和nginx-cm2两个configmap，只想nginx-cm1更新的时候deploy才发生滚动更新，此时无需在两个cm中配置注解，只需要在deploy中写入configmap.reloader.stakater.com/reload:nginx-cm1，其中nginx-cm1如果发生更新，deploy就会触发滚动更新。

如果多个cm直接用逗号隔开

# configmap对象
kind: Deployment
metadata:
  annotations:
    configmap.reloader.stakater.com/reload: "nginx-cm1"
spec:
  template: metadata:

# secret对象
kind: Deployment
metadata:
  annotations:
    secret.reloader.stakater.com/reload: "foo-secret"
spec:
  template: metadata:

无需在cm或secret中添加注解，只需要在引用资源对象中添加注解即可。

四测试

4.1 deploy

apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:   
    reloader.stakater.com/search: "true"
  labels:
    run: nginx
  name: nginx
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      run: nginx
  template:
    metadata:
      labels:
        run: nginx
    spec:
      containers:
      - image: nginx
        name: nginx
        volumeMounts:       
        - name: nginx-cm
          mountPath: /data/cfg
          readOnly: true
      volumes:      
      - name: nginx-cm
        configMap:          
          name: nginx-cm
          items:          
          - key: config.yaml        
            path: config.yaml
            mode: 0644

4.2 configmap

apiVersion: v1
data:
  config.yaml: |
    # project settings
    DEFAULT_CONF:
      port: 8888 
    UNITTEST_TENCENT_ZONE: ap-chongqing-1
kind: ConfigMap
metadata:
  name: nginx-cm
  annotations:
    reloader.stakater.com/match: "true"

4.3 测试

$ kubectl  get pod
NAME                     READY   STATUS    RESTARTS   AGE
nginx-68c9bf4ff7-9gmg6   1/1     Running   0          10m

$ kubectl  get cm
NAME       DATA   AGE
nginx-cm   1      28m

# 更新cm内容

$ kubectl edit cm nginx-cm 

configmap/nginx-cm edited

# 查看po发生了滚动更新，重新加载配置文件
$ kubectl get pod

NAME                     READY   STATUS              RESTARTS   AGE
nginx-66c758b548-9dllm   0/1     ContainerCreating   0          4s
nginx-68c9bf4ff7-9gmg6   1/1     Running             0          10m

五 Reloader 使用注意事项

Reloader 为全局资源对象，建议部署在一个公共服务的ns下，然后其他ns也可以正常使用reloader特性。
Reloader.stakater.com/auto : 如果配置configmap或者secret在 deploymentconfigmap/deployment/daemonsets/Statefulsets
secret.reloader.stakater.com/reload 或者 configmap.reloader.stakater.com/reload 注释中被使用，那么 true 只会重新加载 pod，不管使用的是 configmap 还是 secret。
reloader.stakater.com/search 和 reloader.stakater.com/auto 不能同时使用。如果你在你的部署上有一个 reloader.stakater.com/auto : “true”的注释，那么它总是会在你修改了 configmaps 或者使用了机密之后重新启动，不管他们是否有 reloader.stakater.com/match : “true”的注释。

六反思

Reloader通过 watch ConfigMap 和 Secret，一旦发现对象更新，就自动触发对 Deployment 或 StatefulSet 等工作负载对象进行滚动升级。

如果我们的应用内部没有去实时监控配置文件，利用该方式可以非常方便的实现配置的热更新。

参考链接

https://github.com/stakater/Reloader

作者: kaliarch

原文出处: https://juejin.cn/post/6897882769624727559

Mysqldump导入备份数据到阿里云RDS会报错吗

2021-06-20T09:55:37.000Z

前言

大家都知道，数据量小的备份都使用 mysqldump 命令来备份，最近本人从阿里云RDS实例备份博客数据，并再次把备份出来的数据导入到RDS实例时，会遇到错误 [Err] 1227 - Access denied; you need (at least one of) the SUPER privilege(s) for this operation。

PS：阿里云RDS实例版本：5.6

遇到上面错误感觉很奇怪，为什么没有权限写入，使用的账号是高级账号，为什么没有权限了？？？

错误原因

通过上面报错，查找阿里云帮助文档，最后找到答案，下面是具体解决方法。

导入RDS MySQL 实例：SQL 语句中含有需要 Supper 权限才可以执行的语句，而 RDS MySQL不提供 Super 权限，因此需要去除这类语句。
本地 MySQL 实例没有启用 GTID。

解决方法

1、去除 DEFINER 子句

检查 SQL 文件，去除下面类似的子句

1	DEFINER=`root`@`%`

在 Linux 平台下，可以尝试使用下面的语句去除：

1	$ sed -e 's/DEFINER[ ]=[ ][^]\/\/ ' your.sql > your_revised.sql

2、去除 GTID_PURGED 子句

1	检查 SQL 文件，去除下面类似的语句

1 2	SET @@GLOBAL.GTID_PURGED='d0502171-3e23-11e4-9d65-d89d672af420:1-373, d5deee4e-3e23-11e4-9d65-d89d672a9530:1-616234';

在 Linux 平台，可以使用下面的语句去除

1	$ awk '{ if (index($0,"GTID_PURGED")) { getline; while (length($0) > 0) { getline; } } else { print $0 } }' your.sql \| grep -iv 'set @@' > your_revised.sql

3、检查修改后的文件

修改完毕后，通过下面的语句检查是否合乎要求。

1	$ egrep -in "definer\|set @@" your_revised.sql

如果上面的语句没有输出，说明 SQL 文件符合要求。

参考链接

阿里云文档：https://developer.aliyun.com/article/66463

K8S集群内Pod如何与本地网络打通实现debug

2021-06-05T22:41:41.000Z

前言

大家都知道，在没有K8S集群时，我们能直接连接测试环境服务实现debug。随着K8S到来，我们无法直接连接业务服务dubug，K8S Pod 分配的IP地址是集群内部网络，集群外部网络是无法直接访问到Pod，那有什么好的解决方法能直接连接Pod？下面介绍下开源 Telepresence。

Telepresence 简介

Telepresence 是一种开源工具，可让您在本地运行单个服务，同时将该服务连接到远程 Kubernetes 集群。这使开发 multi-service 应用程序的开发人员能够：

对单个服务进行快速本地开发，即使该服务依赖于集群中的其他服务。对您的服务进行更改并保存，您可以立即看到正在运行的新服务。
使用本地安装的任何工具来测试/调试/编辑您的服务。例如，您可以使用调试器或 IDE！
让您的本地开发机器像 Kubernetes 集群的一部分一样运行。如果您的机器上有一个应用程序要针对集群中的服务运行——这很容易做到。

开源地址: https://github.com/telepresenceio/telepresence

Telepresence 如何运行

Telepresence 在 Kubernetes 集群中运行的 pod 中部署双向网络代理。此 pod 将数据从您的 Kubernetes 环境（例如 TCP 连接、环境变量、卷）代理到本地进程。本地进程的网络被透明覆盖，以便 DNS 调用和 TCP 连接通过代理路由到远程 Kubernetes 集群。

这种方法给出：

您的本地服务可以完全访问远程集群中的其他服务
您的本地服务对 Kubernetes environment、secrets和 ConfigMap 的完全访问权限
您的远程服务可以完全访问您的本地服务

Telepresence 支持的运行平台

Mac OS X
Linux

Telepresence 安装

可使用 Homebrew、apt 或 dnf 安装

Telepresence 使用报告

Telepresence 收集有关其用户的一些基本信息，以便它可以发送重要的客户通知，例如新版本可用性和安全公告。我们还使用这些信息匿名汇总基本使用情况分析。要禁用此行为，请设置环境变量 SCOUT_DISABLE：

1	export SCOUT_DISABLE=1

Telepresence 使用方法

这里不在描述，具体参考 https://www.telepresence.io/tutorials/kubernetes

参考链接

Harbor多实例高可用共享存储搭建

2021-05-16T11:14:17.000Z

多实例共享存储架构图

本文 LB 不使用 Nginx，使用阿里SLB。

更多 Harbor 架构，请参考聊聊Harbor架构

本文架构需要考虑三个问题

1、共享存储的选取，Harbor的后端存储目前支持AWS S3、Openstack Swift, Ceph等。本文使用阿里云极速性NAS，磁盘IO性能比单块磁盘读写性能要好。使用 NFS V3 版本挂载。
2、Session 不能在不同的实例上共享，所以Harbor Redis 需要单独部署，并且多个实例连接相同的Redis。
3、Harbor多实例数据库问题，必须单独部署一个数据库，并且多个实例连接相同的数据库。

注意：生产环境如果使用阿里云NAS，推荐使用 极速性NAS，不推荐使用 通用型NAS。

阿里云NAS性能参考文档 https://help.aliyun.com/document_detail/124577.html?spm=a2c4g.11186623.6.552.2eb05ea0HJUgUB

部署资源

主机名	IP地址	系统
harbor1	192.168.10.10	centos7.9
harbor2	192.168.10.11	centos7.9

部署

Harbor 选择在线部署，使用 docker-compose 部署，docker-compose 和 Docker 部署环境本文不在介绍，网上可以搜索到相关文档。

1、挂载阿里云极速性NAS

harbor1 和 harbor2 机器都需要执行挂载 NAS

配置开机自动挂载，打开 /etc/fstab 配置文件，添加挂载命令。

# 创建 NAS 挂载目录
$ mkdir /data

# 提高同时发起的NFS请求数量
$ sudo echo "options sunrpc tcp_slot_table_entries=128" >>  /etc/modprobe.d/sunrpc.conf 
$ sudo echo "options sunrpc tcp_max_slot_table_entries=128" >>  /etc/modprobe.d/sunrpc.conf

挂载NFS v4文件系统，添加以下命令：

1	file-system-id.region.nas.aliyuncs.com:/ /data nfs vers=4,minorversion=0,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,_netdev,noresvport 0 0

如果您要挂载NFS v3文件系统，添加以下命令：

1	file-system-id.region.nas.aliyuncs.com:/ /data nfs vers=3,nolock,proto=tcp,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,_netdev,noresvport 0 0

# 在 /etc/fstab 配置文件添加好挂载，并执行挂载
$ mount -a

# 检查挂载，如果结果中存在NFS文件系统的挂载地址，则说明挂载成功
$ df -h | grep aliyun

2、临时部署单机 Harbor

在 harbor1 机器上操作

# 在线部署Harbor
$ cd /opt/
$ wget https://github.com/goharbor/harbor/releases/download/v2.2.1/harbor-online-installer-v2.2.1.tgz
$ tar xf harbor-online-installer-v2.2.1.tgz
$ cd /opt/harbor
$ cp harbor.yml.tmpl harbor.yml

# 创建harbor数据存储
$ mkdir /data/harbor

# 添加域名证书，已有域名SSL证书
$ mkdir /data/harbor/cert

# 把SSL证书公钥和私钥上传到 /data/harbor/cert 目录中
$ scp harbor.example.pem root@192.168.10.10:/data/harbor/cert/
$ scp harbor.example.key root@192.168.10.10:/data/harbor/cert/

# 配置 harbor.yml 文件，下面是修改后文件与原文件比较结果
$ diff harbor.yml harbor.yml.tmpl

5c5
< hostname: harbor.example.com
---
> hostname: reg.mydomain.com
17,18c17,18
<   certificate: /data/harbor/cert/harbor.example.pem
<   private_key: /data/harbor/cert/harbor.example.key
---
>   certificate: /your/certificate/path
>   private_key: /your/private/key/path
29c29
< external_url: https://harbor.example.com
---
> # external_url: https://reg.mydomain.com:8433

< data_volume: /data/harbor
---
> data_volume: /data

# 生成配置文件
$ cd /opt/harbor

# harbor开启helm charts 和 镜像漏洞扫描
$ ./prepare --with-notary --with-trivy --with-chartmuseum

# 安装
$ ./install.sh --with-notary --with-trivy --with-chartmuseum

# 查看
$ docker-compose ps

3、单独部署Harbor数据库和Redis

# 创建 postgres 和 redis 存储目录
$ mkdir -p /data/harbor-redis /data/harbor-postgresql

# 修改所属组
$ chown -R 999.999 /data/harbor-redis /data/harbor-postgresql

# 创建 postgres 和 redis docker-compose.yml 文件
$ vim docker-compose.yml

version: '2.3'

services:
  redis:
    image: goharbor/redis-photon:v2.2.1
    container_name: harbor-redis
    restart: always
    cap_drop:
      - ALL
    cap_add:
      - CHOWN
      - SETGID
      - SETUID
    volumes:
      - /data/harbor-redis:/var/lib/redis
    networks:
      - harbor-db
    ports:
      - 6379:6379
  postgresql:
    image: goharbor/harbor-db:v2.2.1
    container_name: harbor-postgresql
    restart: always
    cap_drop:
      - ALL
    cap_add:
      - CHOWN
      - DAC_OVERRIDE
      - SETGID
      - SETUID
    environment:
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: test2021
    volumes:
      - /data/harbor-postgresql:/var/lib/postgresql/data:z
    networks:
      - harbor-db
    ports:
      - 5432:5432

networks:
 harbor-db:
   driver: bridge

# 部署 postgres 和 redis
$ docker-compose up -d

4、导入 postgres 数据

# 进入临时harbor-db容器导出相关表及数据
$ docker exec -it -u postgres harbor-db bash

# 导出数据
$ pg_dump -U postgres registry > /tmp/registry.sql 
$ pg_dump -U postgres notarysigner > /tmp/notarysigner.sql  
$ pg_dump -U postgres notaryserver > /tmp/notaryserver.sql

# 将数据导入单独部署的PostgreSQL数据库
$ psql -h 192.168.10.10 -U postgres registry -W < /tmp/registry.sql
$ psql -h 192.168.10.10 -U postgres notarysigner -W < /tmp/notarysigner.sql
$ psql -h 192.168.10.10 -U postgres notaryserver -W < /tmp/notaryserver.sql

5、清理临时部署单机Harbor数据和相关配置文件

# 清理harbr数据和配置文件
$ cp -a /data/harbor/cert /tmp/
$ rm -rf /data/harbor/*
$ rm -rf /opt/harbor
$ cp -a /tmp/cert /data/harbor/

# 重新创建配置文件
$ cd /opt/
$ tar xf harbor-online-installer-v2.2.1.tgz
$ cd /opt/harbor

# 修改配置文件，连接单独部署postgres和redis，注释harbor自带的postgres和redis
$ cp harbor.yml.tmpl harbor.yml
$ diff harbor.yml harbor.yml.tmpl

5c5
< hostname: harbor.example.com
---
> hostname: reg.mydomain.com
17,18c17,18
<   certificate: /data/harbor/cert/harbor.example.pem
<   private_key: /data/harbor/cert/harbor.example.key
---
>   certificate: /your/certificate/path
>   private_key: /your/private/key/path
29c29
< external_url: https://harbor.example.com
---
> # external_url: https://reg.mydomain.com:8433

37c37
< # database:
---
> database:
39c39
<   # password: root123
---
>   password: root123
41c41
<   # max_idle_conns: 50
---
>   max_idle_conns: 50
44c44
<   # max_open_conns: 1000
---
>   max_open_conns: 1000
47c47

< data_volume: /data/harbor
---
> data_volume: /data

135,158c135,158
< external_database:
<   harbor:
<     host: 192.168.10.10
<     port: 5432
<     db_name: registry
<     username: postgres
<     password: test2021
<     ssl_mode: disable
<     max_idle_conns: 50
<     max_open_conns: 1000
<   notary_signer:
<     host: 192.168.10.10
<     port: 5432
<     db_name: notarysigner
<     username: postgres
<     password: test2021
<     ssl_mode: disable
<   notary_server:
<     host: 192.168.10.10
<     port: 5432
<     db_name: notaryserver
<     username: postgres
<     password: test2021
<     ssl_mode: disable
---
> # external_database:
> #   harbor:
> #     host: harbor_db_host
> #     port: harbor_db_port
> #     db_name: harbor_db_name
> #     username: harbor_db_username
> #     password: harbor_db_password
> #     ssl_mode: disable
> #     max_idle_conns: 2
> #     max_open_conns: 0
> #   notary_signer:
> #     host: notary_signer_db_host
> #     port: notary_signer_db_port
> #     db_name: notary_signer_db_name
> #     username: notary_signer_db_username
> #     password: notary_signer_db_password
> #     ssl_mode: disable
> #   notary_server:
> #     host: notary_server_db_host
> #     port: notary_server_db_port
> #     db_name: notary_server_db_name
> #     username: notary_server_db_username
> #     password: notary_server_db_password
> #     ssl_mode: disable
161,175c161,175
< external_redis:
<   # support redis, redis+sentinel
<   # host for redis: <host_redis>:<port_redis>
<   # host for redis+sentinel:
<   #  <host_sentinel1>:<port_sentinel1>,<host_sentinel2>:<port_sentinel2>,<host_sentinel3>:<port_sentinel3>
<   host: 192.168.10.10:6379
<   password:
<   # sentinel_master_set must be set to support redis+sentinel
<   #sentinel_master_set:
<   # db_index 0 is for core, it's unchangeable
<   registry_db_index: 1
<   jobservice_db_index: 2
<   chartmuseum_db_index: 3
<   trivy_db_index: 5
<   idle_timeout_seconds: 30
---
> # external_redis:
> #   # support redis, redis+sentinel
> #   # host for redis: <host_redis>:<port_redis>
> #   # host for redis+sentinel:
> #   #  <host_sentinel1>:<port_sentinel1>,<host_sentinel2>:<port_sentinel2>,<host_sentinel3>:<port_sentinel3>
> #   host: redis:6379
> #   password:
> #   # sentinel_master_set must be set to support redis+sentinel
> #   #sentinel_master_set:
> #   # db_index 0 is for core, it's unchangeable
> #   registry_db_index: 1
> #   jobservice_db_index: 2
> #   chartmuseum_db_index: 3
> #   trivy_db_index: 5
> #   idle_timeout_seconds: 30

# 部署第一个节点 harbor
$ cd /opt/harbor

# harbor开启helm charts 和 镜像漏洞扫描
$ ./prepare --with-notary --with-trivy --with-chartmuseum

# 安装
$ ./install.sh --with-notary --with-trivy --with-chartmuseum

# 查看
$ docker-compose ps

# 拷贝配置到 harbor2 机器上
$ scp -r /opt/harbor 192.168.10.11:/opt/

在 harbor2 机器上操作

# 部署第二个节点 harbor
$ cd /opt/harbor

# harbor开启helm charts 和 镜像漏洞扫描
$ ./prepare --with-notary --with-trivy --with-chartmuseum

# 安装
$ ./install.sh --with-notary --with-trivy --with-chartmuseum

# 查看
$ docker-compose ps

6、配置阿里云SLB

不具体介绍SLB配置方法，具体配置方法参考下面阿里云SLB配置文档，配置 443端口，使用 TCP 协议，后端映射到两台 harbor1 和 harbor2 443端口上。

SLB配置方法请参考阿里云文档 https://help.aliyun.com/document_detail/205495.html?spm=a2c4g.11174283.6.666.f9aa1192jngFKC

聊聊Harbor架构

2021-05-09T04:59:44.000Z

Harbor 简介

Harbor 是一个用于存储和分发Docker镜像的企业级Registry服务器。

作为一个企业级私有 Registry 服务器，Harbor 提供了更好的性能和安全。提升用户使用 Registry 构建和运行环境传输镜像的效率。Harbor 支持安装在多个 Registry 节点的镜像资源复制，镜像全部保存在私有 Registry 中，确保数据和知识产权在公司内部网络中管控。另外，Harbor 也提供了高级的安全特性，诸如用户管理，访问控制和活动审计等。

基于角色的访问控制：用户与 Docker 镜像仓库通过“项目”进行组织管理，一个用户可以对多个镜像仓库在同一命名空间（project）里有不同的权限。
镜像复制：镜像可以在多个 Registry 实例中复制（同步）。尤其适合于负载均衡，高可用，混合云和多云的场景。
图形化用户界面：用户可以通过浏览器来浏览，检索当前 Docker 镜像仓库，管理项目和命名空间。
AD/LDAP 支持：Harbor 可以集成企业内部已有的 AD/LDAP，用于鉴权认证管理。
审计管理：所有针对镜像仓库的操作都可以被记录追溯，用于审计管理。
国际化：已拥有英文、中文、德文、日文和俄文的本地化版本。更多的语言将会添加进来。
RESTful API：RESTful API 提供给管理员对于 Harbor 更多的操控, 使得与其它管理软件集成变得更容易。
部署简单：提供在线和离线两种安装工具，也可以安装到 vSphere 平台(OVA 方式)虚拟设备。

Harbor 架构

1、主从同步架构

Harbor 官方默认提供主从复制的方案来解决镜像同步问题，通过复制的方式，可以实时将测试环境harbor仓库的镜像同步到生产环境harbor，类似于如下流程：

在实际生产运维的中，往往需要把镜像发布到几十或上百台集群节点上。这时，单个Registry已经无法满足大量节点的下载需求，因此要配置多个Registry实例做负载均衡。手工维护多个Registry实例上的镜像，将是十分繁琐的事情。Harbor可以支持一主多从的镜像发布模式，可以解决大规模镜像发布的难题：

只要往一台Harbor上发布，镜像就会像“仙女散花”般地同步到多个Registry中，高效可靠。

如果是地域分布较广的集群，还可以采用层次型发布方式，比如从集团总部机房同步到分公司1机房，再从分公司1机房同步到分公司2机房：

然而单靠主从同步，仍然解决不了harbor主节点的单点问题。继续看下面Harbor架构。

2、双主复制说明

双主复制其实就是复用主从同步实现两个harbor节点之间的双向同步，来保证数据的一致性，然后在两台harbor前端顶一个负载均衡器将进来的请求分流到不同的实例中去，只要有一个实例中有了新的镜像，就是自动的同步复制到另外的的实例中去，这样实现了负载均衡，也避免了单点故障，在一定程度上实现了Harbor的高可用性：

这个方案有一个问题就是有可能两个Harbor实例中的数据不一致。假设如果一个实例A挂掉了，这个时候有新的镜像进来，那么新的镜像就会在另外一个实例B中，后面即使恢复了挂掉的A实例，Harbor实例B也不会自动去同步镜像，这样只能手动的先关掉Harbor实例B的复制策略，然后再开启复制策略，才能让实例B数据同步，让两个实例的数据一致。

另外，这里还需要多吐槽一句：在实际生产使用中，主从复制十分的不靠谱！所以这里推荐使用下面要说的这种架构方案。

3、多实例共享后端存储

共享后端存储算是一种比较标准的方案，就是多个Harbor实例共享同一个后端存储，任何一个实例持久化到存储的镜像，都可被其他实例中读取。通过前置LB进来的请求，可以分流到不同的实例中去处理，这样就实现了负载均衡，也避免了单点故障。

如果最终生产环境集群中服务器较多，依赖做完LB的Harbor也无法完全达到需求时，可以使用如下架构，部署下级Harbor节点从主节点同步镜像，然后再分发给生产服务器。

这个方案在实际生产环境中部署需要考虑三个问题：

1、共享存储的选取，Harbor的后端存储目前支持AWS S3、Openstack Swift, Ceph等，在下节文章在讲解如何部署这种高可用架构，后端存储使用阿里云极速性NAS。
2、Session在不同的实例上共享，这个现在其实已经不是问题了，在最新的harbor中，默认session会存放在redis中，只需要将redis独立出来即可。可以通过redis sentinel或者redis cluster等方式来保证redis的可用性。不过单台Redis也可以，只是Redis没有高可用。
3、Harbor多实例数据库问题，这个也只需要将harbor中的数据库拆出来独立部署即可。让多实例共用一个外部数据库，数据库的高可用也可以通过数据库的高可用方案保证。

小结

上文简单介绍 Harbor 不同的架构，下文再介绍 多实例共享后端存储 架构如何部署？使用阿里云极速性NAS作为后端存储。敬请期待。。。

参考链接

http://www.yunweipai.com/39320.html

K8S Cluster Autoscaler 集群自动伸缩

2021-04-21T06:00:23.000Z

什么是 cluster-autoscaler

Cluster Autoscaler （CA）是一个独立程序，是用来弹性伸缩kubernetes集群的。在使用kubernetes集群经常问到的一个问题是，应该保持多大的节点规模来满足应用需求呢？ cluster-autoscaler 出现解决了这个问题，它可以自动根据部署应用所请求资源量来动态的伸缩集群。

项目地址：https://github.com/kubernetes/autoscaler

Cluster Autoscaler 什么时候伸缩集群？

在以下情况下，集群自动扩容或者缩放：

扩容：由于资源不足，某些Pod无法在任何当前节点上进行调度
缩容: Node节点资源利用率较低时，且此node节点上存在的pod都能被重新调度到其他node节点上运行

什么时候集群节点不会被 CA 删除？

节点上有pod被 PodDisruptionBudget 控制器限制。
节点上有命名空间是 kube-system 的pods。
节点上的pod不是被控制器创建，例如不是被deployment, replica set, job, stateful set创建。
节点上有pod使用了本地存储
节点上pod驱逐后无处可去，即没有其他node能调度这个pod
节点有注解："cluster-autoscaler.kubernetes.io/scale-down-disabled": "true" （在CA 1.0.3或更高版本中受支持）

Horizontal Pod Autoscaler 如何与 Cluster Autoscaler 一起使用？

Horizontal Pod Autoscaler 会根据当前CPU负载更改部署或副本集的副本数。如果负载增加，则HPA将创建新的副本，集群中可能有足够的空间，也可能没有足够的空间。如果没有足够的资源，CA将尝试启动一些节点，以便HPA创建的Pod可以运行。如果负载减少，则HPA将停止某些副本。结果，某些节点可能变得利用率过低或完全为空，然后CA将终止这些不需要的节点。

如何防止节点被CA删除?

从CA 1.0开始，节点可以打上以下标签：

1	"cluster-autoscaler.kubernetes.io/scale-down-disabled": "true"

可以使用 kubectl 将其添加到节点（或从节点删除）：

1	$ kubectl annotate node <nodename> cluster-autoscaler.kubernetes.io/scale-down-disabled=true

运行Cluster Autoscaler 最佳实践？

不要直接修改属于自动伸缩节点组的节点。同一节点组中的所有节点应该具有相同的容量、标签和在其上运行的系统pod
Pod 声明 requests 资源限制
使用 PodDisruptionBudgets 可以防止突然删除Pod（如果需要）
再为节点池指定最小/最大设置之前，请检查您的云提供商的配额是否足够大
不要运行任何其他节点组自动缩放器（尤其是来自您的云提供商的自动缩放器）

Cluster Autoscaler 支持那些云厂商?

Cluster Autoscaler 部署和更多实践

请参考链接：https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md

参考链接：

十道Kubernetes面试题

2021-04-11T09:42:58.000Z

一、什么是Kubernetes集群中的minions？

1、它们是主节点的组件。
2、它们是集群的工作节点。[答案]
3、他们正在监控kubernetes中广泛使用的引擎。
4、他们是docker容器服务。

二、Kubernetes集群数据存储在以下哪个位置？

1、KUBE-API服务器
2、Kubelet
3、ETCD [答案]
4、以上都不是

三、哪个是Kubernetes控制器？

1、ReplicaSet
2、Deployment
3、Rolling Updates
4、ReplicaSet和Deployment [答案]

四、以下哪个是核心Kubernetes对象？

1、Pods
2、Services
3、Volumes
4、以上所有[答案]

五、Kubernetes Network代理在哪个节点上运行？

1、Master Node
2、Worker Node
3、所有节点[答案]
4、以上都不是

六、节点控制器的职责是什么？

1、将CIDR块分配给节点
2、维护节点列表
3、监视节点的运行状况
4、以上所有[答案]

七、Replication Controller的职责是什么？

1、使用单个命令更新或删除多个pod
2、有助于达到理想状态
3、如果现有Pod崩溃，则创建新Pod
4、以上所有[答案]

八、如何在没有选择器的情况下定义服务？

1、指定外部名称[答案]
2、指定具有IP地址和端口的端点
3、只需指定IP地址即可
4、指定标签和api版本

九、1.8版本的Kubernetes引入了什么？

1、Taints and Tolerations [答案]
2、Cluster level Logging
3、Secrets
4、Federated Clusters

十、Kubelet 调用的处理检查容器的IP地址是否打开的程序是？

1、HTTPGetAction
2、ExecAction
3、TCPSocketAction [答案]
4、以上都不是

作者：fiisio

原文链接：https://zhuanlan.zhihu.com/p/74560934

Redis如何删除数量过万以上Key而不影响业务

2021-03-21T03:33:30.000Z

需求

有时候因为 Redis Key 没有设置过期时间或者因为业务需求或者Redis内存不足或者修改Redis Key值等需求，并且这些Key是有规律的，可以通过正则表达式来匹配。

解决方法一

一般通过网上搜索，会告诉你使用下面方法，Redis 提供了一个简单暴力的指令 keys 用来列出所有满足特定正则字符串规则的 key。

1	$ redis-cli --raw keys "testkey-*" \| xargs redis-cli del

通过 Redis keys 来匹配你需要删除的key，再使用 xargs 把结果传给 redis-cli del ，这样看似完美，实则有很大风险。

上面命令使用非常简单，提供一个简单的正则字符串即可，但是有很明显的两个缺点。

没有 offset、limit 参数，一次性吐出所有满足条件的 key，万一实例中有几百 w 个 key 满足条件，当你看到满屏的字符串刷的没有尽头时，你就知道难受了。
keys 算法是遍历算法，复杂度是 O(n)，如果实例中有千万级以上的 key，这个指令就会导致 Redis 服务卡顿，所有读写 Redis 的其它的指令都会被延后甚至会超时报错，因为 Redis 6 版本以下都是单线程程序，顺序执行所有指令，其它指令必须等到当前的 keys 指令执行完了才可以继续，这样就会导致业务不可用，甚至造成redis宕机的风险。

注意：这种方法不推荐，建议生产环境屏蔽keys命令。那大家会问，有没有更好的方法来解决这个问题？答案是当然用，请接着看下文。

解决方法二

Redis从2.8版本开始支持 scan 命令，SCAN命令的基本用法如下：

1	SCAN cursor [MATCH pattern] [COUNT count]

cursor： 游标，SCAN命令是一个基于游标的迭代器，SCAN命令每次被调用之后，都会向用户返回一个新的游标，用户在下次迭代时需要使用这个新游标作为SCAN命令的游标参数，以此来延续之前的迭代过程，直到服务器向用户返回值为0的游标时，一次完整的遍历过程就结束了。
MATCH： 匹配规则，例如遍历以 testkey- 开头的所有key可以写成 testkey-*。
COUNT：COUNT选项的作用就是让用户告知迭代命令，在每次迭代中应该从数据集里返回多少元素，COUNT只是对增量式迭代命令的一种提示，并不代表真正返回的数量，例如你COUNT设置为2有可能会返回3个元素，但返回的元素数据会与COUNT设置的正相关，COUNT的默认值是10。

例子：

$ scan 0 MATCH testkey-*

1) "34"
2)  1) "testkey-2"
    2) "testkey-49"
    3) "testkey-20"
    4) "testkey-19"
    5) "testkey-93"
    6) "testkey-8"
    7) "testkey-34"
    8) "testkey-76"
    9) "testkey-13"
   10) "testkey-18"
   11) "testkey-10"

$ scan 34 MATCH testkey-* COUNT 1000

1) "0"
2)  1) "testkey-16"
    2) "testkey-19"
    3) "testkey-23"
    4) "testkey-21"
    5) "testkey-40"
    6) "testkey-22"
    7) "testkey-1"
    8) "testkey-11"
    9) "testkey-28"
   10) "testkey-3"
   11) "testkey-26"
   12) "testkey-4"
   13) "testkey-31"
   ...

scan 命令返回的是一个包含两个元素的数组，第一个数组元素是用于进行下一次迭代的新游标，而第二个数组元素则是一个数组，这个数组中包含了所有被迭代的元素。

上面这个例子的意思是扫描所有前缀为testkey-的key。第一次迭代使用0作为游标，表示开始一次新的迭代，同时使用了MATCH匹配前缀为testkey-的key，返回了游标值34以及遍历到的数据。第二次迭代使用的是第一次迭代时返回的游标，也即是命令回复第一个元素的值34，同时通过将COUNT选项的参数设置为1000，强制命令为本次迭代扫描更多元素。在第二次调用SCAN命令时，命令返回了游标0，这表示迭代已经结束，整个数据集已经被完整遍历过了。

Redis scan 命令就是基于游标的迭代器，意味着命令每次被调用都需要使用上一次这个调用返回的游标作为该次调用的游标参数，以此来延续之前的迭代过程。当SCAN命令的游标参数被设置为0时，服务器将开始一次新的迭代，而当redis服务器向用户返回值为0的游标时，表示迭代已结束，这是唯一迭代结束的判定方式，而不能通过返回结果集是否为空判断迭代结束。

上面的需求，最终可以使用下面命令来解决：

1	$ redis-cli --scan --pattern "testkey-*" \| xargs -L 1000 redis-cli del

xargs -L 指令表示xargs一次读取的行数，也就是每次删除key的数量，不要一次行读取太多数量key。

scan 与 keys 比较

scan 相比 keys 具备有以下特点:

复杂度虽然也是 O(n)，但是它是通过游标分步进行的，不会阻塞线程。
提供 limit 参数，可以控制每次返回结果的最大条数，limit 只是对增量式迭代命令的一种提示(hint)，返回的结果可多可少。
同 keys 一样，它也提供模式匹配功能。
服务器不需要为游标保存状态，游标的唯一状态就是 scan 返回给客户端的游标整数。
返回的结果可能会有重复，需要客户端去重复，这点非常重要。
遍历的过程中如果有数据修改，改动后的数据能不能遍历到是不确定的。
单次返回的结果是空的并不意味着遍历结束，而要看返回的游标值是否为零。

小结

Redis 类似 scan 命令还有很多，比如：

scan 指令是一系列指令，除了可以遍历所有的 key 之外，还可以对指定的容器集合进行遍历
zscan 遍历 zset 集合元素
hscan 遍历 hash 字典的元素
sscan 遍历 set 集合的元素

注意：SSCAN 命令、 HSCAN 命令和 ZSCAN 命令的第一个参数总是一个数据库键。而 SCAN 命令则不需要在第一个参数提供任何数据库键，因为它迭代的是当前数据库中的所有数据库键。

参考链接

Nginx 配置可视化管理

2021-03-14T05:15:58.000Z

Nginx 配置可视化UI展示

功能

Nginx 可视化管理
Nginx 配置管理
Nginx 性能监控

部署

快速部署

docker run --detach \
--publish 80:80 --publish 8889:8889 \
--name nginx_ui \
--restart always \
crazyleojay/nginx_ui:latest

数据持久化部署

配置文件路径：/usr/local/nginx/conf/nginx.conf

docker run --detach \
--publish 80:80 --publish 8889:8889 \
--name nginx_ui \
--restart always \
--volume /home/nginx.conf:/usr/local/nginx/conf/nginx.conf \
crazyleojay/nginx_ui:latest

项目地址：https://github.com/onlyGuo/nginx-gui

小结

该项目适用于测试环境或者本地开发环境不适合生产环境，提供给不懂Nginx配置人员使用，通过Web界面能简单的配置。

参考链接

https://github.com/onlyGuo/nginx-gui

Kubernetes(k8s)那些套路之日志收集

2021-03-04T13:49:19.000Z

关于容器日志

Docker的日志分为两类，一类是 Docker引擎日志；另一类是容器日志。引擎日志一般都交给了系统日志，不同的操作系统会放在不同的位置。本文主要介绍容器日志，容器日志可以理解是运行在容器内部的应用输出的日志，默认情况下，docker logs 显示当前运行的容器的日志信息，内容包含 STOUT(标准输出) 和 STDERR(标准错误输出)。日志都会以 json-file 的格式存储于 /var/lib/docker/containers/<容器id>/<容器id>-json.log ，不过这种方式并不适合放到生产环境中。

默认方式下容器日志并不会限制日志文件的大小，容器会一直写日志，导致磁盘爆满，影响系统应用。(docker log-driver 支持log文件的rotate)
Docker Daemon 收集容器的标准输出，当日志量过大时会导致Docker Daemon 成为日志收集的瓶颈，日志的收集速度受限。
日志文件量过大时，利用docker logs -f 查看时会直接将Docker Daemon阻塞住，造成docker ps等命令也不响应。

Docker提供了logging drivers配置，用户可以根据自己的需求去配置不同的log-driver，可参考官网 Configure logging drivers 。但是上述配置的日志收集也是通过Docker Daemon收集，收集日志的速度依然是瓶颈。

log-driver 日志收集速度

syslog 14.9 MB/s

json-file 37.9 MB/s

能不能找到不通过Docker Daemon收集日志直接将日志内容重定向到文件并自动 rotate的工具呢？答案是肯定的采用S6基底镜像。

S6-log 将 CMD 的标准输出重定向到/…/default/current，而不是发送到 Docker Daemon，这样就避免了 Docker Daemon 收集日志的性能瓶颈。本文就是采用S6基底镜像构建应用镜像形成统一日志收集方案。

S6：http://skarnet.org/software/s6/

关于k8s日志

k8s日志收集方案分成三个级别：

应用(Pod)级别
节点级别
集群级别

应用(Pod)级别

Pod级别的日志 , 默认是输出到标准输出和标志输入，实际上跟docker 容器的一致。使用 kubectl logs pod-name -n namespace 查看。

节点级别

Node级别的日志 , 通过配置容器的log-driver来进行管理 , 这种需要配合logrotare来进行 , 日志超过最大限制 , 自动进行rotate操作。

集群级别

集群级别的日志收集，有三种

节点代理方式，在node级别进行日志收集。一般使用DaemonSet部署在每个node中。这种方式优点是耗费资源少，因为只需部署在节点，且对应用无侵入。缺点是只适合容器内应用日志必须都是标准输出。

使用sidecar container作为容器日志代理，也就是在pod中跟随应用容器起一个日志处理容器，有两种形式：

一种是直接将应用容器的日志收集并输出到标准输出（叫做Streaming sidecar container），但需要注意的是，这时候，宿主机上实际上会存在两份相同的日志文件：一份是应用自己写入的；另一份则是 sidecar 的 stdout 和 stderr 对应的 JSON 文件。这对磁盘是很大的浪费 , 所以说，除非万不得已或者应用容器完全不可能被修改。

另一种是每一个pod中都起一个日志收集agent（比如logstash或fluebtd）也就是相当于把方案一里的 logging agent放在了pod里。但是这种方案资源消耗(cpu，内存)较大，并且日志不会输出到标准输出，kubectl logs 会看不到日志内容。

应用容器中直接将日志推到存储后端，这种方式就比较简单了，直接在应用里面将日志内容发送到日志收集服务后端。

日志架构

通过上文对k8s日志收集方案的介绍，要想设计一个统一的日志收集系统，可以采用节点代理方式收集每个节点上容器的日志，日志的整体架构如图所示。

解释如下：

1、所有应用容器都是基于s6基底镜像的，容器应用日志都会重定向到宿主机的某个目录文件下比如/data/logs/namespace/appname/podname/log/xxxx.log
2、log-agent 内部包含 filebeat ，logrotate 等工具，其中filebeat是作为日志文件收集的agent
3、通过filebeat将收集的日志发送到kafka
4、kafka在讲日志发送的es日志存储/kibana检索层
5、logstash 作为中间工具主要用来在es中创建index和消费kafka 的消息

整个流程很好理解，但是需要解决的是

1、用户部署的新应用，如何动态更新filebeat配置，
2、如何保证每个日志文件都被正常的rotate，
3、如果需要更多的功能则需要二次开发filebeat，使filebeat 支持更多的自定义配置。

付诸实践

解决上述问题，就需要开发一个log-agent应用以daemonset形式运行在k8s集群的每个节点上，应用内部包含filebeat，logrotate，和需要开发的功能组件。

第一个问题，如何动态更新filebeat配置，可以利用http://github.com/fsnotify/fsnotify 工具包监听日志目录变化create、delete事件，利用模板渲染的方法更新filebeat配置文件

第二个问题，利用http://github.com/robfig/cron 工具包创建cronJob，定期rotate日志文件，注意应用日志文件所属用户，如果不是root用户所属，可以在配置中设置切换用户

/var/log/xxxx/xxxxx.log {
      su www-data www-data
      missingok
      notifempty
      size 1G
      copytruncate
    }

第三个问题，关于二次开发filebeat，可以参考博文 https://www.jianshu.com/p/fe3ac68f4

总结

本文只是对k8s日志收集提供了一个简单的思路，关于日志收集可以根据公司的需求，因地制宜。

参考文献

1、kubernetes.io/docs/concepts/cluster-administration/logging/
2、https://support.rackspace.com/how-to/understanding-logrotate-utility/
3、https://github.com/elastic/beats/tree/master/filebeat
4、http://skarnet.org/software/s6/

作者：知道又忘了

原文出处：https://zhuanlan.zhihu.com/p/70662744

YP小站

ETCD存储满了如何处理?

一、前言

二、临时解决方案

三、最终解决方案

四、最佳实践

五、参考文档

业务日志告警如何做?

一、前言

二、日志格式

三、告警要求

四、如何根据日志告警？

ElastAlert 特性

ElastAlert 可用性

ElastAlert 部署

ElastAlert 告警监控展示

构建 elastalert 镜像

配置 ElastAlert 并启动

五、参考文档

详解Nginx proxy_pass 使用

前言

详解

第一种场景 后面url加 /

第二种场景 后面url没有 /

第三种场景 后面url添加其它路由，并且最后添加 /

第四种场景 后面url添加其它路由，但最后没有添加 /

Docker与Containerd使用区别

前言

Docker 和 Containerd 常用命令比较

容器日志和相关参数配置差异

CNI 网络

参考链接

docker exec 失败问题排查之旅

前言

问题描述

问题排查

定位组件

定位原因

runc梳理

Reference

阿里云ACK多个Service绑定单个SLB实践

阿里云ACK是什么

Service几种暴露方式

需求

多个Service绑定一个SLB多个端口用法

Service声明TCP协议

Service声明使用https协议

Service声明使用http协议

参考链接

K8S部署分布式调度任务Airflow

一、部署要求

二、生成Helm Charts配置

三、修改airflow配置

3.1 配置持续存储 StorageClass

3.2 配置 airflow Dags 存储仓库 gitSshKey

3.3 Docker 部署 PostgreSQL 12

3.4 修改 airflow_1.2.4_values.yaml 配置

四、部署 Airfolw

五、配置 Airflow Ingress Nginx 访问入口

六、参考链接

Ingress Nginx传递用户真实IP问题

背景

1. use-forwarded-headers

2. forwarded-for-header

3. compute-full-forwarded-for

举例说明

注意项

Kubectl 高亮输出

kubecolor 带有色彩输出

Kubecolor 如何运行？

Kubecolor 安装

Kubecolor 用法

参考链接

聊聊TPS、QPS、CPS概念和区别.md

TPS 概念

QPS 概念

CPS 概念

TPS 与 QPS 区别

QPS 计算公式

系统吞吐量

第一种场景后面url加 /

第二种场景后面url没有 /

第三种场景后面url添加其它路由，并且最后添加 /

第四种场景后面url添加其它路由，但最后没有添加 /

一背景

二解决方案

四测试

六反思

Horizontal Pod Autoscaler 如何与 Cluster Autoscaler 一起使用？

Cluster Autoscaler 部署和更多实践