容器云平台的稳定性设计.pdf

容器云平台的稳定性设计 目录 1 API 稳定性设计 1 1.1 API结构与版本 1 1.2 API扩展 6 2 平台优化实践 17 2.1 组件优化 18 2.2 节点优化24 2.3 网络优化 30 2.4 存储优化 39 3 业务稳定性保障41 3.1 负载均衡42 3.2 健康检查44 3.3 服务质量47 3.4 弹性伸缩 51 3.5 变更策略 55 4 本章总结 59 1 API 稳定性设计 Kubernetes 是一个灵活强大的生产级别的开源容器编排系统，与服务器，网络，存储等各基础设施和认 证授权，虚拟化，大数据等各种技术领域有着密切的交互与协作，同时也在不断吸纳各种其他领域， 迅速地 发展壮大。如何保证这样一个几乎"包罗万象"的系统在不断增加和扩展特性的快速迭代过程中各 版本的稳定 性和兼容性自然是一个至关重要的课题。 依托 Google 生产环境运维经验，同时凝聚社区最佳创意和实践，Kubernetes 社区以其开明的姿态吸引 全世界的开发者和爱好者参与其中，提供诸如讨论版，视频会议，Meetup 社区，特殊兴趣小组等互动讨论 和技术协作渠道，制定严格而高度自动化的开发，审核，迭代规范...。Kubernetes 社区重视代码， 重视民主 化的治理方式及其丰富的运作机制为 Kubernetes 产品本身的的稳定性提供了强有力的保障。 本节不打算讨 论社区治理方面的内容，仅就 Kubernetes 的 API 相关内容一窥 Kubernetes 的稳定性设计。 Kubernetes API 是 Kubernetes 系统的重要组成部分，组件之间的所有操作和通信以及外部对 Kuber- netes 的调用都是由 API Server 处理的 REST API 调用。API 的设计对于产品内部通信和外部协作 1.1 API 结构与版本 Kubernetes API 是通过 HTTP 提供的编程接口，以 REST 风格组织并管理资源，支持通过 POST ， PUT ，DELETE ， GET 等标准的 HTTP 方法对资源进行增删改查等操作。 1.1.1 资源 Kubernetes 中所有内容都被抽象为资源。所有资源都可以使用清单文件(manifest file)进行描述，使用 Etcd 数据库进行存储并由 API Server 统一管理。 ◎ 资源分为集群和命名空间两级作用域，命名空间级资源会在其命名空间删除时被删除。上图资源类 别并不代表其作用域 ◎ 所有资源在其资源对象模式(清单文件)中都有一个具体的表示形式，称为 Kind。同一资源的多个对 象(实例)可以组成集合 ◎ 可以通过 kubectl api-resources 命令查看当前 Kubernetes 环境支持的所有资源的名称，缩写， api 组，作用域及其对应的 Kind 1.1.2 API Kubernetes API 大多数情况下遵循标准的 HTTP REST 规范 ，JSON 和 Protobuf 是其主要序列化结构， 资源通过 API 接口传入 API Server 最终持久化到 Etcd 数据库。API 是由 API Server 组件提供服务，API Server 是 Kubernetes 的管理中心，是唯一能够与 Etcd 数据库交互的组件 API 群组 Kubernetes API 除了提供组织和管理各种资源的接口外，还包括一些系统层面的接口。目前 API 主要 分为三种形式: 除了系统级 API 外 ，Kubernetes 基本上是以 API Group(API 群组)的方式组织各种 API 的，核心组 API 并未使用/apis/core/v1 路径是历史原因(事实上核心组也成为遗留组)。API 群组是一组相关的 API 对象的 集合，使用群组概念能够更方便的管理和扩展 API。 结构示意如下: API 版本 为了在兼容旧版本的同时不断升级新的 API ，Kubernetes 支持多种 API 版本，不同的 API 版本代表其 处于不同的稳定性阶段，低稳定性的 API 版本在后续的产品升