得益于Google的colab可以为我们免费提供13GiB的内存以及15GiB GPU、80GiB硬盘的运算算力，因此，可以借助该资源来体验stable-diffusion项目。

话不多说，先来看下最终效果:

这个问题，其实需要分版本做不同的处理,是通过ArgoCD健康检查的自定义的资源检查来排除对Ingress的检查。

在使用Mac的时候，我一直是有个疑问，就是自带的活动监视器里面的内存总是和第三方安装的 htop 等命令行工具里面的内存使用量对不上。不知道以哪个为准。为此，特意去翻了翻官方的文档，了解了个大概。

如果您曾经在 Linux 系统上工作过，那么您很可能使用过top命令。如果您知道该命令，您将很快习惯 Kubernetes 中的命令是如何工作的。如果你不这样做，不要害怕！虽然kubectl top 是一个强大的命令，但使用起来非常简单。

一、什么是webhook?

1. webhook简介

用过Jenkins自动化构建项目的流程都知道，当git push之后，git的webhook机制便会发出请求，向Jenkins服务器通知开始执行构建流程。
Webhooks可以理解为满足特定的事件触发时（例如git push代码后，或者grafana触发告警），源网站发起一个HTTP请求到webhook配置的URL。webhook收到请求后进行相对应的处理（比如Jenkins自动构建项目，或者转发grafana告警）。
概括来说，就是在一个系统触发事件后，另一个系统收到请求并处理相应的任务，而收到请求并处理的部分便是webhook

2.grafana使用webhook场景

虽然grafana内置了非常丰富的告警媒介（例如邮箱、钉钉、slack、Prometheus Alertmanager等）具体参考官方文档：https://grafana.com/docs/grafana/latest/alerting/notifications/。
但是如果需求是收到grafana告警后执行一系列的其他操作，此时内置的告警媒介便不能满足需求，例如在企业内部已有告警平台接口，实现了告警分级通知，分组通知等功能。但是grafana告警事件与现有的告警平台接口并不能直接对接，因为grafana告警输出格式与告警平台接入格式并不匹配。此时就要用到webhook充当中间人角色，收到grafana告警内容后做一系列处理工作，转换为告警接口要求的请求格式，从而实现告警触发。

没想到有一天，从我的嘴巴里也说出这种老套的话。

但，没办法否认的是，在这个快节奏社会，卷得厉害，为了不被抛弃，谁都不敢松懈，卷不动了依旧坚挺着，压力都是有的。

我们的身体跟我们一起承担着这份压力，我深知，它撑得很辛苦。

我也是。因为辛苦，所以更有必要善待它。

扫描下方二维码领取红包:

持续更新中…

Redis的部署历程从单机部署、主从模式、哨兵模式、集群路径进行演变，如果你还不了解这四种模式以及优缺点的话，这篇文章会很适合你进行阅读认识。《一文读懂Redis的四种模式，单机、主从、哨兵、集群》

在了解QPS、TPS、RT、并发数之前，首先我们应该明确一个系统的吞吐量到底代表什么含义，一般来说，系统吞吐量指的是系统的抗压、负载能力，代表一个系统每秒钟能承受的最大用户访问量。