借助您在前几节中学到的信息，您现在可以开始创建 pod。在第 3 章中，您使用命令式命令 kubectl create 创建了它们，但 pod 和其他 Kubernetes 对象通常是通过创建 JSON 或 YAML 清单文件并将其发布到 Kubernetes API 来创建的，正如您在前一章中已经了解的那样。

使用 YAML 还是 JSON 来定义对象由您决定。大多数人更喜欢使用 YAML，因为它更加人性化，并且允许您向对象定义添加注释。

通过使用 YAML 文件来定义应用程序的结构，您不需要 shell 脚本来使部署应用程序的过程可重复，并且您可以通过将这些文件存储在 VCS（版本控制系统）中来保留所有更改的历史记录.就像你存储代码一样。

事实上，本书中练习的应用程序清单都存储在一个VCS中。您可以在 GitHub 上的 https://github.com/luksa/kubernetes-in-action-2nd-edition 上找到它们。

为 pod 创建 YAML 清单

在上一章中，您学习了如何检索和检查现有 API 对象的 YAML 清单。现在，您将从头开始创建对象清单。

您将首先在您的计算机上创建一个名为 kubia.yaml 的文件，该文件位于您选择的文件目录中。您还可以在本书的代码存档中找到该文件，该文件位于 GitHub 上。该文件位于 Chapter04/ 目录中。下面的清单显示了它的内容。

  1. apiVersion: v1
  2. kind: Pod
  3. metadata:    
  4.   name: kubia
  5. spec:    
  6.   containers:     
  7.   - name: kubia
  8.     image: luksa/kubia:1.0
  9.     ports:        
  10.     - containerPort: 8080

我相信你会同意这个 pod 清单比你在前一章看到的代表 Node 对象的庞大清单更容易理解。但是，一旦您将此 pod 对象清单发布到 API，然后将其读回，它不会有太大不同。

上述清单很短，只是因为它还没有包含 pod 对象在通过 API 创建后获得的所有字段。例如，您会注意到元数据部分仅包含一个字段，而状态部分完全缺失。从这个清单创建对象后，情况将不再如此。但我们稍后会谈到。

在创建对象之前，让我们详细检查清单。它使用 Kubernetes API 的 v1 版本来描述对象。该对象是一个名为 kubia 的 Pod。 pod 由一个名为 kubia 的容器组成，基于 luksa/kubia:1.0 镜像。 pod 定义还指定容器中的应用程序侦听端口 8080。

每当您想从头开始创建 pod 清单时，还可以使用以下命令创建文件，然后对其进行编辑以添加更多字段： kubectl run kubia —image=luksa/kubia:1.0 —dry-run=client -o yaml > mypod.yaml。 —dry-run=client 标志告诉 kubectl 输出定义，而不是通过 API 实际创建对象。

YAML 文件中的字段是不言自明的，但如果您想了解有关每个字段的更多信息或想知道可以添加哪些其他字段，请记住使用 kubectl explain pods 命令。

从 YAML 文件创建 Pod 对象

为 pod 准备好清单文件后，您现在可以通过将文件发布到 Kubernetes API 来创建对象。

通过将清单文件应用于集群来创建对象

当您将清单发布到 API 时，您是在指示 Kubernetes 将清单应用到集群。这就是为什么执行此操作的 kubectl 子命令称为 apply。让我们用它来创建 pod：

  1. $ kubectl apply -f kubia.yaml
  2. pod “kubia” created

通过修改清单文件并重新应用它来更新对象

kubectl apply命令用于创建对象以及对现有对象进行更改。如果您稍后决定对您的 pod 对象进行更改，您可以简单地编辑 kubia.yaml 文件并再次运行 apply 命令。 pod 的某些字段是不可变的，因此更新可能会失败，但您始终可以删除 pod，然后重新创建它。您将在本章末尾学习如何删除 pod 和其他对象。

检索正在运行的 pod 的完整清单

pod 对象现在是集群配置的一部分。您现在可以使用以下命令从 API 中读取它以查看完整的对象清单：

  1. $ kubectl get po kubia -o yaml

如果您运行此命令，您会注意到清单与 kubia.yaml 文件中的清单相比已大大增加。您会看到 metadata 部分现在要大得多，并且对象现在有一个 status 部分。spec 部分也多了几个字段。您可以使用 kubectl explain 来了解有关这些字段的更多信息，但其中大部分将在本章和后续章节中进行解释。

检查新创建的 pod

在我们开始与运行在其中的应用程序交互之前，让我们使用基本的 kubectl 命令来查看 pod 的运行情况。

快速检查 Pod 的状态

你的 Pod 对象已经创建好了，但是你怎么知道 Pod 中的容器是否真的在运行呢？您可以使用 kubectl get 命令查看 pod 的摘要：

  1. $ kubectl get pod kubia
  2. NAME     READY   STATUS    RESTARTS   AGE
  3. kubia    1/1     Running   0          32s

您可以看到 pod 正在运行，但仅此而已。要查看更多信息，您可以尝试使用上一章学习的 kubectl get pod -o wide 或 kubectl describe 命令。

使用 kubectl describe 查看 pod 详细信息

要显示 pod 的更详细视图，请使用 kubectl describe 命令：

  1. $ kubectl describe pod kubia
  2. Name:         kubia
  3. Namespace:    default
  4. Priority:     0
  5. Node:         worker2/172.18.0.4
  6. Start Time:   Mon, 27 Jan 2020 12:53:28 +0100
  7. ...

该清单没有显示完整的输出，但如果您自己运行该命令，您将看到几乎所有信息，如果您使用 kubectl get -o yaml 命令打印完整的对象清单会看到。

检查事件（events）以了解底层发生的情况

与上一章中使用 describe node 命令检查 Node 对象一样，describe pod 命令应该在输出底部显示几个与 pod 相关的事件。

如果您还记得，这些事件不是对象本身的一部分，而是单独的对象。让我们打印它们以了解更多关于创建 pod 对象时发生的情况。以下清单显示了创建 pod 后记录的所有事件。

  1. $ kubectl get events
  2. LAST SEEN   TYPE     REASON      OBJECT      MESSAGE
  3. <unknown>   Normal   Scheduled   pod/kubia   Successfully assigned default/
  4.                                              kubia to worker2
  5. 5m          Normal   Pulling     pod/kubia   Pulling image luksa/kubia:1.0
  6. 5m          Normal   Pulled      pod/kubia   Successfully pulled image
  7. 5m          Normal   Created     pod/kubia   Created container kubia
  8. 5m          Normal   Started     pod/kubia   Started container kubia

这些事件按时间顺序打印。最近的事件位于底部。您会看到，首先将 pod 分配给其中一个工作节点，然后拉取容器映像，然后创建容器并最终启动。