K8S基础

Kubernetes 是一个开源的，用于管理云平台中多个主机上的容器化的应用，Kubernetes 的目标是让部署容器化的应用简单并且高效（powerful），Kubernetes 提供了应用部署，规划，更新，维护的一种机制。

一、以前部署方法

一）传统部署：环境不隔离

存在多个tomcat时，存在资源共享：包括硬盘、网络以及内存等，以及环境冲突：JDK、文件系统等

二）虚拟化部署：占用资源过多

启动一个虚拟机是分钟级别，且资源占用过多

三）容器化部署

优点：容器启动效率高，且资源占用率比虚拟化少
缺点：当删除并重启容器后，容器IP会不稳定，而且原始容器文件不存在了（虽然Docker中可以通过自定义网络、通过访问服务名或者Volume挂载来解决，但是该方法很粗暴。）

二、K8S

一）优势

自我修复：当服务出现错误后，K8s会自动检测，并基于原来的容器，重新复制并运行一份，比如：线程池爆满、内存溢出时。
弹性伸缩：当我一个容器需要部署4个时，只需要告知K8s数字4，K8s会自动部署4个
自动部署和回滚：编写配置文件后，可以自动完成部署。当修改配置文件后，自动滚动更新，自动删除旧容器并部署新容器。当这个版本容器出现问题，可以进行版本回退到上个版本。
服务发现和负载均衡：替代之前nginx应用
机密和配置管理：可以管理mysql、redis、以及各类用户名密码管理
存储编排：把所有机器存在的资源管理成虚拟磁盘，容器访问虚拟磁盘，由虚拟磁盘映射物理磁盘
批处理：批处理高效命令

二）架构特点

Google 早起之前的 Borg 交互逻辑

K8S 交互逻辑

最小集群：1个Master+1个Node，所有请求通过Master调用Node

api-server：维护了所有k8s集群中对于节点或者对于各种任务处理的相关功能的接口

三）组件

1、控制面板组件（Master）

kube-apiserver（API Server）

API 服务器是 Kubernetes 控制平面的组件， 该组件负责公开了 Kubernetes API，负责处理接受请求的工作。 API 服务器是 Kubernetes 控制平面的前端。
Kubernetes API 服务器的主要实现是 kube-apiserver。 kube-apiserver 设计上考虑了水平扩缩，也就是说，它可通过部署多个实例来进行扩缩。 你可以运行 kube-apiserver 的多个实例，并在这些实例之间平衡流量。

kube-controller-manager（控制器）

kube-controller-manager 是控制平面的组件， 负责运行控制器进程。
从逻辑上讲， 每个控制器都是一个单独的进程， 但是为了降低复杂性，它们都被编译到同一个可执行文件，并在同一个进程中运行。
这些控制器包括：

• 节点控制器（Node Controller）：负责在节点出现故障时进行通知和响应
• 任务控制器（Job Controller）：监测代表一次性任务的 Job 对象，然后创建 Pods 来运行这些任务直至完成
• 端点分片控制器（EndpointSlice controller）：填充端点分片（EndpointSlice）对象（以提供 Service 和 Pod 之间的链接）。
• 服务账号控制器（ServiceAccount controller）：为新的命名空间创建默认的服务账号（ServiceAccount）。

cloud-controller-manager（云控制器）

嵌入了特定于云平台的控制逻辑。 云控制器管理器（Cloud Controller Manager）允许你将你的集群连接到云提供商的 API 之上， 并将与该云平台交互的组件同与你的集群交互的组件分离开来。
cloud-controller-manager 仅运行特定于云平台的控制器。 因此如果你在自己的环境中运行 Kubernetes，或者在本地计算机中运行学习环境， 所部署的集群不需要有云控制器管理器。
与 kube-controller-manager 类似，cloud-controller-manager 将若干逻辑上独立的控制回路组合到同一个可执行文件中， 供你以同一进程的方式运行。 你可以对其执行水平扩容（运行不止一个副本）以提升性能或者增强容错能力。

kube-scheduler（调度器）

scheduler 负责资源的调度，按照预定的调度策略将 Pod 调度到相应的机器上；决策这个Pod到时候放到哪个节点上，比如：将MySQL吃存储则存到SSD标识的节点（服务器）上，或者将JAVA程序比较吃内存则放到内存比较大的节点上。

etcd（存储器）

一致且高度可用的键值存储，用作 Kubernetes 的所有集群数据的后台数据库。如果你的 Kubernetes 集群使用 etcd 作为其后台数据库，请确保你针对这些数据有一份备份计划。早期数据存放在内存，现在已经是持久化存储的了。

2、节点组件（Node）

kubelet

kubelet 负责维护 Pod 的生命周期，同时也负责 Volume（CVI）和网络（CNI）的管理；

kube-proxy

kube-proxy 负责为 Service 提供 cluster 内部的服务发现和负载均衡；

container runtime（运行时环境）

Container runtime 负责镜像管理以及 Pod 和容器的真正运行（CRI）；
Kubernetes 支持许多容器运行环境，例如 containerd、 CRI-O 以及 Kubernetes CRI (容器运行环境接口) 的其他任何实现。

Pod

1台服务器（节点）下有多个Pod，1个Pod下有多个容器

3、附加组件

kube-dns

kube-dns 负责为整个集群提供 DNS 服务

Ingress Controller

Ingress Controller 为服务提供外网入口

Prometheus

Prometheus 提供资源监控

Dashboard

Dashboard 提供 GUI

Federation

Federation 提供跨可用区的集群

Fluentd-elasticsearch

Fluentd-elasticsearch 提供集群日志采集、存储与查询

核心概念与专业术语

一）服务的分类

1、无状态

代表应用：Nginx、Apache
优点：对客户端透明，不会对本地环境产生任何依赖，可以高效实现扩容、迁移，例如不会存储数据到本地磁盘
缺点：不能存储数据，需要额外的数据服务支撑

2、有状态

代表应用:MySQL、Redis
优点：可以独立存储数据，实现数据管理
缺点：会对本地环境产生依赖，例如需要存储数据到本地磁盘，集群环境下需要实现主从、数据同步、备份、水平扩容复杂

二）对象规约和状态

对象是用来完成一些任务的，是持久的，是有目的性的，因此 kubernetes 创建一个对象后，将持续地工作以确保对象存在。当然，kubernetes 并不只是维持对象的存在这么简单，kubernetes 还管理着对象的方方面面。每个 Kubernetes 对象包含两个嵌套的对象字段，它们负责管理对象的配置，他们分别是 “spec” 和 “status” 。

1、规约（Spec）

“spec” 是 “规约”、“规格” 的意思，spec 是必需的，它描述了对象的期望状态（Desired State）—— 希望(非必须)对象所具有的特征。当创建 Kubernetes 对象时，必须提供对象的规约，用来描述该对象的期望状态，以及关于对象的一些基本信息，例如：名称、副本数。

2、状态（Status）

表示对象的实际状态，该属性由 k8s 自己维护，k8s 会通过一系列的控制器对对应对象进行管理，让对象尽可能的让实际状态与期望状态重合。
注意：规约中期望3个，但是由于内存资源不够，只启动了2个，这个也是可以的，并不是一定要实际状态和规约重合（当然重合最好）

三）资源和对象

资源=类，对象=基于资源创建的对象

Kubernetes 中的所有内容都被抽象为“资源”，如 Pod、Service、Node 等都是资源。“对象”就是“资源”的实例，是持久化的实体。如某个具体的 Pod、某个具体的 Node。Kubernetes 使用这些实体去表示整个集群的状态。
对象的创建、删除、修改都是通过 “Kubernetes API”，也就是 “Api Server” 组件提供的 API 接口，这些是 RESTful 风格的 Api，与 k8s 的“万物皆对象”理念相符。命令行工具 “kubectl”，实际上也是调用 kubernetes api。
K8s 中的资源类别有很多种，kubectl 可以通过配置文件来创建这些 “对象”，配置文件更像是描述对象“属性”的文件，配置文件格式可以是 “JSON” 或 “YAML”，常用 “YAML”。

1、资源的分类

1.1 元数据型（范围最大，在集群之上的东西）

对于资源的元数据描述，每一个资源都可以使用元空间的数据。

Horizontal Pod Autoscaler（HPA） —— 扩容/缩容

Pod 自动扩容：可以根据 CPU 使用率或自定义指标（metrics）自动对 Pod 进行扩/缩容。如：在CPU>80%，进行缩容到几个实例，当CPU<20%，进行扩容到几个实例

• 控制管理器每隔30s（可以通过–horizontal-pod-autoscaler-sync-period修改）查询metrics的资源使用情况
• 支持三种metrics类型
  • 预定义metrics（比如Pod的CPU）以利用率的方式计算
  • 自定义的Pod metrics，以原始值（raw value）的方式计算
  • 自定义的object metrics
• 支持两种metrics查询方式：Heapster和自定义的REST API
• 支持多metrics

PodTemplate

Pod Template 是关于 Pod 的定义，但是被包含在其他的 Kubernetes 对象中（例如 Deployment、StatefulSet、DaemonSet 等控制器）。控制器通过 Pod Template 信息来创建 Pod。比如：当用HPA自动扩容/缩容时，就会利用Pod的模板创建新容器。

spec.template.描述

LimitRange

可以对集群内 Request 和 Limits 的配置做一个全局的统一的限制，最多可用资源，最少用到资源，相当于批量设置了某一个范围内（某个命名空间）的 Pod 的资源使用限制。

1.2 集群级

作用于集群之上，集群下的所有资源都可以共享使用

Namespace 命名空间

Kubernetes 支持多个虚拟集群，它们底层依赖于同一个物理集群，这些虚拟集群被称为命名空间。作用是用于实现多团队/环境的资源隔离。
命名空间 namespace 是 k8s 集群级别的资源，可以给不同的用户、租户、环境或项目创建对应的命名空间。
默认 namespace：

• kube-system 主要用于运行系统级资源，存放 k8s 自身的组件
• kube-public 此命名空间是自动创建的，并且可供所有用户（包括未经过身份验证的用户）读取。此命名空间主要用于集群使用，关联的一些资源在集群中是可见的并且可以公开读取。此命名空间的公共方面知识一个约定，但不是非要这么要求。
• default 未指定名称空间的资源就是 default，即你在创建pod 时如果没有指定 namespace，则会默认使用 default

Node 节点

不像其他的资源（如 Pod 和 Namespace），Node 本质上不是Kubernetes 来创建的，Kubernetes 只是管理 Node 上的资源。虽然可以通过 Manifest 创建一个Node对象（如下 json 所示），但 Kubernetes 也只是去检查是否真的是有这么一个 Node，如果检查失败，也不会往上调度 Pod。

ClusterRole（作用于集群）

ClusterRole 是一组权限的集合，但与 Role 不同的是，ClusterRole 可以在包括所有 Namespace 和集群级别的资源或非资源类型进行鉴权。

ClusterRoleBinding（作用于集群）

ClusterRoleBinding：将 Subject 绑定到 ClusterRole，ClusterRoleBinding 将使规则在所有命名空间中生效。只能向集群级别资源绑定

1.3 命名空间级

作用在命名空间之上，通常只能在该命名空间范围内使用

1）工作负载型 —— Pod

Pod中需要至少1个以上的容器，可以看到容器组的概念，。

多个容器间通过pause容器实现共用网络、文件系统等

Pod（容器组）是 Kubernetes 中最小的可部署单元。一个 Pod（容器组）包含了一个应用程序容器（某些情况下是多个容器）、存储资源、一个唯一的网络 IP 地址、以及一些确定容器该如何运行的选项。Pod 容器组代表了 Kubernetes 中一个独立的应用程序运行实例，该实例可能由单个容器或者几个紧耦合在一起的容器组成。
Docker 是 Kubernetes Pod 中使用最广泛的容器引擎；Kubernetes Pod 同时也支持其他类型的容器引擎。
Kubernetes 集群中的 Pod 存在如下两种使用途径：
一个 Pod 中只运行一个容器。"one-container-per-pod" 是 Kubernetes 中最常见的使用方式。此时，您可以认为 Pod 容器组是该容器的 wrapper，Kubernetes 通过 Pod 管理容器，而不是直接管理容器。
一个 Pod 中运行多个需要互相协作的容器。您可以将多个紧密耦合、共享资源且始终在一起运行的容器编排在同一个 Pod 中，可能的情况有：

a）副本（replicas）

先引入“副本”的概念——一个 Pod 可以被复制成多份，每一份可被称之为一个“副本”，这些“副本”除了一些描述性的信息（Pod 的名字、uid 等）不一样以外，其它信息都是一样的，譬如 Pod 内部的容器、容器数量、容器里面运行的应用等的这些信息都是一样的，这些副本提供同样的功能。
Pod 的“控制器”通常包含一个名为 “replicas” 的属性。“replicas”属性则指定了特定 Pod 的副本的数量，当当前集群中该 Pod 的数量与该属性指定的值不一致时，k8s 会采取一些策略去使得当前状态满足配置的要求。

b）控制器

当 Pod 被创建出来，Pod 会被调度到集群中的节点上运行，Pod 会在该节点上一直保持运行状态，直到进程终止、Pod 对象被删除、Pod 因节点资源不足而被驱逐或者节点失效为止。Pod 并不会自愈，当节点失效，或者调度 Pod 的这一操作失败了，Pod 就该被删除。如此，单单用 Pod 来部署应用，是不稳定不安全的。
Kubernetes 使用更高级的资源对象 “控制器” 来实现对Pod的管理。控制器可以为您创建和管理多个 Pod，管理副本和上线，并在集群范围内提供自修复能力。 例如，如果一个节点失败，控制器可以在不同的节点上调度一样的替身来自动替换 Pod。

b.1）适用无状态服务

• ReplicationController（RC）
  
  Replication Controller 简称 RC，RC 是 Kubernetes 系统中的核心概念之一，简单来说，RC 可以保证在任意时间运行 Pod 的副本数量，能够保证 Pod 总是可用的。如果实际 Pod 数量比指定的多那就结束掉多余的，如果实际数量比指定的少就新启动一些Pod，当 Pod 失败、被删除或者挂掉后，RC 都会去自动创建新的 Pod 来保证副本数量，所以即使只有一个 Pod，我们也应该使用 RC 来管理我们的 Pod。可以说，通过 ReplicationController，Kubernetes 实现了 Pod 的高可用性。比如：在RC中配置副本数：replicas

• ReplicaSet（RS）
  
  RC （ReplicationController ）主要的作用就是用来确保容器应用的副本数始终保持在用户定义的副本数 。即如果有容器异常退出，会自动创建新的 Pod 来替代；而如果异常多出来的容器也会自动回收（已经成为过去时），在 v1.11 版本废弃。
  ​Kubernetes 官方建议使用 RS（ReplicaSet ） 替代 RC （ReplicationController ） 进行部署，RS 跟 RC 没有本质的不同，只是名字不一样，并且 RS 支持集合式的 selector。

  • Label 和 Selector
    label （标签）是附加到 Kubernetes 对象（比如 Pods）上的键值对，用于区分对象（比如Pod、Service）。 label 旨在用于指定对用户有意义且相关的对象的标识属性，但不直接对核心系统有语义含义。 label 可以用于组织和选择对象的子集。label 可以在创建时附加到对象，随后可以随时添加和修改。可以像 namespace 一样，使用 label 来获取某类对象，但 label 可以与 selector 一起配合使用，用表达式对条件加以限制，实现更精确、更灵活的资源查找。
    label 与 selector 配合，可以实现对象的“关联”，“Pod 控制器” 与 Pod 是相关联的 —— “Pod 控制器”依赖于 Pod，可以给 Pod 设置 label，然后给“控制器”设置对应的 selector，这就实现了对象的关联。

• Deployment（实际使用！！！！！！！！！！！！！）
  Deployment 为 Pod 和 Replica Set 提供声明式更新。
  你只需要在 Deployment 中描述你想要的目标状态是什么，Deployment controller 就会帮你将 Pod 和 Replica Set 的实际状态改变到你的目标状态。你可以定义一个全新的 Deployment，也可以创建一个新的替换旧的 Deployment。

  • 创建 Replica Set / Pod

  • 滚动升级/回滚
    如，运行了两个Pod，由RS1进行管理，现在需要进行模板升级，则先基于RS1生成RS2，再在RS2中新启一个新版Pod，再去停止RS1中的Pod01，再去RS2中新启一个新版Pod，最后停止RS1中的Pod02，这时就完成了无感知的滚动升级，Deployment会将旧RS1保留下来不会直接删除，用于防止回滚。
    

  • 平滑扩容和缩容
    依赖ReplicaSet实现扩容/缩容

  • 暂停与恢复 Deployment
    先不自动升级，当模板将需要修改的5、6个改完后，再恢复，直接一次性升级完成

b.2）适用有状态服务 —— StatefulSet

有状态服务相对无状态服务时，需要解决的问题：
问题1：容器删除并重新部署后，内部IP会变化；
问题2：数据问题，容器删除后，内部的数据丢失了。
问题3：解决顺序问题，需要知道多个节点的顺序，比如redis的3节点集群，或者mysql的主从。

组成：

• Headless Service：用于定义网络标志（DNS domain）
  Domain Name Server：域名服务，将域名与 ip 绑定映射关系
  服务名 => 访问路径（域名） => ip

  > 可以通过这样一个固定的名字，访问到具体的Pod
  StatefulSet 中每个 Pod 的 DNS 格式为 statefulSetName-{0..N-1}.serviceName.namespace.svc.cluster.local
  * serviceName 为 Headless Service 的名字
  * 0..N-1 为 Pod 所在的序号，从 0 开始到 N-1
  * statefulSetName 为 StatefulSet 的名字
  * namespace 为服务所在的 namespace，Headless Servic 和 StatefulSet 必须在相同的 namespace
  * .cluster.local 为 Cluster Domain，本地集群域名
  

• volumeClaimTemplate：申请持久化存储持久卷
  用于创建 PersistentVolumes（PVC）

主要特点：

• 稳定的持久化存储
  即 Pod 重新调度后还是能访问到相同的持久化数据，基于 PVC 来实现
• 稳定的网络标志
  稳定的网络标志，即 Pod 重新调度后其 PodName 和 HostName 不变，基于 Headless Service（即没有 Cluster IP 的 Service）来实现
• 有序部署，有序扩展
  有序部署，有序扩展，即 Pod 是有顺序的，在部署或者扩展的时候要依据定义的顺序依次依次进行（即从 0到 N-1，在下一个Pod 运行之前所有之前的 Pod 必须都是 Running 和 Ready 状态），基于 init containers 来实现
• 有序收缩，有序删除
  有序收缩，有序删除（即从 N-1 到 0）

注意事项：

• kubernetes v1.5 版本以上才支持
• 所有Pod的Volume必须使用PersistentVolume或者是管理员事先创建好
• 为了保证数据安全，删除StatefulSet时不会删除Volume
• StatefulSet 需要一个 Headless Service 来定义 DNS domain，需要在 StatefulSet 之前创建好

b.3）守护进程

DaemonSet 保证在每个 Node 上都运行一个容器副本，常用来部署一些集群的日志、监控或者其他系统管理应用。典型的应用包括：

• 日志收集，比如 fluentd，logstash 等
• 系统监控，比如 Prometheus Node Exporter，collectd，New Relic agent，Ganglia gmond 等
• 系统程序，比如 kube-proxy, kube-dns, glusterd, ceph 等

b.4）任务/定时任务

• Job
  一次性任务，运行完成后Pod销毁，不再重新启动新容器。

• CronJob
  CronJob 是在 Job 基础上加上了定时功能。

2）服务发现

• Service
  “Service” 简写 “svc”。Pod 不能直接提供给外网访问，而是应该使用 service。Service 就是把 Pod 暴露出来提供服务，Service 才是真正的“服务”，它的中文名就叫“服务”。
  可以说 Service 是一个应用服务的抽象，定义了 Pod 逻辑集合和访问这个 Pod 集合的策略。Service 代理 Pod 集合，对外表现为一个访问入口，访问该入口的请求将经过负载均衡，转发到后端 Pod 中的容器。负责K8s集群内的网络通信，跨节点网络通讯 以及 Pod与Pod之间通讯，就可以通过Service来暴露端口实现。

• Ingress
  Ingress 可以提供外网访问 Service 的能力。可以把某个请求地址映射、路由到特定的 service。
  ingress 需要配合 ingress controller 一起使用才能发挥作用，ingress 只是相当于路由规则的集合而已，真正实现路由功能的，是 Ingress Controller，ingress controller 和其它 k8s 组件一样，也是在 Pod 中运行。

3）存储

• Volume
  数据卷，共享 Pod 中容器使用的数据。用来放持久化的数据，比如数据库数据。PV / PVC

• CSI
  Container Storage Interface 是由来自 Kubernetes、Mesos、Docker 等社区成员联合制定的一个行业标准接口规范，旨在将任意存储系统暴露给容器化应用程序。
  CSI 规范定义了存储提供商实现 CSI 兼容的 Volume Plugin 的最小操作集和部署建议。CSI 规范的主要焦点是声明 Volume Plugin 必须实现的接口。

4）特殊类型配置

• ConfigMap
  用来放Key-Value配置，与 Secret 是类似的，只是 ConfigMap 放的是明文的数据，Secret 是密文存放。然后将ConfigMap加载到Pod的容器中，这样就实现了将容器中的配置暴露了出来，当我们修改ConfigMap，容器内的数据会自动更新。

• Secret
  Secret 解决了密码、token、密钥等敏感数据的配置问题，而不需要把这些敏感数据暴露到镜像或者 Pod Spec 中。Secret 可以以 Volume 或者环境变量的方式使用。
  Secret 有三种类型：

  • Service Account：用来访问 Kubernetes API，由 Kubernetes 自动创建，并且会自动挂载到 Pod 的 /run/secrets/kubernetes.io/serviceaccount 目录中；
  • Opaque：base64 编码格式的 Secret，用来存储密码、密钥等；
  • kubernetes.io/dockerconfigjson：用来存储私有 docker registry 的认证信息。

• DownwardAPI
  downwardAPI 这个模式和其他模式不一样的地方在于它不是为了存放容器的数据也不是用来进行容器和宿主机的数据交换的，而是让 pod 里的容器能够直接获取到这个 pod 对象本身的一些信息。
  downwardAPI 提供了两种方式用于将 pod 的信息注入到容器内部：

  • 环境变量：用于单个变量，可以将 pod 信息和容器信息直接注入容器内部
  • volume 挂载：将 pod 信息生成为文件，直接挂载到容器内部中去

5）其他

• Role（作用于命名空间）
  Role 是一组权限的集合，例如 Role 可以包含列出 Pod 权限及列出 Deployment 权限，Role 用于给某个 Namespace 中的资源进行鉴权。

• RoleBinding（作用于命名空间）
  RoleBinding ：将 Subject 绑定到 Role，RoleBinding 使规则在命名空间内生效。

2、资源清单

整个 k8s 的所有文件都是以一个 yaml / json 配置文件形式 描述对应的资源对象，然后基于配置文件把资源对象创建出来

K8S 的资源清单

参数名	类型	字段说明
apiVersion	String	K8S APl 的版本，可以用 kubectl api versions 命令查询
kind	String	yam 文件定义的资源类型和角色
metadata	Object	元数据对象，下面是它的属性
metadata.name	String	元数据对象的名字，比如 pod 的名字
metadata.namespace	String	元数据对象的命名空间
Spec	Object	详细定义对象
spec.containers[]	list	定义 Spec 对象的容器列表
spec.containers[].name	String	为列表中的某个容器定义名称
spec.containers[].image	String	为列表中的某个容器定义需要的镜像名称
spec.containers[].imagePullPolicy	string	定义镜像拉取策略，有 Always、Never、IfNotPresent 三个值可选 - Always（默认）：意思是每次都尝试重新拉取镜像 - Never：表示仅适用本地镜像 - IfNotPresent：如果本地有镜像就使用本地镜像，没有就拉取在线镜像。
spec.containers[].command[]	list	指定容器启动命令，因为是数组可以指定多个，不指定则使用镜像打包时使用的启动命令。
spec.containers[].args[]	list	指定容器启动命令参数，因为是数组可以指定多个。
spec.containers[].workingDir	string	指定容器的工作目录
spec.containers[].volumeMounts[]	list	指定容器内部的存储卷配置
spec.containers[].volumeMounts[].name	string	指定可以被容器挂载的存储卷的名称
spec.containers[].volumeMounts[].mountPath	string	指定可以被容器挂载的存储卷的路径
spec.containers[].volumeMounts[].readOnly	string	设置存储卷路径的读写模式，ture 或者 false，默认是读写模式
spec.containers[].ports[]	list	指定容器需要用到的端口列表
spec.containers[].ports[].name	string	指定端口的名称
spec.containers[].ports[].containerPort	string	指定容器需要监听的端口号
spec.containers[].ports[].hostPort	string	指定容器所在主机需要监听的端口号，默认跟上面 containerPort 相同，注意设置了 hostPort 同一台主机无法启动该容器的相同副本（因为主机的端口号不能相同，这样会冲突）
spec.containers[].ports[].protocol	string	指定端口协议，支持 TCP 和 UDP，默认值为 TCP
spec.containers[].env[]	list	指定容器运行前需设置的环境变量列表
spec.containers[].env[].name	string	指定环境变量名称
spec.containers[].env[].value	string	指定环境变量值
spec.containers[].resources	Object	指定资源限制和资源请求的值（这里开始就是设置容器的资源上限）
spec.containers[].resources.limits	Object	指定设置容器运行时资源的运行上限
spec.containers[].resources.limits.cpu	string	指定 CPU 的限制，单位为 Core 数，将用于 docker run –cpu-shares 参数
spec.containers[].resources.limits.memory	string	指定 mem 内存的限制，单位为 MIB、GiB
spec.containers[].resources.requests	Object	指定容器启动和调度时的限制设置
spec.containers[].resources.requests.cpu	string	CPU请求，单位为core数，容器启动时初始化可用数量
spec.containers[].resources.requests.memory	string	内存请求，单位为MIB、GiB，容器启动的初始化可用数量
spec.restartPolicy	string	定义 pod 的重启策略，可选值为 Always、OnFailure、Never，默认值为 Always。 - Always：pod 一旦终止运行，则无论容器是如何终止的，kubelet 服务都将重启它。 - OnFailure：只有 pod 以非零退出码终止时，kubelet 才会重启该容器。如果容器正常结束（退出码为0），则 kubectl 将不会重启它。 - Never：Pod 终止后，kubelet 将退出码报告给 master，不会重启该 pod
spec.nodeSelector	Object	定义 Node 的 label 过滤标签，以 key：value 格式指定
spec.imagePullSecrets	Object	定义 pull 镜像时使用 secret 名称，以 name：secretkey 格式指定
spec.hostNetwork	Boolean	定义是否使用主机网络模式，默认值为 false。设置 true 表示使用宿主机网络，不使用 docker 网桥，同时设置了 true将无法在同一台宿主机上启动第二个副本