Kubernetes 基础：首先学习如何使用
Kubernetes

> 
> 不要被新项目分心，而是专注于取得你的 Kubernetes 翻斗车驾驶执照。
> 
> 
> 


![Truck steering wheel and dash](/data/attachment/album/201906/30/141021y2qa1pz16yh0dx1o.jpg "Truck steering wheel and dash")


在本系列的前两篇文章中，我解释了为何 Kubernetes [像翻斗车](/article-11011-1.html)，并且想要理解像 [Kubernetes](https://opensource.com/resources/what-is-kubernetes)（和翻斗车，起重机等）这样优雅、专业工具总是有[学习曲线](/article-11026-1.html)的。本文是下一步：学习如何驾驶。


最近，我在 Reddit 上看到了一个关于[重要的 Kubernetes 项目](https://www.reddit.com/r/kubernetes/comments/bsoixc/what_are_the_essential_kubernetes_related/)的帖子。人们似乎很想知道他们应该学习如何开始使用 Kubernetes。“驾驶翻斗车的类比”有助于确保这个问题回到轨道上去。在这个帖子中的某个人提到，除非必要，你不应该运行自己的镜像仓库，所以人们开始逐渐接受驾驭 Kubernetes 而不是构建它的想法。


API 是 Kubernetes 的引擎和变速器。像翻斗车的方向盘、离合器、汽油和制动踏板一样，用于构建应用程序的 YAML 或 JSON 文件是机器的主要接口。当你第一次学习 Kubernetes 时，这应该是你的主要关注点。了解你的控制部件。不要分心于最新和最大的那些项目。当你刚学会开车时，不要尝试驾驶实验性的翻斗车。相反，请专注于基础知识。


### 定义状态和实际状态


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


![Defined state and actual state](/data/attachment/album/201906/30/141023yfx9znjwzfx3tjct.png "Defined state and actual state")


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


在上面的例子中，Replication Controller 可以看到用户指定的三个 pod 之间的差异，其中一个 pod 正在运行，并调度另外两个 Pod。如果你登录 Kubernetes 并手动杀死其中一个 Pod，它会不断启动另一个来替换它。在实际状态与定义的状态匹配之前，Kubernetes 不会停止。这是非常强大的。


### 原语


接下来，你需要了解可以在 Kubernetes 中指定的原语。


![Kubernetes primitives](/data/attachment/album/201906/30/141026kh2d1cz51oh1vh14.png "Kubernetes primatives")


这些原语不仅仅有 Pod，还有<ruby> 部署 <rt>  Deployment </rt></ruby>、<ruby> 持久化卷声明 <rt>  Persistent Volume Claim </rt></ruby>、<ruby> 服务 <rt>  Service </rt></ruby>，<ruby> 路由 <rt>  route </rt></ruby>等。使用支持 Kubernetes 的平台 [OpenShift](https://www.openshift.com/)，你可以添加<ruby> 构建 <rt>  build </rt></ruby>和 BuildConfig。你大概需要一天左右的时间来了解这些原语。你可以在你的用例变得更加复杂时再深入了解。


### 将原生开发者映射到传统 IT 环境


最后，考虑这该如何映射到你在传统 IT 环境中的操作。


![Mapping developer-native to traditional IT environments](/data/attachment/album/201906/30/141032s211270rysr1yl1e.png "Mapping developer-native to traditional IT environments")


尽管是一个技术问题，但用户一直在尝试解决业务问题。从历史上看，我们使用诸如<ruby> 剧本 <rt>  playbook </rt></ruby>之类的东西将业务逻辑与单一语言的 IT 系统绑定起来。对于运维人员来说，这很不错，但是当你尝试将其扩展到开发人员时，它会变得更加繁琐。


直到 Kubernete 出现之前，我们从未能够以原生开发者的方式真正同时指定一组 IT 系统应如何表现和交互。如果你考虑一下，我们正在使用在 Kubernetes 中编写的 YAML/JSON 文件以非常便携和声明的方式扩展了管理存储、网络和计算资源的能力，但它们总会映射到某处的“真实”资源。我们不必以开发者身份担心它。


因此，快放弃关注 Kubernetes 生态系统中的新项目，而是专注开始使用它。在下一篇文章中，我将分享一些可以帮助你使用 Kubernetes 的工具和工作流程。




---


via: <https://opensource.com/article/19/6/kubernetes-basics>


作者：[Scott McCarty](https://opensource.com/users/fatherlinux/users/fatherlinux/users/fatherlinux) 选题：[lujun9972](https://github.com/lujun9972) 译者：[geekpi](https://github.com/geekpi) 校对：[wxy](https://github.com/wxy)


本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出


OK
In the first two articles in this series, I explained how Kubernetes is [like a dump truck](https://opensource.com/article/19/6/kubernetes-dump-truck) and that there are always [learning curves](https://opensource.com/article/19/6/kubernetes-learning-curve) to understanding elegant, professional tools like [Kubernetes](https://opensource.com/resources/what-is-kubernetes) (and dump trucks, cranes, etc.). This article is about the next step: learning how to drive.

Recently, I saw a thread on Reddit about [essential Kubernetes projects](https://www.reddit.com/r/kubernetes/comments/bsoixc/what_are_the_essential_kubernetes_related/). People seem hungry to know the bare minimum they should learn to get started with Kubernetes. The "driving a dump truck analogy" helps frame the problem to stay on track. Someone in the thread mentioned that you shouldn't be running your own registry unless you have to, so people are already nibbling at this idea of driving Kubernetes instead of building it.


The API is Kubernetes' engine and transmission. Like a dump truck's steering wheel, clutch, gas, and brake pedal, the YAML or JSON files you use to build your applications are the primary interface to the machine. When you're first learning Kubernetes, this should be your primary focus. Get to know your controls. Don't get sidetracked by all the latest and greatest projects. Don't try out an experimental dump truck when you are just learning to drive. Instead, focus on the basics.

## Defined and actual states

First, Kubernetes works on the principles of defined state and actual state.

![Defined state and actual state Defined state and actual state](https://opensource.com/sites/default/files/uploads/defined_state_-_actual_state.png)

Humans (developers/sysadmins/operators) specify the defined state using the YAML/JSON files they submit to the Kubernetes API. Then, Kubernetes uses a controller to analyze the difference between the new state defined in the YAML/JSON and the actual state in the cluster.

In the example above, the Replication Controller sees the difference between the three pods specified by the user, with one Pod running, and schedules two more. If you were to log into Kubernetes and manually kill one of the Pods, it would start another one to replace it—over and over and over. Kubernetes does not stop until the actual state matches the defined state. This is super powerful.

**Primitives**

Next, you need to understand what primitives you can specify in Kubernetes.

![Kubernetes primatives Kubernetes primitives](https://opensource.com/sites/default/files/uploads/new_primitives.png)

It's more than just Pods; it's Deployments, Persistent Volume Claims, Services, routes, etc. With Kubernetes platform [OpenShift](https://www.openshift.com/), you can add builds and BuildConfigs. It will take you a day or so to get decent with each of these primitives. Then you can dive in deeper as your use cases become more complex.

## Mapping developer-native to traditional IT environments

Finally, start thinking about how this maps to what you do in a traditional IT environment.

![Mapping developer-native to traditional IT environments Mapping developer-native to traditional IT environments](https://opensource.com/sites/default/files/uploads/developer_native_experience_-_mapped_to_traditional.png)

The user has always been trying to solve a business problem, albeit a technical one. Historically, we have used things like playbooks to tie business logic to sets of IT systems with a single language. This has always been great for operations staff, but it gets hairier when you try to extend this to developers.

We have never been able to truly specify how a set of IT systems should behave and interact together, in a developer-native way, until Kubernetes. If you think about it, we are extending the ability to manage storage, network, and compute resources in a very portable and declarative way with the YAML/JSON files we write in Kubernetes, but they are always mapped back to "real" resources somewhere. We just don't have to worry about it in developer mode.

So, quit focusing on new projects in the Kubernetes ecosystem and get focused on driving it. In the next article, I will share some tools and workflows that help you drive Kubernetes.

## Comments are closed.