本专题主要对整个阿里云产品的概览、集群规划创建、核心组件配置及优化、集群运维四个部分进行介绍。

本文为第三部分和第四部分，点击这里，查看第一部分和第二部分。

想看精彩直播回放，请点击这里。

以下为精彩直播内容整理：

三、核心组件配置及优化

核心组件-Ingress Controller部署架构：混布（中小规模）

当建好集群以及布好业务之后，为了更好的对外服务，Ingress是以Pod的形式部署在k8s里，集群默认初始化的配置给到的是Ingress Controller集齐的两个Pod，这两个Pod是随机的运行在Worker节点上的，基于这样的场景，对于一些中小规模的集群运行是没问题的。Ingress Controller和其他的Pod是同步在Worker节点上，这样会灵活伸缩，同时维护比较简单。但是，在这个节点上同时存在外部的南北流量和内部的东西流量，会产生流量的叠加，所以这样的场景比较适合中小规模。对整个Ingress需要对外访问的Kubernetes要求不会特别高的场景，可以用默认的配置直接使用。

核心组件-Ingress Controller部署架构：独立部署（大规模）

Ingress Controller核心组件的Pod可以独立进行部署，相当于是规划好的一组node节点。使这组节点不调动其他非Ingress的Pod，就只应用于Ingress Controller，这样的能力相当于这个节点上只提供Ingress Controller的Pod使用，从而最大限度的保证性能。但存在的问题是需要手动的维护机器组，当伸缩时，维护相对复杂。好处是一个节点内只有南北流量，或者只有东西流量，抗干扰性好，并且Ingress性能也有所保障。有一点需要注意的是，如果用于独立部署ingress controller的节点需要选择大规划，nf_conntrack表会受限于CPU核数，同时定义每一core对应的基本值为多少。Ingress Controller节点选择什么规格就决定了这个节点上能有多少的转发能力，nf_conntrack表就直接决定了转发的性能。通常，ingress的南北流量很大，但是ingress controller没有做特定的隔离选择，可能运行在普通的机器上，大概十几万的转发表，在高峰业务流量后很容易将ingress controller打垮，这属于一个典型的案例。

核心组件-独立部署Ingress Controller配置建议
独立部署Ingress Controller配置建议如下：

• 选用32c/64g的配置2~3台对应一个SLB(5G入口流量) ，作为Ingress Controller节点组共同承担Pod任务；
• 为部署的机器打上污点标签例如Taint: Ingress=:NoEexcute；
• 设置Ingress controller的POD资源限制为request/limit: 15c/32g；
• 设置Ingress controller使用ENI(对应Service要用cluster类型)；
• 更改对应的SLB规格（支持的并发数），以及选择按照流量计费（最大支持5G），或者使用指定已有SLB创建ingress-lb-svc。

核心组件-Ingress Controller的Nginx参数配置
Ingress controller通过configmap的key-value来配置Nginx的参数，可以使用官方的配置文档（https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/）来调节。

核心组件-Ingress Controller性能调优

默认的Controller存在一些默认的参数优化由上图左侧部分，还有一些定制化的参数优化，比如timeout的参数配置，可以通过自己修改configmap来实现。修改完的configmap是无需重新启动Pod的，可以自动地刷新配置。

核心组件-CoreDNS
CoreDNS作为内部的服务解析的组件，包括外部域名的服务解析。建议配置cluster-proportional-autoscaler，根据node数量以及vCore的数量水平自动扩展副本数；容器内打开nscd（域名缓存服务）时，可大幅提升解析性能；严禁生产环境使用alpine作为基础镜像，会导致dns解析请求异常。

核心组件-容器伸缩

HPA作为原生提供的水平伸缩，可以根据CPU或者外部的指标做外部的指标扩容。目前VPA作为还未成熟的方案，主要指容器的Pod的资源限制，包括容器垂直的伸缩。阿里云提出的定时POD伸缩能力已经开源。同样通过人为也可以进行伸缩。这些伸缩都只在集群内部的Pod伸缩，当Pod伸缩到触及整个最大容量上限时，就需要一个Cluster级别的伸缩，此伸缩为集群里的node节点。

核心组件-Cluster Autoscaler

由此产生Cluster Autoscaler核心组件，其核心在于有一个Cluster Autoscaler scheduler调度器，会监听整个调度的状态，当前集群里面有多少Pod是属于pending状态，这些pending状态的Pod需要多少资源，再根据定义的ESST弹性伸缩组里的规格配置，算出需要多少数量，自动触发购买并加入到K8S集群，最后将没有调度的Pod调度到新的节点上，完成闭环状态。

核心组件-Kubernetes日志数据采集
运用越来越多的k8s分布式，则水平扩展的Pod会越来越多，业务里需要完成一键采集、统一管理以及查看日志是必要的任务。目前阿里云的整个k8s ICK是跟整个服务组建完成无缝的连接，当创建集群时勾选了使用日志服务时，阿里就会协助日志服务的Controller，自动的帮助做一些与日志服务对接的工作。从客户应用层面来说，只需要写一个环境变量，如下图所示，实现日志统一的采集。

核心组件-多维度一体化监控体系

监控也是重要的环节，对所有运行的各种组件的状态，能够及时的监控，并且出现异常以后能够触发告警。概括来说，监控可以包含几个部分，最底层为物理主机/VM层监控，指监控系统指标、CPU内存及网络流量等。第二层为容器POD指标监控，涉及到容器本身的系统指标，同样有CPU内存等指标。还有一层指容器POD里面的应用指标，相当于容器CaaS层资源监控。再往上一层为应用层性能监控，对整个应用层进行跟踪和监控。针对不同维度会有不同对接的产品提供相应的服务能力。

核心组件-POD监控/告警
通过创建集群时选择打通云监控，会自动提供丰富的监控能力。

如上图所示可以看到在K8S节点监控：每个节点/Master维度/Node维度，Master组件/Node组件维度，Deployment维度，POD实例维度。

核心组件-应用性能管理ARMS
针对全局应用层拓扑、全局应用性能统计与分析（Dashboard）、调用链分析采用慢调用，异常调用、异常快速定位与告警、方法栈调用分析、JVM监控、快速定位与分析、告警、SQL慢调用分析、动态生效配置，生产级适配、业务日志结合，调用链与业务逻辑关联分析等业务内部生成式的各种的可观测性的指标都可以在ARMS产品上进行管理。

核心组件-ARMS“无侵入式”快捷接入(Java)
整个接入是与阿里的容器服务做controller，controller可以自动的捕捉应用Pod创建的生命周期时是否需要接ARMS，唯一需要做的是在文件里加上annotation，通知arms pilot是可以利用的，以及创建arms pilot的名字，之后arms pilot CRD的controller自动的捕捉Pod创建的生命周期，在Pod启动时，需要用到ARMS的Java探针打在容器里面。这样做的优势是对代码不需要完全的侵入。

四、集群运维

集群运维-一键升级过程

平台提供一个Kubernetes版本的一键升级能力，相当于k8s版本的一个生命周期的迭代，作为由平台方提供一键升级的能力。需要做的只是选择一个在业务低峰时做的升级操作，升级主要分为两部分：第一部分，Master节点做串行的滚动升级，可以说是一台一台升级的，升级过程中对整个业务的访问、发布和使用是没有任何影响的；第二部分，node节点并行升级，相当于很多的节点同时进行升级，在升级过程中只是升级节点3的kubelet组件，并不会引起下面运行的Pod容器的中断，所以这样一键升级的过程是安全、可控的。

集群运维-系统组件升级

针对系统内部使用的系统组件，比如application-controller、disk-controller以及Cloud Controller等一些核心的能力组件，都会定期的进行新特性能力的增强，以及提供自主升级，
只需要定期的关注需要升级的页面，查看是否需要升级的部分，然后进行一键升级就可以。

集群运维-平台审计日志

在整个k8s集群里有很多的通道都会操作集群，比如原生的控制台，镜像操作及其他日志服务等与API Server都有耦合的渠道产生日志，这些渠道的各种日志都会统一的进行监控数据的采集，并且生成平台审计的Dashboard。如下图，时间和操作都可以在Dashboard上查看到。

集群运维-利用NPD增强node错误检测

针对生产集群需要配置的NPD，是作为一个工具使用。节点问题自动化的检测及告警的过程核心是实现挖取API及node节点上的Event，查看Event是否报出。在原生的BPD的社区能力上做出一些增强，包括检测节点进程号PID是否被耗尽以及文件句柄FD 是否被耗尽。

集群运维-密切监控线程/进程和文件句柄泄漏

通过提前获知节点是否ready，知道这些节点的问题，为什么会引起节点的not ready，还是由于业务负载太高或者是运行的容器进程泄露，考虑这些问题，对整个安全区管理和掌控的整个集群的稳定性会是很好地帮助。

集群运维-K8S Event信息归档以及告警

集群默认Event保留1小时后被轮转，给查问题带来不便。建议配置eventer统一采集到SLS存储。

集群运维-查错的经典步骤

• ECS 互通是否有异常
• 安全组是否配置有误
• 使用子账户，授权是否正确
• Docker run 的方式运行，是否能正常提供服务
• 在K8S 里通过一个POD 去访问目标的POD 是否正常
• 通过service 方式访问是否正常
• 通过SLB/Ingress 方式访问是否正常
• Kubectl get event 是否有异常
• Api server/schedule/controller 日志是否有异常
• Docker daemon日志是否有异常

集群运维-节点NotReady查错

• 是否被Cordon ？节点状态是”Ready， SchedulingDisabled”
• 是否被链接不上API Server(kubelet 日志)，API Server 私网SLB 是否存在？
• PID 满？
• 是否机器时钟没有同步？NTP 没有启动？
• Docker Daemon, Kubelet 是否启动以及状态正常？
• 是否磁盘满？磁盘IO 是否正常？（df –h） ）
• 安全组是否一致，是否连接不上API Server
• Fail/completed 的容器数量过多docker ps -a | wc -l # n > 5000

集群运维-Kubelet/Docker挂死的应急恢复处理
有两种处理方法：
1.恢复办法：重启systemctl daemon-reexec重启systemctl restart docker(可选视情况定)重启systemctl restart kubelet。
2.减缓办法：对于容器的liveness/readiness使用tcp/httpget的方式，避免高频率使用exec。

本文为第三部分和第四部分，点击这里，查看第一部分和第二部分。

扫描下方二维码，加入开发与运维钉钉交流群，查看更多精彩内容。