kubelet, container runtime, runc
K8s 网络之深入理解 CNI
K8s 已经在很早前的 1.20 版发布之前就宣布要移除内嵌在 kubelet 中的 docker shim 的代码，大概原因就是谷歌一直在 k8s 中使用一套叫做 CRI（container runtime interface）的规范，该规范旨在定义 k8s 如何更好地操作容器技术，该规范大概分为三部分：CRI Client，CRI Server，OCI Runtime；
简单来讲，就是在 kubelet 中放一个 grpc 的客户端，这个客户端要和一个 grpc 的服务端进行通信，这个 grpc 的服务端里头进行容器管理（“拉起”，“销毁” 等动作）的调用，而真正执行 “拉起”，“销毁” 等动作的代码由 OCI Runtime 实现；

或者再简单点，对应到实现来说：CRI Client 端有个实现就是 kubelet 程序；CRI Server 端有个实现叫 Containerd 程序；OCI Runtime 有好多实现其中有个叫 runc 程序；
然后，把他们串起来就是： 1）kubelet 在做完了一些准入校验操作之后（例如 CSI 的存储卷挂载等等），要去拉起一个 pod 了，在拉起 pod 的时候，就先启动一个 grpc 的客户端，然后与 Containerd 中的 grpc 的服务端通信，告诉它说要拉起一个 pod 了； 2）然后 containerd 收到后会按照一定的流程去“拉镜像”，“创建 sandbox”，“创建 netns”，“启动容器”，“创建容器网络”，“把容器加入到 sandbox” 中等； 3）containerd 基本上只负责调用（高级运行时），真正实现这些功能的地方在 OCI 的 runc（或其他低级运行时）中，有点像是通常服务端的 controller 和 service；
Container Runtime
Container Runtime（容器运行时）是运⾏于 Kubernetes Cluster 每个节点中的服务，负责容器的整个⽣命周期；
随着容器云的发展，涌现了很多容器运⾏时。Docker 就⽬前来说是应⽤最为⼴泛的；
CRI | Container Runtime Interface
Google 为了将 kubelet 与特定的 Container Runtime 解耦（比如底层不仅只能使用 Docker 服务），于是推出 CRI（容器运⾏时接⼝，Container Runtime Interface），其是 Kubernetes 定义的⼀组 gRPC 服务；
kubelet 作为 Client，基于 gRPC 框架，通过[……]

READ MORE

The EFS tail data ERROR!!
问题描述

原因分析
我们咨询官方技术支持，技术支持反馈是：看报错是启动大包出问题，重新上传 .cc 文件即可；
解决方案
参考升级指导书:https://support.huawei.com/enterprise/zh/doc/EDOC1100139828?idPath=24030814|21782164|7923148|256863199 按照《6 通过系统启动菜单升级》进行操作
其大致过程如下： 1）登录路由器的 bootrom 界面：重启设备，在界面出现以下提示信息时，三秒内按下快捷键 Ctrl+B 进入 BootROM 主菜单； 2）输入 BootROM 密码（独立密码，非登陆密码）：huawei / Admin@huawei（具体参考文档） 3）利用其他服务器，配置一个 FTP 服务，FTP 提供 .cc 下载， 4）然后。路由器作为 FTP Client 重新下载 .cc 文件[……]

READ MORE

该笔记将记录：华为网络设备，RADIUS 的配置方法，以及常见问题解决方案；
概念术语
域 | Domain
缺省情况下，设备存在两个域：

全局默认普通域 default、
全局默认管理域 default_admin。两个域均不能删除，只能修改；

注意：该 Domain 与远端认证没有关系，只是通过 Domain 能够为不同用户指定不同认证方案。
默认普通域（default）当前为空闲域，不起作用。default_admin 为管理员（通过 SSH，Telnet，Terminal 或 FTP 方式登录设备的用户）的缺省域，缺省为本地认证
当管理员的用户名未携带域名时，设备将管理员加入到缺省域中
实验过程
本地认证 | local

[R1]aaa
[R1-aaa]local-user huawei password cipher huawei123
[R1-aaa]local-user huawei service-type telnet
[R1-aaa]local-user huawei privilege level 0

[R1]user-interface vty 0 4
[R1-ui-vty0-4]authentication-mode aaa

此时，当用户通过 Telnet 登录设备时，将执行该 aaa 认证，需要用户输入帐号密码；
查看默认域信息：

<Huawei>display domain name default_admin

Domain-name : default_admin
Domain-state : Active
Authentication-scheme-name : default
Accounting-scheme-name : default
Authorization-scheme-name : –
Service-scheme-name : –
RADIUS-server-template : –
HWTACACS-server-template : –
User-group : –

<Huawei>display aaa offline-record all
Info:No records

远端认证 | 通过 RADIUS 认证 | AAA Server
定义 AAA 方案： 1）定义 A、A、[……]

READ MORE

通过 terraform import 导入
Developer / Terraform / Terraform CLI / Import Infrastructure

Import existing resources overview | https://developer.hashicorp.com/terraform/cli/import
Import existing resources | https://developer.hashicorp.com/terraform/cli/import/usage
terraform import command reference | https://developer.hashicorp.com/terraform/cli/commands/import

该方式仅能将现有 resource 导入到 state 文件中，而不能直接转化为具体的 resource {} 配置。
我们需要导入并修改配置，所以我们暂时不研究该方式。
通过 import {} 导入
Import Terraform configuration | https://developer.hashicorp.com/terraform/tutorials/state/state-import | 该文档介绍通过 import {} 将 Infrastructure 配置导出到配置文件的方法。通过该方法，我们能够将已有的 Infrastructure 配置导入到本地的配置文件。
Developer / Terraform / Configuration Language / Import

Import | https://developer.hashicorp.com/terraform/language/import | 针对 import {} 指令，参考文档以获取更多使用方法。
Generating configuration | https://developer.hashicorp.com/terraform/language/import/generating-configuration |

步骤大致如下：

Identify the existing infrastructure you will import.
Define an import block for the resources.

其中，import {} 包含 id / to 两个字段
还需要定义 resource {} 部分，其要与 import {} to 部分相对应。[……]

READ MORE

第一步、服务端配置
部分仅记录与我们环境相关的服务端部署过程，参考官方文档获取相关细节。 https://docs.netgate.com/pfsense/en/latest/recipes/ipsec-mobile-ikev2-eap-mschapv2.html
IKEv2 Certificate Structure
我们使用 ACME Package | https://docs.netgate.com/pfsense/en/latest/packages/acme/index.html 来创建证书，所以不需要单独创建 CA 及 Certificate 信息。
Mobile Client Settings
按照官方文档提示进行操作即可。该部分的难点在于针对各种客户端（Windows Linux macOS Android iOS）进行 Phase 1 及 Phase 2 的配置。
Mobile IPsec User Creation
按照官方文档提示进行操作即可。
Q：如何通过 LDAP 进行认证？ A：EAP-MSCHAPv2 will not work with LDAP. In essence, your client sends over an MD4 hash of your password, not the actual password itself. See “The Protocol” section: https://www.cloudcracker.com/blog/2012/07/29/cracking-ms-chap-v2/ . LDAP expects a clear-text username and password to look-up, which EAP-MSCHAPv2 cannot provide. EAP-Radius should allow us to authenticate against a Windows NPS server, which is able to perform a hash look-up directly on AD. We already do this on our network for Wi-Fi where we use PEAP-EAP-MSCHAPv2. It appears NPS can also do EAP-MSCHAPv2 directly avoiding the redundant TLS tunnel. R：https://forum.netgate.com/topic/81377/ikev2-and-active-directory/5
Firewall Rules
按照官方文档提示进[……]

READ MORE

MAC 认证，是种基于端口和 MAC 地址对用户的网络访问权限进行控制的认证方法，它不需要用户安装任何客户端软件； 接入设备在启动了 MAC 认证的接口上首次检测到用户的 MAC 地址后，即启动对该用户的认证操作；
原理简述
以用户的 MAC 地址作为身份凭据到认证服务器进行认证；
特性特征
在认证过程中，不需要用户手动输入用户名或者密码；
应用场景
MAC 认证的应用场景： 1）哑终端的接入认证（如 IP 电话、打印机）：哑终端表示相对于其他终端而言功能较为有限、交互方式比较单一，这里泛指无法输入用户名和密码等认证信息的终端； 2）不需要或用户无法安装任何客户端软件； 3）或结合认证服务器实现「MAC 优先的 Portal 认证」：当用户首次认证通过后，一定时间内免认证再次接入；
组网方式（网络结构）
包含认证客户端、接入设备、认证服务器；

在无线网络中：
触发认证的方式
缺省时，交换机收到 DHCP/ARP/DHCPv6/ND 报文后均能触发对用户进行 MAC 认证。支持通过配置，使交换机收到任意的数据帧后触发 MAC 认证；
在缺省情况下，MAC 认证的用户名和密码均为不带分隔符“-”的 MAC 地址。如“0005e0112233”；
认证的交互流程
针对 PAP 方式
1）接入设备首次检测到终端的 MAC 地址，进行 MAC 地址学习，触发 MAC 认证； 2）接入设备生成一个随机值（MD5 挑战字），并对 MAC 认证用户的[MAC 地址、密码、随机值]依次排列后经过 MD5 算法进行加密，然后将用户名、加密后的密码以及随机值封装在 RADIUS 认证请求报文中发送给 RADIUS 服务器，请求 RADIUS 服务器对该终端进行 MAC 认证； 3）RADIUS 服务器使用收到的随机值对本地数据库中对应 MAC 认证用户的[MAC 地址、密码、随机值]依次排列后进行加密（MD5 算法）处理，如果与设备发来的密码相同，则向设备发送认证接受报文，表示终端 MAC 认证成功，允许该终端访问网络；
针对 CHAP 方式
该方式的 MAC 认证与 PAP 方式的 MAC 认证相比，不同之处在于是：对 MAC 认证用户的 [CHAP ID、MAC Address、随机值] 依次排列后进行 MD5 算法加密；
配置案例

创建 / 进入 MAC 接入模板视图
[Huawei] mac-access-profile name access-profile-name
设备通过 MAC 接入模板统一管理 MAC 用户接入相关的配置。缺省情况下，设备自带 1 个名称为 mac_access_profile 的 MAC 接入模板；

配置[……]

READ MORE

配置 OSPFv2 协议
该笔记将记录：如何使用 pfSense 配置 OSPFv2 动态路由协议的方法，以及相关问题解决方案；
动态路由协议：Dynamic Routing Protocol Basics | pfSense Documentation
第一步、安装软件
Navigate to System > Package Manager Click Available Packages Locate FRR in the list, or search for it Click the + Install to the right of the FRR package entry. Click √ Confirm Wait for the installation to complete
第二步、运行服务
Navigate to Services > FRR Global/Zebra Enable FRR Set Master Password
Navigate to Services > FRR OSPF
然后，配置相关参数： 1）
第三步、流量放行
如果防火墙针对端口进行流量过滤，需要配置响应的防火墙策略；
第四步、查看状态
Status / FRR / OSPF / OSPF Neighbors
配置 BGP 协议
配置案例 | https://docs.netgate.com/pfsense/en/latest/packages/frr/bgp/example.html
与其他厂商不同的是，Route Maps 需要进行配置，否则不会通告或接受任何路由。[……]

READ MORE

问题描述
在应用中，我们经常接触 LDAP 认证，通过 LDAP 能够实现多个平台用户体系的互通。否则，在不同的应用中，我们需要分别维护用户列表。
某次，当对接应用时，我们了解到 OAuth 协议实现单点登陆。但是，当时并无相关应用场景，所以我们也没有深入了解 OAuth 是什么。
现在（12/21/2023），我们尝试学习 OAuth 授权，以为我们 Nginx 反向代理的应用提供登陆功能，而无需为后端应用程序专门开发登陆功能。
解决方案
OAuth（“开放授权 Open Authorization”的缩写）是一种开放的访问授权标准，通常用作互联网用户授予网站或应用程序访问其在其他网站上的信息的方式，但无需向他们提供密码。
原理简述
发展历史
2007 年 12 月 4 日，OAuth Core 1.0 最终草案发布
OAuth 2.0 是行业标准授权协议。OAuth 2.0 注重客户端开发人员的简单性，同时为 Web 应用程序、桌面应用程序、移动电话、客厅设备提供特定的授权流程。该规范及其扩展正在 IETF OAuth 工作组内开发。
注 1，现在（12/21/2023），我们更关心 OAuth 2.0 的使用方法，所以相关内容与 OAuth 2.0 相关，而较少涉及 OAuth 1.0 协议。
原理简述
针对以往的授权场景中，客户端通常需要 ACCESS KEY 和 ACCESS SECRET 来访问某个资源（该模式类似于用户名、密码认证）。但是，如果 KEY SECRET 发生泄漏，则任何人都能够访问该资源。
而 OAuth 2.0 使用访问令牌，访问令牌通常具有过期时间，这样就不要担心 KEY SECRET 的泄漏。
1）OAuth 2.0 是个授权协议，而不是身份验证协议。 2）OAuth 2.0 使用 ACCESS TOKEN。ACCESS TOKEN 是代表最终用户访问资源的授权的一段数据。 3）OAuth 2.0 没有定义 ACCESS TOKEN 的特定格式。但是，在某些情况下，经常使用 JSON Web Token (JWT) 格式。这使得令牌发行者能够将数据包含在令牌本身中。此外，出于安全原因，访问令牌可能有到期日期。
特性特征
OAuth 2.0 是一种授权协议，而不是身份验证协议。所以，它主要被设计为一种授予对一组资源（例如远程 API 或用户数据）访问权限的手段。 OAuth 2.0 不向后兼容 OAuth 1.0
应用场景
Amazon、Google、Facebook、Microsoft 和 Twitter 等公司，其使用此机制来允许用户与第三方应用程序或网站共享有关其帐户的信息。
参考文献
OA[……]

READ MORE

FRR Mode
借助 FRR 工具，引入 BFD, IPv6，MP-BGP 特性；
目前（MetalLB v0.13.5），出于实现性质，并且 BGP 能够满足我们的需求，所以我们暂时不深入研究；
绑定固定地址

…
metadata:
annotations:
metallb.universe.tf/loadBalancerIPs: 172.31.120.7
…

修改地址池
MetalLB v0.13.9
根据我们的经验，修改地址池地址，需要重新启动 metallb-controller 实例，否则 Service 无法获得地址；
参考文献
MetalLB, bare metal load-balancer for Kubernetes[……]

READ MORE

认识
IAM（Identity and Access Management，身份和访问管理）是一套用于管理数字身份并控制其对资源访问权限的框架、技术和策略。它确保正确的实体（用户、设备、服务等）能够以适当的权限访问正确的资源。随着数字化转型的深入和网络安全威胁的增加，IAM 已成为企业 IT 战略中不可或缺的一部分。
组成
核心组件

身份管理：
– 用户身份创建、存储、管理
– 身份验证（Authentication）
– 单点登录（SSO）
– 多因素认证（MFA）

访问管理：
– 授权（Authorization）
– 权限分配和管理
– 基于角色的访问控制（RBAC）
– 基于属性的访问控制（ABAC）

审计与合规：
– 访问日志记录
– 合规性报告
– 异常检测

标准 and 协议 | 认证协议 | Authentication Protocol
SAML（安全断言标记语言） OAuth 2.0 OpenID Connect LDAP（轻量级目录访问协议） SCIM（跨域身份管理系统）
PAP（Password Authentication Protocol） 特点：明文传输密码，安全性低。 用途：旧式 PPP 拨号认证（现基本被淘汰）。 安全性：❌ 无加密，易被窃听。
CHAP（Challenge-Handshake Authentication Protocol） 特点：使用挑战-响应机制，避免明文传输密码。 用途：PPP、PPPoE（如宽带拨号）。 安全性：✅ 比 PAP 安全，但仍可能被暴力破解
MS-CHAP / MS-CHAPv2（Microsoft CHAP） 特点：微软改进版 CHAP，支持双向认证。 用途：Windows VPN（如 PPTP）、企业网络。 安全性：⚠️ MS-CHAPv1 已不安全，v2 仍可用但推荐替换。
除了前面提到的常见 IAM 协议（SAML、OAuth 2.0、OpenID Connect、LDAP、SCIM），IAM 领域还涉及以下重要协议和技术标准：
—
### 1. 认证协议 Kerberos – 基于票据的网络认证协议，主要用于企业内网的单点登录（SSO） – 典型应用：Windows Active Directory 的默认认证协议
RADIUS（Remote Authentication Dial-In User Service） – 用于网络设备（如 VPN、Wi-Fi）的集中认证、授权和记账（AAA） – 替代协议：Diameter（RADIUS 的升级版，支持更[……]

READ MORE

地址分配
在云环境中，创建 Service.type=LoadBalancer 类型，云商将负责创建负载均衡。在自建集群中，我们可以通过 MetalLB 来实现.
预先定义地址池，然后 MetalLB 将从该地址池中选择地址进行分配； 地址池范围取决于环境：既可以使用运营商分配的公网地址，也可以在内网中使用私有地址，或同时使用；
地址通告
当通过 MetalLB 分配地址后，需要让网络感知到该地址的存在；
ARP for IPv4 | NDP for IPv6
在该模式（二层模式）中，Service 的地址被分配到某台主机，然后使用标准的地址发现协议，使其能否被访问。站在网络的角度，简单说，就是通告地址的主机具有多个地址；
ARP for IPv4, NDP for IPv6
主要的特性特征： 部署简单，具有普适性（适合多数环境），无针对网络硬件的特殊要求（相对于 BGP 模式）； 针对某个服务，所有的流量都被发往某个节点，然后被 kube-proxy 进行负载均衡； 并未实现真正的负载均衡，但是依旧实现故障切换（节点故障，地址将被重新分配到其他节点）；
主要的两个缺点： 1）单节点的带宽瓶颈：鉴于所有流量都转发到同一个节点； 2）故障转义时间较长：ARP/NDP 的工作模式，使得转移需要时间；
官方将其与 keepalived 的对比，但这并非我们关注的内容，所以这里不再深入了解相关内容；
BGP mode
在 BGP mode 中，MetalLB 与 Router 建立会话，并就行地址路由通告。通过 BGP 模式，能够实现跨节点的负载均衡，并能否借助 BGP 选路策略实现更精细的路由控制；
借助 BGP 模式，对路由进行通告，除了下一跳不同，所有路由互为等价路由，即每个节点都能接收流量，最后通过 kube-proxy 转发到对应的 Pod 实例； 其基于 packet hash 进行每连接的负载均衡：同个 TCP/UDP 连接，将被转发到同个节点；不同 TCP/UDP 连接，将负载均衡到不同节点； —- 避免数据包的重新排序问题，保证性能； —- 保证报文被转发到同个 Pod 实例（将同个连接的流量散布到不同的节点，每个节点将负载均衡到不同的 Pod 示例，将导致连接重置） 针对 packet hash 算法，具体取决于路由器的实现，3-tuple，5-tuple，参与哈希的元组越多，负载均衡的模型的结果越接近理想值；
针对 BGP 模式的缺点： 1）后端节点下线，出现连接被重置的现象（因为重新哈希而导致流量转发到新的 Pod（其未建立 TCP 连接）； 2）同样，当增加节点时，也会导致连接出现连接重置（同样是因为流量可以被转发到未建立连接的 Pod[……]

READ MORE

问题描述
当用户已下线，而接入设备、RADIUS Server、Portal Server 未感知到该用户已下线时，会产生以下问题： 1）RADIUS 服务器仍会对该用户进行计费，造成误计费。 2）存在非法用户仿冒合法用户 IP 地址和 MAC 地址接入网络的风险。 3）已下线用户数量过多的情况下，还会占用设备用户规格，可能会导致其他用户无法接入网络。
解决方案
所以，接入设备要能够及时感知到用户已下线，删除该用户表项，并通知 RADIUS Server 停止对该用户进行计费。
用户下线方式分为：客户端主动下线、接入设备控制用户下线、服务器控制用户下线。
注意： 1）MAC 认证，仅支持 接入设备控制用户下线 和 服务器控制用户下线； 2）Portal 认证，支持 认证服务器控制下线 和 Portal 服务器控制下线；[……]

READ MORE

问题
我们需要管理我们下载的电影（视频），目的自建视频网站，用于日常的视频播放、观影休闲；
所以，我们创建该笔记，用来整理部分“比较好用的”（能够满足我们需求的）视频管理系统；
该笔记将记录：我们是如何搭建自己的家庭影院（视频媒体管理），以及常见问题的处理方法；
方案
Synology Video Station
视频检索数据库
https://www.imdb.com/ https://movie.douban.com/
专业的多媒体平台
如果要搭建家庭影院，在市面上已有很多集成方案，已实现家庭影音管理；
PLEX Media Server Watch Free Movies & TV | Stream Smarter with Plex Plex: Free vs Paid | Plex Support
Jellyfin: The Free Software Media System Jellyfin: The Free Software Media System
以 Docker 运行，进行快速体验（但是，无法开放访问，必须有帐号密码）：

docker pull jellyfin/jellyfin:latest
mkdir -p /srv/jellyfin/{config,cache}
docker run -d -v /srv/jellyfin/config:/config -v /srv/jellyfin/cache:/cache -v /media:/media –net=host jellyfin/jellyfin:latest

Emby – The open media solution（我们曾经的选择） Emby – The open media solution
视频的内管理系统
Synology Video Station

我们需要解决以下问题：
1）根据需求选择硬件。比如：应该使用那款 NAS 主机（或者自行组装）、硬盘类型、CPU MEMORY 配置参数等等；
2）寻找合适的存储管理系统，能够通过 Web 界面进行存储管理、创建网络文件系统等等。比如：FreeNAS、黑群辉等等；
3）寻找合适的多媒体服务，进行多媒体资源的管理（音频、视频、照片）。比如：Jellyfin、PLEX Media Server 等等；

视频管理平台

最初，我们没有选用家庭影院方案。起因是我们希望在电脑上可以直接通过网页打开播放，即直接播放 MP4 文件，基于 Web 的「视频管理系统」来是最贴近我们需求的工具；[……]

READ MORE

问题描述
该笔记将记录：在 Linux 中，如何搭建 LDAP 服务，以及相关问题的解决方法。
环境概述
操作系统：Ubuntu 20.04.3 LTS 软件版本：2.4.49+dfsg-2ubuntu1.8
解决方案
已有很多关于 LADP 服务搭建的文章，我们能够进行参考（这里做简单记录）。
第零步、准备工作
1）修改主机名：

hostnamectl set-hostname ldap.d3rm.org

2）添加 ldap.d3rm.org 的 DNS A 记录，并解析到该主机（或通过修改 /etc/hosts 文件，这里不再展开）。
关于修改主机名： 1）修改主机名主要是为了域名最后的部分，这里为 d3rm.org 部分； 2）在安装 slapd 过程中，会提取该值作为 BDN 信息（dc=d3rm,dc=org）； 3）否则，就要使用 dpkg-reconfigure slapd 来重新进行配置； 4）如果未设置主机名，则 cn=admin 将属于 dc=nodomain 条目；
第一步、安装服务

# apt-get install -y slapd ldap-utils
…

// 在安装的过程中会提示输入 admin 密码，根据提示设置即可；

执行 slapcat 命令，以检查服务安装成功：

# slapcat
dn: dc=d3rm,dc=org
objectClass: top
objectClass: dcObject
objectClass: organization
o: tech
dc: d3rm
structuralObjectClass: organization
entryUUID: 0d94ef1c-a873-103b-8452-1d0030c906c2
creatorsName: cn=admin,dc=d3rm,dc=org
createTimestamp: 20210913001240Z
entryCSN: 20210913001240.349640Z#000000#000#000000
modifiersName: cn=admin,dc=d3rm,dc=org
modifyTimestamp: 20210913001240Z

dn: cn=admin,dc=d3rm,dc=org
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: admin
description: LDAP administrator
userPassword:: e1NTSETVaMWWYNnk3UThZZVZ1OExYOF[……]

READ MORE

kubelet 是如何连接 API Server
在 Kubernetes 中，Worker 的 kubelet.service 通过配置文件中的 kubeconfig 来连接 API Server；
kubelet.service 连接 API Server 的配置文件位于 /etc/kubernetes/kubelet.conf。该配置文件中包含了 API Server 的地址、证书和认证信息等。kubelet.service 会使用该配置文件中的信息与 API Server 进行通信，以获取 Pod 的调度信息、镜像等相关信息；
[WIP.] Orphaned pod … found, but volume paths are still present on disk
Aug 27 10:18:16 node1 kubelet[17516]: E0827 10:18:16.373981 17516 kubelet_volumes.go:140] Orphaned pod “14b61b27-c86c-11e9-b6c3-005056814b85” found, but volume paths are still present on disk : There were a total of 1 errors similar to this. Turn up verbosity to see them.
[Sol.] 磁盘 I/O 极高
Kubelet & heapster extremely high disk i/o (reads) · Issue #47928 · kubernetes/kubernetes · GitHub Reserve Compute Resources for System Daemons | Kubernetes
原因分析
内存压力导致磁盘 IO 极高；
解决方案
1）通过处理内存占用高的应用，来环节内存压力； 2）然后，为应用程序增加 CPU、MEM 资源限制；[……]

READ MORE

Nodes are in ‘Not Ready’
问题描述
使用kubectl get nodes命令查看节点状态，节点出于’Not Ready’状态；
原因分析
使用kubectl describe nodes “<node name>”来查看节点的信息；
还可以使用journalctl -f -u kubelet来查看节点日志；
解决方案
How to debug when Kubernetes nodes are in ‘Not Ready’ state
[Sol.] … node XXX already cordoned …
When you try to drain a Kubernetes node but it blocks ?
在执行 kubectl drain node1 –ignore-daemonsets 剔除节点时卡住[……]

READ MORE

问题概述
启动systemctl start kubelet.service服务后，在日志中出现如下错误消息：

Aug 27 11:09:20 node1 kubelet[1188]: E0827 11:09:20.083185 1188 azure_dd.go:147] failed to get azure cloud in GetVolumeLimits, plugin.host: node1
Aug 27 11:09:30 node1 kubelet[1188]: E0827 11:09:30.108157 1188 azure_dd.go:147] failed to get azure cloud in GetVolumeLimits, plugin.host: node1
Aug 27 11:09:40 node1 kubelet[1188]: E0827 11:09:40.122239 1188 azure_dd.go:147] failed to get azure cloud in GetVolumeLimits, plugin.host: node1

大概五秒钟一次，本文将介绍如何处理该错误。
系统环境

操作系统：
CentOS Linux release 7.4.1708 (Core)

Kubernetes：
v1.12.1

问题原因
报错的是AttachVolumeLimit插件，这个插件用于报告可以附加到节点的卷数限制，因为Google，Amazon，Microsoft等云商通常对可以连接到节点的卷数量进行限制。 对于Kubernetes来说，反映这些限制很重要。否则，调度到节点上的Pod可能会因为等待卷挂载而卡住。
但是，我们是自己部署的集群，没有云商的限制，所有可以禁用它。
解决办法
修改/etc/sysconfig/kubelet配置文件，添加–feature-gates=AttachVolumeLimit=false选项。
参考文献
K8S_v1.12.1提示failed to get azure cloud in GetVolumeLimits, plugin.host: master Error message: “failed to get azure cloud in GetVolumeLimits” in bare-metal setup after upgrade to 1.12.1 #69503 resize2fs: Bad magic[……]

READ MORE

认识
pfSense 是一种开源的网络防火墙和路由器操作系统。始于 2004 年，由 m0n0wall 分支而来，由 Netgate 公司主导开发。社区版免费，企业版提供付费支持（如 TAC 支持、云功能等）。以稳定性和企业级功能著称，用户基数庞大。
pfSense software was forked from the m0n0wall open source project in 2004. m0n0wall was focused specifically on providing a firewall/router for embedded devices and was sized for limited hardware resources. Initially pfSense software aimed at providing a firewall/router solution with an expanded set of capabilities on larger PC and server style hardware.
The early tag line for the pfSense open source project was “making sense of pf”, referring to the packet filter technology at the core of the project.
官网
https://www.pfsense.org/
文档
https://docs.netgate.com/pfsense/en/latest/
Finding Information and Getting Help | https://docs.netgate.com/pfsense/en/latest/general/help.html
Acknowledgements | https://docs.netgate.com/pfsense/en/latest/preface/acknowledgements.html
仓库
https://github.com/pfsense/pfsense
组成
—— 该“组成”指构成 pfSense 的内部组件（架构），在日常使用中，我们并不会与该类部件直接交互。例如，操作系统、配置文件、服务管理、……。
协议许可：Apache 2.0 open source license（Learn About the pfSense Project）
FreeBSD
操作系统：其基于 FreeBSD 操作系统；
Why FreeBSD? | https://docs[……]

READ MORE

WIP ! [Kubernetes] apiserver 响应慢，执行 kubectl 返回的时间较长。
事实证明，API 服务器是一个瓶颈，有几个到 API 服务器的连接返回 504 网关超时，此外还有本地客户端限流（指数退避）。这些问题在扩展过程中 呈指数级 增长：
API 服务器上限制速率的队列的大小是通过 max-mutating-requests-inflight 和 max-requests-inflight 更新的。1.20 版本中引入的 优先级和公平性 特性测试版，就是在 API 服务器上这两个标记的控制下将队列的总大小在不同的队列类别之间进行划分。
例如，群首选举请求的优先级比 Pod 请求高。在每个优先级中，都有可配置队列的公平性。未来还可以通过 PriorityLevelConfiguration&FlowSchema API 对象做进一步调优。[……]

READ MORE

集群中的每个节点上都有 kube-proxy 服务，负责为 Service（除 ExternalName 外）实现一种形式的虚拟网络地址； 1）在 Kubernetes v1.0 中，Service 是“第 4 层”（基于 IP 的 TCP/UDP）构造，代理纯粹在用户空间中； 2）在 Kubernetes v1.1 中，添加 Ingress API（beta）来表示“第 7 层”（HTTP）服务，也添加 iptables 代理，并成为自 Kubernetes v1.2 以来的默认操作模式； 3）在 Kubernetes v1.8.0-beta.0 中，添加 ipvs 代理；
下面是 kube-proxy 运行的三种模式：
代理模式：userspace
该模式下，kube-proxy 观察 Kubernetes master 节点，然后删除和添加 Service 与 Endpoints 对象。为每个 Service 在本地节点打开一个端口（随机），任何访问该“代理端口”的连接将被代理到 Service 的后端 Pod 上。至于用哪个后端 Pod，要基于 Service 的 SessionAffinity。最后，它安装防火墙规则，捕获到 Service 的 Cluster IP（虚拟）和端口的流量，然后重定向流量到“代理端口”；
默认后端是循环选择的；

Client => ClusterIP:Port(iptables) => proxy port(kube-proxy) => Backend Pod 1 ~ N

（”为每个 Service 在本地节点打开一个端口“，该端口号存在于 Cluster IP 上）
代理模式：iptables
该模式下，kube-proxy 观察 Kubernetes master 节点，然后删除和添加 Service 与 Endpoints 对象。对于每个 Service，它安装防火墙规则，捕获到 Service 的 Cluster IP（虚拟）和端口的流量，然后重定向流量到 Service 的后端集合。对于每个 Endpoints 对象，它安装防火墙规则，来选择后端的 Pod；
默认后端是循环选择的；

Client => ClusterIP:Port(iptables) => Backend Pod 1 ~ N
^
|
kube-proxy <= api-server

代理模式：ipvs
该模式下，kube-proxy 观察 Kubernetes 的 Service 和 Endpoints，然后调用[……]

READ MORE

当作为一个独立的组件单独测试时，调度器可以支持每秒 1000 个 Pod 的高吞吐率。
然而，在将调度器部署到一个在线集群中时，我们注意到，实际的吞吐量有所降低。etcd 实例速度慢导致调度器的绑定延迟增加，使得待处理队列的大小增加到数千个 Pod 的程度。我们的想法是在测试运行期间将这个数值保持在 100 以下，因为数量比较大的话会影响 Pod 的启动延迟。此外，我们最后还调整了群首选举参数，以应对短暂的网络分区或网络拥堵引发的虚假重启。
kubernetes scheduler How does the Kubernetes scheduler work?
常见问题处理
[WIP] … kube-scheduler: timed out waiting for the condition
当将节点加入集群时，主节点的 kube-scheduler-k8scp-01 发生重启。日志如下：

I0408 10:23:44.110342 1 configmap_cafile_content.go:202] Starting client-ca::kube-system::extension-apiserver-authentication::client-ca-file
I0408 10:23:44.110368 1 shared_informer.go:240] Waiting for caches to sync for client-ca::kube-system::extension-apiserver-authentication::client-ca-file
I0408 10:23:44.110404 1 configmap_cafile_content.go:202] Starting client-ca::kube-system::extension-apiserver-authentication::requestheader-client-ca-file
I0408 10:23:44.110424 1 shared_informer.go:240] Waiting for caches to sync for client-ca::kube-system::extension-apiserver-authentication::requestheader-client-ca-file
I0408 10:23:44.209318 1 shared_informer.go:247] Caches are synced for RequestHeaderAuthRequestController
I0408 10:23:44.2095[……]

READ MORE

Role
Role 是 OAuth 2.0 框架的重要概念，其为参与 OAuth 2.0 过程的所有组件。分为如下几种：
1）资源所有者（Resource Owner）：拥有受保护资源并可以授予对其访问权限的用户或系统。
2）客户端（Client）：客户端是需要访问受保护资源的系统。要访问资源，客户端必须持有适当的访问令牌。
3）授权服务器（Authorization Server）：该服务器接收来自客户端的访问令牌请求，并在成功验证并得到资源所有者同意后发出这些请求。授权服务器公开两个端点：授权端点（处理用户的交互式身份验证和同意）和令牌端点（参与机器对机器交互）。
4）资源服务器（Resource Server）：保护用户资源并接收客户端访问请求的服务器。它接受并验证来自客户端的访问令牌，并向其返回适当的资源。
交互流程

注 1，该交互流程仅用于演示与使用，在不同的配置中，会存在额外的步骤。
0）Client 需要预先获取 Client ID 与 Client Secret 参数。
1）Client 请求 AS 并附带 Client ID、Client Secret、Scope、endpoint URI 参数。

Scope 是 OAuth 2.0 中的一个重要概念。它们用于准确指定授予资源访问权限的原因。

可接受的 Scope 值以及它们与哪些资源相关，取决于 Resource Server。
2）AS 验证 Client，并判断 Client 是否能够访问 Scope 定义的范围。
3）当 AS 通过验证后，RO 与 AS 互动，RO 授予访问权限。
4）AS 重定向到客户端（假定 endpoint URI 为客户端自身），并携带 AC AT RT 参数

携带的具体参数取决 Grant Type：
1）Authorization Code grant：授权服务器向客户端返回一次性授权代码，然后将其交换为访问令牌。对于可以在服务器端安全地进行交换的传统 Web 应用程序来说，这是最佳选择。授权代码流可能由单页应用程序 (SPA) 和移动/本机应用程序使用。然而，在这里，客户端秘密无法安全存储，因此在交换期间的身份验证仅限于仅使用客户端 ID。更好的替代方案是下面带有 PKCE 授予的授权代码。
2）Implicit Grant：访问令牌直接返回给客户端的简化流程。在隐式流程中，授权服务器可以将访问令牌作为回调 URI 中的参数或作为对表单发布的响应返回。由于潜在的令牌泄漏，第一个选项现已弃用。
3）Authorization Code Grant with Proof K[……]

READ MORE

认证协议的交互流程
认证触发方式：

1）客户端主动触发方式：用户主动开启客户端，并输入用户名和密码，然后向接入设备发送 EAP 报文来触发认证（客户端发送 EAPoL-Start 报文触发认证）；

2）接入设备主动触发方式：当接入设备接收到用户终端发送的 DHCP/ARP/DHCPv6/ND（或任意报文）报文后，主动触发用户终端自动弹出客户端界面，用户输入用户名和密码即可启动认证；

接入控制方式：

1）基于 Port 模式：当采用基于端口方式时，只要该端口下的第一个用户认证成功后，其他接入用户无须认证就可使用网络资源。但是当第一个用户下线后，其他用户也会被拒绝使用网络；

2）基于 MAC 模式：当采用基于 MAC 地址方式时，该端口下的所有接入用户均需要单独认证。当某一用户下线时，不影响其他用户接入网络；

EAP 中继方式（以 EAP-MD5 认证为例）

EAP 中继方式的认证流程： 1）当用户需要访问外部网络时打开 802.1X 客户端程序，输入已经申请、登记过的用户名和密码，发起连接请求。此时，客户端程序将向设备端发出认证请求报文（EAPoL-Start），开始启动一次认证过程； 2）设备端收到认证请求报文后，将发出一个 Identity 类型的请求报文（EAP-Request/Identity）要求用户的客户端程序发送输入的用户名； 3）客户端程序响应设备端发出的请求，将用户名信息通过 Identity 类型的响应报文（EAP-Response/Identity）发送给设备端； 4）设备端将客户端发送的响应报文中的 EAP 报文封装在 RADIUS 报文（RADIUS Access-Request）中发送给认证服务器进行处理； 5）RADIUS Server 收到设备端转发的用户名信息后，将该信息与数据库中的用户名列表对比，找到该用户名对应的密码信息，用随机生成的一个 MD5 Challenge 对密码进行加密处理，同时将此 MD5 Challenge 通过 RADIUS Access-Challenge 报文发送给设备端； 6）设备端将 RADIUS Server 发送的 MD5 Challenge 转发给客户端； 7）客户端收到由设备端传来的 MD5 Challenge 后，用该 Challenge 对密码部分进行加密处理，生成 EAP-Response/MD5 Challenge 报文，并发送给设备端； 8）设备端将此 EAP-Response/MD5 Challenge 报文封装在 RADIUS 报文（RADIUS Access-Request）中发送给 RADIUS Server；[……]

READ MORE

连接 LDAP 服务
RH124 CHAPTER 8 CONNECTING TO NETWORK DEFINED USERS AND GROUPS
Configure LDAP Client on Ubuntu 20.04|18.04|16.04
开启 TLS 访问
Secure OpenLDAP Server with SSL/TLS on Ubuntu 20.04|18.04|16.04
证书续期（无需重启）： Re: slapd and LetsEncrypt certificates: does a cert renewal necessitate a server restart?[……]

READ MORE

网络 | Network
关闭自动更新
知乎 / 如何关闭 win10 的自动更新？
我们看到部分文章介绍的方法，但是并不好用。
家庭版，80 端口被占用排查（PID4、System、ntoskrnl）
PID4 (system32/ntoskrnl.exe) blocking the port 80 – Microsoft Q&A Port 80 is being listened by SYSTEM (PID 4) on Windows | fujii.github.io KB-7443: Cannot configure report services when port 80 is used by another application
问题描述：Windows 10 家庭版，系统 80 端口占用；
原因分析：

# netstat -abo | findstr :80 # 查找占用 80 端口的进程

// 我们发现是名为 System 的进程，PID=4，进程为 ntoskrnl 文件；

# netsh http show servicestate # 查看使用 HTTP 服务的进程

// 根据排查上述命令的输出，我们发现是 Microsoft SQL Server Reporting Services 占用 80 端口；

解决方案：根据实际情况， 1）在服务中，禁用 Microsoft SQL Server Reporting Services 服务； 2）或者修改其端口号（KB-7443: Cannot configure report services when port 80 is used by another application）：

Open Reporting Services Configuration Manager.
Navigate to “Web Service URL”
Change the TCP port to an unused port other than 80. For example, port 8080.
Navigate to “Report Manager URL” then click “Advanced”
Change the TCP port to the port number specified in step 3.
Run the Centrify Report Services Configuration Wizard and specify URLs with the new port number. For example,
http:[……]

READ MORE

该笔记将记录：在 Kubernetes Cluster 中，部署及使用 MetalLB 组件的方法，以及常见问题的解决办法。理论：掌握 MetalLB 的使用方法；实践：通过 MetalLB 组件，实现 Service 资源分配地址及服务暴露。
认识
MetalLB，集群 LoadBalancer 组件，能够从 Address Pool 中为 spec.type: LoadBalancer 的 Service 资源分配地址。解决自建 Kubernetes 集群无法使用负载均衡的难题。
官网：https://metallb.io/ 文档：https://metallb.io/installation/ 仓库：https://github.com/metallb/metallb
改进
其成熟度
MetalLB is currently in beta. MetalLB v0.13.5
我们是在 Staging / Developing，以及内部环境中使用，暂时还未遇到严重问题； 根据官方描述，部分用户已经在生产环境中使用；
测试覆盖率：代码库具有合理的测试覆盖率，以及覆盖大部分回归的大量端到端测试。尽管如此，边缘情况可能存在错误，因此如果发现意外行为，考虑提交问题；
配置格式：其可能发生变更，但是官方会进行描述，并提供相关的工具进行说明；
目前（04/28/2022，MetalLB v0.12.1）为止，看起来 MetalLB 并不那么依赖于 Kubernetes API 版本，其主要工作是在 Worker 完成地址绑定及通告、管理流量转发规则；
文档：文档存在，还有需要改善的地方，尚未经过许多不熟悉该项目的读者的实战测试；
开发者：MetalLB 的版权归谷歌所有，直到 2019 年 3 月。然而，它从来都不是谷歌的官方项目。该项目没有任何形式的企业赞助。我们是在 Nginx Ingress Controller 的官方文档中了解到 MetaLB 项目，所以开始尝试使用；
# 05/02/2025 目前 v0.14.9 版本。
社区贡献
metallb/metallb: A network load-balancer implementation for Kubernetes using standard routing protocols[……]

READ MORE

我们设置的凭证保存在哪里？
在 Jenkins 中，我们设置的凭证都存储在 /var/lib/jenkins/credentials.xml 文件中，但是进行了加密。
如何查看凭证信息的明文？
如果想查看，
第一步、访问 http://<YOUR JENKINS_URL/script 地址
第二步、输入如下命令，并运行：

println( hudson.util.Secret.decrypt(“{AQAAABl5pYu3vTzodW48IBDAreNBl6JJtKfpqpgw==}”) )

// 其中 {AQAAABl5pYu3vTzodW48IBDAreNBl6JJtKfpqpgw==} 就是在 /var/lib/jenkins/credentials.xml 中找到的加密口令
// 注意，一定要带上 {}，否则只会反会 null 值。

参考文献
Extract passphrase from Jenkins’ credentials.xml[……]

READ MORE

问题描述
原有 Docker 1.13 版本，升级到 Docker 19.03 版本。在重新启动 kubelet 服务后，产生如下错误：

misconfiguration: kubelet cgroup driver: “systemd” is different from docker cgroup driver: “cgroupfs”

OS：CentOS Linux release 7.5.1804 (Core) Kubernetes：v1.14.0 Docker：Docker version 19.03.2, build 6a30dfc
问题原因
我们没有深入研究，但是根据错误提示，可以得到以下信息：

1）kubelet 使用的 cgroup driver 是 systemd 的，
2）而 docker 使用的 cgroup driver 是 cgroupfs 的

两者不同，导致上述错误。解决办法应该是使二者的 cgroup driver 相同；
解决办法
修改 /etc/sysconfig/kubelet 文件，为 KUBELET_EXTRA_ARGS 添加 –cgroup-driver=cgroupfs 选项；
原先为–cgroup-driver=systemd选项，位于/var/lib/kubelet/kubeadm-flags.env中（应该是初始化时生成的）；
参考文献
1.6.0 kubelet fails with error “misconfiguration: kubelet cgroup driver: “cgroupfs” is different from docker cgroup driver: “systemd” #43805[……]

READ MORE

问题描述
在执行 kubectl get nodes 命令后，产生如下错误：

# kubectl get nodes
Unable to connect to the server: x509: certificate is valid for 10.96.0.1, 172.16.187.21, not 170.34.184.65

我们出现该问题的场景：将远程节点的 .kube/config 复制到本地，并修改 clusters.cluster.server 来使用 170.34.184.65 地址连接 apiserver，以试图从本地来连接（管理）远程服务器；
原因分析
初始化集群的 CA 并未包含 170.34.184.65 地址，所以在连接集群时会产生该错误；
使用如下命令查看 CA 的 SAN 信息：

# openssl x509 -in /etc/kubernetes/pki/apiserver.crt -text
…
X509v3 Subject Alternative Name:
DNS:k8scp-01, DNS:kubernetes, DNS:kubernetes.default, DNS:kubernetes.default.svc, DNS:kubernetes.default.svc.cluster.local, DNS:k8scp-endpoint.k4nz.com, IP Address:10.96.0.1, IP Address:172.16.187.21
…

根据命令输出（省略部分无关内容），字段 X509v3 Subject Alternative Name 显示仅能够连接 apiserver 的 DNS 及 IP Address 信息；
解决方案
很多解决方案：
1）在我们的环境中，我们调整 DNS 解析设置：内网 DNS 请求，返回 172.16.187.21 地址；外网 DNS 请求，返回 170.34.184.65 地址。或者，修改 HOSTS 文件（手动绑定）
2）更复杂一点，需要重新签发 apiserver 证书，参考 Manage TLS Certificates in a Cluster | Kubernetes 文档；
参考文献
Henry Xie ‘s blog: Kubectl: Unable to connect to the server: x509: certificate is valid for ….. , not ….. in K8S[……]

READ MORE

问题描述
在某个主机点上，执行 journalctl -f -u kubelet.service 查看日志，显示如下信息：
问题原因
磁盘空间没有用完，但是只剩下 1G 空间。遇到「kube-dns timed out: eviction manager: must evict pod(s) to reclaim ephemeral-storage #4084」问题的人，是因为磁盘空间满了；
如果想要了解该问题的成因，需要阅读「Local ephemeral storage」手册；
解决办法
在「Kubernetes eviction manager evicting control plane pods to reclaim ephemeral storage」中，答主通过修改/var/lib/kubelet/config.yaml配置文件来解决问题；
而我则对主机磁盘进行扩容；
参考文献
Kubernetes eviction manager evicting control plane pods to reclaim ephemeral storage Managing Compute Resources for Containers docker docs/Configure logging drivers Pods evicted with error “The node was low on resource: ephemeral-storage”[……]

READ MORE