misterli's Blog.

misterli's Blog.

欢迎您访问misterli's Blog.

prometheus监控集群外机器的node-exporter的两种方式

背景

使用kube-prometheus项目在kubernetes集群里部署了prometheus监控,中间件的独立部署在集群外的服务器上的,本来是对中间件有监控,但是这批服务器比较拉,之前经历过五台机器同时发生重启的情况,这里还是要监控mysql/redis/es的的机器。

安装

https://github.com/prometheus/node_exporter/releases下载安装包,这里我选择下载1.8.2

1
2
3
4
cd /opt
wget https://github.com/prometheus/node_exporter/releases/download/v1.8.2/node_exporter-1.8.2.linux-amd64.tar.gz
tar xf node_exporter-1.8.2.linux-amd64.tar.gz
mv node_exporter-1.8.2.linux-amd64 node_exporter

创建一个用户用于启动node_exporter,提升安全性

1
2
3
groupadd prometheus 
useradd -g prometheus -s /sbin/nologin prometheus
chown -R prometheus:prometheus /opt/node_exporter/

创建一个systemd文件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
cat   /usr/lib/systemd/system/node_exporter.service

[Unit]
Description=node_exporter
Documentation=https://prometheus.io/
After=network.target

[Service]
Type=simple
User=prometheus
Group=prometheus
ExecStart=/opt/node_exporter/node_exporter
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure

[Install]
WantedBy=multi-user.target

启动

Cloudflare 代理dockerhub的两种方式

前提条件:

1、一个cloudflare账号

2、一个域名

使用 Cloudflare Workers 来部署我们的镜像加速服务,这里我的账号是使用的免费计划,每天100,000次请求,个人用足够了

首先安装 wrangler 命令行工具 https://developers.cloudflare.com/workers/cli-wrangler/install-update

安装后执行 wrangler login 会自动跳转到浏览器进行身份验证,我们在页面中选择allow

image-20240611171124989

image-20240611160122394

方式一

安装

分析redis 大key

使用rdbtools工具

redis-rdb-tools 是一个 python 的解析 rdb 文件的工具,在分析内存的时候,我们主要用它生成内存快照。

主要有以下三个功能:

  • 生成内存快照
  • 转储成 json 格式
  • 使用标准的 diff 工具比较两个 dump 文件

安装

1
2
3
pip install rdbtools python-lzf
# 在安装python-lzf之前,要安装python-devel依赖包,否则安装会失败
yum install python-devel

rdbtools工具包括了3个可执行文件:

rdb – 解析整个rdb文件
redis-memory-for-key – 解析server里的单个key
redis-profiler –解析rdb文件成html格式

命令help

1、rdb –help:解析整个rdb文件

docker/buildkit 构建问题

环境背景: ack集群,gitlab-runner 运行在k8s中

早上一来同事告诉我好几个项目CI构建都在构建镜像阶段失败

image-20220818113710747查看日志如下:

1
2
3
4
5
6
$ buildctl-daemonless.sh  --debug  build --frontend=dockerfile.v0 --local context=. --local dockerfile=. --output type=image,name=${IMAGE_TAG},push=true --opt    build-arg:BUILD_DIR=${BUILD_ARGS}
could not connect to unix:///run/user/1000/buildkit/buildkitd.sock after 10 trials
========== log ==========
time="2022-08-18T02:24:19Z" level=warning msg="/proc/sys/user/max_user_namespaces needs to be set to non-zero."
[rootlesskit:parent] error: failed to start the child: fork/exec /proc/self/exe: no space left on device
sh: can't kill pid 23: No such process

内心有点懵逼,我最近也没动过CI的流程,查看了一下docker的文档,发现此错误会出现在/proc/sys/user/max_user_namespaces太小时,想看可能是凌晨时候这个k8s集群增加了一台服务器,流水线的这个pod被调度到新的机器上,查看一下新机器的max_user_namespaces,比较偷懒,没有登陆服务器,直接在阿里云控制台远程执行,如下:

image-20220818112255795

image-20220818112304261

max_user_namespaces值果真是0,使用如下命令修改:

1
2
sudo  echo "user.max_user_namespaces=28633" >> /etc/sysctl.conf
sudo sysctl --system

再次构建命令发现如下报错:

K8s环境清理节点上旧的镜像

当我们使用kubernetes集群时,节点上会积累很多不再使用的镜像,虽然kubelet设置的有镜像回收的阈值,但是默认阈值为85%,日常使用中旧的镜像还是会占用很多磁盘空间,可以根据自己容器运行时来使用如下方式清理

docker

1
2
docker image  prune  -f
docker image prune -a -f

image-20211119133016666

Containers

首先下载crictl

1
2
3
4
5
6
#!/bin/bash

wget https://github.91chi.fun//https://github.com//kubernetes-sigs/cri-tools/releases/download/v1.22.0/crictl-v1.22.0-linux-amd64.tar.gz
tar xf crictl-v1.22.0-linux-amd64.tar.gz
\mv -f crictl /usr/bin/
/usr/bin/crictl rmi --prune

image-20211119111119894

如果需要写到cron作为定时任务运行则需要

1
crictl --runtime-endpoint unix:///run/containerd/containerd.sock  rmi --prune 
记一次kuboard故障—Etcd空间爆满

kuboard是一个给研发使用的k8s dashboard ,研发告诉说我打不开了,打开页面发现页面500 无法访问(此处无图,忘了截图保存了)

首先查看了一个pod状态都正常

1
2
3
4
5
6
7
[root@dev-tools ~]# kubectl -n kuboard  get pod
NAME READY STATUS RESTARTS AGE
kuboard-etcd-0 1/1 Running 0 26d
kuboard-etcd-1 1/1 Running 0 162d
kuboard-etcd-2 1/1 Running 0 155d
kuboard-v3-57b6fbcf4f-dglkk 1/1 Running 0 153d

想偷个懒,先祭出祖传重启大法看看能不能打开

1
2
kubectl -n kuboard  rollout  restart deployment  kuboard-v3
kubectl -n kuboard rollout restart statefulset kuboard-etcd

重启后还是打不开,于是开始查看日志

kuboard日志

1
2
3
4
{"level":"warn","ts":"2023-04-12T14:38:31.018+0800","caller":"clientv3/retry_interceptor.go:61","msg":"retrying of unary invoker failed","target":"endpoint://client-5cd98b97-dba1-498e-ae6f-4bcf1408145f/kuboard-etcd-0.kuboard-etcd:2379","attempt":0,"error":"rpc error: code = ResourceExhausted desc = etcdserver: mvcc: database space exceeded"}
time="2023-04-12T06:38:31Z" level=error msg="Failed to create authorization request: etcdserver: mvcc: database space exceeded"
[GIN] 2023/04/12 - 14:38:31 | 500 | 7.722147ms | 106.15.137.195 | GET "/sso/auth?access_type=offline&client_id=kuboard-sso&redirect_uri=%2Fcallback&response_type=code&scope=openid+profile+email+groups&state=%2Fkuboard%2Fcluster&connector_id=gitlab"
{"level":"warn","ts":"2023-04-12T14:38:32.750+0800","caller":"clientv3/retry_interceptor.go:61","msg":"retrying of unary invoker failed","target":"endpoint://client-5cd98b97-dba1-498e-ae6f-4bcf1408145f/kuboard-etcd-0.kuboard-etcd:2379","attempt":0,"error":"rpc error: code = ResourceExhausted desc = etcdserver: mvcc: database space exceeded"}

etcd日志

1
2
3
4
2023-04-12 06:38:05.763042 W | etcdserver: failed to apply request "header:<ID:12031796812563778311 > txn:<compare:<target:CREATE key:\"kuboard-sso-namespace/auth_req/rmq7qrteaen47y5kdvf3y32w5\" create_revision:0 > success:<request_put:<key:\"kuboard-sso-namespace/auth_req/rmq7qrteaen47y5kdvf3y32w5\" value_size:427 >> failure:<>>" with response "" took (481ns) to execute, err is etcdserver: no space
2023-04-12 06:38:05.763071 W | etcdserver: failed to apply request "header:<ID:12031796812563778314 > txn:<compare:<target:CREATE key:\"kuboard-sso-namespace/auth_req/ym7vdka6tote5euge43on5lj4\" create_revision:0 > success:<request_put:<key:\"kuboard-sso-namespace/auth_req/ym7vdka6tote5euge43on5lj4\" value_size:411 >> failure:<>>" with response "" took (320ns) to execute, err is etcdserver: no space
2023-04-12 06:38:05.763086 W | etcdserver: failed to apply request "header:<ID:12031796812563778315 > txn:<compare:<target:CREATE key:\"kuboard-sso-namespace/auth_req/b2zt4l2qlu5kdfgp62cvdpsby\" create_revision:0 > success:<request_put:<key:\"kuboard-sso-namespace/auth_req/b2zt4l2qlu5kdfgp62cvdpsby\" value_size:411 >> failure:<>>" with response "" took (360ns) to execute, err is etcdserver: no space
2023-04-12 06:38:05.763102 W | etcdserver: failed to apply request "header:<ID:12031796812563778316 > txn:<compare:<target:CREATE key:\"kuboard-sso-namespace/auth_req/iycfih7p4u45ckbhcjydx4nq2\" create_revision:0 > success:<request_put:<key:\"kuboard-sso-namespace/auth_req/iycfih7p4u45ckbhcjydx4nq2\" value_size:372 >> failure:<>>" with response "" took (270ns) to execute, err is etcdserver: no space
Umami 安装并升级到v2.x

Umami 是一种开源、注重隐私的 Google Analytics 替代品。Umami 为您提供了一个强大的网络分析解决方案,不会侵犯您用户的隐私。此外,当您自行托管 Umami 时,您可以完全控制您的数据。

目前看好像直接安装v2.x无法成功,这里采用先安装v1.x然后升级至v2.x。

当前latest版本为v2.2.0

安装v1.x

要求

  • 具有 Node.js 版本 12 或更高版本的服务器
  • 一个数据库。Umami 支持MySQLPostgresql数据库。

首先安装1.40.0版本的umami

1
2
3
4
git clone -b v1.40.0 https://github.com/umami-software/umami.git
cd umami
这里我们可以把docker-compose.yml文件中的postgresql镜像版本给为 postgres:15-alpine
docker-compose up -d

启动后访问127.0.0.1:3000查看一下页面是否正常,账号admin 密码umami

image-20230505134745399

SSO之使用Pomerium保护您的网站

简介

Pomerium 是一种身份感知代理,可实现对内部应用程序的安全访问。Pomerium 提供了一个标准化的接口来为应用程序添加访问控制,无论应用程序本身是否具有授权或身份验证。

Pomerium 可用于:

  • 为内部应用程序提供单点登录网关。

  • 基于上下文身份设备身份实施动态访问策略

  • 聚合访问日志和遥测数据。

  • 为自定义、本地和托管应用程序和服务添加统一访问和身份

  • 为基于服务的授权系统执行委托的用户授权:

    Istio

    谷歌云

  • 作为VPN 替代品

架构

Pomerium 位于最终用户和需要强身份验证的服务之间。在通过您的身份提供商 (IdP) 验证身份后,Pomerium 使用可配置的策略来决定如何路由用户的请求以及他们是否有权访问该服务。

pomerium 架构图

Pomerium 由 4 个逻辑组件组成:

  • 代理服务
    • 所有用户流量都流经代理
    • 使用身份验证服务验证所有请求
    • 将用户定向到身份验证服务以建立会话身份
    • 处理策略以确定外部/内部路由映射
  • 认证服务
    • 根据需要处理您的 IdP 的身份验证流程
    • 在初始身份验证后处理身份验证
    • 建立用户会话 cookie
    • 将用户 OIDC 令牌存储在数据代理服务中
  • 授权服务
    • 处理策略以确定每个服务的权限
    • 处理所有用户会话的授权检查
    • 指示代理服务根据需要启动身份验证流程
    • 为上游服务提供额外的安全相关标头以供使用
  • 数据代理服务
    • 检索与身份提供者相关的数据,例如组成员身份
    • 存储和刷新身份提供者访问和刷新令牌
    • 向授权服务提供流式权威会话和身份数据
    • 将会话和身份数据存储在持久存储中

在生产部署中,建议您单独部署每个组件。这允许您限制外部攻击面,以及独立扩展和管理服务。

使用sloop 监控kubernetes event

简介

Sloop 可以监控 Kubernetes event ,记录事件和资源状态变化的历史,并提供可视化来帮助调试过去的事件。

主要特点:

  1. 允许查找和检查不再存在的资源(例如:发现之前部署中的 pod )。
  2. 提供时间线显示,显示deployment 、ReplicaSet 和 StatefulSet 更新中相关资源的退出。
  3. 帮助调试瞬态和间歇性错误。
  4. 可以查看 Kubernetes 应用程序中随时间的变化。
  5. 是一个独立的服务,不依赖于分布式存储。

架构

image-20220509180133422

安装及使用

docker 安装

我们可以使用官方提供的镜像安装,sloop数据文件保存在容器的/data目录下

1
docker run  -it -p 8080:8080 -v ~/.kube/config:/kube/config  -v /data:/data -e KUBECONFIG=/kube/config sloopimage/sloop
阿里云ACK集群 Ingress-nginx配置日志输出request body和request headers信息

背景

我们使用的是阿里云ack pro 托管版集群,创建集群时默认开启采集ingress-nginx的日志,开发和产品那边提了一个需求,排查问题的时候需要查看请求的bodyrequest headers中的部分自定义字段用于排错, 查看了一下默认的nginx-ingress的日志输出格式,发现不包含这些信息,所以我们就要修改日志输出的内容,并且还要保证日志采集展示效果正常。

修改日志输出格式

Ingress Controller访问日志格式可以在ConfigMap中看到(默认ConfigMap为kube-system命名空间下的nginx-configuration)。

ACK Ingress Controller默认的日志格式为:

1
2
3
4
$remote_addr - [$remote_addr] - $remote_user [$time_local]
"$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" $request_length
$request_time [$proxy_upstream_name] $upstream_addr $upstream_response_length
$upstream_response_time $upstream_status $req_id $host [$proxy_alternative_upstream_name]

注意:改动日志格式后,SLS的日志收集规则也需要做相应改动,否则无法在SLS日志控制台看到正确日志信息。

我们先看一下未修改前日志输出的内容:

1
106.15.137.195 - [106.15.137.195] - - [01/May/2022:22:35:13 +0800] "POST /xxl-job-admin/api/registry HTTP/1.1" 200 49 "-" "Java/1.8.0_191" 518 0.004 [harmay-digital-digital-xxl-job-8080] 192.168.94.49:8080 49 0.002 200 3ed90ece4e7fcfb4a555e386a513a143 dev-xxl-job.harmay.com [] 00-e4c221406c5b217f13ae117af5509a48-ecbeec29adbc21ab-01

此时我们采集的日志如下:

avatar
misterli
大风起兮云飞扬
FRIENDS
baidu google