一个 LiquedGlass 风格图像生成器; 一个 LiquedGlass 风格模拟器。
快速生成 Apple 液态玻璃风格图像。快速体验液态玻璃设计风格。
界面截图




一个 LiquedGlass 风格图像生成器; 一个 LiquedGlass 风格模拟器。
快速生成 Apple 液态玻璃风格图像。快速体验液态玻璃设计风格。
界面截图




对于CPU和NUMA架构的介绍本文不再做叙述,感兴趣的可自行查看:Linux–CPU简述,Linux–内存管理浅谈。
NUMA 架构将内存和cpu分散在不同的 NUMA 节点上,每个节点都有自己的本地内存和cpu处理器,将进程绑定到特定的 NUMA 节点或cpu上,可以让进程直接访问本地内存和CPU,减少访问远程节点开销,提高访问速度,从而提高程序性能。
注:不可多进程绑定同一个节点或cpu,这样反而会使该节点产生资源竞争,降低性能。
[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 ~]#
注:下述绑定方法都属于临时绑定,进程重启后失效;要永久生效,请在应用程序中设置绑定或配置文件里提前配置。
#运行前执行,将进程运行的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
#绑定运行在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
以下问题,问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 安全系统检测用户非法使用或者滥用所致,简单就是被盯上了,为了降低成本,给你回复成本低的低智的模型
以上情况都会导致账号标记降智
./hdc shell
hdc app install -r xxx.hap
贝尔摩德,《名侦探柯南》原作漫画及其衍生作品中登场的角色。黑衣组织成员,在组织中深受BOSS乌丸莲耶的喜爱。擅长易容变装,被称作千面魔女。表面身份是已息影的著名影星克丽丝·温亚德,另一个身份是过世的著名影星莎朗·温亚德,克丽丝的母亲、黑羽盗一的徒弟及工藤有希子的好友。知晓江户川柯南和灰原哀的真实身份却没有报告组织,将柯南视为一发就能击溃组织的“银色子弹”。其真实年龄、过往经历等诸多信息至今处于谜团之中。
| 编号 | 标题 | 推出日期 | 登场形式 | 备注 |
|---|---|---|---|---|
| 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 | 登场/开场白/提及 | 安室在电话中向柯南提及(末尾彩蛋) |
在逛 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
agentapiVersion: 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 加入。如果不使用这个模式,会收集不到网络数据,看到的带宽情况一直是 .
目前在用 Keel,感觉良好。
以下是几种可以在 K3s 中实现轻量级 DevOps 解决方案对比:
| 方案 | 资源占用 | 易用性 | Web UI | 集成能力 | 配置复杂度 | 特点 |
|---|---|---|---|---|---|---|
| ArgoCD | 中等 | ★★★★☆ | 优秀 | 原生支持 Git/镜像更新 | 中等 | GitOps 专注,声明式部署 |
| FluxCD | 低 | ★★★☆☆ | 基础(最新版改进) | 原生支持 Git/镜像更新 | 中等 | GitOps 专注,自动化程度高 |
| Drone | 低 | ★★★★☆ | 优秀 | 需配置触发器 | 低 | 轻量级,无需 CRD |
| Jenkins X | 高 | ★★☆☆☆ | 良好 | 丰富 | 高 | 功能全面但较重 |
| Tekton | 中等 | ★★★☆☆ | 需安装Dashboard | 高度可定制 | 中高 | 云原生管道 |
| Keel | 极低 | ★★★★★ | 简单 | 专注镜像更新 | 极低 | 超轻量,专注自动部署 |
优势:
劣势:
资源需求: 至少 1-2 核 CPU,2GB 内存
优势:
劣势:
资源需求: 约 0.5 核 CPU,512MB 内存
优势:
劣势:
资源需求: 约 0.5 核 CPU,512MB 内存
优势:
劣势:
资源需求: 约 0.2 核 CPU,256MB 内存
基于需求(轻量级、简单配置、Web UI、自动化部署):
优势:
配置示例:
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
如果您需要更强大的 UI 和更完整的 GitOps 工作流,推荐使用 ArgoCD,虽然资源消耗稍高,但提供了更全面的功能和更好的可视化体验。
Keel + GitHub Actions 是最轻量且直接的解决方案,几乎零配置即可工作。如果需要更全面的 GitOps 体验和更好的可视化,可以考虑 ArgoCD,它虽然资源消耗稍高,但提供了更完善的功能。
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
GoAccess 是一个开源的实时 网络日志分析器和交互式查看器,可以在 *nix 系统的终端中或通过浏览器运行。


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

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
如果一切顺利,打开报告即可看到多主机分析报表。

Octant 是一个以开发人员为中心的开源 Kubernetes Web 界面,可让您检查 Kubernetes 集群及其应用程序,能够帮助开发人员更好理解 Kubernetes 集群复杂性的平台。在这里发现的。
虽然 VMware 已结束该项目的积极开发 ,但看起来确实很好用,收藏备用。
# ArchLinux
yay -S octant-bin
# Windows
choco install octant --confirm
# MacOS
brew install octant

octant
