xianyuLuo的博客

Prometheus监控数据类型类型特点常用命名常用函数Counter计数器，只增不减*_total *_sum *_countrate：求增长率 topk：Top前N的信息Gauge反映当前状态，可增可减一般不带后缀直接使用指标，表示当前状态 delta：可以获取样本在一段时间返回内的变化情况 predict_linear：数据的变化趋势进行预测Histogram / Summary数据分区间计算 带指标的总和，一般命名为 _sum 带指标

类型简介是否支持CRD资源RestClient提供RestClient客户端，对Kubernetes API执行RESTFUL操作ClientSet对restClient进行了对象分类方式的封装，可以实例化特定资源的客户端不支持DynamicDiscovery...

List-Watch机制List：全量事件Watch：增量事件两者结合可以保证消息的可靠性、实时性、高性能。如果纯使用List也能获取所有事件，但是这会对ApiServer造成很大的压力，也很难满足实时性！K8s每个资源的ResourceVersionk8s的每个资源都会带有resourceVersion字段，数字递增Informerclinet-go中的一个核心工具包，List/Get k8s中的所有ObjectInformer会自己维护一个缓存，以便更快的返回资源信息Inform

背景在工作中经常会有使用k8s部署站点应用，一般会创建两个编排文件：deployment.yaml和svc.yaml，但是有operator概念之后，其实我们可以自定义一个operator来帮忙创建deployment和svc。此篇文章的目的就是通过编写一个自定义的website-operator来实现此功能。只需要提供一个简单的yaml文件，就可以实现需求。样例YAML：apiVersion: website.xianyuluo.com/v1kind: Websitemetadata: n

operator命令定义API/Controllermake generate生成/修改框架自带的 *_types.gomake manifests生成CRD文件make install安装CRD到集群镜像构建make docker-build IMG=xianyuluo/website-operator:v1.0.0构建镜像make docker-push IMG=xianyuluo/website-operator:v1.0.0推送镜像部署Opera

kubernetes原地升级实现原理在介绍原地升级实现原理之前，我们先来看一些原地升级功能所依赖的原生 Kubernetes 功能：技术背景背景 1：Kubelet 针对 Pod 容器的版本管理每个 Node 上的 Kubelet，会针对本机上所有 Pod.spec.containers 中的每个 container 计算一个 hash 值，并记录到实际创建的容器中。如果我们修改了 Pod 中某个 container 的 image 字段，kubelet 会发现 container 的 hash

背景由于容器化和微服务的大力发展，Kubernetes基本已经统一了容器管理方案，当我们使用Kubernetes来进行容器化管理的时候，全面监控Kubernetes也就成了我们第一个需要探索的问题。我们需要监控kubernetes的ingress、service、deployment、pod…等等服务，以达到随时掌握Kubernetes集群的内部状况。此文章也是Prometheus监控系列的第三篇，具体描述了在Kubernetes中使用Prometheus来采集业务指标。多数为思想指导，会列出两个例子。

背景由于容器化和微服务的大力发展，Kubernetes基本已经统一了容器管理方案，当我们使用Kubernetes来进行容器化管理的时候，全面监控Kubernetes也就成了我们第一个需要探索的问题。我们需要监控kubernetes的ingress、service、deployment、pod…等等服务，已达到随时掌握Kubernetes集群的内部状况。此文章是Prometheus监控系列的第二篇，基于上一篇讲解了怎么对Kubernetes集群实施Prometheus监控。Prometheus部署在k

背景由于容器化和微服务的大力发展，Kubernetes基本已经统一了容器管理方案，当我们使用Kubernetes来进行容器化管理的时候，全面监控Kubernetes也就成了我们第一个需要探索的问题。我们需要监控kubernetes的ingress、service、deployment、pod…等等服务，已达到随时掌握Kubernetes集群的内部状况。此文章是Prometheus监控系列的第一篇，目的也很明确，旨在于寻找一套能够胜任kubernetes集群监控的架构。k8s监控方案调研 1、cA

Kubernetes API概念所有的资源都可以通过API返回其信息每个 Kubernetes 对象都有一个 resourceVersion 字段，代表该资源在下层数据库中存储的版本。检视资源集合（名字空间作用域或集群作用域）时，服务器返回的响应 中会包含 resourceVersion 值，可用来向服务器发起 watch 请求。 服务器会返回所提供的 resourceVersion 之后发生的所有变更（创建、删除和更新）。 这使得客户端能够取回当前的状态并监视其变更，且不会错过任何变更事件。 客户端

Kubernetes中的HeadlessService前言：最近在基于K8S开发平台的过程中遇到了有个问题没有弄懂，就是CoreDNS的作用，就好像在Docker Swarm里面，我们可以通过Service name来访问一组容器，在K8S里，我们想要通过name来访问服务的方式就是在Deployment上面添加一层Servic，这样我们就可以通过Service name来访问服务了，那其中的原理就是和CoreDNS有关，它将Service name解析成Cluster IP，这样我们访问Cluster

1、在 Pod 中的容器之间共享进程命名空间kubernetes官网链接进程命名空间共享使用 v1.PodSpec 中的 ShareProcessNamespace 字段启用。例如：apiVersion: v1kind: Podmetadata: name: nginxspec: shareProcessNamespace: true containers: - name: nginx image: nginx - name: shell image: bus

Kubernetes和Istio随着微服务的理念不断深入人心，越来越多的公司、开发者尝试把以前的单体服务转向微服务架构，Container容器技术的出现，大大加速的这个过程，容器和微服务简直就是完美结合、天生一对。因为它有效的解决了N多服务快速交付和快速部署的问题。但随着服务数量的越来越多，很多企业能够希望把相关的服务聚合在一起，进行高效的部署和管理，于是乎后面就出现了服务编排概念。在众多服务编排工具中，Kubernetes带着它在Google的沉淀以及先进的思想横空出世，一统容器编排领域，很多都人直接

前言现在不管出现什么新技术、新框架，那有2个问题是大家都绕不开的，包括操作系统在内也绕不开这2个问题，而且是非常基础的问题——网络和存储。回想以下以前学习过的框架，回想以下操作系统原理，是不是都不可能绕开这两点？这两点是所有程序的基础，同时也是Docker要解决的重点问题。今天我们就一起来学习下Docker的网络解决方案。Docker中的网络解决方案在Docker中，网络问题主要有3种解决方案。如下：FlannelWeaveCalico它们的目的无非就是为了解决同一个问题：如何让容器之间

背景kubernetes中的service最开始是利用iptables技术实现，但是后来kubernetes官方抛弃了iptables，改用ipvs来实现service。Iptables问题规则复杂凌乱，排查问题困难基于链表实现，查找复杂度为O(n)，当规则超过2w条时，内核压力巨大，iptbales将会成为瓶颈IPVS特点专注于负载均衡技术，且支持多种调度算法基于哈希查找，复杂度为O(1)个人思考为什么要弃用iptables？Iptables在功能上应该是偏防火墙功能k8s