先吐槽一下: sf 的编辑器好奇怪，对 yaml 代码的 md 支持不好。
我放弃了，斗不过 sf 的这个代码编辑器。。。
看来文章和评论的编辑器一样，同样对 yaml 支持不友好

不能说是 docker 的编排工具，应该说是对“容器”的编排工具，docker 只是一种容器实现方式

“编排”，通俗理解，类似我国以前大学生毕业后工作“包分配”，大学生毕业后，根据事业单位的特点和大学生的专业和特长信息，看看他们应该安排到哪个单位合适。

一般我们一个集群的会有“多台物理机器 ”，每个物理机器又可以跑“ 多个容器 ”， 但是 到底哪个容器应该跑在哪些物理机里面 ，就要有一套 规则 规划，k8s 就是实现了这样一套规则。

简单举个几个例子，k8s 的这些规则里面有比如“节点选择”，“节点亲和性”、“pod 亲和性”等

节点选择

比如下面这个这个规则，我们希望 nginx 安排跑在有 ssd 类型硬盘的物理机器上

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    env: test
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  nodeSelector:
    disktype: ssd

节点亲和性

如下面这个例子，我们希望：

1. 比如 192.168.1.140和 192.168.1.161 不要给我跑 pod，

2. 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/hostname
podAntiAffinity:
  preferredDuringSchedulingIgnoredDuringExecution:
  - weight: 1
    podAffinityTerm:
      labelSelector:
        matchExpressions:
        - key: app
          operator: In
          values:
          - node-affinity-pod
      topologyKey: kubernetes.io/hostname

这几个例子体现了 k8s“编排”的能力