Kubernetes

Kubernetes监控架构设计 k8s监控设计背景说明 根据 Kubernetes监控架构 1，Kubernetes 集群中的 metrcis 可以分为 系统指标 (Core Metrics) 和 服务指标 (service metrics) ; 系统指标(System metrics) 是通用的指标，通常可以从每一个被监控的实体中获得（例如，容器和节点的CPU和内存使用情况）。服务指标(Service metrics) 是在应用程序代码中显式定义并暴露的 (例如，API Server 处理的 500 错误数量)。 Kubernetes将系统指标分为两部分： 核心指标 (core metrics) 是 Kubernetes 理解和用于其内部组件和核心工具操作的指标，例如：用于调度的指标 (包括资源估算算法的输入, 初始资源/VPA (vertical autoscaling)，集群自动扩缩 (cluster autoscaling)，水平Pod自动扩缩 (horizontal pod autoscaling ) 除自定义指标之外的指标)；Kube Dashboard 使用的指标，以及 “kubectl top” 命令使用的指标。 非核心指标 (non-core metrics) 是指不被 Kubernetes 解释的指标。我们一般假设这些指标包含核心指标 (但不一定是 Kubernetes 可理解的格式)，以及其他额外的指标。 所以，kubernetes monitoring 的架构被设计拥有如下特点： 通过标准的主 API (当前为主监控 API) 提供关于Node, Pod 和容器的核心系统指标，使得核心 Kubernetes 功能不依赖于非核心组件 kubelet 只导出有限的指标集，即核心 Kubernetes 组件正常运行所需的指标。 … 监控管道 Kubernetes 监控管道分为两个：...

工具命令集合 长期总结 - Linux日志查询命令 长期总结 - Linux网络命令合集 长期总结 - Linux性能分析命令 awk常用案例 bash shell常用示例 探索kubectl - 巧用jsonpath提取有用数据 探索kubectl - kubectl诊断命令集合 Pod 检查 Pod 就绪探针 bash 1 kubectl get pods <pod-name> -n <namespace> -o jsonpath='{.status.conditions[?(@.type=="Ready")].status}' 查看 Pod 事件 bash 1 kubectl get events -n <namespace> --field-selector involvedObject.name=<pod-name> 获取 Pod Affinity 和 Anti-Affinity bash 1 kubectl get pod <pod-name> -n <namespace> -o=jsonpath='{.spec.affinity}' 列出 Pod 的 anti-affinity 规则 bash 1 kubectl get pod <pod-name> -n <namespace> -o=jsonpath='{....

本文将介绍 Harbor 从 v1.10.7 升级到 v2.10.0，以及如何将 Harbor 从 v2.10 回滚到 v1.10.7。 升级条件 Linux服务器 4 个 CPU 和 8 GB 内存（强要求），100G可用空间（跨多版本时存放备份文件以及镜像文件，这部分要求） Docker-compose > 1.19.0+ 备份现有的 Harbor /data/database 目录 本次升级主要是使用了 harbor 内置的数据库，所以升级步骤比较容易。 官方升级路线 harbor 的升级，是不能跨很多版本进行升级，官方对此有详细说明 [1] ，可以看到路线为： 1.10.0 [1] => 2.4.0 [2] => 2.6.0 [3] => 2.8.0 [4] => 2.10.0 [5] 模拟升级步骤 github release 页下载对应的安装包 解压 bash 1 2 # 命令主要为将harbor压缩包内文件解压到指定目录中，由于 harbor 解压后文件名无论版本如何都为“harbor” $ mkdir ./harbor-v1.10 && tar -xf harbor-offline-installer-v1.10.0.tgz -C ./harbor-v1.10 --strip-components 1 备份默认的配置文件（仅限于 v1....

tls 证书在 k8s 集群上大量使用的话，当到期时会存在批量替换的难度，比如说每个名称空间，多个业务的使用，在这篇博文中，将尝试批量替换整个集群的证书（前提，在没有使用 vault, cert-manager这类组件的集群之上）。 基本操作 步骤1：首先不知道有多少个名称空间使用了这个证书，所以需要遍历所有的名称空间，这里使用 kubectl 的 json path 实现 bash 1 $ kubectl get ns -o jsonpath='{range $.items[*]}{.metadata.name}{"\n"}{end}' 步骤2：拿到名称空间的名字后，就需要循环这个名称空间下所有的 secret bash 1 2 3 4 for ns in `kubectl get ns -o jsonpath='{range $.items[*]}{.metadata.name}{"\n"}{end}'` do kubectl get secret -n $ns -o jsonpath='{range $.items[*]}{.metadata.name}{"\n"}{end}' done 步骤3：找到与这个匹配的证书进行替换 把步骤3拆解为下面几个步骤： 拿去到符合要求的secret的名字 匹配名称是否为修改的secret 做替换操作 由于步骤2使用的是 jsonpath 拿到的 secret name，由于 kubectl 并不支持高级jsonpath语法，官方推荐使用jq，那么使用jq获取名字 bash 1 kubectl get secret -n $ns -o json|jq -r ....

什么是jsonnet jsonnet是用于app或开发工具的数据模板语言，主要用于json的扩展，具有下面功能： 生成配置数据 无副作用 组织化，简化，统一化 管理无序的配置 jsonnet可以通过面向对象消除重复。或者，使用函数。与现有/自定义应用程序集成。生成 JSON、YAML、INI 和其他格式。 安装jsonnet Jsonnet 有两种实现（C++ 和 Go） 在 Debian/Ubuntu 之上，可以直接使用 apt 源来安装 bash 1 apt install jsonnet -y 安装 go 实现的，可以用下面命令，前提是安装了go bash 1 go get github.com/google/go-jsonnet/cmd/jsonnet 什么是jsonnet-bundler jsonnet-bundler 是 Jsonnet 的包管理器，用于个简化 jsonnet 项目中依赖关系管理的工具。使用 Jsonnet Bundler 可以带来下面便利之处： 使用 jsonnetfile.json 作为依赖关系管理 自动安装和更新依赖项。 版本选择，使用 jsonnetfile.json 可以确保项目使用正确版本的依赖。 可重复构建， 使用 jsonnetfile.json 管理的项目可以在不同环境中构建并确保结果的一致性。 更方便的与 GitOps 结合， Jsonnet Bundler 提供 与 GitOps 的集成。 jsonnet-bundler 安装 Jsonnet Bundler 有两种安装模式，实际上就是 Go 程序通用的安装方式：...