Z.S.K.'s Records

在使用gitlab做ci/cd发布时，变量是无法避免的话题，这次来聊一聊gitlab中各类级别的变量

在很多的一段时间内, 业务一直都是使用单独的prometheus进行集群业务的监控,通过prometheus提供的服务发现能力, 在业务svc加入指定的annotations即可实现数据收集, 但还是会面临时常需要修改prometheus的配置文件(比如static scrape)，prometheus虽然也提供了配置热加载的能力, 久而久之也烦,如果能够实现配置的动态加载, 对运维人员无感操作, 是不是就方便地多, prometheus operator即可实现.

对于平台来说， 上面跑着若干产品线，prometheus operator能够将更多的自由度移位到业务侧, 比如抓取时间，超时时间等，同时也使得平台运维同事的工作量能够解脱出来.

最近kubernetes新上线了个服务,需要基于Kubernetes架构下压测一下该服务的性能, 之前用过ab, 但是ab还是相对简单了点, 网上调研了一番发现了jmeter这个由apache出品的压测工具,特别是报告非常清晰, 使用起来还挺简单.

虽然现业务架构上了kubernetes，因为历史遗留问题, 现在还存在着使用consul来做service discovery组件, 预计还得在生产中存在一段时间, 因此配上了Prometheus监控, 在部署过程中出现了一个Unsupported Media Type错

今天同事接到一个需求, 需求是这样的: 需要对接友商的系统(域名, 公网能够解析),但是友商系统有个白名单, 只有在白名单中的ip才能有权限访问, 这个ip应该是什么?

补充一下架构背景： 应用都是部署在kubernetes集群中的， kubernetes部署在阿里云ECS上. CNI使用的flannel

这么长时间跟kubernetes打交道, 还真没想过这个问题, 刚好可以测试一翻, 探探究竟

期间会涉及到CNI(container network interface)相关的话题,在这里不会做深入研究, 一笔带过.详细的学习记录在这里可以找到Kubernetes学习(flannel深入学习)

经过之前的对Istio的学习，大致明白了istio的机制,而要体会istio对流量的神奇魔法,自然离不开 virtualservice 与 destinationrule这两个对象了.

一直想把istio引入到业务中, 前期调研实操中发现istio完美解决了grpc在kubernetes中的负载均衡问题, 这次学习一下opentracing在istio中的应用, 这里主要是想看grpc-gateway的调用，目前业务中用的最多, 当然tcp就更没问题.

最近有个同事说他在测试kubernetes中跑spark，在运行spark-job时提示Invalid DER: object is not integer，但是如果在线上环境跑同样的任务就没问题, 束手无措，想让我帮看一下什么问题

业务中要在kubernetes中接入grpc， 之前写过一篇文章测试过grpc服务在kubernetes中由于http/2长连接的特性无法达到负载均衡效果, 上次使用的是直接在业务中引用kubernetes的list/watch机制，这次使用istio，同样可以实现grpc的负载均衡.

Gateway在istio中是一个比较重要的对象, 一般用于管理南北流量，即集群外向集群内的访问及集群内需要访问集群外的这部分流量.