zmoon460

我遇到过了，自己指定一下版本就行 ，看看当前的版本号，写道yaml里面 比如我的是 calicoctl: version: v3.26.1

containerd的目录，后期更改非常麻烦，建议安装时支持指定

用本地仓库+离线镜像方式啊， 每台主机的镜像拉取操作就是从仓库拉，不管是内部仓库还是外部仓库，如果真是要手动操作 可以这样 脚本方式导出第一台正常主机的在用镜像 ctr-save-img.sh `#!/bin/bash images=$(ctr -n=k8s.io images ls -q | grep -v @ | grep -v sha256) for image in ${images}; do filename=$(echo ${image} | sed 's/\//_/g' |...

如果用用kubekey的离线方式也觉得麻烦，用kubeasz更能满足需求，就用kubeasz，那个好就用哪个，我也是一个使用者而已。

这个 local_registry 确实没注意，但私有仓库仓库参数应该是指的 kubekey 自带的harbor仓库，我理解是 使用外置仓库服务可能才需要配置 local_registry

3.1.0r1 offline install one node k8s 1.28.6 , 40s timeout two bug : 1: /var/lib/kubelet/kubeadm-flags.env --cgroup-driver=cgroupfs change to --cgroup-driver=systemd 2: etcd service fail /etc/etcd.env ETCD_INITIAL_CLUSTER_STATE=existing change to ETCD_INITIAL_CLUSTER_STATE=new systemctl restart...

artifact miss containerd and runc ： # tar -xvzf kubernetes-v1.26.13-v8.tar.gz cni/v1.2.0/amd64/cni-plugins-linux-amd64-v1.2.0.tgz cni/v3.27.2/amd64/calicoctl crictl/v1.29.0/amd64/crictl-v1.29.0-linux-amd64.tar.gz docker/24.0.9/amd64/docker-24.0.9.tgz etcd/v3.5.6/amd64/etcd-v3.5.6-linux-amd64.tar.gz helm/v3.13.3/amd64/helm images/blobs/sha256/011c48d734f67a18f73c57b12c55f9078fb71f422d6603e5c5374713ba8e309e images/blobs/sha256/01bb612439acdb98f32f2dd90e9d24fa087bcfff053641a5cd0a81522ff10498 images/blobs/sha256/035cb4c70b01d6a8eac213cd0cc812de47d72639333571dc4c6f1e970e4dd1ab images/blobs/sha256/0621cf3d9f3e46ba3a1623e1c21c79fc382c45bb281829aa5c841bb037e5d65d images/blobs/sha256/067cb336aaee1991ba858f38e7e5a88ddea8abd4a6d0def896190eeae320a840 images/blobs/sha256/07a64a71e01156f8f99039bc246149925c6d1480d3957de78510bbec6ec68f7a images/blobs/sha256/0b46a5af7972c235f1aadf4ecd2b319d66ca653314d8a461db6e0542cc1f1c15 images/blobs/sha256/0b98362bb81cddefc791ce877528f53ca91c89fb105b9b9f58d8c3e0a546989f images/blobs/sha256/0bb3dace65bee9c9bf42f7d44594ca981906289f433782148d86541ebcc62616 images/blobs/sha256/0bc79ac9cc95d612fc38f424f36db6a31efce6f42e89159a15273463321a2c79 images/blobs/sha256/0d5dc31130d56697e46f159ebfca106cd1943ef6d0ac9115ec5f8d8fccc4a9d6 images/blobs/sha256/0f0d1a89066326404f38e0356fe06634afd2b87b98a3c304a4fa51a585db3c67 images/blobs/sha256/0f9e39b35c7c080c8fbac45a45fc947907530711c8a595db90d80ff215e70e8e images/blobs/sha256/10286f48c71be2a630e155ceb33e8e5132e861088b8d5db5ae0b2589912a958d...

我的一般思路： 1: 用新版的3.1.x kk 2：分别生成1.19 / 1.20/ 1.21/1.22 的最新离线manifest ，并定义/部署一个内部仓库（如果原来没有）。 3：基于这些manifest 生成离线文件包（不同版本的kk生成的离线文件格式有变过，要和kk版本对应） 4：基于当前环境，生成集群定义，或者使用当前已经保存好的集群定义文件。 5：集群定义文件 要定义一个前面部署的仓库字段： privateRegistry: "xx.xxx.xxx" 。 6： 推送所有版本的离线镜像到仓库： 如./kk artifact images push -f 1node-full.yaml -a kubernetes-v1.26.13-v8.tar.gz 7：基于各个版本的集群定义文件和离线包，执行升级 如:...

我看你主要是从dokcer.io拉取镜像问题，还是用内部仓库，提前准备镜像，再去升级才稳妥。

已知bug，用 3.1.7吧，下一个release 就fix了，或者自己用最新3.1分支编译一个