存储卷介绍 Kubernetes 使用存储的原因 Kubernetes 中的副本控制器保证了pod的始终存储,却保证不了pod中的数据。只有启动一个新pod的,之前pod中的数据会随着容器的删掉而丢失! 共享存储机制 Kubernetes 对于有状态的容器应用或者对数据需要持久化的应用,不仅需要将容器内的目录挂载到宿主机的目录或者emptyDir临时存储卷,而且需要更加可靠的存储来保存应用产生的重要数据,以便容器应用在重建之后,仍然可以使用之前的数据。Kubernetes引入持久化存储卷(PV)和持久化存储声明(PVC)两个资源对象实现对存储的管理子系统。 概念PV 的全称是:PersistentVolume(持久化卷),是对底层共享存储的一种抽象,PV 由管理员进行创建和配置,是一个全局资源,包含存储的类型,存储的大小和访问模式等。它和具体的底层的共享存储技术的实现方式有关,比如 Ceph、GlusterFS、NFS、hostPath 等,都是通过插件机制完成与共享存储的对接。 PVC 的全称是:PersistentVolumeClaim(持久化卷声明),PVC 是用户存储 ...
Ingress 流量出于简单性和可组合性的原因,Linkerd 本身没有提供内置的 Ingress 控制器。Linkerd 旨在与许多现有的 Kubernetes Ingress 解决方案一起使用。 将 Linkerd 和您选择的入口解决方案结合起来需要两件事: 配置您的 Ingress 以支持 Linkerd。 网格化你的 Ingress 控制器,以便它们安装 Linkerd 代理。 对 Ingress 控制器进行网格化将允许 Linkerd 在流量进入集群时提供 L7 指标和 mTLS 等功能,Linkerd 支持与大部分 Ingress 控制器进行集成,包括: Ambassador (aka Emissary) Nginx (community version) Nginx (F5 NGINX version) Traefik Traefik 1.x Traefik 2.x GCE Gloo Contour Kong Haproxy EnRoute ngrok ingress-nginx这里只演示如何开启 ingress-nginx 与 Linkerd 进行集成,不 ...
背景介绍在当今的软件开发环境中,持续集成(Continuous Integration,CI)和持续部署(Continuous Deployment,CD)是非常重要的概念。它们可以帮助我们实现高效的软件开发,提高软件质量,降低软件开发成本。在这篇文章中,我们将深入探讨测试自动化的持续集成与持续部署,并探讨它们如何帮助我们实现高效的软件开发。 核心概念与联系持续集成(Continuous Integration,CI)持续集成是一种软件开发策略,其核心思想是将开发人员的代码通过自动化的构建和测试系统进行集成和测试,以确保代码的质量和可靠性。通常,持续集成包括以下几个步骤: 开发人员在本地环境中编写代码并进行测试。 开发人员将代码推送到共享的代码仓库。 自动化构建系统从代码仓库中获取最新的代码,并进行构建。 自动化测试系统运行所有的测试用例,以确保代码的正确性和质量。 如果测试通过,则将代码部署到下一个环境中,如测试环境或生产环境。 持续集成的主要优点包括: 提高代码质量:通过自动化的构建和测试,可以及时发现和修复代码中的问题,从而提高代码质量。 提高开发效率:开发人员可以更加快速 ...
概述前面我给大家分享了关于分布式链路追踪的基本原理和 SkyWalking的k8s部署玩法,如果还没来得及看的朋友可以看我上俩篇文章。 今天要给大家分享是我们日常工作中最常见的一种场景,那就是部署在k8s环境下的Java微服务,要接入SkyWalking的具体玩法,通过这个过程咱们可以更深入的理解SkyWalking进行数据采集的逻辑,也能更深刻地从运维角度理解日常工作中所写的Java微服务被无侵入的方式接入分布式链路追踪系统的过程! Java微服务接入SkyWalking的方式SkyWalking 的数据采集主要是通过**业务探针(Agent)**来实现的,针对不同的编程语言 SkyWalking 提供了对应的 Agent 实现。Java微服务接入SkyWalking可以使用SkyWalking Java Agent来上报监控数据。 这就需要Java微服务在部署启动的过程中需要获取 SkyWalking Java Agent 探针包,并在启动参数中通过 --javaagent:xxx 进行参数指定。而具体的集成方式大致有以下三种: 使用官方提供的基础镜像; 将agent包构建到已存 ...
Skywalking监控k8s集群资源目前监控k8s集群指标是SkyWalking v9版本新特性,配置的时候网上一篇文章没有,搞了很久,记录一下,经验之谈就是多番找GitHub中 Issues 和阅读官方文档。 官方文档解释监控k8s集群地址:https://skywalking.apache.org/docs/main/next/en/setup/backend/backend-k8s-monitoring 安装kube-state-metric本次安装采用的是 Prometheus Operator 中部署的kube-state-metric,如果你想只想安装 kube-state-metric 请关注公众号回复:kube-state-metric 获取yaml。 12345678910111213# 验证 Prometheus Operator 安装的需要通过https请求访问$ kubectl describe secrets -n monitoring prometheus-k8s-token-j5spg$ curl -k -H "Authorization: B ...
Skywalking介绍 Skywalking 是一个国产的开源框架,2015年有吴晟个人开源,2017年加入Apache孵化器,国人开源的产品,主要开发人员来自于华为,2019年4月17日Apache董事会批准SkyWalking成为顶级项目,支持Java、.Net、NodeJs等探针,数据存储支持Mysql、Elasticsearch等,跟Pinpoint一样采用字节码注入的方式实现代码的无侵入,探针采集数据粒度粗,但性能表现优秀,且对云原生支持,目前增长势头强劲,社区活跃。Skywalking是分布式系统的应用程序性能监视工具,专为微服务,云原生架构和基于容器(Docker,K8S,Mesos)架构而设计,它是一款优秀的APM(Application Performance Management)工具,包括了分布式追踪,性能指标分析和服务依赖分析等。 关于微服务微服务架构已经是一个很通用的系统架构,常见的技术栈如下图所示,这张架构图基本涵括了当前微服务体系下的各种技术栈,可能不同的技术栈有不同的开源实现。 链路追踪工具对比链路追踪框架对比目前市面上开源的APM系统主要有CAT ...
重试与超时在构建分布式系统时,保证可靠性是一项关键任务。Linkerd 是一个功能强大的服务网格工具,通过其重试与超时机制,可以帮助应对临时错误和延迟问题,从而提高系统的可靠性。本文将深入探讨 Linkerd 中的重试与超时特性,以及它们如何帮助应对故障和提升用户体验。 重试是一种处理失败请求的机制。当一个请求失败时,Linkerd 的重试机制可以自动重试请求,以期获得成功的响应。当特定实例上的特定路由返回错误时,Linkerd 可以简单地重试该请求,从而增加请求成功的可能性。这对于处理临时性的网络问题非常有用,例如网络拥塞或服务暂时不可用。通过重试,可以增加请求成功的机会,并提高系统的可靠性。然而,在实践中,实现重试可能会面临一些挑战。可能会给系统增加额外的负载,这个负载可能会让事情变得更糟糕。一种常见的故障场景就是重试风暴,为了避免重试风暴的发生,Linkerd 使用重试预算来设置重试参数。重试预算是可以重试的请求总数的百分比,Linkerd 默认允许对失败的请求进行 20% 的重试,并每秒额外允许 10 个请求的重试。这种方式可以有效地降低重试风暴的风险,确保系统的稳定性。 超时 ...
Service ProfilesLinkerd 服务网格解决的最重要问题之一是可观察性:提供服务行为的详细视图,Linkerd 对可观察性的价值主张是,它可以为你的 HTTP 和 gRPC 服务提供黄金指标,这些都是自动执行,无需更改代码或开发人员参与的。 部署测试应用了解 Linkerd 如何为一项服务工作,安装一个简单的示例应用 Emojivoto,该应用是一个简单的独立 Kubernetes 应用程序,它混合使用 gRPC 和 HTTP 调用,允许用户对他们最喜欢的表情符号进行投票。 通过运行以下命令可以将 Emojivoto 安装到 emojivoto 命名空间中: 1$ curl -fsL https://run.linkerd.io/emojivoto.yml | kubectl apply -f - 在我们对它进行网格(mesh)划分之前,让我们先来看看这个应用程序。可以通过 port-forward 来暴露 web-svc 服务kubectl -n emojivoto port-forward svc/web-svc 8080:80,也可以使用Ingress 1234 ...
Alertmanager简介Prometheus 架构中采集数据和发送告警是独立出来的, 告警触发后将信息转发到独立的组件 Alertmanager,满足告警触发条件就会向 Alertmanager 发送告警信息,最后通过接收器 recevier 发送给指定用户。 工作机制Alertmanager 收到告警信息后: 进行分组 Group(告警组) 通过定义好的路由 routing 转发到正确的接收器 recevier recevier 通过 email dingtalk wechat 等方式通知给定义好的接收人 四大功能 分组 (Grouping): 将同类型的告警进行分组, 合并多条告警到一个通知中 抑制 (Inhibition): 当某条告警已经发送, 停止重复发送由此告警引起的其他异常或者故障 静默 (Silences): 根据标签快速对告警进行静默处理, 如果告警符合静默的配置, Alertmanager 则不会发送告警通知 路由 (Route): 用于配置 Alertmanager 如何处理传入的特定类型的告警通知 配置详解123456789101112131415 ...
简介白盒监控vs黑盒监控白盒监控:监控主机的资源用量、容器的运行状态、数据库中间件的运行数据等等,这些都是支持业务和服务的基础设施,通过白盒能够了解其内部的实际运行状态,通过对监控指标的观察能够预判可能出现的问题,从而对潜在的不确定因素进行优化。 黑盒监控:以用户的身份测试服务的外部可见性,常见的黑盒监控包括 HTTP 探针 TCP 探针 等用于检测站点或者服务的可访问性,以及访问效率等。 黑盒监控相较于白盒监控最大的不同在于黑盒监控是以故障为导向的. 当故障发生时,黑盒监控能快速发现故障,而白盒监控则侧重于主动发现或者预测潜在的问题。一个完善的监控目标是要能够从白盒的角度发现潜在问题,能够在黑盒的角度快速发现已经发生的问题。 blackbox exporterBlackbox Exporter 是 Prometheus 社区提供的官方黑盒监控解决方案,其允许用户通过 HTTP HTTPS DNS TCP ICMP 以及 gPRC 的方式对 endpoints 端点进行探测。可以用于下面的这些场景: HTTP 测试:定义 Request Header 信息、判断 Http statu ...
服务发现简介在 Prometheus Operator 中, 我们无需手动编辑配置文件添加 kubernetes_sd_config 配置, Prometheus Operator 提供了下述资源: serviceMonitor:创建 endpoints 级别的服务发现 podMonitor:创建 pod 级别的服务发现 probe:创建 ingress 级别的服务发现(用于黑盒监控) 通过对这三种 CRD 资源的管理实现 prometheus 动态的服务发现。 除了 Kubernetes 集群中的一些资源对象、节点以及组件都需要监控,有的时候可能还需要根据实际的业务需求去添加自定义的监控项,添加一个自定义监控的步骤也是非常简单的。 第一步建立一个 ServiceMonitor 或 podMonitor 对象,用于 Prometheus 添加监控项 第二步为 ServiceMonitor 或 podMonitor 对象关联 metrics 数据接口的一个 Service 对象 第三步确保 Service 或 Pod 对象可以正确获取到 metrics 数据 接下来就来为大家演示 ...
Prometheus Operator介绍Prometheus Operator:为监控 Kubernetes 资源和 Prometheus 实例的管理提供了简单的定义,简化在 Kubernetes 上部署、管理和运行 Prometheus 和 Alertmanager 集群。 Prometheus Operator 的核心特性是 watch Kubernetes API 服务器对特定对象的更改,为 Kubernetes 提供了对 Prometheus 机器相关监控组件的本地部署和管理方案,该项目的目的是为了简化和自动化基于 Prometheus 的监控栈配置,主要包括以下几个功能: Kubernetes 自定义资源:使用 Kubernetes CRD 来部署和管理 Prometheus、Alertmanager 和相关组件。 简化的部署配置:直接通过 Kubernetes 资源清单配置 Prometheus,比如版本、持久化、副本、保留策略等等配置。 Prometheus 监控目标配置:基于熟知的 Kubernetes 标签查询自动生成监控目标配置,无需学习 Prometheus ...