Kube-prometheus provides quite a few great collections of components and alerts that help us monitoring our Kubernetes cluster. I’ve used it in the production cluster for serveral months. Although the project exposes a bunch of options via _config+:: to makes it partially configurable, the scope of parameters that we can modify is still limited.
In kubernetes-mixin (a dependency of kube-prometheus-stack and prometheus-operator charts) rules, the severity label of alrets can be critical, warning, or info etc. However, OpsGenie’s priority field only accepts values like P1, P2 … P5. As a user of both of them, I would have to convert the “severity” to OpsGenie’s “priority”. For example, if a critical alert was fired, a matched P1 alert to be created in OpsGenie is expected, and warning -> P2, info -> P3, as well.
While I deploying v2ray-exporter with Kustomize, I realized that commonLabels in kustomization.yaml doesn’t take care of the spec.selector.matchLabels field in ServiceMonitors. That makes sense, as ServiceMonitor is a part of CoreOS’s Prometheus Operator project, neither included nor maintained by Kubernetes. But how can we direct Kustomize to fill the labels in ServiceMonitors or even any fields in customized resources?
已发布的 DevOps 自动化实践 - 定时任务监控的进化之路 一次 KubeCPUOvercommit 告警排查过程小记 DevOps 自动化实践 — 在 K8s 上自动化执行 Database Migration 基于 UniFi 全家桶的企业 Wi-Fi 客户端管理 DevOps 自动化实践 — 管理 Incident 工作流 迁移至个人博客的 由于相关人员长期拖延审稿、发稿，将部分文章迁移至个人博客发布。
在 Kubernetes 中实现 TLS termination 非常容易。Ingress 资源包含一 secretName 属性，用于指定 Secret 资源名称。在取得证书后，通过 kubectl create secret tls tls-secret --key tls.key --cert tls.crt 创建 Secret 存储证书，便可以被 Ingress 使用了。 唯独有些不方便的是，证书的申请以及创建 Secret 的过程需要手动执行。在证书即将过期前，还需要人工续期。在传统 VM 部署的场景下，可以使用例如 certbot 或 acme.sh 等项目，配合 Let’s Encrypt 自动申请并定期续签证书。而在 K8s 集群中如何降低证书维护成本？来看看我们是怎么做的。
在上一篇文章中，为大家介绍了 Helm 的初步使用。然而这仍然不能满足我司的工作流，主要问题有： Helm 不提供 apply 命令；因此在 CI/CD 场景中必须考虑到判断是 install 还是 upgrade。 不方便控制安装的 chart 版本；例如指定版本范围、锁定某一版本等。 Values 必须是纯文本；不支持模板渲染、不方便区分环境。 因此我们需要 Helm Releases as Code。我听说过的产品有 Helmsman 和 Helmfile 两款。目前我们团队已经使用后者一段时间，并且有团队成员贡献过部分代码。
Helm 是一款针对 Kubernetes 的「包管理器」，虽说称它为包管理器，其实与应用开发过程中使用的包管理器略有不同，后者管理的是应用开发过程中的依赖，Helm 则管理着 Kubernetes 中应用部署时各项资源的依赖。 如果你对 Kubernetes 有一定了解，相信你已经对 Deployment、Service、Ingress 等资源有了一定认识，大多数 Web 应用在部署到 K8s 集群上时需要大量不同类型的资源。你可以将这些资源声明的 YAML 文件放在同一个文件夹下管理，但是随着数量的增加，如何复用这些 YAML、如何灵活又不繁琐地调整配置以适应不同环境、如何将这些 YAML 作为一个整体管理，成了一个不小的问题。
平时除了维护公司和私人在公有云的 Kubernetes clusters 之外，个人网络环境下还有些需要运行在本地的 workload；比如用于监控本地路由设备（~作~ XD）的 Prometheus exporters 和一些新奇玩意儿。为了能够运行这些应用，我在家组建了一套「边缘计算集群」，来看看是怎么做的吧。
Recently, I’ve been working against Kubernetes and Helm for a while. Today, I faced a strange problem that could only be triggered in a very very specific condition. After determined what happened under the hood, I decided to write it down in case someone else needs it. Also, BTW, to practice my English. :D
（接上文） 前面的部分介绍了如何为我的博客打包 Docker 镜像，接下来就是重头戏 —— 部署到 Kubernetes。