周一见 | GitLab 事件后续:辞职、Vitess 毕业、Kubernetes 集群正在增加
新闻
作者:才云 Caicloud
译者:bot(才云)
2019-11-11 15:20

1CNCF 宣布 Vitess 毕业

11 月 5 日,CNCF 宣布 Vitess 毕业,这是继 Kubernetes、Prometheus、Envoy、CoreDNS、containerd、Fluentd 和 Jaeger 之后的第八个毕业项目。

Vitess 最初是 YouTube 在 2010 年创建的一个内部解决方案,用于使用 MySQL 扩展大量存储,是一个云原生数据库系统。2018 年,它成为 CNCF 孵化项目,借助在 YouTube 和其他组织中的大量实战,它被证明能有效降低组织使用 MySQL 作为云原生的门槛,帮助团队增长在可伸缩管理和弹性数据库领域的技术知识和实力。

除了支持 Kubernetes,Vitess 还集成了包括 etcd、gRPC 和 Prometheus 在内的其他云原生项目。GitHub、京东、Pinterest、Slack 等公司都在不同的生产和部署阶段使用过 Vitess。

在上周新发布的 4.0 版本中,Vitess 提高了对 SQL 查询的支持,改进了可用性,并增加对 VReplication 的实验支持。

github.com/vitessio/vitess

2调查发现 Kubernetes 集群正在增加

近日,国外一家实验室发布了对 1106 位 IT 专业人士的调查结果,发现企业开始加快部署 Kubernetes 集群

该调查发现:

  • 91% 的受访者在混合环境中运行一个以上 Kubernetes 集群;
  • 运行多个集群的主要原因是工作负载/租户隔离(70%),其次是团队自治(48%);
  • 85% 的受访者表示他们在生产环境中运行容器;
  • 91% 的受访者表示正在使用 Kubernetes 进行容器编排;
  • 71% 的受访者正在运行本地工作负载;
  • 67% 的受访者正在运行基于云的应用程序;
  • 容器和 Kubernetes 采用的主要推动力是 IT 架构师、开发人员和 DevOps 团队
  • 容器最常见的用例是内部应用程序(73%)、设计微服务(71%)和构建面向客户的应用程序(70%)。

报告指出,随着越来越多的组织采用多个 Kubernetes 集群,大规模管理集群所带来的挑战已开始显现。构建一个 Kubernetes 集群很容易,但一旦这些集群开始成倍增长,那么组织对于实施最佳 DevOps 实践的需求就会变得更加明显。

在许多情况下,Kubernetes 的采用将迫使组织加快其发展 DevOps 文化。同时,随着 Kubernetes 集群的增加,IT 领域又出现了一个新问题:Kubernetes 会不会太普遍了,以至于被滥用?

3红帽在 Kubernetes 上推进 Java

上周,红帽宣布 Quarkus 项目开源,被业界视为使 Java 实例可用于 Kubernetes 的第一个里程碑。在容器环境中,Docker 容器和 Kubernetes 解决了代码可移植性问题,这为缩小 JVM 和使 JVM 上运行的 Java 应用运行得更快提供了机遇

Quarkus 提供了对 Java 框架和库的支持,在最新版本中,它增加了对反应式编程模型的支持,为 Java 程序实现了一个全新的非阻塞安全层,改进了与 API 框架的兼容性,并增加了对 Java 8、11 和 13 的支持。

鉴于使用 Java 构建企业应用程序的开发人员数量众多,随着云原生趋势越来越明显,将云原生平台与 Java 紧密集成开始变得非常有必要。

除了红帽,以 Jakarta 的形式监督 Java 开发的 Eclipse 基金会也已经开始努力将 Che 集成开发环境(IDE)引入 Kubernetes

4本周 K8s 开源项目推荐

kubeterminal

github.com/samisalkosuo/kubeterminal

这是 Kubernetes 的帮助工具,旨在提供一个简单快速的工具来使基础知识脱离 Kubernetes 环境。它是 kubectl 和 shell 的补充而不是替代品。

k8s-netchecker-server

github.com/Mirantis/k8s-netchecker-server这是一个基本的网络检查器服务,用于检查 Kubernetes 集群中的 DNS 和连接。

machine-controller

github.com/kubermatic/machine-controller

这是一个 Kubernetes 操作符,可以与大多数云供应商 API 交互,为集群创建更多的节点。

kubeselect

github.com/fatliverfreddy/kubeselect

这是一个小助手,它允许开发者通过一个简单的命令使用箭头键选择一个可用的 Kubernetes 上下文,而不是用两个单独的 kubectl 命令来显示、选择上下文。

kruise

github.com/openkruise/kruise

这是一组控制器,可扩展和补充 Kubernetes 核心控制器上的工作负载管理,实现自动化应用程序工作负载管理。

hkube

github.com/kube-HPC/hkube

这是一个云原生的开源框架,可运行基于 Kubernetes 构建的分布式算法管道,根据用户优先级和试探法,最佳利用管道资源。

5谷歌发布自动化 K8s 工具 Skaffold

上周,谷歌发布了开源工具 Skaffold 的第一个正式版,它能简化开发者进行 Kubernetes 开发时需要执行的常见操作任务

Kubernetes 已成为企业容器环境的重要组成部分,因为它可以自动执行、设置和管理集群有关的许多任务。但是,对部署进行更改并不简单:每次工程师希望推出更新时,他们都必须重新配置文件并执行其他耗时的调整。

但借助 Skaffold,开发者可以在机器上分析代码,迅速找出对 Kubernetes 环境要进行的调整,然后自动部署更新。与传统的应用程序环境相比,它能使程序员更高效地发布新代码,使自动化变得更加有价值。

该工具可与其他 Kubernetes 自动化解决方案一起使用,并在用户的本地计算机上运行,这意味着开发人员无需在其容器集群上安装任何其他组件。

github.com/GoogleContainerTools/skaffold

6GitLab 封锁事件后续

上周,GitLab 被曝将针对有权访问客户数据的团队进行“工作家庭国家/地区封锁”,即禁止招聘中国、俄罗斯的程序员担任网络可靠性工程师等职位,并禁止可访问客户数据的已有雇员移居至中国和俄罗斯。

事件发生后,GitLab 全球风险与合规总监 Candice Ciresi 已辞职。虽然她拒绝就此事发表意见,但根据其发布的帖子内容,Ciresi 指责 GitLab 存在歧视性和报复性的行为。目前这则帖子已被删除。

三周前,Ciresi 曾针对封锁声明质疑为什么 GitLab 要将中国和俄罗斯单独列出来,因为没有法律禁止企业在这些国家雇用雇员,这是否是政治气候正在影响员工的一种体现。如果黑客是限制员工的基础,那么目前黑客风险最高的国家分别是罗马尼亚、巴西、俄罗斯、土耳其、中国和美国,不把美国也一并排除在未来的招聘范围之外似乎是愚蠢的。

而 GitLab 不选择中国和俄罗斯只是因为客户要求,而不是法律要求、风险分析或其他合法标准,这样的决策站不住脚。作为一家“完全远程办公的公司”,GitLab 允许员工在家或在任何可以联网的地方办公,并在全球 60 多个国家/地区都有雇员。

鉴于此,有人指出,该公司的立场是对其既定的多元化和包容性价值观的嘲弄

462 comCount 0