Posts

Kyverno 是来自 Nirmata 的开源项目，后来捐赠给了 CNCF。Kyverno 是一个具有验证和变异能力的 Kubernetes 策略引擎，但是它还有生成资源的功能，还加入了 API 对象查询的能力。Kyverno 原本就是为 Kubernetes 编写的，除了对象生成功能之外，无需专用语言即可编写策略。

我们了解了 Prometheus 的使用，了解了基本的 PromQL 语句以及结合 Grafana 来进行监控图表展示，通过 Alertmanager 来进行报警，这些工具结合起来已经可以帮助我们搭建一套比较完整的监控报警系统了，使用 Kube Prometheus 还可以搭建一站式的 Kubernetes 集群监控体系，但是对于生产环境来说则还有许多需要改进的地方。

单台的 Prometheus 存在单点故障的风险，随着监控规模的扩大，Prometheus 产生的数据量也会非常大，性能和存储都会面临问题。毋庸置疑，我们需要一套高可用的高性能的 Prometheus 集群。

最近很多人咨询如何使用 GPT-4，目前只有 ChatGPT Plus 会员才能体验 GPT-4，所以就需要开通 ChatGPT Plus 会员才行，Plus 的好处很多，更加稳定，不会动不动就断掉，需要每个月 20 美元的费用，最关键的是现在你想付费还没办法，国内的 VISA 卡这些也是不支持的，这一步卡住了不少人，注册门槛还是非常高的。这里就分享一下本人有效的 Plus 付费流程，整体上来说需要下面几个步骤。

声明：Depay 是虚拟信用卡提供商，本人不能 100%保证其是否靠谱，所以不要往里面充值太多钱，够一个月使用的费用即可，不要到时候人家跑路了，来找我维权，只是我本人通过该方式成功开通了 Plus 会员，所以自行甄别！

DevStream 是一个开源的 DevOps 工具链管理器，因开发者而生，由开发者开发，为开发者服务。

想象你正在开始一个新的项目或组建一个新的团队。在写第一行代码之前，你需要一个能够高效运转 SDLC(软件开发生命周期)和承载开发至部署全过程的工具。

通常情况下，你需要以下几个部分来高效地工作。

• 项目管理软件或  issue  追溯工具（JIRA 等）
• 源代码管理（GitHub、Bitbucket 等）
• 持续集成（Jenkins、CircleCI、Travis CI 等）
• 持续交付/部署（Flux CD/Flux2、Argo CD 等)
• 密钥和证书的单一事实来源(A single source of truth)（密钥管理器，如 HashiCorp 的 Vault）
• 集成化的日志和监控工具（例如，ELK、Prometheus/Grafana）
• ……

实际的情况可能远不止这些，要找到合适的组件本身就不容易了，再将这些工具整合起来就更难了，需要花费大量的时间和精力。而 DevStream 就是为简化整合 DevOps 组件而构建的工具，有点类似于 yum、apt 这些软件包管理工具，DevStream 就是 DevOps 工具领域的软件包管理器。

昨天网络环境出了点问题，本地的虚拟机搭建的 Kubernetes 环境没有固定 IP，结果节点 IP 变了，当然最简单的方式是将节点重新固定回之前的 IP 地址，但是自己头铁想去修改下集群的 IP 地址，结果一路下来踩了好多坑，压根就没那么简单~

为了方便测试，准备为 Ingress 控制器配置一个 LoadBalaner 类型的 Service，由于我这是本地私有环境，所以需要部署一个支持该服务类型的负载均衡器，在社区中目前最流行的应该是 MetalLB 这个项目，现在也属于 CNCF 沙箱项目，该项目在 2017 年底发起，经过 4 年的发展已经在社区被广泛采用，但是我这边在测试使用过程中一直表现不稳定，经常需要重启控制器才能生效。所以将目光转向了最近国内青云开源的另外一个负载均衡器 OpenELB。

近日，Docker 创始人 Solomon Hykes 对外宣布推出全新产品 Dagger，Dagger 是一个全新的 DevOps 平台，目的是为开发者解决 DevOps 流程上的一些问题。目前 Dagger 已经获得 2000 万 A 轮融资，本轮融资由 Redpoint Ventures 领投，GitHub 前 CEO Nat Fireman、Red Hat 前 CTO Brian Stevens 、Reddit 前 CEO Ellan Pao 等大佬参投。

Dagger 要帮助 DevOps 开发者将 CI/CD 流水线编写成 CUE 中的声明性模型，以此为基础，开发者可以描述自己的流水线、并将其中各个环节进行对接，同时全部以纯代码形式实现。

昨天在 Prometheus 课程辅导群里面有同学提到一个问题，是关于 Prometheus 监控 Job 任务误报的问题，大概的意思就 CronJob 控制的 Job，前面执行失败了，监控会触发报警，解决后后面生成的新的 Job 可以正常执行了，但是还是会收到前面的报警：

这是因为一般在执行 Job 任务的时候我们会保留一些历史记录方便排查问题，所以如果之前有失败的 Job 了，即便稍后会变成成功的，那么之前的 Job 也会继续存在，而大部分直接使用 kube-prometheus 安装部署的话使用的默认报警规则是kube_job_status_failed > 0，这显然是不准确的，只有我们去手动删除之前这个失败的 Job 任务才可以消除误报，当然这种方式是可以解决问题的，但是不够自动化，一开始没有想得很深入，想去自动化删除失败的 Job 来解决，但是这也会给运维人员带来问题，就是不方便回头去排查问题。下面我们来重新整理下思路解决下这个问题。

虽然 Traefik 已经默认实现了很多中间件，可以满足大部分我们日常的需求，但是在实际工作中，用户仍然还是有自定义中间件的需求，为解决这个问题，官方推出了一个 Traefik Pilot 的功能了，此外在 Traefik v2.5 版本还推出了支持本地插件的功能。

随着 Kubernetes 的版本不断迭代发布，很多 Helm Chart 包压根跟不上更新的进度，导致在使用较新版本的 Kubernetes 的时候很多 Helm Chart 包不兼容，所以我们在开发 Helm Chart 包的时候有必要考虑到对不同版本的 Kubernetes 进行兼容。

前面我们有文章介绍过如何在 Kubernetes 集群中使用 GitLab CI 来实现 CI/CD，在构建镜像的环节我们基本上都是使用的 Docker On Docker 的模式，这是因为 Kubernetes 集群使用的是 Docker 这种容器运行时，所以我们可以将宿主机的 docker.sock 文件挂载到容器中构建镜像，而最近我们在使用 Kubernetes 1.22.X 版本后将容器运行时更改为了 Containerd，这样节点上没有可用的 Docker 服务了，这个时候就需要更改构建镜像的模式了，当然要实现构建镜像的方式有很多，我们这里还是选择使用 Docker 来构建我们的 Docker 镜像，也就是使用 Docker IN Docker 的模式。

在学习 Containerd 之前我们有必要对 Docker 的发展历史做一个简单的回顾，因为这里面牵涉到的组件实战是有点多，有很多我们会经常听到，但是不清楚这些组件到底是干什么用的，比如 libcontainer、runc、containerd、CRI、OCI 等等。