Kubernetes

今日在部署旧版本 k8s 集群 (1.16.10) 时出现错误，主要是在新版本操作系统上部署老版本 k8s，kubelet会出现如下错误 bash 1 2 W1123 22:31:47.383423 3686 server.go:605] failed to get the kubelet's cgroup: mountpoint for cpu not found. Kubelet system container metrics may be missing. W1123 22:31:47.383572 3686 server.go:612] failed to get the container runtime's cgroup: failed to get container name for docker process: mountpoint for cpu not found. Runtime system container metrics may be missing. 错误原因 上面的报错是 Kubelet 无法正确访问 Docker 容器运行时的 cgroup 信息，特别是关于 CPU 使用的 cgroup 信息...

在本文中，将探讨使用 k3s 的 kine 项目来替换掉 etcd，并通过实验使用 kubeadm 去 run 一个 k8s 集群，并用 k3s 的 kine 项目来替换掉 etcd。 为什么使用 kine etcd 在 Kubernetes 之外基本上没有应用的场景，并且 etcd 迭代也比较慢，由于没有人愿意维护因此一直在衰退 [1]，并且，Kubernetes 集群中，etcd 也是一个影响集群规模的重大因素。并且 K3S 存在一个项目 Kine 可以使用关系型数据库运行，这样对集群维护者来说可以不需要维护复杂的 etcd 集群，由于关系型数据库有很多高可用方案，这将使得 k8s 集群规模变成了无限可能。 Kine 介绍 前文提到，kubernetes (kube-apiserver) 与 etcd 是耦合的，如果我们要使用 RDBMS 去替换 etcd 就需要实现 etcd 的接口，那么这个项目就是 Kine [2]。 Kine 是一个 etcdshim，处于 kube-apiserver 和 RDBMS 的中间层，它实现了 etcdAPI的子集（不是etcd的全部功能），Kine 在 RDBMS 数据库之上实现了简单的多版本并发控制；将所有信息存储在一个表中；每行存储此 key 的修订, key, 当前值, 先前值, 先前修订，以及表示该 Key 是已创建还是已删除的标记，通过这种机制可以作为 shim 层来替换 etcd。...

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 监控管道分为两个：...

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='{.spec.affinity.podAntiAffinity}' Pod Network 运行 Debug Pod 进行调试 bash 1 kubectl run -it --rm --restart=Never --image=busybox net-debug-pod -- /bin/sh 测试从 Pod 到 Endpoint 的连接性...

本文将介绍 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....