openshift使用
摘要
Kubernetes和OpenShift既强大又灵活。 它们的设置，监视和维护规模也很复杂。 这是我们在OpenShift中监视的内容的简要介绍，以及有关我们的策略如何使您的环境受益的一些来之不易的建议。
在AppDynamics，我们构建用于内部和外部使用的应用程序。 我们一直在创新，以使我们的开发和部署过程更加高效。 我们重构应用程序以获得微服务架构的优势，在不相互依赖的情况下更快地开发和测试，并充分利用容器化。
像许多其他组织一样，我们将Kubernetes用作部署平台。 我们同时使用上游Kubernetes和OpenShift，这是一种基于类固醇的企业Kubernetes发行版。 Kubernetes框架非常强大。 它允许大规模部署，简化了新版本的发布和多变量测试，并提供了许多方法来微调开发和部署过程。
同时，这种灵活性使Kubernetes在规模设置，监视和维护方面变得复杂。 Kubernetes的每个核心组件（api服务器，kube-controller-manager，kubelet，kube-scheduler）都有许多标志来控制集群的行为和性能。 对于较小的群集，默认值最初可能是可以的，但是随着部署规模的扩大，必须进行一些调整。 我们已经学会了在监视OpenShift集群时牢记这些价值观-既是出于我们自身的痛苦，也来自经历过自己的拔毛发现的其他社区成员的已发表报告。
我们使用自己的工具来监视我们的应用程序，包括部署到OpenShift集群的应用程序，也就不足为奇了。 Kubernetes只是基础架构的另一层。 连同服务器和网络可见性数据，我们现在将Kubernetes和OpenShift指标纳入更大的监控范围。
在此博客中，我们将分享我们在OpenShift集群中监视的内容，并就我们的策略如何与您自己的环境相关提供建议。 （有关更多动手建议，请阅读我的博客《 使用Init容器将AppDynamics代理部署到OpenShift》 ）。
OpenShift集群监控
对于OpenShift群集监视，我们使用两个可以与我们的独立计算机代理一起部署的插件。 AppDynamics的Kubernetes事件扩展 ，在我们的监视Kubernetes事件的博客中进行了描述，它跟踪集群中的每个事件。 Kubernetes Snapshot Extension捕获各种群集资源的属性，并将其发布到AppDynamics Events API。 快照扩展收集所有部署，窗格，副本集，守护程序集和服务端点上的数据。 它捕获了可用属性的全部范围，包括元数据，规范详细信息，指标和状态。 这两个扩展都使用Kubernetes API检索数据，并且可以配置为以所需的时间间隔运行。
这些插件提供的数据最终存储在我们的分析数据存储库中，并可立即用于挖掘
，报告，基准和可视化。
数据保留期至少为90天，这提供了足够的时间返回并执行详尽的根本原因分析（RCA）。
它还允许您减少事件在群集本身中的保留间隔。
（默认情况下，此时间设置为一小时。）
我们使用收集到的数据来构建动态基准，设置健康规则并创建警报。 然后，可以在自定义仪表板上显示运行状况规则，基准和汇总数据点，操作员可以在其中查看规范并轻松发现任何偏差。
可自定义的Kubernetes仪表板的示例。
我们监控什么以及为什么
集群节点
在基础级别上，我们希望监视操作员密切注意群集所在节点的运行状况。 通常，您将拥有一个主集群，其中部署了核心Kubernetes核心组件（api服务器，控制器管理器，kube时间表等），以及一个高可用的etcd集群和许多用于来宾应用程序的工作节点。 为了描绘出一个完整的图景，我们将基础架构运行状况指标与我们的Kubernetes数据收集器收集的相关集群数据结合在一起。
从基础结构的角度来看，我们跟踪所有节点上的CPU，内存和磁盘利用率，并放大etcd上的网络流量。 为了发现瓶颈，我们以粒度级别查看流量的各个方面（例如，读/写和吞吐量）。 Kubernetes和OpenShift集群可能会遭受内存不足，磁盘上的日志过多填充或API服务器使用量激增以及因此而遭受苦难的困扰。 具有讽刺意味的是，它经常监视解决方案，这些解决方案通过从Kubernetes API中提取过多信息来关闭集群。 确定多少监视已足够并在必要时进行拨号以进一步诊断问题始终是一个好主意。 如果需要进行高度监视，则可能需要添加更多的master和etcd节点。 另一个有用的技术，特别是在大规模实现中，是具有一个单独的etcd集群，仅用于存储Kubernetes事件。 这样，用于监视目的的事件创建和事件检索中的峰值不会影响主要etcd实例的性能。 可以通过设置api服务器的–etcd-servers-overrides标志来实现，例如：
–etcd-servers-overrides = / events＃https：//etcd1.cluster.com：2379; https：// etcd2。 cluster.com:2379;https://etcd3。 cluster.com:2379
从集群的角度来看，我们监视允许Pod调度的节点之间的资源利用率。 我们还将跟踪pod的数量，并可视化将多少个pod部署到每个节点以及其中有多少个坏（失败/撤离）。
包含基础架构和集群指标的仪表板小部件。
为什么这很重要？ Kubelet是负责管理给定节点上的pod的组件，其设置为–max-pods ，它确定可以编排的pod的最大数量。 在Kubernetes中，默认值为110。在OpenShift中，默认值为250。可以根据需要向上或向下更改该值。 我们希望可视化每个节点上的剩余空间，这有助于主动进行资源规划并防止突然的溢出（这可能意味着中断）。 我们添加的另一个数据点是每个节点逐出的Pod数。
豆荚驱逐
逐出是由于空间不足或内存不足。 由于日志失控，我们最近在一个工作节点上的磁盘空间出现了问题。 结果，kubelet产生了对该节点的吊舱的大量逐出。 由于许多原因，驱逐都是不好的。 它们通常会影响服务质量，甚至可能导致中断。 如果逐出的Pod与遇到磁盘压力的节点具有排他性关系，并且因此无法在集群中的其他地方重新安排，则逐出将导致中断。 驱逐核心组件吊舱可能会导致群集崩溃。
驱逐豆荚的事件发生很久之后，我们看到被驱逐的豆荚仍在徘徊。 怎么会这样 垃圾回收的收集是由kube-controller-manager中称为–terminated-pod-gc-threshold的设置控制的。 默认值设置为12,500，这意味着直到您有许多被驱逐的Pod才会进行垃圾收集。 即使在大型实施中，将这个阈值降低到较小的数字也是一个好主意。
如果您遇到大量迁离的情况，则可能还需要检查kube-scheduler是否定义了没有CheckNodeMemoryPressure或CheckNodeDiskPressure谓词的自定义–policy-config-file 。
在我们最近的事件之后，我们设置了一个新的仪表板小部件，该小部件可跟踪可能导致集群崩溃（例如大规模迁离）的任何威胁的指标。 我们还将健康规则与此指标相关联并设置了警报。 具体来说，我们现在正在寻找警告事件，这些事件告诉我们何时节点将要经历内存或磁盘压力，或者何时无法重新分配Pod（例如NodeHasDiskPressure ， NodeHasMemoryPressure ， ErrorReconciliationRetryTimeout ， ExceededGracePeriod ， EvictionThresholdMet ）。
我们还寻找守护程序Pod故障（ FailedDaemonPod ），因为它们通常与群集运行状况有关，而不是与守护程序集应用程序本身有关。
播客问题
吊舱坠毁显然是要监视的目标，但我们也对跟踪吊舱的死亡感兴趣。 为什么有人要杀死豆荚？ 这样做可能有充分的理由，但也可能表示应用程序有问题。 出于类似的原因，我们通过检查ScalingReplicaSet事件来跟踪部署缩减。 我们还希望可视化缩小趋势以及应用程序的健康状态。 例如，按比例缩小可能是在应用程序负载减少时通过自动缩放设计实现的。 它们也可能是手动发布的，也可能是错误发布的，并且可能会使应用程序承受过多的负载。
待定状态应该是吊舱生命周期中的一个相对较短的阶段，但有时并非如此。 跟踪等待时间超过某个合理阈值（例如一分钟）的Pod可能是个好主意。 在AppDynamics中，我们还可以为所有指标设定基准，然后跟踪与基准之间的任何可配置偏差。 如果您在未决状态持续时间内遇到高峰，那么首先要检查的是图像的大小和图像的下载速度。 一幅大图可能会阻塞管道并影响其他容器。 Kubelet具有此标志–serialize-image-pulls ，默认情况下将其设置为“ true”。 这意味着将一次加载一张图像。 如果要并行加载图像并避免被怪物大小的图像阻塞，请将标志更改为“ false”。 但是请记住，您必须使用Docker的overlay2存储驱动程序才能完成此工作。 在较新的Docker版本中，此设置为默认设置。 除了Kubelet设置之外，您可能还需要调整Docker守护程序的max-concurrent-downloads标志，以确保所需的并行性。
下载时间较长的大映像可能还会导致其他类型的问题，从而导致部署失败。 Kubelet标志–image-pull-progress-deadline确定图像被认为“太长而无法拉出或提取”的时间点。 如果要处理大图像，请确保拨出该标志的值以适合您的需求。
用户错误
集群中的许多大问题源于小的用户错误（人为错误）。 规范中的错字（例如，映像名称）可能会破坏整个部署。 由于缺少映像或对注册表的权限不足，可能会发生类似的效果。 考虑到这一点，我们会密切跟踪图像错误，并注意过度拉扯图像。 除非确实需要，否则，为了节省带宽并加快部署速度，您需要避免图像拖拽。
由于规格错误，权限不足或策略冲突，也容易出现存储问题。 我们监视存储问题（例如，安装问题），因为它们可能会导致崩溃。 我们还密切关注违反资源配额的情况，因为它们不会触发pod失败。 但是，它们将阻止启动新部署以及阻止现有部署扩大规模。
说到配额违规，您是否在部署规范中设置资源限制？
监管集群
在我们的OpenShift仪表板上，我们显示了一个潜在的危险信号列表，这些信号不一定是问题，但可能会导致严重的问题。 其中有没有资源限制的Pod，也没有部署规范中的运行状况调查。
资源限制可以通过整个群集中的资源配额或更精细的级别来实施。 违反这些限制将阻止部署。 在没有配额的情况下，可以在没有定义资源限制的情况下部署Pod。 由于多种原因，没有资源限制是不好的。 这使集群容量规划具有挑战性。 这也可能导致中断。 如果在没有限制的活动吊舱中创建或更改资源配额，则这些吊舱的任何后续扩展或重新部署都将导致失败。
健康状况调查，准备状态和活动状态不是强制性的，但最好在规范中进行定义。 它们是Pod告诉kubelet应用程序是否已准备好接受流量并且仍在运行的主要机制。 如果未定义就绪探测器，并且Pod需要很长时间进行初始化（基于kubelet的默认值），则该pod将重新启动。 此循环可能会持续一段时间，无故占用群集资源，并有效导致不良的用户体验或中断。
如果应用程序正在执行冗长的操作并且吊舱对Kubelet似乎无响应，则缺少活动探针可能会导致类似的效果。
我们可以轻松访问规格不完整的Pod列表，使集群管理员可以与开发团队进行针对性的纠正措施对话。
路由和端点跟踪
作为OpenShift监视的一部分，我们提供了对潜在路由和服务端点问题的可见性。 我们会跟踪未使用的服务，包括那些由错误的人创建的服务以及由于Pod发生故障或被移除而在其后没有任何Pod的服务。
我们还将监视指向旧（已删除）吊舱的不良端点，这些端点会导致停机。 当群集承受的负载增加并且API请求限制低于所需的数量时，滚动更新期间可能会发生此问题。 要解决此问题，您可能需要增加kube-controller-manager的–kube-api-burst和–kube-api-qps配置值。
我们可以在列表中查看和分析在仪表板上显示的每个指标，并使用AppDynamics查询语言ADQL进一步完善。 在仪表板上发现异常之后，操作员可以钻取原始数据以找出问题的根本原因。
应用监控
上下文在我们的监视哲学中起着重要作用。 我们始终通过最终用户体验和期望的业务成果来审视应用程序性能。 与专用的群集监视工具不同，我们不仅对群集的运行状况和正常运行时间感兴趣。 我们同样关注集群可能对应用程序运行状况以及随后对应用程序的业务目标的影响。
除了拥有集群级仪表板之外，我们还构建了具有更以应用程序为中心的观点的专用仪表板。 在那里，我们将群集事件和异常与应用程序或组件的可用性，实际用户监视报告的最终用户体验以及业务指标（例如，特定用户细分的转化）相关联。
利用K8s元数据
Kubernetes使运行Canary部署，蓝绿色部署以及A / B或多变量测试变得非常容易。 我们通过提取部署元数据并使用标签并排分析不同版本的性能来利用这些便利。
监控Kubernetes或OpenShift只是AppDynamics满足内部需求和客户需求的一部分。 AppDynamics涵盖了从基础基础架构到商业智能的整个端到端监控范围。 从本质上讲，AppDynamics被许多不同技能的操作员组使用。 例如，我们将平台视为协作工具，可以帮助将APM的语言转换为Kubernetes的语言，反之亦然。
通过将这些不同的数据集集中在一起，AppDynamics为不同的运营商群体建立了共同点。 一方面，您有集群管理员，他们是Kubernetes的专家，但可能不了解来宾应用程序的详细信息。 另一方面，您可能需要由DevOps负责APM或经理查看业务指标，而他们可能对Kubernetes并不十分熟悉。 这些小组现在可以使用每个人都很好理解的术语和单个工具来检查共享仪表板上的数据点，进行富有成效的监视对话。
了解有关AppDynamics如何帮助您在Kubernetes和OpenShift上监视应用程序的更多信息。
翻译自: https://www.javacodegeeks.com/2018/10/kubernetes-openshift-appdynamics.html
openshift使用
4209
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
