容器云平台的稳定性设计.docx
- 文档编号:588565
- 上传时间:2023-04-29
- 格式:DOCX
- 页数:65
- 大小:2.92MB
容器云平台的稳定性设计.docx
《容器云平台的稳定性设计.docx》由会员分享,可在线阅读,更多相关《容器云平台的稳定性设计.docx(65页珍藏版)》请在冰点文库上搜索。
容器云平台的稳定性设计
目录
1API稳定性设计..............................................................................................................................................................1..........................
1.1API结构与版本...........................................................................................................................................................1.........................
1.2API扩展....................................................................................................................................................................6...........................
2平台优化实践................................................................................................................................................................1..7........................
2.1组件优化..................................................................................................................................................................1.8.........................
2.2节点优化..................................................................................................................................................................2.4.........................
2.3网络优化..................................................................................................................................................................3.0.........................
2.4存储优化..................................................................................................................................................................3.9.........................
3业务稳定性保障.............................................................................................................................................................4..1........................
3.1负载均衡..................................................................................................................................................................4.2.........................
3.2健康检查..................................................................................................................................................................4.4.........................
3.3服务质量..................................................................................................................................................................4.7.........................
3.4弹性伸缩..................................................................................................................................................................5.1.........................
3.5变更策略..................................................................................................................................................................5.5.........................
4本章总结.......................................................................................................................................................................5..9.........................
1API稳定性设计
Kubernetes是一个灵活强大的生产级别的开源容器编排系统,与服务器,网络,存储等各基础设施和认证授权,虚拟化,大数据等各种技术领域有着密切的交互与协作,同时也在不断吸纳各种其他领迅域速,地发展壮大。
如何保证这样一个几乎"包罗万象"的系统在不断增加和扩展特性的快速迭代过程中各版本的稳
定性和兼容性自然是一个至关重要的课题。
依托Google生产环境运维经验,同时凝聚社区最佳创意和实践K,ubernetes社区以其开明的姿态吸引全世界的开发者和爱好者参与其中,提供诸如讨论版,视频会议M,eetup社区,特殊兴趣小组等互动讨论和技术协作渠道,制定严格而高度自动化的开发,审核,迭代规.范..。
Kubernetes社区重视代码,重视民主化的治理方式及其丰富的运作机制为Kubernetes产品本身的的稳定性提供了强有力的保障。
本节不打算讨论社区治理方面的内容,仅就Kubernetes的API相关内容一窥Kubernetes的稳定性设计。
KubernetesAPI是Kubernetes系统的重要组成部分,组件之间的所有操作和通信以及外部对
Kuber-netes的调用都是由APIServer处理的RESTAPI调用。
API的设计对于产品内部通信和外部协作
1.1API结构与版本
KubernetesAPI是通过HTTP提供的编程接口,以REST风格组织并管理资源,支持通过
POST,PUT,DELETE,GET等标准的HTTP方法对资源进行增删改查等操作。
1.1.1资源
Kubernetes中所有内容都被抽象为资源。
所有资源都可以使用清单文件(manifestfile)进行描述,使用Etcd数据库进行存储并由APIServer统一管理。
◎资源分为集群和命名空间两级作用域,命名空间级资源会在其命名空间删除时被删除。
上图资源类别并不代表其作用域
◎所有资源在其资源对象模式(清单文件)中都有一个具体的表示形式,称为Kind。
同一资源的多个对象(实例)可以组成集合
◎可以通过kubectlapi-resources命令查看当前Kubernetes环境支持的所有资源的名称,缩写,api组,作用域及其对应的Kind
1.1.2API
KubernetesAP大I多数情况下遵循标准的HTTPREST规范,JSON和Protobuf是其主要序列化结
构,资源通过API接口传入APIServer最终持久化到Etcd数据库。
API是由APIServer组件提供服务,
APIServer是Kubernetes的管理中心,是唯一能够与Etcd数据库交互的组件
1.1.2.1API群组
KubernetesAPI除了提供组织和管理各种资源的接口外,还包括一些系统层面的接口。
目AP前I主要分为三种形式:
除了系统级API外,Kubernetes基本上是以APIGroup(API群组)的方式组织各种API的,核心组API并未使用/apis/core/v1路径是历史原因(事实上核心组也成为遗留组)。
API群组是一组相关的API对象的集合,使用群组概念能够更方便的管理和扩展API。
结构示意如下:
1.1.2.2API版本
为了在兼容旧版本的同时不断升级新的API,Kubernetes支持多种API版本,不同的API版本代表其处于不同的稳定性阶段,低稳定性的API版本在后续的产品升级中可能成为高稳定性的版本。
API版本规则是通过基于APIlevel选择版本,而不是基于资源和域级别选择,是为了确A保PI能够描述一个清晰的连续的系统资源和行为的视图,能够控制访问的整个过程和控制实验AP性I的访问。
API通过这种三级渐进式版本共存与演化策略,在不断吸纳新的功能特性并给予其足够的孵化空间的同时,保证了整体API的可用性和稳定性。
◎资源定位三元组
APIGroup,APIVersion和Resource(GVR三元组)就可以唯一确定一个资源的API路径。
如
/apis/r-bac.authorization.k8s.io/v1beta1/clusterroles。
对于命名空间级资源则需要额外包含具体命名空间(否则将请求所有命名空间下相应资源),如
/apis/apps/v1/namespaces/kube-system/deployments。
对应到资源对象模式(清单文件)三元组则为APIGroup,APIVersion和Kind(GVK),相应字段为apiVersion和kind,如{"apiVersion":
"app/v1,""kind":
"Deployment"。
}
◎Kubernetes组件默认启用加密通信,并需要请求者提供凭证,为了更方便地请A求PI,可以开启代理访问。
kubectlproxy--port=8888#开启代理访问
curlhttp:
//localhost:
8888/api/pods/#kubec代tl理会自动使用默认凭证路径(/etc/kubernetes/ssl下/)的凭证文件(kube-proxy.xx)
◎可以通过kubectlapi-versions命令查看当前Kubernetes环境启用的所有API群组及其版本。
1.1.3数据持久化与无损转换
用户向Kubernetes发起资源构建请求时只提供了一个资源清单文(件如deployment.yaml,)但事实上
Kubernetes基于可用性和稳定性的考虑,却能够支持同时使用不同稳定性A的PI版本访问同一资源,返回不同版本的资源数据。
这一灵活的特性有赖A于PIServer的资源数据无损耗转换机制。
1.1.3.1数据持久化
资源数据是持久化到Etcd数据库中的,而从资源清单文件到持久化到Etcd数据库的资源数据的大致流程如下:
1.客户端(kubectl,curl,sdk等)得到资源清单文件(YAML或JSON格式)
2.部分支持格式转换的客户端(如kubectl,sdk等)会先将YAML格式的资源清单文件转换为JSON格式化,然后根据清单字段或相应参数获取APIServer请求路径,发送到APIServer
3.APIServer对收到的资源清单文件进行准入校验和字段预处理,生成资源数据,对同资源的多个版本进行无损转换
4.APIServer将资源数据转换为指定的存储版本
5.APIServer将存储版本的资源数据按照指定编码(PROTOBUF或JSON)进行序列化,以key-value的方式存储到Etcd中
APIServer启动时可以通过--storage-versions参数指定资源数据的存储版本(默认是最新稳定版,如v1);通过--storage-media-type参数指定序列化编码(默认是
application/vnd.kubernetes.protobu。
f)
Etcd数据库中的资源数据是作为value存储的,而对应的key则是按照/registry/#{k8s对象}/#{命名空间}/#{具体实例名}的规范格式生成的。
1.1.3.2无损转换
Etcd数据库中只存储了资源的一个指定版本,但客户端传入的资源清单文件中指定的资源版本和客户端向APIServer请求的资源版本可能并不是Etcd数据库中存储的版本,APIServer如何在各个版本之间
进行无损转换呢?
如果一个资源存在众多版本,那么编写各种不同版本之间的转换规则无疑是非常麻烦的,A因P此IServer中维护着一个internal版本,需要作版本转换时,任意原版本都先转换i为nternal版本,再由
inter-nal版本转换到指定的目的版本,如此只要每个版本都可转换in为ternal版本,则可以支持任意版本之间的转换。
而保证版本转换过程中不出现数据丢失(即无损转换)则是依靠annotations(注解)实现。
例如从版本A转换到版本B,对不同字段的处理如下:
◎版本A和B中均存在的字段可直接转换
◎版本A中存在而版本B中不存在的字段将写入注解中
◎版本A中不存在而版本B中存在的字段,如果存在于版本A的注解中则从注解中读取字段值,否则字段值置空
1.2API扩展
Kubernetes因其平台级基础设施的特殊性,与服务器,网络,存储,虚拟化,身份认证等等绝大多数计算机软硬件技术领域存在广泛交集,这需要大量的适配与对接,此外作为底层容器编排引擎,也需要满足高度的可扩展性以面对大量的功能特性扩展需求。
常规的解决方案是修改Kubernetes相关API和控制器的源代码或者定义新的资源类型并作为新的核心资源API合并到Kubernetes官方社区代码中。
但这些方无疑会迅速使得Kubernetes核心API资源变得
臃肿庞杂难以维护,最终导致API过载,这会为项目本身维护和产品生产环境运行的稳定性带来巨大挑战。
Kubernetes提供了两种API扩展机制保证核心API足够精简的同时满足庞杂的适配对接和特性扩展需
求:
1.自定义资源类型(CRD):
即CustomResourceDefinitions。
允许用户通过资源清单的方式定义任意全新的资源对象类型,并由APIServer管理自定义资源的整个生命周期,用户还可以通过定义相应的控制器对自定义资源及其他相关资源进行监视,协调和管理。
通常将自定义资源和自定义控制器配合工作的方式统称为CRD方式。
2.APIServer聚合(AA):
即APIServerAggregattion。
其前身是用户APIServer(UAS),UAS允许用户设计一套自定义的APIServer与Kubernetes主APIServer并行生效,可以在不影响原APIServer的前提下实现更加复杂和定制化的逻辑和功能,但这种方式对代码开发的要求会比较高。
自定A义PIServer可以选择与主APIServer进行聚合也可以独立存在,但独立存在的方式无法K与ubernetes很好的集成,因此自定义APIServer普遍采用APIServer聚合的方式。
1.2.1自定义资源类型
Kubernetes原生支持自定义资源的创建和生命周期维护,自定义资源类型一经创建便Po与d,Job,Secret等内建资源拥有同等地位,可以像内建资源一样创建并运行自定义资源类型的实例对象。
自定义资源配合定制的控制器就可以完成如自动化网络管理,自动化存储管理,自动化证书管理,自动化应集用群
管理等广泛的特性需求。
1.2.1.1自定义资源
自定义资源类型的创建
每个API资源都有相应的Group群组和资源类型,声明自定义资源就必须命名一个与已有群组不重复的新的Group群组,新的群组中可以有任意数量的自定义资源类型,并且这些资源类型可以与其他群组中的资源类型重名。
自定义资源类型的声明方式与Kubernetes的内建资源的创建方式相同,都是通过资源清单文件进行声明并应用,因为CustomResourceDefinition本身就是一种内建资源。
一个最简单的自定义资源类型的声明清单示例如下:
#apps-crd.yaml
apiVersion:
apiextensions.k8s.io/v1beta1kind:
CustomResourceDfienitionmetadata:
name:
apps.foo.barspec:
group:
foo.barversion:
v1names:
kind:
App
plural:
apps
scope:
Namespaced
各字段解释如下:
◎apiVersion:
CustomResourceDfienition这一内建资源所在的群组及当前使用的api版本。
目前为固定字段
◎kind:
固定字段,表示是在声明自定义资源类型
◎metadata.name:
自定义资源类型的全名,它由spec.group和spec.names.plural字段组合而成
◎spec.group:
自定义资源类型所在群组
◎spec.version:
自定义资源类型的群组版本
◎spec.names.kind:
自定义资源的类型,惯例首字母大写
◎spec.names.plural:
其值通常为kind的全小写复数,关系到自定义资源在RESTAPI中的HTTP路径
◎spec.names.scope表:
spaced)
示自定义资源的作用范围,Kubernetes中大部分资源都是命名空间级(Name-
自定义资源本身是不支持多版本的,但自定义资源的群组支持多版本。
也就是说每一个群组的特定版本里的所有自定义资源都不需要考虑资源版本之间的兼容问题,保证群组内各资源的整体一致性。
spec.names中还有许多其他字段,不指定则会由APIServer在创建自定义资源类型时自动填充.自定义资源类型声明完成后就可以通过kubectlcreate-fapps-crd.yam或lkubectlapply-f
appscrd.yaml命令进行创建了,创建完成后可通过kubectlgetcrdapps.foo.bar-oyam命l
看。
自定义资源类型创建完成后,其RESTAPI的HTTP访问路径为
令进行查
/apis/foo.bar/v1/namespaces/de-fault/apps以(default命名空间为例)。
自定义资源的创建
自定义资源类型创建完成后就可以创建相应的自定义资源。
一个简单的自定义资源的创建清单如:
下
#app.yamlapiVersion:
foo.bar/v1kind:
Appmetadata:
name:
demo
spec:
port:
3333path:
/app
自定义资源声明完成后就可以通过kubectlcreate-fapp.yaml或kubectlapply-fapp.yaml命令进行创建了,创建完成后可通过kubectlgetapps.foo.bar-oyaml命令进行查看。
自定义资源创建完成后,其RESTAPI的HTTP访问路径为
/apis/foo.bar/v1/namespaces/default/apps
/demo(以default命名空间为例)。
自定义资源spec下的字段只有在被特定控制器或应用按照约定的规范读取解析和处理后才具有实际意
义.
终止器
自定义资源和内建资源一样都可以支持终止器(finalizer),终止器允许控制器实现异步的预删除钩子。
对于具有终止器的资源对象第一个删除请求仅仅是m为etadata.deletionTimestam字p段设置一个值,而
不是删除它,然后触发相应控制器执行自定义处理并删除该资源对象的终止器,最后再一次发出删除请求。
每个资源对象都可以有多个终止器,删除资源对象时,只有当其所有终止器都删除后才会真正被删除。
1.2.1.2自定义控制器
在Kubernetes中,工作负载(workload类)的资源(如ReplicaSet,Deployment,StatefulSe,t
CronJob等运行容器的内建资源)是通过控制器(controller进)
于控制对应Pod的具体状态和行
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 容器 平台 稳定性 设计