两招搞定K8s改造？全球领先数据云Snowflake这样做

Snowflake 的 IT 云运营团队迎来了云基础设施演进的关键转折点。随着 Amazon EKS 上容器化工作负载规模不断扩大，他们亟需一个更现代、安全且高效的操作系统。
其原有基于 Amazon Linux 2（AL2）的架构虽能运行，却存在多重挑战：

• 安全加固需频繁更新补丁导致运维负担加重；
  
• 大规模节点的一致更新难以保障；
  
• AL2 节点启动速度较慢影响扩缩容效率
  

经过全面评估，AWS 专为容器优化设计的操作系统 Bottlerocket 成为解决这些问题的理想选择。
01/Bottlerocket 是什么？

Bottlerocket 是 AWS 专为容器优化场景设计的开源操作系统。
与传统通用型操作系统不同，Bottlerocket 采用了最小化设计，去除了不必要的软件包，仅包含运行容器所需的核心组件。
它具有 API 化配置管理、系统更新快速可靠、提高容器安全防护等特点，大幅提升了集群节点的安全性、可维护性与启动速度。
Github 地址：https://github.com/bottlerocket-os/bottlerocket#bottlerocket-os
02/迁移策略：从 AL2 到 Bottlerocket 的演进

从 AL2 转向 Bottlerocket，不只是一次简单的技术升级，更是一次为 Kubernetes 基础设施构建未来竞争力的战略决策。
考虑到工作负载的规模与复杂性，迁移方案设计遵循零宕机、最小化中断和弹性扩缩原则。
Snowflake 最终选择开源 Kubernetes 集群自动扩缩工具 Karpenter，配合 NodePool 和 NodeClass 实现动态节点调度。整个迁移采用渐进式实施策略，以降低风险并保持稳定。
03/迁移步骤

1.集群准备

• 修改 NodePool 和 NodeClass 的配置，将 Bottlerocket AMI 集成到 EKS 环境中，并将其设定为默认的 AMI 类型
  
• 遵循最小权限原则，调整 AWS 身份访问管理策略以适配 Bottlerocket 安全模型，确保所有权限设置符合基础设施安全要求
  

以下架构图展示了迁移策略：

2.引入 Karpenter

在架构设计层面，Karpenter 的引入取代了传统的静态节点预配置方式，实现了节点的“按需实时调度”，极大提升了集群的弹性和响应能力。

• Staging 环境测试：完成配置后，在 Staging 环境中验证 Bottlerocket 节点的工作负载性能和兼容性，达标后逐步推广到生产环境
  
• 构建监控体系：借助 Fluentd 和 Datadog 实现实时指标与跟踪分析
  
• 安全合规测试：确保 Bottlerocket 的不可变基础设施符合 Snowflake 内部的安全策略和标准
  

3.渐进式上线

• 从无状态应用开始，利用节点亲和性（Node Affinity）、Pod 反亲和性（Pod Anti-Affinity）及节点分类等机制，确保工作负载合理分布
  
• 逐步引入 Bottlerocket 节点，与现有的 AL2 实例共存运行，保证迁移过程中业务运行的连续性与稳定性
  
• 逐步替换，通过标记不可调度（Cordon）和排空节点（Drain）有序下线 AL2 实例，实现平滑过渡
  

4.深度优化与监控

• 利用 Karpenter 弹性伸缩策略，动态调整节点池，按需供给资源，避免过度配置
  
• 基于真实工作负载进行性能调优
  
• 增强可观测性，实时监控系统健康状态，提前预警潜在问题
  

⚪ 示例配置

定义 NodeClass（Bottlerocket 节点模板）：

1. apiVersion: karpenter.k8s.aws/v1alpha5
2. kind: NodeClass
3. metadata:
4.   name: bottlerocket-nodeclass
5. spec:
6.   amiFamily: Bottlerocket
7.   instanceProfile: "KarpenterNodeInstanceProfile"
8.   securityGroupSelector:
9.     aws-ids: ["sg-0123456789"]

复制代码

定义 NodePool 并关联上述 NodeClass：

1. apiVersion: karpenter.k8s.aws/v1alpha5
2. kind: NodePool
3. metadata:
4.   name: bottlerocket-nodepool
5. spec:
6.   template:
7.     spec:
8.       nodeClassRef:
9.         name: bottlerocket-nodeclass
10.   limits:
11.     resources:
12.       cpu: 1000
13.   ttlSecondsAfterEmpty: 30

复制代码

利用节点亲和性调度工作负载至 Bottlerocket 节点：

1. apiVersion: apps/v1
2. kind: Deployment
3. metadata:
4.   name: bottlerocket-app
5. spec:
6.   replicas: 3
7.   selector:
8.     matchLabels:
9.       app: bottlerocket-app
10.   template:
11.     metadata:
12.       labels:
13.         app: bottlerocket-app
14.     spec:
15.       affinity:
16.         nodeAffinity:
17.           requiredDuringSchedulingIgnoredDuringExecution:
18.             nodeSelectorTerms:
19.             - matchExpressions:
20.               - key: karpenter.k8s.aws/node-pool
21.                 operator: In
22.                 values:
23.                 - bottlerocket-nodepool
24.       containers:
25.       - name: app
26.         image: my-app-image:latest

复制代码

利用 Pod 反亲和性跨节点分散工作负载的示例：

1. apiVersion: apps/v1
2. kind: Deployment
3. metadata:
4.   name: workload-deployment
5. spec:
6.   replicas: 3
7.   selector:
8.     matchLabels:
9.       app: critical-app
10.   template:
11.     metadata:
12.       labels:
13.         app: critical-app
14.     spec:
15.       affinity:
16.         podAntiAffinity:
17.           requiredDuringSchedulingIgnoredDuringExecution:
18.           - labelSelector:
19.               matchExpressions:
20.               - key: app
21.                 operator: In
22.                 values:
23.                 - critical-app
24.             topologyKey: "kubernetes.io/hostname"
25.       containers:
26.       - name: workload
27.         image: workload-image:latest

复制代码

 
04/挑战与解决方案

尽管 Bottlerocket 带来了诸多优势，但在迁移过程中我们仍然遇到了一些挑战。
部分工作负载在最初配置时，与 Bottlerocket 的不可变文件系统（immutable filesystem）存在兼容性问题。
针对这一情况，我们通过修改应用镜像，使其完全兼容容器化，并在适用场景下采用只读配置（read-only configurations），最终顺利解决了兼容性障碍。
此外，Bottlerocket 需要重新配置 IAM 角色以匹配其安全模型。
为此，我们引入了细粒度访问控制（Fine-grained access control），并充分利用了 Karpenter 的 IAM 集成能力，确保访问控制既安全又高效。
为了最大程度降低风险，我们采取了渐进式迁移的方式，确保应用性能稳定后再完全下线 AL2 节点。
05/核心优势

此次迁移在安全性、性能和运维效率方面实现了显著提升：
安全性增强

• 采用不可变节点，杜绝未经授权的更改，彻底消除了配置漂移（Configuration Drift）的风险；
  
• 移除包管理器、Shell 访问和 SSH 登录，进一步缩小攻击面，显著降低了潜在的安全漏洞；
  
• 自动化原子更新，确保节点补丁安装零宕机；
  

性能提升

• 优化节点启动速度，大幅缩短了新节点加入集群的时间
  
• 改进自动扩缩效率，保障工作负载快速重新调度
  

Bottlerocket vs. AL2 性能对比：
Bottlerocket 在节点就绪速度方面持续表现更优。初步基准测试显示：

• 节点就绪时间：Bottlerocket 比 AL2 缩短约 5 秒
  
• 容器镜像缓存：新节点上每个 Pod 节省约 36 秒
  
• 待调度 Pod 响应：整体比 AL2 快约 40 秒
  

Bottlerocket 与 AL2 性能对比运维效率

• 借助 Karpenter 实现动态扩缩容，确保资源按需分配，避免了过度配置
  
• 结合 Bottlerocket 轻量级操作系统和 Karpenter 的智能化资源调度，显著提高成本节约
  

06/总结

这次迁移过程带来了许多宝贵的经验教训：

• 安全性与效率相辅相成：Bottlerocket 的不可变设计大幅强化了 Snowflake 的整体安全防护体系。
  
• 自动化简化复杂度：通过 Karpenter 实现实时扩缩容，消除了大量手动干预，提高了集群运维效率。
  
• 渐进式迁移降低风险：采用分阶段、增量式迁移策略，使我们能够在不影响生产环境的前提下，逐步调优配置、平滑过渡。
  

Snowflake 将其 Kubernetes 基础设施成功迁移至 Bottlerocket 和 Karpenter 的实践，为行业树立了新的标杆。
这一案例证实，在安全性、配置速度和运维效率等方面取得的成果，完全可复用于其他需要大规模管理 Kubernetes 的企业。
通过采用这两项技术，Snowflake 不仅显著强化了自身的安全防护，还通过弹性扩缩实现了性能优化，充分体现了现代云原生解决方案在打造高性能、弹性 Kubernetes 环境的巨大潜力。
关注⌈ CloudPilot AI ⌋，带您了解更多企业的弹性扩缩容实践案例。

来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！