周一见 | 本周开源项目推荐、著名程序员一般工作到几点?如何从 GitHub 托管 Helm repo
新闻
作者: K8sMeetup社区
译者: K8sMeetup社区
2019-07-22 18:40

Kubernetes 资讯 

1. 本周 K8s 开源项目推荐 

以下是本周社区筛选的 Kubernetes 开源项目:

Nuclio

Nuclio 是一个基于 Kubernetes 的开源无服务器平台,它源自 Iguazio 的弹性数据生命周期管理服务,可用于高性能事件和数据处理。该项目专注于:高吞吐量数据处理流水线或 ETL;实时提供机器学习模型;多人游戏等实时应用。

详情请见:https://github.com/nuclio/nuclio?utm_sq=g3rzlg7sgg

torrent

torrent 是一个 Kubernetes 日志工具。它不仅可以收集容器标准输出,还可以收集 Kubernetes 容器内的日志文件。

详情请见:https://github.com/Rand01ph/Torrent?utm_sq=g3rhtpf1p7

wardroom

wardroom 是一个用于创建基于 Kubernetes 的基本操作系统镜像的工具,它主要有两项功能:

  • Image Building:使用 Packer 和 Ansible 构建基于 Kubernetes 的基本操作系统镜像;
  • Deployment Orchestration:基于 Ansible 的编排,使用 kubeadm 部署高可用 Kubernetes 集群。

详情请见:https://github.com/heptiolabs/wardroom?utm_sq=g3rbbagi95

Kubecos

tKubecost 是一个可以帮助开发者了解当前和历史 Kubernetes 支出和资源分配,以减少支出并防止基于资源的中断的工具。

详情请见:https://github.com/kubecost/cost-model?utm_sq=g3p6l3k21u

Kubit

Kubit 是一个用于管理多个 K8s kubeconfigs 的 CLI 工具。它可以帮助开发者在同一台机器上管理多个 Kubernetes 配置,工作方式类似于 Zsh 中的 wd 实用程序。

通过 kubit add,你可以将一个简单的标签耦合到 kubeconfig 文件的位置;通过 kubit use,你可以将 KUBECONFIG 环境变量设置为正确的值。

详情请见:https://github.com/vbsteven/kubit/?utm_sq=g3ozn85212

Kboom

Kboom 是一个简单的 Kubernetes 负载测试工具,可用于可扩展性测试和浸泡测试。例如,当使用 Kboom 进行可扩展性测试时,你可以看看可以放置多少 Pod 以及需要多长时间。

详情请见:https://github.com/mhausenblas/kboom?utm_sq=g3n7hrctdk

2. 如何从 GitHub 托管 Helm repo 

Helm 是 Kubernetes 常用的包管理器,提供很多开箱即用的 Charts。在使用过程中,管理自定义 Charts 的一种方法是将源保留在某个目录中,然后通过引用目录来使用此类 Charts。但这种方法仍有缺陷,比如版本控制和工具要求

我们知道,Helm repo 托管的是打包 Charts 文件和指向它们的 index.yaml。其中 index.yaml 还存储有关 repo 的元数据。因此,我们可以通过 GitHub 来托管这些文件。

首先,创建私有 GitHub repo,然后推送一些文件:

为了让 Helm 能够从这样的 repo 中提取文件,我们需要为它提供 GitHub 用户名和令牌:

最后,将新包添加到现有 repo:

  • 将新包放入 repo 根目录;
  • 运行 helm repo index,这将检查新文件并更新 index.yaml;
  • 提交、推送新包并更新 index.yaml;
  • helm repo update。

安全说明:这里最重要的是要意识到 Helm 实际存储 GitHub 令牌的位置。它以纯文本形式存储在 ~/.helm/repository/repositories.yaml,建议各位读者使用尽可能少的权限生成令牌。

3. Kubernetes v1.16 将删除被弃用的 API 

随着 Kubernetes API 的发展,API 会定期进行重组或升级,旧的 API 将被弃用,并最终被删除。根据最新版本的信息,Kubernetes v1.16 将对以下四种服务的 API 做一些调整

  • NetworkPolicy 将不再从 v1.16 中的 extensions/v1beta1 提供服务,而是迁移到从 v1.8 开始提供的 networking.k8s.io/v1 API。现有的持久化数据可以通过 networking.k8s.io/v1 API 检索、更新;
  • PodSecurityPolicy 在 v1.16 中将不再从 extensions/v1beta1 提供服务,而是迁移到从 v1.10 开始提供的 policy/v1beta1 API。现有的持久化数据可以通过 policy/v1beta1 API 检索、更新;
  • DaemonSet、Deployment、StatefulSet 和 ReplicaSet 在 v1.16 中将不再从 extensions/v1beta1、apps/v1beta1 或 apps/v1beta2 提供服务,而是迁移到从 v1.9 开始提供的 apps/v1 API。现有的持久化数据可以通过 apps/v1 API 检索、更新;
  • Ingress 在 v1.16 中将不再从 extensions/v1beta1 提供服务,而是迁移到 networking.k8s.io/v1beta1 API。现有的持久化数据可以通过 networking.k8s.io/v1beta1 API 检索、更新。

这些资源目前都不会从 Kubernetes 中删除,也不会以任何方式被弃用。但是,如果开发者想要继续使用这些资源,就必须使用 Kubernetes API 的当前版本。具体迁移细节,请见:《用户须知:Kubernetes v1.16 将删除被弃用的 API》。

 4. Kubernetes 的一些基本事实 

Kubernetes 是一个集群编排系统,可用于在容器环境下构建分布式应用程序。近年来,K8s 从一个小型开源 Google 项目迅速崛起为 CNCF 的主要项目,虽然许多组织和公司正在通过它自动化容器化应用程序的管理,但是人们对它的认知还存在很多问题。

K8s 与 Docker Swarm 的区别

Kubernetes 和 Swarm 主要有以下区别:

  • Kubernetes 开发速度更快,市场份额更高(K8s 占 51%,Docker Swarm 占 11%);
  • Docker Swarm 的可扩展性较低,而且没有内置的负载均衡支持;
  • K8s 具有这种支持,它为内部和外部负载均衡提供内置实现,其中内部均衡由 Service 对象提供,外部负载平衡由 NodePort 以及内置的 LoadBalancer 原语提供;
  • Docker Swarm 不支持 Auto-Scaling,既不支持自动扩展容器,也不支持自动扩展节点;
  • Kubernetes 支持所有可能的自动缩放器:Vertical Pod Autoscaler 、Horizontal Pod Autoscaler,以及基于 Cluster AutoScaler 的集群本身自动缩放(节点数);
  • Docker Swarm 在监控方面存在困难,开发者只能在专有工具的帮助下监控容器;
  • Docker Swarm 本身不支持有状态应用程序的持久存储;
  • Docker Swarm 仅适用于 Docker 容器,而 K8s 有许多容器运行时选项,例如 Docker、Rocket、ContainerD 等。

K8s 与 OpenStack 相比如何?

Kubernetes 旨在管理容器编排,而 OpenStack 最初设计用于管理虚拟机。换句话说,OpenStack 用于管理传统虚拟基础架构,而 Kubernetes 则用于容器化。

两者都是由社区开发的开源系统,不同的是,K8s 的前身是 Google 的 Borg,即便是第一个版本,它就已经做到功能丰富且相当稳定。而 OpenStack 几乎从头到尾就是由社区开发的,版本众多,相对分散。

如果做类比,K8s 更像 Apple,而 OpenStack 更像是 Android。企业在生产环境中部署 Kubernetes 的成本和时间会远远低于 OpenStack。

K8s 如何简化容器化部署?

Kubernetes 简化容器化应用部署离不开它以下几个优点:

  • Kubernetes 有内置的服务发现。换句话说,当出现新服务时,K8s 会为其分配唯一的域名,其他服务可以在 etcd 中获取有关此服务的信息;
  • Kubernetes 为支持容器化应用的不同部署策略提供了灵活的清单。如它为 A/B 测试提供了金丝雀部署支持,具备内置的健康检查和基于 Prometheus 的监控;
  • Kubernetes 使用滚动更新策略来推出 Pod 版本更新。滚动更新策略会在执行更新时随时保持某些实例正常运行,有助于保护应用程序免于停机。

AI 资讯 

1. BERT 跌落神坛 

自发布以来,BERT 凭借在 11 项 NLP 任务中夺得 STOA 结果,一直被业界视为谷歌最强 NLP 模型。但日前,台湾省两名学生发表的一篇论文《Probing Neural Network Comprehension of Natural Language Arguments》,却指出 BERT 的成功或许只是利用了虚假的统计学线索后的假象

在论文摘要中,作者表示:我们惊讶地发现 BERT 在 ARCT 任务中的峰值性能高达 77%,仅比平均未经训练的人类基线低 3 个点。但是,我们表明这个结果完全是通过利用数据集中的虚假统计线索来解释的。我们分析了这些线索的性质,并证明一系列模型都在利用它们。

ARCT 是一种考验语言模型推理能力的阅读理解任务。在这个任务中,AI 要根据一个给定的观点,在两个选项里找出正确的佐证。虽然 BERT 的性能在数据上很惊艳,但经过对 AI 眼中容易分类的数据点的观察、分析,作者发现“Not”“Is”“Do”“Are”这些线索词对 AI 输出有明显影响。如果没有这些词,利用虚假统计线索的模型的表现还不如一般模型。

简而言之,BERT 并不能真正分析出句子之间的逻辑关系,它只是找到了数据集的 pattern,钻了空子。

对于这个结果,不少人表示收获颇多。在学界,BERT 等模型给学者们指明了一条利用数据通往成功的路,如今它陨落了,也把更多人从对数据的盲目信服中解救出来,毕竟机器学习不应只是“统计机器学习”,人类距离真正的人工智能还需要付出更多努力。

其他

1. 那些著名程序员一般工作到几点 

从 996 ICU 到 10x 工程师,程序员的工作时间成了上半年全球的一大热点话题。上周,俄罗斯程序员 Ivan Bessarabov 从 GitHub 代码提交时间入手,分析了 Linux 之父、Python 之父、Golang 作者等知名程序员的工作时间。

Linus Torvalds 是 Linux 操作系统的作者、git VCS 的作者和 Subsurface 的作者。如上图所示(第一列时间,第二列代码数),他的代码提交时间总体非常正常,主要集中在常规工作时间段。

Sebastian Riedel 是两个流行的 Perl 框架的作者:Catalyst 和 Mojolicious。他的工作安排很疯狂,羡慕他的生产力。

Chris Lattner 是 LLVM 编译器和 Swift 的作者。他在Apple、特斯拉工作过,现在在 Google,看起来像个十足的夜猫子。

Rob Pike 最新的项目是 Go 语言,他的代码提交时间非常“朝九晚五”。

Guido van Rossum 是 Python 之父,下午和晚上是他工作效率最高的时候。整份调研融合了提交时间和合并时间,并对周末的工作情况做了单独统计。

总体来看,这些图表主要有两种形状:日行族和夜行族。虽然文章统计的时间和真正的工作时间不完全吻合,但这也算是一个好的观察角度。

你的产能图像是什么样的呢?

1220 comCount 0