本文主要介绍了在 KubeGems 中启用并使用Nacos插件作为应用的配置中心的基本管理功能

本文将指导用户使用 Kind 快速部署一个 KubeGems v1.21的版本用于本地测试。

最近我司业务扩展在机房新开了一个区域，折腾了一段时间的 Calico BGP，为了能将整个过程梳理得更简单明了，我还是决定将这个过程记录下来。不管是对当下的总结还是未来重新审视方案都是值得的。大家都知道，云原生下的网络架构在 Kubernetes 里可以算是百花齐放，各有所长，这无形中也导致网络始终是横在广大 K8S 爱好者面前迈向高阶管理的几座大山之一。通常大家在公有云上使用厂家提供的 CNI 组件可能还感受不到其复杂，但一旦要在 IDC 自建集群时，就会面临 Kubernetes 网络架构选型的问题。

前段时间学习群中有朋友在询问线上 Linux 主机的命令行操作审计方案时，当时给了一个用 rsyslog + elasticsearch 的方案简单搪塞过去了，并没有对方案的细节进行说明。要命的是当时立了个 flag 说在下次公众号文章更新中推送，时间一晃快 2 个月过去了，今天终于来把之前的挖的坑给填上。首先，当谈到 Linux 的操作审计需求时，大多数我们希望的是还原线上服务器被人为（误）操作时执行的命令行，以及它关联的上下文。这个需求场景其实跟通用的业务日志采集一致，简单一点可以直接通过 histo

c前文：Logging Operator 的文章去年拖更很久了，原以为不会再有进度，不过最近在自己的KubeGems项目中遇到处理日志可观察性部分的需求时，又重新研究了下它，于是有了本系列的第三篇。Logging Operator是BanzaiCloud下开源的一个云原生场景下的日志采集方案。它在 2020 年 3 月的时候经过重构后的 v3 版本，底层凭借高效的 fluentbit 和插件丰富的 flunetd，Logging Operator几乎已经完美的适配了 kubernetes 模式下的

Certified Kubernetes是CNCF基金会在2018年推出的Kubernetes一致性认证计划。它由CNCF基金会提供的一套诊断测试工具（Sonobuoy）并运行在Kubernetes中。各云厂商如果需要将自己产品纳入到Certified Kubernetes当中，就需要按照操作指导进行自身测试，并将测试结果上传给CNCF社区，当报告审核通过，交付一定的费用（CNCF Members免费）后，就会得到CNCF基金会给企业颁发一个Certified Kubernetes的认证。也就是说得到认证后

Operator Framework是由CoreOS开发，后被RedHat收购的一个开源工具包，它可以有效的、自动化的和可扩展的方式管理 Kubernetes原生应用程序。该框架下包含Operator SDK，可协助开发人员利用自己的专业知识来引导和构建Operator，而无需了解 Kubernetes API复杂性。今天我们就学习它，用于创建一个基于Ansible的Operator应用（之前小白在《Loki Operator简明教程》中也简单聊到过），它可以利用现有 Ansible playbook和模块

曾几何时，我们将自己的应用运行在Kubernetes上，每当出现容器异常崩溃时，我们往往都是一边重启容器，一边面对崩溃的容器无从下手。通常在业务研发自己build的镜像内包含了shell，我们还能通过在command中嵌入一个["sleep", "3600"]命令来阻塞容器内服务启动，不过也有时候会出现不知道从哪里冒出来一个distroless镜像，这时可能最先崩溃的就是运维了。那是一种运维这个职业自诞生以来，第一次感受到手足无措并脱离掌控的无助感。于是在k8s环境下无法debug容器的梗开始在坊间广为吐槽

很多新入坑Loki的小伙伴当看到distributor、ingester、querier以及各种依赖的三方存储时，往往都比较懵逼，不知道从哪儿入手。此外再加上官方的文档里面对于集群部署的粗浅描述，更是让新手们大呼部署太难。其实，除了官方的helm外，藏在Loki仓库的production目录里面有一篇生产环境的集群部署模式。原文里面，社区采用的是docker-compose的方式来快速拉起一套Loki集群。虽然我们正式在生产环境中实施时，不会傻到用docker-compose部署在一个node上（显然这

当我们在看Loki的架构文档时，社区都会宣称Loki是一个可以支持多租户模式下运行的日志系统，但我们再想进一步了解时，它却含蓄的表示Loki开启多租户只需要满足两个条件：配置文件中添加 auth_enabled: true请求头内带上租户信息X-Scope-OrgID这一切似乎都在告诉你，“快来用我吧，这很简单”，事实上当我们真的要在kubernetes中构建一个多租户的日志系统时，我们需要考虑的远不止于此。通常当我们在面对一个多租户的日志系统架构时，出于对日志存储的考虑，我们一般会有两种模式来

Logging Operator是BanzaiCloud下开源的一个云原生场景下的日志采集方案。之前小白转载过崔大佬介绍的一篇文章，不过由于之前一直认为在单个k8s集群下同时管理Fluent bit和Fluentd两个服务在架构上比较臃肿，便留下了一个不适用的初步印象。后来小白在一个在多租户场景下对k8s集群的日志管理做方案时，发现将日志配置统一管理的传统方式灵活性非常的弱。通常操作者会站在一个全局的角度，尽量的让日志的配置做成模版来适配业务，久而久之模版就变得非常庞大且臃肿，对后续维护和接任者都带来了不小

说到绘制产品原型图的工具，大家一定首先先到的是大名鼎鼎的“Axure RP”，或者在线协同的“墨刀”。它们的功能确实非常的强大，以至于很多产品经理可以做出还原度非常高的产品原型，不过能够熟练的够驾驭它们，还需使用者有不少的磨练。对于小型的团队（3-5人），特别是在没有专业的产品经理的情况下，大部分我们在接到产品的需求时，我们需要借助一个简单的、快速的工具将需求体现在产品上。这也是今天小白要介绍的一个轻量级产品原型设计工具Balsamiq Mockups。简单来说，Balsamiq Mockups是一个用

最近遇到一个有趣的场景，当业务方有一个只运行异步任务的容器，这意味着它逻辑简单，即从上游服务中获取内容进行数据处理，但应用本身不提供任何方式判断当前服务状态。当服务运行出现阻塞时，我们该如何在Kubernetes中来实现探针管理呢？很多同学都使用过存活探针、就绪探针和启动探针，不过它们有一个共同的属性就是需要应用本身提供一个Http/TCP接口或一个Command来评估服务当前是否健康。在不具备上述条件的情况下，我们就只能通过捕获容器的控制台日志输出来判断容器运行是否健康了不要问我业务应用阻塞的原因，.

在Kubernetes API的众多对象中，Events算是最容易被我们忽视的类型之一。与其他对象相比，Event的活动量很大，不太可能长时间存储在etcd中，默认情况下，Event留存时间也只有1小时。当我们使用kubectl describe获取一个对象时，可能因时间超限而无法获取它的历史事件，这对集群的使用者非常的不友好。除了能查看集群事件外，我们可能还有类似追踪一些特定的Warning事件（如Pod生命周期、副本集或worker节点状态）来进行相关告警的需求。那么在开启本期话题之前，我们先来理解下

一直以来，小白在Kubernetes集群中测试Loki的日志采集都是在容器内执行echo命令输出到控制台。这种方式操作起来既不方便无法大规模做日志测试。直到小白遇到一个好用的日志输出小工具flog。flog是一个golang开发的测试日志生成器，它可以生成一些常见（如Apache、Nginx、RFC3164或Json）格式的日志在Mac下用homebrew可以直接安装brew tap mingrammer/flogbrew install flog或者直接用docker来运行docker ru

前段时间在Loki2.0发布时，更新了一个配套的用LogQL语法绘制Nginx监控面板的Demo。今天小白准备用同样的手法炮制一个基于Traefik日志的监控面板。还不清楚之前Nginx面板操作的同学可以看参考文末后的推荐阅读。TraefikTraefik是一个用Golang实现的云原生轻量级HTTP反向代理工具。由于它支持配置适配多种后端服务（docker，kubernetes，Mesos，redis）来做动态的路由配置。当前Rancher的边缘产品K3S也默认把Traefik作为默认的Ingress

自从Loki2.0发布以来，LogQL v2凭借丰富的查询功能，让Loki也逐渐具备日志分析的能力。对于有些时候，当研发的同学没有提供Metrics时，我们也能利用LogQL构建基于日志的相关指标，这里面就主要用到了聚合查询。常见操作熟悉PromQL的同学应该知道，常见的聚合查询包括sum、rate，count等等。那么在Loki中，也有两种常见类型的聚合操作第一种类型，将日志条目作为一个整体来计算数值支持的操作功能有：rate(log-range)：计算每秒的日志条目数count_over_

在之前的Loki操作方法系列中，我已经分享了创建快速过滤器查询的所有最佳技巧，这些查询可以在几秒钟内过滤掉TB级的数据。在本期中，我将介绍如何在Loki的LogQL中正确转义字符串中的特殊字符。在编写LogQL查询时，可能已经意识到，我们必须在多个地方编写用双引号分隔的字符串。对于标签匹配器，行过滤器，正则表达式和标签过滤器来说，这是没问题的，我们也在很多地方都使用双引号字符串。但是，当我们突然想要过滤包含双引号的行时，就会出现问题。例如，下面这条查询语句{namespace="loki-ops",

LogQL在很大程度上受Prometheus的PromQL启发。但是，当涉及到在过滤海量日志时，我们就像面临在大海捞针一样复杂。LogQL是Loki特有的语句，在本文中，我们将提供LogQL的快速过滤器查询技巧，这些查询可以在几秒钟内过滤掉数TB的数据。在Loki中，我们可以使用三种类型的过滤器：[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Label matchersLabel matchers（标签匹配器）是你的第一道防线，是大幅减少你搜索的日志数量（例如，从1.

相信大家在2020年岁末都被Kubernetes即将抛弃Docker的消息刷屏了。事实上作为接替Docker运行时的Containerd在早在Kubernetes1.7时就能直接与Kubelet集成使用，只是大部分时候我们因熟悉Docker，在部署集群时采用了默认的dockershim。不过社区也说了，在1.20之后的版本的kubelet会放弃对dockershim部分的支持。作为普通小白，我们在更换Containerd后，以往的一些习惯和配置也不得不改变和适配。那么本篇也是最近小白逐渐替换Conta.

Loki在分布式部署的模式下，保存Ingester服务的状态主要有3个渠道，分别是etcd、consul和基于gossip协议的memberlist。不管Loki用的是什么方式，它们最终都是将哈希环以KV的方式保存。再聊Loki之前，先来了解下一致性哈希的基本概念。一致性哈希是在1997年由麻省理工学院提出的一种分布式哈希（DHT）实现算法。相较于普通的哈希算法，一致性哈希除了继承数据的离散性、扩展性和容错性之外，还引入了虚拟节点的概念，极大的优化了数据在存储过程的中出现的倾斜问题。另外，遇到需要在不中.

最近无意间发现Grafana官网的Dashboard页面首推了一个用Loki分析Nginx日志的页面，大体也就是Loki2.0后产品主推的LogQL V2语法的典型应用。也许是最近感受到大家愈发对新语法的不熟悉，社区也特地做了一个quick demo来简单说明其新语法的使用。在视频里，我们看到基于LogQL V2语法为Nginx日志分析提供了一个新的思路。这个demo我们可以通过官网的Dashboard中找到。不过今天小白想写的是如何在Ingress-Nginx中也能用上如视频般丝滑的界面。1. Ing

Loki中拥有这众多的limit策略，有的已经开放到配置文件中，还有的配置代码中已经实现但还没开放出来。大部分情况下开发者给了出一些默认参数足够优秀，不过有的时候我们也不免需要微调。那么小白这次先简单捡几个比较重要的策略来说明下Limits_Config中到底限制了什么。1. 限流器小白前段时间无意间重启升级了下Loki的服务，由于过程持续了一段时间，当服务恢复时客户端在push日志时总是会收到如下的报错，429 Too Many Requests Ingestion rate limit exc.

最近群里有小伙伴有说到自己的日志存储路径先是从客户端到Kafka，再通过消费kafka到ElasticSearch。现在要将ES换成Loki面临需要同时支持Kafka和Loki插件的工具。小白查了下当前市面上满足需求且足够可靠的工具分别为Fluentd、Logstash以及Vector。FluentdCNCF已毕业的云原生日志采集客户端。与kubernetes结合比较精密，插件丰富且有大厂背书。不足之处在于受ruby限制，在日志量大（建议使用FluentBit）时本身的资源消耗不小。Logst.

小白在Grafana Dashboard中发现居然没有现成的Loki2.0版本监控，无奈只有自己来造个轮子????先来看下截图吧：面板版本基本信息：Grafana v7.3.1Loki2.0.0依赖的服务Cassandra （Index）S3 （Chunk）Redis（Cache）如果没有以上依赖的同学可能Dashboard里面部分存在无数据Loki部署部分可以参考我的demo,里面有loki集群的部署和依赖服务的配置https://github.com/CloudX

自从Kubernetes1.11之后，CoreDNS作为集群内默认的域名解析服务，你是否对它还仅仅还停留在对Kubernetes的Service解析呢？事实上光DNS在K8S内就有很多有意思的操作，今天我们不妨来看看CoreDNS的各种高阶玩法。1. 自定义hosts解析默认情况下，Kubernetes集群内的容器要解析外部域名时，CoreDNS会将请求转发给/etc/resolv.conf文件里指定的上游DNS服务器。这个是由这个配置决定的。forward . /etc/resolv.conf有

小白前段时间做Loki分布式追踪时，遇到需要在Nginx这一层生成TraceID和打印traceid相关日志的需求，在网上找了一大圈恁是没找到合适的Docker镜像。原本应该用opentracing-contrib编译的nginx-opentracing的docker镜像，但是当pull镜像时居然发现它有1.5G的容量，看了Dockerfile才知道这个镜像把Nginx源码和所有编译所需的C库都放在里面，真是佩服。最后还是得我们自己根据OpenTracing的方法给Nginx安装插件。按照阿里云的文档.

Tempo是Grafana Labs在ObservabilityCON 2020大会上新开源的一个用于做分布式式追踪的后端服务。它和Cortex、Loki一样，Tempo也是一个兼备高扩展和低成本效应的系统。之前小白有提到Grafana Labs的云原生Observability宇宙只剩下trace部分，那么今天就拿Loki的分布式追踪来体验下这Observability的最后一环吧。关于TempoTempo本质上来说还是一个存储系统，它兼容一些开源的trace协议（包含Jaeger、Zipkin和O.

就在10月27日，Loki迎来至1.0版本以来的重要更新! 原以为这次Release会是1.7，没想到直接跳到2.0，看来Loki的应用和成熟度都有不少的提升，那么就看下本次重大更新包含哪些内容。1. LogQL语法大增强本次LogQL已经将原先的filter expression更换为log pipeline，进一步增强了日志查询期间的管道功能，新的log pipeline包含了几大表达器。Line Filter Expression(行过滤表达式)原先filter expression大部分功.

Dagger是一个基于Loki的日志查询和管理系统，它是从我们的云平台内派生出来的一个项目。dagger运行在Loki前端，当前具备日志查询、搜索、保存和下载等特性，适用于云原生场景下的容器日志管理场景，更多的功能我们会在后面持续开放。之前小白分享过许多关于Loki的文章，有的同学可能会问了Grafana的Explore也可以接Loki查看日志啊，为什么还要自己在搞个Dagger。Grafana的确非常不错，对于查询方面它非常的高效且炫酷，刚开始小白也是直接将Grafana丢给研发的同学自己使用，不过也

受PromQL的启发，Loki也有自己的LogQL查询语句。根据官方的说法，它就像一个分布式的grep日志聚合查看器。和PromeQL一样，LogQL也是使用标签和运算符进行过滤，它主要分为两个部分：log stream selector （日志流选择器）filter expression （过滤器表达式）我们用这两部分就可以在Loki中组合出我们想要的功能，通常情况下我们可以拿来做如下功能根据日志流选择器查看日志内容通过过滤规则在日志流中计算相关的度量指标log stre

Krew是kubectl插件的软件包管理器，简单来说它就像apt、dnf或者brew一样，通过krew你可以方便的管理机器上kubectl的插件。小白在这里根据日常工作给大家推荐一个效率的krew插件，带有一定的主观性，大家自行选择。kubectl别名这个并不是krew插件，不过我们可以利用alias将常见的kubectl组合命令精简成简单的别名。GitHub上有个kubectl-aliases项目，上面有很多精简的别名，虽然可以通过tab命令补全，不过能记住它们并不是容易的事。小白简单提取一部分，将.

小白之前有通过Grafana设置Loki数据源的骚操作来做日志告警，虽然能直接在Grafana面板上配置告警，当它们还是没办法集中维护和管理。小白前面介绍了那么多关于Loki的文章，那么它有没有像Promethues一样的rules来管理策略呢？答案是肯定的！根据Loki的RoadMap，Ruler组件将于Loki 1.7.0版本正式推出。那么小白今天先带大家尝尝鲜，体验下在Loki里日志告警的正确姿势。Loki RulerLoki1.7将包含一个名为Ruler的组件，它是从Crotex项目里面引入.

小白之前用Ceph S3在为Harbor的Registry做后端存储时，不管是在1.x还是最新的2.1版本都会遇到docker push较大块镜像时不断重试的情况。按照以往的经验，小白只能将Ceph的S3改为兼容Swift协议才能成功push镜像。不过最近有了新的解决方案，引起该问题的似乎跟registry服务的配置multipartcopythresholdsize有关https://github.com/goharbor/harbor/issues/12317harbor-helm里面关于

本文参考《Loki label best practice》，并结合小白实际的工作经验总结而来，不对的地方还请海涵。1. 尽量使用静态标签使用静态标签可以在日志时的开销更小。通常日志在发送到Loki之前，在注入label时，常见的推荐静态标签包含：物理机：kubernetes/hosts应用名：kubernetes/labels/app_kubernetes_io/name组件名：kubernetes/labels/name命名空间：kubernetes/namespace其他kube..

相信大家看过《听说，你的Loki还是单体?(上篇)》之后对Loki的分布式架构有了一定的认识，那么本篇主要就是对上篇内容的实践。小白主要提供docker-compose和helm两种方式将部署Loki集群的Demo版本。在正式部署之前，我们还是先来看下Loki整体架构如下图：我们本次部署清单里面主要涉及到的组件如下：组件副本数说明Cassandra1Loki Index存储Minio1Loki S3存储Consul1Loki 组件状态和哈希环存储.

很多时候我们把Loki部署成一个单体应用，这样能够让我们快速的将它在开发、测试环境中应用起来。不过最终大家都还是逃不过真香定律，这个时候大家就在琢磨运维的灵魂三问了，这东西怎么部署到生产环境？高可用稳定吗？分布式怎么样？今天小白起个引子， 在Loki分布式部署上面给大家带来思考。Loki主要组件在分布式部署之前，小白还是有必要简单介绍下Loki的几个核心组件。DistributorDistributor是Loki日志写入的最前端，当它收到日志时会验证其正确性，之后会将日志切成块（chunk）后.

正文共： 1969字预计阅读时间： 5分钟前段时间小白发了很多关于Loki的实践分享，有同学就问了，我该如何把现在运行在kubernetes上的容器日志接入到Loki里面呢？那么今天小白在这里就主要跟大家分享下loki跟fluentd结合的一些实践。为什么是FluentdFluentd是一个由云原生基金会(CNCF)管理的统一日志层数据收集器。它可以从多种数据源里采集、处理日志，并集中将它们存储到文件或者数据库当中。其主要的目的也是让你的基础设施能够实现统一的数据收集和分发，以便业务可以更好的..

缓存在当下已被广泛的应用到大型业务系统当中 合理的使用缓存可有效加快应用速度、提升应用的可扩展性和降低对后端数据的性能依赖。那么对于Loki来说，它支持哪些缓存以及缓存的作用范围呢？小白今天带大家简单过下Loki中关于缓存的应用缓存类型cache_config是Loki的缓存配置区块，当前Loki 1.6支持的缓存主要是in-memory、memcached和redis。这三种缓存类型各有自己的场景需求，如果你的Loki是AllinOne部署话，三选一都可以。如果你的Loki是分布式的架构，那么可以选.

用了Loki的同学都知道，日志存储在Loki里主要分为两部分，日志原始文件以及日志索引。按照Loki数据的设计思路，日志原始文件可以存放在任何文件系统中，可以是filesystem，对象存储等。而日志的索引则专门存储到索引服务当中，这里面包含Loki内置的BoltDB当中。其数据存储主要的思想也是让对象存储负责廉价地存储压缩日志，而索引则负责以快速，有效的查询方式存储这些标签。当前Loki1.6版本支持的数据存储如下：Chunks 日志原始文件CassandraGCSFile System