kubernetes:_Kubernetes基础知识：学习如何首先驾驶

kubernetes:

在本系列的前两篇文章中，我解释了Kubernetes如何像自卸车 ，并且总是需要学习一些曲线来理解诸如Kubernetes （以及自卸车，起重机等）之类的优雅而专业的工具。 本文介绍了下一步：学习如何驾驶。

最近，我在Reddit上看到了一个有关Kubernetes基本项目的话题 。 人们似乎渴望知道应该学习入门的最低限度的知识。 “驾驶自卸车类比”有助于确定问题的发展方向。 线程中的一个人提到，除非必须这样做，否则您不应该运行自己的注册表，因此人们已经开始讨厌驱动Kubernetes而不是构建它了。

定义状态和实际状态

首先，Kubernetes遵循定义状态和实际状态的原则。

人员（开发人员/系统管理员/操作员）使用他们提交给Kubernetes API的YAML / JSON文件指定定义的状态。 然后，Kubernetes使用控制器来分析YAML / JSON中定义的新状态与集群中实际状态之间的差异。

在上面的示例中，Replication Controller在运行一个Pod的情况下，看到用户指定的三个Pod之间的差异，并计划另外两个Pod。 如果您要登录Kubernetes并手动杀死其中一个Pod，它将一遍又一遍地启动另一个Pod来替换它。 在实际状态与定义的状态匹配之前，Kubernetes不会停止。 这是超级强大的。

原语

接下来，您需要了解可以在Kubernetes中指定哪些原语。

不仅仅是Pods； 它是部署，持久性批量声明，服务，路由等。使用Kubernetes平台OpenShift ，您可以添加构建和BuildConfigs。 您将需要一天左右的时间来熟悉这些原语。 然后，随着用例变得越来越复杂，您可以更深入地研究。

将开发人员本机映射到传统IT环境

最后，开始考虑如何将其映射到您在传统IT环境中所做的工作。

用户一直试图解决业务问题，尽管是技术问题。 从历史上看，我们曾使用过诸如剧本之类的东西将业务逻辑与单一语言的IT系统集联系起来。 对于运营人员而言，这一直以来都是很棒的选择，但是当您尝试将其扩展到开发人员时，它将变得更加困难。

在Kubernetes之前，我们从未能够以开发人员本机的方式真正指定一组IT系统应如何表现和相互作用。 如果您考虑一下，我们正在使用我们在Kubernetes中编写的YAML / JSON文件，以非常可移植和声明性的方式扩展管理，存储和网络资源以及计算资源的功能，但是它们始终会映射回某个地方的“实际”资源。 我们只是不必在开发人员模式下担心它。

因此，不要再关注Kubernetes生态系统中的新项目，而要专注于推动它。 在下一篇文章中，我将分享一些工具和工作流程，以帮助您推动Kubernetes。

翻译自: https://opensource.com/article/19/6/kubernetes-basics

kubernetes: