一、前言

当运行 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

一、前言

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

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

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

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

前言

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

前言

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异常日志：

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"

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

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

阿里云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管理的负载均衡器。

一、部署要求

Apache Airflow 已通过以下测试：

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

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

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

背景

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

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

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

kubecolor 带有色彩输出

• 获取 kubernetes node 节点信息

• 显示 kubernetes pods 详细信息

TPS 概念

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

QPS 概念

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

CPS 概念

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