首页 > 其他分享> > kubernetes权威指南第四版读书笔记

kubernetes权威指南第四版读书笔记

2020-03-23 17:52:31 作者：互联网

yum list kubelet --showduplicates | sort -r

第一章、第二章

1.　　HPA与之前的RC、Deployment一样，也属于一种Kubernetes资源对象。通过追踪分析指定RC控制的所有目标Pod的负载变化情况，来确定是否需要有针对性地调整目标Pod的副本数量，这是HPA的实现原理。HPA有以下两种方式作为Pod负载的度量指标：CPUUtilizationPercentage 应用程序自定义的度量指标，比如服务在每秒内的相应请求数（TPS或QPS）。CPUUtilizationPercentage是一个算术平均值，即目标Pod所有副本自身的CPU利用率的平均值。一个Pod自身的CPU利用率是该Pod当前CPU 的使用量除以它的Pod Request的值，比如定义一个Pod的Pod Request为 0.4，而当前Pod的CPU使用量为0.2，则它的CPU使用率为50%，这样就可以算出一个RC控制的所有Pod副本的CPU利用率的算术平均值了。在CPUUtilizationPercentage计算过程中使用到的Pod的CPU使用量通常是1min内的平均值

2.　　StatefulSet特性：StatefulSet里的每个Pod都有稳定、唯一的网络标识，可以用来发现集群内的其他成员。StatefulSet控制的Pod副本的启停顺序是受控的，操作第n个Pod 时，前n-1个Pod已经是运行且准备好的状态。StatefulSet里的Pod采用稳定的持久化存储卷，通过PV或PVC来实现，删除Pod时默认不会删除与StatefulSet相关的存储卷（为了保证数据的安全）StatefulSet除了要与PV卷捆绑使用以存储Pod的状态数据，还要与 Headless Service配合使用，即在每个StatefulSet定义中都要声明它属于哪个Headless Service。Headless Service与普通Service的关键区别在于，它没有Cluster IP，如果解析Headless Service的DNS域名，则返回的是该 Service对应的全部Pod的Endpoint列表。StatefulSet在Headless Service的基础上又为StatefulSet控制的每个Pod实例都创建了一个DNS域名：podname.headless.service name

3.　　PV: accessModes属性，目前有以下类型: ReadWriteOnce：读写权限，并且只能被单个Node挂载 ReadOnlyMany：只读权限，允许被多个Node挂载 ReadWriteMany：读写权限，允许被多个Node挂载

PV是有状态的对象，它的状态有以下几种:Available：空闲状态。Bound：已经绑定到某个PVC上。Released：对应的PVC已经被删除，但资源还没有被集群收回。Failed：PV自动回收失败。Reclaiming：用户删除PVC释放对PV的占用后，系统根据PV的"reclaim policy"决定对PV执行何种回收操作。目前，"reclaim policy"有三种方式：Retained、Recycled、Deleted。Retained：保护被PVC释放的PV及其上数据，并将PV状态改成"released"，不将被其它PVC绑定。集群管理员手动通过如下步骤释放存储资源：手动删除PV，但与其相关的后端存储资源如(AWS EBS, GCE PD, Azure Disk, or Cinder volume)仍然存在。手动清空后端存储volume上的数据。手动删除后端存储volume，或者重复使用后端volume，为其创建新的PV Delete：删除被PVC释放的PV及其后端存储volume。对于动态PV其"reclaim policy"继承自其"storage class"，默认是Delete。集群管理员负责将"storage class"的"reclaim policy"设置成用户期望的形式，否则需要用户手动为创建后的动态PV编辑"reclaim policy"

4.　　kubelet的职责在于通过RPC管理容器的生命周期，实现容器生命周期的钩子，存活和健康监测，以及执行Pod的重启策略等

5.　　目前还有一个潜在问题是，kubelet处理所有的请求连接，使其有成为Node通信瓶颈的可能。在设计CRI时，要让容器运行时能够跳过中间过程。容器运行时可以启动一个单独的流式服务来处理请求（还能对 Pod的资源使用情况进行记录），并将服务地址返回给kubelet。这样 kubelet就能反馈信息给API Server，使之可以直接连接到容器运行时提供的服务，并连接到客户端

6.　　目前已经有多款开源CRI项目可用于Kubernetes：Docker、CRI-O、 Containerd、frakti（基于Hypervisor的容器运行时），各CRI运行时的安装手册可参考官网https://kubernetes.io/docs/setup/cri/的说明

第三章

1.　　kubelet只支持可以被API Server管理的Pod使用ConfigMap。 kubelet在本Node上通过 --manifest-url或--config自动创建的静态Pod将无法引用ConfigMap

2.　　在Pod对ConfigMap进行挂载（volumeMount）操作时，在容器内部只能挂载为“目录”，无法挂载为“文件”。在挂载到容器内部后，在目录下将包含ConfigMap定义的每个item，如果在该目录下原来还有其他文件，则容器内的该目录将被挂载的ConfigMap覆盖

3.　　将Pod信息注入为环境变量:

apiVersion: v1
kind: pod
metadata:
  name: {{ template "module.name" . }}
  namespace: {{ $.Release.Namespace }}
spec:
  containers:
        - name: {{ .Chart.Name }}
          image: {{ .Values.image.repository }}:{{ .Values.image.tag }}
          env:
            - name: MY_POD_NAME
              valueFrom:
                fieldRef:
                  fieldPath: metadata.name
            - name: MY_POD_NAMESPACE
              valueFrom:
                 fieldRef:
                   fieldPath: metadata.namespace
            - name: MY_POD_IP
              valueFrom:
                fieldPath: matadata.podIP

4.　　将容器资源信息注入为环境变量

apiVersion: v1
kind: pod
metadata:
  name: {{ template "module.name" . }}
  namespace: {{ $.Release.Namespace }}
spec:
  containers:
        - name: {{ .Chart.Name }}
          image: {{ .Values.image.repository }}:{{ .Values.image.tag }}
          resources:
            requests:
              memory: "32Mi"
              cpu: "125m"
            limits:
             memory: "64Mi"
             cpu: "250m"
          env:
            - name: MY_CPU_REQUEST
              valueFrom:
                resourceFieldRef:
                  containerName: test-container
                  resource: request.cpu

5.　　通过Downward API将Pod的Label、Annotation列表通过 Volume挂载为容器中的一个文件

apiVersion: v1
kind: pod
metadata:
  name: {{ template "module.name" . }}
  namespace: {{ $.Release.Namespace }}
  labels:
    zone: us-est-coast
    cluster: test-cluster1
    rack: rack-22
    annotations:
      build: two
      builder: john-doe
spec:
  containers:
        - name: {{ .Chart.Name }}
          image: {{ .Values.image.repository }}:{{ .Values.image.tag }}
          resources:
            requests:
              memory: "32Mi"
              cpu: "125m"
            limits:
             memory: "64Mi"
             cpu: "250m"
          volumeMounts:
            - name: pidinfo
              mountPath: /etc
              readOnly: false
          volumes:
            - name: podinfo
              downloadAPI:
                items:
                  - path: "labels"
                    fieldRef:
                      fieldPath: metadata.labels
                  - path: "annotations"
                    fieldRef:
                      fieldPath: metadata.annotations

这里要注意“volumes”字段中downwardAPI的特殊语法，通过items 的设置，系统会根据path的名称生成文件。根据上例的设置，系统将在容器内生成/etc/labels和/etc/annotations两个文件。Downward API的价值.在某些集群中，集群中的每个节点都需要将自身的标识（ID）及进程绑定的IP地址等信息事先写入配置文件中，进程在启动时会读取这些信息，然后将这些信息发布到某个类似服务注册中心的地方，以实现集群节点的自动发现功能

6.　　pod的生命周期：kubelet重启失效容器的时间间隔以sync-frequency乘以2n来计算，例如1、2、4、8倍等，最长延时5min，并且在成功重启后的10min后重置该时间.　

7.　　NodeAffinity：Node亲和性调度 NodeAffinity意为Node亲和性的调度策略，是用于替换NodeSelector 的全新调度策略。目前有两种节点亲和性表达:◎ RequiredDuringSchedulingIgnoredDuringExecution：必须满足指定的规则才可以调度Pod到Node上（功能与nodeSelector很像，但是使用的是不同的语法），相当于硬限制 ◎ PreferredDuringSchedulingIgnoredDuringExecution：强调优先满足指定规则，调度器会尝试调度Pod到Node上，但并不强求，相当于软限制。多个优先级规则还可以设置权重（weight）值，以定义执行的先后顺序。IgnoredDuringExecution的意思是：如果一个Pod所在的节点在Pod运行期间标签发生了变更，不再符合该Pod的节点亲和性需求，则系统将忽略Node上Label的变化，该Pod能继续在该节点运行

8.　　PodAffinity：Pod亲和与互斥调度策略。Pod间的亲和与互斥从Kubernetes 1.4版本开始引入。这一功能让用户从另一个角度来限制Pod所能运行的节点：根据在节点上正在运行的 Pod的标签而不是节点的标签进行判断和调度，要求对节点和Pod两个条件进行匹配。这种规则可以描述为：如果在具有标签X的Node上运行了一个或者多个符合条件Y的Pod，那么Pod应该（如果是互斥的情况，那么就变成拒绝）运行在这个Node上

9.　　Pod的互斥性调度

10.　　Taints和Tolerations（污点和容忍）Taint需要和Toleration配合使用，让Pod避开那些不合适的Node。在 Node上设置一个或多个Taint之后，除非Pod明确声明能够容忍这些污点，否则无法在这些Node上运行。Toleration是Pod的属性，让Pod能够（注意，只是能够，而非必须）运行在标注了Taint的Node上可以用kubectl taint命令为Node设置Taint信息：kubectl taint nodes node1 key=value:NoSchedule 这个设置为node1加上了一个Taint。该Taint的键为key，值为 value，Taint的效果是NoSchedule。这意味着除非Pod明确声明可以容忍这个Taint，否则就不会被调度到node1上.然后，需要在Pod上声明Toleration。下面的两个Toleration都被设置为可以容忍（Tolerate）具有该Taint的Node，使得Pod能够被调度到 node1上

tolerations:
- key: "key"
  operator: "Equal"
  value: value
  effect: "NoSchedule"

或者

tolerations:
- key: "key"
  operator: "Exists"
  effect: "NoSchedule"

Pod的Toleration声明中的key和effect需要与Taint的设置保持一致，并且满足以下条件之一。◎ operator的值是Exists（无须指定value）。◎ operator的值是Equal并且value相等。如果不指定operator，则默认值为Equal。另外，有如下两个特例。◎ 空的key配合Exists操作符能够匹配所有的键和值。◎ 空的effect匹配所有的effect。在上面的例子中，effect的取值为NoSchedule，还可以取值为 PreferNoSchedule，这个值的意思是优先，也可以算作NoSchedule的软限制版本—一个Pod如果没有声明容忍这个Taint，则系统会尽量避免把这个Pod调度到这一节点上，但不是强制的系统允许在同一个Node上设置多个Taint，也可以在Pod上设置多个 Toleration。Kubernetes调度器处理多个Taint和Toleration的逻辑顺序为：首先列出节点中所有的Taint，然后忽略Pod的Toleration能够匹配的部分，剩下的没有忽略的Taint就是对Pod的效果了。下面是几种特殊情◎ 如果在剩余的Taint中没有NoSchedule效果，但是有 PreferNoSchedule效果，则调度器会尝试不把这个Pod指派给这个节点。◎ 如果在剩余的Taint中存在effect=NoSchedule，则调度器不会把该Pod调度到这一节点上。◎ 如果在剩余的Taint中有NoExecute效果，并且这个Pod已经在该节点上运行，则会被驱逐；如果没有在该节点上运行，则也不会再被调度到该节点上。

11.　　Pod Priority Preemption：Pod优先级调度。在Kubernetes 1.8版本之前，当集群的可用资源不足时，在用户提交新的Pod创建请求后，该Pod会一直处于Pending状态，即使这个Pod是一个很重要（很有身份）的Pod，也只能被动等待其他Pod被删除并释放资源，才能有机会被调度成功。Kubernetes 1.8版本引入了基于Pod优先级抢占（Pod Priority Preemption）的调度策略，此时Kubernetes会尝试释放目标节点上低优先级的Pod，以腾出空间（资源）安置高优先级的 Pod，这种调度方式被称为“抢占式调度”。在Kubernetes 1.11版本中，该特性升级为Beta版本，默认开启，在后继的Kubernetes 1.14版本中正式 Release。如何声明一个负载相对其他负载“更重要”？我们可以通过以下几个维度来定义：◎ Priority，优先级；◎ QoS，服务质量等级；◎ 系统定义的其他度量指标。优先级抢占调度策略的核心行为分别是驱逐（Eviction）与抢占（Preemption），这两种行为的使用场景不同，效果相同。Eviction是 kubelet进程的行为，即当一个Node发生资源不足（under resource pressure）的情况时，该节点上的kubelet进程会执行驱逐动作，此时 Kubelet会综合考虑Pod的优先级、资源申请量与实际使用量等信息来计算哪些Pod需要被驱逐；当同样优先级的Pod需要被驱逐时，实际使用的资源量超过申请量最大倍数的高耗能Pod会被首先驱逐。对于QoS等级为“Best Effort”的Pod来说，由于没有定义资源申请（CPU/Memory Request），所以它们实际使用的资源可能非常大。Preemption则是 Scheduler执行的行为，当一个新的Pod因为资源无法满足而不能被调度时，Scheduler可能（有权决定）选择驱逐部分低优先级的Pod实例来满足此Pod的调度目标，这就是Preemption机制。需要注意的是，Scheduler可能会驱逐Node A上的一个Pod以满足 Node B上的一个新Pod的调度任务

12. 　　deployment更新。当更新Deployment时，系统创建了一个新的 ReplicaSet（nginx-deployment-3599678771），并将其副本数量扩展到 1，然后将旧的ReplicaSet缩减为2。之后，系统继续按照相同的更新策略对新旧两个ReplicaSet进行逐个调整。最后，新的ReplicaSet运行了3个新版本Pod副本，旧的ReplicaSet副本数量则缩减为0

13.　　自动扩缩容机制。Kubernetes中的某个Metrics Server（Heapster或自定义Metrics Server）持续采集所有Pod副本的指标数据。HPA控制器通过Metrics Server的API（Heapster的API或聚合API）获取这些数据，基于用户定义的扩缩容规则进行计算，得到目标Pod副本数量。当目标Pod副本数量与当前副本数量不同时，HPA控制器就向Pod的副本控制器（Deployment、RC或ReplicaSet）发起scale操作，调整Pod的副本数量，完成扩缩容操作

14.　　指标的类型Master的kube-controller-manager服务持续监测目标Pod的某种性能指标，以计算是否需要调整副本数量。目前Kubernetes支持的指标类型如下：◎ Pod资源使用率：Pod级别的性能指标，通常是一个比率值，例如CPU使用率。 ◎ Pod自定义指标：Pod级别的性能指标，通常是一个数值，例如接收的请数量。◎ Object自定义指标或外部自定义指标：通常是一个数值，需要容器应用以某种方式提供，例如通过HTTP URL“/metrics”提供，或者使用外部服务提供的指标采集URL。Kubernetes从1.11版本开始，弃用基于Heapster组件完成Pod的CPU 使用率采集的机制，全面转向基于Metrics Server完成数据采集。Metrics Server将采集到的Pod性能指标数据通过聚合API（Aggregated API）如 metrics.k8s.io、custom.metrics.k8s.io和external.metrics.k8s.io提供给HPA 控制器进行查询

15.　　扩缩容算法详解 Autoscaler控制器从聚合API获取到Pod性能指标数据之后，基于下面的算法计算出目标Pod副本数量，与当前运行的Pod副本数量进行对比，决定是否需要进行扩缩容操作：

即当前副本数×（当前指标值/期望的指标值），将结果向上取整。当计算结果与1非常接近时，可以设置一个容忍度让系统不做扩缩容操作。容忍度通过kube-controller-manager服务的启动参数--horizontal- pod-autoscaler-tolerance进行设置，默认值为0.1（即10%），表示基于上述算法得到的结果在[-10%-+10%]区间内，即[0.9-1.1]，控制器都不会进行扩缩容操作。也可以将期望指标值（desiredMetricValue）设置为指标的平均值类型，例如targetAverageValue或targetAverageUtilization，此时当前指标值（currentMetricValue）的算法为所有Pod副本当前指标值的总和除以Pod 副本数量得到的平均值。此外，存在几种Pod异常的情况，如下所述：◎ Pod正在被删除（设置了删除时间戳）：将不会计入目标Pod副本数量。◎ Pod的当前指标值无法获得：本次探测不会将这个Pod纳入目标 Pod副本数量，后续的探测会被重新纳入计算范围。◎ 如果指标类型是CPU使用率，则对于正在启动但是还未达到 Ready状态的Pod，也暂时不会纳入目标副本数量范围。可以通过kube- controller-manager服务的启动参数--horizontal-pod-autoscaler-initial- readiness-delay设置首次探测Pod是否Ready的延时时间，默认值为30s。另一个启动参数--horizontal-pod-autoscaler-cpuinitialization-period设置首次采集Pod的CPU使用率的延时时间。如果在HorizontalPodAutoscaler中设置了多个指标，系统就会对每个指标都执行上面的算法，在全部结果中以期望副本数的最大值为最终结果。如果这些指标中的任意一个都无法转换为期望的副本数（例如无法获取指标的值），系统就会跳过扩缩容操作。最后，在HPA控制器执行扩缩容操作之前，系统会记录扩缩容建议信息（Scale Recommendation）。控制器会在操作时间窗口（时间范围可以配置）中考虑所有的建议信息，并从中选择得分最高的建议。这个值可通过kube-controller-manager服务的启动参数--horizontal-pod- autoscaler-downscale-stabilization-window进行配置，默认值为5min。这个配置可以让系统更为平滑地进行缩容操作，从而消除短时间内指标值快速波动产生的影响

标签：Node,副本,name,kubernetes,读书笔记,Taint,调度,第四版,Pod
来源： https://www.cnblogs.com/qinghe123/p/12512347.html