本文永久链接: https://www.xtplayer.cn/rancher/rancher-logging-v2-collect-rke1-k8s-logs/ 问题背景rke1 创建的 k8s 集群，k8s 系统基础组件（比如 kubelet、etcd、kube-scheduler等）都是以 docker 容器方式部署。在使用 rancher v2.6+ 版本，建议升级 rancher logging 到 v2 版本。rancher logging 基于开源的 logging operator，对应的 git repo：https://github.com/kube-logging/logging-operator 和文档地址：https://kube-logging.dev/docs/ 。 logging operator 默认只针对 k8s pod 日志和 k8s events，对于主机上 docker run 运行的容器日志不是很友好。因此针对这个问题，rancher 在原有的 logging operator 基础上增加了 rancher-logging-rke-agg ...

本文永久链接: https://www.xtplayer.cn/rancher/etcd-snapshots-showing-0kb-size-in-the-rancher-ui/ 在 rancher 2.6.x 和 2.7.x 版本中，创建的下游集群可能存在集群 etcd 备份大小为 0 kb 的情况。根据 suse 知识库文档 https://www.suse.com/support/kb/doc/?id=000021447 说明，这个问题主要是 rke2 和 rke2-etcd、k3s 和 k3s-etcd 租约的租约持有者不匹配导致。 对于 rke2 集群，可以使用以下命令去修复。 kubectl -n kube-system get cm rke2-etcd-snapshots -oyaml > rke2-etcd-snapshots-cm-bak.yamlkubectl -n kube-system patch cm --type=json -p='[{"op": "remove", "path ...

如上图，有时候在执行 kubectl 命令时候会提示 "memcache.go:255] couldn't get resource list for external.metrics.k8s.io/v1beta1: the server is currently unable to handle the request" 错误。或者在某些系统组件的日志中也可以看到类似 couldn't get resource list for xxx.xxx.k8s.io/v1beta1 这样的错误。 根据以上信息可以知道此问题与 external.metrics.k8s.io/v1beta1 相关，从报错现象看是无法连接到 external metrics server 获取相关信息。 分析rancher\rke\rke2 默认不会部署与 external.metrics 相关的资源，因此如果 k8s 提示 external.metrics.k8s.io/v1beta1 相关信息，那么可以说明集群中有人为部署 external.metrics 相 ...

本文永久链接: https://www.xtplayer.cn/rke2/rke2-enable-audit-logs-of-the-downstream-cluster/ 本文以自定义 rke2 集群为例，编辑 rke2 集群的 yaml，在 machineGlobalConfig 层级下添加 audit-policy-file 配置。以下为设置好的 rke2 集群 yaml 的部分内容 # 默认审计日志输出配置spec:...... rkeConfig:...... machineGlobalConfig: audit-policy-file: | apiVersion: audit.k8s.io/v1 kind: Policy rules: - level: RequestResponse resources: - group: "" resources: - pods. ...

本文永久链接: https://www.xtplayer.cn/rke2/rke2-enable-event-rate-limit-always-pull-images/ rke2 中如果要启用 event_rate_limit 和 always_pull_images 功能，需要单独手动配置。这两个参数对应 k8s 的 https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/admission-controllers/#eventratelimit 启用插件 如果要启用这两个功能，先在主机上执行 ps -ef| grep kube-apiserver ，找到 enable-admission-plugins 后面已启用的插件。然后在 kube-apiserver-arg 下添加 enable-admission-p ...

本文永久链接: https://www.xtplayer.cn/cilium/bandwidth-manager-not-work/ 问题现象在 rke2-cilium app 版本升级到 1.15.000+ 后，可能会导致 bandwidthManager 无法使用，通过 cilium status 命令查看 BandwidthManager 是禁用状态。在 应用|已安装应用中，编辑 rke2-cilium app 将其降级到 1.15 以下版本就可以正常使用。 问题分析通过以下配置，在 rke2 配置中启用 cilium 的 debug。 rkeConfig: additionalManifest: '' chartValues: rke2-cilium: bandwidthManager: bbr: false enabled: true debug: enabled: true ipv6: enabled: false etcd: 在 cilium pod ...

本文永久链接: https://www.xtplayer.cn/calico/readiness-probe-failed-calico-node-is-not-ready-bird-is-not-ready/ 问题现象在通过 rancher ui 或者 rke 安装 k8s 集群时，如果使用的是 calico 网络驱动，可能会出现 calico-node pod 一直无法正常 running。通过执行 kubectl -n kube-system describe calico-node-xxx 命令查看 calico-node pod 事件，可以看到类似如下的报错。 Readiness probe failed: calico/node is not ready: BIRD is not ready: Error querying BIRD: unable to connect to BIRDv4 socket: dial unix /var/run/calico/bird.ctl: connect: connection refused或者calico/node is not ...

本文永久链接: https://www.xtplayer.cn/calico/calico-log-level-set/ 增加 calico-typha 组件的日志级别 运行以下命令以编辑 calico-typha 部署。 kubectl edit deploy calico-typha -n kube-system 将 TYPHA_LOGSEVERITYSCREEN 环境变量从 info 更改为 debug。 containers:- env: - name: TYPHA_LOGSEVERITYSCREEN value: debug 保存并关闭文件以应用更改，然后重新启动 calico-typha 部署。 增加 calico-cni 组件的日志级别 运行以下命令以编辑 calico-config ConfigMap。 kubectl edit cm -n kube-system calico-config 或者 canal-config 将 cni_network_config > plugins > log_level 环境变量更改为 debug ...

本文永久链接: https://www.xtplayer.cn/prometheus/rancher-prometheus-error-opening-query-log-file-permission-denied/ 在 rancher dashboard 启用集群监控时，可能会遇到 prometheus 无法正常运行，报如下的错误。 level=info ts=2020-10-31T12:40:33.171Z caller=main.go:353 msg="Starting Prometheus" version="(version=2.22.0, branch=HEAD, revision=0a7fdd3b76960808c3a91d92267c3d815c1bc354)"level=info ts=2020-10-31T12:40:33.171Z caller=main.go:358 build_context="(go=go1.15.3, user=root@6321101b2c50, date=20201015-12:29 ...

本文永久链接: https://www.xtplayer.cn/rke2/rancher-rke2-init-node-not-found/ 在 rke2 原生架构中，会先运行第一个 server 节点，这个节点被称为初始节点或者 init node，然后其他节点再根据配置的 server url 向第一个节点进行注册。对于 rancher ui 上创建的自定义 rke2 集群也一样，第一个添加的自定义节点默认会被设置为初始节点（init node），其他节点添加后会自动向第一个节点进行注册。 当需要替换初始节点（init node），正常情况下删除初始节点（init node）后，rancher 会自动随机寻找一个其他正常的 master 节点作为初始节点（init node）。但是这里有个前提条件，就是需要有其他状态为 Active 的正常节点。 如果当前集群只有初始节点（init node），添加了一个新的 master 节点准备替换初始节点（init node）。如果没有等新加的 master 节点状态变为 Active 就执行了删除旧初始节点（init node）的操作，那 ...

本文永久链接: https://www.xtplayer.cn/rke2/rke2-waiting-for-probes-kube-controller-manager-kube-scheduler/ 问题背景在使用 rancher 部署的自定义 rke2 集群时，可能会出现如下图的状态。即使更新集群配置触发集群更新，此状态也无法消失。 问题分析在 rke2 架构中，每个节点会运行一个 rancher-system-agent 服务。可执行 systemctl status rancher-system-agent.service 查看服务状态，也可以执行 journalctl -xef -u rancher-system-agent.service 查看服务日志。 默认 rancher-system-agent 服务日志等级为 info，可以通过添加环境变量来提高日志等级。 cat >>/etc/systemd/system/rancher-system-agent.env<<EOFRANCHER_DEBUG=trueCATTLE_DEBUG=trueC ...

本文永久链接: https://www.xtplayer.cn/longhorn/failure-to-delete-orphaned-pod-volume-directory/ 适用版本所有 Longhorn 版本。 Kubernetes v1.28 版本，向后移植的 PRv1.27正在等待合并。 症状如果工作节点发生故障，在托管活动 Pod 时，随着节点停机并等待恢复，这些 Pod 会被正常驱逐。在此期间，负责管理节点的 kubelet 会每隔两秒生成如下错误消息。 orphaned pod <pod-uid> found, but error not a directory occurred when trying to remove the volumes dirE0810 18:19:37.442065 4092 kubelet_volumes.go:245] "There were many similar errors. Turn up verbosity to see them." err="orphaned pod \ ...

本文永久链接: https://www.xtplayer.cn/rancher/rancher-rke2-pulls-image-from-the-http-registries/ 问题背景截止当前 rancher 最新版本 2.7.5，当使用的镜像仓库为 http 访问时，在部署 rke2 时可以看到 rancher-system-agent.service 日志中报 http: server gave HTTP response to HTTPS client，无法正常拉取镜像，比如如下日志 Aug 10 17:56:23 rke2-2 rancher-system-agent[1658]: time="2023-08-10T17:56:23+08:00" level=warning msg="Failed to get image from endpoint: Get \"https://192.168.110.110:80/v2/\": http: server gave HTTP response to HTTPS clie ...

本文永久链接: https://www.xtplayer.cn/linux/another-app-is-currently-holding-the-xtables-lock/ 有时候当我们执行 iptables 命令时候可能会报 Another app is currently holding the xtables lock. Perhaps you want to use the -w option? 在 iptables 客户端进行写 iptables 规则的时候，会短时间的锁住 xtables lock，以防止其他客户端同事写成造成冲突。正常情况下，这个锁定时间会非常短暂。当出现截图问题时，说明其他进程还一直锁住 xtables lock 并未释放，从而会导致其他 iptables 客户端无法正常写 iptables 规则。如果是在 k8s 环境，因为网络驱动会进行 iptables 规则的更新，如果 xtables lock 被锁住导致 iptables 规则无法更新，从而导致跨节点集群网络不可互通。 解决方法 可以通过执行 ps -fp $(pidof ipt ...

本文永久链接: https://www.xtplayer.cn/ingress/set-ingress-default-ssl-cert/ rke1 创建 ingress default ssl cert secret kubectl -n ingress-nginx \ create secret tls ingress-default-cert \ --cert=mycert.cert --key=mycert.key 编辑集群 YAML，在 ingress 配置下添加如下 extra_args 参数 ingress: provider: "nginx" extra_args: default-ssl-certificate: "ingress-nginx/ingress-default-cert" 重启 ingress pod kubectl delete pod -l app=ingress-nginx -n ingress-nginx rke2 在 kube-system 命名空间下创建一个名为 custom ...

本文永久链接: https://www.xtplayer.cn/ingress/persistent-ingress-custom-configuration/ ingress 控制器的某些配置需要在 system 项目下修改 ingress-nginx-controller 配置映射来实现，在 rancher-rke 集群中，ingress 由 rancher 运行的一个 job 来负责安装和更新。虽然手动修改配置映射的方式可以临时生效，在 k8s 集群进行大版本更新时，会触发 job 的重新运行，从而会覆盖之前的所有自定义配置。要持久化配置，需要通过以下方法固定配置。 RKE1 在 rke1 集群的 YAML 配置中，找到 ingress 层级，然后在 options 中添加自定义配置。示例配置如下： ingress: default_backend: false http_port: 0 https_port: 0 options: access-log-path: /var/log/nginx/nginx_access.log ...

本文永久链接: https://www.xtplayer.cn/coredns/persistent-coredns-custom-configuration/ 根据之前的文章 coreDNS 加速外部域名解析 和 coredns 解析外部域名 了解到，如果需要访问集群外部一个没有 dns 解析的域名，可以通过修改 coredns 配置映射文件，使用 coredns 的 hosts 插件进行配置解析。 以上通过手动修改配置映射的方式可以临时生效，在 rancher-rke 集群中，coredns 由 rancher 运行的一个 job 来负责安装和更新。在 k8s 集群进行大版本更新时，会触发 job 的重新运行，从而会覆盖之前的所有自定义配置。要持久化配置，需要通过以下方法固定配置。 RKE1 在 rke1 集群的 YAML 配置中，将 coredns 的完整配置以 addons 的方式添加。 rancher_kubernetes_engine_config: addon_job_timeout: 45 addons: |- --- apiVersion: v1 ...

本文永久链接: https://www.xtplayer.cn/kubernetes/unexpected-eof-during-watch-stream-event-decoding/ 在 rke 部署的 k8s 集群架构中，只有 worker 角色的节点，会在节点上以 host 网络模式运行一个 nginx-proxy 容器，这个容器代理到 apiserver 服务然后保留 6443 端口以供节点上的 k8s 组件连接（比如 kubelet、kube-proxy）。节点上的 kubelet 容器等 k8s 组件，会直接通过连接 https://127.0.0.1:6443 的方式来了解 apiserver。 因此在 kubelet 或者 kube-proxy 组件中可以看到类似如下的信息。 I0806 14:27:53.862021 5166 streamwatcher.go:103] Unexpected EOF during watch stream event decoding: unexpected EOFI0806 14:27:53.863139 5166 ...

本文永久链接: https://www.xtplayer.cn/rancher/rancher-2-6-logging-output-alyun-oss-example/ 参考 https://kube-logging.dev/docs/configuration/plugins/outputs/secret/ 创建授权密文 apiVersion: v1kind: Secrettype: Opaquemetadata: annotations: logging.banzaicloud.io/default: watched name: oss-auth-secret namespace: cattle-logging-systemdata: username: <base64 加密> password: <base64 加密> 创建 ClusterOutput，oss 插件配置参数参考 https://kube-logging.dev/docs/configuration/plugins/outputs/oss/ ，buffer 配置参数参 ...

本文永久链接: https://www.xtplayer.cn/rancher/rancher-2-6-project-user-view-monitor-metric/ 在给项目添加成员时，可以添加项目所有者、项目成员、项目只读用户，或者自定义的某些项目权限。 有时候可能需要项目用户也可以查看应用的监控图表，但默认配置下以上的这些权限都无法查看应用的监控指标。为了满足这个需求，我们需要自定义一个集群权限。 操作方法 在 用户&认证|角色 中创建一个集群角色，授予 services/proxy 资源的 create 和 get 权限。 也可以使用以下的 YAML 文件直接在 local 集群创建。 apiVersion: management.cattle.io/v3builtin: falsecontext: clusterdescription: show-metricdisplayName: show-metricexternal: falsehidden: falsekind: RoleTemplatemetadata: annotations ...

本文永久链接: https://www.xtplayer.cn/kubernetes/no-podsandbox-found/ 根据 issue https://github.com/kubernetes/kubelet/issues/21 说明，在相对较老的 k8s 版本中，当从 runtimeservice 收到不一致的容器列表时，Kubelet 进入循环重启状态。在 kubelet 日志中可以看到如下的错误信息，这些错误信息会持续的循环打印 {"log":"F0609 16:18:40.349779 48606 kubelet.go:1386] Failed to start ContainerManager failed to build map of initial containers from runtime: no PodsandBox found with Id 'ad00f282abdb54fbb90b357ae79e9aeeb89ca33054fca207c2ca7c1522a742d3'\n&qu ...