• 1. 概述
  • 1.1、集群信息
  • 1.2、故障现象
• 2. 故障分析
  • 2.1、查询控制节点服务状态
• 3. 故障处理
  • 3.1、查询etcd容器启动参数
  • 3.2、强制启动etcd
  • 3.3、重启kubelet
• 4. 复盘
  • 4.1、控制平面节点数量
  • 3.2、上述操作能避免吗？

1. 概述

这是一个不慎的操作导致的Kubenernets控制平面故障，正常情况下不应该存在偶数控制节点。出现这个情况的原因是，需要我需要更新Node1节点服务器版本，服务器有启动失败的的情况，为了稳妥起见另外启动一个控制节点（即Node2）。更新前已经备份好Etcd数据，崩溃数据恢复已经做好了准备（我以为的…）。

1.1、集群信息

1.2、故障现象

我按照正常卸载控制平面节点的操作步骤，一切顺利，当时并没有什么异常。

1
2
3
4

root@node1:~# kubectl drain node node2 --ignore-daemonsets --delete-emptydir-data
root@node1:~# kubectl delete node node2

root@node2:~# kubeadm reset --force

故障出现原因：双控制平面Kubernetes(这个状态本身就异常，但不在本次讨论范围内)删除Node2控制节点后，另外一个控制平面无法正常工作。具体表现为ETCD启动失败，导致Kubernetes api-server 启动失败。

1

Jul 22 23:17:05 node1 kubelet[3301]: E0722 23:17:05.135471    3301 controller.go:145] "Failed to ensure lease exists, will retry" err="Get \"https://172.17.1.120:6443/apis/coordination.k8s.io/v1/namespaces/kube-node-lease/leases/node1?timeout=10s\": dial tcp 172.17.1.120:6443: connect: connection refused" interval="7s"

这是 胆大心不细[My Fault系列] 的第一篇，之鲁莽升级Host OS后k8s集群故障处理。

Ubuntu 16.04 升级到22.04 能有什么坑呢。

• 1. cgroups 创建失败，Docker containerd Kubernetes Pod创建失败。
  • 1）解决方案
  • 2）为什么呢
• 2. CoreDNS CrashLoopBackOff
  • 1）解决方案
  • 2）为什么呢
• 3. Pod 频繁重启
  • 1）解决方案
  • 2）为什么呢

1. cgroups 创建失败，Docker containerd Kubernetes Pod创建失败。

syslog 如下
Jan 27 16:54:58 k8s-3 kubelet[159565]: E0127 16:54:58.707563 159565 pod_workers.go:951]
…
“Error syncing pod, skipping” err=”failed to "CreatePodSandbox"
…
CreatePodSandboxError: "Failed to create sandbox for pod
…
rpc error: code = Unknown desc = failed to create containerd task: cgroups: cgroup mountpoint does not exist: unknown"“
…
Jan 27 16:55:30 k8s-3 kubelet[159565]: E0127 16:55:30.485050 159565 pod_workers.go:951]
“Error syncing pod, skipping” err=”failed to "CreatePodSandbox" for "prometheus-k8s-1_kubesphere-monitoring-system(9040c116-1ef3-4603-a74d-5e9574b260d1)" with CreatePodSandboxError:
…
rpc error: code = Unknown desc = failed to setup network for sandbox
…
plugin type=\"flannel\" failed (add): loadFlannelSubnetEnv failed: open /run/flannel/subnet.env: no such file or directory"“
…

Kubernetes 用户认证

1. 从Dashboard鉴权认识Kubernetes的用户认证
2. 从签发用户证书认识Kubernetes的用户认证

接上篇从Dashboard鉴权认识Kubernetes的用户认证，我们通过给普通用户签发证书，来认识Kubernetes用户认证。

Nginx1.25 开始开始支持HTTP/3, 当我使用最新的Chrome(116.0.0.0)访问网站，并非每次都是用HTTP/3,很多次访问同一网站还是采用HTTP/2，就如下图，是5分钟内先后两次的访问记录。

这里就引出一个问题，客户端这里专指浏览器是怎么知道要访问的网站采用的HTTP1.1、HTTP/2还是HTTP/3?

Kubernetes 用户认证

1. 从Dashboard鉴权认识Kubernetes的用户认证
2. 从签发用户证书认识Kubernetes的用户认证

Kubernetes的API准入（Access Control）分为用户认证（Authenticating）、鉴权(Authorization)两个部分。鉴权是对权限的控制，来控制角色（Role）、用户(User)是否能访问对象，主要通过RBAC、ABAC实现，你大概率听说过这两种鉴权控制策略。当然鉴权不是本片讨论的重点，下面内容我们主要讨论认证部分。

一、出了什么问题

去年弄了一堆轻量应用服务器，搭建了一个k3s（Rancher发布的轻量版kubebernets）。k3s默认的Flannel的CNI，这个网络插件的好处就是简单，坏处就是过于简陋。每当设置网卡重启的时候flannel路由丢失(相关ISSUE),导致节点失联。

本文主题是IOS使用Rust库。其实C/C++库操作类似，本文前半部分我将描述怎么把Rust library编译为静态/动态连接库，后半部分是怎么使用这个库。

同样的，Rust编译的库同样适用于其他平台的项目比如Android、MSVC等。

API设计中最开始的步骤就是设计鉴权，当前这篇介绍的认证只是鉴权一部分，当然在一个权限设计不完备的系统里，这就是鉴权的全部。

HTTP（不包涵Websocket）是无状态的，所以获得认证的客户端（用户）每次发起请求，都必须携带服务端签发的Token、SessionID等信息。当然这个信息可能不是服务端签发的，比如Basic Auth就是请求携带username+password。从token携带方式上有使用http请求参数的，有使用Cookie方式，还有放到请求body中的。下文我们将分析一下各种认证方式，以及推荐的使用场景。

先说结论，显卡受限于驱动原因，暂时有Ubuntu 21.04+ 以上系统可以实现，直通Windows 10绝无可能（2022/05/19）。
回到主题，最近流行各种小主机做软路由、家庭影音、Nas等系统。这些主机的CPU主要有J4125（10gen）、N5105（11gen）、N6005，其中前两款为Intel® Celeron®，后面这个款为Intel® Pentium®，10代采用14nm工艺，11代采用10nm工艺，N5105和N6005相对J4125有不错的性能提升。在性能相差不大的情况N5105要经济一些，这也是很多人被坑的主要原因，N5105有各种直通方案的折腾。

这是《Golang 微服务监控浅谈》的子篇，本篇介绍一下怎么使用kubernetes prometheus operator监控集群外部节点。