前面其实我们在 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 记录解决这个问题。

日志和监控就像 Tony Stark 和他的 Iron Man 西装一样，两者需要一起使用才能发挥最大的威力，因为它们可以很好互补。

日志一直是应用程序和基础框架性能和故障诊断的重要手段，但是现在我们已经意识到日志不仅可以用于故障诊断，还可以用于大数据分析以及业务的一些可视化和性能分析等等。

所以，记录应用程序日志是非常非常重要的。

Okteto 是一个通过在 Kubernetes 中来开发和测试代码的应用程序开发工具。可以通过 Okteto 在 Kubernetes 中一键为我们启动一个开发环境，非常简单方便。前面我们也介绍过 Google 推出的 Skaffold 工具，今天我们演示下如何使用 Okteto 来搭建 Python 应用开发环境。

刚刚发现一款看上去非常厉害的工具：icepanel，可以用来快速创建和可视化我们的 Kubernetes 微服务应用程序。使用也是非常简单，只需要安装一款 VSCODE 插件即可。

在前面文章中，我们在 Kubernetes 集群中安装了 Tekton，通过 Tekton 克隆 GitHub 代码仓库并执行了应用测试命令。接着前面的内容，本文我们将创建一个新的 Task 来构建一个 Docker 镜像并将其推送到 Docker Hub，最后，我们将这些任务组合成一个流水线。

Tekton 是一款功能非常强大而灵活的 CI/CD 开源的云原生框架。Tekton 的前身是 Knative 项目的 build-pipeline 项目，这个项目是为了给 build 模块增加 pipeline 的功能，但是随着不同的功能加入到 Knative build 模块中，build 模块越来越变得像一个通用的 CI/CD 系统，于是，索性将 build-pipeline 剥离出 Knative，就变成了现在的 Tekton，而 Tekton 也从此致力于提供全功能、标准化的云原生 CI/CD 解决方案。

本文将通过一个简单的示例来创建一个构建流水线，在流水线中将运行应用程序的单元测试、构建 Docker 镜像然后推送到 Docker Hub。