1.找到harbor的configmap配置文件，以harbor-cm.yaml为例，修改配置文件，vim harbor-cm.yaml
1 | http { |
2.执行kubectl apply -f harbor-cm.yaml命令更新配置
3.找到harbor的pod所在yaml，以harbor1.yaml为例，vim harbor1.yaml，修改harbor nginx的探针，把默认探测 / 修改为探测 /api/systeminfo
1 | - image: goharbor/nginx-photon:v1.6.4 |
kubectl apply -f harbor1.yaml重启harbor服务harbor页面，预期返回403 Forbidden，无法登录在使用国产海光CPU Hygon C86 7265的服务器上部署K8S集群时，出现calico-node启动失败，相关日志如下：
1 | [root@node1 ~]# kubectl get pod -A -owide |
查看具体错误日志：
1 | [root@node1 ~]# kubectl logs -n kube-system calico-node-v64fv |
经沟通确认，该环境之前安装的版本没有问题，最新的版本才出现。考虑到最新版本升级过calico，先怀疑是不是calico版本的问题。通过升级calico到最新版本，发现问题依然存在。
根据错误日志CRNGT failed查找相关资料[1]，发现有人遇到相同的错误，原因是使用的AMD Ryzen 9 3000 系列CPU存在bug，导致RNRAND 在某些 BIOS 版本中无法正确生成随机数，解决方法是升级BIOS版本。
按照资料[1]提供的检测方法，创建一个main.go文件：
1 | package main |
执行如下命令，在问题服务器上未复现出问题：
1 | $ GOEXPERIMENT=boringcrypto go run main.go |
继续查资料[2]，同样也是AMD Ryzen 9 3000 系列CPU，并且给出了另一种检查方法：
1 | you@ubuntu-live:~$ wget https://cdn.arstechnica.net/wp-content/uploads/2019/10/rdrand-test.zip |
不过，这个链接已经失效了，继续搜索相关资料，又找了一个测试工具[3]，并提供了二进制文件，在异常服务器上测试效果如下：
1 | [root@node1 ~]# ./RDRAND_Tester_Linux_x86_64 --第一次随机数不同 |
在正常的服务器上执行效果如下：
1 | [root@node1 ~]# ./RDRAND_Tester_Linux_x86_64 --多次测试，随机数没有出现相同的情况 |
对比两个服务器的BIOS差异：
1 | 异常服务器： |
1 | 正常服务器： |
对比发现，异常服务器的BIOS版本是Version: 3.07.09P01，而正常服务器的BIOS版本是Version: 5.19，基本确认是BIOS版本差异导致。最后升级BIOS版本后再次测试，随机数生成正常，calico-node也可以正常启动。
升级BIOS的版本。
1.https://github.com/projectcalico/calico/issues/7001
2.https://arstechnica.com/gadgets/2019/10/how-a-months-old-amd-microcode-bug-destroyed-my-weekend/
3.https://github.com/cjee21/RDRAND-Tester
java项目中引用了sshj依赖包远程执行ssh命令，执行ssh的命令在环境上可以正常运行，但通过单元测试验证ssh命令时提示如下错误：
1 | 2024-03-28 17:25:22 WARN DefaultConfig:206 - Disabling high-strength ciphers: cipher strengths apparently limited by JCE policy |
根据报错信息Invalid signature file digest for Manifest main attributes，查找相关资料，尝试以下几种解决方法都没有效果：
provider：Security.addProvider(new sun.security.ec.SunEC());JCE加密限制：Security.setProperty("crypto.policy", "unlimited");sshj的SecurityUtils设置provider：1 | 将BC提供者设置为SSHJ的安全提供者 |
查sshj相关issue[1]，发现一个类似的问题，原因是bcprov的签名无法被验证。查看bcprov的签名情况：
1 | 有问题的版本： |
看起来是版本问题，更新项目中的bcprov版本到1.69，重新测试后报错消失，显示正常的命令执行结果：
1 | 2024-03-29 09:00:08 INFO BouncyCastleRandom:48 - Generating random seed from SecureRandom. |
升级依赖包bcprov的版本到1.69。
参考资料[1]，问题初始现象是：VMWare虚拟化环境下Pod跨VXLAN通信异常。
通过资料[2]可知，临时方案有2个：
方案1：调整网卡的配置：
1 | ethtool -K vxlan.calico tx-checksum-ip-generic off |
方案2：在创建虚拟机时，把网络适配器的类型改为 E1000或E1000e：
最近在跟踪相关issue[3,4]时发现，还有2个方案可以解决该问题（未实际测试验证）。
方案1：如果是flanne网络插件，可以使用如下命令临时解决：
1 | iptables -A OUTPUT -p udp -m udp --dport 8472 -j MARK --set-xmark 0x0 |
方案2：如果是calico网络插件，可以使用如下特性门永久解决：
1 | featureDetectOverride: "ChecksumOffloadBroken=true" |
基于openjdk，使用-d参数控制持续60s后自动停止，使用浏览器打开html报告，内容显示正常：
1 | [root@test arthas]# /usr/bin/java -jar arthas-boot.jar |
基于openjdk-openj9，同样使用-d参数控制持续60s后自动停止，使用浏览器打开html报告，内容显示空白：
1 | [root@test arthas]# /usr/lib/openj9/bin/java -jar arthas-boot.jar |
profiler对openjdk-openj9的支持还不够全面，可以通过不加-d参数，主动stop临时规避：
1 | [root@test arthas]# /usr/lib/openj9/bin/java -jar arthas-boot.jar |
使用这种方法，可以正常输出基于内存的火焰图。
根据kubesphere官方资料[1]，记录搭建离线部署环境出现的几个问题。
制作过程中出现部分镜像拉取超时，可能是网络问题，多次重试即可。
1 | [root@node kubesphere]# ./kk artifact export -m manifest-sample.yaml -o kubesphere.tar.gz |
安装harbor阶段出现unable to sign certificate: must specify a CommonName错误：
1 | [root@node1 kubesphere]# ./kk init registry -f config-sample.yaml -a kubesphere.tar.gz |
参考资料[2]，修改配置registry相关配置：
1 | registry: |
提示下载kubernetes的二进制文件：
1 | [root@node1 kubesphere]# ./kk create cluster -f config-sample.yaml -a kubesphere.tar.gz |
这个错误是因为config-sample.yaml不是通过命令生成的，所以kubernetes的版本不对，查看命令的帮助信息，发现kubesphere的默认版本是v3.4.1：
1 | [root@node1 kubesphere]# ./kk create cluster -f config-sample.yaml -a kubesphere.tar.gz -h |
修改命令，指定kubesphere版本：
1 | [root@node1 kubesphere]# ./kk create cluster -f config-sample.yaml -a kubesphere.tar.gz --with-kubesphere 3.4.0 |
1 | kubesphere-system ks-apiserver-86757d49bb-m9pp4 ContainerCreating |
通过资料[3]可知，可以使用命令kubectl logs -n kubesphere-system $(kubectl get pod -n kubesphere-system -l app=ks-install -o jsonpath='{.items[0].metadata.name}') -f查询进度，上面的异常Pod需要等所有组件安装后才起来：
1 | ##################################################### |
通过查看相关日志可知，如果把harbor仓库安装在master节点，端口会冲突：
1 | [root@master ~]# kubectl logs -f -n kube-system metrics-server-6d987cb45c-4swvd |
修改端口后恢复。
1 | kubesphere-logging-system opensearch-cluster-data-0 init:ImagePullBackOff |
查看发现，init失败，是因为用了busybox镜像，但离线包没有提前下载：
1 | initContainers: |
后面两个镜像拉取失败问题，同样是因为离线包没有提前下载：
1 | Normal BackOff 21s (x51 over 15m) kubelet Back-off pulling image "dockerhub.kubekey.local/kubesphereio/install-cni:1.14.6" |
手动下载导入到离线环境后，异常Pod恢复。
1.https://kubesphere.io/zh/docs/v3.3/installing-on-linux/introduction/air-gapped-installation/
2.https://github.com/kubesphere/kubekey/issues/1762#issuecomment-1681625989
Docker 版本不低于 19.03，同时还要通过设置环境变量 DOCKER_CLI_EXPERIMENTAL 来启用。可以通过下面的命令来为当前终端启用 buildx 插件，并验证是否开启[1]：1 | [root@node1 root]# export DOCKER_CLI_EXPERIMENTAL=enabled |
Linux内核版本升级到 4.8 以上，否则会出现如下异常[2]：1 | [root@node1 root]# docker run --privileged --rm tonistiigi/binfmt --install all |
4.9为例，相关rpm包见链接[3]：1 | [root@node1 4.9]# ll |
binfmt_misc，并检查启用结果：1 | [root@node1 ~]# docker run --privileged --rm tonistiigi/binfmt --install all |
创建一个新的构建器，并启动构建器：
1 | [root@node1 ~]# docker buildx create --use --name mybuilder |
以构建xxx镜像为例，并将构建好的镜像保存在本地，将 type 指定为 docker：
1 | [root@node1 images]# docker buildx build -t xxx/xxx --platform=linux/arm64 -o type=docker . |
查看镜像：
1 | [root@node1 images]# docker images|grep xxx |
https://cloud.tencent.com/developer/article/1543689
https://www.cnblogs.com/frankming/p/16870285.html
http://ftp.usf.edu/pub/centos/7/virt/x86_64/xen-414/Packages/k/
在bclinux-for-eular操作系统上部署K8S集群后，安装上层的业务组件时，突然从某个组件开始，Pod无法正常启动。
查看description日志，出现了明显的too many open files错误：
1 | Normal Scheduled 41m default-scheduler Successfully assigned xx/xxx-v3falue7-6f59dd5766-npd2x to node1 |
因为使用的是docker作为CRI，所以先查看docker日志：
1 | time="2023-11-13T14:56:05.734166795+08:00" level=info msg="/etc/resolv.conf does not exist" |
从docker日志看，错误原因是：fork/exec /usr/bin/containerd-shim-runc-v2: too many open files: unknown，基本确认是**containerd的文件句柄打开数量过多**。
如下所示，查询到containerd运行时的文件句柄数限制为默认的1024，默认配置偏低。当节点容器过多时，就会出现容器无法启动的现象。
1 | [root@node1 ~]# systemctl status containerd.service |
查看containerd.service文件，没有对文件句柄数做显示配置（对比其他正常环境，操作系统安装完成后，containerd.service文件中存在LimitNOFILE配置）：
1 | [root@node1 ~]# cat /usr/lib/systemd/system/containerd.service |
修改containerd.service文件，显示配置文件句柄数，具体大小值根据实际需要：
1 | [root@node1 ~]# cat /usr/lib/systemd/system/containerd.service |
https://blog.csdn.net/weixin_42072280/article/details/126513751
K8S集群环境中有个容器化的组件A需要在节点上创建iptables规则实现请求转换，在centos 7的操作系统上功能正常，但在redhat 8的操作系统上发现该功能失效。具体来说，就是容器内iptables命令执行后没有生效。
业务组件A的功能是基于iptables命令的，查看当前容器内使用的iptables版本：
1 | ~ # iptables -V |
查看使用的centos 7宿主机上的iptables版本：
1 | [root@node1 ~]# iptables -V |
对比redhat8.4的环境，发现它提供的iptables版本较高，且**模式从默认的legacy变成了nf_tables**：
1 | [root@node1 ~]# iptables -V |
从redhat官方资料看[1]，该模式无法修改，因为在制作rpm包时删掉了legacy模式依赖的二进制文件：
1 | iptables changelog: |
而其他操作系统，如debian、alpine安装的高版本iptables均支持legacy和nf_tables两种模式，且支持切换：
1 | update-alternatives --set iptables /usr/sbin/iptables-legacy |
至此，基本确认是iptables模式不匹配导致的规则下发失效。实测在redhat8.4的环境，基于alpine的基础镜像制作的组件A，通过上述命令修改iptables为nf_tables模式后，规则下发正常。
为了同时支持centos 7和redhat 8，组件A需要在容器启动时按需选择iptables的模式，保证老环境使用原来的legacy模式，新环境调整为nf_tables模式。
K8S集群环境稳定运行一年后，pod重启卡在ContainerCreating状态：
1 | [root@node1 ~]# kubectl get pod -n kube-system -owide |
describe查看
1 | [root@node1 ~]# kubectl describe pod -n xxx xxx |
事件里显示的Unauthorized，也就是因为无权限从kube-apiserver中获取相关信息，查看对应pod使用的token，发现确实存在过期时间相关的定义：
1 | { |
查看相关issue[1,2,3]，基本确认是**k8s版本迭代引起的**，为了提供更安全的token机制，从v1.21版本开始，BoundServiceAccountTokenVolume特性进入beta版本，并默认启用。
kube-apiserver和kube-controller-manager组件添加feature gate禁用即可。1 | 1. How can this feature be enabled / disabled in a live cluster? |
token的一方适配修改，做到不缓存或者token失效后支持自动刷新新的token到内存即可，已知新版本的client-go和fabric8客户端均已支持。