Kubenetes Application

TIPS之 应用云原生改造要素

应用云原生改造要素

Posted by 董江 on Wednesday, April 23, 2025

应用云原生改造要素

一、什么是云原生应用？如何云原生改造？

应用云原生是一种架构设计理念。 可生于云、可长于云，不被云锁定，并充分利用云平台的弹性、分布式和自动化等特性，以实现高效的开发、部署和运行。

1.1 云原生应用需要支持

应用完成微服务改造（计算存储分离、控制数据分离），以Kubernetes做运行时生命周期管理， 并可以在水平/垂直扩缩容、驱逐操作对业务无损的云原生改造

1.2 云原生应用，也需要包括以下内容（非必须）：

1、 工程化和服务化改造（可以不是微服务）：

  • 容器镜像
  • 配置和二进制分离
  • 应用可观测支持: custom metrice、logging 和 tracing

2、 存算分离：

  • 计算存储分离、控制数据分离
  • 状态转移：RPC or Http幂等性

3、优雅管理

  • 优雅启停（支持信号量）
  • 优雅扩缩容
  • 优雅升级和降级（主要是版本和配置）
  • 支持reload操作

4、纯软件化

  • 对OS、硬件无依赖
  • 对PM Host无依赖

二、关键技术

2.1 容器化改造

2.1.1 基础镜像和业务镜像制作

统一的基础镜像，可控制容器OS心脏漏洞的发生

  • 基础镜像统一引入标准基础镜像
  • 规范镜像时区，统一使用Asia/Shanghai时区
  • 指定非root用户运行主进程
  • 镜像中仅运行一个主进程，禁止使用systemd管理进程
  • 镜像中不可存储凭据密钥等敏感文件
  • 镜像中不可存储大量运行时临时文件，如日志，调试文件等;
  • 镜像不可超过80层
  • 基础镜像以entrypoint或空执行结束；业务镜像以CMD结束（不建议以 CMD [shell script] 结束）
  • 镜像安全扫描：通过安全扫描，避免容器OS“心脏”漏洞导致Host OS kernel Crash

2.1.2 多架构支持

  • arm64
  • amd64
  • 等

2.2 微服务改造

通过统一脚手架 减少框架版本碎片化 和 兼容性风险；

2.2.1 服务注册发现

统一服务注册中心

  • 服务按组注册
  • 服务health check
  • 服务发现按组权重调用

2.2.2 统一配置中心

  • 全量拉取
  • 增量推送

2.2.3 轻量级通行协议

  • gRPC
  • http/1.1
  • http/2.0
  • jsonRPC

2.2.4 服务存算分离

  • 数据多级缓存
  • 数据加载
  • 数据reload

2.3 软件工程

  • 版本发布：滚动发布、蓝绿发布、feature toggles
  • 可观察性：
    • metrics：框架metric + 自定义metrics
    • logging：业务log、accesslog、crashlog 分离
    • tracing：method级买点
    • topo：流量拓扑
  • 基础库Interface扩展
    • middleware插件
    • fliter插件
    • 注解annotation管理
    • router管理
  • 安全
    • rbac
    • policy
  • HA
    • gslb
    • failover

2.4 服务治理

2.4.1 流量管控

在地址发现和负载均衡机制之外，微服务丰富的流量管控规则可以控制服务间的流量走向和 API 调用，基于这些规则可以实现在运行期动态的调整服务行为如超时时间、重试次数、限流参数

  • context控制超时控制
  • retry
  • rratelimiter qps 和 brust

2.4.2 诊断和调优

  • 服务端对客户端进行回调
  • 只订阅
  • 只注册
  • 运行时动态指定 IP 调用
  • 直连提供者
  • 启动时检查
  • 本地调用
  • 参数校验
  • 本地伪装
  • 本地存根
  • 回声测试
  • 调用信息记录
  • 延迟暴露

2.4.3 统一基础库

  • 端口协议复用
  • 线程池隔离
  • 多协议
  • 多注册中心
  • 请求耗时采样
  • 线程模型
  • 服务引用配置对象缓存
  • 路由状态采集
  • 负载均衡
  • 注册信息简化
  • 调用结果缓存
  • 并发控制
  • 连接控制
  • 延迟连接
  • 粘滞连接
  • 导出线程堆栈
  • 自定义服务容器
  • 优雅停机
  • 主机地址自定义暴露
  • 一致性哈希选址
  • 日志框架适配及运行时管理

2.4.4 流量灰度

2.4.4.1 搭建多套独立的逻辑测试环境

2.4.4.2 搭建一套完全隔离的线上灰度环境用来部署新版本服务

gray1

2.4.4.3 金丝雀发布

weight1.png

2.4.4.4 同区域优先。当应用部署在多个不同机房/区域的时候，优先调用同机房/区域的服务提供者，避免了跨区域带来的网络延时，从而减少了调用的响应时间。

region1

2.5 服务降级

2.5.1 限流降级

  • Dubbo Sentinel
  • 集群负载情况执行限流

2.5.2 熔断降级

  • Hystrix
  • 配置下发自定义熔断

2.5.3 failover降级

  • 兜底返回策略

2.6 服务网格

2.6.1 Proxyless

dubbo-proxyless

2.6.2 Proxy mesh

dubbo-sidecar

多协议支持，底层也需要支持dubbo rpc协议，控制面选用；

三、业务云原生改造阶段

3.1 CICD持续部署

  • helm改造
  • 静态配置版本管理
  • 服务依赖workload版本管理（多helm依赖）

3.2 运行时云原生化

  • 对于java类型的应用，必须在启动参数中指明-Xms， -Xmx参数

建议：通过java应用获取pod ENV（INI）配置，支持堆大小、gc释放时间、PodIP等等有效配置

  • 应用支持 readyz 和 healthz
  • 应用支持metrics
  • 日志持久化：自轮转和定时压缩
  • 处理信号量：优雅启停、reload、信号量传递
  • 需要应用自实现
    • 禁止exec shell
    • 遏制对内核参数syscall获取
    • Pod/Node IP和name获取（通过ENV传递）
    • 遏制对网卡名称获取
    • 禁止应用直接使用swap（jvm除外）

3.3 服务治理云原生化

3.3.1 数据采集

  • label规范：env, region, azone, project, module, server

3.3.2 版本发布

  • 版本管理：tag x.x.x
  • 扩缩容
  • 弹性伸缩：hpa、vpa

3.3.3 资源画像

  • 资源预测
  • 资源预调整

四、其他

「如果这篇文章对你有用,请随意打赏」

Kubeservice博客

如果这篇文章对你有用,请随意打赏

使用微信扫描二维码完成支付

CATALOG
    FEATURED TAGS
    agent apiserver application bandwidth-limit cgo cgroupfs ci/cd client-go cloudnative cncf cni community container container-network-interface containerd controller coredns crd cuda custom-controller deployment device-plugin docker docker-build docker-image drop ebpf ecology egress etcd gitee github gitlab golang governance gpu-device hpa http2 image ingress iptables jobs kata kata-runtime kernel kind kubelet kubenetes kubernetes library linux-os logging loki metrics monitor namespace network network-troubleshooting node nodeport nvidai ollama pingmesh pod prestop prometheus proxyless pvc rollingupdate schedule scheduler serverless sglang sidecar sigtrem systemd tensorrt-llm throttling timeout tools traceroute vllm