云原生集群管理运维IaC【免费下载链接】kopsKubernetes Operations (kOps) - Production Grade k8s Installation, Upgrades and Management项目地址https://gitcode.com/gh_mirrors/kop/kops点击查看免费下载InstanceGroup实例组命令行简称ig是 kOpsKubernetes Operations中描述一组行为一致的机器的核心资源在 AWS 上它直接对应一个 Auto Scaling GroupASG。本文以 docs/instance_groups.md 为主干结合 kOps 仓库源码API 定义、AWS 模型构建、校验逻辑深入剖析cloudLabels、suspendProcesses、instanceProtection、IMDSv2、外部负载均衡器、用户数据、Mixed Instances PolicySpot 混合实例策略、Warm Pool、实例生命周期上限等关键配置项帮助读者从能配进阶到懂原理直接应用于生产集群的节点池规划与运维。InstanceGroup 是什么API 形态与角色体系InstanceGroup表示一组在同一个可用区Availability Zone内、配置相似的机器在 AWS 上它直接映射为一个 Auto Scaling Group。从源码看其核心结构由TypeMeta、ObjectMeta与Spec InstanceGroupSpec三部分组成见 pkg/apis/kops/instancegroup.go#L37-L42type InstanceGroup struct { metav1.TypeMeta json:,inline metav1.ObjectMeta json:metadata,omitempty Spec InstanceGroupSpec json:spec,omitempty }每个 InstanceGroup 都有一个role字段决定该组机器的职责。kOps 定义了 7 种角色pkg/apis/kops/instancegroup.go#L57-L72角色常量值说明ControlPlaneControlPlane控制平面历史文档中称为 masterNodeNode工作节点BastionBastion堡垒机APIServerAPIServer仅运行 API ServerEtcdEtcd仅运行 etcdSchedulerScheduler仅运行调度器KubeControllerManagerKubeControllerManager仅运行 kube-controller-manager这些角色派生出一系列判断方法HasControlPlane()、RunsAPIServer()、RunsEtcd()等例如ControlPlane角色默认同时承担 API Server 与 etcd而APIServer/Etcd等独立角色用于把控制面拆分成更细的机器组。在实际编排时InstanceGroup 作为 Kubernetes API 对象保存于集群状态并拥有便捷的 CRD 打印列role、machineType、min、max、zones见 pkg/apis/kops/v1alpha2/instancegroup.go#L27-L32方便kubectl get ig直接查看摘要。cloudLabels给云资源打标签如果你需要在自动伸缩组或实例上添加标签并让标签传播到 ASG 的实例上可以在 InstanceGroup 的 spec 中设置cloudLabels。集群 spec 级别的 Cloud Labels 会被继承到所有实例组。spec: cloudLabels: billing: infra environment: dev从源码看CloudLabels的类型是map[string]stringpkg/apis/kops/instancegroup.go#L178最终在 AWS 模型构建阶段通过CloudTagsForInstanceGroup合并集群级与实例组级的标签后写入 ASG 的 Tagspkg/model/awsmodel/autoscalinggroup.go#L467-L471。标签通常用于成本分摊如billing、环境隔离如environment或配合 AWS 资源组的自动化运维。suspendProcesses暂停 ASG 的伸缩进程AWS 自动伸缩组自带多种 scaling processes 来维持 ASG 健康。某些场景下你可能希望禁用特定的伸缩活动。典型场景当你在一个 ASG 中运行多个可用区、并使用 Kubernetes Cluster Autoscaler 时autoscaler 会精确移除未使用的实例而 ASG 的AZRebalance进程可能会在无预警的情况下重新平衡可用区、导致实例被意外替换。此时可以挂起该进程spec: suspendProcesses: - AZRebalance实现上SuspendProcesses是字符串数组pkg/apis/kops/instancegroup.go#L196在构建 ASG 任务时被追加到进程列表并写入t.SuspendProcessespkg/model/awsmodel/autoscalinggroup.go#L473-L475。可挂起的进程还包括Launch、Terminate、AddToLoadBalancer、AlarmNotification、ScheduledActions等请按实际运维需求选择。instanceProtection防止实例被 ASG 缩容ASG 可能为了平衡实例类型、区域等原因自动扩容/缩容。Instance protection 可以防止受保护的实例被 ASG 缩容时终止spec: instanceProtection: true源码中该字段为*boolpkg/apis/kops/instancegroup.go#L206构建 ASG 任务时默认初始化为false仅当 spec 显式设置时才覆盖默认值pkg/model/awsmodel/autoscalinggroup.go#L437 与 L477-L479。注意实例保护与 AZRebalance 搭配使用时要考虑平衡性过度保护可能妨碍 ASG 的正常容量管理。instanceMetadataEC2 实例元数据服务IMDSv2新创建的集群默认启用 IMDSv2自 Kubernetes 1.27 起该默认值同样应用于存量集群。所有节点角色的默认 hop limit 均为 1。显式启用 IMDSv2spec: instanceMetadata: httpTokens: required禁用 IMDSv2降级为 IMDSv1 可用spec: instanceMetadata: httpTokens: optionalInstanceMetadataOptions定义了两个字段pkg/apis/kops/instancegroup.go#L284-L292httpTokens元数据请求的 token 使用状态默认为requiredhttpPutResponseHopLimitHTTP PUT 响应跳数上限值越大元数据请求可传输的距离越远默认值为 1。在 AWS 模型构建中这两个字段被映射到 LaunchTemplate 的元数据选项pkg/model/awsmodel/autoscalinggroup.go#L323-L329默认即写入LaunchTemplateHttpTokensStateRequiredpkg/model/awsmodel/autoscalinggroup.go#L212。IMDSv2 能显著降低 SSRF 攻击面安全合规场景建议保持required并配合 hop limit1 防止元数据被容器网络内的恶意 Pod 窃取。externalLoadBalancers挂接外部负载均衡器一个实例组最多可以关联 10 个负载均衡器。挂接后实例组内新启动的任何实例都会自动注册到这些负载均衡器上。典型场景为 Ingress Controller 创建专用节点池Ingress 以 NodePort 方式暴露你手动创建负载均衡器并关联到该实例组此后负载均衡器的流量会自动分发到这些节点。你可以通过loadBalancerName关联 AWS Classic ELB或通过targetGroupArn关联目标组Target GroupALB/NLB 使用apiVersion: kops.k8s.io/v1alpha2 kind: InstanceGroup metadata: labels: kops.k8s.io/cluster: k8s.dev.local name: ingress spec: machineType: m4.large maxSize: 2 minSize: 2 role: Node externalLoadBalancers: - targetGroupArn: arn:aws:elasticloadbalancing:eu-west-1:123456789012:targetgroup/my-ingress-target-group/0123456789abcdef - loadBalancerName: my-elb-classic-load-balancer源码中LoadBalancerSpec包含LoadBalancerName与TargetGroupARN两个指针字段pkg/apis/kops/instancegroup.go#L483-L489。模型构建时loadBalancerName被转换为共享的 ClassicLoadBalancer 任务、targetGroupArn被解析为目标组名称并生成共享 TargetGroup 任务随后按名称排序挂到 ASG 上pkg/model/awsmodel/autoscalinggroup.go#L511-L539。注意v1alpha2 中该字段的 JSON 键是targetGroupArn新 API 中统一为targetGroupARN见下文 API 变更表。detailedInstanceMonitoring详细监控启用详细监控后CloudWatch 监控数据从每 5 分钟一次变为每 1 分钟一次便于生产环境快速排障spec: detailedInstanceMonitoring: true注意启用详细监控会产生额外的 CloudWatch 计费。additionalUserData注入 cloud-init 用户数据kOps 使用 cloud-init 在开机时初始化并配置主机。如果你的基础设施已经使用了 cloud-init 的某些能力可以通过additionalUserData字段向主机供应额外的用户数据。合法的用户数据 content-type 列表可参考 cloud-init MIME 多部分归档格式脚本会按字母顺序执行见 cloud-init scripts-per-instance。spec: additionalUserData: - name: myscript.sh type: text/x-shellscript content: | #!/bin/sh echo Hello World. The time is now $(date -R)! | tee /root/output.txt - name: local_repo.txt type: text/cloud-config content: | #cloud-config apt: primary: - arches: [default] uri: http://local-mirror.mydomain search: - http://local-mirror.mydomain - http://archive.ubuntu.com重要限制在 Flatcar-OS 上不支持传入 additionalUserData会导致节点无法启动。实现原理UserData结构体包含Name、Type、Content三个字段pkg/apis/kops/instancegroup.go#L334-L342。在 AWS 上nodeup 引导脚本会与额外用户数据一起被打包为 MIME 多部分归档Content-Type: multipart/mixed边界为MIMEBOUNDARY其中 nodeup.sh 作为text/x-shellscript写入其余部分按name逐个写入pkg/model/resources/nodeup.go#L468-L513。因此脚本的执行顺序遵循 cloud-init 的字母序约定建议在命名时显式编号。compressUserData压缩用户数据kOps 1.19 起默认支持压缩部分用户数据以节省空间规避某些云平台的体积上限。目前仅压缩 nodeup.sh 中的 Specs 部分spec: compressUserData: true在引导脚本构建流程中该开关会直接传入 nodeup 脚本模板{{ if CompressUserData -}}见 pkg/model/resources/nodeup.go#L226并通过AWSMultipartMIME之前的 gzip/base64 流程落地pkg/model/resources/nodeup.go#L461-L465。若实例组配置较大且接近用户数据上限开启该选项是低成本解决方案。packages批量安装系统包kOps 1.24 起默认支持通过packages字段以字符串数组形式为实例组内的主机安装额外的系统包apiVersion: kops.k8s.io/v1alpha2 kind: InstanceGroup metadata: name: nodes spec: packages: - nfs-common注意包名与发行版强相关kOps 不会做任何校验。指定错误的包名可能导致节点无法启动。sysctlParameters自定义内核运行时参数kOps 1.17 起默认支持通过sysctlParameters以字符串数组形式为实例组添加自定义内核运行时参数。每个字符串必须是variablevalue形式写法与 sysctl.conf 一致参见sysctl(8)手册apiVersion: kops.k8s.io/v1alpha2 kind: InstanceGroup metadata: name: nodes spec: sysctlParameters: - fs.pipe-user-pages-soft524288 - net.ipv4.tcp_keepalive_time200这些参数最终会落在该实例组节点的 drop-in 文件中。与普通 file asset 不同以这种方式指定的内核参数会自动执行sysctl --system完成应用。从源码看sysctlParameters会被写入 nodeup 配置并在节点启动阶段合并nodeup/pkg/model/sysctls.go#L175确保内核参数在每次引导时都能正确生效。mixedInstancesPolicy仅 AWS混合实例策略与 Spot 容量优化使用 EC2 Spot 与capacity-optimized分配策略的 Mixed Instances Policy可以让 ASG 优先选择可用容量最高的实例类型从而降低实例组中 Spot 中断的概率。包含混合实例策略的实例组可以通过kops toolbox instance-selector命令生成。instance-selector 接受用户提供的资源参数vcpus、memory 等动态筛选符合条件的实例类型kops toolbox instance-selector spotgroup --vcpus 4 --flexible --usage-class spot生成后的实例组配置示例如下apiVersion: kops.k8s.io/v1alpha2 kind: InstanceGroup metadata: labels: kops.k8s.io/cluster: spot.k8s.local name: spotgroup spec: image: 099720109477/ubuntu/images/hvm-ssd-gp3/ubuntu-noble-24.04-amd64-server-20260714 machineType: c3.xlarge maxSize: 15 minSize: 2 mixedInstancesPolicy: instances: - c3.xlarge - c4.xlarge - c5.xlarge - c5a.xlarge onDemandAboveBase: 0 onDemandBase: 0 spotAllocationStrategy: capacity-optimized nodeLabels: kops.k8s.io/instancegroup: spotgroup role: Node subnets: - us-east-1a - us-east-1b - us-east-1cInstancesinstances是允许在 EC2 Auto Scaling 组中运行的实例类型列表pkg/apis/kops/instancegroup.go#L297。构建时会映射为 ASG 的MixedInstanceOverridespkg/model/awsmodel/autoscalinggroup.go#L582。onDemandAllocationStrategy指定如何分配实例类型来满足按需On-Demand容量pkg/apis/kops/instancegroup.go#L301。onDemandBaseOn-Demand 实例必须满足的 ASG 容量最小值这部分基础容量会在组扩容时优先供应pkg/apis/kops/instancegroup.go#L302-L304。onDemandAboveBase控制超出onDemandBase之后的额外容量中按需实例与 Spot 实例的百分比取值范围 0–100默认 100即超出部分 100% 使用按需实例、0% 使用 Spot。当设置onDemandAboveBase: 0且onDemandBase: 0时整个组的容量将全部使用 Spot。spotAllocationStrategy指定如何跨 Spot 实例池分配实例pkg/apis/kops/instancegroup.go#L313lowest-priceASG 使用价格最低的 Spot 池启动实例并将实例平均分配到spotInstancePools指定的池数量中capacity-optimizedASG 根据可用的 Spot 容量选择最优的 Spot 池启动实例中断概率更低其余支持值还包括diversified、capacity-optimized-prioritized、price-capacity-optimized完整列表见 pkg/apis/kops/instancegroup.go#L244-L264。spotInstancePools仅在 Spot 分配策略为lowest-price时使用表示 Spot 实例分配所跨的 Spot 池数量池由 LaunchTemplate 的 Overrides 数组中不同实例类型决定默认值为 2pkg/apis/kops/instancegroup.go#L314-L316。CapacityRebalancekOps 1.26 起默认支持如果使用 Spot 实例建议在实例组中启用capacityRebalance。这会配置 ASG 在收到 rebalance 推荐时主动替换 Spot 实例详见 EC2 Auto Scaling 容量再平衡spec: capacityRebalance: true对应字段为*boolpkg/apis/kops/instancegroup.go#L192构建时写入 ASG 任务pkg/model/awsmodel/autoscalinggroup.go#L481-L483。instanceRequirementskOps 1.24 起默认支持除了指定具体机型还可以让实例组使用所有满足给定条件的机型交由 EC2 Fleet 自动选择spec: mixedInstancesPolicy: instanceRequirements: cpu: min: 2 max: 16 memory: min: 2G注意burstable可突发实例始终包含在候选集合中。可以使用excludedInstanceTypes从候选集合中排除机型支持一个或多个星号*通配符来匹配实例类型、规格或代际例如m7i.8xlarge、c7*.*、m7a.*、r*、*3*spec: mixedInstancesPolicy: instanceRequirements: cpu: min: 2 max: 16 memory: min: 2G excludedInstanceTypes: - t2.* - t3.*实现上InstanceRequirementsSpec包含CPU/MemoryMinMaxSpec类型为resource.Quantity与ExcludedInstanceTypespkg/apis/kops/instancegroup.go#L319-L332。模型构建时将 CPU/内存上下限换算为整数内存以 MB 为单位ScaledValue(resource.Mega)并传递ExcludedInstanceTypespkg/model/awsmodel/autoscalinggroup.go#L545-L580。warmPool仅 AWS预热池加速扩容kOps 1.21 起默认支持Warm Pool 包含预先初始化好的 EC2 实例它们能比常规实例快得多地加入集群。这些实例会先运行 kOps 配置流程、拉取已知的容器镜像然后关机。当 ASG 需要扩容时如果 Warm Pool 中有可用实例会直接从中取出。最简单的启用方式spec: warmPool: {}这会使用 AWS 默认设置。调整池大小spec: warmPool: minSize: 3 maxSize: 10也可以在集群 spec 中为所有 Node 或 APIServer 角色的实例组设置默认的warmPool。若集群级已启用 Warm Pool实例组级可通过设置maxSize: 0来禁用。WarmPoolSpec字段定义见 pkg/apis/kops/cluster.go#L1135-L1150minSizeWarm Pool 的最小容量maxSizeWarm Pool 的最大容量实际目标容量会减去实例组自身的期望容量除非结果小于 minSize默认取实例组的 MaxSizeenableLifecycleHook是否添加 ASG 生命周期钩子确保 nodeup 运行完成lifecycleHookTimeout生命周期钩子超时时间秒additionalImages预热阶段额外拉取的容器镜像列表。IsEnabled()的实现是MaxSize nil || *MaxSize ! 0pkg/apis/kops/cluster.go#L1152-L1154因此maxSize: 0即表示关闭。集群级与实例组级的默认值解析由ResolveDefaults完成且控制平面与堡垒机角色默认返回MaxSize: 0不启用pkg/apis/kops/cluster.go#L1156-L1171相关测试见 pkg/apis/kops/cluster_test.go#L26-L150。校验规则pkg/apis/kops/validation/validation.go#L2226-L2240maxSize不能为负且不能小于minSizeminSize不能为负additionalImages只能在实例组 spec 中设置集群级不允许携带。附加容器镜像有些场景希望在预热阶段就下载大型容器镜像以缩短节点加入后工作负载的启动时间。可通过additionalImages字段指定spec: warmPool: additionalImages: - nvcr.io/nvidia/tritonserver:24.10-py3 - nvcr.io/nvidia/tritonserver:25.11-vllm-python-py3生命周期钩子默认情况下 AWS 并不保证 kOps 配置流程一定能完整运行也不保证配置完成后实例能及时关机。为了确保这两点需要生命周期钩子Lifecycle Hook。安全警告启用生命周期钩子前必须保护好你的元数据 API。否则集群中任意 Pod 都可以用ABANDONED结果完成钩子导致任何实例都无法加入集群。生命周期钩子默认超时为 600s可通过warmPoolspec 中的lifecycleHookTimeout字段自定义当预热阶段需要拉取更大的附加容器镜像时可能需要调大超时spec: warmPool: enableLifecycleHook: true lifecycleHookTimeout: 900 instanceMetadata: httpPutResponseHopLimit: 1 httpTokens: required当钩子启用时kOps 还会在 AWS IAM 策略中为 ASG 附加相应的 lifecycle hook 权限见 pkg/model/awsmodel/iam.go#L86-L113保证 nodeup 能正常完成钩子动作。maxInstanceLifetime仅 AWS实例最大服役时长kOps 1.24 起默认支持maxInstanceLifetime指定实例在服务中可以被保留的最长时间Go duration 格式如48h超过后实例会被终止并替换。常见用途是满足内部安全策略或外部合规要求下的定期替换——本质上是给集群注入临时性。必须指定至少 24h86,400 秒的值要清除之前设置的值将其设为 0 即可spec: maxInstanceLifetime: 48h源码中该字段类型为*metav1.Durationpkg/apis/kops/instancegroup.go#L236。构建 ASG 任务时换算为秒并写入MaxInstanceLifetime未设置时显式写 0pkg/model/awsmodel/autoscalinggroup.go#L602-L607。校验逻辑强制要求非 0 值必须 ≥ 86400 秒pkg/apis/kops/validation/aws.go#L159-L168。API 变更v1alpha2 到新 API 的字段迁移kOps 正在将v1alpha2API 升级到更新版本。新 API 仍在开发中但内部形态与校验错误消息已经使用新字段名。下表跟踪了相关变更不含已废弃字段的移除v1alpha2 FieldNew FieldassociatePublicIpassociatePublicIPexternalLoadBalancers[*].targetGroupArnexternalLoadBalancers[*].targetGroupARNrootVolumeEncryptionrootVolume.encryptionrootVolumeEncryptionKeyrootVolume.encryptionKeyrootVolumeIopsrootVolume.iopsrootVolumeOptimizationrootVolume.optimizationrootVolumeSizerootVolume.sizerootVolumeThroughputrootVolume.throughputrootVolumeTyperootVolume.type其中targetGroupArn的迁移已经在内部结构中落实新 API 定义使用TargetGroupARNpkg/apis/kops/instancegroup.go#L488而 v1alpha2 的 JSON 键仍为targetGroupArnpkg/apis/kops/v1alpha2/instancegroup.go#L297。rootVolume*系列字段则统一收敛到rootVolume子对象InstanceRootVolumeSpec含size、type、iops、throughput、optimization、encryption、encryptionKey见 pkg/apis/kops/instancegroup.go#L266-L282。编写新配置时建议直接使用新字段名避免后续迁移成本。其他值得关注的 InstanceGroup 能力InstanceGroupSpec还包含大量本文未展开但同样常用的字段完整字段清单见 pkg/apis/kops/instancegroup.go#L137-L242machineType/image实例机型与 AMI/镜像minSize/maxSize/autoscale容量与 Cluster Autoscaler 联动Node 角色默认 min/max 为 2见 pkg/model/awsmodel/autoscalinggroup.go#L440-L451subnets/zones放置子网或可用区nodeLabels/taints节点标签与污点kOps 会自动为节点打上kops.k8s.io/instancegroup组名标签见 pkg/apis/kops/instancegroup.go#L467-L472rootVolume根卷大小、类型、IOPS、加密等volumes/volumeMounts附加数据盘及挂载hooks节点初始化钩子可覆盖集群级配置maxPrice/spotDurationInMinutes/instanceInterruptionBehaviorSpot 竞价与中断行为iam/additionalSecurityGroups/securityGroupOverride身份与安全组定制updatePolicy自动更新策略automatic默认 /external手动或外部系统管理manager节点生命周期管理器CloudGroup默认 /Karpenter见 pkg/apis/kops/instancegroup.go#L129-L134。小结InstanceGroup 是 kOps 管理节点池的操作面它把 Kubernetes 侧的意图角色、容量、标签、用户数据、Spot 策略翻译为云厂商侧的 Auto Scaling 资源并在 nodeup 引导阶段完成主机初始化。掌握本文涉及的配置项与底层实现ASG 构建于 pkg/model/awsmodel/autoscalinggroup.go、用户数据打包于 pkg/model/resources/nodeup.go、参数校验于 pkg/apis/kops/validation你就能针对 Spot 混合实例、快速扩容Warm Pool、合规轮换maxInstanceLifetime等生产场景做出正确的配置决策。更完整的字段说明可继续阅读 docs/instance_groups.md 对应的 API 参考页面以及 docs/tutorial/working-with-instancegroups.md 了解日常操作流程。赞分享云原生集群管理运维IaC【免费下载链接】kopsKubernetes Operations (kOps) - Production Grade k8s Installation, Upgrades and Management项目地址https://gitcode.com/gh_mirrors/kop/kops点击查看免费下载相关推荐kOps 实战指南使用 kops create instancegroup 创建与管理 InstanceGroupkOps 实战指南使用 kops create instancegroup 创建与管理 InstanceGroup 导读 本文围绕 kOpsKubernet云原生集群管理运维IaCAntiMicroX手柄映射完全指南从基础配置到高级应用AntiMicroX手柄映射完全指南从基础配置到高级应用 想要让不支持手柄的PC游戏也能享受手柄操控的乐趣吗AntiMicroX作为一款免费开源的手柄映射工桌面应用GUI 自动化kOps kops edit instancegroup 命令完全指南交互式与非交互式修改节点组配置kOps kops edit instancegroup 命令完全指南交互式与非交互式修改节点组配置 导读 kops edit instancegroup 是云原生集群管理运维IaC创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考