编写配置文件
Kubernetes 跟 Docker 等很多项目最大的不同，就在于它不推荐你使用命令行的方式直接运行容器（虽然 Kubernetes 项目也支持这种方式，比如：kubectl run），而是希望你用 YAML 文件的方式，即：把容器的定义、参数、配置，统统记录在一个 YAML 文件中，然后用这样一句指令把它运行起来：
$ kubectl create -f 我的配置文件
Yaml文件示例：
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
selector:
matchLabels:
app: nginx
replicas: 2
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
- 像这样的一个 YAML 文件，对应到 Kubernetes 中，就是一个 API Object（API 对象）。当你为这个对象的各个字段填好值并提交给 Kubernetes 之后，Kubernetes 就会负责创建出这些对象所定义的容器或者其他类型的 API 资源。
- 这个 YAML 文件中的 Kind 字段，指定了这个 API 对象的类型（Type），是一个 Deployment。Deployment，是一个定义多副本应用（即多个副本 Pod）的对象
- 这个 YAML 文件中，定义的 Pod 副本个数 (spec.replicas) 是：2。
- Pod 模版（spec.template），这个模版描述了创建的 Pod 的细节。在上面的例子这个 Pod 里只有一个容器，这个容器的镜像（spec.containers.image）是 nginx:1.7.9，这个容器监听端口（containerPort）是 80。
- 这样使用一种 API 对象（Deployment）管理另一种 API 对象（Pod）的方法，在 Kubernetes 中，叫作“控制器”模式（controller pattern）
- 一个 Kubernetes 的 API 对象的定义，大多可以分为 Metadata 和 Spec 两个部分。前者存放的是这个对象的元数据，对所有 API 对象来说，这一部分的字段和格式基本上是一样的；而后者存放的，则是属于这个对象独有的定义，用来描述它所要表达的功能。
[root@k8s ~]# kubectl apply -f nginx-deployment.yaml --namespace=kube-system
deployment.apps/nginx-deployment created
[root@k8s ~]# kubectl get pods -l app=nginx
NAME READY STATUS RESTARTS AGE
nginx-deployment-54f57cf6bf-jpgq4 0/1 Pending 0 86m
nginx-deployment-54f57cf6bf-rrmbq 0/1 Pending 0 86m
或者
[root@k8s ~]# kubectl get pods -n kube-system
解决 pending 状态：
检查：
[root@k8s ~]# kubectl -n kube-system describe pod nginx-deployment-54f57cf6bf-rg8td
……
……
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedScheduling 5s (x17 over 22m) default-scheduler 0/1 nodes are available: 1 node(s) had taints that the pod didn't tolerate.
查看节点的 Taints（kubectl describe node <node_name>）
Taints: node-role.kubernetes.io/master:NoSchedule
解决方案：
- 在 Pod 的.yaml 文件中的 spec 部分，加入 tolerations 字段即可
- 或者
kubectl taint nodes --all node-role.kubernetes.io/master-
在“node-role.kubernetes.io/master”这个键后面加上了一个短横线“-”，这个格式就意味着移除所有以“node-role.kubernetes.io/master”为键的 Taint。
[root@k8s ~]# kubectl taint nodes --all node-role.kubernetes.io/master-
node/instance-010oj085 untainted
再次查看状态(在命令行中，所有 key-value 格式的参数，都使用“=”而非“:”表示)
[root@k8s ~]# kubectl get pods -l app=nginx
NAME READY STATUS RESTARTS AGE
nginx-deployment-54f57cf6bf-jpgq4 1/1 Running 0 148m
nginx-deployment-54f57cf6bf-rrmbq 1/1 Running 0 148m
查看 describe 的 Event 事件：
……
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedScheduling 10m (x39 over 65m) default-scheduler 0/1 nodes are available: 1 node(s) had taints that the pod didn't tolerate.
Normal Pulling 5m41s kubelet, instance-010oj085 Pulling image "nginx:1.7.9"
Normal Pulled 4m37s kubelet, instance-010oj085 Successfully pulled image "nginx:1.7.9"
Normal Created 4m37s kubelet, instance-010oj085 Created container nginx
Normal Started 4m37s kubelet, instance-010oj085 Started container nginx
镜像服务升级
1. 修改 YAML 文件
2. 执行命令
# 修改nginx-deployment.yaml的内容
kubectl apply -f nginx-deployment.yaml
当应用本身发生变化时，开发人员和运维人员可以依靠容器镜像来进行同步；当应用部署参数发生变化时，这些 YAML 文件就是他们相互沟通和信任的媒介。
删除 Nginx Deployment
$ kubectl delete -f nginx-deployment.yaml
总结
- Kubernetes 里“最小”的 API 对象是 Pod。Pod 可以等价为一个应用，所以，Pod 可以由多个紧密协作的容器组成。
- 在 Kubernetes 中，我们经常会看到它通过一种 API 对象来管理另一种 API 对象，比如 Deployment 和 Pod 之间的关系；而由于 Pod 是“最小”的对象，所以它往往都是被其他对象控制的。这种组合方式，正是 Kubernetes 进行容器编排的重要模式。
- 像这样的 Kubernetes API 对象，往往由 Metadata 和 Spec 两部分组成，其中 Metadata 里的 Labels 字段是 Kubernetes 过滤对象的主要手段。
- 在这些字段里面，容器想要使用的数据卷，也就是 Volume，正是 Pod 的 Spec 字段的一部分。而 Pod 里的每个容器，则需要显式的声明自己要挂载哪个 Volume。