一次Kubernetes集群故障处理案例:etcd无法选出Leader导致Kubernetes API-Server启动失败

1. 概述

1、集群信息

Name IP Role
Node1 172.17.1.120 控制节点1
Node2 172.17.1.121 控制节点2
k8s-2 172.17.1.131 工作节点1
k8s-3 172.17.1.132 工作节点2

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 启动失败。

journalctl -u kubelet -n 100 --no-pager | less
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"
阅读更多

Ubuntu升级后导致的Kubernetes问题

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

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

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"“

阅读更多

HTTP/3 Alpn? 为什么网站开启了HTTP3浏览器却是用HTTP/2访问?

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

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

阅读更多

从Dashboard鉴权认识Kubernetes的用户认证

Kubernetes 用户认证

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

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

阅读更多

使用UDEV处理k3s节点路由异常问题

一、出了什么问题

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

阅读更多

MacOS/IOS swift项目调用Rust库

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

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

阅读更多

API的身份认证

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

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

阅读更多

N5105 Jellyfin 硬件加速

先说结论,显卡受限于驱动原因,暂时有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有各种直通方案的折腾。

阅读更多