一、前言一说起kuberenetsb集群备份，我们首先会想到etcd数据备份，因为我们kubernetes数据都是以键值的形式存储在etcd中，上一边文章也讲解了关于etcd快照备份也恢复，但是etcd备份是全局的，无法针对于集群对象级别的备份，这一期，我们了解kubernetes备份的"新宠"-Velero二、概念讲解1. 什么是 Velero?Velero 是一个 Vmware 大厂用 Go
一、前言Kubernets集群在企业中的运用，数据备份是至关重要的，而k8s集群数据是存储在etcd键值数据库中，倘若出现数据误删除或者服务器集群宕机等情况，会导致etcd数据的丢失或者某个etcd节点异常。此时我们最快速最有效的方法就是从备份中去恢复集群数。二、实验环境首先准备了一套标配的二进制部署的k8s集群，三个（master、etcd）节点+两个node节点，创建名为"test-bak"命
一、前言在k8s中，ConfigMap这一概念相信很多小伙伴都知道吧？它是Kubernetes中一种机制，很多应用在其初始化或者运行期间要依赖一些配置信息，可让你将配置数据注入到应用的Pod内部，允许你将配置清单与镜像内容，以保持容器化的应用程序的可移植性。前几天在某一公众号看到关于网友留言提出疑问：应用程序配置如环境变量或者以ConfigMap的方式可以不重建实现动态更新吗？，先不说结论，那么我
一、前言用过阿里云平台的小伙伴相信大家都对阿里云的对象存储OSS都了解，这款产品对我们企业日常数据文件归档备份都起着至关重要的作用，本期就简单来了解一下，如何实现本地文件通过相应指令去实现文件的上传备份归档。二、环境类别本地mac上传安装ossutil工具#curl https://gosspublic.alicdn.com/ossutil/install.sh | sudo bash配置本地环境
一、前言现如今，互联网安全问题已经引起各个企业的重点关注，门户网站对外提供服务，用户浏览访问，很容易遭受到不法分子攻击，甚至泄露敏感数据信息。而SSL 证书已成为保护用户数据和隐私的必备工具，一般情况下，我们会花钱去正规渠道购买证书，如果不想花那钱，自然也是有许多免费 SSL 证书的，但有效期仅为三个月，这就意味着网站管理员需要频繁地更新证书，为了解决这个痛点，就引入了acme工具。二、实现过程1
一、前言在上一篇中详细讲解了Jenkins 流水线发布的内容，主要在部署环节，我们是通过kubectl set更新镜像的方式来完成版本迭代，如果忘记大家可以参考上篇博客（https://blog.51cto.com/u_11880730/7246083），虽然方式可行，但仍存在美中不足地方。如存在以下弊端1、Jenkinsfile 与Deployment解耦。在上述文章中要想完成业务流程发版，在初
一、前言因一次Harbor 域名DNS解析变更，导致在认证以及push或pull都会出现 “x509: certificate signed by unknown authority”问题。二、问题排查思路首先在Harbor仓库本地尝试docker login登录验证是否可行，发现同样失败。该错误在网上很常见，尝试在本地指定insecure-registries参数，设置允许Docker
一、前言今日研发反馈服务版本迭代上线之后出现404情况，询问Nginx是否有做调整，我这边确认没有变更，该项目比较特殊，前端静态文件是集成至后端Java程序里面的，根据以往的经验，多半是后端的Java程序存在问题。二、问题排查首先确认是否是后端程序问题，于是乎我跳过Nginx代理层，直接通过curl 后端IP加端口跟上URL路径测试是否同样返回404，其结果果然不出我所料，后端是异常的。这样就排除
一、前言近期我们接到一个需求，Leader如何快速统计当前Nginx环境下所有域名，需求如下：1、只统计conf结尾的nginx配置文件，且生效的域名2、统计出来之后根据其域名生效情况进行分类归档，快速判断是否弃用二、脚本实例脚本逻辑剖析：第一部分egrep -r server_name: 首先递归搜索字符串"server_name"的文件内容egrep -v ".bak|[0-9]|*@：在上一
一、前言于2024年7月8号下午16:12分，也就是昨天下午线上业务反馈异常，同一时间，业务也出现了告警，官网访问“502 Bad Gateway”,随后便介入展开排查。附上官网截图二、排查过程看报错反馈，因为我们的负载入口是走的阿里云SLB，后面代理了两台Nginx服务器作为高可用环境，我第一时间登录阿里云负载均衡器检查代理的后端服务器所监听状态，果然不出我所料，SLB后端监听代理的服务器异常此
一、前言业务项目引用kube-ptometheusrelease-0.10，用于监控Kubernetes集群状态，但是该监控项目默认预设了告警规则，但并不能实现告警通知，需要我们结合自己企业内部实际情况来做告警通知机制，本篇带大家了解一下企微告警通知二、实施流程说到企微告警，在过去几年间，常见的方式就是登录企微后台到应用管理，单独新建应用作为监控消息群组，然后通过调用其secret id来实现告警
一、前言在kube-prometheus项目中，默认已内置了我们集群节点资源的监控，在整个集群项目中，我们还需需要监控集群外部的资源，其中就包含了其它服务器节点资源的监控，总不可能再搭建一套传统的Promehtues去针对集群外部的资源监控吧，这显然不是我们想要的二、实施流程关于kube-prometheus监控集群外node节点资源，网上资源并不多，可以说没有，我不知道是不重要是还有没有这种需求
一、前言今天更新一期关于Kubertes Etcd集群的监控，这里我们依然基于Kube-Prometheus监控etcd，话不多说，开整！二、Promehtues监控创建Etcd Service通常来说，我们Endpoints对象是一个动态的IP列表，随着绑定Pod标签的IP变化而变化，但在监控etcd的场景中，etcd不是作为Pod，而是组件，组件的IP都是固定的，因此在指定对应的Service
一、前言近期我们要对项目线上的Java应用进行JVM监控，由于我们的Java程序都部署在Kubernetes集群中，难点就是不能像常规传统的方式对其监控，这里我们采用Grafana+Prometheus的方式去实时监控Java应用的JVM数据，那么中间就缺少不了jmx_exporter。接下来就开始实战，全程干货！二、实践流程2.1、封装jvm-exporter以及JXM监控指标我们采集java监
一、前言随着互联网技术不断迭代更新，我们传统的监控手段已无法满足现有需求，提起监控利器，大家都会想到Promehtues，没错，他的确是企业授权首选的方案，尤其是结合Kubernetes容器编排业务场景，堪称最佳搭档。可尽管如此，这款开源技术通过传统的手段去实现落地并不是一件简单的事情。现如今，Kubernetes为了更好的与Promehtues相结合，引用Kube-Promehesu实现高效便捷
Copyright © 2005-2025 51CTO.COM 版权所有 京ICP证060544号
