affinity

Node Affinity Affinity 翻译成中文是“亲和性”，它对应的是 Anti-Affinity，我们翻译成“互斥”。这两个词比较形象，可以把 pod 选择 node 的过程类比成磁铁的吸引和互斥，不同的是除了简单的正负极之外，pod 和 node 的吸引和互斥是可以灵活配置的。 Affinity的优点： 匹配有更多的逻辑组合，不只是字符串的完全相等 调度分成软策略(soft)和硬策略(hard)，在软策略下，如果没有满足调度条件的节点，pod会忽略这条规则，继续完成调度。 目前主要的node affinity： requiredDuringSchedulingIgnoredDuringExecution 表示pod必须部署到满足条件的节点上，如果没有满足条件的节点，就不停重试。其中IgnoreDuringExecution表示pod部署之后运行的时候，如果节点标签发生了变化，不再满足pod指定的条件，pod也会继续运行。 requiredDuringSchedulingRequiredDuringExecution 表示pod必须部署到满足条件的节点上，如果没有满足条件的节点，就不停重试。其中RequiredDuringExecution表示pod部署之后运行的时候，如果节点标签发生了变化，不再满足pod指定的条件，则重新选择符合要求的节点。

[toc] Pod Affinity 通过 《K8S调度之节点亲和性》 ，我们知道怎么在调度的时候让pod灵活的选择node，但有些时候我们希望调度能够考虑pod之间的关系，而不只是pod与node的关系。于是在kubernetes 1.4的时候引入了pod affinity。 为什么有这样的需求呢？举个例子，我们系统服务 A 和服务 B 尽量部署在同个主机、机房、城市，因为它们网络沟通比较多；再比如，我们系统数据服务 C 和数据服务 D 尽量分开，因为如果它们分配到一起，然后主机或者机房出了问题，会导致应用完全不可用，如果它们是分开的，应用虽然有影响，但还是可用的。 pod affinity 可以这样理解：调度的时候选择（或者不选择）这样的节点 N ，这些节点上已经运行了满足条件 X。条件 X 是一组 label 选择器，它必须指明作用的 namespace（也可以作用于所有的 namespace），因为 pod 是运行在某个 namespace 中的。 这里的X指的是集群中的节点、机架、区域等概念，通过kubernetes内置节点标签中的key来进行声明。这个key的名字为topologyKey，意为表达节点所属的topology范围： kubernetes.io/hostname failure-domain.beta.kubernetes.io/zone failure

在K8S平台上，我们很少会直接创建一个Pod，在大多数情况下会通过RC，Deployment，DaemonSet，Job等控制器完成一组Pod副本的创建，调度及全生命周期的自动控制任务。 在k8s 1.9以前，在RC等对象被删除后，它们所创建的Pod副本都不会被删除；在k8s 1.9以后，这些Pod副本会被一并删除。 如果不希望这样做，可以通过kubectl命令的“--cascade=false”参数来取消这一默认特性： kubectl delete replicaset my-reset --cascade=false NodeSelector：定向调度 在一些情况下，我们需要将pod调度到指定的一些Node上，可以通过Node的标签（Label）和Pod的nodeSelector属性相匹配。 首先通过kubectl label 命令给目标Node打上一些标签： kubectl label nodes node-name label-key=label-vaule kubectl label nodes 172.20.103.2 test=jinguanhua 然后，在pod的定义中加上nodeSelector的设置： kubectl create -f redis.yaml apiVersion: v1 kind: deploy metadata: name: redis

通常情况下，Pod分配到哪些Node是不需要管理员操心的，这个过程会由scheduler自动实现。但有时，我们需要指定一些调度的限制，例如某些应用应该跑在具有SSD存储的节点上，有些应用应该跑在同一个节点上等等。 nodeSelector ： 首先我们为Node规划标签，然后在创建部署的时候，通过使用nodeSelector标签来指定Pod运行在哪些节点上。 亲和性（Affinity ）与反亲和性（AntiAffinity）： 亲和性：应用A与应用B两个应用频繁交互，所以有必要利用亲和性让两个应用的尽可能的靠近，甚至在一个node上，以减少因网络通信而带来的性能损耗。 反亲和性：当应用的采用多副本部署时，有必要采用反亲和性让各个应用实例打散分布在各个node上，以提高HA。 包含：nodeAffinity（主机亲和性），podAffinity（POD亲和性）以及podAntiAffinity（POD反亲和性） 策略名称 匹配目标 支持的操作符 支持拓扑域 设计目标 nodeAffinity 主机标签 In,NotIn,Exists,DoesNotExist,Gt,Lt 不支持 决定Pod可以部署在哪些主机上 podAffinity Pod标签 In，NotIn，Exists，DoesNotExist 支持 决定Pod可以和哪些Pod部署在同一拓扑域 PodAntiAffinity

一、应用程序优化 （1）编译器优化。适当开启编译器优化选项，在编译阶段提升性能。gcc提供优化选项-On会自动对应用程序的代码进行优化。 （2）算法优化。使用复杂度更低的算法，可以显著加快处理速度。在数据比较大的情况下，可以用O(nlogn)的排序算法（如快排、归并排序等），代替O(n^2)的排序算法（如冒泡、插入排序等）。 （3）异步处理。使用异步处理，可以避免程序因为等待某个资源而一直阻塞，从而提升程序的并发处理能力。把轮询替换为事件通知，就可以避免轮询耗费CPU的问题。 （4）多线程代替多进程。相对于进程的上下文切换，线程的上下文切换并不切换进程地址空间，因此可以降低上下文切换的成本。 （5）善用缓存。经常访问的数据或者计算过程中的步骤，可以放到内存中缓存起来，在下次用时就能直接从内存中获取，加快程序的处理速度。 二、系统优化 1、CPU绑定 （1）CPU绑定：把进程绑定到一个或者多个CPU上，可以提高CPU缓存的命中率，减少跨CPU调度带来的上下文切换问题。 （2）CPU孤立：将CPU分组，并通过CPU Affinity机制为其分配进程。指定CPU由特定进程独占，不允许其它进程再使用。 2、进程CPU资源限制 使用Linux cgroups来设置进程CPU使用上限，可以防止由于某个应用自身的问题，而耗尽系统资源。 3、进程优先级调整 使用nice调整进程优先级

一 Pod生命周期管理 1.1 Pod生命周期 Pod在整个生命周期过程中被系统定义了如下各种状态。 状态值 描述 Pending API Server已经创建该Pod，且Pod内还有一个或多个容器的镜像没有创建，包括正在下载镜像的过程。 Running Pod内所有容器均已创建，且至少有一个容器处于运行状态、正在启动状态或正在重启状态。 Succeeded Pod内所有容器均成功执行退出，且不会重启。 Failed Pod内所有容器均已退出，但至少有一个容器退出为失败状态。 Unknown 由于某种原因无法获取该Pod状态，可能由于网络通信不畅导致。 1.2 Pod重启策略 Pod重启策略（RestartPolicy）应用于Pod内的所有容器，并且仅在Pod所处的Node上由kubelet进行判断和重启操作。当某个容器异常退出或者健康检查失败时，kubelet将根据RestartPolicy的设置来进行相应操作。 Pod的重启策略包括Always、OnFailure和Never，默认值为Always。 Always：当容器失效时，由kubelet自动重启该容器； OnFailure：当容器终止运行且退出码不为0时，由kubelet自动重启该容器； Never：不论容器运行状态如何，kubelet都不会重启该容器。 kubelet重启失效容器的时间间隔以sync

作者：李彬，赵雪枫，金融科技工程师，架构师社区特邀作者！ 应用服务性能调优，是每个系统投产前都需要关注的问题，系统及软件层面的调优方法均有大量文章介绍，但在所有招数使出后，是否就无潜可挖了？如果了解Linux内核运行特征，经过简单的配置，仍存在不少可行的方案。本文将介绍的是基于Linux内核CPU亲和性参数调整，榨取最后一丝性能优势的方案。 一、背景知识 CPU是常规应用运行计算的核心，从性能角度至少需要了解物理CPU、逻辑CPU和超线程技术实现。 1. 物理CPU：机器上实际安装的CPU个数。 2. 逻辑CPU：物理CPU会有多个逻辑运算核心，基于Intel的超线程技术（Hyper-Threading），可以在此基础上形成更多核心算力。 3. 超线程技术（Hyper-Threading）：就是利用特殊的硬件指令，把一个CPU核模拟成多个逻辑CPU，形成多核多线程CPU。 综上所述，三者的逻辑关系如下： 逻辑CPU的数量=物理CPU的数量*CPU的核数*2（如果支持并开启了超线程的话） 二、CPU的亲和性参数原理 CPU的亲和性是一种调度属性，它可以将一个进程绑定到一个或者一组CPU上。CPU的亲和性分为两种：软亲和性和硬亲和性。 1）软CPU亲和性就是进程要在指定的CPU上尽量长时间地运行而不被迁移到其他处理器上运行。Linux内核的自身特性