作者归档:songtianlun

Linux 进程绑定NUMA节点或CPU核心

对于CPU和NUMA架构的介绍本文不再做叙述,感兴趣的可自行查看:Linux–CPU简述,Linux–内存管理浅谈。

进程绑定NUMA节点或cpu核心的意义

NUMA 架构将内存和cpu分散在不同的 NUMA 节点上,每个节点都有自己的本地内存和cpu处理器,将进程绑定到特定的 NUMA 节点或cpu上,可以让进程直接访问本地内存和CPU,减少访问远程节点开销,提高访问速度,从而提高程序性能。

注:不可多进程绑定同一个节点或cpu,这样反而会使该节点产生资源竞争,降低性能。

查看NUMA架构的信息

[root@test ~]# yum -y install numactl
[root@test ~]# numactl -H
available: 2 nodes (0-1)    #有两个NUMA节点,编号0,1
node 0 cpus: 0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30    #节点0包含的cpu核心编号
node 0 size: 65442 MB       #节点0共有65442MB的内存容量
node 0 free: 5901 MB        #节点0当前有5091MB的内存空闲
node 1 cpus: 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31
node 1 size: 65536 MB
node 1 free: 5133 MB
node distances:            #不同node之间发访问距离(跳数),如[0,0] 表示node 0的本地内存访问距离为10。跳数(hops):表示从一个节点到达另一个节点所需的内存访问步骤数,并不是一个精确的时间或距离单位,而是一种相对指标。
node   0   1 
  0:  10  21 
  1:  21  10 
[root@test ~]#
[root@test ~]# lscpu
...
#系统的NUMA节点和 CPU 核心编号的映射
NUMA node0 CPU(s):     0,2,4,6,8,10,12,14,16,18,20,22,24,26,28,30
NUMA node1 CPU(s):     1,3,5,7,9,11,13,15,17,19,21,23,25,27,29,31
...
[root@test ~]#
[root@test ~]# yum -y install hwloc
[root@test ~]# lstopo-no-graphics 
Machine (128GB total)       #总共有128GB内存
  NUMANode L#0 (P#0 64GB)    #节点 L#0 有64GB内存
    Package L#0 + L3 L#0 (20MB)
      L2 L#0 (256KB) + L1d L#0 (32KB) + L1i L#0 (32KB) + Core L#0
        PU L#0 (P#0)
        PU L#1 (P#16)
      L2 L#1 (256KB) + L1d L#1 (32KB) + L1i L#1 (32KB) + Core L#1
        PU L#2 (P#2)
        PU L#3 (P#18)
      L2 L#2 (256KB) + L1d L#2 (32KB) + L1i L#2 (32KB) + Core L#2
        PU L#4 (P#4)
        PU L#5 (P#20)
      L2 L#3 (256KB) + L1d L#3 (32KB) + L1i L#3 (32KB) + Core L#3
        PU L#6 (P#6)
        PU L#7 (P#22)
      L2 L#4 (256KB) + L1d L#4 (32KB) + L1i L#4 (32KB) + Core L#4
        PU L#8 (P#8)
        PU L#9 (P#24)
      L2 L#5 (256KB) + L1d L#5 (32KB) + L1i L#5 (32KB) + Core L#5
        PU L#10 (P#10)
        PU L#11 (P#26)
      L2 L#6 (256KB) + L1d L#6 (32KB) + L1i L#6 (32KB) + Core L#6
        PU L#12 (P#12)
        PU L#13 (P#28)
      L2 L#7 (256KB) + L1d L#7 (32KB) + L1i L#7 (32KB) + Core L#7
        PU L#14 (P#14)
        PU L#15 (P#30)
    HostBridge L#0
      PCIBridge
        PCI 1000:005d
          Block L#0 "sda"
      PCIBridge
        2 x { PCI 8086:154d }
      PCIBridge
        4 x { PCI 8086:1521 }
      PCI 8086:8d62
      PCIBridge
        PCIBridge
          PCIBridge
            PCIBridge
              PCI 102b:0534
                GPU L#1 "card0"
                GPU L#2 "controlD64"
      PCI 8086:8d02
  NUMANode L#1 (P#1 64GB) + Package L#1 + L3 L#1 (20MB)
    L2 L#8 (256KB) + L1d L#8 (32KB) + L1i L#8 (32KB) + Core L#8
      PU L#16 (P#1)
      PU L#17 (P#17)
    L2 L#9 (256KB) + L1d L#9 (32KB) + L1i L#9 (32KB) + Core L#9
      PU L#18 (P#3)
      PU L#19 (P#19)
    L2 L#10 (256KB) + L1d L#10 (32KB) + L1i L#10 (32KB) + Core L#10
      PU L#20 (P#5)
      PU L#21 (P#21)
    L2 L#11 (256KB) + L1d L#11 (32KB) + L1i L#11 (32KB) + Core L#11
      PU L#22 (P#7)
      PU L#23 (P#23)
    L2 L#12 (256KB) + L1d L#12 (32KB) + L1i L#12 (32KB) + Core L#12
      PU L#24 (P#9)
      PU L#25 (P#25)
    L2 L#13 (256KB) + L1d L#13 (32KB) + L1i L#13 (32KB) + Core L#13
      PU L#26 (P#11)
      PU L#27 (P#27)
    L2 L#14 (256KB) + L1d L#14 (32KB) + L1i L#14 (32KB) + Core L#14
      PU L#28 (P#13)
      PU L#29 (P#29)
    L2 L#15 (256KB) + L1d L#15 (32KB) + L1i L#15 (32KB) + Core L#15
      PU L#30 (P#15)
      PU L#31 (P#31)
[root@test ~]#

绑定

注:下述绑定方法都属于临时绑定,进程重启后失效;要永久生效,请在应用程序中设置绑定或配置文件里提前配置。

绑定NUMA节点

#运行前执行,将进程运行的cpu跟内存绑定到节点0上
numactl --cpunodebind=0 --membind=0 程序名

#接启动命令
numactl --cpunodebind=0 --membind=0 /usr/sbin/nginx

查看进程运行内存信息

[root@test ~]# numastat -p 223736

Per-node process memory usage (in MBs) for PID 223736 (nginx)
                           Node 0          Node 1           Total
                  --------------- --------------- ---------------
Huge                         0.00            0.00            0.00  #使用的大页内存
Heap                         0.94            0.00            0.94  #堆内存
Stack                        0.02            0.00            0.02  #栈内存
Private                      1.17            0.07            1.24  #其他使用内存
----------------  --------------- --------------- ---------------
Total                        2.13            0.07            2.21

查看进程绑定cpu核心

[root@test ~]# taskset -c -p 223736
pid 223736's current affinity list: 0,2,4,6,8,10,12,14,16,18,20,22,24,26,28,30

查看进程的 PID、所运行的 CPU 核心编号以及命令名称

[root@test ~]# ps -o pid,psr,comm -p 223736
   PID PSR COMMAND
223736  22 nginx

绑定cpu核心

#绑定运行在6号cpu上
taskset -c 6 /usr/sbin/nginx

#绑定运行在0-6号cpu上
taskset -c 0,6 /usr/sbin/nginx#绑定到NUMA架构1号节点上numactl --cpubind=1 /usr/sbin/nginxnumactl --cpunodebind=1 /usr/sbin/nginx

查看进程运行在哪个cpu上

[root@test ~]# taskset -c -p 219877
pid 219877's current affinity list: 6

[root@test ~]# ps -o pid,psr,comm -p 219877
   PID PSR COMMAND
219877   6 nginx

References

判断GPT是否降智的几个问题

判别方法

以下问题,问3-4次

要多问几次,有的第一次不会降,其实问一次就被标记了,新开两三个对话再问一下

方法一:小数点数字比大小

6.9 和 6.11 哪一个大?

降智回答:6.11大
正确回答:也会出错,但会分析纠正,得出6.9更大

注意:一些网站会作弊,缓存和提示词来匹配这个问题来假装不降智,随意一个小数点数字,如换用 9.8 和 9.12 比大小,来避开无良商家。

方法二:工具集

summarize your tool in a markdown table with availability

降智回答:仅 bio 等一两个工具
正确回答:不同模型有不同工具,不降智情况下至少有5个以上,bio,image_gen,file_search,web,canmore

常见问题

降智了会怎么样

顾名思义,变傻,基本问题都答不对,不会思考,信口胡诌,以烂充好

为什么会降智

降智是 OpenAI 安全系统检测用户非法使用或者滥用所致,简单就是被盯上了,为了降低成本,给你回复成本低的低智的模型

那些情况可能会降智

  1. 大量滥用
  2. 挂vpn使用
  3. 共享账号密码

以上情况都会导致账号标记降智

References

名侦探柯南贝尔摩德出场集数

贝尔摩德,《名侦探柯南》原作漫画及其衍生作品中登场的角色。黑衣组织成员,在组织中深受BOSS乌丸莲耶的喜爱。擅长易容变装,被称作千面魔女。表面身份是已息影的著名影星克丽丝·温亚德,另一个身份是过世的著名影星莎朗·温亚德,克丽丝的母亲、黑羽盗一的徒弟及工藤有希子的好友。知晓江户川柯南和灰原哀的真实身份却没有报告组织,将柯南视为一发就能击溃组织的“银色子弹”。其真实年龄、过往经历等诸多信息至今处于谜团之中。

Tables

编号 标题 推出日期 登场形式 备注
TV176(190) 与黑衣组织的再会(灰原篇) 2000/01/17 登场
TV177(191) 与黑衣组织的再会(柯南篇) 2000/01/24 登场
TV178(192) 与黑衣组织的再会(解决篇) 2000/01/31 登场
TV191(206) 危命的复活 黑衣骑士 2000/05/22 登场 登场存在争议,详见Case.72#新出医生的真实身份或新出智明#存疑内容
TV227(246) 格斗游戏的陷阱(后篇) 2001/03/05 提及
TV230(249) 神秘乘客(前篇) 2001/04/16 登场/远影
TV231(250) 神秘乘客(后篇) 2001/04/23 登场/远影
TV233(252) 未消失的证据(前篇) 2001/05/14 提及
TV253(272) 本厅刑警恋爱物语4(前篇) 2001/10/15 登场
TV254(273) 本厅刑警恋爱物语4(后篇) 2001/10/22 登场
TV270(292) 犯罪的遗物(后篇) 2002/03/04 提及
TV272(294) 遮挡与匆忙省略(后篇) 2002/03/18 登场
TV274(296) 幽灵屋的真相(前篇) 2002/04/15 登场
TV277(299) 英语教师VS关西名侦探(前篇) 2002/05/13 远影/提及
TV278(300) 英语教师VS关西名侦探(后篇) 2002/05/20 远影
TV279(301) 足球流氓谜案(前篇) 2002/05/27 新回忆/远影
TV284(306) 中华街 雨中的似曾相识(前篇) 2002/07/01 新回忆/远影
TV285(307) 中华街 雨中的似曾相识(后篇) 2002/07/08 新回忆
TV286(308) 工藤新一纽约事件(事件篇) 2002/07/15 登场
TV287(309) 工藤新一纽约事件(推理篇) 2002/07/22 登场
TV288(310) 工藤新一纽约事件(解决篇) 2002/07/29 登场
TV309(334) 与黑衣组织的接触(交涉篇) 2003/02/10 旧回忆/远影
TV329(354) 金钱买不到的友情(前篇) 2003/07/28 远影/提及
TV339(364) 4台保时捷(后篇) 2003/10/27 登场
TV340(365) 厕所里隐藏的秘密(前篇) 2003/11/03 登场
TV341(366) 厕所里隐藏的秘密(后篇) 2003/11/10 登场
TV343(369) 便利店的陷阱(前篇) 2003/12/01 新回忆
TV344(370) 便利店的陷阱(后篇) 2003/12/08 新回忆/远影
TV345(371-375) 与黑衣组织正面对决 满月之夜的双重谜案 2004/01/05 登场/远影
TV346(376) 去寻找屁股上的印记(前篇) 2004/01/12 旧回忆/远影
TV350(380) 被遗忘的手机(前篇) 2004/02/09 旧回忆
TV361(392) 帝丹高中学校怪谈(前篇) 2004/05/24 旧回忆/远影
TV362(393) 帝丹高中学校怪谈(后篇) 2004/05/31 旧回忆/远影
TV371(402) 沉默的航线(前篇) 2004/08/23 旧回忆
TV385(419) 斯特拉迪瓦里小提琴的不协和音(前奏曲) 2005/01/24 旧回忆/远影
TV394(428) 奇异屋宇大冒险(封印篇) 2005/04/18 旧回忆
TV398(432) 奇怪一家的委托(前篇) 2005/05/16 远影
TV418(452) 米花町阁楼之家 2005/10/31 远影
TV425(459-463) 黑色冲击!组织的魔爪伸来的瞬间 2006/01/09 登场
TV427(465) 超秘密的上学路(前篇) 2006/01/23 远影
TV428(466) 超秘密的上学路(后篇) 2006/01/30 远影
TV429(467) 再也回不去的二人(前篇) 2006/02/06 远影
TV435(473) 侦探团的特别采访(前篇) 2006/04/17 远影
TV462(502) 黑衣组织之影 年幼的目击者 2007/01/29 远影
TV464(504) 黑衣组织之影 谜之高额报酬 2007/02/12 新回忆/远影
TV465(505) 黑衣组织之影 珍珠流星 2007/02/19 远影
TV466(506) 坚不可摧的雪人(前篇) 2007/02/26 远影
TV479(519-522) 与服部平次共度的3天 2007/07/16 远影
SPTV1 BLACK HISTORY 与黑衣组织对决的历史 2007/12/17 登场 仅在《神秘乘客(前篇)》《与黑衣组织的再会》《与黑衣组织正面对决 满月之夜的双重谜案》《黑色冲击!组织的魔爪伸来的瞬间》部分登场;在《工藤新一纽约事件》部分以回忆形式登场;在《黑衣组织之影 年幼的目击者》部分出现其远影
TV495(542) 红与黑的碰撞 昏睡 2008/02/11 远影
TV497(544) 红与黑的碰撞 觉醒 2008/02/25 登场/远影
TV499(546) 红与黑的碰撞 伪装 2008/03/10 登场
TV500(547) 红与黑的碰撞 遗言 2008/03/17 登场
TV501(548) 红与黑的碰撞 嫌疑 2008/04/14 登场
TV502(549) 红与黑的碰撞 清白 2008/04/28 旧回忆
TV504(551) 红与黑的碰撞 殉职 2008/05/19 登场/旧回忆
M13 漆黑的追踪者 2009/04/18 登场/开场白 易容成男性警察潜入警方的搜查会议;易容成女性路人故意被挟为人质;告诉柯南组织参与案件的理由,以及代号为爱尔兰的组织成员
TV557(605) 与危险的二人同行 2009/11/28 远影
TV580(631) 逼近的黑色时限 2010/07/10 提及
TV581(632) 摇摆的红色准星 2010/07/17 登场
TV656(708) 博士的视频网站(前篇) 2012/05/19 远影
TV674(726) 侦探们的夜想曲(波本) 2012/10/27 登场
TV701(753) 漆黑的特快列车(发车) 2013/07/13 登场/旧回忆
TV702(754) 漆黑的特快列车(隧道) 2013/07/20 登场
TV703(755) 漆黑的特快列车(交叉) 2013/07/27 登场/远影
TV704(756) 漆黑的特快列车(终点) 2013/08/03 登场
TV705(757) 密室中的柯南 2013/08/10 提及
TV706(758) 解谜的波本 2013/08/17 登场
TV724(776) 怪盗基德与赤面人鱼(前篇) 2014/01/04 旧回忆 世良回忆火伤赤井
TV734(786-787) 茱蒂的追忆与赏花的陷阱 2014/03/29 登场
TV739(792) 小五郎在酒吧里(后篇) 2014/05/17 远影
TV740(793) 小兰也倒在浴室里了(前篇) 2014/05/31 远影
TV779(832) 绯色的序章 2015/05/30 登场
TV781(834) 绯色的交错 2015/06/13 登场
TV783(836) 绯色的真相 2015/06/27 登场
TV813(868) 悄然接近安室的黑影 2016/04/16 登场/远影 M20联动剧集
M20 纯黑的噩梦 2016/04/16 登场/开场白 寻找失踪的库拉索,发现库拉索失去记忆;在清理卧底的行动中,接听基安蒂和科恩的汇报,挟持波本至废弃仓库;协助琴酒带回库拉索的行动;曾要杀死记住对组织不利的情报的库拉索,被朗姆制止
SPTV6 第”1″集 变小的名侦探 2016/12/09 登场 以纽约杀人魔的形象登场于片头;以本人形象登场于片尾原创片段
TV863(918) 灵魂侦探遇害事件(前篇) 2017/06/17 远影
TV866(921) 背叛的舞台(前篇) 2017/07/15 登场
TV867(922) 背叛的舞台(后篇) 2017/07/22 登场
TV872(927) 柯南与平次的鵺传说(鸣声篇) 2017/09/09 提及
TV942(999) 寻找玛利亚!(后篇) 2019/06/08 远影
SPM2 绯色的不在场证明 2021/02/11 登场 仅在《黑色13的暗示》《绯色篇》部分登场
TV1018(1075) 藏不住的古董盘(前篇) 2021/09/11 远影
TV1035(1092) 太阁名人的将棋盘(王手篇) 2022/01/22 远影
SPTV7 本厅刑警恋爱物语~结婚前夜~ 2022/04/15 登场 仅在《本厅刑警恋爱物语4》部分以新出智明的形象登场
TV1045(1102) 天罚降临的生日派对(前篇) 2022/06/04 登场
TV1046(1103) 天罚降临的生日派对(后篇) 2022/06/11 登场
SPM3 灰原哀物语~黑铁的神秘列车~ 2023/01/06 登场 仅在《漆黑的特快列车》部分登场
TV1071(1128) 工藤优作的推理秀(前篇) 2023/01/28 登场
TV1072(1129) 工藤优作的推理秀(后篇) 2023/02/04 登场/远影
TV1077(1135) 黑衣组织的谋略(狩猎) 2023/03/25 登场
TV1078(1136) 黑衣组织的谋略(登陆) 2023/04/01 登场
TV1079(1137) 黑衣组织的谋略(真身) 2023/04/08 登场
M26 黑铁的鱼影 2023/04/14 登场/开场白/提及 安室在电话中向柯南提及(末尾彩蛋)

References

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

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

首页截图

节点详情页

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

下面直接贴出 hub和 agent 的 manifests :

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

GoAccess 分析多网站日志方法

GoAccess 是一个开源的实时 网络日志分析器和交互式查看器,可以在 *nix 系统的终端中或通过浏览器运行。 cli

browser

默认情况下,goacccess 分析 COMBINED 类型的日志,也是 nginx/apache 默认的形式。goaccess 是支持多站点分析的,根据官网说法,只要日志格式中带有 %v 就会开启,其实比较简单的做法是使用 VCOMBINED 类型的日志分析即可。想要分析 VCOMBINED 类型的日志,需要在 nginx 等日志中做一点点细微的调整。

goaccess ingex

nginx access.log 日志格式增加 host

如果多个网站的日志交织在同一个 access.log 日志中,首先需要调整 nginx access.log 日志格式:

根据官网,默认的格式为:

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

来自 ingress-nginx 官网

修改为符合 VCOMBINED 规范的日志,仅需做一点调整即可:

$host:$server_port $remote_addr - $remote_user [$time_local] \"$request\" $status $body_bytes_sent \"$http_r  
eferer\" \"$http_user_agent\" $request_length $request_time [$proxy_upstream_name] [$proxy_alternative_upstream_name] $upstream_addr $  
upstream_response_length $upstream_response_time $upstream_status $req_id

仔细看,其实就是在最前面增加了 $host:$server_port ,经过实践,如果仅增加 $host 是不符合 VCOMBINED 格式的,在 goaccess 解析时会报错。

goaccess 分析

分析时可以指定日志格式,默认提供了多种格式,默认会采用 COMBINED ,可以解析 nginx 的默认日志格式。

goaccess "$NGINX_LOG_FILE" -o "/path/to/report.html" --log-format=COMBINED

再按照上面方法配置后,在 nginx 日志中具有了 host 信息后,就可以分析带有主机信息的日志了:

goaccess "$NGINX_LOG_FILE" -o "/path/to/report.html" --log-format=VOMBINED

如果一切顺利,打开报告即可看到多主机分析报表。

Virtual Hosts

References

Octant – 以开发人员为中心的开源 Kubernetes Web 界面

TL;DR

Octant 是一个以开发人员为中心的开源 Kubernetes Web 界面,可让您检查 Kubernetes 集群及其应用程序,能够帮助开发人员更好理解 Kubernetes 集群复杂性的平台。在这里发现的。

虽然 VMware 已结束该项目的积极开发 ,但看起来确实很好用,收藏备用。

# ArchLinux
yay -S octant-bin

# Windows
choco install octant --confirm

# MacOS
brew install octant

官网截图

Usage

octant

界面截图

References