[不]使用k8的10个理由

今天,我们将讨论Kubernetes,可以实际使用的耙子,以及对作者有帮助的发展,也应为您提供帮助。 我们将尝试证明在现代世界中任何地方都没有k8。 对于k8的对手,我们还提供了您不应该使用它的绝妙理由。 也就是说,在这个故事中,我们不仅将捍卫Kubernetes,还将责骂他。 这个[not]从这里来的名字来了。

本文基于Ivan Glushkovgli )在DevOops 2017大会上的演讲.Ivan的最后两个工作地点以某种方式与Kubernetes有关:他在Postmates和Machine Zone的基础架构中工作,它们对Kubernetes的影响非常紧密。 另外,Ivan负责DevZen播客。 进一步的介绍将代表Ivan。





首先,我将简要地探讨一下为什么它对许多人有用和重要,为什么会出现这种炒作。 然后,我将告诉您我们在技术使用方面的经验。 好吧,那么结论。

在本文中,所有幻灯片都作为图片插入,但是有时您想要复制某些内容。 例如,将有带有配置的示例。 PDF幻灯片可在此处下载。

我不会严格告诉所有人:一定要使用Kubernetes。 有优点也有缺点,因此,如果您寻找缺点,就会找到它们。 您可以选择,只看优点,只看缺点,通常一起看所有东西。 西蒙·卡特(Simon Cat)将为我提供专业方面的帮助,黑猫将在遇到减号时过马路。



因此,为什么发生这种炒作,为什么X技术比Y技术更好。Kubernetes是完全相同的系统,而且不止一个。 有Puppet,Chef,Ansible,Bash + SSH,Terraform。 我最喜欢的SSH现在正在帮助我,为什么我应该去某个地方。 我相信有很多标准,但我强调了最重要的标准。

从提交到发布的时间非常好,Express 42的专家们对此非常有帮助。 装配自动化,整个管道的自动化是一件非常好的事情,您不能称赞它,它实际上会有所帮助。 持续集成,持续部署。 当然,您将在所有事情上花费多少精力。 就像我说的那样,一切都可以用汇编器编写,也可以用部署系统编写,但这不会增加便利。



我不会告诉您Kubernetes的简短介绍,您知道它是什么。 我将进一步探讨这些领域。

为什么这对开发人员如此重要? 可重复性对他们来说很重要,也就是说,如果他们编写了某种应用程序并运行了测试,它将对您,您的邻居和生产都有效。

第二个是标准化的环境:如果您学习过Kubernetes并去了Kubernetes所在的附近公司,那么一切都会相同。 简化测试过程和进行持续集成并不是使用Kubernetes的直接结果,但是它仍然简化了任务,因此一切变得更加方便。



对于发行版开发人员,还有更多优势。 首先,它是一个不变的基础架构。

其次,基础架构就像存储在某处的代码。 第三,幂等性,用一个按钮添加发布的能力。 版本回滚发生得非常快,并且系统的自省非常方便。 当然,所有这一切都可以在您的系统上完成,只需写在膝盖上,但您不一定总能正确执行,而且Kubernetes已经实现了它。

Kubernetes不是什么,它不允许做什么? 在这方面有很多误解。 让我们从容器开始。 Kubernetes在它们之上运行。 容器不是轻量级虚拟机,而是完全不同的实体。 在这个概念的帮助下,它们很容易解释,但实际上是错误的。 这个概念是完全不同的,必须理解并接受。
其次,Kubernetes不能使应用程序更安全。 它不会使其自动扩展。

您需要尽力启动Kubernetes,但这不会使“按下一个按钮,所有这些都自动工作”。 会疼的


我们的经验。 我们希望您和其他所有人不要破坏任何东西。 为此,您需要四处看看-这就是我们的一面。



首先,Kubernetes并不孤单。 当构建一个可以完全管理发布和部署的结构时,您应该了解Kubernetes是一个骰子,并且必须有100个这样的骰子,要构建所有这些骰子,您需要认真研究。 进入系统的初学者也将研究此堆栈,其中包含大量信息。

Kubernetes不是唯一的重要块,周围还有许多其他重要块,否则,该系统将无法运行。 也就是说,您需要非常担心容错能力。



因此,Kubernetes是一个缺点。 该系统很复杂,您需要多多照顾。



但是有优点。 如果一个人在一家公司学习过Kubernetes,那么在另一家公司中,由于发布系统的原因,他的头发不会竖立。 随着时间的流逝,当Kubernetes占据更多空间时,人员和培训的过渡将变得更加容易。 为此-一个加号。





我们使用头盔。 该系统基于Kubernetes构建,类似于软件包管理器。 您可以单击该按钮,说您要在系统上安装* Wine *。 可以安装在Kubernetes中。 它可以正常工作,自动下载,启动,并且一切正常。 它允许您使用插件,客户端-服务器体系结构。 如果与他一起工作,建议您在名称空间上运行一个Tiller。 这样可以将命名空间彼此隔离,并且破坏一个命名空间不会破坏另一个命名空间。



实际上,该系统非常复杂。 一个系统,应该是更高层次的抽象,并且更简单,更易于理解,实际上并没有使其变得更容易理解。 对于这个减号。



让我们比较一下配置。 如果您在生产环境中运行系统,则很可能还会有一些配置。 我们有自己的系统,称为BOOMer。 我不知道为什么我们这么称呼她。 它由木偶,厨师,Ansible,Terraform以及其他所有东西组成,有一个大瓶子。



让我们看看它是如何工作的。 这是当前正在生产中的实际配置示例。 我们在这里看到什么?

首先,我们看到在哪里启动该应用程序,其次,需要启动什么,其次,应该为启动做好准备。 一瓶中的概念已经混杂在一起。



如果我们进一步研究,因为我们添加了继承来制​​作更复杂的配置,所以我们应该查看一下我们所指的通用配置中的内容。 另外,我们添加了网络配置,访问权限,负载计划。 为了在生产中运行真正的应用程序,所有这些都需要在一个配置中完成,我们将一堆概念混合在一起。

这非常困难,这是非常错误的,对于Kubernetes来说,这是一个巨大的优势,因为您可以在其中轻松确定要运行的内容。 在Kubernetes的安装过程中执行了网络设置,使用docker解决了整个配置问题-您进行了封装,所有问题都以某种方式分开了,在这种情况下,配置仅包含您的应用程序,并且还有一个优点。



让我们仔细看看。 在这里,我们只有一个应用程序。 为了使部署正常工作,您还需要大量工作。 首先,您需要定义服务。 机密信息,ConfigMap和访问Load Balancer的方式。



不要忘记您有几种环境。 有舞台/产品/开发。 所有这些都不是我展示的小作品,而是一大堆配置,这确实很困难。 对于这个减号。



头盔模板进行比较。 它完全重复了Kubernetes模板,如果Kubernetes中有任何带有部署定义的文件,那么在Helm中也是如此。 您可以使用替换为值的模板来代替环境的特定值。
您有一个单独的模板,应在此模板中替换单独的值。

当然,尽管事实上在Kubernetes中有很多配置文件需要拖放到Helm中,但您仍需要另外定义Helm本身的不同基础结构。 这都是非常困难的,为此要减一分。

实际上应该简化的系统却很复杂。 对我来说,这是明显的缺点。 需要添加其他东西,或者不使用



让我们更深入,我们还不够深入。



首先,我们如何使用集群。 我读过Google的文章“ Borg,Omega和Kubernetes” ,该文章强烈主张需要一个大型集群的概念。 我也是这个主意,但是最后,我们离开了。 由于发生纠纷,我们使用了四个不同的类别。

第一个e2e集群可测试Kubernetes本身并测试用于部署环境,插件等的脚本。 第二,当然是产品和阶段。 这些是标准概念。 第三,这是admin,其中加载了其他所有内容-特别是,我们在那里有CI,并且由于这个原因,看来这个群集将永远是最大的。

测试有很多:通过提交,通过合并,每个人都会进行一堆提交,因此集群非常庞大。



我们尝试查看CoreOS,但未使用它。 它们内部有TF或CloudFormation,但它们都非常差劲,无法让我们了解内部状态。 因此,升级过程中会出现问题。 当您想更新Kubernetes的设置(例如其版本)时,您可能会遇到这样的事实,即更新的顺序不正确。 这是一个很大的稳定性问题。 这是负号。



其次,当您使用Kubernetes时,您需要从某个地方下载图像。 它可以是内部源,存储库或外部。 如果内部存在问题。 我建议使用Docker Distribution,因为它很稳定,它是由Docker制造的。 但是支撑价仍然很高。 要使其正常运行,您需要使其具有容错能力,因为这是您的应用程序获取数据的唯一场所。



想象一下,在关键时刻,当您发现生产中的错误时,您的存储库崩溃了-您无法更新应用程序。 您必须使其具有容错能力,并避免所有可能出现的问题。

其次,如果团队规模很大,每个团队都有自己的形象,它们会迅速积累很多。 您可以杀死您的Docker发行版。 有必要进行清洁,删除图像,为用户提供信息,清洁的时间和内容。

第三,对于大图像,假设如果有一个整体,图像尺寸将非常大。 想象一下,您需要释放30个节点。 每30个节点2 GB-计算哪个流以及它下载到所有节点的速度。 我希望它按下一个按钮,并立即变为绿色。 但是,不,您必须首先等待下载它。 有必要以某种方式加快此下载的速度,并且一切都可以从一个角度进行。



对于外部存储库,垃圾收集器也存在相同的问题,但是大多数情况下这是自动完成的。 我们使用Quay。 对于外部存储库,这些是第三方服务,其中大多数映像是公开的。 没有公开的图片,有必要提供访问权限。 我们需要机密,图像的访问权限,所有这些都是经过特殊配置的。 当然,这可以是自动化的,但是在系统上本地启动Cuba的情况下,您仍然必须对其进行配置。



要安装Kubernetes,我们使用kops。 这是一个非常好的系统,我们是从尚未写博客的早期用户开始。 它不完全支持CoreOS,与Debian配合得很好,知道如何自动配置Kubernetes主节点,可以与附加组件一起使用,并且能够在Kubernetes更新期间实现零停机时间。
所有这些功能都是开箱即用的,而且还有很大胆的优点。 很棒的系统!





从链接中可以找到许多在Kubernetes中设置网络的选项。 确实有很多,每个人都有自己的优点和缺点。 Kops仅支持这些选项的一部分。 当然,您可以对其进行配置以通过CNI进行工作,但是最好使用最受欢迎和标准的工具。 它们已通过社区测试,并且很可能稳定。



我们决定使用印花棉布。 它从头开始运行良好,没有很多问题,使用BGP,更快的封装,支持IP-in-IP,允许您使用多云,这对我们来说是一大优势。
与Kubernetes的良好集成,使用标签可以限制流量。 这是一个加号。

我没想到Calico会在打开时进入状态,并且一切正常。



正如我所说,高可用性是通过kops来完成的,您可以使用5-7-9个节点,我们使用三个。 我们正坐在etcd v2上,因为存在错误,因此未在v3上进行更新。 从理论上讲,这将加快某些过程。 我不知道,我对此表示怀疑。



棘手的时刻是,我们有一个特殊的集群来试验脚本,并自动遍历CI。 我们相信我们可以防止完全错误的操作,但是对于某些特殊和复杂的发行版,以防万一我们为所有磁盘制作快照,我们不会每天进行备份。





授权是一个永恒的问题。 Kubernetes的我们使用基于角色的RBAC访问。 它比ABAC更好,而且,如果您配置了它,那么您就会明白我的意思。 查看配置-感到惊讶。
我们使用Dex,这是一个OpenID提供程序,可以从某个数据源中抽取所有信息。
为了登录Kubernetes,有两种方法。 必须以某种方式在.kube / config中注册该去哪里以及它可以做什么。 有必要以某种方式获取此配置。 或者,用户进入用户界面,在那里他登录,接收配置,将其复制到/ config并工作。 这不是很方便。 我们逐渐转移到一个事实,即一个人进入控制台,单击按钮,登录,从他那里自动生成配置,并将其堆叠在正确的位置。 非常方便,我们决定以这种方式采取行动。



作为数据源,我们使用Active Directory。 Kubernetes允许您通过整个授权结构推送有关该组的信息,该结构将转换为名称空间和角色。 因此,我们立即区分一个人可以去哪里,他无权去哪里以及可以释放什么。



通常,人们需要访问AWS。 如果您没有Kubernetes,则有一台运行该应用程序的机器。 似乎您所需要的只是获取日志,查看日志而已。 当人们可以开车去看应用程序的工作方式时,这很方便。 从Kubernetes的角度来看,一切都在容器中运行。 有一个命令“ kubectl exec”-进入应用程序中的容器,看看在那里发生了什么。 因此,无需转到AWS实例。 我们拒绝访问除基础指挥官以外的所有人。

此外,我们禁止长时间使用管理员密钥和通过角色进入。 如果可以使用admin角色-我是admin。 另外,我们添加了按键旋转功能。 通过awsudo命令配置它很方便,这是github上的一个项目,我极力推荐它,它允许您像使用sudo-team一样工作。







配额。 Kubernetes中的一件非常好的事情,开箱即用。 例如,您可以通过消耗的对象,内存或CPU数量来限制任何名称空间。 我相信这对每个人都是重要和有用的。 我们尚未达到内存和CPU,我们仅使用对象的数量,但是我们将添加所有这些对象。

又胖又胖,可以让您做很多棘手的事情。





缩放比例。 您不能在Kubernetes内部和Kubernetes外部混合缩放。 在Kubernetes内部进行扩展。 负载大时可以自动增加吊舱。

我在这里谈论的是扩展Kubernetes实例本身。 这可以使用AWS Autoscaler完成,这是一个github项目。 当您添加新的pod时,由于它在所有实例上都缺少资源而无法启动,因此AWS Autoscaler可以自动添加节点。 它允许您处理Spot实例,我们尚未添加它,但是我们会节省很多。





当您有很多用户和用户应用程序时,您需要以某种方式对其进行监视。 通常这是遥测,日志和一些漂亮的图形。



由于历史原因,我们使用了Sensu,它不适用于Kubernetes。 需要一个更注重指标的项目。 我们研究了整个TICK堆栈,尤其是InfluxDB。 良好的UI,类似SQL的语言,但功能不足。 我们改用普罗米修斯。

他很好。 良好的查询语言,良好的警报以及所有可用的功能。



为了发送遥测,我们使用了Cernan。 这是我们自己的用Rust编写的项目。 这是Rust唯一一个已经在我们的生产中工作了一年的项目。 它有几个概念:有一个数据源概念,您可以配置多个源。 您可以配置数据的合并位置。 我们有一个过滤器配置,即可以某种方式处理流数据。 您可以根据需要将日志转换为指标,将指标转换为日志。
尽管您有多个输入,几个结论,并且您证明了它的去向,但是却有一个像大型图形系统这样的东西,事实证明,这样做很方便。



现在,我们正在从当前的Statsd / Cernan / Wavefront堆栈无缝迁移到Kubernetes。 从理论上讲,Prometheus希望自己从应用程序中获取数据,因此您需要将端点添加到所有应用程序,并从该端点获取指标。 塞尔南(Cernan)是传播的纽带,应该在任何地方都可以使用。 有两种可能性:当另一个容器在发送数据的数据字段中工作时,您可以使用Sidecar概念在每个实例上运行Kubernetes。 我们做到这一点。


现在,所有日志都发送到stdout / stderr。 所有应用程序都是为此目的而设计的,因此关键要求之一就是我们不要离开该系统。 Cernan将数据发送到ElasticSearch,然后使用Heapster将整个Kubernetes系统的事件发送到那里。 我建议这是一个非常好的系统。

之后,您可以在一个位置(例如,在控制台中)查看所有日志。 我们使用Kibana。 有一个很棒的Stern产品,仅用于原木。 它使您可以观看,用不同的颜色绘制不同的豆荚,知道如何看待一个下面的动物死亡以及另一个已经重新启动。 自动获取所有日志。 我强烈推荐一个理想的项目,它是一个不错的选择,加上Kubernetes,一切都很好。





机密 我们使用S3和KMS。 我们正在考虑切换到Kubernetes本身的保管箱或秘密。 它们在alpha状态下处于1.7,但是需要做一些事情。



我们到了有趣的部分。 Kubernetes的发展通常没有太多考虑。它基本上说:“ Kubernetes是一个理想的系统,一切都很好,让我们继续前进。”
但是实际上,免费奶酪只是个陷阱,对于Kubernetes的开发人员来说,这真是个地狱。



不是从一切都不好的角度来看,而是从您需要稍微不同的角度来看。我将Kubernetes中的开发与函数式编程进行了比较:在您接触它之前,您以命令式的方式认为一切都很好。为了发展功能主义,您需要稍微向另一侧转头-这是同一件事。

, , . -, Docker Way. , . , , SSH, : « - , ».

, Kubernetes , read only . , , , , , , , . Kubernetes , , , , -, .

: , - , , - , pipeline , : «, », . - , , , . , CI , - , CI . .

当您有一个包含一百个服务的分支应用程序时,这特别困难,要使其中一个服务正常工作,您需要确保其他所有人并肩工作。您需要模拟环境,或者以某种方式在本地运行。所有这些选择都不是小事,开发人员需要认真考虑。这对Kubernetes产生了消极态度。他当然是好人-但他是坏人,因为您需要思考很多,并改变自己的习惯。
因此,这里有三只肥猫横过马路。





当我们查看Kubernetes时,我们试图了解,也许有一些方便的开发系统。特别是有Deis这样的东西,可以肯定您已经听说了所有有关它的信息。它非常易于使用,实际上,我们检查了所有简单的项目,都非常容易切换到Deis。但是问题在于,更复杂的项目可能不会切换到Deis。

, Helm Charts. , — . - How-to, - FAQ, , , , , . , . , , .


Minikube — , , , , , . Kubernetes , , SSH .

我在MacOS上工作,分别有Mac,要运行本地应用程序,我需要在本地运行docker。无法做到这一点。最后,您需要运行virtualbox或xhyve。实际上,这两件事都是在我的操作系统上进行的仿真。我们使用xhyve,但我们建议使用VirtualBox,因为存在许多错误,因此必须加以规避。

但是,存在虚拟化以及在虚拟化内部启动虚拟化的另一种抽象层次的想法是某种荒谬的,妄想的。总的来说,以某种方式起作用是件好事,但如果完成了会更好。





CI与Kubernetes并没有直接关系,但是它是一个非常重要的系统,尤其是如果您拥有Kubernetes,将其集成后可以获得很好的结果。我们使用Concourse for CI,它具有非常丰富的功能,您可以构建可怕的图形,图形,图形,位置,图形如何开始以及图形取决于什么。但是Concourse开发人员对其产品非常陌生。说,从一个版本切换到另一个版本时,它们破坏了向后兼容性,并且没有重写大多数插件。而且,文档还没有完成,当我们尝试做某事时,根本没有任何效果。

一般而言,所有配置项的文档很少,您必须阅读代码,并且总体而言,我们放弃了Concourse。我们改用Drone.io-它很小,非常轻便,灵活,功能要少得多,但通常情况下就足够了。是的,拥有大而重的依存关系图会很方便,但是您也可以处理小的关系图。还有一些文档,我们阅读了代码,但是还可以。

管道的每个阶段都在自己的docker容器中工作,这使得切换到Kubernetes变得更加容易。如果您有在真实机器上运行的应用程序,为了将其添加到CI,请使用docker容器,然后切换到Kubernetes很简单。
我们配置了admin / stage集群的自动发布,而我们担心将设置添加到生产集群。另外还有一个插件系统。



这是一个简单的Drone配置示例。从完成的工作系统中取出,在这种情况下,管道中有五个步骤,每个步骤都要做一些事情:收集,测试等等。有了Drone中的功能集,我认为这是一件好事。





我们对拥有多少个集群争论不休:一个或多个。当我们想到几个集群的想法时,我们开始朝这个方向做进一步的工作,创建了一些脚本,为我们的Kubernetes设置了一堆其他多维数据集。之后,他们来到Google寻求建议,每个人都这样做了吗,也许需要解决一些问题。

Google同意单个集群的想法不适用于Kubernetes。有很多缺陷,特别是与地理位置一起使用。事实证明,这个想法是正确的,但现在谈论它还为时过早。也许以后。虽然Service Mesh可以提供帮助。



通常,如果您想了解我们的系统如何工作,请注意Geodesic。这是类似于我们所做的产品。它是开源的,是非常相似的设计概念选择。我们正在考虑组队并可能使用它们。



是的,在我们与Kubernetes合作的实践中,也存在一些问题。

带有证书的本地名称会给您带来痛苦。下载大图像及其工作可能与文件系统有关,这是一个问题,我们尚未在此处进行挖掘。已经有三种安装Kubernetes扩展的方法。我们从事这个项目不到一年,而且我们已经有了三种不同的方式,年轮正在增长。



让我们像所有缺点一样。

因此,我认为主要缺点之一是要学习大量信息,不仅是新技术,还有新概念和习惯。这就像学习一种新语言:从原则上讲,这并不困难,但很难向所有用户开放。如果您以前没有使用过类似的概念,则很难切换到Kubernetes。

Kubernetes将只是您系统的一小部分。每个人都认为他们将安装Kubernetes,一切都将立即生效。不,这是一个小立方体,并且会有很多这样的立方体。

通常,某些应用程序很难在Kubernetes上运行-最好不要运行它们。同样非常繁重的配置文件,在Kubernetes之上的概念中,它们甚至更加复杂。当前所有解决方案都是原始的。

当然,所有这些缺点都是令人作呕的。



妥协和艰难的过渡给Kubernetes带来了负面印象,我不知道该如何处理。我们无法克服很多困难,有些人讨厌整个运动,不愿也不了解其优势。
, Minikube, , , . , , , Kubernetes . — , .



— . , , , , 1-2 , , , . Kubernetes .

-, Kubernetes , , . CI, CI , , , . .

以下是代码拆分。我们的系统和您的大多数系统在一个地方收集不同级别的配置,也就是说,您有一个基础结构代码,一个业务代码,所有逻辑都混合在一个地方。在Kubernetes中这并不是开箱即用的,选择正确的概念有助于提前避免这种情况。
一个庞大且非常活跃的社区,这意味着需要进行大量更改。我在过去两年中提到的大部分内容已经变得非常稳定,可以将它们发布到生产中。也许其中一些出现较早,但不是很稳定。

, , Kubernetes , . . , .



. Kubernetes . -. , Kubernetes, , ( — , ) , .

用户想要卸载该应用程序,他不会来要求它,而只是启动一个新的pod,有一个用于此的命令。不需要基础架构团队来调查问题。查看日志就足够了,我们的设计集不是那么大,有一个列表很容易找到问题。是的,在某些情况下,如果问题出在Kubernetes中,则有时需要支持,但是更多时候是问题出在应用程序上。

我们添加了错误预算。这是以下概念:每个团队都有有关生产中出现多少问题的统计信息。如果有太多问题,团队将削减发行版,直到花费一些时间。这很好,因为团队将认真监控其发布是否非常稳定。需要新功能-请发布。想要在凌晨两点放行-请。如果在发布后您在SLA中只有“九”-做您想做的事,一切都稳定了,您可以做任何事。但是,如果情况变得更糟,则很可能除修复程序外,我们将不允许发布其他任何内容。

对于系统的稳定性和团队内部的情绪而言,这都是一件方便的事情。我们不再是“道德警察”,阻止我们在深夜将其释放。在有充足的错误预算的情况下做自己想做的事情。这大大减轻了公司内部的压力。

您可以使用电子邮件或推特与我联系@gliush

最后,您可以找到许多链接,您可以自己下载并查看所有内容:

  1. 容器原生网络-比较
  2. Jez Humble,David Farley的连续交付。
  3. 容器不是虚拟机
  4. Docker发行版(映像注册表)
  5. 码头-图像注册表即服务
  6. etcd-operator-Kubernetes上的etcd集群的经理
  7. Dex-具有可插拔连接器的OpenID Connect身份(OIDC)和OAuth 2.0提供程序
  8. awsudo-用于管理AWS凭证的类似于sudo的实用程序
  9. Autoscaling-related components for Kubernetes
  10. Simon's cat
  11. Helm: Kubernetes package manager
  12. Geodesic: framework to create your own cloud platform
  13. Calico: Configuring IP-in-IP
  14. Sensu: Open-core monitoring system
  15. InfluxDB: Scalable datastore for metrics, events, and real-time analytics
  16. Cernan: Telemetry and logging aggregation server
  17. Prometheus: Open Source monitoring solution
  18. Heapster: Compute Resource Usage Analysis and Monitoring of Container Clusters
  19. Stern: Multi pod and container log tailing for Kubernetes
  20. Minikube: tool to run Kubernetes locally
  21. Docker machine driver fox xhyve native OS X Hypervisor
  22. Drone: Continuous Delivery platform built on Docker, written in Go
  23. Borg, Omega and Kubernetes
  24. Container-Native Networking — Comparison
  25. Bug in minikube when working with xhyve driver.

分钟的广告。 如果您喜欢DevOops会议的这份报告-请注意,新的DevOops 2018将于10月14日在圣彼得堡举行,其计划中将会有很多有趣的事情。 该网站已经有第一批发言人和报告。

Source: https://habr.com/ru/post/zh-CN416161/


All Articles