2.4.1 部署应用（Pod）

在 Kubernetes 集群上自主运行的 Pod 对象再非计划内终止后，其生命周期即告以结束，用户需要再次手动创建类似的 Pod 对象才能确保容器中的应用依然可得。对于 Pod 数量众多的场景，尤其是对微服务来说，用户必将疲于应付此类需求。Kubernetes 的工作负载（workload）类型的控制器能够自动确保由其管控的 Pod 对象按用户期望的方式运行，因此，Pod 的创建和管理大多都会通过这种类型的控制器来进行，包括 Deployment、ReplicaSet、ReplicationController 等。

1. 创建 Deployment 控制器对象

“kubectl run” 命令可于命令行直接创建 Deployment 控制器，并以 --image 选项指定镜像的运行 Pod 中的容器，--dry-run 选项可用于命令的测试运行，但并未真正执行资源对象的创建过程。例如，下面的命令要创建一个名为 myapp 的 Deployment 控制器对象，它使用镜像 ikubernetes/myapp:v1 创建 Pod 对象，但仅在测试运行后即退出：

**[terminal]
**[delimiter $ ]**[command kubectl run myapp --image=ikubernetes/myapp:v1 --port=80 --replicas=1 --dry-run]

镜像 ikubernetes/myapp:v1中定义的容器主进程为默认监听于80端口的Web服务程序Nginx，因此，如下命令使用“--port=80” 来指明容器要暴露的端口。而“--replicas=1”选项则指定了目标控制器对象要自动创建的Pod对象的副本数量。确认测试命令无误后，可移除“--dry-run”选项后再次执行命令以完成资源对象的创建：

**[terminal]
**[delimiter $ ]**[command kubectl run myapp --image=ikubernetes/myapp:v1 --port=80 --replicas=1]

创建完成后，其运行效果示意图如图 2-10 所示，它在 default 名称空间中创建了一个名为 myapp 的 Deployment 控制器对象，并由它基于指定的镜像文件创建了一个 Pod 对象。

kubectl run 命令其他常用的选项还有如下几个，它们支持用户在创建资源对象时实现更多的控制，具体如下：

• -l, --lables：为 Pod 对象设定自定义标签
• --record：是否将当前的对象创建命令保存至对象的 Annotation 中，布尔型数据，其值可为 true 或 false。
• --save-config：是否将当前对象的配置信息保存至 Annotation 中，布尔型数据，其值可为 true 或 false。
• --restart=Never：创建不受控制器管控的自主式 Pod 对象。

其他可用选项及使用方式可通过“kubectl run --help”命令获取。资源对象创建完成后，通常需要了解其当前状态是否正常，以及是否能够吻合于用户期望的目标状态，相关的操作一般使用 kubectl get、kubectl describe 等命令进行。

2. 打印资源的相关信息

kubectl get 命令可用于获取各种资源对象的相关信息，它既能够显示对象类型特有格式的简要信息，也能够指定出格式为YAML或JSON的详细信息，或者使用Go模板自定义要显示的属性及信息等。例如，下面是查看前面创建的Deployment对象的相关运行状态的命令及其输出的结果：

**[terminal]
**[delimiter $ ]**[command kubectl get deployments]
NAME               READY   UP-TO-DATE   AVAILABLE   AGE
myapp              1/1     1            1           4m59s

上面的命令的执行结果中，各字段的说明具体如下：

1. NAME：资源对象的名称
2. READY：在“/”前的数值表示为当前控制器已有的Pod对象的副本数量，“/”后的数值表示为用户期望由当前控制器管理的Pod对象副本的精确数量。
3. UP-TO-DATE：更新到最新版本定义的Pod对象的副本数量，再控制器的滚动更新模式下，它表示已经完成版本更新的Pod对象的副本数量。
4. AVAILABLE：当前处于可用状态的Pod对象的副本数量，即可正常提供服务的副本数。
5. AGE：Pod的存在时长。

Deployment 资源对象通过 ReplicaSet 控制器实例完成对 Pod 对象的控制，而非直接控制。另外，通过控制器创建的Pod对象都会被自动附加一个标签，其格式为“run=”，例如，上面的命令所创建的Pod，会拥有“run=myapp”标签。后面的章节对此会有更详细的描述。

而此Deployment控制器创建的唯一Pod对象运行正常与否，其被调用至哪个节点运行，当前是否就绪等也是用户在创建完成后应该重点关注的信息。由控制器创建的Pod对象的名称通常是以控制器名称为前缀，以随机字符串为后缀，例如，下面命令输出的结果中的myapp-5c647497bf-9km8t：

**[terminal]
**[delimiter $ ]**[command kubectl get pods -o wide]
NAME                               READY   STATUS    RESTARTS   AGE     IP           NODE                      NOMINATED NODE   READINESS GATES
myapp-5c647497bf-9km8t             1/1     Running   0          8m53s   10.244.3.3   kube-node-2.localdomain   <none>           <none>
nginx-deployment-d86dfb797-m2vpm   1/1     Running   0          18h     10.244.4.4   kube-node-3.localdomain   <none>           <none>

上面命令的执行结果中，每一个字段均代表着Pod资源对象一个方面的属性，除了NAME之外的其他字段及功能说明如下：

1. READY：Pod中的容器进程初始化完成并能够正常提供服务即为就绪状态，此字段用于记录处于就绪状态的容器数量。
2. STATUS：Pod的当前状态，其值可能是Pending、Running、Succeeded、Failed 和 Unknown 等其中一种。
3. RESTARTS：Pod 对象可能会因容器进程崩溃、超出资源限额等原因发生故障问题而被重启，此字段记录了它重启的次数。
4. IP：Pod的IP地址，其通常由网络插件自动分配。
5. NODE：创建时，Pod对象会由调度器调度至急群众的某节点上运行，此字段即为节点的相关标示信息。

如果指定的名称空间中存在大量的Pod对象而使得类似如上命令的输出结果存在太多的不相关信息时，则可通过指定选项“-l run=myapp”进行Pod的对象过滤，其仅显示符合此标签选择器的Pod对象。

确认Pod对象已转为“Runnning”状态之后，即可于集群中的任一节点（或其他Pod对象）直接访问其容器化应用中的服务，如图2-11中节点 NodeX 上客户端程序Client，或者集群上运行于Pod中的客户端程序。

例如，在集群中任一节点上使用curl命令对地址为10.244.3.3的Pod对象myapp-5c647497bf-9km8t的80端口发起服务请求，命令及结果如下所示：

**[terminal]
**[delimiter $ ]**[command curl http://10.244.3.3:80/]
Hello MyApp | Version: v1 | <a href="hostname.html">Pod Name</a>