1CNCF 宣布 K8s 论坛日程

上周,CNCF 公布了首届 Kubernetes 论坛的日程安排,论坛将于今年 12 月 9 日至 10 日在韩国首尔举行12 月 12 日至 13 日在澳大利亚悉尼举行

届时,来自三星、SK 电信、康泰纳仕国际、微软和 Atlassian 等公司的 Kubernetes 贡献者将登台发表 29 场演讲,主题覆盖技术演示和最终用户体验。

对此,CNCF 执行董事 Dan Kohn 表示:我们很高兴地宣布,第一届 Kubernetes 论坛将在首尔和悉尼举行。这是 CNCF 的一项新举措,将本地和国际专家聚集在一起,与全球社区分享他们的专业知识。

详见(events19.linuxfoundation.org/events

2Ubuntu 19.10 新增 K8s 边缘功能

经过 25 周的开发,上周 Canonical 发布了 Ubuntu 19.10,亮点包括 Kubernetes 的新边缘功能,集成 AI 开发人员体验以及迄今为止最快的 GNOME 桌面性能

Ubuntu 19.10 对 MicroK8 进行了严格限制,以确保完全隔离和高度安全的生产级 K8s 环境。MicroK8 的附加组件,例如 Istio、Knative、CoreDNS、Prometheus 和 Jaeger,现在可以通过单个命令部署在边缘。

此外,由才云科技、谷歌、红帽等企业推出的 Kubernetes + AI 开源项目 Kubeflow 现在也可作为 MicroK8 的附加组件使用,以改善 AI 和机器学习功能。开发人员可以在几分钟内、设置、开发、测试和扩展其生产需求。MicroK8 也可以开箱即用地进行 Kubeflow 和 GPU 加速。

详见(ubuntu.com/download/desktop

3两个新修补的 K8s 漏洞

上周,Kubernetes 补丁发布团队为修补漏洞 CVE-2019-16276 和 CVE-2019-11253 发布了新版本。这两个漏洞在过去一个月内被披露,并在某些设置下可能对集群安全造成严重威胁。

CVE-2019-16276

这个漏洞的根源是 Golang 的标准 HTTP 库 net/http,该库主要用于 K8s 中的 HTTP 请求解析。

众所周知,HTTP 请求由一个字段名、一个冒号、它的值组成,根据 HTTP/1.1 规范,标头的字段名称和冒号之间不允许有空格,但 net/http 库把带有空格的标头视为有效标头

当依赖库的 Go 服务器与过滤请求标头的反向代理结合使用时,这个看似无害的问题会变得很危险:代理可能会忽略无效的标头,但会将其转发到 Go 服务器,后者会将这些标头解释为有效。

CVE-2019-11253

月前,Stack Overflow 的一位用户发现 Kubernetes API 服务器容易受到针对 YAML 解析器的一种特定类型的攻击,称为“YAML 炸弹攻击”,也称“Billion laughs attack”。

该漏洞旨在通过对 YAML 解析器进行指数加载,从而使其崩溃。漏洞被发现时,团队曾发布过一个补丁,但他们没意识到此漏洞的真正罪魁祸首是 YAML 分析器库补丁程序,近日,他们又发布了一个补丁,在 go-yaml 库级别解决了这个问题。

综上所述,无论你的 Kubernetes 配置如何,社区强烈建议你升级到 Kubernetes 内部版本 1.14.8、1.15.5 或 1.16.2,以避免上述漏洞。

4在生产中部署微服务的六个步骤

微服务在促进模块化应用程序设计、提高灵活性方面的建树是行业有目共睹的。考虑到业界目前还没有关于在生产环境部署微服务架构的通用介绍,谷歌、亚马逊和 Netflix 的工程师经过归纳总结,认为企业 DevOps 团队在准备微服务部署时应注重解决以下六大问题。

将云服务用于生产基础架构

简而言之,比起传统 IT 架构,企业更应在云中构建和部署微服务。微服务旨在将应用解耦成离散的、可独立扩展的组件,而云服务则是将基础资源或企业应用封装为按需服务——成本更低,也更容易解耦,因此更有利于微服务部署。

提前准备好故障设计

微服务架构是解耦和分布式的,这意味着各个应用程序组件具有许多依赖性,但都能相互独立运行。对此,企业提前准备好应对故障的方案,例如,微服务必须将服务器(或容器节点)视为可以独立停止、重新启、自动扩展和修补的无状态实体。应用程序必须容忍微服务组件的故障,并从组件级故障中恢复。

分散数据管理

为提高运营效率、简化管理,企业数据中心通常会把数据库和存储卷整合到几个系统上。考虑到有时几个微服务应用程序团队可能会共享同一数据库,更改时势必会很麻烦,因此这种整体性的方案并不适合微服务设计。为了解决这个问题,开发人员可以通过使用云平台挑选最佳数据库,同时灵活地更改和更新数据库架构。

分配治理

传统意义上,企业 IT 组织通常在功能孤岛中运作——独立的存储、网络、数据库,乃至独立的开发、运维和服务器团队——每个孤岛只处理整个应用程序生命周期的一部分。企业在采用微服务时应该颠覆这种结构,用具有 DevOps 文化和敏捷开发实践的跨职能微服务团队取代 IT 孤岛。

自动化基础架构部署,采用 CI/CD 流程

如前一条所述,微服务在敏捷的 DevOps 环境中蓬勃发展依赖于快速、无摩擦的过程。为了避免团队摩擦,Netflix 建议企业加速构建流程自动化,同时使代码处于相似的成熟度,并为每个微服务使用单独的内部版本。

从一开始就进行监控、记录和故障排除

微服务通常会触发一系列事件,从而导致应用程序失败。为了最大程度地减少故障,请将监视和故障排除纳入微服务设计中。

5本周 K8s 开源项目推荐

kubeman

github.com/walmartlabs/kubeman

尽管 kubectl 是使用 Kubernetes 集群的必备工具,但在调查与 Kubernetes、Istio 相关的复杂问题时,它还是很麻烦。该工具旨在通过执行相关的交叉引用和相关信息分析来简化此类任务。

kubectl-eksporter

github.com/Kyrremann/kubectl-eksporter

这是一个简单的 Ruby 脚本,用以导出 K8s 资源(Python 没有内置的 yaml-converter,Go 在需要通用数据结构时也很麻烦)。

ksniff

github.com/eldadru/ksniff

使用微服务时,很多时候捕获微服务及其依赖关系之间的网络活动非常有帮助。这一个 kubectl 插件,它利用 tcpdump 和 Wireshark 可在 Kubernetes 集群中的任何 Pod 上启动远程捕获。

kone

github.com/IBM/kone

这是一个用于将 Node.js 应用程序构建和部署到 Kubernetes 的工具。

loghouse

github.com/flant/loghouse

这是一个现成的 Kubernetes 日志管理解决方案。它能有效地存储大量日志,使用简单的查询语言对其进行处理,并通过 Web UI 在线对其进行监控。

kubesec

github.com/shyiko/kubesec

这是一个 Secret 安全管理工具,它允许你加密 Secret,以便可以将它们与其余资源一起存储在 VCS 中。

6OpenEBS 的一些技巧

对于任何 Kubernetes 初学者,存储会是他们花费大量时间进行反复测试的一大领域。在开源社区中,Rook、Longhorn 和 OpenEBS 是大家比较常用的解决方案

月前,国外工程师 Vito Botta 对上述方案做了数周测试,认为 Rook 总体上是一个可靠的选择,但偶尔存在稳定性问题;Longhorn 有着美观的 UI,管理起来也很轻松,但 CPU 使用率仍然太高;Portworx、StorageOS 等闭源产品价格昂贵,普通工程师难以负担。相比之下,OpenEBS 似乎是最佳选择

详见(vitobotta.com/2019/07/03/openebs-tips

7PyTorch & TensorFlow NLP 测评关于 PyTorch 和 TensorFlow 孰优孰劣这件事,算法工程师们一直没有停止过争论。最近一位工程师就推理速度,用 Transformer 模型(NLP)在两大平台上进行了测试

测试条件如下:

  • CPU 推理:使用谷歌云平台上的 n1-standard-32 硬件;
  • GPU 推理:使用谷歌云平台上的定制化硬件;
  • 推理时间:用本地 Python 模块 timeit 测量;
  • 数值取法:每个实验重复 30 次,对这 30 个值取平均值;
  • Batch Size 分别设置为 1、2、4、8;
  • 序列长度为 8、64,、128、256、512、1024。


测试结果如上图所示。在大多数情况下,这两个平台都能获得相似的结果。与 PyTorch 相比,TensorFlow 在 CPU 上通常要慢一些,但在 GPU 上要快一些。而 PyTorch 模型比 TensorFlow 模型更容易耗尽内存

medium.com/huggingface/benchmarking-transformers-pytorch-and-tensorflow