这期内容当中小编将会给大家带来有关基于K8s的自定义控制器Enhanced Statefulset怎么用，文章内容丰富且以专业的角度为大家分析和叙述，阅读完这篇文章希望大家可以有所收获。
成都创新互联长期为1000+客户提供的网站建设服务，团队从业经验10年，关注不同地域、不同群体，并针对不同对象提供差异化的产品和服务；打造开放共赢平台，与合作伙伴共同营造健康的互联网生态环境。为通许企业提供专业的成都网站建设、成都网站制作，通许网站改版等技术服务。拥有十年丰富建站经验和众多成功案例,为您定制开发。
下面要讲的产品——Enhanced statefulset。
顾名思义，Enhanced statefulset就是我们在statefulset的基础上对控制器做了进一步的扩展。它主要解决Pod绑定静态IP问题，同时也解决了statefulset在升级过程中不允许同时升级多个实例的限制。另外，它还可以在节点故障时支持Pod和IP的迁移。
前面已经提到了静态IP的重要场景是业务依赖的周边组件都以IP作为实例唯一标识，所以上到Kubernetes后仍然需要Pod实例保持IP不变。相信很多用户也面临着类似的问题，下面就来分享一下实现原理。
我们主要是通过对Enhanced Statefulset Controller 、 Scheduler、CNI这几个模块扩展来支持Enhanced Statefulset的Pod绑定静态IP。
Enhanced Statefulset Controller 对静态IP的管理主要是维护更新Static IP CR来实现的。当Controller收到创建请求时，会首先检查要创建的实例是否已经有对应的static IP CR记录，若记录不存在则会创建一个新的记录。在稍后scheduler完成调度，CNI完成静态IP分配后，controller会监听Pod信息并将其更新到Static IP CR中。反之若创建实例时，对应的static IP CR记录已经存在则表示这个Pod是删除重建，Controller会将static IP CR中的信息更新到Pod上，scheduler和CNI根据pod上的配置进行亲和性调度和IP分配。
StaticIP CRD中记录了负载类型、负载名称、节点、IP和Pod信息。其中IP信息在Pod实例上以annotation
新增缓存：原有 Node 缓存基础上新增 staticIPNode 缓存,用于计算和缓存 staticIPPod 资源占用情况、缓存 IP 数量、Pod cpu/内存 使用量；
新增predicate ：
PodFitsResourcesWithStaticIPPodPred Node 现有资源基础上基于 staticIPPod 占用资源再次过滤,达到资源预占目的；
CheckPodAnnotationWithStaticIPPred 检查pod 是否包含 static ip 的指定 node annotation, 并仅保留指定 node 结果只 fit node 列表。
概括起来核心思路就是将静态IP Pod所占用的资源作为一种特殊资源单独标识，在调度时进行匹配调度达到资源预占目的。
CNI 在静态IP场景下主要实现以下三个功能：
按照Pod annotation上指定的IP分配，若无IP则从IP池中随机分配一个IP并将此记录更新到Pod中 ；
IP地址预留，当绑定静态IP的Pod删除重建时，CNI会检查static IP CR记录，如果记录未删除则IP地址不释放，确保重建的Pod能够拿到绑定的IP；
在大规模集群场景下，为了提高SDN网络性能，我们要求CNI必须使用IP range模式。在这种模式下，弹性网卡上绑定的是IP CIDR，例如10.0.0.0/24,而不是某一个具体IP。IP迁移，释放和申请都是以CIDR的形式进行。
最后，我们通过一个创建流程来展示一下Enhanced statefulset对象如何绑定静态IP：
用户创建一个enhanced statefulset对象，该请求首先发送到API server；
enhanced statefulset controller监听到该请求，首先查询是否有该Pod对应的CR记录，若没有则创建新的CR，若已经有CR，则将CR中的信息更新的新建的Pod中；
enhanced statefulset controller开始创建Pod；
Scheduler根据Pod的affinity信息将其调度到相应的节点上，若无affinity信息则是新建pod正常调度。同时调度时会触发资源预留逻辑确保已有的静态IP Pod的资源不被占用；
CNI查看Pod静态IP记录，如无记录则随机分配IP并将IP信息更新到Pod上，若有记录则按记录分配；
StaticIP controller监听到Pod上静态IP信息变更，并将此信息更新到CR中。
除了支持静态IP这个强需求，我们考虑的第二个重点就是尽可能将Kubernetes的DevOps能力赋能给业务场景。社区原生的 StatefulSet 在升级过程中不允许同时升级多个实例，这主要是为了某些有状态应用需要依次按序升级的需求。但这样带来的问题是效率太低，而集团业务对升级失败和顺序有一定容忍度，为了提升升级效率，我们定义了MaxUnavailable 参数，它允许应用实例被并行升级，且始终保持最大不可用的实例数不超过 MaxUnavailable 的限制数。
此外，为了保证升级足够可控，Enhanced Statefulset可以通过Partitions进行分批升级。每个批次升级完成后通过再次更新Partitions触发下一次升级，如果发现升级过程中遇到问题也可以进行Rollback回滚或Paused暂停。
通过这些优化，Enhanced Statefulset具备更好了灵活性，既可以兼容原生Statefulset规则严格按照实例顺序升级，确保有状态服务的可靠性。又可以兼具类似Deployment的能力，以更高效的方式并发升级。同时还可以分批手工触发，基本覆盖了集团业务的绝大部分场景。
下面通过一个示例来具体了解下：
用户创建了一个Enhanced Statefulset的应用，副本数为6，应用从staticip-example-0到staticip-example-5，Partitions设置为3, MaxUnavailable设置为2。
1apiVersion: jke.jdcloud.com/v1alpha1
2kind: EnhancedStatefulSet
3metadata:
4 name: staticip-example
5 annotations:
6 staticip.jke.jdcloud.com/enable: "true" #打开静态IP功能
7spec:
8 serviceName: enhanced-sts-service-example
9 replicas: 6
10 selector:
11 matchLabels:
12 apps: staticip-example
13 updateStrategy:
14 rollingUpdate:
15 maxUnavailable: 2 #最大不可用数量，允许并行升级，并且容忍副本不可用
16 partition: 3 #enhanced statefulset创建的Pod都有index，命名从0开始，例如pod-0 pod-1 所有index大于等于partition值的实例升级，通过变更partition值来实现分批升级
17 paused: false
18 podUpdatePolicy: ReCreate
19 type: RollingUpdate
20 template:
21 metadata:
22 labels:
23 apps: staticip-example
24 spec:
25 containers:
26 - image: nginx:v1 # nginx:v1 变更为 nginx:v2 触发升级当用户将镜像从v1升级到v2时,升级流程如下：
Enhanced Statefulset Controller将staticip-example-3到staticip-example-5这3个副本并发升级到v2版本，其中staticip-example-4不可用，因为MaxUnavailable当前值为2，不影响应用继续升级；
用户将Partitions设置为0，enhanced statefulset controller将剩余3个副本staticip-example-0到staticip-example-2并发升级到v2版本，其中staticip-example-2不可用；
随后用户对不可用Pod进行手工修复，所有实例均恢复正常。
在执行第二步时，如果第一步升级有两个实例不可用触发MaxUnavailable阈值，则用户在第二步即使将Partitions设置为0也不会触发再次升级。
最后，再和大家聊一下故障迁移功能。静态IP为业务上Kubernetes带来便利的同时也带来了问题，其中一个比较突出的问题就是故障迁移场景。故障迁移有几个前提条件：
静态IP Pod和其所绑定的IP需要迁移到同一个目标节点上，这样才能保证Pod迁移后IP不变；
前面已经提到在大规模集群下我们要求CNI必须配置成IP Range模式，这种模式下IP CIDR不能拆分到更细粒度迁移，一个节点绑定的一个IP CIDR只能迁移到一个目标节点。这就意味着，所有绑定静态IP的Pod也必须迁移到同一个目标。这样就带来了一个问题，怎样才能保证目标节点有足够的资源；
故障迁移后，业务希望最大程度保留原来的物理拓扑，虚机配置与规格；
针对这些问题，我们当前给出的方案是node migration。基本流程如下：
当节点处于失联状态超过容忍的时间窗口后（用户可根据业务情况配置时间窗口阈值），node operator会将此节点禁用；
node operator会创建一台与故障节点同规格同AZ的目标节点；
node operator将故障节点的IP和Pod 指定迁移到新节点重新创建，并更新元数据信息；
将故障节点删除。
上述就是小编为大家分享的基于K8s的自定义控制器Enhanced Statefulset怎么用了，如果刚好有类似的疑惑，不妨参照上述分析进行理解。如果想知道更多相关知识，欢迎关注创新互联行业资讯频道。
