linux kernel 4.8以上内核NR_KERNEL_STACK的改变

1. NR_KERNEL_STACK是干什么用的?

通过下面的命令,我们可以查看内核栈的数量:

这个值在内核中的宏为:NR_KERNEL_STACK,表示当前内核中有多少个内核栈。

我们使用这个数字来监控K8S节点上使用PID的数量,以避免PID被耗尽。

2. 那么PID与内核栈有什么关系呢?

在linux系统中,每个进程、子进程和线程在运行时都会有一个PID。这些进程或线程在运行时,因为CPU需要进行任务切换,在任务切换时就需要上下文交换,在上下文交换时就需要把当前进程的上下文压到内核栈内去,以便下次再运行时取出继续执行。

所以可以确定:每个进程、子进程和线程都会有一个内核栈。内核栈的数量与PID的数量大致相当。

注:基于linux内核的线程,比如java的线程与linux的线程是一一对应的,nodejs只使用了linux的进程,线程模型是其自己实现的,golang最特别,使用了多进程,每个进程上有多线程(基于内核),线程上还是自己实现的协程或者说goroute(可以理解为自己实现的线程)

继续阅读

PVC在K8S集群迁移或恢复需注意地方

目前在做同城双活,每个机房都有一个k8s集群,其中一些共享卷需要做到双活的2个集群上都可用。

比如我们现在在主机房的集群上有一个PVC:

以及对应的PV:

继续阅读

k8s源码分析:kube-apiserver –admission-control及–enable-admission-plugins –disable-admission-plugins参数差异

kubernetes源码分支:1.18

先说结论,kube-apiserver启动时:

  1. –admission-control参数带的插件将是apiserver启动的插件,不包括默认插件
  2. –admission-control和–enable-admission-plugins –disable-admission-plugins不能同时使用
  3. –enable-admission-plugins参数不需要按加载顺序填写
  4. 不使用–admission-control参数时,api server会同时启动默认插件
  5. –enable-admission-plugins参数启用时,api server会同时启动默认插件,除非使用了–disable-admission-plugins显示的关闭某个插件
  6. –enable-admission-plugins和–disable-admission-plugins如果同时填写了某一个插件,这个插件将会被加载

继续阅读

istio 1.6新特性:istio自身灰度发布功能测试

1. istio 1.6灰度功能测试

istio 1.6新增了istio自身的灰度测试特性,我先测试其灰度功能。

在官网下载并解压istio 1.6,并把istioctl复制到对应目录:

继续阅读

istio 1.5版本升级

之前测试的istio是1.5.1,现在升级到1.5.2。可以参考之前的istio定制安装的文章。http://www.huilog.com/?p=1299

  • 下载新版本,并准备好之前安装时的配置文件

  • 查看支持的版本列表,验证 istoctl 命令是否支持从当前版本升级

继续阅读

istio-init容器Init:CrashLoopBackOff故障解决

最近在测试istio时,经常发现注入过sidecar的pod过段时间就变成了Init:CrashLoopBackOff状态。如:

我的kubernetes版本为1.14.10,istio版本为:1.5.1
查看istio-init容器的日志,发现有如下的报错:

继续阅读

istio 1.5 定制安装

在istio 1.5,已经不支持helm方式安装,因为helm已经弃用。helm部分的代码已不在更新。只支持istioctl的方式安装istio。

istioctl在安装包内,可通过下面的链接下载安装包。
https://istio.io/docs/setup/getting-started/#download

安装包解压后,直接将istioctl复制到执行目录就可以用了:
cp bin/istioctl /usr/local/bin/

以下命令可以默认配置安装istio:
istioctl manifest apply

如果想安装demo:
istioctl manifest apply --set profile=demo

但是默认配置有些部件是没有选中的。参考下图:

继续阅读

Api Gateway和服务网格的对比

在服务网络出来之前,就已经有很多各式各样的Api Gateway了。他们之间有什么不同呢?

1. Api Gateway架构

Api Gateway有很多,现阶段做的比较好的有ambassador和kong。还有一些其它的,目前看来这两个用的人比较多。
– Ambassador架构:

  • Kong架构:

从流量转发的角度来看,Api Gateway主要做的事是外部到内部的流量转发,也就是通常所说的南北流量。基于kubernetes的架构内来说,其主要是实现ingress的功能。

应用内部之间的流量(东西流量)并不是它关注的重点,虽然部分上也可以实现,但是相关功能并不多。

2. API Gateway解决了什么问题?

API Gateway主要是解决了API管理的问题。

根据Wikipedia的定义:API管理的过程包括创建和发布Web API、执行调用策略、访问控制、订阅管理、收集和分析调用统计以及报告性能。

根据以上定义,API Gateway主要的功能如下:
– api的创建和发布,比如说api的自动注册
– 访问控制和调用策略(流控等),谁能访问?API被调用时,怎么确保安全和稳定的访问?
– 订阅管理,哪些人可以访问我的API
– 调用性能分析及信息收集等

继续阅读

traefik 重写配置

traefik ingress同样可以配置URL的重写:

  • traefik 1.x配置方法

下面是一个完整例子:

参考文档:
https://s0docs0traefik0io.icopy.site/v1.7/basics/#path-matcher-usage-guidelines

https://docs.traefik.io/v1.7/basics/#rules-order

继续阅读

使用prometheus监控k8s集群

1. Prometheus 简介

以下是网上看到的简介:

Prometheus 是一套开源的系统监控报警框架。它启发于 Google 的 borgmon 监控系统,由工作在 SoundCloud 的 google 前员工在 2012 年创建,作为社区开源项目进行开发,并于 2015 年正式发布。2016 年,Prometheus 正式加入 Cloud Native Computing Foundation,成为受欢迎度仅次于 Kubernetes 的项目。

作为新一代的监控框架,Prometheus 具有以下特点:

  • 强大的多维度数据模型:
  • 时间序列数据通过 metric 名和键值对来区分。
  • 所有的 metrics 都可以设置任意的多维标签。
  • 数据模型更随意,不需要刻意设置为以点分隔的字符串。
  • 可以对数据模型进行聚合,切割和切片操作。
  • 支持双精度浮点类型,标签可以设为全 unicode。
  • 灵活而强大的查询语句(PromQL):在同一个查询语句,可以对多个 metrics 进行乘法、加法、连接、取分数位等操作。
  • 易于管理: Prometheus server 是一个单独的二进制文件,可直接在本地工作,不依赖于分布式存储。
  • 高效:平均每个采样点仅占 3.5 bytes,且一个 Prometheus server 可以处理数百万的 metrics。
  • 使用 pull 模式采集时间序列数据,这样不仅有利于本机测试而且可以避免有问题的服务器推送坏的 metrics。
  • 可以采用 push gateway 的方式把时间序列数据推送至 Prometheus server 端。
  • 可以通过服务发现或者静态配置去获取监控的 targets。
  • 有多种可视化图形界面。
  • 易于伸缩。
    需要指出的是,由于数据采集可能会有丢失,所以 Prometheus 不适用对采集数据要 100% 准确的情形。但如果用于记录时间序列数据,Prometheus 具有很大的查询优势,此外,Prometheus 适用于微服务的体系架构。

继续阅读