先吐槽一下: sf的编辑器好奇怪，对yaml代码的md支持不好。
我放弃了，斗不过sf的这个代码编辑器。。。
看来文章和评论的编辑器一样，同样对yaml支持不友好
不能说是docker的编排工具，应该说是对“容器”的编排工具，docker只是一种容器实现方式
“编排”，通俗理解，类似我国以前大学生毕业后工作“包分配”，大学生毕业后，根据事业单位的特点和大学生的专业和特长信息，看看他们应该安排到哪个单位合适。
一般我们一个集群的会有“多台物理机器”，每个物理机器又可以跑“多个容器”，但是到底哪个容器应该跑在哪些物理机里面，就要有一套规则规划，k8s就是实现了这样一套规则。
简单举个几个例子，k8s的这些规则里面有比如“节点选择”，“节点亲和性”、“pod亲和性”等
节点选择
比如下面这个这个规则，我们希望nginx安排跑在有ssd类型硬盘的物理机器上
apiVersion: v1kind: Podmetadata: name: nginx labels: env: testspec: containers: - name: nginx image: nginx imagePullPolicy: IfNotPresent nodeSelector: disktype: ssd节点亲和性
如下面这个例子，我们希望：
- 比如
192.168.1.140和192.168.1.161不要给我跑pod， area=south如的这个果有节点满足area=south的这个条件的话，pod尽量往这里安排。
apiVersion: v1
kind: Pod
...
spec:
containers:
- name: with-node-affinity
image: nginx
affinity:
nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/hostname operator: NotIn values: - 192.168.1.140 - 192.168.1.161 preferredDuringSchedulingIgnoredDuringExecution: - weight: 1 preference: matchExpressions: - key: area operator: In values: - south# pod亲和性如下面这例子，我们希望：1. 我们希望这个pod和有`app=busybox-pod`这个标签信息的pod，尽量分配到一起2. 同时，不希望这个pod和有`app=node-affinity-pod`的这些pod尽量不要搞到一起。apiVersion: v1
kind: Pod
...
spec:
containers:
- name: with-pod-affinity
image: nginx
affinity:
podAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: app operator: In values: - busybox-pod topologyKey: kubernetes.io/hostnamepodAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 1 podAffinityTerm: labelSelector: matchExpressions: - key: app operator: In values: - node-affinity-pod topologyKey: kubernetes.io/hostname这几个例子体现了k8s“编排”的能力