2020 年 11 月 2 日,原 CNCF 执行董事 Dan Kohn 辞世。

2020 年 11 月 2 日,Mr. Dan Kohn 被癌症夺去了生命,永远离开了我们,对中国开源社区,我们失去了一位真正的朋友和英雄,对 LF APAC,我们失去了一位战友和导师。Dan 每年都会多次来到中国,并且不遗余力地帮助中国开源项目走向全球,在 Dan 的强力支持下,CKA 和 LF 的培训得以落地中国,并培养了一大批开源人才。LF 计划为 Dan 两名未成年的孩子发起教育基金,有进一步消息我们会跟大家及时分享。让我们永远怀念这位全心全意帮助中国开源发展的英雄!感谢!Linux Foundation APAC Team

在担任 CNCF 执行董事期间,Dan Kohn 一直致力于云原生技术的推广,积极参与开源社区建设。Dan 的妻子也表示他最自豪的成就是为云原生基金会协调开发者社区。

Dan 曾担任 Linux 基金会的首席运营官,帮助启动 Linux 基金会的“核心基础设施计划”(Core Infrastructure Initiative),该计划旨在资助和支持对互联网至关重要的开源软件项目。

此外,Dan 还领导了 Linux 基金会的公共卫生计划,并使用开源软件来帮助公共卫生部门应对 COVID-19 和其他流行病。

现在这位伟大的开源领袖永远离开了我们,沉痛悼念!

Grafana 发布 Loki v2.0 和 Tempo

近日,Grafana Labs 发布了多项产品更新,除了日志记录平台 Loki 进入 2.0 版本外,还发布了一个全新的开源大规模可扩展的分布式追踪系统 Grafana Tempo。Loki 是一个开源的日志记录平台,可以让开发人员简单且高效地管理日志。Loki v2.0 朝着提高性能以及减少依赖性前进。新版本中,用户可以转换日志,并提取额外的标签,以实现额外的过滤和分组。另外 Loki v2.0 提供了新的查询工具,用户可以跨任何格式转换日志,包括 JSON 日志格式以及结构化与非结构化日志,Loki 都能进行规范化,以直接进行复杂的查询,而且不需要提前定义标签或是将标签存储在资料库中。

Loki v2.0 地址:github.com/grafana/loki/releases/tag/v2.0.0

至于 Grafana Tempo,Grafana 实验室产品副总裁 Wilkie 表示,Loki 和 Tempo 的目的都是为了降低实现可观察性的障碍。Grafana Tempo 支持 Loki 和开源的 Prometheus 监控平台所采用的相同的 Tempo 数据发现引擎,以及建立在 Prometheus 之上的 Grafana 平台。Tempo 还可以与任何开源跟踪协议一起使用,包括 Jaeger、Zipkin 和 OpenTelemetry,该平台的用户可以轻松地从日志跳转到跟踪,再跳转回来。

Grafana Tempo 地址:grafana.com/oss/tempo

社区热议 Kubernetes 发布频率

近日,Kubernetes 社区在讨论是否要修改 Kubernetes 的发行频率。在推特上一项共有 709 位参与者的民意调查中,有 59.1% 的人选择了每年应该发布三个版本。

投票地址:twitter.com/stephenaugustus/status/1305902993095774210?s=20

这里总结了一些社区人员的看法,有人认为每年发布 3 个版本足够了:

  • 这意味着可以给实际功能开发更多的时间。
  • 从终端用户的角度来看,这可以减轻团队的负担,以跟上有关的升级和管理工作。
  • 随着越来越多复杂工作负载转移到 Kubernetes 上,一年内进行较少的升级有助于稳定。

而有些人认为每年需要发布 4 个版本:

  • 可以将第四个版本定位为错误修复、测试和稳定性的版本。
  • 保持每季度发布一个版本可以让开发者保持警惕,避免懈怠。

社区讨论地址:github.com/kubernetes/sig-release/issues/1290

Linkerd 发布社区主播计划

一个项目之所以能成功,是因为人们每天都在使用并和它一起工作。讨论我们正在解决的问题可以帮助比我们想象得更多的人。我们的经验,可能看起来很一般,但可以为其他人节省数周甚至数月的努力。虽然我们都在使用容器、Kubernetes 等云原生技术,但还有很多人对此并不熟悉。

Linkerd 社区推出社区主播计划(Linkerd Community Anchor),旨在推广大家的 Linkerd 故事和经验。无论是想在会议或聚会上分享,或者以博客文章、视频教程的形式,Linkerd 团队都会在整个过程中进行指导和支持。

报名地址:linkerd.io/community/anchor

Linkerd 是一个提供弹性云端原生应用服务网格(service mesh)的开源项目,也是面向微服务的开源 RPC 代理,现由 CNCF 管理。Linkerd 是一个透明的服务网格,旨在通过透明地将服务发现、负载均衡、故障处理,插桩(instrumentation)和路由添加到所有的服务间通信中,使现代应用程序安全可靠,而无需侵入应用内部本身的实现。

项目地址:linkerd.io

解决 Pod 故障的 5 个技巧

在很多情况下,我们可能发现 Kubernetes 中的应用程序没有正确部署,或者没有正常工作。其实 Pod 失败的原因一般有两个:

  • Kubernetes 资源配置错误,例如 Deployment 和 Service 里。
  • 代码中的问题。

在第一种情况下,容器一般不会启动。在第二种情况下,应用程序代码会在容器启动后失败。以下是了解并解决故障的几个技巧:

检查 Pod

我们需要确认Pod处于运行(Running)状态或准备就绪(Ready)的状态:kubectl get pods这里介绍一些在容器启动失败时常见的错误情况,如下:

  • Imagepullbackoff:Docker 镜像仓库不可访问,Deployment 中指定的镜像名称或版本不正确。确保镜像名称是正确的,并且镜像仓库是可访问的以及经过身份验证的(docker login…)。
  • RunContainerError:可能缺少 ConfigMap 或 Secrets。
  • ContainerCreating:容器创建时一些组件无法立刻启用,例如持久卷等。

检查 Pod 的相关事件

如果在 Pod 状态上看到一个错误代码,我们可以使用 describe 命令获得更多信息:kubectl describe frontend-65c58c957d-f4cqn

检查日志(Log)

现在容器已经启动,可以通过检查日志来查看应用程序是否正常运行,例如 Pod frontend-65c58c957d-bzbg2:

kubectl logs --tail=10 frontend-65c58c957d-bzbg2

实时滚动查看一个正在运行的日志:

kubectl logs -f frontend-65c58c957d-bzbg2

如果 kubectl logs 后没有任何输出,试试使用 get pod,这很有可能是一个新启动的 Pod,因此可以尝试检查一些上一次挂掉的 Pod 的日志:

kubectl logs frontend-65c58c957d-bzbg2 --previous

直接在 Pod 中运行 “sh”、“bash” 或 “ash”

可以进入到 Pod 内部并运行命令来对应用程序进行故障排除(输入 exit 即可退出):kubectl exec -it frontend-65c58c957d-bzbg2 /bin/sh

显示集群级别的事件

Kubernetes 在它管理的资源状态发生变化(正常、警告等)时触发对应的事件。这能帮助我们了解背后到底发生了什么。get events 命令能提供事件的聚合透视图。

本周 K8s 开源项目推荐cass-operator

  • 这是适用于 ApacheCassandra 的 DataStax Kubernetes Operator。
  • github.com/datastax/cass-operator

Gemini

  • 它用于在 Kubernetes 中自动备份 PersistentVolumeClaims。
  • github.com/FairwindsOps/gemini

Ktunnel

  • 它是一个 CLI 工具,可在 kubernetes 集群和本地计算机之间建立反向隧道。
  • github.com/omrikiei/ktunnel

kubectl-reap

  • 这是一个 kubectl 插件,可删除未使用的 Kubernetes 资源。
  • github.com/micnncim/kubectl-reap

Kubetail

  • 这是一个小型的 Bash 脚本,它允许将来自多个窗格的日志聚合到一个流中。
  • github.com/johanhaleby/kubetail

kubectl-aliases

  • 这是一个脚本,可以为 kubectl 生成数百个方便的 shell 别名。
  • github.com/ahmetb/kubectl-aliases