标签归档:k8s

k3s k8s 快速部署轻量节点监控方案 beszel

在逛 Reddit 时看到 这篇帖子 发现 beszel 这个熟悉又陌生的名字。看了一下官网发现还支持 kubernetes 的部署,直接使用 daemonset 就可以在所有节点自动部署 agent ,虽然还需要手动在 hub 添加,但已经很方便,用了一下不错。

首页截图

节点详情页

作为轻量级的 k3s/k8s 集群监控方案确实不错,比 kube-prometheus-stack 这样的庞然大物轻便太多,解决轻量的监控和告警需求。

下面直接贴出 hubagentmanifests

hub

---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: beszel-zgus1-pvc
  namespace: beszel
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: local-zgus1
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: app
  namespace: beszel
  labels:
    app: beszel
spec:
  replicas: 1
  selector:
    matchLabels:
      app: beszel
  template:
    metadata:
      annotations: {}
      labels:
        app: beszel
    spec:
      #nodeSelector:
      #  kubernetes.io/hostname: zgocloud-us1
      containers:
        - name: app
          image: henrygd/beszel:0.11.1
          ports:
            - containerPort: 8090
              name: web
          env:
            - name: TZ
              value: "Asia/Shanghai"
          volumeMounts:
            - name: beszel-data
              mountPath: /beszel_data
      volumes:
        - name: beszel-data
          persistentVolumeClaim:
            claimName: beszel-zgus1-pvc
---
apiVersion: v1
kind: Service
metadata:
  name: beszel
  namespace: beszel
spec:
  selector:
    app: beszel
  ports:
    - name: web
      port: 8090
      targetPort: 8090
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: beszel-ingress
  namespace: beszel
  annotations:
    cert-manager.io/cluster-issuer: "cf-cluster-issuer"
spec:
  ingressClassName: nginx
  tls:
  - hosts:
      - <YOUR DOMAIN>
    secretName: <YOUR DOMAIN TLS SECRET NAME>            
  rules:
  - host: <YOUR DOMAIN>
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: beszel
            port:
              name: web

agent

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: agent
  namespace: beszel
spec:
  selector:
    matchLabels:
      app: agent
  template:
    metadata:
      labels:
        app: agent
    spec:
      hostNetwork: true
      containers:
        - env:
            - name: LISTEN
              value: '45876'
            - name: KEY
              value: 'YOUR-KEY-HERE'
          image: henrygd/beszel-agent:latest
          imagePullPolicy: Always
          name: beszel-agent
          ports:
            - containerPort: 45876
              hostPort: 45876
      restartPolicy: Always
      tolerations:
        - effect: NoSchedule
          key: node-role.kubernetes.io/master
          operator: Exists
        - effect: NoSchedule
          key: node-role.kubernetes.io/control-plane
          operator: Exists
  updateStrategy:
    rollingUpdate:
      maxSurge: 0
      maxUnavailable: 100%
    type: RollingUpdate

注意,agent 使用了hostNetwork 网络,实现对宿主机网络的监控并监听 45876 端口,需放通端口后在可以在 hub 加入。如果不使用这个模式,会收集不到网络数据,看到的带宽情况一直是 .

References

k3s-k8s 实现 DevOps 方案横向对比

目前在用 Keel,感觉良好。

主流方案对比

以下是几种可以在 K3s 中实现轻量级 DevOps 解决方案对比:

方案 资源占用 易用性 Web UI 集成能力 配置复杂度 特点
ArgoCD 中等 ★★★★☆ 优秀 原生支持 Git/镜像更新 中等 GitOps 专注,声明式部署
FluxCD ★★★☆☆ 基础(最新版改进) 原生支持 Git/镜像更新 中等 GitOps 专注,自动化程度高
Drone ★★★★☆ 优秀 需配置触发器 轻量级,无需 CRD
Jenkins X ★★☆☆☆ 良好 丰富 功能全面但较重
Tekton 中等 ★★★☆☆ 需安装Dashboard 高度可定制 中高 云原生管道
Keel 极低 ★★★★★ 简单 专注镜像更新 极低 超轻量,专注自动部署

方案详细分析

1. ArgoCD

优势:

  • 优秀的 Web UI,直观展示应用状态
  • GitOps 原生支持,可监控仓库变化
  • 支持镜像更新自动化(通过 Image Updater 插件)
  • 良好的 K8s 集成度,使用 CRD 扩展

劣势:

  • 资源占用相对较高
  • 初期配置有一定学习曲线

资源需求: 至少 1-2 核 CPU,2GB 内存

2. FluxCD

优势:

  • 极轻量级设计,资源消耗小
  • 完全自动化的 GitOps 流程
  • 内置镜像更新自动化
  • 无需持续手动干预

劣势:

  • UI 相对简单(Flux v2 已有改进)
  • 学习曲线略陡

资源需求: 约 0.5 核 CPU,512MB 内存

3. Drone

优势:

  • 极轻量级 CI/CD 系统
  • 简单直观的 Web UI
  • 配置简单(YAML 文件)
  • 与 GitHub 集成良好

劣势:

  • 需要额外配置触发器实现自动化部署
  • 功能不如大型 CI/CD 平台丰富

资源需求: 约 0.5 核 CPU,512MB 内存

4. Keel

优势:

  • 超轻量级,专注于一件事:自动化部署更新后的镜像
  • 配置极其简单(注解或简单 CRD)
  • 支持多种触发方式:Webhook、轮询或 Pub/Sub
  • 几乎零配置即可工作

劣势:

  • 功能单一,仅专注于部署更新
  • UI 非常基础
  • 社区相对小众

资源需求: 约 0.2 核 CPU,256MB 内存

推荐方案

基于需求(轻量级、简单配置、Web UI、自动化部署):

主推方案: Keel + GitHub Actions

  1. GitHub Actions 负责 CI 部分(代码提交触发构建并推送到 Docker Hub)
  2. Keel 负责 CD 部分(检测到新镜像自动更新部署)

优势:

  • 最轻量级组合,资源占用最小
  • 配置极其简单,只需在部署中添加几个注解
  • GitHub Actions 原生集成 GitHub
  • 完全满足您的自动化流程需求

配置示例:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: your-app
  annotations:
    keel.sh/policy: force  # 强制更新策略
    keel.sh/trigger: poll  # 轮询 Docker Registry
    keel.sh/pollSchedule: "@every 2m"  # 每2分钟检查
spec:
  template:
    spec:
      containers:
        - name: your-container
          image: your-dockerhub/your-image:latest

替代方案: ArgoCD

如果您需要更强大的 UI 和更完整的 GitOps 工作流,推荐使用 ArgoCD,虽然资源消耗稍高,但提供了更全面的功能和更好的可视化体验。

结论

Keel + GitHub Actions 是最轻量且直接的解决方案,几乎零配置即可工作。如果需要更全面的 GitOps 体验和更好的可视化,可以考虑 ArgoCD,它虽然资源消耗稍高,但提供了更完善的功能。

k8s 配置访问私有镜像仓库

harbor 私有仓库、aliyun acr 等同理。

创建凭据

以创建 docker-registry-creds 为例,按需调整名称

kubectl create secret docker-registry docker-registry-creds --docker-server="<私有仓库域名>"
--docker-email=test@test.com 
--docker-username='******' 
--docker-password='******'

# 参数解释
# --docker-server 是私有docker仓库全限定域名(FQDN)
# --docker-username 是机器人账户的username,需要用单引号引起来。
# --docker-password 是机器人账户生成的token,需要用单引号引起来。
# --docker-email 是docker邮箱(非必须)。
# 这样就成功地将集群中的docker凭据设置为名为docker-registry-creds的secret。

使用凭据

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  containers:
  - name: nginx
    image: <私有仓库域名>/kubernetes/nginx:latest 
    ports:
    - containerPort: 80
  imagePullSecrets:
    - name: docker-registry-creds

References

k8s csi-driver-nfs的一个坑

TL;DR

发现 k8s csi 组的社区项目 csi-driver-nfs v4.10v4.11 至少这两个版本存在删除 pv 时会连带将整个根删除的问题。

声明 StorageClass 时虽然支持 subDir ,类似这样:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: nfs-aliyun-gz
provisioner: nfs.csi.k8s.io
parameters:
  share: "/csi"
  server: "28364f4a1fa-eok75.cn-guangzhou.nas.aliyuncs.com"
  #server: "172.26.12.20"
  #subDir: "${pvc.metadata.namespace}/${pvc.metadata.name}"
reclaimPolicy: Delete
#volumeBindingMode: WaitForFirstConsumer
volumeBindingMode: Immediate
allowVolumeExpansion: true
mountOptions:
#  - nolock,tcp,noresvport
  - vers=3,nolock,proto=tcp,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport

但如果类似这样使用 subDir 声明路径,同命名空间下的其他 pvc 删除,会导致整个 subDir 根目录都被删除。目前官方 pr 已经修复,但实测还是有问题,有空再研究一下代码,不知道是不是刻意为之。

回溯 issuer 历史发现是有人提了 bug 发现目录下出现很多空目录,认为需要删除,修复者修复这一问题时错误的将整个根删除。为了规避这一问题,暂时回退到更早的 4.9 版本 csi

helm upgrade --install csi-driver-nfs csi-driver-nfs/csi-driver-nfs --namespace kube-system --version v4.  
9.0 -f values.yaml

升级版本要谨慎,新装版本要充分测试,特别是这种涉及数据安全的!

最后发现 sig 组还有一个 nfs-subdir-external-provisioner 可以看一下。

References

k3s 容器 mirror 配置方法

TL; DR

root@tencent-sh1:~# cat /etc/rancher/k3s/registries.yaml 
mirrors:
  "docker.io":
    endpoint:
      - "https://harbor.xxx.me"
    rewrite:
      "^(.*)": "mirror-dockerhub/$1"
  "registry.k8s.io":
    endpoint:
      - "https://harbor.xxx.me"
    rewrite:
      "^(.*)": "mirror-registry-k8s-io/$1"
  "ghcr.io":
    endpoint:
      - "https://harbor.xxx.me"
    rewrite:
      "^(.*)": "mirror-registry-ghcr-io/$1"
  "quay.io":
    endpoint:
      - "https://harbor.xxx.me"
    rewrite:
      "^(.*)": "mirror-registry-quay-io/$1"

以上是我的配置,在 harbor 中镜像以上镜像源,之后这样 配置即可。

如果没有路径,比如使用 registry 镜像,忽略 rewrite 部分即可。

References

wordpress 使用 k8s 部署并使用 nginx ingress 代理无限 302 到 ssl 问题解决

发现容器化之后,wp 网站打开一直尝试 302 到 https 的页面,即使我当前已经是 https 了,经过排查是由于代理提供了 ssl 但 wordpress 不知道,默认会再重定向一次,出现无限 302 。

TL; DR

解决方法很简单,只需在 wp 配置文件 /wp-config.php 中增加这几行即可解决:

define( 'FORCE_SSL_ADMIN', true );
// in some setups HTTP_X_FORWARDED_PROTO might contain 
// a comma-separated list e.g. http,https
// so check for https existence
if( strpos( $_SERVER['HTTP_X_FORWARDED_PROTO'], 'https') !== false )
    $_SERVER['HTTPS'] = 'on';

方法来源于官网.

References