今天在排查集群一个问题时,发现相关的pod的状态为UnexpectedAdmissionError
,在这之前从未没遇到过pod还有这种状态的,一脸好奇,在解决问题的过程中,发现越挖越深, 里面涉及到的信息也是相当的多,特此记录一下.
再见2021,2022再见
Opentelemetry调研实践四(k8s中golang应用接入opentelemetry实现可观测性)
历史文章:
整个opentelemetry体系还是相当复杂的,这里没办法将所有opentelemetry的东西讲清楚,直接通过case顺带opentelemetry里的概念来拆解会比较直观
这里通过一个简单的golang demo来介绍怎么接入opentelemetry以实现Metrics跟Trace的传递
Opentelemetry调研实践三(全链路追踪的TraceID与SpanID)
历史文章:
在opentelemetry架构及名词介绍 中就引出了一个问题: 无论在数据平面如何做流量劫持,如何透传信息,以及如何生成或者继承Span,入口流量和出口流量之间的链路都存在无法串联的问题, 这个问题要解决还是需服务来埋点透传,将链路信息透传到下一次请求当中去
Opentelemetry调研实践二(opentelemetry架构及名词介绍)
历史文章:
上文简单说了下可观测性,然后引出了主角: opentelemetry
可观测性一个很重要的领域Trace
有两个业界标杆: 一个是OpenTracing,另一个OpenCensus,OpenTracing其实是一个规范,jeager就是基于opentracing实现的开源工具,而OpenCensus则是由google开源的度量工具,简单来说,这两者在可观测性领域功能高度重合,因此,在CNCF主导下进行了合并形成opentelemetry项目,OpenTracing跟penCensus共同推进opentelemetry,两者的官网也赫赫表达基本不再维护,同时opentelemetry也致力于trace、logging、metrics间的关联性.
Opentelemetry调研实践一(可观测性到底在说什么)
可观测性(Observability)并不是一个新词,而在几十年前被广泛地用于控制理论,用它来描述和理解⾃我调节系统。随着容器技术、微服务、⽆服务器迅速流行,使得系统间的访问越来越复杂,在云上、本地或两者上可能会运⾏数千个进程, 使用传统的监控技术和⼯具很难跟踪这些分布式架构中的通信路径和相互依赖关系。系统内部的可见性就变得非常重要。
那可观测性到底在说什么呢?
Kubernetes学习(又是bridge-nf-call-iptables惹的祸)
使用kubernetes遇到最多的70%问题都可以归于网络问题,最近发现如果内核参数: bridge-nf-call-iptables
设置不当的话会影响kubernetes中Node节点上的Pod通过ClusterIP去访问同Node上的其它pod时会有超时现象,复盘记录一下排查的前因后因.
Kubernetes学习(hostPort劫持了我的请求)
最近排查了一个kubernetes中使用了hostport后遇到比较坑的问题,奇怪的知识又增加了.
Kubernetes学习(为什么Pod突然就不见了?)
最近发生一件很诡异的事情, 某个ns下的pods会莫名其妙地被删了, 困扰了好一阵子,排查后发现问题的起因还是挺有意思。
Kube-batch学习(nodeorder插件使用)
AI场景跟大多数的业务不太一样的是: 网络端需要尽可能地靠近,对于大多数业务来说,为了保证其可用性,一般副本都会分散地部署在不同node,而AI业务通常伴随着海量的数据交换,一个job中的多个pod需要协同处理,如果分散在多个node上,task间的任务交换的快慢就得依赖于网络的传输的快慢,而如果是在一台node上的话,那就没有这部分的消耗,一个job中的pods如何做到尽可能地调度在同一台机器上呢, kube-batch除了能够支持poggroup外,也是能够支持的podaffinit的.