容器云平台的性能设计

1、容器云平台的性能设计（下载原文可改文字颜色）II目录目录4.1 计算节点架构和容量154.2 计算节点监控和性能调优174.3 应用规划18亨1Kubernetes整体容量规划通常个完整的高可用Kubernetes群集田3奀节点组成：Master节点用千运行APIServer和ETCD等控制服务。Infra节点：涉及容器基础设施相关，包括负责日志查询的EFK集群、负责容器监控的Prometheus和AlertManager集群和负责外部流量导入的Ingress集群等。App节点负责运行普通业务应用的节点。每个计算节点都具有些可分配的资源(CPU,内存，GPU等）。因此如何更合理地分配这些计算资

2、源在确保平台本身稳定性的同时满足业务需求并提升资掠利用率，这就需要对集群的容量进行规划。针对集群计算资掠，首先需要定义节点数量和总资源容量。假设要在群集上运行的个应用需要总容量为8Core32G的计算资源，这里主要有2种部署思路：21个思路是使用2台4Core16GB服务器实例作为Kubernetes工作节点即较少的节点较高配的服务器（类似集群直接使用物理机）。另个思路是使用4台2Core8GB服务器实例作为Kubernetes工作节点（类似集群使用虚拟机）。这么，哪种思路更有优势？下文我们做下对比：高配置方案低配置方案管理便利性节点少，管理成本低节点多，管理成本高应用可用资源单节点资源多、应

3、用适配灵活单节点资源较少、应用单实例资源依赖不可过大应用稳定性单节点应用较多，爆炸半径大单节点应用较少，爆炸半径小资源利用率单节点资源颗粒度大，可充分利用单节点资源颗粒度小，可能无法满足应用而闲置由上图可以发现，如果使用高配置方案，针对集群的管理便利性由千节点数量较少而变得较为简单，同时针对应用的资源利用率会有所提升。但是同样也需要注意到由千节点密度较高，单个节点出现故障后的导致应用影响的爆炸半径会比较大，对节点容量规划和监控自愈响应有定要求。因为上述特点在Kubernetes集群节点容量规划上，应保持节点配置和节点规模的平衡。下文将具体阐述主要组件的规划思路。2Master节点性能设计2.1

4、 Master节点架构和容量设计Master节点通过staticpod启动APIServer、ControllerManager、Scheduler等控制服务，以及ETCD分布式数据库。后者是CoreOS基千Raft协议开源的分布式key-value存储，可用千服务发现、共享配置以及致性保障（如数据库选主、分布式锁等）。在这里用千存储KubernetesAPIServer所接收的A回对象。对千Master的容量设计主要包括如下几点1节点和服务高可用。关千这点Kubernetes本身高可用部署架构就涉及。建议至少3台Master节点。同时通过设置污点节点亲和性的方式，避免应用容器调度到Maste

5、r上。参考下图Master节点架构，Master上主要涉及kube-apiserv­er、kube-controller-manager与kube-scheduler几个服务。kube-apiserver由千服务本身无状态，需要确保通过负载均衡实现访问APIServer多实例的高可用访问。kubecontrollermanager与kubescheduler:田千这两个服务般使用单主节点active,多个从节点standy的模式运行。其内部会使用锁争用方式确认主节点，其余节点处千standy状态。直到主节点发生异室锁失效后被其他节点争用代替（在后续开发方案设计的文章中会涉及实现方法）

6、。2.ETCD本身需要高可用部署，建议至少3个节点，根据实际性能情况可以和Master并运行或独立部署。官方使用kubeadm部署的方案参考https:/kubemete.sio/docs/setup/productionenvironmen/ttools/kubeadm/setuphaetcdwithkubeadm/。物理硬件上，田千ETCD其高度依赖存储和网络，建议使用SSD等高IOPS存储方案并确保ETCD集群之间以及APIServer访问ETCD网络条件良好。另方面，ETCD也涉及客户端和服务器优化，这部分在下节再进行讨论。通常来说Master节点的性能与ETCD相关，与集群中A回对象

7、的读写频率成正比。若集群节点数量稳定总体而言其TPS和IOPS还是趋于稳定的。因此建议采用合理计算资掠的高配詈方案搭建集群。2.2 Master节点监控和性能调优2.2.1 Master性能调优确保ETCD使用3.X版本并且使用V3存储模式根据ETCD官方说明，3.x版本引入可伸缩性和性能改进，可减少任何大小群集的CPU、内存、网络和磁盘需求，从ETCD2升级到ETCD3,APIServer的IOPS/CPU改善超过50%。根据Kubernetes版本说明，1.5.1版本后开始支持ETCD3,1.13废除了ETCD2的支持。Master节点OS参数优化selinuxavecachethresh

8、old=8192netnf_conntrack_hashsize=l31072sysctlnet.ipv4.ip_forward=1kernel.pid_max=>131072filter.nf_conntrack_max=1048576net.ipv4.neigh.default.gc_thresh1=8192net.ipv4.neigh.default.gc_thresh2=32768net.ipv4.neigh.default.gc_thresh3=65536net.ipv6.neigh.default.gc_thresh1=8192net.ipv6.neigh.default.g

9、c_thresh2=32768net.ipv6.neigh.default.gc_thresh3=65536kernel.sched_min_granularity_ns=lOOOOOOOkernel.sched_migration_cost_ns=SOOOOOOkernel.sched_wakeup_granularity_ns=4000000sysfs/sys/module/nvme_core/parameters/io_timeout=4294967295/sys/module/nvme_core/parameters/max_retries=lOETCD服务端客户端优化ETCD由千对存

10、储性能依赖较大。通常可以通过服务器端客户端进行性能优化。关千服务器端存储优化阿里云实现了ETCDfreelist分配回收算法，具体参考cf.io/blog/2019/05/09/performanceoptimizationofetcd|nwebscaledatascenario/。关千客户端性能优化，核心在千控制及优化对APIServer的对象读写。由千Kubernetes支持CRD扩展API资源对象，因此在CRD对象Controller设计上应尽可能精简避免大对象的频繁读写变化。2.2.2 Master相关监控指标建议CPU<80%Mem<80%磁盘分区使用率<80%10

11、使用率<90%网卡流量使用率<50%(A-A网卡）主机可用性外部主机可用性监控监控服务可用性（通过Prometheus)99%APIServer请求延时4秒Kubeclient访问错误率5%APIServer证书过期<7天APIServerDown>lCPU/MemovercommitNode不可用Nodeexporter不可用预测磁盘满<1天Node中磁盘10>90%Pod无法启动（重启失败）Pod状态不readyPodCPU/Mem使用率3Infra节点性能设计主要包含以下几类业务无关的平台服务日志服务、监控服务和外部流量路由服务。3.1 EFK架构和容

12、量Kubernetes本身支持多种日志收集方案，思路上可分为应用直接写Elasticsearch日志。应用通过emptydir等形式将日志输出在Pod中，再通过Sidecar容器读取日志写入Elasticsearch。应用将日志输出在Docker标准输出再通过平台方案写入Elasticsearch。当今比较流行的方案是最后这个，通过Elasticsearch,Fluentd和Kibana(EFK)技术栈实现。其方案的具体思路是通过DaemonSet在需要收集日志的各个节点上运行fluentd的容器，后者挂载每个节点宿主机的Docker日志目录（如var/log和var/lib/docker/c

13、ontainer)。这样当该节点的容器写入Docker日志后就会被fluentd捕获，最终写入Elasticsearch。这样用户通过灼bana即可查询指定Pod日志。此方案需要应用将日志重定向到标准输出，以便Dockerlog捕获。值得注意的是，由千EFK堆栈通过Fluentd将日志搬运至Elasticsearch的数据是不断累积的，故需要注意下列配置来保证集群可用·Fluentd容量Fluentd的作用主要是将计算节点宿主机日志读取后放入本地Buffer,再异步发送给远端Elasticsearch。因此当远端无法及时写入数据或本地产生日志过多远端无法及时消化时，Fluentd默认

14、本地会产生overflow报错并丢弃旧的日志。因此需要合理调整配置中chunklim凡size大小。1. <match*>2. idelasticsearch3. typeelasticsearch4. log_levelinfo5. type_name_doc6. include_tag_keytrue7. 8. port92009. userelastic10. passwordelastic11. logstash_formattrue12. <buffer>13. typefile14. path/var/log/fluentd-buffers/kubernet

15、es.system.buffer15. 于lushmodeinterval16.17. chunklimitsize20M18. overflowactionblock19. </buffer>20. </match>Elasticsearch高可用Elasticsearch部署需要注意以下几点1 由千Elasticsearch对千存储依赖较高，般使用本地存储或基千LocalVolume的PV持久化，并使用StatefulSet启动多节点实现高可用。因此Elasticsearch应用建议启动在Kubernetes集群固定独占节点上，禁止业务容器调度。2 作为Kubern

16、etes集群的日志查询服务，其对计算资源高度依赖。故建议使用少数节点高配置部署方案。节点数量至少为3台。3 为了避免主节点脑裂，需要设置discover.zen.minimum_master_nodes节点数量2+1。4 由千Elasticsearch存储的日志是根据Namespace和日期单独存储。故需要定义日志存储时间，避免存储空间不足。可以通过CronJob定期根据Namespace和日期清理历史日志存储。3.2 EFK监控和调优日志节点OS参数优化selinuxavecachethreshold=8192netnfconntrackhashsize=131072sysctlnet.ip

17、v4.ip_forward=1kernel.pid_max=>131072filter.nfconntrackmax=1048576net.ipv4.neigh.default.gc_thresh1=8192net.ipv4.neigh.default.gc_thresh2=32768net.ipv4.neigh.default.gc_thresh3=65536net.ipv6.neigh.default.gc_thresh1=8192net.ipv6.neigh.default.gc_thresh2=32768net.ipv6.neigh.default.gc_thresh3=6553

18、6net.ipv4.tcp_fastopen=3fs.file-max=655350fs.inotify.max_user_watches=65536vm.max_map_count=262144sysfs/sys/module/nvme_core/parameters/io_timeout=4294967295/sys/module/nvme_core/parameters/max_retries=10日志节点监控指标CPU<80%Mem<80%磁盘分区使用率<80%10使用率<90%网卡流量使用率<50%(A-A网卡）主机可用性外部主机可用性监控监控服务可用性

19、（通过Prometheus)PV剩余空间<3%CPU/Memovercommit预测磁盘满<1天Node中磁盘10>90%Pod无法启动（重启失败）Pod状态不readyPodCPU/Mem使用率Cluster/Node/Index状态（通过ESexporter)3.3 Prometheus架构和容量传统对于IT系统的监控，思路上会有三种实现方式通过日志、通过探针和通过数据上报度量。基千日志的监控方案典型的方案就是通过ELK/EFK。应用层将相关监控K回以日志形式进行记录，通过应用层或平台层输出最终汇聚到Elasticsearch。后者通过可以通过定期查询获取对应的监控指标，

20、或者输出报警。基千探针的监控方案典型的方案就是JavaSpringCloud体系使用zipkinsleuth。其原理是通过Spring的APO在业务请求的两端进行拦截，实现用千标记请求的TraceID和标记最小处理单元的SpanID等信息的注入，以此来跟踪整个微服务调用链。基千度量褽合的监控方案Kubernetes默认使用的Prometheus就是采用这个方案。基千时序数据库，通过内置或外挂的exporter主动或被动获取段时间的监控数据，然后再通过聚合运算，最终实现监控指标展示和趋势预测。但同时也应该注意到，由千度量KPI在设计上就放弃了部分数据准确性（如定义采集周期是5min,势必会忽略其

21、中部分尖峰KPI),Prometheus针对某些强精准性的监控场景未必适用，这个需要在定义具体监控方案时识别到。Prometheus包含以下关键组件：PrometheusServer用千收集和存储时序数据，负责监控数据的获取存储以及查询。监控目标配置PrometheusServer可以静态配置定义监控目标的exporter,同时也支持通过服务发现（基千Kuberne­tes,DNS或Consul)来实现动态管理监控目标。目前Kubernetes社区巳经实现通过定义CRD扩展(监控数据查询方案PrometheusServer通过实现PromQL语言来对监控数据进行查询以及分析。般Kub

22、ernetes集成Prometheus主要有几个思路：1采用原生PrometheusUI并自定义个sidecar容器，通过注入sidecar来实现查询权限管理。2.基千Grafana定义查询U|。客户端监控输出。应用将监控指标输出给Prometheus主要有几个思路：1. ClientSDK。为需要监控的应用服务生成相应的Metrics并暴露给PrometheusServer。当PrometheusServer来Pull时，直接返回实时状态的Metrics。2. PushGateway。主要用千不适合长期存在的短期Jobs等应用。通过主动Push将数据发送给Gateway。后者会暴露Metri

23、cs被Prometheus拉取。3自定义Exporters。通过ClientSOK额外开发程序，用千使用应用层私有协议等方法从被监控目标获取指定K回再暴露Metrics给Prometheus。Alertmanager,出千报警信息的冗余性考虑，从PrometheusServer端接收到Alerts后，Alertmanager集群会对数据进行去重、分组等处理，然后根据规则，触发报警。包括原生支持的邮件、微信或自定义WebHook。架构上田于作为容器云的核心监控方案，需要确保自身的高可：用PrometheusPrometheus本身不支持高可用和数据分片，架构上实现高可用般有2个思路。1. 冗余的

24、高可用。至少需要2个节点保持相同的配置和监控目标。各自独立运行进行数据监控数据采集，并通过网络等负载均衡实现请求高可用分发。需要注意的是，由千每个实例完全独立运行，即使配置相同也可能因为获取数据时间的微小差异而导致存储的监控数据有差异。因此建议使用session粘连方式进行负载均衡。对千Kubernetes而言需要在Service中使用sessionAffinity。同时作为最常见和简单的部署方案，为了避免自身出现监控问题，建议生产上使用2个集群的交叉监控确保Prometheus平台本身可用性。2. 远程存储联邦集群方案。目前开源项目thanos(AlertmanagerAlertmanage

25、r基于Gossip协议实现高可用，避免同时获取多个Prometheus节点的告警数据，因此器要至少3个节点保持集群稳定。另外，针对Alertmanager监控可以基千其自带的Deadmanswitch进行开发扩展。后者Deadmanswitch是Prometheus自带的静默报警测试，会直不断触发报警直到Prometheus或Alertmanager集群自身不可用当然这个报警默认是被忽略的。部署方案上针对PrometheusServer的持久化，根据Prometheus社区官方的说明(ServiceMonitor、AlertManager以及PrometheusRule4个CRD对象来创建集群

26、。这样针对监控目标的调整可直接通过CRD进行，相关OperatorController会自动刷新Prometheus对应的配置规则。需要额外注意的是，当前版本的prometheusoperator代码将针对Kubernetes的监控规则以binary形式编译在operator程序中。因此除非调整代码，外部无法通过环境变量或配置注入的方式更新这部分规则。不过可以通过Alertmanager禁用报警并且额外建立其他监控规则的方式绕过。物理部署上同样建议启动在Kubernetes集群固定独占节点上，使用少数节点高配詈部署方案，禁止业务容器调度。整体节点数量至少为3台。具体容量参考如下Pod数噩Pro

27、metheus每日增长内存网络18006.3G6G16M360013GlOG26M540019G12G36M720025G14G46M3.4 Prometheus监控和调优日志节点OS参数优化selinuxavecachethreshold=8192netnfconntrackhashsize=131072sysctlnet.ipv4.ip_forward=1kernel.pid_max=>l31072filter.nfconntrackmax=1048576net.ipv4.neigh.default.gc_thresh1=8192net.ipv4.neigh.default.gc_t

28、hresh2=32768net.ipv4.neigh.default.gc_thresh3=65536net.ipv6.neigh.default.gc_thresh1=8192net.ipv6.neigh.default.gc_thresh2=32768net.ipv6.neigh.default.gc_thresh3=65536net.ipv4.tcp_fastopen=3fs.file-max=655350fs.inotify.max_user_watches=65536sysfs/sys/module/nvme_core/parameters/io_timeout=4294967295

29、/sys/module/nvme_core/parameters/max_retries=lO监控节点监控指标CPU<80%Mem<80%磁盘分区使用率<80%10使用率<90%网卡流量使用率<50%(A-A网卡）主机可用性外部主机可用性监控监控服务可用性（通过Prometheus)PV剩余空间<3%CPU/Memovercommit预测磁盘满<1天Node中磁盘10>90%Prometheus不可用（通过AlertManager)AlertManager配置异常AlertManager服务不可用(Deadmanswitch)Prometheus

30、ob不可用Pod无法启动（重启失败）Pod状态不readyCPU/Mem使用率3.5 Ingress架构和容量在Kubernetes集群中，Ingress是组路由规则，用于对集群的入站访问提供7层服务器负载均衡功能。个Ingress可以配置用千提供外部可访问的服务url上下文负载均衡流量SSL证书装载和域名流量绑定配置。不同厂商通过不同产品实现IngressController来满足Ingress功能，包括常用的Nginx(Kubernetes官方清单(https:/kubemetes.io/docs/concepts/servicesnetworking/ingresscontrollers

31、/)。本章以使用最多的NginxIngressController做进步介绍。田于IngressController本身基千Deployment安装，遇到性能问题时可以比较方便进行手工或自动的弹性伸缩，但仍然需要注意下列问题·独占部署。物理部署上建议启动在Kubernetes集群固定独占节点上，使用少数节点高配置部署方案，至少使用独立2个节点实现物理上高可用。禁止业务容器调度并使用DaemonSet部署。具体容量参考Nginx官方的RPS性能测试来刑大兰二HTTPHTTPS请求大小1K1K2Core74,19258,0414Core148,936117,2558Core300,625

32、236,70316Core342,651341,232配置优化和普通nginx类似，针对高并发场景需要额外进行优化。主要涉及HTTP会话保持是否使用HTTPS、TLS会话恢复单POD请求分摊合理上层网络优化、后端应用请求大小优化等。具体参考Kubernetes官方建议(https:/kubernetes.github.io八ngressnginx/userguide/nginxcon廿guration/conflgmap/)，需要在Conflgmap中调整如下等参数:keepalive、keepaliverequests、keepalivetimeout。3.6 Ingress监控和调优日志节

33、点OS参数优化selinuxavecachethreshold=8192netnfconntrackhashsize=131072sysctlnet.ipv4.ip_forward=1kernel.pid_max=>131072filter.nf_conntrack_max=1048576net.ipv4.neigh.default.gc_thresh1=8192net.ipv4.neigh.default.gc_thresh2=32768net.ipv4.neigh.default.gc_thresh3=65536net.ipv6.neigh.default.gc_thresh1=81

34、92net.ipv6.neigh.default.gc_thresh2=32768net.ipv6.neigh.default.gc_thresh3=65536net.ipv4.tcp_fastopen=3fs.file-max=655350fs.inotify.max_user_watches=65536sysfs/sys/module/nvme_core/parameters/io_timeout=4294967295/sys/module/nvme_core/parameters/max_retries=lO监控节点监控指标CPU<80%Mem<80%磁盘分区使用率<8

35、0%10使用率<90%网卡流量使用率<50%(A-A网卡）主机可用性外部主机可用性监控监控服务可用性（通过Prometheus)CPU/Memovercommit预测磁盘满<1天Node中磁盘10>90%Pod无法启动（重启失败）Pod状态不readyCPU/Mem使用率4应用节点规划和调整4.1 计算节点架构和容量与Infra节点类似，Kubernetes计算节点也需要做定容量规划，避免集群过载。同时，针对部分组件特性需要有的放矢，这里主要介绍CPUManager和不同存储方案的使用场景。4.1.1 容量规划Node数量节点数量应不大于5000。但官方文档建议不同数量

36、Node对Master节点性能有额外性能要求。节点数量CPUCore数量1-516-10211-1004101-2508250-50016>50032Pod数量单节点Pod数量不超过100个，总数量不超过150000个。Namespace数量由千Namespace数量过多会导致ETCD性能下降，建议不超过10000个。每个Namespace中对象数量由千大量Controller会实现Pod控制循环，故建议每个NamespacePod数量不超过25000个。Deployment等部署对象数量不超过2000个。Service数量由千Service在Kubernetes实现依赖千lptable

37、规则，故数量建议不超过10000个。4.1.2 CPUManager默认kubelet使用CFS配额来执行Pod对CPU约束。正室Pod的CPU工作负载可能会由千其QoS等原因被分配到不同的CPUCore中。这通室般对工作负载不敏感的应用未必能感受出明显的差异，但是如果Pod中的应用是CPU密集型的，有些工作负载的性能明显地受到CPU缓存亲和性以及调度延迟的影响。对此，kubelet提供了可选的CPUManager策略，来确定节点上的些分配倌好。None策略None策略显式地启用现有的默认CPU亲和方案，不提供操作系统调度器默认行为之外的亲和性策略。通过CFS配额来实现Guaranteedpo

38、ds的CPU使用限制。Static策略Static策略针对具有整数型CPUrequests的Guaranteedpod,它允许该类pod中的容器访问节点上的独占CPU资源。这种独占性是使用cpusetcgroup控制器来实现的。需要额外注意的是，由千独占资源可能会导致该节点平台级容器无法获取CPU调度，因此在kubelet中需要额外添加kubereserved/systemreserved/reservedcpus参数保留平台计算资源。另方面，若Kubernetes集群同时包含CPU密集型和CPU非密集型应用，建议使用节点亲和性进行隔离。4.1.3 存储Kubernetes虽然支持基千Stor

39、ageClass和CS的存储接口实现，但物理存储归根结底分为以下三类块存储即传统的SAN存储作为块设备呈现给操作系统。适用千使用方需要完全控制存储文件系统的场景。本身不可共享。般云平台（如Vmware等）通过实现CSI接口以提供容器平台PVprovision。文件存储即传统的NAS存储作为NFS端点由下层操作系统或软件导出。通过手工建立NFSPV或实现NFSStor­ageClass可提供基千NAS的PV。对象存储即通过RESTfulA回访问的文件存储。般需要应用或平台层驱动支持方可作为抽象文件系统使用，否则需要直接通过RESTful操作文件。AWSS3是个典型的实现。不同类型存储使

40、用的场景参考如下：存储类型读写类型PrometheusElasticsearchRegistry应用块存储ROX建议建议不可实现建议文件存储ROX/RWX可实现但避免可实现可实现建议对象存储ROX/RWX不可实现不可实现建议（取决产品）不可实现4.2 计算节点监控和性能调优日志节点OS参数优化selinuxavecachethreshold=8192netnfconntrackhashsize=131072sysctlnet.ipv4.ip_forward=1kernel.pid_max=>131072filter.nfconntrackmax=l048576net.ipv4.neigh

41、.default.gc_thresh1=8192net.ipv4.neigh.default.gc_thresh2=32768net.ipv4.neigh.default.gc_thresh3=65536net.ipv6.neigh.default.gc_thresh1=8192net.ipv6.neigh.default.gc_thresh2=32768net.ipv6.neigh.default.gc_thresh3=65536net.ipv4.tcp_fastopen=3fs.file-max=655350fs.inotify.max_user_watches=65536sysfs/sy

42、s/module/nvme_core/parameters/io_timeout=4294967295/sys/module/nvme_core/parameters/max_retries=lO监控节点监控指标CPU<80%Mem<80%磁盘分区使用率<80%10使用率<90%网卡流量使用率<50%(A-A网卡）主机可用性外部主机可用性监控监控服务可用性（通过Prometheus)单节点Pod数量250PV剩余空间<3%CPU/MemovercommitNode不可用Nodeexporter不可用预测磁盘满<1天Node中磁盘10>90%Pod

43、无法启动（重启失败）Pod状态不readyCPU/Mem使用率应用自定义指标（如直接实现Metrics、JavaJMXexporter等第三方扩展等）4.3 应用规划4.3.1 应用资源依赖通室个容器化应用部署，势必会对周边产生依赖。本章节将列举室见的几个依赖：计算资源依赖通室Pod需要定义QoS以便声明合理地独占或共享计算资源。Kubernetes默认支持Pod对CPU和Mem资源进行定义。其中requests关键字定义的是Pod所需的最小资源量。例如应用启动依赖的内容如果大千512M,但requests设詈为512M,它可能将无法启动。而limits关键字限制定义了你需要为给定Pod提供的

44、最大资源量。同时通过实现Deviceplugin,Kubernetes可支持第三方硬件（如GPU)调度。具体QoS说明如下·另外，Kubernetes1.11版本后还支持通过定义和orityClass来声明Pod的调度优先级，这样当资源不足时优先级低的Pod就会被优先驱离。1. apiVersion:scheduling.k8s.io/vl2. kind:PriorityClass3. metadata:4. name:high-priority5. value:10006.-7. apiVersion:vl8. kind:Pod9. metadata:10. name:mypod1

45、1. spec:12. containers13. -miage:redis14 .name:mycontainer15 .priorityClassName:high-priority存储依赖通常Pod中存储主要涉及三类，包括Pod本身、emptyDir和PersistentVolumes持久卷（这里暂将Loca|Path记为以PV形式暴露）。需要注意，Pod容器本身存储大小由dockerdevicemapper限制（默认10G)，应用若超出这个数值可能导致容器应用异常。emptyDir可以通过对ephemeraI-storage的request和limit限制大小，如果超出设置数值容器可能

46、会被驱离。1.apiVersion:vl2.kind:Pod3.metadata4. name:frontend5. spec:6. containers:7. -name:db8. image:mysql9. env10.-name:MYSQL_ROOT_PASSWORD11.value:"password"12 .resources:13 .requests:14.ephemeral-storage:"2Gi"15.limits:16.ephemeral-storage:"4Gi"17.-name:wp18 .image:word

47、press19 .resources:20. .requests:21. ephemeral-storage:"2Gi"22. .limits:23. .ephemeral-storage:"4Gi"使用PV需要取人持久卷是否可以随着计算节点迁移，否则需要通过计算节点亲和性避免容器重新调度到其他节点后无法访问持久卷或持久卷丢失的情况。下图就是个基千localpath的本地存储，应进行亲和性规避。1. apiVersion:vl2. kind:PersistentVolmueClaim3. metadata:4. name:my-pvc5. spec6.

48、storageClassName:local7. accessModes:8. -ReadWriteonce9. resources:10. requests:11. storage:100Mi12.-13. apiVersion:vl14. kind:Pod15.metadata:16.name:pvc-example17. spec:18. containers·19.-miage::pvc-examplemand:'sh','-c','sleep10000'22.volmueMounts:23. .-mo

49、untPath:"/data"24. .name:my-vol25.26. .volmues:27. .-name:my-vol28. .persistentVolumeClaim:29. claimName:my-pvc上层依赖需要确认应用是否对外有额外依赖或约束。例如应用使用Ingress泰露服务时对所绑定的域名有约束、通过NodePort暴露时对VIP和端口有约束，或是使用HostPort暴露时对绑定的宿主机IP和端口有约束。4.3.2 应用配置优化对千高负载应用，如果直接使用水平伸缩HorizontalPodAutoscale,随着应用的自动扩容和收缩，往往发现期间

50、会有部分请求出现错误和中断。这Kubelet和删除Pod原理有关，其正室是步骤是1如果收到个请求来删除Pod,默认的优雅退出时间是30秒。超过该时间Pod被认为死亡，其显示状态为Terminating。2. 当Kubelet发现Pod标记为退出中的时候，开始pod关闭的流程。3. 如果该Pod定义了个停止前的钩子preStop,其会在pod内部被调用。如果钩子在优雅退出时间段超时仍然在运行，第二步会有个很小的优雅时间断被调用。随后进程被发送TERM的信号。4 与此同时，Pod对应的Endpoint对象会从Service的列表中被删除，但缓慢关闭的pod可能继续运行。5 当优雅退出时间超时了，任

51、何Pod中正在运行的进程会被发送SIGKILL信号被杀死。Kubelet会完成pod的删除，将优雅退出的时间设置为0（表示立即删除）。此时Pod会被真正删除。当第三步执行时，应用程序会获取TERM信号，如果不做任何响应，则会等最终被SIGKILL杀死。但事实上对般Java程序而言，获取TERM信号会直接退出，若此时存在正在进行的业务请求，该请求会由千JVM尝试退出而异室终止。另方面，第四步执行与第三步并行，这也意昧着应用退出时可能Kube-Proxy没有及时完全删除Service上的关联着的该实例Endpoint以及对应的集群内所有计算节点的iptable规则。因此前端仍会有请求被送到这个已经

52、停止的应用端口，进而导致请求失败。因此解决这类问题最简单的方法就是在停止应用前设置s个leep时间，因为在这个时候Kube-Proxy会删除Service上该实例的Endpoint并更新ptable,同时也可以给应用时间处理完正在进行的业务请求。1. apiVersion:extensions/vlbetal2. kind:Deployment3. metadata:4. name:nginx1sraocti1P1eers5. spec:ce678. matchLabels:9. component:nginx10. template:11. metadata12. ponent:nginx14.spec:15.containers:16.-name:nginx17.image:"nginx"18.ports19.-name:http20.h