文章

设置集群时，有时需要测试集群内部Pod之间的连通性，或是测试DNS服务是否正常 可以使用kubectl run命令来创建一个Pod，并指定Pod名称、镜像以及命名空间 例如，创建一个busybox镜像，目的是测试kube-authen命名空间下的Pod是否能ping通、DNS服务是否生效： kubectl run ping-test --image=busybox -n kube-authen -it -- sh 以上命令的含义是：在kube-authen命名空间内创建一个镜像为busybox的Pod，Pod名称为ping-test，创建后立刻打开一个交互式终端 在终端内即可进行ping测试或是nslookup测试 有时仅需要进行临时测试，测试完毕后需要立刻删除Pod，那么可以执行指令： kubectl run ping-test --image=busybox -n kube-authen -it --rm -- ping google.com 这里的--rm参数意为“会话结束后自动删除Pod” 注意 如果仅创建了busybox的Pod而没有指定运行命令，例如kubectl run ping-test --image=busybox -n kube-authen，则会导致Pod无限重启，原因是： 在未指定命令的情况下，busybox使用默认入口点，默认行为是启动shell，但启动shell后没有可执行的命令，于是shell自动退出，这表现为容器进程退出，K8s即认为容器启动失败并进行自动重启，如此不断循环，产生CrashLoopBackOff错误

以之前构建完成的Webhook工程为例，将此Go应用部署至k8s中并指定为认证服务器 构建镜像 在工程根目录创建Dockerfile： FROM alpine:3.17 WORKDIR /app # 复制已编译好的二进制文件（此处hook-demo为已构建的Go应用） COPY hook-demo /app/ # 设置可执行权限 RUN chmod +x /app/hook-demo # 暴露服务端口 EXPOSE 9999 # 运行应用 CMD ["/app/hook-demo"] 在Dockerfile所在目录中，运行sudo docker build -t webhook-auth:v1.0 . 完成后检查： ficn@master:~/k8s-webhook-auth$ sudo docker images REPOSITORY TAG IMAGE ID CREATED SIZE webhook-auth v1.0 536c17b2a66c 13 seconds ago 31.8MB alpine 3.17 775f483016a7 7 months ago 7.08MB Pod与Service部署 创建deploy-webhook.yaml： # ~/deploy/deploy-webhook.yaml apiVersion: apps/v1 kind: Deployment metadata: name: webhook-auth namespace: kube-authen # 命名空间 labels: app: webhook-auth spec: replicas: 1 # 本地开发环境，使用单个副本 selector: matchLabels: app: webhook-auth template: metadata: labels: app: webhook-auth spec: containers: - name: webhook-auth image: webhook-auth:v1.0 # 本地镜像名称 imagePullPolicy: Never # 强制使用本地镜像，不尝试从远程拉取 ports: - containerPort: 9999 # webhook实际端口 name: http 创建service-webhook.yaml： ...

本文章所描述的各操作最终目的是将Webhook服务接入Kubernetes集群的认证流程中 LDAP安装 对于Ubuntu，使用apt安装命令：apt-get install -y slapd ldap-utils 安装过程中会出现交互式界面，可以在其中配置管理员密码（不重要，接下来会再次配置） 安装后，slapd服务即开始执行，此时运行dpkg-reconfigure slapd命令，对slapd服务再次进行配置 如果提示未找到dpkg-reconfigure命令，则执行sudo apt install debconf进行安装，若已安装，则可能是dpkg-reconfigure未被配置到PATH中，可以临时使用绝对路径：sudo /usr/sbin/dpkg-reconfigure slapd 配置界面将再次出现，在其中设置： 属性 配置 Omit configuration No DNS domain example.com Organization name orgldap Administrator password 647252 Remove database No Move old database Yes 初始设置完成后，在终端输入sudo slapcat命令即可查看条目： ficn@master:~$ sudo slapcat dn: dc=example,dc=com objectClass: top objectClass: dcObject objectClass: organization o: orgldap dc: example structuralObjectClass: organization entryUUID: 8056974e-a31a-103f-8e78-156a6f1ed35c creatorsName: cn=admin,dc=example,dc=com createTimestamp: 20250401075602Z entryCSN: 20250401075602.540676Z#000000#000#000000 modifiersName: cn=admin,dc=example,dc=com modifyTimestamp: 20250401075602Z 增加条目 创建组织 创建文件base.ldif，设置三个条目，分别为组织管理者、人员组织单位以及组的组织单位 ...

最近在树莓派上使用Docker部署了AList作为个人云盘使用，同时AList还支持整合各大网盘资源，可以极大方便我管理自己的网盘资源，在这里记录一下部署的过程，供之后参考 Docker环境安装 在Linux环境中安装Docker非常方便，直接下载即可。我的树莓派是基于Debian的系统所以直接安装即可，没有遇到什么问题，注意国内网络需要在/etc/docker/daemon.json配置一下镜像源。 docker有效镜像源持续更新网站：Docker/DockerHub 国内镜像源/加速列表（2月15日更新-长期维护） 对于Windows系统，安装Docker的步骤相对比较复杂，参考文章：Windows 11：Docker Desktop 安装和配置指南，因为我是在树莓派上安装的AList，所以有关Windows系统部署AList的过程不在本文讨论中 安装完成后，执行systemctl status docker检查Docker服务是否正常运行 外接硬盘配置 为了能让AList担当个人云盘的功能，我在树莓派外部设置了一个1TB的机械硬盘用于存储数据，硬盘插在硬盘盒上，通过USB线与树莓派连接 连接硬盘后，命令sudo fdisk -l可以查看硬盘的相关信息 在Linux中连接一个硬盘后，一些图形化的系统可以自动挂载硬盘，我的树莓派系统也可以自动挂载，但默认挂载点是在/media的，我不想让它挂载在这个地方，于是决定手动挂载 创建目录：/mnt/1TB_disk作为指定挂载点，然后进行挂载： sudo mount /dev/sda1 /mnt/1TB_disk 挂载完成后，命令lsblk -f可以查看硬盘的文件系统类型、UUID等信息： FICN@FICN:~ $ lsblk -f NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS sda └─sda1 exfat 1.0 67AF-3F5B 926.7G 1% /mnt/1TB_disk 但这样的话，每次连接硬盘时都需要手动挂载一次，很麻烦，所以可以使用autofs实现自动将连接的硬盘挂载至指定目录，当一段时间不使用硬盘资源时，autofs也会自动取消硬盘挂载 autofs自动挂载 sudo apt-get install autofs下载autofs，然后systemctl enable autofs、systemctl start autofs启动服务，创建/etc/auto.master添加： /mnt /etc/auto.disk --timeout=60 最后创建/etc/auto.disk并设置： 1TB_disk -fstype=exfat,raw,noatime :/dev/disk/by-uuid/67AF-3F5B 这里指定了硬盘文件系统类型为exfat，并使用UUID来指定需要被挂载的硬盘，这两个都是之前执行lsblk -f命令获得的信息 如此配置后，硬盘将被自动挂载至/mnt/1TB_disk目录 最后还要禁用系统原有的自动挂载服务：systemctl stop fstab、systemctl disable fstab ...

问题描述 配置master节点时，执行kubeadm init --config kubeadm-config.yaml --v=5命令后，执行至初始化Pod步骤时报错： [wait-control-plane] Waiting for the kubelet to boot up the control plane as static Pods from directory "/etc/kubernetes/manifests". This can take up to 4m0s [kubelet-check] Initial timeout of 40s passed. Unfortunately, an error has occurred: timed out waiting for the condition This error is likely caused by: - The kubelet is not running - The kubelet is unhealthy due to a misconfiguration of the node in some way (required cgroups disabled) ...... 经过检查，host配置无误，cluster的IP地址也与本机相同 ...