乐趣区

关于云计算:云原生爱好者周刊Lens-50-发布更炫更快更强

云原生一周动静要闻:

  • Lens 5.0.0 公布
  • GitHub 推出 AI 编程工具 GitHub Copilot
  • Kubernetes 公布 2020 年社区年度报告
  • Weaveworks 推出实用于 Kubernetes 的集成 GitOps 平台
  • HashiCorp Boundary 0.4.0 公布
  • 开源我的项目举荐
  • 文章举荐

IT 从业人员想必都据说过 《深刻了解计算机系统》 这本神书,也就是赫赫有名的 CSAPP(Computer Systems: A Programmer’s Perspective),它将 硬件 零碎 软件 这三者联合起来,造成一个对立的框架,从程序员的视角来了解计算机系统的运作模式。

这本书也是 CMU(Carnegie Mellon University),即卡内基梅隆大学的计算机系统入门教材,CMU 还录制了讲课视频,如果感觉看书难度比拟大,能够先看一遍视频,再回过头来浏览教材,或者能够两者联合。当然,如果你的英文程度还不太现实,能够抉择观看带中文字幕的视频,视频链接在 B 站。

云原生动静

Lens 5.0.0 公布

Lens 是一个弱小的 kubernetes IDE。能够实时查看 kubernetes 集群状态,比方 Pod 实时日志查看、集群 Events 实时查看、集群故障排查等。有了 Lens,不再须要敲打很长的 kubectl 命令,只有应用鼠标点击几下,十分便捷。

Lens 为在 Kubernetes 中运行的所有内容提供残缺的态势感知。它升高了老手的进入门槛,并进步了经验丰富的人的工作效率。

这个新版本的亮点是 Catalog、Hotbars 和 Spaces。

Hotbar 当初是次要导航,容许用户从目录中筛选最重要和最罕用的性能(例如凋谢集群)并将它们调配给 hotbar。用户能够拜访多个快捷栏,在它们之间疾速切换并依据本人的爱好进行自定义以不便调用。

应用 Spaces 时,你能够抉择共享对集群的拜访权限。你还能够承受其他人的邀请以拜访他们的集群。为了实现这一点,Lens 创立了一项全新的技术:集群连贯。它容许 Lens 用户将他们的任何集群连贯到 Spaces,而无需在防火墙上启用入站端口。它利用端到端加密来爱护用户和集群之间的连贯,打消对 VPN 的需要。这意味着无需通过 Internet 公开 Kubernetes API。开发人员和运营商能够从任何中央轻松拜访和应用他们的 Kubernetes 集群。

详情见

GitHub 推出 AI 编程工具 GitHub Copilot

GitHub Copilot 不仅只是一个代码主动补全工具,其底层技术采纳了由 OpenAI 打造的新 AI 零碎——Codex,目前通过了数十亿行公开代码的训练,与大多数代码辅助工具相比,它能够了解更多的上下文。无论是文档、正文、函数名,还是代码自身,GitHub Copilot 都会基于开发者提供的上下文来合成匹配的代码。开发者可通过 GitHub Copilot 在编辑器中获取无关整行代码或残缺函数的倡议。

GitHub Copilot 运作流程如下图所示:

GitHub Copilot 官网

Kubernetes 公布 2020 年社区年度报告

受到 Apache 软件基金会的 PMC 报告凋谢指南和 CNCF 我的项目年度报告的启发,Kubernetes 我的项目发表了 Kubernetes 社区针对非凡趣味组 (SIG) 和工作组 (WG) 的年度报告。在其旗舰版中,2020 年总结报告侧重于通过评估和促成上游社区内个人的衰弱来改善 Kubernetes 生态系统。

通过这份报告,Kubernetes 心愿为最终用户社区提供信息,他们能够应用这些信息来确定他们能够反对我的项目的形式,并领先理解行将推出的性能的路线图。

详情见

Weaveworks 推出实用于 Kubernetes 的集成 GitOps 平台

Weaveworks 首席运营官 Steve George 示意,Weave GitOps 聚合了 Weaveworks 始终在推动的开源软件开发工具,使它们更易于部署和应用。

Weaveworks GitOps 产品组合的外围是 Flux,这是一种开源工具,可主动确保集群状态与存储在 Git 存储库中的配置相匹配。它在集群中应用一个称为 Flagger 的操作符来触发将应用程序部署到 Kubernetes,而无需 IT 团队获取和部署专用的继续交付平台。

Flux 监控所有镜像存储库,检测新镜像,触发部署并相应地更新配置。在该外围平台之上,Weaveworks 增加了 Team Workspaces,这是一个工作流应用程序,用于跟踪对基于 Git 的部署的更改,可供多个 DevOps 团队应用。每个工作区还能够逾越多个 Kubernetes 集群,以简化跨 Kubernetes 集群队列的应用程序部署。

详情见

HashiCorp Boundary 0.4.0 公布

HashiCorp Boundary 是基础设施网格,使开发人员、DevOps 和 SRE 能够应用细粒度的受权来平安地拜访基础设施服务(SSH 服务器、Kubernetes 集群),而无需间接拜访网络,同时又禁止应用 VPN 或堡垒主机。

会话证书代理:HashiCorp Boundary 0.4.0 减少了一个 Vault 集成,用于将 Vault 机密代理到 Boundary 客户端(命令行和桌面客户端)以用于 Boundary 会话。

Vault 秘密的代理是 Boundary 更大的凭证治理故事的根底,用于无缝单点登录到基础架构指标。此性能引入了新的边界资源 - 凭证存储、凭证库和凭证 - 以反对将凭证与用户会话绑定,以及在命令行和 Boundary Desktop 中的会话初始化期间显示这些凭证。

boundary connect 凭证代理集成:此外,咱们曾经开始集成到边界连贯助手中,在这个版本中从 Postgres 助手开始;如果凭据蕴含用户名 / 明码并且边界连贯 postgres 是正在应用的帮忙程序,则该命令将主动将凭据传递给 psql 过程。

会话平安改良:边界工作人员当初将在他们无奈向工作人员收回状态申请时敞开他们正在解决的任何现有代理连贯。此行为的超时以后为 15 秒。

详情见

开源我的项目举荐

eBPFSnitch

eBPFSnitch 是基于 eBPF 的 Linux 防火墙程序,eBPF 想必大家都晓得是啥,这里就不赘述了。想用 eBPF 代替 iptables 作为防火墙还是有很大挑战的,每加一条规定就须要进行编码,极其不便,最好是能通过命令来增加和批改规定。有几个我的项目对这个方向进行了尝试,但曾经很久不更新了,这里就不介绍了。eBPFSnitch 这个我的项目提供了一个 GUI 来增加和批改防火墙规定,惋惜的是目前还没有命令行版本。

missing-container-metrics

Kubernetes 默认状况下应用 Cadvisor 来收集容器的各项指标,足以满足大多数人的需要,但还是有所欠缺,比方短少对以下几个指标的收集:

  • OOM kill
  • 容器重启的次数
  • 容器的退出码

    missing-container-metrics 这个我的项目补救了 Cadvisor 的缺点,新增了以上几个指标,集群管理员能够利用这些指标迅速定位某些故障。例如,假如某个容器有多个子过程,其中某个子过程被 OOM kill,但容器还在运行,如果不对 OOM kill 进行监控,管理员很难对故障进行定位。

podman-static

Podman 是 Red Hat 开源的容器运行时我的项目,它的性能与 Docker 简直重合,甚至还有很多新增的性能,它与 Docker 等容器运行时最大的差别是不须要运行守护过程。

默认状况下,Podman 是不提供动态二进制文件的,你须要装置残缺的依赖能力失常应用,而且只反对特定几个发行版,其余发行版须要本人从头编译。podman-static 这个我的项目就是为了解决这个问题,它提供了 Podman 及其依赖的动态二进制文件,你只须要拷贝这几个二进制文件就能让 Podman 失常工作。想想你的 Openwrt 吧,这个我的项目就是你的救星。

FirefoxPWA

PWA 是渐进式网络应用程序(Progressive Web Apps)的缩写,旨在为跨平台的 HTML 网页带来相似于本地利用的用户体验,由 Google 在 2015 年推出。目前只有局部基于 chromium 内核的浏览器反对 PWA,FireFox 默认状况下是不反对的。FirefoxPWA 这个我的项目就是为了让 FireFox 反对 PWA,惋惜目前还不反对 macOS,感兴趣的能够急躁期待一下。

文章举荐

为什么 Kubernetes 抉择了 ETCD?

本文从源码的角度分析了 Kubernetes 抉择 ETCD 的劣势,蕴含以下几个方面:

  • EtcdServer 的工作原理
  • bbolt 的工作原理
  • 数据是如何长久化到 ETCD 中的
  • MVCC 的原理

如何将 eBPF 增加到可观测性产品中

这篇文章是驰名的性能巨匠 Brendan Gregg 的最新博文,探讨了如何疾速将 eBPF 增加到商业可观测性产品中。

通过机器学习来优化 Kubernetes 中的利用

随着互联网利用架构的一直变更,通过手动的形式来优化 Kubernetes 上的利用是极其简单的,须要大量的测试和监控工作,占用了无尽的工程工夫。本文尝试通过机器学习来解决这个问题。

本文由博客一文多发平台 OpenWrite 公布!

退出移动版