Prometheus 监控生态逐渐成熟

Kubernetes 集群的 Prometheus 开源监控生态系统已经开始成熟。其中,Cortex 是可扩展、高可用的 Prometheus 多租户存储平台,Thanos 是提供集中化和扩展 Prometheus 实例的度量标准系统,两者都已成为 CNCF 中的孵化级项目。下一步是假设这些项目能够在整个 CNCF 社区中获得足够的支持,并升至与 Prometheus 和 Kubernetes 相同的等级。

Prometheus 的使用与 Kubernetes 集群的采用保持同步,尤其是在应用程序开发环境中。随着容器应用程序进入生产环境,虽然目前尚不清楚有多少组织将继续使用 Prometheus,因为很多 IT 组织已经拥有大量监控工具可以使用,但还有一些未开发的 Kubernetes Deployment 还将依赖 Prometheus 来监控生产环境。

另外,可观察性是任何最佳 DevOps 实践的核心原则。实际上,Kubernetes 和微服务也在要求 IT 团队采用 DevOps。Prometheus 并不是实现可观察性的唯一方法,但毫无疑问,Prometheus 是最佳 DevOps 的重要力量,特别是随着 Cortex 和 Thanos 的不断成熟

K8s 开发工作流程 3 个关键步骤

建立有效的 K8s 开发工作流程对于 K8s 的成功使用至关重要。随着 K8s 的发展,现在使用 K8s 的开发人员比以往任何时候都要多,这也意味着原先的工作流程必须更改,但将 K8s 有效集成到开发工作流程中并不容易,以下是 K8s 开发工作流程的 3 个关键步骤。

设置 Kubernetes 工作环境

建立有效的 K8s 开发工作流程的第一步是确定使用哪种工作环境。这个问题不仅是要使用哪种云环境或 Kubernetes 托管服务,还有是否应该要完全使用云环境。本地和基于云的工作环境各有利弊:虽然有免费使用的本地环境,但云环境却要花钱。本地环境可以脱机使用,并且完全独立于其他开发人员和其他基础结构。云环境的优势在于,它提供了更多的计算资源,运行着“标准的” K8s(不仅是在本地计算机上运行的版本),而且易于启动。另外,它可以使用内部 K8s 平台自动执行此类环境的配置。

发展

开发人员可以访问 Kubernetes 工作环境后,需要确定实际的开发阶段,即编码、构建和结果观察测试。尽管大多数工程师没有设置 K8s 环境的经验,但他们对软件开发阶段非常熟悉。不过,与引入 K8s 后相比,工作流程可能会发生重大变化。这就给开发人员带来了新的挑战:如何对软件进行容器化?如何在 K8s 中构建和启动容器?如何将代码更改部署到容器中,以便开发人员查看其更改?如何调试软件?所有这些问题都需要解决,所有解决方案都应成为标准化的工作流程。

同时,许多公司将 K8s 引入开发阶段后,面对着相同的问题,因此开发了一些开源工具来解决这一领域的问题。例如 DevSpace、Skaffold、Tilt 和 Telepresence。所有这些工具都具有相似的用途并且相对通用(例如 Tilt 可用于远程环境,DevSpace 也可用于本地环境或 CI/CD 管道)。我们应该查看所有的解决方案,通过自身偏好和需求,来决定哪种解决方案最适合自身情况

部署

与 K8s 开发工作流程相关的最后一步是部署,这意味着开发人员将他们的代码推送到存储或测试环境,最终将推送到生产环境。部署到 K8s 的解决方案之一是前面提到的开发工具,其中最著名的是 Skaffold 和 DevSpace,它们可以集成到更复杂的 CI/CD 管道中。

最后

为了建立有效的 K8s 开发工作流程,需要定义和简化工作流程步骤。首先是为开发人员提供 K8s 工作环境,该环境可以在本地运行或在云中运行;然后我们需要易于使用的 K8s 开发工具来支持开发的,即编码、快速部署和调试;最后开发人员必须有一种简单的方法来将开发的代码部署到生产环境。以上步骤的共同点是,它们标准化并易于开发人员使用,以使 K8s 的采用尽可能地流畅。这样一来,我们就不必担心使用 K8s 会非常复杂。

https://loft.sh/blog/kubernetes-development-workflow-3-critical-steps/

简单安全的自动化之路

近期的 COVID-19 事件使 IT 响应团队承受了前所未有的压力,零售、在线学习等行业在数字化运营方面皆受到了极大挑战,与此前相比,如今的 IT 事故发生率翻了一番。许多团队需要比以往更多的时间来处理紧急工作,对此,自动化展现出了极大优势。自动执行重复性和手动任务可以减少人工成本并更快完成,在许多情况下还能提供更高的准确性。

自动化听起来不错,但有个问题,自动化是否安全?如果它可以很好地解决 95% 的事件,但对另外 5% 的事件造成了灾难性的恶化,该怎么办?这是一个非常公平的问题,但它基于了错误的前提,因为自动化并不一定是完全自动化。实际上,自动化更应该是分阶段实施的。安全的自动化途径包括几个步骤。自动化演进的每个步骤都建立在最后一步,尽管在某些情况下可能会省略某些步骤。

  • 阶段 1:确定要自动化什么。第一步就是确定团队重复遇到的事件类型。在这种事件中,自动化是最有意义的,并能提供最高回报。
  • 阶段 2:人为启动自动化。下一步是使运行手册自动化,并将自动化脚本提供给个人使用。这样他们只需按一下按钮即可自动化修复问题,并根据需要完善脚本。该步骤的目标是每次都以完全相同的方式解决重复性事件,并验证脚本是否真正起作用。
  • 阶段 3:人机共存。在此步骤中,需要一个工作人员,并同时启动自动化。人类的职责是确保自动化能够正常进行。
  • 阶段 4:机器启动的人为后备。在此步骤中,检测到事件后会自动启动补救措施,并在无法解决问题的情况下对人员进行呼叫。请记住,即使自动化成功了,定期观察其结果也很重要,以便在必要时能够进行过程校正。

这种自动化方法有几个非常重要的优点。首先,就是节省时间;其次,这是一种非常低风险的方法,因为自动修复的有效性一次又一次地被验证,并且永远有人工监督;最后,这种自动化方法可以逐步实施,而不会破坏现有流程。

Kubernetes 集群热门工具

推特上有人询问 Kubernetes 集群应该拥有的前三工具是什么。对于这个问题,有人表示每个集群应该拥有 3 个以上的工具,以下是 Kubernetes 集群上都应运行的顶级工具:

  • cert-manager:在 Kubernetes 集群上运行 cert-manager,就可以在集群中自动配置和管理 TLS 证书。
  • external-dns external-dns:可以为 k8s 集群中运行的应用程序自动创建 DNS 记录。
  • cluster-autoscaler:当所有现有资源被现有工作负载使用时,cluster-autoscaler 可以为集群添加更多节点。
  • metrics server:运行该服务可以用公开资源度量标准 API,该 API 可以使用 HPA 根据 CPU 或内存使用量扩展工作负载。
  • Nginx ingress controller:这是一个出色的即用型负载均衡器,可以快速、高质量地完成工作。

本周 K8s 开源项目推荐

Pangolin

  • 这是用于 Kubernetes 的增强型 Pod 水平自动伸缩器,可根据 Prometheus 指标扩展 Deployment。
  • github.com/dpeckett/pangolin

helm-diff

  • 这是一个 Helm 插件,可以预览 helm upgrade 将要发生的变化。
  • github.com/databus23/helm-diff

kubie

  • 它是 kubectx、kubens 的替代品,能在每个 shell 彼此独立的情况下进行上下文切换、命名空间切换和快速修改。
  • github.com/sbstp/kubie

secrets-store-csi-driver

  • 它可以通过 CSI 卷将 Secret 存储与 Kubernetes 集成。
  • github.com/kubernetes-sigs/secrets-store-csi-driver

magicpak

  • 它可以构建最小的 Docker 镜像,而无需例如 static linking 的准备工作。
  • github.com/coord-e/magicpak

hyscale

  • 它可以标准化基于容器的应用交付。
  • github.com/hyscale/hyscale

PGitHub CLI v1.0 正式发布

经过 6 个月的非常成功的 Beta 测试,近日,GitHub CLI 第一个稳定版本 v1.0 发布了。自年初测试版发布以来,用户使用 GitHub CLI 创建了超过 250000 个 pull request,执行了超过 350000 次合并,创建了超过 20000 个 issues。GitHub CLI 是一个非常有用的工具, 它可以将 GitHub 添加到终端,在终端使用命令行(CLI)管理代码项目,而不必打开网页,减少了环境切换,使我们可以集中精力,更轻松地编写脚本和创建自己的工作流。现在 GitHub CLI 已经可以在 Windows、macOS 和 Linux 上下载了。

GitHub CLI 允许开发者在终端内直接操作 GitHub 的各项功能:

  • 从终端运行整个 GitHub 工作流(从 issues 到 releases)。
  • 调用 GitHub API 编写脚本,并为任何命令创建自定义别名。
  • 除 GitHub.com 之外,还可以连接到 GitHub Enterprise Server。

https://github.blog/2020-09-17-github-cli-1-0-is-now-available/