zifuy 的个人笔记

nodeName

pod.spec.nodeName用于强制约束将Pod调度到指定的Node节点上，这里说是“调度”，但其实指定了nodeName的Pod会直接跳过Scheduler的调度逻辑，直接写入PodList列表，该匹配规则是强制匹配。

示例：

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx-pvc
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: nginx-pvc
    spec:
      nodeName: node01    # 这里制定pod调度的节点
      containers:
      - name: nginx
        image: nginx:1.7.9
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80
          name: web-nginx
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
      volumes:
      - name: www
        persistentVolumeClaim:
          claimName: pvc1

imagePullPolicy

ifNotPresent: 使用节点相同版本镜像

Always: 每次总是去仓库拉取最新版镜像

Never: 永远都不会去拉取镜像

nodeSelector

Pod.spec.nodeSelector是通过kubernetes的label-selector机制进行节点选择，由scheduler调度策略MatchNodeSelector进行label匹配，调度pod到目标节点，该匹配规则是强制约束。启用节点选择器的步骤为：

Node添加label标记

#标记规则：kubectl label nodes <node-name> <label-key>=<label-value>

kubectl label nodes k8s.node1 cloudnil.com/role=dev

#确认标记

kubectl get nodes k8s.node1 --show-labels

NAME        STATUS    AGE       LABELS
k8s.node1   Ready     29d       beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,cloudnil.com/role=dev,kubernetes.io/hostname=k8s.node1

Pod定义中添加nodeSelector

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: tomcat-deploy
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: tomcat-app
    spec:
      nodeSelector:
        cloudnil.com/role: dev #指定调度节点为带有label标记为：cloudnil.com/role=dev的node节点
      containers:
      - name: tomcat
        image: tomcat:8.0
        ports:
        - containerPort: 8080

Affinity and AntiAffinity

nodeAffinity: nodeSelector升级版

比如我有三个node节点，我不想让pod最终被调度到node01，但可以调度到node02和node03，此时使用nodeName或者nodeSelector只能指定node02和node03某一个固定节点。如果用nodeAffinit就可以让其自由选择node02和node03，且node02和node03可以设置优先级

上面的硬性过滤排除掉节点1；软性评分（node被选中的比重）再从node02和node03做进一步挑选

podAffinity：让某些 Pod 分布在同一组 Node 上

podAntiAffinity：避免某些 Pod 分布在同一组 Node 上

Taints 和 Tolerations

Taint（污点）和 Toleration（容忍）可以作用于 node 和 pod 上，其目的是优化 pod 在集群间的调度，这跟节点亲和性类似，只不过它们作用的方式相反，具有 taint 的 node 和 pod 是互斥关系，而具有节点亲和性关系的 node 和 pod 是相吸的。另外还有可以给 node 节点设置 label，通过给 pod 设置 nodeSelector 将 pod 调度到具有匹配标签的节点上。

Taint 和 toleration 相互配合，可以用来避免 pod 被分配到不合适的节点上。每个节点上都可以应用一个或多个 taint ，这表示对于那些不能容忍这些 taint 的 pod，是不会被该节点接受的。如果将 toleration 应用于 pod 上，则表示这些 pod 可以（但不要求）被调度到具有相应 taint 的节点上。

restartPolicy

restartPolicy 适用于 Pod 中的所有容器。restartPolicy 仅针对同一节点上 kubelet 的容器重启动作。当 Pod 中的容器退出时，kubelet 会按指数回退 方式计算重启的延迟（10s、20s、40s、...），其最长延迟为 5 分钟。 一旦某容器执行了 10 分钟并且没有出现问题，kubelet 对该容器的重启回退计时器执行 重置操作。

minReadySeconds

spec:
  minReadySeconds: 30      #滚动升级时30s后认为该pod就绪

rollingUpdate

spec:
  strategy:
    rollingUpdate:  ##由于replicas为3,则整个升级,pod个数在2-4个之间
      maxSurge: 1      #滚动升级时会先启动1个pod
      maxUnavailable: 1 #滚动升级时允许的最大Unavailable的pod个数