cn

为什么Kubernetes要移除Docker

先来看一下 kubernetes 和 Docker 的实际关系

在 什么是容器 一文中我们提到过，容器并不仅仅是docker，容器实际上是

OCI 组织定义的一套规范，包含 runtime spec 和 image format spec

Kubernetes 在 1.5 版本里（2016年）引入了CRI，于是 Docker 和 Kubernetes 关系就变成了下面这样

Dockershim是由社区维护的，可以让kubernetes正常使用docker的docker垫片

CRI-O

当容器运行时（Container Runtime）的标准被提出以后，Red Hat 的一些人开始想他们可以构建一个更简单的运行时，而且这个运行时仅仅为 Kubernetes 所用。这样就有了 skunkworks项目，最后定名为 CRI-O， 它实现了一个最小的 CRI 接口

最后这个结构演变成了这样

在本文写作的2021年，也就是距离CRI接口概念提出的6年之后，kubernetes已经成为了容器编排环境的事实标准，在话语权方面自然也开始高于原生的Docker，而反观Docker一边，似乎从来没有认真考虑过要支持 CRI 接口，仍然需要Kubernetes社区在仓库中维护 Dockershim

这也就不难理解为什么kubernetes打算开始逐渐移除对docker的支持

更不用说现在对于kubernetes而言，docker应该也不会支持它的一系列其他模块的接口

Docker 和 Kubernetes CRI 的关系更像是下面这样

Docker提供了远远超出于 CRI 需要的更多功能，提供了从运行到构建的全套工具，也正是因为这种负责和全能性，使得Kubernetes在和Docker对接时不得不付出更多成本。

还有许多新的CRI特性由于无法在 Dockershim上实现而一再被推迟发布，导致了kubernetes最终选择开始尝试从项目中移除Dockershim。

Kubernetes Node污点

kubectl taint nodes 192.168.204.129 key1=value1:NoExecute
node/192.168.204.129 tainted

如果不指定key，那么可以使用

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-hello-deployment3
  namespace: lizhe
  labels:
    app: nginx-hello3
spec:
  replicas: 6
  selector:
    matchLabels:
      app: nginx-hello3
  template:
    metadata:
      labels:
        app: nginx-hello3
    spec:
      tolerations:
      - effect: NoExecute
        operator: Exists
      containers:
      - name: nginx-hello3
        image: nginx
        ports:
        - containerPort: 80

这样会忽略所有 key

可以看到 nginx3 运行在了 129上

如果需要指定特定的 key ，例如这里指定 key = key2 ，实际上这个 key2 不存在，所以是没有任何容忍的

    spec:
      tolerations:
      - effect: NoExecute
        operator: Exists
        key: key2

也可以加入 value 但是就无法使用 operator 了

The Deployment "nginx-hello-deployment3" is invalid: spec.template.spec.tolerations[0].operator: Invalid value: core.Toleration{Key:"key1", Operator:"Exists", Value:"value2", Effect:"NoExecute", TolerationSeconds:(*int64)(nil)}: value must be empty when `operator` is 'Exists'

    spec:
      tolerations:
      - effect: NoExecute
        key: key1
        value: value2

如果想容忍的话

    spec:
      tolerations:
      - effect: NoExecute
        key: key1
        value: value1

Kubernetes Pod 亲和性

和节点亲和性类似，Pod亲和性主要用于限制调度器工作，顾名思义，Pod亲和性是参考pod运行来调度的

而不是像节点亲和性那样根据节点来控制调度

在 Kubernetes 节点亲和性 中我们创建了nginx的deploy

可以看到 nginx全部 运行在 129 上

这里我们尝试让 nginx2 跟随 nginx 调度在同一个节点上

使用

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-hello-deployment2
  namespace: lizhe
  labels:
    app: nginx-hello2
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx-hello2
  template:
    metadata:
      labels:
        app: nginx-hello2
    spec:
      affinity:
        podAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - nginx-hello
            topologyKey: numberCores
      containers:
      - name: nginx-hello2
        image: nginx
        ports:
        - containerPort: 80

结果发现 nginx2 不仅被调度在了 129 上，还被调度在了 139 上

这就不得不说一说 topologyKey 了，由于我们的3个node都指定了 numberCores=6

也就是说，

1. 运行了 pod app=nginx-hello 的 node上，带有numberCores, 且值为 6
2. 则 只要是带有 numberCores 为 6 的 node，都可以运行 nginx2

我们把numberCores在 129 上改为 7 ，这样就只有 129的 numberCores 是 7 ，其余node 都是 6

这样，nginx2 为了跟随 nginx的7，只能被调度在 129上

由于亲和性配置在 已经创建的 pod 上不能重新生效（因为已经被调度完成了）

所以这里我们删除原 dep 重新创建

这一次可以看到，因为只有 129带有7，所以nginx 被全部调度在了 129 上

那如果你想要让 pod A 只被调度在已经运行了 pod B 的节点上，只需要把

topologyKey 写成 kubernetes.io/hostname

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-hello-deployment2
  namespace: lizhe
  labels:
    app: nginx-hello2
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx-hello2
  template:
    metadata:
      labels:
        app: nginx-hello2
    spec:
      affinity:
        podAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - nginx-hello
            topologyKey: kubernetes.io/hostname
      containers:
      - name: nginx-hello2
        image: nginx
        ports:
        - containerPort: 80

Kubernetes 节点亲和性

节点亲和性 是对节点选择器方法的一种泛化，允许指定必要规则和偏好规则

下面的例子是一个 nginx ， 亲和性规则要求它

只考虑有3个以上核心（不包含3个）的节点

尽量选择不是 master 的节点

这里还有一个权重，值为1，如果这个节点符合 名称不为 master，则会获得一个权重积分1

调度器最后会选择一个 所有权重 得分最高的节点，权重是一个列表

看下面一个例子

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-hello-deployment
  namespace: lizhe
  labels:
    app: nginx-hello
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx-hello
  template:
    metadata:
      labels:
        app: nginx-hello
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: numberCores
                operator: Gt
                values: ["3"]
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 1
            preference:
              matchFields:
              - key: metadata.name
                operator: NotIn
                values: ["master"]
      containers:
      - name: nginx-hello
        image: nginx
        ports:
        - containerPort: 80

在这个例子中，使用了 numberCores ，请不要误以为这是一个 原生字段，实际上这是一个 node 上的 label，我们需要自己手动创建

不创建的话，是不会调度成功的

添加label

已经可以正确调度了

快速安装NFS

有时候我们会在本地环境中使用 kubernetes，这时候想要一些方便的类似 aws 和 其他公有云上那种 storage class 就不太可能了，这时候一般我们会选择使用 linux NFS 来代替这些共有云的存储卷

如果不需要storage class的话，直接使用docker run也是可以的，但是这里，因为我很懒，我希望在 NFS 创建之后能自动得到一个 storage class，那最方便的实际上是 rancher 提供的 helm，注意这里

nfs-client-provisioner 和 nfs-server-provisioner 只是驱动模式不同，功能是一样的

K8S的外部NFS驱动，可以按照其工作方式（是作为NFS server还是NFS client）分为两类：

NFS client 通过K8S的内置的NFS驱动挂载远端的NFS服务器到本地目录；然后将自身作为storage provider，关联storage class。当用户创建对应的PVC来申请PV时，该provider就将PVC的要求与自身的属性比较，一旦满足就在本地挂载好的NFS目录中创建PV所属的子目录，为Pod提供动态的存储服务

NFS server 与 nfs-client 不同，该驱动并不使用 k8s 的 NFS 驱动来挂载远端的 NFS 到本地再分配，而是直接将本地文件映射到容器内部，然后在容器内使用 ganesha.nfsd 来对外提供 NFS 服务；在每次创建 PV 的时候，直接在本地的 NFS 根目录中创建对应文件夹，并 export 出该子目录。利用 NFS 动态提供 Kubernetes 后端存储卷

可惜这里我使用的是 NFS-provisioner https://github.com/kubernetes-retired/external-storage

直接点击安装没什么好说得，注意默认的 node 上存储路径是 /srv，至于存储到哪个node上，这里是随机的，也可以通过node name 指定

可以看到这里我的 workload 被分配在了 139 上，

这种方式最方便的点在于可以直接得到 storage class

然后我们尝试安装一个 nginx 来使用这个 nfs-provisioner

然后我会在 nginx的pod上，使用 shell 在 /test 路径上创建一个测试文件

可以看到这个文件可以在 nfs node 上被找到