阳明的博客

在本节中我们将要安装配置 Filebeat 来收集 Kubernetes 集群中的日志数据，然后发送到 ElasticSearch 去中，Filebeat 是一个轻量级的日志采集代理，还可以配置特定的模块来解析和可视化应用（比如数据库、Nginx 等）的日志格式。

Elastic APM 是 Elastic Stack 上用于应用性能监控的工具，它允许我们通过收集传入请求、数据库查询、缓存调用等方式来实时监控应用性能。这可以让我们更加轻松快速定位性能问题。

Elastic APM 是兼容 OpenTracing 的，所以我们可以使用大量现有的库来跟踪应用程序性能。

前面我们的文章中都是将 Prometheus 安装在 Kubernetes 集群中来采集数据，但是在实际环境中很多企业是将 Prometheus 单独部署在集群外部的，甚至直接监控多个 Kubernetes 集群，虽然不推荐这样去做，因为 Prometheus 采集的数据量太大，或大量消耗资源，比较推荐的做法是用不同的 Prometheus 实例监控不同的集群，然后用联邦的方式进行汇总。但是使用 Prometheus 监控外部的 Kubernetes 集群这个需求还是非常有必要的。

前面我们和大家提到过 GitOps 的实践，我们知道 GitOps 是提倡通过 Git 来管理所有的配置，通过声明式代码来对环境配置和基础设施进行版本管理。

在 Kubernetes 中我们知道可以使用资源清单文件来管理集群中的一资源对象，但是讲 Kubernetes 的 Secrets 数据存储在 Git 仓库中还是非常不妥的，毕竟也是非常不安全的。

Kubernetes Secrets 是用来帮助我们存储敏感信息的资源对象，比如密码、密钥、证书、OAuth Token、SSH KEY 等等。管理员可以通过创建 Secrets 对象，然后开发人员就可以在资源清单文件中非常方便的引用 Secrets 对象，而不用直接将这些敏感信息硬编码。

虽然这看上去非常方便，但是有 Secrets 的问题是它们只是简单的将这些敏感信息做了一次 base64 编码而已，任何人都可以非常容易对其进行解密获得原始的数据。所以我们说 Secrets 清单文件不能直接存储在 Git 源码仓库中，但是如果每次都去手工创建的话，这又使得我们的 GitOps 不是很流畅了。

为此 Bitnami Labs 创建了一个名为 Sealed Secrets 的开源工具来解决这个问题。

我们对 PV 和 PVC 的几种状态应该不算陌生，但是在使用过程中可能也会产生一些疑问，比如为什么 PV 变成 Failed 状态了，新创建的 PVC 如何能够绑定之前的 PV，我可以恢复之前的 PV 吗？这里我们就来对 PV 和 PVC 中的几种状态变化再次进行说明。

前面其实我们在 Windows 系统的 WSL2 下面使用 KinD 搭建了一套 Kubernetes 集群，KinD 是一个非常轻量级的 Kubernetes 安装工具，他将 Docker 容器当成 Kubernetes 的节点，使用非常方便。既然在 Docker 容器中可以运行 Kubernetes 集群，那么我们自然就会想到是否可以在 Pod 中来运行呢？在 Pod 中运行会遇到哪些问题呢？

本文我们将介绍如何在 Windows10 下使用 WSL2 和 KinD 来搭建一套 Kubernetes 集群。在过去几年，Kubernetes 已经成为了容器编排领域事实上的标准。虽然现在已经有各种各样的 Kubernetes 发行版本和安装程序来部署 Kubernetes 环境了，除了云环境或者裸机环境下面之外，我们仍然需要在本地部署和运行 Kubernetes 集群，特别是对于相关的开发人员。

但是 Kubernetes 最开始是被设计在 Linux 环境中来部署和使用的，然而还是有不少用户平时工作还是使用的是 Windows 操作系统，为了降低 Windows 用户使用 Linux 的困难程度，微软推出了 WSL (Windows Subsystem for Linux)，该工具相当于一个运行在 Windows 下面的 Linux 子系统，这让 Windows 和 Linux 之间的环境界限变得更加不明显了，特别是 WSL2 版本推出以后，完全具有了在 WSL2 中运行 Docker 的能力了，所以现在我们几乎可以无缝地在 WSL2 上面运行 Kubernetes。

对于生产环境以及一个有追求的运维人员来说，哪怕是毫秒级别的宕机也是不能容忍的。对基础设施及应用进行适当的日志记录和监控非常有助于解决问题，还可以帮助优化成本和资源，以及帮助检测以后可能会发生的一些问题。前面我们介绍了使用 EFK 技术栈来收集和监控日志，本文我们将使用更加轻量级的 Grafana Loki 来实现日志的监控和报警，一般来说 Grafana Loki 包括 3 个主要的组件：Promtail、Loki 和 Grafana（简称 PLG），最为关键的是如果你熟悉使用 Prometheus 的话，对于 Loki 的使用也完全没问题，因为他们的使用方法基本一致的，如果是在 Kubernetes 集群中自动发现的还具有相同的 Label 标签。

前面我们都是通过手动创建一个 TaskRun 或者一个 PipelineRun 对象来触发任务。但是在实际的工作中更多的是开发人员提交代码过后来触发任务，这个时候就需要用到 Tekton 里面的 Triggers 了。

Triggers 同样通过下面的几个 CRD 对象对 Tekton 进行了一些扩展：

• TriggerTemplate: 创建资源的模板，比如用来创建 PipelineResource 和 PipelineRun
• TriggerBinding: 校验事件并提取相关字段属性
• ClusterTriggerBinding: 和 TriggerBinding 类似，只是是全局的
• EventListener: 连接 TriggerBinding 和 TriggerTemplate 到事件接收器，使用从各个 TriggerBinding 中提取的参数来创建 TriggerTemplate 中指定的 resources，同样通过 interceptor 字段来指定外部服务对事件属性进行预处理

从我们第一次听到持续交付这个词，到现在估计差不多有 10 年时间了吧。Humble Jez 和 Farley David 在 2010 年的时候，通过他们的新书《Continuous Delivery: Reliable Software Releases Through Build, Test and Deployment Automation》提出的。在过去 10 年中，持续交付改变了我们软件发布的方式。现在随着围绕 Kubernetes 生态系统不断演变出的一套新的工具，让我们在持续交付的旅程中实现了又一次飞跃。这些工具基本上都是围绕着 GitOps 这个概念展开的，本文将尝试来解释下 “GitOps” 的 Why? What? 以及 How?

如果你经常使用 Jenkins Pipeline 一定会遇到多个不同流水线中有大量重复代码的情况，很多时候为了方便我们都是直接复制粘贴到不同的管道中去的，但是长期下去这些代码的维护就会越来越麻烦。为了解决这个问题，Jenkins 中提供了共享库的概念来解决重复代码的问题，我们只需要将公共部分提取出来，然后就可以在所有的 Pipeline 中引用这些共享库下面的代码了。

前几天我们在解决 CoreDNS 的 5 秒超时问题的时候，使用了 NodeLocal DNSCache 来解决这个问题，集群 DNS 的解析性能也明显大幅提升了。但是今天确遇到一个很大的坑，我们在做 DevOps 实验的时候，相关的工具都使用的是自定义的域名，这个时候要互相访问的话就需要添加自定义的域名解析，我们可以通过给 Pod 添加 hostAlias 来解决，但是在使用 Jenkins 的 Kubernetes 插件的时候却不支持这个参数，需要使用 YAML 来自定义，比较麻烦，所以想着通过 CoreDNS 来添加 A 记录解决这个问题。